MMS na IEC 61850: cliente-servidor, reports, controles e mapeamento da IEC 61850-8-1

MMS é parte importante, mas IEC 61850 é maior que MMS

IEC 61850 define modelos de dados e serviços abstratos antes de definir como eles são transportados. A IEC 61850-8-1 mapeia muitos serviços ACSI para MMS, Manufacturing Message Specification, e para a pilha de comunicação sobre Ethernet/TCP. Esse mapeamento viabiliza comunicação cliente-servidor para supervisão, leitura de dados, reports, controles e outros serviços.

GOOSE e SV não são simplesmente 'tipos de MMS'. GOOSE possui mapeamento próprio em Ethernet e SV é definido na IEC 61850-9-2. Assim, um IED pode ter sessão MMS com um SCADA e ao mesmo tempo publicar GOOSE para proteção local. Separar esses caminhos é fundamental para troubleshooting: perda da sessão MMS não implica automaticamente perda de GOOSE.

• MMS: serviços cliente-servidor.
• GOOSE: multicast orientado a eventos.
• SV: multicast de amostras.
• Todos compartilham o modelo IEC 61850, mas não o mesmo transporte.

Modelo de objetos e nomes

Em vez de uma tabela plana de endereços numéricos, IEC 61850 organiza dados em Logical Devices, Logical Nodes, Data Objects e Data Attributes. MMS fornece mecanismos para representar e acessar essa estrutura mapeada. Nomes como LLN0, XCBR, MMXU e atributos de qualidade/tempo carregam semântica que ajuda integração e engenharia.

Essa riqueza também cria dependência de consistência. Se o SCADA espera um objeto que mudou após atualização de modelo ou SCL, a sessão MMS pode estar saudável e ainda assim uma variável específica não funcionar. O diagnóstico deve comparar o browse/modelo visto pelo cliente com o arquivo SCL e a configuração do IED.

• Nome do objeto carrega significado funcional.
• Qualidade e timestamp fazem parte do dado.
• Sessão TCP ativa não prova mapeamento correto.

Reports, datasets e RCBs

Reports permitem que o servidor envie mudanças ao cliente sem polling contínuo de cada atributo. Um Report Control Block referencia um dataset e possui condições de disparo, integridade e outros parâmetros. Buffered Reports preservam informações para entrega posterior conforme regras do serviço; Unbuffered Reports são voltados ao fluxo enquanto a associação está ativa.

Configurar reports exige entender dataset, trigger options, integrity period, buffer e ownership. Dois clientes competindo por um BRCB ou parâmetros não persistidos podem produzir sintomas intermitentes. Em comissionamento, force mudanças de dados, desconecte o cliente quando aplicável e confirme comportamento de reconexão. Verifique EntryID e sequência quando a implementação expõe esses mecanismos.

• Dataset define quais dados entram no report.
• BRCB e URCB têm comportamentos distintos.
• Teste reconexão e recuperação, não apenas operação contínua.

Controles e segurança operacional

Controles IEC 61850 podem usar modelos como direct-with-normal-security ou select-before-operate e variantes com enhanced security conforme modelagem e implementação. MMS carrega os serviços cliente-servidor associados ao controle. A ação final ainda depende de intertravamentos, permissivos e lógica do IED. Um comando protocolarmente aceito pode não resultar em mudança de equipamento se a condição de processo impedir.

Registre quem é o originador do comando, timestamps, AddCause e feedback. Para cibersegurança, IEC 62351-6 trata proteção de protocolos derivados da IEC 61850, enquanto arquitetura de rede, certificados e controle de acesso precisam ser projetados de ponta a ponta. Segurança não deve ser reduzida a 'MMS usa TCP'.

• Teste seleção, operação, cancelamento e timeout quando aplicável.
• Correlacione resposta de comando com mudança de estado.
• Proteção do protocolo e autorização de usuário são camadas diferentes.

Wireshark e diagnóstico

Em captura, comece pela sessão TCP e estabelecimento da associação. Depois filtre MMS e siga requests/responses, reports e erros. Se o tráfego estiver em porta ou contexto inesperado, Decode As pode ajudar, mas deve ser usado com conhecimento do fluxo. Compare a ordem temporal com logs do cliente e servidor.

Para problemas de report, confirme se o cliente configurou o RCB e se o IED enviou notificações. Para objeto ausente, compare o modelo disponível com SCL. Para comando, siga toda a transação e retorno de estado. O objetivo é localizar a primeira camada em que o comportamento diverge: transporte, associação, modelo, report, controle ou processo elétrico.

• Comece por TCP/associação antes do objeto.
• Use browse/modelo e SCL como referências.
• Preserve PCAP e log do cliente na mesma janela temporal.

Associação, reconexão e disponibilidade

Uma sessão MMS pode cair por perda TCP, reset do IED, timeout, mudança de rede ou política de segurança. O cliente deve reconectar e restaurar configuração necessária, como habilitação de reports, conforme serviço e implementação. Um teste que só verifica comunicação após boot não cobre comportamento após uma queda de switch ou reinício do servidor.

Em alta disponibilidade, verifique múltiplos clientes e limites de associação do IED. Alguns equipamentos suportam número finito de conexões e RCBs. Uma ferramenta de engenharia deixada conectada pode competir com o SCADA. Documente limites e separe sessões permanentes de acesso de manutenção.

• Teste reconexão automática.
• Conheça limite de clientes do IED.
• Evite ferramentas de engenharia ocupando recursos críticos.

Reports e tempestades de dados

Durante recuperação de comunicação, reports buffered podem gerar grande volume em curto intervalo. O cliente precisa processar backlog sem perder dados ou atrasar excessivamente o estado atual. Observe CPU, banda e filas em cenários com muitos IEDs reconectando simultaneamente após falha de switch ou energia.

Uma arquitetura pode funcionar bem com um IED de bancada e falhar em recomposição massiva. Testes de escala, ou pelo menos estimativa de volume, devem fazer parte da engenharia de station bus.

Ao documentar o station bus, relacione cada cliente MMS aos IEDs que acessa, serviços utilizados, reports habilitados e dependências de rede. Essa matriz facilita avaliar impacto de firewall, manutenção de servidor e mudanças de firmware, além de revelar conexões de engenharia que não deveriam permanecer permanentes.

Inclua ainda limites de associação, políticas de timeout e responsabilidade por reconfigurar RCBs após reconexão; esses detalhes evitam falhas silenciosas quando o cliente volta ao serviço.

• Simule reconexão de múltiplos IEDs quando possível.
• Meça backlog e tempo de normalização.
• Dimensione servidores e rede para contingência.