Uma execução do Tekvel Magic — e o dispositivo escolhido no SCL ganha vida: um servidor MMS é iniciado a partir do seu modelo de dados e um painel de controle abre no navegador. Você altera os valores e a qualidade dos sinais — e o cliente do nível superior recebe relatórios dchg/qchg reais, exatamente como de um IED real. O módulo funciona sem um único dispositivo físico na bancada: basta um arquivo SCL.

Nos artigos anteriores da série mostramos como o Tekvel Magic compara a configuração de um SCD com a configuração real do IED, como, com um clique, captura o estado atual dos blocos de controle de relatórios via MMS e como transforma uma configuração SCL num formulário legível de transferência de teleinformação. Hoje — o quarto caso, que aborda a tarefa do outro lado da mesa. Até agora o Magic trabalhava com o que já existe: arquivos e dispositivos ativos. Agora ele torna-se o próprio dispositivo — para testar quem recebe esses relatórios.

Por que emular um dispositivo

A transferência de teleinformação por IEC 61850 tem sempre dois lados: o dispositivo servidor (um IED de proteção, um controlador de bay, um transdutor de medição) que gera os relatórios via MMS, e o cliente do nível superior (um servidor de telecontrole, o SCADA) que se inscreve nesses relatórios e os exibe ao operador. O primeiro lado costuma ser testado a fundo no projeto. Já o lado receptor — como exatamente o nível superior recebe, interpreta e mostra os relatórios — é bem mais difícil de testar.

O motivo é simples: para testar o cliente com honestidade é preciso um servidor em funcionamento que entregue os dados certos no momento certo. E aí começam as dificuldades:

  • Alguns dispositivos ainda não estão no objeto ou não foram totalmente comissionados. A configuração e a aceitação do nível superior muitas vezes correm em paralelo com a configuração — ou até a entrega — de alguns dispositivos, e às vezes à frente disso. Não há contra o que testar o nível superior.
  • O dispositivo existe, mas não se consegue tirar dele o estado necessário. Como forçar um terminal real a emitir bad-state para a posição de um disjuntor, qualidade questionable ou a flag test — e ainda em uma sequência controlada? Num dispositivo em serviço isso é impossível ou inseguro (por exemplo, porque os bays do objeto já estão em operação).
  • É preciso reproduzir um cenário raro. Perda e recuperação da validade, substituição de valores — tais situações simplesmente não se criam num objeto real.

Como resultado, a aceitação do nível superior muitas vezes se transforma em observar o que por acaso chegou da rede, em vez de um teste dirigido. O módulo do Tekvel Magic apresentado aqui fecha essa lacuna: ele inicia um servidor MMS diretamente de um arquivo SCL e oferece um painel prático a partir do qual o engenheiro controla os valores e a qualidade dos sinais — e observa como o cliente reage.

Painel web do simulador de servidor MMS: visão geral
Fig. 1. O painel web do simulador: o estado dos blocos de controle de relatórios expostos pelo servidor, a estrutura dos conjuntos de dados, o controle dos valores e da qualidade dos sinais, o histórico de alterações, o registro de operações.

Lugar na série de cenários de teste do SCADA: ler, mostrar, documentar — e jogar como o dispositivo

Para não confundir tarefas próximas, convém ter em mente a divisão em toda a série de cenários de teste relacionados ao SCADA:

  • Caso #1 — conformidade: compara o SCD de projeto com a configuração real dos dispositivos via MMS e produz um relatório de divergências.
  • Caso #2 — estado: conecta-se aos dispositivos via MMS e mostra como os relatórios funcionam agora (RptEna, Owner, quem está inscrito em quê).
  • Caso #3 — documentação: pega a configuração SCL e a transforma num formulário legível de transferência de teleinformação, offline.
  • Caso #4 — emulação (este): pega a configuração SCL e torna-se o dispositivo nela descrito, gerando relatórios reais para testar o lado receptor.

A diferença-chave do quarto caso é que ele é ativo. Os três primeiros trabalham com o que já existe: leem, comparam, mostram, documentam. Aqui, pela primeira vez, o Magic não observa o tráfego, mas o cria — atua como servidor IEC 61850 e faz o papel de um dispositivo que pode ainda nem estar no objeto, ou pode não estar configurado. Isso desloca o foco do teste do dispositivo para o nível superior: não «o IED está configurado corretamente», mas «quem está acima recebe e exibe os dados corretamente».

Como funciona

O cenário é o mais curto possível. Você inicia o módulo — e na primeira caixa de diálogo seleciona um arquivo SCL: pode ser um CID/ICD isolado com um único dispositivo ou um SCD de subestação com várias dezenas de IEDs. Se houver vários dispositivos no arquivo, o módulo propõe escolher um — aquele que ele vai «representar».

Depois disso tudo acontece automaticamente: o módulo inicia um servidor MMS a partir do modelo de dados do dispositivo selecionado e abre um painel de controle no navegador. A partir desse momento, para qualquer cliente do nível superior na rede o simulador é indistinguível de um IED real: tem o mesmo modelo de dados, os mesmos blocos de controle de relatórios, os mesmos conjuntos de dados e o endereço do SCL.

Todo o percurso fica claro como um diagrama de blocos — da escolha do arquivo ao fluxo de relatórios para o nível superior:

flowchart TB
    A["Iniciar o módulo"]
    F["Selecionar um arquivo SCL<br/><i>CID / ICD / SCD</i>"]
    S["Selecionar um dispositivo<br/><i>se houver vários IEDs no arquivo</i>"]
    P["Verificar: há RCB<br/>com conjuntos de dados?"]
    B["Iniciar o servidor MMS<br/><i>modelo do IED selecionado</i>"]
    C["Cliente interno<br/><i>readback + varredura em segundo plano</i>"]
    W["Painel web<br/><i>abre no navegador</i>"]

    A --> F --> S --> P --> B
    B --> C
    B --> W
    W ==> ACT

    subgraph ACT["Ações do engenheiro no painel"]
        direction TB
        V["Alterar valores dos sinais"]
        Q["Alterar qualidade (validity / test / source)"]
        AC["Varredura automática de valores e qualidade"]
        V --> RPT
        Q --> RPT
        AC --> RPT
        RPT["Relatórios dchg / qchg via MMS"]
    end

    ACT ==> EXT["<b>CLIENTE DO NÍVEL SUPERIOR</b><br/>SCADA / gateway / despacho —<br/>recebe e exibe os relatórios"]

    style A fill:#F3F3F3,stroke:#888
    style F fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style S fill:#EDE7F6,stroke:#7E57C2,color:#311B92
    style P fill:#EDE7F6,stroke:#7E57C2,color:#311B92
    style B fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style W fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style V fill:#FFF8E1,stroke:#F9A825,color:#E65100
    style Q fill:#FFF8E1,stroke:#F9A825,color:#E65100
    style AC fill:#FFF8E1,stroke:#F9A825,color:#E65100
    style RPT fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style EXT fill:#E8F5E9,stroke:#43A047,color:#1B5E20
Fig. 2. Como o simulador funciona: da escolha do arquivo SCL ao fluxo de relatórios para o nível superior.

Vale destacar à parte o tratamento de um SCD de subestação. Segundo a IEC 61850-6, esse arquivo descreve dezenas de dispositivos num único modelo — e não é possível iniciar diretamente dele um servidor para um único IED. O módulo resolve isso sozinho: extrai o dispositivo selecionado para um arquivo temporário de um único dispositivo, tratando cuidadosamente os pontos de acesso (inclusive a construção ServerAt, quando um ponto referencia o servidor de outro). O engenheiro não precisa pensar nisso — basta indicar o nome do dispositivo.

Mais um ponto — o Tekvel Magic pode expor o dispositivo simulado no seu endereço IP extraído do arquivo SCL. Isso também é importante.

O que o painel de controle faz

O painel abre num navegador comum e atualiza em tempo real. Dentro — vários blocos coordenados.

Estado dos blocos de controle de relatórios expostos pelo dispositivo simulado. Uma tabela de todos os blocos — bufferizados (BRCB) e não bufferizados (URCB) — com seu estado ao vivo: RptEna, SqNum, EntryID, Owner, a flag de interrogação geral (GI), a hora do último evento, o conjunto de dados, os gatilhos ativos (TrgOps) e os campos opcionais (OptFlds). Vê-se qual cliente se inscreveu em qual bloco e o que realmente está ativado.

A tabela «Estado dos Report Control Blocks» com um cliente inscrito
Fig. 3. Estado ao vivo dos blocos de controle de relatórios: vê-se quem está inscrito e quais gatilhos estão ativos.

Controle de valores. Os sinais são agrupados por conjunto de dados. Para cada objeto de dados o painel escolhe sozinho a entrada conveniente: uma lista suspensa para sinais discretos (posição do disjuntor — off/on/intermediate/bad-state), um campo numérico para medições. Grandezas multifásicas (WYE/DEL/SEQ) são gravadas em todas as fases de uma vez. Cada gravação é verificada por readback — o que você vê no painel garantidamente foi para o modelo e para o relatório.

Controle de qualidade. Um formulário separado para cada sinal: validity (good / invalid / questionable), as flags test e operatorBlocked, a fonte process/substituted. Qualquer alteração de qualidade gera um relatório qchg — exatamente o necessário para verificar como o nível superior exibe a invalidez e os dados de teste.

Controle dos valores e da qualidade dos sinais de um conjunto de dados
Fig. 4. Controle dos valores e da qualidade dos sinais: a entrada se adapta ao tipo do objeto de dados.

Histórico de alterações e registro de operações. Cada alteração de valor ou de qualidade é registrada num histórico cronológico — com o valor atual, a qualidade atual e um carimbo de tempo. Um registro separado das ações do operador é mantido. Nada se perde, mesmo que as alterações venham mais rápido do que a página se atualiza.

Varredura automática — teste em massa de cenários em um clique

A comutação manual é boa para verificações pontuais, mas quando é preciso passar um sinal por todos os estados — ou testar de uma vez um conjunto de dados inteiro — entra em cena a varredura automática. Você marca os sinais, define o intervalo e o número de ciclos — e o módulo percorre ciclicamente todos os valores significativos de cada sinal conforme o seu tipo (CDC):

  • discretos (DPC/DPS): off → on → intermediate → bad-state;
  • únicos (SPC/SPS/ACT): false → true;
  • enumerados e inteiros (INS/ENS): por uma série de valores;
  • medições (MV/CMV/WYE/DEL/SEQ): por uma série de valores.

Com a opção «+ qualidade» ativada, após cada valor pode-se ainda percorrer uma sequência de estados de validade: invalid → questionable → good+test → good+operatorBlocked → good+substituted → e de volta a good. Assim, em uma única execução o nível superior recebe o espectro completo de combinações «valor × qualidade» — ideal para verificar a exibição de todos os estados de uma vez. A varredura pode ser pausada ou interrompida; ao parar, a qualidade de todos os sinais é cuidadosamente devolvida a good para que o modelo não fique num estado «corrompido».

O painel de varredura automática de valores e qualidade
Fig. 5. Varredura automática de valores e qualidade: teste em massa de cenários para um conjunto de dados ou para todos de uma vez.

Para que serve — na prática

O principal valor é a possibilidade de testar o nível superior quando é conveniente, e não quando se «tem sorte» com o tráfego de dispositivos reais.

Comissionar o nível superior com antecedência. Os dispositivos ainda estão a caminho, mas o servidor de telecontrole ou o servidor SCADA já precisa ser configurado e testado. O simulador, construído a partir do SCD de projeto, representa o futuro dispositivo — o mapeamento de sinais, as inscrições em relatórios e a exibição podem ser depurados de antemão.

O nível superior é implantado quando os painéis já estão em operação. Situação frequente: os painéis de proteção e SCADA de um bay há muito estão em serviço, enquanto a ampliação ou modernização do nível superior (um novo servidor SCADA, um gateway, um centro de despacho) é feita depois. Já não se pode iniciar alterações de sinais nos dispositivos em serviço para testar a recepção no nível superior — o equipamento está sob carga, e interferir na sua operação é inadmissível. O simulador remove essa limitação: atua como um «dublê» do dispositivo em operação usando a própria configuração SCL dele, e todas as alterações necessárias — posições, medições, qualidade — são iniciadas a partir dele, sem tocar nos painéis reais em operação.

Testar a exibição de qualidade e dados de teste. Como o operador verá um sinal com qualidade invalid? O nível superior filtrará dados com a flag test? O simulador permite definir qualquer combinação de bits de qualidade e observar a reação — algo praticamente impossível de reproduzir num dispositivo em serviço.

Reproduzir cenários raros e «incômodos». Uma posição intermediária do disjuntor, a perda da validade e o seu restabelecimento, uma série de alterações rápidas — tudo isso é definido no painel ou executado pela varredura automática em uma sequência controlada.

Treinamento e demonstração. O simulador é uma bancada visual para treinar o pessoal a trabalhar com relatórios IEC 61850 e para demonstrar como a transferência de teleinformação se parece «em movimento».

Em conjunto com os casos anteriores, forma-se um bom conjunto de cenários de teste para um engenheiro de SCADA moderno. O caso #1 verifica que o dispositivo está configurado conforme o projeto; o caso #2 mostra como os relatórios funcionam agora; o caso #3 produz documentação legível; e o caso #4 permite jogar como o dispositivo e garantir que o nível superior recebe e exibe tudo corretamente. «Como está configurado», «como funciona agora», «como explicar isso aos outros» — e, por fim, «como será recebido do outro lado».

Aproveite! E lembre-se: às vezes a engenharia da IEC 61850 exige um pouco de Magia :)