Un piloto de vPAC en 2026 cuenta con una amplia gama de productos entre los que elegir. El SSC600 SW de ABB, el PhasorController de GE, el SIPROTEC V de Siemens, la plataforma de referencia SEAPATH de LF Energy que alcanzó la versión v1.0 en febrero de 2025, y una larga lista de ofertas de miembros de la vPAC Alliance. Cada uno tiene su propia respuesta a la misma serie de preguntas de ingeniería: ¿qué interfaz IEC 61850 debe exponer un EIU virtualizado?, ¿cómo se configura?, ¿cómo se mantiene su disciplina de tiempo?, ¿cómo se supervisa durante su operación?, ¿cómo se aplica un parche sin desconectar la subestación?

Lo que ha faltado hasta ahora es un marco de la industria que defina esas respuestas — y ese marco ahora está siendo redactado. El Grupo de Trabajo B5.84 de CIGRE — título completo: "Recomendaciones y restricciones para el desarrollo y la interfaz de Dispositivos Electrónicos Inteligentes virtualizados implementados en Sistemas de Protección, Automatización y Control" — es el organismo que realiza este trabajo. Está convocado por David Macdonald (GB), con David Madrid y Marcus Stollfuss como coautores del artículo del marco publicado en CIGRE Future Connections el 20 de enero de 2026 y reimpreso en ELECTRA 345 en abril de 2026.

CIGRE no es un organismo de estandarización; es la asociación internacional de sistemas eléctricos grandes, y sus grupos de trabajo producen Brochures Técnicas, no estándares normativos. Lo que sí tiene CIGRE es un enlace de Categoría A entre el Comité de Estudio B5 (Protección y Automatización) y el TC 57 de IEC, el comité técnico que posee IEC 61850. En la práctica, esto significa que el trabajo del SC B5 de CIGRE — y específicamente el trabajo de grupos de trabajo relevantes para vIED como B5.60 (TB 891) y B5.84 — es un canal directo de entrada hacia el WG 10 y el WG 17 de IEC TC 57. Por lo tanto, una definición de vIED que surja de B5.84 no es una regla vinculante, pero será el documento al que los editores de IEC recurran cuando la próxima parte de IEC 61850 necesite abordar explícitamente la virtualización.

El artículo del marco y el Documento de Alcance (TOR) juntos establecen el alcance esperado de la Brochure Técnica final, prevista para el primer trimestre de 2028, y las implicaciones para los pilotos de vPAC que se están comisionando ahora.

Por qué CIGRE se involucró

El Grupo de Trabajo B5.84 no apareció de la nada. Es el sucesor directo del Grupo de Trabajo B5.60, que se inició en 2017 y produjo la Brochure Técnica 891, "Arquitecturas de Protección, Automatización y Control con Funcionalidad Independiente del Hardware (FIH)", en abril de 2023. La TB 891 sentó las bases conceptuales: las funciones de PAC pueden desacoplarse de la caja en la que actualmente residen, y existen dos caminos arquitectónicos para lograrlo: un EIU basado en middleware con interfaces estandarizadas hacia contenedores de aplicaciones, y un sistema centralizado de Protección y Control basado en servidor que agrega aplicaciones en computación redundante.

TB 891 también proporcionó a la industria el argumento del ciclo de vida que ha sido citado en cada presentación de vPAC desde entonces: los ciclos de vida del hardware de PAC son aproximadamente de 10 a 15 años, mientras que los ciclos de vida de la planta primaria son de 40 a 60 años. Durante la vida del interruptor se reemplaza el relé varias veces. Cada reemplazo implica una reconstrucción del panel, un nuevo SCD y una nueva campaña de puesta en servicio. La funcionalidad independiente del hardware promete romper ese ciclo.

Lo que TB 891 deliberadamente no hizo fue especificar el propio vIED. Describió la opción arquitectónica; no indicó cómo debe verse el vIED en sus interfaces, cómo se configura, cómo se supervisa o cómo se actualiza. Ese es el vacío que B5.84 está llenando.

El enfoque en el artículo de CIGRE es directo: un porcentaje significativo de la base instalada de IED se encuentra al final de su vida útil o se acerca a ella. Las empresas eléctricas están a punto de tomar las próximas decisiones de reemplazo. Si lo hacen sin una visión de un organismo de estándares sobre lo que es un vIED, la industria obtendrá exactamente lo que obtuvo con la primera ola de implementaciones de IEC 61850: seis dialectos específicos de proveedor del mismo concepto.

Lo que realmente cubre el Grupo de Trabajo

El mandato (TOR), firmado por la presidenta del SC B5 y fechado el 8 de enero de 2024, enumera los temas que tratará el Grupo de Trabajo.

%%{init: {
  "theme": "base",
  "themeVariables": {
    "background": "#fafaf7",
    "fontFamily": "Roboto Flex, Inter, system-ui, sans-serif",
    "primaryColor": "#1e1f1d",
    "primaryTextColor": "#fafaf7",
    "primaryBorderColor": "#58c1da",
    "lineColor": "#cbcbc4",
    "mainBkg": "#1e1f1d",
    "nodeTextColor": "#fafaf7",
    "darkTextColor": "#fafaf7",

    "cScale0":  "#1e1f1d", "cScaleLabel0":  "#fafaf7", "cScaleInv0":  "#58c1da",
    "cScale1":  "#d6f0f6", "cScaleLabel1":  "#0d5566", "cScaleInv1":  "#58c1da",
    "cScale2":  "#fdf0c5", "cScaleLabel2":  "#5c3f00", "cScaleInv2":  "#f5b301",
    "cScale3":  "#d1efe1", "cScaleLabel3":  "#0e4f31", "cScaleInv3":  "#2f9e6a",
    "cScale4":  "#fbd6d8", "cScaleLabel4":  "#6e1014", "cScaleInv4":  "#e5484d",
    "cScale5":  "#c3e7ef", "cScaleLabel5":  "#0d4452", "cScaleInv5":  "#2fa9c6",
    "cScale6":  "#dde0e3", "cScaleLabel6":  "#2e3338", "cScaleInv6":  "#6e7681",
    "cScale7":  "#1e1f1d", "cScaleLabel7":  "#fafaf7", "cScaleInv7":  "#58c1da",
    "cScale8":  "#1e1f1d", "cScaleLabel8":  "#fafaf7", "cScaleInv8":  "#58c1da",
    "cScale9":  "#1e1f1d", "cScaleLabel9":  "#fafaf7", "cScaleInv9":  "#58c1da",
    "cScale10": "#1e1f1d", "cScaleLabel10": "#fafaf7", "cScaleInv10": "#58c1da",
    "cScale11": "#1e1f1d", "cScaleLabel11": "#fafaf7", "cScaleInv11": "#58c1da"
  }
}}%%
mindmap
  root((Ámbito del Grupo de Trabajo B5.84))
    Definición
      IED virtual · qué es y qué no es
      Riesgos, beneficios, soluciones
    Interfaz
      IEC 61850 obligatoria
      Reglas y archivos de configuración
      Sincronización de tiempo
    Ciclo de vida
      Administración y actualización
      Supervisión del vIED
    Recursos
      Capacidad de comunicación
      Capacidad de memoria
      Capacidad de CPU
    Lado host
      Requisitos del servidor para alojamiento de vIED
      Requisitos de interfaz servidor-vIED
      Requisitos de servidor industrial
      Comparación de hipervisores
      Redundancia
      Monitoreo de hardware/mediadware/software
    Futuro
      Futuro del concepto de vIED
      Vinculación con el Digital Twin

Algunos puntos merecen ser destacados en este mapa.

La interfaz IEC 61850 es obligatoria. Tanto el TOR como el artículo de CIGRE lo mencionan dos veces: un vIED debe exponer una interfaz IEC 61850 y debe ser configurable mediante reglas y archivos de configuración IEC 61850. No existe una vía alternativa basada en propietarios. Si un producto se autodenomina vIED y no consume un SCD, se trata de algo diferente.

Ambos métodos —VM y contenedor— están incluidos. El artículo de CIGRE describe explícitamente los dos métodos principales de virtualización: sistemas basados en hipervisores donde cada máquina virtual contiene su propio sistema operativo, y sistemas basados en contenedores donde estos se ejecutan en el sistema operativo anfitrión mediante un motor de contenedores. El Grupo de Trabajo abarca ambos. No elige un ganador, y por la forma en que está redactado el TOR, es poco probable que lo haga. Espere un tratamiento comparativo.

La supervisión y la actualización tienen cada una un capítulo. Dos de los temas enumerados son "administración y actualización de IED virtual" y "supervisión del IED virtual". Para cualquier persona con experiencia en campo en actualizaciones masivas de firmware en un conjunto de IEDs de nivel de bay, esta es la sección que debe leer primero cuando se publique el folleto. Un IED virtual (vIED) que es fácil de desplegar en la aceptación de fábrica pero imposible de mantener en campo representa un retroceso, no un avance.

La plataforma anfitriona está dentro del alcance, pero no la arquitectura del PACS. El grupo de trabajo abarca el lado del servidor: requisitos de servidor industrial, comparación de hipervisores, redundancia, monitoreo de hardware/intermediario/software. Lo que no abarca es cómo se arquitecta el PACS en su conjunto, ni la estructura del servidor para PACS centralizados — ese tema está reservado para el grupo de trabajo B5.70.

Este es un límite útil para comprender. B5.84 les está indicando lo que un vIED debe ser en sus interfaces y cómo debe comportarse su plataforma anfitriona para apoyarlo. No les está diciendo si deben construir un PAC centralizado, un vPAC distribuido o uno híbrido. La arquitectura es responsabilidad de otro grupo de trabajo.

Lo que el grupo de trabajo explicitamente no abarca

%%{init: {
  "theme": "base",
  "themeVariables": {
    "background": "#fafaf7",
    "fontFamily": "Roboto Flex, Inter, system-ui, sans-serif",
    "primaryColor": "#ffffff",
    "primaryTextColor": "#1e1f1d",
    "primaryBorderColor": "#e2e2dc",
    "lineColor": "#cbcbc4"
  }
}}%%
flowchart LR
    subgraph IN["B5.84 EN ALCANCE"]
        direction TB
        I1["Definición de vIED"]
        I2["Interfaz IEC 61850"]
        I3["Configuración · sincronización de tiempo"]
        I4["Actualización · supervisión"]
        I5["Dimensionamiento de CPU · memoria · red"]
        I6["Requisitos de la plataforma anfitriona"]
        I7["Comparación de hipervisores"]
        I1 ~~~ I2 ~~~ I3 ~~~ I4 ~~~ I5 ~~~ I6 ~~~ I7
    end
    subgraph OUT["FUERA DE ALCANCE"]
        direction TB
        O1["Elección de arquitectura del PACS"]
        O2["Estructura del servidor del PACS centralizado<br/>(reservado para el grupo de trabajo B5.70)"]
        O3["Certificación de productos de proveedores"]
        O4["Elección entre VM o contenedor como política"]
        O1 ~~~ O2 ~~~ O3 ~~~ O4
    end
    IN -.->|"complementa"| OUT

    classDef inItem  fill:#d6f0f6,stroke:#58c1da,color:#0d5566;
    classDef outItem fill:#dde0e3,stroke:#6e7681,color:#2e3338;
    class I1,I2,I3,I4,I5,I6,I7 inItem
    class O1,O2,O3,O4 outItem
    style IN  fill:#eff8fb,stroke:#58c1da,stroke-width:1.5px,color:#0d5566;
    style OUT fill:#f3f3ee,stroke:#6e7681,stroke-width:1.5px,color:#2e3338;

Los ingenieros que solo han leído el material de marketing sobre vPAC tienden a suponer que el marco de CIGRE eventualmente les indicará qué arquitectura deben elegir: servidor central, servidores distribuidos, híbrido con cajas de borde. No lo hará. El grupo de trabajo B5.84 toma la arquitectura como dada y responde una pregunta más estrecha y útil: independientemente de dónde coloquen el vIED, ¿qué debe ofrecer el propio vIED al resto del sistema?

La TOR también enumera el "concepto futuro de IED virtual" y señala una conexión entre el IED virtual y el concepto de Doble Digital como un tema que el grupo de trabajo discutirá. Aún no existe registro público sobre cuál será esa vinculación en la publicación.

Los dos métodos de virtualización, lado a lado

El artículo de CIGRE describe los dos métodos de la siguiente manera. Relacionándolos con lo que actualmente se está comercializando:

%%{init: {
  "theme": "base",
  "themeVariables": {
    "background": "#fafaf7",
    "fontFamily": "Roboto Flex, Inter, system-ui, sans-serif",
    "primaryColor": "#ffffff",
    "primaryTextColor": "#1e1f1d",
    "primaryBorderColor": "#e2e2dc",
    "lineColor": "#cbcbc4"
  }
}}%%
flowchart TB
    subgraph H["Hipervisor + VMs"]
        direction TB
        HW1["Hardware industrial de servidor<br/>(IEC 61850-3 / IEEE 1613)"]:::hw
        HV["Hipervisor (KVM / VMware ESXi)"]:::platform
        OS1["Sistema operativo invitado · vIED-A"]:::runtime
        OS2["Sistema operativo invitado · vIED-B"]:::runtime
        OS3["Sistema operativo invitado · vIED-C"]:::runtime
        APP1["Aplicación de protección A"]:::app
        APP2["Aplicación de protección B"]:::app
        APP3["Aplicación de protección C"]:::app
        HW1 --> HV
        HV --> OS1 --> APP1
        HV --> OS2 --> APP2
        HV --> OS3 --> APP3
    end
    H ~~~ C
    subgraph C["Motor de contenedores + contenedores"]
        direction TB
        HW2["Hardware industrial de servidor<br/>(IEC 61850-3 / IEEE 1613)"]:::hw
        OSH["Sistema operativo anfitrión (Linux, kernel en tiempo real)"]:::platform
        CE["Motor de contenedores"]:::platform
        CT1["Contenedor · vIED-A"]:::runtime
        CT2["Contenedor · vIED-B"]:::runtime
        CT3["Contenedor · vIED-C"]:::runtime
        AP1["Aplicación de protección A"]:::app
        AP2["Aplicación de protección B"]:::app
        AP3["Aplicación de protección C"]:::app
        HW2 --> OSH --> CE
        CE --> CT1 --> AP1
        CE --> CT2 --> AP2
        CE --> CT3 --> AP3
    end

    classDef hw       fill:#1e1f1d,stroke:#1e1f1d,color:#fafaf7;
    classDef platform fill:#d6f0f6,stroke:#58c1da,color:#0d5566;
    classDef runtime  fill:#fdf0c5,stroke:#f5b301,color:#5c3f00;
    classDef app      fill:#d1efe1,stroke:#2f9e6a,color:#0e4f31;
    style H fill:#fafaf7,stroke:#e2e2dc,stroke-width:1.5px,color:#1e1f1d;
    style C fill:#fafaf7,stroke:#e2e2dc,stroke-width:1.5px,color:#1e1f1d;

El artículo de CIGRE establece directamente la distinción: "la diferencia entre ambos es que la máquina virtual contiene su propio sistema operativo (OS), mientras que los contenedores funcionan todos sobre el sistema operativo anfitrión". Esa distinción cambia la respuesta a casi todas las preguntas que la publicación pretende abordar.

  • Sincronización de tiempo: en el modelo de máquina virtual (VM), cada sistema operativo invitado termina el PTP por separado. En el modelo de contenedores, el sistema operativo host mantiene la hora y los contenedores la heredan. La disciplina que se escriba para uno no se aplica al otro.
  • Administración de actualizaciones: actualizar una VM implica orquestar un sistema operativo más una aplicación; actualizar un contenedor implica intercambiar una imagen. El perfil de riesgo es diferente.
  • Supervisión: lo que cuenta como una señal de "vIED está activo" varía. Un contenedor puede estar activo aunque su aplicación haya fallado; una VM puede estar activa aunque su interfaz de red (NIC) haya perdido su controlador. El Grupo de Trabajo (WG) deberá definir la señal de supervisión a nivel de IEC 61850 para que no dependa del método que use el host.

Hoy en día, cada proveedor que fabrica productos vPAC tiene su propia respuesta a estas preguntas. La publicación no prescribirá una implementación, pero se espera que defina la interfaz y el comportamiento a nivel de IEC 61850 que un vIED debe exponer independientemente del método de virtualización subyacente.

Tiempo real, determinismo y las cosas que el Grupo de Trabajo no puede ignorar

El artículo de CIGRE identifica como “uno de los desafíos de la virtualización” la “garantía de baja latencia y rendimiento determinista”. Para la protección, esto es decisivo: IEC 61850-5 establece un tiempo de transferencia de 3 ms para un mensaje de disparo de tipo 1A. Una plataforma virtualizada debe cumplirlo incluso en la condición de carga peor caso, con el proceso de fondo más exigente y el vecino ruidoso más intenso en el mismo socket — o no lo cumple.

Trabajos académicos recientes han sido explícitos sobre las técnicas necesarias. Núcleos de Linux en tiempo real, fijación de CPU (CPU pinning) para dedicar núcleos al vIED, colocación consciente del NUMA, passthrough de hardware para las NICs que manejan tráfico SV y GOOSE, y configuración del planificador del hipervisor para latencia determinista. Las pruebas publicadas por la TU Delft sobre controladores virtualizados en una subestación IEC 61850 definida por software mostraron tiempos promedio de disparo GOOSE por debajo del requisito de tiempo de transferencia de 3 ms de IEC 61850 — pero solo con la configuración en tiempo real activada y solo bajo cargas de tráfico controladas. El trabajo de evaluación de MDPI hace la misma advertencia: la latencia de comunicación aumenta conforme se añaden vIEDs y crece el tráfico de fondo, y la relación no es lineal.

Este es el aspecto más difícil que el Grupo de Trabajo debe documentar sin convertirse en una guía de selección de proveedores. Se espera que la publicación especifique la supervisión y la generación de informes que permitan a una empresa eléctrica medir si su host cumple los objetivos de determinismo, en lugar de mandatar una versión específica de kernel de Linux o hipervisor. La redacción del TOR — “evaluación de capacidad de comunicación, memoria y CPU” — apoya esta interpretación.

Los entregables y el cronograma

El TOR enumera cuatro cuatrimestres con hitos definidos; todo lo demás (inicio del borrador de trabajo, ritmo de revisión interna) no está fijado a una fecha y no debe inferirse:

Sección Hito 4T 2027 1T 2028 2T 2028
Folleto Borrador del TB para revisión del SC ◆
Folleto Folleto Técnico Final (crítico) ◆
Comunicaciones Tutorial ◆
Comunicaciones Webinario ◆

4T 2027 para el borrador del Folleto Técnico presentado al Comité de Estudio. 1T 2028 para el Folleto Técnico final. 2T 2028 para el tutorial y el webinario. El artículo publicado por ELECTRA que se discute aquí forma parte de ese cronograma: el primer documento de posición pública del Grupo de Trabajo (WG), diseñado para presentar el marco mientras el folleto aún está en desarrollo.

Según los estándares del Grupo de Trabajo de CIGRE, este es un cronograma ajustado. También es el correcto. El mercado de vPAC está evolucionando tan rápidamente que un folleto publicado hacia el final de la década describiría un museo.

Tres decisiones técnicas que tomar antes de la publicación del folleto

Si está llevando a cabo una prueba piloto de vPAC en 2026, tres cosas derivan del marco tal como está establecido.

Primero, asegúrese de que sus candidatos de vIED expongan una interfaz IEC 61850 que sea configurable a partir de archivos SCL (de acuerdo con el requisito del TOR de que los vIED sean "configurables basados en reglas y archivos de configuración IEC 61850"), no a través de una interfaz gráfica de usuario exclusiva del proveedor. Cualquier dispositivo puesto en servicio hoy mediante una herramienta de configuración propietaria quedará fuera de ese requisito y será un candidato probable para rehacerse una vez que se publique el folleto.

Segundo, decida ahora si va por la vía de las máquinas virtuales (VM) o la de los contenedores, e instrumente tanto su supervisión como su proceso de actualización según esa elección. El Grupo de Trabajo no elegirá un ganador. Sin embargo, sí definirá qué debe un vIED al resto del sistema en supervisión y actualización; si su prueba piloto ya expone esas señales a través de MMS, no necesitará realizar modificaciones posteriores cuando se publique el folleto.

Tercero, preste atención a lo que el Grupo de Trabajo no abarca. La arquitectura de su PACS —central, distribuida, híbrida— no está dentro del alcance de B5.84. Esa es su decisión técnica; la estructura de servidor centralizado de PACS se menciona en el TOR de B5.84 como trabajo perteneciente al Grupo de Trabajo B5.70 (un grupo de trabajo separado). No espere a que B5.84 le diga si debe construir un CPC. No lo hará.

En particular, para la supervisión —el capítulo más probable de ser adaptado a herramientas existentes en lugar de desarrollado de cero—, las empresas eléctricas que operan hoy monitores de tráfico IEC 61850 en tiempo real tienen una ventaja. Un vIED, al igual que un IED de hardware, publica datos en un bus. Herramientas como Tekvel Park que ya supervisan el tráfico GOOSE, SV y MMS en redes PACS reales ven a un vIED como simplemente otro publicador; no les importa si la fuente es un relé o una VM, siempre que la interfaz y el comportamiento IEC 61850 estén intactos. Ese es el punto que el Grupo de Trabajo está imponiendo: la identidad del vIED para el resto de la subestación es su interfaz IEC 61850, no su hardware.

Hipervisor frente a contenedor y la frontera de ciberseguridad

Quedan dos preguntas importantes, y el folleto tendrá que responderlas.

La primera es la recomendación entre hipervisor y contenedor. El artículo de CIGRE presenta ambos métodos de manera equilibrada. El TOR incluye "comparación de hipervisores". La práctica industrial real está dividida: VMware ESXi y Linux KVM dominan el campo de las máquinas virtuales (VM); mientras que Kubernetes, k3s y motores de contenedores personalizados están emergiendo en el campo de los contenedores. SEAPATH, la referencia de LF Energy, se basa en KVM. La mayoría de los productos vPAC que los proveedores envían actualmente son basados en VM. Si el Grupo de Trabajo (WG) termina siendo neutral, el folleto será una referencia útil; si termina promoviendo un método, eso reconfigurará las rutas de desarrollo de los proveedores.

La segunda es el límite con la ciberseguridad. La virtualización reduce las superficies de ataque en algunos lugares (un host endurecido en lugar de veinte dispositivos expuestos) y las aumenta en otros (una comprometida hipervisor ahora es un comprometido subestación). El TOR no eleva la ciberseguridad a un título de capítulo, pero el tema es inevitable. La pregunta interesante es si B5.84 hará referencia cruzada con el trabajo del Grupo de Trabajo B5.66 / SC D2 sobre ciberseguridad de OT, o escribirá su propia declaración breve sobre lo que la interfaz del vIED debe a una arquitectura de seguridad. El artículo de CIGRE no lo revela.

Para los ingenieros que aún consideran partes de la pila IEC 61850 como opcionales —especialmente los Valores Muestreados, donde el costo de las unidades de fusión y el bus de proceso se ha utilizado como argumento para posponer la adopción—, el marco del Grupo de Trabajo B5.84 es, de paso, una respuesta. Un vIED no tiene entradas I/O nativas. No tiene entradas de cobre. La única forma en que ve la subestación es a través del bus de proceso y del bus de estación IEC 61850. La virtualización hace que toda la pila sea obligatoria de una manera que los IEDs de hardware nunca lo hicieron del todo, porque un IED de hardware siempre podría recurrir a una entrada de CT cableada. En el mundo de los vIED no hay retroceso —el bus de proceso ES la entrada. Los ahorros de eliminar veinte IED solo se materializan si la infraestructura de las unidades de fusión debajo de ellos ya está presente.

Tenga cuidado con esperar dos años por las respuestas. Las subestaciones que se están poniendo en servicio ahora vivirán durante 40 años. El marco se está escribiendo para ellos.

Fuentes