Att köra en mottagare mot ett exporterat scenario

En mottagartillverkare som äger en GNSS-simulator för laboratoriebruk kan spela upp ett Kshana-scenarios fordonsrörelse genom den, registrera vad mottagaren under test gör och poängsätta den loggen med kshana receiver-trust mot händelser som angetts före körningen. Kshana tillhandahåller rörelsen, händelsetiderna och poängsättningen. Den skriver ingen signal: inget som exporteras här syntetiserar, modellerar eller sänder en radiofrekvens- eller basbandsvågform, och en exporterad händelse är ett märkt tidsintervall, inte ett recept för att framställa störning. Simulatorn och dess operatör tillhandahåller signalerna, och operatören ansvarar för att köra dem endast där det är tillåtet (ledningsbundet eller skärmat, enligt simulatorns egna säkerhetsanvisningar).

Den här sidan är en metod. Den publicerar inga resultat.

1. Export#

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

Gäller för typen gnss-ins (en körprofil med attityd; avbrotten i navigeringstillståndet är händelserna), och för jamming och gnss-sim (en stillastående mottagare under scenariots varaktighet; ett jamming-scenarios störsändare är en enda händelse under körningen). Andra typer anger varför de saknar fordonsbana. --epoch är UTC-ögonblicket för rörelsens tid noll (standard 2024-01-01T00:00:00Z); scenarierna har inget eget kalenderdatum för fordonsrörelse. Det måste vara ett verkligt UTC-ögonblick, YYYY-MM-DDTHH:MM:SS (ett avslutande Z accepteras) med året i intervallet 2000 till 2099 och varje fält inom sitt intervall; allt annat avvisas. Utdata är byte-identiskt för samma scenario och epok.

System och konventioner#

• Position: WGS 84, jordfast (ECEF: x genom ekvatorn vid nollmeridianen, z genom polen); lat_deg, lon_deg, h_m ger samma position geodetiskt, h_m över ellipsoiden.
• Hastighet: jordfasta axlar, relativt jorden.
• Attitude: heading_deg medurs från sann nord i [0, 360), pitch_deg nosen uppåt positivt, roll_deg höger vinge nedåt positivt; girning-stigning-rullning (3-2-1) från det lokala nord-öst-ned-systemet till kroppsaxlarna x framåt, y höger, z nedåt. En stillastående källa skriver nollor. NMEA och waypointtexten har ingen attityd.
• Kursen är kroppens girning, inte färdriktningen. I körprofilen gnss-ins girar kroppen i fyrkantsvågor medan hastigheten följer efter, så heading och kursen över grund kan skilja sig med tiotals grader (upp till cirka 77 grader i det medföljande scenariot automotive-urban-canyon). NMEA-kursen RMC är kursen över grund, hastighetsvektorns riktning, så en simulator som läser heading från rörelsefilen och en som läser kurs från NMEA-filen ser olika vinklar. Kursen över grund från CSV-filen är atan2(v_east, v_north) av dess hastighet roterad till nord-öst-ned.
• Höjden följer scenariot. För gnss-ins är h_m typens egen tangentplanssteppning av sin referens och hålls inte konstant (cirka 7 m under 180 s av automotive-urban-canyon); det är scenariots rörelse, skriven som den är.
• Platshållare i NMEA GGA. Positionsbestämningens kvalitet (1), använda satelliter (12) och HDOP (1,0) skrivs bara för att göra meningen välformad. De säger ingenting om scenariots geometri eller något mottagartillstånd.
• Time: time_s efter epoken, UTC, skottsekunder är inte modellerade.
• NMEA-höjder är ellipsoidala. Höjden i GGA innehåller den ellipsoidala höjden och geoidseparationen skrivs som 0,0. En simulator som behandlar höjden som höjd över medelhavsytan placerar fordonet fel med den lokala geoidundulationen.
• Tur-och-retur-toleranser (testade genom att läsa tillbaka varje fil): CSV-position 0,1 mm, latitud och longitud 1e-9 grad, hastighet 0,1 mm/s, vinklar 1e-6 grad; NMEA horisontell position 5 mm, höjd 1 mm, fart 0,001 knop, kurs 0,001 grad.

Att läsa in filerna i en simulator#

Laboratoriesimulatorer skiljer sig åt, och det här förrådet återger ingen simulators handbok. Kontrollera vilka av formaten ovan din läser och dess angivna krav:

• Många rörelseimportörer förväntar sig en fast uppdateringstakt, vanligen 10 Hz. Scenariot gnss-ins stegar med 0,1 s; för ett stillastående scenario, sätt [time] step_s till den takt din simulator vill ha.
• Vissa importörer hoppar över sampel som faller mellan hela sekunder, eller ignorerar tidskolumnen och använder radordningen. Starta rörelsen på en hel sekund och håll rutnätet regelbundet.
• En CSV-importör som låter dig mappa kolumner kan läsa run1.motion.csv direkt: välj de jordfasta eller geodetiska kolumnerna och ange deras enheter utifrån run1.motion.json. Att kapa decimalerna ger falsk acceleration, så behåll den skrivna precisionen.
• Filen innehåller endast rörelse. Konfigurera konstellationen, störningen och mottagarens frontände i simulatorn, och tidsätt dem efter händelserna i run1.events.csv.

Kshana skriver inget skriptgränssnitt för någon tillverkare.

Kontrollerat med en öppen källkod-simulators läsare

Rörelseläsarna i gps-sdr-sim (MIT, commit 28ca29a6) fick exporterna från åtta medföljande scenarier. Varje läsare returnerade den exporterade banan (tests/testbench_gpssdrsim_oracle.rs, förhandsregistrerad i xval/testbench-gpssdrsim/PREREGISTRATION.md):

• Ge inte -u hela rörelse-CSV-filen. Dess läsare rymmer 100 tecken per rad, och en CSV-rad är cirka 160 tecken, så varje rad läses som två sampel. Rubrikraden läses som ytterligare ett sampel utan några tal i sig.
• gps-sdr-sim rymmer högst 3000 sampel, 300 s vid sin fasta takt på 10 Hz, och ignorerar tidskolumnen. Exporterna från gnss-ins stegar med exakt 0,1 s. Längre scenarier, till exempel det 20 minuter långa gnss-ins-maritime, läses bara till sina första 300 s.
• Det här kontrollerar att filerna läses som de är skrivna. Det kontrollerar inte scenariots fysik eller något som simulatorn sänder.

2. Ange vad du ska poängsätta före körningen#

Händelsefilen anger de intervall som scenariot definierar. Kopiera run1.events.toml till ett receiver-trust-scenario, lägg till de prediktioner du vill få kontrollerade och fastställ monitorernas trösklar och toleranser innan mottagaren körs. Justera dem inte efter att ha sett loggen; scenariot, trösklarna och loggens SHA-256 ingår alla 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 exporterade händelserna bär scenariots egen typ: ett jamming-scenarios störsändare är jamming; ett avbrott i navigeringstillståndet är other, eftersom scenariot anger att GNSS inte var tillgängligt, inte hur. Ändra kind så att den stämmer med vad du konfigurerar simulatorn att göra.

3. Kör mottagaren#

Starta mottagaren och dess loggare, starta simulatorscenariot med rörelsefilen och låt körningen täcka kalibreringsintervallet, varje händelse och en marginal efter den sista. Behåll mottagarens egen logg (UBX, RINEX 3-observationer, en CSV från Android-loggare, eller NMEA med satellitstatusmeningar). En logg utan signalstyrka per satellit kan fortfarande poängsättas utifrån mottagarens egen position, men monitorerna för bärvåg-till-brus behöver den.

4. Justera klockorna#

receiver-trust räknar händelsetider från första epoken i mottagarens logg; rörelsefilen räknar från sitt första sampel. Om loggen startar d sekunder före rörelsens första sampel, lägg till d på varje onset_s och end_s. Anteckna offseten och hur du mätte den, och ange den i scenariots name eller i en kommentar, eftersom en felaktig offset förskjuter varje poäng. Enbart händelsetiderna kan inte berätta offseten; använd simulatorns markör för scenariostart eller mottagarens egna tidsstämplar.

5. Poängsätt#

kshana receiver-trust bench-session.toml

skriver bench-session.result.json, .trust.csv och .trust.svg. För varje händelse anger resultatet falsklarm före starten, det första larmet och dess monitorer, fördröjningen och utfallet (detected, late, missed, not-evaluable), samt ett predikterat och observerat fall i bärvåg-till-brus där du angav en prediktion. En avvikelse rapporteras, aldrig bortjusterad. Se RECEIVER-TRUST.md.

För att se vilka rader i offentliga ramverk som sessionen ger belägg för:

kshana compliance-report bench-session.result.json

Se compliance/README.md. Den rapporten beskriver beläggen i de körningar du ger den; den gör inget fastställande om mottagaren eller något ramverk.

6. Länka tur-och-retur-körningen i ett signerat paket#

Efter poängsättningen knyter kshana evidence round-trip ihop de fyra registreringarna: scenariot du exporterade, laboratoriets testvillkor, mottagarloggen och poängen. Fyll i run1.conditions.json (loggens sökväg och SHA-256, mottagaren under test, varje händelses typ och angivna effekt), och sedan:

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 innehåller ett round_trip-block (kshana.round-trip/1) med scenario_sha256, conditions_hash, log_sha256 och poängen (detekterade händelser av utvärderingsbara, första larmet), täckt av manifestets hashar och signaturen. Kommandot avvisar ett paket vars villkor och poängsatta händelser inte stämmer överens, eller vars angivna loggash inte är loggens. Som varje bevispaket är det en teknisk registrering, inte ett juridiskt utlåtande.

Genomgånget exempel: gps-sdr-sim skriver en fil#

Det här exemplet använder den öppna simulatorn gps-sdr-sim bara för att skriva en basbandsfil utifrån den exporterade rörelsen. Kshana sänder inte, och inget på den här sidan automatiserar uppspelning av filen genom en radio. Om ditt laboratorium spelar upp en sådan fil in i en mottagare är det din operatörs ansvar, och sker bara där det är tillåtet (ledningsbundet eller skärmat, enligt simulatorns och radions egna säkerhetsanvisningar), och Kshana varken dokumenterar eller omsluter 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

Vad laboratoriet än gör med run1.iq sker utanför Kshana. Mottagarens egen logg, hur den än har erhållits, är vad steg 5 poängsätter och steg 6 länkar. Filerna och de kontroller som Kshana gör av sina egna exporter är endast testade på syntetiska data (tests/round_trip_pack.rs); ingen laboratoriekörning görs gällande här.

Vad den här metoden inte gör#

• Den framställer ingen signal, och den säger inte vilken störning en simulator bör generera. Händelserna anger när, inte vad.
• En enskild session är en enda datapunkt. Resultatet beskriver den loggen under den konfigurationen och säger ingenting om andra mottagare, firmware, antenner eller verklig störning.
• Höjder, takter och tidsjustering är operatörens att kontrollera mot simulatorn; exporten anger sina egna konventioner och toleranser och inget mer.