En los requisitos técnicos para equipos de subestaciones digitales aparece con frecuencia la formulación: «debe soportar IEC 61850».

Pero para un ingeniero, un proyectista, un especialista de puesta en marcha o un especialista de operación, esa frase por sí sola es demasiado general. El soporte de IEC 61850 puede significar cosas muy distintas: la presencia de un servidor MMS, el soporte de GOOSE y/o Sampled Values, la capacidad de importar/exportar archivos SCL, el funcionamiento en el rol de cliente o de configurador de sistema.

Por eso, en la práctica profesional importa no solo la pregunta:

¿El dispositivo soporta IEC 61850?

Mucho más importante es otra pregunta:

¿Esta implementación concreta ha pasado la verificación de conformidad con IEC 61850, según qué edición de la norma, para qué versión de software y para qué funciones?

La respuesta a esa pregunta la da la base de certificados de conformidad de UCAIug / UCA Testing.

Dónde buscar los certificados IEC 61850

El punto de entrada oficial actual es el sitio UCA Testing. Se posiciona como un recurso que agrega información sobre ensayos de interoperabilidad funcional, verificaciones de conformidad con la norma, acreditación de laboratorios de ensayo y programas de certificación para IEC 61850, CIM y OpenFMB. En la página principal de UCA Testing las bases de certificados de conformidad están destacadas por separado, incluida la base IEC 61850.

Para IEC 61850 hay una página dedicada, 61850 Testing. En ella se indica que el recurso contiene información pública y cerrada relacionada con la verificación de dispositivos respecto a la conformidad con la norma. Allí también está el enlace IEC 61850 Conformance Certificates, que conduce al sitio externo Redmine de UCAIug, donde se pueden consultar los documentos de los certificados e información asociada sobre conformidad con IEC 61850.

En otras palabras, el esquema práctico de hoy es el siguiente:

UCA Testing — el punto de entrada oficial para los programas de ensayo y certificación. Redmine Certificate Repository UCAIug — el repositorio donde se alojan los registros y los propios certificados.

Es importante no confundir esa base con un Redmine issue tracker corriente. En este caso, Redmine se utiliza como infraestructura de acceso a los certificados de conformidad.

¿Es un recurso nuevo?

Es más correcto decirlo así: es el repositorio oficial actual de certificados de conformidad IEC 61850 en la infraestructura UCAIug / UCA Testing. Antes los certificados se alojaban en otra dirección.

Los materiales actuales de UCA Testing apuntan precisamente al Redmine externo como lugar de consulta de los certificados.

UCAIug / UCA Testing han centralizado el acceso actualizado a los certificados de conformidad IEC 61850 a través del Redmine Certificate Repository. Para los ingenieros, esto significa que es mejor verificar la existencia de un certificado no por una copia PDF de una propuesta comercial, sino por un registro en la base oficial.

Quién está detrás de estos certificados

La UCA International Users Group desempeña un papel clave en la infraestructura práctica de IEC 61850. En la comunidad IEC 61850, UCAIug es conocida sobre todo por la acreditación de laboratorios de ensayo y la certificación de los resultados de las verificaciones de conformidad.

Este es un punto importante. UCAIug no sustituye a la IEC y no «escribe la norma en lugar de IEC TC57». Pero es alrededor de UCAIug donde se ha formado buena parte de la infraestructura práctica de verificación de conformidad: procedimientos de ensayo, laboratorios acreditados, certificados, ensayos de interoperabilidad funcional y retroalimentación de fabricantes y usuarios.

Para la subestación digital esto es fundamental. IEC 61850 no es solo un conjunto de documentos. Es también un ecosistema de verificaciones, ensayos y confirmación práctica de que las implementaciones concretas realmente cumplen los requisitos declarados.

Qué son las verificaciones de conformidad

Las verificaciones de conformidad (conformance testing) son la verificación de la conformidad de un producto concreto con los requisitos de la norma y con los procedimientos de ensayo aprobados.

En el contexto de IEC 61850, esto significa que no se verifica un abstracto «soporte de la norma», sino una implementación concreta:

  • un modelo concreto de dispositivo o de producto de software;
  • una versión concreta de software o firmware;
  • una edición concreta de IEC 61850;
  • un rol o característica concreta: Server, Client, Merging Unit, Sampled Values, GOOSE Performance o SCL/SCT;
  • bloques de conformidad y procedimientos de ensayo concretos.

El certificado, así, confirma no que «el dispositivo sirve para cualquier subestación digital en general», sino que la implementación ensayada no mostró no conformidades en el alcance de ensayo declarado.

Es una afirmación más estrecha, pero mucho más útil en términos de ingeniería.

Cuántos registros hay en la base de certificados

Según la extracción publicada del registro de UCA IUG del 18 de marzo de 2026, la base contenía 1650 registros referidos a tres ediciones de IEC 61850. Importante: son precisamente registros de ensayo, no necesariamente 1650 dispositivos físicos únicos. Un producto puede tener varios registros por distintas versiones de software, ediciones de la norma, roles o tipos de ensayo.

La distribución por edición de IEC 61850 era la siguiente:

Edición de IEC 61850 Número de registros
Edition 1 805
Edition 2 730
Edition 2.1 115
Total 1650

Estas estadísticas muestran no solo la escala de la base, sino también la evolución de la norma. La Edition 1 formó la base de la adopción masiva de IEC 61850, la Edition 2 se convirtió en la siguiente etapa importante, y la Edition 2.1 se está convirtiendo ahora en la trayectoria principal de los nuevos ensayos.

Estructura del registro de certificados de conformidad IEC 61850 de la base de UCA IUG
Fig. 1. Estructura del registro de certificados de conformidad IEC 61850: distribución de 1650 registros por edición de la norma y por tipo de ensayo (según la extracción del 18 de marzo de 2026).

Qué tipos de certificados existen

En la base hay registros de distintos tipos. Las categorías más numerosas son Server y Client. Juntas suman 1568 de los 1650 registros, es decir, alrededor del 95% del registro.

No es de extrañar. En la mayoría de los proyectos de subestaciones digitales, los IED de protección, los controladores y los dispositivos de medida actúan en el rol de servidores IEC 61850. Proporcionan el modelo de datos y los servicios de acceso a él. SCADA, pasarelas y herramientas de ingeniería y diagnóstico trabajan en el rol de cliente IEC 61850.

Según la extracción publicada, la distribución por tipo de ensayo era la siguiente:

Tipo de ensayo Número de registros
Server 1302
Client 266
Merging Unit 34
GOOSE Performance 30
Sampled Values 10
SCL/SCT 8
Total 1650

Estas categorías se pueden explicar brevemente así:

Tipo de ensayo Qué significa
Server El dispositivo o software proporciona el modelo de datos IEC 61850 y los servicios de acceso del lado del servidor
Client El sistema accede a servidores IEC 61850
Merging Unit Dispositivo del bus de proceso que asegura la publicación de las medidas
Sampled Values Verificación de las funciones de publicación y/o recepción de SV
GOOSE Performance Verificación del rendimiento y las características temporales de GOOSE
SCL/SCT Verificación de las herramientas de trabajo con archivos SCL

Aparte, en el registro hay una pequeña categoría SCL/SCT, ligada a la verificación de las herramientas de trabajo con archivos SCL. En el marco de este artículo no examinaremos en detalle los configuradores, pero la propia existencia de esa categoría es importante: la conformidad con IEC 61850 atañe no solo a los dispositivos y los servicios de comunicación, sino también a las herramientas de ingeniería mediante las cuales se crean y mantienen SCD, SSD, ICD, CID y otros archivos SCL.

Qué hay que analizar exactamente en el certificado

Un error es simplemente encontrar en la base el nombre del fabricante y marcar una casilla. Para una verificación de ingeniería eso no basta.

En el certificado y en el registro de la base hay que analizar:

  1. El modelo del producto. Un certificado de otra serie de dispositivos no confirma la conformidad del modelo necesario.
  2. La versión de software o firmware. En IEC 61850 esto es crítico. La pila de comunicación, el modelo de datos y otros aspectos pueden cambiar de versión a versión.
  3. La edición de la norma. Edition 1, Edition 2 y Edition 2.1 no son lo mismo. Para proyectos nuevos, cada vez más hace falta indicar por separado la edición requerida.
  4. El tipo de ensayo. Server, Client, Merging Unit, Sampled Values, GOOSE Performance y SCL/SCT son áreas de verificación distintas. Un certificado Server no significa automáticamente que el producto se haya ensayado como Client, Merging Unit o herramienta SCL.
  5. Los bloques de conformidad (conformance blocks). Son ellos los que muestran qué bloques funcionales se declararon y se ensayaron.
  6. El laboratorio de ensayo. Importa entender quién realizó los ensayos y si fue un laboratorio acreditado en el marco del procedimiento de UCAIug.
  7. La fecha de los ensayos. Para líneas de producto de larga vida, la fecha puede importar: una versión antigua del dispositivo pudo certificarse hace muchos años, mientras que la versión que se suministra realmente ya difiere.
flowchart TB
    START["<b>Registro en el registro UCAIug / UCA Testing</b><br/>se ha encontrado el nombre del fabricante — eso es poco"]

    START --> C1["<b>1 · Modelo del producto</b><br/>un certificado de otra serie<br/>no confirma el modelo necesario"]
    C1 --> C2["<b>2 · Versión de software / firmware</b><br/>pila, modelo de datos, exportación SCL,<br/>GOOSE e informes cambian de versión a versión"]
    C2 --> C3["<b>3 · Edición de la norma</b><br/>Edition 1 / 2 / 2.1 — no son lo mismo"]
    C3 --> C4["<b>4 · Tipo de ensayo</b><br/>Server / Client / Merging Unit /<br/>Sampled Values / GOOSE Performance / SCL-SCT"]
    C4 --> C5["<b>5 · Bloques de conformidad</b><br/>qué bloques funcionales se<br/>declararon y realmente se ensayaron"]
    C5 --> C6["<b>6 · Laboratorio de ensayo</b><br/>estaba acreditado en el marco del procedimiento de UCAIug"]
    C6 --> C7["<b>7 · Fecha de los ensayos</b><br/>la versión suministrada puede ya<br/>diferir de la certificada"]
    C7 --> OK["<b>Una conclusión fundamentada</b><br/>qué confirma exactamente el certificado —<br/>y si eso se aplica a su proyecto"]

    style START fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style C1 fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C2 fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C3 fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C4 fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C5 fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C6 fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C7 fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style OK fill:#E8F5E9,stroke:#67C23A,color:#1B5E3F
Fig. 2. Siete parámetros a analizar en un certificado de conformidad IEC 61850 para entender qué confirma exactamente y si eso se aplica a un proyecto concreto.

Por qué el certificado no es solo un «papel para la licitación»

En las compras tradicionales, el certificado se percibe a menudo como un documento formal. En IEC 61850 esa es una simplificación peligrosa.

El certificado de conformidad ayuda a responder a preguntas reales de ingeniería:

  • si esta implementación fue ensayada por un laboratorio independiente;
  • según qué edición de IEC 61850 se verificó;
  • qué versión de software fue objeto de los ensayos;
  • qué servicios y bloques de ensayo entraron en el alcance de la verificación;
  • si se puede referenciar el certificado en el proyecto, la compra, la puesta en marcha o la aceptación;
  • si el rol declarado del dispositivo corresponde a la aplicación real en el proyecto.

Esto es especialmente importante en subestaciones digitales multifabricante. Los problemas surgen no solo porque un dispositivo «no soporta IEC 61850». Con mucha más frecuencia los problemas aparecen en las interfaces: distintas interpretaciones del SCL, secciones private y ajustes de los configuradores, entre otros.

El certificado no resuelve todos esos problemas automáticamente. Pero establece un nivel inicial de confianza: la implementación concreta al menos ha pasado una verificación formal de conformidad.

En qué se diferencian las verificaciones de conformidad de los ensayos de interoperabilidad funcional

Es importante no mezclar dos niveles distintos de verificación.

La verificación de conformidad responde a la pregunta:

¿Un producto concreto cumple los requisitos de la norma y del procedimiento de ensayo?

Los ensayos de interoperabilidad funcional responden a otra pregunta:

¿Podrán los productos de distintos fabricantes interactuar correctamente entre sí en escenarios reales?

Ambos niveles son necesarios. El certificado de conformidad es la base. Pero para la subestación digital eso no basta: en el objeto siguen siendo necesarias la verificación del SCL de proyecto, la verificación de GOOSE/SV, la verificación de MMS, el análisis de la conformidad de la configuración real con el SCD de proyecto y los ensayos en el contexto del sistema concreto.

Es precisamente por eso que UCAIug es importante no solo como titular de la base de certificados, sino también como plataforma alrededor de la cual se desarrolla la práctica de ensayos de IEC 61850.

flowchart TB
    subgraph CONF["Verificaciones de conformidad"]
        direction TB
        CQ["<b>Pregunta:</b><br/>¿un producto concreto cumple<br/>los requisitos de la norma<br/>y del procedimiento de ensayo?"]
        CO["Objeto: una implementación<br/>modelo · versión de software · edición · rol"]
        CR["Resultado: un certificado de conformidad —<br/>un nivel inicial de confianza"]
        CQ --> CO --> CR
    end

    subgraph INTEROP["Ensayos de interoperabilidad funcional"]
        direction TB
        IQ["<b>Pregunta:</b><br/>¿podrán los productos de distintos<br/>fabricantes interactuar<br/>correctamente entre sí?"]
        IO["Objeto: un conjunto de dispositivos<br/>en escenarios reales de intercambio"]
        IR["Resultado: confirmación del funcionamiento en las<br/>interfaces — SCL, DataSet, RCB,<br/>suscripciones GOOSE, SV, control"]
        IQ --> IO --> IR
    end

    CR ==>|"la base, pero insuficiente"| IQ
    IR --> SITE["<b>En el objeto siguen siendo necesarias</b><br/>verificación del SCL de proyecto · verificación de GOOSE/SV ·<br/>verificación de MMS · FAT / SAT ·<br/>cotejo de la configuración real con el SCD de proyecto"]

    style CONF fill:#EAF3FF,stroke:#42A5F5
    style INTEROP fill:#FBE9E7,stroke:#E64A19
    style CQ fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style CO fill:#fff,stroke:#90b8e0,color:#0D47A1
    style CR fill:#E8F5E9,stroke:#67C23A,color:#1B5E3F
    style IQ fill:#FBE9E7,stroke:#E64A19,color:#BF360C
    style IO fill:#fff,stroke:#e0a48a,color:#BF360C
    style IR fill:#FFF3E0,stroke:#E6A23C,color:#7A5418
    style SITE fill:#EDE7F6,stroke:#7E57C2,color:#311B92
Fig. 3. Dos niveles distintos de verificación: las verificaciones de conformidad confirman la conformidad de una implementación con la norma, los ensayos de interoperabilidad funcional — el trabajo conjunto de productos de distintos fabricantes. El certificado es la base, pero no sustituye a los ensayos de proyecto en el objeto.

Cómo usar la base de certificados en un proyecto

La base de certificados de UCAIug es útil en varias etapas del ciclo de vida de una subestación digital.

En la etapa de compra

Se verifica si el equipo declarado por el proveedor tiene realmente un certificado IEC 61850 publicado.

Es importante exigir no solo «un certificado IEC 61850», sino un certificado con indicación de:

  • modelo del producto;
  • versión de software;
  • edición de la norma;
  • tipo de ensayos;
  • bloques de conformidad;
  • laboratorio de ensayo;
  • número y fecha del certificado.

En la etapa de proyecto

El proyectista puede entender qué funciones están realmente confirmadas por ensayos. Por ejemplo, un dispositivo puede tener un certificado Server, pero eso no significa que se haya ensayado como Sampled Values Publisher o Subscriber.

En la etapa de FAT y SAT

El certificado se puede usar como punto de partida para el programa de ensayos. Pero el programa de FAT/SAT debe verificar no solo la conformidad del dispositivo con la norma, sino el funcionamiento de todo el sistema: SCD, GOOSE, SV, MMS, informes, control, sincronización de tiempo e interacción con otros dispositivos.

En la etapa de operación

Para el servicio de operación, la base de certificados es útil en el análisis de cambios. Si en el objeto se ha actualizado el firmware de un IED, hay que entender: si la nueva versión corresponde a la que se certificó, o si ya es otra implementación desde el punto de vista de IEC 61850.

Cómo formular mejor los requisitos en el pliego técnico

Formulación débil:

El equipo debe soportar IEC 61850.

Formulación más correcta:

El equipo debe disponer de un certificado de conformidad IEC 61850 publicado en la base UCAIug / UCA Testing, con indicación de la edición de la norma, el tipo de ensayos, la versión de software/firmware, los procedimientos de ensayo aplicados y la lista de bloques de conformidad certificados.

Para los IED de protección, los controladores de bahía y los dispositivos de medida, en la mayoría de los casos se requerirá un certificado IEC 61850 Server.

Para SCADA, pasarelas, sistemas de adquisición de datos, herramientas de ingeniería y diagnóstico, puede ser importante un certificado Client.

Para soluciones ligadas al bus de proceso, hay que analizar por separado Merging Unit, Sampled Values y, si es necesario, GOOSE Performance.

Para las herramientas de ingeniería de trabajo con archivos SCL, el registro prevé la categoría SCL/SCT. En este artículo no la examinamos en detalle, pero en el proyecto de subestaciones digitales multifabricante el propio hecho de la verificación de las herramientas SCL también puede ser importante.

Por qué la Edition 2.1 se vuelve especialmente importante

Para proyectos nuevos, cada vez tiene más sentido indicar por separado el requisito de la Edition 2.1. En las estadísticas publicadas se ve que la Edition 2.1 se ha convertido en la dirección dominante de las nuevas certificaciones: desde enero de 2024, la verificación de conformidad según la Edition 2.1 se convirtió en dirección obligatoria en los laboratorios acreditados de UCA IUG, y los datos de 2025–2026 reflejan esa transición.

Esto no significa que todos los dispositivos de la Edition 1 o de la Edition 2 deban considerarse no aptos. En objetos en operación se usarán todavía durante mucho tiempo. Pero para proyectos nuevos, compras nuevas y nuevos requisitos para subestaciones digitales es importante fijar explícitamente qué edición de IEC 61850 se requiere.

De lo contrario, la formulación «conformidad con IEC 61850» puede admitir un producto con un certificado antiguo que formalmente cumple la norma, pero no corresponde a las expectativas de un proyecto moderno.

La conclusión principal

La base de certificados de UCAIug / UCA Testing no es solo un archivo de documentos PDF. Es una herramienta práctica de verificación de las afirmaciones de los fabricantes sobre el soporte de IEC 61850.

Para la subestación digital, importa no la mera presencia de la frase «IEC 61850» en la descripción del equipo, sino la confirmación de que una implementación concreta ha pasado la verificación de conformidad:

  • según la edición necesaria de la norma;
  • en el rol necesario;
  • con la versión de software necesaria;
  • según procedimientos de ensayo definidos;
  • con un alcance claro de funciones verificadas.

Por eso, al elegir equipos, preparar el pliego técnico, realizar FAT/SAT y acompañar la operación, la pregunta debe sonar no así:

¿El dispositivo soporta IEC 61850?

Sino así:

¿Tiene esta versión concreta del producto un certificado de conformidad IEC 61850 publicado en la base UCAIug / UCA Testing, y qué confirma exactamente ese certificado?

Es precisamente ese enfoque el que convierte IEC 61850 de una declaración general en un requisito de ingeniería verificable.