Synchronizacja czasu hardware-in-the-loop: odłącz antenę, oceń holdover

Operatorzy telekomunikacyjni i energetyczni testują system synchronizacji, odbierając mu GNSS i obserwując, co robi zegar. Kshana tego za nich nie robi i nie dotyka ich sprzętu. Czyta zapis błędu czasu, który wytworzyły własne przyrządy operatora, dzieli go w dwóch podanych przez operatora chwilach i mierzy każdy krok względem publicznych masek ITU-T. Rodzaj scenariusza to holdover-test; scenariusze przykładowe to scenarios/holdover-test-example.toml i scenarios/holdover-test-ptp4l.toml.

To etap 1 bezpieczeństwa sprzętu: pasywny, tylko odbiór, bez RF z Kshana (HARDWARE-SAFETY.md). Oprogramowanie wyłącznie doradcze, nie jest to sprzęt z zatwierdzeniem typu. Nikt nie ocenił, nie zatwierdził ani nie zweryfikował tej procedury i nic ona nie mówi o tym, czy system spełnia Zalecenie.

Procedura#

Operator wykonuje cztery kroki. Kshana nie wykonuje żadnego z nich.

Dwie rzeczy, które operator musi zrobić, bo Kshana nie może:

• Podać dwa czasy. gnss_removed_s i gnss_restored_s to oświadczenie operatora. Kshana nie wykrywa usunięcia sygnału w zapisie i nie weryfikuje tych czasów. Błędny czas przesuwa granice kroków, a więc i wynik.
• Użyj tego samego zegara dla zapisu i dla czasów. W logu zegara oś czasu zaczyna się od pierwszego odczytu, więc oba czasy są sekundami od pierwszej linii logu.

Co zapisać#

Dowolne z poniższych, przez istniejące czytniki clock_log (CLOCK-LOG-FORMATS.md):

Ma znaczenie, co zapis mierzy. Log serwomechanizmu (linuxptp, chrony) rejestruje przesunięcie, które demon zmierzył i koryguje: to błąd czasu pozostały pod kontrolą serwomechanizmu, a nie niezależny pomiar zegara względem UTC. W kroku holdover testu, który naprawdę odbiera wzorzec, log serwomechanizmu nadal pokazuje to, co demon uważał, a to może różnić się od prawdziwego błędu. Mocniejszym zapisem jest TICC lub inny licznik względem niezależnego wzorca; przy podawaniu wyniku napisz, którego użyto.

Scenariusz#

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

Klucze opcjonalne: budgets (nazwa, max_abs_te_ns, źródło; gdy ich brak, obowiązują domyślne ustawienia telecom-timing) oraz clock = "..." wewnątrz [series.clock_log], aby wybrać jedno źródło z logu zawierającego kilka.

Co zawiera raport#

• steps: dla stanu wyjściowego, holdover i powrotu: początek i koniec, liczba próbek oraz wartość średnia, rms, największa i końcowa błędu czasu.
• masks: każda wymieniona maska, mierzona w kroku wskazanym przez jej warunek. Maska napisana dla zegara zablokowanego jest mierzona w stanie wyjściowym; napisana dla holdover lub zegara autonomicznego, w holdover. Każda kontrola ma swój limit, zmierzoną wartość, margines i tabelę, z której została przepisana. Maska, która wymaga dłuższego zapisu, niż dał krok, ma status INCOMPLETE i nigdy nie jest ekstrapolowana; maska, której silnik nie może ocenić dla odstępu próbkowania zapisu, ma status NOT-EVALUATED wraz z powodem.
• holdover: ułamkowe przesunięcie częstotliwości, które system utrzymał (nachylenie prostej najmniejszych kwadratów przez błąd czasu w holdover, w ns/s, czyli w częściach na miliard), reszta względem tej prostej, największy bezwzględny błąd czasu i moment jego wystąpienia oraz skok w chwili usunięcia.
• holdover_envelope: obwiednia holdover ePRTC-A z ITU-T G.8272.1 Tabela 3, wyznaczona z locked_duration_days, wraz z chwilą jej pierwszego przekroczenia.
• budgets: czas po usunięciu, w którym każdy budżet błędu czasu zostaje pierwszy raz przekroczony.
• recovery: czy |TE| weszło do pasma i pozostało w nim przez czas przetrzymania, ile po powrocie GNSS to nastąpiło, szczyt po przywróceniu i największy skok między kolejnymi próbkami podczas powrotu.
• curves: MTIE i TDEV kroków stanu wyjściowego i holdover.
• verdicts: jednowyrazowe podsumowanie każdego kroku.

Każda liczba niesie swoją jednostkę i źródło w bloku units raportu.

Słowa i limity#

• Wynik jest mierzony względem maski. Maski są przepisane z swobodnie dostępnych Zaleceń ITU-T (te same tabele co w rodzaju telecom-timing, wymienione w TELECOM-TIMING.md), a każdy wpis, który Zalecenia pozostawiają „do dalszych badań”, jest nieobecny, a nie uzupełniony. Kshana nie twierdzi, że zegar lub system spełnia Zalecenie albo jest względem niego zatwierdzony, i raport też tego nie robi.
• MODELLED. Logika kroków, dopasowanie prostej i reguła powrotu są sprawdzone na zapisach zbudowanych ze wzorów, których wyniki znane są przed przebiegiem; żaden laboratoryjny holdover nie został oceniony względem zewnętrznej wyroczni i żaden partner ani laboratorium na nic się nie zgodził. Potrzebne byłoby laboratorium czasu, zanim jakąkolwiek wartość dla klasy zegara można by awansować.
• Czego nie obejmuje, podane w każdym raporcie: czy GNSS rzeczywiście został usunięty i przywrócony w podanych chwilach; każdy krok, którego operator nie zapisał; maski zdefiniowane przez filtr 0,1 Hz dla zapisu próbkowanego rzadziej niż raz na sekundę; własna niepewność pomiarowa przyrządu; oraz każda procedura z Zalecenia wykraczająca poza zapis błędu czasu (profile temperatury, obciążenie sieci pakietowej).
• Pasmo powrotu to własny wybór testu. Wartość domyślna 100 ns to maksymalny bezwzględny błąd czasu PRTC-A (ITU-T G.8272); to wygodna granica, a nie wymaganie żadnego Zalecenia dotyczące powrotu.
• Brak ścieżki nadawczej. Kshana czyta pliki. Nie generuje sygnału, a usuwanie GNSS w laboratorium odbywa się własnym sprzętem laboratorium i na jego własne upoważnienie.

Powierzchnie#

holdover-test jest rodzajem scenariusza, więc działa wszędzie, gdzie działają rodzaje: kshana <scenario.toml>, API Rust (kshana::api::run_toml), powiązanie Pythona (kshana.run), kompilacja WebAssembly i npm (samples lub clock_log.text w treści wywołania; kluczy plikowych tam nie ma), serwer MCP (run_scenario, tylko treść w wywołaniu) oraz moduł uruchamiania scenariuszy w Kshana Studio. Oba pliki scenariuszy są dołączone (kshana example holdover-test-example).