• Przećwicz minutę, w której GNSS gaśnie
• Co nowego w 0,40, Co nowego w 0,39, Co nowego w 0,38 oraz 0,38 szczegółowo: ocena jammertest, własne flagi odbiornika, wejścia maszynowe, czas i holdover, pakiety norm, LunaNet AFS, pełna pętla laboratoryjna, kshana-bench, obserwatorium, eksportery, optyka, nawigacja użytkowników przestrzeni kosmicznej i infrastruktura księżycowa
• Kshana Studio i każda strona Studio
• Możliwości: tabela obszarów, każdy rodzaj scenariusza według rodziny, każde polecenie, każda powierzchnia
• Jak działa przebieg, Misje
• Dowody: rejestr (ledger), dziedziny możliwości
• Instalacja, Architektura (i diagramy), asystent AI
• Wydania, Badania, Cytowanie, Licencja
• Dokumentacja odniesienia: użycie, format scenariusza, wyniki, układ repozytorium, FAQ, rozwiązywanie problemów, wersjonowanie, plan rozwoju, współtworzenie, dokumentacja

Uruchom dowolny z nich poleceniem kshana example <scenario> > s.toml && kshana s.toml: scenariusze to l-band-waterfall-jamming, constellation-multi-gnss-coverage, solar-system-tour i leo-pass-iridium.

Wszystkie cztery to dane wymyślone i doradcze: pokazują format i zachowanie oprogramowania, a nie to, jak jakikolwiek odbiornik lub system radzi sobie z zakłóceniami. Pierwszy uruchom poleceniem kshana receiver-trust examples/maritime-trust/session.toml, drugi poleceniem kshana route-exposure na próbkach w examples/interference-map/, trzeci poleceniem kshana nmea-scenario scenarios/training/coastal-drag-off.toml --out drag.nmea (tylko do szkolenia: nigdy nie podawaj go na wejście żywego sprzętu nawigacyjnego), a czwarty jak w docs/EVIDENCE-PACKS.md.

Poniżej pełny opis dziedzina po dziedzinie; rejestr dojrzałości poszczególnych możliwości znajdziesz w docs/CAPABILITY.md i docs/VALIDATION.md.

Każda możliwość jest dostępna jako API w Rust, uruchamialny scenariusz kind lub jedno i drugie. Dojrzałość każdej możliwości — sprawdzona, uruchamialna lub biblioteczna — jest śledzona w docs/CAPABILITY.md. Sprawdzana maszynowo macierz weryfikacji (src/verification.rs) przedstawia odsyłacze wymaganie → moduł → test → wyrocznia → status, z testowanymi jednostkowo niezmiennikami uczciwości, które dopuszczają etykietę sprawdzone tylko tam, gdzie wspiera ją niezależna zewnętrzna wyrocznia — oraz które odnotowują możliwości sprzętowe/PA (zapewnienie produktu), których Kshana celowo nie zapewnia.

Wyniki#

Każdy scenariusz porównuje czujnik kwantowy z jego klasycznym odpowiednikiem w ciągu ~1,8 h przerwy GNSS. Liczby są odtwarzalne (scenario + seed + version).

_{Co dają czujniki kwantowe, gdy brakuje GNSS — clock-holdover · ziarno 42 · narysowane w silniku 0.40.0, a każda powyższa wartość jest ponownie sprawdzana względem bieżącego silnika przy każdej kompilacji przez tests/published_figures_still_reproduce.rs · SVG}

Przewaga zależy od czasu przerwy i drgań, z jawnym punktem równowagi, w którym wygrywa klasyczne — pokazana uczciwie na drabinie gotowości technologicznej (wartości zegarów optycznych to cele demonstratorów naziemnych; żaden optyczny zegar strontowy nie poleciał w kosmos):

_{Punkt przecięcia odporności kwantowej i klasycznej — drabina TRL holdover zegara (góra) · mapa przewagi inercyjnej z konturem punktu równowagi (dół). Do ponownego wygenerowania przez cargo run --release --bin crossover_study.}

Błąd pozycji w nawigacji zliczeniowej podczas przerwy GNSS: czujnik kwantowy (niebieski) pozostaje płaski blisko specyfikacji; czujnik klasyczny (czerwony) rozbiega się do dziesiątek kilometrów. Wygenerowane przez Kshana z scenarios/imu-deadreckoning.toml.

Zwieńczenie pokazuje tezę o fuzji: optyczny międzysatelitarny transfer czasu utrzymuje w synchronizacji nawet klasyczny zegar, co izoluje czujnik inercyjny jako słabe ogniwo zestawu klasycznego — czyli kwantowy czujnik inercyjny i optyczny pomiar czasu razem.

Holdover zegara podczas przerwy GNSS: zegar optyczny (niebieski) pozostaje w specyfikacji 20 ns przez cały lot bezwładny; zegar w skali chipa (czerwony) przekracza ją w trakcie. Wygenerowane przez Kshana z scenarios/clock-holdover.toml.

Kolejny scenariusz, orbit-gnss-challenged.toml, wyprowadza dostępność GNSS z geometrii orbitalnej, a nie z ręcznie zapisanych okien: statek kosmiczny wewnątrz powłoki GNSS jest propagowany względem konstelacji Walkera podobnej do GPS, a liczba widocznych satelitów (linia widzenia, przesłonięcie przez Ziemię, maska elewacji) ustala stan pozycji w każdym kroku. W ciągu doby użytkownik ma pozycję tylko przez ~59% czasu; zegar kwantowy utrzymuje rozwiązanie czasu 5 ns przez każdą lukę (dostępność 1.0), a zegar w skali chipa tylko ~0.83.

Błąd czasu w ciągu doby przy dostępności GNSS wyprowadzonej z geometrii orbitalnej: liczba widocznych satelitów (linia widzenia, przesłonięcie przez Ziemię, maska elewacji) ustala stan pozycji w każdym kroku, więc zegar musi przetrwać każdą lukę — zegar optyczny utrzymuje specyfikację 5 ns, a zegar w skali chipa ją przekracza. Wygenerowane przez Kshana z scenarios/orbit-gnss-challenged.toml.

Konstelację można też podać jako rzeczywiste zestawy elementów dwuwierszowych (TLE). Pełny TLE (wiersz 1 + wiersz 2) jest propagowany pełnym modelem SGP4/SDP4 — w tym z oporem atmosferycznym oraz członami rezonansowymi księżycowo-słonecznymi w głębokiej przestrzeni i 12 h / 24 h, które mają znaczenie dla orbit GNSS o okresie ~12 h — sprawdzonym względem oficjalnych wektorów AIAA 2006-6753 do najgorszego przypadku ≈ 4 mm. scenarios/orbit-sgp4-gps.toml zawiera rzeczywistą migawkę Celestrak gps-ops operacyjnej konstelacji GPS (2021-07-28, 30 satelitów) i wymaga poprawnych sum kontrolnych TLE — zestawy elementów dwuwierszowych to otwarte dane z katalogu US Space Force / 18th Space Defense Squadron, redystrybuowane przez Celestrak (dr T. S. Kelso, celestrak.org); odśwież poleceniem scripts/fetch_tles.sh. Blok tylko z wierszem 2 zachowuje analityczną propagację dwóch ciał (scenarios/orbit-real-tle.toml); obie formy można mieszać w jednej konstelacji. Konstelację można równie dobrze zbudować z bloku rekordów efemeryd nadawanych GPS w RINEX-3 — formacie, który dekoduje odbiornik — propagowanych algorytmem użytkownika IS-GPS-200 i podanych na wejście tej samej geometrii (scenarios/orbit-rinex.toml).

Czym jest, a czym nie jest#

Jest to: deterministyczny silnik o niewielkiej liczbie zależności, obejmujący cały stos PNT — geometrię orbit, nawigację inercyjną, fuzję GNSS/INS, integralność, zegary i czas. Uruchamia scenariusz (często przerwę GNSS), rozwija skalibrowane modele błędów czujników przez odpowiedni estymator i ocenia wynik względem operacyjnych wskaźników jakości — emitując odtwarzalny wynik JSON (JavaScript Object Notation) i wykres SVG, z biblioteki Rust, interfejsu wiersza poleceń (CLI), rozszerzenia Pythona, modułu WebAssembly w przeglądarce, serwera Model Context Protocol (MCP) dla agentów AI lub wtyczki do środowisk JetBrains IDE (zintegrowane środowisko programistyczne).

Nie jest to: sprzęt lotniczy, projekt ładunku kwantowego, pełny odbiornik sygnałów GNSS, symulator sygnałów radiowych (RF) ani stanowisko hardware-in-the-loop, ani certyfikowany produkt awioniczny — i nie zastępuje MATLAB/Simulink, STK (Systems Tool Kit) ani Orekit; działa obok nich i wymienia z nimi pliki. Wierność sprzętu kwantowego pochodzi z opublikowanych modeli błędów, a nie z tego narzędzia. Szczegółową dojrzałość każdej możliwości opisano w docs/CAPABILITY.md.

Nie jest to (jeszcze): pełny silnik fizyki interferometrii atomowej (większość czujników kwantowych korzysta z opublikowanych współczynników Allana/budżetu szumów; akcelerometr CAI (interferometr zimnych atomów) ma warstwę z pierwszych zasad — faza Macha–Zehndera, szum projekcji, zanik kontrastu i sprzężenie drgań, a także systematyka Coriolisa i przesunięcia świetlnego — ale systematyka czoła fali i rozwiązywanie niejednoznaczności prążków pozostają warstwą planu rozwoju P2 (faza 2 planu, warstwa fizyki kwantowej), zob. ROADMAP.md i docs/QUANTUM-MODELS.md); certyfikowany ani sprzętowy odbiornik GNSS (rozwiązuje jednopunktową pozycję PVT (pozycja, prędkość i czas) z rzeczywistych obserwacji kodowych RINEX (Receiver Independent Exchange Format) — sprawdzoną na rzeczywistych danych IGS (International GNSS Service) — a jego warstwa IQ (kshana iq, od 0.31.0) programowo wykonuje akwizycję i śledzenie zarejestrowanych lub wygenerowanych próbek pasma podstawowego, jako odbiornik analityczny: nie steruje sprzętem radiowym ani niczego nie nadaje, nie jest certyfikowanym odbiornikiem i nie wykonuje pozycjonowania na fazie nośnej (RTK ani PPP)); ani pełny zestaw do projektowania misji (ma elementy składowe Lambert / porkchop / manewr / wyznaczanie orbity, ale jest warstwą symulacji osiągów nad GMAT (General Mission Analysis Tool)/Orekit, a nie ich zamiennikiem). Wyznaczenie tego zakresu jest celowe. Jeśli potrzebne są budżety błędów interferometru zimnych atomów z pierwszych zasad (np. klasy CARIOQA-PMP — Cold Atom Rubidium Interferometry in Orbit for Quantum Accelerometry, Pathfinder Mission Preparation — lub walidacja w stylu X-37B), zob. plan P2 i skontaktuj się, aby podjąć współpracę.

Walidacja, odtwarzalność i uczciwość#

• Każdy człon szumu jest skalibrowany do opublikowanej, cytowanej wartości i sprawdzony względem standardowej zależności (odchylenie Allana dla zegarów; wzrost błędu nawigacji zliczeniowej wg Grovesa dla inercyjnych; przeliczenie czasu na odległość dla transferu czasu). Status każdego członu jest śledzony w docs/VALIDATION.md jako validated lub not modeled — nic nie jest przedstawiane jako sprawdzone, jeśli nie jest.
• Odtwarzalne z założenia: scenario + seed + engine version → identical bits. scripts/check-reproducible.sh to wymusza; przebiegi kwantowe i klasyczne używają niezależnych ziaren, więc ich szum jest nieskorelowany.
• Dojrzałość jest podana uczciwie: wartości zegarów optycznych i łączy optycznych to wyniki celów / demonstratorów naziemnych, a nie lotów.

Etykieta dowodowa przy każdej wartości#

Każda wartość i tabela zapisywana przez przebieg mówi, na ile jej ufać i na których wierszach rejestru się opiera. JSON wyniku ma klucz evidence, SVG wykresu wiersz pod wykresem (oraz element <metadata id="kshana-evidence">), a tabela CSV z przodu # evidence: wierszy komentarza (odczytywanych z comment='#'). Podaje poziom, VALIDATED, MODELLED lub PARTNER, oraz identyfikatory (VM- i osiem cyfr szesnastkowych) wierszy macierzy weryfikacji, które przebieg wykorzystał. Poziom jest najsłabszy z tych wierszy, więc przebieg opierający się na jednym wierszu obliczonym z modelu jest oznaczony MODELLED, ile by obok niego nie było wierszy sprawdzonych; etykieta nigdy nie może twierdzić więcej niż rejestr. Wiersze, statusy i identyfikatory są odczytywane z macierzy, a nie wpisywane (docs/VERIFICATION-MATRIX.md, docs/SCHEMA.md), a tests/evidence_labels_doc_sync.rs kończy się niepowodzeniem, jeśli wartość nie ma etykiety lub etykieta nie zgadza się z macierzą.

Walidacja w skrócie#

Każdy wiersz jest wymuszany przez nazwany test w CI. Ta tabela to wyselekcjonowane najważniejsze wyniki; pełna, sprawdzana maszynowo macierz ma 401 wierszy — 176 VALIDATED, 221 MODELLED, 4 PARTNER (src/verification.rs), z kompletnymi dowodami (i tym, co uczciwie nie jest jeszcze sprawdzone) w docs/VALIDATION.md oraz w artefakcie kshana-validation-summary.html dla każdego wydania (generowanym przez cargo run --bin validation_report, z atestacją SLSA — Supply-chain Levels for Software Artifacts).

Kolumna Status podaje rodzaj dowodu, zgodnie z drabiną walidacji powyżej: VALIDATED = sprawdzone względem niezależnej wyroczni zewnętrznej (rzeczywiste dane, niezależna biblioteka lub opublikowane wektory referencyjne); MODELLED = sprawdzone względem prawdy analitycznej lub samospójności symulacji (bez niezależnego zewnętrznego zbioru danych). VALIDATED opisuje metodę sprawdzania, a nie zaliczenie/niezaliczenie — uczciwe niedotrafienie względem rzeczywistej wyroczni zewnętrznej pozostaje VALIDATED, natomiast porównanie, którego żaden wiersz macierzy nie wymienia jako wyroczni (dopasowanie LRO — Lunar Reconnaissance Orbiter — powyżej), jest pokazane jako MODELLED. Wiersze CI to zabezpieczenia procesu, a nie wskaźniki jakości. Kilka wysp rzeczywistych danych (mierzony zegar cezowy, Stable32 PHASE.DAT oraz kontrole OPS-SAT/ICGEM, gdzie surowe wejścia nie mają licencji na redystrybucję) jest bramkowanych danymi: test wypisuje komunikat o pominięciu i pozostaje zielony, gdy wejścia brakuje, a publiczne liczby referencyjne są zatwierdzone w tests/fixtures/. Surowe wejścia odtworzysz odpowiednim scripts/fetch_*.sh.

_{Jak możliwość zyskuje swoją etykietę — niezmiennik wymuszany w CI: brak zewnętrznej wyroczni ⇒ nie może być uznana za sprawdzoną · SVG}

_{Góra: każdy sprawdzony wiersz jest poparty zewnętrznym zbiorem danych z konstrukcji. Dół: SGP4 zgadza się z oficjalnym odniesieniem w każdym reżimie (najgorzej 4,12 mm). SVG · SVG}

_{176 sprawdzonych · 221 obliczonych z modelu · 4 partnera — SVG}

import json, kshana

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

Poza run moduł udostępnia run_full (JSON, SVG i jednowierszowe podsumowanie naraz), run_typed, validate_toml, list_kinds / scenario_kinds oraz error_kind; zob. docs/PYTHON_API.md.

Pakiet npm to cały silnik skompilowany do WebAssembly. W Node.js przekaż binarkę do initSync; w przeglądarce await init() ją pobiera (zob. README.npm.md).

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

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

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

Jeden silnik, wiele drzwi wejściowych. Jeden rdzeń w Rust (kshana) uruchamia każdy scenariusz, dostępny przez CLI, rozszerzenie Pythona, moduł WebAssembly w przeglądarce, serwer MCP dla agentów AI i wtyczkę do JetBrains IDE — wszystkie zbiegają się w jednym dyspozytorze api::run_toml. Wewnątrz pakiety czujników podłączają się do wspólnego interfejsu modeli błędów; obok nich znajdują się warstwa układów odniesienia (precesja–nutacja IAU 2006/2000A i redukcja GCRS↔ITRS oparta na CIO), warstwa astrodynamiki/numeryczna (analityczny SGP4/SDP4 oraz numeryczny propagator Cowella z modelem sił EGM2008/perturbacji, projektowaniem manewrów i wyznaczaniem orbity), warstwa integralności/GNSS (RAIM/ARAIM, SBAS, dziedzina pomiaru, zagłuszanie, cislunar), warstwa fuzji / alt-PNT (estymatory GNSS/INS oraz dopasowywacze map grawitacji/terenu/magnetyzmu), warstwa głębokiej przestrzeni i Księżyca (radiometryczne Mars-PNT i zestaw PNT księżycowego, z poziomem dowodowym każdego elementu w macierzy — czas LTC, VLBI, wspólne OD+zegar, realizacja układu odniesienia, obszar usługi, różnicowy PNT, interoperacyjność), warstwa analizy misji (budżety startu / wejścia w atmosferę / pokrycia / wskazywania / przelotu / łącza oraz środowisko pogody kosmicznej) oraz otwarta warstwa badań odporności i uczenia maszynowego (ocena odporności RPCF, luka optymizmu zakłóceń RF i demonstrator PNT z wykorzystaniem kwantowym), której odtwarzalne artefakty opierają się na sprawdzonych jądrach.

Dwa samodzielne pakiety (crate), wyłączone z przestrzeni roboczej, leżą obok rdzenia — mcp/kshana-mcp (serwer MCP, zbudowany na SDK rmcp w edycji 2024) i xval/anise-frames (kontrola krzyżowa układów ANISE/SPICE, która ściąga zależności na licencji MPL-2.0 (Mozilla Public License 2,0)) — i są trzymane poza grafem zależności opublikowanego pakietu, Cargo.lock, bramką licencji i budową MSRV (minimalna obsługiwana wersja Rust) przez listę exclude w głównym Cargo.toml. Wtyczka JetBrains (ide/jetbrains) to osobny projekt w Kotlinie. Pełny zestaw diagramów zob. docs/ARCHITECTURE.md.

Wyrenderowane diagramy (przepływ silnika, mapa modułów, dystrybucja) są w docs/ARCHITECTURE.md.

Scenariusze i raporty

Eksport i interoperacyjność

Zaufanie do odbiornika i statku

GNSS IQ (pliki w katalogu roboczym; wyłączone w trybie HTTP)

Mapowanie compliance

Benchmark

Na czym opiera się Kshana Pro. Każda część Pro pracuje na otwartym silniku i zostawia go bez zmian:

• Optymalizator projektu, badanie niepewności i dossier misji uruchamiają scenariusze otwartego silnika przez jego publiczny interfejs i obliczają każdą liczbę z wyników tych przebiegów. Każdy wynik zachowuje poziom VALIDATED, MODELLED lub PARTNER, który otwarty silnik nadał danej wartości, nigdy wyższy.
• Cyfrowe bliźniaki zegarów korzystają z modelu zegara otwartego silnika i jego estymatora odchylenia Allana: bliźniak jest kalibrowany do opublikowanego budżetu Allana urządzenia, a następnie sprawdzany przez oszacowanie odchylenia Allana bliźniaka otwartym estymatorem.
• Badania kompromisowe uruchamiają każdą opcję architektury jako scenariusz otwartego silnika, bez zmian, i szeregują opcje według wskaźnika jakości odczytanego z wyniku każdego przebiegu.
• Obserwacja kampanii odczytuje swoje wartości z wyników przebiegów scenariuszy z pakietu w otwartym silniku i porównuje je z poprzednim udanym przebiegiem.
• Współistnienie widmowe odczytuje każdą liczbę fizyczną z przebiegów otwartego silnika rodzajów leo-signal i constellation-design, a dodaje tylko sumę po widocznych satelitach i szeregowanie planów.
• Lokalna usługa zadań uruchamia otwarte scenariusze i scenariusze Pro w tym samym silniku i zapisuje każdy wynik tak, jak zwrócił go przebieg.
• Pakiety dowodowe zapisują dla każdego przebiegu skrót scenariusza, który otwarty silnik umieszcza w wyniku, więc wartość z pakietu można odtworzyć, uruchamiając scenariusz ponownie.
• Inżynieria systemów i narzędzia programowe. Narzędzia Kshana Pro do inżynierii systemów opartej na modelach (MBSE) i do programów sprawdzają wymagania programu względem przebiegów otwartego silnika: importują wymagania jako wartości rozdzielane przecinkami (CSV) albo jako udokumentowany podzbiór Requirements Interchange Format (ReqIF) lub tekstu Systems Modeling Language w wersji 2 (SysML v2), oceniają każde kryterium akceptacji, z jego jednostką, względem wartości zapisanych przez przebieg i tworzą macierz odsyłaczy weryfikacji (VCRM), model SysML v2, raport wpływu zmian i pakiet dowodowy offline. Niczego nie uruchamia ponownie ani nie przelicza i odczytuje tylko to, co publikuje otwarty silnik: result.json każdego przebiegu (pola, które wskazuje kryterium, ich jednostki, znacznik odtwarzalności ze skrótem scenariusza, ziarnem, wersją silnika i wersją schematu oraz etykietę przebiegu i poziomy wartości), jego report.json (rodzaj, zapis odtwarzalności i etykiety możliwości), plik scenariusza (jego skrót, rodzaj, ziarno i parametry), schemat jednostek pól (jednostkę, pochodzenie i poziom dowodowy każdego pola) oraz macierz weryfikacji (etykietę VALIDATED, MODELLED lub PARTNER każdej możliwości).

Wsparcie i usługi profesjonalne#

Kshana jest bezpłatna i otwartoźródłowa na licencji AGPL-3.0 oraz profesjonalnie rozwijana i utrzymywana przez Ashforde® OÜ (Estonia). Otwarty silnik jest kompletny i można go używać samodzielnie. Dla organizacji, które potrzebują więcej, Ashforde® OÜ oferuje:

• Wsparcie komercyjne i integrację: osadzenie Kshana w Twoim zestawie narzędzi, scenariusze na zamówienie i poprawki z pierwszeństwem.
• Własne modele czujników: skalibrowane do Twojego sprzętu, w tym modele odporności objęte ograniczeniami eksportowymi, utrzymywane w prywatnej nakładce.
• Kshana Pro: zastrzeżone narzędzia do inżynierii systemów opartej na modelach (MBSE) i do programów, które sprawdzają wymagania programu względem przebiegów otwartego silnika i tworzą macierz odsyłaczy weryfikacji (VCRM), model Systems Modeling Language w wersji 2 (SysML v2), raport wpływu zmian i pakiet dowodowy offline. Niczego nie uruchamia ponownie i odczytuje tylko opublikowane wyjścia silnika: result.json i report.json każdego przebiegu, plik scenariusza, schemat jednostek pól i etykiety macierzy weryfikacji (pełna lista jest w sekcji Wydania).
• Narzędzia Kshana Pro do projektowania, niepewności i misji: front Pareto przestrzeni projektowej, niepewność i czułość na tysiącach przebiegów oraz dossier misji jednym poleceniem, z macierzą weryfikacji i plikiem PDF; zob. docs/PRO.md.
• Obserwacja kampanii, współistnienie widmowe i usługa zadań w Kshana Pro: potok, który przerywa się, gdy obserwowana wartość się pogarsza, plany sygnałów sprawdzane względem otwartych sygnałów nawigacji satelitarnej w obu kierunkach oraz lokalna kolejka zadań z rejestrem dostaw powiązanym łańcuchem skrótów; zob. docs/PRO.md.
• Szkolenia i doradztwo w analizie wydajności kwantowych i klasycznych systemów PNT.

To model open-core: silnik ma i zachowa otwartą licencję; utrzymanie firmy opiera się na wiedzy, wsparciu i zastrzeżonych rozszerzeniach, a nie na opłatach licencyjnych. Kontakt: contact@ashforde.org · ashforde.org.

Instalacja i budowanie#

Wymaga toolchainu Rust (≥ 1,88, czyli rust-version w Cargo.toml; rozwijane na 1,93).

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

Sposób użycia#

Uruchom dowolny scenariusz; CLI rozpoznaje go po polu kind scenariusza i zapisuje obok niego <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html i <scenario>.report.json, a dla rodzajów, które publikują tabelę, także <scenario>.table.csv. Raport (strona HyperText Markup Language (HTML) i dokument JSON o tej samej treści) zawiera podsumowanie dla kadry kierowniczej, każde wejście z jego jednostką, wyniki i wykresy, tabele przeglądu kampanii, Monte Carlo lub łańcucha, oś zdarzeń, etykietę VALIDATED / MODELLED / PARTNER i źródło każdej możliwości użytej w przebiegu, to, czego nie modeluje, oraz zapis odtwarzalności (wersja silnika, skróty Secure Hash Algorithm 256-bit (SHA-256), ziarno, platforma i dokładne polecenie). Z przeglądarki drukuje się do czystego pliku PDF (Portable Document Format) na papierze A4 lub Letter; sam silnik nie zapisuje żadnego PDF. Zob. docs/REPORTS.md.

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

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

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

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

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

--export <czml|kml|geojson|stk|sigmf|all|list> zapisuje obok scenariusza CZML (Cesium Language), KML (Keyhole Markup Language), GeoJSON (Request for Comments 7946), efemerydy Ansys STK (Systems Tool Kit) .e i nagrania SigMF (Signal Metadata Format), a --import-route <route.geojson> wprowadza linię GeoJSON do rodzajów, w których śledzi się trasę. Każdy format jest walidowany względem opublikowanej specyfikacji, a scenariusz, do którego format nie ma zastosowania, podaje powód: zob. docs/INTEROP.md.

Inne tryby CLI: sprawdzenie scenariusza (lint), wczytanie rzeczywistych danych orientacji Ziemi lub uruchomienie całego zestawu:

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

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

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

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

Eksport animacji. --animate svg|html|frames|all zapisuje <scenario>.animation.svg (klatki kluczowe Cascading Style Sheets (CSS), bez skryptu), <scenario>.animation.html (odtwarzanie, pauza, przewijanie, prędkość i zsynchronizowane panele, bez zewnętrznych zasobów) i <scenario>.frames/ (frame_0000.svg, … oraz manifest.json z liczbą klatek na sekundę i czasem trwania). Kampania odtwarza swoje fazy i alarmy, przebieg widmowy swój wodospad; motyw podąża za prefers-color-scheme, a prefers-reduced-motion pokazuje gotowy obraz. Renderuje własne próbki przebiegu, identyczne co do bajta przy ponownym uruchomieniu, i nie dodaje dowodów. Zob. docs/ANIMATION.md.

Manifest zestawu to mały plik TOML (Tom's Obvious, Minimal Language): title i tablica scenarios = [ … ] ze ścieżkami scenariuszy, które silnik uruchamia kolejno, scalając każdy wynik (z jego etykietami MODELLED / VALIDATED) w jeden samoopisujący się artefakt badania. Zob. scenarios/quantum-pnt-demonstrator.suite.toml.

Rola w interoperacyjności. Kshana jest warstwą symulacji wydajności, która działa obok narzędzi przetwarzania końcowego, a nie ich zamiennikiem: jej wyjście RINEX podaj do RTKLIB lub gLAB, by uzyskać rozwiązanie pozycji, a jej wyjścia SP3 użyj jako precyzyjnego produktu orbitalnego w narzędziach takich jak Ginan; Kshana odpowiada na pytanie jaką odporność daje dana architektura PNT, zanim będą rzeczywiste sygnały, w formatach, które te narzędzia już przyjmują (--export-sp3 lub export_sp3 = true w scenariuszu orbit zapisuje <scenario>.sp3). Tę samą orbitę można opublikować jako średnie elementy CCSDS OMM ze ścieżki standaryzacyjnej (--export-omm lub export_omm = true zapisuje <scenario>.omm): jeden komunikat OMM 502,0 KVN (zapis słowo kluczowe = wartość) na każdego satelitę zdefiniowanego przez TLE, z rzeczywistym numerem katalogowym NORAD (North American Aerospace Defense Command), międzynarodowym oznaczeniem COSPAR (Committee on Space Research) i epoką każdego obiektu, dla dowolnego odbiorcy obsługującego OMM, zamiast dedykowanego dwuwierszowego zestawu elementów.

Przykładowe wyjście (holdover zegara; zwróć uwagę, jak raportowane są wskaźniki jakości Integrity i Security):

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

95. percentyl (p95) błędu czasu zegara optycznego wynosi 1.20e-4 ns: podsumowanie wypisuje małe wartości z cyframi znaczącymi, zamiast zaokrąglać je do 0.0. security pokazuje n/a (no attack), ponieważ ten scenariusz nie konfiguruje żadnego ataku, więc nie ma czego wykrywać. Wynik JSON nadal zawiera analityczną granicę wykrywalności spoofingu każdego zegara w fom.security (0,997 dla zegara optycznego, 0,000 dla zegara atomowego w skali układu scalonego, którego własny szum w oknie monitorowania przekracza specyfikację 20 ns), a jego blok figure_tiers oznacza tę wartość jako applicable: false. Rodzaj scenariusza spoof ocenia detekcję względem wstrzykniętego ataku. figure_tiers nadaje też każdej raportowanej wartości jej poziom weryfikacji (VALIDATED, czyli sprawdzone względem zewnętrznej wyroczni, lub MODELLED) oraz wiersz macierzy weryfikacji, z którego poziom odczytano. Scenariusz orbit dodatkowo raportuje blok geometrii: ułamek próbek z rozwiązaniem oraz najlepszy i medianowy pozycyjny współczynnik DOP (PDOP) i dokładność pozycji, obok wyniku zegara.

Przeczytaj uważnie te dwie liczby. security to analityczna granica wykrywalności spoofingu wyprowadzona ze stabilności każdego zegara; ma sens tylko dla skonfigurowanego scenariusza spoofingu i nie jest wielosatelitarnym detektorem RAIM. integrity oznacza tu samospójność filtra (ułamek próbek podczas przerwy mieszczących się w jego własnej granicy k-sigma), a nie lotniczą wartość integralności HPL/VPL. Zob. docs/INTEGRITY.md.

Dla rzeczywistej integralności autonomicznej odbiornika rodzaj scenariusza integrity (scenarios/integrity-raim.toml) uruchamia rzeczywisty RAIM migawkowy i z separacją rozwiązań (typu ARAIM) na propagowanej geometrii konstelacji: oblicza dla każdej epoki poziomy ochrony (HPL/VPL) w poziomie i w pionie oraz podaje ułamek epok, które mieszczą się w skonfigurowanych limitach alarmowych, z diagramem integralności Stanforda do klasyfikacji błąd–PL (poziom ochrony).

Odtwarzalne artefakty badań

Cztery otwarte badania odtwarzają po jednym artefakcie deterministycznym co do bajta (stałe ziarno) jednym poleceniem: liczby stojące za badaniami punktu przecięcia kwantowego i klasycznego, luki optymizmu detektorów zakłóceń RF, punktowania odporności PNT i poziomu ochrony czasu:

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

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

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

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

Każdy artefakt rejestruje wersję silnika, ziarna i skrót konfiguracji oraz nosi uczciwą etykietę MODELLED/VALIDATED. Sondy na rzeczywistych danych (*_probe) uruchamiają ten sam potok na nagraniach, które dostarczasz lokalnie; w repozytorium nie ma żadnych zbiorów danych. Badanie luki optymizmu detektorów zakłóceń RF opisano w preprincie arXiv:2606,22054, a warunkowy poziom ochrony czasu (tpl_jammertest powyżej) w preprincie arXiv:2606,24210 (zob. Cytowanie).

Opublikowane badania księżycowego PNT (arXiv:2607,06212 DOP z nadajnikami powierzchniowymi, arXiv:2607,02566 obserwowalność VLBI i arXiv:2610,23871 obserwowalność cislunarna względem długości łuku) mają swoje twierdzenia o geometrii, rozmyciu dokładności, przewidywaniu ramki czasu rzeczywistego i parametrów orientacji Ziemi (EOP), orbitach dalekich wstecznych i pomiarach odległości RF niezależnie sprawdzone krzyżowo w tests/validate_p*.rs względem osobnych wyroczni (scipy.special.j1, niezależne rozwiązanie DOP w NumPy z (HᵀH)⁻¹, ponowne sparsowanie w NumPy tych samych wierszy IERS finals2000A oraz baza NASA/JPL Three-Body Periodic Orbit Database). Są to dodatkowe kontrole regresji nad modelowanym zestawem księżycowym; nie zmieniają liczby pozycji macierzy sprawdzanych maszynowo.

Format scenariusza#

Scenariusze są deklaratywnym TOML. Pole najwyższego poziomu kind wybiera pakiet; jest ich w sumie pięćdziesiąt (clock jest domyślny, jeśli pole pominięto): inertial, timetransfer, hybrid, hybrid-ukf, fusion, gnss-ins, orbit, ephemeris, gnss-sim, integrity, lunar-integrity, lunar-time-offset, spoof, spoof-detect, jamming, sweep, sweep-nd, gravity-map, terrain-nav, terrain-slam, combined-altpnt, pvt, mars-pnt, impairment-eval (stanowisko do oceny detekcji zakłóceń RF metodami uczenia maszynowego: oznakowany korpus syntetyczny, niezależna od detektora uprząż ROC/AUC i luka optymizmu między rozkładem pierwotnym a spoza niego), quantum-trade (kompromis między PNT kwantowym a klasycznym z wczytywaniem zmierzonego ADEV i obwiednią odporności bez GNSS; MODELLED), space-weather (wskaźniki słoneczne i geomagnetyczne, temperatura egzosferyczna Jacchia-71 i zależna od aktywności gęstość termosferyczna nad atmosferą statyczną; MODELLED), oem-interop (most importu i obiegu CCSDS OEM dla efemeryd GMAT/Orekit/STK; MODELLED), trójka analiz misji launch-window (azymut startu, zmiana płaszczyzny i okazje dla dwóch ciał), reentry (korytarz balistycznego wejścia w atmosferę Allena-Eggersa), eo-coverage (geometria pasa obserwacji, GSD, dostępu i rewizyty EO), space-packet (ramkowanie Space Packet CCSDS 133,0 TM/TC, czyli telemetrii i telekomend, z dokładnym układem bitów, zweryfikowane w obie strony) oraz attitude-budget (moment gradientu grawitacyjnego o 3 stopniach swobody i budżet błędu wskazywania RSS), passes (przewidywanie przejść nad stacją naziemną: AOS/TCA/LOS, maksymalna elewacja, dostęp) i link-budget (jednokierunkowe równanie łącza CCSDS/DSN: FSPL / Eb·N₀ / zapas / zamknięcie); telecom-timing (błąd czasu w holdover, MTIE i TDEV sprawdzone względem masek ITU-T); spectrum (całe pasmo L GNSS jako jedna widmowa gęstość mocy: wodospad częstotliwość–czas pod skryptowaną osią czasu zagłuszarki o fali ciągłej, wąskopasmowej, typu chirp lub o szumie dopasowanym, stosunek zagłuszarki do sygnału w każdym paśmie i efektywna gęstość nośna do szumu z widmowego współczynnika separacji oraz wejście i wyjście nagrań Signal Metadata Format (SigMF) z estymatami widmowymi Welcha; widma sygnałów VALIDATED względem wartości podręcznikowych, scenariusz zagłuszarki MODELLED; zob. docs/SPECTRUM.md; ten sam rodzaj rysuje panele pasm UHF, S i C z zaprojektowanymi sygnałami niskiej orbity okołoziemskiej); leo-signal (projekty sygnałów pozycjonowania, nawigacji i czasu na niskiej orbicie okołoziemskiej dla dowolnego systemu: widma ograniczone pasmowo, drżenie śledzenia kodu i dokładność pomiaru odległości, przeszukiwanie i czas akwizycji, separacja widmowa względem GPS i Galileo, odporność na zagłuszanie oraz kompromis między pasmami UHF i C, z publicznych ustawień wstępnych, takich jak Xona Pulsar, Iridium, Starlink i CentiSpace, lub z projektów podanych w treści; zależności w postaci zamkniętej i Doppler LEO VALIDATED, projekty MODELLED; zob. docs/LEO-SIGNAL.md); solar-system (Słońce, planety, Pluton, Księżyc i siedem dużych księżyców w jednej epoce: położenia, stałe, czasy światła i tory orbitalne; położenia planet VALIDATED względem JPL Horizons) i body-pnt (pozycjonowanie wokół dowolnego z tych ciał z lokalną konstelacją nawigacyjną i łączem dalekiego kosmosu z Ziemi; MODELLED); campaign (istniejące rodzaje złożone w łańcuchowy harmonogram misji ze stanem przekazywanym między fazami, przegląd parametru, zasiany zespół Monte Carlo lub kilka scenariuszy w jednym wspólnym warunku; MODELLED, zob. docs/CAMPAIGNS.md); constellation-design (wzory delta i star Walkera, listy elementów i projekty wielopowłokowe z ustawieniami wstępnymi GPS, Galileo, BeiDou i GLONASS oraz pokrycie i rozmycie dokładności na siatce szerokości i długości geograficznej; generator i globalny DOP GPS VALIDATED względem opublikowanych dokumentów usługi, zob. docs/CONSTELLATION-DESIGN.md); leo-pass (przejście satelity pozycjonowania, nawigacji i czasu (PNT) na niskiej orbicie okołoziemskiej (LEO) i jego budżet łącza pasmo po paśmie, dla dowolnej konstelacji i dowolnego projektu sygnału: kąty widzenia, Doppler i jego tempo, tłumienie ITU-R przez deszcz, gazy, scyntylacje i wnikanie do budynków, gęstość nośna do szumu względem satelitów GNSS MEO w zasięgu, jonosfera pierwszego rzędu i pary wolne od jonosfery, budżet namiaru o niskiej energii, sondowanie jonosfery z każdej pary pasm oraz monitory spoofingu według spójności Dopplera i geometrii przejścia i według spójności międzypasmowej; człony ITU-R i obwiednia Dopplera użytkownika nieruchomego VALIDATED, przejście MODELLED, zob. docs/LEO-PASS.md); leo-navmsg (komunikat efemeryd i zegara rozgłaszany przez satelitę PNT na niskiej orbicie okołoziemskiej (LEO), dla dowolnej orbity i nośnej: dopasowanie od całkowanej orbity prawdziwej do zestawu keplerowskiego Galileo, ten zestaw z wielomianami poprawek wzdłuż toru, w poprzek toru i radialnych, 22-parametrowy model Liu i in. 2025 lub wielomian ECEF ATOMIC z zerowym zegarem; błąd odległości sygnału w przestrzeni (SISRE) w funkcji przedziału dopasowania i okresu aktualizacji, kontrola ciągłości aktualizacji w trakcie przejścia, własna udokumentowana ramka binarna Kshana z cykliczną kontrolą nadmiarową CRC-24Q i budżetem kwantyzacji oraz blok w stylu RINEX-4 oznaczony jako rozszerzenie Kshana; wagi SISRE, algorytm użytkownika Galileo i CRC-24Q VALIDATED, dopasowania MODELLED; opcjonalne ustawienia wstępne dla Xona Pulsar, Iridium, Starlink, CentiSpace, reprezentatywnego systemu pasma C, ATOMIC i Celeste IOD; zob. docs/LEO-NAVMSG.md); trójka połączonego PNT MEO + LEO leo-pvt (pozycjonowanie Dopplerowskie z prędkości zmiany odległości LEO, wspólne namiary pseudoodległości GNSS + LEO z błędami międzysystemowymi i DOP w funkcji liczby satelitów LEO, pokrycie polarne i arktyczne oraz transfer czasu LEO do UTC, dla dowolnej konstelacji, z opcjonalnymi ustawieniami wstępnymi, takimi jak sygnały okazjonalne Xona Pulsar, Iridium i Starlink; obwiednia Dopplera LEO VALIDATED względem opublikowanych wartości Iridium i Xona), leo-ppp (zbieżność precyzyjnego pozycjonowania punktowego samym GNSS i z uzupełnieniem LEO, porównana z Li i in. 2019) i ntn-positioning (pozycjonowanie 5G w sieci pozaziemskiej z granicy Craméra-Rao dla pasma sygnału), MODELLED poza tą obwiednią, zob. docs/LEO-PNT-FUSION.md; leo-pnt-chain (jeden system LEO-PNT od końca do końca: projekt leo-signal niesiony przez pasmo leo-pass, C/N0 przejścia i błąd odległości sygnału w przestrzeni komunikatu nawigacyjnego przekazane do połączonego namiaru leo-pvt i zbieżności leo-ppp, z wypisanym każdym przekazaniem; MODELLED, zob. docs/LEO-PNT.md, które jest też przeglądem każdego rodzaju i scenariusza LEO-PNT, w tym kampanii odporności, po jednym scenariuszu na obszar zainteresowania eksperymentu i po jednym na pionową dziedzinę użytkownika końcowego); zestaw księżycowego PNT lunar-vlbi, lunar-joint-od-clock, lunar-frame-realisation, moonlight-service-volume, lunar-differential-pnt, lunar-interop-export; demonstrator PNT z wykorzystaniem kwantowym quantum-time-transfer, quantum-gnss-free-nav, quantum-anomaly-detect; oraz rodzaje badawcze bezpieczeństwa sygnałów, cislunarne i warstwowej odporności lunar-attack-surface, realtime-frame-eop, lunar-time-budget, hybrid-optical-rf, cislunar-observability, conflict-resilience. Trójka analiz misji i te późniejsze rodzaje są w całości MODELLED (każdy ze sprawdzonym rdzeniem w postaci zamkniętej; zob. macierz). Wspólne pola: seed, siatka [time], oś czasu dostępności [gnss] (źródło przerw) oraz bloki poszczególnych czujników z ciągami provenance cytującymi źródło każdej wartości. Przykład (clock):

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

Pola opcjonalne (wyłączone, gdy ich brak): zegar może dodać flicker_floor (poziom Allana szumu 1/f FM, czyli modulacji częstotliwości); czujnik inercyjny może dodać gyro_bias i q_arw (dryf żyroskopu i błądzenie kąta losowego) oraz bias_instability i q_aa (poziom Allana niestabilności biasu i błądzenie przyspieszenia losowego), razem jednoosiowy (1-DOF) budżet błędu akcelerometru (VRW/ARW, czyli błądzenie losowe prędkości i kąta, oraz niestabilność biasu). To jest budżet błędu, który uruchamia dostarczany pakiet scenariuszy inertial. Oddzielnie biblioteka zawiera teraz zweryfikowany 3-osiowy nawigator strapdown (src/inertial/{attitude,mechanization,imu_errors}.rs): orientację kwaternionową z kompensacją coningu i sculllingu, pełną mechanizację NED (człony prędkości obrotu Ziemi i prędkości transportu, grawitacja Somigliany WGS-84) oraz deterministyczny model błędów IMU, w którym współczynnik skali, niewspółosiowość, czułość na g, kwantyzacja i narastanie prędkości są modelowane (IEEE Std 952-1997, specyfikacja i procedura testowa żyroskopów IEEE, §A.2; Groves 2013 §4,3). Ta ścieżka 3-osiowa jest teraz podłączona do uruchamialnego pakietu luźno sprzężonego GNSS/INS (kind = "gnss-ins"): 15-stanowy filtr EKF stanu błędu dyscyplinuje rozwiązanie strapdown względem zaszumionych namiarów, gdy GNSS działa, a następnie przechodzi przez przerwę bez wsparcia, raportując połączony błąd poziomy na tle wybiegu samego INS w pętli otwartej. Dostępna jest też aktualizacja ściśle sprzężona w pseudoodległości (tworzy innowację w dziedzinie odległości, więc wciąż koryguje przy mniej niż czterech satelitach). Scenariusz holdover zegara może dodać runs (> 1), aby uruchomić zespół Monte Carlo: każdy wskaźnik jakości jest wtedy podawany jako średnia z rozrzutem między 5. a 95. percentylem, a wykres zacieniowuje pasmo ufności błędu (zob. scenarios/clock-ensemble.toml).

Scenariusz fusion (te same bloki co hybrid) uruchamia dwa niezależne estymatory Kalmana, jeden dla stanu zegara i jeden dla stanu pozycji, dyscyplinowane przez GNSS i wspomagane optycznym transferem czasu, i raportuje połączony wskaźnik jakości holdover. Te dwa bloki nie mają wspólnej kowariancji: to jest ułożona obok siebie para budżetów błędu, a nie prawdziwy sprzężony filtr wspólny zegara i pozycji (kowariancja między blokami jest pozycją planu rozwoju). Zob. scenarios/fusion-pnt.toml.

Scenariusz spoof wstrzykuje spoofing czasu, jeden z czterech rodzajów [attack.shape] (linear_ramp, step_jump, meaconing, replay; sama rate_ns_per_s jest nadal przyjmowana jako liniowa rampa), i uruchamia detektor spoofingu każdego zegara. Detektorem jest dwustronny test energii χ²₁ / test Neymana–Pearsona na statystyce monitora wspomaganej zegarem: próg jest ustawiany z docelowego budżetu fałszywych alarmów target_pfa, a prawdopodobieństwo niewykrycia P_md jest podawane zarówno w postaci zamkniętej, jak i metodą Monte Carlo (mc_runs prób na hipotezę; obie wartości zgadzają się do kilku ×1/√N). Wskaźnik jakości Security to 1 − P_md przy operacyjnie szkodliwej (specyfikowanej) wielkości, więc spokojny zegar, który wychwytuje spoofing o wielkości ze specyfikacji, dostaje ≈ 1, a hałaśliwy, który często go nie wychwytuje, dostaje mniej (zob. scenarios/spoof-attack.toml, scenarios/spoof-meaconing.toml).

Scenariusz gnss-sim to symulacja w dziedzinie pomiarów: dla każdego widocznego satelity syntezuje pseudoodległość ρ = geometric range + c·δt_rx − c·δt_sv + I + T + noise + multipath i Dopplera L1, z jednoczęstotliwościową jonosferą Klobuchara ([iono], IS-GPS-200 §20.3.3.5.2.5) i zenitalną troposferą Saastamoinena rzutowaną funkcją odwzorowania Niella (1996) ([tropo]). Residua zasilają migawkowy RAIM dla HPL/VPL w każdej epoce, a pseudoodległość, Doppler, C/N₀ i poprawki jonosferyczne i troposferyczne każdego satelity są emitowane w tablicy JSON gnss_measurements. To symulator wprost (generuje pomiary ze znanej prawdy), a nie odbiornik ani solver: przebieg bez szumu odtwarza geometrię plus poprawki z dokładnością poniżej milimetra (zob. scenarios/gnss-sim-raim.toml).

Scenariusz jamming modeluje zakłócenia RF jako budżet łącza: [jammer] (położenie ECEF, moc nadawania power_dbw, typ) podnosi stosunek zagłuszarki do sygnału w [receiver] obserwującym [constellation] Walkera. Z geometrii (tłumienie w wolnej przestrzeni i zysk anteny odbiorczej w danym kierunku) oblicza J/S każdego satelity i efektywne C/N₀ ze standardowego równania antyzagłuszeniowego (zysk przetwarzania z rozproszenia widma × współczynnik separacji widmowej Q; Kaplan & Hegarty §9,4), oraz oznacza utratę synchronizacji poniżej konfigurowalnego progu śledzenia, raportując wskaźnik jakości availability_under_jamming. Zagłuszarka szerokopasmowa o mocy 10 W z odległości 1 km całkowicie uniemożliwia pracę odbiornika (J/S ≈ 72 dB); ta sama zagłuszarka z odległości 100 km tylko pogarsza łącza (zob. scenarios/jamming-demo.toml).

Scenariusz sweep prowadzi badanie kompromisowe: zmienia jeden parameter (threshold_ns, duration_s, quantum_q_wf lub classical_q_wf) od start do stop w steps punktach na scale lin lub log, zapisuje metric (np. holdover_s) dla obu zegarów i rysuje dwie krzywe. Scenariusz bazowy trafia do [base] (zob. scenarios/sweep-clock-stability.toml).

Scenariusz sweep-nd uogólnia to na dowolny pakiet i dowolną liczbę osi: zmienia klucze TOML w notacji z kropkami scenariusza [base] (o dowolnym kind) na iloczynie kartezjańskim [[axes]], ponownie uruchamia każdy węzeł siatki i zapisuje metrics podane jako ścieżki JSON w notacji z kropkami w wyniku (np. classical.fom.holdover_s). Działa dla każdego pakietu, ponieważ operuje na granicy TOML/wynik; uruchomienia natywne oceniają siatkę równolegle (bez dodatkowych zależności, wasm wraca do trybu sekwencyjnego), a wynik jest deterministyczny i w porządku wierszowym (zob. scenarios/sweep-nd-inertial.toml).

Scenariusz orbit wyprowadza oś czasu [gnss] z geometrii zamiast ją zapisywać: podaj orbitę [user], [constellation], mask_deg elewacji i dwa bloki zegarów. Raportuje też dokładność pozycji z geometrii satelitów; opcjonalne sigma_uere_m (błąd równoważny odległości użytkownika, 1-sigma, domyślnie 1 m) skaluje pozycyjne rozmycie dokładności do sigmy pozycji. Orbita użytkownika może być ekscentryczna dzięki eccentricity i argp_deg, a j2 = true dodaje wiekowy dryf od spłaszczenia Ziemi (zob. scenarios/orbit-molniya.toml). Konstelacja może być zamiast tego rzeczywista: podaj w [constellation] blok tle z zestawami elementów dwuwierszowych, a satelity zostaną z niego wczytane (zob. scenarios/orbit-real-tle.toml). Dodaj jeden lub więcej bloków [[constellations]] dla wielosystemowego GNSS (np. GPS + Galileo; zob. scenarios/orbit-multignss.toml):

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

Rodzaje alt-PNT bez GPS nawigują bez żadnego GNSS, dopasowując zmierzony ciąg pola do mapy filtrem cząsteczkowym. Scenariusz gravity-map prowadzi tor przez pole anomalii grawitacyjnych w harmonikach sferycznych i odzyskuje go z odczytu grawimetru z zimnymi atomami (scenarios/gps-denied-gravity-nav.toml); scenariusz terrain-nav robi to samo względem cyfrowego modelu terenu SRTM (TERCOM/SITAN, scenarios/terrain-nav.toml); a scenariusz combined-altpnt łączy w jednym filtrze grawitację + magnetyzm IGRF + teren (scenarios/combined-altpnt.toml).

Scenariusz lunar-integrity ocenia PNT cislunarne: wykonuje przebieg poziomu ochrony ARAIM na południowym biegunie Księżyca względem zestawu przekaźników LunaNet/LNIS i uczciwie raportuje lukę integralności: lunarne σ_URE rzędu ~30 m podnosi poziom ochrony znacznie ponad limit alarmowy 50 m, więc usługa jest niedostępna według reguł integralności w stylu lotniczym (scenarios/lunanet-araim.toml).

Scenariusz lunar-time-offset raportuje relatywistyczne tempo zegara Ziemia–Księżyc, podstawę skali Lunar Coordinate Time (LTC/TCL). Tożsamość postnewtonowska z pierwszych zasad sumuje różnicę potencjałów własnych (potencjał geoidy IAU L_G minus potencjał własny powierzchni Księżyca) i człon kinetyczny Księżyca (Doppler drugiego rzędu) do wiekowego tempa ≈ 57 µs/dobę, podawanego z opublikowanym pasmem 56–59 µs/dobę; podaje też skumulowane przesunięcie LTC−TT na horyzoncie oraz zespół z odwrotnością wariancji (księżycowy zegar papierowy). MODELLED: wartość nagłówkowa zależy od odniesienia (geoida Ziemi a selenoida Księżyca, okno uśredniania), dlatego podawane jest pasmo, a nie pojedyncza liczba uznana za wiążącą (scenarios/lunar-time-offset.toml).

Zob. scenarios/, gdzie jest co najmniej jeden działający przykład każdego rodzaju (92 rodzajów, 193 plików scenariuszy .toml + 1 manifest zestawu; kilka rodzajów ma więcej niż jeden przykład). Nie każdy rodzaj ma plik nazwany od siebie: lunar-integrity → scenarios/lunanet-araim.toml i gravity-map → scenarios/gps-denied-gravity-nav.toml to dwa z kilku takich przypadków. Rodzaje, które można uruchomić, wypiszesz w każdej chwili przez błędy cargo run -- --validate <file>, przez funkcję Pythona list_kinds() albo przez narzędzie MCP list_scenario_kinds.

Wynik#

Artefakt wyniku to wersjonowany, samoopisujący się JSON: szeregi czasowe poszczególnych kroków, ocenione wskaźniki jakości, aktywne specyfikacje modeli (z pochodzeniem), ziarno, skrót scenariusza (dzięki któremu każdy wykres można odtworzyć z pliku) oraz, dla każdego zegara, adev_curve ([{tau_s, adev, n_samples, noise, edf, ci_lo, ci_hi}]): nakładające się odchylenie Allana dla czasów uśredniania rozmieszczonych oktawowo (standardowy sposób odczytu stabilności zegara), teraz z pasmem ufności 95% zależnym od typu szumu przy każdym punkcie (typ potęgowy zapisu jest rozpoznawany z nachylenia zmodyfikowanego odchylenia Allana, a przedział χ² używa odpowiadających mu efektywnych stopni swobody NIST SP 1065). Plac zabaw w przeglądarce rysuje go jako wykres log-log „Stabilność zegara (ADEV)”. (MDEV, TDEV i HDEV są dostępne jako estymatory biblioteczne; eksportowaną krzywą wyniku jest nakładające się ADEV.) Każde pole, z jednostkami i wskazaniem źródła, jest udokumentowane w docs/SCHEMA.md.

Każdy wykres jest samoopisujący się. Plac zabaw w przeglądarce, eksport *.chart.svg z CLI i karta wyników HTML (HyperText Markup Language) opatrują każdy obraz wykresu stopką o treści Kshana v<version> · scenario <hash> · kshana.dev. scenario <hash> to pierwsze 12 znaków szesnastkowych skrótu scenariusza przebiegu: skrótu SHA-256 (256-bitowy Secure Hash Algorithm) z kanonicznej definicji scenariusza (ziarno, progi, parametry modelu, okna GNSS, …); raporty integralności i księżycowe, które nie mają własnego skrótu, używają SHA-256 ze źródła scenariusza. To ten sam odcisk, który widać w jednowierszowym podsumowaniu i w JSON wyniku, więc zapisany lub wklejony wykres zawsze niesie swoją wersję, dokładny scenariusz, który go wytworzył (do odtworzenia bit po bicie) i źródło: zmień dowolne wejście, a skrót się zmieni.

Wskaźniki jakości odpowiadają standardowym operacyjnym wskaźnikom jakości PNT:

Nowe pojęcia? Każde jest zdefiniowane prostym językiem w słowniczku.

Układ repozytorium#

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

FAQ#

Czy muszę rozumieć fizykę kwantową, żeby tego używać? Nie. Jeśli potrafisz uruchomić wiersz poleceń, uruchomisz Kshana. Zacznij od wprowadzenia prostym językiem; pojęć szukaj w słowniczku.

Czy to projekt sprzętu kwantowego albo oprogramowanie pokładowe? Nie. To symulator wydajności. Wierność sprzętu kwantowego pochodzi z opublikowanych modeli błędów, a nie z tego narzędzia. Zob. Czym jest, a czym nie jest.

Czy wyniki kwantowe są realistyczne, czy to marketing? Każdy parametr jest przypisany do karty katalogowej lub pracy, każdy model jest sprawdzony względem zależności podręcznikowej, a dojrzałość jest uczciwie oznaczona w VALIDATION.md, w tym to, że żaden optyczny zegar strontowy nie latał w kosmosie. Silnik jest neutralny: kwantowy i klasyczny to ten sam kod z różnymi opublikowanymi liczbami.

Czy mogę zaufać, że dwa przebiegi się zgadzają? Tak, przebiegi są deterministyczne: scenario + seed + engine version → bit-identical output, co wymusza scripts/check-reproducible.sh.

Czy mogę używać tego z Pythona lub w przeglądarce? Tak, zob. Instalacja: przykłady w Pythonie i WebAssembly są pod nią. Oba wywołują ten sam silnik.

Jak zamodelować własny czujnik? Napisz scenariusz .toml z opublikowanymi wartościami swojego czujnika w polach provenance. Zob. Format scenariusza i przykłady w scenarios/.

Czy jest bezpłatny do użytku komercyjnego? Tak, na licencji AGPL-3.0, także w warunkach komercyjnych, o ile przestrzegasz copyleftu AGPL (w szczególności: jeśli zmodyfikujesz Kshana i udostępnisz ją przez sieć, musisz udostępnić tym użytkownikom swój zmodyfikowany kod źródłowy). Jeśli to Ci nie odpowiada, np. musisz osadzić Kshana w zastrzeżonym produkcie lub uruchamiać zamkniętą usługę sieciową, licencja komercyjna jest dostępna od Ashforde® OÜ; zob. LICENSING.md i Wsparcie.

Rozwiązywanie problemów#

cargo build kończy się błędem na starym toolchainie. Kshana wymaga Rust ≥ 1,88. Zaktualizuj poleceniem rustup update.

Budowanie rozszerzenia Pythona kończy się błędem konsolidacji w macOS (Undefined symbols … _Py…). Rozszerzenie Pythona rozwiązuje swoje symbole w czasie ładowania. maturin ustawia właściwą flagę konsolidatora automatycznie: użyj maturin develop --features python zamiast samego cargo build.

Kompilacja Pythona zgłasza, że interpreter jest nowszy, niż zna PyO3. Ustaw PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 (koła abi3 są zgodne w przód między wersjami CPython).

Kompilacja WebAssembly nie może znaleźć celu. Zainstaluj go jednorazowo poleceniem rustup target add wasm32-unknown-unknown, a potem wasm-pack build --target web -- --features wasm.

Gdzie się podziało moje wyjście? Każdy przebieg zapisuje <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html i <scenario>.report.json obok wejściowego .toml, a dla rodzajów, które publikują tabelę, także <scenario>.table.csv. Wszystkie są celowo ignorowane przez git.

Wersjonowanie i wydania#

Kshana stosuje Semantic Versioning. Przed wersją 1.0 publiczny schemat scenariuszy i wyników może się jeszcze zmieniać; zmiany niezgodne są wyraźnie opisane w CHANGELOG.md. Każdy wynik można odtworzyć z scenario + seed + engine version.

Każdy tag vX.Y.Z publikuje automatycznie wszystkie kanały, w jednej kolejności: najpierw na oznaczonym commicie działa pełny zestaw testów, nic nie jest publikowane, dopóki nie przejdzie, a potem potok sprawdza, czy każdy rejestr rzeczywiście udostępnia nową wersję (docs/RELEASING.md). Kanały:

Wersja crate, obrazu i rejestru serwera MCP podąża za silnikiem (zawiera on bibliotekę); wtyczka JetBrains ma niezależne wersjonowanie (wywołuje zainstalowane u Ciebie binarium kshana).

Plan rozwoju#

Zob. ROADMAP.md, gdzie jest fazowy plan rozwoju, CHANGELOG.md, gdzie jest historia wydań, i docs/CAPABILITY.md, gdzie jest plan rozwoju poszczególnych możliwości. Kolejność priorytetów jest taka: najpierw dowody dla synchronizacji czasu i holdover w infrastrukturze krytycznej (maski telekomunikacyjne, dłuższy holdover ze starzeniem i szumem migotania, wczytywanie zmierzonych danych zegara); w drugiej kolejności neutralna metoda kompromisu między rozwiązaniami kwantowymi a klasycznymi (wyniki oznaczone MODELLED, dopóki zmierzone dane partnera ich nie awansują); oraz nawigacja księżycowa, cislunarna i w dalekim kosmosie jest utrzymywana, a nie rozwijana jako główny kierunek. Precyzyjna redukcja ramek ITRF jest już dostarczona: pełny łańcuch GCRS↔ITRS IAU 2006/2000A oparty na CIO (ruch bieguna + nutacja poniżej sekundy łuku), sprawdzony co do bitu względem SOFA/ERFA i niezależnie sprawdzony krzyżowo względem ANISE (SPICE w czystym Rust) do ≤ 3,6 m na orbicie GNSS. Pozycje bliskiego terminu to ściśle sprzężone łączenie fazy nośnej i udostępnienie luźno i ściśle sprzężonego nawigatora GNSS/INS w większej liczbie pakietów; silnik radiometrycznej nawigacji w dalekim kosmosie i na Marsie pojawił się w v0.17.0 (sprawdzony symulacją). Warstwa fizyki kwantowej jest pozycją P2: akcelerometr CAI jest teraz symulowany z pierwszych zasad (faza Macha–Zehndera, szum projekcji, zanik kontrastu, sprzężenie drgań), a czujniki zegara i transferu czasu są nadal sterowane opublikowanymi współczynnikami Allana i budżetu szumu. TEME↔ECEF oparte na GMST, systemy czasu IERS z sekundami przestępnymi (UTC/TAI/TT/UT1), propagacja orbit SGP4/SDP4 (v0.7.0, sprawdzona względem wektorów AIAA 2006-6753) i uruchamialny pakiet fuzji gnss-ins zostały dostarczone, a prędkość inercyjna jest udostępniona dalej. Na main trafiły: aktywny stochastyczny detektor spoofingu czasu (test energii Neymana–Pearsona / χ²₁ z P_fa/P_md metodą Monte Carlo i wskaźnikiem Security równym 1−P_md), model zagłuszania jako budżet łącza (J/S → efektywne C/N₀ → utrata synchronizacji), dostępność wielokonstelacyjna, jednoosiowy (1-DOF) budżet błędu IMU, dwa niezależne estymatory Kalmana (zegar + pozycja) raportowane jako połączony wskaźnik jakości, rzeczywista geometria konstelacji z TLE, raport w postaci karty wyników HTML, dostępność GNSS i rozmycie dokładności wyprowadzone z geometrii orbit keplerowskich z ekscentrycznością i dryfem J2, pasma ufności Monte Carlo, przeglądy parametrów w badaniach kompromisowych, plac zabaw WebAssembly w przeglądarce oraz opcjonalne wiązania Pythona (PyO3) i WebAssembly (wasm-bindgen).

Współtworzenie#

Zob. CONTRIBUTING.md. W skrócie: testy przechodzą (cargo test), dwa skrypty kontrolne przechodzą, Conventional Commits oraz wpis [Unreleased] w CHANGELOG.md dla każdej zmiany widocznej dla użytkownika. Udział w projekcie reguluje nasz Kodeks postępowania. Aby zgłosić problem bezpieczeństwa, zob. Politykę bezpieczeństwa; prosimy nie otwierać publicznego zgłoszenia o podatnościach.

Dokumentacja#

Najważniejsze źródła#

Wyrocznie walidacji i standardy: zewnętrzne autorytety, do których zakotwiczone są kontrole Kshana:

• Vallado, Crawford, Hujsak & Kelso — Revisiting Spacetrack Report #3 (AIAA 2006-6753; dane testowe): zestaw weryfikacyjny SGP4/SDP4, z którym Kshana zgadza się do 4,12 mm, oraz opracowane przykłady ramek, względem których sprawdza się łańcuch TEME→ITRF.
• IAU SOFA / ERFA — referencyjne procedury czasu i ramek, względem których nutacja IAU 2000A i redukcja GCRS↔ITRS oparta na CIO są sprawdzone co do bitu.
• Petit & Luzum (red.) — IERS Conventions (2010), IERS TN (Technical Note) 36 (orientacja Ziemi, ruch bieguna i standardy ramek).
• Riley — Handbook of Frequency Stability Analysis, NIST SP 1065 (zależności odchylenia Allana i szereg referencyjny NBS14; NBS = dawne amerykańskie National Bureau of Standards).
• Pedregosa i in. — scikit-learn: Machine Learning in Python, JMLR 12 (2011): referencyjne implementacje ROC/AUC, macierzy pomyłek oraz precyzji/czułości/F1, z którymi stanowisko do oceny detekcji zakłóceń RF jest dokładnie zgodne (tests/eval_metrics_reference.rs).
• Virtanen i in. — SciPy 1,0, Nature Methods 17 (2020): optimize.nnls, stats.chi2 i linalg.expm, czyli procedury referencyjne, względem których sprawdzane są dopasowanie NNLS zmierzonego ADEV w kompromisie kwantowym, pasma spójności χ² oraz macierz kowariancji szumu procesu zegara van Loana (tests/scipy_reference.rs).
• Knowles, Kanhere, Neamati & Gao — gnss_lib_py, SoftwareX 27 (2024): używane zarówno jako otwarty stan wiedzy (zob. Porównanie i otwarty stan wiedzy poniżej), jak i jako niezależna wyrocznia DOP, z którą obliczenia GDOP/PDOP/HDOP/VDOP/TDOP są zgodne do 1e-6 (tests/dop_reference.rs).
• Montenbruck & Gill — Satellite Orbits: Models, Methods and Applications (Springer): modele sił stojące za dopasowaniem modelu sił do precyzyjnych efemeryd agencji.
• Howell — Three-dimensional, periodic, halo orbits, Celestial Mechanics 32(1) (1984), doi:10.1007/BF01358403; Zimovan-Spreen, Howell & Davis — Near rectilinear halo orbits and nearby higher-period dynamical structures, Astrodynamics 6 (2022), doi:10.1007/s42064-021-0125-x (rodziny halo/NRHO, które odtwarza korektor różnicowy CR3BP).

Fizyka urządzeń i metod: cytowane źródła stojące za modelami czujników:

• Origlia, Schiller, Bongs i in. — arXiv:1503,08457 (optyczny zegar sieciowy ze strontem, cel zorientowany na przestrzeń kosmiczną).
• Oelker i in., Nature Photonics (2019) — doi:10.1038/s41566-019-0493-4 (laboratoryjny zegar Sr, 4,8×10⁻¹⁷).
• Templier i in., Science Advances (2022) — arXiv:2209,13209 (hybrydowa trójka akcelerometrów kwantowych).
• Groves, Principles of GNSS, Inertial, and Multisensor Integrated Navigation — samouczek IEEE AESS (Aerospace and Electronic Systems Society) (repozytorium University College London Discovery) (narastanie błędu nawigacji zliczeniowej).
• Giorgetta i in., Nature Photonics 7, 434 (2013) — arXiv:1211,4902; Deschênes i in., Phys. Rev. X 6, 021016 (2016) — APS (American Physical Society) (optyczny dwukierunkowy transfer czasu i częstotliwości; optyczne łącze międzysatelitarne wzorowane jest na tych pracach w budżecie niewzajemności).
• Betz — Binary Offset Carrier Modulations for Radionavigation, NAVIGATION 48(4) (2001), doi:10.1002/j.2161-4296.2001.tb00247.x (modulacja BOC i teoria separacji widmowej stojące za src/navsignal.rs).
• Kaplan & Hegarty (red.) — Understanding GPS/GNSS: Principles and Applications (wyd. 3, Artech House, 2017): równanie efektywnego C/N₀ przy zagłuszaniu oraz termiczne drżenie śledzenia kodu w DLL typu wczesny–późny, których używają modele sygnału nawigacyjnego i zagłuszania.

Porównanie i otwarty stan wiedzy: narzędzia i przeglądy, względem których pozycjonuje się Kshana:

• Humphreys i in. — TEXBAT (Texas Spoofing Test Battery; ION, Institute of Navigation, GNSS 2012): parametry baterii testów spoofingu, względem których charakteryzowany jest wielowarstwowy detektor.
• González i in. — NaveGo (2017): otwarte, sprawdzone profile błędów nawigacji inercyjnej używane jako klasyczny punkt odniesienia.
• Iiyama, Casadesús Vila & Gao — LuPNT (ION GNSS+ 2023, Stanford NavLab): otwarty symulator księżycowego PNT.
• Knowles, Kanhere, Neamati & Gao — gnss_lib_py, SoftwareX 27 (2024), doi:10.1016/j.softx.2024.101811: otwarta analiza danych GNSS.
• Li, Zaminpardaz, Kealy & Greentree — Quantum sensors for enhanced positioning and navigation: a comprehensive review, GPS Solutions 30(1):62 (2026), doi:10.1007/s10291-026-02030-y.
• Bertone i in. — Earth and Space Science 8(6) (2021), doi:10.1029/2020EA001454: zredukowane dynamicznie wyznaczanie orbity GRAIL, próg przyspieszenia empirycznego, który odtwarza dopasowanie LRO.