Hardware-in-the-loop de temporização: desligar a antena, pontuar o holdover

Os operadores de telecomunicações e de energia testam um sistema de temporização retirando-lhe o GNSS e observando o que o relógio faz. O Kshana não faz isso por eles, e não toca no equipamento deles. Lê o registo de erro de tempo produzido pelos instrumentos do próprio operador, divide-o nos dois instantes que o operador indica e mede cada passo face às máscaras públicas da ITU-T. O tipo de cenário é holdover-test; os cenários de exemplo são scenarios/holdover-test-example.toml e scenarios/holdover-test-ptp4l.toml.

Esta é a fase 1 da segurança de hardware: passiva, apenas de receção, sem RF do Kshana (HARDWARE-SAFETY.md). Software de caráter consultivo, não um equipamento homologado. Ninguém classificou, aprovou ou reviu este procedimento, e ele não diz nada sobre se um sistema satisfaz uma Recomendação.

O procedimento#

O operador executa quatro passos. O Kshana não executa nenhum deles.

Duas coisas que o operador tem de fazer, porque o Kshana não pode:

• Indicar os dois instantes. gnss_removed_s e gnss_restored_s são declaração do operador. O Kshana não deteta a remoção a partir do registo e não verifica os instantes. Um instante errado desloca as fronteiras dos passos e, portanto, o resultado.
• Utilize o mesmo relógio para o registo e para os instantes. Num registo de relógio, o eixo do tempo começa na primeira leitura, pelo que os dois instantes são segundos desde a primeira linha do registo.

O que registar#

Qualquer um destes, através dos leitores clock_log existentes (CLOCK-LOG-FORMATS.md):

O que o registo mede é importante. Um registo de servo (linuxptp, chrony) regista o desvio que o daemon mediu e está a corrigir: é o erro de tempo que subsiste sob controlo do servo, não uma medição independente do relógio face ao UTC. Durante o passo de holdover de um ensaio que realmente remove a referência, um registo de servo continua a mostrar o que o daemon julgava, o que pode diferir do erro verdadeiro. Um TICC ou outro contador face a uma referência independente é o registo mais forte; indique qual utilizou ao comunicar o resultado.

O cenário#

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

Chaves opcionais: budgets (nome, max_abs_te_ns, fonte; por predefinição os de temporização de telecomunicações quando ausente) e clock = "..." dentro de [series.clock_log] para escolher uma fonte de um registo que contém várias.

O que o relatório contém#

• steps: para a linha de base, o holdover e a recuperação, o início e o fim, o número de amostras e os valores médio, rms, máximo e final do erro de tempo.
• masks: cada máscara indicada, medida no passo que a sua condição designa. Uma máscara escrita para um relógio em bloqueio é medida na linha de base; uma escrita para holdover ou para um relógio autónomo, no holdover. Cada verificação tem o seu limite, o valor medido, a margem e a tabela de onde foi transcrita. Uma máscara que exige um registo mais longo do que o passo forneceu é INCOMPLETE, nunca extrapolada; uma que o motor não consegue avaliar para o intervalo de amostragem do registo é NOT-EVALUATED com o motivo.
• holdover: o desvio fracionário de frequência que o sistema manteve (o declive de uma reta de mínimos quadrados através do erro de tempo do holdover, em ns/s, o que equivale a partes por mil milhões), o resíduo em torno dessa reta, o maior erro de tempo absoluto e quando ocorreu, e o salto no momento da remoção.
• holdover_envelope: o envelope de holdover ePRTC-A da ITU-T G.8272.1 Tabela 3, a partir de locked_duration_days, com o instante em que é excedido pela primeira vez.
• budgets: o tempo após a remoção em que cada orçamento de erro de tempo é excedido pela primeira vez.
• recovery: se |TE| entrou na banda e nela permaneceu durante o tempo de permanência, quanto tempo depois do regresso do GNSS isso começou, o pico após o restabelecimento e o maior salto entre amostras consecutivas durante a recuperação.
• curves: MTIE e TDEV dos passos de linha de base e de holdover.
• verdicts: um resumo de uma palavra por passo.

Cada número traz a sua unidade e a sua origem no bloco units do relatório.

As palavras e os limites#

• O resultado é medido face à máscara. As máscaras são transcritas de Recomendações da ITU-T de descarga gratuita (as mesmas tabelas do tipo de cenário telecom-timing, listadas em TELECOM-TIMING.md), e todas as entradas que as Recomendações deixam "a estudar futuramente" estão ausentes, não preenchidas. O Kshana não afirma que um relógio ou um sistema satisfaz ou foi aprovado face a uma Recomendação, e o relatório também não.
• MODELLED. A lógica dos passos, o ajuste da reta e a regra de recuperação são verificados em registos construídos a partir de fórmulas cujas respostas são conhecidas antes da execução; nenhum holdover de laboratório foi pontuado face a uma referência independente externa, e nenhum parceiro ou laboratório concordou com o que quer que seja. Seria necessário um laboratório de temporização antes de qualquer valor por classe de relógio poder ser promovido.
• O que não é coberto, declarado em todos os relatórios: se o GNSS foi realmente removido e restabelecido nos instantes indicados; qualquer passo que o operador não tenha registado; máscaras definidas através de um filtro de 0,1 Hz para um registo amostrado mais lentamente do que uma vez por segundo; a incerteza de medição do próprio instrumento; e qualquer procedimento das Recomendações para além de um registo de erro de tempo (perfis de temperatura, carga da rede de pacotes).
• A banda de recuperação é uma escolha do próprio ensaio. O valor predefinido de 100 ns é o erro de tempo absoluto máximo de um PRTC-A (ITU-T G.8272); é uma linha conveniente, não um requisito de nenhuma Recomendação para a recuperação.
• Sem via de transmissão. O Kshana lê ficheiros. Não gera um sinal, e a remoção do GNSS num laboratório é feita com o equipamento do próprio laboratório e sob a sua própria autorização.

Superfícies#

holdover-test é um tipo de cenário, pelo que é executado em todo o lado onde se executam tipos de cenário: kshana <scenario.toml>, a API Rust (kshana::api::run_toml), a ligação Python (kshana.run), a compilação WebAssembly e npm (samples ou clock_log.text inline; as chaves de ficheiro não estão aí disponíveis), o servidor MCP (run_scenario, apenas conteúdo inline) e o executor de cenários do Kshana Studio. Os dois ficheiros de cenário estão incluídos (kshana example holdover-test-example).