Апаратне тестування хронометражу в контурі: відключіть антену, оцініть holdover

Оператори телекомунікацій і енергетики перевіряють систему синхронізації часу, забираючи в неї GNSS і спостерігаючи, що робить годинник. Kshana цього за них не робить і не торкається їхнього обладнання. Вона читає запис похибки часу, створений власними приладами оператора, розбиває його за двома заявленими оператором моментами й вимірює кожен крок щодо публічних масок ITU-T. Тип сценарію — holdover-test; приклади сценаріїв — scenarios/holdover-test-example.toml і scenarios/holdover-test-ptp4l.toml.

Це етап 1 апаратної безпеки: пасивний, лише приймання, без RF від Kshana (HARDWARE-SAFETY.md). Консультативне програмне забезпечення, не обладнання із затвердженням типу. Ніхто не оцінював, не схвалював і не перевіряв цю процедуру, і вона нічого не каже про те, чи система відповідає Рекомендації.

Процедура#

Оператор виконує чотири кроки. Kshana не виконує жодного з них.

Дві речі, які мусить зробити оператор, бо Kshana не може:

• Заявити обидва моменти. gnss_removed_s і gnss_restored_s — це твердження оператора. Kshana не виявляє вилучення за записом і не перевіряє ці моменти. Хибний момент зсуває межі кроків, а отже й результат.
• Використовуйте один годинник для запису і для моментів. Для журналу годинника вісь часу починається з першого показання, тож обидва моменти — це секунди від першого рядка журналу.

Що записувати#

Будь-що з цього, через наявні читачі clock_log (CLOCK-LOG-FORMATS.md):

Важливо, що вимірює запис. Журнал серво (linuxptp, chrony) фіксує зміщення, яке демон виміряв і виправляє: це похибка часу, що лишилася під керуванням серво, а не незалежне вимірювання годинника щодо UTC. Під час кроку holdover тесту, що справді вилучає опору, журнал серво все одно показує те, що вважав демон, а це може відрізнятися від справжньої похибки. Лічильник TICC або інший лічильник щодо незалежної опори — сильніший запис; зазначайте, який із них ви використали, коли повідомляєте результат.

Сценарій#

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

Необов'язкові ключі: budgets (назва, max_abs_te_ns, джерело; типові значення telecom-timing, якщо їх немає) і clock = "..." усередині [series.clock_log], щоб вибрати одне джерело з журналу, що містить кілька.

Що містить звіт#

• steps: для базового рівня, holdover і відновлення — початок і кінець, кількість відліків і середнє, rms, найбільше та кінцеве значення похибки часу.
• masks: кожна названа вами маска, виміряна на кроці, який називає її умова. Маска, написана для синхронізованого годинника, вимірюється на базовому рівні; написана для holdover або автономного годинника — на holdover. Кожна перевірка має свою межу, виміряне значення, запас і таблицю, з якої її транскрибовано. Маска, що потребує довшого запису, ніж дав крок, є INCOMPLETE і ніколи не екстраполюється; та, яку рушій не може оцінити для інтервалу відліків запису, є NOT-EVALUATED із зазначенням причини.
• holdover: дробове зміщення частоти, яке тримала система (нахил прямої найменших квадратів через похибку часу holdover, у ns/s, що є частинами на мільярд), залишок навколо цієї прямої, найбільша абсолютна похибка часу і коли вона виникла, та стрибок у момент вилучення.
• holdover_envelope: огинаюча holdover ePRTC-A за таблицею 3 ITU-T G.8272.1, із locked_duration_days, з часом, коли її вперше перевищено.
• budgets: час після вилучення, коли кожен бюджет похибки часу вперше перевищено.
• recovery: чи потрапила |TE| в смугу та залишалася в ній протягом часу витримки, скільки часу після повернення GNSS це почалося, пік після відновлення і найбільший стрибок між послідовними відліками під час відновлення.
• curves: MTIE і TDEV кроків базового рівня та holdover.
• verdicts: підсумок одним словом на крок.

Кожне число має одиницю та джерело походження в блоці units звіту.

Слова та межі#

• Результат виміряно щодо маски. Маски транскрибовано з вільно доступних Рекомендацій ITU-T (ті самі таблиці, що й для типу telecom-timing, перелічені в TELECOM-TIMING.md), а кожен запис, який Рекомендації залишають «для подальшого вивчення», відсутній, а не заповнений. Kshana не стверджує, що годинник чи система відповідає Рекомендації або схвалена за нею, і звіт цього не стверджує.
• MODELLED. Логіку кроків, підгонку прямої та правило відновлення перевірено на записах, побудованих за формулами, відповіді яких відомі до прогону; жоден лабораторний holdover не оцінено за зовнішнім оракулом, і жоден партнер чи лабораторія ні на що не погодилися. Знадобиться лабораторія синхронізації часу, перш ніж якесь значення для будь-якого класу годинників можна буде підвищити.
• Що не охоплено, зазначається в кожному звіті: чи справді GNSS було вилучено й відновлено в заявлені моменти; будь-який крок, який оператор не записав; маски, визначені через фільтр 0,1 Hz, для запису, дискретизованого рідше ніж раз на секунду; власна невизначеність вимірювання приладу; та будь-яка процедура Рекомендації понад запис похибки часу (температурні профілі, навантаження пакетної мережі).
• Смуга відновлення — власний вибір тесту. Типове значення 100 ns — це максимальна абсолютна похибка часу PRTC-A (ITU-T G.8272); це зручна лінія, а не вимога жодної Рекомендації до відновлення.
• Жодного шляху передавання. Kshana читає файли. Вона не генерує сигналу, а вилучення GNSS у лабораторії виконується власним обладнанням лабораторії та за її власним дозволом.

Поверхні#

holdover-test — це тип сценарію, тож він запускається скрізь, де запускаються типи: kshana <scenario.toml>, API Rust (kshana::api::run_toml), прив'язка Python (kshana.run), збірка WebAssembly і npm (вбудовані samples або clock_log.text; файлових ключів там немає), сервер MCP (run_scenario, лише вбудований вміст) і засіб запуску сценаріїв Kshana Studio. Обидва файли сценаріїв вбудовані (kshana example holdover-test-example).