Executar um recetor contra um cenário exportado

Um fabricante de recetores que possua um simulador GNSS de laboratório pode reproduzir através dele o movimento do veículo de um cenário Kshana, registar o que o recetor em ensaio faz e pontuar esse registo com kshana receiver-trust face a eventos declarados antes da execução. O Kshana fornece o movimento, os instantes dos eventos e a pontuação. Não escreve nenhum sinal: nada do que aqui se exporta sintetiza, modela ou transmite uma forma de onda de radiofrequência ou de banda de base, e um evento exportado é um intervalo de tempo etiquetado, não uma receita para produzir interferência. O simulador e o seu operador fornecem os sinais, e o operador é responsável por os executar apenas onde isso seja autorizado (por condução ou em blindagem, segundo as instruções de segurança do próprio simulador).

Esta página é um método. Não publica resultados.

1. Exportar#

kshana bench-export scenarios/gnss-ins.toml --out run1 --epoch 2025-03-01T10:00:00Z

Aplica-se ao tipo de cenário gnss-ins (um perfil de condução com atitude; as interrupções do estado de navegação são os eventos) e a jamming e gnss-sim (um recetor estacionário durante a duração do cenário; o emissor de interferência de um cenário jamming é um único evento ao longo da execução). Os outros tipos de cenário explicam porque não têm trajetória de veículo. --epoch é o instante UTC do tempo zero do movimento (por predefinição 2024-01-01T00:00:00Z); os cenários não têm data de calendário própria para o movimento do veículo. Tem de ser um instante UTC real, YYYY-MM-DDTHH:MM:SS (um Z final é aceite) com o ano entre 2000 e 2099 e todos os campos dentro do intervalo; qualquer outra coisa é refused. A saída é idêntica byte a byte para o mesmo cenário e época.

Referenciais e convenções#

• Posição: WGS 84, fixa à Terra (ECEF: x através do equador no meridiano de Greenwich, z através do polo); lat_deg, lon_deg, h_m dão a mesma posição em termos geodésicos, h_m acima do elipsoide.
• Velocidade: eixos fixos à Terra, relativamente à Terra.
• Attitude: heading_deg no sentido horário a partir do norte verdadeiro em [0, 360), pitch_deg positivo com o nariz para cima, roll_deg positivo com a asa direita para baixo; guinada-arfagem-rolamento (3-2-1) do referencial local norte-este-baixo para os eixos do corpo x para a frente, y para a direita, z para baixo. Uma fonte estacionária escreve zeros. O NMEA e o texto dos pontos de passagem não contêm atitude.
• O rumo é a guinada do corpo, não a direção de deslocação. No perfil de condução gnss-ins, o corpo guina em ondas quadradas enquanto a velocidade segue, pelo que o rumo e o curso sobre o solo podem diferir em dezenas de graus (até cerca de 77 graus no cenário incluído automotive-urban-canyon). O curso NMEA RMC é o curso sobre o solo, a direção do vetor velocidade, pelo que um simulador que leia o rumo do ficheiro de movimento e outro que leia o curso do ficheiro NMEA veem ângulos diferentes. O curso sobre o solo do CSV é atan2(v_east, v_north) da sua velocidade rodada para norte-este-baixo.
• A altura segue o cenário. Para gnss-ins, h_m é o avanço próprio do tipo de cenário no plano tangente da sua referência e não é mantido constante (cerca de 7 m ao longo dos 180 s de automotive-urban-canyon); é o movimento do cenário, escrito tal como é.
• Marcadores de posição NMEA GGA. A qualidade da solução de posição (1), os satélites utilizados (12) e o HDOP (1,0) são escritos apenas para que a frase fique bem formada. Não dizem nada sobre a geometria do cenário nem sobre qualquer estado do recetor.
• Time: time_s após a época, UTC, segundos intercalares não modelados.
• As alturas NMEA são elipsoidais. A altitude GGA contém a altura elipsoidal e a separação do geoide é escrita como 0,0. Um simulador que trate a altitude como altura acima do nível médio do mar colocará o veículo desviado da ondulação local do geoide.
• Tolerâncias de ida e volta (testadas ao reler cada ficheiro): posição CSV 0,1 mm, latitude e longitude 1e-9 grau, velocidade 0,1 mm/s, ângulos 1e-6 grau; posição horizontal NMEA 5 mm, altura 1 mm, velocidade 0,001 nó, curso 0,001 grau.

Carregar os ficheiros num simulador#

Os simuladores de laboratório diferem, e este repositório não reproduz o manual de nenhum simulador. Verifique quais dos formatos acima o seu lê, e os requisitos que indica:

• Muitos importadores de movimento esperam uma taxa de atualização fixa, habitualmente de 10 Hz. O cenário gnss-ins avança a 0,1 s; para um cenário estacionário, defina [time] step_s para a taxa que o seu simulador pretende.
• Alguns importadores saltam amostras que caem entre segundos inteiros, ou ignoram a coluna de tempo e usam a ordem das linhas. Inicie o movimento num segundo inteiro e mantenha a grelha regular.
• Um importador de CSV que permita mapear colunas pode ler run1.motion.csv diretamente: escolha as colunas fixas à Terra ou geodésicas e defina as respetivas unidades a partir de run1.motion.json. Truncar as casas decimais produz aceleração falsa, pelo que se deve manter a precisão escrita.
• O ficheiro contém apenas movimento. Configure a constelação, a interferência e o front end do recetor no simulador, e sincronize-os com os eventos em run1.events.csv.

O Kshana não escreve nenhuma interface de scripts de fabricante.

Verificado com os leitores de um simulador de código aberto

Os leitores de movimento do gps-sdr-sim (MIT, commit 28ca29a6) receberam as exportações de oito cenários incluídos. Cada leitor devolveu a trajetória exportada (tests/testbench_gpssdrsim_oracle.rs, pré-registada em xval/testbench-gpssdrsim/PREREGISTRATION.md):

• Não forneça a -u o CSV de movimento completo. O seu leitor comporta 100 carateres por linha, e uma linha de CSV tem cerca de 160 carateres, pelo que cada linha é lida como duas amostras. A linha de cabeçalho é lida como mais uma amostra sem números.
• O gps-sdr-sim comporta no máximo 3000 amostras, 300 s a 10 Hz fixos, e ignora a coluna de tempo. As exportações gnss-ins avançam exatamente a 0,1 s. Os cenários mais longos, como o gnss-ins-maritime de 20 minutos, são lidos apenas até aos primeiros 300 s.
• Isto verifica que os ficheiros são lidos tal como foram escritos. Não verifica a física do cenário nem nada do que o simulador transmite.

2. Declarar o que se vai pontuar antes da execução#

O ficheiro de eventos indica os intervalos que o cenário define. Copie run1.events.toml para um cenário receiver-trust, acrescente qualquer previsão que pretenda ver verificada e fixe os limiares do monitor e as tolerâncias antes de o recetor ser executado. Não os ajuste depois de ver o registo; o cenário, os limiares e o SHA-256 do registo constam todos do hash do 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

Os eventos exportados trazem o tipo próprio do cenário: o emissor de interferência de um cenário jamming é jamming; uma interrupção do estado de navegação é other, porque o cenário declara que o GNSS estava indisponível, não como. Altere kind para corresponder ao que configurar o simulador para fazer.

3. Executar o recetor#

Inicie o recetor e o seu registador, inicie o cenário do simulador com o ficheiro de movimento e deixe que a execução cubra o intervalo de calibração, todos os eventos e uma margem após o último. Conserve o registo do próprio recetor (UBX, observações RINEX 3, um CSV de registador Android, ou NMEA com frases de estado dos satélites). Um registo sem intensidade de sinal por satélite pode ainda ser pontuado com base na posição do próprio recetor, mas os monitores de portadora-ruído precisam dela.

4. Alinhar os relógios#

receiver-trust conta os instantes dos eventos a partir da primeira época do registo do recetor; o ficheiro de movimento conta a partir da sua primeira amostra. Se o registo começar d segundos antes da primeira amostra do movimento, some d a cada onset_s e end_s. Registe o desfasamento e a forma como o mediu, e indique-o em name do cenário ou num comentário, uma vez que um desfasamento errado desloca todas as pontuações. Os instantes dos eventos, por si só, não permitem conhecer o desfasamento; utilize o marcador de início de cenário do simulador ou as marcas temporais do próprio recetor.

5. Pontuar#

kshana receiver-trust bench-session.toml

escreve bench-session.result.json, .trust.csv e .trust.svg. Para cada evento, o resultado indica os falsos alarmes antes do início, o primeiro alarme e os seus monitores, a latência e o desfecho (detected, late, missed, not-evaluable), além de uma descida prevista e observada da relação portadora-ruído quando declarou uma previsão. Uma discordância é comunicada, nunca ajustada para desaparecer. Ver RECEIVER-TRUST.md.

Para ver as linhas de referenciais públicos para as quais a sessão fornece elementos de prova em apoio de:

kshana compliance-report bench-session.result.json

Ver compliance/README.md. Esse relatório descreve as evidências nas execuções que lhe forem fornecidas; não faz nenhuma apreciação sobre o recetor nem sobre qualquer referencial.

6. Ligar a ida e volta num único pacote assinado#

Após a pontuação, kshana evidence round-trip liga os quatro registos: o cenário que exportou, as condições de ensaio do laboratório, o registo do recetor e a pontuação. Preencha run1.conditions.json (o caminho e o SHA-256 do registo, o recetor em ensaio, o tipo e a potência declarada de cada evento) e depois:

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 contém um bloco round_trip (kshana.round-trip/1) com scenario_sha256, conditions_hash, log_sha256 e a pontuação (eventos detetados entre os avaliáveis, primeiro alarme), abrangido pelos hashes do manifesto e pela assinatura. O comando recusa um pacote cujas condições e eventos de pontuação discordem, ou cujo hash do registo indicado não seja o do registo. Como qualquer pacote de evidências, é um registo técnico, não um parecer jurídico.

Exemplo prático: o gps-sdr-sim a escrever um ficheiro#

Este exemplo utiliza o simulador de código aberto gps-sdr-sim apenas para escrever um ficheiro de banda de base a partir do movimento exportado. O Kshana não transmite, e nada nesta página automatiza a reprodução desse ficheiro através de um rádio. Se o seu laboratório reproduzir tal ficheiro num recetor, isso é da responsabilidade do operador, feito apenas onde seja autorizado (por cabo ou em blindagem, seguindo as instruções de segurança do simulador e do rádio), e o Kshana nem o documenta nem o encapsula.

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

Tudo o que o laboratório fizer depois com run1.iq acontece fora do Kshana. O registo do próprio recetor, seja como for obtido, é o que o passo 5 pontua e o passo 6 liga. Os ficheiros e as verificações que o Kshana faz às suas próprias exportações são testados apenas com dados sintéticos (tests/round_trip_pack.rs); aqui não se alega nenhuma execução em laboratório.

O que este método não faz#

• Não produz um sinal, e não diz que interferência um simulador deve gerar. Os eventos dizem quando, não o quê.
• Uma única sessão é um único ponto de dados. O resultado descreve esse registo nessa configuração, e não diz nada sobre outros recetores, firmware, antenas ou interferência real.
• As alturas, as taxas e o alinhamento temporal cabem ao operador verificar face ao simulador; a exportação indica as suas próprias convenções e tolerâncias e nada mais.