Een ontvanger draaien tegen een geëxporteerd scenario

Een ontvangerfabrikant met een GNSS-simulator in het laboratorium kan de voertuigbeweging van een Kshana-scenario erdoorheen afspelen, vastleggen wat de te testen ontvanger doet, en die log met kshana receiver-trust scoren tegen gebeurtenissen die vóór de run zijn vastgelegd. Kshana levert de beweging, de gebeurtenistijden en de scoring. Het schrijft geen signaal: niets wat hier wordt geëxporteerd synthetiseert, modelleert of zendt een radiofrequente of basisbandgolfvorm uit, en een geëxporteerde gebeurtenis is een benoemd tijdsinterval, geen recept om interferentie te produceren. De simulator en zijn operator leveren de signalen, en de operator is ervoor verantwoordelijk ze alleen te draaien waar dat is toegestaan (geleid of afgeschermd, volgens de eigen veiligheidsinstructies van de simulator).

Deze pagina is een methode. Ze publiceert geen resultaten.

1. Exporteren#

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

Geldt voor de soort gnss-ins (een rijprofiel met oriëntatie; de uitval van de navigatietoestand zijn de gebeurtenissen), en voor jamming en gnss-sim (een stilstaande ontvanger voor de duur van het scenario; de jammer van een scenario jamming is één gebeurtenis over de run). Andere soorten zeggen waarom ze geen voertuigtraject hebben. --epoch is het UTC-tijdstip van bewegingstijd nul (standaard 2024-01-01T00:00:00Z); de scenario's hebben geen eigen kalenderdatum voor voertuigbeweging. Het moet een echt UTC-tijdstip zijn, YYYY-MM-DDTHH:MM:SS (een afsluitende Z wordt geaccepteerd) met het jaar in 2000 tot en met 2099 en elk veld binnen bereik; al het andere wordt geweigerd. De uitvoer is byte-identiek voor hetzelfde scenario en dezelfde epoche.

Stelsels en conventies#

• Positie: WGS 84, aardvast (ECEF: x door de evenaar bij de nulmeridiaan, z door de pool); lat_deg, lon_deg, h_m geven dezelfde positie geodetisch, h_m boven de ellipsoïde.
• Snelheid: aardvaste assen, ten opzichte van de aarde.
• Attitude: heading_deg kloksgewijs vanaf ware noord in [0, 360), pitch_deg neus omhoog positief, roll_deg rechtervleugel omlaag positief; yaw-pitch-roll (3-2-1) van het lokale noord-oost-omlaag-stelsel naar lichaamsassen x vooruit, y rechts, z omlaag. Een stilstaande bron schrijft nullen. NMEA en de waypointtekst bevatten geen oriëntatie.
• De heading is de yaw van het lichaam, niet de rijrichting. In het rijprofiel gnss-ins maakt het lichaam yaw in blokgolven terwijl de snelheid volgt, dus heading en koers over de grond kunnen tientallen graden verschillen (tot ongeveer 77 graden in het meegeleverde scenario automotive-urban-canyon). De NMEA-koers RMC is de koers over de grond, de richting van de snelheidsvector, dus een simulator die de heading uit het bewegingsbestand leest en een die de koers uit het NMEA-bestand leest, zien verschillende hoeken. De koers over de grond uit de CSV is atan2(v_east, v_north) van zijn naar noord-oost-omlaag geroteerde snelheid.
• De hoogte volgt het scenario. Voor gnss-ins is h_m de eigen raakvlakstapping van de soort van zijn referentie en wordt niet constant gehouden (ongeveer 7 m over de 180 s van automotive-urban-canyon); het is de beweging van het scenario, geschreven zoals ze is.
• Plaatshouders in NMEA GGA. De fixkwaliteit (1), het aantal gebruikte satellieten (12) en HDOP (1,0) worden alleen geschreven om de zin goedgevormd te maken. Ze zeggen niets over de geometrie van het scenario of enige toestand van de ontvanger.
• Time: time_s na de epoche, UTC, schrikkelseconden niet gemodelleerd.
• NMEA-hoogten zijn ellipsoïdaal. De hoogte in GGA bevat de ellipsoïdale hoogte en de geoïdescheiding wordt geschreven als 0,0. Een simulator die de hoogte behandelt als hoogte boven gemiddeld zeeniveau, plaatst het voertuig ernaast met de lokale geoïdeondulatie.
• Rondreistoleranties (getest door elk bestand terug te lezen): CSV-positie 0,1 mm, breedte- en lengtegraad 1e-9 graad, snelheid 0,1 mm/s, hoeken 1e-6 graad; NMEA horizontale positie 5 mm, hoogte 1 mm, snelheid 0,001 knoop, koers 0,001 graad.

De bestanden in een simulator laden#

Laboratoriumsimulators verschillen, en deze repository reproduceert de handleiding van geen enkele simulator. Controleer welke van de bovenstaande formaten de uwe leest, en zijn vermelde eisen:

• Veel beweging-importers verwachten een vaste verversingssnelheid, gewoonlijk 10 Hz. Het scenario gnss-ins stapt met 0,1 s; stel voor een stilstaand scenario [time] step_s in op de snelheid die uw simulator wil.
• Sommige importers slaan samples over die tussen hele seconden vallen, of negeren de tijdkolom en gebruiken de rijvolgorde. Begin de beweging op een hele seconde en houd het raster regelmatig.
• Een CSV-importer waarmee u kolommen kunt toewijzen kan run1.motion.csv rechtstreeks lezen: kies de aardvaste of geodetische kolommen en stel hun eenheden in op basis van run1.motion.json. Het afkappen van decimalen veroorzaakt valse versnelling, dus behoud de geschreven precisie.
• Het bestand bevat alleen beweging. Configureer de constellatie, de interferentie en de front-end van de ontvanger in de simulator, en stem ze af op de gebeurtenissen in run1.events.csv.

Kshana schrijft geen scriptinterface van een leverancier.

Gecontroleerd met de lezers van één opensourcesimulator

De bewegingslezers van gps-sdr-sim (MIT, commit 28ca29a6) kregen de exports van acht meegeleverde scenario's. Elke lezer gaf het geëxporteerde traject terug (tests/testbench_gpssdrsim_oracle.rs, vooraf vastgelegd in xval/testbench-gpssdrsim/PREREGISTRATION.md):

• Geef -u niet de volledige beweging-CSV. Zijn lezer bevat 100 tekens per regel, en een CSV-rij is ongeveer 160 tekens, dus elke rij wordt als twee samples gelezen. De kopregel wordt gelezen als nog een sample zonder getallen erin.
• gps-sdr-sim bevat hoogstens 3000 samples, 300 s bij zijn vaste 10 Hz, en negeert de tijdkolom. De exports van gnss-ins stappen met precies 0,1 s. Langere scenario's, zoals de gnss-ins-maritime van 20 minuten, worden alleen tot hun eerste 300 s gelezen.
• Dit controleert dat de bestanden worden gelezen zoals geschreven. Het controleert niet de fysica van het scenario of iets wat de simulator uitzendt.

2. Leg vast wat u gaat scoren vóór de run#

Het gebeurtenissenbestand geeft de intervallen die het scenario definieert. Kopieer run1.events.toml naar een scenario receiver-trust, voeg elke voorspelling toe die u gecontroleerd wilt hebben, en leg de drempels en toleranties van de monitors vast voordat de ontvanger draait. Pas ze niet aan na het zien van de log; het scenario, de drempels en de SHA-256 van de log zitten allemaal in de hash van het resultaat.

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

De geëxporteerde gebeurtenissen dragen de eigen soort van het scenario: de jammer van een scenario jamming is jamming; een uitval van de navigatietoestand is other, omdat het scenario stelt dat GNSS niet beschikbaar was, niet hoe. Wijzig het veld kind zodat het overeenkomt met wat u de simulator laat doen.

3. Draai de ontvanger#

Start de ontvanger en zijn logger, start het simulatorscenario met het bewegingsbestand, en laat de run het kalibratie-interval, elke gebeurtenis en een marge na de laatste beslaan. Bewaar de eigen log van de ontvanger (UBX, RINEX 3-waarnemingen, een CSV van een Android-logger, of NMEA met zinnen voor satellietstatus). Een log zonder signaalsterkte per satelliet kan nog wel op de eigen positie van de ontvanger worden gescoord, maar de carrier-to-noise-monitors hebben die nodig.

4. Breng de klokken op één lijn#

receiver-trust telt gebeurtenistijden vanaf de eerste epoche van de log van de ontvanger; het bewegingsbestand telt vanaf zijn eerste sample. Als de log d seconden vóór het eerste sample van de beweging begint, tel dan d op bij elke onset_s en end_s. Leg de offset vast en hoe u hem hebt gemeten, en vermeld hem in de name van het scenario of in een commentaar, want een verkeerde offset verschuift elke score. Gebeurtenistijden alleen kunnen u de offset niet vertellen; gebruik de startmarkering van het scenario van de simulator of de eigen tijdstempels van de ontvanger.

5. Scoren#

kshana receiver-trust bench-session.toml

schrijft bench-session.result.json, .trust.csv en .trust.svg. Voor elke gebeurtenis geeft het resultaat de valse alarmen vóór het begin, het eerste alarm en zijn monitors, de latentie en de uitkomst (detected, late, missed, not-evaluable), plus een voorspelde en waargenomen daling van de carrier-to-noise waar u een voorspelling hebt vastgelegd. Een afwijking wordt gerapporteerd, nooit weggeregeld. Zie RECEIVER-TRUST.md.

Om te zien voor welke rijen van openbare kaders de sessie bewijs levert:

kshana compliance-report bench-session.result.json

Zie compliance/README.md. Dat rapport beschrijft het bewijs in de runs die u het geeft; het doet geen vaststelling over de ontvanger of enig kader.

6. Koppel de rondreis in één ondertekend pakket#

Na het scoren verbindt kshana evidence round-trip de vier records: het scenario dat u hebt geëxporteerd, de testomstandigheden van het laboratorium, de ontvangerlog en de score. Vul run1.conditions.json in (het pad en de SHA-256 van de log, de te testen ontvanger, het type en het vermelde vermogen van elke gebeurtenis), en dan:

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 bevat een blok round_trip (kshana.round-trip/1) met scenario_sha256, conditions_hash, log_sha256 en de score (gedetecteerde gebeurtenissen van de evalueerbare, eerste alarm), gedekt door de hashes van het manifest en de handtekening. Het commando weigert een pakket waarvan de omstandigheden en scoringsgebeurtenissen niet overeenkomen, of waarvan de vermelde loghash niet die van de log is. Zoals elk bewijspakket is het een technisch record, geen juridisch oordeel.

Uitgewerkt voorbeeld: gps-sdr-sim schrijft een bestand#

Dit voorbeeld gebruikt de opensourcesimulator gps-sdr-sim alleen om uit de geëxporteerde beweging een basisbandbestand te schrijven. Kshana zendt niet uit, en niets op deze pagina automatiseert het afspelen van dat bestand via een radio. Als uw laboratorium zo'n bestand in een ontvanger afspeelt, is dat de verantwoordelijkheid van uw operator, alleen uitgevoerd waar dat is toegestaan (via kabel of afgeschermd, volgens de eigen veiligheidsinstructies van de simulator en de radio), en Kshana documenteert of omwikkelt het niet.

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

Wat het laboratorium daarna ook met run1.iq doet, gebeurt buiten Kshana. De eigen log van de ontvanger, hoe verkregen ook, is wat stap 5 scoort en stap 6 koppelt. De bestanden en de controles die Kshana op zijn eigen exports doet, zijn alleen op synthetische gegevens getest (tests/round_trip_pack.rs); hier wordt geen laboratoriumrun beweerd.

Wat deze methode niet doet#

• Ze produceert geen signaal, en ze zegt niet welke interferentie een simulator moet genereren. De gebeurtenissen zeggen wanneer, niet wat.
• Eén sessie is één gegevenspunt. Het resultaat beschrijft die log onder die configuratie, en zegt niets over andere ontvangers, firmware, antennes of echte interferentie.
• Hoogten, snelheden en tijduitlijning moet de operator aan de simulator toetsen; de export vermeldt zijn eigen conventies en toleranties en niet meer.