Pruebas funcionales de sistemas de automatización de subestaciones basados en IEC 61850
Fuente: https://electrical-engineering-portal.com/
Introducción al sistema de automatización de subestaciones
Probar la configuración de los elementos de protección de los IED y los esquemas de protección son prácticas bien establecidas cuando se prueba un sistema de Protección, Automatización y Control (PAC). Hay herramientas y métodos disponibles para admitir rutinas de prueba de protección estandarizadas y automatizadas. Se pueden crear planes de prueba para esquemas y tipos de relés específicos que se reutilizarán durante las distintas fases de un proyecto, como pruebas de aceptación de fábrica (FAT), puesta en servicio, pruebas de aceptación del sitio (SAT) y mantenimiento.
Por el contrario, la prueba del Sistema de automatización de subestaciones (SAS), que involucra muchas funciones de automatización, control y SCADA, generalmente se realiza de forma manual. Al observar el tiempo empleado durante la puesta en servicio, por ejemplo, probar el sistema de automatización y comunicación actualmente consume más tiempo que probar las funciones de protección.
Los sistemas de automatización se han vuelto cada vez más complejos y los esfuerzos para probar la comunicación, la lógica de enclavamiento y el funcionamiento adecuado de todas las señales transmitidas a los sistemas SCADA han aumentado de manera espectacular . En las subestaciones, todas las interfaces de conexión entre los IED y el equipo primario deben verificarse como parte de FAT y SAT. Para las interfaces cableadas, por ejemplo, esto generalmente se realiza una por una en un proceso manual de «marca verde» todas las interfaces en los diagramas funcionales y de cableado impresos.Para probar las funciones lógicas implementadas, como los enclavamientos de comandos, es necesario forzar muchas entradas físicas al mismo tiempo y verificar la lógica ejecutando la operación de control relacionada. Para probar la señalización SCADA, se realiza una verificación de extremo a extremo estimulando las señales directamente en el nivel del equipo en el patio de distribución o forzándolas en los terminales de entrada del IED. Por lo general, se requiere documentación adicional, como una hoja de cálculo con la señal de la unidad terminal remota (RTU) y la lista de asignaciones .
Este proceso, que se realiza preferiblemente durante FAT antes de la entrega e instalación en el sitio, requiere varias semanas para una subestación típica e involucra a varios ingenieros de control y SCADA experimentados.
Las siguientes competencias técnicas, de hardware y de software estarán disponibles para las pruebas del sistema en la fábrica:
- Idealmente, todo el SAS con todos los IED de bahía, equipos de red, puertas de enlace, HMI, etc.
- Un simulador de aparamenta cableado a los IED (pueden ser simples interruptores e indicadores LED hasta sofisticados simuladores basados en PLC),
- Simulador de centro de control compatible con el protocolo SCADA utilizado (p. Ej., IEC 60870-5-104, DNP3)
- Herramientas de prueba de red y herramientas de mantenimiento específicas del IED
- Conocimiento profundo sobre los productos de proveedores implementados, el estándar IEC 61850 y las redes Ethernet en general.
- Planes de prueba y documentación bien preparados (hoja de cálculo de señales, lógicas entrelazadas y otros procedimientos de prueba)
Por lo general, no todos los componentes del SAS están disponibles en la fábrica, por ejemplo, en los casos en los que los IED son parte de las entregas de equipos de distribución y se envían directamente al sitio de la subestación sin una prueba adecuada del sistema realizada antes. En tales casos, las pruebas deben realizarse exclusivamente en el sitio, con consecuencias en términos de esfuerzos y costos.
La experiencia práctica muestra que cuanto mejor se prueba el sistema en la fábrica, menos problemas ocurren durante la instalación y prueba en el sitio , y finalmente el proyecto es más eficiente y fluido.
Durante el procedimiento de prueba, se detectan y corrigen errores y errores en los parámetros del dispositivo, pero a veces también en el firmware del dispositivo. Pero cada actualización de la versión de firmware y cualquier cambio en la configuración del dispositivo requiere al menos una nueva prueba de la función involucrada, idealmente una nueva prueba de todo el sistema. Este proceso no es eficiente si se realizan pruebas manuales, por lo que es muy necesario un nuevo enfoque hacia pruebas de sistemas más automatizadas y eficientes.
Una solución de este tipo está disponible en la actualidad y se basa en el concepto SCL, que forma parte de la norma IEC 61850.
Tabla de contenido:
- IEC 61850 y el concepto SCL
- Nuevo enfoque de prueba SAS basado en archivos SCD
- Caso de uso práctico: ampliación de una subestación existente
- Conclusión
1. IEC 61850 y el concepto SCL
IEC 61850, el estándar internacional para redes y sistemas de comunicación para la automatización de servicios de energía, define no solo protocolos de comunicación, sino también modelos de datos para equipos de subestaciones. Además, el estándar también especifica un concepto de configuración común independiente del proveedor.
En este proceso se utiliza información de configuración legible por máquina en un formato estandarizado basado en XML: el lenguaje de configuración del sistema (SCL) .
1.1 Proceso de ingeniería SCL
El concepto SCL se define en IEC 61850-6. Su objetivo principal es permitir el intercambio de datos de configuración, de forma compatible, entre diferentes herramientas de configuración y prueba.
Figura 1 – Concepto SCL
La Figura 1 muestra el concepto general del proceso de ingeniería de un sistema de automatización de subestaciones con el uso de intercambio de datos SCL.
Los siguientes tipos de archivos SCL, con diferentes extensiones, se especifican para el intercambio de información:
SSD (Descripción de la especificación del sistema): describe el diagrama unifilar de la subestación, los niveles de voltaje, el equipo primario y los nodos lógicos (LN) necesarios para implementar las funciones de automatización de la subestación. El archivo SSD es generado por una herramienta de especificación del sistema (SST).
ICD (Descripción de la capacidad del IED): describe las capacidades funcionales de un tipo de IED. Cada tipo de IED tiene su archivo ICD relacionado. Contiene los nodos lógicos del IED, los datos y los servicios compatibles. Lo genera la herramienta de configuración de IED (ICT) específica del proveedor.
SCD (Descripción de la configuración del sistema): contiene todos los IED configurados, la configuración de comunicación y todos los aspectos IEC 61850 para un sistema determinado. Es creado por la Herramienta de configuración del sistema (SCT).
CID (Descripción del IED configurado): contiene un subconjunto del archivo SCD con toda la información relacionada con un IED específico. Se permiten extensiones privadas.
En principio, hay tres tipos de herramientas de ingeniería en este proceso: Herramienta de especificación del sistema (SST), Herramienta de configuración del sistema (SCT) y Herramienta de configuración de IED (ICT). En la práctica, a menudo se utiliza una herramienta todo en uno y sin SSD en el caso de sistemas de un solo proveedor. En instalaciones de varios proveedores con TIC específicas del proveedor, normalmente se utiliza un SCT dedicado.
Hoy en día, cada vez más usuarios comprenden la necesidad de estandarización y utilizan una SST para el proceso de especificación.El SCT permite a los ingenieros diseñar y configurar el flujo de datos de comunicación IEC 61850 en todo el sistema . Los archivos ICD de todos los IED y el archivo SSD se pueden importar al SCT. La herramienta debe permitir la configuración de las características relacionadas con IEC 61850 de los IED, la configuración de enlaces de comunicación horizontal (GOOSE y Sampled Values) y la configuración de enlaces de comunicación vertical (Informes Cliente / Servidor).
Mediante el uso de datos del archivo SSD o mediante la entrada directa, el ingeniero puede asociar las funciones del IED (nodos lógicos) al equipo y las funciones de una sola línea. En última instancia, el archivo SCD, que documenta el sistema completo, es generado por la SCT.
Volver a la tabla de contenido ↑
1.2 Contenido SCL
El lenguaje SCL en todo su alcance permite describir un modelo de la subestación que consta de tres partes básicas:
Subestación: describe el diagrama unifilar de la subestación, equipos primarios y funciones; El equipo de la subestación, como un disyuntor, está «conectado» a los nodos lógicos virtuales contenidos en el IED;
IED: describe todos los dispositivos de hardware (IED) utilizados en el sistema de automatización de la subestación. En esta parte se describe el modelo de datos implementado en el IED, incluidos sus dispositivos lógicos y nodos lógicos. Los IED están conectados al sistema de comunicación a través de sus puntos de acceso;
Comunicación: describe las conexiones lógicamente posibles entre IED en subredes mediante puntos de acceso (puertos de comunicación).
Figura 2 – Contenido SCL
El contenido de un archivo SCD completo se compone de estas tres partes más una sección con plantillas de tipos de datos que describen qué datos y atributos utilizan los IED.
Volver a la tabla de contenido ↑
1.3 Estructura de subestación y denominación funcional
La estructura de la subestación representa la arquitectura del sistema principal y describe qué funciones del equipo principal se utilizan y cómo se conecta el equipo . Los objetos de esta sección están estructurados jerárquicamente y designados de acuerdo con IEC 81346.
La Figura 3 muestra un ejemplo de un diagrama unifilar de subestación que sigue las convenciones de nomenclatura de IEC 81346 para la estructura y el equipo de la subestación, como interruptores de desconexión y disyuntores.
figura 3 – Ejemplo de topología de subestación
El propósito principal de esta sección es obtener una designación funcional clara para los nodos lógicos abstractos, que se implementan en los IED para el equipo primario en la subestación. De lo contrario, podría resultar difícil para el probador del sistema averiguar qué instancia de LN específica en el IED está «conectada» a qué elemento primario en el tablero.
Volver a la tabla de contenido ↑
1.4 Contenido y uso de archivos SCD
Como se explicó anteriormente, el archivo SCD es el archivo definitivo resultante de un diseño de sistema IEC 61850 completo. El archivo SCD no solo lo utilizan las herramientas de ingeniería y con fines de documentación, sino también las herramientas de prueba . Las herramientas de prueba pueden respaldar una prueba más eficiente, aprovechando la información del archivo SCD sobre la subestación bajo prueba.
Sin embargo, aunque el estándar define un concepto claro para el proceso de ingeniería, no define un requisito de contenido mínimo para el archivo SCD. La información de topología en la sección de la subestación, por ejemplo, es opcional. La información de la sección IED depende de las capacidades de los productos IED específicos utilizados en el proyecto.
Por lo tanto, se recomienda encarecidamente que los propietarios de activos incluyan requisitos mínimos en el archivo SCD en las especificaciones SAS utilizadas para licitaciones de proyectos y contratos de servicio, tales como:
- La sección de la subestación debe contener todos los niveles de voltaje, bahías y interruptores / seccionadores con sus referencias LN (XCBR / XSWI, CSWI y CILO)
- Los objetos de datos incluyen atributos de descripción «desc» con texto de señal según lo definido por el propietario,
- Suscripciones GOOSE utilizan <IEDName> elementos en el elemento, y el uso <Entradas> <ExtRef type =”GOOSE”> elementos
- Se deben definir RTU / Gateways o HMI, tener los Bloques de control de informes en el IED reservados y declarados utilizando <ClientLN> en el elemento <ReportControl> .
- Todos los conjuntos de datos utilizados en los informes de informes son de tipo estático (ya que los conjuntos de datos dinámicos no están documentados en el SCD)
Cuanto mejor sea la calidad y el contenido del archivo SCD de la subestación, mayor será la eficiencia de las pruebas del sistema. Un archivo SCD compatible también admite extensiones posteriores de la estación, como se describe más adelante.
Volver a la tabla de contenido ↑
2. Nuevo enfoque de prueba SAS basado en archivos SCD
2.1 Método de prueba
Como se mencionó, las pruebas de la funcionalidad de automatización y control generalmente se realizan de forma manual. Desde hace muchos años, hay herramientas disponibles que ofrecen capacidades de prueba por IED, lo que permite la prueba manual y la simulación de IED individuales.El método que se presenta aquí extiende la prueba desde la prueba y simulación de un IED hasta la prueba de todo el sistema de automatización de la subestación . La prueba se basa completamente en el archivo de configuración SCD. Al importar el archivo SCD, se puede visualizar todo el sistema y se utiliza toda la información disponible en el SCD. La información en la sección de la subestación se utiliza para colocar los IED y el equipo de conmutación dentro de sus niveles de voltaje y bahías.
Como se puede ver en la Figura 5 , el probador puede ver el sistema de una manera muy similar al diagrama unifilar o al HMI de la subestación local, con los que ya está familiarizado.
El método propuesto es adecuado para probar el SAS durante todo el ciclo de vida del proyecto, cuyas fases del proyecto se describen en IEC 61850-4 y se ilustran en la Figura 4.
La herramienta que utiliza este método debe admitir tanto el seguimiento como la simulación del sistema. Al realizar la prueba, el equipo de prueba debe tener acceso al tráfico de la red GOOSE y una conexión MMS a los IED.
Figura 4 – Ciclo de vida SAS
Durante la fase de especificación, el archivo SCD, las señales y los servicios de comunicación se pueden validar sin necesidad de ningún dispositivo físico. Posteriormente, se pueden realizar pruebas de puertas de enlace SCADA y HMI simulando el comportamiento de comunicación y las señales de todos los IED, nuevamente sin ningún IED real. Durante la FAT, los IED que aún no están presentes se pueden simular para probar los que ya están disponibles.
A medida que el proyecto pasa a la etapa de puesta en servicio, se realizan más controles y pruebas de los IED reales en lugar de la simulación.
Uno de los factores clave para un enfoque eficiente es la opción de crear planes de prueba . Un procedimiento de prueba puede documentarse y reutilizarse durante todo el ciclo de vida de SAS. Las secuencias de prueba se pueden realizar y evaluar automáticamente.
Volver a la tabla de contenido ↑
2.2 Pruebas funcionales SAS con StationScout
StationScout es la solución de prueba innovadora para subestaciones IEC 61850 que proporciona las características de prueba requeridas como se describió anteriormente. StationScout simplifica las pruebas para SAS y reduce significativamente el esfuerzo de prueba requerido . Viene con un hardware robusto y potente que permite a los usuarios simular varios IED con un aislamiento seguro de las redes SAS.
Este software fácil de usar ayuda a visualizar archivos SCL o señales de rastreo dentro de la subestación sin ningún esfuerzo de configuración.
Figura 5 – Ejemplo SCL cargado en StationScout
En las siguientes secciones se analizan algunos casos de uso práctico de StationScout relacionados con la resolución de problemas y las pruebas de SAS.
Volver a la tabla de contenido ↑
2.3 Verificación de enlaces de comunicación
Al cargar el archivo SCD y tener acceso al tráfico de red y la conexión MMS a los IED, StationScout puede validar automáticamente todos los enlaces de comunicación GOOSE, Sampled Values y Report. El conjunto de prueba puede sondear atributos en los IED y validarlos con el modelo. El usuario puede comprobar, por ejemplo, si los Bloques de control de informes están habilitados actualmente y si los Propietarios de los informes son los Clientes declarados en el archivo SCD.
Los enlaces de comunicación de GOOSE se verificarán automáticamente para:
- Discrepancia de GOOSE en el lado del remitente: verificando la configuración del Bloque de control;
- Errores de publicación de GOOSE: husmeando en la red y comparándola con SCD;
- Errores de suscripción de GOOSE: verificando los estados de LGOS en cada IED suscrito. También se comprueban las discrepancias.
La Figura 6 ilustra un ejemplo en el que el GOOSE publicado por un IED se verifica en la red, pero StationScout identifica un problema en uno de los suscriptores debido a una discrepancia en la revisión de la configuración . El enlace de conexión está resaltado en amarillo y se muestran señales de advertencia para indicar el problema.
Figura 6 – Verificación de los enlaces de suscriptores y editores de GOOSE
Volver a la tabla de contenido ↑
2.4 Prueba de lógicas de enclavamiento
PLC Logic se implementa en la mayoría de los IED para cubrir las funciones de control y automatización. Se pueden probar automáticamente mediante la simulación de las entradas de la lógica (ya sea mediante simulación de IED o el estado real de la aparamenta) y la evaluación de los resultados de los cálculos lógicos con StationScout. Un ejemplo de aplicación es el uso de lógicas para esquemas de enclavamiento para asegurar el funcionamiento adecuado de los interruptores de desconexión y puesta a tierra .
Para representar el resultado de las condiciones lógicas de enclavamiento, IEC 61850 define el estado del relé en el nodo lógico CILO. Para las pruebas, se puede probar un subconjunto o, idealmente, todas las combinaciones posibles de entradas, y la salida lógica se puede evaluar leyendo automáticamente los valores de estado de CILO.
Figura 7 – Prueba de esquemas de enclavamiento: lógica de enclavamiento y definición de pasos de prueba en hoja de cálculo
Figura 8 – Resultados de la prueba de enclavamiento después de la ejecución con StationScout
Volver a la tabla de contenido ↑
2.5 Solución de problemas mediante el seguimiento de señales
Hay múltiples transferencias de mensajes y señales dentro de un sistema SAS. Una señal pasa por varios pasos hasta que llega al centro de control. Si hay un error en esta comunicación, el ingeniero de puesta en servicio debe seguir la señal en su camino a través del SAS. Encontrar estos errores de señal puede llevar mucho tiempo.
Con StationScout es posible seguir cómo se propagan las señales a través del SAS .
Figura 9 – Posición del interruptor transmitida por SAS
Volver a la tabla de contenido ↑
2.6 Prueba de la configuración de RTU / Gateway y HMI local
Las puertas de enlace, las RTU y las HMI locales suelen comunicarse con casi todos los IED del sistema, principalmente a través de informes, pero también de GOOSE. Normalmente, es necesario probar varios miles de señales por subestación. Durante la puesta en servicio, al menos las señales más críticas se prueban punto a punto estimulando la señal en el patio de distribución. Todas las demás señales pueden ser simuladas por StationScout.
Se puede construir un plan de prueba con StationScout simulando todos los IED y señales de la subestación para una verificación rápida si la RTU y las puertas de enlace están configuradas correctamente.Las puertas de enlace / RTU, HMI y otros IED en general suelen estar expuestos a actualizaciones de firmware y parches de seguridad durante su vida útil . Esos dispositivos se pueden volver a probar fácilmente después de la actualización (verificación de cordura) ejecutando el plan de prueba que ya estaba preparado para ese dispositivo antes de que vuelva a funcionar.
Esas pruebas se pueden realizar en la subestación con todos los demás IED simulados por StationScout sin afectar a los dispositivos en funcionamiento.
Volver a la tabla de contenido ↑
3. Caso de uso práctico: Ampliación de una subestación existente
Para una importante subestación interior de 20 kV con alrededor de 55 IED, 3 barras colectoras y dos secciones de barra en un gran complejo industrial , el propietario decidió ampliar la subestación existente con varios compartimentos adicionales. La subestación se puso en servicio hace unos 10 años con un moderno sistema PAC basado en IEC 61850. Debido a las limitaciones operativas, la ampliación debe realizarse sin desenergizar y durante el funcionamiento de la subestación.Los enclavamientos de comando se han implementado mediante funciones de PLC en los IED y GOOSE se utiliza para el intercambio de las señales relevantes entre los IED. Los enclavamientos relacionados con la bahía se implementan en el dispositivo de bahía respectivo. Además, un IED de enclavamiento de estación dedicado calcula los enclavamientos de toda la estación (Figura 10).
Para darse cuenta de esto, los dispositivos de bahía envían sus posiciones de interruptor y otra información a través de GOOSE al IED de enclavamiento, que calcula información topológica como «barra colectora 1 conectada a tierra» y envía esta información nuevamente a través de GOOSE a los dispositivos de bahía, donde se libera el comando final se calculan. Ventaja: si falla el dispositivo central, los enclavamientos relacionados con la bahía permanecen disponibles.
Y lo más importante: los IED de bahía existentes no se ven afectados en caso de ampliaciones de la subestación.
Figura 10 – Diagrama del sistema principal del SAS (gris… alcance del proyecto de extensión)
Esta forma de implementación permite la extensión posterior sin volver a probar las bahías existentes y, cuando se utilizan herramientas de prueba modernas como StationScout, también durante la operación.
Volver a la tabla de contenido ↑
3.1 Prueba de fábrica de los nuevos IED
Como la mayoría de los IED ya están en funcionamiento, los IED de las nuevas bahías no se pudieron probar en fábrica junto con los IED existentes y los dispositivos de nivel de estación. Por lo tanto, el propietario decidió realizar la prueba de los nuevos IED con un IED de enclavamiento de repuesto y el resto de la subestación para ser simulada por StationScout (Figura 11).
Al principio, el ingeniero importó el archivo SCD existente a una nueva base de datos del proyecto, agregó los nuevos IED, actualizó el IED de enclavamiento central, la HMI y las puertas de enlace para incorporar las nuevas bahías y finalmente creó un nuevo archivo SCD de todo el subestación (existente + ampliación).
Los IED de protección y control de bahía existentes no se vieron afectados y no se cargarán con nuevos archivos de parámetros.
Figura 11 – Configuración de prueba de los nuevos IED en fábrica
Para la operación de apertura / cierre de cada seccionador en las nuevas bahías, se han definido casos de prueba con> 50 pasos de prueba como una tabla de permutación en una hoja de cálculo ( Figura 7 ) y se han implementado en StationScout. Los casos de prueba se han creado solo una vez para una bahía típica y se han copiado fácilmente para las demás. Finalmente, esos pasos de prueba se han ejecutado mediante la simulación de los IED existentes y la evaluación de los objetos de datos CILO relevantes en los nuevos IED (Figura 11).
De esta manera, se ha verificado la correcta implementación del esquema de enclavamiento en el IED de enclavamiento central, así como en los nuevos IED de bahía.
Volver a la tabla de contenido ↑
3.2 Prueba de las pasarelas actualizadas
Una segunda parte del proyecto de extensión implica la actualización de las pasarelas existentes con el último hardware y firmware de CPU por razones de ciberseguridad . Teniendo en cuenta la extensa evolución del hardware y el firmware durante los últimos 10 años, se recomendó una nueva prueba completa de alrededor de 2.000 señales desde los IED al Centro de control después de la actualización.
Como la estación está equipada con puertas de enlace redundantes, una de las dos puertas de enlace se puede desconectar de la LAN de la estación sin interrumpir el control remoto desde el centro de control. Cada puerta de enlace se actualizará y se realizará una prueba de señal completa simulando todos los informes y señales SCADA con StationScout, verificando el correcto funcionamiento de la puerta de enlace hasta el centro de control.
Volver a la tabla de contenido ↑
4. Conclusión
Se presentó un enfoque de prueba innovador para probar la comunicación, la automatización, el control y la parte SCADA del sistema SAS, que se basa en la información del archivo SCD. Ahora se pueden crear planes de prueba para automatizar los procedimientos de prueba y documentación que han consumido mucho tiempo hasta ahora.
Los planes de prueba automatizados también permiten una nueva prueba rápida después de los parches de seguridad y las actualizaciones de firmware, que se realizan con bastante frecuencia en la actualidad. Las pruebas se están convirtiendo en una parte integral del sistema y evolucionan rápidamente hacia una función de supervisión y monitoreo.
Acerca de los autores
Christian Brauner
OMICRON electronics GmbH, AustriaChristian Brauner tiene un título de ingeniero en el campo de la electrónica y la tecnología de la comunicación. Durante 30 años se dedicó a fabricantes de automatización de subestaciones, protección y sistemas SCADA. Comenzó como experto técnico en ventas en Austria con VA TECH SAT (ahora Siemens), luego trabajó como gerente de ventas con SPRECHER AUTOMATION. Ha estado involucrado en una variedad de proyectos relacionados con IEC 61850 y contratos marco para grandes empresas de servicios públicos en toda Europa. Desde 2018 trabaja en OMICRON Austria como director de desarrollo de ventas. Su enfoque especial está en las soluciones de prueba y monitoreo para sistemas de automatización de subestaciones.
Eugenio Carvalheira
OMICRON Electronics Corp., EE. UU.Eugenio Carvalheira recibió su B.Sc. en Ingeniería Eléctrica en la UFPE en Brasil y su M.Sc. en Ingeniería Computacional en la Universidad de Erlangen en Alemania. Tiene más de 18 años de experiencia en el diseño y puesta en servicio de sistemas de protección, automatización y control de sistemas eléctricos. Se incorporó a OMICRON en 2008 como ingeniero de aplicaciones y actualmente es director de ingeniería para América del Norte con sede en Houston, TX. También es un miembro activo de los grupos de trabajo de IEEE PSRC.
Los comentarios están cerrados.