受信機の信頼性：実際の GNSS 受信機ログの評価

kshana receiver-trust は、実際の全球測位衛星システム（GNSS）受信機のログを読み取り、そのログに対してエポックごとに信頼性モニターを実行し、受信機のフィックスがいつ、なぜ信頼できなくなったかを示します。また、実行の前にあなたが示したイベントと予測に照らしてログを採点することもできます。具体的には、各イベントが時間内に検出されたか、そしてモデルから計算した搬送波電力対雑音密度（C/N0）の低下が受信機の測定値と一致するかどうかです。

観測量は受信機自身のものです。モニターとそのしきい値は、エンジンとあなたのものです。すべての結果には、そのラベル、ログの SHA-256、実行時に用いたすべてのしきい値が記録されるため、実行を再現し、監査できます。

航行中の船舶で、ライブスコアと海図システムの前段に置くオプションのゲートを使う場合は、MARITIME-TRUST.md を参照してください。

実行する#

kshana receiver-trust examples/receiver-trust/session.toml

これは、シナリオの隣に session.result.json、session.trust.csv（エポックごとに一行）、session.trust.svg（時間に対する平均 C/N0 とその下に信頼状態）を書き出し、一行の判定を表示します。例のログは形式を示すために作成した合成データです。path は、お使いの受信機のログに向けてください。

上の図は MARITIME-TRUST.md の船舶デモで、作り物のログと助言のスコアによるものです。

同じシナリオは、Python（kshana.receiver_trust(toml)）、WebAssembly パッケージ（receiver_trust(toml)、ログはインライン）、および Model Context Protocol（MCP）サーバーの assess_receiver_log ツールから実行できます。

読み取れるログ#

これら三つの詳細、出典、制限：MACHINE-INPUTS.md。

リーダーが生成する各エポックには、入力内のバイトオフセット source_span、[start, end) も付きます。これは、そのエポックに寄与したレコードを含む最小の連続範囲で、イベントウィンドウに対して正確な生データの断片をハッシュ化できます。NMEA：エポックが現在である間に読み取ったすべての行（無関係な行が文の間に挟まる場合はその上位集合）。UBX：そのエポックのフレーム。RINEX 3：各 > 行から次の行までのエポックレコード。Android：そのエポックの Raw 行（Fix 行は Raw 行を持たないエポックの場合のみ）。ライブストリームの場合、および明確に定義できない場合（RINEX 2）は付きません。

ファイルは path（シナリオ自身のフォルダーを基準に解決）で渡すか、text または base64 としてインラインで渡します（ブラウザーでは後者のみ）。

第二のセンサーとしての IMU ログ#

[log.imu] は、同じクロックの慣性ログを追加します。

[log.imu]
format = "csv"          # or "euroc"
path = "imu.csv"        # or text / base64
heading0_deg = 90.0     # heading at the first IMU sample
yaw_axis_down = true    # body z down (NED/FRD); false for z up (ENU/FLU)
time_offset_s = 0.0     # added to the IMU clock to reach the log's t_s

ヨーレートは heading0_deg から積分され、受信機ログに方位がない箇所の方位を補います。これにより、heading-course モニター（プラットフォームに heading_sensor = true が必要）が、ジャイロの方位と対地針路を比較します。ジャイロはドリフトします。方位の良さは積分ウィンドウ次第であり、何を不一致とみなすかは hdg_cog_tol_deg で決まります。csv のレイアウトは MACHINE-INPUTS.md に記載されています。IMU のバイト列は、シナリオのハッシュとエビデンスパックのシナリオハッシュの一部です。インライン（text/base64）はすべての環境で動作し、path はファイルを読み取らない環境では拒否されます。

プラットフォーム：静止または船舶#

上記のモニターはアンテナが固定されていることを前提としています。シナリオは、実行前にトップレベルの [platform] テーブルでプラットフォームを宣言します。宣言がない場合、プラットフォームは static となり、何も変わりません。

[platform]
kind = "vessel"            # "static" (default) or "vessel"
max_speed_kn = 30.0        # default 30
max_accel_mps2 = 0.5       # default 0.5
max_turn_rate_dps = 6.0    # default 6
antenna_height_m = 18.0    # no default: without it the sea-level monitor does not run
heading_sensor = false     # true: the stream carries a gyro heading (HDT or THS)

kind = "static" の下では、船舶用のキーは拒否されます。船舶の場合、position-jump モニターは動作しません。これは較正平均からの距離を測るもので、移動するアンテナでは誤りになるためです。結果の monitor_config には、プラットフォームと使用した上限が記録されます。

乗組員訓練用に kshana nmea-scenario で作成された合成 NMEA ストリームは、NMEA リーダーで受け付けられ、他の NMEA ログと同様にこの種別で実行できます。

モニター#

各モニターには、それぞれのデータが必要です。ログにデータがないモニターは実行されず、monitors_run にも記載されません。最初の calibration_s 秒（既定は 60）はベースラインの設定に使われ、警報は出しません。

較正済みプロファイル（オプトイン）。 [monitors] profile = "jammertest-2024-calibrated" は、三つの干渉しきい値を、公開されている JammerTest 2024 データセット（シナリオごとに u-blox ZED-F9P 一台。Zenodo 15911589）で較正した値に置き換えます：cn0_drop_db = 1.5、agc_k_sigma = 3.5、jam_ind_threshold = 29。この較正は事前登録されており（xval/jammertest-trust/PREREGISTRATION.md）、プロファイルは MODELLED であり、一つの公開キャンペーンに合わせて当てはめたものです。その cn0_drop_db しきい値は、事前登録した保留データでの誤警報の合格基準（0.02 に対して 0.0231）を満たしませんでした。AGC とジャミング指標の合格基準、および和集合の合格基準（誤警報 0.033、検出 0.81）は満たしています（xval/jammertest-trust/RESULTS.md）。これが成り立つのは、そのイベントにおけるその受信機タイプに限られ、予定された攻撃枠に対するものであり、データセットの CSV ログで較正されています（UBX ログでは 二つのフォルダーで誤警報が増えます）。プロファイルを使った結果には、適用したしきい値が記録され、これらすべてを述べた profile_note が付きます。プロファイルを使わない場合は、上記の既定値が適用され、すべての出力は変わりません。

vessel プラットフォームでは、移動プラットフォーム用のモニターも動作します（しきい値はトップレベルの [maritime] テーブルにあり、既定値はすべて src/receiver_trust/maritime.rs に記載）。各モニターにはそれぞれのデータが必要で、判定を下した場合にのみ monitors_run に記載されます。

エポックは、RAIM、クロックモニター、解の失敗、または位置ジャンプが警報を出すか、C/N0 低下がしきい値の二倍に達した場合に信頼不可となり、それ以外の警報があれば劣化、なければ正常となります。

エンジンの経路（raim、solve-failure、clock）は、tests/jammertest_spoof_oracle_support にある JammerTest 2024 のスプーフィングのオラクルと同じ計算です。tests/receiver_trust_jammertest.rs は、公表されている八つの開始時点すべてで、最初の警報が同じエポックに現れ、同じ種類であることを確認します。

信頼スコア（船舶プラットフォーム）#

船舶では、較正後のすべてのエポックに 0 から 100 までのスコアと、100 にならない理由も付きます。この対応づけは決定論的で、どのログを採点するよりも前に固定されており、学習も、イベントへの当てはめも行いません。各モニターは、その根拠を比率 statistic / threshold（1 以上で警報）に換算し、比率がスコアから差し引く量は次のとおりです。

points = weight * clamp((ratio - onset_ratio) / (full_ratio - onset_ratio), 0, 1)
score  = round_to_0.1( clamp(100 - sum of points, 0, 100) )

つまり、モニターはしきい値の onset_ratio（既定は 0.5）未満の間は何も差し引かず、しきい値で重みの半分、しきい値の full_ratio 倍（既定は 1.5）で全体を差し引きます。スコアはどの統計量についても非増加です。あるエポックで報告のない情報源は、その直前の統計量を evidence_hold_s（既定は 10 s。5 s ごとに送られる C/N0 センテンスの二周期分）だけ保持し、警報としても減点としても同様に扱います。

丸めは四捨五入（floor(x * 10 + 0.5) / 10）で、帯域は丸めたスコアのものであり、クランプは丸めより前に行います。減点に記載されるのは、点数がゼロを超えるモニターのみで、その比率と丸め前の点数を添え、点数の大きい順に並べます。点数が等しい減点は、モニター名 cn0-drop、agc、jam-ind、loss-of-lock、position-jump、raim、clock、solve-failure、kinematic、heading-course、speed-log、sea-level、cn0-spread、cn0-rise、time-consistency、osnma、geometry の順に並べます。検査が合否で決まるモニター（解の失敗、認証の失敗）には、比率 1.5、すなわち全重みが与えられます。記載される点数は、0 でのクランプ前のものです。

[score]
nominal_min = 90.0         # score >= 90: nominal
degraded_min = 55.0        # 55 <= score < 90: degraded; below 55: untrusted
onset_ratio = 0.5
full_ratio = 1.5
evidence_hold_s = 10.0
[score.weights]            # overrides; a monitor not listed keeps its default
sea-level = 30.0

帯域の境界は重みから導かれます。警報を出す最も軽いモニターでも、しきい値で 12.5 点を差し引くため、いずれかの警報が出れば正常の帯域から外れます。60 点未満の単独のモニターでは、信頼不可の帯域に単独では達しません（複数が重なれば達します）。結果にはスコアモデル（score_model）が記録され、各エポックには score.deductions、すなわちどのモニターが減点したか、その比率と点数が付きます。船舶では、エポックの状態はそのスコアの帯域です。

ジオメトリ：攻撃を思わせる不整合とは別の、自然な劣化#

岸壁のクレーンの脇、閘門の中、または高い船体の下にいる受信機は、衛星を失い、攻撃とは無関係の理由でフィックスが悪化します。0.36 以降、ジオメトリ設計メモ（docs/design/2026-10-12-geometry-and-skyline-design.md、4 節）に従い、すべてのエポックが衛星ジオメトリを持ち、船舶のスコアにはジオメトリモニターがあり、すべての減点にクラスが付きます。クラスは geometry（空）、environment（信号環境）、inconsistency（攻撃を思わせる証拠）のいずれかです。

ジオメトリの出どころ。追尾している各衛星の仰角と方位角（NMEA GSV、UBX NAV-SAT）から、エンジンの唯一の DOP カーネル（orbit::dop、gnss_lib_py に対して VALIDATED）で DOP（精度低下率）を導出します。source = derived。それができない場合は、受信機が示す DOP と使用衛星（NMEA GSA）を使います。source = reported。多くのバスが GSV を数秒おきに送るため、空の位置情報と GSA はスコアの evidence_hold_s（既定は 10 s）の間は有効とみなされます。エポック内で不完全な GSV セット（抜粋の末尾、欠落したセンテンス）は使用しません。どちらもないログ、たとえば GGA と RMC のみの NMEA や、現時点の Android および RINEX のログは、ステータス unknown と「geometry unknown」という注記が付きます。エンジンは与えられていないジオメトリを推測せず、ジオメトリモニターは動作しません。

ステータスは記述的なもので、スコアにとって重要なのは（後述の）ラベルです。degraded には、情報のみの sky-blocked の場合が含まれ、これは DOP が良好または普通でも生じ得ます。スコアに反映されるのは poor ラベルだけです。

ラベル（常に報告され、スコアには反映されません）。各エポックの geometry.label は、good（HDOP が hdop_good 2 以下、PDOP が pdop_good 3 以下で、かつ used_good 6 機以上の衛星）、poor（HDOP が hdop_max 4 を超える、PDOP が pdop_max 6 を超える、または衛星が min_used 5 機未満）、その中間の fair、または unknown のいずれかです。エポックの注記は、常にラベルと数値で始まります。たとえば「geometry fair: HDOP 1.105, PDOP 1.831, VDOP 1.410, 8 satellites; not scored (the score deducts only above HDOP 4, PDOP 6 or below 5 satellites)」のようになり、該当する場合は「, signal loss」が追加されます。

ジオメトリモニター（船舶スコア）。ジオメトリが不良でない限り何も差し引きません。その比率は max(hdop / hdop_max, pdop / pdop_max, min_used / n_used) で、これが 1 以下の間（良好または普通のジオメトリ、8 機の GPS のみの開けた空を含む）は何も差し引かないため、そのようなログは 0.35 とまったく同じスコアになります。1 を超えると、減点は full_ratio（しきい値の 1.5 倍：HDOP 6、PDOP 9、衛星 3 機）で cap_points（15）まで線形に増加します。比率 1.25（HDOP 5、または衛星 4 機）で 7.5 点、1.5 以上で 15 点（スコア 85、劣化）です。単独では、スコアを floor（既定はスコアの degraded_min、55）より下に下げることはなく、ジオメトリだけでは劣化の帯域までしか達せず、信頼不可には達しません。有効な上限は min(cap_points, 100 - floor) であるため、degraded_min を引き上げる [score] テーブル（たとえば degraded_min を 90 とした 0.35 版のもの）は、拒否されるのではなく上限を 100 - degraded_min に下げ、degraded_min を下回る floor の設定は拒否されます。このモニターは警報を出しません。いずれかのエポックで判定を下した場合（ログがジオメトリを与える船舶）は monitors_run の最後に記載され、0.35 との同一性には数えられません。[score.weights] のエントリではなく（設定すると拒否されます）、有効な上限と下限は geometry_model.cap_in_force と geometry_model.floor_in_force に記録されます。不良なエポックの注記には理由が書かれます。たとえば「geometry poor: HDOP 5.200, PDOP 7.900, VDOP 4.100, 7 satellites; degraded by geometry: HDOP 5.200 above 4 (derived from 7 logged satellites); not an inconsistency」のようになります。

クラス。すべての減点（score.deductions[].class）：

偽の不良な空に対するガード。スプーフィングを行う者は、薄い GSV を送ったり高い HDOP を報告したりして、許容を得ようとするかもしれません。エンジンはラベルを付けるだけで、許しはしません。不良なジオメトリによって他のチェックが緩められることはなく、受信機が示す HDOP（保持期間内の GSA、なければ GGA）は、示された空から導出した HDOP と比較されます。両者の差が max(reported_vs_derived_tol, reported_vs_derived_rel × derived HDOP)（1.0、または導出した HDOP の 25 %、いずれか大きい方）を超えると、そのエポックには reported_derived_mismatch: true が付き、ジオメトリが不良であれば、その減点は inconsistency に分類されます。ジオメトリが良好または普通の場合、食い違いは報告されるだけでスコアには反映されません。ジオメトリが不良でない限り、何も差し引かれません。これは意図的な選択です（0.36）。「不良でない限りゼロ」がすべてのエポックで成り立つため、良好および普通のジオメトリは 0.35 とまったく同じスコアになり、偽の HDOP が黙って見過ごされることもありません。フラグ（reported_derived_mismatch）は結果のすべてのエポックとすべてのライブ行に付き、注記には「…beyond the tolerance: reported, not scored (the geometry is not poor)」または「…: the geometry deduction is classed an inconsistency」と書かれ、geometry_summary.hdop_mismatch がエポック数を数え、エビデンスの要約ページにはゼロを含めてその件数が表示されます。25 % はREPRESENTATIVEなエンジニアリング上の選択であり、測定値でも標準の値でもありません。コンステレーションごとに一つのクロックを解く受信機や、追尾している衛星の一部（仰角マスク、C/N0 のカット、RAIM の除外）で解く受信機が示す HDOP は、追尾しているすべての衛星の単一クロック HDOP とは、HDOP が大きいほど拡大する量だけ異なります。そのため、固定の許容差だけでは、自然な不良ジオメトリを不整合と読み違えることになります。それより大きな差は、依然として不整合と読まれます。geometry に分類された減点は、空についての記述であり、攻撃がなかったという所見ではありません。

信号喪失は空ではありません。受信機が視界にあるとして挙げる衛星（low_elev_deg より上）が追尾されていない場合、エンジンは視界にあるすべての衛星の DOP も導出します。その視界内の DOP がしきい値内にあり、かつ何も追尾されていないか、追尾されていない衛星が水平線の周囲に分散している（半分に偏っていない）場合、空はあったのに信号がなかったことになり、そのエポックには signal_loss: true が付き、注記は「satellites in view but not tracked: signal environment, not geometry」となり、ジオメトリの減点は environment に分類されます。水平線の半分に偏っている追尾されていない衛星は、引き続き遮られた空（壁、崖、岸壁）と読まれます。両側の遮蔽（峡谷や狭いフィヨルド）は、スカイラインが設定されるまでは信号喪失と読まれます。受信機のフィックスなしを示す番兵値は DOP ではありません。示された HDOP または PDOP が 99 以上、GGA の品質が 0、GSA のモードが 1 のとき、示された DOP はないものとして扱います。

出力で何が変わり、何が変わらないか。ジオメトリが不良でない限り、スコアは変わりません。ラベルは常に報告されます。追加されたキー：epochs[].geometry（status、reasons、source、n_used、hdop、pdop、0.001 に丸めた vdop、open_fraction（スカイラインが設定されるまで null）、max_azimuth_gap_deg、age_s、reported_hdop、reported_derived_mismatch、note、in_view（low_elev_deg より上にあるとして挙げられた衛星）、signal_loss、label）、すべての減点の class、および末尾の geometry_model（しきい値、保持期間、有効な上限と下限、出典、クラスの規則）と geometry_summary（ステータス別、ラベル別、減点クラス別のエポック数と、示された HDOP が食い違うエポック）です。score_model.weights は 0.35 と同じです。二つのテストが、これらのキーを取り除くと「0.36 portable」ベースラインのバイト列と一致することを保証しています（0.35.0 のハッシュで、エンジンがポータブルな数学に移行した際に再基準化され、0.35.0 がリリースしたものの記録としてテストに保持されています。docs/revisions/STUDIO15-portable-math-rebaseline.md）。tests/geometry_trust_no_change.rs は、二つの例セッションのすべての出力（結果 JSON、CSV、SVG、判定、再生したライブ行、$PKSHT、Prometheus、CEF、LEEF）を保証します。tests/geometry_corpus_identity.rs は、コミット済みのすべての船舶 NMEA コーパス（デモと海事リファレンスのフィクスチャ。それぞれ 8 機の GPS のみの開けた空としても用意され、さらにそれらのシードから生成した乗組員訓練シナリオ）のバッチ結果、要約、ライブ行、$PKSHT を保証します。ジャミングによってジオメトリが不良になる二つの訓練シナリオでは、不良でないエポックはすべて同一で、不良なエポックはすべてジオメトリの減点のみで異なります。ジオメトリが不良なログは、0.35 では失わなかった点数を最大 15 点失いますが、これは意図した変更です。デモではドラッグオフは inconsistency と読まれます。tests/geometry_trust.rs は、ログを編集して西の空を遮蔽し（普通：ラベルのみでスコアには反映されません）、西の空と東の衛星二つを遮蔽し（不良：ジオメトリの減点が付き、高い衛星も失われたため、ロックロスは environment）、15° 未満の衛星だけを失わせ（ロックロスは geometry）、空では説明できない HDOP を示す（不良ジオメトリの減点が inconsistency になる）ことを確認します。しきい値は MODELLED です。選んだものであり、いかなるログにも当てはめておらず、実データで自然な劣化と攻撃がどれだけの頻度で区別されるかについては、ここでは何も主張していません。

イベントと予測の指定#

[[events]]
label = "jammer on"
kind = "jamming"            # jamming, spoofing or other
onset_s = 120.0             # seconds since the first epoch of the log
end_s = 240.0               # optional; otherwise onset_s + compare.horizon_s
predicted_cn0_drop_db = 12.0  # optional, e.g. from a `jamming` scenario's link budget

[compare]
detect_tol_s = 10.0         # an alarm this soon after onset counts as a detection
cn0_tol_db = 3.0            # predicted and observed drops agree within this

各イベントについて、結果には、較正から開始時点までの誤警報、最初の警報とそのモニター、遅延、結果（detected、late、missed、または not-evaluable）、および予測に対する観測された C/N0 低下の中央値（agree、disagree、no-prediction、または not-evaluable）が示されます。不一致は報告され、調整で消されることはありません。許容差はシナリオ内にあり、シナリオは結果のハッシュに含まれます。

これが主張しないこと#

信頼性モニターは MODELLED です。そのしきい値は入力であり、実際の干渉に対する検出性能は、イベントの採点が測定するものであって、この種別が断定するものではありません。JammerTest 2024 のスプーフィングセッションでは、エンジン経路のモニターは一部の開始時点を 10 s 以内に捕捉し、他の開始時点では遅れます。数値については、VERIFICATION-MATRIX.md の「Clock-aided χ², RAIM, AGC, SQM fused per-epoch security FoM」の行を参照してください。一つのログと一致する予測は一つのデータ点であり、検証ではありません。