IEC 61850-10 define cómo se prueba que la comunicación de un IED cumple la serie: el fabricante entrega el equipo con sus documentos PICS (protocolo), MICS (modelo de datos) y PIXIT (información adicional), y el laboratorio ejecuta casos positivos y negativos sobre cada modelo de servicios que el equipo declara. Cada caso termina en pasa, falla o no concluyente, y todo queda en un informe con identificador único. La conformidad no sustituye a las pruebas FAT y SAT de cada proyecto.
Qué dice la norma y para qué sirve
IEC 61850-10 describe cómo probar que la comunicación de un dispositivo cumple la serie IEC 61850 y cómo medir los parámetros de desempeño que se declaran. Su finalidad práctica, según el propio texto, es que el integrador pueda incorporar los IED con facilidad, operarlos correctamente y respaldar las aplicaciones previstas. Esta guía se basa en la edición 1 (2005). La norma deja fuera de su alcance quién ejecuta las pruebas y cómo se certifican los resultados, y las pruebas de dispositivos que actúan como cliente; los casos definidos son los de un servidor.
Para entender el lugar de esta prueba dentro de la vida de un equipo, la norma recuerda la secuencia: ensayos internos de desarrollo, prueba de tipo, pruebas de rutina en producción y, ya en el proyecto, FAT y SAT. Una prueba de conformidad es la prueba de tipo de la comunicación y, como la comunicación forma un sistema, también la prueba del IED dentro de ese sistema. Lo que dice IEC 61850-4 sobre versiones, soporte de producto y pruebas FAT y SAT está en ciclo de vida y calidad del sistema IEC 61850-4.
Lo que la conformidad no hace
- No garantiza todos los requisitos funcionales y de desempeño; reduce el riesgo de problemas costosos en la integración.
- No reemplaza las pruebas FAT y SAT de cada proyecto, que parten de los requisitos del cliente. El FAT/SAT lo hace el integrador y normalmente lo presencia el cliente.
- No cubre las funciones del equipo: IEC 61850 no estandariza las funciones de los equipos que se comunican, de modo que sus modos de falla están fuera de alcance. La verificación de aplicaciones funcionales, como el uso de GOOSE en una lógica, tampoco forma parte de la prueba de conformidad.
- No prueba las siete capas. Como la serie no define pilas de comunicación nuevas, la conformidad de las capas inferiores puede demostrarse con documentación de que se usa una pila conforme; en la prueba estándar solo se prueba la aplicación según ACSI.
- No certifica. El texto aclara que el papel de los laboratorios de prueba y la certificación de resultados quedan fuera de la parte 10.
Los tres documentos del fabricante
La prueba se adapta a cada equipo según las capacidades que declara el fabricante en tres documentos.
| Documento | Qué declara | Observación |
|---|---|---|
| PICS | Capacidades de comunicación: servicios y perfiles soportados | Formato estándar de la parte 7-2; concreto según cada mapeo |
| MICS | Elementos del modelo de datos que soporta | Se implementa en el archivo SCD según la parte 6 |
| PIXIT | Información propia del equipo, fuera del alcance de la serie | No se estandariza |
El PICS cumple tres propósitos: seleccionar el conjunto de pruebas, asegurar que se ejecutan las pruebas que corresponden a lo que se afirma y servir de base para revisar la conformidad estática. Los requisitos de conformidad se dividen en estáticos (lo que la implementación debe cumplir) y dinámicos (los que surgen del protocolo usado).
Además, el equipo debe entregarse con su archivo ICD. El laboratorio genera a partir de él el SCD del sistema de prueba, como se explica en archivos SCL.
- Documentos del fabricante. PICS, MICS y PIXIT
- Revisión estática. Se contrasta lo declarado con los requisitos
- Pruebas dinámicas. Interconexión básica, capacidades y comportamiento
- Análisis de resultados. Se ejecuta la revisión final
- Informe. Pasa, falla o no concluyente por caso
Qué se prueba en un servidor
Un dispositivo se prueba contra un solo dispositivo de prueba. El equipo se trata como una caja negra: se usan sus entradas y salidas y su interfaz de comunicación. Las pruebas incluyen, según corresponda, casos positivos y negativos de:
- documentación y control de versiones (parte 4);
- archivo de configuración contra el esquema normalizado (parte 6) y contra el modelo de objetos (partes 7-3 y 7-4);
- implementación de la pila contra el mapeo aplicable (partes 8-1, 9-1 y 9-2);
- servicios ACSI implementados contra su definición (parte 7-2);
- extensiones propias del fabricante, según las reglas generales de la serie.
Configuración y modelo de datos
Se comprueba que el ICD cumpla el esquema XML, que corresponda con los datos, tipos y servicios que el equipo realmente expone y que, al cambiar parámetros en el SCD y configurar el equipo con su herramienta, la configuración en línea coincida con el archivo. En el modelo de datos se verifica la presencia de los objetos obligatorios de cada nodo (M), la de los condicionales (C), el tipo de cada dato y que los valores estén en el rango especificado. Las extensiones se revisan según las reglas de espacios de nombres y deben documentarse en el MICS. También se verifica la longitud de los nombres, la organización de los componentes funcionales y el nombre de los bloques de control y registros; el tema está en nombres de datos en MMS. Qué incluye cada bloque de conformidad de ICCP, del 1 al 5, está en ICCP: bloques de conformidad 1 al 5 y qué hace cada uno.
Modelos de servicios
Los casos se agrupan por modelo de la parte 7-2:
| Modelo | Abreviatura |
|---|---|
| Asociación | Ass |
| Servidor, dispositivo lógico, nodo y dato | Srv |
| Conjuntos de datos | Dset |
| Grupos de ajustes | Sg |
| Reportes | Rpt |
| Registros | Log |
| Eventos genéricos de subestación (GOOSE) | Goo |
| Mando | Ctl |
| Sustitución | Sub |
| Valores muestreados | Sv |
| Hora y sincronización | Tm |
| Transferencia de archivos | Ft |
Un caso es obligatorio cuando el modelo y el servicio están declarados como soportados en el PICS, y la interpretación de pasa o falla depende de las capacidades declaradas.
Positivos y negativos: ejemplos
Una prueba positiva verifica condiciones normales, normalmente con respuesta afirmativa. Una negativa verifica condiciones anormales, normalmente con respuesta negativa. Ejemplos tomados del texto:
| Modelo | Caso positivo | Caso negativo |
|---|---|---|
| Asociación | Asociar y liberar; asociar y abortar desde el cliente; asociar con el máximo de clientes simultáneos según el PIXIT | Parámetros de autenticación incorrectos; desconexión de la interfaz, que el equipo debe detectar en un plazo especificado; corte y retorno de alimentación |
| Dato | Consultar directorios y valores | Pedir un objeto desconocido, escribir un valor fuera de rango o con tipo inconsistente |
| Reportes | Campos opcionales de reportes con y sin buffer | Omitir una opción de disparo; integridad con periodo cero |
| Mando | Recorrer cada camino de la máquina de estados en los cuatro modelos de control | Operar sin seleccionar, seleccionar dos veces, ordenar el mismo valor que ya tiene |
| Hora | Soporte de sincronización; exactitud de estampas según su calidad declarada | Pérdida de sincronización detectada tras un plazo especificado |
Hay además un caso combinado: mantener activos reportes, registros, GOOSE y sincronización mientras se solicita todo el abanico de servicios, de forma continua durante diez minutos, para comprobar que el equipo sigue respondiendo.
La norma pide que las pruebas se concentren en lo que es difícil de probar en un FAT o SAT, como el comportamiento ante paquetes retrasados, perdidos, duplicados o desordenados, nombres o tipos que no coinciden, límites excedidos, caminos de la máquina de estados de control y órdenes simultáneas de varios clientes. Sobre el mando, véase MMS: reportes, mandos y archivos; sobre reportes y valores muestreados, las guías de GOOSE y de valores muestreados. Las siglas y términos de la norma (LN, LD, DO, CDC, SCL, ACSI) están agrupados en glosario IEC 61850.
Criterios de aceptación
Cada caso termina en uno de tres veredictos, tomados de la serie ISO/IEC 9646:
- Pasa: el resultado observado evidencia conformidad con el requisito y no hubo eventos inválidos.
- Falla: el resultado demuestra al menos un incumplimiento o contiene un evento inválido.
- No concluyente: no se puede dar ni lo uno ni lo otro. Siempre debe resolverse para saber si el origen es la norma, la implementación o el procedimiento de prueba.
En general, un caso pasa si el equipo se comporta como dice la serie y el PIXIT. Cuando algo no está especificado, el equipo debe seguir respondiendo a los mensajes sintácticamente correctos e ignorar los incorrectos. Los resultados deben ser reproducibles en el mismo laboratorio y en otros.
El informe de prueba
El informe incluye: la lista de documentos de procedimiento y normas citadas con número, fecha y cláusula; el equipo de prueba y los programas usados; datos del fabricante, del solicitante y del laboratorio; nombre del equipo y todas sus variantes de hardware y firmware; fecha de emisión; nombre y firma del probador; un número de referencia único; la lista de casos ejecutados; y comentarios y problemas hallados. De cada caso se documenta la descripción con objetivo, procedimiento y resultado esperado, la referencia a parte y cláusula, un identificador único, el resultado (pasa, falla, no concluyente, no aplica o vacío si no se probó) y la comparación con lo esperado. Cualquier cambio hecho al equipo durante la prueba se describe por completo.
El laboratorio debe contar con un sistema de calidad conforme con ISO 9001, un plan de calidad, un plan de pruebas e inspección con puntos de espera y de testigo, y permitir auditorías del solicitante.
Cómo se aprovecha en un proyecto
- Compra: exigir PICS, MICS, PIXIT e ICD del equipo y revisar los servicios soportados antes de elegir.
- Ingeniería: usar el PIXIT para conocer los límites (clientes simultáneos, tiempos, rangos).
- FAT y SAT: reutilizar los casos negativos de la parte 10 como lista de verificación de integración. Vea normas para FAT y SAT y las herramientas de prueba IEC 61850.
Le ayudamos con sus pruebas
En Tiza Group preparamos y ejecutamos las pruebas FAT y SAT de su sistema IEC 61850: revisión de documentos del fabricante, pruebas de servicios, casos negativos y informe trazable. Lo hacemos en nuestras pruebas FAT y SAT y con nuestra ingeniería IEC 61850.
Guías relacionadas
- Herramientas de prueba IEC 61850
- Pruebas de desempeño IEC 61850-10: latencia y tiempo
- Normas para puesta en servicio, FAT y SAT
- Modo de prueba y simulación en IEC 61850
- Archivos SCL de IEC 61850
- IEC 61850 MMS: reportes, mandos SBO y archivos
- Glosario IEC 61850: siglas y términos de la norma
- Ciclo de vida y calidad del sistema IEC 61850-4
- ICCP: bloques de conformidad 1 al 5 y qué hace cada uno
Referencias
- IEC 61850-10, edición 1 (2005): cláusulas 1, 3, 5, 6 y anexo A.
- IEC 61850-7-2, anexo A: declaración PICS.
- ISO/IEC 9646: metodología y marco de pruebas de conformidad.
Preguntas frecuentes
¿Qué documentos debe entregar el fabricante para una prueba de conformidad?
El equipo listo para probar, la declaración PICS (capacidades de comunicación, con el formato estándar de la parte 7-2), la declaración PIXIT (información propia del equipo que está fuera del alcance de la norma), la declaración MICS (elementos del modelo de datos que soporta) y los manuales de instalación y operación.
¿Qué es una prueba negativa?
Es la que verifica la respuesta correcta del equipo ante servicios o información que no implementa, o ante mensajes que no cumplen la serie. Por ejemplo, pedir un dato inexistente, escribir un valor fuera de rango o seleccionar dos veces un objeto de mando. Una prueba positiva verifica, en cambio, el comportamiento normal.
¿Una prueba de conformidad reemplaza al FAT y al SAT?
No. La conformidad es la prueba de tipo de la comunicación y reduce el riesgo de problemas en la integración, pero el FAT y el SAT se basan en los requisitos de un proyecto concreto, los hace el integrador y normalmente los presencia el cliente.