Запуск приёмника против экспортированного сценария

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

Эта страница описывает метод. Результатов она не публикует.

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). Курс RMC в NMEA — это путевой угол, то есть направление вектора скорости, поэтому симулятор, который читает курс из файла движения, и симулятор, который читает путевой угол из файла NMEA, видят разные углы. Путевой угол из CSV — это atan2(v_east, v_north) его скорости, повёрнутой в систему «север–восток–вниз».
• Высота следует сценарию. Для gnss-ins величина h_m — это собственное шаговое движение вида по касательной плоскости над его истиной, и она не считается постоянной (около 7 м за 180 с automotive-urban-canyon); это движение сценария, записанное как есть.
• Заглушки NMEA GGA. Качество решения (1), число используемых спутников (12) и HDOP (1,0) записываются только для того, чтобы предложение было корректно сформировано. Они ничего не говорят ни о геометрии сценария, ни о состоянии какого-либо приёмника.
• Time: time_s после момента отсчёта, UTC, високосные секунды не моделируются.
• Высоты в NMEA эллипсоидальные. Высота в GGA содержит эллипсоидальную высоту, а разделение геоида записывается как 0,0. Симулятор, который считает высоту превышением над средним уровнем моря, расположит транспортное средство со смещением на местную ундуляцию геоида.
• Допуски кругового преобразования (проверяются чтением каждого файла обратно): положение в CSV 0,1 мм, широта и долгота 1e-9 градуса, скорость 0,1 мм/с, углы 1e-6 градуса; горизонтальное положение в NMEA 5 мм, высота 1 мм, скорость 0,001 узла, путевой угол 0,001 градуса.

Загрузка файлов в симулятор#

Лабораторные симуляторы различаются, и этот репозиторий не воспроизводит руководство какого-либо симулятора. Проверьте, какие из перечисленных выше форматов читает ваш симулятор, и его заявленные требования:

• Многие импортёры движения ожидают фиксированную частоту обновления, обычно 10 Гц. Сценарий gnss-ins идёт с шагом 0,1 с; для неподвижного сценария задайте [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 с при фиксированных 10 Гц, и игнорирует столбец времени. Экспорты gnss-ins идут ровно с шагом 0,1 с. Более длинные сценарии, такие как 20-минутный gnss-ins-maritime, читаются только до первых 300 с.
• Это проверяет, что файлы читаются как записано. Оно не проверяет физику сценария или что-либо из того, что передаёт симулятор.

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 используется только для того, чтобы записать файл baseband из экспортированного движения. 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); никакой лабораторный прогон здесь не заявляется.

Чего этот метод не делает#

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