holdover-test (тип сценарію)

Тип сценарію рушія v0.40.0, родина Годинники, синхронізація часу та holdover. Лише консультативно: результат аналізу від дослідницького та інженерного інструмента; це не навігаційне обладнання із затвердженням типу і не послуга забезпечення безпеки життя. Кожна позначка тут належить рушієві або матриці верифікації; тип вважається MODELLED, якщо матриця не каже іншого (як заробляється позначка: розділ Evidence у README).

Що він робить#

MODELLED тест holdover системи синхронізації часу, оцінений за записом похибки часу, який надає ОПЕРАТОР (журнал linuxptp ptp4l, phc2sys або ts2phc, журнал відстеження чи статистики chrony, журнал годинника TICC, TimeLab або RINEX, або пари time_s,time_error_ns). Тест має чотири кроки, і Kshana не виконує жодного з них: закріплений БАЗОВИЙ рівень, GNSS ВІДКЛЮЧЕНО оператором (антенний кабель або вихід симулятора; Kshana нічого не передає й нічим не керує) у заявлений момент, HOLDOVER на власному генераторі системи та ВІДНОВЛЕННЯ після того, як оператор повертає GNSS у другий заявлений момент. Запис розділяється за цими двома моментами. Базовий рівень: статистика похибки часу та маски ITU-T, написані для закріпленого годинника. Holdover: статистика, дробове зміщення частоти, яке утримувала система (пряма за методом найменших квадратів), маски, написані для holdover або автономного годинника, огинаюча holdover ePRTC-A за заявленою тривалістю закріпленого стану та час до перевищення кожного бюджету похибки часу. Відновлення: чи і коли |TE| потрапила в заявлену смугу й залишилася в ній, пік і найбільший стрибок. Кожну межу переписано з публічної таблиці ITU-T (маски синхронізації для телекомунікацій); формулювання — «виміряно відносно маски», а два моменти є твердженням оператора, а не перевіреними. Запис, надто короткий для маски, є НЕПОВНИМ і ніколи не екстраполюється. Див. docs/TIMING-HIL.md.

Один прогін scenarios/holdover-test-ptp4l.toml підсумовується так: holdover-test: holdover 1795 с, макс.|TE| 59,0 нс; prtc-a PASS, eprtc-a-holdover FAIL; відновлено через 0 с після повернення GNSS (MODELLED, виміряно відносно маски)

Входи#

Зі схеми (kshana kinds --json):

• Обов'язкові поля: test, series
• Необов'язкові поля: masks, budgets

Приклад scenarios/holdover-test-ptp4l.toml задає, зокрема:

Запуск#

kshana scenarios/holdover-test-ptp4l.toml

Цей різновид використовують 2 вбудовані сценарії; решта — у scenarios/.

Що це дає#

Скалярні результати цього прогону з одиницями, які вказує рушій:

Позначка результату (від рушія): MODELLED — тест holdover, оцінений за записом похибки часу, наданим оператором. Кожна межа перенесена з названої відкритої рекомендації ITU-T, а результат виміряно відносно маски; він нічого не говорить про те, чи відповідає якийсь годинник або система рекомендації, і ніхто його не оцінював і не затверджував

Докази#

MODELLED: рядки матриці верифікації, що називають цей різновид.

• MODELLED Вид holdover-test: запис похибки часу (журнал linuxptp, chrony, TICC, TimeLab або RINEX для годинника чи пари time_s,time_error_ns) поділяється у два моменти, які вказує оператор для вимкнення та відновлення GNSS, на базову частину, holdover та

Рядки, які задіяв сам прогін, з оракулом, що його дає матриця кожному (публічні джерела названі там):

• MODELLED Детерміновані, хешовані за сценарієм, SBOM + міжплатформні еталонні шлюзи. Оракул (ExternalDataset): відповідність SBOM офіційній схемі JSON CycloneDX 1,5 (+ дійсні ідентифікатори SPDX) — зовнішній опублікований стандарт, нуль помилок валідації на всьому графі залежностей; частина щодо детермінованості FoM / побайтової відтворюваності залишається закріпленою перевіркою самоузгодженості, тому рядок залишається MODELLED
• VALIDATED Максимальна похибка часового інтервалу та девіація часу, які повідомляє вид сценарію telecom-timing для запису holdover телекомунікаційного масштабу: ковзне вікно O(n) на монотонній черзі. Оракул (ExternalDataset): allantools 2024,06 — незалежна стороння бібліотека стабільності частоти — mtie() і tdev() на tests/fixtures/telecom_timing/holdover_te_series.csv, ряд розібрано з того самого тексту з 17 значущими цифрами з обох боків; еталон записує SHA-256 ряду і може бути відтворений офлайн за допомогою tests/fixtures/telecom_timing/generate_telecom_timing_reference.py. Перевіряє ОЦІНЮВАЧІ на цьому записі, а не син
• MODELLED Перенесені межі ITU-T G.8272 (07/2025) PRTC-A/B, G.8272.1 (2024) Amd. 1 (07/2025) ePRTC у синхронізованому стані та ePRTC-A holdover (зокрема огинна похибки часу з таблиці 3). Оракул (InternalConsistency): Перенесення названих рекомендацій (вільно доступних на itu.int), кожна межа із зазначенням таблиці чи пункту, з переліком усіх непідтверджених або нереалізованих позицій у docs/TELECOM-TIMING.md; тотожності неперервності у точках зламу, які випливають із таблиць, перевіряються в тестах. Перенесення стандарту з перевірками внутрішньої узгодженості, а не тест на відповідність і не зовнішня перевірка за еталоном. 0,30 раунд 2 (попередня реєстрація
• MODELLED Вид holdover-test: запис похибки часу (журнал linuxptp, chrony, TICC, TimeLab або RINEX для годинника чи пари time_s,time_error_ns) поділяється у два моменти. Оракул (InternalConsistency): Ручне обчислення на записах, побудованих за формулами, у яких нахил, стрибок, екстремум і час відновлення відомі до прогону (тести їх наводять), а також маски, огинна та бюджети рядків telecom-timing вище. Жодного лабораторного вимірювання реального holdover не оцінювали і жодного зовнішнього оракула не порівнювали, тому вид не робить жодних тверджень про будь-який годинник чи систему; перед будь-яким остаточним висновком для окремого класу годинників потрібен партнер із лабораторії синхронізації часу

Обмеження#

Що, за власним звітом прогону, не обчислено за моделлю або не перевірено за зовнішнім еталоном:

• MODELLED — тест holdover, оцінений за записом похибки часу, наданим оператором. Кожна межа перенесена з названої відкритої рекомендації ITU-T, а результат виміряно відносно маски; він нічого не говорить про те, чи відповідає якийсь годинник або система рекомендації, і ніхто його не оцінював і не затверджував. Моменти вимкнення та відновлення GNSS — це твердження оператора, і їх не перевірено. Консультативне програмне забезпечення (результат label)
• Тест holdover системи синхронізації часу рівня MODELLED, оцінений за записом похибки часу, який надає ОПЕРАТОР (журнал linuxptp ptp4l, phc2sys або ts2phc, журнал відстеження чи статистики chrony, журнал годинника TICC, TimeLab або RINEX чи пари time_s,time_error_ns). (каталог видів (kshana kinds --json))
• Відтворюваність і гарантування якості програмного забезпечення — MODELLED, а не перевірено за зовнішнім еталоном: підтвердження частини вимоги перевірено зовні, але вся можливість складається з обчислених за моделлю частин, тому можливість залишається обчисленою за моделлю. (матриця верифікації (docs/MODELLED-RATIONALE.md))
• Маски телекомунікаційної синхронізації ITU-T з PASS/FAIL і запасом мають рівень MODELLED, їх не перевірено за незалежним еталоном: звірено з власною замкненою / аналітичною тотожністю — це виявляє помилки перенесення та коефіцієнтів, але не є зовнішнім оракулом. (матриця верифікації (docs/MODELLED-RATIONALE.md))
• Тест holdover, оцінений за записом похибки часу, наданим оператором, має рівень MODELLED, його не перевірено за незалежним еталоном: звірено з власною замкненою / аналітичною тотожністю — це виявляє помилки перенесення та коефіцієнтів, але не є зовнішнім оракулом. (матриця верифікації (docs/MODELLED-RATIONALE.md))

Див. також#

• Сторінка родини: Годинники, синхронізація часу та holdover
• Усі різновиди: KINDS.md
• Тематична сторінка: TIMING-HIL.md
• Тематична сторінка: HARDWARE-SAFETY.md