Com base em nossas observações, 8 dos 10 configuradores não reconhecem completamente a configuração de arquivos SCD. Recentemente, encontramos um caso interessante de importação incorreta que nos levou a escrever tissue 1791.
Fundamentos
Para um de nossos projetos envolvendo 43 IEDs (intelligent electronic devices), desenvolvemos um arquivo SCD (Substation Configuration Description). O equipamento descrito no arquivo incluía conversores de sinais analógicos, conversores de sinais discretos, terminais de relés de proteção e automação, e controladores de barramento de oito fabricantes diferentes. Ao desenvolver o arquivo SCD, consideramos as especificidades de configuração dos dispositivos de cada fabricante para garantir compatibilidade e configuração unificada durante a comissionamento.
Durante a importação do arquivo SCD e sua reconhecimento pelos configuradores de IED (ICT), verificou-se que os dispositivos de um fabricante não conseguiam subscrever mensagens GOOSE e fluxos de Valores Amostrados (SV). A funcionalidade estava ausente porque os blocos de controle configurados não foram exibidos ao importar as configurações do dispositivo publicador. O arquivo desenvolvido passou na validação da sintaxe SCL sem erros, e o ICT não sinalizou nenhum problema durante a importação. Como se verificou posteriormente, a razão pela qual os blocos de controle não foram exibidos foi a ausência do atributo confRev nos blocos de controle do dispositivo publicador no arquivo SCD. Neste artigo, investigaremos por que o ICT do fabricante não exibiu a configuração e se tal comportamento é correto.
O que é o Atributo confRev e Para Que Ele Serve?
confRev é um atributo que indica quantas vezes a configuração do conjunto de dados referenciado pelo atributo DatSet de um bloco de controle foi alterada. O atributo é necessário para a sincronização de configuração entre o publicador e o assinante; seu valor atual é incluído na mensagem GOOSE publicada e no fluxo SV.
Se um assinante receber um quadro em que o valor de confRev difere do valor esperado com base na configuração carregada, isso indica uma discrepância entre a versão da configuração do publicador e a real. Se o assinante verifica esse atributo pode ser determinado a partir do documento PIXIT do dispositivo.
No PIXIT em análise, consta que o assinante verifica o valor de confRev. Portanto, se ele diferir do valor esperado, os sinais da mensagem recebida não serão processados. Esse atributo, assim, fornece uma forma de proteger o dispositivo receptor de interpretar incorretamente os sinais de entrada.
Evolução do confRev
Desde o lançamento da Edição 1 da IEC 61850 até a Edição 2.1 atual, os requisitos que descrevem o papel funcional do atributo confRev foram progressivamente formalizados — mudanças que contribuíram diretamente para o problema que enfrentamos.
IEC 61850 Ed1
Na primeira edição da IEC 61850, o confRev é definido como o número de revisão da configuração do bloco de controle. O atributo é obrigatório para os blocos de controle de Relatório e opcional para os blocos de controle GOOSE e SV.
Para os blocos de controle de Relatório, o confRev deve ser incrementado quando um elemento é excluído do conjunto de dados ou quando a ordem dos elementos muda.
O valor inicial do confRev não é especificado pelo padrão. O valor 0 está reservado.
O valor do confRev não deve ser redefinido para seu valor inicial após a reinicialização do dispositivo.
IEC 61850 Ed2
Com o lançamento da Edição 2, a formalização do atributo confRev foi expandida e parcialmente revisada.
O confRev agora é definido como um atributo que reflete o número de vezes em que a configuração do conjunto de dados referenciado pelo atributo DatSet foi alterada.
A principal diferença em relação à Edição 1 é que o confRev torna-se obrigatório para os blocos de controle GOOSE e SV no corpo do padrão. No entanto, no esquema XML da Edição 2, o confRev para os blocos de controle GOOSE e SV continua opcional.
As condições que exigem o incremento do atributo foram formalizadas.
Alterações que devem ser rastreadas para os blocos de controle de Relatório:
- exclusão de um elemento do conjunto de dados;
- mudança na ordem dos elementos do conjunto de dados;
- configuração do conjunto de dados via serviço SetBRCBValues que altera o valor do atributo DatSet.
Alterações que devem ser rastreadas para os blocos de controle GOOSE:
- exclusão de um elemento do conjunto de dados;
- adição de um elemento ao conjunto de dados;
- mudança na ordem dos elementos do conjunto de dados;
- alteração de configuração via SetGoCBValues, onde o IED é responsável por incrementar o confRev;
- referência a um valor de DatSet já definido via SetGoCBValues.
Alterações que devem ser rastreadas para os blocos de controle SV:
- exclusão de um elemento do conjunto de dados;
- mudança na ordem dos elementos do conjunto de dados;
- alteração dos valores dos atributos MsvID, DatSet, SmpMod, SmpRate, OptFids.
Note que, para os blocos de controle SV, o incremento do confRev é afetado não apenas por alterações na configuração do conjunto de dados, mas também pelos próprios parâmetros do bloco de controle.
Alterações na configuração do conjunto de dados via serviços não são permitidas para os blocos de controle SV.
Foi adicionada uma recomendação para o passo de incremento do confRev (para os blocos de controle GOOSE e SV — tissue 1590 levanta a questão de por que uma recomendação análoga não se aplica aos blocos de controle de Relatório — esta questão ainda está em discussão): o padrão recomenda o incremento em 10.000 quando a alteração ocorre em configuradores (SCT, ICT), e em 1 quando alterado via serviços MMS.
O valor inicial do confRev não é definido pela IEC 61850, mas é especificado uma faixa inteira de 0 a 4.294.967.295.
O comportamento do confRev para os blocos de controle de Relatório e GOOSE após a reinicialização do dispositivo pode ser implementado de duas formas:
- restaurar o valor da configuração base;
- restaurar o valor da configuração no momento da reinicialização.
A implementação para um dispositivo específico deve ser especificada no PIXIT.
Para os blocos de controle SV, o confRev não deve ser redefinido na reinicialização — ele deve ser restaurado a partir da configuração pré-reinicialização.
A responsabilidade pela alteração do valor do atributo reside nos configuradores (SCT e ICT). O SCT e o ICT devem definir o valor do confRev do bloco de controle quando este é criado ou modificado, conforme definido na IEC 61850-7-2.
IEC 61850 Ed2.1
Os requisitos atualmente em vigor para o confRev são os da Edição 2.1. Eles coincidem quase inteiramente com a Edição 2, com as seguintes adições:
- para o valor reservado confRev=0 (mantido da Edição 2), foi adicionada uma clareza de que ele deve ser usado apenas para blocos de controle de Report, GOOSE ou SV que não possuem referência a conjunto de dados;
- para os blocos de controle de Report, o confRev será incrementado quando um elemento for adicionado ao conjunto de dados. No entanto, de acordo com a resposta ao tissue 673, a Edição 2 também permite o incremento do confRev quando novos elementos são adicionados ao conjunto de dados, embora a adição não esteja listada entre as alterações que acionam o incremento.
Investigação
Vamos retornar ao problema que motivou este artigo. O configurador estava correto ao recusar a importação dos blocos de controle GOOSE e SV do arquivo SCD, impedindo assim a conclusão da configuração do dispositivo?
O problema observado surgiu de uma inconsistência entre os requisitos de presença do atributo no texto do padrão e na estrutura do esquema. A validação integrada das ferramentas SCT e ICT geralmente verifica apenas a conformidade com a sintaxe SCL declarada nos esquemas XML. Como resultado, arquivos ICD sem confRev — e os arquivos SCD derivados deles, também sem confRev — passam com sucesso na validação.
No nosso tissue, propusemos tornar o confRev obrigatório para que os esquemas das Edições 2 e 2.1 estivessem alinhados com o texto do padrão e permitissem capturar erros durante a validação. A resposta recebida foi de que o atributo permanecerá opcional no esquema para manter a compatibilidade com versões anteriores entre as edições, e que a validação do configurador não deve se limitar apenas às verificações do esquema XML.
Ao trabalhar com ferramentas SCT e ICT de fabricantes russos, observamos que a maioria delas não cumpre os requisitos do padrão em relação ao confRev. Como os arquivos SCL são validados apenas contra o esquema XML — onde o confRev é opcional para GOOSE e SV — o atributo frequentemente está ausente nos blocos de controle em arquivos ICD e, consequentemente, não é adicionado pelo SCT. E quando o confRev está presente no ICD, as ferramentas deixam seu valor inalterado, o que significa que as alterações na configuração do conjunto de dados não são rastreadas.
Ao revisar outros tissues no site da base de dados tissue, notamos que ninguém havia levantado esse problema anteriormente — o que significa que colegas estrangeiros ou não encontraram esses problemas ou não os observaram. Para examinar uma implementação estrangeira, utilizamos o ICT de um fabricante bem conhecido amplamente implantado em instalações, inclusive na Rússia.
Durante a análise, foram testadas alterações nos valores de confRev reproduzindo diversos cenários operacionais e cenários provenientes dos procedimentos de teste de ICT e SCT.
Resultados
Ao criar um bloco de controle GOOSE, o ICT atribuiu um valor padrão de 1.
O valor 0 não foi utilizado porque o ICT em análise opera de acordo com a Edição 2. Também tentamos carregar um ICD sem confRev — o ICT atribuiu um valor padrão de 1.
Quando uma referência de conjunto de dados foi atribuída ao bloco de controle, confRev foi incrementado em 10.000.
Quando a referência do conjunto de dados foi removida do bloco de controle GOOSE, confRev foi novamente incrementado em 10.000.
Alterações subsequentes — reordenamento de atributos do conjunto de dados, exclusão de atributos do conjunto de dados e alteração da referência do conjunto de dados — todas causaram um incremento de 10.000 em confRev, de acordo com as recomendações da IEC 61850.
Ao tentar excluir o valor de confRev do bloco de controle, o ICT recusou-se a salvar a configuração, citando a faixa válida de 0 a 4.294.967.295.
Conclusões
Para resumir a investigação: o configurador do fabricante em nosso projeto comportou-se incorretamente ao importar o arquivo SCD. O arquivo SCD não atendia aos requisitos do padrão, mas o ICT carregou a configuração inválida sem informar ao usuário qualquer erro. O problema também foi identificado no lado do SCT, utilizado para desenvolver o arquivo — ele permitiu a criação e exportação de um arquivo que não estava em conformidade com a IEC 61850.
Para prevenir tais problemas no futuro, os desenvolvedores de SCT e ICT devem revisar como suas ferramentas lidam com o atributo confRev e se seu valor é incrementado quando:
- a referência do conjunto de dados do bloco de controle muda (modificação do atributo DatSet);
- elementos são excluídos do conjunto de dados;
- a ordem dos atributos no conjunto de dados muda;
- elementos são adicionados ao conjunto de dados.
Para blocos de controle SV, adicionalmente quando:
- os parâmetros MsvID, DatSet, SmpMod, SmpRate, OptFids mudam.
Os procedimentos de teste IEC 61850-10 para ICT e SCT, bem como os documentos Server Devices com IEC 61850-8-1 e PIXIT, especificam como as ferramentas e dispositivos devem se comportar quando a configuração do conjunto de dados de um bloco de controle muda.
Desenvolvedores de arquivos ICD e IID devem verificar a presença de confRev em blocos de controle se ele já estiver incluído no arquivo.
A Tekvel desenvolveu pacotes de software que permitem testes automatizados de conformidade de configuradores de IED (ICT) e configuradores de sistema (SCT) em relação aos requisitos da IEC 61850. Os testes de ICT e SCT são igualmente importantes quanto aos testes de conformidade de IED já estabelecidos e amplamente praticados. Tais verificações são essenciais para a implementação bem-sucedida do fluxo de engenharia proposto pela IEC 61850.
Como indicado em resposta ao nosso tecido, são necessárias ferramentas adicionais de análise de arquivos SCD — ferramentas capazes de verificar a configuração não apenas contra a estrutura XML, mas também contra os requisitos do próprio padrão. Uma dessas ferramentas é o Tekvel Inspector. O Tekvel Inspector é utilizado nos mercados russos e internacionais para revisão especializada de arquivos SCD em desenvolvimento. A ferramenta identifica não conformidades com a estrutura e o padrão, auxilia clientes finais e projetistas de SCD ao indicar áreas da configuração que exigem atenção, e fornece referências relevantes ao padrão para orientar práticas corretas de configuração. Utilizar um arquivo SCD que tenha passado por revisão especializada pelo Tekvel Inspector durante a comissionamento previne uma grande quantidade de problemas relacionados à configuração, reduzindo assim a duração dos trabalhos de comissionamento.
Também é importante enfatizar a necessidade de monitoramento contínuo dos valores do atributo confRev durante o comissionamento e a operação subsequente. Nesses estágios, quando o conjunto de dados de saída de um publicador é reconfigurado — acionando uma mudança no confRev — é fundamental estar ciente de que a alteração ocorreu. Nesse cenário, o dispositivo publicador transmitirá mensagens GOOSE/SV com um valor atualizado de confRev que difere do especificado no arquivo SCD, enquanto o assinante esperará o valor especificado nesse SCD. Nessas circunstâncias, identificar a causa raiz dos problemas de comunicação torna-se extremamente difícil, pois ambos os dispositivos foram configurados usando o mesmo arquivo SCD. Sem monitoramento contínuo das alterações, isso leva a um isolamento prolongado de falhas — e, em última análise, a prazos mais longos para comissionamento e manutenção.
A instalação do complexo de hardware e software Tekvel Park como sistema de monitoramento em uma subestação ajuda a evitar tais problemas. O monitoramento contínuo e a diagnóstico das comunicações IEC 61850 permitem que o pessoal de comissionamento e operação identifique em tempo real que a configuração de um determinado IED (dispositivo eletrônico inteligente) foi alterada. Isso melhora a observabilidade do sistema operacional e aumenta a eficiência operacional.