• Proben Sie die Minute, in der GNSS ausfällt
• Was neu ist in 0,40, Was neu ist in 0,39, Was neu ist in 0,38 und 0,38 im Detail: Jammertest-Bewertung, die eigenen Flags des Empfängers, maschinenlesbare Eingaben, Zeitgebung und holdover, Normenpakete, LunaNet AFS, der Laborrundlauf, kshana-bench, das Observatorium, Exporter, Optik, Navigation für Raumfahrzeugnutzer und Mondinfrastruktur
• Kshana Studio und jede Studio-Seite
• Fähigkeiten: die Tabelle der Bereiche, jeder Szenariotyp nach Familie, jeder Befehl, jede Oberfläche
• Wie ein Lauf funktioniert, Missionen
• Nachweise: das Register, Fähigkeitsbereiche
• Installation, Architektur (und die Diagramme), KI-Assistent
• Editionen, Forschung, Zitieren, Lizenz
• Referenz: Verwendung, Szenarioformat, Ausgabe, Repository-Aufbau, FAQ, Fehlerbehebung, Versionierung, Roadmap, Mitwirken, Dokumentation

Führen Sie jedes davon mit kshana example <scenario> > s.toml && kshana s.toml aus: die Szenarien sind l-band-waterfall-jamming, constellation-multi-gnss-coverage, solar-system-tour und leo-pass-iridium.

Alle vier sind erfundene Daten und beratend: Sie zeigen das Format und das Verhalten der Software, nicht, wie sich irgendein Empfänger oder System gegenüber Störungen verhält. Führen Sie das erste mit kshana receiver-trust examples/maritime-trust/session.toml aus, das zweite mit kshana route-exposure auf den Beispielen in examples/interference-map/, das dritte mit kshana nmea-scenario scenarios/training/coastal-drag-off.toml --out drag.nmea (nur zu Trainingszwecken: nie in Live-Navigationsausrüstung einspeisen) und das vierte wie in docs/EVIDENCE-PACKS.md.

Es folgt die vollständige Aufstellung Bereich für Bereich; für ein Reifegrad-Register je Fähigkeit siehe docs/CAPABILITY.md und docs/VALIDATION.md.

Jede Fähigkeit ist als Rust-API, als ausführbares Szenario kind oder als beides erreichbar. Der Reifegrad je Fähigkeit — validiert, ausführbar oder Bibliothek — wird in docs/CAPABILITY.md verfolgt. Eine maschinell geprüfte Verifikationsmatrix (src/verification.rs) stellt den Querverweis Anforderung → Modul → Test → unabhängige Referenz → Status dar, mit unit-getesteten Ehrlichkeitsinvarianten, die ein Etikett validiert nur zulassen, wo eine unabhängige externe Referenz es stützt — und die die Hardware-/PA-Fähigkeiten (Produktsicherung) festhalten, die Kshana bewusst nicht bereitstellt.

Ergebnisse#

Jedes Szenario vergleicht einen Quantensensor mit seinem klassischen Gegenstück über einen GNSS-Ausfall von ~1,8 h. Die Zahlen sind reproduzierbar (scenario + seed + version).

_{Was Quantensensoren bringen, wenn GNSS weg ist — clock-holdover · Seed 42 · gezeichnet mit Engine 0.40.0, und jede Zahl oben wird bei jedem Build von tests/published_figures_still_reproduce.rs erneut gegen die aktuelle Engine geprüft · SVG}

Der Vorteil hängt von Ausfall und Vibration ab, mit einem ausdrücklichen Break-even, wo klassisch gewinnt — ehrlich gezeigt über die Leiter der Technologiereife (Angaben zu optischen Uhren sind Ziele für Bodendemonstratoren; noch keine optische Strontium-Uhr ist geflogen):

_{Crossover der Resilienz Quanten gegen klassisch — Uhren-Holdover auf der TRL-Leiter (oben) · Karte des inertialen Vorteils mit Break-even-Kontur (unten). Neu erzeugbar über cargo run --release --bin crossover_study.}

Positionsfehler der Koppelnavigation während eines GNSS-Ausfalls: Der Quantensensor (blau) bleibt flach nahe der Spezifikation; der klassische Sensor (rot) divergiert auf Dutzende Kilometer. Von Kshana aus scenarios/imu-deadreckoning.toml erzeugt.

Der Abschluss zeigt die Fusionsthese: Die optische Inter-Satelliten-Zeitübertragung hält selbst eine klassische Uhr verriegelt und isoliert den inertialen Sensor als das schwache Glied der klassischen Ausstattung — also inertial mit Quanten und optische Zeitgebung zusammen.

Uhren-Holdover durch einen GNSS-Ausfall: Die optische Uhr (blau) bleibt für den gesamten Coast innerhalb der Spezifikation von 20 ns; die chipgroße Uhr (rot) überschreitet sie auf halbem Weg. Von Kshana aus scenarios/clock-holdover.toml erzeugt.

Ein weiteres Szenario, orbit-gnss-challenged.toml, leitet die GNSS-Verfügbarkeit aus der Bahngeometrie ab statt aus von Hand verfassten Fenstern: Ein Raumfahrzeug innerhalb der GNSS-Schale wird gegen eine GPS-ähnliche Walker-Konstellation propagiert, und die Anzahl sichtbarer Satelliten (Sichtlinie, Erdverdeckung, Elevationsmaske) legt in jedem Schritt den Lösungszustand fest. Über einen Tag hinweg ist der Nutzer nur ~59 % der Zeit in der Lösung; die Quantenuhr hält eine Zeitlösung von 5 ns durch jede Lücke (Verfügbarkeit 1.0), die chipgroße Uhr nur ~0.83.

Zeitfehler über einen Tag mit aus der Bahngeometrie abgeleiteter GNSS-Verfügbarkeit: Die Anzahl sichtbarer Satelliten (Sichtlinie, Erdverdeckung, Elevationsmaske) legt in jedem Schritt den Lösungszustand fest, die Uhr muss also jede Lücke überbrücken — die optische Uhr hält die Spezifikation von 5 ns, während die chipgroße Uhr sie überschreitet. Von Kshana aus scenarios/orbit-gnss-challenged.toml erzeugt.

Die Konstellation kann auch als echte Two-Line-Element-Sätze (TLEs) angegeben werden. Ein vollständiges TLE (Zeile 1 + Zeile 2) wird mit dem vollen Modell SGP4/SDP4 propagiert — einschließlich atmosphärischem Widerstand und der Tiefraum-Terme von Mond und Sonne sowie der Resonanzterme von 12 h / 24 h, die für GNSS-Umlaufbahnen von ~12 h zählen — und gegen die offiziellen Vektoren AIAA 2006-6753 auf einen ungünstigsten Fall von ≈ 4 mm validiert. scenarios/orbit-sgp4-gps.toml liefert einen echten Celestrak-Schnappschuss gps-ops der operativen GPS-Konstellation (2021-07-28, 30 Satelliten) und verlangt gültige TLE-Prüfsummen — Two-Line-Element-Sätze sind offene Daten aus dem Katalog der US Space Force / des 18th Space Defense Squadron, von Celestrak weiterverbreitet (Dr. T. S. Kelso, celestrak.org); aktualisieren mit scripts/fetch_tles.sh. Ein Block nur mit Zeile 2 behält die analytische Zweikörper-Propagation (scenarios/orbit-real-tle.toml); beide Formen lassen sich in einer Konstellation mischen. Eine Konstellation lässt sich ebenso aus einem Block von RINEX-3-GPS-Broadcast-Ephemeriden-Datensätzen aufbauen — dem Format, das ein Empfänger dekodiert —, mit dem Algorithmus für Nutzer nach IS-GPS-200 propagiert und durch dieselbe Geometrie geführt (scenarios/orbit-rinex.toml).

Was es ist / nicht ist#

Es ist: eine deterministische, abhängigkeitsarme Engine über den gesamten PNT-Stapel — Bahngeometrie, Inertialnavigation, GNSS/INS-Fusion, Integrität, Uhren und Zeitgebung. Sie führt ein Szenario aus (oft einen GNSS-Ausfall), entwickelt kalibrierte Sensorfehlermodelle durch den passenden Schätzer weiter und bewertet das Ergebnis gegen die operativen Gütegrößen — und gibt ein reproduzierbares JSON-Ergebnis (JavaScript Object Notation) und ein SVG-Diagramm aus, aus einer Rust-Bibliothek, einer Kommandozeilenschnittstelle (CLI), einer Python-Erweiterung, einem WebAssembly-Modul im Browser, einem Model-Context-Protocol-Server (MCP) für KI-Agenten oder einem Plugin für JetBrains-IDEs (integrierte Entwicklungsumgebung).

Es ist nicht: Flughardware, ein Entwurf einer Quanten-Nutzlast, ein vollständiger GNSS-Signalempfänger, ein Simulator für Hochfrequenzsignale (HF) oder ein Hardware-in-the-Loop-Aufbau oder ein zertifiziertes Avionikprodukt — und es ersetzt weder MATLAB/Simulink noch STK (Systems Tool Kit) noch Orekit; es steht neben ihnen und tauscht Dateien mit ihnen aus. Die Treue zur Quantenhardware stammt aus veröffentlichten Fehlermodellen, nicht aus diesem Werkzeug. Der granulare Reifegrad jeder Fähigkeit ist in docs/CAPABILITY.md dokumentiert.

Es ist (noch) nicht: eine vollständige Physik-Engine der Atominterferometrie (die meisten Quantensensoren verbrauchen veröffentlichte Allan-/Rauschbudget-Koeffizienten; der CAI-Beschleunigungsmesser (Kaltatom-Interferometer) hat eine Schicht aus ersten Prinzipien — Mach–Zehnder-Phase, Projektionsrauschen, Kontrastabfall und Schwingungskopplung, plus Coriolis- und Lichtverschiebungs-Systematiken —, aber Wellenfront-Systematiken und die Auflösung der Streifenmehrdeutigkeit bleiben eine Roadmap-Schicht P2 (Roadmap-Phase 2, die Schicht der Quantenphysik), siehe ROADMAP.md und docs/QUANTUM-MODELS.md); ein zertifizierter oder Hardware-GNSS-Empfänger (er löst eine Einzelpunkt-PVT-Positionslösung (Position, Geschwindigkeit und Zeit) aus echten RINEX-Codebeobachtungen (Receiver Independent Exchange Format) — validiert an echten IGS-Daten (International GNSS Service) — und seine IQ-Schicht (kshana iq, seit 0.31.0) erfasst und verfolgt aufgezeichnete oder erzeugte Basisband-Abtastwerte in Software, als Analyseempfänger: Er steuert keine Funkhardware an und sendet nicht, ist kein zertifizierter Empfänger und leistet keine Trägerphasen-Positionierung (RTK oder PPP)); oder eine vollständige Suite für den Missionsentwurf (er hat Bausteine für Lambert / Porkchop / Manöver / Bahnbestimmung, ist aber die Ebene der Leistungssimulation oberhalb von GMAT (General Mission Analysis Tool)/Orekit, kein Ersatz). Diesen Umfang zu besitzen ist Absicht. Wenn Sie Fehlerbudgets für Kaltatom-Interferometer aus ersten Prinzipien brauchen (z. B. in der Güte von CARIOQA-PMP — Cold Atom Rubidium Interferometry in Orbit for Quantum Accelerometry, Pathfinder Mission Preparation — oder eine Validierung im Stil von X-37B), siehe die Roadmap P2 und nehmen Sie Kontakt auf, um zusammenzuarbeiten.

Validierung, Reproduzierbarkeit und Ehrlichkeit#

• Jeder Rauschterm ist auf eine veröffentlichte, zitierte Größe kalibriert und gegen die Standardbeziehung validiert (Allan-Abweichung für Uhren; Groves' Fehlerwachstum der Koppelnavigation für Inertial; die Umrechnung Zeitgebung→Entfernungsmessung für Zeitübertragung). Der Status je Term wird in docs/VALIDATION.md als validated oder not modeled verfolgt — nichts wird als validiert dargestellt, das es nicht ist.
• Reproduzierbar durch Konstruktion: scenario + seed + engine version → identical bits. scripts/check-reproducible.sh erzwingt es; Quanten- und klassische Läufe verwenden unabhängige Seeds, damit ihr Rauschen unkorreliert ist.
• Der Reifegrad wird ehrlich angegeben: Angaben zu optischen Uhren und optischen Verbindungen sind Ziele / Ergebnisse von Bodendemonstratoren, nicht geflogen.

Die Nachweiskennzeichnung an jeder Zahl#

Jede Zahl und Tabelle, die ein Lauf schreibt, sagt, wie weit ihr zu trauen ist und auf welchen Registerzeilen das beruht. Das Ergebnis-JSON hat einen Schlüssel evidence, die Diagramm-SVG eine Zeile unter der Grafik (und ein Element <metadata id="kshana-evidence">), und die CSV-Tabelle hat davor Kommentarzeilen # evidence: (gelesen mit comment='#'). Sie nennt eine Stufe, VALIDATED, MODELLED oder PARTNER, und die Kennungen (VM- und acht Hexadezimalziffern) der Zeilen der Verifikationsmatrix, die der Lauf beansprucht hat. Die Stufe ist die schwächste dieser Zeilen, sodass ein Lauf, der sich auf eine modellierte Zeile stützt, als MODELLED gekennzeichnet wird, wie viele validierte Zeilen auch daneben stehen; die Kennzeichnung kann nie mehr behaupten als das Register. Zeilen, Status und Kennungen werden aus der Matrix gelesen, nicht getippt (docs/VERIFICATION-MATRIX.md, docs/SCHEMA.md), und tests/evidence_labels_doc_sync.rs schlägt fehl, wenn eine Grafik keine Kennzeichnung hat oder eine Kennzeichnung der Matrix widerspricht.

Validierung auf einen Blick#

Jede Zeile wird durch einen benannten Test in der CI durchgesetzt. Diese Tabelle ist eine kuratierte Auswahl; die vollständige maschinengeprüfte Matrix hat 401 Zeilen — 176 VALIDATED, 221 MODELLED, 4 PARTNER (src/verification.rs), mit den vollständigen Nachweisen (und dem, was ehrlich noch nicht validiert ist) in docs/VALIDATION.md und dem Artefakt kshana-validation-summary.html je Release (erzeugt von cargo run --bin validation_report, SLSA-attestiert — Supply-chain Levels for Software Artifacts).

Die Spalte Status nennt die Art des Nachweises, passend zur Validierungsleiter oben: VALIDATED = gegen eine unabhängige externe Referenz geprüft (echte Daten, eine unabhängige Bibliothek oder veröffentlichte Referenzvektoren); MODELLED = gegen analytische Wahrheit oder die Selbstkonsistenz der Simulation geprüft (kein unabhängiger externer Datensatz). VALIDATED beschreibt die Methode der Prüfung, kein Bestanden/Durchgefallen — eine ehrliche Verfehlung gegen eine echte externe unabhängige Referenz bleibt VALIDATED, während ein Vergleich, den keine Matrixzeile als unabhängige Referenz nennt (die Anpassung an LRO — Lunar Reconnaissance Orbiter — oben), als MODELLED gezeigt wird. CI-Zeilen sind Prozesswächter, keine Gütegrößen. Einige Inseln mit realen Daten (die gemessene Cäsiumuhr, Stable32 PHASE.DAT und die Prüfungen OPS-SAT/ICGEM, bei denen die rohen Eingaben keine Weiterverbreitungslizenz tragen) sind datengesteuert: Der Test gibt einen Hinweis zum Überspringen aus und bleibt grün, wenn die Eingabe fehlt, und die öffentlichen Referenzzahlen sind unter tests/fixtures/ festgeschrieben. Reproduzieren Sie die rohen Eingaben mit dem passenden scripts/fetch_*.sh.

_{Wie sich eine Fähigkeit ihr Label verdient — die in der CI durchgesetzte Invariante: keine externe unabhängige Referenz ⇒ kann nicht validiert sein · SVG}

_{Oben: Jede validierte Zeile ist konstruktionsbedingt durch einen externen Datensatz abgesichert. Unten: SGP4 stimmt in jedem Regime mit der offiziellen Referenz überein (schlechtester Wert 4,12 mm). SVG · SVG}

_{176 validiert · 221 modelliert · 4 Partner — SVG}

import json, kshana

toml = open("clock-holdover.toml").read()
result = json.loads(kshana.run(toml))
print(kshana.version(), result["quantum"]["fom"]["holdover_s"], result["classical"]["fom"]["holdover_s"])
# 0.40.0 6600.0 2610.0

Über run hinaus stellt das Modul run_full (JSON, SVG und die einzeilige Zusammenfassung auf einmal), run_typed, validate_toml, list_kinds / scenario_kinds und error_kind bereit; siehe docs/PYTHON_API.md.

Das npm-Paket ist die gesamte, nach WebAssembly kompilierte Engine. In Node.js übergeben Sie die Binärdatei an initSync; in einem Browser lädt await init() sie (siehe README.npm.md).

import { readFileSync } from "node:fs";
import { createRequire } from "node:module";
import { initSync, run, summary, version } from "kshana";

const wasm = createRequire(import.meta.url).resolve("kshana/kshana_bg.wasm");
initSync({ module: readFileSync(wasm) });

const toml = readFileSync("clock-holdover.toml", "utf8");
const result = JSON.parse(run(toml));
console.log(version(), result.quantum.fom.holdover_s, result.classical.fom.holdover_s);
// 0.40.0 6600 2610
console.log(summary(toml));

Eine Engine, viele Eingänge. Ein einziger Rust-Kern (kshana) führt jedes Szenario aus, erreichbar über eine CLI, eine Python-Erweiterung, ein WebAssembly-Modul im Browser, einen MCP-Server für KI-Agenten und ein JetBrains-IDE-Plugin — alle münden in einen api::run_toml-Dispatch. Im Inneren fügen sich die Sensorpakete in eine gemeinsame Fehlermodell-Schnittstelle ein; daneben stehen eine Bezugssystem-Schicht (IAU-2006/2000A-Präzession–Nutation und die CIO-basierte GCRS↔ITRS-Reduktion), eine Astrodynamik-/Numerik-Schicht (analytisches SGP4/SDP4 und ein numerischer Cowell-Propagator mit seinem EGM2008-/Störkräftemodell, Manöverentwurf und Bahnbestimmung), eine Integritäts-/GNSS-Schicht (RAIM/ARAIM, SBAS, die Messdomäne, Jamming, cislunar), eine Fusions-/Alt-PNT-Schicht (die GNSS/INS-Schätzer und die Karten-Matcher für Schwere/Gelände/Magnetfeld), eine Deep-Space- und Mond-Schicht (radiometrisches Mars-PNT und die Mond-PNT-Suite, ihre Evidenzstufe je Baustein in der Matrix — LTC-Zeit, VLBI, gemeinsame OD+Uhr, Realisierung von Bezugssystemen, Service-Volume, differenzielles PNT, Interoperabilität), eine Missionsanalyse-Schicht (Start / Wiedereintritt / Abdeckung / Ausrichtung / Überflug / Link-Budgets und die Weltraumwetter-Umgebung) und die offene Studienschicht für Resilienz & maschinelles Lernen (RPCF-Resilienzbewertung, die Optimismuslücke bei HF-Beeinträchtigungen und der quantengestützte PNT-Demonstrator), deren reproduzierbare Artefakte auf den validierten Kernen aufsetzen.

Zwei eigenständige, aus dem Workspace ausgeschlossene Crates stehen neben dem Kern — mcp/kshana-mcp (der MCP-Server, gebaut auf dem Edition-2024-rmcp-SDK) und xval/anise-frames (die ANISE/SPICE-Gegenprüfung der Bezugssysteme, die MPL-2.0-Abhängigkeiten (Mozilla Public License 2,0) einbindet) — und über die exclude-Liste der Wurzel-Cargo.toml aus dem Abhängigkeitsgraphen des veröffentlichten Crates, aus Cargo.lock, Lizenzprüfung und MSRV-Build (minimum supported Rust version) herausgehalten. Das JetBrains-Plugin (ide/jetbrains) ist ein eigenes Kotlin-Projekt. Den vollständigen Satz an Diagrammen finden Sie in docs/ARCHITECTURE.md.

Die gerenderten Diagramme (Engine-Ablauf, Modulkarte, Verteilung) stehen in docs/ARCHITECTURE.md.

Szenarien und Berichte

Export und Interoperabilität

Vertrauen in Empfänger und Schiff

GNSS-IQ (Dateien im Arbeitsverzeichnis; im HTTP-Modus aus)

compliance-Zuordnung

Benchmark

Worauf Kshana Pro aufbaut. Jeder Teil von Pro arbeitet mit der offenen Engine und lässt sie unverändert:

• Der Entwurfsoptimierer, die Unsicherheitsstudie und das Missions-Dossier führen Szenarien der offenen Engine über deren öffentliche Schnittstelle aus und berechnen jede Zahl aus den Ergebnissen der Läufe. Jede Ausgabe behält die Stufe VALIDATED, MODELLED oder PARTNER, die die offene Engine jeder Kennzahl gegeben hat, nie eine höhere.
• Digitale Uhrenzwillinge verwenden das Uhrenmodell der offenen Engine und ihren Schätzer der Allan-Abweichung: Ein Zwilling wird auf das veröffentlichte Allan-Budget des Geräts kalibriert und dann geprüft, indem die Allan-Abweichung des Zwillings mit dem offenen Schätzer bestimmt wird.
• Trade-Studien führen jede Architekturoption unverändert als Szenario der offenen Engine aus und ordnen die Optionen nach einer aus dem Ergebnis jedes Laufs gelesenen Gütekennzahl.
• Campaign Watch liest seine Kennzahlen aus den Ergebnissen von Läufen der offenen Engine für die Szenarien eines Packs und vergleicht sie mit dem vorherigen bestandenen Lauf.
• Spektrumkoexistenz liest jede physikalische Zahl aus Läufen der offenen Engine für die Arten leo-signal und constellation-design und fügt nur die Summe über die sichtbaren Satelliten und die Rangfolge der Pläne hinzu.
• Der On-Premises-Auftragsdienst führt offene und Pro-Szenarien über dieselbe Engine aus und speichert jedes Ergebnis so, wie der Lauf es zurückgegeben hat.
• Nachweispakete halten für jeden Lauf den Szenario-Hash fest, den die offene Engine auf ihr Ergebnis stempelt, sodass sich eine Kennzahl in einem Paket durch erneutes Ausführen ihres Szenarios reproduzieren lässt.
• Systems-Engineering- und Programm-Werkzeuge. Die modellbasierten Systems-Engineering-Werkzeuge (MBSE) und Programm-Werkzeuge von Kshana Pro prüfen die Anforderungen eines Programms gegen Läufe der offenen Engine: Sie importieren Anforderungen als kommagetrennte Werte (CSV) oder als dokumentierte Teilmenge des Requirements Interchange Format (ReqIF) oder des Textes der Systems Modeling Language Version 2 (SysML v2), werten jedes Abnahmekriterium mit seiner Einheit gegen die Werte aus, die ein Lauf geschrieben hat, und erzeugen eine Verifikations-Querverweismatrix (VCRM), ein SysML-v2-Modell, einen Änderungsauswirkungsbericht und ein Offline-Nachweispaket. Sie führen nichts erneut aus und berechnen nichts neu und lesen nur, was die offene Engine veröffentlicht: das result.json jedes Laufs (die Felder, die ein Kriterium nennt, ihre Einheiten, den Reproduzierbarkeitsstempel aus Szenario-Hash, Seed, Engine-Version und Schema-Version sowie das Label und die Kennzahlenstufen des Laufs), sein report.json (Art, Reproduzierbarkeitsprotokoll und Fähigkeits-Labels), die Szenariodatei (ihren Hash, ihre Art, ihren Seed und ihre Parameter), das Schema der Feldeinheiten (Einheit, Herkunft und Evidenzstufe jedes Feldes) und die Verifikationsmatrix (das Label VALIDATED, MODELLED oder PARTNER jeder Fähigkeit).

Support & professionelle Dienstleistungen#

Kshana ist frei und Open Source unter der AGPL-3.0 und wird von Ashforde® OÜ professionell entwickelt und gepflegt (Estland). Die offene Engine ist vollständig und für sich allein nutzbar. Für Organisationen, die mehr brauchen, bietet Ashforde® OÜ:

• Kommerziellen Support & Integration — Kshana in Ihre Toolchain einbetten, individuelle Szenarien und bevorzugte Fehlerbehebungen.
• Individuelle Sensormodelle — auf Ihre Hardware kalibriert, einschließlich exportsensibler Resilienzmodelle, die in einem privaten Overlay gepflegt werden.
• Kshana Pro — proprietäre modellbasierte Systems-Engineering-Werkzeuge (MBSE) und Programm-Werkzeuge, die die Anforderungen eines Programms gegen Läufe der offenen Engine prüfen und eine Verifikations-Querverweismatrix (VCRM), ein Modell der Systems Modeling Language Version 2 (SysML v2), einen Änderungsauswirkungsbericht und ein Offline-Nachweispaket erzeugen. Sie führen nichts erneut aus und lesen nur die veröffentlichten Ausgaben der Engine: das result.json und das report.json jedes Laufs, die Szenariodatei, das Schema der Feldeinheiten und die Labels der Verifikationsmatrix (die vollständige Liste steht unter Editionen).
• Entwurfs-, Unsicherheits- und Missions-Werkzeuge von Kshana Pro — die Pareto-Front eines Entwurfsraums, Unsicherheit und Sensitivität über Tausende von Läufen und ein Missions-Dossier per Einzelbefehl mit Verifikationsmatrix und PDF; siehe docs/PRO.md.
• Campaign Watch, Spektrumkoexistenz und Auftragsdienst von Kshana Pro — eine Pipeline, die fehlschlägt, wenn sich eine überwachte Kennzahl verschlechtert, Signalpläne, die in beide Richtungen gegen die offenen Satellitennavigationssignale getestet werden, und eine On-Premises-Auftragswarteschlange mit einem hashverketteten Lieferregister; siehe docs/PRO.md.
• Schulung & Beratung zur Leistungsanalyse von Quanten-/klassischem PNT.

Das ist das Open-Core-Modell: Die Engine ist und bleibt offen lizenziert; das tragende Geschäft sind Fachwissen, Support und die proprietären Erweiterungen — nicht Lizenzgebühren. Kontakt: contact@ashforde.org · ashforde.org.

Installation & Build#

Erfordert eine Rust-Toolchain (≥ 1,88, die rust-version in Cargo.toml; entwickelt mit 1,93).

git clone https://github.com/ashfordeOU/kshana
cd kshana
cargo build --release
cargo test          # all tests pass

Verwendung#

Jedes Szenario ausführen; die CLI verzweigt anhand des Feldes kind des Szenarios und schreibt <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html und <scenario>.report.json daneben — plus <scenario>.table.csv für die Arten, die eine Tabelle veröffentlichen. Der Bericht (eine HyperText-Markup-Language-Seite (HTML) und ein JSON-Dokument mit demselben Inhalt) enthält eine Management-Zusammenfassung, jede Eingabe mit ihrer Einheit, die Ergebnisse und Diagramme, die Sweep-, Monte-Carlo- oder Ketten-Tabellen einer Kampagne, eine Ereigniszeitleiste, das Label VALIDATED / MODELLED / PARTNER und die Quelle jeder vom Lauf verwendeten Fähigkeit, was nicht modelliert ist, und ein Reproduzierbarkeitsprotokoll (Engine-Version, Digests des Secure Hash Algorithm 256-bit (SHA-256), Seed, Plattform und der genaue Befehl). Er lässt sich aus dem Browser auf A4- oder Letter-Papier als saubere PDF-Datei (Portable Document Format) drucken; die Engine schreibt selbst kein PDF. Siehe docs/REPORTS.md.

cargo run -- scenarios/clock-holdover.toml
cargo run -- scenarios/imu-deadreckoning.toml
cargo run -- scenarios/timetransfer.toml
cargo run -- scenarios/hybrid-pnt.toml
cargo run -- scenarios/orbit-gnss-challenged.toml
cargo run -- scenarios/orbit-sgp4-gps.toml
cargo run -- scenarios/orbit-rinex.toml
cargo run -- scenarios/integrity-raim.toml

# Export a propagated constellation to an SP3-c precise-ephemeris file:
cargo run -- scenarios/orbit-sgp4-gps.toml --export-sp3 gps.sp3

# Export the constellation's mean elements to a CCSDS OMM catalogue (one OMM
# message per TLE-defined satellite, with its real NORAD id / COSPAR designator):
cargo run -- scenarios/orbit-sgp4-gps.toml --export-omm gps.omm

# Export the velocity-carrying state to a CCSDS OEM 2.0 ephemeris (GMAT/Orekit/STK):
cargo run -- scenarios/orbit-sgp4-gps.toml --export-oem gps.oem

# Export the geometry for a globe, a map or a mission-analysis tool: CZML, KML,
# GeoJSON, STK .e, or SigMF for the spectrum kind (every format that applies):
cargo run -- scenarios/jamming-demo.toml --export all

--export <czml|kml|geojson|stk|sigmf|all|list> schreibt CZML (die Cesium Language), KML (Keyhole Markup Language), GeoJSON (Request for Comments 7946), Ansys-STK-Ephemeriden (Systems Tool Kit) .e und SigMF-Aufzeichnungen (Signal Metadata Format) neben das Szenario, und --import-route <route.geojson> speist eine GeoJSON-Linie in die Arten ein, die einen Kurs abfliegen. Jedes Format wird gegen seine veröffentlichte Spezifikation validiert, und ein Szenario, für das ein Format nicht gilt, sagt warum: siehe docs/INTEROP.md.

Weitere CLI-Modi — ein Szenario linten, reale Erdorientierungsdaten einspeisen oder eine ganze Suite ausführen:

# Lint a scenario without running it (checks the kind + required fields):
cargo run -- --validate scenarios/integrity-raim.toml

# Feed a real IERS Earth-orientation file (finals2000A) for frame precision:
cargo run -- scenarios/orbit-sgp4-gps.toml --eop tests/fixtures/agency/eop/finals2000A_2022001.txt

# Run a SUITE of scenarios into one aggregated, stamped study artifact
# (writes <suite>.study.json + <suite>.study.html next to the manifest):
cargo run -- --study scenarios/quantum-pnt-demonstrator.suite.toml

# Animate a run's time series: an animated SVG, a self-contained HTML player, and a
# numbered SVG frame sequence with manifest.json (see docs/ANIMATION.md):
cargo run -- scenarios/campaign-jam-spoof-holdover-integrity.toml --animate all

Animationsexport. --animate svg|html|frames|all schreibt <scenario>.animation.svg (Cascading-Style-Sheets-Keyframes (CSS), kein Skript), <scenario>.animation.html (Wiedergabe, Pause, Scrubben, Geschwindigkeit und synchronisierte Panels, ohne externe Ressource) und <scenario>.frames/ (frame_0000.svg, … plus manifest.json mit den Bildern pro Sekunde und der Dauer). Eine Kampagne spielt ihre Phasen und Alarme ab, ein Spektrumlauf sein Wasserfalldiagramm; das Design folgt prefers-color-scheme und prefers-reduced-motion zeigt das fertige Bild. Sie stellt die eigenen Samples des Laufs dar, bei erneutem Lauf byte-identisch, und fügt keine Evidenz hinzu. Siehe docs/ANIMATION.md.

Ein Suite-Manifest ist eine kleine TOML-Datei (Tom's Obvious, Minimal Language) — ein title und ein scenarios = [ … ]-Array von Szenariopfaden —, die die Engine nacheinander ausführt, wobei jedes Ergebnis (mit seinen Labels MODELLED / VALIDATED) in ein selbstbeschreibendes Studienartefakt gefaltet wird. Siehe scenarios/quantum-pnt-demonstrator.suite.toml.

Interoperabilitätsrolle. Kshana ist die Leistungssimulations-Schicht, die neben der Nachverarbeitungs-Toolchain steht, kein Ersatz für sie: Speisen Sie die RINEX-Ausgabe in RTKLIB oder gLAB für eine Positionslösung ein und verwenden Sie die SP3-Ausgabe als Präzisionsbahn-Produkt für Werkzeuge wie Ginan — Kshana beantwortet welche Resilienz eine gegebene PNT-Architektur bringt, bevor Sie reale Signale haben, in Formaten, die diese Werkzeuge bereits einlesen (--export-sp3, oder export_sp3 = true in einem orbit-Szenario, schreibt <scenario>.sp3). Dieselbe Bahn kann als CCSDS-OMM-Mittelelemente auf dem Standardisierungspfad veröffentlicht werden (--export-omm, oder export_omm = true, schreibt <scenario>.omm) — eine OMM-502,0-KVN-Nachricht (keyword = value notation) je durch TLE definiertem Satelliten, die die reale NORAD-Katalognummer (North American Aerospace Defense Command), die internationale COSPAR-Bezeichnung (Committee on Space Research) und die Epoche jedes Objekts trägt, für jeden OMM-fähigen Verbraucher statt eines eigens gebauten Zweizeilen-Elementesatzes.

Beispielausgabe (Uhren-Holdover — beachten Sie, wie die Gütemaße für Integrität und Sicherheit berichtet werden):

scenario 5ba83a232b94 | quantum holdover 6600s p95 1.20e-4ns integrity 1.000 security n/a (no attack) | classical holdover 2610s p95 19.7ns integrity 1.000 security n/a (no attack)
wrote scenarios/clock-holdover.result.json, scenarios/clock-holdover.chart.svg, scenarios/clock-holdover.report.html, and scenarios/clock-holdover.report.json

Der Zeitfehler der optischen Uhr im 95. Perzentil (p95) beträgt 1.20e-4 ns: Die Zusammenfassung gibt kleine Werte mit signifikanten Stellen aus, statt sie auf 0.0 zu runden. security zeigt n/a (no attack), weil dieses Szenario keinen Angriff konfiguriert und es daher nichts zu erkennen gibt. Das JSON-Ergebnis trägt dennoch für jede Uhr die analytische Schranke der Spoof-Erkennbarkeit in fom.security (0,997 für die optische Uhr, 0,000 für die chipskalige Atomuhr, deren eigenes Rauschen über das Überwachungsfenster die Vorgabe von 20 ns übersteigt), und sein Block figure_tiers kennzeichnet diese Kennzahl mit applicable: false. Die Szenarioart spoof bewertet die Erkennung anhand eines eingespeisten Angriffs. figure_tiers gibt außerdem jeder berichteten Kennzahl ihre Verifikationsstufe — VALIDATED (gegen eine externe unabhängige Referenz geprüft) oder MODELLED — und die Zeile der Verifikationsmatrix an, aus der die Stufe gelesen wird. Das Orbit-Szenario berichtet zusätzlich neben dem Uhrenergebnis einen Geometrieblock — Anteil der Samples mit Fix sowie beste/mediane Positions-Dilution-of-Precision (PDOP) und Positionsgenauigkeit.

Lesen Sie diese beiden Zahlen sorgfältig. security ist eine analytische Schranke der Spoof-Erkennbarkeit, abgeleitet aus der Stabilität jeder Uhr — sie ist nur gegenüber einem konfigurierten Spoofing-Szenario aussagekräftig und kein RAIM-Detektor mit mehreren Satelliten. integrity ist hier die Selbstkonsistenz des Filters (Anteil der Ausfall-Samples innerhalb seiner eigenen k-Sigma-Schranke), keine HPL/VPL-Integritätskennzahl der Luftfahrt. Siehe docs/INTEGRITY.md.

Für echte empfängerautonome Integrität führt die Szenarioart integrity (scenarios/integrity-raim.toml) echtes Snapshot- und Solution-Separation-RAIM (nach Art von ARAIM) über der propagierten Konstellationsgeometrie aus: Sie berechnet horizontale/vertikale Schutzradien (HPL/VPL) pro Epoche und berichtet den Anteil der Epochen, die die konfigurierten Alarmgrenzen einhalten, mit einem Stanford-Integritätsdiagramm zur Klassifikation von Fehler gegen PL (protection level).

Reproduzierbare Studienartefakte

Vier offene Studien erzeugen jeweils ein byte-deterministisches Artefakt (fester Seed) aus einem Befehl neu — die Zahlen hinter den Studien zum Quanten-gegen-klassisch-Übergang, zur Optimismuslücke bei HF-Beeinträchtigungen, zur Bewertung der PNT-Resilienz und zum Zeitgebungs-Schutzradius:

# Quantum-vs-classical resilience crossover map (writes paper/crossover/*.json):
cargo run --release --bin crossover_study -- paper/crossover

# RF-impairment optimism-gap study (13-detector panel, scaling laws, LOO predictor):
cargo run --release --example optimism_study -- paper-artifacts/optimism-study.json

# Framework-aligned PNT-resilience scoring + decision-instability study:
cargo run --release --example resilience_report -- paper-artifacts/resilience-study.json

# Conditional Timing Protection Level, calibrated on a real recorded spoof:
cargo run --release --example tpl_jammertest

Jedes Artefakt hält seine Engine-Version, seine Seeds und einen Konfigurations-Hash fest und trägt ein ehrliches Label MODELLED/VALIDATED. Die Echtdaten-Sonden (*_probe) führen dieselbe Pipeline über Aufzeichnungen aus, die Sie lokal bereitstellen; im Repository werden keine Datensätze mitgeliefert. Die Studie zur Optimismuslücke bei HF-Beeinträchtigungen ist im Preprint arXiv:2606,22054 beschrieben und der bedingte Zeitgebungs-Schutzradius (tpl_jammertest oben) im Preprint arXiv:2606,24210 (siehe Zitieren).

Bei den veröffentlichten Studien zu Mond-PNT (arXiv:2607,06212 DOP von Oberflächenbaken, arXiv:2607,02566 VLBI-Beobachtbarkeit und arXiv:2610,23871 Beobachtbarkeit der Bogenlänge im cislunaren Raum) sind die Aussagen zu Geometrie, Dilution of Precision, Echtzeit-Vorhersage von Bezugssystem / Erdorientierungsparametern (EOP), retrograden Fernbahnen und HF-Entfernungsmessung in tests/validate_p*.rs unabhängig gegen getrennte unabhängige Referenzen gegengeprüft (scipy.special.j1, eine unabhängige NumPy-DOP-Lösung mit (HᵀH)⁻¹, ein NumPy-Neu-Parsen derselben IERS-finals2000A-Zeilen und die Three-Body Periodic Orbit Database von NASA/JPL). Dies sind zusätzliche Regressionsprüfungen über der modellierten Mond-Suite; sie ändern nichts an der maschinell geprüften Anzahl der Matrix.

Szenarioformat#

Szenarien sind deklaratives TOML. Ein kind auf oberster Ebene wählt das Pack — insgesamt fünfzig (clock ist der Standard, wenn er fehlt): inertial, timetransfer, hybrid, hybrid-ukf, fusion, gnss-ins, orbit, ephemeris, gnss-sim, integrity, lunar-integrity, lunar-time-offset, spoof, spoof-detect, jamming, sweep, sweep-nd, gravity-map, terrain-nav, terrain-slam, combined-altpnt, pvt, mars-pnt, impairment-eval (Testbed zur Bewertung der Erkennung von HF-Beeinträchtigungen mit maschinellem Lernen — gelabelter synthetischer Korpus + detektorunabhängiges ROC/AUC-Harness + Optimismuslücke zwischen Verteilung und Fremdverteilung), quantum-trade (PNT-Trade Quanten gegen klassisch mit Einlesen gemessener ADEV + Resilienzhüllkurve bei GNSS-Ausfall; MODELLED), space-weather (Sonnen-/geomagnetische Indizes + exosphärische Temperatur nach Jacchia-71 + aktivitätsgetriebene thermosphärische Dichte über der statischen Atmosphäre; MODELLED), oem-interop (CCSDS-OEM-Import/Round-Trip-Brücke für GMAT/Orekit/STK-Ephemeriden; MODELLED), das Missionsanalyse-Trio launch-window (Zwei-Körper-Startazimut / Ebenenwechsel / Gelegenheiten), reentry (ballistischer Wiedereintrittskorridor nach Allen-Eggers), eo-coverage (EO-Streifen- / GSD- / Zugriffs- / Wiederbesuchsgeometrie), space-packet (CCSDS-133,0-TM/TC — Telemetrie/Telekommando — Space-Packet-Rahmung — exaktes Bit-Layout, per Round-Trip verifiziert) und attitude-budget (3-DOF-Gravitationsgradienten-Drehmoment + RSS-Ausrichtungsfehlerbudget), passes (Vorhersage von Überflügen mit Auf-/Untergang an der Bodenstation — AOS/TCA/LOS, maximale Elevation, Zugriff) und link-budget (einseitige CCSDS/DSN-Streckengleichung — FSPL / Eb·N₀ / Marge / Schließung); telecom-timing (Holdover-Zeitfehler, MTIE und TDEV gegen ITU-T-Masken geprüft); spectrum (das gesamte GNSS-L-Band als eine spektrale Leistungsdichte: ein Frequenz-Zeit-Wasserfalldiagramm unter einer skriptgesteuerten Zeitleiste eines Dauerstrich-, Schmalband-, Chirp- oder rauschangepassten Störsenders, Störer-zu-Signal-Verhältnis je Band und effektive Träger-zu-Rauschleistungsdichte aus dem spektralen Trennkoeffizienten sowie Ein- und Ausgabe von Aufzeichnungen im Signal Metadata Format (SigMF) mit Welch-Spektralschätzungen; die Signalspektren VALIDATED gegen Lehrbuchwerte, das Störsender-Szenario MODELLED; siehe docs/SPECTRUM.md; dieselbe Art zeichnet UHF-, S- und C-Band-Panels mit entworfenen Signalen niedriger Erdumlaufbahn); leo-signal (Signalentwürfe für Positionierung, Navigation und Zeitgebung in niedriger Erdumlaufbahn für jedes System: bandbegrenzte Spektren, Code-Nachführ-Jitter und Entfernungsmessgenauigkeit, Akquisitionssuche und -zeit, spektrale Trennung gegen GPS und Galileo, Störfestigkeit und ein UHF-bis-C-Band-Trade, aus öffentlichen Presets wie Xona Pulsar, Iridium, Starlink und CentiSpace oder Inline-Entwürfen; die geschlossenen Formen und der LEO-Doppler VALIDATED, die Entwürfe MODELLED; siehe docs/LEO-SIGNAL.md); solar-system (die Sonne, die Planeten, Pluto, der Mond und sieben große Monde zu einer Epoche — Positionen, Konstanten, Lichtlaufzeiten und Bahnspuren; Planetenpositionen VALIDATED gegen JPL Horizons) und body-pnt (Positionierung um jeden dieser Körper mit einer lokalen Navigationskonstellation und einer Deep-Space-Strecke von der Erde; MODELLED); campaign (bestehende Arten, zusammengesetzt zu einer verketteten Missionszeitleiste mit zwischen den Phasen übergebenem Zustand, einem Parameter-Sweep, einem Monte-Carlo-Ensemble mit Seed oder mehreren Szenarien unter einer gemeinsamen Bedingung; MODELLED, siehe docs/CAMPAIGNS.md); constellation-design (Walker-Delta- und Walker-Star-Muster, Elementlisten und Mehrschalen-Entwürfe mit Presets für GPS, Galileo, BeiDou und GLONASS sowie Abdeckung und Dilution of Precision über einem Breiten-/Längengitter; der Generator und das globale GPS-DOP VALIDATED gegen die veröffentlichten Dienstdokumente, siehe docs/CONSTELLATION-DESIGN.md); leo-pass (ein Überflug eines Positionierungs-, Navigations- und Zeitgebungs-Satelliten (PNT) in niedriger Erdumlaufbahn (LEO) und sein Link-Budget Band für Band, aus jeder Konstellation und jedem Signalentwurf: Blickwinkel, Doppler und Doppler-Rate, ITU-R-Regen-, -Gas-, -Szintillations- und Gebäudeeindringungsdämpfung, Träger-zu-Rauschleistungsdichte gegenüber den sichtbaren MEO-GNSS-Satelliten, die Ionosphäre erster Ordnung und ionosphärenfreie Paare sowie ein Fix-Budget mit niedriger Energie, Ionosphärensondierung aus jedem Bandpaar und Spoofing-Monitore durch Doppler- und Überflug-Geometrie-Konsistenz und durch Konsistenz zwischen den Bändern; die ITU-R-Terme und die Doppler-Hüllkurve für ruhende Nutzer VALIDATED, der Überflug MODELLED, siehe docs/LEO-PASS.md); leo-navmsg (die Broadcast-Ephemeriden- und Uhrennachricht eines PNT-Satelliten in niedriger Erdumlaufbahn (LEO), für jede Bahn und jeden Träger: ein Fitter von einer integrierten Wahrheitsbahn auf den Galileo-Kepler-Satz, dieser Satz mit Korrekturpolynomen entlang der Bahn, quer zur Bahn und radial, das 22-Parameter-Modell von Liu et al. 2025 oder das ATOMIC-ECEF-Polynom mit Null-Uhr; Signal-in-Space-Entfernungsfehler (SISRE) gegenüber Fit-Intervall und Aktualisierungsperiode, eine Kontinuitätsprüfung bei Aktualisierung mitten im Überflug, das eigene dokumentierte Binärframe von Kshana mit einer zyklischen Redundanzprüfung CRC-24Q und einem Quantisierungsbudget sowie ein Block im RINEX-4-Stil, als Kshana-Erweiterung gekennzeichnet; die SISRE-Gewichte, der Galileo-Nutzeralgorithmus und CRC-24Q VALIDATED, die Fits MODELLED; optionale Presets für Xona Pulsar, Iridium, Starlink, CentiSpace, ein repräsentatives C-Band-System, ATOMIC und Celeste IOD; siehe docs/LEO-NAVMSG.md); das fusionierte MEO + LEO PNT-Trio leo-pvt (Doppler-Positionierung aus der Entfernungsrate von Satelliten in niedriger Erdumlaufbahn (LEO), gemeinsame GNSS- + LEO-Pseudorange-Fixes mit systemübergreifenden Biases und das DOP gegenüber der Anzahl der LEO-Satelliten, Polar- und Arktisabdeckung sowie LEO-Zeitübertragung zu UTC — über jede Konstellation, mit optionalen Presets wie Xona Pulsar, Iridium und Starlink als Gelegenheitssignalen; die LEO-Doppler-Hüllkurve VALIDATED gegen veröffentlichte Iridium- und Xona-Werte), leo-ppp (Konvergenz der präzisen Punktbestimmung nur mit GNSS und mit LEO-Augmentation, verglichen mit Li et al. 2019) und ntn-positioning (Positionierung über nichtterrestrische 5G-Netze aus der Cramér-Rao-Schranke der Signalbandbreite), außer dieser Hüllkurve MODELLED, siehe docs/LEO-PNT-FUSION.md; leo-pnt-chain (ein LEO-PNT-System von Anfang bis Ende: ein Entwurf leo-signal, getragen von einem Band leo-pass, das C/N0 des Überflugs und der Signal-in-Space-Entfernungsfehler der Navigationsnachricht, übergeben an einen fusionierten Fix leo-pvt und die Konvergenz leo-ppp, jede Übergabe aufgelistet; MODELLED, siehe docs/LEO-PNT.md, das zugleich die Übersicht über jede LEO-PNT-Art und jedes Szenario ist, einschließlich der Resilienzkampagnen, eines Szenarios je Schwerpunkt des Experiments und eines je Endnutzer-Vertikale); die Mond-PNT-Suite lunar-vlbi, lunar-joint-od-clock, lunar-frame-realisation, moonlight-service-volume, lunar-differential-pnt, lunar-interop-export; der quantengestützte PNT-Demonstrator quantum-time-transfer, quantum-gnss-free-nav, quantum-anomaly-detect; und die Forschungsarten zu Signalsicherheit, cislunarem Raum & mehrschichtiger Resilienz lunar-attack-surface, realtime-frame-eop, lunar-time-budget, hybrid-optical-rf, cislunar-observability, conflict-resilience — das Missionsanalyse-Trio und diese späteren Arten allesamt MODELLED (jeweils mit einem validierten Kern in geschlossener Form; siehe die Matrix). Gemeinsame Felder: seed, ein Raster [time], eine Verfügbarkeitszeitleiste [gnss] (der Ausfalltreiber) und Blöcke je Sensor mit provenance-Strings, die die Quelle jeder Kennzahl nennen. Beispiel (Uhr):

seed = 42
threshold_ns = 20.0
[time]
step_s = 10.0
duration_s = 7200.0
[gnss]
windows = [
  { t0 = 0.0,   t1 = 600.0,  state = "nominal" },  # 10 min GNSS sync
  { t0 = 600.0, t1 = 7200.0, state = "denied"  },  # ~1.8 h outage
]
[clock_quantum]
id = "optical-sr-lattice"
provenance = "Strontium optical lattice clock, space-oriented goal sigma_y(1s)=1e-15 (arXiv:1503.08457)"
y0 = 5.0e-17
q_wf = 1.0e-30   # white FM:  q_wf = sigma_y(1s)^2
q_rw = 0.0       # random-walk FM
drift = 0.0      # linear aging (per second)
[clock_classical]
id = "csac-sa45s"
provenance = "Microchip SA65 / SA.45s CSAC datasheet sigma_y(1s)=3e-10"
y0 = 5.0e-10
q_wf = 9.0e-20
q_rw = 0.0
drift = 0.0

Optionale Felder (aus, wenn nicht vorhanden): Eine Uhr kann flicker_floor hinzufügen (1/f-FM — Frequenzmodulation — Allan-Untergrenze); ein Inertialsensor kann gyro_bias und q_arw hinzufügen (Gyro-Bias und Winkel-Random-Walk) sowie bias_instability und q_aa (die Allan-Untergrenze der Bias-Instabilität und der Beschleunigungs-Random-Walk) — zusammen ein einachsiges (1-DOF) Fehlerbudget des Beschleunigungsmessers (VRW/ARW — Geschwindigkeits-/Winkel-Random-Walk — und Bias-Instabilität). Dies ist das Fehlerbudget, das das mitgelieferte Pack an inertial-Szenarien ausführt. Davon getrennt enthält die Bibliothek jetzt einen verifizierten 3-achsigen Strapdown-Navigator (src/inertial/{attitude,mechanization,imu_errors}.rs): Quaternionen-Lage mit Coning-/Sculling-Kompensation, eine vollständige NED-Mechanisierung (Erdrate- und Transportrate-Terme, Somigliana-Schwere nach WGS-84) und ein deterministisches IMU-Fehlermodell, in dem Skalenfaktor, Fehlausrichtung, g-Empfindlichkeit, Quantisierung und Ratenrampe modelliert werden (IEEE Std 952-1997, die IEEE-Norm für Gyro-Spezifikation und Testverfahren, §A.2; Groves 2013 §4,3). Dieser 3-achsige Pfad ist jetzt in ein lauffähiges lose gekoppeltes GNSS/INS-Pack eingebunden (kind = "gnss-ins"): Ein EKF mit 15 Fehlerzuständen diszipliniert die Strapdown-Lösung gegen verrauschte Fixes, solange GNSS verfügbar ist, läuft dann durch den Ausfall und berichtet den fusionierten horizontalen Fehler gegenüber dem offenen reinen INS-Auslauf. Eine eng gekoppelte Pseudorange-Aktualisierung ist ebenfalls verfügbar (sie bildet die Innovation im Entfernungsbereich und korrigiert daher auch mit weniger als vier Satelliten weiter). Ein Uhren-Holdover-Szenario kann runs (> 1) hinzufügen, um ein Monte-Carlo-Ensemble auszuführen — jede Kennzahl wird dann als Mittelwert mit einer Streuung vom 5. bis 95. Perzentil berichtet, und das Diagramm schattiert das Konfidenzband des Fehlers (siehe scenarios/clock-ensemble.toml).

Ein Szenario fusion (dieselben Blöcke wie hybrid) führt zwei unabhängige Kalman-Schätzer aus — einen für den Uhrenzustand, einen für den Positionszustand —, die von GNSS diszipliniert und durch optische Zeitübertragung gestützt werden, und berichtet ein kombiniertes Holdover-Gütemaß. Die beiden Blöcke teilen keine Kreuzkovarianz: Dies ist ein gestapeltes Paar von Fehlerbudgets, kein echtes gekoppeltes gemeinsames Uhren-+-Positions-Filter (blockübergreifende Kovarianz steht auf der Roadmap). Siehe scenarios/fusion-pnt.toml.

Ein Szenario spoof speist ein Zeit-Spoofing ein — eine von vier Arten [attack.shape] (linear_ramp, step_jump, meaconing, replay; ein bloßes rate_ns_per_s wird weiterhin als lineare Rampe akzeptiert) — und führt den Spoof-Detektor jeder Uhr aus. Der Detektor ist ein zweiseitiger χ²₁-Energie- / Neyman-Pearson-Test auf der uhrengestützten Monitorstatistik: Die Schwelle wird aus einem Zielbudget für Fehlalarme target_pfa festgelegt, und die Wahrscheinlichkeit einer Fehldetektion P_md wird sowohl in geschlossener Form als auch per Monte-Carlo berichtet (mc_runs Versuche je Hypothese — beide stimmen bis auf wenige ×1/√N überein). Das Sicherheits-Gütemaß ist 1 − P_md bei der betrieblich schädlichen (Vorgabe-)Größe, sodass eine ruhige Uhr, die einen Spoof in Vorgabegröße erkennt, ≈ 1 erreicht und eine verrauschte, die ihn oft verfehlt, weniger (siehe scenarios/spoof-attack.toml, scenarios/spoof-meaconing.toml).

Ein Szenario gnss-sim ist eine Simulation im Messungsbereich: Für jeden sichtbaren Satelliten synthetisiert es die Pseudorange ρ = geometric range + c·δt_rx − c·δt_sv + I + T + noise + multipath und den L1-Doppler, mit der Einfrequenz-Ionosphäre nach Klobuchar ([iono], IS-GPS-200 §20.3.3.5.2.5) und der Zenit-Troposphäre nach Saastamoinen, projiziert mit der Abbildungsfunktion von Niell (1996) ([tropo]). Die Residuen speisen das Snapshot-RAIM für HPL/VPL je Epoche, und Pseudorange, Doppler, C/N₀ sowie Iono-/Tropo-Korrekturen jedes Satelliten werden im JSON-Array gnss_measurements ausgegeben. Es ist ein Vorwärtssimulator (er erzeugt Messungen aus einer bekannten Wahrheit), kein Empfänger/Löser — ein rauschfreier Lauf reproduziert die Geometrie plus die Korrekturen im Sub-Millimeter-Bereich (siehe scenarios/gnss-sim-raim.toml).

Ein Szenario jamming modelliert HF-Störung als Link-Budget: Ein [jammer] (ECEF-Position, Sende-power_dbw, Typ) erhöht das Störer-zu-Signal-Verhältnis an einem [receiver], der eine Walker-[constellation] beobachtet. Aus der Geometrie (Freiraumdämpfung und der richtungsabhängige Empfangsantennengewinn) berechnet es das J/S jedes Satelliten und das effektive C/N₀ über die Standard-Anti-Jam-Gleichung (Entspreizungs-Prozessgewinn × der spektrale Trennfaktor Q; Kaplan & Hegarty §9,4) und markiert den Verlust der Nachführung unterhalb einer konfigurierbaren Nachführschwelle — und berichtet ein Gütemaß availability_under_jamming. Ein Breitband-Störsender mit 10 W in 1 km Entfernung unterbindet den Empfang vollständig (J/S ≈ 72 dB); derselbe Störsender in 100 km beeinträchtigt die Links nur (siehe scenarios/jamming-demo.toml).

Ein Szenario sweep führt eine Trade-Studie aus: Es variiert einen parameter (threshold_ns, duration_s, quantum_q_wf oder classical_q_wf) von start bis stop über steps Punkte auf einer lin- oder log-scale, erfasst für beide Uhren eine metric (z. B. holdover_s) und zeichnet die beiden Kurven. Das Basisszenario steht unter [base] (siehe scenarios/sweep-clock-stability.toml).

Ein Szenario sweep-nd verallgemeinert dies auf jedes Pack und beliebig viele Achsen: Es variiert gepunktete TOML-Schlüssel eines Szenarios [base] (von beliebiger kind) über das kartesische Produkt von [[axes]], führt jeden Rasterknoten erneut aus und erfasst metrics, angegeben als gepunktete JSON-Pfade in das Ergebnis (z. B. classical.fom.holdover_s). Es funktioniert für jedes Pack, weil es an der Grenze zwischen TOML und Ergebnis arbeitet; native Läufe werten das Raster parallel aus (keine zusätzliche Abhängigkeit, wasm fällt auf sequenziell zurück), und die Ausgabe ist deterministisch und zeilenweise geordnet (siehe scenarios/sweep-nd-inertial.toml).

Ein Szenario orbit leitet die Zeitleiste [gnss] aus der Geometrie ab, statt sie zu verfassen — geben Sie eine Bahn [user], eine [constellation], eine Elevationsmaske mask_deg und die beiden Uhrenblöcke an. Es berichtet außerdem die Positionsgenauigkeit aus der Satellitengeometrie; der optionale Wert sigma_uere_m (1-Sigma-Nutzer-Entfernungsfehler, Standardwert 1 m) skaliert die Positions-Dilution-of-Precision zu einem Positions-Sigma. Die Nutzerbahn kann mit eccentricity und argp_deg exzentrisch gemacht werden, und j2 = true fügt die säkulare Drift durch die Erdabplattung hinzu (siehe scenarios/orbit-molniya.toml). Die Konstellation kann stattdessen eine reale sein: Geben Sie [constellation] einen Block tle mit Zweizeilen-Elementesätzen, und die Satelliten werden daraus geparst (siehe scenarios/orbit-real-tle.toml). Fügen Sie einen oder mehrere Blöcke [[constellations]] für Multi-GNSS hinzu (z. B. GPS + Galileo; siehe scenarios/orbit-multignss.toml):

kind = "orbit"
seed = 7
threshold_ns = 5.0
mask_deg = 10.0
sigma_uere_m = 1.0           # optional; position sigma = position-DOP * this
[time]
step_s = 60.0
duration_s = 86400.0
[user]                       # spacecraft (altitude in km, angles in deg)
altitude_km = 8000.0
inclination_deg = 0.0
[constellation]              # Walker-delta GNSS (GPS-like)
altitude_km = 20180.0
inclination_deg = 55.0
planes = 6
sats_per_plane = 4
phasing_f = 1.0
[clock_quantum]  # ... as above
[clock_classical]  # ... as above

Die Arten für GPS-freies Alt-PNT navigieren ganz ohne GNSS und gleichen dabei eine gemessene Feldsequenz über einen Partikelfilter mit einer Karte ab. Ein Szenario gravity-map fliegt einen Kurs durch ein Schwereanomalie-Feld aus Kugelfunktionen und stellt ihn aus der Messung eines Kaltatom-Gravimeters wieder her (scenarios/gps-denied-gravity-nav.toml); ein Szenario terrain-nav tut dasselbe gegen ein SRTM-Höhen-DEM (TERCOM/SITAN, scenarios/terrain-nav.toml); und ein Szenario combined-altpnt fusioniert Schwere + IGRF-Magnetfeld + Gelände in einem Filter (scenarios/combined-altpnt.toml).

Ein Szenario lunar-integrity bewertet cislunares PNT: Es führt einen ARAIM-Schutzradius-Durchlauf am lunaren Südpol gegen einen LunaNet/LNIS-Relaissatz aus und berichtet die Integritätslücke ehrlich — ein lunares σ_URE von ~30 m treibt den Schutzradius weit über eine Alarmgrenze von 50 m, sodass der Dienst unter Integritätsregeln nach Art der Luftfahrt nicht verfügbar ist (scenarios/lunanet-araim.toml).

Ein Szenario lunar-time-offset berichtet die relativistische Uhrenrate Erde–Mond — die Grundlage einer Mond-Koordinatenzeitskala (LTC/TCL). Eine post-newtonsche Identität aus ersten Prinzipien summiert die Differenz der Eigenpotenziale (IAU-L_G-Geoidpotenzial minus das Eigenpotenzial der Mondoberfläche) und den kinetischen Term des Mondes (Doppler zweiter Ordnung) zu einer säkularen Rate von ≈ 57 µs/Tag, berichtet mit dem veröffentlichten Band von 56–59 µs/Tag; es gibt außerdem den aufgelaufenen LTC−TT-Offset über einen Horizont und ein Ensemble mit inverser Varianz an (eine lunare Papieruhr). MODELLED — die Kernzahl ist referenzabhängig (Erdgeoid gegenüber Mond-Selenoid, Mittelungsfenster), weshalb ein Band und nicht eine einzelne zertifizierte Zahl berichtet wird (scenarios/lunar-time-offset.toml).

Siehe scenarios/ für mindestens ein ausgearbeitetes Beispiel jeder Art (92 Arten, 193 Szenario-Dateien .toml + 1 Suite-Manifest — mehrere Arten liefern mehr als ein Beispiel mit). Nicht jede Art hat eine nach ihr benannte Datei: lunar-integrity → scenarios/lunanet-araim.toml und gravity-map → scenarios/gps-denied-gravity-nav.toml sind zwei von mehreren solchen. Listen Sie die verteilbaren Arten jederzeit auf mit cargo run -- --validate <file>-Fehlern, dem Python-list_kinds() oder dem MCP-Werkzeug list_scenario_kinds.

Ausgabe#

Das Ergebnisartefakt ist versioniertes, selbstbeschreibendes JSON: Zeitreihen je Schritt, die bewerteten Gütemaße, die aktiven Modellspezifikationen (mit Herkunft), der Seed, ein Szenario-Hash — damit sich jedes Diagramm aus der Datei reproduzieren lässt — und für jede Uhr eine adev_curve ([{tau_s, adev, n_samples, noise, edf, ci_lo, ci_hi}]): die überlappende Allan-Abweichung über oktavweise gestufte Mittelungszeiten — die übliche Art, die Stabilität einer Uhr zu lesen — jetzt mit einem rauschtypspezifischen 95-%-Konfidenzband je Punkt (der Potenzgesetz-Typ der Aufzeichnung wird aus ihrer Steigung der modifizierten Allan-Abweichung bestimmt, und das χ²-Intervall verwendet die passenden effektiven Freiheitsgrade nach NIST SP 1065). Der Browser-Playground stellt es als doppelt logarithmisches Diagramm „Clock stability (ADEV)“ dar. (MDEV, TDEV und HDEV stehen als Bibliotheksschätzer zur Verfügung; die exportierte Ergebniskurve ist die überlappende ADEV.) Jedes Feld mit Einheiten und einem Quellverweis ist in docs/SCHEMA.md dokumentiert.

Jedes Diagramm ist selbstbeschreibend. Der Browser-Playground, der Export *.chart.svg der CLI und die HTML-Scorecard (HyperText Markup Language) versehen jedes Diagrammbild mit einer Fußzeile mit dem Wortlaut Kshana v<version> · scenario <hash> · kshana.dev. Das scenario <hash> sind die ersten 12 Hex-Zeichen des Szenario-Hashs des Laufs — ein SHA-256-Digest (der 256-Bit Secure Hash Algorithm) über die kanonische Szenariodefinition (Seed, Schwellen, Modellparameter, GNSS-Fenster, …); die Integritäts- und Mondberichte, die keinen eigenen Hash tragen, greifen auf ein SHA-256 des Szenarioquelltexts zurück. Es ist derselbe Fingerabdruck, der in der einzeiligen Zusammenfassung und im Ergebnis-JSON steht, sodass ein gespeichertes oder eingefügtes Diagramm immer seine Version, das genaue Szenario, das es erzeugt hat (für die bitgenaue Reproduktion), und die Quelle trägt — ändert man eine Eingabe, ändert sich der Hash.

Die Gütemaße folgen den üblichen betrieblichen PNT-Gütemaßen:

Neu bei diesen Begriffen? Jeder ist im Glossar in einfacher Sprache erklärt.

Repository-Aufbau#

kshana/
├── src/                                       # the kshana core crate (library + CLI)
│   ├── api.rs · main.rs · lib.rs              # typed dispatch (92 kinds) + CLI + crate root
│   ├── python.rs · wasm.rs                    # optional PyO3 / wasm-bindgen bindings
│   ├── types.rs · scenario.rs · allan.rs      # shared core (time grid, GNSS timeline, Allan)
│   │
│   ├── models.rs · estimator.rs · kalman.rs   # Pack 1 — clock holdover + integrity
│   ├── security.rs · detection.rs · spoof.rs · spoof_monitors.rs  # spoof detection
│   ├── filter_health.rs · fom.rs · fom_label.rs · report.rs · chart.rs · run.rs  # health · FoM scoring + labelling · output
│   ├── suite.rs · study.rs                     # scenario suites + aggregated multi-scenario study artifacts (`--study`)
│   ├── inertial/                              # Pack 2 — strapdown INS (attitude · mechanization · imu_errors · quantum_imu)
│   ├── timetransfer.rs · timetransfer_adv.rs · timegeo.rs  # Pack 3 — TWSTFT/CV/PPP/optical, Sagnac
│   ├── hybrid.rs · ensemble.rs · sweep.rs     # Pack 4 — fused PNT, Monte-Carlo, trade sweeps
│   │
│   ├── timescales.rs · jd2.rs · ephem.rs      # time systems, two-part JD, Sun/Moon ephemeris
│   ├── precession.rs · nutation.rs · cio.rs   # IAU 2006/2000A precession-nutation + CIO GCRS↔ITRS
│   ├── frames.rs · *_data.rs                  # TEME↔ECEF + generated nutation/CIO/EGM2008/IGRF tables
│   │
│   ├── orbit.rs · sgp4.rs · tle.rs · walker.rs   # geometry, SGP4/SDP4, TLE, Walker design
│   ├── propagator.rs · forces.rs · gravity_sh.rs · integrator.rs  # Cowell + perturbations (EGM2008 d/o70, GR) + RK4/DOPRI
│   ├── maneuver.rs · batch_ls.rs · orbit_determination.rs  # burns/Lambert/porkchop, Gauss-Newton, OD
│   ├── cr3bp.rs · lunar.rs · lunar_frame.rs · lunar_od.rs  # Earth–Moon CR3BP + halo/NRHO STM corrector, cislunar/LunaNet ARAIM, MCI↔MCMF, lunar OD
│   ├── lunar_time.rs · lunar_vlbi.rs · lunar_combination.rs · lunar_frame_realise.rs · lunar_service.rs · lunar_dpnt.rs · lunar_interop.rs  # tiers per piece in the matrix lunar PNT suite — LTC time · geodetic VLBI · joint OD+clock · frame realisation · Moonlight service-volume · differential PNT · LunaNet/IOAG interop export
│   ├── body.rs · mars_frame.rs · ephem_provider.rs · radiometric.rs · ccsds_tdm.rs  # deep-space: multi-body · Mars frame · ephemeris seam · radiometric obs + CCSDS-TDM
│   ├── deepspace_od.rs · clock_state.rs · mars_atmos.rs · mars_pnt.rs · linkbudget.rs · gse_sim.rs  # SRIF OD · onboard clock · Mars drag · relay-PNT · link budget · GSE sim
│   │
│   ├── fusion/                                # GNSS/INS — EKF · UKF · tightly_coupled(17) · coupled · closed_loop
│   ├── raim.rs · sbas.rs                      # RAIM/ARAIM HPL/VPL, SBAS DO-229E PLs + L1/L5 iono-free
│   ├── gnss_sim.rs · ionex.rs · pvt.rs · jamming.rs  # measurement domain · ionosphere maps · single-point positioning · jamming
│   ├── navsignal.rs                            # nav-signal PSD (BPSK-R/BOC) · spectral-separation → anti-jam Q · DLL code-tracking jitter · multipath envelope
│   ├── gravimeter.rs · igrf.rs · mapmatch.rs · particle_filter.rs · altpnt/  # gravity/magnetic/terrain alt-PNT
│   ├── rinex.rs · rinex_obs.rs · glonass.rs · sp3.rs · oem.rs · omm.rs · permalink.rs  # interop formats
│   ├── launch.rs · reentry.rs · eo_payload.rs · attitude_budget.rs · passes.rs · space_packet.rs  # mission-analysis budgets + CCSDS Space Packet
│   ├── space_weather.rs · holdover.rs · tpl.rs   # space-weather environment · GNSS-denied clock-holdover calculator · conditional Timing Protection Level (under spoofing)
│   ├── resilience/                              # framework-aligned PNT-resilience scoring + decision-instability study (RPCF · Dirichlet · Kendall-τ · diversity collapse · assurance report)
│   ├── impairment_eval.rs · impairment_study.rs · impairment_ml.rs · eval_stats.rs  # Machine-learning RF-impairment eval testbed · optimism-gap study · LR/MLP detectors · bootstrap/DeLong/Spearman stats
│   ├── sdr.rs · realdata/                       # software-defined-receiver front end (IQ/IF → E/P/L taps → SQM) + real-data ingest adapters (RINEX · UBX · GnssLogger · JammerTest · Yunnan · SatGrid)
│   ├── crossover.rs · quantum_trade.rs · frugal.rs · integrity_impact.rs  # quantum-vs-classical crossover map · PNT trade · cost-per-coverage ROI · integrity impact
│   ├── quantum_devices.rs · quantum_faults.rs · quantum_nav_od.rs · qtrade.rs · timetransfer_chain.rs · representativeness.rs  # Quantum-Enabled PNT demonstrator — device error models · fault catalogue · GNSS-free quantum OD · unified trade harness · quantum time-transfer chain · representativeness / gaps-to-flight ledger
│   ├── interchange.rs · verification.rs          # KIF artifact envelope · machine-checked verification matrix
│   └── bin/crossover_study.rs · bin/validation_report.rs  # crossover-study artifact generator · release validation-summary HTML
│
├── mcp/kshana-mcp/        # standalone, workspace-EXCLUDED crate — the MCP server (+ Dockerfile, server.json)
├── ide/jetbrains/         # standalone Kotlin/Gradle IntelliJ-Platform plugin
├── xval/                  # standalone, workspace-EXCLUDED external cross-checks: anise-{frames,lunar-od,mars-od,service-geometry} (Rust ANISE/SPICE DE440) + orekit-passes (Java Orekit)
│
├── examples/            # reproducible study generators: tpl_jammertest · resilience_report · optimism_study + real-data probes (jammertest_probe · yunnan_probe · satgrid_probe · texbat_probe · ingest_realdata)
├── paper-artifacts/     # byte-deterministic study artifacts, regenerable from examples/ (optimism-study.json · resilience-study.json); raw datasets stay out
├── scenarios/            # one cited .toml per kind + geometry-driven + GPS-denied
├── scripts/              # reproducibility + repo-hygiene + SBOM guards
├── docs/                 # CONCEPTS, ARCHITECTURE, CAPABILITY, VALIDATION, PROVENANCE, GLOSSARY, …
├── web/                  # the WebAssembly playground + kshana.dev site
├── tools/                # table generators (EGM2008 · IGRF · nutation · CIO) + fetch_tles.sh
├── .github/workflows/    # ci · release · publish · wheels · pages · mcp-publish · jetbrains-plugin · frame-xval
├── pyproject.toml        # Python packaging (maturin)
├── CHANGELOG.md          # Keep a Changelog + SemVer
└── CITATION.cff · ROADMAP.md · CONTRIBUTING.md · SECURITY.md

FAQ#

Muss ich Quantenphysik verstehen, um das zu nutzen? Nein. Wenn Sie eine Kommandozeile bedienen können, können Sie Kshana ausführen. Beginnen Sie mit der Einführung in einfacher Sprache; schlagen Sie Begriffe im Glossar nach.

Ist das ein Entwurf für Quantenhardware oder Flugsoftware? Nein. Es ist ein Simulator für die Leistung. Die Genauigkeit der Quantenhardware stammt aus veröffentlichten Fehlermodellen, nicht aus diesem Werkzeug. Siehe Was es ist / nicht ist.

Sind die Quantenergebnisse realistisch oder Marketing? Jeder Parameter ist mit einem Datenblatt oder Paper belegt, jedes Modell ist gegen eine Lehrbuchbeziehung validiert, und der Reifegrad ist in VALIDATION.md ehrlich gekennzeichnet — einschließlich der Tatsache, dass noch keine optische Strontiumuhr geflogen ist. Die Engine ist neutral: Quanten und klassisch sind derselbe Code mit unterschiedlichen veröffentlichten Zahlen.

Kann ich darauf vertrauen, dass zwei Läufe übereinstimmen? Ja — Läufe sind deterministisch: scenario + seed + engine version → bit-identical output, durchgesetzt von scripts/check-reproducible.sh.

Kann ich es aus Python oder in einem Browser nutzen? Ja — siehe Installation: Die Python- und WebAssembly-Beispiele stehen darunter. Beide rufen dieselbe Engine auf.

Wie modelliere ich meinen eigenen Sensor? Schreiben Sie ein Szenario .toml mit den veröffentlichten Kennzahlen Ihres Sensors in den Feldern provenance. Siehe Szenarioformat und die Beispiele in scenarios/.

Ist es für die kommerzielle Nutzung kostenlos? Ja — unter der AGPL-3.0, auch in kommerziellen Umgebungen, solange Sie das Copyleft der AGPL einhalten (insbesondere: Wenn Sie Kshana ändern und über ein Netzwerk anbieten, müssen Sie diesen Nutzern Ihren geänderten Quelltext anbieten). Wenn das nicht passt — z. B. weil Sie Kshana in ein proprietäres Produkt einbetten oder einen geschlossenen Netzwerkdienst betreiben müssen —, ist von Ashforde® OÜ eine kommerzielle Lizenz erhältlich; siehe LICENSING.md und Support.

Fehlerbehebung#

cargo build schlägt mit einer alten Toolchain fehl. Kshana braucht Rust ≥ 1,88. Aktualisieren Sie mit rustup update.

Der Build der Python-Erweiterung lässt sich unter macOS nicht linken (Undefined symbols … _Py…). Eine Python-Erweiterung löst ihre Symbole zur Ladezeit auf. maturin setzt das richtige Linker-Flag automatisch — verwenden Sie maturin develop --features python statt eines bloßen cargo build.

Der Python-Build beanstandet, der Interpreter sei neuer, als PyO3 kennt. Setzen Sie PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 (abi3-Wheels sind über CPython-Versionen hinweg vorwärtskompatibel).

Der WebAssembly-Build findet das Target nicht. Installieren Sie es einmalig mit rustup target add wasm32-unknown-unknown, dann wasm-pack build --target web -- --features wasm.

Wo ist meine Ausgabe geblieben? Jeder Lauf schreibt <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html und <scenario>.report.json neben die Eingabe .toml, und <scenario>.table.csv ebenfalls für die Arten, die eine Tabelle veröffentlichen. Alle sind bewusst von git ignoriert.

Versionierung & Releases#

Kshana folgt Semantic Versioning. Solange es vor 1.0 ist, kann sich das öffentliche Szenario-/Ergebnisschema noch ändern; inkompatible Änderungen werden im CHANGELOG.md ausdrücklich genannt. Jedes Ergebnis ist aus scenario + seed + engine version reproduzierbar.

Jeder Tag vX.Y.Z veröffentlicht automatisch alle Kanäle, in einer Reihenfolge — zuerst läuft die vollständige Testsuite auf dem getaggten Commit, nichts wird veröffentlicht, bis sie besteht, und danach prüft die Pipeline, dass jede Registry tatsächlich die neue Version ausliefert (docs/RELEASING.md). Die Kanäle:

Die Crate-/Image-/Registry-Version des MCP-Servers folgt der Engine (er bündelt die Bibliothek); das JetBrains-Plugin wird unabhängig versioniert (es ruft Ihre installierte Binärdatei kshana auf).

Roadmap#

Siehe ROADMAP.md für die phasenweise Roadmap, CHANGELOG.md für die veröffentlichte Historie und docs/CAPABILITY.md für die Roadmap je Fähigkeit. Die Prioritätsreihenfolge lautet: zuerst Zeitgebungs- und Holdover-Evidenz für kritische Infrastruktur (Telecom-Masken, längerer Holdover mit Alterung und Flickerrauschen, Einlesen gemessener Uhrendaten); an zweiter Stelle die neutrale Trade-Methode Quanten gegen klassisch (Ergebnisse als MODELLED gekennzeichnet, bis gemessene Daten eines Partners sie heraufstufen); und Navigation für Mond / cislunaren Raum und Deep Space wird gepflegt, nicht als Schwerpunkt ausgebaut. Die ITRF-präzise Bezugssystem-Reduktion ist jetzt geliefert — die vollständige CIO-basierte Kette IAU 2006/2000A GCRS↔ITRS (Polbewegung + Nutation unter einer Bogensekunde), bitgenau gegen SOFA/ERFA validiert und unabhängig gegen ANISE (reines Rust-SPICE) auf ≤ 3,6 m in der GNSS-Bahn gegengeprüft. Zu den kurzfristigen Punkten gehören eng gekoppelte Trägerphasen-Fusion und die Bereitstellung des lose/eng gekoppelten GNSS/INS-Navigators in mehr Packs; die radiometrische Navigations-Engine für Deep Space / Mars wurde in v0.17.0 geliefert (simulationsvalidiert). Die Quantenphysik-Schicht ist ein Punkt P2: Der CAI-Beschleunigungsmesser wird jetzt aus ersten Prinzipien simuliert (Mach-Zehnder-Phase, Projektionsrauschen, Kontrastabfall, Vibrationskopplung), während die Uhren-/Zeitübertragungssensoren weiter über veröffentlichte Koeffizienten für Allan/Rauschbudget angetrieben werden. GMST-basiertes TEME↔ECEF, die Zeitsysteme der IERS mit Schaltsekunden (UTC/TAI/TT/UT1), die SGP4/SDP4-Bahnpropagation (v0.7.0, validiert gegen die Vektoren AIAA 2006-6753) und das lauffähige Fusions-Pack gnss-ins sind alle ausgeliefert, und die Inertialgeschwindigkeit wird nachgelagert bereitgestellt. Ein aktiver stochastischer Zeit-Spoof-Detektor (Neyman-Pearson- / χ²₁-Energietest mit Monte-Carlo-P_fa/P_md und einem Sicherheits-Gütemaß von 1−P_md), ein Link-Budget-Jamming-Modell (J/S → effektives C/N₀ → Verlust der Nachführung), Verfügbarkeit mit mehreren Konstellationen, ein einachsiges (1-DOF) IMU-Fehlerbudget, zwei unabhängige (Uhr + Position) Kalman-Schätzer, berichtet als kombiniertes Gütemaß, reale Konstellationsgeometrie aus TLEs, ein HTML-Scorecard-Bericht, aus der Geometrie abgeleitete GNSS-Verfügbarkeit und Dilution of Precision aus Kepler-Bahnen mit Exzentrizität und J2-Drift, Monte-Carlo-Konfidenzbänder, Parameter-Sweeps für Trade-Studien, ein WebAssembly-Playground im Browser sowie optionale Bindings für Python (PyO3) und WebAssembly (wasm-bindgen) sind auf main gelandet.

Mitwirken#

Siehe CONTRIBUTING.md. Kurz: Die Tests bestehen (cargo test), die beiden Guard-Skripte bestehen, Conventional Commits, und ein Eintrag [Unreleased] in CHANGELOG.md für jede für Nutzer sichtbare Änderung. Die Teilnahme unterliegt unserem Verhaltenskodex. Um ein Sicherheitsproblem zu melden, siehe die Sicherheitsrichtlinie — bitte eröffnen Sie für Schwachstellen kein öffentliches Issue.

Dokumentation#

Wichtige Referenzen#

Validierungs-Referenzen & Standards — die externen Autoritäten, an die die Prüfungen von Kshana angebunden sind:

• Vallado, Crawford, Hujsak & Kelso — Revisiting Spacetrack Report #3 (AIAA 2006-6753; Testdaten): der SGP4/SDP4-Verifikationssatz, mit dem Kshana auf 4,12 mm übereinstimmt, und die durchgerechneten Bezugssystem-Beispiele, gegen die die Kette TEME→ITRF geprüft wird.
• IAU SOFA / ERFA — die Referenzroutinen für Zeit und Bezugssysteme, gegen die die IAU-2000A-Nutation und die CIO-GCRS↔ITRS-Reduktion bitgenau validiert werden.
• Petit & Luzum (Hrsg.) — IERS Conventions (2010), IERS TN (Technical Note) 36 (Standards zu Erdorientierung, Polbewegung und Bezugssystemen).
• Riley — Handbook of Frequency Stability Analysis, NIST SP 1065 (Beziehungen der Allan-Abweichung und die Referenzreihe NBS14; NBS = das frühere US National Bureau of Standards).
• Pedregosa et al. — scikit-learn: Machine Learning in Python, JMLR 12 (2011): die Referenzimplementierungen für ROC/AUC, Konfusionsmatrix und Precision/Recall/F1, an die das Bewertungs-Testbed für HF-Beeinträchtigungen exakt angeglichen ist (tests/eval_metrics_reference.rs).
• Virtanen et al. — SciPy 1,0, Nature Methods 17 (2020): optimize.nnls, stats.chi2 und linalg.expm — die Referenzroutinen, gegen die die NNLS-Anpassung der gemessenen ADEV im Quantum-Trade, die χ²-Konsistenzbänder und die van-Loan-Prozessrauschen-Kovarianz der Uhr validiert werden (tests/scipy_reference.rs).
• Knowles, Kanhere, Neamati & Gao — gnss_lib_py, SoftwareX 27 (2024): verwendet sowohl als offener Stand der Technik (siehe Vergleich & offener Stand der Technik unten) als auch als unabhängige DOP-Referenz, an die die Berechnung von GDOP/PDOP/HDOP/VDOP/TDOP auf 1e-6 angeglichen ist (tests/dop_reference.rs).
• Montenbruck & Gill — Satellite Orbits: Models, Methods and Applications (Springer): die Kräftemodelle hinter der Anpassung des Kräftemodells an präzise Behörden-Ephemeriden.
• Howell — Three-dimensional, periodic, halo orbits, Celestial Mechanics 32(1) (1984), doi:10.1007/BF01358403; Zimovan-Spreen, Howell & Davis — Near rectilinear halo orbits and nearby higher-period dynamical structures, Astrodynamics 6 (2022), doi:10.1007/s42064-021-0125-x (die Halo-/NRHO-Familien, die der CR3BP-Differentialkorrektor reproduziert).

Physik von Geräten & Methoden — die zitierten Quellen hinter den Sensormodellen:

• Origlia, Schiller, Bongs et al. — arXiv:1503,08457 (optische Strontium-Gitteruhr, raumfahrtorientiertes Ziel).
• Oelker et al., Nature Photonics (2019) — doi:10.1038/s41566-019-0493-4 (Sr-Uhr im Labor, 4,8×10⁻¹⁷).
• Templier et al., Science Advances (2022) — arXiv:2209,13209 (hybrides Quanten-Beschleunigungsmesser-Triple).
• Groves, Principles of GNSS, Inertial, and Multisensor Integrated Navigation — IEEE-AESS-Tutorial (Aerospace and Electronic Systems Society; Discovery-Repository des University College London) (Fehlerwachstum bei Koppelnavigation).
• Giorgetta et al., Nature Photonics 7, 434 (2013) — arXiv:1211,4902; Deschênes et al., Phys. Rev. X 6, 021016 (2016) — APS (American Physical Society) (optische Zwei-Wege-Zeit-Frequenz-Übertragung; die optische Inter-Satelliten-Verbindung modelliert ihr Budget der Nichtreziprozität nach diesen).
• Betz — Binary Offset Carrier Modulations for Radionavigation, NAVIGATION 48(4) (2001), doi:10.1002/j.2161-4296.2001.tb00247.x (die BOC-Modulations- und Spektraltrennungstheorie hinter src/navsignal.rs).
• Kaplan & Hegarty (Hrsg.) — Understanding GPS/GNSS: Principles and Applications (3. Aufl., Artech House, 2017): die Anti-Jam-Gleichung für das effektive C/N₀ und der thermische Rausch-Jitter der Early-Late-DLL-Code-Nachführung, den die Modelle für Navigationssignale und Jamming verwenden.

Vergleich & offener Stand der Technik — die Werkzeuge und Übersichten, gegen die Kshana positioniert ist:

• Humphreys et al. — TEXBAT (die Texas Spoofing Test Battery; ION — Institute of Navigation — GNSS 2012): die Parameter der Spoofing-Testbatterie, gegen die der mehrschichtige Detektor charakterisiert wird.
• González et al. — NaveGo (2017): die offenen, validierten Fehlerprofile der Inertialnavigation, die als klassische Basislinie verwendet werden.
• Iiyama, Casadesús Vila & Gao — LuPNT (ION GNSS+ 2023, Stanford NavLab): offener Mond-PNT-Simulator.
• Knowles, Kanhere, Neamati & Gao — gnss_lib_py, SoftwareX 27 (2024), doi:10.1016/j.softx.2024.101811: offene GNSS-Datenanalyse.
• Li, Zaminpardaz, Kealy & Greentree — Quantum sensors for enhanced positioning and navigation: a comprehensive review, GPS Solutions 30(1):62 (2026), doi:10.1007/s10291-026-02030-y.
• Bertone et al. — Earth and Space Science 8(6) (2021), doi:10.1029/2020EA001454: GRAIL-Bahnbestimmung (reduziert-dynamisch), die Untergrenze der empirischen Beschleunigung, die die LRO-Anpassung reproduziert.