Basado en nuestras observaciones, 8 de cada 10 configuradores no reconocen completamente la configuración de los archivos SCD. Recientemente nos encontramos con un caso interesante de importación incorrecta que nos llevó a escribir tissue 1791.
Antecedentes
Para uno de nuestros proyectos que incluía 43 IED (intelligent electronic devices, dispositivos electrónicos inteligentes), desarrollamos un archivo SCD (Substation Configuration Description, descripción de la configuración de la subestación). El equipo descrito en el archivo incluía convertidores de señales analógicas, convertidores de señales discretas, terminales de relés de protección y automatización, y controladores de bayas de 8 fabricantes diferentes. Al desarrollar el archivo SCD, tuvimos en cuenta las especificidades de configuración de los dispositivos de cada fabricante para garantizar la compatibilidad y una configuración unificada durante la puesta en marcha.
Durante la importación del archivo SCD y su reconocimiento por los configuradores de IED (ICT), se detectó que los dispositivos de un fabricante no podían suscribirse a mensajes GOOSE y flujos de Valores Muestreados (SV). La funcionalidad estaba ausente porque los bloques de control configurados no se mostraban al importar las configuraciones de los dispositivos publicadores. El archivo desarrollado pasó la validación contra la sintaxis SCL sin errores, y el ICT no emitió ninguna señal de problemas durante la importación. Como se descubrió, la razón por la cual los bloques de control no se mostraban era la ausencia del atributo confRev en los bloques de control del dispositivo publicador dentro del archivo SCD. En este artículo, investigaremos por qué el ICT del fabricante no mostró la configuración y si tal comportamiento es correcto.
¿Qué es el atributo confRev y para qué sirve?
confRev es un atributo que indica el número de veces que la configuración del conjunto de datos referenciado por el atributo DatSet de un bloque de control ha sido modificada. Este atributo es requerido para la sincronización de configuración entre el publicador y el suscriptor; su valor actual se incluye en el mensaje GOOSE publicado y en el flujo SV.
Si un suscriptor recibe un marco en el que el valor de confRev difiere del valor esperado basado en la configuración cargada, esto indica una discrepancia entre la versión de configuración del publicador y la real. Si el suscriptor verifica este atributo puede determinarse a partir del documento PIXIT del dispositivo.
En el PIXIT en consideración, se indica que el suscriptor verifica el valor de confRev. Por lo tanto, si difiere del valor esperado, las señales del mensaje entrante no serán procesadas. Este atributo proporciona así una forma de proteger el dispositivo receptor de interpretar incorrectamente las señales de entrada.
Evolución de confRev
Desde la publicación de la Edición 1 de IEC 61850 hasta la actual Edición 2.1, los requisitos que describen el papel funcional del atributo confRev se han formalizado progresivamente — cambios que contribuyeron directamente al problema que encontramos.
IEC 61850 Ed1
En la primera edición de IEC 61850, confRev se define como el número de revisión de la configuración del bloque de control. Este atributo es obligatorio para los bloques de control de informes y opcional para los bloques de control GOOSE y SV.
Para los bloques de control de informes, confRev debe incrementarse cuando se elimina un elemento del conjunto de datos o cambia el orden de los elementos.
El valor inicial de confRev no está especificado por la norma. El valor 0 está reservado.
El valor de confRev no debe restablecerse a su valor inicial tras el reinicio del dispositivo.
IEC 61850 Ed2
Con la publicación de la Edición 2, la formalización del atributo confRev se amplió y revisó parcialmente.
confRev ahora se define como un atributo que refleja el número de veces que la configuración del conjunto de datos referenciado por el atributo DatSet ha sido modificada.
La diferencia clave respecto a la Edición 1 es que confRev se convierte en obligatorio para los bloques de control GOOSE y SV en el cuerpo de la norma. Sin embargo, en la definición del esquema XML de la Edición 2, confRev para los bloques de control GOOSE y SV sigue siendo opcional.
Las condiciones que requieren el incremento del atributo fueron formalizadas.
Cambios que deben rastrearse para los bloques de control de informes:
- eliminación de un elemento del conjunto de datos;
- cambio en el orden de los elementos del conjunto de datos;
- configuración del conjunto de datos mediante el servicio SetBRCBValues que cambia el valor del atributo DatSet.
Cambios que deben rastrearse para los bloques de control GOOSE:
- eliminación de un elemento del conjunto de datos;
- adición de un elemento al conjunto de datos;
- cambio en el orden de los elementos del conjunto de datos;
- cambio de configuración mediante SetGoCBValues, donde el IED es responsable de incrementar confRev;
- referencia a un valor DatSet ya establecido mediante SetGoCBValues.
Cambios que deben rastrearse para los bloques de control SV:
- eliminación de un elemento del conjunto de datos;
- cambio en el orden de los elementos del conjunto de datos;
- cambio en los valores de los atributos MsvID, DatSet, SmpMod, SmpRate, OptFids.
Cabe destacar que, para los bloques de control SV, el incremento de confRev se ve afectado no solo por cambios en la configuración del conjunto de datos, sino también por los propios parámetros del bloque de control.
No se permiten cambios en la configuración del conjunto de datos mediante servicios para los bloques de control SV.
Se añadió una recomendación para el paso de incremento de confRev (para los bloques de control GOOSE y SV — tissue 1590 plantea la pregunta de por qué una recomendación análoga no se aplica a los bloques de control de informes — esta cuestión sigue en discusión): la norma recomienda incrementar en 10.000 cuando el cambio se produce en configuradores (SCT, ICT), y en 1 cuando se realiza mediante servicios MMS.
El valor inicial de confRev no está establecido por IEC 61850, pero se especifica un rango entero de 0 a 4.294.967.295.
El comportamiento de confRev para los bloques de control de informes y GOOSE tras el reinicio del dispositivo puede implementarse de dos formas:
- restablecer el valor desde la configuración base;
- restablecer el valor desde la configuración existente en el momento del reinicio.
La implementación para un dispositivo específico debe indicarse en el PIXIT.
Para los bloques de control SV, confRev no debe restablecerse al reiniciar; debe restaurarse desde la configuración previa al reinicio.
La responsabilidad de cambiar el valor del atributo recae en los configuradores (SCT e ICT). SCT e ICT deben establecer el valor de confRev del bloque de control cuando se crea o modifica, según se define en IEC 61850-7-2.
IEC 61850 Ed2.1
Los requisitos actualmente vigentes para confRev son los de la Edición 2.1. Coinciden casi completamente con la Edición 2, con las siguientes adiciones:
- para el valor reservado confRev=0 (heredado de la Edición 2), se añadió una aclaración de que solo debe usarse para bloques de control Report, GOOSE o SV que no tengan referencia a un conjunto de datos;
- para los bloques de control Report, confRev se incrementará cuando se añada un elemento al conjunto de datos. Sin embargo, según la respuesta a tissue 673, la Edición 2 también permite incrementar confRev cuando se añaden nuevos elementos al conjunto de datos, aunque esta adición no se incluye entre los cambios desencadenantes.
Investigación
Volvamos al problema que motivó este artículo. ¿Estaba correcto el configurador al negarse a importar los bloques de control GOOSE y SV del archivo SCD, impidiendo así la finalización de la configuración del dispositivo?
El problema observado surgió de una inconsistencia entre los requisitos de presencia del atributo en el texto del estándar y en la esquema. La validación integrada de las herramientas SCT e ICT suele verificar únicamente la conformidad con la sintaxis SCL declarada en los esquemas XML. Como resultado, los archivos ICD sin confRev — y los archivos SCD derivados de ellos, también sin confRev — pasan la validación con éxito.
En nuestro tissue, proponemos hacer obligatorio confRev para que los esquemas de la Edición 2 y 2.1 coincidan con el texto del estándar y permitan detectar errores durante la validación. La respuesta que recibimos fue que el atributo permanecerá opcional en el esquema para mantener la compatibilidad hacia atrás entre ediciones, y que la validación del configurador no debe limitarse únicamente a las comprobaciones de esquema XML.
Al trabajar con herramientas SCT e ICT de fabricantes rusos, observamos que la mayoría no cumplen con los requisitos del estándar respecto a confRev. Dado que los archivos SCL se validan solo contra el esquema XML — donde confRev es opcional para GOOSE y SV — el atributo a menudo falta en los bloques de control de los archivos ICD y no se añade posteriormente en el SCT. Y cuando confRev está presente en el ICD, las herramientas dejan su valor sin cambios, lo que significa que los cambios en la configuración del conjunto de datos pasan completamente desapercibidos.
Al revisar otros tissues en el sitio web de la base de datos tissue, notamos que nadie había planteado previamente este problema — lo que significa que los colegas extranjeros o bien no han encontrado estos problemas o bien no les han prestado atención. Para examinar una implementación extranjera, utilizamos el ICT de un fabricante conocido ampliamente desplegado en instalaciones, incluyendo en Rusia.
Durante el análisis, se probaron los cambios en el valor de confRev reproduciendo varios escenarios operativos y escenarios de los procedimientos de prueba de ICT y SCT.
Resultados
Al crear un bloque de control GOOSE, el ICT asignó un valor predeterminado de 1.
El valor 0 no se utilizó porque el ICT en revisión opera según la Edición 2. También probamos cargar un ICD sin confRev; el ICT asignó un valor predeterminado de 1.
Cuando se asignó una referencia de conjunto de datos al bloque de control, confRev se incrementó en 10,000.
Cuando se eliminó la referencia de conjunto de datos del bloque de control GOOSE, confRev se incrementó nuevamente en 10,000.
Cambios posteriores — reordenamiento de atributos del conjunto de datos, eliminación de atributos del conjunto de datos y cambio de la referencia del conjunto de datos — provocaron que confRev se incrementara en 10,000, de acuerdo con las recomendaciones de IEC 61850.
Al intentar eliminar el valor de confRev del bloque de control, el ICT se negó a guardar la configuración, citando el rango válido de 0 a 4,294,967,295.
Conclusión
Para resumir la investigación: el configurador del fabricante en nuestro proyecto actuó incorrectamente al importar el archivo SCD. El archivo SCD no cumplía con los requisitos del estándar, sin embargo, el ICT cargó la configuración inválida sin informar al usuario sobre ningún error. El problema también se detectó en el lado de la SCT, que se utilizó para desarrollar el archivo; permitió la creación y exportación de un archivo que no cumplía con IEC 61850.
Para prevenir estos problemas en el futuro, los desarrolladores de SCT y ICT deben revisar cómo sus herramientas manejan el atributo confRev y si su valor se incrementa cuando:
- cambia la referencia de conjunto de datos del bloque de control (modificación del atributo DatSet);
- se eliminan elementos del conjunto de datos;
- cambia el orden de los atributos en el conjunto de datos;
- se agregan elementos al conjunto de datos.
Para los bloques de control SV, adicionalmente cuando:
- cambian los parámetros MsvID, DatSet, SmpMod, SmpRate, OptFids.
Los procedimientos de prueba IEC 61850-10 para ICT y SCT, así como los documentos de Servidores con IEC 61850-8-1 y PIXIT, especifican cómo deben comportarse las herramientas y dispositivos cuando cambia la configuración del conjunto de datos de un bloque de control.
Los desarrolladores de archivos ICD e IID deben verificar la presencia de confRev en los bloques de control si ya está incluido en el archivo.
Tekvel ha desarrollado paquetes de software que permiten pruebas de conformidad automatizadas de los configuradores de EID (ICT) y configuradores de sistemas (SCT) frente a los requisitos de IEC 61850. La prueba de ICT y SCT es igualmente importante que la prueba de conformidad de EID ya establecida y ampliamente utilizada. Estas verificaciones son esenciales para la implementación exitosa del flujo de ingeniería propuesto por IEC 61850.
Como se indicó en respuesta a nuestro tissue, se requieren herramientas adicionales de análisis de archivos SCD: herramientas capaces de verificar la configuración no solo contra la estructura XML, sino también contra los requisitos del estándar. Una de estas herramientas es Tekvel Inspector. Tekvel Inspector se utiliza en los mercados rusos e internacionales para la revisión experta de archivos SCD en desarrollo. La herramienta identifica incumplimientos con respecto a la estructura y al estándar, ayuda a los clientes finales y a los diseñadores de SCD al señalar áreas de la configuración que requieren atención, y proporciona referencias al estándar correspondiente para guiar las prácticas correctas de configuración. Utilizar un archivo SCD que haya pasado la revisión experta mediante Tekvel Inspector durante la puesta en marcha previene una gran cantidad de problemas relacionados con la configuración, reduciendo así la duración de los trabajos de puesta en marcha.
También es importante destacar la necesidad de monitoreo continuo de los valores del atributo confRev durante la puesta en marcha y la operación posterior. En estas etapas, cuando el conjunto de datos saliente de un publicador se reconfigura —lo que provoca un cambio en confRev—, es fundamental estar al tanto de que dicho cambio ha ocurrido. En tal escenario, el dispositivo publicador transmitirá mensajes GOOSE/SV con un valor actualizado de confRev que difiere del especificado en el archivo SCD, mientras que el suscriptor esperará el valor indicado en ese SCD. Bajo estas circunstancias, identificar la causa raíz de los problemas de comunicación se vuelve extremadamente difícil, ya que ambos dispositivos fueron configurados utilizando el mismo archivo SCD. Sin un monitoreo continuo de los cambios, esto conduce a una aislamiento prolongado de fallas —y, en última instancia, a duraciones más largas en la puesta en marcha y mantenimiento generales.
La instalación del complejo de hardware y software Tekvel Park como sistema de monitoreo en una subestación ayuda a evitar tales problemas. El monitoreo continuo y la diagnóstico de las comunicaciones IEC 61850 permiten al personal de puesta en marcha y operación identificar en tiempo real que la configuración de un IED específico ha cambiado. Esto mejora la observabilidad del sistema operativo y aumenta la eficiencia operativa.