Puntuación de Jammertest: el plan publicado como verdad planificada
kshana jammertest import lee el catálogo de pruebas y el plan de transmisión de Jammertest y convierte las franjas de una zona de pruebas en [[events]] de confianza del receptor. kshana jammertest score hace pasar un registro de receptor por los monitores de confianza y lo puntúa frente a esa planificación, prueba por prueba. Todo resultado es MODELLED: la planificación indica cuándo estaba prevista una prueba, no cuándo estaba encendido un transmisor.
Software de carácter consultivo, no un equipo de navegación homologado (IEC 61108, IEC 61162): el operador sigue siendo responsable de la navegación del buque. Nada de lo aquí expuesto cuenta con el respaldo de la Administración Noruega de Carreteras Públicas, de Nkom ni de los organizadores del evento; no se alega ningún acuerdo con ellos.
El plan y el catálogo#
Fuente: el repositorio NPRA/jammertest-plan de la Administración Noruega de Carreteras Públicas (https://github.com/NPRA/jammertest-plan), con licencia MIT (copyright 2024 Administración Noruega de Carreteras Públicas; el texto de la licencia se comprueba en xval/jammertest-plan/MANIFEST.tsv). Los archivos se descargan, nunca se incorporan al repositorio:
xval/jammertest-plan/fetch.sh <dest-dir-outside-the-repo>Descarga los catálogos y los archivos del plan de 2025 en la confirmación fijada 75c0b2ceea10e470c3799d14a8ef18842d8375a7 y rechaza cualquier archivo cuyo SHA-256 difiera del de xval/jammertest-plan/MANIFEST.tsv.
Una prueba del catálogo tiene un identificador con puntos, type.group.test (por ejemplo 1.2.5: tipo 1 inhibición, grupo 2, prueba 5). El plan indica, por zona de pruebas y franja horaria, qué identificador está programado. Los tipos 1 (jamming), 2 (spoofing) y 3 (meaconing) transmiten; el tipo 0 (reuniones informativas, periodo de gracia, reservas y franjas ad hoc) no transmite y se omite. Las horas del plan son de reloj local; --local-offset-h (por defecto 2, CEST) indica cuánto se alejan del UTC. Los archivos del plan incluyen un campo de contacto de la prueba con el nombre de una persona: nunca se lee, y no se escribe nada derivado de él.
Importación#
kshana jammertest import --catalog testcatalog2025.json \
--plan plan-tuesday-2025-09-16.json --plan plan-wednesday-2025-09-17.json \
--location 1 --log receiver.ubx --format ubx --out events.toml--log-start <UTC time> sustituye a --log/--format cuando el registro no indica su inicio. La salida es TOML [[events]] para añadir a un escenario de confianza del receptor; cada etiqueta empieza por scheduled truth: e incluye el año de edición, el identificador del catálogo y la zona, y la cabecera registra el SHA-256 de cada archivo de origen. --attack-log <scenario.json> lee en su lugar la verdad de eventos de una carpeta del conjunto de datos JammerTest 2024 (su attack_log, con marcas de tiempo desplazadas por --time-shift-h, por defecto -2: dicen Z pero son hora local).
Puntuación#
kshana jammertest score session.toml --catalog testcatalog2025.json --plan plan-....json \
--location 1 [--json] [--key signer.key --out pack/]session.toml es un escenario de confianza del receptor ([log] format/path, con [monitors] y [compare] opcionales). Sus propios [[events]] se sustituyen por la planificación importada. Por cada prueba programada:
| campo | significado |
|---|---|
outcome |
detected (una alarma dentro de compare.detect_tol_s, por defecto 10 s, del inicio previsto), late (más tarde, dentro de la franja), missed (ninguna), not-evaluable |
latency_s |
primera alarma menos inicio previsto |
time_to_recover_s |
desde el final de la franja hasta el inicio del primer tramo de al menos --recover-hold-s (10 s) sin alarma, antes de la prueba siguiente |
Una prueba es puntuable solo si empieza al menos calibration_s + guard_s después del comienzo del registro; un registro con una prueba anterior se marca como baseline_contaminated (la línea base puede haberse formado bajo interferencia). Las falsas alarmas son épocas posteriores a la calibración con alarma, fuera de toda franja ampliada en --guard-s (60 s) antes y después (o después del punto de recuperación), contadas como épocas y como ejecuciones, con ejecuciones por hora de tiempo limpio. Con --key y --out, la ejecución se escribe como un paquete de evidencias firmado (docs/EVIDENCE-PACKS.md): el cuadro de resultados y la planificación importada están dentro de config.json, y por tanto dentro de la cadena de hashes y de la firma. Un paquete es un registro técnico, no un dictamen jurídico.
Lo que un resultado no dice#
- Una franja planificada no es un registro de emisión real. Un transmisor puede haber empezado tarde, haber parado antes o no haber funcionado nunca; una prueba «no detectada» puede ser una prueba que no transmitió, y una latencia se mide desde el inicio previsto.
- Una época «limpia» es «fuera de las franjas planificadas», no «demostrada libre de interferencia».
- La detección por monitores del dominio de la medida no dice nada sobre la detección de un suplantador coherente de baja potencia.
- Ninguna referencia independiente externa indica las horas reales de emisión, por lo que nada de esto es VALIDATED.
La ejecución del conjunto de datos de 2024 (preregistrada)#
xval/jammertest-score/PREREGISTRATION.md fijó la población, las definiciones y los umbrales antes de la primera ejecución puntuada; xval/jammertest-score/RESULTS.md registra esa ejecución. Resultado: la regla registrada de datos mínimos no se satisfizo (4 ventanas de inhibición puntuables procedentes de 4 de las 12 carpetas .ubx: 5 carpetas se descartaron por la regla de la línea base y 3 registros UBX indican su inicio solo como tiempo GPS de la semana), por lo que no se puede evaluar ningún umbral. No se aflojó ni se repitió nada. v2 (PREREGISTRATION-v2.md, confirmada por separado antes de su ejecución; solo tratamiento de datos, los mismos umbrales y la misma regla de datos mínimos) situó los registros con solo tiempo GPS a partir de la fecha de la carpeta, puntuó las 12 carpetas solo con CSV y usó una sesión de plataforma en movimiento para los róveres en movimiento. Resultado (RESULTS-v2.md): se conservaron 14 de 24 carpetas, pero solo 7 ventanas de inhibición puntuables, por lo que la regla de datos mínimos volvió a no satisfacerse y no se puede evaluar ningún umbral. El resultado de v1 no cambia. Solo descriptivo: 3 de 7 ventanas de inhibición dieron alarma en 10 s, 4 más tarde, ninguna sin detectar; latencia mediana 18 s; tasa de alarmas en tiempo limpio 0,089. El límite determinante es ahora la regla de la línea base, que elimina 10 carpetas; un nuevo registro necesitaría una regla distinta para las ventanas tempranas. El conjunto de datos (JammerTest 2024, Zenodo 15911589, GPL-3.0-or-later) se descarga con xval/oracles/setup.sh y nunca se incorpora al repositorio; la prueba tests/jammertest_score_2024.rs fija la ejecución registrada cuando KSHANA_JAMMERTEST_DIR apunta al conjunto de datos extraído.
El conjunto de datos NMEA de SimulaMet de 2025#
El conjunto de datos derivado de NMEA de SimulaMet Jammertest 2025 (IEEE DataPort, DOI 10.21227/a7v4-xw11) no está adaptado en 0,38. Su página no indica ninguna licencia y dice «This dataset requires an IEEE DataPort Subscription to access»: los términos no permiten con claridad la redistribución ni una descarga automatizada, por lo que no se escribió ningún adaptador ni script de descarga. Usarlo requiere la decisión del propietario y, idealmente, el acuerdo por escrito de los autores.
Superficies#
CLI, Rust (kshana::jammertest), Python (jammertest_import, jammertest_score), WebAssembly (los mismos nombres), herramientas MCP con los mismos nombres, y el comando /kshana-jammertest y la skill jammertest. El paquete firmado solo está disponible en la línea de comandos (necesita una clave de firma). Véase docs/SURFACES.md.