Na engenharia convencional IEC 61850, os erros surgem no momento pior possível: durante a comissionamento, quando o equipamento está no local, as equipes estão desdobradas e os cronogramas do projeto estão sob pressão. O processo de engenharia de cima para baixo — formalizado na TR IEC 61850-90-30:2025 e na TR IEC 61850-7-6 (Ed. 2) — antecipa esse momento significativamente: antes de qualquer IED ser selecionado, antes de um contrato ser assinado, antes de qualquer dispositivo físico existir. Quatorze TSOs europeus, incluindo a Elia e a 50Hertz, assinaram uma Declaração Comum em 2023 apoiando essa abordagem como o caminho para a engenharia de subestações digitais. O primeiro artigo desta série abordou por que a indústria está seguindo nessa direção e o que levou à consenso entre as quatorze empresas. Este artigo explica a mecânica: o que acontece em cada um dos cinco passos, quais arquivos são trocados e por que o processo produz melhores resultados do que os anteriores.

Por que a Abordagem de Baixo para Cima Falha

O processo convencional IEC 61850 começa com o IED. Você obtém um arquivo ICD de um fornecedor, constrói o sistema em torno do que o dispositivo pode fazer e comunica os requisitos por meio de documentos de especificação em PDF — que cada fornecedor lê e interpreta de forma independente. Quando os desalinhamentos surgem, o equipamento já foi adquirido, o projeto está comprometido e as correções são caras. O processo de cima para baixo inverte completamente essa sequência: os requisitos funcionais são definidos primeiro em formato legível por máquina, validados sem hardware e, somente então, entregues aos fornecedores como uma especificação estruturada que podem processar em suas próprias ferramentas.

O Processo de Cinco Etapas em Resumo

O processo consiste em cinco etapas, cada uma produzindo um arquivo estruturado que se torna a entrada para a próxima. Três categorias de ferramenta estão envolvidas: uma Ferramenta de Especificação do Sistema (SST) operada pelo engenheiro da utility, uma Ferramenta de Configuração do IED (ICT) operada pelo fornecedor do IED e uma Ferramenta de Configuração do Sistema (SCT) operada novamente pelo engenheiro da utility. Veja como elas se conectam:

flowchart LR
    A["Passo 1\nPerfilamento do Sistema\nFSD / ASD\n(SST)"] -->|"Arquivos ASD\nnamespace 6-100"| B["Passo 2\nEspecificação do Sistema\nISD / SSD\n(SST)"]
    B -->|"SSD\nto simulation"| C["Passo 3\nSimulação e\nValidação\n(Gate de Simulação)"]
    C -->|"fail:\nrevisar SSD"| B
    C -->|"pass:\nSSD validado\n+ ISD para fornecedor"| D["Passo 4\nCapacidade do IED\nprocessar ICD\n(ICT)"]
    D -->|"processar ICD + SSD"| E["Passo 5\nConfiguração do Sistema\nSCD\n(SCT)"]
    E -->|"SCD"| F["IED\nImplantação"]
    style C fill:#d4f4dd,stroke:#2d9e5a

Todos os arquivos usam formato SCL com extensões de namespace 6-100. O Passo 3 pode envolver um ciclo iterativo — a simulação está integrada ao desenvolvimento da especificação, com o engenheiro especificando, testando e refinando até que o comportamento seja confirmado. Os arquivos ISD são enviados aos fornecedores somente após a especificação ter sido validada.

O Passo 1 produz os blocos funcionais utilizados ao longo do projeto. O engenheiro do sistema cria modelos reutilizáveis — chamados Descrições de Especificação de Função (FSD) e Descrições de Especificação de Aplicação (ASD) — sem qualquer referência a um fabricante ou linha de produtos específico de IED.

Uma FSD descreve uma única função de proteção ou controle: seus nós lógicos, sinais e atributos de dados necessários. Uma ASD reúne múltiplas FSDs em uma aplicação completa — por exemplo, uma aplicação de proteção por distância (P21) ou uma aplicação de controle de disjuntor. A ASD também contém:

  • Fluxo de dados — como os sinais se movem entre funções, anotado com o tipo de serviço (GOOSE, SMV ou Interno) e direção
  • BehaviorDescription — a lógica funcional, escrita como requisitos em texto simples ou formalizada como Diagramas de Blocos de Função (FBD) conforme IEC 61131-3
  • ProcessResources — espaços reservados para sinais esperados de outras aplicações ainda não combinadas no projeto

Este último elemento é importante. Quando uma aplicação de proteção espera que um comando de disparo chegue ao disjuntor, essa conexão não pode ser totalmente resolvida dentro de uma única ASD — a aplicação do disjuntor é um modelo separado. Assim, ela é modelada como um espaço reservado de ProcessResource e resolvida no Passo 2, quando ambas as aplicações são combinadas.

As funções dentro de uma ASD são agrupadas usando AllocationRoles — papéis lógicos como "PIU", "Controlador de Barramento" ou "Proteção". Um AllocationRole define o que um IED lógico fará; ele não nomeia um dispositivo físico ou fabricante. Nesta fase, nenhum fornecedor está envolvido.

No protótipo de demonstração da Elia, apresentado em dezembro de 2023 usando o Helinks STS (Helinks/Alvexis), a equipe criou dois modelos de ASD: uma aplicação de disjuntor com quatro papéis de alocação e uma aplicação de proteção por distância P21 com lógica de disparo conforme IEC 61131-3. Ambos os modelos foram totalmente independentes das capacidades de produtos de qualquer fornecedor.

Thomas Sterckx, da Elia, resumiu o princípio: "Você realmente pode fazer isso de forma independente de tecnologia. É também uma especificação independente de fornecedor."

Passo 2: Especificação do Sistema — Requisitos de IED em Formato Machine-Readable

No Passo 2, o engenheiro instancia os modelos da biblioteca de ASD em um projeto concreto. Quando duas aplicações são combinadas, seus ProcessResources são resolvidos: o sinal de disparo esperado pela aplicação de proteção para o disjuntor agora é mapeado para a função real na aplicação do disjuntor. O sistema começa a tomar forma — ainda sem hardware.

Para cada IED físico no projeto, o engenheiro gera uma Descrição de Especificação de IED (ISD): um arquivo legível por máquina que substitui a tradicional pilha de documentos em PDF com requisitos. Uma ISD contém:

  • O modelo de dados esperado: dispositivos lógicos, nós lógicos, objetos de dados e atributos (especificados por meio dos elementos DOS/DAS)
  • Especificações de DataFlow: quais sinais o IED deve receber e enviar, com tipo de serviço e UUIDs de SourceRef
  • Descrições de Comportamento: a lógica funcional necessária que o IED deve implementar
  • Expectativas de interface física e nomeação (elementos LNodeSpecNaming)

Um ISD pode ser enviado simultaneamente a vários fornecedores. Cada fornecedor processa-o com sua própria ferramenta de configuração de IED — não lendo e interpretando texto, mas analisando maquinalmente o arquivo SCL. As respostas retornam em um formato estruturado e comparável. Como explicou Thomas Sterckx: "Em vez de entregar ao fornecedor do IED uma grande série de documentos escritos, você pode fornecer algo que seja legível por máquina, que ele possa processar dentro de sua própria ferramenta."

A saída da Etapa 2 é dupla: arquivos ISD para cada IED e uma SSD (System Specification Description) que captura a especificação completa do projeto — que também serve como entrada para a Etapa 3. A SSD prossegue imediatamente para a simulação. Os arquivos ISD, no entanto, não são enviados aos fornecedores neste momento: são enviados somente após a especificação ter sido validada por simulação (Etapa 3, ou no final do ciclo iterativo de simulação). Essa sequência é intencional — enviar um ISD a um fornecedor antes da validação corre o risco de fixar uma especificação que não foi confirmada como funcionando conforme o esperado.

Etapa 3: Simulação e Validação do Sistema — Teste Antes da Existência do Hardware

Esta é a etapa que define a engenharia de cima para baixo.

Sem hardware. Sem fornecedor selecionado. Sem contrato assinado.

A SSD ou ASD é importada em uma ferramenta de simulação, e o comportamento do sistema é testado contra a especificação funcional — inteiramente em software. O que torna isso possível é a estrutura formal da própria ASD. Uma especificação em PDF descreve a lógica de proteção em linguagem natural. Uma ASD codifica os mesmos requisitos como Diagramas de Blocos de Função em IEC 61131-3 — uma representação que as ferramentas podem analisar, renderizar e executar diretamente. Este não é um simulação no sentido aproximado; é a execução da especificação tal como escrita.

Duas visualizações estão disponíveis. A primeira é um gráfico de fluxo de dados: recursos de processo (entradas) à esquerda, lógica funcional no centro, saídas à direita. Todos os caminhos de sinal são visíveis, incluindo tipo de serviço e direção — o engenheiro pode rastrear qualquer entrada até qualquer saída antes de configurar um único IED. A segunda é a execução de comportamento: onde a ASD contém lógica em Diagrama de Blocos de Função IEC 61131-3, a ferramenta a renderiza e permite manipulação interativa. Defina um valor de entrada como ativo — o sinal propaga-se pelo diagrama de blocos de função em tempo real, e você observa quais saídas são acionadas.

Para validação estruturada em escala, os cenários podem ser definidos como casos de teste tabulares: uma linha por cenário, com valores de entrada pré-definidos e valores de saída esperados para cada sinal na aplicação. A ferramenta executa a sequência, sinaliza discrepâncias e captura os tempos — permitindo a verificação do comportamento dependente do tempo, onde a precisão em milissegundos é importante.

É importante destacar que a simulação não é necessariamente uma etapa única no final do trabalho de especificação. Como Jackson Moore descreveu: "isso pode ser um processo iterativo — os testes podem ocorrer enquanto o projeto ainda está sendo desenvolvido." Na prática, isso significa que o engenheiro pode especificar uma parte do ASD ou SSD, simular, refinar com base nos resultados e simular novamente — percorrendo o ciclo especificar → simular → refinar até que o comportamento esteja totalmente confirmado. A ferramenta de simulação está integrada ao fluxo de especificação, não adicionada a ele.

A saída da Etapa 3 não é um novo arquivo. É uma especificação verificada — o mesmo SSD ou ASD, confirmado para se comportar conforme o esperado. Neste ponto, os arquivos ISD estão prontos para serem enviados aos fornecedores (Etapa 4): eles trazem uma especificação que foi executada e validada, não apenas escrita. O argumento econômico é direto: um erro de especificação encontrado na Etapa 3 custa uma tarde de retrabalho em um arquivo SCL. O mesmo erro encontrado durante a comissionamento — após a compra, após a mobilização, com equipamentos no local e equipes deslocadas — custa ordens de magnitude a mais. O mecanismo técnico é igualmente direto: como o comportamento é formalizado em IEC 61131-3 e não em linguagem natural, pode ser executado por uma ferramenta independentemente de qualquer dispositivo específico.

Jackson Moore, que demonstrou a simulação no protótipo da Elia: "Muitos erros potenciais podem agora ser identificados muito mais cedo no processo de engenharia — e são comparativamente muito mais baratos e fáceis de corrigir."

Etapa 4: Descrição da Capacidade do IED — O Fornecedor Responde

O arquivo ISD é enviado ao fabricante do IED, que o importa em sua Ferramenta de Configuração do IED. A ferramenta compara automaticamente a especificação com o modelo de dados real do dispositivo — identificando quais nós lógicos e objetos de dados estão disponíveis, quais precisam ser criados e onde as convenções de nomenclatura do fornecedor diferem das da especificação.

A saída é um ICD de processo: um arquivo ICD padrão estendido com informações de mapeamento do namespace 6-100. Ele documenta explicitamente:

  • Como cada nó lógico na especificação se mapeia para o LN real do fornecedor (mappedLnUuid, mappedDoName)
  • Espaços reservados de ExtRef (extRefUuid) ligados a entradas de SourceRef na especificação — esses serão resolvidos automaticamente pelo SCT na Etapa 5
  • Quaisquer desvios em BehaviorDescription: se o fornecedor não pode implementar a lógica especificada exatamente como escrita, esse desvio é documentado no arquivo, em vez de permanecer implícito
  • Rastreabilidade baseada em UUID ligando o ICD de processo ao SSD e ISD de origem através da entrada de cabeçalho SourceFiles

Os fornecedores têm duas opções de implementação. Podem manter nomes proprietários enquanto documentam o mapeamento completo — maximizando a compatibilidade com as ferramentas existentes. Alternativamente, podem importar o modelo de dados unificado da especificação, adotando os nomes exatamente como especificados — maximizando a interoperabilidade, mas com o custo de mais trabalho de adaptação no lado da TI (Tecnologia da Informação).

No PoC da Elia, Cedric Harispu demonstrou esse passo usando o Siemens DIGSI 5 com uma unidade de fusão 6MU e um relé de proteção de distância 7SA87. O DIGSI 5 reconheceu automaticamente os dispositivos lógicos do ISD, tratou o mapeamento de LNode para LN e gerou arquivos ICD de processo para ambos os dispositivos — incluindo a criação de entradas de entrada GOOSE que não faziam parte da configuração padrão do dispositivo.

O resultado crítico: o engenheiro recebe uma resposta legível por máquina. As discrepâncias entre a especificação e a capacidade do fornecedor são explícitas, rastreáveis e documentadas — não enterradas em trocas de e-mail.

O ICD de processo não é apenas "a resposta do fornecedor". Ele foi projetado para permitir a verificação automatizada do lado do usuário. Uma vez recebido o ICD de processo, a SCT pode comparar automaticamente a implementação do fornecedor com a especificação original — sinalizando sinais não mapeados, desvios de nomeação e lacunas em BehaviorDescription sem inspeção manual. Como declarou Thomas Sterckx: "este ICD de processo também permite automatizar a etapa de validação do lado do usuário — para validar o que você recebeu de um fornecedor de IED."

Etapa 5: Configuração do Sistema — Montagem Automatizada do SCD

O engenheiro de sistema recebe arquivos ICD de processo de todos os fornecedores e os importa na Ferramenta de Configuração do Sistema (SCT). A SCT lê as informações de mapeamento do namespace 6-100 e automatiza a montagem do SCD final.

Especificamente, a SCT:

  1. Cria instâncias de IED a partir dos modelos de ICD de processo
  2. Resolve as entradas SourceRef da especificação em links ExtRef concretos, usando os mapeamentos extRefUuid fornecidos pelo fornecedor
  3. Gera conjuntos de dados, blocos de controle GOOSE e SMV, e parâmetros de comunicação
  4. Sinaliza quaisquer sinais não resolvidos — onde um elemento da especificação não foi abrangido no ICD de processo

No PoC da Elia, a importação de dois arquivos ICD de processo (PIU Siemens e relé de proteção de distância Siemens) no Helinks STS preencheu uma matriz GOOSE com inscrições, gerou blocos de controle com conjuntos de dados para sinais de posição e disparo, e produziu uma configuração de comunicação completa — as 28 entradas ExtRef no IED PIU foram resolvidas automaticamente, e blocos de controle GOOSE apareceram onde anteriormente não existiam.

Ferramentas SCT que suportam a importação de ICD de processo e a resolução automática de vinculação SourceRef — como o Tekvel Park — podem realizar essa montagem com intervenção manual mínima.

O grau de automação na Etapa 5 é diretamente proporcional à qualidade do trabalho nas Etapas 1 a 4. Um ISD completo, um processo ICD bem executado com mapeamento completo e uma BehaviorDescription validada na Etapa 3 tornam a Etapa 5 amplamente automática. Qualquer lacuna nesses arquivos anteriores se traduz diretamente em trabalho de configuração manual aqui.

Após a exportação do SCD, o arquivo é devolvido ao fornecedor do IED para carregamento final do dispositivo. No PoC da Elia, o SCD foi importado no DIGSI 5 e verificado em um ambiente Siemens Digital Twin — dois dispositivos virtuais confirmando a recepção correta de valores amostrados, o comportamento de inscrição GOOSE e a consistência dos nomes do modelo de dados antes de qualquer hardware físico ser manipulado.

O que isso muda

A engenharia top-down IEC 61850 altera três aspectos para o engenheiro prático. Os erros de especificação são detectados durante a fase de projeto — antes das decisões de aquisição, antes dos compromissos com fornecedores, antes de qualquer hardware estar no local. A interação com os fornecedores de IED torna-se estruturada: um ISD substitui documentos PDF, um processo ICD substitui respostas informais, e toda a troca é legível por máquina e rastreável. E a seleção de fornecedores torna-se verdadeiramente competitiva: um ISD enviado a múltiplos fornecedores produz respostas comparáveis e estruturadas que podem ser avaliadas com base em mérito técnico.

Thomas Sterckx, da Elia, afirmou diretamente: "Agora você pode testar o que projetou antes de implementá-lo em um dispositivo. Muitos erros potenciais podem agora ser identificados muito mais cedo no processo de engenharia."

Os padrões técnicos estão publicados. As ferramentas existem. O processo de aquisição está em andamento na Elia. O próximo artigo desta série examina como o formato ISD altera o processo de aquisição e licitação de IEDs na prática.

Fontes

  1. Thomas Sterckx, Yannick Thiessoz, Jackson Moore, Cedric Harispu — IEC 61850 Top-Down Engineering PoC Webinar (Elia Group, dezembro de 2023)
  2. Elia Group — Visão Comum para a Engenharia Top-Down IEC 61850 (2023)
  3. TR IEC 61850-90-30:2025 — Redes e sistemas de comunicação para automação de usinas elétricas — Parte 90-30: Diretrizes para engenharia de sistemas IEC 61850
  4. TR IEC 61850-7-6:2024 (Ed. 2) — Diretrizes para gestão de sistemas e projetos IEC 61850