Запуск приймача проти експортованого сценарію

Виробник приймачів, який має лабораторний симулятор GNSS, може відтворити через нього рух транспортного засобу зі сценарію Kshana, записати, що робить випробовуваний приймач, і оцінити цей журнал за допомогою kshana receiver-trust щодо подій, заявлених до прогону. Kshana надає рух, часи подій і оцінювання. Вона не записує жодного сигналу: ніщо з експортованого тут не синтезує, не моделює і не передає радіочастотну чи базову форму хвилі, а експортована подія — це позначений часовий інтервал, а не рецепт створення завад. Сигнали забезпечують симулятор і його оператор, а оператор відповідає за запуск їх лише там, де це дозволено (кондуктивно або в екрануванні, за власними інструкціями безпеки симулятора).

Ця сторінка описує метод. Вона не публікує результатів.

1. Експорт#

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

Стосується типу gnss-ins (профіль руху з орієнтацією; збої навігаційного стану — це події), а також jamming і gnss-sim (нерухомий приймач протягом тривалості сценарію; джамер сценарію jamming — одна подія протягом прогону). Інші типи пояснюють, чому вони не мають траєкторії транспортного засобу. --epoch — момент UTC нульового часу руху (типово 2024-01-01T00:00:00Z); сценарії не мають власної календарної дати для руху транспортного засобу. Це має бути реальний момент UTC у форматі YYYY-MM-DDTHH:MM:SS (кінцевий Z приймається) з роком від 2000 до 2099 і кожним полем у межах діапазону; усе інше відхиляється. Вихідні дані побайтово ідентичні для того самого сценарію та епохи.

Системи відліку та умовності#

• Позиція: WGS 84, земна фіксована (ECEF: x через екватор на нульовому меридіані, z через полюс); lat_deg, lon_deg, h_m дають ту саму позицію геодезично, h_m над еліпсоїдом.
• Швидкість: земні фіксовані осі, відносно Землі.
• Attitude: heading_deg за годинниковою стрілкою від істинного напряму на північ в [0, 360), pitch_deg носом угору додатний, roll_deg правим крилом униз додатний; рискання-тангаж-крен (3-2-1) від локальної системи північ-схід-униз до осей корпусу: x уперед, y праворуч, z униз. Нерухоме джерело записує нулі. NMEA і текст шляхових точок не містять орієнтації.
• Курс — це рискання корпусу, а не напрям руху. У профілі руху gnss-ins корпус рискає прямокутними хвилями, тоді як швидкість слідує за рухом, тож курс і шляховий кут можуть відрізнятися на десятки градусів (до близько 77 градусів у вбудованому сценарії automotive-urban-canyon). Курс NMEA RMC — це шляховий кут, напрям вектора швидкості, тож симулятор, що читає курс із файлу руху, і той, що читає шляховий кут із файлу NMEA, бачать різні кути. Шляховий кут із CSV — це atan2(v_east, v_north) його швидкості, повернутої до північ-схід-униз.
• Висота відповідає сценарію. Для gnss-ins величина h_m — це власне кроковання типу сценарію в дотичній площині за його істинними даними, і вона не є сталою (близько 7 m за 180 s у automotive-urban-canyon); це рух сценарію, записаний як є.
• Заповнювачі NMEA GGA. Якість розв'язку (1), кількість використаних супутників (12) і HDOP (1,0) записуються лише для того, щоб речення було правильно сформоване. Вони нічого не кажуть про геометрію сценарію чи стан будь-якого приймача.
• Time: time_s після епохи, UTC, зміни секунд не моделюються.
• Висоти NMEA є еліпсоїдальними. Висота GGA містить еліпсоїдальну висоту, а геоїдальне відокремлення записується як 0,0. Симулятор, що розглядає висоту як висоту над середнім рівнем моря, розмістить транспортний засіб із похибкою на місцеву ундуляцію геоїда.
• Допуски кругового обміну (перевіряються зчитуванням кожного файлу назад): позиція CSV 0,1 mm, широта і довгота 1e-9 градуса, швидкість 0,1 mm/s, кути 1e-6 градуса; горизонтальна позиція NMEA 5 mm, висота 1 mm, швидкість 0,001 вузла, курс 0,001 градуса.

Завантаження файлів у симулятор#

Лабораторні симулятори різняться, і цей репозиторій не відтворює посібник жодного симулятора. З'ясуйте, які з наведених вище форматів читає ваш, і його заявлені вимоги:

• Багато імпортерів руху очікують фіксовану частоту оновлення, зазвичай 10 Hz. Сценарій gnss-ins крокує з 0,1 s; для нерухомого сценарію встановіть [time] step_s на частоту, яку хоче ваш симулятор.
• Деякі імпортери пропускають відліки, що припадають між цілими секундами, або ігнорують стовпець часу та використовують порядок рядків. Починайте рух із цілої секунди й зберігайте регулярну сітку.
• Імпортер CSV, що дає змогу зіставляти стовпці, може читати run1.motion.csv безпосередньо: оберіть земні фіксовані або геодезичні стовпці та задайте їхні одиниці з run1.motion.json. Відкидання десяткових знаків породжує хибне прискорення, тож зберігайте записану точність.
• Файл містить лише рух. Налаштуйте орбітальне угруповання, завади та приймальний тракт у симуляторі й узгодьте їх за часом із подіями в run1.events.csv.

Kshana не записує жодного інтерфейсу скриптів постачальника.

Перевірено за читачами одного симулятора з відкритим кодом

Читачам руху gps-sdr-sim (MIT, коміт 28ca29a6) надали експорти восьми вбудованих сценаріїв. Кожен читач повернув експортовану траєкторію (tests/testbench_gpssdrsim_oracle.rs, попередньо зареєстровано в xval/testbench-gpssdrsim/PREREGISTRATION.md):

• Не подавайте -u повний CSV руху. Його читач вміщує 100 символів на рядок, а рядок CSV має близько 160 символів, тож кожен рядок читається як два відліки. Рядок заголовка читається як ще один відлік без жодних чисел.
• gps-sdr-sim вміщує щонайбільше 3000 відліків, тобто 300 s за його фіксованої частоти 10 Hz, і ігнорує стовпець часу. Експорти gnss-ins кроковані рівно з 0,1 s. Довші сценарії, як-от 20-хвилинний gnss-ins-maritime, читаються лише до перших 300 s.
• Це перевіряє, що файли читаються так, як записані. Це не перевіряє фізику сценарію чи будь-що, що передає симулятор.

2. Заявіть, що ви оцінюватимете, до прогону#

Файл подій містить інтервали, які визначає сценарій. Скопіюйте run1.events.toml у сценарій receiver-trust, додайте будь-який прогноз, який хочете перевірити, і зафіксуйте пороги моніторів і допуски до запуску приймача. Не коригуйте їх після перегляду журналу; сценарій, пороги та SHA-256 журналу входять у хеш результату.

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

Експортовані події несуть власний тип сценарію: джамер сценарію jamming — це jamming; збій навігаційного стану — це other, бо сценарій стверджує, що GNSS була недоступна, а не яким способом. Змініть kind відповідно до того, що ви налаштовуєте симулятор робити.

3. Запустіть приймач#

Запустіть приймач і його реєстратор, запустіть сценарій симулятора з файлом руху й нехай прогін охопить інтервал калібрування, кожну подію та запас після останньої. Зберігайте власний журнал приймача (UBX, спостереження RINEX 3, CSV журналу Android або NMEA з реченнями стану супутників). Журнал без потужності сигналу по супутниках усе ще можна оцінити за власною позицією приймача, але монітори відношення несівної до шуму його потребують.

4. Узгодьте годинники#

receiver-trust відлічує часи подій від першої епохи журналу приймача; файл руху відлічує від свого першого відліку. Якщо журнал починається на d секунд раніше за перший відлік руху, додайте d до кожного onset_s і end_s. Запишіть зміщення і спосіб його вимірювання та вкажіть його в name сценарію або в коментарі, бо хибне зміщення зсуває кожну оцінку. Самі часи подій не можуть підказати зміщення; використовуйте маркер початку сценарію симулятора або власні мітки часу приймача.

5. Оцініть#

kshana receiver-trust bench-session.toml

записує bench-session.result.json, .trust.csv і .trust.svg. Для кожної події результат містить хибні тривоги до початку, першу тривогу та її монітори, затримку та підсумок (detected, late, missed, not-evaluable), а також передбачене й спостережене падіння відношення несівної до шуму там, де ви заявили прогноз. Розбіжність повідомляється і ніколи не підганяється. Див. RECEIVER-TRUST.md.

Щоб побачити, які рядки публічних рамок сесія підтримує доказами:

kshana compliance-report bench-session.result.json

Див. compliance/README.md. Цей звіт описує докази в наданих йому прогонах; він не робить жодного висновку про приймач чи будь-яку рамку.

6. З'єднайте круговий обмін в одному підписаному пакеті#

Після оцінювання kshana evidence round-trip зв'язує чотири записи: експортований вами сценарій, умови випробування лабораторії, журнал приймача та оцінку. Заповніть run1.conditions.json (шлях і SHA-256 журналу, випробовуваний приймач, тип і заявлена потужність кожної події), потім:

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 містить блок round_trip (kshana.round-trip/1) з scenario_sha256, conditions_hash, log_sha256 та оцінкою (виявлені події з тих, що піддаються оцінці, перша тривога), що охоплюється хешами маніфесту і підписом. Команда відхиляє пакет, умови якого й події оцінювання розходяться або заявлений хеш журналу не є хешем журналу. Як і кожен пакет доказів, це технічний запис, а не юридичний висновок.

Робочий приклад: gps-sdr-sim записує файл#

Цей приклад використовує симулятор з відкритим кодом gps-sdr-sim лише для того, щоб записати файл у базовій смузі з експортованого руху. Kshana нічого не передає, і ніщо на цій сторінці не автоматизує відтворення цього файлу через радіо. Якщо ваша лабораторія подає такий файл на приймач, це відповідальність вашого оператора, і робиться це лише там, де це дозволено (кабельно або в екрануванні, за інструкціями безпеки симулятора та самого радіо), а Kshana цього ні документує, ні обгортає.

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

Усе, що лабораторія далі робить із run1.iq, відбувається поза Kshana. Власний журнал приймача, як би його не отримали, — це те, що оцінює крок 5 і з'єднує крок 6. Файли та перевірки, які Kshana виконує над власними експортами, випробувано лише на синтетичних даних (tests/round_trip_pack.rs); жодного лабораторного прогону тут не заявлено.

Чого цей метод не робить#

• Він не створює сигналу і не каже, які завади має генерувати симулятор. Події кажуть, коли, а не що.
• Один сеанс — це одна точка даних. Результат описує цей журнал за цієї конфігурації й нічого не каже про інші приймачі, мікропрограми, антени чи реальні завади.
• Висоти, швидкості та вирівнювання часу оператор перевіряє щодо симулятора; експорт заявляє власні умовності й допуски і не більше.