• Ensaye el minuto en que el GNSS se apaga
• Novedades de 0,40, Novedades de 0,39, Novedades de 0,38 y 0,38 en detalle: puntuación de jammertest, los indicadores propios del receptor, entradas de máquina, temporización y holdover, paquetes de normas, LunaNet AFS, la ida y vuelta de laboratorio, kshana-bench, el observatorio, exportadores, óptica, navegación de usuarios espaciales e infraestructura lunar
• Kshana Studio y cada página de Studio
• Capacidades: la tabla de áreas, cada tipo de escenario por familia, cada comando, cada superficie
• Cómo funciona una ejecución, Misiones
• Evidencias: el registro, dominios de capacidades
• Instalar, Arquitectura (y los diagramas), asistente de IA
• Ediciones, Investigación, Cómo citar, Licencia
• Referencia: uso, formato de escenario, salida, estructura del repositorio, preguntas frecuentes, solución de problemas, versionado, hoja de ruta, contribuir, documentación

Ejecute cualquiera de ellos con kshana example <scenario> > s.toml && kshana s.toml: los escenarios son l-band-waterfall-jamming, constellation-multi-gnss-coverage, solar-system-tour y leo-pass-iridium.

Los cuatro son datos inventados y de carácter consultivo: muestran el formato y el comportamiento del software, no cómo se comporta ningún receptor o sistema frente a interferencias. Ejecute el primero con kshana receiver-trust examples/maritime-trust/session.toml, el segundo con kshana route-exposure sobre las muestras de examples/interference-map/, el tercero con kshana nmea-scenario scenarios/training/coastal-drag-off.toml --out drag.nmea (solo para formación: nunca lo introduzca en equipos de navegación en servicio) y el cuarto como en docs/EVIDENCE-PACKS.md.

A continuación sigue el detalle completo dominio por dominio; para un registro de madurez por capacidad véanse docs/CAPABILITY.md y docs/VALIDATION.md.

Cada capacidad es accesible como API de Rust, como kind de escenario ejecutable, o ambos. La madurez de cada capacidad — validada, ejecutable o de biblioteca — se sigue en docs/CAPABILITY.md. Una matriz de verificación comprobada por máquina (src/verification.rs) presenta la referencia cruzada requisito → módulo → prueba → referencia independiente → estado, con invariantes de honestidad probados unitariamente que permiten una etiqueta validada solo cuando la respalda una referencia independiente externa — y que registran las capacidades de hardware/PA (garantía del producto) que Kshana deliberadamente no ofrece.

Resultados#

Cada escenario compara un sensor cuántico con su equivalente clásico a lo largo de una interrupción del GNSS de ~1,8 h. Las cifras son reproducibles (scenario + seed + version).

_{Lo que aportan los sensores cuánticos cuando falta el GNSS — clock-holdover · semilla 42 · dibujado con el motor 0.40.0, y cada figura anterior se vuelve a comprobar con el motor actual en cada compilación mediante tests/published_figures_still_reproduce.rs · SVG}

La ventaja depende de la duración de la interrupción y de la vibración, con un punto de equilibrio explícito en el que gana el sistema clásico — mostrada con honestidad a lo largo de la escala de madurez tecnológica (las cifras del reloj óptico son objetivos de demostrador en tierra; ningún reloj óptico de estroncio ha volado):

_{Cruce de resiliencia cuántico frente a clásico — escala TRL del holdover del reloj (arriba) · mapa de ventaja inercial con contorno de punto de equilibrio (abajo). Regenerable mediante cargo run --release --bin crossover_study.}

Error de posición de la navegación por estima durante una interrupción del GNSS: el sensor cuántico (azul) se mantiene plano cerca de la especificación; el sensor clásico (rojo) diverge hasta decenas de kilómetros. Generado por Kshana a partir de scenarios/imu-deadreckoning.toml.

El colofón muestra la tesis de la fusión: la transferencia óptica de tiempo entre satélites mantiene enganchado incluso un reloj clásico, de modo que el sensor inercial queda aislado como el eslabón débil del conjunto clásico — es decir, inercial cuántico + temporización óptica en conjunto.

Holdover del reloj durante una interrupción del GNSS: el reloj óptico (azul) se mantiene dentro de la especificación de 20 ns durante toda la deriva; el reloj de escala de chip (rojo) la supera a mitad de la interrupción. Generado por Kshana a partir de scenarios/clock-holdover.toml.

Otro escenario, orbit-gnss-challenged.toml, deriva la disponibilidad del GNSS de la geometría orbital en lugar de ventanas definidas a mano: una nave espacial dentro de la capa del GNSS se propaga frente a una constelación Walker de tipo GPS, y el número de satélites visibles (línea de visión, ocultación por la Tierra, máscara de elevación) fija el estado de la solución de posición en cada paso. A lo largo de un día el usuario tiene solución de posición solo ~59 % del tiempo; el reloj cuántico mantiene una solución de temporización de 5 ns durante todos los huecos (disponibilidad 1.0), el reloj de escala de chip solo ~0.83.

Error de temporización a lo largo de un día con la disponibilidad del GNSS derivada de la geometría orbital: el número de satélites visibles (línea de visión, ocultación por la Tierra, máscara de elevación) fija el estado de la solución de posición en cada paso, de modo que el reloj debe sostener cada hueco — el reloj óptico mantiene la especificación de 5 ns mientras que el reloj de escala de chip la supera. Generado por Kshana a partir de scenarios/orbit-gnss-challenged.toml.

La constelación también puede darse como conjuntos reales de elementos de dos líneas (TLE). Un TLE completo (línea 1 + línea 2) se propaga con el modelo SGP4/SDP4 completo — que incluye la resistencia atmosférica y los términos lunisolares de espacio profundo y de resonancia de 12 h / 24 h que importan para las órbitas GNSS de ~12 h — validado frente a los vectores oficiales AIAA 2006-6753 con un caso más desfavorable de ≈ 4 mm. scenarios/orbit-sgp4-gps.toml incluye una instantánea real de Celestrak gps-ops de la constelación GPS operativa (2021-07-28, 30 satélites) y exige sumas de comprobación de TLE válidas — los conjuntos de elementos de dos líneas son datos abiertos del catálogo del Servicio Espacial de EE. UU. / 18.º Escuadrón de Defensa Espacial, redistribuidos por Celestrak (Dr. T. S. Kelso, celestrak.org); se actualizan con scripts/fetch_tles.sh. Un bloque con solo la línea 2 conserva la propagación analítica de dos cuerpos (scenarios/orbit-real-tle.toml); las dos formas pueden mezclarse en una misma constelación. Una constelación también puede construirse a partir de un bloque de registros de efemérides de difusión GPS en RINEX-3 — el formato que decodifica un receptor — propagados con el algoritmo de usuario de IS-GPS-200 y procesados con la misma geometría (scenarios/orbit-rinex.toml).

Qué es y qué no es#

Es: un motor determinista y con pocas dependencias que abarca toda la pila PNT — geometría orbital, navegación inercial, fusión GNSS/INS, integridad, relojes y temporización. Ejecuta un escenario (a menudo una interrupción del GNSS), hace evolucionar modelos de error de sensores calibrados a través del estimador adecuado y puntúa el resultado frente a las figuras de mérito operativas, emitiendo un resultado JSON (JavaScript Object Notation) reproducible y un gráfico SVG, desde una biblioteca de Rust, una interfaz de línea de comandos (CLI), una extensión de Python, un módulo WebAssembly en el navegador, un servidor Model Context Protocol (MCP) para agentes de IA o un complemento para IDE (entorno de desarrollo integrado) de JetBrains.

No es: hardware de vuelo, un diseño de carga útil cuántica, un receptor completo de señales GNSS, un simulador de señales de radiofrecuencia (RF) ni un banco de pruebas con hardware en el bucle, ni un producto de aviónica certificado — y no sustituye a MATLAB/Simulink, STK (Systems Tool Kit) ni Orekit; se sitúa junto a ellos e intercambia archivos con ellos. La fidelidad del hardware cuántico procede de modelos de error publicados, no de esta herramienta. La madurez detallada de cada capacidad está documentada en docs/CAPABILITY.md.

No es (todavía): un motor de física de interferometría atómica completo (la mayoría de los sensores cuánticos consumen coeficientes publicados de Allan/presupuesto de ruido; el acelerómetro CAI (interferómetro de átomos fríos) tiene una capa de primeros principios — fase de Mach–Zehnder, ruido de proyección, decaimiento del contraste y acoplamiento de vibraciones, además de sistemáticos de Coriolis y de desplazamiento por luz — pero los sistemáticos de frente de onda y la resolución de la ambigüedad de franjas siguen siendo una capa de hoja de ruta P2 (fase 2 de la hoja de ruta, la capa de física cuántica), véase ROADMAP.md y docs/QUANTUM-MODELS.md); un receptor GNSS certificado o de hardware (resuelve una posición PVT (posición, velocidad y tiempo) de punto único a partir de observaciones de código RINEX (Receiver Independent Exchange Format) reales — validado con datos reales del IGS (International GNSS Service) — y su capa de IQ (kshana iq, desde 0.31.0) adquiere y sigue en software muestras de banda base grabadas o generadas, como receptor de análisis: no controla hardware de radio ni transmite, no es un receptor certificado y no hace posicionamiento por fase de portadora (RTK ni PPP)); ni una suite completa de diseño de misiones (tiene bloques de construcción de Lambert / porkchop / maniobra / determinación de órbita, pero es la capa de simulación de desempeño por encima de GMAT (General Mission Analysis Tool)/Orekit, no un sustituto). Asumir este alcance es deliberado. Si necesita presupuestos de error de interferómetros de átomos fríos de primeros principios (p. ej., de nivel CARIOQA-PMP — Cold Atom Rubidium Interferometry in Orbit for Quantum Accelerometry, Pathfinder Mission Preparation — o validación al estilo X-37B), consulte la hoja de ruta P2 y póngase en contacto para colaborar.

Validación, reproducibilidad y honestidad#

• Cada término de ruido está calibrado con una cifra publicada y citada y validado frente a la relación estándar (desviación de Allan para relojes; crecimiento del error de navegación por estima de Groves para inerciales; la conversión de temporización a distancia para la transferencia de tiempo). El estado de cada término se sigue en docs/VALIDATION.md como validated o not modeled — nada se presenta como validado si no lo está.
• Reproducible por construcción: scenario + seed + engine version → identical bits. scripts/check-reproducible.sh lo impone; las ejecuciones cuánticas y clásicas usan semillas independientes para que su ruido no esté correlacionado.
• La madurez se declara con honestidad: las cifras del reloj óptico y del enlace óptico son resultados de objetivos / demostrador en tierra, no de vuelo.

La etiqueta de evidencia en cada figura#

Cada figura y tabla que escribe una ejecución indica hasta qué punto fiarse de ella y en qué filas del registro se apoya. El JSON de resultados tiene una clave evidence, el SVG del gráfico una línea bajo el trazado (y un elemento <metadata id="kshana-evidence">), y la tabla CSV líneas de comentario # evidence: por delante (se leen con comment='#'). Nombra un nivel, VALIDATED, MODELLED o PARTNER, y los identificadores (VM- y ocho dígitos hexadecimales) de las filas de la matriz de verificación que ejercitó la ejecución. El nivel es el más débil de esas filas, de modo que una ejecución que se apoya en una fila modelada se etiqueta MODELLED por muchas filas validadas que haya a su lado; la etiqueta nunca puede afirmar más que el registro. Las filas, los estados y los identificadores se leen de la matriz, no se escriben a mano (docs/VERIFICATION-MATRIX.md, docs/SCHEMA.md), y tests/evidence_labels_doc_sync.rs falla si una figura no tiene etiqueta o si una etiqueta discrepa de la matriz.

La validación de un vistazo#

Cada fila la hace cumplir una prueba con nombre en la CI. Esta tabla es una selección destacada; la matriz completa verificada por máquina es de 401 filas — 176 VALIDATED, 221 MODELLED, 4 PARTNER (src/verification.rs), con las evidencias completas (y lo que honestamente no está todavía validado) en docs/VALIDATION.md y el artefacto kshana-validation-summary.html de cada versión (generado por cargo run --bin validation_report, con atestación SLSA — Supply-chain Levels for Software Artifacts).

La columna Estado indica el tipo de evidencia, de acuerdo con la escala de validación anterior: VALIDATED = contrastado con una referencia independiente externa (datos reales, una biblioteca independiente o vectores de referencia publicados); MODELLED = contrastado con la verdad analítica o con la autoconsistencia de la simulación (sin un conjunto de datos externo independiente). VALIDATED describe el método de comprobación, no un resultado de aprobado/suspendido — un fallo honesto frente a una referencia independiente externa real sigue siendo VALIDATED, mientras que una comparación que ninguna fila de la matriz nombra como referencia independiente (el ajuste a LRO — Lunar Reconnaissance Orbiter — de arriba) se muestra como MODELLED. Las filas de CI son salvaguardas de proceso, no figuras de mérito. Unas pocas islas de datos reales (el reloj de cesio medido, Stable32 PHASE.DAT y las comprobaciones OPS-SAT/ICGEM cuyos datos de entrada en bruto no tienen licencia de redistribución) están condicionadas por datos: la prueba imprime un aviso de omisión y se mantiene en verde cuando falta la entrada, y las cifras públicas de referencia se confirman en tests/fixtures/. Los datos de entrada en bruto se reproducen con el scripts/fetch_*.sh correspondiente.

_{Cómo gana una capacidad su etiqueta — el invariante aplicado por CI: sin referencia independiente externa ⇒ no puede quedar validada · SVG}

_{Arriba: cada fila validada está respaldada por un conjunto de datos externo, por construcción. Abajo: SGP4 coincide con la referencia oficial en todos los regímenes (caso más desfavorable 4,12 mm). SVG · SVG}

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

import json, kshana

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

Además de run, el módulo expone run_full (JSON, SVG y el resumen de una línea a la vez), run_typed, validate_toml, list_kinds / scenario_kinds y error_kind; véase docs/PYTHON_API.md.

El paquete npm es el motor completo compilado a WebAssembly. En Node.js, pase el binario a initSync; en un navegador, await init() lo descarga (véase README.npm.md).

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

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

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

Un motor, muchas puertas de entrada. Un único núcleo de Rust (kshana) ejecuta cada escenario, al que se accede mediante una CLI, una extensión de Python, un módulo WebAssembly en el navegador, un servidor MCP para agentes de IA y un complemento para IDE de JetBrains — todos convergen en un único despacho api::run_toml. En su interior, los paquetes de sensores se conectan a una interfaz común de modelos de error; junto a ellos hay una capa de marcos de referencia (precesión–nutación IAU 2006/2000A y la reducción GCRS↔ITRS basada en CIO), una capa de astrodinámica/numérica (SGP4/SDP4 analítico y un propagador numérico de Cowell con su modelo de fuerzas EGM2008/perturbaciones, diseño de maniobras y determinación de órbita), una capa de integridad/GNSS (RAIM/ARAIM, SBAS, el dominio de medida, jamming, cislunar), una capa de fusión / PNT alternativo (los estimadores GNSS/INS y los correladores de mapas de gravedad/terreno/magnéticos), una capa de espacio profundo y lunar (PNT radiométrico de Marte y la suite de PNT lunar, con su nivel de evidencia por pieza en la matriz — tiempo LTC, VLBI, OD+reloj conjunta, realización de marcos, volumen de servicio, PNT diferencial, interoperabilidad), una capa de análisis de misión (presupuestos de lanzamiento / reentrada / cobertura / apuntamiento / paso / enlace y el entorno de meteorología espacial) y la capa abierta de estudios de resiliencia y aprendizaje automático (puntuación de resiliencia RPCF, la brecha de optimismo ante degradaciones de RF y el demostrador de PNT con tecnología cuántica) cuyos artefactos reproducibles se apoyan en los núcleos validados.

Dos crates independientes, excluidos del workspace, están junto al núcleo — mcp/kshana-mcp (el servidor MCP, construido sobre el SDK rmcp de la edición 2024) y xval/anise-frames (la comprobación cruzada de marcos de ANISE/SPICE, que incorpora dependencias MPL-2.0 (Mozilla Public License 2,0)) — que se mantienen fuera del grafo de dependencias del crate publicado, de Cargo.lock, de la puerta de licencias y de la compilación de MSRV (versión mínima compatible de Rust) mediante la lista exclude de Cargo.toml de la raíz. El complemento de JetBrains (ide/jetbrains) es un proyecto independiente en Kotlin. Véase docs/ARCHITECTURE.md para el conjunto completo de diagramas.

Los diagramas renderizados (flujo del motor, mapa de módulos, distribución) están en docs/ARCHITECTURE.md.

Escenarios e informes

Exportación e interoperabilidad

Confianza en receptores y buques

IQ de GNSS (archivos del directorio de trabajo; desactivado en modo HTTP)

Correspondencia de compliance

Benchmark

Sobre qué se construye Kshana Pro. Cada parte de Pro funciona a partir del motor abierto y lo deja sin cambios:

• El optimizador de diseño, el estudio de incertidumbre y el dosier de misión ejecutan escenarios del motor abierto a través de la interfaz pública del motor y calculan cada cifra a partir de los resultados de las ejecuciones. Cada salida conserva el nivel VALIDATED, MODELLED o PARTNER que el motor abierto dio a cada cifra, nunca uno superior.
• Los gemelos digitales de relojes usan el modelo de reloj del motor abierto y su estimador de desviación de Allan: un gemelo se calibra con el presupuesto de Allan publicado del dispositivo y después se comprueba estimando la desviación de Allan del gemelo con el estimador abierto.
• Los estudios de compromisos ejecutan cada opción de arquitectura como un escenario del motor abierto, sin cambios, y clasifican las opciones según una figura de mérito leída del resultado de cada ejecución.
• La vigilancia de campañas lee sus cifras de los resultados de ejecuciones del motor abierto de los escenarios de un paquete y las compara con la ejecución anterior que pasó.
• La coexistencia de espectro lee cada cifra física de ejecuciones del motor abierto de los tipos de escenario leo-signal y constellation-design, y añade solo la suma sobre los satélites a la vista y la clasificación de los planes.
• El servicio de trabajos en las instalaciones ejecuta escenarios abiertos y de Pro con el mismo motor y almacena cada resultado tal como lo devolvió la ejecución.
• Los paquetes de evidencias registran, para cada ejecución, el hash del escenario que el motor abierto estampa en su resultado, de modo que una cifra de un paquete pueda reproducirse volviendo a ejecutar su escenario.
• Herramientas de ingeniería de sistemas y de programa. Las herramientas de ingeniería de sistemas basada en modelos (MBSE) y de programa de Kshana Pro comprueban los requisitos de un programa frente a ejecuciones del motor abierto: importan requisitos como valores separados por comas (CSV), o como un subconjunto documentado del Requirements Interchange Format (ReqIF) o del texto de Systems Modeling Language versión 2 (SysML v2), evalúan cada criterio de aceptación, con su unidad, frente a los valores que escribió una ejecución, y producen una matriz de referencia cruzada de verificación (VCRM), un modelo SysML v2, un informe de impacto de cambios y un paquete de evidencias sin conexión. No vuelven a ejecutar ni recalculan nada, y leen solo lo que publica el motor abierto: el result.json de cada ejecución (los campos que nombra un criterio, sus unidades, el sello de reproducibilidad con hash del escenario, semilla, versión del motor y versión del esquema, y la etiqueta y los niveles de las cifras de la ejecución), su report.json (tipo de escenario, registro de reproducibilidad y etiquetas de capacidad), el archivo de escenario (su hash, tipo de escenario, semilla y parámetros), el esquema de unidades de campo (la unidad, la procedencia y el nivel de evidencia de cada campo) y la matriz de verificación (la etiqueta VALIDATED, MODELLED o PARTNER de cada capacidad).

Soporte y servicios profesionales#

Kshana es gratuito y de código abierto bajo la AGPL-3.0 y está desarrollado y mantenido profesionalmente por Ashforde® OÜ (Estonia). El motor abierto está completo y es utilizable por sí solo. Para las organizaciones que necesitan más, Ashforde® OÜ ofrece:

• Soporte comercial e integración — incorporar Kshana a su cadena de herramientas, escenarios a medida y correcciones prioritarias.
• Modelos de sensores a medida — calibrados para su hardware, incluidos modelos de resiliencia sujetos a control de exportación mantenidos en una capa privada.
• Kshana Pro — herramientas propietarias de ingeniería de sistemas basada en modelos (MBSE) y de programa que comprueban los requisitos de un programa frente a ejecuciones del motor abierto y producen una matriz de referencia cruzada de verificación (VCRM), un modelo de Systems Modeling Language versión 2 (SysML v2), un informe de impacto de cambios y un paquete de evidencias sin conexión. No vuelven a ejecutar nada y leen solo las salidas publicadas del motor: el result.json y el report.json de cada ejecución, el archivo de escenario, el esquema de unidades de campo y las etiquetas de la matriz de verificación (la lista completa está en Ediciones).
• Herramientas de diseño, incertidumbre y misión de Kshana Pro — el frente de Pareto de un espacio de diseño, incertidumbre y sensibilidad sobre miles de ejecuciones, y un dosier de misión con un solo comando, con una matriz de verificación y un PDF; véase docs/PRO.md.
• Vigilancia de campañas, coexistencia de espectro y servicio de trabajos de Kshana Pro — un pipeline que falla cuando empeora una cifra vigilada, planes de señal probados frente a las señales abiertas de navegación por satélite en ambos sentidos, y una cola de trabajos en las instalaciones con un registro de entrega encadenado por hash; véase docs/PRO.md.
• Formación y consultoría sobre análisis del desempeño de PNT cuántico/clásico.

Este es el modelo open-core: el motor tiene, y seguirá teniendo, una licencia abierta; el negocio que lo sostiene es la experiencia, el soporte y las extensiones propietarias, no las cuotas de licencia. Contacto: contact@ashforde.org · ashforde.org.

Instalar y compilar#

Requiere una cadena de herramientas de Rust (≥ 1,88, la rust-version de Cargo.toml; desarrollado con 1,93).

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

Uso#

Ejecute cualquier escenario; la CLI despacha según el campo kind del escenario y escribe <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html y <scenario>.report.json junto a él — además de <scenario>.table.csv para los tipos de escenario que publican una tabla. El informe (una página de HyperText Markup Language (HTML) y un documento JSON con el mismo contenido) incluye un resumen ejecutivo, cada entrada con su unidad, los resultados y los gráficos, las tablas de barrido, Monte Carlo o encadenamiento de una campaña, una cronología de eventos, la etiqueta VALIDATED / MODELLED / PARTNER y la fuente de cada capacidad que usó la ejecución, lo que no está modelado y un registro de reproducibilidad (versión del motor, resúmenes Secure Hash Algorithm de 256 bits (SHA-256), semilla, plataforma y el comando exacto). Se imprime como un archivo PDF (Portable Document Format) limpio desde el navegador en papel A4 o Letter; el motor no escribe ningún PDF por sí mismo. Véase docs/REPORTS.md.

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

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

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

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

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

--export <czml|kml|geojson|stk|sigmf|all|list> escribe junto al escenario grabaciones CZML (el Cesium Language), KML (Keyhole Markup Language), GeoJSON (Request for Comments 7946), efemérides .e de Ansys STK (Systems Tool Kit) y SigMF (Signal Metadata Format), y --import-route <route.geojson> introduce una línea GeoJSON en los tipos de escenario que vuelan una trayectoria. Cada formato se valida frente a su especificación publicada, y un escenario al que no se aplica un formato explica el motivo: véase docs/INTEROP.md.

Otros modos de la CLI — comprobar un escenario con lint, introducir datos reales de orientación de la Tierra o ejecutar una suite completa:

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

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

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

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

Exportación de animaciones. --animate svg|html|frames|all escribe <scenario>.animation.svg (fotogramas clave de Cascading Style Sheets (CSS), sin script), <scenario>.animation.html (reproducir, pausar, desplazar, velocidad y paneles sincronizados, sin ningún recurso externo) y <scenario>.frames/ (frame_0000.svg, … más manifest.json con los fotogramas por segundo y la duración). Una campaña reproduce sus fases y alarmas, una ejecución de espectro su cascada; el tema sigue prefers-color-scheme y prefers-reduced-motion muestra la imagen final. Representa las propias muestras de la ejecución, idénticas byte a byte al repetirla, y no añade evidencias. Véase docs/ANIMATION.md.

Un manifiesto de suite es un pequeño archivo TOML (Tom's Obvious, Minimal Language) — un title y una matriz scenarios = [ … ] de rutas de escenarios — que el motor ejecuta por turnos, integrando cada resultado (con sus etiquetas MODELLED / VALIDATED) en un artefacto de estudio autodescriptivo. Véase scenarios/quantum-pnt-demonstrator.suite.toml.

Papel en la interoperabilidad. Kshana es la capa de simulación de desempeño que se sitúa junto a la cadena de posprocesamiento, no un sustituto de ella: introduzca su salida RINEX en RTKLIB o gLAB para obtener una solución de posición y use su salida SP3 como producto de órbita precisa para herramientas como Ginan — Kshana responde a qué resiliencia aporta una arquitectura PNT dada antes de tener señales reales, en formatos que esas herramientas ya ingieren (--export-sp3, o export_sp3 = true en un escenario orbit, escribe <scenario>.sp3). La misma órbita puede publicarse como elementos medios CCSDS OMM de la vía de normalización (--export-omm, o export_omm = true, escribe <scenario>.omm) — un mensaje OMM 502,0 KVN (notación palabra clave = valor) por satélite definido por TLE, con el número de catálogo NORAD (North American Aerospace Defense Command), el designador internacional COSPAR (Committee on Space Research) y la época reales de cada objeto, para cualquier consumidor que entienda OMM en lugar de un conjunto de elementos de dos líneas a medida.

Salida de ejemplo (holdover del reloj — observe cómo se informan las figuras de mérito de integridad y de seguridad):

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

El error de temporización del percentil 95 (p95) del reloj óptico es de 1.20e-4 ns: el resumen imprime los valores pequeños con cifras significativas en lugar de redondearlos a 0.0. security muestra n/a (no attack) porque este escenario no configura ningún ataque, de modo que no hay nada que detectar. El resultado JSON sigue incluyendo la cota analítica de detectabilidad de spoofing de cada reloj en fom.security (0,997 para el reloj óptico, 0,000 para el reloj atómico de escala de chip, cuyo propio ruido durante la ventana de monitorización supera la especificación de 20 ns), y su bloque figure_tiers marca esa cifra como applicable: false. El tipo de escenario spoof puntúa la detección frente a un ataque inyectado. figure_tiers también da a cada cifra informada su nivel de verificación — VALIDATED (contrastada con una referencia independiente externa) o MODELLED — y la fila de la matriz de verificación de la que se lee el nivel. El escenario de órbita informa además un bloque de geometría — fracción de muestras con solución de posición y mejor/mediana dilución de la precisión de posición (PDOP) y exactitud de posición — junto al resultado del reloj.

Lea estas dos cifras con atención. security es una cota analítica de detectabilidad de spoofing derivada de la estabilidad de cada reloj — solo tiene sentido frente a un escenario de spoofing configurado y no es un detector RAIM multisatélite. integrity aquí es la autoconsistencia del filtro (fracción de muestras de la interrupción dentro de su propia cota de k sigmas), no una cifra de integridad HPL/VPL de aviación. Véase docs/INTEGRITY.md.

Para una integridad autónoma del receptor genuina, el tipo de escenario integrity (scenarios/integrity-raim.toml) ejecuta RAIM real instantáneo y de separación de soluciones (estilo ARAIM) sobre la geometría de la constelación propagada: calcula los niveles de protección (HPL/VPL) horizontal/vertical por época e informa de la fracción de épocas que satisfacen los límites de alerta configurados, con un diagrama de integridad de Stanford para la clasificación de error frente a PL (nivel de protección).

Artefactos de estudio reproducibles

Cuatro estudios abiertos regeneran cada uno un artefacto determinista byte a byte (semilla fija) con un solo comando — las cifras que hay detrás del cruce cuántico frente a clásico, la brecha de optimismo ante degradaciones de RF, la puntuación de resiliencia PNT y los estudios del nivel de protección de temporización:

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

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

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

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

Cada artefacto registra la versión del motor, las semillas y un hash de configuración, y lleva una etiqueta honesta MODELLED/VALIDATED. Las sondas de datos reales (*_probe) ejecutan el mismo pipeline sobre grabaciones que usted suministra localmente; en el repositorio no se incluye ningún conjunto de datos. El estudio de la brecha de optimismo ante degradaciones de RF se describe en el preprint arXiv:2606,22054, y el nivel de protección de temporización condicional (tpl_jammertest arriba) en el preprint arXiv:2606,24210 (véase Citar).

Los estudios publicados de PNT lunar (arXiv:2607,06212 DOP con balizas en superficie, arXiv:2607,02566 observabilidad con VLBI y arXiv:2610,23871 observabilidad cislunar por longitud de arco) tienen sus afirmaciones de geometría, dilución de la precisión, predicción de marcos en tiempo real / parámetros de orientación de la Tierra (EOP), órbita retrógrada distante y medición de distancia por RF contrastadas de forma independiente en tests/validate_p*.rs con referencias independientes distintas (scipy.special.j1, una resolución independiente de DOP con (HᵀH)⁻¹ de NumPy, un nuevo análisis con NumPy de las mismas filas finals2000A del IERS y la Three-Body Periodic Orbit Database de NASA/JPL). Son comprobaciones de regresión adicionales sobre la suite lunar modelada; no cambian el recuento de la matriz comprobada por máquina.

Formato de escenario#

Los escenarios son TOML declarativo. Un campo kind de nivel superior selecciona el paquete — cincuenta en total (clock es el predeterminado si se omite): inertial, timetransfer, hybrid, hybrid-ukf, fusion, gnss-ins, orbit, ephemeris, gnss-sim, integrity, lunar-integrity, lunar-time-offset, spoof, spoof-detect, jamming, sweep, sweep-nd, gravity-map, terrain-nav, terrain-slam, combined-altpnt, pvt, mars-pnt, impairment-eval (banco de pruebas de evaluación de detección de degradaciones de RF con aprendizaje automático — corpus sintético etiquetado + arnés de ROC/AUC independiente del detector + brecha de optimismo dentro/fuera de la distribución), quantum-trade (compromiso PNT cuántico frente a clásico con ingesta de ADEV medido + envolvente de resiliencia sin GNSS; MODELLED), space-weather (índices solares/geomagnéticos + temperatura exosférica de Jacchia-71 + densidad termosférica impulsada por la actividad sobre la atmósfera estática; MODELLED), oem-interop (puente de importación/viaje de ida y vuelta de CCSDS OEM para efemérides de GMAT/Orekit/STK; MODELLED), el trío de análisis de misión launch-window (acimut de lanzamiento de dos cuerpos / cambio de plano / oportunidades), reentry (corredor de reentrada balística de Allen-Eggers), eo-coverage (geometría de franja / GSD / acceso / revisita de observación de la Tierra), space-packet (encapsulado de paquetes espaciales TM/TC — telemetría/telecomando — CCSDS 133,0 — disposición exacta de bits, verificada en viaje de ida y vuelta) y attitude-budget (par de gradiente de gravedad en 3-DOF + presupuesto de error de apuntamiento RSS), passes (predicción de pasos de salida/puesta sobre estación terrestre — AOS/TCA/LOS, elevación máxima, acceso) y link-budget (ecuación de enlace unidireccional CCSDS/DSN — FSPL / Eb·N₀ / margen / cierre); telecom-timing (error de tiempo en holdover, MTIE y TDEV contrastados con las máscaras de ITU-T); spectrum (toda la banda L del GNSS como una sola densidad espectral de potencia: una cascada de frecuencia por tiempo bajo una cronología guionizada de interferidor de onda continua, banda estrecha, chirp o ruido adaptado, relación interferencia-señal por banda y densidad de ruido a portadora efectiva a partir del coeficiente de separación espectral, y entrada y salida de grabaciones Signal Metadata Format (SigMF) con estimaciones espectrales de Welch; los espectros de señal VALIDATED frente a valores de manual, el escenario de interferidor MODELLED; véase docs/SPECTRUM.md; el mismo tipo de escenario dibuja paneles de banda UHF, S y C con señales diseñadas de órbita terrestre baja); leo-signal (diseños de señales de posicionamiento, navegación y temporización de órbita terrestre baja para cualquier sistema: espectros de banda limitada, fluctuación del seguimiento de código y exactitud de medición de distancia, búsqueda y tiempo de adquisición, separación espectral frente a GPS y Galileo, tolerancia al interferidor y un compromiso de banda UHF a C, a partir de preajustes públicos como Xona Pulsar, Iridium, Starlink y CentiSpace o de diseños en línea; las formas cerradas y el Doppler LEO VALIDATED, los diseños MODELLED; véase docs/LEO-SIGNAL.md); solar-system (el Sol, los planetas, Plutón, la Luna y siete lunas principales en una época — posiciones, constantes, tiempos de luz y trayectorias orbitales; posiciones de los planetas VALIDATED frente a JPL Horizons) y body-pnt (posicionamiento alrededor de cualquiera de esos cuerpos con una constelación de navegación local y un enlace de espacio profundo desde la Tierra; MODELLED); campaign (tipos de escenario existentes compuestos en una cronología de misión encadenada con el estado traspasado entre fases, un barrido de parámetros, un conjunto de Monte Carlo con semilla o varios escenarios bajo una condición compartida; MODELLED, véase docs/CAMPAIGNS.md); constellation-design (patrones Walker delta y estrella, listas de elementos y diseños multicapa con preajustes de GPS, Galileo, BeiDou y GLONASS, y cobertura y dilución de la precisión sobre una malla de latitud/longitud; el generador y el DOP global de GPS VALIDATED frente a los documentos de servicio publicados, véase docs/CONSTELLATION-DESIGN.md); leo-pass (un paso de satélite de posicionamiento, navegación y temporización (PNT) de órbita terrestre baja (LEO) y su presupuesto de enlace banda por banda, para cualquier constelación y cualquier diseño de señal: ángulos de visión, Doppler y tasa de Doppler, pérdidas de ITU-R por lluvia, gases, centelleo y penetración en edificios, densidad de ruido a portadora frente a los satélites GNSS MEO a la vista, la ionosfera de primer orden y los pares libres de ionosfera, y un presupuesto de solución de posición de baja energía, sondeo de la ionosfera con cada par de bandas, y monitores de spoofing por consistencia de Doppler y geometría del paso y por consistencia entre bandas; los términos de ITU-R y la envolvente Doppler de usuario estático VALIDATED, el paso MODELLED, véase docs/LEO-PASS.md); leo-navmsg (el mensaje de efemérides y reloj de difusión de un satélite PNT de órbita terrestre baja (LEO), para cualquier órbita y portadora: un ajustador desde una órbita de verdad integrada hasta el conjunto kepleriano de Galileo, ese conjunto con polinomios de corrección along-track, cross-track y radial, el modelo de 22 parámetros de Liu et al. 2025 o el polinomio ECEF de reloj cero ATOMIC; error de alcance de la señal en el espacio (SISRE) frente al intervalo de ajuste y al período de actualización, una comprobación de continuidad de actualización a mitad de paso, la propia trama binaria documentada de Kshana con una comprobación de redundancia cíclica CRC-24Q y un presupuesto de cuantización, y un bloque de estilo RINEX-4 etiquetado como extensión de Kshana; los pesos de SISRE, el algoritmo de usuario de Galileo y el CRC-24Q VALIDATED, los ajustes MODELLED; preajustes opcionales para Xona Pulsar, Iridium, Starlink, CentiSpace, un sistema representativo en banda C, ATOMIC y Celeste IOD; véase docs/LEO-NAVMSG.md); el trío de PNT fusionado MEO + LEO leo-pvt (posicionamiento Doppler a partir de la velocidad de alcance de órbita terrestre baja (LEO), soluciones conjuntas de pseudodistancia GNSS + LEO con sesgos entre sistemas y el DOP en función del número de satélites LEO, cobertura polar y ártica y transferencia de tiempo LEO a UTC — sobre cualquier constelación, con preajustes opcionales como las señales de oportunidad de Xona Pulsar, Iridium y Starlink; la envolvente Doppler LEO VALIDATED frente a las cifras publicadas de Iridium y Xona), leo-ppp (convergencia del posicionamiento preciso de punto solo con GNSS y con aumentación LEO, comparada con Li et al. 2019) y ntn-positioning (posicionamiento 5G de red no terrestre a partir de la cota de Cramér-Rao del ancho de banda de la señal), MODELLED salvo esa envolvente, véase docs/LEO-PNT-FUSION.md; leo-pnt-chain (un sistema LEO-PNT de extremo a extremo: un diseño leo-signal transportado por una banda leo-pass, el C/N0 del paso y el error de alcance de la señal en el espacio del mensaje de navegación entregados a una solución fusionada leo-pvt y a la convergencia de leo-ppp, con cada traspaso enumerado; MODELLED, véase docs/LEO-PNT.md, que es también la visión general de todos los tipos de escenario y escenarios LEO-PNT, incluidas las campañas de resiliencia, un escenario por área de enfoque experimental y uno por sector de usuario final); la suite de PNT lunar lunar-vlbi, lunar-joint-od-clock, lunar-frame-realisation, moonlight-service-volume, lunar-differential-pnt, lunar-interop-export; el demostrador de PNT con tecnología cuántica quantum-time-transfer, quantum-gnss-free-nav, quantum-anomaly-detect; y los tipos de escenario de investigación de seguridad de señal, cislunar y resiliencia por capas lunar-attack-surface, realtime-frame-eop, lunar-time-budget, hybrid-optical-rf, cislunar-observability, conflict-resilience — el trío de análisis de misión y estos tipos posteriores, todos MODELLED (cada uno con un núcleo de forma cerrada validado; véase la matriz). Campos comunes: seed, una malla [time], una cronología de disponibilidad [gnss] (el factor de las interrupciones) y bloques por sensor con cadenas provenance que citan la fuente de cada cifra. Ejemplo (reloj):

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

Campos opcionales (desactivados si faltan): un reloj puede añadir flicker_floor (suelo de Allan de FM — modulación de frecuencia — 1/f); un sensor inercial puede añadir gyro_bias y q_arw (sesgo del giróscopo y paseo aleatorio angular), y bias_instability y q_aa (el suelo de inestabilidad del sesgo de Allan y el paseo aleatorio de aceleración) — en conjunto un presupuesto de error de acelerómetro de un solo eje (1-DOF) (VRW/ARW — paseo aleatorio de velocidad/angular — e inestabilidad del sesgo). Este es el presupuesto de error que ejecuta el paquete de escenarios inertial incluido. Por separado, la biblioteca incorpora ahora un navegador strapdown de 3 ejes verificado (src/inertial/{attitude,mechanization,imu_errors}.rs): actitud por cuaterniones con compensación de coning/sculling, una mecanización NED completa (términos de velocidad de rotación terrestre y de transporte, gravedad de Somigliana de WGS-84) y un modelo determinista de error de IMU en el que se modelan el factor de escala, la desalineación, la sensibilidad a g, la cuantización y la rampa de velocidad (IEEE Std 952-1997, el estándar del IEEE de especificación y procedimiento de prueba de giróscopos, §A.2; Groves 2013 §4,3). Esa vía de 3 ejes está ahora conectada a un paquete GNSS/INS ejecutable de acoplamiento débil (kind = "gnss-ins"): un EKF de estado de error de 15 estados disciplina la solución strapdown frente a posiciones ruidosas mientras el GNSS está disponible y después sigue por inercia durante la interrupción, e informa del error horizontal fusionado frente a la deriva INS libre en lazo abierto. También hay disponible una actualización de pseudodistancia de acoplamiento fuerte (forma la innovación en el dominio de la distancia, por lo que sigue corrigiendo con menos de cuatro satélites). Un escenario de holdover del reloj puede añadir runs (> 1) para ejecutar un conjunto de Monte Carlo — cada figura de mérito se informa entonces como una media con una dispersión de los percentiles 5 a 95 y el gráfico sombrea la banda de confianza del error (véase scenarios/clock-ensemble.toml).

Un escenario fusion (mismos bloques que hybrid) ejecuta dos estimadores de Kalman independientes — uno para el estado del reloj y otro para el estado de posición — disciplinados por el GNSS y asistidos por transferencia óptica de tiempo, e informa de una FoM combinada de holdover. Los dos bloques no comparten covarianza cruzada: es un par apilado de presupuestos de error, no un verdadero filtro conjunto acoplado de reloj+posición (la covarianza entre bloques es un elemento de la hoja de ruta). Véase scenarios/fusion-pnt.toml.

Un escenario spoof inyecta un spoofing de tiempo — uno de los cuatro tipos de [attack.shape] (linear_ramp, step_jump, meaconing, replay; un rate_ns_per_s a secas se sigue aceptando como rampa lineal) — y ejecuta el detector de spoofing de cada reloj. El detector es una prueba de energía χ²₁ / de Neyman–Pearson bilateral sobre el estadístico de monitorización asistido por reloj: el umbral se fija a partir de un presupuesto objetivo de falsa alarma target_pfa, y la probabilidad de detección fallida P_md se informa tanto en forma cerrada como por Monte Carlo (mc_runs ensayos por hipótesis — ambas coinciden con una diferencia de unos pocos ×1/√N). La figura de mérito de seguridad es 1 − P_md en la magnitud operativamente dañina (la de la especificación), de modo que un reloj silencioso que detecta un spoofing del tamaño de la especificación puntúa ≈ 1 y uno ruidoso que a menudo lo pasa por alto puntúa menos (véanse scenarios/spoof-attack.toml, scenarios/spoof-meaconing.toml).

Un escenario gnss-sim es una simulación en el dominio de la medida: para cada satélite visible sintetiza la pseudodistancia ρ = geometric range + c·δt_rx − c·δt_sv + I + T + noise + multipath y el Doppler en L1, con la ionosfera monofrecuencia de Klobuchar ([iono], IS-GPS-200 §20.3.3.5.2.5) y la troposfera cenital de Saastamoinen proyectada con la función de mapeo de Niell (1996) ([tropo]). Los residuos alimentan el RAIM instantáneo para obtener HPL/VPL por época, y la pseudodistancia, el Doppler, el C/N₀ y las correcciones iono/tropo de cada satélite se emiten en la matriz gnss_measurements del JSON. Es un simulador directo (genera mediciones a partir de una verdad conocida), no un receptor/solucionador — una ejecución sin ruido reproduce la geometría más las correcciones con precisión submilimétrica (véase scenarios/gnss-sim-raim.toml).

Un escenario jamming modela la interferencia de RF como un presupuesto de enlace: un [jammer] (posición ECEF, power_dbw de transmisión, tipo) eleva la relación interferencia-señal en un [receiver] que observa una [constellation] Walker. A partir de la geometría (pérdida en el espacio libre y ganancia de la antena receptora por dirección) calcula el J/S de cada satélite, la C/N₀ efectiva mediante la ecuación estándar antiinterferencia (ganancia de procesamiento por desensanchamiento × el factor de separación espectral Q; Kaplan & Hegarty §9,4) y señala la pérdida de enganche por debajo de un umbral de seguimiento configurable — informando de una figura de mérito availability_under_jamming. Un interferidor de banda ancha de 10 W a 1 km niega por completo el receptor (J/S ≈ 72 dB); el mismo interferidor a 100 km solo degrada los enlaces (véase scenarios/jamming-demo.toml).

Un escenario sweep ejecuta un estudio de compromisos: varía un parameter (threshold_ns, duration_s, quantum_q_wf o classical_q_wf) desde start hasta stop en steps puntos con una scale lin o log, registra una metric (p. ej., holdover_s) para ambos relojes y representa las dos curvas. El escenario base va bajo [base] (véase scenarios/sweep-clock-stability.toml).

Un escenario sweep-nd generaliza esto a cualquier paquete y cualquier número de ejes: varía claves TOML con puntos de un escenario [base] (de cualquier kind) sobre el producto cartesiano de [[axes]], vuelve a ejecutar cada nodo de la malla y registra metrics dadas como rutas JSON con puntos dentro del resultado (p. ej., classical.fom.holdover_s). Funciona con todos los paquetes porque opera en el límite TOML/resultado; las ejecuciones nativas evalúan la malla en paralelo (sin dependencias adicionales; wasm recurre a la ejecución secuencial) y la salida es determinista y de orden por filas (véase scenarios/sweep-nd-inertial.toml).

Un escenario orbit deriva la cronología [gnss] de la geometría en lugar de definirla a mano — indique una órbita [user], una [constellation], una mask_deg de elevación y los dos bloques de reloj. También informa de la exactitud de posición a partir de la geometría de los satélites; el sigma_uere_m opcional (error de alcance equivalente del usuario a 1 sigma, 1 m por defecto) escala la dilución de la precisión de posición hasta un sigma de posición. La órbita del usuario puede hacerse excéntrica con eccentricity y argp_deg, y j2 = true añade la deriva secular por achatamiento terrestre (véase scenarios/orbit-molniya.toml). La constelación puede ser en cambio una real: dé a [constellation] un bloque tle de conjuntos de elementos de dos líneas y los satélites se leen de él (véase scenarios/orbit-real-tle.toml). Añada uno o más bloques [[constellations]] para multi-GNSS (p. ej., GPS + Galileo; véase scenarios/orbit-multignss.toml):

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

Los tipos de escenario de PNT alternativo sin GPS navegan sin ningún GNSS, haciendo coincidir una secuencia de campo medida con un mapa mediante un filtro de partículas. Un escenario gravity-map vuela una trayectoria a través de un campo de anomalías de gravedad en armónicos esféricos y la recupera a partir de la lectura de un gravímetro de átomos fríos (scenarios/gps-denied-gravity-nav.toml); un escenario terrain-nav hace lo mismo con un DEM de elevación SRTM (TERCOM/SITAN, scenarios/terrain-nav.toml); y un escenario combined-altpnt fusiona gravedad + magnetismo IGRF + terreno en un solo filtro (scenarios/combined-altpnt.toml).

Un escenario lunar-integrity evalúa el PNT cislunar: ejecuta un paso de nivel de protección ARAIM en el polo sur lunar frente a un conjunto de relés LunaNet/LNIS e informa con honestidad de la brecha de integridad — un σ_URE lunar de ~30 m lleva el nivel de protección muy por encima de un límite de alerta de 50 m, de modo que el servicio no está disponible bajo reglas de integridad de estilo aeronáutico (scenarios/lunanet-araim.toml).

Un escenario lunar-time-offset informa de la tasa relativista del reloj Tierra–Luna — la base de una escala de Tiempo Coordenado Lunar (LTC/TCL). Una identidad postnewtoniana de primeros principios suma la diferencia de potencial propio (potencial del geoide de la IAU L_G menos el potencial propio de la superficie de la Luna) y el término cinético de la Luna (efecto Doppler de segundo orden) hasta una tasa secular de ≈ 57 µs/día, informada con la banda publicada de 56–59 µs/día; también da el desfase LTC−TT acumulado a lo largo de un horizonte y un conjunto por varianza inversa (un reloj de papel lunar). MODELLED — la cifra principal depende de la referencia (geoide terrestre frente a selenoide lunar, ventana de promediado), por lo que se informa una banda y no un único número certificado (scenarios/lunar-time-offset.toml).

Consulte scenarios/ para ver al menos un ejemplo práctico de cada tipo de escenario (92 tipos de escenario, 193 archivos de escenario .toml + 1 manifiesto de conjunto; varios tipos de escenario incluyen más de un ejemplo). No todos los tipos de escenario tienen un archivo con su nombre: lunar-integrity → scenarios/lunanet-araim.toml y gravity-map → scenarios/gps-denied-gravity-nav.toml son dos de varios casos así. Puede enumerar en cualquier momento los tipos de escenario despachables con los errores de cargo run -- --validate <file>, con list_kinds() en Python o con la herramienta list_scenario_kinds de MCP.

Salida#

El artefacto de resultado es un JSON versionado y autodescriptivo: series temporales por paso, las figuras de mérito puntuadas, las especificaciones de modelo activas (con su procedencia), la semilla, un hash del escenario — de modo que cualquier gráfico puede reproducirse a partir del archivo — y, para cada reloj, una adev_curve ([{tau_s, adev, n_samples, noise, edf, ci_lo, ci_hi}]): la desviación de Allan solapada a lo largo de tiempos de promediado espaciados por octavas — la forma estándar de leer la estabilidad de un reloj — ahora con una banda de confianza del 95 % específica del tipo de ruido por punto (el tipo de ley de potencias del registro se identifica a partir de su pendiente de Allan modificada, y el intervalo χ² usa los grados de libertad efectivos correspondientes de NIST SP 1065). El playground del navegador la representa como un gráfico log-log de "Estabilidad del reloj (ADEV)". (MDEV, TDEV y HDEV están disponibles como estimadores de la biblioteca; la curva exportada del resultado es la ADEV solapada.) Cada campo, con sus unidades y una referencia a la fuente, está documentado en docs/SCHEMA.md.

Cada gráfico es autodescriptivo. El playground del navegador, la exportación *.chart.svg de la CLI y el cuadro de mando HTML (HyperText Markup Language) estampan en cada imagen de gráfico un pie con el texto Kshana v<version> · scenario <hash> · kshana.dev. El scenario <hash> son los primeros 12 caracteres hexadecimales del hash del escenario de la ejecución — un resumen SHA-256 (Secure Hash Algorithm de 256 bits) sobre la definición canónica del escenario (semilla, umbrales, parámetros del modelo, ventanas GNSS, …); los informes de integridad y lunares, que no llevan hash propio, recurren a un SHA-256 del código fuente del escenario. Es la misma huella que se muestra en el resumen de una línea y en el JSON del resultado, de modo que un gráfico guardado o pegado siempre lleva su versión, el escenario exacto que lo produjo (para reproducirlo bit a bit) y la fuente — si cambia cualquier entrada, cambia el hash.

Las figuras de mérito siguen las figuras de mérito operativas estándar de PNT:

¿Nuevo con estos términos? Cada uno se define en lenguaje llano en el glosario.

Estructura del repositorio#

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

FAQ#

¿Necesito entender la física cuántica para usar esto? No. Si puede ejecutar una línea de comandos, puede ejecutar Kshana. Empiece por la introducción en lenguaje llano; consulte los términos en el glosario.

¿Es un diseño de hardware cuántico o software de vuelo? No. Es un simulador de desempeño. La fidelidad del hardware cuántico procede de modelos de error publicados, no de esta herramienta. Véase Qué es y qué no es.

¿Los resultados cuánticos son realistas o marketing? Cada parámetro se cita a una hoja de datos o un artículo, cada modelo está validado frente a una relación de manual y la madurez se etiqueta con honestidad en VALIDATION.md — incluido que ningún reloj óptico de estroncio ha volado. El motor es neutral: lo cuántico y lo clásico son el mismo código con cifras publicadas distintas.

¿Puedo confiar en que dos ejecuciones coincidan? Sí — las ejecuciones son deterministas: scenario + seed + engine version → bit-identical output, garantizado por scripts/check-reproducible.sh.

¿Puedo usarlo desde Python o en un navegador? Sí — véase Instalar: los ejemplos de Python y WebAssembly están debajo. Ambos llaman al mismo motor.

¿Cómo modelo mi propio sensor? Escriba un escenario .toml con las cifras publicadas de su sensor en los campos provenance. Véanse Formato de escenario y los ejemplos de scenarios/.

¿Es gratuito para uso comercial? Sí — bajo la AGPL-3.0, también en entornos comerciales, siempre que respete el copyleft de la AGPL (en particular: si modifica Kshana y lo ofrece a través de una red, debe ofrecer a esos usuarios su código fuente modificado). Si eso no le conviene — p. ej., necesita incorporar Kshana a un producto propietario o ejecutar un servicio de red cerrado — Ashforde® OÜ ofrece una licencia comercial; véanse LICENSING.md y Soporte.

Solución de problemas#

cargo build falla con una cadena de herramientas antigua. Kshana necesita Rust ≥ 1,88. Actualice con rustup update.

La compilación de la extensión de Python falla al enlazar en macOS (Undefined symbols … _Py…). Una extensión de Python resuelve sus símbolos en el momento de la carga. maturin establece automáticamente la opción de enlazador correcta — use maturin develop --features python en lugar de un cargo build a secas.

La compilación de Python se queja de que el intérprete es más reciente de lo que PyO3 conoce. Establezca PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 (los wheels abi3 son compatibles hacia adelante entre versiones de CPython).

La compilación de WebAssembly no encuentra el destino. Instálelo una vez con rustup target add wasm32-unknown-unknown y luego wasm-pack build --target web -- --features wasm.

¿Dónde está mi salida? Cada ejecución escribe <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html y <scenario>.report.json junto al .toml de entrada, y también <scenario>.table.csv para los tipos de escenario que publican una tabla. Todos ellos están excluidos de git por diseño.

Versiones y lanzamientos#

Kshana sigue el Versionado Semántico. Mientras sea anterior a 1.0, el esquema público de escenario/resultado aún puede cambiar; los cambios incompatibles se señalan explícitamente en CHANGELOG.md. Cada resultado es reproducible a partir de scenario + seed + engine version.

Cada etiqueta vX.Y.Z publica todos los canales automáticamente, en un solo orden — primero se ejecuta la suite de pruebas completa en el commit etiquetado, no se publica nada hasta que pasa y después el pipeline comprueba que cada registro sirve realmente la nueva versión (docs/RELEASING.md). Los canales:

La versión del crate / imagen / registro del servidor MCP sigue la del motor (incluye la biblioteca); el complemento de JetBrains lleva versiones independientes (invoca el binario kshana que tenga instalado).

Hoja de ruta#

Véase ROADMAP.md para la hoja de ruta por fases, CHANGELOG.md para el historial publicado y docs/CAPABILITY.md para la hoja de ruta por capacidad. El orden de prioridad es: primero la evidencia de temporización y holdover para infraestructuras críticas (máscaras de telecomunicaciones, holdover más largo con envejecimiento y ruido flicker, ingesta de datos de reloj medidos); en segundo lugar el método neutral de compromiso cuántico frente a clásico (resultados etiquetados MODELLED hasta que los datos medidos de un socio los promuevan); y la navegación lunar / cislunar y de espacio profundo se mantiene, sin ampliarse como prioridad. La reducción de marcos precisa en ITRF ya está entregada — la cadena completa GCRS↔ITRS IAU 2006/2000A basada en CIO (movimiento polar + nutación subarcosegundo), validada bit a bit frente a SOFA/ERFA y contrastada de forma independiente con ANISE (SPICE en Rust puro) con ≤ 3,6 m en órbita GNSS. Los elementos a corto plazo incluyen la fusión de fase de portadora de acoplamiento fuerte y la exposición del navegador GNSS/INS de acoplamiento débil/fuerte en más paquetes; el motor de navegación radiométrica de espacio profundo / Marte llegó en v0.17.0 (validado por simulación). La capa de física cuántica es un elemento P2: el acelerómetro CAI se simula ahora desde primeros principios (fase de Mach–Zehnder, ruido de proyección, decaimiento del contraste, acoplamiento de vibraciones), mientras que los sensores de reloj/transferencia de tiempo siguen basándose en coeficientes publicados de Allan/presupuesto de ruido. La conversión TEME↔ECEF basada en GMST, los sistemas de tiempo con segundos intercalares del IERS (UTC/TAI/TT/UT1), la propagación orbital SGP4/SDP4 (v0.7.0, validada frente a los vectores AIAA 2006-6753) y el paquete de fusión gnss-ins ejecutable ya se han entregado, y la velocidad inercial se expone aguas abajo. En main han llegado un detector estocástico activo de spoofing de tiempo (prueba de energía de Neyman–Pearson / χ²₁ con P_fa/P_md por Monte Carlo y una FoM de seguridad de 1−P_md), un modelo de jamming con presupuesto de enlace (J/S → C/N₀ efectiva → pérdida de enganche), disponibilidad multiconstelación, un presupuesto de error de IMU de un solo eje (1-DOF), dos estimadores de Kalman independientes (reloj + posición) informados como una FoM combinada, geometría de constelación real a partir de TLE, un informe de cuadro de mando HTML, disponibilidad GNSS derivada de la geometría y dilución de la precisión a partir de órbitas keplerianas con excentricidad y deriva J2, bandas de confianza de Monte Carlo, barridos de parámetros de estudios de compromisos, un playground WebAssembly en el navegador y enlaces opcionales de Python (PyO3) y WebAssembly (wasm-bindgen).

Contribuir#

Véase CONTRIBUTING.md. En resumen: las pruebas pasan (cargo test), los dos scripts de guarda pasan, Conventional Commits, y una entrada [Unreleased] de CHANGELOG.md por cada cambio visible para el usuario. La participación se rige por nuestro Código de Conducta. Para informar de un problema de seguridad, consulte la Política de seguridad — no abra una incidencia pública para vulnerabilidades.

Documentación#

Referencias clave#

Referencias independientes de validación y normas — las autoridades externas a las que se anclan las comprobaciones de Kshana:

• Vallado, Crawford, Hujsak & Kelso — Revisiting Spacetrack Report #3 (AIAA 2006-6753; datos de prueba): el conjunto de verificación de SGP4/SDP4 con el que Kshana coincide hasta 4,12 mm, y los ejemplos de marcos resueltos con los que se contrasta la cadena TEME→ITRF.
• IAU SOFA / ERFA — las rutinas de referencia de tiempo y marcos con las que se validan bit a bit la nutación IAU 2000A y la reducción GCRS↔ITRS basada en CIO.
• Petit & Luzum (eds.) — IERS Conventions (2010), IERS TN (Nota Técnica) 36 (orientación de la Tierra, movimiento polar y estándares de marcos).
• Riley — Handbook of Frequency Stability Analysis, NIST SP 1065 (relaciones de la desviación de Allan y la serie de referencia NBS14; NBS = la antigua Oficina Nacional de Normas de EE. UU.).
• Pedregosa et al. — scikit-learn: Machine Learning in Python, JMLR 12 (2011): las implementaciones de referencia de ROC/AUC, matriz de confusión y precisión/exhaustividad/F1 con las que el banco de pruebas de evaluación de degradaciones de RF coincide exactamente (tests/eval_metrics_reference.rs).
• Virtanen et al. — SciPy 1,0, Nature Methods 17 (2020): optimize.nnls, stats.chi2 y linalg.expm — las rutinas de referencia frente a las que se validan el ajuste NNLS de ADEV medida del compromiso cuántico, las bandas de consistencia χ² y la covarianza del ruido de proceso del reloj de van Loan (tests/scipy_reference.rs).
• Knowles, Kanhere, Neamati & Gao — gnss_lib_py, SoftwareX 27 (2024): usado tanto como estado de la técnica abierto (véase Comparación y estado de la técnica abierto más abajo) como referencia independiente de DOP con la que coincide hasta 1e-6 el cálculo de GDOP/PDOP/HDOP/VDOP/TDOP (tests/dop_reference.rs).
• Montenbruck & Gill — Satellite Orbits: Models, Methods and Applications (Springer): los modelos de fuerzas que hay detrás del ajuste del modelo de fuerzas a las efemérides precisas de agencias.
• Howell — Three-dimensional, periodic, halo orbits, Celestial Mechanics 32(1) (1984), doi:10.1007/BF01358403; Zimovan-Spreen, Howell & Davis — Near rectilinear halo orbits and nearby higher-period dynamical structures, Astrodynamics 6 (2022), doi:10.1007/s42064-021-0125-x (las familias halo/NRHO que reproduce el corrector diferencial del CR3BP).

Física de dispositivos y métodos — las fuentes citadas que hay detrás de los modelos de sensores:

• Origlia, Schiller, Bongs et al. — arXiv:1503,08457 (reloj óptico de red de estroncio, objetivo orientado al espacio).
• Oelker et al., Nature Photonics (2019) — doi:10.1038/s41566-019-0493-4 (reloj de Sr de laboratorio, 4,8×10⁻¹⁷).
• Templier et al., Science Advances (2022) — arXiv:2209,13209 (tríada de acelerómetros cuánticos híbridos).
• Groves, Principles of GNSS, Inertial, and Multisensor Integrated Navigation — tutorial de IEEE AESS (Aerospace and Electronic Systems Society) (repositorio Discovery de University College London) (crecimiento del error de navegación por estima).
• Giorgetta et al., Nature Photonics 7, 434 (2013) — arXiv:1211,4902; Deschênes et al., Phys. Rev. X 6, 021016 (2016) — APS (American Physical Society) (transferencia óptica bidireccional de tiempo-frecuencia; el enlace óptico entre satélites modela su presupuesto de no reciprocidad según estos trabajos).
• Betz — Binary Offset Carrier Modulations for Radionavigation, NAVIGATION 48(4) (2001), doi:10.1002/j.2161-4296.2001.tb00247.x (la teoría de la modulación BOC y de la separación espectral que hay detrás de src/navsignal.rs).
• Kaplan & Hegarty (eds.) — Understanding GPS/GNSS: Principles and Applications (3.ª ed., Artech House, 2017): la ecuación de C/N₀ efectiva antiinterferencia y la fluctuación por ruido térmico del seguimiento de código DLL early–late que usan los modelos de señal de navegación y de jamming.

Comparación y estado de la técnica abierto — las herramientas y estudios frente a los que se posiciona Kshana:

• Humphreys et al. — TEXBAT (la Texas Spoofing Test Battery; ION — Institute of Navigation — GNSS 2012): los parámetros de la batería de pruebas de spoofing con los que se caracteriza el detector multicapa.
• González et al. — NaveGo (2017): los perfiles abiertos y validados de error de navegación inercial usados como línea base clásica.
• Iiyama, Casadesús Vila & Gao — LuPNT (ION GNSS+ 2023, Stanford NavLab): simulador abierto de PNT lunar.
• Knowles, Kanhere, Neamati & Gao — gnss_lib_py, SoftwareX 27 (2024), doi:10.1016/j.softx.2024.101811: análisis abierto de datos GNSS.
• Li, Zaminpardaz, Kealy & Greentree — Quantum sensors for enhanced positioning and navigation: a comprehensive review, GPS Solutions 30(1):62 (2026), doi:10.1007/s10291-026-02030-y.
• Bertone et al. — Earth and Space Science 8(6) (2021), doi:10.1029/2020EA001454: OD de dinámica reducida con GRAIL, el suelo de aceleración empírica que reproduce el ajuste a LRO.