Refatorização de uma aplicação industrial antiga — quando faz sentido e como realizá-la sem riscos para a produção?

Porque é que este tema é importante hoje

A refatorização de uma aplicação industrial antiga deixou de ser uma questão de estética do código ou de conveniência de manutenção. Hoje, é uma decisão que afeta a continuidade da produção, a previsibilidade dos custos e o âmbito da responsabilidade do proprietário do sistema. Em muitas instalações, as aplicações de controlo, as ferramentas de operação e as camadas de comunicação foram desenvolvidas ao longo de anos sem uma arquitetura coerente, muitas vezes em torno de equipamentos, bibliotecas e mecanismos de integração cujo suporte é limitado ou já terminou. Durante algum tempo, esta situação pode ser tolerada, mas apenas até ao momento em que cada alteração adicional começa a custar mais do que a própria funcionalidade que deveria entregar. Nessa altura, a questão deixa de ser se vale a pena intervir na aplicação antiga e passa a ser se a organização continua, de facto, a controlar o seu comportamento em condições reais de produção.

A importância deste tema resulta do facto de, nos sistemas industriais, a dívida tecnológica se transformar muito rapidamente em dívida operacional. Se a aplicação é difícil de reproduzir, depende de pessoas específicas, não dispõe de testes de regressão fiáveis ou mistura na sua lógica funções de produção com funções de segurança e de diagnóstico, então qualquer incidente será mais dispendioso do que um problema semelhante num sistema de escritório. A consequência não é apenas a paragem. Soma-se o custo do trabalho da manutenção, o risco de soluções provisórias incorretas aplicadas sob pressão de tempo, a dificuldade em demonstrar a devida diligência após a alteração e o problema de distinguir o que já era uma falha anterior do que resultou da intervenção da equipa de projeto. Para um gestor e para o proprietário do produto, o critério prático é simples: se o tempo e a incerteza associados à implementação de pequenas alterações crescem mais depressa do que o seu valor para o negócio, a aplicação entrou num estado em que a decisão de refatorizar tem de ser tomada de forma consciente, e não adiada até à primeira falha crítica.

A maioria dos erros surge quando a refatorização é tratada como uma modernização “sem impacto no processo”, quando, na realidade, altera a forma como o sistema toma decisões. Na prática, basta uma intervenção aparentemente pequena: substituir um componente de comunicação, reestruturar o agendamento de tarefas, alterar a lógica de armazenamento temporário dos dados dos sensores ou reorganizar a sequência de arranque após reinício. No papel, parecem apenas ajustes técnicos. No chão de fábrica, porém, podem alterar o momento de envio de um sinal, a ordem de libertação dos bloqueios, a reação à perda de comunicação ou o comportamento da aplicação após uma falha de alimentação. É precisamente aqui que o tema da refatorização passa para a avaliação do risco da alteração segundo a ISO 12100: a questão não é saber se o código ficou “melhor”, mas se, após a alteração, a máquina, a linha ou o posto de trabalho continuam a comportar-se de forma previsível em condições normais, em situação de perturbação e após o rearranque.

Um bom teste à maturidade da decisão é verificar se a equipa consegue definir a fronteira entre uma alteração da estrutura interna da aplicação e uma alteração de uma função relevante para o processo ou para a segurança. Se essa fronteira não puder ser descrita ao nível dos sinais, dos estados e das condições de transição, o projeto fica exposto ao risco, independentemente da qualidade do executante. No ambiente industrial, são particularmente sensíveis as situações em que a aplicação participa na sequência de arranque, paragem, reposição de falhas, confirmação de alarmes ou coopera com sistemas de corte de energia e bloqueios. Nesse momento, deixa de estar em causa apenas a arquitetura do software, mas também a proteção contra o arranque inesperado e a questão de saber se a análise abrange igualmente a instalação elétrica, a lógica de controlo e as dependências entre equipamentos. É precisamente neste ponto que uma refatorização aparentemente local deixa de ser uma tarefa informática e passa a ser uma alteração técnica que exige um processo de decisão completo.

A referência aos requisitos normativos só ganha relevância nesta fase, porque as normas não substituem a decisão de projeto, mas ajudam a delimitar o seu âmbito. Se a alteração puder influenciar as condições de arranque, paragem, retoma do funcionamento após uma perturbação ou as medidas de proteção, deve ser avaliada como uma alteração de risco, e não como simples manutenção de código. Se a intervenção afetar a lógica que interage com o corte de energia, os bloqueios ou a sequência de acesso seguro, abre-se naturalmente também o campo dos requisitos relativos à proteção contra o arranque inesperado. Do ponto de vista da responsabilidade, o mais importante não é, portanto, apenas “se se deve refatorizar”, mas sim se a organização consegue demonstrar que conhece os limites da alteração, dispõe de critérios de aceitação baseados no comportamento do processo e sabe distinguir entre a reorganização do sistema e uma modificação que exige uma avaliação completa do risco e coordenação com o projeto da instalação e com os testes no terreno.

Onde o custo ou o risco mais frequentemente aumentam

O maior aumento de custos na refatorização de uma aplicação industrial antiga raramente resulta do próprio código. A origem do problema costuma estar numa qualificação incorreta da alteração: a equipa trata-a como uma reorganização da estrutura do programa, quando, na realidade, está a mudar o comportamento do sistema ao longo do tempo, a sequência das operações ou as condições de transição entre estados. Num ambiente de produção, este erro tem um impacto direto no projeto. O cronograma deixa de corresponder ao âmbito real, os testes passam a ser planeados para a funcionalidade informática e não para o desenrolar do processo, e a responsabilidade pelo resultado dilui-se entre a manutenção, a automação e o fornecedor de software. O critério prático aqui é simples: se, após a alteração, for necessário voltar a confirmar a sequência de arranque, paragem, retoma do funcionamento após uma perturbação ou a reação aos sinais dos circuitos de proteção, então já não se trata de uma “refatorização segura” no sentido organizacional, mas de uma alteração que pode gerar risco para a produção e exigir um processo de aprovação diferente.

Outro domínio típico de aumento de custos é uma decisão de projeto tomada sem uma visão completa das dependências. As aplicações industriais antigas estão frequentemente interligadas com a configuração do controlador, dos atuadores, da visualização, do arquivo de dados e dos procedimentos do operador. Na documentação, isto parece um único sistema, mas, na prática, são camadas desenvolvidas ao longo de anos por equipas diferentes. Uma refatorização destinada a melhorar a legibilidade do código ou a facilitar a manutenção futura pode alterar, sem que isso seja percetível de imediato, o significado dos atrasos, das condições de bloqueio, dos valores por defeito após reinício ou da forma de tratar um erro de comunicação. A consequência não é apenas uma correção técnica, mas também o custo de paragens, ensaios adicionais no terreno e discussões sobre se a falha já existia antes ou se foi introduzida pela alteração. Por isso, antes de decidir, vale a pena avaliar não apenas a dimensão da modificação, mas também o número e a criticidade dos pontos de interface: quantos sinais, receitas, modos de funcionamento e soluções operacionais de recurso dependem do fragmento de código que se pretende reestruturar. Quanto maior for o número desses pontos, menos sentido faz uma refatorização “aproveitando” outra tarefa.

Na prática, são particularmente dispendiosos os projetos em que a equipa só descobre os requisitos reais durante o arranque. Um exemplo típico é a reformulação de um módulo sequencial que, segundo a descrição, “faz o mesmo, só que de forma mais limpa”. No entanto, após a implementação, verifica-se que a versão anterior continha comportamentos não documentados que compensavam imperfeições da instalação: uma breve manutenção do sinal, tolerância a um sensor atrasado, uma sequência específica de reposição de alarme ou uma condição da qual dependia o acesso da assistência técnica. No código, isto parecia um erro ou dívida técnica, mas, para o processo, era um elemento de estabilização. Se a refatorização eliminar esses mecanismos sem identificar a sua função, o custo surge de imediato: aumenta o número de intervenções após o arranque, prolonga-se o tempo de aceitação e torna-se necessário reconstruir a lógica sob a pressão do funcionamento da fábrica. Por isso, a pertinência da refatorização também deve ser avaliada pela possibilidade de reproduzir o comportamento do sistema atual. Se a organização não dispuser de registo de eventos, descrições fiáveis dos modos de funcionamento e cenários de teste baseados no processo real, então primeiro é necessário criar essa base de avaliação e só depois tomar uma decisão sobre a reformulação.

Este tema conduz diretamente a uma avaliação prática do risco das alterações quando a modificação afeta funções de proteção, sequências de acesso seguro, o controlo do movimento dos atuadores ou o comportamento da instalação após falha e restabelecimento da alimentação. Neste âmbito, o custo de um erro não se limita a correções de programação, porque surge também a questão da responsabilidade pela autorização da alteração para entrada em serviço. Se a aplicação trabalhar em conjunto com sistemas hidráulicos, pneumáticos ou soluções como o comando bimanual, então a fronteira entre refatorização e alteração técnica torna-se ainda mais estreita e exige verificar se os pressupostos de projeto das medidas de proteção não foram comprometidos. É precisamente aqui que faz sentido recorrer a métodos estruturados de identificação de perigos de acordo com a ISO 12100, incluindo a abordagem utilizada na prática com base na ISO/TR 14121-2 e, no caso de sistemas hidráulicos, também aos requisitos de projeto organizados pela NP EN ISO 4413. Não se trata de formalismo por si só, mas de uma regra de decisão simples: se a alteração puder afetar a segurança do processo ou da operação, o seu custo deve ser calculado em conjunto com a validação, os testes no terreno e o regime de responsabilidade, e não apenas com o tempo de trabalho do programador.

Como abordar o tema na prática

Na prática, a pertinência de refatorar uma aplicação industrial antiga não se avalia pela atratividade tecnológica da mudança, mas sim pela possibilidade de reduzir simultaneamente o risco operacional e manter o controlo sobre a implementação. Para o gestor e para o proprietário do produto, isto significa uma mudança simples de perspetiva: a questão não é se “vale a pena organizar o código”, mas se o estado atual da aplicação dificulta, de forma real, a manutenção, os testes, a correção de falhas ou a introdução de novas alterações em conformidade com os requisitos. Se a resposta for afirmativa, a refatoração faz sentido, mas apenas na medida em que possa ser separada da operação produtiva e avaliada com base em efeitos mensuráveis. Um bom critério de decisão é comparar dois custos: o custo de manter a aplicação no estado atual, incluindo paragens, tempo de diagnóstico, dependência de pessoas específicas e risco de alterações incorretas, e o custo de uma reestruturação controlada com testes, validação e colocação em serviço. Sem esta comparação, o projeto tende normalmente a perder o controlo, porque a equipa acaba por financiar a reorganização do código com o orçamento destinado à funcionalidade, enquanto a responsabilidade pelas consequências na instalação fica por definir.

Por isso, a primeira decisão não deve ser “reescrevemos” ou “deixamos como está”, mas sim definir o limite da alteração. Numa abordagem madura, separa-se a parte que diz respeito exclusivamente à estrutura do software da parte que afeta a lógica do processo, as sequências de arranque, de paragem, os modos de funcionamento, a comunicação com os acionamentos e o comportamento após uma perturbação da alimentação elétrica. Esta distinção tem impacto direto nos custos e na organização. Uma alteração limitada à camada de reorganização do código pode ser conduzida num ciclo mais curto e com menor envolvimento das equipas de manutenção. Já uma alteração que interfira no comportamento da máquina ou da linha exige um plano de testes na instalação, uma janela de intervenção, um procedimento de reversão e a definição inequívoca de quem aprova a entrada em funcionamento. Convém, além disso, medir não só o tempo de execução dos trabalhos de programação, mas também o tempo necessário para repor o sistema após uma tentativa falhada, o número de áreas abrangidas pelos testes de regressão e o tempo necessário para diagnosticar um desvio após o arranque. Estes são os indicadores que mostram se a refatoração reduz efetivamente o risco do projeto, e não apenas se melhora o conforto de trabalho da equipa de desenvolvimento.

Um exemplo prático, típico de aplicações de controlo mais antigas, é o seguinte: o código contém múltiplos fragmentos repetidos responsáveis pelos interbloqueios de movimento, pelo tratamento de alarmes e pelas transições entre o modo manual e o automático. A equipa pretende uniformizá-los, porque a estrutura atual dificulta a evolução e provoca discrepâncias entre postos. Esta decisão só faz sentido depois de verificar se essa uniformização não altera as condições em que um elemento atuador recebe autorização de movimento e se, após o reinício do controlador, não surge uma sequência diferente de reposição do estado. Se a aplicação também controlar válvulas, acionamentos ou sistemas com energia armazenada, até uma refatorização aparentemente “interna” pode passar para o domínio da avaliação do risco da alteração segundo a ISO 12100 e exigir a análise da proteção contra o arranque inesperado. Nesse caso, uma prática sensata consiste em executar a refatoração por etapas: primeiro, reproduzir o comportamento num ambiente de teste; depois, separar os módulos sem alterar a lógica; por fim, verificar na instalação com um cenário de reversão previamente preparado. Isto limita a responsabilidade operacional e permite interromper a implementação antes que o problema tenha impacto na produção.

Só nesta fase é necessário um enquadramento normativo, porque as normas não substituem a decisão técnica, mas ajudam a definir o momento em que a alteração deixa de ser apenas um trabalho de programação. Se a refatoração afetar medidas de proteção, condições de acesso seguro, corte de energia ou o comportamento dos sistemas após paragem e novo arranque, entra naturalmente no âmbito de uma avaliação prática e estruturada do risco da alteração, também com recurso à abordagem conhecida da ISO/TR 14121-2. Quando surge o risco de arranque inesperado, já não basta verificar apenas o código: é igualmente necessário analisar a lógica de corte e de restabelecimento de energia, o que remete diretamente para as questões associadas à ISO 14118. Se, por sua vez, a aplicação estiver ligada a sistemas hidráulicos ou pneumáticos, a avaliação não pode ignorar os pressupostos de projeto desses sistemas, porque uma sequência de controlo incorreta pode comprometer o seu funcionamento seguro, independentemente da correção do próprio programa; nesse caso, torna-se também justificado recorrer aos requisitos que estruturam o projeto de sistemas hidráulicos. Na prática, isto significa uma coisa: o âmbito da refatoração não é determinado pela elegância da solução, mas pelo limite da responsabilidade pelo comportamento seguro da instalação após a alteração.

Aspetos a ter em conta na implementação

A implementação da refatoração de uma aplicação industrial antiga é o momento em que até uma decisão arquitetónica correta pode transformar-se num problema operacional. Todo o sentido da iniciativa termina no ponto em que a alteração melhora o código, mas piora a previsibilidade do funcionamento da instalação ou alarga a responsabilidade da equipa para além do que foi identificado e aprovado. O erro mais frequente consiste em tratar a implementação como uma simples publicação de uma nova versão. Num ambiente de produção, não conta apenas se a aplicação funciona, mas também se, após a alteração, todos os estados transitórios se comportam de forma idêntica: arranque após falha de alimentação, reinício da comunicação, reposição de receitas, tratamento de alarmes, interbloqueios e modos manuais. O critério prático é simples: se a equipa não consegue descrever de forma inequívoca quais os comportamentos que têm de permanecer inalterados após a implementação, isso significa que ainda não existem condições para uma entrada em funcionamento segura.

Na fase de decisão sobre a implementação, é necessário distinguir uma alteração tecnicamente reversível de uma alteração que, após entrar em funcionamento, cria uma nova linha de base e dificulta o regresso ao estado anterior. Isto tem consequências diretas no custo e no calendário. Uma refatorização que exige a atualização simultânea dos controladores, da visualização, do servidor de dados e das interfaces com os sistemas de nível superior deixa de ser uma tarefa isolada de programação; passa a ser uma alteração coordenada em produção, com múltiplos pontos de falha. Por isso, antes da implementação, vale a pena adotar um critério de aceitação baseado não na declaração “os testes passaram”, mas na capacidade de reverter a alteração de forma controlada num prazo aceitável para o processo. Se não existir um procedimento de reversão credível, também não há fundamento para afirmar que o risco foi controlado. Na prática, é preferível medir não uma abstrata “qualidade da implementação”, mas indicadores como o tempo de reposição da versão anterior, o número de interfaces dependentes da alteração e o número de funções cuja correção pode ser confirmada na instalação sem interferir na produção.

Um bom exemplo é a situação em que a refatorização organiza o tratamento de exceções e das mensagens de erro, mas ao mesmo tempo altera a sequência de inicialização após o reinício do sistema. No posto de teste, tudo parece correto, porque os equipamentos estão imediatamente disponíveis e o processo não trabalha sob carga. No entanto, na fábrica, o mesmo código pode iniciar a sequência num momento diferente do habitual, o que leva à perda de sincronização com os acionamentos, à interpretação incorreta dos sinais de prontidão ou à paragem de um lote de material num estado intermédio. Um incidente deste tipo não tem necessariamente de significar uma avaria em sentido técnico, mas gera custos de paragem, desperdício, novo arranque e responsabilidade adicional pela decisão de retomar o funcionamento. É precisamente aqui que o tema da refatorização passa para a avaliação prática do risco das alterações: não quando a alteração é grande, mas quando os seus efeitos já não podem ser limitados à camada de software.

O limite da responsabilidade torna-se ainda mais claro quando a aplicação afeta funções de proteção, a lógica de autorização de movimento, sequências de alívio, paragem e reinício após uma perturbação. Nesse caso, já não basta comparar versões de código nem realizar um teste funcional executado pelo integrador. É necessária uma avaliação estruturada para verificar se a alteração modifica o nível de risco e se não compromete os pressupostos de funcionamento seguro da máquina ou da instalação. Este é o momento natural para entrar no domínio da avaliação do risco de acordo com a ISO 12100 e das práticas utilizadas na avaliação do risco das alterações, sendo que, em casos mais complexos, pode ser útil a abordagem metodológica conhecida da ISO/TR 14121-2. Se a aplicação controlar sistemas hidráulicos ou pneumáticos, é ainda necessário verificar se a nova lógica não altera as condições de controlo seguro da energia nem a sequência dos movimentos; nesse caso, também são relevantes os requisitos de projeto próprios desses sistemas, e não apenas a correção do próprio programa. Para a equipa de projeto, isto significa uma coisa: a implementação só pode ser considerada preparada quando o âmbito da responsabilidade técnica, operacional e de conformidade tiver sido definido antes do arranque, e não apenas após o primeiro incidente.