Traduction automatique, non relue par un locuteur natif. L'anglais fait foi.

Confiance du récepteur et maritimeModifier sur GitHubSource : docs/JAMMERTEST.md

Notation Jammertest : le plan publié comme vérité planifiée

kshana jammertest import lit le catalogue d'essais et le plan de transmission de Jammertest et transforme les créneaux d'une zone d'essai en [[events]] de confiance du récepteur. kshana jammertest score fait passer un journal de récepteur dans les moniteurs de confiance et le note par rapport à ce calendrier, essai par essai. Chaque résultat est MODELLED : le calendrier dit quand un essai était planifié, et non quand un émetteur était en marche.

Logiciel à titre consultatif, et non un équipement de navigation homologué (IEC 61108, IEC 61162) : l'opérateur reste responsable de la navigation du navire. Rien ici n'est avalisé par l'Administration norvégienne des routes publiques, Nkom ou les organisateurs de l'événement ; aucun accord avec eux n'est revendiqué.

Notation d'un journal de récepteur synthétique par rapport à un calendrier de trois essais, issue d'une véritable exécution du moteur v0.40.0 (`kshana jammertest score`). Le journal est inventé : 1800 s de NMEA avec une baisse de C/N0 de 20 dB sur deux intervalles. Le calendrier liste trois créneaux ; le créneau du milieu n'a aucun brouilleur dans le journal. La notation marque 2 essais détectés sur 3 (latence médiane 0 s) et 1 manqué, avec 0 exécution de fausse alarme sur 0,25 h de temps sans brouillage. Rien ici ne dit quoi que ce soit d'un récepteur réel. Logiciel à titre consultatif, et non un équipement de navigation homologué (IEC 61108, IEC 61162) : l'opérateur reste responsable de la navigation du navire.Notation d'un journal de récepteur synthétique par rapport à un calendrier de trois essais, issue d'une véritable exécution du moteur v0.40.0 (`kshana jammertest score`). Le journal est inventé : 1800 s de NMEA avec une baisse de C/N0 de 20 dB sur deux intervalles. Le calendrier liste trois créneaux ; le créneau du milieu n'a aucun brouilleur dans le journal. La notation marque 2 essais détectés sur 3 (latence médiane 0 s) et 1 manqué, avec 0 exécution de fausse alarme sur 0,25 h de temps sans brouillage. Rien ici ne dit quoi que ce soit d'un récepteur réel. Logiciel à titre consultatif, et non un équipement de navigation homologué (IEC 61108, IEC 61162) : l'opérateur reste responsable de la navigation du navire.

Le plan et le catalogue#

Source : le dépôt NPRA/jammertest-plan de l'Administration norvégienne des routes publiques (https://github.com/NPRA/jammertest-plan), licence MIT (copyright 2024 Administration norvégienne des routes publiques ; le texte de la licence est enregistré dans xval/jammertest-plan/MANIFEST.tsv). Les fichiers sont récupérés, jamais intégrés au dépôt :

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

Il télécharge les catalogues et les fichiers du plan 2025 au commit figé 75c0b2ceea10e470c3799d14a8ef18842d8375a7 et refuse tout fichier dont le SHA-256 diffère de celui de xval/jammertest-plan/MANIFEST.tsv.

Un essai du catalogue a un identifiant pointé, type.group.test (par exemple 1.2.5 : type 1 brouillage, groupe 2, essai 5). Le plan liste, par zone d'essai et par créneau, quel identifiant est planifié. Les types 1 (brouillage), 2 (leurrage) et 3 (meaconing) émettent ; le type 0 (briefings, période de grâce, créneaux de réservation et ponctuels) n'émet pas et est ignoré. Les heures du plan sont l'heure locale murale ; --local-offset-h (par défaut 2, CEST) dit de combien elles s'écartent de l'UTC. Les fichiers du plan comportent un champ de contact d'essai avec le nom d'une personne : il n'est jamais lu, et rien qui en dérive n'est écrit.

Importation#

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> remplace --log/--format lorsque le journal n'indique pas son début. La sortie est du TOML [[events]] à ajouter à un scénario de confiance du récepteur ; chaque étiquette commence par scheduled truth: et porte l'année de l'édition, l'identifiant du catalogue et la zone, et l'en-tête enregistre le SHA-256 de chaque fichier source. --attack-log <scenario.json> lit à la place la vérité d'événements d'un dossier du jeu de données JammerTest 2024 (son attack_log, horodatages décalés de --time-shift-h, par défaut -2 : ils disent Z mais sont en heure locale).

Notation#

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

session.toml est un scénario de confiance du récepteur ([log] format/path, [monitors] et [compare] facultatifs). Ses propres [[events]] sont remplacés par le calendrier importé. Par essai planifié :

champ signification
outcome detected (une alarme dans les compare.detect_tol_s, par défaut 10 s, du début planifié), late (plus tard, à l'intérieur du créneau), missed (aucune), not-evaluable
latency_s première alarme moins début planifié
time_to_recover_s de la fin du créneau au début de la première période d'au moins --recover-hold-s (10 s) sans alarme, avant l'essai suivant

Un essai n'est notable que s'il commence au moins calibration_s + guard_s après le début du journal ; un journal comportant un essai plus précoce est marqué baseline_contaminated (la référence de base peut avoir été formée sous interférence). Les fausses alarmes sont des époques en alarme après calibration, en dehors de chaque créneau étendu de --guard-s (60 s) avant et après (ou après le point de récupération), comptées en époques et en exécutions, avec des exécutions par heure de temps sans brouillage. Avec --key et --out, l'exécution est écrite sous forme de paquet de preuves signé (docs/EVIDENCE-PACKS.md) : la fiche de notation et le calendrier importé se trouvent dans config.json, donc à l'intérieur de la chaîne de hachage et de la signature. Un paquet est un enregistrement technique, et non un avis juridique.

Ce qu'un résultat ne dit pas#

  • Un créneau planifié n'est pas un enregistrement d'émission. Un émetteur peut avoir démarré tard, s'être arrêté tôt ou n'avoir jamais fonctionné ; un essai « manqué » peut être un essai qui n'a pas émis, et une latence se mesure depuis le début planifié.
  • Une époque « propre » est « en dehors des créneaux planifiés », et non « prouvée exempte d'interférence ».
  • La détection par des moniteurs du domaine de la mesure ne dit rien de la détection d'un leurreur cohérent de faible puissance.
  • Aucune référence indépendante externe n'indique les heures réelles d'émission, donc rien ici n'est VALIDATED.

L'exécution sur le jeu de données 2024 (préenregistrée)#

xval/jammertest-score/PREREGISTRATION.md a fixé la population, les définitions et les seuils avant la première exécution notée ; xval/jammertest-score/RESULTS.md consigne cette exécution. Résultat : la règle enregistrée de minimum de données a échoué (4 fenêtres de brouillage notables provenant de 4 des 12 dossiers .ubx : 5 dossiers ont été écartés par la règle de référence de base et 3 journaux UBX n'indiquent leur début qu'en temps GPS de la semaine), de sorte qu'aucun seuil n'est évaluable. Rien n'a été assoupli ni ré-exécuté. La v2 (PREREGISTRATION-v2.md, validée seule avant son exécution ; traitement des données uniquement, mêmes seuils et même règle de minimum de données) a placé les journaux en temps GPS seul à partir de la date du dossier, noté les 12 dossiers CSV seul et utilisé une session de plateforme mobile pour les mobiles en déplacement. Résultat (RESULTS-v2.md) : 14 dossiers sur 24 conservés mais seulement 7 fenêtres de brouillage notables, de sorte que la règle de minimum de données a de nouveau échoué et qu'aucun seuil n'est évaluable. Le résultat de la v1 est inchangé. À titre descriptif seulement : 3 fenêtres de brouillage sur 7 ont déclenché une alarme dans les 10 s, 4 plus tard, aucune manquée ; latence médiane 18 s ; taux d'alarme en l'absence de brouillage 0,089. La limite contraignante est désormais la règle de référence de base, qui supprime 10 dossiers ; un nouvel enregistrement exigerait une règle différente pour les fenêtres précoces. Le jeu de données (JammerTest 2024, Zenodo 15911589, GPL-3.0-or-later) est récupéré par xval/oracles/setup.sh et jamais intégré au dépôt ; le test tests/jammertest_score_2024.rs fige l'exécution enregistrée lorsque KSHANA_JAMMERTEST_DIR pointe vers le jeu de données extrait.

Le jeu de données NMEA SimulaMet 2025#

Le jeu de données SimulaMet Jammertest 2025 dérivé de NMEA (IEEE DataPort, DOI 10.21227/a7v4-xw11) n'est pas adapté dans 0,38. Sa page n'indique aucune licence et dit « This dataset requires an IEEE DataPort Subscription to access » : les conditions n'autorisent pas clairement la redistribution ni une récupération automatisée, aucun adaptateur ni script de récupération n'a donc été écrit. Son usage exige la décision du propriétaire et, idéalement, l'accord écrit des auteurs.

Surfaces#

CLI, Rust (kshana::jammertest), Python (jammertest_import, jammertest_score), WebAssembly (les mêmes noms), outils MCP aux mêmes noms, et la commande /kshana-jammertest et la compétence jammertest. Le paquet signé n'existe qu'en ligne de commande (il a besoin d'une clé de signature). Voir docs/SURFACES.md.