Eventos no IEC 101: classes, ACD, ordem temporal e recuperação de backlog
Organize eventos IEC 101 por classes, prioridade e timestamps, usando ACD, polling, espontâneo quando aplicável, buffers e recuperação após indisponibilidade.
Engenharia de eventos IEC 101
| Elemento | Definição | Teste |
|---|---|---|
| Tipo | com/sem tempo e representação | decodificar ASDU |
| Classe | prioridade de coleta | medir latência |
| ACD | demanda de dados prioritários | observar drenagem |
| Buffer | capacidade e overflow | falha prolongada |
| Recuperação | ordem de GI e eventos | backlog controlado |
Estado final correto não comprova que todas as transições foram preservadas.
Evento registra mudança, não apenas estado atual
Uma indicação estática informa a condição presente; evento preserva uma transição, normalmente com causa, qualidade e, quando configurado, tempo. Após falha de comunicação, o valor atual pode estar correto enquanto mudanças intermediárias foram perdidas. Por isso o aceite deve comprovar sequência e não somente atualização final. Defina quais pontos geram eventos, com que tipo IEC 101, prioridade, timestamp e comportamento quando a fila enche.
Classes organizam prioridade do enlace
No procedimento não balanceado, dados de maior e menor prioridade podem ser tratados como classes conforme o perfil. A primária precisa consultar ambas em frequência compatível. Uma configuração que coleta apenas a classe prioritária pode deixar dados comuns acumulados; polling excessivo de classe menos crítica pode atrasar ocorrências urgentes. Relacione cada ponto à classe, estime taxa e dimensione o ciclo pelo pior caso, não pelo silêncio normal.
ACD indica demanda de acesso
A secundária pode usar ACD na resposta para sinalizar dados de maior prioridade aguardando coleta. A primária deve interpretar e agir conforme procedimento implementado. ACD permanente sugere classe não drenada, backlog, função não suportada ou erro de estado. Capture a sequência desde a indicação até as solicitações seguintes. O bit não diz sozinho quantos eventos existem; combine com volume recebido, estado da fila e logs do equipamento.
Timestamp precisa ter origem conhecida
Eventos podem carregar CP24Time2a ou CP56Time2a conforme Type ID e perfil. O tempo deve representar a ocorrência na origem, não a chegada ao SCADA, quando o equipamento oferece SOE. Documente fonte de relógio, resolução, fuso tratado pela aplicação e qualidade. Compare evento injetado em horário conhecido com relógio da RTU. Uma sequência ordenada por recepção pode ficar errada durante backlog ou caminhos com latências diferentes.
Buffer é dimensionado pela indisponibilidade
Capacidade necessária deriva da taxa máxima plausível de eventos multiplicada pelo tempo de falha que se deseja suportar, com margem. Chatter de entrada e analógicos instáveis podem consumir fila rapidamente. Quando há overflow, o sistema deve sinalizar perda; jamais apresentar o SOE como completo. Revise condicionamento, deadband, classes, polling e capacidade. Aumentar memória sem eliminar a fonte de tempestade apenas adia o problema.
Espontâneo e polling dependem do modo
Algumas arquiteturas e perfis permitem transmissão iniciada pela estação em condições compatíveis; outras dependem do ciclo de consultas. O comportamento deve ser explicitamente acordado, especialmente em enlaces multiponto e rádio. Não assuma que “evento” significa envio instantâneo. Meça latência desde a mudança física até recepção sob carga. Se o requisito exige tempo menor que o ciclo, reavalie modo, prioridade ou tecnologia do canal.
Retorno do canal é situação de pico
Na reconexão, várias RTUs podem ter filas e a primária pode iniciar GI, sincronismo e polling ao mesmo tempo. Planeje ordem: preservar eventos, recompor estado e evitar saturação. Verifique duplicatas e limites de buffer. Um gateway deve manter qualidade de comunicação durante recuperação. O tempo até normalização faz parte do SLA operacional; ficar conectado não basta se eventos críticos levam minutos para chegar ou perdem ordem.
Teste usa mudanças controladas e contagem
Gere sequência conhecida de aberturas, fechamentos e valores, incluindo duas mudanças rápidas. Interrompa o canal, produza eventos e recupere. Compare quantidade, ordem, timestamps, classes e qualidade entre IED, captura e SCADA. Depois exceda limite em bancada para confirmar alarme de overflow. O relatório declara lacunas e critérios. Assim a equipe prova a cadeia de SOE e conhece exatamente quando a história deixa de ser completa.
Critério de engenharia e governança
A classificação de eventos deve partir de consequência operacional. Mudança de disjuntor, alarme de proteção e falha de fonte não recebem prioridade apenas porque são digitais; cada ponto precisa de justificativa, tempo máximo e política de retenção. Eventos analógicos podem ser críticos quando indicam limite, mas também gerar grande volume. Use testes de taxa para validar capacidade por classe e não concentre todos os pontos em uma única prioridade. No SCADA, preserve a distinção entre evento recebido, estado recomposto por GI e valor substituído. A tela pode mostrar o estado atual, enquanto a lista de eventos indica lacuna ou overflow. Para análises pós-falha, guarde horário de origem, recepção, CA, IOA, tipo, COT e qualidade. Em redundância, verifique se o standby recebe ou recupera a mesma fila e como duplicatas são identificadas. O aceite deve estabelecer uma fronteira explícita: até qual duração e taxa de indisponibilidade o sistema garante história completa, e como informa o operador quando essa garantia foi ultrapassada.
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.
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.