Vastaanottimen ajo viedyllä skenaariolla

Vastaanottimen valmistaja, jolla on laboratorion GNSS-simulaattori, voi toistaa Kshana-skenaarion ajoneuvon liikkeen sen kautta, tallentaa testattavan vastaanottimen toiminnan ja pisteyttää tuon lokin komennolla kshana receiver-trust ennen ajoa ilmoitettuja tapahtumia vastaan. Kshana toimittaa liikkeen, tapahtuma-ajat ja pisteytyksen. Se kirjoittaa ei signaalia: mikään tässä viety ei synteesioi, mallinna tai lähetä radiotaajuista tai kantataajuista aaltomuotoa, ja viety tapahtuma on nimetty aikaväli, ei resepti häiriön tuottamiseen. Simulaattori ja sen käyttäjä toimittavat signaalit, ja käyttäjä vastaa siitä, että niitä ajetaan vain siellä, missä se on sallittua (johdotettuna tai suojattuna, simulaattorin omien turvaohjeiden mukaisesti).

Tämä sivu on menetelmä. Se ei julkaise tuloksia.

1. Vienti#

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

Koskee tyyppiä gnss-ins (ajoprofiili asenteella; navigointitilan katkot ovat tapahtumat) sekä tyyppejä jamming ja gnss-sim (paikallaan oleva vastaanotin skenaarion keston ajan; skenaarion jamming häirintälähetin on yksi tapahtuma ajon yli). Muut tyypit kertovat, miksi niillä ei ole ajoneuvon lentorataa. --epoch on liikkeen aikanollan UTC-hetki (oletus 2024-01-01T00:00:00Z); skenaarioissa ei ole omaa kalenteripäivää ajoneuvon liikkeelle. Sen on oltava todellinen UTC-hetki, YYYY-MM-DDTHH:MM:SS (perässä oleva Z hyväksytään), vuosi välillä 2000-2099 ja jokainen kenttä sallitulla alueella; mikä tahansa muu evätään. Tuloste on tavu tavulta identtinen samalle skenaariolle ja epookille.

Koordinaatistot ja käytännöt#

• Paikka: WGS 84, Maahan kiinnitetty (ECEF: x päiväntasaajan kautta nollameridiaanilla, z navan kautta); lat_deg, lon_deg, h_m antavat saman paikan geodeettisesti, h_m ellipsoidin yläpuolella.
• Nopeus: Maahan kiinnitetyt akselit, suhteessa Maahan.
• Attitude: heading_deg myötäpäivään tosipohjoisesta välillä [0, 360), pitch_deg nokka ylös positiivinen, roll_deg oikea siipi alas positiivinen; kääntö-nousu-kierto (3-2-1) paikallisesta pohjois-itä-alas-koordinaatistosta runkoakseleihin x eteen, y oikealle, z alas. Paikallaan oleva lähde kirjoittaa nollia. NMEA ja reittipisteteksti eivät sisällä asennetta.
• Suunta on rungon kääntökulma, ei kulkusuunta. Ajoprofiilissa gnss-ins runko kääntyy kanttiaaltona nopeuden seuratessa, joten suunta ja maan suhteen kulkusuunta voivat erota kymmenillä asteilla (jopa noin 77 astetta mukana toimitetussa skenaariossa automotive-urban-canyon). NMEA:n RMC kurssi on maan suhteen kulkusuunta, nopeusvektorin suunta, joten simulaattori, joka lukee suunnan liiketiedostosta, ja simulaattori, joka lukee kurssin NMEA-tiedostosta, näkevät eri kulmat. CSV:n maan suhteen kulkusuunta on pohjois-itä-alas-koordinaatistoon käännetyn nopeuden atan2(v_east, v_north).
• Korkeus seuraa skenaariota. Tyypillä gnss-ins arvo h_m on tyypin oman totuutensa tangenttitasoaskeltamista eikä sitä pidetä vakiona (noin 7 m skenaarion automotive-urban-canyon 180 s:n aikana); se on skenaarion liike kirjoitettuna sellaisenaan.
• NMEA-paikkamerkit GGA. Paikannuksen laatu (1), käytetyt satelliitit (12) ja HDOP (1,0) kirjoitetaan vain, jotta lause on hyvin muodostettu. Ne eivät kerro mitään skenaarion geometriasta tai vastaanottimen tilasta.
• Time: time_s epookin jälkeen, UTC, karkaussekunteja ei mallinneta.
• NMEA-korkeudet ovat ellipsoidisia. Kentän GGA korkeus sisältää ellipsoidisen korkeuden ja geoidierotus kirjoitetaan arvona 0,0. Simulaattori, joka käsittelee korkeutta korkeutena keskimerenpinnasta, sijoittaa ajoneuvon väärin paikallisen geoidin aaltoilun verran.
• Edestakaisen luvun toleranssit (testattu lukemalla jokainen tiedosto takaisin): CSV:n paikka 0,1 mm, leveys- ja pituusaste 1e-9 astetta, nopeus 0,1 mm/s, kulmat 1e-6 astetta; NMEA:n vaakapaikka 5 mm, korkeus 1 mm, nopeus 0,001 solmua, kurssi 0,001 astetta.

Tiedostojen lataaminen simulaattoriin#

Laboratoriosimulaattorit eroavat toisistaan, eikä tämä repositorio toista minkään simulaattorin käsikirjaa. Tarkista, mitä yllä olevista muodoista omasi lukee, ja sen ilmoitetut vaatimukset:

• Monet liiketuojat odottavat kiinteää päivitystaajuutta, yleisesti 10 Hz. Skenaario gnss-ins askeltaa 0,1 s:n välein; paikallaan olevassa skenaariossa aseta [time] step_s simulaattorisi haluamaan taajuuteen.
• Jotkin tuojat ohittavat näytteet, jotka osuvat kokonaisten sekuntien väliin, tai jättävät aikasarakkeen huomiotta ja käyttävät rivijärjestystä. Aloita liike kokonaisesta sekunnista ja pidä ruudukko säännöllisenä.
• CSV-tuoja, jonka avulla voi yhdistää sarakkeita, voi lukea tiedoston run1.motion.csv suoraan: valitse Maahan kiinnitetyt tai geodeettiset sarakkeet ja aseta niiden yksiköt tiedostosta run1.motion.json. Desimaalien typistäminen tuottaa väärää kiihtyvyyttä, joten säilytä kirjoitettu tarkkuus.
• Tiedosto sisältää vain liikkeen. Määritä tähdistö, häiriö ja vastaanottimen etupää simulaattorissa ja ajoita ne tiedoston run1.events.csv tapahtumiin.

Kshana ei kirjoita mitään toimittajakohtaista skriptirajapintaa.

Tarkistettu yhden avoimen lähdekoodin simulaattorin lukijoilla

Simulaattorin gps-sdr-sim (MIT, commit 28ca29a6) liikelukijoille annettiin kahdeksan mukana toimitetun skenaarion viennit. Jokainen lukija palautti viedyn lentoradan (tests/testbench_gpssdrsim_oracle.rs, ennakkorekisteröity tiedostossa xval/testbench-gpssdrsim/PREREGISTRATION.md):

• Älä anna asetukselle -u koko liike-CSV:tä. Sen lukija mahtuu 100 merkkiä riville, ja CSV-rivi on noin 160 merkkiä, joten jokainen rivi luetaan kahtena näytteenä. Otsikkorivi luetaan yhtenä lisänäytteenä, jossa ei ole lukuja.
• gps-sdr-sim pitää muistissa enintään 3000 näytettä, 300 s kiinteällä 10 Hz:llä, ja jättää aikasarakkeen huomiotta. Viennit gnss-ins askeltavat täsmälleen 0,1 s:n välein. Pidemmät skenaariot, kuten 20 minuutin gnss-ins-maritime, luetaan vain ensimmäisten 300 s:n osalta.
• Tämä tarkistaa, että tiedostot luetaan sellaisina kuin ne on kirjoitettu. Se ei tarkista skenaarion fysiikkaa eikä mitään, mitä simulaattori lähettää.

2. Ilmoita, mitä pisteytät, ennen ajoa#

Tapahtumatiedosto antaa skenaarion määrittelemät aikavälit. Kopioi run1.events.toml skenaarioon receiver-trust, lisää mikä tahansa ennuste, jonka haluat tarkistettavan, ja kiinnitä monitorien kynnysarvot ja toleranssit ennen kuin vastaanotin ajaa. Älä säädä niitä lokin näkemisen jälkeen; skenaario, kynnysarvot ja lokin SHA-256 ovat kaikki tuloksen tiivisteessä.

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

Viedyt tapahtumat kantavat skenaarion oman tyypin: skenaarion jamming häirintälähetin on jamming; navigointitilan katko on other, koska skenaario ilmoittaa, ettei GNSS ollut saatavilla, mutta ei miten. Muuta kenttä kind vastaamaan sitä, mitä määrität simulaattorin tekemään.

3. Aja vastaanotin#

Käynnistä vastaanotin ja sen kirjaaja, käynnistä simulaattorin skenaario liiketiedostolla ja anna ajon kattaa kalibrointijakso, jokainen tapahtuma ja marginaali viimeisen jälkeen. Säilytä vastaanottimen oma loki (UBX, RINEX 3 -havainnot, Android-kirjaajan CSV tai NMEA satelliittitilalauseineen). Lokin voi silti pisteyttää vastaanottimen oman paikan perusteella, vaikka siinä ei olisi satelliittikohtaista signaalinvoimakkuutta, mutta kantoaalto-kohinasuhteen monitorit tarvitsevat sen.

4. Kohdista kellot#

receiver-trust laskee tapahtuma-ajat vastaanottimen lokin ensimmäisestä epookista; liiketiedosto laskee ensimmäisestä näytteestään. Jos loki alkaa d sekuntia ennen liikkeen ensimmäistä näytettä, lisää d jokaiseen arvoon onset_s ja end_s. Kirjaa siirtymä ja se, miten mittasit sen, ja ilmoita se skenaarion kentässä name tai kommentissa, koska väärä siirtymä siirtää jokaista pistemäärää. Pelkät tapahtuma-ajat eivät kerro siirtymää; käytä simulaattorin skenaarion aloitusmerkkiä tai vastaanottimen omia aikaleimoja.

5. Pisteytä#

kshana receiver-trust bench-session.toml

kirjoittaa bench-session.result.json, .trust.csv ja .trust.svg. Jokaisesta tapahtumasta tulos antaa väärät hälytykset ennen alkua, ensimmäisen hälytyksen ja sen monitorit, viiveen ja lopputuloksen (detected, late, missed, not-evaluable) sekä ennustetun ja havaitun kantoaalto-kohinasuhteen laskun, kun ennuste on ilmoitettu. Ristiriita raportoidaan, ei koskaan säädetä pois. Katso RECEIVER-TRUST.md.

Jos haluat nähdä, mille julkisen viitekehyksen riveille istunto tukee todisteita:

kshana compliance-report bench-session.result.json

Katso compliance/README.md. Tuo raportti kuvaa antamiesi ajojen todisteita; se ei tee havaintoa vastaanottimesta eikä mistään viitekehyksestä.

6. Linkitä edestakainen ajo yhteen allekirjoitettuun pakettiin#

Pisteytyksen jälkeen kshana evidence round-trip sitoo neljä kirjausta yhteen: viemäsi skenaarion, laboratorion testiolosuhteet, vastaanotinlokin ja pisteytyksen. Täytä run1.conditions.json (lokin polku ja SHA-256, testattava vastaanotin, kunkin tapahtuman tyyppi ja ilmoitettu teho), sitten:

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 sisältää lohkon round_trip (kshana.round-trip/1), jossa on scenario_sha256, conditions_hash, log_sha256 ja pisteytys (arvioitavista tapahtumista havaitut, ensimmäinen hälytys), manifestin tiivisteiden ja allekirjoituksen kattamana. Komento kieltäytyy paketista, jonka olosuhteet ja pisteytystapahtumat ovat ristiriidassa tai jonka ilmoitettu lokin tiiviste ei ole lokin tiiviste. Kuten jokainen todistepaketti, se on tekninen kirjaus, ei oikeudellinen lausunto.

Työstetty esimerkki: gps-sdr-sim kirjoittaa tiedoston#

Tämä esimerkki käyttää avoimen lähdekoodin simulaattoria gps-sdr-sim vain kantataajuustiedoston kirjoittamiseen viedystä liikkeestä. Kshana ei lähetä, eikä mikään tällä sivulla automatisoi tuon tiedoston toistamista radion kautta. Jos laboratoriosi toistaa tällaisen tiedoston vastaanottimeen, se on käyttäjäsi vastuulla, tehdään vain siellä, missä se on sallittua (johdotettuna tai suojattuna, simulaattorin ja radion omien turvaohjeiden mukaisesti), ja Kshana ei dokumentoi eikä kääri sitä.

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

Mitä laboratorio sitten tekeekin tiedostolla run1.iq, tapahtuu Kshanan ulkopuolella. Vastaanottimen oma loki, miten se sitten hankitaankin, on se, jonka vaihe 5 pisteyttää ja vaihe 6 linkittää. Tiedostot ja tarkistukset, joita Kshana tekee omille viennilleen, on testattu vain synteettisellä datalla (tests/round_trip_pack.rs); mitään laboratorioajoa ei väitetä tässä.

Mitä tämä menetelmä ei tee#

• Se ei tuota signaalia, eikä se sano, mitä häiriötä simulaattorin pitäisi tuottaa. Tapahtumat kertovat milloin, eivät mitä.
• Yksittäinen istunto on yksittäinen datapiste. Tulos kuvaa tuota lokia tuolla kokoonpanolla, eikä kerro mitään muista vastaanottimista, laiteohjelmistoista, antenneista tai todellisesta häiriöstä.
• Korkeudet, nopeudet ja aikakohdistus on käyttäjän tarkistettava simulaattoria vasten; vienti ilmoittaa omat käytäntönsä ja toleranssinsa eikä muuta.