holdover-test (tipo de cenário)

Tipo de cenário do motor v0.40.0, família Relógios, temporização e holdover. Consultivo: saída de análise de uma ferramenta de pesquisa e engenharia, não um equipamento de navegação homologado e não um serviço de segurança da vida humana. Todo rótulo aqui é do motor ou da matriz de verificação; um tipo de cenário é MODELLED, a menos que a matriz diga outra coisa (como um rótulo é conquistado: a seção Evidence do README).

O que faz#

Teste de holdover MODELLED de um sistema de temporização, pontuado a partir de um registro de erro de tempo que o OPERADOR fornece (um log do ptp4l, phc2sys ou ts2phc do linuxptp, um log de tracking ou statistics do chrony, um log de relógio TICC, TimeLab ou RINEX, ou pares time_s,time_error_ns). O teste tem quatro etapas e o Kshana não executa nenhuma delas: uma LINHA DE BASE travada, GNSS REMOVIDO pelo operador (o cabo da antena ou a saída do simulador; o Kshana não transmite nem aciona nada) em um instante declarado, HOLDOVER no oscilador próprio do sistema e RECUPERAÇÃO depois que o operador restabelece o GNSS em um segundo instante declarado. O registro é dividido nesses dois instantes. Linha de base: estatísticas de erro de tempo e as máscaras da ITU-T escritas para um relógio travado. Holdover: estatísticas, o desvio fracionário de frequência que o sistema manteve (uma reta de mínimos quadrados), as máscaras escritas para holdover ou para um relógio autônomo, o envelope de holdover do ePRTC-A a partir da duração travada declarada e o tempo para exceder cada orçamento de erro de tempo. Recuperação: se e quando |TE| entrou em uma faixa declarada e permaneceu nela, o pico e o maior degrau. Todo limite é transcrito de uma tabela pública da ITU-T (as máscaras de temporização de telecomunicações); as palavras são 'medido em relação à máscara', e os dois instantes são uma declaração do operador, não verificada. Um registro curto demais para uma máscara é INCOMPLETE, nunca extrapolado. Ver docs/TIMING-HIL.md.

Uma execução de scenarios/holdover-test-ptp4l.toml resume-se assim: holdover-test: holdover 1795 s, máx.|TE| 59,0 ns; prtc-a PASS, eprtc-a-holdover FAIL; recuperado 0 s após o retorno do GNSS (MODELLED, medido em relação à máscara)

Entradas#

A partir do esquema (kshana kinds --json):

• Campos obrigatórios: test, series
• Campos opcionais: masks, budgets

O exemplo scenarios/holdover-test-ptp4l.toml define, entre outros:

Execute#

kshana scenarios/holdover-test-ptp4l.toml

2 cenários incluídos usam este tipo de cenário; os demais estão em scenarios/.

O que ele fornece#

Os resultados escalares dessa execução, com as unidades que o motor declara:

Rótulo do resultado (o do motor): MODELLED — um teste de holdover pontuado a partir de um registro de erro de tempo fornecido pelo operador. Todo limite é transcrito da Recomendação pública da ITU-T indicada e o resultado é medido em relação à máscara; ele nada diz sobre se algum relógio ou sistema atinge uma Recomendação, e ninguém o classificou nem aprov

Evidências#

MODELLED: as linhas da matriz de verificação que nomeiam este tipo de cenário.

• MODELLED O tipo de cenário holdover-test: um registro de erro de tempo (um log de relógio linuxptp, chrony, TICC, TimeLab ou RINEX, ou pares time_s,time_error_ns) é dividido nos dois instantes que o operador declara para a remoção e o restabelecimento do GNSS em uma linha de base, um holdover e

As linhas que a própria execução exercitou, com a referência independente que a matriz dá a cada uma (as fontes públicas são nomeadas ali):

• MODELLED Portões determinísticos, com hash de cenário, de SBOM e de golden entre plataformas. Referência independente (ExternalDataset): aderência à norma do SBOM ao JSON Schema oficial do CycloneDX 1,5 (+ identificadores SPDX válidos) — um padrão externo publicado, zero erros de validação em todo o grafo de dependências; a parte de determinismo das FoMs / reprodutibilidade byte a byte continua sendo uma verificação de autoconsistência fixada, de modo que a linha permanece MODELLED
• VALIDATED O erro máximo de intervalo de tempo e o desvio de tempo que o tipo de cenário telecom-timing informa, em um registro de holdover em escala de telecomunicações: uma janela deslizante O(n) de fila monotônica. Referência independente (ExternalDataset): allantools 2024,06 — uma biblioteca independente de terceiros de estabilidade de frequência — mtie() e tdev() em tests/fixtures/telecom_timing/holdover_te_series.csv, a série analisada a partir do mesmo texto de 17 algarismos significativos em ambos os lados; a referência independente registra o SHA-256 da série e pode ser regenerada offline por tests/fixtures/telecom_timing/generate_telecom_timing_reference.py. Valida os ESTIMADORES neste registro, não o syn
• MODELLED Limites transcritos da ITU-T G.8272 (07/2025) PRTC-A/B, G.8272.1 (2024) Amd. 1 (07/2025) ePRTC travado e holdover do ePRTC-A (incluindo o envelope de erro de tempo da Tabela 3. Referência independente (InternalConsistency): Transcrição das Recomendações indicadas (disponíveis gratuitamente em itu.int), cada limite com a sua tabela ou cláusula, listada com todo item não confirmado ou não implementado em docs/TELECOM-TIMING.md; as identidades de continuidade de pontos de quebra que as tabelas implicam são verificadas nos testes. Uma transcrição de normas com verificações de consistência interna, não um teste de aderência à norma e não uma validação externa. 0,30 rodada 2 (fixada antecipada
• MODELLED O tipo de cenário holdover-test: um registro de erro de tempo (um log de relógio linuxptp, chrony, TICC, TimeLab ou RINEX, ou pares time_s,time_error_ns) é dividido nos dois instantes. Referência independente (InternalConsistency): Cálculo manual em registros construídos a partir de fórmulas cuja inclinação, degrau, extremo e tempo de recuperação são conhecidos antes da execução (os testes os declaram), e as máscaras, o envelope e os orçamentos das linhas de telecom-timing acima. Nenhuma medição de laboratório de um holdover real foi pontuada e nenhuma referência independente externa foi comparada, de modo que o tipo de cenário não faz nenhuma afirmação sobre nenhum relógio ou sistema; é preciso um parceiro de laboratório de temporização antes de qualquer fi

Limitações#

O que o próprio relatório da execução diz que não é modelado ou não é validado:

• MODELLED — um teste de holdover pontuado a partir de um registro de erro de tempo fornecido pelo operador. Todo limite é transcrito da Recomendação pública da ITU-T indicada e o resultado é medido em relação à máscara; ele nada diz sobre se algum relógio ou sistema atinge uma Recomendação, e ninguém o classificou nem aprovou. Os instantes em que o GNSS foi removido e restabelecido são uma declaração do operador e não são verificados. Software de caráter consultivo (resultado label)
• Teste de holdover MODELLED de um sistema de temporização, pontuado a partir de um registro de erro de tempo que o OPERADOR fornece (um log do ptp4l, phc2sys ou ts2phc do linuxptp, um log de tracking ou statistics do chrony, um log de relógio TICC, TimeLab ou RINEX, ou pares time_s,time_error_ns). (catálogo de tipos de cenário (kshana kinds --json))
• Reprodutibilidade e garantia de software é MODELLED, não validada: uma subafirmação é verificada externamente, mas a capacidade inteira compõe peças modeladas, de modo que a capacidade permanece modelada. (matriz de verificação (docs/MODELLED-RATIONALE.md))
• As máscaras de sincronização de telecomunicações da ITU-T com PASS/FAIL e margem são MODELLED, não validadas: conferidas contra a sua própria identidade analítica / de forma fechada — detecta erros de transcrição e de coeficientes, mas não é uma referência independente externa. (matriz de verificação (docs/MODELLED-RATIONALE.md))
• O teste de holdover pontuado a partir de um registro de erro de tempo fornecido pelo operador é MODELLED, não validado: conferido contra a sua própria identidade analítica / de forma fechada — detecta erros de transcrição e de coeficientes, mas não é uma referência independente externa. (matriz de verificação (docs/MODELLED-RATIONALE.md))

Veja também#

• Página da família: Relógios, temporização e holdover
• Todos os tipos de cenário: KINDS.md
• Página do tópico: TIMING-HIL.md
• Página do tópico: HARDWARE-SAFETY.md