Ejecutar un receptor contra un escenario exportado
Un fabricante de receptores que posea un simulador GNSS de laboratorio puede reproducir con él el movimiento del vehículo de un escenario de Kshana, registrar lo que hace el receptor sometido a ensayo y puntuar ese registro con kshana receiver-trust frente a sucesos declarados antes de la ejecución. Kshana aporta el movimiento, los instantes de los sucesos y la puntuación. No escribe ninguna señal: nada de lo que se exporta aquí sintetiza, modela ni transmite una forma de onda de radiofrecuencia o de banda base, y un suceso exportado es un intervalo de tiempo etiquetado, no una receta para producir interferencia. El simulador y su operador aportan las señales, y el operador es responsable de ejecutarlas solo donde esté autorizado (conducidas o apantalladas, según las propias instrucciones de seguridad del simulador).
Esta página es un método. No publica resultados.
1. Exportar#
kshana bench-export scenarios/gnss-ins.toml --out run1 --epoch 2025-03-01T10:00:00Z
Se aplica al tipo gnss-ins (un perfil de conducción con actitud; los sucesos son las interrupciones del estado de navegación) y a jamming y gnss-sim (un receptor estacionario durante la duración del escenario; el jammer de un escenario jamming es un único suceso a lo largo de la ejecución). Otros tipos explican por qué no tienen trayectoria de vehículo. --epoch es el instante UTC del tiempo cero del movimiento (por defecto 2024-01-01T00:00:00Z); los escenarios no llevan fecha de calendario propia para el movimiento del vehículo. Debe ser un instante UTC real, YYYY-MM-DDTHH:MM:SS (se acepta una Z final) con el año entre 2000 y 2099 y cada campo dentro de rango; cualquier otra cosa se rechaza. La salida es idéntica byte a byte para el mismo escenario y la misma época.
| Archivo | Contenido |
|---|---|
run1.motion.csv |
una fila por muestra: time_s, x_m,y_m,z_m fijas a la Tierra, vx_m_s,vy_m_s,vz_m_s, lat_deg,lon_deg,h_m geodésicas, heading_deg,pitch_deg,roll_deg, utc, kshana_row |
run1.motion.json |
la época, los marcos, las unidades, las columnas y las tolerancias de ida y vuelta de ese CSV |
run1.nmea |
Sentencias NMEA 0183 GGA y RMC por muestra, con sumas de comprobación |
run1.waypoints.txt |
una línea RESOLUTION: <ms> y luego filas longitude,latitude,altitude (se escribe solo cuando todos los intervalos de muestreo son el mismo número entero de milisegundos; si se omite, el comando indica el motivo por la salida de error estándar) |
run1.events.csv |
label,kind,onset_s,end_s,description |
run1.events.toml |
los mismos sucesos como bloques [[events]] para un escenario receiver-trust |
run1.conditions.json |
la ejecución como documento kshana.test-conditions/1 para una grabación receiver-log: los sucesos como verdad declarada, con recording.path, recording.sha256, receiver.*, el type de cada suceso y la potencia que el laboratorio debe rellenar |
Marcos y convenciones#
- Posición: WGS 84, fija a la Tierra (ECEF:
xa través del ecuador en el meridiano de Greenwich,za través del polo);lat_deg,lon_deg,h_mdan la misma posición en forma geodésica,h_msobre el elipsoide. - Velocidad: ejes fijos a la Tierra, relativa a la Tierra.
- Attitude:
heading_degen sentido horario desde el norte verdadero en [0, 360),pitch_degpositivo con el morro hacia arriba,roll_degpositivo con el ala derecha hacia abajo; guiñada-cabeceo-alabeo (3-2-1) desde el marco local norte-este-abajo hasta los ejes del cuerpo x adelante, y derecha, z abajo. Una fuente estacionaria escribe ceros. NMEA y el texto de puntos de ruta no llevan actitud. - El rumbo es la guiñada del cuerpo, no la dirección de desplazamiento. En el perfil de conducción
gnss-insel cuerpo guiña en ondas cuadradas mientras la velocidad sigue su curso, de modo que el rumbo y el rumbo sobre el suelo pueden diferir en decenas de grados (hasta unos 77 grados en el escenario incluidoautomotive-urban-canyon). El rumboRMCde NMEA es el rumbo sobre el suelo, la dirección del vector de velocidad, de modo que un simulador que lea el rumbo del archivo de movimiento y otro que lea el rumbo del archivo NMEA ven ángulos distintos. El rumbo sobre el suelo del CSV esatan2(v_east, v_north)de su velocidad rotada a norte-este-abajo. - La altura sigue al escenario. Para
gnss-ins,h_mes el avance propio del tipo en plano tangente de su verdad y no se mantiene constante (unos 7 m a lo largo de los 180 s deautomotive-urban-canyon); es el movimiento del escenario, escrito tal cual. - Valores de relleno de NMEA
GGA. La calidad de posición (1), los satélites usados (12) y el HDOP (1,0) se escriben solo para que la sentencia esté bien formada. No dicen nada sobre la geometría del escenario ni sobre ningún estado del receptor. - Time:
time_stras la época, UTC, sin modelar los segundos intercalares. - Las alturas NMEA son elipsoidales. La altitud de
GGAcontiene la altura elipsoidal y la separación del geoide se escribe como 0,0. Un simulador que trate la altitud como altura sobre el nivel medio del mar situará el vehículo desviado en la ondulación local del geoide. - Tolerancias de ida y vuelta (comprobadas leyendo de nuevo cada archivo): posición del CSV 0,1 mm, latitud y longitud 1e-9 grados, velocidad 0,1 mm/s, ángulos 1e-6 grados; posición horizontal de NMEA 5 mm, altura 1 mm, velocidad 0,001 nudos, rumbo 0,001 grados.
Carga de los archivos en un simulador#
Los simuladores de laboratorio difieren, y este repositorio no reproduce el manual de ningún simulador. Compruebe cuál de los formatos anteriores lee el suyo, y sus requisitos declarados:
- Muchos importadores de movimiento esperan una tasa de actualización fija, habitualmente de 10 Hz. El escenario
gnss-insavanza a 0,1 s; para un escenario estacionario, fije[time] step_sa la tasa que quiera su simulador. - Algunos importadores omiten las muestras que caen entre segundos enteros, o ignoran la columna de tiempo y usan el orden de las filas. Inicie el movimiento en un segundo entero y mantenga la rejilla regular.
- Un importador de CSV que permita asignar columnas puede leer
run1.motion.csvdirectamente: elija las columnas fijas a la Tierra o geodésicas y fije sus unidades a partir derun1.motion.json. Truncar los decimales produce una aceleración falsa, de modo que conserve la precisión escrita. - El archivo es solo de movimiento. Configure la constelación, la interferencia y el extremo frontal del receptor en el simulador, y sincronícelos con los sucesos de
run1.events.csv.
Kshana no escribe ninguna interfaz de scripts de fabricante.
Comprobado con los lectores de un simulador de código abierto
Los lectores de movimiento de gps-sdr-sim (MIT, commit 28ca29a6) recibieron las exportaciones de ocho escenarios incluidos. Cada lector devolvió la trayectoria exportada (tests/testbench_gpssdrsim_oracle.rs, preregistrado en xval/testbench-gpssdrsim/PREREGISTRATION.md):
| Opción de gps-sdr-sim | Entrada que se le da | Peor diferencia respecto al CSV |
|---|---|---|
-g (NMEA GGA) |
run1.nmea tal como está escrito |
1,2 mm |
-x (tiempo, latitud, longitud, altura) |
tail -n +2 run1.motion.csv | cut -d, -f1,8,9,10 |
0,15 mm |
-u (tiempo, x, y, z) |
tail -n +2 run1.motion.csv | cut -d, -f1-4 |
exacto |
- No dé a
-uel CSV de movimiento completo. Su lector admite 100 caracteres por línea, y una fila del CSV tiene unos 160 caracteres, de modo que cada fila se lee como dos muestras. La línea de encabezado se lee como una muestra más sin números. - gps-sdr-sim admite como máximo 3000 muestras, 300 s a su 10 Hz fijos, e ignora la columna de tiempo. Las exportaciones de
gnss-insavanzan exactamente a 0,1 s. Los escenarios más largos, comognss-ins-maritimede 20 minutos, solo se leen hasta sus primeros 300 s. - Esto comprueba que los archivos se leen tal como están escritos. No comprueba la física del escenario ni nada de lo que transmite el simulador.
2. Declare lo que va a puntuar antes de la ejecución#
El archivo de sucesos da los intervalos que define el escenario. Copie run1.events.toml en un escenario receiver-trust, añada cualquier predicción que quiera comprobar y fije los umbrales de los monitores y las tolerancias antes de que se ejecute el receptor. No los ajuste tras ver el registro; el escenario, los umbrales y el SHA-256 del registro están todos en el hash del resultado.
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
Los sucesos exportados llevan el propio tipo de escenario: el jammer de un escenario jamming es jamming; una interrupción del estado de navegación es other, porque el escenario declara que GNSS no estaba disponible, no cómo. Cambie el kind para que coincida con lo que configure que haga el simulador.
3. Ejecute el receptor#
Inicie el receptor y su registrador, inicie el escenario del simulador con el archivo de movimiento y deje que la ejecución abarque el intervalo de calibración, cada suceso y un margen tras el último. Conserve el registro propio del receptor (UBX, observaciones RINEX 3, un CSV de registrador de Android o NMEA con sentencias de estado de satélites). Un registro sin intensidad de señal por satélite aún puede puntuarse sobre la posición del propio receptor, pero los monitores de relación portadora/ruido la necesitan.
4. Alinee los relojes#
receiver-trust cuenta los instantes de los sucesos desde la primera época del registro del receptor; el archivo de movimiento cuenta desde su primera muestra. Si el registro empieza d segundos antes de la primera muestra del movimiento, añada d a cada onset_s y end_s. Registre el desfase y cómo lo midió, y declárelo en el name del escenario o en un comentario, ya que un desfase erróneo desplaza cada puntuación. Los instantes de los sucesos por sí solos no permiten conocer el desfase; use el marcador de inicio de escenario del simulador o las propias marcas de tiempo del receptor.
5. Puntúe#
kshana receiver-trust bench-session.toml
escribe bench-session.result.json, .trust.csv y .trust.svg. Para cada suceso, el resultado da las falsas alarmas antes del inicio, la primera alarma y sus monitores, la latencia y el desenlace (detected, late, missed, not-evaluable), además de una caída prevista y otra observada de la relación portadora/ruido donde usted declaró una predicción. Un desacuerdo se informa, nunca se ajusta para eliminarlo. Véase RECEIVER-TRUST.md.
Para ver a qué filas de marcos públicos aporta evidencias a favor la sesión:
kshana compliance-report bench-session.result.json
Véase compliance/README.md. Ese informe describe las evidencias de las ejecuciones que se le dan; no formula ninguna conclusión sobre el receptor ni sobre ningún marco.
6. Vincule la ida y vuelta en un único paquete firmado#
Tras puntuar, kshana evidence round-trip une los cuatro registros: el escenario que exportó, las condiciones de ensayo del laboratorio, el registro del receptor y la puntuación. Rellene run1.conditions.json (la ruta y el SHA-256 del registro, el receptor sometido a ensayo, el tipo y la potencia declarada de cada suceso) y, después:
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 lleva un bloque round_trip (kshana.round-trip/1) con scenario_sha256, conditions_hash, log_sha256 y la puntuación (sucesos detectados de los evaluables, primera alarma), cubierto por los hashes del manifiesto y por la firma. El comando rechaza un paquete cuyas condiciones y sucesos de puntuación no coinciden, o cuyo hash de registro declarado no es el del registro. Como todo paquete de evidencias, es un registro técnico, no un dictamen jurídico.
Ejemplo práctico: gps-sdr-sim escribiendo un archivo#
Este ejemplo usa el simulador de código abierto gps-sdr-sim solo para escribir un archivo de banda base a partir del movimiento exportado. Kshana no transmite, y nada de esta página automatiza la reproducción de ese archivo a través de una radio. Si su laboratorio reproduce un archivo así en un receptor, es responsabilidad de su operador, y se hace solo donde esté autorizado (por cable o apantallado, siguiendo las propias instrucciones de seguridad del simulador y de la radio); Kshana ni lo documenta ni lo envuelve.
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
Lo que haga después el laboratorio con run1.iq ocurre fuera de Kshana. El propio registro del receptor, se obtenga como se obtenga, es lo que puntúa el paso 5 y vincula el paso 6. Los archivos y las comprobaciones que Kshana hace sobre sus propias exportaciones se prueban solo con datos sintéticos (tests/round_trip_pack.rs); aquí no se afirma ninguna ejecución de laboratorio.
Lo que este método no hace#
- No produce una señal, y no dice qué interferencia debe generar un simulador. Los sucesos dicen cuándo, no qué.
- Una sola sesión es un único dato. El resultado describe ese registro con esa configuración, y no dice nada sobre otros receptores, firmware, antenas ni interferencia real.
- Las alturas, las tasas y la alineación temporal corresponde comprobarlas al operador frente al simulador; la exportación declara sus propias convenciones y tolerancias, y nada más.