Si se intentara elegir el único tema que se manifestó con mayor claridad en la zona de exposición de CIGRE 2026 en París, para nosotros fue la virtualización de la protección.
Y ya no se trata de un único producto experimental ni de un bonito concepto en diapositivas. A lo largo de unas horas recorriendo la feria, encontramos este tema en los estands de ABB, Siemens, Moxa, Welotec, Kalkitech y otros. Unas empresas ofrecen directamente funciones de protección virtualizadas, otras los servidores en los que esas funciones deben ejecutarse, y otras más ensamblan, a partir de componentes de distintos fabricantes, arquitecturas multifabricante prácticamente listas.
Y cuanto más hablábamos con los representantes de las empresas, más evidente se hacía: la pregunta clave aquí ya no es «¿se puede ejecutar la protección en una máquina virtual?». Por supuesto que sí. Mucho más interesante es otra pregunta: ¿quién define ahora la arquitectura de hardware y responde por la fiabilidad de toda esa plataforma de cómputo?
ABB: la protección se separa definitivamente del «hierro»
Una de las primeras paradas fue el estand de ABB.
La protección centralizada no es nueva para ABB. Desde hace varios años su cartera incluye el SSC600 — un dispositivo en el que las funciones de protección y control, tradicionalmente distribuidas entre los terminales de cada bahía, se centralizan a nivel de subestación.
El siguiente paso fue el SSC600 SW. En este caso, de la plataforma de hardware dedicada de ABB queda ya solo la implementación de software. ABB describe oficialmente el SSC600 SW como un producto puramente de software, entregado como máquina virtual y destinado a funcionar en entornos KVM y VMware; el cliente puede usar la plataforma de hardware que elija.
Precisamente la conversación con los representantes de ABB resultó especialmente interesante.
La lógica de suministro es más o menos así: la imagen de software para el despliegue en una máquina virtual puede obtenerse por separado, y la funcionalidad necesaria se activa luego mediante licencia. Según los representantes de la empresa en el estand, se prepara también una versión para usar en la plataforma abierta SEAPATH.
Pero lo más importante no fue ni siquiera eso.
ABB se abstrae casi por completo de cómo exactamente el cliente construirá la infraestructura de cómputo. La empresa está dispuesta a formular los requisitos de rendimiento del servidor según el número y la composición de las funciones implementadas, pero la elección de la arquitectura de hardware concreta queda a cargo del integrador de sistemas y del cliente.
Es más, preguntamos aparte si hay restricciones de principio para alojar otras aplicaciones en el mismo servidor físico. La respuesta fue negativa. En máquinas virtuales vecinas podrían funcionar, por ejemplo, SCADA, un controlador de comunicaciones e incluso funciones de protección virtualizadas de otros fabricantes.
Y aquí aparece la otra cara de la independencia de hardware.
A la pregunta de cómo debe construirse exactamente una arquitectura de servidor tolerante a fallos no obtuvimos una respuesta inequívoca. La redundancia de los nodos de cómputo, la arquitectura de disponibilidad continua/alta, el comportamiento ante el fallo de un servidor físico — todo esto ya no está dentro del producto de ABB, sino que se convierte en objeto del diseño del sistema en su conjunto.
Se trata de un cambio bastante fundamental en la frontera de la responsabilidad.
En un terminal de protección tradicional, el desarrollador del dispositivo controla el procesador, el sistema operativo, las interfaces de hardware y buena parte de los mecanismos de garantía de la fiabilidad. En el mundo virtualizado, el fabricante proporciona las funciones de protección como software más los requisitos del entorno de ejecución. Y la tolerancia a fallos de toda la plataforma la tiene que diseñar ya el integrador, conforme a los requisitos del cliente final. De hecho, el cliente aquí ya puede definir una plataforma de hardware estándar — y no solo de hardware, sino también de software, en lo relativo al entorno de despliegue de las máquinas virtuales, su número, etcétera.
Otro exponente interesante de ABB completaba bien este cuadro — el compacto REX600, que recibe señales de transductores de medida de baja potencia y desempeña funciones de convertidor de señales analógicas. El dispositivo también puede desempeñar funciones locales de protección de respaldo. ABB lo posiciona como un elemento integrable con el SSC600 y el SSC600 SW; admite, entre otros, IEC 61869-9 e IEC 61869-13.
El resultado es una arquitectura muy característica: junto al equipo primario queda una interfaz de proceso relativamente sencilla, mientras que las principales funciones de cómputo se trasladan a una plataforma centralizada.
Moxa: si la protección se ha vuelto software, ¿dónde va a funcionar?
De los representantes de ABB obtuvimos los nombres de dos fabricantes de plataformas de hardware ya usadas o consideradas por los clientes para tales tareas: Moxa y Welotec.
Por eso, la siguiente parada fue, con toda naturalidad, el estand de Moxa.
Y prácticamente en el centro de la exposición se encontraba, en efecto, el DA-920E — un nuevo servidor sin refrigeración activa (de tipo sin ventiladores), posicionado por la empresa específicamente como plataforma para Virtual Protection, Automation and Control — vPAC.
Esto ya no es un ordenador industrial corriente. El DA-920E viene en formato 2U y cumple los requisitos de IEC 61850-3, IEEE 1613 e IEC 60255. En su núcleo, un Intel Xeon D-1834 con 8 núcleos y 16 hilos; admite hasta 256 GB de ECC RAM, cuatro SSD de 2,5 pulgadas con RAID y una unidad NVMe aparte, además de expansión PCIe. Moxa vincula directamente este producto con la transición a la protección virtualizada.
Aquí se percibe especialmente bien la formación de un nuevo mercado.
El fabricante de protección ya no tiene por qué desarrollar su propio bloque de cómputo dedicado. Aparecen plataformas de hardware independientes, diseñadas justamente para la explotación directamente en instalaciones eléctricas.
Es decir, el movimiento no va del equipo dedicado directamente a un servidor corriente de centro de datos. Más bien se forma una clase intermedia de dispositivos: arquitectura x86 estándar, pero en una ejecución diseñada para el entorno electromagnético y las condiciones de operación de una subestación.
Sin embargo, el exponente más inusual de Moxa para nosotros no fue el servidor.
En el estand mostraban un prototipo de receptor GNSS/GPS construido en formato SFP. Al pequeño módulo se conecta una antena externa, tras lo cual se instala directamente en la ranura SFP de un conmutador compatible. La idea es que tal módulo permite al propio conmutador actuar como fuente de tiempo preciso y PTP Grandmaster, sin un servidor de tiempo separado.
Para subestaciones pequeñas la idea resulta extraordinariamente atractiva: el dispositivo de sincronización separado literalmente «colapsa» en un módulo SFP.
Pero por ahora es justamente un prototipo. Y si se convierte en un producto real, la pregunta principal ya no será su impresionante formato, sino la madurez de la implementación. ¿Con qué flexibilidad se configurarán los perfiles PTP? ¿Cómo se comportará el dispositivo ante la pérdida de GNSS? ¿Cómo se producirá el restablecimiento de la sincronización? ¿Con qué estabilidad funcionará en distintos regímenes transitorios?
Es el caso en que una idea de ingeniería muy hermosa todavía tiene que demostrar su aptitud para la explotación real.
Welotec: toda la arquitectura en un solo armario
En el estand de Welotec vimos ya no un elemento aislado, sino una demostración prácticamente montada de cómo puede verse una protección virtual multifabricante.
En la base estaba el RSAPC Mk2 — Rugged Substation Automation Computer. También es un servidor 2U de ejecución para subestación, sin ventiladores, con IEC 61850-3 e IEEE 1613. En la configuración máxima se usa un Intel Xeon W con 8 núcleos y 16 hilos; el rango de temperatura declarado es de −40 a +70 °C. Welotec ofrece para esta plataforma distintos entornos operativos, incluidos VMware ESXi, Red Hat Enterprise Linux Real Time y, lo que es especialmente interesante, una preinstalación de LF Energy SEAPATH.
Pero mucho más importante que las características del servidor era la propia arquitectura de demostración.
Sobre una única infraestructura se combinaron componentes de varios fabricantes. Como plataforma de virtualización actuaba SEAPATH, como protección virtualizada se demostraba una solución de ABB, y al lado funcionaba la SCADA/HMI zenon de COPA-DATA. La infraestructura de red la representaba Westermo, y la sincronización de tiempo — entre otros, equipo de Hopf.
De hecho, el rótulo «Multi Vendor vPAC Demo Setup» en el estand de Welotec resultó una de las imágenes más elocuentes de toda la feria.
Muestra el cambio principal: la automatización de subestaciones potencialmente deja de ser un conjunto de dispositivos acabados de fabricantes individuales y se convierte en un sistema de cómputo integrable.
El servidor puede fabricarlo una empresa. El hipervisor o la plataforma de virtualización — otro ecosistema. Los dispositivos de protección virtualizados — un tercero. La SCADA — un cuarto.
La libertad aumenta considerablemente.
Pero, al mismo tiempo, se vuelve mucho más difícil responder a la pregunta: ¿quién responde por el resultado en su conjunto?
La presencia de dos fuentes de alimentación, RAID, PRP/HSR o interfaces de red redundantes no significa por sí misma la tolerancia a fallos de un sistema de protección virtualizado. Hay que definir los posibles dominios de fallo, la estrategia de redundancia de los nodos de cómputo, el tiempo admisible de restablecimiento de las funciones, el comportamiento de las máquinas virtuales ante fallos y los requisitos de actualización del software de infraestructura.
En otras palabras, la virtualización traslada buena parte de la complejidad de ingeniería del IED individual al nivel de la arquitectura del sistema.
Kalkitech: el siguiente paso — la subestación definida por software
En el estand de Kalkitech nos topamos de nuevo con el mismo tema, pero aquí se formuló aún más ampliamente — Software Defined Substation (subestación definida por software).
En la arquitectura de demostración se usaba la plataforma de servidor SYNC, un bare-metal hypervisor y varias máquinas virtuales. En el diagrama, una al lado de otra, había funciones de protección virtuales, incluido el propio Kalkitech VPR y el SSC600 SW de ABB, y por encima — otras aplicaciones de automatización.
Kalkitech desarrolla desde hace bastante tiempo el concepto de Virtual Protection Relay y ofrece su propio IEC 61850 VPR Framework. Incluye suscripción a Sampled Values, MMS, GOOSE, configuración SCL, reference protection functions e interfaces para conectar algoritmos de terceros.
Y si en el estand de ABB hablábamos ante todo de la virtualización de la protección, Kalkitech plantea una pregunta más amplia: si la protección ya puede ser aplicación, ¿por qué SCADA, gateway, HMI, monitoreo y otras funciones deben permanecer obligatoriamente como dispositivos físicos separados?
Tras cuatro estands distintos — ABB, Moxa, Welotec y Kalkitech — la coincidencia ya es difícil de considerar casual. En torno a la protección virtualizada empieza a formarse un ecosistema tecnológico pleno.
Siemens: virtualización — sí, pero bajo el control del fabricante
En este contexto, el enfoque de Siemens resulta especialmente interesante.
La empresa también demuestra protección virtualizada — el SIPROTEC V, que usa los algoritmos probados del SIPROTEC 5. Siemens declara escalabilidad de hasta 60 IED virtuales en una única plataforma de cómputo.
Sin embargo, el modelo comercial difiere notablemente del enfoque de ABB.
Siemens también usa el término «hardware independent», pero la independencia de hardware aquí está limitada a una lista de plataformas de servidor de ejecución para subestación aprobadas, o whitelisted. Es más, Siemens habla directamente de un «packaged approach»: al cliente se le pretende suministrar un hardware/software bundle, en el que SIPROTEC V y el sistema operativo ya vienen preinstalados en equipo validado.
Y esta es, quizá, una de las conclusiones más interesantes del recorrido por la feria: incluso dentro de una única tendencia, los fabricantes eligen modelos distintos.
El enfoque de ABB puede describirse, a grandes rasgos, como «protección como software». El fabricante da un producto de software y los requisitos de recursos de cómputo, mientras que buena parte de la arquitectura del sistema queda a cargo del integrador.
El enfoque de Siemens está más cerca de «virtualised protection as a validated system». El software de protección ya está separado del IED tradicional, pero el fabricante sigue controlando la combinación de las plataformas de software y hardware.
Cuál de los dos resultará más cercano a la futura arquitectura masiva de las subestaciones digitales, está lejos de ser evidente aún.
Arteche: una tecnología que nunca llegó a masificarse
Sobre el fondo de la historia muy dinámica de la virtualización, el estand de Arteche se veía inesperadamente contrastante.
Allí se presentaba un transformador de corriente óptico, el SDO-OCT — una solución basada en el efecto Faraday. El transductor de medida es totalmente pasivo, y la electrónica activa se ha trasladado a un bloque electrónico capaz de formar Sampled Values conforme a IEC 61869-9.
El principio en sí está lejos de ser nuevo. Dispositivos similares se demostraban en ferias del sector hace muchos años. Por eso nos interesó especialmente preguntar a los representantes de Arteche: ¿cuánto ha avanzado el mercado en ese tiempo?
La respuesta resultó más bien aleccionadora.
Según los representantes de la empresa, la escala de implantación de los transformadores de corriente ópticos sigue siendo hasta hoy extremadamente pequeña. Es más, varios fabricantes que trabajaron con esta tecnología, según su estimación, cerraron por completo las líneas correspondientes.
Y visualmente la feria no contradecía esta impresión: durante nuestro recorrido, el TC óptico de Arteche resultó casi el único exponente de ese tipo que atrajo nuestra atención.
Se formó un contraste interesante.
Los sistemas secundarios se mueven con relativa rapidez hacia una arquitectura definida por software, la virtualización y plataformas de cómputo independientes. En cambio, la revolución en los transductores de medida primarios, prometida al sector hace muchos años, avanza por ahora mucho más despacio.
Atractivo tecnológico y adopción masiva, como es sabido, están lejos de ser siempre lo mismo.
Hopf: 30 kilómetros entre la antena y el reloj
Otro descubrimiento inesperado para nosotros fue la empresa Hopf. Reparamos en ella por primera vez en la demostración multifabricante de Welotec, donde su equipo se usaba en el sistema de sincronización de tiempo, tras lo cual decidimos pasar por su propio estand.
Hopf se especializa en sistemas de tiempo único. En el estand se presentaban distintos servidores de tiempo, incluidas versiones de alta estabilidad con osciladores de rubidio.
Pero lo que más atrajo nuestra atención fue un pequeño componente del sistema de antena.
Se trata de un convertidor que permite transmitir la señal entre una antena GNSS y un servidor de tiempo por fibra óptica. En el estand se declaraba un alcance de hasta 30 km.
A primera vista es un dispositivo bastante de nicho. Pero desde el punto de vista de una instalación real la idea es muy interesante.
En el caso corriente, la longitud del trayecto coaxial de la antena GNSS está limitada por la atenuación. Incluso en la documentación de la propia Hopf para sus sistemas de antena, un cable estándar se limita a decenas de metros y, con ciertos tipos de cable y amplificadores, se habla ya de centenares — pero no decenas de miles — de metros (aunque tales cables ya no son tan flexibles).
El paso a la fibra cambia la situación de forma fundamental.
La antena puede alejarse a una distancia considerable de la instalación protegida — por ejemplo, hacia donde la vista del cielo de satélites es mejor o es más fácil cumplir los requisitos de ubicación. Al mismo tiempo, desaparece el largo trayecto conductor entre la antena externa y el equipo dentro del edificio, lo que resulta interesante también desde el punto de vista del aislamiento galvánico y la protección contra descargas atmosféricas.
Es un buen ejemplo de que las cosas realmente interesantes en una gran feria están lejos de ocupar siempre el lugar central del estand.
Qué mostró la feria al final
Tras recorrer estos estands, nuestra principal conclusión no es que «ha aparecido la protección virtualizada». Esa idea existe desde hace ya varios años.
Ha cambiado otra cosa: en torno a ella empieza a aparecer un mercado.
Hay funciones como aplicaciones en ABB y Siemens. Hay plataformas de cómputo dedicadas de Moxa y Welotec. Está el entorno abierto SEAPATH. Hay empresas como Kalkitech, que ya ven la virtualización como base de una Software Defined Substation más amplia. Aparecen demostraciones multifabricante en las que productos de distintos fabricantes realmente funcionan dentro de una única arquitectura.
Lo que significa que la siguiente etapa de desarrollo estará ligada ya no tanto a demostrar la viabilidad en principio de la protección virtual, cuanto a la ingeniería de sistemas.
¿Cómo hacer redundantes las plataformas de cómputo? ¿Cómo definir los dominios de fallo admisibles? ¿Se pueden alojar SCADA y protección en los mismos servidores físicos? ¿Quién responde por la actualización del hipervisor? ¿Cómo validar el sistema tras un cambio de infraestructura? ¿Dónde pasa la frontera de responsabilidad entre el proveedor de las funciones de protección y el integrador de sistemas?
En una subestación digital clásica, uno de los objetos clave del diseño era la red IEC 61850.
Parece que la subestación definida por software gana un objeto más de ese tipo — la propia infraestructura de cómputo.
Y quizá sea justamente aquí donde se encuentra el principal cambio que hoy puede verse en CIGRE.
La protección deja gradualmente de ser solo un dispositivo.
Se convierte en una función de software.
Y con ello, al cliente final, al proyectista y al integrador de sistemas les tocará aprender a diseñar no solo la protección, la red y el sistema de sincronización, sino también la plataforma en la que esa protección vive.