Relógios, temporização e holdover (família de tipos de cenário)

9 tipos de cenário do mecanismo v0.40.0. Consultivo: resultado 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 mecanismo ou da matriz de verificação; um tipo é MODELLED a menos que a matriz diga o contrário (como um rótulo é obtido: a seção Evidence do README).

Páginas de tópico: TELECOM-TIMING, SLOT-TIMING, TIMING-HIL, CLOCK-LOG-FORMATS. Execute uma: kshana scenarios/clock-holdover.toml. Todas as famílias: KINDS.md.

clock#

Holdover do relógio em relação à especificação; conjunto Monte Carlo opcional (execuções > 1).

Campos obrigatórios: seed, threshold_ns, time, gnss, clock_quantum, clock_classical. Opcionais: runs, integrity.

Registro: MODELLED. Página completa, com as entradas, os resultados, as evidências e as limitações: clock.

kshana scenarios/clock-ensemble.toml

sweep#

Varredura 1-D de estudo de compromissos sobre um parâmetro do pacote de relógio.

Campos obrigatórios: parameter, metric, start, stop, steps, base. Opcionais: scale.

Registro: MODELLED. Página completa, com as entradas, os resultados, as evidências e as limitações: sweep.

kshana scenarios/sweep-clock-stability.toml

sweep-nd#

Varredura genérica N-D sobre qualquer pacote por meio de chaves TOML pontuadas / caminhos de métricas JSON.

Campos obrigatórios: base, axes, metrics.

Registro: nenhuma linha da matriz cita este tipo; o mecanismo rotula o seu próprio resultado. Página completa, com as entradas, os resultados, as evidências e as limitações: sweep-nd.

kshana scenarios/sweep-nd-inertial.toml

telecom-timing#

Temporização de telecomunicações: erro de tempo, erro máximo de intervalo de tempo (MTIE) e desvio de tempo (TDEV) de um holdover de GNSS, conferidos contra máscaras da ITU-T com PASS ou FAIL e uma margem por máscara. A entrada é um HOLDOVER SINTÉTICO (uma predefinição de oscilador -- ocxo, rubídio, césio ou csac, cada uma com os valores de estabilidade, envelhecimento e temperatura de um datasheet público e nomeado da Microchip -- mais o tempo de perda do GNSS, a duração do registro e o intervalo de amostragem; o relógio em operação livre tem ruído de frequência branco, flicker e, quando o ajuste ao datasheet exige, de passeio aleatório, envelhecimento linear e um termo senoidal de temperatura) ou uma SÉRIE INGERIDA de pares [time_s, time_error_ns] fornecidos em linha (e, apenas em compilações nativas, um arquivo CSV). Máscaras: ITU-T G.8272 (07/2025) PRTC-A e PRTC-B (max|TE| 100 / 40 ns, MTIE Tabelas 1-2, TDEV Tabelas 3-4); G.8272.1 (2024) Amd. 1 (07/2025) ePRTC bloqueado (30 ns, Tabelas 1-2) e holdover de ePRTC-A (o envelope de erro de tempo da Tabela 3 que sobe de 30 ns a 100 ns ao longo do período de holdover H definido pela duração em bloqueio, MTIE Tabela 4, TDEV Tabela 5); G.8273.2 (2023) Amd. 2 (11/2025) classes A-C de T-BC/T-TSC (max|TE|, erro de tempo constante, MTIE e TDEV filtrados por passa-baixa) e classe D (max|TE_L| 5 ns, o único valor da classe D não deixado para estudo futuro); G.8271.1 (2022) Amd. 3 (05/2025) ponto de referência C (max|TE_L| 1100 / 600 / 100 ns com MTIE Tabelas 7-1 a 7-3). Toda entrada que uma Recomendação marca para estudo futuro está ausente em vez de preenchida, e cada relatório lista o que não está implementado. Informa também o tempo para exceder cada orçamento de erro de tempo máximo (padrões: 100 ns max|TE_HO| de ePRTC, 400 ns de alocação de holdover de rede, 1100 ns ponto C, 1,5 us classe 4), as curvas de MTIE/TDEV como uma tabela CSV com o limite de cada máscara, e uma entrada de unidades e proveniência por campo numérico. VALIDATED: os estimadores de MTIE e TDEV contra o pacote allantools em uma série de holdover versionada. MODELLED: as tabelas de máscaras são transcrições, e um holdover sintético é um modelo construído a partir de máximos de datasheet, não uma medição de qualquer unidade. Não é um teste de aderência à norma.

Campos obrigatórios: nenhum. Opcionais: seed, masks, budgets, holdover, series.

Registro: MODELLED 5 · VALIDATED 1. Página completa, com as entradas, os resultados, as evidências e as limitações: telecom-timing.

kshana scenarios/telecom-synce-eec.toml

slot-timing#

Temporização de slot: segundos até um relógio em operação livre sair da guarda de um slot de roteamento ou de atribuição de tarefas indexado no tempo (o maior erro de tempo absoluto que o slot tolera), a contribuição de cada termo nesse instante com o dominante indicado (incerteza da correção, ruído de fase branco, ruído de frequência branco, flicker, de passeio aleatório e de corrida aleatória, deslocamento de frequência residual, temperatura, envelhecimento), o tempo restante desde a última correção e o maior intervalo de correção que mantém o relógio dentro, descontada a latência da correção. O oscilador é um padrão de CLASSE (csac, uso, dsac, tcxo, ocxo ou rafs: um desvio de Allan de um segundo citado e um piso de ruído vermelho assumido), uma PREDEFINIÇÃO DE DATASHEET de temporização de telecomunicações ou um DATASHEET em linha (máximos do desvio de Allan ajustados como envoltória, mais envelhecimento e um coeficiente de temperatura), ou um REGISTRO DE FASE MEASURED em linha (seu desvio de Allan sobreposto ajustado por mínimos quadrados ponderados na base de ruído de fase branco e de modulação de frequência da IEEE Std 1139, de modo que o piso de ruído vermelho é medido em vez de assumido). Uma violação além do maior tempo de médias que o datasheet ou o registro suporta é sinalizada como extrapolada. Uma seção opcional de spoofing acrescenta o nível de proteção de temporização para um receptor em órbita: velocidade e período orbitais, por quanto tempo um único spoofer em solo alcança o satélite a cada passagem, o piso do monitor auxiliado pelo relógio e a latência de detecção do CUSUM, o limite condicional, o desvio que um spoofer com uma taxa de rampa máxima declarada acumula antes de o satélite sair do seu alcance ou de uma verificação independente ser executada, e se cada verificação de contato com o solo ou de crosslink é independente desse spoofer. VALIDATED: a inversão de holdover a partir de um registro ajustado, mantida de reserva em um relógio real de césio medido contra um maser de hidrogênio (tests/slot_timing_cs5071a_holdout.rs, condicionado a dados); em um oscilador de cristal medido, a predição reservada é conservadora, mas não está dentro do limiar, portanto o caso do cristal é MODELLED. MODELLED: as fontes de classe e de datasheet, os termos determinísticos e a avaliação de spoofing.

Campos obrigatórios: oscillator, slot. Opcionais: spoofing.

Registro: MODELLED 2 · VALIDATED 1. Página completa, com as entradas, os resultados, as evidências e as limitações: slot-timing.

kshana scenarios/slot-timing-ocxo-leo.toml

timetransfer#

Transferência bidirecional de tempo/frequência óptica versus RF.

Campos obrigatórios: seed, samples, step_s, range_spec_mm, link_quantum, link_classical.

Registro: MODELLED. Página completa, com as entradas, os resultados, as evidências e as limitações: timetransfer.

kshana scenarios/timetransfer.toml

time-transfer-budget#

Transferência bidirecional de tempo e frequência por satélite entre duas estações por meio de um relé geoestacionário: a equação bidirecional resolvida para T_A - T_B com todo termo não recíproco (atrasos do equipamento das estações, ionosfera em banda Ku, transponder, Sagnac), um orçamento de incerteza em quadratura cujo termo do tipo A é o TDEV do enlace simulado no tempo de médias, um enlace simulado com ruído de fase branco e flicker e uma não reciprocidade diurna, e a estabilidade (taxa, RMS residual, TDEV, ADEV) de qualquer série fornecida da Seção 1 da Circular T do BIPM, CSV MJD,ns ou registros de relógio de estação RINEX do IGS. MODELLED.

Campos obrigatórios: station_a, station_b, satellite_lon_deg, transponder_ab_ns, transponder_ba_ns, white_noise_ns, uncertainty. Opcionais: uplink_ghz, downlink_ghz, true_offset_ns, flicker_noise_ns, diurnal_amplitude_ns, reciprocity_bias_ns, step_s, span_days, averaging_s, seed, series.

Registro: MODELLED. Página completa, com as entradas, os resultados, as evidências e as limitações: time-transfer-budget.

kshana scenarios/time-transfer-budget.toml

holdover-test#

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.

Campos obrigatórios: test, series. Opcionais: masks, budgets.

Registro: MODELLED. Página completa, com as entradas, os resultados, as evidências e as limitações: holdover-test.

kshana scenarios/holdover-test-ptp4l.toml

quantum-time-transfer#

Cadeia de temporização quântica confiável, MODELLED: um orçamento de transferência de tempo de ponta a ponta quântico (relógio de rede óptica + enlace de emaranhamento/fóton único) contra clássico (CSAC + RF de dois sentidos), um nível de proteção de temporização reaproveitado + uma figura de mérito de segurança contra ataque de atraso/repetição (1-P_md), uma probabilidade de detecção de anomalia de relógio + latência do CUSUM, e a comparação quântico-versus-clássico como TradeEvidence honesto, com um registro de representatividade + lacunas até o voo. Parâmetros ilustrativos de dispositivo/enlace de fonte pública; modela a classe, sem alegação de TRL, voo nem certificação.

Campos obrigatórios: nenhum. Opcionais: integration_s, dissemination_interval_s, link_loss_db, classical_link_sigma_s, monitor_pfa, attack_delay_s, clock_fault_sigma.

Registro: nenhuma linha da matriz cita este tipo; o mecanismo rotula o seu próprio resultado. Página completa, com as entradas, os resultados, as evidências e as limitações: quantum-time-transfer.

kshana scenarios/quantum-time-transfer.toml