Hardware-in-the-loop de temporización: desconectar la antena, puntuar el holdover

Los operadores de telecomunicaciones y de energía ensayan un sistema de temporización retirándole el GNSS y observando qué hace el reloj. Kshana no hace eso por ellos, y no toca sus equipos. Lee el registro de error de tiempo que produjeron los propios instrumentos del operador, lo divide en los dos instantes que declara el operador y mide cada paso frente a máscaras públicas de la ITU-T. El tipo de escenario es holdover-test; los escenarios de ejemplo son scenarios/holdover-test-example.toml y scenarios/holdover-test-ptp4l.toml.

Esta es la etapa 1 de seguridad del hardware: pasiva, solo de recepción, sin RF de Kshana (HARDWARE-SAFETY.md). Software de carácter consultivo, no un equipo homologado. Nadie ha calificado, aprobado ni revisado este procedimiento, y no dice nada sobre si un sistema satisface una Recomendación.

El procedimiento#

El operador ejecuta cuatro pasos. Kshana no realiza ninguno de ellos.

Dos cosas que debe hacer el operador, porque Kshana no puede:

• Declarar los dos instantes. gnss_removed_s y gnss_restored_s son una declaración del operador. Kshana no detecta la retirada a partir del registro y no verifica los instantes. Un instante erróneo desplaza los límites de los pasos y, con ello, el resultado.
• Use el mismo reloj para el registro y para los instantes. En un registro de reloj, el eje de tiempo empieza en la primera lectura, de modo que los dos instantes son segundos desde la primera línea del registro.

Qué registrar#

Cualquiera de estos, mediante los lectores clock_log existentes (CLOCK-LOG-FORMATS.md):

Importa lo que mide el registro. Un registro de servo (linuxptp, chrony) registra el desfase que midió el demonio y que está corrigiendo: es el error de tiempo que queda bajo control del servo, no una medición independiente del reloj frente a UTC. Durante el paso de holdover de un ensayo que retira realmente la referencia, un registro de servo sigue mostrando lo que creía el demonio, que puede diferir del error real. Un TICC u otro contador frente a una referencia independiente es el registro más sólido; indique cuál usó al informar del resultado.

El escenario#

kind = "holdover-test"
masks = ["prtc-a", "eprtc-a-holdover"]      # see docs/TELECOM-TIMING.md for the ids

[test]
gnss_removed_s = 600.0                      # the operator's statement
gnss_restored_s = 2400.0                    # omit if GNSS was not restored within the record
locked_duration_days = 5.0                  # how long it was locked before step 2 (sets the ePRTC-A period)
recovery_band_ns = 100.0                    # |TE| inside this counts as recovered
recovery_dwell_s = 60.0                     # ... and must stay inside this long

[series.clock_log]                          # or [series] samples = [[t, ns], ...] or csv_path = "..."
format = "ptp4l"
path = "holdover-2026-11-02.log"            # or text = "..." inline

kshana holdover-test.toml

Claves opcionales: budgets (nombre, max_abs_te_ns, origen; los valores por defecto de telecom-timing cuando faltan) y clock = "..." dentro de [series.clock_log] para elegir un origen de un registro que contiene varios.

Qué contiene el informe#

• steps: para la línea base, el holdover y la recuperación, el inicio y el fin, el número de muestras y los valores medio, rms, mayor y final del error de tiempo.
• masks: cada máscara que nombró, medida en el paso que nombra su condición. Una máscara escrita para un reloj bloqueado se mide en la línea base; una escrita para holdover o para un reloj autónomo, en el holdover. Cada comprobación lleva su límite, el valor medido, el margen y la tabla de la que se transcribe. Una máscara que necesita un registro más largo del que dio el paso es INCOMPLETE, nunca extrapolada; una que el motor no puede evaluar para el intervalo de muestreo del registro es NOT-EVALUATED con el motivo.
• holdover: el desfase fraccionario de frecuencia que mantuvo el sistema (la pendiente de una recta de mínimos cuadrados a través del error de tiempo del holdover, en ns/s, que son partes por mil millones), el residuo respecto de esa recta, el mayor error de tiempo absoluto y cuándo se produjo, y el salto en el momento de la retirada.
• holdover_envelope: la envolvente de holdover de ePRTC-A de la Tabla 3 de ITU-T G.8272.1, a partir de locked_duration_days, con el instante en que se supera por primera vez.
• budgets: el tiempo transcurrido tras la retirada en el que se supera por primera vez cada presupuesto de error de tiempo.
• recovery: si |TE| entró en la banda y permaneció en ella durante el tiempo de permanencia, cuánto después de que volviera GNSS empezó eso, el pico tras el restablecimiento y el mayor salto entre muestras consecutivas durante la recuperación.
• curves: MTIE y TDEV de los pasos de línea base y de holdover.
• verdicts: un resumen de una palabra por paso.

Cada número lleva su unidad y su procedencia en el bloque units del informe.

Las palabras y los límites#

• El resultado se mide frente a la máscara. Las máscaras se transcriben de Recomendaciones de la ITU-T de descarga libre (las mismas tablas que el tipo telecom-timing, enumeradas en TELECOM-TIMING.md), y toda entrada que las Recomendaciones dejan "for further study" está ausente, no rellenada. Kshana no afirma que un reloj o un sistema satisfaga una Recomendación ni que esté aprobado frente a ella, y el informe tampoco.
• MODELLED. La lógica de pasos, el ajuste de recta y la regla de recuperación se comprueban sobre registros construidos a partir de fórmulas cuyas respuestas se conocen antes de la ejecución; ningún holdover de laboratorio se ha puntuado frente a una referencia independiente externa, y ningún socio ni laboratorio ha acordado nada. Haría falta un laboratorio de temporización antes de poder promover cualquier cifra por clase de reloj.
• Lo que no se cubre, indicado en todos los informes: si GNSS se retiró y se restableció realmente en los instantes declarados; cualquier paso que el operador no registró; las máscaras definidas mediante un filtro de 0,1 Hz para un registro muestreado más despacio que una vez por segundo; la propia incertidumbre de medición del instrumento; y cualquier procedimiento de una Recomendación que vaya más allá de un registro de error de tiempo (perfiles de temperatura, carga de la red de paquetes).
• La banda de recuperación es una elección propia del ensayo. El valor por defecto de 100 ns es el error de tiempo absoluto máximo de un PRTC-A (ITU-T G.8272); es una línea cómoda, no un requisito de ninguna Recomendación para la recuperación.
• Sin ruta de transmisión. Kshana lee archivos. No genera ninguna señal, y retirar GNSS en un laboratorio se hace con el equipo propio del laboratorio y bajo su propia autorización.

Superficies#

holdover-test es un tipo de escenario, de modo que se ejecuta en todos los lugares donde se ejecutan los tipos: kshana <scenario.toml>, la API de Rust (kshana::api::run_toml), el enlace de Python (kshana.run), la compilación de WebAssembly y npm (samples o clock_log.text en línea; las claves de archivo no están disponibles allí), el servidor MCP (run_scenario, solo contenido en línea) y el ejecutor de escenarios de Kshana Studio. Los dos archivos de escenario vienen incluidos (kshana example holdover-test-example).