• Ensaiar o minuto em que o GNSS fica às escuras
• Novidades da 0,40, Novidades da 0,39, Novidades da 0,38 e a 0,38 em detalhe: pontuação do jammertest, os próprios indicadores do recetor, entradas de máquina, temporização e holdover, pacotes de normas, LunaNet AFS, o ciclo de ida e volta no laboratório, kshana-bench, o observatório, exportadores, ótica, navegação de utilizadores no espaço e infraestrutura lunar
• Kshana Studio e todas as páginas do Studio
• Capacidades: a tabela de áreas, todos os tipos de cenário por família, todos os comandos, todas as superfícies
• Como funciona uma execução, Missões
• Evidências: o registo, domínios de capacidade
• Instalar, Arquitetura (e os diagramas), assistente de IA
• Edições, Investigação, Citar, Licença
• Referência: utilização, formato de cenário, saída, estrutura do repositório, perguntas frequentes, resolução de problemas, versionamento, roteiro, contribuir, documentação

Execute qualquer um deles com kshana example <scenario> > s.toml && kshana s.toml: os cenários são l-band-waterfall-jamming, constellation-multi-gnss-coverage, solar-system-tour e leo-pass-iridium.

Os quatro são dados fictícios e de caráter consultivo: mostram o formato e o comportamento do software, não o desempenho de qualquer recetor ou sistema face a interferência. Execute o primeiro com kshana receiver-trust examples/maritime-trust/session.toml, o segundo com kshana route-exposure sobre as amostras em examples/interference-map/, o terceiro com kshana nmea-scenario scenarios/training/coastal-drag-off.toml --out drag.nmea (apenas para formação: nunca o alimentar a equipamento de navegação em direto) e o quarto como em docs/EVIDENCE-PACKS.md.

Segue-se o pormenor completo domínio a domínio; para um registo de maturidade por capacidade, ver docs/CAPABILITY.md e docs/VALIDATION.md.

Cada capacidade é acessível como uma API Rust, como um kind de cenário executável, ou ambos. A maturidade por capacidade — validada, executável ou biblioteca — é acompanhada em docs/CAPABILITY.md. Uma matriz de verificação verificada por máquina (src/verification.rs) apresenta a referência cruzada requisito → módulo → teste → referência independente → estado, com invariantes de honestidade testados por unidade que só permitem uma etiqueta validada quando uma referência independente externa a sustenta — e que registam as capacidades de hardware/PA (garantia do produto) que o Kshana deliberadamente não fornece.

Resultados#

Cada cenário compara um sensor quântico com o seu equivalente clássico durante uma interrupção GNSS de ~1,8 h. Os números são reprodutíveis (scenario + seed + version).

_{O que os sensores quânticos trazem quando o GNSS desaparece — clock-holdover · semente 42 · desenhado no motor 0.40.0, e todos os valores acima são reverificados face ao motor atual em cada compilação por tests/published_figures_still_reproduce.rs · SVG}

A vantagem depende da interrupção e da vibração, com um ponto de equilíbrio explícito onde o clássico ganha — mostrado com honestidade ao longo da escada de maturidade tecnológica (os valores de relógios óticos são alvos de demonstradores em terra; nenhum relógio ótico de estrôncio voou):

_{Cruzamento de resiliência quântico-versus-clássico — escada TRL do holdover do relógio (em cima) · mapa de vantagem inercial com contorno de ponto de equilíbrio (em baixo). Regenerável através de cargo run --release --bin crossover_study.}

Erro de posição da navegação por estima durante uma interrupção GNSS: o sensor quântico (azul) mantém-se plano junto à especificação; o sensor clássico (vermelho) diverge para dezenas de quilómetros. Gerado pelo Kshana a partir de scenarios/imu-deadreckoning.toml.

A síntese final mostra a tese da fusão: a transferência de tempo ótica entre satélites mantém bloqueado até um relógio clássico, isolando o sensor inercial como o elo fraco do conjunto clássico — ou seja, inercial quântico + temporização ótica em conjunto.

Holdover do relógio durante uma interrupção GNSS: o relógio ótico (azul) permanece dentro da especificação de 20 ns durante toda a deriva; o relógio à escala de chip (vermelho) ultrapassa-a a meio. Gerado pelo Kshana a partir de scenarios/clock-holdover.toml.

Um outro cenário, orbit-gnss-challenged.toml, deriva a disponibilidade GNSS da geometria orbital em vez de janelas escritas à mão: uma nave espacial dentro da casca GNSS é propagada face a uma constelação Walker semelhante ao GPS, e o número de satélites visíveis (linha de visada, ocultação pela Terra, máscara de elevação) define o estado da solução de posição em cada passo. Ao longo de um dia o utilizador tem solução de posição apenas ~59% do tempo; o relógio quântico mantém uma solução de temporização de 5 ns em todas as interrupções (disponibilidade 1.0), o relógio à escala de chip apenas ~0.83.

Erro de temporização ao longo de um dia com a disponibilidade GNSS derivada da geometria orbital: o número de satélites visíveis (linha de visada, ocultação pela Terra, máscara de elevação) define o estado da solução de posição em cada passo, pelo que o relógio tem de percorrer sozinho cada lacuna — o relógio ótico mantém a especificação de 5 ns enquanto o relógio à escala de chip a ultrapassa. Gerado pelo Kshana a partir de scenarios/orbit-gnss-challenged.toml.

A constelação também pode ser dada como conjuntos reais de elementos de duas linhas (TLE). Um TLE completo (linha 1 + linha 2) é propagado com o modelo SGP4/SDP4 completo — incluindo a resistência atmosférica e os termos lunissolares de espaço profundo e de ressonância de 12 h / 24 h que importam para órbitas GNSS de ~12 h — validado face aos vetores oficiais AIAA 2006-6753 até um pior caso de ≈ 4 mm. scenarios/orbit-sgp4-gps.toml inclui um instantâneo real do Celestrak gps-ops da constelação GPS operacional (2021-07-28, 30 satélites) e exige somas de verificação TLE válidas — os conjuntos de elementos de duas linhas são dados abertos do catálogo da Força Espacial dos EUA / 18.º Esquadrão de Defesa Espacial, redistribuídos pelo Celestrak (Dr T. S. Kelso, celestrak.org); atualize com scripts/fetch_tles.sh. Um bloco só com a linha 2 mantém a propagação analítica de dois corpos (scenarios/orbit-real-tle.toml); as duas formas podem ser misturadas numa só constelação. Uma constelação pode igualmente ser construída a partir de um bloco de registos de efemérides difundidas GPS RINEX-3 — o formato que um recetor descodifica — propagados pelo algoritmo de utilizador da IS-GPS-200 e passados pela mesma geometria (scenarios/orbit-rinex.toml).

O que é / não é#

É: um motor determinista, com poucas dependências, que abrange toda a pilha PNT — geometria orbital, navegação inercial, fusão GNSS/INS, integridade, relógios e temporização. Executa um cenário (muitas vezes uma interrupção GNSS), faz evoluir modelos calibrados de erro de sensores através do estimador adequado e avalia o resultado face aos valores de mérito operacionais — emitindo um resultado JSON (JavaScript Object Notation) reprodutível e um gráfico SVG, a partir de uma biblioteca Rust, de uma interface de linha de comandos (CLI), de uma extensão Python, de um módulo WebAssembly no navegador, de um servidor Model Context Protocol (MCP) para agentes de IA ou de um plugin para IDE (ambiente de desenvolvimento integrado) JetBrains.

Não é: hardware de voo, um projeto de carga útil quântica, um recetor completo de sinais GNSS, um simulador de sinais de radiofrequência (RF) ou uma bancada hardware-in-the-loop, nem um produto de aviónica certificado — e não substitui o MATLAB/Simulink, o STK (Systems Tool Kit) nem o Orekit; fica ao lado deles e troca ficheiros com eles. A fidelidade do hardware quântico vem de modelos de erro publicados, não desta ferramenta. A maturidade granular de cada capacidade está documentada em docs/CAPABILITY.md.

Não é (ainda): um motor completo de física de interferometria atómica (a maioria dos sensores quânticos consome coeficientes publicados de Allan/orçamento de ruído; o acelerómetro CAI (interferómetro de átomos frios) tem uma camada de primeiros princípios — fase de Mach–Zehnder, ruído de projeção, decaimento de contraste e acoplamento de vibração, mais sistemáticos de Coriolis e de desvio de luz — mas os sistemáticos de frente de onda e a resolução da ambiguidade de franjas continuam a ser uma camada do roteiro P2 (fase 2 do roteiro, a camada de física quântica), ver ROADMAP.md e docs/QUANTUM-MODELS.md); um recetor GNSS certificado ou de hardware (resolve uma solução de posição PVT (posição, velocidade e tempo) de ponto único a partir de observações de código RINEX (Receiver Independent Exchange Format) reais — validado com dados reais do IGS (International GNSS Service) — e a sua camada IQ (kshana iq, desde 0.31.0) adquire e segue amostras em banda base gravadas ou geradas, em software, como recetor de análise: não aciona hardware de rádio nem transmite, não é um recetor certificado e não faz posicionamento por fase da portadora (RTK ou PPP)); nem um conjunto completo de projeto de missões (tem blocos de construção de Lambert / porkchop / manobra / determinação de órbita, mas é a camada de simulação de desempenho acima do GMAT (General Mission Analysis Tool)/Orekit, não uma substituição). Assumir este âmbito é deliberado. Se precisar de orçamentos de erro de interferómetro de átomos frios de primeiros princípios (por exemplo, de nível CARIOQA-PMP — Cold Atom Rubidium Interferometry in Orbit for Quantum Accelerometry, Pathfinder Mission Preparation — ou validação ao estilo do X-37B), consulte o roteiro P2 e entre em contacto para colaborar.

Validação, reprodutibilidade e honestidade#

• Cada termo de ruído é calibrado para um valor publicado e citado e validado face à relação padrão (desvio de Allan para relógios; crescimento do erro de navegação por estima de Groves para inercial; a conversão temporização→distância para transferência de tempo). O estado por termo é acompanhado em docs/VALIDATION.md como validated ou not modeled — nada é apresentado como validado sem o ser.
• Reprodutível por construção: scenario + seed + engine version → identical bits. scripts/check-reproducible.sh impõe-o; as execuções quânticas e clássicas usam sementes independentes, pelo que o seu ruído não é correlacionado.
• A maturidade é indicada com honestidade: os valores de relógios óticos e de ligações óticas são resultados de alvos / demonstradores em terra, não de voo.

A etiqueta de evidência em cada figura#

Cada figura e tabela que uma execução escreve diz até que ponto confiar nela e em quais linhas do registo ela assenta. O JSON de resultado tem uma chave evidence, o SVG do gráfico tem uma linha sob o gráfico (e um elemento <metadata id="kshana-evidence">), e a tabela CSV tem linhas de comentário # evidence: no início (lidas com comment='#'). Ele nomeia um nível, VALIDATED, MODELLED ou PARTNER, e os ids (VM- e oito dígitos hexadecimais) das linhas da matriz de verificação que a execução exercitou. O nível é o mais fraco dessas linhas, de modo que uma execução que assenta numa linha modelada é etiquetada MODELLED por mais linhas validadas que haja ao lado; a etiqueta nunca pode afirmar mais do que o registo. Linhas, estados e ids são lidos da matriz, não escritos à mão (docs/VERIFICATION-MATRIX.md, docs/SCHEMA.md), e tests/evidence_labels_doc_sync.rs falha se uma figura não tem etiqueta ou se uma etiqueta discorda da matriz.

A validação num relance#

Cada linha é imposta por um teste nomeado na CI. Esta tabela é um destaque selecionado; a matriz completa, verificada por máquina, tem 401 linhas — 176 VALIDATED, 221 MODELLED, 4 PARTNER (src/verification.rs), com as evidências completas (e o que honestamente ainda não é validado) em docs/VALIDATION.md e o artefacto kshana-validation-summary.html de cada versão (gerado por cargo run --bin validation_report, atestado pelo SLSA — Supply-chain Levels for Software Artifacts).

A coluna Estado indica o tipo de evidência, em linha com a escada de validação acima: VALIDATED = verificado face a uma referência independente externa (dados reais, uma biblioteca independente ou vetores de referência publicados); MODELLED = verificado face a verdade analítica ou autoconsistência da simulação (sem conjunto de dados externo independente). VALIDATED descreve o método de verificação, não um resultado de passa/falha — uma falha honesta face a uma referência independente externa real continua VALIDATED, enquanto uma comparação que nenhuma linha da matriz nomeia como referência independente (o ajuste do LRO — Lunar Reconnaissance Orbiter — acima) é apresentada como MODELLED. As linhas CI são salvaguardas de processo, não valores de mérito. Algumas ilhas de dados reais (o relógio de césio medido, o PHASE.DAT do Stable32 e as verificações OPS-SAT/ICGEM em que as entradas em bruto não têm licença de redistribuição) são condicionadas por dados: o teste imprime um aviso de salto e permanece verde quando a entrada está ausente, e os números de referência públicos estão registados em tests/fixtures/. Reproduza as entradas em bruto com o scripts/fetch_*.sh correspondente.

_{Como uma capacidade obtém o seu rótulo — o invariante imposto pela CI: sem referência independente externa ⇒ não pode ser Validada · SVG}

_{Em cima: cada linha Validada é suportada por um conjunto de dados externo, por construção. Em baixo: o SGP4 coincide com a referência oficial em todos os regimes (pior caso 4,12 mm). SVG · SVG}

_{176 validadas · 221 modeladas · 4 de parceiros — SVG}

import json, kshana

toml = open("clock-holdover.toml").read()
result = json.loads(kshana.run(toml))
print(kshana.version(), result["quantum"]["fom"]["holdover_s"], result["classical"]["fom"]["holdover_s"])
# 0.40.0 6600.0 2610.0

Para além de run, o módulo expõe run_full (JSON, SVG e o resumo de uma linha em simultâneo), run_typed, validate_toml, list_kinds / scenario_kinds e error_kind; consulte docs/PYTHON_API.md.

O pacote npm é o motor completo compilado para WebAssembly. No Node.js, entregue o binário a initSync; num navegador, await init() obtém-no (consulte README.npm.md).

import { readFileSync } from "node:fs";
import { createRequire } from "node:module";
import { initSync, run, summary, version } from "kshana";

const wasm = createRequire(import.meta.url).resolve("kshana/kshana_bg.wasm");
initSync({ module: readFileSync(wasm) });

const toml = readFileSync("clock-holdover.toml", "utf8");
const result = JSON.parse(run(toml));
console.log(version(), result.quantum.fom.holdover_s, result.classical.fom.holdover_s);
// 0.40.0 6600 2610
console.log(summary(toml));

Um motor, muitos pontos de entrada. Um único núcleo em Rust (kshana) executa cada cenário, acessível através de uma CLI, de uma extensão Python, de um módulo WebAssembly no navegador, de um servidor MCP para agentes de IA e de um plugin para IDE JetBrains — todos convergindo num único despacho api::run_toml. No interior, os pacotes de sensores ligam-se a uma interface comum de modelos de erro; a par deles encontram-se uma camada de referenciais (precessão–nutação IAU 2006/2000A e a redução GCRS↔ITRS baseada no CIO), uma camada de astrodinâmica/numérica (SGP4/SDP4 analítico e um propagador numérico de Cowell com o respetivo modelo de forças EGM2008/perturbações, conceção de manobras e determinação de órbita), uma camada de integridade/GNSS (RAIM/ARAIM, SBAS, o domínio das medições, jamming, cislunar), uma camada de fusão / PNT alternativo (os estimadores GNSS/INS e os correlacionadores de mapas de gravidade/terreno/magnéticos), uma camada de espaço profundo e lunar (PNT radiométrico em Marte e o conjunto de PNT lunar, com o nível de evidência de cada parte na matriz — tempo LTC, VLBI, OD+relógio conjuntos, realização de referencial, volume de serviço, PNT diferencial, interoperabilidade), uma camada de análise de missão (balanços de ligação de lançamento / reentrada / cobertura / apontamento / passagem e o ambiente de meteorologia espacial) e a camada aberta de estudos de resiliência e aprendizagem automática (pontuação de resiliência RPCF, a lacuna de otimismo por degradações de RF e o demonstrador de PNT quântico) cujos artefactos reprodutíveis assentam em núcleos validados.

Dois crates autónomos, excluídos do workspace, situam-se junto ao núcleo — mcp/kshana-mcp (o servidor MCP, construído sobre o SDK rmcp da edição 2024) e xval/anise-frames (a verificação cruzada de referenciais ANISE/SPICE, que traz dependências MPL-2.0 (Mozilla Public License 2,0)) — mantidos fora do grafo de dependências do crate publicado, de Cargo.lock, da barreira de licenças e da compilação MSRV (versão mínima suportada do Rust) pela lista exclude do Cargo.toml da raiz. O plugin JetBrains (ide/jetbrains) é um projeto Kotlin separado. Consulte docs/ARCHITECTURE.md para o conjunto completo de diagramas.

Os diagramas renderizados (fluxo do motor, mapa de módulos, distribuição) encontram-se em docs/ARCHITECTURE.md.

Cenários e relatórios

Exportação e interoperabilidade

Confiança do recetor e da embarcação

IQ GNSS (ficheiros do diretório de trabalho; desativado no modo HTTP)

Mapeamento de compliance

Benchmark

Sobre o que o Kshana Pro assenta. Cada parte do Pro trabalha a partir do motor aberto e deixa-o inalterado:

• O otimizador de projeto, o estudo de incerteza e o dossiê de missão executam cenários do motor aberto através da interface pública do motor e calculam cada número a partir dos resultados das execuções. Cada saída mantém o nível VALIDATED, MODELLED ou PARTNER que o motor aberto atribuiu a cada valor, nunca um superior.
• Os gémeos digitais de relógios usam o modelo de relógio do motor aberto e o seu estimador do desvio de Allan: um gémeo é calibrado com o orçamento de Allan publicado do dispositivo e depois verificado estimando o desvio de Allan do gémeo com o estimador aberto.
• Os estudos de compromissos executam cada opção de arquitetura como um cenário do motor aberto, sem alterações, e ordenam as opções segundo uma figura de mérito lida do resultado de cada execução.
• A vigilância de campanhas lê os seus valores dos resultados de execuções do motor aberto dos cenários de um pacote e compara-os com a execução anterior bem-sucedida.
• A coexistência espetral lê cada número físico de execuções do motor aberto dos tipos leo-signal e constellation-design, e acrescenta apenas a soma sobre os satélites à vista e a ordenação dos planos.
• O serviço de tarefas nas instalações do cliente executa cenários abertos e do Pro através do mesmo motor e guarda cada resultado tal como a execução o devolveu.
• Os pacotes de evidências registam, para cada execução, o hash do cenário que o motor aberto grava no seu resultado, para que um valor de um pacote possa ser reproduzido voltando a executar o seu cenário.
• Ferramentas de engenharia de sistemas e de programas. As ferramentas de engenharia de sistemas baseada em modelos (MBSE) e de programas do Kshana Pro verificam os requisitos de um programa face a execuções do motor aberto: importam requisitos como valores separados por vírgulas (CSV), ou como um subconjunto documentado do Requirements Interchange Format (ReqIF) ou de texto Systems Modeling Language versão 2 (SysML v2), avaliam cada critério de aceitação, com a respetiva unidade, face aos valores que uma execução escreveu, e produzem uma matriz de referência cruzada de verificação (VCRM), um modelo SysML v2, um relatório de impacto de alterações e um pacote de evidências offline. Não voltam a executar nem a recalcular nada, e leem apenas o que o motor aberto publica: o result.json de cada execução (os campos que um critério nomeia, as respetivas unidades, o carimbo de reprodutibilidade com hash do cenário, semente, versão do motor e versão do esquema, e o rótulo da execução e os níveis dos valores), o seu report.json (tipo, registo de reprodutibilidade e rótulos de capacidades), o ficheiro de cenário (o seu hash, tipo, semente e parâmetros), o esquema de campos e unidades (a unidade, a proveniência e o nível de evidência de cada campo) e a matriz de verificação (o rótulo VALIDATED, MODELLED ou PARTNER de cada capacidade).

Apoio e serviços profissionais#

O Kshana é gratuito e de código aberto sob a AGPL-3.0 e desenvolvido e mantido profissionalmente pela Ashforde® OÜ (Estónia). O motor aberto é completo e utilizável por si só. Para organizações que precisam de mais, a Ashforde® OÜ oferece:

• Apoio comercial e integração — incorporação do Kshana na sua cadeia de ferramentas, cenários à medida e correções prioritárias.
• Modelos de sensores à medida — calibrados para o seu equipamento, incluindo modelos de resiliência sujeitos a controlo de exportação mantidos numa sobreposição privada.
• Kshana Pro — ferramentas proprietárias de engenharia de sistemas baseada em modelos (MBSE) e de programas que verificam os requisitos de um programa face a execuções do motor aberto e produzem uma matriz de referência cruzada de verificação (VCRM), um modelo Systems Modeling Language versão 2 (SysML v2), um relatório de impacto de alterações e um pacote de evidências offline. Não voltam a executar nada e leem apenas as saídas publicadas do motor: o result.json e o report.json de cada execução, o ficheiro de cenário, o esquema de campos e unidades e os rótulos da matriz de verificação (a lista completa está em Edições).
• Ferramentas do Kshana Pro de projeto, incerteza e missão — a frente de Pareto de um espaço de projeto, incerteza e sensibilidade ao longo de milhares de execuções, e um dossiê de missão com um só comando, com uma matriz de verificação e um PDF; consulte docs/PRO.md.
• Vigilância de campanhas, coexistência espetral e serviço de tarefas do Kshana Pro — um pipeline que falha quando um valor vigiado piora, planos de sinal testados face aos sinais abertos de navegação por satélite nos dois sentidos, e uma fila de tarefas nas instalações do cliente com um registo de entregas encadeado por hash; consulte docs/PRO.md.
• Formação e consultoria sobre análise de desempenho de PNT quântico/clássico.

Este é o modelo de núcleo aberto: o motor é, e continuará a ser, de licença aberta; o negócio que o sustenta é o conhecimento especializado, o apoio e as extensões proprietárias — não as taxas de licença. Contacto: contact@ashforde.org · ashforde.org.

Instalar e compilar#

Requer uma cadeia de ferramentas Rust (≥ 1,88, a rust-version em Cargo.toml; desenvolvido em 1,93).

git clone https://github.com/ashfordeOU/kshana
cd kshana
cargo build --release
cargo test          # all tests pass

Utilização#

Execute qualquer cenário; a CLI despacha segundo o campo kind do cenário e escreve <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html e <scenario>.report.json junto dele — mais <scenario>.table.csv para os tipos que publicam uma tabela. O relatório (uma página HyperText Markup Language (HTML) e um documento JSON com o mesmo conteúdo) traz um resumo executivo, cada entrada com a sua unidade, os resultados e os gráficos, as tabelas de varrimento, Monte Carlo ou cadeia de uma campanha, uma cronologia de eventos, o rótulo VALIDATED / MODELLED / PARTNER e a origem de cada capacidade que a execução usou, o que não está modelado e um registo de reprodutibilidade (versão do motor, resumos Secure Hash Algorithm 256-bit (SHA-256), semente, plataforma e o comando exato). Imprime-se para um ficheiro PDF (Portable Document Format) limpo a partir do navegador em papel A4 ou Letter; o motor não escreve nenhum PDF. Consulte docs/REPORTS.md.

cargo run -- scenarios/clock-holdover.toml
cargo run -- scenarios/imu-deadreckoning.toml
cargo run -- scenarios/timetransfer.toml
cargo run -- scenarios/hybrid-pnt.toml
cargo run -- scenarios/orbit-gnss-challenged.toml
cargo run -- scenarios/orbit-sgp4-gps.toml
cargo run -- scenarios/orbit-rinex.toml
cargo run -- scenarios/integrity-raim.toml

# Export a propagated constellation to an SP3-c precise-ephemeris file:
cargo run -- scenarios/orbit-sgp4-gps.toml --export-sp3 gps.sp3

# Export the constellation's mean elements to a CCSDS OMM catalogue (one OMM
# message per TLE-defined satellite, with its real NORAD id / COSPAR designator):
cargo run -- scenarios/orbit-sgp4-gps.toml --export-omm gps.omm

# Export the velocity-carrying state to a CCSDS OEM 2.0 ephemeris (GMAT/Orekit/STK):
cargo run -- scenarios/orbit-sgp4-gps.toml --export-oem gps.oem

# Export the geometry for a globe, a map or a mission-analysis tool: CZML, KML,
# GeoJSON, STK .e, or SigMF for the spectrum kind (every format that applies):
cargo run -- scenarios/jamming-demo.toml --export all

--export <czml|kml|geojson|stk|sigmf|all|list> escreve junto do cenário gravações CZML (a Cesium Language), KML (Keyhole Markup Language), GeoJSON (Request for Comments 7946), efemérides Ansys STK (Systems Tool Kit) .e e SigMF (Signal Metadata Format), e --import-route <route.geojson> alimenta uma linha GeoJSON nos tipos que percorrem um trajeto. Cada formato é validado face à sua especificação publicada, e um cenário a que um formato não se aplica diz porquê: consulte docs/INTEROP.md.

Outros modos da CLI — analisar um cenário com lint, fornecer dados reais de orientação da Terra ou executar uma bateria completa:

# Lint a scenario without running it (checks the kind + required fields):
cargo run -- --validate scenarios/integrity-raim.toml

# Feed a real IERS Earth-orientation file (finals2000A) for frame precision:
cargo run -- scenarios/orbit-sgp4-gps.toml --eop tests/fixtures/agency/eop/finals2000A_2022001.txt

# Run a SUITE of scenarios into one aggregated, stamped study artifact
# (writes <suite>.study.json + <suite>.study.html next to the manifest):
cargo run -- --study scenarios/quantum-pnt-demonstrator.suite.toml

# Animate a run's time series: an animated SVG, a self-contained HTML player, and a
# numbered SVG frame sequence with manifest.json (see docs/ANIMATION.md):
cargo run -- scenarios/campaign-jam-spoof-holdover-integrity.toml --animate all

Exportação de animações. --animate svg|html|frames|all escreve <scenario>.animation.svg (keyframes de Cascading Style Sheets (CSS), sem script), <scenario>.animation.html (reproduzir, pausar, deslocar, velocidade e painéis sincronizados, sem recursos externos) e <scenario>.frames/ (frame_0000.svg, … mais manifest.json com as imagens por segundo e a duração). Uma campanha reproduz as suas fases e alarmes, uma execução de espetro a sua cascata; o tema segue prefers-color-scheme e prefers-reduced-motion mostra a imagem final. Renderiza as amostras da própria execução, idênticas ao byte numa nova execução, e não acrescenta evidências. Consulte docs/ANIMATION.md.

Um manifesto de bateria é um pequeno ficheiro TOML (Tom's Obvious, Minimal Language) — um title e uma lista scenarios = [ … ] de caminhos de cenários — que o motor executa por sua vez, reunindo cada resultado (com os respetivos rótulos MODELLED / VALIDATED) num único artefacto de estudo autodescritivo. Consulte scenarios/quantum-pnt-demonstrator.suite.toml.

Papel de interoperabilidade. O Kshana é a camada de simulação de desempenho que se situa a par da cadeia de ferramentas de pós-processamento, não uma substituição dela: alimente a sua saída RINEX ao RTKLIB ou ao gLAB para obter uma solução de posição, e use a sua saída SP3 como produto de órbita precisa para ferramentas como o Ginan — o Kshana responde a que resiliência uma dada arquitetura PNT proporciona antes de existirem sinais reais, em formatos que essas ferramentas já ingerem (--export-sp3, ou export_sp3 = true num cenário orbit, escreve <scenario>.sp3). A mesma órbita pode ser publicada como elementos médios CCSDS OMM de uma norma em curso (--export-omm, ou export_omm = true, escreve <scenario>.omm) — uma mensagem OMM 502,0 KVN (keyword = value notation) por satélite definido por TLE, com o número de catálogo NORAD (North American Aerospace Defense Command), o designador internacional COSPAR (Committee on Space Research) e a época reais de cada objeto, para qualquer consumidor que compreenda OMM, em vez de um conjunto de elementos de duas linhas feito à medida.

Exemplo de saída (holdover do relógio — repare em como as figuras de mérito de Integridade e de Segurança são comunicadas):

scenario 5ba83a232b94 | quantum holdover 6600s p95 1.20e-4ns integrity 1.000 security n/a (no attack) | classical holdover 2610s p95 19.7ns integrity 1.000 security n/a (no attack)
wrote scenarios/clock-holdover.result.json, scenarios/clock-holdover.chart.svg, scenarios/clock-holdover.report.html, and scenarios/clock-holdover.report.json

O erro de temporização do percentil 95 (p95) do relógio ótico é de 1.20e-4 ns: o resumo imprime valores pequenos com algarismos significativos em vez de os arredondar para 0.0. security indica n/a (no attack) porque este cenário não configura nenhum ataque, pelo que não há nada a detetar. O resultado JSON continua a conter o limite analítico de detetabilidade de spoofing de cada relógio em fom.security (0,997 para o relógio ótico, 0,000 para o relógio atómico à escala de chip, cujo ruído próprio na janela de monitorização excede a especificação de 20 ns), e o seu bloco figure_tiers marca esse valor como applicable: false. O tipo de cenário spoof pontua a deteção face a um ataque injetado. figure_tiers atribui também a cada valor comunicado o seu nível de verificação — VALIDATED (verificado face a uma referência independente externa) ou MODELLED — e a linha da matriz de verificação de onde o nível é lido. O cenário de órbita comunica adicionalmente um bloco de geometria — fração de amostras com solução de posição e melhor/mediana diluição de precisão de posição (PDOP) e exatidão de posição — a par do resultado do relógio.

Leia estes dois números com cuidado. security é um limite analítico de detetabilidade de spoofing derivado da estabilidade de cada relógio — só tem significado face a um cenário de spoofing configurado e não é um detetor RAIM multissatélite. integrity é aqui a autoconsistência do filtro (fração das amostras de falha dentro do seu próprio limite de k sigma), não um valor de integridade HPL/VPL de aviação. Consulte docs/INTEGRITY.md.

Para integridade autónoma genuína do recetor, o tipo de cenário integrity (scenarios/integrity-raim.toml) executa RAIM real de instantâneo e de separação de soluções (ao estilo ARAIM) sobre a geometria da constelação propagada: calcula os níveis de proteção horizontal/vertical (HPL/VPL) por época e comunica a fração de épocas que satisfazem os limites de alerta configurados, com um diagrama de integridade de Stanford para a classificação de erro face ao PL (nível de proteção).

Artefactos de estudo reprodutíveis

Quatro estudos abertos regeneram cada um um artefacto determinista ao byte (semente fixa) com um só comando — os números por trás dos estudos do cruzamento quântico-versus-clássico, da lacuna de otimismo por degradações de RF, da pontuação de resiliência de PNT e do nível de proteção de temporização:

# Quantum-vs-classical resilience crossover map (writes paper/crossover/*.json):
cargo run --release --bin crossover_study -- paper/crossover

# RF-impairment optimism-gap study (13-detector panel, scaling laws, LOO predictor):
cargo run --release --example optimism_study -- paper-artifacts/optimism-study.json

# Framework-aligned PNT-resilience scoring + decision-instability study:
cargo run --release --example resilience_report -- paper-artifacts/resilience-study.json

# Conditional Timing Protection Level, calibrated on a real recorded spoof:
cargo run --release --example tpl_jammertest

Cada artefacto regista a versão do motor, as sementes e um hash de configuração e traz um rótulo MODELLED/VALIDATED honesto. As sondas com dados reais (*_probe) executam o mesmo pipeline sobre gravações que fornece localmente; nenhum conjunto de dados é distribuído no repositório. O estudo da lacuna de otimismo por degradações de RF está descrito no preprint arXiv:2606,22054, e o nível de proteção de temporização condicional (tpl_jammertest acima) no preprint arXiv:2606,24210 (consulte Citar).

Os estudos publicados de PNT lunar (arXiv:2607,06212 DOP com faróis à superfície, arXiv:2607,02566 observabilidade por VLBI e arXiv:2610,23871 observabilidade do comprimento de arco cislunar) têm as suas afirmações de geometria, diluição de precisão, previsão em tempo real de referencial / parâmetros de orientação da Terra (EOP), órbitas retrógradas distantes e medição de distância por RF verificadas de forma cruzada e independente em tests/validate_p*.rs face a referências independentes separadas (scipy.special.j1, uma resolução DOP (HᵀH)⁻¹ independente em NumPy, uma nova análise em NumPy das mesmas linhas finals2000A do IERS, e a NASA/JPL Three-Body Periodic Orbit Database). São verificações de regressão adicionais sobre o conjunto lunar modelado; não alteram a contagem da matriz verificada por máquina.

Formato de cenário#

Os cenários são TOML declarativo. Um kind de nível superior seleciona o pacote — cinquenta no total (clock é o predefinido se for omitido): inertial, timetransfer, hybrid, hybrid-ukf, fusion, gnss-ins, orbit, ephemeris, gnss-sim, integrity, lunar-integrity, lunar-time-offset, spoof, spoof-detect, jamming, sweep, sweep-nd, gravity-map, terrain-nav, terrain-slam, combined-altpnt, pvt, mars-pnt, impairment-eval (banco de ensaio de avaliação da deteção de degradações de RF por aprendizagem automática — corpus sintético rotulado + estrutura de ROC/AUC independente do detetor + lacuna de otimismo dentro/fora da distribuição), quantum-trade (compromisso PNT quântico versus clássico com ingestão de ADEV medida + envolvente de resiliência sem GNSS; MODELLED), space-weather (índices solares/geomagnéticos + temperatura exosférica de Jacchia-71 + densidade termosférica condicionada pela atividade sobre a atmosfera estática; MODELLED), oem-interop (ponte de importação/ida-e-volta CCSDS OEM para efemérides do GMAT/Orekit/STK; MODELLED), o trio de análise de missão launch-window (azimute de lançamento de dois corpos / mudança de plano / oportunidades), reentry (corredor de reentrada balística de Allen-Eggers), eo-coverage (geometria de faixa / GSD / acesso / revisita de observação da Terra), space-packet (enquadramento de pacotes espaciais CCSDS 133,0 TM/TC — telemetria/telecomando — disposição exata de bits, ida-e-volta verificada) e attitude-budget (binário de gradiente de gravidade em 3 graus de liberdade + orçamento de erro de apontamento RSS), passes (previsão de passagens de nascer/pôr de estações terrenas — AOS/TCA/LOS, elevação máxima, acesso) e link-budget (equação de ligação CCSDS/DSN unidirecional — FSPL / Eb·N₀ / margem / fecho); telecom-timing (erro de tempo em holdover, MTIE e TDEV verificados face a máscaras ITU-T); spectrum (toda a banda L do GNSS como uma única densidade espetral de potência: uma cascata frequência-tempo sob uma cronologia de jammer programada de onda contínua, banda estreita, chirp ou ruído adaptado, relação jammer-sinal por banda e densidade efetiva de portadora-ruído a partir do coeficiente de separação espetral, e entrada e saída de gravações Signal Metadata Format (SigMF) com estimativas espetrais de Welch; os espetros de sinal VALIDATED face a valores de manuais, o cenário de jammer MODELLED; consulte docs/SPECTRUM.md; o mesmo tipo desenha painéis de banda UHF, S e C com sinais de órbita terrestre baixa concebidos); leo-signal (projetos de sinais de posicionamento, navegação e temporização em órbita terrestre baixa para qualquer sistema: espetros de banda limitada, jitter de seguimento de código e exatidão de medição de distância, pesquisa e tempo de aquisição, separação espetral face ao GPS e ao Galileo, tolerância a jammers e um compromisso entre bandas UHF e C, a partir de predefinições públicas como Xona Pulsar, Iridium, Starlink e CentiSpace ou projetos em linha; as formas fechadas e o Doppler em LEO VALIDATED, os projetos MODELLED; consulte docs/LEO-SIGNAL.md); solar-system (o Sol, os planetas, Plutão, a Lua e sete grandes luas numa só época — posições, constantes, tempos de luz e trajetórias orbitais; posições dos planetas VALIDATED face ao JPL Horizons) e body-pnt (posicionamento em torno de qualquer desses corpos com uma constelação de navegação local e uma ligação de espaço profundo desde a Terra; MODELLED); campaign (tipos existentes compostos numa cronologia de missão encadeada com o estado passado entre fases, um varrimento de parâmetros, um conjunto Monte Carlo com semente, ou vários cenários sob uma condição partilhada; MODELLED, consulte docs/CAMPAIGNS.md); constellation-design (padrões Walker delta e estrela, listas de elementos e projetos de várias camadas com predefinições GPS, Galileo, BeiDou e GLONASS, e cobertura e diluição de precisão numa grelha de latitude/longitude; o gerador e o DOP global do GPS VALIDATED face aos documentos de serviço publicados, consulte docs/CONSTELLATION-DESIGN.md); leo-pass (uma passagem de satélite de posicionamento, navegação e temporização (PNT) em órbita terrestre baixa (LEO) e o seu balanço de ligação banda a banda, a partir de qualquer constelação e de qualquer projeto de sinal: ângulos de visada, Doppler e taxa de Doppler, perda ITU-R por chuva, gases, cintilação e penetração em edifícios, densidade de portadora-ruído face aos satélites GNSS MEO à vista, a ionosfera de primeira ordem e os pares livres de ionosfera, e um orçamento de solução de posição de baixa energia, sondagem da ionosfera a partir de cada par de bandas, e monitores de spoofing por consistência de Doppler e de geometria da passagem e por consistência entre bandas; os termos ITU-R e a envolvente de Doppler de utilizador estático VALIDATED, a passagem MODELLED, consulte docs/LEO-PASS.md); leo-navmsg (a mensagem de efemérides e de relógio difundida por um satélite PNT em órbita terrestre baixa (LEO), para qualquer órbita e portadora: um ajustador desde uma órbita de referência integrada até ao conjunto kepleriano do Galileo, esse conjunto com polinómios de correção ao longo da trajetória, transversal e radial, o modelo de 22 parâmetros de Liu et al. 2025 ou o polinómio ECEF de relógio zero ATOMIC; erro de distância do sinal no espaço (SISRE) em função do intervalo de ajuste e do período de atualização, uma verificação de continuidade da atualização a meio da passagem, a própria trama binária documentada do Kshana com uma verificação de redundância cíclica CRC-24Q e um orçamento de quantização, e um bloco no estilo RINEX-4 rotulado como extensão do Kshana; os pesos do SISRE, o algoritmo de utilizador do Galileo e o CRC-24Q VALIDATED, os ajustes MODELLED; predefinições opcionais para Xona Pulsar, Iridium, Starlink, CentiSpace, um sistema representativo em banda C, ATOMIC e Celeste IOD; consulte docs/LEO-NAVMSG.md); o trio de PNT fundido MEO + LEO leo-pvt (posicionamento por Doppler a partir da taxa de variação da distância em órbita terrestre baixa (LEO), soluções de posição conjuntas de pseudodistâncias GNSS + LEO com enviesamentos entre sistemas e o DOP em função do número de satélites LEO, cobertura polar e do Ártico, e transferência de tempo LEO para UTC — sobre qualquer constelação, com predefinições opcionais como sinais de oportunidade Xona Pulsar, Iridium e Starlink; a envolvente de Doppler em LEO VALIDATED face a valores publicados do Iridium e da Xona), leo-ppp (convergência de posicionamento preciso de ponto apenas com GNSS e com aumentação por LEO, comparada com Li et al. 2019) e ntn-positioning (posicionamento de rede não terrestre 5G a partir do limite de Cramér-Rao da largura de banda do sinal), MODELLED à parte essa envolvente, consulte docs/LEO-PNT-FUSION.md; leo-pnt-chain (um sistema LEO-PNT de ponta a ponta: um projeto leo-signal transportado por uma banda leo-pass, o C/N0 da passagem e o erro de distância do sinal no espaço da mensagem de navegação passados a uma solução de posição fundida leo-pvt e a uma convergência leo-ppp, com cada passagem de testemunho listada; MODELLED, consulte docs/LEO-PNT.md, que é também a visão geral de todos os tipos e cenários LEO-PNT, incluindo as campanhas de resiliência, um cenário por área de foco de experiência e um por vertical de utilizador final); o conjunto de PNT lunar lunar-vlbi, lunar-joint-od-clock, lunar-frame-realisation, moonlight-service-volume, lunar-differential-pnt, lunar-interop-export; o demonstrador de PNT com tecnologias quânticas quantum-time-transfer, quantum-gnss-free-nav, quantum-anomaly-detect; e os tipos de investigação de segurança de sinal, cislunar e resiliência em camadas lunar-attack-surface, realtime-frame-eop, lunar-time-budget, hybrid-optical-rf, cislunar-observability, conflict-resilience — o trio de análise de missão e estes tipos mais recentes, todos MODELLED (cada um com um núcleo de forma fechada validado; consulte a matriz). Campos comuns: seed, uma grelha [time], uma cronologia de disponibilidade [gnss] (o motor das falhas), e blocos por sensor com cadeias provenance que citam a origem de cada valor. Exemplo (relógio):

seed = 42
threshold_ns = 20.0
[time]
step_s = 10.0
duration_s = 7200.0
[gnss]
windows = [
  { t0 = 0.0,   t1 = 600.0,  state = "nominal" },  # 10 min GNSS sync
  { t0 = 600.0, t1 = 7200.0, state = "denied"  },  # ~1.8 h outage
]
[clock_quantum]
id = "optical-sr-lattice"
provenance = "Strontium optical lattice clock, space-oriented goal sigma_y(1s)=1e-15 (arXiv:1503.08457)"
y0 = 5.0e-17
q_wf = 1.0e-30   # white FM:  q_wf = sigma_y(1s)^2
q_rw = 0.0       # random-walk FM
drift = 0.0      # linear aging (per second)
[clock_classical]
id = "csac-sa45s"
provenance = "Microchip SA65 / SA.45s CSAC datasheet sigma_y(1s)=3e-10"
y0 = 5.0e-10
q_wf = 9.0e-20
q_rw = 0.0
drift = 0.0

Campos opcionais (desligados quando ausentes): um relógio pode acrescentar flicker_floor (patamar de Allan de 1/f FM — modulação de frequência); um sensor inercial pode acrescentar gyro_bias e q_arw (enviesamento do giroscópio e passeio aleatório angular), e bias_instability e q_aa (o patamar de Allan da instabilidade do enviesamento e o passeio aleatório da aceleração) — em conjunto, um orçamento de erro de acelerómetro de eixo único (1-DOF) (VRW/ARW — passeio aleatório de velocidade/angular — e instabilidade do enviesamento). Este é o orçamento de erro que o pacote de cenários inertial distribuído executa. Em separado, a biblioteca inclui agora um navegador strapdown de 3 eixos verificado (src/inertial/{attitude,mechanization,imu_errors}.rs): atitude por quaterniões com compensação de coning/sculling, uma mecanização NED completa (termos da velocidade de rotação da Terra e da velocidade de transporte, gravidade de Somigliana WGS-84) e um modelo determinista de erros da IMU em que o fator de escala, o desalinhamento, a sensibilidade a g, a quantização e a rampa de taxa são modelados (IEEE Std 952-1997, a norma da IEEE para especificação e procedimento de ensaio de giroscópios, §A.2; Groves 2013 §4,3). Esse percurso de 3 eixos está agora ligado a um pacote GNSS/INS fracamente acoplado executável (kind = "gnss-ins"): um EKF de estado de erro de 15 estados disciplina a solução strapdown face a soluções de posição ruidosas enquanto o GNSS está disponível e depois segue em inércia durante a falha, comunicando o erro horizontal fundido face ao seguimento em inércia pura em malha aberta. Está também disponível uma atualização de pseudodistância fortemente acoplada (forma a inovação no domínio da distância, pelo que continua a corrigir com menos de quatro satélites). Um cenário de holdover de relógio pode acrescentar runs (> 1) para executar um conjunto Monte Carlo — cada figura de mérito é então comunicada como uma média com uma dispersão entre o percentil 5 e o percentil 95 e o gráfico sombreia a banda de confiança do erro (consulte scenarios/clock-ensemble.toml).

Um cenário fusion (com os mesmos blocos de hybrid) executa dois estimadores de Kalman independentes — um para o estado do relógio, outro para o estado da posição — disciplinados pelo GNSS e auxiliados por transferência de tempo ótica, e comunica uma FoM de holdover combinada. Os dois blocos não partilham covariância cruzada: trata-se de um par empilhado de orçamentos de erro, não de um verdadeiro filtro conjunto acoplado de relógio+posição (a covariância entre blocos é um item do plano de desenvolvimento). Consulte scenarios/fusion-pnt.toml.

Um cenário spoof injeta um spoof de tempo — um de quatro tipos de [attack.shape] (linear_ramp, step_jump, meaconing, replay; um simples rate_ns_per_s continua a ser aceite como rampa linear) — e executa o detetor de spoofing de cada relógio. O detetor é um teste de energia χ²₁ / de Neyman–Pearson bilateral sobre a estatística do monitor auxiliado pelo relógio: o limiar é definido a partir de um orçamento de falsos alarmes target_pfa, e a probabilidade de falha de deteção P_md é comunicada em forma fechada e por Monte Carlo (mc_runs ensaios por hipótese — os dois concordam até alguns ×1/√N). A figura de mérito de Segurança é 1 − P_md na magnitude operacionalmente prejudicial (da especificação), pelo que um relógio silencioso que apanha um spoof com a dimensão da especificação pontua ≈ 1 e um ruidoso que o falha muitas vezes pontua menos (consulte scenarios/spoof-attack.toml, scenarios/spoof-meaconing.toml).

Um cenário gnss-sim é uma simulação no domínio das medições: para cada satélite visível sintetiza a pseudodistância ρ = geometric range + c·δt_rx − c·δt_sv + I + T + noise + multipath e o Doppler em L1, com a ionosfera monofrequência de Klobuchar ([iono], IS-GPS-200 §20.3.3.5.2.5) e a troposfera zenital de Saastamoinen projetada pela função de mapeamento de Niell (1996) ([tropo]). Os resíduos alimentam o RAIM de instantâneo para HPL/VPL por época, e a pseudodistância, o Doppler, o C/N₀ e as correções iono/tropo de cada satélite são emitidos na lista gnss_measurements do JSON. É um simulador direto (gera medições a partir de uma referência conhecida), não um recetor/resolvedor — uma execução sem ruído reproduz a geometria mais as correções a nível submilimétrico (consulte scenarios/gnss-sim-raim.toml).

Um cenário jamming modela a interferência de RF como um balanço de ligação: um [jammer] (posição ECEF, power_dbw de emissão, tipo) eleva a relação jammer-sinal num [receiver] que observa um [constellation] Walker. A partir da geometria (perda de percurso em espaço livre e ganho da antena de receção por direção) calcula o J/S de cada satélite, o C/N₀ efetivo através da equação anti-jam padrão (ganho de processamento de desespalhamento × o fator de separação espetral Q; Kaplan & Hegarty §9,4), e sinaliza a perda de bloqueio abaixo de um limiar de seguimento configurável — comunicando uma figura de mérito availability_under_jamming. Um jammer de banda larga de 10 W a 1 km nega totalmente o recetor (J/S ≈ 72 dB); o mesmo jammer a 100 km apenas degrada as ligações (consulte scenarios/jamming-demo.toml).

Um cenário sweep executa um estudo de compromissos: varia um parameter (threshold_ns, duration_s, quantum_q_wf ou classical_q_wf) de start a stop ao longo de steps pontos numa scale lin ou log, regista uma metric (por exemplo holdover_s) para ambos os relógios e traça as duas curvas. O cenário de base vai em [base] (consulte scenarios/sweep-clock-stability.toml).

Um cenário sweep-nd generaliza isto para qualquer pacote e qualquer número de eixos: varia chaves TOML com pontos de um cenário [base] (de qualquer kind) sobre o produto cartesiano de [[axes]], volta a executar cada nó da grelha e regista metrics dadas como caminhos JSON com pontos no resultado (por exemplo classical.fom.holdover_s). Funciona para todos os pacotes porque opera na fronteira entre TOML e resultado; as execuções nativas avaliam a grelha em paralelo (sem dependências adicionais, o wasm recorre ao modo sequencial) e a saída é determinista e por linhas (consulte scenarios/sweep-nd-inertial.toml).

Um cenário orbit deriva a cronologia [gnss] a partir da geometria em vez de a redigir — indique uma órbita [user], uma [constellation], uma mask_deg de elevação e os dois blocos de relógio. Comunica também a exatidão de posição a partir da geometria dos satélites; o sigma_uere_m opcional (erro de distância equivalente do utilizador a 1 sigma, predefinição 1 m) converte a diluição de precisão de posição num sigma de posição. A órbita do utilizador pode ser tornada excêntrica com eccentricity e argp_deg, e j2 = true acrescenta a deriva secular do achatamento da Terra (consulte scenarios/orbit-molniya.toml). A constelação pode, em alternativa, ser real: dê a [constellation] um bloco tle de conjuntos de elementos de duas linhas e os satélites são lidos a partir dele (consulte scenarios/orbit-real-tle.toml). Acrescente um ou mais blocos [[constellations]] para multi-GNSS (por exemplo GPS + Galileo; consulte scenarios/orbit-multignss.toml):

kind = "orbit"
seed = 7
threshold_ns = 5.0
mask_deg = 10.0
sigma_uere_m = 1.0           # optional; position sigma = position-DOP * this
[time]
step_s = 60.0
duration_s = 86400.0
[user]                       # spacecraft (altitude in km, angles in deg)
altitude_km = 8000.0
inclination_deg = 0.0
[constellation]              # Walker-delta GNSS (GPS-like)
altitude_km = 20180.0
inclination_deg = 55.0
planes = 6
sats_per_plane = 4
phasing_f = 1.0
[clock_quantum]  # ... as above
[clock_classical]  # ... as above

Os tipos de PNT alternativo sem GPS navegam sem qualquer GNSS, fazendo corresponder uma sequência de campo medida a um mapa através de um filtro de partículas. Um cenário gravity-map percorre um trajeto num campo de anomalias gravíticas em harmónicos esféricos e recupera-o a partir da leitura de um gravímetro de átomos frios (scenarios/gps-denied-gravity-nav.toml); um cenário terrain-nav faz o mesmo face a um DEM de elevação SRTM (TERCOM/SITAN, scenarios/terrain-nav.toml); e um cenário combined-altpnt funde gravidade + magnético IGRF + terreno num único filtro (scenarios/combined-altpnt.toml).

Um cenário lunar-integrity avalia PNT cislunar: executa uma passagem de nível de proteção ARAIM no polo sul lunar face a um conjunto de retransmissores LunaNet/LNIS e comunica com honestidade a lacuna de integridade — um σ_URE lunar de ~30 m leva o nível de proteção muito acima de um limite de alerta de 50 m, pelo que o serviço fica indisponível sob regras de integridade ao estilo da aviação (scenarios/lunanet-araim.toml).

Um cenário lunar-time-offset comunica a taxa relativista do relógio Terra–Lua — a base de uma escala de Tempo Coordenado Lunar (LTC/TCL). Uma identidade pós-newtoniana a partir de princípios fundamentais soma a diferença de potencial próprio (o potencial do geoide L_G da IAU menos o potencial próprio à superfície da Lua) e o termo cinético da Lua (Doppler de segunda ordem) numa taxa secular de ≈ 57 µs/dia, comunicada com a banda publicada de 56–59 µs/dia; dá também o desvio LTC−TT acumulado ao longo de um horizonte e um conjunto de variância inversa (um relógio de papel lunar). MODELLED — o valor principal é dependente da referência (geoide terrestre versus selenoide lunar, janela de média), razão pela qual se comunica uma banda e não um único número certificado (scenarios/lunar-time-offset.toml).

Veja scenarios/ para pelo menos um exemplo prático de cada tipo de cenário (92 tipos, 193 ficheiros .toml de cenário + 1 manifesto de suíte — vários tipos de cenário trazem mais de um exemplo). Nem todo tipo de cenário tem um ficheiro com o seu nome: lunar-integrity → scenarios/lunanet-araim.toml e gravity-map → scenarios/gps-denied-gravity-nav.toml são dois de vários casos assim. Liste os tipos de cenário despacháveis a qualquer momento com os erros de cargo run -- --validate <file>, o list_kinds() do Python ou a ferramenta list_scenario_kinds do MCP.

Saída#

O artefacto de resultado é JSON versionado e autodescritivo: séries temporais por passo, as figuras de mérito pontuadas, as especificações dos modelos ativos (com proveniência), a semente, um hash do cenário — para que qualquer gráfico possa ser reproduzido a partir do ficheiro — e, para cada relógio, uma adev_curve ([{tau_s, adev, n_samples, noise, edf, ci_lo, ci_hi}]): o desvio de Allan sobreposto em tempos de média espaçados por oitavas — a forma habitual de ler a estabilidade de um relógio — agora com uma banda de confiança de 95% específica do tipo de ruído por ponto (o tipo de lei de potência do registo é identificado a partir do seu declive de Allan modificado, e o intervalo χ² usa os graus de liberdade efetivos correspondentes do NIST SP 1065). O playground no navegador renderiza-o como um gráfico log-log "Clock stability (ADEV)". (MDEV, TDEV e HDEV estão disponíveis como estimadores da biblioteca; a curva de resultado exportada é o ADEV sobreposto.) Cada campo, com unidades e uma indicação da origem, está documentado em docs/SCHEMA.md.

Cada gráfico é autodescritivo. O playground no navegador, a exportação *.chart.svg da CLI e o painel de resultados HTML (HyperText Markup Language) carimbam todos cada imagem de gráfico com um rodapé que diz Kshana v<version> · scenario <hash> · kshana.dev. O scenario <hash> são os primeiros 12 carateres hexadecimais do hash do cenário da execução — um resumo SHA-256 (o Secure Hash Algorithm de 256 bits) sobre a definição canónica do cenário (semente, limiares, parâmetros dos modelos, janelas GNSS, …); os relatórios de integridade e lunares, que não trazem hash próprio, recorrem a um SHA-256 do código-fonte do cenário. É a mesma impressão digital mostrada no resumo de uma linha e no JSON do resultado, pelo que um gráfico guardado ou colado traz sempre a sua versão, o cenário exato que o produziu (para reprodução bit a bit) e a origem — altere qualquer entrada e o hash muda.

As figuras de mérito seguem as figuras de mérito operacionais habituais de PNT:

Não conhece estes termos? Cada um está definido em linguagem simples no glossário.

Estrutura do repositório#

kshana/
├── src/                                       # the kshana core crate (library + CLI)
│   ├── api.rs · main.rs · lib.rs              # typed dispatch (92 kinds) + CLI + crate root
│   ├── python.rs · wasm.rs                    # optional PyO3 / wasm-bindgen bindings
│   ├── types.rs · scenario.rs · allan.rs      # shared core (time grid, GNSS timeline, Allan)
│   │
│   ├── models.rs · estimator.rs · kalman.rs   # Pack 1 — clock holdover + integrity
│   ├── security.rs · detection.rs · spoof.rs · spoof_monitors.rs  # spoof detection
│   ├── filter_health.rs · fom.rs · fom_label.rs · report.rs · chart.rs · run.rs  # health · FoM scoring + labelling · output
│   ├── suite.rs · study.rs                     # scenario suites + aggregated multi-scenario study artifacts (`--study`)
│   ├── inertial/                              # Pack 2 — strapdown INS (attitude · mechanization · imu_errors · quantum_imu)
│   ├── timetransfer.rs · timetransfer_adv.rs · timegeo.rs  # Pack 3 — TWSTFT/CV/PPP/optical, Sagnac
│   ├── hybrid.rs · ensemble.rs · sweep.rs     # Pack 4 — fused PNT, Monte-Carlo, trade sweeps
│   │
│   ├── timescales.rs · jd2.rs · ephem.rs      # time systems, two-part JD, Sun/Moon ephemeris
│   ├── precession.rs · nutation.rs · cio.rs   # IAU 2006/2000A precession-nutation + CIO GCRS↔ITRS
│   ├── frames.rs · *_data.rs                  # TEME↔ECEF + generated nutation/CIO/EGM2008/IGRF tables
│   │
│   ├── orbit.rs · sgp4.rs · tle.rs · walker.rs   # geometry, SGP4/SDP4, TLE, Walker design
│   ├── propagator.rs · forces.rs · gravity_sh.rs · integrator.rs  # Cowell + perturbations (EGM2008 d/o70, GR) + RK4/DOPRI
│   ├── maneuver.rs · batch_ls.rs · orbit_determination.rs  # burns/Lambert/porkchop, Gauss-Newton, OD
│   ├── cr3bp.rs · lunar.rs · lunar_frame.rs · lunar_od.rs  # Earth–Moon CR3BP + halo/NRHO STM corrector, cislunar/LunaNet ARAIM, MCI↔MCMF, lunar OD
│   ├── lunar_time.rs · lunar_vlbi.rs · lunar_combination.rs · lunar_frame_realise.rs · lunar_service.rs · lunar_dpnt.rs · lunar_interop.rs  # tiers per piece in the matrix lunar PNT suite — LTC time · geodetic VLBI · joint OD+clock · frame realisation · Moonlight service-volume · differential PNT · LunaNet/IOAG interop export
│   ├── body.rs · mars_frame.rs · ephem_provider.rs · radiometric.rs · ccsds_tdm.rs  # deep-space: multi-body · Mars frame · ephemeris seam · radiometric obs + CCSDS-TDM
│   ├── deepspace_od.rs · clock_state.rs · mars_atmos.rs · mars_pnt.rs · linkbudget.rs · gse_sim.rs  # SRIF OD · onboard clock · Mars drag · relay-PNT · link budget · GSE sim
│   │
│   ├── fusion/                                # GNSS/INS — EKF · UKF · tightly_coupled(17) · coupled · closed_loop
│   ├── raim.rs · sbas.rs                      # RAIM/ARAIM HPL/VPL, SBAS DO-229E PLs + L1/L5 iono-free
│   ├── gnss_sim.rs · ionex.rs · pvt.rs · jamming.rs  # measurement domain · ionosphere maps · single-point positioning · jamming
│   ├── navsignal.rs                            # nav-signal PSD (BPSK-R/BOC) · spectral-separation → anti-jam Q · DLL code-tracking jitter · multipath envelope
│   ├── gravimeter.rs · igrf.rs · mapmatch.rs · particle_filter.rs · altpnt/  # gravity/magnetic/terrain alt-PNT
│   ├── rinex.rs · rinex_obs.rs · glonass.rs · sp3.rs · oem.rs · omm.rs · permalink.rs  # interop formats
│   ├── launch.rs · reentry.rs · eo_payload.rs · attitude_budget.rs · passes.rs · space_packet.rs  # mission-analysis budgets + CCSDS Space Packet
│   ├── space_weather.rs · holdover.rs · tpl.rs   # space-weather environment · GNSS-denied clock-holdover calculator · conditional Timing Protection Level (under spoofing)
│   ├── resilience/                              # framework-aligned PNT-resilience scoring + decision-instability study (RPCF · Dirichlet · Kendall-τ · diversity collapse · assurance report)
│   ├── impairment_eval.rs · impairment_study.rs · impairment_ml.rs · eval_stats.rs  # Machine-learning RF-impairment eval testbed · optimism-gap study · LR/MLP detectors · bootstrap/DeLong/Spearman stats
│   ├── sdr.rs · realdata/                       # software-defined-receiver front end (IQ/IF → E/P/L taps → SQM) + real-data ingest adapters (RINEX · UBX · GnssLogger · JammerTest · Yunnan · SatGrid)
│   ├── crossover.rs · quantum_trade.rs · frugal.rs · integrity_impact.rs  # quantum-vs-classical crossover map · PNT trade · cost-per-coverage ROI · integrity impact
│   ├── quantum_devices.rs · quantum_faults.rs · quantum_nav_od.rs · qtrade.rs · timetransfer_chain.rs · representativeness.rs  # Quantum-Enabled PNT demonstrator — device error models · fault catalogue · GNSS-free quantum OD · unified trade harness · quantum time-transfer chain · representativeness / gaps-to-flight ledger
│   ├── interchange.rs · verification.rs          # KIF artifact envelope · machine-checked verification matrix
│   └── bin/crossover_study.rs · bin/validation_report.rs  # crossover-study artifact generator · release validation-summary HTML
│
├── mcp/kshana-mcp/        # standalone, workspace-EXCLUDED crate — the MCP server (+ Dockerfile, server.json)
├── ide/jetbrains/         # standalone Kotlin/Gradle IntelliJ-Platform plugin
├── xval/                  # standalone, workspace-EXCLUDED external cross-checks: anise-{frames,lunar-od,mars-od,service-geometry} (Rust ANISE/SPICE DE440) + orekit-passes (Java Orekit)
│
├── examples/            # reproducible study generators: tpl_jammertest · resilience_report · optimism_study + real-data probes (jammertest_probe · yunnan_probe · satgrid_probe · texbat_probe · ingest_realdata)
├── paper-artifacts/     # byte-deterministic study artifacts, regenerable from examples/ (optimism-study.json · resilience-study.json); raw datasets stay out
├── scenarios/            # one cited .toml per kind + geometry-driven + GPS-denied
├── scripts/              # reproducibility + repo-hygiene + SBOM guards
├── docs/                 # CONCEPTS, ARCHITECTURE, CAPABILITY, VALIDATION, PROVENANCE, GLOSSARY, …
├── web/                  # the WebAssembly playground + kshana.dev site
├── tools/                # table generators (EGM2008 · IGRF · nutation · CIO) + fetch_tles.sh
├── .github/workflows/    # ci · release · publish · wheels · pages · mcp-publish · jetbrains-plugin · frame-xval
├── pyproject.toml        # Python packaging (maturin)
├── CHANGELOG.md          # Keep a Changelog + SemVer
└── CITATION.cff · ROADMAP.md · CONTRIBUTING.md · SECURITY.md

FAQ#

Preciso de compreender física quântica para usar isto? Não. Se sabe executar uma linha de comandos, sabe executar o Kshana. Comece pelo guia introdutório em linguagem simples; consulte os termos no glossário.

É um projeto de hardware quântico ou software de voo? Não. É um simulador de desempenho. A fidelidade do hardware quântico vem de modelos de erro publicados, não desta ferramenta. Consulte O que é / não é.

Os resultados quânticos são realistas, ou marketing? Cada parâmetro está citado a uma folha de especificações ou a um artigo, cada modelo é validado face a uma relação de manual, e a maturidade está rotulada com honestidade em VALIDATION.md — incluindo que nenhum relógio ótico de estrôncio voou. O motor é neutro: quântico e clássico são o mesmo código com números publicados diferentes.

Posso confiar que duas execuções concordam? Sim — as execuções são deterministas: scenario + seed + engine version → bit-identical output, garantido por scripts/check-reproducible.sh.

Posso usá-lo a partir de Python ou num navegador? Sim — consulte Instalar: os exemplos de Python e WebAssembly estão por baixo. Ambos chamam o mesmo motor.

Como modelo o meu próprio sensor? Escreva um cenário .toml com os valores publicados do seu sensor nos campos provenance. Consulte Formato de cenário e os exemplos em scenarios/.

É gratuito para uso comercial? Sim — sob a AGPL-3.0, incluindo em contextos comerciais, desde que respeite o copyleft da AGPL (em especial: se modificar o Kshana e o oferecer através de uma rede, tem de oferecer a esses utilizadores o seu código-fonte modificado). Se isso não lhe convier — por exemplo, se precisar de incorporar o Kshana num produto proprietário ou de executar um serviço de rede fechado — está disponível uma licença comercial da Ashforde® OÜ; consulte LICENSING.md e Apoio.

Resolução de problemas#

cargo build falha numa cadeia de ferramentas antiga. O Kshana precisa de Rust ≥ 1,88. Atualize com rustup update.

A compilação da extensão Python falha na ligação no macOS (Undefined symbols … _Py…). Uma extensão Python resolve os seus símbolos no momento do carregamento. O maturin define automaticamente a opção de ligação correta — use maturin develop --features python em vez de um simples cargo build.

A compilação do Python queixa-se de que o interpretador é mais recente do que o PyO3 conhece. Defina PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 (as wheels abi3 são compatíveis para a frente entre versões do CPython).

A compilação WebAssembly não encontra o alvo. Instale-o uma vez com rustup target add wasm32-unknown-unknown e depois wasm-pack build --target web -- --features wasm.

Onde foi parar a minha saída? Cada execução escreve <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html e <scenario>.report.json junto do .toml de entrada, e também <scenario>.table.csv para os tipos que publicam uma tabela. Todos eles são ignorados pelo git por conceção.

Versionamento e publicações#

O Kshana segue o Versionamento Semântico. Enquanto for anterior à 1.0, o esquema público de cenário/resultado ainda pode mudar; as alterações incompatíveis são assinaladas explicitamente no CHANGELOG.md. Cada resultado é reproduzível a partir de scenario + seed + engine version.

Cada tag vX.Y.Z publica automaticamente todos os canais, por uma única ordem — a bateria de testes completa executa-se primeiro no commit etiquetado, nada é publicado até ela passar, e depois o pipeline verifica que cada registo serve realmente a nova versão (docs/RELEASING.md). Os canais:

A versão do crate / imagem / registo do servidor MCP acompanha o motor (inclui a biblioteca); o plugin JetBrains tem versões independentes (invoca o binário kshana que tem instalado).

Roteiro#

Consulte ROADMAP.md para o plano de desenvolvimento por fases, CHANGELOG.md para o histórico de versões publicadas e docs/CAPABILITY.md para o plano por capacidade. A ordem de prioridade é: primeiro, evidências de temporização e holdover para infraestruturas críticas (máscaras de telecomunicações, holdover mais longo com envelhecimento e ruído flicker, ingestão de dados de relógio medidos); em segundo lugar, o método neutro de compromisso quântico versus clássico (resultados rotulados MODELLED até que os dados medidos de um parceiro os promovam); e navegação lunar / cislunar e de espaço profundo mantida, não ampliada como prioridade. A redução de referencial de precisão ITRF está agora concluída — a cadeia GCRS↔ITRS completa IAU 2006/2000A baseada no CIO (movimento polar + nutação sub-arcsegundo), validada bit a bit face ao SOFA/ERFA e verificada de forma cruzada e independente face ao ANISE (SPICE em Rust puro) a ≤ 3,6 m em órbita GNSS. Os itens a curto prazo incluem a fusão de fase da portadora fortemente acoplada e a disponibilização do navegador GNSS/INS fraca e fortemente acoplado em mais pacotes; o motor de navegação radiométrica de espaço profundo / Marte chegou na v0.17.0 (validado por simulação). A camada de física quântica é um item P2: o acelerómetro CAI é agora simulado a partir de princípios fundamentais (fase de Mach–Zehnder, ruído de projeção, decaimento do contraste, acoplamento de vibração), enquanto os sensores de relógio/transferência de tempo continuam a ser orientados por coeficientes publicados de Allan/orçamento de ruído. A conversão TEME↔ECEF baseada em GMST, os sistemas de tempo com segundos intercalares do IERS (UTC/TAI/TT/UT1), a propagação de órbitas SGP4/SDP4 (v0.7.0, validada face aos vetores AIAA 2006-6753) e o pacote de fusão gnss-ins executável foram todos entregues, e a velocidade inercial é exposta a jusante. Chegaram a main: um detetor estocástico ativo de spoof de tempo (teste de energia de Neyman–Pearson / χ²₁ com P_fa/P_md por Monte Carlo e uma FoM de Segurança de 1−P_md), um modelo de jamming por balanço de ligação (J/S → C/N₀ efetivo → perda de bloqueio), disponibilidade multiconstelação, um orçamento de erro de IMU de eixo único (1-DOF), dois estimadores de Kalman independentes (relógio + posição) comunicados como uma FoM combinada, geometria real de constelações a partir de TLE, um relatório HTML de resultados, disponibilidade GNSS derivada da geometria e diluição de precisão a partir de órbitas keplerianas com excentricidade e deriva J2, bandas de confiança Monte Carlo, varrimentos de parâmetros de estudos de compromissos, um playground WebAssembly no navegador e ligações opcionais para Python (PyO3) e WebAssembly (wasm-bindgen).

Contribuir#

Consulte CONTRIBUTING.md. Em resumo: os testes passam (cargo test), os dois scripts de salvaguarda passam, Conventional Commits, e uma entrada [Unreleased] em CHANGELOG.md para cada alteração visível ao utilizador. A participação rege-se pelo nosso Código de Conduta. Para comunicar um problema de segurança, consulte a Política de segurança — não abra um problema público para vulnerabilidades.

Documentação#

Referências principais#

Referências independentes de validação e normas — as autoridades externas a que as verificações do Kshana estão ancoradas:

• Vallado, Crawford, Hujsak & Kelso — Revisiting Spacetrack Report #3 (AIAA 2006-6753; dados de teste): o conjunto de verificação SGP4/SDP4 com o qual o Kshana coincide a 4,12 mm, e os exemplos resolvidos de referenciais face aos quais a cadeia TEME→ITRF é verificada.
• IAU SOFA / ERFA — as rotinas de referência de tempo e de referenciais face às quais a nutação IAU 2000A e a redução CIO GCRS↔ITRS são validadas bit a bit.
• Petit & Luzum (eds.) — IERS Conventions (2010), IERS TN (Technical Note) 36 (orientação da Terra, movimento polar e normas de referenciais).
• Riley — Handbook of Frequency Stability Analysis, NIST SP 1065 (relações do desvio de Allan e a série de referência NBS14; NBS = o antigo National Bureau of Standards dos EUA).
• Pedregosa et al. — scikit-learn: Machine Learning in Python, JMLR 12 (2011): as implementações de referência de ROC/AUC, matriz de confusão e precisão/recall/F1 com as quais o banco de ensaio de avaliação de degradações de RF coincide exatamente (tests/eval_metrics_reference.rs).
• Virtanen et al. — SciPy 1,0, Nature Methods 17 (2020): optimize.nnls, stats.chi2 e linalg.expm — as rotinas de referência face às quais o ajuste NNLS da ADEV medida do quantum-trade, as bandas de consistência χ² e a covariância do ruído de processo do relógio de van Loan são validados (tests/scipy_reference.rs).
• Knowles, Kanhere, Neamati & Gao — gnss_lib_py, SoftwareX 27 (2024): usado tanto como estado da técnica aberto (consulte Comparação e estado da técnica aberto abaixo) como referência independente de DOP com a qual o cálculo de GDOP/PDOP/HDOP/VDOP/TDOP coincide a 1e-6 (tests/dop_reference.rs).
• Montenbruck & Gill — Satellite Orbits: Models, Methods and Applications (Springer): os modelos de forças por trás do ajuste do modelo de forças às efemérides precisas de agências.
• Howell — Three-dimensional, periodic, halo orbits, Celestial Mechanics 32(1) (1984), doi:10.1007/BF01358403; Zimovan-Spreen, Howell & Davis — Near rectilinear halo orbits and nearby higher-period dynamical structures, Astrodynamics 6 (2022), doi:10.1007/s42064-021-0125-x (as famílias de halo/NRHO que o corretor diferencial do CR3BP reproduz).

Física de dispositivos e de métodos — as fontes citadas por trás dos modelos de sensores:

• Origlia, Schiller, Bongs et al. — arXiv:1503,08457 (relógio ótico de rede de estrôncio, objetivo orientado para o espaço).
• Oelker et al., Nature Photonics (2019) — doi:10.1038/s41566-019-0493-4 (relógio de Sr de laboratório, 4,8×10⁻¹⁷).
• Templier et al., Science Advances (2022) — arXiv:2209,13209 (tríade de acelerómetros quânticos híbridos).
• Groves, Principles of GNSS, Inertial, and Multisensor Integrated Navigation — tutorial da IEEE AESS (Aerospace and Electronic Systems Society) (repositório University College London Discovery) (crescimento do erro da navegação por estima).
• Giorgetta et al., Nature Photonics 7, 434 (2013) — arXiv:1211,4902; Deschênes et al., Phys. Rev. X 6, 021016 (2016) — APS (American Physical Society) (transferência ótica bidirecional de tempo-frequência; a ligação ótica entre satélites modela o seu orçamento de não reciprocidade a partir destes).
• Betz — Binary Offset Carrier Modulations for Radionavigation, NAVIGATION 48(4) (2001), doi:10.1002/j.2161-4296.2001.tb00247.x (a modulação BOC e a teoria da separação espetral por trás de src/navsignal.rs).
• Kaplan & Hegarty (eds.) — Understanding GPS/GNSS: Principles and Applications (3.ª ed., Artech House, 2017): a equação anti-jam do C/N₀ efetivo e o jitter térmico do seguimento de código do DLL early–late que os modelos de sinal de navegação e de jamming usam.

Comparação e estado da técnica aberto — as ferramentas e levantamentos face aos quais o Kshana se posiciona:

• Humphreys et al. — TEXBAT (a Texas Spoofing Test Battery; ION — Institute of Navigation — GNSS 2012): os parâmetros da bateria de testes de spoofing face aos quais o detetor multicamada é caracterizado.
• González et al. — NaveGo (2017): os perfis abertos e validados de erro de navegação inercial usados como linha de base clássica.
• Iiyama, Casadesús Vila & Gao — LuPNT (ION GNSS+ 2023, Stanford NavLab): simulador aberto de PNT lunar.
• Knowles, Kanhere, Neamati & Gao — gnss_lib_py, SoftwareX 27 (2024), doi:10.1016/j.softx.2024.101811: análise aberta de dados GNSS.
• Li, Zaminpardaz, Kealy & Greentree — Quantum sensors for enhanced positioning and navigation: a comprehensive review, GPS Solutions 30(1):62 (2026), doi:10.1007/s10291-026-02030-y.
• Bertone et al. — Earth and Space Science 8(6) (2021), doi:10.1029/2020EA001454: DO reduzida-dinâmica do GRAIL, o patamar de aceleração empírica que o ajuste do LRO reproduz.