Kjøre en mottaker mot et eksportert scenario

En mottakerprodusent som eier en GNSS-simulator i laboratoriet, kan spille av bevegelsen til et Kshana-scenarios kjøretøy gjennom den, registrere hva mottakeren under test gjør, og skåre den loggen med kshana receiver-trust mot hendelser som er oppgitt før kjøringen. Kshana leverer bevegelsen, hendelsestidspunktene og skåringen. Den skriver ikke noe signal: ingenting som eksporteres her syntetiserer, modellerer eller sender en radiofrekvent bølgeform eller en bølgeform i basebånd, og en eksportert hendelse er et merket tidsintervall, ikke en oppskrift for å lage interferens. Simulatoren og operatøren leverer signalene, og operatøren er ansvarlig for å kjøre dem bare der det er tillatt (kablet eller skjermet, i henhold til simulatorens egne sikkerhetsanvisninger).

Denne siden er en metode. Den publiserer ingen resultater.

1. Eksport#

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

Gjelder typen gnss-ins (en kjøreprofil med holdning; utfallene i navigasjonstilstanden er hendelsene), og jamming og gnss-sim (en stasjonær mottaker i scenarioets varighet; jammeren i et jamming-scenario er én hendelse over kjøringen). Andre typer sier hvorfor de ikke har noen kjøretøybane. --epoch er UTC-tidspunktet for bevegelsestid null (standard 2024-01-01T00:00:00Z); scenarioene har ingen egen kalenderdato for kjøretøybevegelse. Det må være et ekte UTC-tidspunkt, YYYY-MM-DDTHH:MM:SS (en avsluttende Z godtas) med år i området 2000 til 2099 og alle felt innenfor gyldig område; alt annet avvises. Utdataene er byte for byte identiske for samme scenario og epoke.

Referansesystemer og konvensjoner#

• Posisjon: WGS 84, jordfast (ECEF: x gjennom ekvator ved nullmeridianen, z gjennom polen); lat_deg, lon_deg, h_m gir den samme posisjonen geodetisk, h_m over ellipsoiden.
• Hastighet: jordfaste akser, relativt til jorden.
• Attitude: heading_deg med klokken fra sann nord i [0, 360), pitch_deg nese opp er positiv, roll_deg høyre vinge ned er positiv; gire-stampe-rulle (3-2-1) fra det lokale nord-øst-ned-systemet til kroppsaksene x fremover, y til høyre, z ned. En stasjonær kilde skriver nuller. NMEA og veipunktteksten har ingen holdning.
• Heading er kroppens gir, ikke bevegelsesretningen. I kjøreprofilen gnss-ins girer kroppen i firkantbølger mens hastigheten følger etter, slik at heading og kursen over bakken kan avvike med flere titalls grader (opptil omtrent 77 grader i det medfølgende scenarioet automotive-urban-canyon). NMEA-kursen i RMC er kursen over bakken, retningen til hastighetsvektoren, så en simulator som leser heading fra bevegelsesfilen og en som leser kurs fra NMEA-filen ser ulike vinkler. Kursen over bakken fra CSV-filen er atan2(v_east, v_north) av hastigheten rotert til nord-øst-ned.
• Høyden følger scenarioet. For gnss-ins er h_m typens egen trinnvise beregning i tangentplanet av referansen sin og holdes ikke konstant (omtrent 7 m over 180 s av automotive-urban-canyon); det er scenarioets bevegelse, skrevet slik den er.
• NMEA-plassholdere i GGA. Posisjonskvalitet (1), brukte satellitter (12) og HDOP (1,0) skrives bare for at setningen skal være velformet. De sier ingenting om scenarioets geometri eller noen mottakertilstand.
• Time: time_s etter epoken, UTC, skuddsekunder er ikke modellert.
• NMEA-høyder er ellipsoidiske. Høyden i GGA inneholder den ellipsoidiske høyden, og geoideseparasjonen skrives som 0,0. En simulator som behandler høyden som høyde over middelhavsnivå, vil plassere kjøretøyet feil med den lokale geoideundulasjonen.
• Rundtur-toleranser (testet ved å lese hver fil tilbake): CSV-posisjon 0,1 mm, bredde- og lengdegrad 1e-9 grad, hastighet 0,1 mm/s, vinkler 1e-6 grad; NMEA horisontal posisjon 5 mm, høyde 1 mm, fart 0,001 knop, kurs 0,001 grad.

Laste filene inn i en simulator#

Laboratoriesimulatorer er forskjellige, og dette depotet gjengir ingen simulators håndbok. Sjekk hvilke av formatene ovenfor din leser, og dens oppgitte krav:

• Mange bevegelsesimportører forventer en fast oppdateringsrate, ofte 10 Hz. Scenarioet gnss-ins går i steg på 0,1 s; for et stasjonært scenario setter du [time] step_s til den raten simulatoren din vil ha.
• Noen importører hopper over sampler som faller mellom hele sekunder, eller ignorerer tidskolonnen og bruker radrekkefølgen. Start bevegelsen på et helt sekund og hold rutenettet regelmessig.
• En CSV-importør der du kan tilordne kolonner, kan lese run1.motion.csv direkte: velg de jordfaste eller geodetiske kolonnene og sett enhetene deres ut fra run1.motion.json. Å kutte desimaler gir falsk akselerasjon, så behold den skrevne presisjonen.
• Filen inneholder bare bevegelse. Sett opp konstellasjonen, interferensen og mottakerens frontend i simulatoren, og tidfest dem mot hendelsene i run1.events.csv.

Kshana skriver ikke noe skriptgrensesnitt for noen leverandør.

Kontrollert mot leserne i én åpen kildekode-simulator

Bevegelsesleserne i gps-sdr-sim (MIT, commit 28ca29a6) fikk eksportene fra åtte medfølgende scenarioer. Hver leser returnerte den eksporterte banen (tests/testbench_gpssdrsim_oracle.rs, forhåndsregistrert i xval/testbench-gpssdrsim/PREREGISTRATION.md):

• Ikke gi -u den fulle bevegelses-CSV-filen. Leseren rommer 100 tegn per linje, og en CSV-rad er omtrent 160 tegn, så hver rad leses som to sampler. Overskriftslinjen leses som ett sampel til uten tall i seg.
• gps-sdr-sim rommer høyst 3000 sampler, 300 s ved den faste raten på 10 Hz, og ignorerer tidskolonnen. Eksportene fra gnss-ins går i steg på nøyaktig 0,1 s. Lengre scenarioer, for eksempel det 20 minutter lange gnss-ins-maritime, leses bare til de første 300 s.
• Dette kontrollerer at filene leses slik de er skrevet. Det kontrollerer ikke scenarioets fysikk eller noe simulatoren sender.

2. Oppgi hva du vil skåre før kjøringen#

Hendelsesfilen gir intervallene scenarioet definerer. Kopier run1.events.toml inn i et receiver-trust-scenario, legg til eventuelle prediksjoner du vil ha kontrollert, og fastsett monitorterskler og toleranser før mottakeren kjører. Ikke juster dem etter å ha sett loggen; scenarioet, tersklene og loggens SHA-256 inngå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 eksporterte hendelsene har scenarioets egen type: jammeren i et jamming-scenario er jamming; et utfall i navigasjonstilstanden er other, fordi scenarioet oppgir at GNSS var utilgjengelig, ikke hvordan. Endre kind slik at det stemmer med det du setter opp simulatoren til å gjøre.

3. Kjør mottakeren#

Start mottakeren og loggeren, start simulatorscenarioet med bevegelsesfilen, og la kjøringen dekke kalibreringsintervallet, hver hendelse og en margin etter den siste. Behold mottakerens egen logg (UBX, RINEX 3-observasjoner, en Android-logger-CSV eller NMEA med setninger for satellittstatus). En logg uten signalstyrke per satellitt kan fortsatt skåres på mottakerens egen posisjon, men monitorene for bærebølge-til-støy trenger den.

4. Synkroniser klokkene#

receiver-trust teller hendelsestidspunkter fra første epoke i mottakerens logg; bevegelsesfilen teller fra sitt første sampel. Hvis loggen starter d sekunder før bevegelsens første sampel, legger du d til hver onset_s og end_s. Noter forskyvningen og hvordan du målte den, og oppgi den i scenarioets name eller i en kommentar, siden en feil forskyvning flytter hver skåring. Hendelsestidspunktene alene kan ikke fortelle deg forskyvningen; bruk simulatorens markør for scenariostart eller mottakerens egne tidsstempler.

5. Skår#

kshana receiver-trust bench-session.toml

skriver bench-session.result.json, .trust.csv og .trust.svg. For hver hendelse oppgir resultatet falske alarmer før starten, den første alarmen og monitorene bak den, forsinkelsen og utfallet (detected, late, missed, not-evaluable), pluss et predikert og observert fall i bærebølge-til-støy der du har oppgitt en prediksjon. Et avvik rapporteres, aldri justert bort. Se RECEIVER-TRUST.md.

For å se hvilke offentlige rammeverksrader økten gir belegg for:

kshana compliance-report bench-session.result.json

Se compliance/README.md. Den rapporten beskriver evidensen i kjøringene du gir den; den gir ingen konklusjon om mottakeren eller noe rammeverk.

6. Knytt rundturen sammen i én signert pakke#

Etter skåringen knytter kshana evidence round-trip de fire registreringene sammen: scenarioet du eksporterte, laboratoriets testbetingelser, mottakerloggen og skåringen. Fyll inn run1.conditions.json (loggens sti og SHA-256, mottakeren under test, hver hendelses type og oppgitte effekt), og kjør deretter:

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 inneholder en round_trip-blokk (kshana.round-trip/1) med scenario_sha256, conditions_hash, log_sha256 og skåringen (hendelser oppdaget av evaluerbare, første alarm), dekket av manifestets hasher og signaturen. Kommandoen avviser en pakke der betingelsene og skåringshendelsene er uenige, eller der den oppgitte loggkontrollsummen ikke er loggens. Som alle bevispakker er den en teknisk registrering, ikke en juridisk vurdering.

Gjennomgått eksempel: gps-sdr-sim som skriver en fil#

Dette eksempelet bruker åpen kildekode-simulatoren gps-sdr-sim bare til å skrive en basebåndfil ut fra den eksporterte bevegelsen. Kshana sender ikke, og ingenting på denne siden automatiserer avspilling av den filen gjennom en radio. Hvis laboratoriet ditt spiller en slik fil inn i en mottaker, er det operatørens ansvar, og skal bare gjøres der det er tillatt (kablet eller skjermet, i henhold til simulatorens og radioens egne sikkerhetsanvisninger); Kshana verken dokumenterer eller pakker inn dette.

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

Det laboratoriet deretter gjør med run1.iq, skjer utenfor Kshana. Mottakerens egen logg, uansett hvordan den er skaffet, er det trinn 5 skårer og trinn 6 knytter sammen. Filene og kontrollene Kshana gjør av sine egne eksporter, er bare testet på syntetiske data (tests/round_trip_pack.rs); ingen laboratoriekjøring påstås her.

Hva denne metoden ikke gjør#

• Den lager ikke et signal, og den sier ikke hvilken interferens en simulator bør generere. Hendelsene sier når, ikke hva.
• Én enkelt økt er ett enkelt datapunkt. Resultatet beskriver den loggen under den konfigurasjonen, og sier ingenting om andre mottakere, firmware, antenner eller ekte interferens.
• Høyder, rater og tidssynkronisering må operatøren selv kontrollere mot simulatoren; eksporten oppgir sine egne konvensjoner og toleranser og ikke mer.