Krydsreference til rammeværk for PNT-resiliens

Tilpasset, ikke vurderet eller godkendt. Dette kobler Kshanas simulerede funktioner til de offentliggjorte rammeværker for PNT-resiliens (PNT: positionering, navigation og tidssynkronisering). Det er en simuleringsbaseret selvvurdering, tilpasset DHS/CISA (DHS: Department of Homeland Security; CISA: Cybersecurity and Infrastructure Security Agency) Resilient PNT Conformance Framework (RPCF) v2.0, RethinkPNT/Firesmith-modellen Resist-Detect-Respond-Recover (RDRR) og Yang Yuanxis kriterier for resilient PNT. Det er hverken en vurdering, en godkendelse, en akkreditering eller en compliance-erklæring, og det bærer ingen anbefaling fra DHS, IEEE (Institute of Electrical and Electronics Engineers) eller nogen myndighed. Hver række er mærket med sin ærlige verifikationsstatus (VALIDATED mod en ekstern uafhængig reference eller MODELLED ud fra grundprincipper med tests); selve laget for resiliensscore er MODELLED. To af dets kerner har egne VALIDATED-rækker i verifikationsmatrixen, kernen for invers Simpson-diversitet (resilience::diversity) og kernen for rangordensstatistik (resilience::stats); det validerer aritmetikken, ikke de score, der er bygget på den.

Scoringsmotoren (src/resilience/) bruger disse funktioner og udsender delscore for hver dimension, aldrig ét fantomtal. Se src/verification.rs for de maskinkontrollerede statusinvarianter.

DHS RPCF v2.0: hvad rammeværket definerer, og Kshanas egne delscorekategorier#

Det offentliggjorte rammeværk (Resilient PNT Conformance Framework, version 2,0, 26 april 2022, DHS Science and Technology Directorate sammen med CISA) definerer tre kernefunktioner (afsnit 5,2: Prevent, Respond, Recover), resiliensniveauerne 0 til 4 (afsnit 5,3) og otte nummererede minimumskrav fordelt på niveau 1 til 4 (afsnit 5,3, gentaget i 5,5) samt en evalueringsmetode (afsnit 8). Det definerer ikke en liste med syv teknikkategorier. En tidligere version af denne side og kommentarerne i resiliensmodulet beskrev syv "RPCF technique categories"; ordene Obfuscate og Diversify forekommer ikke i v2.0. Dokumentets tekst blev genlæst den 2026-10-09, og ingen sådan liste blev fundet.

De syv navne på delscore, som scoringsmotoren udsender (Obfuscate, Limit, Verify, Isolate, Diversify, Mitigate, Recover; "OLVIDMR" er vores huskeord), er derfor Kshanas egne scoringskategorier, bevaret for at holde output stabilt. De er ikke DHS-begreber, og rækkerne nedenfor siger ikke, at DHS kræver dem. Hvor en kategori svarer til et krav i rammeværket, siger den sidste kolonne det; hvor den ikke gør, står der "ingen".

Kshanas delscorekategori	Kshana-funktion brugt som drivkraft	Modul	Status	Nærmeste RPCF v2.0-reference
Obfuscate	Angiven teknik × kildekvalitet (ingen direkte adfærdsdrivkraft)	`resilience::score`	MODELLED	ingen (en forebyggelsesteknik; afsnit 5,2, Prevent)
Grænse	Angiven teknik × kildekvalitet	`resilience::score`	MODELLED	ingen (en forebyggelsesteknik; afsnit 5,2, Prevent)
Verify	AUC (arealet under kurven) for forstyrrelsesdetektoren under scenariet (spoof-/jam-/meacon-monitorer)	`impairment_eval`, `resilience::score`	MODELLED	Niveau 2 krav 4; niveau 3 krav 7
Isolate	Angiven teknik × kildekvalitet	`resilience::score`	MODELLED	Niveau 3 krav 6
Diversify	Antal uafhængige grupper → invers Simpson-effektiv diversitet	`resilience::diversity`	MODELLED	Niveau 4 krav 8; afsnit 5,5 (fælles fejl)
Mitigate	Tilgængelighed under afvisning	`fom`, `resilience::score`	MODELLED	afsnit 5,2, Respond
Recover	Holdover-udløb × port for afgrænset forringelse	`fom`, `holdover`, `resilience::timeline`	MODELLED	Niveau 2 krav 5; afsnit 5,2, Recover

Den detaljerede kobling for hvert krav til det virkelige rammeværk, med hvad Kshanas output leverer belæg for, og hvad der er tilbage, findes i compliance/dhs-rpcf.md.

Funktionerne i RethinkPNT / Firesmith RDRR#

Funktion	Drivkraft	Modul	Status
Resist	Middelværdi af delscorene Obfuscate/Limit/Isolate/Diversify	`resilience::score`	MODELLED
Detect	Delscore for Verify (detektorens AUC)	`resilience::score`	MODELLED
Respond	Delscore for Mitigate (tilgængelighed)	`resilience::score`	MODELLED
Recover	Holdover × afgrænset port; nøgletal for resiliens-tidslinjen (KPI'er: detect/react/recover/loss)	`resilience::timeline`	MODELLED

Yang Yuanxis kriterier (den delmængde, som tidssynkroniserings- og detektionskvalitetsmålene udtaler sig om)#

Kriterium	Drivkraft	Modul	Status
Tilgængelighed	Tilgængelighed under afvisning	`resilience::score`	MODELLED
Pålidelighed	Filterets integritetsandel	`fom`, `resilience::score`	MODELLED
Kontinuitet	Holdover × afgrænset port	`resilience::timeline`	MODELLED
Nøjagtighed	Stedfortræder for tidssynkronisering/kvalitet — nøjagtighed i positionsdomænet indgår ikke i scoren. `fom::positioning_performance` omsætter en leveret positionskovarians og HPL (horisontalt beskyttelsesniveau) til CEP/SEP/2DRMS (circular error probable, spherical error probable, twice the distance root mean square), men intet scenarie fører den ind i resiliensscoren	`resilience::score`	MODELLED (kun i tidsdomænet)

Hvad denne krydsreference ikke hævder#

Intet tildelt RPCF-niveau. Det angivne niveau er en foreløbig, simuleringsbaseret aflæsning med en eksplicit port for afgrænset forringelse, ikke en tildelt modenhed.
Ingen nøjagtighed i positionsdomænet i scoren. Delscorene for resiliens er bygget af metrikker for tidsdomænet og detektion. Motoren beregner positioner andre steder (typerne pvt, gnss-ins og leo-pvt) og beskyttelsesniveauer (typen integrity), men scoringslaget bruger dem ikke.
Ingen feltvalidering. Referencepanelet og trusselsensemblet er syntetiske, parameterforankrede reduktioner (resilience::panel), angivet som en begrænsning af første rang.

Ledsagestudiet (resilience::study) findes netop for at vise, at en sammenlægning af disse dimensioner til én samlet score eller ét niveau giver en vurdering, hvis rangordning af arkitekturer er ustabil under forsvarlige valg af vægte og trusler — så denne krydsreference er et målelag, der skal læses dimension for dimension, ikke en enkelt karakter at vurdere et produkt efter.

Resiliens- og vertikalscenarier, der udnytter disse lag#

De medfølgende scenarier nedenfor kører det trussels- og genoprettelsesapparat, som rækkerne i krydsreferencen peger på. Hvert er en virkelig kørsel af den nævnte type; hvert er MODELLED (ingen feltdata).

Scenarie (`scenarios/`)	Type	Hvad den viser
`conflict-resilience.toml`	`conflict-resilience`	Lagdelt PNT under en fælles jamming-/spoofing-trussel: en seedet Monte Carlo af lagafvisning, inverse-varians-fusion af de overlevende, forholdet mellem totalt tab for ét lag og for lagdelt PNT, og hvordan korreleret afvisning får det forhold til at falde sammen. Dens identiteter mellem Monte Carlo og lukket form samt fusion kontrolleres af tests i cratet; typen har ingen række i verifikationsmatrixen, så den bedømmes her som MODELLED.
`leo-resilience-gnss-jammed-leo-carries.toml`	`campaign`	GNSS (globalt navigationssatellitsystem) forstyrret af jamming, et PNT-lag i lav jordbane (LEO) bærer brugeren, integritet bevaret (tre faser på én tidslinje).
`leo-resilience-multiband-diversity.toml`, `leo-resilience-spoof-monitors.toml`	`campaign`	Én jammer mod en modtager med fire bånd; hvilken spoofing-monitor ser hvilken spoofer.
`leo-resilience-js-margin.toml`	`spectrum`	Marginen for jammer-til-signal (J/S) ud fra modtaget effekt.
`leo-resilience-spoof-doppler.toml`	`leo-pass`	Detektion af spoofing ud fra konsistens mellem Doppler og passagegeometri.
`leo-vertical-5g-network-timing.toml`, `leo-vertical-critical-infrastructure-timing.toml`	`campaign`	Tidssynkronisering af basestationer og kritisk infrastruktur i holdover, med LEO-tid.
`leo-vertical-autonomous-vehicle.toml`, `leo-vertical-rail-maritime.toml`, `leo-vertical-polar-arctic.toml`, `leo-vertical-asset-tracking-iot.toml`	`campaign`	Brugere på vej, bane, hav, i polarområder og i tingenes internet (IoT) med et LEO-lag.
`automotive-urban-canyon.toml`, `small-uas-jammed-nav.toml`	`gnss-ins`	GNSS/INS (inertialt navigationssystem)-dødregning gennem en byprofil og gennem jamming på et lille ubemandet luftfartøj.
`maritime-port-approach-coast.toml`, `rail-tunnel-coast.toml`	`ins-trn-coast`	Hvor længe et INS holder et skib eller et tog inden for sin grænse, når GNSS er afvist.
`maritime-strait-jamming.toml`, `maritime-spoof-position-push.toml`	`jamming`, `spoof-detect`	En maritim jammer; detektion af en spoofer, der trækker et skibs rapporterede position væk.