En el tutorial del comité de estudio B5 del CIGRE, tres reconocidos expertos internacionales en protección y subestaciones digitales mostraron el siguiente peldaño de la evolución del sector. Las funciones de protección se separan gradualmente de los terminales dedicados y migran a plataformas de cómputo en servidor. Pero la discusión más interesante hoy ya no es si esto es técnicamente posible, sino cómo diseñar, probar y operar tales complejos — y quién, en última instancia, responde por su funcionamiento.
En la sala del Palais des Congrès de París, en la mesa de la presidencia están Alex Apostolov, editor jefe de la revista PAC World y especialista de OMICRON electronics; Ratan Das, especialista de Siemens Energy y coordinador del grupo de trabajo de la IEEE que elaboró la guía IEEE C37.300 sobre protección y control centralizados; y David MacDonald, arquitecto de soluciones y estandarización de GE Grid Automation y coordinador del grupo de trabajo CIGRE B5.84 sobre dispositivos de protección virtualizados.
El tutorial del comité de estudio B5 estuvo dedicado al desarrollo de las arquitecturas de los sistemas de protección, automatización y control, con especial atención al bus de proceso y a la virtualización de los dispositivos de protección.
Las tres ponencias se alinearon prácticamente en una única secuencia histórica.
Primero, el enlace de los dispositivos de protección con el equipo primario se vuelve digital gracias al bus de proceso. Luego, las funciones de protección se separan de los numerosos terminales físicos y se centralizan. Por último, el siguiente paso — la virtualización: la función de protección se convierte en una aplicación de software, y el servidor, en una plataforma de cómputo que después se puede reemplazar sin cambiar el propio algoritmo de protección.
En algo más de veinte años, el sector ha recorrido el camino desde las primeras demostraciones de transmisión de valores instantáneos digitalizados por IEC 61850 hasta complejos de protección virtualizados que funcionan sobre plataformas de servidor.
Y el carácter de las preguntas ha cambiado junto con la tecnología.
Hoy la pregunta principal ya no es «¿funcionará?», sino: cómo poseerlo, cómo probarlo y mantenerlo — y quién responde por el complejo si sus componentes los suministran distintos fabricantes.
Veinte años de la demostración al uso industrial
La primera ponencia de Alex Apostolov estuvo dedicada al bus de proceso.
En su base está el folleto técnico del CIGRE TB 949, «Process Bus in Protection, Automation & Control Systems», que resume la experiencia acumulada por el sector en la aplicación del bus de proceso: soluciones de arquitectura, redundancia, proyectos reales, los resultados de encuestas a compañías eléctricas y fabricantes, aspectos económicos y direcciones futuras de desarrollo.
La historia resultó más larga de lo que a veces se imagina.
El trabajo que más tarde condujo a la IEC 61850 comenzó aún en los años 1990. En 2004, el perfil 9-2LE se convirtió en un hito práctico importante en el desarrollo de la transmisión de valores instantáneos digitalizados y en la interoperabilidad de equipos de distintos fabricantes. Apostolov recordó cómo, en la sesión del CIGRE de ese mismo año, ABB, Siemens y Omicron ya demostraban dispositivos trabajando en conjunto con flujos SV.
Sin embargo, entre la demostración de la tecnología y su amplio uso industrial pasó cerca de una década.
El sector observaba de cerca la nueva arquitectura, acumulaba experiencia, lanzaba proyectos piloto. Desde mediados de la década de 2010, el número de implantaciones comenzó a crecer rápidamente.
«Estamos en un punto de inflexión: prácticamente todas las grandes compañías eléctricas del mundo han fijado un rumbo hacia la digitalización».
Detrás de esta conclusión hay un material bastante amplio: más de 200 publicaciones analizadas, alrededor de 60 proyectos examinados y los resultados de una encuesta del sector.
La mayoría de los proyectos estudiados se refieren no a la construcción de nuevas instalaciones, sino a la reforma de subestaciones existentes. Esto es importante: el bus de proceso deja gradualmente de ser una tecnología solo para nuevas instalaciones digitales «ideales» y entra en la práctica de la modernización de subestaciones existentes.
Un pequeño glosario
Para la conversación que sigue, es útil definir algunos términos fijados en la terminología internacional.
- MU / SAMU — dispositivos que convierten las señales analógicas de corriente y tensión en flujos digitales de valores instantáneos SV.
- SCU — unidad de interfaz con el aparellaje de maniobra, que proporciona E/S binaria.
- PIU — unidad de interfaz con el proceso, que combina las funciones de conversión de señales analógicas y binarias.
Como señaló Apostolov, la terminología aquí todavía se usa de forma no del todo consistente.
- PRP y HSR — mecanismos de redundancia de red con recuperación sin pérdidas de la transmisión de datos.
- PTP — el protocolo de sincronización de tiempo de alta precisión IEEE 1588, que permite transmitir la escala de tiempo directamente por la red Ethernet y, en muchas arquitecturas, prescindir de líneas separadas de sincronización por pulsos.
Qué impulsa el bus de proceso — y qué lo frena
Las razones de la adopción pueden dividirse en económicas y tecnológicas.
La economía — menos cableado de cobre y trabajo de montaje, armarios y salas más compactos, reducción del volumen de trabajo en la reforma y una posible disminución de los costes de mantenimiento y modernización.
Las ventajas tecnológicas — mayor seguridad del personal, flexibilidad de arquitectura, escalabilidad, más amplias posibilidades de monitoreo del estado del equipo y una base para la futura integración funcional.
Pero las barreras también son bastante concretas.
A las compañías eléctricas les falta experiencia propia de trabajo con la tecnología. Las dificultades de operación conjunta de equipos de distintos fabricantes son especialmente notables en la fase de diseño y configuración. La ciberseguridad plantea exigencias adicionales a la arquitectura. Se necesitan nuevos métodos de diagnóstico y ensayos.
Y, quizá, una de las cuestiones más importantes son las herramientas.
El propio estándar IEC 61850 permite construir muchas arquitecturas distintas, pero la complejidad de la configuración todavía se traslada con demasiada frecuencia directamente al ingeniero. Apostolov subrayó aparte la necesidad de herramientas que deben ocultar la complejidad tecnológica de la IEC 61850 al usuario, en lugar de obligarlo a trabajar con ella manualmente todo el tiempo.
«El mercado necesita herramientas que oculten la complejidad tecnológica de la IEC 61850 al usuario, en lugar de obligarlo a trabajar con ella manualmente todo el tiempo».
Una cuestión aparte es la economía.
A menudo la subestación digital se evalúa comparando el coste de componentes individuales de una solución tradicional y de una digital. Pero el beneficio real solo se manifiesta al evaluar el coste total de propiedad: diseño, cableado, construcción, puesta en marcha, mantenimiento, reforma y posterior sustitución del equipo.
Y es justamente el ciclo de vida el que resulta especialmente interesante en la siguiente etapa de desarrollo.
De diez mil conexiones a la protección centralizada
Ratan Das comenzó su ponencia con una historia personal.
En 1981, recién incorporado a una compañía eléctrica, recibió la tarea de preparar el esquema de conexiones entre dispositivos en una instalación con tres unidades generadoras de 500 MW cada una.
Alrededor de 10 000 conexiones.
El proyectista elaboraba los esquemas, luego se verificaban, y después todo eso había que montarlo físicamente y verificarlo en la instalación.
Las siguientes generaciones de protección redujeron gradualmente esta complejidad.
Los relés electromecánicos dieron paso a los estáticos, luego aparecieron los terminales microprocesados. La IEC 61850 permitió sustituir buena parte de los enlaces por cable por intercambio digital.
La siguiente pregunta lógica surgió hace aproximadamente una década: si las mediciones analógicas y las señales binarias ya están disponibles por el bus de proceso, ¿es obligatorio que cada bahía tenga su propio terminal de cómputo?
Así surgió el concepto de protección y control centralizados — CPC (Centralized Protection and Control).
Las unidades de interfaz permanecen junto al equipo primario. Reciben mediciones, estados y comandos. Y los algoritmos de protección y control se trasladan a una plataforma de cómputo centralizada de nivel de subestación.
En palabras de Das, esto puede considerarse como la siguiente generación en el desarrollo de los complejos de protección.
«Cuando en 2013 escribimos un artículo sobre un complejo de protección en servidor, muchos lo miraban como una fantasía descabellada. Hoy, en los estands de esta sesión, la protección funciona precisamente en servidores».
Pero la centralización resuelve solo parte de la tarea.
Las funciones ya están reunidas en una plataforma de cómputo común, pero el software todavía puede permanecer estrechamente ligado a la plataforma de hardware específica del fabricante.
El siguiente paso es separar una cosa de la otra.
Las funciones por separado, la plataforma de hardware por separado
En eso consiste precisamente la idea de independencia de la funcionalidad respecto de la plataforma de hardware — FIH (Functionality Independent of Hardware).
El principio básico es simple: la sustitución de la plataforma de cómputo no debe requerir una reelaboración sustancial de las funciones aplicadas de protección.
Por supuesto, la independencia absoluta no existe. Para una nueva plataforma pueden necesitarse controladores, verificación de compatibilidad, ajuste del entorno de ejecución.
Pero el propio algoritmo de protección no debería tener que crearse de nuevo cada vez solo porque el fabricante del procesador ha descontinuado una generación antigua o ha cambiado el hardware del servidor.
En esto consiste el cambio fundamental del ciclo de vida.
Hoy el terminal de protección es, en la práctica, un producto único: los algoritmos de protección, el procesador, el sistema operativo, las interfaces de red, la fuente de alimentación y el chasis se suministran juntos.
Cuando la parte de hardware queda obsoleta, a menudo hay que sustituir el terminal entero.
En un complejo virtualizado, la función aplicada y la plataforma de cómputo empiezan a vivir ciclos de vida distintos.
Para el sector eléctrico esto es especialmente importante. El equipo primario se opera durante décadas, mientras que las plataformas de cómputo evolucionan mucho más rápido.
Como resultado, a lo largo de la vida útil del equipo primario pueden sucederse varias generaciones de medios de cómputo de protección.
Con la nueva arquitectura, cambiar cada vez la propia función de protección ya no es obligatorio.
Los ensayos pueden aumentar, y el trabajo en la instalación, disminuir
A primera vista parece que la virtualización debería reducir el volumen de ensayos.
Das hizo una salvedad importante: es más correcto plantearlo de un modo bien distinto.
Se pueden realizar incluso más ensayos — pero trasladar buena parte de ellos de la instalación al laboratorio.
Una aplicación de software puede verificarse exhaustivamente con independencia de una instalación concreta.
Si después cambia solo la plataforma de cómputo, mientras el código de la propia función de protección permanece el mismo, el volumen completo de ensayos funcionales de la aplicación ya no tiene que repetirse necesariamente directamente en la subestación.
El grueso de la verificación de una nueva plataforma puede hacerse de antemano.
Esto potencialmente cambia de forma seria el propio proceso de sustitución del equipo.
Hoy, la sustitución de un terminal a menudo significa un proyecto, aprobaciones, puesta fuera de servicio, montaje, configuración y un volumen completo de verificaciones.
En un complejo de protección definido por software, la sustitución de la plataforma de hardware puede, en el futuro, convertirse en una operación mucho más rutinaria.
Pero junto con esto surge una cuestión organizativa fundamental: ¿quién da la garantía de todo el complejo y cómo se distribuye la responsabilidad entre los participantes?
La discusión volvió a ella después de las ponencias.
Qué aporta exactamente la virtualización
La tercera ponencia — de David MacDonald, coordinador del grupo de trabajo CIGRE B5.84 sobre dispositivos de protección virtualizados — estuvo dedicada directamente a la virtualización.
La principal diferencia de un complejo virtualizado respecto de uno centralizado corriente no radica solo en el uso de un servidor.
Entre las funciones aplicadas y la plataforma de hardware aparece una capa de virtualización, que permite separar las aplicaciones de software del hardware de servidor concreto y aislarlas entre sí.
Para las máquinas virtuales, el elemento básico de tal capa es el hipervisor — un recurso de software que permite ejecutar simultáneamente varias máquinas virtuales aisladas en un único servidor físico.
Las funciones aplicadas de protección pueden ejecutarse en máquinas virtuales separadas. Otro enfoque es la contenerización, cuando varias aplicaciones usan un sistema operativo común, pero se aíslan entre sí por medios de software. También es posible una variante combinada — por ejemplo, alojar aplicaciones contenerizadas dentro de una máquina virtual.
Para complejos en los que se prevé el uso de aplicaciones de distintos fabricantes, las máquinas virtuales son especialmente interesantes gracias a la separación más estricta de los entornos de software.
Una función de protección virtual aislada puede desplegarse, ensayarse o actualizarse con independencia de otras funciones que se ejecutan en el mismo servidor.
Es precisamente esta posibilidad la que crea las premisas para complejos en los que aplicaciones de distintos fabricantes puedan funcionar sobre una plataforma de cómputo común.
En un complejo centralizado tradicional hay bastante menos libertad: las funciones están reunidas, pero toda la solución sigue siendo un complejo único de software y hardware de un solo proveedor.
La plataforma de hardware no desaparece
Aquí es importante no caer en una trampa terminológica.
La independencia de la plataforma de hardware no significa que cualquier servidor sirva para la protección.
Las exigencias a la plataforma de cómputo siguen siendo extremadamente serias.
Hay que tener en cuenta el rendimiento del procesador y la memoria, las interfaces de red, la redundancia de alimentación y discos, las condiciones de operación, la compatibilidad electromagnética, los medios de gestión remota, el esquema de redundancia y las exigencias de fiabilidad.
Además, para cada dispositivo virtual hay que definir los recursos de cómputo requeridos y las características de la red virtual.
Es decir, la virtualización no elimina el diseño de ingeniería de la parte de hardware.
Cambia otra cosa: la plataforma de hardware deja de determinar la propia funcionalidad aplicada de la protección.
Es una distinción importante.
Dos modelos de redundancia
Para un complejo de protección en servidor se pueden usar distintos enfoques de redundancia.
El más obvio — dos servidores independientes en los que se ejecutan simultáneamente instancias idénticas de las protecciones. Cada uno es capaz de emitir su propio comando de disparo.
Una variante más compleja — un clúster de varios servidores.
En este caso, un grupo de nodos se gestiona como un único sistema de cómputo. Ante el fallo de un servidor, sus aplicaciones pueden reiniciarse automáticamente en otro nodo.
Para tomar decisiones sobre el estado de los participantes del clúster se usa un número impar de nodos — por ejemplo, tres o cinco. Esto permite determinar una mayoría y excluir el nodo fallido.
También es posible migrar una máquina virtual de un servidor físico a otro.
Y aquí surge una de las características fundamentales de la nueva arquitectura: lo que se hace redundante ya no es necesariamente el propio dispositivo físico, sino la capacidad de ejecutar la función.
Para un complejo de protección tradicional, estos dos conceptos prácticamente coincidían.
Para uno virtualizado — ya no.
Microsegundos: donde la virtualización se encuentra con el tiempo real
Sin embargo, un complejo de protección en servidor plantea a la infraestructura de cómputo exigencias muy distintas de las de los sistemas de información corrientes.
No basta con asegurar un tiempo medio breve de ejecución de la función.
La protección requiere un tiempo de reacción predecible y una dispersión limitada de los retardos incluso en condiciones desfavorables.
Los sistemas operativos corrientes se optimizan ante todo para el uso eficiente de los recursos, no para un determinismo temporal estricto.
La propia virtualización también puede introducir retardos adicionales: un paquete de red pasa por varias capas de software antes de llegar a la aplicación de protección.
Para acortar este camino y reducir los retardos se usan mecanismos especiales de acceso directo y acelerado a las interfaces de red — en particular, PCI passthrough, SR-IOV y DPDK.
Un análisis detallado de estas tecnologías es tema de un material aparte. Lo que importa aquí es otra cosa: en un complejo de protección virtualizado, el trayecto de red y la forma de entrega de los datos a la aplicación pasan a ser parte del diseño de ingeniería tanto como la elección del procesador, la asignación de los recursos de cómputo o el ajuste del funcionamiento en tiempo real.
Pero la principal conclusión de MacDonald no fue sobre la elección de una tecnología concreta.
El determinismo no se puede simplemente declarar. Hay que medirlo y confirmarlo con ensayos.
Cómo está construida la plataforma abierta SEAPATH
Como ejemplo ilustrativo de arquitectura, MacDonald examinó la plataforma abierta LF Energy SEAPATH.
Aquí los dispositivos virtuales de protección se sitúan sobre un conjunto de herramientas estándar de virtualización y gestión de la infraestructura de cómputo.
Se usan Linux con un kernel para operación en tiempo real, KVM, QEMU y libvirt. Para la red virtual se aplican las herramientas de software correspondientes, y para construir una infraestructura tolerante a fallos — mecanismos de clusterización.
La asignación de los recursos de cómputo desempeña un papel importante.
Los núcleos del procesador pueden fijarse a determinadas tareas. Se tiene en cuenta la arquitectura NUMA — la organización del acceso de los procesadores a la memoria principal en plataformas de servidor multiprocesador. Se gestionan las prioridades de los hilos y el tratamiento de las interrupciones.
Es decir, el servidor deja de ser simplemente «un ordenador en el que se ha lanzado la protección».
Se convierte en un entorno de cómputo especialmente ajustado para ejecutar funciones críticas en tiempo real.
Ensayar una protección sin detener las demás
La virtualización ofrece posibilidades muy interesantes junto con los mecanismos estándar IEC 61850 Test y Simulation.
Imaginemos que en un único servidor se ejecutan los dispositivos virtuales de varias bahías.
Uno de ellos hay que ensayarlo.
Se puede poner en modo de ensayo y alimentarlo con flujos SV y GOOSE simulados desde un equipo de ensayo.
Mientras tanto, los dispositivos virtuales vecinos siguen trabajando con los datos reales de la instalación.
Los mensajes GOOSE de prueba se marcan en consecuencia, por lo que los dispositivos de actuación que permanecen en modo normal no deben ejecutar los comandos contenidos en ellos.
Así surge la posibilidad de localizar el ensayo de una función individual dentro de un complejo en funcionamiento.
Para una arquitectura centralizada tradicional, tal independencia de los componentes de software individuales se logra con bastante más dificultad.
El determinismo hay que demostrarlo bajo carga
El grupo de trabajo considera también ensayos especiales de la plataforma de cómputo.
Se mide cuánto difiere el tiempo real de ejecución de las tareas respecto del esperado.
Tales ensayos se realizan muchas veces y bajo una carga creada artificialmente sobre el procesador, la memoria y el subsistema de red.
El más ilustrativo es el ensayo de extremo a extremo.
El equipo de ensayo genera un estímulo, la protección virtual lo procesa y devuelve un comando GOOSE de disparo.
Se mide el trayecto completo de la señal — desde el estímulo hasta el comando de respuesta.
Y la plataforma de cómputo se pone deliberadamente en condiciones desfavorables de competencia por los recursos.
Es precisamente aquí donde se hace visible la diferencia fundamental entre una aplicación de servidor corriente y una función de protección.
Para la protección importa no el mejor resultado y ni siquiera el medio.
Importa la característica garantizada en las peores condiciones previstas.
Ciberseguridad: no hay ventajas sin nuevos riesgos
La centralización y la virtualización crean al mismo tiempo nuevos medios de protección y nuevas amenazas.
Por un lado, el aislamiento de las máquinas virtuales permite limitar la propagación de fallos y las consecuencias del compromiso de aplicaciones individuales.
Se pueden aplicar arranque confiable, verificación de integridad y firma de las imágenes de software, segregación de privilegios, autenticación multifactor y cifrado.
Por otro lado, aparecen nuevos componentes críticos: el propio entorno de virtualización, el sistema operativo del nodo, los medios de gestión centralizada, la cadena de suministro de software.
Además, las consecuencias de un ataque exitoso a una infraestructura de servidor común pueden ser, potencialmente, mucho mayores en escala que el compromiso de un terminal individual.
Por eso, afirmar que un complejo virtualizado es «más seguro» por sí mismo sería demasiado simple.
Es más correcto decir que la virtualización cambia el modelo de amenazas y el conjunto de medios de protección.
Preguntas del público: de la fiabilidad a la responsabilidad
La parte más interesante del tutorial comenzó después de abrir los micrófonos.
Las preguntas del público mostraron bien cuánto ha cambiado el carácter de la discusión profesional.
El debate ya no era sobre la posibilidad de la virtualización como tal, sino sobre sus límites prácticos.
«¿No estaremos creando un nuevo punto único de fallo?»
La primera pregunta natural se refería a la fiabilidad.
En una subestación digital tradicional, decenas de dispositivos físicos están distribuidos por las bahías. El fallo de un terminal concreto suele quedar localizado en un conjunto limitado de funciones.
En un complejo virtualizado, buena parte de las funciones puede depender de solo unos pocos servidores.
¿No surge un nuevo punto único de fallo?
La respuesta de los ponentes fue que la infraestructura de cómputo puede hacerse redundante de forma bastante más profunda y económica que una gran cantidad de dispositivos dedicados.
Una función de protección puede tener varias instancias funcionando simultáneamente, ubicadas en distintos servidores. Ante el fallo de un nodo, es posible continuar el funcionamiento en otro.
Pero los representantes de las compañías eléctricas, con razón, prestaron atención también al reverso.
El fallo de un componente común es, en efecto, potencialmente capaz de afectar a muchas funciones a la vez.
Por eso no se puede simplemente comparar «dos terminales» y «dos servidores».
Es necesario un análisis de fiabilidad de toda la arquitectura: los servidores, los conmutadores, las tarjetas de red, las fuentes de alimentación, el entorno de virtualización, los medios de gestión y las propias aplicaciones.
La virtualización no elimina la ingeniería de fiabilidad tradicional.
Solo ofrece otras formas de construir la redundancia.
«¿Y quién responde si el software y el servidor son de distintos fabricantes?»
Quizá la pregunta más práctica vino de un representante de Scottish and Southern Electricity Networks (SSEN, Reino Unido) — un operador de redes eléctricas del Reino Unido.
Supongamos que la protección virtual la desarrolló el fabricante A.
La plataforma de servidor la suministró el fabricante B.
El entorno de virtualización — el fabricante C.
La protección actuó incorrectamente.
¿A quién debe llamar el cliente?
Esta es una de las tareas clave aún no resueltas de la nueva arquitectura.
Los ponentes señalaron que cierto análogo ya existe hoy en las subestaciones digitales con equipos de distintos fabricantes.
Dispositivos de distintas empresas se unen mediante una red IEC 61850 común, pero la responsabilidad por el complejo en su conjunto debe, aun así, asignarse a una parte concreta — el cliente o un integrador de sistemas designado.
Para un complejo de protección virtualizado, este problema solo se vuelve más evidente.
Por consiguiente, el sector necesita no solo estándares técnicos de interfaces.
Se necesitan reglas de cualificación de las plataformas de cómputo, de compatibilidad de las aplicaciones, de diagnóstico, de ensayos y de distribución contractual de la responsabilidad.
En la práctica, se trata de la formación de un nuevo modelo de operación de los complejos de protección.
Es mejor hablar no de independencia, sino de liberación de limitaciones
Una formulación interesante la propuso un participante de la discusión del Electricity Supply Board (ESB, Irlanda) — una compañía energética irlandesa.
En su opinión, la expresión «independencia de la plataforma de hardware» no describe con precisión el problema.
Una función de protección tradicional no tanto «depende» de la plataforma de hardware como está limitada por ella.
La vida útil de los algoritmos de protección a menudo la determina no su obsolescencia conceptual.
Fallan las fuentes de alimentación, los convertidores de tensión, los módulos de procesador. El fabricante descontinúa una plataforma de hardware concreta — y, junto con ella, hay que cambiar todo el dispositivo.
Aunque los propios algoritmos satisfagan plenamente a la compañía eléctrica.
La virtualización potencialmente rompe este vínculo.
La función permanece, y la plataforma de cómputo se puede actualizar de forma independiente.
En este sentido, se trata en efecto no de la ausencia total de dependencia de hardware, sino de la liberación de la funcionalidad aplicada de las limitaciones de una generación concreta de equipo.
Dónde termina la independencia de la plataforma de hardware
Un representante de Schweitzer Engineering Laboratories (SEL, EE. UU.) — conocido fabricante de dispositivos y soluciones para protección, automatización y control — planteó una cuestión técnica aún más interesante.
Las funciones estándar de protección se pueden virtualizar y ejecutar en una plataforma de servidor estándar.
Pero existen métodos en los que el algoritmo está estrechamente ligado a equipo de medición dedicado.
Por ejemplo, las protecciones por ondas viajeras requieren una frecuencia de muestreo extremadamente alta.
En tales casos, transmitir un enorme flujo de datos a un servidor central puede ser irracional.
Una de las opciones es realizar tal procesamiento directamente en la unidad de interfaz con el proceso.
Pero aquí tampoco todo es tan simple.
Si la función usa datos de varios puntos remotos, un cálculo local en un único dispositivo ya no resuelve la tarea.
Al final, la discusión condujo a una conclusión más importante que la idea de «trasladarlo todo al servidor»: la virtualización no significa la centralización obligatoria de absolutamente todas las funciones.
Distintos algoritmos pueden ejecutarse en distintos niveles.
Las funciones que usan exclusivamente datos locales y requieren un retardo mínimo pueden permanecer junto al proceso.
Las funciones que usan información de varias bahías — ejecutarse a nivel de subestación.
Las funciones de sistema — a un nivel aún más alto.
Es decir, el futuro puede resultar no totalmente centralizado, sino más bien un complejo de protección definido por software jerárquicamente distribuido, en el que el lugar de ejecución de cada función se elige en función de sus requisitos.
¿Y qué hay de la media tensión?
Una cuestión aparte se refería a las redes de distribución.
En las clases de alta tensión, un terminal de protección es un elemento comparativamente caro. En la media tensión, el coste de los dispositivos individuales es sustancialmente menor.
¿Se mantiene allí el sentido económico de la virtualización?
Los ponentes creen que sí.
Los modernos conjuntos de maniobra reciben cada vez más medios digitales integrados de medición y control. En el futuro, la unidad de interfaz con el proceso puede llegar a ser parte del propio aparato de maniobra.
Y las funciones de protección, en ese caso, se añaden por software.
El resultado es un nivel más de separación de los ciclos de vida: la adquisición del equipo primario se separa de la adquisición y el posterior desarrollo de las funciones de protección y automatización.
Son precisamente las subestaciones de distribución masivas las que en el futuro pueden convertirse en una de las mayores áreas de aplicación de los complejos de protección definidos por software.
En resumen
Lo más ilustrativo del tutorial no se dijo desde las diapositivas.
Durante todo el bloque de discusión abierta, prácticamente nadie preguntó: «¿Para qué sirve, en general, la protección virtualizada?»
Las preguntas fueron otras.
¿Cómo asegurar el determinismo requerido? ¿Cómo hacer redundante la infraestructura de servidor? ¿Cómo ensayar una función individual sin afectar a las demás? ¿Qué dejar directamente junto al proceso y qué trasladar al servidor? ¿Cómo cambia la ciberseguridad? Y, por último, ¿quién responde por el resultado si la aplicación, el entorno de virtualización y la plataforma de hardware los suministran empresas distintas?
Para una tecnología que hace apenas unos diez años muchos percibían como un concepto bastante audaz, este es, quizá, el mejor indicador de madurez.
La protección realmente empieza a dejar el «hierro».
Pero el principal reto de la siguiente etapa ya no es demostrar la posibilidad fundamental de la virtualización.
El sector tendrá que aprender a diseñar, cualificar, ensayar y operar la protección como un complejo definido por software.
Y a juzgar por lo que debatieron los especialistas en el CIGRE 2026, esta transición ya ha comenzado.