Preguntas técnicas del equipo — respuestas

Sí, viene por defecto. El estándar IEEE C37.111 obliga a que el archivo .CFG incluya dos líneas de tiempo que el RC10 escribe automáticamente:

Formato dd/mm/aaaa,hh:mm:ss.ssssss con resolución de microsegundos. De la diferencia entre ambas líneas nuestro validador calcula los ciclos pre-falla.

El matiz importante: el timestamp lo escribe el reloj interno (RTC) del recloser. El archivo es tan preciso como ese reloj. Si el RTC está en hora local o desviado, el registro queda mal estampado — el archivo no "sabe" corregirlo.

Además, el formato 1999 no tiene campo estándar para declarar el offset UTC (el 2013 sí lo agregó: time_code). Por eso nuestro validador marca "UTC time code not found" en los registros de Verona: no es un error del equipo, es una limitación del formato 1999. La práctica correcta es operar el reloj del RC10 directamente en UTC y documentar la fuente de sincronización (ver pregunta 8).

Son dos archivos complementarios:

• .CFG — texto plano legible: estación, lista de canales con factores de escala (valor real = a·x + b, en unidades primarias), frecuencia, tasa de muestreo (1600 sps en NOJA = 32 muestras/ciclo) y los dos timestamps.
• .DAT — binario (formato binario 1999): por cada muestra → n° de muestra (4 bytes) + marca de tiempo (4 bytes) + un entero de 16 bits por canal analógico. Compacto (~21 kB por registro de Verona) pero no legible a ojo.

Con qué se abren: nuestro comtrade_validator.py (parsea el CFG completo y verifica el DAT), el software NOJA PQS, y cualquier visor estándar de oscilografías: Wavewin, SIGRA, TOP, o la librería comtrade de Python para análisis propio.

Si al equipo le sirve, podemos agregar un visor de formas de onda en el dashboard (graficar los canales del DAT) — es trabajo acotado.

Fácil — es scripting, no re-medición. El 2013 es retrocompatible con el 1999: las muestras binarias del .DAT no cambian. La conversión consiste esencialmente en reescribir el encabezado del .CFG: año de revisión (1999→2013) y agregar los campos nuevos (time_code con el offset UTC, calidad de tiempo). Estimación: 1–2 días para añadirlo como paso automático del pipeline, validado.

Sobre el "todo en un archivo": sí existe — el 2013 introduce el contenedor .CFF (Combined File Format) que empaqueta CFG+DAT+HDR+INF en un solo archivo. Pero ojo: la carta DE 03474-26 exige explícitamente .CFG y .DAT como archivos obligatorios (separados). Entregar un .CFF podría no corresponder a lo pedido. Conclusión práctica:

• Si el CEN acepta 1999 → entregamos lo nativo del NOJA (cero conversión).
• Si exige 2013 → activamos el conversor (CFG reescrito + DAT intacto, separados).
• .CFF solo si el CEN lo pidiera expresamente (improbable, dado el texto de la carta).

Son dos procesos independientes que corren en paralelo — el Modbus watcher NO depende del FTP.

• Modbus watcher (continuo): sondea el outstation Modbus del RC10 cada 2 segundos, leyendo los 17 puntos binarios mapeados (posición del interruptor, disparo, arranque, autoreenganche, lockout, protección ON, etc.). Registra solo los cambios (detección de flanco 0→1 / 1→0) con timestamp UTC, los guarda en modbus_events.csv y sube los eventos tipo disparo/arranque/AR al dashboard. Mientras no hay falla, está en silencio observando.
• FTP pull (periódico): tarea programada que cada 10 minutos baja los archivos COMTRADE nuevos, los valida y los registra.

¿Cómo se relacionan? Por timestamp, después: cuando ocurre una falla, el watcher la ve en segundos (señal binaria en vivo) y el archivo COMTRADE de esa misma falla llega en el siguiente pull (≤10 min). Ambos quedan correlacionados por fecha/hora en el repositorio.

Mejora opcional (fácil): que un disparo detectado por Modbus gatille un pull FTP inmediato en vez de esperar el ciclo — extracción "event-driven". Lo añadimos cuando quieran.

Cada 10 minutos (tarea programada GridVault-Verona-Pull, corre sola, sobrevive reinicios).

Por qué 10 min: con la captura configurada en 1,0 s, la memoria interna del RC10 solo guarda 3 oscilografías con sobrescritura activada (dato del manual NOJA). Hay que extraer antes de que un evento nuevo sobrescriba uno antiguo. Como las fallas no ocurren cada minutos, 10 min da margen muy holgado, y el pull es idempotente: si no hay archivos nuevos no hace nada, y nunca duplica registros (deduplicación local + contra la base de datos).

El intervalo es un parámetro (se puede bajar a 5 min o menos sin problema — la carga sobre el recloser es mínima, es solo un listado FTP). El respaldo adicional es activar "Guardar en USB" en el RC10 (hasta 500 archivos/día) como buffer secundario.

Hay tres hitos con entregables distintos:

El paquete por evento (lo que físicamente queda en el repositorio por cada falla):

1. .CFG + .DAT renombrados al formato FechaInicio,HoraInicio,Subestacion,PMGD y con canales estandarizados vía diccionario.
2. Reporte de validación (PASS/WARN/FAIL contra cada requisito).
3. Extracto de señales binarias (disparo/arranque/AR del Modbus + registro de eventos), porque la oscilografía NOJA es solo-analógica — con la justificación técnica de limitación ya redactada.
4. Checksum SHA-256 + entrada en la bitácora de auditoría.

Importante: el CEN aún no publica el mecanismo del SLRP (su repositorio). Hasta entonces, el repositorio externo propio + evidencia es lo exigible — y es exactamente lo que ya corre en Verona.

La carta exige que los registros estén estampados en UTC ±00:00, con sincronización "GPS o equivalente". El propósito: que las oscilografías de cualquier instalación del sistema se puedan correlacionar entre sí en una misma línea de tiempo (una falla vista por varios equipos debe calzar al milisegundo).

Implicaciones prácticas:

• Chile usa hora local UTC-3/UTC-4 (con cambio estacional). El reloj del RC10 debe operar directamente en UTC, no en hora local — porque el formato 1999 no tiene campo para declarar el offset (pregunta 1), y porque los cambios de hora estacionales romperían la correlación.
• No basta ponerlo en hora una vez: los relojes internos (RTC) derivan (típicamente segundos por mes) → se necesita resincronización periódica documentada.

En los registros reales de Verona el validador encontró que no hay código UTC y la fuente de sincronización no está confirmada → es el gap técnico abierto de Verona, con plan claro (pregunta 8).

Sí podemos actualizar el reloj: CMS tiene el botón "Sincronizar Fecha & Hora" (lo vimos en Operaciones con Conexión) que empuja la hora del PC al RC10. Pero es un ajuste puntual — el RTC luego deriva. Las opciones reales, evaluadas:

Plan Verona (orden):

1. Ahora: poner el reloj del RC10 en UTC (sync puntual desde CMS, con cuidado del offset) → los próximos registros ya salen bien estampados.
2. Consulta al CEN: ¿NTP documentado califica como "equivalente"? (pregunta 10)
3. Según respuesta: si NTP basta → automatizar opción A. Si exigen GPS → opción C (Teltonika GPS-NTP).

Estas no las podemos resolver nosotros ni el vendor — van como consultas formales en el plan ConectaCEN (ya redactadas en el paquete de presentación):

1. Versión COMTRADE: ¿se acepta 1999 (nativo del NOJA RC10) o se exige 2013? (Si exigen 2013, activamos el conversor — pregunta 3.)
2. Señales binarias: cuando el equipo no las incluye en la oscilografía (caso NOJA, solo-analógica por diseño), ¿se acepta la entrega combinada COMTRADE + registro de eventos/Modbus con justificación técnica?
3. Sincronización: ¿"GPS o equivalente" admite NTP documentado? ¿Qué exactitud mínima exigen?
4. SLRP: mecanismo, API y fecha del repositorio del CEN; ¿el repositorio propio es válido hasta entonces?
5. Retención: ¿cuánto tiempo deben conservarse los archivos?
6. Muestreo: ¿exigen las 20 muestras/ciclo "deseadas" o basta el mínimo 16? (Académica para nosotros: el RC10 da 32 — cumplimos igual.)
7. Nombres Infotécnica: validación de los nombres exactos de subestación y PMGD para el formato de archivo.