Pontuação do Jammertest: o plano publicado como verdade agendada

kshana jammertest import lê o catálogo de testes e o plano de transmissão do Jammertest e transforma os slots de uma área de teste em [[events]] de confiança do receptor. kshana jammertest score passa um log de receptor pelos monitores de confiança e o pontua contra esse cronograma, teste a teste. Todo resultado é MODELLED: o cronograma diz quando um teste foi planejado, não quando um transmissor estava ligado.

Software de caráter consultivo, não um equipamento de navegação homologado (IEC 61108, IEC 61162): o operador continua responsável pela navegação da embarcação. Nada aqui é endossado pela Norwegian Public Roads Administration, pela Nkom ou pelos organizadores do evento; nenhum acordo com eles é alegado.

Pontuação de um log de receptor sintético contra um cronograma de três testes, a partir de uma execução real do motor v0.40.0 (`kshana jammertest score`). O log é inventado: 1800 s de NMEA com uma queda de 20 dB em C/N0 durante dois intervalos. O cronograma lista três slots; o slot do meio não tem jammer no log. A pontuação marca 2 de 3 testes detectados (latência mediana de 0 s) e 1 perdido, com 0 execuções de falso alarme em 0,25 h de tempo limpo. Nada aqui diz coisa alguma sobre um receptor real. Software de caráter consultivo, não um equipamento de navegação homologado (IEC 61108, IEC 61162): o operador continua responsável pela navegação da embarcação.

O plano e o catálogo#

Fonte: o repositório NPRA/jammertest-plan da Norwegian Public Roads Administration (https://github.com/NPRA/jammertest-plan), licença MIT (copyright 2024 Norwegian Public Roads Administration; o texto da licença é verificado em xval/jammertest-plan/MANIFEST.tsv). Os arquivos são baixados, nunca incorporados ao repositório:

xval/jammertest-plan/fetch.sh <dest-dir-outside-the-repo>

Ele baixa os catálogos e os arquivos do plano de 2025 no commit fixado 75c0b2ceea10e470c3799d14a8ef18842d8375a7 e recusa qualquer arquivo cujo SHA-256 difira de xval/jammertest-plan/MANIFEST.tsv.

Um teste do catálogo tem um id com pontos, type.group.test (por exemplo 1.2.5: tipo 1 jamming, grupo 2, teste 5). O plano lista, por área de teste e slot de tempo, qual id está agendado. Os tipos 1 (jamming), 2 (spoofing) e 3 (meaconing) transmitem; o tipo 0 (briefings, período de tolerância, reservas e slots ad hoc) não transmite e é ignorado. Os horários do plano são o horário local de parede; --local-offset-h (padrão 2, CEST) diz o quanto diferem do UTC. Os arquivos do plano trazem um campo de contato do teste com o nome de uma pessoa: ele nunca é lido, e nada derivado dele é gravado.

Importação#

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> substitui --log/--format quando o log não informa o seu início. A saída é TOML [[events]] para anexar a um cenário de confiança do receptor; cada rótulo começa com scheduled truth: e traz o ano da edição, o id do catálogo e a área, e o cabeçalho registra o SHA-256 de cada arquivo de origem. --attack-log <scenario.json> lê, em vez disso, a verdade de eventos de uma pasta do conjunto de dados JammerTest 2024 (o seu attack_log, com carimbos deslocados por --time-shift-h, padrão -2: eles dizem Z, mas são horário local).

Pontuação#

kshana jammertest score session.toml --catalog testcatalog2025.json --plan plan-....json \
    --location 1 [--json] [--key signer.key --out pack/]

session.toml é um cenário de confiança do receptor ([log] format/path, [monitors] e [compare] opcionais). Os seus próprios [[events]] são substituídos pelo cronograma importado. Por teste agendado:

campo	significado
`outcome`	`detected` (um alarme dentro de `compare.detect_tol_s`, padrão 10 s, do início planejado), `late` (depois, dentro do slot), `missed` (nenhum), `not-evaluable`
`latency_s`	primeiro alarme menos o início planejado
`time_to_recover_s`	do fim do slot até o início do primeiro trecho de pelo menos `--recover-hold-s` (10 s) sem alarme, antes do teste seguinte

Um teste só é pontuável se começar pelo menos calibration_s + guard_s depois do início do log; um log com um teste anterior é sinalizado como baseline_contaminated (a linha de base pode ter sido formada sob interferência). Os falsos alarmes são épocas de alarme pós-calibração fora de todos os slots estendidos por --guard-s (60 s) antes e depois (ou depois do ponto de recuperação), contados como épocas e como execuções, com execuções por hora de tempo limpo. Com --key e --out, a execução é gravada como um pacote de evidências assinado (docs/EVIDENCE-PACKS.md): o placar e o cronograma importado ficam dentro de config.json, portanto dentro da cadeia de hashes e da assinatura. Um pacote é um registro técnico, não uma opinião jurídica.

O que um resultado não diz#

Um slot planejado não é um registro de transmissão no ar. Um transmissor pode ter começado tarde, parado cedo ou nunca ter funcionado; um teste "missed" pode ser um teste que não transmitiu, e uma latência é medida a partir do início planejado.
Uma época "limpa" é "fora dos slots planejados", não "comprovadamente livre de interferência".
A detecção por monitores no domínio da medição não diz nada sobre a detecção de um spoofer coerente de baixa potência.
Nenhuma referência independente externa informa os horários reais no ar, de modo que nada aqui é VALIDATED.

A execução do conjunto de dados de 2024 (pré-registrada)#

xval/jammertest-score/PREREGISTRATION.md fixou a população, as definições e os limiares antes da primeira execução pontuada; xval/jammertest-score/RESULTS.md registra essa execução. Resultado: a regra registrada de dados mínimos falhou (4 janelas de jamming pontuáveis vindas de 4 das 12 pastas .ubx: 5 pastas foram descartadas pela regra da linha de base e 3 logs UBX informam o seu início apenas como tempo da semana GPS), de modo que nenhum limiar é avaliável. Nada foi afrouxado nem reexecutado. A v2 (PREREGISTRATION-v2.md, versionada isoladamente antes da sua execução; apenas tratamento de dados, os mesmos limiares e a mesma regra de dados mínimos) posicionou os logs só com tempo GPS a partir da data da pasta, pontuou as 12 pastas somente com CSV e usou uma sessão de plataforma móvel para os rovers em movimento. Resultado (RESULTS-v2.md): 14 de 24 pastas mantidas, mas apenas 7 janelas de jamming pontuáveis, de modo que a regra de dados mínimos falhou de novo e nenhum limiar é avaliável. O resultado da v1 permanece inalterado. Apenas descritivo: 3 de 7 janelas de jamming deram alarme em até 10 s, 4 depois, nenhuma perdida; latência mediana de 18 s; taxa de alarme limpo de 0,089. O limite determinante agora é a regra da linha de base, que remove 10 pastas; um novo registro exigiria uma regra diferente para as janelas iniciais. O conjunto de dados (JammerTest 2024, Zenodo 15911589, GPL-3.0-or-later) é baixado por xval/oracles/setup.sh e nunca incorporado ao repositório; o teste tests/jammertest_score_2024.rs fixa a execução registrada quando KSHANA_JAMMERTEST_DIR aponta para o conjunto de dados extraído.

O conjunto de dados NMEA SimulaMet de 2025#

O conjunto de dados derivado de NMEA do SimulaMet Jammertest 2025 (IEEE DataPort, DOI 10.21227/a7v4-xw11) não é adaptado na 0,38. A sua página não indica nenhuma licença e diz "This dataset requires an IEEE DataPort Subscription to access": os termos não permitem claramente a redistribuição nem um download automatizado, de modo que nenhum adaptador ou script de download foi escrito. Usá-lo exige a decisão do proprietário e, idealmente, o acordo escrito dos autores.

Superfícies#

CLI, Rust (kshana::jammertest), Python (jammertest_import, jammertest_score), WebAssembly (os mesmos nomes), ferramentas MCP com os mesmos nomes, e o comando /kshana-jammertest e a skill jammertest. O pacote assinado existe apenas na linha de comando (exige uma chave de assinatura). Veja docs/SURFACES.md.