Classes DNP3: Class 0, 1, 2 e 3 sem confusão

A primeira correção conceitual: Class 0 não é “a classe mais importante”

No DNP3, Class 0 e Classes 1, 2 e 3 têm papéis diferentes. Class 0 é usada para obter a visão estática configurada da outstation, normalmente em uma leitura de integridade. Classes 1, 2 e 3 são classes de eventos. Isso significa que comparar “prioridade da Class 0” com “prioridade da Class 1” como se fossem quatro filas equivalentes leva a uma configuração errada.

A leitura de Class 0 responde à pergunta “qual é o estado atual?”. A coleta de Classes 1/2/3 responde à pergunta “quais mudanças registradas ainda precisam ser entregues?”. Em uma ocorrência, essas duas respostas podem ser diferentes. Se uma entrada abriu e fechou durante uma interrupção, o estado atual pode ser fechado, enquanto os eventos preservam as duas transições.

Classes 1, 2 e 3: prioridade é uma decisão de engenharia

A norma permite organizar eventos em três classes. O significado operacional de cada classe deve ser definido pelo projeto. Uma prática comum é colocar eventos mais críticos ou que exigem menor latência em uma classe consultada com maior frequência, mas não existe uma regra universal que obrigue todo sistema a usar Class 1 para um mesmo tipo de ponto. O master e a outstation precisam concordar com a estratégia.

O critério deve considerar criticidade do processo, taxa de geração de eventos, capacidade de buffer, largura de banda, latência do canal e frequência de polling. Em um enlace satelital, por exemplo, uma estratégia agressiva de polling pode aumentar custo e carga sem melhorar o que realmente importa. Em um enlace de baixa latência, uma coleta frequente pode ser viável. O desenho precisa ser medido, não copiado.

Group 60 e a seleção de classes

DNP3 usa Class Data para solicitar classes. O Group 60 é a família associada a Class 0 e às Classes 1, 2 e 3. A requisição de uma classe não significa que todos os pontos da outstation pertencem automaticamente a ela. A outstation mantém associações configuradas entre pontos/eventos e classes, e o master pede os dados de acordo com sua política.

No comissionamento, não valide apenas se “Class 1 responde”. Gere um evento em um ponto que a engenharia declara como Class 1, confirme que ele aparece na coleta correta e depois repita com pontos de Class 2 e Class 3. Isso prova tanto o mapeamento quanto a estratégia do master.

Polling por classe e integridade: por que ambos existem

Um master pode fazer integrity polls em intervalos definidos e, entre eles, coletar eventos por classe. A integridade reconstrói a imagem estática e é importante após inicialização, restart, perda prolongada ou condições em que a base precisa ser reconciliada. As classes de evento preservam mudanças sem obrigar a transmitir todo o banco a cada ciclo.

Se o projeto usa apenas integridade frequente, pode consumir banda desnecessariamente e perder a riqueza temporal de eventos. Se usa apenas eventos e nunca reconcilia estado, uma perda de buffer ou reinicialização pode deixar a imagem do master incoerente. A política correta combina mecanismos conforme o risco operacional.

Classes e unsolicited: a mesma organização, outro modo de entrega

Quando Unsolicited Response é habilitado, a outstation pode enviar eventos das classes configuradas sem esperar pelo poll correspondente. As classes continuam importantes: elas ajudam a selecionar quais eventos podem ser enviados e a organizar a política de entrega. O master precisa confirmar quando exigido e tratar reconexão, retries e eventos acumulados.

Unsolicited não deve ser tratado como “polling automático”. Ele muda quem inicia a entrega e exige mais atenção à recuperação. Se a sessão cai enquanto eventos são gerados, o buffer da outstation e a política pós-reconexão determinam se o histórico será preservado.

Parâmetros que precisam ser documentados para cada classe

A tabela de engenharia deve tornar explícita a estratégia de classes. Sem isso, o master pode estar corretamente configurado para coletar Class 1 enquanto pontos críticos foram cadastrados como Class 2 na outstation. O resultado parece uma falha intermitente, mas é apenas uma inconsistência de engenharia.

• Associação ponto→classe — O que é: define em qual classe o evento daquele ponto entra. Efeito: determina por qual consulta/unsolicited ele será entregue. Validar: gerar evento conhecido e observar a classe retornada.
• Intervalo de poll — O que é: periodicidade de coleta de cada classe. Efeito: afeta latência, banda e crescimento do buffer. Validar: timestamps das requisições, resposta e ocupação do buffer.
• Integrity interval — O que é: periodicidade ou condição para Class 0. Efeito: reconcilia estado estático. Validar: captura, logs e comparação da base antes/depois.
• Unsolicited por classe — O que é: autorização para envio espontâneo de eventos de determinadas classes. Efeito: reduz latência, mas exige confirmação/retry. Validar: enable, evento de teste, resposta e confirm.
• Buffer por classe/tipo — O que é: capacidade de retenção de eventos. Efeito: limita quanto histórico sobrevive à indisponibilidade. Validar: Device Profile, teste controlado e alarmes/IIN de overflow.

Teste de campo: prove a classificação e a recuperação

Monte um caso de teste com pelo menos um ponto de cada classe usada. Registre estado inicial, provoque mudanças em horários conhecidos e acompanhe a captura. Confirme que cada evento chega pela classe prevista, com índice, valor, qualidade e timestamp coerentes. Depois interrompa a comunicação por um intervalo controlado e produza alguns eventos adicionais.

No retorno, observe se o master coleta os eventos acumulados antes ou depois da integridade, se há overflow e se a sequência do processo pode ser reconstruída. O resultado esperado precisa estar escrito antes do teste. Essa disciplina transforma “parece que recuperou” em evidência de interoperabilidade.