Uruchamianie odbiornika na wyeksportowanym scenariuszu

Producent odbiornika, który ma laboratoryjny symulator GNSS, może odtworzyć w nim ruch pojazdu ze scenariusza Kshana, zarejestrować, co robi badany odbiornik, i ocenić ten log poleceniem kshana receiver-trust względem zdarzeń podanych przed przebiegiem. Kshana dostarcza ruch, czasy zdarzeń i ocenę. Nie zapisuje sygnału: nic, co tu eksportowane, nie syntezuje, nie modeluje ani nie nadaje przebiegu radiowego lub w paśmie podstawowym, a wyeksportowane zdarzenie jest oznaczonym przedziałem czasu, a nie przepisem na wytwarzanie zakłóceń. Sygnały dostarczają symulator i jego operator, a operator odpowiada za uruchamianie ich tylko tam, gdzie jest to dozwolone (w układzie przewodowym lub ekranowanym, zgodnie z własnymi instrukcjami bezpieczeństwa symulatora).

Ta strona to metoda. Nie publikuje żadnych wyników.

1. Eksport#

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

Dotyczy rodzaju gnss-ins (profil jazdy z orientacją; zdarzeniami są przerwy stanu nawigacyjnego) oraz jamming i gnss-sim (nieruchomy odbiornik przez czas trwania scenariusza; nadajnik zakłócający w scenariuszu jamming to jedno zdarzenie w całym przebiegu). Inne rodzaje podają, dlaczego nie mają trajektorii pojazdu. --epoch to chwila UTC zerowego czasu ruchu (domyślnie 2024-01-01T00:00:00Z); scenariusze nie mają własnej daty kalendarzowej dla ruchu pojazdu. Musi to być prawdziwa chwila UTC, YYYY-MM-DDTHH:MM:SS (końcowe Z jest akceptowane), z rokiem w zakresie od 2000 do 2099 i każdym polem w zakresie; wszystko inne jest odrzucane. Wynik jest identyczny bajt po bajcie dla tego samego scenariusza i epoki.

Układy współrzędnych i konwencje#

• Pozycja: WGS 84, stała względem Ziemi (ECEF: x przez równik na południku zerowym, z przez biegun); lat_deg, lon_deg, h_m podają tę samą pozycję geodezyjnie, h_m ponad elipsoidą.
• Prędkość: osie stałe względem Ziemi, względem Ziemi.
• Attitude: heading_deg zgodnie z ruchem wskazówek zegara od północy prawdziwej w [0, 360), pitch_deg dodatnie dziobem w górę, roll_deg dodatnie prawym skrzydłem w dół; odchylenie-pochylenie-przechylenie (3-2-1) od lokalnego układu północ-wschód-dół do osi ciała: x do przodu, y w prawo, z w dół. Źródło nieruchome zapisuje zera. NMEA i tekst punktów trasy nie niosą orientacji.
• Kierunek (heading) to odchylenie ciała, a nie kierunek ruchu. W profilu jazdy gnss-ins ciało odchyla się falami prostokątnymi, podczas gdy prędkość podąża za ruchem, więc kierunek (heading) i kurs nad ziemią mogą się różnić o dziesiątki stopni (do około 77 stopni w dołączonym scenariuszu automotive-urban-canyon). Kurs RMC w NMEA to kurs nad ziemią, kierunek wektora prędkości, więc symulator, który czyta heading z pliku ruchu, i taki, który czyta kurs z pliku NMEA, widzą różne kąty. Kurs nad ziemią z CSV to atan2(v_east, v_north) jego prędkości obróconej do układu północ-wschód-dół.
• Wysokość podąża za scenariuszem. Dla gnss-ins wartość h_m pochodzi z własnego krokowania w płaszczyźnie stycznej, wykonywanego przez rodzaj na jego prawdzie, i nie jest stała (około 7 m w ciągu 180 s automotive-urban-canyon); to ruch scenariusza, zapisany takim, jaki jest.
• Wartości zastępcze NMEA GGA. Jakość pozycji (1), liczba użytych satelitów (12) i HDOP (1,0) są zapisywane wyłącznie po to, by zdanie było poprawnie sformułowane. Nic nie mówią o geometrii scenariusza ani o jakimkolwiek stanie odbiornika.
• Time: time_s po epoce, UTC, sekundy przestępne niemodelowane.
• Wysokości NMEA są elipsoidalne. Wysokość GGA zawiera wysokość elipsoidalną, a separacja geoidy jest zapisywana jako 0,0. Symulator, który traktuje wysokość jako wysokość nad średnim poziomem morza, umieści pojazd z błędem równym lokalnej undulacji geoidy.
• Tolerancje odtworzenia (sprawdzone przez odczyt każdego pliku z powrotem): pozycja w CSV 0,1 mm, szerokość i długość geograficzna 1e-9 stopnia, prędkość 0,1 mm/s, kąty 1e-6 stopnia; pozycja pozioma w NMEA 5 mm, wysokość 1 mm, prędkość 0,001 węzła, kurs 0,001 stopnia.

Wczytywanie plików do symulatora#

Symulatory laboratoryjne się różnią, a to repozytorium nie powiela instrukcji żadnego symulatora. Sprawdź, które z powyższych formatów czyta Twój, i jego podane wymagania:

• Wiele importerów ruchu oczekuje stałej częstotliwości aktualizacji, najczęściej 10 Hz. Scenariusz gnss-ins ma krok 0,1 s; dla scenariusza nieruchomego ustaw [time] step_s na częstotliwość, jakiej chce symulator.
• Niektóre importery pomijają próbki przypadające między pełnymi sekundami albo ignorują kolumnę czasu i używają kolejności wierszy. Zacznij ruch w pełnej sekundzie i utrzymuj regularną siatkę.
• Importer CSV, który pozwala mapować kolumny, może czytać run1.motion.csv bezpośrednio: wybierz kolumny stałe względem Ziemi lub geodezyjne i ustaw ich jednostki na podstawie run1.motion.json. Obcinanie miejsc dziesiętnych powoduje fałszywe przyspieszenie, więc zachowaj zapisaną precyzję.
• Plik zawiera wyłącznie ruch. Skonfiguruj konstelację, zakłócenia i tor wejściowy odbiornika w symulatorze i zsynchronizuj je ze zdarzeniami w run1.events.csv.

Kshana nie zapisuje żadnego interfejsu skryptowego dostawców.

Sprawdzone czytnikami jednego symulatora open source

Czytniki ruchu z gps-sdr-sim (MIT, commit 28ca29a6) otrzymały eksporty ośmiu dołączonych scenariuszy. Każdy czytnik zwrócił wyeksportowaną trajektorię (tests/testbench_gpssdrsim_oracle.rs, zarejestrowaną wstępnie w xval/testbench-gpssdrsim/PREREGISTRATION.md):

• Nie podawaj -u pełnego CSV ruchu. Jego czytnik mieści 100 znaków w wierszu, a wiersz CSV ma około 160 znaków, więc każdy wiersz jest czytany jako dwie próbki. Wiersz nagłówka jest czytany jako jeszcze jedna próbka bez żadnych liczb.
• gps-sdr-sim mieści co najwyżej 3000 próbek, czyli 300 s przy stałej częstotliwości 10 Hz, i ignoruje kolumnę czasu. Eksporty gnss-ins mają krok dokładnie 0,1 s. Dłuższe scenariusze, takie jak 20-minutowy gnss-ins-maritime, są czytane tylko do pierwszych 300 s.
• To sprawdza, że pliki są czytane tak, jak zapisano. Nie sprawdza fizyki scenariusza ani niczego, co symulator nadaje.

2. Określ, co będziesz oceniać, przed przebiegiem#

Plik zdarzeń podaje przedziały, które definiuje scenariusz. Skopiuj run1.events.toml do scenariusza receiver-trust, dodaj każdą prognozę, którą chcesz sprawdzić, i ustal progi monitorów oraz tolerancje przed uruchomieniem odbiornika. Nie zmieniaj ich po obejrzeniu logu; scenariusz, progi i SHA-256 logu wchodzą do skrótu wyniku.

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

Wyeksportowane zdarzenia niosą własny rodzaj scenariusza: nadajnik zakłócający w scenariuszu jamming to jamming; przerwa stanu nawigacyjnego to other, ponieważ scenariusz stwierdza, że GNSS był niedostępny, a nie w jaki sposób. Zmień kind tak, aby odpowiadał temu, co skonfigurujesz w symulatorze.

3. Uruchom odbiornik#

Uruchom odbiornik i jego rejestrator, uruchom scenariusz symulatora z plikiem ruchu i niech przebieg obejmie interwał kalibracji, każde zdarzenie oraz zapas po ostatnim. Zachowaj własny log odbiornika (UBX, obserwacje RINEX 3, CSV z rejestratora Androida albo NMEA ze zdaniami stanu satelitów). Log bez natężenia sygnału dla poszczególnych satelitów można nadal ocenić na podstawie własnej pozycji odbiornika, ale monitory stosunku nośnej do szumu go wymagają.

4. Wyrównaj zegary#

receiver-trust liczy czasy zdarzeń od pierwszej epoki logu odbiornika; plik ruchu liczy od swojej pierwszej próbki. Jeśli log zaczyna się d sekund przed pierwszą próbką ruchu, dodaj d do każdego onset_s i end_s. Zapisz przesunięcie i sposób jego pomiaru oraz podaj je w name scenariusza lub w komentarzu, ponieważ błędne przesunięcie zmienia każdą ocenę. Same czasy zdarzeń nie pozwalają ustalić przesunięcia; użyj znacznika początku scenariusza w symulatorze lub własnych znaczników czasu odbiornika.

5. Ocena#

kshana receiver-trust bench-session.toml

zapisuje bench-session.result.json, .trust.csv i .trust.svg. Dla każdego zdarzenia wynik podaje fałszywe alarmy przed początkiem, pierwszy alarm i jego monitory, opóźnienie oraz rezultat (detected, late, missed, not-evaluable), a także przewidywany i zaobserwowany spadek stosunku nośnej do szumu, jeśli podano prognozę. Rozbieżność jest raportowana, a nie wygładzana strojeniem. Zob. RECEIVER-TRUST.md.

Aby zobaczyć, dla których publicznych wierszy ram sesja dostarcza dowodów (supports evidence for):

kshana compliance-report bench-session.result.json

Zob. compliance/README.md. Ten raport opisuje dowody w przebiegach, które mu się poda; nie formułuje żadnego ustalenia o odbiorniku ani o żadnych ramach.

6. Połącz cały obieg w jednym podpisanym pakiecie#

Po ocenie kshana evidence round-trip wiąże ze sobą cztery zapisy: wyeksportowany scenariusz, warunki testu laboratorium, log odbiornika i ocenę. Uzupełnij run1.conditions.json (ścieżkę i SHA-256 logu, badany odbiornik, rodzaj i podaną moc każdego zdarzenia), a następnie:

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 zawiera blok round_trip (kshana.round-trip/1) z scenario_sha256, conditions_hash, log_sha256 i oceną (liczba wykrytych zdarzeń spośród ocenialnych, pierwszy alarm), objęty skrótami manifestu i podpisem. Polecenie odrzuca pakiet, w którym warunki i zdarzenia oceny są ze sobą sprzeczne albo w którym podany skrót logu nie jest skrótem tego logu. Jak każdy pakiet dowodowy jest to zapis techniczny, a nie opinia prawna.

Przykład praktyczny: gps-sdr-sim zapisujący plik#

Ten przykład używa symulatora open source gps-sdr-sim wyłącznie do zapisania pliku pasma podstawowego z wyeksportowanego ruchu. Kshana niczego nie nadaje, a nic na tej stronie nie automatyzuje odtwarzania tego pliku przez radio. Jeśli laboratorium odtwarza taki plik do odbiornika, odpowiada za to jego operator i robi to wyłącznie tam, gdzie jest to dozwolone (w układzie przewodowym lub ekranowanym, według instrukcji bezpieczeństwa symulatora i radia), a Kshana tego ani nie dokumentuje, ani nie obudowuje.

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

Cokolwiek laboratorium zrobi następnie z run1.iq, dzieje się poza Kshana. Własny log odbiornika, uzyskany dowolnie, jest tym, co ocenia krok 5 i łączy krok 6. Pliki i kontrole, które Kshana wykonuje na własnych eksportach, są testowane wyłącznie na danych syntetycznych (tests/round_trip_pack.rs); nie twierdzi się tu żadnego przebiegu laboratoryjnego.

Czego ta metoda nie robi#

• Nie wytwarza sygnału i nie mówi, jakie zakłócenia powinien generować symulator. Zdarzenia mówią kiedy, a nie co.
• Pojedyncza sesja to pojedynczy punkt danych. Wynik opisuje ten log przy tej konfiguracji i nic nie mówi o innych odbiornikach, oprogramowaniu układowym, antenach ani rzeczywistych zakłóceniach.
• Wysokości, szybkości i wyrównanie czasu operator sprawdza względem symulatora; eksport podaje własne konwencje i tolerancje i nic ponadto.