holdover-test (rodzaj scenariusza)

Rodzaj scenariusza silnika v0.40.0, rodzina Zegary, synchronizacja czasu i holdover. Wyłącznie doradczo: wynik analizy z narzędzia badawczo-inżynieryjnego; nie jest to sprzęt nawigacyjny z zatwierdzeniem typu ani usługa bezpieczeństwa życia. Każda etykieta tutaj pochodzi od silnika lub z macierzy weryfikacji; rodzaj jest MODELLED, o ile macierz nie mówi inaczej (jak zdobywa się etykietę: sekcja Evidence w README).

Co robi#

MODELLED test holdover systemu synchronizacji czasu, oceniany na podstawie zapisu błędu czasu dostarczonego przez OPERATORA (log linuxptp ptp4l, phc2sys lub ts2phc, log chrony tracking lub statistics, log zegara TICC, TimeLab lub RINEX albo pary time_s,time_error_ns). Test ma cztery kroki i Kshana nie wykonuje żadnego z nich: zablokowany punkt odniesienia (BASELINE), GNSS ODŁĄCZONY przez operatora (kabel antenowy lub wyjście symulatora; Kshana niczego nie nadaje i niczym nie steruje) w podanym czasie, HOLDOVER na własnym oscylatorze systemu oraz ODZYSKANIE po przywróceniu przez operatora GNSS w drugim podanym czasie. Zapis jest dzielony w tych dwóch momentach. Punkt odniesienia: statystyki błędu czasu i maski ITU-T napisane dla zegara zablokowanego. Holdover: statystyki, ułamkowe przesunięcie częstotliwości, które system utrzymał (prosta metodą najmniejszych kwadratów), maski napisane dla holdover lub zegara autonomicznego, obwiednia holdover ePRTC-A z podanego czasu zablokowania oraz czas przekroczenia każdego budżetu błędu czasu. Odzyskanie: czy i kiedy |TE| zmieścił się w podanym paśmie i w nim pozostał, wartość szczytowa i największy skok. Każdy limit jest przepisany z publicznej tabeli ITU-T (maski synchronizacji telekomunikacyjnej); sformułowanie brzmi „zmierzone względem maski”, a oba momenty są oświadczeniem operatora, nie są weryfikowane. Zapis zbyt krótki dla maski to INCOMPLETE, nigdy nie jest ekstrapolowany. Zob. docs/TIMING-HIL.md.

Jeden przebieg scenarios/holdover-test-ptp4l.toml podsumowuje się tak: 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)

Wejścia#

Ze schematu (kshana kinds --json):

• Wymagane pola: test, series
• Pola opcjonalne: masks, budgets

Przykład scenarios/holdover-test-ptp4l.toml ustawia między innymi:

Uruchom#

kshana scenarios/holdover-test-ptp4l.toml

Tego rodzaju używa 2 dołączonych scenariuszy; pozostałe są w scenarios/.

Co daje#

Wyniki skalarne tego przebiegu, z jednostkami podanymi przez silnik:

Etykieta wyniku (silnika): MODELLED — test holdover oceniany na podstawie zapisu błędu czasu dostarczonego przez operatora. Każdy limit jest przepisany z wymienionej publicznej Rekomendacji ITU-T, a wynik jest zmierzony względem maski; nie mówi nic o tym, czy jakikolwiek zegar lub system spełnia Rekomendację, i nikt nie ocenił ani nie zatwierdził

Dowody#

MODELLED: wiersze macierzy weryfikacji, które wymieniają ten rodzaj.

• MODELLED Rodzaj holdover-test: zapis błędu czasu (log linuxptp, chrony, TICC, TimeLab lub RINEX albo pary time_s,time_error_ns) jest dzielony w dwóch momentach podanych przez operatora dla odłączenia i przywrócenia GNSS na punkt odniesienia, holdover a

Wiersze, które sam przebieg wykorzystał, wraz z wyrocznią, jaką macierz podaje dla każdego (publiczne źródła są tam wymienione):

• MODELLED Deterministyczne, haszowane na poziomie scenariusza, bramki SBOM i złotych wyników między platformami. Wyrocznia (ExternalDataset): zgodność SBOM z oficjalnym schematem JSON CycloneDX 1,5 (+ prawidłowe identyfikatory SPDX): zewnętrzny opublikowany standard, zero błędów walidacji w całym grafie zależności; część dotycząca determinizmu wskaźników jakości i odtwarzalności bajt w bajt pozostaje przypiętą kontrolą samospójności, więc wiersz pozostaje MODELLED
• VALIDATED Maksymalny błąd przedziału czasu i odchylenie czasu, które raportuje rodzaj scenariusza telecom-timing, na zapisie holdover w skali telekomunikacyjnej: O(n) przesuwna kolejka monotoniczna. Wyrocznia (ExternalDataset): allantools 2024,06 — niezależna biblioteka stabilności częstotliwości innej firmy — mtie() i tdev() na tests/fixtures/telecom_timing/holdover_te_series.csv, szereg sparsowany z tego samego tekstu o 17 cyfrach znaczących po obu stronach; wzorzec zapisuje SHA-256 szeregu i można go odtworzyć offline przez tests/fixtures/telecom_timing/generate_telecom_timing_reference.py. Waliduje ESTYMATORY na tym zapisie, nie syn
• MODELLED Przepisane limity ITU-T G.8272 (07/2025) PRTC-A/B, G.8272.1 (2024) Amd. 1 (07/2025) ePRTC zablokowanego i holdover ePRTC-A (w tym obwiednia błędu czasu z tabeli 3. Wyrocznia (InternalConsistency): transkrypcja wymienionych Rekomendacji (do swobodnego pobrania z itu.int), każdy limit z podaniem tabeli lub punktu, wraz z wykazem każdej niepotwierdzonej lub niezaimplementowanej pozycji w docs/TELECOM-TIMING.md; tożsamości ciągłości w punktach załamania, które wynikają z tabel, są sprawdzane w testach. Transkrypcja norm z kontrolami spójności wewnętrznej, nie jest testem spełnienia wymagań normy ani zewnętrzną walidacją. 0,30 runda 2 (zarejestrowane z góry
• MODELLED Rodzaj holdover-test: zapis błędu czasu (log linuxptp, chrony, TICC, TimeLab lub RINEX albo pary time_s,time_error_ns) jest dzielony w dwóch momentach. Wyrocznia (InternalConsistency): obliczenia ręczne na zapisach zbudowanych ze wzorów, których nachylenie, skok, ekstremum i czas odzyskania są znane przed przebiegiem (podają je testy), oraz maski, obwiednia i budżety z wierszy synchronizacji telekomunikacyjnej powyżej. Nie oceniono żadnego laboratoryjnego pomiaru rzeczywistego holdover i nie porównano z żadną zewnętrzną wyrocznią, więc rodzaj nie formułuje żadnego twierdzenia o żadnym zegarze ani systemie; potrzebny jest partner z laboratorium czasu, zanim powstanie jakikolwiek wynik dla klasy zegara

Ograniczenia#

Co raport samego przebiegu podaje jako niemodelowane lub niesprawdzone względem niezależnego wzorca:

• MODELLED — test holdover oceniany na podstawie zapisu błędu czasu dostarczonego przez operatora. Każdy limit jest przepisany z wymienionej publicznej Rekomendacji ITU-T, a wynik jest zmierzony względem maski; nie mówi nic o tym, czy jakikolwiek zegar lub system spełnia Rekomendację, i nikt go nie ocenił ani nie zatwierdził. Momenty usunięcia i przywrócenia GNSS są oświadczeniem operatora i nie są weryfikowane. Oprogramowanie wyłącznie dor (wynik label)
• MODELLED test holdover systemu synchronizacji czasu, oceniany na podstawie zapisu błędu czasu dostarczonego przez OPERATORA (log linuxptp ptp4l, phc2sys lub ts2phc, log chrony tracking lub statistics, log zegara TICC, TimeLab lub RINEX albo pary time_s,time_error_ns). (katalog rodzajów (kshana kinds --json))
• Odtwarzalność i zapewnienie jakości oprogramowania jest MODELLED, nie jest sprawdzona względem niezależnego wzorca: jedno twierdzenie składowe jest sprawdzone zewnętrznie, ale cała możliwość składa się z elementów obliczonych na podstawie modelu, więc pozostaje obliczona na podstawie modelu. (macierz weryfikacji (docs/MODELLED-RATIONALE.md))
• Maski synchronizacji telekomunikacyjnej ITU-T z PASS/FAIL i marginesem są MODELLED, nie są sprawdzone względem niezależnego wzorca: sprawdzone względem własnej tożsamości w postaci zamkniętej / analitycznej, wychwytuje błędy transkrypcji i współczynników, ale nie jest zewnętrzną wyrocznią. (macierz weryfikacji (docs/MODELLED-RATIONALE.md))
• Test holdover oceniany na podstawie zapisu błędu czasu dostarczonego przez operatora jest MODELLED, nie jest sprawdzony względem niezależnego wzorca: sprawdzony względem własnej tożsamości w postaci zamkniętej / analitycznej, wychwytuje błędy transkrypcji i współczynników, ale nie jest zewnętrzną wyrocznią. (macierz weryfikacji (docs/MODELLED-RATIONALE.md))

Zobacz też#

• Strona rodziny: Zegary, synchronizacja czasu i holdover
• Wszystkie rodzaje: KINDS.md
• Strona tematu: TIMING-HIL.md
• Strona tematu: HARDWARE-SAFETY.md