Querverweis zu PNT-Resilienz-Rahmenwerken

Daran ausgerichtet, nicht bewertet oder genehmigt. Dies ordnet die simulierten Fähigkeiten von Kshana den veröffentlichten Rahmenwerken zur PNT-Resilienz (PNT: Positionierung, Navigation und Zeitgebung) zu. Es ist eine aus der Simulation abgeleitete Selbstbewertung, ausgerichtet am Resilient PNT Conformance Framework (RPCF) v2.0 von DHS/CISA (DHS: Department of Homeland Security; CISA: Cybersecurity and Infrastructure Security Agency), am Modell Resist-Detect-Respond-Recover (RDRR) von RethinkPNT/Firesmith und an den Kriterien für resiliente PNT von Yang Yuanxi. Es ist keine Bewertung, keine Genehmigung, keine Akkreditierung und keine Compliance-Aussage, und es trägt keine Billigung von DHS, IEEE (Institute of Electrical and Electronics Engineers) oder irgendeiner Behörde. Jede Zeile ist mit ihrem ehrlichen Verifikationsstatus gekennzeichnet (VALIDATED gegen eine externe unabhängige Referenz oder MODELLED aus ersten Prinzipien mit Tests); die Resilienz-Bewertungsebene selbst ist MODELLED. Zwei ihrer Kerne tragen in der Verifikationsmatrix eigene Zeilen VALIDATED, der Kern für die inverse Simpson-Diversität (resilience::diversity) und der Kern für Rangordnungsstatistik (resilience::stats); das validiert die Arithmetik, nicht die darauf aufgebauten Bewertungen.

Die Bewertungs-Engine (src/resilience/) verwendet diese Fähigkeiten und gibt Teilbewertungen je Dimension aus, nie eine einzelne Phantomzahl. Siehe src/verification.rs für die maschinengeprüften Statusinvarianten.

DHS RPCF v2.0: was das Rahmenwerk definiert, und die eigenen Teilbewertungskategorien von Kshana#

Das veröffentlichte Rahmenwerk (Resilient PNT Conformance Framework, Version 2,0, 26. April 2022, DHS Science and Technology Directorate mit CISA) definiert drei Kernfunktionen (Abschnitt 5,2: Prevent, Respond, Recover), Resilienzstufen 0 bis 4 (Abschnitt 5,3) und acht nummerierte Mindestanforderungen, verteilt auf die Level 1 bis 4 (Abschnitt 5,3, wiederholt in 5,5), plus einen Bewertungsansatz (Abschnitt 8). Es definiert keine Liste von sieben Technikkategorien. Eine frühere Fassung dieser Seite und die Kommentare des Resilienzmoduls beschrieben sieben „RPCF-Technikkategorien“; die Wörter Obfuscate und Diversify kommen in v2.0 nicht vor. Der Text dieses Dokuments wurde am 2026-10-09 erneut gelesen, und es wurde keine solche Liste gefunden.

Die sieben Namen der Teilbewertungen, die die Bewertungs-Engine ausgibt (Obfuscate, Limit, Verify, Isolate, Diversify, Mitigate, Recover; „OLVIDMR“ ist unsere Merkhilfe), sind daher die eigenen Bewertungskategorien von Kshana, aus Gründen der Ausgabestabilität beibehalten. Sie sind keine DHS-Begriffe, und die Zeilen unten sagen nicht, dass DHS sie verlangt. Wo eine Kategorie zu einer Anforderung des Rahmenwerks passt, sagt es die letzte Spalte; wo nicht, steht dort „keine“.

Teilbewertungskategorie von Kshana	Fähigkeit von Kshana als Treiber	Modul	Status	Nächste Referenz in RPCF v2.0
Obfuscate	Deklarierte Technik × Quellenqualität (kein direkter Verhaltenstreiber)	`resilience::score`	MODELLED	keine (eine Präventionstechnik; Abschnitt 5,2, Prevent)
Grenze	Deklarierte Technik × Quellenqualität	`resilience::score`	MODELLED	keine (eine Präventionstechnik; Abschnitt 5,2, Prevent)
Verify	AUC (Fläche unter der Kurve) des Beeinträchtigungsdetektors unter dem Szenario (Spoofing-/Jamming-/Meaconing-Monitore)	`impairment_eval`, `resilience::score`	MODELLED	Level 2 Anforderung 4; Level 3 Anforderung 7
Isolate	Deklarierte Technik × Quellenqualität	`resilience::score`	MODELLED	Level 3 Anforderung 6
Diversify	Zahl unabhängiger Gruppen → effektive Diversität nach inverser Simpson-Formel	`resilience::diversity`	MODELLED	Level 4 Anforderung 8; Abschnitt 5,5 (gemeinsame Ursache)
Mitigate	Verfügbarkeit unter Störung	`fom`, `resilience::score`	MODELLED	Abschnitt 5,2, Respond
Recover	Holdover-Überbrückung × Gate für begrenzte Verschlechterung	`fom`, `holdover`, `resilience::timeline`	MODELLED	Level 2 Anforderung 5; Abschnitt 5,2, Recover

Die Zuordnung je Anforderung zum realen Rahmenwerk, mit dem, wofür die Ausgaben von Kshana Belege liefern, und dem, was übrig bleibt, steht in compliance/dhs-rpcf.md.

Funktionen RDRR von RethinkPNT / Firesmith#

Funktion	Treiber	Modul	Status
Resist	Mittel der Teilbewertungen Obfuscate/Limit/Isolate/Diversify	`resilience::score`	MODELLED
Detect	Teilbewertung Verify (AUC des Detektors)	`resilience::score`	MODELLED
Respond	Teilbewertung Mitigate (Verfügbarkeit)	`resilience::score`	MODELLED
Recover	Holdover × begrenztes Gate; Leistungskennzahlen (KPIs: Erkennen/Reagieren/Erholen/Verlust) der Resilienz-Zeitleiste	`resilience::timeline`	MODELLED

Kriterien von Yang Yuanxi (die Teilmenge, zu der die Gütemaße für Zeitgebung/Erkennung etwas aussagen)#

Kriterium	Treiber	Modul	Status
Verfügbarkeit	Verfügbarkeit unter Störung	`resilience::score`	MODELLED
Zuverlässigkeit	Anteil der Filterintegrität	`fom`, `resilience::score`	MODELLED
Kontinuität	Holdover × begrenztes Gate	`resilience::timeline`	MODELLED
Genauigkeit	Stellvertreter für Zeitgebung/Qualität — die Genauigkeit im Positionsbereich ist nicht Teil der Bewertung. `fom::positioning_performance` macht aus einer gelieferten Positionskovarianz und HPL (horizontales Schutzniveau) CEP/SEP/2DRMS (circular error probable, spherical error probable, twice the distance root mean square), aber kein Szenario speist es in die Resilienzbewertung ein	`resilience::score`	MODELLED (nur Zeitbereich)

Was dieser Querverweis nicht behauptet#

Kein verliehenes RPCF-Level. Das zugewiesene Level ist eine vorläufige, aus der Simulation abgeleitete Lesart mit einem ausdrücklichen Gate für begrenzte Verschlechterung, kein verliehener Reifegrad.
Keine Genauigkeit im Positionsbereich in der Bewertung. Die Resilienz-Teilbewertungen werden aus Metriken des Zeitbereichs und der Erkennung aufgebaut. Die Engine berechnet an anderer Stelle durchaus Positionen (die Arten pvt, gnss-ins und leo-pvt) und Schutzniveaus (die Art integrity), aber die Bewertungsebene verwendet sie nicht.
Keine Felderprobung. Das Referenzpanel und das Bedrohungsensemble sind synthetische, durch Parameter begründete Reduktionen (resilience::panel), als erstrangige Einschränkung ausgewiesen.

Die Begleitstudie (resilience::study) existiert genau deshalb, um zu zeigen, dass das Zusammenfassen dieser Dimensionen zu einer Gesamtbewertung oder einem Level eine Bewertung ergibt, deren Rangfolge der Architekturen unter vertretbaren Gewichtungs- und Bedrohungsannahmen instabil ist — dieser Querverweis ist also eine Messebene, die je Dimension zu lesen ist, keine einzelne Note, an der ein Produkt bewertet wird.

Resilienz- und Vertikal-Szenarien, die diese Ebenen ausüben#

Die untenstehenden mitgelieferten Szenarien führen die Bedrohungs- und Erholungsmechanik aus, auf die die Zeilen des Querverweises zeigen. Jedes ist ein realer Lauf der genannten Art; jedes ist MODELLED (keine Felddaten).

Szenario (`scenarios/`)	Typ	Was es zeigt
`conflict-resilience.toml`	`conflict-resilience`	Geschichtete PNT unter einer gemeinsamen Jamming-/Spoofing-Bedrohung: ein gesäter Monte Carlo des Ausfalls von Schichten, inverse-Varianz-Fusion der Überlebenden, das Verhältnis des Gesamtverlusts bei einer einzelnen Schicht gegenüber geschichtet, und wie korrelierter Ausfall dieses Verhältnis zusammenbrechen lässt. Seine Identitäten Monte Carlo zu geschlossener Form und der Fusion werden von Crate-internen Tests geprüft; die Art hat keine Zeile in der Verifikationsmatrix, daher wird sie hier mit MODELLED eingestuft.
`leo-resilience-gnss-jammed-leo-carries.toml`	`campaign`	GNSS (globales Satellitennavigationssystem) gestört, eine PNT-Schicht in niedriger Erdumlaufbahn (LEO) trägt den Nutzer, Integrität gewahrt (drei Phasen auf einer Zeitleiste).
`leo-resilience-multiband-diversity.toml`, `leo-resilience-spoof-monitors.toml`	`campaign`	Ein Jammer gegen einen Empfänger mit vier Bändern; welcher Spoofing-Monitor welchen Spoofer sieht.
`leo-resilience-js-margin.toml`	`spectrum`	Die Marge des Störer-zu-Signal-Verhältnisses (J/S) aus der Empfangsleistung.
`leo-resilience-spoof-doppler.toml`	`leo-pass`	Spoofing-Erkennung durch Konsistenz von Doppler und Überflug-Geometrie.
`leo-vertical-5g-network-timing.toml`, `leo-vertical-critical-infrastructure-timing.toml`	`campaign`	Zeitgebung von Basisstationen und kritischer Infrastruktur im Holdover, mit LEO-Zeit.
`leo-vertical-autonomous-vehicle.toml`, `leo-vertical-rail-maritime.toml`, `leo-vertical-polar-arctic.toml`, `leo-vertical-asset-tracking-iot.toml`	`campaign`	Straßen-, Schienen-, See-, Polar- und Internet-der-Dinge-(IoT-)Nutzer mit einer LEO-Schicht.
`automotive-urban-canyon.toml`, `small-uas-jammed-nav.toml`	`gnss-ins`	GNSS/INS-Koppelnavigation (INS: Inertialnavigationssystem) durch eine Straßenschlucht und durch Jamming auf einem kleinen unbemannten Luftfahrzeug.
`maritime-port-approach-coast.toml`, `rail-tunnel-coast.toml`	`ins-trn-coast`	Wie lange ein INS ein Schiff oder einen Zug bei verwehrtem GNSS innerhalb seiner Grenze hält.
`maritime-strait-jamming.toml`, `maritime-spoof-position-push.toml`	`jamming`, `spoof-detect`	Ein maritimer Jammer; Erkennung eines Spoofers, der die gemeldete Position eines Schiffs wegzieht.