タイミングのハードウェア・イン・ザ・ループ：アンテナを外し、ホールドオーバーを採点する

通信事業者や電力事業者は、GNSS を取り去ってクロックの挙動を観察することで、タイミングシステムを試験します。Kshana はそれを代行せず、事業者の機器にも触れません。事業者自身の計測器が作成した時刻誤差の記録を読み込み、事業者が明記した 二つの時刻で分割し、各ステップを公開の ITU-T マスクに照らして測定します。シナリオのカインドは holdover-test で、例のシナリオは scenarios/holdover-test-example.toml と scenarios/holdover-test-ptp4l.toml です。

これはハードウェア安全のステージ 1です。受動的で受信専用であり、Kshana からの RF はありません（HARDWARE-SAFETY.md）。助言用ソフトウェアであり、型式承認を受けた機器ではありません。この手順を格付け、承認、確認した者はおらず、システムが勧告を満たすかどうかについては何も示しません。

手順#

運用者は 四つのステップを実行します。Kshana はそのいずれも実行しません。

Kshana にはできないため、運用者が行わなければならないことが二つあります。

• 二つの時刻を明記すること。 gnss_removed_s と gnss_restored_s は運用者の申告です。Kshana は記録から除去を検出せず、時刻の検証も行いません。誤った時刻はステップの境界を動かし、したがって結果も変えてしまいます。
• 記録と時刻には同じクロックを使ってください。クロックログでは、時間軸が最初の読み値から始まるため、二つの時刻はログの最初の行からの秒数です。

記録するもの#

次のいずれかを、既存の clock_log リーダー（CLOCK-LOG-FORMATS.md）で読み込めます。

記録が何を測定しているかが重要です。サーボログ（linuxptp、chrony）が記録するのは、デーモンが測定し補正している最中のオフセットです。これはサーボ制御下に残る時刻誤差であり、クロックを UTC に対して独立に測定したものではありません。基準を実際に取り除く試験のホールドオーバーのステップでも、サーボログが示すのはデーモンが認識していた値であり、真の誤差とは異なる場合があります。独立した参照に対する 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、ソース。指定がなければ通信タイミングの既定値）と、複数のソースを含むログから 一つを選ぶための [series.clock_log] 内の clock = "..."。

レポートの内容#

• steps：ベースライン、ホールドオーバー、復旧のそれぞれについて、開始と終了、サンプル数、時刻誤差の平均値、rms、最大値、終了値。
• masks：指定した各マスクを、その条件が指すステップで測定したもの。ロックされたクロック向けに書かれたマスクはベースラインで、ホールドオーバーまたは自律クロック向けのものはホールドオーバーで測定します。各チェックには、限界値、測定値、マージン、転記元の表が示されます。ステップが与えた以上に長い記録を必要とするマスクはINCOMPLETEであり、外挿は行いません。記録のサンプル間隔ではエンジンが評価できないマスクは、理由とともにNOT-EVALUATEDとなります。
• holdover：システムが保持した周波数偏差の比（ホールドオーバー時刻誤差に対する最小二乗直線の傾き。単位は ns/s で、十億分の一 に相当）、その直線まわりの残差、絶対時刻誤差の最大値とその発生時刻、除去の瞬間のステップ。
• holdover_envelope：ITU-T G.8272.1 の表 3 にある ePRTC-A のホールドオーバーエンベロープで、locked_duration_days に基づき、最初に超過した時刻を含みます。
• budgets：除去後、各時刻誤差バジェットが最初に超過した時刻。
• recovery：|TE| が帯域内に入り、待機時間のあいだ留まったかどうか、それが GNSS の復帰後どれだけ経って始まったか、復旧後のピーク、復旧中の連続するサンプル間の最大のステップ。
• curves：ベースラインとホールドオーバーのステップの MTIE と TDEV。
• verdicts：ステップごとの一語による要約。

すべての数値には単位と出所が付き、レポートの units ブロックに記載されます。

用語と限界#

• 結果はマスクに照らして測定されたものです。マスクは、自由にダウンロードできる ITU-T 勧告から転記したもので（telecom-timing カインドと同じ表で、TELECOM-TIMING.md に一覧があります）、勧告が「今後の検討課題」としている項目はすべて、補完せずに省いてあります。Kshana は、クロックやシステムが勧告を満たす、あるいは勧告に照らして承認されたとは言いませんし、レポートもそう述べません。
• MODELLED。ステップのロジック、直線近似、復旧の規則は、実行前に答えが分かっている式から作った記録で確認されています。実験室でのホールドオーバーが外部のオラクルに照らして採点されたことはなく、パートナーや実験室が何かに同意したこともありません。クロッククラスごとの数値を格上げするには、タイミング実験室が必要です。
• 対象外のこと（すべてのレポートに明記されます）：GNSS が明記された時刻に実際に除去・復旧されたかどうか。運用者が記録しなかったステップ。一秒に一回より遅くサンプリングされた記録に対する、0.1 Hz のフィルターで定義されたマスク。計測器自身の測定不確かさ。時刻誤差の記録を超える勧告の手順（温度プロファイル、パケットネットワーク負荷）。
• 復旧の帯域は、試験自身が選ぶものです。既定の 100 ns は PRTC-A（ITU-T G.8272）の最大絶対時刻誤差です。これは便宜的な基準線であり、復旧に関するどの勧告の要件でもありません。
• 送信経路はありません。Kshana はファイルを読み込みます。信号は生成せず、実験室で GNSS を取り除く作業は、実験室自身の機器で、その実験室自身の許可のもとで行います。

利用形態#

holdover-test はシナリオのカインドであるため、カインドが動作するすべての場所で実行できます。kshana <scenario.toml>、Rust API（kshana::api::run_toml）、Python バインディング（kshana.run）、WebAssembly と npm のビルド（インラインの samples または clock_log.text。ファイルキーはそこでは使えません）、MCP サーバー（run_scenario、インラインの内容のみ）、Kshana Studio のシナリオランナーです。二つのシナリオファイルは同梱されています（kshana example holdover-test-example）。