Un seul moteur. Toutes les portes d'entrée.

Exécute un scénario Kshana de résilience PNT à partir d'une définition TOML et renvoie ses chiffres de mérite. Renvoie le résumé lisible par l'humain suivi du JSON de résultat complet (FoM, courbes). Kshana valide SGP4/SDP4, les référentiels IAU, les déviations d'Allan, la disponibilité GNSS/DOP, les niveaux de protection ARAIM, la fusion GNSS/INS et les modèles de capteurs quantiques par rapport à des références publiées. Chaque type passe par cet unique outil, y compris spectrum (spectre radiofréquence et cascade), solar-system, constellation-design et body-pnt (constellations autour de n'importe quel corps), campaign (phases enchaînées, balayages de paramètres, ensembles Monte Carlo et scénarios composés) et les types de navigation en orbite terrestre basse leo-signal, leo-pass, leo-navmsg, leo-pvt, leo-ppp, ntn-positioning et leo-pnt-chain. Le contenu est en ligne : un champ de scénario qui nomme un fichier est refusé, et un scénario fait au plus 4 MiB. Appelez d'abord list_scenario_kinds pour découvrir les types de scénario et leurs champs, et list_example_scenarios / get_example_scenario pour obtenir un scénario complet et exécutable d'un type donné.

Liste chaque type de scénario Kshana intégré avec sa description et ses champs TOML obligatoires/facultatifs, sous forme de tableau JSON. Utilisez-la pour découvrir quels scénarios peuvent être exécutés et comment construire un TOML de scénario valide pour run_scenario.

Contrôle préalable d'un TOML de scénario Kshana : vérifie qu'il s'analyse comme du TOML et détecte son type de scénario, sans l'exécuter. Renvoie le type détecté, ou une erreur descriptive pour un TOML mal formé. (run_scenario effectue la validation complète en exécutant le scénario.)

Évalue la confiance accordée à un journal réel de récepteur GNSS : lit un journal u-blox UBX, RINEX 3 (éventuellement avec la navigation diffusée, qui ajoute la position propre du moteur, le RAIM et un moniteur assisté par l'horloge), Android GnssLogger ou NMEA, exécute les moniteurs de confiance (baisse du rapport porteuse sur densité de bruit, AGC, indicateur de brouillage, perte d'accrochage, saut de position, RAIM, horloge) par rapport à une référence de base d'étalonnage, et indique quand et pourquoi le récepteur a cessé d'être digne de confiance. Des [[events]] facultatifs avec des débuts et des baisses prévues de C/N0 sont notés par rapport aux tolérances énoncées dans le scénario : détecté, tardif ou manqué, et concordant ou non. Renvoie le résumé et le JSON de résultat complet (graphique et CSV sur demande ; le CSV d'une exécution de navire commence par une ligne de commentaire # portant la déclaration à titre consultatif, que les lecteurs de CSV ignorent avec leur option de commentaire). Les octets du journal sont placés en ligne dans le TOML sous text ou base64 (en ligne uniquement, au plus 4 MiB). Une table [platform] kind = "vessel" sélectionne les moniteurs maritimes (cohérence cinématique, cap par rapport à la route, loch, hauteur d'antenne, dispersion du C/N0, cohérence temporelle) et ajoute un score de confiance de 0 à 100 par époque avec les moniteurs qui ont déduit des points. Chaque époque porte aussi sa geometry satellitaire (good ; degraded pour peu de satellites ou un PDOP ou HDOP élevé ; ou unknown lorsque le journal n'a ni élévations de satellites ni DOP) ; chaque époque a un label (good, fair, poor) ; pour un navire, un moniteur geometry entre dans le score, ne déduisant que lorsque la géométrie est poor (au plus 15 points : degraded, jamais untrusted), et chaque déduction porte une classe : geometry (le ciel), environment ou inconsistency (semblable à une attaque). Pour un extrait de flux avec la porte, utilisez assess_vessel_stream. À titre consultatif seulement ; niveau de preuve MODELLED.

Liste les scénarios de référence fournis en JSON : count, et scenarios, un tableau de name, kind et about (la première phrase du commentaire d'en-tête du fichier lui-même). Chacun est un scénario complet qui s'exécute tel quel ; c'est donc le chemin le plus rapide vers un TOML valide pour un type : choisissez un nom, récupérez-le avec get_example_scenario, modifiez-le, exécutez-le. Passez kind pour ne lister que les exemples d'un type (par exemple spectrum, solar-system, constellation-design, campaign, leo-signal, leo-pass, leo-navmsg, leo-pvt).

Renvoie le texte TOML d'un scénario de référence fourni, octet pour octet le fichier que le dépôt livre sous scenarios/. Passez le texte (modifié ou non) à run_scenario, report_scenario, animate_scenario ou à un outil d'export. Les noms proviennent de list_example_scenarios. Un scénario qui existe dans le dépôt mais n'est pas fourni est refusé, avec la raison.

Exécute un scénario Kshana et renvoie son rapport : un résumé exécutif, les entrées, chaque chiffre de résultat avec son unité et son étiquette VALIDATED ou MODELLED, les événements, les lignes de capacités sollicitées par l'exécution, et un enregistrement de reproductibilité (version du moteur, empreintes SHA-256 du scénario et du résultat, graine, commande qui le reproduit). format vaut json (par défaut ; le report.json lisible par machine) ou html (le report.html imprimable et autonome avec le graphique intégré). Le rapport d'une campagne porte aussi son tableau de balayage ou sa distribution Monte Carlo. Le rapport est une fonction pure du scénario : aucune horloge n'est lue.

Exécute un scénario Kshana et renvoie sa série temporelle sous forme d'animation. format vaut svg (par défaut : un SVG animé, sans script), html (une page de lecteur autonome) ou frames (des images SVG statiques numérotées plus manifest.json, au plus 120 images dans une réponse). Facultatifs : fps (1 à 60, 12 par défaut), duration_s (0,5 à 600, 8 par défaut) et width (480 à 3840 pixels, 960 par défaut). Le premier élément de contenu est un résumé JSON de ce qui a été dessiné : la plage de temps et l'unité, les titres des graphiques, le nombre de phases et d'événements, la présence ou non d'une cascade de spectre, les chemins de résultat d'où les tracés ont été lus, toute série omise, et les noms de fichiers. Les fichiers suivent, un élément de contenu chacun, dans l'ordre qu'énumère files du résumé. Un type dont le résultat n'a pas d'axe temporel échantillonné est refusé avec un message qui le dit. L'animation est une présentation MODELLED des chiffres propres à l'exécution ; le même scénario et les mêmes options donnent des fichiers identiques à l'octet près.

Indique quels formats d'export d'interopérabilité s'appliquent à un scénario Kshana, sans l'exécuter : un tableau JSON avec une entrée par format (czml, kml, geojson, stk, sigmf) donnant applies, la reason lorsqu'il ne s'applique pas, et spec_url, la spécification publiée que suit l'écrivain. CZML (Cesium Language), KML (Keyhole Markup Language), GeoJSON et l'éphéméride STK (Systems Tool Kit) .e décrivent la géométrie du scénario ; SigMF (Signal Metadata Format) consigne les échantillons que synthétise un scénario spectrum avec un bloc [iq]. Appelez-la avant export_interop.

Exporte un scénario Kshana dans un format d'interopérabilité : czml (Cesium Language, pour CesiumJS), kml (Keyhole Markup Language, pour Google Earth et les outils de système d'information géographique), geojson (RFC 7946), stk (éphéméride Systems Tool Kit .e, un fichier par satellite) ou sigmf (enregistrement Signal Metadata Format des échantillons synthétisés d'un scénario spectrum). Le premier élément de contenu est un index JSON : format, spec_url et files, chacun avec son suffix (ce que la ligne de commande ajoute au nom de sortie, par exemple .czml ou .G01.e), bytes, sha256 et encoding. Les fichiers suivent, un élément de contenu chacun, dans l'ordre de l'index : les fichiers utf-8 sous forme de texte, le fichier binaire d'échantillons SigMF en base64. Une campagne exporte chaque scénario membre auquel le format s'applique. Un format qui ne s'applique pas est refusé avec la raison ; list_export_formats les indique tous les cinq à la fois. Les heures sont en temps universel coordonné (UTC) ; le même scénario donne des fichiers identiques à l'octet près.

Écrit un itinéraire GeoJSON dans un scénario Kshana qui parcourt une trace de points de passage, et renvoie le nouveau TOML du scénario (à exécuter avec run_scenario). L'itinéraire est une LineString (ou une Feature / FeatureCollection en contenant une) de positions longitude, latitude ; il remplace start_lat_deg, start_lon_deg, step_lat_deg, step_lon_deg et waypoints du scénario. Les types qui acceptent un itinéraire sont terrain-nav, terrain-slam, gravity-map et combined-altpnt ; tout autre type est refusé, avec la raison. Donnez les deux extrémités de la trace, ou des positions régulièrement espacées le long d'une ligne droite : les types à trace parcourent start + i*step, de sorte que toute autre forme est refusée.

Exporte la constellation propagée d'un scénario orbit sous forme de texte d'éphéméride précise SP3-c (le format standard de post-traitement GNSS). Erreur si le scénario n'est pas du type orbit.

Exporte les éléments moyens d'un scénario orbit sous forme de catalogue CCSDS 502.0-B-2 OMM (Orbit Mean-Elements Message) : un OMM par satellite. Erreur si le scénario n'est pas du type orbit.

Exporte la constellation propagée d'un scénario orbit sous forme de texte d'éphéméride CCSDS OEM 2,0 : la série temporelle d'états inertiels (TEME) portant la position ET la vitesse, que lisent les outils de dynamique du vol (GMAT / Orekit / STK). C'est le complément, porteur de la vitesse, de export_sp3 qui ne porte que la position. Erreur si le scénario n'est pas du type orbit.

Exécute un scénario Kshana et renvoie son tableau de reproductibilité sous forme de texte CSV : le tableau stable à l'octet près que la CLI écrit sous <scenario>.table.csv et que citent les articles. Seuls ces types en produisent un : realtime-frame-eop, lunar-time-budget, lunar-jamming, telecom-timing, leo-navmsg lorsque son analyse encode-decode s'exécute sur un modèle de message kepler16 ou kepler-rac (le tableau d'éphéméride diffusée), et moonlight-service-volume lorsque export_site_lat_deg et export_site_lon_deg sont tous deux définis. Erreur pour tout autre type (ou un scénario invalide) ; utilisez run_scenario pour les chiffres de mérite.

Géométrie du ciel sous une ligne d'horizon dépendant de l'azimut (un canyon urbain, un port, un fjord, un terminal à conteneurs) : à partir d'un site, d'une heure et de préréglages de constellation, d'éléments à deux lignes (tle, avec une epoch UTC) ou de satellites donnés en azimut/élévation ou en ECEF, quels satellites sont visibles et lesquels sont masqués par l'horizon, GDOP/PDOP/HDOP/VDOP/TDOP à partir du noyau DOP vérifié avec gnss_lib_py, le cofacteur et la covariance est-nord-haut avec une horloge de récepteur par système (ou une seule en commun), et l'ellipse d'erreur horizontale à un sigma et à un niveau de confiance déclaré pour une UERE déclarée. Sans request, décrit un préréglage d'horizon REPRESENTATIVE avec sa provenance et sa coupe tous les degrés (un skyline_preset vide les énumère). Les scénarios des types orbit et integrity (avec user_site), gnss-sim, jamming, leo-pvt et leo-pass acceptent la même section [skyline] via run_scenario. Niveau de preuve MODELLED : géométrie sous un modèle d'erreur déclaré, en visibilité directe seulement ; ce n'est pas une prédiction de l'erreur réelle d'un récepteur ni une borne d'intégrité ; les constellations prédéfinies sont un ciel représentatif, non le ciel d'une date ; un texte tle avec une epoch (UTC) donne le ciel que ces éléments donnent à cette époque (SGP4), et non une mesure, et sky_source indique lequel des deux. Porte la mention à titre consultatif : pas un équipement de navigation homologué. Pas de Monte Carlo via MCP (échantillons en masse ; utilisez la CLI, Python ou WASM). En ligne uniquement, au plus 4 MiB.

La configuration de la couche IQ GNSS, en JSON : signals (les noms de signaux qu'acceptent iq_scene, iq_acquire et iq_track), enabled (si les outils de fichiers IQ sont activés), work_dir (le seul dossier qu'ils lisent et dans lequel ils écrivent ; chaque chemin passé en argument est relatif à celui-ci), max_samples (le plus grand nombre d'échantillons complexes qu'un appel peut générer ou traiter) et, lorsqu'ils sont désactivés, reason. Les échantillons IQ ne transitent jamais par le protocole : les outils prennent des chemins de fichiers du répertoire de travail et répondent par des résumés JSON compacts. La couche IQ n'ajoute aucune synthèse d'interférence ni de leurre ; rien n'est jamais émis. À appeler en premier.

Décrit un enregistrement IQ du répertoire de travail sans le traiter : nature (brut avec fichier annexe, SigMF, collection SigMF), format d'échantillon, fréquence d'échantillonnage, fréquence centrale, nombre total d'échantillons, durée, fichiers de données et leur taille, limites de capture et nombre d'annotations, en JSON (la même ligne qu'affiche kshana iq info). raw, facultatif, décrit un fichier brut sans fichier annexe ; hash, facultatif, ajoute le SHA-256 de chaque fichier de données (lit le fichier entier).

Génère une scène IQ GNSS multi-satellites dans un fichier du répertoire de travail (kshana iq scene). Mode à profil déclaré : signal + prns (+ dopplers_hz, cn0_dbhz, data facultatifs). Mode diffusion : nav (un fichier de navigation RINEX du répertoire de travail) + rx_pos [lat, lon, alt] place chaque satellite GPS en bon état selon sa géométrie de diffusion réelle. channel, facultatif, applique au niveau du signal l'ionosphère, la troposphère, la scintillation, les trajets multiples, l'ombrage en mobile terrestre ou le NLOS. rate_hz × duration_s doit tenir dans le budget d'échantillons (voir iq_signals). Écrit l'enregistrement (brut + fichier annexe <out>.json, ou une paire SigMF) et un fichier annexe de vérité ; répond avec les fichiers écrits et leur nombre d'octets, le nombre d'échantillons et l'échantillonnage, et la première époque de la vérité par satellite (phase de code, Doppler, C/N0) pour y confronter iq_acquire. La couche IQ n'ajoute aucune synthèse d'interférence ni de leurre ; rien n'est jamais émis.

Acquisition par FFT d'un ou plusieurs PRN sur un enregistrement IQ du répertoire de travail (kshana iq acquire). Ne lit que les échantillons qu'une recherche nécessite (périodes de code cohérentes × non cohérentes), qui doivent tenir dans le budget d'échantillons. Les étapes frontend facultatives (passe-bande, réjecteur, suppression, excision, AGC, quantificateur) s'exécutent en premier. Répond avec une détection par PRN : acquired, doppler_hz, code_phase_chips, la statistic du pic normalisé, son threshold de détection et le peak_ratio ; json_out / csv_out conservent aussi le résultat complet sous forme de fichiers, et surface_out (un PRN ; .csv, .json ou .bin) conserve toute la surface de puissance de corrélation Doppler × phase de code avec le pic et ses affinements Doppler parabolique et de recherche fine.

Acquiert puis poursuit un ou plusieurs PRN sur un enregistrement IQ du répertoire de travail (kshana iq track) : l'acquisition initialise chaque canal, puis le banc de boucles DLL/PLL (éventuellement assisté par FLL) rejoue l'enregistrement une fois. Les échantillons poursuivis (l'enregistrement entier, ou ses premières max_seconds) doivent tenir dans le budget d'échantillons. Les boucles proviennent de design (un fichier TOML kshana.loop-design/1 du répertoire de travail, design_name pour en choisir une) ou de la conception intégrée, les arguments de boucle la remplaçant ; reacquire réacquiert un canal qui perd l'accrochage ou s'accroche à tort. La poursuite se fait au fil de l'eau, de sorte que la mémoire ne croît pas avec l'enregistrement. Répond avec le nom et l'empreinte de la conception, tout élément de warnings (commensurate_sampling : une fréquence d'échantillonnage multiple de la moitié du débit de puce rend la gigue et le biais de la boucle de code non représentatifs) et, par canal, le nombre d'époques, les secondes poursuivies, le Doppler et la phase de code finaux, le C/N0 final et moyen (dB-Hz), les fractions d'époques en accrochage de phase et de code, locked_at_end, l'état d'accrochage final, les faux accrochages détectés et les réacquisitions. La sortie par époque va uniquement dans des fichiers : epochs_out (E/P/L, discriminateurs, états de boucle, C/N0, état d'accrochage ; .csv/.jsonl/.bin), events_out, json_out / csv_out. Un PRN non acquis est refusé, avec sa statistique et son seuil.

Applique le traitement du signal de frontal de récepteur et d'atténuation des interférences à un enregistrement IQ du répertoire de travail et écrit le résultat comme un nouvel enregistrement brut avec un fichier annexe <out>.json (kshana iq frontend). stages choisit parmi : un FIR passe-bande bandpass_hz [lo, hi], un notch adaptatif, une suppression d'impulsions blank, une excise dans le domaine fréquentiel, agc, et un quantificateur sur bits bits (précédé d'un AGC automatique sauf no_agc), toujours dans cet ordre. L'entrée entière doit tenir dans le budget d'échantillons. Répond avec les échantillons traités et les fichiers écrits avec leur nombre d'octets. Cela traite un enregistrement ; rien n'est synthétisé.

Exécute une campagne de rejeu en laboratoire conservée dans le répertoire de travail (kshana iq campaign) : enregistrements (chacun décrit par un fichier kshana.test-conditions/1 énonçant la vérité connue du laboratoire) x chaînes de frontal x conceptions de boucle, chaque cellule étant suivie et notée par rapport aux conditions déclarées (temps jusqu'à la perte d'accrochage, temps de réacquisition, dégradation du C/N0 par rapport au J/S déclaré à côté d'une référence analytique étiquetée MODELLED, taux de faux accrochage, gigue PLL/DLL, disponibilité). Incrémentale : un appel exécute les cellules en attente qui tiennent dans le budget d'échantillons (ou max_cells), chaque cellule terminée est conservée et l'appel suivant reprend. Répond avec le nombre de cellules, les échecs, les fichiers écrits et le digest une fois toutes les cellules terminées. Ne note que des données enregistrées ; ne synthétise aucune interférence.

Indique l'avancement d'une campagne de rejeu en laboratoire à partir de son dossier de sortie dans le répertoire de travail, en lecture seule : cellules terminées et en attente, enregistrements, frontaux et conceptions du plan, et le digest une fois toutes les cellules terminées.

Rejoue un enregistrement IQ du répertoire de travail sur plusieurs conceptions de boucle de poursuite et indique le résultat en régime établi de chacune (kshana iq sweep) : les conceptions sont toutes celles d'un fichier kshana.loop-design/1 (design), ou le produit des listes pll_bws_hz, dll_bws_hz, spacings_chips et coherents sur la conception intégrée. Chaque PRN est acquis une fois et chaque canal (conception, PRN) poursuit les mêmes échantillons, de sorte que chaque résultat est exactement celui de la conception exécutée seule. Répond avec, par conception et par PRN, epochs, phase_jitter_deg et code_jitter_chips (sur la seconde moitié de l'exécution), phase_lock_frac, code_lock_frac, mean_cn0_dbhz et l'empreinte de la conception ; json_out / csv_out conservent le tableau sous forme de fichiers. L'intervalle poursuivi doit tenir dans le budget d'échantillons (max_seconds le réduit) et au plus 256 canaux (conception, PRN) s'exécutent par appel. Cela traite un enregistrement ; rien n'est synthétisé.

Exécute les moniteurs de détection d'interférence et de leurrage sur un enregistrement IQ du répertoire de travail (kshana iq monitor) : les moniteurs à large bande power et spectral et, avec signal + prns, les moniteurs de C/N0 et de qualité du signal par satellite, chacun par rapport à une référence de base apprise sur les premières baseline_s secondes (ou à partir d'un fichier de réglages). Répond avec les séries (nom et longueur), chaque événement levé par les moniteurs (début, fin, moniteur, ce qui a changé ; au plus 200 dans la réponse), ainsi que les réglages et références de base appris par les moniteurs ; json_out conserve le rapport complet (chaque série, événement et spectre) et csv_prefix écrit <prefix>.series.csv et <prefix>.events.csv. L'intervalle doit tenir dans le budget d'échantillons (max_seconds le réduit). Un événement de moniteur indique qu'une grandeur mesurée a quitté sa référence de base apprise ; il n'identifie ni une cause ni une source. Cela ne note que des données enregistrées ; rien n'est synthétisé. Niveau de preuve : MODELLED.

Valide un fichier de conditions d'essai de laboratoire (kshana iq conditions) : un fichier kshana.test-conditions/1, en texte TOML ou JSON, énonçant la vérité connue du laboratoire pour un enregistrement (les satellites attendus, le temps de stabilisation, le calendrier déclaré de brouillage ou d'interférence). Répond avec les conditions résolues et leur hash, ou la raison pour laquelle le fichier est invalide. En ligne uniquement : rien n'est lu sur le disque, et un chemin d'enregistrement que nomme le fichier n'est pas ouvert (une campagne les résout à l'intérieur du répertoire de travail). L'entrée est plafonnée à 4 MiB.

Ajuste le modèle de perte d'accrochage de la boucle de poursuite à des essais de laboratoire (kshana iq labfit) : un TOML de scénario iq-labfit nomme un ou plusieurs essais, chacun étant un journal de récepteur avec ses conditions d'essai déclarées ; le moteur charge chaque journal, ajuste les modèles de boucle et empirique, estime l'incertitude par bootstrap et calcule l'erreur sur le jeu réservé. Tout est en ligne : le log de chaque essai donne text ou base64 (un path est refusé) et l'outil ne lit ni n'écrit aucun fichier, de sorte qu'il n'a pas besoin du répertoire de travail IQ. Sinon, le [input] du scénario nomme campaign = "<out-dir>", un dossier de sortie kshana iq campaign terminé : l'outil ajuste alors les modèles de C/N0 et d'accrochage à ses cellules notées (un rapport kshana.labfit-iq/1 ; Q est déclaré, jamais ajusté, et le décalage J/S identifiable est ajusté ; avec mode = "validation", une table [validation] est requise). Ce dossier est résolu par rapport au répertoire de travail IQ et doit s'y trouver (tout ce qui est en dehors est refusé) ; il est lu, rien n'y est écrit. Répond avec le report analysé, les résidus et prédictions en texte CSV et un résumé Markdown. L'entrée est plafonnée à 4 MiB. L'ajustement décrit les essais de laboratoire fournis ; ce n'est pas une prédiction pour d'autres récepteurs ou conditions au-delà de ce que le rapport énonce. Niveau de preuve : MODELLED.

Calcule le score d'un extrait borné d'un flux NMEA 0183 de navire comme le fait kshana receiver-trust live, et renvoie l'état de confiance par époque (calibrating, nominal, degraded, untrusted) et le score de 0 à 100 avec les moniteurs qui ont déduit des points (schéma JSON-lines live 1,3 : chaque époque porte position, une déclaration advisory indiquant que la sortie est à titre consultatif, et sa geometry satellitaire (good, degraded avec des raisons telles que few-satellites ou high-pdop, ou unknown lorsque l'extrait n'a ni GSV ni GSA) avec un label (good, fair, poor ; la géométrie ne déduit que lorsqu'elle est poor) ; chaque déduction porte une class : geometry (le ciel, et non la constatation qu'aucune attaque n'a eu lieu), environment ou inconsistency (semblable à une attaque)), le résumé (décomptes par état, géométrie et classe, score le plus bas et final, moment où la première époque untrusted est survenue) et la dernière phrase $PKSHT. session_toml déclare le navire ([platform] kind = "vessel", ses limites de vitesse, d'accélération et de vitesse de giration, la hauteur d'antenne, la présence ou non d'un capteur de cap sur le bus). L'extrait doit contenir la fenêtre d'étalonnage ; l'entrée est plafonnée à 2 MiB et 20 000 époques, et la réponse porte au plus 200 lignes d'époques degraded ou untrusted. C'est la forme bornée de la commande live : aucun socket n'est ouvert et rien n'est écrit sur un port, et la passerelle et les exportateurs de télémétrie (le processus de longue durée et son serveur --listen) relèvent uniquement de la ligne de commande. Les contrôles ne peuvent pas voir un leurre dont la position est cohérente avec tout ce qui circule sur le bus. À titre consultatif seulement : pas un équipement de navigation homologué ; l'opérateur reste responsable. Niveau de preuve : MODELLED.

Lit le catalogue d'essais et le plan de transmission publiés de Jammertest (NPRA/jammertest-plan, MIT) comme vérité planifiée (kshana jammertest import) : les créneaux d'une zone d'essai deviennent des événements receiver-trust, avec l'identifiant du catalogue et l'année dans chaque libellé. plans contient un fichier de plan par jour, log_start_utc est la première époque du journal, local_offset_h le décalage du plan par rapport à l'UTC (par défaut 2, CEST). Renvoie events_toml (à ajouter à une session receiver-trust), events (identifiant d'essai, type, début et fin en secondes depuis le début du journal) et les nombres d'éléments ignorés. Les événements sont des créneaux PLANIFIÉS, et non des heures d'émission enregistrées : un créneau peut démarrer tard ou ne jamais s'exécuter, et le champ status du plan est le plus souvent vide. Aucun champ de contact ou personnel du plan n'est lu. L'entrée est plafonnée à 4 MiB par texte. Niveau de preuve : MODELLED.

Note un journal de récepteur par rapport au calendrier Jammertest (kshana jammertest score) : pour chaque essai planifié, la latence de détection (première alarme moins début prévu), s'il a été détecté dans la tolérance, tardivement ou manqué, et le temps de rétablissement (une période sans alarme de recover_hold_s), ainsi que les fausses alarmes hors de tout créneau et de sa marge de garde. session_toml n'a besoin que de [log] format = "ubx" (ou rinex, android, nmea, sbf) ; donnez le journal sous la forme log (formats texte) ou log_base64 (binaire). Nécessite le JSON du catalogue et du plan (catalog_json, plans) et la zone d'essai (location). Renvoie la fiche de résultats : tests, summary, baseline_contaminated et une étiquette MODELLED. Le calendrier se compose de créneaux planifiés, et non d'heures d'émission enregistrées, de sorte qu'un essai manqué peut être un essai qui ne s'est jamais exécuté. Un paquet de preuves signé nécessite une clé de signature : utilisez la ligne de commande (kshana jammertest score --key). L'entrée est plafonnée à 4 MiB par texte. À titre consultatif seulement : pas un équipement de navigation homologué ; l'opérateur reste responsable. Niveau de preuve : MODELLED.

Évalue un journal NMEA 0183 de navire comme une exécution par lot (kshana receiver-trust avec [platform] kind = "vessel") : le modèle de score, les moniteurs exécutés et le score de 0 à 100 de chaque époque avec ses déductions, sa géométrie satellitaire (bonne, dégradée, inconnue) avec un label (good, fair, poor) sur chaque époque, la géométrie ne déduisant que lorsqu'elle est mauvaise, et une classe sur chaque déduction (géométrie, environnement, incohérence), avec geometry_model (seuils, plafond et plancher en vigueur, et provenance) et geometry_summary. session_toml énonce les limites du navire et les réglages éventuels de moniteur ou de score (aucune table [log] n'est nécessaire) et nmea est le texte du journal, ce qui évite de le coller dans une chaîne TOML. L'entrée est plafonnée à 4 MiB ; la réponse porte le document avec epochs réduit à des décomptes par état et à au plus 200 époques degraded ou untrusted. Pour un journal dans un autre format, ou avec des [[events]] à noter, utilisez assess_receiver_log. À titre consultatif seulement : pas un équipement de navigation homologué ; l'opérateur reste responsable. Niveau de preuve : MODELLED.

Génère du NMEA 0183 synthétique de passerelle pour la formation des équipages à partir d'un TOML nmea-scenario (kshana nmea-scenario) : une trace de navire et une chronologie d'événements scriptés (brouillage, dérive de la position, leurrage temporel, retard de rejeu, avec rétablissement). Renvoie l'ensemble de phrases à somme de contrôle valide (GGA, RMC, VTG, GSV, GSA, GNS, ZDA, HDT, VBW ; les 2000 premières lignes) et le journal de l'instructeur (ce qui a été injecté et quand, avec la vraie trace et un summary de premier niveau des vitesses et accélérations de crête ; les événements de dérive portent leur vitesse et leur accélération de dérive de crête ; schéma kshana-nmea-training/1) en JSON et en texte. Le plafond de satellites visibles du récepteur est receiver.max_used (par défaut 12). Déterministe selon seed. TEXTE UNIQUEMENT : rien ici ne synthétise de RF, d'IQ ni aucune forme d'onde, rien n'est émis, et la sortie sert à la formation et à l'essai, jamais aux systèmes de navigation en service d'un navire (une phrase repère dans le flux le dit). À titre consultatif, pas un équipement de navigation homologué. La diffusion vers une adresse TCP ou UDP relève uniquement de la ligne de commande. Quatre scénarios d'exemple sont livrés dans scenarios/training/.

Crée un paquet de preuves signé pour une fenêtre d'un journal NMEA 0183 de navire (kshana receiver-trust evidence) : les octets bruts du journal pour la fenêtre, la configuration avec chaque seuil, les résultats et motifs par époque, une page de synthèse autonome, et un manifeste listant le SHA-256 de chaque fichier avec l'empreinte du journal complet et une chaîne d'empreintes, signé avec Ed25519. from_s/to_s sont des secondes depuis la première époque du journal. Renvoie les fichiers en JSON (à fournir à verify_evidence_pack), la clé publique du signataire et son empreinte. La graine de signature n'est jamais renvoyée ni journalisée ; si signing_key_seed_hex est omis, une clé à usage unique est utilisée puis détruite, de sorte que le paquet prouve l'intégrité par rapport à la clé qu'il nomme lui-même, et non l'identité du signataire : pour une clé qui compte, créez le paquet en ligne de commande (une graine passée ici transite par la conversation). L'entrée est plafonnée à 4 MiB et la réponse à 4 MiB (réduisez la fenêtre). Un paquet est un enregistrement technique de ce que le moteur a calculé à partir d'un journal sous des réglages déclarés ; ce n'est ni un avis juridique, ni une constatation de fait sur un événement, ni une certification. Niveau de preuve : MODELLED.

Crée le paquet aller-retour de laboratoire signé (kshana evidence round-trip, docs/spec/TEST-CONDITIONS.md) : relie par empreinte le scénario qui a produit le mouvement, le document kshana.test-conditions/1 du laboratoire, le journal du récepteur et son score par rapport aux événements déclarés, dans un paquet de preuves signé dont config.json porte un bloc round_trip. Refuse un paquet dont les conditions et les événements de notation sont en désaccord, ou dont le SHA-256 déclaré du journal n'est pas celui du journal. AUCUN SIGNAL : rien n'est écrit, rejoué ni planifié ; la manière dont le mouvement d'un scénario est parvenu au récepteur relève de la responsabilité de l'opérateur et n'est consignée que telle qu'elle est déclarée. La graine de signature n'est jamais renvoyée ni journalisée ; si elle est omise, une clé à usage unique est utilisée puis détruite (intégrité, non identité). L'entrée est plafonnée à 4 MiB et la réponse à 4 MiB. Un enregistrement technique, et non un avis juridique ni une certification. Niveau de preuve : MODELLED.

Vérifie un paquet de preuves signé (kshana evidence verify) : le SHA-256 de chaque fichier par rapport au manifeste, la chaîne d'empreintes, la signature Ed25519, et, avec public_key (la clé du signataire, obtenue du signataire par une autre voie), que le signataire est bien celui attendu, et, avec full_log, que le journal que vous détenez est celui que consigne le paquet et que l'extrait en provient. Renvoie le rapport : ok, chaque échec par code et par fichier, chaque contrôle, signer_pinned, des notes, et un verdict : verified (signataire épinglé), intact-signer-not-pinned (tout se vérifie mais aucune public_key de confiance n'a été fournie, de sorte que la signature prouve seulement que le paquet est intact par rapport à la clé qu'il nomme lui-même, que n'importe qui peut générer ; dites-le, ne le qualifiez pas de vérifié) ou failed, avec un message à montrer à l'utilisateur. require_timestamp fait échouer un paquet qui ne porte aucun jeton d'horodatage. Les entrées sont plafonnées à 4 MiB. Un succès vérifié indique que l'enregistrement est inchangé et qui l'a signé (la clé que vous avez fournie) ; il n'indique pas ce qui a causé un événement, qui en est responsable, ni que le journal montre ce que le récepteur a réellement reçu.

Construit une carte d'interférence GNSS à partir de rapports de position d'aéronefs (ADS-B NIC/NACp) ou de navires (AIS) sous licence ouverte, fournis sous forme de texte CSV (kshana interference-map adsb|ais). Renvoie un document GeoJSON par jour UTC (schéma kshana-interference-map/v1) (noms de fichiers <source>-<dataset>-<date>.geojson ; version de méthode 2) dans lequel chaque cellule de grille publiée est degraded, not_degraded, insufficient_sample, withheld_day_confounded ou withheld_no_background (ADS-B) ou anomalous/not_anomalous (AIS), avec la méthode, ses seuils préenregistrés, la licence du jeu de données et l'attribution intégrés. Chaque décompte par cellule inférieur au minimum de publication (5) vaut null (retenu, jamais zéro), et un jour dont le bruit de fond ne peut être estimé retient ses jugements. Agrégat uniquement : les identifiants sont hachés en mémoire et jamais renvoyés, et une cellule comptant moins de 5 aéronefs ou navires distincts n'est pas publiée. dataset est l'un des préréglages admis ou custom (avec licence, licence_url, attribution). L'entrée est plafonnée à 4 MiB et la réponse à 4 MiB (utilisez un cell_deg plus grossier ou la ligne de commande pour davantage). Rien n'est récupéré : les polygones de terre, si on les souhaite pour l'AIS, sont fournis en entrée. Une cellule degraded n'identifie pas l'interférence comme cause ; une cellule non publiée n'est pas la preuve d'une cellule dégagée ; ce n'est pas une prévision. Niveau de preuve : MODELLED.

Résume la part d'un itinéraire qui traverse des cellules dégradées d'une ou plusieurs cartes d'interférence (kshana route-exposure) : pour chaque carte (une par source et par jour UTC, le GeoJSON que renvoie build_interference_map), la longueur de l'itinéraire et les parts de sa longueur dans des cellules dégradées, dans des cellules qui n'étaient pas dégradées, dans des cellules disposant de trop peu d'échantillons pour être évaluées, et dans des cellules non observées. L'itinéraire est un GeoJSON LineString ou un texte CSV lat,lon ; date_from/date_to (AAAA-MM-JJ) conservent les cartes d'une plage de dates. L'entrée est plafonnée à 4 MiB par élément. Les cellules non observées ne sont pas la preuve d'un itinéraire dégagé ; une cellule dégradée n'identifie pas l'interférence comme cause ; cela décrit des rapports passés et ce n'est pas une prévision. Niveau de preuve : MODELLED.

Remplit la correspondance avec les cadres publics à partir de documents de résultats Kshana (kshana compliance-report) : quelles lignes de six cadres et normes de résilience (le cadre US DHS Resilient PNT v2.0, les orientations de l'OMI pour les navires, les orientations de l'EASA pour l'aviation, NIS2 article 21, EN 16803, NIST IR 8323r1) les exécutions fournies apportent des éléments de preuve en faveur de, lesquelles non, et l'écart que conserve chaque ligne. Passez chaque exécution sous la forme label, result (le texte JSON du résultat) et, lorsque vous l'avez, scenario (le TOML du scénario, qui nomme le type qu'un résultat ne nomme pas ; un résultat receiver-trust n'en a pas besoin). Au plus 64 exécutions et 4 MiB au total ; rien n'est lu sur le disque. Le status de chaque ligne est evidenced, partly-evidenced, not-evidenced ou out-of-scope, et chaque ligne conserve son gap même lorsqu'elle est evidenced ; les entrées inutilisables sont listées dans unrecognised et ne comptent pour rien. Montrez le statement du rapport avec tout résultat, tel quel : un statut signifie qu'une exécution apporte des éléments de preuve en faveur des capacités que nomme la ligne ; ce n'est pas la constatation qu'un cadre est satisfait, et cela ne signifie pas qu'un produit a été évalué ou approuvé par qui que ce soit. Ne décrivez pas la sortie en des termes plus forts. Niveau de preuve : MODELLED.

La correspondance statique avec les cadres publics (kshana compliance-report --mapping / --sources) en Markdown : un tableau par cadre avec, pour chaque ligne, l'exigence paraphrasée, les sorties de Kshana qui apportent des éléments de preuve en faveur de celle-ci et l'écart que ces sorties ne comblent pas ; ou, avec sources à true, les documents sources que citent les tableaux, avec leurs versions et leurs URL. Précédée de la déclaration que porte chaque rapport, et qui reste avec tout extrait : une ligne marquée evidenced signifie qu'une exécution apporte des éléments de preuve en faveur des capacités que nomme la ligne ; ce n'est pas la constatation qu'un cadre est satisfait, et cela ne signifie pas qu'un produit a été évalué ou approuvé par qui que ce soit. Ne nécessite aucune exécution.

Ajuste les paramètres de capteur des scénarios hybrid et fusion à partir d'un journal IMU stationnaire (kshana imu-fit, docs/MACHINE-INPUTS.md). Ces scénarios prennent des paramètres de bruit, et non une série temporelle : l'outil les déduit d'un journal enregistré capteur immobile, par la déviation d'Allan chevauchante du signal intégré. Renvoie du JSON : fit (biais de l'accéléromètre, DSP de marche aléatoire de vitesse q_va, biais du gyroscope, DSP de marche aléatoire d'angle q_arw, plancher d'instabilité de biais lorsque le journal est assez long pour en montrer un, cadence et durée du journal, pentes d'Allan initiales, et notes sur ce qui n'a pas pu être ajusté ou jugé fiable), toml (une table [accel_classical] dont la provenance nomme le SHA-256 du journal, prête à coller dans un scénario) et sha256. Un journal non stationnaire, trop court ou échantillonné de façon irrégulière donne des paramètres erronés ou est refusé ; les pentes (environ -0.5 là où le bruit blanc domine) montrent lequel. Rien n'est écrit sur le disque. Niveau de preuve : MODELLED (l'estimateur appliqué au journal, sans référence indépendante externe).

Liste les paquets de normes (kshana standards-pack list) : des ensembles de scénarios notés pour les profils d'essai du cadre DHS Resilient PNT, l'OMI MSC.1/Circ.1575 et l'ICAO Doc 9849 Appendice F, chacun avec les seuils qu'il énonce avant l'exécution et les lignes de compliance en faveur desquelles il apporte des éléments de preuve. Ne nécessite aucune entrée. Un paquet mesure des scénarios modélisés par rapport à des seuils déclarés ; il n'évalue aucun produit. Niveau de preuve : MODELLED.

Exécute un paquet de normes (kshana standards-pack run <id>) : chaque scénario qu'il contient, noté par rapport à des seuils énoncés avant l'exécution. Renvoie le rapport (chaque essai MET, NOT MET, ou NEEDS INPUT lorsqu'il nécessite un journal de récepteur et n'est pas noté ; chaque seuil avec sa valeur mesurée et sa valeur attendue) et la même chose en markdown. Passez le JSON du rapport à compliance_report pour voir les lignes en faveur desquelles le paquet apporte des éléments de preuve. Dites clairement qu'un seuil MET signifie qu'un scénario modélisé a atteint un seuil déclaré, et qu'un NOT MET est un résultat consigné ; ne décrivez jamais la sortie comme montrant qu'un produit ou un cadre est satisfait. À titre consultatif seulement : sortie d'analyse, pas un équipement de navigation homologué. Niveau de preuve : MODELLED.

Vérifie le LunaNet Augmented Forward Signal (AFS) par rapport à la spécification publiée, arrêtée sur LNIS Version 5 Applicable Document 1 Volume A (LSIS-AFS V1.0, 29 janvier 2025) (kshana lunanet-afs-check, docs/LUNANET-AFS.md). Le mode spec vérifie cette implémentation par rapport aux tables de codes imprimées du document (les 24 premières et dernières puces de chaque code AFS-I Gold, AFS-Q Weil et tertiaire pour les PRN 1 à 210, et les deux séquences de Legendre) et aux exemples traités (SB1 BCH, CRC-24Q), seuils B1 à B10 d'un préenregistrement ; B4 signale un échec (le document imprime les mêmes 24 dernières puces pour les PRN tertiaires 147 et 151). Le mode symbols vérifie un flux de symboles à décision dure (texte de 0 et de 1) pour le motif de synchronisation, le décodage SB1, le FID, la continuité du TOI et l'espacement des trames. Les sous-trames 2 à 4 (LDPC de rendement 1/2, CRC-24Q) ne sont PAS vérifiées : les matrices LDPC figurent dans une annexe distincte qui n'est pas implémentée. Le mode generate renvoie un flux d'essai avec des sous-trames de substitution : des symboles, et non une forme d'onde ; Kshana n'écrit aucun signal. VALIDATED uniquement par rapport aux tables imprimées de cette édition, que le document marque lui-même TBC ; dites-le, et ne décrivez pas un résultat comme montrant qu'un nœud ou un service LunaNet est correct. À titre consultatif seulement.

Note une soumission kshana-bench (kshana bench score, bench/SPEC.md, docs/BENCH.md) : un fichier de prédictions (kshana-bench-predictions/1) par rapport à un fichier de vérité (kshana-bench-truth/1), tous deux en texte JSON, d'au plus 4 MiB chacun, et renvoie le fichier de résultats (kshana-bench-result/1) avec la version de la spécification, la tâche (a détection sur journaux de récepteur, b détection sur IQ, c prédiction de holdover de la synchronisation temporelle, d écart d'optimisme hors distribution), la répartition, le SHA-256 des deux entrées et les métriques de la tâche (AUC, probabilité de détection à un plafond de fausses alarmes, RMSE par horizon, ou écart d'optimisme). threshold est le seuil d'alarme déclaré des tâches a et b. Rien n'est lu sur le disque ni écrit. Chaque score est MODELLED et décrit un journal ou un corpus, jamais un produit ; ce n'est pas une certification et aucune organisation n'est cautionnée par un score. Niveau de preuve : MODELLED.

Produit les fichiers de résultats kshana-bench (kshana bench leaderboard) sous forme de page de classement statique, en texte HTML dans la réponse : results est une liste de textes JSON kshana-bench-result/1 (au plus 256, 4 MiB chacun), chacun validé d'abord ; un fichier noté selon une autre version majeure de la spécification est refusé, car les résultats de versions majeures différentes ne sont jamais réunis dans un même tableau. Une ligne indique que ce fichier a obtenu ce score sur cette répartition ; cela ne signifie pas qu'un produit a été évalué ou approuvé par qui que ce soit. Rien n'est écrit. Niveau de preuve : MODELLED.

Produit un flux de confiance GNSS ou un résultat receiver-trust sous forme de texte de télémétrie de sécurité (kshana trust-telemetry, docs/TRUST-TELEMETRY.md), avec les mêmes encodeurs que ceux de la ligne de commande : prometheus (l'exposition de l'état final), cef ou leef (une ligne syslog RFC 5424 par changement de bande, ou par époque avec syslog_all ; sans horodatage, car aucune horloge n'est lue) ou otlp (la charge utile de métriques JSON OTLP/HTTP). input_kind vaut jsonl (par défaut) ou result ; une ligne de flux qui ne s'analyse pas est ignorée et comptée dans kshana_trust_input_errors_total. Rien n'est envoyé, servi ni écrit : la sortie est du texte dans la réponse (les exportateurs en cours d'exécution, qui sont un processus, restent en ligne de commande). La position rapportée par le récepteur est omise sauf si expose_position vaut true. Une entrée qui porte la géométrie satellitaire (schéma live 1,3, résultats à partir de 0,36) ajoute l'étiquette de géométrie (good, fair, poor ; jamais notée sauf pour poor) et l'état, le HDOP, le PDOP, le VDOP et les satellites utilisés, ainsi qu'une étiquette class (géométrie, environnement, incohérence) sur chaque motif ; une entrée plus ancienne est rendue exactement comme avant. À titre consultatif seulement : Kshana n'est pas un équipement de navigation homologué (IEC 61108, IEC 61162) et l'opérateur reste responsable. Niveau de preuve : MODELLED.

Exporte le mouvement du véhicule et les événements d'un scénario pour un simulateur GNSS de laboratoire (kshana bench-export, docs/TEST-BENCH.md) : un CSV de mouvement et sa description JSON (position terrestre fixe et géodésique, vitesse, attitude, UTC), des phrases NMEA 0183 GGA/RMC, un texte de points de passage lorsque la grille d'échantillonnage est régulière à la milliseconde, et les événements du scénario en CSV et en TOML [[events]] pour un scénario receiver-trust. S'applique à gnss-ins (ses interruptions d'état de navigation sont les événements), jamming et gnss-sim ; un autre type est refusé, avec la raison. epoch est l'instant UTC du temps zéro du mouvement, YYYY-MM-DDTHH:MM:SS (par défaut 2024-01-01T00:00:00Z). Rien n'est écrit sur le disque : le premier élément de contenu est un index JSON (files avec suffix, bytes, sha256 ; notes pour tout fichier omis ; notice), suivi du texte de chaque fichier dans l'ordre de l'index. Le même scénario et la même époque donnent des fichiers identiques à l'octet près. AUCUN SIGNAL : rien de ce qui est exporté n'est, ne modélise ni ne pilote un signal radiofréquence ou en bande de base, et un événement est un intervalle étiqueté, et non une recette pour produire de l'interférence ; le simulateur et son opérateur fournissent les signaux et sont responsables de ne les exécuter que là où c'est autorisé. Conservez l'avis avec les fichiers. Kshana ne publie aucun résultat de telles exécutions. Niveau de preuve : MODELLED.

Associe un jeton d'horodatage RFC 3161 à un paquet de preuves (kshana evidence attach-timestamp), en mémoire : files est un paquet tel que le renvoie create_evidence_pack, token_base64 les octets du fichier .tsr provenant d'une autorité d'horodatage. Le jeton est stocké sous timestamp.tsr à côté du manifeste signé, et non à l'intérieur, et le paquet avec le jeton doit toujours se vérifier, faute de quoi rien n'est associé ; un jeton existant est conservé sauf si replace vaut true. Renvoie les files mis à jour (à fournir à verify_evidence_pack avec require_timestamp à true pour exiger la présence du jeton) et les notes de vérification. Cela ne vérifie PAS la signature de l'autorité d'horodatage sur le jeton ni le certificat de l'autorité (cela vérifie la structure du jeton et que son empreinte de message est le hachage du manifest.json de ce paquet) : dites-le, et renvoyez l'utilisateur à openssl ts -verify. L'entrée et la réponse sont plafonnées à 4 MiB. Un horodatage montre qu'un hachage existait à un moment que l'autorité déclare ; ce n'est pas un avis juridique. Niveau de preuve : MODELLED.