Einen Empfänger gegen ein exportiertes Szenario betreiben

Ein Empfängerhersteller, der einen GNSS-Simulator im Labor besitzt, kann die Fahrzeugbewegung eines Kshana-Szenarios darüber abspielen, aufzeichnen, was der zu prüfende Empfänger tut, und dieses Protokoll mit kshana receiver-trust anhand von Ereignissen bewerten, die vor dem Lauf festgelegt wurden. Kshana liefert die Bewegung, die Ereigniszeiten und die Bewertung. Es schreibt kein Signal: Nichts, was hier exportiert wird, synthetisiert, modelliert oder sendet eine Hochfrequenz- oder Basisband-Wellenform, und ein exportiertes Ereignis ist ein benanntes Zeitintervall, keine Anleitung zur Erzeugung von Störungen. Der Simulator und sein Betreiber liefern die Signale, und der Betreiber ist dafür verantwortlich, sie nur dort zu betreiben, wo es zulässig ist (leitungsgebunden oder abgeschirmt, gemäß den Sicherheitshinweisen des Simulators selbst).

Diese Seite ist ein Verfahren. Sie veröffentlicht keine Ergebnisse.

1. Export#

kshana bench-export scenarios/gnss-ins.toml --out run1 --epoch 2025-03-01T10:00:00Z

Gilt für die Szenarioart gnss-ins (ein Fahrprofil mit Lage; die Ausfälle des Navigationszustands sind die Ereignisse) sowie für jamming und gnss-sim (ein ruhender Empfänger für die Dauer des Szenarios; der Störsender eines jamming-Szenarios ist ein Ereignis über den gesamten Lauf). Andere Szenarioarten geben an, warum sie keine Fahrzeugtrajektorie haben. --epoch ist der UTC-Zeitpunkt der Bewegungszeit null (Standard 2024-01-01T00:00:00Z); die Szenarien tragen für die Fahrzeugbewegung kein eigenes Kalenderdatum. Er muss ein realer UTC-Zeitpunkt sein, YYYY-MM-DDTHH:MM:SS (ein abschließendes Z wird akzeptiert), mit dem Jahr zwischen 2000 und 2099 und jedem Feld im zulässigen Bereich; alles andere wird abgelehnt. Die Ausgabe ist für dasselbe Szenario und dieselbe Epoche byte-identisch.

Bezugssysteme und Konventionen#

• Position: WGS 84, erdfest (ECEF: x durch den Äquator am Nullmeridian, z durch den Pol); lat_deg, lon_deg, h_m geben dieselbe Position geodätisch an, h_m über dem Ellipsoid.
• Geschwindigkeit: erdfeste Achsen, relativ zur Erde.
• Attitude: heading_deg im Uhrzeigersinn von geografisch Nord in [0, 360), pitch_deg positiv bei Bug nach oben, roll_deg positiv bei rechtem Flügel nach unten; Gier-Nick-Roll (3-2-1) vom lokalen Nord-Ost-Unten-System zu den Körperachsen x vorwärts, y rechts, z unten. Eine ruhende Quelle schreibt Nullen. NMEA und der Wegpunkttext enthalten keine Lage.
• Der Kurs ist das Gieren des Körpers, nicht die Fahrtrichtung. Im Fahrprofil gnss-ins giert der Körper in Rechteckwellen, während die Geschwindigkeit folgt, sodass sich Kurs und Kurs über Grund um mehrere zehn Grad unterscheiden können (bis zu etwa 77 Grad im mitgelieferten Szenario automotive-urban-canyon). Der NMEA-Kurs RMC ist der Kurs über Grund, die Richtung des Geschwindigkeitsvektors, daher sehen ein Simulator, der den Kurs aus der Bewegungsdatei liest, und einer, der den Kurs aus der NMEA-Datei liest, unterschiedliche Winkel. Der Kurs über Grund aus der CSV ist atan2(v_east, v_north) seiner nach Nord-Ost-Unten gedrehten Geschwindigkeit.
• Die Höhe folgt dem Szenario. Bei gnss-ins ist h_m die eigene Tangentialebenen-Schrittrechnung der Szenarioart für ihre Wahrheit und wird nicht konstant gehalten (etwa 7 m über die 180 s von automotive-urban-canyon); sie ist die Bewegung des Szenarios, so geschrieben, wie sie ist.
• NMEA-GGA-Platzhalter. Fix-Qualität (1), verwendete Satelliten (12) und HDOP (1,0) werden nur geschrieben, damit der Satz wohlgeformt ist. Sie sagen nichts über die Geometrie des Szenarios oder einen Empfängerzustand aus.
• Time: time_s nach der Epoche, UTC, Schaltsekunden nicht modelliert.
• NMEA-Höhen sind ellipsoidisch. Die Höhe in GGA enthält die ellipsoidische Höhe, und die Geoidabweichung wird als 0,0 geschrieben. Ein Simulator, der die Höhe als Höhe über dem mittleren Meeresspiegel behandelt, setzt das Fahrzeug um die lokale Geoidundulation versetzt.
• Rundlauf-Toleranzen (getestet durch Zurücklesen jeder Datei): CSV-Position 0,1 mm, Breite und Länge 1e-9 Grad, Geschwindigkeit 0,1 mm/s, Winkel 1e-6 Grad; NMEA-Horizontalposition 5 mm, Höhe 1 mm, Geschwindigkeit 0,001 Knoten, Kurs 0,001 Grad.

Die Dateien in einen Simulator laden#

Laborsimulatoren unterscheiden sich, und dieses Repository gibt kein Handbuch eines Simulators wieder. Prüfen Sie, welches der obigen Formate Ihr Simulator liest und welche Anforderungen er angibt:

• Viele Bewegungsimporte erwarten eine feste Aktualisierungsrate, häufig 10 Hz. Das Szenario gnss-ins arbeitet mit einer Schrittweite von 0,1 s; bei einem ruhenden Szenario setzen Sie [time] step_s auf die Rate, die Ihr Simulator verlangt.
• Manche Importe überspringen Abtastwerte, die zwischen ganzen Sekunden liegen, oder ignorieren die Zeitspalte und verwenden die Zeilenreihenfolge. Beginnen Sie die Bewegung auf einer ganzen Sekunde und halten Sie das Raster regelmäßig.
• Ein CSV-Import, bei dem sich Spalten zuordnen lassen, kann run1.motion.csv direkt lesen: Wählen Sie die erdfesten oder die geodätischen Spalten und legen Sie ihre Einheiten anhand von run1.motion.json fest. Das Abschneiden der Dezimalstellen erzeugt eine falsche Beschleunigung, daher behalten Sie die geschriebene Genauigkeit bei.
• Die Datei enthält nur die Bewegung. Konfigurieren Sie die Konstellation, die Störung und das Empfänger-Frontend im Simulator und legen Sie deren Zeiten auf die Ereignisse in run1.events.csv.

Kshana schreibt keine herstellerspezifische Skriptschnittstelle.

Mit den Readern eines Open-Source-Simulators geprüft

Den Bewegungslesern von gps-sdr-sim (MIT, Commit 28ca29a6) wurden die Exporte von acht mitgelieferten Szenarien übergeben. Jeder Leser gab die exportierte Trajektorie zurück (tests/testbench_gpssdrsim_oracle.rs, vorab registriert in xval/testbench-gpssdrsim/PREREGISTRATION.md):

• Übergeben Sie -u nicht die vollständige Bewegungs-CSV. Ihr Leser fasst 100 Zeichen pro Zeile, und eine CSV-Zeile hat etwa 160 Zeichen, sodass jede Zeile als zwei Abtastwerte gelesen wird. Die Kopfzeile wird als ein weiterer Abtastwert ohne Zahlen gelesen.
• gps-sdr-sim fasst höchstens 3000 Abtastwerte, also 300 s bei seinen festen 10 Hz, und ignoriert die Zeitspalte. Die Exporte von gnss-ins arbeiten mit genau 0,1 s Schrittweite. Längere Szenarien, etwa das 20-minütige gnss-ins-maritime, werden nur bis zu den ersten 300 s gelesen.
• Dies prüft, dass die Dateien wie geschrieben gelesen werden. Es prüft weder die Physik des Szenarios noch irgendetwas, das der Simulator sendet.

2. Vor dem Lauf festlegen, was bewertet wird#

Die Ereignisdatei enthält die Intervalle, die das Szenario definiert. Kopieren Sie run1.events.toml in ein receiver-trust-Szenario, fügen Sie jede Vorhersage hinzu, die geprüft werden soll, und legen Sie die Monitorschwellen und Toleranzen fest, bevor der Empfänger läuft. Passen Sie sie nicht an, nachdem Sie das Protokoll gesehen haben; das Szenario, die Schwellen und das SHA-256 des Protokolls sind alle im Hash des Ergebnisses enthalten.

kind = "receiver-trust"
name = "bench session 1"

[log]
format = "ubx"                 # ubx, rinex, android or nmea
path = "receiver-log.ubx"

[monitors]
calibration_s = 60.0

# paste run1.events.toml here, and shift onsets by the log offset (step 4)
[[events]]
label = "gnss-denied-1"
kind = "other"
onset_s = 100.0
end_s = 160.0

Die exportierten Ereignisse tragen die eigene Art des Szenarios: Der Störsender eines jamming-Szenarios ist jamming; ein Ausfall des Navigationszustands ist other, weil das Szenario angibt, dass GNSS nicht verfügbar war, nicht wie. Ändern Sie kind entsprechend dem, was Sie im Simulator einstellen.

3. Den Empfänger betreiben#

Starten Sie den Empfänger und seinen Logger, starten Sie das Simulatorszenario mit der Bewegungsdatei und lassen Sie den Lauf das Kalibrierintervall, jedes Ereignis und einen Spielraum nach dem letzten abdecken. Bewahren Sie das eigene Protokoll des Empfängers auf (UBX, RINEX-3-Beobachtungen, eine CSV eines Android-Loggers oder NMEA mit Satellitenstatus-Sätzen). Ein Protokoll ohne Signalstärke pro Satellit kann dennoch anhand der eigenen Position des Empfängers bewertet werden, aber die Träger-Rausch-Monitore benötigen sie.

4. Die Uhren abgleichen#

receiver-trust zählt Ereigniszeiten ab der ersten Epoche des Empfängerprotokolls; die Bewegungsdatei zählt ab ihrem ersten Abtastwert. Beginnt das Protokoll d Sekunden vor dem ersten Abtastwert der Bewegung, addieren Sie d zu jedem onset_s und end_s. Notieren Sie den Versatz und wie Sie ihn gemessen haben und geben Sie ihn im name des Szenarios oder in einem Kommentar an, denn ein falscher Versatz verschiebt jede Bewertung. Ereigniszeiten allein verraten den Versatz nicht; verwenden Sie die Startmarke des Simulatorszenarios oder die eigenen Zeitstempel des Empfängers.

5. Bewerten#

kshana receiver-trust bench-session.toml

schreibt bench-session.result.json, .trust.csv und .trust.svg. Für jedes Ereignis gibt das Ergebnis die Fehlalarme vor dem Beginn, den ersten Alarm und seine Monitore, die Latenz und den Ausgang (detected, late, missed, not-evaluable) an, dazu einen vorhergesagten und einen beobachteten Rückgang des Träger-Rausch-Verhältnisses, wo Sie eine Vorhersage angegeben haben. Eine Abweichung wird berichtet, nie weggeregelt. Siehe RECEIVER-TRUST.md.

Um zu sehen, für welche öffentlichen Framework-Zeilen die Sitzung Belege liefert:

kshana compliance-report bench-session.result.json

Siehe compliance/README.md. Dieser Bericht beschreibt die Evidenz in den Läufen, die Sie ihm übergeben; er trifft keine Feststellung über den Empfänger oder ein Framework.

6. Den Rundlauf in einem signierten Paket verknüpfen#

Nach der Bewertung verknüpft kshana evidence round-trip die vier Aufzeichnungen: das exportierte Szenario, die Testbedingungen des Labors, das Empfängerprotokoll und die Bewertung. Füllen Sie run1.conditions.json aus (Pfad und SHA-256 des Protokolls, den geprüften Empfänger, Typ und angegebene Leistung jedes Ereignisses), dann:

kshana evidence keygen --out lab.key
kshana evidence round-trip bench-session.toml --scenario scenarios/gnss-ins.toml \
    --conditions run1.conditions.json --from 0 --to 180 --key lab.key --out round-trip-pack
kshana evidence verify round-trip-pack --pubkey <signer public key>

round-trip-pack/config.json enthält einen Block round_trip (kshana.round-trip/1) mit scenario_sha256, conditions_hash, log_sha256 und der Bewertung (erkannte Ereignisse von auswertbaren, erster Alarm), abgedeckt durch die Hashes des Manifests und die Signatur. Der Befehl lehnt ein Paket ab, dessen Bedingungen und Bewertungsereignisse nicht übereinstimmen oder dessen angegebener Protokoll-Hash nicht der des Protokolls ist. Wie jedes Nachweispaket ist es eine technische Aufzeichnung, keine Rechtsauffassung.

Durchgespieltes Beispiel: gps-sdr-sim schreibt eine Datei#

Dieses Beispiel verwendet den Open-Source-Simulator gps-sdr-sim nur, um aus der exportierten Bewegung eine Basisbanddatei zu schreiben. Kshana sendet nicht, und nichts auf dieser Seite automatisiert das Abspielen dieser Datei über ein Funkgerät. Wenn Ihr Labor eine solche Datei in einen Empfänger einspielt, liegt das in der Verantwortung Ihres Betreibers und geschieht nur dort, wo es zulässig ist (kabelgebunden oder abgeschirmt, gemäß den Sicherheitshinweisen des Simulators und des Funkgeräts), und Kshana dokumentiert oder kapselt es weder.

kshana bench-export scenarios/gnss-ins.toml --out run1 --epoch 2025-03-01T10:00:00Z
tail -n +2 run1.motion.csv | cut -d, -f1-4 > run1.xyz          # time, x, y, z (see above)
gps-sdr-sim -e brdc0600.25n -u run1.xyz -b 8 -o run1.iq        # writes a file, nothing else

Was das Labor anschließend mit run1.iq tut, geschieht außerhalb von Kshana. Das eigene Protokoll des Empfängers, wie auch immer gewonnen, ist das, was Schritt 5 bewertet und Schritt 6 verknüpft. Die Dateien und die Prüfungen, die Kshana an seinen eigenen Exporten vornimmt, sind nur mit synthetischen Daten getestet (tests/round_trip_pack.rs); hier wird kein Laborlauf behauptet.

Was dieses Verfahren nicht leistet#

• Es erzeugt kein Signal und sagt nicht, welche Störung ein Simulator erzeugen soll. Die Ereignisse sagen wann, nicht was.
• Eine einzelne Sitzung ist ein einzelner Datenpunkt. Das Ergebnis beschreibt dieses Protokoll unter dieser Konfiguration und sagt nichts über andere Empfänger, Firmware, Antennen oder reale Störungen.
• Höhen, Raten und Zeitabgleich sind vom Betreiber gegen den Simulator zu prüfen; der Export gibt seine eigenen Konventionen und Toleranzen an und nicht mehr.