Crescimento da fábrica e arquitetura IT/OT – porque é que as integrações provisórias acabam por cobrar o preço ao fim de alguns anos?

Porque é que este tema é importante hoje

O desenvolvimento de uma fábrica já raramente consiste em acrescentar uma máquina ou colocar em funcionamento mais uma linha de forma isolada. Normalmente, significa expandir um ambiente em que os sistemas de produção, a manutenção, a qualidade, o planeamento, o armazém e o reporting de gestão têm de trocar dados e influenciam-se mutuamente na disponibilidade do processo. Neste contexto, a arquitetura IT/OT deixa de ser uma questão técnica “a definir mais tarde” e passa a ser uma decisão de projeto com consequências financeiras e organizacionais. As integrações provisórias funcionam na fase de arranque, porque resolvem um problema imediato: ligam rapidamente uma nova máquina, exportam alguns sinais para um relatório, contornam limitações de um controlador mais antigo. O problema surge alguns anos depois, quando a unidade tenta aumentar a eficiência, cumprir novos requisitos de conformidade ou alterar com segurança o modo de funcionamento da instalação. Nessa altura, percebe-se que o problema não está num cabo ou num script isolado, mas na ausência de regras coerentes de comunicação, responsabilidade e separação de funções.

O maior erro é tratar estas soluções como se fossem neutras em termos de custo. Na realidade, apenas adiam o custo no tempo e, regra geral, fazem-no no pior momento possível: durante uma ampliação, uma auditoria, um incidente ou uma mudança de fornecedor. Do ponto de vista do projeto, a consequência não é apenas uma implementação mais cara da fase seguinte, mas também a perda de previsibilidade. A equipa deixa de saber quais são as dependências críticas para a continuidade da produção, onde termina a responsabilidade do integrador e onde começa a responsabilidade do proprietário da unidade, ou que alterações exigem uma nova avaliação de risco. Na prática, é precisamente aqui que começa a área dos custos ocultos de decisões de projeto erradas: paragens adicionais, intervenções de serviço pontuais, novas receções, dificuldades em documentar alterações e litígios sobre o âmbito da garantia. Se a arquitetura não tiver sido descrita como um modelo consciente de desenvolvimento da fábrica, cada etapa seguinte ficará onerada por dívida técnica e organizacional.

Um bom teste prático não é perguntar se a integração “funciona”, mas sim se pode ser alterada com segurança e de forma previsível dentro de duas ou três fases de investimento. Se uma nova linha exigir mapeamento manual de sinais em vários pontos, se o conhecimento sobre as ligações estiver disperso entre fornecedores e se a reconstrução do percurso completo dos dados exigir análise do código dos controladores, de bases intermédias e de serviços não documentados, então o projeto já entrou numa trajetória de risco acrescido. Vale a pena avaliar a situação com base em três critérios mensuráveis: o tempo necessário para introduzir uma alteração controlada, a possibilidade de identificar de forma inequívoca o responsável por cada troca de dados e a capacidade de reconstruir o impacto de uma avaria ou modificação na produção e na segurança. Se estas três dimensões não forem claramente identificáveis, o problema já não diz respeito à conveniência da equipa, mas à capacidade de controlo de todo o empreendimento.

O exemplo prático repete-se com frequência: a unidade arranca uma nova área de produção e, para garantir um início rápido, liga os dados de processo aos sistemas empresariais através de soluções intermédias criadas fora da arquitetura final. Durante algum tempo, tudo parece estar correto, porque o fluxo de dados é suficiente para o reporting e para a supervisão corrente. A dificuldade surge com a continuação da automação industrial, com a integração com a manutenção ou com a alteração da lógica de funcionamento da máquina. Nessa altura, uma única modificação na camada operacional afeta relatórios, alarmes, receitas ou o acesso remoto, e as dependências deixam de ser evidentes. Se, além disso, a solução interferir com funções relacionadas com a paragem, o corte de energia ou o bloqueio do rearranque, o tema deixa de ser apenas uma questão informática. Passa para o domínio da segurança funcional e exige uma análise autónoma, incluindo a verificação de que não foram comprometidos os pressupostos relativos à proteção contra o arranque inesperado. É neste ponto que a arquitetura IT/OT se cruza diretamente com a análise de risco no projeto de desenvolvimento da fábrica e com decisões que, mais tarde, também influenciam o âmbito da avaliação da conformidade e da documentação técnica.

Por isso, este tema exige uma decisão agora, e não depois de concluído o arranque. Não porque todas as integrações tenham de ser complexas desde o início, mas porque logo à partida é necessário distinguir uma solução temporária de uma solução que passará a integrar a arquitetura permanente da unidade. Esta distinção deve ter consequências no projeto: um responsável específico pela decisão, condições para eliminar a solução de contorno, requisitos de documentação e critérios de reavaliação em caso de ampliação. Se a unidade estiver a planear novas fases de investimento, modernização de máquinas ou preparação para a avaliação da conformidade, a ausência desta distinção quase sempre aumenta o custo da alteração e alarga o âmbito da responsabilidade do investidor. É precisamente por isso que a arquitetura IT/OT já não é hoje um complemento ao projeto, mas uma das condições para manter o controlo sobre o custo, o calendário e o risco.

Onde o custo ou o risco mais frequentemente aumentam

Na evolução de uma fábrica, o mais dispendioso raramente são as próprias interfaces entre IT e OT, mas sim as consequências de decisões tomadas “provisoriamente” e que, passados alguns anos, acabam por assumir o papel de arquitetura permanente. A integração improvisada cobra o seu preço não por ser tecnicamente imperfeita, mas porque ninguém definiu os seus limites: quem é responsável pela alteração, quais são os dados de referência, como repor a configuração após uma avaria e em que momento a solução de recurso deve ser eliminada. Na prática, o custo aumenta quando uma solução temporária passa a fazer parte da manutenção, da produção, da qualidade ou do reporting de gestão sem uma decisão formal de que, a partir desse momento, se torna um elemento crítico. Para o projeto, isto traduz-se mais tarde em conflitos sobre orçamento e âmbito e, para a organização, também numa diluição de responsabilidades: a avaria parece um problema técnico, embora a sua origem esteja numa decisão de arquitetura que nunca foi formalmente encerrada. Um critério útil de avaliação é uma pergunta simples: após a expansão da unidade, é possível identificar o responsável pelo processo, o responsável pelos dados e um procedimento de alteração segura sem depender “da única pessoa que sabe como isto funciona”? Se não, o risco já está incorporado no projeto.

Uma segunda área de custos crescentes é a ausência de separação entre a camada de controlo e a camada de troca de dados de negócio. Na fase inicial do investimento, este atalho pode parecer tentador: o mesmo servidor faz a mediação da comunicação com a máquina, arquiva dados, alimenta relatórios e assegura o acesso remoto do serviço técnico. Numa linha isolada, isto parece funcionar de forma aceitável, mas, nas fases seguintes de expansão, qualquer alteração num objetivo acaba por afetar os restantes. Uma atualização imposta pelo sistema corporativo pode comprometer a continuidade da produção, e a necessidade de relatórios mais rápidos pode levar a intervenções na configuração de equipamentos que antes operavam de forma estável. Nessa altura, os custos ocultos de decisões de projeto incorretas não se limitam à compra adicional de hardware ou de serviços do integrador. Muito mais gravosos são os custos de paragens, novos testes, trabalho noturno durante as implementações e a necessidade de reconstruir conhecimento que não ficou registado em lado nenhum. Do ponto de vista da gestão de projetos, o mínimo razoável é avaliar se uma avaria ou alteração na componente informática pode parar a função operacional da máquina ou da linha. Se a resposta for afirmativa, a arquitetura precisa de ser corrigida, independentemente de “para já funcionar”.

Um exemplo típico surge na ligação de novas máquinas à infraestrutura já existente da fábrica. O fornecedor coloca o equipamento em funcionamento rapidamente, porque é preciso concluir a receção e arrancar a produção, e por isso implementa a comunicação com os sistemas da unidade através de um computador adicional, de um script de exportação de ficheiros ou de um mapa de sinais alterado manualmente. Ao fim de um ano, entra mais uma máquina; ao fim de dois, muda o sistema de nível superior; e, ao fim de três, verifica-se que ninguém consegue descrever de forma inequívoca quais as mensagens críticas para o processo, quais servem apenas para reporting e quais são relevantes para diagnóstico ou rastreabilidade do lote. Neste ponto, o tema entra já parcialmente no domínio da elaboração de instruções de operação de máquinas, porque, se o operador, a manutenção ou o serviço técnico não dispõem de regras documentadas para atuar em caso de perda de comunicação, modo manual de recurso ou reposição de parâmetros após a substituição de um componente, então o problema deixa de ser exclusivamente informático. Passa a fazer parte da organização de uma exploração segura e da responsabilidade posterior pela forma de utilização e pelas modificações.

É só nesta fase que se percebe por que motivo o tema regressa também na avaliação da conformidade, na documentação técnica e na orçamentação das alterações. Se a integração afetar as funções da máquina, a lógica dos bloqueios, a forma de confirmação dos estados ou a informação transmitida ao utilizador, pode ser necessária uma nova análise de risco e a verificação de que a documentação continua a corresponder à solução efetivamente implementada. O âmbito desta avaliação depende da natureza da alteração, pelo que não é possível resolvê-lo de forma séria com uma única frase universal, mas é precisamente por isso que as soluções provisórias saem tão caras: dificultam determinar o que foi realmente alterado e quais são as consequências legais e operacionais. Para a equipa de decisão, o critério prático é o seguinte: se a alteração na integração não puder ser descrita na documentação de configuração, no procedimento de ensaio e nas regras de exploração sem recorrer a conhecimento informal, então o projeto já entrou numa zona em que aumenta não só o custo técnico, mas também a responsabilidade do investidor, do gestor de projeto e das pessoas que autorizam a entrada da solução em funcionamento.

Como abordar o tema na prática

Na prática, a questão não é se a integração entre IT e OT deve ser feita mais depressa, mas sim onde traçar a fronteira entre uma solução temporária e uma dívida de arquitetura que, dentro de alguns anos, irá bloquear o desenvolvimento da fábrica. As ligações provisórias surgem normalmente sob pressão do arranque: é preciso extrair rapidamente dados da máquina, acrescentar uma nova linha, ligar o sistema da qualidade aos registos de produção ou garantir acesso remoto para assistência técnica. O problema começa quando uma solução implementada “temporariamente” se transforma na base de decisões de projeto subsequentes. A equipa perde uma divisão clara de responsabilidades, e cada expansão passa a exigir a reconstrução de conhecimento a partir de correspondência, definições locais e práticas dos operadores. Isto já não é um pequeno incómodo técnico, mas um fator que afeta o calendário, o custo da alteração e a capacidade de demonstrar quem autorizou determinada solução a entrar em funcionamento, e com base em quê.

Por isso, a abordagem correta começa por uma decisão de arquitetura, e não pela escolha da ferramenta. O gestor ou responsável pela área deve exigir que cada nova integração tenha um objetivo operacional definido, um responsável de cada lado da fronteira IT/OT e condições de manutenção estabelecidas para depois da entrada em funcionamento. Se não estiver claro quem responde pela fonte de dados, quem aprova a alteração de configuração, quem testa os efeitos no processo e quem decide o modo de contingência, então o projeto está, na prática, a transferir o risco para a fase de exploração. É precisamente aqui que começa, de forma natural, o papel do gestor de projeto nas decisões IT/OT: não como coordenador de prazos, mas como a pessoa que obriga a clarificar responsabilidades antes que uma solução improvisada seja inscrita no orçamento e no cronograma como “solução rápida”. O critério prático de avaliação é simples: se a integração planeada não puder ser mantida após a mudança de fornecedor, a substituição do controlador ou a ampliação da linha sem a participação do autor da solução improvisada original, então não se trata de uma solução temporária, mas sim de um custo futuro do projeto.

Um bom teste é a situação em que uma linha de produção existente é ampliada com um posto adicional, que deve transmitir dados ao sistema de nível superior e, ao mesmo tempo, reagir aos estados da parte já em funcionamento. Se a equipa decidir ligar diretamente os sinais e fazer uma tradução informal dos dados “porque assim será mais rápido”, no início tudo pode funcionar corretamente. Com o tempo, porém, surgem efeitos secundários: torna-se mais difícil determinar se o erro resulta da lógica da máquina, da camada de comunicação ou da aplicação de reporte; os testes de aceitação cobrem apenas os cenários padrão; a modernização de um elemento obriga a correções em vários pontos ao mesmo tempo. É também nessa altura que se tornam visíveis os custos ocultos de decisões de projeto erradas: paragens adicionais para diagnóstico, presença dispendiosa do integrador em cada alteração, disputas sobre o âmbito da garantia e atrasos nas fases seguintes do investimento. Por isso, vale a pena medir não só o tempo de arranque, mas também o número de pontos de integração que exigem configuração manual, o tempo necessário para analisar um incidente após uma alteração e o número de mudanças que têm de ser testadas de forma transversal em vez de local.

Só neste contexto faz sentido remeter para os requisitos de segurança e conformidade. Se a integração afeta os estados de funcionamento da máquina, os bloqueios, as confirmações de sinais, a sequência de arranque ou de paragem, deixa de ser um complemento informático neutro. Dependendo da natureza da alteração, isso pode desencadear a necessidade de uma nova avaliação de risco, da atualização da documentação técnica e da verificação de que o modo de utilização continua a corresponder aos pressupostos adotados para a máquina ou linha em causa. Isto é particularmente evidente quando a camada de integração começa a influenciar indiretamente as condições de acesso seguro, de corte de energia ou de prevenção de arranque inesperado. Nesse caso, a decisão de arquitetura deixa de pertencer ao domínio da conveniência de implementação e passa para o domínio da responsabilidade jurídica e técnica. Se a equipa não consegue demonstrar quais as ligações que têm caráter exclusivamente informativo e quais as que influenciam o comportamento da máquina, isso é um sinal de que o tema deve sair do nível da “integração de sistemas” e ser tratado como uma alteração relevante para a segurança, para o orçamento e para a responsabilidade das pessoas que aprovam a solução.

O que ter em atenção na implementação

A maior parte dos problemas não resulta da própria integração IT/OT, mas do facto de, no projeto, ela ser tratada como um meio rápido para ativar uma nova função, e não como um elemento duradouro da arquitetura da fábrica. É precisamente aí que as ligações provisórias acabam por cobrar o seu preço passados alguns anos: na ampliação da linha, na substituição de controladores, na mudança de fornecedor do sistema de nível superior ou numa auditoria de segurança de máquinas e linhas de produção, verifica-se que ninguém consegue indicar de forma inequívoca o responsável pela interface, as regras do seu funcionamento nem as consequências de uma falha. Para o projeto, isto significa não só o custo da dívida técnica, mas também um custo organizacional: mais alinhamentos, testes transversais mais longos, aceitações mais difíceis e maior risco de que o atraso só apareça no fim, quando o cronograma já é o menos flexível possível. Neste ponto, o tema passa naturalmente para o campo dos custos ocultos de decisões de projeto erradas, porque a origem do problema não é um erro isolado de execução, mas a decisão de adiar uma arquitetura sólida para mais tarde.

Por isso, na implementação, vale a pena avaliar a solução não pela perspetiva de saber se “funciona agora”, mas sim se pode ser mantida e alterada com segurança de forma previsível. O critério prático é simples: se a integração planeada não tiver o âmbito de responsabilidades descrito, o modo de falha definido, as regras de versionamento estabelecidas e o procedimento de testes após alteração, então ainda não está pronta para implementação em produção, mesmo que funcione num posto de teste. Isto é particularmente importante onde a mesma interface deve servir a fase atual do investimento e a futura ampliação. O desenvolvimento da fábrica aumenta quase sempre o número de dependências entre sistemas, e as soluções improvisadas funcionam pior precisamente quando cresce o número de exceções, contornos e acordos locais. Na perspetiva da engenharia de projeto, isto significa a necessidade de decidir cedo quem aprova as decisões de fronteira entre a automação, a manutenção, a informática e a conformidade, porque sem isso a responsabilidade dilui-se exatamente onde mais tarde surgem os maiores conflitos sobre custo e prazo.

Um exemplo prático típico é acrescentar a troca de dados entre a linha e o sistema de reporting através de um script intermédio ou de um serviço não documentado executado num servidor que “já existe na fábrica”. Na fase de arranque, a solução parece racional: não exige alterações do lado do fornecedor da máquina, encurta a implementação e permite demonstrar rapidamente o resultado de negócio. O problema surge mais tarde. Após uma atualização do sistema operativo, uma alteração de endereçamento, o restauro de uma cópia de segurança ou a substituição de um equipamento, ninguém tem a certeza de que a lógica de mapeamento dos sinais continua a corresponder à realidade do processo. Se este mecanismo participar em confirmações, bloqueios, enfileiramento de ordens ou condições de arranque, a falha deixa de ser um incidente informático e passa a afetar a disponibilidade da linha, a qualidade da produção e a responsabilidade pela colocação da solução em exploração. Nesse momento, o tema passa naturalmente para a análise de risco no projeto de desenvolvimento da fábrica, porque é necessário avaliar não só a probabilidade de falha, mas também as consequências de uma informação incorreta, de uma sequência incorreta e de uma reação incorreta do operador.

Só neste contexto faz sentido remeter para os requisitos formais. Se a camada de integração se mantiver exclusivamente informativa e isso puder ser demonstrado tecnicamente, o âmbito das obrigações será diferente do que numa situação em que influencia o comportamento da máquina ou da linha. No entanto, se interferir com a lógica de funcionamento, as condições de arranque, paragem, confirmação ou bypass, a implementação deve ser tratada como uma alteração com relevância técnica e potencial impacto na segurança, e não como uma simples expansão do sistema. Isto pode significar a necessidade de rever os pressupostos da adequação das máquinas aos requisitos mínimos, a documentação técnica e as condições de conformidade adotadas para a solução em causa. Na prática, a decisão segura não é “se isto pode ser ligado”, mas sim “se, após a implementação, seremos capazes de demonstrar o que esta interface faz, quem é responsável por ela e como controlamos a alteração”. Se a resposta não for inequívoca, o custo da decisão arquitetónica adiada acabará normalmente por regressar na modernização seguinte, na certificação CE de máquinas ou após um incidente, e nessa altura já não será apenas um problema técnico, mas também de gestão.