Cenários de Automação: como planejar e escalar

Visão essencial: por que um “Scenario Automação” muda o jogo

Ao estruturar um Scenario Automação, você transforma necessidades operacionais em um plano executável: define como máquinas, sensores, sistemas e pessoas se coordenam para produzir com consistência. Na prática, um bom cenário reduz a variabilidade do processo, melhora a rastreabilidade e cria base para evolução contínua — do comissionamento ao acompanhamento do desempenho em operação.

Embora o termo possa aparecer em diferentes contextos, a ideia central permanece: cenários são descrições operacionais e tecnológicas que organizam eventos, condições, rotinas e integrações. Em ambientes industriais, isso costuma envolver lógica de controle, troca de dados em tempo hábil e padrões de resposta a falhas.

É importante perceber que “cenário” aqui não é apenas uma história de treinamento ou um diagrama genérico. Ele funciona como uma espécie de “contrato comportamental” entre as áreas: define o que o sistema deve fazer em cada estado, qual informação deve ser produzida, quais alarmes precisam orientar a ação e como exceções devem ser tratadas. Quando esse contrato existe, cada equipe consegue trabalhar com previsibilidade — e os problemas passam a ser resolvidos com base em evidências (logs, eventos correlacionados, critérios de teste e requisitos), em vez de discussões subjetivas do tipo “funcionou ontem, mas hoje não”.

Em muitos projetos, o que quebra não é a falta de equipamentos, nem a ausência de uma automação “visível”. O que quebra é a falta de um mecanismo consistente para responder ao mundo real: pequenas variações de matéria-prima, diferenças de comportamento entre operadores, atrasos de comunicação, instantes de falha de utilidades, leituras erráticas e o inevitável “modo degradado” que toda fábrica precisa saber operar. Um Scenario Automação é a ferramenta que organiza essa realidade em regras claras.

O que é, de fato, “Scenario Automação” em projetos industriais

No dia a dia de engenharia e operações, “Scenario Automação” funciona como uma camada de planejamento que conecta requisitos (qualidade, segurança, capacidade, manutenção) às escolhas técnicas (arquitetura, padrões de comunicação, estratégias de controle e validação). Em vez de tratar automação como “um conjunto de equipamentos”, o cenário trata como um sistema integrado.

Um cenário costuma especificar:

• Estado do processo (ex.: operação normal, ciclo de troca, modo degradado, parada planejada).
• Eventos e gatilhos (ex.: detecção de peça fora de especificação, abertura de intertravamento, falha de utilidade).
• Regras de decisão (ex.: o que fazer quando a taxa cai, como reagir a um desvio, quando chamar manutenção).
• Interfaces (chão de fábrica, supervisão, ERP/MES, logs, sistemas de qualidade e manutenção).

Essa organização ajuda a evitar um problema comum: “implementar automação” sem um mapa claro de comportamento e exceções. Em curto prazo, isso pode até funcionar; em médio prazo, a inconsistência aparece em manutenções, retrabalhos e paradas não planejadas.

Para tornar o conceito ainda mais prático, vale pensar que o cenário responde a perguntas do tipo: “Quando uma falha ocorre, o sistema entra em qual estado? Qual fluxo de informação é disparado? O que o operador vê? Quais registros entram no banco de dados? O que é necessário para retomar a produção sem violar requisitos de qualidade e segurança?”. Sem essas respostas, a automação tende a virar um conjunto de lógicas isoladas, onde cada componente “decide por conta própria” e a operação acaba dependente do instinto do operador e do conhecimento tácito.

Também é útil diferenciar o cenário do “desenho de telas” (HMI). O cenário não é apenas o que aparece no painel. Ele determina o que está por trás: transições, temporizações, validações, correlação de dados e a governança do que será considerado “real” para fins de rastreabilidade.

Componentes que sustentam um cenário robusto

Para que o Scenario Automação seja confiável, ele precisa de fundamentos técnicos sólidos. Do ponto de vista de um especialista, há três pilares: controle, dados e segurança (inclusive segurança funcional).

Esses pilares não são conceitos isolados; na prática, eles se reforçam. Um bom controle reduz situações de falha; dados consistentes permitem diagnóstico; e segurança funcional garante que, mesmo quando há falha, a planta permanece em condição previsível e apropriada. Quando um pilar é negligenciado, outro costuma ser “puxado” para compensar, gerando custos escondidos e retrabalho.

1) Controle e lógica de estados

Uma boa prática é modelar o processo por estados (normal, preparação, execução, limpeza, reset, parada). Assim, cada evento tem uma resposta previsível. Esse desenho facilita validação, testes e treinamento.

Modelar por estados significa reconhecer que o sistema não é um “loop infinito” de lógica contínua, mas sim um conjunto de fases. Cada fase tem: (a) permissões (o que pode acontecer), (b) expectativas (quais medições devem estar dentro de faixas), (c) comportamento quando algo foge do esperado, e (d) como voltar ao fluxo normal de operação. Essa modelagem também facilita a padronização de interfaces com supervisão: por exemplo, a HMI pode refletir o estado atual, e os registros podem associar eventos à fase em que ocorreram.

Além disso, estados ajudam a lidar com temporalidade. Em ambientes industriais, é comum que a resposta dependa de temporização: aguardar pressão estabilizar, confirmar temperatura por tempo mínimo, respeitar janela de troca, ou verificar que um sensor esteve “confiável” por N segundos. Sem estados e temporizações bem definidos, a lógica vira “gambiarras” de condições soltas, difíceis de manter.

2) Dados com semântica consistente

Automação sem padronização de dados gera “ruído”: indicadores que não fecham, alarmes duplicados e inconsistência entre relatórios. Por isso, o cenário deve definir o significado dos sinais, convenções de nomes, qualidade do dado e regras de registro (com timestamps, correlação por lote e critérios de descarte de eventos incompletos).

Semântica consistente é, muitas vezes, a diferença entre “ter dados” e “ter informações úteis”. Por exemplo:

• O que significa “Produto OK” no sensor? É uma leitura momentânea ou uma confirmação após testes? Em qual janela de tempo isso é válido?
• Qual é a unidade e a escala: mm ou cm, bar ou kPa, contagem ou taxa por minuto?
• O que acontece quando a leitura falha temporariamente (sensor intermitente)? O dado é marcado como inválido? É interpolado? É registrado como “unknown”?

O cenário também precisa prever “qualidade do dado” e como isso aparece na rastreabilidade. Em auditorias e análises de falhas, não basta dizer “registramos temperatura”. É necessário saber se a temperatura foi medida com confiabilidade, se houve saturação do sensor, se houve reconfiguração, se a medição ocorreu durante um modo de operação específico.

Outro ponto crítico é a correlação. Um registro deve conseguir relacionar: ordem de produção, lote (se aplicável), máquina, estação, turno, operador (quando pertinente), e sequência de eventos que levou ao resultado final. Isso costuma exigir IDs consistentes e regras para geração/propagação desses identificadores entre sistemas (CLP, SCADA, MES/ERP e base de dados corporativa).

3) Segurança operacional

Intertravamentos, redundâncias e estratégias de parada precisam estar incorporados ao cenário desde o início. Em termos práticos: o que acontece quando um sensor falha? Qual é o comportamento seguro? Quais modos de operação são permitidos?

Segurança funcional não é apenas “cumprir norma”. É desenhar comportamento de forma que falhas previsíveis não gerem situações perigosas. Por isso, o cenário deve definir:

• Quais sinais são “de segurança” (e como são validados).
• Quais ações são permitidas em cada estado (por exemplo, limpeza e retorno para operação normal).
• Quais intertravamentos bloqueiam saída de modo de falha (por exemplo, porta aberta, emergência ativa, ausência de condição mínima).
• Como ocorre reset/ack de alarmes de segurança, considerando que alguns eventos não devem ser “desarmados” sem verificação (dependendo da arquitetura).

Além disso, segurança operacional também inclui “segurança de processo” (por exemplo, evitar despejo indevido, evitar mistura incorreta, evitar execução em condição de utilidade insuficiente). Embora nem sempre seja rotulada como safety, a lógica de cenários precisa respeitar limites físicos, químicos e térmicos para prevenir danos, contaminação e riscos.

Arquitetura recomendada: do chão de fábrica ao nível corporativo

Mesmo sem entrar em marcas específicas, o desenho de Scenario Automação tende a seguir um padrão de referência: automação e supervisão no nível de controle, observabilidade e governança de dados no nível intermediário, e integração com sistemas corporativos no nível superior.

Uma abordagem típica inclui:

• Camada de campo: sensores, atuadores, CLPs/PLCs, I/O distribuído.
• Camada de controle: lógica de máquina, estados do processo, intertravamentos, ciclos.
• Camada de supervisão: HMI/SCADA, alarmes, dashboards, registro de eventos.
• Camada de integração: MES/ERP, qualidade, manutenção, gestão de lotes e rastreabilidade.

O ponto-chave é que o cenário não é só “fluxo de produção”; é também o fluxo de informação. Isso reduz disputas entre engenharia, operação e TI quando surgem divergências entre relatórios e o que foi realmente executado.

Se o cenário for pensado corretamente, cada camada “entende” o mesmo comportamento. Por exemplo, quando o CLP entra em um estado de falha, o SCADA deve refletir esse estado, criar um evento consistente e notificar o sistema de manutenção com contexto suficiente (o quê, onde, quando e quais condições estavam ativas). Se houver integração com MES, o cenário precisa prever como representar o impacto no status da ordem (parada, pausa, rejeição, reprocesso). Sem esse alinhamento, a fábrica vive em dois mundos: o mundo do controle (verdade operacional) e o mundo do corporativo (verdade contábil/relatorial). Quando isso acontece, o retrabalho vira parte do cotidiano.

Outro aspecto arquitetural relevante é o tratamento de “eventos” como entidade. Um cenário maduro trata eventos como registros com atributos (tipo, severidade, estado, correlação) e não apenas como mensagens textuais. Isso melhora a rastreabilidade e habilita análises posteriores: mineração de dados de falhas, identificação de padrões de comportamento degradado e auditoria de conformidade.

Planejamento com foco em requisitos: qualidade, disponibilidade e segurança

Uma metodologia objetiva para montar o Scenario Automação começa com requisitos. O especialista normalmente prioriza três eixos:

1. Qualidade: critérios de aceitação, medidas de processo, rastreabilidade por lote e gestão de não conformidades.
2. Disponibilidade: políticas de manutenção, reconhecimento de padrões de falha e estratégias de recuperação.
3. Segurança: conformidade com práticas aceitas, comportamento seguro em modos anômalos e validação de alarmes/intertravamentos.

Esse encadeamento evita que o cenário vire um “projeto técnico abstrato”. Ele se conecta ao que a operação realmente precisa.

Para ilustrar, considere um cenário de inspeção. Em muitos projetos, a lógica decide apenas “aprova/reprova”. No cenário robusto, você adiciona requisitos de qualidade como parte da decisão: quais parâmetros determinam aprovação? O que acontece quando algum sensor está fora de calibração? Como garantir que rejeitados não entrem no fluxo final? Qual o comportamento do sistema em reprocesso? Quais eventos são registrados para auditoria? Qual é a lógica de bloqueio e permissão para retestar?

Disponibilidade também tem nuances além de manutenção. Um cenário pode prever automaticamente recuperação: por exemplo, se uma utilidade falha momentaneamente, o sistema entra em “modo espera” e tenta retomar dentro de janela de tempo; se excede limite, muda para “modo falha” e solicita intervenção. Isso reduz paradas longas por eventos transitórios. Para isso funcionar, o cenário precisa ter temporizações, contadores, critérios de repetição e registro da causa presumida.

Segurança, por sua vez, permeia o desenho de estados e decisões. Um cenário pode definir: “mesmo que o operador pressione reset, a máquina não deve recomeçar se a condição de segurança não estiver atendida”. Além disso, deve prever como tratar falhas de leitura, intermitência e inconsistências entre sensores redundantes.

Questões de custo e precificação: como pensar preço sem ruído

Ao tratar de Scenario Automação, é comum surgir a pergunta sobre preço e o que está incluído. Em vez de buscar um valor genérico, o caminho mais consistente é estruturar a estimativa por escopo e fases: engenharia, comissionamento, integração, treinamento, validação, documentação, ciclos de teste e suporte assistido no pós-posta.

Como regra profissional, o “preço” depende de variáveis como complexidade do processo, número de estações, extensão de integrações e nível de requisitos de segurança funcional. Em projetos reais, relatórios e cotações devem detalhar o que está incluso (por exemplo: programação, painéis, comissionamento, testes FAT/SAT, instalação e documentação).

Condição prática: para comparar propostas com justiça, peça descrições de escopo por fase e critérios de aceite. Isso reduz surpresas e protege o cronograma.

Um elemento que costuma ser subestimado é a “engenharia de exceções”. Quando um cenário é bem definido, isso exige tempo para modelar comportamentos não ideais: atrasos, falhas de sensor, perda de comunicação, divergência entre estados, quedas de rede, variação de tempos de ciclo e falhas de utilidades. Sem orçamento adequado, a lógica pode ser entregue “funcionando no ideal”, mas sem cobertura de modos degradados — e aí os custos migram para o comissionamento e para o período pós-lançamento.

Outro ponto é a validação. Um cenário robusto raramente é “validado” apenas por uma sequência manual. Ele exige simulações, testes repetitivos, casos extremos, verificação de correlação de dados e auditoria de rastreabilidade. Isso pode incluir ferramentas, scripts de teste, procedimentos documentados e critérios objetivos, como “taxa de falha residual” ou “tempo máximo de recuperação”. Quando a proposta não contempla esses itens, o preço inicial pode parecer competitivo, mas a soma total de custo do projeto (incluindo paradas e retrabalho) pode aumentar.

Portanto, uma forma madura de negociar “preço” é considerar custo total: custo de engenharia, custo de validação, custo de integração, custo de formação das equipes e custo de sustentação. Em termos de risco, um cenário bem desenhado reduz incerteza — e isso costuma ser mais valorizado quando o negócio sofre com atrasos e quando a operação exige auditoria.

Fornecedor e capacidade técnica: como avaliar sem improviso

Outro aspecto recorrente é a escolha de fornecedor (ou integrador). O cenário de automação precisa de capacidade para desenhar, implementar, validar e sustentar mudanças. Na visão de um especialista, a avaliação deve ir além do “entrega do equipamento”. Deve incluir:

• Histórico de projetos similares (não só por setor, mas por complexidade e tipo de processo).
• Processo de engenharia: documentação, versionamento, gestão de alterações (change management).
• Metodologia de testes: FAT/SAT, simulações, critérios de aceitação, rastreabilidade de requisitos.
• Integração: experiência com troca de dados, padronização de tags, consistência de alarmes e logs.
• Capacidade de suporte: acompanhamento pós-partida, SLA e gestão de correções.

Em termos de risco, o cenário tende a falhar quando o fornecedor interpreta automação como “configuração pontual”, e não como sistema com comportamento e exceções bem definidos.

Uma forma objetiva de avaliar fornecedores é pedir evidências de maturidade em “práticas de cenário”. Exemplos:

• Existe uma estrutura de documento de cenário (ou equivalente) com estados, eventos, regras e integrações?
• Como o fornecedor garante rastreabilidade entre requisitos e testes? Existe matriz de rastreio?
• Como é feito versionamento das lógicas e como se controla regressão durante alterações?
• Qual é o padrão de alarmes (naming, severidade, texto e recomendação de ação)?
• Como são tratados eventos incompletos ou “perda de dados” (rede interrompida, falha de MES, atraso de mensagens)?

Quando o fornecedor responde com processos, evidências e critérios, o cenário deixa de ser um conceito e vira uma entrega controlável. Quando a resposta é vaga (“vamos ver depois”), o risco aumenta. Em automação, “ver depois” quase sempre significa “pagar depois”.

Onde o Scenario Automação costuma ser mais valioso

Há cenários típicos em que o Scenario Automação se torna particularmente relevante:

• Processos com múltiplos produtos e ajustes frequentes (trocas de parâmetros e sequências).
• Linhas com restrição de capacidade, onde pequenas variações geram gargalos.
• Ambientes com alta exigência de rastreabilidade e auditoria.
• Operações que dependem de manutenção preditiva/preditiva assistida por dados confiáveis.
• Integrações entre chão de fábrica e sistemas corporativos que exigem consistência semântica.

Além disso, existe um contexto muito específico em que o cenário muda o jogo: quando a operação precisa evoluir com frequência. Se a fábrica lança novos produtos, altera receitas, modifica parâmetros críticos ou troca componentes ao longo do ciclo de vida, um cenário bem arquitetado reduz o custo dessas mudanças. Sem um modelo de comportamento (estados e regras), mudanças viram “cirurgia improvisada” na lógica — e cada atualização cria chance de regressão.

Outro caso frequente é quando há equipes distribuídas ou quando a fábrica tem alta rotatividade de operadores. Um cenário melhora a transferência de conhecimento porque padroniza como o sistema reage. Assim, o operador aprende com o comportamento do sistema, não apenas com treinamentos. Isso também ajuda a reduzir erros humanos, especialmente em situações de falha e transição.

Comparação por abordagem: cenário “orientado a execução” vs. “orientado a integração”

A seguir, uma visão comparativa para apoiar a decisão. Use como referência para alinhar expectativas internamente e com o fornecedor.

Guia passo a passo para criar e validar um Scenario Automação

Se você precisa estruturar um Scenario Automação para um projeto em andamento ou uma nova linha, a sequência abaixo ajuda a reduzir risco e a aumentar a taxa de sucesso no comissionamento.

1. Mapeie o processo e seus estados

   Descreva como a operação acontece em normalidade e o que muda em condições anômalas. Identifique estados, transições e eventos.

2. Defina critérios de qualidade e rastreabilidade

   Estabeleça como serão confirmadas conformidades e como não conformidades serão registradas com correlação a lote/ordem.

3. Projete regras de exceção

   Especifique respostas para falhas típicas: sensores inconsistentes, interrupções de utilidades, tempo de ciclo acima do limite e falhas de comunicação.

4. Padronize tags e semântica

   Crie convenções para nomenclatura, unidades de medida, qualidade do sinal e regras de registro de eventos.

5. Integre segurança e modos de operação

   Documente intertravamentos e comportamentos seguros. Determine quais modos são permitidos e em quais condições.

6. Planeje testes com critérios objetivos

   Estabeleça como validar: cenários simulados, FAT/SAT, testes de intertravamento e aceitação por requisito.

7. Crie observabilidade operacional

   Defina dashboards e alarmes com foco em ações. Evite alarmes “decorativos” sem causa provável e sem orientação para tratamento.

8. Treine equipes e feche lacunas

   Treine operação e manutenção no comportamento do cenário. Garanta que a equipe sabe como agir nos principais eventos.

9. Revise após a partida

   Durante as primeiras semanas, colete lições: alarmes que não ajudam, tempos de recuperação, ajustes de lógica e melhorias de registro.

Condições e requisitos para que o Scenario Automação funcione no mundo real

Mesmo com engenharia bem feita, a operação pode sofrer se requisitos não forem cumpridos. Considere as condições abaixo como checklist.

• Requisitos de processo documentados: sem ambiguidade entre produção, qualidade e engenharia.
• Governança de mudanças: toda alteração deve ter impacto avaliado em controle, dados, alarmes e validação.
• Integração de rede e comunicação: latência, redundância e tratamento de falhas devem ser considerados desde o início.
• Critérios de aceite e validação: teste não é “ver funcionando”; é verificar requisitos e comportamento esperado.
• Capacitação do time: operação e manutenção precisam entender modos de falha e recuperação.

Além desses itens, há condições “operacionais” que raramente entram na lista inicial, mas que definem se o cenário vai “segurar a onda”. Por exemplo, o que ocorre quando existe divergência entre o que o sistema considera como estado e o que a operação realmente consegue fazer fisicamente? O cenário precisa contemplar a realidade do intertravamento mecânico, das rotinas de limpeza e das restrições de segurança. Também precisa prever como validar retorno ao serviço após manutenção: quais inspeções são necessárias, quais flags precisam ser resetados e como registrar evidências para qualidade e auditoria.

Outra condição essencial é o alinhamento de horários e relógios entre sistemas. Se a planta registra eventos com timestamps diferentes do MES/ERP ou do banco corporativo, a rastreabilidade perde valor. Em cenário maduro, o tempo é parte da governança: sincronização NTP, padrões de timezone, consistência de relógio e regras de reconciliação quando a rede está indisponível.

Também é importante garantir que o cenário tenha “capacidade de degradação”. Em redes instáveis ou em falhas temporárias de integração, o sistema precisa continuar operando de forma segura e previsível. Dependendo do requisito, ele pode continuar em modo local e “empilhar” eventos para envio posterior, ou pode restringir produção até restabelecer comunicação. O cenário define essas escolhas com base em risco, custo e requisitos de qualidade.

Fonte e base técnica (para referência e consistência)

Para manter o conteúdo alinhado com boas práticas reconhecidas na indústria, este guia se apoia em princípios amplamente adotados em automação industrial, segurança funcional e gestão de engenharia. Como referências gerais sobre conceitos e práticas, recomenda-se consultar:

• IEC 61508 (segurança funcional: fundamentos).
• IEC 62061 (segurança funcional em sistemas relacionados a máquinas).
• ISA-88 (modelagem de processos por bateladas; útil em cenários de estados e rotinas).
• IEC 62443 (segurança cibernética para sistemas de automação e controle industrial).

Uma observação prática: quando você incorpora padrões como IEC 62443 no desenho do cenário, o comportamento do sistema também precisa considerar segurança cibernética. Isso inclui: como o sistema reage a tentativas de acesso, como autentica ações do operador, como registra mudanças, e como diferencia incidentes de falhas operacionais comuns. Cenários com foco apenas em controle e dados podem ignorar vetores de segurança cibernética, o que abre espaço para incidentes e para mudanças não autorizadas no comportamento da planta.

FAQs sobre Scenario Automação

1) Scenario Automação é o mesmo que automação industrial?

Não exatamente. Automação industrial é a implementação de sistemas de controle e supervisão. Já o Scenario Automação é uma descrição/arquitetura do comportamento do processo (estados, eventos, exceções) e, muitas vezes, do fluxo de dados associado.

2) Como relacionar o cenário com qualidade e rastreabilidade?

O cenário deve definir quais eventos são relevantes para auditoria, como a conformidade é registrada e como dados são correlacionados a lotes/ordens. Isso exige semântica consistente e critérios de registro.

3) O que mais costuma gerar retrabalho em projetos de automação?

Tipicamente, a falta de modelagem de exceções, inconsistência na padronização de dados e ausência de critérios claros de aceitação e testes. Quando o cenário não prevê modos de falha, o “pós-posta” tende a consumir tempo.

4) Qual é a melhor forma de comparar propostas de fornecedores?

Compare por escopo e fases: engenharia, integração, testes, documentação, treinamento e suporte pós-partida. Solicite critérios de aceite e evidências de validação (FAT/SAT, testes de intertravamento e cenários simulados).

5) Como definir “preço” de forma objetiva em Scenario Automação?

Evite comparar valores sem detalhar entregáveis. O ideal é que o orçamento esteja decomposto por atividades e que inclua o que é necessário para validar o comportamento do sistema e sustentar a operação.

6) Em que projetos o cenário traz mais retorno?

Geralmente, em linhas com variação de produtos, exigências de rastreabilidade, integrações com sistemas corporativos e operações onde paradas e desvios custam caro. Nesses casos, a previsibilidade operacional é valiosa.

Conclusão: do mapa ao desempenho contínuo

Um Scenario Automação bem estruturado conecta tecnologia e operação por meio de estados, eventos, regras de decisão e um fluxo de dados confiável. Ao tratar automação como sistema — e não como “conjunto de equipamentos” — você reduz variação, melhora a qualidade, fortalece a segurança e cria uma base sólida para evolução.

Se seu objetivo é escalar, padronizar e integrar com menos atrito entre engenharia, produção e TI, comece pelo cenário: é nele que as decisões se tornam comportamento verificável.

Para que isso continue gerando valor ao longo do tempo, o cenário deve ser tratado como um artefato vivo: recebe melhorias a partir do que a planta aprende durante partidas e operação, mas mantém governança. Isso significa controlar versões, registrar mudanças, atualizar documentação, revalidar pontos críticos e garantir que o comportamento permaneça consistente. Assim, o Scenario Automação não vira um documento “para o projeto”; vira o alicerce que sustenta o desempenho contínuo — reduzindo paradas, elevando a qualidade e permitindo evoluções mais rápidas e seguras.

Em última instância, o cenário é aquilo que transforma automação em previsibilidade. E previsibilidade, na fábrica, é dinheiro: dinheiro economizado em retrabalho, dinheiro evitado em paradas não planejadas, dinheiro ganho em qualidade e auditoria, e dinheiro investido com segurança para crescer. É por isso que, na prática, quando uma empresa organiza seu comportamento operacional com um Scenario Automação, ela muda o jogo — não só na implementação, mas também na maneira de operar e evoluir a planta.