Jammertest-Bewertung: der veröffentlichte Plan als geplante Wahrheit

kshana jammertest import liest den Jammertest-Testkatalog und den Sendeplan und macht aus den Slots eines Testgebiets receiver-trust-[[events]]. kshana jammertest score lässt ein Empfängerprotokoll durch die Vertrauensmonitore laufen und bewertet es Test für Test gegen diesen Zeitplan. Jedes Ergebnis ist MODELLED: Der Zeitplan sagt, wann ein Test geplant war, nicht, wann ein Sender eingeschaltet war.

Beratende Software, keine typzugelassene Navigationsausrüstung (IEC 61108, IEC 61162): Der Betreiber bleibt für die Navigation des Schiffes verantwortlich. Nichts hiervon wird von der norwegischen Straßenverwaltung, der Nkom oder den Veranstaltern gebilligt; eine Vereinbarung mit ihnen wird nicht behauptet.

Bewertung eines synthetischen Empfängerprotokolls gegen einen Zeitplan mit drei Tests, aus einem echten Lauf der Engine v0.40.0 (`kshana jammertest score`). Das Protokoll ist erfunden: 1800 s NMEA mit einem Abfall von 20 dB C/N0 über zwei Intervalle. Der Zeitplan listet drei Slots; im mittleren Slot gibt es im Protokoll keinen Jammer. Die Bewertung markiert 2 von 3 Tests als erkannt (mediane Latenz 0 s) und 1 als verpasst, mit 0 Fehlalarm-Läufen über 0,25 h sauberer Zeit. Nichts hiervon sagt etwas über einen echten Empfänger aus. Beratende Software, keine typzugelassene Navigationsausrüstung (IEC 61108, IEC 61162): Der Betreiber bleibt für die Navigation des Schiffes verantwortlich.

Der Plan und der Katalog#

Quelle: das Repository NPRA/jammertest-plan der norwegischen Straßenverwaltung (https://github.com/NPRA/jammertest-plan), MIT-Lizenz (Copyright 2024 Norwegian Public Roads Administration; der Lizenztext wird in xval/jammertest-plan/MANIFEST.tsv geprüft). Die Dateien werden abgerufen, nie mitgeliefert:

xval/jammertest-plan/fetch.sh <dest-dir-outside-the-repo>

Es lädt die Kataloge und die Plandateien von 2025 beim festgelegten Commit 75c0b2ceea10e470c3799d14a8ef18842d8375a7 herunter und weist jede Datei zurück, deren SHA-256 von xval/jammertest-plan/MANIFEST.tsv abweicht.

Ein Katalogtest hat eine gepunktete Kennung, type.group.test (zum Beispiel 1.2.5: Typ 1 Jamming, Gruppe 2, Test 5). Der Plan listet je Testgebiet und Zeitslot auf, welche Kennung geplant ist. Die Typen 1 (Jamming), 2 (Spoofing) und 3 (Meaconing) senden; Typ 0 (Briefings, Karenzzeit, Buchungs- und Ad-hoc-Slots) tut es nicht und wird übersprungen. Planzeiten sind lokale Uhrzeit; --local-offset-h (Standard 2, CEST) gibt an, wie weit sie von UTC entfernt sind. Die Plandateien tragen ein Testkontakt-Feld mit dem Namen einer Person: Es wird nie gelesen, und nichts, was daraus abgeleitet ist, wird geschrieben.

Import#

kshana jammertest import --catalog testcatalog2025.json \
    --plan plan-tuesday-2025-09-16.json --plan plan-wednesday-2025-09-17.json \
    --location 1 --log receiver.ubx --format ubx --out events.toml

--log-start <UTC time> ersetzt --log/--format, wenn das Protokoll seinen Beginn nicht nennt. Die Ausgabe ist TOML [[events]], das an ein receiver-trust-Szenario anzuhängen ist; jede Bezeichnung beginnt mit scheduled truth: und trägt das Jahr der Ausgabe, die Katalogkennung und das Gebiet, und der Kopf hält das SHA-256 jeder Quelldatei fest. --attack-log <scenario.json> liest stattdessen die Ereigniswahrheit eines Ordners des Datensatzes JammerTest 2024 (sein attack_log, Zeitstempel verschoben um --time-shift-h, Standard -2: Sie sagen Z, sind aber Ortszeit).

Bewertung#

kshana jammertest score session.toml --catalog testcatalog2025.json --plan plan-....json \
    --location 1 [--json] [--key signer.key --out pack/]

session.toml ist ein receiver-trust-Szenario ([log] format/path, optional [monitors], [compare]). Seine eigenen [[events]] werden durch den importierten Zeitplan ersetzt. Je geplantem Test:

Feld	Bedeutung
`outcome`	`detected` (ein Alarm innerhalb von `compare.detect_tol_s`, Standard 10 s, nach dem geplanten Beginn), `late` (später, innerhalb des Slots), `missed` (keiner), `not-evaluable`
`latency_s`	erster Alarm minus geplanter Beginn
`time_to_recover_s`	vom Slot-Ende bis zum Beginn der ersten Strecke von mindestens `--recover-hold-s` (10 s) ohne Alarm, vor dem nächsten Test

Ein Test ist nur bewertbar, wenn er mindestens calibration_s + guard_s nach dem Beginn des Protokolls startet; ein Protokoll mit einem früheren Test wird mit baseline_contaminated markiert (die Basislinie wurde möglicherweise unter Störung gebildet). Fehlalarme sind alarmierende Epochen nach der Kalibrierung außerhalb jedes Slots, der um --guard-s (60 s) davor und danach verlängert ist (oder nach dem Erholungspunkt), gezählt als Epochen und als Läufe, mit Läufen je Stunde sauberer Zeit. Mit --key und --out wird der Lauf als signiertes Nachweispaket geschrieben (docs/EVIDENCE-PACKS.md): Die Auswertungskarte und der importierte Zeitplan liegen in config.json, also innerhalb der Hash-Kette und der Signatur. Ein Paket ist ein technischer Nachweis, keine Rechtsauskunft.

Was ein Ergebnis nicht aussagt#

Ein geplanter Slot ist keine Aufzeichnung der Sendezeit. Ein Sender kann spät begonnen, früh aufgehört oder nie gelaufen sein; ein „missed“-Test kann ein Test sein, der nicht gesendet hat, und eine Latenz wird ab dem geplanten Beginn gerechnet.
Eine „saubere“ Epoche ist „außerhalb der geplanten Slots“, nicht „nachweislich störungsfrei“.
Die Erkennung durch Monitore im Messraum sagt nichts über die Erkennung eines kohärenten Spoofers mit geringer Leistung aus.
Keine unabhängige externe Referenz gibt die wahren Sendezeiten an, daher ist hier nichts VALIDATED.

Der Lauf mit dem Datensatz 2024 (vorab registriert)#

xval/jammertest-score/PREREGISTRATION.md legte die Population, die Definitionen und die Zielwerte vor dem ersten bewerteten Lauf fest; xval/jammertest-score/RESULTS.md hält diesen Lauf fest. Ergebnis: die registrierte Mindestdatenregel schlug fehl (4 bewertbare Jamming-Fenster aus 4 der 12 .ubx-Ordner: 5 Ordner wurden durch die Basislinienregel verworfen, und 3 UBX-Protokolle nennen ihren Beginn nur als GPS-Wochenzeit), sodass kein Zielwert beurteilbar ist. Nichts wurde gelockert oder erneut ausgeführt. v2 (PREREGISTRATION-v2.md, allein vor seinem Lauf eingecheckt; nur Datenbehandlung, dieselben Zielwerte und dieselbe Mindestdatenregel) ordnete die Protokolle nur mit GPS-Zeit anhand des Ordnerdatums ein, bewertete die 12 Ordner nur mit CSV und verwendete für die bewegten Rover eine Sitzung mit bewegter Plattform. Ergebnis (RESULTS-v2.md): 14 von 24 Ordnern behalten, aber nur 7 bewertbare Jamming-Fenster, sodass die Mindestdatenregel erneut fehlschlug und kein Zielwert beurteilbar ist. Das Ergebnis von v1 bleibt unverändert. Nur beschreibend: 3 von 7 Jamming-Fenstern lösten innerhalb von 10 s Alarm aus, 4 später, keines wurde verpasst; mediane Latenz 18 s; Alarmrate im sauberen Zeitraum 0,089. Die bindende Grenze ist jetzt die Basislinienregel, die 10 Ordner entfernt; eine weitere Registrierung bräuchte für frühe Fenster eine andere Regel. Der Datensatz (JammerTest 2024, Zenodo 15911589, GPL-3.0-or-later) wird von xval/oracles/setup.sh abgerufen und nie mitgeliefert; der Test tests/jammertest_score_2024.rs legt den aufgezeichneten Lauf fest, wenn KSHANA_JAMMERTEST_DIR auf den entpackten Datensatz zeigt.

Der NMEA-Datensatz 2025 von SimulaMet#

Der aus NMEA abgeleitete Datensatz Jammertest 2025 von SimulaMet (IEEE DataPort, DOI 10.21227/a7v4-xw11) ist in 0,38 nicht angebunden. Seine Seite nennt keine Lizenz und sagt „This dataset requires an IEEE DataPort Subscription to access“: Die Bedingungen erlauben die Weitergabe oder einen automatisierten Abruf nicht eindeutig, daher wurde kein Adapter und kein Abrufskript geschrieben. Seine Verwendung braucht die Entscheidung des Eigentümers und idealerweise die schriftliche Zustimmung der Autoren.

Oberflächen#

CLI, Rust (kshana::jammertest), Python (jammertest_import, jammertest_score), WebAssembly (dieselben Namen), MCP-Werkzeuge mit denselben Namen sowie der Befehl /kshana-jammertest und der Skill jammertest. Das signierte Paket gibt es nur auf der Kommandozeile (es braucht einen Signierschlüssel). Siehe docs/SURFACES.md.