Table de correspondance avec les cadres de résilience PNT

Aligné sur, non évalué ni approuvé. Ceci met en correspondance les capacités simulées de Kshana avec les cadres publiés de résilience PNT (PNT : positionnement, navigation et synchronisation temporelle). C'est une autoévaluation issue de la simulation, alignée sur le Resilient PNT Conformance Framework (RPCF) v2.0 du DHS/CISA (DHS : Department of Homeland Security ; CISA : Cybersecurity and Infrastructure Security Agency), le modèle Resist-Detect-Respond-Recover (RDRR) de RethinkPNT/Firesmith, et les critères de PNT résilient de Yang Yuanxi. Ce n'est pas une évaluation, une approbation, une accréditation ou une déclaration de compliance, et elle ne porte aucun aval du DHS, de l'IEEE (Institute of Electrical and Electronics Engineers) ni d'aucune autorité. Chaque ligne est étiquetée avec son statut de vérification honnête (VALIDATED par rapport à une référence indépendante, ou MODELLED à partir des premiers principes avec des tests) ; la couche de notation de la résilience elle-même est MODELLED. Deux de ses noyaux portent leurs propres lignes VALIDATED dans la matrice de vérification, le noyau de diversité par l'inverse de Simpson (resilience::diversity) et le noyau de statistiques d'ordre par rangs (resilience::stats) ; cela valide l'arithmétique, non les scores qui en découlent.

Le moteur de notation (src/resilience/) consomme ces capacités et émet des sous-scores par dimension, jamais un nombre fantôme unique. Voir src/verification.rs pour les invariants d'état vérifiés par machine.

DHS RPCF v2.0 : ce que le cadre définit, et les catégories de sous-scores propres à Kshana#

Le cadre publié (Resilient PNT Conformance Framework, Version 2,0, 26 avril 2022, DHS Science and Technology Directorate avec la CISA) définit trois fonctions essentielles (section 5,2 : Prevent, Respond, Recover), des niveaux de résilience 0 à 4 (section 5,3) et huit exigences minimales numérotées réparties sur les niveaux 1 à 4 (section 5,3, reprises en 5,5), plus une approche d'évaluation (section 8). Il ne définit pas une liste de sept catégories de techniques. Une version antérieure de cette page, et les commentaires du module de résilience, décrivaient sept « catégories de techniques RPCF » ; les mots Obfuscate et Diversify n'apparaissent pas dans la v2.0. Le texte de ce document a été relu le 2026-10-09 et aucune liste de ce genre n'y a été trouvée.

Les sept noms de sous-scores qu'émet le moteur de notation (Obfuscate, Limit, Verify, Isolate, Diversify, Mitigate, Recover ; « OLVIDMR » est notre mnémonique) sont donc des catégories de notation propres à Kshana, conservées pour la stabilité de la sortie. Ce ne sont pas des termes du DHS et les lignes ci-dessous ne disent pas que le DHS les exige. Lorsqu'une catégorie correspond à une exigence d'un cadre, la dernière colonne l'indique ; sinon, elle indique « aucune ».

Catégorie de sous-score de Kshana	Capacité de Kshana utilisée comme moteur	Module	État	Référence RPCF v2.0 la plus proche
Obfuscate	Technique déclarée × qualité de la source (aucun moteur comportemental direct)	`resilience::score`	MODELLED	aucune (une technique de prévention ; section 5,2, Prevent)
Limite	Technique déclarée × qualité de la source	`resilience::score`	MODELLED	aucune (une technique de prévention ; section 5,2, Prevent)
Verify	AUC (aire sous la courbe) du détecteur de perturbations sous le scénario (moniteurs de leurrage/brouillage/meaconing)	`impairment_eval`, `resilience::score`	MODELLED	Niveau 2 exigence 4 ; Niveau 3 exigence 7
Isolate	Technique déclarée × qualité de la source	`resilience::score`	MODELLED	Niveau 3 exigence 6
Diversify	Nombre de groupes indépendants → diversité effective par l'inverse de Simpson	`resilience::diversity`	MODELLED	Niveau 4 exigence 8 ; section 5,5 (mode commun)
Mitigate	Disponibilité sous déni	`fom`, `resilience::score`	MODELLED	section 5,2, Respond
Recover	Dérive en holdover × barrière de dégradation bornée	`fom`, `holdover`, `resilience::timeline`	MODELLED	Niveau 2 exigence 5 ; section 5,2, Recover

Le rapprochement exigence par exigence avec le cadre réel, avec ce pour quoi les sorties de Kshana apportent des éléments de preuve en faveur de et ce qui reste, se trouve dans compliance/dhs-rpcf.md.

Fonctions RDRR de RethinkPNT / Firesmith#

Fonction	Moteur	Module	État
Resist	Moyenne des sous-scores Obfuscate/Limit/Isolate/Diversify	`resilience::score`	MODELLED
Detect	Sous-score Verify (AUC du détecteur)	`resilience::score`	MODELLED
Respond	Sous-score Mitigate (disponibilité)	`resilience::score`	MODELLED
Recover	Holdover × barrière bornée ; indicateurs clés de performance (KPI : détection/réaction/récupération/perte) de la chronologie de résilience	`resilience::timeline`	MODELLED

Critères de Yang Yuanxi (le sous-ensemble auquel s'adressent les indicateurs de performance de synchronisation temporelle et de détection)#

Critère	Moteur	Module	État
Disponibilité	Disponibilité sous déni	`resilience::score`	MODELLED
Fiabilité	Fraction d'intégrité du filtre	`fom`, `resilience::score`	MODELLED
Continuité	Holdover × barrière bornée	`resilience::timeline`	MODELLED
Précision	Indicateur de synchronisation temporelle/de qualité — la précision dans le domaine de la position ne fait pas partie du score. `fom::positioning_performance` transforme une covariance de position fournie et un HPL (niveau de protection horizontal) en CEP/SEP/2DRMS (erreur circulaire probable, erreur sphérique probable, deux fois la racine de la moyenne quadratique des distances), mais aucun scénario ne l'injecte dans le score de résilience	`resilience::score`	MODELLED (domaine de la synchronisation temporelle seulement)

Ce que ce rapprochement n'affirme pas#

Aucun niveau RPCF conféré. Le niveau attribué est une lecture provisoire, issue de la simulation, avec une barrière de dégradation bornée explicite, non une maturité conférée.
Aucune précision dans le domaine de la position dans le score. Les sous-scores de résilience sont construits à partir de métriques de synchronisation temporelle et de détection. Le moteur calcule bien des positions ailleurs (les types de scénario pvt, gnss-ins et leo-pvt) et des niveaux de protection (le type de scénario integrity), mais la couche de notation ne les consomme pas.
Aucune validation sur le terrain. Le panel de référence et l'ensemble de menaces sont des réductions synthétiques, fondées sur des paramètres (resilience::panel), énoncées comme une limite de premier rang.

L'étude associée (resilience::study) existe précisément pour montrer que réduire ces dimensions à un score composite unique ou à un seul niveau produit une évaluation dont le classement des architectures est instable selon des choix défendables de pondération et de menace — ce rapprochement est donc une couche de mesure à lire dimension par dimension, non une note unique par rapport à laquelle évaluer un produit.

Scénarios de résilience et scénarios verticaux qui exercent ces couches#

Les scénarios fournis ci-dessous exécutent la mécanique de menace et de récupération vers laquelle pointent les lignes du rapprochement. Chacun est une exécution réelle du type de scénario nommé ; chacun est MODELLED (aucune donnée de terrain).

Scénario (`scenarios/`)	Type	Ce qu'il montre
`conflict-resilience.toml`	`conflict-resilience`	PNT en couches sous une menace commune de brouillage/leurrage : un Monte Carlo à graine fixée du déni de couches, la fusion à variance inverse des survivantes, le rapport de perte totale couche unique contre couches multiples, et la manière dont un déni corrélé effondre ce rapport. Ses identités Monte Carlo–forme close et de fusion sont vérifiées par des tests internes au crate ; le type de scénario n'a pas de ligne dans la matrice de vérification, il est donc classé MODELLED ici.
`leo-resilience-gnss-jammed-leo-carries.toml`	`campaign`	GNSS (système mondial de navigation par satellite) brouillé, une couche PNT en orbite terrestre basse (LEO) porte l'utilisateur, intégrité maintenue (trois phases sur une même chronologie).
`leo-resilience-multiband-diversity.toml`, `leo-resilience-spoof-monitors.toml`	`campaign`	Un brouilleur contre un récepteur à quatre bandes ; quel moniteur de leurrage voit quel leurreur.
`leo-resilience-js-margin.toml`	`spectrum`	La marge brouilleur sur signal (J/S) à partir de la puissance reçue.
`leo-resilience-spoof-doppler.toml`	`leo-pass`	Détection de leurrage par la cohérence du Doppler et de la géométrie de passage.
`leo-vertical-5g-network-timing.toml`, `leo-vertical-critical-infrastructure-timing.toml`	`campaign`	Synchronisation temporelle de stations de base et d'infrastructures critiques en holdover, avec l'heure LEO.
`leo-vertical-autonomous-vehicle.toml`, `leo-vertical-rail-maritime.toml`, `leo-vertical-polar-arctic.toml`, `leo-vertical-asset-tracking-iot.toml`	`campaign`	Utilisateurs routiers, ferroviaires, maritimes, polaires et de l'Internet des objets (IoT) avec une couche LEO.
`automotive-urban-canyon.toml`, `small-uas-jammed-nav.toml`	`gnss-ins`	Navigation à l'estime GNSS/INS (système de navigation inertielle) à travers un canyon urbain et à travers un brouillage sur un petit aéronef sans équipage.
`maritime-port-approach-coast.toml`, `rail-tunnel-coast.toml`	`ins-trn-coast`	Combien de temps une INS maintient un navire ou un train dans sa limite lorsque le GNSS est refusé.
`maritime-strait-jamming.toml`, `maritime-spoof-position-push.toml`	`jamming`, `spoof-detect`	Un brouilleur maritime ; détecter un leurreur qui entraîne la position rapportée d'un navire.