Comandos DNP3: CROB, SBO, Direct Operate e segurança operacional

Comando remoto exige mais evidência do que “o bit mudou”

Em telecontrole DNP3, um comando não é apenas um valor booleano enviado ao equipamento. A transação possui modelo de operação, objeto de controle, índice, código de controle, temporizações e um status devolvido pela outstation. Além disso, o IED ou RTU pode aplicar permissivos, modo local/remoto, bloqueios, intertravamentos e lógica de processo. O protocolo pode aceitar a solicitação e o equipamento primário ainda assim não executar a manobra por uma condição operacional legítima.

Por isso, o comissionamento precisa separar três perguntas: o master montou o comando correto? A outstation aceitou o comando DNP3? O processo executou a ação esperada? Cada resposta requer evidência diferente: PCAP, log do IED e mudança física/lógica confirmada.

CROB: o bloco de controle binário

Control Relay Output Block, normalmente associado ao Group 12, representa comandos binários. O CROB carrega informações que descrevem a operação desejada e parâmetros de execução. Entre os campos encontrados em implementações estão control code, count, on-time, off-time e status. A interpretação exata dos códigos e limites deve ser confirmada na IEEE 1815 e no Device Profile.

O índice continua sendo fundamental: ele identifica qual saída lógica está sendo comandada. Uma lista de pontos que documenta apenas “abrir disjuntor” sem registrar o índice de controle e o retorno associado é incompleta. O mesmo equipamento pode ter índices separados para trip, close, reset, bloqueio ou outras funções.

• Index — O que é: identifica o ponto de controle. Efeito: seleciona a saída/função lógica. Validar: mapa de pontos, captura e resposta do equipamento.
• Control code — O que é: codifica o tipo de operação do CROB. Efeito: diferencia pulso, latch e outras operações previstas. Validar: Device Profile, manual e decodificação do request.
• Count — O que é: quantidade associada à execução repetida quando suportada/aplicável. Efeito: pode alterar número de operações. Validar: capacidade do dispositivo; não usar valor arbitrário em equipamento energizado.
• On-time — O que é: duração de energização/estado ativo para operações temporizadas quando aplicável. Efeito: define duração do pulso. Validar: requisito da saída, limites do IED e ensaio seguro.
• Off-time — O que é: intervalo inativo em sequências repetidas quando aplicável. Efeito: participa da temporização do controle. Validar: documentação e comportamento real.
• Status — O que é: resultado devolvido pela outstation para a operação. Efeito: distingue sucesso de recusas/erros. Validar: response DNP3 e log local.

Select Before Operate: duas etapas e uma janela de validade

No Select Before Operate, o master envia SELECT para o objeto de controle. A outstation valida a seleção e responde. Em seguida, dentro da janela prevista e mantendo coerência dos parâmetros, o master envia OPERATE. A vantagem é permitir que a estação valide a intenção antes da execução. A seleção, porém, não deve ser confundida com autenticação de usuário ou autorização de cibersegurança.

Se o OPERATE chega depois que a seleção expirou, com campos incompatíveis ou sem seleção válida, a outstation pode recusá-lo. Isso explica falhas em canais de latência alta quando timers são copiados de uma LAN sem medição. O teste deve medir o tempo SELECT→response→OPERATE e confrontá-lo com a configuração do dispositivo.

Direct Operate: uma transação mais curta, com responsabilidade maior na engenharia

Direct Operate solicita execução em uma única sequência request/response, sem a etapa SELECT prévia. A IEEE 1815 também define formas sem resposta para casos específicos, mas o uso operacional precisa ser cuidadosamente avaliado. Menos mensagens não significa automaticamente melhor arquitetura. Para manobras críticas, a escolha do modelo deve considerar política de operação, latência, confiabilidade, rastreabilidade e capacidades do equipamento.

A decisão SBO versus Direct Operate não deve ser tomada apenas para “fazer funcionar”. Se um master tenta Direct Operate e a outstation foi projetada/configurada para exigir SBO, a recusa é comportamento correto. Documente o modelo aceito para cada ponto ou classe de controle.

Function Codes: distinguir comando da aplicação e resultado do processo

Na aplicação DNP3, SELECT, OPERATE e DIRECT_OPERATE são Function Codes distintos. Em uma captura, identifique primeiro qual função foi enviada e qual objeto/índice ela carregou. Depois examine o status de controle retornado. Um TCP ACK não significa que o comando foi aceito; uma response DNP3 bem-formada também não prova que o disjuntor mudou de posição.

O fechamento do caso só ocorre quando o retorno do processo confirma a mudança esperada — por exemplo, estado do equipamento, entrada auxiliar, indicação de posição e, quando aplicável, evento com timestamp. Em lógica crítica, o relatório deve correlacionar command request, response e feedback.

Intertravamentos, local/remote e autoridade: o protocolo não substitui a lógica

Uma outstation pode rejeitar controle porque está em modo local, porque a saída está bloqueada, porque existe intertravamento ou porque outra condição interna impede a operação. Esses mecanismos são parte da segurança operacional do sistema. Não devem ser desabilitados apenas para obter um “SUCCESS” no protocolo.

A matriz de causa e efeito precisa dizer quais condições permitem abrir, fechar, resetar ou bloquear. O comissionamento deve incluir casos negativos: tentar o comando quando um permissivo propositalmente não está atendido e confirmar que a recusa ocorre como esperado. Provar que o sistema impede uma ação indevida é tão importante quanto provar que executa uma ação válida.

SBO não é mecanismo de cibersegurança

Select Before Operate reduz alguns riscos operacionais de execução acidental ou transação inconsistente, mas não autentica identidade humana nem protege sozinho contra um agente com acesso indevido ao canal. Segurança de DNP3 deve considerar arquitetura de rede, controle de acesso, logging e os mecanismos de segurança definidos para o ecossistema DNP3 conforme a edição/perfil aplicável.

Em projeto real, a política de firewall deve limitar origens e destinos, o front-end deve controlar privilégios de operação e o sistema deve manter rastreabilidade de quem solicitou a manobra. Quando mecanismos de autenticação DNP3 estiverem implementados, confirme interoperabilidade e gestão de chaves/credenciais segundo a documentação normativa e do fabricante.

Roteiro seguro de comissionamento de controles

Faça o primeiro ensaio em bancada ou com a saída desacoplada do processo quando possível. Registre configuração, índice, modelo de controle, código, temporizações e estado inicial. Execute SELECT/OPERATE ou Direct Operate conforme a engenharia e salve request/response. Depois valide feedback lógico. Só avance para equipamento primário energizado dentro de procedimento operacional autorizado.

Teste também condições de falha: SELECT sem OPERATE, OPERATE após expiração, índice inválido em bancada, modo local e perda de comunicação entre seleção e operação. O objetivo é conhecer o comportamento seguro, não descobrir limites em produção.