Kørsel af en modtager mod et eksporteret scenarie

En modtagerproducent, der ejer en GNSS-simulator til laboratoriebrug, kan afspille et Kshana-scenaries køretøjsbevægelse gennem den, optage, hvad modtageren under test gør, og score den log med kshana receiver-trust mod hændelser, der er angivet før kørslen. Kshana leverer bevægelsen, hændelsestiderne og scoringen. Den skriver intet signal: intet, der eksporteres her, syntetiserer, modellerer eller sender en radiofrekvens- eller basisbåndsbølgeform, og en eksporteret hændelse er et mærket tidsinterval, ikke en opskrift på at frembringe interferens. Simulatoren og dens operatør leverer signalerne, og operatøren er ansvarlig for kun at køre dem, hvor det er tilladt (ledningsført eller afskærmet, efter simulatorens egne sikkerhedsanvisninger).

Denne side er en metode. Den publicerer ingen resultater.

1. Eksport#

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

Gælder for typen gnss-ins (en køreprofil med attitude; udfaldene i navigationstilstanden er hændelserne) og for jamming og gnss-sim (en stationær modtager i scenariets varighed; en jamming-scenariets jammer er én hændelse over kørslen). Andre typer angiver, hvorfor de ikke har nogen køretøjsbane. --epoch er UTC-tidspunktet for bevægelsens tidsnul (standard 2024-01-01T00:00:00Z); scenarierne bærer ingen egen kalenderdato for køretøjsbevægelse. Det skal være et reelt UTC-tidspunkt, YYYY-MM-DDTHH:MM:SS (et efterstillet Z accepteres) med året i intervallet 2000 til 2099 og hvert felt inden for sit område; alt andet afvises. Outputtet er byte-identisk for det samme scenarie og den samme epoke.

Systemer og konventioner#

• Position: WGS 84, jordfast (ECEF: x gennem ækvator ved nulmeridianen, z gennem polen); lat_deg, lon_deg, h_m angiver den samme position geodætisk, h_m over ellipsoiden.
• Hastighed: jordfaste akser, relativt til Jorden.
• Attitude: heading_deg med uret fra sand nord i [0, 360), pitch_deg næsen op er positiv, roll_deg højre vinge ned er positiv; yaw-pitch-roll (3-2-1) fra det lokale nord-øst-ned-system til kropsakserne x fremad, y til højre, z ned. En stationær kilde skriver nuller. NMEA og waypointteksten bærer ingen attitude.
• Heading er kroppens yaw, ikke bevægelsesretningen. I køreprofilen gnss-ins yawer kroppen i firkantbølger, mens hastigheden følger med, så heading og kurs over grunden kan afvige med flere tiere grader (op til cirka 77 grader i det medfølgende scenarie automotive-urban-canyon). NMEA-kursen RMC er kursen over grunden, hastighedsvektorens retning, så en simulator, der læser heading fra bevægelsesfilen, og en, der læser kurs fra NMEA-filen, ser forskellige vinkler. Kursen over grunden fra CSV'en er atan2(v_east, v_north) af dens hastighed roteret til nord-øst-ned.
• Højden følger scenariet. For gnss-ins er h_m typens egen tangentplan-trinvise fremskrivning af dens reference og holdes ikke konstant (cirka 7 m over de 180 s af automotive-urban-canyon); det er scenariets bevægelse, skrevet som den er.
• Pladsholdere i NMEA GGA. Positionskvalitet (1), anvendte satellitter (12) og HDOP (1,0) skrives kun for at gøre sætningen velformet. De siger intet om scenariets geometri eller nogen modtagertilstand.
• Time: time_s efter epoken, UTC, skudsekunder er ikke modelleret.
• NMEA-højder er ellipsoidale. Højden i GGA rummer den ellipsoidale højde, og geoideseparationen skrives som 0,0. En simulator, der behandler højden som højde over middelhavsniveau, vil placere køretøjet forkert med den lokale geoideundulation.
• Tolerancer for rundtur (testet ved at læse hver fil tilbage): CSV-position 0,1 mm, breddegrad og længdegrad 1e-9 grad, hastighed 0,1 mm/s, vinkler 1e-6 grad; NMEA vandret position 5 mm, højde 1 mm, fart 0,001 knob, kurs 0,001 grad.

Indlæsning af filerne i en simulator#

Laboratoriesimulatorer er forskellige, og dette repositorium gengiver ingen simulators manual. Kontrollér, hvilke af formaterne ovenfor din læser, og dens angivne krav:

• Mange bevægelsesimportører forventer en fast opdateringsrate, ofte 10 Hz. Scenariet gnss-ins stepper med 0,1 s; for et stationært scenarie sættes [time] step_s til den rate, din simulator ønsker.
• Nogle importører springer sampler over, der falder mellem hele sekunder, eller ignorerer tidskolonnen og bruger rækkefølgen. Start bevægelsen på et helt sekund, og hold gitteret regelmæssigt.
• En CSV-importør, der lader dig knytte kolonner, kan læse run1.motion.csv direkte: vælg de jordfaste eller geodætiske kolonner, og sæt deres enheder ud fra run1.motion.json. At afkorte decimalerne giver falsk acceleration, så behold den skrevne præcision.
• Filen er kun bevægelse. Konfigurér konstellationen, interferensen og modtagerens front end i simulatoren, og tids dem efter hændelserne i run1.events.csv.

Kshana skriver ingen leverandørspecifik scripting-grænseflade.

Kontrolleret med én open source-simulators læsere

Bevægelsesindlæsningerne i gps-sdr-sim (MIT, commit 28ca29a6) fik eksporterne af otte medfølgende scenarier. Hver læser returnerede den eksporterede bane (tests/testbench_gpssdrsim_oracle.rs, præregistreret i xval/testbench-gpssdrsim/PREREGISTRATION.md):

• Giv ikke -u den fulde bevægelses-CSV. Dens læser rummer 100 tegn pr. linje, og en CSV-række er cirka 160 tegn, så hver række læses som to sampler. Overskriftslinjen læses som endnu en sample uden tal i.
• gps-sdr-sim rummer højst 3000 sampler, 300 s ved dens faste 10 Hz, og ignorerer tidskolonnen. Eksporterne for gnss-ins stepper med præcis 0,1 s. Længere scenarier, såsom gnss-ins-maritime på 20 minutter, læses kun til deres første 300 s.
• Dette kontrollerer, at filerne læses, som de er skrevet. Det kontrollerer ikke scenariets fysik eller noget, simulatoren sender.

2. Angiv, hvad du vil score, før kørslen#

Hændelsesfilen angiver de intervaller, scenariet definerer. Kopiér run1.events.toml ind i et receiver-trust-scenarie, tilføj en eventuel forudsigelse, du vil have kontrolleret, og fastlæg monitorernes tærskler og tolerancer før modtageren kører. Justér dem ikke, efter du har set loggen; scenariet, tærsklerne og logens SHA-256 indgår alle i resultatets hash.

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 eksporterede hændelser bærer scenariets egen type: et jamming-scenaries jammer er jamming; et udfald i navigationstilstanden er other, fordi scenariet angiver, at GNSS var utilgængeligt, ikke hvordan. Ret kind til, så den svarer til det, du konfigurerer simulatoren til at gøre.

3. Kør modtageren#

Start modtageren og dens logger, start simulatorscenariet med bevægelsesfilen, og lad kørslen dække kalibreringsintervallet, hver hændelse og en margin efter den sidste. Behold modtagerens egen log (UBX, RINEX 3-observationer, en Android-logger-CSV eller NMEA med sætninger om satellitstatus). En log uden signalstyrke for hver satellit kan stadig scores på modtagerens egen position, men monitorerne for bærebølge-til-støj har brug for den.

4. Afstem urene#

receiver-trust tæller hændelsestider fra den første epoke i modtagerens log; bevægelsesfilen tæller fra sin første sample. Hvis loggen starter d sekunder før bevægelsens første sample, så læg d til hver onset_s og end_s. Notér forskydningen og hvordan du målte den, og angiv den i scenariets name eller en kommentar, da en forkert forskydning flytter hver score. Hændelsestiderne alene kan ikke fortælle dig forskydningen; brug simulatorens markør for scenariets start eller modtagerens egne tidsstempler.

5. Score#

kshana receiver-trust bench-session.toml

skriver bench-session.result.json, .trust.csv og .trust.svg. For hver hændelse angiver resultatet falske alarmer før starten, den første alarm og dens monitorer, forsinkelsen og udfaldet (detected, late, missed, not-evaluable), plus et forudsagt og et observeret fald i bærebølge-til-støj, hvor du har angivet en forudsigelse. En uenighed rapporteres, den tunes aldrig væk. Se RECEIVER-TRUST.md.

For at se, hvilke rækker i offentlige rammeværker sessionen leverer belæg for:

kshana compliance-report bench-session.result.json

Se compliance/README.md. Den rapport beskriver evidensen i de kørsler, du giver den; den udtaler sig ikke om modtageren eller noget rammeværk.

6. Forbind hele kredsløbet i én signeret pakke#

Efter scoringen binder kshana evidence round-trip de fire optegnelser sammen: det scenarie, du eksporterede, laboratoriets testbetingelser, modtagerloggen og scoren. Udfyld run1.conditions.json (logens sti og SHA-256, modtageren under test, hver hændelses type og angivne effekt), og derefter:

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 bærer en round_trip-blok (kshana.round-trip/1) med scenario_sha256, conditions_hash, log_sha256 og scoren (hændelser detekteret af evaluerbare, første alarm), dækket af manifestets hashes og signaturen. Kommandoen afviser en pakke, hvis betingelser og scoringshændelser er uenige, eller hvis angivne loghash ikke er logens. Som enhver bevispakke er den en teknisk optegnelse, ikke en juridisk vurdering.

Gennemgået eksempel: gps-sdr-sim skriver en fil#

Dette eksempel bruger kun open source-simulatoren gps-sdr-sim til at skrive en basisbåndsfil ud fra den eksporterede bevægelse. Kshana sender ikke, og intet på denne side automatiserer afspilning af den fil gennem en radio. Hvis dit laboratorium afspiller en sådan fil ind i en modtager, er det din operatørs ansvar, og det må kun ske, hvor det er tilladt (via kabel eller afskærmet, efter simulatorens og radioens egne sikkerhedsanvisninger), og Kshana hverken dokumenterer eller omslutter det.

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

Hvad laboratoriet end derefter gør med run1.iq, sker uden for Kshana. Modtagerens egen log, uanset hvordan den er skaffet, er det, trin 5 scorer, og trin 6 forbinder. Filerne og de kontroller, Kshana foretager af sine egne eksporter, er kun testet på syntetiske data (tests/round_trip_pack.rs); der gøres ikke krav på nogen laboratoriekørsel her.

Hvad denne metode ikke gør#

• Den frembringer ikke et signal, og den siger ikke, hvilken interferens en simulator bør generere. Hændelserne siger hvornår, ikke hvad.
• En enkelt session er et enkelt datapunkt. Resultatet beskriver den log under den konfiguration og siger intet om andre modtagere, firmware, antenner eller reel interferens.
• Højder, rater og tidsafstemning er operatørens at kontrollere mod simulatoren; eksporten angiver sine egne konventioner og tolerancer og ikke mere.