Eine Engine. Jeder Zugang.

Führt ein Kshana-PNT-Resilienz-Szenario aus einer TOML-Definition aus und gibt seine Gütemaße zurück. Gibt die menschenlesbare Zusammenfassung gefolgt vom vollständigen Ergebnis-JSON (Gütemaße, Kurven) zurück. Kshana validiert SGP4/SDP4, IAU-Bezugssysteme, Allan-Abweichungen, GNSS-Verfügbarkeit/DOP, ARAIM-Schutzniveaus, GNSS/INS-Fusion und Quantensensor-Modelle gegen veröffentlichte Referenzen. Jede Art läuft über dieses eine Werkzeug, darunter spectrum (Hochfrequenzspektrum und Wasserfall), solar-system, constellation-design und body-pnt (Konstellationen um beliebige Himmelskörper), campaign (verkettete Phasen, Parameterdurchläufe, Monte-Carlo-Ensembles und zusammengesetzte Szenarien) und die Navigationsarten für niedrige Erdumlaufbahnen leo-signal, leo-pass, leo-navmsg, leo-pvt, leo-ppp, ntn-positioning und leo-pnt-chain. Der Inhalt wird inline übergeben: Ein Szenariofeld, das eine Datei benennt, wird abgelehnt, und ein Szenario umfasst höchstens 4 MiB. Rufen Sie zuerst list_scenario_kinds auf, um Szenariotypen und ihre Felder zu ermitteln, und list_example_scenarios / get_example_scenario für ein vollständiges lauffähiges Szenario einer Art.

Listet jede eingebaute Kshana-Szenarioart mit ihrer Beschreibung und den erforderlichen/optionalen TOML-Feldern als JSON-Array auf. Damit ermitteln Sie, welche Szenarien ausgeführt werden können und wie ein gültiges Szenario-TOML für run_scenario aufgebaut wird.

Vorabprüfung eines Kshana-Szenario-TOML: prüft, dass es sich als TOML parsen lässt, und erkennt seine Szenarioart, ohne es auszuführen. Gibt die erkannte Art oder bei fehlerhaftem TOML einen beschreibenden Fehler zurück. (run_scenario führt die vollständige Validierung durch, indem es das Szenario ausführt.)

Bewertet ein reales GNSS-Empfängerprotokoll auf Vertrauenswürdigkeit: liest ein u-blox-UBX-, RINEX-3- (optional mit Broadcast-Navigationsdaten, wodurch die eigene Positionslösung der Engine, RAIM und ein uhrgestützter Monitor hinzukommen), Android-GnssLogger- oder NMEA-Protokoll, führt die Vertrauensmonitore (Abfall der Trägerleistungsdichte zum Rauschen, AGC, Jamming-Indikator, Verlust der Signalverfolgung, Positionssprung, RAIM, Uhr) gegen eine Kalibrier-Basislinie aus und gibt zurück, wann und warum der Empfänger nicht mehr vertrauenswürdig war. Optionale [[events]] mit Beginnzeiten und vorhergesagten C/N0-Abfällen werden gegen die im Szenario angegebenen Toleranzen bewertet: erkannt, verspätet oder verpasst, und übereinstimmend oder abweichend. Gibt die Zusammenfassung und das vollständige Ergebnis-JSON zurück (Diagramm und CSV auf Anfrage; die CSV eines Schiffslaufs beginnt mit einer #-Kommentarzeile, die die Hinweisaussage trägt und die CSV-Leser mit ihrer Kommentaroption überspringen). Die Bytes des Protokolls stehen inline im TOML als text oder base64 (nur inline, höchstens 4 MiB). Eine [platform] kind = "vessel"-Tabelle wählt die maritimen Monitore aus (kinematische Konsistenz, Steuerkurs gegen Kurs über Grund, Logge, Antennenhöhe, C/N0-Streuung, Zeitkonsistenz) und fügt je Epoche einen Vertrauenswert von 0 bis 100 hinzu, mit den Monitoren, die Punkte abgezogen haben. Jede Epoche trägt außerdem ihre Satelliten-geometry (good; degraded bei wenigen Satelliten oder hohem PDOP oder HDOP; oder unknown, wenn das Protokoll keine Satellitenelevationen oder DOP enthält); jede Epoche hat ein label (good, fair, poor); für ein Schiff kommt ein geometry-Monitor zur Bewertung hinzu, der nur bei schlechter Geometrie Punkte abzieht (höchstens 15 Punkte: degraded, nie untrusted), und jeder Abzug trägt eine Klasse: geometry (der Himmel), environment oder inconsistency (angriffsartig). Für einen Datenstromausschnitt mit dem Gate verwenden Sie assess_vessel_stream. Nur beratend; Evidenzstufe MODELLED.

Listet die mitgelieferten Referenzszenarien als JSON auf: count und scenarios, ein Array aus name, kind und about (der erste Satz des eigenen Kopfkommentars der Datei). Jedes ist ein vollständiges Szenario, das unverändert läuft; das ist also der schnellste Weg zu einem gültigen TOML für eine Art: einen Namen wählen, mit get_example_scenario abrufen, bearbeiten, ausführen. Übergeben Sie kind, um nur die Beispiele einer Art aufzulisten (zum Beispiel spectrum, solar-system, constellation-design, campaign, leo-signal, leo-pass, leo-navmsg, leo-pvt).

Gibt den TOML-Text eines mitgelieferten Referenzszenarios zurück, Byte für Byte die Datei, die das Repository unter scenarios/ ausliefert. Übergeben Sie den Text (bearbeitet oder nicht) an run_scenario, report_scenario, animate_scenario oder ein Exportwerkzeug. Die Namen stammen aus list_example_scenarios. Ein Szenario, das im Repository existiert, aber nicht mitgeliefert wird, wird mit Begründung abgelehnt.

Führt ein Kshana-Szenario aus und gibt seinen Bericht zurück: eine Zusammenfassung für die Leitung, die Eingaben, jede Ergebniskennzahl mit ihrer Einheit und ihrer Kennzeichnung VALIDATED oder MODELLED, die Ereignisse, die Fähigkeitszeilen, die der Lauf ausgeübt hat, und einen Reproduzierbarkeitsnachweis (Engine-Version, SHA-256-Digests von Szenario und Ergebnis, Seed, der Befehl, der es reproduziert). format ist json (Standard; die maschinenlesbare report.json) oder html (die druckbare, eigenständige report.html mit eingebettetem Diagramm). Der Bericht einer Kampagne enthält außerdem ihre Durchlauftabelle oder die Monte-Carlo-Verteilung. Der Bericht ist eine reine Funktion des Szenarios: Es wird keine Uhr gelesen.

Führt ein Kshana-Szenario aus und gibt seine Zeitreihe als Animation zurück. format ist svg (Standard: eine animierte SVG, ohne Skript), html (eine eigenständige Wiedergabeseite) oder frames (nummerierte statische SVG-Einzelbilder plus manifest.json, höchstens 120 Einzelbilder in einer Antwort). Optional fps (1 bis 60, Standard 12), duration_s (0,5 bis 600, Standard 8) und width (480 bis 3840 Pixel, Standard 960). Das erste Inhaltselement ist eine JSON-Zusammenfassung dessen, was gezeichnet wurde: der Zeitbereich und die Einheit, die Diagrammtitel, die Anzahl der Phasen und Ereignisse, ob ein Spektrum-Wasserfall vorhanden ist, die Ergebnispfade, aus denen die Verläufe gelesen wurden, alle weggelassenen Reihen und die Dateinamen. Die Dateien folgen, je ein Inhaltselement, in der Reihenfolge, in der die files der Zusammenfassung sie aufführt. Eine Art, deren Ergebnis keine abgetastete Zeitachse hat, wird mit einer entsprechenden Meldung abgelehnt. Die Animation ist eine Darstellung der eigenen Zahlen des Laufs und gilt als MODELLED; dasselbe Szenario und dieselben Optionen ergeben byteidentische Dateien.

Meldet, welche Interoperabilitäts-Exportformate für ein Kshana-Szenario gelten, ohne es auszuführen: ein JSON-Array mit einem Eintrag je Format (czml, kml, geojson, stk, sigmf), der applies, den reason, wenn es nicht gilt, und spec_url angibt, die veröffentlichte Spezifikation, der der Schreiber folgt. CZML (Cesium Language), KML (Keyhole Markup Language), GeoJSON und die STK-Ephemeride (Systems Tool Kit) .e beschreiben die Geometrie des Szenarios; SigMF (Signal Metadata Format) zeichnet die Abtastwerte auf, die ein spectrum-Szenario mit einem [iq]-Block synthetisiert. Rufen Sie dies vor export_interop auf.

Exportiert ein Kshana-Szenario in einem Interoperabilitätsformat: czml (Cesium Language, für CesiumJS), kml (Keyhole Markup Language, für Google Earth und geografische Informationssysteme), geojson (RFC 7946), stk (Systems-Tool-Kit-Ephemeride .e, eine Datei je Satellit) oder sigmf (Signal-Metadata-Format-Aufzeichnung der synthetisierten Abtastwerte eines spectrum-Szenarios). Das erste Inhaltselement ist ein JSON-Index: format, spec_url und files, jeweils mit seinem suffix (was die Befehlszeile an den Ausgabenamen anhängt, zum Beispiel .czml oder .G01.e), bytes, sha256 und encoding. Die Dateien folgen, je ein Inhaltselement, in der Reihenfolge des Index: utf-8-Dateien als ihr Text, die binäre SigMF-Abtastdatei als base64. Eine Kampagne exportiert jedes Mitgliedsszenario, für das das Format gilt. Ein Format, das nicht gilt, wird mit Begründung abgelehnt; list_export_formats meldet alle fünf auf einmal. Zeiten sind in koordinierter Weltzeit (UTC); dasselbe Szenario ergibt byteidentische Dateien.

Schreibt eine GeoJSON-Route in ein Kshana-Szenario, das eine Wegpunktspur abfliegt, und gibt das neue Szenario-TOML zurück (mit run_scenario ausführen). Die Route ist ein LineString (oder ein Feature / FeatureCollection, das eines enthält) aus Positionen von Längen- und Breitengrad; sie ersetzt start_lat_deg, start_lon_deg, step_lat_deg, step_lon_deg und waypoints des Szenarios. Die Arten, die eine Route annehmen, sind terrain-nav, terrain-slam, gravity-map und combined-altpnt; jede andere Art wird mit Begründung abgelehnt. Geben Sie die beiden Enden der Spur an oder gleichmäßig verteilte Positionen entlang einer Geraden: Die Spurarten fliegen start + i*step, jede andere Form wird daher abgelehnt.

Exportiert die propagierte Konstellation eines orbit-Szenarios als SP3-c-Text mit präzisen Ephemeriden (das Standardformat der GNSS-Nachverarbeitung). Gibt einen Fehler zurück, wenn das Szenario nicht von der Art orbit ist.

Exportiert die mittleren Elemente eines orbit-Szenarios als CCSDS-502.0-B-2-OMM-Katalog (Orbit Mean-Elements Message), eine OMM je Satellit. Gibt einen Fehler zurück, wenn das Szenario nicht von der Art orbit ist.

Exportiert die propagierte Konstellation eines orbit-Szenarios als CCSDS-OEM-2,0-Ephemeridentext, die inertiale (TEME) Zustandszeitreihe mit Position UND Geschwindigkeit, die Flugdynamik-Werkzeuge (GMAT / Orekit / STK) lesen. Das ist das geschwindigkeitsführende Gegenstück zu export_sp3, das nur die Position enthält. Gibt einen Fehler zurück, wenn das Szenario nicht von der Art orbit ist.

Führt ein Kshana-Szenario aus und gibt seine Reproduzierbarkeitstabelle als CSV-Text zurück, die byte-stabile Tabelle, die die CLI als <scenario>.table.csv schreibt und die die Veröffentlichungen zitieren. Nur diese Arten erzeugen eine: realtime-frame-eop, lunar-time-budget, lunar-jamming, telecom-timing, leo-navmsg, wenn seine encode-decode-Analyse mit einem kepler16- oder kepler-rac-Nachrichtenmodell läuft (die Tabelle der Broadcast-Ephemeriden), und moonlight-service-volume, wenn sowohl export_site_lat_deg als auch export_site_lon_deg gesetzt sind. Gibt für jede andere Art (oder ein ungültiges Szenario) einen Fehler zurück; für die Gütemaße verwenden Sie run_scenario.

Himmelsgeometrie unter einer azimutabhängigen Horizontlinie (eine Straßenschlucht, ein Hafen, ein Fjord, ein Containerterminal): aus einem Standort, einer Zeit und Konstellationsvorgaben, Two-Line-Element-Sätzen (tle, mit einer UTC-epoch) oder als Azimut/Elevation oder ECEF angegebenen Satelliten, welche Satelliten sichtbar und welche von der Horizontlinie verdeckt sind, GDOP/PDOP/HDOP/VDOP/TDOP aus dem mit gnss_lib_py geprüften DOP-Kern, die Ost-Nord-Oben-Kofaktor- und Kovarianzmatrix mit einer Empfängeruhr je System (oder einer gemeinsamen) sowie die horizontale Fehlerellipse bei einem Sigma und bei einem angegebenen Konfidenzniveau für ein angegebenes UERE. Ohne request beschreibt es eine REPRESENTATIVE Horizontlinien-Vorgabe mit ihrer Herkunft und ihrem Schnitt für jedes Grad (ein leeres skyline_preset listet sie auf). Szenarien der Arten orbit und integrity (mit user_site), gnss-sim, jamming, leo-pvt und leo-pass nehmen über run_scenario denselben Abschnitt [skyline] entgegen. Evidenzstufe MODELLED: Geometrie unter einem angegebenen Fehlermodell, nur Sichtverbindung; keine Vorhersage des realen Fehlers eines Empfängers und keine Integritätsschranke; Konstellationsvorgaben sind ein repräsentativer Himmel, nicht der Himmel eines bestimmten Datums; tle-Text mit einer epoch (UTC) liefert den Himmel, den diese Elementsätze zu dieser Epoche ergeben (SGP4), keine Messung, und sky_source gibt an, welcher von beiden vorliegt. Trägt den Hinweis: keine typzugelassene Navigationsausrüstung. Kein Monte Carlo über MCP (Massenstichproben; verwenden Sie die CLI, Python oder WASM). Nur inline, höchstens 4 MiB.

Die Konfiguration der GNSS-IQ-Schicht als JSON: signals (die Signalnamen, die iq_scene, iq_acquire und iq_track akzeptieren), enabled (ob die IQ-Dateiwerkzeuge eingeschaltet sind), work_dir (der einzige Ordner, den sie lesen und beschreiben; jedes Pfadargument ist relativ dazu), max_samples (die meisten komplexen Abtastwerte, die ein Aufruf erzeugen oder verarbeiten darf) und, wenn ausgeschaltet, reason. IQ-Abtastwerte laufen nie über das Protokoll: Die Werkzeuge nehmen Dateipfade im Arbeitsverzeichnis entgegen und antworten mit kompakten JSON-Zusammenfassungen. Die IQ-Schicht fügt keine Synthese von Störungen oder Spoofern hinzu; es wird nie etwas gesendet. Rufen Sie dies zuerst auf.

Beschreibt eine IQ-Aufzeichnung im Arbeitsverzeichnis, ohne sie zu verarbeiten: Art (roh mit Sidecar, SigMF, SigMF-Sammlung), Abtastformat, Abtastrate, Mittenfrequenz, Gesamtzahl der Abtastwerte, Dauer, Datendateien und ihre Größe, Aufnahmegrenzen und Anzahl der Annotationen, als JSON (dieselbe Zeile, die kshana iq info ausgibt). Das optionale raw beschreibt eine Rohdatei ohne Sidecar; das optionale hash fügt den SHA-256 jeder Datendatei hinzu (liest die ganze Datei).

Erzeugt eine GNSS-IQ-Szene mit mehreren Satelliten in einer Datei im Arbeitsverzeichnis (kshana iq scene). Modus mit angegebenem Profil: signal + prns (+ optional dopplers_hz, cn0_dbhz, data). Broadcast-Modus: nav (eine RINEX-Navigationsdatei im Arbeitsverzeichnis) + rx_pos [lat, lon, alt] platziert jeden intakten GPS-Satelliten in seiner wahren Broadcast-Geometrie. Das optionale channel wendet auf Signalebene Ionosphäre, Troposphäre, Szintillation, Mehrwegeausbreitung, Landmobil-Abschattung oder NLOS an. rate_hz × duration_s muss in das Abtastbudget passen (siehe iq_signals). Schreibt die Aufzeichnung (roh + <out>.json-Sidecar oder ein SigMF-Paar) und eine Wahrheits-Sidecar-Datei; antwortet mit den geschriebenen Dateien und ihren Byte-Zahlen, der Abtastwertzahl und der Abtastung sowie der ersten Epoche der Wahrheit je Satellit (Codephase, Doppler, C/N0), gegen die iq_acquire bewertet werden kann. Die IQ-Schicht fügt keine Synthese von Störungen oder Spoofern hinzu; es wird nie etwas gesendet.

FFT-Akquisition einer oder mehrerer PRNs über einer IQ-Aufzeichnung im Arbeitsverzeichnis (kshana iq acquire). Liest nur die Abtastwerte, die eine Suche braucht (kohärente × nichtkohärente Codeperioden), die in das Abtastbudget passen müssen. Optionale frontend-Stufen (Bandpass, Notch, Austastung, Excision, AGC, Quantisierer) laufen zuerst. Antwortet mit einer Detektion je PRN: acquired, doppler_hz, code_phase_chips, der normierten Spitze statistic, ihrer Detektions-threshold und dem peak_ratio; json_out / csv_out halten außerdem das vollständige Ergebnis als Dateien, und surface_out (eine PRN; .csv, .json oder .bin) hält die gesamte Korrelationsleistungsfläche aus Doppler × Codephase mit der Spitze und ihren parabolischen und Feinsuch-Dopplerverfeinerungen.

Erfasst und verfolgt dann eine oder mehrere PRNs über einer IQ-Aufzeichnung im Arbeitsverzeichnis (kshana iq track): Die Akquisition initialisiert jeden Kanal, dann spielt die DLL/PLL-Schleifenbank (optional FLL-gestützt) die Aufzeichnung einmal ab. Die verfolgten Abtastwerte (die ganze Aufzeichnung oder ihre ersten max_seconds) müssen in das Abtastbudget passen. Die Schleifen stammen aus design (eine kshana.loop-design/1-TOML-Datei im Arbeitsverzeichnis, design_name zur Auswahl eines Entwurfs) oder dem eingebauten Entwurf, wobei die Schleifenargumente ihn überschreiben; reacquire erfasst einen Kanal erneut, der die Verriegelung verliert oder falsch verriegelt. Die Verfolgung streamt, sodass der Speicherbedarf nicht mit der Aufzeichnung wächst. Antwortet mit Namen und Hash des Entwurfs, etwaigen warnings (commensurate_sampling: Eine Abtastrate, die ein Vielfaches der halben Chiprate ist, macht Jitter und Bias der Codeschleife nicht repräsentativ) und je Kanal mit der Epochenzahl, den verfolgten Sekunden, dem endgültigen Doppler und der Codephase, dem endgültigen und mittleren C/N0 (dB-Hz), den Anteilen der Epochen in Phasen- und Codeverriegelung, locked_at_end, dem endgültigen Verriegelungszustand, erkannten falschen Verriegelungen und Wiedererfassungen. Die Ausgabe je Epoche geht nur in Dateien: epochs_out (E/P/L, Diskriminatoren, Schleifenzustände, C/N0, Verriegelungszustand; .csv/.jsonl/.bin), events_out, json_out / csv_out. Eine PRN, die nicht erfasst wurde, wird mit ihrer Statistik und Schwelle abgelehnt.

Wendet Empfänger-Front-End- und Störungsminderungs-DSP auf eine IQ-Aufzeichnung im Arbeitsverzeichnis an und schreibt das Ergebnis als neue Rohaufzeichnung mit einer <out>.json-Sidecar-Datei (kshana iq frontend). stages wählt beliebige davon: bandpass_hz [lo, hi] FIR, adaptives notch, Impuls-blank, excise im Frequenzbereich, agc und einen bits-Bit-Quantisierer (davor eine automatische AGC, außer bei no_agc), stets in dieser Reihenfolge. Die gesamte Eingabe muss in das Abtastbudget passen. Antwortet mit den verarbeiteten Abtastwerten und den geschriebenen Dateien samt ihren Byte-Zahlen. Es verarbeitet eine Aufzeichnung; es synthetisiert nichts.

Führt eine im Arbeitsverzeichnis liegende Laborwiedergabe-Kampagne aus (kshana iq campaign): Aufzeichnungen (jede beschrieben durch eine kshana.test-conditions/1-Datei, die die bekannte Wahrheit des Labors angibt) x Front-End-Ketten x Schleifenentwürfe, wobei jede Zelle verfolgt und gegen die angegebenen Bedingungen bewertet wird (Zeit bis zum Verlust der Signalverfolgung, Wiedererfassungszeit, C/N0-Verschlechterung gegenüber dem angegebenen J/S neben einer analytischen Referenz mit der Kennzeichnung MODELLED, Rate falscher Verriegelung, PLL/DLL-Jitter, Verfügbarkeit). Inkrementell: Ein Aufruf führt die ausstehenden Zellen aus, die in das Abtastbudget (oder max_cells) passen, jede fertige Zelle bleibt erhalten, und der nächste Aufruf setzt fort. Antwortet mit den Zellenzahlen, Fehlern, den geschriebenen Dateien und dem digest, sobald jede Zelle erledigt ist. Bewertet nur aufgezeichnete Daten; es synthetisiert keine Störungen.

Meldet den Fortschritt einer Laborwiedergabe-Kampagne aus ihrem Ausgabeordner im Arbeitsverzeichnis, nur durch Lesen von Dateien: erledigte und ausstehende Zellen, die Aufzeichnungen, Front-Ends und Entwürfe des Plans und den digest, sobald jede Zelle erledigt ist.

Spielt eine IQ-Aufzeichnung im Arbeitsverzeichnis über mehrere Entwürfe der Tracking-Schleife ab und meldet das Ergebnis im eingeschwungenen Zustand je Entwurf (kshana iq sweep): Die Entwürfe sind alle Entwürfe einer kshana.loop-design/1-Datei (design) oder das Produkt der Listen pll_bws_hz, dll_bws_hz, spacings_chips und coherents für den eingebauten Entwurf. Jede PRN wird einmal erfasst, und jeder Kanal (Entwurf, PRN) verfolgt dieselben Abtastwerte, sodass jedes Ergebnis genau dem entspricht, das der Entwurf allein ergäbe. Antwortet je Entwurf und PRN mit epochs, phase_jitter_deg und code_jitter_chips (über die zweite Hälfte des Laufs), phase_lock_frac, code_lock_frac, mean_cn0_dbhz und dem Hash des Entwurfs; json_out / csv_out halten die Tabelle als Dateien. Die verfolgte Spanne muss in das Abtastbudget passen (max_seconds verengt sie), und pro Aufruf laufen höchstens 256 Kanäle (Entwurf, PRN). Es verarbeitet eine Aufzeichnung; es synthetisiert nichts.

Führt die Monitore zur Erkennung von Störungen und spoofing über einer IQ-Aufzeichnung im Arbeitsverzeichnis aus (kshana iq monitor): die Breitband-Monitore power und spectral und, wenn signal + prns angegeben sind, die C/N0- und Signalqualitätsmonitore je Satellit, jeweils gegen eine Basislinie, die aus den ersten baseline_s Sekunden (oder aus einer Einstellungsdatei) gelernt wird. Antwortet mit den Reihen (Name und Länge), jedem Ereignis, das die Monitore ausgelöst haben (Beginn, Ende, Monitor, was sich änderte; höchstens 200 in der Antwort), und den Einstellungen und Basislinien, die die Monitore gelernt haben; json_out hält den ganzen Bericht (jede Reihe, jedes Ereignis und Spektrum) und csv_prefix schreibt <prefix>.series.csv und <prefix>.events.csv. Die Spanne muss in das Abtastbudget passen (max_seconds verengt sie). Ein Monitorereignis besagt, dass eine gemessene Größe ihre gelernte Basislinie verlassen hat; es benennt weder eine Ursache noch eine Quelle. Dies bewertet nur aufgezeichnete Daten; es synthetisiert nichts. Evidenzstufe: MODELLED.

Validiert eine Labor-Testbedingungsdatei (kshana iq conditions): eine kshana.test-conditions/1-Datei, als TOML- oder JSON-Text, die die bekannte Wahrheit des Labors für eine Aufzeichnung angibt (die erwarteten Satelliten, die Einschwingzeit, den angegebenen Zeitplan für jamming oder Störungen). Antwortet mit den aufgelösten Bedingungen und ihrem hash oder mit dem Grund, warum die Datei ungültig ist. Nur inline: Es wird nichts von der Festplatte gelesen, und ein Aufzeichnungspfad, den die Datei nennt, wird nicht geöffnet (eine Kampagne löst diese innerhalb des Arbeitsverzeichnisses auf). Die Eingabe ist auf 4 MiB begrenzt.

Passt das Modell des Verlusts der Signalverfolgung in der Tracking-Schleife an Laborläufe an (kshana iq labfit): Ein iq-labfit-Szenario-TOML nennt einen oder mehrere Läufe, jeweils ein Empfängerprotokoll samt seinen angegebenen Testbedingungen; die Engine lädt jedes Protokoll, passt die Schleifen- und die empirischen Modelle an, schätzt die Unsicherheit per Bootstrap und berechnet den Fehler auf dem zurückgehaltenen Datensatz. Alles steht inline: Das log jedes Laufs enthält text oder base64 (ein path wird abgelehnt), und das Werkzeug liest und schreibt keine Datei, braucht also das IQ-Arbeitsverzeichnis nicht. Alternativ nennt das [input] des Szenarios campaign = "<out-dir>", einen fertigen Ausgabeordner von kshana iq campaign: Das Werkzeug passt dann die C/N0- und Verriegelungsmodelle an dessen bewertete Zellen an (ein kshana.labfit-iq/1-Bericht; Q wird angegeben, nie angepasst, und der identifizierbare J/S-Versatz wird angepasst; bei mode = "validation" ist eine [validation]-Tabelle erforderlich). Dieser Ordner wird relativ zum IQ-Arbeitsverzeichnis aufgelöst und muss darin liegen (alles außerhalb wird abgelehnt); er wird gelesen, es wird nichts geschrieben. Antwortet mit dem geparsten report, den Residuen und Vorhersagen als CSV-Text und einer Markdown-Zusammenfassung. Die Eingabe ist auf 4 MiB begrenzt. Die Anpassung beschreibt die übergebenen Laborläufe; sie ist keine Vorhersage für andere Empfänger oder Bedingungen über das hinaus, was der Bericht angibt. Evidenzstufe: MODELLED.

Bewertet einen begrenzten Ausschnitt eines NMEA-0183-Datenstroms eines Schiffes so, wie es kshana receiver-trust live bewertet, und gibt den Vertrauenszustand je Epoche (calibrating, nominal, degraded, untrusted) und die Bewertung von 0 bis 100 zurück, zusammen mit den Monitoren, die Punkte abgezogen haben (Live-JSON-Lines-Schema 1,3: Jede Epoche trägt position, eine advisory-Aussage, dass die Ausgabe nur beratend ist, und ihre Satelliten-geometry (good, degraded mit Gründen wie few-satellites oder high-pdop, oder unknown, wenn der Ausschnitt kein GSV oder GSA enthält) mit einem label (good, fair, poor; die Geometrie zieht nur bei poor Punkte ab); jeder Abzug trägt eine class: geometry (der Himmel, kein Befund, dass kein Angriff stattfand), environment oder inconsistency (angriffsartig)), die Zusammenfassung (Anzahl nach Zustand, Geometrie und Klasse, niedrigste und letzte Bewertung, wann die erste untrusted-Epoche auftrat) und den letzten $PKSHT-Satz. session_toml deklariert das Schiff ([platform] kind = "vessel", seine Grenzen für Geschwindigkeit, Beschleunigung und Drehrate, die Antennenhöhe, ob ein Kurssensor am Bus hängt). Der Ausschnitt muss das Kalibrierfenster enthalten; die Eingabe ist auf 2 MiB und 20.000 Epochen begrenzt, und die Antwort enthält höchstens 200 Zeilen mit degraded- oder untrusted-Epochen. Dies ist die begrenzte Form des Live-Befehls: Es wird kein Socket geöffnet und nichts an einen Port geschrieben, und das Gate sowie die Telemetrie-Exporter (der dauerhaft laufende Prozess und sein --listen-Server) gibt es nur auf der Befehlszeile. Die Prüfungen können einen Spoofer nicht sehen, dessen Positionslösung mit allem auf dem Bus konsistent ist. Nur beratend: keine typzugelassene Navigationsausrüstung; der Betreiber bleibt verantwortlich. Evidenzstufe: MODELLED.

Liest den veröffentlichten Jammertest-Testkatalog und Sendeplan (NPRA/jammertest-plan, MIT) als geplante Wahrheit (kshana jammertest import): Die Slots eines Testgebiets werden zu receiver-trust-Ereignissen, wobei jede Bezeichnung die Katalog-ID und das Jahr enthält. plans enthält eine Plandatei je Tag, log_start_utc ist die erste Epoche des Protokolls, local_offset_h der Versatz des Plans zu UTC (Standard 2, CEST). Gibt events_toml zurück (an eine receiver-trust-Sitzung anhängen), events (Test-ID, Art, Beginn und Ende in Sekunden seit Protokollbeginn) und die Zahl der übersprungenen Einträge. Die Ereignisse sind GEPLANTE Slots, keine aufgezeichneten Sendezeiten: Ein Slot kann verspätet beginnen oder nie laufen, und das Feld status des Plans ist meist leer. Kein Kontakt- oder personenbezogenes Feld des Plans wird gelesen. Die Eingabe ist auf 4 MiB je Text begrenzt. Evidenzstufe: MODELLED.

Bewertet ein Empfängerprotokoll gegen den Jammertest-Zeitplan (kshana jammertest score): je geplantem Test die Erkennungslatenz (erster Alarm minus geplanter Beginn), ob er innerhalb der Toleranz erkannt wurde, verspätet oder verpasst, und die Zeit bis zur Erholung (eine alarmfreie Strecke von recover_hold_s), dazu die Fehlalarme außerhalb jedes Slots und seines Schutzintervalls. session_toml braucht nur [log] format = "ubx" (oder rinex, android, nmea, sbf); geben Sie das Protokoll als log (Textformate) oder log_base64 (binär) an. Benötigt den Katalog und den Plan als JSON (catalog_json, plans) und das Testgebiet (location). Gibt die Bewertungskarte zurück: tests, summary, baseline_contaminated und eine Kennzeichnung MODELLED. Der Zeitplan besteht aus geplanten Slots, nicht aus aufgezeichneten Sendezeiten, sodass ein Fehlschlag ein Test sein kann, der nie lief. Ein signiertes Nachweispaket braucht einen Signaturschlüssel: Verwenden Sie die Befehlszeile (kshana jammertest score --key). Die Eingabe ist auf 4 MiB je Text begrenzt. Nur beratend: keine typzugelassene Navigationsausrüstung; der Betreiber bleibt verantwortlich. Evidenzstufe: MODELLED.

Bewertet das NMEA-0183-Protokoll eines Schiffes als Stapellauf (kshana receiver-trust mit [platform] kind = "vessel"): das Bewertungsmodell, die ausgeführten Monitore und die Bewertung von 0 bis 100 jeder Epoche mit ihren Abzügen, ihre Satellitengeometrie (good, degraded, unknown) mit einem label (good, fair, poor) für jede Epoche, wobei die Geometrie nur bei poor Punkte abzieht, und eine Klasse für jeden Abzug (geometry, environment, inconsistency), mit geometry_model (Schwellen, die geltende Ober- und Untergrenze sowie die Herkunft) und geometry_summary. session_toml gibt die Grenzen des Schiffes und etwaige Monitor- oder Bewertungseinstellungen an (keine [log]-Tabelle nötig), und nmea ist der Protokolltext, wodurch das Einfügen in eine TOML-Zeichenkette entfällt. Die Eingabe ist auf 4 MiB begrenzt; die Antwort enthält das Dokument mit epochs gekürzt auf Anzahlen je Zustand und höchstens 200 Epochen mit degraded oder untrusted. Für ein Protokoll in einem anderen Format oder mit zu bewertenden [[events]] verwenden Sie assess_receiver_log. Nur beratend: keine typzugelassene Navigationsausrüstung; der Betreiber bleibt verantwortlich. Evidenzstufe: MODELLED.

Erzeugt synthetisches Brücken-NMEA 0183 für die Besatzungsausbildung aus einem nmea-scenario-TOML (kshana nmea-scenario): eine Schiffsspur und eine Zeitleiste skriptgesteuerter Ereignisse (jamming, Positions-Drag-off, Zeit-spoofing, Replay-Verzögerung, mit Erholung). Gibt den prüfsummengültigen Satzsatz (GGA, RMC, VTG, GSV, GSA, GNS, ZDA, HDT, VBW; die ersten 2000 Zeilen) und das Ausbilderprotokoll (was wann eingespielt wurde, mit der wahren Spur und einer summary auf oberster Ebene mit Spitzengeschwindigkeiten und -beschleunigungen; Drag-off-Ereignisse tragen ihre Spitzen-Drag-Geschwindigkeit und -Beschleunigung; Schema kshana-nmea-training/1) als JSON und Text zurück. Die Obergrenze sichtbarer Satelliten des Empfängers ist receiver.max_used (Standard 12). Deterministisch je seed. NUR TEXT: Nichts hier synthetisiert HF, IQ oder irgendeine Wellenform, nichts wird gesendet, und die Ausgabe dient Ausbildung und Test, nie den Live-Navigationssystemen eines Schiffes (ein Markierungssatz im Datenstrom sagt das). Beratend, keine typzugelassene Navigationsausrüstung. Das Streamen an eine TCP- oder UDP-Adresse gibt es nur auf der Befehlszeile. Vier Beispielszenarien liegen in scenarios/training/ bei.

Erstellt ein signiertes Nachweispaket für ein Zeitfenster des NMEA-0183-Protokolls eines Schiffes (kshana receiver-trust evidence): die rohen Protokoll-Bytes des Fensters, die Konfiguration mit jeder Schwelle, die Ergebnisse und Gründe je Epoche, eine eigenständige Zusammenfassungsseite und ein Manifest, das den SHA-256 jeder Datei samt dem Hash des vollständigen Protokolls und einer Hash-Kette auflistet und mit Ed25519 signiert ist. from_s/to_s sind Sekunden seit der ersten Epoche des Protokolls. Gibt die Dateien als JSON zurück (an verify_evidence_pack weiterreichen), dazu den öffentlichen Schlüssel und den Fingerabdruck des Unterzeichners. Der Signatur-Seed wird nie zurückgegeben oder protokolliert; wird signing_key_seed_hex weggelassen, wird ein Einmalschlüssel verwendet und verworfen, sodass das Paket die Integrität gegen den Schlüssel belegt, den es selbst nennt, nicht aber, wer signiert hat: Für einen Schlüssel, auf den es ankommt, erstellen Sie das Paket auf der Befehlszeile (ein hier übergebener Seed läuft durch die Unterhaltung). Die Eingabe ist auf 4 MiB und die Antwort auf 4 MiB begrenzt (verengen Sie das Fenster). Ein Paket ist ein technischer Nachweis dessen, was die Engine unter angegebenen Einstellungen aus einem Protokoll berechnet hat; es ist weder ein Rechtsgutachten noch eine Tatsachenfeststellung zu irgendeinem Ereignis noch eine Zertifizierung. Evidenzstufe: MODELLED.

Erstellt das signierte Round-Trip-Paket des Labors (kshana evidence round-trip, docs/spec/TEST-CONDITIONS.md): Es verknüpft per Hash das Szenario, das die Bewegung erzeugt hat, das kshana.test-conditions/1-Dokument des Labors, das Empfängerprotokoll und seine Bewertung gegen die angegebenen Ereignisse in einem signierten Nachweispaket, dessen config.json einen round_trip-Block enthält. Lehnt ein Paket ab, dessen Bedingungen und Bewertungsereignisse einander widersprechen oder dessen angegebener Protokoll-SHA-256 nicht der des Protokolls ist. KEIN SIGNAL: Es wird nichts geschrieben, wiedergegeben oder eingeplant; wie die Bewegung eines Szenarios den Empfänger erreichte, liegt in der Verantwortung des Betreibers und wird nur wie angegeben festgehalten. Der Signatur-Seed wird nie zurückgegeben oder protokolliert; wird er weggelassen, wird ein Einmalschlüssel verwendet und verworfen (Integrität, nicht Identität). Die Eingabe ist auf 4 MiB und die Antwort auf 4 MiB begrenzt. Ein technischer Nachweis, weder ein Rechtsgutachten noch eine Zertifizierung. Evidenzstufe: MODELLED.

Verifiziert ein signiertes Nachweispaket (kshana evidence verify): den SHA-256 jeder Datei gegen das Manifest, die Hash-Kette, die Ed25519-Signatur, mit public_key (der Schlüssel des Unterzeichners, auf anderem Weg vom Unterzeichner bezogen), dass der Unterzeichner der erwartete ist, und mit full_log, dass das vorliegende Protokoll das im Paket verzeichnete ist und dass der Ausschnitt daraus stammt. Gibt den Bericht zurück: ok, jeden Fehler nach Code und Datei, jede Prüfung, signer_pinned, Hinweise und ein verdict: verified (Unterzeichner festgelegt), intact-signer-not-pinned (alles stimmt, aber es wurde kein vertrauenswürdiger public_key angegeben, sodass die Signatur nur belegt, dass das Paket gegen den Schlüssel unversehrt ist, den es selbst nennt und den jeder erzeugen kann; sagen Sie das so, nennen Sie es nicht verifiziert) oder failed, mit einer message, die dem Benutzer gezeigt wird. require_timestamp lässt ein Paket durchfallen, das kein Zeitstempel-Token trägt. Die Eingaben sind auf 4 MiB begrenzt. Ein bestandenes verified besagt, dass der Nachweis unverändert ist und wer signiert hat (der von Ihnen angegebene Schlüssel); es besagt nicht, was ein Ereignis verursacht hat, wer verantwortlich ist oder dass das Protokoll zeigt, was der Empfänger tatsächlich empfangen hat.

Erstellt eine GNSS-Störungskarte aus offen lizenzierten Positionsmeldungen von Flugzeugen (ADS-B NIC/NACp) oder Schiffen (AIS), die als CSV-Text übergeben werden (kshana interference-map adsb|ais). Gibt ein GeoJSON-Dokument je UTC-Tag zurück (Schema kshana-interference-map/v1) (Dateinamen <source>-<dataset>-<date>.geojson; Methodenversion 2), in dem jede veröffentlichte Gitterzelle degraded, not_degraded, insufficient_sample, withheld_day_confounded oder withheld_no_background (ADS-B) bzw. anomalous/not_anomalous (AIS) ist, mit eingebetteter Methode, ihren vorab festgelegten Schwellen, der Datensatzlizenz und der Quellenangabe. Jede Zellenzahl unter dem Veröffentlichungsminimum (5) ist null (zurückgehalten, nie null), und ein Tag, dessen Hintergrund nicht geschätzt werden kann, hält seine Einstufungen zurück. Nur aggregiert: Kennungen werden im Arbeitsspeicher gehasht und nie zurückgegeben, und eine Zelle mit weniger als 5 verschiedenen Flugzeugen oder Schiffen wird nicht veröffentlicht. dataset ist eine zulässige Voreinstellung oder custom (mit licence, licence_url, attribution). Die Eingabe ist auf 4 MiB und die Antwort auf 4 MiB begrenzt (verwenden Sie ein gröberes cell_deg oder die Befehlszeile für mehr). Es wird nichts abgerufen: Landpolygone, falls für AIS gewünscht, werden übergeben. Eine degraded-Zelle benennt Störung nicht als Ursache; eine unveröffentlichte Zelle ist kein Beleg für eine ungestörte Zelle; dies ist keine Prognose. Evidenzstufe: MODELLED.

Fasst zusammen, wie viel einer Route durch gestörte Zellen einer oder mehrerer Störungskarten verläuft (kshana route-exposure): für jede Karte (eine je Quelle und UTC-Tag, das GeoJSON, das build_interference_map zurückgibt) die Routenlänge und die Anteile ihrer Länge in gestörten Zellen, in Zellen, die nicht gestört waren, in Zellen mit zu wenigen Stichproben für eine Bewertung und in Zellen, die nicht beobachtet wurden. Die Route ist ein GeoJSON-LineString oder CSV-Text lat,lon; date_from/date_to (YYYY-MM-DD) behalten Karten in einem Datumsbereich. Die Eingabe ist auf 4 MiB je Element begrenzt. Nicht beobachtete Zellen sind kein Beleg für eine freie Route; eine gestörte Zelle benennt Störung nicht als Ursache; dies beschreibt vergangene Meldungen und ist keine Prognose. Evidenzstufe: MODELLED.

Füllt die Zuordnung zu öffentlichen Rahmenwerken aus Kshana-Ergebnisdokumenten (kshana compliance-report): für welche Zeilen von sechs Resilienz-Rahmenwerken und -Normen (das US-amerikanische DHS-Rahmenwerk Resilient PNT v2.0, IMO-Leitlinien für Schiffe, EASA-Leitlinien für die Luftfahrt, NIS2 Artikel 21, EN 16803, NIST IR 8323r1) die übergebenen Läufe Belege liefern, für welche nicht, und welche Lücke jede Zeile behält. Übergeben Sie jeden Lauf als label, result (den Ergebnis-JSON-Text) und, wenn vorhanden, scenario (das Szenario-TOML, das die Art nennt, die ein Ergebnis nicht nennt; ein receiver-trust-Ergebnis braucht keines). Höchstens 64 Läufe und insgesamt 4 MiB; es wird nichts von der Festplatte gelesen. Der status jeder Zeile ist evidenced, partly-evidenced, not-evidenced oder out-of-scope, und jede Zeile behält ihre gap auch dann, wenn sie belegt ist; Eingaben, die nicht verwendet werden konnten, stehen in unrecognised und zählen nicht. Zeigen Sie zu jedem Ergebnis die statement des Berichts wörtlich an: Ein Status bedeutet, dass ein Lauf Belege für die Fähigkeiten liefert, die die Zeile nennt; er ist keine Feststellung, dass ein Rahmenwerk erfüllt ist, und er bedeutet nicht, dass irgendein Produkt von irgendjemandem bewertet oder genehmigt wurde. Beschreiben Sie die Ausgabe nicht in stärkeren Worten. Evidenzstufe: MODELLED.

Die statische Zuordnung zu öffentlichen Rahmenwerken (kshana compliance-report --mapping / --sources) als Markdown: eine Tabelle je Rahmenwerk mit der umschriebenen Anforderung jeder Zeile, den Kshana-Ausgaben, die Belege dafür liefern, und der Lücke, die die Ausgaben nicht schließen; oder, wenn sources true ist, die Quelldokumente, die die Tabellen zitieren, mit Versionen und URLs. Angeführt von der Aussage, die jeder Bericht trägt und die bei jedem Auszug erhalten bleibt: Eine als evidenced markierte Zeile bedeutet, dass ein Lauf Belege für die Fähigkeiten liefert, die die Zeile nennt; sie ist keine Feststellung, dass ein Rahmenwerk erfüllt ist, und sie bedeutet nicht, dass irgendein Produkt von irgendjemandem bewertet oder genehmigt wurde. Braucht keine Läufe.

Schätzt die Sensorparameter der Szenarien hybrid und fusion aus einem IMU-Protokoll im Stillstand (kshana imu-fit, docs/MACHINE-INPUTS.md). Diese Szenarien nehmen Rauschparameter entgegen, keine Zeitreihe: Dies liest sie aus einem Protokoll ab, das bei ruhig gehaltenem Sensor aufgezeichnet wurde, anhand der überlappenden Allan-Abweichung des integrierten Signals. Gibt JSON zurück: fit (Beschleunigungsmesser-Bias, Geschwindigkeits-Random-Walk-PSD q_va, Gyro-Bias, Winkel-Random-Walk-PSD q_arw, Bias-Instabilitätsboden, wenn das Protokoll lang genug ist, um einen zu zeigen, die Rate und Spanne des Protokolls, die frühen Allan-Steigungen und notes dazu, was nicht angepasst oder nicht als verlässlich gelten konnte), toml (eine [accel_classical]-Tabelle, deren Herkunft den SHA-256 des Protokolls nennt, bereit zum Einfügen in ein Szenario) und sha256. Ein Protokoll, das nicht im Stillstand war oder zu kurz oder ungleichmäßig abgetastet ist, ergibt falsche Parameter oder wird abgelehnt; die Steigungen (etwa -0,5, wo weißes Rauschen dominiert) zeigen, welcher Fall vorliegt. Es wird nichts auf die Festplatte geschrieben. Evidenzstufe: MODELLED (der auf das Protokoll angewandte Schätzer, keine externe unabhängige Referenz).

Listet die Normenpakete auf (kshana standards-pack list): bewertete Szenariosätze für die Testprofile des DHS-Rahmenwerks Resilient PNT, IMO MSC.1/Circ.1575 und ICAO Doc 9849 Anhang F, jeweils mit den Zielwerten, die es vor dem Lauf festlegt, und den compliance-Zeilen, für die es Belege liefert. Braucht keine Eingabe. Ein Paket misst modellierte Szenarien gegen angegebene Zielwerte; es bewertet kein Produkt. Evidenzstufe: MODELLED.

Führt ein Normenpaket aus (kshana standards-pack run <id>): jedes darin enthaltene Szenario, bewertet gegen Zielwerte, die vor dem Lauf festgelegt wurden. Gibt den Bericht zurück (jeder Test MET, NOT MET oder NEEDS INPUT, wenn er ein Empfängerprotokoll braucht und nicht bewertet wird; jeder Zielwert mit seinem gemessenen und erwarteten Wert) und dasselbe als markdown. Übergeben Sie den Bericht-JSON an compliance_report, um die Zeilen zu sehen, für die das Paket Belege liefert. Sagen Sie klar, dass ein MET-Zielwert bedeutet, dass ein modelliertes Szenario einen angegebenen Zielwert erreicht hat, und dass ein NOT MET ein festgehaltenes Ergebnis ist; beschreiben Sie die Ausgabe nie so, als zeige sie, dass ein Produkt oder ein Rahmenwerk erfüllt ist. Nur beratend: Analyseausgabe, keine typzugelassene Navigationsausrüstung. Evidenzstufe: MODELLED.

Prüft das LunaNet Augmented Forward Signal (AFS) gegen die veröffentlichte Spezifikation, festgelegt auf LNIS Version 5 Applicable Document 1 Volume A (LSIS-AFS V1.0, 29 January 2025) (kshana lunanet-afs-check, docs/LUNANET-AFS.md). Der Modus spec prüft diese Implementierung gegen die abgedruckten Codetabellen des Dokuments (die ersten und letzten 24 Chips jedes AFS-I-Gold-, AFS-Q-Weil- und Tertiärcodes für PRN 1 bis 210 sowie beide Legendre-Folgen) und gegen durchgerechnete Beispiele (SB1 BCH, CRC-24Q), Zielwerte B1 bis B10 einer Vorregistrierung; B4 meldet einen Fehlschlag (das Dokument druckt dieselben letzten 24 Chips für die Tertiär-PRN 147 und 151). Der Modus symbols prüft einen Hard-Decision-Symbolstrom (Text aus 0 und 1) auf Synchronisationsmuster, SB1-Dekodierung, FID, TOI-Kontinuität und Rahmenabstand. Die Subframes 2 bis 4 (Rate-1/2-LDPC, CRC-24Q) sind NICHT verifiziert: Die LDPC-Matrizen stehen in einem getrennten Anhang, der nicht implementiert ist. Der Modus generate gibt einen Teststrom mit Platzhalter-Subframes zurück: Symbole, keine Wellenform; Kshana schreibt kein Signal. VALIDATED nur gegen die abgedruckten Tabellen dieser Ausgabe, die das Dokument selbst mit TBC kennzeichnet; sagen Sie das, und beschreiben Sie ein Ergebnis nicht so, als zeige es, dass irgendein LunaNet-Knoten oder -Dienst korrekt ist. Nur beratend.

Bewertet eine kshana-bench-Einreichung (kshana bench score, bench/SPEC.md, docs/BENCH.md): eine Vorhersagedatei (kshana-bench-predictions/1) gegen eine Wahrheitsdatei (kshana-bench-truth/1), beide als JSON-Text, höchstens je 4 MiB, und gibt die Ergebnisdatei (kshana-bench-result/1) zurück mit der Spezifikationsversion, der Aufgabe (a Erkennung auf Empfängerprotokollen, b Erkennung auf IQ, c Vorhersage des timing holdover, d Optimismuslücke außerhalb der Verteilung), dem Split, dem SHA-256 beider Eingaben und den Metriken der Aufgabe (AUC, Erkennungswahrscheinlichkeit bei einer Obergrenze der Fehlalarmrate, RMSE je Horizont oder die Optimismuslücke). threshold ist die deklarierte Alarmschwelle der Aufgaben a und b. Es wird nichts von der Festplatte gelesen oder geschrieben. Jede Bewertung ist MODELLED und beschreibt ein Protokoll oder Korpus, nie ein Produkt; sie ist keine Zertifizierung, und keine Organisation wird durch eine Bewertung befürwortet. Evidenzstufe: MODELLED.

Stellt kshana-bench-Ergebnisdateien (kshana bench leaderboard) als statische Bestenlistenseite dar, HTML-Text in der Antwort: results ist eine Liste von kshana-bench-result/1-JSON-Texten (höchstens 256, je 4 MiB), jeder zuerst validiert; eine unter einer anderen Hauptversion der Spezifikation bewertete Datei wird abgelehnt, weil Ergebnisse verschiedener Hauptversionen nie in eine Tabelle gestellt werden. Eine Zeile besagt, dass diese Datei diesen Wert in diesem Split erzielt hat; sie bedeutet nicht, dass irgendein Produkt von irgendjemandem bewertet oder genehmigt wurde. Es wird nichts geschrieben. Evidenzstufe: MODELLED.

Stellt einen GNSS-Vertrauensdatenstrom oder ein receiver-trust-Ergebnis als Sicherheitstelemetrie-Text dar (kshana trust-telemetry, docs/TRUST-TELEMETRY.md), mit denselben Kodierern wie die Befehlszeile: prometheus (die Ausgabe des Endzustands), cef oder leef (eine RFC-5424-Syslog-Zeile je Bandwechsel oder je Epoche mit syslog_all; ohne Zeitstempel, weil keine Uhr gelesen wird) oder otlp (die OTLP/HTTP-JSON-Metriknutzlast). input_kind ist jsonl (Standard) oder result; eine Datenstromzeile, die sich nicht parsen lässt, wird übersprungen und in kshana_trust_input_errors_total gezählt. Es wird nichts gesendet, bereitgestellt oder geschrieben: Die Ausgabe ist Text in der Antwort (die laufenden Exporter, die ein Prozess sind, bleiben auf der Befehlszeile). Die vom Empfänger gemeldete Position wird weggelassen, außer expose_position ist true. Eine Eingabe, die Satellitengeometrie trägt (Live-Schema 1,3, Ergebnisse ab 0,36), fügt die Geometriekennzeichnung (good, fair, poor; nur bei poor bewertet) und den Status, HDOP, PDOP, VDOP und die verwendeten Satelliten hinzu sowie eine class-Kennzeichnung (geometry, environment, inconsistency) an jedem Grund; eine ältere Eingabe wird genau wie zuvor dargestellt. Nur beratend: Kshana ist keine typzugelassene Navigationsausrüstung (IEC 61108, IEC 61162), und der Betreiber bleibt verantwortlich. Evidenzstufe: MODELLED.

Exportiert die Fahrzeugbewegung und die Ereignisse eines Szenarios für einen GNSS-Simulator im Labor (kshana bench-export, docs/TEST-BENCH.md): eine Bewegungs-CSV mit ihrer JSON-Beschreibung (erdfeste und geodätische Position, Geschwindigkeit, Lage, UTC), NMEA-0183-GGA/RMC-Sätze, einen Wegpunkttext, wenn das Abtastraster millisekundenregelmäßig ist, und die Ereignisse des Szenarios als CSV und als [[events]]-TOML für ein receiver-trust-Szenario. Gilt für gnss-ins (seine Ausfälle des Navigationszustands sind die Ereignisse), jamming und gnss-sim; eine andere Art wird mit Begründung abgelehnt. epoch ist der UTC-Zeitpunkt des Bewegungszeitpunkts null, YYYY-MM-DDTHH:MM:SS (Standard 2024-01-01T00:00:00Z). Es wird nichts auf die Festplatte geschrieben: Das erste Inhaltselement ist ein JSON-Index (files mit suffix, bytes, sha256; notes zu jeder weggelassenen Datei; notice), gefolgt vom Text jeder Datei in Indexreihenfolge. Dasselbe Szenario mit derselben Epoche ergibt byteidentische Dateien. KEIN SIGNAL: Nichts Exportiertes ist ein Hochfrequenz- oder Basisbandsignal, modelliert eines oder steuert eines, und ein Ereignis ist ein benanntes Intervall, keine Anleitung zur Erzeugung von Störungen; der Simulator und sein Betreiber liefern die Signale und sind dafür verantwortlich, sie nur dort auszuführen, wo es erlaubt ist. Behalten Sie den Hinweis bei den Dateien. Kshana veröffentlicht keine Ergebnisse aus solchen Läufen. Evidenzstufe: MODELLED.

Bindet im Arbeitsspeicher ein RFC-3161-Zeitstempel-Token an ein Nachweispaket (kshana evidence attach-timestamp): files ist ein Paket, wie create_evidence_pack es zurückgibt, token_base64 die Bytes der .tsr-Datei einer Zeitstempelautorität. Das Token wird als timestamp.tsr neben dem signierten Manifest gespeichert, nicht darin, und das Paket mit dem Token muss weiterhin verifizieren, sonst wird nichts angehängt; ein vorhandenes Token bleibt erhalten, außer replace ist true. Gibt die aktualisierten files zurück (an verify_evidence_pack mit require_timestamp true weiterreichen, um das Vorhandensein des Tokens zu erzwingen) und die Verifikationshinweise. Dies prüft NICHT die Signatur der Zeitstempelautorität auf dem Token oder das Zertifikat der Autorität (es prüft die Struktur des Tokens und dass sein Message-Imprint der Hash der manifest.json dieses Pakets ist): Sagen Sie das, und verweisen Sie den Benutzer auf openssl ts -verify. Eingabe und Antwort sind auf 4 MiB begrenzt. Ein Zeitstempel zeigt, dass ein Hash zu einem von der Autorität angegebenen Zeitpunkt existierte; er ist kein Rechtsgutachten. Evidenzstufe: MODELLED.