Una falla en un sistema de potencia se despeja en milisegundos. Las protecciones actúan, aíslan lo que tienen que aislar y el sistema queda como queda. El trabajo humano empieza después, y ahí el reloj corre distinto.
En República Dominicana ese plazo está escrito. El Reglamento para la Aplicación de la Ley General de Electricidad, en su artículo 215, obliga al Centro de Control de Energía a entregar al Organismo Coordinador y a la Superintendencia de Electricidad, dentro de las 24 horas siguientes a la indisponibilidad forzada de una instalación del SENI, un informe detallado que establezca la actuación de las protecciones, los registros de frecuencia, los registros de tensiones y los demás datos que permitan esclarecer el hecho.
Entre el evento de milisegundos y el informe de 24 horas está todo lo que este artículo explica. Y conviene saber que buena parte de ese trabajo se gana o se pierde meses antes, cuando se configuró el sistema.
Lo que la norma pide y lo que la norma no dice
El artículo 215 es preciso sobre el resultado y silencioso sobre el medio. Pide la actuación de las protecciones y los registros, con un plazo. No dice en qué formato, ni con qué resolución, ni con qué sincronización se obtienen.
Lo comprobamos sobre el texto completo del Reglamento. Las palabras «oscilografía», «secuencia de eventos», «registro de eventos», «milisegundo» y «estampa de tiempo» no aparecen ni una vez. Las dos menciones de sincronización se refieren a unidades de generación, no a relojes.
Eso no es un defecto del Reglamento, que regula obligaciones y no ingeniería. Es una descripción del punto donde el Reglamento deja de decidirlo y pasa a decidirlo el diseño. Quien tiene que cumplir el plazo es quien tiene que haber preparado el sistema para poder cumplirlo, y eso no se improvisa la mañana siguiente a un evento.
Hay un segundo artículo que conviene distinguir, porque es el que se cita casi siempre cuando se habla de esto. El artículo 216 faculta al Organismo Coordinador a convocar a los Agentes del Mercado Eléctrico Mayorista para el análisis de fallas por incidencias, y dice «podrá», o sea que es una facultad y no una obligación automática. El plazo de las 24 horas no está ahí, está en el 215.
Qué registra realmente una protección
Alrededor de una falla no queda un registro, quedan tres, y son de naturaleza distinta.
La oscilografía es la forma de onda. Corrientes y tensiones muestreadas a alta frecuencia durante una ventana corta alrededor del evento, con algo de prefalla, la falla y algo de posfalla. Es lo que permite ver qué ocurrió eléctricamente, distinguir una falla monofásica de una trifásica, calcular la distancia al punto de falla y comprobar si la protección actuó por lo que creía.
La secuencia de eventos, que en la jerga se llama SOE por sus siglas en inglés, es otra cosa. No son ondas, son marcas de tiempo. Este contacto cambió de estado en este instante, este disparo se emitió en este otro, y este interruptor confirmó apertura en un tercero. Es la película en vez de la fotografía.
El registro de eventos y alarmas del sistema de supervisión es la tercera capa, y suele ser la más pobre en resolución y la más rica en contexto, porque incluye lo que el operador vio y lo que el operador hizo.
Reconstruir una falla es cruzar las tres. La oscilografía dice qué pasó eléctricamente, la secuencia de eventos dice en qué orden, y el registro del sistema dice qué se estaba haciendo cuando pasó. Con una sola de las tres se puede contar una historia, pero casi nunca es la historia completa.
Por qué el dato existe y aun así no se analiza
Esta es la parte incómoda, y no tiene que ver con la tecnología.
En la mayoría de las instalaciones que hemos visto, el dato está. Los relés registran, los sistemas guardan, los equipos hacen su trabajo. Lo que falla es todo lo que hay alrededor.
- Nadie ha descargado un registro en meses, así que no se sabe si la descarga funciona hasta el día en que hace falta.
- Los ajustes de disparo del registrador están en los valores de fábrica, o en unos que alguien puso en la puesta en marcha y nadie revisó, así que la ventana no cubre lo que hay que ver.
- La memoria del equipo se llenó y lleva meses sobreescribiendo los registros viejos con los nuevos, que es el comportamiento normal y esperado.
- El fichero se descarga pero nadie sabe abrirlo, porque el software del fabricante está en una computadora que ya no existe o con una licencia que venció.
- La documentación no corresponde a la instalación real. Lo encontramos con frecuencia en campo, y casi siempre por la misma razón, que es un arreglo temporal hecho para resolver una emergencia y que se quedó de forma permanente sin que nadie actualizara el plano.
De todas, la que más daño hace a largo plazo es la ausencia de auditoría sobre la calidad de las señales que envían los equipos. Rara vez se comprueba de forma periódica que lo que el sistema recibe es lo que el equipo cree estar enviando, y esa comprobación no se puede hacer el día de la falla, porque el día de la falla lo que hay es lo que hay.
El tiempo común, que decide si hay secuencia o no
Sin un reloj compartido no hay secuencia de eventos. Y sin secuencia, la causa se vuelve muy difícil de sostener, porque establecer qué pasó primero es lo que separa la causa del efecto.
El mejor argumento sobre esto no es teórico, es histórico. El informe final del apagón que dejó sin luz a buena parte de Estados Unidos y Canadá en agosto de 2003 dedicó una recomendación entera a exigir registradores sincronizados, y explicó por qué con una franqueza poco habitual en un documento oficial. Los investigadores tuvieron que ordenar miles de datos a mano para determinar la secuencia de los hechos, y concluyeron que el proceso habría sido mucho más rápido y sencillo con un uso más amplio de dispositivos de registro sincronizados. En la misma página está el diagnóstico que lo motivó, y es que aquel 14 de agosto los registradores de tiempo se usaban con frecuencia pero no estaban sincronizados a un patrón.
¿De cuánta precisión hablamos? Aquí hay que tener cuidado con las cifras que circulan. La norma internacional de referencia para comunicaciones en subestaciones, en su parte 5, no da un número único: clasifica la exigencia de sincronismo en clases y separa la clase que aplica al sellado de tiempo de la que aplica al muestreo, porque no son el mismo problema. Como referencia de orden de magnitud, la norma norteamericana NERC PRC-002 sí fija un valor y exige que los relojes de los registradores estén dentro de ±2 milisegundos de UTC, aunque conviene decir que esa norma rige el sistema eléctrico de Norteamérica y no aplica en República Dominicana.
Cómo se consigue ese reloj común es un tema en sí mismo, con su propio menú de opciones, y lo tratamos aparte. Lo que importa aquí es la consecuencia: si los relojes derivan más de lo que separa dos eventos, la secuencia que se reconstruya será una secuencia falsa, y una secuencia falsa produce una conclusión falsa con toda la apariencia de un análisis serio.
COMTRADE, y qué resuelve de verdad
Cuando varios fabricantes conviven en la misma subestación, cada uno registra en su propio formato. Ese problema tiene una norma, y conviene saber exactamente qué resuelve y qué no.
Se llama COMTRADE, y es un caso curioso porque es un solo documento con dos referencias: IEC 60255-24 e IEEE C37.111, revisadas conjuntamente bajo un acuerdo de doble logo entre los dos organismos. La edición de 2013 es la última publicada, y su estado depende de por dónde se mire. La IEC la mantiene vigente, con fecha de estabilidad en 2028, y la IEEE reclasificó su referencia como inactiva en marzo de 2024, que es un movimiento de catálogo y no una retirada del formato.
Define un formato común para ficheros que contienen formas de onda transitorias y datos de eventos recogidos de sistemas de potencia. Y tiene una frase en su alcance que vale más que todo lo que se escribe alrededor de ella:
No es una norma para transferir ficheros de datos a través de redes de comunicación.
O sea que COMTRADE normaliza el fichero, no el transporte. Busca que lo que llegue se pueda leer con herramientas de distintos fabricantes, y no dice nada sobre cómo llega. Quien quiera automatizar la recolección de registros necesita otra capa encima, y esa capa es donde se decide si el proceso funciona sin que nadie viaje a la subestación.
Dos precisiones más, porque son las que evitan una expectativa equivocada.
La primera es que su uso es voluntario. La propia norma aclara que ni IEC ni IEEE certifican conformidad, y de hecho existe precisamente porque cada equipo genera su formato propietario. Que un relé exporte COMTRADE depende del fabricante y del modelo, y es una pregunta que se hace antes de comprar, no después.
La segunda es que la edición de 2013 trajo dos cosas útiles que las anteriores no tenían. Una es el fichero único con extensión .CFF, en lugar de los cuatro ficheros separados de antes. La otra son los campos que llevan el desfase respecto a UTC y la calidad de tiempo de las muestras. Un registro en formato de 2013 puede viajar, por tanto, declarando la calidad de su propio reloj. En el parque instalado siguen conviviendo ediciones anteriores, y eso es algo que vemos con frecuencia aunque no sea un dato que podamos cuantificar.
Hay incluso una norma aparte solo para el nombre del fichero, la IEEE C37.232, que COMTRADE cita entre sus referencias normativas. Parece un detalle menor hasta que alguien tiene que ordenar los ficheros de una decena de equipos distintos y descubre que el nombre era la mitad del problema.
Del registro al informe
Reconstruir una falla, en la práctica, es este recorrido.
| Paso | Qué se hace | Dónde se rompe |
|---|---|---|
| Recolección | Traer los registros de todos los equipos implicados | El equipo no es accesible remotamente, o la descarga nunca se probó |
| Normalización | Llevar todo a un formato común y a una base de tiempo común | Relojes que derivaron, o formatos propietarios sin exportación |
| Ordenamiento | Construir la secuencia real de lo que ocurrió | Resolución insuficiente para distinguir qué fue antes |
| Análisis | Distinguir la causa de las consecuencias | Falta contexto de operación, o falta la prefalla |
| Informe | Escribir lo que pasó, con evidencia | Se entrega a tiempo lo que se pudo, no lo que hacía falta |
La fila que más se subestima es la segunda. Normalizar suena a trámite y es donde se decide si el análisis es posible, porque una vez que los registros están en escalas de tiempo incompatibles no hay software que lo arregle de forma fiable después.
Y hay una diferencia de fondo entre las dos primeras filas y las tres últimas. Las tres últimas dependen de quién analiza, o sea de criterio y experiencia. Las dos primeras dependen de cómo se diseñó y se configuró el sistema, meses o años antes, y ninguna cantidad de talento el día del evento compensa un sistema que no guardó lo que había que guardar.
Cómo se prepara esto antes de que haga falta
Lo que sigue es criterio nuestro, no obligación reglamentaria, y conviene decirlo así.
Un sistema preparado para analizar fallas tiene resueltas cinco cosas antes de que ocurra la primera. Acceso remoto probado a todos los equipos que registran, y probado quiere decir que alguien descargó un registro este trimestre. Una base de tiempo común, con su método declarado y verificado. Ajustes de ventana y de disparo revisados contra lo que se quiere poder ver, no contra los valores de fábrica. Un procedimiento escrito de recolección, que diga quién descarga qué y en qué orden cuando suena el teléfono. Y documentación que corresponda a la instalación real, con un mecanismo para mantenerla así.
Ninguna de las cinco es cara comparada con el sistema que protege. Las cinco se vuelven imposibles el día del evento.
En proyectos donde conviven equipos de varias marcas, esto se cruza con otro problema que tratamos aparte, el de conectar tecnologías de distintos fabricantes, porque la recolección de registros es justamente uno de los puntos donde la integración multimarca se nota o se sufre.
El contexto dominicano
En República Dominicana el análisis de fallas mayores tiene un espacio institucional. La Superintendencia de Electricidad publica la composición del Comité de Fallas del SENI, que reúne al Ministerio de Energía y Minas, a la propia SIE, al Organismo Coordinador, a la Empresa de Transmisión Eléctrica Dominicana, a las distribuidoras y a los generadores. Según la propia SIE, el comité elabora los informes técnicos correspondientes y sus resultados se comunican a la ciudadanía conforme van siendo concluyentes.
Ese comité trabaja con lo que los agentes puedan aportar. Y lo que cada agente puede aportar es exactamente lo que su sistema registró y lo que puede recuperar en el plazo que se le pide.
Quien haya trabajado en la operación del sistema nacional conoce la diferencia entre las dos situaciones. Entre 2004 y 2007 trabajé en ETED, en la tercera fase del proyecto del Centro de Control de Energía, como encargado del sistema SCADA nacional. Una parte central de ese trabajo era dar soporte al Departamento de RTU y a los agentes del sistema para asegurar el correcto envío de las señales de telemetría. Esa tarea, la de vigilar que lo que llega sea lo que se envió, es la misma que años después decide si una falla se puede reconstruir o no. No es glamorosa y no se nota mientras funciona.
Preguntas frecuentes
¿Cómo se realiza el análisis de una falla eléctrica?
Recolectando los registros de todos los equipos implicados, llevándolos a un formato y una base de tiempo comunes, ordenando la secuencia real de lo ocurrido y separando la causa de sus consecuencias. La calidad del resultado depende sobre todo de los dos primeros pasos, que se deciden al configurar el sistema y no el día del evento.
¿Qué es la oscilografía de un relé?
Es el registro de las formas de onda de corriente y tensión que el relé captura alrededor de una falla, con una parte de prefalla y otra de posfalla. Permite ver qué ocurrió eléctricamente y comprobar si la protección actuó por la causa que creía.
¿Qué diferencia hay entre la oscilografía y la secuencia de eventos?
La oscilografía son formas de onda y responde qué pasó eléctricamente. La secuencia de eventos son marcas de tiempo de cambios de estado y responde en qué orden pasó. Para determinar una causa casi siempre hacen falta las dos.
¿Qué es COMTRADE y para qué sirve?
Es el formato común para intercambio de datos de fallas transitorias, publicado conjuntamente como IEC 60255-24 e IEEE C37.111. Sirve para que un registro generado por un equipo se pueda leer con la herramienta de otro. No cubre la transferencia por red, así que automatizar la descarga de registros requiere resolver esa parte por separado.
¿Cuánto tiempo hay para entregar un informe de falla en República Dominicana?
El Reglamento de la Ley General de Electricidad, en su artículo 215, da 24 horas al Centro de Control de Energía para entregar al Organismo Coordinador y a la Superintendencia de Electricidad un informe detallado con la actuación de las protecciones y los registros, cuando ocurre la indisponibilidad forzada de una instalación del SENI.
¿Qué precisión de reloj hace falta para que la secuencia sea confiable?
Depende de la aplicación. La parte 5 de la IEC 61850 lo trata por clases y distingue la exigencia del sellado de eventos de la del muestreo. Como referencia, la norma norteamericana NERC PRC-002 exige que los relojes de los registradores estén dentro de ±2 milisegundos de UTC, si bien esa norma no rige en República Dominicana.
Conversemos sobre su sistema
Si tiene una instalación donde el análisis de una falla dependería de registros que nadie ha descargado en meses, esa conversación conviene tenerla antes del próximo evento.
Revisamos qué registra hoy su sistema, qué se podría recuperar en el plazo que se le pida y qué falta para que la secuencia sea reconstruible. Así trabajamos la automatización y el control de sistemas eléctricos, y el recorrido completo de un proyecto está en nuestra metodología de trabajo.
Soluciones TASC integra soluciones con fabricantes reconocidos. El respaldo, soporte y garantía directa de fabricante aplica según la solución implementada.
