Correspondance de compliance

Les acheteurs et les fabricants de récepteurs doivent répondre à des cadres publics de résilience. Ce dossier met en correspondance ce que Kshana calcule et consigne avec ces cadres, ligne par ligne, et kshana compliance-report remplit la correspondance à partir des exécutions dont vous disposez réellement.

Formulation. Les sorties de Kshana apportent des éléments de preuve en faveur d'une exigence. Elles ne constituent ni une évaluation ni une approbation d'un produit, et aucun de ces fichiers n'est une déclaration d'un organisme d'évaluation ; Kshana n'en est pas un. Le texte des exigences est paraphrasé, jamais reproduit.

Les paquets de normes (0,38) transforment un cadre en scénarios notés : chaque paquet comprend des scénarios, des seuils fixés avant l'exécution et les lignes en faveur desquelles il apporte des éléments de preuve. kshana standards-pack list les affiche.

Chaque fichier énumère ses documents sources avec la version, l'URL, la date de lecture et ce qui a été vérifié ou non. Les sources ont été lues le 2026-10-09 (le profil du NIST le 2026-10-18 ; le bulletin de l'EASA et les pages du catalogue de l'EN 16803 ont été revérifiés le 2026-10-10). Lorsqu'une source n'a pu être lue que par un miroir ou une page de catalogue, le fichier le dit.

Le rapport#

kshana compliance-report spoof-detect.result.json integrity-raim.result.json session.result.json

écrit compliance-report.compliance.md et compliance-report.compliance.json (--out <base> change le nom). Les entrées sont des fichiers de résultats d'exécutions antérieures : l'exécution d'un scénario écrit <name>.result.json à côté de <name>.toml, et kshana receiver-trust écrit le sien. Le type de scénario de chaque exécution est lu dans le fichier de scénario voisin du résultat, dans le contenu d'un résultat receiver-trust, ou dans un kind de premier niveau, et doit être un type de scénario que le moteur connaît. Un résultat est signalé comme non utilisé, avec la raison, et ne compte pour rien lorsque son type de scénario est introuvable, n'est pas un type de scénario connu, ou lorsque le scénario voisin et le kind propre au résultat ne concordent pas. (Le scenario_hash du résultat et un hachage du fichier de scénario ne sont pas comparés : le moteur calcule le premier sur son scénario analysé et un hachage de fichier porte sur le texte, ce sont donc des grandeurs différentes.)

Une étiquette de type de scénario seule n'est pas une preuve. Une exécution ne compte pour une capacité que lorsque son résultat porte aussi les champs qu'écrit ce type de scénario (par exemple un résultat jamming a besoin de ses figures de mérite et de ses lignes par époque ; un résultat integrity a besoin de ses décomptes d'échantillons). Les champs sont énumérés dans src/compliance/mapping.rs (KIND_FIELDS), et un résultat auquel il en manque un n'est pas compté. Un hachage qui n'est pas hexadécimal n'est pas signalé comme un hachage. Un résultat receiver-trust dont les décomptes ne sont pas des nombres entiers, ou dont le décompte détecté ou concordant dépasse son décompte évaluable, est exclu et signalé comme non utilisé.

Pour chaque ligne, le rapport donne l'une des mentions suivantes :

La colonne d'écart est affichée pour chaque ligne, y compris celles étayées : une exécution qui apporte des éléments de preuve en faveur d'une capacité laisse quand même l'essentiel d'une exigence à d'autres éléments de preuve. Le rapport répète la règle de formulation en tête. --mapping affiche les tableaux statiques et --sources la liste des sources.

Les exécutions receiver-trust apportent aussi les décomptes qu'elles indiquent (événements détectés parmi ceux évaluables, prédictions concordantes parmi celles évaluables). Ceux-ci décrivent ce journal, noté par rapport à des événements et à des tolérances fixés avant l'exécution, et sont rapportés tels que l'exécution les indique.

Capacités#