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.
DNP3 serial: como ler o quadro e a pilha
Como ler esta figura
Start 0x05 0x64
Delimita o início de um frame DNP3. É a primeira evidência de que o receptor está vendo um quadro com framing DNP3 válido.
Na implementação: Se a sequência não aparece onde deveria, verifique serial, direção TX/RX, conversor e captura antes de mexer em objetos ou polling.
Length
Define o comprimento indicado pelo frame. Tamanho incoerente ou quadro truncado costuma revelar problema abaixo da aplicação.
Na implementação: Compare o valor declarado com os bytes realmente recebidos quando houver timeouts somente em respostas maiores.
Link Control
Indica direção e função da camada de enlace. Não confunda esse campo com o Function Code da camada de aplicação.
Na implementação: Use-o para separar falha de enlace, confirmação e estado de link de uma falha de READ/OPERATE/UNSOLICITED.
Destination / Source
São endereços lógicos DNP3. Eles continuam existindo mesmo quando o transporte é TCP/IP.
Na implementação: Uma conexão TCP pode estar estabelecida e ainda assim não haver resposta de aplicação se os endereços DNP3 não coincidirem.
CRC
Protege o cabeçalho e blocos de dados contra corrupção.
Na implementação: CRC recorrente pede análise de ruído, polaridade RS-485, aterramento, baud/paridade e comportamento de conversores/radios.
User Data
Transporta fragmentos que chegam à aplicação: objetos, eventos, confirmações, comandos e informações internas.
Na implementação: Depois de provar o enlace, é aqui que Group/Variation/Qualifier, classes, IIN e Function Codes passam a dominar o diagnóstico.
GOOSE e Sampled Values: o que olhar no quadro Ethernet
Como ler esta figura
MAC destino
Normalmente multicast para distribuir o fluxo a assinantes.
Na implementação: Valide grupo multicast, filtragem no switch e se as portas dos assinantes realmente recebem o tráfego.
VLAN / PCP
802.1Q carrega VLAN ID e prioridade de usuário, permitindo segmentação e tratamento de fila.
Na implementação: PCP não cria banda; apenas ajuda o switch a decidir prioridade quando há concorrência.
EtherType
Identifica GOOSE (0x88B8) ou Sampled Values (0x88BA).
Na implementação: Essa distinção torna simples filtrar e comprovar se o fluxo certo está no enlace.
APPID
Identifica a aplicação/instância do fluxo.
Na implementação: Compare APPID com SCL e com o assinante; duplicidade ou divergência dificulta interoperabilidade e diagnóstico.
APDU
No GOOSE contém estado, sequência, dataset e metadados; em SV contém amostras e metadados do stream.
Na implementação: No GOOSE acompanhe stNum/sqNum/ConfRev; em SV acompanhe smpCnt/smpSynch/svID e continuidade.
FCS e contadores da porta
Protegem o quadro Ethernet e evidenciam defeitos físicos ou congestionamento.
Na implementação: Antes de acusar o IED, cheque CRC, drops, queue discards e erros da interface dos switches.
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
As explicações do Portal são autorais. Use as fontes oficiais e materiais públicos de implementação abaixo para confirmar edição, escopo, capacidades e comportamento do equipamento utilizado no seu 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 pelo mecanismo deste artigo. A ideia é formar uma sequência técnica, não apenas listar páginas do mesmo tema.