Roteiro de atualização de SCADA legado

Em que ponto está o sistema antigo: leia antes os sinais de substituição

Muitas fábricas oscilam na dúvida de "atualizar ou não", mas os sinais de que um SCADA envelhecido vai começar a atrapalhar a produção são bem específicos. Basta um destes quatro aparecer para a atualização merecer lugar no cronograma:

• Fim do fornecimento de peças e licenças: placas, placas de rede e dongles descontinuados, sem como comprar; renovação da licença do sistema operacional ou do software SCADA impossível;
• Ambiente de execução defasado: o nível superior ainda roda sobre um sistema operacional sem suporte há muito tempo, como o Windows XP (sem suporte desde abril de 2014) ou o Windows 7 (sem suporte desde janeiro de 2020), sem fonte de correções nem de atualizações de segurança;
• Ruptura de pessoas: o engenheiro que conhecia parâmetros, scripts e a lógica histórica saiu ou se aposentou, e a equipe nova não consegue assumir;
• Alterações viraram risco: acrescentar um ponto de medição ou ajustar uma tela significa mexer em código antigo que ninguém ousa tocar, e o custo da mudança chega perto do de um sistema novo.

O roteiro de atualização: como andam os cinco passos

Decidida a atualização, defina a rota antes de mexer em qualquer coisa. Uma sequência confiável é:

• Avaliação e abertura do projeto: conte os pontos (tags), os tipos de interface, as telas e os anos de operação, e diga com clareza "o que a atualização deve resolver" — fim de peças, lentidão ou conexão com MES e plataforma de dados; objetivos diferentes levam a rotas diferentes;
• Inventário de ativos: exporte o conteúdo do sistema antigo item a item em listas que se tornarão a entrada de requisitos do sistema novo; este é o passo do roteiro que não pode ser pulado;
• Operação paralela: alimente os mesmos sinais nos dois sistemas, antigo e novo, por um período e compare dados, telas e comportamento de alarmes item a item;
• Transição por etapas: mude para o sistema novo setor por setor ou linha por linha — seções auxiliares de menor impacto primeiro, linha principal por último, com janela de observação após cada lote;
• Aceitação e entrega de documentos: cumpridos os critérios de operação contínua, faça a aceitação formal e conclua o treinamento de operadores junto com a entrega de documentos e do código-fonte.

Levantamento de ativos: cinco listas

A qualidade do inventário antes da operação paralela define o tamanho do risco no dia da transição. As cinco listas devem virar tabelas:

O que verificar durante a operação paralela

Rodar em paralelo não é "ligar e observar" — é comparar contra um checklist. Quatro verificações para esta janela:

• Consistência de dados: o mesmo ponto mostra os mesmos valores, curvas históricas e períodos de gravação nos dois sistemas, com atenção especial à conversão de faixas e ao tratamento de pontos inválidos;
• Telas e operação alinhadas: operadores executam partidas, paradas e ajustes de setpoint no sistema novo seguindo os hábitos de sempre, confirmando que posição de botões e lógica de confirmação não geram ambiguidade;
• Comportamento de alarmes comparado: diante da mesma perturbação, os dois sistemas disparam, classificam e registram alarmes de forma idêntica, para que o dia da transição não traga alarmes faltantes nem tempestade de alarmes;
• Cenários de borda e de falha: perda de comunicação, queda de energia e recuperação após reinício são ensaiados item a item, confirmando que o sistema novo se recupera tão bem quanto o antigo ou com desempenho ainda mais confiável.

Fechamento: transição e aceitação

A ordem no dia da transição nasce de um procedimento escrito antes. Quatro pontos para firmar no fechamento:

• Escreva o procedimento de transição e o plano de reversão: em que dia, quais setores, quem confirma — e as condições e etapas para voltar ao sistema antigo igualmente por escrito, evitando decisões improvisadas na planta;
• Aceitação formal só após cumprir os critérios de operação contínua: combine antes a duração e os critérios (por exemplo, um ciclo completo de produção sem parada causada pelo sistema novo); antes disso, o serviço não está concluído;
• Histórico migrado e ainda consultável: o histórico que o sistema antigo gravava nos períodos combinados precisa de destino, e as curvas devem continuar consultáveis como sempre foram — o piso da rastreabilidade da produção;
• Documentos, treinamento e código-fonte entregues juntos: na assinatura da aceitação, manuais, descrições de telas, listas de tags, arquivos-fonte do projeto e registros de treinamento vão juntos — sem deixar a situação "sistema vivo, conhecimento perdido".

Quatro riscos que aparecem repetidamente

Mesmo com método certo, algumas armadilhas voltam sempre:

Informações a preparar antes do projeto

Leve estas informações ao fornecedor da solução e o roteiro cai direto no cronograma: nome e versão do software SCADA antigo, sistema operacional do servidor superior, escala de tags e telas, forma de conexão com CLPs e instrumentos, volume do histórico e períodos de gravação, janela de parada aceitável para a transição e a questão que a atualização deve resolver primeiro. A Shanghai Chengxuan Intelligent atua desde 2009 em engenharia de software industrial e conectividade de equipamentos, com capacidade para desenvolver e atualizar sistemas SCADA e de nível superior; com base nas listas acima avaliamos o estado atual e propomos uma rota de atualização por etapas com plano de operação paralela, com contato por English-speaking team.

Nota histórica: por que as plataformas envelhecem

As plataformas que hoje chamamos de "legado" eram escolhas comuns quando foram criadas: o Modbus, publicado em 1979, segue amplamente usado em enlaces seriais e Ethernet, e o OPC UA, lançado em 2008 e depois padronizado como IEC 62541, tornou-se o padrão comum de intercâmbio de dados entre plataformas. A plataforma não envelheceu porque a escolha foi errada na época, e sim porque o ambiente trocou de geração ao longo de trinta anos — sistemas operacionais, exigências de segurança e usos dos dados mudaram todos. Nessa leitura, atualizar não é negar o passado; é mover um ativo para um ambiente onde ele pode continuar recebendo manutenção.