Class 1 no DNP3: eventos críticos, latência e recuperação

Class 1 é política de coleta, não tipo de dado

No DNP3, Classes 1, 2 e 3 organizam eventos para que o master possa coletá-los com políticas diferentes. A classe não transforma um Binary Input em outro objeto e não substitui Group, Variation, índice, flags ou timestamp. O ponto conserva sua representação; a atribuição a Class 1 apenas informa em qual conjunto de eventos a mudança será disponibilizada.

A norma não determina que toda concessionária coloque exatamente os mesmos pontos na Class 1. Tratar Class 1 como sinônimo de trip é uma convenção frequente, não regra universal. O critério nasce da consequência da demora ou perda, do volume esperado, da capacidade do canal e da estratégia do master.

Do processo ao IIN1.1: ciclo completo do evento

Quando uma mudança atende ao critério de geração — transição digital, incremento de contador ou variação analógica acima do deadband — a outstation cria um registro. Ele associa valor, flags, índice e, quando a Variation permite, timestamp. O evento permanece no buffer até ser entregue e processado conforme as confirmações aplicáveis.

A presença de eventos Class 1 pode ser indicada por IIN1.1. Esse bit é uma indicação, não contém os eventos. Ao detectá-lo, um master configurado para varredura por indicação pode agendar Group 60 Variation 2. Se o master ignora o IIN ou não possui event scan, a informação fica acumulada mesmo com o canal online.

• Geração: a outstation detecta mudança elegível.
• Enfileiramento: o registro entra no buffer da classe do ponto.
• Sinalização: IIN1.1 pode informar eventos Class 1 disponíveis.
• Entrega: polling de classe ou Unsolicited Response transporta os objetos.
• Baixa: o evento deixa de ficar pendente após intercâmbio e confirmações corretos.

Como decidir o que pertence à Class 1

Class 1 deve concentrar informações cujo atraso prejudica decisão, segurança operacional ou reconstrução de ocorrência. Abertura de religador, atuação de proteção, mudança Local/Remote e falha de alimentação auxiliar podem justificar prioridade. Em outra arquitetura, algumas delas podem ter mecanismo distinto; a lista precisa ser formalizada na matriz de pontos.

Evite colocar todo o banco na Class 1. Uma classe superdimensionada perde significado, cria rajadas após reconexão e compete com comandos e integridade. Para cada ponto registre justificativa, taxa de pico, Variation de evento, presença de tempo, retenção e teste.

Polling, unsolicited e os componentes da latência

Com polling, a latência inclui espera até a próxima varredura, fila do master, RTT e duração da resposta. Reduzir o intervalo melhora o pior caso, mas aumenta ocupação e transações vazias. O ajuste deve usar medição real, não valor copiado.

Com unsolicited, a outstation pode iniciar o envio após gerar eventos. O ganho depende de confirmação, retries, atraso de agregação e sessão. Polling de recuperação continua importante: após restart ou perda prolongada, o master precisa reconstruir estado e consumir backlog.

Dimensione o buffer para a indisponibilidade prevista

Como estimativa, use capacidade mínima maior ou igual à taxa de pico multiplicada pela indisponibilidade de projeto, mais margem para rajadas. A conta não é normativa; ela obriga a explicitar hipóteses e comparar o resultado com o Device Profile.

Overflow é grave porque o estado atual pode estar correto enquanto a sequência histórica ficou incompleta. Ao receber Event Buffer Overflow, aplique a estratégia definida, normalmente incluindo integrity scan e registro da lacuna. Preserve IIN, logs e intervalo afetado.

Teste normal, falha e recuperação

No teste normal, provoque transição autorizada e acompanhe criação na outstation, IIN1.1 ou unsolicited, objeto entregue e atualização no SCADA com flags e horário. Repita com eventos próximos para provar a ordem.

No teste de falha, interrompa o canal, gere sequência conhecida e restabeleça. Verifique backlog, confirmações, duplicidades, ordem temporal, limpeza do IIN e preservação após reconexão. Voltar a ficar online não comprova retenção.

Diagnóstico por evidência

Se Class 0 mostra o estado novo mas não há histórico, investigue classe, Variation, deadband, buffer e coleta. Se IIN1.1 permanece, confirme Group 60 Variation 2 e a resposta. Se aparecem duplicidades, compare sequência, retransmissões e timeout.

Se eventos chegam atrasados após interrupção, meça resposta, fragmentação, fila e drenagem. A primeira divergência entre outstation, PCAP, front-end e banco SCADA localiza a camada responsável.

Folha de parâmetros e responsabilidade entre master e outstation

Documente separadamente o que pertence à outstation e ao master. Na remota ficam atribuição de classe por ponto, Variation de evento, deadband, capacidade de buffer, política de unsolicited e temporizações suportadas. No master ficam intervalos de scan, reação aos bits IIN, prioridade da tarefa, timeouts, retries e tratamento de overflow. Valores com o mesmo nome podem existir nas duas pontas e ter funções diferentes.

Registre firmware, edição do Device Profile, unidade de cada tempo e comportamento após restart. Um timeout expresso em milissegundos numa ponta e segundos na outra produz diagnóstico enganoso. A configuração aprovada deve indicar responsável, origem do requisito, valor, faixa permitida, evidência de teste e condição de rollback.

Em sistemas com gateway, acrescente uma terceira coluna. Descubra se ele preserva a classe de origem, recria eventos a partir do banco interno ou altera Group/Variation. Só uma captura antes e depois do gateway prova se a Class 1 atravessou com a mesma semântica.