DNP3 vs GOOSE: por que não são substitutos e onde cada um deve ser usado
Entenda por que DNP3 e IEC 61850 GOOSE resolvem problemas diferentes: supervisão, telecontrole, eventos, proteção peer-to-peer, latência e dependência de rede.
Checklist de frame DNP3 para este recorte
| Campo | Pergunta objetiva | Falha que ajuda a separar |
|---|---|---|
| Source / Destination | Os endereços DNP são os esperados nas duas direções? | Endereço trocado, broadcast indevido, resposta de outro equipamento. |
| Application Sequence | A sequência avança e corresponde à transação? | Resposta antiga, duplicação ou perda de estado. |
| Function Code | A ação enviada é a suportada para o objeto? | Function Code Not Supported. |
| Group / Variation / Qualifier | Formato e range são suportados? | Object Unknown / Parameter Error. |
| IIN | A resposta carrega condição que exige ação do master? | Restart, Need Time, classe pendente, overflow. |
A comparação começa pelo problema que cada um resolve
DNP3 foi desenhado para telecontrole entre mestre e outstations, com leitura de estados e analógicos, filas de eventos, comandos, qualidade e recuperação após falha de comunicação. GOOSE faz parte do ecossistema IEC 61850 e foi concebido para distribuição rápida de eventos entre publicadores e assinantes em uma LAN, normalmente em aplicações de proteção, intertravamento e automação de subestação. Portanto, perguntar qual é 'melhor' sem definir a função leva a uma comparação falsa.
Um religador remoto reportando carga e eventos para o centro de operação é um cenário natural para DNP3. Um IED de proteção publicando pickup, trip, bloqueio ou permissivo para outros IEDs na mesma subestação é um cenário natural para GOOSE. É possível existir DNP3 e GOOSE no mesmo equipamento e na mesma instalação porque eles atuam em caminhos funcionais diferentes.
- DNP3: supervisão e telecontrole mestre-remoto.
- GOOSE: evento multicast peer-to-peer em LAN IEC 61850.
- A escolha deve partir da função elétrica e do caminho da informação.
Arquitetura e modelo de comunicação
DNP3 é orientado à relação mestre/outstation, mesmo quando há arquiteturas mais complexas com múltiplos mestres e gateways. O mestre consulta ou recebe eventos do remoto e executa comandos. A semântica usa grupos, variações, índices, classes e funções. O desenho precisa considerar polling, unsolicited, buffers e reconexão. A comunicação atravessa frequentemente WANs, rádios, fibra, LTE ou redes roteadas.
GOOSE usa Ethernet multicast em camada 2 no mapeamento clássico IEC 61850-8-1. Um publicador envia um conjunto de dados e qualquer assinante configurado para aquele fluxo pode consumir a mensagem. Não há sessão TCP e não há consulta periódica para cada assinante. A confiabilidade temporal é obtida por retransmissões rápidas após mudança de estado e retransmissões espaçadas em estado estável, acompanhadas por campos como stNum, sqNum e TimeAllowedToLive.
- GOOSE exige engenharia de multicast, VLAN/PCP e assinatura correta.
- DNP3 exige engenharia de endereçamento, sessão e política de eventos.
- WAN e LAN de proteção têm requisitos de disponibilidade diferentes.
Latência e comportamento em falha
GOOSE é usado onde a latência deve ser previsível e muito baixa. O caminho normalmente permanece dentro da subestação e deve ser projetado com switches, redundância e prioridade compatíveis com a função. Uma perda breve pode ser compensada pelas retransmissões, mas congestionamento, loop ou erro de VLAN pode afetar vários assinantes ao mesmo tempo. Por isso, testes de failover e tempestades de multicast são importantes.
DNP3 tolera latências muito maiores porque o objetivo não é substituir contato de trip peer-to-peer. Ele lida bem com enlaces de telecomunicações mais lentos e intermitentes, desde que timers, retries e buffers sejam dimensionados. A preocupação central é preservar eventos, evitar polls excessivos e garantir comandos seguros. Tentar usar DNP3 para uma função de proteção que depende de milissegundos muda completamente o risco do sistema.
- Teste GOOSE sob failover de rede e carga de multicast.
- Teste DNP3 sob perda de WAN e recuperação de eventos.
- Não transforme requisito de proteção em requisito de telecontrole.
Diagnóstico em captura
Em DNP3, uma captura mostra endereços de enlace, códigos de função, objetos, variações, índices, qualifiers, IINs e confirmações. Em TCP, é possível correlacionar sessão e retransmissões do transporte com o comportamento da aplicação. Perguntas úteis incluem: o mestre solicitou a classe correta? o outstation tinha eventos? houve overflow? a resposta carregava o índice esperado?
Em GOOSE, o foco muda para endereço MAC multicast, VLAN, PCP, APPID, GoCBRef, DatSet, ConfRev, stNum, sqNum, Test, Simulation e tempo entre retransmissões. Se o assinante não atua, valide se o quadro chega à porta, se o Control Block e dataset correspondem ao arquivo SCL e se a revisão de configuração está coerente. A existência do frame na rede não prova que o assinante o aceitou.
- DNP3: seguir requisição e resposta por ponto/objeto.
- GOOSE: seguir publicador, dataset e sequência de estados.
- Correlacione PCAP com evento interno do IED.
Onde os dois se encontram
Em uma subestação moderna, um evento pode nascer em GOOSE e terminar reportado ao centro via DNP3. Um IED publica trip por GOOSE; outro IED ou gateway registra o evento; a RTU envia o estado e timestamp via DNP3. Cada etapa deve preservar significado, qualidade e hora. Se houver gateway, documente o mapping para que o evento de proteção não seja reduzido a um bit sem contexto.
A arquitetura correta usa cada tecnologia na função em que ela é forte. GOOSE atende a troca rápida local entre IEDs; DNP3 atende supervisão e controle remoto. Quando a engenharia tenta padronizar tudo em um único protocolo, normalmente transfere complexidade para gateways, timers ou lógica de aplicação. A melhor integração é aquela que deixa explícita a fronteira entre proteção, automação local e supervisão.
- Mapeie origem do evento até o ponto de SCADA.
- Mantenha timestamp e qualidade sempre que possível.
- Documente a fronteira entre LAN IEC 61850 e telecontrole WAN.
Erros de arquitetura que a comparação ajuda a evitar
Um erro é usar gateway para converter GOOSE em DNP3 e esperar manter a mesma característica temporal da proteção. O gateway precisa receber o multicast, processar a lógica, criar um evento DNP3 e atravessar uma pilha e possivelmente uma WAN. Isso pode ser totalmente aceitável para supervisão do evento, mas não para substituir o caminho de atuação original. A função de proteção deve permanecer no domínio projetado para sua latência.
O erro oposto é usar GOOSE para espalhar pelo sistema informações que deveriam ser tratadas como telemetria, sem uma estratégia clara de registro, buffer e recuperação. GOOSE informa estado atual e transições conforme sua lógica de retransmissão, mas não é uma fila de eventos histórica equivalente ao modelo de DNP3. Se a rede ou assinante estiver fora durante um intervalo, a recuperação do histórico precisa vir de outra fonte, como logs do IED, MMS reports ou telecontrole.
- Não converta caminho de trip em telecontrole sem nova análise de risco.
- Não trate GOOSE como substituto de historiador ou fila de eventos.
- Defina qual tecnologia é autoridade para cada função.
Referências técnicas e normas
As explicações do Portal são autorais. Normas e fontes oficiais são priorizadas; materiais acadêmicos e documentação pública de fabricantes complementam a implementação e não substituem a edição normativa aplicável ao projeto.
- Overview of DNP3 Protocol — DNP Users Group
- IEC 61850-8-1:2011+AMD1:2020 CSV — IEC
- DNP Users Group — Public Documents — DNP Users Group. Aplicações públicas, boletins e materiais técnicos para validar comportamento de implementações.
- DNP3 Communication Protocol Solutions — Triangle MicroWorks. Referência de implementador para recursos como events, deadbands, unsolicited, time sync, file transfer e ferramentas de teste.
- DNP3 Application Layer Function Codes — Rockwell Automation. Exemplo público de fabricante para Function Codes, incluindo COLD_RESTART, WARM_RESTART e ENABLE/DISABLE_UNSOLICITED.
- ITT600 — Integrated Testing Tool — Hitachi Energy. Exemplo de ferramenta de fabricante para explorar SCL, MMS, GOOSE, SV, simulação e diagnóstico de IEC 61850.
Continue estudando
Os próximos conteúdos foram escolhidos para formar uma sequência técnica, relacionando fundamento, configuração, diagnóstico e aplicação.