IIN bits no DNP3: como ler o estado interno da outstation e diagnosticar falhas

IIN é o painel de instrumentos interno da resposta DNP3

Internal Indications, ou IIN, são bits que a outstation inclui em respostas para informar condições internas relevantes. Eles não substituem logs do equipamento, mas são pistas padronizadas que o master pode usar para decidir ações. Entre as situações mais úteis estão restart, necessidade de sincronismo, disponibilidade de eventos por classe, local mode, device trouble, event buffer overflow e indicações de função ou objeto não suportado.

Quem está começando deve aprender a ler IIN junto com a solicitação que provocou a resposta. Um bit isolado não conta toda a história. Um profissional experiente ganha valor quando correlaciona mudança do IIN com sequência, horário, buffer, logs, firmware e comportamento de failover.

Restart, Need Time e classes de evento

Quando Restart aparece, a primeira pergunta é quando e por que a outstation reiniciou. Depois valide se o master refez integridade e demais inicializações. Need Time indica que a outstation necessita sincronização temporal; em sistemas com SOE, ignorar isso pode produzir eventos cronologicamente incoerentes mesmo quando os valores estão corretos.

Indicações de Class 1, 2 ou 3 mostram que existem eventos aguardando coleta. Se o master usa unsolicited, essas flags ajudam a entender se houve evento pendente não entregue. Se usa polling, ajudam a explicar por que a fila continua crescendo. O significado de prioridade das classes é definido pela engenharia do projeto, não pelo número sozinho.

Overflow, trouble, local e não suportado

Event buffer overflow é uma evidência crítica: significa que a fila não conseguiu preservar todos os eventos. O valor estático final pode estar correto e ainda assim o SOE ter perdido mudanças. A resposta correta não é só “aumentar o buffer”: revise deadband, taxa de mudança, classes, intervalo de poll, unsolicited, indisponibilidade máxima e dimensionamento da memória.

Local mode ou device trouble precisam ser interpretados com o estado real do equipamento. Function Not Supported e Object Unknown apontam para incompatibilidade de capacidade, perfil ou requisição. Nesse caso, aumentar timeout é irrelevante: a própria outstation está dizendo que a aplicação não aceita o que foi solicitado.

Fluxo de diagnóstico recomendado

Salve a captura e a resposta que contém o IIN. Identifique qual request veio antes, compare endereço, Function Code, objetos e sequência, depois correlacione com logs do master e da outstation. Se o bit é transitório, preserve o primeiro momento em que apareceu; reiniciar pode limpá-lo.

Monte no comissionamento uma tabela “IIN → ação do master → evidência esperada”. Restart pode disparar integridade; Need Time pode disparar sincronismo; eventos pendentes devem gerar coleta; overflow deve gerar alarme e investigação. Isso transforma IIN de detalhe de protocolo em mecanismo operacional.

Do bit à ação: como transformar IIN em lógica operacional

O valor prático do IIN aparece quando cada indicação possui uma resposta planejada. Restart não deveria gerar apenas um alarme genérico: o master precisa decidir se executará integrity poll, coleta das classes, sincronismo e reabilitação de funções. Need Time pede verificação da fonte temporal e da política de sincronização. Class 1/2/3 Events indica eventos pendentes e deve ser correlacionado com a estratégia de polling ou unsolicited. Event Buffer Overflow precisa elevar a severidade porque a outstation já informa que a sequência histórica pode estar incompleta.

Para implementar isso sem criar automações perigosas, monte uma matriz por modelo e firmware: IIN observado, significado segundo o Device Profile, ação automática permitida, ação que exige operador e evidência de encerramento. Nem todo bit deve disparar comando. Device Trouble ou Local podem refletir estados operacionais que precisam de intervenção humana; Function Not Supported ou Object Unknown pedem revisão da requisição. O teste de aceitação deve provocar, quando possível em bancada, estados controlados e confirmar que o master registra a indicação sem escondê-la atrás de um simples “canal online”.

• Restart: correlacionar com uptime/log e provar a sequência de recuperação.
• Need Time: verificar offset e sucesso do método de sincronização utilizado.
• Class 1/2/3: confirmar que os eventos são coletados e que a indicação desaparece conforme a implementação.
• Overflow: registrar perda potencial de SOE e investigar dimensionamento, deadband, indisponibilidade e taxa de eventos.
• Function/Object not supported: comparar a requisição com capacidades declaradas no Device Profile.

Diagnóstico por IIN: exemplos de decisão sem reiniciar o equipamento

Quando um canal está online mas os dados parecem incompletos, leia o IIN antes de aumentar timeout ou reiniciar a outstation. Class Events presente junto com ausência de eventos no SCADA direciona a investigação para coleta, confirmação ou sessão do master. Event Buffer Overflow muda a interpretação: o valor estático atual pode estar correto e ainda assim a cronologia anterior já ter sido perdida. Need Time com SOE fora de ordem pede correlação com o relógio do equipamento; Device Trouble exige consultar os diagnósticos locais antes de responsabilizar a rede. A utilidade do IIN está justamente em reduzir o espaço de hipóteses.

Também é importante distinguir indicações persistentes de indicações transitórias. Uma captura deve mostrar em quais respostas o bit apareceu, o que o master fez em seguida e em que condição ele deixou de ser reportado. Em redundância, compare o comportamento dos dois masters: um servidor pode limpar ou tratar a condição enquanto o outro continua exibindo alarme por cache, polling diferente ou sessão independente. Esse nível de rastreabilidade transforma IIN em ferramenta de manutenção, em vez de um campo hexadecimal que só é observado quando o fabricante solicita uma captura.