Änderungsprotokoll

Alle nennenswerten Änderungen an Kshana sind hier dokumentiert.

Das Format basiert auf Keep a Changelog, und dieses Projekt hält sich an Semantic Versioning. Solange das Projekt vor 1.0 ist, kann sich das öffentliche Schema für Szenarien und Ergebnisse noch ändern; inkompatible Änderungen werden ausdrücklich genannt.

Unveröffentlicht#

[0.40.0] - 2026-10-29#

0,40 fügt den Missionsstrang im Stil von Artemis und sein Mondsegment hinzu, eine Nachweiskennzeichnung an jeder Zahl und Tabelle, die ein Lauf schreibt, das Einlesen und Anpassen gemessener Uhren, eine Prüfung für Einreichungen von Datenpartnern, eine geschätzte Senderregion aus ADS-B- oder AIS-Meldungen, die Benchmark-Neukampagne 0,40 sowie die Befehlszeile, Berichte und Studio in siebzehn Sprachen neben Englisch (maschinenlesbare Dokumente bleiben Englisch). Die Verifikationsmatrix wächst von 388 auf 401 Zeilen: 176 VALIDATED (unverändert), 221 MODELLED (vorher 208) und 4 PARTNER. Keine Zeile wurde zu VALIDATED befördert. Die Szenarioarten wachsen von 87 auf 92. Jeder Zielwert, den ein vorab festgelegter Vergleich verfehlt hat, ist unten genannt und bleibt festgeschrieben; keiner wurde gelockert. Die Hinweisaussage ist unverändert: Kshana ist beratende Software, keine typzugelassene Navigationsausrüstung und keine Zertifizierung; der Betreiber bleibt verantwortlich.

Bekannte Grenzen#

• Läufe in anderen Sprachen dauern etwa doppelt so lange, weil das Szenario zweimal läuft (einmal auf Englisch für die maschinenlesbaren Dateien, einmal in der gewählten Sprache für die Person).
• Einige Sätze im Studio werden aus Fragmenten zusammengesetzt und können in Sprachen mit grammatischem Geschlecht Artikel vermissen lassen.
• Die Übersetzungen sind maschinelle Übersetzungen, die kein Muttersprachler geprüft hat; Englisch ist die Referenz.

Hinzugefügt#

• Siebzehn Sprachen neben Englisch für den menschenlesbaren Text der Engine und für die Website und das Studio: nl, pl, pt-BR, pt-PT, fi, sv, da, nb, cs, uk, ru, de, fr, es, et, ja, zh-Hans (--lang, KSHANA_LANG, die Locale-Variablen; lang bei den Aufrufen der Bibliothek, von Python, WebAssembly und MCP). Meldungen und Fehler der Befehlszeile, Laufzusammenfassungen, Diagrammtext, report.html, Beschreibungen der Arten und die Hinweise sind übersetzt; maschinenlesbare Dokumente (JSON, CSV, Fehlercodes, die Verifikationsmatrix) bleiben Englisch, und ein Lauf in einer anderen Sprache führt das Szenario einmal auf Englisch für die maschinenlesbaren Dateien und einmal in der gewählten Sprache für die Person aus (docs/i18n.md). Die Übersetzungen sind maschinelle Übersetzungen, nicht von Muttersprachlern geprüft; Englisch ist die Referenz; die REVIEW.md jeder Sprache listet auf, was ein Prüfer zuerst kontrollieren sollte, und die Seiten der Website tragen einen entsprechenden Hinweis. Urteilswörter, Evidenzstufen und der Geltungsbereich des Hinweises („nicht typzugelassen“, „keine Zertifizierung“, „der Betreiber bleibt verantwortlich“) bleiben in jeder Sprache erhalten.
• kshana interference-map locate: eine geschätzte Senderregion aus ADS-B- oder AIS-Meldungen. Eine Posterior darüber, wo sich eine Quelle gestörter Positionsmeldungen befinden kann (Funksicht bei einem 4/3-Erdradius, Höhe der Senderantenne und Leistung marginalisiert, betroffene Flugzeuge ziehen und unbetroffene Flugzeuge mit Funksicht drücken dagegen), geschrieben als Regionen zu 50, 90 und 95 %, ein Schwerpunkt mit seiner Unsicherheitsellipse (nie ein bloßer Punkt), Sitzungen in der Zeit (Beginn, Ende, Dauer, betroffene Fläche, unterschiedliche Flugzeuge über dem Veröffentlichungsminimum), ein Tagesgangprofil und Stunden pro Tag, mit optionaler Fusion einer TDOA-Lösung aus geolocation. Ausgaben: GeoJSON, JSON-Zusammenfassung, Sitzungs-CSV und eine SVG-Grafik, jeweils mit Lizenz, Quellenangabe, Methodenkennung, Annahmen, Grenzen und ihrer Nachweiskennzeichnung. Bibliothek interference_map::api::emitter_regions_from_*, Python und WebAssembly interference_emitter_regions. MODELLED (Registerzeile VM-bc70cb57; die Matrix hat nun 401 Zeilen, 176 VALIDATED, 221 MODELLED, 4 PARTNER); nur an synthetischen Daten kalibriert, wobei der Vergleich mit den Senderstandorten des Jammertests 2025 vorab festgelegt und einmal ausgeführt wurde: ADS-B und AIS beide NOT ASSESSABLE (zu wenige geplante Sitzungen in den offenen Daten), sodass die Zeile MODELLED bleibt (docs/emitter-region/RESULTS.md). Neutrale Formulierung, nur aggregiert; das Veröffentlichen von Senderregionen im öffentlichen Observatorium bleibt ausgeschaltet. Ein synthetisches Beispiel liegt in examples/emitter-region/ (docs/INTERFERENCE-MAP.md).
• Gemessene Uhrenlogs. src/clock_log.rs liest ein gemessenes Uhrenlog in eine Phasenreihe ein: acht Formate (RINEX clock, TimeLab, TICC, linuxptp ptp4l, phc2sys und ts2phc, chrony-Tracking und -Statistik), jedes eine dokumentierte Teilmenge; alles außerhalb davon wird mit einem Fehler abgelehnt, der nennt, was gefunden wurde. Es wird von telecom-timing ([series.clock_log]) und der Uhrenart ([clock_log], die einen Block measured mit dem SHA-256 des Logs und den überlappenden ADEV, TDEV und MTIE ergänzt) mit dem mitgelieferten Szenario clock-measured-log verwendet (docs/CLOCK-LOG-FORMATS.md). Verglichen mit allantools an realen öffentlichen Daten gegen vorab festgelegte Zielwerte: Der erste Lauf verfehlte B1 (5 von 11 Fällen, alle TICC-Zeitstempel als f64 gehalten), B2, B3 (7 von 24 Fällen) und B4 (die Versionskennung im Kopf wurde nicht geprüft); nach den Korrekturen sind B1, B3 und B4 erreicht, und B2 ist erreicht bis auf ein MTIE-Paar, das festgeschrieben ist und kein Fehler der Engine ist (allantools 2024,6 entfernt die mittlere Frequenz, bevor es integriert; gegenüber seinem MTIE im Phasenmodus stimmt die Engine bis auf 1e-10 überein). Die Zeile bleibt MODELLED (tests/fixtures/clock_log_real/RESULTS.md).
• Ein holdover, der von einer angepassten gemessenen Reihe angetrieben wird: das [clock_fit] der Uhrenart passt das Rauschen einer gemessenen Reihe an und treibt daraus den holdover an (src/clock_fit.rs, mitgeliefertes Szenario clock-fitted-log). Vorab festgelegter Vergleich: F1(b), F3 und F4 erreicht; F1(a) (die Wiedergewinnung des registrierten Random-Walk-FM) NOT MET bei den C3-Aufzeichnungen (konstruktionsbedingt nicht identifizierbar) und bei zwei von drei C4-Aufzeichnungen (Random-Walk-FM von Flicker-FM und Drift aufgenommen); F2 (Rauschidentifikation gegen allantools) erreicht bei elf von zwölf Aufzeichnungen und bei D3 und NOT MET bei D2 wie registriert (bei gleichem Vergleich erreicht). Alle Verfehlungen sind festgeschrieben (tests/clock_fit_known_noise.rs); der Block fitted und der damit angetriebene holdover bleiben MODELLED (tests/fixtures/clock_fit/RESULTS.md).
• Die Benchmark-Neukampagne 0,40, mit Freigabe des Eigentümers vor jedem Lauf vorab festgelegt: A3 (EXPLORATORY, die ordnerweise geclusterte Bootstrap-AUC von agc_k_sigma, 2,5 %-Quantil 0,8502 gegenüber 0,80), D3 (EXPLORATORY, drei von fünf Detektoren überschreiten bei Skalierung 0,25 eine Optimismuslücke von 0,05), R3 (AUC 1,0) und R4 (P_fa 0,0, P_d 1,0): alle MET, alle MODELLED. A2, D1 und R1 sind unberührt und bleiben NOT MET; nichts hier schließt sie (xval/bench/RESULTS-0.40.md, Bench).
• kshana partner check <submission.toml>: prüft Format und Metadaten einer Einreichung eines Datenpartners (kshana.partner-submission/1: Gerät, Datendatei und SHA-256, wie sie aufgenommen wurde, die MODELLED-Zeilen, gegen die sie angeboten wird, Lizenz, Erklärungen) und liest die Daten mit den eigenen Uhrenlog- oder IMU-Readern der Engine. Sie bewertet nichts und validiert nichts. Ein synthetisches Beispiel liegt in examples/partner-submission/.
• docs/PARTNER-DATA.md: welche MODELLED-Registerzeilen gemessene Daten befördern könnten, die akzeptierten Formate, wie eine Einreichung geprüft, an einem vorab festgelegten Zielwert bewertet und angerechnet wird und was PARTNER und VALIDATED jeweils bedeuten; ein Entwurf eines Ansprachetexts für den Eigentümer in docs/drafts/PARTNER-OUTREACH.md (es wird nichts versendet).
• Zweite Kampagnen für die nicht erreichten Zielwerte von gnss-ssv und lunar-infrastructure, wie vorab festgelegt ausgeführt (xval/gnss-ssv/PREREGISTRATION-v2.md, xval/lunar-infra/PREREGISTRATION-v2.md; vor jedem Lauf freigegeben). Jede ursprüngliche Verfehlung bleibt NOT MET und festgeschrieben. gnss-ssv: Die Kontrolle reproduziert Lauf 1 Zelle für Zelle; fünf Ablationen mit je einer Lesart bringen 2 der 78 verfehlten Zellen in die Toleranz (EXPLORATORY, kein Zielwert); der neue Zielwert S7b (eine auf Classic-IIR-Panels angepasste Sendeform aus Abfall und Untergrenze) ist bei den IIR-M-Panels mit 3,83 bis 3,95 dB gegenüber 3 dB NOT MET; die Kampagne mit zurückgehaltenen veröffentlichten Empfangsdaten wurde nicht ausgeführt (keine Quelle festgelegt) (xval/gnss-ssv/RESULTS-v2.md). lunar-infrastructure: Die neuen Zielwerte C3a, C3b (eine Nachweisgrenze von etwa 3e-9 m/s2), Q3a, Q3b (eine genaue Normalverteilungsfunktion beseitigt die Differenz von 1.7e-6) und G3'' sind als eigene Zielwerte erreicht, und G3' mit illustrativen Priors ist erreicht und als EXPLORATORY gekennzeichnet (xval/lunar-infra/RESULTS-v2.md). Alles bleibt MODELLED. Neue öffentliche Elemente: kshana::lambda::{erfc_accurate, normal_cdf_accurate, bootstrap_success_rate_accurate}.
• Eine Nachweiskennzeichnung an jeder Zahl und Tabelle, die ein Lauf schreibt. Das Ergebnis-JSON hat einen Schlüssel evidence, die Diagramm-SVG ein Metadatenelement und eine Zeile unter der Grafik, und die CSV-Tabelle # evidence: Kommentarzeilen: die Stufe (VALIDATED, MODELLED oder PARTNER, die schwächste der Zeilen) und die Kennungen der Zeilen der Verifikationsmatrix, auf denen der Lauf beruht. Zeilen und Status werden aus der Matrix gelesen, nicht getippt; die Kennungen sind stabil (VM- und acht Hexadezimalziffern, eine neue Spalte ID in docs/VERIFICATION-MATRIX.md, eine eingefrorene Liste in tests/fixtures/evidence_ids.txt). Auch bei receiver-trust, jammertest score, iq acquire/sweep/track/monitor, dem Bericht zur Routenexposition und, innerhalb der signierten config.json, bei jedem Nachweispaket (config_version 1,1; kshana evidence verify meldet die Stufe; vor 0,40 erstellte Pakete werden unverändert verifiziert). tests/evidence_labels_doc_sync.rs schlägt fehl, wenn eine Grafik keine Kennzeichnung hat, eine Kennzeichnung der Matrix widerspricht oder ein neuer Dateischreiber weder gekennzeichnet noch mit einem Grund aufgelistet ist. Ausgaben, die keine tragen, sind in docs/SURFACES.md aufgelistet. Die drei Demo-Diagramme der README wurden mit der Kennzeichnung neu gerendert (ohne sie ergeben sich wieder die alten Bytes; docs/revisions/STUDIO15-evidence-label-0.40.md). Keine Aussage hat sich geändert.
• Die Szenarioart mission-thread (scenarios/mission-thread-artemis-class.toml, docs/MISSION-THREAD.md): das Fehlerbudget für Navigation und Zeitgebung einer Kette von Phasen vom Start bis zum Wiedereintritt, jede Zahl MODELLED und jede Eingabe genannt. Acht Phasenarten: launch-ascent, leo-rendezvous (Clohessy-Wiltshire-Relativkovarianz über Sensorabschnitte, Andockfenster), tli-and-cruise (Cowell-Fortschreibung mit einer Zustandsübergangsmatrix aus finiten Differenzen, Manöverfehler, gnss-ssv- und Bodenverfolgungsaktualisierungen, der Mond aus einem optionalen DE440-Kernel-Ausschnitt), entry (Sigma des Bahnneigungswinkels, Korridorwahrscheinlichkeit, Spitzenverzögerung an den Korridorrändern, Landeellipse) und die vier Mondarten. Übergaberegeln (carry, inflate, reacquire), Umrechnungen von Bezugssystem und Zeitskala als eigene Budgetzeilen, eine optionale Bodennetz-Überlagerung, die den Verfolgungseinsatz jeder Phase festlegt, die Marge gegenüber genannten Anforderungen und das schwächste Glied. Das Beispiel folgt der Abfolge einer öffentlichen NASA-Foliensammlung zum Einsatzkonzept mit ILLUSTRATIVE Zahlen: ein durchgängiges Beispiel im Stil von Artemis über 11 Phasen, Erd- und Mondsegmente. Die cislunare Fortschreibung wurde mit der öffentlichen Trajektorie von Artemis I über einen Bogen von 72 h gegen einen Zielwert verglichen, der vor dem Lauf in xval/mission-thread/PREREGISTRATION.md festgelegt wurde: NOT MET (45,3 km und 0,25 m/s gegenüber 5 km und 0,05 m/s). Die Diagnose verortet die Verfehlung in fünf kleinen impulsiven Ereignissen in der Referenz; zwischen ihnen gibt das Kraftmodell die Stundenzustände mit einem Median von 0,4 m wieder. Die Zeile bleibt MODELLED (xval/mission-thread/RESULTS.md).
• Das Mondsegment des Missionsstrangs im Stil von Artemis: vier Szenarioarten, jede zugleich eine Phasenart der Schnittstelle mission-thread (src/mission_thread/lunar/), alle MODELLED.
  • lunar-orbit-rendezvous: Relativnavigation bis zum Andocken in einer kreisförmigen Polarbahn in 100 km oder einer elliptischen Polarbahn von 100 km mal 3000 km (scenarios/lunar-orbit-rendezvous.toml, ...-elfo.toml). Eine Gauß-Newton-Batchschätzung über den Bogen fusioniert je Fahrzeug eine absolute Lösung aus einer illustrativen Relaisgruppe der LCNS-Klasse, einen beständigen Fehler im Signalraum (beiden Fahrzeugen gemeinsam und unabhängig) und eine Querverbindungsentfernung, unter dem Mondkraftmodell des Crates. Sie gibt die Relativposition und -geschwindigkeit in den lokalen Achsen des Ziels an, die Verfügbarkeit der Lösung, den mittleren normierten quadrierten Schätzfehler gegenüber seinem Erwartungswert, die Kosten der Vernachlässigung der Gravitationsharmonischen, die Modelle der Relativsensoren in der Endphase neben dem Wert nur aus Signalen und die weitergegebene 6x6-Kovarianz.
  • lunar-descent: das Landestreuungsbudget an einem Standort am Südpol (scenarios/lunar-descent.toml; lunar-descent-lola.toml liest das LOLA-DEM aus einem Checkout): ein inertiales Fehlermodell mit fünf Zuständen je Achse, eine AFS-Lösung (eigenständig oder differenziell, mit dem Residuum der Korrekturverbindung aus lunar-differential-pnt), eine geländerelative Lösung (der Abgleicher terrain-nav auf seinem synthetischen Relief oder die Cramer-Rao-Schranke des Abgleichs mit dem LOLA-DEM) und Mondzeit über die Fahrzeuguhr (lunar-time-offset). Sie gibt die 3-Sigma-Landeellipse an, jede Kombination von Stützungen und eine Monte-Carlo-Kalibrierung der Ellipse.
  • lunar-surface: Verfügbarkeit von Positionierung und Zeitgebung nach Standort und Jahreszeit (scenarios/lunar-surface.toml; lunar-surface-terrain.toml ergänzt den per Strahlverfolgung berechneten LOLA-Horizont): Der Positionierungswert für einen einzelnen Standort ist bitgenau gleich dem von moonlight-service-volume; die Sichtbarkeit von Erde und Sonne aus den analytischen Ephemeriden ist das, was sich mit der Jahreszeit verändert.
  • lunar-ascent: der Aufstieg in die Rendezvous-Umlaufbahn und die in die Umlaufbahn zurückgetragene Positions-Geschwindigkeits-Kovarianz (scenarios/lunar-ascent.toml), mit der daneben angegebenen Streuung beim Triebwerksabschalten.
  • docs/MISSION-THREAD-LUNAR.md; die Vorregistrierung, ihre Änderungen und jedes Ergebnis, Verfehlungen eingeschlossen, in xval/mission-thread-lunar/.

Nachweise#

• Vor jedem Lauf in xval/mission-thread-lunar/PREREGISTRATION.md vorab festgelegt, mit sechs datierten Änderungen (jede vor dem Abruf der Daten vorgenommen, außer Änderung 6, die nach dem Abruf und vor jedem A2-Ergebnis einen Rechenfehler in einer Zustandszahl korrigiert; jede Änderung ist in der Datei offengelegt). Kein Zielwert wurde gelockert.
• A1 (der Propagator gegen die rekonstruierte LRO-Trajektorie aus JPL Horizons, 24 h): MET, eine größte 3D-Differenz von 33 m gegenüber einem Zielwert von 500 m und eine radiale RMS-Differenz von 2,4 m gegenüber 60 m.
• A2 (derselbe Propagator gegen den CAPSTONE-NRHO über einen Umlauf von 6.5 Tagen): NOT MET, eine Differenz der Endposition von 136,8 km gegenüber einem Zielwert von 25 km und eine Differenz des oskulierenden Perilunradius von 28,4 km gegenüber 10 km. Die Zeile bleibt MODELLED, und die Verfehlung ist durch tests/mission_thread_lunar_oracles.rs festgeschrieben.
• B1 (die Konsistenz der Rendezvous-Schätzung mit ihrem eigenen Modell) ist beim vierten Schätzerentwurf MET, mittlerer NEES 5,85 bis 5,93 gegenüber einem Band von [5,2, 6,8]; die drei früheren Entwürfe, ein erweiterter Kalman-Filter in drei Varianten, haben es verfehlt. Eine fünfte Änderung, vorgenommen, nachdem sich zeigte, dass das ausgelieferte Szenario von 2 h 4 von 50 Versuchen in ein lokales Minimum führte (mittlerer NEES 1e9), lässt die Gauß-Newton-Anpassung über einen wachsenden Bogen mit Schrittweitenhalbierung laufen; B1 bleibt davon unverändert, und die ausgelieferten Szenarien ergeben 6,51 und 6,33. Die Geschichte steht in xval/mission-thread-lunar/RESULTS.md.
• Nichts hiervon ist VALIDATED: Die Zeilen mit unabhängiger Referenz prüfen den gemeinsam genutzten Propagator, nicht einen Navigationsfilter, ein Signal oder ein Budget.

[0.39.0] - 2026-10-22#

Keine neuen Funktionen: eine Korrektur an der Befehlszeile, Abhängigkeitsaktualisierungen im Werkzeug für die Kreuzvalidierung und Dokumentation. Die Ergebnisse der Engine sind gegenüber 0.38.0 unverändert.

Behoben#

• Die Befehlszeile beendet sich still mit dem Status 141, wenn ihre Standardausgabe schließt (kshana kinds | head), statt mit "failed printing to stdout: Broken pipe" abzustürzen. 141 ist 128 plus SIGPIPE, der Status, den eine Shell für yes | head meldet. Behandelt wird nur eine geschlossene Pipe: Eine volle Festplatte oder jeder andere Schreibfehler meldet sich weiterhin selbst, und ein Live-Feed, der in einen geschlossenen Socket schreibt, erhält weiterhin seinen Schreibfehler. tests/cli_closed_pipe.rs schließt den Leser, bevor das Programm startet, sodass der erste Schreibvorgang in jedem Lauf fehlschlägt.

Sicherheit#

Eine Abhängigkeitsaktualisierung in der ausgelieferten Bibliothek (der erste Eintrag), die übrigen in den Werkzeugen zur Kreuzvalidierung (xval/).

• p256, p384 und p521 0,13 auf 0,14 (mit elliptic-curve 0.14.3, ecdsa 0.17.0 und crypto-bigint 0.5.5 auf 0.7.10; ebenso die direkte Abhängigkeit crypto-bigint, jetzt 0,7) beheben RUSTSEC-2026-0387, eine Zeitvariabilität in crypto-bigint 0.5.5. Kshana verwendet diese Crates nur zur Prüfung öffentlicher Signaturen (der Galileo-OSNMA-Wurzelschlüssel und RFC-3161-Zeitstempeltoken) und signiert nur in Tests mit Wegwerfschlüsseln, daher war die praktische Gefährdung null; das Upgrade beseitigt die Warnung ohne Ignore-Eintrag. Die Lock-Dateien der Bibliothek und des MCP ändern sich beide; kein Verifikationsergebnis ändert sich (die Vektortests für OSNMA und Zeitstempel bestehen unverändert).
• Die minimal unterstützte Rust-Version ist jetzt 1,88 (erforderlich durch die Behebung von RUSTSEC-2026-0387).
• memmap2 0.9.10 auf 0.9.11 (RUSTSEC-2026-0186) in den Locks der ANISE-Gegenprüfung (xval/anise-lunar-od, xval/anise-mars-od); die Locks synchronisieren außerdem die Pfadabhängigkeit kshana im Repository neu.
• pillow 12.3.0 auf 13.0.0 und certifi 2026.7.22 auf 2026.10.19 in den Versionsfestlegungen der Umgebung für die unabhängigen Referenzen (xval/oracles/requirements.lock, requirements.frozen.txt): die korrigierten Versionen für acht pillow-Sicherheitshinweise und einen certifi-Sicherheitshinweis.

Dokumentation#

• docs/BENCH.md, die README und diese Datei führen jeden Zielwert von kshana-bench auf, der NOT MET ist, wie in xval/bench/RESULTS-v2.md festgehalten: A2 (agc_k_sigma AUC 0,766 gegenüber mindestens 0,80 auf dem Test-Split), D1 (größte Lücke 0,0301) und Aufgabe (b) R1 (übernommen, nicht erneut ausgeführt). Kein Zielwert wird gelockert.
• Vervollständigung der README: ein Inhaltsverzeichnis; die Szenarioarten, nach Familien abgelegt, jeweils mit einer Seite unter docs/kinds/by-kind/ (die Beschreibung und die Felder der Engine, die Eingaben und Ergebnisse eines Beispiellaufs, die Registerzeilen und unabhängigen Referenzen, die Einschränkungen, die der Bericht des Laufs nennt, und das Diagramm, das die Engine schreibt), ein Übersichtsblatt je Familie, alle indiziert durch docs/KINDS.md; jeder Befehl in docs/COMMANDS.md; jede Oberfläche, jeder Plugin-Befehl, jede Skill und jede Studio-Seite in docs/ALL-SURFACES.md; jeder Fähigkeitsbereich in docs/CAPABILITY-DOMAINS.md; eingebettete Mermaid-Diagramme (Systemüberblick, Oberflächen, innere Schleife, Empfängervertrauen, Labor-Rundreise, Studio, Test- und Release-Ablauf, Modulkarte, Verteilung). Geschrieben von tools/gen_kinds_index.py, tools/gen_readme_blocks.py und tools/gen_figures_038.py; geprüft von tools/readme_audit.py; abgesichert durch tests/readme_completeness_doc_sync.rs, das außerdem Beschreibung und Felder jedes Eintrags an die Engine bindet.
• tools/render-diagram-chromium.sh: rendert ein Mermaid-Diagramm unter Linux als SVG und PNG und aktualisiert den Render-Nachweis.
• README: Die Abbildungen zu Weltraumnutzern und zum Mond verwendeten Pfade relativ zu docs/ und wurden daher in der README nicht geladen; ein Link zeigte auf ../../docs/JAMMERTEST.md.
• Zwei veraltete, von Hand kopierte Diagrammdateien entfernt (docs/assets/clock-ensemble-band.svg, sweep-clock-stability.svg), die keine Seite verwendete und die nicht mehr zur Engine passten; docs/KINDS.md enthält die aktuellen Diagramme.

[0.38.0] - 2026-10-19#

Hinzugefügt#

• GNSS jenseits der Konstellation (gnss-ssv). Eine neue Szenarioart für Raumfahrzeuge oberhalb, rund um und jenseits der GNSS-Umlaufbahnen (docs/SSV.md): Verfügbarkeit von einem und von vier Signalen, Ausfalldauern, C/N0, DOP sowie Hauptkeulen- gegenüber Nebenkeulen-Verbindungen für GPS, GLONASS, Galileo, BDS, QZSS und NavIC auf einer Schale oder entlang von LEO-, MEO-, GEO-, HEO- und Mondtransfer-Trajektorien; Sendemuster aus dem Heft, parametrisch oder vom Benutzer geliefert; ein Modell für Ionosphäre, Plasmasphäre und Atmosphäre mit Randstrahl; ein Empfängerentwurf für schwache Signale; ein bordeigener GNSS-erweiterter Kalman-Filter für HEO und Mondtransfer; und relative Navigation im Verbund. Verglichen mit dem Heft zum ICG Space Service Volume unter einer Vorregistrierung, die vor dem Lauf committet wurde: Die Konstanten der minimal abgestrahlten Leistung und der Zielwert für den Mond stimmen überein, die übrigen Zielwerte sind unter der vorab registrierten Lesart nicht erreicht (fast alle durch den inkonsistenten GLONASS-Strahlwinkel des Hefts), und der parametrische Nebenkeulen-Ersatz reproduziert die gemessenen Antennendiagramme der GPS-Panels nicht. Alles bleibt MODELLED (xval/gnss-ssv/RESULTS.md).
• Mondbahn und Mondoberfläche als Navigations- und Geodäsie-Infrastruktur (lunar-infrastructure). Eine neue Szenarioart mit fünf Studien, ausgewählt über study (docs/LUNAR-INFRASTRUCTURE.md): Konsistenz einer bordeigenen Bahnbestimmung per Erd-GNSS in einer nahezu geradlinigen Halo-Bahn gegenüber einer unabhängigen Bodenbestimmung aus Entfernung und Entfernungsrate; gemeinsame doppeldifferenzierte Trägerphase von Oberflächenstation und Orbiter mit ganzzahliger LAMBDA-Festlegung; Fisher-Information des siebenparametrigen Mond-Datums mit und ohne Entfernungsmessungen zwischen Orbiter und Oberfläche; Versätze zwischen den Techniken GNSS, VLBI und Laserentfernungsmessung gegenüber dem lokalen Anschluss; und Sensitivität gegenüber h2, k2, l2 und der physikalischen Libration. MODELLED, mit ILLUSTRATIVE-Eingaben: Die Numerik wird an unabhängigen numpy- und scipy-Programmen geprüft, und nichts wird mit einer Messung einer Mondgröße verglichen. Die Zielwerte wurden in xval/lunar-infra/PREREGISTRATION.md und zwei offengelegten Änderungen festgelegt. Drei sind NOT MET, und jeder ist durch einen Test festgeschrieben, der die Verfehlung behauptet: C3 (ein eingespeister Kraftfehler wird nicht mit der vorab registrierten Rate erkannt), Q3 (die Bootstrap-Erfolgsrate weicht von der numpy-Referenz um 1.7e-6 ab, bei einem Zielwert von 1e-9, wegen der Normalverteilungs-Näherung von LAMBDA), und die Spurhälfte von G3 (das Hinzufügen einer Entfernungsmessungsfamilie senkt die Spur der Pseudoinversen nicht immer). Die übrigen sind erreicht (xval/lunar-infra/RESULTS.md).
• Ein sechstes Paper in der Forschungstabelle. „Cislunar navigation is an observability problem: arc-length thresholds, Gramian conditioning, and the Doppler lever“ (arXiv:2610,23871, eess.SP) zeigt, dass die Verdünnung der Präzision für reine Entfernungsverfolgung im cislunaren Raum nicht definiert ist, und verwendet stattdessen die Beobachtbarkeits-Gramian-Matrix auf vier ebenen weiten retrograden Bahnen: Reine Entfernungsmessung hat Rang 2 von 4 in einem Augenblick und braucht einen Bogen von etwa 2,09 h, Entfernungsrate (Doppler) ergibt sofort Rang 4, und die gemeinsame Schätzung einer Station mit Satellitenzuständen und Uhren bleibt ohne eine externe interferometrische Beobachtungsgröße um eins rangdefizient. Ihre Zahlen werden von der Szenarioart cislunar-observability (kshana scenarios/cislunar-observability.toml) neu erzeugt; cislunar-arc-recovery prüft die Schwelle mit einem unabhängigen Schätzer. Die Forschungskarte der README, die READMEs von Crates, npm und PyPI sowie der Generator führen es.
• Der neutrale Schiedsrichter, messbar gemacht. kshana jammertest import liest den veröffentlichten NPRA-Jammertest-Katalog und -Sendeplan als geplante Wahrheit (Katalog-IDs bleiben erhalten), und kshana jammertest score bewertet ein Empfängerprotokoll dagegen je Test (Erkennungslatenz, verpasste Alarme, Fehlalarme, Erholungszeit), wahlweise als signiertes Nachweispaket (docs/JAMMERTEST.md). Die Zielwerte der Bewertung wurden vor jedem bewerteten Lauf vorab registriert (xval/jammertest-score/). Beim Datensatz JammerTest 2024 (abgerufen, nie eingebunden) scheiterte die vorab registrierte Mindestdatenregel sowohl im ersten Lauf als auch in der Überarbeitung der Datenbehandlung, sodass kein Zielwert bewertbar ist und nichts behauptet wird; beide Läufe sind festgehalten und festgeschrieben. MODELLED: Der Plan besteht aus den protokollierten Fenstern des Datensatzes, nicht aus aufgezeichneten Sendezeiten. Der NMEA-Satz von SimulaMet aus 2025 wird nicht angebunden (auf seiner Seite ist keine Lizenz angegeben).
• Die eigenen Flags des Empfängers neben denen von Kshana. UBX-NAV-STATUS spoofDetState und UBX-SEC-SIG werden in jeder Epoche in self_report gelesen, und der Vergleich receiver_self_report im Ergebnis stellt sie den Monitoren von Kshana gegenüber (beide, nur Empfänger, nur Kshana, keiner); er löst keinen Alarm aus und ändert keine Bewertung. Ein Septentrio-SBF-Leser (PVTGeodetic, MeasEpoch, RFStatus, nur lesend, auf dem MIT-lizenzierten Crate sbf-tools) und receiver-trust live --serial (ein serieller oder USB-NMEA-Feed, nur lesend; er schreibt nie in einen Empfänger) kommen hinzu.
• Zeitgebung und Hardwaresicherheit (docs/TIMING-HIL.md, docs/HARDWARE-SAFETY.md). Die Szenarioart holdover-test bewertet einen Holdover-Test eines Zeitgebungssystems (GNSS vom Betreiber entfernt, Holdover, Wiederherstellung) aus einer gemessenen Zeitfehleraufzeichnung, gemessen an den ITU-T-Masken aus öffentlichen Tabellen. clock_log liest Protokolle von linuxptp (ptp4l, phc2sys, ts2phc) und chrony (tracking, statistics). iq scene --format sdrx schreibt ION-GNSS-SDR-Metadaten, und iq monitor --follow überwacht eine SigMF-Aufzeichnung, während sie wächst (nur Empfang). compliance-report erhält das Foundational PNT Profile von NIST IR 8323r1 (15 paraphrasierte Zeilen, liefert Belege für). Ein Nachweispaket kann die lab-attestation des Betreibers in seinem signierten Manifest festhalten, nie verifiziert; die Hardwarestufen 0 bis 4 und die rechtlichen Hinweise stehen in HARDWARE-SAFETY.md (rechtliche Prüfung steht aus). Es gibt keinerlei Sendepfad.
• kshana-bench v1 (kshana bench, bench/SPEC.md, docs/BENCH.md): feste Aufgaben, Splits und Metriken für die Erkennung von GNSS-Störungen in Empfängerprotokollen (JammerTest 2024) und IQ, die Vorhersage des Holdovers der Zeitgebung (IGS-Uhren) und die Optimismuslücke bei Daten außerhalb der Verteilung; Split-Manifeste mit festgeschriebenen Hashes und Abrufskripten (keine Daten eingebunden), ein versiegelter zurückgehaltener Datensatz per Commit und Aufdeckung, ein Schema für Ergebnisdateien und eine statische Bestenlistenseite. Basislinien unter Zielwerten, die in xval/bench/PREREGISTRATION.md vorab registriert wurden: Zielwerte des Bewerters erreicht, C1 bis C3 erreicht, D2 erreicht; A2 NOT MET (agc_k_sigma AUC 0,766 gegenüber mindestens 0,80 auf dem Test-Split), D1 NOT MET (größte Lücke 0,0301) und Aufgabe (b) R1 NOT MET (übernommen, nicht erneut ausgeführt), jeweils festgeschrieben (xval/bench/RESULTS-v2.md). Jede Bewertung ist MODELLED. Python bench_score, bench_leaderboard; WebAssembly dasselbe; MCP score_benchmark, render_leaderboard.
• Störungs-Observatorium (kshana interference-map daily, sensitivity, docs/observatory/METHOD.md): ein reproduzierbares tägliches GeoJSON, PNG und Vorfallbericht-JSON mit drei Zuständen (degraded, not degraded, not observed), einer Mindestverzögerung von 24 h, Zellen von 0,5 Grad oder gröber, ohne zugeschriebene Ursache und mit zurückgewiesenen OpenSky-Daten; eine Sensitivitätsstudie der vorab registrierten Parameter; ein 30-tägiger Baltik-Rückkatalog von adsb.lol.
• Maschinen- und Sensoreingänge für receiver-trust (docs/MACHINE-INPUTS.md). Neue Werte für [log] format, alle nur lesend, MODELLED, mit selbst geschriebenen Fixtures und ohne eingebundene Daten: rtklib-pos (RTKLIB-Lösungsdateien .pos), novatel (OEM7-ASCII und Binär BESTPOS, RANGE C/No und RXSTATUS; das Jammer-Flag des Empfängers wird zur self_report der Epoche, den Alarmen von Kshana gegenübergestellt durch den Vergleich receiver-self-report), rtcm3 (MSM4- und MSM7-C/N0 für GPS, GLONASS, Galileo, SBAS, QZSS, BeiDou und NavIC; Layouts aus den unter BSD lizenzierten pyrtcm-Tabellen, deren Hinweis in NOTICE steht, nicht aus dem RTCM-Standard) und gnss-sdr (GNSS-SDR-Monitor- und PVT-Monitor-Nachrichten als JSON-Zeilen, weitergereicht von integrations/gnss-sdr/relay.py).
• IMU-Protokolle als zweiter Sensor. [log.imu] (csv oder euroc) integriert die Gierrate des Kreisels zu dem Kurs, den der Monitor heading-course liest; inline auf jeder Oberfläche und durch Nachweispakete weitergetragen. kshana imu-fit (Python imu_fit, WebAssembly imu_fit, MCP fit_imu_log, Plugin /kshana-fit-imu, eine JetBrains-Aktion) passt die Parameter von Beschleunigungsmesser und Kreisel der Szenarien hybrid und fusion aus einem Ruheprotokoll per Allan-Abweichung an und gibt eine Tabelle [accel_classical] mit dem SHA-256 des Protokolls in ihrer Herkunftsangabe aus.
• Integrationen: ein ROS-2-Paket (integrations/ros2/kshana_trust: NavSatFix und ublox_ubx_msgs als Eingang, Vertrauens-Topics als Ausgang; seine ROS-freie Brücke wird gegen die reale Engine getestet, der Knoten selbst lief nicht in einem laufenden ROS-Graphen), eine Brücke zu gnss_lib_py (integrations/gnss_lib_py, Abhängigkeit unter MIT, optional) und ein GNSS-SDR-Relay.
• Home-Assistant-MQTT-Exporter für Vertrauenstelemetrie: kshana trust-telemetry --print-mqtt und --mqtt-tcp <host:port> (Discovery-Nachrichten und ein JSON-Zustandsdokument; nur Veröffentlichen, keine Zugangsdaten oder TLS) sowie format = "mqtt" als Text in Python, WebAssembly und MCP.
• Sieben MODELLED Registerzeilen zu dem Obigen. Nichts davon ist VALIDATED: Es wurde keine Aufzeichnung eines realen Empfängers, einer Basisstation, einer IMU, eines GNSS-SDR-Laufs, eines ROS-Graphen oder eines MQTT-Brokers gelesen.
• Optische Streckenreserve über die Zeit. Die Szenarioart optical-atmosphere nimmt eine optionale Tabelle [timeseries] (duration_h, step_s, seed) entgegen und schreibt dann auch je Standort eine mit Startwert erzeugte Realisierung des angegebenen Standortmodells über die Zeit: Wolkenepisoden, eine Flüssigwassersäule je Episode, eine Gamma-Gamma-Szintillationsprobe je Schritt, und daraus die Streckenreserve, die Wolken- und Szintillations-Fades und das Flag für aktive Strecke, mit realisierter Verfügbarkeit, Wolkenanteil, Anzahl der Ausfälle und längstem Ausfall. MODELLED (eine Ziehung aus dem Modell, nicht das Klima; keine externe unabhängige Referenz). Ohne die Tabelle ist das Ergebnis das Dokument 0,37. Die beiden mitgelieferten optischen Szenarien tragen die Tabelle (336 h, 600 s, Startwert 37). Zielwerte, vorab registriert in xval/optical-atmosphere/PREREGISTRATION-timeseries.md vor dem ersten Lauf.
• Spezifikation der Testbedingungen und die Labor-Rundreise. kshana.test-conditions/1 wird als docs/spec/TEST-CONDITIONS.md mit einem JSON-Schema veröffentlicht und erhält recording.kind = "receiver-log". kshana bench-export schreibt außerdem <base>.conditions.json. kshana evidence round-trip erstellt ein signiertes Paket, das den Szenario-Hash, den Hash der angegebenen Bedingungen, den Hash des Empfängerprotokolls und die Bewertung gegen die angegebenen Ereignisse verknüpft, und weist Bedingungen zurück, die den Bewertungsereignissen widersprechen. Ausgearbeitetes Beispiel, bei dem gps-sdr-sim nur eine Datei schreibt; das Abspielen liegt in der Verantwortung des Betreibers und wird nie automatisiert. Python evidence_round_trip, MCP create_round_trip_pack, Plugin /kshana-evidence-pack.
• Standardpakete (kshana standards-pack, standards/): die Testprofile des DHS-Rahmenwerks Resilient PNT für die Stufen 1 bis 4, die Genauigkeitsstufen und die Integritätsbewertung nach IMO MSC.1/Circ.1575 sowie Überwachen, Bewerten und Abmildern nach ICAO Doc 9849 Anhang F, jeweils eine Reihe von Szenarien, bewertet gegen Zielwerte, die vor dem Lauf festgelegt wurden, mit den Zeilen von compliance-report, für die sie Belege liefern. Verfehlungen sind festgehalten und festgeschrieben: DHS L4-T1 und die vier Genauigkeitstests der IMO. Doc 9849 selbst wurde nicht gelesen (kostenpflichtig); das ICAO-Paket folgt der eigenen Präsentation der ICAO zum RFI Mitigation Plan. compliance-report erhält einen Abschnitt zu Standardpaketen. Alles MODELLED.
• LunaNet Augmented Forward Signal (docs/LUNANET-AFS.md): AFS-I-Gold- und AFS-Q-Weil-Codes für PRN 1 bis 210, die Signale lunanet-afs-i und lunanet-afs-q in kshana iq, der SB1-BCH-Code, CRC-24Q und Interleaver sowie kshana lunanet-afs-check (spec, symbols, generate), festgelegt auf LNIS V5 Applicable Document 1 Volume A (LSIS-AFS V1.0, 29. Januar 2025). Codes VALIDATED gegen die gedruckten Tabellen des Dokuments (die es mit TBC kennzeichnet); eine gedruckte Tertiärspalte (PRN 147) ist wahrscheinlich ein Druckfehler, und die Abweichung ist festgeschrieben. Die LDPC-Kodierung der Subframes 2 bis 4 ist nicht implementiert.
• Kurs-Notebooks (notebooks/course/): Jamming, Spoofing, Holdover, Integrität, OSNMA und Störungskarte, jeweils mit Übungen.
• Studie zur maximalen URA im EU-US-WG-C-ARAIM-Meilenstein 3 (xval/araim-m3/, src/bin/gen_araim_m3_study.rs), ersetzt den zurückgezogenen Plan „Table A-3“; MODELLED unter genannten Abweichungen.
• Entwürfe zur Freigabe durch den Eigentümer unter docs/drafts/: JOSS-Paper, Änderung der TSC-Satzung, Prozess für das Register unabhängiger Referenzen und ein Aufteilungsvorschlag für LICENSES/. Nichts davon ist angenommen.
• Studio-Ansichten für die Funktionen von 0,38 (kshana.dev/studio/). Bridge-Wiedergabe (zwei synthetische Läufe auf einer Uhr: Spur, Vertrauenswert, die Satelliten, die das Protokoll hört, und das Urteil, mit den eigenen Markierungen des Empfängers neben den Alarmen von Kshana); Optical PNT (die beiden Szenarien optical-atmosphere, mit einer optionalen, mit Seed erzeugten Realisierung von [timeseries], MODELLED); Holdover-Test (das Ergebnis von holdover-test, gemessen an den ITU-T-Masken, gezeichnet aus der record.series des Ergebnisses selbst); ein Viewer für das Störungs-Observatorium, der die von Ihnen erzeugten Dateien öffnet und keine mitliefert; auf der Seite Tools ein Jammertest-Scorer, eine IMU-Anpassung und MQTT als Telemetrieformat; und unter Trust eine Auswahl des Protokollformats (RTKLIB .pos, NovAtel OEM7, RTCM 3, GNSS-SDR, Septentrio SBF) mit optionaler IMU-Datei. Jede Ansicht liest Dateien im Browser und lädt nichts hoch; jede Zahl behält die Kennzeichnung, die das Register für sie führt, und jede trägt den Hinweis. Die Seite /benchmark der Website zeigt das Fragment kshana bench leaderboard.

Behoben#

• Issue #36: byteexakte Pin-Schichten. Byteexakte Pin-Schichten laufen nur auf einem Host, der als Basislinie erklärt ist (KSHANA_EXACT_PINS=1, gesetzt durch scripts/gate.sh), nicht auf jedem Apple-Silicon-Mac, weil sich Apples Mathematikbibliothek zwischen macOS-Versionen unterscheidet; die portable Schicht läuft überall, und tests/exact_pin_gate_guard.rs verhindert, dass eine byteexakte Schicht erneut allein nach Plattform freigeschaltet wird. Die Vergleiche mit den unabhängigen Referenzen selbst bestehen unter macOS. Kein Literal wurde neu aufgenommen und keine Toleranz geändert. scripts/oracle-triage.sh und docs/LOCAL-ORACLE-TESTS.md beschreiben, wie ein Unterschied zu sichten ist; .github/workflows/oracle-macos.yml ist eine manuelle und wöchentliche Diagnose, keine Schranke.
• CodeQL: ein nicht verankertes Muster im Trust-Open-Helfer des Studios passt jetzt auf den gesamten Header (web/studio/lib/trust-open.mjs).
• CI: Speicherplatz des Runners. Der Job check baut die Profile dev und test ohne Debug-Informationen, sodass das Linken den Speicherplatz nicht mehr füllt.
• Quellcode-Wächter. Jede Quelldatei mit Test-Fixtures, die Pins enthalten, erklärt ihren Pin-Geltungsbereich, und die Tests, die temporäre Dateien schreiben, verwenden bei jedem Aufruf einen eindeutigen Pfad, sodass parallele Läufe nicht kollidieren können.
• docs/SCENARIOS.md wird für das optionale Feld timeseries von optical-atmosphere neu erzeugt.
• JetBrains-Plugin: keine Verwendung veralteter oder zur Entfernung vorgesehener Plattform-API. Der IntelliJ Plugin Verifier (verifyPlugin) gegen IntelliJ IDEA Build 263 (2026,3: 263.6800.24 und 263.7031.23) fand einen veralteten Aufruf, FileEditorManager.openFile, in Insert Example; die neue Datei wird jetzt mit OpenFileDescriptor geöffnet. Das Plugin ist mit 2024,3 (dem unveränderten since-build) und beiden Builds 263 kompatibel und ohne Befunde. CI führt jetzt verifyPlugin aus und schlägt bei Kompatibilitätsproblemen und bei jeder Verwendung von zur Entfernung vorgesehener API fehl.

[0.37.0] - 2026-10-17#

Hinzugefügt#

• Optisches PNT durch die Atmosphäre (Szenarioart optical-atmosphere, docs/OPTICAL-ATMOSPHERE.md, Entwurfsnotiz docs/design/optical-atmosphere-0.37.md). Für eine optische Verbindung und eine Menge von Bodenstationen liefert es die von Wellenlänge und Elevation abhängige Dämpfung bei klarer Luft, den Zustand der Turbulenz nach Hufnagel-Valley (Rytov-Varianz, Szintillationsindex, Gamma-Gamma-Schwunde, Aperturmittelung), die Verfügbarkeit gegenüber der Link-Reserve aus einem genannten Wolkenklima, die für Ziel-Verfügbarkeiten nötige Reserve und die Obergrenze, die keine Reserve anhebt, die Verteilung der Ausfalldauer, den Zeit- und Entfernungsfehler pro Ausfall über das Holdover-Modell der Uhr, entfernungskorrelierte Standortdiversität sowie Was-wäre-wenn-Gewinne für eine Wellenlängenänderung, eine größere Apertur, die Verringerung der Szintillation durch adaptive Optik und zusätzliche Reserve. optical_linkbudget erhält ein atmosphärenbewusstes Budget; ohne eines ist seine Ausgabe bitgleich mit 0,36 (Zielwert A5). Zwei mitgelieferte Szenarien tragen ILLUSTRATIVE Wolkenklimata. MODELLED: drei Registerzeilen. Die Numerik erfüllt die Zielwerte A1 bis A6, vorab registriert in xval/optical-atmosphere/PREREGISTRATION.md, gegenüber einem unabhängigen mpmath-Programm; das prüft die Umsetzung der genannten Formeln, nicht die Atmosphäre, und es wurde keine gemessene Verfügbarkeitsaufzeichnung verglichen, daher ist keine Zeile VALIDATED. Der Zielwert A4 wurde zunächst um 3e-9 verfehlt, weil die verwendete Normalverteilungs-CDF eine Näherung mit 1.5e-7 war; die CDF wurde ersetzt und der Zielwert blieb wie registriert. Die nativen und die WebAssembly-Builds liefern für beide mitgelieferten Szenarien byteidentische Dokumente (A7, ausgeführt auf dem Integrations-Commit von 0.37.0).

[0.36.0] - 2026-10-16#

Hinzugefügt#

• Detektions-ROC der IQ-Monitore (PRO-32, docs/design/DETECTION-ROC.md). Eine Kampagne mit Monitoren behält das Maximum der Teststatistik jeder Alarmart über genannte Ereignisfenster (positiv) und über Fenster, die außerhalb der Ereignisse gekachelt sind (negativ, roc_window_s). Der Bericht fasst sie pro Alarmart zu einer ROC mit ihrer AUC und dem Arbeitspunkt bei der konfigurierten Schwelle zusammen, als roc.json und als Berichtsabschnitt. Bei synthetischen Kampagnen ist die Prüfung auf Zufallsniveau erfüllt. Der Zielwert der C/N0-AUC (0,95) ist nicht erreicht (0,79), weil die negativen Fenster unmittelbar nach einem Ereignis den Abfall der CUSUM aus der Detektion erben; das ist festgehalten. MODELLED.

• IQ-Monitore in der Lab-Replay-Kampagne (PRO-31, docs/design/MONITORS-IN-CAMPAIGN.md). Eine optionale Tabelle [monitors] in einer Kampagnendatei lässt die IQ-Monitore im einzigen Durchlauf des Runners laufen: Leistung und Spektrum nach jeder Front-End-Kette sowie C/N0, SQM und Lock pro verfolgtem Kanal. Ihre Alarme werden an den genannten Ereignissen bewertet: erkannt oder verpasst, Zeit bis zur Erkennung und Fehlalarme pro Stunde Exposition. Die geschlossene Fehlalarmzahl jedes Tests ist angegeben, darunter eine neue zweiseitige Gauß-Zahl für die SQM-Tests (2Q(k)). Ohne die Tabelle ändert sich nichts. Bei synthetischen Kampagnen sind die Fehlalarm-Zielwerte für Leistung und SQM sowie der Fehlalarm-Zielwert für C/N0 erfüllt; 18 von 18 Dämpfungen werden erkannt, aber die Schranke für die Zeit bis zur Erkennung, konstruktionsbedingt unter einem Detektor-Abtastwert, ist nicht erfüllt und ist festgehalten. MODELLED; Registerzeile „IQ monitors scored in lab-replay campaigns“.

• Lab-Anpassung aus IQ-Kampagnen, Folgeprüfung (tests/iq_labfit_followup.rs, CI-Job labfit-iq-followup). Sie prüft die beiden Hypothesen, die §13,6 von docs/design/LABFIT-FROM-IQ.md offen ließ, gegen Zielwerte, die in 1e532f84 vorab registriert wurden. Sie fügt zwei synthetische Kampagnen hinzu: S mit gestuftem J/S (Seed 2026_1014) und R, eine frische Rampe (Seed 2026_1015). Die Ergebnisse stehen in docs/design/evidence/labfit-followup/RESULTS.md.

  • S1 erfüllt: Bei jeweils gehaltenem J/S-Niveau wird δ_eff innerhalb von +0,185 dB wiedergewonnen. Der Fehler von −1,1 dB bei den Rampenkampagnen ist Schätzer-Verzögerung.
  • S2 nicht erfüllt, festgehalten durch einen Test, der den Fehlschlag prüft: (d) wie geschrieben gilt bei der gestuften Kampagne für das Tracking-Loop-Modell (0,45 dB), aber nicht für das empirische (6,42 dB).
  • R1 erfüllt: Bei der frischen Rampenkampagne liegt (d) mit den angepassten Abfall-Verweilzeiten, zu denen die Rampenrate jedes Ereignisses addiert wird, für beide Modelle innerhalb von 1 dB.
  • Die Fehlschläge bei (a′) und (d) wiederholen sich bei R.
  • Eine Kampagne kann ihr J/S jetzt im Test-Harness als Profil step angeben.
  • Kein Urteil in §13 ändert sich, und die Registerzeile bleibt MODELLED.

• Begrenztes FLL-Pull-in, optional (DS-LOOP-05): ein neuer Schlüssel im Schleifenentwurf [design.carrier] fll_pull_in_max_s (s), in Rust LoopConfig::fll_pull_in_max_s. Unter fll_assist = "pull-in" erzwingt er nach dieser Dauer die Übergabe von FLL an PLL, unabhängig vom PLI. Standardmäßig nicht gesetzt, und dann nicht im Entwurfs-Hash; der Standardentwurf und sein Hash bleiben unverändert.

  • Geprüft gegen Zielwerte, die bei 58789af0 vorab registriert wurden, an eingespeister Wahrheit. Die Kontrolle ist erfüllt: Der Standard übergibt bei 33 dB-Hz in 9 von 10 Seeds nie.
  • Nicht erfüllt: Mit einer Begrenzung von 1,0 s halten 16 von 20 Läufen bei 33 dB-Hz den Lock und 8 von 20 bei 31 dB-Hz; die übrigen wechseln zwischen erzwungenen Übergaben und der Rückkehr der FLL. Der Phasenjitter beträgt bei 33 dB-Hz das 1,8-Fache der PLL allein.
  • Die Pull-in-Untergrenze von ~35 dB-Hz bleibt die dokumentierte Grenze des Standards.
  • MODELLED; Registerzeile „Capped FLL pull-in below the default design's FLL-to-PLL hand-over floor (opt-in)“.

• Akquisitions-Hysterese und der Front-End-Quantisierer in der Art jamming (CAP-06c): zwei optionale Abschnitte für ein Szenario jamming.

  • [acquisition]: acquisition_threshold_dbhz (dB-Hz, auf oder über der Tracking-Schwelle) und reacquisition_delay_s (s, Standard 0). Ein Satellit ist akquiriert, wenn er auf oder über der Akquisitionsschwelle liegt, nachdem er für die Dauer der Verzögerung nicht akquiriert war. Er wird gehalten, solange er auf oder über der Tracking-Schwelle liegt. Ausgaben: epochs[].sats[].acquired (wahr/falsch), epochs[].acquired (Anzahl) und fom.availability_acquired (1).
  • [front_end]: adc_bits (1 bis 16) und bandwidth_mhz (MHz, Standard das Doppelte der Chiprate). Gibt einen Block front_end aus: agc_gain_reduction_db (dB, 10·log10(1 + J/N)), quantiser_loss_db (dB, von der effektiven C/N0 jeder Verbindung abgezogen) und loss_model. Der Verlust ist der für gaußsche Eingänge und ist als nicht gültig für CW-, Schmalband- und gewobbelte Jammer gekennzeichnet.
  • Ohne die Abschnitte ist jede Ausgabe byteidentisch.
  • Geprüft gegen Zielwerte, die bei 70c72fcc vorab registriert wurden. Der Quantisierungsverlust liegt innerhalb von 0,0007 dB eines unabhängigen Monte-Carlo-Laufs, und der AGC-Wert innerhalb von 0,012 dB der AGC-Schleife der IQ-Schicht.
  • Die registrierten Hysterese-Läufe waren nicht aussagekräftig (jede Verbindung verloren), daher ist dieser Zielwert NOT MET. Ein ergänzender Lauf-Satz, registriert bei 37793290, erfüllt ihn: Jede Markierung entspricht einer unabhängigen Neuberechnung, und 732 von 1824 Verbindungen zeigen die Hysterese.
  • Befund: Mit einem CW-Jammer verliert ein 1-Bit-ADC etwa 5 dB mehr als der gaußsche Wert.
  • MODELLED; Registerzeile „Acquisition hysteresis and the front-end quantiser in the jamming kind against independent recomputations“.

• Geländeabschattung des Jammers in der Art jamming (CAP-06b): ein optionaler Abschnitt [terrain] in einem Szenario jamming mit Jammer. Felder:

  • dem_hgt: eine SRTM-Kachel .hgt, relativ zum Arbeitsverzeichnis;
  • samples_per_side, ll_lat_deg und ll_lon_deg (Grad): Größe und Ecke der Kachel;
  • geoid_undulation_m (m, Standard 0), k_factor (Standard 4/3) und profile_step_m (m, Standard 30).

  Die Engine tastet das Geländeprofil entlang des Großkreises zwischen Jammer und Empfänger ab und findet die dominante Schneidenkante. Die empfangene Leistung des Jammers und damit jedes J/S wird um den Einzelschneiden-Beugungsverlust nach ITU-R P.526-15 §4,1 gesenkt.

  • Das Ergebnis erhält einen Block jammer_terrain: nu_max (1), diffraction_loss_db (dB), obstacle_distance_m (m), obstacle_terrain_m (m), path_length_m (m) und profile_points (Anzahl).
  • Ohne den Abschnitt ist jede Ausgabe byteidentisch.
  • Geprüft gegen Zielwerte und zehn Platzierungen, die bei 92cd2bfd vorab registriert wurden, an der eingecheckten echten SRTM-Kachel des Death Valley, gegen eine unabhängige Neuberechnung mit numpy. Alle erfüllt: größte Abweichung 1.6e-10 bei ν und beim Verlust (Zielwert 1e-9), der Verlust monoton in der Jammerhöhe, und der Verlust erreicht J/S exakt.
  • MODELLED; Registerzeile „Terrain shadowing of the jammer in the jamming kind against an independent numpy recomputation on a real SRTM tile“.

• CRPA-Antennengewinne in der Art jamming (CAP-06a): ein optionaler Abschnitt [crpa] in einem Szenario jamming. Felder: elements_enu_m (Elementpositionen in lokalem Ost-Nord-Oben, m), weighting ("null-steering" oder "mvdr") und bandwidth_mhz (MVDR-Rauschbandbreite, MHz, Standard das Doppelte der Chiprate).

  • Jeder Kanal bildet einen verzerrungsfreien Strahl zu seinem Satelliten. Das Rauschen der Verbindung wird mit ‖w‖² und der Jammer mit |wᴴa_j|² skaliert, bevor die bestehende Anti-Jam-C/N0-Gleichung angewandt wird.
  • Jede Verbindung erhält einen Block crpa: array_noise_gain_db (dB) und jammer_gain_db (dB).
  • Ohne den Abschnitt ist jede Ausgabe byteidentisch.
  • Ein ungültiger Abschnitt (eine leere Elementliste, eine unbekannte Gewichtung, eine nicht positive Bandbreite) ist ein Fehler, über kshana und api::run_toml ebenso wie über jamming::run_jamming.
  • Geprüft gegen Zielwerte, die bei 08d83b4d vorab registriert wurden. Erfüllt: Additivität (nach einer Korrektur: Der erste Build fügte die neuen Einheiten der Einheitentabelle jedes Jamming-Laufs hinzu); ein Element ist kein Array; Rauschgewinn und effektive C/N0 innerhalb von 1e-9 dB einer unabhängigen Neuberechnung mit numpy; MVDR strebt bei hohem JNR zur Nullstelle.
  • Nicht erfüllt: der MVDR-Jammergewinn bei 194 von 456 Verbindungen mit der portablen Mathematik von 0,36 (202 mit der Host-Mathematik; docs/revisions/STUDIO15-batch4-rebaseline.md) (schlechtester Wert 1.7e-6 dB). Die Residuen von −100 bis −188 dB liegen unter der Auflösung von float64 bei diesem Zielwert, und numpy weicht von sich selbst in derselben Größenordnung ab.
  • MODELLED; Registerzeile „CRPA antenna gains in the jamming kind against an independent numpy recomputation“.

• IQ-Tracking-Engine gegen GNSS-SDR 0.0.19 (PRO-33): kshana iq track und GNSS-SDR verfolgen dieselben unabhängigen numpy-Aufzeichnungen von GPS L1 C/A bei 30 bis 45 dB-Hz.

  • Zielwerte vorab registriert bei 48edd4a5. Die registrierte Kalibrierung scheiterte an einer falschen Übergabe von GNSS-SDR (F3), daher ergänzt Nachtrag 1 (1e4288c4) beiden Empfängern eine reine Pull-in-FLL, eingecheckt vor jeder Testaufzeichnung.
  • Erfüllt: Träger- und Codejitter sowie Doppler stimmen bei jeder C/N0 innerhalb von 5 % überein.
  • Nicht erfüllt: Die NWPR-C/N0 der Engine liegt 2,3–7,1 dB unter dem SNV von GNSS-SDR (F4, eine bekannte Schätzergrenze; M2M4 liegt innerhalb von 0,06 dB der Wahrheit); die Lock-Indikatoren unterscheiden sich per Definition (F5); eine abweichende Bewertung eines Slips bei 30 dB-Hz (F6).
  • MODELLED; Registerzeile „IQ tracking engine against GNSS-SDR 0.0.19 on independent recordings“.

• Zwei Zeilen VALIDATED für Codes der IQ-Schicht (DS-GIQ-06b, PRO-39).

  • BeiDou B1I. Alle 63 primären B1I-Codes stimmen Chip für Chip mit dem unabhängigen Generator von GNSS-SDR v0.0.19 überein (Zielwert vorab registriert bei 911106d1). Nur die Ausgabe dieses Programms ist eingecheckt: die B1I-PRN-Codes, die das öffentliche ICD definiert, als Präfix und Hash.
  • GPS L1C. Alle 126 L1CP/L1CD-Codes und 63 L1CO-Overlays stimmen mit den Prüfspalten überein, die IS-GPS-800J ausweist, und die berechnete Legendre-Folge stimmt mit ihrer Tabelle 6.2-1 überein (Zielwerte vorab registriert bei fe372e26).
  • Zeilen: „BeiDou B1I primary ranging codes against an independent generator“ und „GPS L1C ranging and overlay codes against the IS-GPS-800J printed check columns“.

• GLONASS-, BeiDou- und Galileo-E6-Bänder im Spektrummodell (CAP-12, Signale): neue Bandnamen glonass-l1of und glonass-l2of (jeder FDMA-Kanal als glonass-l1of-k<K>, K = −7 bis 6), beidou-b1i, beidou-b1c, beidou-b2a, beidou-b3i und galileo-e6. Jedes trägt Träger, Modulation und minimale Empfangsleistung aus seinem ICD. Sie sind nur über den Namen optional zuschaltbar: Der Standard-Bandsatz und jede bestehende Ausgabe bleiben unverändert.

  • Geprüft gegen Zielwerte, die bei 5806f28b vorab registriert wurden: Die ICD-Werte, Nullstellen, der B1C-Verbund und der C/N0-Pfad sind erfüllt.
  • Zwei Zielwerte wurden nicht erfüllt. Der Zielwert für die Flächeneinheit war wie geschrieben unerreichbar (F1). Die Wellenformen B1I und B1C der IQ-Schicht stimmen mit dem Modell nur bandgemittelt überein, wegen der ungleichmäßigen Linienspektren ihrer Codes (F2).
  • MODELLED; Registerzeile „Spectrum model: GLONASS, BeiDou and Galileo E6 bands (opt-in)“.

• Option Cell-Averaging-CFAR in der IQ-Akquisition (PRO-37): iq::acq::ca_cfar und ca_cfar_cells entscheiden auf einem Akquisitionsraster, indem jede Zelle mit dem Mittel der Referenzzellen in ihrer Doppler-Zeile verglichen wird. Die Schwelle ergibt sich aus der geschlossenen CA-CFAR-Fehlalarmwahrscheinlichkeit für M nichtkohärente Blöcke (ca_cfar_pfa, ca_cfar_alpha), sodass die Entscheidung nicht von der Normierung der Abtastleistung abhängt. Sie ist optional; der Standarddetektor und jede bestehende Ausgabe bleiben unverändert.

  • Geprüft gegen Zielwerte, die bei 3724aefa vorab registriert wurden: die geschlossene Form gegen Monte Carlo (18 von 18 Fällen) und eine Entwurfsrate von 1 %, gemessen mit 0,97–1,01 % bei gaußschem und 2-Bit-quantisiertem Rauschen.
  • Ein Zielwert wurde nicht erfüllt: Bei einem rauschfreien 2-Bit-Signal überschreiten 1,28 % der Zellen außerhalb des Peaks die Schwelle, an den Korrelationsnebenmaxima des Codes (Befund F1).
  • MODELLED; Registerzeile „Cell-averaging CFAR option in IQ acquisition“.

• Szintillationsmodell gegen Messdaten (PRO-34): Das Cornell-Szintillationsmodell des IQ-Kanals wurde mit gemessener Intensität und Phase von GPS L1 bei 50 Hz aus einer äquatorialen Szintillationsnacht verglichen (Zenodo-Eintrag 16941224, INGV, Malindi, CC BY 4,0), unter bei b6ccb499 vorab registrierten Zielwerten. Erfüllt: die Intensitätsverteilung und die an S4 gebundene Phasenszintillation. Nicht erfüllt: Das Modell schwindet 2,4-mal so oft unter −10 dB und 3,5-mal so lang (Befund F1). Die registrierte Verarbeitung liest die umbrochene Phase des Modells (Befund F2); das Phasenergebnis gilt auch entfaltet. scripts/fetch_scint_malindi.sh lädt die Daten. Die Zeile bleibt MODELLED: „IQ ionospheric scintillation channel (Cornell model) against measured 50 Hz GPS L1 scintillation“.

• Korrigierter LuGRE-Sample-Leser (MR-09): realdata::lugre::parse_iqs_sdrx liest einen LuGRE-IQ-Stapel mit I im hohen Nibble und den Mid-Rise-Pegeln 2v + 1 (SdrLayout::mid_rise), die das Mittel von −½ beseitigen, das die reinen Zweierkomplement-Ganzzahlen bei I und Q tragen. run_acq.py --corrected gibt GNSS-SDR dieselbe Lesart. Der generische ION-Leser und jede bestehende Ausgabe bleiben unverändert: 149 Szenarioergebnisse und eine Studie sind vorher und nachher byteidentisch, und die festgehaltenen LuGRE-Befunde lesen sich wie registriert (xval/lugre-reader/RESULTS.md). Keine Registerzeile ändert sich.

• Optionales BOC(1.1)-Tracking (CAP-07 (a)): LoopConfig::boc skaliert die DLL-Diskriminatoren für den Sinus-BOC(1.1)-Hauptpeak und fügt einen Bump-Jump-Monitor hinzu (sehr frühe und sehr späte Korrelatoren bei ±0,5 Chip, Auf-/Ab-Zähler, N = 8), der den Code-NCO von einem Nebenpeak weg bewegt; Channel::bump_jumps listet die Sprünge auf. Standardmäßig aus, und jede bestehende Ausgabe bleibt unverändert. Geprüft gegen Zielwerte, die bei 6b68f6cc vorab registriert wurden, an einem synthetischen BeiDou-B1C-Signal: Ein Start auf einem Nebenpeak, der ohne die Option 0,55 Chip daneben bleibt, wird mit ihr durch einen Sprung bei 0,08 s auf den Hauptpeak gezogen, und es wurde kein falscher Sprung vom Hauptpeak aus beobachtet. Ein Zielwert wurde nicht erfüllt: Das Raster des Unit-Tests für die Skalierung reicht über den linearen Bereich der Diskriminatoren hinaus (Befund F1 in docs/design/evidence/boc-bump-jump/RESULTS.md). MODELLED; Registerzeile „BOC(1.1) tracking: DLL scaling and bump-jump ambiguity resolution (opt-in)“.

• Lab-Anpassung aus IQ-Kampagnen (B7.1, docs/design/LABFIT-FROM-IQ.md). Das [input] campaign = "<out-dir>" eines Labfit-Szenarios passt einen Ausgabeordner von kshana iq campaign an, in der CLI (kshana iq labfit), in Python (kshana.iq_labfit) und im MCP-Labfit-Werkzeug (nur Ordner innerhalb seines Arbeitsverzeichnisses). Es passt eine Einheit pro Signal, Schleifenentwurf, Front-End-Kette und Jammer-Typ an:

  • das C/N0-Modell gegen genanntes J/S, mit Zensierung;
  • die Tracking-Schwelle, direkt und in geschlossener Form;
  • die Tracking-Loop- und empirischen Lock-Modelle, über das C/N0-Modell gekoppelt, mit ihren Verweilzeiten;
  • ein Cluster-Bootstrap mit Seed über Aufzeichnungen, 90-%-Prädiktionsintervalle und Hold-outs mit je einer ausgelassenen Aufzeichnung;
  • eine vorab registrierte, gehashte Tabelle [validation], mit PASS/FAIL pro Zielwert.

  Der Bericht ist kshana.labfit-iq/1 als JSON, CSV und Markdown, mit einem Einheitenblock. Q_eff ist aus C/N0-Daten nicht identifizierbar, ohne eine unabhängige Leistungsmessung. Es wird angegeben, nie angepasst, und der angepasste Parameter ist delta_eff = delta - 10 log10 Q (Entwurfsänderung 2026-10-12). Ein unbekannter Jammer-Typ nimmt das schädlichste angegebene Q (cw, 1). Bei synthetischen Kampagnen aus Kshanas eigenen Szenen besteht der Zielwert für die Hold-out-Abdeckung (c). Die Zielwerte (a') und (b') für delta_eff (0 von 50 Kampagnen abgedeckt) und der Zielwert (d) für die Schwelle in geschlossener Form sind nicht erfüllt: Sie sind mit ihren Werten festgehalten. MODELLED; Registerzeile „Calibration of the open receiver's C/N0 and lock models to IQ campaign results, with stated prediction error“. Der Labfit-Pfad für Empfängerprotokolle und seine Ausgaben bleiben unverändert.

• solar-system auf einem JPL-Kernel (CAP-31): planetary_kernel_path nimmt jeden Körper, den die SPK enthält (mit de440s: Merkur, Venus, die Erde, den Mond), aus dem Kernel, Label KERNEL, und fügt einen Block kernel nur hinzu, wenn gesetzt. Neue Zeile, VALIDATED gegen SPICE (vorab registriert f8e946ea; schlechtester Wert 3.3e-5 m, 1.0e-11 m/s). Der Standardbericht bleibt unverändert.

• Porkchop auf der Ephemeride DE440 (CAP-20b): maneuver::porkchop_kernel durchfährt C3 und Ankunfts-V∞ auf heliozentrischen Zuständen aus einer DE440-SPK. Neue Zeile, VALIDATED gegen SPICE-Zustände

  • pykep 3.0.1 (vorab registriert 2d857fb1; Erde zu Mars 2026-2028, 304 Zellen, schlechtester Wert 2.6e-14, dieselbe Zelle mit minimalem C3).

• Nichtgravitatives Makromodell für LRO: NOT MET (DS-LRO-10, vorab registriert e82047e2). lunar_od::LunarMacroModel (optional über LunarForceModel::macro_model): ebene Platten mit direkter Sonnenstrahlung mit dem Schatten des Mondes, ein der Sonne nachgeführtes Array sowie Mond-Albedo und thermisches IR; LunarMacroModel::lro_generic ist eine gekennzeichnete generische LRO-Näherung aus veröffentlichten Fakten (keine Bus-Platten: Die Plattentabelle konnte nicht beschafft werden). Beim LRO-Bogen von 4 h lässt es den reduziert-dynamischen RMS bei 6,668 m und den dynamischen bei 11,94 m, mit einem unplausiblen Strahlungsfaktor (etwa +21 / −22), sodass alle drei Zielwerte verfehlt werden. Der Befund ist durch einen Test festgehalten, und keine Standardausgabe ändert sich (docs/design/evidence/ds-lro-10-macro-model/RESULTS.md). Das optionale lunare Kanonenkugel-SRP verwendet jetzt den konischen Schatten des Mondes statt den der Erde (forces::conical_shadow_body).

• Lunare Bahnbestimmung: optionale feste k2-Gezeit und selenozentrische Relativität (DS-LRO-11), standardmäßig aus (LunarForceModel::lunar_tide, ::relativity); ein Schalter KSHANA_LRO_DEGREE für die ANISE-Kreuzvalidierung (DS-LRO-04); eine Fixture mit einem LRO-Bogen von 24 h und eine nur informative Anpassung über einen langen Bogen (DS-LRO-09). Informationsläufe sind in docs/design/evidence/ds-lro-09-11-longer-arc/RESULTS.md festgehalten; keine veröffentlichte Zahl ändert sich.

• CR3BP-NRHO 9:2 gegen CAPSTONE (CAP-29d): neue Zeile MODELLED, die die kreisförmig-eingeschränkte NRHO der Engine gegen die geflogene Bahn von CAPSTONE misst (JPL Horizons, März 2023; vorab registriert 4e868170): Periode 1,07 %, Apolun 0,05 %, Perilun 4,1 % von den Mittelwerten von CAPSTONE, innerhalb der registrierten Zielwerte von 3 / 5 / 20 %. Eine Messung, keine Validierung.

• CR3BP-Rotationszustände nach mondzentriertem ICRF (RM-34, FUT-06): cr3bp::to_moon_centred_icrf / from_moon_centred_icrf / to_moon_centred_icrf_de440 bilden einen dimensionslosen rotierenden Erde-Mond-Zustand auf die momentane Erde-Mond-Linie von DE440 ab, einschließlich der Rate des Bezugssystems außerhalb der Ebene. Neue Zeile, VALIDATED gegen ein SPICE-Zwei-Vektor-Bezugssystem (vorab registriert 2313eb1b, vor jedem Lauf geändert d5ef79b3; 72 Fälle, schlechtester Wert 1.8e-7 m und 1.2e-9 m/s).

• CR3BP-Familienmitglieder gegen die JPL Three-Body Periodic Orbits API: NOT MET (RM-35, vorab registriert a9074f65). cr3bp_family (Halo-, NRHO- und DRO-Korrektur, Stabilitätsindex der Monodromie, Pseudo-Bogenlängen-Fortsetzung) stimmt bei 54 von 58 API-Mitgliedern bei jedem Zielwert überein (Zustand, Periode und Jacobi überall innerhalb von 1e-10). Ein L1-Halo-Stabilitätsindex (9.5e-2) und drei Schließungen kleiner DROs (1.5e-8 bis 3.3e-8 gegen 1e-8) verfehlen ihn, daher ist das Modul #[doc(hidden)] und keine Zeile beansprucht es. Ergebnisse: docs/design/evidence/cr3bp-families/RESULTS.md.

• Optionale lunare Orientierung und Umgebung nach DE440 (FUT-05, DS-LRO-08; Standards unverändert): lunar_frame::try_icrf_to_moon_pa_de440, lunar::try_mci_to_mcmf_de440 / try_mcmf_to_mci_de440 (epochenverankert, Hauptachsen nach DE440) und lunar_od::De440LunarEnvironment (eingebettete DE440-PA-Orientierung plus die geozentrische Sonne und der geozentrische Mond aus einer vom Nutzer gelieferten DE440-SPK). Gegen ANISE (vorab registriert ea537710): Orientierung innerhalb von 3.5e-7 rad und LRO-Anpassungen innerhalb von 1 mm, aber das Ephemeriden-Teilstück verfehlte seinen Zielwert (Sonne 30,7 m, Mond 1,1 m, ein Zeitversatz von ~1 ms auf der ANISE-Seite), daher ist es keine validierte Zeile. Ergebnisse: docs/design/evidence/fut05-de440-lunar-env/RESULTS.md.

• Datum der Kampagne im lunaren Bezugssystem, konditionsskalierter NumPy-Zielwert: NOT MET (vorab registriert b887eb05; bleibt MODELLED). Schritt 0 schließt den Pseudo-Inversen-Rückfall als Ursache der Lücke von 0,30 bei geschätzten Stationen aus; NumPy stimmt bei sechs von acht Szenarien innerhalb des Zielwerts überein, aber stations_estimated verfehlt ihn (6.8e-6 gegen 5.9e-7), und am frischen Datum 2026-12-01 macht eine unbeobachtete Bake am Südpol die Informationsmatrix der Bake rangdefizient, was die unveränderte unabhängige Referenz nicht auswerten kann. Ergebnisse: docs/design/evidence/mr05-lunar-datum-cond/RESULTS.md.

• Datum des lunaren Bezugssystems aus einer realen Beobachtungskampagne (analytischer Mond) VALIDATED an frischen EDC-Normalpunkten von 2025 (vorab registriert 31f5283, bevor einer abgerufen wurde): Die unveränderte unabhängige Referenz aus SPICE und NumPy stimmt bei Buchführung, Rängen und Nullkopplung überein und innerhalb von 1.11e-3 bei den Sigmas (Zielwert 1e-2), 8.95e-4 bei der Kondition und 1.79e-3 bei den Verhältnissen quer/längs (Zielwert 2e-2). Eine Library-Prüfung allein der Kovarianzberechnung; die Zielwerte unterscheiden keine Mondmodelle. Ergebnisse: docs/design/evidence/mr06-llr-analytic-fresh/RESULTS.md.

• IAU-Orientierung und GM der vierzehn hinzugefügten Körper des Sonnensystems, aus der Zeile „Physical constants of every solar-system body“ in eine Zeile VALIDATED ausgelagert (vorab registriert 154bc54): Body::iau_rotation_et stimmt mit SPICE pxform auf pck00011 innerhalb von 1e-9 rad bei 574 Matrizen zu den ursprünglichen Epochen und bei 574 zu 41 frischen, nie zuvor verglichenen Epochen überein (schlechtester Wert Phobos 1.38e-10 rad), und Body::mu entspricht gm_de440 für alle vierzehn Körper. Der Rest der ursprünglichen Zeile (J2, mittlerer Radius, der Bericht) bleibt MODELLED. Ergebnisse: docs/design/evidence/mr08-body-orientation/RESULTS.md.

• Lambert mit mehreren Umläufen (maneuver::lambert_multirev): jede Lösung mit bis zu drei Umläufen, beide Zweige. Neue Registerzeile, VALIDATED gegen pykep 3.0.1 (vorab registriert a75de851; 382 Fälle, 1058 Lösungen, größte Geschwindigkeitsdifferenz 1.6e-13 gegen 1e-8). Der interne Kepler-Landing-Wächter fand bei einem Bogen mit e = 0,994 eine Einschränkung von maneuver::kepler_universal; sie ist in docs/design/evidence/lambert-multirev/RESULTS.md festgehalten.

• Solarer Strahlungsdruck nach Box-Wing und ECOM2 (DS-PA-14), optional. srp_boxwing: ein Box-Wing-Modell aus ebenen Platten mit den Galileo-FOC/IOV-Tabellen aus den GSC-Satellitenmetadaten, bei nominaler GNSS-Gier-Steuerung, mit Strahlungsfaktor und Ableitungen pro Panel, sowie das empirische ECOM2-Modell mit seinen Ableitungen. Ausgewählt mit ForceModel::box_wing_srp / PreciseForceModel::box_wing_srp (Felder srp_boxwing, Standard None: der Kanonenkugel-Pfad und jeder Golden-Wert bleiben unverändert); bei einem Box-Wing-Satz ist cr sein Strahlungsfaktor. Verglichen mit Orekit 12,2 unter einer Vorregistrierung (xval/srp-boxwing-orekit/): jeder Zielwert erfüllt, etwa 1e-15 relativ; VALIDATED als Modellauswertung, die Vorhersage des Galileo-SRP bleibt MODELLED.

• SRP-Schatten der abgeplatteten Erde und Randverdunkelung der Sonne (FUT-09, RM-11). Neues Modul srp_shadow: oblate_conical_shadow (verdeckendes WGS-84-Ellipsoid), limb_darkened_shadow (Eddington-Gesetz) und ShadowModel, ausgewählt mit ForceModel::srp_shadow (Standard: der bestehende sphärische konische Schatten, unverändert); forces::srp_accel_with_lit_fraction. Der Schatten der abgeplatteten Erde stimmt mit dem Beleuchtungsverhältnis von Orekit 12,2 innerhalb von 7.4e-9 über 2400 Geometrien überein (VALIDATED, xval/srp-oblate-shadow-orekit/); die Randverdunkelung hat keine externe unabhängige Referenz (MODELLED).

• NRLMSISE-00-Thermosphäre (FUT-08, RM-10, DS-PA-13). nrlmsise00: eine Portierung von gtd7 und gtd7d (Schalter, Modi mit täglichem Ap und 3-stündlichem ap-Array) aus der gemeinfreien C-Version des NRL-Fortran. Sie ist bitgleich mit dieser C-Portierung und liegt innerhalb von 1.9e-6 relativ zu pymsis 0.13.0 (NRL-Fortran, einfache Genauigkeit) auf einem Raster mit 720 Punkten, und sie reproduziert die 17 veröffentlichten Testfälle (VALIDATED; xval/nrlmsise00-pymsis/). Das validiert die Portierung, nicht die Genauigkeit des Modells gegenüber gemessener Dichte.

• Optionale Stufe für die Luftwiderstandsdichte nach NRLMSISE-00. forces::DensityModel::{Exponential, Nrlmsise00 { f107a, f107, ap }}, forces::drag_accel_with_density, density_at und propagator::ForceModel::drag_density. Das statische Exponentialmodell bleibt der Standard, Bit für Bit. Das Weltraumwetter ist pro Modell konstant. VALIDATED auf Bahnebene gegen den eigenen NRLMSISE-00-Luftwiderstand von Orekit 12,2 über 24 h (schlechtester Wert 0,03 m gegen bis zu 142 km Luftwiderstandsverschiebung; xval/drag-tier-orekit/).

• Optionale DE440-Sonne und -Mond im Cowell-Propagator (RM-33, FUT-10). propagator::ForceModel::with_ephemeris nimmt jeden EphemerisProvider (z. B. einen DE440-KernelEphemeris) für die Terme des dritten Körpers und des SRP; sie lehnt einen Anbieter ab, der die Epoche nicht bedienen kann, zählt Rückfälle auf die analytische Reihe und ist standardmäßig aus. EphemerisProvider::relative_position_jd2 behält die Zweiteilpräzision. Gegen Orekit 12,2 mit dessen eigenem DE440-Leser stimmen Bahnen von 24 h auf 0,017 m überein; der vorab registrierte Zielwert für die Position von Sonne und Mond wurde verfehlt (6,4 m / 0,24 m; SPICE zeigt dieselbe Lücke), daher MODELLED (xval/propagator-de440-orekit/).

• Optionale atmosphärische S1-Gezeit (DS-PA-03). tides::atmospheric_tide_s1 und s1_air_tide_acceleration (Biancale & Bode 2006, GFZ STR06/01 Tabelle 1 Modell N1, Grade 2–6), aktiviert mit air_tide_s1() bei propagator::ForceModel und precise_od::PreciseForceModel; standardmäßig aus. MODELLED (Koeffizienten gegen die veröffentlichte Tabelle erneut geprüft; keine externe unabhängige Referenz für die Kraftwirkung).

• Batch-Bahnbestimmung aus Range-Rate und Azimut/Elevation mit Elevationsmaske (RM-36, FUT-13). orbit_determination::determine_orbit_batch_tracking, simulate_tracking, predict_tracking, propagate_with_stm (variationelle STM mit analytischen Zweikörper- und J2-Ableitungen), is_visible, measurement_with_partials; batch_ls::gauss_newton_analytic. Der Pfad nur mit Entfernung bleibt unverändert. Verglichen mit der Batch-Kleinste-Quadrate-Methode von Orekit 12,2 über 8 vorab registrierte Szenarien: jeder Zielwert erfüllt, außer der rauschfreien Zustandsübereinstimmung (≤ 1 cm), die bei 2 von 4 Szenarien mit 1,46 und 1,74 cm verfehlt wurde, wobei kshana innerhalb von 1e-8 m der Wahrheit liegt; festgehalten, MODELLED.

• SP3-Genauigkeitsgewichtung (DS-PA-06). sp3::parse_sp3_accuracy und Sp3Accuracy::position_sigma_m bilden die Genauigkeitscodes aus Header und je Datensatz auf Beobachtungs-Sigmas ab; eine SP3-gewichtete Variante der Galileo-Anpassung (3D-RMS der Stufe 2 0,035 m gegen 0,070 m ungewichtet) kommt neben den unveränderten aufgezeichneten Läufen hinzu. MODELLED.

• Swarm-A-Dispatch-Job für den vollen Bogen (DS-PA-08) in .github/workflows/agency-od-validation.yml.

• Planetare Gravitation aus PDS-SHADR-Tabellen (CAP-30, Teil von CAP-31). SphericalHarmonicField::from_shadr (src/gravity_pds.rs) liest Mars GMM-3 (Grad/Ordnung 120) und GRAIL GL0660B (Grad/Ordnung 660); Body::with_gravity_field hängt jedes geladene Feld an (Standards unverändert). Ausschnitte bis Grad 20 sind mitgeliefert (NASA PDS, gemeinfrei; tests/fixtures/planetary_gravity/NOTICE.md); die vollständigen Dateien lädt xval/planetary-gravity-pyshtools/fetch_data.sh. VALIDATED gegen pyshtools 4.14.1 (innerhalb von 4e-15 der gesamten Gravitation bei Grad/Ordnung 120 über die ganze Kugel, 5e-14 bei Grad/Ordnung 660 für |lat| ≤ 60°); die Verdrahtung im körperfesten Bezugssystem bleibt MODELLED (das native Bezugssystem jedes Feldes ist nicht das verwendete IAU-System).

• Gravitation hohen Grades bis Grad 2190 (RM-14, FUT-07). SphericalHarmonicField::acceleration_hf / potential_hf (modifizierte Vorwärtsspalte nach Holmes–Featherstone, kein Unterlauf, keine Polsingularität), prepare_high_degree, ein streamender ICGEM-Lader from_gfc_file / from_gfc_reader (Prüfungen von Norm und Maximalgrad, Gezeitensystem festgehalten, zeitvariable Terme abgelehnt) und scripts/fetch_egm2008.sh (vollständiges EGM2008, SHA-256 festgelegt, nicht mitgeliefert; Tests gesteuert über KSHANA_EGM2008_GFC). propagator::FieldEvaluator wählt es beim optionalen Geopotential aus. Stimmt mit Orekit 12,2 auf 7.3e-17 m/s² bis Grad 2190 überein, und eine Bahn von 24 h mit 200×200 stimmt auf 0,13 m überein. MODELLED: pyshtools verfehlte den vorab registrierten Zielwert nahe dem Pol (auf pyshtools zurückgeführt), und die Empfindlichkeitskontrolle der Bahn bei Grad 70 verfehlte ihren Zielwert (0,73 m < 1 m); beides ist in xval/ festgehalten.

• DOP853-Integrator (FUT-11). integrator::integrate_dop853, integrate_dop853_checked, integrate_dop853_dense (dichte Ausgabe 7. Ordnung), dop853_step, dop853_initial_step, mit einem Schrittwächter, der im Zweifel sperrt; propagator::Integrator::Dop853, propagate_dop853, propagate_dop853_checked. Der Standardtreiber bleibt unverändert. VALIDATED gegen SciPy 1.18.1 solve_ivp(method="DOP853"): Einzelschritte innerhalb von 5.6e-15, übereinstimmende Schrittfolgen, Endzustände innerhalb von 1.6e-12 (xval/dop853-scipy/).

• Robuster Kepler-Löser (FUT-12). Neues Modul kepler: solve_kepler_markley (Startwert nach Markley 1995, auslöschungsfreies Residuum) für alle 0 ≤ e < 1, eingebettet in propagator::solve_kepler_robust. VALIDATED gegen mpmath-Wurzeln mit 50 Stellen auf 0,9 ε·|E| bis e = 0,999999 (xval/kepler-mpmath/).

• Optionale tesserale Erdgravitation im Cowell-Propagator (RM-09). propagator::ForceModel erhält geopotential: Option<Geopotential> (with_geopotential, with_egm2008(nmax)). Es wertet ein SphericalHarmonicField (mitgeliefertes EGM2008 bis Grad/Ordnung 70 oder jede ICGEM-Datei .gfc) in einem erdfesten Bezugssystem aus, das über den Erdrotationswinkel (EarthFixedFrame::Era) oder die CIO-Kette GCRS-nach-ITRS (EarthFixedFrame::Cio) erreicht wird. Standard None: Keine bestehende Ausgabe ändert sich. VALIDATED gegen Orekit 12,2 Holmes–Featherstone über 24 h (6 Fälle, schlechtester Wert 0,036 m), mit den in xval/cowell-tesseral-orekit/PREREGISTRATION.md vorab registrierten Zielwerten.

• Zweiteilige Julianische Daten durch die Erdrotation auf dem Bahnpfad: jd2::gmst82, cio::gcrs_to_itrs_matrix_jd2, frames::teme_to_itrf_jd2 / itrf_to_teme_jd2, orbit::Propagator::position_in_frame_jd2 und own_jd2_utc, From-Umwandlungen zwischen jd2::Jd2 und timescales::TwoPartJd sowie ein optionales two_part_jd = true für das Szenario ephemeris (ECEF, Bodenspur und Stationsansicht; standardmäßig aus und unverändert, und der Schlüssel bleibt im Szenario-Hash weg, wenn er aus ist). Neue Registerzeile, VALIDATED gegen pyerfa gmst82/c2t06a (vorab registriert b10475ee; 40 Daten: GMST bitgleich, Matrix innerhalb von 2.7e-14, Rotation über Schritte von 1 µs innerhalb von 1.1e-14 rad, wo der Pfad mit einzelnem f64 sie verfehlt). Die Epoche des Cowell-Kraftmodells bleibt einzeln f64; der Grund steht in seiner Dokumentation.

• EOP-Vorhersage über die Tabelle hinaus (EopSeries::with_ls_ar_prediction, EopSeries::last_mjd): eine optionale Erweiterung einer IERS-Erdorientierungsreihe durch den LS+AR-Prädiktor, der an ihrer letzten Zeile ausgegeben wird, sodass die Bezugssystemargumente einer späteren Epoche der Vorhersage folgen, statt an der letzten Zeile zu klemmen. Antworten innerhalb der Tabelle sind bitgleich (getestet); die Reihe klemmt weiterhin, solange dies nicht aufgerufen wird. Die Genauigkeit der Vorhersage bleibt der bestehende LS+AR-Befund gegen Bulletin A (MODELLED).

• Offsets dX, dY des Himmelspols auf der CIO-Kette (cio::gcrs_to_cirs_matrix_with_offsets), und direkte ERFA-Vektorprüfungen von precession_matrix, teme_to_gcrs_matrix und der neuen Funktion. Neue Registerzeile, VALIDATED gegen pyerfa (vorab registriert 979c1e39; 40 Epochen 1950–2100: Präzession und CIO bitgleich, TEME→GCRS innerhalb von 1.1e-10 rad, der vorhergesagte Effekt der zweitermigen Reihe der Äquinoktien-Gleichung). Bestehende Funktionen bleiben unverändert.

• UTC vor 1972 auf dem zweiteiligen Zeitpfad (timescales::tai_minus_utc_on_date, sowie Jd2::from_utc_calendar, jd2::utc_to_tai und jd2::tai_to_utc ab 1960-01-01): die Ära mit driftender Rate („Gummisekunde“), mit der Drifttabelle von SOFA, gebrochenen Schritten am Tagesende und der Skalierung des Tagesbruchteils von UTC auf SI. Neue Registerzeile, VALIDATED gegen pyerfa dtf2d/utctai/taiutc (vorab registriert 23c40661; 117 Zeitpunkte 1960–1971, schlechtester Wert 2.9e-11 s gegen einen Zielwert von 1 µs). Jedes Ergebnis ab 1972 ist bitgleich (Prüfsumme vor der Änderung festgelegt). Vor 1960 ist TAI − UTC 0, wie in SOFA. Das einzelne f64 timescales::tai_minus_utc bleibt unverändert.

• GLONASS-Broadcast-Satellitenuhr (GlonassEphemeris::sv_clock_bias_s): −τn + γn·(t − tb) aus dem RINEX-Datensatz, zu einer auf der Satellitenuhr abgelesenen Zeit (zwei Festkomma-Iterationen, die RTKLIB-Konvention). Die geparsten −τn und γn waren zuvor ungenutzt. Neue Registerzeile „GLONASS broadcast satellite clock and broadcast-orbit propagation“, VALIDATED gegen RTKLIB 2.4.2-p13 geph2clk/geph2pos (vorab registriert e099c42a; 292 Fälle in einer echten Broadcast-Datei von 2013: Uhrendifferenz 0 s, schlechteste Position 1,1 mm gegen einen Zielwert von 1 cm). Library-Funktion; keine Szenarioausgabe ändert sich. Es wird keine Transformation PZ-90.11 → ITRF angewandt, und das Modul sagt das.

• PPP-Zeitlösung gegen die IGS-Stationsuhr (0,36, FUT-19): Die Empfängeruhr des Float-PPP-Filters auf WTZR stimmt mit der kombinierten IGS-Final-Uhr für die Station auf 0,075 ns (Standardabweichung) überein, mit einem konstanten Versatz von −0,66 ns über die konvergierten zwei Stunden. Die Zielwerte wurden in xval/ppp-time/ vorab registriert. VALIDATED (neue Registerzeile). Neue Fixture igs_2025055_WTZR_05m_0006.clk, die Stationsuhr-Datensätze der IGS-Final-Uhrendatei, die bereits für die Satellitenuhren verwendet wird.

• PPP-Parität mit gLAB (0,36, WP-07, RM-31): gLAB 6.0.0 wurde auf denselben WTZR-Eingaben als getrenntes Werkzeug ausgeführt (Apache-2.0-Kern; Prüfsumme des Downloads gegen die veröffentlichte Liste geprüft), mit der Kommandozeile eines vor dem Lauf eingecheckten verfahrensmäßigen Nachtrags. Bei ihrem ersten registrierten Lauf stimmen das Float-PPP von Kshana und das von gLAB bei 240 von 240 Epochen innerhalb von 0,05 m überein und bei der letzten auf 5,0 mm. Der SPP-Zielwert wurde verfehlt (Median 1,187 m gegen 0,50 m) und ist als Befund festgehalten: Die eigenen SPP-Lösungen von gLAB und RTKLIB unterscheiden sich voneinander um 0,852 m. Die registrierte Regel lässt daher die Teilstücke beider Werkzeuge insgesamt nicht erfüllt, während die PPP-Parität gilt.

• Lesen von RINEX-4-Navigationsdateien (0,36, WP-07, PRO-41): rinex::parse_nav liest RINEX-4.00-4.02-Navigationsdateien (> EPH GPS LNAV, Galileo I/NAV und F/NAV, BeiDou D1/D2, QZSS LNAV; andere Datensätze bis zum nächsten Datensatz-Header übersprungen), und parse_nav_with nimmt Optionen. VALIDATED gegen die zusammengeführte IGS-RINEX-3-Datei desselben Tages: jedes dekodierte Feld identisch und 0 m in der Position. Das Lesen von RINEX 2/3 bleibt unverändert.

• BeiDou-GEO-Broadcast-Positionen (optional): NavParseOptions::include_beidou_geo und RinexEphemeris::sv_position_ecef_bds_geo (BDS ICD, Neigung −5 Grad). parse_nav überspringt GEOs weiterhin. MODELLED: Der vorab registrierte Vergleich mit einer präzisen Bahn ist datengesteuert und noch nicht gelaufen.

• RINEX-4-Beobachtungsdateien: Eine echte RINEX-4,00-MGEX-Beobachtungsdatei wird in Tests gelesen (MODELLED, Formatkonformität).

• RTK mit LAMBDA auf echtem RINEX (0,36, WP-07 ★): rtk_real::run_rtk, Doppeldifferenzen kurzer Basislinien aus Zweifrequenz-GPS-Code und -Phase mit einem Float-Kalman-Filter und ganzzahliger Fixierung nach LAMBDA (Ratio-Test). VALIDATED an den IGS-Stationen WTZR und WTZZ (1,4 m voneinander entfernt) gegen ihre ITRF2020-Basislinie unter vorab registrierten Zielwerten: nach den ersten zehn Minuten bei jeder Epoche fixiert, Basislinienfehler Median 4,5 mm und 95. Perzentil 5,5 mm.

• RTKLIB-Parität des PPP mit Echtdaten (RM-31): xval/ppp-parity/run.sh und tests/ppp_parity_glab_rtklib.rs mit vorab registrierten Zielwerten. RTKLIB v2.4.2-p13 PPP auf denselben WTZR-Eingaben stimmt bei der dritten Registrierung mit Kshana bei jeder Epoche der letzten zwei Stunden innerhalb von 5 cm überein (9,7 mm am Ende); die ersten beiden Läufe, als Befunde festgehalten, hatten die feste Gezeit aus und die Empfängerantenne auf dem Basis-Slot von RTKLIB. Der Zielwert für die Single-Point-Parität wurde verfehlt (1,09 m Median gegen 0,5 m). Das Teilstück mit gLAB ist nicht gelaufen (datengesteuert).

• Kodierer für Navigationsnachrichten über LNAV hinaus (0,36, WP-07, PRO-40): gnss_navmsg kodiert GPS CNAV (Nachrichtentypen 10, 11, 30; CRC-24Q; kontinuierliche Kodierung mit Rate 1/2, K=7), Galileo I/NAV (Worttypen 1-5 in geraden/ungeraden nominalen Seiten; 30x8-Interleaver; Sync 0101100000) und Galileo F/NAV (Seitentypen 1-4; 61x8-Interleaver; Sync 101101110000), mit Test-Dekodierern. MODELLED: Round-Trips und bekannte Antworten aus dem ICD; eine vorab registrierte Prüfung, dass gesendete Galileo-Ephemeriden auf dem LSB-Raster des Kodierers liegen, hielt (schlechtester Wert 3.6e-3 LSB), verfehlte aber ihren Zielwert für die Satellitenzahl (15 von 20), festgehalten. Die Kodierer sind Library-Funktionen; die Szenenanbindung ist nicht Teil dieser Änderung.

• IONEX-Dateileser (0,36, WP-07): ionex::parse_ionex_file mit IonexFile, IonexHeader, IonexEpoch, IonexFileMap und IonexTimeInterp: ein strenger IONEX-1,0-Leser mit festen Spalten, mit Epochen, die ab dem Tag der ersten Karte gezählt werden, 9999 als fehlend gelesen, RMS-Karten und den Zeitinterpolationen des Formats (nächste, aufeinanderfolgende und rotierte Karte); Slant-TEC auf der Schalenhöhe des Headers. Geprüft an einer eingecheckten synthetischen Karte und, datengesteuert (zur Testzeit mit festgelegter SHA-256 geladen, nicht mitgeliefert), an einem Ausschnitt eines echten CODE-GIM: jeder Knoten exakt; die Interpolation stimmt mit einer Formelreferenz auf 4e-13 TECU überein. iontec von RTKLIB stimmt auf 3.6e-13 TECU bei 6885 Punkten überein (vorab registriert B6). VALIDATED auf datengesteuerter Evidenz (Entscheidung des Eigentümers, 2026-10-13): Der Test schlägt bei jeder anderen Karte als der SHA-festgelegten fehl.

• Hatch-Trägerglättung (0,36, WP-07): hatch::HatchFilter und pvt::assemble_epoch_precise_smoothed, die divergenzfreie (ionosphärenfreie) Form im präzisen Single-Point-Aufbau. MODELLED mit festgehaltenem Befund: An der IGS-Station WTZR senkt sie den medianen Single-Point-Fehler von 1,55 m auf 1,12 m und das 95. Perzentil von 3,47 m auf 3,21 m, was unter der vorab registrierten Verringerung von 40 % bleibt (der verbleibende Fehler ist biasartig, kein Rauschen).

• Float-PPP auf echtem RINEX (0,36, WP-07): ppp_real::run_ppp, ein statischer Float-Filter für präzise Punktbestimmung auf echtem Zweifrequenz-GPS-Code und -Phase mit IGS-Final-Produkten (Antennenversätze und -variationen, feste Erdgezeit, Phase-Wind-up, Shapiro-Verzögerung, geschätzte feuchte Verzögerung, Erkennung von Cycle-Slips), mit parse_antex_receiver. VALIDATED an der zurückgehaltenen IGS-Station WTZR gegen ihre ITRF2020-Koordinate unter vorab registrierten Zielwerten: nach 6 h beträgt der Fehler 1,5 mm horizontal und 2,9 cm vertikal, und jede Epoche der letzten zwei Stunden liegt innerhalb von 10 cm.

• Interpolation der präzisen Uhren aus SP3 (0,36, WP-07): Sp3File::clock_s und clock_nodes interpolieren die tabellierten SP3-Satellitenuhren linear zwischen den beiden einschließenden gültigen Knoten (Sentinel für schlechte Uhr übersprungen), und ClockRinex::from_sp3 übergibt sie an PreciseProducts, sodass die präzise Kette allein aus einer SP3 läuft. VALIDATED gegen die IGS-Final-Uhren von 30 s vom 2025-02-24 unter vorab registrierten Zielwerten: 32 GPS-Satelliten, RMS am Mittelpunkt 0,121 ns (Zielwert 0,15 ns), 95. Perzentil 0,265 ns (Zielwert 0,30 ns).

• RAIM neben den Gütemaßen des Uhren-Holdovers (CAP-05b): ein optionaler Abschnitt [integrity] in der Art clock meldet einen getrennten Block integrity_fom (Snapshot-RAIM auf einem voreingestellten Himmel von einem genannten Standort: Urteil je Epoche und Schutzniveaus, Verfügbarkeit; nicht verfügbar, solange GNSS verweigert ist, nie extrapoliert). Die Holdover-Zahlen bleiben unverändert; ohne den Abschnitt ist die Ausgabe byteidentisch. MODELLED.

• Am JammerTest 2024 kalibrierte Schwellen für das Empfänger-Vertrauen (CAP-13): eine vorab registrierte Kalibrierung der Monitore für C/N0-Abfall, AGC und Jamming-Indikator am öffentlichen JammerTest-Datensatz 2024 (zur Laufzeit geladen, nie mitgeliefert; examples/jammertest_trust_calibration.rs), nur als optionales [monitors] profile = "jammertest-2024-calibrated" ausgeliefert (1,5 dB, 3,5 Sigma, 29). Zurückgehalten: Die Zielwerte für AGC, Jamming-Indikator und Vereinigung bestehen; der Fehlalarm-Zielwert für C/N0 wird nicht bestanden (0,023 gegen 0,02), daher ist die Zeile MODELLED (xval/jammertest-trust/RESULTS.md). Standards und Ausgaben ohne das Profil bleiben unverändert.

• ARAIM-Fehlerhypothesen für mehrere Satelliten (CAP-05a): die Teilmengenregel des ADD v4.2, über Paare hinaus verallgemeinert (add_v42_subset_plan, add_v42_protection_levels_to_order; Ordnung 2 ist genau der bestehende, von MAAST geprüfte Pfad) und ein optionales fortgeschrittenes RAIM über diese Hypothesen (araim_subset_raim), das bei erkanntem Fehler die Teilmenge der größten Trennung meldet. Prioren, die tiefere Teilmengen brauchen, werden abgelehnt, nie gekürzt. MODELLED.

• Skyline im Empfänger-Vertrauen (FUT-01): Eine Empfänger-Vertrauens-Sitzung kann eine [skyline] angeben; Satelliten dahinter gehen für den Himmel verloren (sky-blocked, behind_skyline, open_fraction) und ihre Verluste werden als geometry eingestuft, nie als environment; ohne sie sind der Azimutlücken-Rückfall und jede Ausgabe wie zuvor. Der Generator für Besatzungstraining erhält ein Ereignis natural-degradation (ein blockierter Himmel, keine Störung) und das Szenario scenarios/training/fjord-natural-degradation.toml. Der UERE-x-DOP-Monte-Carlo erhält die zwei Geometrien mit maskierter Skyline aus der Entwurfsnotiz, allein vorab registriert: alle 26 Prüfungen bestehen.

• Prüfung von Zeitstempeln nach RFC 3161 (CAP-14): kshana::evidence::tsa::verify_token prüft offline die Signatur eines Zeitstempel-Tokens (RSA PKCS#1 v1.5, RSA-PSS, ECDSA P-256 und P-384), seine ESS-Bindung an das Signaturzertifikat, die Verwendung timeStamping des Signierers und seine Kette zu einem vertrauenswürdigen Anker zur genTime des Tokens; kshana evidence verify --tsa-ca <anchors.pem> wendet es auf die timestamp.tsr eines Pakets an (optional; ohne sie bleibt der Bericht unverändert). VALIDATED, eng gefasst: alle 27 selbst erzeugten Fälle stimmen bei Urteil und genTime mit OpenSSL 3.0.13 überein, unter einem Vergleich, der vorab registriert wurde, bevor der Prüfer geschrieben war. Der Widerruf wird nicht geprüft.

• Verifikationsstufen je Kennzahl für jede Art (RM-04): Das Ergebnis jeder Szenarioart endet jetzt mit einem Block figure_tiers, der ihre Kernzahlen nennt, die Zeile der Verifikationsmatrix, der jede gehört, und die aus dieser Zeile gelesene Stufe (Kennzahlen, die keiner Zeile gehören, werden als ohne Stufe aufgeführt). Der Block wird nach dem Lauf angehängt und lässt sich Byte für Byte auf das vorherige Dokument zurückführen (api::without_figure_tiers). lunar-station-coverage hat kein figure_tiers, bis eine neue datierte Vorhersage die eingefrorene ersetzt; leo-ppp, solar-system, sweep und sweep-nd haben keine skalare Kernzahl, und lunar-attack-surface schreibt kompaktes JSON. Kampagnenmitglieder behalten ihre Dokumente ohne Stufe.

• Quanten-Preset quantum-cai-coast (CAP-08c): ein mitgeliefertes Inertialszenario, in dem ein Kaltatom-Interferometer-Beschleunigungsmesser, spezifiziert durch seine Interferometer-Physik ([accel_quantum.cai] mit einem genannten Schwingungsniveau der Plattform), während eines GNSS-Ausfalls von 110 Minuten gegen einen Quarz-Beschleunigungsmesser in Navigationsqualität ausläuft. MODELLED.

• Exakte äquivalente Freiheitsgrade nach Greenhall (CAP-03): allan::edf_greenhall, der vollständige Algorithmus von Greenhall und Riley (2003) (Differenzordnungen 1 bis 3, Rauschexponenten +2 bis -4, überlappend und nicht überlappend, modifiziert und unmodifiziert, mit den Tabellen für großes J), mit Hüllfunktionen für ADEV, MDEV und HDEV. VALIDATED unter einem vorab registrierten Vergleich mit allantools 2024,6: 4.876 Rasterpunkte innerhalb von 6.0e-13 relativ; allantools scheitert bei 32 weiteren Punkten, die ohne Wert der unabhängigen Referenz festgehalten sind. Die Konfidenzintervalle von assurance::uncertainty sind Bit für Bit unverändert.

• Fehlerterme des Kaltatom-Interferometers (RM-26/27/28): Raman-Laser-Phasenrauschen (mit dem Term der Rückreflexionsverzögerung), der Wellenfront-Krümmungsbias einer thermischen Wolke (reine Defokussierung, mit einem Detektionsradius) und die Auflösung der Streifenmehrdeutigkeit (klassisch gestützt und zwei Abfragezeiten), als Library-Funktionen in src/inertial/cai_error_terms.rs, jede geschlossene Form gegen Quadratur oder Monte Carlo geprüft. MODELLED; noch nicht aus einer Szenarioart erreichbar (docs/QUANTUM-MODELS.md).

• Uhrenprotokoll-Formate (RM-03): src/clock_log.rs liest RINEX-Uhrendateien, Phasen- oder Frequenzprotokolle im ASCII-Stil von TimeLab und Zählerprotokolle des TAPR TICC in eine normalisierte Phasenreihe (tau0 angegeben oder gefunden, Lücken gezählt, eine Lückenregel). Optional: Eine Telecom-Timing-Reihe kann ein Protokoll benennen ([series.clock_log]), und die Tabelle [clock_log] eines Uhrenszenarios fügt einen Block measured hinzu (ADEV, TDEV, MTIE). Ohne die Tabelle sind beide Arten byteidentisch (docs/CLOCK-LOG-FORMATS.md). Ein vorab registrierter Vergleich an drei synthetischen Protokollen erfüllte seine Zielwerte für Phase und Anbindung; die Schätzer stimmen mit allantools innerhalb von 2.5e-14 überein, wo es auswertet, und es wertet den MTIE-Punkt der gesamten Aufzeichnung nicht aus (festgehalten). MODELLED.

• Wander-Masken für die Frequenzsynchronisation (RM-01): Die Art telecom-timing erhält sieben MTIE- und TDEV-Masken für die Wander-Erzeugung bei konstanter Temperatur, ITU-T G.811 PRC, G.812 Typen I bis III, G.8262 EEC Optionen 1 und 2 und G.8262.1 eEEC, mit den Potenzgesetz-Stücken, die die Tabellen schreiben, und das Referenzszenario scenarios/telecom-synce-eec.toml (ein freilaufender OCXO gegen die EEC-Masken: Er scheitert bei 1.000 s, wo eine Regelschleife die Arbeit leisten muss). Jede Zeile wurde gegen den Text von itu.int erneut gelesen; G.812 (06/2004) wird durch eine vorab veröffentlichte Ausgabe 08/2026 abgelöst, die nicht gelesen werden konnte. MODELLED (eine Abschrift); bestehende Masken und Ausgaben bleiben unverändert.

• Hinweise zum Filter-Prior für die Art gnss-ins (0,36, WP-09, Befund RM-21): Der Standard-Filter-Prior des Pakets passt zu einer IMU taktischer Qualität. Mit einer IMU in Navigationsqualität kann der Standard die fusionierte Auslaufphase schlechter machen als reine freie INS: 52 m gegen 11 m bei einem Flugzeugprofil mit 70 m/s. Setzen Sie [imu_*.filter_prior] passend zur Qualität des Sensors, wie es die neuen Pakete für See, Schiene und Luftfahrt tun. Kein mitgeliefertes Szenario koppelt eine IMU in Navigationsqualität mit dem Standard-Prior: Jedes, das den Standard verwendet, hat Restverzerrungen des Beschleunigungsmessers von mindestens 0,015 m/s². Nur Dokumentation; keine Ausgabe ändert sich.

• Mit den eigenen Lesern eines Simulators geprüfter Test-Bench-Export (0,36, WP-09, CAP-16): Die Bewegungsdateien von kshana bench-export aus 8 mitgelieferten Szenarien wurden von den Lesern für NMEA, Breite/Länge/Höhe und erdfeste Bewegung von gps-sdr-sim zurückgelesen (MIT, Commit 28ca29a6, als getrenntes Werkzeug über xval/testbench-gpssdrsim/ verwendet; es wird keine Signalfunktion aufgerufen). Sie geben die exportierte Trajektorie auf 1,2 mm, 0,15 mm und exakt zurück. BEFUND: Der erdfeste Leser dieses Simulators kann die CSV mit voller Breite nicht aufnehmen, weil sein Zeilenpuffer von 100 Zeichen jede Zeile teilt. docs/TEST-BENCH.md nennt jetzt die zu verwendenden Spaltenschnitte und die Begrenzung des Simulators auf 300 s. VALIDATED (neue Registerzeile); die Bytes des Exports bleiben unverändert.

• GNSS/INS auf dem KF-GINS-Datensatz (0,36, WP-09, FUT-17): Lader und Runner für fusion::kfgins und das Hebelarm-Messmodell im geschlossenen EKF. Auf dem KF-GINS-Demodatensatz (zur Testzeit geladen, nicht mitgeliefert) beträgt der horizontale RMS von Kshana gegen die Referenztrajektorie 1,09 cm gegen 1,11 cm von KF-GINS selbst, und jeder vorab registrierte Zielwert wurde gehalten. VALIDATED auf datengesteuerter Evidenz (Entscheidung des Eigentümers, 2026-10-13): Der Datensatz wird mit SHA-256-Pins geladen, und der Reproduktionspfad steht in xval/kfgins/PREREGISTRATION.md.

• Gekoppelter PNT-Filter im Fusionspaket (0,36, WP-09, FUT-16): Die Art fusion nimmt eine optionale Tabelle [coupled], die einen gestapelten Filter auf Pseudoentfernungen mit einem Bias-Zustand des Beschleunigungsmessers laufen lässt (fusion::coupled::CoupledPntBiasFilter), und fusion::coupled::CoupledPnt3d ist die 3D-Version mit 8 Zuständen. Neues mitgeliefertes Szenario fusion-pnt-coupled: Mit verzerrten Beschleunigungsmessern hält der gekoppelte Modus die Position der Quanten-Suite auf 18,7 m (95. Perzentil) bei voller Integrität, wo die entkoppelten Filter 430 m erreichen. Ohne die Tabelle sind fusion und hybrid unverändert (festgelegt); hybrid lehnt die Tabelle ab. MODELLED.

• GNSS/INS-Pakete für See, Schiene und Luftfahrt (0,36, WP-09, RM-21): mitgelieferte Szenarien gnss-ins-maritime, gnss-ins-rail und gnss-ins-aviation auf der Trajektorienbibliothek und eine optionale Tabelle [tight] für die Art gnss-ins, die Pseudoentfernungen aus einer SGP4-Walker-Konstellation fusioniert (alle Satelliten im Normalfall, die höchsten wenigen bei Verschlechterung). Beim Schienenpaket hält die enge Kopplung die Lösung in Navigationsqualität bei 5,3 m durch einen Einschnitt und Tunnel, gegen 12,9 m bei loser Kopplung. Ohne [tight] ist das Paket unverändert (festgelegt). MODELLED.

• Enge Kopplung mit Trägerphase (0,36, WP-09, RM-25 / FUT-17): fusion::carrier_tc, ein Fehlerzustands-EKF mit ausdrücklicher Empfängeruhr mit zwei Zuständen und Float-Trägermehrdeutigkeiten, angetrieben von einer SGP4-Walker-Konstellation mit Klobuchar- und Saastamoinen-Korrekturen in der Messschleife, Slip-Erkennung über zeitdifferenzierte Trägerphase und Neuinitialisierung der Mehrdeutigkeiten, und einem Lauf nur mit Code auf denselben Messungen zum Vergleich. MODELLED: Bei einer Fahrt in Form einer 8 beträgt die Trägerlösung 2,5 cm gegen 47 cm nur mit Code, und NIS/NEES sind über die Seeds konsistent.

• GNSS/INS-Trajektorienbibliothek (0,36, WP-09, RM-24): Die Art gnss-ins nimmt eine optionale Tabelle [trajectory] mit profile = "straight" | "figure8" | "stop_go" | "aircraft" | "uas" | "csv". Die Profile geben aus dem Wahrheitszustand Euler-Raten und Beschleunigung in Fahrtrichtung vor und leiten die wahre IMU aus der Kinematik starrer Körper ab (koordinierte Kurven, Steigflüge, Coriolis); csv importiert eine Wahrheitstrajektorie (t, lat, lon, alt, vn, ve, vd, roll, pitch, yaw) und löst die IMU, die sie reproduziert. Ohne die Tabelle fliegt das Paket seine historische Fahrt, Bit für Bit (festgelegt). MODELLED.

• DEM-Kacheln nach Breite/Länge für den lunaren Horizont: [terrain] dem_tile_path liest eine Textkachel realdata::lola_dem (Höhen über der mittleren Kugel auf einem Breiten-/Längenraster) anstelle der polar-stereographischen dem_path, sowohl für lunar-station-coverage als auch für moonlight-service-volume; der Bericht gibt die Kachel wieder (terrain.dem_tile, mit ihrer SHA-256). realdata::lola_dem ist jetzt in das Ray-Marching des Horizonts eingebunden. Eine aus dem mitgelieferten Ausschnitt neu abgetastete Kachel gibt der Station den Horizont des Ausschnitts auf 0,22 Grad. MODELLED.

• Gelände am Exportstandort des Service-Volumens: Mit einem Abschnitt terrain trägt jede Zeile des Geometrie-Exports je Satellit von moonlight-service-volume den Wert clears_terrain (der Satellit liegt über der flachen Maske und dem Horizont des Exportstandorts in seinem Azimut), der Bericht trägt den Horizont des Standorts (export_site_terrain), und das Laufzeit-CSV erhält die Spalte. Ohne Gelände ist der Export unverändert. MODELLED.

• Kernfelder aus der Engine (0,36, STUDIO-06): kshana::api::HEADLINE_FIELDS, field_importance_json() und das WebAssembly-field_importance() geben für zwölf Arten an, welche Felder eines Szenarios seine Frage beantworten, die besten zuerst, als gepunktete Pfade (jammers[].eirp_dbw). Das Studio liest sie vor seiner eigenen Rangfolge. Nur Anzeige-Metadaten: Die Engine liest sie nie, keine Szenariodatei braucht sie, kein Ergebnis hängt von ihnen ab. tests/field_importance.rs schlägt fehl, wenn eine Art nicht versendbar ist oder ein Pfad in keinem der mitgelieferten Szenarien der Art gefunden wird (es fing zwei Pfade, die die abgeflachten IDs des Studios ohne die Array-Klammern geschrieben hatten).

• Tabelle Art-zu-Modul aus der Engine (0,36, STUDIO-05): kshana::api::KIND_MODULES, kind_modules_json() und das WebAssembly-kind_modules() geben für jede Szenarioart, deren Zeilen der Verifikationsmatrix ein anderes Modul als ihr eigenes nennen, die Modulnamen an. Die Fähigkeitenkarte des Studios benutzte ihre eigene handgeschriebene Kopie; tests/kind_modules.rs schlägt fehl, wenn eine Art in der Tabelle nicht versendbar ist oder ein Modul in keiner Zeile der Matrix vorkommt. Keine Ausgabe hat sich geändert.

• Kurzer IQ-Lauf im Browser-Build (0,36): iq_signals() und iq_run_short(fs_hz, duration_s, signal, ids, dopplers_hz, cn0_dbhz, seed) im WebAssembly-Modul bauen eine synthetische Szene, akquirieren jeden Satelliten und verfolgen die akquirierten, alles im Speicher, begrenzt auf 0,25 s, 1.000.000 Abtastwerte und 8 Satelliten. Der Szenenbauer und die Signalsuche nach Namen wurden aus dem nur nativen iq::cli (nach iq::scene::synthetic und iq::signals::by_name) verschoben, sodass beide Builds sie teilen; die Ausgabe der Kommandozeile bleibt unverändert. Der native Test und web/smoke.mjs vergleichen dieselbe Anfrage Byte für Byte mit einem Golden-Wert (tests/fixtures/iq_short_golden.json): Seit der Änderung auf portable Mathematik (STUDIO-15, unten) liefern der Browser-Build und der native Build dieselben Bits.

• Typisierte APIs für Python und TypeScript (CAP-34): kshana.pyi typisiert die geschlossenen Vokabulare (ScenarioKind, jeder Artname; ErrorKind; ProvenanceClass) und die Wörterbücher KindMeta und FieldUnit; scenario_kinds() und error_kind() geben sie zurück. Das WebAssembly-Paket fügt run_typed hinzu (ein Lauf als typisiertes Objekt RunOutput mit dem geparsten Dokument als data) und scenario_kinds (die geparsten KindMeta[]), und sein kshana.d.ts trägt dasselbe Vokabular; error_kind ist als ErrorKind | "" typisiert. tests/typed_api_sync.rs hält beide Listen gleich mit denen der Engine.

• Einheiten für jede Spalte von sweep-nd (FUT-28): Ein Ergebnis von sweep-nd trägt jetzt key_units und metric_units, die Einheit jedes durchgefahrenen Schlüssels und jeder aufgezeichneten Metrik, gelesen aus der eigenen Einheitentabelle des durchgefahrenen Pakets. Eine Achse kann unit für einen Schlüssel angeben, den das Paket nicht ausgibt; eine angegebene Einheit, die der des Pakets widerspricht, wird abgelehnt, und eine Einheit, die keines von beiden angibt, ist null, nie geraten. points[].coords[] und points[].metrics[] sind beschrieben, sodass jede der 76 Arten jetzt vollständig vom Einheiten-Gate der Felder abgedeckt ist (Obergrenze nicht abgedeckter Arten 1 -> 0).

• NumPy-Arrays aus RunOutput (FUT-26): Das Python-Objekt RunOutput erhält array(path), columns(path) und series(), die numpy.ndarrays zurückgeben für eine numerische Liste, die numerischen Spalten einer Liste von Datensätzen oder jede Datensatzreihe im Dokument. Jedes Array ist gleich numpy.asarray derselben Werte aus data() (dtype und Bits). NumPy wird nur importiert, wenn eines davon aufgerufen wird, und gehört nicht zu den Laufzeitanforderungen. Typisiert in kshana.pyi und mit stubtest geprüft.

• Kampagnen-Optimierer (CAP-32): Der neue, optionale Abschnitt [optimize] der Art campaign sucht ein bis drei Szenarioschlüssel innerhalb genannter Grenzen nach dem besten Wert einer Metrik: minimieren, maximieren oder einen Zielwert treffen. Er sucht erschöpfend auf einem Raster oder mit einem deterministischen, begrenzten Nelder–Mead-Simplex. Jede Auswertung ist ein echter Lauf der genannten Art und steht im trace des Ergebnisses. Beispiel: scenarios/campaign-optimize-link-budget.toml. Die Zielwerte wurden vorab registriert (docs/design/evidence/cap32-optimize/):

  • die Rosenbrock-Funktion ist erfüllt (f* = 1.7e-20);
  • eine 1D-Zielwertlösung in geschlossener Form ist erfüllt (6e-15 relativ);
  • das Raster ist bitgleich mit einer unabhängigen Brute-Force-Suche;
  • der Simplex schneidet in 177 Läufen mindestens so gut ab wie ein Raster von 41 × 41.

  Der 1D-Zielwert von Runde 1 ist als NOT MET festgehalten, weil die vorab registrierte Box die Lösung ausschloss. MODELLED; Registerzeile „Bounded optimisation of one metric over campaign parameters“. Additiv: Kampagnen ohne den Abschnitt bleiben unverändert.

• Kalibrierungs-Ensembles (CAP-10): drei Prüfungen mit einzelnem Seed, erneut über 200 unabhängige Seeds gegen vorab registrierte Zielwerte gelaufen, in docs/CALIBRATION-ENSEMBLES.md (erzeugt von gen_calibration_ensembles; Werte je Seed in docs/data/calibration-ensembles.csv).

  • Das 95-%-Bootstrap-Intervall des Kampagnen-Monte-Carlo deckt den wahren Mittelwert bei 192 von 200 Ensembles ab, und seine Chi-Quadrat-Prüfung wird bei 196 bestanden.
  • Die Perzentil-Toleranz mit einzelnem Seed wird nur bei 183 von 200 bestanden: NOT MET, wie vorhergesagt. Sie ist ein Zielwert von etwa 2 Sigma, festgehalten und nicht gelockert.
  • Die ADEV-Kalibrierungen für weißes FM werden bei jedem Seed bestanden, mit ihrem schlechtesten Fehler weit innerhalb der Toleranz.

  MODELLED.

• Eingebaute Arten über den Trait Scenario (FUT-27, in Arbeit): der Trait BuiltinKind (api::BuiltinKind, mit einem Haken für die Stufe je Kennzahl und append_figure_tiers) und die ersten Arten, die darauf umgestellt wurden (inertial, spoof, passes, link-budget, jamming). Die Ausgabe bleibt unverändert: Ein Manifest des gesamten Katalogs mit der SHA-256 jeder Ausgabe ist vorher und nachher identisch (tests/scenario_output_manifest.rs).

• No-fetch-Prüfung des Playgrounds (RM-07): tests/playground_no_fetch.rs prüft drei Dinge:

  • Jedes Szenario der Studio-Bibliothek ist im Browser-Bundle enthalten;
  • das Bundle ist byteidentisch mit scenarios/;
  • jedes Browser-Szenario läuft aus einem leeren Arbeitsverzeichnis.

• Alt-PNT-Karten: reales Schwerefeld, Monte Carlo der Kartenfehler, SRTM in voller Auflösung (0,36, WP-10). Die Art gravity-map nimmt ein optionales [reference]: eine aus den mitgelieferten EGM2008-Koeffizienten synthetisierte Schwereanomalie (oder eine ICGEM-Datei .gfc über gfc_path, nur native Builds). Diese Synthese stimmt mit dem ICGEM Calculation Service auf etwa 1e-8 mGal über 794 Knoten in zwei Regionen überein, gegen vorab registrierte Zielwerte von 0,005 mGal RMS und 0,02 mGal Maximum (VALIDATED; Registerzeile „Gravity-anomaly synthesis from a spherical-harmonic model“). Das neue mitgelieferte Szenario gps-denied-gravity-nav-egm2008 lässt den 60-Minuten-Benchmark auf diesem realen Feld vom Grad 70 laufen. Vorab registriertes Ergebnis: angepasster Fehler 3106 m, daher ist der Zielwert < 500 m NOT MET, wie vorhergesagt (Grad 70 ist zu glatt), und die zehnfache Verringerung der Drift ist MET (MODELLED). Ein optionales [map_error_mc] lässt den Benchmark erneut über Kartenfehler laufen, die mit Seed erzeugt und gaußsch korreliert sind, und meldet die Verteilung des angepassten Fehlers (mitgeliefertes Szenario gravity-map-error-mc). Explorativ und nicht vorab registriert: Mit einem Kartenfehler von 2 mGal, korreliert über 0,2 Grad (die Größe, die der eigene Sigma-Haushalt des Matchers vorsieht), bleibt 1 von 20 Realisierungen innerhalb von 500 m (Median 2,9 km, p95 14,7 km), gegen 144 m mit einer perfekten Karte. Die Fixierung des synthetischen Benchmarks unter 500 m nimmt an, dass die Karte exakt ist. Ohne eine der beiden Optionen ist das Dokument byteidentisch mit früheren Veröffentlichungen. combined-altpnt nimmt ein optionales [magnetic_grid] (csv_path, column), das den magnetischen Kanal aus einer CSV im Format EMAG2v3 liest. EMAG2 wird nicht mitgeliefert, weil seine Bedingungen nicht eindeutig sind: tools/fetch_emag2_tile.py lädt es mit einer festgelegten SHA-256 und schneidet eine Box aus. Auf dem realen EMAG2-Raster wird kein Navigationsergebnis beansprucht. Gemeinsame Kartenschätzung (Terrain-SLAM, RM-18): altpnt::sequential::run_sequential_trn_on_map lässt den sequenziellen Geländenavigator über eine gespeicherte Karte fliegen, die von der Wahrheit abweicht, und vertraut ihr entweder oder schätzt mit einem Rao-Blackwell-Filter im Stil von FastSLAM eine Kartenkorrektur je Zelle. Vorab registriert gegen SITAN mit bekannter Karte bei einem korrelierten Kartenfehler von 15 m über 20 Seeds: ein mittlerer Gewinn von 1,5 %, besser bei 10 von 20, daher sind beide Verbesserungs-Zielwerte NOT MET (10 % und 12 von 20), ohne Schaden bei einer perfekten Karte (MET). Ein einzelner Durchgang ohne Wiederbesuche lässt die Karte nicht lernen (xval/terrain-slam-rbpf/, MODELLED). Dokumente von terrain-slam sind byteidentisch. Die SRTM-Tests mit echten Daten laufen jetzt in CI auf zwei eingecheckten Ausschnitten in voller Auflösung; alle vorab registrierten Zielwerte sind erfüllt, wobei der nächste Knoten bei 8 von 8 Punkten GDAL 3.8.4 entspricht (xval/srtm-ungate/).

• Interoperabilität, WP-08 (0,36; jeder Punkt vorab registriert und allein eingecheckt vor seinem Lauf der unabhängigen Referenz, jeder eine neue Registerzeile VALIDATED, außer dem Telemetriepunkt, der eine bestehende Zeile erweitert):

  • CCSDS Orbit Data Messages (src/odm.rs): OPM 3.0/2.0, OMM 3.0/2.0 und OCM 3,0 (Blöcke TRAJ, PHYS, COV, MAN, USER) in KVN und NDM/XML geschrieben und gelesen, und ein OMM in voller Genauigkeit aus einem SGP4-Elementsatz (OmmMessage::from_omm_file); die Ausgabe von OmmFile::to_omm_kvn bleibt unverändert. Gegen Orekit 13.1.8 in beide Richtungen: 27 von 30 Kshana-Nachrichten werden in Orekit geparst, und Kshana liest jede von Orekit geschriebene, Werte innerhalb von 1e-14 relativ und Epochen innerhalb von 1e-9 s; vier Befunde festgehalten (Orekit verlangt ELEMENT_SET_NO, lehnt COMMENT in benutzerdefinierten XML-Parametern ab, schreibt BTERM nicht ohne BSTAR und liest relative OCM-Epochen unter TDB in SI-Sekunden). Das META_START des alten OMM-Schreibers wird von Orekit abgelehnt (festgehalten). Zeile „CCSDS Orbit Data Messages (OPM, OMM, OCM)“.
  • CCSDS Attitude Data Messages (src/adm.rs, src/ndm_xml.rs): AEM 2.0/1.0 und APM 2,0 in KVN und XML gegen Orekit 13.1.8, jeder Zielwert erfüllt; der APM-Schreiber von Orekit lehnt ein Manöver ohne MAN_DELTA_MASS ab (festgelegt). Zeile „CCSDS Attitude Data Messages (AEM, APM)“.
  • SPICE-SPK-Export (src/spk_writer.rs): Schreiber und Leser für SPK-Typen 9 und 13 sowie OEM-nach-SPK-Export; gegen CSPICE N0067 sind die Kernel byteidentisch mit denen von SPICE und werten bitgleich aus. Zeile „SPICE SPK export (types 9 and 13)“.
  • SPICE-SPK-Typen 3 und 21 (src/spk_writer.rs): Segmente vom Typ 3 (Tschebyscheff) und vom Typ 21 (erweiterte Differenzzeilen), aus gegebenen Datensätzen geschrieben und so ausgewertet, wie SPICE es tut; gegen CSPICE N0067 sind die Kernel byteidentisch mit denen von SPICE, und jede Auswertung stimmt in beide Richtungen Bit für Bit überein. Zeile „SPICE SPK types 3 and 21 (Chebyshev, extended difference lines)“.
  • Erweiterungen für Space Packets (src/space_packet.rs): Sekundär-Header mit den Zeitcodes CUC/CDS, Paketfehlerkontrolle, Segmentierung und Stream-Prüfungen, gegen ccsdspy 2.0.1, spacepackets-rs 0.18.0, spacepackets-py 0.32.0 und CPython crc_hqx, null Abweichungen. Zeile „CCSDS Space Packet secondary header, packet error control and segmentation“.
  • Telemetrieschema 1,3 über echte Konsumenten: die Prometheus-Exposition und das OTLP/HTTP-JSON eines synthetischen Streams nach Schema 1.3, einschließlich der Geometriereihe und des Labels class, exakt gelesen von prometheus_client und dem OTLP-Proto, von promtool 3.5.0 check metrics ohne Lint-Problem akzeptiert und unverändert durch den OpenTelemetry Collector contrib 0.135.0 geleitet (datengesteuert: Werkzeuge mit festgelegter SHA-256 geladen, Ausgaben eingecheckt).

• Mars-Bahnbestimmung, Lauf 2 (0,36, WP-14, CAP-30): mars_od::fit_damped skaliert die Normalmatrix mit ihrer Diagonale und dämpft den Schritt (Levenberg-Marquardt), nachdem die registrierte Gauß-Newton-Anpassung an einer Matrix scheiterte, deren rohe Diagonale acht Größenordnungen umspannt. Gesondert registriert (xval/mro-od/PREREGISTRATION-RUN2.md, derselbe Bogen, dieselben Zielwerte und Bearbeitung). Auf den bewerteten MRO-Überflügen liegt die Bahn innerhalb von 0,36 km RMS (0,53 km Maximum) der MRO-Navigationsrekonstruktion, Zielwerte erfüllt. Der Doppler nach der Anpassung beträgt 48,6 mHz gegen den Zielwert von 30 mHz, nicht erfüllt (Befund festgelegt). Ein Nachtrag nur zur Bewertung, R2-A1, ist in docs/revisions offengelegt. Die Zeile bleibt MODELLED.

• Mars-Modell des Ramped-2-Wege-Dopplers und Bahnbestimmung (0,36, WP-14, Teil von CAP-30, Stufe 2): mars_od sagt den Ramped-2-Wege-Doppler im X-Band des DSN aus ODF-Rampentabellen vorher (Lichtlaufzeit, Shapiro, Troposphäre, Stationszeit, DSN-Stationen über die CIO-Kette und IERS-EOP) und passt einen Mars-Orbiter an (GMM-3, dritte Körper, SRP, Luftwiderstand). naif_kernel liest SPK-Typ 1 (gegen CSPICE geprüft) und gravity_sh::from_shadr liest PDS-SHADR-Felder. Vorab registriert gegen die MRO-Navigationsrekonstruktion an echten MRO-Überflügen (datengesteuert, scripts/fetch_mro_od.sh, monatliches CI): Der vorhergesagte Doppler stimmt mit den Beobachtungen auf 12,5 mHz überein (Zielwert 30 mHz, erfüllt); die registrierte Bahnanpassung scheiterte auf dem bewerteten Bogen und lieferte keine Bahn (Befund festgelegt). Die Zeile bleibt MODELLED.

• Leser für DSN Orbit Data Files (0,36, WP-14, Teil von CAP-30): odf::parse_odf liest ODFs nach TRK-2-18. An einer echten ODF des Mars Reconnaissance Orbiter (NASA PDS, mitgeliefert) stimmt der Leser mit der Datensatzzahl, den Gruppenpositionen, Stationen und Zeiten des PDS-Labels überein, und alle seine Datentypen sind bekannt. Die Tabelle am Dateiende im Label hat eine Zeile weniger als die Datei, eine Inkonsistenz des Labels, als Befund festgehalten. MODELLED. Die Bahnbestimmung mit diesen Daten ist noch nicht erfolgt.

• TWSTFT-Budget und Stabilität der Zeitübertragung: die Art time-transfer-budget (0,36, WP-14, FUT-19).

  • Zwei-Wege-Gleichung: twstft_budget löst sie nach T_A − T_B mit den Geräteverzögerungen der Stationen, der Ionosphären-Asymmetrie im Ku-Band zwischen Auf- und Abwärtsstrecke, der Differenz der Transponderverzögerung und den Sagnac-Termen und gewinnt das Vorwärtsmodell auf 1e-15 s zurück.
  • Unsicherheitsbudget: quadratisch kombiniert, mit dem TDEV der Verbindung als Typ-A-Term.
  • Verbindungsrauschen: Die Zwei-Wege-Reihe erhält einen Flicker-Phasenrauschboden, eine tageszeitliche Nicht-Reziprozität und einen konstanten Reziprozitätsrest. Das Paket timetransfer mit weißem Jitter bleibt unverändert.
  • Reale Reihen: die Stabilität gelieferter Reihen von BIPM Circular T, MJD,ns-CSV oder IGS-Stationsuhren.

  MODELLED. Neues mitgeliefertes Szenario time-transfer-budget. Die PPP-Zeitlösung ist gesondert gegen die IGS-Stationsuhr VALIDATED, im GNSS-Zweig mit Echtdaten.

• Eintrittsheizung, EO-Radiometrie und Aufstiegsverluste (0,36, WP-14, CAP-28): drei neue Arten.

  • entry-heating: ein Eintritt eines Massenpunkts mit 3 Freiheitsgraden über einer rotierenden Erde oder einem rotierenden Mars, mit Staupunktheizung nach Sutton-Graves.
  • eo-radiometry: SNR des Imagers, MTF bei Nyquist, relative Kantenantwort und GIQE-4-NIIRS.
  • ascent-losses: ein aus mehreren Stufen bestehender Aufstieg mit Schwerkraftkurve, mit Verlusten durch Gravitation, Luftwiderstand, Lenkung und Gegendruck, geprüft über die exakte Identität ideales dv minus Verluste.

  Die maximale Verzögerung beim Eintritt wurde unter einem vorab registrierten Zielwert gegen den veröffentlichten Stardust-Nominalwert geprüft: 35,44 g gegen 33,4 g (+6,1 %, Zielwert 10 %). Diese Zeile ist VALIDATED. Heizung, Radiometrie und Aufstieg sind MODELLED. Ebenfalls neu: reentry::us76_pressure, mitgelieferte Szenarien entry-heating-stardust, eo-radiometry und ascent-losses sowie docs/ENTRY-EO-ASCENT.md.

• Lageregelung mit Reaktionsrädern: die Art aocs (0,36, WP-14, CAP-21). Ein Schwenk mit inertialer Ausrichtung eines starren Hubs mit drei oder mehr ausgewuchteten Reaktionsrädern unter MRP-Rückführung, mit Raddrehmomenten kleinster Norm, die auf das Limit jedes Motors begrenzt sind (aocs). Sie kann die Schleife auch über einen multiplikativen EKF aus einem simulierten Gyro und Sternsensor schließen (aocs_mekf). Die Schleife mit wahrem Zustand wurde mit Basilisk 2.9.1 an drei Fällen verglichen, die vorab registriert wurden, bevor der Code existierte (drei orthogonale Räder, eine Vierrad-Pyramide, ein Sättigungsfall). Jede MRP-Komponente, Körperrate, Raddrehzahl und jedes Motordrehmoment stimmte an jedem Abtastwert überein, schlechtester Wert 2.4e-14 bei Sigma und 2.9e-11 rad/s bei der Raddrehzahl. Diese Zeile ist VALIDATED; der MEKF ist MODELLED (NEES-Konsistenz). Neue mitgelieferte Szenarien aocs-slew und aocs-slew-mekf sowie docs/AOCS.md.

• Planung von Bodenkontakten und DVB-S2-ACM (0,36, WP-14, CAP-22/23): zwei neue Szenarioarten. acm-link liefert für einen Satelliten über einer Station das Es/N0 jedes Überflugs und das entlang davon gewählte DVB-S2-MODCOD (Schwellen aus ETSI EN 302 307-1 Tabelle 13 plus eine Reserve). Es liefert auch das Datenvolumen, das ACM gegenüber der Basislinie mit konstanter Kodierung bewegt. contact-schedule tut dasselbe für mehrere Satelliten über mehreren Stationen und baut einen konfliktfreien Kontaktplan (Antennenumlauf, eine Station je Satellit, prioritätsgewichtete Auslieferung, bei jedem Rückstand gedeckelt). Es meldet einen Greedy-Plan nach Grenzwert, eine Basislinie nach Eingangsreihenfolge und bei kleinen Mengen das exakte Optimum, mit der Optimalitätslücke des Greedy-Plans. Zugangsfenster stammen aus dem VALIDATED Prädiktor für scheinbare Überflüge. Neue mitgelieferte Szenarien acm-link und contact-schedule (illustrative Eingaben) sowie docs/CONTACT-SCHEDULING.md. MODELLED (zwei neue Registerzeilen).

• Starlink-Doppler-Positionierung gegen ein veröffentlichtes Experiment (0,36, WP-14, Teil von CAP-11, MODELLED). Dies ist ein vorab registrierter Stellvertreter-Vergleich des Doppler-Modus von leo-pvt mit dem Preset starlink-sop gegen die Perzentile des Datensatzes 3 aus „Unveiling Starlink for PNT“ (NAVIGATION 72(1), 2025, doi:10.33012/navi.685). Das Modell verwendete 3 Satelliten (eine Maske von 47 Grad, nach einer festen Regel gewählt), keine Höhenstützung und ein Doppler-Sigma von 30 Hz, über 200 Seeds. Sein 90.-Perzentil des 3D-Fehlers beträgt 92,2 m bei 20 s und 870 m bei 8 s, gegen die veröffentlichten 2 m und 10 m, daher sind beide Zielwerte vom Faktor zwei NOT MET. Das Modell ist pessimistisch, nicht optimistisch wie vorhergesagt: drei feste Satelliten geben weit weniger geometrische Vielfalt als die 63 Satelliten des Experiments über 10 Minuten mit Kanalwechsel alle 15 s. Beide Fehlschläge sind festgeschrieben (tests/starlink_doppler_published_proxy.rs).

• Optimierer für impulsive Transfers auf DE440 (0,36, WP-14, CAP-20c/d): maneuver::optimise_transfer_kernel findet die Abflug- und Ankunftsdaten eines ballistischen Zwei-Impuls-Transfers mit einem Umlauf, die das Abflug-C3 oder das Ankunfts-V-unendlich innerhalb von Typ I oder Typ II minimieren. Er durchsucht ein Raster von 2 Tagen und verfeinert dann mit Nelder-Mead in 2D, auf heliozentrischen Zuständen aus dem DE440-Kernel; er baut auf porkchop_kernel auf. Der Vergleich wurde vorab registriert (bf0439e8) gegen einen unabhängigen Optimierer aus SPICE + pykep 3.0.1 + SciPy 1.18.1 an der Gelegenheit Erde-Mars von 2026: alle vier Optimierungen stimmen auf 8.7e-13 relativ überein, mit Daten innerhalb von 1e-5 Tag (VALIDATED, neue Registerzeile). Als sekundäre veröffentlichte Referenz wird NASA/TM-2010-216764 (das Handbuch Erde-Mars 2026-2045) beim minimalen C3 des Typs II (9,182 gegen 9,144) und beim minimalen Ankunfts-V-unendlich des Typs II (2,564 gegen 2,565) getroffen. Sein minimales C3 des Typs I wird nicht getroffen: 10,535 gegen 11,11 (-5.18 %), wo die unabhängige Referenz der Bibliothek mit Kshana übereinstimmt. Dieser Fehlschlag ist festgehalten und festgeschrieben.

• Studie zur lunaren Referenzstation (0,36, angeregt durch veröffentlichtes Material zu einer geplanten Referenzstation am lunaren Südpol; Quellen in docs/LUNAR-REFERENCE-STATION.md): die Art lunar-station-coverage, ein Monte-Carlo-Durchlauf des lunaren differenziellen PNT-Modells über ein südpolares Nutzerraster und einen Tag von Epochen, der je Punkt und über die Region den Perzentilfehler mit und ohne Korrektur, die Verfügbarkeit mit Gründen, die Abdeckung gegen eine genannte Schwelle, Schutzniveaus, den Abdeckungsradius je Azimut und das Budget der Korrekturstrecke liefert. Sie reduziert sich bei einem Punkt, einer Epoche und einem Versuch exakt auf lunar-differential-pnt; ihre Arithmetik wurde unter einem vorab registrierten Zielwert mit numpy neu berechnet (Positionen und Perzentile erfüllt; die Stationskorrekturen verfehlten ihren durch Rundung in doppelter Genauigkeit, festgehalten). MODELLED; Registerzeile „Lunar reference-station coverage and accuracy map“. Nicht mit einer Behörde verbunden oder von ihr unterstützt; keine Aussage über die Leistung irgendeines realen Systems.

• Vorab registrierte Vorhersage: Abdeckung der lunaren Referenzstation (keine Validierung; MODELLED). docs/predictions/lunar-reference-station.md friert bei Commit c05dac1d die Ergebnisse von lunar-station-coverage unter den öffentlich genannten Annahmen ein, mit SHA-256-Hashes der Eingaben und Ergebnisse und einem jetzt festgelegten Bewertungsprotokoll (Faktor 2 für Genauigkeiten und Schutzniveaus, 10 Prozentpunkte für Verfügbarkeit und Abdeckung; eine geänderte Annahme erhält eine neue datierte Vorhersage, nie eine Bearbeitung; ein Fehlschlag wird ebenso deutlich veröffentlicht wie ein Treffer). Jede Zahl wird vom unveröffentlichten Elementsatz der Konstellation mit vier Satelliten bestimmt, der ILLUSTRATIVE ist und das auch sagt. tests/prediction_frozen.rs schützt sie; docs/VALIDATION.md erhält einen Abschnitt „Pre-registered predictions“. Keine Registerzeile.

• Erweiterungen der lunaren Referenzstation (0,36; die Einschränkungen 2 und 3 der Stationsstudie und der Lösungsstil der Quellen), jede optional bei lunar-station-coverage und standardmäßig nicht vorhanden, sodass jedes bestehende Dokument, auch die eingefrorene Vorhersage, unverändert ist: [receiver] (Mehrwegeausbreitung a + b exp(-el / el0) beim Nutzer und bei der Station, bei der Station wahlweise Gauß-Markov über Epochen, DLL-Coderauschen aus C/N0, Bias zwischen Kanälen; Werte auf dem Mond ILLUSTRATIVE); orbit_err_growth_m_per_s (lineares Wachstum des Broadcast-Bahnfehlers über die Latenz der Korrektur, ILLUSTRATIVE); [solution] (Höhenbedingung, ein Minimum von drei Satelliten damit, ein Fenster für statische Nutzer über Epochen). Zwei Nachträge zum Vergleich mit den veröffentlichten Behauptungen, jeder allein vor seinem Lauf vorab registriert, stehen neben dem unveränderten aufgezeichneten Lauf: K5 mit Wachstum scheitert bei jeder Rate; mit dem Lösungsstil der Quellen scheitern K1 bis K5 und K6 besteht (1 von 6), wobei der korrigierte 3D-Fehler im p95 von R300 von 280,6 m auf 2,11 m fällt. MODELLED; drei Registerzeilen.

• Maske des lunaren Geländehorizonts (0,36; die erste Einschränkung der Studie zur lunaren Referenzstation): ein optionaler Abschnitt [terrain] bei lunar-station-coverage (die Station und jeder Nutzerpunkt) und moonlight-service-volume (jeder Rasterpunkt) gibt jedem Standort einen azimutabhängigen Horizont im Format der Skyline-Tabelle von 0,36, aus einem genannten Profil, das mit seiner Quelle gekennzeichnet ist (station_horizon, user_horizon), und/oder aus einem Ray-Marching über ein polares DEM (dem_path) entlang von Großkreisen der Mondkugel mit exakter Krümmung. Liefert einen Ausschnitt von 0,98 MB des gemeinfreien südpolaren LRO-LOLA-DEM LDEM_75S_240M mit, 5 x 5 blockgemittelt neu abgetastet auf 1200 m (data/lunar-dem/, mit seiner NOTICE, SHA-256 und scripts/make_lola_south_polar_crop.py), und das nur im Repository liegende Szenario scenarios/lunar-station-coverage-terrain.toml. Geprüft gegen Horizonte in geschlossener Form (bloße Kugel, Krater in einem Plateau, gerasterter Kegel); MODELLED, Registerzeile „Lunar terrain horizon masks from a stated profile or a polar DEM“. Ohne den Abschnitt ist jedes Dokument, den Einheitenblock eingeschlossen, byteidentisch.

• Geometriebewusstes Vertrauen (Entwurfsnotiz zur Geometrie von 0,36, Abschnitt 4). Jede Epoche von receiver-trust, statisch oder Schiff, Batch oder live, trägt ihre Satellitengeometrie: good, degraded (Gründe few-satellites, high-pdop, high-hdop und informativ sky-blocked) oder unknown, wo das Protokoll keine Satellitengeometrie angibt, mit HDOP, PDOP, VDOP und den verwendeten Satelliten. Sie wird aus den Elevationen und Azimuten abgeleitet, die der Empfänger meldet (NMEA GSV, UBX NAV-SAT), über den bestehenden Kernel orbit::dop, oder aus NMEA GSA übernommen. Jede Epoche trägt außerdem ein Label, good, fair oder poor, stets gemeldet und nie bewertet, und eine Notiz mit HDOP, PDOP, VDOP, Satellitenzahl und Signalverlust in Worten. Der Wert eines Schiffs erhält einen Monitor geometry, der nichts abzieht, solange die Geometrie nicht schlecht ist (HDOP über 4, PDOP über 6 oder weniger als 5 verwendete Satelliten), und dann bis zu einer Obergrenze von 15 Punkten ansteigt; die Geometrie allein erreicht höchstens das Band „beeinträchtigt“, nie das nicht vertrauenswürdige (kein Alarm). Jeder Abzug erhält eine Klasse, geometry, environment oder inconsistency, sodass ein schlechter Himmel nicht als Angriff gelesen wird. loss-of-lock ist geometry, wenn die verlorenen Satelliten bei ihrer letzten Meldung alle unter 15 Grad lagen; ein Abzug wegen schlechter Geometrie ist inconsistency, wenn der vom Empfänger genannte HDOP um mehr als max(1,0, 25 % des abgeleiteten HDOP) von seinem genannten Himmel abweicht, sodass ein gefälschter schlechter Himmel das Label nicht erkaufen kann. Eine neue Tabelle [geometry] nennt jede Schwelle mit ihrer Herkunft (HDOP 4, PDOP 6, mindestens 5 verwendet, sigma_UERE 1,5 m, eine HDOP-Toleranz von max(1,0, 25 % des abgeleiteten HDOP), wobei 25 % eine repräsentative Wahl für Empfänger mit Uhren je Konstellation oder Teilmengenlösungen ist, 15 Grad; die Zahlen aus IEC 61108-1 und GPS SPS wie zitiert, gegen den Text der Normen zu prüfen). Ein vollständiger Signalverlust wird nicht als Himmel etikettiert: Wenn sichtbare Satelliten nicht verfolgt werden und der DOP der sichtbaren Satelliten gut ist (und die nicht verfolgten nicht auf eine Hälfte des Horizonts beschränkt sind), trägt die Epoche signal_loss, und der Geometrieabzug ist environment. Ein genannter HDOP oder PDOP von 99 oder mehr, GGA-Qualität 0 und GSA-Modus 1 werden als keine Lösung gelesen, nicht als DOP. Die Obergrenze (cap_points 15), das Ende der Rampe (full_ratio 1,5) und die Untergrenze (floor, Standard der degraded_min des Werts) stehen in [geometry], ebenso die guten Stufen des Labels (HDOP 2, PDOP 3, 6 Satelliten, repräsentativ); die geltende Obergrenze ist min(cap_points, 100 - floor), sodass eine Tabelle [score], die degraded_min anhebt (auch eine von 0,35), die Obergrenze senkt, statt abgelehnt zu werden, und eine Untergrenze unter degraded_min abgelehnt wird. MODELLED; Beratende Software, keine typzugelassene Navigationsausrüstung (IEC 61108, IEC 61162): Der Betreiber bleibt für die Navigation des Schiffes verantwortlich.

• Die Geometrie erreicht jede Oberfläche: das Ergebnis-JSON (epochs[].geometry, class bei jedem Abzug, geometry_model, geometry_summary), die Live-JSON-Zeilen (Schema 1,3), die Python- und WebAssembly-Funktionen receiver_trust, assess_vessel_log und receiver_trust_replay, die MCP-Werkzeuge assess_*, Nachweispakete (epochs.json, config.json, eine Geometriespur auf der Zusammenfassungsseite) und trust-telemetry (Prometheus kshana_trust_geometry* und ein Label class bei kshana_trust_reason_active, OTLP kshana.geometry.*, benutzerdefinierte CEF-Felder cs6 (Geometriestatus und Klassen), cfp3 (HDOP) und cfp4 (PDOP), gegen beide CEF-Parser der unabhängigen Referenz geprüft, und LEEF geoStatus, geoHdop, geoClass). Das Geometrie-Label wird ebenfalls exportiert, nach jeder früheren Reihe und jedem früheren Feld angehängt und nur für Eingaben, die es tragen: Prometheus kshana_trust_geometry_label{label} und kshana_trust_geometry_vdop, OTLP kshana.geometry.label und kshana.geometry.vdop, LEEF geoLabel, geoPdop, geoVdop, geoUsed, und CEF ein drittes Feld cs6 (das Label) und cn1 (verwendete Satelliten); der VDOP steht nicht in CEF (die benutzerdefinierten Gleitkommafelder sind vergeben). Beide CEF-Parser der unabhängigen Referenz lesen die Label-Fälle wie geschrieben zurück (Nachtrag 5: 176 Zeilen, 172 von pycef geparst, 176 von Logstash). Ein genannter HDOP, den der genannte Himmel nicht erklärt, wird bei jeder Epoche markiert und gezählt (geometry_summary.hdop_mismatch, eine Zeile auf der Zusammenfassungsseite des Nachweises), und nur bewertet, wenn die Geometrie schlecht ist. Der Signalverlust wird für sich exportiert, da der Geometriestatus degraded bleibt, solange er besteht: Prometheus kshana_trust_geometry_signal_loss, OTLP kshana.geometry.signal_loss, LEEF geoSignalLoss=1; in CEF erscheint er als Klasse environment in cs6.

• orbit::dop_cofactor: der Kovarianzfaktor (HᵀH)⁻¹ hinter orbit::dop, mit derselben Arithmetik daraus herausgelöst.

• Registerzeile „Position error from geometry: RMS error = sigma_UERE x DOP“ (MODELLED, interne Konsistenz): ein Monte-Carlo-Lauf mit Seed des Fixes der Engine nach kleinsten Quadraten auf den 8 mit gnss_lib_py abgeglichenen DOP-Geometrien gegen den Kovarianzfaktor des validierten DOP-Kernels, mit Toleranzen, die vor dem ersten Lauf vorab registriert wurden, und zwei Negativkontrollen, die wie verlangt scheitern; daneben eine frühere Prüfung an vier von Hand gewählten Himmeln mit Chi-Quadrat-Konfidenzintervallen, berichtet als vor der Vorregistrierung gelaufen.

• Azimutabhängige Skyline-Masken (src/skyline.rs, docs/SKYLINE.md, Punkt 1 der Entwurfsnotiz): ein von Azimut abhängiger Elevationsschnitt, das punktweise Maximum von Tabellen (jede für sich interpoliert, bei 360° umbrochen), eine Straßenschlucht in geschlossener Form (mit optionalen offenen Enden), scharfkantige Sektoren und ein Geländeprofil mit der Krümmung der Erde; der wirksame Schnitt ist max(mask_deg, skyline). Vier REPRESENTATIVE Presets mit genannter Herkunft (city-street, harbour-approach, fjord, container-terminal), Feld für Feld überschreibbar. Ein optionaler Abschnitt [skyline] in den Trainingsdateien gnss-sim, jamming, leo-pvt (jeder Modus, der polare Durchlauf eingeschlossen), leo-pass und nmea-scenario sowie in orbit und integrity über einen neuen Bodenstandort-Nutzer, user_site = { lat_deg, lon_deg, height_m } (geodätische Blickwinkel auf der rotierenden Erde, mit dem geodätischen Oben für die horizontale und vertikale Aufteilung bei ARAIM; jeder Abtastwert ist ein absoluter Zeitpunkt, epoch + t, auf den Elementsätze, Broadcast-Ephemeriden und SP3-Dateien von ihren eigenen Epochen aus fortgeschrieben werden, datiert von der neuesten Satellitenepoche, wenn keine epoch angegeben ist; ein umlaufender user lehnt eine Skyline ab). Ergebnisse erhalten skyline { source, open_fraction, provenance } und je Abtastwert masked_by_skyline. Ohne den Abschnitt ist jedes Szenario byteidentisch mit 0.35.0, geprüft gegen Digests vom Release-Commit. Sechs mitgelieferte Beispiele: orbit-urban-canyon-skyline, integrity-harbour-approach, gnss-sim-container-terminal-skyline, jamming-harbour-approach-skyline, leo-pvt-fjord-skyline und die Kampagne leo-vertical-autonomous-vehicle-skyline (die Schlucht des autonomen Fahrzeugs als flacher Schnitt und als Straße; die bestehende Kampagne bleibt unverändert). MODELLED.

• Funktionen zur Himmelsgeometrie (src/geometry.rs, Punkt 2 der Entwurfsnotiz): sky_geometry (sichtbare und maskierte Satelliten von einem Standort, einer Zeit und Konstellations-Presets, Zweizeilen-Elementsätzen (tle, höchstens 4 MiB, vom SGP4 der Engine auf eine UTC-epoch propagiert) oder gegebenen Satelliten; sky_source und sky_statement sagen, ob der Himmel repräsentativ ist oder der Himmel, den die Elementsätze zu dieser Epoche geben, keine Messung; tle_skipped listet jede unbenutzte Zeile mit ihrem Grund; Eingabegrenzen von 2000 Satelliten über dem Horizont, vor dem Bau einer Systemtabelle geprüft, und 16 Empfängeruhren; die fünf DOPs; der ENU-Kofaktor und die Kovarianz mit einer Uhr je System oder einer gemeinsamen; die horizontale Fehlerellipse bei einem Sigma und bei einer genannten Konfidenz), sky_monte_carlo (Fehler nach kleinsten Quadraten mit Seed, höchstens 5000), skyline_presets, skyline_profile und skyplot_svg. orbit::dop_cov legt die Kovarianz hinter orbit::dop offen, das jetzt ihre Reduktion ist (die validierten Skalare bleiben unverändert). Oberflächen: kshana sky und kshana skyline, Python- und WASM-Funktionen mit denselben Namen und das MCP-Werkzeug sky_geometry (40 Werkzeuge) sowie das Notebook notebooks/geometry.ipynb (mit seinem Spiegel .md; ausgeführt von tests/python/test_notebooks.py). Jedes Ergebnis trägt das Label MODELLED, die Aussage zum Fehlermodell und den Hinweis.

• Register: fünf Zeilen zu Skyline und Himmelsgeometrie. VALIDATED, jede in einem Vergleich, der vorab registriert wurde, bevor ihre unabhängige Referenz lief: Azimutabhängige Skyline-Maske: sichtbare Menge, Azimut und Elevation sowie DOP unter der Maske gegen Orekit 12,2 (TopocentricFrame, ElevationMask) und gnss_lib_py 1.0.4 (get_dop), schlechteste Unterschiede bei Blickwinkel und Maske 1.1e-12° gegen 1e-9°, identische sichtbare Mengen, DOP 3.3e-13 relativ (xval/orekit-skyline/); Horizontale Fehlerellipse und Kofaktor je System aus der Geometrie-Kovarianz gegen numpy linalg.inv und linalg.eigh (Standard P2), 270 Fälle, Achsen 5.1e-13 relativ (xval/numpy-ellipse/). MODELLED: die Reduktionen für Schlucht, Sektor und Gelände; die Presets; die Zusammensetzung der Himmelsgeometrie (Preset-Himmel, Monte-Carlo-Wolke).

• Mit den Zeilen zu Geometrie-Vertrauen, Skyline und lunarer Referenzstation hat das Register 274 Zeilen: 134 validiert, 136 modelliert, 4 Partner.

• Lunare Referenzstation: Zeitlabor der Station (MODELLED). Ein optionaler Block [time_lab] bei lunar-time-budget (src/lunar_time_lab.rs). Er modelliert eine Stationsuhr (standardmäßig die Klasse miniRAFS, jede benannte Klasse oder eine an genannte Stabilitätspunkte angepasste Gerätekarte), die auf LTC gesteuert wird und dann frei läuft oder alle N Sekunden neu gesteuert wird. Er gibt die Zeitfehlerkurve x(t), die Zeit bis 1, 10 und 100 ns (Bisektion neben der geschlossenen Form) und den dominanten Term je Horizont aus, alles mit Einheiten. Der Steuerrest ist ILLUSTRATIVE. Die LTC-Rate wird nicht neu abgeleitet und behält ihre eigene Zeile VALIDATED. Das Ziel im Nanosekundenbereich aus dem öffentlichen Material des ICG WG-B zu lunarem PNT (Juni 2024) wird als Aussage der Quelle zitiert, nicht als Anspruch. Die Uhrenordnung optisch < PHM < RAFS < miniRAFS gilt von 1 s bis 7e5 s, und der Test legt die Kreuzung der Kurven von PHM und RAFS nahe 7.5e5 s fest. Diese Kreuzung ist eine Eigenschaft der Uhrenmodelle mit einem einzigen Rauschtyp (reines Flicker-FM gegen reines White-FM), kein physikalisches Ergebnis. Ohne den Block sind der Bericht, seine Tabelle und seine Zusammenfassung unverändert. Beispiel: scenarios/lunar-station-time-lab.toml. Fügt eine Registerzeile hinzu, gekennzeichnet MODELLED.

• Lunare Referenzstation: Geodäsie der Station (MODELLED). Optionale Eingaben extra_reflectors und extra_beacons bei lunar-llr-datum fügen einen Block station_geodesy hinzu. Die Datums-Information mit fünf Arrays aus dem archivierten Ausschnitt der Laserentfernungsmessung wird mit dem kombiniert, was ein hinzugefügter Retroreflektor und eine hinzugefügte VLBI-Bake an genannten Standorten beitragen würden. Die Entfernung zum Reflektor wird zu den archivierten Epochen, die er sehen kann, mit ihren archivierten Gewichten gemessen. Die Bake verwendet das Netz und den Zeitplan von lunar-frame-campaign, mit festgehaltenen Stationen. Der Block gibt jedes Helmert-1-Sigma davor und danach sowie ihr Verhältnis an. Das sind Cramér-Rao-Schranken für einen reduzierten Parametersatz, bei einem ILLUSTRATIVE Zeitplan und Standort. Fehlende oder leere Eingaben lassen den Bericht byteidentisch. Beispiele: scenarios/lunar-station-geodesy-baseline.toml und -with-station.toml. Fügt eine Registerzeile hinzu, gekennzeichnet MODELLED.

• Lunare Referenzstation: Vergleich mit veröffentlichten Behauptungen (MODELLED). Jede numerische Behauptung in fünf öffentlichen Quellen ist mit ihrem genauen Wortlaut, ihrer Seite und ihren genannten Annahmen aufgeführt und als vergleichbar, teilweise vergleichbar oder nicht vergleichbar eingestuft (tests/fixtures/lunar_station_published/CLAIMS.md; Quellen mit URL, Abrufdatum, SHA-256 und Lizenz in tests/fixtures/lunar_station/SOURCES.md). Die teilweise vergleichbaren Behauptungen wurden unter sechs einseitigen Zielwerten bewertet, die vor dem Lauf vorab registriert wurden (PREREGISTRATION.md, Revision 2, 05bf9a19): 1 von 6 Behauptungen innerhalb des vorab registrierten Zielwerts (vorab registriert 05bf9a19). Die Abdeckung beträgt 0,00 gegen >= 0,95 auf beiden südpolaren Kreisen, und das korrigierte p95 beträgt 280,6 m gegen <= 1,5 m. Die Ursache sind die Bahnelemente der Satelliten, die keine Quelle veröffentlicht: Mit den ILLUSTRATIVE Elementen im Repository sind vier Satelliten in 8 % der Epochen gemeinsam in Sicht, bei nahezu singulärer Geometrie. Der Lauf reproduziert die Behauptungen mit diesen Elementen nicht und ist kein Beleg dafür, dass die Behauptungen falsch sind. Festgelegt in tests/lunar_station_published_oracle.rs. Eine Registerzeile, gekennzeichnet MODELLED mit dem Befund.

• Lunare Referenzstation: Datenbereitschaft der Uhrendatei. realdata::clk::rinex_clock_series nennt jetzt das Zeitsystem seiner Epochen. Es ist der Wert von TIME SYSTEM ID oder, wenn dieser nicht erklärt ist, der Standard des Satellitensystems des Headers. Das Ergebnis sagt auch, ob das System erklärt wurde. Die Funktion lehnt ein unbekanntes Zeitsystem (zum Beispiel eine lunare Zeitskala), eine Datei mit nicht erklärtem gemischtem System und Dateien, die sich widersprechen, ab, statt sie als GPS-Zeit zu lesen. Sie liefert eine synthetische Fixture einer Stationsuhr mit. Es ist kein Format für Korrekturdateien definiert, weil es kein öffentliches gibt.

Geändert#

• Die Modul-Dokumentation von fusion::ukf, fusion::tightly_coupled und fusion::gnss_ins_ekf nennt den UKF-Navigator mit 17 Zuständen, die enge Kopplung mit vollem INS und den ausdrücklichen Uhrenzustand nicht mehr als künftige Arbeit; sie verweisen auf hybrid_ukf, tightly_coupled17 und carrier_tc.

• RINEX 4 wird nicht mehr abgelehnt (0,36, WP-07): Eine RINEX-4-Navigationsdatei wurde früher absichtlich abgewiesen; sie wird jetzt gelesen (siehe Hinzugefügt). Bei Beobachtungsdateien der Version 4 und später werden Header-Labels nur in den Spalten 61-80 abgeglichen, sodass die neuen Freitext-Datensätze nicht als Labels durchgehen können.

• ionex::parse_ionex liest echte IONEX-Dateien (0,36, WP-07): Ein vollständiger Datensatz mit 16 Werten füllt die Spalten 61-80, die der Leser für ein Label hielt, sodass er bei jeder echten IONEX-Datei None zurückgab. Jetzt liest er einen Datensatz, dessen Label-Feld numerisch ist, als Werte. Keine ausgelieferte Ausgabe hat ihn verwendet.

• Empfangsleistungen von Galileo E1 und E5a nach OS SIS ICD Issue 2,1 (Revision, 2026-10-14). Die Spektrumbänder galileo-e1 und galileo-e5a und die GNSS-Opfer mit LEO-Signal, die ihre Leistung von dort beziehen, verwenden jetzt die minimalen Empfangsleistungen aus Tabelle 12 des Galileo OS SIS ICD Issue 2,1: −157,25 dBW (war −157,0) und −155,25 dBW (war −155,0).

  • Neun Szenarioergebnisse verschieben sich: die Spektrumbeispiele, die Spektrumkampagne, drei LEO-Resilienz-Vertikalen und drei LEO-Signalentwürfe. Die effektive C/N0 verschiebt sich um −0,25 dB und J/S um +0,25 dB bei diesen Bändern.
  • Jeder verschobene Wert (1766, alt → neu) ist in docs/revisions/CAP12-galileo-icd21-power-changes.md und seiner CSV aufgeführt, mit den verschobenen Dokumentationstabellen. Keine Registerzeile ändert ihren Status.
  • Zweiter Teil, am selben Tag: die LEO-Signal-Opfer galileo-e5b (−155,0 → −155,25 dBW, Tabelle 12 E5b) und galileo-e5-altboc (−152,0 → −152,24 dBW). Das ICD hat keine Zeile für den vollständigen Bereich E5, daher ist der AltBOC-Wert die Leistungssumme der Gesamtwerte E5a und E5b aus Tabelle 12, so gebildet wie der alte Wert. Drei Ergebnisse von LEO-Signalentwürfen verschieben sich (64 Werte: diese Empfangsleistungen und die Verschlechterung der C/N0 durch LEO gegenüber GNSS bei den beiden Opfern), aufgeführt in derselben Revision (§5) und CSV. Nichts sonst verschiebt sich.

• Korrektur der atmosphärischen S2-Gezeit (tides::atmospheric_tide). Die S2-Luftdruckharmonischen von Ray (2001) sind Koeffizienten der nicht normierten P_nm mit Kosinus-Phasenverzögerungen; sie wurden als vollständig normiert verwendet, mit der Verzögerung als Sinus-Vorlauf nach IERS. Sie gehen jetzt geteilt durch N_nm mit ε = 90° − ψ ein; das neue tides::s2_air_waves reproduziert das Modell A2 von GFZ STR06/01 Tabelle 5 für alle 21 Wellen (schlechtester Wert 0,0005 cm, 0,05°; VALIDATED). Nur Ausgaben mit aktivierter Gezeit verschieben sich: die CI-Anpassung von Galileo 0,132 → 0,133 m, die Komponenten von Swarm-A um 1–2 mm (vorab registriert in xval/s2-air-tide-fix/).

• Nur Dokumentation: propagator::solve_kepler_checked, orbit::solve_kepler und ephem::solve_kepler sind als Legacy-Löser dokumentiert, numerisch unverändert, mit Verweis auf kepler::solve_kepler_markley.

• Stand von D9, Runde 3 (utck_bound). BIPM Circular T 465 erschien am 2026-10-12. Die vorab registrierte prospektive Bewertung ist weiterhin nicht gelaufen: Ausgabe 465 enthält etwa 285 Testwerte, und die Abbruchregel braucht 1000, also etwa die Ausgaben 465–468. Der Lauf braucht außerdem die archivierten Dateien je Labor vom 2026-09-30, weil das BIPM seitdem 87 der 113 neu geschrieben hat. Die Registerzeile und der Kopf des Tests sagen das; der Test, seine Zielwerte und seine Aufteilung bleiben unverändert.

• Durchgang zur Wahrheit der Dokumentation (0,36). Roadmap, Fähigkeitszeilen, Statuszeilen der Entwurfsdokumente und Modulkommentare wurden mit dem Code in Einklang gebracht; keine Ausgabe ändert sich. Punkte, die schon gebaut, aber noch als offen aufgeführt waren, sind jetzt als erledigt markiert: die Prüfungen der ITU-T-Masken, das Holdover-Szenario von 24 h und die Aufnahme von Uhrenprotokollen (Telecom-Timing), die Quickstarts der ersten Minute, Lense–Thirring und die Kreuzprüfung des Orekit-Propagators, die ITRF-präzise GCRS-Kette, Golden- und plattformübergreifende Hashes, Provenienz, ARAIM bei mehreren Fehlern (ADD v4.2), FDE bei einem Satelliten, die CRPA-Bibliothek, die Grenze der CAI-Streifenmehrdeutigkeit, die Dimensionierung von Streets of Coverage und die 3D-Bahnansicht, Lagedynamik starrer Körper, der OMM-Schreiber und der NAIF-Kernel-Leser, die lunare Libration nach DE440, der Satz zur Bedeutung des Laufs im Playground, PositioningFom, der eng gekoppelte Navigator mit 17 Zuständen und die Art gravity-map. Die Zeilen sagen auch genau, was noch offen ist (zum Beispiel das zweiteilige JD in orbit::Propagator, der Leser src/ionex.rs gegen ein reales Produkt und der Ausschluss mehrerer Satelliten in raim). Die fehlende docs/design/evidence/cn0-m2m4/RESULTS.md ist aus einem frischen Lauf ihrer Tests geschrieben (M1–M4 bestehen), und der partnerseitige Entwurf zur IQ-Validierung hat aktuelle Registerzahlen.

• Die Galileo-E1-Speichercodes werden nicht mehr mitgeliefert. data/galileo-os-sis-icd/C7_E1B.txt und C8_E1C.txt (ICD-Anhang C.7/C.8) sind aus dem Repository und aus den Paketen entfernt. Die Bedingungen des ICD (zitiert in LICENSING.md) erlauben es einem Nutzer, die Codes unter Nennung der Quelle zu speichern und in einem Produkt zu verwenden, gestatten die Weitergabe aber nur für nichtkommerzielle Zwecke, und Kshana wird auch unter einer kommerziellen Lizenz angeboten. galileo::e1b_table / e1c_table liefern jetzt ein Result und lesen die eigene Kopie des Nutzers aus KSHANA_GALILEO_E1B / KSHANA_GALILEO_E1C oder, in einem Source-Checkout, aus data/galileo-os-sis-icd/, wohin das neue scripts/fetch_galileo_e1_codes.sh sie aus dem ICD-PDF extrahiert (mit Hash-Prüfung). galileo::E1B_TABLE_TEXT / E1C_TABLE_TEXT sind entfernt. Ohne die Tabellen geben die Galileo-E1-Signale (galileo-e1b, galileo-e1c) einen Fehler zurück, der angibt, wie sie bereitzustellen sind, und die E1-Tests werden mit einer Meldung übersprungen. Sind die Tabellen vorhanden, bleibt jede E1-Ausgabe unverändert. Kein Szenario, keine Golden-Ausgabe und keine Spektrumsausgabe verwendet die Codetabellen. Die E5a-Testfixtures aus Anhang C.3/C.4 (die LFSR-Referenz in tests/iq_signals.rs) werden genauso behandelt: Sie werden mit demselben Skript geholt, von git ignoriert, und der Test wird ohne sie übersprungen.

• Portable Mathematik überall (0,36, STUDIO-15): Jede transzendente f64-Funktion der Bibliothek sowie die Normal-, Gamma- und Exponential-Sampler von rand_distr rechnen jetzt über die reine Rust-Bibliothek libm (portable_math::PortableFloat, portable_distr), sodass ein nativer Build und der WebAssembly-Build für alle 141 mitgelieferten Szenarien und für den kurzen IQ-Lauf byte-identisches Ergebnis-JSON liefern. Der Preis dafür ist, dass sich die letzten Bits der mit der Mathematikbibliothek des Hosts berechneten Ergebnisse verschoben haben: 98 der 141 mitgelieferten Szenarien haben sich geändert, 43 nicht; bei 5 änderte sich ihr größtes Feld um mehr als 1e-3, bei den übrigen um weniger. Jeder verschobene Wert ist alt -> neu in docs/revisions/STUDIO15-portable-math-rebaseline.md aufgeführt (mit einer CSV aller 136.127 verschobenen Zahlen); kein Zielwert, keine Toleranz und keine Schwelle wurde geändert. Veröffentlichte Zahlen, die sich geändert haben: europa-surface-pnt Verfügbarkeit mit der Erdentfernung 0,719 -> 0,713 und RMS-Fehler 86,147 -> 86,499 m (eine Epoche am Rand der Verfügbarkeit wird nun überall gleich aufgelöst; auf macOS arm64 wurden 0,725 / 85,800 m ausgegeben); lunar-joint-od-clock Stationsfehler 3,541350 -> 3,536885 m mit VLBI und 2183,558 -> 2184,021 m ohne; paper/crossover/inertial.json, acht vibration_psd-Werte um 3 Einheiten in der letzten Stelle (Erratum im technischen Bericht); das veröffentlichte Dokument cislunar-observability bei Größen im Rundungsrauschen (acht Werte jenseits von sechs signifikanten Stellen, bis zu 6.8e-5 relativ; kein Rang und keine Schwelle verschoben). Die festgelegten Hashes der Byte-Identitäts-Wächter (skyline_scenarios, geometry_corpus_identity, geometry_trust_no_change) sind auf eine benannte Basislinie „0,36 portable“ umgestellt, wobei die Werte von 0.35.0 als historische Aufzeichnung erhalten bleiben; die eingefrorene Vorhersage der Mond-Referenzstation bleibt unberührt, und ihr portabler Neulauf liegt daneben (docs/predictions/*.portable-0.36.json). tests/lunar_joint_od_numpy_oracle.rs (die validierte Zeile zur gemeinsamen Mond-Bahnbestimmung): Die Fixtures wurden neu exportiert und der numpy-Vergleich mit numpy 2.4.6 erneut ausgeführt, der registrierten Version; Skript und Zielwert unverändert; alle sechs Netze bestehen (docs/revisions/STUDIO15-lunar-joint-od-oracle-rerecord.md). Die nach STUDIO-15 zusammengeführten Arbeiten der Batches 2-3 verwenden ebenfalls portable Mathematik (457 Aufrufstellen in 62 Dateien); was sich dadurch verschoben hat, steht in docs/revisions/STUDIO15-batch4-rebaseline.md: 12 mitgelieferte Szenarien (größte relative Änderung 5.2e-8, keine ausgegebene Zahl verschiebt sich), 28 neu bestätigte Skyline-Wächterzeilen, der M2M4-Digest von iq_campaign, die alten Truth-Hashes von gnss-ins, die Datum-Sigma der unbeobachteten Bake (632,3769 -> 632,3772 m) und zwei festgehaltene Befunde (CR3BP-DRO-Schließungen; CRPA A3, 194 von 456 Verbindungen). Die exakte Greenhall-edf behält ihren validierten Zielwert mit einem Double-Double-Logarithmus in ihrem Kern (docs/revisions/STUDIO15-greenhall-edf-portable.md), und die gps-sdr-sim-test-bench-Referenz wurde auf den verschobenen NMEA-Exporten erneut ausgeführt, wobei jeder Zielwert eingehalten wird (docs/revisions/STUDIO15-testbench-gpssdrsim-rerun.md).

• README: Die Zeile zur Mond-Suite nennt die Evidenzstufe jedes Teils (zuvor hieß es, alle seien MODELLED).

• realdata::clk::rinex_clock_series liefert RinexClockSeries (Reihe, Gridding-Protokoll, Zeitsystem, ob es angegeben war, Satztyp) statt eines (PhaseSeries, GriddingLog)-Tupels. Es greift jetzt von Satelliten-Datensätzen (AS) auf Empfänger-/Stationsdatensätze (AR) mit dem angeforderten Namen zurück.

• Kein Wert ändert sich, außer wenn die Geometrie schlecht ist; das Label wird immer ausgegeben. Bei guter oder mittlerer Geometrie (einschließlich eines GPS-only-Himmels ohne Abschattung mit 8 Satelliten) oder bei unbekannter Geometrie (der Monitor läuft nicht) ist jeder Wert wie in 0,35: tests/geometry_trust_no_change.rs hält die Ausgaben beider Beispielsitzungen und tests/geometry_corpus_identity.rs jedes eingecheckte NMEA-Korpus von Schiffen (auch als GPS-only-Himmel ohne Abschattung) sowie die Szenarien des Crew-Trainings auf die Bytes von 0.35.0 fest, sobald die angehängten Schlüssel entfernt sind; in den beiden Trainingsszenarien, deren jamming die Geometrie schlecht macht, unterscheiden sich die schlechten Epochen allein durch den Geometrieabzug. Ein Log mit schlechter Geometrie verliert bis zu 15 Punkte, die es in 0,35 nicht verlor. Gewollte Änderungen sonst, alle als Ergänzungen: die obigen Schlüssel im Ergebnis-JSON und in den Nachweispaketen (score_model.weights ist unverändert); das Live-JSON-Lines-Schema geht von 1,2 auf 1,3 (geometry angehängt, class in jedem Abzug); die Auszugszusammenfassung erhält geometry; die Telemetrie erhält Geometrie-Reihen, Felder und das Label class nur für Eingaben, die sie mitbringen, sodass ein Strom oder Ergebnis aus 0,35 Byte für Byte wie zuvor dargestellt wird. geometry ist der 17. Monitorname; er steht zuletzt in monitors_run, wenn er entschieden hat (ein Schiff, dessen Log die Geometrie liefert; eine Liste aus 0,35 behält ihre Reihenfolge, und die Monitoranzahl der Zusammenfassung steigt um eins) und hat keinen Eintrag in [score.weights] (einen zu setzen wird abgelehnt: sein Abzug wird in [geometry] festgelegt).

• tests/fixtures/dop/NOTICE nannte die Lizenz von gnss_lib_py Apache-2.0; die Version 1.0.4 steht unter MIT.

• Der NMEA-Leser liest jetzt GSA (ein kurzer GSA-Satz wird ignoriert, nicht als übersprungen gezählt) und behält GSV-Elevationen und -Azimute, auch für Satelliten, die ohne Signal aufgeführt sind; der UBX-Leser behält die Elevation und den Azimut aus NAV-SAT. C/N0 wird genau wie zuvor gelesen.

• Ergebnisänderung: Breitband- und Sweep-Störsender verwenden jetzt Q = 2. Die Anti-Jam-Gleichung verwendet für diese Störsender die in Lehrbüchern übliche Spreizspektrum-Anpassung Q, wo sie zuvor 1 verwendete. Q = 2 entspricht weißem Rauschen über die Hauptkeule bei normalisierter Signalleistung im Band; es ist in den Tests auf die geschlossene Form aus navsignal festgelegt.

  • Unverändert: CW- und Schmalband-Störsender (Q = 1), ein nicht erkannter Störsendertyp (Q = 1, der schädlichste Wert) und q_override.
  • Wirkung: Wo ein Breitband- oder Sweep-Störsender wirkt, steigt das effektive C/N0 um bis zu 3,0103 dB, abgeleitete J/S-Schwellen steigen um 3,0103 dB, und die Sperrradien im freien Raum schrumpfen um den Faktor 0,7071.
  • Geänderte mitgelieferte Szenarien: 12 von 144 ändern sich, alle wie vorab registriert (xval/jammer-q/PREREGISTRATION.md, Ergebnisse in xval/jammer-q/RESULTS.md):
    • jamming-demo: C/N0 +3,01 dB;
    • jamming-harbour-approach-skyline: min_tracking 6 → 7;
    • lunar-jamming: verlorene Satelliten 26 → 0, Median des Abstands bis zum Verlust der Verriegelung 27,4 → 19,4 km;
    • tracking-loop: Sperrradius der Schleifendynamik 75,2 → 53,2 km;
    • und die Kampagnen und Spektrum-Gegenprüfungen, die diese enthalten.
  • Betroffene Verbraucher: die Arten jamming, lunar-jamming, tracking-loop und impairment-eval, der jamming_kind_cross_check der Spektrum-Arten, die Referenzkurve der IQ-Kampagne, die MODELLED ist, und das labfit-Standard-Q sowie der Interop-Szenenexport.

• JetBrains-Plugin: keine veraltete und nicht zur Entfernung vorgesehene Plattform-API. Die fünf Auswahldialoge verwenden einen kleinen DialogWrapper mit Dropdown anstelle des veralteten Messages.showChooseDialog; Einzeldatei-Auswahldialoge verwenden den Konstruktor FileChooserDescriptor anstelle des veralteten FileChooserDescriptorFactory.createSingleFileDescriptor(); die Animation öffnet sich mit BrowserUtil.browse(Path) anstelle von browse(File), das die Plattform 2026,3 zur Entfernung vorsieht. Since-build bleibt 243. Der IntelliJ Plugin Verifier meldet Compatible ohne veraltete oder zur Entfernung vorgesehene Verwendung gegenüber 2024,3 (IC-243.21565.193), 2025,2 (IC-252.23892.409), 2026.2.3 (IU-262.10968.63) und 2026,3 EAP (IU-263.6259.32); verifyPlugin prüft standardmäßig 2024,3 sowie jede in KSHANA_VERIFY_IDES angegebene Liste.

• gnss_sim::run_gnss_sim und jamming::run_jamming liefern Result: Ein ungültiger Abschnitt [skyline] ist bei direktem Aufruf ein Fehler, wie er es über api::run_toml bereits war, statt eines stillen Rückfalls auf die flache Maske. Breaking für Rust-Aufrufer dieser beiden Funktionen.

Behoben#

• Kampagnen-Bewerter: Ein echtes Falsch-Einrasten des Trackers wurde nie gezählt (iq::campaign). Die Falsch-Einrast-Prüfung des Trackers setzt einen Kanal beim Auslösen von LOCKED auf LOST. Der Bewerter markierte stattdessen die nächste Aktualisierung des Kanals, die dann entriegelt war und deshalb nie gezählt wurde. Ein Ereignis false-lock, das aus LOCKED gemeldet wird, ist jetzt eine Episode zu seinem Zeitpunkt, im Lauf und in jedem angegebenen Ereignis, das es enthält. Eines, das während des Pull-in gefunden oder von einem bereits LOST-Kanal wiederholt wird, ist keine neue Episode. Ein neuer Test erzeugt ein echtes Falsch-Einrasten: ein legitimer GPS-L1-C/A-Träger, der im verriegelten Zustand um 1/(2T) springt (tests/iq_campaign_false_lock.rs).

  • In der Referenzkampagne von tests/iq_campaign.rs ändert sich nur PRN 11 von ramp/agc-3bit (Falsch-Einrast-Episoden 0 → 1, 426 und 437 pro verriegelter Stunde).
  • Die DIGESTs seiner Zellen sind neu festgelegt.
  • Die vorab registrierte Festlegung der bewerteten Ergebnisse bleibt aktiv und lässt sich weiterhin exakt reproduzieren: In ihrem Hash werden nur jene sechs Felder, die sich durch diese nach der Registrierung vorgenommene Korrektur geändert haben, auf ihre Werte vor der Korrektur zurückabgebildet. Die korrigierten Werte sind für sich festgelegt.
  • Es wurde kein Zielwert geändert, und keine Zeile VALIDATED, keine Abbildung und keine Zahl im Web hat sich verschoben.

• lunar-frame-campaign: Eine Bake ohne Beobachtung wird jetzt gemeldet (gefunden von MR-05). Der Bericht erhält unobserved_beacons und warning nur dann, wenn irgendeine Bake keine Beobachtung hat, und die Sigmas der beobachteten Baken stammen dann aus ihrer eigenen Information, statt alle null zu sein. Das Datum ist unverändert, und keine Standard-, mitgelieferte oder veröffentlichte Ausgabe verschiebt sich (docs/revisions/BEACON-unobserved-cell-changes.md).

• Hauptachsen-Bezugssystem des Mondes (lunar_frame::icrf_to_moon_pa, verwendet von lunar_od und der LRO-Anpassung): Der DE421-Versatz vom mittleren Erdsystem zum Hauptachsensystem aus moon_080317.tf wurde in der falschen Richtung und mit der falschen Euler-Reihenfolge angewendet, sodass das analytische PA-System etwa 208″ von PA entfernt lag, statt darauf. Es ist jetzt so übertragen, wie es SPICEs Frames Required Reading definiert, und stimmt mit SPICE pxform('MOON_ME','MOON_PA') auf 2.6e-16 rad überein; das analytische PA-System liegt 6″ bis 8″ von DE440 PA entfernt (vorab registriert e1ead19b, neu registriert be33382e, nachdem die erste vorgeschlagene Änderung den Zielwert 1e-12 verfehlt hatte; docs/design/evidence/fut05b-me-pa-offset-sign/). Veröffentlichte Zahlen, die sich verschieben: die LRO-Anpassung (tests/agency_lro.rs) Roh-Überlappung 53,8 → 39,9 m, dynamisch 12,6 → 12,05 m, reduziert-dynamisch 6,65 → 6,67 m (Zielwerte unverändert). Der analytische Stack stimmt nun auf beiden Stufen mit der DE-Güte-Kreuzvalidierung von ANISE (12,0 / 6,67 m) überein; die frühere Lücke auf der dynamischen Stufe war dieser Fehler.

• Der MCP-Server lehnt [terrain] dem_hgt ab (Nachfolgearbeit zu CAP-06b). Der Pfad der Geländekachel der Szenarioart jamming steht jetzt in inline_only::FILE_SOURCE_KEYS. Eine Inline-Oberfläche lehnt ein Szenario ab, das einen solchen Pfad nennt, mit einer Meldung, die weder den Pfad noch einen Betriebssystemfehler enthält. Der Wächtertest für Dateiquellen kennzeichnet nun auch Felder, die auf _hgt enden.

• Jd2::from_parts mit einem gebrochenen Tagesanteil verwarf den Bruchteil in den Umrechnungen UTC, TAI, UT1 und Erdrotation (eine Stunde Tagesanteil ließ die Erde um 15° falsch stehen); der Tagesanteil wird jetzt auf eine ganze Zahl normalisiert. Kein Aufrufer der Engine war betroffen: Jeder übergibt einen ganzzahligen Tag, und jede ausgelieferte Ausgabe ist bitidentisch.

Geplant#

• Die Geometrie aus einer angegebenen Skyline (0,36 Punkt 1, jetzt in der Engine als src/skyline.rs): sky-blocked und open_fraction aus der Skyline, wo die Eingabe eine liefert (die Azimutlücke als Ausweichlösung), ein Ereignis natürlicher Beeinträchtigung (Fjord oder Terminal) in nmea-scenario und die beiden maskierten Geometrien der Designnotiz in der Zeile sigma_UERE x DOP, vorab als Nachtrag registriert.
• Geometrie für RINEX-Logs mit Navigationsdaten (aus dem eigenen Fix der Engine) und für Android-Logs (aus den Status-Zeilen); beide lesen heute unknown. Geometrie in $PKSHT (Version 1 in 0,36 unverändert) und die Integrationen für Signal K und OpenCPN.
• Eine bereits bestehende Lücke, in 0,36 nicht eingeführt: Sobald das SNR-Feld jedes Satelliten leer ist, löst weder loss-of-lock noch ein C/N0-Abzug aus; der vollständige Signalverlust ist nur über das signal_loss des Geometrie-Monitors sichtbar (klassifiziert als environment). Ein Abzug dafür ist geplant.
• Ein Strom nach Schema 1,3 in den externen Telemetrie-Referenzen (Prometheus-Textformat-Parser und OTLP-Collector), die heute nur Ströme nach 1,2 abdecken.
• Eine beidseitige Abschattung (eine Schlucht oder ein enger Fjord) wird als Signalverlust gelesen und nicht als blockierter Himmel, bis die Skyline integriert ist.

[0.35.0] - 2026-10-12#

Eine Passage, die KI-Clients von Drittanbietern nennt, ist hier ausgelassen; sie steht in CHANGELOG.md auf GitHub.

Galileo-OSNMA-Verifizierer#

• Neues Modul kshana::osnma und kshana osnma verify <input>: ein offener Verifizierer auf Empfängerseite für Galileo OSNMA in reinem Rust. Er liest I/NAV-Seiten und meldet je Satellit und Epoche, ob die Navigationsdaten authentifiziert sind, mit einem Grund für jeden Fehlschlag oder jede Verzögerung: Parsen von HKROOT und MACK, Wiederzusammensetzen von DSM-KROOT und DSM-PKR, Merkle-Verifizierung des öffentlichen Schlüssels, Verifizierung der TESLA-Schlüsselkette, MACSEQ- und Tag-Verifizierung für ADKD 0, 4 und 12 einschließlich Kreuzauthentifizierung sowie ein Ergebnis in der Form von $PKSOS für den Receiver-Trust-Monitor. Die Ausgabe trägt einen Hinweis, dass der Status kein Navigations-Integritätsdienst ist. docs/OSNMA.md legt dar, was verifiziert wird und was nicht, die Zeitanforderung und dass Kshana keine Rechte unter den IPRs des ICD von OSNMA der EU gewährt (Nutzer stützen sich auf die Autorisierung in Anhang E des ICD). Umgesetzt gegen das SIS ICD Issue 1,1 und die Receiver Guidelines Issue 1,3. Seiten werden per CRC geprüft, und ein Bytestrom UBX-RXM-SFRBX von u-blox kann direkt gelesen werden (--format ubx). Die Standardtests verwenden synthetische Daten und veröffentlichte Known-Answer-Tests der Primitive; ein optionaler Test liest eine lokal heruntergeladene Kopie der offiziellen Vektoren. Nach unabhängiger Prüfung entnimmt der Verifizierer seine Zeit nur aus verifizierten TESLA-Schlüsseln (ein gefälschter Subframe weit in der Zukunft kann einen Fehlschlag nicht mehr löschen), lässt eine Authentifizierung ablaufen und dem verwendeten IODnav folgen, beachtet verifizierte Alarmmeldungen (deren Merkle-Blatt jetzt das zufällige Feld NPK enthält) und den NMA-Status „don't use“, hält Dummy-Tags aus dem Satellitenstatus heraus, führt Ketten nach CID mit Widerruf und Erneuerung, prüft den Padding-Hash von KROOT und begrenzt UBX-Framelängen und den Aufwand der TESLA-Verifizierung. Ein Satellit gilt nur so lange als authentifiziert, wie die neuesten von ihm gesendeten Ephemeriden- und Uhrdaten Bit für Bit die Daten sind, die authentifiziert wurden (nicht lediglich unter demselben IODnav); ein Status oder Widerruf aus dem nicht authentifizierten NMA-Header zählt nur, wenn zwei Satelliten übereinstimmen oder ein verifiziertes KROOT ihn trägt; ein wieder eingespieltes älteres KROOT kann eine Kette nicht ersetzen, und ein stockender Schlüsselstrom wird gemeldet.

Hinzugefügt (MCP-Server-Kanäle)#

Eine Passage, die KI-Clients von Drittanbietern nennt, ist hier ausgelassen; sie steht in CHANGELOG.md auf GitHub.

• kshana-mcp --http <addr>, Streamable HTTP, selbst gehostet. Standardmäßig Loopback; eine Nicht-Loopback-Adresse braucht --allow-remote und ein Bearer-Token in KSHANA_MCP_HTTP_TOKEN; kein Tool liest oder schreibt einen Pfad (die IQ-Dateitools sind aus); Grenzen für Anfragegröße, Zeit und Nebenläufigkeit; kein CORS-Header; Prüfungen von Host und Origin. Kshana betreibt keinen Endpunkt (docs/deploy/mcp-http.md, mit Vorlagen für Docker, Fly.io und Cloud Run).

Hinzugefügt (Oberflächen)#

• osnma_verify in Python und WebAssembly. Der Verifizierer hinter kshana osnma verify auf Bytes im Speicher, der das JSON zurückgibt, das --json ausgibt (Hinweis in seinem Feld advisory; nur Authentifizierungsstatus, kein Navigations-Integritätsdienst). Dieselben Ablehnungen wie auf der Kommandozeile. Nicht über MCP: Die Eingabe ist ein langer roher Empfängerstrom, der besser von der CLI und von Python bedient wird. docs/SURFACES.md und docs/OSNMA.md sagen das.

• trust_telemetry in WebAssembly, Python und MCP, mit einem Plugin-Befehl und einer JetBrains-Aktion. Stellt einen Vertrauensstrom oder ein receiver-trust-Ergebnis als Prometheus-Text, als CEF- oder LEEF-Syslog-Zeilen oder als OTLP-JSON-Nutzlast dar, mit den Encodern, die kshana trust-telemetry verwendet (kshana::surface::trust_telemetry); kein Socket und keine Uhr. Plugin: /kshana-trust-telemetry und der Skill trust-telemetry. JetBrains: Render Trust Telemetry. Die Features wasm und python und der MCP-Server aktivieren jetzt auch otlp, was kein Crate hinzufügt.

• Paritätsdurchgang. JetBrains-Aktionen Validate Scenario, List Scenario Kinds und Assess Receiver Stream; kshana --help listet jetzt receiver-trust evidence, evidence, trust-telemetry und nmea-scenario; das Notebook compliance-and-test-bench (compliance-Zuordnung und test-bench-Export); und jede verbleibende JetBrains-Zelle „CLI only“ in docs/SURFACES.md ist jetzt ein ausdrückliches N/A mit Begründung.

Eine Passage, die KI-Clients von Drittanbietern nennt, ist hier ausgelassen; sie steht in CHANGELOG.md auf GitHub.

Hinzugefügt (Nachweispakete)#

• kshana receiver-trust evidence und kshana evidence verify: signierte, verifizierbare Nachweispakete für ein GNSS-Vertrauensereignis. Ein Paket bündelt den rohen Log-Ausschnitt und das SHA-256 des vollständigen Logs, die Konfiguration mit jeder Schwelle, die Ergebnisse und Gründe je Epoche, die Engine-Version, ein hashverkettetes Manifest und eine eigenständige HTML-Zusammenfassung, signiert mit Ed25519 (ein Schlüssel aus kshana evidence keygen oder Ihre eigene Datei; Schlüssel werden nie in einem Paket gespeichert, und *.evidence-key wird von git ignoriert). verify prüft jeden Hash, die Kette und die Signatur und nennt genau, was fehlschlägt; mit --pubkey legt es den Unterzeichner fest. Ein RFC-3161-Token kann angehängt werden und wird gelesen und an das Manifest gebunden (die eigene Signatur der Instanz wird von diesem Build nicht geprüft; openssl ts -verify deckt sie ab). Der Log-Ausschnitt besteht aus den exakten Bytes des Fensters, wo der Leser Quellspannen meldet (NMEA, UBX, RINEX 3, Android), sonst aus dem ganzen Log, und das Manifest sagt, was zutrifft. Erstellung und Verifizierung sind reine öffentliche Funktionen (kshana::evidence), die für wasm32 gebaut werden. Die Pakete geben an, dass sie eine technische Aufzeichnung sind, kein Rechtsgutachten. Die neuen Abhängigkeiten sind der Baum von ed25519-dalek (BSD-3-Clause und Apache-2.0/MIT, minimale Features) und ein direktes zeroize (bereits in diesem Baum), um Schlüsselmaterial zu löschen. Siehe docs/EVIDENCE-PACKS.md.

Hinzugefügt (Vertrauenstelemetrie)#

• kshana trust-telemetry: GNSS-Vertrauen als Quelle für Sicherheitstelemetrie. Liest den Vertrauensstrom je Epoche (JSON Lines: Wert 0-100, Band, Gründe) oder ein Batch-Ergebnis von receiver-trust und speist einen Prometheus-Endpunkt /metrics (standardmäßig localhost), Syslog-Ereignisse in CEF oder LEEF innerhalb eines RFC-5424-Umschlags (UDP oder TCP) und, hinter dem standardmäßig ausgeschalteten Feature otlp, den OTLP/HTTP-JSON-Export. Die Zustellung läuft in Worker-Threads mit Zeitgrenzen für Verbindungsaufbau und Schreiben, begrenztem Reconnect-Backoff und einem Zähler kshana_trust_syslog_send_failures_total, sodass ein toter oder hängender Collector weder die Live-Bewertung anhalten noch /metrics einfrieren kann; Gründe-Labels sind auf 64 Reihen begrenzt. Keine neuen Abhängigkeiten. Ein Beispiel-Grafana-Dashboard liegt in deploy/grafana/. Metriknamen, Labels und die CEF/LEEF-Feldzuordnung stehen in docs/TRUST-TELEMETRY.md. Das Stromformat ist in src/telemetry/sample.rs isoliert.

Hinzugefügt#

• Maritimes Vertrauen: ein Live-Vertrauenswert von 0-100 für den Fix eines fahrenden Schiffes, aus dem NMEA 0183, das der Empfänger ohnehin ausgibt, mit einem optionalen Gate. kshana receiver-trust nimmt eine Tabelle [platform] entgegen (kind = "static" oder "vessel", die Höchstgeschwindigkeit, Beschleunigung und Drehrate des Schiffes, die Antennenhöhe über der Wasserlinie und ein optionaler Kurssensor; jeder Standardwert ist mit seiner Begründung dokumentiert). Für ein Schiff wird der statische Positionssprung-Monitor, der den Abstand vom Kalibrierungsmittel misst und auf einem fahrenden Schiff falsch liegt, durch kausale Monitore für bewegte Plattformen ersetzt: kinematische Konsistenz der Position mit der gemeldeten Geschwindigkeit und dem gemeldeten Kurs sowie mit den Grenzen des Schiffes, Kreiselkompasskurs gegen Kurs über Grund, Logge gegen Geschwindigkeit über Grund, Antennenhöhe gegen die angegebene Höhe über der Wasserlinie, ein Zusammenbruch der C/N0-Streuung, der zusammen mit einem Anstieg gegen die Kalibrierungs-Basislinie auftritt, und Zeitkonsistenz (im Live-Modus auch gegen die Uhr dieses Rechners). Er liest außerdem einen gemeldeten Authentifizierungsstatus, insgesamt oder je Satellit (nur ein gemeldeter Status: keine OSNMA-Kryptografie). Jede Schwelle wird vor dem Lauf in einer Tabelle [maritime] angegeben. Jede Epoche erhält dann einen Wert von 0 bis 100 durch eine deterministische, vorab registrierte Abbildung (kein Lernen, nichts an Ereignisse angepasst; Gewichte, Bandgrenzen und der Nachweis stehen in einer Tabelle [score]), abgebildet auf die bestehenden Vertrauenszustände, mit den Monitoren, die Punkte abgezogen haben, und deren Punkten. Statische Szenarien sind unverändert und haben denselben Hash wie zuvor. kshana receiver-trust live <session.toml> liest stdin, eine Datei, an die angehängt wird, TCP oder UDP und schreibt je Epoche eine JSON-Zeile und einen proprietären Satz $PKSHT; mit --gate reicht es den Strom unverändert durch, solange der Fix vertrauenswürdig ist, und markiert den Fix als ungültig (GGA-Qualität 0, RMC- und GLL-Status V, GNS- und VTG-Modus N), solange er es nicht ist. Das Gate ist aus, sofern es nicht verlangt wird; --listen tcp:<port> stellt den gefilterten Strom beliebig vielen TCP-Clients bereit (standardmäßig Loopback, ein langsamer Client wird getrennt, statt die anderen zu blockieren). Dies ist beratende Software, keine typzugelassene Navigationsausrüstung (IEC 61108, IEC 61162); der Betreiber bleibt verantwortlich. examples/maritime-trust/ ist ein synthetisches Log von Tallinn nach Helsinki, nur als Text geschrieben, mit einem Wegdriften der Position auf halber Strecke, währenddessen der Empfänger weiter einen gültigen Fix meldet; seine erwartete Ausgabe ist durch einen Test festgelegt. Leitfaden: docs/MARITIME-TRUST.md. Die Prüfungen können einen Spoofer nicht erkennen, dessen Fix mit allem auf dem Bus konsistent ist; der Leitfaden sagt das.

Störungskarte#

• kshana interference-map und kshana route-exposure: ein öffentliches Bild davon, wo Flugzeuge und Schiffe beeinträchtigte Navigationsdaten gemeldet haben und wie viel einer Route davon berührt wird. Eingaben sind lokale CSV-Dateien, erstellt aus offen lizenzierten ADS-B-Daten (adsb.lol, ODbL 1,0) und AIS-Daten (NOAA MarineCadastre, Kystverket unter NLOD 2,0); jede Ausgabedatei umfasst eine Quelle und einen UTC-Tag als GeoJSON und trägt die Methode, ihre Schwellen, die Datenlizenz, die Namensnennung und die Abdeckungsverzerrung der Quelle. Die ADS-B-Methode aggregiert NIC und NACp auf ein festes Raster und stuft eine Zelle anhand des Anteils verschiedener Flugzeuge als beeinträchtigt ein, mit Schutzvorkehrungen für Geräte, die nie eine Genauigkeit melden, für geringe Höhe und für großräumige Ursachen. Die AIS-Methode lässt fünf Detektoren laufen: Positionen an Land (gegen eine vom Nutzer gelieferte Küstenlinie), Kreisbahnen, unplausible Sprünge, unplausible Geschwindigkeiten und viele Schiffe an einer Position. Schwellen sind vorab registrierte Konstanten einer benannten Methodenversion. Nur Aggregate: Kennungen werden im Speicher gehasht und nie geschrieben, und Zellen mit weniger als 5 verschiedenen Flugzeugen oder Schiffen werden nicht veröffentlicht. Eine beeinträchtigte Zelle ist kein Befund einer Störung. Die Standardbefehle verwenden kein Netzwerk; ein optionaler Helfer fetch-land --allow-network lädt Natural-Earth-Landpolygone von einer an einen Commit gebundenen Adresse herunter und behält die Datei nur, wenn ihr SHA-256 übereinstimmt. ADS-B-Eingabe ist eine CSV oder direkt die readsb-History-Dateien von adsb.lol (neue Abhängigkeit: flate2 mit seinem reinen Rust-Backend, für gzip). Beide Methoden haben die Version 2: Eine Einstufung als beeinträchtigt oder anomal braucht mindestens 5 Flugzeuge oder Schiffe (das Veröffentlichungsminimum), jede Anzahl je Zelle unter 5 wird als null zurückgehalten, und ein Tag, dessen Hintergrund nicht geschätzt werden kann, hält seine Einstufungen zurück. Ausgabedateien heißen <source>-<dataset>-<date>.geojson und werden nie überschrieben; die Eingabe wird zeilenweise gestreamt; die Routenexposition behandelt den Antimeridian. Tests verwenden nur synthetische Daten. Siehe docs/INTERFERENCE-MAP.md und die Lizenzprüfung in docs/data/INTERFERENCE-DATA-SOURCES.md.

Hinzugefügt (Trainingsströme)#

• kshana nmea-scenario: synthetisches Brücken-NMEA 0183 für das Crew-Training im Erkennen von GNSS-jamming und -spoofing. Aus einem Szenario-TOML schreibt es eine Datei oder streamt über TCP oder UDP (Unicast oder Broadcast; in Echtzeit, beschleunigt oder so schnell wie möglich) den vollständigen Brückensatz GGA, RMC, VTG, GSV, GSA, GNS, ZDA, HDT und VBW für einen Schiffskurs mit Grenzen für Drehrate, Beschleunigung und Strömung, mit Satellitengeometrie aus den eigenen nominalen Konstellationen der Engine. Geskriptete Ereignisse auf einer Zeitachse: jamming, Wegdriften der Position (ein gültiger Fix, der sich entfernt), Zeit-spoofing und eine Wiedergabeverzögerung, jeweils mit Anstiegs- und Abklingrampen. Ein Ausbilderlog (JSON und Text) hält fest, was wann eingespeist wurde, mit dem wahren Kurs gegenüber dem gemeldeten. Eine Bibliothek in scenarios/training/ (jamming auf offener See, Wegdriften an der Küste, Zeit-spoofing bei der Hafeneinfahrt, kombiniert) enthält Trainerhinweise. Die Ausgabe ist prüfsummengültig und je Seed deterministisch; die Tests legen für jedes Szenario einen Golden-Auszug fest und lesen jeden Satz mit dem NMEA-Leser von receiver-trust. Nur Text: keine HF-, IQ- oder Wellenformausgabe; die Ströme dienen Training und Test und dürfen nie in die Live-Navigationssysteme eines Schiffes eingespeist werden. Siehe docs/NMEA-TRAINING.md.

Maritime Integrationen (0.35.0, Arbeitsstrang B)#

• Signal-K-Plugin (integrations/signalk/, nicht auf npm veröffentlicht): führt kshana receiver-trust live aus oder verbindet sich damit (der eigene NMEA-Eingang des Servers, benutzerdefinierte Eingabeargumente, ein JSON-Lines-TCP-Feed oder die Sätze $PKSHT eines Gate-Stroms), veröffentlicht den Vertrauenswert, das Band, die Gründe, die Alarme und den Gate-Zustand unter navigation.gnss.kshana.* (einschließlich der vom Empfänger gemeldeten Position als Kontext, nie als navigation.position) und löst eine Signal-K-Benachrichtigung aus (warn bei degraded, alarm bei untrusted, mit Schwellen für Halten, Löschen und Veralten, alle im Konfigurationsschema). Keine npm-Abhängigkeiten. Getestet an aufgezeichneter synthetischer Ausgabe.
• OpenCPN: NMEA im Gate-Modus wird direkt von kshana receiver-trust live --gate --listen tcp:10110 bereitgestellt (empfohlen); ein abhängigkeitsfreies TCP-Relay (integrations/opencpn/nmea-tcp-relay.mjs) ist die optionale Alternative. In beiden Fällen sieht OpenCPN einen ungültigen Fix, wenn das Vertrauen zusammenbricht, und $PKSHT in seinem NMEA-Debug-Fenster; die Tests spielen den synthetischen gefilterten Strom über einen echten TCP-Socket ab und prüfen, was ein Verbraucher erhält. Ein natives Plugin mit Wertanzeige (integrations/opencpn/plugin/, Plugin-API 1,18, CMake) liest $PKSHT aus dem eigenen NMEA-Strom von OpenCPN und alarmiert im Band untrusted; es baut, seine Logik ist per Unit-Test geprüft, und es lief in OpenCPN 5.8.4 unter einem virtuellen Display (Nachweis und ein Reproduktionsskript in integrations/opencpn/evidence/); es ist nicht für den Plugin-Manager paketiert.
• Referenzaufbau (deploy/reference-build/): generische Teileliste, Betriebssystem-Einrichtung, systemd-Units für den beratenden Monitor und das optionale Gate (von check-units.sh mit systemd-analyze verify geprüft), eine Container-Option, Signal-K-Verdrahtung.
• Das Signal-K-Plugin akzeptiert das Live-JSON-Schema 1,2 (ein Schlüssel position, dann ein Schlüssel advisory angehängt; unbekannte angehängte Schlüssel werden ignoriert), geprüft an echter Ausgabe nach 1,2 und gegen einen echten signalk-server.
• Korrekturen aus der Prüfung: Die systemd-Units starten immer neu und laufen in einer Sandbox (keine Shell, kein Netzwerk, wo keines gebraucht wird), ein logrotate-Schnipsel, check-units.sh schlägt bei jedem Befund fehl; der Container führt das Gate mit Umgebungsvariablen aus, mit Health-Check und per Digest festgelegten Basis-Images; Signal-K-Wert-Metadaten, die veraltete Benachrichtigung wird ersetzt, wenn wieder Daten eintreffen, Fehler von Kindprozessen bleiben erhalten und Kills eskalieren, unsichere inputArgs werden abgelehnt, und die Benachrichtigung liegt unter notifications.navigation.gnss.kshana.trust; das Relay begrenzt eine zurückgehaltene Teilzeile; die Parser von $PKSHT weisen Werte außerhalb von 0 bis 100 zurück; eine Prüfung der Dokumentationslinks; ein CI-Workflow (marine-integrations.yml), der all das ausführt, einschließlich der echten Binärdatei von Anfang bis Ende.
• docs/MARINE-INTEGRATIONS.md. Beratende Software, kein typzugelassenes Gerät; der Betreiber bleibt verantwortlich. Nur Software: Nichts sendet, und es wird keine Erkennungs- oder Fehlalarmzahl behauptet.

Hinzugefügt: compliance-Zuordnung und test-bench-Export#

• docs/compliance/ und kshana compliance-report. Eine Zuordnung von Kshana-Ausgaben zu fünf Resilienz-Rahmenwerken und Normen (das Resilient PNT Conformance Framework v2.0 des US-DHS, IMO-Leitlinien für Schiffe, EASA-Leitlinien für die Luftfahrt, NIS2 Artikel 21, EN 16803, eine kostenpflichtige Norm, zitiert nach Teil und nach den wenigen im Katalogtext sichtbaren Abschnittsnummern), eine Tabelle je Rahmenwerk: die Referenz, was sie in unserer Paraphrase verlangt, die Ausgaben, die Belege dafür liefern, und die Lücke. Quellversionen, URLs und was gelesen wurde und was nicht, sind festgehalten. kshana compliance-report <result.json>... füllt die Zuordnung aus den angegebenen Läufen und markiert jede Zeile als evidenced, partly-evidenced, not-evidenced oder out-of-scope, als Markdown und JSON, wobei die Lücke in jeder Zeile erhalten bleibt. Die Formulierung lautet „liefert Belege für“; nichts wird bewertet oder genehmigt. Die Tests verwenden synthetische Läufe und schlagen fehl, wenn eine eingecheckte Tabelle vom Code abweicht.
• kshana bench-export <scenario.toml>. Schreibt die Fahrzeugbewegung und die Ereignisse eines Szenarios der Art gnss-ins, jamming oder gnss-sim für einen GNSS-Simulator im Labor: eine Nutzerbewegungs-CSV mit dokumentierten Bezugssystemen und einer Metadaten-Begleitdatei, NMEA 0183 GGA/RMC, Wegpunkttext und die Ereignisse als CSV und als [[events]]-Blöcke von receiver-trust (src/interop/testbench.rs). Nur Bewegung und Ereignisse: Es wird kein Signal geschrieben. Jede Datei wird in tests/interop_testbench.rs zurückgelesen und innerhalb ihrer angegebenen Toleranz verglichen. docs/TEST-BENCH.md gibt die Methode an, den Export über einen Simulator abzuspielen und das Log des Empfängers mit kshana receiver-trust zu bewerten.
• Was als Nachweis zählt. Ein Ergebnis zählt nur dann für eine Fähigkeit, wenn es die Felder trägt, die seine Art schreibt; ein Art-Label allein zählt nichts. Unbekannte Arten, ein Ergebnis, das seinem Geschwister-Szenario widerspricht, nicht hexadezimale Hashes und fehlerhafte receiver-trust-Zählungen werden als nicht verwendet aufgeführt, mit dem Grund. Der Bericht maskiert Markdown-Zellen und kann bei einem Nicht-ASCII-Hash nicht in Panik geraten. compliance::run_from_text und assess_texts nehmen Texte entgegen, keine Pfade.
• Test-bench-Export. --epoch wird auf Wertebereich geprüft (UtcEpoch::parse_iso); die Wegpunktdatei prüft jedes Intervall, und der Befehl sagt, warum, wenn eines ausgelassen wird; die Dokumentation legt dar, dass der Heading von gnss-ins der Gierwinkel des Körpers ist und nicht der Kurs, die Platzhalterfelder von GGA und die eigene Höhenänderung des Szenarios. bench-export und compliance-report stehen im Nutzungstext.
• fusion::pack::truth_trajectory legt die wahre Zustandshistorie des Fahrprofils von gnss-ins offen (dieselbe Schrittfolge, die die eigene Truth der Art verwendet), und UtcEpoch erhält NMEA-Datums- und Zeitfelder.

Validierung der Störungskarte#

• Die Dekodiersemantik und die Geometrie der Störungskarte werden an synthetischen Eingaben gegen unabhängige Implementierungen geprüft. Die Bedeutungen der NIC- und NACp-Codes gegen die pyModeS-Dekodierung synthetischer ADS-B-Frames, die AIS-Werte für „nicht verfügbar“ gegen die pyais-Dekodierung synthetischer AIVDM-Sätze, die Zuordnung zu Rasterzellen gegen shapely, die Streckenlänge je Zellzustand gegen shapely und GeographicLib sowie die Maskierung des Binnenlands gegen shapely und pyproj, jeweils mit einer Toleranz, die vor dem ersten Vergleich festgelegt wurde (tests/fixtures/interference_map_ref/PREREGISTRATION.md). Das validiert, wie Codes und Feldwerte gelesen werden, und die Geometrie, nicht aber, dass eine markierte Zelle eine Störung ist. Der Leser für Landpolygone schließt jetzt einen Ring, der seinen ersten Eckpunkt nicht wiederholt und den er zuvor ohne seine letzte Kante las. Die Dokumentation gibt die Schwellen für niedrige Genauigkeit bei NACp und NIC als die Grenze an, für die jeder Code steht (NACp 6 ist eine EPU-Grenze von 556 m, NIC 5 eine Einschlussgrenze von 1 NM).

Hinzugefügt (Validierung der Telemetrieformate und Nachweispakete)#

• Externe Prüfungen der Kryptografie der Nachweispakete, des Paket-Verifizierers und der Telemetrie-Wire-Formate. Die Ed25519-Testvektoren aus RFC 8032 Abschnitt 7,1 (1, 2, 3 und 1024) und die SHA-256-Beispiele aus FIPS 180-4 laufen durch die eigenen Signier-, Verifizier- und Hash-Funktionen des Pakets, bis zur exakten Gleichheit. Ein Verifizierer, der in Python allein aus dem normativen Abschnitt von docs/EVIDENCE-PACKS.md geschrieben wurde (hashlib und cryptography), stimmt mit dem Rust-Verifizierer bei 71 intakten und manipulierten Paketen überein: Urteil, Fehlermenge, Signatururteil und beide Kettenköpfe. Unsere Prometheus-Ausgabe wird vom Parser des offiziellen Python-Clients gelesen und unser OTLP-JSON von der offiziellen Nachricht opentelemetry-proto, streng, und beide stimmen mit dem Zustand überein, aus dem sie erzeugt wurden. CEF und LEEF haben keinen unabhängigen offenen Validator und bleiben modelliert. docs/EVIDENCE-PACKS.md hat das normative Paketformat und das Verifizierungsverfahren erhalten, aus dem der Clean-Room-Verifizierer geschrieben wurde; VerifyReport hat signature_valid erhalten. Referenzen und Fixtures: scripts/gen_ed25519_rfc8032_ref.py, scripts/gen_evidence_pack_ref.py mit scripts/evidence_verify_cleanroom.py, scripts/gen_telemetry_formats_ref.py; Tests evidence_crypto_reference, evidence_pack_reference und telemetry_formats_reference. Die CI braucht kein Python.

Hinzugefügt (Validierung der CEF-Ereignisse)#

• Die CEF-Ereignisse der Telemetrie werden von zwei unabhängigen Open-Source-Parsern korrekt zurückgelesen. pycef 1,11 und der Logstash-CEF-Codec (logstash-codec-cef 6.2.7 in Logstash 8.15.3) parsen 157 CEF-Zeilen (jeden Bandwechsel und jede Epoche des eingecheckten Telemetriestroms sowie gegnerischen Text mit =, Backslashes, Pipes, Zeilenumbrüchen, Tabulatoren und Mehrbyte-Text) und stellen jedes Headerfeld, den Schweregrad, die exakte Menge der Erweiterungsschlüssel und jeden Wert exakt wieder her. Der Logstash-Codec liest außerdem vier Zeilen, deren Headertext Escaping braucht, was pycef nicht kann. Der Zielwert wurde registriert, bevor einer der beiden Parser lief (tests/cef_reference.rs); Fixtures in tests/fixtures/cef/, Referenzskripte scripts/gen_cef_ref.py und scripts/gen_cef_logstash_ref.py; die CI braucht weder Python noch Logstash. LEEF hat keinen gepflegten offenen Parser und bleibt modelliert. Die CEF-Ereignisse tragen jetzt den Vertrauenswert und den Epochenversatz in den benutzerdefinierten Gleitkommafeldern des CEF-Wörterbuchs (cfp1, cfp2) statt in den Ganzzahlfeldern cn1 und cn2, die für keinen der beiden Werte passten; CEF ist in diesem Release neu, daher ändert sich nichts bereits Ausgeliefertes.

Geändert#

• MCP: assess_receiver_log akzeptiert das Log als text oder base64; die Tool-Eingabe ist auf 4 MiB begrenzt.
• Auch das jamming-Diagramm bezieht seine Farben aus der Palette. src/jamming.rs war das eine Modul, das die Überarbeitung der Observatory-Palette bei seinen eigenen Farben beließ, während die jammer-Q-Arbeit einging; sein *.chart.svg (die Szenarien jamming, maritime-strait-jamming und andere Szenarien der Art jamming) liest jetzt src/palette.rs, und die Allowlist in tests/palette_sync.rs ist leer. Nur Farben und Schrift: Die Diagramme jamming-demo und maritime-strait-jamming sind gleich ihren zuvor aufgezeichneten Darstellungen, sobald Farbe, font-family und die Versionsfußzeile normalisiert sind. Kein dargestellter Wert hat sich verschoben. Die aufgezeichneten Studio-Kopien unter web/studio/recorded/ wurden bei den Re-Ports von 0.33.0 und 0.34.0 neu aufgezeichnet (nur der Versionsstempel): Sie tragen noch den alten Anstrich des jamming-Diagramms und übernehmen den Anstrich der Palette beim nächsten Re-Port.

Behoben#

• Die 3-Sigma-Grenze des clock-ensemble deckt jetzt den Flicker-Boden ab, und die Filtergesundheitsprüfung sieht ihn. Mit einem flicker_floor trug die Truth-Uhr Flicker-FM, das Zwei-Zustands-Filter, das die Integritätsgrenze liefert, jedoch nicht, sodass die 3-Sigma-Abdeckung des ausgelieferten Szenarios clock-ensemble 0,41 (klassisch) und 0,33 (Quanten) betrug und die NIS/NEES-Prüfung, die ihre eigene Truth aus dem Modell des Filters zog, mit und ohne Boden identische Werte meldete. Die Grenze ist jetzt die Zwei-Zustands-Varianz plus die exakte Varianz der seit der letzten Synchronisierung aufgelaufenen Flicker-Phase, berechnet aus derselben Bank, die die Truth-Uhr verwendet; die NIS/NEES-Prüfung zieht ihre Truth aus dem erweiterten Modell mit dieser Bank und lässt das passende erweiterte Filter laufen (und das Zwei-Zustands-Filter gegen Flicker-Truth meldet consistent = false). Ausgabeänderung, nur für Uhren mit einem flicker_floor ungleich null: integrity in clock-ensemble geht von 0,40866 / 0,33026 auf 0,99970 / 1,0 (klassisch / Quanten), und die NIS/NEES von filter_health enthalten jetzt den Flicker; der Zeitfehler, holdover_s und timing_p95_ns sind unverändert, und Szenarien ohne Boden sind byte-identisch. scenarios/orbit-gnss-challenged.toml (Art orbit, Seed 7, Böden 1e-16 / 2e-11) verschiebt sich ebenfalls: fom.integrity klassisch 0,7734 auf 1,0 und Quanten 0,9796 auf 1,0, und die NIS/NEES von filter_health und ihre Bänder ändern sich. Sein Quanten-filter_health.consistent kippt von true auf false: ein Stichprobenereignis des Flicker-Ensembles aus 16 Seeds mal 60 Schritten (NIS 0,8815 gegen ein Band von [0,9125, 1,0914]), kein Defekt. Das Band ist ein 95-%-Band, sodass etwa 5 % der Seeds ein passendes Filter konstruktionsbedingt markieren (40 frische Seeds dieses Szenarios: Quanten 1 und klassisch 2 markiert); bei 64 mal 200 liegt derselbe Seed für beide Uhren im Band (NIS 0,990 und 1,001). Bekannte Nacharbeit: Die Art fusion hat dieselbe Lücke (klassische Integrität 0,80 mit einem Boden); die Art hybrid bleibt über 0,99.

[0.34.1] - 2026-10-10#

Sicherheit#

• Eingabe des MCP-Servers gehärtet. Die Szenario-Tools des MCP-Servers akzeptieren jetzt nur Inline-Inhalt und lehnen Dateiquellenfelder ab; die Eingabegröße ist begrenzt. Hinweis: GHSA-8wpf-hqg5-6xjr.

[0.34.0] - 2026-10-09#

Lab-Replay: eine Tracking-Engine, Erkennungsmonitore und ein Kampagnenläufer für GNSS-IQ-Aufzeichnungen, mit den dazugehörigen Schleifenentwürfen, C/N0-Schätzern und Bewertungen. Evidenzklasse: Alles Folgende ist MODELLED oder auf interne Konsistenz gegen geschlossene Formen und gesäte Simulation geprüft; nichts davon fügt eine Zeile der Stufe VALIDATED hinzu, und das Verifikationsregister ist unverändert (251 Zeilen: 124 validiert, 123 modelliert, 4 Partner). Es ist eine Software-Analyseschicht: Nichts hier synthetisiert eine Wellenform eines Störsenders oder Spoofers, und nichts sendet.

Hinzugefügt#

• Lab-Replay: Testbedingungen, Kampagnenläufer und Bewertung (0.34.0). kshana iq campaign <campaign.toml> spielt Aufzeichnungen × Front-End-Ketten × Schleifenentwürfe (kshana.loop-design/1) ab und bewertet jede Zelle gegen eine Testbedingungsdatei je Aufzeichnung (kshana.test-conditions/1, TOML oder JSON). Diese Datei gibt an, was ein Labor über die Aufzeichnung weiß: die erwarteten Satelliten und für jedes Ereignis sein Typ-Label, Beginn und Ende, betroffene Satelliten und das angegebene J/S- oder Störsenderleistungsprofil. Sie besteht nur aus Metadaten. Die Bewertungen je Satellit, für den ganzen Lauf und je Ereignis, sind:

  • Verfügbarkeit, Zeit bis zum Verlust der Verriegelung und das angegebene J/S beim Verlust;
  • Wiedererfassungszeit, vom Ereignisende und vom Verlust an;
  • gemessene C/N0-Degradation je Bin des angegebenen J/S;
  • Falsch-Einrast-Episoden je verriegelter Stunde (die Markierung des Trackers oder Doppler gegen eine Truth-Begleitdatei);
  • Jitter der PLL- und DLL-Diskriminatoren.

  Neben jeder gemessenen Degradationskurve ist eine analytische Referenz der spektralen Trennung (jamming::effective_cn0_dbhz mit dem Q des Typs) eingezeichnet und überall, wo sie erscheint, als MODELLED beschriftet.

  Zellen laufen parallel durch die Verriegelungs-Zustandsmaschine der Tracking-Sitzung, und jede wird atomar unter einem Inhalts-Hash-Schlüssel geschrieben. Der Schlüssel umfasst das SHA-256 der Aufzeichnung, die Hashes von Bedingung, Front-End, Entwurf, Lauf und Bewertung, die erforderliche data_class (synthetic | client-confidential) und die Engine-Version. Ist run.epochs gesetzt, werden auch der Strom kshana.track-epoch/1 und die Verriegelungsereignisse jeder Zelle aufbewahrt, nach dem Zellschlüssel benannt und in die Zelle gehasht. cell_key und report::digest sind öffentlich, sodass ein Verbraucher jeden Schlüssel und den Digest neu ableiten kann. Ein erneuter Lauf überspringt daher fertige Zellen, und Ausgaben hängen nie von der Anzahl der Worker ab. Der Lauf schreibt scorecard.csv/.json, ein eigenständiges report.html und einen DIGEST. Pass/Fail-Zielwerte ([scoring.bars], je Aufzeichnung überschreibbar) werden beim Erstellen des Berichts angewendet.

  • [scoring] cn0_estimator = "m2m4" | "nwpr" (Standard "m2m4", Teil des Bewertungs-Hashes) wählt das C/N0 hinter dem gemeldeten C/N0 und der Degradationskurve. Beide Schätzungen werden immer bewertet und gemeldet (Mediane über den ganzen Lauf und über die Basislinie sowie je J/S-Bin), und die Zelle und die Scorecard halten den Schätzer fest. NWPR liest unter dem eigenen Jitter der Schleife um etwa 8 dB × Bn·T zu niedrig; M2M4 nicht.

  Ebenfalls neu:

  • kshana iq campaign report <dir> baut die Scorecards, den Bericht und den Digest aus den Zellen neu auf;
  • kshana iq conditions <file> prüft eine Testbedingungsdatei gegen ihr Schema;
  • events_from_sigmf = true importiert die Annotationen kshana:test_event einer SigMF-Aufzeichnung als Ereignisse;
  • Python erhält iq_test_conditions, iq_campaign und iq_campaign_report;
  • kshana-mcp erhält iq_campaign, das inkrementell und unter dem Sample-Budget je Aufruf fortsetzbar ist, wobei jede Datei auf das Arbeitsverzeichnis beschränkt ist, und iq_campaign_status.

  Tests: tests/iq_campaign.rs führt eine synthetische Kampagne aus 3 Aufzeichnungen × 2 Front-Ends × 2 Entwürfen aus. Ihre Szenen tragen angegebene C/N0-Profile, und sie deckt Folgendes ab:

  • jede Metrik, geprüft gegen die eingespeiste Truth;
  • Fortsetzung nach einem teilweisen Einzel-Worker-Lauf mit einer beschädigten Zelle, byte-identisch zu einem ununterbrochenen Lauf mit vier Workern;
  • Epochendateien je Zelle;
  • eine Regression der Wiedererfassung mit drei Satelliten über 20 s: Mit eingeschaltetem reacquire ist jeder Kanal innerhalb von 2 s nach einer Lücke von 2 s zurück; das Ergebnis bei ausgeschaltetem reacquire ist festgelegt;
  • Zielwerte, die ohne erneuten Lauf neu beurteilt werden;
  • die CLI;
  • ignorierte Durchsatz- und Speicherprüfungen im Release-Modus, darunter eine Aufzeichnung von 4 GB (5,45× Echtzeit, Spitzenspeicher 2 MB über dem anfänglichen RSS; Messungen auf einer Maschine, keine Zielwerte).

  Nur Software: Nichts sendet, und es wird keine Störungs- oder Spoofing-Wellenform synthetisiert. Entwurfs- und Ist-Notizen: docs/design/LAB-CAMPAIGN.md.

• Tracking-Engine für Lab-Replay (0.34.0: B3.1, B3.2, B3.3, B6.1).

  • Schleifenentwurfsdateien: kshana.loop-design/1-TOML (docs/design/LOOP-DESIGN-TOML.md; Parser iq::track::design). Ein oder mehrere benannte Entwürfe legen jedes Schleifenfeld fest:

    • Trägerart (PLL, FLL oder FLL-gestützte PLL), Ordnungen und Bandbreiten;
    • PLL-/FLL-/DLL-Diskriminatoren und Trägerstützung;
    • Abstand und Integration;
    • Verriegelungsschwellen und C/N0-Fenster sowie Bitsynchronisation;
    • die Verriegelungs-Zustandsmaschine;
    • die Übergabe-Akquisition ("auto" oder explizit).

    Entwürfe können einander mit extends erweitern. Unbekannte Schlüssel werden abgelehnt. Jeder aufgelöste Entwurf hat einen SHA-256-Hash über eine kanonische JSON-Form (auf jeder Ebene sortierte Schlüssel, feste Zahlenformatierung), sodass der Hash nicht von der Feldreihenfolge abhängt; jede Ausgabe hält ihn fest. Oberflächen:

    • kshana iq track --design <file> [--design-name], wobei explizite Flags den Entwurf überschreiben und festgehalten werden;
    • kshana iq sweep --design <file>, das jeden Entwurf der Datei ausführt;
    • Python iq_track(design=, design_name=, reacquire=), iq_loop_designs;
    • MCP iq_track design/design_name.

  • M2M4-C/N0 (EpochOutput.cn0_m2m4_dbhz, die Spalte cn0_m2m4_dbhz der Track-Epoche nach cn0_beaulieu_dbhz; Python-Epochen-Dicts). Die Schätzung aus zweitem und viertem Moment über dieselben Fenster wie NWPR, nur aus der Prompt-Leistung: NWPR liest unter dem eigenen Trägerjitter der Schleife zu niedrig (etwa 8 dB × Bn_PLL·T), M2M4 nicht. Auf GPS L2C CM (20 ms, nominal 40 dB-Hz, PLL 1 bis 10 Hz) liest es bei jeder Bandbreite 39,93 dB-Hz, während NWPR von 39,55 auf 38,22 fällt; auf L1 C/A bei 45 dB-Hz liest es 45,34. NWPR und jede andere Ausgabe sind unverändert (eine Bit-für-Bit-Festlegung). Der binäre Datensatz bleibt bei 184 Bytes (der Wert nimmt den reservierten Float und das Flag-Bit 6).

  • Zusätzliche Korrelator-Taps (Multikorrelator / SQM). [design.integration] extra_taps_chips = [..] (Versätze in Chips vom Prompt, positiv früh; höchstens 16, jeder innerhalb von ±2) korreliert zusätzliche Replikate neben E/P/L und gibt sie als EpochOutput.extra zurück ((offset, value) in Entwurfsreihenfolge). Die Schleifen verwenden sie nie. Der Schlüssel wird aus dem kanonischen JSON weggelassen, wenn er leer ist, sodass der Hash des Standardentwurfs und jede Ausgabe ohne Taps unverändert sind (kshana.track-epoch/1 bleibt; die CSV/JSONL/Binärdaten ohne Taps sind bitidentisch). Mit Taps: CSV-/JSONL-Spalten und ein binärer Datensatz von 184 + 16 × taps Bytes, dessen Header extra_taps_chips trägt, sodass ein alter Leser die Datei ablehnt, statt sie falsch zu parsen. --extra-taps (CLI), extra_taps (Python) und extra_taps_chips (MCP iq_track). Die Entwürfe eines Laufs müssen bei den Taps übereinstimmen.

  • Parallele Kanäle (iq track / iq sweep --threads <N|auto>; Rust TrackSession::with_threads). Die Kanäle jedes Chunks laufen auf bis zu N Threads (std::thread::scope; wasm32 bleibt seriell). Die Korrelation und die Verriegelungs-Zustandsmaschine eines Kanals berühren nur diesen Kanal; seine Epochen und Ereignisse werden gepuffert und in Kanalreihenfolge in die Senken geschrieben, sodass die Ausgabe (CSV, JSONL, Binärdaten, Ereignisse, Zusammenfassung) für jedes N byte-identisch zum seriellen Lauf ist. Der Standard bleibt 1 Thread. Gemessen an einer Aufzeichnung mit 12 Kanälen, 4 s, 4,092 MHz auf 4 Kernen: 19,5 s seriell, 11,5 s bei 2 Threads, 6,3 s bei 4 (3,1×; die anfängliche Akquisition ist seriell).

  • Export der Akquisitionsfläche (kshana.acq-surface/1; iq::acq_surface, docs/design/ACQ-SURFACE.md). iq acquire --surface <path> (ein PRN; CSV, JSON oder Binärdaten), Python iq_acq_surface und MCP iq_acquire surface_out schreiben die gesamte Korrelationsleistungsfläche aus Doppler × Codephase, die die Suche berechnet (ihre Zellen sind Bit für Bit die von acquire), mit dem Maximum und zwei feinen Doppler-Verfeinerungen: einer parabolischen Schätzung und einer Feinsuche mit 1/16-Bin (≈5 Hz bei 4 ms kohärent, gegenüber Bins von 167 Hz). acquire selbst und jeder Standard sind unverändert.

  • Streaming-Epochenausgabe (kshana.track-epoch/1; iq::track::sink). Jede Schleifenaktualisierung trägt:

    • die Early-/Prompt-/Late-Korrelatoren;
    • alle drei Diskriminatorausgaben;
    • die NCO-Zustände von PLL/FLL/DLL und die Trägerphase;
    • das PLI und die Verriegelungs-Flags;
    • beide C/N0-Schätzungen und die Bits;
    • den Verriegelungszustand.

    Sie wird laufend geschrieben, als CSV, JSON Lines oder in einer versionierten Binärform, mit Lesern in Rust (BinaryEpochReader) und Python (iq_read_epochs).

    • iq track erhält --epochs, --events und --summary (kshana.track-summary/1), und iq sweep erhält --epochs und --events. MCP iq_track erhält epochs_out/events_out und baut seine Antwort aus der Zusammenfassung mit begrenztem Speicher.
    • Der Heap eines Laufs wächst nicht mehr mit der Länge der Aufzeichnung: tests/iq_track_memory.rs misst ihn mit einem zählenden Allocator (6× die Länge, derselbe Spitzenwert innerhalb von 64 KiB), mit einer Kontrolle, die zeigt, dass der In-Memory-Pfad wächst.
    • Gestreamte Ausgabe ist bitgleich mit der Wiedergabe im Speicher.

  • Lock-Zustandsautomat (iq::track::lock, TrackSession): Pull-in → Lock → verloren → Wiederakquisition → Pull-in, oder außer Dienst gestellt, sobald ein Verlust länger dauert als reacq_window_s (Standard 30 s). Fehlgeschlagene Suchen werden alle reacq_interval_s (0,1 s) wiederholt, gleichmäßig verteilt, sodass der Wiederholungsplan zu einer gemessenen Zeit der Wiederakquisition höchstens 0,1 s hinzufügt. Ein optionales Back-off (reacq_max_interval_s über reacq_interval_s) ist standardmäßig aus, und max_reacq_attempts ist eine optionale Obergrenze (0, standardmäßig keine). Ein Ausfall von 2 s bei drei PRNs mit 4,092 MS/s endet jetzt damit, dass jeder Kanal wieder akquiriert und im Lock ist. Bei einem Budget von 3 Versuchen wurde jeder Kanal innerhalb von 0,2 s nach dem Verlust außer Dienst gestellt.

    • Schwellen (loss_dwell_s, pull_in_max_s, das Doppler-Fenster der Wiederakquisition) stammen aus dem Entwurf. Jeder Übergang ist ein Ereignis mit seinem Grund.
    • Die Prüfung auf falschen Lock durchsucht den verfolgten Doppler gegen seinen FLL/PLL-Alias bei ±1/(2T). Sie fängt den falschen Lock, den PR #38 gemessen hat (−2400 Hz verfolgt, 500 Hz daneben). Bei eingeschalteter Wiederakquisition endet der Kanal im Lock beim eingespeisten Doppler.
    • Eine Signallücke von 0,8 s wird als verloren erklärt und innerhalb von 0,3 s nach der Rückkehr des Signals wieder akquiriert.
    • --summary final_state (und die Spalte der Tabelle) ist der Zustand nach dem letzten Übergang, sodass ein Kanal, der nach seiner letzten Aktualisierung der Schleife außer Dienst gestellt wurde, RETIRED zeigt.
    • FLL-Unterstützung nur während des Pull-in ([design.carrier] fll_assist = "pull-in", der Standard; "always" behält das frühere Verhalten Bit für Bit bei). Die FLL übergibt an die PLL, sobald der geglättete PLI für fll_gate_dwell_s (0,1 s) auf oder über fll_off_pli (0,8) gehalten hat, und kehrt unter fll_on_pli (0,6) zurück. Eingeschaltet gelassen, brach der FLL-Pfad mit 10 Hz bei sauberen Signalen unter etwa 38 dB-Hz den Phasen-Lock: bei 35 dB-Hz betrug der Anteil des Phasen-Locks 10–16 %, mit einem wahren Phasenfehler von 38–41°. Mit Gate hält der Standard 100 % bei 35 dB-Hz mit 4,5°, dasselbe wie eine PLL allein. Das Pull-in aus einem Übergabefehler von 100 Hz ist unverändert. Evidenz mit vorab registrierten Zielwerten: docs/design/evidence/carrier-lock/. Die Standardschleifen sind daher nicht Bit für Bit mit früheren Läufen des Standardentwurfs identisch. Verwenden Sie fll_assist = "always", um sie zu reproduzieren. Bekannte Grenze: Bei 35 dB-Hz erfolgt die Übergabe 1,9–2,6 s nach Beginn des Trackings, und bei 33 dB-Hz hält die FLL mit 10 Hz den PLI unter der Übergabeschwelle, sodass das Pull-in nie abgeschlossen wird.
    • Neue Schlüssel des Schleifenentwurfs und neue API, aufgeführt:
      • [design.carrier]: fll_assist, fll_off_pli, fll_on_pli, fll_gate_dwell_s;
      • [design.lock]: reacq_window_s, reacq_interval_s, reacq_max_interval_s, wobei max_reacq_attempts von einem Standard von 3 auf eine optionale Obergrenze (Standard 0) geändert wurde;
      • Rust: LoopConfig.fll_assist (FllAssist, FllGate), LoopCore::set_fll_enabled, EpochOutput.fll_active, ChannelSummary.final_state.
    • Der Hash des Entwurfs wird über eine kanonische JSON-Form gebildet, und der Hash des eingebauten Standards ist 33261cd171a53803a6c262686e878e01f37d902a93d5918c20a44297b8ef8e80 (durch einen Test festgelegt).
    • Hinweise zur Kompatibilität der Ausgabe:
      • die Tabelle von iq track hat eine abschließende Spalte final_state;
      • die CSV von iq sweep hat eine abschließende Spalte design_hash, und ihr JSON hat design_hash und warnings;
      • das mean_cn0_dbhz des Sweeps ist jetzt der Mittelwert über jede Aktualisierung mit einer NWPR-Schätzung (Zusammenfassung mit begrenztem Speicher), nicht mehr über die zweite Hälfte des Laufs.
    • Die Wiederakquisition ist im eingebauten Standard aus, wo der Zustandsautomat nur beobachtet und die Schleifen Bit für Bit so laufen wie ohne ihn. (Die Standardschleifen selbst haben sich jedoch geändert: siehe FLL-Unterstützung oben.) Schalten Sie sie je Entwurf ein ([design.lock] reacquire = true), mit --reacquire oder mit reacquire=True.
    • Eine Warnung commensurate_sampling: Wenn fs innerhalb von 1e-6 eines Vielfachen der halben Chiprate liegt (iq::track::commensurate_samples_per_chip), warnen iq track/iq sweep (Ausgabe, --summary, Sweep-JSON), die MCP-Antwort iq_track und das Python-Ergebnis iq_track, dass Jitter und Bias der Code-Schleife nicht repräsentativ sind. Die Ursache ist mit vorab registrierten Zielwerten in docs/design/evidence/dll-jitter/ dokumentiert. Bei genau 2 Abtastwerten je Chip mit Abstand von 0.5 Chip ist die DLL-S-Kurve eine einzelne Stufe, und die Schleife zittert: ≈ 0,09 Chip RMS Codefehler (≈ 26 m) bei 45 dB-Hz, gegen ≈ 0,004 Chip bei einer inkommensurablen Rate. Die um ~2 dB zu niedrige NWPR-C/N0 bei dieser Rate hat dieselbe Ursache. Bei genau 0 Hz Code-Doppler und 4 Abtastwerten je Chip überschreitet der Code nie die Totzone von ±0.21 Chip, sodass ein Codephasen-Bias von bis zu etwa 0,2 Chip bestehen bleiben kann, ohne im Jitter sichtbar zu werden (gemessen: Abstand von 0.5 Chip gibt das 2,0-Fache des Codefehlers der Kontrolle mit einem Mittel von +0,011 Chip; Abstand von 0.25 Chip gibt +0,125 Chip); die Warnung deckt die Rate ab.
    • Bekannte Grenze: Der Standardentwurf übergibt unter etwa 35 dB-Hz nicht von FLL an PLL (eine Pull-in-Untergrenze von ~35 dB-Hz; siehe FLL-Unterstützung oben und docs/design/evidence/carrier-lock/).
    • Eine Suche nach falschem Lock oder Wiederakquisition, die nicht laufen kann (eine Rate ohne ganze Zahl von Abtastwerten je Codeperiode), beendet das Tracking nicht mehr.
    • Tests: tests/iq_track_engine.rs, tests/iq_cli.rs, iq::track::design::tests, tests/python und der MCP-IQ-Round-Trip.

• C/N0-Profile in synthetischen Szenen (0.34.0). iq::channel::cn0_profile plant zeitveränderliche C/N0 je Satellit in den eigenen Szenen von Kshana ein, als dB-Offsets relativ zur C/N0 der Szene. Formen: Stufe, Rampe, stückweise linear und Rice-Schwunde mit Seed, die Szintillation ähneln, mit genanntem S4 und genannter Dekorrelationszeit. Sie werden über den bestehenden Kanal-Haken der Szene angewandt (Cn0ProfileChannel, zusammengesetzt mit den Effekten von Ionosphäre, Troposphäre, Szintillation und Mehrwegeausbreitung), ohne Änderung am Szenenkern. Das cn0_dbhz des Wahrheits-Sidecars folgt dem Profil.

  • Oberflächen: kshana iq scene … --cn0-profile <toml> und kshana.iq_scene(…, cn0_profile="<toml>").
  • Wofür es gedacht ist: Schleifen, Monitore und die Bewertung von Kampagnen lassen sich gegen eine bekannte Wahrheit belasten. Es ändert nur die Stärke der legitimen Signale.
  • Prüfungen (tests/iq_cn0_profile.rs). Zielwerte: mittlere Intensität des Schwunds innerhalb von 5 % von 1, S4 innerhalb von 8 % des Ziels (bei S4 = 0,3, 0,7 und 1), Intensitätskorrelation über 0,9 bei 0,05 τ und unter 0,05 bei 5 τ; die Wahrheit genau die genannte C/N0 plus das Profil; ein Abfall der verfolgten NWPR-C/N0 innerhalb von 0,7 dB einer Stufe von 6 dB. Gemessen: S4 innerhalb von 1,3 % des Ziels und ein verfolgter Abfall von 6,26 dB.

• Detektions-Monitore für den IQ-Pfad (0.34.0 „Lab replay“). Neues Modul iq::monitor, Befehl kshana iq monitor und Anbindung kshana.iq_monitor(path, ...). Sie beobachten eine Aufzeichnung und melden Zeitreihen sowie markierte Ereignisse (Start-, Alarm- und Endzeiten, Spitze, Schwelle). Sie detektieren und messen nur; nichts hier erzeugt ein Signal.

  • Gesamtleistung / AGC: Blockleistung und die Verstärkung, die eine ideale AGC anwenden würde; markiert Anstiege und Abfälle.
  • Spektrum vor der Korrelation: Welch-PSD je Block gegen eine gelernte Basislinie. Die Überschuss-Schwelle ergibt sich aus einem Fehlalarmziel. Außerdem komplexe Kurtosis und ein Pulsdetektor. Der Pulsdetektor zählt Abtastwerte über einer Schwelle in jedem Block und löst ein Ereignis aus, wenn der exakte binomiale obere Rand dieser Zahl unter pulse_pfa liegt (Standard 1e-4 je Block), nicht wenn ein z-Wert eine Grenze überschreitet: Bei den kleinen erwarteten Zahlen kurzer Blöcke liegt ein einzelner Abtastwert schon mehrere Sigma darüber.
  • C/N0 je Kanal: zwei einseitige CUSUM-Änderungsdetektoren (Abfall und Anstieg), gespeist mit unabhängigen Schätzungen (die Schrittweite wird aus dem C/N0-Fenster der Schleife gesetzt).
  • SQM aus den Korrelatoren: Delta (I_E − I_L)/I_P und Verhältnis (I_E + I_L)/(2 I_P), dazu Asymmetrietests aus zusätzlichen Korrelatoren, wenn ein Kanal sie liefert.
  • Lock-Indikator-Reihen: PLI und ein Frequenz-Lock-Indikator aus aufeinanderfolgenden Prompts, als Rohsignale. Entscheidungen über Lock und Lock-Verlust bleiben beim Lock-Zustandsautomaten der Tracking-Engine.

  Ein einziger streamender Durchlauf (iq::monitor::run::run_monitors) führt alles aus, mit einer TOML/JSON-Einstellungsdatei (MonitorConfig); der Kampagnen-Runner verwendet denselben Einstiegspunkt. Alles MODELLED. Jede Statistik wird durch Simulation mit Seed gegen ihre geschlossene Form geprüft (tests/iq_monitor.rs):

  • Überschreitungen der Blockleistung gegen den Gamma-Rand;
  • Kurtosis-Mittel 2 und Streuung 2/√N;
  • Pulsanteil e^{−t};
  • Lauflängen der CUSUM gegen die Näherung von Siegmund (gemessen 330 und 8,46 Abtastwerte gegen 338 und 8,34);
  • der Phasen-Lock-Indikator gegen das Mittel der Rice-Phase;
  • bei einem verfolgten C/A-Signal weichen die Streuungen von SQM-Delta und -Verhältnis um etwa 6 % von den Formen in geschlossener Form erster Ordnung ab (gemessen 5,97 %; Zielwert des Tests 12 %).

  Die Formel für den Fehlalarm bei spektralem Überschuss ist eine Näherung; die gemessene Rate war das 1,3-Fache der Formel. Von Ende zu Ende markieren die Monitore:

  • eine C/N0-Stufe von 6 dB (Zeitpunkt der Änderung innerhalb einer Schätzung);
  • einen reflektierten Pfad, der in der Mitte der Aufzeichnung erscheint (Verhältnistest);
  • einen Signalausfall (PLI fällt dabei von 0,999 auf −0,3 und FLI von 0,93 auf 0,03);
  • einen Schmalbandton und vereinzelte Abtastwerte mit hoher Amplitude (Spektral-, Puls- und Kurtosis-Tests). Das sind generische DSP-Testeingaben, keine Störungsmodelle.

Geändert#

• iq track/iq sweep streamen durch die neue Sitzung (siehe Hinzugefügt).
  • --csv behält seine Spalten von 0,32, wird aber jetzt gestreamt, sodass sich Zeilen mehrerer Kanäle in zeitlicher Reihenfolge verschränken, statt nach Kanal gruppiert zu sein. --json behält seine Form von 0,32 und hält weiterhin jede Epoche im Speicher: Verwenden Sie --epochs für lange Aufzeichnungen.
  • iq sweep misst den Jitter über die Aktualisierungen in der zweiten Hälfte der Dauer des Laufs (zuvor die zweite Hälfte der Zahl der Aktualisierungen), und seine CSV/JSON erhalten eine Spalte design_hash.
  • Die Track-Tabelle erhält eine Spalte final_state.
  • Der Hilfetext behauptet nicht mehr, dass iq track die Front-End-Flags annimmt; nur iq acquire wendet sie an.
  • acq_noncoherent und doppler_max von Python iq_track haben jetzt None als Standard (die Werte des Entwurfs, 1 und 5000 Hz im eingebauten Entwurf). Seine Epochen erhalten die Early-/Late-Korrelatoren, carrier_phase_cycles, bit_edge, bit und state, und das Ergebnis erhält design und events.

Behoben#

• Der Standard-Akquisitionsschritt übergibt dem Tracking von Galileo E1 kein Residuum mehr, das die FLL nicht einziehen kann. Der Schritt 2 / (3 · N · T_code) lässt bei der Übergabe bis zu 1 / (3 · N · T_code) Doppler-Fehler, aber die standardmäßige Zwei-Quadranten-FLL zieht nur 1 / (4 T_track) ein. Bei jedem Code von 4 ms oder länger (N = 1), einschließlich Galileo E1-B und E1-C, lag das Residuum (83,3 Hz bei 4 ms) außerhalb des Pull-in von 62,5 Hz, und das Tracking rastete bei +125 Hz falsch ein, mit einem Phasen-Lock-Indikator von 0,97, der es verdeckte. Der Standardschritt wird jetzt außerdem auf 0.2 / T_track begrenzt (kshana::iq::acq::default_step_hz), 0,8 des Pull-in, sodass die Übergabe innerhalb davon bleibt, auch wenn der benachbarte Bin gewinnt. (0,4 wurde zuerst versucht: Es rastete bei E1-B in 1 Lauf von 42 falsch ein, und eine kohärente GPS-L1-C/A-Suche mit 1 ms wählte einen Bin mit 350 Hz Abstand und rastete bei +500 Hz ein; 0,25 und 0,2 hatten in denselben Läufen keinen.) Kosten: Galileo E1-B/E1-C gehen von Bins mit 166,7 Hz auf 50 Hz, 201 Bins über ±5 kHz statt 61; die Codes mit 1 ms (166,7 Hz, N = 4) bleiben unverändert. "auto" in einem Schleifenentwurf bedeutet dies; ein ausdrücklicher Wert doppler_step_hz oder --doppler-step wird wie geschrieben verwendet, und iq acquire (keine Tracking-Übergabe) behält den Lehrbuchschritt. Der Epochen-Header und --summary halten jetzt für jeden Kanal den aufgelösten Schritt und die Schleifenbandbreiten fest (resolved). Der Hash des Standardentwurfs ist unverändert. Änderung der Ausgabe: Detektionen bei Codes von 4 ms und länger können auf anderen Doppler-Bins landen.

• GPS L2C CM (Schleifenaktualisierung von 20 ms) hält den Lock mit dem Standardentwurf. Die standardmäßige PLL mit 15 Hz und FLL mit 10 Hz haben Bn · T von 0,3 und 0,2 bei T = 20 ms, und die Schleife verlor den Lock sogar bei perfektem Start (PLI −0,08, M2M4 15,8 dB-Hz). Neuer Entwurfsschlüssel carrier.bn_t_max (Standard 0,1) begrenzt die Rauschbandbreiten von PLL und FLL auf bn_t_max / T, wenn die Aktualisierungszeit der Schleife länger als 4 ms ist (Design::loop_config_for): 5 Hz und 5 Hz bei 20 ms, 10 Hz und 10 Hz bei 10 ms von BeiDou B1C; die Codes mit 1 ms und 4 ms behalten 15 und 10 Hz. Es gilt auch für ausdrückliche Bandbreiten; bn_t_max = 0 schaltet es ab. Der Schlüssel entfällt in der kanonischen Form bei seinem Standard, sodass der Standard-Hash unverändert ist; ein Entwurf, der einen anderen Wert setzt, hat einen anderen Hash. Bei 45 dB-Hz ergibt L2C CM jetzt PLI 0,996, Doppler-Fehler 0,00 Hz und M2M4 42,71 dB-Hz. Bekannter offener Punkt: Die NWPR-C/N0 liegt dort 1,76 dB zu niedrig (und 2,45 dB zu niedrig bei B1C mit 10 ms), sodass T5 der Matrix für L2C ein ignorierter Befund bleibt.

• docs/assets/clock-ensemble-band.svg neu erzeugt: Die eingecheckte Abbildung war gegenüber ihrem eigenen Szenario veraltet (eine Datenänderung, kein Neuzeichnen). Das Diagramm wurde am 2026-06-02 aus scenarios/clock-ensemble.toml gezeichnet; zwei Tage später setzte 67fed19e die Flicker-FM-Böden in diesem Szenario (Quanten flicker_floor = 1e-16, CSAC flicker_floor = 2e-11), und die Abbildung wurde nie neu gezeichnet. Sie zeigte den Lauf vor den Böden: y-Achse 0 bis 47 ns, Ausfall-p95 je Lauf bei CSAC von 10,5 bis 47,6 ns (Mittel 25,2 ns), klassischer Holdover 4050 s im Mittel. Das ausgelieferte Szenario (und wie schon Tutorial und CLI-Zusammenfassung angeben) ergibt eine y-Achse von 0 bis 407 ns, p95 je Lauf bei CSAC 40,8 bis 374,0 ns (Mittel 167,0 ns), klassischen Holdover 844 s [220 bis 2130 s]; die Spezifikationslinie von 20 ns liegt bei denselben 20 ns auf einer etwa neunmal höheren Achse. Die Engine ist unverändert: Die heutige Engine reproduziert mit der Szenariodatei von Juni exakt die Achse der alten Abbildung. Auf die Abbildung wird weder aus der README noch aus der Dokumentation verwiesen.

Bekannte Einschränkungen#

• Die NWPR-C/N0 liest bei hoher C/N0·T je Prompt zu niedrig, und BOC(1.1) bei 5 MS/s verliert etwa 1 dB. NWPR ist bei idealen Prompts unverzerrt, aber der eigene PLL-Jitter der Schleife kostet etwa einen angepassten Wert von 8 dB × Bn·T (eine Szene, vier Punkte: −0.24/−0.44/−0.77/−1,58 dB bei 1/2.5/5/10 Hz und 20 ms; etwa −1 dB beim Standard bn_t_max = 0.1); M2M4 ist unempfindlich. BeiDou-B1C-Daten bei 5 MS/s verlieren durch die Bandbegrenzung ebenfalls etwa 1 dB Prompt-Leistung (verwenden Sie 10 MS/s oder mehr). Keines von beiden ist ein Defekt des Schätzers; die Zeilen T5 der Signalmatrix für GPS L2C und BeiDou B1C bleiben ignorierte Befunde mit diesen Ursachen.

[0.33.1] - 2026-10-08#

Sicherheit#

• Diagrammtext und Übernahme von Diagrammen im Studio gehärtet. Text, den ein Szenario in ein erzeugtes Diagramm trägt, wird jetzt von einer gemeinsamen Routine einheitlich maskiert, und das Studio übernimmt aus einem Diagramm nur Zeichenmarkup. Die Adressparameter des Studios, Nachschlagen nach Art und Abrufe von Szenarien sind auf bekannte Werte beschränkt. Mitgelieferte Diagramme, aufgezeichnete Ergebnisse und veröffentlichte Zahlen bleiben unverändert. Ein Upgrade wird allen empfohlen, die Szenariodateien aus nicht vertrauenswürdigen Quellen im Studio öffnen oder erzeugte Diagramme in Webseiten einbetten. Sicherheitshinweis: GHSA-h25h-cg9f-v2cg.

[0.33.0] - 2026-10-08#

Dokumentation#

• Der Umfang der IQ-Schicht bei Störung und Spoofing, genau angegeben. Die Einträge von 0.31.0 und 0.32.0 unten sagen, die IQ-Schicht füge „keine Synthese von Störungs- oder Spoofing-Wellenformen“ hinzu. Das stimmt für die IQ-Schicht selbst (iq::scene erzeugt nur legitime GNSS-Signale), las sich aber wie eine Aussage über die ganze Engine, und das ist sie nicht: Seit 0.29.0 schreibt der Abschnitt [iq] der Art spectrum einen SigMF-Schnappschuss seines analytischen Modells mit den konfigurierten Jammern darin (rauschartige Jammer Bin für Bin, Töne und Chirps als Wellenformen), und spoof_capture summiert ein authentisches und ein Spoofer-Replikasignal im Speicher, um den Capture der Schleife zu testen (das Verbundsignal wird nie ausgeschrieben). Die Engine trägt außerdem seit 0.20.0 einen Software-GNSS-Empfänger (sdr: Akquisition und Tracking; seit 0.31.0 auch iq::acq und iq::track). Nichts in Kshana sendet oder steuert Funkhardware. Die Statuszeile der README, docs/POSITIONING.md, docs/SPECTRUM.md und die IQ-Entwurfsnotizen sagen das jetzt; die veröffentlichten Einträge bleiben so, wie sie veröffentlicht wurden. Kein Verhalten ändert sich.
• Bekannte Einschränkung: kommensurable Abtastung. Bei einer Abtastrate, die ein ganzzahliges oder halbzahliges Vielfaches der Chiprate ist, liegen die Abtastwerte in jedem Chip auf denselben Chipphasen, und der Code-Diskriminator wird zu einer Treppe. Bei einem synthetischen GPS-L1-C/A-Signal mit 45 dB-Hz und Abstand von 0.5 Chip gibt 2,046 MHz (2 Abtastwerte/Chip) ≈ 0,09 Chip (≈ 26 m) RMS Codefehler und einen Bias von −0,09 Chip, gegen ≈ 0,003 Chip bei einer inkommensurablen Rate. Die NWPR-C/N0 liest dort ≈ 2,4 dB zu niedrig. Bei 4,092 MHz hängt es vom Abstand und vom Code-Doppler ab. Bei 0,5 Chip ist es bei 1500 Hz Doppler harmlos, aber 2× bei 0 Hz mit einem Bias von 0,011 Chip, und bei 0,25 oder 0,1 Chip ist es das 8–10-Fache des Codefehlers. Das Carrier-Tracking ist nicht betroffen. docs/design/iq-notes/receiver.md enthält die Messungen.

Hinzugefügt#

• GNSS-IQ-Schicht auf dem MCP-Server (Phase B.1). kshana-mcp erhält sechs Werkzeuge, die die Schicht kshana iq von einem Agenten aus ansteuern: iq_signals (die akzeptierten Signalnamen und die IQ-Einrichtung), iq_info (eine Aufzeichnung beschreiben), iq_scene (eine Szene mit genanntem Profil oder aus Broadcast-Ephemeriden erzeugen, mit dem optionalen Kanal auf Signalebene), iq_acquire (FFT-Akquisition, wahlweise hinter Front-End-Stufen), iq_track (akquirieren, dann die Bank aus DLL/PLL/FLL) und iq_frontend (Bandpass, Notch, Blanking, Excision, AGC, Quantisierer). IQ-Abtastwerte überqueren nie das Protokoll: Jedes Werkzeug nimmt Dateipfade innerhalb eines Arbeitsverzeichnisses, das über KSHANA_MCP_IQ_DIR gesetzt wird (nicht gesetzt, bleiben die IQ-Dateiwerkzeuge aus und jedes andere Werkzeug unberührt), lehnt Pfade, die außerhalb davon auflösen, und bereits vorhandene Ausgaben ab, sofern nicht overwrite gesetzt ist, erzwingt vor jeder Arbeit ein Abtastwert-Budget je Aufruf (KSHANA_MCP_IQ_MAX_SAMPLES, Standard 50.000.000), lehnt unbekannte Argumente ab und antwortet mit einer kompakten JSON-Zusammenfassung (Detektionen, C/N0, Lock-Zustand und jede geschriebene Datei mit ihrer Byte-Zahl). Die Ausgabe je Epoche geht nur in Dateien, die der Aufrufer benennt. Die Werkzeuge führen über eine neue öffentliche Naht, kshana::iq::cli::execute, denselben Codepfad aus wie die CLI, die die Meldung der CLI zurückgibt, statt sie zu drucken (stdout ist der JSON-RPC-Kanal von MCP); iq::cli::build_code und iq::cli::signal_names sind jetzt ebenfalls öffentlich. Nur Software und additiv: Die IQ-Schicht fügt keine Synthese von Störungen oder Spoofern hinzu, nichts wird je gesendet, und es gibt keine neuen Abhängigkeiten. server.json erklärt die beiden Umgebungsvariablen. Round-Trip-Tests in mcp/kshana-mcp/tests/iq_round_trip.rs erzeugen eine kurze Szene mit zwei Satelliten und prüfen die Akquisition gegen das eigene Wahrheits-Sidecar der Szene, Tracking-Lock und C/N0, das Front-End, die SigMF-Ausgabe, das Budget, die Pfadbeschränkung und den deaktivierten Zustand.

• Die GNSS-IQ-Schicht im Validierungsregister. Eine vorab registrierte Kreuzprüfung gegen gps-sdr-sim (ein unabhängiger GPS-L1-C/A-Basisbandgenerator, MIT, Commit 28ca29a6) ist jetzt Teil der stets laufenden Testsuite (tests/iq_gpssdrsim_cross_generator.rs). Ihre eingecheckte Referenzausgabe (tests/fixtures/iq_gpssdrsim_cross_generator/: 20 ms des eigenen 8-Bit-I/Q von gps-sdr-sim, seine Kanalliste und der Kanalzustand dahinter aus einem Harness, das gegen denselben Build gelinkt ist) wird von scripts/gen_iq_gpssdrsim_ref.sh neu erzeugt. Nichts zur Testzeit braucht Netz oder das externe Werkzeug. Zwei Registerzeilen werden hinzugefügt (251 Zeilen: 124 validiert, 123 modelliert, 4 Partner):

  • Signalgeometrie der GNSS-IQ-Szene gegen einen unabhängigen Basisbandgenerator: Validiert. Die Wahrheit der Szene (sichtbare Menge, Pseudoentfernung, Codephase, Doppler, Blickwinkel) für eine Szene aus Broadcast-Ephemeriden stimmt auf allen 11 Kanälen mit dem Kanalzustand von gps-sdr-sim überein: schlechtester Wert 1,6 mm, 5.5e-6 Chip, 7.4e-5 Hz, 4e-9 Grad, gegen Zielwerte von 0,05 m, 2e-4 Chip, 0,02 Hz und 1e-4 Grad, die vor dem Lauf festgelegt wurden.
  • GNSS-IQ-Akquisition an unabhängig erzeugten I/Q-Abtastwerten: Modelliert, mit einem Befund. iq::acq findet jeden simulierten Satelliten in den Abtastwerten von gps-sdr-sim innerhalb der registrierten Zielwerte (Codephase innerhalb von 0,195 Chip, Doppler innerhalb von 72 Hz). Der registrierte Zielwert „kein anderer PRN detektiert“ scheitert allerdings: Bei der rauschfreien Ausgabe von gps-sdr-sim wird die Schwelle für gaußsches Rauschen von der Kreuzkorrelation der anderen Satelliten für alle 21 abwesenden PRNs überschritten. Der strikte Test bleibt erhalten, mit dem Befund ignoriert, und ein festgelegter Test hält ihn fest. Kein Engine-Code und keine öffentliche API ändert sich. Das Abtastwert-I/Q wird nicht Abtastwert für Abtastwert verglichen: Die ganzzahlige Sinustabelle von gps-sdr-sim, Verstärkungen, die anfängliche Trägerphase null und abgeschnittene LNAV-Felder sind keine Größen, in denen ein Empfänger übereinstimmen muss. Der Vergleich erfolgt an den Observablen, die ein Empfänger misst.

Geändert#

• iq track übergibt standardmäßig aus einer Akquisition von ≈4 ms (Verhaltensänderung). Die Akquisition, die jeden Tracking-Kanal initialisiert, integriert jetzt ceil(4 ms / T_code) Codeperioden kohärent statt einer, wobei T_code die volle Periode des Codes ist (Primär- mal Sekundärlänge bei einem gestuften Code, die Einheit, über die die Akquisition integriert). Die ungestuften Codes mit 1 ms (GPS L1 C/A, BeiDou B1I, GLONASS L1OF) durchsuchen jetzt 4 Perioden (4 ms), sodass der Standard-Dopplerschritt 2 / (3 · N · T_code) ~167 Hz statt ~667 Hz beträgt. Jeder Code, dessen volle Periode bereits 4 ms oder länger ist, behält 1 Periode: Galileo E1-B (4 ms), BeiDou B1C (10 ms) und die gestuften GPS L5-I/L5-Q, Galileo E5a-I/E5a-Q und E1-C (10 bis 100 ms mit ihren Overlay-Codes) sowie GPS L2C. Jedes Signal integriert daher mindestens ~4 ms. Eine Suche mit einer Periode konnte einen Kanal mit bis zu ~333 Hz Abweichung übergeben, außerhalb des Pull-in der FLL, und er verfolgte dann einen falschen Lock ~500 Hz entfernt und meldete dabei ein sauberes Tracking. Bei einem Sweep mit Seed über 180 GPS-L1-C/A-Kanäle (Doppler über ±5 kHz, 38 bis 47 dB-Hz, die Hälfte mit Navigationsdaten; docs/design/evidence/iq-track-acq-default/, wiederholbar) sinken falsche Locks von 27 von 180 auf 1 von 180 und verpasste Akquisitionen von 102 auf 11, bei ~40 ms mehr Suche je PRN auf GPS L1 (11 → 52 ms). Der eine verbleibende falsche Lock liegt bei 38 dB-Hz, 36 Hz daneben. Jede Oberfläche stimmt überein: kshana iq track und kshana iq sweep (--acq-coherent), Python kshana.iq_track (acq_coherent=None ist jetzt automatisch; Stub aktualisiert) und das MCP-Werkzeug iq_track. Wer sich auf den alten Standard verlassen hat, kann acq_coherent=1 übergeben (--acq-coherent 1). Der eigene Standard --coherent von kshana iq acquire bleibt 1. Neue öffentliche iq::acq::auto_coherent_periods und iq::acq::AUTO_COHERENT_S; Regressionstest tests/iq_cli.rs::track_default_handoff_does_not_false_lock_where_one_period_did.
• Jede erzeugte Grafik folgt jetzt dem Observatory-Design der Website: Die Bytes jedes Diagramms ändern sich. Das ist eine bewusste Überarbeitung der veröffentlichten Abbildungen, nur bei Farben und Schriften; kein gezeichneter Wert, keine Koordinate und kein Label hat sich bewegt. Das *.chart.svg jedes Szenarios (und damit die Diagrammexporte des Studios und die Demo-Diagramme der README), das HTML des Laufberichts (*.report.html), die Zeitleisten-Animation (--animate), die HTML-Seiten für Szenarioergebnisse und Studien, die Validierungszusammenfassung und die Abbildungen und Diagramme der Dokumentation verwendeten die warm-dunkle Palette vom Juli (Grund #0c0b08, Gold #e0bd84) und ein warmes Papier-Design für Berichte. Sie nehmen jetzt jede Farbe und Schrift aus einem einzigen Modul, src/palette.rs, das web/theme.css spiegelt: Diagramme werden instrumentendunkel auf dem Observatory-Grund (#060A14) im Schriftstapel Geist gezeichnet; der Bericht, der Animationsplayer und die Ergebnisseiten folgen der Hell/Dunkel-Einstellung des Betrachters mit den hellen und dunklen Tokens des Observatory. Die sechs Fehlerdomänen behalten je eine Farbe (Störung Koralle, Spoofing Magenta, Zeitgebung Blau, Bahnen Cyan, Integrität Limette, Navigation Bernstein), und die Evidenzstufen lesen sich validiert Limette, modelliert Bernstein, Partner Magenta. Die Rampen des Wasserfalls behalten ihre wahrnehmungsbasierte Ordnung (Inferno), neu verankert am neuen Grund.
  • tests/palette_sync.rs hält das Modul in beiden Designs auf web/theme.css, prüft, dass docs/assets/palette.json und docs/diagrams/mermaid-config.json (beide aus dem Modul erzeugt, für die Python-Abbildungswerkzeuge und mermaid-cli) aktuell sind, und schlägt fehl, wenn ein Hex-Farbliteral in src/ außerhalb der Palette auftaucht.
  • tests/published_figures_still_reproduce.rs erhält eine dritte Diagnose, „nur Farben und Schriften haben sich bewegt“, sodass eine Palettenrevision von einem verschobenen gezeichneten Wert unterschieden wird. Jedes neu gerenderte README-Diagramm wurde unter diesem Normalisierer als gleich mit seinem Vorgänger geprüft.
  • tools/gen_validation_figures.py liest die Palette und erzeugt jetzt auch die drei README-Ergebnisabbildungen, die keinen eingecheckten Generator hatten (domain-coverage-map, scenario-fom, sgp4-regime-bars), mit echten Textelementen, aus web/capabilities.json, dem Ergebnis von clock-holdover und tests/fixtures/sgp4_comparison.md. tools/gen_readme_assets.py liest dieselbe Palette, was seine Abweichung des hellen Designs von der Website korrigiert. Die Werte von sgp4-regime-bars sind die Spalte des schlechtesten Falls kshana↔ref dieser Fixture (7.31e-9, 8.05e-9, 8.18e-9 und 4.12e-6 km), unverändert gegenüber der Matplotlib-Abbildung, und tests/figures_doc_sync.rs schlägt jetzt fehl, wenn die eingecheckte Abbildung und die Fixture nicht übereinstimmen.
• docs/assets/figures/domain-coverage-map auf aktuelle Daten aktualisiert (eine Datenänderung, kein Neuzeichnen). Die Abbildung nannte 28 Fähigkeiten in 8 Domänen (11 validiert, 17 modelliert), veraltet gegenüber ihrer eigenen genannten Quelle; jetzt von ihrem neuen Generator aus web/capabilities.json gezeichnet, nennt sie 46 Fähigkeiten in 8 Domänen (17 validiert, 29 modelliert).

Behoben#

• Q des CW-/Schmalband-Jammers ist jetzt 1,0, nicht 1,5. Der Lehrbuchwert für einen Ton auf dem Träger ist 1 (ein Ton behält die spektrale Spitze des Signals, κ = T_c, Q = 1/(R_c κ)); der alte Wert 1,5 machte einen Ton bei gleichem J/S weniger schädlich als Breitbandrauschen. Änderung der Ausgabe: etwa −1,8 dB effektive C/N0 bei CW-/Schmalband-Jammern mit hohem J/S in den Arten jamming, lunar-jamming und interop (der Ton des mitgelieferten Beispiels spectrum: 17,98 dB-Hz aus der Tabelle, vorher 19,74). Das Q für Breitband bleibt 1,0 (konservativ, etwa 3 dB unter dem Lehrbuchwert ~2), bis die Prüfung von 0,34 vorliegt. Setzen Sie q_override, um den alten Wert 1,5 zu behalten.

• Die Ganzzahlausgabe von kshana iq scene nutzt den ganzzahligen Bereich. Mit Rauschen mit Einheitsleistung und einer Schreiber-Skala von 1 kamen die Szenen ci8/ci16 als etwa {-1, 0, 1} heraus, und Szenen mit 2 Bit hatten ihre Schwellen bei 2,8 Sigma. Ganzzahlformate werden jetzt so skaliert, dass der erwartete RMS je Komponente ein Viertel des Vollausschlags beträgt (31,75 LSB bei ci8, 8191,75 bei ci16) oder 2 LSB bei 2 Bit. Die Skala und die Zahl der abgeschnittenen Elemente werden gedruckt und in das Sidecar geschrieben. Die Float-Ausgabe ist unverändert.

• Acht Fixture-Pins in sieben Testdateien schlagen unter macOS nicht mehr wegen Unterschieden im letzten Bit fehl (Teil von Issue #36). Die Pins, die prüfen, dass die Engine die eingecheckten Eingaben einer unabhängigen Referenz noch aufbaut (Jacobi-Matrizen, eine Zustandstabelle, Startazimute), verglichen Bit für Bit und schlugen unter macOS arm64 um 2 bis einige tausend Einheiten in der letzten Stelle fehl. Sie vergleichen jetzt innerhalb von 1e-12 einer aus der Fixture genommenen Skala; Ganzzahlen, Schlüssel und Längen werden weiterhin exakt verglichen, und ein Mutationstest zeigt, dass eine relative Änderung von 1e-6 weiterhin fehlschlägt. Der Pin für den Startazimut vergleicht sin az und den aufsteigenden/absteigenden Zweig statt des Azimuts selbst, weil asin ein Ulp seines Arguments auf etwa 3e-9 rad verstärkt, wo eine Inklination der Kobreite eines Standorts entspricht. Keine Toleranz einer unabhängigen Referenz und kein vorab registrierter Zielwert hat sich geändert. Zwei Tests (lunare gemeinsame Bahnbestimmung, lunare Beobachtbarkeit) sind nicht abgedeckt: Unter macOS verschieben sich ihre vorab registrierten Vergleiche selbst, und das bleibt einem Folgeschritt überlassen.

• kshana iq track und kshana iq sweep wenden die Front-End-Flags an. Der Hilfetext bewarb --bandpass/--notch/--blank/--excise/--agc/--bits bei track, aber track und sweep bauten die Kette nie auf: Die Flags wurden stillschweigend ignoriert, und ein Flag ohne Wert wie --notch verschluckte das Flag danach. Beide Befehle parsen sie jetzt wie iq acquire und setzen eine frische Front-End-Kette vor den Akquisitionsdurchlauf und den Tracking-Durchlauf. Die Ausgabe entspricht dem Ausführen des Befehls auf der Datei, die iq frontend für dieselben Flags schreibt.

• IQ-Szenendaten werden je Signal platziert. kshana iq scene --data (und NavData::Seeded) legen Bits mit 50 bit/s auf jedes Signal, Pilotsignale eingeschlossen, und mit der GPS-LNAV-Rate auf Galileo und BeiDou. Die Daten folgen jetzt dem eigenen Symboltakt jedes Signals, angegeben durch das neue SpreadingCode::data_modulation() (DataModulation, gesetzt von jedem Konstruktor in iq::signals). Das sind 10 ms bei L5-I5, 4 ms bei E1-B, 2 ms bei BeiDou B1I GEO (D2) und Bits mit 20 ms mit einem Mäander von 10 ms bei GLONASS L1OF. Daten werden bei Pilotsignalen abgelehnt, bei GPS L2C als einem CM/CL-Strom, und NavData::Lnav bei allem außer L1 C/A. Benutzerdefinierte Codes behalten standardmäßig den früheren Takt von 20 ms. Eine programmatische Scene, die NavData::Lnav bei einem Code, der nicht L1 C/A ist, oder NavData::Seeded bei einem Pilotsignal verlangte, erzeugte früher stillschweigend und gibt jetzt beim ersten Lesen einen Fehler zurück.

• GLONASS-L1OF-Kanäle werden auf ihrem eigenen FDMA-Träger akquiriert und verfolgt. iq::acq::acquire und die Tracking-Kanäle mischten jeden Code allein von if_hz herunter. In einer GLONASS-Aufzeichnung mit mehreren Kanälen fand eine Suche nach Kanal +3 daher das Signal von Kanal 0 (alle Kanäle teilen sich einen Entfernungscode) und schaute nie 1,6875 MHz höher. Beide verwenden jetzt SampleSpec::baseband_hz(carrier) = if_hz + (carrier − center_hz). Der Trägerterm ist null für jede Aufzeichnung, die auf dem eigenen Träger des Signals zentriert ist, und entfällt, wenn die Mitte unbekannt ist, sodass die CDMA-Verarbeitung unverändert ist. Wenn Sie das alte Verhalten umgangen haben, indem Sie carrier − center in das if_hz des Sidecars eingerechnet haben, entfernen Sie diesen Term: Der Versatz wird jetzt aus Träger und Mitte angewandt, sodass er bei Beibehaltung zweimal angewandt wird. Bekannte Einschränkung, hier unverändert: Eine GLONASS-Szene identifiziert jeden Satelliten über seinen Frequenzkanal k, und die Satelliten-ID u32 umbricht einen negativen Kanal. Das Wahrheits-Sidecar schreibt k = -7 als sat_id 4294967289 (k + 2^32). Lesen Sie ihn als k mit einem Cast auf i32 zurück.

[0.32.0] - 2026-10-05#

Hinzugefügt#

• GNSS-IQ-Schicht in CLI und Python (0.32.0 Phase A). Das bestehende Modul iq ist jetzt ohne Rust-Programmierung nutzbar. Fünf neue Befehle kshana iq kommen zur Gruppe der Datenverarbeitung hinzu: scene erzeugt eine lange IQ-Szene mit mehreren Satelliten in eine Datei, mit einem Wahrheits-Sidecar; acquire führt FFT-Akquisition eines oder mehrerer PRNs über eine Aufzeichnung aus und meldet jede Detektion (PRN, Doppler, Codephase, Statistik, Schwelle); track akquiriert und lässt dann die Bank aus DLL/PLL/FLL über eine Aufzeichnung laufen und gibt das Tracking je Epoche aus (CSV/JSON), mit konfigurierbaren Schleifenbandbreiten, Integrationszeit und Korrelatorabstand; sweep spielt eine Aufzeichnung über mehrere Schleifenentwürfe ab und meldet den resultierenden Jitter und die Lock-Kennzahlen je Entwurf; und labfit passt das Lock-Verlust-Modell der Tracking-Schleife an eine Zeitreihe des Empfänger-Vertrauens an. Derselbe Kern wird Python zugänglich gemacht (kshana.iq_scene, iq_acquire, iq_track, iq_labfit, iq_signals) und liefert NumPy-freundliche Listen und Wörterbücher. Nur Software und additiv: keine neuen Abhängigkeiten, kein Senden, keine Synthese von Störungs- oder Spoofing-Wellenformen; Engine, Akquisition, Tracking und Schleifenentwürfe sind die eigenen des Crates, sodass ein Aufrufer von CLI oder Python dieselben Bits erhält wie die Rust-Tests. Neues Modul iq::cli; das eigene Wahrheits-Sidecar der Szene ist die unabhängige Referenz in tests/iq_cli.rs (die Akquisition gewinnt jede eingespeiste Codephase und jeden Doppler zurück, das Tracking konvergiert zum eingespeisten Doppler). Keine veröffentlichte Zahl von Szenarioarten und keine Zeile der Verifikationsmatrix ändert sich.
• Übrige Fähigkeiten der GNSS-IQ-Bibliothek in der CLI iq und in Python (0.32.0 Phase A.2). Baut auf Phase A auf und macht den Rest der Schicht iq ohne Rust-Programmierung zugänglich:
  • Ausbreitungskanal bei iq scene (und im Python-iq_scene): eine Ionosphäre erster Ordnung (--iono-stec/--iono-vtec oder --iono-klobuchar), die Troposphäre nach Saastamoinen/Niell (--tropo), das Cornell-Szintillationsmodell (--s4, --scint-tau0, --sigma-phi), spekulare Mehrwegeausbreitung am Boden (--multipath-height/--multipath-ground), der Land-Mobil-Kanal mit drei Zuständen (--land-mobile) und ein Block ohne Sichtverbindung (--nlos) wirken über eine neue crate-interne Brücke (iq::channel::SceneChannelAdapter), die die absoluten Pfade der Kanalmodelle in die Überschuss-über-Geometrie-Form der Szene umwandelt, auf jeden Satelliten.
  • SigMF-Ausgabe bei iq scene (--format sigmf): schreibt die Abtastwerte als Paar .sigmf-data/.sigmf-meta mit einem Capture und Annotationen je Satellit; acquire/track lesen SigMF bereits, sodass eine Szene den Round-Trip besteht.
  • Front-End-DSP: ein neuer Befehl iq frontend <in> <out> und dieselben Flags bei acquire/track (--bandpass, --notch, --blank, --excise, --agc, --bits 1/2/3/8/14) führen die Stufen von iq::frontend aus (Bandpass-FIR, adaptiver Notch, Pulsaustastung, Excision im Frequenzbereich, AGC, Quantisierer); in Python gespiegelt als iq_frontend.
  • Szenen aus Broadcast-Ephemeriden: iq scene --nav <rinex_nav> --rx-pos lat,lon,alt (mit --start/--window/--prn) setzt mit dem RINEX-Leser der Engine jeden gesunden GPS-Satelliten auf seine wahre Broadcast-Geometrie, sodass das Wahrheits-Sidecar die reale Entfernung, den Doppler und die Codephase je Satellit trägt; in Python gespiegelt als iq_scene_broadcast. Nur Software und additiv: keine neuen Abhängigkeiten, kein Senden, keine Synthese von Störungs- oder Spoofing-Wellenformen (Ausbreitungseffekte des Kanals wirken nur auf das legitime Signal). Jede numerische Behauptung wird in den Unit-Tests für Kanal und Front-End und in tests/iq_cli.rs gegen eine unabhängige Referenz geprüft (geschlossene Form oder eingespeiste Wahrheit).

[0.31.0] - 2026-10-04#

Hinzugefügt#

• GNSS-IQ-Schicht: Simulation auf Signalebene und Verarbeitung durch Software-Empfänger. Ein neues Modul iq führt Kshana von einem Einzelsatelliten-Front-End für kurze Blöcke mit L1 C/A zu einer vollständigen Schicht auf Signalebene, erreichbar über die Befehlsgruppe kshana iq. Es erzeugt lange rohe IQ-Szenen mit mehreren Satelliten und einem Wahrheits-Sidecar je Epoche (iq::scene); wendet die Ausbreitung auf Signalebene an – Ionosphäre mit Code-Träger-Divergenz, Troposphäre, Amplituden- und Phasenszintillation (Cornell-Modell), Fresnel-Mehrwegeausbreitung und einen Land-Mobil-Kanal mit drei Zuständen, mit fehlender Sichtverbindung (iq::channel); akquiriert und verfolgt mit FFT-Akquisition und einer Bank aus mehreren DLL/PLL/FLL-Kanälen und spielt eine Aufzeichnung durch viele Schleifenentwürfe ab (iq::acq, iq::track); modelliert das Front-End – FIR-/IIR-Filterung, Quantisierung mit 1 bis 14 Bit, AGC, Notch, Pulsaustastung und Excision im Frequenzbereich (iq::frontend); streamt große aufgezeichnete Datensätze mit begrenztem Speicher – Formate int8/int16/float32/gepackt mit 2 Bit und reale ZF, SigMF aus mehreren Dateien, Resampling, ein Datensatzinventar mit SHA-256 je Datei und ein Batch-Runner (iq::io); fügt Spreizcodes für GPS L5/L2C, Galileo E1 (CBOC, reale ICD-Speichercodes) und E5a, BeiDou B1C/B1I und GLONASS L1OF hinzu, jeweils gegen sein Interface Control Document geprüft (iq::signals); und passt das Lock-Verlust-Modell der Tracking-Schleife an das beobachtete Verhalten eines realen Empfängers in Laborläufen an, mit Hold-out-Fehler bei Auslassung je eines Laufs und als Vorhersage gekennzeichneter Extrapolation (iq::labfit). Jede numerische Behauptung wird gegen eine unabhängige Referenz geprüft (eine ICD-Tabelle, eine geschlossene Form oder einen unabhängigen Empfänger, der die eingespeiste Wahrheit zurückgewinnt); die physikalischen Kanal- und Schleifenmodelle bleiben MODELLED. Das ist nur eine Software-Schicht: Sie schreibt IQ-Dateien für Software-Empfänger und synthetisiert keine Störungs- oder Spoofing-Wellenformen und steuert keine Funkhardware an. Keine veröffentlichte Zahl von Szenarioarten und keine Zeile der Verifikationsmatrix ändert sich. Entwurf: docs/design/GNSS-IQ-PLAN.md.
• Empfänger-Vertrauen: ein reales GNSS-Empfängerprotokoll bewerten. kshana receiver-trust <scenario.toml> liest ein Protokoll von u-blox UBX, RINEX 3 (mit optionaler Broadcast-Navigationsdatei), Android GnssLogger oder NMEA 0183 in eine zeitgestempelte Zeitleiste und lässt darüber Vertrauens-Monitore laufen: Abfall der Trägerrauschdichte (C/N0), Lock-Verlust, automatische Verstärkungsregelung (AGC), den Jamming-Indikator von u-blox, Positionssprung und, mit RINEX und Navigation, die eigene Single-Point-Lösung der Engine mit Paritäts-RAIM (receiver autonomous integrity monitoring) und den uhrengestützten Monitor. Jede Epoche ist nominal, beeinträchtigt oder nicht vertrauenswürdig, und das Ergebnis sagt, wann und warum. Im Szenario genannte Ereignisse und vorhergesagte C/N0-Abfälle werden gegen Toleranzen bewertet, die in derselben Datei genannt sind: erkannt, verspätet oder verpasst, und übereinstimmend oder abweichend. Ausgaben sind das Ergebnis-JSON, eine CSV je Epoche und ein Diagramm; das Ergebnis trägt die SHA-256 des Protokolls und jede Schwelle. Auch erreichbar aus Python (kshana.receiver_trust), dem WebAssembly-Paket (receiver_trust, Protokolle inline) und dem neuen Werkzeug assess_receiver_log des Model-Context-Protocol-Servers (MCP). Anleitung: docs/RECEIVER-TRUST.md; Beispiel: examples/receiver-trust/. Bei den Spoofing-Protokollen von JammerTest 2024 reproduziert der Pfad der Engine den ersten Alarm der vorab registrierten Pipeline der unabhängigen Referenz bei jedem veröffentlichten Beginn (tests/receiver_trust_jammertest.rs). Die Monitore bleiben MODELLED; keine Zeile der Verifikationsmatrix ändert sich.

0.30.0 - 2026-10-03#

Ein Minor-Release. Validierungsrunden 2 und Pakete der Welle 1 heben die Verifikationsmatrix von 223 Zeilen (93 VALIDATED) bei 0.29.3 auf 249 Zeilen (123 VALIDATED, 122 MODELLED, 4 PARTNER); jede Beförderung wurde gegen eine unabhängige Referenz bei einer vor dem Lauf festgelegten Toleranz geprüft, und jede Abweichung ist als Befund veröffentlicht. Neu: ein nativer Leser für NAIF-Kernel und ein Pfad für DE440, ein validierter Pfad für SGP4-nach-ITRS-Propagation und Zeit, eine gemessene Uhrenbibliothek, ein Referenzgenerator für LunaNet AFS, Löser mit erweiterter Genauigkeit und Quadratwurzel-Information sowie reale lunare IQ-Verarbeitung an LuGRE-Daten. Veröffentlichte Zahlen, die sich verschoben haben, sind unten als Revisionen aufgeführt.

Siebenundzwanzig Zeilen der Verifikationsmatrix werden VALIDATED, nachdem eine unabhängige Referenz innerhalb einer vor dem ersten Vergleich festgelegten Toleranz übereinstimmte (die Beförderungsregel in docs/VALIDATION.md): zehn in einer ersten Validierungsrunde und siebzehn in einer zweiten. Einundfünfzig MODELLED Zeilen wurden in der ersten Runde einer externen unabhängigen Referenz unterzogen und die übrigen zuordenbaren Zeilen in der zweiten; jede Abweichung ist unten als Befund festgehalten, statt weggestimmt zu werden. Drei Zeilen wurden aufgeteilt, damit ein validierter Teil keinen nicht validierten Rest mitträgt, wodurch die Matrix von 223 auf 226 Zeilen wächst; die seither eingearbeiteten Validierungspakete bringen sie auf 249. Die Zahlen werden aus der erzeugten docs/VERIFICATION-MATRIX.md gelesen.

In diesem Eintrag verwendete Abkürzungen

Abkürzung	Bedeutung
ADD, ARAIM, MAAST	Airborne Design Document (von ARAIM); advanced receiver autonomous integrity monitoring; das Matlab Algorithm Availability Simulation Tool der Stanford University
ADEV, VRW, ARW	Allan-Abweichung; Random Walk der Geschwindigkeit; Random Walk des Winkels
ANISE, SPICE, NAIF, PCK	ein quelloffenes Werkzeug für Astrodynamik (Nyx Space); das Toolkit Spacecraft, Planet, Instrument, C-matrix, Events der NASA aus ihrer Navigation and Ancillary Information Facility; Kernel für Planetenkonstanten
BCRS, TDB, TT	Barycentric Celestial Reference System; Barycentric Dynamical Time; Terrestrial Time
BIPM, UTC(k)	Internationales Büro für Maß und Gewicht; die Realisierung der koordinierten Weltzeit durch ein Labor
CCSDS, OEM, LTC, TCL	Consultative Committee for Space Data Systems; Orbit Ephemeris Message; lunare Zeitsysteme, die in das Feld TIME_SYSTEM der Nachricht geschrieben werden
CRLB	untere Schranke nach Cramér–Rao
CW	Relativbewegung nach Clohessy–Wiltshire
DE440	Development Ephemeris 440 des Jet Propulsion Laboratory
DOP, PDOP	Dilution of Precision; Position Dilution of Precision
EKF, UKF, INS, GNSS, IMU	erweiterter Kalman-Filter; Unscented-Kalman-Filter; Inertialnavigationssystem; globales Satellitennavigationssystem; inertiale Messeinheit
EMT, VPL, HPL	effektive Monitorschwelle; vertikales und horizontales Schutzniveau
EOP, IERS, PCC, MAE	Erdorientierungsparameter; International Earth Rotation and Reference Systems Service; Prediction Comparison Campaign; mittlerer absoluter Fehler
ERFA, SOFA	Essential Routines for Fundamental Astronomy; Standards of Fundamental Astronomy
GMAT	das General Mission Analysis Tool der NASA
NTN, SSB	nichtterrestrisches Netz (3GPP); Synchronisationssignalblock
IGS, ILRS, ITRF2020	International GNSS Service; International Laser Ranging Service; International Terrestrial Reference Frame 2020
ILS, LAMBDA	ganzzahlige kleinste Quadrate; Least-squares AMBiguity Decorrelation Adjustment
ISB	Bias zwischen Systemen
LEO	niedrige Erdumlaufbahn
MHSS, PL, TPL	Lösungstrennung bei mehreren Hypothesen; Schutzniveau; Schutzniveau der Zeitgebung
PSD, IQ, SigMF	spektrale Leistungsdichte; Abtastwerte in Phase und Quadratur; Signal Metadata Format
QPN	Quantenprojektionsrauschen
RAIM	receiver autonomous integrity monitoring
SBAS, WAAS, DFMC, GEO	satellitengestütztes Ergänzungssystem; das US-amerikanische Wide Area Augmentation System; Mehrfrequenz und mehrere Konstellationen; ein geostationärer SBAS-Satellit
RMS, SISRE	quadratischer Mittelwert; Entfernungsfehler im Signal im Raum
RTKLIB	eine quelloffene Bibliothek für GNSS-Positionierung
TCXO	temperaturkompensierter Quarzoszillator
VLBI	Interferometrie mit sehr langer Basislinie

Validiert#

Jede Zeile unten nennt die Art ihrer unabhängigen Referenz (Library: eine unabhängige Bibliothek eines Dritten, die eine eindeutig definierte Größe berechnet; Measured: reale Messdaten; P2: eine unabhängige numerische Bibliothek, die eine Größe der linearen Algebra auf eingecheckten Eingaben neu berechnet), die unabhängige Referenz, die vor dem Lauf festgelegte Toleranz und das Ergebnis. Jede Beförderung wurde von einem zweiten Prüfer erneut ausgeführt, der die Fixture Byte für Byte neu erzeugte und zeigte, dass eine bewusste Mutation der Engine den Test rot werden lässt.

• GNSS/INS-Sensorfusion (Library), begrenzt auf den lose gekoppelten Fehlerzustands-EKF mit 15 Zuständen: NaveGo v1.4 (LGPL-3.0, unter GNU Octave ausgeführt) auf seiner eigenen realen IMU/GNSS-Fahrt mit Ekinox. Der horizontale, der vertikale und der Positions-Innovations-RMS von Kshana betragen 0,912, 0,940 und 0,861 von denen von NaveGo (Zielwert 1,2), und seine mittlere normierte Innovation beträgt 0,395 (Zielwert 1,5). GNSS ist während der ganzen Fahrt vorhanden, daher wird kein Ausfall getestet. Der eng gekoppelte UKF und der gekoppelte Uhrenfilter bleiben außerhalb der Behauptung.
• Fehlerbudget für 3-DOF-Lage und Ausrichtung (Library), eingegrenzt auf die Spitze des Gravitationsgradienten-Moments: Basilisk 2.9.1 GravityGradientEffector, 40 Fälle, innerhalb von 1e-12 relativ (schlechtester Wert 2.1e-15). Das RSS-Budget der Ausrichtung ist eine Summe vom Aufrufer gelieferter Zahlen und bleibt außerhalb davon.
• Lunare gemeinsame Geometrie für Kommunikation und Navigation (Library), eingegrenzt auf Standortplatzierung, Azimut, Elevation und Entfernung: ANISE 0.10.2, 768 Stichproben, innerhalb von 1e-6 Grad und 1 mm (schlechtester Wert 2.2e-12 Grad und 5.6e-9 m). Der Parameter für die Genauigkeit der Entfernungsmessung ist eine Entwurfseingabe außerhalb der Behauptung.
• Momentenfreie Lagedynamik starrer Körper (Library): der Basilisk-2.9.1-Raumfahrzeug-Hub, 1e4 s auf zwei allgemeinen Trägheiten, Quaternion und Raten innerhalb von 1e-9 (schlechteste Werte 3.3e-11 und 3.4e-12 rad/s).
• Auflösung der ganzzahligen Mehrdeutigkeit der GNSS-Trägerphase (LAMBDA) (Library), eingegrenzt auf die ILS-Lösung und ihre beiden besten Normen: RTKLIB v2.4.2-p13 lambda(), 300 Kovarianzen, 0 ganzzahlige Abweichungen, Normen innerhalb von 1e-9 relativ (schlechtester Wert 5.6e-13). Die Erfolgsrate des Bootstrap bleibt nur intern geprüft.
• Zusammengesetzte Zeitgebungs-PL, skalares MHSS (P2): numpy 2.3.5 und scipy 1.18.1 auf 300 festgeschriebenen Eingaben, PL innerhalb von 1e-9 relativ (schlechtester Wert 1.2e-10), Teilmenge der Ansteuerung identisch.
• GLS-Gleichtakt-Whitening und die Mahalanobis-Identität (P2): numpy 2.3.5 LAPACK auf 201 festgeschriebenen Kovarianzen, innerhalb von 1e-12 relativ (schlechtester Wert 7.9e-16); Konditionszahlen bis 19,3.
• DE440-Anbieter der Hauptachsenorientierung des Mondes (Bibliothek): SPICE pxform auf dem binären PCK bei 2.000 Epochen außerhalb der Knoten, innerhalb von 1.7e-5 rad (schlechtester Wert 1.7e-6 rad, etwa 3 m an der Oberfläche), nach der unter "Fixed" aufgeführten Korrektur.
• SigMF-Aufzeichnungs-Ein- und -Ausgabe sowie Welch-Spektren (Bibliothek), eingegrenzt auf SigMF-Lesen und -Schreiben und welch_psd: scipy 1.18.1 signal.welch innerhalb von 1e-12 relativ je Bin (schlechtester Wert 6.0e-14); sigmf-python 1.13.0-Aufzeichnungen bitidentisch dekodiert; die Metadaten des Crates gültig gegen das SigMF-Schema v1.2.6. IQ-Synthese und ihre Modellvergleiche bleiben außerhalb.
• LEO-Broadcast-Ephemeriden-Fitter und SISRE gegen das Fit-Intervall (Measured), eingegrenzt auf den Kepler-Fit mit 16 Parametern und dessen reine Bahn-SISRE: präzise TU-Graz-ITSG-Bahnen von vier Satelliten gegen die Statistik von Liu et al. 2025, Komponenten innerhalb des 1.5-Fachen (0,804 bis 1,087) und SISRE innerhalb des 1.5-Fachen (0,716 bis 0,809).

Befunde#

Die unabhängige Referenz widersprach diesen Zeilen, daher bleiben sie MODELLED. Jeder Befund ist zusätzlich in den Referenztext der Zeile geschrieben (und damit in docs/MODELLED-RATIONALE.md), mit einem Test, der ihn festschreibt.

• Zustandsschätzung der Borduhr: auf zurückgehaltenen IGS-Uhren von 11 GPS-Block-IIF-Satelliten ist das Filter mit drei Zuständen einen Schritt voraus konsistent, aber nach einer Stunde bei 9 von 11 übermäßig zuversichtlich (periodische und Flicker-Terme sind nicht im Modell).
• Spoofing-Erkennung: bei JammerTest 2024 schlug kein Monitor auf Beobachtungsebene innerhalb von 10 s nach einem der 8 veröffentlichten Einsätze Alarm, und drei Fenster vor dem Einsatz enthielten Fehlalarme.
• Zeitgebungs-Schutzniveau unter Spoofing: der gemessene unentdeckte Zeitfehler überschreitet das TPL bei 3 von 8 erkannten Einsätzen (1.9x bis 5.3x); eine Uhrenkalibrierung von 60 s deckt das Wandern des TCXO des Empfängers nicht ab.
• Startfenster und Aufstiegsgeometrie: gegenüber Orekit 12,2 stimmt die Geometrie bis auf Rundung überein, aber die Standortgeschwindigkeit aus der Erdrotation verfehlt 1e-6 relativ bei 62,9 Grad Breite (1.12e-6, die Polbewegung, die das sphärische Modell auslässt). Runde 2: die Geschwindigkeit am wahren Pol mit Epoche stimmt überein, die Standardgeschwindigkeit ohne Epoche verfehlt weiterhin (siehe unten).
• Ballistischer Wiedereintrittskorridor (Allen–Eggers): die vorhergesagte Spitzenverzögerung für den Stardust-Eintritt beträgt 61,8 g gegenüber den rekonstruierten 32,89 g (+88 %, Toleranz 15 %).
• Gemeinsamer UT1- und Polbewegungsfehler: gegenüber der in 178 IERS-Bulletin-A-Ausgaben gedruckten Genauigkeitsformel stimmt der Pol innerhalb des 1.5-Fachen überein, UT1 jedoch nicht (0,48 bei 10 Tagen, 1,59 bei 40 Tagen). In Runde 2 abgelöst: die Zeile ist jetzt VALIDATED (siehe unten).
• Standard-Erdorientierungseingabe offline: astropy bestätigt die Zeilenzählung, aber die 12 Zeilen, die das Crate als Bulletin-A-Vorhersagen bezeichnet, sind als gemessen (I) gekennzeichnet, nicht als vorhergesagt (P). Die Übereinstimmungswerte der Zeile des operativen Prädiktors bezogen sich daher auf gemessene Zeilen. In Runde 2 abgelöst: die Engine klassifiziert Zeilen nach Kennzeichen, und die Zeile ist VALIDATED.
• Vorhersagefehler der Erdorientierung im operativen Stil: der UT1-Fehler des Prädiktors ist 2.4x bis 12.6x der von Bulletin A bei 1 bis 10 Tagen und 5,32 ms bei 10 Tagen, außerhalb des Bereichs von 0,36 bis 3,13 ms des 2nd EOP PCC.
• Mondgeodätische VLBI: gegenüber ANISE-Lichtlaufzeiten über DE440 liegt keine Verzögerung innerhalb von 1 ps; die größte Abweichung beträgt 24 µs, überwiegend durch das analytische Mondzentrum (etwa 200 km von DE440). Runde 2: der Kernel-Pfad ist in einer eigenen Zeile VALIDATED; dieser analytische Pfad bleibt MODELLED.
• Export zur Interoperabilität auf dem Mond: Orekit 12,2 verweigert die Zeitsysteme LTC und TCL, daher ist der Austausch der lunaren OEM-Dateien mit einem zweiten Leser nicht belegt.
• Clohessy–Wiltshire-Relativbewegung: gegenüber der nichtlinearen Bewegung in Orekit bei 100 m beträgt die Abweichung 1,2 bis 6,3 mm, über 1 mm; sie skaliert wie der ausgelassene Term zweiter Ordnung, sodass die vorab festgelegte Toleranz unter dem Linearisierungsfehler lag. In Runde 2 abgelöst: die Korrektur zweiter Ordnung ist gegen denselben Zielwert VALIDATED.
• Fehlerwachstum bei INS/TRN-Koppelnavigation: gegenüber einer freien inertialen Monte-Carlo-Rechnung von NaveGo gelten die Wachstumsgesetze innerhalb von 5 % bis 600 s und überschätzen darüber hinaus (2.2x bis 8x nach einer Stunde), weil sie die Schuler-Rückkopplung auslassen. In Runde 2 abgelöst: das Schuler-Fehlermodell ist VALIDATED.
• Mond-Dienstvolumen aus realer Konstellationsgeometrie: 4 von 12 veröffentlichten Verfügbarkeitsstatistiken weichen um mehr als 2 Prozentpunkte ab (bis zu 22,5).
• Überschranke der Rückführbarkeitsabweichung heterogener UTC(k): auf 105.024 BIPM-Zeilen wird die Überschranke bei 50,8 % der Zeilen überschritten; die veröffentlichte Unsicherheit begrenzt die Messung des Versatzes durch das BIPM, nicht den Versatz.
• Klassifikation des Nullraums des Mond-Datums: bei der veröffentlichten Fünf-Reflektor-Geometrie beträgt die Korrelation -0.78 gegenüber -0.97, und die CRLB des Ursprungs liegt 96 bis 98 % unter der der Veröffentlichung.
• Geometriesubstrat des Mond-LLR-Datums: gegenüber 192 lunaren ILRS-Normalpunkten von 2024 betrug der RMS des Einweg-Residuums 96 m mit der früheren Orientierungsinterpolation und beträgt 22,7 m nach der unten genannten Korrektur, weiterhin über dem Zielwert von 10 m (gerundete Stationskoordinaten, keine Polbewegung). Die Orientierungsreihe wird außerhalb von 2024-2025 stillschweigend begrenzt. Runde 2: das Modell der gemessenen Entfernung ist in einer eigenen Zeile VALIDATED (2,81 m); die Reihe deckt jetzt 2014-2030 ab und meldet außerhalb davon Fehler.
• Kopplung der relativistischen Uhrenrate an das Bezugssystem: der Eigenpotentialterm liegt 3.18e-4 über dem veröffentlichten Wert (Toleranz 1e-4); die Veröffentlichung wertet ein anderes Potential aus, sodass für diese geschlossene Form kein veröffentlichter Wert existiert. In Runde 2 abgelöst: das äquatoriale Potential vom Grad 2 ist gegen dieselbe Veröffentlichung VALIDATED.
• Physikalische Konstanten jedes Körpers des Sonnensystems: 12 von 84 Konstanten der hinzugefügten Körper weichen von NAIF pck00011 und gm_de440 ab (ältere Elemente der Marsmonde; andere GM-Lösungen für Uranus, Neptun und Pluto). Runde 2: die Konstanten folgen jetzt NAIF (eine Transkription, nicht gezählt), und die berechnete Orientierung stimmt mit SPICE überein; die Zeile bleibt MODELLED.
• Wählbare LEO-Ephemeridenmodelle: der Fit mit 22 Parametern lässt das 1.71-Fache und das 1.86-Fache des veröffentlichten Along-Track-Fehlers auf Bögen von 20 min, über dem 1.5-Fachen. In Runde 2 abgelöst: das Modell mit 22 Parametern und sein Fit sind in einer eigenen Zeile VALIDATED.
• Gemeinsame GNSS- und LEO-Positionierung: die Intersystemabweichung stimmt mit RTKLIB überein, aber 93,2 % der Epochen liegen innerhalb von 3 m von ITRF2020 gegenüber 95 %; RTKLIB selbst erreicht auf den Daten 88,2 % (93,6 % nach der Gruppenlaufzeitkorrektur aus Runde 2).
• Integritätsblindheit im Gleichtakt und Abdeckungs- und DOP-Karten: beide Vergleiche bestanden, wurden aber bei der Prüfung abgelehnt, weil auch eine absichtlich falsche Engine sie besteht (der erste prüft nur eine interne Identität; die veröffentlichten Untergrenzen des zweiten können ein verdoppeltes PDOP nicht erkennen). Runde 2: die Integritätsblindheit im Gleichtakt ist bei paritätstragenden Eingaben VALIDATED; die Abdeckungskarten bleiben ein Befund (siehe unten).

Validierungsrunde 2#

Die zweite Runde nahm jede Zeile, die die erste Runde noch routbar ließ, mit frischen Vorregistrierungen, die festgeschrieben wurden, bevor ein Fixture abgerufen oder eine unabhängige Referenz ausgeführt wurde, mit einem adversarialen zweiten Prüfer, der jeden Vergleich erneut ausführte, und mit einer absichtlichen Engine-Mutation, die jeden Test rot färben muss. Der Eigentümer nahm am 2026-10-02 den korrigierten Wortlaut der Zeile zur Schranke außerhalb von Omega an, bevor sie hochgestuft wurde (ihr alter Text widersprach dem Code).

Zu VALIDATED hochgestuft (17). Art der unabhängigen Referenz in Klammern; Toleranz vor dem Lauf festgelegt.

• Kopplung der relativistischen Uhrenrate an das Bezugssystem (Referenz): L_m von Ashby und Patla 2024 innerhalb von 2.8e-6 (Zielwert 1e-4) aus dem äquatorialen Potential vom Grad 2 der beiden Felder, die die Veröffentlichung zitiert; pyshtools-Gravitation vom Grad 350 für den radialen Eintrag (8.3e-5); DE441-Mondgeschwindigkeit (2.5e-3).
• Standard-Erdorientierungseingabe offline (Bibliothek): astropy 8.0.1 und IERS Bulletin A Nr. 039 bestätigen die 30 endgültigen, 54 schnellen und 90 vorhergesagten Zeilen des neu zugeschnittenen Auszugs.
• Gemeinsamer UT1- und Polbewegungsfehler (Bibliothek): vollständige Rotationen von astropy und pyerfa reproduzieren die gemeinsame Tabelle (UT1 und Pol innerhalb von 6e-16, die Kombination innerhalb von 1.9e-7); die realisierten Fehler des IERS Annual Report 2019 ergeben Verhältnisse von 1,001 bis 1,100.
• Fußabdruck und Abdeckung der EO-Nutzlast (Bibliothek): Orekit 12,2 und GeographicLib 2,1 bei jedem vorab festgelegten Zielwert, wobei die J2-Knotenregression jetzt im Knotenabstand enthalten ist.
• Clohessy–Wiltshire-Relativbewegung (Bibliothek): mit einer Korrektur zweiter Ordnung in geschlossener Form innerhalb von 1.2e-7 m von der nichtlinearen Bewegung in Orekit gegenüber 1e-3 m; die lineare Matrix allein bleibt charakterisiert (1,2 bis 6,3 mm).
• B-Ebenen-Zielführung und Gravity Assist mit Patched Conics (Bibliothek): GMAT R2026a B-Ebene, Asymptoten, C3 und heliozentrische Elemente; sbpy 0.6.0 sowie Kasuga und Jewitt 2019 für den Tisserand-Parameter.
• Fehlerwachstum bei INS/TRN-Koppelnavigation (Bibliothek): ein Schuler-Fehlermodell mit neun Zuständen innerhalb von 5 % der korrigierten NaveGo-Koppelläufe an allen 48 Punkten (schlechtester Wert 3,70 %).
• Integritätsblindheit im Gleichtakt (P2): numpy lstsq auf 1464 paritätstragenden Eingaben innerhalb von 1e-12 (schlechtester Wert 1.06e-14).
• Gemeinsame lunare Multi-Technik-OD und Uhr (P2): numpy berechnet jeden Gauß-Newton-Schritt, jedes Sigma und jeden Stationsfehler auf sechs Netzen (innerhalb von 2.4e-11) nach einer Korrektur der QR-Lösung neu.
• Stationskoordinaten-Kovarianz der Mond-VLBI (Bibliothek): eine mit SPICE aufgebaute Jacobi-Matrix reproduziert Zeitplan, Spektrum, Sigmas und Nullraum innerhalb von 1 % und 0,1 Grad; numpy bis 2e-13.
• Nicht erkennbare Gleichtaktschranke bei Residuum außerhalb von Omega (P2, Wortlaut durch Entscheidung des Eigentümers korrigiert): numpy LAPACK auf 256 Fällen innerhalb von 1e-12, sechs exakte Unendlichkeiten.
• Basisinvariante Klassifikation des Nullraums (P2): Unterraumschnitt mit SciPy und NumPy auf 72 konstruierten Matrizen, ganze Zahlen exakt, Projektornorm innerhalb von 6.0e-15.
• Einfrequenz-Ionosphären- und UTC-Dienste einer LEO-Navigationsnachricht (Bibliothek): GNSSTk 15.3.1 für Klobuchar, Az und die UTC-Drift; ERFA für die drei Schaltsekundenfälle.
• Positionierungsschranke für 5G-Nicht-Terrestrische-Netze (P1): Einzel-SSB-Schranken von Bachl, Lei und Nabeel 2026 innerhalb einer halben gedruckten Stelle; numpy für die Fix-Kovarianzen.
• LLR-Modell der gemessenen Entfernung (Measured, neue Zeile, abgespalten vom LLR-Datumssubstrat): 192 lunare ILRS-Normalpunkte bei 2,81 m RMS gegenüber einem Zielwert von 10 m, mit der baryzentrischen Lichtlaufzeit nach IERS 2010; die Komponenten unterhalb des Zielwerts werden nicht einzeln aufgelöst, und die Zeile sagt das.
• Mondgeodätische VLBI, Kernel-Pfad (Bibliothek, neue Zeile, abgespalten von der Zeile zur Mond-VLBI): konvergierte Lichtlaufzeiten aus SPICE innerhalb von 1 ps und Partialableitungen innerhalb von 1e-6 bei Epochen nahe J2000; der analytische Standardpfad bleibt MODELLED.
• LEO-Ephemeridenmodell mit 22 Parametern nach Liu et al. 2025 und sein Fit (Measured, neue Zeile, abgespalten von der Zeile der wählbaren Modelle): reale präzise Bahnen innerhalb des 1.5-Fachen der veröffentlichten Statistik an Tagen der Veröffentlichung und an zurückgehaltenen Tagen (0,683 bis 1,186); die Skalenkonvention von n_dot ist übernommen und wird durch diesen Vergleich nicht validiert, und die Abbruchregel ist die Parameterkonvergenzregel von Kshana, nicht die RMS-Änderungsregel der Veröffentlichung. Das ATOMIC-Polynom und die Tabelle mit fünf Höhen bleiben MODELLED.

Bestehende Zeilen VALIDATED neu abgestützt (keine Änderung der Anzahl).

• Planetenpositionen aus den JPL-Standish-Elementen und Lichtlaufzeit zwischen Körpern des Sonnensystems: die nachträglichen Zielwerte mit doppeltem Nennwert werden durch vorregistrierte Vergleiche mit JPL Horizons DE441 ersetzt (RMS höchstens der Wert der Tabelle 8.10.1 des Explanatory Supplement, schlechtester Wert 0,778, einschließlich der Aufteilung der Erde und der ICRF-Rotation; Lichtlaufzeiten innerhalb von 1e-6 s von Horizons auf DE441-Positionen, schlechtester Wert 6.7e-9 s). Ihre Kennzeichen "Grenze nach dem Vergleich festgelegt" sind entfernt.
• Integrität (RAIM/ARAIM/SBAS): die Zeile beruht nicht mehr auf Plausibilitätsprüfungen. Sie sagt jetzt: die Multiple-Hypothesen-Lösungstrennung von ARAIM nach ADD v4.2 stimmt bei ARAIM 2 auf 270 realen Fällen mit Stanford MAAST überein (schlechteste VPL-Differenz 2.2e-3 m gegenüber 0,05 m); Snapshot-RAIM-Erkennung und -Ausschluss stimmen mit RTKLIB raim_fde bei 2016 von 2016 Entscheidungen überein, mit dem Schutzniveau der Steigung innerhalb von 2.7e-12 m; die L1-Schutzniveaus des SBAS DO-229E stimmen bei realen WAAS-Aussendungen mit Stanford MAAST überein (2868 Paare innerhalb von 1.6e-5 m). Sie stellt klar fest, dass die Funktionen mit einheitlichem Sigma raim::araim_raim und raim::araim_dual_raim NICHT ADD-konform sind (Lücken bei gleichen Eingaben 0.75/4.04 m und 0.39/1.93 m VPL/HPL, ein Befund), dass der DFMC-L5-SBAS-Vergleich ein Befund ist (308 Paare ohne GEO in Sicht werden von Kshana geschützt und von MAAST nicht) und dass raim::solution_separation_raim keinen externen Vergleich hat. Ihr Selbstkennzeichen ist entfernt.
• LEO-Broadcast-Ephemeriden-Fitter: die integrierte Wahrheitsbahn wird dem validierten Teil hinzugefügt (Orekit 12,2 innerhalb von 4,55 mm über 6 h, Zielwert 2 cm); die Korrekturpolynome, der Uhr-Fit und der Kompromiss bei der Aktualisierungsperiode bleiben modelliert.

Befunde und blockierte Zeilen (bleiben MODELLED). Der Referenztext jeder Zeile enthält den Befund und seinen festgeschriebenen Test.

• Modulation von Navigationssignalen (Betz 2001, Hein 2006): Spektren und Korrelationen stimmen überein; die Nebenkeulen bei 24 MHz und jede Mehrwegabweichung (11 bis 15 % zu niedrig) nicht, Ursache ungeklärt.
• TDOA/FDOA-Geolokalisierung: die Schranken stimmen mit Ho und Chan sowie Ho und Xu überein, und mit dem Code der Autoren bis 3e-12; die aus einer Monte-Carlo-Rechnung gedruckten Ottawa-Faktoren weichen um 1,3 % und 4,4 % ab.
• Erd-GNSS in Monddistanz: die GENESIS-Zenitmittelwerte stimmen bei 5 von 6 mit Montenbruck et al. 2023 überein; die Nadirmittelwerte liegen 1,0 bis 2,4 Satelliten zu hoch.
• Abdeckungs- und DOP-Karten: Erd-Designs stimmen bei jedem Zielwert mit Orekit, gnss_lib_py und numpy überein; Mond- und Mars-Designs überschreiten 1e-9 nur bei nahezu singulären Zellen.
• Gemeinsame GNSS-Positionierung: Zweifrequenz 79,9 % und präzise Produkte 94,2 % innerhalb von 3 m gegenüber 95 % (RTKLIB 67,9 % und 94,1 %); die ISB-Lücke bei den präzisen Produkten entsteht, weil RTKLIB Antennenversätze ignoriert.
• Nachführschleifen (GNSS-SDR 0.0.19): stimmen bei 35 bis 45 dB-Hz überein; bei 30 dB-Hz PLL +21 %, DLL -32 %, Schwellen +1,5 dB; Slip-Zeiten 0,5 bis 2 Dekaden kürzer.
• Mond-Dienstvolumen (Orekit und Hipparchus): 155 von 160 Werten stimmen überein; die Anforderung an die schlechteste Stichprobe scheitert bei nahezu singulärer LNCSS-B-Geometrie.
• Quanteninertialsensor: die Untergrenze nur aus QPN liegt 21 bis 31 % unter dem gemessenen Rauschen von Gauguet 2009 (Zielwert 30 %, um 0,5 Punkte verfehlt).
• Oszillator-Voreinstellungen: gemessene Einheiten überschreiten die Holdover-Voreinstellung für Rubidium, die Kurzzeitvoreinstellung für Caesium und die Voreinstellungen für die schlechteste Einheit des CSAC; für die OCXO-Voreinstellung gibt es keine Messaufzeichnung.
• Weltraumwetter-Dichte: Jacchia 1971 liegt im Sonnenmaximum innerhalb eines Faktors 2 der Beschleunigungsmesserdichten, ist aber im Minimum 2008 etwa 1.7x zu dicht.
• Geometriefreies schräges TEC: 33 von 36 Bögen innerhalb von 3 TECU der CODE-Karte (schlechtester Wert 6,84).
• Spoofing-Erkennung und TPL gegen das offizielle JammerTest-2024-Protokoll: 4 von 10 Einsätzen rechtzeitig erkannt; das TPL wird bei 4 von 10 überschritten.
• Uhrenfilter auf frischen IGS-Uhren: zwei von 11 Satelliten verfehlen das Kriterium der Innovationssumme.
• EOP-Prädiktor aus kleinsten Quadraten plus Autoregression: UT1 1,73 bis 2.11x Bulletin A bei 2 bis 10 Tagen.
• Überschranke des realisierten UTC(k)-Versatzes: gepoolte Überschreitung 0,0333 gegenüber 1e-2.
• Mond-Bezugssystemdatum aus einer Kampagne: der SPICE-Zweig stimmt überein; der Zweig P2 mit geschätzten Stationen verfehlt 1e-9 bei einem Problem mit Kondition 2.1e8.
• Mond-Bezugssystemdatum aus realem LLR: 15 von 16 Werten stimmen mit SPICE überein; das Sigma der z-Translation ist 1,03 % zu hoch gegenüber 1 %.
• Wiedereintritt (Allen-Eggers): die Punktmassenlösung stimmt mit Rekonstruktionen von Raumfahrtagenturen überein (nur eine Gegenprüfung); der Vergleich mit dem Beschleunigungsmesser ist blockiert, bis eine lesbare Hayabusa2-Quelle vorliegt.
• ITU-T-Masken: die gedruckten Rechenbeispielwerte stimmen überein; für die Klassengrenzen von G.8273.2 gibt es keine (blockiert).
• Startfenstergeometrie: die Standortgeschwindigkeit am wahren Pol mit Epoche stimmt mit Orekit überein (4.9e-8); die Standardgeschwindigkeit ohne Epoche verfehlt weiterhin (1.12e-6). Nicht hochgestuft; Nachverfolgung steht aus.
• Physikalische Konstanten jedes Körpers: jetzt weichen 0 von 84 von NAIF ab (eine Transkription), und die berechnete Orientierung stimmt mit SPICE bis 1.4e-10 rad überein. Nicht hochgestuft; Nachverfolgung steht aus.
• Blockiert durch eine Festlegung des Eigentümers zum Umfang, jeweils mit festgeschriebenem übereinstimmendem Vergleich: lunare Beobachtbarkeit absoluter Stationen, DOP von Oberflächenbaken, der Off-Boresight-Export, Erkennungsleistung über Modalitäten hinweg, die Konsistenzstatistik im Gleichtakt und polare LEO-Abdeckung.
• Blockiert durch Daten: Fehlerbudgetierung bei der Zeitübertragung (braucht eine Reduktion realer Daten), JammerTest C/N0 (Antennenposition und Leistungsaufteilung nicht dokumentiert).

Revisionen (veröffentlichte Zahlen, die sich verschoben haben, alt -> neu).

• Die Schutzniveaus von snapshot_raim liegen jetzt auf dem geodätischen lokalen Niveau statt auf dem radialen: bis zu 0,31 m HPL und 0,14 m VPL bei ABMF (16 Grad N); kein Golden-Wert hat sich bewegt, aber die aufgezeichnete Zusammenfassung des Tutorials gnss-sim wechselt von mittlerem HPL 22,1 m / VPL 40,0 m zu 22,2 m / 39,9 m (docs/tutorials/scenarios/gnss-sim.toml).
• Standardwerte der Ratenkopplung im Mondbezugssystem: d_alpha/d_scale 3.139807e-11 -> 3.138801e-11; d_alpha/d_radial 1.807187e-17 -> 1.806185e-17 pro Meter.
• EOP-Lauf mit Standardwerten offline (realtime-frame-eop, Zellen aufgeführt in docs/revisions/M035-default-eop-recut-cell-changes.md): predicted_rows 12 -> 90; Polgrenze 0,06776 -> 0,05550 mas; eop_term_m 14,01601 -> 14,01583; total_m 20,09759 -> 20,09746; total_time_ns 67,03834 -> 67,03790; die Zeilen der Tabelle 2 von tests/golden/realtime-frame-eop.csv; Übereinstimmung des operativen Prädiktors 0.256/0.695/1.252/3.885 ms -> 0.133/0.421/0.839/2.786 ms.
• docs/LEO-NAVMSG.md liu22 SISRE Bahn/mit Uhr: 60 s 0.011/0.046 -> 0.014/0.046 cm; 300 s 0.068/0.139 -> 0.074/0.142 cm; 600 s 0.269/0.299 -> 0.258/0.290 cm.
• Höhentabelle von Liu, Kshana (Verhältnis): GRACE-A 5,40 (0,61) -> 4,25 (0,48); GRACE-C 4,12 (0,66) -> 2,87 (0,46); Sentinel-2A 2,95 (1,03) -> 2,20 (0,77); HY-2A 2,38 (1,13) -> 1,25 (0,59); Sentinel-6A 0,70 (0,94) -> 0,51 (0,67).
• LEO-Navigationsnachricht nDot Skala 2^-60 -> 2^-58 (nicht vorregistriert, offengelegt; außerhalb des Fit-Vergleichs); der CRC des liu22-Beispielframes 0x62373A -> 0xDED99C.
• Verifikationstabelle docs/LEO-NAVMSG.md: die Zeile zu Liu und ATOMIC aufgeteilt in eine Zeile mit 22 Parametern der Stufe VALIDATED und eine Zeile zu ATOMIC und der Fünf-Höhen-Tabelle der Stufe MODELLED.
• Zeilentext zur DE440-Hauptachsenorientierung des Mondes: Spanne 2024-2025 / 731 Zeilen -> 2014-2030 / 6.209 Zeilen; "clamps silently" -> Fehler außerhalb ihrer Spanne.
• Szenario eo-coverage: equatorial_ground_track_spacing_km 2756,37 -> 2752,17 km; neue Felder inclination_deg (98,19) und nodal_period_min (98,893).
• constellation-multi-gnss-coverage (Bezugsuhr für TDOP/GDOP ist jetzt die Konstellation mit der niedrigsten Nummer in Sicht): globales GDOP-Maximum 2,2236 -> 2,1205, Mittelwert 1,122 -> 1,131, Median 1,115 -> 1,125, p90 1,255 -> 1,265, p95 1,305 -> 1,315, p99 1,41 -> 1,42 und die GDOP-Karte je Zelle; mean_visible_by_constellation als ganze Zahlen summiert (etwa 1e-12 relativ, bei 4 Dezimalstellen unsichtbar).
• Gemeinsamer GNSS-Einfrequenz-Fix nach der Korrektur der Broadcast-Gruppenlaufzeit: 93,2 % -> 93,6 % innerhalb von 3 m; ISB-Median -0.351 -> -0.114 ns.
• tracking-loop jitter_table log10_mean_time_to_cycle_slip_s (Costas-Schleife SNR rho/4): an der Schwelle von 25,47 dB-Hz 11,58 -> 2,10; bei 25 dB-Hz 9,55 -> 1,60; bei 22 dB-Hz 2,24 -> -0.14.
• ins-trn-coast: jede Ausgabe verschiebt sich mit dem Schuler-Fehlermodell; die TRN-Spitze des ausgelieferten Szenarios 52,932679 -> 44,711834 m (tests/conflict_resilience_architecture_guard.rs).
• lunar-vlbi-Bericht: neuer Schlüssel geometry_path ("analytic" beim Standardlauf, kein numerischer Wert geändert); neue optionale Felder planetary_kernel_path, earth_orientation_kernel_path und moon_orientation_kernel_path, mit epoch_partials auf dem Kernel-Pfad; die Beschreibung der Art ist neu geschrieben. Die unabhängige Referenz der Verifikationszeile für den Kernel-Pfad ist SPICE (0,06 ps); ANISE (0,12 ps) wird zu einer Gegenprüfung der Kernel-Auswertung.
• Körperkonstanten: Phobos GM 7.087e5 -> 7.087546066894452e5; Deimos 9.62e4 -> 9.615569648120313e4; Uranus 5.7939506103e15 -> 5.793951256527211e15; Neptun 6.83509997e15 -> 6.835103145462294e15; Pluto 8.69326e11 -> 8.696138177608748e11 (m^3/s^2); Äquatorradius von Phobos 13,1 -> 13,0 km; Pol und Nullmeridian von Phobos und Deimos aus pck00011; der prime_meridian_deg des Sonnensystems enthält jetzt die quadratischen und periodischen Terme.
• europa-surface-pnt (body-pnt auf Europa), aus der vollständigen Europa-Orientierung nach pck00011 (7cfd66b4; die Orientierung stimmt mit SPICE pxform bis 1.4e-10 rad überein), die den Lander im inertialen Raum verschiebt: Verfügbarkeit nur Relais / mit der Erdentfernung 0,485 / 0,725 -> 0,480 / 0,719 (83 -> 82 von 171 Epochen nur Relais), mittleres PDOP 5,266 -> 5,360, RMS des Fix-Fehlers 129,516 / 100,983 m -> 112,742 / 86,147 m, mittleres formales Sigma 5,266 / 4,272 m -> 5,360 / 4,239 m. Die Tabelle in docs/SOLAR-SYSTEM.md und die Festschreibung in mcp/kshana-mcp/tests/round_trip.rs folgen; mars-orbit-pnt ist unverändert.
• space-weather (f107 180, f107a 165, kp 4), der kalibrierte Faktor ersetzt durch Jacchia 1971: activity_density_kg_m3 bei 300/400/500/600/800 km 2.602e-11 -> 3.608e-11, 4.176e-12 -> 6.929e-12, 8.136e-13 -> 1.618e-12, 1.769e-13 -> 4.189e-13, 1.544e-14 -> 3.781e-14; activity_factor 1.076/1.121/1.168/1.216/1.320 -> 1.492/1.860/2.322/2.881/3.232; reference_exospheric_temperature_k entfernt, mean_exospheric_temperature_k hinzugefügt (1186,7 K); tests/space_weather_reference.rs: der Sonnenzyklus-Hub bei 800 km beträgt jetzt 10.4x (NRLMSISE-00 13.6x), und die Höhenaussage folgt dem Anstieg von NRLMSISE bis 500 km und dem Abfall bei 800 km.
• ntn-5g-positioning toa_median_sigma_3d_m: NR 5 MHz 2,0903959 -> 2,0903962 m; NB 200 kHz 25,938613 -> 25,938839 m (Zusammenfassungstext unverändert bei 2,09 / 25,94 m).
• lunar-joint-od-clock (QR-Lösung): with_vlbi.station_pos_err_m 3,541344 -> 3,541350 m; without_vlbi.station_pos_err_m 2183,119 -> 2183,558 m.
• docs/field-units-schema.json neu erzeugt für die neuen und entfernten Felder oben.

Validierungspakete#

D12, erweiterte Genauigkeit und ein Quadratwurzel-Löser (zwei neue Zeilen VALIDATED: 226 -> 228 Zeilen, 110 -> 112 validiert).

Teil 1, unabhängige Referenz mit erweiterter Genauigkeit:

• Mond-Bezugssystemdatum bei geschätzten Stationen: eine unabhängige Referenz mit erweiterter Genauigkeit aus 50-stelligem mpmath (vorregistriert 804662d5, konditionsskalierte Zielwerte aus einer a-priori-Rückwärtsfehlerformel) stimmt an einem neuen Kampagnendatum (2026-03-18) und am ursprünglichen Szenario vom 2024-01-01 überein; neue Zeile VALIDATED unter P2. Sie entscheidet den früheren Streit um doppelte Genauigkeit: die Datums-Sigmas der Engine weichen um bis zu 9.7e-6 ab, die Inversions- und Eigenwertwege von NumPy um bis zu 6.2e-6 und seine Cholesky- und QR-Wege um etwa 1e-8. Die Engine liegt innerhalb ihrer Fehlerschranke, ist aber etwa tausendmal weniger genau als ein Faktorisierungsweg.
• Umgebung der unabhängigen Referenz: mpmath 1.3.0 hinzugefügt.
• Revisionen: keine. Keine Golden-Datei und keine veröffentlichte Zahl ändert sich; die Zeile "Lunar frame datum from an observing campaign" bleibt MODELLED (Entscheidung des Gründers 2026-10-02, Option A: sie übernimmt nicht den Status der separaten Zeile); ihr Testtext nennt den neuen Test und seinen Befund.

Teil 2, Datumslöser mit Quadratwurzel-Information:

• Neuer optional zuschaltbarer Löser mit Quadratwurzel-Information (linalg_sr; solver = "srif" im Szenario lunar-frame-campaign): Householder-QR, Marginalisierung über den Dreiecksfaktor, eine Jacobi-SVD für das Spektrum und kompensierte Produkte allein aus korrekt gerundeten Operationen. Gegenüber der unabhängigen Referenz mit 50 Stellen (vorregistriert b41908c9) stimmen seine Datums-Sigmas an einem neuen Datum (2026-06-09) bis 3e-13 überein; bei den Eingaben vom 2026-03-18 und 2024-01-01 weicht der Standardlöser um bis zu 1e-5 ab. Neue Zeile VALIDATED unter P2. Der Standardlöser und seine Ausgabe bleiben unverändert. Die vorregistrierten Zielwerte bescheinigen Fehler nur oberhalb von etwa 2e-7 relativ: Sie weisen den Standardlöser zurück, nicht aber ein umgekehrtes Householder-Vorzeichen, ein unkompensiertes Skalarprodukt oder eine spektrale Endinverse, und die Zeile sagt das.
• Optional zuschaltbare Quadratwurzelwege neben den unveränderten Standardwegen: fim::crlb_srif, batch_ls::gauss_newton_srif, orbit_determination::determine_orbit_batch_srif, lunar_combination::formal_covariance_srif, precise_od::fit_srif und cislunar_srif::srif_cross_validation_sqrt, auf den neuen linalg_sr::weighted_lstsq und covariance_from_sqrt_information. Jeder stimmt mit seinem Standardweg überein, wo beide genau sind (eine interne Prüfung, keine Zeile; für sie wird keine Validierung behauptet). precise_od::fit delegiert jetzt an eine gemeinsame Routine; ihre Ausgabe und die Standardausgabe jedes Szenarios sind unverändert.
• Rangentscheidungen der Mond-Bezugssystemkampagne: eine vorregistrierte Prüfung mit erweiterter Genauigkeit über 40 Tage bestätigt jede entscheidbare Stationsblock- und Vollrang-Helmert-Entscheidung. Die a-priori-Schranke kann die 20 rangdefizitären Helmert-Tage nicht belegen; in exakter Arithmetik ist ihr Defekt geometrisch, wobei die Schwelle 1e-9 innerhalb des natürlichen Bereichs der Eigenwertverhältnisse der Kampagne liegt. Keine Zeile.
• Die Aussage der Zeile zur Kampagne mit erweiterter Genauigkeit wird auf "innerhalb der Worst-Case-Schranke" eingegrenzt, und ihre Prüfung der schwächsten Richtung bei festen Stationen misst jetzt einen echten Winkel (6.6e-16 rad; der Vergleichsoperator wechselte von acos zu einer Sehne, der Zielwert nicht).
• Revisionen: keine. Keine Golden-Datei und keine veröffentlichte Zahl ändert sich; die Zeile "Lunar frame datum from an observing campaign" ist unverändert und bleibt MODELLED (Entscheidung des Gründers 2026-10-02, Option A).

D4, Rückgrat der JPL-Kernel-Ephemeriden, Phase 1 (vier neue Zeilen VALIDATED: 228 -> 232 Zeilen, 112 -> 116 validiert).

• Der NAIF-Kernel-Leser hat eine eigene Zeile. naif_kernel (DAF-Container, SPK-Typ 2, binäres PCK vom Typ 2) stimmt mit dem SPICE Toolkit (CSPICE N0067 über spiceypy 8.2.0) und mit ANISE 0.10.6 bei allen 600 DE440-Zuständen und 200 Mondorientierungsrotationen eines Zufallsgitters überein, das aus dem eigenen Hash des Vorregistrierungs-Commits gezogen wurde (abcd9133), innerhalb von Zielwerten, die vorab aus der Chebyshev-Auswertung in doppelter Genauigkeit abgeleitet wurden (schlechtester Wert 0,6 % des Zielwerts, 1.95e-3 m). Die Zeile behauptet, dass die Engine JPL-Kernel korrekt liest, nicht dass DE440 oder die analytische Reihe genau ist (tests/naif_reader_spice_oracle.rs).
• ephem_provider::KernelEphemeris: DE440- (oder beliebige SPK-Typ-2-) Positionen über den eigenen Leser der Engine, mit zweiteiligen TDB-Epochen und dem SHA-256 des Kernels für Berichte; sie setzt nie einen Systembarycentre für einen Planeten ein. LunisolarSource lässt einen Geometriepfad die analytische Reihe (die Voreinstellung) oder einen Kernel wählen.
• Optional zuschaltbarer Kernel-Mond für lunar-llr-datum und lunar-vlbi-fim: ein Schlüssel planetary_kernel_path liest den geozentrischen Mondmittelpunkt aus dem Kernel; sonst ändert sich nichts, und der Bericht erhält einen Block moon_ephemeris, der den Kernel und seinen SHA-256 nennt. Ohne den Schlüssel sind beide Berichte bytegleich mit früher.
• Kovarianz eines Punkts auf der Mondoberfläche auf dem Kernel-Pfad (neue Zeile VALIDATED): bei festen Stationen und der Bake auf dem DE440-Mond stimmt die Kovarianz der Bake mit einer SPICE-Lichtlaufzeit-Jacobi-Matrix (schlechtester Wert 1.7e-3 gegenüber einem Zielwert von 1 %) und einer NumPy-Inversion (4e-14 gegenüber 1e-9) überein, vorregistriert 4a51256 (tests/lunar_vlbi_surface_point_spice_oracle.rs). Die Zeile des analytischen Pfads bleibt MODELLED: beim analytischen Mond liegt ihr kleinstes Bake-Sigma 3,9 % unter der unabhängigen Referenz.
• Mond-Bezugssystemdatum aus einer realen Kampagne, Kernel-Mondmittelpunkt (neue Zeile VALIDATED): auf 447 ungesehenen Normalpunkten aus dem 2. Quartal 2019, vorregistriert 830d945a, bevor einer abgerufen wurde, stimmt die Datumskovarianz auf dem Kernel-Pfad mit der unveränderten SPICE- und NumPy-Referenz innerhalb von 7.6e-5 gegenüber Zielwerten von 1 % und 2 % überein (tests/validate_llr_datum_kernel_moon_fresh.rs). Der Gründer entschied, dass diese Zeile nur an frischen Punkten hochgestuft wird; die Diagnose mit bereits gesehenen Daten (c51f8b2) ist ein Befund, kein Beleg. Der Zielwert unterscheidet Mondmodelle nicht: Auch der analytische Mond besteht auf demselben Ausschnitt (schlechtester Wert 3.8e-3), die geplante Mutation (der Kernel-Mond eine Stunde zu spät) wurde nicht erkannt, und bei der Faltung bestand auch ein um etwa 4.650 km falscher Mondmittelpunkt (der Mond um den Erde-Mond-Schwerpunkt genommen). Die Zeile beansprucht die Kovarianz auf diesem Pfad, nicht den Mondmittelpunkt, und sagt das.
• Positionen von Sonne, Mond, Merkur und Venus aus DE440 bei UTC-Epochen (neue VALIDATED Zeile): KernelEphemeris::relative_position_utc stimmt mit Skyfield 1,54 auf 600 Positionen zwischen 1973 und 2026 überein, schlechtester Wert 2,96 m, innerhalb eines vorregistrierten Zielwerts (0bfafe6d), der durch die zweitermige Reihe TDB − TT festgelegt ist (tests/kernel_ephemeris_skyfield_oracle.rs). Planetenpositionen erhalten jetzt diese neue Kernel-Zeile; die Standish-Zeile und die Zeile der Planetenmonde sind unverändert, und die Monde warten auf ein Szenario, das sie braucht (Entscheidung des Gründers).
• Befunde: die eine Verfehlung des LLR-Datumsvergleichs (Sigma der z-Translation 1,025 % gegenüber 1 %) fällt auf 0,049 %, wenn nur der Mondmittelpunkt aus DE440 gelesen wird, an bereits gesehenen Daten (tests/validate_llr_datum_kernel_moon.rs); auf dem frischen Ausschnitt von 2019 besteht auch der analytische Mond, die Verfehlung von 2015 lag also randständig an der Geometrie jenes Quartals. Die analytischen Zeilen "Lunar frame datum from a REAL observing campaign" und "Lunar-surface-point coordinate covariance … kept distinct from the Earth-station one" bleiben MODELLED; ihre Texte zur unabhängigen Referenz verweisen jetzt auf die Zeilen des Kernel-Pfads.
• lunar_ephemeris sagt nicht mehr, dass die Engine keinen Leser für binäre Kernel hat; es verweist auf die Zeile des Lesers und erklärt, warum Raumfahrzeug-Kernel (Typen 13 und 21) weiterhin über Horizons kommen.
• Revisionen: keine. Keine Golden-Datei, keine veröffentlichte Zahl und kein bestehender Testwert ändert sich; die analytischen Berichte lunar-llr-datum, lunar-vlbi-fim und der Bericht lunar-vlbi-fim mit allen festen Stationen sind bytegleich mit früher (Präfixe des Ergebnis-SHA-256 9927aac2, cf1d2671, 25c357e4).

D9, gemessene Uhrenbibliothek "Clock Atlas" (drei neue Zeilen, eine VALIDATED: 232 -> 235 Zeilen, 116 -> 117 validiert).

• Gemessene Uhrenbibliothek (clock_library). Gerätekarten (weißes Phasenrauschen, weiße, Flicker- und Random-Walk-Frequenzmodulation, eine lineare Frequenzdrift und optional Phasenterme mit ein- bis vierfacher Frequenz pro Umlauf), angepasst an eine benannte gemessene Uhrenaufzeichnung und an zurückgehaltenen Daten bewertet; lückenbewusste Allan- und Hadamard-Varianzen; ein Konditionierungsdetektor, der jede Lücke, jeden Phasenausreißer, jeden Phasensprung, jeden Burst und jeden Frequenzsprung protokolliert und nichts von Datei- oder Tagesgrenzen weiß; Umwandlung einer Karte in das Rauschmodell der Slot-Zeitgebung, das erweiterte Kalman-Uhrenmodell und die Rauschpegel des Spoofing-Monitors. Leser für RINEX- und IGS-Uhrendateien, BIPM-Dateien je Labor und Circular T Abschnitt 1 (realdata::clk); eine gepoolte, hierarchische Alterungsschranke für UTC(k) (utck_bound, noch nicht bewertet).
• Rauschidentifikation per Autokorrelation bei Lag 1 (allan::lag1_noise_id, Riley und Greenhall 2004), neue Zeile VALIDATED (Bibliothek): stimmt mit allantools 2024,6 autocorr_noise_id auf 140 Fällen überein, ganze Zahlen identisch, schlechteste Differenz 9.6e-13 gegenüber einem Zielwert von 1e-9 (vorregistriert 2ec76864; tests/clock_library_lag1_noise_id_allantools.rs).
• Gemessene Gerätekarten mit Vorhersage auf zurückgehaltenen Daten, neue Zeile der Stufe MODELLED (ein Befund): Fit auf einem Drittel, Vorhersage der Allan-Abweichung der anderen zwei Drittel innerhalb eines Faktors von 1,5 (vorregistriert 2ec76864). GPS Block IIF auf einem frischen IGS-Fenster (2026-03-01 bis 14): 10 von 11; G27 ist auf der Zwei-Stunden-Skala optimistisch (schlechtester Faktor 1,510). Caesium (innerhalb, 1,070), OCXO (außerhalb, 2,348) und Strontium (innerhalb) werden berichtet, nicht blind. Die Empfängerkarte des JammerTest sowie die Karten für den Galileo-Maser und die Deep Space Atomic Clock sind blockiert. Eine Modellklasse für den TCXO des Empfängers ZED-F9P an 12 statischen Stationen in Wroclaw (Zenodo 6488497) scheitert: 1 von 11 blinden Stationen in einem offengelegten, korrigierten erneuten Lauf (tests/clock_library_device_cards_oracle.rs, tests/clock_library_f9p_cards_oracle.rs).
• GPS-Block-IIF-Karten mit Termen pro Umlauf, neue Zeile der Stufe MODELLED (ein Befund): auf einem zweiten frischen Fenster (2026-04-01 bis 14) liegen 9 von 11 innerhalb des Zielwerts; G03 (1,947) und G25 (1,581) sind optimistisch, weil ihre zurückgehaltenen Aufzeichnungen verrauschter sind als ihre Fit-Drittel; ohne die periodischen Terme scheitern alle 11 (vorregistriert fb475550; tests/clock_library_periodic_cards_oracle.rs).
• M002, Zustandsschätzung der Borduhr, Runde 3 (ein Befund, bleibt MODELLED): nach dem eingefrorenen Konditionierungsdetektor erfüllt das erweiterte Filter aus Runde 2 mit unveränderter Abstimmung und unveränderten Kriterien (a) und (c) erstmals auf allen 11 Satelliten; (b) scheitert bei G09 (0,894) und G26 (0,876) (vorregistriert fb475550; tests/clock_state_ext_igs_conditioned_oracle.rs).
• M010, Spoofing-Erkennung, Runden 3 bis 4b (bleibt MODELLED): Runde 3 blockiert (167 Trainingsepochen aus den anderen Sitzungen der JammerTest-Einheit gegenüber 3600); mit einer Karte der Modellklasse ZED-F9P (Runden 4 und 4b) löst der Uhrenmonitor bei allen 10 protokollierten Einsätzen null Fehlalarme vor dem Einsatz aus (Runde 2: 86), und 6 von 10 Einsätzen werden innerhalb von 10 s erkannt (Runde 2: 4); dieselben vier bleiben verspätet (tests/clock_library_tcxo_card_jammertest_oracle.rs).
• M083, Überschranke für UTC(k), Runde 3: prospektiv vorregistriert (fb475550) auf Circular-T-Ausgaben ab 465, noch nicht ausgeführt (tests/utck_bound_prospective_oracle.rs).
• Umgebung der unabhängigen Referenz: die Wroclaw-ZED-F9P-Aufzeichnung ist unter $KSHANA_ORACLES/data/wroclaw_f9p datengebunden (CC BY 4,0, etwa 1,5 GB); die IGS-Uhren-Fixtures sind mitgeliefert (IGS-Produkte, mit Quellenangabe).
• Revisionen: keine. Keine Golden-Datei, keine veröffentlichte Zahl und kein bestehender Testwert ändert sich; auf M001 (Holdover-Neuverankerung) wird nicht reagiert, weil keine Uhrenklasse hochgestuft wurde.

D8, ein validierter Propagations-, Bezugssystem- und Zeitpfad (drei neue Zeilen VALIDATED und M131 hochgestuft: 235 -> 238 Zeilen, validiert 117 -> 121).

Die Erdorbit-Arten, die eigene Zweikörper-, säkulare J2- oder nur auf Sternzeit beruhende Modelle mitführten, teilen sich jetzt einen Pfad: SGP4/SDP4-Elementsätze mit zweiteiligen Julianischen Daten, überführt in das GCRS und das ITRS (International Terrestrial Reference System) über die Kette IAU (International Astronomical Union) 2006/2000A, mit optionalen Erdorientierungsparametern.

• Neu: sgp4::MeanElementSet, sgp4::SgpOrbit, sgp4::Eop, sgp4::teme_to_itrs_matrix[_eop] und sgp4::gcrs_to_itrs_matrix[_eop]; Sgp4::new_at und Sgp4::propagate_at nehmen zweiteilige Epochen. Neu: jd2::Jd2::from_utc_calendar (SOFA-Konvention dtf2d für Schaltsekundentage), jd2::utc_to_tai, tai_to_utc, utc_to_ut1 (über TAI, wie SOFA utcut1), tai_to_tt und ein zweiteiliges jd2::earth_rotation_angle.
• Der Polarmodus von leo-pvt propagiert per SGP4 bei 2026-01-01T00:00:00 UTC auf der IAU-Kette (leo_fusion::polar::latitude_sweep_at nimmt jede Epoche); der SGP4-Walker-Generator rotiert über die IAU-Kette in das erdfeste System.
• Die Art passes führt einen neuen Prädiktor für scheinbare Überflüge aus (passes::predict_passes_apparent, apparent_look_angles): SGP4 auf der IAU-Kette, Refraktion nach ITU-R P.834-9 und die Downlink-Lichtlaufzeit (neue Schalter refraction und light_time, standardmäßig an), Erdorientierungsparameter (ut1_minus_utc_s, xp_arcsec, yp_arcsec, Voreinstellung 0), Durchgänge bis 1e-7 s gelöst und die Kulmination per Goldener-Schnitt-Suche. Der geometrische passes::predict_passes ist unverändert.
• tests/no_private_models.rs sorgt dafür, dass die Geometrie-, Zeit- und Propagationskerne des Pakets keine private Kepler-Propagation, keine säkularen J2-Raten und keine reine Sternzeitrotation mitführen; benannte schnelle Stufen und Physik, die Gegenstand einer Zeile ist, sind begründete Ausnahmen.
• Neue VALIDATED Zeile "Two-part Julian dates and leap seconds on the Earth-orbit time path": pyerfa 2.0.1.5 dtf2d/utctai/taiutc auf 224 Zeitpunkten rund um alle 27 Schaltsekunden innerhalb von 1e-6 s (vorregistriert e947e69d); schlechtester Wert 1.9e-11 s.
• Neue Zeile VALIDATED "One Earth-orbit path": TEME-Positionen von 232 Elementsätzen gegenüber python-sgp4 2,24 (Vallados Referenz-SGP4) innerhalb von 6.1e-8 m (Zielwert 1 cm), und die Rotationen GCRS -> ITRS und TEME -> ITRS gegenüber ERFA c2t06a, pnm06a und ee06a innerhalb von 2.9e-6 mas und 0,41 mas (Zielwerte 0,1 und 2 mas), mit Erdorientierungsparametern (vorregistriert 72ea9eb0). Offengelegt: der erste Lauf scheiterte bei 2016-12-31T23:59:59,5 um eine Sekunde Rotation; UT1 wurde an einem Schaltsekundentag aus dem quasi-julianischen Datum von UTC genommen, die Engine geht nun über TAI, und der zweite Lauf stimmt bei unveränderten Zielwerten überein.
• M131 "LEO coverage and dilution of precision for polar and Arctic users against MEO GNSS" wird VALIDATED: Orekit 13.1.8 nimmt die GCRS-Zustände der Engine, rotiert sie und berechnet Sichtbarkeit und DOP (NumPy für Mehr-Uhren-Gruppen); Positionen innerhalb von 6.8e-5 m (Zielwert 0,2 m), Anzahlen sichtbarer Satelliten identisch bei 4040/4040 Stichproben, mittleres DOP innerhalb von 2.3e-11 relativ.
• Neue VALIDATED Zeile "Apparent ground-station pass prediction with refraction and light time": Orekit 13.1.8 propagiert dieselben Elementsätze in einem TEME, das es nach der angegebenen Definition aufbaut, mit ITU-R-P.834-Refraktion und seinem Lichtlaufzeit-Messmodell, über 60 Fälle an Stationen auf Meereshöhe: 1210 Überflüge, Durchgänge innerhalb von 3.4e-6 s (Zielwert 5 ms), maximale Elevation innerhalb von 5.5e-7 Grad, scheinbare Richtung innerhalb von 8.8e-7 Grad (Zielwert 1e-4 Grad).
• Befunde, festgeschrieben: die ersten Vergleiche der vollen Aussage mit Orekit Ende zu Ende verfehlten ihre Positions- und Richtungszielwerte, nicht wegen der Engine, sondern weil das SDP4 von Orekit 13.1.8 bei kreisförmigen (e = 0) Deep-Space-Bahnen vom Referenz-SGP4 abweicht (bis zu 67 m) und sein Standard-TEME auf der Nutation nach IERS 1996 (IAU 1980) aufbaut, etwa 72 Millibogensekunden von der Kette IAU 2006/2000A entfernt (2,7 m bei LEO). Der Koeffizient von h*theta0^2 in ITU-R P.834 ist bei Orekit 0,011380, wo die Empfehlung 0,01380 druckt; der Vergleich erfolgt auf Meereshöhe, wo der Term verschwindet, und die Differenz darüber ist festgeschrieben.
• "Ground-station pass prediction (ground segment)" bleibt VALIDATED, wobei ihre Aussage auf den geometrischen passes::predict_passes eingegrenzt wird; die Art passes gehört zur neuen Zeile.
• Umgebung der unabhängigen Referenz: Orekit 13.1.8 mit Hipparchus 4.0.3, pyerfa 2.0.1.5, python-sgp4 2,24 (xval/d8-orekit13/setup.sh).
• Revisionen: mitgeliefertes scenarios/passes.toml Gesamtzugang 1675 s -> 1659 s (fünf Überflüge wie zuvor; beste maximale Elevation 73,25 Grad -> 70,08 Grad), und jede Ausgabe von passes verschiebt sich mit dem neuen Pfad (die gedruckte Zeile in docs/examples/multi-tool-pipeline.md und der Eintrag passes von docs/CAPABILITY.md sagen das jetzt); mitgeliefertes polar-arctic-leo-coverage GNSS-VDOP am Äquator 1,19669 -> 1,19710, bei 89,9 Grad 1,50645 -> 1,50590, fusioniertes VDOP bei 89,9 Grad 1,14388 -> 1,14250 (die veröffentlichten Zahlen mit zwei Dezimalstellen 1,20, 1,51 und 1,14 sind unverändert). Keine Golden-Datei ändert sich.
• Noch nicht geroutet: leo_pass, die Doppler-, Gemeinsam- und Zeitgebungsmodi von leo-pvt und die Wahrheitsbahn von leo_navmsg (ihre Modelle liegen in leo_link::geometry und leo_fusion::geom) sowie Erd-Designs in constellation-design (eine benannte schnelle Zweikörperstufe).

D6, Referenzgenerator für LunaNet AFS, LSIS V1.0 (vier neue Zeilen, zwei VALIDATED: 238 -> 242 Zeilen, validiert 121 -> 123).

• Referenzgenerator für das LunaNet Augmented Forward Signal (AFS) (lunar_afs), festgelegt auf den LunaNet Signal-In-Space Recommended Standard (LSIS) V1.0 vom 29. Januar 2025 und mit Nennung dieser Version in jeder Ausgabe: der Träger 2492,028 MHz; der AFS-I-BPSK(1)-Datenkanal mit 500 Symbolen pro Sekunde und seinem Gold-Code mit 2046 Chips; der AFS-Q-BPSK(5)-Pilot mit seinem primären Weil-Code mit 10230 Chips, dem sekundären Code mit 4 Chips und dem tertiären Code mit 1500 Chips; der Frame mit Frame-Kennung 0 (Synchronisationsmuster, BCH (51, 8) Subframe 1, CRC-24, LDPC-Subframes mit Rate ein Halb 2 bis 4, Blockinterleaver 60 mal 98) mit einem erschöpfenden Subframe-1-Decoder und einem Min-Sum-LDPC-Decoder, der allein aus der Paritätsprüfmatrix geschrieben wurde; und Basisband-IQ-Synthese mit Wahrheitsetiketten, geschrieben als SigMF-Aufzeichnung. Die Codes werden aus den Schieberegistern und den Legendre-/Weil-Konstruktionen des Standards erzeugt. Nichts aus dem Standard Kopiertes wird weiterverbreitet (er enthält keine Wiederverwendungsbedingungen): die primären AFS-Q-Indizes stammen aus IS-GPS-800J, und was nur die Anhänge des Standards festlegen (AFS-I-G2-Verzögerungen, tertiäre Codes, LDPC-Teilmatrizen), wird zur Laufzeit aus einem lokalen Cache gelesen, den xval/lunar-afs/fetch_lsis.sh aus dem von der NASA gehosteten PDF füllt, jede Datei geprüft gegen ein festgelegtes SHA-256 (lunar_afs::lsis). Das Modell ist eine Referenz für die Übereinstimmung mit dem Standard, kein Kanal-, Ausbreitungs- oder Link-Budget-Modell.
• sigmf::meta_to_json_with_extensions und sigmf::annotation_extension_fields: eine Aufzeichnung kann Erweiterungsfelder mit Namensraum tragen, die in core:extensions deklariert sind.
• Neue Zeile VALIDATED "LunaNet AFS baseband rendering against an independent generator, given its channel state": gegenüber LANS-AFS-SIM (BSD-2-Clause, Commit 480c6bf3, S-Band-Build) null Chip-Abweichungen über die Codes der PRNs 1 bis 210, null Symbolabweichungen über die drei Frames des Laufs und eine normierte komplexe Korrelation von 0,999990 über 23,9 s seiner eigenen Abtastwerte (schlechtester Block von 2 ms 0,999948), innerhalb von Zielwerten, die vor dem Vergleich festgelegt wurden (vorregistriert 986ac280). Sie steuert den Renderer mit dem eigenen Kanalzustand des Simulators an und deckt weder die Leistungsaufteilung aus der Trägerrauschdichte noch das Schreiben von SigMF und 8 Bit ab.
• Neue Zeile der Stufe VALIDATED "LunaNet AFS frame channel coding, FID 0": die Frames mit 6000 Symbolen sind Symbol für Symbol gleich denen von LANS-AFS-SIM (vorregistriert 986ac280); der Subframe-1-Code reproduziert das Rechenbeispiel in Abbildung 8 des LSIS, und der CRC-24 den Prüfwert aus dem Katalog CRC-24/LTE-A.
• Beide hochgestuften Zeilen sind an den LSIS-Cache datengebunden: ihr Test zur unabhängigen Referenz wird mit einem Hinweis übersprungen, bis xval/lunar-afs/fetch_lsis.sh ausgeführt wurde.
• Befund (neue Zeile MODELLED), "LunaNet AFS spreading-code generation": von 2.937.232 erzeugten Chips und Bits, die mit den Tabellen des Standards und den Dateien von Annex 3 verglichen wurden, weicht einer ab, die "last 24 chips" aus Tabelle E-5 für den tertiären PRN 147, die die Zelle von PRN 151 dupliziert, während die eigene Datei von Annex 3 des Standards mit dem Generator übereinstimmt. Das Kriterium null Abweichungen wird verfehlt.
• Befund (neue MODELLED Zeile), "LunaNet AFS closed-loop decodability": drei vorregistrierte Läufe gegen PocketSDR-AFS; der dritte erfüllte seine Zielwerte für Tracking und Dekodierung vollständig, nicht aber seine Absicherung, dass ein Empfänger-Build mit reiner Druckausgabe das Protokoll des festgelegten Builds reproduziert, weil sich schon zwei Läufe des unveränderten Empfängers in ihren Akquisitionsaufzeichnungen unterscheiden.
• Korrigiert: der Standardträger von lunar_service (export_antenna.carrier_hz), lunar_jamming und attack_surface war ein gerundetes 2,4 GHz; er ist jetzt der AFS-Träger aus LSIS-020, 2492,028 MHz. Beim alten Standardwert war die Freiraumdämpfung um 0,327 dB zu niedrig angesetzt.
• Revisionen: keine. Jedes mitgelieferte Szenario nennt seinen Träger, und die Ergebnisse aller 138 Szenariodateien sind bytegleich mit dem vorherigen main.

D7, reale lunare IQ-Daten und GPS LNAV (sieben neue Zeilen, keine VALIDATED: 242 -> 249 Zeilen, validiert 123 unverändert).

• portable_math::FftPlan: eine schnelle Fourier-Transformation (FFT) mit gemischter Basis, deren Ausgabe auf jeder Plattform dieselben Bits ergibt; ein SHA-256-Pin der Transformationen mit 8000 und 24000 Punkten besteht auf x86_64 und auf wasm32-wasip1 (Runner in xval/portable-fft-wasm/).

• acquisition: parallele Codephasensuche auf abgetasteten IQ-Daten (pcps_acquire, pcps_grid) mit kohärenter Faltung, nichtkohärenter Akkumulation, einer Chi-Quadrat-Schwelle für eine suchweite Fehlalarmwahrscheinlichkeit und einer zellmittelnden Statistik für bandbegrenztes Rauschen; refine, prompt_series mit Code-Doppler sowie die Schätzer für die Träger-Rauschleistungsdichte (C/N0) nach M2M4 und aus der Gitterspitze.

• gps_lnav: ein Encoder für die Legacy-Navigationsnachricht (LNAV) nach IS-GPS-200 für die Subframes 1 bis 3, mit der Parität aus Tabelle 20-XIV und einem Felddecoder.

• realdata::ion_sdr: ein Leser für den ION GNSS SDR Metadata Standard (.sdrx) und seine Beispieldateien, mit to_mid_rise für Zweierkomplement-Pegel.

• realdata::lugre: der IQS-Batch-Header des LuGRE (Lunar GNSS Receiver Experiment), RAW-, ACQ- und NAV-Telemetrie sowie CLK-Dateien und eine Prüfung, die auflistet, wo die Metadaten von .sdrx dem binären Header widersprechen.

• antenna::GainPattern2D und, in earth_gnss_lunar, das Yaw-Steering-Körpersystem, Sendeazimut und Off-Nadir-Winkel sowie transmit_side_db für relatives C/N0 mit gemessenen Mustern.

• Kodierung der GPS-LNAV-Navigationsnachricht (neue Zeile, bleibt nach der Nachverifikation durch den Integrator MODELLED): auf der IGS-Broadcast-Datei vom 2. März 2025, von RTKLIB v2.4.2-p13 geparst und dekodiert, bestehen alle 960 Wörter die Paritätsprüfung, alle 96 Subframes dekodieren und alle 608 Broadcast-Ganzzahlen sind gleich denen von Kshana (tests/gps_lnav_rtklib_integer_oracle.rs), aber die Vorregistrierung (d4d9eb9d) erreichte den öffentlichen Branch zwei Sekunden nach dem Commit mit dem Ergebnis, sodass die Reihenfolge "registriert, bevor die Datei abgerufen wurde" nicht gezeigt werden kann und die Zeile nicht hochgestuft wird.

• realdata::ion_sdr füllt Wörter ab dem höchstwertigen Bit (I im oberen Nibble eines LuGRE-Bytes; die frühere Lesart ergab das konjugierte Signal), behält die alte Lesart als SdrLayout::fill_lsb_first und liest Abtastwerte, die breiter als ein Wort sind.

• acquisition::refine_doppler_coherent: phasenkohärente Doppler-Verfeinerung (0,2 Hz RMS bei 30 dB-Hz über 200 ms in der Simulation).

• GPS L1 C/A gegenüber gps-sdr-sim: Chips und Paritätsbit bitgenau; 230 von 1152 LNAV-Feldern unterscheiden sich um eine Einheit, weil gps-sdr-sim abschneidet, wo die Broadcast-Ganzzahl Rundung braucht.

• LNAV dekodiert von RTKLIB: alle Paritäten und Subframes bestehen, und jeder Parameter liegt innerhalb eines halben Quantums; 41 skalierte Werte weichen durch die dezimale Konstante 2^-43 von RTKLIB um einige Einheiten in der letzten Stelle ab, über dem registrierten Zielwert.

• LuGRE-Akquisition gegenüber GNSS-SDR 0.0.19: 266 von 266 Entscheidungen stimmen überein, 250 auf derselben Zelle lokalisiert; die meisten Positiven sind Artefakte eines Mittelwerts von −0,5 in den nackten 4-Bit-Pegeln; für den C/N0-Zweig gab es keine zeitgleichen Flugdaten. Zwei Batches (OP5, OP12) wurden irrtümlich ausgeschlossen: ihre Metadaten stimmen mit ihren Headern überein, aber der Leser konnte damals keinen Abtastwert lesen, der breiter als ein Wort ist.

• LuGRE-Akquisition gegenüber bahnvorhergesagtem Doppler: bei der Entscheidung nach Abtastleistung kreuzt jede Suche auf bandbegrenztem Rauschen; bei der zellmittelnden Entscheidung stimmen die stärksten Paare im Betrag überein, mit umgekehrtem Vorzeichen, was zeigt, dass die registrierte I/Q-Reihenfolge das Konjugierte der Daten ist.

• Blinde Akquisition auf den Batches der Mondoberfläche: vier Batches erfassen je einen Satelliten (als sichtbar vorhergesagt, kein Fehlalarm bei 1e-7), keiner zwei, sodass der Zielwert für die Doppler-Differenz kein Paar zum Bewerten hat.

• Relatives C/N0 in Monddistanz (M039 neu formuliert): 15 Aufzeichnungen von Block IIR/IIR-M und ein Paar, zu wenig für den registrierten Zielwert.

• Revisionen: keine; keine veröffentlichte Zahl, keine Golden-Datei und keine Zahl der Dokumentation hat sich geändert.

• Die M039-Zeile "Earth-GNSS at lunar distance" formuliert ihre Aussage in Monddistanz neu als das relative C/N0 zwischen Satelliten zu einer Epoche plus Sichtbarkeit (ein absolutes C/N0 wird nicht behauptet); sie bleibt MODELLED. Der NOTICE auf oberster Ebene trägt die Namensnennung für LuGRE CC BY 4,0.

Behoben#

• Die DE440-Hauptachsenorientierung des Mondes wird jetzt entlang der Geodäte zwischen den Tagesknoten interpoliert. Die frühere elementweise Interpolation war nahe den Viertelpunkten jedes Tages um bis zu 2.0e-4 rad (340 m an der Mondoberfläche) fehlerhaft, nicht "etwa 14 m", wie die Zeile angab. Ihre Nutzer (Geometrie der Laserentfernungsmessung zum Mond, Mond-Datum, Beobachtbarkeit von Mondverwerfungen) erhalten die korrigierte Orientierung.
• Engine-Korrekturen der Runde 2, jeweils erneut gegen die unveränderte vorregistrierte Toleranz ausgeführt: die IERS-Ausgabe einer EOP-Zeile wird aus ihren I/P-Kennzeichen gelesen statt aus einem leeren Bulletin-B-Block; snapshot_raim verwendet das geodätische lokale Niveau; die Ratenkopplung im Mondbezugssystem verwendet Äquatorradius, J2 und Rotation; der liu22-Fit beginnt mit Korrekturen von null ohne Priors und verwendet die Rate der mittleren Bewegung aus der Veröffentlichung; der Knotenabstand für EO enthält die J2-Knotenregression; die Cycle-Slip-Zeit der Costas-Schleife verwendet rho/4; der gemeinsame Fix wendet die Broadcast-Gruppenlaufzeit des Paars an; die gemeinsame lunare Lösung verwendet einen QR-Schritt; die NTN-Schranke wird an der wahren Position ausgewertet; die Uhrenreferenz des Konstellationsdesigns ist die Konstellation mit der niedrigsten Nummer in Sicht; die DE440-Orientierungsreihe umfasst 2014-2030 und meldet außerhalb davon Fehler, statt zu begrenzen.

Hinzugefügt#

• leo_navmsg::truth::TruthOrbit::from_ecef_states, eine Wahrheitsbahn, aufgebaut aus tabellierten erdfesten Zuständen, verwendet beim Vergleich des Fitters mit realen Bahnen.
• Die Testdateien und Fixtures der obigen Vergleiche, jeweils mit ihrem Generator und einem NOTICE.md mit Quelle, Lizenz, Abrufdatum und SHA-256.
• Runde 2: araim_reference::add_v42_protection_levels und _ecef (Fehlererkennung nach ADD v4.2, nach Stanford MAAST für ARAIM 2, BSD-3-Hinweis im Quelltext); raim::snapshot_raim_fde; cw_dynamics::second_order_correction und propagate_second_order; das INS-Fehlermodell mit neun Zuständen inertial::coast::ErrorDynamics; Partialableitungen von lunar_vlbi::KernelGeometry und die Eingaben von lunar-vlbi auf dem Kernel-Pfad; naif_kernel, ein Leser für SPK-Typ 2 und binäre PCK-Kernel; lunar_llr_geometry::llr_bcrs_one_way_m mit ITRF2020-Stationen; Dichte nach Jacchia 1971; solar_system::link_on über jeden Ephemeridenanbieter; launch::site_rotation_speed_at; eo_payload::j2_nodal_period und ground_track_spacing_equator_j2; batch_ls::gauss_newton_qr; precise_products (Leser für RINEX-Uhren, ANTEX und DCB).

[0.29.3] - 2026-10-01#

Ein Patch-Release auf 0.29.2. Kshana Studio ist um zwei Ansichten neu aufgebaut: eine Einfache Ansicht, die zuerst antwortet und in einfachen Worten erklärt, und eine Erweiterte Ansicht mit dem vollständigen Dashboard. Zwei kleine Korrekturen auf kshana.dev kommen hinzu. Die Engine ändert sich nicht: Jedes mitgelieferte Szenario liefert bis auf den Versionsstempel ein byte-identisches Ergebnis zu 0.29.2.

Geändert#

• Kshana Studio hat eine Einfache Ansicht. Mit ihr öffnet sich das Studio.
  • Die Antwort kommt zuerst: Ein Szenario öffnet sich mit seinem Ergebnis, in einem einfachen Satz formuliert. Jedes mitgelieferte Szenario hat einen eigenen Satz, geschrieben für das, was dieses Szenario misst.
  • Höchstens fünf Einstellungen sind sichtbar, nämlich die, die die Antwort am stärksten verändern. Die übrigen stehen unter „Erweiterte Einstellungen“, eingeklappt, bis Sie sie öffnen.
  • „So wird es berechnet“ erklärt die Methode in wenigen Zeilen, und „Für Forschende“ zeigt die eigenen Zahlen der Engine, die Szenariodatei und die Belege hinter dem Ergebnis.
• Das vollständige Dashboard ist die Erweiterte Ansicht. Jedes Panel, jedes Diagramm, jeder Export und jeder Bericht des früheren Studios ist dort vorhanden.
• Ein Schalter wechselt zwischen den beiden Ansichten und behält Ihre Position bei. Das Szenario, die Ansicht, in der Sie waren, und alle bearbeiteten Einstellungen werden übernommen. Das Studio merkt sich, welche Ansicht Sie zuletzt benutzt haben. Links von der Website und aus der Dokumentation öffnen die Einfache Ansicht; ein Link mit view=advanced öffnet die Erweiterte Ansicht, und jeder frühere Studio-Link öffnet weiterhin dasselbe Szenario in derselben Ansicht.
• Eine schnellere erste Ansicht bei langsamen Verbindungen. Die aufgezeichnete Antwort eines Szenarios wird gezeichnet, bevor der Rest des Studios geladen ist; bei einer langsamen mobilen Verbindung erscheint die Antwort so nach etwa zwei Sekunden statt nach etwa neun.
• Bessere Suche. Eine Suche listet nun zuerst Szenarien auf, deren Bereich oder Titel zu den Wörtern passt, vor Szenarien, die sie nur im Dateinamen oder im Text erwähnen.

Behoben#

• Der Globus auf der Startseite wird bei eingeschalteter reduzierter Bewegung nicht mehr leer. Bei eingeschalteter Systemeinstellung für reduzierte Bewegung konnte das Ändern der Fenstergröße den Hero-Globus leer lassen, bis die Seite gescrollt wurde. Der Globus wird nun im selben Frame wie die Größenänderung neu gezeichnet.
• Die L-Band-Konsole auf der Startseite erklärt ihr leeres Band. In „Watch a jammer take the band“ blieb das Panel GPS L5 / Galileo E5a die ganze Minute lang dunkel, was wie ein Defekt wirkte. In diesem Szenario sendet kein Jammer in diesem Band, und die Satellitensignale liegen unter dem Rauschteppich, sodass sich dort nichts über ihn erhebt. Ein dezentes Etikett sagt das nun in jedem Panelabschnitt, in dem nichts über dem Rauschteppich liegt (das Panel L5 / E5a und das Panel L2C, bevor sein Rauschjammer startet), zusammen mit dem C/N0 und dem Lock-Zustand jedes Bandes aus demselben Lauf. Es wird nur dort gesetzt, wo nichts über dem Rauschteppich liegt, und verdeckt daher nie Jammer-Energie.

0.29.2 - 2026-10-01#

Ein Patch-Release auf 0.29.1. Es entfernt doppelten Code in den LEO-Navigationsnachrichten-, Fusions- und Spektrummodulen, fügt kshana.dev ein helles Thema hinzu, verlegt Kshana Studio auf eine eigene Adresse, macht die Website für Suchmaschinen und KI-Assistenten lesbar, behebt mehrere Kleinigkeiten im Studio und lässt npm-Releases ohne gespeichertes Token veröffentlichen. Keine Engine-Ausgabe ändert sich: Jedes mitgelieferte Szenario liefert bis auf den Versionsstempel ein byte-identisches Ergebnis zu 0.29.1.

Hinzugefügt#

• Ein helles Thema für kshana.dev. Jede Seite kann hell oder dunkel gelesen werden. Die Website folgt der Systemeinstellung der lesenden Person und hat einen Schalter zum Ändern.
• Suchmaschinen und KI-Assistenten können die Website lesen. Jede Seite hat nun einen eigenen Titel, eine eigene Beschreibung, eine kanonische Adresse, Social-Card-Tags und strukturierte schema.org-Daten sowie Klartext für die Abschnitte, die ein Skript zeichnet. Die Website veröffentlicht robots.txt, eine sitemap.xml mit dem Datum der letzten Änderung jeder Seite, llms.txt und llms-full.txt (einen kurzen und einen vollständigen Klartext-Leitfaden für KI-Assistenten) sowie einen IndexNow-Schlüssel, damit ein Deploy Suchmaschinen mitteilen kann, was sich geändert hat.
• npm-Releases können ohne gespeichertes Token veröffentlichen. Der npm-Job läuft nun mit Node 24 und npm 11.5.1 oder höher, die npm Trusted Publishing unterstützen: npm tauscht die GitHub-Identität des Release-Jobs gegen eine kurzlebige Anmeldeinformation. Das Secret NPM_TOKEN funktioniert weiterhin und wird verwendet, solange es gesetzt ist; es ändert sich also nichts, bis Trusted Publishing für das Paket auf npmjs.com eingeschaltet wird. docs/RELEASING.md listet die Schritte auf.

Geändert#

• Die Überschrift der Startseite ist über dem Globus lesbar. Ein weicher Schatten liegt nun hinter der Überschrift und ihrem Text und blendet die Bahnlinien und Satellitenpunkte des animierten Globus aus, wo sie ihn kreuzen.

• Kshana Studio hat eine eigene Adresse: https://kshana.dev/studio/. Jeder Link auf der Website und in der Dokumentation zeigt dorthin. Die alte Adresse /playground/ funktioniert weiterhin und leitet zur neuen weiter, wobei Szenario, Ansicht und andere Einstellungen im Link erhalten bleiben.

• Studio-Korrekturen. Die Engine-Datei wird einmal statt zweimal heruntergeladen. Während des Downloads zeigt das Studio sofort das aufgezeichnete Ergebnis des Szenarios, als aufgezeichnet gekennzeichnet, statt eines leeren Bildschirms. Auf einem Smartphone ist die Kopfzeile eine kompakte Zeile. Die Kennzahlen umbrechen zu zweit pro Zeile, sodass keine über den Bildschirmrand hinausragt. Feldbezeichnungen verwenden die eigenen Worte des Szenarios mit dem Feldnamen daneben, und die Suche findet Felder über beides.

• Weniger doppelter Code. Die Einheitentabelle der LEO-Navigationsnachricht schrieb dieselben zehn SISRE-Statistikzeilen für vier Fit-Zusammenfassungen. Ein Makro schreibt sie nun einmal. Die beiden Spektrum-Wasserfalldiagramme teilen sich eine Zeitachse, eine Farbleiste und ein C/N0-Balkenpanel. Das Downsampling des Hauptgitters verwendet downsample_grid wieder, und das Simpson-Integral verwendet navsignal::simpson wieder. Die zwei Einstiegspunkte der LEO-Durchlaufart teilen sich einen Einrichtungsschritt. leo_link::geometry importiert die Vektorhilfen von leo_fusion::geom, statt sie zu kopieren. Der erweiterte Bericht importiert das HTML-Escaping des API-Berichts, statt es zu kopieren. Jede der 139 Szenariodateien in scenarios/ wurde auf 0.29.1 und mit diesem Code ausgeführt, und jede Ausgabedatei ist byte-identisch.

• Die Einheitentabellen von leo-navmsg und leo-pvt haben eigene Dateien. Sie wurden aus Modulen, die auch Logik enthalten, nach src/leo_navmsg/units.rs und src/leo_fusion/pvt_units.rs verschoben. PVT_UNITS behält seinen öffentlichen Pfad. Nur diese beiden Tabellendateien kommen zu den Ausnahmen der Copy-Paste-Erkennung für deklarative Kataloge in sonar-project.properties hinzu, die tests/sonar_cpd_exclusions_are_justified.rs prüft.

Behoben#

• Das CI-Badge der README zeigt das Ergebnis von Pushes auf main. Das Badge zählte Läufe jedes Ereignisses auf main, sodass es „failing“ anzeigen konnte, obwohl jeder Push-Lauf grün war; es fragt nun nur Push-Läufe ab (event=push).

0.29.1 - 2026-10-01#

Ein Patch-Release auf 0.29.0: die gemessene Abdeckungszahl, die Namenszeile des Projekts auf kshana.dev, ein schnellerer Coverage-Job und eine überarbeitete README. Keine Engine-Ausgabe ändert sich: Jedes Szenario liefert dasselbe Ergebnis wie auf 0.29.0.

Korrekturen an veröffentlichten Zahlen#

• Zeilenabdeckung: ~96 % → ~95 %. Der Coverage-Job hat den freigegebenen Code von 0.29.0 neu gemessen (Commit db796dd, CI-Lauf 36809850252, 2026-10-01): 95.35 %, 55.970 von 58.697 Zeilen in src/. Die veröffentlichte Zahl war 95,63 % (37.697 von 39.419 Zeilen), gemessen auf b1d350d vor 0.28.0; sie rundete auf ~96 %. Die neue Zahl rundet auf ~95 %, sodass sich jede Stelle, die tests/coverage_figure_doc_sync.rs festhält, gemeinsam ändert: docs/COVERAGE.md, das README-Badge, die Evidence-Zeile und die CI-Tabelle, die Badges von crates.io, PyPI und npm, der technische Bericht und die Coverage-Seite auf kshana.dev. Die Untergrenze von 85 % bleibt unverändert.

Hinzugefügt#

• Die Namenszeile auf kshana.dev. „Kshana · क्षण · the precise instant“ eröffnet nun den Home-Hero und steht in der Fußzeile jeder Seite unter der Marke. kshana.dev stellt weiterhin keine Anfrage an einen anderen Host: Die Devanagari-Schrift ist eine selbst gehostete Noto-Sans-Devanagari-Teilmenge der drei Buchstaben von क्षण (1.692 Bytes, web/fonts/, mit ihrem Text der SIL Open Font License und ihrem SHA-256 in web/fonts/FONTS.json). web/tools/fetch_third_party.py kann nun eine Google-Fonts-Teilmenge mit text= unter einem inhaltsadressierten Dateinamen speichern.

Geändert#

• Die Links der Website landen dort, worauf sie zeigen, mit sauberen Adressen. Ein Link zu einem Abschnitt setzt diesen Abschnitt auf Smartphone und Desktop knapp unter die Kopfzeile: Ein Missions-Sektor-Link öffnet diesen Sektor mit seinem Panel oben; Links zu Capabilities und Editions halten ihre Position, während die Diagramme darüber gezeichnet werden; Editions fügt keinen zweiten Kopfzeilenversatz mehr hinzu; und ein Link in einen eingeklappten Teil einer Docs-Seite öffnet ihn. Jede Seite wird über ihre saubere Adresse verlinkt (/evidence#research, /docs/changelog, / für Home), und die kanonischen Links, die Sitemap und die Weiterleitungen alter Adressen nennen dieselben; die Adressen mit .html funktionieren weiterhin. Research hat einen eigenen Link in der Kopfzeile, zwischen Evidence und Developers, und in der Fußzeile. Die Docs zeigen die Roadmap nicht mehr (ROADMAP.md bleibt im Repository): Die Gruppe Project besteht aus Changelog, Licensing, Security, Contributing, Governance und Code of conduct, und das Glossary ist zu Get started umgezogen.
• Der Coverage-Job ist schneller. Auf 0.29.0 dauerte er 143 Minuten gegenüber gesunden 91 bis
  94. Der Fuzzer tests/property.rs, beim letzten Mal die Ursache, benötigte 4 davon. Das mitgelieferte Korpus wuchs von 74 auf 139 Szenarien, und drei Test-Binaries gingen es Datei für Datei vollständig durch (determinism zweimal, advanced_report und animation je einmal): zusammen 37 Minuten unter Coverage-Instrumentierung, gegenüber 3 auf 0.27.2. Sie teilen sich nun tests/support/corpus.rs, das die Arbeit pro Szenario auf allen Kernen ausführt und die Ergebnisse sortiert zurückgibt; jedes Szenario und jede Assertion bleibt erhalten. Auf einem arm64-Laptop, Debug-Build: determinism braucht 143 s auf 14 Kernen gegenüber 612 s mit KSHANA_CORPUS_THREADS=1 (dem alten seriellen Durchlauf).
• Die README, überarbeitet. Sie beginnt mit derselben Namenszeile wie die Website; die Studio-Screenshots sind vom Studio 0.29.1 neu aufgenommen, mit einem neuen vom Studio auf einem Smartphone und seiner unteren Schrittleiste; ein neuer Streifen „The site“ zeigt drei Seiten von kshana.dev aus dem Build 0.29.1 (tools/capture_site_shots.mjs, zusammengestellt von tools/readme_shots.py und festgehalten in docs/assets/readme/site/SHOTS.json); die Coverage-Zahl lautet ~95 %; und der Alternativtext der Research-Abbildung, der den der Architekturabbildung wiederholte, beschreibt nun die Papers. Die Header-Badges sind kleiner und kürzer (18 px hoch; „~95%“, „83/223“, „quality“, „AGPL-3.0“, „zenodo.20528627“), sodass die elf auf zwei Zeilen passen; jeder Link und jeder Alternativtext behält seine volle Bedeutung.
• Der Container-Image-Job erhält 90 Minuten. Bei v0.29.0 erreichte der emulierte linux/arm64-Build des Images kshana-mcp beim Kompilieren seines letzten Crates das alte Limit von 45 Minuten, sodass das Image, der Eintrag in der MCP-Registry und die Kanalprüfung nicht veröffentlicht wurden. Das Limit beträgt nun 90 Minuten; das Image ist unverändert.
• Acht Float-Literale neu gruppiert in src/ephem.rs und src/sgp4.rs (0.323_273_64 → 0.323_273_640): SonarQube Cloud las eine letzte Gruppe _64 oder _32 als fehlendes Suffix f64 oder f32 (Regel S7454). Die Werte sind dieselben Zahlen, sodass jedes Ergebnis unverändert bleibt.

0.29.0 - 2026-10-01#

Zwölf neue Szenarioarten und drei neue Arten, einen Lauf zu lesen. Die Engine deckt nun das Funkspektrum, das gesamte Sonnensystem, Konstellationen um jeden Körper, Kampagnen, die Szenarien zu einer Mission verketten, sowie Positionierung, Navigation und Zeitgebung (PNT) aus der niedrigen Erdumlaufbahn (LEO) vom Signal bis zur Lösung ab. Jeder Lauf kann außerdem als Animation, als vollständiger Bericht und als Satz von Interoperabilitätsdateien für andere Werkzeuge geschrieben werden.

Rund um die Engine: eine neu gestaltete kshana.dev (eine mehrseitige Website und ein neues Dashboard Kshana Studio, das jede Fähigkeit im Browser ausführt), eine neu geschriebene README, vierzehn Werkzeuge auf dem Model-Context-Protocol-Server (MCP), ein Browser-Build, der dieselben Zahlen liefert wie der native, und eine öffentliche Seite für Kshana Pro.

Woher das Wachstum kommt:

Die LEO-Fähigkeit ist systemunabhängig: Sie läuft mit generischen, angegebenen Parametern und braucht kein benanntes System. Benannte Systeme sind optionale Voreinstellungen, jede in einer eigenen Datei mit ihrer öffentlichen Quelle. Eine Voreinstellung, Celeste IOD (In-Orbit-Demonstration), verwendet Zahlen, die auf dem ESA-NAVISP-LEO-PNT-Workshop 2026 vorgestellt wurden (ESA ist die Europäische Weltraumorganisation; NAVISP ist ihr Navigation Innovation and Support Programme); sie liegt in einer Datei, src/celeste_iod.rs, mit ihren fünf Szenarien, die nur im Repository liegen, sodass sie ohne Quelländerung zurückgehalten werden kann, und keine ihrer Workshop-Zahlen wird in diesem Changelog wiederholt.

Lesen Sie „Revisions to published numbers“ vor dem Upgrade. Eine Engine-Ausgabe ändert sich (die Spalten im inertialen Bezugssystem der Art ephemeris, nach einer Vorzeichenkorrektur in der Nutationsmatrix), und das Audit der Dokumentation hat Zahlen korrigiert, die frühere Dokumente gedruckt hatten.

In diesem Eintrag verwendete Abkürzungen

Status: VALIDATED bedeutet, gegen eine unabhängige externe Referenz geprüft (eine veröffentlichte Tabelle, die Software einer anderen Gruppe oder Messdaten); MODELLED bedeutet, ein angegebenes Modell, nur auf interne Konsistenz geprüft; PARTNER bedeutet, die Prüfung benötigt Hardware oder Daten eines Partners.

Abkürzung	Bedeutung
3GPP, 5G, NTN	3rd Generation Partnership Project; Mobilfunknetz der fünften Generation; nichtterrestrisches Netz
AD, BC	Zeitrechnungen (anno Domini, vor Christus)
AIAA	American Institute of Aeronautics and Astronautics
AltBOC, BOC, BPSK, MBOC	Alternative Binary Offset Carrier; Binary Offset Carrier; binäre Phasenumtastung; Multiplexed Binary Offset Carrier (Signalmodulationen)
ATOMIC	Autonomous Time and Orbit Determination for Microsatellite Constellations (ein veröffentlichtes LEO-Ephemeridenmodell)
C/A, L1, L2, L2C, L5	Coarse/Acquisition-Code sowie die Träger- und Zivilsignalnamen des Global Positioning System
C/N0	Träger-zu-Rauschleistungsdichte-Verhältnis
CIO	Celestial Intermediate Origin
CLI	Kommandozeilenschnittstelle
CRC-24Q	zyklische 24-Bit-Redundanzprüfung (Qualcomm-Polynom)
CSAC	chipskalige Atomuhr
CSS, HTML, SVG, XML	Cascading Style Sheets; HyperText Markup Language; Scalable Vector Graphics; Extensible Markup Language
CSV, JSON, PDF, TOML, URL	durch Kommas getrennte Werte; JavaScript Object Notation; Portable Document Format; Tom's Obvious Minimal Language; Uniform Resource Locator
CW	Dauerstrich (continuous wave)
CZML, KML, GeoJSON	Cesium Language; Keyhole Markup Language; Geographic JSON (Karten- und Globusformate)
DE441	Development Ephemeris 441 des Jet Propulsion Laboratory
DOI	Digital Object Identifier
DOP, GDOP, PDOP, HDOP, VDOP	Dilution of Precision: geometrisch, Position, horizontal, vertikal
E1, E5, E5a, E5b	Signalnamen von Galileo
E3F	ein Slot-Name in der Konstellationstabelle des Global Positioning System
ECEF	erdzentriert, erdfest
EE	Gleichung der Äquinoktien
EGM2008	Earth Gravitational Model 2008
EIRP	äquivalente isotrope Strahlungsleistung
ERFA, SOFA	Essential Routines for Fundamental Astronomy; Standards of Fundamental Astronomy (astronomische Referenzbibliotheken)
ESA, NAVISP	Europäische Weltraumorganisation; ihr Navigation Innovation and Support Programme
FDMA	Frequenzmultiplex-Vielfachzugriff
GCRF, GCRS	Geocentric Celestial Reference Frame; Geocentric Celestial Reference System
GLONASS	das Globale Satellitennavigationssystem Russlands
GNSS, GPS	globales Satellitennavigationssystem; Global Positioning System
IAU	Internationale Astronomische Union
ICD, OS SIS ICD, OS SDD	Interface Control Document; Galileo Open Service Signal-In-Space Interface Control Document; Galileo Open Service Service Definition Document
ICRF	International Celestial Reference Frame
IMO	Internationale Seeschifffahrts-Organisation
INS, MEMS	Trägheitsnavigationssystem; mikroelektromechanisches System
IOD	In-Orbit-Demonstration
IQ	Gleichphasen- und Quadraturkomponente
IS-GPS-200	die Schnittstellenspezifikation des Global Positioning System
ISS	Internationale Raumstation
ITRF, ITRS, PEF, TEME	International Terrestrial Reference Frame; International Terrestrial Reference System; Pseudo-Earth-Fixed; True Equator, Mean Equinox (Bezugssysteme)
ITU, ITU-R	Internationale Fernmeldeunion; ihr Radiocommunication Sector
J/S	Störer-zu-Signal-Verhältnis (jammer-to-signal)
J2 bis J6, J2000	zonale Harmonische des Schwerefelds; die Epoche 2000-01-01 12:00
JPL	Jet Propulsion Laboratory
LEO, MEO	niedrige Erdumlaufbahn; mittlere Erdumlaufbahn
MBSE	modellbasiertes Systems Engineering
NEES	normiertes quadratisches Schätzfehlermaß (normalised estimation error squared)
NeQuick-G	das Ionosphärenmodell von Galileo
OEM, SP3, TLE	Orbit Ephemeris Message; Standard Product 3 (präzise Bahnen); Two-Line-Element-Satz
PNT, PPP	Positionierung, Navigation und Zeitgebung; Precise Point Positioning
PSD, SSC	spektrale Leistungsdichte; spektraler Trennungskoeffizient
RAIM, SQM	Receiver Autonomous Integrity Monitoring; Signalqualitätsüberwachung
RINEX, RTCM	Receiver Independent Exchange Format; Radio Technical Commission for Maritime Services
RMS	quadratischer Mittelwert (root mean square)
RTKLIB	eine quelloffene GNSS-Positionierungsbibliothek, hier als unabhängige Referenz verwendet
SGP4	Simplified General Perturbations 4 (das Bahnmodell der Two-Line-Element-Sätze)
SHA-256	Secure Hash Algorithm, 256 Bit
SigMF	Signal Metadata Format
SISRE	Entfernungsfehler im Signal im Raum (signal-in-space range error)
SPS PS	Standard Positioning Service Performance Standard
SRTM	Shuttle Radar Topography Mission
STK	Systems Tool Kit (sein Ephemeridendateiformat .e)
STL	Satellite Time and Location
SVID	Kennung des Raumfahrzeugs (space vehicle identifier)
T/P/F	die Gesamtzahl der Satelliten, Bahnebenen und die Phasierung einer Walker-Konstellation
TEC	Gesamtelektronengehalt
UHF	Ultrahochfrequenz
UTC	Koordinierte Weltzeit
WGS 84	World Geodetic System 1984
X1, X5	Signalnamen des Systems Xona Pulsar

Korrekturen an veröffentlichten Zahlen#

Eine geänderte veröffentlichte Zahl ist eine Revision und wird festgehalten, nie stillschweigend korrigiert. Dieses Release enthält eine Revision der Engine-Ausgabe und mehrere von Zahlen, die in der Dokumentation gedruckt waren.

Engine-Ausgabe

• Die Reduktion TEME→GCRS drehte um 2·Δψ: Die Nutationsmatrix hatte das Vorzeichen von Δψ vertauscht. nutation::numat baute Rx(−(ε̄+Δε))·Rz(Δψ)·Rx(ε̄), wo iauNumat von SOFA Rx(−(ε̄+Δε))·Rz(−Δψ)·Rx(ε̄) baut, sodass nutation_matrix, nutation_matrix_2000a, teme_to_gcrs und gcrs_to_teme um das Doppelte der Nutation in Länge drehten, etwa 25 Bogensekunden. Jede Prüfung der Kette war ein Eigenschaftstest (echte Rotation, Hin-und-zurück, ein von null verschiedener Nutationsbeitrag), den ein Vorzeichenfehler besteht; der Ende-zu-Ende-Test nach Vallado deckte TEME→PEF, TEME→ITRF und GCRS→ITRS ab, aber nicht TEME→GCRS. Im Vallado-Beispiel (AIAA 2006-6753, 2004-04-06) verfehlte die Kette das veröffentlichte GCRF um 1.145 m; nun liegt sie 0,11 m davon entfernt, und die Matrix gleicht numat von ERFA auf 1e-14. tests/frame_reference_vectors.rs::teme_to_gcrs_matches_vallado_gcrf und nutation::tests::nutation_matrix_matches_erfa_numat schlagen beide mit dem alten Vorzeichen fehl. Der Konsistenztest des CIO (Celestial Intermediate Origin) in src/cio.rs hatte die daraus folgende Abweichung von ~130 m auf „≈ 2·EE“ zurückgeführt; das Residuum beträgt nun 5 cm, und seine Schranke ist von 250 m auf 1 m verschärft. Dies verändert veröffentlichte Zahlen und wird hier als Revision festgehalten: die Spalten gcrs_r_m und gcrs_v_m_s der Art ephemeris (etwa 0,8–1,0 km für das mitgelieferte Szenario der ISS (Internationale Raumstation); ihre Spalten für TEME, erdfest, Bodenspur, Blickwinkel und Doppler ändern sich nicht) sowie Propagator::position_in_frame / state_gcrs für die Bezugssysteme GCRS und ITRS. Keine Zusammenfassungszeile, kein Diagramm und kein Golden-Hash eines mitgelieferten Szenarios liest diese Spalten. Die neuen Interoperabilitäts-Exporte verwenden die korrigierte Kette: Die CZML-Position des ersten Satelliten von orbit-sgp4-gps stimmt mit einer ERFA-Reduktion desselben TLE (propagiert vom Python-Paket sgp4) auf 2,3 cm überein.
• Die Art leo-navmsg, nativ und im Browser-Build. Die Art berechnet nun jede transzendente Funktion über eine portable Mathematikbibliothek, sodass ihr Frame auf jeder Plattform und in jedem Build dieselben Bytes hat (unter Fixed). Jede Zahl von leo-navmsg ändert sich damit, ebenso die Stufe navmsg von leo-pnt-chain. Die Art ist neu in diesem Release, sodass sich nichts aus einem früheren Release ändert, wohl aber Zahlen, die vor der Korrektur gedruckt wurden: Der Prüfwert von docs/LEO-NAVMSG.md für das Encode-und-Decode-Szenario war 0x110315 und ist 0x19105F, und der SISRE der dekodierten Nachricht beträgt 0,129 cm. Auf kshana.dev zeigte die Missions-Karte für leo-navmsg-fit-interval-trade einen größten Entfernungsfehler von 1,6 mm mit einem Fit von 60 s und 40,3 mm mit einem Fit von 900 s; die Website wird nun aus der Engine dieses Releases gebaut und zeigt 1,8 mm und 46,6 mm.
• Die Jamming-Footprint-Karte auf kshana.dev (Missions). Jede ihrer 875 Zellen ist ein Lauf von maritime-strait-jamming, bei dem sich nur die Position des Empfängers ändert. Die Zellen werden nun aus denselben dreistelligen Dezimalkoordinaten berechnet, die der Link „open this run“ der Zelle Kshana Studio übergibt, sodass eine Zelle genau das zeigt, was ihr Link reproduziert. Das mittlere Störer-zu-Signal-Verhältnis (J/S) von 30 Zellen ändert sich um 0,1 dB, nach oben oder unten; die Tracking-Verfügbarkeit keiner Zelle ändert sich. Die Engine liefert für jede Zelle in 0.28.0 und 0.29.0 identische Ergebnisse.
• Resampling mit festem Seed im WebAssembly-Paket (WASM). Der Browser-Build zog aus demselben Seed andere Bootstrap- und Shuffle-Indizes als der native Build (unter Fixed). Das Intervall von quantum-anomaly-detect für die Fläche unter der Kurve lautete im Browser [0.9901265, 0.9938305] und ist nun das native [0.99035875, 0.993861]. Keine native Zahl ändert sich.

In der Dokumentation gedruckte Zahlen

Die Dokumentation wurde Wort für Wort gegen Läufe der Engine dieses Releases geprüft. Wo eine gedruckte Zahl nicht zum Lauf passte, wurde das Dokument korrigiert, und jede Korrektur ist hier aufgeführt, alt → neu. In jedem der folgenden Fälle hat sich die Engine-Ausgabe nicht geändert; das Dokument hatte sie falsch gelesen, falsch gerundet oder war von ihr überholt worden.

• Dokumentationsaudit der Seiten zu Spektrum, Konstellation, Kampagne, Animation, Bericht und Interoperabilität sowie ein neues docs/SOLAR-SYSTEM.md. Jede Zahl wurde mit dieser Engine neu ausgeführt. Zwei veröffentlichte Zahlen ändern sich: docs/CONSTELLATION-DESIGN.md nannte den Abdeckungstest mit 5 000 Satelliten „etwa 0,13 s in einem Debug-Build“; das ließ sich nicht reproduzieren (1,24 s auf einem ausgelasteten Laptop), sodass die Seite nun den Anteil des Vorfilters angibt, den der Test ausgibt (9,9 % von 19.440.000 Paartests), und die 0,14 s des Release-Binarys für das mitgelieferte leo-pnt-mega-shell. Dieselbe Seite nannte die Kreuzung von E3F „um 0,050 Grad daneben“; kein Test gibt diese Zahl aus, sodass die Seite nun nur den Zielwert von 0,06 Grad nennt, den der Test erzwingt, und die Herleitung 7,30 gegenüber 7,36 Grad dahinter. Keine Engine-Ausgabe ändert sich.
• LEO-PNT-Dokumente: korrigierte veröffentlichte Zahlen (auf der Engine dieses Releases neu ausgeführt). docs/LEO-SIGNAL.md, Bandvergleich: Die ionosphärische Verzögerung erster Ordnung von generic-s beträgt 3,24 m (gedruckt war 3,25 m) und die von generic-c-wide 0,77 m (war 0,78 m). docs/LEO-NAVMSG.md, Kodieren und Dekodieren: Der SISRE der dekodierten Nachricht war mit 0,119 cm gedruckt, wo der Lauf 0,122 cm lieferte; die Seite druckt nun 0,129 cm, die Zahl nach der Korrektur der Plattformunabhängigkeit unter Fixed weiter unten. docs/LEO-PASS.md, LEO-gegen-GNSS-Überflug: 32 dB weniger Freiraumdämpfung am Höhepunkt des Überflugs (war „26 bis 32 dB“). Bei den Signal- und Überflugzahlen hat sich die Engine-Ausgabe nicht geändert; die Dokumente hatten sie falsch gelesen oder falsch gerundet.
• Tutorials, das durchgearbeitete Pipeline-Beispiel und der Befehl /kshana-run, gegen die Engine dieses Releases geprüft. Korrekturen an veröffentlichten Zahlen, alt → neu: Die Arten, die <scenario>.table.csv schreiben, sind sechs, nicht vier (leo-navmsg und telecom-timing fehlten; docs/tutorials/README.md, commands/kshana-run.md); die Kreuzung ½bT² des Kaltatom-Sensors in Tutorial 3 liegt bei 18.443 s, nicht bei 18.440 s; der Hin-und-zurück-Fehler von oem-interop in docs/examples/multi-tool-pipeline.md beträgt gemessene 4.88e-7 km, nicht „~1e-7 km“; das Holdover-Band der CSAC in Tutorial 2 ist das von 2000–3200 s, das der Test festlegt, nicht „~2600–4400 s“; Tutorial 1 zitiert die SP3-Zeilen und den Geometrieblock in der Genauigkeit, in der die Engine sie schreibt. Keine Engine-Ausgabe hat sich geändert.
• Seiten zu Validierung, Quanten, SGP4, Animation, Aussagen und Integrität. docs/VALIDATION.md: Die erzwungene Schranke für die simulierte Allan-Abweichung bei einer Sekunde einer Uhr mit weißem Frequenzrauschen beträgt 20 % (gedruckt war 25 %; die Schranke von 25 % ist die auf der Kurve bei 1, 10 und 100 s); die Zeile zum Geschwindigkeits-Random-Walk nennt nun ihre erzwungene Schranke von 20 % neben den beobachteten etwa 12 %; und die Verfügbarkeit der Chip-Scale-Atomuhr in orbit-gnss-challenged beträgt etwa 0,73 (gedruckt war etwa 0,83). docs/QUANTUM.md: Das schwingungsbegrenzte Rauschen pro Messung im durchgerechneten Kaltatom-Beispiel der Seite beträgt etwa das 46-Fache seiner Schrotrauschgrenze (war „~45ד; neu berechnet 46,49), und der Bereich „1–50 µg/√Hz“ für im Feld eingesetzte Geräte, der einem von der Seite selbst zitierten Gerät widersprach, ist durch die veröffentlichten Zahlen der beiden zitierten Geräte ersetzt. docs/SGP4-VALIDATION.md: Die größte Positionsdifferenz beträgt 4,12 mm (war „≈ 4 mm“), mit Nennung des Satelliten. docs/ANIMATION.md: Das Beispiel mit dem Video-Encoder las die Frames mit 24 Bildern pro Sekunde mit 12; es verwendet nun 24, die Rate, die das Frame-Manifest nennt. docs/CLAIMS-VS-REALITY.md: Das Jamming-Modell hat 10 Tests (waren 8), und die Angabe „2,97 m gegenüber 48,8 m“ des gekoppelten Filters ist durch das ersetzt, was sein Test festlegt (der Positionsfehler des gekoppelten Filters unter dem 0,6-Fachen des entkoppelten, bei mindestens 90 von 100 Versuchen gewinnend). docs/INTEGRITY.md: Der Stempel „Today“ lautete v0.22.0; er nennt nun dieses Release, und zwei seither gebaute Fähigkeiten (der konstellationsweite Fehlermodus und die Integritäts-Unterstützungsnachricht) verlassen seine Lückenliste.

Hinzugefügt#

Spektrum

• Szenarioart spectrum: ein Spektrummodell und Wasserfall für das L-Band (src/spectrum.rs, src/sigmf.rs, docs/SPECTRUM.md). Das gesamte GNSS-L-Band als eine spektrale Leistungsdichte (PSD): GPS L1 Coarse/Acquisition (C/A) und L2 Civil (L2C) (BPSK(1)), Galileo E1 (Multiplexed Binary Offset Carrier, MBOC(6,1,1/11), oder BOC(1.1)), GPS L5 und Galileo E5a (BPSK(10)), ein kT-Rauschteppich mit einer Rauschzahl des Empfängers sowie Dauerstrich-Jammer (CW), Schmalband-, Chirp- und Matched-Noise-Jammer auf einer skriptgesteuerten Zeitachse. Jeder Jammer wird pro Band über seinen spektralen Trennungskoeffizienten (SSC) bewertet, woraus sich das Störer-zu-Signal-Verhältnis (J/S) und die effektive Träger-zu-Rauschleistungsdichte (C/N0) pro Band und Zeile ergeben. Das Diagramm ist ein SVG-Wasserfall mit C/N0-Balken; result.json enthält das Gitter, in der Leistung blockweise gemittelt. Optionales [iq] zeichnet das Modell als IQ-Samples, schreibt und liest eine Aufnahme im Signal Metadata Format (SigMF) (cf32_le, ci16_le) und vergleicht eine Welch-Schätzung mit dem Modell; optionales [recording] schätzt eine echte SigMF-Datei. Mitgeliefertes Beispiel scenarios/l-band-waterfall-jamming.toml: Ein Chirp nimmt L1 C/A und E1 bei 10 s, ein CW-Ton auf dem L1-Träger hält C/A nach dem Ende des Chirps bei 17,98 dB-Hz, während sich E1, dessen Spektrum dort eine Nullstelle hat, erholt; L5 und E5a bleiben unberührt.
  • Neue VALIDATED Zeile: die Signal-PSDs und SSCs, gegen die Hauptkeule von BPSK(n) mit 2n x 1,023 MHz, die um +/-1.023 MHz zentrierten Keulen von BOC(1.1), die geschlossenen Parseval-Formen hinter den veröffentlichten SSCs von -61.8 / -64.8 / -67.8 dB/Hz und das Lehrbuch-Q = 1 (CW) und 1,5 (Matched). Das PSD-Maximum von BOC(1.1) liegt bei +/-0.759 MHz, nicht in der Keulenmitte; der Test legt beides fest.
  • Zwei neue Zeilen (MODELLED): der Wasserfall und die C/N0-Zeitleiste, die sich genau auf die Kette der Art jamming reduzieren (in jedem Bericht gegengeprüft), sowie der SigMF-Codec und der Welch-Schätzer. Im Repository liegt keine Aufnahme von Dritten.
  • navsignal: eine MBOC-Variante und spectral_separation_coeff_offset.
  • Der Bericht gibt das C/N0 aus, das die repräsentative Q-Tabelle der Art jamming ergäbe, neben dem aus dem Spektrum abgeleiteten; bei einem CW-Ton auf dem C/A-Träger unterscheiden sie sich um 1,8 dB. Drei neue Matrixzeilen: eine validiert (Signalspektren und spektrale Trennkoeffizienten) und zwei modelliert.

Sonnensystem

• Sonnensystem-Ephemeride und Positionierung um jeden Körper. Zwei neue Szenarioarten.
  • solar-system: die Sonne, die acht Planeten, Pluto, der Mond, Phobos, Deimos, Io, Europa, Ganymed, Kallisto und Titan zu einer Epoche: heliozentrische Position und Geschwindigkeit im International Celestial Reference Frame (ICRF), Gravitationsparameter, Radien, J2 (die zweite zonale Harmonische), wo veröffentlicht, siderische Rotation, der Pol und der Nullmeridian der Internationalen Astronomischen Union (IAU), eine Bahnspur über einen Umlauf sowie die Lichtlaufzeit, die Ein- und Zweiweg-Entfernung, die solare Shapiro-Verzögerung und der Sonnenabstand von einem Beobachterkörper aus und für jede zusätzliche Verbindung. Die Planeten stammen aus den Keplerschen Elementen des Jet Propulsion Laboratory (JPL) von Standish und Williams (Tabelle 1, 1800 n. Chr. bis 2050 n. Chr.; Tabellen 2a/2b, 3000 v. Chr. bis 3000 n. Chr.); die Monde aus mittleren JPL-Elementen mit der synchronen Rotationsrate der IAU, und Titan aus dem Rotationsmodell der IAU. Beispiel: scenarios/solar-system-tour.toml.
  • body-pnt: ein Orbiter oder eine Oberflächenlandeeinheit um einen dieser Körper, die mit Pseudoentfernungen aus einer Walker-Konstellation um den Körper und einer uhrenfreien Zweiweg-Entfernung von der Erde navigieren; Dilution of Precision, formale Unsicherheit und Least-Squares-Lösungen mit festem Seed mit und ohne die Erdverbindung. Beispiele: scenarios/mars-orbit-pnt.toml, scenarios/europa-surface-pnt.toml.
  • Body erhält Merkur, Venus, Jupiter, Saturn, Uranus, Neptun, Pluto und die sieben Monde, eine Namenssuche und einen physikalischen Datensatz; AnalyticSolarSystem liefert jeden Körper relativ zu jedem anderen über die bestehende Schnittstelle EphemerisProvider.
  • VALIDATED gegenüber JPL Horizons (Development Ephemeris DE441; Fixtures und Abfragen in tests/fixtures/solar_system/): Merkur bis Saturn und die Erde aus Tabelle 1 innerhalb des Doppelten des angegebenen Nennfehlers (schlechtester Wert 1,87-fach), alle acht Planeten aus den Tabellen 2a/2b (schlechtester Wert 1,71-fach) und die Lichtlaufzeit von Erde zu Mars und Jupiter. MODELLED: Uranus und Neptun aus Tabelle 1, die gegenüber DE441 den angegebenen Fehler überschreiten (2,0- und 5,2-fach), Pluto, die Monde, die Körperkonstanten und die Ergebnisse von body-pnt.
  • Befund: Die Mondreihe von Montenbruck & Gill in src/ephem.rs ist durch ihren eigenen Präzessionsterm bereits auf das Äquinoktium J2000 bezogen (0,05 Grad von Horizons), sodass sie ohne weitere Präzessionsrotation verwendet wird. Sechs neue Matrixzeilen: zwei validated (Planetenpositionen, Lichtlaufzeit) und vier modelled.

Konstellationen um jeden Körper

• Konstellationsentwurf im großen Maßstab (Art constellation-design, src/constellation.rs). Walker-Delta- und Walker-Star-Muster (T/P/F), explizite Elementlisten und Mehrschalen-Entwürfe, mehrere Konstellationen pro Lauf, um die Erde, den Mond, den Mars oder einen anderen Planeten, Pluto oder einen großen Mond aus den Körperkonstanten, die die Art solar-system hinzugefügt hat. Voreinstellungen aus veröffentlichten Nennelementen: die GPS-Basiskonstellation (Global Positioning System) und die erweiterbare 24-Slot-Konstellation (Standard Positioning Service Performance Standard, SPS PS, 2020), Galileo Walker 24/3/1 (Open Service Service Definition Document, Ausgabe 1,1), BeiDou in der mittleren Erdumlaufbahn Walker 24/3/1 plus geostationäre und geneigte geosynchrone Satelliten (Open Service Performance Standard 3,0) und GLONASS 24/3/1 (Interface Control Document 5,1). Abdeckung und Dilution of Precision (DOP) über einem Breiten-/Längengitter: sichtbare Satelliten, GDOP, PDOP, HDOP und VDOP (geometrisch, Position, horizontal, vertikal) und Verfügbarkeit pro Zelle, global und am ungünstigsten Standort, mit einer Empfängeruhr pro Konstellation. Ein Sichtbarkeits-Vorfilter (Abdeckungs-Halbwinkel plus ein Breitenband des Subsatellitenpunkts, auf einem kugelförmigen Körper exakt) verarbeitet 5.000 Satelliten auf einem 10-Grad-Gitter in einem Debug-Build in etwa 0,13 s.
  • VALIDATED: Der Walker-Generator reproduziert Tabelle 23 des Galileo OS SDD und die Slot-Formel des GLONASS ICD; die GPS-Voreinstellung reproduziert die Spalte der Äquatorkreuzungen des SPS PS (35 von 36 Orten innerhalb von 0,0108 Grad; E3F innerhalb von 0,06 Grad, wobei die Tabellenzeile selbst inkonsistent ist); die globale HDOP-Verteilung der GPS-Basiskonstellation entspricht dem SPS PS, Anhang B (Median 0,940 gegenüber 0,94, 95 % 1,255 gegenüber 1,25, Mittelwert 0,965 gegenüber 0,96; Zielwert 0,03).
  • MODELLED: beliebige Entwürfe, andere Körper, die Phasen- und geneigten geosynchronen Knoten von BeiDou, Zweikörperbahnen mit optionalem J2, nur Geometrie.
  • Szenarien: constellation-multi-gnss-coverage (102 Satelliten, Verfügbarkeit 100 %, mittlerer PDOP 0,95, 31,0 sichtbar über 10 Grad), leo-pnt-mega-shell (5.000 Satelliten, Verfügbarkeit 99,22 % bei PDOP 3 oder weniger über 20 Grad, 0 % an den Polkappen, der Vorfilter behält 11,5 % der Paartests), lunar-relay-constellation (14 Satelliten um den Mond, Verfügbarkeit 21,33 % insgesamt und am höchsten über der Südpolregion). Alle drei sind für kshana example mitgeliefert. Hinweise: docs/CONSTELLATION-DESIGN.md. Drei neue Matrixzeilen: zwei validated (Walker-Generator und GNSS-Voreinstellungen, globaler GPS-DOP) und eine modelled.
• Eine vom Spektrummodell gesteuerte Kampagne und Konstellationen um jeden Körper. scenarios/campaign-spectrum-holdover-integrity.toml verkettet die Art spectrum mit einem Uhren-Holdover und einem Integritätsmonitor (ein Chirp nimmt L1 C/A und E1; ein CW-Ton hält danach C/A unten, während sich E1 erholt und der Empfänger auf einen reinen Galileo-Himmel zurückfällt), festgehalten gegen das eigenständige Wasserfallbeispiel in tests/campaign_composition_reference.rs. constellation-design löst seinen Zentralkörper nun über Body::by_name auf, sodass eine Konstellation um jeden Planeten, Pluto oder großen Mond gelegt werden kann, mit den Konstanten, die die Art solar-system verwendet.

Kampagnen

• Kampagnen: viele Szenarien zu einem Lauf zusammengesetzt. Eine neue Art campaign (src/campaign.rs, dokumentiert in docs/CAMPAIGNS.md) führt Mitglieder bestehender Arten über dieselbe Verteilung wie die Kommandozeile aus und liest Zahlen aus ihren Ergebnissen zurück. Vier Abschnitte, in beliebiger Kombination:
  • [[phases]]: eine verkettete Mission auf einer Zeitachse. Voreinstellungen pro Art lesen den Uhrzeitfehler gegen seine Schutzgrenze, das mittlere effektive Träger-zu-Rauschleistungsdichte-Verhältnis (C/N0) gegen die Tracking-Untergrenze, das vertikale Schutzniveau gegen die Alarmgrenze, den Positionsfehler, die trackenden Satelliten und die Alarmflags, festgehalten auf einem gemeinsamen Gitter mit Phasengrenzen und Ereignissen. Der Zustand wird durch carry, handoff und end_at weitergereicht.
  • [sweep]: ein bis drei Punktschlüssel einer beliebigen Art, optional mit einem Ensemble mit festem Seed an jedem Knoten.
  • [monte_carlo]: Realisierung k mit Basis-Seed + k, mit Mittelwert, Streuung, Perzentilen und einem Bootstrap-Konfidenzintervall von 95% mit festem Seed.
  • [compose]: gemeinsame Werte, die an mehrere Mitglieder gebunden sind, mit einer kombinierten Zusammenfassung von bestem und schlechtestem Fall. Jedes Ergebnis trägt einen Kampagnen-Hash und einen Digest über jedes Mitgliedsergebnis. Vier mitgelieferte Szenarien: campaign-jam-spoof-holdover-integrity (nominal, Jamming, Spoofing, das bei der Detektion des Uhrenmonitors nach 370 s endet, Holdover, der den gespooften Offset von 37,0 ns trägt, mit auslaufender Inertialeinheit, ein Integritätsalarm, Erholung), campaign-sweep-jammer-power, campaign-shared-jammer-sea-road und campaign-monte-carlo-clock-holdover. tests/campaign_composition_reference.rs hält die Kompositionsidentitäten fest: Eine Kampagne mit einer Phase reproduziert den eigenständigen Lauf bei drei Arten bitgenau, ein Ensemble mit festem Seed ist byte-stabil, und bei einer Uhr mit weißem Frequenzrauschen liegt der Ensemble-Mittelwert innerhalb des gemeldeten Intervalls, mit der Streuung innerhalb des Chi-Quadrat-Intervalls von sqrt(q_wf * tau) = 16,459 ns. Drei neue modelled-Matrixzeilen.

Animation

• Animationsexport (--animate svg|html|frames|all, src/animation.rs, docs/ANIMATION.md). Jeder Lauf, dessen Ergebnis eine Zeitreihe enthält, kann nun als animierte SVG-Datei (Scalable Vector Graphics) geschrieben werden (CSS-Keyframes (Cascading Style Sheets), kein Skript: Die Kurven zeichnen sich hinter einem wandernden Zeitcursor ein), als einzelner, in sich geschlossener HTML-Player (HyperText Markup Language) (Wiedergabe und Pause, Scrubbing, Geschwindigkeit, jedes Panel an einem synchronisierten Cursor, Ereignismarken, die beim Klick springen; keine externe Ressource) oder als nummerierte SVG-Frame-Folge mit einer manifest.json, die Bilder pro Sekunde, Dauer und Frame-Zeiten für einen Video-Encoder nennt. Eine Kampagne wird als ihre Phasen abgespielt, mit markierten Alarmen; ein Spektrumlauf animiert seinen Wasserfall Zeile für Zeile. Der Player folgt prefers-color-scheme, und unter prefers-reduced-motion zeigen sowohl die SVG als auch der Player das fertige Bild, statt sich zu bewegen. --animate-fps und --animate-duration legen die Wiedergabe fest; kshana::api::animate_toml und kshana::animation::animate_result sind die Einstiegspunkte der Bibliothek, und result.json erhält nur dann einen Block animation, wenn --animate läuft. Die Ausgabe ist eine reine Funktion von Ergebnis und Optionen, bei einem erneuten Lauf byte-identisch, ohne Zeitstempel. Eine Art ohne abgetastete Zeitachse wird mit „no time series to animate“ abgelehnt, und es wird nichts geschrieben. Der Exporter zeichnet die eigenen Samples des Laufs und fügt keine Zahl hinzu, ist also MODELLED (interne Konsistenz) und trägt keine Zeile der Verifikationsmatrix; keine veröffentlichte Zahl ändert sich. Tests: tests/animation.rs (Determinismus, Frame-Anzahl, keine externe Adresse, wohlgeformtes XML, der Pfad für reduzierte Bewegung und jedes mitgelieferte Szenario mit Zeitreihe, das animiert).

Berichte

• Erweiterte Laufberichte (src/advanced_report.rs, docs/REPORTS.md). Jeder Lauf der Kommandozeilenschnittstelle (CLI) schreibt nun <scenario>.report.html, einen druckbaren HTML-Bericht (HyperText Markup Language), und <scenario>.report.json, denselben Inhalt als maschinenlesbares JSON-Dokument (JavaScript Object Notation). Abschnitte: eine Kurzfassung; jede Szenarioeingabe mit ihrer Einheit, gelesen aus dem Schema der Feldeinheiten (der Block units des Ergebnisses), sonst aus dem Suffix des Feldnamens, sonst als nicht angegeben ausgewiesen; die Ergebnisse mit dem Diagramm des Laufs, jedem Skalar und einer Zusammenfassung jeder numerischen Spalte; bei einer Kampagne die Knotentabelle des Sweeps, der Monte-Carlo-Mittelwert, die Standardabweichung, das 5.-/50.-/95.-Perzentil und das Bootstrap-Konfidenzintervall mit einem Histogramm pro Metrik, die Phasentabelle der Kette oder die Mitglieder der Komposition und ihre kombinierte Zusammenfassung (und das Gitter eines Laufs von sweep oder sweep-nd); eine Ereigniszeitleiste; die Kennzeichnung VALIDATED / MODELLED / PARTNER, die unabhängige Referenz und der Testnachweis jeder Zeile der Verifikationsmatrix, die die Arten des Laufs berühren, gelesen aus der Matrix über eine Zuordnung von Art zu Zeile (eine Zeile, die einen Eingabepfad bewertet, etwa den Pfad Simplified General Perturbations 4 (SGP4) von orbit oder den Pfad des gemessenen Datensatzes von slot-timing, wird nur aufgeführt, wenn der Lauf diesen Pfad genommen hat, und die Zeile des Shuttle-Radar-Topography-Mission-Lesers (SRTM) wird für keine Art aufgeführt, da kein Szenariofeld eine SRTM-Kachel liest); die Aussagen zu Nicht-Modelliertem und die Annahmen, jeweils mit ihrer Quelle zitiert; und ein Reproduzierbarkeitsprotokoll (Engine-Version, der Quell-Commit, wenn der Build KSHANA_GIT_COMMIT setzt, Digests im Secure Hash Algorithm 256-bit (SHA-256) der Szenariodatei und des Ergebnisdokuments, Seed, Plattform und der genaue Befehl). Der Bericht liest keine Uhr: Gleiches Szenario, gleicher Seed und gleicher Engine-Build ergeben einen byte-identischen Bericht, und der einzige Zeitstempel, den er zeigen kann, ist der, den --study-name bereits schreibt. Ein Druck-Stylesheet passt auf A4 und US Letter, wiederholt Tabellenköpfe und hält Zeilen und Abbildungen über Seiten hinweg zusammen; eine Datei im Portable Document Format (PDF) entsteht mit „Als PDF speichern“ des Browsers. Eine Option --report pdf gibt es nicht, weil das Rendern der Diagramme in ein PDF eine neue, schwere Abhängigkeit erfordern würde. Tests: tests/advanced_report.rs berichtet jedes mitgelieferte Szenario (kein leerer Abschnitt, kein Platzhaltertext, Kennzeichnungen gleich der Matrix, der Szenario-Digest gleich dem der Datei, byte-identisch bei erneutem Lauf), und tests/advanced_report_cli.rs führt den aufgezeichneten Befehl in einem frischen Verzeichnis erneut aus und verlangt ein byte-identisches result.json. Keine veröffentlichte Zahl ändert sich, und die Anzahlen der Arten, Szenariodateien und Matrixzeilen bleiben unverändert.
• Bericht, Animation und Exporte arbeiten zusammen. Der erweiterte Bericht erhält einen Abschnitt „Animation and exports“: die animierte Zeichnung des Laufs als inaktives Bild eingebettet (oder der Grund, warum es keine gibt), Links zu den daneben geschriebenen Animations- und Exportdateien und jedes Interoperabilitätsformat mit der Angabe, ob es zutrifft, warum nicht und wie seine Spezifikation lautet; report.json trägt denselben Block companions. Der HTML-Animationsplayer listet die daneben geschriebenen Exportdateien auf. Die Kommandozeilenschnittstelle (CLI) rendert die Exporte nun vor dem Schreiben des Berichts, sodass beide die Dateien nennen können.

Interoperabilitäts-Exporte

• Interoperabilitäts-Exporte und -Importe (--export, src/interop/, docs/INTEROP.md). kshana <scenario.toml> --export <format> schreibt die Geometrie des Szenarios als CZML (die Cesium Language), KML (Keyhole Markup Language 2,2, ein Standard des Open Geospatial Consortium, mit zeitmarkierten Spuren gx:Track), GeoJSON (Request for Comments 7946 der Internet Engineering Task Force) und als Ephemeriden .e von Ansys STK (Systems Tool Kit) (EphemerisTimePosVel, Meter, eine Datei pro bewegtem Objekt) sowie den synthetisierten IQ-Schnappschuss (Gleichphasen- und Quadraturkomponente) der Art spectrum als SigMF-Paar (Signal Metadata Format) über das bestehende src/sigmf.rs. --export all schreibt jedes zutreffende Format und gibt aus, warum die anderen nicht zutreffen; --export list berichtet, ohne zu laufen. Bewegte Objekte werden im Geocentric Celestial Reference System (CZML INERTIAL, STK ICRF) und als erdfeste Länge, Breite und Höhe in WGS 84 (World Geodetic System 1984) geschrieben (KML, GeoJSON); feste Standorte in CZML sind FIXED. Die Art jamming fügt zwei Jammer-Footprints aus ihren eigenen Streckengleichungen hinzu. --import-route <file.geojson> schreibt ein GeoJSON LineString in die Spureingaben von terrain-nav, terrain-slam, gravity-map und combined-altpnt. Exporte sind byte-deterministisch und tragen keinen Zeitstempel. tests/interop_formats.rs validiert jeden Export gegen seine veröffentlichte Spezifikation, vergleicht exportierte Satellitenzustände auf 1 mm mit denen der Engine selbst und führt jedes mitgelieferte Szenario durch jedes Format, wobei jedes entweder exportiert oder angibt, warum nicht (die Tabelle in docs/INTEROP.md). Keine veröffentlichte Zahl ändert sich: Die IQ-Synthese der Art spectrum wurde in eine gemeinsame Funktion verschoben, und ihr Ergebnisdokument ist byte-identisch, und PassesScenario erhält propagator() und epoch_calendar(), die sein eigener Lauf verwendet. Die Anzahlen der Arten, Szenariodateien und Zeilen der Verifikationsmatrix bleiben unverändert. Ein Bahn- oder Integritätsszenario ohne epoch wird nach den eigenen Daten seiner Satelliten datiert: t = 0 ist die früheste Epoche eines TLE (Two-Line-Element-Satz), einer Broadcast-Ephemeride oder von SP3 (Standard Product 3), und jeder solche Satellit wird zu seinem eigenen Zeitpunkt in das GCRS und in erdfeste Bezugssysteme gedreht; 2000-01-01T00:00:00Z wird nur verwendet, wenn kein Satellit eine Epoche trägt. Die Exporte SP3 und OEM (Orbit Ephemeris Message) behalten ihre Bezeichnung 2000-01-01. Um dies zu unterstützen, wurden Sgp4::epoch_jd_utc, Sp3Interpolator::jd_ut1 und Propagator::own_jd_utc hinzugefügt; nichts, was es bereits gab, liest sie.

Navigation in der niedrigen Erdumlaufbahn: Signal

• LEO-PNT-Signalentwürfe und ein Mehrband-Spektrum. Eine neue Art leo-signal und eine Art spectrum, die über das L-Band hinausreicht: eine Art, vier Szenariodateien (drei mitgeliefert; die Datei Celeste IOD liegt nur im Repository) und vier Matrixzeilen (zwei VALIDATED, zwei MODELLED).
  • leo-signal: parametrierte Signalentwürfe für Positionierung, Navigation und Zeitgebung (PNT) in der niedrigen Erdumlaufbahn (LEO) für jedes System (Band, Sendebandbreite, ITU-Zuweisung; Akquisitions-, Daten- und Pilotkomponenten mit BPSK(n), BOC(m,n), MBOC oder flachen Spektren, Leistungsanteile, FDMA-Unterträger, Codelängen und Datenraten), aus einkompilierten öffentlichen Voreinstellungsdateien unter data/leo-signals/ (Xona Pulsar X1/X5, Iridium STL, ein Gelegenheitssignal von Starlink, CentiSpace, ein repräsentativer C-Band-Entwurf und repräsentative Entwürfe für UHF/L/S/C/Breit-C, jeweils mit Angabe ihrer Quell-URL) oder inline geschrieben. Pro Signal: die bandbegrenzte PSD und die Leistungsanteile im Band, die Gabor-Bandbreite, der bandbegrenzte Early-Late-Code-Tracking-Jitter gegen C/N0 und Abstand (Betz & Kolodziejski 2009) und die Entfernungsmessgenauigkeit, der Akquisitionssuchraum, die Detektionswahrscheinlichkeit und die mittlere serielle und codeparallele Akquisitionszeit, der SSC in und aus GPS L1 C/A, Galileo E1, GPS L5, Galileo E5a, E5b und AltBOC mit dem C/N0-Verlust, die Toleranz gegenüber CW-, Breitband- und Matched-J/S aus dem SSC-Code der Spektrum-Art, ein Bandvergleich (ionosphärische Verzögerung, Freiraumdämpfung, Entfernungsmessung bei gleichem C/N0 und gleicher EIRP, Jammer-Toleranz) und optionale Formprüfungen gegen eine beschriebene Messung. Beispiele: scenarios/leo-band-trade.toml, scenarios/xona-pulsar-signals.toml, scenarios/celeste-iod-classical-pilot-signals.toml (die Bänder und die Signalkonfiguration von Celeste IOD, vorgestellt auf dem ESA-NAVISP-LEO-PNT-Workshop 2026; zurückgehalten mit der Voreinstellung Celeste IOD, siehe „LEO-PNT end to end“ weiter unten). Hinweise in docs/LEO-SIGNAL.md.
  • spectrum: Bänder können nun eine voreingestellte Signalentwurf sein (jede Komponente gezeichnet, bandbegrenzt, C/N0 und J/S bezogen auf die getrackte Komponente) oder ein benutzerdefinierter Träger mit Modulation; [[panels]] fügen Wasserfälle über andere Frequenzbereiche auf einer Zeitachse hinzu; ein Jammer wideband (Barrage) gesellt sich zu den vier Wellenformen. Der Bericht fügt bands[].tracked_power_dbw, bands[].design und panels sowie einen Eintrag not_modelled hinzu. Einfache Bänder liefern dieselben Zahlen wie zuvor. Beispiel: scenarios/multi-band-jamming-waterfall.toml.
  • navsignal erhält das Sinusintegral, die geschlossenen Formen für BPSK-Leistung im Band und bandbegrenzte Gabor-Bandbreite, den bandbegrenzten Early-Late-Jitter für jedes Spektrum und seine Gabor-Schranke, die geschlossene Form des Offset-BPSK-SSC, das Galileo-E5-AltBOC(15.10)-Spektrum und einen Parser für Modulationsbezeichnungen; Modulation::label gibt BPSK(1/3) als Bruch aus.
  • Vier Matrixzeilen: VALIDATED bandbegrenzte geschlossene Formen (90,3 % der BPSK-Leistung im Hauptkeulenbereich, der Jitter, der sich auf die kohärente Form von Kaplan & Hegarty reduziert, 0,0039564 Chips bei 45 dB-Hz, B_L 1 Hz, d 1 Chip, T 20 ms, und auf seine Gabor-Schranke, und das BPSK-Eigen-SSC 2/(3 R_c); die geschlossene Gabor-Form und das Offset-SSC gegenüber seiner Parseval-Form sind als interne Gegenprüfungen angegeben); VALIDATED maximaler LEO-Doppler (Xona X1 33,2 kHz innerhalb der veröffentlichten 32 bis 34 kHz, Iridium innerhalb von 0,5 kHz von 36 kHz); MODELLED leo-signal; MODELLED Multiband-Spektrum.

Navigation im niedrigen Erdorbit: Link

• LEO-PNT-Überflug und Link-Budget je Band: die Art leo-pass. LEO-PNT bezeichnet Positionierung, Navigation und Zeitgebung (PNT) durch Satelliten im niedrigen Erdorbit (LEO). Ein Nutzer (am Boden, auf See, in der Luft oder in Gebäuden, statisch oder bewegt) und ein oder mehrere LEO-Satelliten aus einem entworfenen Überflug, expliziten Elementen, einem Two-Line-Element-Satz (TLE) über SGP4 oder einer Walker-Konstellation aus dem Code von constellation-design. Je Satellit, Band und Epoche: Blickwinkel, Entfernung, Entfernungsrate und Entfernungsbeschleunigung in geschlossener Form (bei jedem Lauf gegen zentrale Differenzen geprüft), Doppler und Dopplerrate, Freiraumdämpfung, EIRP (äquivalente isotrope Strahlungsleistung) mit isoflux-, Gauß-Strahl- oder flachem Satellitenmuster, einer Patch-Nutzerantenne, gasförmiger Dämpfung nach ITU-R P.676, Regendämpfung nach ITU-R P.838/P.618, troposphärischer Szintillation nach P.618, Gebäudeeindringdämpfung nach ITU-R P.2109 für einen Nutzer in Gebäuden, Polarisationsfehlanpassung, Systemrauschtemperatur und C/N0 (Träger-Rauschleistungsdichte); die ionosphärische Laufzeit erster Ordnung je Band aus einem Klobuchar- oder einem schrägen vertikal-TEC-Wert (Gesamtelektroneninhalt) unterhalb des Satelliten sowie ionosphärenfreie Bandpaare mit ihrer Rauschverstärkung. Galileo- oder GPS-Satelliten werden mit demselben Empfänger aus den Empfangsleistungen ihrer Schnittstellendokumente ausgewertet, sodass der glockenförmige LEO-Überflug und die flachen MEO-Träger (mittlerer Erdorbit) in einem Diagramm stehen. Ein Abschnitt [iot] gibt Zeit bis zum ersten Fix, Energie je Fix und Batterielebensdauer gegenüber dem Tastverhältnis an (MODELLED).
  • Systemunabhängig: die Engine braucht keine Voreinstellung. Optionale Voreinstellungen, jede in einer eigenen Datei und gekennzeichnet als PUBLIC (mit URL), REPRESENTATIVE oder WORKSHOP: generisches Multiband (UHF, L, S, C), generisches C-Band, Xona Pulsar X1/X5 (arXiv 2509,19551), Iridium STL, Starlink als reines Doppler-Gelegenheitssignal, CentiSpace und Celeste IOD (Demonstration im Orbit), dessen Signalparameter auf dem ESA-NAVISP-LEO-PNT-Workshop 2026 vorgestellt wurden und in src/celeste_iod.rs liegen, sodass sie zurückgehalten werden können (siehe "LEO-PNT end to end" unten).
  • Öffentliche Bausteine in src/leo_link/ (Geometrie, Antenne, ITU, Ionosphäre, Energie, Voreinstellungen), die andere Module aufrufen können.
  • Szenarien: leo-pass-vs-gnss-cn0, leo-indoor-uhf, leo-iot-energy, leo-pass-xona-pulsar, leo-pass-iridium, leo-pass-celeste-iod-multiband.
  • Neun Matrixzeilen. VALIDATED (6): Koeffizienten nach ITU-R P.838-3 gegenüber ihrer Tabelle 5; Regendämpfung und Szintillation nach P.618-14 gegenüber den Validierungsbeispielen der ITU-R Study Group 3; Gebäudeeindringdämpfung nach P.2109 gegenüber der Arbeitsmappe der Study Group 3; ionosphärische Skalierung erster Ordnung gegenüber dem Gruppenlaufzeitverhältnis aus IS-GPS-200, mit der Freiraumdämpfung; der maximale Doppler eines statischen Nutzers auf einer Kreisbahn gegenüber arXiv 2509,19551 Tabelle 1. MODELLED (3): der Überflug und das Link-Budget, die Voreinstellungen und das Budget für Fixes mit niedrigem Energiebedarf. Eine Art und sechs Szenariodateien. Hinweise in docs/LEO-PASS.md.

Navigation im niedrigen Erdorbit: Navigationsnachricht

• LEO-Navigationsnachricht (Art leo-navmsg, src/leo_navmsg/). Die Broadcast-Ephemeriden- und Uhrennachricht eines Satelliten für Positionierung, Navigation und Zeitgebung (PNT) im niedrigen Erdorbit (LEO), für jede Bahn, jeden Träger und jedes Modell; benannte Voreinstellungen sind optionale Daten, und jede Fähigkeit läuft ohne sie. Eine Art, fünf Szenariodateien und neun Matrixzeilen (drei VALIDATED, sechs MODELLED). Siehe docs/LEO-NAVMSG.md.
  • Nachrichteninhalt: SVID, Datenausgabe, Band und Signalzustand; Woche, Wochenzeit und ein Uhrenpolynom zweiter Ordnung; die Ephemeride in einem von vier Modellen — dem Kepler-Satz mit 16 Parametern aus dem Galileo OS SIS ICD, diesem Satz plus Korrekturpolynomen für Along-Track, Cross-Track und radial, dem Modell mit 22 Parametern von Liu et al. 2025 (doi 10.3390/rs17162894) oder dem ATOMIC-Zero-Clock-ECEF-Polynom — sowie ein Klobuchar-Satz, NeQuick-G-Koeffizienten mit dem effektiven Ionisationsniveau und Parameter von Systemzeit zu UTC mit den Schaltsekundenfällen des ICD.
  • Fitter: eine Wahrheitsbahn, integriert mit zonaler J2–J6- oder EGM2008-Gravitation und Luftwiderstand, eine mit Startwert versehene freie oder gesteuerte Uhr, ein Levenberg–Marquardt-Fit auf nichtsingulären Elementen, dann lineare Korrekturpolynome nach kleinsten Quadraten und eine Uhr, die abzüglich des relativistischen Terms des Nutzers angepasst wird.
  • Vier Analysen und Szenarien: leo-navmsg-fit-interval-trade (Signal-in-Space-Entfernungsfehler (SISRE) gegenüber Fit-Intervall und Aktualisierungsperiode), leo-navmsg-model-comparison (vier Modelle, Bits und der Fit mit 22 Parametern von Kshana auf den Höhen von Liu et al. neben den veröffentlichten Zahlen, MODELLED), leo-navmsg-midpass-update (Kontinuität bei jedem Nachrichtenwechsel während eines Überflugs) und leo-navmsg-encode-decode (der eigene dokumentierte Binärframe von Kshana mit CRC-24Q und einem Quantisierungsbudget, ein Block im Stil von RINEX 4, der als Kshana-Erweiterung gekennzeichnet ist, und eine CSV-Tabelle).
  • VALIDATED: die global gemittelten SISRE-Gewichte gegenüber der veröffentlichten Tabelle für mittlere und geostationäre Bahnen von Montenbruck et al. 2018; der Galileo-Nutzeralgorithmus gegenüber RTKLIB auf vier realen Galileo-Broadcast-Ephemeriden (tests/leo_navmsg_reference.rs); CRC-24Q gegenüber dem Katalogprüfwert und dem Beispielframe RTCM 10403 1005.
  • Voreinstellungen, je eine Datei mit Quellen: Xona Pulsar und Pulsar-0, Iridium, Starlink, CentiSpace, ein repräsentatives C-Band-System, ATOMIC und Celeste IOD (die einzige Voreinstellung mit Material, das auf dem ESA-NAVISP-LEO-PNT-Workshop 2026 vorgestellt wurde, gehalten in src/celeste_iod.rs mit ihren Szenarien, sodass sie zurückgehalten werden kann).

Navigation im niedrigen Erdorbit: Fusion

• Fusionierte MEO- + LEO-Positionierung, -Navigation und -Zeitgebung: leo-pvt, leo-ppp und ntn-positioning. Drei neue Szenarioarten in src/leo_fusion/, systemunabhängig: jede Konstellation besteht aus Walker-Schalen, Elementsätzen oder einer GNSS-Voreinstellung, jedes Signal aus einem Träger, einer Chiprate und einer Hüllkurve der Träger-Rauschleistungsdichte (C/N0), jedes Fehlerbudget aus einem ausdrücklichen Ein-Sigma, und benannte Systeme im niedrigen Erdorbit (LEO) sind optionale Voreinstellungen, je eine Datei mit ihren als öffentlich, Workshop oder abgeleitet gekennzeichneten Quellen (Xona Pulsar X1/X5, Iridium Satellite Time and Location (STL), Starlink-Gelegenheitssignale, CentiSpace, ein repräsentatives C-Band-System, das ATOMIC-Zero-Clock-Ephemeridenmodell und eine Voreinstellung für die ESA-Demonstration im Orbit Celeste, deren aus dem Workshop abgeleitete Parameter in src/celeste_iod.rs liegen, sodass sie zurückgehalten werden können).
  • leo-pvt hat vier Modi: Doppler-Positionierung (Batch-Ausgleichung nach kleinsten Quadraten auf der Entfernungsrate mit Uhrendrift- und Geschwindigkeitszuständen, ein reiner Doppler-Gelegenheitssignalmodus, die Along-Track- und Cross-Track-Genauigkeit eines einzelnen Überflugs sowie die Hüllkurve aus Doppler, Dopplerrate und Ruck); gemeinsame GNSS- + LEO-gewichtete kleinste Quadrate mit einer Uhr je System (die Intersystemabweichung) oder einem bekannten Versatz, Sigmas je Messung als Eingaben und dem DOP gegenüber der Anzahl der LEO-Satelliten; polare und arktische Abdeckung gegenüber der Breite; und LEO-Zeitübertragung zur koordinierten Weltzeit (UTC) gegenüber C/N0 und dem Empfängeroszillator mit dem Ausdruck von Systemzeit zu UTC aus IS-GPS-200.
  • leo-ppp: ein Extended-Kalman-Filter für Float-Precise-Point-Positioning (PPP) auf ionosphärenfreiem Code und ionosphärenfreier Phase, nur GNSS und mit LEO-Unterstützung, mit seiner Konvergenzzeit und einem Monte-Carlo-NEES-Konsistenztest (normalisiertes quadratisches Schätzfehlermaß). Das mitgelieferte Szenario ergibt 7,4 min mit vier MEO-Systemen und 4,8, 3,2, 2,7 und 2,3 min mit 60, 96, 192 und 288 LEO-Satelliten, neben den 9,6, 7,0, 3,2, 2,1 und 1,3 min von Li et al. (J. Geod. 93:749, 2019) als Vergleich MODELLED des Trends.
  • ntn-positioning: Positionierung in 5G-Nicht-Terrestrischen-Netzen (NTN) im mobilen Satelliten-S-Band 3GPP n256 aus der Cramér-Rao-Schranke für Ankunftszeit und Doppler.
  • Szenarien: leo-doppler-positioning, starlink-sop-doppler-positioning, meo-leo-fused-pvt, leo-ppp-convergence, ntn-5g-positioning, polar-arctic-leo-coverage, leo-timing-utc (mitgeliefert) und celeste-iod-fused-pvt (nur im Repository, zurückgehalten mit der Voreinstellung Celeste IOD).
  • Acht Matrixzeilen: die LEO-Doppler-Hüllkurve VALIDATED gegenüber den veröffentlichten Zahlen für Iridium (±36 kHz: 35,9 kHz, innerhalb von 5%) und Xona Pulsar X1 (32 bis 34 kHz: 33,6 kHz aus der Schale mit 97 Grad, ohne Aufweitung) (tests/leo_doppler_reference.rs); Doppler-Positionierung, gemeinsame Pseudorange-Positionierung, PPP-Konvergenz, NTN-Schranken, LEO-Zeitgebung, polare Abdeckung und die Voreinstellungen MODELLED. Drei Arten und acht Szenariodateien. Dokumentation: docs/LEO-PNT-FUSION.md.
• LEO-PNT Ende zu Ende: die Art leo-pnt-chain und die miteinander verdrahteten LEO-Stufen. Ein System für Positionierung, Navigation und Zeitgebung (PNT) im niedrigen Erdorbit (LEO), verfolgt von seinem Signalentwurf bis zur Position des Nutzers, jede Stufe eine eigene Art der Engine auf ihrer eigenen Szenariotabelle, mit im Code weitergereichten Werten (docs/LEO-PNT.md):
  • Bänder von leo-pass können einen Entwurf leo-signal benennen (signal = "xona-x5"): das Band übernimmt die Mittenfrequenz, die Sendebandbreite und die Chiprate der verfolgten Komponente des Entwurfs, teilt seine EIRP (äquivalente isotrope Strahlungsleistung) auf die Komponenten des Entwurfs auf und meldet für jede Epoche das C/N0 (Träger-Rauschleistungsdichte) der verfolgten Komponente und den bandbegrenzten Code-Tracking-Jitter (den Entfernungsfehler; das Paarrauschen von iono_free verwendet ihn ebenfalls). Ein Band ohne Entwurf liefert dieselbe Ausgabe wie zuvor.
  • leo-pnt-chain führt aus: Signal -> Überflug -> Navigationsnachricht -> fusionierter gemeinsamer Fix von leo-pvt -> optional leo-ppp. Jedes LEO-System der Positionierungsstufe, das sie nicht gesetzt lässt, übernimmt eine C/N0-Linie in sin(Elevation), angepasst an den Überflug, den Signal-in-Space-Entfernungsfehler der Nachricht (SISRE: ihren Darstellungsfehler auf der Bahn des Überflugsatelliten, mit einem angegebenen Bahnbestimmungsterm od_sisre_m als Wurzel der Quadratsumme) sowie Träger und Chiprate des Entwurfs; die Fälle des Precise Point Positioning (PPP) übernehmen den SISRE. Jede Übergabe ist mit Wert und Einheit aufgeführt, und tests/leo_pnt_chain.rs prüft, dass jede der Ausgabe davor entspricht und dass Änderungen davor die nachfolgenden Zahlen verschieben. LeoNavmsgScenario::broadcast_sisre ist der neue Einstiegspunkt der Nachricht.
  • Szenarien: leo-pnt-end-to-end (eine generische Konstellation mit 1080 km und das repräsentative Signal generic-l), xona-pulsar-end-to-end (das öffentliche X5-Signal), beide mitgeliefert, sowie das optionale, nur im Repository vorhandene celeste-iod-end-to-end.
  • Die Celeste-IOD-Voreinstellungen (Demonstration im Orbit) der Bereiche Überflug, Nachricht und fusionierte Positionierung liegen jetzt in einer Datei, src/celeste_iod.rs, die build.rs nur einbindet, wenn sie existiert (das Konfigurationskennzeichen kshana_celeste). Ihre fünf Szenarien (scenarios/*celeste-iod*.toml) gibt es nur im Repository, sodass das Löschen dieser Datei und dieser Szenarien jede auf dem ESA-NAVISP-LEO-PNT-Workshop 2026 vorgestellte Zahl ohne Quelltextänderung zurückhält; tests/workshop_preset_isolation.rs prüft, welche Dateien die Voreinstellung nennen oder ihre Bandplan-Zahlen tragen dürfen.
  • Jede LEO-Art in der Gegenüberstellung des erweiterten Berichts, wobei ihre pfadspezifischen Zeilen nur aufgeführt werden, wenn der Lauf diesen Pfad nahm (eine Regenrate, ein Gebäude, eine Analyse oder ein Modus, der lief). Doppler-Fenster von leo-pvt erhalten t_s und Fälle von leo-ppp erhalten t_min, sodass beide animiert werden; leo-pass und leo-pnt-chain exportieren CZML, KML, GeoJSON und STK-Ephemeriden, und die anderen LEO-Arten geben an, warum ein Format nicht zutrifft.

Navigation im niedrigen Erdorbit: Resilienz, Schwerpunktbereiche und Endnutzer-Szenarien

• LEO-PNT-Resilienz, ein Szenario je Experiment-Schwerpunktbereich und eines je Endnutzer-Vertikale sowie docs/LEO-PNT.md als Überblick über jede LEO-Art und jedes Szenario. Jedes Szenario läuft ohne Celeste-Daten und ist mitgeliefert.
  • leo-pass erhält einen Abschnitt [spoofer]: ein Spoofer fälscht in sich konsistent in Entfernung und Entfernungsrate die Signale einer behaupteten Position, die nach einem Einsatz springt und/oder von der wahren weggeschoben wird (je LEO-Band und das MEO-GNSS-Signal), mit oder ohne Ionosphäre. Zwei Monitore laufen bei einer angegebenen Fehlalarmwahrscheinlichkeit: Doppler- und Überflug-Geometrie-Konsistenz (gemessene Entfernungsraten gegenüber den aus den Bahnen und einer unabhängigen vorherigen Position und Geschwindigkeit vorhergesagten; ein verallgemeinertes Chi-Quadrat nach kleinsten Quadraten über ein Fenster, auf den GNSS-, LEO- und allen Kanälen, Rauschen der Frequenzregelschleife aus C/N0) und Konsistenz zwischen den Bändern (der Sprung der modellkorrigierten geometriefreien Kombination jedes LEO-Bandpaars). Das Ergebnis gibt die Statistiken je Epoche an (sodass es animiert wird), jedes Paar und wann jeder Monitor erkennt. Bausteine in leo_link::spoof. Fehlt der Abschnitt, bleibt die Ausgabe unverändert.
  • Jedes Bandpaar von leo-pass meldet außerdem den schrägen Gesamtelektroneninhalt (TEC), den seine geometriefreie Kombination im Überflugmaximum zurückgewinnt, und das Code-Rauschsigma dieser Schätzung (Ionosphärensondierung). Das fügt jedem Multiband-Ergebnis von leo-pass zwei Felder hinzu; keine bestehende Zahl ändert sich.
  • Der Zeitgebungsmodus von leo-pvt nimmt trace = true: jede Zeile meldet dann ihren Zeitfehler und ihr vorhergesagtes Sigma zu jeder Epoche, mit denselben Ziehungen, sodass die Zeilenstatistiken unverändert sind und der Lauf animiert und in einer Kampagne verkettet wird.
  • Eine Kampagne exportiert jetzt jedes Mitgliedsszenario mit Geometrie (Phasenläufe, die Basisszenarien von Sweep und Monte-Carlo, zusammengesetzte Mitglieder mit ihren gebundenen gemeinsamen Werten) als eigenen Dateisatz, mit der Mitgliedsbezeichnung im Dateinamen; zuvor exportierte eine Kampagne nichts. Die Interoperabilitätstabelle in docs/INTEROP.md ändert sich entsprechend.
  • Ein Sweep-Schlüssel einer Kampagne kann ein Array von Tabellen nach Position indizieren (system.2.sisre_m).
  • Resilienzszenarien: leo-resilience-multiband-diversity (ein Breitbandstörer von 50 MHz im L5-Band, in der Leistung durchgefahren: jedes L-Band-Signal fällt, die LEO-Signale in UHF-, S- und C-Band behalten ihr C/N0), leo-resilience-js-margin (J/S-Marge aus der Empfangsleistung: GPS L5, Galileo E5a und Xona X5 gehen bei -105, -100 und -95 dBW verloren, ein generisches LEO-Signal mit -135 dBW wird bei -90 dBW noch verfolgt), leo-resilience-spoof-doppler (ein Sprung von 30 m, vom reinen GNSS-Doppler-Test verfehlt und vom Test auf allen Kanälen 105 s nach dem Einsatz erkannt), leo-resilience-spoof-monitors (vier Spoofer gegen beide Monitore) und leo-resilience-gnss-jammed-leo-carries (GNSS gestört, die LEO-Schicht in S- und C-Band verfolgt, die Überwachung der Empfängerintegrität (RAIM) allein auf der LEO-Schicht schlägt bei 2 von 30 Epochen Alarm).
  • Szenarien der Schwerpunktbereiche: leo-focus-ppp-altitude, leo-focus-ntn-bandwidth, leo-focus-iot-eirp, leo-focus-science-iono-sounding, leo-focus-data-services, leo-focus-indoor-uhf, leo-focus-fused-pnt-sisre (Resilienz in L, S und C ist leo-resilience-multiband-diversity).
  • Vertikale Kampagnen, jede animiert und mit Export ihrer LEO-Überflüge: leo-vertical-autonomous-vehicle, leo-vertical-rail-maritime (die mitgelieferten Szenarien für See und Schiene plus LEO), leo-vertical-critical-infrastructure-timing, leo-vertical-polar-arctic, leo-vertical-5g-network-timing, leo-vertical-asset-tracking-iot. Einzeilige Ergebnisse in docs/LEO-PNT.md.
  • Drei Matrixzeilen der Stufe MODELLED: der Spoofing-Monitor für Doppler und Überflug-Geometrie, der Spoofing-Monitor zwischen den Bändern und die Ionosphärensondierung. tests/leo_resilience_verticals.rs prüft die Monitore (still vor dem Einsatz, die Doppler-Statistik quadratisch im Sprung, der ionosphärische Sprung eines Bodenspoofers und keiner bei einem ionosphärenbewussten), die Sondierungsidentität, die Zeitgebungsspur gegenüber den Zeilenstatistiken und dass der Export einer Kampagne dem jedes Mitglieds entspricht.
  • Die Seite leo-pass zieht nach docs/LEO-PASS.md um; docs/LEO-PNT.md ist der Überblick.

Maritime, Straßen- und Schienenszenarien

• Szenarien für See, Straße und Schiene. Fünf mitgelieferte Beispiele zu bestehenden Arten, sodass Schiffe, Straßenfahrzeuge und Züge je einen durchgerechneten Fall haben. Jede Zahl ist MODELLED; keine ist gegen Messdaten validiert.
  • scenarios/maritime-strait-jamming.toml (jamming): ein Breitbandstörer von 50 W auf einem Mast von 30 m, 30 km über offenes Wasser von einem Schiff entfernt. Mittleres Stör-Signal-Verhältnis (J/S) etwa 48 dB, und die Verfügbarkeit fällt von 1,00 auf 0,00.
  • scenarios/maritime-port-approach-coast.toml (ins-trn-coast): ein Trägheitsnavigationssystem (INS) der Navigationsklasse bei 12 Knoten, GNSS verloren und ohne Stützung. Es überschreitet 10 m nach 281 s und 100 m nach 833 s, die Werte für Hafenansteuerung und Ozeangewässer aus der Resolution A.1046(27) der Internationalen Seeschifffahrts-Organisation (IMO), hier als Budgets verwendet.
  • scenarios/maritime-spoof-position-push.toml (spoof-detect): ein nicht trägerausgerichteter Spoofer mit +2 dB, der vier Satelliten schiebt, um ein Schiff um 500 m abzulenken. Der fusionierte Monitor erkennt ihn (Wert 0,70 gegenüber einer Schwelle von 0,50) über die Überwachung der Empfängerintegrität (RAIM) und die Überwachung der Signalqualität (SQM); die reine Leistungsüberwachung verfehlt ihn.
  • scenarios/automotive-urban-canyon.toml (gnss-ins): ein Auto durch eine Unterführung von 15 s und einen Ausfall durch einen Straßenrandstörer von 60 s, gegenüber einem Budget von 1,5 m für eine halbe Fahrspur. Der fusionierte quadratische Mittelwert (RMS) des Fehlers beim Ausfall beträgt 1,9 m für eine mikroelektromechanische (MEMS) Einheit der Automobilklasse und 0,7 m für einen Vergleich der taktischen Klasse; im freien Lauf driftet die MEMS-Einheit auf 850,8 m.
  • scenarios/rail-tunnel-coast.toml (ins-trn-coast): ein INS der taktischen Klasse auf einem Zug mit 160 km/h in einem Tunnel. Es überschreitet 2 m (Gleisunterscheidung) nach 35,8 s, etwa 1,6 km im Tunnel, und 20 m nach 107,3 s. Das ist nur INS: die Engine hat kein Odometermodell, daher ist es die pessimistische Schranke. Die Anzahl der Szenariodateien in der README steigt von 77 auf 82. Alle fünf sind für kshana example mitgeliefert und im Browser-Playground aufgelistet.

Model-Context-Protocol-Server

• Der Server des Model Context Protocol (MCP) erreicht jede Art und jede Ansicht eines Laufs: sieben neue Werkzeuge, insgesamt vierzehn. run_scenario hat bereits jede Art bedient; was einem Agenten fehlte, war ein Weg zu einem gültigen Szenario einer Art und zu den drei Ausgaben, die die Befehlszeile neben einem Ergebnis schreibt. Neue Werkzeuge:

  • list_example_scenarios und get_example_scenario liefern die mitgelieferten Referenzszenarien (die Tabelle von kshana example), jeweils mit ihrer Art und dem ersten Satz ihres eigenen Kopfes, Byte für Byte die Datei unter scenarios/. Ein Szenario, das im Repository liegt, aber nicht mitgeliefert wird, wird mit Begründung abgelehnt. Jede Art außer lunar-llr-datum (deren Datenausschnitt nur mit dem Repository ausgeliefert wird) hat mindestens ein Beispiel.
  • report_scenario liefert den Bericht des Laufs als JSON (JavaScript Object Notation) oder als druckbare HTML-Seite (HyperText Markup Language) (docs/REPORTS.md).
  • animate_scenario liefert die Zeitreihen des Laufs als animierte SVG-Zeichnung (Scalable Vector Graphics), als HTML-Player oder als nummerierte Einzelbilder, nach einer JSON-Zusammenfassung dessen, was gezeichnet wurde (docs/ANIMATION.md). Eine Antwort enthält höchstens 120 Einzelbilder; die Befehlszeile schreibt jede Länge.
  • list_export_formats, export_interop und import_route liefern die Interoperabilitätsexporte und den GeoJSON-Routenimport (docs/INTEROP.md): CZML (Cesium Language), KML (Keyhole Markup Language), GeoJSON, die STK-Ephemeride (Systems Tool Kit) .e und SigMF (Signal Metadata Format), mit einem JSON-Index der Dateien (Endung, Größe und SHA-256, der 256-Bit-Digest des Secure Hash Algorithm) und der binären SigMF-Abtastdatei als Base64.

  Die Bibliothek erhält ein standardmäßig ausgeschaltetes Feature bundled-scenarios, das die Tabelle der Referenzszenarien als kshana::bundled_scenarios bereitstellt; nur der MCP-Server schaltet es ein, sodass das Python-Wheel und das WebAssembly-Modul den Szenariotext weiterhin nicht enthalten. Studiensuiten (--study) bleiben nur der Befehlszeile vorbehalten, weil eine Suite Dateien auf der Festplatte benennt und der Server keine liest. Die Round-Trip-Tests führen jedes neue Werkzeug gegen mitgelieferte Szenarien aus und prüfen die Zahlen der Engine: Spektrum, das Sonnensystem, Konstellationen um Mond und Europa, einen Kampagnen-Sweep sowie die Arten für LEO-Signal (niedriger Erdorbit), Überflug, Navigationsnachricht, fusionierte Positionierung, Precise Point Positioning, Nicht-Terrestrische Netze und Ende zu Ende. Jede Oberfläche, die die Anzahl der MCP-Werkzeuge nennt oder die Werkzeuge auflistet, sagt jetzt vierzehn, außer der Playground-Seite unter web/, die durch die Website ersetzt wird.

kshana.dev, Kshana Studio und die README

• Ein neu gestaltetes kshana.dev. Die einzelne Playground-Seite wird durch eine mehrseitige Website ersetzt: Home, Missions, Capabilities, Evidence, Developers, Editions und Docs, mit Kshana Studio einen Klick entfernt. Jedes Diagramm, jede Karte und jede Zahl darauf ist ein aufgezeichneter Lauf der Engine dieser Version, mit dem Szenario und einem Link, der denselben Lauf im Studio wieder öffnet; der Build der Website lehnt eine Aufzeichnung ab, die mit einem anderen Engine-Commit gemacht wurde. Die Dokumentationsseiten werden aus docs/ des Repositorys erzeugt, die Installationsoptionen aus seinen Kanälen. Schriften und Skriptbibliotheken werden von kshana.dev selbst ausgeliefert, sodass keine Seite etwas bei einem Drittanbieter-Host anfordert. Alte Adressen (/#playground, /#ledger, Share-Links /#s=<scenario>, Embed-Links /?embed=1&… und die übrigen) leiten an ihren neuen Ort weiter, und eine unbekannte Adresse erhält eine 404-Seite.
• Kshana Studio, ein Dashboard für jede Fähigkeit. Das Studio öffnet mit einem Startbildschirm mit Domänenkacheln und guten ersten Läufen und führt einen Lauf dann durch fünf nummerierte Schritte: Szenario wählen, Parameter setzen, die Engine lokal im Browser ausführen, die Ergebnisse lesen (zuerst die Kennzahlen, jede mit einem Chip PASS oder FAIL, wo der Lauf eine Schwelle nennt, dann die Panels) und teilen oder exportieren. Ein Suchfeld findet Szenarien, Domänen und die Felder darin und springt zum Bedienelement; Läufe können angeheftet und verglichen werden; eine Pfadanzeige zeigt, wo Sie sich befinden; auf dem Smartphone werden die Schritte zu einer Schrittleiste. Jede Szenarioart hat ihre Ansicht, darunter den Spektrum-Wasserfall, das Sonnensystem, die Konstellationsabdeckung, Kampagnen, die Animation, den Laufbericht, die Interoperabilitätsexporte und die Kette für niedrige Erdumlaufbahnen. Ein Deep-Link (?scenario=…&tab=…) öffnet denselben Lauf im genannten Panel.
• Forschung und Zitierung. Die Seite Evidence listet die fünf Kshana-Veröffentlichungen auf arXiv (2606,22054, 2606,24210, 2607,02566, 2607,05415 und 2607,06212), jede mit einer Zusammenfassung, einer von dieser Engine berechneten Abbildung, dem Befehl, der sie reproduziert, einem Studio-Link und BibTeX, neben dem Hinweis, wie die Software zu zitieren ist. Die README erhält denselben Abschnitt Research.
• Eine öffentliche Seite für Kshana Pro. docs/PRO.md und die Seite Editions der Website sagen, was die proprietäre Pro-Überlagerung über derselben Engine hinzufügt (Designoptimierer, Unsicherheit und Sensitivität, Missionsdossier, Kampagnenüberwachung, Spektrumkoexistenz, lokaler Auftragsdienst, Anforderungsrückverfolgbarkeit), was jedes erzeugt und was nicht. Jede Pro-Zahl, die die Website zeigt, ist auf dieser öffentlichen Seite angegeben. Pro fügt kein physikalisches Modell hinzu, und die offene Engine bleibt vollständig und frei.
• Eine neu geschriebene README. Kurze Abschnitte, ein Bild je Abschnitt, das Kshana-Zeichen, zwei Badge-Reihen, erzeugte Bilder zu Architektur, Szenarioablauf, Kette im niedrigen Erdorbit und Verifikation (tools/gen_readme_assets.py, das bei einem veralteten Bild fehlschlägt) sowie Studio-Screenshots, die tools/capture_studio_shots.mjs aus dem laufenden Studio aufnimmt. Die READMEs von crates.io, PyPI, npm und MCP-Server folgen demselben Design. Langes Referenzmaterial wird eingeklappt oder nach docs/ verlegt.

Geändert#

• <scenario>.report.html ist jetzt der erweiterte Laufbericht, der unter Added beschrieben ist, und die Zeile wrote … der CLI nennt auch <scenario>.report.json. Die einseitige Auswertung, die er ersetzt hat, ist als RunOutput::html_report() unverändert, den die Python- und WebAssembly-Bindungen weiterhin liefern. OracleKind::modelled_reason() stellt den Satz bereit, den docs/MODELLED-RATIONALE.md für jede Zeile mit MODELLED ausgibt; dieses Dokument ist unverändert.
• Die README sagt, worauf Kshana Pro aufbaut. Der Abschnitt Editions und die Zeile zu Kshana Pro unter "Support & professional services" sagen jetzt, was die modellbasierten Systems-Engineering-Werkzeuge (MBSE) und Programmwerkzeuge von Pro tun und welche veröffentlichten Ausgaben der offenen Engine sie lesen (result.json und report.json jedes Laufs, die Szenariodatei, das Einheitenschema der Felder und die Bezeichnungen der Verifikationsmatrix) und worauf die Uhren-Digitalzwillinge, Trade-Studien und Nachweispakete in der offenen Engine beruhen. Nur der Wortlaut: keine Ausgabe der Engine und keine veröffentlichte Zahl ändert sich.
• Kompatibilität. Das öffentliche Enum navsignal::Modulation erhält eine Variante Mboc, was für einen Aufrufer, der es erschöpfend abgleicht, eine inkompatible Änderung ist. Die Spalten gcrs_r_m und gcrs_v_m_s der Art ephemeris ändern sich (siehe "Revisions to published numbers"). Ein Lauf wird weiterhin von der Version der Engine reproduziert, die ihn erzeugt hat.

Behoben#

• export_table_csv auf dem MCP-Server nannte vier Arten als einzige mit einer CSV-Tabelle (kommagetrennte Werte); sechs veröffentlichen eine. Das Werkzeug lieferte die Tabelle immer für telecom-timing und für leo-navmsg (seine Analyse encode-decode bei einem Nachrichtenmodell kepler16 oder kepler-rac), aber seine Beschreibung, seine Ablehnungsmeldung und die Dokumente, die die Arten auflisten, ließen beide aus, sodass ein Agent erfuhr, er solle nicht danach fragen. Sie sind jetzt genannt, und ein Round-Trip-Test ruft beide Tabellen ab.

• Der Frame der Navigationsnachricht im niedrigen Erdorbit (LEO) hatte nicht auf jeder Plattform dieselben Bytes, auch nicht in jedem Build einer Plattform. scenarios/leo-navmsg-encode-decode.toml kodierte einen Frame mit zyklischer Redundanzprüfung 0x110315 im Release-Build auf aarch64 macOS, 0x898BD8 in einem Debug-Build desselben Quelltexts auf derselben Maschine und 0x6A82D9 im WebAssembly-Build (WASM); leo-navmsg-celeste-iod.toml ergab nativ 0x6EDB2D gegenüber 0xC6E4F0 im Browser. Drei Ursachen, jede bis zum ersten abweichenden Wert zurückverfolgt:

  • Zwischen Plattformen. Die Wahrheitsbahn war auf beiden bitidentisch; der Startpunkt des Fits nicht. truth::state_to_elements nimmt die oskulierende Inklination aus einem acos und das Argument des Perigäums aus einem atan2, und die beiden Mathematikbibliotheken runden diese in der letzten Stelle unterschiedlich (bei 20.000 Argumenten weichen sie bei 781 Sinuswerten, 858 Kosinuswerten, 1.931 Exponentialfunktionen und 1.899 Arkustangens mit zwei Argumenten ab).
  • Zwischen Build-Profilen. Ein optimierter Build auf macOS fasst einen Sinus und einen Kosinus eines Arguments zu einem einzigen Aufruf der kombinierten Routine des Systems zusammen, und sein Sinus ist bei 379 von 200.000 Argumenten nicht der des einzelnen sin; ein nicht optimierter Build führt die beiden Aufrufe aus. Die Art nimmt an dreizehn Stellen einen Sinus und einen Kosinus zusammen.
  • In der Uhr. Der Normalverteilungs-Sampler von rand_distr ruft in seinen zwei seltenen Zweigen die exp und ln des Hosts auf: von vier Millionen gesäten Ziehungen unterschieden sich drei im letzten Bit zwischen dem nativen und dem WASM-Build.

  Der Levenberg–Marquardt-Fit, der auf diesem Bogen an seiner Grenze von 80 Iterationen stoppt und nicht an einem Minimum, trägt eine Einheit in der letzten Stelle in andere quantisierte Felder. Die Art berechnet jetzt jede transzendente Funktion über das neue src/portable_math.rs, das das reine Rust-Crate libm aufruft (bereits im Abhängigkeitsbaum, jetzt in Cargo.toml benannt), aus einem Quelltext für jedes Ziel kompiliert und kein Bibliotheksaufruf, den der Optimierer umschreibt: leo_navmsg::{truth, fit, elements, codec, sisre, services} und der Szenariocode. Ganzzahlige Potenzen auf diesem Pfad sind als Square-and-Multiply ausgeschrieben, weil f64::powi eine nicht spezifizierte Genauigkeit hat, und die Wahrheitsuhr zieht ihre normalverteilten Abweichungen aus portable_math::standard_normal (Marsaglias Polarmethode auf der Rohausgabe des Generators). Die gemeinsamen Routinen, über die die Wahrheitsbahn integriert, sind einmal geschrieben, generisch über die Mathematikbibliothek, mit einem Crate-internen Einstiegspunkt _portable neben dem bestehenden: die Beschleunigung aus Kugelfunktionen, die zonalen Beschleunigungen und der Luftwiderstand, die säkularen J2-Raten und die Klobuchar-Laufzeit. Die bestehenden Einstiegspunkte sind bis auf das letzte Bit unverändert, sodass sich keine Zahl einer anderen Art verschiebt. leo_navmsg::tests::the_encoded_frame_is_the_same_bytes_on_every_platform legt den ganzen 171-Byte-Frame und einen Prüfwert je Ephemeridenmodell fest, im gewöhnlichen (nicht optimierten) Testprofil, auf jeder Plattform und ohne Baseline-Host-Gate; the_kind_never_calls_the_host_mathematics_library liest die Quelltexte der Art von der Festplatte und schlägt bei einem inhärenten transzendenten Aufruf fehl, bei einem Sampler rand_distr oder bei einem Aufruf in ein Modul, das nicht geprüft wurde. Nach der Änderung erzeugen ein Debug-Build, ein Release-Build und der WASM-Build bytegleiche Ergebnisdokumente für alle fünf Szenarien leo-navmsg. Das verschiebt Zahlen und wird hier als Revision festgehalten. Die Art leo-navmsg ist in dieser Version neu, sodass sich nichts verschiebt, was in einer früheren Version veröffentlicht wurde, aber jede Zahl von leo-navmsg verschiebt sich, nativ und im WASM-Build, und die Stufe navmsg von leo-pnt-chain mit ihr: die Bahnzahlen, weil der Fit jetzt von den portablen Elementen ausgeht, die Uhrenzahlen, weil die Wahrheitsuhr eine andere Realisierung desselben Prozesses ist. docs/LEO-NAVMSG.md wird aus den neuen Ergebnissen neu erzeugt; ihr veröffentlichter Prüfwert für das Szenario Kodieren und Dekodieren war 0x110315 und ist 0x19105F (Position innerhalb von 1,126 mm der exakten Nachricht, wo sie 0,665 mm war, Uhr innerhalb von 0,185 mm, wo sie 0,451 mm war). Die Größe der Änderungen bei den Zahlen im Submillimeterbereich ist die Sensitivität des Fits, kein Fehler in einem der beiden Sätze: der Fit ist unverändert und stoppt weiterhin an seiner Iterationsgrenze.

• Gesätes Resampling zog auf einem 32-Bit-Ziel andere Indizes. Rng::gen_range über usize nimmt auf einem 64-Bit-Host 64 Bit vom Generator und auf einem 32-Bit-Host 32 Bit, sodass derselbe Seed andere Indizes lieferte und den Strom im WASM-Build anders hinterließ. Drei Stellen zogen so: die Perzentil-Bootstraps in eval_stats (bootstrap_ci, bootstrap_auc_ci), das Mischen vor jedem Trainingsdurchlauf in impairment_ml und der Permutationstest in impairment_study. Sie ziehen jetzt über portable_math::uniform_index, das immer als u64 abtastet: genau das, was ein 64-Bit-Host tat, sodass sich keine native Zahl verschiebt. Das verschiebt veröffentlichte Zahlen des WASM-Pakets und wird hier als Revision festgehalten: das Bootstrap-Intervall der Fläche unter der Kurve für quantum-anomaly-detect (quantum_auc_ci, trade.foms[0].ci95) war [0.9901265, 0.9938305] im Browser und ist jetzt das native [0.99035875, 0.993861].

• Dateinamen der STK-Ephemeriden aus Mover-IDs. Eine Mover-ID mit einem / oder einem Leerzeichen (eine Konstellationsschale und ein Satellit, Pulsar inclined/S1-0163) ließ die CLI bei --export stk in Panik geraten; jede ID läuft jetzt durch einen sicheren Dateinamensteil (Buchstaben, Ziffern, -, _).

• Das Vorzeichen der TEME→GCRS-Nutation, oben unter "Revisions to published numbers" beschrieben, weil es veröffentlichte Ausgaben verschiebt.

0.28.0 - 2026-09-26#

Hinzugefügt#

• Szenarioart slot-timing (src/slot_timing.rs): Sekunden, bis eine freilaufende Uhr die Schutzzeit eines zeitindizierten Routing- oder Tasking-Slots verlässt, jeder beitragende Term in diesem Moment mit Nennung des dominierenden, die seit dem letzten Fix verbleibende Zeit und das größte Fix-Intervall, das die Uhr drinnen hält, abzüglich der Fix-Latenz. Die Uhr stammt aus einem Klassenstandard, einer Voreinstellung aus dem Datenblatt für Telekom-Zeitgebung, einem Inline-Datenblatt (Maxima der Allan-Abweichung, Alterung, Temperaturkoeffizient) oder einer gemessenen Phasenaufzeichnung. Eine Verletzung jenseits der längsten Mittelungszeit, die die Quelle unterstützt, wird als extrapoliert gekennzeichnet. Mitgeliefertes Beispiel: slot-timing-ocxo-leo. Siehe docs/SLOT-TIMING.md.
• Gemessene Untergrenze des roten Rauschens. Die überlappende Allan-Abweichung einer Phasenaufzeichnung wird mit gewichteten kleinsten Quadraten in der Basis aus weißer Phase und Frequenzmodulation nach IEEE Std 1139 angepasst (slot_timing::fit_weighted), jeder Punkt gewichtet mit seinen äquivalenten Freiheitsgraden, sodass eine Holdover-Antwort auf der eigenen Untergrenze der Uhr beruhen kann statt auf der Klassenannahme. Ein ungewichteter Fit setzte eine falsche Flicker-Untergrenze auf eine Testaufzeichnung mit weißem Rauschen und verkürzte eine Verletzung bei 2.000 s um 30 %.
• Validierung der Holdover-Inversion auf zurückgehaltenen Daten an einer realen Uhr (tests/slot_timing_cs5071a_holdout.rs): angepasst auf dem ersten Drittel der Aufzeichnung Caesium 5071A gegen Wasserstoffmaser liegen die vorhergesagten Ein-Sigma-Verletzungen bei sechs Schwellen von 0,5 bis 2,5 ns bei 0,84 bis 1,03 der Verletzungen, die an den anderen zwei Dritteln gemessen wurden, gegenüber einem Zielwert von 1,5, der vor dem ersten Lauf des Tests festgelegt wurde. Eine Kontrolle (die Allan-Abweichung bei einer Sekunde als weißes Rauschen gelesen) verfehlt ihn um einen Faktor von etwa 1.000 und scheitert am Zielwert. Neue Registerzeile der Stufe VALIDATED; der Workflow realdata-clock führt sie jetzt aus.
• Dieselbe Vorhersage an einem realen Quarzoszillator (tests/slot_timing_ocxo_holdout.rs, scripts/fetch_ocxo.sh): bei einem gemessenen ofengesteuerten Quarzoszillator ist die Vorhersage auf zurückgehaltenen Daten konservativ, bei 0,59 bis 0,70 der gemessenen Verletzung und nie später, und größtenteils außerhalb des Zielwerts 1,5, weil sich die Rauschuntergrenze dieses Oszillators während der Aufzeichnung von 5.5 Stunden halbierte; in der Stichprobe angepasst liegt sie bei 0,98 bis 1,17. Der Quarzfall ist nicht validiert und bleibt MODELLED. Der Lauf deckte außerdem einen fehlenden Term auf: die Frequenz eines Quarzes wandert, daher trägt das Modell jetzt die Unsicherheit der beim Fix bekannten Frequenz (fix_frequency_sigma); ohne sie war die Vorhersage um bis zu 2,5× zu optimistisch.
• Dieselbe Vorhersage an Atomuhren im Orbit (tests/slot_timing_igs_holdout.rs, scripts/fetch_igs_clocks.sh): 14 Tage endgültige Uhren des International GNSS Service für die GPS-Block-IIF-Satelliten, mit dem Protokoll, das vor dem Herunterladen der Daten niedergeschrieben wurde. Acht von zehn Satelliten liegen innerhalb des Zielwerts 1,5; G25 und G30 sagen Verletzungen voraus, die bis zu etwa doppelt so spät liegen wie gemessen. Das Protokoll verlangt, dass jeder Satellit besteht, daher ist der Orbitfall nicht validiert und bleibt MODELLED; das Ergebnis ist festgeschrieben.
• Uhrenklassen temperaturkompensierter Quarz (TCXO), ofengesteuerter Quarz (OCXO) und Rubidium-Atomfrequenznormal (RAFS) (ClockClass::Tcxo, Ocxo, Rafs), die Teile, die ein kommerzieller Smallsat-Bus oder ein Bodengateway fliegt, jede mit Verweis auf ein öffentliches Datenblatt (ClockClass::source). ClockClass::ALL, id und from_id hinzugefügt. baseline_clock_class von quantum-trade akzeptiert die drei neuen IDs. Das Hinzufügen von Varianten zu einem öffentlichen Enum ist für einen Aufrufer, der es erschöpfend abgleicht, eine inkompatible Änderung.
• Zeitgebungs-Schutzniveau für einen Empfänger im Orbit (src/orbital_timing.rs, der optionale Abschnitt spoofing der Art slot-timing): wie lange ein Bodenspoofer einen Satelliten im niedrigen Erdorbit je Überflug erreichen kann, den Versatz, den ein Spoofer mit einer angegebenen maximalen Rampenrate ansammelt, bevor der Satellit seine Reichweite verlässt oder eine unabhängige Prüfung läuft, und ob jede Bodenkontakt- oder Crosslink-Prüfung von diesem Spoofer unabhängig ist. Reduziert sich exakt auf tpl::timing_protection_level_ns bei einer Uhr ohne Flicker-, Weißphasen- oder Random-Run-Rauschen. MODELLED.
• Drei Hinweise: docs/SLOT-TIMING.md (einschließlich der Frage, an welcher Wander-Metrik ein Slot akzeptiert werden sollte: maximaler absoluter Zeitfehler, nicht maximaler Zeitintervallfehler oder Zeitabweichung, und warum), docs/DECEIVED-TIME.md (ein signierter Befehl, der zu einer getäuschten Zeit angewandt wird, leitet trotzdem falsch) und docs/DEPLOYMENT-TARGETS.md (wo Kshana läuft; es wird kein Flugkern no_std angeboten).

0.27.4 - 2026-09-26#

Die Version v0.27.3 erreichte crates.io (kshana und kshana-mcp) und PyPI und blieb dann bei npm stehen, sodass npm, das ghcr.io-MCP-Image, die MCP-Registry, der JetBrains Marketplace und kshana.dev sie nie erhielten. 0.27.4 trägt dieselbe Engine, mit der unten genannten Korrektur der Veröffentlichung, in jeden Kanal.

Behoben#

• Der npm-Veröffentlichungsschritt benennt das Tarball über einen expliziten Pfad. npm liest ein nacktes npm-dist/kshana-0.27.3.tgz als die GitHub-Kurzform owner/repo, sodass der npm-Job von v0.27.3 versuchte, github.com/npm-dist/kshana-0.27.3.tgz zu klonen, und mit "Permission denied (publickey)" scheiterte. Das Tarball selbst war gebaut und attestiert worden. Der Schritt veröffentlicht jetzt ./npm-dist/*.tgz. Alles nach npm in der Reihenfolge der Veröffentlichung (das MCP-Image, das JetBrains-Plugin, die Prüfung der Kanalparität und die Website) wurde wie vorgesehen übersprungen.

Geändert#

• Die Einheitenkataloge für Telekom-Zeitgebung und gnss-ins sind von der Copy-Paste-Erkennung ausgenommen, nach derselben Richtlinie und demselben Begründungstest wie die anderen Kataloge. Das Quality Gate von SonarCloud war wegen Duplikation im neuen Code rot geworden (4,0 % gegenüber 3 %), und jeder duplizierte Block war eine Einheitenzeile oder ein ITU-T-Maskeneintrag.

0.27.3 - 2026-09-25#

Hinzugefügt#

• scenarios/small-uas-jammed-nav.toml: wie lange die Navigation einer kleinen Drohne nach einer GNSS-Störung hält. Es lässt eine mikroelektromechanische (MEMS) Inertialeinheit der Klasse eines Flugreglers, einen Bosch BMI088, gegen eine Einheit der taktischen Klasse laufen. Das GNSS-Signal (Global Navigation Satellite System) ist 100 s lang nominal, dann 60 s lang verweigert (jamming-demo.toml zeigt, warum ein naher Störer das tut). Die Bias-Werte des BMI088 sind die Residuen, die nach der Kalibrierung beim Start bleiben, entnommen den Temperaturkoeffizienten in seinem Datenblatt (BST-BMI088-DS000-19 rev 1,9): 0,015 °/s je K für das Gyroskop und < 0,2 mg je K für den Beschleunigungsmesser. Zwei Annahmen sind in der Datei gekennzeichnet: eine Erwärmung um 10 K nach der Kalibrierung und eine fortgesetzte Erwärmung um 1 K pro Minute im Flug. Die Drift im Flug ist der Fehler, den das Filter vor Beginn der Störung nicht lernen kann, und sie beendet das Koppeln. Jede Zahl ist modelliert; sie zu validieren erfordert Flugprotokolle aus einer gestörten Umgebung. kshana example small-uas-jammed-nav gibt es aus.

• Jeder Sensor von gnss-ins kann sein eigenes Filter-Prior setzen ([imu_quantum.filter_prior] oder [imu_classical.filter_prior], mit sigma_accel_bias und sigma_gyro_bias). Der Standard ist unverändert, sodass jedes bestehende Szenario dasselbe Ergebnis liefert. Der Rest-Gyroskop-Bias einer Einheit der Verbraucherklasse liegt etwa 26 Sigma außerhalb des Standards der taktischen Klasse, wo das Filter ihn nie lernen würde. Ein Prior, der nicht endlich und positiv ist, wird abgelehnt, und das Ergebnis gibt den Prior wieder, wenn einer gesetzt ist.

• kshana example [<name>] gibt einem Registry-Nutzer ein Szenario zum Ausführen. Ein Nutzer von cargo install kshana hat die ausführbare Datei und kein Verzeichnis scenarios/, sodass der erste Befehl jeder Kurzanleitung bei ihm fehlschlug. Die Befehlszeilenschnittstelle (CLI) trägt jetzt die 75 Referenzszenarien, die für sich laufen, Byte für Byte aus scenarios/ einkompiliert (src/bundled_scenarios.rs; die Tabelle liegt in der CLI-Binärdatei, sodass das Python-Wheel und das WebAssembly-Modul nicht wachsen). kshana example listet sie auf; kshana example clock-holdover > clock-holdover.toml schreibt eines. Die anderen zwei Dateien gibt es nur im Repository: lunar-llr-datum liest archivierte Daten der Laserentfernungsmessung zum Mond, die nur mit dem Repository ausgeliefert werden, und quantum-pnt-demonstrator.suite ist ein Studienmanifest, das drei Schwesterdateien mit --study ausführt. Wer eine davon anfordert, erhält den Grund und Exit-Code 2, statt dass etwas ausgegeben wird, das nicht für sich laufen kann. tests/cli_first_run.rs hält die Tabelle in beide Richtungen am Verzeichnis fest, sodass eine neue Szenariodatei, die weder mitgeliefert noch als nur im Repository benannt ist, fehlschlägt.

• Jede Kennzahl in einem Uhren-, Orbit-, Hybrid- oder Fusionsergebnis sagt jetzt im Ergebnis selbst, ob sie VALIDATED oder MODELLED ist. Das Ergebnisdokument erhält einen Block figure_tiers, immer sein letzter Schlüssel. Er listet jede gemeldete Zahl (zum Beispiel quantum.fom.timing_p95_ns) mit ihrer Stufe auf — VALIDATED bedeutet gegen eine unabhängige externe Referenz geprüft, MODELLED bedeutet ein Modell aus ersten Prinzipien, das intern getestet wird — und der Zeile der Verifikationsmatrix, aus der die Stufe gelesen wird. Die Stufe kommt aus src/verification.rs über src/fom_label.rs, sodass es keine zweite Tabelle gibt, die auseinanderlaufen kann. Zuvor kamen die Wörter "validiert" und "modelliert" in einem Ergebnis zum Uhren-Holdover null Mal vor, und ein Leser des rohen JSON (JavaScript Object Notation) konnte die beiden nicht unterscheiden. Die Positionszahlen von hybrid und fusion haben keine zugehörige Matrixzeile, daher sind sie unter untiered aufgeführt, statt eine Stufe zu erhalten. Der Block enthält keine Zahlen. Es ist als additiv bewiesen, nicht angenommen: sein Entfernen liefert das Dokument vor der Änderung Byte für Byte zurück, für alle fünf Arten (ein Engine-Test), und beide Golden-Harnesses (tests/registry_golden.rs, tests/cross_platform_golden.rs) entfernen jetzt genau diesen Schlüssel, und nur, wenn er der letzte ist, und bilden dann den Hash des Rests gegen ihre unveränderten eingefrorenen Konstanten. Eine Liste in jedem Harness legt fest, welche Szenarien den Block tragen müssen, sodass sich der Ausschluss nicht unbemerkt ausweiten kann.

• Eine Art telecom-timing antwortet in den Einheiten eines Zeitgebungsingenieurs: Zeitfehler, maximaler Zeitintervallfehler (MTIE) und Zeitabweichung (TDEV), jeweils mit PASS oder FAIL und einer Marge gegenüber den Masken des Sektors Telekommunikationsstandardisierung der Internationalen Fernmeldeunion (ITU-T). Die Masken sind aus den geltenden Ausgaben übernommen: G.8272 (07/2025) für die Klassen A und B der primären Referenzzeituhr (PRTC), G.8272.1 (2024) Amd. 1 (07/2025) für die erweiterte PRTC im verriegelten Modus und im Holdover (einschließlich ihrer Zeitfehlerhüllkurve, die über eine Holdover-Periode, die davon abhängt, wie lange die Uhr verriegelt war, von 30 ns auf 100 ns ansteigt), G.8273.2 (2023) Amd. 2 (11/2025) für Telekom-Grenzuhren und -Zeitslaveuhren der Klassen A bis D und G.8271.1 (2022) Amd. 3 (05/2025) für die Netzgrenzen am Referenzpunkt C. Jeder Eintrag, den diese Empfehlungen "für weitere Studien" lassen, fehlt, wird nicht geschätzt, und docs/TELECOM-TIMING.md listet jede Zahl mit ihrer Tabelle oder Klausel und jedes ausgelassene Element auf. Der Bericht gibt außerdem die Zeit bis zur Überschreitung jedes Zeitfehlerbudgets an: standardmäßig die Holdover-Voreinstellung der ePRTC von 100 ns, eine Netz-Holdover-Zuteilung von 400 ns, die Grenze am Punkt C von 1.100 ns und die Ende-zu-Ende-Anforderung von 1,5 Mikrosekunden der Klasse 4.

  Die Eingabe ist entweder ein synthetischer Holdover oder eine eigene Reihe. Der synthetische nutzt eine von vier Oszillator-Voreinstellungen (ein ofengesteuerter Quarzoszillator, ein Rubidiumnormal, ein Caesiumnormal und eine Atomuhr im Chip-Maßstab), jede mit den Stabilitäts-, Alterungs- und Temperaturwerten eines benannten Microchip-Datenblatts. Wie diese Werte zu weißem, Flicker- und Random-Walk-Frequenzrauschen, zu Alterung und zu einem Temperaturterm werden, ist in jedem Bericht angegeben und mit MODELLED gekennzeichnet. Eine eigene Reihe sind Paare [time_s, time_error_ns], inline (so läuft es im Browser) oder, bei nativen Builds, aus einer Datei mit kommagetrennten Werten. Die MTIE/TDEV-Tabelle, mit der Grenze jeder gewählten Maske daneben, wird als CSV-Artefakt des Laufs geschrieben.

  scenarios/telecom-prtc-holdover-24h.toml ist ein Rubidium-Holdover über 24 Stunden mit Alterung, Flicker und einem täglichen Temperaturzyklus: sein größter Zeitfehler beträgt 603,2 ns, er überschreitet 100 ns 8.206 s nach dem Verlust und bleibt den ganzen Tag innerhalb von 1,5 Mikrosekunden, und er besteht die Holdover-Hüllkurve der erweiterten PRTC nicht, wie es eine Uhr tun sollte, die nicht der Caesium-Klasse angehört. scenarios/telecom-tie-ingest.toml zeigt die Inline-Eingabe. MTIE und TDEV, die die Art meldet, werden gegenüber dem Paket allantools an einer festgeschriebenen Holdover-Reihe mit 2 048 Abtastwerten geprüft, exakt für MTIE und auf 1.1e-15 für TDEV, sodass die Matrix eine Zeile VALIDATED und zwei Zeilen MODELLED hinzugewinnt (die Transkription der Masken und die Voreinstellungen) und nun bei 171 Zeilen steht — 65 VALIDATED, 102 MODELLED, 4 PARTNER. Die Abdeckung der Feldeinheiten geht von 60 von 61 Arten auf 61 von 62 und von 1.742 auf 1.788 beschriebene Felder. Die Art ist neu und additiv: Kein bestehendes Szenario, keine Festschreibung und keine veröffentlichte Zahl verschiebt sich.

• Der Playground führt die Engine in einem Web Worker im Hintergrund aus, sodass ein langsames Szenario die Seite nicht mehr einfriert. web/engine-worker.mjs hostet die WebAssembly-Engine, und web/engine.mjs leitet jede Szenarioausführung an sie weiter — Läufe, Parameter-Sweeps und die Exporte SP3 / OMM / OEM / CSV. Ein Lauf, der länger als 150 ms dauert, zeigt einen Zustand "beschäftigt" (Run deaktiviert, "Running… N s") und eine Schaltfläche Cancel, die den Worker beendet und neu startet; ein Browser, der keinen Modul-Worker starten kann, fällt auf den alten Pfad im Hauptthread zurück. cislunar-arc-recovery, das aus dem Katalog genommen worden war, weil es die Seite einfror, ist wieder darin, als langsam gekennzeichnet: es braucht in Chrome etwa 13 s (vier Engine-Aufrufe zu je etwa 3 s), währenddessen die Seite ansprechbar bleibt.

• Jede gemeldete Größe von cislunar-observability trägt jetzt eine Einheit, eine Herkunftsklasse und eine Definition — die vorletzte Art auf der crateweiten Ausnahmeliste. Alle 41 numerischen Felder des RELEASED-Dokuments sind beschrieben, sodass die Abdeckung der Felder-Einheiten von 59 von 61 Arten auf 60 von 61 steigt und von 1.698 auf 1.742 beschriebene Felder, wobei der Rückstand ohne Definition unverändert bei 239 bleibt.

  Das war durch die Festschreibung blockiert, die das veröffentlichte Dokument einfriert und units als Schlüssel nannte, den das Dokument nie erhalten darf. Einen hinzuzufügen hätte bedeutet, diese Zusicherung zu löschen und drei Hashes in drei Dateien neu zu basieren — eine Form, die sich vom Vertuschen einer Regression nicht unterscheiden lässt. Stattdessen beweisen die zwei Festschreibungen, die dieses Dokument messen, jetzt, dass die Ergänzung additiv ist: jede entfernt den Block units wieder und bildet den Hash neu gegen die Konstante, die eingefroren wurde, bevor es den Block gab, und beide Konstanten sind unverändert. Eine Mutation bestätigt, dass die Garantie echt ist — einen veröffentlichten Wert verschieben und den Hash des ganzen Dokuments so neu basieren, wie es eine nachlässige Korrektur täte, und das Entfernen mit neuem Hash scheitert trotzdem. Die dritte Festschreibung im generischen Registry-Golden-Harness wird im Einklang mit den sechs Geschwistern neu basiert, die genau aus diesem Grund neu basiert wurden, und ihr wertetragendes Literal expect_summary verschiebt sich nicht.

• realtime-frame-eop meldet, an welcher Wahrheit jede Zeile zur Erdorientierung bewertet wurde und wie oft der Rückgriff griff. table3_joint_eop[].{ut1, polar_motion,combined} erhalten truth_source und truth_fallback_rows. Die Untergrenze final wird gegen das endgültige Bulletin B bewertet und kann nur Epochen verwenden, die eines veröffentlichen; jede Zeile dN wird gegen truth_pm()/truth_ut1() bewertet, die auf den schnellen Wert aus Bulletin A zurückgreifen. Beim mitgelieferten Auszug von 2026 sind das 12 von 31 Stichproben bei einem Tag, gegenüber 0 bei der Untergrenze — die Zeile der Untergrenze und die Vorhersagezeilen daneben beruhen also auf messbar unterschiedlicher Wahrheit, was der Bericht jetzt angibt, statt es aus einer Stichprobenzahl erschließen zu lassen, die dort steigt, wo verschachtelte Horizonte es nicht zulassen.

• moonlight-service-volume gibt eine größengleiche Kepler-Basislinie aus. ephemeris_comparison.keplerian_matched führt die illustrative Konstellation erneut mit der eigenen Satellitenzahl des ABGERUFENEN Satzes aus, nur vorhanden, wenn die Zahlen abweichen. Die Zahl ist Teil der Geometrie dieses Designs — RAAN und mittlere Anomalie werden beide als 360k/n verteilt —, sodass ohne sie ein abgerufener Satz mit fünf Satelliten gegen einen illustrativen mit acht bewertet wurde und Design und Größe vermengt wurden. Für den Referenzsatz LANS mit fünf Satelliten erweisen sich 8,68 der 14.24 Punkte Abdeckungslücke als die drei fehlenden Satelliten und nur 5,56 Punkte als das Design; für die vier Raumfahrzeuge, die wirklich im Mondorbit sind, erreicht ein eigens gebauter Satz mit vier Satelliten 4,86 %, wo sie 0 % erreichen. Ein Test legt fest, dass die abgeglichene Zeile eine neu aufgebaute Konstellation ist und nicht die konfigurierte, umbenannt, so wie sie zuerst geschrieben war und was der Lauf dann meldete.

• Neun Fähigkeitskarten auf der öffentlichen Website, die 22 Zeilen der Verifikationsmatrix abdecken, die ohne Karte auf Produktebene ausgeliefert wurden. Die Engine hatte eine Familie von Fähigkeiten hervorgebracht — die ARAIM-Prüfung gegen veröffentlichte Referenzvektoren der Working Group C, reale abgerufene lunare Konstellationsgeometrie, die lunare Verweigerungskontur mit einem gemessenen C/N₀-Band, der Schritt vom VLBI-Zeitplan zur Stationskovarianz, optische und HF-Übergabe mit Fehlerinjektion über Modalitäten hinweg, Echtzeit-Vorhersage der Erdorientierung gegenüber archiviertem Bulletin A, gemeinsame Nutzung der Apertur für Navigation gegenüber Kommunikation, INS/TRN-Koppelnavigation und die Abdeckung von Einheiten und Herkunft — jede mit einer Matrixzeile und einem mitgelieferten Szenario, und keine davon auf kshana.dev genannt. Die Abdeckung von Karten zu Zeilen steigt von 72 von 168 Zeilen auf 94.

• Acht Szenarien zum Katalog des Playgrounds hinzugefügt. Die Schaltfläche Run einer Fähigkeitskarte erscheint nur, wenn auch web/app.js die Datei enthält; sechs Karten nannten ein Szenario, das sie nicht enthielt, sodass sie ohne Möglichkeit zum Ausführen dargestellt wurden — eine davon, das Datum aus realer Laserentfernungsmessung, war seit ihrer Auslieferung in diesem Zustand. tests/scenario_examples_doc_sync.rs sichert die Invariante jetzt in beiden Hälften: das Ziel run einer Karte muss unter scenarios/ mitgeliefert und vom Katalog angeboten sein. Gegen beide Fehlerarten per Mutation getestet.

• moonlight-service-volume gibt seine Geometrie je Satellit als <scenario>.table.csv aus, wenn ein Exportstandort konfiguriert ist (G11). Es ist das größte Array, das das Crate veröffentlicht — 2304 Zeilen in der veröffentlichten gemeinsamen Tabelle für Kommunikation und Navigation — und es erreichte Verbraucher nur innerhalb von JSON, der Form, die die Kurve mit 57 Punkten eines Schwesterszenarios unter einer Spalte, die alle beanspruchte, auf 23 Punkte gekürzt hat. Eine Zeile je Link, die Zeilenzahl in der Kopfzeile, die Antennenspalten nur vorhanden, wenn eine Antenne konfiguriert war. Ein Lauf ohne Exportstandort ist bytegleich unverändert und schreibt keine Datei.

• Die SBOM beschreibt jetzt, was ausgeliefert wird: aus 60 Komponenten wurden 66. scripts/gen-sbom.sh listete jedes Paket der Auflösung mit Standard-Features auf, einschließlich Dev-Abhängigkeiten. Das setzte sgp4 und chrono — Crates nur für Tests, in keinem Artefakt kompiliert — in die Stückliste und ließ die Kette --features python aus, die das PyPI-Wheel einbindet (pyo3, pyo3-ffi, pyo3-macros, pyo3-macros-backend, pyo3-build-config, portable-atomic, target-lexicon, heck), die die Fremdfunktionsgrenze dieses Wheels ist. Das Skript durchläuft den Auflösungsgraphen jetzt vom Paket kshana aus nur über normale und Build-Kanten, über die Vereinigung der Feature-Mengen Default, python und wasm (das npm-Paket trägt dieselbe SBOM), für jede Zielplattform. Das festgeschriebene CycloneDX-Prüfurteil zur Schemaübereinstimmung wird über seinen festgeschriebenen Generator neu basiert: 60 → 66 Komponenten, 53 → 60 zusammengesetzte Lizenzausdrücke, und weiterhin null Schemafehler, sobald diese in die Standardform expression gebracht sind.

• Die CSV-Reproduzierbarkeitstabelle erreicht jede Eingangstür, nicht nur die CLI und das Python-Wheel. Der MCP-Server erhält ein siebtes Werkzeug, export_table_csv, das ein Szenario ausführt und die byte-stabile Tabelle liefert, die die CLI als <scenario>.table.csv schreibt — oder einen Fehler, der die Arten nennt, die eine veröffentlichen (realtime-frame-eop, lunar-time-budget, lunar-jamming und moonlight-service-volume nur, wenn export_site_lat_deg + export_site_lon_deg gesetzt sind). Das WebAssembly-Modul erhält table_csv, das denselben Text oder undefined liefert. Der MCP-Round-Trip-Test und die Tests der Python-Bindung legen das gelieferte CSV jetzt Byte für Byte gegen tests/golden/realtime-frame-eop.csv fest und legen fest, dass RunOutput.write_csv die geschriebenen Bytes liefert und 0 ohne erzeugte Datei für eine Art ohne Tabelle. Jede Oberfläche, die die Anzahl der MCP-Werkzeuge nennt oder die Werkzeuge auflistet, sagt jetzt sieben.

• run_all im WebAssembly-Modul: ein Engine-Lauf für jede Ausgabe. run, chart_svg, summary und table_csv führen das Szenario jeweils von Grund auf aus, sodass der Playground pro Klick vier vollständige Läufe bezahlte — etwa 12 s statt 3 s für cislunar-arc-recovery in einem Browser. run_all liefert {json, svg, summary, csv} aus einem Lauf, und der Playground verwendet es jetzt. Es stimmt Byte für Byte mit den vier einzelnen Aufrufen überein.

Behoben#

• REVISION: die Gyroskop-Bias-Kopplung des GNSS/INS-Filters hatte das falsche Vorzeichen, und die Ausfallzahlen von gnss-ins ändern sich. Das Extended-Kalman-Filter (EKF) im Fehlerzustand hält beide Trägheits-Bias als Residuen (wahr minus laufende Schätzung, durch Addition zurückgeführt). Die Beschleunigungsmesser-Spalte trieb den Geschwindigkeitsfehler mit +C_b^n b_a, aber die Gyroskop-Spalte trieb den Lagefehler mit −C_b^n b_g. Ein Rest-Gyroskop-Bias dreht die berechnete Lage tatsächlich um +C_b^n b_g, sodass jede Schätzung des Gyroskop-Bias in die falsche Richtung schob. Das Paket blieb nur stabil, weil sein Standard-Prior für den Gyroskop-Bias (1e-4 rad/s, 1-Sigma) eng genug war, um diese Zustände festzuhalten. Mit einem weiteren Prior divergierte das Filter, selbst wenn der wahre Gyroskop-Bias null war: aus 93 m fusioniertem Ausfallfehler wurden 4,3 km. Die veröffentlichten Zahlen für scenarios/gnss-ins.toml ändern sich wie folgt:

  gnss-ins.toml	vorher (≤ 0.27.2)	nachher
  Kaltatom-IMU, fusionierter Ausfall-RMS	96,1 m	1,9 m
  Kaltatom-IMU, Koppeln innerhalb der Spezifikation (50 m)	30 s	60 s (der ganze Ausfall)
  taktische IMU, fusionierter Ausfall-RMS	62,5 m	3,1 m
  taktische IMU, Koppeln innerhalb der Spezifikation (50 m)	37 s	60 s (der ganze Ausfall)

  Die Zahlen im freien Lauf (130,7 m und 314,3 m) ändern sich nicht; sie nutzten das Filter nie. Die frühere Lesart des Pakets, dass das fusionierte Koppeln durch eine Lageuntergrenze bei der Übergabe begrenzt ist und sich daher mit einem besseren Sensor nicht verbessert, war ein Artefakt dieses Fehlers und wird zurückgezogen. Bei konstanten, rauschfreien Bias lernt das Filter sie jetzt, solange GNSS verfügbar ist, sodass das fusionierte Koppeln ein bester Fall ist. Die externe Referenz filterpy (tests/gnss_ins_sensor_fusion_reference.rs) prüft nur die Messaktualisierungen, weshalb sie die Propagation nie sah. Zwei Tests prüfen das Vorzeichen jetzt direkt, und beide scheitern am alten. Der erste in closed_loop.rs speist einen bekannten Rest-Gyroskop-Bias durch das Strapdown ein und verlangt, dass das Filter den resultierenden Lagefehler auf 2 % genau vorhersagt. Der zweite verlangt, dass ein weiter Prior einen Gyroskop-Bias von 1e-3 rad/s lernt und innerhalb von 6 m bleibt. Der plattformübergreifende Golden-Wert von gnss-ins wird aus diesem Grund und keinem anderen neu festgeschrieben.

• Jede Kurzanleitung der Registries läuft jetzt wie geschrieben auf einer sauberen Maschine. Vor dieser Änderung gemessen, lasen die Beispiele für crates.io und PyPI (Python Package Index) scenarios/clock-holdover.toml, das eine Registry-Installation nicht hat, und das npm-Beispiel stürzte unter Node.js mit TypeError: fetch failed ab, weil das init() des Pakets seine WebAssembly-Binärdatei per Abruf lädt und das fetch von Node keine lokale Datei lesen kann. Jetzt:

  • README.crates.md und README.pypi.md tragen dieses Szenario inline, wie es README.npm.md schon tat. Der Rust-Codeblock ist ein ganzes Programm mit eigenem main, weil die von rustdoc verborgene Zeile # Ok::<…>, mit der er endete, auf crates.io angezeigt wird und beim Einfügen nicht kompiliert. tests/readme_code_fences_doc_sync.rs kompiliert ihn weiterhin Byte für Byte und lehnt jetzt außerdem eine verborgene Zeile im Codeblock ab.
  • README.npm.md trennt den Browser von Node.js und gibt ein Node-Rezept, das die Binärdatei von der Festplatte liest und an initSync übergibt. Der Doc-Sync-Test akzeptiert initSync als den Loader, den wasm-bindgen erzeugt.
  • Alle drei betten das Szenario mit ungekürzten Herkunftszeichenfolgen ein, sodass der Szenario-Hash auf jeder Oberfläche 5ba83a232b94 ist. Das npm-Beispiel kürzte sie früher, was ihm einen anderen Hash als der CLI gab.
  • Aus lokalen Builds dieses Baums reproduziert: ein frisches Projekt mit cargo new und einer Pfadabhängigkeit auf das gepackte Crate baute und führte das Rust-Beispiel aus; ein mit maturin aus den gepackten Quellen gebautes Wheel, in eine neue virtuelle Umgebung installiert, führte das Python-Beispiel aus; und das Paket wasm-pack --target web, gepackt und mit npm installiert, führte das Node-Rezept aus. Alle drei gaben dieselbe Zusammenfassungszeile aus.

• cargo run -- <scenario.toml> funktioniert aus einem Clone. Cargo.toml setzt default-run = "kshana". Ohne das lehnte cargo mit "could not determine which binary to run" ab, was jede Zeile cargo run -- in der Dokumentation traf.

• Die Fehlermeldungen der CLI in der ersten Minute sagen, was als Nächstes zu tun ist. Ein nicht vorhandener Szenariopfad fügt jetzt einen Hinweis auf kshana example hinzu, und ein zweites Positionsargument gibt auch den Verwendungstext aus, statt nur das Argument zu nennen. --help, --version, der Fehler bei einer unbekannten Option (Exit-Code 2) und die einzeilige Meldung ok: von --validate bei Erfolg waren bereits in main. tests/cli_first_run.rs deckt jetzt alle ab, da zuvor kein Test die Binärdatei für eines davon ausführte.

• list_kinds() in Python ist als Rückgabe einer JSON-Zeichenfolge dokumentiert, nicht einer Liste. Es liefert dieselben Metadaten wie scenario_kinds(), serialisiert, sodass das Iterieren Zeichen durchläuft. Es behält seine Rückgabe als Zeichenfolge, damit bestehende Aufrufer nicht brechen. kshana.pyi, der Doc-Kommentar der Bindung, docs/PYTHON_API.md und README.pypi.md sagen das jetzt und verweisen auf scenario_kinds().

• Die drei Registry-READMEs schreiben jede Abkürzung bei der ersten Verwendung aus. PNT ist jetzt im Slogan ausgeschrieben, wo es zuerst vorkommt, und CLI, TOML, JSON, SVG, CSV, CSAC, HTML, URL und API sind in den Dateien ausgeschrieben, die sie verwenden. Die Überschrift der Tabelle zur unabhängigen Referenz sagt nicht mehr "CI-gated", bevor CI definiert ist.

• Eine veröffentlichte Zahl korrigiert: die ARAIM-Verfügbarkeit mit zwei Konstellationen auf den mitgelieferten GPS- + Galileo-TLEs von Celestrak. docs/CAPABILITY.md gab an, dass das Hinzunehmen von Galileo die Verfügbarkeit bei einem VAL von 12 m von 0,21 auf 0,67 hebt und dass der gegen Konstellationsfehler robuste Modus mit nur zwei Konstellationen begrenzt ist. Das kam daher, dass tests/araim_dual_real_data.rs jeden Satelliten von seiner eigenen TLE-Epoche aus propagierte (parse_propagators lässt die Epoche weg) und die Epochen in diesen Dateien 70,6 h (GPS) und 335,7 h (Galileo) überspannen, sodass die Satelliten zu untereinander unstimmigen Zeiten standen. Der Test behält jetzt jede Epoche (parse_tle) und wertet jeden Satelliten zu einem gemeinsamen UTC-Zeitpunkt aus, der letzten TLE-Epoche im Satz (2026-06-07T07:21:04). Die gemessene Verfügbarkeit über dasselbe Gitter von 24 h mit 289 Stichproben wird zu nur GPS 0,993 (war 0,208), gepoolt 1,000 (war 0,671) und gegen Konstellationsfehler robust mit zwei Konstellationen 0,990 (war 0,031); an der Grenze APV-I geht der Modus mit zwei Konstellationen von 0,180 auf 1,000. Die Schlussfolgerung kehrt sich um: an einem konsistenten Himmel tragen zwei Konstellationen die Konstellationsfehler-Hypothese bei einem VAL von 12 m. Dieselben Zahlen ergeben sich mit der frühesten TLE-Epoche als Referenz. Eine Selbstprüfung im Test legt seine Verfügbarkeitsschleife Stichprobe für Stichprobe auf araim_dual_constellation_availability fest, sodass der einzige Unterschied die Zeitausrichtung ist. docs/CAPABILITY.md und docs/REAL_TLE_GUIDE.md §3 tragen die neuen Zahlen; der Eintrag 0.13.0 unten bleibt wie veröffentlicht.

• Die öffentlichen Oberflächen bewerben RINEX 4 nicht mehr als validiert. Die Engine lehnt eine RINEX-4-Navigationsdatei jetzt namentlich ab, statt sie falsch zu dekodieren, aber das Standardsraster zeigte weiterhin eine Karte "RINEX 3 / 4" mit einem Etikett validiert, gebunden an die RINEX-3-Belege des Navigationsparsers. Die Karte heißt jetzt "RINEX 3", und die README, docs/CAPABILITY.md, docs/STANDARDS.md, ROADMAP.md und die Zusammenfassung der Fähigkeiten sagen, was zutrifft: RINEX-3.0x-Beobachtungsdateien werden geparst, das Beobachtungslayout 4,00 soll es ebenfalls, aber es wurde noch keine Datei 4,00 durch den Code gelesen, und RINEX-4-Navigationsdateien werden abgelehnt.

• --validate sagt, wann "ok" bedeutet, dass nichts zu prüfen war. Etwa zwei Drittel des Katalogs veröffentlichen kein Pflichtfeld — diese Pakete führen ihre Referenzkonfiguration aus einem leeren Rumpf aus —, sodass die Prüfung für sie nur "ok" ausgeben konnte, mit denselben Worten wie nach der Prüfung von sechs Feldern. Die Erfolgszeile nennt jetzt die Zahl der als vorhanden gefundenen Pflichtfelder oder dass die Art keine verlangt.

• scripts/gate.sh lehnt ein nichtnumerisches REPEAT oder TEST_THREADS ab. Unter bash 3,2 ließ REPEAT=no den numerischen Vergleich mit einem Fehler enden und falsch auswerten, sodass das Gate "repeatability loop SKIPPED (REPEAT=0)" für einen Wert meldete, der nicht 0 war, und trotzdem eine Quittung schrieb. Beide Stellschrauben beenden jetzt mit Exit-Code 2, sofern sie keine einfachen ganzen Zahlen sind.

• Die MSRV wird überall, wo ein Mensch sie liest, als 1,85 angegeben. Cargo.toml wechselte in der letzten Version auf 1,85; das README-Badge, der Installations- und Fehlerbehebungstext, codemeta.json und die eigene Begründung des MCP-Crates sagten noch 1,75.

• RunOutput.__repr__ in der Python-Bindung meldet Bytes, nicht "chars". Es gab len() von UTF-8-Zeichenfolgen aus, was eine Bytezahl ist: 710 "chars" für eine Tabelle mit 708 Zeichen.

• Die README dokumentiert --study --study-name nicht mehr zusammen. --study-name ist ein Schalter für ein einzelnes Szenario und wird mit --study ignoriert (die Binärdatei warnt). Die zwei Copy-Paste-Beispiele in README.md und README.crates.md zeigen jetzt den Studienbefehl allein.

• Der Evidenzabschnitt der Website zur Uhrenstabilität nennt beide beobachteten Toleranzen. Die Serie 5071A Caesium wird bis ≤ 3e-5 reproduziert und PHASE.DAT bis ≤ 5e-5; der Absatz nannte 3e-5 für beide.

• Zwei Ausgabedateien der Engine werden nicht mehr nachverfolgt. scenarios/quantum-pnt-demonstrator.study.{json,html} wurden von Engine 0.20.0 mit jeder leeren Kennzahl erzeugt, und der eigene Studienbefehl der README überschrieb sie, was den Baum verschmutzte und das Push-Gate blockierte. *.study.json / *.study.html werden jetzt wie die anderen vier Engine-Ausgaben ignoriert.

• Ein Seed-Sweep im Playground scheitert nicht mehr bei jedem Lauf. Der Sweep durchlief den ganzzahligen Regler seed linear (1, 10,9, 20,8, …), und die Engine, die ihn als u64 las, lehnte jeden gebrochenen Wert ab. Ganzzahlige Regler durchlaufen jetzt verschiedene ganze Zahlen.

• Jeder Download aus dem Playground nennt, welche Engine und welche Eingabe ihn erzeugt hat. Einige Arten (z. B. realtime-frame-eop) geben weder engine_version noch scenario_hash aus, sodass ihre Downloads schlicht kshana-csv.csv hießen. Der Name greift jetzt auf die Version der geladenen Engine und einen 12-stelligen hexadezimalen FNV-1a-64-Fingerabdruck des Szenariotexts zurück.

Geändert#

• Das veröffentlichte Crate ist weniger als halb so groß wie zuvor, und cargo install kshana baut nur die CLI. Das Paket enthielt früher die Veröffentlichungen, ihre Einreichungspakete, die Artefakte der Abbildungen, die Notebooks, docs/, die Wartungsskripte und die Beispielprogramme. Nichts davon wird von der Bibliothek oder der CLI kompiliert. Es enthielt auch die drei internen Generatoren unter src/bin/ (crossover_study, gen_validation_artifacts, validation_report), sodass eine Registry-Installation vier ausführbare Dateien kompilierte und installierte, von denen drei nur innerhalb eines Checkouts nützlich sind. Diese Bäume und die drei Generatorquellen sind jetzt ausgeschlossen. Cargo listet die Binärdateien eines Pakets aus den Dateien auf, die es enthält, sodass das veröffentlichte Manifest nur kshana nennt. In einem Clone werden die Generatoren weiterhin automatisch gefunden, sodass cargo run --bin <name> und der Release-Job, der validation_report ausführt, unverändert sind. Gemessen mit cargo package: 763 Dateien, 16,7 MiB, 6,8 MiB komprimiert vorher; 591 Dateien, 10,5 MiB, 3,0 MiB komprimiert nachher. Sein Verifikations-Build, der nur die gepackten Dateien kompiliert, besteht. cargo install --path auf dem gepackten Crate installierte eine ausführbare Datei, kshana.

• Ausgabe, die ein Zeitgebungsingenieur lesen kann: kein p95 0.0ns mehr, kein security 0.000 mehr ohne Angriff und Zahlen der Standorte, die zu den READMEs passen. Das ist eine Revision der Anzeige. Keine veröffentlichte Zahl ändert sich; die JSON-Werte sind identisch, was die Golden-Hashes oben belegen.

  • Die einzeilige Zusammenfassung gab den Zeitfehler im 95. Perzentil (p95) der optischen Uhr als 0.0ns aus, während die Tabelle daneben 1.20e-4 ns zeigte. Eine Zeitzahl ungleich null, die für eine Dezimalstelle zu klein ist, wird jetzt mit drei signifikanten Stellen ausgegeben (p95 1.20e-4ns); eine exakte Null wird weiterhin als 0.0 ausgegeben. Der HTML-Bericht (HyperText Markup Language), die Vergleichstabelle der Studie und der herunterladbare Bericht des Playgrounds verwenden dieselbe Regel, sodass auch keine Zahl ungleich null als 0.000 ausgegeben wird.
  • security ist eine analytische Schranke der Erkennbarkeit von Spoofing, die nur gegenüber einem konfigurierten Angriff etwas bedeutet. Die Arten clock, orbit, hybrid und fusion konfigurieren keinen, sodass ihre Zusammenfassung jetzt security n/a (no attack) ausgibt statt einer Zahl wie 0.000, die wie eine verfehlte Erkennung gelesen wird. Der Wert bleibt in fom.security, gekennzeichnet mit applicable: false und dem Grund in figure_tiers, und die Berichtstabellen zeigen "not applicable". Die Art spoof bewertet die Erkennung weiterhin.
  • Zwei Festschreibungen der Zusammenfassung in tests/registry_golden.rs verschoben sich aus genau diesen zwei Gründen und keinem anderen: golden_clock (das Quanten-p95 und beide Werte security) und golden_orbit (beide Werte security; seine p95-Werte sind genau null). Ihre Hashes des ganzen Dokuments verschoben sich nicht. Die erwarteten Zusammenfassungen in der README, den drei Tutorials und ihren Lehrszenarien sind entsprechend aktualisiert, und tests/tutorials.rs prüft die Lehrkopien gegen die Engine.
  • Die geführte Tour des Playgrounds öffnet sich beim ersten Laden nicht mehr. Ihr Modal fing die ersten Klicks ab, und ihr Spotlight scrollte die Seite von dort weg, wo der Besucher gelandet war. Sie startet über die Schaltfläche "Take the 60-second tour" oder die schwebende Schaltfläche Tour.
  • Die Seite scrollt auf einem Telefon nicht mehr seitwärts. Bei 390 px kamen die Markenzeile und die GitHub-Schaltfläche auf etwa 410 px Inhalt, ein Überlauf von 4 px; die Kopfzeile passt jetzt ab 320 px aufwärts, und die Tabelle der Kennzahlen scrollt in ihrem eigenen Feld, statt die Seite zu verbreitern.
  • Der Fähigkeitsexplorer führte mit seiner eigenen Kartenzahl ("46 capability cards … 17 backed by an external oracle") neben READMEs, die 64 von 168 sagen. Er führt jetzt mit der Verifikationsmatrix, gelesen aus der erzeugten web/data/verification-matrix.json (derselben Matrix, an die die Zahlen der README festgeschrieben sind), und nennt die Karten danach als die Zusammenfassungsschicht, die sie sind. web/counts.test.mjs, ein neuer Schritt im Workflow der kontinuierlichen Integration (CI), prüft die Arithmetik und gleicht README.md und die Beschreibungen der Seite gegeneinander ab; tests/web_validation_counts_doc_sync.rs legt die Verdrahtung von der Rust-Seite fest.

• Die öffentliche Beschreibung führt jetzt mit Zeitgebung und Holdover, der am besten validierten Domäne. Der Anfang der README und docs/POSITIONING.md stellen Kshana als offene, reproduzierbare, nach Herkunft gekennzeichnete Evidenz-Engine für PNT-Resilienz dar: Zeitgebung und Holdover kritischer Infrastruktur zuerst (die Schätzer für Allan, modifizierte Allan, Zeitabweichung und maximalen Zeitintervallfehler sowie die Inversion der Koppelvarianz im Holdover sind die Zeilen VALIDATED dahinter), Quanten als neutrale Methode zum Abwägen Quanten gegenüber klassisch, deren Ergebnisse MODELLED gekennzeichnet sind, und lunare / cislunare sowie Deep-Space-Navigation als gepflegte Fähigkeiten statt als Schlagzeile. Beide Seiten sagen jetzt, was Kshana nicht ist -- kein Hochfrequenz-Signalsimulator und kein Hardware-in-the-Loop-Aufbau, kein Ersatz für MATLAB/Simulink, STK oder Orekit -- und verweisen auf die neue Art telecom-timing und auf docs/TELECOM-TIMING.md. Die alte Zeile "Es gibt kein gutes offenes Werkzeug" ist entfernt: Eine Suche, die nichts findet, ist kein Beleg dafür, dass nichts existiert. ROADMAP.md erhält eine undatierte Prioritätsreihenfolge (zuerst Zeitgebung, an zweiter Stelle die Quantenabwägung, Mond gepflegt) und verliert drei veraltete Punkte (Coriolis- und Lichtverschiebungs-Systematiken, die NRHO-Anfangsbedingungen und das Mondszenario, alle ausgeliefert); die Zeile der README "Coriolis und Lichtverschiebung bleiben Roadmap" wird auf dieselbe Weise korrigiert.

• docs/CAPABILITY.md untertreibt nicht mehr. Die Zeile zu erdfesten Bezugssystemen sagte "none", während die Matrix GCRS→ITRS mit VALIDATED einstuft; sie sagt jetzt "full", und die Zeile zu den Kernbezugssystemen verzeichnet die Gegenprüfung mit ANISE als geliefert. Der geführte Modus war als Fahrplan aufgeführt; der Playground hat geführte Schieberegler und eine geführte Tour ausgeliefert. Ein Abgleich mit src/verification.rs korrigierte fünf weitere Zeilen, die ihren Validierungen vorausgingen: das Cowell-Kräftemodell und die Batch-/sequentielle Bahnbestimmung gegenüber Orekit 12,2, Bodenstationsüberflüge gegenüber dem Elevationsdetektor von Orekit, den DOP-Kern gegenüber gnss_lib_py und den OEM-Import gegenüber dem unabhängigen Parser oem; die Zeile zu Verifikation und Validierung nennt jetzt die Schutzvorrichtungen, die prüfen, dass jeder zitierte Test existiert.

• Das Glossar erklärt, was eine Ergebnisdatei sagt. docs/GLOSSARY.md erhält Einträge in einfacher Sprache für die Ausgabebegriffe (Holdover, p95, Integrität, den Sicherheitswert, PDOP, sigma_y, q_wf), die Begriffe der Telekom-Zeitgebung (Zeitfehler, max|TE|, cTE, dTE, MTIE, TDEV, PRTC, ePRTC, T-BC, T-TSC, OCXO, CSAC) und die drei Evidenzstufen (VALIDATED, MODELLED, PARTNER).

• Abkürzungen werden bei der ersten Verwendung in jedem von Hand geschriebenen öffentlichen Dokument ausgeschrieben. Die README und 24 Dateien unter docs/ hatten mehrere hundert Abkürzungen, die vor oder ohne ihre Erläuterung verwendet wurden; jede ist jetzt dort ausgeschrieben, wo sie in der Datei zuerst erscheint. Die drei erzeugten Dateien (docs/VERIFICATION-MATRIX.md, docs/MODELLED-RATIONALE.md, docs/SCENARIOS.md) bleiben unberührt: sie werden aus src/verification.rs und api::list_scenario_kinds() geschrieben, ihr Wortlaut muss sich also an der Quelle ändern.

• Die Zeilenabdeckung hat eine maßgebliche Messung. docs/COVERAGE.md verzeichnet 95,63 % (37.697 von 39.419 Zeilen) aus dem CI-Job coverage bei b1d350d, und tests/coverage_figure_doc_sync.rs legt die fünf öffentlichen Oberflächen mit "~96%" darauf fest — die eine Schlagzeilenzahl, die von Hand gepflegt wurde und sich schon einmal unbemerkt verschoben hatte.

• Neue Doc-Sync-Gates für Oberflächen, die niemand las. tests/readme_code_fences_doc_sync.rs prüft jedes import { … } from "kshana" in einem JavaScript-Codeblock gegen die WebAssembly-Exporte und legt das Rust-Beispiel in README.crates.md Byte für Byte auf eine Kopie fest, die die Testbinärdatei kompiliert. tests/security_md_doc_sync.rs schlägt fehl, wenn src/lib.rs das #![forbid(unsafe_code)] verliert oder SECURITY.md es nicht mehr nennt. tests/no_overclaims.rs durchsucht jetzt auch web/README.md und die drei Registry-READMEs, und jeder Standard auf der Website muss sein proof ausdrücklich angeben.

• Die zwei Uhrenprüfungen an realer Hardware laufen auf einem Runner. realdata-clock.yml (monatlich und auf Anforderung) ruft die Serien 5071A und PHASE.DAT ab und führt beide Tests mit KSHANA_REQUIRE_REALDATA=1 aus, sodass eine fehlende Eingabe scheitert, statt übersprungen zu werden. Beide Abrufskripte sind auf einen allantools-Commit festgelegt und prüfen SHA-256.

• Der Python-Typ-Stub wird gegen das gebaute Wheel geprüft (mypy.stubtest im Bindungs-Job), wodurch csv/write_csv ohne Stub ausgeliefert wurde.

• Das Glossar definiert URE, EOP, FoM, CTI und TIB, die die README und das Register nackt verwendeten.

• Der veröffentlichte Feldvertrag jeder Art ist jetzt wahr, und ein Test hält ihn dort. Fünf der 61 Arten änderten sich. Arten mit nicht leerem required_fields gehen von 21 auf 22: ephemeris verlangt jetzt tle|orbit+epoch (ein nacktes kind = "ephemeris" bestand früher --validate und ließ dann den Lauf scheitern), und quantum-trade fügt candidate_adev_taus+candidate_adev_values|candidate_clock_class hinzu, was sein Lauf bereits verlangte. Ein verlangter Eintrag darf | (eines davon) und + (alle zusammen) verwenden; --validate versteht beides. lunar-joint-od-clock, pvt und earth-gnss-lunar veröffentlichen 9 echte optionale Felder, die sie ausgelassen hatten. docs/SCENARIOS.md sagt jetzt, dass kind für jede Art außer clock verlangt wird. tests/required_fields_are_true.rs prüft jede Art gegen ihr ausgeliefertes Szenario: das Entfernen jedes verlangten Eintrags muss den Lauf scheitern lassen, und ein Dokument, das nur die verlangten Felder enthält, muss laufen.

• Die Hinweise im JetBrains Marketplace sind abgesichert. scripts/check-version-sync.sh scheitert jetzt, sofern nicht der neueste Eintrag <change-notes> in plugin.xml die auszuliefernde Version nennt; sieben veröffentlichte Versionen hatten die Hinweise von 0.22.0 unverändert ausgeliefert.

• Die Abdeckungszahl des technischen Berichts ist die gemessene. paper/kshana-technical-report.md sagte "near 97 %"; er sagt jetzt nahe 96 % (95,63 % gemessen, docs/COVERAGE.md) und ist die sechste Oberfläche, die der Abdeckungstest festlegt.

• Der Engine-Client außerhalb des Hauptthreads wird getestet (web/engine.test.mjs, in CI): Dispatch-Allowlist, Abbruch und Neustart, die drei Ausweichrouten im Hauptthread und Absturzwiederherstellung, gegen einen falschen Worker.

• Nichts wird veröffentlicht, bis der getaggte Commit seine Tests bestanden hat, und eine Version ist nicht fertig, bis jede Registry sie ausliefert. Die Reihenfolge ist jetzt Tag, Verifikation, Veröffentlichung, Parität, Website, in einem Lauf von release.yml (docs/RELEASING.md).

  • Die Veröffentlichung wartet auf das Urteil. publish.yml, mcp-publish.yml und jetbrains-plugin.yml starten nicht mehr beim Push des Tags; release.yml ruft sie aus Jobs auf, die needs: verify haben. Zuvor liefen sie ihm davon: bei v0.27.2 hatten crates.io, npm und der Python Package Index (PyPI) alle innerhalb von 4,5 Minuten nach dem Tag veröffentlicht, und verify kam 84 Minuten danach zurück; bei v0.27.0 veröffentlichten npm und PyPI, während der Job für crates.io scheiterte. Ein manueller Wiederholungsversuch auf einem Tag wird vom neuen scripts/check-release-verdict.sh angehalten, das ein grünes verify für genau diesen Commit aus der Actions-Oberfläche verlangt und bei allem anderen geschlossen scheitert.
  • Alles wird gebaut, bevor irgendetwas hochgeladen wird, und crates.io, dessen Paketierungsschritt der war, der mitten in der Veröffentlichung scheiterte, veröffentlicht zuerst.
  • Ein fehlendes Registry-Token lässt den Job scheitern, statt den Upload zu überspringen und Erfolg zu melden.
  • Eine Paritätsprüfung nach der Veröffentlichung. scripts/check_channel_parity.py fragt crates.io (kshana und kshana-mcp), npm, PyPI (die Quelldistribution und alle sechs Plattform-Wheels) und ghcr.io ab, bis jede die Version ausliefert, oder lässt den Lauf scheitern; docs.rs und die Registry des Model Context Protocol (MCP) werden gemeldet, sind aber nicht erforderlich. Auf vergangene Versionen angewandt, findet es 0.22.0 bei npm und PyPI fehlend, 0.23.0 bei PyPI und 0.27.0 bei crates.io.
  • Vorgebaute Befehlszeilen-Binärdateien für macOS (Apple Silicon und Intel) und Windows x86-64, benannt nach Ziel (kshana-aarch64-apple-darwin und so weiter), neben dem Linux-kshana, dessen Name unverändert ist. Eine Datei SHA256SUMS deckt jedes Asset ab, und verify-release prüft sie und führt die macOS- und Windows-Binärdateien auf ihren eigenen Systemen aus.
  • kshana.dev zeigt eine Version, nicht main. Es wurde früher bei jedem Push auf main neu bereitgestellt, während seine Seiten die letzte Version nannten. pages.yml baut jetzt nur einen Release-Tag: die Version stößt es an, sobald jeder Kanal die Version ausliefert, und ein manueller Aufruf stellt die neueste Version (oder eine benannte) neu bereit.
  • Eine Quelle für Wheels. Die von Hand kopierte Matrix mit sechs Zielen in publish.yml ist weg; es ruft wheels.yml auf, sodass das Tag-Gate von auditwheel und die Prüfung der Byte-Reproduzierbarkeit jetzt die Wheels bewerten, die PyPI erhält, und ein Fehler in einem von beiden die Version stoppt.
  • Festgelegte Build-Werkzeuge. Jeder Workflow fordert Rust 1.93.0 an (der Job msrv seine eigene Version); publish.yml und pages.yml hatten @stable angefordert, und das Protokoll von v0.27.2 zeigt, dass rustup 1.98.1 installierte und dann nur deshalb mit 1.93.0 kompilierte, weil rust-toolchain.toml Vorrang hat. wasm-pack ist auf 0.13.1 festgelegt (die Version, die v0.27.2 baute und die das nicht festgelegte Installationsskript wählte), mit einer Prüfsummenprüfung, und mcp-publisher auf 1.8.1 mit seinem veröffentlichten SHA-256. scripts/check-toolchain.sh scheitert jetzt, wenn ein Workflow einen anderen Compiler anfordert oder ein heruntergeladenes Skript in eine Shell leitet. Kein Verifikationsjob, keine Golden-Festschreibung und kein lokales Gate-Skript wurde entfernt oder gelockert.

Sicherheit#

• Jede GitHub Action eines Drittanbieters ist per Commit-SHA festgelegt — 93 Verweise in 15 Workflows, 92 davon neu —, wobei der Tag als nachgestellter Kommentar bleibt, damit Dependabot ihn aktualisiert. Die Ausnahme ist dtolnay/rust-toolchain, dessen Tag der Toolchain-Wähler ist.

• Die Basisschichten des Images des MCP-Servers sind per Multi-Arch-Digest festgelegt, und Dependabot beobachtet jetzt das Dockerfile von mcp/kshana-mcp, sodass die OS-Schichten weiterhin Sicherheitsupdates erhalten — über einen geprüften PR.

• Die Prüfung Tag gegen Manifest läuft in den zwei Veröffentlichungs-Workflows, die die Version des Tags ausliefern. mcp-publish.yml (ghcr-Image, MCP-Registry) und jetbrains-plugin.yml (Marketplace) laufen publish.yml davon, statt auf es zu warten, sodass ein falsch geschnittener Tag nur in einem Geschwister abgesichert war. Beide führen jetzt vor dem Bauen scripts/check-version-sync.sh aus.

• Vier Advisories, die Dependabot an dem Tag meldete, an dem seine Alarme eingeschaltet wurden, sind behoben. Der MCP-Server wechselt von rmcp 1,7 auf 2,2: drei Advisories gegen rmcp < 2,1 (ein Leck in der Sitzungstabelle bei Streamable HTTP, fehlende OAuth-Validierung geschützter Ressourcen, benutzerdefinierte Header, die einer herkunftsübergreifenden Weiterleitung folgen) — hier keines erreichbar, da der Server nur stdio spricht, aber ein veröffentlichtes Crate sollte kein verwundbares SDK festlegen. Die Makros von rmcp 2 brauchen Rust 1,88, daher deklariert jetzt kshana-mcp allein rust-version = "1.88"; die Bibliothek kshana bleibt bei 1,85. Die eine API-Änderung (Content → ContentBlock) ist angewandt, und die Round-Trip-Tests bestehen. Die SonarQube-Scan-Action wechselt von v5 auf v6, was ein Advisory zur Argument-Injektion behebt (≥ 4,0, < 6,0).

0.27.2 - 2026-09-22#

Hinzugefügt#

• Jedes Rust-Element, das eine Zeile der Verifikationsmatrix zitiert, wird jetzt gegen das Crate aufgelöst. Die bestehende Schutzvorrichtung prüfte die Zitate in Form von Dateipfaden; 63 der 164 Nicht-Partner-Zeilen nennen ihre Evidenz stattdessen als Element im Crate — navsignal::code_tests, integrity::tpl_scalar::tests, api::tests::tracking_loop_kind_round_trips_through_the_dispatch — und ein Token ohne Endung .rs war für einen Pfad-Scanner unsichtbar. Diese Zeilen hätten ein umbenanntes Modul, ein geleertes Testmodul oder eine nie existierende Funktion nennen können, und jedes Gate wäre grün geblieben.

  tests/verification_rows_name_a_test_that_exists.rs löst alle 339 solchen Zitate durch den Modulbaum auf, verlangt, dass jede Nicht-Partner-Zeile mindestens einen Test nennt, der tatsächlich #[test] trägt, und verlangt, dass Partner-Zeilen keinen nennen. Vier Mutationen dienten zu seiner Bewertung: ein zitiertes Modul umbenennen, das einzige Testzitat einer Zeile auf eine Nicht-Test-Funktion richten, das echte mod tests umbenennen und die Attribute #[test] davon entfernen — jede färbt die Zusicherung rot, die dafür zuständig ist.

  Eine Zeile war bereits falsch: Alternative / complementary PNT zitierte tests/*, ein Glob, was kein Zitat ist. Sie nennt jetzt tests/alternative_complementary_pnt_reference.rs und die drei Testmodule im Crate dahinter.

• Die veröffentlichten Abbildungen werden bei jedem Build gegen die Engine neu geprüft (tests/published_figures_still_reproduce.rs). Die drei Demo-Diagramme der README sind die eigene Ausgabe chart.svg der Engine, und nichts führte das Szenario erneut aus; die zwei Crossover-Studien der Veröffentlichung wurden einmal erzeugt und festgeschrieben; und die README nennt vier Kennzahlen in Prosa neben scenario-fom.png. Alle drei sind jetzt auf die Live-Ausgabe der Engine festgelegt.

  Der Abgleich brachte das nützliche Ergebnis hervor: die Demo-Diagramme waren bei Engine 0.22.0 gezeichnet worden und das Crossover-JSON der Veröffentlichung bei 0.20.0, und bei 0.27.1 ist jeder gezeichnete Wert in allen fünf Artefakten identisch — die drei Diagramm-SVGs unterscheiden sich von einem frischen Lauf um genau zwei Zeichen je Datei, den Versionsstempel in der Fußzeile. Die Diagramme wurden neu gerendert, damit die Fußzeile stimmt. Das JSON der Veröffentlichung bleibt absichtlich mit 0.20.0 gestempelt: es ist die Aufzeichnung des Laufs, dessen Abbildung eine veröffentlichte Arbeit einbettet, und ein neuer Stempel würde eine Herkunft behaupten, die das PDF nicht hat. Die Schutzvorrichtung prüft stattdessen die stärkere Eigenschaft — dass die aktuelle Engine jeden veröffentlichten Wert weiterhin reproduziert.

Behoben#

• SonarCloud-Analysen wurden als VERSION=not provided aufgezeichnet, sodass der Zeitraum previous_version für neuen Code nie voranschritt: er war weiterhin an der Analyse vom 2026-07-02 verankert, bewertete zweiundachtzig Tage Arbeit als einzelnes Delta und maß 7877 "neue" duplizierte Zeilen gegen eine Schwelle von 3 %. Der Scan übergibt jetzt die Version des Crates. Die zugrunde liegende Duplikation ist real und wird dadurch nicht verborgen: sie konzentriert sich in den deklarativen Registries FieldUnit, die über ensemble, hybrid, fusion, inertial und report wiederholt werden, und in der Verifikationstabelle mit 168 Zeilen, und sie wird hier als Arbeit benannt, statt von der Messung ausgeschlossen zu werden.

• scripts/gate.sh hatte keine Sperre für einen einzigen Schreiber, und jeder Lauf schrieb dasselbe Protokoll. Das ist keine Ordnungsfrage: integration_binaries, tests_passed und tests_ignored der Quittung werden AUS diesem Protokoll zurückgelesen, und der Pre-Push-Hook vertraut der Quittung. Ein Gate, das beendet wurde, dessen Testbinärdatei aber noch lebte, schrieb weiter in die Datei, die der nächste Lauf gerade gekürzt hatte — sodass die Zahlen eines Laufs als die eines anderen bescheinigt werden konnten und einen Push auf Grundlage einer Suite genehmigten, die auf dem gepushten Baum nie lief. Es gibt jetzt ein Gate je Checkout (es lehnt mit Exit-Code 75 neben einem lebenden ab und räumt eine veraltete Sperre, deren pid verschwunden ist) und ein Protokoll je Lauf, wobei target/gate-run.log beim Beenden vom abschließenden Lauf aufgefrischt wird. Beide Richtungen sind getestet: eine lebende pid lehnt ab, eine tote wird geräumt.

• src/verification.rs behauptete, seine Tests bewiesen "do not prove the named test/oracle strings resolve to live code". Zwei Schutzvorrichtungen tun jetzt genau das, sodass die Moduldokumentation das Gegenteil der Wahrheit sagte; sie sagt jetzt, was maschinell geprüft wird und was dem menschlichen Urteil überlassen bleibt. Ein veralteter Verweis auf verification::gen — das Modul heißt artifacts — wird in der eigenen Dokumentation der Geschwister-Schutzvorrichtung korrigiert.

Geändert#

• main wurde am 2026-09-22 neu geschrieben und per Force-Push übertragen. Aus zehn Commits wurden vier. Das Umschreiben faltete jeden Commit, der ein Gate rot zurückließ, in den Commit, der es klärte, sodass jeder Commit auf main jetzt einen Baum hat, der besteht, und entfernte die abgebrochenen Läufe, die eine branchweite Concurrency-Gruppe auf jedem überholten Commit hinterlassen hatte.

  Nichts wurde verworfen. Die Commits vor dem Umschreiben bleiben über die Tags erreichbar, die auf sie zeigen, und der endgültige Baum ist bytegleich mit dem Baum, von dem das Umschreiben ausging — git diff zwischen der alten und der neuen Spitze ist leer bis auf die drei Workflow-Dateien, die diese Version ändert.

  Die abgelösten SHAs, für alle, die einen Verweis auf einen halten:

  alt	Betreff
  9733177	docs(changelog): die Umschreibung der Autorenschaft und die zwei hängenden crate-sha1 offenlegen
  5d16ea8	fix(docs): das Diagramm des Engine-Ablaufs nannte 6 Kennzahlen; die Engine bewertet 7
  148d31d	fix(test): zwei weitere plattformübergreifende Festschreibungen und zwei falsche Annahmen von mir
  a3a2667	feat(web): den lunaren Cluster auf der Website sichtbar machen — sieben Fähigkeitskarten
  1e8bec6	docs(lunar): 42 öffentliche Felder dokumentieren und die Obergrenze auf 985 senken
  7bba514	chore(release): v0.27.0
  3154548	test(docs): das Verteilungsdiagramm absichern, das letzte ungesicherte
  7864142	chore(release): v0.27.1

  Die Tags v0.27.0 und v0.27.1 wurden absichtlich NICHT verschoben. Sie zeigen weiterhin auf 7bba514 und 7864142, die genauen Commits, deren Bäume die Artefakte erzeugten, die jetzt auf crates.io, npm, PyPI, ghcr.io und in der MCP-Registry liegen. Die .cargo_vcs_info.json eines Crates verzeichnet das sha1, aus dem es gepackt wurde, Registries sind unveränderlich, und die SLSA-Build-Provenance-Attestierung auf den Release-Assets von v0.27.1 ist an diesen Commit gebunden. Ein Verschieben der Tags hätte jedes dieser veröffentlichten Artefakte auf einen Commit zeigen lassen, der nicht mehr existiert. Sie zu belassen hält die alten Commits erreichbar und jede veröffentlichte Herkunftskette auflösbar, auf Kosten von zwei Tags, die keine Vorfahren von main mehr sind — weshalb es diese Version gibt: v0.27.2 gibt main einen eigenen Tag, gepackt aus einem Commit, der darauf liegt.

  Dies ist das zweite offengelegte Umschreiben dieser Historie; das erste, am 2026-09-21, kanonisierte die Autorenschaft und ist in den Hinweisen zu 0.27.0 mit seinen eigenen zwei hängenden crate-sha1 verzeichnet. Ein Umschreiben wird hier jedes Mal offengelegt, weil ein Repository, das nachprüfbare Herkunft verkauft, den Boden unter einem veröffentlichten Artefakt nicht stillschweigend verschieben kann.

0.27.1 - 2026-09-22#

Behoben#

• Das veröffentlichte Crate kompilierte nicht. src/lunar_orientation.rs enthält ein include_str! auf oberster Ebene von tests/fixtures/llr_geometry/de440_moon_pa.csv, und das Manifest schließt /tests/fixtures aus dem Paket aus, sodass dem Tarball, den crates.io erhält, eine Datei fehlte, die die Bibliothek selbst einbettet. Die Veröffentlichung von v0.27.0 scheiterte aus diesem Grund an ihrem Verifikations-Build, und kein 0.27.0 erreichte crates.io; npm und PyPI, deren Jobs nicht davon abhängen, veröffentlichten normal. Der Ausschluss trägt jetzt eine Ausnahme für diesen einen Katalog.

  Jedes andere include_str! eines Fixtures in src/ liegt in einem Modul #[cfg(test)] und erreicht daher nie die gepackte Bibliothek. Nur eines auf oberster Ebene tut das.

• Nichts in CI führte cargo package aus, weshalb ein Tarball, der nicht kompiliert, erst vom Veröffentlichungsjob entdeckt wurde, nachdem zwei andere Registries bereits ausgeliefert hatten. Ein Job package baut und kompiliert jetzt bei jedem Push genau den Tarball.

Geändert#

• Die Festschreibungen der Ausgabe zur Mond-Bezugssystemrealisierung verschieben sich bei einem Versionssprung nicht mehr. Die SVG-Fußzeile trägt die Version der Engine, sodass jede Version drei Hashes neu basierte — zweimal an einem Tag — und eine routinemäßig neu genommene Festschreibung nicht mehr gelesen wird. Die Versionszeichenfolge wird vor dem Hashen auf einen Platzhalter normalisiert, und die Ausgabe wird getrennt zugesichert, die laufende Version zu nennen, sodass diese Tatsache genauer geprüft wird, als der Hash sie je prüfte.

0.27.0 - 2026-09-22#

Hinzugefügt#

• lunar-llr-datum — das Mond-Bezugssystemdatum aus einer realen Beobachtungskampagne. lunar-frame-campaign ersetzte eine injizierte Helmert-Transformation durch eine simulierte Kampagne und sagte das: ihr Stationsnetz, ihr Zeitplan und ihr Sigma je Beobachtung sind illustrative Eingaben. Dieses Szenario entfernt die Simulation aus den zwei Stellen, an denen ein Zeitplan und ein Fehlermodell in die Antwort eingehen. Die Epochen sind die Sendezeiten von 337 archivierten Normalpunkten der ILRS-Laserentfernungsmessung zum Mond (2015-04-08 .. 2015-06-27, Grasse MeO 7845 und Matera MLRO 7941, alle fünf Retroreflektor-Arrays), und jedes Beobachtungsgewicht ist die eigene archivierte Präzision dieses Normalpunkts, bin_rms / sqrt(n_raw) — ein Median von 5,13 mm Einweg-Entfernung, aus der Datei, nicht hier gewählt. Stationskoordinaten stammen aus IERS ITRF2020 und die Reflektorkoordinaten aus JPL DE430 Tabelle 7; jedes Fixture verzeichnet eine URL, ein Abrufdatum und ein SHA-256 und wird von einem festgeschriebenen Generator aus seiner Quelle neu erzeugt, der die Quelle prüft und abbricht, statt eine Zahl auszugeben. Der Bericht nennt, welche Links gemessen sind und welche modelliert bleiben, und die modellierten werden gemessen: die beobachtete minus berechnete Einweg-Entfernung über die realen Daten beträgt 156.494 m RMS, was derselbe Testsatz gegenüber JPL Horizons über denselben Zeitraum bestätigt (195.655 m RMS-Vektor, schlechteste Epoche 0,054° — innerhalb der ~0,3°, die die eingebaute analytische Mondreihe für sich beansprucht). Additiv: eine neue Art, ein neuer Leser (realdata::llr_crd) und ein neues Modul (lunar_llr); die bestehenden Pakete zum Mond-Bezugssystem sind bitgenau festgelegt.

• sigma_ure_m als Szenarioparameter bei lunar-integrity und moonlight-service-volume. Die Genauigkeit der Entfernungsmessung im Signal im Raum war eine Konstante zur Übersetzungszeit (LUNAR_SIGMA_URE_M), sodass ein Sweep des Dienstvolumens immer nur Bestanden/Nicht bestanden bei einem festen Wert beantworten konnte. Die Schutzniveaus sind exakt linear darin, sodass seine Bereitstellung den Sweep in eine Anforderung an die Entfernungsgenauigkeit über das ganze Volumen verwandelt. Der Standardwert reproduziert das frühere Verhalten bitgenau.

• Export der Geometrie je Satellit bei moonlight-service-volume: export_site_lat_deg + export_site_lon_deg fügen ein Array per_sat_geometry hinzu, das Azimut, Elevation und Schrägentfernung zu jedem Satelliten zu jeder Epoche für einen benannten selenographischen Standort angibt, plus das Sichtbarkeitskennzeichen. Die aggregierte Abdeckungszusammenfassung fasst die Geometrie je Satellit absichtlich zusammen, aber die Schrägentfernung ist genau das, was ein Link-Budget verbraucht, sodass eine gemeinsame Analyse von Kommunikation und Navigation nicht allein aus der Zusammenfassung möglich war. Aus, sofern nicht beide Koordinaten angegeben sind; rein additiv.

• lunar_service::topocentric, der öffentliche Hilfsbaustein für Blickwinkel hinter dem Export.

• Eine Zeile der Verifikationsmatrix für die neue Geometriefähigkeit.

• Das reale Antennenmuster im Geometrieexport. Die Engine führt seit P1 ein Muster einer gleichmäßig ausgeleuchteten kreisförmigen Apertur (antenna::pattern_gain_dbi, die Form [2·J₁(x)/x]² nach Airy), und nichts außerhalb von antenna.rs verwendete es — stattdessen leistete eine Boresight-Verstärkung, gepaart mit einer Faustregel von Verstärkung zu Strahlbreite, die Arbeit. Eine optionale Tabelle export_antenna bei moonlight-service-volume (nur gelesen, wenn der Exportstandort gesetzt ist) gibt jeder exportierten Zeile jetzt den Off-Boresight-Winkel am Satelliten und die Sendeverstärkung in Richtung des Standorts aus diesem Muster und fügt einen Block antenna_pattern hinzu, der die Anzahl im Strahl beim realen Muster neben der Anzahl im Strahl bei der symmetrischen Näherung (θ₃dB[deg] = √(31000/G_lin)) meldet, mit der Differenz als benannte Korrektur. Beide Zahlen werden ausgegeben; keine ersetzt die andere. Gemessen an der eigenen repräsentativen lunaren Apertur der Engine (Schüssel von 1 m, 2,4 GHz, η = 0,60) über einem südpolaren Standort und der illustrativen Schale der Klasse LCNS weichen die beiden um mehr als einen Satelliten ab: das reale Muster legt 0 von 76 sichtbaren Links in den Halbleistungsstrahl, die Näherung behauptet 28 — eine Korrektur von −2,33 Satelliten je Epoche, schlechteste einzelne Epoche 3. Die Näherung trägt eine eigene Aperturausbeute (0,641 gegenüber der Regel 70·λ/D Grad, mit der sie üblicherweise angegeben wird, 0,920 gegenüber einer gleichmäßigen kreisförmigen Apertur), sodass sie bei einer Schüssel mit η = 0,60 einen Strahl liefert, der 1,238× zu breit ist; der Block gibt beide implizierten Ausbeuten aus, statt sie erschließen zu lassen. Rein additiv: gemessen über den dokumentierten Arbeitspunkt, 597 bereits vorhandene Blätter, 0 geändert, 0 entfernt, 494 hinzugefügt.

• antenna::symmetric_beamwidth_rad, antenna::symmetric_relation_implied_efficiency, antenna::within_half_power_beam, antenna::HALF_POWER_DROP_DB, antenna::SYMMETRIC_GAIN_BEAMWIDTH_CONST_DEG2, antenna::UNIFORM_APERTURE_HPBW_COEFF und lunar_service::nadir_off_boresight_rad, die öffentlichen Bausteine dahinter. Das Muster ist jetzt außerdem an den veröffentlichten Airy-Konstanten verankert statt nur an sich selbst: der Halbleistungsdurchgang wird per Bisektion gefunden und mit x = 1.61634 verglichen, was die exakte Halbleistungsbreite 1.02899·λ/D ergibt und ehrlich festhält, dass der übliche Koeffizient 1.02 pattern_gain_dbi auf −2,955 dB legt, nicht auf −3,010 dB.

• Eine Langformtabelle zur Reproduzierbarkeit für lunar-time-budget. Die arraywertigen Ausgaben des Szenarios — das Gitter der Mittelungszeiten, die sieben Kurven x(τ) je Term und ihre Gesamtsumme als Wurzel der Quadratsumme — erreichten Verbraucher nur als JSON-Arrays. Eine veröffentlichte Tabelle wurde bei 400 Zeichen gekürzt und veröffentlichte 23 ihrer 57 Mittelungszeiten unter einer Spalte, die alle beanspruchte, und das Manuskript baute die Kurven je Term aus geschlossenen Formen neu auf, weil die Engine sie nie ausgab. Ein gewöhnlicher Lauf schreibt jetzt außerdem <scenario>.table.csv mit einer Zeile je (Gitterindex, Mittelungszeit, Term), die nicht zu etwas gekürzt werden kann, das noch vollständig aussieht. Der Gitterindex ist ein exakter Verbindungsschlüssel; τ wird mit 13 signifikanten Stellen geschrieben und jedes x mit 7, sodass sich die Bytes zwischen Builds desselben Quelltexts nicht aufspalten. Rein additiv: das JSON des Berichts ist bytegleich.

• Der Bericht zu hybrid-optical-rf beschreibt sich nun selbst. Ein Block link_configuration gibt die aufgelösten Eingaben der Strecke wieder — Trägerwellenlänge, Sende- und Empfangsapertur, Entfernung, Pulsbreite, Integrationszeit, Wirkungsgrade und Verluste — mit angewendeten Standardwerten, sodass eine Veröffentlichung die Konfiguration angibt, mit der gerechnet wurde, statt einen aus dem Quelltext abgelesenen Standardwert zu zitieren. Ein Block units nennt für jede Größe, die eine Veröffentlichung voraussichtlich zitiert, die Einheit und die Herkunftsklasse. Der Anlass sind die Spuren der Übergabe-Kovarianz: Sie wurden als nacktes variance ausgegeben, und ein Manuskript schloss aus einer internen Konsistenzprüfung auf Quadratmeter. Der Schluss war richtig, und genau deshalb war es ein Mangel — nichts hätte aufgedeckt, wenn er falsch gewesen wäre. Rein additiv: gemessen über vier Konfigurationen, 456 bereits vorhandene Felder, 0 geändert, 0 entfernt, 196 hinzugefügt.

• Eine Zeile der Verifikationsmatrix für die Reproduzierbarkeitstabelle des Zeitbudgets, ehrlich als InternalConsistency / MODELLED eingestuft — die Summe wird gegen die Wurzel aus der Quadratsumme der Terme in derselben Datei geprüft, die dieselben Termdefinitionen wie die Engine selbst verwendet und daher keine unabhängige Referenz ist. Zusammen kommen damit drei Zeilen hinzu. Die laufende Summe für diesen unveröffentlichten Abschnitt beträgt 168 Zeilen — 64 VALIDATED, 100 MODELLED, 4 PARTNER.

Geändert#

• Die Commit-Urheberschaft in der gesamten Historie ist nun eine einzige Identität, und zwei veröffentlichte Crates verweisen auf einen Commit, der nicht mehr existiert. Am 2026-09-21 wurde die Git-Historie so umgeschrieben, dass jeder menschliche Commit von ashfordeOU <236818772+ashfordeOU@users.noreply.github.com> verfasst und committet ist. Zuvor gab es drei Schreibweisen einer einzigen Person — 688 Commits als ashfordeOU <contact@ashforde.org>, 34 als Chakshu Baweja <contact@ashforde.org> und 94 bereits in der kanonischen Form. Der eine Commit von dependabot[bot] wurde bewusst als eigener Autor belassen: Den Abhängigkeits-Bump eines Bots umzubenennen, würde die Urheberschaft einer Arbeit beanspruchen, die hier niemand geleistet hat.

  Kein Inhalt hat sich geändert. Das Umschreiben betraf nur die Header von Autor und Committer, und das ist überprüfbar statt bloß behauptet: Der Baum jedes Tags und jedes Branches ist bitgleich mit dem von zuvor. v0.26.0 löst weiterhin auf den Baum 92284e9420605568f1bfabb78cd95d383b40f3e2 auf, genau wie bisher.

  Was es gekostet hat. Der Name eines Commits ist ein Hash über seinen Baum, seine Eltern und seine Autoren-Header; wird also ein Vorfahr geändert, erhält jeder Nachfahr einen neuen Namen. Der Release-Commit von v0.26.0 hieß dce2dbf7700788cf6de46260c14673c0e5347360 und heißt jetzt d4921f3025569e00e425e1747d0acfc261e96e18. Zwei Artefakte haben den alten Namen zum Zeitpunkt der Veröffentlichung festgehalten und lassen sich nicht korrigieren, weil eine veröffentlichte Registry-Version von Grund auf unveränderlich ist:

  • kshana 0.26.0 auf crates.io — .cargo_vcs_info.json hält dce2dbf… fest
  • kshana-mcp 0.26.0 auf crates.io — dasselbe sha1, path_in_vcs: mcp/kshana-mcp

  Nichts anderes ist betroffen. Das npm-Paket hält kein gitHead fest, und die PyPI-Distribution hält überhaupt keinen Commit fest; beides wurde geprüft statt angenommen.

  Es gibt keine Reparatur, die dce2dbf… auf den umgeschriebenen Commit verweisen lässt: Diese Zeichenfolge ist die alte Vorgeschichte, und sie lässt sich nur auflösen, indem die Historie vor dem Umschreiben veröffentlicht bleibt, was die durch das Umschreiben entfernte Urheberschaft wiederherstellen würde. Die Herkunft von 0.26.0 läuft daher über das Tag und nicht über das festgehaltene sha1 — und das Tag liefert exakt dieselben Bytes, aus denen das Crate gebaut wurde. Das nächste Release hält einen gültigen Commit fest, ohne dass etwas zu tun ist.

Behoben#

• realtime-frame-eop verwendete standardmäßig eine EOP-Datei ohne Vorhersagezeilen (G12). Das Szenario bettete als Offline-Standard einen fünfzeiligen Auszug aus finals2000A ein, der nur Endwerte enthielt, sodass ein einfacher Lauf predicted_rows.n = 0 meldete und die Tabelle je Vorhersagehorizont auf 5, 4, 3 und 2 Paaren beruhte. Die Engine konnte stets eine Vorhersagezeile lesen — die Eingabe enthielt schlicht keine. Der Standard ist nun der unveränderte IERS-Auszug von 2026 (tools/finals2000A_2026.txt, MJD 61173–61204): 20 endgültige Werte aus Bulletin B und 12 reine Vorhersagezeilen aus Bulletin A, sodass ein einfacher Lauf ohne Dateiargument und ohne Netzwerk predicted_rows.n = 12 meldet und eine Tabelle je Vorhersagehorizont mit n = 20 / 31 / 30 / 29 liefert; auch der Vergleich mit dem operationellen Prädiktor und die Übereinstimmung mit den vom Produkt selbst veröffentlichten Vorhersagen werden befüllt. Der lange 45-Zeilen-Auszug wurde als Alternative gemessen und verworfen: Er enthält ebenfalls nur Endwerte und hätte predicted_rows.n bei 0 belassen. Dies verändert veröffentlichte Zahlen, nach Regel R4 und mit Autorisierung durch den Gründer: zehn der 22 Zellen der veröffentlichten p4_frame_eop.csv und 24 der 42 befüllten Zellen von tests/golden/realtime-frame-eop.csv. Der gemessene Polbodenwert aus Rapid minus Final wird 0,0678 mas (zuvor 0,0769 mas), und das ist der Wert, den die eigene Polbewegungstabelle von Paper P4 bei n = 20 bereits veröffentlicht — beide stimmen nun überein, statt um 13,5 % abzuweichen. Jede andere Zahl, die P4 aus dieser Tabelle ausgibt, ist in der ausgegebenen Genauigkeit unverändert. Die vollständige Aufstellung alt → neu, einschließlich der Felder, die sich nicht bewegt haben, steht in docs/revisions/G12-default-eop-cell-changes.md. Der Auszug mit nur Endwerten wird weiterhin ausgeliefert, bytegenau festgelegt und ausgeführt: Eine Anzahl von null Vorhersagezeilen bei ihm ist eine Eigenschaft der Datei, und ein Test belegt das weiterhin.

• Eine veraltete Satellitenbegrenzung in moonlight-service-volume. Das Szenario begrenzte n_sats auf 12, obwohl sein eigener Konstellationsgenerator 24 unterstützt und ein Test 24 prüft. Daher wurde jede angeforderte Anzahl über 12 stillschweigend reduziert, und ein Sweep über die Satellitenzahl lieferte oberhalb von 12 identische Werte, die sich nicht von echter geometrischer Sättigung unterscheiden ließen. Jetzt wird an der Grenze des Generators begrenzt. Dies ist eine Verhaltensänderung nur für n_sats > 12.

• Dieselbe veraltete Begrenzung in lunar-differential-pnt. lunar_dpnt begrenzte n_sats auf 12 mit derselben Folge, und diese erreichte eine veröffentlichte Tabelle: dpnt_nsats_sweep.csv enthält eine Zeile n = 16, die byteidentisch mit der Zeile n = 12 ist, weil die Engine die Antwort für zwölf Satelliten unter einer Bezeichnung für sechzehn Satelliten lieferte. Jetzt wird an der Generatorgrenze von 24 begrenzt, und ein neuer Test hält dies fest: Jede größere Konstellation muss sowohl ihre eigene Anzahl melden als auch das Schutzniveau streng verbessern, sodass die Begrenzung nicht unbemerkt zurückkehren kann. Dies verschiebt veröffentlichte Zahlen: Das Schutzniveau für n = 16 wird von 16,92 m zu 14,57 m. Bis 24 durchgerechnet ist die Kurve streng monoton (11,94 m bei 24 Satelliten, 29,5 % besser als bei 12), es gibt also keine Sättigung bei 12: Das scheinbare Plateau war die Begrenzung. Verhaltensänderung nur für n_sats > 12.

0.26.0 - 2026-09-18#

Ein Release für Dokumentation, Transparenz und Playground. Keine Änderungen am Engine-Verhalten: Die Verifikationsmatrix steht bei 102 Zeilen: 56 VALIDATED, 42 MODELLED, 4 PARTNER, unverändert gegenüber 0.25.0.

Hinzugefügt#

• Rustdoc auf Crate-Ebene (//! in lib.rs), die Einstiegspunkte, das Modell von Ehrlichkeit und Evidenzstufen sowie die Reproduzierbarkeit abdeckt, sodass docs.rs mit einer echten Startseite statt einer bloßen Modulwand öffnet.
• docs/SCENARIOS.md: eine Referenz je Art für alle 50 Szenarioarten, von gen_validation_artifacts aus api::list_scenario_kinds() (der einzigen maßgeblichen Quelle) erzeugt und durch tests/scenarios_reference_doc_sync.rs abgesichert, sodass sie nicht vom Dispatcher abweichen kann.
• Moduldokumentation für die 11 zuvor undokumentierten öffentlichen Module (allan, estimator, fom, hybrid, inertial, models, report, run, scenario, timetransfer, types).
• Literaturquellen für fünf Formelmodule, die eine Gleichung angaben, aber keine Referenz nannten: batch_ls (Tapley/Schutz/Born; Bjorck), cr3bp (Szebehely; Koon et al.), detection (Kay), attitude_budget (Wertz; Sidi), reentry (Allen-Eggers, NACA TR-1381).
• Eine veröffentlichte security.txt auf kshana.dev für koordinierte Offenlegung.
• Validierungsstufe je Lauf im Playground. Die Gütemaßtabelle eines Einzellaufs trägt jetzt je Kennzahl eine Markierung VALIDATED/MODELLED, gelesen aus derselben Abfrage fomTier(), die auch der herunterladbare Bericht verwendet (spiegelt src/fom_label.rs, selbst aus der Verifikationsmatrix abgeleitet), sodass die neben einer Live-Zahl angezeigte Stufe dem Register nie widersprechen kann.
• lunar-attack-surface im Playground-Menü: Alle 50 aufrufbaren Arten sind jetzt einen Klick entfernt (zuvor 49/50).
• Fünf weitere lauffähige Capability-Karten (Weltraumwetter, Bewertung von HF-Beeinträchtigungen, Resilienz, CCSDS-OEM-Interoperabilität, KIF), wodurch die lauffähigen Karten von 11 auf 16 steigen. Karten nur für API und Bibliothek behalten einen ehrlichen Dokumentationslink statt einer vorgetäuschten Ausführen-Schaltfläche.

Geändert#

• Die Dokumentationsabdeckung wird jetzt in der CI schrittweise hochgesetzt. check-doc-coverage.sh kompiliert die Bibliothek mit missing_docs, zählt die Warnungen und schlägt nur fehl, wenn die Zahl über eine festgelegte Obergrenze (986) steigt. Ein hartes #![warn(missing_docs)] unter -D warnings hätte ~1000 derzeit undokumentierte öffentliche Elemente über Nacht zu einem Build-Abbruch gemacht; so lassen neue undokumentierte öffentliche Elemente den Build scheitern, während der bestehende Rückstand gezielt abgebaut wird.

Behoben#

• Die Zeile des MCP-Werkzeugs list_scenario_kinds nannte „~17 eingebaute Szenarioarten“, während api::list_scenario_kinds() seit einiger Zeit 50 bereitstellte: eine für Agenten gedachte Dokumentation, die die tatsächliche Fähigkeit um das Dreifache zu niedrig angab. Auf die tatsächliche Zahl festgesetzt.
• Die unabhängige Referenz für die Schema-Übereinstimmung des CycloneDX-SBOM wurde für den aktualisierten Abhängigkeitsgraphen (60 Komponenten) neu erzeugt. Der Übereinstimmungsbefund ist unverändert: null normalisierte Schemafehler, und jede atomare Lizenzkennung steht weiterhin in der offiziellen SPDX-Aufzählung.

0.25.0 - 2026-07-15#

Hinzugefügt#

• Fünf Fähigkeiten zu extern VALIDATED hochgestuft, jede jetzt gegen eine unabhängige Drittimplementierung derselben eindeutig definierten Größe gegengeprüft (nicht zirkulär, mit offline neu erzeugbaren Fixtures):
  • Umrechnung IEEE-1139-Potenzgesetz → Allan-Abweichung gegen die geschlossenen Formen aus allantools für alle fünf Rauscharten (tests/powerlaw_oadev_reference.rs);
  • Gewichte des CRPA-MVDR-/Minimum-Norm-Nullsteuerungs-Beamformers gegen numpy/scipy LAPACK (tests/crpa_reference.rs);
  • Lagebestimmung nach Wahba / TRIAD / QUEST gegen die SVD-Funktion Rotation.align_vectors von SciPy bei rauschfreien Beobachtungen (tests/wahba_reference.rs);
  • CCSDS-502,0-OEM-Austausch von Kovarianzblöcken, per Round-Trip durch den Parser der unabhängigen Bibliothek oem geführt (tests/ccsds_oem_covariance_reference.rs);
  • der Kern für die Detektionsstatistik der Square-Law-Akquisition (verallgemeinertes Marcum-Q / P_d / P_fa / Schwelle) gegen SciPy ncx2/chi2 (tests/acquisition_reference.rs). Die maschinell geprüfte Validierungsmatrix wandert auf 56 VALIDATED · 42 MODELLED · 4 PARTNER über 102 Zeilen (zuvor 51 · 47 · 4). Die ehrlichen Einschränkungen des Geltungsbereichs bleiben erhalten, z. B. deckt die Hochstufung der Akquisition nur den Kern der Detektionsstatistik ab; CFAR/Straddling-Verlust bleibt MODELLED.
• Gütemaße im Positionsbereich (fom::positioning_performance): exakte CEP, SEP und 2DRMS aus der 3-D-ENU-Positionskovarianz einer Navigationslösung plus einem horizontalen Schutzniveau. CEP/SEP sind die exakten medianen Radialfehler (nicht die lineare Regel 0.589·(σ₁+σ₂)), gegengeprüft gegen die Rayleigh-/Maxwell-Quantile aus scipy.stats und einen unabhängigen NumPy-Monte-Carlo-Median (tests/positioning_fom_reference.rs). Ersetzt den bisherigen ehrlichen Stub „nicht implementiert“: Die Funktionssignatur hat sich geändert von (), das einen Fehler lieferte, zu (cov_enu, hpl_m), das ein PositioningFom liefert.
• Äquivalente Freiheitsgrade (EDF) für Konfidenzintervalle für alle Estimatoren der Allan-Familie vervollständigt (assurance::uncertainty::edf): Die EDF für modifizierte Allan-, Hadamard- und Gesamtvarianz verwenden jetzt den kombinierten EDF-Algorithmus von Greenhall & Riley und die TOTVAR-Form aus Tabelle 7 von NIST SP 1065 (zuvor war nur die EDF der überlappenden Allan-Varianz implementiert; die anderen verwendeten diese stillschweigend mit), gegengeprüft gegen allantools edf_greenhall/edf_totdev (tests/uncertainty_edf_reference.rs).
• Unabhängige externe Gegenprüfungen für die Fähigkeiten Mond-PNT-Geometrie, DOP, EOP, DRO und HF-Entfernungsmessung (tests/validate_p*.rs, mit Fixtures und Generatoren der unabhängigen Referenz unter tests/fixtures/{p1_footprint,lunar_service,eop_prediction,rf_ranging_precision,dro_family_jpl,p2_independent_dop}/). Jede Prüfung lässt eine bereits ausgelieferte modellierte Fähigkeit gegen eine Referenz laufen, die von einer anderen Implementierung erzeugt wurde, sodass die Übereinstimmung nicht zirkulär ist: der Sende-/Erfassungs-Footprint im Orbit gegen scipy.special.j1 (Cephes, eine tatsächlich andere Bessel-J1); die DOP der Oberflächenbaken-Geometrie gegen eine unabhängige NumPy-Lösung von (HᵀH)⁻¹; das Fehlerwachstum der UT1/EOP-Persistenzvorhersage gegen ein separates NumPy-Neueinlesen derselben wörtlichen IERS-Zeilen aus finals2000A; die Familie ebener retrograder Fernbahnen gegen die NASA/JPL Three-Body Periodic Orbit Database; und das Budget der HF-Entfernungsmessgenauigkeit gegen eine Referenz aus ersten Prinzipien. Dies sind zusätzliche Regressionsbelege für bestehende Module; das Hinzufügen dieser Gegenprüfungstests stuft für sich genommen keine Fähigkeit um (die fünf Hochstufungen oben sind separate, durch eine unabhängige Referenz gestützte Statusänderungen in src/verification.rs).
• Szenario lunar-attack-surface (src/attack_surface.rs, kind = "lunar-attack-surface"): ein zusammengesetzter, binär erreichbarer (CLI / Python / MCP / wasm über run_toml) Lauf zur P1-Signalsicherheit auf dem Mond, der das Leistungsdefizit der Link-Bilanz und sein Sensitivitätsband von 12–18 dB, die erforderliche Jam-/Spoof-Sendeleistung gegenüber dem Abstand, den Erfassungs-Footprint im Orbit unter einem realen Antennendiagramm, das Ergebnis des Einrastens (Pull-in) bei Spoof-Erfassung der Tracking-Schleife, die Horizontreichweite auf einem Körper ohne Atmosphäre und das OSNMA/TESLA-Authentifizierungsbudget zusammenführt. Ein leerer Rumpf reproduziert die P1-Basislinie.
• Sensitivitätsband des Leistungsdefizits (linkbudget::deficit_sensitivity_band, deficit_power_factor): ein echter mehrachsiger Sweep (Referenz × EIRP × Schrägentfernung), aufgebaut auf sweep::SweepAxis und ausgewertet über received_signal_power_dbw, der das P1-Band von 12–18 dB reproduziert und die linearen Faktoren 32× (gerundet) / 36× (ungerundet) in Einklang bringt.
• Dreidimensionaler Spoof-Erfassungswürfel (spoof_capture::capture_cube): ergänzt die Karte um die Achse des Träger-/Doppler-Versatzes (J/S × Codeversatz × Trägerversatz, Einrastzeit je Zelle); die Schicht mit Trägerversatz null reduziert sich exakt auf die 2-D-capture_map.

Geändert#

• Detektion mit spärlichem Monitornetz (monitor_network) setzt jetzt die physikalische AGC-Statistik aus spoof_monitors und das selenographische Sichtbarkeitsraster aus lunar_service zusammen, um Detektionsstatistik und Geometrie jeder Station abzuleiten, statt freier Parameter und einer ad-hoc-Überlappung auf dem Großkreis; die Detektionswahrscheinlichkeiten je Monitor und für das Netz bleiben die geschlossenen Chi-Quadrat-/Marcum-Q-Formen aus detection. Die Felder von SurfaceMonitor / SpoofEvent haben sich geändert auf physikalische Größen (Breite/Länge/Höhe/Leistung).

Behoben#

• Dimensionierung des OSNMA/TESLA-Authentifizierungsaufwands (nma_budget): Die OSNMA-Feldanteile je Seite (8 Bit HKROOT + 32 Bit MACK pro Seite von 2 s) waren fälschlich als Summen je Subframe bezeichnet, wodurch der Aufwand um das 15-Fache zu niedrig angegeben war (1,33 bit/s). Korrigiert auf die veröffentlichten Summen je Subframe von 30 s aus dem SIS-ICD (HKROOT 120 + MACK 480 Bit ⇒ 20 bit/s). Die Folge wird nun ehrlich benannt: Bei einer AFS-Navigationsrate von 50 bit/s ist der Authentifizierungsaufwand ein Kostenfaktor erster Ordnung von ≈40 %, nicht ein vernachlässigbarer Anteil von wenigen Prozent; das Feld auth_latency ist als Verzögerung der Schlüsselfreigabe dokumentiert (eine untere Schranke der Ende-zu-Ende-Zeit bis zur ersten authentifizierten Lösung).

0.24.0 - 2026-07-09#

Ein breites Capability-Release. Es bringt zwei vollständig extern validierte Analysesuiten: eine vollständige Familie der multikriteriellen Entscheidungsanalyse (MCDA) und die Estimatoren für Allan-Wander / Uhrenstabilität bei langem τ. Dazu öffnet es auf dem Unterbau eine neue lauffähige Szenarioschicht für Mond-Zeitbudget, Echtzeit-Frame/EOP, optisch/HF-hybride Verfahren, cislunare Beobachtbarkeit und Konfliktresilienz geschichteter PNT, sowie einen Unterbau für Mond-Oberflächenbaken und Signalsicherheit. Die maschinell geprüfte Validierungsmatrix wächst auf 51 VALIDATED · 47 MODELLED · 4 PARTNER über 102 Zeilen (zuvor 40 · 47 · 4 über 91): Alle elf neuen Zeilen sind Validierungen der Entscheidungsanalyse- und Zeitschätzer gegen eine externe unabhängige Referenz, gegen unabhängige Bibliotheken (SciPy, pymcdm, pyDecision, allantools) auf enge Toleranz geprüft, während die neue PNT-Fähigkeitsoberfläche ehrlich als MODELLED ausgewiesen wird. Wie immer wird keine numerische Modellaussage ohne externen Datensatz dahinter hochgestuft.

Hinzugefügt#

Lauffähige Szenarien: jedes ein registriertes Szenario-kind, über die Engine ausgeliefert und in der CI durchgängig durch tests/determinism.rs belegt (das jedes mitgelieferte scenarios/*.toml ausführt und bei jeder nicht lauffähigen Fixture hart fehlschlägt):

• Konfliktresilienz geschichteter PNT (conflict-resilience, src/conflict_resilience.rs) — eine Monte-Carlo-Resilienz-Engine mit festem Seed für eine mehrschichtige PNT-Architektur, mit einem Modell des Überlebens bei graceful degradation je Vektor nach §4,2 (vier benannte Bedrohungsvektoren, die geschlossene Form des Überlebens nutzbarer PNT, gegen die die Monte-Carlo-Läufe je Schicht konvergieren, im Ergebnis-JSON ausgegeben) und dokumentierter, gegen Abweichung abgesicherter Herkunft der Bedrohungsparameter (src/conflict_threat_params.rs). Die Architekturen sind MODELLED; die Konvergenz des Überlebens-Monte-Carlo → geschlossene Form ist der validierte Kern.
• Cislunare Beobachtbarkeit (cislunar-observability, src/cislunar_observability.rs): ein Eigenspektrum der Beobachtbarkeits-Gramian über einen Bogen, ein durch Differentialkorrektur gewonnener Seeder für retrograde Fernbahnen (DRO) und eine unabhängige Gegenprüfung mit einem Square-Root-Information-Filter, dessen A-posteriori-Kovarianz genau bei vollem Beobachtbarkeitsrang endlich wird. Konstellation MODELLED; die Invarianten von Rang/Gramian/STM/SRIF sind der validierte Kern.
• Heterogene optisch/HF-hybride Kontinuität und Integrität (hybrid-optical-rf, src/hybrid_integrity.rs, src/optical_availability.rs, src/optical_linkbudget.rs, src/cross_raim.rs): domänenübergreifende Verfügbarkeit und Integrität, wenn optische und HF-PNT kombiniert werden. MODELLED.
• Endogenes Mond-Zeitbudget (lunar-time-budget, src/lunar_time_budget.rs) und Echtzeit-Frame-/EOP-Budget (realtime-frame-eop, src/realtime_frame_eop.rs, src/frame_eop.rs): die Budgets für Mondzeit und Erdorientierung nach P3/P4, endogen aus der Zeitgebungskette abgeleitet statt behauptet. MODELLED.

Extern validierte Analysesuiten: Bibliotheksfähigkeiten, die jeweils als neue Zeilen VALIDATED in die Matrix eingehen (gegen eine unabhängige externe Referenz geprüft, keine Selbstprüfung):

• Vollständige Suite zur multikriteriellen Entscheidungsanalyse (MCDA) (src/mcda/): die vier Methodenfamilien: Wertaggregation (WSM, WPM, WASPAS), Verhältnissystem (MOORA) und proportional (COPRAS), Abstand zum Ideal (TOPSIS), Kompromissprogrammierung (VIKOR) und Outranking (PROMETHEE II mit sechs verallgemeinerten Kriterienformen, ELECTRE I Konkordanz/Diskordanz), dazu AHP-Prioritätsgewichte aus dem Perron-Eigenvektor mit dem Gate des Saaty-Konsistenzverhältnisses (CR < 0,10), MAUT-Nutzen, Extraktion der Pareto-Front und Sensitivitätsanalyse der Gewichte. Die neun Aggregatoren reproduzieren pymcdm / pyDecision, und der AHP-Eigenvektor stimmt mit SciPy/LAPACK überein, jeweils auf < 1e-9 (tests/mcda_*_reference.rs). Das Sensitivitäts-Tornadodiagramm wird auch im Szenario zur Konfliktresilienz ausgewiesen.
• Allan-Wander- und Langzeit-τ-Uhrenstabilitätsschätzer (src/allan.rs): MTIE (die Wanderstatistik des Spitze-Spitze-Zeitfehlers nach ITU-T G.810/G.823/G.8261, auf die Synchronisationsmasken geschrieben sind), die Zeitbereichs-Wanderstatistiken MDEV und TDEV sowie die Schätzer mit erweitertem Bereich Theo1 / TOTVAR. VALIDATED gegen allantools an der Serie aus NIST SP 1065; das auf TOTVAR aufbauende, biasbereinigte Hybridverfahren ThéoH bleibt ehrlich MODELLED.
• Assurance-/Harness für externe unabhängige Referenzen (src/assurance/): ein Harness für unabhängige Referenzen, direkt an das Ehrlichkeits-Gate der CI angebunden, ein W3C-PROV-Herkunftsprotokoll mit deterministischer Merkle-Wurzel sowie äquivalente Freiheitsgrade nach Greenhall + Chi-Quadrat-Konfidenzintervalle für Stabilitätsschätzungen.
• PackRegistry / ExternalPack-Erweiterungsnaht (src/registry.rs, src/api.rs): eine Dispatch-Naht, damit Capability-Packs über eine einzige Registry laufen (der eingebaute Dispatch liegt auf dem heißen Pfad der CLI; Packs außerhalb des Baums werden hinter einem vorbelegten ExternalPack::register_into angebunden), abgesichert durch eine Golden-Suite zur Byte-Identität sowie Standalone-/wasm32-CI-Gates.

Unterbau modellierter Fähigkeiten: neue Bibliotheksmodule, die die obigen und künftige Szenarien speisen (noch kein eigenständiges Szenario-kind):

• DOP von Mond-Oberflächenbaken (src/lunar_beacon.rs) mit Budget der realisierten Genauigkeit, Sweep über die Satellitenzahl und GDOP-Karte, außerdem eine gestörte Mond-Ephemeride (src/lunar_perturbed.rs) sowie Geometrie des atmosphärelosen Horizonts / Inverse der Spoof-Leistung / AFS-Defizitband (src/jamming.rs, src/linkbudget.rs). Verwendet den mit gnss_lib_py validierten DOP-Kern wieder.
• Einlesen von DEM im LOLA-Format + Sichtlinie über das Gelände (src/realdata/lola_dem.rs).
• Dreischichtige Abwehr für Signalsicherheit: Spoof-Erfassung, sensorübergreifende Integrität und Dimensionierung des Monitornetzes (src/spoof_capture.rs, src/cross_sensor_integrity.rs, src/monitor_network.rs) mit einem Antennen-Footprint des Orbitalstrahls und einem OSNMA-Authentifizierungsbudget (src/antenna.rs, src/nma_budget.rs). MODELLED.

Geändert#

• Die Validierungsmatrix und jedes abgeleitete Artefakt wurden aus der einzigen maßgeblichen Quelle (src/verification.rs) neu erzeugt: das Register auf der Website, die Diagramme der Modulkarte und der Validierungsherkunft sowie die Zählstrings in README und je Oberfläche lauten jetzt 51 / 47 / 4 von 102 (zuvor 40 / 47 / 4 von 91); der Wächter für die Ehrlichkeit der Zählung durchsucht jetzt die vollständige Git-Historie, und die README-Abbildungen sind auf die dunkle Markenpalette vereinheitlicht.
• Ein gemeinsamer adaptiver Integrationstreiber trägt jetzt sowohl integrate als auch integrate_dopri (src/integrator.rs) und beseitigt den duplizierten Stepper.
• Statische Analyse mit SonarQube Cloud zur CI hinzugefügt (Rust + importierte Abdeckung), mit Bewertungsabzeichen für Sicherheit / Wartbarkeit / Zuverlässigkeit im README.

Eine Passage, die KI-Clients von Drittanbietern nennt, ist hier ausgelassen; sie steht in CHANGELOG.md auf GitHub.

• Disziplin bei Release und Paketierung: Die CI registriert je Paket/Registry-Veröffentlichung eine Deployment-Umgebung, und der fokussierte öffentliche Standalone-Job ist von den langsamen Validierungs-Binaries abgekoppelt.
• Der Hygiene-Wächter gegen Urheberschaftsangaben ist nur noch auf Urheberschaftsmarkierungen beschränkt, sodass die Nennung eines Integrationshosts oder Produkts den Build nicht mehr scheitern lässt.
• Dokumentation: Der Abschnitt Citing im README listet jetzt die vier veröffentlichten arXiv-Preprints, und die Fähigkeit DOP von Oberflächenbaken ist in der Mond-Zeile dokumentiert.

Behoben#

• Ganzzahlige Schleifenzähler für gleitkommagesteuerte Schleifen (Sonar S2193).
• Genaues Chi-Quadrat-Inverses bei niedrigen Freiheitsgraden durch Newton-Verfeinerung im Pfad der Konfidenzintervalle der Assurance.
• kshana.dev: Der Abschnitt zu den Standards ist jetzt standardmäßig geöffnet, und der Fallback der Registerzählung ist korrigiert; veraltete Strings in README / Website rund um die Beobachtbarkeitsschicht wurden abgeglichen.

0.23.0 - 2026-06-29#

Ein Capability-Release, das eine allgemeine Schicht für Fisher-Information / Cramér-Rao-Beobachtbarkeit und optimale Versuchsplanung hinzufügt, und das Release, auf dem das Paper zur Beobachtbarkeit von Mond-PNT beruht. Die maschinell geprüfte Validierungsmatrix wächst auf 40 VALIDATED · 47 MODELLED · 4 PARTNER über 91 Zeilen (zuvor 39 · 46 · 4 über 89): Die neue Schätz-Engine ist gegen eine externe unabhängige Referenz geprüft und VALIDATED; ihre Anwendung auf den Mond ist ehrlich MODELLED. Wie immer wird keine numerische Modellaussage ohne externen Datensatz dahinter hochgestuft.

Hinzugefügt#

• src/fim.rs: Fisher-Information, Cramér-Rao-Schranken und optimale Versuchsplanung. Eine allgemeine, wiederverwendbare Engine der Schätztheorie: die Fisher-Informationsmatrix M = HᵀWH aus einer Messungs-Jacobi-Matrix und Gewichten; ein symmetrischer Eigenlöser (zyklisches Jacobi-Verfahren); die untere Cramér-Rao-Schranke über die Inverse oder, wenn die Information rangdefizient ist (der Fall des freien Netzes / Datumsdefekts), über die Moore-Penrose-Pseudoinverse plus eine Nullraumbasis; und D-, A-, E- und T-optimale Metriken der Versuchsplanung mit einem Selektor best_design über Kandidatengeometrien. VALIDATED gegen NumPy (eigh/inv) und die veröffentlichten geschlossenen Schranken von Kay (1993) auf 1e-9 (tests/fim_observability_reference.rs), sodass sie als Zeile mit externer unabhängiger Referenz statt als Selbstprüfung in die Matrix eingeht.
• Beobachtbarkeit der gemeinsamen Bahnbestimmung (OD) auf dem Mond (lunar_observability in src/lunar_combination.rs, im Bericht zur Mond-Kombination ausgewiesen): wendet die FIM/CRLB-Engine auf die gemeinsame Lösung von Bahn und Uhr an, um den Datumsdefekt der absoluten Station, die Wiederherstellung des Rangs bei Hinzunahme von Stationen auf Erdbasislinien, die erreichte CRLB der Stationsposition und die E-optimale Konditionierung offenzulegen. Ehrlich MODELLED: Die Schätz-Engine ist extern validiert, aber das Mondnetz, auf das sie angewendet wird, ist eine repräsentative Simulation, und kein derzeitiger Datensatz kann diese Geometrie in eine Messung überführen.
• Repräsentative Geometrie einer elliptischen eingefrorenen Mondbahn (ELFO) für das Szenario zur Mond-Kombination (orbit_ecc, orbit_inc_deg, orbit_argp_deg, orbit_planes; kreisförmige Platzierung bleibt die Voreinstellung) und ein Beobachtbarkeitsfeld ohne VLBI im Bericht, sodass sich zeigen lässt, dass das Ergebnis zum Datumsdefekt geometrieunabhängig gilt. Dieselbe Stufenfolge 3→1→0 und dieselbe Schwelle von drei Stationen gelten auf einer ELFO der Moonlight/LCNS-Familie, und mit drei Erd-VLBI-Basislinien ist die absolute Stationsposition mit einer Schranke im Submeterbereich beobachtbar, festgehalten durch elfo_geometry_confirms_the_observability_structure. Weiterhin MODELLED.

Geändert#

• Die Validierungsmatrix und jedes erzeugte Nachweisartefakt wurden aus der einzigen maßgeblichen Quelle (src/verification.rs) neu erzeugt: das Register (web/data/verification-matrix.json), docs/VERIFICATION-MATRIX.md, docs/MODELLED-RATIONALE.md, die Abbildungen der Validierungsaufschlüsselung und der Arten unabhängiger Referenzen sowie die Zählstrings im README auf allen Verteilungsoberflächen lauten jetzt 40 / 47 / 4 von 91.

0.22.1 - 2026-06-29#

Ein reines Packaging-Patch-Release. Keine Änderungen an Engine, Szenario oder Ergebnissen; die Validierungsmatrix bleibt unverändert bei 39 VALIDATED · 46 MODELLED · 4 PARTNER über 89 Zeilen.

Behoben#

• npm publish: Das aus dem Crate-Manifest abgeleitete Paketfeld repository.url verwendete den GitHub-Eigentümer in falscher Groß-/Kleinschreibung (AshfordeOU), woran die sigstore-Provenienzprüfung von npm scheiterte (sie vergleicht den Eigentümer unter Beachtung der Groß-/Kleinschreibung). Das Manifestfeld repository ist jetzt das kanonische ashfordeOU in Kleinschreibung, sodass die erzeugte package.json zum Provenienzsubjekt passt und das npm-Release veröffentlicht wird.

Geändert#

• Der Wheel-Build legt codegen-units = 1 fest, damit das manylinux-Wheel über Neubuilds hinweg byte-reproduzierbar ist (die Reproduzierbarkeitsprüfung per Neubau und Diff).

0.22.0 - 2026-06-29#

Ein Konsolidierungs-Release mit Schwerpunkt auf Evidenz, Herkunft und Disziplin bei der Verteilung. Die maschinell geprüfte Validierungsmatrix wächst auf 39 VALIDATED · 46 MODELLED · 4 PARTNER über ihre 89 Zeilen (zuvor 15 · 42 · 4 über 61), getragen von der Kreuzvalidierung modellierter Fähigkeiten gegen unabhängige externe Referenzen. Jedes verteilte Artefakt trägt jetzt eine kryptografische SLSA-Build-Provenienzbescheinigung, liefert ein CycloneDX-SBOM mit und wird im Gleichschritt über alle Oberflächen veröffentlicht. Keine numerische Modellaussage wird ohne externen Datensatz dahinter hochgestuft; neue Fähigkeiten bleiben ehrlich MODELLED.

Hinzugefügt#

• Lagedynamik (src/attitude_dynamics.rs, MODELLED): momentenfreie Eulergleichungen des starren Körpers + Quaternionenkinematik (RK4), mit Selbsttests der Erhaltungssätze (Quaternionennorm, kinetische Energie, |Iω|, Präzession des symmetrischen Kreisels).
• Kreuzvalidierung modellierter Fähigkeiten gegen unabhängige externe Referenzen, womit die Validierungsmatrix auf 39 Zeilen VALIDATED kommt, jede durch einen externen Datensatz gestützt (das Ehrlichkeits-Gate der CI verbietet den Status VALIDATED ohne einen solchen). Die neuesten Validierungen gegen externe unabhängige Referenzen: die gemessene Stabilitätskurve optischer Uhren (der ADEV-Kurvenfit von quantum_trade reproduziert das veröffentlichte σ_y(τ) der ⁸⁸Sr-Optischen-Gitteruhr von Norcia et al., Science 366:93 (2019), Zenodo 10.5281/zenodo.3382347, CC-BY-4.0, unter tests/fixtures/optical_clock_adev/ mitgeliefert); die Erzeugung des GPS-L1-C/A-Spreizcodes (das G1/G2-LFSR von src/sdr.rs reproduziert die Oktalwerte der Codephase aus IS-GPS-200 Tabelle 3-Ia für PRN 1–9); und der SRTM-Höhenmodell-Leser auf realem Gelände (src/altpnt/terrain.rs liest eine mitgelieferte gemeinfreie NASA/USGS-SRTM-v3-Kachel, N36W117 / Death Valley, und platziert Badwater Basin innerhalb seines dokumentierten Vermessungsbandes).
• Neue Fähigkeiten MODELLED, jede intern gegen eine geschlossene Form oder einen Schwesterpfad im Code gegengeprüft: Relativbewegungsdynamik nach Clohessy–Wiltshire / Hill, passive Emitterlokalisierung per TDOA/FDOA, Lagebestimmung nach Wahba/TRIAD/QUEST, Auflösung ganzzahliger Mehrdeutigkeiten der GNSS-Trägerphase (LAMBDA), B-Plane-Targeting & Gravity-Assist nach Patched-Conic, CRPA-Anti-Jam-Array-Beamforming, GNSS-Square-Law-Akquisitionsstatistik, Fringe-Mehrdeutigkeit / Dynamikbereich quanteninertialer Sensoren, IEEE-1139-Potenzgesetz-Uhrenrauschen + Flicker-FM-Untergrenze und Austausch von CCSDS-OEM-Kovarianzblöcken.
• Evidenzregister aus einer einzigen Quelle mit erzeugter Verifikationsdokumentation und einem Wächter gegen Abweichung; ein durchsuchbares Validierungsregister auf kshana.dev mit Tiefenlinks zur Evidenz je Karte.
• Maschinenlesbare Zitiermetadaten: codemeta.json (CodeMeta 2,0) und .zenodo.json, durch tests/citation_metadata_doc_sync.rs an das Cargo-Manifest gebunden.
• Herkunft der Lieferkette: SLSA-Build-Provenienzbescheinigung für Crate-Tarball, Wheels, sdist und npm-Tarball; PyPI-OIDC-Trusted-Publishing; CycloneDX-SBOM, mitgeliefert im Wheel und im npm-Paket; Diff für reproduzierbare Builds und Verifikation nach dem Release.
• Auffindbarkeit: robots.txt, sitemap.xml und Open-Graph-/JSON-LD-Metadaten auf kshana.dev; eine erzeugte Abbildung validation-breakdown, aus der Matrix abgeleitet.
• READMEs je Oberfläche für crates.io / PyPI / npm mit einem Wächter für die Ehrlichkeit der Zählung.

Geändert#

• Die unabhängige Referenz für Sagnac-Zeitübertragung wurde auf ExternalDataset hochgestuft: Die Sagnac-Korrektur für die äquatoriale Erdumrundung wird jetzt gegen Ashbys veröffentlichte 207,4 ns geprüft (Living Reviews in Relativity 6:1, 2003, Gl. 1,29; auf < 0,05 ns reproduziert). Die zusammengesetzte Fähigkeit der Zeitübertragung bleibt ehrlich MODELLED.
• Dokumentation, Diagramme und Abbildungen aktualisiert auf die aktuelle Matrix (39/46/4/89): das Diagramm der Validierungsherkunft, die Abbildung oracle-kind-stacked (jetzt aus der Matrix erzeugt, mit einem CI-Wächter gegen Abweichung), VALIDATION/PROVENANCE/CAPABILITY/QUANTUM-MODELS/WHEEL_TAGS, die Architektur- und Tutorial-Dokumente sowie die Gesamtzahl im Register auf kshana.dev.
• Der Quellbaum wurde mit dem festgelegten rustfmt (Toolchain 1.93.0) neu formatiert: reine Formatierung, keine Verhaltensänderung.
• Versionierung im Gleichschritt. Jede Verteilungsoberfläche (Crate, PyPI, npm, MCP-Crate + OCI-Image, JetBrains-Plugin) wird jetzt im Gleichschritt mit der Engine versioniert, in der CI durch scripts/check-version-sync.sh erzwungen.
• Das JetBrains-Plugin wurde auf AGPL-3.0-only umlizenziert (die veröffentlichte Version 0.1.1 wies noch Apache-2.0 aus) und leitet seine Marketplace-Version jetzt aus dem Release-Tag ab.
• Härtung der Robustheit: Nicht-Test-unwraps entfernt oder begründet; clippy::unwrap_used für Nicht-Test-Code als Gate gesetzt.
• kshana.dev, Überarbeitung nach dem Grundsatz Beleg zuerst: dominanter Hero-Bereich, Architekturdiagramme und Ergebnisabbildungen, i18n, einklappbare/responsive Abschnitte für Register und Standards.

Behoben#

• Präzise SP3-Ephemeride: Die IGS-Knotenkorrektur der Erdrotation wird bei der Interpolation angewendet.
• Registry-Bilder: Die READMEs für PyPI/crates.io/npm verwenden absolute Bild-URLs; die relativen Bildpfade des Haupt-README wurden auf der PyPI-Seite 0.21.0 als defekte Bilder dargestellt. Ein CI-Wächter (tests/surface_readme_image_urls_doc_sync.rs) verhindert den Rückfall.
• CI: fmt + clippy grün; nicht mehr gegen per Git ignorierte reale Daten kompilieren.

Tests#

• Die Kalman-Uhrenkovarianz bleibt positiv semidefinit und symmetrisch (Eigenschaftstest, tests/property.rs).
• Doc-Sync-Wächter: Jeder öffentliche String mit Validierungszahlen, die Zitiermetadaten, die erzeugte Abbildung und die Bild-URLs der READMEs je Oberfläche sind alle an ihre maßgebliche Quelle gebunden.

0.21.0 - 2026-06-26#

Dieses Release fügt der offenen Engine zwei Anwendungssuiten der Stufe MODELLED hinzu: einen Demonstrator für quantengestützte PNT (vertrauenswürdige Quanten-Zeitübertragung, GNSS-freie Quantennavigation, Quanten-Fehler-/Anomalieerkennung) und eine PNT-Suite für Mond / cislunaren Raum (Mond-Koordinatenzeit, Mond-VLBI, gemeinsame OD+Uhr, Frame-Realisierung, Service-Volume, differenzielle PNT, Interoperabilitätsexport), jede aus einem einzigen kind ausführbar und jede mit einem ehrlichen TradeEvidence-Datensatz sowie einem Register zu Repräsentativität / Lücken bis zum Flug. Es bringt außerdem sechs neue Validierungen gegen externe unabhängige Referenzen und erhöht damit die maschinengeprüfte Validierungsmatrix auf 15 VALIDATED · 42 MODELLED · 4 PARTNER in ihren 61 Zeilen. Die neuen Anwendungszahlen sind MODELLED und stammen aus illustrativen Parametern öffentlicher Quellen, ohne TRL, Flugerfahrung, Zertifizierung oder Billigung durch eine Agentur; die validierten Kerne, die sie wiederverwenden, sind als solche gekennzeichnet.

Hinzugefügt#

• Demonstrator-Suite für quantengestützte PNT (quantum-time-transfer, quantum-gnss-free-nav, quantum-anomaly-detect). Drei lauffähige Anwendungsbereiche (MODELLED) hinter der Engine, jeder mit Ausgabe von TradeEvidence plus einem Datensatz zu Repräsentativität / Lücken bis zum Flug:
  • Vertrauenswürdige Quanten-Zeitübertragung (src/timetransfer_chain.rs): ein Zweiwege-Budget aus optischer Gitteruhr + photonischer Strecke gegenüber CSAC + HF, das das Schutzniveau der Zeitgebung wiederverwendet, mit einem Sicherheitsgütemaß gegen Verzögerungs-/Replay-Angriffe (1 − P_md) und Uhrenanomalie-Erkennung + CUSUM-Latenz.
  • GNSS-freie Quantennavigation (src/quantum_nav_od.rs): ein Kaltatom-Interferometer im inertialen Auslauf gegenüber einem INS der Navigationsklasse über einen GNSS-Ausfall, mit dem ehrlichen Hinweis, dass ohne externe Lösung der Beschleunigungsmesser-Bias unbeobachtbar bleibt und der Fehler deshalb weiter wächst.
  • Quanten-Fehler-/Anomalieerkennung (src/quantum_faults.rs): ein gelabelter Fehlerkatalog mit einer ROC-AUC mit Bootstrap-Konfidenzintervall und einem minimal erkennbaren Fehler bei fester Falschalarmrate.
  • Eine gemeinsame Bibliothek von Fehlermodellen für Quantengeräte (src/quantum_devices.rs) und ein einheitliches Trade-Harness Quanten gegen klassisch (src/qtrade.rs) bilden die Grundlage aller drei.
• PNT-Suite für Mond / cislunaren Raum. Sieben lauffähige kinds (MODELLED), aufgesetzt auf den CR3BP-Kern: Mond-Koordinatenzeit (säkulare Rate LTC/TCL − TT, src/lunar_time.rs), geodätische Mond-VLBI-Verzögerungsobservable (src/lunar_vlbi.rs), gemeinsamer Batch-Estimator für Multitechnik-OD + Uhr (src/lunar_combination.rs), Realisierung des Bezugssystems (7-Parameter-Helmert + IAU-2015-WGCCRE-Anbindung, src/lunar_frame_realise.rs), Analyse des Service-Volume der Klasse Moonlight / LCNS (src/lunar_service.rs), differenzielle PNT auf dem Mond (src/lunar_dpnt.rs) und ein an LunaNet / IOAG ausgerichteter Interoperabilitätsexport (CCSDS-OEM + lunare Zeitskala im KIF-Umschlag, src/lunar_interop.rs). Alle MODELLED aus illustrativen Parametern öffentlicher Quellen; nicht gegen reale VLBI- / Gateway-Verfolgung validiert; keine Zugehörigkeit zu und keine Bestätigung durch eine Behörde.
• Sechs neue Validierungen gegen externe unabhängige Referenzen (die Validierungsmatrix steht jetzt bei 15 validierten):
  • ADEV / HDEV an einer realen 5071A-Cäsiumuhr: validiert gegen die Dekadenpunkt-Referenzen von Stable32 (tests/cs5071a_reference.rs).
  • OADEV / MDEV / TDEV an der Stable32-Referenz PHASE.DAT: validiert gegen die veröffentlichten Tabellen von Stable32 (tests/phasedat_reference.rs).
  • ROC-AUC der Anomalieerkennung an realer ESA-OPS-SAT-Telemetrie: validiert gegen scikit-learn (tests/opssat_ad_reference.rs).
  • ICGEM-Synthese von Schwerefeldfunktionalen: validiert gegen den GRS80-Normalschwerestandard (Somigliana-γ auf 3.5e-12; EGM2008-Störungskarte, tests/icgem_gravity_reference.rs).
  • Klobuchar-Broadcast-Ionosphärenmodell: validiert gegen RTKLIB (tests/klobuchar_reference.rs).
  • RAIM-Detektionskern (171 Fälle, tests/raim_reference.rs) und das SBAS-DO-229E-Schutzniveau an realen EGNOS-Daten (RTKLIB-SBAS-PL-Fork, tests/sbas_reference.rs): beide validiert gegen ihre externen unabhängigen Referenzen.
• Register zu Repräsentativität & Lücken bis zum Flug (src/representativeness.rs). Ein strukturierter Datensatz, den jeder Demonstrator ausgibt: was repräsentativ ist, was vereinfacht ist und was zwischen dem Modell und dem Flug steht, der ehrliche Begleiter jedes Trades der Stufe MODELLED.
• Studienaggregation & CLI-Ergonomie. Ein Manifest für Szenariosuiten mit Studienaggregation per Einzelbefehl, hash-stabile Studienmetadaten + --study-name, Linting von Szenarien mit --validate und Ausweis der Validierungsstufe je Gütemaß in Studienberichten.

Geändert#

• kshana.dev neu gestaltet um ein gemeinsames Domänenrückgrat: Fähigkeiten und Validierung zu einem Domänen-Explorer mit gemeinsamem Vokabular zusammengeführt, die neuen validierten Inseln ausgewiesen, ein landgenaues animiertes Erdinstrument und ein CTA zur Studienanfrage sowie das Branding und die Links von Ashforde OÜ.
• README + ARCHITECTURE auf Vollständigkeit und Ehrlichkeit geprüft: veraltete Zahlen validierter Fähigkeiten korrigiert (jetzt 15 externe unabhängige Referenzen), die Diagramme erweitert, und die Preprints zum Conditional Timing Protection Level (arXiv:2606,24210) und zur Optimismuslücke bei HF-Beeinträchtigungen (arXiv:2606,22054) zitiert.
• Die Quellen in paper/ und die JOSS-Entwurfspipeline werden im öffentlichen Repository gehalten.

0.20.0 - 2026-06-22#

Dieses Release fügt der offenen Engine vier Studienfähigkeiten hinzu: ein bedingtes Timing Protection Level, eine am Rahmenwerk ausgerichtete Bewertung der PNT-Resilienz, eine Bewertung der Optimismuslücke bei HF-Beeinträchtigungen und ein Frontend für Software-Defined-Receiver / reale Daten, jede aus einem einzigen Befehl reproduzierbar und mit byte-deterministischem Artefakt. Alle Studien sind MODELLED (synthetische oder auf öffentlichen Datensätzen kalibrierte Daten), tragen ihre ehrliche Herkunft (Engine-Version, Seeds, Konfigurations-Hash) und Validierungslabels und sind keine Zertifizierungen.

Hinzugefügt#

• Bedingtes Timing Protection Level (tpl). Eine durch Holdover begrenzte Schranke des unerkannten Zeitfehlers bei GNSS-Spoofing, mit einer k-Sigma-Untergrenze des Monitors, einer Coast-Varianz nach van Loan über die Detektionslatenz und einer CUSUM-Zeit bis zum Alarm. Kalibriert an einem realen aufgezeichneten Angriff (JammerTest 2024, Szenario 2.1.1) über cargo run --release --example tpl_jammertest, das seine Referenztabelle aus Skalaren reproduziert, die aus der öffentlichen Aufzeichnung gewonnen wurden (der Rohdatensatz wird nicht weiterverteilt).
• Am Rahmenwerk ausgerichtete Bewertung der PNT-Resilienz + Studie zur Entscheidungsinstabilität (resilience). Architekturmodell, an RPCF ausgerichtete Bewertung, Dirichlet-Gewichtungssimplex, Instabilität nach Kendall-Tau und Top-1-Flip-Rate sowie Zusammenbruch der Gleichtaktdiversität (Hill-N2), mit cargo run --release --example resilience_report -- paper-artifacts/resilience-study.json. Zuordnungstabelle in docs/RESILIENCE-CROSSWALK.md.
• Studie zur Optimismuslücke bei HF-Beeinträchtigungen (impairment_study, impairment_ml, eval_stats). Ein Panel aus 13 Detektoren über einem parametergestützten synthetischen Korpus, eine Optimismuslücke zwischen In- und Out-of-Distribution, Skalierungsgesetz-Trends mit einer Permutations-Nullhypothese und ein Leave-one-out-Prädiktor der Degradation, über cargo run --release --example optimism_study -- paper-artifacts/optimism-study.json.
• Frontend für Software-Defined-Receiver (sdr) und Adapter für reale Daten (realdata/). Roh-IQ/IF bis zu Korrelator-Taps und SQM, dazu Einlese-Adapter (RINEX, u-blox UBX, GnssLogger, JammerTest, Yunnan, SatGrid) und Beispiele zur Sondierung. Diese lesen Aufzeichnungen, die der Nutzer lokal bereitstellt; es werden keine Aufzeichnungen eingecheckt.
• Eingecheckte Studienartefakte. Die byte-deterministischen Dateien optimism-study.json und resilience-study.json werden jetzt unter paper-artifacts/ versioniert, sodass die Studienzahlen ohne Neubau geprüft werden können; sie bleiben aus den obigen Generatoren neu erzeugbar. Rohdatensätze bleiben außerhalb des Repositorys (/realdata-cache/).

Geändert#

• Version auf 0.20.0 angehoben in Cargo.toml, CITATION.cff und README; die Studienartefakte zum Crossover sind neu erzeugt, damit ihr Stempel zur veröffentlichten Version passt.

0.19.0 - 2026-06-18#

Geändert#

• Umlizenziert von Apache-2.0 auf die GNU AGPL-3.0-only, mit einer von Ashforde OÜ erhältlichen kommerziellen Lizenz (Dual-Licensing). Die offene Engine bleibt vollständig offen und öffentlich verifizierbar; das Netzwerk-Copyleft der AGPL (§13) bedeutet, dass eine geschlossene oder gehostete abgeleitete Fassung zu Open Source zurückkehren muss, oder eine kommerzielle Lizenz erwerben. Dies schützt den validierten Kern vor Fork-und-Schließen und wahrt zugleich die Glaubwürdigkeit einer öffentlichen, ausführbaren, prüfbaren Engine. Siehe LICENSE (AGPL) und das neue LICENSING.md (was jede Lizenz abdeckt und wann sie gilt).
  • LICENSE enthält jetzt den Text der AGPL-3.0; die SPDX-Header in allen Quellen sind auf AGPL-3.0-only aktualisiert; NOTICE, README, GOVERNANCE, GLOSSARY, die Website und die Crate-/Paketmetadaten (Cargo.toml, pyproject.toml, CITATION.cff, das MCP-Crate + Image) wurden entsprechend aktualisiert.
  • Die Beitragsbedingungen (CONTRIBUTING.md) lizenzieren eingehende Beiträge jetzt unter der AGPL und räumen Ashforde OÜ das Recht ein, Beiträge in die kommerziell lizenzierte Edition aufzunehmen, damit das Dual-Licensing weiter funktioniert.
  • Abhängigkeitsrichtlinie unverändert, aber neu begründet (deny.toml, GOVERNANCE): Abhängigkeiten bleiben permissiv (Apache/MIT/BSD/ISC). AGPL ist nur für das eigene Crate von kshana erlaubt: Eine Copyleft-Abhängigkeit würde die kommerzielle Edition infizieren und das Dual-Licensing brechen.
  • Hinweis für nachgelagerte Nutzer: Dies ist eine Copyleft-Umlizenzierung. Nutzer, die sich auf die permissiven Bedingungen von Apache-2.0 verlassen haben, können das letzte Apache-2.0-Release weiterverwenden (v0.18.0 und früher, wie veröffentlicht); ab v0.19.0 gilt AGPL-3.0 / kommerziell.

Sicherheit#

• pyo3 von 0,24 auf 0,29 angehoben, um RUSTSEC-2026-0176 / RUSTSEC-2026-0177 (GHSA-36hh-v3qg-5jq4 / GHSA-chgr-c6px-7xpp) aus externen OSV-/Abhängigkeitsscans zu beseitigen. Beides sind Hinweise auf Funktionsebene, deren betroffene Funktionen (BoundList/TupleIterator::nth/nth_back, PyCFunction::new_closure) Kshana nie aufruft, und pyo3 ist eine optionale Abhängigkeit (Feature python), die tatsächliche Gefährdung war also null; die Anhebung hält aber den Scan für nachgelagerte Auditoren sauber. src/python.rs wurde auf die API von pyo3 0,29 migriert (Bound-Rückgabetyp für scenario_kinds; explizites skip_from_py_object an der pyclass RunOutput). Alle 11 Python-Binding-Tests bestehen gegen die neu gebaute Erweiterung.

0.18.0 - 2026-06-17#

Hinzugefügt#

• Elf neue lauffähige Szenarioarten: Demonstratoren mit zwei Ausschreibungen, eine CCSDS-Interop-Brücke und eine Suite für Missionsanalyse / Umgebung in erster Ordnung (alle MODELLED, additiv; bestehende Reproduzierbarkeits-Goldens unverändert). Jede ist per CLI / Python / WASM / MCP aufrufbar, liefert ein scenarios/<kind>.toml mit und trägt ein ausdrückliches Label MODELLED in ihrem Ergebnis-JSON und in der einzeiligen Zusammenfassung (ein Test je Art in tests/dominance_demonstrators.rs prüft, dass das Label vorhanden ist und dass die Ausgabe nie den String VALIDATED enthält):

  • impairment-eval (src/impairment_eval.rs): Testumgebung zur Bewertung maschineller Lernverfahren zur Erkennung von HF-Beeinträchtigungen: ein gelabelter synthetischer Korpus + ein detektorunabhängiges ROC/AUC-Harness + ein Bericht zur Optimismuslücke zwischen In- und Out-of-Distribution (nur Betriebskennlinien, nie Feld-/IQ-Daten).
  • quantum-trade (src/quantum_trade.rs): Trade PNT Quanten gegen klassisch mit Einlesen gemessener ADEV und einer Resilienzhülle für GNSS-verweigerte Umgebungen.
  • space-weather (src/space_weather.rs): solare/geomagnetische Indizes (Kp↔ap-Tabelle der IAGA, tägliches Ap, zentriertes 81-Tage-F10.7a), exosphärische Temperatur nach Jacchia-71 und eine aktivitätsgetriebene Kopplung der thermosphärischen Dichte über einer statischen Atmosphäre (KEIN Modell absoluter Dichte nach NRLMSISE).
  • oem-interop (src/oem.rs): Import + Round-Trip-Brücke für CCSDS-502,0-OEM für Ephemeriden aus GMAT / Orekit / STK (der Leser parse_oem, exakte Umkehrung des Schreibers).
  • launch-window (src/launch.rs): Startazimut im Zweikörperproblem (sin Az = cos i/cos lat), Δv für Ebenenwechsel, Bonus durch die Rotation des Startplatzes und Geometrie der täglichen Startgelegenheiten.
  • reentry (src/reentry.rs): ballistischer Wiedereintrittskorridor nach Allen-Eggers: maximale Verzögerung, Geschwindigkeiten bei Spitzen-g und Spitzenheizung, Höhe bei Spitzen-g.
  • eo-coverage (src/eo_payload.rs): Geometrie von EO-Streifenbreite / GSD / Zugriff / Wiederkehr (SMAD-Raumdreieck).
  • space-packet (src/space_packet.rs): Kodierung/Dekodierung des Primary Header des CCSDS-133.0-B-Space-Packets mit bitgenauem Round-Trip.
  • attitude-budget (src/attitude_budget.rs): 3-DOF-Gravitationsgradientenmoment + RSS-Budget des Ausrichtungsfehlers (skalares Budget vor der Hardware, keine Regelschleife).
  • passes (src/passes.rs): Vorhersage von Auf-/Untergangsüberflügen für Bodenstationen (AOS/TCA/LOS, maximale Elevation, Zugriff).
  • link-budget (src/linkbudget.rs): Einweg-Linkgleichung nach CCSDS-401 / DSN-810-005 (C/N₀ = EIRP − FSPL − L_other + G/T − k, FSPL / Eb·N₀ / Marge / Schließung).

• Hybrider eng gekoppelter UKF mit 17 Zuständen aus Quanten- und klassischen Sensoren, als lauffähiges Szenario ausgewiesen (MODELLED). Eine neue Szenarioart hybrid-ukf (src/fusion/hybrid_ukf.rs, scenarios/hybrid-ukf.toml), die den bisher nur über die API nutzbaren eng gekoppelten GNSS/INS-Unscented-Filter mit 17 Zuständen (src/fusion/tightly_coupled17.rs) zu einem Szenario macht, das die Bindings für CLI/Python/WASM/MCP aufrufen können. Der Fehlervektor mit 17 Zuständen besteht aus den 15 INS-Fehlerzuständen (Position, Geschwindigkeit, Lagefehlausrichtung, Beschleunigungs- + Gyro-Bias), ergänzt um die aus dem CAI abgeleitete Korrektur des Beschleunigungsmesser-Bias (das Kaltatom-Interferometer (src/inertial/quantum_imu.rs) legt die Untergrenze der Geschwindigkeits-Zufallsbewegung q_va fest, sodass die langfristige Coast-Drift die durch den Quantensensor begrenzte ist), und eine Uhr mit 2 Zuständen für Phase + Frequenz, deren Prozessrauschen aus der Uhren-Engine mit q-Parametern stammt (clock_state::q_from_allan, die das Allan-Abweichungsprofil einer Uhr auf die PSDs q_wf/q_rw abbildet, skaliert auf Entfernungseinheiten). Die Plattform wird für einen Vorlauf durch GNSS gestützt (der Filter lernt Biases, Geschwindigkeit und Uhr), läuft dann durch einen GNSS-Ausfall allein auf dem CAI-IMU + der Uhr aus, sodass der Lauf die Hybridisierung klassischer IMU kurzfristig + Quanten langfristig zeigt. Das Gütemaß ist die Selbstkonsistenz des Filters: gepoolte NEES (Normalised Estimation Error Squared, über die schätzbare Teilmenge aus Position/Geschwindigkeit/Uhr) und NIS der Innovationsweißheit (Normalised Innovation Squared) über ein Monte-Carlo-Ensemble, geprüft gegen ihre 95-%-χ²-Bänder (Bar-Shalom §5,4). Der angepasste Filter liegt innerhalb der Bänder; ein absichtlich falsch abgestimmter Filter (die Stellgrößen q_factor / r_factor) wird markiert: ein objektiv prüfbares, trennscharfes Gate, kein Abnicken. Die Prüfung von NEES/Innovationsweißheit ist die STATISTISCHE UNABHÄNGIGE REFERENZ: eine Aussage zur Selbstkonsistenz (die vom Filter gemeldete Kovarianz stimmt ehrlich mit der Streuung seiner eigenen Fehler unter dem modellierten Rauschen überein), KEINE Garantie realer Genauigkeit. Ehrlicher Geltungsbereich: Alles ist modelliert / Simulation: Die Eingaben für CAI und Uhr sind eingegrenzte, für die Literatur repräsentative Werte, keine gemessene Hardware; die CAI-Hardware und ihre Schlüsselperson bleiben beim Partner; nichts hier impliziert TRL > 3, Flugerfahrung oder externe Validierung (das Ergebnis-JSON und die einzeilige Zusammenfassung tragen diese Labels ausdrücklich). Die einzelne ebene Trajektorie mit konstanter Geschwindigkeit lässt die Zustände für Lage und IMU-Bias nur schwach beobachtbar, daher wird NEES über die 8 schätzbaren Zustände bewertet; eine Trajektorie mit Manövern für volle Beobachtbarkeit aller 17 steht auf der Roadmap. Ergänzt außerdem Ukf::update_stats (liefert den NIS je Update) und die Konsistenzinstrumentierung TightlyCoupled17::{update_gnss_nis, nees, nees_subset}. Alle bestehenden Szenarien sind unberührt (additiv; Reproduzierbarkeits-Goldens unverändert).

• Sequenzielle (rekursive) geländegestützte Navigation: SITAN als laufender Filter. Eine neue Szenarioart terrain-slam (src/altpnt/sequential.rs, scenarios/terrain-slam.toml), die das bestehende Messmodell Höhenmesser gegen DEM Epoche für Epoche durch die SIR-Engine particle_filter laufen lässt, statt der gestuften Batch-Suche von grob zu fein, mit der terrain-nav einen einzelnen konstanten INS-Versatz wiedergewinnt. An jedem Wegpunkt wird die Wolke um das vom INS gemeldete Inkrement fortgeschrieben (selbst durch das Driftwachstum je Schritt verfälscht), durch den Geländeabgleich neu gewichtet und bei Degeneration neu abgetastet, sodass eine zeitvariable INS-Drift entlang der Spur verfolgt wird, was eine Anpassung mit konstantem Versatz strukturell nicht kann. Auf dem synthetischen DEM bleibt die rekursive Schätzung beschränkt und konvergiert erneut (am Ende ≈ 70 m), während die ungestützte inertiale Lösung unbegrenzt auf ≈ 5 km divergiert; der Fehler je Epoche folgt der Eindeutigkeit des Geländes (über flachen Sätteln läuft sie auf dem verzerrten INS aus und rastet über markantem Relief wieder ein), und der Monitor der effektiven Stichprobengröße bestätigt eine gesunde Wolke. Ehrlicher Geltungsbereich: Die Karte ist bekannt und fest, es ist rekursive Lokalisierung gegen ein gespeichertes DEM (die Lokalisierungshälfte von Gelände-SLAM), keine gemeinsame Kartenschätzung; nicht zirkulär per Konstruktion (die eingespeiste Driftrampe ist die unabhängige Wahrheit). Alle bestehenden Szenarien sind unberührt (additiv; Reproduzierbarkeits-Goldens unverändert).

• Resilienzrückgrat bei GNSS-Verweigerung + Demonstrator-Slices für FutureNAV (src/holdover.rs sowie Grundlagen der Resilienzhülle unter src/impairment_eval.rs, src/quantum_trade.rs, src/navsignal.rs, src/inertial/quantum_imu.rs, mit Verifikations-Slices für FutureNAV in src/verification.rs). Setzt die Bausteine alternativer PNT, nämlich Uhren-Holdover, Signalverfolgung, inertialen Auslauf und Gelände, zu einer einzigen Resilienzerzählung für GNSS-Ausfälle zusammen. MODELLED; additiv.

• Kshana Interchange Format (KIF): ein versionierter, selbstbeschreibender Artefaktumschlag (src/interchange.rs). Ein Schema-markierter Umschlag um Szenarioergebnisse, sodass ein gespeichertes Artefakt seine Art, seine Schemaversion und seine Labels MODELLED/VALIDATED mit sich führt und ältere Umschläge vorwärtskompatibel lesbar bleiben. Additiv; bestehendes Ergebnis-JSON unverändert.

• Modulation / Verfolgung von Navigationssignalen + CR3BP-Differentialkorrektor für Halo/NRHO (src/navsignal.rs, src/cr3bp.rs). Ein Modell der Modulation und Verfolgung von Navigationssignalen in erster Ordnung sowie ein Differentialkorrektor für das eingeschränkte Dreikörperproblem mit Kreisbahnen für Halo-/nahezu geradlinige Halo-Bahnen, ausgewiesen auf der bestehenden Achse Deep-Space-Fähigkeit. MODELLED.

• Auswertungsmodus für Verteilungsverschiebung + Regler der Schweregradskala des Korpus für impairment-eval (src/impairment_eval.rs). Ergänzt das Harness zur Optimismuslücke bei ROC/AUC um eine ausdrückliche Aufteilung In-/Out-of-Distribution und eine einstellbare Schweregradskala des Korpus (nur Betriebskennlinien, nie Feld-/IQ-Daten).

• ROI Kosten je Abdeckung + Abbildung der Integritätsauswirkung verpasster Detektionen (src/frugal.rs, src/integrity_impact.rs). Eine ROI-Sicht des frugalen Engineerings (Kosten je Abdeckungseinheit) und eine Abbildung von der Rate verpasster Detektionen auf die Integritätsauswirkung. MODELLED; additiv.

• Zitiertes Parameterblatt für das Fehlermodell des Kaltatom-Interferometers (CAI) (src/inertial/quantum_imu.rs). Ein mit Literatur belegtes, eingegrenztes Parameterblatt für das inertiale CAI-Modell: Die Eingaben sind zitiert, keine gemessene Hardware (keine Aussage zu TRL / Flug); es speist die Untergrenze der Geschwindigkeits-Zufallsbewegung von hybrid-ukf.

• Projekt-Governance. GOVERNANCE.md dokumentiert das Entscheidungsmodell und die Grenze zwischen offen und geschlossen; die Zeile Community/Governance der Capability-Map wechselt von none → partial, um dies abzubilden.

Behoben#

• Integritäts-Schutzniveau der ARAIM: nominaler Bias (b_nom) und σ_URA jetzt angewendet. Das MHSS-Schutzniveau subtrahiert jetzt je Fehlermodus die einseitige Projektion des nominalen Bias b_k = Σ_i |s_i|·b_nom und verwendet das Integritäts-Sigma σ_URA (verschieden vom Genauigkeits-Sigma σ_URE), das in der Integrity Support Message mitgeführt wird. Dies macht das Schutzniveau konservativer und normgerecht, und ändert daher die PL-Werte, die bestehende Integritätsszenarien melden. ISM/Szenario erhalten die Felder #[serde(default)] sigma_ura_m / b_nom_m, sodass Eingaben, die sie nicht setzen, das bisherige Verhalten behalten. Siehe docs/ARAIM_REFERENCE.md für die wiederhergestellte Formel b_k und den ehrlichen Implementierungshinweis.

• Konsistenz des Spoof-Monitors per χ². parity_raim_test verwendet jetzt den gemeinsamen Pfad des inversen χ² aus raim::chi2_quantile und beseitigt damit eine zweite abweichende χ²-Implementierung, sodass RAIM und der Paritäts-Spoof-Monitor bei ihren Schwellen übereinstimmen.

• gravity-map-nav an den CLI-Dispatcher angebunden. Das Szenario war bisher nur über die API erreichbar; es wird jetzt wie jedes andere Szenario als kind= aufgerufen.

• Genauigkeit von Dokumentation und Anzahlen. Die Anzahlen der Szenariotypen im README sind nun durch einen Test scenario_count_doc_sync an api::list_scenario_kinds().len() gebunden, sodass die dokumentierte Anzahl nicht mehr vom Dispatcher abweichen kann.

0.17.0 - 2026-06-14#

Hinzugefügt#

• PNT im tiefen Weltraum und auf dem Mars — offene radiometrische Navigations-Engine + GSE-Simulation. Eine neue, vollständig additive Fähigkeitsachse auf dem für die Erde validierten Kern (jedes bestehende Erd-Szenario ist byteidentisch — die Reproduzierbarkeits-Goldens bestehen unverändert ohne Neuerzeugung). Hinzu kommen: ein Mehrkörper-Dynamikkern (Body{mu, re, zonals, gravity, rotation, IAU-pole} mit tesseraler Schwerefeldbeschreibung nach Mars GMM-3, einem IAU-körperfesten Marsrahmen, einer austauschbaren Schnittstelle EphemerisProvider, Julianischen Daten in zwei Teilen mit Submikrosekunden-Auflösung und TT↔TDB); radiometrische Observablen (iterative Lichtlaufzeit + Shapiro-Verzögerung, Zwei-/Ein-/Dreiweg-Doppler und -Entfernung über die Moyer-Zweistrecken-Lösung, kohärente Transponder-Umkehr, regenerative/PN-Entfernungsmessung nach CCSDS 414, Δ-DOR nach CCSDS 506, Medien aus Solarplasma/Tropo-/Ionosphäre); Einlesen und Ausgeben von CCSDS-TDM (503); ein reduziert-dynamischer Square-Root-Information-Filter mit empirischen RTN-Beschleunigungen, einer Bordzeituhr mit drei Zuständen und einem Mars-Widerstandsmodell; ein gemeinsamer Schätzer für Ein- und Zweiweg-Fusion; die Szenariooberfläche mars-pnt (Relais-Konstellation + LMO/Transfer/Oberfläche) über CLI, Python, WASM, MCP und den Playground; und ein durchgängiger GSE-Leistungssimulator (Geometrie → Link-Budget → Observablen → SRIF → Kovarianz). Validierungsstufe — simulationsvalidiert: synthetische Closed-Loop-Bahnbestimmung (Mars-LMO ≈ 0,2 m) und analytische Selbstkonsistenz, wobei die sonnenzentrische Marsdynamik unabhängig gegen JPL DE440 gegengeprüft wurde (xval/anise-mars-od, kernel-gesteuert: 137 m bei 1-Tages-Bogen, das ehrliche Residuum der nicht modellierten n Körper). Die berichteten Genauigkeiten im tiefen Weltraum sind Simulations- bzw. Kovarianz-Gütemaße, keine Ergebnisse realer Missionen; die Validierung mit realen DSN/ESTRACK-Tracking-Daten bleibt auf der Roadmap. ANISE (MPL-2.0, edition-2024) ist auf ein vom Workspace ausgeschlossenes Crate für die Gegenprüfung beschränkt, sodass die Lizenzprüfung cargo deny und der MSRV-1.75-Job unberührt bleiben.
• Agenturgenaue Bodenspuren aus realer IERS-Erdorientierung. Das Szenario ephemeris nimmt ein optionales Feld eop_finals2000a entgegen — den eingebetteten Inhalt einer realen IERS-Datei finals2000A — und reduziert die Bodenspur über UT1−UTC und Polbewegung je Epoche, die daraus interpoliert werden (dieselbe EopSeries, die precise_od verwendet), und überschreibt damit die nominalen Skalare dut1_s/xp_arcsec/yp_arcsec. Die Daten reisen im Szenario mit, sodass der Lauf reproduzierbar bleibt und kein Dateisystem braucht (er funktioniert im WASM-Playground). Ein Flag kshana --eop <finals2000A> faltet eine reale Datei von der CLI aus in das Szenario ein. Damit wird die Asymmetrie geschlossen, dass nur precise_od reale Erdorientierungsdaten verarbeitete.

Behoben#

• Konsistenz des Bezugssystems bei der Entfernungsrate. Die Bodenstation wird nun über die exakte Umkehrung der Reduktion des Satelliten (frames::itrf_to_teme, die Polbewegung und die siderische Rotation rückgängig macht) in das Inertialsystem abgebildet, statt über eine für Polbewegung blinde GMST-Rotation, sodass beide Endpunkte dasselbe Bezugssystem teilen. Die Wirkung auf den berichteten Doppler liegt unter der Validierungsschwelle, doch sie beseitigt eine echte Unstimmigkeit des Bezugssystems und eine Übertreibung mit „exakt“ im Quelltext.
• carrier_hz wird geprüft. Eine Trägerfrequenz von null oder eine nicht endliche liefert nun einen Fehler, statt stillschweigend einen Doppler von null zu erzeugen (λ = c/Träger war dadurch unendlich geworden), passend zur bestehenden Absicherung von step_s.

0.16.0 - 2026-06-11#

Hinzugefügt#

• Validierung des Kraftmodells durch Ephemeridenanpassung, gegen reale Agenturprodukte gegengeprüft. Ein neuer Batch-Kleinste-Quadrate-Schätzer (src/precise_od.rs) mit variationeller Zustandsübergangsmatrix und Ausreißerbearbeitung, angetrieben von einem vollständigen Kraftmodell (PreciseForceModel: EGM2008-Geopotential, dritte Körper, feste + ozeanische + atmosphärische Gezeiten sowie empirische CPR-/2-per-rev-Beschleunigungen), gespeist von einem Parser für reale IERS-Erdorientierung finals2000A. Validiert gegen veröffentlichte Referenzbahnen: Galileo-MEO bis auf 13 cm nach der Anpassung, ESA Swarm-A LEO und LRO lunar (selenozentrisch, GRAIL-Schwerefeld, IAU-2015-Körperrahmen — reduziert-dynamisch 6,6 m, ehrlich über dem Zielwert von 5 m auf dem offenen Pfad; der Pfad ANISE/DE440 in DE-Güte, der ihn erreicht, ist ein vom Workspace ausgeschlossenes Crate).
• Szenario spoof-detect — ein integrierter mehrschichtiger Spoofing-Detektor, der RAIM-Parität je Epoche, AGC- und Signalqualitäts-Monitore (SQM) und eine fusionierte Entscheidung kombiniert und gegen die veröffentlichten Szenarioparameter von TEXBAT (Humphreys et al., ION GNSS 2012) validiert ist, einschließlich des trägerausgerichteten schwierigen Falls.
• Szenario ephemeris — Zustand, Bezugssysteme, Bodenspur und Doppler. Einen Satelliten propagieren (TLE→SGP4 oder eine analytische Bahn) und je Schritt den inertialen TEME- und GCRS-Zustand (Position und Geschwindigkeit), die erdfeste ITRF/ECEF-Position, die WGS-84-Bodenspur des Subsatellitenpunkts (Breite / Länge / Höhe) sowie Azimut / Elevation / Entfernung topozentrisch mit Entfernungsrate und Doppler von einer Bodenstation ausgeben. Erreichbar über CLI, Python, WASM und den MCP-Server und ausgeliefert als Voreinstellung „Ground track“ im Web-Playground, in dem die Spur über einer realen Weltkarte gezeichnet wird (Natural-Earth-Küstenlinien 1:110m, eingebettet — kein Netzwerk und keine externe Abhängigkeit).
• CCSDS-OEM-Export (--export-oem / export_oem = true) — die geschwindigkeitstragende Orbit Ephemeris Message, die von GMAT / Orekit / STK verarbeitet wird, gleichwertig mit den bestehenden Exportern für SP3 und OMM.
• Feste, ozeanische (FES2004) und atmosphärische (Ray 2001 S2) Erdgezeiten auf dem Geopotential (IERS Conventions Kap. 6), eingebunden in das Kraftmodell.
• ARM64-Wheels — der PyPI-Build erzeugt nun auch Wheels für Linux aarch64 (manylinux_2_28), macOS arm64 und Windows arm64.
• Erweiterter technischer Bericht (Preprint), aus dem README verlinkt, und das JOSS-Paper einreichbar gemacht (Autoren-ORCID, bei jeder Änderung in der CI zu PDF kompiliert).

Geändert#

• Bezugssysteme auf den Millimeter gegen veröffentlichte Vallado-Vektoren validiert. Die Reduktion TEME→PEF/ITRF, die vollständige CIO-Kette IAU 2006/2000A GCRS→ITRS und die Umrechnung ECEF→geodätisch WGS-84 sind nun am durchgerechneten Beispiel in Vallado et al. (AIAA 2006-6753) mit dessen IERS-EOP festgelegt, nicht mehr nur an interner Selbstkonsistenz.
• Unabhängige Gegenprüfungen der Zeitskalen. ERA und die Skalen UTC/TAI/TT stimmen mit hifitime auf < 1 µs überein, und die Planetenephemeride DE440 stimmt mit JPL Horizons überein (geozentrische Positionen von Mond/Sonne), beides als stets aktive CI-Gates.
• Der Web-Playground blendet den Tab der Gütemaße aus, wenn ein Ergebnis keine Zeilen mit Gütemaßen enthält, sodass reine Diagramm-Pakete (Ephemeride, RAIM, Spoof) mit ihrem Diagramm öffnen — bei der Ephemeride mit der Bodenspur — statt mit einer leeren Tabelle.
• Die geführten Schieberegler des Playgrounds und der Parameter-Sweep funktionieren nun für das Szenario Ephemeride / Bodenspur: Seine Stellgrößen (Breite / Länge der Station, Zeitschritt, Dauer, UT1−UTC) sind einstellbar, und ein Sweep kann die Überflug-Geometrie (maximale Elevation, maximaler Doppler, Höhe, Geschwindigkeit) über jede davon auftragen — z. B. maximale Elevation über der Breite der Station. Der Tab Sweep wird nun nur noch angezeigt, wenn ein Szenario tatsächlich durchgesweept werden kann, sodass kein Paket ein Bedienelement anbietet, das nichts darstellt.
• Die Näherung DUT1 ≈ 0 von SGP4 an der GMST-Aufrufstelle dokumentiert (ein Rotationsfehler von ≤ ~13″, deutlich innerhalb des eigenen Modellfehlers von SGP4) und CAPABILITY.md aktualisiert.

0.15.1 - 2026-06-09#

Hinzugefügt#

• Das JetBrains-Plugin Kshana — PNT simulator ist nun veröffentlicht und im JetBrains Marketplace akzeptiert. README, kshana.dev und die Distributionsdokumentation verlinken direkt darauf.

Behoben#

• Die Veröffentlichung in der MCP-Registry gelingt nun: Das Feld description in server.json lag über dem Limit der Registry von 100 Zeichen (HTTP 422). Es wurde gekürzt, und der Servername (sowie das Eigentümer-Label des Images) wurde an den kanonischen Namensraum io.github.ashfordeOU/kshana-mcp angeglichen.
• Die Veröffentlichung im JetBrains Marketplace gelingt nun: Die CI hatte dieselbe Plugin-Version erneut hochgeladen, die bereits manuell gelistet worden war, was der Marketplace ablehnt. Die Plugin-Version wird auf 0.1.1 angehoben, und die Idempotenz-Absicherung behandelt nun auch die Antwort „already contains version“ als erfolgreichen No-op.
• Cache-Busting für kshana.dev: Die versionsgestempelten Query-Strings von style.css/app.js folgen dem Release, sodass wiederkehrende Besucher stets den aktuellen Build erhalten.

0.15.0 - 2026-06-08#

Hinzugefügt#

• kshana-mcp — Kshana als Server für das Model Context Protocol (MCP) (mcp/kshana-mcp/). Ein eigenständiges, vom Workspace ausgeschlossenes Crate (das SDK rmcp ist edition 2024), das die validierte Engine KI-Agenten und -Assistenten — Cursor, JetBrains AI Assistant / Junie und jedem MCP-Client — über stdio zugänglich macht. Werkzeuge: run_scenario, list_scenario_kinds, validate_scenario, export_sp3, export_omm, jedes ein dünner Wrapper um kshana::api.
• JetBrains-IDE-Plugin (ide/jetbrains/). Rechtsklick auf ein Szenario .toml → Run Kshana Scenario; Gütemaße und Ergebnis-JSON werden in ein Kshana-Werkzeugfenster gestreamt. Reines Plattform-Plugin in Kotlin, kompatibel mit jeder JetBrains-IDE 2024,3+.
• Öffentliche Distribution + automatische Veröffentlichung je Release für beide:
  • kshana-mcp auf crates.io (cargo install kshana-mcp) über publish.yml.
  • kshana-mcp als OCI-Image für mehrere Architekturen auf ghcr.io (docker run ghcr.io/ashfordeou/kshana-mcp) über eine neue mcp-publish.yml.
  • kshana-mcp in die offizielle MCP-Registry über GitHub OIDC (ohne Secrets); der Registry-Eintrag (server.json) verwendet den OCI-Pakettyp mit einem per Label verifizierten Eigentümer.
  • das IDE-Plugin in den JetBrains Marketplace über publishPlugin (token-gesteuert, optionale Entwicklersignatur) bei jedem Release-Tag.

0.14.1 - 2026-06-08#

Hinzugefügt#

• Unabhängige Gegenvalidierung der Bezugssysteme mit ANISE/SPICE (xval/anise-frames/). Ein eigenständiges, vom Workspace ausgeschlossenes Crate prüft die CIO-Reduktion IAU 2006/2000A von kshana (kshana::cio::gcrs_to_itrs_matrix, GCRS→ITRS) gegen ANISE (die in reinem Rust gehaltene Neuimplementierung von NAIF/SPICE), das GCRF→ITRF93 aus earth_latest_high_prec.bpc von JPL rotiert, wobei dieselben IERS-Erdorientierungsparameter finals2000A beiden Seiten zugeführt werden, über acht vierteljährliche Epochen 2020–2023. Die beiden unabhängigen Realisierungen des Bezugssystems stimmen bis auf eine maximale relative Rotation von 0,028″ überein — ≤ 0,86 m am Boden, ≤ 0,93 m im LEO, ≤ 3,6 m in der GNSS-Bahn, womit die seit Langem bestehende ROADMAP-Gegenprüfung der Bezugssysteme mit „< 10 m“ mit großem Abstand erfüllt wird (sie ergänzt die bestehenden bitgenauen SOFA/ERFA-Anker, ersetzt sie aber nicht). Das Crate ist isoliert, weil anise + hifitime unter MPL-2.0 stehen bzw. edition-2024 sind und nie in den Abhängigkeitsgraphen des veröffentlichten Crates kshana, dessen Cargo.lock, die Lizenzprüfung cargo deny oder den MSRV-Build gelangen dürfen; ANISE ist mit default-features = false festgelegt. Enthalten sind ein Binary frame-xval (lädt die ~5 MB große BPC herunter, gibt eine Tabelle aus, schreibt report.{json,md}), ein Test-Gate, das sich bei fehlendem Kernel oder Netzwerk selbst überspringt, und ein optionaler CI-Job nur für workflow_dispatch (blockiert nie main). Dokumentiert in docs/VALIDATION.md (CIO-Zeile) und ROADMAP.md.

Behoben#

• Für Mobilgeräte geeigneter Playground. Horizontalen Überlauf von .panel des Playgrounds auf Smartphones behoben (ein CSS-Grid-Element mit dem Standardwert min-width: auto wurde ~100 px breiter als der Viewport dargestellt), über min-width: 0 und breitengesicherte Bedienelemente; sauber verifiziert bei 360 / 390 / 414 / 768 px. Die Aktionsschaltflächen „Pin to compare“ / „Download report“ ausgerichtet (gleiche Margin-Boxen in der Flex-Zeile). Ausführen-Schaltflächen, Schieberegler, Auswahlfelder und Navigationslinks auf dem Smartphone und auf Touch-Geräten auf das Touch-Target-Minimum von ~44 px nach WCAG 2.5.5 / Apple-HIG vergrößert, bei unveränderter Desktop-Größe.

0.14.0 - 2026-06-08#

Behoben#

• Robustheitshärtung aus einem adversarialen Battle-Test-Durchlauf. (1) sbas_protection_level weist nun nicht endliche Elevation/Azimut/Varianz sowie negative oder nicht endliche Kovarianzdiagonalen zurück (eine fast singuläre Geometrie, durch kleines σ hochskaliert, konnte zuvor das Absolut-Pivot-Gate passieren und ein NaN-VPL / ein absurdes HPL als gültiges Some zurückgeben — ein stiller Integritätsfehler). (2) Der numerische Propagator (propagate/propagate_dopri) bricht bei einem nicht endlichen Anfangszustand sicher ab, statt den adaptiven Regler endlos kreisen zu lassen. (3) Der Hilfsbaustein für DEM-Zellen löst bei einem Gitter mit einer einzigen Stichprobe (1×N) keine Panik mehr aus. (4) Der Azimut von lunar_look_angle wird strikt in [0, 360) gehalten. (5) SphericalHarmonicField::from_gfc weist nicht physikalische (NaN / nicht positive) Werte für GM/Radius zurück.

Hinzugefügt#

• Binary validation_report + Release-Artefakt: ein abhängigkeitsfreier Generator, der eine einseitige, druckfertige HTML-Validierungszusammenfassung erzeugt, die jede in der CI erzwungene Validierung (SGP4 666/666, EGM2008, bitgenaue Bezugssysteme, NIST Allan, IMU-Datenblätter, ARAIM/SBAS, Reproduzierbarkeit auf 3 Betriebssystemen, Abdeckung) ihrem Test und ihrer externen unabhängigen Referenz zuordnet. Der Release-Workflow erzeugt kshana-validation-summary.html und hängt sie (mit SLSA-Provenienz) an jedes getaggte Release an.
• numpy-Interop-pytest + Härtung der Wheels: tests/python/test_numpy_interop.py (in der CI ausgeführt) sowie ein festgelegter manylinux-Container und ein Verifikationsschritt auditwheel show im Wheel-Build.
• Tutorials & Lehre: docs/tutorials/ (drei durchgerechnete Tutorials, kommentierte Szenarien je Fachgebiet, Übungen der Stufen 1/2/3) mit tests/tutorials.rs, der jede zitierte Zahl an die tatsächliche Ausgabe der Engine bindet.
• Artefakte für externe Einreichungen (paper/, notebooks/, submissions/): ein Entwurf für ein JOSS-Paper, ein Notebook Quanten vs. klassisch und einreichfertige Kits für awesome-gnss / ESA Navipedia / NASA ASCL / ESA ESSR / ION/IAC sowie FUNDING.yml — die externen Schritte der Einreichung vorbereitet.
• Geländereferenzierte und kombinierte Alt-PNT-Navigation (Modul altpnt): ein TERCOM/SITAN-Geländeabgleich-Navigator über einem DEM (Loader für .hgt + Generator für synthetische Fixtures) und ein kombinierter GPS-verweigerter Navigator aus Schwere + Magnetfeld (IGRF) + Gelände, bereitgestellt als Szenariotypen terrain-nav und combined-altpnt. Validiert durch die Konvergenz des Geländeabgleichs (ein bekannter eingebrachter Versatz wird zurückgewonnen) und einen beschränkten Fehler des kombinierten Filters über ein GPS-verweigertes Fenster.
• LunaNet-LANS-Geometrie (lunar): benannte Standorte auf der Mondoberfläche (Apollo 11/15/16, Shackleton-Rand) mit maßgeblichen selenographischen Koordinaten, Blickwinkel von der Oberfläche (Az/El/Entfernung), Sichtbarkeit/Abdeckung und DOP des Standorts, validiert gegen den Mondradius, die veröffentlichten Standortkoordinaten und die Identität der radialen Elevation von 90° im Zenit.
• Geführter Browser-Playground: Schieberegler im geführten Modus, ein Ausgabebereich mit Tabs, ein Rundgang-Overlay beim ersten Start, Modi für Parameter-Sweep und Überlagerung mehrerer Läufe, eine abhängigkeitsfreie 3D-Bahnansicht per Canvas/SVG (das Orbit-Paket gibt nun additiv eci_track aus), ein Embed-/iframe-Modus und Download als HTML-Bericht — jeweils mit Node-Unit-Tests in der CI.
• Anhand von Datenblättern validiertes IMU-Fehlermodell (tests/imu_allan_spec.rs): ARW/VRW/Bias-Instabilität von ADIS16465/16488/16460 werden aus der synthetisierten Allan-Abweichung zurückgewonnen und gegen die Herstellerangaben geprüft (Identifikation nach NIST SP1065 / IEEE 952).
• Validierung der Allan-Schätzer nach NIST SP1065 (tests/allan_nist_sp1065_1000point.rs): Die vier Schätzer reproduzieren die veröffentlichten Referenzabweichungen für 1000 Punkte und die Konfidenzgrenzen aus Tabelle 32.
• SBAS / DO-229E-Schutzniveaus, ionosphärenfrei L1/L5 und eine DO-316-compliance-Zuordnung (Modul sbas). sbas_protection_level bildet die gewichtete Geometriematrix aus Elevation/Azimut jedes Satelliten und dem Fehlerbudget aus UDRE/GIVE/Flugzeug/Tropo, invertiert die Normalmatrix (gemeinsam genutztes orbit::invert4) und projiziert die Varianzen über die K-Faktoren aus DO-229E (PA 6.0/5.33, NPA 6,18) auf HPL/VPL. iono_free_l1l5 ergänzt die ionosphärenfreie GPS-L1/L5-Pseudostrecke (IS-GPS-705, γ₁₅ = 1.79327), validiert dafür, die unabhängige Ionosphärenverzögerung erster Ordnung der Engine aufzuheben. do316_compliance_map ordnet Anforderungen aus DO-316/DO-229E den umsetzenden Funktionen zu. Validiert gegen die geschlossenen Definitionen der K-Faktoren, die numpy-Referenzgeometrie inv(GᵀG) und die Kovarianzidentität über zwei Wege; der Gegenabgleich der veröffentlichten PL mit RTKLIB/gLAB ist als in Prüfung ausstehend in docs/COMPLIANCE.md dokumentiert.
• Vollständige tesserale Kugelflächenfunktions-Schwerefeld — das Feld EGM2008 bis Grad/Ordnung 70. Ein neues gravity_sh::SphericalHarmonicField wertet das Geopotential und seine Beschleunigung im erdfesten Bezugssystem aus vollständig normierten Koeffizienten C̄_nm, S̄_nm aus und nutzt die stabile normierte Legendre-Rekursion nach Holmes–Featherstone (eine Denormierung würde bei diesem Grad überlaufen). Die ausgelieferten Koeffizienten sind das NGA-Produkt EGM2008 (gemeinfrei, über ICGEM), gebündelt in egm2008_data.rs und bitgenau von tools/gen_egm2008.py aus der eingecheckten tools/egm2008_to70.gfc reproduziert; jedes ICGEM-Modell .gfc lässt sich über from_gfc laden. Validiert gegen drei unabhängige Referenzen: Kollaps zur Punktmasse (nur C̄00 = −μr/|r|³), ein reines Zonalfeld, das das bestehende forces::zonal_accel auf ~1e-9 reproduziert, und die analytische Beschleunigung, die dem Differenzengradienten des direkt aufsummierten Potentials auf <1e-6 entspricht.
• Allgemein-relativistische Lense–Thirring-Beschleunigung (Rahmenmitführung) (forces::lense_thirring_accel, IERS 2010 Gl. 10,12), der gravitomagnetische Term über die bestehende Schwarzschild-Korrektur hinaus, über ein neues Flag ForceModel::lense_thirring() in den numerischen Propagator eingebunden. Validiert als linear im Drehimpuls der Erde und um 1–2 Größenordnungen unterhalb des Schwarzschild-Terms, dem Bereich der Messungen von LAGEOS / Gravity Probe B.
• Ein Trait Propagator, der die analytischen und numerischen Bahnpropagatoren vereint. Der numerische Cowell-Propagator mit Kraftmodell ist nun ein gleichrangiger Partner von SGP4: Ein neuer Typ NumericalPropagator (Anfangszustand + ForceModel + Tolerance + Wahl zwischen Schrittverdopplung oder Dormand–Prince Integrator) und Sgp4 implementieren beide propagator::Propagator, dessen state_at(t_seconds) -> StateVector den inertialen TEME-Zustand in SI-Einheiten (m, m/s) zurückgibt, sodass beide hinter einer Box<dyn Propagator> austauschbar sind. Die SGP4-Implementierung ist die exakte Umrechnung km/min→SI der inhärenten Methode (durch einen Gleichheitstest verifiziert); die numerische Implementierung besteht über den Trait dasselbe Submeter-Gate mit exaktem Kepler, die beiden adaptiven Treiber stimmen überein, und ein PropagatorError macht den zugrunde liegenden SGP4-Code sichtbar.

0.13.0 - 2026-06-08#

Dieses Release schließt die größte Korrektheitslücke der Engine: Erdorientierung und Reduktion der Bezugssysteme erfolgen nun in Güte einer Referenzimplementierung (bitgenau gegen ERFA/SOFA validiert), der Integritätsstapel erhält ARAIM mit zwei Konstellationen auf realen GPS+Galileo-TLEs, und die Schichten für Propagation, Quantensensorik, Mond/cislunar und Geomagnetik werden alle vertieft — dazu eine typisierte Python-API, ein reichhaltigerer Browser-Playground und eine Reproduzierbarkeitsmatrix auf drei Betriebssystemen. Höhepunkte:

• Bezugssysteme, bitgenau. Vollständige Nutation IAU 2000A und 2000B, Präzession IAU 2006, die CIO-basierte Reduktion (X, Y, s) IAU 2006/2000A GCRS↔ITRS, Polbewegung nach IERS und Ausgabesysteme TEME→GCRS/ITRS — jeweils bitgenau gegen die Referenzroutinen von ERFA/SOFA validiert.
• ARAIM mit zwei Konstellationen (GPS + Galileo) auf realen TLEs, mit HPL/VPL, Ausgabe als Stanford-Diagramm und einer offenen docs/ARAIM_REFERENCE.md.
• Cislunares PNT: ein CR3BP-Propagator für Erde–Mond, die Bezugssysteme MCI↔MCMF, selenographische Koordinaten und ein lauffähiges Szenario zur LunaNet-Mondintegrität.
• Quantensensorik: Coriolis- und AC-Stark-Systematiken für das Kaltatom-Interferometer, ein Drift-Sweep und Validierung gegen das Budget von Freier (2016).
• IGRF-14, Hauptfeldmodell des Erdmagnetfelds, in sich geschlossen und validiert.
• Typisierte Python-API (PyO3 RunOutput/ScenarioMeta, .data(), scenario_kinds, validate_toml, Typ-Stubs) mit einem Wheel-Build in der CI sowie gleichrangiger GCRS/ITRS-Propagatorausgabe und CCSDS-OMM-Export.
• Glaubwürdigkeit & Reproduzierbarkeit: ein direkter Genauigkeitsvergleich von SGP4 mit dem unabhängigen Crate sgp4, ein Abdeckungs-Gate in der CI (~97 % der Zeilen in src/) und eine Reproduzierbarkeitsmatrix auf drei Betriebssystemen (ubuntu/macos/windows).

Geändert#

• Jedes Diagramm im Playground passt nun zum Design der Website. Alle zwölf SVG-Diagrammgeneratoren — das Ergebnis-/Holdover-Diagramm (src/report.rs + src/chart.rs), das Allan-Abweichungs-Diagramm (web/app.js) und jedes Szenariodiagramm (src/hybrid.rs, jamming.rs, timetransfer.rs, spoof.rs, raim.rs Stanford + Verfügbarkeit, lunar.rs, ensemble.rs, sweep.rs, gnss_sim.rs, fusion/pack.rs, inertial/mod.rs) — verwendeten kühle marineblaue Flächen (#0e131b), kühlgraue Achsen/Texte und eine unpassende Serienpalette aus Rot/Blau/Violett. Sie verwenden nun durchgehend die warme Graphitpalette: Flächen in --bg, warmes Raster in --line, Beschriftungen in --fg, mit einheitlicher Zuordnung der Serien — Quanten = Honiggold (--accent-bright), klassisch = warmes Bernstein (--partial), Spezifikation/Grenzwert = --crit. Sicherheitskodierte Ansichten behalten ihre Bedeutung: Das RAIM-Stanford-Diagramm bleibt grün (verfügbar) / bernsteinfarben (irreführend) / rot (gefährlich) / gedämpftes Stahlgrau (nicht verfügbar), und HPL/VPL erscheinen als Gold/Bronze.
• Diagramme beschreiben sich beim Speichern/Herunterladen nun selbst. Beide Diagramme tragen ihren Titel im SVG (der Titel des Allan-Diagramms + der Untertitel „lower is better“ standen zuvor nur als HTML um das Bild herum, sodass ein gespeichertes Bild keine Beschriftung hatte), und beide tragen eine Herkunftsfußzeile — Kshana v<version> · <scenario-hash> · kshana.dev —, sodass ein heruntergeladenes Diagramm für sich allein steht und reproduzierbar bleibt.
• Jedes Diagramm trägt nun die Herkunftsfußzeile. Die Fußzeile — Kshana v<version> · scenario <hash> · kshana.dev — wird zentral für alle Szenariotypen in api::run_toml aufgebracht (zuvor nur bei den Diagrammen für Holdover und Allan), sodass jedes gespeicherte oder heruntergeladene Bild — aus dem Playground, aus dem Export .chart.svg der CLI oder aus der HTML-Scorecard — seine Version, den Fingerabdruck des Szenarios und die Quelle erkennen lässt. Der Hash ist zur Klarheit mit scenario beschriftet und stammt, wo vorhanden, aus scenario_hash des Ergebnisses, mit einem Rückgriff auf den Quell-Hash bei den Integritäts-/Mondberichten. Was der Fingerabdruck ist und warum er da ist, steht im Abschnitt „Output“ des README und in docs/PROVENANCE.md.

Behoben#

• raim::chi2_quantile und der Stanford-Rauschsampler von RAIM sind bei Eingaben außerhalb des Bereichs oder nicht endlichen Eingaben nun panikfrei (ein von der Reihenfolge von read_dir abhängiger Fuzz-Befund aus den neuen ARAIM-Szenarien). chi2_quantile sichert nun p/k wie normal_quantile ab (gibt einen Randwert zurück, statt mit assert! abzustürzen), und das Normal des Stanford-Rauschens der Verfügbarkeit begrenzt auf ein streng positives σ — sodass der Integritäts-/ARAIM-Stapel bei mutierten oder falsch konfigurierten Szenarien nie in Panik gerät.

Hinzugefügt#

• CI-Matrix für plattformübergreifende Reproduzierbarkeit. Ein neuer Job reproducibility-matrix führt die Reproduzierbarkeitstests bei jedem Push auf ubuntu-latest, macos-latest und windows-latest aus. Da das vollständige Ergebnis-JSON zwischen Betriebssystemen nicht bytegleich ist (Abweichung der libm in der letzten ULP), prüft er die plattforminvariante Projektion exakt — den Eingabe-Fingerabdruck plus die Form der Ausgabe, je Szenario als SHA-256-Goldens in tests/golden/ durch das neue tests/cross_platform_golden.rs festgelegt — neben den numerischen Festlegungen (golden.rs, auf 1e-6), den SGP4-Zuständen (sgp4_verification.rs, auf 2e-5 km) und der Determinismus im selben Prozess (determinism.rs). Zusammen belegen sie plattformübergreifende Reproduzierbarkeit auf drei Betriebssystemen, ohne die Brüchigkeit exakter Byte-Hashes der gesamten Ausgabe. docs/REPRODUCIBILITY.md dokumentiert die Aufteilung.
• Gate für die Code-Abdeckung in der CI. Ein neuer Job coverage führt cargo-tarpaulin mit der LLVM-quellbasierten Engine aus, veröffentlicht einen lcov-Bericht als Build-Artefakt und erzwingt eine Untergrenze der Zeilenabdeckung für src/ (generierte Datentabellen, der CLI-Einstiegspunkt, die Tests und Web-Assets ausgenommen). Die gemessene Zeilenabdeckung beträgt ~97 % in src/ (SGP4 und die Uhrenmodule ≥95 %); das Gate ist auf 85 % gesetzt — über dem Ziel von ≥80 % und deutlich vom gemessenen Wert entfernt, sodass es Regressionen erfasst, ohne instabil zu werden. Ein Abdeckungs-Badge wird im README veröffentlicht.
• SGP4/SDP4 im direkten Vergleich mit dem unabhängigen Crate sgp4. Ein neuer Test (tests/sgp4_crate_comparison.rs) validiert den Propagator von Kshana gegenüber der am weitesten verbreiteten SGP4-Bibliothek in Rust (neuromorphicsystems/sgp4, als reine Test-Dev-Abhängigkeit hinzugefügt) anhand derselben 666 Vektoren aus AIAA 2006-6753. Wenn beide mit dem Schwerefeldmodell WGS72 betrieben werden, das die Vektoren verwenden, stimmen die beiden unabhängigen Implementierungen bei erdnahen und resonanten Bahnen im Submikrometerbereich und über alle Regime im ungünstigsten Fall auf 4,12 mm überein; beide reproduzieren die Referenztabelle tcppver.out. Die eingecheckte Vergleichstabelle (tests/fixtures/sgp4_comparison.md, neu erzeugt über KSHANA_REGEN_FIXTURES=1) schlüsselt das Ergebnis nach Regime auf (LEO/MEO, Deep Space, ½-Tages- und 1-Tages-Resonanz) und vermerkt die vier bewusst pathologischen Fälle, die das Crate bei der Konstruktion zurückweist. Die Live-Assertions halten beide innerhalb von 2e-5 km der Referenz und lassen sie innerhalb von 4e-5 km übereinstimmen — eine Regressionssicherung, keine einmalige Prüfung. Das ist wettbewerbsfähige Herkunft: Korrektheit gegenüber einer unabhängigen Codebasis, nicht bloß gegenüber einer statischen Tabelle. (Das Standard-from_elements des Crates verwendet WGS84 und weicht daher um ~km von der Referenz WGS72 ab — im Text der Tabelle ehrlich benannt.)
• Der CCSDS-OMM-Export ist nun durchgängig erreichbar. Der OMM-Writer (src/omm.rs) hatte zuvor keinen Pfad über CLI/API; die mittleren Elemente eines Szenarios orbit lassen sich nun als OMM-Katalog nach CCSDS 502.0-B-2 veröffentlichen — eine OMM-KVN-Nachricht je TLE-definiertem Satelliten — über kshana <orbit.toml> --export-omm out.omm, oder export_omm = true im Szenario schreibt <scenario>.omm automatisch (analog zum bestehenden --export-sp3). Jede Nachricht trägt die reale NORAD-Katalognummer des Satelliten, die internationale COSPAR-Bezeichnung (YYYY-NNNP) und die Epoche (CCSDS-Form Tag des Jahres), aus der TLE-Zeile 1 durch das neue tle::parse_tle_identity geparst; die Namenszeile wird zu OBJECT_NAME (sonst OBJECT <id>). CREATION_DATE ist die Epoche des Szenarios, nicht die Uhrzeit der Wanduhr, sodass die Ausgabe reproduzierbar ist. Neue API: api::export_omm / api::auto_export_omm, OmmFile::from_tle_block, OrbitClockScenario::to_omm_string. Ein synthetisches Walker- oder RINEX-Szenario (ohne mittlere TLE-Elemente) liefert einen Fehler, statt eine leere Datei auszugeben. Validiert gegen den mitgelieferten Snapshot gps-ops mit 30 Satelliten (tests/sp3_export_roundtrip.rs).
• Interaktive Hover-Anzeigen auf den Diagrammen des Playgrounds. Bewegt man den Cursor über ein Diagramm, rastet ein Fadenkreuz am nächsten Messwert ein und zeigt einen Wert-Tooltip (web/hover.mjs, in web/app.js eingebunden). Beim Allan-Diagramm zeigt er τ und das σ_y(τ) jeder Uhr; bei den Zeitreihen-Szenariodiagrammen (Uhren-Holdover, Koppelnavigation, Zeitübertragung, hybrides PNT, GNSS/INS) zeigt er die Zeit und den Wert jeder Suite in den eigenen Einheiten des Diagramms (ns / m / ps / Auslastung), aus dem Ergebnis geparst, sodass die Anzeige zur Kurve passt. Spezialisierte Diagramme (RAIM, Spoof, Sweep) erhalten kein Overlay. Die Diagramme bleiben sich selbst beschreibende Blob-<img>s — das Overlay ist ein transparentes Fadenkreuz + Tooltip darüber, sodass Download/Vergleich/Export unberührt bleiben. Die Koordinatenmathematik (nächster Messwert, Cursor→Anteil im Plot, Parsen der Polylinie) ist per Unit-Test geprüft (web/hover.test.mjs, in der CI ausgeführt).
• A/B-Vergleichsmodus im Playground. Man kann jeden Lauf als Basislinie A anheften, ein zweites Szenario ausführen, und beide werden nebeneinander mit einer Delta-Tabelle der Gütemaße (Holdover, Zeitgebung RMS/p95, Verfügbarkeit) angezeigt, die je Kennzahl den Gewinner einfärbt (web/compare.mjs, in web/app.js eingebunden; Delta-Logik per Unit-Test in web/compare.test.mjs geprüft, in der CI ausgeführt). Alle Werte werden als Text eingefügt und alle Diagramme über Blob-<img>, sodass nie etwas aus einer Szenario-Zeichenfolge als Markup eingeschleust wird.
• Download-Schaltflächen für Diagramme (SVG + PNG). Jedes Diagramm im Playground hat nun eine zum Design passende Leiste „Download SVG / PNG“ (web/chartdl.mjs, in web/app.js eingebunden). SVG liefert das getreue, skalierbare Original; PNG rastert dasselbe sich selbst beschreibende Bild in 2x für Folien und Dokumente. Die Dateien werden mit ihrer Herkunft benannt — kshana-<chart>-v<version>-<scenario-hash>.<ext> — und die Logik für Dateiname/Größe ist per Unit-Test geprüft (web/chartdl.test.mjs, in der CI ausgeführt).
• IGRF-14, Hauptfeldmodell des Erdmagnetfelds (src/igrf.rs). Das Standard-Kugelfunktionsfeld der IAGA (Grad/Ordnung 13, Epoche 2025,0 + säkulare Variation 2025–2030; Koeffizienten maschinell aus der offiziellen igrf14coeffs.txt durch tools/gen_igrf.py nach src/igrf_data.rs erzeugt, bitgenau reproduzierbar). Eine Schmidt-normierte Synthese liefert den Feldvektor (Nord/Ost/Unten) und abgeleitete Elemente (Deklination, Inklination, horizontale/gesamte Intensität) an jedem geodätischen Ort zu jedem Datum, dazu den geomagnetischen Pol und die Dipolstärke — das magnetische Gegenstück zum Abgleich mit der Schwerekarte für die alternative PNT-Navigation. In sich geschlossen validiert: Die Synthese entspricht dem exakten geschlossenen Ausdruck des geneigten Dipols, das vollständige analytische Feld bis Grad 13 entspricht einer Differenzenbildung des skalaren Potentials, die Dipolachse reproduziert den bekannten geomagnetischen Pol (~80,7°N, −72,7°E) und eine Stärke von ~29,7 µT, und das globale Feld ist physikalisch.
• Typisierte Python-Bindings (src/python.rs). Über das Muster String-hinein/String-heraus von run/run_full hinaus stellt das Modul nun eine typisierte Klasse RunOutput bereit (.json, .svg, .summary und ein Accessor .data(), der das Ergebnis geparst als natives Python-Dict zurückgibt — ohne erneutes JSON-Parsen, mit NumPy umhüllbar), dazu run_typed, scenario_kinds() (geparste Liste von Metadaten-Dicts) und validate_toml() (eine Liste von Fehlermeldungen ohne Exception). Es liefert einen Typ-Stub nach PEP 561 (kshana.pyi + py.typed) für mypy/pyright/Editoren und eine Kurzanleitung docs/PYTHON_API.md mit. Die bestehenden Funktionen sind unverändert.
• Gleichrangige Ausgabesysteme für Propagatoren (src/orbit.rs Enum Frame + position_in_frame + state_gcrs). Jeder Propagator (Kepler, SGP4, RINEX, GLONASS, SP3) kann seine Position nun in TEME, GCRS (≈ J2000) oder ITRS (erdfest) ausgeben — TEME nativ, GCRS über die validierte Reduktion TEME→GCRS, ITRS durch Verkettung mit der CIO-Rotation gcrs_to_itrs nach IAU 2006/2000A — und seinen vollständigen GCRS-Zustand (Position + Geschwindigkeit) über state_gcrs. Die inertiale Ausgabe zur jeweiligen Epoche ist nicht mehr auf TEME beschränkt.
• CIO-basierte Reduktion von himmelsfest zu erdfest nach IAU 2006/2000A (src/cio.rs). Die moderne, äquinoktiumsfreie Kette GCRS↔CIRS↔ITRS: CIP-Koordinaten X, Y, aus der Matrix für Bias-Präzession-Nutation nach IAU 2006/2000A abgelesen (unter Wiederverwendung der validierten FW-Präzession + Nutation 2000A mit der Anpassung eraNut06a P03), die 66-Term-Reihe des CIO-Locators s (eraS06, maschinell aus der ERFA-Referenz durch tools/gen_s06.py nach src/cio_s06_data.rs erzeugt, bitgenau reproduzierbar), die Matrix GCRS→CIRS (eraC2ixys), der Erdrotationswinkel (eraEra00) und die vollständige Rotation GCRS→ITRS (eraC2tcio, zusammengesetzt mit der bestehenden Polbewegung nach IERS). Bitgenau validiert gegen die veröffentlichten Testvektoren eraXys06a (X=0.5791308482835292617e-3, Y=0.4020580099454020310e-4, s=-0.1220032294164579896e-7 bei JD_TT 2453736,5), eraC2ixys und eraEra00. Die CIO-Kette und die ältere Reduktion TEME nach Äquinoktium/GMST-1982 stimmen nachweislich überein, bis auf ihren dokumentierten Konventionsunterschied der Sternzeit von ≈2·(Äquinoktien-Gleichung). Dies ist die strenge Reduktion, die der Pfad über Äquinoktium/GMST angenähert hat.
• Vollständige Nutationsreihe IAU 2000A (src/nutation.rs nutation_iau2000a, nutation_matrix_2000a). Das vollständige Modell MHB2000 — 678 lunisolare + 687 planetare Terme — auf < 0,1 mas genau, neben der bestehenden Kürzung 2000B mit 77 Termen. Die Tabellen werden maschinell aus der Referenz nut00a von IAU SOFA / ERFA durch tools/gen_nut00a.py nach src/nutation_iau2000a_data.rs erzeugt (der Generator reproduziert die eingecheckte Datei bitgenau), und die gesamte Reihe — sowohl die Sätze fundamentaler Argumente nach IERS-2003 und MHB2000 als auch die planetaren Längen — ist bitgenau gegen den veröffentlichten Testvektor eraNut00a validiert (Δψ = −0.9630909107115518e-5, Δε = 0.4063239174001679e-4 bei JD_TT 2453736,5, auf 1e-13 rad). Die Standardreduktion TEME→GCRS behält die Reihe 2000B (~1 mas, unterhalb der Vereinfachung der Geschwindigkeits-Bezugssystemrotation der Kette); nutation_matrix_2000a stellt die Matrix zur jeweiligen Epoche mit < 0,1 mas für Aufrufer bereit, die sie brauchen.
• Lauffähiges Szenario zur Mondintegrität (kind = "lunar-integrity", scenarios/lunanet-araim.toml). Bindet den Durchgang mit Schutzniveau am Mondsüdpol (src/lunar.rs LunarScenario → south_pole_hpl_pass) mit einem JSON-LunarReport und einem SVG-Diagramm HPL über Zeit in den Szenario-Runner ein, sodass der cislunare Integritätsfall direkt aus der CLI erreichbar ist. Es macht die Lücke ehrlich sichtbar: Mit dem LANS-σ_URE von 30 m überschreitet das HPL am Südpol (≈ 260–450 m) einen Alarmgrenzwert von 50 m (0 % verfügbar) — die Integrität des Mond-PNT ist noch nicht erreicht.
• Verfügbarkeit von ARAIM mit zwei Konstellationen auf realen GPS+Galileo-TLEs und Anbindung an den Szenario-Runner (src/raim.rs, src/orbit.rs, scenarios/araim-gps-galileo.toml). Fügt araim_dual_constellation_availability hinzu (die fortgeschrittene ARAIM-Engine — Fehler einzelner Satelliten und konstellationsweite Fehler — über ein Zeitraster ausgeführt) und visible_positions_labeled, und bindet sie über ein Flag araim_dual in den Runner IntegrityScenario ein, sodass eine ARAIM-Studie mit mehreren GNSS direkt aus TOML erreichbar ist. Ein Test mit realen Daten (tests/araim_dual_real_data.rs) auf mitgelieferten Celestrak-Snapshots von GPS+Galileo vom 2026-06-07 zeigt, dass das Zusammenlegen mit Galileo die Verfügbarkeit von ARAIM bei einem anspruchsvollen VAL von 12 m von 0,21 auf 0,67 hebt (10,5→21,8 Satelliten in Sicht), während der gegen Konstellationsfehler robuste Modus mit nur zwei Konstellationen grundsätzlich begrenzt ist — der quantitative Grund, warum robuste Integrität mit zwei Konstellationen auf eine dritte Konstellation oder SBAS hinausläuft. Ehrlicher Restpunkt: die numerisch exakte Reproduktion von Tabelle A-3 der EU-ARAIM-TN gegen eine einzelne versionsgebundene Epoche und ein Zenodo-Fixture-Eintrag.
• Eingeschränktes Dreikörperproblem auf Kreisbahnen (CR3BP) für das System Erde–Mond (src/cr3bp.rs). Ein neuer Kern für die cislunare Dynamik, den die Zweikörper-/SGP4-Propagatoren nicht bieten können: Bewegungsgleichungen im rotierenden System (cr3bp_accel), ein RK4-Propagator (propagate_cr3bp), das Integral der Jacobi-Konstante (jacobi_constant) und die fünf Lagrange-Punkte (lagrange_points). Validiert gegen geschlossene bzw. veröffentlichte Anker: die kollinearen Punkte von Erde–Mond (L1 ≈ 0,83692, L2 ≈ 1,15568, L3 ≈ −1,00506), die exakten gleichseitigen L4/L5 = (½−μ, ±√3/2, 0), alle fünf als Gleichgewichte des Feldes bestätigt, Jacobi-Konstante unter Propagation bis auf die Integratorgenauigkeit erhalten, und die aus der Ebene herausführende Rückstellkraft, die Halo-/NRHO-Bahnen möglich macht. Dies ist die Grundlage, um eine reale NRHO darzustellen. Ehrlicher Restpunkt: differentiell korrigierte periodische Anfangsbedingungen der NRHO 9:2, das exzentrische/Ephemeriden-Modell (DE) und die denormierte Transformation in die selenozentrischen Bezugssysteme von src/lunar.rs.
• Polbewegung nach IERS und die Reduktion TEME→ITRF (src/frames.rs). Fügt polar_motion_matrix hinzu (SOFA iauPom00: W = Rx(−y_p)·Ry(−x_p)·Rz(s′) mit dem TIO-Locator s′), pef_to_itrf / itrf_to_pef und teme_to_itrf — die GMST-basierte Rotation TEME→PEF gefolgt von der Polbewegung —, womit eine ITRF-genaue erdfeste Position auf dem rein GMST-basierten teme_to_ecef vervollständigt wird (die Polbewegung ist beim Bahnradius ein Effekt von mehreren zehn Metern). x_p/y_p sind beobachtete IERS-Größen, die der Aufrufer liefert. Ehrlicher Restpunkt: eine vollständig CIO-basierte Kette (X, Y, s) und eine numerische Gegenprüfung mit ANISE/SPICE auf <10 m bleiben Folgearbeiten.
• Systematiken des Kaltatom-Interferometers, Drift-Sweep und Validierung an einem veröffentlichten Gerät (src/inertial/quantum_imu.rs, docs/QUANTUM.md). Erweitert den CAI-Beschleunigungsmesser aus ersten Prinzipien um die zwei führenden deterministischen Systematiken: die Coriolis-/Rotations-Phase Φ_cor = 2·k_eff·v_⊥·Ω·T² (coriolis_phase, mit dem äquivalenten Beschleunigungs-Bias 2·Ω×v über coriolis_accel_bias) und die Phase der AC-Stark-Lichtverschiebung Φ_LS = (δ_LS,1 − δ_LS,3)/Ω_eff (ac_stark_phase, die sich bei konstanter Verschiebung durch die Symmetrie π/2–π–π/2 aufhebt). Fügt cai_drift_sweep hinzu (Drift der Koppelnavigationsposition über die Zykluszeit — der Kern eines Vergleichs Quanten vs. klassisch) und einen Validierungstest gegen das mobile Gravimeter von Freier et al. 2016 (arXiv:1512,05660): Der modellierte Boden des Quantenprojektionsrauschens liegt unterhalb des veröffentlichten kurzzeitigen Rauschens von 96 nm/s²/√Hz und innerhalb von ~2 Größenordnungen davon. docs/QUANTUM.md aktualisiert. Ehrlicher Restpunkt: Systematiken von Wellenfront/Strahlausrichtung, Auflösung der Streifenmehrdeutigkeit, die exakte Reproduktion der Flugtests CARIOQA-PMP / Boeing-AOSense (erfordert veröffentlichte PSDs der Plattform) und eine JS-Playground-Voreinstellung.
• Reduktion cislunarer Bezugssysteme und ein Integritätsdurchgang am Mondsüdpol (src/lunar.rs). Erweitert die ARAIM-Engine für den Mond um die Rotation MCI↔MCMF (Moon-centered inertial ↔ Moon-fixed) (mci_to_mcmf / mcmf_to_mci, ein vereinfachtes Modell der mittleren Rotation mit der siderischen Rate des Mondes), selenographische Breite/Länge/Höhe (mcmf_to_selenographic / selenographic_to_mcmf) und south_pole_hpl_pass — ein gelandeter Empfänger in der Artemis-Region gegenüber einem repräsentativen LunaNet-Relais-Satz über einen Durchgang von 24 h, der die Integritätslücke ehrlich beziffert: Mit dem nominalen LANS-σ_URE von 30 m ist das Schutzniveau endlich, überschreitet aber einen Alarmgrenzwert für Oberflächeneinsätze von 50 m. Ehrlicher Restpunkt: die präzise LANS-NRHO-Ephemeride (eine cislunare Bahn mit 3 Körpern), die physikalische Libration / der präzedierende Mondpol (DE421/SPICE) und ein LunaNet-TOML-Szenario bleiben Folgearbeiten.
• ARAIM-Integritätsunterstützungsnachricht, Stanford-Diagramm als SVG und die offene ARAIM-Referenz (src/raim.rs, docs/ARAIM_REFERENCE.md). Fügt eine explizite IntegritySupportMessage hinzu (σ_URA / σ_URE / b_nom / P_sat / P_const, mit den Referenzwerten der WG-C für GPS+Galileo und Konvertern .fault_priors() / .dual_fault_priors() in die Engines araim_raim für Einzelfehler und araim_dual_raim für konstellationsweite Fehler), einen eigenständigen Renderer stanford_svg des Stanford-Integritätsdiagramms (die vier Zonen, die Grenze PL = error, die Hilfslinien des Alarmgrenzwerts, eine farbkodierte Markierung je Epoche) und docs/ARAIM_REFERENCE.md, das den Algorithmus, die ISM, die Fehlerhypothesen, den Vertrag des Schutzniveaus und den Nutzen von zwei Konstellationen dokumentiert. Tests belegen den Gewinn an Geometrie/Redundanz (das Zusammenlegen einer zweiten Konstellation verengt das HPL bei Einzelfehlern) und die Toleranz gegenüber Konstellationsfehlern (der Nutzer mit zwei Konstellationen übersteht den Verlust einer ganzen Konstellation; ein Nutzer mit einer einzigen Konstellation nicht). Ehrlicher Restpunkt: die numerische Reproduktion von Tabelle A-3 der EU-ARAIM-TN / der Verfügbarkeitszahl von 15–25 % gegen einen versionsgebundenen realen TLE-Snapshot, ein Zenodo-Fixture-Eintrag und die Anbindung von araim_dual_raim an den Runner für Szenariodateien.
• Nutation IAU 2000B und die vollständige inertiale Reduktion TEME→GCRS/J2000 (src/nutation.rs). Fügt das zweite und dritte Stück einer echten inertialen Reduktion der Bezugssysteme zur ausgelieferten Präzession IAU 2006 hinzu: die lunisolare Nutationsreihe MHB2000 mit 77 Termen (nutation_iau2000b, die übliche Kürzung IAU 2000B, auf ~1 mas genau) mit den fundamentalen Argumenten nach Delaunay und der Nutationsmatrix iauNumat von SOFA, sowie die Kette nach Vallado AIAA-2006-6980 TEME→TOD (Gleichung der Äquinoktien) → TOD→MOD (Nutation) → MOD→GCRS (Bias-Präzession), bereitgestellt als teme_to_gcrs(r, v, jd_tt) / gcrs_to_teme. Die Reihe, die Argumente und die Einheitenkonstanten sind aus der Referenz nut00b von IAU SOFA / ERFA übertragen und bitgenau gegen den veröffentlichten Testvektor eraNut00b validiert (Δψ, Δε auf 1e-13 rad). Ehrlicher Restpunkt: die vollständige Reihe IAU 2000A mit 678 Termen (<0,1 mas), eine numerische Gegenprüfung mit ANISE/SPICE auf <10 m und die Polbewegung bleiben Folgearbeiten (siehe ROADMAP.md).

0.12.0 - 2026-06-06#

Dieses Release bringt Kshanas ersten nicht analytischen Bahnpropagator — einen Cowell-Integrator mit einem hierarchischen Kraftmodell aus sechs Störungen (Zweikörper + zonale Terme J2–J6 + von der Epoche abhängiger dritter Körper Sonne/Mond + Strahlungsdruck der Sonne mit konischem Umbra-/Penumbra-Schatten + atmosphärischer Widerstand + die post-newtonsche relativistische Schwarzschild-Korrektur), angetrieben von der Wahl zwischen zwei adaptiven Integratoren (RK4 mit Schrittverdopplung und das eingebettete Paar Dormand–Prince RK5(4)) — zusammen mit einer Schicht für Manöver / Trajektorienentwurf (impulsive und endliche Brennphasen, ein Lambert-Löser nach Izzo und ein Porkchop-Sweep), einer Alt-PNT-Schicht mit Schwerekartenabgleich, die eine 60-minütige GPS-verweigerte Spur auf unter 500 m zurückgewinnt, einer Pipeline zur Bahnbestimmung im Batch- und sequenziellen Verfahren und einem vollständigen eng gekoppelten GNSS/INS-UKF mit 17 Zuständen und Quanten-CAI-Koppelnavigation. Jede numerische Fähigkeit ist an analytische Wahrheit oder einen von Hand hergeleiteten geschlossenen Ausdruck gebunden; die standardmäßig abgeschalteten Störungen lassen die veröffentlichten Goldens unberührt.

Hinzugefügt#

• Post-newtonsche relativistische Korrektur (Schwarzschild) (forces::relativistic_accel + propagator::ForceModel::relativity). Fügt die dominante allgemein-relativistische Störung auf einer erdnahen Bahn hinzu — den führenden Treiber der relativistischen Perigäumsdrehung — in der Form β = γ = 1 nach IERS / Montenbruck–Gill: a = (μ/c²r³)·{[4μ/r − v²]·r + 4(r·v)·v}. Wie der atmosphärische Widerstand ist sie geschwindigkeitsabhängig und wird daher über [accel_rv] in die rechte Seite des Integrators (r, v) eingebracht, optional und standardmäßig abgeschaltet. In sich geschlossen validiert: Auf einer Kreisbahn fällt sie auf den geschlossenen Ausdruck 3μ²/(c²r³)·r̂ zusammen (rein radial und nach außen gerichtet, Komponenten abseits der Achse exakt null); ihr Verhältnis zum Zweikörperterm ist im LEO der Lehrbuchwert ≈1.9·10⁻⁹ (die Signatur von μ/(c²r)); ein Fall mit radialer Geschwindigkeit entspricht dem von Hand vereinfachten μ(4μ + 3v²r)/(c²r³); und im Propagator stört sie die Bahn, ohne sie zu dissipieren — die große Halbachse bleibt auf deutlich unter einen Meter pro Tag erhalten, strukturell das Gegenteil des monotonen Zerfalls durch Widerstand. Weil sie standardmäßig abgeschaltet ist, bleiben die Goldens für Zweikörper/J2/zonal unberührt. Das Abstimmen der PPN-Parameter (β,γ) und der Term der Lense–Thirring-Rahmenmitführung bleiben Folgearbeiten.
• Konisches Schattenmodell aus Umbra+Penumbra (forces::conical_shadow), nun vom Strahlungsdruck der Sonne verwendet. Rüstet die binäre Finsternis mit Umbra-Zylinder auf einen glatten Faktor ν ∈ [0,1] auf: Sonne und Erde werden als Scheiben mit scheinbaren Winkelradien a = asin(R☉/d☉), b = asin(Rₑ/|r|) und scheinbarem Mittelpunktabstand c modelliert, und ν ist eins minus der Anteil der Sonnenscheibe, der von der Erdscheibe verdeckt wird (die Überlappungsfläche zweier Kreise, die Linse) — volle Sonne für c ≥ a+b, totale Umbra für c ≤ b−a, ringförmig für c ≤ a−b und dazwischen eine kontinuierliche Penumbra. srp_accel verwendet ihn nun, sodass die Kraft des Strahlungsdrucks durch die Finsternis hindurch glatt abklingt, statt ein- und auszuschalten. Fügt den nominalen IAU-Wert forces::SOLAR_RADIUS hinzu. In sich geschlossen validiert: ν = 1 in voller Sonne und ν = 0 tief in der Umbra (exakt), eine glatte monotone Penumbra (ν steigt über das Band [b−a, b+a] von 0 → ~½ bei c = b → 1) und die konische Penumbra reicht über den Umbra-Zylinder hinaus (ein Punkt, den der binäre Zylinder als voll beleuchtet bezeichnet, ist für den Kegel 0 < ν < 1). Der einfachere cylindrical_shadow bleibt verfügbar; Randverdunkelung der Sonne und der Schatten der abgeplatteten Erde bleiben Folgearbeiten.
• Eingebetteter Integrator Dormand–Prince RK5(4) (integrator::dopri54_step / integrator::integrate_dopri + propagator::propagate_dopri). Fügt das standardmäßige eingebettete Butcher-Tableau-Paar von Dormand–Prince (1980) neben dem bestehenden RK4-Treiber mit Schrittverdopplung hinzu: Sieben FSAL-Stufen liefern aus einem Satz von Auswertungen eine Lösung 5. Ordnung und eine Fehlerschätzung 4. Ordnung (7 gegenüber 11 Funktionsaufrufen je Schritt), eine günstigere Schätzung des lokalen Fehlers. Der adaptive Treiber verwendet dieselbe RMS-Fehlernorm und denselben Schrittregler 0.9·(1/err)^(1/5), ist also eine direkt austauschbare Alternative; propagator::propagate_dopri stellt ihn für das Kraftmodell der Bahn bereit. In sich geschlossen validiert: Die eingebettete Fehlerschätzung ist O(h⁵) (Halbieren des Schritts senkt sie um ~32×); DP5(4) integriert y' = y bis e und den harmonischen Oszillator über 50 Perioden bei Energieerhaltung auf <1e-6; er erreicht denselben Endpunkt bei gleicher Toleranz mit weniger Funktionsauswertungen als die Schrittverdopplung (ohne Genauigkeit zu opfern); und propagate_dopri besteht dasselbe Gate gegen die analytische Wahrheit wie der RK4-Pfad — unter einem Meter gegenüber der exakten Kepler-Lösung in universellen Variablen über eine LEO-Bahn von 24 h — während die beiden Treiber auf einer J2..J6-Bahn (ohne geschlossenen Ausdruck) auf <1 m übereinstimmen. Höhere eingebettete Paare (RKF7(8) / DOP853) bleiben Folgearbeiten.
• Atmosphärischer Widerstand als erste geschwindigkeitsabhängige Kraft in den Propagator eingebunden (forces::atmospheric_density + forces::drag_accel + propagator::ForceModel::drag). Fügt die stückweise exponentielle Atmosphäre nach Vallado Tabelle 8-4 ρ = ρ0·exp(−(h−h0)/H) hinzu (28 Bänder vom Meeresspiegel bis über 1000 km, unterhalb der Oberfläche begrenzt) und den quadratischen Widerstand a = −½ · ρ(h) · (C_D·A/m) · |v_rel| · v_rel gegenüber der mitrotierenden Atmosphäre v_rel = v − ωₑ ẑ × r (forces::EARTH_ROTATION_RATE = 7.2921151467e-5). Da der Widerstand von der Geschwindigkeit abhängt, erhält ForceModel ein neues accel_rv(t, r, v), und die rechte Seite des Integrators übergibt nun die Geschwindigkeit (f(t,[r;v]) = [v; a(t,r,v)]); das rein positionsabhängige accel_at ist unverändert, sodass die konservativen Terme und Goldens unberührt bleiben. In sich geschlossen validiert: Die Dichte ist am Wert 1,225 kg/m³ auf Meereshöhe verankert, wird unterhalb der Oberfläche begrenzt, nimmt durch das LEO hindurch monoton ab, liegt bei 400 km im sonnenmittleren Band von ~1e-12 kg/m³, und ihre zurückgewonnene lokale Skalenhöhe (≈ 58 km bei 400 km) ist physikalisch; der Widerstand wirkt der mitrotierenden Relativgeschwindigkeit entgegen mit der Größenordnung von ~2e-6 m/s² im LEO für C_D·A/m = 0.02 m²/kg; und — das entscheidende Merkmal — der Widerstand ist dissipativ: Eine Bahn auf 300 km verliert spezifische Energie monoton, und ihre große Halbachse nimmt mit einer beschränkten Rate von ~km/Tag ab, während die Basislinie im Vakuum die Energie auf <1e-9 erhält. Die thermosphärische Dichte NRLMSISE-00 (die Klausel < 5 % für die Widerstandsdichte) bleibt eine Folgearbeit.
• Strahlungsdruck der Sonne, epochengesteuert in das Kraftmodell des Propagators eingebunden (forces::srp_accel + propagator::ForceModel::solar_radiation). Fügt das Kanonenkugel-Modell für den Strahlungsdruck a = ν · P☉ · cᵣ · (A/m) · (AU/d)² · d̂ mit einem Finsternisfaktor durch zylindrischen Schatten hinzu (forces::cylindrical_shadow, ν ∈ {0.1}): den Strahlungsdruck P☉ = Φ☉/c aus der modernen Gesamtbestrahlungsstärke der Sonne von 1361 W/m² (≈ 4,5398·10⁻⁶ N/m²), den Abfall des Flusses mit dem Abstandsquadrat (AU/d)² und den radialen Stoß von der Sonne weg. Er läuft über die selbe epochengesteuerte rechte Seite wie der dritte Körper und tastet die Sonne ephem einmal zur fortgeschriebenen Epoche epoch_jd_tt + t/86400 ab, die sich Sonne als dritter Körper und Strahlungsdruck teilen. Kombinierbar: with_zonals_j2_j6().third_body(true, true, epoch).solar_radiation(1.5, 0.02). In sich geschlossen gegen von Hand hergeleitete Signaturen validiert: Der Strahlungsdruck bei 1 AU entspricht dem Lehrbuchwert ≈ 4,5398·10⁻⁶ N/m²; der Strahlungsdruck eines voll beleuchteten LEO-Satelliten ist bitgleich mit der Kanonenkugel-Formel, zeigt von der Sonne weg und liegt im Band von ~1,36·10⁻⁷ m/s² für cᵣ = 1,5, A/m = 0,02 m²/kg; eine Verdopplung des Sonnenabstands viertelt den Betrag (Abstandsquadrat); der zylindrische Schatten verfinstert nur den Umbra-Zylinder (sonnenabgewandt und innerhalb eines Erdradius der Linie Erde–Sonne) und ergibt in der Finsternis exakt null Strahlungsdruck; und im Propagator stört der Strahlungsdruck eine LEO-Bahn um einen kleinen beschränkten Betrag, der ~linear mit A/m skaliert — während ein Modell ohne Störungen bitgenau zeitunabhängig bleibt und die Goldens für Zweikörper/J2/zonal unberührt lässt. Die konische Umbra/Penumbra (glattes ν ∈ [0.1]), der atmosphärische Widerstand und eine externe Gegenvalidierung mit GMAT/Orekit bleiben Folgearbeiten.
• Epochengesteuerter dritter Körper Sonne/Mond in die zeitveränderliche rechte Seite des Propagators eingebunden (propagator::ForceModel::third_body / accel_at). Die Störung durch den dritten Körper ist kein eigenständiger Kraftterm mehr — sie wird nun vom Cowell-Propagator als wirklich zeitveränderliche Kraft integriert: Jede Auswertung der rechten Seite tastet die Positionen von Sonne/Mond aus ephem zur fortgeschriebenen Epoche epoch_jd_tt + t/86400 ab (wobei precession::julian_centuries_tt für die Umrechnung Tag↔Jahrhundert wiederverwendet wird), sodass die störenden Körper sich während der Integration auf ihren Bahnen bewegen, statt zu Beginn eingefroren zu sein. Kombinierbar mit jedem Schwerefeldmodell (ForceModel::with_zonals_j2_j6().third_body(true, true, epoch)). In sich geschlossen validiert: Der Sonnenterm der rechten Seite ist bitgleich mit third_body_accel, ausgewertet an der Ephemeridenposition für jenen Zeitpunkt, sowohl bei t = 0 als auch bei t = 1 day (was die Verdrahtung 86400 s ↔ 1 Tag ↔ 1/36525 Jahrhundert exakt belegt), der störende Körper rückt zwischen den Abtastungen um ~2,6·10⁹ m/Tag vor (nicht eingefroren), die momentanen Gezeitenbeträge im LEO erreichen die Lehrbuch-Bänder von ~5·10⁻⁷ m/s² (Sonne) und ~1,1·10⁻⁶ m/s² (Mond, ≈ 2× die Sonne), jeder Körper stört die eintägige Trajektorie messbar und bleibt dabei beschränkt, und derselbe Anfangszustand, zu Epochen mit einem Vierteljahr Abstand propagiert, ergibt eine andere Trajektorie (die Gezeitenachse dreht sich um 90°) — während ein Modell ohne aktivierten Körper bitgenau zeitunabhängig ist und die Goldens für Zweikörper/J2/zonal unberührt lässt. Ephemeridengenauigkeit in DE-Güte und eine externe Gegenvalidierung mit GMAT/Orekit bleiben Folgearbeiten.
• Mondephemeride geringer Genauigkeit (ephem::moon_position), die das Paar Sonne/Mond als dritter Körper vervollständigt. Fügt die niedrigpräzise Mondreihe von Montenbruck & Gill (§3.3.2) neben dem Sonnenmodell hinzu, sodass das körperunabhängige forces::third_body_accel nun von beiden Gestirnen gespeist werden kann, ohne externen DE/SPK-Kernel. In sich geschlossen gegen von Hand hergeleitete Mondsignaturen validiert: Die geozentrische Entfernung bleibt über einen Monat innerhalb der realen Hülle aus Perigäum/Apogäum (~356.500–406.700 km), und ihr Monatsmittel gibt die große Halbachse von ~384.400 km zurück; die ekliptikale Breite überschreitet nie die Bahnneigung des Mondes von ~5,3° (geprüft durch Projektion auf den Ekliptikpol in äquatorialen Koordinaten, wodurch die Breitenreihe und die Rotation um die Schiefe der Ekliptik gemeinsam validiert werden); die Richtung des Mondes kehrt nach einem siderischen Monat (27,3217 d) auf 1° zurück, und seine tägliche Bewegung bleibt im physikalischen Band von 12–15°/Tag; und die Störung durch den Mond als dritter Körper auf einen LEO-Satelliten hat den Lehrbuchbetrag von ~1,1·10⁻⁶ m/s² (≈ das Doppelte der Sonne). Positionsgenauigkeit in DE-Güte, atmosphärischer Widerstand und Strahlungsdruck bleiben Folgearbeiten.
• Gravitation des dritten Körpers (Sonne) mit eingebauter Ephemeride geringer Genauigkeit (forces::third_body_accel, ephem::sun_position). Fügt dem Kraftmodell die Störung durch den dritten Körper hinzu: a = GM₃·((s−r)/|s−r|³ − s/|s|³) (direkte Anziehung minus den indirekten Term, den das geozentrische System abziehen muss), mit der Sonnenposition aus der niedrigpräzisen analytischen Reihe von Montenbruck & Gill im neuen Modul ephem — kein externer DE/SPK-Kernel nötig für einen Lauf mit geringer Genauigkeit. In sich geschlossen validiert: Die Beschleunigung entspricht dem exakten Gradienten ihres eigenen Störpotentials (third_body_potential), die Störung verschwindet im Geozentrum und hat auf einem LEO-Satelliten den Lehrbuchbetrag von ~5·10⁻⁷ m/s², und die Sonnenephemeride trifft von Hand hergeleitete J2000-Anker — Perihelabstand ≈ 1,471·10¹¹ m, Deklination ≈ −23° nahe der Dezember-Sonnenwende, eine scheinbare Bewegung von ≈ 1°/Tag (≈ 90° je Vierteljahr) und ein Abstand, der über ein volles Jahr innerhalb der Hülle der Erdbahn von 0,983–1,017 AU bleibt. Liefert die Hälfte des dritten Körpers für den Kraftmodell-Schritt des Meilensteins zum numerischen Propagator (der Mond wird in einem begleitenden Eintrag weiter oben geliefert); Positionsgenauigkeit in DE-Güte, atmosphärischer Widerstand und Strahlungsdruck bleiben Folgearbeiten.
• Kraftmodell der zonalen Harmonischen J2–J6 (forces::zonal_accel / zonal_potential). Erweitert das Kraftmodell des Cowell-Propagators über J2 hinaus auf das vollständige zonale Erdfeld bis Grad 6 (die standardmäßig veröffentlichten nicht normierten Werte J2..J6 aus EGM-96), als ForceModel::with_zonals_j2_j6() in den Propagator eingebunden. Die Beschleunigung ist der exakte analytische Gradient des zonalen Störpotentials R(r) = −(μ/r)·Σ Jₙ(Re/r)ⁿPₙ(z/r) (Legendre-Polynome durch aufsteigende Rekursion), auf drei unabhängige Weisen validiert: Sie reduziert sich bis auf Maschinengenauigkeit auf das an 666 Vektoren validierte j2_accel, wenn sie auf [J2] beschränkt wird; sie entspricht dem numerischen Gradienten ihres eigenen Potentials über das gesamte Feld J2..J6 (die Goldstandard-Prüfung für konservative Felder); und die ungeraden Terme J3 gegenüber den geraden Termen J2/J4..J6 zeigen unter z → −z ihre charakteristische (Anti-)Symmetrie zwischen Nord und Süd — die Asymmetrie der Birnenform. Eine propagierte J2..J6-Bahn erhält die Gesamtenergie (kinetisch + zentral + zonales Potential) über einen Tag auf ~1e-8 und stört die reine J2-Bahn um einen kleinen, von null verschiedenen Betrag. Das liefert Schritt 2 („zonale Harmonische J2–J6“) des Meilensteins zum numerischen Propagator; das tesserale EGM-Feld hohen Grades, Widerstand, Strahlungsdruck, dritter Körper und eine externe Gegenvalidierung mit GMAT/Orekit bleiben Folgearbeiten.
• Numerischer Bahnpropagator (Cowell) (src/propagator.rs). Der erste nicht analytische Propagator von Kshana (der Rest des Bahnstapels ist analytisches SGP4/SDP4): Er verbindet das Kraftmodell aus Zweikörper + J2 (src/forces.rs) mit dem adaptiven RK4-Treiber mit Schrittverdopplung (src/integrator.rs) als f(t,[r;v]) = [v; a(r)], mit einem Schalter ForceModel. Validiert gegen eine analytische Wahrheit, die stärker ist, als es eine numerische Gegenprüfung mit einem anderen Werkzeug wäre: Die ungestörte Bahn reproduziert die exakte Kepler-Lösung in universellen Variablen auf unter einen Meter über eine 24-Stunden-LEO-Bahn (ein engeres Gate als das „gegenüber einer numerischen Referenz < 10 m“, das der Meilenstein formuliert), spezifische Energie und Drehimpuls bleiben auf ~1e-9 relativ erhalten, und die nodale Regression durch J2 reproduziert die geschlossenen Raten j2_secular_rates nach Theorie erster Ordnung (innerhalb von 2 %, dem Residuum O(J2²)). Fügt außerdem solve_kepler_checked hinzu, einen Newton-Löser für die Kepler-Gleichung, der Err zurückgibt, statt einer stillschweigend falschen Antwort, wenn er innerhalb eines beschränkten Iterationsbudgets nicht konvergiert (der Fall e = 0.999 nahe dem Perigäum). Ehrlicher Umfang: Das Kraftmodell ist nur Zweikörper + J2 — das tesserale EGM-Feld hohen Grades (200×200 + Loader), Widerstand (NRLMSISE-00), Strahlungsdruck, Kräfte dritter Körper und eine externe Gegenvalidierung mit GMAT/Orekit bleiben Folgearbeiten.
• 60-minütiger Schwerekartenabgleich ohne GPS auf < 500 m (run_gps_denied_gravity_nav). Vertieft die Alt-PNT-Schicht bis zum Validierungsziel Quantum Wayfarer von ESA NAVISP: Ein Fahrzeug fliegt eine Spur von ~700 km bei einem vollen einstündigen GNSS-Ausfall — seine Inertiallösung driftet auf ≈ 70 km — und ein Kaltatom-Gravimeter plus ein hierarchischer grob-zu-fein arbeitender Partikel-/Gitter-Abgleicher gewinnt die konstante INS-Drift auf ≈ 145 m (< 500 m) zurück, eine Verringerung um mehr als 480×. Der reale Weißrauschboden des Gravimeters wird als deterministische, mit Seed erzeugte Folge eingespeist, sodass dem Abgleicher nie rauschfreie Wahrheit gegeben wird, der Lauf aber exakt reproduzierbar ist (bitgleich verifiziert und über Rauschrealisierungen hinweg auf wenige Meter stabil). Ein Test in Regressionsgüte zeigt, dass die Verfeinerung notwendig ist — ein einzelnes grobes Gitter bleibt bei ~2 km stehen, erst die dreistufige Verfeinerung durchbricht die Grenze von 500 m. Neues eingechecktes Szenario scenarios/gps-denied-gravity-nav.toml. Die Zeile docs/CAPABILITY.md bleibt ehrlich teilweise (weiterhin keine mitgelieferte EGM2008-Karte), ihr Beleg ist auf das Ergebnis < 500 m über 60 min aktualisiert. Der ehrliche Umfang bleibt unverändert: Feld aus Kugelflächenfunktionen niedrigen Grades + synthetische Mascons; eine Monte-Carlo-Studie über Realisierungen des Darstellungsfehlers der Karte ist eine Folgearbeit.
• Register der Übertreibungen + Regressionssicherung (docs/CLAIMS-VS-REALITY.md, tests/no_overclaims.rs). Schließt den Strang zur Ehrlichkeit/Zurücknahme von Behauptungen ab: Die vierzehn Übertreibungen, die ein früheres Audit katalogisiert hat (OC-0…OC-13), sind nun alle GREEN — die starken Behauptungen (OC-0 gekoppeltes Kalman-Filter für Uhr + Position, OC-2 Jamming J/S→C/N₀→Signalverlust, OC-7 Physik des Mach–Zehnder-CAI, OC-8 ARAIM HPL/VPL) sind durch ausgelieferte, getestete Fähigkeiten abgelöst, statt abgeschwächt formuliert zu werden, und die übrigen Zeilen sind passend zum Code zurückgenommen. Ein neuer CI-Test durchsucht die aktuellen öffentlichen Oberflächen (README, CAPABILITY, GLOSSARY, web/) und schlägt fehl, wenn eine ausgemusterte nackte Übertreibung ohne Einschränkung wieder auftaucht, sodass eine Zeile GREEN nicht unbemerkt zurückfallen kann. Das Gütemaß „Integrität“ je Lauf bleibt ehrlich mit Selbstkonsistenz des Filters beschriftet (nicht Integrität der Luftfahrt); das echte ARAIM HPL/VPL wird getrennt ausgewiesen, sodass beide nie vermischt werden.
• Navigation mit Schwerekartenabgleich (Alt-PNT ohne GPS). Neues src/gravimeter.rs fügt die Alt-PNT-Fähigkeitsschicht hinzu, die die Studien zum Schwerekartenabgleich von ESA NAVISP (Quantum Wayfarer / QT-CCI) fordern: ein Messmodell für das Kaltatom-Gravimeter, dessen Weißrauschboden aus der ASD des CAI-Beschleunigungsmessers abgeleitet ist (σ = ASD/√τ); ein Schwereanomalie-Feld aus Kugelflächenfunktionen niedrigen Grades, vollständig normiert (validiert gegen die geschlossenen Legendre-Funktionen P̄₁₁=√3·cosφ, P̄₂₀=(√5/2)(3sin²φ−1), P̄₂₂=(√15/2)cos²φ und eine von Hand hergeleitete Anomalie eines einzelnen Terms von 1,897 mGal), plus synthetische Mascons für die lokalen Merkmale hohen Grades; und ein Partikelfilter für den Schwerekartenabgleich (aus mapmatch + particle_filter zusammengesetzt), das eine Spur ohne GPS aus der Anomaliefolge zurückgewinnt, die es durchfliegt. Ein eingechecktes NAVISP-Benchmark (scenarios/gravity-map-nav.toml) senkt eine freie Inertialdrift von ~73 km auf wenige km. Ehrlicher Umfang: Kshana liefert den vollständigen Koeffizientensatz EGM2008 mit 2190° nicht mit — das Feld hat niedrigen Grad + Mascons, ist keine reale hochaufgelöste Karte; der EGM/EIGEN-Loader, eine Magnetkarte, geländegestütztes SLAM und die Einbindung von kind= in die Szenario-Engine mit einem SVG-Driftdiagramm bleiben Folgearbeiten. docs/CAPABILITY.md „Gravity-map / alt-PNT navigation“ → teilweise.
• Manövermodellierung und Brückenkopf für den Trajektorienentwurf. Neues src/maneuver.rs fügt die erste Schicht für den Trajektorienentwurf oberhalb von SGP4 hinzu: impulsive ΔV-Knoten, die eine Geschwindigkeitsunstetigkeit anwenden und eine Kovarianz 6×6 fortschreiben (deterministischer Brennvorgang ⇒ Identität als Zustandsübergang; die Kovarianz des Ausführungsfehlers wird aus dem Brennsystem — ECI oder LVLH — in den Geschwindigkeitsblock gedreht), eine Integration endlicher Brennphasen (konstanter Schub über einen Brennbogen mit der Masse als Zustand), deren erreichtes ΔV gegen die geschlossene Tsiolkovsky-Raketengleichung auf besser als 0,01 % geprüft wird, ein Lambert-Löser nach Izzo-2015 für einen einzelnen Umlauf (r1, r2, Flugzeit ⇒ v1, v2), ein exakter Kepler-Propagator in universellen Variablen (Zweikörper-Wahrheit) und ein Porkchop-Sweep, der ein Raster aus Startepoche × Ankunftsepoche auf das Abflug-C3 und das Ankunfts-V∞ abbildet, als 2D-JSON-Array für die Konturdarstellung im Browser ausgegeben. Die Validierung ist in sich geschlossen und stärker als die Ausgabe eines Tutorials: Jede Ausgabe von Lambert wird durch den Kepler-Propagator hin und zurück geführt (sie muss wieder auf r2 landen), und das Minimum des Porkchop wird gegen die analytische C3-Untergrenze des Hohmann-Transfers für zwei komplanare Kreisbahnen geprüft. Kshana versteht dies als Schicht zur Leistungssimulation oberhalb von GMAT/Orekit, nicht als Ersatz (Zweige mit mehreren Umläufen und eine reale Planetenephemeride bleiben außerhalb des Umfangs). Zehn Tests.
• Vollständiger eng gekoppelter GNSS/INS-UKF mit 17 Zuständen und Quanten-CAI-Koppelnavigation. Neues src/fusion/tightly_coupled17.rs trägt den vollständigen Inertialnavigationszustand, den ein eng gekoppeltes Filter schätzt — [position, velocity, attitude-error, accelerometer bias, gyro bias, clock bias, clock drift] (17 Zustände) —, durch die Strapdown-Mechanisierung fortgeschrieben, angetrieben von der gemessenen spezifischen Kraft und Drehrate, mit der Kleinwinkel-Rotation Körper→Inertial C ≈ I + [ψ×], sodass der Lagefehler in die horizontale Beschleunigung einkoppelt (die übliche Neigungskopplung der INS). Bei einem GNSS-Ausfall läuft es allein auf der IMU weiter; das Prozessrauschen der Geschwindigkeits-Zufallsbewegung ist das abgeleitete q_va des Kaltatom-Interferometer-Beschleunigungsmessers (crate::inertial::quantum_imu), sodass die Drift der Koppelnavigation die durch den Quantensensor begrenzte ist — ein Ausfall von 120 Sekunden bleibt auf wenige hundert Meter beschränkt, gegenüber den Kilometern, die eine freie INS in Navigationsgüte erreichen würde. Das Update für Pseudostrecke/Entfernungsrate läuft über den gemeinsamen Unscented-Filter (mit α = 1 für gut konditionierte Gewichte bei dieser Zustandsgröße). Fünf Tests: Identität des Messmodells, Integration mit konstanter Geschwindigkeit bei perfekter IMU, GNSS-Stützung, Schätzung des Beschleunigungsmesser-Bias und der durch CAI begrenzte Benchmark mit 120 s Ausfall.

0.11.0 - 2026-06-05#

Geändert#

• Ehrliche Darstellung der Quantenpositionierung. Die Kernbezeichnung lautet nun einheitlich „PNT-resilience simulator with quantum-sensor performance models“ im Slogan des README, in der Zitatzeile, in CITATION.cff (Titel + Abstract) und im Bannerbild — und ersetzt die lockerere Marketingformulierung „hybrid quantum/classical PNT simulator“. Der Abschnitt What it is / is not des README erhält eine ausdrückliche Umfangsaussage „It is not (yet)“ (keine Physik-Engine für Atominterferometrie aus ersten Prinzipien, kein GNSS-Empfänger/PVT-Löser, kein Werkzeug für den Missionsentwurf), und eine neue ROADMAP.md auf oberster Ebene führt die Quantenphysik-Schicht als Punkt P2 (Phase des Mach–Zehnder-CAI, Projektionsrauschen, Vibrationstensor), damit Leser wissen, dass die Physik aus ersten Prinzipien eingegrenzt ist und folgt, nicht aufgegeben wurde. Keine Änderung von Verhalten oder API.

Hinzugefügt#

• Trade-Studie zum Konstellationsentwurf: Walker-Entwurfs-Sweep mit Pareto-Front, JSON zur Wiederkehrzeit und eine Validierung der Walker-Formel unter einem Kilometer. src/walker.rs erhält walker_design_sweep, das ein Raster planes × sats_per_plane (z. B. eine Trade-Studie 3×3) bei fester Inklination ausführt und je Entwurf den Abdeckungsanteil, den ungünstigsten PDOP und die maximale/mittlere Lücke der Wiederkehrzeit tabelliert; pareto_front markiert die nicht dominierten Entwürfe (weniger Satelliten, mehr Abdeckung, niedrigerer PDOP, kürzere Wiederkehrzeit), und WalkerDesignReport::to_json serialisiert die Zellen und die Pareto-Front — einschließlich der Felder zur Wiederkehrzeit — als JSON. Eine neue Validierung legt den Generator auf die Walker-Formel i:T/P/F fest: Satelliten desselben Slots in benachbarten Ebenen lassen sich nachweislich durch eine exakte Rotation R_z(2π/P) aufeinander abbilden, auf unter 1 km über volle 24 h SGP4-Propagation (das kurzperiodische „Atmen“ durch J2 ist gleichphasig und hebt sich auf), und die Slots innerhalb der Ebene sind im Mittel mit Abstand 2π/S bestätigt. Baut auf dem eingecheckten realen Celestrak-Snapshot gps-ops vom 2021-07-28 auf (scenarios/orbit-sgp4-gps.toml, von den Tests zur Szenarioabdeckung und zum SP3-Roundtrip genutzt).
• Fortgeschrittene Zeit- und Frequenzübertragung: TWSTFT, GNSS Common-View, PPP, optisch, Potenzgesetz-Anpassung nach IEEE-1139 und ein Uhrenensemble. Neues src/timetransfer_adv.rs baut die operativen Übertragungsverfahren auf den ausgelieferten geschlossenen Ausdrücken für Sagnac/Common-View und den Werkzeugen zur Allan-Stabilität auf. twstft_sagnac liefert die Sagnac-Korrektur der Two-Way Satellite Time and Frequency Transfer als Schleifensumme über drei Hops, exakt gleich dem geschlossenen Ausdruck des BIPM Δt = 2·A·ω_E/c² (durch das unabhängige twstft_sagnac_bipm gegengeprüft); run_twstft gibt eine eintägige Reihe T_A − T_B und ihre TDEV aus. gnss_common_view_series bildet Einzeldifferenzen zweier synthetischer Bodenstationen, sodass sich die Satellitenuhr aufhebt. iono_free_combination + ppp_receiver_clock sind die ionosphärenfreie PPP-Kombination und die Lösung der Empfängeruhr gegen eine (synthetische) Wahrheit in SP3-Güte, die die Ionosphäre erster Ordnung exakt aufhebt. rytov_variance, fried_parameter und das mittelwerteinheitliche lognormal_fading modellieren die durch Turbulenz bedingte Szintillation einer optischen Freiraumstrecke. fit_power_law_psd ist eine vollständige Kleinste-Quadrate-Anpassung der Allan-Varianzkurve mit fünf Koeffizienten h_α nach IEEE-1139 (alle fünf kanonischen Rauschprozesse zugleich), wobei der dominante Prozess je τ-Dekade ausgewiesen wird. ensemble_timescale bildet eine mit der inversen Varianz gewichtete Papier-Zeitskala, deren Allan-Abweichung streng unter der der besten beitragenden Uhr liegt. 31 Unit-Tests; die Validierungsziele sind geschlossene Ausdrücke und synthetische Wahrheit — das Einlesen echter Daten aus BIPM Circular-T / IGS SP3 steht noch aus.
• IONEX-Ionosphärenkarten: Dateiparser, zeitliche Interpolation und Abbildung über die Schrägneigung. src/ionex.rs erhält parse_ionex, das das Dateiformat IONEX (Kopfzeile mit Gitterdefinition + Blöcke START/END OF TEC MAP) in eine Folge von IonexMap einliest — dabei wird die Breitenordnung der Datei von Nord nach Süd in ein TecGrid mit positiver Schrittweite normiert und die Werte werden mit 10^EXPONENT skaliert. interpolate_tec_in_time mischt zwei aufeinanderfolgende Karten auf eine Abfrageepoche, und obliquity_factor / slant_tec bilden das vertikale TEC über den Faktor der dünnen Einzelschicht M(z) = 1/cos z′ (sin z′ = (Rₑ/(Rₑ+H))·sin z) auf einen schrägen Strahl ab. Zusammen mit dem ausgelieferten Gittermodell machen sie aus einer gemessenen globalen IGS-Ionosphärenkarte eine brauchbare Schrägverzögerung.
• Konstellationsentwurf: Dimensionierung nach Streets-of-Coverage + Vergleich mehrerer Konstellationen. src/walker.rs erhält min_satellites_streets_of_coverage, einen idealisierten Löser für die Mindestzahl von Satelliten nach Streets-of-Coverage — aus dem ausgelieferten Abdeckungs-Halbwinkel λ und der Halbbreite der Straße c dimensioniert er die fast polare Konstellation für kontinuierliche einfache globale Abdeckung zu p = ⌈π/(2c)⌉ Ebenen (z. B. braucht eine Ebene mit 4 Satelliten in GPS-Höhe 2 Ebenen, 8 Satelliten) und meldet None, wenn die Satelliten zu dünn verteilt sind, um eine kontinuierliche Straße zu bilden. compare_constellations ist das Werkzeug zum Vergleich mehrerer Konstellationen: Es bewertet jeden benannten Walker-Entwurf an derselben Station/im selben Fenster über pdop_sweep und gibt Abdeckung / PDOP / Größe nebeneinander zurück. Ehrlicher Umfang: Die nahtgenaue Rider-Korrektur an der Grenze gegenläufiger Ebenen und ein 3D-Abdeckungsglobus sind Folgearbeiten.
• Mehrschichtige Spoofing-Erkennung: Paritätsdetektor zur RAIM-Konsistenz + Schichtfusion. src/spoof_monitors.rs erhält die dritte und letzte Erkennungsschicht und die Fusionsstufe: parity_raim_test passt die Lösung aus Position/Uhr per kleinsten Quadraten an einen redundanten Satz von Pseudostrecken an und prüft die verbleibende gewichtete Residuenquadratsumme gegen ihre Schwelle χ²(m−4) — dabei wird eine verzerrte Teilmenge der Satelliten markiert, während ein gleichphasiger Bias (von der Empfängeruhr absorbiert) korrekt für RAIM unsichtbar bleibt und nicht überdeckt wird. fuse_spoof_layers kombiniert die Schichten Parität, AGC und SQM zu einer gewichteten Entscheidung, die festhält, welche Schichten ausgelöst haben. Eine Monte-Carlo-Studie charakterisiert den Detektor: empirisches P_fa ≈ 0,068 gegenüber einem Entwurfspunkt von 0,05, mit einer Fehlerkennungsrate, die von 0,885 bei einem Spoofing-Bias von 2σ auf 0,16 bei 8σ sinkt. Ehrlicher Umfang: Die Gegenvalidierung gegen bestimmte veröffentlichte Spoofing-Testvektoren (Spirent / ION GNSS+) erfordert diese externen Datensätze und bleibt eine Folgearbeit.
• Validierungsensemble gekoppeltes vs. entkoppeltes Kalman-Filter. Eine Monte-Carlo-Studie mit 100 Läufen in src/fusion/coupled.rs beziffert den Nutzen, die Kreuzkovarianz Position↔Uhr mitzuführen: Eine getreue entkoppelte Basislinie im Code (bitgenau gegen das ausgelieferte CoupledPntFilter validiert) verarbeitet dieselben Daten mit auf null gesetzten Kreuzblöcken, und nach fast entarteten Pseudostrecken plus einer reinen Uhrenkorrektur gewinnt das gekoppelte Filter die Position auf 2,97 m RMS gegenüber 48,8 m beim entkoppelten Filter zurück und gewinnt 97 von 100 Läufen — die Uhrenkorrektur schärft die Position nur durch die Korrelation, die das entkoppelte Paket verwirft. Damit ist die Validierungssuite zur Korrektheit des Kalman-Filters vollständig (Joseph-Form, PSD-Sicherheit, Konsistenz NEES/NIS und nun das Ensemble des gekoppelten Filters).
• Pipeline zur Bahnbestimmung (Batch + sequenziell). Ein neues src/orbit_determination.rs gewinnt den Bahnzustand [r, v] eines Satelliten aus der Entfernungsverfolgung von Bodenstationen zurück und setzt dazu drei ausgelieferte Bausteine zusammen: Das Kraftmodell aus Zweikörper + J2 (src/forces.rs) und der RK4-Integrator (src/integrator.rs) propagieren einen Kandidatenzustand über den Bogen, ein Entfernungsmessmodell sagt jede Stationsentfernung voraus, und der Gauss–Newton-Batch-Korrektor (src/batch_ls.rs) führt den Kandidaten auf den am besten passenden Zustand (determine_orbit_batch). Dieselbe Dynamik und dasselbe Entfernungsmodell treiben auch eine sequenzielle rekursive Bestimmung mit dem ausgelieferten Unscented-Filter (determine_orbit_sequential). Vier Tests validieren es: Entfernungsvorhersage über den Bogen; Batch-Rückgewinnung auf unter einen Meter / mm·s⁻¹ aus rauschfreien Entfernungen; Batch-Rückgewinnung auf ~2 m mit einem Residuum nach der Anpassung am Rauschboden von 5 m (das Merkmal einer konsistenten Anpassung nach kleinsten Quadraten); und sequenzielle Rückgewinnung auf einige zehn Meter. Ehrlicher Umfang: Entfernungsrate/Doppler und Winkelmessungen, eine analytische Zustandsübergangsmatrix für J2 und die Sichtbarkeitsmaskierung von Stationen sind Folgearbeiten.
• Eng gekoppelter GNSS/INS-UKF-Navigator. Ein neues src/fusion/tightly_coupled.rs bindet den ausgelieferten Unscented-Kalman-Kern (src/fusion/ukf.rs) in einen funktionierenden eng gekoppelten Navigator über den achtdimensionalen Zustand [px,py,pz,vx,vy,vz,b,d] ein (ECEF-Position/-Geschwindigkeit sowie Bias und Drift der Empfängeruhr in Entfernungseinheiten). Er verarbeitet die rohen Satellitenmessungen — pseudorange (ρ = |p − sᵢ| + b) und range_rate/Doppler (ρ̇ = (p − sᵢ)·(v − ṡᵢ)/|p − sᵢ| + d) — statt einer vorab gebildeten Positionslösung, sodass TightlyCoupled (mit propagate/propagate_orbital/ update_gnss) auch mit weniger als vier Satelliten weiter korrigiert und GNSS-Ausfälle über seine propagierte Dynamik überbrückt. Fünf Tests validieren es durchgängig, einschließlich der Abnahmeszenarien des Meilensteins: die Geometrie von Pseudostrecke/Doppler gegen Handwerte; rauschfreie Konvergenz auf unter einen Meter mit fünf Satelliten; ein Fall mit drei Satelliten, der von ~212 m auf ~13 m konvergiert, wo sich eine PVT-Momentaufnahme gar nicht bilden lässt; ein Ausfall von 120 Sekunden bei konstanter Geschwindigkeit innerhalb von 50 m; und — die entscheidende Abnahme — ein 30-minütiger gekrümmter LEO-Durchgang (reale Bahn aus Zweikörper + J2) mit einem GNSS-Ausfall von 120 Sekunden, gehalten auf 0,77 m RMS über den Durchgang und 2,9 m im ungünstigsten Fall während des Ausfalls. Dieses Überbrücken auf der Bahn setzt das ausgelieferte Schwerefeld-Kraftmodell (src/forces.rs) und den RK4-Integrator (src/integrator.rs) zum Prozessmodell des UKF (propagate_orbital) zusammen, sodass das Filter der Krümmung der Bahn folgt — was ein Überbrücken mit konstanter Geschwindigkeit nicht kann (die Krümmung allein beträgt im LEO ~58 km über 120 s). Ehrlicher Umfang: Das Überbrücken auf der Bahn verwendet das Kraftmodell aus Zweikörper + J2 statt der rohen spezifischen Kraft der IMU (für eine antriebslose Bahnplattform fallen beide zusammen); die Aufnahme eines Fehlerzustands der Strapdown-IMU und von Iono-/Tropo-Korrekturen in der Schleife bleiben Folgearbeiten.
• Messmodell für den Kartenabgleich (gelände-/schwerereferenzierte Navigation). Ein neues src/mapmatch.rs liefert das Messmodell, das das ausgelieferte Partikelfilter mit sequenziellem Importance-Resampling (src/particle_filter.rs) zu einem funktionierenden Navigator ohne GPS macht: field_likelihood (eine gaußsche Likelihood für den Feldabgleich) und map_match_likelihood, das ein beliebiges georeferenziertes Referenzfeld — Geländehöhe (TRN) oder eine Schwereanomalie — an der Position eines Partikels abtastet und es nach der Übereinstimmung mit dem gemessenen Wert des Fahrzeugs gewichtet. Das Feld ist ein beliebiger Sampler Fn(lat, lon) -> value, sodass es sich mit dem bilinearen Gitter in src/ionex.rs oder einem Closure kombinieren lässt. Zwei Tests verankern es — die Likelihood hat bei perfekter Übereinstimmung ihr Maximum (=1) und fällt bei einer Sigma auf e^(−½), und ein Partikelfilter über einem markanten synthetischen Geländeausschnitt gewinnt die wahre Position auf 0,1 genau zurück. Ehrlicher Umfang: Die realen Referenzkarten (SRTM-Höhe, EGM/EIGEN-Schwereanomalie) und ihre Loader sind Folgearbeiten.
• Integrität von cislunarem PNT (ARAIM für den Mond). Ein neues src/lunar.rs wendet die Erd-seitige MHSS-ARAIM-Engine auf einen Mondnavigationsdienst im Stil von LunaNet an, mit den Mondparametern (σ_URE ≈ 30 m gegenüber 0,6 m bei GPS, P_sat ≈ 1e-4): Mondkonstanten, eine selenozentrische Basis Ost/Nord/Oben samt Hilfsfunktion für die Himmelsgeometrie und lunar_araim (HPL/VPL). Drei Tests verankern es — die orthonormale selenozentrische Basis, die Geometrie der Schrägentfernung und die exakte lineare Skalierung des Schutzniveaus mit σ_URE (beim Mond ergeben 30 m ein 50× größeres Schutzniveau als dieselbe Geometrie bei 0,6 m wie bei GPS — der quantitative Grund, warum die Integrität von Mond-PNT schwierig ist). Ehrlicher Umfang: Die präzise LANS-NRHO-Ephemeride, das Fehlerbudget des Signals im Raum und die Reduktion der Bezugssysteme MCI↔MCMF sind Folgearbeiten.
• Julianische Daten in zwei Teilen (hohe Genauigkeit). Ein neues src/jd2.rs fügt Jd2 hinzu, ein Julianisches Datum, aufgeteilt in einen ganzzahligen Anteil day und einen gebrochenen Anteil frac in [0,1) (die Konvention von SOFA/hifitime), mit new/from_parts/add_seconds/diff_seconds/total. Differenzen naher Epochen bleiben bis zur Grenze von f64 exakt, wo ein JD mit einem einzigen f64 nahe J2000 etwa 50 µs verliert. Vier Tests verankern es: den Hin-und-zurück-Durchlauf, die Normierung des Bruchteils, die exakte Rückgewinnung von Mikrosekunden (mit dem daneben gezeigten Versagen des einzelnen f64) und additive/umkehrbare Sekundenarithmetik.
• Writer für CCSDS OMM (Orbit Mean-Elements Message). Ein neues src/omm.rs ergänzt den Ephemeriden-Writer oem um die Nachricht mit mittleren Elementen: OmmFile::from_tle bildet mittlere Elemente von SGP4/TLE auf die Einheiten der OMM ab (mittlere Bewegung in Umläufen/Tag, Winkel in Grad, plus BSTAR), und to_omm_kvn serialisiert die Standards-Track-Form KVN nach CCSDS 502.0-B-2 — sodass eine Bahn von Kshana von jedem OMM-fähigen Werkzeug verarbeitet werden kann statt als eigens gebaute TLE. Zwei Tests verankern die Einheitenumrechnung TLE→OMM (≈ 15,5 Umläufe/Tag, 51,6° Inklination usw.) und das Vorhandensein der erforderlichen KVN-Schlüsselwörter. Ehrlicher Umfang: Die Form KVN und die Abbildung der TLE werden hier ausgeliefert; die XML-Darstellung (ndm/omm) und ein Roundtrip mit einem Referenzparser sind Folgearbeiten.
• Partikelfilter mit sequenziellem Importance-Resampling. Ein neues src/particle_filter.rs fügt den nichtlinearen, nicht gaußschen Schätzer hinter der kartengestützten Navigation ohne GPS hinzu (geländereferenziert oder durch Abgleich mit der Schwerekarte): predict (Partikel durch die Dynamik + gaußsches Prozessrauschen propagieren), update (Neugewichtung mit einer Likelihood der Messung je Partikel), systematisches resample, den Entartungsmonitor effective_sample_size und den gewichteten Mittelwert als Schätzung. Sechs Tests verankern den deterministischen Kern exakt — ESS über 1…N, systematisches Resampling, das Indizes proportional zum Gewicht wählt, die konvexe Kombination des gewichteten Mittelwerts, eine gaußsche Likelihood, die die Schätzung auf die Messung zieht, das Verhalten beim Resampling auf Gleichverteilung und deterministisches predict mit Seed. Ehrlicher Umfang: Die Engine wird hier ausgeliefert; die Referenzkarten (SRTM-Höhe, EGM-Schwereanomalie) und das Messmodell der Karte sind Folgearbeiten (der Sampler aus Gitter + bilinear in ionex würde eine Schwere- oder Geländekarte gleichermaßen bedienen).
• TEC-Ionosphärenkarten im Stil von IONEX. Ein neues src/ionex.rs fügt die gemessene Ionosphäre als Alternative zum ausgesendeten Klobuchar-Modell hinzu: ein TecGrid (ein regelmäßiges Breiten-/Längengitter des vertikalen TEC, eine globale IGS-Ionosphärenkarte) mit bilinearer Interpolation an einem Durchstoßpunkt (vtec_at, außerhalb des Gitters begrenzt) und der Verzögerung erster Ordnung Δ = 40.3·TEC/f² (vtec_to_delay_m, delay_at). Vier Tests verankern es: 1 TECU ≈ 0.162 m bei L1 mit der Skalierung 1/f², knotengenaue Interpolation, bilineare Mittelpunkte, die die Ecken mitteln, und am Rand begrenzte Abfragen außerhalb des Gitters. Ehrlicher Umfang: Das Gitter und die Interpolation werden hier ausgeliefert; das Parsen des Dateiformats IONEX, die zeitliche Interpolation zwischen Karten und die Abbildungsfunktion für die Schrägstrecke sind Folgearbeiten.
• Geometrische Korrekturen der Zeitübertragung (Sagnac + GNSS Common-View). Ein neues src/timegeo.rs fügt die zwei deterministischen Effekte hinzu, die ein realer Uhrenvergleich berücksichtigen muss, und ergänzt damit das stochastische Zwei-Wege-Modell in timetransfer: sagnac_correction (Δt = (ω_E/c²)·(x₁y₂ − x₂y₁), die Verzögerung durch die rotierende Erde — einige zehn ns bei kontinentalen Basislinien) und common_view_offset, die Einzeldifferenz GNSS Common-View, die den Fehler der Satellitenuhr exakt aufhebt und den Versatz zwischen den Stationen zurückgewinnt. Drei Tests verankern sie an exakten Referenzen: das ≈ 33 ns große Sagnac einer äquatorialen Vierteldrehung, Antisymmetrie und die Fälle radial/polar mit null sowie die exakte Aufhebung der Satellitenuhr. Ehrlicher Umfang: Ein vollständiges Budget für Transponder-/Hardwareverzögerungen bei TWSTFT und eine ionosphärenfreie PPP-Zeitübertragungslösung sind Folgearbeiten.
• Bahnkraftmodell (Zweikörper + J2). Ein neues src/forces.rs fügt das Beschleunigungsmodell hinzu, das ein numerischer Propagator integriert: two_body_accel (−μ·r/|r|³), die Störung durch die Abplattung j2_accel (der geschlossene ECI-Ausdruck) und gravity_accel, das beide summiert — in Kombination mit src/integrator.rs als f(t,[r;v]) = [v; a(r)]. Es stellt außerdem die analytischen säkularen Raten von J2 bereit (j2_secular_rates): die Knotenregression Ω̇, die Apsidendrehung ω̇ und die Drift der mittleren Anomalie Ṁ. Sechs Tests verankern die Physik an exakten Referenzen: μ/r² für den Zweikörperterm, der geschlossene Ausdruck von J2 am Äquator (~10⁻³ des Betrags des Zweikörperterms), die kritische Inklination (63,4349°), die das Perigäum festhält (ω̇ = 0), die Knotenregression der ISS (Ω̇ ≈ −5°/day) und die ostwärts gerichtete Drift einer rückläufigen sonnensynchronen Bahn. Ehrlicher Umfang: nur Zweikörper + J2; J3–J6, Widerstand, Strahlungsdruck und dritter Körper sind Folgearbeiten.
• Teilbare Permalinks für Szenarien. Ein neues src/permalink.rs fügt einen abhängigkeitsfreien Base64-Codec nach RFC 4648 hinzu (das Standard-Alphabet +/ mit Padding und ein URL-sicheres Alphabet -_ ohne Padding) sowie die Wrapper encode_scenario / decode_scenario, sodass ein TOML des Playgrounds in einen Query-Parameter ?s= kodiert und als URL geteilt werden kann. Dem Browser als WASM-Bindings encode_permalink / decode_permalink bereitgestellt. Vier Tests verankern es an den kanonischen Vektoren aus RFC 4648 ("foobar" → "Zm9vYmFy" usw.), einem URL-sicheren Roundtrip eines Szenarios (kein +///= zu maskieren), der Zurückweisung ungültiger Symbole und einem Roundtrip über alle 256 Bytes. Ehrlicher Umfang: Der Codec und die Bindings werden hier ausgeliefert; die Oberfläche der Share-Schaltfläche im Playground, das Mehrserien-Diagramm mit Plotly/D3 und der A/B-Vergleichsmodus sind Folgearbeiten.
• Batch-Kleinste-Quadrate nach Gauss–Newton (der differentielle Batch-Korrektor). Ein neues src/batch_ls.rs fügt den Schätzkern hinzu, auf dem eine Bahnbestimmung im Batch-Verfahren (oder jede Parameteranpassung) beruht: gauss_newton linearisiert ein vom Nutzer geliefertes Modell h(x) mit einer Jacobi-Matrix aus zentralen finiten Differenzen, bildet und löst die gewichteten Normalgleichungen (HᵀWH)·Δx = HᵀW·(z − h(x)) (unter Wiederverwendung der getesteten Matrixinversion) und iteriert bis zur Konvergenz mit Gewichten je Messung. Vier Tests verankern es: eine lineare Geradenanpassung, die die exakte Lösung der gewichteten kleinsten Quadrate erreicht, eine nichtlineare Anpassung a·exp(b·t), die die wahren Parameter zurückgewinnt, eine 3D-Entfernungs-Multilateration, die aus rauschfreien Entfernungen eine bekannte Position zurückgewinnt (der Geschmack der Bahnbestimmung), und die Zurückweisung unterbestimmter/nicht passender Eingaben. Ehrlicher Umfang: Dies ist die generische Korrektor-Engine; das bahnspezifische Messmodell für Entfernung/Entfernungsrate/Azimut-Elevation, die analytische Zustandsübergangsmatrix für J2 und die Validierung an veröffentlichten Fällen sind Folgearbeiten.
• Spoofing-Monitore auf HF-Ebene (AGC-Leistung und SQM). Ein neues src/spoof_monitors.rs fügt zwei unabhängige Spoofing-Detektoren am Empfänger-Frontend hinzu, die den uhrgestützten Monitor für Zeit-Spoofing in spoof ergänzen: einen AGC-Leistungsmonitor (inkohärente Leistungssumme combine_power_dbm + AgcMonitor), der die über einen konfigurierbaren dB-Spielraum hinausgehende zusätzliche Empfangsleistung markiert, die ein Spoofing-Sender hinzufügt, und einen Signalqualitätsmonitor (dreieckige Code-Autokorrelation bpsk_autocorr + SqmMonitor), der das Ungleichgewicht der Korrelatoren Early minus Late markiert, das Mehrwegeausbreitung/Meaconing/Replay hervorrufen. Vier Tests verankern die exakten geschlossenen Ausdrücke (3,01 dB bei einer Verdopplung der Leistung, die Summe 10·log10(N), das dreieckige R(τ)=1−|τ| und die Alarmschwelle Early/Late von 10 %). Ehrlicher Umfang: Der vollständige Paritätsdetektor für Spoofing nach RAIM-Konsistenz, die Mehrschicht-Fusion der Ausgaben der Monitore und die Validierung gegen veröffentlichte Spoofing-Vektoren von Spirent/ION GNSS+ sind Folgearbeiten.
• Adaptiver numerischer ODE-Integrator. Ein neues src/integrator.rs fügt das erste Stück eines numerischen Propagators hinzu (die Bahnpropagation von Kshana ist sonst analytisches SGP4/SDP4): einen generischen Runge-Kutta-Schritt vierter Ordnung (rk4_step) über jedes System erster Ordnung y' = f(t, y) und einen adaptiven Treiber (integrate), der den lokalen Fehler durch Schrittverdopplung (Richardson-Extrapolation) mit dem üblichen Schrittregler 0.9·(tol/err)^(1/5) und der Logik für Annahme/Ablehnung steuert. Sechs Tests verankern ihn an exakten Lösungen: die Exponentialfunktion y' = y → e auf < 1e-9, die Fehlerreduktion um ~16× je halbiertem Schritt, die die Konvergenz vierter Ordnung belegt, die Erhaltung von Energie/Rückkehr des harmonischen Oszillators über eine volle Periode und der adaptive Treiber, der mit variablen Schritten eine enge Toleranz einhält. Ehrlicher Umfang: Dies ist der Integratorkern mit seiner Fehlersteuerung; die eingebetteten Tableaus Dormand–Prince RK5(4)/RKF7(8) und das hierarchische Bahnkraftmodell (Zweikörper + J2–J6 + Widerstand + Strahlungsdruck + dritter Körper), die ihn zu einem NumericalPropagator machen, sind Folgearbeiten.
• Unscented-Kalman-Filter (Sigma-Punkte). Ein neues src/fusion/ukf.rs fügt das skalierte Unscented-Kalman-Filter (Julier & Uhlmann; Wan & van der Merwe) als allgemeinen Schätzer mit n Zuständen über vom Nutzer gelieferte Prozess- und Messfunktionen hinzu — den Sigma-Punkt-Schätzer, den ein eng gekoppelter GNSS/INS-Navigator verwendet, wenn das Modell für Pseudostrecke/Doppler stark nichtlinear ist und die Jacobi-Matrix eines EKF schlechter wird. Es enthält die zugehörige dichte lineare Algebra (Cholesky-Faktor für die Streuung der Sigma-Punkte, Gauss–Jordan-Inverse für die Innovationskovarianz) und ein Joseph-freies Update P⁺ = P⁻ − K S Kᵀ. Sechs Tests legen es fest, die wichtigsten nutzen die exakte Eigenschaft, dass die Unscented-Transformation für ein lineares Modell das Kalman-Filter bis auf numerische Genauigkeit reproduziert (predict, update und ein vollständiger Zyklus aus predict+update jeweils gegen ein von Hand gerechnetes lineares KF abgeglichen, dazu eine 1D-analytische Prüfung der bayesschen Posteriori und die Identitäten von Cholesky/Inverse). Ehrlicher Umfang: Dies ist die Schätzer-Engine; der eng gekoppelte GNSS/INS-Navigator mit 17 Zuständen, das Messmodell für Pseudostrecke/Doppler und das Szenario zur Validierung des Ausfalls bleiben Folgearbeiten.
• Schutzniveaus für ARAIM mit zwei Konstellationen. Ein neues araim_dual_raim erweitert das Advanced RAIM für Einzelfehler (araim_raim) um den konstellationsweiten Fehlermodus von EU-ARAIM / DO-316: Neben den Hypothesen fehlerfrei und je Satellit liefert jede Konstellation (je Satellit gekennzeichnet) eine Hypothese, die alle ihre Satelliten auf einmal entfernt, mit der A-priori-Wahrscheinlichkeit P_const (ein neues DualFaultPriors { p_sat, p_const }). Jede Hypothese fügt der Integritätssumme von MHSS einen Term hinzu, sodass VPL/HPL die kleinsten Schranken sind, deren Summe P_HMI das Budget über fehlerfrei + einzelner SV + Fehler je Konstellation einhält (die Aufteilung der Bonferroni-Fehlalarme erfolgt über alle N + C Hypothesen). Mit P_const = 0 ist das Ergebnis bitgleich mit araim_raim; ein Nutzer mit einer einzigen Konstellation erhält gegenüber dem Fehler seiner eigenen Konstellation None zurück (sie lässt sich nicht ausschließen) — genau deshalb ist die Abdeckung mit zwei Konstellationen wichtig. Vier Tests decken die Äquivalenz, die Aufweitung des Schutzniveaus, die Nichtverfügbarkeit bei einer einzigen Konstellation und die Eingabevalidierung ab und verwenden dabei die bestehende Maschinerie der Teillösungen mit Lösungstrennung wieder.
• Präzession nach IAU 2006 (Winkel nach Fukushima–Williams und Matrix für Bias-Präzession). Ein neues src/precession.rs implementiert die Präzession nach IAU 2006 (P03; Capitaine, Wallace & Chapront 2003): die vier Winkel nach Fukushima–Williams (γ̄, φ̄, ψ̄, ε̄_A) als Polynome in Julianischen Jahrhunderten der TT (fw_angles) und die Rotationsmatrix für Bias-Präzession von GCRS nach mittlerem Datum, über die SOFA-Konstruktion iauFw2m daraus aufgebaut (precession_matrix, mit den Hilfsfunktionen gcrs_to_mod / mod_to_gcrs). Dies ist das erste Stück eines inertialen Bezugssystems über der bestehenden GMST-basierten Reduktion frames. Acht Tests validieren gegen geschlossene Anker — die mittlere Schiefe der Ekliptik für J2000 ε̄ = 84381.406″ = 23.4392794°, die veröffentlichten konstanten Terme der Winkel, die Akkumulation der allgemeinen Präzession ψ̄ ≈ 5039.998″ über ein Jahrhundert, Orthonormalität der Matrix und det = +1, den Wert nahe der Identität (nur Bezugssystem-Bias) bei J2000 und den Nettodrehwinkel ≈ 1.40°/Jahrhundert. Ehrlicher Umfang (ROADMAP.md): nur Präzession — die Nutation IAU 2000A mit 678 Termen, die vollständige Kette TEME→GCRS und eine numerische Gegenprüfung mit SOFA/ANISE auf µas/<10 m sind Folgearbeiten.
• Physik des Beschleunigungsmessers mit Kaltatom-Interferometer (CAI) aus ersten Prinzipien. src/inertial/quantum_imu.rs modelliert ein Atominterferometer nach Mach–Zehnder mit drei Pulsen aus ersten Prinzipien statt aus einem Datenblatt: effektiver Wellenvektor k_eff = 4π/λ, Interferometerphase Φ = k_eff·a·T², Quantenprojektionsrauschen (Schrotrauschen) σ_Φ = 1/(C·√N), Beschleunigungsempfindlichkeit je Schuss, Kontrastabfall C(t) = C₀·e^(−t/τ) und — darauf kommt es an — CaiAccelerometer::q_va(), das die weiße Beschleunigungs-PSD, die das klassische AccelModel bereits verarbeitet, aus Atomzahl, Abfragezeit und Kontrast ableitet. Das Modell deckt nun auch die Kopplung von Vibrationen ab — den dominanten Term realer Geräte: die Übertragungsfunktion Beschleunigung→Phase des Interferometers |H(ω)| = (4/ω²)sin²(ωT/2) (accel_transfer_function), die Phasenvarianz bei weißer PSD σ_Φ² = k_eff²·S_a·T³/3 (vibration_phase_variance_white, mit einer numerischen Gegenprüfung durch ein Bandintegral vibration_phase_variance_band), die Rang-1-Größe beam_axis_projection entlang des Strahls sowie CaiAccelerometer::vibration_phase_noise / vibration_limited_accel (letzteres reduziert sich auf den von k_eff unabhängigen Boden √(S_a/(3T))). Elf Tests prüfen die Physik von Hand nach (Rb-87 k_eff ≈ 1.61×10⁷, Φ(1 g) ≈ 1.58×10⁴ rad, σ_a ≈ 0.13 µg/Schuss als Boden des Schrotrauschens gegenüber einem Vibrationsboden von ≈ 5,9 µg, die Skalierungsgesetze 1/T², 1/√N und T³). Ehrlicher Umfang in docs/QUANTUM.md: Dies umfasst den Boden des Projektionsrauschens und das darüber liegende vibrationsbegrenzte Regime; Laserphasenrauschen, Systematiken von Coriolis und Lichtverschiebung sowie die Validierungsszenarien PHARAO/CARIOQA bleiben Folgearbeiten.
• Quanten-CAI-Beschleunigungsmesser in das Inertialszenario eingebunden. Ein Beschleunigungsmesser in einem Szenario der inertialen Koppelnavigation wird nun zu einem neuen ImuKind aufgelöst — Classical (der bestehende Sensor mit Datenblattkoeffizienten) oder QuantumCai, wenn er einen optionalen Block [cai] trägt (CaiCfg: Wellenlänge, Pulsabstand, Atomzahl, Kontrast, Zykluszeit und eine optionale vibration_psd der Plattform). Die PSD der Geschwindigkeits-Zufallsbewegung q_va eines Sensors quantum_cai wird aus der Physik des Interferometers abgeleitet — dem Boden des Schrotrauschens plus, wenn eine Vibrations-PSD angegeben ist, dem vibrationsbegrenzten Beitrag quadratisch addiert — statt aus einem gelieferten Koeffizienten, und die Herkunft des Laufs hält fest, dass das Rauschen physikalisch abgeleitet ist. Das Feld cai ist skip_serializing_if = "Option::is_none", sodass bestehende Szenarien es auslassen und bytegleich serialisiert werden (der Hash des Szenarios ist unverändert). Fünf Tests decken die Ableitung, die quadratische Summe der Vibration, die Auswahl Classical/QuantumCai, die hashstabile Serialisierung und einen durchgängigen Lauf mit CAI-Antrieb ab.
• Optimierer für den Konstellationsentwurf und Geometrie nach Streets-of-Coverage. src/walker.rs erhält optimize_walker_design, einen gradientenfreien Gitteroptimierer, der den Entwurfsraum {planes × sats × inclination} durchsucht und den besten Walker-Entwurf unter einem gewählten DesignObjective — MinSatellitesForCoverage, MaxCoverage oder MinWorstPdop — über den bereits validierten PDOP-Sweep zurückgibt (ein Test bestätigt, dass er den Gewinner der Brute-Force-Suche liefert). Dazu kommen die analytischen geschlossenen Ausdrücke nach Streets-of-Coverage coverage_half_angle_rad (λ = arccos(Re/r·cos ε) − ε) und street_half_width_rad (cos c = cos λ / cos(π/s), Rider/Beste), von Hand gegen die Geometrie aus Lehrbüchern geprüft und mit Erkennung der Lücke bei zu dünner Besetzung. Der vollständige Löser nach Rider für die Mindestzahl von Satelliten bei globaler Abdeckung, ein 3D-Globus im Playground und eine DOP-Gegenprüfung mit einem externen Werkzeug bleiben Folgearbeiten.
• Export der präzisen Ephemeride als SP3 aus der CLI. Ein propagiertes Szenario für Bahn/Konstellation lässt sich nun in eine SP3-c-Datei schreiben: kshana <orbit.toml> --export-sp3 out.sp3, oder export_sp3 = true im Szenario schreibt <scenario>.sp3 automatisch (api::export_sp3 / auto_export_sp3, OrbitClockScenario::to_sp3_string, optional epoch). Ein Roundtrip-Test (tests/sp3_export_roundtrip.rs) propagiert den realen Celestrak-Snapshot gps-ops, exportiert ihn, parst ihn erneut und bestätigt, dass die zurückgewonnenen ECEF-Positionen über 24 h mit der Wahrheit von SGP4 auf < 0,5 m übereinstimmen (deutlich innerhalb der Toleranz von 10 m in TLE-Güte). Das README dokumentiert die Rolle für die Interoperabilität (RINEX → RTKLIB/gLAB, SP3 → Ginan/Produkte für präzise Bahnen).
• Gekoppeltes Kalman-Filter für Uhr+Position (Kovarianz mit Kreuzblock). src/fusion/coupled.rs CoupledPntFilter ist ein einziges gestapeltes Filter [pos, vel, phase, freq] (Updates in Joseph-Form), dessen Messung der Pseudostrecke ρ = g·pos + c·phase + noise die Blöcke von Position und Uhr tatsächlich koppelt — anders als die zwei unabhängigen Filter mit je zwei Zuständen im älteren Fusionspaket, die die Kovarianz des Kreuzblocks exakt bei null halten. Validiert: Eine gemeinsame Pseudostrecke treibt P[pos,phase] auf einen Wert ungleich null; zwei verschiedene Geometrien lösen gemeinsam eingebrachte Versätze von Position+Uhr auf, die eine einzelne Entfernung nicht trennen kann; eine reine Uhrenkorrektur schärft die Position über die Kreuzkovarianz (der Gewinn, den entkoppelte Filter nicht liefern können); und das Monte-Carlo-NEES ist mit χ²(4) konsistent. Dies ist die Realisierung mit 1 Freiheitsgrad (die Dimensionalität des Fusionspakets); die 3D-Erweiterung auf 8 Zustände und die Einbindung in das lauffähige Paket sind als Folgearbeiten verfolgt.
• Überwachung der Konsistenz des Kalman-Filters (NIS/NEES). Die Kovarianzaktualisierung des Uhrenfilters mit zwei Zuständen liegt nun in der stabilisierten Joseph-Form `P⁺ = (I−KH)P(I−KH)ᵀ
  • KRKᵀ, which stays positive-semidefinite under extreme Q/R ratios (Cholesky-checked in CI at R=1e-26 / Q≈1e-30). A new src/filter_health.rsruns a Monte-Carlo consistency assessment (Bar-Shalom §5.4): pooled **NIS** (normalised innovation², target 1) and **NEES** (normalised estimation error², target 2) against 95% χ² bands, surfaced as afilter_health { nis_mean, nis_chi2_lower_95, nis_chi2_upper_95, nees_mean, nees_chi2_lower_95, nees_chi2_upper_95, consistent } block in the clock result JSON and as a green/amber card in the playground. A Q/R-mismatch sweep test proves the monitor flips to inconsistent when the process noise is mistuned by ×0.1–×10. Adds a general χ² quantile (detection::chi2_inv_cdf`, Wilson–Hilferty, tabellengeprüft).
• docs/PROVENANCE.md — eine einzige zitierbare Herkunftstabelle. Fasst jeden Sensorparameter (Uhren, Inertial, Zeitübertragung), jedes physikalische/algorithmische Modell (Bahn, Zeitsysteme, Bezugssysteme, Iono/Tropo, Integrität, Erkennung, Jamming, Allan) und jeden Validierungsdatensatz (AIAA 2006-6753, Celestrak gps-ops) mit seiner veröffentlichten Quelle zusammen — Datenblatt, Paper, ICD oder Norm — und einer ehrlichen Reifebezeichnung (flugqualifiziert / Bodenlabor / Weltraumziel auf Bodenhardware). Aus der Einleitung des README und der Dokumentationstabelle verlinkt; ergänzt die Zeichenfolgen provenance je Lauf, die bereits im Ergebnis-JSON mitreisen.
• Typisierte Szenario-API. Der Dispatch erfolgt nun über ein typisiertes Enum ScenarioKind statt über einen rohen Vergleich der Zeichenfolge kind (ScenarioKind::classify + erschöpfender Dispatch), sodass das Hinzufügen eines Pakets vom Compiler geprüft wird. Neue typisierte Oberflächen neben dem unveränderten, eine Zeichenfolge zurückgebenden run_toml: run_scenario(src) -> Result<RunOutput, KshanaError> mit einer strukturierten Fehlertaxonomie (InvalidInput / NonConvergence / Unsupported / IoError, jeweils mit einem stabilen kind_tag()); ein Trait Scenario und ein Erweiterungspunkt ExternalPack (das Paket jamming ist als durchgerechnetes Beispiel darüber verdrahtet); und eine Introspektion über list_scenario_kinds() (Name, Beschreibung, erforderliche/optionale Felder je Typ). Die Bindings für Python und WebAssembly erhalten list_kinds() und error_kind(). Dokumentiert in docs/ARCHITECTURE.md.
• Reale GPS-Konstellation + Abdeckung des Betriebsbereichs. scenarios/orbit-sgp4-gps.toml liefert nun einen realen Celestrak-Snapshot gps-ops (2021-07-28, 30 Satelliten) statt synthetischer Walker-TLEs, mit strict_checksum = true, sodass er nur geladen wird, wenn jede TLE-Prüfsumme gültig ist; scripts/fetch_tles.sh dokumentiert die reproduzierbare Aktualisierung, und das README nennt die offene Datenquelle. Der neue tests/scenario_coverage.rs übt jedes Paket über ≥5 Varianten des Betriebsbereichs und stellt dabei endliche/beschränkte Ausgaben fest, bestätigt, dass der Flicker-FM-Boden das Überbrücken einer Uhr messbar verschlechtert, wenn er aktiviert ist (nun in drei ausgelieferten Szenarien gesetzt), und bestätigt, dass das Fusionsfilter mit einem realistischen Bias des Beschleunigungsmessers ungleich null konvergiert (innerhalb des 3-Fachen des Falls mit auf null gesetzten Biases), womit die Realismuslücke „Fusion funktioniert nur mit auf null gesetzten Biases“ geschlossen wird. docs/VALIDATION.md erhält eine Tabelle zum Betriebsbereich.
• GNSS-Simulation im Messraum (Typ gnss-sim). Ein Vorwärtsmodell auf Pseudostreckenebene: Je sichtbarem Satelliten synthetisiert es ρ = geometric range + c·δt_rx − c·δt_sv + I + T + noise + multipath und den L1-Doppler, mit der Einzelfrequenz-Ionosphäre nach Klobuchar (IS-GPS-200 §20.3.3.5.2.5) und der Zenit-Troposphäre nach Saastamoinen, mit der Abbildungsfunktion nach Niell (1996) projiziert — bereitgestellt als TOML-Blöcke [iono] und [tropo]. Die Residuen speisen ein Snapshot-RAIM für HPL/VPL je Epoche, und ein JSON-Array gnss_measurements[] trägt je SV die Pseudostrecke, den Doppler, C/N₀ und die Korrekturen für Iono/Tropo. Ein Lauf ohne Rauschen reproduziert Geometrie + Korrekturen auf unter einen Millimeter (CI-Test). Neu: src/gnss_sim.rs und scenarios/gnss-sim-raim.toml.
• Stochastischer Detektor für Zeit-Spoofing (Typ spoof). Das Paket Spoof führt nun einen echten Detektor aus statt eines deterministischen Vergleichs von Rampe und Schranke: vier Einspeiseformen (linear_ramp, step_jump, meaconing, replay), einen zweiseitigen Energietest χ²₁ / nach Neyman–Pearson auf der Monitorstatistik mit Uhrenstützung, wobei die Schwelle aus einem Zielbudget für Fehlalarme target_pfa festgelegt wird, und die Wahrscheinlichkeit der Fehlerkennung P_md, sowohl als geschlossener Ausdruck als auch per Monte-Carlo ausgewiesen (mc_runs Läufe je Hypothese — beide stimmen bis auf einige ×1/√N überein). Das Gütemaß Security ist nun 1 − P_md bei der operativ schädlichen Größe (Spezifikation). Neu: src/detection.rs (gaußsche Schwanzfunktionen, NP-/Energietest, Monte-Carlo P_fa/P_md) und scenarios/spoof-meaconing.toml. Abwärtskompatibel: Ein einfaches [attack] rate_ns_per_s wird weiterhin als lineare Rampe akzeptiert.

Geändert#

• Definition des Gütemaßes Security (Typ spoof): von der analytischen Erkennbarkeitsschranke 1 − min_detectable/threshold zu 1 − P_md des stochastischen Detektors. Das Feld security des Uhrenpakets bleibt der schnellere analytische Stellvertreter.

Hinzugefügt (Fortsetzung)#

• HF-Jamming-Modell (Typ jamming). Ein Störungsmodell auf Basis des Link-Budgets, das Leistung und Geometrie eines Jammers in den Verlust der Verfolgung je Satellit übersetzt: das Verhältnis von Jammer zu Signal aus der Freiraumdämpfung und dem Gewinn der Empfangsantenne je Richtung, das effektive C/N₀ über die Standardgleichung für Anti-Jam (Spreizgewinn der Entspreizung × der Faktor der spektralen Trennung Q; Kaplan & Hegarty §9,4) und eine konfigurierbare Verfolgungsschwelle, über eine Walker-Konstellation als Gütemaß availability_under_jamming bewertet. Neu: src/jamming.rs und scenarios/jamming-demo.toml. Der ehrliche Umfang (keine Mehrwegeausbreitung, keine Geländeabschattung, kein AGC, kein adaptives Nullen) ist in docs/CAPABILITY.md / docs/VALIDATION.md dokumentiert.
• Generischer N-D-Parameter-Sweep über jeden Szenariotyp (sweep-nd). Der bisherige N-D-Sweep galt nur für das Uhrenpaket. sweep-nd variiert gepunktete TOML-Schlüssel eines Szenarios [base] über das kartesische Produkt seiner Achsen, schickt jeden Gitterknoten erneut über den normalen Laufpfad und liest eine oder mehrere Kennzahlen über einen gepunkteten JSON-Pfad aus dem Ergebnis aus — sodass er für jedes Paket funktioniert (inertial, gnss-ins, integrity, spoof, …), ohne an den Rust-Typ des jeweiligen Pakets gebunden zu sein. Auf nativen Zielplattformen werden die Gitterknoten parallel über Betriebssystem-Threads ausgewertet (ohne zusätzliche Abhängigkeit); wasm fällt auf sequenzielle Ausführung zurück. Deterministisch und zeilenweise unabhängig von der Zahl der Threads. Neues Beispiel scenarios/sweep-nd-inertial.toml.
• Per TOML konfigurierbares deterministisches IMU-Fehlermodell im Paket gnss-ins. Die dreiachsige Strapdown-Fehlerkette (Skalenfaktor, Fehlausrichtung, g-Empfindlichkeit, Quantisierung, Ratenrampe; IEEE Std 952-1997 §A.2, Groves 2013 §4,3) ist nun je Sensor über einen optionalen Block [imu_*.error_model] aus einer Szenariodatei erreichbar und legt sich über die konstanten Einschaltbiases. Wird der Block weggelassen, bleibt jeder Sensor eine reine Quelle mit konstantem Bias, sodass bestehende Läufe von gnss-ins unverändert sind. Damit wird das zuvor nur in der Bibliothek vorhandene Fehlermodell in ein lauffähiges Paket und ein Gütemaß eingebunden.

0.10.0 - 2026-06-04#

Geändert#

• Validierung mit realen Daten. Der Parser für RINEX-Navigationsdateien mit mehreren GNSS, der RK4-Propagator für GLONASS und der SP3-Reader werden nun gegen echte Dateien von IGS/DLR geübt (eine reale gemischte RINEX-3-Broadcast-Navigationsdatei und ein SP3-c-Bahnprodukt des IGS), nicht nur gegen selbst verfasste Beispiele — wobei nicht leere Satellitenmengen und endliche, physikalisch plausibel große ECEF-Positionen festgestellt werden. Die Fixtures dienen nur Tests (vom veröffentlichten Crate ausgenommen); siehe tests/fixtures/igs/NOTICE.
• RAIM auf der Geometrie realer Referenzbahnen. Die Kerne für Snapshot, Lösungstrennung (MHSS) und das Schutzniveau von ARAIM sind nun gegen die reale Geometrie der präzisen IGS-Bahnen (SP3) validiert, nicht allein gegen synthetische Konstellationen: Die Geometrie der Sichtlinien wird aus der ersten SP3-Epoche an einer realen Bodenstation aufgebaut, und die Tests stellen Schutzniveaus im Meterbereich mit Verfügbarkeit nach APV-I fest, dass ein Bias der Pseudostrecke von 60 m den χ²-Monitor auslöst, dass die Lösungstrennung den fehlerhaften Satelliten identifiziert und dass die Niveaus von ARAIM das zugewiesene P_HMI einhalten. Damit wird die Lücke geschlossen, nur auf synthetischer Geometrie validiert zu sein (die Parität mit gLAB im Empfängerbereich über einen vollständigen RINEX-Bogen bleibt ein Punkt der Roadmap — sie braucht eine Lösung der Pseudostrecke).

Hinzugefügt#

• Konfidenzintervalle je Knoten für den N-D-Parameter-Sweep (sweep::nd_sweep_ensemble). Jeder Gitterknoten des N-dimensionalen Sweeps über das kartesische Produkt kann nun als Monte-Carlo-Ensemble von Seeds ausgewertet werden und weist je Knoten den Mittelwert, die Perzentile und ein Perzentil-Bootstrap-KI von 95 % der Kennzahl aus (für beide Uhren) — ein statistisch ehrlicher Sweep statt einer einzelnen Ziehung je Knoten. Verwendet die Maschinerie für Ensemble/Bootstrap wieder (metric_stat); deterministisch; runs = 1 reduziert sich exakt auf den nd_sweep mit einem Seed. (Die Verallgemeinerung des Sweeps auf alle Pakete, verflochten mit dem Refactoring des typisierten Szenarios, und die parallele Ausführung stehen noch aus.)
• NaveGo-Kreuzvalidierung der IMU-Rauschpipeline (tests/navego_imu_crossval.rs). Eine externe Gegenprüfung mit NaveGo (der Open-Source-INS/GNSS-Toolbox von R. Gonzalez): Sie reproduziert den synthetischen Round-Trip von navego_example_allan.m auf dem veröffentlichten Referenzprofil des Microstrain 3DM-GX3-35 und bestätigt, dass unser überlappender ADEV-Schätzer die Koeffizienten des Geschwindigkeits- und Winkel-Random-Walk von NaveGo (ADEV(1 s) = σ·√dt) auf unter 5% genau wiedergewinnt, mit der erwarteten Steigung von −1/2 für weißes Rauschen. (Das 40 MB große aufgezeichnete STIM300-.mat-Log wird nicht eingelesen — durch das Binärformat blockiert.)
• Eng gekoppeltes (Pseudorange-)GNSS/INS-Update. GnssInsEkf::update_tightly_coupled (und der Wrapper ClosedLoopInsGnss::fuse_tightly_coupled) implementieren die zuvor nur als Platzhalter vorhandene Messung im Entfernungsbereich: Die Innovation ist die vorhergesagte Entfernung von der INS-Position zu jedem Satelliten im Vergleich zur gemessenen Pseudorange, mit einer Line-of-Sight-Jacobi-Matrix auf den Positionsfehler. Da jeder Satellit eine skalare Messung ist, korrigiert das Filter weiter, auch mit weniger als vier Satelliten — wo ein lose gekoppelter PVT-Fix nicht existiert. Fünf Tests decken das Nullen mit vier Satelliten, die Korrektur mit zwei Satelliten (kein PVT möglich), die Beobachtbarkeit entlang der Sichtlinie mit einem einzelnen Satelliten und die Eingabevalidierung ab. Nur Pseudorange; Trägerphase und ein expliziter Empfängeruhr-Zustand bleiben Roadmap. Das ungenutzte Cargo-Feature tight_coupling (das den alten Fehler-Platzhalter absicherte) wurde entfernt.
• Lose gekoppeltes GNSS/INS-Szenariopaket (kind = "gnss-ins", src/fusion/pack.rs). Verbindet den dreiachsigen Strapdown-Navigator und den Fehlerzustands-EKF mit 15 Zuständen (closed_loop / gnss_ins_ekf) zu einem lauffähigen Szenario mit einer Gütekennzahl — der EKF diszipliniert die Mechanisierung mit verrauschten GNSS-Fixes, solange Abdeckung besteht, und überbrückt dann den Ausfall, wobei er den Truth-Snap-Reset des früheren skalaren 1-DOF-Pakets durch echte Fusion ersetzt. Das Ergebnis meldet die fusionierte Reihe des horizontalen Fehlers, die bewertete Positionsgütekennzahl (Verfügbarkeit / Ausfall-RMS / holdover) und den RMS der freilaufenden INS im offenen Regelkreis zum Vergleich; ein Quanten-/klassisches IMU-Paar unterscheidet sich nur im wahren Bias. Aufgerufen über den CLI-/Python-/wasm-Einstiegspunkt mit einem Beispiel scenarios/gnss-ins.toml. Ehrliche Einordnung: nur lose gekoppelt, eine deterministische Trajektorie, und der fusionierte Ausfallfehler wird durch den Lagefehler bei der Übergabe nach unten begrenzt (daher wird nicht behauptet, dass er mit dem Bias skaliert) — die belastbaren Befunde sind, dass die Fusion die ungestützte Koppelnavigation bei einem Sensor mit Bias schlägt und dass ein Sensor mit geringerem Bias die bessere ungestützte Überbrückung hat.
• Konstellationsentwurf auf dem validierten SGP4-Kern (src/walker.rs). Ein neues Modul walker erzeugt ein entworfenes Walker-Delta-Muster (i: T/P/F) als SGP4-Mittelelemente, sodass die synthetische Konstellation über denselben SGP4-Pfad propagiert wird, der gegen die Vektoren von AIAA 2006-6753 auf 4,12 mm validiert wurde — nicht über den analytischen Kepler-Generator. Darauf aufbauend: pdop_sweep tabelliert Abdeckung und mittleren/schlechtesten PDOP über einem Entwurfsraster {planes × sats × inclination}, und coverage_revisit meldet den Abdeckungsanteil und die Revisit-Lücken (schlechteste/mittlere) an einem Bodenpunkt. Validiert anhand der physikalischen Monotonien, die ein Trade einhalten muss (mehr Satelliten ⇒ höhere Abdeckung, niedrigerer PDOP, kürzerer Revisit). Außerdem wird ein echter Celestrak-gps-ops-TLE-Snapshot (2021-07-28, 30 betriebsbereite GPS-Satelliten) als reine Test-Fixture hinzugefügt und der Pfad der realen Geometrie TLE → SGP4 → ECEF dagegen validiert (komplette MEO-Schale innerhalb von 1%, neun Satelliten gleichzeitig sichtbar bei PDOP 1,64), neben den bestehenden Realdaten-Pfaden für SP3 und RINEX.
• Rauschtyp-spezifische effektive Freiheitsgrade für die Allan-Konfidenzintervalle. allan::edf_overlapping_adev implementiert die geschlossenen Formeln aus NIST SP 1065 Tabelle 5 (der einfache Satz von Stable32) für alle fünf kanonischen Potenzgesetz-Rauschtypen — weißes/Flicker-PM, weißes/Flicker-FM, Random-Walk-FM — und ersetzt damit die konservative Zählung ohne Überlappung als χ²-Freiheitsgrade. Ein neues Enum PowerLawNoise und classify_power_law bestimmen den dominanten Typ aus der Steigung der modifizierten Allan-Abweichung des Datensatzes (MDEV trennt weißes von Flicker-PM, wo ADEV es nicht kann), und overlapping_adev_curve hängt nun an jeden Punkt der exportierten ADEV-Kurve den bestimmten Rauschtyp, seinen edf und ein 95%-Konfidenzband an (AdevPoint erhält noise/edf/ci_lo/ci_hi, additiv mit serde-Defaults). Auf zwei Wegen validiert: Die fünf Formeln stimmen mit von Hand ausgewerteten Werten auf 1e-12 überein, und ein Monte-Carlo-Ensemble mit 4 000 Datensätzen mit weißem FM bestätigt, dass die Formel den tatsächlichen Chi-Quadrat-edf des Schätzers auf 20% genau vorhersagt (und dass sie die konservative Zählung deutlich übertrifft). Acht neue Tests.
• Stochastisches Modell für den Zwei-Wege-Zeitvergleich. timetransfer::TwoWayLink ersetzt den reinen White-Noise-Sampler durch ein physikalisch fundiertes Modell: Die reziproke (Gleichtakt-)Pfadverzögerung hebt sich in der Schätzung (m_AB - m_BA)/2 auf (two_way_offset_estimate, sodass zwei unabhängige Einweg-Messungen zu 1/sqrt(2) mitteln), und das Residuum ist die nicht reziproke differenzielle Verzögerung — modelliert als farbiger Prozess aus weißem FM + Random-Walk-FM (das validierte ClockModel), was der Reihe des Synchronisationsfehlers eine realistische Allan-Signatur (sigma_y^2(tau) = q_rw*tau/3) statt flachen weißen Rauschens gibt. LinkCfg erhält q_wf_s/q_rw_s (serde-Default 0 ⇒ das frühere Verhalten mit reinem White-Noise, bitgenau), die Link-Gütekennzahl meldet adev_tau0 (die Allan-Abweichung des Modells beim Basisschritt), und das Szenario bzw. die CLI timetransfer machen sie zugänglich. Golden-Gütekennzahl neu festgesetzt. Sechs von Hand hergeleitete Tests (Gleichtakt-Auslöschung, der sqrt(2)-Zwei-Wege-Gewinn, das RWFM-Gesetz tau/3 über das step() des Links selbst, Äquivalenz zum früheren Verhalten bei q=0, Determinismus und durchgängige Ausweisung der Gütekennzahl).
• Numerische Übereinstimmung mit Stable32 für die Schätzer der Allan-Familie (NBS14). tests/allan_reference.rs validiert die Schätzer für überlappende ADEV, modifizierte ADEV, Zeitabweichung und überlappende Hadamard-Abweichung gegen die Stable32-Referenzabweichungen für den kanonischen Datensatz NBS14 (W. J. Riley, Handbook of Frequency Stability Analysis, NIST SP 1065, ca. S. 107) bei tau = 1, 2 mit einer relativen Toleranz von 1e-4 — tatsächliche Übereinstimmung ca. 1e-6. Das verankert die Schätzer-Mathematik an der De-facto-Referenzimplementierung und nicht nur an der eigenen analytischen Selbstkonsistenz der Schätzer. Es werden nur die öffentlichen Referenzzahlen verwendet; kein Code Dritter.
• Vom Szenario integrity exportiertes vertikales Stanford-Integritätsdiagramm. Die lauffähige Szenarioart integrity exportiert nun neben der HPL/VPL-Verfügbarkeitskarte ein vertikales Stanford(-ESA)-Diagramm: In jeder geschützten Epoche wird eine mit Seed reproduzierbare Ziehung eines fehlerfreien Entfernungsfehlers über die Geometrie auf einen tatsächlichen vertikalen Positionsfehler abgebildet und gegen die VPL und die vertikale Alarmgrenze klassifiziert (Available / System-Unavailable / Misleading / Hazardously-Misleading). Das Diagramm (Punkte je Epoche + Regionszähler) steht im Ergebnis-JSON, die Zähler für Integritätsereignisse / HMI in der CLI-Zusammenfassung, sodass der Stanford-Klassifikator — bisher nur als Bibliothek vorhanden — durchgängig erreichbar ist. IntegrityScenario erhält ein Feld seed (Default 0), das die Fehlerrealisierung steuert; die Verfügbarkeitskarte selbst bleibt rein geometrisch und unabhängig vom Seed.
• ARAIM-Integritätsrisiko-Budget (P_HMI) für die Schutzniveaus. raim::araim_raim leitet die horizontalen und vertikalen Schutzniveaus aus einem expliziten Integritätsrisiko-Budget statt aus einem festen Multiplikator K_md ab: Für die All-in-View-Lösung und jede Teillösung mit Ausschluss eines einzelnen Satelliten bildet es das (prior, detection threshold, σ) je Modus auf jeder Achse, dann löst araim_protection_level das kleinste PL, dessen summierte Wahrscheinlichkeit gefährlich irreführender Information (araim_integrity_risk, P_HMI = Σ_k p_fault,k · Q((PL − T_k)/σ_k), Blanch et al. Baseline ARAIM) das zugewiesene P_HMI einhält. Das Ergebnis meldet das Integritätsrisiko, das die Niveaus tatsächlich erreichen, sodass man Integrität und Alarmgrenze explizit gegeneinander abwägen kann. Sechs von Hand hergeleitete Tests (geschlossene Formeln für fehlerfreien und schwellenbehafteten Einzelmodus, Mehrmodus-Summation/Monotonie, durchgängiger fehlerfreier Schutz, bei dem ein um 10⁵× engeres Budget das PL anhebt, Fehlererkennung/-identifikation und die Redundanzuntergrenze bei sechs Satelliten). Single-Fault-MHSS ist die ARAIM-Basislinie; gleichzeitige Fehler in mehreren SV-Teilmengen, der konstellationsweite Fehlermodus und die Validierung mit dem gLAB-Referenzdatensatz sind dokumentierte Erweiterungen.
• Zwei-Raten-Coning-/Sculling-Kompensation für die Strapdown-Mechanisierung. inertial::mechanization::coning_sculling_compensate faltet die hochratigen Coning-Terme (Lage) und Rotations-+Sculling-Terme (Geschwindigkeit) aus den geordneten IMU-Inkrementen der Teilintervalle eines groben Updates heraus, sodass ein NavState::step_increments mit moderater Rate die durch Vibration gleichgerichtete Bewegung reproduziert, die ein grober Schritt über den rohen Summen verfehlt. Ein Validierungstest treibt eine Coning+Sculling-Umgebung mit 10 Hz über 60 s und vergleicht die Wahrheit bei feiner Rate, die naive grobe Integration und die gefaltete grobe Integration: Die Faltung senkt den Positionsfehler um ca. 18× (von Metern naiver Drift auf unter einen Dezimeter) und bestätigt damit, dass die Coning-/Sculling-Terme tragend sind. Ein Typalias ScalarErrorBudget benennt das frühere 1-DOF-AccelModel als das, was es ist, abgegrenzt vom dreiachsigen Navigator NavState.
• Parser für RINEX-Beobachtungsdateien. Das neue Modul rinex_obs liest die RINEX-3.0x- / 4,00-Beobachtungsdatei — die tatsächlichen Messungen des Empfängers — und vervollständigt damit das RINEX-Paar neben dem bestehenden Parser für Navigationsnachrichten. parse_obs dekodiert den Header (Version/Typ, die Listen SYS / # / OBS TYPES je System mit Fortsetzungszeilen, genäherte Position, Intervall, Zeit der ersten Beobachtung) und die Datensätze je Satellit in jeder Epoche: Pseudorange, Trägerphase, Doppler und Signalstärke, adressiert über ihren RINEX-3-Beobachtungscode (C1C, L1C, …) mit den Flags für Lock-Verlust (LLI) und Signalstärke (SSI), wobei ein leeres Feld als nicht vorhanden statt als null erhalten bleibt. Ehrlicher Umfang: Dies ist der Einlese-Pfad für das Standardformat (ein echtes Beobachtungslog von RTKLIB/gLAB/IGS-Station hinein, typisierte Messungen heraus), keine Positionierungs-Engine — hier gibt es keine Pseudorange-Lösung, kein PPP und kein RTK.
• CCSDS-OEM-Writer (Orbit Ephemeris Message). Das neue Modul oem exportiert eine propagierte Konstellation als gültige CCSDS-502.0-B-OEM-2,0-Nachricht — das KVN-Ephemeridenformat, das GMAT, Orekit, STK und die meisten Flugdynamik-Werkzeuge einlesen. OemFile::from_propagators tastet den inertialen (TEME-)Zustand jedes Satelliten — Position und Geschwindigkeit, direkt aus dem Propagator ohne erdfeste Rotation, anders als beim SP3-Export — auf einem Zeitraster ab, und OemFile::to_oem_string serialisiert den Header CCSDS_OEM_VERS/CREATION_DATE/ ORIGINATOR plus ein Segment META_START … META_STOP je Satellit (OBJECT_NAME/OBJECT_ID/CENTER_NAME/REF_FRAME = TEME/TIME_SYSTEM = GPS/ START_TIME/STOP_TIME), gefolgt von dessen Zeilen epoch X Y Z X_DOT Y_DOT Z_DOT (km, km/s). Das CREATION_DATE wird vom Aufrufer geliefert, nie aus der Systemuhr genommen, sodass die Ausgabe über Läufe hinweg byteidentisch ist (der Reproduzierbarkeitsvertrag). Dies ist das Gegenstück für Raumfahrzeug-Ephemeriden zum GNSS-SP3-Export: Eine Kshana-Bahn kann nun in einem Standardformat an ein Flugdynamik-Werkzeug übergeben werden.
• Präzise SP3-Ephemeride als Propagationsquelle. Sp3File::interpolator baut je Satellit einen Sp3Interpolator, der die Position zwischen den tabellierten SP3-Epochen mit einem Lagrange-Polynom 9. Ordnung füllt (übliche IGS-Praxis) und sie in das gemeinsame TEME-System dreht; verfügbar als Propagator::Sp3Precise. Eine Präzisionsbahndatei eines IGS-/Analysezentrums kann nun dieselbe Pipeline für Geometrie, Sichtbarkeit und Integrität antreiben wie die Broadcast- und die analytischen Propagatoren. Validiert per Round-Trip: Eine in SP3 geschriebene und über den Interpolator wieder eingelesene Kepler-Bahn stimmt an den Stützstellen auf unter einen Meter und im Intervallinneren auf < 100 m mit dem Original überein. Die Uhreninterpolation folgt als Nächstes.
• GLONASS-Broadcast-Ephemeride (vervollständigt die Multi-GNSS-RINEX-Navigation). Neues Modul glonass: GLONASS sendet keine Kepler-Elemente, sondern einen erdfesten Zustandsvektor im PZ-90 (Position, Geschwindigkeit, lunisolare Beschleunigung). parse_glonass_nav liest die RINEX-3-Datensätze R, und die Satellitenposition zu einem beliebigen Zeitpunkt ergibt sich durch Runge-Kutta-Integration 4. Ordnung der Bewegungsgleichungen aus dem GLONASS-ICD (zentrale Gravitation + J2 + Coriolis-/Zentrifugalterme der Erdrotation + die gesendete Beschleunigung). Verfügbar als Propagator::Glonass, sodass GLONASS-Satelliten neben den Kepler-Systemen durch die Pipeline für Konstellation/Sichtbarkeit/Integrität laufen; ein einzelner Konstellationsblock rinex kann nun GPS, Galileo, QZSS, BeiDou und GLONASS mischen.
• Multi-GNSS-RINEX-Navigation (GPS, Galileo, QZSS, BeiDou). Der RINEX-3-Navigationsparser dekodiert nun Datensätze von Galileo (E), QZSS (J) und BeiDou (C, MEO/IGSO) neben GPS (G) — sie teilen dasselbe Kepler-Layout und denselben Nutzeralgorithmus —, jeweils ausgewertet mit eigener Gravitationskonstante und eigener Erdrotationsrate (Galileo/BeiDou μ, BeiDou Ω̇ₑ). Eine Datei mit gemischten Konstellationen liefert alle davon, die als Propagator::Rinex durch die Pipeline für Konstellation/Sichtbarkeit/Integrität laufen. Geostationäre BeiDou-Satelliten verwenden eine andere Koordinatenrotation und werden übersprungen, bis eine Referenz-Fixture zur Validierung vorliegt. Der Datensatz-Walker verwendet systemspezifische Zeilenzahlen und behebt damit einen latenten Fehler, bei dem vierzeilige GLONASS-/SBAS-Datensätze übersprungen wurden, als wären sie acht Zeilen lang. GLONASS (ein Zustandsvektormodell) folgt als Nächstes.
• Leser und Schreiber für präzise SP3-c/d-Ephemeriden. Das neue Modul sp3 parst SP3-Präzisionsbahndateien von IGS-/Analysezentren (parse_sp3) — das nachbearbeitete ECEF-Positions-/Uhrenprodukt, das PPP-Engines (Ginan, RTKLIB, gLAB) als Referenz behandeln — in eine strukturierte Sp3File (Header, Epochenraster, Position je Satellit km→m, Uhr µs und Geschwindigkeit dm/s→m/s für V-Produkte) und bewahrt dabei die SP3-Platzhalter für ungültige Werte. Auch die Gegenrichtung ist abgedeckt: Sp3File::from_propagators baut aus einer propagierten Konstellation ein SP3 (TEME→ECEF je Epoche), und to_sp3_string serialisiert es, sodass Kshana-Bahnen in dem Format exportiert werden können, das externe PPP-Werkzeuge einlesen — der Round-Trip Lesen↔Schreiben. Epocheninterpolation und eine SP3-Propagatorquelle folgen als Nächstes.
• RINEX-Broadcast-Ephemeride als lauffähige Konstellationsquelle. Eine Konstellation akzeptiert nun einen Inline-Block rinex (RINEX-3-GPS-Navigationstext) neben der bestehenden Option tle, sodass eine echte Broadcast-Datei ein Szenario durchgängig über die CLI, Python oder den Playground im Browser antreibt — RINEX hinein, PNT-Geometrie heraus. Das neue scenarios/orbit-rinex.toml demonstriert GNSS-Verfügbarkeit und DOP für acht GPS-Satelliten, die direkt aus Broadcast-Datensätzen aufgebaut werden. (Nur GPS LNAV; Multi-GNSS und SP3 folgen als Nächstes.)
• RINEX-Broadcast-Ephemeride als Propagationsquelle. Eine geparste RinexEphemeris lässt sich nun in einen orbit::Propagator (Propagator::Rinex) umwandeln: Die Position ist die Broadcast-Bahn nach IS-GPS-200, von ECEF in das gemeinsame inertiale TEME-System gedreht (sv_position_teme, mit schaltsekundenkorrekter Zeit GPS→UT1), die Geschwindigkeit per zentraler finiter Differenz und die Kepler-Umlaufzeit. Echte GPS-Broadcast-Daten können nun dieselbe Pipeline für Geometrie, Sichtbarkeit und Integrität (RAIM) antreiben wie die analytischen SGP4-/Kepler-Propagatoren. (Noch nicht als Szenarioart für RINEX-Dateien verfügbar — das und Multi-GNSS/SP3 folgen als Nächstes.)

0.9.2 - 2026-06-03#

Hinzugefügt#

• Archiv-DOI. Releases werden nun bei Zenodo hinterlegt und erhalten eine zitierfähige DOI.

0.9.1 - 2026-06-03#

Geändert#

• Dokumentation. Das README wurde auf institutionelles Niveau überarbeitet: ein Überblick über die Fähigkeiten des gesamten Stacks v0.9.0, ein Abschnitt zu Versionierung & Releases, ein aufgeräumter Header mit dem neuen Zeichen und eine knappe Statuszeile. Keine Änderungen an der Engine.

0.9.0 - 2026-06-03#

Dieses Release fügt auf dem SGP4-Unterbau von 0.8.0 drei umfangreiche Fähigkeitsbereiche hinzu: ein echtes dreiachsiges Strapdown-INS, einen lose gekoppelten GNSS/INS-Fehlerzustands-EKF mit Closed-Loop-Rückführung, echtes Snapshot- und Solution-Separation-RAIM (im Stil von ARAIM) mit HPL/VPL und einem lauffähigen Szenario integrity, sowie den ersten Schritt zur Interoperabilität mit GNSS-Formaten (Einlesen der RINEX-3-GPS-Ephemeride).

Hinzugefügt#

• Parser für die RINEX-3-GPS-Navigationsnachricht (src/rinex.rs). Erster Schritt zur Interoperabilität mit GNSS-Formaten: parse_nav liest eine RINEX-3.x-Navigationsdatei und dekodiert jeden GPS-Broadcast-Ephemeridendatensatz (G) — den achtzeiligen Block SV/Epoche + BROADCAST ORBIT — in eine RinexEphemeris aus Kepler-Elementen und Uhrenkorrekturen, mit Feldnamen und Einheiten nach IS-GPS-200. Behandelt das Fortran-Gleitkommaformat mit D-Exponent (parse_d) und das Spaltenlayout fester Breite; Datensätze für Nicht-GPS-Systeme werden übersprungen, nicht abgelehnt, sodass eine gemischte Datei weiterhin ihre GPS-Ephemeriden liefert. Vier Tests: Parsen des D-Exponenten (einschließlich Leerfeldern und Fehlern), ein vollständiger Datensatz, dekodiert gegen bekannte Feldwerte mit einer Plausibilitätsprüfung der GPS-Halbachse (√A² ≈ 26.560 km), das Überspringen von Nicht-GPS-Systemen und der Fall der leeren Datei.
• GPS-Broadcast-Ephemeride → ECEF-Position (src/rinex.rs). RinexEphemeris::sv_position_ecef(t_tow) wertet die erdfeste Position des Satelliten aus der geparsten Ephemeride über den Nutzeralgorithmus nach IS-GPS-200 §20.3.3.4.3.1 aus: Newton-Lösung der Kepler-Gleichung für die exzentrische Anomalie, die Korrekturen zweiter Harmonischer für Argument der Breite / Radius / Inklination und die Drehung nach ECEF unter Berücksichtigung der Erdrotation seit der Referenzepoche (mit dem von der Spezifikation vorgeschriebenen GPS-μ und -Ω̇ₑ sowie einer Faltung tk beim Wochenüberlauf). Drei Tests: Der geozentrische Radius bleibt im GPS-Bereich (≈ 26.560 km), die erdfeste Geschwindigkeit beträgt ca. 3,9 km/s, und die Auswertung genau eine Woche entfernt reproduziert dieselbe Position.
• GPS-SV-Uhrenversatz mit der relativistischen Korrektur (src/rinex.rs). RinexEphemeris::sv_clock_bias_s(t_tow) wertet das Broadcast-Uhrenpolynom af0 + af1·Δt + af2·Δt² um Toc aus, plus den relativistischen Exzentrizitätsterm F·e·√A·sin Ek (IS-GPS-200 §20.3.3.3.3.1). Ein neues EpochUtc::gps_time_of_week wandelt die Kalenderepoche des Datensatzes per Julianischer-Tage-Arithmetik ab der GPS-Epoche (1980-01-06) in die GPS-Wochensekunde um, und die Kepler-Lösung wird mit der Positionsauswertung geteilt. Tests: GPS-Wochensekunde für einen Sonntag/Dienstag/Samstag (Wochengrenzen), und der Uhrenversatz, der von af0 dominiert wird und einen vorhandenen, begrenzten relativistischen Term enthält. Die L1-Gruppenlaufzeit TGD wird bereitgestellt, aber bewusst nicht einbezogen. Ehrlicher Umfang: Eine Propagator-Quelle, Galileo/BeiDou/GLONASS und SP3 bleiben nächste Schritte. (docs/CAPABILITY.md wurde entsprechend angepasst.)
• Vom Nutzer ausführbare Szenarioart integrity (scenarios/integrity-raim.toml). Die RAIM-Verfügbarkeitsfähigkeit ist nun wie jedes andere Paket über CLI/TOML erreichbar: kind = "integrity" parst ein IntegrityScenario (Nutzerbahn, eine oder mehrere GNSS-Konstellationen, Elevationsmaske und die Integritätskonfiguration (sigma, P_fa, P_md, AL_H, AL_V)), führt constellation_raim_availability aus und gibt die HPL/VPL-Verfügbarkeitskarte je Epoche als JSON aus, plus ein eigenständiges SVG — Schutzniveaus über die Zeit gegen die Alarmgrenzen, mit einem grün/roten Verfügbarkeitsstreifen. kshana scenarios/integrity-raim.toml schreibt das JSON, die Grafik und einen HTML-Bericht. Das mitgelieferte Szenario (24-Satelliten-Walker, Zweifrequenz-Entfernungsmessung mit 1 m, APV-I-Grenzen) meldet ca. 95 % Verfügbarkeit; es dokumentiert, dass Einfrequenz-RAIM die vertikale APV-I-Grenze mit einer Konstellation nicht erfüllt, weshalb die vertikale Führung SBAS/Zweifrequenz/ARAIM nutzt. Die Tests decken den Aufruf, das JSON der Verfügbarkeitskarte und das SVG ab.
• Lauffähige RAIM-Verfügbarkeit über eine Konstellation (src/raim.rs). Das Integritätsmodul hatte keinen Aufrufer — constellation_raim_availability macht es zu einem echten durchgängigen Einstiegspunkt: In jeder Epoche eines Zeitrasters propagiert es die sichtbaren Satelliten (dieselben SGP4-/Kepler-Propagator wie in der Engine), berechnet die fehlerfreien Schutzniveaus und beurteilt die Verfügbarkeit gegen die horizontalen/vertikalen Alarmgrenzen und liefert einen mit serde serialisierbaren RaimAvailabilityReport zurück (je Epoche n_visible/HPL/VPL/available plus den Verfügbarkeitsanteil). Ein RaimConfig bündelt (sigma, P_fa, P_md, AL_H, AL_V), und das raim_availability_epoch je Epoche wird für Aufrufer bereitgestellt, die ihre eigene Geometrie auflösen. Drei Tests: eine Epoche, die unter APV-I-Grenzen bei einer Geometrie mit zehn Satelliten als verfügbar beurteilt wird, durch eine unmöglich enge Grenze nicht verfügbar wird, und None-Niveaus unter fünf Satelliten; sowie ein durchgängiger Lauf über eine 24-Satelliten-Walker-Konstellation, der eine endliche Verfügbarkeitskarte ergibt und sich serialisieren lässt. (Sechs Satelliten — die Redundanzuntergrenze des Residuen-RAIM — erfüllen APV-I ehrlicherweise selbst bei 1 m Entfernungsmessung nicht; für die APV-I-Verfügbarkeit braucht es die dichtere Geometrie, die der Test verwendet.)
• Akkumulator für das Stanford(-ESA)-Integritätsdiagramm (src/raim.rs). Die Standardmethode, einen Integritätsmonitor über viele Epochen zusammenzufassen: Er trägt den tatsächlichen Positionsfehler (x) gegen das Schutzniveau (y) auf und klassifiziert jede Epoche anhand der Diagonale y = x und der Alarmgrenze als Available (PL begrenzt den Fehler, innerhalb AL), SystemUnavailable (PL begrenzt den Fehler, überschreitet aber AL — sicher, nicht nutzbar), MisleadingInformation (PL < Fehler ≤ AL) oder HazardouslyMisleadingInformation (PL < Fehler und Fehler > AL — das unsichere Versagen). classify_stanford ist der reine Klassifikator; StanfordDiagram akkumuliert Punkte (error, PL) gegen eine feste Alarmgrenze und legt Regionszähler, Verfügbarkeit, Summen der Integritätsereignisse sowie mit serde serialisierbare Punkte für Plot/JSON-Export offen. Vier Tests: jede Region (einschließlich der Grenze error == PL als begrenzt), Akkumulation von Zählern/Verfügbarkeit und JSON-Round-Trip. Dies ist die Berichtsoberfläche für die RAIM-Schutzniveaus; die Einbindung in das Konstellationsszenario und die Validierung gegen einen öffentlichen Datensatz bleiben Roadmap-Punkte.
• RAIM mit Solution Separation (im Stil von ARAIM) (src/raim.rs). Ein Integritätsmonitor mit Mehrfachhypothesen neben dem bestehenden Residuen-/Paritäts-Chi-Quadrat-snapshot_raim. Für die All-in-View-Kleinste-Quadrate-Lösung und jede Teillösung mit Ausschluss eines einzelnen Satelliten bildet er die Separation Δ_k = x_k − x₀ — mittelwertfrei gaußverteilt ohne Fehler, mit der Kovarianz Cov(x_k) − Cov(x₀) (die Identität genesteter Schätzer, gültig, weil die All-in-View-Lösung BLUE ist) — und so erkennt er sowohl einen Fehler als auch identifiziert den fehlerhaften Satelliten (jenen, dessen Ausschluss die größte normierte Separation ergibt). Die horizontalen/vertikalen Schutzniveaus folgen der Standard-MHSS-Zuteilung PL = max(K_md·σ₀, max_k[K_fa·σ_ss,k + K_md·σ_k]), mit K_fa = Φ⁻¹(1−P_fa/2), K_md = Φ⁻¹(1−P_md). Neue abhängigkeitsfreie normal_cdf/normal_quantile, aufgebaut auf der bereits im Modul vorhandenen regularisierten unvollständigen Gammafunktion (erf(x) = P(½,x²)). Vier von Hand hergeleitete Tests: Normalverteilungs-CDF / Quantil gegen Lehrbuchwerte (Φ(1,95996)=0,975, der 1e-7-Rand = 5,1993, Symmetrie); eine fehlerfreie Geometrie, die keinen Alarm auslöst und endliche, positive HPL/VPL ergibt; ein Bias von 60 σ auf einem einzelnen Satelliten, der erkannt und korrekt identifiziert wird (excluded_sv == 2); und die Redundanzuntergrenze bei sechs Satelliten. Schließt auf Algorithmusseite die P0-Lücke des Audits „tautologische Integrität — kein echtes RAIM/HPL/VPL"; die Validierung mit dem gLAB-Datensatz und der Stanford-Diagramm-Akkumulator bleiben Roadmap-Punkte.
• Closed-Loop-GNSS/INS-Integration (src/fusion/closed_loop.rs). ClosedLoopInsGnss verbindet den Fehlerzustands-EKF-Kern mit der dreiachsigen Strapdown-Mechanisierung: Jede IMU-Probe wird mit den laufenden Bias-Schätzungen korrigiert, vorwärts mechanisiert, und die EKF-Kovarianz wird mit dem passenden Navigationskontext zeitlich propagiert; jeder GNSS-Positions-/Geschwindigkeits-Fix bildet die INS−GNSS-Innovation und führt die geschätzten Position, Geschwindigkeit, Lagefehler (ψ, als Quaternionen-Rotation) und Beschleunigungs-/Gyro-Biases in die Lösung zurück und setzt den Mittelwert des Fehlerzustands zurück. Die Rückführung der Lage (nicht nur der Biases) ist für die Stabilität erforderlich — die Neigung und der Beschleunigungs-Bias sind ein gekoppeltes Paar, sodass die Korrektur des einen ohne den anderen divergiert. INS und GNSS werden in einem lokalen NED-Tangentialebenen-System verglichen, unter Verwendung der eigenen Krümmungsradien der Mechanisierung (neu mechanization::radii_of_curvature; NavState::omega_ie_n/omega_en_n offengelegt). Dies ist der ehrliche Ersatz für den Truth-Snap-Reset des Hybridpakets. Drei Tests: ein Closed Loop, der einen eingespeisten Positionsfehler von 8 m / −5 m auf <0,1 m nullt; eine gestützte Lösung, die auf einer Fahrtrajektorie meterbegrenzt bleibt (<6 m), während eine freilaufende INS über 100 m hinaus divergiert; und der Meilenstein-Benchmark — der Monte-Carlo-Positions-RMS der fusionierten Lösung über einen GNSS-Ausfall von 60 s schlägt einen ungestützten Koppelnavigator im offenen Regelkreis um >2× (≈4× über alle Seeds). Im Modul dokumentierte ehrliche Einschränkung: Im lose gekoppelten Modus sind Beschleunigungs-Bias und Neigung nur schwach trennbar (beide koppeln über die Schwerkraft), sodass der gelieferte Wert der begrenzte, korrigierte Zustand und ein sauberer Eintritt in den Ausfall ist — keine präzise inertiale Kalibrierung; reichhaltigere Dynamik und die eng gekoppelte Erweiterung bleiben Roadmap-Punkte.
• Kern des lose gekoppelten GNSS/INS-Fehlerzustands-EKF (src/fusion/gnss_ins_ekf.rs). Ein erweitertes Kalman-Filter mit 15 Fehlerzuständen — δx = [δp, δv, ψ, b_a, b_g] — mit der Strapdown-Fehlerdynamik nach Groves 2013 §14,2 (Kopplung von spezifischer Kraft und Neigung, Coriolis, Projektion des Bias vom Körper- ins Navigationssystem, Gauß-Markov-Bias-Modelle), einem diskreten Übergang erster Ordnung Φ = I + F·dt und einem lose gekoppelten Messupdate für Position+Geschwindigkeit (H = [I₃ 0 0 0 0; 0 I₃ 0 0 0]) in Joseph-Form. Abhängigkeitsfreie dichte lineare Algebra (Gauß-Jordan-Inverse, Joseph-Kovarianzupdate). Ein Cargo-Feature tight_coupling sichert ein dokumentiertes, noch nicht implementiertes Pseudorange-/Doppler-Update ab. 7 Tests mit von Hand hergeleiteten Erwartungen: die Skew-/Kreuzprodukt-Identität, eine verifizierte 3×3-Inverse, eine Kovarianz, die unter Prädiktion symmetrisch/PSD bleibt (und eine ungestützt wachsende Positionsunsicherheit), ein Positions-Fix, der die Positionskovarianz verkleinert, die exakte Wiedergewinnung eines bekannten Positionsfehlers beim analytischen Kalman-Gain P/(P+R) und kleinere Korrekturen bei größerem Messrauschen. Dies ist der Kern, der den Open-Loop-Truth-Snap-Reset des Hybridpakets durch Closed-Loop-Rückführung ersetzen wird (Paketanbindung + NaveGo-Validierung folgen).
• Deterministisches IMU-Fehlermodell für den 3-Achsen-Strapdown-Navigator (src/inertial/imu_errors.rs). ImuErrorModel verzerrt ein wahres Paar (ω, f) im körperfesten System in ein gemessenes, über fünf systematische Kategorien (IEEE Std 952-1997 §A.2; Groves 2013 §4,3, Tabelle 4,1): Skalenfaktor (Verstärkungsfehler je Achse in ppm), Fehlausrichtung / Kreuzkopplung (Nichtorthogonalität des Triaden außerhalb der Diagonale), g-Empfindlichkeit (ein Bias der Drehrate des Gyros proportional zur spezifischen Kraft), Quantisierung (Runden auf das LSB der Ausgabe) und Ratenrampe (eine in der Zeit lineare Drift — die dritte Allan-Region), dazu ein konstanter Einschaltbias. Jeder Term ist standardmäßig null, sodass ImuErrorModel::ideal() ein transparenter Durchgriff ist und bestehende Szenarien unberührt bleiben. Jede Fehlerquelle hat einen Isolationstest (Skala linear auf <0,01 %, Kreuzachsen-Fehlausrichtung über dem Boden des VRW, Bias durch g-Empfindlichkeit, LSB-Raster, lineare Rampe), und ein durchgängiger Test treibt einen Navigationsfehler aus einer verzerrten IMU durch die Mechanisierung. Nicht modelliert: Fehler durch Vibrationsgleichrichtung, Temperaturgradienten-Drift. (Das ausgelieferte Szenariopaket inertial rechnet weiterhin mit dem älteren skalaren Budget mit 1 Freiheitsgrad; dieses Modell speist die 3-Achsen-Bibliothek.)
• Coning- und Sculling-Kompensation für den Strapdown-Integrator. Der Lagepfad erhält das Zwei-Proben-coning_increment (½ Δθ_prev × Δθ_cur); eine Integration mit grober Rate (30 Hz, 5 Proben/Zyklus) einer Coning-Umgebung mit 5 Hz folgt nachweislich der Wahrheit bei feiner Rate mit der Korrektur um ≥ 3× besser als naives Aufsummieren der Inkremente. Der Geschwindigkeitspfad erhält sculling_increment (½ Δθ × Δv, Groves Gl. 5,82) und löst das Geschwindigkeitsinkrement im Körpersystem über ein neues inkrementbasiertes Update NavState::step_increments mit der körperrelativen Rotation Δθ_rel = Δθ_b − C_n^b ζ auf, sodass eine erdfeste Plattform kein falsches Sculling erfährt, während eine echte Vibration den vollen Term auslöst.
• Vollständige dreiachsige Strapdown-Mechanisierung im NED-System (src/inertial/mechanization.rs). NavState { q, v_ned, p_llh } wird mit step(gyro_b, accel_f_b, dt) nach den üblichen NED-Gleichungen im erdfesten System fortgeschrieben (Groves §5,4): Die Lage Körper→NED wird um die Rate vom inertialen zum Navigationssystem ω_in = ω_ie + ω_en (Erdrotation + Transportrate) korrigiert; die spezifische Kraft wird über die DCM von Körper→NED aufgelöst; die Geschwindigkeit integriert v̇ = f_n − (2 ω_ie + ω_en) × v + g_n (Coriolis/Transport + Schwerkraft); und die geodätische Position ergibt sich über die Meridian-/Quer-Krümmungsradien. Die Schwerkraft ist die geschlossene WGS-84-Somigliana-Normalschwere (Lotschwere) mit einer Freiluft-Höhenkorrektur nach NIMA — nie eine fest eincodierte Konstante. Dies ist der echte dreiachsige Navigator, der den skalaren 1-DOF-Fehlerbudgetpfad ablöst. Verifiziert durch physikalische Invarianten: Eine an die rotierende Erde geschraubte Plattform bei 45°N (die Erdrate + 1 g erfasst) bleibt über 60 s innerhalb von 1 mm; eine horizontale spezifische Kraft nach Norden ergibt v_N ≈ a·t und eine Verschiebung ½ a t²; die Normalschwere entspricht den bekannten Oberflächenwerten am Äquator, am Pol und bei 45° sowie dem Freiluft-Gradienten.
• Dreiachsige Darstellung der Lage für Strapdown-INS (src/inertial/attitude.rs). Ein Typ Quaternion für Einheitsquaternionen (Skalar zuerst, Konvention nach Hamilton), der die Rotation Körper→Nav trägt, mit einer DCM-Sicht (to_dcm/from_dcm nach dem Verfahren von Shepperd), dem Hamilton-Produkt, Konstruktoren aus Achse-Winkel und Rotationsvektor (exakte Exponentialabbildung) sowie der Kinematik der Quaternionen — sowohl ein Update der Rate mit RK erster Ordnung (q̇ = ½ q ⊗ ω) als auch ein Update des Rotationsvektors mit Coning-Korrektur. Das Zwei-Abtastwert-coning_increment (Savage / Bryan–Lewantowski, ½ Δθ_prev × Δθ_cur) liefert den Kreuzkopplungsterm der Drehrate, den die skalare Koppelnavigation auslässt. Dies ist die Grundlage der Lage für die vollständige 3-Achsen-Mechanisierung, die den älteren Pfad mit Fehlerbudget für 1 Freiheitsgrad ersetzt. Gegen geschlossene Rotationen verifiziert: Die Propagation mit konstanter Rate entspricht dem Quaternion aus Achse-Winkel auf 1e-6, DCMs sind orthonormal mit Determinante eins, und Coning verschwindet bei Bewegung um eine einzelne Achse. (src/inertial.rs ist nun das Modulverzeichnis src/inertial/; der öffentliche Pfad crate::inertial ist unverändert.)
• Geodätisch korrekte Sichtbarkeit von Bodenstationen (src/frames.rs). elevation, is_visible und visible_count berechnen die Elevation eines Satelliten über dem Horizont einer Bodenstation gegen die Normale des WGS-84-Ellipsoids (die wahre lokale Vertikale), nicht gegen die geozentrische Radialrichtung — beide unterscheiden sich um bis zu die geodätische Lotabweichung von ca. 0,19°, genug, um Satelliten nahe dem Horizont in eine Elevationsmaske hinein- oder aus ihr herauszuschieben. Durchgängig verifiziert (eine Walker-Konstellation propagiert, von TEME nach ECEF gedreht und von einem geodätischen Standort aus gezählt) sowie gegen die geozentrische Näherung.

Geändert#

• CI-Zuverlässigkeit. Der Job test-python-bindings baut das Wheel nun mit PyO3/maturin-action (manylinux-Container) statt mit einem rohen maturin build auf dem Host und beseitigt damit einen sporadischen rustup-Konflikt zwischen rustfmt-preview/cargo-fmt auf dem Runner-Image. Der Job deny installiert cargo-deny als vorgebaute Binärdatei über taiki-e/install-action statt über die Docker-basierte cargo-deny-action und beseitigt damit einen Timeout beim Pull aus der Docker-Hub-Registry. Keine der Änderungen wirkt sich auf die durchgeführten Prüfungen aus.

0.8.0 - 2026-06-02#

Hinzugefügt#

• Die inertiale Geschwindigkeit wird an nachgelagerte Stellen weitergegeben. Propagator::velocity_eci und Propagator::state_eci (liefert StateEci { r_m, v_m_s }) reichen die analytische TEME-Geschwindigkeit, die SGP4 ohnehin berechnet — bisher verworfen — in m/s an die Aufrufer durch; Orbit::velocity_eci gibt dem Kepler-Pfad eine konsistente Geschwindigkeit. Der Verifikationstest nach AIAA 2006-6753 prüft nun für jede Referenzzeile auch die Geschwindigkeit (schlechtester Geschwindigkeitsfehler 1.85e-9 km/s über alle 666 Zustände) und legt die Zahl der verglichenen Zeilen exakt auf 666 fest.

• Strengeres, panikfreies TLE-Parsen. Zeilen müssen ASCII sein und werden sicher zerteilt (keine Panics durch Byte-Indizes mehr bei Mehrbyte-Eingaben); Elemente werden auf Wertebereiche geprüft (Inklination, Exzentrizität, mittlere Bewegung); die Prüfsumme in Spalte 69 kann über ParseOpts { strict_checksum } / parse_propagators_opts und das neue Flag strict_checksum in ConstellationCfg erzwungen werden (standardmäßig nachsichtig).

• Allan-Abweichungskurve in der Ausgabe. Jeder Uhrenlauf meldet nun eine adev_curve ([{tau_s, adev, n_samples}]), und der Browser-Playground stellt ein doppelt logarithmisches Diagramm „Uhrenstabilität (ADEV)“ dar.

• Validierung der Eingabe des Zeitrasters. TimeCfg::validate weist ein nicht endliches, null, negatives oder überdimensioniertes Zeitraster zurück (einen Schritt größer als die Dauer oder mehr als MAX_TIME_STEPS Proben), bevor irgendetwas allokiert wird, sodass ein fehlerhaftes Szenario einen Fehler zurückgibt, statt zu paniken oder den Speicher zu erschöpfen.

• Monte-Carlo-Ensembles für das Inertialpaket. runs = N bei einem Inertialszenario führt N Seeds aus und weist je Kennzahl den Mittelwert, die Standardabweichung, die Perzentile und ein Perzentil-Bootstrap-Konfidenzintervall von 95 % aus (ensemble). Jeder Inertiallauf trägt nun ein Flag monte_carlo, sodass ein Gütemaß aus einer einzelnen Realisierung nicht mehr mit einer Verteilung verwechselt wird. (CEP/2DRMS werden bewusst nicht ausgewiesen — sie erfordern das 3-Achsen-Modell der Roadmap.)

• Geführter Playground-Modus. Der Browser-Playground wirft Sie nicht mehr auf eine rohe TOML-Wand: Ein Streifen „Hier starten“ mit Szenariokarten für einen Klick lädt und führt ein durchgerechnetes Beispiel aus, Schieberegler legen die allgemeinen Stellgrößen (Seed, Zeitgebungsschwelle) offen, ohne das TOML anzufassen, ein Hinweis „So lesen Sie das“ erklärt das Ergebnis, und das vollständige TOML ist nur einen Klick zum Einklappen entfernt. Jeder Lauf ist teilbar — Freigabelink kopieren kodiert das gesamte Szenario in das URL-Fragment (nichts wird hochgeladen), sodass ein Link beim Laden genau denselben Lauf reproduziert. Der Codec ist per Unit-Test geprüft (web/share.test.mjs, läuft in der CI).

• N-dimensionale Parameter-Sweeps (src/sweep.rs). nd_sweep wertet eine Kennzahl über das gesamte kartesische Produkt mehrerer Bereiche SweepAxis aus (die Trade-Studie mit mehreren Parametern), in zeilenweiser Reihenfolge, deterministisch. Additiv — die bestehende 1-D-Sweep-API bleibt unverändert. Bootstrap-Konfidenzintervalle je Knoten und die Verallgemeinerung über das Uhrenpaket hinaus bleiben auf der Roadmap.

• Echtes Snapshot-RAIM (src/raim.rs). Echtes Receiver Autonomous Integrity Monitoring im Positionsbereich: Es baut die Sichtlinien-Geometrie zu den sichtbaren Satelliten auf, bildet die Kleinste-Quadrate-Lösung und die Residuen, führt einen χ²-Residuentest zur Fehlererkennung aus (exakte Schwelle aus einem abhängigkeitsfreien unvollständigen-Gamma-χ²/nichtzentralen-χ²) und berechnet steigungsbasierte horizontale und vertikale Schutzniveaus (HPL/VPL) mit dem für die konfigurierten P_fa/P_md hergeleiteten Bias bei verpasster Erkennung. Dies ist verschieden von der Integritätskennzahl der Filter-Selbstkonsistenz in der Szenario-Pipeline — und noch nicht an sie angebunden; Fehlerausschluss, Budgetierung von Alarmgrenze/P_HMI und ARAIM bleiben auf der Roadmap.

• Suite zur Frequenzstabilität: MDEV, TDEV, HDEV + Konfidenzintervalle (src/allan.rs). Neben der überlappenden ADEV: die modifizierte Allan-Abweichung (trennt weißes von Flicker-Phasenrauschen), die Zeitabweichung (TDEV = tau/sqrt(3) * MDEV) und die Hadamard-Abweichung (unterdrückt linearen Frequenzdrift exakt und konvergiert für divergente Rotrausch-Typen). χ²-basierte Konfidenzintervalle (deviation_ci) verwenden ein abhängigkeitsfreies Paar von Normal-/χ²-Quantilen (Acklam + Wilson-Hilferty) mit einem konservativen edf ohne Überlappung; rauschtyp-spezifische edf und numerische Übereinstimmung mit Stable32 bleiben auf der Roadmap.

• Reduktion zwischen Bezugssystemen (src/frames.rs). GMST-basierte Rotation TEME↔ECEF (mit derselben Sternzeit nach IAU-1982 wie der Propagator), exaktes geodätisch↔ECEF nach WGS-84 mit einer iterativen Umkehrung mit Bowring-Startwert (Maschinengenauigkeit in allen Höhen, einschließlich MEO/GEO) und ein geodätischer Bodenstations-Beobachter, der Azimut / Elevation / Entfernung im lokalen East-North-Up-System liefert. Polbewegung und Nutation unterhalb einer Bogensekunde werden nicht angewandt (nur GMST, unterhalb eines Kilometers auf der Bodenspur); eine ITRF-präzise CIO-Kette steht auf der Roadmap.

• Grundlage für Zeitskalen (src/timescales.rs). Eine abhängigkeitsfreie Julianisches-Datum-API (Gregorianisch zivil ↔ JD, MJD), die vollständige ganzzahlige IERS-Schaltsekunden-Historie (UTC↔TAI, 10 s im Jahr 1972 bis 37 s seit 2017), der definierte Offset TAI→TT, die UT1-Korrektur über ein bereitgestelltes DUT1 und der Erdrotationswinkel nach IAU-2000. Dies ist das Zeitfundament, auf dem die (geplante) Reduktion ins erdfeste System aufsetzt. Zeitpunkte sind Julianische Daten als einzelnes f64 (ca. 50 µs Auflösung nahe der heutigen Epoche; ein zweiteiliges JD steht auf der Roadmap), und die Ära der Gummisekunden vor 1972 wird nicht modelliert — beides ist im Modul dokumentiert.

• Reproduzierbarkeit & Herkunft. Ein deterministischer CycloneDX-SBOM-Generator (scripts/gen-sbom.sh) und eine SLSA-Build-Provenance-Attestierung für die Release-Binärdatei und das SBOM; die Release-Toolchain ist passend zur CI festgelegt. Determinismus-Garantien, der plattformübergreifende Vorbehalt zu libm und der Ansatz des Festsetzens von Golden-Werten sind in docs/REPRODUCIBILITY.md dokumentiert.

• Eigenschaftsbasierte und Fuzz-Tests (tests/property.rs). Deterministische Zufallstests (keine neue Abhängigkeit) prüfen Invarianten über Tausende von Eingaben: Die TLE- und Szenario-Parser paniken nie bei Müll, Nicht-ASCII, mutierter oder abgeschnittener Eingabe; TimeCfg::validate paniert nie bei NaN/inf/negativen Rastern; die TLE-Prüfsumme ist konsistent und nur auf Spalte 69 bezogen; geodätisch↔ECEF-Round-Trips und die Rotation TEME→ECEF erhalten die Norm über den ganzen Globus und ein weites Höhenband.

Geändert#

• Golden-Tests legen die Gütekennzahlen nun feldweise fest für die vier Referenzszenarien (mit einer Toleranz, die plattformübergreifendes libm-Jitter auffängt) und ersetzen die früheren reinen Ungleichungsprüfungen, sodass eine stille numerische Regression sofort auffällt.
• schema_version in den Ergebnisartefakten wurde von 0.1 auf 0.7 angehoben (sie war eingefroren, während die Engine weiterentwickelt wurde).
• cargo-deny lehnt zurückgezogene (yanked) Abhängigkeiten nun ab (statt nur davor zu warnen).
• Neue Dokumente: CAPABILITY.md (ehrliche Umfangskarte), SCHEMA.md (Referenz der Ergebnisfelder), INTEGRITY.md, QUANTUM-MODELS.md, REAL_TLE_GUIDE.md. Ein CI-Wächter schlägt fehl, wenn das Versionsabzeichen im README von Cargo.toml abweicht.

0.7.0 - 2026-06-02#

Hinzugefügt#

• SGP4/SDP4-Bahnpropagation. Eine vollständige, abhängigkeitsfreie Implementierung des Standard-Propagators für vereinfachte Störungen — erdnahes SGP4 zusammen mit der Erweiterung SDP4 für den tiefen Raum (säkulare und periodische Mond-Sonne-Störungen sowie Geopotential-Resonanz bei 12 h / 24 h). Sie ist gegen die offiziellen Verifikationsvektoren von AIAA 2006-6753 („Revisiting Spacetrack Report #3“) validiert: Alle 666 Referenzzustände der erdnahen, Tiefraum-, Resonanz- und Fehlercode-Fälle stimmen mit einem Positionsfehler im ungünstigsten Fall von etwa 4 mm überein. Dies ist das Modell, gegen das Two-Line-Element-Sätze definiert sind, sodass es reale Konstellationen abbildet — insbesondere die GNSS-Bahnen mit ca. 12 h, die im tiefen Raum liegen und resonant sind und die das frühere Zwei-Körper- + J2-säkulare Modell nicht erfassen kann.
• Eine Konstellation, die als vollständige Two-Line-Element-Sätze (Zeile 1 + Zeile 2) angegeben ist, wird nun mit SGP4/SDP4 propagiert; eine Konstellation, die nur mit Elementen der Zeile 2 angegeben ist, behält die analytische Kepler-Zwei-Körper-Propagation unverändert bei. Die beiden Formen lassen sich in einem Block mischen. Neues Referenzszenario orbit-sgp4-gps.toml (eine GPS-ähnliche MEO-Konstellation im echten Two-Line-Format, mit SGP4 propagiert) — mit einem aktuellen Celestrak-Satz „gps-ops“ lässt sich die live betriebene Konstellation untersuchen.

0.6.0 - 2026-06-02#

Hinzugefügt#

• Demonstrator für aktive Spoofing-Angriffe. Eine neue Szenarioart spoof speist ein ansteigendes falsches Zeit-Spoofing ein und führt den uhrengestützten Integritätsmonitor jeder Uhr aus; sie meldet, ob und wann das Spoofing erkannt wird und ob es unentdeckt die betriebliche Spezifikation erreicht — und macht die Sicherheits-Gütekennzahl so zu einer konkreten Angriffs-/Verteidigungsdemonstration. Neues Referenzszenario spoof-attack.toml.
• Verfügbarkeit mit mehreren Konstellationen. Ein Bahnszenario kann mehrere Konstellationen kombinieren (eine Liste [[constellations]] neben der primären [constellation]) für Multi-GNSS-Verfügbarkeit und Dilution of Precision — z. B. GPS plus Galileo. Neues Referenzszenario orbit-multignss.toml.

0.5.0 - 2026-06-02#

Hinzugefügt#

• HTML-Scorecard-Bericht. Jeder Lauf erzeugt nun außerdem eine eigenständige HTML-Scorecard im Brand-Design — die einzeilige Zusammenfassung, das Diagramm (als inertes Data-URI-Bild eingebettet) und das vollständige JSON —, von der CLI neben JSON und SVG geschrieben. Ein teilbares Einzeldatei-Artefakt für ein Studienergebnis oder einen Anhang.
• Gemeinsamer Sensorfusions-Schätzer. Eine neue Szenarioart fusion führt ein einziges rekursives Kalman-Filter als Navigationslösung aus — es fusioniert den Uhrenzustand [phase, frequency] und den Positionszustand [position, velocity], wird durch GNSS diszipliniert (lernt den Frequenzoffset und die Geschwindigkeit) und während des Ausfalls durch optischen Zeitvergleich gestützt —, statt unabhängige Prädiktoren zusammenzusetzen. Es meldet fusioniertes holdover von Zeitgebung/Position und eine Integrität aus der gemeinsamen Kovarianz. Neues Referenzszenario fusion-pnt.toml.
• Vollständigeres IMU-Rauschmodell. Der Beschleunigungsmesser modelliert nun die übrigen Terme der Allan-Varianz über den konstanten Bias und den Geschwindigkeits-Random-Walk hinaus: Bias-Instabilität (eine 1/f-Flicker-Untergrenze beim üblichen Allan-Koeffizienten der Bias-Instabilität, unter Wiederverwendung der Flicker-Synthese der Uhr) und Beschleunigungs-Random-Walk. Neue optionale Szenariofelder bias_instability und q_aa für Inertialszenarien; ein erneuter GNSS-Fix kalibriert die verbleibende Bias-Drift neu.
• Reale Konstellationsgeometrie aus TLEs. Eine Konstellation kann über ein Feld tle als Block von Two-Line-Element-Sätzen (dem NORAD-/Celestrak-Standardformat) angegeben werden, sodass Verfügbarkeit und Dilution of Precision die veröffentlichte Geometrie einer realen Konstellation statt eines synthetischen Walker-Musters verwenden. Die Engine liest die mittleren Kepler-Elemente jedes TLE und propagiert sie als Zwei-Körper-Problem — nicht mit SGP4 —, was für eine Momentaufnahmestudie von einer gemeinsamen Epoche aus tragfähig ist. Neues Referenzszenario orbit-real-tle.toml.

0.4.0 - 2026-06-02#

Hinzugefügt#

• Parameter-Sweeps für Trade-Studien. Eine neue Szenarioart sweep variiert einen Parameter (threshold_ns, duration_s, quantum_q_wf oder classical_q_wf) über einen linearen oder logarithmischen Bereich und zeichnet an jedem Punkt für beide Uhren eine gewählte Gütekennzahl auf; so entsteht das Vergleichsdiagramm „Wie skaliert holdover mit der Uhrenstabilität?“, das ein Entwurfs-Trade braucht. Neues Referenzszenario sweep-clock-stability.toml.
• Monte-Carlo-Konfidenzbänder. Das Uhren-holdover-Szenario kann viele Realisierungen ausführen (neues optionales Feld runs): Jede Gütekennzahl wird dann als Mittelwert mit einer Streuung vom 5. bis 95. Perzentil gemeldet, und das Diagramm schattiert für jede Uhr die Fehlerhüllkurve von 5–95% um den Median. Ein einzelner Lauf bleibt der Standard. Neues Referenzszenario clock-ensemble.toml.
• Exzentrische Bahnen und J2-Drift. Der Bahntyp ist nun eine vollständige Kepler-Bahn (große Halbachse, Exzentrizität, Inklination, RAAN, Argument des Perigäums, mittlere Anomalie), propagiert durch Lösen der Kepler-Gleichung, mit optionaler säkularer J2-Knotenregression und Apsidenpräzession. Neue optionale Szenariofelder eccentricity, argp_deg und j2 sowie ein Referenzszenario orbit-molniya.toml (ein hochexzentrischer Nutzer mit kritischer Inklination und 12 h Umlaufzeit). Kreisbahnen behalten den ursprünglichen geschlossenen Pfad bitgenau bei.
• Das Hybridpaket (kombiniertes PNT) meldet nun Integrität und Sicherheit, sodass alle vier Pakete den vollen Satz betrieblicher Gütekennzahlen abdecken. Die Integrität ist die Einschließung durch die Schutzgrenze im Zeitgebungskanal, aus einem Kalman-Schätzer, der gegen die Wahrheit diszipliniert wird, solange GNSS nominal ist, und bei jeder optischen Neu-Synchronisation (lockerer) neu verankert wird; ihre Grenze enthält die Messrauschuntergrenze des Links, sodass eine Uhr, die weit besser ist als der Link, gegen das tatsächliche Rauschen der gelieferten Lösung bewertet wird. Die Sicherheit ist der uhrengestützte Spoofing-Erkennungswert gegen die Zeitgebungsspezifikation.

Geändert#

• Release Notes werden nun aus dem kuratierten CHANGELOG-Abschnitt für das Tag erzeugt (scripts/changelog-extract.sh), sodass jedes GitHub-Release hervorhebt, was sich geändert hat, statt rohe Commits aufzulisten.

0.3.0 - 2026-06-02#

Hinzugefügt#

• Sicherheits-Gütekennzahl (bisher unbelegt): ein uhrengestützter Spoofing-Erkennungswert für die Pakete Uhren-holdover und Bahn. Sie modelliert einen Integritätsmonitor, der die aus GNSS abgeleitete Zeit über ein kohärentes Fenster mit der eigenen fortgeschriebenen Vorhersage der Uhr abgleicht; die Erkennungsuntergrenze kombiniert das gemittelte Messrauschen mit der Fortschreibungsunsicherheit der Uhr, sodass eine ruhigere Uhr kleinere, langsamere Zeit-Spoofings erkennt. Der Wert wird in [0, 1] relativ zur Zeitgebungsspezifikation gemeldet und vervollständigt damit die sechs betrieblichen Gütekennzahlen.
• Aus der Geometrie abgeleitete Positionsgenauigkeit für das Bahnpaket: Aus der Sichtlinien-Geometrie zu den sichtbaren Satelliten bildet sie die Entwurfsmatrix und ihren Kovarianzfaktor Q = (HᵀH)⁻¹ und liefert so die Dilution-of-Precision-Faktoren (GDOP/PDOP/HDOP/VDOP/TDOP). Die Positionsgenauigkeit ist der Positions-DOP, skaliert mit einem konfigurierbaren Nutzeräquivalent-Entfernungsfehler (neues optionales Szenariofeld sigma_uere_m). Ein Bahnergebnis trägt nun eine Geometriezusammenfassung (Anteil der Proben mit Fix, bester und mittlerer PDOP und Positionssigma).
• Ein Playground im Browser (web/), der die Engine clientseitig als WebAssembly ausführt: Man wählt ein Referenzszenario oder bearbeitet das TOML, führt es aus und sieht Zusammenfassung, Diagramm und vollständiges JSON, ohne dass etwas hochgeladen wird. Ein Workflow pages baut und veröffentlicht ihn auf GitHub Pages, und ein neuer WebAssembly-Export summary liefert die Anzeige.
• Beschriftete y-Achsen in den SVG-Diagrammen: Gitternetzlinien, numerische Teilstrichbeschriftungen und ein Achsentitel mit Einheiten (über einen gemeinsamen Helfer chart), sodass Größenordnungen lesbar sind.
• Workflow zur Paketveröffentlichung (publish) für crates.io, PyPI und npm, jeweils abhängig vom Token der Registry und ausgelöst durch ein veröffentlichtes Release.

0.2.0 - 2026-06-02#

Hinzugefügt#

• Flicker-(1/f-)FM-Untergrenze für das Uhrenfehlermodell, synthetisiert als Summe logarithmisch verteilter Ornstein-Uhlenbeck-Prozesse und so kalibriert, dass die flache Untergrenze der Allan-Abweichung auf einem konfigurierbaren Niveau liegt. Standardmäßig aus; je Uhr über das optionale Szenariofeld flicker_floor aktivierbar.
• Gyro-Kanal für das Inertialmodell: Der verbleibende Gyro-Bias und der Winkel-Random-Walk treiben einen Lagefehler (Neigung) an, der die Schwerkraft in einen horizontalen Fehler der spezifischen Kraft einkoppelt, den dominanten Mechanismus des Fehlerwachstums beim Strapdown. Standardmäßig aus; je Sensor über die optionalen Felder gyro_bias und q_arw aktivierbar.
• Kalman-Uhrenschätzer mit zwei Zuständen (Phase, Frequenz) mit exakter Diskretisierung des Prozessrauschens nach van Loan. Das Fortschreiben von einem bekannten Zustand aus reproduziert das analytische Wachstum des holdover-Fehlers (q_wf*T + q_rw*T^3/3) exakt, und das Filter liefert zusätzlich eine Online-Unsicherheitsgrenze von 1 Sigma.
• Der Uhrenlauf meldet nun die Integritäts-Gütekennzahl (bisher unbelegt): den Anteil der Ausfallproben, deren Fehler innerhalb der 3-Sigma-Schutzgrenze des Filters bleibt, ausgewiesen im JSON-Ergebnis und in der CLI-Zusammenfassung.
• Aus der Geometrie abgeleitete GNSS-Verfügbarkeit: Kreisbahn-Propagation, ein Walker-Delta-Konstellationsgenerator und Sichtlinien-Sichtbarkeit (Erdverdeckung plus Elevationsmaske) erzeugen den Verfügbarkeitsverlauf aus realer Bahngeometrie. Neue Szenarioart orbit und das Referenzszenario orbit-gnss-challenged.toml (ein Raumfahrzeug innerhalb der GNSS-Schale mit zeitweiliger Abdeckung).
• Optionale Python-Erweiterung (PyO3, abi3), die run, run_full und version bereitstellt, mit maturin verpackt (pyproject.toml) und für Linux, macOS und Windows durch einen Workflow wheels beim Release-Tag gebaut. Die Anbindung ist eine optionale Abhängigkeit hinter einem Feature-Schalter: Der Standard-Build, die Tests und das Gate der Abhängigkeitsprüfung bleiben unberührt.
• Optionales WebAssembly-Modul (wasm-bindgen), das run, chart_svg und version bereitstellt, mit wasm-pack unter dem Feature wasm gebaut; getrandom ist zielabhängig geschaltet, um auf wasm32 die Entropiequelle des Browsers zu nutzen.
• Gemeinsamer Aufruf api::run_toml, den die CLI und beide Anbindungen verwenden, sodass Kommandozeile und Anbindungen nicht auseinanderlaufen können.

Geändert#

• Die holdover-Bewertung ist nun segmentbewusst: Ausfallverläufe werden bei der GNSS-Wiedererfassung in zusammenhängende Segmente geteilt, und das gemeldete holdover ist die ungünstigste (kürzeste) Überbrückung über diese. Szenarien mit einem einzelnen Ausfall bleiben unverändert. Gilt für die Bewerter von Uhr, Inertial und Hybrid.
• Das gemeldete kind des Inertialmodells ist nun inertial (zuvor accelerometer) und spiegelt die kombinierten Kanäle von Beschleunigungsmesser und Gyro wider.

0.1.0 - 2026-06-01#

Erstes Release.

Hinzugefügt#

• Deterministische Simulations-Engine für hybrides Quanten-/klassisches PNT: eine gemeinsame Fehlermodell-Schnittstelle, deklarative GNSS-Verfügbarkeitsszenarien, holdover- / Koppelnavigations-Schätzer und Bewertung der Gütekennzahlen gegen die üblichen betrieblichen PNT-Kriterien. Die Ergebnisse sind reproduzierbar aus scenario + seed + engine version (versioniertes, selbstbeschreibendes JSON mit einem Szenario-Hash) und werden als SVG-Diagramme dargestellt. Die CLI ruft Szenarien über kind auf.
• Vier Sensorpakete, jedes an veröffentlichte Daten kalibriert und gegen die Standardbeziehung validiert:
  • Uhren-Holdover — weißes FM, Random-Walk-FM und lineare Alterung; validiert durch die überlappende Allan-Abweichung (Riley, NIST SP 1065). Chip-Scale-Atomuhr gegenüber optischer Gitteruhr mit Strontium.
  • Inertiale Koppelnavigation — Restbias + Zufallsbewegung der Geschwindigkeit, doppelt zum Positionsfehler integriert; validiert gegen die Beziehungen zum Fehlerwachstum nach Groves. Kaltatom-Beschleunigungsmesser gegenüber einem Beschleunigungsmesser in Navigationsgüte.
  • Zeitübertragung — Timing-Jitter einer optischen gegenüber einer HF-Strecke → Synchronisationsgenauigkeit → Einweg-Entfernungsmessung.
  • Hybride Fusion (Abschluss) — eine kombinierte PNT-Suite, die sowohl Zeit als auch Position halten muss, mit optionaler Uhrenstützung durch optische Zeitübertragung zwischen Satelliten.
• Ein zitiertes Referenzszenario je Paket unter scenarios/, wobei jeder numerische Parameter ein begutachtetes provenance trägt.
• Schutzvorkehrungen für Reproduzierbarkeit und Hygiene des Repositorys; CI (Format, clippy, Tests, Schutzvorkehrungen, MSRV) und eine an Tags gebundene Release-Pipeline, die alle Prüfungen erneut ausführt.
• Dokumentation: README mit Architekturdiagrammen, Bericht zum Validierungsstatus, Leitfaden zum Mitwirken, Sicherheitsrichtlinie und Verhaltenskodex; Lizenz Apache-2.0; Vorlagen für Issues/PRs und Konfiguration von Dependabot.
• Durchgehend herstellerneutral; begutachtete wissenschaftliche und metrologische Zitate bleiben erhalten.
• Lizenzhygiene nach Apache-2.0: SPDX-Header in allen Quellen, eine NOTICE mit Markenhinweis, Sign-off nach dem Developer Certificate of Origin (DCO) für Beiträge und Durchsetzung der Lizenzen/Hinweise der Abhängigkeiten durch cargo-deny in der CI.
• Open-Core-Positionierung (README): eine freie Engine unter Apache-2.0 plus verfügbarer kommerzieller Support, Integration und proprietäre Erweiterungen von Ashforde OÜ — getragen von Dienstleistungen, nicht von Lizenzgebühren.
• CITATION.cff, damit die Software zitiert werden kann.