SCL na IEC 61850: ICD, IID, CID, SCD, SSD e fluxo de engenharia

SCL é a linguagem que conecta engenharia e configuração

SCL, Substation Configuration Language, é definida na IEC 61850-6 para descrever IEDs, sistema elétrico, comunicação e relações de engenharia em uma forma estruturada baseada em XML. Seu valor não é ser um arquivo legível por humanos apenas; é permitir que ferramentas de engenharia troquem informação com menos reentrada manual e mantenham consistência entre capacidades do IED, topologia, datasets, Control Blocks e assinaturas.

A edição consolidada atual da IEC 61850-6 inclui AMD1:2018 e AMD2:2024. A AMD2 adicionou melhorias ao acompanhamento de troca de arquivos, identificação de elementos, configuração de controles e clarificações; o preview da IEC destaca UUIDs para identificar elementos/arquivos, modelagem de binding de controles pela perspectiva do cliente e labels traduzidos. Projetos novos devem controlar a versão de SCL suportada pelas ferramentas.

• SCL é XML estruturado por esquema da IEC.
• Ferramentas diferentes precisam concordar em versão e extensões.
• Arquivo SCL deve ser tratado como artefato de engenharia versionado.

ICD e IID: o que o IED oferece e o que está instanciado

ICD, IED Capability Description, é normalmente fornecido pelo fabricante ou ferramenta do IED e descreve capacidades que podem ser usadas na engenharia. Ele funciona como ponto de partida para inserir o equipamento no sistema. Não representa necessariamente toda a configuração final implantada na subestação.

IID, Instantiated IED Description, é usado para trocar uma instância configurada de IED entre ferramentas no processo de engenharia. Ele permite trabalhar com configuração de um IED já contextualizada sem carregar todo o SCD. Fluxos exatos dependem da edição e ferramentas, então é importante definir governança: quem gera, quem importa, quem é autoridade e como mudanças são reconciliadas.

• ICD: capacidades oferecidas pelo IED.
• IID: descrição instanciada para troca de engenharia.
• Controle versões para evitar regressão de parâmetros.

SSD, SCD e CID

SSD, System Specification Description, pode representar a especificação funcional do sistema, incluindo estrutura de subestação e funções ainda antes da alocação completa em IEDs. SCD, Substation Configuration Description, consolida a configuração integrada do sistema: IEDs, comunicação, datasets, Control Blocks e relacionamentos necessários à engenharia.

CID, Configured IED Description, é uma visão voltada ao IED configurado, derivada da engenharia do sistema conforme fluxo adotado. Em campo, é comum existir discrepância entre SCD mestre e arquivos efetivamente carregados nos IEDs. Essa divergência é uma fonte séria de falhas: GOOSE pode chegar com ConfRev diferente, assinaturas podem não corresponder e troubleshooting fica baseado em documentação desatualizada.

• SSD: especificação do sistema.
• SCD: configuração integrada da subestação.
• CID: configuração de um IED para implantação conforme processo.

GOOSE, SV e comunicação dentro do SCL

SCL descreve redes, Access Points, endereços e parâmetros de comunicação. Para GOOSE, Control Blocks, datasets e associações de publicação/assinatura podem ser representados e usados pela ferramenta para gerar configuração coerente. Para SV, streams e parâmetros relacionados seguem processo semelhante. A engenharia deve usar SCL como fonte de verdade para MAC multicast, APPID, VLAN e prioridade quando essas informações estão sob gestão da ferramenta.

Alterar um Control Block diretamente no IED sem atualizar o sistema pode criar uma configuração órfã. O mesmo vale para IPs, VLANs e datasets. Mudanças de campo precisam voltar ao repositório de engenharia, ser reconciliadas e gerar nova baseline. Em instalações grandes, versionar SCD em Git ou sistema documental com aprovação formal oferece rastreabilidade extremamente útil.

• Compare SCL com captura de rede durante comissionamento.
• Evite alteração local sem retroalimentar engenharia.
• Use diff estruturado e revisão, não apenas data do arquivo.

Boas práticas de gestão de SCL

Defina uma autoridade para o SCD, convenção de nomes, versão de esquema, regras para private extensions e procedimento de import/export. Guarde arquivos originais de fabricante e baselines aprovadas. Antes de atualização de firmware ou ferramenta, faça teste em cópia porque um import/export pode normalizar ou remover extensões que outra ferramenta usa.

No comissionamento, valide não só se o arquivo é aceito, mas se o comportamento resultante está correto: GOOSE publicado, assinaturas, relatórios MMS, datasets e sincronismo. Depois gere um pacote as-built com SCD, arquivos por IED, firmware e relatório de testes. Isso transforma SCL de 'arquivo de configuração' em parte central da engenharia digital da subestação.

• Versione SCL junto com firmware e lógica.
• Faça backup antes de migrar ferramenta/versão.
• Gere baseline as-built após comissionamento.

Validação automática e qualidade do arquivo

Como SCL é estruturado, arquivos podem ser validados contra os esquemas correspondentes à edição. Isso detecta muitos erros de sintaxe e estrutura, mas não prova que a engenharia funcional esteja correta. Um SCD pode ser XML válido e ainda apontar um GOOSE para o dataset errado. Combine validação de esquema com regras de projeto e testes funcionais.

Ferramentas de engenharia podem inserir extensões privadas para recursos do fabricante. Ao migrar entre vendors, verifique o que é preservado. Remover um Private aparentemente irrelevante pode afetar uma função específica. Mantenha o arquivo original e compare exportações para identificar alterações automáticas.

• Validação XSD detecta estrutura, não intenção funcional.
• Controle extensões privadas.
• Compare arquivos antes/depois de importação.

SCL como documentação de troubleshooting

Durante uma falha GOOSE, abra o SCD e localize publicador, dataset, APPID, MAC, VLAN e assinantes. Depois confronte com captura. Em MMS, use SCL para confirmar modelos e reports esperados. Em SV, identifique streams e subscribers. Essa abordagem transforma o arquivo de engenharia em mapa de diagnóstico.

Para facilitar, gere relatórios legíveis a partir do SCL: matriz publisher/subscriber, endereços, datasets e Control Blocks. Esses derivados não substituem o SCD, mas ajudam equipes de campo. Versione também os relatórios para que correspondam à mesma baseline.

Em projetos com vários fabricantes, reserve uma etapa específica de interoperabilidade de engenharia. Importe e exporte arquivos entre ferramentas, valide o resultado e compare elementos críticos antes de carregar qualquer IED. O objetivo é descobrir incompatibilidades no laboratório, não durante uma janela de manutenção na subestação.

• Use SCL como referência durante captura de tráfego.
• Gere matrizes técnicas para campo.
• Mantenha baseline e derivados com o mesmo identificador de versão.