Pontuação do Jammertest: o plano publicado como referência calendarizada

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 receiver-trust. kshana jammertest score passa um registo de recetor pelos monitores de confiança e pontua-o face a esse calendário, teste a teste. Todos os resultados são MODELLED: o calendário indica quando um teste estava planeado, não quando um transmissor esteve ligado.

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

Pontuação de um registo sintético de recetor face a um calendário de três testes, a partir de uma execução real do motor v0.40.0 (`kshana jammertest score`). O registo é inventado: 1800 s de NMEA com uma queda de C/N0 de 20 dB em dois intervalos. O calendário enumera três slots; o slot do meio não tem jammer no registo. A pontuação marca 2 de 3 testes detetados (latência mediana de 0 s) e 1 falhado, com 0 execuções de falso alarme ao longo de 0,25 h de tempo limpo. Nada aqui diz seja o que for sobre um recetor real. Software de caráter consultivo, não um equipamento de navegação homologado (IEC 61108, IEC 61162): o operador continua a ser 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 (direitos de autor 2024 Norwegian Public Roads Administration; o texto da licença é verificado em xval/jammertest-plan/MANIFEST.tsv). Os ficheiros são obtidos, nunca incluídos no repositório:

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

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

Um teste do catálogo tem um identificador com pontos, type.group.test (por exemplo 1.2.5: tipo 1 jamming, grupo 2, teste 5). O plano indica, por área de teste e por slot de tempo, que identificador está agendado. Os tipos 1 (jamming), 2 (spoofing) e 3 (meaconing) transmitem; o tipo 0 (sessões informativas, período de tolerância, reservas e slots ad hoc) não transmite e é ignorado. As horas do plano são horas locais de relógio; --local-offset-h (por predefinição 2, CEST) indica quanto distam do UTC. Os ficheiros do plano contêm um campo de contacto de teste com o nome de uma pessoa: nunca é lido, e nada derivado dele é escrito.

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 registo não indica o seu início. A saída é TOML [[events]] para acrescentar a um cenário receiver-trust; cada etiqueta começa por scheduled truth: e inclui o ano da edição, o identificador do catálogo e a área, e o cabeçalho regista o SHA-256 de cada ficheiro de origem. --attack-log <scenario.json> lê antes a referência de eventos de uma pasta do conjunto de dados JammerTest 2024 (o seu attack_log, com marcas temporais deslocadas por --time-shift-h, por predefinição -2: dizem Z mas são hora 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 receiver-trust ([log] format/path, [monitors] e [compare] opcionais). Os seus próprios [[events]] são substituídos pelo calendário importado. Por teste agendado:

campo	significado
`outcome`	`detected` (um alarme dentro de `compare.detect_tol_s`, por predefinição 10 s, do início planeado), `late` (mais tarde, dentro do slot), `missed` (nenhum), `not-evaluable`
`latency_s`	primeiro alarme menos início planeado
`time_to_recover_s`	do fim do slot ao início do primeiro período 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 de o registo ter começado; um registo com um teste anterior é assinalado como baseline_contaminated (a linha de base pode ter-se formado sob interferência). Os falsos alarmes são épocas em alarme após a calibração fora de cada slot, prolongado 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 é escrita como um pacote de evidências assinado (docs/EVIDENCE-PACKS.md): a folha de pontuação e o calendário importado ficam dentro de config.json, logo dentro da cadeia de hashes e da assinatura. Um pacote é um registo técnico, não um parecer jurídico.

O que um resultado não diz#

Um slot planeado não é um registo de emissão. Um transmissor pode ter começado tarde, parado cedo ou nunca ter funcionado; um teste "falhado" pode ser um teste que não transmitiu, e uma latência conta-se a partir do início planeado.
Uma época "limpa" é uma época "fora dos slots planeados", não "comprovadamente sem interferência".
A deteção por monitores no domínio da medição não diz nada sobre a deteção de um spoofer coerente de baixa potência.
Nenhuma referência independente externa indica as horas reais de emissão, pelo que nada aqui é VALIDATED.

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

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 regista essa execução. Resultado: a regra registada de dados mínimos falhou (4 janelas de jamming pontuáveis de 4 das 12 pastas .ubx: 5 pastas foram descartadas pela regra da linha de base e 3 registos UBX indicam o seu início apenas como tempo GPS da semana), pelo que nenhum limiar é avaliável. Nada foi afrouxado nem voltou a ser executado. A v2 (PREREGISTRATION-v2.md, submetida sozinha antes da sua execução; apenas tratamento de dados, mesmos limiares e mesma regra de dados mínimos) colocou os registos só com tempo GPS a partir da data da pasta, pontuou as 12 pastas só com CSV e usou uma sessão de plataforma em movimento para os rovers em movimento. Resultado (RESULTS-v2.md): 14 de 24 pastas mantidas mas apenas 7 janelas de jamming pontuáveis, pelo que a regra de dados mínimos voltou a falhar e nenhum limiar é avaliável. O resultado da v1 não se altera. Apenas descritivo: 3 de 7 janelas de jamming deram alarme em 10 s, 4 mais tarde, nenhuma falhada; latência mediana de 18 s; taxa de alarmes em tempo limpo de 0,089. O limite determinante é agora a regra da linha de base, que remove 10 pastas; um novo registo exigiria uma regra diferente para as janelas iniciais. O conjunto de dados (JammerTest 2024, Zenodo 15911589, GPL-3.0-or-later) é obtido por xval/oracles/setup.sh e nunca incluído no repositório; o teste tests/jammertest_score_2024.rs fixa a execução registada quando KSHANA_JAMMERTEST_DIR aponta para o conjunto de dados extraído.

O conjunto de dados NMEA da SimulaMet de 2025#

O conjunto de dados derivado de NMEA do Jammertest 2025 da SimulaMet (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 uma obtenção automática, pelo que não foi escrito nenhum adaptador nem script de obtenção. A sua utilização exige a decisão do titular 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 é só de linha de comandos (precisa de uma chave de assinatura). Ver docs/SURFACES.md.