holdover-test (tipo de escenario)

Tipo de escenario del motor v0.40.0, familia Relojes, temporización y holdover. Consultivo: salida de análisis de una herramienta de investigación e ingeniería, no un equipo de navegación homologado ni un servicio de seguridad de la vida humana. Toda etiqueta de aquí es la del motor o la de la matriz de verificación; un tipo de escenario es MODELLED salvo que la matriz diga otra cosa (cómo se gana una etiqueta: la sección Evidence del README).

Qué hace#

Prueba de holdover MODELLED de un sistema de temporización, puntuada a partir de un registro de error de tiempo que suministra el OPERADOR (un registro de linuxptp ptp4l, phc2sys o ts2phc, un registro de seguimiento o estadísticas de chrony, un registro de reloj TICC, TimeLab o RINEX, o pares time_s,time_error_ns). La prueba tiene cuatro pasos y Kshana no realiza ninguno: una LÍNEA BASE con enganche, GNSS RETIRADO por el operador (el cable de antena o la salida del simulador; Kshana no transmite ni controla nada) en un instante indicado, HOLDOVER con el oscilador propio del sistema, y RECUPERACIÓN después de que el operador restablezca el GNSS en un segundo instante indicado. El registro se divide en esos dos instantes. Línea base: estadísticas de error de tiempo y las máscaras de ITU-T escritas para un reloj enganchado. Holdover: estadísticas, el desvío fraccionario de frecuencia que mantuvo el sistema (una recta de mínimos cuadrados), las máscaras escritas para holdover o para un reloj autónomo, la envolvente de holdover de ePRTC-A a partir de la duración indicada de enganche, y el tiempo hasta superar cada presupuesto de error de tiempo. Recuperación: si |TE| entró dentro de una banda indicada y cuándo, y si permaneció en ella, el máximo y el mayor salto. Todo límite se transcribe de una tabla pública de ITU-T (las máscaras de temporización de telecomunicaciones); las palabras son «medido frente a la máscara», y los dos instantes son una declaración del operador, no verificada. Un registro demasiado corto para una máscara es INCOMPLETE, nunca se extrapola. Véase docs/TIMING-HIL.md.

Una ejecución de scenarios/holdover-test-ptp4l.toml se resume así: holdover-test: holdover 1795 s, max|TE| 59,0 ns; prtc-a PASS, eprtc-a-holdover FAIL; recovered 0 s after GNSS returned (MODELLED, measured against the mask)

Entradas#

Del esquema (kshana kinds --json):

• Campos obligatorios: test, series
• Campos opcionales: masks, budgets

El ejemplo scenarios/holdover-test-ptp4l.toml establece, entre otros:

Ejecútelo#

kshana scenarios/holdover-test-ptp4l.toml

2 escenarios incluidos usan este tipo de escenario; los demás están en scenarios/.

Qué proporciona#

Los resultados escalares de esa ejecución, con las unidades que indica el motor:

Etiqueta del resultado (la del motor): MODELLED — una prueba de holdover puntuada a partir de un registro de error de tiempo suministrado por el operador. Todo límite se transcribe de la Recomendación pública de ITU-T nombrada y el resultado se mide frente a la máscara; no dice nada sobre si algún reloj o sistema satisface una Recomendación, y nadie lo ha calificado ni aprob

Evidencias#

MODELLED: las filas de la matriz de verificación que nombran este tipo de escenario.

• MODELLED El tipo de escenario holdover-test: un registro de error de tiempo (un registro de reloj de linuxptp, chrony, TICC, TimeLab o RINEX, o pares time_s,time_error_ns) se divide en los dos instantes que indica el operador para la retirada y el restablecimiento del GNSS en una línea base, un holdover y

Las filas que la propia ejecución puso a prueba, con la referencia independiente que da la matriz a cada una (las fuentes públicas se nombran allí):

• MODELLED Determinista, con hash de escenario, SBOM + barreras golden multiplataforma. Referencia independiente (ExternalDataset): ajuste a la norma del SBOM al esquema JSON oficial de CycloneDX 1,5 (+ identificadores SPDX válidos) — un estándar externo publicado, cero errores de validación en todo el grafo de dependencias; la parte de determinismo de FoM / reproducibilidad byte a byte sigue siendo una comprobación de autoconsistencia fijada, por lo que la fila sigue siendo MODELLED
• VALIDATED El error máximo de intervalo de tiempo y la desviación de tiempo que informa el tipo de escenario telecom-timing, en un registro de holdover de escala de telecomunicaciones: una cola monótona deslizante O(n). Referencia independiente (ExternalDataset): allantools 2024,06 — una biblioteca independiente de terceros de estabilidad de frecuencia — mtie() y tdev() sobre tests/fixtures/telecom_timing/holdover_te_series.csv, con la serie analizada a partir del mismo texto de 17 cifras significativas en ambos lados; la referencia registra el SHA-256 de la serie y es regenerable sin conexión mediante tests/fixtures/telecom_timing/generate_telecom_timing_reference.py. Valida los ESTIMADORES en este registro, no el sin
• MODELLED Límites transcritos de ITU-T G.8272 (07/2025) PRTC-A/B, G.8272.1 (2024) Amd. 1 (07/2025) ePRTC bloqueado y ePRTC-A en holdover (incluida la envolvente de error de tiempo de la Tabla 3. Referencia independiente (InternalConsistency): Transcripción de las Recomendaciones citadas (de descarga libre en itu.int), con cada límite acompañado de su tabla o cláusula, y con cada elemento sin confirmar o sin implementar listado en docs/TELECOM-TIMING.md; las identidades de continuidad en los puntos de ruptura que implican las tablas se comprueban en las pruebas. Una transcripción de normas con comprobaciones de coherencia interna, no una prueba de ajuste a la norma ni una validación externa. 0,30 round 2 (pre-register
• MODELLED El tipo de escenario holdover-test: un registro de error de tiempo (un registro de reloj de linuxptp, chrony, TICC, TimeLab o RINEX, o pares time_s,time_error_ns) se divide en los dos instantes en que th. Referencia independiente (InternalConsistency): Cálculo manual sobre registros construidos a partir de fórmulas cuya pendiente, escalón, extremo y tiempo de recuperación se conocen antes de la ejecución (las pruebas los indican), y las máscaras, la envolvente y los presupuestos de las filas de temporización de telecomunicaciones anteriores. No se puntuó ninguna medición de laboratorio de un holdover real ni se comparó con ninguna referencia independiente externa, por lo que el tipo de escenario no afirma nada sobre ningún reloj o sistema; se necesita un socio de laboratorio de temporización antes de cualquier per-clock-class fi

Limitaciones#

Lo que el propio informe de la ejecución dice que no está modelado o no está validado:

• MODELLED: una prueba de holdover puntuada a partir de un registro de error de tiempo aportado por el operador. Cada límite está transcrito de la Recomendación pública ITU-T citada y el resultado se mide frente a la máscara; no dice nada sobre si algún reloj o sistema satisface una Recomendación, y nadie lo ha calificado ni aprobado. Los instantes en que se retiró y se restableció el GNSS son una declaración del operador y no están verificados. Software de carácter consultivo (resultado label)
• Prueba de holdover MODELLED de un sistema de temporización, puntuada a partir de un registro de error de tiempo que aporta el OPERADOR (un registro ptp4l, phc2sys o ts2phc de linuxptp, un registro de tracking o de estadísticas de chrony, un registro de reloj de TICC, TimeLab o RINEX, o pares time_s,time_error_ns). (catálogo de tipos de escenario (kshana kinds --json))
• La reproducibilidad y el aseguramiento del software son MODELLED, no están validados: una subafirmación se comprueba externamente, pero la capacidad completa compone piezas modeladas, por lo que la capacidad sigue siendo modelada. (matriz de verificación (docs/MODELLED-RATIONALE.md))
• Las máscaras de sincronización de telecomunicaciones ITU-T con PASS/FAIL y margen son MODELLED, no validadas: se comprueban frente a su propia identidad analítica o de forma cerrada, lo que detecta errores de transcripción y de coeficientes, pero no es una referencia independiente externa. (matriz de verificación (docs/MODELLED-RATIONALE.md))
• La prueba de holdover puntuada a partir de un registro de error de tiempo aportado por el operador es MODELLED, no validada: se comprueba frente a su propia identidad analítica o de forma cerrada, lo que detecta errores de transcripción y de coeficientes, pero no es una referencia independiente externa. (matriz de verificación (docs/MODELLED-RATIONALE.md))

Véase también#

• Página de familia: Relojes, temporización y holdover
• Todos los tipos de escenario: KINDS.md
• Página temática: TIMING-HIL.md
• Página temática: HARDWARE-SAFETY.md