Mapa de capacidades — o que o Kshana faz, faz parcialmente e não faz
O Kshana é um motor de evidências de desempenho e resiliência PNT (posicionamento, navegação e temporização), não um conjunto completo de ferramentas de sistemas espaciais. Dá primazia à temporização e ao holdover, o seu domínio mais bem validado (ver POSITIONING.md). Esta página é o mapa franco do âmbito: para cada área de capacidade que um revisor de aquisições ou de investigação possa verificar, indica o estado, o que realmente existe no código, o que falta e em que ponto do roteiro se encontra. O estado é um de:
- full — implementado de ponta a ponta e validado a um nível indicado na linha;
- partial — um modelo real mas limitado (âmbito explicitamente delimitado abaixo);
- none — não modelado (fora do âmbito atualmente).
Estes três são os únicos valores que a coluna de estado assume. Classificam a maturidade da capacidade, que é um eixo diferente da classificação VALIDATED / MODELLED / PARTNER em VERIFICATION-MATRIX.md — essa classifica a proveniência da evidência, linha a linha, e é verificada por máquina a partir de src/verification.rs.
Nada aqui é aspiracional: "partial" nunca significa "quase concluído", significa "isto e nada mais". Ver também VALIDATION.md, INTEGRITY.md, QUANTUM-MODELS.md e o registo de encerramento de afirmações excessivas CLAIMS-VS-REALITY.md (cada afirmação excessiva histórica, como foi resolvida e uma proteção de CI (integração contínua) que a mantém resolvida).
PNT essencial (onde o Kshana realmente atua)#
| Capacidade | Estado | O que existe | O que falta | Roteiro |
|---|---|---|---|---|
| Determinação e propagação de órbita | partial | SGP4/SDP4 sem dependências (SGP4: Simplified General Perturbations 4; SDP4: Simplified Deep-space Perturbations 4), validado até 4,12 mm face a todos os 666 vetores AIAA (American Institute of Aeronautics and Astronautics) 2006-6753 (posição e velocidade, esta última até 1 mm/s); kepleriano analítico + secular de J2; velocidade inercial exposta e disponibilizada de ponta a ponta através do cenário ephemeris executável (src/ephemeris.rs, acessível a partir de CLI/Python/WASM/MCP (CLI: interface de linha de comandos; WASM: WebAssembly; MCP: Model Context Protocol)) — por passo emite o estado TEME (true equator, mean equinox) e GCRS (Geocentric Celestial Reference System) (posição + velocidade), a posição ITRF/ECEF (ITRF: International Terrestrial Reference Frame; ECEF: Earth-centred, Earth-fixed), a projeção do ponto subsatélite WGS-84 (WGS: World Geodetic System) (lat/lon/alt), e azimute/elevação/distância da estação + taxa de variação da distância/Doppler (a taxa radial de variação da distância coincide com a derivada real da posição, sem ruído de JD (JD: data juliana), até 6e-9 m/s) — e através da exportação de efemérides com velocidade OEM (Orbit Ephemeris Message) do CCSDS (Consultative Committee for Space Data Systems) (--export-oem). Um propagador numérico (Cowell) (src/propagator.rs) integra um modelo de forças de gravidade zonal configurável — o campo zonal completo da Terra até ao grau 6 (forces::zonal_accel, o J2..J6 publicado do EGM-96 (EGM: Earth Gravitational Model)) — com uma escolha de integrador adaptativo — RK4 (Runge–Kutta de quarta ordem) com duplicação de passo ou o par embebido Dormand–Prince RK5(4) (integrate_dopri / propagate_dopri, uma estimativa de erro embebida mais económica, com 7 avaliações, que satisfaz a mesma barreira de Kepler e concorda com o caminho RK4 até <1 m numa órbita J2..J6) — fixado face a uma referência analítica mais forte do que uma comparação numérica entre ferramentas: a órbita sem perturbações reproduz a solução de Kepler exata em variáveis universais a menos de um metro ao longo de 24 h (uma barreira mais apertada do que a do marco, "face à referência < 10 m"), a energia e o momento angular conservam-se até ~1e-9 em termos relativos, a regressão nodal de J2 coincide com a taxa secular de forma fechada segundo a teoria de primeira ordem, verifica-se que a aceleração zonal é o gradiente exato do seu próprio potencial (e que se reduz à forma fechada de J2 validada com os 666 vetores), e solve_kepler_checked devolve Err em vez de uma resposta errada quando o Newton não converge (por exemplo, perto do perigeu com e = 0,999). A gravidade de terceiro corpo (Sol e Lua) dirigida por época está ligada ao integrador variável no tempo (ForceModel::third_body / accel_at, com as efemérides de baixa precisão do Sol e da Lua de Montenbruck & Gill em src/ephem.rs — sem necessidade de kernel DE/SPK (DE: Development Ephemeris; SPK: kernel de efemérides planetárias)): cada avaliação do RHS (right-hand side, membro direito) amostra as posições dos perturbadores na época avançada epoch_jd_tt + t/86400, de modo que o Sol e a Lua se movem ao longo das suas órbitas durante a integração. Verifica-se que a perturbação é o gradiente exato do seu potencial perturbador, anula-se no geocentro e tem as magnitudes LEO (órbita terrestre baixa) de manual (~5e-7 m/s² do Sol, ~1.1e-6 m/s² da Lua); as efemérides do Sol atingem âncoras J2000 derivadas à mão (distância ao periélio, declinação de solstício de ~−23°, movimento de ~1°/dia) e as da Lua o seu envelope de perigeu/apogeu, a distância média de ~384 400 km, o limite de inclinação ≤ 5,3° e o retorno da direção ao fim de um mês sideral; e a ligação da integração está comprovada como exata ao bit (o termo do RHS é igual a third_body_accel na posição amostrada em t = 0 e t = 1 dia), com um desvio de época de um quarto de ano a produzir uma trajetória diferente. A pressão da radiação solar (SRP) usa o mesmo RHS dirigido por época (forces::srp_accel / ForceModel::solar_radiation): o modelo de bola de canhão ν·P☉·cᵣ·(A/m)·(AU/d)²·d̂ com um fator de eclipse de umbra+penumbra forces::conical_shadow (ν ∈ [0 1] suave, verificado como decaindo através de uma penumbra monótona que se estende para além do cilindro de umbra), verificado face à pressão de manual a 1 UA (UA: unidade astronómica) (≈ 4.54e-6 N/m²), à magnitude LEO de ~1.36e-7 m/s² que empurra para longe do Sol, à queda com o inverso do quadrado (duplicar a distância ao Sol divide-a por quatro), a uma aceleração exatamente nula no cilindro de umbra e a um deslocamento propagado que escala de forma ~linear com A/m. O arrastamento atmosférico é o primeiro termo dependente da velocidade (forces::drag_accel / ForceModel::drag + o novo RHS accel_rv / com passagem de velocidade): arrastamento quadrático −½·ρ(h)·(C_D·A/m)·|v_rel|·v_rel face à atmosfera em co-rotação v_rel = v − ωₑ ẑ × r, sendo ρ o forces::atmospheric_density exponencial por troços de Vallado — verificado pela âncora de 1,225 kg/m³ ao nível do mar, por um decaimento LEO estritamente monótono com uma altura de escala física de ~58 km, pela magnitude de arrastamento de ~2e-6 m/s² a opor-se à velocidade relativa e pela assinatura de dissipação (uma órbita de 300 km perde energia específica de forma monótona e o seu semieixo maior decai uns ~km/dia limitados, ao passo que a órbita no vácuo conserva a energia). A correção relativista pós-newtoniana (Schwarzschild) é o segundo termo dependente da velocidade (forces::relativistic_accel / ForceModel::relativity): a forma β = γ = 1 do IERS (International Earth Rotation and Reference Systems Service) a = (μ/c²r³)·{[4μ/r − v²]·r + 4(r·v)·v}, o principal responsável pelo avanço relativista do perigeu — verificada face ao seu valor circular de forma fechada 3μ²/(c²r³)·r̂ (radial, para fora), à sua razão de manual ≈1.9e-9 para LEO em relação ao problema de dois corpos, à forma de velocidade radial simplificada à mão e à assinatura conservativa (perturba a órbita mas mantém o semieixo maior a menos de um metro/dia, o oposto estrutural do arrastamento). O termo de arrastamento de referencial de Lense–Thirring (forces::lense_thirring_accel / ForceModel::lense_thirring, IERS 2010 §10) é a correção gravitomagnética para além de Schwarzschild — opcional, ~1–2 ordens de grandeza abaixo dela em LEO, verificado como anulando-se sem rotação da Terra e situando-se abaixo da magnitude de Schwarzschild. A determinação de órbita (OD, src/orbit_determination.rs) fecha o ciclo das observações de volta a um estado: um corretor em lote de Gauss–Newton (src/batch_ls.rs) leva um [r, v] candidato ao melhor ajuste de distâncias de estações terrestres propagadas ao longo do arco (sub-métrico / mm·s⁻¹ a partir de distâncias sem ruído; ~2 m com um resíduo pós-ajuste no piso de ruído de 5 m — a assinatura de um ajuste de mínimos quadrados consistente), com uma variante recursiva sequencial sobre o filtro unscented |
O modelo de forças de Cowell predefinido inclui apenas o campo zonal: o campo tesseral EGM2008 (Earth Gravitational Model 2008) de alto grau (src/gravity_sh.rs, grau/ordem 70, com um carregador from_gfc para ficheiros ICGEM (International Centre for Global Earth Models)) só é composto no motor de ajuste preciso de efemérides (src/precise_od.rs; ver AGENCY-ORBIT-VALIDATION.md); a densidade de arrastamento é a exponencial por troços de Vallado estática (independente da atividade solar), não a NRLMSISE-00 (o modelo de atmosfera estendido de espetrómetro de massa e radar de dispersão incoerente do Naval Research Laboratory; a cláusula de densidade termosférica de < 5 %); a SRP é o modelo de bola de canhão com uma sombra geométrica cónica de umbra+penumbra (sem escurecimento de bordo solar, sem sombra de Terra achatada, sem forma/atitude do satélite); a relatividade abrange os termos de Schwarzschild e de Lense–Thirring (arrastamento de referencial), ambos opcionais, mas sem ajuste de parâmetros PPN (PPN: pós-newtoniano parametrizado); o terceiro corpo e a SRP usam as efemérides de baixa precisão (~0,005° para o Sol, ~0,3° para a Lua), não a exatidão de kernels DE/SPK. Os níveis conservativos do modelo de forças (dois corpos → J2–J6 → Sol/Lua → SRP) são VALIDATED face ao Orekit 12,2 (pior caso 0,08 m ao longo de 24 h, tests/numerical_cowell_propagator_reference.rs), e a determinação de órbita em lote/sequencial é VALIDATED face aos estimadores do Orekit 12,2 (tests/batch_sequential_orbit_determination_reference.rs); o nível de arrastamento e a fidelidade absoluta dos dados de efemérides/densidade mantêm-se MODELLED; não existe verificação cruzada com o GMAT (General Mission Analysis Tool) |
gravidade tesseral no modelo de Cowell predefinido + arrastamento NRLMSISE-00 + escurecimento de bordo solar + efemérides de nível DE + validação cruzada com o GMAT + medições de taxa de variação da distância/ângulo em OD e STM (matriz de transição de estado) analítica: P2+ |
| Sistemas de tempo | partial | src/timescales.rs: API de datas julianas (civil↔JD, MJD (data juliana modificada)), UTC↔TAI (UTC: Tempo Universal Coordenado; TAI: Tempo Atómico Internacional) através da tabela completa de segundos intercalares do IERS (10→37 s, 1972→2017), TAI→TT (TT: Tempo Terrestre), UT1 (Tempo Universal 1, tempo de rotação da Terra) através de DUT1 (o tempo de rotação da Terra menos o Tempo Universal Coordenado) e o Ângulo de Rotação da Terra IAU-2000 (IAU: União Astronómica Internacional) (ERA validado bit a bit face ao vetor eraEra00 do SOFA (Standards of Fundamental Astronomy)). A aproximação DUT1≈0 do caminho SGP4 está explicitamente documentada no ponto de chamada de gstime (um erro de GMST (tempo sideral médio de Greenwich) de ≤ ~13″, bem dentro do erro do próprio modelo SGP4), e o cenário ephemeris aceita parâmetros explícitos dut1_s/xp_arcsec/yp_arcsec ou uma série IERS finals2000A real incorporada (eop_finals2000a / kshana --eop <file>, interpolada através da mesma EopSeries que precise_od usa), de modo que a projeção no solo é reduzida através de UT1 e do movimento polar reais do IERS, e não apenas dos escalares nominais |
Os caminhos de órbita terrestre ainda usam um JD de f64 único (~50 µs de resolução perto de 2020 — este, e não o algoritmo, é o limite de uma verificação cruzada por diferenças finitas); existe um JD em duas partes (timescales::TwoPartJd, usado pelos caminhos radiométrico, CCSDS-TDM, de simulador de segmento terrestre e do sistema solar, e por src/jd2.rs Jd2) e é propagado através do SGP4 (Sgp4::propagate_at(Jd2)), da previsão de passagens, da geometria e dos projetos Walker (validado face ao SOFA, tests/jd2_sofa_time_oracle.rs), e através da rotação da Terra no caminho de órbita (jd2::gmst82, cio::gcrs_to_itrs_matrix_jd2, orbit::Propagator::position_in_frame_jd2, o two_part_jd opcional do cenário de efemérides; VALIDATED face ao ERFA, tests/jd2_earth_rotation_erfa_oracle.rs), com conversões sem perdas entre Jd2 e TwoPartJd; os caminhos de órbita terrestre predefinidos mantêm a data de f64 único, a menos que two_part_jd esteja definido, e a época do modelo de forças de Cowell permanece de f64 único de propósito (o seu erro analítico do Sol/Lua ofusca um arredondamento de 40 µs); o UTC de segundo elástico anterior a 1972 (1960–1971) é modelado no caminho de duas partes (jd2, timescales::tai_minus_utc_on_date, VALIDATED face ao ERFA, tests/jd2_pre1972_sofa_oracle.rs), mas timescales::tai_minus_utc de f64 único continua a limitar-se a 10 s antes de 1972; um preditor de orientação da Terra por mínimos quadrados + autorregressivo (src/eop_ls_ar.rs, comparado com o Boletim A do IERS como um resultado) pode agora estender uma série EOP para além da sua última linha (EopSeries::with_ls_ar_prediction, opcional; tests/eop_prediction_beyond_table.rs), de modo que os argumentos de referencial para lá da tabela seguem a previsão em vez de ficarem limitados; a série predefinida continua a limitar-se e nenhuma chave de cenário ativa ainda a previsão |
concluído (base); JD em duas partes na rotação da Terra no caminho de órbita: concluído (opcional no cenário de efemérides) ; previsão de EOP para além da tabela: concluído (biblioteca, opcional); UTC anterior a 1972 no caminho de duas partes: concluído |
| Referenciais | full | src/frames.rs: TEME↔ECEF baseado em GMST, geodésico WGS-84↔ECEF (exato + inversa iterativa, com precisão de máquina a todas as altitudes) e um observador geodésico de estação terrestre (azimute/elevação/distância); precessão IAU 2006 (src/precession.rs: os ângulos de Fukushima–Williams (γ̄, φ̄, ψ̄, ε̄_A) + a matriz de enviesamento-precessão GCRS↔média da data); nutação IAU 2000A/2000B + cadeia completa TEME→GCRS (src/nutation.rs: a série IAU 2000A completa — 678 termos luni-solares + 687 planetários, nutation_iau2000a / nutation_matrix_2000a, tabela gerada por máquina a partir da referência nut00a do ERFA (Essential Routines for Fundamental Astronomy) por tools/gen_nut00a.py — a par da série 2000B de 77 termos, dos argumentos de Delaunay, da matriz de nutação iauNumat do SOFA, da equação dos equinócios e de teme_to_gcrs(r, v, jd_tt) através de TEME→TOD→MOD→GCRS (verdadeiro da data, médio da data) — ambas as séries validadas bit a bit face aos vetores de referência nut00a/nut00b do SOFA/ERFA, Δψ/Δε até 1e-13 rad); movimento polar do IERS PEF→ITRF (pseudo-fixo à Terra para terrestre) (teme_to_itrf / polar_motion_matrix, iauPom00 do SOFA, x_p/y_p fornecidos por quem chama — um efeito de dezenas de metros ao raio orbital); redução IAU 2006/2000A baseada no CIO (CIO: Origem Intermédia Celeste) (src/cio.rs: a cadeia GCRS↔CIRS↔ITRS sem equinócio (CIRS: Sistema de Referência Intermédio Celeste; ITRS: Sistema de Referência Terrestre Internacional) — CIP (Polo Intermédio Celeste) X,Y a partir da matriz NPB (nutação-precessão-enviesamento) 2006/2000A, a série de 66 termos do localizador do CIO s, gcrs_to_cirs_matrix, o ângulo de rotação da Terra e o gcrs_to_itrs_matrix completo — validada bit a bit face aos vetores eraXys06a/eraC2ixys/eraEra00 do SOFA). As transformações de ponta a ponta estão agora fixadas a um exemplo trabalhado de referência e publicado, e não apenas à autoconsistência: face ao estado Vallado AIAA 2006-6753 (2004-04-06, com os seus EOP (parâmetros de orientação da Terra) do IERS; tests/frame_reference_vectors.rs), TEME→PEF coincide até 0,1 mm, TEME→ITRF até 0,6 mm, o GCRS→ITRS completo por CIO até 4 mm, e ECEF→geodésico reproduz lat/lon/alt do Exemplo 3-3 de Vallado até ao último dígito publicado. A cadeia completa é acessível ao utilizador através do cenário ephemeris (posição ITRF/ECEF + projeção do ponto subsatélite WGS-84 por passo) |
A cadeia TEME→GCRS predefinida usa 2000B (~1 mas, abaixo da sua própria simplificação de rotação de referencial de velocidade); o caminho de < 0,1 mas completo 2000A está disponível através de nutation_matrix_2000a, e a redução rigorosa por CIO (X, Y, s) está disponível através de src/cio.rs. O caminho TEME legado usa o GMST IAU-1982 (convenção SGP4). A verificação cruzada numérica independente com ANISE/SPICE (ANISE: Attitude, Navigation, Instrument, Spacecraft, Ephemeris — um conjunto de ferramentas de geometria planetária em Rust puro; SPICE: Spacecraft, Planet, Instrument, C-matrix, Events) está entregue (xval/anise-frames/: gcrs_to_itrs_matrix face ao GCRF→ITRF93 do ANISE (GCRF: Referencial Celeste Geocêntrico; ITRF93: Referencial Terrestre Internacional 1993) ao longo de oito épocas 2020–2023, ≤ 0,86 m no solo, ≤ 3,6 m em órbita GNSS (sistema global de navegação por satélite)); é uma crate autónoma fora das barreiras de CI predefinidas. precession_matrix e teme_to_gcrs_matrix são também verificadas diretamente face ao ERFA em 40 épocas 1950–2100, e a cadeia CIO aceita os desvios do polo celeste do IERS dX, dY (cio::gcrs_to_cirs_matrix_with_offsets; tests/frames_erfa_vector_oracle.rs); os caminhos predefinidos continuam a desprezar dX, dY. A matriz de verificação classifica esta linha como VALIDATED (vetores SOFA/ERFA + Vallado) |
TEME↔ECEF + geodésico: concluído (verificado com Vallado); TEME→GCRS inercial: concluído (2000B + 2000A completa); ITRF com movimento polar: concluído (verificado com Vallado); GCRS→ITRS por CIO: concluído (verificado com Vallado) |
| Temporização e frequência | partial | Relógio de Kalman de dois estados com Q de van Loan exata (NIST (National Institute of Standards and Technology) SP (Special Publication) 1065) com uma atualização de covariância estabilizada de Joseph (semidefinida positiva sob razões Q/R extremas, verificada por Cholesky em CI) e um monitor de saúde da consistência do filtro (src/filter_health.rs): uma avaliação NIS/NEES de Monte Carlo (NIS: inovação normalizada ao quadrado; NEES: erro de estimação normalizado ao quadrado) face a bandas de confiança χ², apresentada como filter_health no JSON (JavaScript Object Notation) do resultado e como um cartão verde/âmbar no playground, com um teste de varrimento de incompatibilidade Q/R que prova que o monitor passa a inconsistente quando a afinação está errada (Bar-Shalom §5,4); estimadores sobrepostos de ADEV (desvio de Allan), MDEV (desvio de Allan modificado), TDEV (desvio de tempo), HDEV (desvio de Hadamard) + intervalos de confiança baseados em χ² com graus de liberdade efetivos específicos do tipo de ruído (formas fechadas da Tabela 5 do NIST SP 1065 para WPM/FPM/WFM/FFM/RWFM (WPM: modulação de fase de ruído branco; FPM: modulação de fase de ruído flicker; WFM: modulação de frequência de ruído branco; FFM: modulação de frequência de ruído flicker; RWFM: modulação de frequência de passeio aleatório), o conjunto que o Stable32 usa; a curva ADEV exportada identifica o tipo de lei de potência do registo a partir da sua inclinação MDEV e anexa uma banda de 95% por τ — src/allan.rs), validados numericamente face aos desvios de referência do Stable32 para o conjunto de dados canónico NBS14 até 1e-4 (tests/allan_reference.rs) e com o edf verificado de forma cruzada por um conjunto de Monte Carlo de FM (modulação de frequência) branca; FoM (figura de mérito) de holdover limitada pela grelha e franca quanto aos limites; conjuntos de relógios; modelo de transferência de tempo bidirecional com cancelamento de atraso recíproco + um piso de atraso diferencial não recíproco de FM de passeio aleatório (src/timetransfer.rs, assinatura de Allan indicada); uma calculadora de holdover de relógio sem GNSS (src/holdover.rs) que expõe o crescimento do erro de deslize de van Loan de forma fechada σ_x²(t) = q_wf·t + q_rw·t³/3 + q_drift·t⁵/20 como uma inversão de holdover até ao limiar orientada ao utilizador (durante quanto tempo um relógio funciona em regime livre antes de o seu erro de temporização exceder o orçamento), com classes representativas de relógios quânticos (rede ótica/iões aprisionados/iões de mercúrio) — modelada, não validada externamente: verificada de forma cruzada face à recursão de covariância clock_state em vários passos, e declarando com franqueza que, para um relógio muito estável, o holdover até um limiar apertado é determinado pelo piso de ruído vermelho de tau longo assumido, e não pelo ADEV citado (usar pisos medidos para obter um número defensável). Um Nível de Proteção de Temporização condicional (src/tpl.rs) assenta no mesmo mecanismo de holdover para o caso de spoofing: um limite para o erro de tempo não detetado dada uma verificação cruzada independente — um piso de monitor de k-σ mais a variância de deslize de van Loan sobre a latência de deteção mais um tempo até ao alarme de CUSUM (soma cumulativa) — calibrado sobre um spoof real registado (JammerTest 2024, Zenodo 15911589) e reproduzível através de cargo run --example tpl_jammertest. Composição modelada, condicionada à deteção: não existe um limite incondicional finito (uma rampa suficientemente lenta escapa a um único monitor assistido por relógio). O erro máximo de intervalo de tempo (MTIE) e o TDEV são VALIDATED face ao allantools (tests/mtie_reference.rs, tests/mdev_tdev_reference.rs), e a inversão da variância de deslize de holdover é VALIDATED face ao SciPy (tests/gnss_denied_clock_holdover_reference.rs); o tipo de cenário telecom-timing aplica-os às máscaras ITU-T (International Telecommunication Union Telecommunication Standardization Sector) G.8272 / G.8272.1 / G.8273.2 / G.8271.1 — ver TELECOM-TIMING.md |
edf completo pelo algoritmo de Greenhall (as formas fechadas simples têm viés limitado mas são mais grosseiras do que o BasicSum exato) e identificação de misturas de vários ruídos | edf exato + identificação de ruído misto: P2 |
| Processamento GNSS / PNT | partial | Uma simulação de pseudodistâncias no domínio da medição (tipo de cenário gnss-sim, src/gnss_sim.rs): por cada satélite visível sintetiza ρ = geometric range + c·δt_rx − c·δt_sv + I + T + noise + multipath e o Doppler em L1, com a ionosfera de frequência única de Klobuchar (IS-GPS-200 (IS: Especificação de Interface; GPS: Sistema de Posicionamento Global) §20.3.3.5.2.5) e a troposfera zenital de Saastamoinen (Davis 1985) projetadas pela função de mapeamento de Niell (1996) — cada modelo testado unitariamente face a um cálculo manual — e depois alimenta os resíduos ao RAIM instantâneo (monitorização autónoma da integridade pelo recetor) para HPL/VPL por época (HPL: nível de proteção horizontal; VPL: nível de proteção vertical) e emite uma matriz gnss_measurements[] (pseudodistância, Doppler, C/N₀, correções de ionosfera/troposfera por SV (veículo espacial, isto é, um satélite)). Além disso, DOP/disponibilidade (DOP: diluição da precisão) e RAIM por separação de soluções a partir de órbitas; ingestão NAV multi-GNSS RINEX (Receiver Independent Exchange Format) 3 (GPS/Galileo/QZSS/BeiDou (QZSS: Sistema Quase-Zenital de Satélites do Japão) via IS-GPS-200, vetor de estado do GLONASS (Sistema Global de Navegação por Satélite da Rússia)) analisada → posição ECEF e desvio de relógio do SV, utilizável como fonte Propagator de primeira classe E como bloco rinex de constelação em linha (scenarios/orbit-rinex.toml); ingestão de OBSERVAÇÕES RINEX 3 (espera-se que o formato de observação 4,00 seja analisado, mas nenhum ficheiro 4,00 foi exercitado; os ficheiros de NAVEGAÇÃO RINEX 4 são recusados pelo nome em vez de serem descodificados incorretamente); um solucionador de posicionamento de ponto único (tipo de cenário pvt, src/pvt.rs) que transforma pseudodistâncias de código RINEX reais + efemérides difundidas numa posição do recetor por mínimos quadrados ponderados iterados — correção de Sagnac/rotação da Terra, relógio do satélite difundido com −TGD, a combinação L1/L2 de dupla frequência sem ionosfera (ou Klobuchar de frequência única), troposfera de Saastamoinen/Niell, ponderação por elevação, DOP e RAIM instantâneo — validado com dados IGS (International GNSS Service) reais (estação ABMF, Guadalupe, 2018-05-13) até 5,7 m de RMS (raiz do valor quadrático médio) 3-D / 1,1 m na horizontal face à coordenada levantada da estação (tests/pvt_abmf.rs, scenarios/pvt-abmf.toml); e leitura/escrita de órbitas precisas SP3 (Standard Product 3, o formato de órbitas precisas) |
Um motor de posicionamento por código e, a partir da 0,36, processamento de fase da portadora em observações reais: o solucionador pvt calcula uma posição real a partir de medições de código reais (posicionamento de ponto único, ao nível do metro, com a combinação de dupla frequência sem ionosfera); rtk_real::run_rtk faz RTK de linha de base curta sobre código e fase GPS reais de dupla frequência (diferenças duplas, um filtro de Kalman de valores flutuantes, fixação de ambiguidade inteira LAMBDA com teste de razão, src/lambda.rs), e um filtro PPP estático de valores flutuantes funciona sobre código e fase reais com órbitas e relógios finais do IGS. Ambos são VALIDATED face a coordenadas ITRF2020 publicadas de estações IGS (WTZR/WTZZ, tests/rtk_real_wettzell_oracle.rs, tests/ppp_real_wettzell_oracle.rs, limiares fixados antecipadamente); o que continua em falta é a resolução de ambiguidade inteira em PPP, o RTK cinemático ou em rede e a operação em tempo real. O alisamento da portadora de Hatch é um resultado MODELLED fixado (os seus limiares fixados antecipadamente não foram atingidos). O tipo de cenário leo-ppp executa um filtro PPP de valores flutuantes sobre medições que simula, para estudos de convergência; o pacote direto gnss-sim continua a ser um simulador a partir da referência; BeiDou-GEO (GEO: órbita geoestacionária) excluído |
Fixação de ambiguidades PPP, RTK cinemático ou em rede, operação em tempo real: usar RTKLIB/gLAB (RTKLIB: uma biblioteca de código aberto de posicionamento cinemático em tempo real) |
| Fusão de sensores / navegação à estima por INS (sistema de navegação inercial) | full | Biblioteca strapdown de 3 eixos (src/inertial/{attitude,mechanization,imu_errors}.rs): atitude por quaterniões com compensação de coning/sculling, mecanização NED (norte-este-baixo) completa (taxa da Terra + taxa de transporte, gravidade de Somigliana WGS-84) e um modelo determinista de erros de IMU (unidade de medição inercial) (fator de escala, desalinhamento, sensibilidade a g, quantização, rampa de taxa modelados). O navegador strapdown está agora ligado a um pacote GNSS/INS fracamente acoplado executável com uma figura de mérito (src/fusion/pack.rs, kind = "gnss-ins"): a mecanização de três eixos é disciplinada pelo EKF (filtro de Kalman estendido) de estados de erro de 15 estados (src/fusion/{gnss_ins_ekf,closed_loop}.rs, realimentação de posição/velocidade/atitude/enviesamento) enquanto o GNSS está disponível, e depois desliza através da indisponibilidade — substituindo a reposição forçada à referência por fusão genuína, e indicando o erro horizontal fundido face ao deslize de INS livre em malha aberta. O pacote inertial legado e separado continua a executar o orçamento escalar de 1 DOF (DOF: grau de liberdade) com reposição forçada à referência. Está também implementada uma atualização de pseudodistância fortemente acoplada (update_tightly_coupled / fuse_tightly_coupled): forma a inovação no domínio da distância (Jacobiano de linha de vista sobre δp) e continua a corrigir com menos de quatro satélites, onde uma solução PVT (posição, velocidade e tempo) fracamente acoplada não existe. Um UKF (filtro de Kalman unscented) GNSS/INS fortemente acoplado completo de 17 estados (src/fusion/tightly_coupled17.rs) transporta a posição, a velocidade, o erro de atitude, os enviesamentos do acelerómetro e do giroscópio e o relógio do recetor (enviesamento + deriva), com navegação à estima quântica CAI (CAI: interferómetro de átomos frios) — o ruído de processo de passeio aleatório de velocidade é o q_va derivado do acelerómetro de átomos frios — a deslizar numa indisponibilidade de 120 segundos limitada a algumas centenas de metros (face aos quilómetros de um INS livre de grau de navegação). Este UKF de 17 estados está agora disponibilizado como cenário executável (src/fusion/hybrid_ukf.rs, kind = "hybrid-ukf", acessível a partir de CLI/Python/WASM/MCP): os 15 estados de erro do INS são aumentados com a correção de enviesamento do acelerómetro derivada do CAI (o interferómetro de átomos frios define o piso de passeio aleatório de velocidade q_va) e um relógio de 2 estados fase+frequência cujo ruído de processo vem do motor de relógio de parâmetros q (clock_state::q_from_allan, perfil de Allan → q_wf/q_rw), conduzido pelo modelo de erro CAI delimitado, de modo que a execução demonstra a hibridação de curto prazo de IMU clássica + longo prazo quântico. A sua figura de mérito é a autoconsistência do filtro — NEES + brancura da inovação (NIS) agregados sobre um conjunto de Monte Carlo face às suas bandas χ² de 95% (o filtro ajustado fica dentro das bandas; um filtro mal afinado é assinalado, uma barreira objetivamente verificável). Esta é uma afirmação de AUTOCONSISTÊNCIA sob o ruído modelado, NÃO uma garantia de exatidão no mundo real — as entradas CAI/relógio são delimitadas/modeladas, o equipamento CAI é propriedade do parceiro, e nada aqui implica TRL (nível de maturidade tecnológica)>3, herança de voo ou validação externa. O modelo determinista de erros de IMU é configurável por sensor a partir do ficheiro de cenário TOML (Tom's Obvious Minimal Language) gnss-ins ([imu_*.error_model]: fator de escala, desalinhamento, sensibilidade a g, quantização, rampa de taxa), com predefinição de uma fonte de enviesamento constante pura quando omitido |
O acoplamento forte é apenas de pseudodistância (a fase da portadora está no roteiro); o cenário hybrid-ukf usa uma única trajetória nivelada de velocidade constante na qual os estados de erro de atitude e de enviesamento de IMU são apenas fracamente observáveis, pelo que a consistência NEES é avaliada sobre o subconjunto estimável (posição, velocidade, relógio = 8 estados) — a observabilidade plena dos 17 estados exige uma trajetória com manobras (roteiro); o par enviesamento do acelerómetro/inclinação do acoplamento fraco é pouco separável, pelo que a calibração por enviesamento não é afirmada; o modelo de erros de IMU omite a retificação de vibração e a deriva por gradiente de temperatura; o UKF de 17 estados e os caminhos fortemente acoplados são autovalidados (integração analítica a velocidade constante, convergência do auxílio GNSS, recuperação de enviesamento, o limite de indisponibilidade de 120 s limitado por CAI e a referência de consistência χ² de NEES/NIS) — a mecanização strapdown em si é VALIDATED face ao NaveGo v1.4 (tests/classical_strapdown_ins_reference.rs: atitude idêntica bit a bit, velocidade/posição dentro de limites analíticos indicados), mas não foi executada nenhuma validação cruzada ao nível do filtro (NaveGo ou o conjunto de dados de veículo KF-GINS) |
acoplamento forte com fase da portadora, observabilidade plena dos 17 estados com trajetória com manobras, biblioteca de trajetórias, validação cruzada ao nível do filtro com NaveGo/KF-GINS: P2 |
| Integridade / RAIM / ARAIM (monitorização autónoma avançada da integridade pelo recetor) | partial | RAIM instantâneo real em src/raim.rs: solução de mínimos quadrados + deteção de falhas por χ² dos resíduos (limiar exato a partir de um χ² de gama incompleta sem dependências) e HPL/VPL baseados em declive (pbias a partir de um χ² não central para os P_fa/P_md configurados); RAIM por separação de soluções (MHSS) com deteção/identificação de falhas; orçamento de risco de integridade (P_HMI) do ARAIM (araim_raim) que resolve o menor HPL/VPL cujo P_HMI = Σ_k p_fault,k·Q((PL−T_k)/σ_k) somado satisfaz uma atribuição explícita de risco de integridade, o modo de falha de toda a constelação em dupla/múltipla constelação (araim_dual_raim, EU (União Europeia) ARAIM TN (nota técnica) / DO-316; P_const = 0 ⇒ araim_raim idêntico bit a bit), uma mensagem de suporte de integridade explícita (IntegritySupportMessage: σ_URA/σ_URE/b_nom/P_sat/P_const, com os valores de referência GPS+Galileo do WG-C (WG: Grupo de Trabalho)), além de um diagrama de integridade de Stanford(-ESA, a Agência Espacial Europeia) (o tipo de cenário integrity, e um renderizador autónomo stanford_svg das quatro zonas + fronteira PL=error). Documentado de ponta a ponta em ARAIM_REFERENCE.md. Além disso, a autoconsistência do filtro da FoM do cenário (limite de k-σ) |
O RAIM é acessível através do tipo de cenário integrity e (0,36, opcional) ao lado da FoM de relógio/holdover como um bloco integrity_fom separado ([integrity]: RAIM instantâneo num céu predefinido a partir de um local indicado, indisponível enquanto o GNSS está negado; MODELLED), nunca integrado na FoM de holdover, que continua a indicar a autoconsistência; o RAIM instantâneo inclui FDE de satélite único (deteção e exclusão de falhas, raim::snapshot_raim_fde, VALIDATED face ao RTKLIB raim_fde em tests/integrity_snapshot_raim_rtklib_oracle.rs); a separação de soluções por hipóteses múltiplas do ARAIM ADD v4.2 com determinação de subconjuntos de vários satélites está em src/araim_reference.rs (VALIDATED face ao Stanford MAAST, tests/integrity_araim_stanford_oracle.rs), mas o orçamento raim::araim_raim de sigma uniforme continua a cobrir apenas falhas de um só SV e de toda a constelação e não é aderente à norma ADD (0,36, opcional: falhas simultâneas de subconjuntos de vários SV através da regra de subconjuntos do ADD v4.2 generalizada para além de pares, araim_subset_raim, add_v42_protection_levels_to_order; MODELLED, sem execução MAAST para além de pares), e a exclusão de vários SV não é modelada; e araim_dual_raim está ligado ao executor de cenários TOML através da opção araim_dual (scenarios/araim-gps-galileo.toml), com um caminho de disponibilidade por época araim_dual_constellation_availability; os núcleos instantâneo/MHSS/ARAIM são exercitados com geometria real de órbitas precisas IGS (SP3) (tests/igs_real_data.rs) e com TLE reais GPS+Galileo do Celestrak (tests/araim_dual_real_data.rs, cada satélite propagado para uma época UTC comum — a época do TLE (conjunto de elementos de duas linhas) mais recente do conjunto, 2026-06-07T07:21:04 — para um utilizador a 400 km com inclinação de 45° ao longo de 24 h: a disponibilidade sob um VAL (limite de alerta vertical) de 12 m / HAL (limite de alerta horizontal) de 10 m é 0,993 só com GPS, 1,000 com GPS+Galileo agregados e 0,990 no modo duplo robusto a falhas de constelação; o valor anteriormente publicado aqui, 0,21→0,67 com o modo robusto "limitado", resultou de propagar cada satélite a partir da sua própria época de TLE — um céu que nunca existiu — e foi retirado); a anterior comparação "EU-ARAIM-TN Table A-3" foi retirada (sem fonte pública), e uma reprodução das entradas de URA máxima do Marco 3 do ARAIM do WG-C UE-EUA, públicas (Tabelas 5 a 7, linhas Depleted e Baseline), é tentada em xval/araim-m3/ com desvios declarados (MODELLED, ver INTEGRITY.md); não certificado segundo DO-229/ARAIM |
ARAIM de falhas múltiplas (ADD v4.2): concluído; subconjuntos de vários SV em raim + paridade em domínio de recetor com o gLAB + ligação à FoM: P2 (ver INTEGRITY.md) |
| Modelação de ameaças de spoofing / jamming | partial | Um detetor estocástico de time spoof (tipo de cenário spoof, src/spoof.rs + src/detection.rs): quatro formas de injeção (rampa linear, salto em degrau, meaconing, replay) face a um monitor assistido por relógio com um teste de energia χ²₁ / de Neyman–Pearson bilateral, com o limiar de deteção definido a partir de um orçamento-alvo de falsos alarmes P_fa, e a probabilidade de deteção falhada P_md indicada tanto em forma fechada como por Monte Carlo (as duas concordam até alguns ×1/√N) — a figura de mérito de segurança é 1 − P_md. Além disso, um modelo de jamming por orçamento de ligação (tipo de cenário jamming, src/jamming.rs): razão entre o jammer e o sinal a partir da geometria (perda de percurso em espaço livre + ganho da antena de receção por direção), a equação normalizada de C/N₀ efetivo antijamming (ganho de processamento de despreading + fator de separação espetral Q; Kaplan & Hegarty §9,4), perda de sincronização por satélite num limiar de seguimento configurável e uma figura de mérito availability_under_jamming sobre uma constelação Walker. Além disso, uma suite de monitores de spoofing em múltiplas camadas de RF/medição (RF: radiofrequência) (src/spoof_monitors.rs): um teste de paridade de consistência RAIM com vários satélites (parity_raim_test, SOS (soma dos quadrados) ponderada dos resíduos face a um limiar χ²(m−4) — e assinala corretamente que um enviesamento de modo comum é invisível ao RAIM), um monitor de AGC (controlo automático de ganho) (AgcMonitor, excesso de potência recebida acima do piso esperado), um monitor de qualidade do sinal / SQM (monitorização da qualidade do sinal) (SqmMonitor, desequilíbrio dos correlacionadores Early/Late) e um combinador de fusão de camadas (fuse_spoof_layers). Estes compõem um CombinedSpoofDetector integrado cujo evaluate ingere uma época de observáveis (geometria + resíduos, potência de AGC, derivações Early/Late) e executa as três camadas através da fusão ponderada numa única chamada, devolvendo os diagnósticos por camada; está exposto como o cenário spoof-detect executável (src/spoof_detect.rs, acessível por CLI / Python / playground, JSON + SVG (Scalable Vector Graphics)) e caracterizado face aos parâmetros publicados dos cenários TEXBAT (Texas Spoofing Test Battery) (Humphreys et al., ION (Institute of Navigation) GNSS 2012; tests/spoof_texbat_validation.rs) — reproduzindo o padrão de detetabilidade documentado, incluindo os resultados negativos: ds2 de potência excessiva apanhado por AGC + SQM, ds3 de potência igualada apenas por SQM, ds4 de empurrão de posição por RAIM, e ds7 de potência igualada e alinhado em fase da portadora deixado (corretamente) ao detetor assistido por relógio |
O tipo de cenário jamming é um orçamento de ligação — não tem multipercurso nem dinâmica de AGC no tempo. Desde a 0,36 aceita quatro secções opcionais: [crpa], um feixe de agrupamento adaptativo por canal (anulação direcional ou MVDR a partir de src/crpa.rs, verificado face a um recálculo independente em numpy; MODELLED), e [terrain], a perda de difração única em aresta de faca do percurso do emissor de jamming sobre um mosaico SRTM (src/jamming_terrain.rs, ITU-R P.526-15 §4,1, verificada face a um recálculo independente em numpy num mosaico real; MODELLED, apenas uma aresta de faca), [acquisition], a histerese entre aquisição e seguimento, e [front_end], a leitura estabilizada do AGC e a perda do quantizador do ADC para entrada gaussiana (src/jamming_rx.rs; assinalada como não válida para emissores de jamming não gaussianos; MODELLED). O multipercurso especular, o desvanecimento em móvel terrestre e o AGC existem na camada IQ (src/iq/channel/multipath.rs, src/iq/channel/land_mobile.rs, src/iq/frontend/agc.rs) e não estão ligados ao tipo de cenário jamming; a tabela de separação espetral Q contém os valores de manual por tipo (CW e banda estreita 1, banda larga e varrido 2 desde a 0,36), fixada aos coeficientes derivados das densidades espetrais de potência (PSD) em navsignal (ver a linha do sinal de navegação). O detetor de spoofing assistido por relógio é de relógio único; os monitores de RF/medição estão agora integrados (CombinedSpoofDetector) e caracterizados face aos parâmetros publicados dos cenários TEXBAT (Humphreys et al.); o que resta é a validação face aos vetores em bruto — amostras IQ (em fase/quadratura) do TEXBAT (que exigem um front-end de aquisição/seguimento SDR (rádio definido por software) que o Kshana não tem, por ser um simulador e não um recetor) ou um cenário Spirent licenciado — um desenvolvimento seguinte documentado |
detetor combinado assistido por relógio + consistência integrada RAIM multi-SV + AGC + SQM + caracterização com parâmetros TEXBAT: concluído; validação com vetores em bruto (TEXBAT IQ / Spirent licenciado): desenvolvimento seguinte |
| Modulação do sinal de navegação e desempenho do seguimento de código | partial | src/navsignal.rs: o nível do sinal entre o orçamento de ligação e o domínio da medição. Densidades espetrais de potência de área unitária para BPSK-R(n) (modulação por desvio de fase binária, chips retangulares) e sine-BOC(m,n) (portadora com desvio binário) (validadas em CI quanto à área unitária, à forma fechada do coeficiente de separação espetral (SSC) próprio do BPSK κ = 2/(3R_c) e à divisão espetral do BOC — nulo na portadora, picos em ±f_s); o coeficiente de separação espetral κ = ∫ G_s(f)G_i(f) df, que agora deriva o Q antijamming usado por jamming a partir dos espetros reais do sinal e do emissor de jamming (Q = 1/(R_c·κ)) em vez de uma constante representativa (a referência de banda larga é verificada de forma cruzada em CI); a largura de banda RMS (Gabor) (BOC > BPSK — a medida de informação de distância / de Cramér–Rao); a instabilidade de ruído térmico do seguimento de código por DLL (malha de bloqueio de atraso) coerente early–late (Kaplan & Hegarty §8 — ~sub-métrica para C/A a 45 dB-Hz, monótona em C/N₀); e o envelope do erro de multipercurso (EML (early-minus-late) coerente, obtido localizando o zero do discriminador composto — supressão do correlacionador estreito verificada). Uma camada de compromissos de projeto de códigos de distância (CodeFamily) acrescenta o lóbulo lateral da autocorrelação periódica de sequências-m/Gold (1/L para uma sequência-m) e o limite de correlação cruzada de Gold t(n)/L de três valores — reproduzindo a correlação cruzada de Gold do GPS C/A de −23,9 dB publicada (uma âncora externa) e a contagem de sequências-m φ(2ⁿ−1)/n — além da inversão entre comprimento do código e distância não ambígua; as garantias de Gold devolvem com franqueza None onde não existe par preferencial (n mod 4 = 0), em vez de indicarem um limite que não se verifica. |
Desde a 0.31.0, a camada IQ separada (src/iq/, os comandos kshana iq; projeto em design/GNSS-IQ-PLAN.md) acrescenta uma cadeia de recetor por software: aquisição por FFT (transformada rápida de Fourier), um banco de seguimento multicanal DLL/PLL/FLL (malhas de bloqueio de atraso, de fase e de frequência), filtragem de front-end e quantização de 1 a 14 bits, e transmissão contínua de conjuntos de dados registados. Um recetor por software independente recupera a referência injetada das suas cenas, e os códigos GPS L1 C/A e os bits LNAV (mensagem de navegação legada) são idênticos bit a bit aos do gps-sdr-sim. Continua em falta: os discriminadores das malhas assumem o triângulo de correlação BPSK ideal, pelo que não existe resolução da ambiguidade de seguimento BOC; os modelos de canal e de malha são MODELLED, verificados face a formas fechadas e à referência injetada, não face a IQ de terreno medido; apenas malhas escalares (sem seguimento vetorial). O projeto de hardware de antenas/carga útil de RF (diagramas de radiação, front-end) está deliberadamente fora do âmbito — é o papel de um parceiro de carga útil. |
Ambiguidade BOC + validação da camada IQ com IQ de terreno: P2+ |
| Física de sensores quânticos para PNT | partial | A maioria dos sensores são coeficientes publicados de Allan/orçamento de ruído (CSAC, ótico), mais um acelerómetro de interferómetro de átomos frios (CAI) de primeiros princípios em src/inertial/quantum_imu.rs: a fase de Mach–Zehnder de três impulsos Φ = k_eff·a·T², o ruído de projeção quântica (shot) σ_Φ = 1/(C√N), a PSD derivada de passeio aleatório de velocidade q_va que a pilha inercial consome, o decaimento do contraste, a função de transferência de vibração |H(ω)| + variância de PSD branca e, agora, os sistemáticos de Coriolis/rotação (coriolis_phase, enviesamento equivalente 2Ω×v) e de desvio de luz AC-Stark (AC: corrente alternada) (ac_stark_phase, cancelamento simétrico) + uma varredura de deriva do tempo de ciclo (cai_drift_sweep), e um orçamento composto de erro de navegação à estima quântico-inercial (QuantumNavBudget) que reúne o passeio aleatório de velocidade de ruído branco do CAI com o enviesamento residual (½·b·t², verificado de forma cruzada face ao integrador de Euler AccelModel independente), o erro de fator de escala e uma degradação opcional da estabilidade de longo prazo (distinta da decoerência por disparo) numa única figura de deriva de posição ao longo do holdover, mais um holdover inercial até ao limiar — o gémeo de navegação à estima do holdover do relógio. O piso quântico modelado está delimitado (não igualado) face aos 96 nm/s²/√Hz do gravímetro móvel de Freier et al. 2016 (arXiv:1512,05660) — situa-se abaixo dele e a ~2 ordens de grandeza. Documentado em QUANTUM.md |
Sistemáticos de frente de onda/apontamento do feixe não modelados; o limite de ambiguidade de franjas de Mach–Zehnder está modelado (max_unambiguous_accel, dynamic_range_cells em src/inertial/quantum_imu.rs), mas a resolução da ambiguidade não; os orçamentos exatos de ensaio em voo do CARIOQA-PMP (CARIOQA: Cold Atom Rubidium Interferometer in Orbit for Quantum Accelerometry) / Boeing-AOSense (exigem PSD de plataforma publicadas + SNR (relação sinal-ruído) por disparo) e uma predefinição de playground em JS (JavaScript) permanecem por fazer |
sistemáticos de frente de onda + reprodução de ensaio em voo: P2+ (QUANTUM-MODELS.md) |
| Projeto de constelações | partial | Walker sintético (tanto kepleriano analítico como de elementos médios SGP4, este último propagado através do núcleo validado a 4,12 mm — src/walker.rs) + visibilidade e DOP de multiconstelação com TLE reais (GPS+Galileo até 100%), validados face a um instantâneo real gps-ops do Celestrak (tests/igs_real_data.rs); uma varredura de projeto de PDOP (diluição da precisão de posição) sobre a grelha {planes × sats × inclination} e figuras de mérito de fração de cobertura / tempo de revisita; o tipo de cenário constellation-design executável (padrões Walker delta e estrela na convenção i: T/P/F, listas explícitas de elementos, projetos de várias camadas e predefinições publicadas, em torno da Terra, da Lua, de Marte ou de qualquer outro corpo catalogado) cuja geometria Walker e cujas posições GPS, Galileo e GLONASS publicadas são VALIDATED face às tabelas publicadas e cuja linha de base global de diluição da precisão do GPS é VALIDATED face à norma de desempenho do Serviço de Posicionamento Padrão do GPS, enquanto os mapas de cobertura de projetos arbitrários permanecem MODELLED; um otimizador de projeto sem gradiente (optimize_walker_design) que procura na grelha o melhor projeto para um objetivo escolhido (MinSatellitesForCoverage / MaxCoverage / MinWorstPdop), validado por devolver o vencedor da força bruta; e a geometria analítica de ruas de cobertura (coverage_half_angle_rad, street_half_width_rad; formas fechadas de Rider/Beste, verificadas à mão — GPS com máscara de 5°: λ ≈ 71,2°, semilargura da rua de 4 satélites ≈ 62,8°) |
Existe um dimensionamento idealizado de número mínimo de satélites por ruas de cobertura (walker::StreetsCoverageDesign); a correção de Rider exata na junção, na fronteira de planos em contrarrotação, não está implementada; o playground desenha uma vista orbital 3-D sem dependências (web/studio/lib/orbit3d.mjs), e uma exportação CZML (Cesium Language), --export czml, carrega a geometria no globo CesiumJS; o núcleo de DOP é VALIDATED face ao gnss_lib_py (tests/dop_reference.rs), e toda a cadeia de visibilidade de multiconstelação é verificada de forma cruzada de ponta a ponta face ao Orekit 12,2 + gnss_lib_py (tests/coverage_dop_full_oracle.rs): os projetos para a Terra concordam em todos os limiares, mas os projetos para a Lua e Marte falham o limiar de DOP em geometria numericamente singular, pelo que a linha continua MODELLED; "cima" geodésico vs geocêntrico no referencial de DOP |
dimensionamento por ruas de cobertura + vista orbital 3-D + verificação cruzada de ponta a ponta para a Terra: concluído; correção de Rider exata na junção + DOP fora da Terra mal condicionado: P2 |
| Verificação e validação | partial | Verificações com referência independente externa em todo o motor (SGP4 face a 666 vetores AIAA, a família de Allan face ao Stable32 e ao allantools, referenciais face ao SOFA/ERFA, modelo de forças e determinação de órbita face ao Orekit, ARAIM face ao exemplo trabalhado do WG-C, e mais; a contagem atual é o cabeçalho gerado de VERIFICATION-MATRIX.md); verificações de Allan deterministas; uma matriz de verificação verificada por máquina (src/verification.rs) — uma referência cruzada requisito→módulo→teste→referência independente→estado cujas invariantes de rigor são testadas unitariamente: uma linha só pode ser etiquetada como validada se tiver uma referência independente externa (NIST/AIAA/SOFA/IGS/valor publicado), de modo que uma verificação de autoconsistência interna não possa passar por validação; produz Markdown/CSV (CSV: valores separados por vírgulas) para uma referência cruzada de verificação ECSS-E-ST-10-02 (ECSS: European Cooperation for Space Standardization) e regista como tal as quatro lacunas de hardware/PA (PA: garantia do produto) que são da responsabilidade de parceiros |
Os conjuntos de calibração cobrem até agora três verificações de semente única (CALIBRATION-ENSEMBLES.md, fixadas antecipadamente: o intervalo de bootstrap de Monte Carlo cobre em 96 % de 200 sementes; uma tolerância de percentil é frágil à semente, NOT MET a 91,5 %); as restantes linhas continuam calibradas com sementes únicas. A matriz impõe a classificação das linhas, e a CI verifica agora também que todos os testes, ficheiros e itens da crate citados por uma linha existem (tests/verification_rows_name_a_test_that_exists.rs, tests/verification_rows_cite_evidence_that_exists.rs) e que as figuras publicadas continuam a reproduzir-se (tests/published_figures_still_reproduce.rs); não avalia a própria referência independente, que um revisor continua a ler |
conjuntos de calibração: P1 |
| LEO-PNT (posicionamento, navegação e temporização a partir de órbita terrestre baixa) | partial | Sete tipos de cenário, agnósticos quanto ao sistema, com predefinições públicas nomeadas: leo-signal (projetos de sinal de qualquer banda e estrutura: componentes BPSK, BOC, MBOC (BOC multiplexado) ou de tipo OFDM plano (multiplexagem por divisão de frequências ortogonais), seguimento de código, aquisição, compatibilidade GNSS, compromisso de bandas), leo-pass (uma passagem projetada, por elementos, TLE ou Walker com um orçamento de ligação por banda: chuva, cintilação e perda de entrada em edifícios segundo o ITU-R (Setor de Radiocomunicações da União Internacional das Telecomunicações), ionosfera, antena, Doppler, face aos satélites GNSS MEO (órbita terrestre média) à vista), leo-navmsg (efemérides e relógio difundidos sobre a base kepleriana do ICD (documento de controlo de interface) do Galileo ou modelos LEO selecionáveis, ajustados e codificados com uma verificação de trama CRC-24Q (verificação de redundância cíclica de 24 bits)), leo-pvt (posicionamento fundido MEO + LEO por pseudodistância e Doppler sobre quaisquer constelações), leo-ppp (convergência de PPP com e sem aumentação LEO, sobre medições simuladas), ntn-positioning (limites de posicionamento 5G NTN, redes não terrestres, a partir da largura de banda do sinal) e leo-pnt-chain (um sistema de ponta a ponta, com a saída de cada fase entregue à seguinte). Partes VALIDATED: os termos de ligação do ITU-R face às tabelas e aos exemplos de validação das Recomendações, o Doppler máximo face a uma tabela publicada, o algoritmo de utilizador do Galileo face ao RTKLIB até 1 mm, o CRC-24Q, os pesos do SISRE (erro de alcance do sinal no espaço) |
Sem dados de terreno nem sinais registados; as figuras de posicionamento, PPP, NTN e temporização são MODELLED (formas fechadas, consistência de filtros, comparações de tendências publicadas); as predefinições são de fonte pública ou derivadas, não dados de operadores | validação com sinais reais registados: P3 |
| Espetro / ambiente de RF | partial | Tipo de cenário spectrum (src/spectrum.rs): a banda L do GNSS (e projetos multibanda UHF (frequência ultra-alta), banda S e banda C) como uma única densidade espetral de potência, com a frequência na horizontal e o tempo na vertical, sob uma cronologia programada de emissores de jamming (de onda contínua, de banda estreita, chirp e de banda larga igualada), com J/S (razão entre o jammer e o sinal) e C/N₀ (densidade de portadora/ruído) efetivo por banda; gravações SigMF de entrada e saída e estimativas espetrais de Welch de amostras complexas. Os espetros de sinal de forma fechada e os coeficientes de separação espetral são VALIDATED; a cascata é MODELLED |
Sinais GLONASS, BeiDou e Galileo E6 não modelados; sem front-end de recetor nem validação com IQ (em fase/quadratura) registado | comparação com sinais registados: P3 |
| Confiança nos registos do recetor (embarcações e uso geral) | partial | src/receiver_trust/: monitores sobre o próprio registo de um recetor (densidade de portadora/ruído, consistência de posição, velocidade e rumo, tempo) com eventos e previsões declarados antes da execução; numa plataforma de embarcação, uma pontuação de 0-100 com razões; modo em direto sobre um fluxo com a frase $PKSHT e uma barreira opcional. MODELLED; consultivo, não é um equipamento de navegação homologado |
Os limiares são predefinições declaradas, não medidas face a recetores em serviço; um registo pontua apenas esse registo; sem entrada nem saída de radiofrequência; não é um equipamento de navegação homologado | docs/RECEIVER-TRUST.md, docs/MARITIME-TRUST.md |
| Pacotes de evidências e telemetria de confiança | partial | src/evidence/: um pacote assinado e encadeado por hash de uma janela de registo, da sua configuração e do resultado do motor, verificável offline, com um token de marca temporal RFC 3161 opcional. src/telemetry/: o fluxo de confiança como métricas Prometheus, eventos syslog (CEF ou LEEF) e OpenTelemetry opcional, com um painel Grafana de exemplo |
Um pacote é um registo técnico, não um parecer jurídico, e não diz o que causou um evento; a assinatura da autoridade de marcação temporal não é verificada; a telemetria transmite apenas telemetria | docs/EVIDENCE-PACKS.md, docs/TRUST-TELEMETRY.md |
| Fluxos de formação de tripulações e mapas de interferência | partial | src/nmea_synth/: NMEA sintético de ponte com eventos programados de jamming, drag-off, time spoof e replay e um registo de instrutor (apenas texto). src/interference_map/: mapas agregados de navegação degradada a partir de relatórios de aeronaves e navios de licença aberta e a exposição de uma rota, a partir de ficheiros locais |
Os fluxos são dados de formação, nunca para os sistemas de navegação em funcionamento de uma embarcação; os mapas são agregados, não uma previsão, e dependem dos relatórios fornecidos | docs/NMEA-TRAINING.md, docs/INTERFERENCE-MAP.md |
| Exportação para test bench | partial | src/interop/testbench.rs: o movimento do veículo e os eventos de um cenário gnss-ins, jamming ou gnss-sim como CSV de movimento, NMEA, texto de pontos de passagem e ficheiros de eventos para um simulador GNSS de laboratório |
Não é escrito nenhum sinal; não é afirmado nenhum desempenho de simulador ou de recetor; os ficheiros são verificados tal como relidos pelos leitores de movimento de um simulador de código aberto (gps-sdr-sim), mas a física da própria trajetória de referência do cenário não é verificada externamente | docs/TEST-BENCH.md |
| Verificação Galileo OSNMA | partial | src/osnma/ e kshana osnma verify: lê páginas I/NAV do Galileo ou um fluxo UBX e indica, por satélite e época, se os dados de navegação estão autenticados (chave assinada com raiz de Merkle, cadeia TESLA, MAC), com a razão da falha de uma verificação e uma referência temporal independente opcional para a atualidade; também osnma_verify em Python e WebAssembly |
Autentica dados face a chaves fornecidas pelo utilizador; não afirma desempenho antispoofing e não é um serviço de integridade de navegação nem um equipamento homologado; verificado com vetores sintéticos, os vetores de teste oficiais do ICD são um descarregamento externo | docs/OSNMA.md |
| Mapeamento de compliance de referenciais públicos | partial | src/compliance/ e kshana compliance-report: saídas do Kshana associadas a seis referenciais e normas públicos de resiliência, com fontes e uma lacuna em cada linha; uma execução só conta quando o seu resultado inclui os campos que o seu tipo de cenário escreve |
Um mapeamento é um juízo; o relatório diz o que um conjunto de execuções fornece elementos de prova em apoio de, nunca que um referencial é satisfeito ou que um produto é aprovado; a EN 16803 é citada apenas a partir do texto do catálogo | docs/compliance/README.md |
| Integrações marítimas | partial | Um plugin Signal K, o OpenCPN através de NMEA em modo de barreira sobre TCP e uma compilação de referência para um computador pequeno junto ao recetor (integrations/, deploy/) |
Testado sobre saída sintética registada; o plugin não está publicado no npm; consultivo, não é um equipamento de navegação homologado | docs/MARINE-INTEGRATIONS.md |
Domínios mais amplos de sistemas espaciais (fora do âmbito atualmente)#
Vários destes são none; outros são agora modelos de primeira ordem partial (os tipos de cenário de análise de missão / ambiente acrescentados na série v0.17.0) — listados para que o âmbito seja inequívoco, e não implícito pelo silêncio. O Kshana é um simulador PNT, não o GMAT/STK/Orekit (STK: Systems Tool Kit); estes modelos adjacentes são deliberadamente de primeira ordem e MODELLED, nunca ferramentas de voo validadas.
| Capacidade | Estado | Nota / roteiro |
|---|---|---|
| Conceção de missões / otimização de trajetórias | partial | src/maneuver.rs: nós de ΔV impulsivos com propagação de covariância 6×6 (referenciais de erro de execução ECI/LVLH (ECI: inercial centrado na Terra; LVLH: vertical local, horizontal local)), integração de queima finita verificada face à equação de Tsiolkovsky de forma fechada até < 0,01 %, um solucionador de Lambert de revolução única Izzo-2015 + um propagador de Kepler exato em variáveis universais (saídas de Lambert reconduzidas à referência de dois corpos) e uma varredura porkchop (lançamento × chegada) de C3 / V∞ de chegada emitida como grelha de contornos JSON cujo mínimo é verificado face ao piso analítico de Hohmann. Sem otimizador de trajetória; um solucionador de Lambert de várias revoluções (maneuver::lambert_multirev, até três revoluções, ambos os ramos) é VALIDATED face ao pykep 3.0.1 (tests/lambert_multirev_oracle.rs); o porkchop corre sobre o modelo sintético circular coplanar ou, com maneuver::porkchop_kernel, sobre um SPK DE440 (VALIDATED face a estados SPICE + o Lambert do pykep, tests/porkchop_de440_oracle.rs); maneuver::optimise_transfer_kernel encontra o ótimo contínuo de data (C3 mínimo ou V∞ de chegada mínimo, Tipo I ou II) em DE440, VALIDATED face a um otimizador independente SPICE + pykep + SciPy (tests/transfer_optimiser_oracle.rs); face aos mínimos Terra–Marte 2026 publicados no NASA/TM-2010-216764 coincide com os valores do Tipo II e falha o C3 mínimo do Tipo I em −5,18 % (registado). O GMAT em si não foi executado; o pykep é a referência independente de biblioteca. Existem agora uma junção de efemérides planetárias de espaço profundo (src/ephem_provider.rs) e uma verificação cruzada DE440 (Development Ephemeris 440) (xval/anise-mars-od, 137 m @ arco de Marte de 1 dia) — ver a linha de PNT de espaço profundo / interplanetário. A camada de simulação de desempenho acima do GMAT/Orekit, não uma substituição. P3 |
| AOCS (sistema de controlo de atitude e órbita) / GNC (guiamento, navegação e controlo) / atitude | partial | Tipo de cenário attitude-budget (src/attitude_budget.rs): binário de gradiente de gravidade no pior caso 1.5·(μ/R³)·ΔI + orçamento de erro de apontamento RSS (raiz da soma dos quadrados) sobre termos de 1σ por contribuinte — um orçamento escalar MODELLED de apontamento/perturbações antes do hardware. A dinâmica de atitude de corpo rígido sem binário com estado em quaterniões (src/attitude_dynamics.rs: equações de Euler + cinemática de quaterniões, RK4) é VALIDATED face ao hub de veículo espacial Basilisk 2.9.1 (tests/attitude_dynamics_basilisk_oracle.rs, quaternião dentro de 1e-9 ao longo de 1e4 s), e o pico do binário de gradiente de gravidade face ao GravityGradientEffector do Basilisk (tests/attitude_gg_torque_basilisk_oracle.rs); a determinação de atitude de Wahba está em src/wahba.rs. Tipo de cenário aocs (src/aocs.rs, src/aocs_kind.rs, AOCS.md): uma manobra de apontamento inercial com rodas de reação equilibradas sob realimentação MRP, binários de roda de norma mínima com limites de motor; a malha fechada é VALIDATED face ao Basilisk 2.9.1 em três casos fixados antecipadamente até ao erro de arredondamento. Um MEKF a partir de um giroscópio e de um seguidor de estrelas (src/aocs_mekf.rs) pode fechar a malha sobre a sua estimativa (MODELLED, consistência do filtro). Sem guiamento de seguimento, sem realimentação integral, sem gestão de momento, sem magnetorquers, propulsores, atrito de rodas ou limites de velocidade; sem ambiente de binários externos na dinâmica de atitude; não é um controlador de voo. P3 |
| Referenciais → fixos à Terra | full | Concluído — TEME→ECEF/ITRF, movimento polar e a cadeia GCRS→ITRS baseada no CIO estão implementados e VALIDATED (bit a bit face ao SOFA/ERFA; 4 mm de ponta a ponta face a Vallado). Ver a linha Referenciais acima |
| Comunicações e orçamentos de ligação | partial | src/linkbudget.rs: um orçamento de ligação de Friis para espaço profundo (potência de Tx · ganhos de antena · ruído → C/N₀ · Eb/N₀ · margem) que alimenta o caminho radiométrico/GSE (GSE: equipamento de apoio em terra), além das ligações óticas/RF de transferência de tempo (src/timetransfer*.rs), e o tipo de cenário link-budget executável — a equação de ligação unidirecional CCSDS-401/DSN-810-005 (DSN: Deep Space Network) C/N₀ = EIRP − FSPL − L_other + G/T − k com entradas de EIRP (potência isotrópica radiada equivalente) / G-T e seleção de banda S/X/Ka (orçamento de ligação de engenharia MODELLED, não uma ficha técnica de terminal calibrada). Sem agendamento de acessos, sem codificação adaptativa. P2 |
| Segmento terrestre e operações | partial | Tipo de cenário passes (src/passes.rs): previsão de passagens com nascimento/ocaso para estações terrestres — AOS/TCA/LOS (AOS: aquisição do sinal; TCA: instante de maior aproximação; LOS: perda do sinal), elevação máxima, duração por passagem e acesso total ao longo de um horizonte, a partir de um conjunto de elementos SGP4 no referencial fixo à Terra IAU 2006/2000A com refração ITU-R P.834-9 e tempo de luz — VALIDATED face ao Orekit 13.1.8 em estações ao nível do mar (60 casos / 1210 passagens, tests/pass_predictor_on_path_orekit_oracle.rs); o passes::predict_passes geométrico é VALIDATED face ao detetor de elevação do Orekit 12,2 (22 cenários / 129 passagens, tests/ground_station_pass_prediction_reference.rs); sem otimizador de agendamento nem resolução de conflitos. P3 |
| Telemetria / TT&C / CCSDS | partial | TOML de entrada/JSON de saída à medida; exportação e importação CCSDS OEM (Orbit Ephemeris Message) (502.0-B KVN (notação chave-valor), GMAT/Orekit/STK) através do tipo de cenário oem-interop executável (ponte de ida e volta src/oem.rs parse_oem; a troca aderente à norma de objeto único está VALIDATED face ao analisador oem 0.4.5 independente); análise + emissão de Tracking-Data-Message CCSDS-TDM (503) (src/ccsds_tdm.rs, o formato de intercâmbio radiométrico de espaço profundo); e o tipo de cenário space-packet (src/space_packet.rs): codificação/descodificação do cabeçalho primário do Space Packet CCSDS 133.0-B com ida e volta exata ao bit. Um escritor CCSDS OMM (Orbit Mean-Elements Message, 502.0-B-2, parte da família ODM) (src/omm.rs) publica elementos médios SGP4 em KVN, e um leitor de kernels NAIF SPICE em Rust puro (src/naif_kernel.rs: contentor DAF, SPK tipo 2, PCK binário tipo 2) suporta ephem_provider::KernelEphemeris. Outros tipos de mensagem CCSDS (OPM, OCM, AEM (AEM: Attitude Ephemeris Message)) e a escrita SPICE continuam a ser um item do roteiro (P2) |
| Interoperabilidade e normas (RINEX/SP3/SPICE/CCSDS) | partial | NAV multi-GNSS RINEX 3 — GPS, Galileo, QZSS, BeiDou MEO/IGSO (IS-GPS-200) e GLONASS (vetor de estado PZ-90 (PZ: Parametry Zemli, o datum geodésico russo) RK4) — ingerida + propagada + executável como uma constelação mista; analisador de OBSERVAÇÕES RINEX 3 (pseudodistância/portadora/Doppler/SNR por código de observação, com indicadores LLI/SSI (LLI: indicador de perda de sincronização; SSI: indicador de intensidade do sinal); espera-se que 4,00 seja analisado, não testado); ida e volta de leitura ↔ escrita de efemérides precisas SP3-c/d (análise + exportação para Ginan/RTKLIB/gLAB) e um propagador de Lagrange de ordem 10 (11 pontos) (Propagator::Sp3Precise); a exportação SP3 está exposta na CLI (kshana <orbit.toml> --export-sp3 out.sp3, ou export_sp3 = true) e validada em ida e volta face à constelação GPS real até <0,5 m ao longo de 24 h (tests/sp3_export_roundtrip.rs); escritor de efemérides CCSDS OEM 2,0 — a exportação do estado TEME com velocidade para ferramentas de dinâmica de voo — agora exposto na CLI (kshana <orbit.toml> --export-oem out.oem, ou export_oem = true) e verificado em ida e volta face ao estado do propagador (tests/sp3_export_roundtrip.rs). O analisador de observações RINEX alimenta agora uma solução de posicionamento de ponto único (pvt, validada com dados IGS reais — ver a linha GNSS / PNT). Além disso, análise + emissão de tracking-data-message CCSDS-TDM (503) (src/ccsds_tdm.rs). Exportações de geometria para visualizadores e ferramentas de análise de missão: CZML, KML (Keyhole Markup Language), GeoJSON e efemérides STK (--export, src/interop/), cada uma analisada de volta por um validador escrito a partir da especificação do formato (tests/interop_formats.rs), uma importação de rota GeoJSON (--import-route), gravações SigMF (Signal Metadata Format) de entrada e saída para o tipo de cenário spectrum, e texto em estilo RINEX-4 / CSV para a mensagem de navegação LEO (INTEROP.md, STANDARDS.md). Sem BeiDou-GEO, sem fixação de ambiguidade inteira em PPP nem RTK cinemático (existem PPP estático de valores flutuantes e RTK de linha de base curta com dados reais, ver a linha GNSS / PNT), sem escritor SPICE e ainda sem OPM/AEM (o leitor OEM existe através do tipo de cenário oem-interop, o escritor OMM em src/omm.rs e um leitor SPICE SPK/PCK em src/naif_kernel.rs) — P2 "anexar domínios adjacentes através de formatos normalizados" |
| Meteorologia espacial / ambiente (iono/atmo/radiação) | partial | Tipo de cenário space-weather (src/space_weather.rs): índices solares/geomagnéticos (tabela de 28 níveis Kp↔ap da IAGA (International Association of Geomagnetism and Aeronomy), Ap diário, F10.7a centrado de 81 dias), temperatura exosférica de Jacchia-71 e um acoplamento de densidade termosférica dirigido pela atividade sobre uma atmosfera estática — MODELLED de primeira ordem, NÃO um modelo de densidade absoluta NRLMSISE. Ionosfera: o modelo difundido de Klobuchar (VALIDATED face ao RTKLIB) e um leitor de mapas IONEX (IONosphere map EXchange format) de TEC (conteúdo eletrónico total) (src/ionex.rs, testado unitariamente). Um mapa ionosférico global CODE real (CODG1330.18I) é a referência medida da linha de TEC oblíquo sem geometria (tests/geometry_free_tec_gim_oracle.rs), mas esse teste avalia o mapa no seu próprio gerador de fixtures, pelo que o leitor src/ionex.rs em si ainda não foi verificado de forma cruzada face a um produto real; sem modelo de ionosfera de base física nem dirigido pela meteorologia espacial; P2+ |
| Navegação por mapas gravíticos / alt-PNT | partial | src/gravimeter.rs: um modelo de medição de gravímetro de átomos frios cujo piso de ruído branco é derivado da ASD do acelerómetro CAI (σ = ASD/√τ), um campo de anomalia gravítica em harmónicos esféricos totalmente normalizados de baixo grau (validado face às funções de Legendre de forma fechada e a uma anomalia de termo único derivada à mão) mais mascons sintéticos, e um filtro de partículas de correspondência com mapas gravíticos (que compõe mapmatch + particle_filter) que recupera uma trajetória sem GPS a partir da sequência de anomalias que atravessa. O teste de referência de 60 minutos sem GPS (run_gps_denied_gravity_nav, scenarios/gps-denied-gravity-nav.toml) percorre uma indisponibilidade de ~700 km / uma hora em que a solução inercial deriva até ≈ 70 km, e um correlacionador hierárquico de grosseiro a fino com o ruído branco determinista com semente do gravímetro recupera-a até ≈ 145 m (< 500 m) — estável entre realizações de ruído, e comprovadamente limitado pelo refinamento (uma única grelha grosseira estagna em ~2 km). Além disso, um modelo completo do campo principal geomagnético IGRF-14 (IGRF: Campo Geomagnético Internacional de Referência) (src/igrf.rs: o campo em harmónicos esféricos normalizado de Schmidt da IAGA até ao grau/ordem 13, 2025,0 + variação secular, coeficientes gerados por máquina a partir do igrf14coeffs.txt oficial; validado face ao dipolo inclinado de forma fechada, a uma diferença finita do potencial escalar e ao polo/intensidade geomagnéticos conhecidos) — o campo magnético que uma plataforma pode correlacionar com mapas para navegação por anomalias magnéticas. Além disso, navegação referenciada ao terreno (TERCOM/SITAN (TERCOM: correspondência de contornos do terreno; SITAN: Sandia Inertial Terrain-Aided Navigation)) e o navegador combinado de gravidade+magnetismo+terreno (src/altpnt/terrain.rs): um analisador .hgt SRTM (Shuttle Radar Topography Mission) de modelo digital de elevação (DEM) escrito de raiz (inteiros de 16 bits com sinal em big-endian, por linhas, linha norte primeiro, vazio -32768; validado face à especificação do controlador SRTMHGT (formato de ficheiros de altura da Shuttle Radar Topography Mission) do GDAL (Geospatial Data Abstraction Library) e a uma referência independente de ponto médio bilinear de forma fechada), um modelo de altímetro radar/barométrico e um correlacionador run_terrain_nav que recupera uma trajetória sem GPS a partir do perfil de elevação do solo face ao DEM, e run_combined_altpnt, que funde três canais de campo escalares por ponto de passagem (Δg mGal · |B| nT de anomalia crustal · elevação m), de modo que a posterior conjunta é mais nítida (CRLB (limite inferior de Cramér–Rao) mais baixo) do que qualquer campo isolado — limitada a < 500 m ao longo da indisponibilidade de 60-min e, em valor esperado, não pior do que o melhor canal isolado. Além disso, navegação referenciada ao terreno sequencial (recursiva) — SITAN como filtro em execução (src/altpnt/sequential.rs, run_sequential_trn): o mesmo modelo de medição altímetro-versus-DEM executado época a época através do motor SIR (reamostragem por importância amostrada) de particle_filter (predizer pelo incremento do INS + ruído de processo → repesar pela correspondência do terreno → reamostrar na degenerescência), de modo que uma deriva do INS variável no tempo é seguida ao longo da trajetória onde o correlacionador em lote recupera apenas um desvio constante único — a estimativa recursiva mantém-se limitada e reconverge (final ≈ 70 m) enquanto a solução sem auxílio diverge sem limite até ≈ 5 km, com o erro por época a acompanhar a distintividade do terreno e um monitor de saúde do tamanho efetivo da amostra. Âmbito com franqueza: o mapa é conhecido e fixo — localização recursiva face a um DEM armazenado (a metade de localização do SLAM de terreno (localização e mapeamento simultâneos)); a estimação conjunta do mapa é o RBPF separado abaixo. Todos os quatro estão agora ligados ao motor de cenários por kind= (gravity-map, terrain-nav, combined-altpnt, terrain-slam) com um gráfico SVG de deriva (scenarios/terrain-nav.toml, scenarios/combined-altpnt.toml, scenarios/terrain-slam.toml). 0,36 (WP-10): o navegador gravity-map aceita um campo de referência real opcional ([reference]: EGM2008 incluído até ao grau 70, ou um ficheiro .gfc do ICGEM), cuja síntese de anomalias coincide com o Serviço de Cálculo do ICGEM até cerca de 1e-8 mGal (VALIDATED, xval/icgem-egm2008/); nesse campo de grau 70, o teste de referência de 60 min termina em 3106 m, pelo que o limiar de < 500 m é NOT MET (fixado antecipadamente e previsto: o grau 70 é demasiado suave). Um Monte Carlo opcional de erro do mapa ([map_error_mc], scenarios/gravity-map-error-mc.toml) mostra que a correção sintética de 144 m pressupõe um mapa exato (1 de 20 realizações dentro de 500 m sob um erro correlacionado de 2 mGal; exploratório). combined-altpnt aceita uma grelha magnética crustal EMAG2v3 opcional ([magnetic_grid]; o EMAG2 é obtido, não incorporado, e não é afirmado nenhum resultado de navegação com ela). terrain-nav permanece apenas com DEM por conceção: é o correlacionador TERCOM/SITAN de canal único, e a correspondência magnética vive em combined-altpnt, que funde o terreno com os canais magnético e gravítico; um canal magnético em terrain-nav duplicá-lo-ia, pelo que o item de auditoria "EMAG2 em terrain-nav" é coberto pela ligação a combined-altpnt (RM-16). As verificações com SRTM real correm em CI sobre dois recortes de resolução total versionados (nó a nó iguais ao GDAL 3.8.4, xval/srtm-ungate/). Existe estimação conjunta do mapa (run_sequential_trn_on_map, um RBPF ao estilo FastSLAM): numa única passagem ganha 1,5 % sobre o SITAN de mapa conhecido num mapa errado, falhando o seu limiar fixado antecipadamente de 10 % (xval/terrain-slam-rbpf/). Continua em falta: um modelo gravítico de alto grau numa execução de navegação (exige um novo pré-registo), um resultado de navegação magnética com grelha real e um caso de SLAM com revisita (fecho de ciclo). P3 |
| Reentrada / EDL (entrada, descida e aterragem), análise de lançamento, EO/carga útil (EO: observação da Terra) | partial | Geometria MODELLED de primeira ordem através de três tipos de cenário executáveis: reentry (src/reentry.rs, corredor balístico de Allen-Eggers — desaceleração máxima, velocidades de g máximo e de aquecimento máximo, altitude de g máximo), launch-window (src/launch.rs, azimute de lançamento de dois corpos sin Az = cos i/cos lat, Δv de mudança de plano, bónus da rotação do local, oportunidades diárias) e eo-coverage (src/eo_payload.rs, geometria EO de faixa / GSD (distância de amostragem no solo) / acesso / revisita em triângulo espacial segundo o SMAD (Space Mission Analysis and Design)). Sem simulação EDL/aerotérmica de 6 graus de liberdade, sem otimizador de trajetória, sem radiometria de sensor/MTF (MTF: função de transferência de modulação). P3 |
| PNT lunar / cislunar (LunaNet) | partial | src/lunar.rs: um motor de ARAIM lunar que reutiliza o núcleo MHSS do lado da Terra com parâmetros LNIS (LunaNet Interoperability Specification) do LunaNet (σ_URE ≈ 30 m, P_sat ≈ 1e-4), a redução de referencial cislunar MCI↔MCMF (MCI: inercial centrado na Lua; MCMF: centrado e fixo à Lua) (mci_to_mcmf / mcmf_to_mci, um modelo simplificado de rotação média à taxa sideral) e latitude/longitude/altitude selenográficas (mcmf_to_selenographic), e uma passagem de nível de proteção no polo sul (south_pole_hpl_pass) que quantifica a lacuna de integridade — com 30 m de medição de distância, o HPL é finito mas excede um limite de alerta de operações à superfície de 50 m. src/cr3bp.rs acrescenta o CR3BP (problema restrito circular de três corpos) Terra–Lua (dinâmica em referencial rotativo + propagador RK4 + constante de Jacobi + os cinco pontos de Lagrange, validado face aos valores publicados de L1/L2/L3 e aos exatos de L4/L5) — o núcleo de três corpos de que uma NRHO (órbita de halo quase retilínea) real necessita — e um corretor diferencial de tiro único com matriz de transição de estado (cr3bp_jacobian, propagate_state_stm, differential_correct_halo) que produz órbitas de halo/NRHO L2 genuinamente periódicas: a STM é validada face a diferenças finitas, os halos corrigidos fecham-se sobre si próprios com precisão de máquina (com conservação de Jacobi), e a semeadura com o estado de apolúnio publicado reproduz a NRHO L2 sul 9:2 (a órbita do Gateway) com período ≈ 6,57 d e perilúnio ≈ 3 250 km — coerente com os ≈ 6,56 d / ≈ 3 370 km publicados | As IC (condições iniciais) da NRHO corrigidas por diferenciação estão agora ligadas, mas a transformação selenocêntrica (MCI/MCMF) desnormalizada da órbita corrigida e a continuação de famílias continuam a ser desenvolvimentos seguintes; a orientação lunar de eixos principais DE440 com libração física real existe (src/lunar_orientation.rs, a partir do PCK moon_pa_de440, verificada face ao SPICE pxform em tests/lunar_pa_orientation_spice_oracle.rs), mas o caminho lunar::mci_to_mcmf mais antigo ainda usa a rotação média sem libração nem o polo em precessão; a NRHO é uma solução CR3BP (circular, sem Sol), não validada face a uma efeméride real LANS/Gateway (LANS: Lunar Augmented Navigation Service); um tipo de cenário lunar-integrity executável (scenarios/lunanet-araim.toml) expõe a passagem do polo sul a partir da CLI | transformação selenocêntrica + continuação de famílias + interface SPICE/LunaNet: P3 |
| PNT de espaço profundo / interplanetário (Marte, radiométrico) | partial | Entregue na v0.17.0. Um motor de navegação radiométrica: tempo de luz iterativo + atraso de Shapiro, Doppler e distância bi/uni/tridirecionais (duas pernas de Moyer), retorno coerente do transponder, medição de distância regenerativa/PN (PN: pseudo-ruído) (CCSDS 414), Δ-DOR (CCSDS 506), meios de plasma solar/tropo/iono (src/radiometric.rs); análise + emissão CCSDS-TDM (503) (src/ccsds_tdm.rs); um SRIF de dinâmica reduzida (filtro de informação em raiz quadrada) com acelerações empíricas RTN (radial, transversal, normal) + um relógio de bordo de 3 estados + arrastamento de Marte (src/deepspace_od.rs, clock_state.rs, mars_atmos.rs) que alcança OD em LMO de Marte (LMO: órbita baixa de Marte) ≈ 0,2 m num ciclo fechado sintético; fusão unidirecional+bidirecional; um núcleo de dinâmica multicorpo (src/body.rs, GMM-3 de Marte (GMM: Goddard Mars Model), referencial IAU de Marte src/mars_frame.rs, uma junção EphemerisProvider src/ephem_provider.rs, JD em duas partes + TT↔TDB (TDB: Tempo Dinâmico Baricêntrico)); e o cenário de PNT de retransmissão mars-pnt (constelação areoestacionária MARCONI, src/mars_pnt.rs) + um simulador de desempenho de GSE de ponta a ponta (src/gse_sim.rs). Validado por simulação (FoM de covariância/ciclo fechado); dinâmica centrada no Sol verificada de forma cruzada face ao DE440 do JPL (Jet Propulsion Laboratory) (137 m @ arco de 1 dia, xval/anise-mars-od). Em falta: validação com dados reais de seguimento DSN/ESTRACK (ESTRACK: European Space Tracking network); gravidade de Marte no seu referencial nativo (o campo GMM-3 de g/o 120 carrega-se a partir da tabela PDS SHADR, from_shadr, VALIDATED face ao pyshtools, e liga-se através de Body::with_gravity_field, mas é avaliado no referencial IAU e não no seu próprio referencial Konopliv-2006); efemérides de nível DE no núcleo (condicionadas a kernel em xval). P3 |
| Sistema solar e PNT em torno de qualquer corpo | partial | Tipo de cenário solar-system: posições, velocidades e constantes físicas do Sol, dos planetas, de Plutão, da Lua e de sete grandes luas numa época, com o tempo de luz entre corpos; as posições dos planetas (elementos de Standish do JPL) e o tempo de luz são VALIDATED face ao JPL Horizons (tests/solar_system_horizons_reference.rs), as luas, Plutão e a tabela dos planetas exteriores permanecem MODELLED. Tipo de cenário body-pnt: um orbitador ou módulo de aterragem em torno de qualquer corpo catalogado (Marte, a Lua, Europa, Ganimedes, Titã e os restantes) a navegar com pseudodistâncias unidirecionais de uma constelação Walker local mais uma distância bidirecional opcional a partir da Terra — MODELLED. Sem kernel de efemérides planetárias no núcleo (elementos analíticos), as órbitas de retransmissão body-pnt usam apenas J2 (os campos completos GMM-3 de Marte de g/o 120 e GRAIL GL0660B da Lua de g/o 660 carregam-se a partir de tabelas PDS SHADR e ligam-se a um Body para o propagador, src/gravity_pds.rs). P3 |
| Campanhas / composição de missões | partial | Tipo de cenário campaign (src/campaign.rs): tipos de cenário existentes encadeados numa cronologia partilhada (por exemplo jamming, depois spoofing, depois holdover com um INS a deslizar, depois um alarme de integridade, depois recuperação), varreduras de parâmetros e conjuntos de Monte Carlo com semente sobre qualquer tipo de cenário, e vários cenários sob condições partilhadas com um resumo combinado; cada número é lido de uma execução real do tipo de cenário membro. As identidades de composição são testadas (tests/campaign_composition_reference.rs: uma campanha de uma só fase reproduz a execução autónoma byte a byte); MODELLED. Uma secção [optimize] (grelha ou Nelder–Mead limitado sobre uma a três chaves, uma métrica, minimizar, maximizar ou atingir um alvo) satisfaz os seus limiares de forma fechada e de força bruta fixados antecipadamente (tests/campaign_optimize_reference.rs); MODELLED, uma procura local sem qualquer afirmação de ótimo global, e sem método de gradiente nem bayesiano. P3 |
| Relatórios, animação e saídas | partial | Cada execução escreve result.json, um gráfico e um relatório (report.html, report.json) cujas etiquetas são lidas da matriz de verificação e cujo comando registado reproduz o resultado byte a byte (tests/advanced_report_cli.rs); --animate (svg, html ou frames) apresenta uma série temporal como animação (src/animation.rs, ANIMATION.md); --export escreve os formatos de intercâmbio da linha de interoperabilidade. São representações da execução, não evidência sobre a física. |
Ecossistema e prontidão (acompanhados com franqueza, não uma capacidade do código)#
| Área | Estado | Nota |
|---|---|---|
| Ligações de linguagem e empacotamento | partial | Rust + Python (abi3) + WASM em três registos. Superfícies tipadas (0,36, CAP-34): RunOutput em Python com acessores NumPy (array, columns, series) e ScenarioKind / ErrorKind / KindMeta com stubs tipados; run_typed em JavaScript (um objeto RunOutput tipado) e scenario_kinds, com o mesmo vocabulário nas declarações TypeScript. Os documentos de resultados continuam a ser JSON por tipo de cenário, tipados apenas pelo seu envelope partilhado (units, versões) |
| Educação / UX (experiência do utilizador) de integração | partial | Playground no navegador com modo guiado entregue: controlos deslizantes guiados adaptados ao cenário (web/studio/lib/guided.mjs, até seis parâmetros por cenário) e uma visita guiada interativa (web/studio/lib/tour.mjs, repetível a partir do playground). Cada execução recebe também uma frase de significado em linguagem simples e as suas figuras principais, lidas do documento de resultados (web/studio/lib/meaning.mjs, com modelos por tipo de cenário em meaning-kinds.mjs; um tipo de cenário sem modelo recebe a sua primeira figura de destaque indicada de forma simples). Em falta: explicações guiadas por figura para além dessa frase (o GLOSSARY.md em linguagem simples cobre-as) |
| Comunidade / governação | partial | Estrutura de governação presente — GOVERNANCE.md (modelo de mantenedor benevolente + limiar técnico + fronteira aberto/fechado), CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md, modelos de issues/PR (PR: pull request), FUNDING.yml, dependabot. Fundador único; uma comunidade externa ativa (contribuidores, citações) depende de pessoas/tempo e ainda está a formar-se (divulgação a aguardar revisão) |
| Prontidão de financiamento e aquisição | none | TRL ~3; ainda sem citações/contratos de agências (ver notas de estratégia) |
Atualizado em 2026-10-29 para o motor 0.40.0 (92 tipos de cenário, a partir de kshana kinds --json; novos na 0.40.0: mission-thread, lunar-orbit-rendezvous, lunar-descent, lunar-surface e lunar-ascent). 2026-10-22: motor 0.39.0, 87 tipos, nenhum tipo novo. 2026-10-19: motor 0.38.0, 87 tipos (novos na 0.38.0: holdover-test, gnss-ssv e lunar-infrastructure). 2026-10-18: 84 tipos (novo na 0,37: optical-atmosphere). 2026-10-16: 83 tipos (novos na 0,36: acm-link, aocs, ascent-losses, contact-schedule, entry-heating, eo-radiometry, lunar-station-coverage e time-transfer-budget). 2026-10-10: motor 0.35.0, 75 tipos, nenhum tipo novo. 2026-10-09 e 2026-10-08: revisões anteriores. 2026-10-04: a linha Nav-signal anota a camada IQ da 0.31.0. 2026-09-29: linhas de LEO-PNT, espectro, PNT do sistema solar / de qualquer corpo, campanha e saída adicionadas. Antes: alinhado à matriz de 27 linhas de capacidades da grande auditoria de 2026-06-02; linha de PNT de espaço profundo / Marte adicionada na v0.17.0. As adições de PNT quântico (holdover de relógio sem GNSS src/holdover.rs, orçamento composto de navegação inercial-quântica por estima QuantumNavBudget, estudo de compromisso de projeto de códigos de alcance CodeFamily, matriz de verificação verificada por máquina src/verification.rs) foram incorporadas às linhas de Temporização, sensor de PNT quântico, Nav-signal e V&V — cada uma etiquetada como validada ou modelada conforme a sua referência independente real.
Acrescentos do demonstrador FutureNAV (modelados, verificados internamente de forma cruzada — não validados externamente): (1) Banco de ensaio de avaliação de deteção de degradação de RF por aprendizagem automática src/impairment_eval.rs — um corpus de degradação sintético etiquetado (com base em parâmetros, não IQ) + uma estrutura de ROC/AUC/confusão/Pfa-Pmd independente do detetor (ROC: característica de funcionamento do recetor; AUC: área sob a curva) com proteção contra fugas e divisão estratificada; os detetores incluídos são linhas de base transparentes de métodos publicados, não o estado da arte (SOTA), e uma AUC elevada aqui demonstra o pipeline, não o desempenho em terreno. (2) Motor de compromisso PNT quântico versus clássico src/quantum_trade.rs — ingestão de ADEV medido (ajuste NNLS (mínimos quadrados não negativos) de σ_y²(τ)=q_wf/τ + q_rw·τ/3 + q_drift·τ³/20, verificado em ida e volta face a q_from_allan), uma tabela de benefícios de holdover de temporização/inercial que transporta no artefacto a ressalva do pressuposto de piso, e uma envolvente de resiliência versus tempo sem GNSS; quantifica o benefício quântico de um parceiro, nunca valida o dispositivo. Ambos revistos de forma adversarial (um erro de base de deriva τ²→τ³ e uma afirmação falsa de resiliência "limitada indefinidamente" foram detetados e corrigidos). 911 testes da biblioteca na altura desse acrescento, fmt+clippy limpos.
Acrescento de intercâmbio / formato normalizado (src/interchange.rs): o Kshana Interchange Format (KIF) — um Envelope neutro, versionado e autodescritivo que envolve qualquer artefacto (cenário, resultado, estudo de compromisso) com uma etiqueta format reconhecível, a SCHEMA_VERSION de fonte única de verdade (a versão do esquema, antes copiada como literal em 15 locais, é agora detida numa só constante que toda a crate referencia), o engine_version produtor e um contrato de compatibilidade explícito e testado (compatibility(): a mesma versão principal / versão secundária igual ou mais antiga é legível sob a disciplina de campos aditivos; uma versão secundária mais recente ou uma versão principal diferente é recusada na fronteira por Envelope::parse em vez de ser analisada incorretamente em silêncio). Reversível (wrap→to_json→parse→payload_as::<T>()) para qualquer carga Deserialize; deliberadamente sem marcas temporais para preservar a reprodutibilidade bit a bit do Kshana. Documentado em SCHEMA.md, para que o formato seja citável e não apenas emitido — o posicionamento de "norma em espera" do núcleo aberto. 923 testes da biblioteca na altura desse acrescento, fmt+clippy limpos.
Acrescentos da construção de dominância FutureNAV (modelados, verificados internamente de forma cruzada — não validados externamente): (1) Camada frugal de custo por cobertura / ROI (retorno do investimento) src/frugal.rs — uma camada de enquadramento de benefícios sobre o motor de dimensionamento de constelações (walker) que indica o custo por ponto percentual de cobertura e o ROI de cobertura por euro face a uma linha de base; o custo por satélite é um intervalo baixo/nominal/alto com fonte, fornecido por quem chama (sem preços pontuais inventados), pelo que as saídas são intervalos e não pontos espúrios; um enquadramento económico modelado de um valor de cobertura modelado, não uma cotação. (2) Mapeamento do impacto na integridade das deteções falhadas src/integrity_impact.rs — associa um enviesamento de posição não detetado, induzido por spoofing/jamming, ao seu erro efetivo → região de Stanford (disponível / sistema indisponível / enganoso / perigosamente enganoso) face a limites de alerta específicos do contexto (céu aberto vs urbano, HAL vs VAL), compondo o RAIM classify_stanford ancorado externamente; a ponte deteção falhada→limite de alerta é modelada, não é uma atribuição de integridade certificada. Ambos estão associados à matriz de verificação verificada por máquina (src/verification.rs, invariante Validated⇒ExternalDataset intacta; a contagem atual de linhas é o cabeçalho gerado de VERIFICATION-MATRIX.md). A divisão com validação cruzada / proteção contra fugas / estratificada por parâmetros para a estrutura de avaliação de IA já tinha sido entregue em src/impairment_eval.rs (stratified_split, Split::has_leakage). 951 testes da biblioteca na altura desse acrescento, fmt+clippy limpos.
Acrescentos do estudo da diferença de otimismo FutureNAV (modelados, verificados internamente de forma cruzada face a formas fechadas — não validados externamente, não uma afirmação de simulação-para-terreno): um estudo sintético controlado da diferença de otimismo da AUC entre dentro da distribuição→fora da distribuição para detetores de degradação de RF. (1) Detetores aprendidos src/impairment_ml.rs — um mapa de características fixo + normalizador ajustado ao treino, uma linha de base de regressão logística (descida de gradiente determinista em lote completo) e um MLP (perceptrão multicamada; retropropagação com SGD (descida de gradiente estocástica) com semente) de uma camada oculta, por trás do mesmo trait ImpairmentDetector que as linhas de base de métodos publicados usam. (2) Estatísticas derivadas à mão src/eval_stats.rs — intervalos de confiança (IC) por bootstrap de percentis, variância/IC da AUC de DeLong, ρ de Spearman e regressão ridge, cada uma verificada face a uma forma fechada (AUC binormal Φ(d′/√2), uma variância de DeLong calculada à mão, um ρ de postos empatados de manual, recuperação exata por OLS (mínimos quadrados ordinários)). (3) O estudo src/impairment_study.rs — AUC por classe, a tendência de lei de escala por (detector,class) (diferença vs 1−gravidade) e um preditor ridge da diferença apenas com dados ID que estima a diferença de otimismo apenas a partir de diagnósticos dentro da distribuição, pontuado deixando de fora um detetor e deixando de fora uma classe face a uma linha de base que prevê a média. Artefacto de um só comando através de cargo run --release --example optimism_study. Cada número é uma AUC sobre etiquetas derivadas de modelo num corpus sintético, com base em parâmetros; a diferença é uma variação de gravidade sintético→sintético, nunca um resultado de deteção em terreno. Associados à matriz de verificação verificada por máquina (src/verification.rs, invariante Validated⇒ExternalDataset intacta).