機械翻訳であり、ネイティブスピーカーによる確認は行われていません。英語版が基準です。

シナリオリポジトリのシナリオファイルと検証マトリクスから、ビルド時に生成しています。

シナリオのリファレンス

同梱されているすべてのシナリオファイル(193 個)を kind ごとにまとめたものです。説明はファイル自身のヘッダーコメントで、主要なパラメーターはトップレベルの設定です。ステータスは、その kind のモジュールについて検証マトリクスを読みます。Kshana Studio で開くと、記録された実行が開きます。

一機の衛星と 一つの地上局:各パスの斜距離、仰角、パス沿いのEs/N0、各ステップで選ばれるDVB-S2のMODCOD(ETSI EN 302 307-1 Table 13のしきい値に実装マージンを加えたもの)、およびマスクで閉じる一定符号化のベースラインに対してACMが運ぶデータ量。MODELLED。

aocs#

宇宙機の姿勢制御:三つ以上の釣り合いのとれたリアクションホイールを持つ剛体ハブの慣性指向スルーを、MRPフィードバック(L = -K sigma - P omega)で行い、最小ノルムのホイールトルクを各モーターの上限でクリップし、RK4とゼロ次ホールドで計算します。オプションで、シミュレートしたジャイロ(角度とレートのランダムウォーク)とスタートラッカーから、乗算型EKFによるループを閉じます。整定時間、最終および最大の指向誤差、最大のホイール速度とトルク、飽和した割合、角運動量のドリフトを報告し、推定器を使う場合はその姿勢誤差とNEESも報告します。真の状態のループはBasilisk 2.9.1に対してVALIDATEDであり、推定器はMODELLEDです。

aocs-slew.toml

種別 aocs名前では台帳のモジュールと対応づけられていません

MRP フィードバックによるリアクションホイールの姿勢スルー、真の状態で閉ループ。

kind = "aocs"
duration_s = 600.0
dt_s = 0.1
sample_s = 1.0
k_nm = 3.5
p_nms = 30.0
pointing_threshold_deg = 0.1
axis = [0.5773502, 0.5773502, 0.5773504]

Kshana Studio で開く · GitHub で見る

aocs-slew-mekf.toml

種別 aocs名前では台帳のモジュールと対応づけられていません

MRP フィードバックによるリアクションホイールの姿勢スルー、MEKF 推定値で閉ループ。

kind = "aocs"
duration_s = 600.0
dt_s = 0.1
sample_s = 1.0
k_nm = 3.5
p_nms = 30.0
pointing_threshold_deg = 0.1
axis = [0.5773502, 0.5773502, 0.5773504]

Kshana Studio で開く · GitHub で見る

aperture-duty-cycle#

アパーチャのデューティサイクル:コンタクト計画が、可動アパーチャのプールに対して暗黙のうちに定める、航法と通信の時間配分。コンタクト計画([[contacts]]のaos_s/los_sウィンドウのリスト。各ウィンドウは航法または通信を要求し、passes予測器が出力するものと同じaos_s/los_sの語彙を使います)、アパーチャの数、調停ポリシー(既定は航法優先、または通信優先、または非プリエンプティブな先着順)を受け取り、航法デューティ、通信デューティ、アイドルデューティ、およびセッションごとの途切れ(セッションが要求したが、どのアパーチャも対応しなかったコンタクト時間)を報告します。ウィンドウ境界に対する厳密な区間スイープにより、接するウィンドウは競合せず、アパーチャ秒が二重に数えられることはありません。航法、通信、アイドルのアパーチャ秒は独立に累積され、apertures*horizon_sに対して閉じます。レポートには、解決された調停ポリシーとその完全な定義、およびデューティと途切れの定義を明記します。調停ポリシーなしで引用されたデューティの数値は再現できないためです。MODELLEDのスケジューリング演算:アパーチャがサービスやセッションを切り替える際のスルー、再同調、切替の時間は計上されず、データ量、バッファ状態、エネルギー収支、リンクの成立は判断に影響せず、コンタクトウィンドウは入力であり、その幾何はそれを生成したものに依存します。地上セグメントのスケジューリング製品ではありません。

aperture-duty-cycle.toml

種別 aperture-duty-cycle名前では台帳のモジュールと対応づけられていません

アパーチャのデューティサイクルのデモンストレーター(地上セグメントと運用)。

kind = "aperture-duty-cycle"
apertures = 2
arbitration = "navigation-priority"
name = "nav-1"
service = "navigation"
aos_s = 0.0
los_s = 600.0
name = "comms-1"

Kshana Studio で開く · GitHub で見る

araim-reference-check#

公開されたARAIM認証用の参照ベクトル:エンジンのARAIMの水平・垂直保護レベルを、WG-C ARAIM Technical Subgroup自身の数値例に対して、それらの文書自身が示す許容差(TOL_PL = 5e-2 m)で実行します。二つのベクトルがフィクスチャとしてコミットされており、それぞれに取得URL、取得日、ソースファイルのSHA-256、ページが付いています。Reference Airborne Algorithm Description Document v3.1(2019)のAppendix D(自己整合しており、受け入れ用のベクトル)と、Milestone 3 Report(2016)のAnnex A section A.IX(研究の文献リストが引用する記述)です。公開されているすべての入力(10機の衛星、2コンステレーションの幾何行列、C_intとC_accの分散の対角成分、b_nom、P_sat、P_const、LPV-200の定数セット)と、公開されているすべての出力(VPL、HPL、EMT、sigma_v_acc、K_fa_3、および二つのコンステレーション故障モードのsigma_3、sigma_ss_3、b_3)は、エンジン自身の数値およびそれらの絶対差とともに報告されます。保護レベルの方程式はここで解き直すことはありません。参照のモードリストをエンジンの既存のraim::araim_protection_level / araim_integrity_riskに渡しているため、試験対象の二分法とガウス裾の代数はエンジン自身のものです。幾何、部分解、検出しきい値、公開された予算配分だけが、そのために構築されています。2019のベクトルに対して外部で確認済み:VPL 18.2926 mに対し公開値18.3 m、HPL 13.4063 mに対し13.45 m、EMT 7.2997 mに対し7.2998 m、sigma_v_acc 1.3694 mに対し1.3694 m、そして公開されている六つの中間値はすべて、最後に印字された小数桁の半単位以内です。2016のベクトルには、報告書が隠さず明記している内部の欠陥が二つあります。Gの行3の符号の誤植と、文書がN_fault_max = 1(12モード)と述べているのに57の故障モードで評価されたK_fa_3です。そのため、幾何の中間値は正確に再現される一方、保護レベルは測定された不一致として報告され、受け入れの数値からは除外されます。これらを吸収するために許容差が広げられることはありません。出力されるすべての数値フィールドには単位と出所の区分が付き、転記した数値にはpublishedのラベルが付くため、計算値と取り違えることはありません。適用範囲:実装されているのはN_fault_max = 1(単一衛星および単一コンステレーションの故障モード)のみで、事前確率が複数事象の同時故障の部分集合を必要とするケースは、黙って切り捨てるのではなくREFUSEDとします。参照アルゴリズムの故障検出、除外、カイ二乗整合性チェック、二重計上の再配分ステップは対象外です。これは公開された参照アルゴリズムの数値例を再現するものであり、認証、耐空性に関する成果物、承認ではありません。

araim-reference-check.toml

種別 araim-reference-check名前では台帳のモジュールと対応づけられていません

エンジンの ARAIM 保護レベルを、WG-C サブグループ自身の計算例と照合。

kind = "araim-reference-check"

Kshana Studio で開く · GitHub で見る

ascent-losses#

自転しない球形の地球上での、多段機体の平面重力ターン上昇を、US Standard Atmosphere 1976を通して計算します(垂直上昇、ピッチキック、速度方向の推力)。重力損失、抗力損失、操舵損失、背圧損失を積分し、理想dvから損失を引いた値を燃焼終了時の速度と照合します。max-Q、最大加速度、燃焼終了時の状態も求めます。MODELLED。

ascent-losses.toml

種別 ascent-losses名前では台帳のモジュールと対応づけられていません

ILLUSTRATIVEの二段式ケロシン/酸素ロケット(実在の機体ではありません)の重力ターン上昇損失:1 km まで垂直に上昇し、10 s の間 3 deg のピッチキックを与え、その後は速度方向に推力をかけます。この実行は、重力、抗力、操舵、背圧の損失を積分し、理想 dv から損失を引いたものが燃焼終了速度に等しいことを確認します。MODELLED:平面で自転しない地球、一定の C_D、慣性飛行なし、キック以外の誘導なし。

kind = "ascent-losses"
payload_kg = 10000.0
drag_coefficient = 0.3
kick_altitude_m = 1000.0
kick_angle_deg = 3.0
kick_duration_s = 10.0
step_s = 0.1
dry_mass_kg = 25000.0

Kshana Studio で開く · GitHub で見る

attitude-budget#

3-DOFの姿勢・指向誤差バジェット:最悪ケースの重力傾斜外乱トルク((3/2)(μ/R³)ΔI)と、名前付きの1σ 寄与要因(センサーノイズ、リアクションホイールのジッター、熱、アライメント)に対する二乗和平方根の指向誤差バジェット、および支配的な項を、軌道高度と機体慣性の広がりに対して求めます。MODELLEDのスカラーAOCSバジェット — Basilisk/42に対するハードウェア前段階の補完であり、制御ループ、6-DoF、柔軟モードのシミュレーションではありません。

attitude-budget.toml

種別 attitude-budget種別に、外部参照で確認済みの台帳の行があります · 1 行中 1 行が確認済み

3-DOF の姿勢・ポインティング誤差バジェットのデモンストレーター(ハードウェア前の AOCS/GNC)。

kind = "attitude-budget"
altitude_km = 600.0
name = "star_tracker_noise"
sigma_arcsec = 5.0
name = "reaction_wheel_jitter"
sigma_arcsec = 8.0
name = "thermal_distortion"
sigma_arcsec = 4.0

Kshana Studio で開く · GitHub で見る

body-pnt#

太陽系の任意の天体の周りでの測位:名前で選んだ中心天体(火星、月、エウロパ、ガニメデ、タイタンなど、太陽系カタログの天体)の周りの周回機または地表ランダーが、その天体の周りの小規模なWalker航法コンステレーション(二体軌道に天体固有のJ2永年ドリフトを加えたもの、未知のユーザークロック)からの片道疑似距離を使って航法を行い、必要に応じて、クロック不要の深宇宙の地球からの往復レンジも使います。その方向と距離は、各エポックで解析的な太陽系エフェメリスから得られます。視線は天体の平均球で遮られ、地表のユーザーには仰角マスクも必要です。エポックごとに、視野内の中継機、地球が周縁より上にあるかどうか、コンステレーションのみのGDOPとPDOP(幾何および位置の精度低下率)、地球の行を含む場合と含まない場合の形式的な一シグマの位置不確かさ、およびそれぞれの場合のシード付きガウス・ニュートン最小二乗解の誤差を求めます。実行全体では、可用性、地球の可視率、PDOPの中央値、RMS誤差、形式的シグマの中央値に加え、そのエポックにおける地球と天体の間の光行時間、往復時間、シャピロ遅延、太陽との離角も求めます。MODELLED:中継機の軌道、ノイズレベル、瞬時測定モデルはモデル化上の選択であり、ミッションの航法データに対して検証されたものではありません。天体の定数はbody.rsに引用された公表値であり、地球の幾何は太陽系エフェメリスのラベルを引き継ぎます。

europa-surface-pnt.toml

種別 body-pnt名前では台帳のモジュールと対応づけられていません

エウロパでの着陸機の測位:木星の衛星のケース。

kind = "body-pnt"
body = "Europa"
epoch = "2027-02-19T00:00:00"
duration_s = 306822.0
step_s = 1800.0
seed = 11
kind = "surface"
lat_deg = 20.0

Kshana Studio で開く · GitHub で見る

mars-orbit-pnt.toml

種別 body-pnt名前では台帳のモジュールと対応づけられていません

火星航法コンステレーションと深宇宙リンクによる、低高度の火星周回機の測位。

kind = "body-pnt"
body = "Mars"
epoch = "2027-02-19T00:00:00"
duration_s = 88775.0
step_s = 300.0
seed = 7
kind = "orbiter"
altitude_km = 300.0

Kshana Studio で開く · GitHub で見る

campaign#

キャンペーン:既存のシナリオの種類を一つの実行に組み合わせたもので、すべての数値は指定した種類の実際の実行から読み取ります。四つのセクションを任意の組み合わせで使えます。フェーズ:共有の一つのタイムライン上で連鎖するミッション。各フェーズは一つ以上のシナリオを実行し(例:ジャミング、次にスプーフィング、次に慣性航法装置が並走する中での時計のホールドオーバー、次にインテグリティ警報、次に回復)、その出力は、種類ごとのプリセットまたは明示的な結果パスによって、名前付きのチャンネル(ガードに対する時計の時刻誤差、追尾下限に対する搬送波対雑音密度比、警報限界に対する保護レベル、位置誤差、追尾中の衛星、警報フラグ)に読み込まれ、ゼロ次ホールドで共通のグリッドにリサンプリングされ、フェーズ境界とイベントも付きます。状態は、carry(チャンネルが前のフェーズの終了値から続く)、handoff(前のフェーズの数値をこのフェーズのシナリオに書き込む)、end_at(スプーフィングモニターの検出時刻など、実行が計算した時刻でフェーズが終わる)によって引き継がれます。スイープ:任意の種類のシナリオの、ドット区切りのキー一〜三個にわたるグリッド(整数のセグメントはテーブルの配列を指します。例:system.2.sisre_m)。指標は結果パスで読み取り、実行回数が一を超える場合は、すべてのノードでシード付きのモンテカルロのアンサンブルを行います。MONTE_CARLO:実現kはbase_seed + kで実行され、各指標は平均、標準偏差、最近順位法による5/50/95パーセンタイル、および平均に対する固定シードのブートストラップ95%信頼区間を報告します。合成:共有の値(一つのジャマーの出力と位置を、船舶と道路の受信機に書き込む)のもとでの複数のシナリオで、最良/最悪を合わせた要約が付きます。結果には、キャンペーンのハッシュ、すべてのメンバー結果にわたるダイジェスト、出力されるすべての数値に対する単位のエントリーが含まれます。相互運用のエクスポートは、幾何を持つ各メンバーシナリオを、それぞれ独立したファイルセットとして書き出します。合成に関する恒等性がテストされています。単一フェーズのキャンペーンはスタンドアロンの実行をビット単位で再現し、固定シードのアンサンブルはバイト単位で安定しており、白色周波数雑音の時計ではアンサンブルの平均が報告された区間の内側に収まり、ばらつきはsqrt(q_wf * tau)と一致します。MODELLED:加算的なcarryとゼロ次ホールドはモデル化上の選択であり、各フェーズには、それを実行した種類のラベルが付きます。

campaign-jam-spoof-holdover-integrity.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

連鎖したミッション:平常、ジャミング、スプーフィング、クロックのホールドオーバーと慣性による惰行を伴う GNSS 喪失、インテグリティ警報、回復を、一つの共有タイムライン上で扱います。

kind = "campaign"
title = "Jamming, spoofing, holdover and integrity: a chained mission"
seed = 20260928
step_s = 10.0
name = "nominal"
duration_s = 600.0
seed = 42
threshold_ns = 50.0

Kshana Studio で開く · GitHub で見る

campaign-monte-carlo-clock-holdover.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

閉形式の解がある事例での、キャンペーンを通したシード付きモンテカルロアンサンブル。

kind = "campaign"
title = "Monte Carlo: free-running clock error against its closed form"
seed = 20260928
runs = 200
seed_key = "seed"
metrics = [
seed = 42
threshold_ns = 20.0

Kshana Studio で開く · GitHub で見る

campaign-shared-jammer-sea-road.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

領域をまたぐ合成:一つのジャマー、二つのプラットフォーム。フィンランド湾の船舶(59.80 N、24.90 E、maritime-strait-jamming の例の受信機)とヘルシンキの海岸道路の車(60.17 N、24.94 E)が、59.80 N、25.44 E、高さ 30 m に置かれた同じ広帯域ジャマーの下にいます(船から約 30 km、車から 50 km)。

kind = "campaign"
title = "One jammer, a ship and a car"
seed = 20260928
name = "jammer_power"
unit = "dBW"
value = 8.0
name = "jammer_position"
unit = "m"

Kshana Studio で開く · GitHub で見る

campaign-spectrum-holdover-integrity.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

L バンドのスペクトルで駆動される連鎖ミッション:チャープジャマーが GPS L1 C/A と Galileo E1 を奪い、クロックがホールドオーバーし、L1 搬送波に残された連続波(CW)トーンが C/A を使えない状態に保つ一方で E1 は回復するため、受信機は Galileo にフォールバックし、そのインテグリティモニターは Galileo のみの空で動作します。

kind = "campaign"
title = "L-band jamming from the spectrum, clock holdover and a Galileo-only fallback"
seed = 20260928
step_s = 1.0
name = "onset"
duration_s = 60.0
end_at = "timeline.bands[0].first_loss_t_s"
end_at_run = 1

Kshana Studio で開く · GitHub で見る

campaign-sweep-jammer-power.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

キャンペーンを通したパラメーター掃引:jamming の例の受信機(52 N、4 E、GPS に似た 24 機の Walker シェル)が、1 km 離れた広帯域ジャマーの下にあり、ジャマーの送信電力を -50 dBW(10 nW)から +10 dBW(10 W)まで 5 dB 刻みで掃引します。各ノードは通常の jamming の実行です。キャンペーンはノードごとに、四機以上の衛星が追尾を続けているエポックの割合、平均のジャマー対信号比(J/S)、追尾している衛星の最少数を記録します。

kind = "campaign"
title = "Jammer power sweep: availability and J/S against transmit power"
seed = 20260928
metrics = [
name = "jammer_power"
key = "jammer.power_dbw"
unit = "dBW"
start = -50.0

Kshana Studio で開く · GitHub で見る

leo-focus-data-services.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

LEO-PNT の重点分野:航法メッセージにおける追加の PNT データサービス。

kind = "campaign"
title = "Navigation-message service data against frame length"
seed = 20260929
name = "fit_interval"
unit = "s"
value = 300.0
label = "ephemeris-clock"
bind = { fit_interval = "message.fit_interval_s" }

Kshana Studio で開く · GitHub で見る

leo-focus-fused-pnt-sisre.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

LEO-PNT の重点分野:MEO + LEO の融合 PNT。

kind = "campaign"
title = "Fused MEO + LEO positioning against the LEO SISRE"
seed = 20260929
metrics = [
name = "leo_sisre"
key = "system.2.sisre_m"
unit = "m"
start = 0.05

Kshana Studio で開く · GitHub で見る

leo-focus-indoor-uhf.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

LEO-PNT の重点分野:UHF による屋内航法。

kind = "campaign"
title = "Indoor LEO-PNT by band and building class"
seed = 20260929
label = "traditional-building"
metrics = [
kind = "leo-pass"
epoch = "2026-09-28T12:00:00"
duration_s = 900.0

Kshana Studio で開く · GitHub で見る

leo-focus-iot-eirp.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

LEO-PNT の重点分野:IoT(モノのインターネット)とモバイル向けの低消費エネルギー測位。

kind = "campaign"
title = "IoT energy per fix against LEO UHF transmit power"
seed = 20260929
metrics = [
name = "uhf_eirp"
key = "satellite.0.band.0.eirp_dbw"
unit = "dBW"
start = -35.0

Kshana Studio で開く · GitHub で見る

leo-focus-ntn-bandwidth.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

LEO-PNT の重点分野:5G/6G 非地上系ネットワーク(NTN)との互換性。

kind = "campaign"
title = "NTN positioning against reference-signal bandwidth"
seed = 20260929
metrics = [
name = "bandwidth"
key = "signal.0.bandwidth_hz"
unit = "Hz"
start = 180000.0

Kshana Studio で開く · GitHub で見る

leo-focus-ppp-altitude.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

LEO-PNT の重点分野:高精度測位(精密単独測位、PPP)。

kind = "campaign"
title = "PPP convergence against the altitude of a 192-satellite LEO layer"
seed = 20260929
metrics = [
name = "leo_altitude"
key = "case.0.system.0.shell.0.altitude_km"
unit = "km"
start = 500.0

Kshana Studio で開く · GitHub で見る

leo-resilience-gnss-jammed-leo-carries.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

LEO-PNT レジリエンスのミッション:GNSS がジャミングされ、LEO-PNT がユーザーを支え、インテグリティが維持される。

kind = "campaign"
title = "GNSS jammed, LEO-PNT carries the user, integrity maintained"
seed = 20260929
step_s = 30.0
name = "nominal"
duration_s = 600.0
series = [
kind = "spectrum"

Kshana Studio で開く · GitHub で見る

leo-resilience-multiband-diversity.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

バンドの多様性による LEO-PNT レジリエンス:一つのジャマーと、四バンドの受信機。

kind = "campaign"
title = "LEO-PNT band diversity against an L-band barrage jammer"
seed = 20260929
metrics = [
name = "jammer_power"
key = "jammers.0.received_power_dbw"
unit = "dBW"
start = -140.0

Kshana Studio で開く · GitHub で見る

leo-resilience-spoof-monitors.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

スプーフィングに対する LEO-PNT のレジリエンス:どのモニターがどのスプーファーを見つけるか。

kind = "campaign"
title = "Spoofing monitors against four spoofers"
seed = 20260929
name = "jump"
unit = "m"
value = 30.0
label = "l-band-only"
bind = { jump = "spoofer.offset_m" }

Kshana Studio で開く · GitHub で見る

leo-vertical-5g-network-timing.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

LEO-PNT の業種:無線ネットワーク、5G/6G 基地局のタイミング。

kind = "campaign"
title = "5G base-station timing: holdover and LEO time"
seed = 20260929
step_s = 300.0
name = "gnss-lost"
duration_s = 86400.0
events = [
kind = "telecom-timing"

Kshana Studio で開く · GitHub で見る

leo-vertical-asset-tracking-iot.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

LEO-PNT の業種:資産追跡と IoT(モノのインターネット)、測位解ごとのエネルギー。

kind = "campaign"
title = "Container tracking with LEO UHF: energy per fix along a journey"
seed = 20260929
step_s = 10.0
name = "port-hamburg"
duration_s = 480.0
series = [
kind = "leo-pass"

Kshana Studio で開く · GitHub で見る

leo-vertical-autonomous-vehicle.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

LEO-PNT の業種:自動運転車、LEO レイヤーを加えた都市の谷間。

kind = "campaign"
title = "Autonomous vehicle in an urban canyon with a LEO layer"
seed = 20260929
step_s = 10.0
name = "open-road"
duration_s = 600.0
series = [
alarms = [{ channel = "position_error_m", compare = "above", threshold = 1.5 }]

Kshana Studio で開く · GitHub で見る

leo-vertical-autonomous-vehicle-skyline.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

LEO-PNT の業種:自動運転車の都市の谷間を、平坦なカットオフと実際の通りとして。

kind = "campaign"
title = "Autonomous vehicle in an urban canyon: a flat cut-off and a city-street skyline"
seed = 20260929
step_s = 10.0
name = "urban-canyon"
duration_s = 900.0
series = [
alarms = [{ channel = "position_error_m", compare = "above", threshold = 1.5 }]

Kshana Studio で開く · GitHub で見る

leo-vertical-critical-infrastructure-timing.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

LEO-PNT の業種:重要インフラのタイミング、LEO 時刻によるホールドオーバー。

kind = "campaign"
title = "Critical infrastructure timing: holdover with LEO time"
seed = 20260929
step_s = 300.0
name = "gnss-locked"
duration_s = 600.0
alarms = []
seed = 42

Kshana Studio で開く · GitHub で見る

leo-vertical-polar-arctic.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

LEO-PNT の業種:極域と北極のユーザー。

kind = "campaign"
title = "Polar and Arctic users with a polar LEO layer"
seed = 20260929
step_s = 60.0
name = "tromso"
duration_s = 3600.0
series = [
alarms = [{ channel = "position_error_m", compare = "above", threshold = 3.0 }]

Kshana Studio で開く · GitHub で見る

leo-vertical-rail-maritime.toml

種別 campaign名前では台帳のモジュールと対応づけられていません

LEO-PNT の業種:鉄道と海上、同梱の海上・鉄道シナリオに LEO を加えたもの。

kind = "campaign"
title = "Railway and maritime with a LEO layer"
seed = 20260929
step_s = 10.0
name = "strait-jammed"
duration_s = 1800.0
kind = "jamming"
seed = 1

Kshana Studio で開く · GitHub で見る

cislunar-arc-recovery#

地球・月間空間(シスルナー)の弧長可観測性しきい値に対する、MODELLEDの独立推定器テスト。そのしきい値は、解析的なレンジのヤコビアン行と解析的な変分状態遷移行列から組み立てた可観測性行列に対するランクの読み取りであり、その平方根情報フィルターによるクロスチェックも同じ行を畳み込むため、二つの数値計算機構の間の整合性チェックであって、裏付けではありません。この種類は欠けている裁定役を提供します。シミュレートした測定からチーフの初期状態を実際に回復するバッチ最小二乗推定器で、測定の偏導関数は、合成した順方向モデルの中心有限差分として求めます。解析的なヤコビアン行、変分STM、特異値分解や固有値分解、ランクの許容差、平方根情報フィルターは一切呼び出しません。tests/cislunar_arc_recovery_reference.rsのソーステキストガードによってこれが強制されます。一方、力学(同じRK4のCR3BPフロー)、初期条件(同じ微分補正済みコンステレーション)、スカラー観測量、エポックグリッドは意図的に共有され、出力されるindependenceブロックに明記されます。一つの物理問題に対する二つの解析は、比較できるようにするため、その物理について一致していなければならないからです。二つの基準があり、それぞれが固有の境界に対して五桁にわたってスイープされます。ノイズなし回復(シード付きの各試行の最終状態誤差が、事前の変位のrecovery_factor倍以下。特異値の許容差を含まない、ランクの類似物)と、モンテカルロの推定可能性(シード付きのノイズアンサンブルでのMEASUREDRMS位置誤差が、示された境界を下回ること。予測ではなくMEASUREDした、推定可能性の類似物)です。平面の四状態と空間の六状態、DRO/L2ハロー/L2 NRHOのファミリー、レンジとレンジレートの観測量、および月中心の極座標によるパラメーター化(変換を状態に適用し、順方向モデルをそこで再微分)に対応します。公開された平面DROグリッドでの実測:推定器は四状態を0.782609 hから回復するのに対し、ランク基準はrel_tol 1e-6で2.086957 hです(比0.375)。ランクのしきい値は、回復可能性の境界としては裏付けられていません。一方、実測した推定可能性の境界は、形式的な境界5.739130 hと同じグリッドセルに入り、実測した誤差曲線は、21個の弧長にわたって形式的な1シグマを、幾何平均比0.98で再現します。MODELLED:コンステレーションの設計、エポックグリッド、追尾する単一のリンク、変位の大きさ、測定のシグマ、示された二つの境界。認証を受けた航法性能製品ではありません。

cislunar-arc-recovery.toml

種別 cislunar-arc-recovery名前では台帳のモジュールと対応づけられていません

地球・月間空間の弧長可観測性しきい値の独立推定器による試験(R6、論文 B)。

kind = "cislunar-arc-recovery"

Kshana Studio で開く · GitHub で見る

cislunar-observability#

MODELLEDの、平面の地球・月間空間(シスルナー)コンステレーションの可観測性(P6):衛星間レンジングを用いて、微分補正した四機の平面DROコンステレーションを追尾し、弧によって宇宙機の四状態[x,y,ẋ,ẏ]のどこまでが可観測になるかを報告します。出力は、(1)単一のレンジのみのリンクについてのランクと弧長の表(瞬時にはランク1で、弧が延びるにつれて四状態の全体に向かって増加:P6 Table 1)、(2)弧にわたる可観測性グラミアンの固有スペクトルと条件数、(3)レンジのみとレンジ+レンジレートの瞬時ランクの比較(ドップラーという設計上の手段)と、レンジのみでは特異、レンジ+レートでは定義されるGDOPの報告、(4)可観測ランクが四に達する弧のところで、事後共分散が有限かつ良条件になる、独立したSRIFのクロスバリデーションです。VALIDATEDの中核:可観測ランクは、グラミアンの固有ランクとクロスチェックされた、ランクを明らかにする特異値しきい値です。固有スペクトルはスペクトル不変量(trace=Σλ、det=Πλ、Frobenius²=Σλ²)に従います。変分STMは、有限差分で照合済みのCR3BP STMです。レンジ/レンジレートのヤコビアン行は、有限差分で照合済みの解析的な偏導関数です(クレートの3-Dレンジレート観測量とクロスチェック)。四つの初期条件は、微分補正した平面DROで、厳密な周期性残差まで閉じ、逆行です。ランクの遷移は、クレートの平方根情報フィルターとクロスバリデーションされています(完全ランクのところで事後共分散が有限、cond(P)=cond(OᵀO))。ランク不足のスナップショットはGDOP未定義(fim condition=inf)と表示され、でたらめな有限値になることはありません。これはpvt::solve_sppが適用する、特異な幾何に対するガードと同じです。MODELLED:コンステレーションの設計(DROのペリルーン振幅と位相)と、それが生む具体的なランクの推移。認証を受けた航法性能製品ではありません。

cislunar-observability.toml

種別 cislunar-observability名前では台帳のモジュールと対応づけられていません

追跡弧にわたる平面的な地球・月間空間コンステレーションの可観測性(P6)。

kind = "cislunar-observability"

Kshana Studio で開く · GitHub で見る

clock#

時計のホールドオーバーと仕様の比較。任意のモンテカルロのアンサンブル(runs > 1)。

clock-ensemble.toml

種別 clock名前では台帳のモジュールと対応づけられていません

時計ホールドオーバーシナリオのモンテカルロアンサンブル。

seed = 42
threshold_ns = 20.0
runs = 200
step_s = 10.0
duration_s = 7200.0
windows = [
id = "optical-sr-lattice"
provenance = "Strontium optical lattice clock, space-oriented goal sigma_y(1s)=1e-15 (Origlia/Schiller/Bongs et al., arXiv:1503.08457); q_wf=sigma_y(1s)^2; ground-demonstrator maturity, not flown; flicker floor modeled at sigma_y=1e-16"

Kshana Studio で開く · GitHub で見る

clock-fitted-log.toml

種別 clock名前では台帳のモジュールと対応づけられていません

古典クロックが、実測ログの雑音を取り込むクロックシナリオ([clock_fit])。

seed = 42
threshold_ns = 20.0
step_s = 10.0
duration_s = 7200.0
windows = [
id = "optical-sr-lattice"
provenance = "Strontium optical lattice clock, space-oriented goal sigma_y(1s)=1e-15 (Origlia/Schiller/Bongs et al., arXiv:1503.08457); q_wf=sigma_y(1s)^2; ground-demonstrator maturity, not flown; flicker/aging not modeled"
q_wf = 1.0e-30

まだ GitHub にはありません

clock-holdover.toml

種別 clock名前では台帳のモジュールと対応づけられていません

Kshana の基準シナリオ:2 h の実行で、10 min の GNSS 同期の後、約 1.8 h 妨害される。クロックの白色 FM ノイズは、公表されている sigma_y(1 s) で較正:q_wf = sigma_y(1s)^2。tests/calibration.rs でシミュレートしたアラン偏差に対して確認済み(約 2%)。

seed = 42
threshold_ns = 20.0
step_s = 10.0
duration_s = 7200.0
windows = [
id = "optical-sr-lattice"
provenance = "Strontium optical lattice clock, space-oriented goal sigma_y(1s)=1e-15 (Origlia/Schiller/Bongs et al., arXiv:1503.08457); q_wf=sigma_y(1s)^2; ground-demonstrator maturity, not flown; flicker/aging not modeled"
q_wf = 1.0e-30

Kshana Studio で開く · GitHub で見る

clock-holdover-labsr.toml

種別 clock名前では台帳のモジュールと対応づけられていません

バリアント:実験室級のストロンチウム光時計と CSAC の比較。実験室の Sr 時計は sigma_y(1 s) = 4.8e-17 に達します(Oelker ら、2019、Nature Photonics)。

seed = 42
threshold_ns = 20.0
step_s = 10.0
duration_s = 7200.0
windows = [
id = "optical-lab-sr"
provenance = "Laboratory Sr optical lattice clock, sigma_y(1s)=4.8e-17 (Oelker et al. 2019, Nature Photonics); q_wf=sigma_y(1s)^2; laboratory maturity, not flown; flicker/aging not modeled"
q_wf = 2.304e-33

Kshana Studio で開く · GitHub で見る

clock-measured-log.toml

種別 clock名前では台帳のモジュールと対応づけられていません

シミュレーションしたホールドオーバーと並べて、実測ログを持つクロックシナリオ([clock_log])。

seed = 42
threshold_ns = 20.0
step_s = 10.0
duration_s = 7200.0
windows = [
id = "optical-sr-lattice"
provenance = "Strontium optical lattice clock, space-oriented goal sigma_y(1s)=1e-15 (Origlia/Schiller/Bongs et al., arXiv:1503.08457); q_wf=sigma_y(1s)^2; ground-demonstrator maturity, not flown; flicker/aging not modeled"
q_wf = 1.0e-30

まだ GitHub にはありません

combined-altpnt#

GPSが使えない状況での、重力・磁気・地形を組み合わせた航法装置:三つのスカラー場チャンネルをウェイポイントごとに融合し、どの単一の場よりも鋭い(CRLBの低い)ドリフト補正を得ます。

combined-altpnt.toml

種別 combined-altpnt名前では台帳のモジュールと対応づけられていません

重力 + 磁気 + 地形を組み合わせた GPS 拒否環境の航法装置:融合型の代替 PNT。

kind = "combined-altpnt"
start_lat_deg = 12.05
start_lon_deg = 20.05
step_lat_deg = 0.004
step_lon_deg = 0.003
waypoints = 60
drift_lat_deg = 0.5
drift_lon_deg = -0.4

Kshana Studio で開く · GitHub で見る

conflict-resilience#

MODELLEDの、階層型PNTの紛争下レジリエンス(P7):係争環境のユーザーが複数のPNTレイヤー(オープンサービスのGNSS、広帯域GNSS、認証付きコンステレーション、補強中継機)を使い、各レイヤーには基本の可用性、1σ の精度、および共有されるジャミング/スプーフィングの脅威に対するベクトルごとの拒否脆弱性があります。強度をスイープするシード付きのモンテカルロが、各レイヤーを確率clamp(vulnerability·intensity·vector_weight,0,1)で拒否し、生き残ったものを閉形式の逆分散則 σ_fused=(Σ 1/σ_i²)^(−1/2)で融合し、全損失確率(すべてのレイヤーが拒否される確率)、融合誤差の中央値、強度に対するレイヤーごとの利用可能/拒否の統計を報告します。代表的なレジリエンス比(単一レイヤーと階層型の全損失確率の比)は、独立性の仮定のもとで~7x程度になります。次に、一因子ガウス・コピュラによる相関拒否のスイープを行うと、拒否の相関が高まるにつれてその~7xが1に向かって崩れることが示されます(相関は階層化を無力にします)。事前分布の感度ブロックは、mcdaのトルネード図、ディリクレ分布による脅威労力の再配分、パーセンタイル信頼区間によって、出典付きの脆弱性の事前分布にわたって代表値の範囲を求めます。VALIDATEDの中核:モンテカルロの全損失は、閉形式の独立積 Π_i p_deny_iに収束します(固定シードかつ大きなNでの、モンテカルロの標準誤差の範囲内)。逆分散融合は閉形式の恒等式です。ρ=0ではコピュラは独立モデルに帰着し、どの ρ でも各レイヤーの周辺拒否率が保たれます。MODELLED:レイヤーごとの脆弱性/可用性/精度の大きさは、出典はあるがモデルから計算した入力であり(JammerTest 2024、TEXBAT、EASA SIB、RTCA DO-229、LunaNet/IOAG — conflict_threat_paramsを参照)、具体的な~7xという大きさと、比と相関の曲線の形は、このパラメーター設定から導かれます。続く §4.2のベクトルごとの生存の内訳は、共有されるRFの脅威を、名前付きの四つのベクトル(ジャミング/スプーフィング/運動エネルギー/サイバー)に分解し、各ベクトルについて、利用可能なPNTの段階的劣化曲線S_v(x)=1-Prod_i(1-a_i(1-clamp(susceptibility_i,v·x,0,1)))を報告します。VALIDATED:シード付きのレイヤーごとのモンテカルロはその閉形式に収束します。相関のあるRFベースラインでは、ジャミングが最も鋭いベクトルであり、RFの影響を受けない慣性レイヤーが決定的な生き残りです。認証を受けた航法可用性の製品ではありません。

conflict-resilience.toml

種別 conflict-resilience名前では台帳のモジュールと対応づけられていません

レイヤード PNT の紛争下レジリエンス(論文 P7)。

kind = "conflict-resilience"
trials = 4000
seed = 20260709
primary_layer = 0
min = 0.0
max = 1.0
steps = 11
values = [0.0, 0.2, 0.4, 0.6, 0.8, 0.95]

Kshana Studio で開く · GitHub で見る

constellation-design#

大規模なコンステレーション設計:i: T/P/F 表記の Walker DELTA と Walker STAR のパターン(ノードを 360 または 180 deg に分散、面内間隔 360*P/T、面間位相オフセット 360*F/T)、明示的な要素リスト、複数シェルの設計、一回の実行で複数のコンステレーション。地球、月、火星、その他の惑星、冥王星、または主要な衛星を周回し、body モジュールの定数(solar-system と body-pnt の各種別が使うものと同じ)を用います。公表されている公称要素に基づくプリセット:gps-baseline と gps-expandable(GPS Standard Positioning Service Performance Standard 第 5 版(2020)の表 3.2-1 から 3.2-3 にある 24 スロットと、前後の拡張ペア六組)、galileo(29,599.801 km、56 deg の Walker 24/3/1、Galileo Open Service Service Definition Document 第 1.1 版の表 1 と 23)、beidou と beidou-meo(21,528 km、55 deg の Walker 24/3/1 に、東経 80、110.5、140 deg の静止衛星三機と、55 deg の傾斜静止軌道衛星三機を加えたもの。BeiDou Open Service Performance Standard 3.0 の 4.1 節。MEO の位相と東経 118 deg の傾斜静止軌道の交差は、規格が述べていないためモデルから計算しています)、glonass(GLONASS Interface Control Document 第 5.1 版 5.2 節のスロット式による、19,100 km、64.8 deg の 24/3/1)。カバレッジと精度低下率:緯度経度のグリッドと仰角マスク付きのサンプリング窓にわたり、セルごとの可視衛星数、GDOP、PDOP、HDOP、VDOP、セルごとの可用性(PDOP がしきい値以下のフィックス。既定は 6)、全球(面積加重)と最悪地点での可用性を、clock = "common" でない限りコンステレーションごとに一つの受信機クロックで算出します。数千機の衛星まで拡張でき、可視性は各衛星のカバレッジ半角に対する内積で判定し、衛星は各エポックで衛星直下点の緯度ごとに帯状に分けるため、グリッドの行は可視になり得るものだけを検査します。レポートは省略できたペア検査の数を数えます。JSON にはグリッドマップと、間引いた衛星ごとの地上軌跡が含まれます。VALIDATED:Walker ジェネレーターは Galileo OS SDD の表 23 と GLONASS ICD のスロット式に対して、GPS プリセットは SPS PS の表 3.2-1 で公表されている赤道通過の列に対して、GPS ベースラインの全球 HDOP 分布は SPS PS の付録 B(中央値 0.94、95% が 1.25、平均 0.96、許容差 0.03)に対して照合されています。MODELLED:オプションの永年 J2 を含む二体軌道、球形の天体、幾何的な可視性のみ(信号電力、健全性、地形は含まない)、そして異なるシステム間の相対位相(これはいかなる実在の日付のスナップショットでもありません)。

constellation-multi-gnss-coverage.toml

種別 constellation-design名前では台帳のモジュールと対応づけられていません

複数コンステレーションのカバレッジ:四つの全球測位衛星システム(GNSS)を合わせて、一日分の、地球全体にわたる可視衛星数、精度低下率(DOP)、可用性のマップとして示します。

kind = "constellation-design"
body = "earth"
duration_s = 86164.0
step_s = 900.0
mask_deg = 10.0
pdop_threshold = 6.0
grid_step_deg = 10.0
clock = "per-constellation"

Kshana Studio で開く · GitHub で見る

leo-pnt-mega-shell.toml

種別 constellation-design名前では台帳のモジュールと対応づけられていません

低軌道の測位・航法・時刻(PNT)メガコンステレーション:四つの Walker シェルにある 5,000 機の衛星を、カバレッジと精度低下率(DOP)のマップとして採点します。

kind = "constellation-design"
body = "earth"
duration_s = 7200.0
step_s = 600.0
mask_deg = 20.0
pdop_threshold = 3.0
grid_step_deg = 10.0
clock = "common"

Kshana Studio で開く · GitHub で見る

lunar-relay-constellation.toml

種別 constellation-design名前では台帳のモジュールと対応づけられていません

月の中継・航法コンステレーション:楕円月周回凍結軌道(ELFO)の衛星と円形の低高度月周回軌道のシェルを、一日分の、月全体にわたるカバレッジと精度低下率(DOP)のマップとして採点します。

kind = "constellation-design"
body = "moon"
duration_s = 86400.0
step_s = 1800.0
mask_deg = 10.0
pdop_threshold = 6.0
grid_step_deg = 10.0
clock = "common"

Kshana Studio で開く · GitHub で見る

contact-schedule#

複数の衛星と複数の地上局に対する地上コンタクトの計画:見かけのアクセスウィンドウ(SGP4、IAU 2006/2000A地球固定座標系、ITU-R P.834屈折、光行時間)、各パスのDVB-S2 ACMデータ量(ETSI EN 302 307-1 Table 13のしきい値)、および競合のないスケジュール(折り返し時間を伴うアンテナごとに一つの衛星、衛星ごとに一つの地上局、各バックログを上限とする優先度加重の配信)。これを、限界価値の貪欲法、先着順のベースライン、小規模な集合に対する厳密な分枝限定法で求め、貪欲法の最適性ギャップも示します。MODELLED。

contact-schedule.toml

種別 contact-schedule名前では台帳のモジュールと対応づけられていません

地上コンタクトの計画:例示用の三機の衛星と、例示用の三つの局を、12 時間にわたって扱います。この実行は、各衛星と局のパスについて、アクセス窓と、DVB-S2 適応符号化変調(ACM)がその間に運べるデータ量(ETSI EN 302 307-1 の表 13 のしきい値に実装マージンを加えたもの)を与えます。次に、各アンテナが一度に一機の衛星にのみ対応し、コンタクト間に切り替え時間を置き、各衛星が一度に一つの局にのみダウンリンクする、競合のないコンタクト計画を構築します。配信は優先度で重み付けされ、各衛星のバックログで上限が設けられます。三つの計画が並べて報告されます:限界価値の貪欲法、先着順のベースライン、および候補集合が小さい場合の厳密な最適解で、貪欲法の最適性ギャップも示されます。

kind = "contact-schedule"
epoch = [2024.0, 1.0, 1.0, 0.0, 0.0, 0.0]
duration_hours = 12.0
step_s = 30.0
refraction = true
light_time = true
frequency_ghz = 8.2
eirp_dbw = 7.0

Kshana Studio で開く · GitHub で見る

earth-gnss-lunar#

月までの距離での地球GNSSの受信:コンフリクトレジリエンス論文が挙げているものの、エンジンにはモデルがなかった微弱信号レイヤーです。GNSS衛星はアンテナを地球に向けており、月の近くにいる受信機は軌道半径の約十五倍の距離にいるため、三つのことが同時に効いてきます。地球がボアサイトを遮ります:26,560 kmからは地球が13.9 degの半角で見えるため、月に向かう光線はどれも、少なくともそれだけ天底からずれて送信機を離れる必要があり、電力を計算する前にビームのピークが取り除かれます。残るのはメインローブの縁とサイドローブであり、LuGREペイロードが2025年に実際に動作したのはこの領域です。さらに、自由空間損失はL1で約208 dBであり、地上のユーザーが払うより約25 dB大きくなります。レポートは衛星ごとに一行(天底からの角度、地球による掩蔽、距離、経路損失、その角度での送信ゲイン、受信電力、搬送波対雑音密度)を出力し、追尾しきい値を超えるリンクだけを集計します。条件数(コンディショニング)も報告します。それがこのレイヤーを特徴づけるからです。見えている衛星はすべて、月から見て数度幅の円錐の内側にあるため、視線はほぼ平行で、DOP(精度低下率)は極めて大きく、月までの距離での地球GNSSによる測位解は、位置の観測というよりタイミング級の観測です。MODELLEDであり、その理由は送信パターンです:角度に対するゲインは一様な円形開口(エアリー)ですが、実際のGPS L1アンテナは、成形されたメインローブと非エアリーのサイドローブを持つ十二素子のヘリカルアレイです。実測のパターンは存在しますが、ここには同梱されていないため、順序や桁は意味を持つものの、個々の衛星のdBは意味を持ちません。意図的に含まれていないもの(いずれも、バジェットを楽観的にします):地球の縁をかすめる光線に対する電離圏や対流圏の損失はなく、偏波、指向、実装の損失もなく、屈折による拡張のない球形の地球です。月の位置はエフェメリスの参照ではなく入力(距離と慣性方向)です。試験の対象はリンクとビームの幾何だからです。この行を、独立した外部の参照と照合して確認済みに格上げするには、実測の送信パターンとLuGREの標準点が必要ですが、どちらもリポジトリにはなく、ここで作り出してもいません。

earth-gnss-lunar.toml

種別 earth-gnss-lunar種別の台帳の行はモデルから計算されたものです · 1 行中 0 行が外部参照で確認済み

月までの距離での地球 GNSS の受信。

kind = "earth-gnss-lunar"
altitude_km = 20180.0
inclination_deg = 55.0
planes = 6
sats_per_plane = 4
phasing_f = 2.0
epoch_s = 0.0
receiver_range_m = 384400000.0

Kshana Studio で開く · GitHub で見る

entry-heating#

自転する球形の地球または火星上での3-DoF 質点による大気圏突入(弾道型、または一定バンクの揚力型)を、US76、指数関数型、または火星の大気を通して RK4 で計算し、Sutton-Graves 式による淀み点対流加熱(NASA TR R-376)を適用します:ピーク減速度、熱流束と動圧、熱負荷、ダウンレンジ、回転座標系でのエネルギー検査、そして並べて示す Allen-Eggers の閉形式。ピーク減速度は公表されている Stardust の公称値と照合しており、加熱は MODELLED です。

entry-heating-stardust.toml

種別 entry-heating名前では台帳のモジュールと対応づけられていません

Stardust サンプルリターンカプセルの突入:entry-heating 種別を照合する公表済みのケース(xval/entry-stardust/PREREGISTRATION.md、tests/entry_stardust_published.rs)。

kind = "entry-heating"
body = "earth"
atmosphere = "us76"
entry_interface_altitude_m = 125003.0
velocity_frame = "inertial"
entry_speed_m_s = 12900.0
flight_path_angle_deg = 8.2
latitude_deg = 41.0

Kshana Studio で開く · GitHub で見る

eo-coverage#

地球観測ペイロードのフットプリントとカバレッジ幾何(SMAD の宇宙三角形):軌道高度、傾斜角(既定では太陽同期)、センサーの FOV/IFOV から、地球角半径、観測幅、天底の地上サンプル距離、最大オフナディアアクセス、円軌道周期、J2 の昇交点周期、赤道上の地上軌跡間隔、および連続カバレッジのフラグを求めます。MODELLED の球形地球幾何(放射測定・MTF・大気・ジッター・太陽反射なし);ノード間隔は R_e·(ω − Ω̇)·T_nodal で、J2 の一次永年変化率を用います。

eo-coverage.toml

種別 eo-coverage名前では台帳のモジュールと対応づけられていません

地球観測ペイロードのフットプリントとカバレッジのデモンストレーター(SMAD 宇宙トライアングル)。

kind = "eo-coverage"
altitude_km = 700.0
half_fov_deg = 7.5
ifov_microrad = 14.0
max_off_nadir_deg = 45.0

Kshana Studio で開く · GitHub で見る

eo-radiometry#

天底撮像装置の放射測定と画質:ランベルト面シーンの開口面放射輝度、カメラ方程式、信号とショット/暗電流/読み出し/量子化雑音、および SNR;系全体の MTF(ナイキスト周波数、回折 x 検出器 x スミア x ジッター)、そこから求める相対エッジ応答、Q = lambda F/p、そして MTF 補償なしの GIQE バージョン4による NIIRS。MODELLED です。

eo-radiometry.toml

種別 eo-radiometry名前では台帳のモジュールと対応づけられていません

ILLUSTRATIVEの小型地球観測カメラ(特定の事業者の設計ではありません)の天底撮像の放射測定と画質:開口 0.40 m、焦点距離 3.6 m(F/9)、5.5 um の画素、高度 500 km から。この実行は、反射率 15 % の場面の信号対雑音比の収支、ナイキスト周波数でのシステム MTF、相対エッジ応答、GIQE バージョン 4 の NIIRS を与えます。MODELLED:NIIRS は、モデル化された入力で評価した経験的回帰であり、格付けされた画像ではありません。

kind = "eo-radiometry"
altitude_m = 500000.0
focal_length_m = 3.6
aperture_m = 0.40
pixel_pitch_um = 5.5
wavelength_um = 0.65
bandwidth_um = 0.2
fill_factor = 1.0

Kshana Studio で開く · GitHub で見る

ephemeris#

エフェメリスと地上軌跡:一機の衛星を伝搬し(TLE→SGP4 または解析的軌道)、その TEME/GCRS 状態(位置+速度)、ITRF/ECEF 位置、WGS-84 の衛星直下点の緯度・経度・高度、そしてステップごとの局の方位角/仰角/距離と距離変化率(ドップラー)を出力します。衛星はtle、またはepochを伴う解析的なorbitで与えます(両方が指定された場合はtleが優先されます);tleを使う場合、epochは TLE 自身のエポックを t = 0 として上書きします。

ephemeris.toml

種別 ephemeris名前では台帳のモジュールと対応づけられていません

エフェメリスと地上軌跡 — 「衛星は今どこにいるか」。

kind = "ephemeris"
tle = """
step_s = 30.0
duration_s = 16740.0
xp_arcsec = 0.0
yp_arcsec = 0.0
lat_deg = 49.8707
lon_deg = 8.6217

Kshana Studio で開く · GitHub で見る

fusion#

同じハイブリッド入力に対する、カルマンフィルターによる統合センサーフュージョン PNT。

fusion-pnt.toml

種別 fusion名前では台帳のモジュールと対応づけられていません

統合センサーフュージョンの PNT:独立した予測器を組み合わせるのではなく、単一のカルマンフィルターがナビゲーターとなり、クロックと慣性の状態を融合し、光 ISL の時刻比較で支援されます。GNSS は 1.8 h 妨害されます。

kind = "fusion"
seed = 42
timing_spec_ns = 20.0
position_spec_m = 100.0
step_s = 10.0
duration_s = 7200.0
windows = [
enabled = true

Kshana Studio で開く · GitHub で見る

fusion-pnt-coupled.toml

種別 fusion名前では台帳のモジュールと対応づけられていません

結合型の統合センサーフュージョン PNT:fusion-pnt.toml と同じスイートと GNSS 途絶ですが、ナビゲーターは位置、速度、クロック位相、クロック周波数、加速度計バイアスにわたる単一の積み重ねたカルマンフィルターです([coupled] テーブル)。GNSS が正常な間は、視線方向の係数 g に沿った rho = g * position + c * clock phase + noise の疑似距離を取り込むため、一つの測定が位置とクロックを一緒に拘束し、フィルターはそれらの相互共分散を保持します。途絶中の光時刻比較による再同期は、クロックのみの疑似距離です。ここでの加速度計には一定のバイアスがあり、バイアス状態が途絶の前にそれを学習します(fusion-pnt.toml はフィルターにバイアス状態がないためバイアスをゼロにしています)。ベンダー中立で、クロックとノイズのパラメーターは fusion-pnt.toml と同じで、バイアスは例示用です。MODELLED。

kind = "fusion"
seed = 42
timing_spec_ns = 20.0
position_spec_m = 100.0
step_s = 10.0
duration_s = 7200.0
windows = [
enabled = true

Kshana Studio で開く · GitHub で見る

gnss-ins#

疎結合および密結合の GNSS/INS 誤差状態 EKF。

automotive-urban-canyon.toml

種別 gnss-ins名前では台帳のモジュールと対応づけられていません

都市の谷間を通る道路車両:アンダーパスと路側のジャマーをまたぐ GNSS/INS 推測航法を、レーンレベルの予算に照らして評価します。

kind = "gnss-ins"
seed = 7
threshold_m = 1.5
fix_interval_s = 1.0
sigma_pos_m = 1.0
sigma_vel_mps = 0.05
lat_deg = 48.137
lon_deg = 11.575

Kshana Studio で開く · GitHub で見る

gnss-ins.toml

種別 gnss-ins名前では台帳のモジュールと対応づけられていません

疎結合の GNSS/INS:三軸のストラップダウンナビゲーターを 15 状態の誤差状態 EKF で制御し、60 s の GNSS 途絶を惰行します。inertial パック(フィックスごとに真値へ戻すリセットを行う、1-DOF のスカラー推測航法)とは異なり、これは本物の閉ループフィルターを実行します。GNSS が使える間は雑音の多いフィックスから学習し、途絶の間は補正された状態で惰行します。報告される誤差は真値に対する実際の水平残差で、各センサーは開ループの自由 INS の RMS も併せて持つため、フィルターの価値が明確になります。

kind = "gnss-ins"
seed = 7
threshold_m = 50.0
fix_interval_s = 1.0
sigma_pos_m = 1.0
sigma_vel_mps = 0.05
lat_deg = 45.0
lon_deg = -57.3

Kshana Studio で開く · GitHub で見る

gnss-ins-aviation.toml

種別 gnss-ins名前では台帳のモジュールと対応づけられていません

密結合の航空 GNSS/INS:軽飛行機が離陸し、6 deg で上昇し、水平飛行に移り、25 deg のバンクの協調旋回を行います(軌道プロファイル aircraft)。GNSS は旋回を含む二分間途絶します。方位と姿勢の誤差が水平方向に投影されるため、旋回は惰行で最も厳しい部分です。GPS に似た SGP4 Walker コンステレーション上で密結合([tight])です。

kind = "gnss-ins"
seed = 13
threshold_m = 100.0
fix_interval_s = 1.0
sigma_pos_m = 3.0
sigma_vel_mps = 0.1
lat_deg = 52.0
lon_deg = 5.0

Kshana Studio で開く · GitHub で見る

gnss-ins-maritime.toml

種別 gnss-ins名前では台帳のモジュールと対応づけられていません

海事の GNSS/INS:8 m/s(約 15.5 ノット)の船舶が、1 deg/s で円を描いて蛇行し、その後五分間の GNSS 途絶に入ります。gnss-ins.toml と同じ閉ループの 15 状態 GNSS/INS フィルターを用います。運動は軌道ライブラリ([trajectory]、プロファイル figure8)に由来し、車ではなく船舶の領域である、ゆっくりとした安定した旋回です。

kind = "gnss-ins"
seed = 11
threshold_m = 50.0
fix_interval_s = 1.0
sigma_pos_m = 2.0
sigma_vel_mps = 0.1
lat_deg = 54.0
lon_deg = 10.0

Kshana Studio で開く · GitHub で見る

gnss-ins-rail.toml

種別 gnss-ins名前では台帳のモジュールと対応づけられていません

密結合の鉄道 GNSS/INS:列車が 30 m/s で停車駅の間を走り、20 deg のゆるやかなカーブ(軌道プロファイル stop_go)を通り、視界に衛星が二機しか残らない深い切通しを通過し、その後二分間のトンネルに入ります。受信機は密結合([tight])で、切通しでも追尾している二機の衛星の疑似距離を融合し続けます。疎結合の受信機ではフィックスがまったく得られない場面です。衛星は GPS に似た SGP4 Walker コンステレーションから得ます。

kind = "gnss-ins"
seed = 12
threshold_m = 30.0
fix_interval_s = 1.0
sigma_pos_m = 2.0
sigma_vel_mps = 0.1
lat_deg = 48.0
lon_deg = 11.0

Kshana Studio で開く · GitHub で見る

small-uas-jammed-nav.toml

種別 gnss-ins名前では台帳のモジュールと対応づけられていません

GNSS ジャミング下の小型無人航空機:フライトコントローラー級の MEMS 慣性ユニットが、受信機がロックを失った後にどれだけドリフトするかを、戦術級のユニットと比較します。gnss-ins.toml と同じ閉ループ GNSS/INS フィルターを用います。

kind = "gnss-ins"
seed = 7
threshold_m = 50.0
fix_interval_s = 1.0
sigma_pos_m = 1.0
sigma_vel_mps = 0.05
lat_deg = 59.437
lon_deg = 24.745

Kshana Studio で開く · GitHub で見る

gnss-sim#

測定領域での疑似距離シミュレーション(Klobuchar 電離圏、Saastamoinen/Niell 対流圏)+ RAIM。

gnss-sim-container-terminal-skyline.toml

種別 gnss-sim名前では台帳のモジュールと対応づけられていません

コンテナ岸壁のストラドルキャリアの疑似距離と RAIM。海側に岸壁クレーン、陸側にコンテナの山があります。container-terminal のスカイラインプリセットを用いた gnss-sim シナリオです。

kind = "gnss-sim"
seed = 7
mask_deg = 5.0
noise_sigma_m = 1.5
multipath_m = 0.5
sat_clock_rms_m = 30.0
uere_m = 3.0
p_fa = 1.0e-5

Kshana Studio で開く · GitHub で見る

gnss-sim-raim.toml

種別 gnss-sim名前では台帳のモジュールと対応づけられていません

測定領域での GNSS シミュレーション:電離圏遅延と対流圏遅延を含む疑似距離を、保護レベルのためにスナップショット RAIM へ入力します。

kind = "gnss-sim"
seed = 7
mask_deg = 5.0
noise_sigma_m = 1.5
multipath_m = 0.5
sat_clock_rms_m = 30.0
uere_m = 3.0
p_fa = 1.0e-5

Kshana Studio で開く · GitHub で見る

gnss-ssv#

MODELLED の、宇宙サービスボリュームおよびその先での GNSS 可用性とリンク強度:球面上(ICG 小冊子のグローバルシェル)またはケプラー軌道上(LEO から月遷移軌道まで)のユーザーについて、衛星コンステレーションごと(GPS、GLONASS、Galileo、BDS、QZSS、NavIC)および全体で、C/N0 しきい値を超えて使える信号を数えます - 信号一つ以上および四つ以上の可用性、最大途絶時間、受信 C/N0、精度低下率、メインローブ対サイドローブのリンク - 小冊子、パラメトリック、またはユーザー提供の送信パターン、任意のリム経路電離圏・プラズマ圏・大気の効果、任意の微弱信号受信機設計を伴います;さらに HEO および月遷移機向けの搭載 GNSS 拡張カルマンフィルター(軌道力学、太陽放射圧、第三体、時計)と、単一差分疑似距離による複数機編隊の相対航法も含みます。事前登録のもとで ICG SSV 小冊子の表と照合(xval/gnss-ssv)

gnss-ssv-formation-heo.toml

種別 gnss-ssv名前では台帳のモジュールと対応づけられていません

冊子の高楕円軌道における、三機編隊の相対航法。

kind = "gnss-ssv"
name = "HEO formation relative navigation (reduced length)"
include = ["gps", "glonass", "galileo", "bds"]
bands = ["l1", "l5"]
preset = "heo"
duration_min = 400.0
step_s = 60.0
antennas = ["booklet-high-gain-nadir", "booklet-patch-zenith"]

Kshana Studio で開く · GitHub で見る

gnss-ssv-heo.toml

種別 gnss-ssv名前では台帳のモジュールと対応づけられていません

GNSS 軌道を貫く高楕円軌道:近地点から遠地点までにユーザーが見るもの。

kind = "gnss-ssv"
name = "HEO, high-gain nadir and patch zenith antennas, parametric sidelobes, limb medium"
include = ["gps", "glonass", "galileo", "bds"]
bands = ["l1", "l5"]
pattern = "parametric"
preset = "heo"
duration_periods = 1.0
step_min = 10.0

Kshana Studio で開く · GitHub で見る

gnss-ssv-lunar-weak.toml

種別 gnss-ssv名前では台帳のモジュールと対応づけられていません

月遷移軌道上の GNSS と、感度を稼ぎ出す微弱信号受信機。

kind = "gnss-ssv"
name = "Lunar transfer, weak-signal receiver, parametric sidelobes"
include = ["gps", "galileo", "glonass", "bds"]
bands = ["l1", "l5"]
pattern = "parametric"
apply = "acquisition"
t_coh_s = 0.1
n_noncoherent = 100.0

Kshana Studio で開く · GitHub で見る

gnss-ssv-nav-lunar.toml

種別 gnss-ssv名前では台帳のモジュールと対応づけられていません

月へ向かう途中の搭載 GNSS 航法:疑似距離のみに対する拡張カルマンフィルター。

kind = "gnss-ssv"
name = "Lunar transfer, onboard GNSS EKF (reduced length)"
include = ["gps", "glonass", "galileo", "bds"]
bands = ["l1", "l5"]
preset = "lunar-transfer"
duration_min = 1440.0
step_s = 300.0
antennas = ["booklet-high-gain-nadir", "booklet-patch-zenith"]

Kshana Studio で開く · GitHub で見る

gnss-ssv-shell.toml

種別 gnss-ssv名前では台帳のモジュールと対応づけられていません

上位 SSV シェルでの GNSS 信号の可用性:冊子の全球指標を、一秒で実行できる規模で。

kind = "gnss-ssv"
name = "Upper SSV shell, 20 dB-Hz (reduced size)"
include = ["gps", "glonass", "galileo", "bds"]
bands = ["l1", "l5"]
altitude_km = 36000.0
antenna = "hemisphere"
grid_levels = 2
duration_min = 4320.0

Kshana Studio で開く · GitHub で見る

gravity-map#

GPS が使えない環境での重力マップマッチング航法:冷却原子重力計が、通過する重力異常の系列から INS の一定のドリフトを復元します。

gps-denied-gravity-nav.toml

種別 gravity-map名前では台帳のモジュールと対応づけられていません

60 分間の GPS 拒否環境での重力マップマッチングのベンチマーク(量子代替 PNT)。

kind = "gravity-map"
nmax = 3
start_lat_deg = 10.0
start_lon_deg = 20.0
step_lat_deg = 0.06
step_lon_deg = 0.045
waypoints = 90
drift_lat_deg = 0.5

Kshana Studio で開く · GitHub で見る

gps-denied-gravity-nav-egm2008.toml

種別 gravity-map名前では台帳のモジュールと対応づけられていません

実際の重力場での 60 分間の GPS 拒否環境の重力マップマッチングのベンチマーク(WP-10、RM-17)。

kind = "gravity-map"
nmax = 3
start_lat_deg = 10.0
start_lon_deg = 20.0
step_lat_deg = 0.06
step_lon_deg = 0.045
waypoints = 90
drift_lat_deg = 0.5

Kshana Studio で開く · GitHub で見る

gravity-map-error-mc.toml

種別 gravity-map名前では台帳のモジュールと対応づけられていません

60 分間の GPS 拒否環境の重力マップベンチマークにおけるマップ誤差のモンテカルロ(WP-10、RM-15)。

kind = "gravity-map"
nmax = 3
start_lat_deg = 10.0
start_lon_deg = 20.0
step_lat_deg = 0.06
step_lon_deg = 0.045
waypoints = 90
drift_lat_deg = 0.5

Kshana Studio で開く · GitHub で見る

gravity-map-nav.toml

種別 gravity-map名前では台帳のモジュールと対応づけられていません

量子重力マップマッチング航法シナリオ(GPS 拒否環境の代替 PNT)。

kind = "gravity-map"
nmax = 3
start_lat_deg = 12.0
start_lon_deg = 24.0
step_lat_deg = 0.18
step_lon_deg = 0.13
waypoints = 12
drift_lat_deg = 0.55

Kshana Studio で開く · GitHub で見る

holdover-test#

タイミングシステムの MODELLED ホールドオーバー試験で、運用者が提供する時刻誤差の記録(linuxptp の ptp4l、phc2sys、ts2phc のログ、chrony の tracking または statistics ログ、TICC、TimeLab、RINEX のクロックログ、または time_s,time_error_ns の組)から採点します。試験は四つの手順から成り、Kshana はそのいずれも実行しません:ロック状態のベースライン、指定した時刻に運用者が行う GNSS の除去(アンテナケーブルまたはシミュレーター出力;Kshana は何も送信せず、何も駆動しません)、システム自身の発振器によるホールドオーバー、そして運用者が二つ目に指定した時刻に GNSS を復旧させた後の復旧です。記録はこの二つの時刻で分割されます。ベースライン:ロック状態のクロック向けに定められた時刻誤差の統計と ITU-T マスク。ホールドオーバー:統計、システムが保持した周波数偏差の割合(最小二乗直線)、ホールドオーバーまたは自律クロック向けに定められたマスク、指定したロック継続時間から求める ePRTC-A ホールドオーバーのエンベロープ、そして各時刻誤差バジェットを超えるまでの時間。復旧:|TE| が指定した帯域内に入り、そこにとどまったかどうかとその時期、ピーク、最大のステップ。すべての限界値は公開されている ITU-T の表(通信タイミングのマスク)から転記したものです;表現は「マスクに対して測定」であり、二つの時刻は運用者の申告であって、検証されていません。マスクに対して短すぎる記録は INCOMPLETE であり、外挿は行いません。docs/TIMING-HIL.md を参照してください。

holdover-test-example.toml

種別 holdover-test名前では台帳のモジュールと対応づけられていません

ホールドオーバー試験、取り込みの例:holdover-test 種別が採点する時刻誤差の記録(「アンテナを抜いて、ホールドオーバーを採点する」)。記録は運用者が指定する二つの時刻で分割され、ここでは 600 s に GNSS を除去し、2,400 s に復旧します。各ステップは、そのために書かれた ITU-T のマスクに照らして測定されます。

kind = "holdover-test"
masks = ["prtc-a", "eprtc-a-holdover"]
gnss_removed_s = 600.0
gnss_restored_s = 2400.0
locked_duration_days = 5.0
recovery_band_ns = 100.0
recovery_dwell_s = 60.0
samples = [

Kshana Studio で開く · GitHub で見る

holdover-test-ptp4l.toml

種別 holdover-test名前では台帳のモジュールと対応づけられていません

linuxptp ログのホールドオーバー試験:holdover-test-example.toml と同じ四つのステップで、記録は ptp4l のサーボログから [series.clock_log](形式 "ptp4l"、オフセットは ns、デーモン自身のタイムスタンプ、ここでは 5 s 間隔)を通して読み取ります。

kind = "holdover-test"
masks = ["prtc-a", "eprtc-a-holdover"]
gnss_removed_s = 600.0
gnss_restored_s = 2400.0
locked_duration_days = 5.0
recovery_band_ns = 100.0
recovery_dwell_s = 60.0
format = "ptp4l"

Kshana Studio で開く · GitHub で見る

hybrid#

ハイブリッド PNT の集大成:時計+IMU+時刻比較による補助。

hybrid-pnt.toml

種別 hybrid名前では台帳のモジュールと対応づけられていません

ハイブリッド PNT の集大成:すべて量子のスイート(光時計 + 冷却原子 IMU + 光 ISL の時刻比較による支援)とすべて古典のスイート(CSAC + 航法級 IMU + RF)の比較。GNSS は 1.8 h 妨害されます。

kind = "hybrid"
seed = 42
timing_spec_ns = 20.0
position_spec_m = 100.0
step_s = 10.0
duration_s = 7200.0
windows = [
enabled = true

Kshana Studio で開く · GitHub で見る

hybrid-optical-rf#

MODELLED の、異種の光学+RF PNT の結合性能指標(P5):1550 nm の往復光リンクバジェット(光子制限の往復測距 CRLB σ_τ/√N と回折フットプリント λ/D·range)、位置と時刻の両方についての、モダリティ間の解分離 RAIM 保護レベル(共分散の異なる疎結合 RF 解と密結合光学解を融合)、N 局の光学晴天可用性(独立和集合 1−Π(1−a_i) と空間相関を持つ変種)、証明されたビット連続(ジャンプなし)の平均と NEES χ² 整合性ゲートを備えた光学↔RF の状態/共分散ハンドオフ、そして相関の扱いを含む結合スコア P(可用 かつ 精密グレード かつ インテグリティ保証)。VALIDATED の閉形式:測距 CRLB、回折フットプリント、χ² 保護レベル分位点、和集合の組合せ論、ハンドオフの平均連続性+NEES ゲート、そして結合の独立積。MODELLED:光学損失の配分、RF/光学の σ の大きさ、雲気候値の入力、相関、P_HMI バジェット。認証を受けた可用性/インテグリティ製品ではありません。

hybrid-optical-rf.toml

種別 hybrid-optical-rf名前では台帳のモジュールと対応づけられていません

異種の光学 + RF PNT の統合可用性 / 精密度 / インテグリティ(P5)。

kind = "hybrid-optical-rf"
wavelength_nm      = 1550.0
tx_power_w         = 1.0e-3
tx_aperture_m      = 0.85
rx_aperture_m      = 0.85
range_km           = 384000.0
pulse_rms_ps       = 50.0
integration_s      = 1.0

Kshana Studio で開く · GitHub で見る

hybrid-ukf#

17状態の量子+古典ハイブリッド密結合 GNSS/INS UKF(MODELLED):15 個の INS 誤差状態+CAI 由来の加速度バイアス補正+q パラメーター時計エンジンによる2状態(位相+周波数)の時計を、上下限で囲んだ CAI 誤差モデルで駆動します。性能指標はフィルターの自己整合性(NEES+イノベーションの白色性を χ² 境界と比較)であり、自己整合性についての記述であって、実世界での精度の保証ではありません。シミュレーションのみ;TRL>3 ではなく、飛行実績もなく、外部での検証もありません。

hybrid-ukf.toml

種別 hybrid-ukf名前では台帳のモジュールと対応づけられていません

17 状態のハイブリッド量子 + 古典の密結合 GNSS/INS UKF(MODELLED)。

kind = "hybrid-ukf"
seed = 1771
speed_m_s = 100.0
sigma_pr_m = 1.0
sigma_rr_mps = 0.05
consistency_seeds = 24
q_factor = 1.0
r_factor = 1.0

Kshana Studio で開く · GitHub で見る

impairment-eval#

機械学習による RF 障害検出の評価テストベッド(13494):ラベル付きでパラメーターに基づく合成コーパス(nominal/jamming/spoof-time/spoof-position/multipath)を生成し、検出器(energy|agc|sqm|parity|fused)を検出器に依存しないハーネスで採点して、AUC/ROC/混同行列と、目標 Pfa でのクラスごとの Pd、さらに分布内と分布外の楽観性ギャップを報告します。MODELLED の動作特性のみ — 現場データや IQ は一切なく、良し悪しの判定もありません。

impairment-eval.toml

種別 impairment-eval種別の台帳の行はモデルから計算されたものです · 1 行中 0 行が外部参照で確認済み

機械学習による RF 障害検出の評価テストベッド(ESA AO/1-13494 デモンストレーター)。

kind = "impairment-eval"
seed = 42
n_per_class = 200
meas_noise = 0.6
detector = "fused"
target_pfa = 0.05
shift_severity_scale = 0.5
optimism_tol = 0.05

Kshana Studio で開く · GitHub で見る

inertial#

GNSS 途絶中の1-DOF 慣性推測航法。

imu-deadreckoning.toml

種別 inertial名前では台帳のモジュールと対応づけられていません

GNSS 途絶中の推測航法:冷却原子の量子加速度計と航法級の比較。バイアス = GNSS 較正後の残差 = 公表されているバイアス安定度。q_va = (ノイズのルート PSD)^2。

kind = "inertial"
seed = 42
threshold_m = 100.0
step_s = 10.0
duration_s = 7200.0
windows = [
id = "cold-atom-quat"
provenance = "Exail hybrid quantum accelerometer triad: bias stability 6e-8 g = 5.88e-7 m/s^2 after 24 h (Templier et al., Science Advances 2022, arXiv:2209.13209); noise 22 ug/sqrtHz = 2.16e-4 (m/s^2)/sqrtHz; laboratory maturity, not deployed"

Kshana Studio で開く · GitHub で見る

quantum-cai-coast.toml

種別 inertial名前では台帳のモジュールと対応づけられていません

量子プリセット:干渉計の物理から構築した冷却原子干渉計(CAI)の加速度計を、GNSS 途絶中の航法級の水晶加速度計と比較します。一次元の推測航法の惰行で、10 分間の GNSS の後、110 分間の妨害です。

kind = "inertial"
seed = 20261013
threshold_m = 100.0
step_s = 10.0
duration_s = 7200.0
windows = [
id = "cold-atom-interferometer"
provenance = "Cold-atom (Rb-87 D2) interferometric accelerometer: q_va derived from the [accel_quantum.cai] parameters, a bracket in the GAIN/MAIUS literature range (Freier et al. arXiv:1512.05660; Becker et al. Nature 2018); residual bias 5.88e-7 m/s^2 = the 6e-8 g bias stability of a laboratory hybrid quantum accelerometer (Templier et al., Science Advances 2022, arXiv:2209.13209). Laboratory maturity, not deployed."

Kshana Studio で開く · GitHub で見る

ins-trn-coast#

INS/TRN 慣性航行誤差モデル:慣性航行時間に対する位置誤差を、想定したドリフト率を掃引するのではなく、IMU 係数から構築します。五つの増大要因 — 加速度計バイアス、重力を介したジャイロバイアスの傾き、速度ランダムウォーク、角度ランダムウォーク、走行距離に対するスケールファクター — を、それぞれ指定した緯度と高度で Schuler フィードバックを持つ九状態のローカルレベル慣性誤差モデルに通して伝搬し(短い慣性航行での先頭次数の法則 t²、t³、t^1.5、t^2.5、t¹/t² を併せて報告します)、明示した規則で合成します(既定は二乗和平方根、または線形和、または決定論的和と確率的 rss;三つすべてを毎回計算するため、選択が埋もれずに見えます)。呼び出し側が与える位置しきい値(既定では10 m と50 m)に達する慣性航行時間は、エンジン既存の二分法で求め、それぞれに支配的な要因を示す要因別内訳を付け、各要因単独の交差も代数的に反転して二つが一致するようにしています。地形参照航法モードでは、定期的な位置フィックスで慣性航行を抑え、各しきい値を保てる最大のフィックス間隔を報告します;位置のみのフィックスはフィックスをまたいで速度誤差と傾きを残すため、どのフィックス頻度でも常に慣性航行を抑えられるとは限らず、報告はゼロを返すのではなくその旨を述べます。MODELLED:IMU クラスの係数は代表的な帯域の値であって、データシートではなく、地形フィックスの残差は入力です。到達しないしきい値は、ゼロではなく、ステータス付きの null として報告します。認証を受けた慣性航法の性能製品ではありません。

ins-trn-coast.toml

種別 ins-trn-coast名前では台帳のモジュールと対応づけられていません

INS/TRN の惰行誤差モデル:惰行時間に対する位置誤差と、それが 10 m と 50 m を超える惰行時間。

kind = "ins-trn-coast"
imu_grade = "navigation"
speed_m_s = 250.0
combination = "rss"
crossing_thresholds_m = [10.0, 50.0]
drift_band_lo_m_per_s = 0.001
drift_band_hi_m_per_s = 0.050
trn_fix_mode = "position-only"

Kshana Studio で開く · GitHub で見る

maritime-port-approach-coast.toml

種別 ins-trn-coast名前では台帳のモジュールと対応づけられていません

GNSS が妨害された海事の港湾進入:全球測位衛星システム(GNSS)を失った後、慣性航法システム(INS)が船舶を港湾進入の精度予算の範囲内に保てる時間。

kind = "ins-trn-coast"
imu_grade = "navigation"
speed_m_s = 6.17
combination = "rss"
crossing_thresholds_m = [10.0, 100.0]
drift_band_lo_m_per_s = 0.001
drift_band_hi_m_per_s = 0.050
trn_fix_mode = "none"

Kshana Studio で開く · GitHub で見る

rail-tunnel-coast.toml

種別 ins-trn-coast名前では台帳のモジュールと対応づけられていません

鉄道トンネルの惰行:トンネル内で全球測位衛星システム(GNSS)がない状態で、列車の慣性航法システム(INS)が軌道識別の予算の範囲内に保てる時間。

kind = "ins-trn-coast"
imu_grade = "tactical"
speed_m_s = 44.4
combination = "rss"
crossing_thresholds_m = [2.0, 20.0]
drift_band_lo_m_per_s = 0.001
drift_band_hi_m_per_s = 0.050
trn_fix_mode = "none"

Kshana Studio で開く · GitHub で見る

integrity#

スナップショット/解分離/ARAIM の RAIM と、HPL/VPL、Stanford ダイアグラム。

araim-gps-galileo.toml

種別 integrity名前では台帳のモジュールと対応づけられていません

二重コンステレーションの ARAIM 可用性:GPS + Galileo を、コンステレーション全体の故障仮説(araim_dual)を含む高度な ARAIM エンジンで評価します。

kind = "integrity"
mask_deg = 5.0
sigma_uere_m = 0.75
p_fa = 1.0e-5
p_md = 1.0e-3
al_h_m = 40.0
al_v_m = 50.0
araim_dual = true

Kshana Studio で開く · GitHub で見る

integrity-harbour-approach.toml

種別 integrity名前では台帳のモジュールと対応づけられていません

港に入る船舶の ARAIM 可用性:地上サイトのユーザー(user_site)を持つ integrity 種別を、harbour-approach のスカイラインプリセットで実行します。

kind = "integrity"
seed = 7
mask_deg = 5.0
sigma_uere_m = 1.0
p_fa = 1.0e-5
p_md = 1.0e-3
al_h_m = 40.0
al_v_m = 50.0

Kshana Studio で開く · GitHub で見る

integrity-raim.toml

種別 integrity名前では台帳のモジュールと対応づけられていません

GPS 型コンステレーション上の GNSS インテグリティ(RAIM)の可用性。

kind = "integrity"
seed = 7
mask_deg = 5.0
sigma_uere_m = 1.0
p_fa = 1.0e-5
p_md = 1.0e-3
al_h_m = 40.0
al_v_m = 50.0

Kshana Studio で開く · GitHub で見る

jamming#

リンクバジェットによるジャミング:J/S → 実効 C/N₀ → ロック喪失。

jamming-demo.toml

種別 jamming種別の台帳の行はモデルから計算されたものです · 1 行中 0 行が外部参照で確認済み

RF ジャミング:地上の広帯域ジャマーが、近くの受信機に GNSS を使わせない。

kind = "jamming"
seed = 1
mask_deg = 5.0
tracking_threshold_dbhz = 25.0
step_s = 30.0
duration_s = 1800.0
lat_deg = 52.0
lon_deg = 4.0

Kshana Studio で開く · GitHub で見る

jamming-harbour-approach-skyline.toml

種別 jamming種別の台帳の行はモデルから計算されたものです · 1 行中 0 行が外部参照で確認済み

陸上のジャマーの下で港に入る船舶。前方の岸壁の建物が、その方向の低い衛星を遮ります:harbour-approach のスカイラインプリセットを用いた jamming シナリオです。

kind = "jamming"
seed = 1
mask_deg = 5.0
tracking_threshold_dbhz = 25.0
step_s = 60.0
duration_s = 21600.0
lat_deg = 59.80
lon_deg = 24.90

Kshana Studio で開く · GitHub で見る

maritime-strait-jamming.toml

種別 jamming種別の台帳の行はモデルから計算されたものです · 1 行中 0 行が外部参照で確認済み

海事の GNSS ジャミング:陸上または船上の広帯域ジャマーが、開けた海域を渡る船舶から全球測位衛星システム(GNSS)を奪います。

kind = "jamming"
seed = 1
mask_deg = 5.0
tracking_threshold_dbhz = 25.0
step_s = 30.0
duration_s = 1800.0
lat_deg = 59.80
lon_deg = 24.90

Kshana Studio で開く · GitHub で見る

launch-window#

二体問題による打ち上げと上昇の幾何:打ち上げ方位角(sin Az = cos i / cos lat)、到達可能な最小軌道傾斜角、円軌道速度、地球自転による東向きの加算分、目標傾斜角が射場緯度より小さい場合のドッグレッグ面変更 Δv、そして一日あたりの打ち上げ機会の数。MODELLED の球形地球幾何(自転する地球の速度三角形の補正なし、上昇/抗力損失モデルなし)。

launch-window.toml

種別 launch-window名前では台帳のモジュールと対応づけられていません

打ち上げウィンドウと上昇ジオメトリのデモンストレーター(ミッション解析、トレードスタディの階層)。

kind = "launch-window"
site_lat_deg = 28.5
target_inclination_deg = 51.6
altitude_km = 400.0

Kshana Studio で開く · GitHub で見る

leo-navmsg#

LEO 航法メッセージ:低軌道(LEO)の測位・航法・時刻衛星の放送エフェメリスと時計。任意の軌道、搬送波、モデルに対応し、名前付きのプリセット(Xona Pulsar、Iridium、Starlink、CentiSpace、代表的な C バンドシステム、ATOMIC ゼロクロックモデル、Celeste IOD)も任意で使えます。内容:補助データ(SVID、データ発行番号、バンド、信号健全性)、同期(週、週内時刻、toc まわりの二次の時計多項式 af0-af2)、四つのモデルのいずれかによるエフェメリス -- Galileo OS SIS ICD の16パラメーターのケプラー要素セット;そのセットに along-track、cross-track、radial の補正多項式を加えたもの;Liu ら 2025 の22パラメーターモデル;時計項のない ECEF 多項式(ATOMIC ゼロクロック)-- およびその他のサービス(Klobuchar の放送セット、実効電離レベルを伴う NeQuick-G ai0-ai2、ICD のうるう秒ロジックによる系統時刻から UTC へのパラメーター)。フィッター:選んだ次数までの帯状 J2-J6 または EGM2008 重力と抗力で積分した真値の軌道と、シード付きの自由または制御された時計;非特異要素に対するケプラー要素セットの Levenberg-Marquardt 当てはめ、続いて線形最小二乗の補正多項式;時計は、ユーザーが加える相対論項を差し引いて当てはめます。解析:fit-interval-trade(軌道高度に対する全球平均の重みを用いた信号空間距離誤差 SISRE を、当てはめ区間と更新周期に対して、軌道のみと時計込みで)、model-comparison(四つのモデル、パラメーター数、符号化ビット数、そして Liu ら の高度での Kshana の当てはめを、公表されている数値と並べて)、midpass-update(ユーザー上空で最も高いパス、各メッセージ切り替えの位置・時計・ユーザー距離のジャンプ、最悪幾何でのジャンプ、連続性しきい値に対する PASS/FAIL)、encode-decode(CRC-24Q を持つ Kshana 独自の文書化されたバイナリフレーム、フィールドごとの半刻み量子化バジェット、破損フレームの検査、Kshana 拡張と明記した RINEX-4 形式のレコードのエクスポートとインポート、そして CSV 表)。VALIDATED:SISRE の重みを公表されている MEO/GEO の表(Montenbruck ら 2018)に対して;Galileo のユーザーアルゴリズムを実際の Galileo 放送エフェメリスについて RTKLIB に対して;CRC-24Q をそのカタログのチェック値と RTCM 1005 の例示フレームに対して。MODELLED:当てはめと SISRE の数値はすべて、Kshana が積分した真値に対する表現誤差です(軌道決定や予測の誤差はありません);Liu ら との比較は異なる軌道を使っています;符号化とテキスト形式は Kshana 独自のものです。

leo-navmsg-celeste-iod.toml

種別 leo-navmsg名前では台帳のモジュールと対応づけられていません

ESA Celeste の軌道上実証(IOD)プリセット:ESA Navigation Innovation and Support Programme(NAVISP)の LEO-PNT ワークショップ(2026)で発表された資料を使う唯一のシナリオです。リリースから外すには、このファイルと src/leo_navmsg/presets/celeste_iod.rs を削除します(そのファイルのヘッダーを参照)。

kind = "leo-navmsg"
name = "Celeste IOD message (workshop preset)"
seed = 15
preset = "celeste-iod"
analysis = ["encode-decode", "fit-interval-trade"]
csv_schema = "celeste-iod"
span_s = 1800
fit_intervals_s = [60, 120, 300, 600, 900]

Kshana Studio で開く · GitHub で見る

leo-navmsg-encode-decode.toml

種別 leo-navmsg名前では台帳のモジュールと対応づけられていません

LEO 航法メッセージ:Kshana のバイナリ符号化、その量子化の予算、RINEX 形式と CSV のエクスポート。

kind = "leo-navmsg"
name = "LEO message encode and decode"
seed = 14
analysis = ["encode-decode"]
altitude_km = 550.0
inclination_deg = 97.6
gravity_degree = 20
model = "kepler-rac"

Kshana Studio で開く · GitHub で見る

leo-navmsg-fit-interval-trade.toml

種別 leo-navmsg名前では台帳のモジュールと対応づけられていません

LEO 航法メッセージ:フィット区間に対する信号空間測距誤差(SISRE)。

kind = "leo-navmsg"
name = "LEO message fit-interval trade"
seed = 11
analysis = ["fit-interval-trade"]
altitude_km = 550.0
inclination_deg = 97.6
gravity_degree = 20
cd_area_over_mass = 0.005

Kshana Studio で開く · GitHub で見る

leo-navmsg-midpass-update.toml

種別 leo-navmsg名前では台帳のモジュールと対応づけられていません

LEO 航法メッセージ:パスの途中でのメッセージ更新と、ユーザーが飛びを見るかどうか。

kind = "leo-navmsg"
name = "LEO message mid-pass update"
seed = 13
analysis = ["midpass-update"]
altitude_km = 550.0
inclination_deg = 97.6
gravity_degree = 20
model = "kepler-rac"

Kshana Studio で開く · GitHub で見る

leo-navmsg-model-comparison.toml

種別 leo-navmsg名前では台帳のモジュールと対応づけられていません

LEO 航法メッセージ:一つの軌道における四つのエフェメリスモデルと、Liu ら 2025 の SISRE 対高度の表。

kind = "leo-navmsg"
name = "LEO message model comparison"
seed = 12
analysis = ["model-comparison"]
altitude_km = 550.0
inclination_deg = 97.6
gravity_degree = 20
model = "kepler-rac"

Kshana Studio で開く · GitHub で見る

leo-pass#

LEO-PNT(低軌道からの測位・航法・時刻)向けの、システムに依存しない、バンドごとの LEO パスとリンクバジェット:ユーザー(地上、海上、航空、屋内、静止または移動)と一機以上の LEO 衛星を、DESIGNED PASS(設計パス:ユーザーが選んだ時刻に選んだ最大仰角の一回のパスを見るように置いた円軌道、求めに応じて太陽同期)、明示的な軌道要素、エンジンの SGP4 を通した TLE(二行軌道要素セット)、または衛星コンステレーション設計コードが構築する Walker コンステレーション(最も高いパスを報告)から与えます。バンドは名前付きのプリセット(汎用マルチバンド UHF/L/S/C、汎用 C バンド、Xona Pulsar X1/X5、Iridium STL、ドップラーのみの機会信号としての Starlink、CentiSpace、およびWORKSHOPと明記した任意の Celeste IOD プリセット)から取るか、シナリオに書き込みます;各プリセットは、その数値がPUBLIC(URL 付き)、REPRESENTATIVE、またはWORKSHOPのいずれかを明記します。衛星、バンド、エポックごとに:仰角、方位角、距離、距離変化率、距離加速度;自由空間経路損失;EIRP と衛星パターンのゲイン(アイソフラックス、ガウスビーム、フラット);仰角に対するユーザーアンテナのゲイン(パッチ、半球、等方);気体減衰(ITU-R P.676-10 Annex 2)、降雨減衰(降雨強度と降雨高度からの ITU-R P.838-3 係数と P.618-14 手順)、対流圏シンチレーション(ITU-R P.618-14 節2.4.1)、屋内ユーザーの建物侵入損失(ITU-R P.2109-2)、偏波不整合、システム雑音温度と C/N0(搬送波対雑音密度);距離変化率と距離加速度から閉形式で求めるドップラーとドップラー変化率で、それぞれ中心差分と照合;一次の電離圏遅延40.3 STEC/f^2 を、Klobuchar または鉛直 TEC の斜め TEC から、衛星より下の電離圏の部分に換算して求めます。バンドのペアについては、パスのピークで電離圏フリー係数、雑音増幅、コード雑音を求めます。MEO GNSS 衛星(Galileo または GPS のプリセット)は、インターフェース文書の受信電力から、同じアンテナ・雑音モデルで評価されるため、LEO の釣鐘形のパスと平坦な GNSS 搬送波が一つのプロットを共有します。任意の [iot] セクションは、指定した受信機の電力バジェットに対する、デューティサイクルごとの初回測位時間、一回の測位あたりのエネルギー、バッテリー寿命を与えます(MODELLED)。各バンドのペアは、その幾何フリー結合が復元する斜め TEC をピークで求め、その推定のコード雑音の sigma も与えます(電離圏探査)。任意の [spoofer] セクションは、開始後に真の位置から飛ぶか押し出される主張位置の信号を偽造し、指定した誤警報確率と見逃し確率で二つのモニターを実行します:ドップラーとパス幾何の整合性(軌道と独立した事前の位置・速度から予測した距離変化率に対する測定値、窓にわたる一般化最小二乗のカイ二乗検定、GNSS、LEO、全チャネルについて)と、バンド間の整合性(各 LEO バンドペアのモデル補正済み幾何フリー結合のエポック間のステップ)で、エポックごとの統計と各モニターが検出する時点を報告します(MODELLED)。VALIDATED の構成要素:自由空間損失、P.838-3 係数をその表5に対して、P.618-14 の降雨・シンチレーション手順と P.2109 の建物侵入損失を ITU-R Study Group 3 の検証例に対して、IS-GPS-200 の L1/L2 群遅延比、そして円軌道の静止ユーザーの最大ドップラーを arXiv 2509.19551 の表1に対して。MODELLED:EIRP、パターン、衛星より下の TEC の Chapman 割合、そしてパス全体。

leo-focus-science-iono-sounding.toml

種別 leo-pass名前では台帳のモジュールと対応づけられていません

LEO-PNT の重点分野:LEO-PNT 科学、二周波の遅延による電離圏サウンディング。

kind = "leo-pass"
name = "LEO ionosphere sounding from multi-band delays"
epoch = "2026-09-28T11:00:00"
duration_s = 900.0
step_s = 5.0
environment = "ground"
lat_deg = 69.66
lon_deg = 18.94

Kshana Studio で開く · GitHub で見る

leo-indoor-uhf.toml

種別 leo-pass名前では台帳のモジュールと対応づけられていません

屋内の LEO-PNT:L、S、C バンドが苦戦する中で、UHF 搬送波が建物内に届く理由。

kind = "leo-pass"
name = "Indoor UHF LEO-PNT"
epoch = "2026-09-28T12:00:00"
duration_s = 900.0
step_s = 5.0
environment = "indoor"
lat_deg = 41.9
lon_deg = 12.49

Kshana Studio で開く · GitHub で見る

leo-iot-energy.toml

種別 leo-pass名前では台帳のモジュールと対応づけられていません

IoT(モノのインターネット)トラッカー向けの低消費エネルギー LEO-PNT:測位解ごとのエネルギーとデューティサイクルの関係。

kind = "leo-pass"
name = "IoT energy per fix"
epoch = "2026-09-28T06:00:00"
duration_s = 900.0
step_s = 5.0
environment = "ground"
lat_deg = 53.55
lon_deg = 9.99

Kshana Studio で開く · GitHub で見る

leo-pass-celeste-iod-multiband.toml

種別 leo-pass名前では台帳のモジュールと対応づけられていません

ESA Celeste IOD、信号構成 #1、一回のパスにわたる全バンド。WORKSHOPプリセット。

kind = "leo-pass"
name = "Celeste IOD multi-band pass"
epoch = "2026-09-28T08:00:00"
duration_s = 600.0
step_s = 2.0
iono_free_pairs = [["E5", "C"], ["UHF", "C"], ["E5", "SR"]]
environment = "ground"
lat_deg = 52.218

Kshana Studio で開く · GitHub で見る

leo-pass-iridium.toml

種別 leo-pass名前では台帳のモジュールと対応づけられていません

航空機から見た Iridium STL(衛星による時刻と位置)バースト。

kind = "leo-pass"
name = "Iridium STL from an aircraft"
epoch = "2026-09-28T14:00:00"
duration_s = 900.0
step_s = 5.0
environment = "air"
lat_deg = 50.0
lon_deg = -30.0

Kshana Studio で開く · GitHub で見る

leo-pass-vs-gnss-cn0.toml

種別 leo-pass名前では台帳のモジュールと対応づけられていません

可視の Galileo 衛星に対する LEO-PNT のパス:一回のパスにわたる C/N0。

kind = "leo-pass"
name = "LEO pass versus MEO GNSS C/N0"
epoch = "2026-09-28T08:00:00"
duration_s = 900.0
step_s = 2.0
environment = "ground"
lat_deg = 48.137
lon_deg = 11.575

Kshana Studio で開く · GitHub で見る

leo-pass-xona-pulsar.toml

種別 leo-pass名前では台帳のモジュールと対応づけられていません

一回のパスにわたる Xona Pulsar の X1 と X5、および Pulsar コンステレーションの最高仰角のパス。

kind = "leo-pass"
name = "Xona Pulsar pass"
epoch = "2026-09-28T10:00:00"
duration_s = 1200.0
step_s = 5.0
environment = "maritime"
lat_deg = 45.5
lon_deg = -5.0

Kshana Studio で開く · GitHub で見る

leo-resilience-spoof-doppler.toml

種別 leo-pass名前では台帳のモジュールと対応づけられていません

スプーフィングに対する LEO-PNT のレジリエンス:ドップラーとパスジオメトリの整合性。

kind = "leo-pass"
name = "Spoofing detection by LEO Doppler consistency"
epoch = "2026-09-28T08:00:00"
duration_s = 1800.0
step_s = 5.0
environment = "ground"
lat_deg = 50.11
lon_deg = 8.68

Kshana Studio で開く · GitHub で見る

leo-pnt-chain#

任意のコンステレーションと信号に対応する、LEO-PNT(低軌道からの測位・航法・時刻)システムのエンドツーエンドの連鎖:signal_design で指定する leo-signal 設計(公開プリセットまたはインラインの [signal] 設計)が [pass] バンドの中心周波数、帯域幅、チップレート、EIRP の配分を決め、leo-pass のリンクバジェットがパス全体にわたる追跡 C/N0 と帯域制限付きのコードジッターを与え、sin(仰角) に対する C/N0 の直線と [navmsg] メッセージの放送 SISRE(パス衛星の高度で当てはめたもの)が、[fusion] の leo-pvt 統合測位解のすべての LEO システムに、また任意で [ppp] の leo-ppp ケースに渡されます。すべての受け渡しは値と単位とともに一覧されます。MODELLED。

celeste-iod-end-to-end.toml

kind leo-pnt-chain名前では台帳のモジュールと対応づけられていません

Celeste IOD のエンドツーエンド(オプションのプリセット):E5 構成 #1 の信号 → Celeste IOD のパス → Celeste 方式の航法メッセージ → GPS + Galileo + Celeste IOD の統合測位解。

kind = "leo-pnt-chain"
name = "Celeste IOD end to end"
seed = 4
signal_design = "celeste-iod-e5-1-pfa"
od_sisre_m = 0.25
name = "celeste-iod-e5-1-pfa"
system = "Celeste IOD"
source = "WORKSHOP"

Kshana Studio で開く · GitHub で見る

leo-pnt-end-to-end.toml

kind leo-pnt-chain名前では台帳のモジュールと対応づけられていません

汎用コンステレーション上での LEO-PNT のエンドツーエンド:信号設計 → パスのリンクバジェット → 航法メッセージ → MEO と LEO の統合測位解、および精密単独測位(PPP)の収束。

kind = "leo-pnt-chain"
name = "LEO-PNT end to end, generic 1080 km constellation"
seed = 5
signal_design = "generic-l"
od_sisre_m = 0.25
presets = ["generic-bands"]
epoch = "2026-09-28T08:00:00"
duration_s = 1200.0

Kshana Studio で開く · GitHub で見る

xona-pulsar-end-to-end.toml

kind leo-pnt-chain名前では台帳のモジュールと対応づけられていません

Xona Pulsar のエンドツーエンド:公開されている X5 信号 → Pulsar のパス → LEO 航法メッセージ → GPS + Galileo + Pulsar の統合測位解、および精密単独測位(PPP)の収束。

kind = "leo-pnt-chain"
name = "Xona Pulsar end to end"
seed = 9
signal_design = "xona-x5"
od_sisre_m = 0.25
presets = ["xona-pulsar"]
epoch = "2026-09-28T10:00:00"
duration_s = 1200.0

Kshana Studio で開く · GitHub で見る

leo-ppp#

GNSS のみの場合と LEO 補強ありの場合の精密単独測位(PPP)の収束:電離圏フリーのコードと搬送波位相に対するフロート拡張カルマンフィルターで、静的な局座標、白色の受信機クロック、追加システムごとに 一つのシステム間バイアス、1/sin(仰角) でマッピングされるランダムウォークの天頂湿潤遅延、衛星アークごとのフロートアンビギュイティを持ちます。精密な軌道・クロック誤差は白色で、衛星のコードと位相に共通のため、各衛星は Joseph 安定化形式の相関した 二行の更新 一つになります。測定値は、複数の観測局とシードにわたり、シード付きノイズを加えた同じモデルからシミュレートされ、各ケース(最初に GNSS のみ、続いて LEO システムの各 [[case]]、任意のコンステレーションまたはプリセット)は、収束時間の中央値(水平誤差と垂直誤差がしきい値、既定で 10 cm、を下回ったままになる最初のエポック)、収束した割合、誤差曲線の中央値、およびフィルターの整合性(実行ごとに平均した位置 NEES を両側 95% のカイ二乗帯域と比較したもの)を報告します。任意で、公表された Li et al.(2019、J. Geod. 93:749、doi 10.1007/s00190-018-1195-2)の中緯度の数値と並べて示します:マルチ GNSS の 9.6 分は、60、96、192、288 機の LEO 衛星で 7.0、3.2、2.1、1.3 分に短縮されます。MODELLED:傾向の整合性の比較であり、その研究のコンステレーション、ノイズ、観測局の再現ではありません。アンビギュイティ解決、サイクルスリップ、位相ワインドアップ、潮汐、時間相関のある製品誤差はありません。

leo-ppp-convergence.toml

kind leo-ppp名前では台帳のモジュールと対応づけられていません

LEO 補強による精密単独測位(PPP)の収束。

kind = "leo-ppp"
seed = 20
duration_s = 1800.0
step_s = 10.0
runs = 4
lat_deg = 30.5
lon_deg = 114.4
lat_deg = 48.1

Kshana Studio で開く · GitHub で見る

leo-pvt#

任意のコンステレーションにわたる、中軌道(MEO)と低軌道(LEO)を融合した測位・航法・時刻(PNT):各 [[system]] は、constellation-design 種別の GNSS プリセット、LEO プリセット(xona-pulsar、iridium-stl、starlink-sop、centispace、generic-c-band、atomic-zero-clock エフェメリスモデル、または別のプリセットファイル。それぞれ独自のファイルを持ち、出典は PUBLIC、WORKSHOP、DERIVED のいずれかで示されます)、Walker シェル、または明示した軌道要素の集合のいずれかで、搬送波、チップレート、仰角マスクから天頂までの搬送波対雑音密度(C/N0)の包絡線、信号空間距離誤差(SISRE)、ドップラーのシグマ、クロックモデル(独自の受信機クロックでシステム間バイアスを推定するか、既知の放送オフセット)を持ちます。四つのモード。DOPPLER:距離変化率からのバッチ Gauss-Newton 測位で、解析的な偏微分、クロックドリフトと任意の速度状態、任意の高さ拘束を伴い、単一衛星または複数衛星で、窓長に対する誤差、各 LEO システムのドップラー、ドップラーレート、ジャークの包絡線、およびクロストラックオフセットに対する単一パスのアロングトラック精度とクロストラック精度を扱います(パスが真上に来るにつれてクロストラック誤差は際限なく増大し、単一パスには地上軌跡を挟んだ鏡像解も存在します)。ドップラーのみの機会信号(starlink-sop)はここで実行されます。JOINT:GNSS のみ、LEO のみ、両方によるエポックごとの重み付き最小二乗疑似距離測位解で、C/N0 でのディレイロックループの熱雑音モデルと SISRE から測定ごとのシグマを求め(または固定のシグマとし、信号モデルから与えることもできます)、推定したシステム間バイアスと、追加した LEO 衛星数に対する PDOP/HDOP/VDOP を扱います。POLAR:GNSS、LEO、両方についての、緯度に対する視界内の衛星数と DOP。TIMING:既知の位置にある LEO 衛星から協定世界時(UTC)への時刻伝送で、プロセスノイズがエンジンの発振器クラスに由来する 二状態のクロックフィルターを用い、C/N0 と発振器に対して評価し、IS-GPS-200 のシステム時刻から UTC への式も扱います。[timing] で trace = true とすると、すべての行がエポックごとの時刻誤差と予測シグマも報告します。VALIDATED:真上から地平線までのパスの最大ドップラーを、公表された Iridium(最大 36 kHz)と Xona Pulsar X1(32 から 34 kHz)の数値と比較。MODELLED:それ以外のすべて。DOP は手計算で導いたケースと、測位解は共分散と、ドップラーモデルは距離加速度の恒等式と照合されています。

celeste-iod-fused-pvt.toml

kind leo-pvt名前では台帳のモジュールと対応づけられていません

ESA の Celeste 軌道上実証衛星二機が加わる GNSS 測位。

kind = "leo-pvt"
mode = "joint"
seed = 4
duration_s = 5700.0
step_s = 30.0
lat_deg = 52.22
lon_deg = 4.42
height_m = 5.0

Kshana Studio で開く · GitHub で見る

leo-doppler-positioning.toml

kind leo-pvt名前では台帳のモジュールと対応づけられていません

汎用の LEO 航法コンステレーションによる、LEO ドップラーのみからの測位。

kind = "leo-pvt"
mode = "doppler"
seed = 7
duration_s = 600.0
step_s = 10.0
lat_deg = 48.14
lon_deg = 11.58
height_m = 520.0

Kshana Studio で開く · GitHub で見る

leo-pvt-fjord-skyline.toml

kind leo-pvt名前では台帳のモジュールと対応づけられていません

谷壁が水路の対岸の低い空をすべて隠すフィヨルド深部の船舶に対する MEO と LEO の統合測位:fjord スカイラインプリセットのもとでの leo-pvt 統合モード。

kind = "leo-pvt"
mode = "joint"
seed = 3
duration_s = 1800.0
step_s = 30.0
lat_deg = 61.1
lon_deg = 6.6
height_m = 20.0

Kshana Studio で開く · GitHub で見る

leo-timing-utc.toml

kind leo-pvt名前では台帳のモジュールと対応づけられていません

LEO 衛星から UTC への時刻伝送、C/N0 と受信機の発振器に対して。

kind = "leo-pvt"
mode = "timing"
seed = 9
duration_s = 21600.0
step_s = 10.0
lat_deg = 39.99
lon_deg = -105.26
height_m = 1655.0

Kshana Studio で開く · GitHub で見る

meo-leo-fused-pvt.toml

kind leo-pvt名前では台帳のモジュールと対応づけられていません

MEO と LEO を融合した疑似距離測位:GPS と Galileo に LEO 航法レイヤーを加えたもの。

kind = "leo-pvt"
mode = "joint"
seed = 3
duration_s = 1800.0
step_s = 30.0
lat_deg = 40.42
lon_deg = -3.70
height_m = 650.0

Kshana Studio で開く · GitHub で見る

polar-arctic-leo-coverage.toml

kind leo-pvt名前では台帳のモジュールと対応づけられていません

赤道から極までの可視衛星数と精度低下率(DOP):MEO GNSS のみ、極軌道に近い LEO コンステレーションのみ、そして両者の併用。

kind = "leo-pvt"
mode = "polar"
duration_s = 7200.0
step_s = 600.0
lat_step_deg = 10.0
lon_step_deg = 45.0
pdop_threshold = 6.0
name = "GPS"

Kshana Studio で開く · GitHub で見る

leo-signal#

LEO-PNT 信号設計:任意のシステム、バンド、構造に対応する、パラメーター化した低軌道(LEO)の測位・航法・時刻(PNT)信号。SIGNAL は、バンド(中心周波数、送信帯域幅、ITU 割り当て RNSS/RDSS/MSS/EESS/non-RNSS/other)と、成分(捕捉、データ、パイロット。任意の部分集合)からなり、各成分は変調(小数の n を許す BPSK(n)、BOC(m,n)、MBOC(6,1,p)、または平坦な OFDM 風のバンド)、電力配分、任意の FDMA サブキャリアオフセット、コード長、データレートを持ちます。信号は、コンパイル済みの公開プリセットファイル(xona-pulsar、iridium-stl、starlink-soo、centispace、generic-c-band、generic-bands。それぞれ出典 URL を持ち、未公表の値はすべて REPRESENTATIVE と記されます)から得るか、インラインで記述します。信号ごと:帯域制限付きの電力スペクトル密度と、送信帯域が通す各成分の電力の割合(BPSK の閉形式を数値と並べて)、RMS(ガボール)帯域幅、C/N0 と early-late 間隔に対するディレイロックループのコード追跡熱雑音ジッター(Betz & Kolodziejski 2009 の帯域制限付きコヒーレント(または非コヒーレント)early-late 式から、帯域無制限の教科書的な形と、間隔が消える極限のガボール限界を添えて)、メートルでの測距精度、捕捉の探索空間(軌道の最大ドップラーと発振器およびユーザーの項から求めるドップラービン、にコードビンを掛けたもの)、二乗検波の検出確率と、直列およびコード並列の平均捕捉時間、その信号から GPS L1 C/A、Galileo E1、GPS L5、Galileo E5a、E5b、E5 AltBOC へのスペクトル分離係数と、それぞれからその信号への係数および C/N0 の劣化、そして追跡成分が許容する CW、広帯域、整合の J/S(スペクトル種別自身の SSC の仕組みから)。BAND TRADE:一次の電離圏遅延(40.3 TEC/f^2)、自由空間損失、等しい C/N0 と等しい EIRP での測距精度、ジャマー耐性。任意の SHAPE CHECKS は、設計のスペクトルを、記述された測定と照合します(MODELLED の整合性)。VALIDATED:BPSK のバンド内電力(メインローブに 90.3 %)とガボール帯域幅の閉形式、教科書的なコヒーレント early-late 形とそのガボール限界に帰着する帯域制限付きジッター、オフセット BPSK スペクトル分離係数とその Parseval の閉形式との比較、AltBOC スペクトルの単位面積、および最大 LEO ドップラーと公表された Xona Pulsar(32-34 kHz)と Iridium(36 kHz)の数値との比較。MODELLED:すべての設計、電力配分、C/N0、ジャマーレベル。EFQPSK、CSK、OFDM のスペクトルは近似です。

celeste-iod-classical-pilot-signals.toml

kind leo-signal名前では台帳のモジュールと対応づけられていません

Celeste IOD の信号設計:ESA の Celeste 軌道上実証(IOD)による低軌道(LEO)の測位・航法・時刻(PNT)ミッションにおける周波数帯と「Classical Pilot」信号構成 #1 を、パラメーター化した信号設計として示します。

kind = "leo-signal"
noise_figure_db = 2.0
antenna_temp_k = 290.0
loop_bandwidth_hz = 1.0
integration_time_s = 0.02
correlator_spacings_chips = [1.0, 0.5, 0.2, 0.1]
reference_spacing_chips = 0.5
tracking_threshold_dbhz = 25.0

Kshana Studio で開く · GitHub で見る

leo-band-trade.toml

kind leo-signal名前では台帳のモジュールと対応づけられていません

LEO-PNT の周波数帯トレードオフ(UHF から広帯域 C バンドまで):特定のシステムによらず、低軌道(LEO)の測位・航法・時刻(PNT)信号が各周波数帯で得るものと失うもの。

kind = "leo-signal"
presets = ["generic-bands"]
noise_figure_db = 2.0
antenna_temp_k = 290.0
loop_bandwidth_hz = 1.0
integration_time_s = 0.02
correlator_spacings_chips = [1.0, 0.5, 0.2, 0.1]
reference_spacing_chips = 0.5

Kshana Studio で開く · GitHub で見る

xona-pulsar-signals.toml

kind leo-signal名前では台帳のモジュールと対応づけられていません

Xona Pulsar の信号:商用の低軌道(LEO)測位・航法・時刻(PNT)コンステレーションの X1(L1 帯)信号と X5(L5 帯)信号を、公開されている信号表(Leclère、Marathe、Reid、ION GNSS+ 2025、https://arxiv.org/abs/2509.19551)から、コンパイル済みの xona-pulsar プリセットとして収録しています。

kind = "leo-signal"
presets = ["xona-pulsar"]
noise_figure_db = 2.0
antenna_temp_k = 290.0
loop_bandwidth_hz = 1.0
integration_time_s = 0.02
correlator_spacings_chips = [1.0, 0.5, 0.2, 0.1]
reference_spacing_chips = 0.5

Kshana Studio で開く · GitHub で見る

CCSDS 401 / DSN 810-005 のリンク方程式に基づく片方向リンクバジェット:送信 EIRP、受信 G/T、距離、データレート、バンド(s|x|ka)に対する、自由空間伝搬損失、C/N₀、Eb/N₀、マージン、クロージャを、必要な Eb/N₀ と比較します。与えられた入力からの決定論的なエンジニアリング計算であり、較正済みの端末データシートではありません。

lunar-ascent#

南極域の月面地点からランデブー軌道までの MODELLED の動力上昇と、軌道へ引き継がれる位置・速度共分散(Artemis級)。lunar-descent の軸ごとの五状態の慣性誤差モデル(位置、速度、加速度計バイアス、姿勢の傾き、ジャイロバイアスで、比力によって駆動される)は、フェーズが入るときの月面の状態から、地点の三つの軸すべてで実行します。ILLUSTRATIVE な LCNS 級コンステレーションの、見える中継衛星による AFS 位置測位解(単独、または lunar-differential-pnt の補正リンク残差を用いた差動で、見える中継衛星が三つのときはクロックを補助)を、明記した間隔で取得し、月時刻は機体のクロックと進行方向のタイムタグ誤差を通じて加わります。閉形式の慣性誤差源、補助の寄与、アブレーション、上昇中の航法の 1 シグマ、航法知識と並べたエンジン停止時の分散、そして位置・速度の相関を保った、投入時の完全な 6x6 MCI 共分散を報告します。MODELLED:例示的な IMU の等級、比力、中継衛星の組、停止時の分散。誤差は発射地点の軸で保持し、公称の離脱状態は代用です。機関による承認はありません。助言用ソフトウェアであり、認証を受けた航法装置ではありません。

lunar-ascent.toml

kind lunar-ascent名前では台帳のモジュールと対応づけられていません

月面上昇:南極域の月面地点(Artemis クラス)から 100 km のランデブー軌道への動力上昇と、それが軌道へ持ち越す位置・速度の共分散。

kind = "lunar-ascent"
site_lat_deg = -89.5
site_lon_deg = 0.0
ascent_s = 450.0
insertion_altitude_km = 100.0
accel_bias_ug = 100.0
align_arcmin = 3.0
gyro_bias_deg_per_hr = 0.01

まだ GitHub にはありません

lunar-attack-surface#

月面航法の信号セキュリティの攻撃対象領域(P1):公開されている信号セキュリティ解析を、バイナリから到達可能な 一回の実行にまとめます。報告するのは、(1)AFS の受信電力と、地上の GPS 基準に対するその電力の余剰、さらに、リンク入力(基準レベル x EIRP x 斜距離)にわたる本格的な多軸掃引としての 12-18 dB の感度帯域と、25 倍に丸めた値 / 28 倍に丸めない値の線形係数の整合です。改訂(規則 R4):GPS 基準が -125 / -128.5(これらは dBm の値)から -155 / -158.5 dBW、すなわちジャミングモジュールがこれまで一貫して保持してきた ICD-GPS-200 の値に訂正されるまで、これは 15.6 dB の電力不足と 32 倍 / 36 倍の係数を報告していました。符号は反転します。モデル化した月面 AFS 信号は、地上の GPS L1 C/A より 14.4 dB 強く、弱くはありません。受信電力そのものは 一ビットも動いておらず、線形係数は旧値をちょうど 1000 で割ったもので、これはちょうど 30 dB の dBm から dBW へのオフセットに相当します。(2)各スタンドオフでスプーフィング(J/S = 3 dB)と妨害(J/S = 30 dB)に必要な攻撃者の送信電力。これは J/S リンクの逆です。(3)実際の一様開口アンテナパターン(Airy [2 J1(x)/x]^2)の下での軌道上の捕捉フットプリント。高度に制限された半球未満のキャップであり、その縁は捕捉されません。(4)理想として主張した 3 dB のしきい値ではなく、計算したトラッキングループのスプーフィング捕捉プルインの結果(一致するコードのスプーファーが、与えられた電力優位とコードオフセットで、実際に DLL/PLL を引きずるか)。(5)持ち上げた地表送信機の、大気のない天体における幾何学的な地平線到達距離。(6)OSNMA/TESLA の認証バジェット(20 bit/s のオーバーヘッド = 50 bit/s の AFS 航法メッセージの約 40 %、鍵開示の遅延、2^-40 の偽造)。本文が空の場合は P1 のベースラインを再現します。すべての入力には既定値があり、上書きできます。VALIDATED の副次的な結果は、出典モジュールのオラクルを引き継ぎます(閉形式の dB 無線測定、逆 J/S の往復、Airy パターンと A&S のベッセル関数および球冠ジオメトリの比較、DLL/PLL のプルインと Kaplan & Hegarty の比較、球の接線による地平線の恒等式と eo_payload の比較、OSNMA SIS-ICD のフィールドサイズ)。MODELLED:代表的なジオメトリと電力の大きさ、および具体的な捕捉マップのセルの値。認証済みのセキュリティ製品ではありません。

lunar-attack-surface.toml

kind lunar-attack-surface名前では台帳のモジュールと対応づけられていません

月面航法の信号セキュリティの攻撃対象領域(論文 P1)。

kind = "lunar-attack-surface"
afs_eirp_dbw = 26.0
user_gain_dbi = 3.0
slant_range_m = 3.0e6
carrier_hz = 2.4e9
gps_reference_dbw = -155.0
gps_reference_min_dbw = -158.5
transmitter_altitude_m = 100_000.0

Kshana Studio で開く · GitHub で見る

lunar-beacon#

月周回の航法サービスに対する地表ビーコンによる補強を、実行可能な前後比較の表として示します。南極域のユーザーには、まばらな周回衛星の集合が空の狭い領域に見えるため、測距ジオメトリは悪条件になります。少数の測量済みの地表ビーコンが、すべて頭上にある集合には欠けている、低仰角で広い方位角の視線方向の行を補い、水平方向の精度低下率は大きく低下します。このシナリオは 一つのエポックにおける 三つの構成を報告します。衛星のみ、衛星と可視ビーコン、そして同じジオメトリに至る別の経路としてのより大きなコンステレーションです。それぞれに、可視ソースの数、完全な DOP、そして、クロック同期、マルチパス、測量の各項の二乗和平方根として組み立てたビーコンごとのユーザー等価測距誤差を掛け合わせて得られる、メートル単位の実現 1 シグマ精度が付きます。ビーコンの可視性は大気のない月における 二つの高度での幾何学的な地平線です(大気がないため、境界は厳密です)。DOP の組み立ては、tests/dop_reference.rs で gnss_lib_py とクロスチェックしているものと同じカーネルです。この種別が存在する理由:その背後にあるモジュールは L08/L09 以来エンジンに入っており、独立した DOP の経路と照合されていましたが、実行から到達できませんでした -- 種別も、ディスパッチの分岐も、同梱ファイルもありませんでした。README はこの機能をうたっていましたが、検証マトリクスにはその行がまったくなく、そのため散文では主張されながら台帳では主張されておらず、しかもエンジンからは到達できませんでした。既定値は、すでにコミット済みのゴールデンを持つジオメトリです(-80 度のユーザーに 2 m のアンテナ、-80/0、-79/+60、-79/-60 の 三つのビーコン(2 km)、t=0 における六機の例示的な LCNS スナップショット、5 度のマスク)。そのため、何も指定しない実行は、新しい数値を作り出すのではなく、オラクルがすでにカバーしている表を再現します。MODELLED:コンステレーション設計、ビーコンの配置、およびすべての誤差バジェットの大きさは例示的な入力であり、実際に運用されている測量や測定されたリンクではありません。外部に裏付けられているのは、DOP の演算、地平線の閉形式、シグマ = DOP x sigma_URE の関係のみです。サービス性能の確約ではありません。

lunar-beacon.toml

kind lunar-beacon種別の台帳の行はモデルから計算されたものです · 1 行中 0 行が外部参照で確認済み

月軌道航法サービスの、地表ビーコンによる補強。

kind = "lunar-beacon"
n_satellites = 6
comparison_n_satellites = 24
epoch_s = 0.0
elevation_mask_deg = 5.0
clock_sync_m = 1.0
multipath_m = 0.5
survey_m = 0.3

Kshana Studio で開く · GitHub で見る

lunar-descent#

南極域の着陸地点(アルテミス級)への動力降下に対する、MODELLED の着陸分散バジェット。水平軸ごとに、五状態の慣性誤差モデル(位置、速度、加速度計バイアス、姿勢の傾き、ジャイロバイアス)を降下時の比力で駆動し、逐次フィルターが、有効にした補助手段からの位置フィックスを取り込みます。補助手段は、ILLUSTRATIVE な LCNS 級コンステレーションの可視中継衛星からの AFS フィックス(単独、または lunar-differential-pnt の補正リンク残差を使う差分方式で、可視の中継衛星が三つのときは時計を補助します)と、地形相対フィックス(合成起伏に対するクレートの TERCOM/SITAN マッチャー、または実際の LOLA 南極域 DEM の標高窓をマッチングする場合のクラメール・ラオ下限)です。月時刻は、フィックス時点の機体時計(lunar-time-offset の LTC-TT オフセット、または公表された帯域の不確かさ)と、沿軌道方向のタイムタグ誤差として入ります。報告するのは、3-sigma の着陸楕円、R95、閉形式の慣性誤差源、各補助手段の寄与、補助手段のあらゆる組み合わせのアブレーション、楕円のモンテカルロによる較正、そして引き継ぐ共分散です。MODELLED:IMU クラス、中継衛星の構成、降下プロファイル、誘導項は例示的なものです。地形航法は地球のメートルスケールの合成起伏を使います。AFS の可用性は、平坦なマスクでの一エポックのものです。機関の推奨は受けていません。助言用ソフトウェアであり、認証を受けた航法装置ではありません。

lunar-descent.toml

kind lunar-descent名前では台帳のモジュールと対応づけられていません

月面着陸の分散:南極域の地点(Artemis クラス)への動力降下のバジェット。降下スタックの慣性ドリフトと、地形相対航法、LunaNet 信号、月の時刻がそれぞれどれだけ減らすかから求めます。

kind = "lunar-descent"
site_lat_deg = -89.5
site_lon_deg = 0.0
more_site_lats_deg = [-89.9, -88.5, -85.0]
descent_s = 600.0
horizontal_speed_m_s = 150.0
accel_bias_ug = 100.0
align_arcmin = 3.0

まだ GitHub にはありません

lunar-descent-lola.toml

kind lunar-descent名前では台帳のモジュールと対応づけられていません

実際の LOLA 南極 DEM を用いた月面着陸の分散:南極域の地点(Artemis クラス)への動力降下のバジェット。降下スタックの慣性ドリフトと、地形相対航法、LunaNet 信号、月の時刻がそれぞれどれだけ減らすかから求めます。

kind = "lunar-descent"
site_lat_deg = -89.5
site_lon_deg = 0.0
more_site_lats_deg = [-89.9, -88.5, -85.0]
descent_s = 600.0
horizontal_speed_m_s = 150.0
accel_bias_ug = 100.0
align_arcmin = 3.0

まだ GitHub にはありません

lunar-differential-pnt#

モデルから計算した月面の差分 PNT(月面版の DGNSS/SBAS に相当):既知の月面座標にある NovaMoon クラスの基準局が、ILLUSTRATIVEで公開情報に基づく Moonlight/LCNS クラスのコンステレーションから衛星ごとの差分補正を計算します(NovaMoon はシステムのクラスとしてのみ参照しており、ESA とは無関係です)。baseline_km だけ離れたユーザーがそれを適用すると、共通モード(common-mode)の軌道誤差とクロック誤差が打ち消されます。クロック項は正確に打ち消されます(代数的な恒等式)。軌道項に残るのは視線方向の差の射影のみで、これは基線 → 0 で → 0 となり(空間的な非相関の下限)、基線にほぼ線形に比例して増大します。補正ありとなしのユーザーの 3D 位置誤差、低減係数、基線に対する誤差の曲線、そして差分残差 σ を用いて DO-229E の SBAS の仕組み(crate::sbas)を再利用するユーザー保護レベルを報告します。MODELLED — 正確な打ち消しの恒等式と 一次の非相関モデル。実データでは検証されていません。TRL、飛行実績、機関による承認はありません。シードを与えれば決定論的です。

lunar-differential-pnt.toml

kind lunar-differential-pnt名前では台帳のモジュールと対応づけられていません

月のディファレンシャル PNT — 月の DGNSS / SBAS に相当するもの。

kind = "lunar-differential-pnt"
n_sats = 8
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7
argp_deg = 90.0
ref_lat_deg = -89.0
ref_lon_deg = 0.0

Kshana Studio で開く · GitHub で見る

lunar-frame-campaign#

注入した変換ではなく、シミュレートした観測キャンペーンによって駆動される、七パラメーターの Helmert(相似)座標系データム。地上局のネットワークが、明示したスケジュールに従って月面ビーコンのカタログを観測します。月 VLBI の遅延偏微分はそのスケジュールにわたって蓄積され、lunar-vlbi-fim とまったく同様にビーコン座標のフィッシャー情報行列になります。その情報は、カタログ点での Helmert の計画行列 A = [I3 | [p]_x | p] を通して、データム共分散 H = A^T M_b A に伝搬され、crate::fim::crlb で診断されます。変換は一切注入されず、仕込んだ答えから回復されるものも何もないため、報告されるデータム精度は観測計画から導かれます。遅延のシグマを半分にすれば、精度はちょうど半分になり、弧を長くすれば精度が向上します。これは、レポートが測定する秤動(sub_earth_direction_sweep_deg)が、視線方向のビーコン座標を天球面内のものから切り離すためです。ランク、データムの欠損、条件数、スペクトル全体、七パラメーターの基底における観測不能な方向、フルランクでも最も弱い方向、およびその方向への各パラメーターの寄与は、すべての実行で出力されます。キャンペーンが拘束しないパラメーターは、ほぼ特異な逆行列から読み出されることはなく、ステータス付きで NULL として公開されます。ビーコン誤差の相関は、仮定されるのではなく、測定されます。局を固定した場合、どの観測も二つのビーコンに関わらないため、情報行列は厳密にブロック対角になります(offblock_fraction 0)。局を推定する場合は、シューア補元で周辺化したブロックが結合し、誘起された相関が表示され、それを捨てて伝搬全体が再実行されるので、独立性の仮定の代償は数値として得られます。等方的な座標ごとのシグマの下での同じ伝搬と、lunar-frame-realisation シナリオが報告する回復誤差は、どちらもここで実行され、キャンペーンの値と並べて、その比とともに表示されます。MODELLED:ビーコンのカタログは出典付きですが、キャンペーンはシミュレートです。局のネットワークと遅延のシグマは例示的な入力であり、個々の遅延観測は独立として扱われ、月中心のエフェメリス、局のクロック、対流圏、地球姿勢パラメーターは固定されるため、データム共分散は、縮約したパラメーター集合に対するクラメール・ラオ限界です。測地学的な成果物ではありません。

lunar-frame-campaign.toml

kind lunar-frame-campaign名前では台帳のモジュールと対応づけられていません

シミュレートした観測キャンペーンで駆動する、七パラメーターのヘルマート月座標系データム(G9)。

kind = "lunar-frame-campaign"

Kshana Studio で開く · GitHub で見る

lunar-frame-realisation#

モデルから計算した月面の座標系の実現:7 パラメーターの Helmert(相似)データムのフィット — 3 並進、3 微小角回転、1 スケール — で、重み付き最小二乗(crate::batch_ls::gauss_newton)により、月面座標(selenographic)に由来する MCMF の点座標の推定集合をデータムに結び付けます。さらに、IAU 2015 WGCCRE の天体姿勢に対する、ICRF 軸まわりの実現された微小回転を表す簡易な姿勢の結び付けも行います。このシナリオは、既知の微小な変換(並進は数十 m 程度、回転は µrad 程度、スケールは ~1e-7)を、よく分散した合成の点ネットワークに注入し、シード付きのガウスノイズを加え、データムを回復して、回復した変換、注入した真値に対するパラメーターごとの回復誤差、フィット後の RMS 残差を報告します。MODELLED の自己整合性 — 注入した相似変換を回復します(ノイズなしではマシン精度程度まで)。実際の追跡や VLBI のデータに対する実現ではありません。決定論的(シード付き)。TRL、飛行実績、機関による承認はありません。

lunar-frame-realisation.toml

kind lunar-frame-realisation名前では台帳のモジュールと対応づけられていません

月の座標系の実現 — 7 パラメーターのヘルマート(相似)データムのフィット。

kind = "lunar-frame-realisation"
n_points = 8
tx_m = 25.0
ty_m = -40.0
tz_m = 15.0
rot_x_urad = 3.0
rot_y_urad = -2.0
rot_z_urad = 5.0

Kshana Studio で開く · GitHub で見る

lunar-infrastructure#

航法・測地インフラとしての月の軌道と表面の MODELLED の研究。study で選択する一つの種別の下に五つの研究があります:od-consistency(NRHO または ELFO における搭載の地球 GNSS による軌道決定を、独立した地上電波計測による軌道決定と、シード付きモンテカルロにわたるそれぞれの共分散で判定)、carrier-phase(LAMBDA による、地表と周回機の結合した二重差の搬送波位相と整数値バイアスの決定)、frame-coestimation(七パラメーターの月面座標系データムのための、地球局測距への地表局と周回機の追加)、space-tie(一機の宇宙機上の GNSS、VLBI、レーザー測距で、座標系の結び付けの精度をローカルタイの誤差と比較)、geodesy-sensitivity(レーザー測距、周回機の追跡、地表重力計、地表クロックからの、月のラブ数 h2、k2、l2 と物理秤動のフィッシャー情報)。明示した単純化を伴う制限三体モデルです。数値計算は独立したプログラムと照合されており、月の量の測定値との比較は一切ありません。

lunar-infrastructure-carrier-phase.toml

kind lunar-infrastructure名前では台帳のモジュールと対応づけられていません

Kshana の lunar-infrastructure シナリオ:carrier-phase、QUICK の例(短い二つのアーク、10 回の試行、数秒。採点対象の構成は 三つのアークと 400 回の試行で、xval/lunar-infra/scenarios/carrier-phase-scored.toml です)。MODELLED。設計、入力、合格基準は xval/lunar-infra/PREREGISTRATION.md に固定されています(いかなる実行よりも前にコミット済み)。ILLUSTRATIVEの入力には、そこで公開情報源が明記されています。

kind = "lunar-infrastructure"
study = "carrier-phase"
seed = 20261019
family = "nrho"
sample_s = 600.0
arcs_days = [0.25, 0.5]
lat_deg = 0.0
lon_deg = 0.0

Kshana Studio で開く · GitHub で見る

lunar-infrastructure-frame-coestimation.toml

kind lunar-infrastructure名前では台帳のモジュールと対応づけられていません

Kshana の lunar-infrastructure シナリオ:frame-coestimation。MODELLED。設計、入力、合格基準は xval/lunar-infra/PREREGISTRATION.md に固定されています(いかなる実行よりも前にコミット済み)。ILLUSTRATIVEの入力には、そこで公開情報源が明記されています。

kind = "lunar-infrastructure"
study = "frame-coestimation"
seed = 20261019
family = "nrho"
arc_days = 6.56
sample_s = 900.0
sigma_m = 0.05
epochs = 200

Kshana Studio で開く · GitHub で見る

lunar-infrastructure-geodesy-sensitivity.toml

kind lunar-infrastructure名前では台帳のモジュールと対応づけられていません

Kshana の lunar-infrastructure シナリオ:geodesy-sensitivity。MODELLED。設計、入力、合格基準は xval/lunar-infra/PREREGISTRATION.md に固定されています(いかなる実行よりも前にコミット済み)。ILLUSTRATIVEの入力には、そこで公開情報源が明記されています。

kind = "lunar-infrastructure"
study = "geodesy-sensitivity"
seed = 20261019
sigma_m = 0.05
epochs = 400
sigma_mm_s = 0.05
arc_days = 27.3
sample_s = 3600.0

Kshana Studio で開く · GitHub で見る

lunar-infrastructure-od-consistency.toml

kind lunar-infrastructure名前では台帳のモジュールと対応づけられていません

Kshana の lunar-infrastructure シナリオ:od-consistency。MODELLED。設計、入力、合格基準は xval/lunar-infra/PREREGISTRATION.md に固定されています(いかなる実行よりも前にコミット済み)。ILLUSTRATIVEの入力には、そこで公開情報源が明記されています。

kind = "lunar-infrastructure"
study = "od-consistency"
seed = 20261019
family = "nrho"
arc_days = 3.0
sample_s = 600.0
altitude_km = 20180.0
inclination_deg = 55.0

Kshana Studio で開く · GitHub で見る

lunar-infrastructure-od-consistency-model-error.toml

kind lunar-infrastructure名前では台帳のモジュールと対応づけられていません

Kshana の lunar-infrastructure シナリオ:モデル化していない加速度を伴う od-consistency。MODELLED。設計、入力、合格基準は xval/lunar-infra/PREREGISTRATION.md に固定されています(いかなる実行よりも前にコミット済み)。ILLUSTRATIVEの入力には、そこで公開情報源が明記されています。

kind = "lunar-infrastructure"
study = "od-consistency"
seed = 20261019
family = "nrho"
arc_days = 3.0
sample_s = 600.0
altitude_km = 20180.0
inclination_deg = 55.0

Kshana Studio で開く · GitHub で見る

lunar-infrastructure-space-tie.toml

kind lunar-infrastructure名前では台帳のモジュールと対応づけられていません

Kshana の lunar-infrastructure シナリオ:space-tie。MODELLED。設計、入力、合格基準は xval/lunar-infra/PREREGISTRATION.md に固定されています(いかなる実行よりも前にコミット済み)。ILLUSTRATIVEの入力には、そこで公開情報源が明記されています。

kind = "lunar-infrastructure"
study = "space-tie"
seed = 20261019
family = "nrho"
arc_days = 6.56
sample_s = 900.0
gnss_sigma_m = 10.0
vlbi_sigma_m = 1.0

Kshana Studio で開く · GitHub で見る

lunar-integrity#

代表的な LunaNet 中継衛星の集合に対する、月南極の ARAIM 保護レベルのパス。sigma_ure_m は信号空間の測距精度を公開します(保護レベルはこれに比例して線形にスケールするため、これを掃引すれば、警報限界がどの測距精度を要求するかが分かります)。既定値は従来の LNIS クラスの南極のケースです。

lunanet-araim.toml

kind lunar-integrity名前では台帳のモジュールと対応づけられていません

月の南極のインテグリティ:アルテミス地域に着陸した受信機と、代表的な LunaNet 中継衛星群に対する、24 h のパスにわたる ARAIM の保護レベル。

kind = "lunar-integrity"
step_s = 3600.0
duration_s = 86400.0
alert_limit_m = 50.0
p_hmi = 1.0e-4

Kshana Studio で開く · GitHub で見る

lunar-interop-export#

モデルから計算した月面の相互運用性エクスポート:月の座標系、月の時刻系、月のエフェメリスを、LunaNet/IOAG に整合した CCSDS ベースの交換形式で出力し、往復 / フィールド適合性を確認します。このクレートの CCSDS OEM 2.0 のエミッター + パーサー(crate::oem)を月面の文脈向けに付け替えて再利用します — OEM の REF_FRAME は IAU 2015 WGCCRE の月の天体座標系(MOON_ME / MOON_PA)、TIME_SYSTEM は月の時刻系(LTC / TCL / UTC)、CENTER_NAME = MOON を持ち、例示的な LCNS クラスのエフェメリスのサンプル(位置は crate::lunar_service から、速度は有限差分による)に適用します。また、serde_json で往復できる LunaNet/IOAG に整合した月の時刻の記述子(時刻系 ID、crate::lunar_time からの永年変化率 µs/day、公表された帯域、基準面)も出力し、既存の KIF エンベロープ(crate::interchange)に MODELLED の誠実性ラベルを付けて成果物を包みます。出力した成果物、OEM の行数、フィールド適合性の合格と存在 / 欠落フィールドの一覧、OEM の往復 ok、時刻メタデータの往復 ok、KIF のバイトサイズを報告します。MODELLED — オラクルは、決定論的な往復と、公表された CCSDS OEM および LunaNet/IOAG のフィールド意味論に対するフィールド名の適合性です。認証済みの相互運用性適合試験ではありません。例示的で公開情報に基づくエフェメリスであり、ESA とは無関係です。TRL、飛行実績、機関による承認はありません。

lunar-interop-export.toml

kind lunar-interop-export名前では台帳のモジュールと対応づけられていません

月の相互運用エクスポート — LunaNet / IOAG に整合した、CCSDS ベースの交換。

kind = "lunar-interop-export"
frame = "MOON_ME"
time_system = "LTC"
n_states = 9
step_min = 30.0
epoch = "2030-01-01T00:00:00"
object = "LCNS-ILLUSTRATIVE-1"

Kshana Studio で開く · GitHub で見る

lunar-jamming#

月固有の RF ジャミング:例示的で公開情報に基づく Moonlight/LCNS クラスの月周回コンステレーションの上で、月面(または高い位置)のジャマーの下にある月面座標のユーザーについての、衛星ごとのジャマー対信号比、実効 C/N₀、ロックの喪失。既存のオープンなジャミング物理(jamming::j_over_s_db、effective_cn0_dbhz、rx_antenna_gain_db、lock_status、q_factor)と、既存の月の空のジオメトリ(lunar_service::LunarConstellation + topocentric、lunar::selenographic_to_mcmf)を組み合わせます。ジオメトリや無線測定を再導出することはありません。地球の jamming 種別とは異なり、信号の側は固定の受信電力ではありません。各衛星の等方受信電力は、それ自身のリンクバジェットの EIRP − FSPL(斜距離)であるため、J/S は月の距離と仰角に応じて衛星ごとに変わります。可視な(エポック、衛星)リンクごとに一行を報告します — 方位角、仰角、斜距離、J/S がその差となる二つの受信電力、J/S、公称と実効の C/N₀、ロックの状態 — さらに、その表の代わりにではなく、その表に並べて集約した性能指標と、同じ表を CSV 成果物として。出力されるすべての数値フィールドは、単位と出所の区分を持ちます。VALIDATED の副次的な結果は、出典モジュールのオラクルを引き継ぎます(Kaplan & Hegarty の §9.4 の耐ジャミング方程式と J/S リンク。tests/gnss_denied_jamming_resilience_reference.rs で外部参照されています。lunar_service の月のジオメトリ)。構成そのものは、独立した二つのリンクバジェットの経路(linkbudget::received_signal_power_dbw、異なる自由空間損失の式)と 1e-9 dB まで照合されています。MODELLED:例示的なコンステレーション、代表的な EIRP / ジャマー電力 / アンテナ利得 / 雑音温度、そして地形による遮蔽、マルチパス、AGC の動特性、適応ヌル形成がないこと。認証済みのサービス拒否製品ではありません。ジャマーを設定すると、レポートには、一つのスカラーから読み取った等値線ではなく、不確かさの帯を持つ拒否等値線も含まれます。具体的には、衛星ごとの表にわたる、測定された目的信号の C/N₀ 分布全体(n、最小値、p05、p25、中央値、p75、p95、最大値、平均、標本標準偏差、標本自身の非対称性)と、それらの各順序統計量で評価した等値線を、エンジンが認める拒否基準の両方のもとで示します。従来からの電力比基準(J/S = 30 dB、attack-surface と tracking-loop と同じ)と、ロック喪失基準(実効 C/N₀ が tracking_threshold_dbhz まで低下すること。このレポート自身のステータス列が使う基準)で、拒否平面の両方の軸(シナリオのスタンドオフで必要なジャマー EIRP、シナリオの EIRP での拒否スタンドオフ)について評価します。帯の端は contour(p05) と contour(p95) であり、標本自身の分位数に適用した同じ閉形式の写像です。標本に当てはめたシグマでも、中央値 ± k·標準偏差でもなく、標準偏差は連続性のために出力されますが、何にも使われません。追跡しきい値以下にすでにある分位数には、有限の拒否 J/S が存在せず、そのロック喪失の列は、数えた理由とともに null となり、切り詰めた半径が出ることはありません。

lunar-jamming.toml

kind lunar-jamming名前では台帳のモジュールと対応づけられていません

月固有の RF ジャミング:月面ユーザーに対する衛星ごとの J/S。

kind = "lunar-jamming"
n_sats = 4
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7
argp_deg = 90.0
site_lat_deg = -89.67
site_lon_deg = 129.78

Kshana Studio で開く · GitHub で見る

lunar-joint-od-clock#

モデルから計算した、シミュレートしたネットワーク上での、複数技術による月面 OD + クロックの統合バッチ推定器:Gauss-Newton のスナップショットフィットで、地球基線の測地 VLBI 遅延、月面ローカルの局と衛星の間の距離、衛星間距離を融合し、注入した真値から、月面局の 3D 位置、小規模なコンステレーションの位置、各アセットのクロックオフセットを同時に回復します。最も重要な誠実な結果 — 月面ローカルの測距だけでは弱く観測される方向が残る場所で、VLBI が局の完全な 3D 位置を観測可能にすること — は、VLBI あり・なしの局誤差の対比として報告されます。MODELLED のシミュレートした閉ループ回復(真値は観測モデルを共有)。決定論的(シード付き)。実データでの検証ではありません。ソルバー内に力モデルによる伝搬はありません。TRL、飛行実績、機関による承認はありません。

lunar-joint-od-clock.toml

kind lunar-joint-od-clock名前では台帳のモジュールと対応づけられていません

月の複数手法統合による軌道決定 + 時計決定(シミュレートしたネットワーク)。

kind = "lunar-joint-od-clock"
n_sat = 3
n_earth = 6
seed = 42
sigma_vlbi_s = 1.0e-11
sigma_range_m = 0.1
sigma_isl_m = 0.1
station_lat_deg = -88.0

Kshana Studio で開く · GitHub で見る

lunar-llr-datum#

シミュレートしたものではなく、実際にアーカイブされた観測キャンペーンによって駆動される、七パラメーターの Helmert 月面座標系データム。lunar-frame-campaign は注入した変換を取り除きましたが、局のネットワーク、スケジュール、観測ごとのシグマはILLUSTRATIVEな入力として明示していました。この種別は、その三つすべてを測定から取ります。エポックは、アーカイブされた ILRS Consolidated Laser Ranging Data のノーマルポイントの地上送信時刻、観測は月面の五つのレトロリフレクターアレイに実際に発射されたレーザー測距、そしてすべての観測の重みは、そのノーマルポイント自身がファイルに記録している精度 bin_rms/sqrt(n_raw) です。局座標は IERS ITRF2020 の SLR 解(公表された速度でエポックまで伝搬)から、リフレクター座標は、IAU 2015 WGCCRE モデルが実現する平均地球 / 平均自転座標系での JPL DE430 の Table 7 から得ています。測距の偏微分は、リフレクター座標の結合したフィッシャー情報行列に蓄積され、同じ Helmert の計画行列を通してデータム共分散に伝搬され、crate::fim::crlb で診断されます。ランク、欠損、条件、スペクトル、七パラメーターの基底における観測不能な方向、フルランクでの最も弱い方向、およびその方向への各パラメーターの寄与は、すべての実行で出力され、拘束されないパラメーターはステータス付きで NULL として公開されます。アレイ間の相関は、仮定されるのではなく、ちょうどゼロで MEASURED です。レーザー測距は一つのアレイにしか関わらないためです。カタログが位置を決められない記録 — 公表された ITRF 位置のない局 — は、スキップされて数えられ、代用の座標が与えられることはありません。どのリンクが MEASURED で、どのリンクが MODELLED であるかが、レポートそのものであり、脚注ではありません:月中心のエフェメリスと IAU の天体姿勢はモデルから計算したままで、その合成した大きさは、使用したすべての点にわたる、観測値から計算値を引いた片道の距離残差として出力されます。対流圏、固体潮汐、局の偏心、極運動、UT1-UTC、相対論的遅延、局のクロックは含まれず、その残差の内側にあります。エフェメリスの誤差は、各視線方向を通してのみ共分散に届くため、すべての実行は、すべての偏微分を sensitivity_tilt_deg(符号は交互)だけ傾けてデータム全体を再び解き、その比を出力します。したがって、モデルから計算したエフェメリスに対する共分散の鈍感さは、議論ではなく数値です。シミュレートしたキャンペーン自身の数値は、転記されるのではなく、実行されて、測定された数値と並べて表示されます。MODELLED:七パラメーターの数値は、実際のスケジュール上の縮約したパラメーター集合に対するクラメール・ラオ限界であり、解いたデータムでも、LLR の解析でも、測地学的な成果物でもありません。コミット済みの実データのスライスはリポジトリに同梱されていますが、公開されたクレートには含まれません。data_dir をそのコピーに向けてください。

lunar-llr-datum.toml

kind lunar-llr-datum名前では台帳のモジュールと対応づけられていません

実際にアーカイブされた観測キャンペーンから得た、七パラメーターのヘルマート月座標系データム(V3)。

kind = "lunar-llr-datum"

Kshana Studio で開く · GitHub で見る

lunar-station-geodesy-baseline.toml

kind lunar-llr-datum名前では台帳のモジュールと対応づけられていません

月の基準局測地、ベースライン:現在の五つの再帰反射器アレイのみ。

kind = "lunar-llr-datum"
epoch_year = 2024
epoch_month = 1
epoch_day = 1
arc_hours = 672.0
step_min = 60.0
delay_sigma_s = 1.0e-11
elevation_mask_deg = 10.0

Kshana Studio で開く · GitHub で見る

lunar-station-geodesy-with-station.toml

kind lunar-llr-datum名前では台帳のモジュールと対応づけられていません

月面基準局の測地、局あり:五つの後方反射器アレイに加え、月の南極の基準局サイトにある後方反射器一つと VLBI ビーコン一つ。

kind = "lunar-llr-datum"
extra_earth_elevation_mask_deg = 0.0
name = "lunar-reference-station-reflector"
lat_deg = -89.0
lon_deg = 0.0
alt_m = 0.0
name = "lunar-reference-station-beacon"
lat_deg = -89.0

Kshana Studio で開く · GitHub で見る

lunar-orbit-rendezvous#

低い月周回軌道または楕円の極軌道(アルテミス級)でのオリオン・着陸機型のドッキングに対する、MODELLED の相対航法。チェイサーとターゲットは、クレートの月力モデルのもとで同じ軌道を飛びます。弧全体にわたる 21 パラメータの結合バッチ Gauss-Newton 推定(二機の状態と持続的な信号空間バイアス)が、ILLUSTRATIVE な LCNS 級の中継衛星群から機体ごとに得る絶対位置フィックス(月の裏側に隠れた中継衛星は除外し、四つ必要で、機体間で共通モードの信号空間誤差は打ち消されます)と、クロスリンク測距を融合します。測距精度は、LunaNet AFS パイロットに対するコード追尾下限から求めます。報告するのは、ターゲットの LVLH 軸における相対位置・速度誤差の形式値とモンテカルロ値、フィックスの可用性、期待値に対する正規化推定誤差二乗の平均、反復が収束しなかった試行、重力調和項を無視した場合のドリフト、そして引き継ぐ 6x6 共分散全体です。円軌道の場合には、閉形式の Hill/Clohessy-Wiltshire チェックを適用します。MODELLED:中継衛星の構成、誤差バジェット、事前分布は例示的なものです。真値と推定器は一つの力モデルを共有するため、NEES が確認するのは自己整合性であり、モデル誤差ではありません。機関の推奨は受けていません。助言用ソフトウェアであり、認証を受けた航法装置ではありません。

lunar-orbit-rendezvous.toml

kind lunar-orbit-rendezvous名前では台帳のモジュールと対応づけられていません

月面ランデブー:100 km の円形の極低高度月周回軌道(Artemis クラス)での、Orion とランダー方式のドッキングの相対航法。月の重力場と LunaNet 方式の信号を用います。

kind = "lunar-orbit-rendezvous"
orbit = "llo"
separation_m = 2000.0
arc_s = 7200.0
step_s = 20.0
n_relays = 8
sis_ure_m = 30.0
common_mode_fraction = 0.9

まだ GitHub にはありません

lunar-orbit-rendezvous-elfo.toml

kind lunar-orbit-rendezvous名前では台帳のモジュールと対応づけられていません

楕円極軌道での月面ランデブー:100 km × 3000 km の極軌道(近点は南極の上空、Artemis クラス)での、Orion とランダー方式のドッキングの相対航法。月の重力場と LunaNet 方式の信号を用います。

kind = "lunar-orbit-rendezvous"
orbit = "elfo"
separation_m = 2000.0
arc_s = 7200.0
step_s = 20.0
n_relays = 8
sis_ure_m = 30.0
common_mode_fraction = 0.9

まだ GitHub にはありません

lunar-station-coverage#

モデルから計算した月面基準局のカバレッジ:月面の差分 PNT モデルを、南極域のユーザー格子と一日分のエポックにわたってモンテカルロ掃引したもの。既知の南極域の地点にある差分基準局が、明示した信号空間誤差、測量誤差、補正の遅延、リンクの量子化を伴う、明示したコンステレーション(例示的なケプラー軌道、または表形式のエフェメリス)を補正します。点ごと、および領域全体について、補正ありとなしの位置誤差のパーセンタイル(3D、水平、垂直)、可用性、明示したしきい値に対するカバレッジ、DO-229E の保護レベル、方位ごとのカバレッジ半径、局と最悪の点での補正リンクバジェットを報告します。いかなる実システムの性能についての記述でもありません。いかなる機関とも提携しておらず、承認も受けていません。MODELLED。

lunar-station-coverage.toml

kind lunar-station-coverage名前では台帳のモジュールと対応づけられていません

月面基準局のカバレッジ:既知の南極サイトにある月面ディファレンシャル基準局から、ユーザーが南極域全体で 一日にわたって得られる測位精度と保護レベル。

kind = "lunar-station-coverage"
n_sats = 8
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7
argp_deg = 90.0
mask_deg = 5.0
station_lat_deg = -89.0

Kshana Studio で開く · GitHub で見る

lunar-station-coverage-public-sources.toml

kind lunar-station-coverage名前では台帳のモジュールと対応づけられていません

公開されている前提のもとでの月面基準局のカバレッジ:lunar-station-coverage.toml と同じ kind で、公開情報源が値を示している入力はすべてそこから設定して情報源 ID で引用し、どの情報源も示していない入力は組み込みの既定値のままにしてILLUSTRATIVEと明記しています。情報源(取得日 2026-10-12。タイトル、識別子、ライセンスは docs/LUNAR-REFERENCE-STATION.md に記載):S1 arXiv:2602.08432v3 S2 IOAG Cislunar PNT Workshop 2025, "Lunar local Differential PNT and Selenodetic Reference Station"(スライド) S3 UNOOSA ICG WG-B, Lunar PNT, June 2024 (LunarPNT_Jun24_01_04.pdf) S4 IOAG Cislunar 2026, "Moonlight Programme Development Status"

kind = "lunar-station-coverage"
n_sats = 4
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7
argp_deg = 90.0
mask_deg = 5.0
station_lat_deg = -89.4765

Kshana Studio で開く · GitHub で見る

lunar-station-coverage-terrain.toml

kind lunar-station-coverage名前では台帳のモジュールと対応づけられていません

地形を考慮した月面基準局のカバレッジ:同梱の lunar-station-coverage シナリオに対し、平坦な仰角マスクだけの代わりに、局とすべてのユーザー地点で、実際の月面数値標高モデル上を光線追跡して地点ごとの地平線を求めたもの。

kind = "lunar-station-coverage"
n_sats = 8
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7
argp_deg = 90.0
mask_deg = 5.0
station_lat_deg = -89.0

Kshana Studio で開く · GitHub で見る

lunar-surface#

アルテミス級の南極域の地点について、地点と季節ごとの、MODELLED の月面測位・タイミングの可用性。地点と季節(エポックとその後の時間窓)ごとに、中継衛星による測位(ILLUSTRATIVE な LCNS 級コンステレーションの中継衛星が四つ以上見え、PDOP がしきい値未満であること。moonlight-service-volume と同じ関数を使い、地形セクションがある場合は lunar-station-coverage の地形のレイマーチングによるスカイラインを使います)、地球と太陽が地点の地平線より上にあるか(解析的な太陽、月、月の向き。秤動を含み、季節とともに動くのはこれです)、そしてタイミングの可用性(中継衛星または地球が見えること)を報告し、どちらも見えない最長の区間、すなわち月面の時計が持ちこたえなければならないホールドオーバーも示します。単一地点の結果は、moonlight-service-volume の結果とビット単位で一致します。MODELLED:平均自転の月の上の、例示的なケプラー軌道の中継衛星群です。中継衛星の数値は季節で変わりません。地形は 1200 m の LOLA 切り出しです。機関の推奨は受けていません。助言用ソフトウェアであり、認証を受けた航法装置ではありません。

lunar-surface.toml

kind lunar-surface名前では台帳のモジュールと対応づけられていません

地点と季節ごとの月面 PNT と時刻の可用性(Artemis級の南極域の地点)。

kind = "lunar-surface"
season_dates = ["2028-01-01", "2028-04-01", "2028-07-01", "2028-09-30"]
window_days = 27.3217
step_min = 30.0
n_sats = 8
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7

まだ GitHub にはありません

lunar-surface-terrain.toml

kind lunar-surface名前では台帳のモジュールと対応づけられていません

実際の LOLA 南極域の地形の地平線を用いた、地点と季節ごとの月面 PNT とタイミングの可用性(Artemis クラスの南極域の地点)。

kind = "lunar-surface"
season_dates = ["2028-01-01", "2028-04-01", "2028-07-01", "2028-09-30"]
window_days = 27.3217
step_min = 30.0
n_sats = 8
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7

まだ GitHub にはありません

lunar-time-budget#

MODELLED のエンドツーエンドの協定月時刻(LTC)の時刻誤差バジェット:七つの LTC 誤差項を、平均化時間の格子全体にわたる時刻誤差曲線 x_i(τ) として組み立て、二乗和平方根で x_Σ(τ) にまとめ、増大するクロック項が一定のリアルタイム座標系実現の項を追い越すクロックと座標系の交差 τ(それより下では座標系が支配的、上ではクロックが支配的)を求めます — 単一 τ の成果物に対する誠実な答えです。τ の傾きは閉形式で解析的に確認でき(クロック τ^{+1/2}/τ^{+1}、下限 τ^0、測定 τ^{-1/2})、クロックの行は公表された一日のクロック仕様(crate::clock_specs)を再現します。RF/光リンク、座標系実現、相対論的残差、エフェメリスの下限の大きさは、モデルから計算した(文書化した既定値で、呼び出し側が上書き可能な)バジェット配分であり、測定ではありません。寄与は再現可能な交差 τ であり、認証された項ごとの数値ではありません。運用上の時刻維持のために認証されたものではありません。

lunar-station-time-lab.toml

kind lunar-time-budget種別の台帳の行はモデルから計算されたものです · 1 行中 0 行が外部参照で確認済み

月面基準局の時刻研究室:小型ルビジウム時計(miniRAFS)を月協定時(LTC)に同期させ、その後自走させたもの。

kind = "lunar-time-budget"
clock = "passive-h-maser"
clock = "mini-rafs"
steer_residual_ns = 0.5
ltc_realisation_ns = 0.05
station_height_sigma_m = 0.0
thresholds_ns = [1.0, 10.0, 100.0]
horizons_s = [3600.0, 86400.0, 604800.0, 2592000.0]

Kshana Studio で開く · GitHub で見る

lunar-time-budget.toml

kind lunar-time-budget種別の台帳の行はモデルから計算されたものです · 1 行中 0 行が外部参照で確認済み

tau グリッド上の月協定時(LTC)のエンドツーエンド時刻誤差バジェット。

kind = "lunar-time-budget"
clock = "passive-h-maser"

Kshana Studio で開く · GitHub で見る

lunar-time-offset#

モデルに基づく相対論的な地球・月間の時計レート(月座標時、LTC/TCL)です。自己ポテンシャルの差と月の運動項から LTC−TT の永年レートを求め、公表されている 56–59 µs/日の範囲とあわせて報告し、期間にわたる累積オフセットも示します。

lunar-time-offset.toml

kind lunar-time-offset名前では台帳のモジュールと対応づけられていません

月の座標時(LTC/TCL):相対論的な地球・月の時計の進み率。

kind = "lunar-time-offset"
epoch_year = 2000
epoch_month = 1
epoch_day = 1
horizon_days = 1.0

Kshana Studio で開く · GitHub で見る

lunar-vlbi#

モデルに基づく月測地VLBIの遅延観測量です。地球上の基線(二つの地上局、GCRS)が、NovaMoon クラスの月面ビーコンからの一方向信号を観測します。パスにわたって、近距離場の二距離差遅延、その変化率、波面曲率による近距離場補正を出力し、遠距離場の極限では同じコードベースの平面波 Δ-DOR 観測量と相互確認し、偏微分は有限差分で検証しています。既定の解析経路は MODELLED であり、フレームの整合性、xp=yp=0 の極運動、平面波と近距離場の違いという注意点を伴います。planetary_kernel_path、earth_orientation_kernel_path、moon_orientation_kernel_path を設定すると、代わりにカーネル経路が実行されます(DE440、MOON_PA_DE440、ITRF93。収束した太陽系重心の光行時間。そのエポックのビーコンと局の偏微分を追加)。そのニュートン力学的な遅延と偏微分は、NAIF SPICE の収束した光行時間と 0.06 ps および 7.4e-9 まで一致します。実際のVLBIデータとの照合による確認は行っていません。

lunar-vlbi.toml

kind lunar-vlbi種別の台帳の行はモデルから計算されたものです · 1 行中 0 行が外部参照で確認済み

月の測地 VLBI:月面ビーコンを観測する地球基線。

kind = "lunar-vlbi"
beacon_lat_deg = 0.0
beacon_lon_deg = 0.0
beacon_alt_m = 0.0
epoch_year = 2024
epoch_month = 1
epoch_day = 1
horizon_hours = 6.0

Kshana Studio で開く · GitHub で見る

lunar-vlbi-fim#

月面 VLBI の局座標共分散:lunar-vlbi の観測量の遅延偏微分を、明示的なスケジュール(基線 x エポック)にわたってフィッシャー情報行列に累積し、逆行列を求めて、局座標共分散と座標ごとの局シグマとして報告します。これは、仮定した等方的な g = 3 の等分配係数を通して遅延の精密度(スカラー)を押し出したものではなく、計算されたエンジン出力です。状態は地球固定(ITRS)の局座標を持つため、ヤコビアンは慣性系の偏微分を各エポックの GCRS->ITRS 行列で回転させたものです。それらの座標を可観測にするのは地球の自転であり、レポートは地球固定の視線方向の掃引とビーコンの赤緯を、仮定せずに実測します。一つの観測は、両方の局が仰角マスクより上にある(基線、エポック)の組一つで、重みは 1/delay_sigma_s^2 です。毎回の実行で、ランク、データム欠損、条件数、情報スペクトルの全体、共分散行列、局ごと・軸ごとおよび 3 次元のシグマ、自由網の零空間を報告します。ランク落ちの場合、代表シグマは、ほぼ特異な逆行列から読み取られることなく、ステータス付きで NULL として公開されます。同じスケジュールについての等分配の値 c*delay_sigma_s*sqrt(g/N) は、計算値の横に比率とともに出力され、あわせて AM-HM によって厳密な下限となる等方的なトレース境界 sqrt(p/trace(M)) も出力されます。そのため、この比率は、この仮定が捨てた異方性を表します。遅延の閉合 tau_ik = tau_ij + tau_jk により、n(n-1)/2 本の基線のうち幾何学的に独立なのは n-1 本だけです。レポートは両方の本数を示します。MODELLED:月中心の暦、局の時計、対流圏、地球姿勢パラメーターは固定され、観測は互いに独立として扱われます。したがって、この共分散は、縮約したパラメーター集合に対するクラメール・ラオ下限であり、セッション結果の予測ではありません。遅延のシグマ、局座標、スケジュールは入力です。幾何学的遅延のヤコビアンが含めない偏微分(差分化したシャピロ項)は、有限差分で測定して出力します。測地の成果物ではありません。

lunar-vlbi-fim.toml

kind lunar-vlbi-fim名前では台帳のモジュールと対応づけられていません

明示的な観測スケジュールから得た Lunar-VLBI の局座標共分散(G8、論文 D3)。

kind = "lunar-vlbi-fim"

Kshana Studio で開く · GitHub で見る

mars-pnt#

深宇宙の火星PNT:シミュレートした MARCONI リレーコンステレーション(一方向の送信と、深宇宙局への双方向の中継を行う静止軌道型と傾斜軌道型のリレー)が、一方向と双方向の電波測定を統合した推定器を通じて、基準ユーザー(transfer | lmo | surface)を航法します。エポックごとのジオメトリと可視性、真値に対する達成 RMS、形式共分散(1σ / 3σ の位置)を報告します。これはシミュレーションによる正直な性能指標であり、認証された保護レベルではありません。

mars-pnt-lmo.toml

kind mars-pnt名前では台帳のモジュールと対応づけられていません

火星 PNT — 低火星軌道のユーザーが、シミュレートした MARCONI 中継コンステレーション(一方向放送を行い、深宇宙局へ双方向を中継する静止(火星同期)中継衛星)に対し、一方向・双方向の統合放射計測融合推定器を通じて航法を行います。

kind = "mars-pnt"
user = "lmo"
clock_class = "uso"
step_s = 60.0
duration_s = 7200.0
nmax = 4
range_sigma_m = 1.0
doppler_sigma_mps = 1.0e-4

Kshana Studio で開く · GitHub で見る

mars-pnt-surface.toml

kind mars-pnt名前では台帳のモジュールと対応づけられていません

火星 PNT — 固定された地表ユーザー(自転する火星表面上のランダーまたはローバー)が、シミュレートした MARCONI 中継コンステレーションに対し、一方向・双方向の統合放射計測融合推定器を通じて航法を行います。

kind = "mars-pnt"
user = "surface"
clock_class = "uso"
step_s = 30.0
duration_s = 7200.0
nmax = 4
range_sigma_m = 1.0
doppler_sigma_mps = 1.0e-4

Kshana Studio で開く · GitHub で見る

mars-pnt-transfer.toml

kind mars-pnt名前では台帳のモジュールと対応づけられていません

火星 PNT — 火星遷移・捕獲ユーザー(高く離心率の大きい火星中心の弧。接近時や捕獲軌道で機体が飛行する長い弧)が、シミュレートした MARCONI 中継コンステレーションに対し、一方向・双方向の統合放射計測融合推定器を通じて航法を行います。

kind = "mars-pnt"
user = "transfer"
clock_class = "dsac"
step_s = 120.0
duration_s = 28800.0
nmax = 4
range_sigma_m = 1.0
doppler_sigma_mps = 1.0e-4

Kshana Studio で開く · GitHub で見る

mission-thread#

打ち上げから再突入までの、明示したミッションフェーズの連鎖についての、MODELLED の航法・タイミング誤差バジェット。打ち上げと上昇、低軌道でのランデブーとドッキング(繰り返し可)、月遷移軌道投入と地球・月間空間(シスルナー)の巡航、月周回軌道でのランデブー、降下、月面滞在、上昇、そして帰還と再突入で、各フェーズは、それぞれ固有のセンサーとフィルターを持つ、登録済みの八つの種別のうちの一つです。6x6 共分散、時計、座標系は、明示した規則(引き継ぎ、膨張、または再取得)のもとでフェーズ間を受け渡します。座標系と時間系の変換(GCRF、MCI、MCMF、UTC、TT、TDB、LTC)はそれぞれ独立したバジェット行で、月の状態は任意の DE440 カーネルの切り出しから、フォールバックとして明示した解析的な級数が使われます。任意の地上ネットワークのオーバーレイが、各フェーズの追尾デューティを設定します。報告するのは、フェーズごとのバジェット(入口、ピーク、出口の 1-sigma と、単位付きのすべての寄与)、明示した要求に対する余裕、最弱の連結、イベント、そしてタイムライン図です。MODELLED:すべての数値は明示した入力であり、連鎖は一つのスタックに従い、機体はモデル化していません。公開情報のみを使用しており、いかなる機関とも提携せず、承認も受けていません。助言用ソフトウェアであり、認証を受けた航法装置ではありません。

mission-thread-artemis-class.toml

kind mission-thread名前では台帳のモジュールと対応づけられていません

Artemis クラスのミッションスレッド:打ち上げから大気圏再突入までの一連のフェーズの航法・タイミング誤差バジェット。公開されている運用構想の資料から構築しています。

kind = "mission-thread"
title = "Artemis-class mission thread (ILLUSTRATIVE)"
seed = 20261024
epoch_utc = "2028-01-01T00:00:00Z"
moon_kernel_path = "tests/fixtures/mission_thread/de440s_moon_2028-01-01_2028-04-01.bsp"
min_elevation_deg = 10.0
handover_gap_s = 120.0
step_s = 300.0

まだ GitHub にはありません

mission-thread-short.toml

kind mission-thread名前では台帳のモジュールと対応づけられていません

バイナリ単体で実行できる短いミッションスレッド:打ち上げと上昇、低軌道でのランデブー1回、1日間の月遷移軌道の巡航、帰還と再突入を、解析級数による月の位置(カーネルファイルなし)で扱います。チェックアウトから切り出した月カーネルを読み込む mission-thread-artemis-class に同梱される対となるものです。

kind = "mission-thread"
title = "Short mission thread, launch to entry (ILLUSTRATIVE)"
seed = 20261028
epoch_utc = "2028-01-01T00:00:00Z"
frame = "gcrf"
x = [5285007.866, 1880185.649, 3025316.817, -137.105, 385.389, 0.0]
sigma_pos_m = 10.0
sigma_vel_mps = 0.01

Kshana Studio で開く · GitHub にはまだありません

moonlight-service-volume#

ILLUSTRATIVE(例示用)の、公開情報に基づく Moonlight/LCNS クラスの月周回コンステレーション(ESA とは無関係)を用いた、モデルに基づく月航法サービスボリューム解析です。時間範囲にわたって月面の緯度・経度グリッドを掃引し、DOP、カバレッジ、可用性(≥4 機かつ PDOP がしきい値未満)と、そのボリュームにわたる一般化した月 ARAIM 保護レベル(HPL/VPL)の包絡を報告します。DOP のジオメトリは gnss_lib_py で VALIDATED なカーネル(crate::orbit::dop)を再利用し、保護レベルは LunaNet LNIS の月 ARAIM の仕組み(crate::lunar、σ_URE≈30 m)を再利用して、既存の南極 PL を特殊な場合として含みます。MODELLED の構成:円軌道・楕円ケプラー軌道のリレー群(実際の微分補正された LCNS/NRHO エフェメリスではありません)と、平均自転の月(秤動や歳差する極はなし)。決定論的(純粋なジオメトリ)。TRL・飛行実績・機関による承認はありません。

moonlight-service-volume.toml

kind moonlight-service-volume名前では台帳のモジュールと対応づけられていません

月の航法サービスボリュームの解析 — Moonlight / LCNS クラスのコンステレーション。

kind = "moonlight-service-volume"
n_sats = 8
sma_km = 9737.4
eccentricity = 0.6
inc_deg = 57.7
argp_deg = 90.0
lat_min_deg = -90.0
lat_max_deg = -60.0

Kshana Studio で開く · GitHub で見る

ntn-positioning#

移動衛星サービス(MSS)S帯(3GPP バンド n256、ダウンリンク 2170 ~ 2200 MHz、既定のキャリア 2172.5 MHz)における5G非地上系ネットワーク(NTN)ダウンリンクからの測位です。各信号(既定では、占有 4.5 MHz の 5 MHz New Radio チャネルと、占有 180 kHz の 200 kHz 狭帯域チャネル)について、到達時刻のクラメル・ラオ限界(CRB)c / (2 pi beta sqrt(2 (C/N0) T))(beta は平坦な OFDM スペクトルの二乗平均平方根(ガボール)帯域幅 B/sqrt(12))と、複素トーンのドップラーの限界 sqrt(3 / (2 pi^2 (C/N0) T^3)) を求めます。続いて、任意のLEOコンステレーションにわたり、未知の受信機クロックを含むダウンリンク到達時刻の測位解(シード付きで、限界とネットワーク同期誤差を sigma とする)、その PDOP と形式的な3次元 sigma、そして高度を固定した最長パスでの単一衛星ドップラー測位解を求めます。MODELLED:帯域幅から限界への段階は教科書的な閉形式であり、平坦な帯域制限BPSKスペクトルの数値積分に照らして確認しています(内部整合性であり、公表された具体的な数値には固定していません)。測位精度は、同期誤差を明示した、マルチパスのないチャネル上での限界であり、達成した結果ではありません。

ntn-5g-positioning.toml

kind ntn-positioning名前では台帳のモジュールと対応づけられていません

移動衛星 S バンドの 5G 非地上系ネットワーク(NTN)ダウンリンクからの測位。

kind = "ntn-positioning"
seed = 5
carrier_hz = 2172.5e6
integration_s = 0.1
doppler_integration_s = 1.0
sync_error_m = 1.0
duration_s = 600.0
step_s = 10.0

Kshana Studio で開く · GitHub で見る

oem-interop#

CCSDS OEM 相互運用ブリッジ:外部の飛行力学ツール(GMAT/Orekit/STK はいずれも OEM を出力します)が生成した Orbit Ephemeris Message を取り込み、そのセグメント、オブジェクト、座標系、エポック範囲と、速度の整合性チェックを報告します。入力がない場合は、生成した基準軌道を往復変換し、取り込みと書き出しの忠実度を報告します。MODELLED の構造的・物理的な取り込みチェックであり、元データの軌道精度の確認では「ありません」。

oem-interop.toml

kind oem-interop名前では台帳のモジュールと対応づけられていません

CCSDS OEM 相互運用ブリッジのデモンストレーター(GMAT / Orekit / STK との相互運用)。

kind = "oem-interop"

Kshana Studio で開く · GitHub で見る

optical-atmosphere#

大気を通る MODELLED の光PNTです。光リンクと、雲の気候を明示した地上局の集合について、波長と仰角に依存する晴天時の損失(Kim の視程則に Rayleigh を加えたもの)、Hufnagel-Valley の乱流状態(Rytov 分散、シンチレーション指数、ガンマ・ガンマのパラメーター、開口平均化)、リンクマージンに対する天候に左右される可用性(対数正規の液水気候から求めた雲の光学的厚さ、幾何光学的な減衰、独立した乱流フェージング)、目標の可用性に必要なリンクマージン、途絶時間の分布、時計のホールドオーバーモデルを通じた途絶ごとのタイミング誤差と測距誤差の増大、距離に相関するサイトダイバーシティの可用性、そして改善手法(波長、受信開口、補償光学によるシンチレーション低減、追加マージン)を用いた場合の利得の仮定計算を報告します。次の項目は、示した式の実装として、独立した mpmath のオラクルに照らして VALIDATED です:Rytov 分散、シンチレーション指数、ガンマ・ガンマのフェード確率、開口平均化係数、雲および晴天時の光学的厚さ。MODELLED:天候、手法、時計のすべての入力と、独立性およびコピュラの仮定。測定した可用性の記録との比較は行っていません。助言としての解析であり、認証を受けた可用性または航法の製品ではありません。

optical-atmosphere-network.toml

kind optical-atmosphere名前では台帳のモジュールと対応づけられていません

大気を通した光学 PNT:ILLUSTRATIVEの三つの地上サイト(雲の多い北部サイト、中間の中部サイト、晴天の多い南部サイト)から、仰角 30 度、1550 nm で LEO の光学端末を見る場合です。雲の気候は設定した入力であり、測定値でも特定のデータセットの値でもないため、以下の可用性はすべて MODELLED です。実行では、サイトごとに、晴天時の損失、Hufnagel-Valley の乱流状態、リンクマージンに対する可用性、40 / 50 / 60 / 70 パーセントに必要なマージン(光リンクは厚い雲を通過できないため、どのマージンでも引き上げられない可用性の上限がサイトごとにあり、サイトごとに報告されます)、停止時間の分布、三種類の時計クラスについての停止ごとの時刻誤差の増大を報告し、続いて、独立した天候と距離相関のある天候(500 km の相関長)のもとで、最良の 1、2、3 サイトのサイトダイバーシティによる可用性を報告します。

kind = "optical-atmosphere"
wavelength_nm = 1550.0
elevation_deg = 30.0
availability_targets_pct = [40.0, 50.0, 60.0, 70.0]
tx_power_w = 0.5
tx_aperture_m = 0.1
rx_aperture_m = 0.4
range_km = 1000.0

Kshana Studio で開く · GitHub で見る

optical-atmosphere-techniques.toml

kind optical-atmosphere名前では台帳のモジュールと対応づけられていません

ILLUSTRATIVEの一つの地上サイトに対する強化手法のもしも分析:波長の変更、受信開口の拡大、補償光学によるシンチレーション低減、追加マージン。それぞれ、同じサイトのベースラインに対する可用性の向上として予測します。向上分は設定した入力です(Kshana は補償光学ループをモデル化しません)。新しい波長や開口では、晴天時のバジェット、晴天時の損失、開口平均化を再評価し、すべては MODELLED です。端末は、手法の効果が表れるよう、意図的にマージンを制限しています(大気の手前で約 3 dB)。実行では、どの手法でも引き上げられない雲の上限も示します。マージン表の 100 パーセント未満の目標は、必要な追加マージンとして報告します(負の値は余裕があることを示します)。

kind = "optical-atmosphere"
wavelength_nm = 1550.0
elevation_deg = 25.0
availability_targets_pct = [50.0, 60.0, 70.0]
tx_power_w = 0.5
tx_aperture_m = 0.1
rx_aperture_m = 0.3
range_km = 1000.0

Kshana Studio で開く · GitHub で見る

orbit#

衛星コンステレーション(Walker / TLE / RINEX)による GNSS の可用性と DOP。

orbit-gnss-challenged.toml

kind orbit名前では台帳のモジュールと対応づけられていません

軌道ジオメトリから導いた GNSS の可用性(手書きのウィンドウではない)。

kind = "orbit"
seed = 7
threshold_ns = 5.0
mask_deg = 10.0
sigma_uere_m = 1.0
step_s = 60.0
duration_s = 86400.0
altitude_km = 8000.0

Kshana Studio で開く · GitHub で見る

orbit-molniya.toml

kind orbit名前では台帳のモジュールと対応づけられていません

高離心率(モルニヤ)ユーザーの GNSS の可用性、軌道ジオメトリから。

kind = "orbit"
seed = 11
threshold_ns = 5.0
mask_deg = 5.0
sigma_uere_m = 1.0
step_s = 120.0
duration_s = 43200.0
altitude_km = 20229.0

Kshana Studio で開く · GitHub で見る

orbit-multignss.toml

kind orbit名前では台帳のモジュールと対応づけられていません

軌道ジオメトリによるマルチ GNSS の可用性:GPS + Galileo の併用。

kind = "orbit"
seed = 7
threshold_ns = 5.0
mask_deg = 10.0
sigma_uere_m = 1.0
step_s = 60.0
duration_s = 86400.0
altitude_km = 8000.0

Kshana Studio で開く · GitHub で見る

orbit-real-tle.toml

kind orbit名前では台帳のモジュールと対応づけられていません

二行軌道要素セットによる、実際の衛星ジオメトリからの GNSS の可用性。

kind = "orbit"
seed = 13
threshold_ns = 10.0
mask_deg = 5.0
sigma_uere_m = 1.0
step_s = 120.0
duration_s = 43200.0
altitude_km = 500.0

Kshana Studio で開く · GitHub で見る

orbit-rinex.toml

kind orbit名前では台帳のモジュールと対応づけられていません

実際の RINEX 3 放送エフェメリスからの GNSS の可用性。

kind = "orbit"
seed = 13
threshold_ns = 10.0
mask_deg = 5.0
sigma_uere_m = 1.0
step_s = 120.0
duration_s = 43200.0
altitude_km = 500.0

Kshana Studio で開く · GitHub で見る

orbit-sgp4-gps.toml

kind orbit名前では台帳のモジュールと対応づけられていません

SGP4/SDP4 で伝搬した実際の GPS コンステレーションからの GNSS の可用性。

kind = "orbit"
seed = 17
threshold_ns = 10.0
mask_deg = 5.0
sigma_uere_m = 1.0
step_s = 120.0
duration_s = 43200.0
altitude_km = 500.0

Kshana Studio で開く · GitHub で見る

orbit-urban-canyon-skyline.toml

kind orbit名前では台帳のモジュールと対応づけられていません

都市の街路の底での GNSS の可用性と精度低下率(DOP):city-street スカイラインプリセットのもとで、地上サイトのユーザー(user_site)を置いた orbit kind。

kind = "orbit"
seed = 7
threshold_ns = 5.0
mask_deg = 5.0
sigma_uere_m = 1.0
step_s = 300.0
duration_s = 86400.0
lat_deg = 52.0

Kshana Studio で開く · GitHub で見る

passes#

地上局のパス予測:円軌道(ウィンドウ開始時点の SGP4 平均要素)について、ウィンドウにわたり仰角マスクより上にある局に対する時間領域の可視パス(AOS/TCA/LOS、最大見かけ仰角、継続時間)と総アクセス時間を求めます。IAU 2006/2000A の地球固定座標系上の SGP4/SDP4 伝播(任意で UT1 - UTC と極運動)、ITU-R P.834-9 の対流圏屈折とダウンリンクの光行時間(どちらも既定でオン)を用い、交差は 1e-7 s まで解き、最大仰角は黄金分割探索で求めます。パスのジオメトリは、海面高度の局で Orekit 13.1.8 と照合して VALIDATED であり、シナリオの軌道と局は例示用の入力です。

passes.toml

kind passes種別に、外部参照で確認済みの台帳の行があります · 1 行中 1 行が確認済み

地上局のパス予測のデモンストレーター(地上セグメントと運用)。

kind = "passes"
altitude_km = 550.0
inclination_deg = 97.6
raan_deg = 0.0
arg_lat_deg = 0.0
station_lat_deg = 52.2
station_lon_deg = 4.4
station_alt_m = 0.0

Kshana Studio で開く · GitHub で見る

pvt#

実観測による単独測位:RINEX 3 の観測ファイルと放送航法ファイル(コード疑似距離、放送エフェメリス、Klobuchar 電離層、Saastamoinen/Niell 対流圏)から受信機の位置を解き、必要に応じて測量済みの座標と照合して確認します。

pvt-abmf.toml

kind pvt名前では台帳のモジュールと対応づけられていません

測量済みの IGS 観測局の実観測による単独測位(SPP)。

kind = "pvt"
mask_deg = 5.0
dual_frequency = true
truth_ecef = [2919786.4480, -5383745.1780, 1774604.7340]
obs_rinex = """
nav_rinex = """

Kshana Studio で開く · GitHub で見る

quantum-anomaly-detect#

量子PNTシステムのための MODELLED の故障・異常検出:ラベル付きの故障カタログ(時計の周波数ジャンプ/ドリフト/ロック喪失、センサーのバイアスステップ/ドロップアウト)、検出統計量の ROC AUC(外部で確認済みの eval_stats によるブートストラップ信頼区間付き)、固定の誤警報率での最小検出可能故障を扱い、量子時計支援モニター(低ノイズ)がより小さな故障を検出することを、正直な TradeEvidence と代表性として示します。ガウス型の検出統計量モデル(AUC = Phi(mu/(sigma*sqrt2)))。このクラスをモデル化し、パラメーターは公開情報に基づく例示用で、TRL・飛行実績・認証はありません。

quantum-anomaly-detect.toml

kind quantum-anomaly-detect名前では台帳のモジュールと対応づけられていません

量子 PNT システムの故障・異常検出 — ラベル付き故障カタログ、ROC AUC、最小検出可能故障、量子時計支援と従来型モニターの比較。MODELLED。公開情報源に基づく例示用パラメーター。クラスをモデル化するものであり、TRL や飛行実績の主張はしません。

kind = "quantum-anomaly-detect"
fault_mu = 1.0
quantum_sigma = 0.3
classical_sigma = 1.0
pfa = 1.0e-3
pd = 0.9
samples = 2000
seed = 42

Kshana Studio で開く · GitHub で見る

quantum-gnss-free-nav#

MODELLED のGNSSに依存しない量子航法:GNSS途絶中の、量子(冷却原子干渉計)慣性バジェットと古典的な航法級 INS の比較です。コースト中の位置誤差の増大、位置しきい値までのホールドオーバー、そして量子と古典のトレードを、代表性とともに正直な TradeEvidence として示します。観測可能性に関する正直な注記:外部の測位解がなければ加速度計のバイアスは観測できないため、誤差は増大します。量子センサーはその増大を遅らせますが、差を埋めることはできません。デバイスのパラメーターは公開情報に基づく例示用で、このクラスをモデル化したものであり、TRL・飛行実績・認証はありません。

quantum-gnss-free-nav.toml

kind quantum-gnss-free-nav名前では台帳のモジュールと対応づけられていません

GNSS に依存しない量子航法 — GNSS 途絶中の、量子(冷却原子干渉計)と従来型の航法級 INS による推測航法の比較。MODELLED。公開情報源に基づく例示用のデバイスパラメーター。クラスをモデル化するものであり、TRL や飛行実績の主張はしません。

kind = "quantum-gnss-free-nav"
outage_s = 300.0
threshold_m = 100.0

Kshana Studio で開く · GitHub で見る

quantum-time-transfer#

MODELLED の信頼できる量子タイミングチェーン:エンドツーエンドの量子(光格子時計+もつれ/単一光子リンク)と古典(CSAC+RF 双方向)の時刻比較バジェット、再利用したタイミング保護レベルと遅延・リプレイ攻撃のセキュリティ性能指標(1-P_md)、時計異常の検出確率と CUSUM の遅延、そして量子と古典のトレードを、代表性と飛行に至るまでのギャップの記録とともに正直な TradeEvidence として示します。デバイス/リンクのパラメーターは公開情報に基づく例示用で、このクラスをモデル化したものであり、TRL・飛行実績・認証は主張しません。

quantum-time-transfer.toml

kind quantum-time-transfer名前では台帳のモジュールと対応づけられていません

信頼できる量子タイミング — エンドツーエンドの時刻伝送チェーン、安全な配信、異常検出、量子と従来型のトレードオフ。MODELLED。公開情報源に基づく例示用のデバイス・リンクのパラメーター。クラスをモデル化するものであり、TRL や飛行実績の主張はしません。

kind = "quantum-time-transfer"
integration_s = 1.0
dissemination_interval_s = 100.0
link_loss_db = 30.0
classical_link_sigma_s = 1.0e-9
monitor_pfa = 1.0e-3
attack_delay_s = 5.0e-9
clock_fault_sigma = 4.0

Kshana Studio で開く · GitHub で見る

quantum-trade#

量子と古典の PNT トレード(13503):候補の時計(実測 ADEV 曲線 — 防御可能性の要 — または量子時計クラス)が古典のベースラインクラスに対してもたらす、タイミングホールドオーバーと慣性ホールドオーバーの利益です。長い tau のフロアを仮定したことの注意点を成果物に添え、さらに GNSS を使えない状況でのレジリエンス対時間の包絡も示します。MODELLED。パートナーのデバイスを定量化するだけで、確認はしません。候補の時計は、実測曲線(candidate_adev_taus と candidate_adev_values、同じ長さで、少なくとも 2 点。両方の形式が与えられた場合はこちらが優先)または candidate_clock_class です。

quantum-trade.toml

kind quantum-trade種別の台帳の行はモデルから計算されたものです · 1 行中 0 行が外部参照で確認済み

実測 ADEV の取り込みを伴う量子と古典の PNT トレード(ESA AO/1-13503 デモンストレーター)。

kind = "quantum-trade"
timing_threshold_s = 20.0e-9
position_threshold_m = 100.0
baseline_clock_class = "csac"
candidate_adev_taus   = [1.0, 10.0, 100.0, 1000.0, 10000.0, 100000.0]
candidate_adev_values = [5.0e-16, 1.6e-16, 6.0e-17, 4.0e-17, 6.0e-17, 2.0e-16]
resilience_times_s = [1.0, 60.0, 600.0, 1800.0, 3600.0, 7200.0, 14400.0, 28800.0]

Kshana Studio で開く · GitHub で見る

realtime-frame-eop#

リアルタイムの月フレーム・地球姿勢の予測バジェット:P4 表 1(フレーム誤差の整合性チェック — 後処理 ~0.27 m ↔ ~0.010 ms とリアルタイム ~15 m ↔ ~0.5 ms。各フレーム位置を L19 のレバーアーム Δr = D_EM·ω⊕·ΔUT1 により等価な UT1 誤差として表現)と表 2(予測期間に対する UT1 予測誤差の実測 — 実際の IERS finals2000A 系列から直接読み取った L18 の曲線。Bulletin A − Bulletin B の最終フロアと複数日の持続予測器の誤差を、それぞれ L19 で月フレームの位置に変換)、さらに L21 の二乗和平方根によるリアルタイムのフレーム誤差バジェット(EOP+エフェメリス+実現フロア)です。閉形式(L19 のレバーアーム、ω⊕ は CIO の地球自転角と相互確認)は VALIDATED、実データ(実際の finals2000A の行から読み取った L18 曲線)も VALIDATED です。MODELLED は、月リレーの OD 共分散の大きさとフレーム実現フロア(代表的な配分)、および持続予測器(IERS の運用用 Bulletin A のアルゴリズムではありません)です。認証を受けたリアルタイムのフレーム製品ではありません。

realtime-frame-eop.toml

kind realtime-frame-eop名前では台帳のモジュールと対応づけられていません

リアルタイムの月座標系 / 地球姿勢(EOP)予測バジェット。

kind = "realtime-frame-eop"
epoch = "2022-01-01"
horizons_days = [1, 2, 3]

Kshana Studio で開く · GitHub で見る

reentry#

Allen-Eggers の弾道再突入回廊:指数大気中の、突入速度・飛行経路角・弾道係数に対する、最大減速度(弾道係数に依存しない V_e^2 sin|γ|/(2eH))、最大 g での速度と高度、最大加熱の速度。さらに、重力、地球の曲率、US Standard Atmosphere 1976 を含む同じ弾道突入の平面質点積分(最大減速度、速度、高度と、最大時の時刻)も求めます。MODELLED の弾道(揚力なし)突入であり、加熱の出力は最大加熱の速度であって、熱流束ではありません(空力加熱・TPS モデルなし)。

reentry.toml

kind reentry種別の台帳の行はモデルから計算されたものです · 1 行中 0 行が外部参照で確認済み

弾道再突入回廊のデモンストレーター(Allen-Eggers、ミッション解析)。

kind = "reentry"
entry_velocity_m_s = 7800.0
flight_path_angle_deg = 6.0

Kshana Studio で開く · GitHub で見る

slot-timing#

スロットタイミング:自由走行する時計が、時刻で割り当てられたルーティングまたはタスク割り当てのスロットのガード(スロットが許容する最大の絶対時刻誤差)から外れるまでの秒数、その時点での各項の寄与(支配的な項を明示:測位解の不確かさ、ホワイト位相雑音、ホワイト・フリッカー・ランダムウォーク・ランダムランの周波数雑音、残留周波数オフセット、温度、経年変化)、最後の測位解からの残り時間、測位解の遅延を差し引いて時計をスロット内に保つ最大の測位解間隔を求めます。発振器は、クラスの既定値(csac、uso、dsac、tcxo、ocxo、rafs:引用した一秒のアラン偏差一つと、仮定した赤色雑音フロア)、通信タイミングのデータシートのプリセット、インラインのデータシート(包絡としてフィットしたアラン偏差の最大値と、経年変化および温度係数)、またはインラインのMEASURED位相記録(重複アラン偏差を、ホワイト位相と IEEE Std 1139 の周波数変調の基底で重み付き最小二乗によりフィットするため、赤色雑音フロアは仮定ではなく実測となります)のいずれかです。データシートまたは記録が対応する最長の平均化時間を超える逸脱は、外挿として示します。任意のスプーフィングのセクションでは、軌道上の受信機のタイミング保護レベルを加えます:軌道速度と周期、単一の地上スプーファーがパスごとに衛星へ届く時間、時計支援モニターのフロアと CUSUM の検出遅延、条件付きの限界、指定した最大ランプレートのスプーファーが、衛星がその到達範囲を離れるか独立した確認が行われるまでに蓄積する引き込み量、そして各地上接触またはクロスリンクの確認がそのスプーファーから独立しているかどうかです。VALIDATED:当てはめた記録からのホールドオーバー逆算は、水素メーザーに対して測定した実際のセシウム時計でホールドアウトしています(tests/slot_timing_cs5071a_holdout.rs、データ条件付き)。実測の水晶発振器では、ホールドアウトした予測は保守的ですが、基準には収まらないため、水晶の場合は MODELLED です。MODELLED:クラスとデータシートの出典、決定論的な項、そしてスプーフィングの評価。

slot-timing-ocxo-leo.toml

kind slot-timing名前では台帳のモジュールと対応づけられていません

スロットタイミング:低軌道の小型衛星に搭載した恒温槽付き水晶発振器(OCXO)が、最後の全球測位衛星システム(GNSS)の測位解から、時刻でインデックス付けされたルーティングスロットのガード内にどれだけ留まれるか、またどれだけの頻度で測位解が必要か。

kind = "slot-timing"
preset = "ocxo"
guard_ns = 100.0
k_sigma = 3.0
fix_sigma_ns = 10.0
elapsed_since_sync_s = 600.0
fix_latency_s = 5.0
temperature_excursion_k = 2.0

Kshana Studio で開く · GitHub で見る

solar-system#

ある一つのエポックにおける太陽系全体を、任意の天体の周りの PNT(測位・航法・時刻)のために扱います。太陽、八つの惑星、冥王星、月、Phobos、Deimos、Io、Europa、Ganymede、Callisto、Titan について、ICRF(国際天文基準座標系、赤道 J2000)での太陽中心の位置と速度、太陽中心距離と J2000 黄道経度・緯度、重力定数、赤道半径と平均半径、公表されている場合は J2 とその基準半径、恒星自転周期、IAU の極とエポックでの本初子午線、一周にわたってサンプリングした軌道トラック(惑星は太陽中心、衛星は親天体中心)、そして観測者の天体(既定は地球)からの光行時間、片方向と双方向の距離、太陽の Shapiro 遅延、太陽との離角を報告します。追加の from/to リンクにも同じ処理を行います。位置:Standish と Williams による JPL のケプラー要素(1800 AD ~ 2050 AD は表 1、3000 BC ~ 3000 AD は表 2a/2b)と各惑星の公称誤差、地球と月の分離には Montenbruck & Gill の月の級数、火星と木星のガリレオ衛星には IAU の同期自転レートを用いた JPL の平均要素、Titan には IAU の自転モデルを使います。光行時間:放射測定の不動点解法で、送信側は遅延位置。ニュートン力学的で、Shapiro 遅延は別に報告します。公称誤差の二倍以内で JPL Horizons(DE441)と照合して VALIDATED:水星から土星および地球は表 1(最悪で公称の 1.87 倍)、八つの惑星すべては表 2a/2b(最悪で 1.71 倍)、そして地球から火星と木星への光行時間。MODELLED、各行にラベル付き:表 1 の天王星と海王星(DE441 に対する公称誤差の 2.0 倍と 5.2 倍)、冥王星(1992 の行。誤差の記載なし)、月と七つの衛星(Horizons に対して測定、公表された限界なし)。

solar-system-tour.toml

kind solar-system名前では台帳のモジュールと対応づけられていません

一つのエポックにおける太陽系全体。

kind = "solar-system"
epoch = "2026-09-28T00:00:00"
observer = "Earth"
track_points = 180
from = "Mars"
to = "Jupiter"
from = "Saturn"
to = "Earth"

Kshana Studio で開く · GitHub で見る

space-packet#

CCSDS 133.0-B スペースパケットプロトコルのフレーミング:合成した TM/TC のパケットストリーム(6オクテットのプライマリヘッダー+データフィールド)を符号化し、パケットごとのヘッダーのデコード、総オクテット数、符号化とデコードの厳密な往復を報告します。決定論的で厳密なビットレイアウトのフレーミングであり、機関のパケット形式の相互運用層です。適合性の認証ではありません(フラグ以外のセカンダリヘッダー、CRC、セグメンテーションの処理はありません)。

space-packet.toml

kind space-packet種別に、外部参照で確認済みの台帳の行があります · 1 行中 1 行が確認済み

CCSDS 133.0-B スペースパケットのフレーミングのデモンストレーター(TM/TC の相互運用)。

kind = "space-packet"
apid = 100
telecommand = false
packet_count = 4
data_len = 32

Kshana Studio で開く · GitHub で見る

space-weather#

宇宙天気の環境モデル:太陽(F10.7/F10.7a)と地磁気(Kp。定義上の Kp↔ap 表付き)の活動指数、それらが決める Jacchia-1971 の外圏温度(公表された太陽活動極小・平均・極大の値と照合して確認済み)、そして、昼夜平均の外圏温度での Jacchia-1971 の熱圏中性大気密度を、活動を含まない静的プロファイルと複数の高度で比較したもの — 静的な大気が省略している太陽周期による密度の依存性です。MODELLED:密度は、加速度計から導いた密度(TOLEOS の CHAMP と GRACE)と、太陽活動極大期には 2 倍以内で一致しますが、2008 年の太陽活動極小期には約 1.7 倍密すぎます。

space-weather.toml

kind space-weather種別の台帳の行はモデルから計算されたものです · 1 行中 0 行が外部参照で確認済み

宇宙天気環境モデルのデモンストレーター。

kind = "space-weather"
kp = 4.0
altitudes_km = [300.0, 400.0, 500.0, 600.0, 800.0]

Kshana Studio で開く · GitHub で見る

spectrum#

Lバンドのスペクトルモデルとウォーターフォール:GNSS の L バンド全体を一つの電力スペクトル密度(PSD)として、横軸を周波数、縦軸を時間とし、台本どおりのジャマーのタイムラインにわたって示します。信号:GPS L1 C/A と L2C(BPSK(1))、Galileo E1 オープンサービス(MBOC(6,1,1/11)、または BOC(1,1))、GPS L5 と Galileo E5a(BPSK(10))で、それぞれの搬送波に、上書きしない限りインターフェース仕様の最小受信電力(IS-GPS-200、IS-GPS-705、Galileo OS SIS ICD)を与えます。GLONASS、BeiDou、Galileo E6 はモデル化していません。ジャマー:連続波トーン、平坦な狭帯域雑音、線形のこぎり波チャープ、各バンド自身の変調に合わせた広帯域雑音で、それぞれ中心、帯域幅、受信電力(直接指定、またはジャミングの種類の自由空間伝搬損失を通した EIRP と距離)、オン/オフ時刻を持ちます。各ジャマーは、受信機帯域幅にわたるスペクトル分離係数 kappa によって各バンドに対して評価され、(C/N0)_eff = [1/(C/N0) + sum (J/S) kappa]^-1 となります。ジャマーが一台の場合、これは Q = 1/(R_c kappa) としたジャミングの種類の耐ジャム式と等しく、レポートはこの相互確認(とその横にジャミングの種類の代表的な Q の値)を載せます。雑音フロアは k T_sys で、T_sys = T_ant + 290 K (F - 1) です。ウォーターフォールは各セルをそのビンと行にわたって平均します(チャープは厳密に、掃引全体と部分的な掃引を合わせて。行の途中で切り替わるジャマーはそのデューティで)。そのため C/N0 のタイムラインと画像は同じ数値から得られます。result.json は、電力でブロック平均したグリッド、行ごとのバンド別 C/N0 と J/S、そしてジャマーごと・バンドごとの SSC、Q、J/S、帯域内 J/S、定常 C/N0 を保持します。任意の [iq]:ある一時点でのモデルを複素 IQ として描き、SigMF 記録(cf32_le または ci16_le)に書き出して読み戻し、Welch 推定と比較します。任意の [recording](ネイティブビルド):実際の SigMF 記録の Welch PSD をモデルの横に示します。VALIDATED:信号の PSD は教科書的な主ローブ幅(BPSK(n) は零点間で 2n x 1.023 MHz、BOC(1,1) のローブは +/-1.023 MHz を中心)に照らして、スペクトル分離係数はその Parseval の閉形式と Kaplan & Hegarty の Q = 1(CW)および 1.5(整合)に照らして確認しています。MODELLED:ジャマーの電力、タイムライン、フロントエンドの帯域幅、連続スペクトル(符号線なし)の扱い、そして AGC、ブランキング、アンテナパターンを含まないこと。

l-band-waterfall-jamming.toml

kind spectrum名前では台帳のモジュールと対応づけられていません

ジャミング下の L バンドウォーターフォール:全球測位衛星システム(GNSS)の L バンド全体を 一つの電力スペクトル密度(PSD)として、横軸に周波数、縦軸に時間をとって示し、その間にスクリプトで定めた順序でジャマーが次々にオンになります。

kind = "spectrum"
seed = 7
duration_s = 60.0
step_s = 1.0
noise_figure_db = 2.0
antenna_temp_k = 290.0
tracking_threshold_dbhz = 25.0
f_min_mhz = 1160.0

Kshana Studio で開く · GitHub で見る

leo-resilience-js-margin.toml

kind spectrum名前では台帳のモジュールと対応づけられていません

受信電力から見た LEO-PNT のレジリエンス:ジャマー対信号(J/S)マージン。

kind = "spectrum"
seed = 12
duration_s = 100.0
step_s = 1.0
noise_figure_db = 2.0
antenna_temp_k = 290.0
tracking_threshold_dbhz = 25.0
f_min_mhz = 1150.0

Kshana Studio で開く · GitHub で見る

multi-band-jamming-waterfall.toml

kind spectrum名前では台帳のモジュールと対応づけられていません

マルチバンドのジャミングウォーターフォール:四つの周波数帯(UHF、L、S、C)の低軌道(LEO)測位・航法・時刻(PNT)信号を GPS および Galileo とともに取り上げ、各周波数帯に固有のジャマーを置いて、一つのタイムライン上に周波数帯ごとのウォーターフォールとして描画します。

kind = "spectrum"
seed = 11
duration_s = 60.0
step_s = 1.0
noise_figure_db = 2.0
antenna_temp_k = 290.0
tracking_threshold_dbhz = 25.0
f_min_mhz = 1160.0

Kshana Studio で開く · GitHub で見る

spoof#

モンテカルロによる P_fa/P_md を伴う、確率的な時刻スプーフィング検出器(Neyman–Pearson / χ²₁)。

spoof-attack.toml

kind spoof名前では台帳のモジュールと対応づけられていません

能動的な時刻スプーフィング攻撃:各時計のインテグリティモニターは、被害が出る前にスプーフィングを捉えられるか。

kind = "spoof"
threshold_ns = 20.0
step_s = 10.0
duration_s = 660.0
start_s = 60.0
rate_ns_per_s = 0.1
id = "optical-sr-lattice"
provenance = "Strontium optical lattice clock, space-oriented goal sigma_y(1s)=1e-15 (arXiv:1503.08457); not flown."

Kshana Studio で開く · GitHub で見る

spoof-meaconing.toml

kind spoof名前では台帳のモジュールと対応づけられていません

攻撃の形を明示した時刻スプーフィング検出と、確率的な検出器。

kind = "spoof"
threshold_ns = 0.5
step_s = 1.0
duration_s = 1200.0
start_s = 100.0
target_pfa = 0.001
mc_runs = 20000
kind = "meaconing"

Kshana Studio で開く · GitHub で見る

spoof-detect#

RF と測定値を組み合わせたスプーフィング検出器(複数 SV の RAIM 整合性 + AGC + SQM を融合)を、パラメーター化した攻撃(電力優位、搬送波位相の整合、時刻・位置の押し出し;TEXBAT 方式)に対して評価します。

maritime-spoof-position-push.toml

kind spoof-detect名前では台帳のモジュールと対応づけられていません

海上の GNSS スプーフィング:船の報告位置を引きずる送信機の検出。

kind = "spoof-detect"
power_advantage_db = 2.0
carrier_aligned = false
push = "position"
push_magnitude_m = 500.0
num_biased = 4
el_imbalance = 0.12
sat_power_dbm = -130.0

Kshana Studio で開く · GitHub で見る

spoof-detect.toml

kind spoof-detect名前では台帳のモジュールと対応づけられていません

RF と測定の複合スプーフィング検出器:複数 SV の RAIM 整合性 + AGC + SQM を融合。

kind = "spoof-detect"
power_advantage_db = 1.5
carrier_aligned = false
push = "position"
push_magnitude_m = 75.0
num_biased = 3
el_imbalance = 0.12
sat_power_dbm = -130.0

Kshana Studio で開く · GitHub で見る

sweep#

クロックパックのパラメーターに対する1次元のトレードスタディ掃引。

sweep-clock-stability.toml

kind sweep名前では台帳のモジュールと対応づけられていません

トレードスタディ:ホールドオーバーは時計の安定度に応じてどう変わるか。

kind = "sweep"
parameter = "classical_q_wf"
metric = "holdover_s"
start = 1.0e-24
stop = 1.0e-18
steps = 25
scale = "log"
seed = 42

Kshana Studio で開く · GitHub で見る

sweep-nd#

ドット区切りの TOML キーまたは JSON メトリクスパスによる、任意のパックに対する汎用の N 次元掃引。

sweep-nd-inertial.toml

kind sweep-nd名前では台帳のモジュールと対応づけられていません

あらゆるシナリオ kind に使える汎用の N 次元パラメーター掃引。時計専用の sweep kind とは異なり、sweep-nd は [base] シナリオのドット区切りの TOML キーを軸のデカルト積にわたって変化させ、各グリッドノードを再実行し、選んだメトリクスを結果からドット区切りの JSON パスで読み出します。TOML と結果の境界で動作し、パックごとの Rust 型には依存しないため、すべてのパック(inertial、gnss-ins、integrity、spoof など)で動作します。ネイティブ実行ではグリッドを並列に評価し(追加の依存関係はありません)、wasm では逐次実行にフォールバックします。出力グリッドは決定的で、行優先です(最後の軸が最も速く変化します)。

kind = "sweep-nd"
metrics = ["classical.fom.holdover_s", "classical.fom.pos_rms_m"]
key = "threshold_m"
start = 100.0
stop = 500.0
steps = 5
key = "accel_classical.bias"
start = 1.0e-3

Kshana Studio で開く · GitHub で見る

telecom-timing#

通信タイミング:GNSS ホールドオーバーの時刻誤差、最大時間間隔誤差(MTIE)、時間偏差(TDEV)を ITU-T マスクに照らして確認し、マスクごとに PASS または FAIL とマージンを出します。入力は、合成ホールドオーバー(発振器プリセット -- ocxo、rubidium、caesium、csac のいずれかで、それぞれ名前の付いた公開 Microchip データシートの安定度、エージング、温度の数値を持つ -- に、GNSS 喪失時間、記録長、サンプル間隔を加えたもの。自走クロックは、ホワイト周波数雑音、フリッカー周波数雑音、データシートへのフィッティングに必要な場合はランダムウォーク周波数雑音、線形エージング、正弦波状の温度項を持ちます)か、インラインで与える [time_s, time_error_ns] の組の取り込み系列(ネイティブビルドに限り CSV ファイルも可)のいずれかです。マスク:ITU-T G.8272(07/2025)PRTC-A と PRTC-B(max|TE| はそれぞれ 100 / 40 ns、MTIE は表 1-2、TDEV は表 3-4)、G.8272.1(2024)Amd. 1(07/2025)の ePRTC ロック時(30 ns、表 1-2)と ePRTC-A ホールドオーバー(ロック期間で決まるホールドオーバー期間 H の間に 30 ns から 100 ns へ上昇する表 3 の時刻誤差エンベロープ、MTIE は表 4、TDEV は表 5)、G.8273.2(2023)Amd. 2(11/2025)の T-BC/T-TSC クラス A-C(max|TE|、定常時刻誤差、ローパスフィルタ後の MTIE と TDEV)とクラス D(max|TE_L| 5 ns。今後の検討に残されていないクラス D の数値はこれだけ)、G.8271.1(2022)Amd. 3(05/2025)の基準点 C(max|TE_L| 1100 / 600 / 100 ns と、MTIE の表 7-1 から 7-3)。勧告が今後の検討としているエントリーは、埋め合わせずに含めておらず、各レポートは未実装の項目を一覧にします。また、各最大時刻誤差バジェットを超えるまでの時間(既定値:ePRTC の max|TE_HO| 100 ns、ネットワークホールドオーバー割当 400 ns、基準点 C 1100 ns、クラス 4 の 1.5 us)、各マスクの限界値を付けた CSV 表としての MTIE/TDEV 曲線、数値フィールドごとの単位と出典のエントリーも報告します。VALIDATED:コミット済みのホールドオーバー系列に対する、allantools パッケージとの MTIE および TDEV 推定器の照合。MODELLED:マスク表は転記したものであり、合成ホールドオーバーはデータシートの最大値から作ったモデルで、いかなる機器の測定でもありません。適合性試験ではありません。

telecom-prtc-holdover-24h.toml

kind telecom-timing名前では台帳のモジュールと対応づけられていません

通信タイミングの基準:全球測位衛星システム(GNSS)の基準を失い、24 時間ホールドオーバーするルビジウム時計を、国際電気通信連合 電気通信標準化部門(ITU-T)のマスクに照らして確認します。

kind = "telecom-timing"
seed = 20260925
masks = ["eprtc-a-holdover", "prtc-a"]
oscillator = "rubidium"
gnss_loss_s = 3600.0
duration_s = 90000.0
sample_interval_s = 1.0
locked_te_sigma_ns = 1.0

Kshana Studio で開く · GitHub で見る

telecom-synce-eec.toml

kind telecom-timing名前では台帳のモジュールと対応づけられていません

通信タイミング、周波数同期:自走する恒温槽付き水晶発振器(OCXO)を、国際電気通信連合 電気通信標準化部門(ITU-T)の同期イーサネット装置クロック(EEC)ワンダ生成マスクに照らします。

kind = "telecom-timing"
seed = 20260925
masks = ["g8262-eec-option-1", "g8262-eec-option-2", "g8262-1-eeec"]
budgets = []
oscillator = "ocxo"
gnss_loss_s = 0.0
duration_s = 12000.0
sample_interval_s = 1.0

Kshana Studio で開く · GitHub で見る

telecom-tie-ingest.toml

kind telecom-timing名前では台帳のモジュールと対応づけられていません

通信タイミング、取り込みの例:インラインで与えた時間間隔誤差(TIE)の系列を、国際電気通信連合 電気通信標準化部門(ITU-T)のマスクに照らして確認します。

kind = "telecom-timing"
masks = ["prtc-a", "prtc-b", "eprtc", "eprtc-a-holdover", "t-bc-class-c", "g8271-1-point-c"]
holdover_start_s = 300.0
locked_duration_days = 5.0
samples = [

Kshana Studio で開く · GitHub で見る

terrain-nav#

GPS が使えない環境での地形参照航法(TERCOM/SITAN):電波高度計・気圧高度計の地表標高プロファイルを SRTM 方式の DEM と照合し、INS のドリフトを復元します。

terrain-nav.toml

kind terrain-nav名前では台帳のモジュールと対応づけられていません

地形参照航法(TERCOM/SITAN) — GPS 拒否環境の代替 PNT。

kind = "terrain-nav"
dem_seed = 1
start_lat_deg = 12.05
start_lon_deg = 20.05
step_lat_deg = 0.004
step_lon_deg = 0.003
waypoints = 60
drift_lat_deg = 0.5

Kshana Studio で開く · GitHub で見る

terrain-slam#

GPS が使えない環境での逐次(再帰)地形参照航法:パーティクルフィルタがエポックごとに地形照合の測定モデルを実行し(実行中のフィルタとしての SITAN)、軌跡に沿って時間変化する INS ドリフトを追跡します。バッチ方式の terrain-nav が復元できるのは、単一の一定オフセットだけです。

terrain-slam.toml

kind terrain-slam名前では台帳のモジュールと対応づけられていません

逐次(再帰)地形参照航法 — GPS 拒否環境の代替 PNT。

kind = "terrain-slam"
dem_seed = 1
start_lat_deg = 12.08
start_lon_deg = 20.08
step_lat_deg = 0.004
step_lon_deg = 0.003
waypoints = 60
drift_rate_lat_deg = 0.0006

Kshana Studio で開く · GitHub で見る

time-transfer-budget#

静止中継衛星を介した二つの地上局間の双方向衛星時刻・周波数伝送:すべての非可逆項(局の機器遅延、Ku バンド電離圏、トランスポンダー、Sagnac)を含む T_A - T_B について双方向方程式を解き、タイプ A の項をシミュレートしたリンクの平均化時間での TDEV とする二乗和平方根の不確かさバジェット、ホワイト位相雑音とフリッカー位相雑音および日周の非可逆性を持つシミュレートしたリンク、そして与えられた BIPM Circular T 第 1 節の系列、MJD,ns 形式の CSV、または IGS RINEX の局クロック記録の安定度(レート、残差 RMS、TDEV、ADEV)を扱います。MODELLED。

time-transfer-budget.toml

kind time-transfer-budget名前では台帳のモジュールと対応づけられていません

ILLUSTRATIVEの二つの局(中央ヨーロッパに一つ、北米東部に一つ)の間の、西経 10 度の静止中継衛星を介した双方向衛星時刻・周波数比較(TWSTFT)。実行では、設定した機器、トランスポンダー、電離圏(Ku バンド、14/11 GHz)、Sagnac の各項から、T_A - T_B についての双方向の式を解きます。統計項を、白色と フリッカー位相雑音および日周の非相反性を持つシミュレートしたリンクの、一日でのTDEV とする不確かさバジェットを作成します。遅延と不確かさは例示用であり、いずれの研究所の校正値でもありません。MODELLED。実際の UTC-UTC(k) または局時計の系列を [[series]] の下に追加して(形式は circular-t、mjd-csv、rinex-clock)、その安定度を報告させることができます。

kind = "time-transfer-budget"
satellite_lon_deg = -10.0
transponder_ab_ns = 812.0
transponder_ba_ns = 809.5
uplink_ghz = 14.0
downlink_ghz = 11.0
true_offset_ns = 12.5
white_noise_ns = 0.3

Kshana Studio で開く · GitHub で見る

timetransfer#

光と RF による双方向の時刻・周波数伝送。

timetransfer.toml

kind timetransfer名前では台帳のモジュールと対応づけられていません

衛星間の光時刻伝送と従来の RF(TWSTFT)の比較。

kind = "timetransfer"
seed = 42
samples = 600
step_s = 1.0
range_spec_mm = 10.0
id = "optical-isl"
provenance = "Optical inter-satellite link, picosecond-level synchronization target; free-space optical two-way time-frequency transfer lab floor ~1 fs (Giorgetta 2013, Nature Photonics; Deschenes 2016, PRX). Using a 1 ps target as the on-orbit-credible figure."
sigma_j_s = 1.0e-12

Kshana Studio で開く · GitHub で見る

tracking-loop#

トラッキングループのロック喪失:C/N0 → ヒステリシス付きのロック/アンロック、ロックを失うまでの時間、そしてコードおよび搬送波オフセットの変化率の関数としてのスプーフィングのプルインです。エンジンが従来から使う妨害とキャプチャの基準は受信電力の比であり(ジャマーは J/S = 30 dB で妨害し、スプーファーは 3 dB でキャプチャします)、実際のロック喪失は電力比ではなく、ループのジッターに動的ストレスを加えたものがトラッキング閾値のバジェットを超えるところで起きます。報告するのは次のとおりです。(1) 搬送波(Costas)とコード(非コヒーレント early/late)の 1 シグマ熱雑音ジッターを C/N0 に対して、二乗損失を含めて示し、規定の規則 3*sigma_PLL + theta_e <= 45 deg(15 度則を 三シグマの形にしたもの)および 3*sigma_DLL + ramp lag <= d/2 chips と照らします。(2) ドロップと再ロックの C/N0 閾値と、支配的なループの名称。再ロック閾値は、主張するのではなく、受信機が再プルインする際のより広い帯域幅から導出されるため、ヒステリシス幅は 5*log10(ratio) と 10*log10(ratio) dB の間に収まらなければなりません。(3) C/N0 のランプで駆動した、確認ドウェル付きの 二閾値ロック検出器から宣言されるロック喪失までの時間。これは、物理的な位相脱出時間(サイクルスリップ間の Viterbi 平均時間で、数百桁にわたるため log10 s で表します)とは別に報告します。(4) スプーフィングのプルイン限界:被害側のループが追従できるコードスルーと搬送波ドップラー変化率の最大値を、両軸にわたるマップとともに示します。これらより速くスルーさせるスプーファーは、ループをキャプチャするのではなく、置き去りにするためです。(5) ループ動力学が含意する妨害半径は、既存の電力比の半径に代わるものではなく、それと並べて報告し、両者の符号付きの差は独立した名前付きフィールド(denial_radius_delta_km)として、その定義とともに示します。出力するすべての数値フィールドには、単位と出所の区分が付きます。VALIDATED の閉形式:搬送波とコードのジッターの式、ループフィルターの縮約 sqrt(2*B_n*T)、および 一次のランプ遅れは、シード付きの合成 IF 上で進めたエンジン自身の sdr コリレーターと照合しており(同じ数値に至る別の経路です)、それぞれ 0.6 %、3.7 %、0.17 % の範囲で一致しました。サイクルスリップ時間の背後にある変形ベッセル関数 I0 は、標準の表の値と 1e-7 まで一致しました。下側の有効限界は、単に記載されているだけでなく、アサートされています。1 ms で約 32 dB-Hz を下回ると、実際の atan 弁別器は +-pi/2 の範囲で飽和し、どの線形理論よりも小さいジッターを測定してしまいます。MODELLED:ループ帯域幅、積分時間、コリレーター間隔、プルイン帯域幅比、確認ドウェル、ジャマー電力、アンテナ利得は、データシートの値ではなく、周波数帯の代表的な数値です。モデル化していないもの:発振器(アラン偏差)と振動によるジッター、フロントエンドの帯域制限、マルチパス、AGC の動特性、データビット遷移損失、外部補助、および Costas のサイクルスリップの式への半サイクル補正。ループ動力学のもとでは、スプーフィングのキャプチャに半径はまったくなく、支配的な制約は電力ではなくオフセット変化率であるため、そのフィールドは作り出した数値ではなく、理由付きの null です。認証済みの受信機性能製品ではありません。

tracking-loop.toml

kind tracking-loop名前では台帳のモジュールと対応づけられていません

トラッキングループのロック喪失:C/N0 → ヒステリシス付きのロック/アンロック、ロックを失うまでの時間、そしてコードおよび搬送波オフセットの変化率で決まるスプーフィングのプルイン限界。

kind = "tracking-loop"
pll_bandwidth_hz = 10.0
dll_bandwidth_hz = 1.0
predetection_integration_s = 0.001
correlator_spacing_chips = 0.5
carrier_allowance_deg = 45.0
pullin_bandwidth_ratio = 2.0
drop_confirm_epochs = 50

Kshana Studio で開く · GitHub で見る

スタディスイート#

スイートとは、他のシナリオを列挙するシナリオファイルのことで、kshana --study がこれを実行して、一つのタイムスタンプ付きの study.json と study.html にまとめます。これは無償のスイートランナーであり、有償のカスタムスタディではありません。

quantum-pnt-demonstrator.suite.toml

量子対応 PNT デモンストレーター — 三つの応用分野を 一つのスタディとして。

kshana --study scenarios/quantum-pnt-demonstrator.suite.toml

GitHub で見る