• Ensaie o minuto em que o GNSS apaga
• 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 receptor, 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, óptica, navegação de usuários no espaço e infraestrutura lunar
• Kshana Studio e todas as páginas do Studio
• Capacidades: a tabela de áreas, todo tipo de cenário por família, todo comando, toda superfície
• Como uma execução funciona, Missões
• Evidências: o registro, domínios de capacidade
• Instalar, Arquitetura (e os diagramas), assistente de IA
• Edições, Pesquisa, Citar, Licença
• Referência: uso, formato de cenário, saída, estrutura do repositório, FAQ, solução de problemas, versionamento, roteiro, contribuição, 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.

Todos os quatro são dados fictícios e consultivos: mostram o formato e o comportamento do software, não o desempenho de qualquer receptor ou sistema frente à 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 (somente para treinamento: nunca o alimente em equipamento de navegação real) e o quarto como em docs/EVIDENCE-PACKS.md.

O detalhe completo, domínio por domínio, segue; para um registro de maturidade por capacidade, veja docs/CAPABILITY.md e docs/VALIDATION.md.

Cada capacidade é acessível como uma API Rust, um cenário executável kind, 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 testadas por unidade que permitem um rótulo validada somente onde uma referência independente externa a respalda — e que registram as capacidades de hardware/PA (garantia do produto) que o Kshana deliberadamente não oferece.

Resultados#

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

_{O que os sensores quânticos oferecem quando o GNSS desaparece — clock-holdover · semente 42 · desenhado no motor 0.40.0, e cada figura acima reverificada contra o motor atual a 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 vence — mostrada honestamente ao longo da escada de maturidade tecnológica (as cifras de relógio óptico são alvos de demonstradores em solo; nenhum relógio óptico de estrôncio voou):

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

Erro de posição da navegação por estima durante uma interrupção de GNSS: o sensor quântico (azul) permanece plano perto da 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 óptica de tempo entre satélites mantém travado 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 óptica juntos.

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

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

Erro de temporização ao longo de um dia com a disponibilidade de GNSS derivada da geometria orbital: a contagem de satélites visíveis (linha de visada, ocultação pela Terra, máscara de elevação) define o estado da solução em cada passo, de modo que o relógio precisa atravessar toda lacuna em deriva — o relógio óptico mantém a especificação de 5 ns enquanto o relógio em escala de chip a viola. 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 (TLEs). Um TLE completo (linha 1 + linha 2) é propagado com o modelo SGP4/SDP4 completo — incluindo arrasto atmosférico e os termos de espaço profundo lunar-solares e de ressonância de 12 h / 24 h que importam para órbitas GNSS de ~12 h — validado contra os vetores oficiais AIAA 2006-6753 a 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 checksums de TLE válidos — os conjuntos de elementos de duas linhas são dados abertos do catálogo da Força Espacial dos EUA / 18th Space Defense Squadron, redistribuídos pelo Celestrak (Dr. T. S. Kelso, celestrak.org); atualize com scripts/fetch_tles.sh. Um bloco só da linha 2 mantém a propagação analítica de dois corpos (scenarios/orbit-real-tle.toml); as duas formas podem ser misturadas em uma única constelação. Uma constelação também pode ser construída a partir de um bloco de registros de efemérides difundidas do GPS em RINEX-3 — o formato que um receptor decodifica — propagados pelo algoritmo de usuário do IS-GPS-200 e alimentados pela mesma geometria (scenarios/orbit-rinex.toml).

O que é / não é#

É: um motor determinístico e de poucas dependências que abrange a pilha de PNT — geometria orbital, navegação inercial, fusão GNSS/INS, integridade, relógios e temporização. Ele executa um cenário (muitas vezes uma interrupção de GNSS), evolui modelos calibrados de erro de sensores por meio do estimador apropriado e pontua o resultado contra as figuras de mérito operacionais — emitindo um resultado JSON (JavaScript Object Notation) reproduzível e um gráfico SVG, a partir de uma biblioteca Rust, uma interface de linha de comando (CLI), uma extensão Python, um módulo WebAssembly no navegador, um servidor Model Context Protocol (MCP) para agentes de IA ou um plugin para IDE (ambiente de desenvolvimento integrado) JetBrains.

Não é: hardware de voo, um projeto de carga útil quântica, um receptor completo de sinais GNSS, um simulador de sinais de radiofrequência (RF) ou bancada de 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; ele fica ao lado deles e troca arquivos 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, além de sistemáticos de Coriolis e de deslocamento de luz — mas os sistemáticos de frente de onda e a resolução de ambiguidade de franjas continuam sendo uma camada P2 (fase 2 do roteiro, a camada de física quântica) do roteiro, veja ROADMAP.md e docs/QUANTUM-MODELS.md); um receptor GNSS certificado ou de hardware (ele resolve uma solução de posição PVT (posição, velocidade e tempo) de ponto único a partir de observações reais de código RINEX (Receiver Independent Exchange Format) — validada com dados reais do IGS (International GNSS Service) — e sua camada IQ (kshana iq, desde a 0.31.0) adquire e rastreia amostras de banda base gravadas ou geradas em software, como um receptor de análise: ela não aciona hardware de rádio nem transmite, não é um receptor certificado e não faz posicionamento por fase da portadora (RTK ou PPP)); nem um conjunto completo de projeto de missão (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 escopo é deliberado. Se você precisa de orçamentos de erro de interferômetro de átomos frios a partir 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 no estilo X-37B), veja o roteiro P2 e entre em contato para colaborar.

Validação, reprodutibilidade e honestidade#

• Todo termo de ruído é calibrado a uma cifra publicada e citada e validado contra a relação padrão (desvio de Allan para relógios; crescimento de erro de navegação por estima de Groves para inercial; a conversão temporização→medição de 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 sê-lo.
• Reproduzível por construção: scenario + seed + engine version → identical bits. scripts/check-reproducible.sh o impõe; as execuções quânticas e clássicas usam sementes independentes, de modo que seu ruído não é correlacionado.
• A maturidade é declarada honestamente: as cifras de relógio óptico e de enlace óptico são resultados de alvos / demonstradores em solo, não de voo.

O rótulo de evidência em cada figura#

Cada figura e tabela que uma execução grava diz até que ponto confiar nela e em quais linhas do registro ela se apoia. 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: na frente (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 se apoia em uma linha modelada é rotulada MODELLED por mais linhas validadas que haja ao lado; o rótulo nunca pode afirmar mais do que o registro. Linhas, estados e ids são lidos da matriz, não digitados (docs/VERIFICATION-MATRIX.md, docs/SCHEMA.md), e tests/evidence_labels_doc_sync.rs falha se uma figura não tem rótulo ou se um rótulo 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 artefato 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 declara o tipo de evidência, de acordo com a escada de validação acima: VALIDATED = verificado contra uma referência independente externa (dados reais, uma biblioteca independente ou vetores de referência publicados); MODELLED = verificado contra a verdade analítica ou a autoconsistência da simulação (sem conjunto de dados externo independente). VALIDATED descreve o método de verificação, não um passa/falha — uma falha honesta contra 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) é mostrada como MODELLED. As linhas de CI são salvaguardas de processo, não figuras 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 brutas não trazem licença de redistribuição) são condicionadas a dados: o teste imprime um aviso de omissão e permanece verde quando a entrada está ausente, e os números públicos de referência são registrados em tests/fixtures/. Reproduza as entradas brutas com o scripts/fetch_*.sh correspondente.

_{Como uma capacidade conquista seu rótulo — o invariante aplicado pela CI: sem referência independente externa ⇒ não pode ser validada · SVG}

_{Acima: toda linha validada é sustentada por um conjunto de dados externo, por construção. Abaixo: 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

Além de run, o módulo expõe run_full (JSON, SVG e o resumo de uma linha de uma só vez), run_typed, validate_toml, list_kinds / scenario_kinds e error_kind; consulte docs/PYTHON_API.md.

O pacote npm é o motor inteiro compilado para WebAssembly. No Node.js, entregue o binário a initSync; em um navegador, await init() o busca (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, muitas portas de entrada. Um único núcleo em Rust (kshana) executa todos os cenários, acessado por uma CLI, uma extensão Python, um módulo WebAssembly no navegador, um servidor MCP para agentes de IA e um plugin de IDE do JetBrains — todos convergindo para um único despacho api::run_toml. Por dentro, os pacotes de sensores se conectam a uma interface comum de modelo de erro; ao lado deles ficam uma camada de referenciais (precessão–nutação IAU 2006/2000A e a redução GCRS↔ITRS baseada no CIO), uma camada numérica/de astrodinâmica (SGP4/SDP4 analítico e um propagador numérico de Cowell com seu modelo de forças EGM2008/perturbações, projeto de manobras e determinação de órbita), uma camada de integridade/GNSS (RAIM/ARAIM, SBAS, o domínio de medição, jamming, cislunar), uma camada de fusão / PNT alternativo (os estimadores GNSS/INS e os correlacionadores de mapas gravitacionais/de terreno/magnéticos), uma camada de espaço profundo e lunar (PNT radiométrico de Marte e o conjunto de PNT lunar, com seu nível de evidência por peça na matriz — tempo LTC, VLBI, OD+relógio conjunta, realização de referencial, volume de serviço, PNT diferencial, interoperabilidade), uma camada de análise de missão (orçamentos de lançamento / reentrada / cobertura / apontamento / passagem / enlace e o ambiente de clima espacial) e a camada aberta de estudos de resiliência e aprendizado de máquina (pontuação de resiliência RPCF, a lacuna de otimismo por degradação de RF e o demonstrador de PNT quântico), cujos artefatos reproduzíveis se apoiam nos kernels validados.

Dois crates independentes, excluídos do workspace, ficam ao lado do 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, do bloqueio de licenças e da compilação MSRV (versão mínima suportada do Rust) pela lista exclude do Cargo.toml raiz. O plugin do 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) estão em docs/ARCHITECTURE.md.

Cenários e relatórios

Exportação e interoperabilidade

Confiança do receptor e da embarcação

IQ GNSS (arquivos do diretório de trabalho; desligado no modo HTTP)

Mapeamento de compliance

Benchmark

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

• O otimizador de projeto, o estudo de incerteza e o dossiê de missão executam cenários do motor aberto pela 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 deu a cada figura, nunca um superior.
• Gêmeos digitais de relógio usam o modelo de relógio do motor aberto e seu estimador de desvio de Allan: um gêmeo é calibrado ao orçamento de Allan publicado do dispositivo e depois verificado estimando o desvio de Allan do gêmeo com o estimador aberto.
• Estudos de trade executam cada opção de arquitetura como um cenário do motor aberto, sem alterações, e classificam as opções por uma figura de mérito lida do resultado de cada execução.
• O acompanhamento de campanha lê suas figuras dos resultados de execuções do motor aberto dos cenários de um pacote e as compara com a execução anterior que passou.
• A coexistência espectral 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 classificação dos planos.
• O serviço local de tarefas executa cenários abertos e do Pro pelo mesmo motor e armazena cada resultado como a execução o devolveu.
• Pacotes de evidências registram, para cada execução, o hash do cenário que o motor aberto carimba em seu resultado, de modo que uma figura em um pacote possa ser reproduzida executando-se novamente o seu cenário.
• Ferramentas de engenharia de sistemas e de programa. As ferramentas de engenharia de sistemas baseada em modelos (MBSE) e de programa do Kshana Pro conferem os requisitos de um programa com execuções do motor aberto: importam requisitos como valores separados por vírgula (CSV), ou como um subconjunto documentado do Requirements Interchange Format (ReqIF) ou do texto da Systems Modeling Language versão 2 (SysML v2), avaliam cada critério de aceitação, com sua unidade, em relação aos valores que uma execução gravou, e produzem uma matriz de referência cruzada de verificação (VCRM), um modelo SysML v2, um relatório de impacto de mudanças e um pacote de evidências offline. Elas não reexecutam nem recalculam nada, e leem apenas o que o motor aberto publica: o result.json de cada execução (os campos que um critério nomeia, suas unidades, o carimbo de reprodutibilidade com hash do cenário, semente, versão do motor e versão do esquema, e o rótulo e os níveis das figuras da execução), seu report.json (tipo de cenário, registro de reprodutibilidade e rótulos de capacidade), o arquivo de cenário (seu hash, tipo de cenário, semente e parâmetros), o esquema de unidades de campo (a unidade, a procedê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).

Suporte 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:

• Suporte comercial e integração — incorporação do Kshana à sua cadeia de ferramentas, cenários personalizados e correções prioritárias.
• Modelos de sensor sob medida — calibrados ao seu hardware, incluindo modelos de resiliência sujeitos a controle de exportação mantidos em uma camada privada.
• Kshana Pro — ferramentas proprietárias de engenharia de sistemas baseada em modelos (MBSE) e de programa que conferem os requisitos de um programa com 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 mudanças e um pacote de evidências offline. Elas não reexecutam nada e leem apenas as saídas publicadas do motor: o result.json e o report.json de cada execução, o arquivo de cenário, o esquema de unidades de campo e os rótulos da matriz de verificação (a lista completa está em Edições).
• Ferramentas do Kshana Pro para projeto, incerteza e missão — a fronteira 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 único comando, com matriz de verificação e um PDF; consulte docs/PRO.md.
• Acompanhamento de campanha, coexistência espectral e serviço de tarefas do Kshana Pro — um pipeline que falha quando uma figura monitorada piora, planos de sinal testados em relação aos sinais abertos de navegação por satélite nos dois sentidos e uma fila local de tarefas com um registro de entregas encadeado por hash; consulte docs/PRO.md.
• Treinamento e consultoria em análise de desempenho de PNT quântico/clássico.

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

Instalar e compilar#

Requer uma cadeia de ferramentas Rust (≥ 1,88, o 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

Uso#

Execute qualquer cenário; a CLI despacha pelo campo kind do cenário e grava <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html e <scenario>.report.json ao lado dele — além de <scenario>.table.csv para os tipos de cenário que publicam uma tabela. O relatório (uma página HTML (HyperText Markup Language) e um documento JSON com o mesmo conteúdo) traz um resumo executivo, cada entrada com sua unidade, os resultados e gráficos, as tabelas de varredura, Monte Carlo ou cadeia de uma campanha, uma linha do tempo de eventos, o rótulo VALIDATED / MODELLED / PARTNER e a origem de cada capacidade usada pela execução, o que não é modelado e um registro de reprodutibilidade (versão do motor, resumos Secure Hash Algorithm 256-bit (SHA-256), semente, plataforma e o comando exato). Ele é impresso como um arquivo PDF (Portable Document Format) limpo a partir do navegador em papel A4 ou Carta; o motor não grava nenhum PDF por conta própria. 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> grava ao lado do cenário CZML (a Cesium Language), KML (Keyhole Markup Language), GeoJSON (Request for Comments 7946), efemérides .e do Ansys STK (Systems Tool Kit) e gravações SigMF (Signal Metadata Format), e --import-route <route.geojson> injeta uma linha GeoJSON nos tipos de cenário que percorrem uma trilha. Cada formato é validado em relação à sua especificação publicada, e um cenário ao qual um formato não se aplica diz por quê: consulte docs/INTEROP.md.

Outros modos da CLI — verificar um cenário com lint, fornecer dados reais de orientação da Terra ou executar uma suíte inteira:

# 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ção. --animate svg|html|frames|all grava <scenario>.animation.svg (keyframes de Cascading Style Sheets (CSS), sem script), <scenario>.animation.html (reproduzir, pausar, arrastar, velocidade e painéis sincronizados, sem nenhum recurso externo) e <scenario>.frames/ (frame_0000.svg, … mais manifest.json com os quadros por segundo e a duração). Uma campanha reproduz suas fases e alarmes, uma execução de espectro sua cascata; o tema segue prefers-color-scheme e prefers-reduced-motion mostra a imagem final. Ele renderiza as amostras da própria execução, idênticas byte a byte em uma nova execução, e não acrescenta nenhuma evidência. Consulte docs/ANIMATION.md.

Um manifesto de suíte é um pequeno arquivo TOML (Tom's Obvious, Minimal Language) — um title e uma matriz scenarios = [ … ] de caminhos de cenário — que o motor executa em sequência, reunindo cada resultado (com seus rótulos MODELLED / VALIDATED) em um único artefato de estudo autodescritivo. Consulte scenarios/quantum-pnt-demonstrator.suite.toml.

Papel de interoperabilidade. O Kshana é a camada de simulação de desempenho que fica ao lado da cadeia de ferramentas de pós-processamento, e não uma substituta dela: alimente sua saída RINEX no RTKLIB ou no gLAB para obter uma solução de posição e use sua saída SP3 como produto de órbita precisa para ferramentas como o Ginan — o Kshana responde que resiliência uma dada arquitetura de PNT proporciona antes de você ter sinais reais, em formatos que essas ferramentas já ingerem (--export-sp3, ou export_sp3 = true em um cenário orbit, grava <scenario>.sp3). A mesma órbita pode ser publicada como elementos médios CCSDS OMM da trilha de normas (--export-omm, ou export_omm = true, grava <scenario>.omm) — uma mensagem OMM 502,0 KVN (notação palavra-chave = valor) por satélite definido por TLE, trazendo o número de catálogo NORAD (North American Aerospace Defense Command) real de cada objeto, o designador internacional COSPAR (Committee on Space Research) e a época, para qualquer consumidor que entenda OMM, em vez de um conjunto de elementos de duas linhas sob medida.

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

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 óptico é 1.20e-4 ns: o resumo imprime valores pequenos com algarismos significativos em vez de arredondá-los para 0.0. security lê n/a (no attack) porque este cenário não configura nenhum ataque, portanto não há nada a detectar. O resultado JSON ainda traz o limite analítico de detectabilidade de spoofing de cada relógio em fom.security (0,997 para o relógio óptico, 0,000 para o relógio atômico em escala de chip, cujo próprio ruído na janela de monitoramento excede a especificação de 20 ns), e seu bloco figure_tiers marca essa figura como applicable: false. O tipo de cenário spoof pontua a detecção contra um ataque injetado. figure_tiers também dá a cada figura relatada o seu nível de verificação — VALIDATED (verificado em relação 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 relata adicionalmente um bloco de geometria — fração de amostras com solução e melhor/mediana diluição de precisão de posição (PDOP) e exatidão de posição — ao lado do resultado do relógio.

Leia estes dois números com atenção. security é um limite analítico de detectabilidade de spoofing derivado da estabilidade de cada relógio — só tem significado diante de um cenário de spoofing configurado e não é um detector RAIM com vários satélites. integrity aqui é a autoconsistência do filtro (fração das amostras de interrupção dentro do seu próprio limite k-sigma), não uma figura de integridade HPL/VPL de aviação. Consulte docs/INTEGRITY.md.

Para integridade autônoma genuína do receptor, o tipo de cenário integrity (scenarios/integrity-raim.toml) executa RAIM real de snapshot e de separação de soluções (estilo ARAIM) sobre a geometria propagada da constelação: ele calcula níveis de proteção horizontal/vertical (HPL/VPL) por época e relata a fração de épocas que atendem aos limites de alerta configurados, com um diagrama de integridade de Stanford para classificação de erro versus PL (nível de proteção).

Artefatos de estudo reproduzíveis

Quatro estudos abertos regeneram, cada um, um artefato determinístico byte a byte (semente fixa) com um único comando — os números por trás dos estudos de cruzamento quântico versus clássico, de lacuna de otimismo por degradação de RF, de pontuação de resiliência de PNT e de 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 artefato registra a versão do motor, as sementes e um hash de configuração, e traz um rótulo honesto MODELLED/VALIDATED. As sondas com dados reais (*_probe) executam o mesmo pipeline sobre gravações que você fornece localmente; nenhum conjunto de dados é distribuído no repositório. O estudo da lacuna de otimismo por degradação 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 de superfície, arXiv:2607,02566 observabilidade por VLBI e arXiv:2610,23871 observabilidade cislunar por comprimento de arco) têm suas afirmações de geometria, de diluição de precisão, de predição em tempo real de referencial / parâmetros de orientação da Terra (EOP), de órbitas retrógradas distantes e de medição de distância por RF conferidas de forma cruzada e independente em tests/validate_p*.rs com referências independentes separadas (scipy.special.j1, uma solução de DOP independente em NumPy (HᵀH)⁻¹, uma nova leitura em NumPy das mesmas linhas finals2000A do IERS e o NASA/JPL Three-Body Periodic Orbit Database). Estas são verificações de regressão adicionais sobre o conjunto lunar modelado; elas 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 ao todo (clock é o padrão se 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 (bancada de avaliação de detecção de degradação de RF por aprendizado de máquina — corpus sintético rotulado + arcabouço de ROC/AUC independente do detector + lacuna de otimismo dentro/fora da distribuição), quantum-trade (trade quântico versus clássico de PNT com ingestão de ADEV medido + envelope de resiliência sem GNSS; MODELLED), space-weather (índices solares/geomagnéticos + temperatura exosférica de Jacchia-71 + densidade termosférica dirigida pela atividade sobre a atmosfera estática; MODELLED), oem-interop (ponte de importação/ida e volta de OEM CCSDS 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 Space Packet TM/TC — telemetria/telecomando — CCSDS 133,0 — leiaute exato de bits, ida e volta verificada) e attitude-budget (torque de gradiente gravitacional em 3 graus de liberdade + orçamento de erro de apontamento RSS), passes (predição de passagens de nascer/pôr em estação terrestre — AOS/TCA/LOS, elevação máxima, acesso) e link-budget (equação de enlace CCSDS/DSN de sentido único — FSPL / Eb·N₀ / margem / fechamento); telecom-timing (erro de tempo em holdover, MTIE e TDEV verificados em relação a máscaras ITU-T); spectrum (toda a banda L do GNSS como uma única densidade espectral de potência: uma cascata de frequência por tempo sob uma linha do tempo roteirizada de jammer de onda contínua, banda estreita, chirp ou ruído casado, razão jammer-sinal por banda e densidade efetiva de portadora para ruído a partir do coeficiente de separação espectral, e entrada e saída de gravações Signal Metadata Format (SigMF) com estimativas espectrais de Welch; os espectros de sinal VALIDATED em relação a valores de manual, o cenário de jammer MODELLED; consulte docs/SPECTRUM.md; o mesmo tipo de cenário desenha painéis das bandas UHF, S e C com sinais projetados de órbita baixa da Terra); leo-signal (projetos de sinais de posicionamento, navegação e temporização em órbita baixa da Terra para qualquer sistema: espectros limitados em banda, jitter de rastreamento de código e exatidão de medição de distância, busca e tempo de aquisição, separação espectral em relação a GPS e Galileo, tolerância a jammer e um trade de banda UHF a C, a partir de predefinições públicas como Xona Pulsar, Iridium, Starlink e CentiSpace ou de projetos em linha; as formas fechadas e o Doppler LEO VALIDATED, os projetos MODELLED; consulte docs/LEO-SIGNAL.md); solar-system (o Sol, os planetas, Plutão, a Lua e sete luas principais em uma época — posições, constantes, tempos de luz e trajetórias orbitais; posições dos planetas VALIDATED em relação ao JPL Horizons) e body-pnt (posicionamento em torno de qualquer um desses corpos com uma constelação de navegação local e um enlace de espaço profundo a partir da Terra; MODELLED); campaign (tipos de cenário existentes compostos em uma linha do tempo de missão encadeada com o estado passado entre as fases, uma varredura de parâmetros, um conjunto Monte Carlo com semente, ou vários cenários sob uma condição compartilhada; 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 de GPS, Galileo, BeiDou e GLONASS, e cobertura e diluição de precisão sobre uma grade de latitude/longitude; o gerador e o DOP global do GPS VALIDATED em relação 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 baixa da Terra (LEO) e seu orçamento de enlace banda a banda, a partir de qualquer constelação e de qualquer projeto de sinal: ângulos de visada, Doppler e taxa de Doppler, perdas ITU-R por chuva, gases, cintilação e penetração em edifícios, densidade de portadora para ruído em relação 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 baixa energia, sondagem da ionosfera a partir de cada par de bandas, e monitores de spoofing por consistência de Doppler e da geometria da passagem e por consistência entre bandas; os termos ITU-R e o envelope Doppler de usuário estático VALIDATED, a passagem MODELLED, consulte docs/LEO-PASS.md); leo-navmsg (a mensagem de efemérides e de relógio transmitida por um satélite de PNT em órbita baixa da Terra (LEO), para qualquer órbita e portadora: um ajustador de uma órbita verdadeira integrada para o conjunto kepleriano do Galileo, esse conjunto com polinômios de correção ao longo da trajetória, transversais e radiais, 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 de atualização no meio da passagem, o formato binário próprio e documentado 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 usuário 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 Doppler a partir da taxa de variação da distância em órbita baixa da Terra (LEO), soluções conjuntas de pseudodistância GNSS + LEO com vieses entre sistemas e o DOP em função do número de satélites LEO, cobertura polar e ártica, 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; o envelope Doppler LEO VALIDATED em relação a valores publicados do Iridium e da Xona), leo-ppp (convergência do posicionamento por ponto preciso apenas com GNSS e com aumento 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 esse envelope, consulte docs/LEO-PNT-FUSION.md; leo-pnt-chain (um sistema de PNT LEO 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 entregues a uma solução leo-pvt fundida e à convergência leo-ppp, com cada transferência listada; MODELLED, consulte docs/LEO-PNT.md, que também é a visão geral de todos os tipos de cenário e cenários de PNT LEO, incluindo as campanhas de resiliência, um cenário por área de foco de experimento e um por vertical de usuário 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 habilitado por tecnologia quântica quantum-time-transfer, quantum-gnss-free-nav, quantum-anomaly-detect; e os tipos de cenário de pesquisa 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 posteriores são todos MODELLED (cada um com um núcleo de forma fechada validado; consulte a matriz). Campos comuns: seed, uma grade [time], uma linha do tempo de disponibilidade [gnss] (o que dirige a interrupção) e blocos por sensor com strings provenance que citam a fonte de cada figura. 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 (piso de Allan de 1/f FM — modulação em frequência); um sensor inercial pode acrescentar gyro_bias e q_arw (viés do giroscópio e passeio aleatório angular), e bias_instability e q_aa (o piso de Allan de instabilidade de viés e o passeio aleatório de aceleração) — juntos formam um orçamento de erro de acelerômetro de eixo único (1 grau de liberdade) (VRW/ARW — passeio aleatório de velocidade/angular — e instabilidade de viés). Este é o orçamento de erro que o pacote de cenários inertial distribuído executa. Separadamente, a biblioteca agora traz um navegador strapdown de 3 eixos verificado (src/inertial/{attitude,mechanization,imu_errors}.rs): atitude por quatérnions com compensação de coning/sculling, uma mecanização NED completa (termos de taxa da Terra e de taxa de transporte, gravidade de Somigliana do WGS-84) e um modelo determinístico de erros de IMU em que fator de escala, desalinhamento, sensibilidade à gravidade, quantização e rampa de taxa são modelados (IEEE Std 952-1997, o padrão IEEE de especificação e procedimento de teste de giroscópios, §A.2; Groves 2013 §4,3). Esse caminho de 3 eixos agora está 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 em relação a posições ruidosas enquanto o GNSS está ativo e depois segue em deriva durante a interrupção, relatando o erro horizontal fundido em relação à deriva do INS livre em malha aberta. Uma atualização de pseudodistância fortemente acoplada também está disponível (ela forma a inovação no domínio da distância, de modo que continua corrigindo 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 relatada como média com uma dispersão entre os percentis 5 e 95, e o gráfico sombreia a faixa de confiança do erro (consulte scenarios/clock-ensemble.toml).

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

Um cenário spoof injeta um spoofing de tempo — um dos quatro tipos de [attack.shape] (linear_ramp, step_jump, meaconing, replay; um simples rate_ns_per_s ainda é aceito como rampa linear) — e executa o detector de spoofing de cada relógio. O detector é um teste de energia χ²₁ / Neyman–Pearson bilateral sobre a estatística de monitoramento auxiliada pelo relógio: o limiar é definido a partir de um orçamento alvo de falsos alarmes target_pfa, e a probabilidade de detecção perdida P_md é relatada tanto em forma fechada quanto por Monte Carlo (mc_runs tentativas por hipótese — as duas concordam até alguns ×1/√N). A figura de mérito de Segurança é 1 − P_md na magnitude operacionalmente danosa (da especificação), de modo que um relógio silencioso que detecta um spoof do tamanho da especificação pontua ≈ 1 e um ruidoso que frequentemente o perde pontua menos (consulte scenarios/spoof-attack.toml, scenarios/spoof-meaconing.toml).

Um cenário gnss-sim é uma simulação no domínio da medição: para cada satélite visível ele 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 snapshot para HPL/VPL por época, e a pseudodistância, o Doppler, o C/N₀ e as correções ionosféricas/troposféricas de cada satélite são emitidos na matriz JSON gnss_measurements. É um simulador direto (gera medições a partir de uma verdade conhecida), não um receptor/solucionador — uma execução sem ruído reproduz a geometria mais as correções em nível submilimétrico (consulte scenarios/gnss-sim-raim.toml).

Um cenário jamming modela a interferência de RF como um orçamento de enlace: um [jammer] (posição ECEF, power_dbw de transmissão, tipo) eleva a razão jammer-sinal em um [receiver] que observa uma [constellation] Walker. A partir da geometria (perda de percurso em espaço livre e o ganho da antena receptora por direção) ele calcula o J/S de cada satélite, o C/N₀ efetivo pela equação padrão antijamming (ganho de processamento de despreading × o fator de separação espectral Q; Kaplan & Hegarty §9,4), e sinaliza a perda de travamento abaixo de um limiar de rastreamento configurável — relatando uma figura de mérito availability_under_jamming. Um jammer de banda larga de 10 W a 1 km nega totalmente o receptor (J/S ≈ 72 dB); o mesmo jammer a 100 km apenas degrada os enlaces (consulte scenarios/jamming-demo.toml).

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

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

Um cenário orbit deriva a linha do tempo [gnss] da geometria em vez de ela ser escrita à mão — forneça uma órbita [user], uma [constellation], uma mask_deg de elevação e os dois blocos de relógio. Ele também relata a exatidão de posição a partir da geometria dos satélites; o sigma_uere_m opcional (erro de distância equivalente do usuário de 1 sigma, padrão 1 m) converte a diluição de precisão de posição em um sigma de posição. A órbita do usuário pode ser tornada excêntrica com eccentricity e argp_deg, e j2 = true acrescenta a deriva secular por achatamento da Terra (consulte scenarios/orbit-molniya.toml). A constelação pode, em vez disso, ser uma real: dê a [constellation] um bloco tle de conjuntos de elementos de duas linhas e os satélites são lidos 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 cenário de PNT alternativo sem GPS navegam sem nenhum GNSS, correlacionando uma sequência de campo medida com um mapa por meio de um filtro de partículas. Um cenário gravity-map percorre uma trajetória por um campo de anomalia gravitacional de harmônicos esféricos e a recupera 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 em relação 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 em um único filtro (scenarios/combined-altpnt.toml).

Um cenário lunar-integrity avalia PNT cislunar: ele executa uma passagem de nível de proteção ARAIM no polo sul lunar contra um conjunto de retransmissores LunaNet/LNIS e relata 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, de modo que o serviço fica indisponível sob regras de integridade no estilo da aviação (scenarios/lunanet-araim.toml).

Um cenário lunar-time-offset relata a taxa relativística do relógio Terra–Lua — a base de uma escala de Tempo Coordenado Lunar (LTC/TCL). Uma identidade pós-newtoniana de primeiros princípios soma a diferença de potencial próprio (potencial do geoide L_G da IAU menos o potencial próprio da superfície da Lua) e o termo cinético da Lua (Doppler de segunda ordem) em uma taxa secular de ≈ 57 µs/dia, relatada com a faixa publicada de 56–59 µs/dia; ele também dá o deslocamento LTC−TT acumulado ao longo de um horizonte e um conjunto de variância inversa (um relógio de papel lunar). MODELLED — a figura principal é dependente da referência (geoide terrestre versus selenoide lunar, janela de média), razão pela qual se relata uma faixa, 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 arquivos .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 arquivo 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 artefato de resultado é um JSON versionado e autodescritivo: séries temporais por passo, as figuras de mérito pontuadas, as especificações de modelo ativas (com procedência), a semente, um hash do cenário — de modo que qualquer gráfico possa ser reproduzido a partir do arquivo — 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 em oitavas — a forma padrão de ler a estabilidade de um relógio — agora com uma faixa de confiança de 95% específica do tipo de ruído por ponto (o tipo de lei de potência do registro é identificado a partir de sua inclinação de Allan modificada, e o intervalo χ² usa os graus de liberdade efetivos correspondentes do NIST SP 1065). O playground do navegador o renderiza como um gráfico log-log "Clock stability (ADEV)". (MDEV, TDEV e HDEV estão disponíveis como estimadores da biblioteca; a curva exportada do resultado é o ADEV sobreposto.) Cada campo, com unidades e uma indicação da fonte, está documentado em docs/SCHEMA.md.

Todo gráfico é autodescritivo. O playground do navegador, a exportação *.chart.svg da CLI e o painel de resultados em HTML (HyperText Markup Language) carimbam 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 caracteres hexadecimais do hash do cenário da execução — um resumo SHA-256 (o Secure Hash Algorithm de 256 bits) da definição canônica do cenário (semente, limiares, parâmetros de modelo, 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, de modo que um gráfico salvo ou colado sempre traz sua versão, o cenário exato que o produziu (para reprodução bit a bit) e a fonte — mude qualquer entrada e o hash muda.

As figuras de mérito seguem as figuras de mérito operacionais padrão de PNT:

Novo nesses 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 entender física quântica para usar isto? Não. Se você sabe executar uma linha de comando, sabe executar o Kshana. Comece pela introdução em linguagem simples; consulte os termos no glossário.

Isto é um projeto de hardware quântico ou um 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 é citado a partir de uma folha de dados ou de um artigo, cada modelo é validado em relação a uma relação de manual, e a maturidade é rotulada com honestidade em VALIDATION.md — inclusive o fato de que nenhum relógio óptico de estrôncio já 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 determinísticas: scenario + seed + engine version → bit-identical output, garantido por scripts/check-reproducible.sh.

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

Como modelo meu próprio sensor? Escreva um .toml de cenário com as figuras publicadas 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, inclusive em contextos comerciais, desde que você respeite o copyleft da AGPL (em especial: se você modificar o Kshana e oferecê-lo por uma rede, deverá oferecer a esses usuários o seu código-fonte modificado). Se isso não lhe serve — por exemplo, se você precisa incorporar o Kshana a um produto proprietário ou executar um serviço de rede fechado — uma licença comercial está disponível na Ashforde® OÜ; consulte LICENSING.md e Suporte.

Solução de problemas#

cargo build falha em uma 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 seus símbolos em tempo de carga. maturin define automaticamente o sinalizador correto do linker — use maturin develop --features python em vez de um simples cargo build.

A compilação do Python reclama que o interpretador é mais novo do que o PyO3 conhece. Defina PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 (as wheels abi3 têm compatibilidade futura entre versões do CPython).

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

Para onde foi minha saída? Cada execução grava <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html e <scenario>.report.json ao lado do .toml de entrada, e também <scenario>.table.csv para os tipos de cenário que publicam uma tabela. Todos eles são ignorados pelo git por projeto.

Versionamento e lançamentos#

O Kshana segue o Versionamento Semântico. Enquanto estiver antes da 1.0, o esquema público de cenário/resultado ainda pode mudar; as mudanças incompatíveis são destacadas explicitamente em CHANGELOG.md. Todo resultado é reproduzível a partir de scenario + seed + engine version.

Toda tag vX.Y.Z publica todos os canais automaticamente, em uma única ordem — a suíte de testes completa é executada primeiro no commit com tag, nada é publicado até que ela passe, e depois o pipeline confere se cada registro realmente serve a nova versão (docs/RELEASING.md). Os canais:

A versão do crate / imagem / registro do servidor MCP acompanha o motor (ele inclui a biblioteca); o plugin do JetBrains tem versionamento independente (ele chama o binário kshana que você instalou).

Roteiro#

Consulte ROADMAP.md para o roteiro em fases, CHANGELOG.md para o histórico de versões publicadas e docs/CAPABILITY.md para o roteiro por capacidade. A ordem de prioridade é: primeiro, evidências de temporização e holdover para infraestrutura crítica (máscaras de telecomunicações, holdover mais longo com envelhecimento e ruído flicker, ingestão de dados de relógio medidos); em segundo, o método neutro de trade quântico versus clássico (resultados rotulados MODELLED até que os dados medidos de um parceiro os promovam); e a navegação lunar / cislunar e de espaço profundo mantida, não ampliada como prioridade principal. A redução de referencial precisa para o ITRF agora está entregue — a cadeia completa GCRS↔ITRS da IAU 2006/2000A baseada no CIO (movimento polar + nutação abaixo de um segundo de arco), validada bit a bit em relação ao SOFA/ERFA e conferida de forma cruzada e independente com o ANISE (SPICE em Rust puro) em ≤ 3,6 m na órbita GNSS. Os itens de curto prazo incluem a fusão de fase da portadora fortemente acoplada e a exposição do navegador GNSS/INS fracamente/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 primeiros princípios (fase de Mach–Zehnder, ruído de projeção, decaimento de contraste, acoplamento de vibração), enquanto os sensores de relógio/transferência de tempo ainda são dirigidos por coeficientes publicados de Allan/orçamento de ruído. TEME↔ECEF baseado em GMST, os sistemas de tempo IERS com segundos intercalares (UTC/TAI/TT/UT1), a propagação de órbita SGP4/SDP4 (v0.7.0, validada em relação 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. Um detector estocástico ativo de spoofing de tempo (teste de energia 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 orçamento de enlace (J/S → C/N₀ efetivo → perda de travamento), disponibilidade multiconstelação, um orçamento de erro de IMU de eixo único (1 grau de liberdade), dois estimadores de Kalman independentes (relógio + posição) relatados como uma FoM combinada, geometria real de constelação a partir de TLEs, um relatório de painel de resultados em HTML, disponibilidade GNSS derivada da geometria e diluição de precisão a partir de órbitas keplerianas com excentricidade e deriva de J2, faixas de confiança Monte Carlo, varreduras de parâmetros de estudos de trade, um playground WebAssembly no navegador e ligações opcionais para Python (PyO3) e WebAssembly (wasm-bindgen) chegaram ao main.

Como 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 mudança visível ao usuário. A participação é regida pelo nosso Código de Conduta. Para relatar um problema de segurança, consulte a Política de segurança — não abra uma issue pública para vulnerabilidades.

Documentação#

Referências principais#

Referências independentes de validação e normas — as autoridades externas às quais 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 do SGP4/SDP4 com o qual o Kshana coincide em 4,12 mm, e os exemplos práticos de referenciais com os quais a cadeia TEME→ITRF é conferida.
• IAU SOFA / ERFA — as rotinas de referência de tempo e referenciais com as quais a nutação IAU 2000A e a redução GCRS↔ITRS baseada no CIO são validadas bit a bit.
• Petit & Luzum (orgs.) — IERS Conventions (2010), IERS TN (Technical Note) 36 (orientação da Terra, movimento polar e padrões 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 a bancada de avaliação de degradação 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 com as quais o ajuste NNLS de ADEV medido do trade quântico, as faixas de consistência χ² e a covariância de 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 arte aberto (veja Comparação e estado da arte aberto abaixo) quanto como a referência independente de DOP com a qual o cálculo de GDOP/PDOP/HDOP/VDOP/TDOP coincide em 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 a 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 métodos — as fontes citadas por trás dos modelos de sensor:

• Origlia, Schiller, Bongs et al. — arXiv:1503,08457 (relógio óptico de rede de estrôncio, meta voltada ao 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 Discovery da University College London) (crescimento do erro na navegação por estima (dead reckoning)).
• 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 óptica bidirecional de tempo e frequência; o enlace óptico entre satélites modela 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 de separação espectral por trás de src/navsignal.rs).
• Kaplan & Hegarty (orgs.) — Understanding GPS/GNSS: Principles and Applications (3ª ed., Artech House, 2017): a equação de C/N₀ efetivo antijamming e o jitter de ruído térmico do rastreamento de código por DLL early–late que os modelos de sinal de navegação e de jamming usam.

Comparação e estado da arte aberto — as ferramentas e levantamentos em relação aos quais o Kshana se posiciona:

• Humphreys et al. — TEXBAT (o Texas Spoofing Test Battery; ION — Institute of Navigation — GNSS 2012): os parâmetros da bateria de testes de spoofing com os quais o detector multicamadas é 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: OD de dinâmica reduzida do GRAIL, o piso de aceleração empírica que o ajuste do LRO reproduz.