DNP3 Cold Restart e Warm Restart: diferença, Function Codes e teste seguro

Comece pelo significado: restart DNP3 não é um botão genérico

Cold Restart e Warm Restart são Function Codes da camada de aplicação DNP3 enviados pelo master a uma outstation. O código 13 (0x0D) solicita um cold restart; o código 14 (0x0E) solicita um warm restart. A distinção conceitual é importante: cold restart pede uma reinicialização completa do hardware e software conforme a implementação do equipamento, enquanto warm restart reinicializa apenas partes do dispositivo. O detalhe exato do que reinicia é dependente do fabricante e deve ser confirmado no manual do IED/RTU.

Para quem está começando, a regra é simples: nunca use “cold” ou “warm” como tentativa de corrigir comunicação sem antes saber o que o fabricante faz. Em um relé, RTU ou gateway, o efeito pode envolver aplicação, interfaces, base de dados, lógica ou reinicialização completa. Para quem já tem experiência, o ponto crítico é documentar o boundary da função: quais serviços param, quais estados persistem e qual é o tempo até a outstation voltar a responder.

O que observar na transação e no retorno da outstation

Um pedido de restart não deve ser avaliado apenas pelo desaparecimento momentâneo do ping. Capture a solicitação DNP3, confirme Destination/Source, Function Code e a resposta prevista pelo dispositivo. Algumas implementações informam um atraso estimado para reinício; outras simplesmente aceitam a solicitação e a comunicação cai. Após o retorno, observe o IIN Restart e a sequência de inicialização realizada pelo master.

O IIN Restart é especialmente útil porque transforma “acho que reiniciou” em evidência de protocolo. O master normalmente precisa executar sua política pós-restart: integridade, sincronismo de tempo quando necessário, reconstrução de eventos e eventualmente habilitação de unsolicited. O estado pós-restart deve ser tratado como parte do teste e não como detalhe administrativo.

Como testar sem colocar a operação em risco

Faça o ensaio primeiro em bancada ou equipamento fora de serviço. Registre firmware, configuração, alimentação, caminho de comunicação e estado de todos os serviços. Meça o tempo entre a solicitação e a primeira resposta válida após o retorno. Depois confirme Class 0, classes de evento, horário, permissões de controle e qualquer sessão redundante com outro master.

Em produção, restart remoto deve obedecer procedimento operacional e análise de consequência. Não basta saber que o protocolo permite a função. Verifique se o equipamento controla processo ativo, se existe redundância, se a perda temporária de telecontrole é aceitável e se o IED pode voltar em modo local, bloqueado ou com lógica transitória. A engenharia precisa definir quem tem permissão para emitir esses Function Codes.

Diagnóstico: quando restart vira sintoma, não solução

Se o master registra restart repetidamente sem ninguém emitir Function Code 13/14, investigue alimentação, watchdog, firmware, falha de aplicação, manutenção e reinicialização espontânea. Preserve logs do equipamento e IIN antes de reiniciar novamente. Um ciclo de restart pode esvaziar buffers, alterar timestamps e apagar justamente a evidência necessária para encontrar a causa.

Se a outstation retorna mas o SCADA fica incompleto, verifique se o master executou a sequência pós-restart: integrity poll, coleta das classes, time sync e reenable de unsolicited. O canal “online” não garante que o estado operacional foi reconstruído.

Sequência pós-restart: o que o master deve reconstruir

O teste de restart só termina quando o sistema volta a um estado operacional conhecido. Depois que a outstation reaparece, o master precisa reconhecer que houve reinicialização e executar a política definida para aquele projeto. Em uma implementação típica isso inclui confirmar o estado interno indicado pelo IIN, executar leitura de integridade para reconstruir os valores estáticos, recuperar eventos das classes configuradas, sincronizar o relógio quando necessário e restabelecer mecanismos que não sobrevivem ao restart, como a habilitação de Unsolicited Response em implementações que exigem novo ENABLE_UNSOLICITED. A ordem exata deve ser confirmada no Device Profile e no manual do equipamento.

Esse ponto é importante porque “voltou a comunicar” e “voltou a operar” são afirmações diferentes. Um canal pode aceitar READ depois do restart e ainda estar com horário incorreto, eventos pendentes, unsolicited desabilitado ou permissões de controle em estado diferente do esperado. No comissionamento, crie uma tabela com cada estado que deve ser reconstruído, o comando ou mensagem que o comprova e o tempo máximo aceitável para a recuperação. Preserve uma captura completa desde o Function Code de restart até a estabilização do canal; ela se torna um baseline extremamente útil para troubleshooting futuro.

• Confirmar o IIN Restart e registrar quando ele deixa de ser reportado conforme o comportamento do dispositivo.
• Executar a política de integridade e confirmar valores, flags de qualidade e classes de evento.
• Verificar Need Time e a política de sincronização de relógio antes de confiar em SOE posterior ao restart.
• Confirmar se Unsolicited permanece habilitado ou precisa ser habilitado novamente pelo master.
• Testar um comando permitido e seu feedback apenas quando o procedimento operacional autorizar.

Diferenças de fabricante e critérios de aceite

A norma define a função protocolar, mas não transforma todos os equipamentos em implementações idênticas. Um fabricante pode associar Warm Restart à reinicialização da aplicação de comunicação sem desligar funções críticas; outro pode reinicializar um conjunto maior de serviços. Cold Restart pode provocar reboot completo em um produto e ter restrições adicionais em outro. Alguns equipamentos rejeitam a função por configuração ou privilégio; outros devolvem uma informação de atraso antes da reinicialização. Por isso o artigo e o procedimento de campo precisam separar claramente o que é comportamento DNP3 padronizado do que é comportamento específico do equipamento.

O critério de aceite deve declarar versão de firmware, configuração, alimentação, papel da unidade e resultado esperado para Cold e Warm. Meça tempo até perda da sessão, tempo até primeira resposta válida, tempo até reconstrução da base e tempo até retomada de eventos/controles. Repita com uma fila de eventos pendente para saber se eles são preservados. Quando houver redundância de master, verifique se ambos interpretam o restart de forma coerente e se o failover não provoca uma sequência concorrente de inicialização. Esses dados são muito mais úteis do que registrar apenas “restart OK”.