Cause of Transmission no IEC 104: origem, confirmação e diagnóstico da ASDU
Interprete o COT do IEC 104 em mensagens periódicas, espontâneas, interrogadas, ativações e respostas negativas, preservando test, PN e originator.
COT e interpretação operacional
| Grupo | Significado | Cuidado |
|---|---|---|
| Periodic/background | aquisição cíclica | não confundir com evento |
| Spontaneous | mudança não solicitada | preservar tempo/qualidade |
| Interrogated | resposta à GI | pode repetir estado |
| Activation | início de função | aguardar confirmação |
| Negative/test | rejeição ou ensaio | não tratar como processo normal |
COT só é interpretado corretamente junto com Type ID, direção e objeto.
COT explica por que a ASDU existe
Cause of Transmission não é endereço nem tipo do ponto. Ele informa o contexto: periódico, background, espontâneo, resposta a interrogação, ativação, confirmação, término e outras causas definidas. O mesmo Type ID e IOA podem aparecer com COT diferentes. Ignorar esse campo faz o SCADA tratar teste como operação, evento como valor cíclico ou negativa como timeout. A engenharia precisa definir causas esperadas por direção e função.
O campo inclui qualificadores relevantes
Além do valor da causa, a codificação contempla indicadores como test e positive/negative, conforme formato, e pode incluir endereço do originador conforme parâmetros do perfil. O tamanho precisa coincidir nas pontas. Um parser deslocado pode exibir COT plausível e Common Address incorreto. Valide a ASDU desde Type ID, VSQ e COT antes de interpretar CA e IOA, preservando bits qualificadores na captura e nos logs.
Aquisição usa causas que revelam o mecanismo
Medição periódica informa envio cíclico; background pode refletir varredura; spontaneous registra mudança não solicitada; interrogated by station associa dados a uma GI. Essas diferenças ajudam a entender latência e duplicidade aparente. Um ponto pode chegar espontaneamente e reaparecer na GI sem ser evento duplicado. O historiador deve decidir como armazenar cada fluxo, usando timestamp e qualidade, sem apagar a causa necessária ao diagnóstico.
Comando forma uma transação por causas
Activation inicia, Activation Confirmation comunica aceitação ou rejeição e Activation Termination encerra quando previsto. Cada etapa deve manter CA, IOA, Type ID e valor coerentes. Confirmação positiva não prova atuação física. Negativa precisa chegar à interface com motivo contextual, e silêncio não deve ser interpretado como negativa. Capture todas as ASDUs e o retorno de posição para fechar a cadeia.
PN distingue confirmação negativa
O indicador negativo informa que a causa está sendo respondida de forma não positiva, associado ao serviço e ao objeto. A implementação pode complementar com causas e informações específicas. Não descarte a ASDU negativa como erro genérico: ela demonstra que sessão e parser funcionaram até a aplicação. Compare solicitação, capabilities e logs do servidor. A correção pode ser CA, IOA, Type ID, estado, permissão ou função, não timeout TCP.
Test precisa ficar segregado
Mensagens marcadas para teste permitem validar caminhos sem serem confundidas com processo real, quando suportadas. O receptor deve tratar conforme política e nunca alimentar decisão operacional como dado normal. Ambientes de ensaio e produção precisam distinguir origem. Verifique se gateways preservam o bit e se SCADA apresenta indicação clara. Remover a marca em uma conversão cria risco de falso evento ou comando tratado como real.
Originator ajuda em arquiteturas com clientes
Quando utilizado, o originator address identifica origem lógica de uma ativação e auxilia rastreabilidade, mas não substitui autenticação do usuário ou log do SCADA. Em sistemas redundantes, documente valores e comportamento no failover. Se o servidor devolve originator diferente ou zero, confirme o perfil acordado. A auditoria completa liga usuário, estação de operação, sessão, OA, ASDU e efeito no processo.
Teste cobre matriz de causas
Para cada tipo importante, provoque periódico, espontâneo, GI, ativação positiva e negativa, término e teste quando aplicável. Registre COT, qualificadores, tempo e reação do SCADA. Envie combinação não suportada em bancada para observar rejeição. Após reconexão, diferencie dados de recomposição de novos eventos. O aceite entrega uma matriz COT × função × direção, reduzindo interpretações improvisadas durante falhas.
Critério de engenharia e governança
Na integração, crie uma matriz de causas aceitas por Type ID e direção. Um servidor não deve aceitar comando com COT impróprio, e o cliente não deve incorporar mensagem test ou negativa como atualização normal. Gateways precisam mapear causas entre protocolos sem inventar equivalência inexistente; quando não houver correspondência, preserve informação em qualidade ou log e documente a perda semântica. Para eventos, compare COT, timestamp e receive time. Para GI, acompanhe activation, confirmation, dados interrogados e termination, contabilizando objetos. Em redundância, confirme como originator e test são mantidos na troca de mestre. Alarmes devem distinguir causa inesperada de objeto desconhecido. Uma auditoria mensal pode procurar COTs raros ou combinações novas, úteis para detectar mudança de firmware ou configuração. O critério de aceite não é apenas o Wireshark reconhecer o número: cada causa precisa provocar o tratamento correto no SCADA, no histórico e na operação, inclusive quando a resposta é negativa ou chega fora da sequência funcional prevista.
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.
- IEC 60870-5-104:2006+AMD1:2016 CSV — Network access for IEC 60870-5-101 — IEC. Companion standard consolidado do IEC 104; inclui o corrigendum publicado em 2023.
- IEC 60870-5-101:2003+AMD1:2015 CSV — Basic telecontrol tasks — IEC. Companion standard consolidado do IEC 101 para telecontrole serial.
- IEC 60870-5-1:1990 — Transmission frame formats — IEC. Formatos de quadro e requisitos de integridade usados pela família IEC 60870-5.
- IEC 60870-5-2:1992 — Link transmission procedures — IEC. Procedimentos de transmissão da camada de enlace, especialmente pertinentes ao IEC 101.
- IEC 60870-5-3:1992 — General structure of application data — IEC. Regras para estruturar unidades de dados de aplicação.
- IEC 60870-5-5:1995 — Basic application functions — IEC. Funções básicas de aplicação, incluindo aquisição, comandos e sincronização.
- IEC 60870-5-6:2006 — Guidelines for conformance testing — IEC. Método para ensaios de conformidade dos companion standards IEC 60870-5.
- IEC TS 60870-5-601:2015 — Conformance test cases for IEC 101 — IEC. Casos de ensaio de conformidade para implementações IEC 101.
- IEC TS 60870-5-604:2016 — Conformance test cases for IEC 104 — IEC. Casos de ensaio positivos e negativos para implementações IEC 104.
- IEC TS 60870-5-7:2025 — Security extensions for IEC 101/104 — IEC. Extensões de segurança alinhadas à série IEC 62351 para autenticação, integridade e RBAC.
- Wireshark User’s Guide — Wireshark Foundation. Documentação oficial de captura, filtros, estatísticas e interpretação da interface do analisador.
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.