Nos projetos de subestações digitais, costuma-se dar muita atenção a GOOSE, SV, PTP e à infraestrutura de rede. É compreensível: GOOSE e SV são comunicações extremamente críticas — sensíveis a atrasos, perda de pacotes e à qualidade da infraestrutura de rede, enquanto a sincronização de tempo afeta diretamente a confiabilidade das medições e dos eventos.
Mas há outra camada importante, sem a qual a subestação digital não se torna um sistema de automação pleno — a troca MMS e, em particular, os relatórios IEC 61850. É por meio dos relatórios que o SCADA, o sistema de automação, a IHM, os gateways e os sistemas de monitoramento recebem a teleinformação — telessinalização e telemedição — dos dispositivos eletrônicos inteligentes (IEDs).
Na prática, os problemas com relatórios IEC 61850 muitas vezes parecem enganosamente simples: a conexão MMS existe, o dispositivo está acessível, o cliente «vê» o servidor, mas os dados não atualizam, parte dos sinais desaparece, os eventos se duplicam ou o bloco de controle de relatórios simplesmente não ativa. A causa quase sempre não é um único «pacote ruim», mas a falta de concordância entre o modelo de dados, a configuração SCL, os ajustes do cliente e a configuração real do IED.
A seguir, os problemas mais críticos encontrados ao trabalhar com blocos de controle de relatórios na IEC 61850.
A conexão MMS existe, mas o bloco de controle de relatórios não está ativado
Uma das situações mais frequentes: o cliente estabelece com sucesso a conexão MMS com o IED, mas os dados do relatório não chegam. Do ponto de vista de rede, tudo parece normal: há acessibilidade IP, a sessão TCP está estabelecida, a conexão MMS está ativa.
A primeira coisa a verificar é o estado do atributo RptEna do bloco de controle de relatórios em questão.
RptEna = true significa que o bloco de controle de relatórios está ativado pelo cliente e deve transmitir dados de acordo com a sua configuração.
RptEna = false significa que o bloco de controle de relatórios não está ativado e, portanto, não há transmissão de dados por ele.
O problema é que o simples fato de a conexão MMS ter êxito ainda não significa que os relatórios passaram a funcionar. O servidor MMS pode responder a requisições, permitir a leitura do modelo de dados e retornar valores de atributos individuais — e, ainda assim, o bloco de controle de relatórios permanece inativo.
Conclusão prática: no diagnóstico não se pode parar na verificação «há conexão / não há». É preciso verificar o estado do bloco de controle de relatórios específico, antes de tudo o atributo RptEna.
Divergência de ConfRev: o cliente recusa ativar o relatório
ConfRev é um contador de revisão de configuração. Segundo a IEC 61850-7-2 (ed.2.0, §17.2.2.7 para blocos bufferizados e analogamente para os não bufferizados), ele reflete o número de alterações do conjunto de dados (DataSet) que o bloco de controle de relatórios referencia pelo atributo DatSet.
A norma enumera explicitamente quais alterações incrementam ConfRev:
- remoção de um membro do conjunto de dados;
- adição de um membro do conjunto de dados;
- reordenação dos membros do conjunto de dados;
- alteração do valor do atributo
DatSet(troca do bloco para outro conjunto de dados).
Aqui há um detalhe muitas vezes mal compreendido: ConfRev não muda quando se alteram os demais parâmetros do próprio bloco de controle de relatórios — TrgOps, BufTm, IntgPd, OptFlds, RptID e outros. Ou seja, editar os gatilhos, o tempo de buffer ou o período de integrity, por si só, não aumenta ConfRev. Essa revisão está «vinculada» justamente à composição e à ordem do conjunto de dados, não aos ajustes de transmissão de relatórios em geral.
Muitos clientes IEC 61850, ao conectar, leem o ConfRev do modelo ativo do servidor e o comparam com o valor que esperam ver com base no arquivo SCL/CID. Se os valores não coincidem, o cliente pode recusar a ativação do bloco de controle de relatórios.
Na prática, uma divergência de ConfRev quase sempre indica que a composição do conjunto de dados no dispositivo e na configuração do cliente divergiu. Causas típicas:
- alteraram a composição do DataSet;
- adicionaram ou removeram um sinal;
- reordenaram os elementos do conjunto de dados;
- trocaram o bloco de controle de relatórios para outro DataSet;
- recompilaram o arquivo CID com um conjunto de dados atualizado;
- carregaram uma nova configuração no dispositivo;
- atualizaram o projeto SCADA, mas não o sincronizaram com a configuração real do IED.
Como resultado, no objeto pode surgir uma situação paradoxal: na documentação de projeto e no arquivo SCL tudo parece correto, mas o cliente não ativa o relatório porque o ConfRev real no dispositivo é diferente.
É especialmente perigoso quando diferentes participantes do projeto trabalham com versões distintas dos arquivos SCL: o comissionador usa uma versão de CID, o desenvolvedor de SCADA outra, o fabricante do dispositivo carregou uma terceira, e no arquivo do projeto está uma quarta.
Conclusão prática: em problemas com relatórios, deve-se comparar não apenas o arquivo SCL que «deveria» estar no dispositivo, mas o modelo real que o servidor entrega por MMS. Para isso são úteis um navegador MMS ou a análise de uma captura PCAP. E como ConfRev acompanha justamente o conjunto de dados, em caso de divergência de revisão deve-se procurar antes de tudo a diferença na composição, na ordem e nos tipos dos elementos do DataSet.
Um bloco de controle de relatórios já está ocupado por outro cliente
Em uma subestação digital, um único IED costuma atender vários clientes: SCADA, IHM, gateway de telecontrole, sistema de monitoramento, estação de engenharia, registrador de eventos e outros. Todos eles podem querer receber o mesmo conjunto de dados.
Mas uma única instância de um bloco de controle de relatórios não pode ser ativada por vários clientes ao mesmo tempo. Se um cliente já ativou um bloco de controle de relatórios específico, um segundo cliente, ao tentar ativá-lo, receberá uma recusa e simplesmente não conseguirá ativar o relatório.
Um indício do problema é RptEna já em true, embora «nosso» cliente ainda não tenha ativado esse relatório.
A partir daí começa a dificuldade prática: nem sempre o servidor mostra qual cliente exatamente ocupou o bloco de controle de relatórios (pelo atributo Owner). Às vezes isso pode ser visto no diagnóstico do IED, às vezes apenas pelo tráfego de rede, analisando os endereços IP dos clientes que leem e escrevem os atributos do bloco de controle de relatórios.
A IEC 61850 prevê um mecanismo de indexação do Report Control Block. Por exemplo, em vez de um único BRep01, o servidor pode suportar as instâncias BRep0101, BRep0102 e assim por diante. Isso permite que vários clientes trabalhem com instâncias diferentes de um mesmo bloco de controle de relatórios lógico.
Mas, na prática, o suporte à indexação depende do dispositivo e do cliente específicos. Além disso, se o próprio cliente «procura um índice livre», isso pode levar a um comportamento inesperado em reinicializações, perda de conexão e restabelecimento.
Conclusão prática: para sistemas críticos é melhor não depender da busca automática por um bloco de controle de relatórios livre, mas atribuir antecipadamente a cada cliente a sua instância específica. Isso deve estar refletido na configuração, nos arquivos SCL e nos ajustes do SCADA/IHM/gateway.
O bloco de controle de relatórios está ativado, mas os eventos não chegam
Outro problema frequente: RptEna = true, o bloco de controle de relatórios está ativado, mas os dados não chegam quando os sinais mudam. Às vezes o cliente recebe dados apenas periodicamente, às vezes só após uma General Interrogation, às vezes nada.
Aqui é preciso olhar TrgOps — Trigger Options.
É justamente esse parâmetro que define por quais razões o servidor deve gerar um relatório. A IEC 61850 usa as seguintes opções principais:
data-change— transmissão na mudança de valor;quality-change— transmissão na mudança de qualidade;data-update— transmissão na atualização dos dados;integrity— transmissão periódica do estado completo;general-interrogation— transmissão por solicitação de interrogação geral.
O problema prático mais agudo é que o relatório pode estar formalmente ativado, mas os gatilhos necessários não estarem ativados.
Por exemplo, se só integrity estiver ativo, o cliente receberá atualizações periódicas, mas não verá os eventos no momento em que os sinais mudam.
Se quality-change não estiver ativo, o cliente pode não receber uma mudança de qualidade dos dados, embora para a operação isso seja crítico: o sinal pode permanecer no mesmo estado enquanto sua qualidade muda para invalid, questionable, substituted ou test.
Se a escrita das trigger options necessárias não for suportada do lado do cliente, este pode tentar ativar as flags, mas o servidor recusará a escrita. Como resultado, o bloco de controle de relatórios está ativado, mas não funciona como o integrador espera.
Conclusão prática: ao comissionar relatórios, deve-se verificar não só o fato de o bloco de controle de relatórios estar ativado, mas também o valor real de TrgOps no modelo ativo do IED. É especialmente importante controlar data-change, quality-change, integrity e general-interrogation.
O DataSet no cliente não coincide com o DataSet no dispositivo
O bloco de controle de relatórios por si só não contém todos os sinais. Ele referencia um DataSet — o conjunto de dados que deve ser transmitido ao cliente.
Se o cliente e o servidor entendem de forma diferente a composição do DataSet, começam os problemas mais desagradáveis: parte dos sinais atualiza, parte não, os valores «escorregam», a qualidade é interpretada de forma incorreta e o diagnóstico se torna pouco evidente.
Na resposta MMS, os dados do conjunto são transmitidos não como «sinais nomeados com tags legíveis», mas como uma sequência de elementos. O cliente deve saber de antemão qual elemento corresponde a qual sinal. Se a composição do DataSet mudou no servidor e o cliente continua usando a descrição antiga, a correspondência se quebra.
E parece que o atributo confRev descrito acima deveria proteger contra esse problema — mas e se o cliente não o processa?
Um exemplo simples: o cliente espera dez sinais SPS, enquanto no dispositivo o segundo elemento do conjunto foi substituído por um DPS. Externamente, o relatório pode continuar chegando, mas o cliente já não consegue interpretar corretamente toda a sequência de dados. Muitos clientes, nessa situação, processam parte dos dados até a primeira incompatibilidade de tipo e, depois, param de atualizar os elementos restantes.
Do ponto de vista da operação, isso é perigoso porque o problema pode parecer não uma falha total de comunicação, mas uma degradação parcial: «parte dos sinais atualiza, parte travou».
Conclusão prática: ao suspeitar de atualização incorreta de dados, deve-se comparar a composição real do DataSet no IED com a configuração do cliente. É importante verificar não só o número de elementos, mas também sua ordem, os tipos de dados, as restrições funcionais e as referências aos Data Object / Data Attribute concretos. Lembre-se de que é justamente as alterações desse conjunto que o ConfRev reflete — por isso, uma divergência de DataSet e uma divergência de ConfRev costumam andar juntas.
Duplicação de eventos de um bloco de controle de relatórios bufferizado
Os relatórios bufferizados são usados para que os eventos não se percam em uma perda temporária de conexão do cliente com o servidor. O servidor bufferiza os eventos e, após o restabelecimento da conexão, o cliente deve receber o que perdeu.
Mas aqui há um detalhe importante da IEC 61850: o servidor atribui um entryID a cada evento, e o cliente deve acompanhar corretamente quais entryID já foram processados.
Se o cliente gerencia o entryID de forma incorreta, em uma perda de conexão, na reinicialização do cliente ou na reativação do bloco de controle de relatórios bufferizado, ele pode processar os mesmos eventos novamente. Nos registros de eventos isso aparecerá como duplicação.
É especialmente importante considerar as diferenças de comportamento entre implementações e edições da norma. Em alguns cenários, o servidor, ao reconectar, pode transmitir todos os eventos do buffer se o cliente não tiver gravado o entryID correto antes de ativar RptEna.
Conclusão prática: se surgirem eventos duplicados no sistema, deve-se analisar não apenas os eventos em si, mas também o comportamento do cliente ao trabalhar com o bloco de controle de relatórios bufferizado: como ele armazena o entryID, o que grava na reconexão, como reage à perda de conexão e à reinicialização.
Fé excessiva no arquivo SCL
Uma das principais causas de problemas com relatórios IEC 61850 é a certeza de que o arquivo SCL/CID disponível corresponde exatamente ao que está realmente carregado no dispositivo.
Na prática, nem sempre é assim. Alguns dispositivos são configurados não diretamente a partir de um arquivo CID, mas por meio de suas próprias ferramentas de engenharia e arquivos internos de ajustes. Às vezes o CID é exportado do dispositivo, mas não é a fonte da sua configuração ativa. Às vezes, após mudanças no software de engenharia, a nova configuração não foi carregada no IED. Às vezes o SCADA foi configurado por um arquivo enquanto o dispositivo opera por outro.
Por isso, ao investigar problemas com relatórios, é útil trabalhar com três fontes ao mesmo tempo:
- o arquivo SCL/CID considerado de projeto;
- o modelo MMS real, lido do dispositivo;
- a captura PCAP da troca entre cliente e servidor.
Se essas três fontes não coincidem, o problema quase certamente está na dessincronização de configurações. É claro que tudo isso pode ser detectado automaticamente ao usar um sistema de monitoramento IEC 61850.
O que é importante considerar na implementação
Muitos problemas com relatórios IEC 61850 podem ser evitados já na etapa de projeto e comissionamento.
Para cada cliente deve-se definir de antemão quais blocos de controle de relatórios ele utiliza.
Se vários clientes recebem os mesmos dados, deve-se atribuir-lhes explicitamente instâncias diferentes de blocos de controle de relatórios, em vez de contar com a seleção automática de um índice livre.
A composição do DataSet deve ser fixada e sincronizada entre o IED, o SCADA, a IHM, os gateways e os sistemas de monitoramento.
Após alterar a composição do DataSet, deve-se controlar a mudança de ConfRev e atualizar as configurações do cliente. Ao mesmo tempo, vale lembrar que editar apenas os parâmetros do bloco (por exemplo TrgOps ou BufTm) não muda ConfRev — mas a configuração do cliente, mesmo assim, pode precisar ser ajustada.
Para os relatórios bufferizados é necessário verificar separadamente os cenários de perda de conexão, reinicialização do cliente e restabelecimento da conexão.
Nos testes de aceitação convém incluir não só a verificação de «os dados chegam», mas também a verificação de mudanças por evento, mudanças de qualidade, General Interrogation, relatórios de integrity e o comportamento na queda da conexão.
Conclusão
Os relatórios IEC 61850 não são apenas «leitura de dados por MMS». São um mecanismo de transmissão esporádica, orientada a eventos, em que importam o modelo de dados, o DataSet, os gatilhos, a bufferização, as revisões de configuração e o comportamento do cliente.
Os problemas mais agudos costumam surgir não de uma falha de rede, mas da dessincronização entre o que o cliente espera e o que está realmente configurado no IED.
Por isso o princípio-chave do diagnóstico é simples: não confiar em uma única fonte de informação. O arquivo SCL, os ajustes do cliente, o modelo MMS real do dispositivo e a captura PCAP devem ser considerados em conjunto.
É justamente essa abordagem que permite distinguir rapidamente um problema de rede de um de configuração, encontrar a causa de um relatório que não funciona e evitar situações em que a conexão MMS existe, mas a subestação digital, na prática, não recebe teleinformação confiável.