Kshana的定位
Kshana是一个开放的、可复现的PNT（定位、导航与授时）韧性证据引擎。你描述一个场景：传感器或时钟、一次GNSS（全球导航卫星系统）中断、一次压制干扰（jamming）或欺骗干扰（spoofing）攻击、一份预算；它就告诉你时间和位置能保持得多好，并对照运行性能指标（FoM）打分。这些指标背后的每项能力，都在经机器检查的矩阵中被标为VALIDATED（与独立的外部参考基准（oracle）核对一致）、MODELLED（内部自洽，未经外部核对）或PARTNER（由硬件合作方负责）。本页说明它的强项在哪里、它用来做什么，以及它不是什么。
强项所在：关键基础设施的授时与守时（holdover）#
引擎中核对得最充分的部分是授时。电信网络、电网和金融交易场所都从GNSS获取时间，而且各自都必须确定守时（holdover）的规模：本地时钟在GNSS丢失期间自由运行多久，其时间误差才会突破预算。
- 哪些是VALIDATED。守时结论所依据的频率稳定度估计器，即阿伦偏差（ADEV）、修正阿伦偏差（MDEV）、时间偏差（TDEV）、最大时间间隔误差（MTIE）和扩展范围的Theo1估计器，已对照Stable32参考偏差、独立的
allantools库和一台真实实测的铯钟进行核对。守时外推方差的计算及其反演为守时时长，已对照SciPy核对。每一行及其测试和参考基准（oracle）见VERIFICATION-MATRIX.md。 - 哪些仍是MODELLED。每个时钟类别的噪声下限（例如某一振荡器类别的长期下限）决定了稳定时钟的结论，它们是有代表性的数值，不是对你的器件的测量。对于你打算为之辩护的数字，请提供实测的下限。
- 电信单位。
telecom-timing场景类型报告MTIE和TDEV，对照国际电信联盟电信标准化部门（ITU-T）的模板检查它们（主基准时间时钟（PRTC）用G.8272，增强型PRTC（ePRTC）用G.8272.1，电信边界时钟（T-BC）用G.8273.2，参考点C处的网络限值用G.8271.1），并报告守时（holdover）在每个时间误差预算内能维持多久。见TELECOM-TIMING.md。
它的不同之处#
物理和标准并不是区别所在：简化通用摄动4（SGP4）传播、阿伦偏差、参考坐标系和精度因子在其他库中都有，免费而且正确，Kshana也对照其中好几个检查自身。区别在于证据的纪律：
- 开放。引擎采用GNU Affero通用公共许可证（AGPL），因此任何人都可以阅读并重新运行它。另有商业许可，用于闭源集成。
- 可复现。结果由
scenario + seed + engine version逐位决定，运行也可以作为指向浏览器演练场的链接来分享。 - 标注出处。每个传感器参数都可追溯到一个已发表的来源（
PROVENANCE.md），每项能力都带有其VALIDATED / MODELLED / PARTNER等级。持续集成（CI）守卫会拒绝没有独立外部参考基准（oracle）的VALIDATED行，因此内部的自检不能被当作验证呈现。
我们没有找到另一个开放工具，能在守时、完好性、惯性外推和量子传感器上把这些结合起来，但搜索不到并不证明不存在；我们不声称自己是唯一的。
量子：中立的权衡方法，结果标为MODELLED#
Kshana用同一份代码在同一个场景上比较量子与经典的时钟和惯性传感器：每个器件都是一个误差模型，引擎并不知道哪一个是“量子”的。请把它看作一种中立的量子与经典权衡方法，其结果标为MODELLED。大多数输入是已发布的阿伦/噪声预算系数；冷原子干涉仪加速度计有一个第一性原理层，由它推导出其噪声系数。合作方实测的阿伦偏差数据可以通过quantum-trade类型输入，这就是提升某个具体器件数值等级的途径。见QUANTUM.md和QUANTUM-MODELS.md。
月球、地月空间和深空：予以维持，不作为主线#
月球 / 地月空间套件（月球完好性监测、地月三体核心、月球时标、服务区分析）以及深空射电导航引擎是予以维持的能力。它们的大部分行是MODELLED，而且已有专门的工具服务于月球导航，因此它们作为同一引擎的能力提供，各自带有自己的等级，而不是作为主线。
引擎的其余部分#
同一个引擎、同样的等级，还涵盖：
- 低地球轨道（LEO）PNT，端到端。信号设计（
leo-signal）、过境和分频段链路预算（leo-pass）、广播导航电文（leo-navmsg）、融合的中、低地球轨道定位（leo-pvt）、带LEO增强的精密单点定位（PPP）收敛（leo-ppp）、基于5G非地面网络的定位（ntn-positioning），以及leo-pnt-chain，后者把每一阶段的输出交给下一阶段，针对同一个系统。 - 频谱。在脚本化的干扰源时间线下的L频段（以及特高频（UHF）、S和C频段）功率谱密度瀑布图，带分频段干信比和有效载噪密度（
spectrum），以及SigMF（Signal Metadata Format）录制的输入和输出。 - 太阳系和任意中心天体。行星和主要卫星的位置和物理常数（
solar-system）、围绕其中任一天体的定位（body-pnt），以及围绕其中任一天体的、带覆盖和精度因子图的Walker与公布时隙的星座设计（constellation-design）。 - 测评活动。现有类型串联在同一条共享时间线上、做扫描、作为带随机种子的蒙特卡罗集合运行，或在共享条件下并排运行（
campaign）。 - 输出。每次运行都写出一份结果文档、一张图表以及HTML（超文本标记语言）和JSON（JavaScript对象表示法）格式的报告；
--animate写出SVG（可缩放矢量图形）、HTML或帧序列动画；--export为把对象置于地球上的类型写出CZML（Cesium Language）、KML（Keyhole Markup Language）、GeoJSON或STK（Systems Tool Kit）星历，并为spectrum写出SigMF。
这些行大多是MODELLED；验证矩阵点明了其中少数VALIDATED的行（例如国际电信联盟的降雨和闪烁建议书、Galileo广播星历算法、CRC-24Q（24位循环冗余校验）帧检查和行星光行时求解器）。
Kshana不是什么#
- 不是射频（RF）信号模拟器或硬件在环（HIL）试验台。Kshana不驱动任何无线电硬件，也不发射任何东西。它的大部分工作处于误差模型和链路预算的层面，在购置硬件或实验室时间之前使用。在信号层面，它只是软件：GNSS IQ层（
iq）为软件接收机写出合法GNSS信号的基带同相/正交（IQ）采样文件，并在其上运行自己的软件接收机；spectrum类型的[iq]部分（自0.29.0起）写出其解析模型的SigMF（Signal Metadata Format）快照，其中包含所配置的干扰源（类噪声干扰源逐频点，单音和啁啾按波形）；spoof_capture则在内存中把真实信号与欺骗源复制信号相加以测试环路捕获，而不写出。用真实射频激励测试硬件接收机，是射频模拟器的工作。 - 不是MATLAB/Simulink、STK或Orekit的替代品。它与它们并列。它读取和写出它们所用的交换格式，包括CCSDS（Consultative Committee for Space Data Systems）轨道星历电文、SP3（Standard Product 3）精密轨道、RINEX（Receiver Independent Exchange Format），并为它们的查看器写出CZML、KML、GeoJSON和STK星历；它的数值力模型是对照Orekit做交叉检查，而不是用来取代它。
- 不是载波相位GNSS处理引擎，也不是定位服务（见下文）。
- 不是认证机构。VALIDATED标签表示某项能力与外部参考基准（oracle）一致；它不是对任何产品或操作人员的认证。
与GNSS处理引擎相比，Kshana是什么、不是什么#
Kshana 不是载波相位GNSS 处理引擎，也没有任何场景类型是定位服务。它在测量域确实有一席之地，那是性能研究所依赖、并对照独立参考检查过的库代码。基于真实双频RINEX观测、带LAMBDA（最小二乘模糊度降相关平差）整数固定的短基线实时动态（RTK）定位可以运行，使用IGS最终轨道和钟差的静态浮点精密单点定位（PPP）滤波器亦然，而该滤波器估计的接收机时钟是对照IGS最终测站时钟的授时解。这三者各自是验证矩阵中的一个VALIDATED行，对照其中所指名的IGS测站数据；而且每一项都在静态的短观测窗口上运行，不是流式服务，也没有长基线上的整周模糊度解算、载波平滑或动态流动站。leo-ppp类型对码和载波相位运行浮点PPP滤波器，但用的是它自己仿真的测量，目的是研究有无LEO增强时的收敛时间；它不处理观测文件。pvt类型（位置、速度和时间）根据真实的RINEX码伪距加广播星历求解接收机位置，并对照国际GNSS服务（IGS）的测绘坐标（ABMF站，2018-05-13）做了核对，结果为3-D RMS（均方根）5.7 m / 水平1.1 m。但产品是性能研究，而不是定位服务，下文的说明是为了让潜在用户免于选错工具的失望。
| Kshana | GNSS处理引擎（RTKLIB，一个开源的实时动态定位库；gLAB，加泰罗尼亚理工大学gAGE小组的GNSS实验室工具套件） | |
|---|---|---|
| 输入 | 一个场景：传感器误差模型、中断窗口、几何；或者对pvt而言，是真实的RINEX观测文件加广播导航电文 |
真实的GNSS观测（RINEX）、星历、修正 |
| 输出 | 性能指标：守时、授时/位置误差、可用性、完好性/安全性界，外加来自pvt类型的码单点定位（SPP）位置 |
位置/速度/时间解（SPP、PPP、RTK） |
| 它回答的问题 | “这种架构会有多好，它在哪里失效？” | “根据这些测量，我现在在哪里？” |
| 量子 / 光学传感器 | 建模为误差模型（光钟、冷原子惯性测量单元（IMU）、光学时间传递），结果标为MODELLED | 未建模 |
| 真实观测的处理 | 基于真实RINEX观测的码SPP（pvt，米级）；短基线RTK（LAMBDA）和基于真实载波相位的静态浮点PPP，作为对照IGS测站检查过的库代码（VALIDATED，静态且短窗口，不是流式服务）；外加几何 / 精度因子（DOP）/ 可用性 |
核心专长，一直延伸到载波相位PPP/RTK |
| 安装 | 零：在浏览器标签页中运行（WebAssembly） | 原生构建 / 工具链 |
互补而非竞争：RTKLIB和gLAB#
RTKLIB和gLAB是成熟、被广泛使用的GNSS处理套件。它们接收真实测量并给出定位解（SPP/PPP/RTK；gLAB还是一个出色的教学工具，在欧洲航天局（ESA）和欧洲静地导航重叠服务（EGNOS）中有深厚的传承）。Kshana 不替代它们，也不打算替代。它的观测路径很窄：码单点定位（pvt），以及作为经检查的库代码，基于真实双频观测的、带LAMBDA整数固定的短基线RTK和静态浮点PPP滤波器，均对照IGS测站数据做了VALIDATED（PPP滤波器还对照了在相同输入上运行的RTKLIB）。它没有载波平滑，没有动态或流式处理，也没有长基线的整周模糊度解算，并且pvt不估计对流层或电离层：它应用的是Saastamoinen/Niell对流层模型和L1/L2无电离层组合，而不是把它们作为状态来求解。
这条流水线是互补的：
- RTKLIB / gLAB回答“根据这些信号，我在哪里？”
- Kshana回答“这些信号中断之后，我还能保持多久的良好结果，更好的时钟或惯性传感器（无论经典还是量子）又能换来多少？”
一种自然的工作流是：在GNSS可用的时段使用处理引擎，用Kshana研究其周围的守时（holdover）行为和传感器权衡空间。如果你需要载波相位定位服务（动态PPP或RTK、长基线、网络整周模糊度解算），请使用RTKLIB或gLAB；如果你需要关于韧性和守时的、可复现且带标签的证据，那正是Kshana所要做的工作。
零安装的浏览器层#
这一领域的大多数仿真工具（RTKLIB、gLAB、通用任务分析工具（GMAT）、Orekit、STK）都需要原生安装或许可，并且在得到第一个结果之前需要一段学习过程。Kshana编译为WebAssembly并完全在浏览器中运行：演练场载入一个示例场景，在客户端运行真正的引擎（不上传任何内容），几秒钟内显示结果。带引导的滑块和一键场景意味着第一个有用的结果无需TOML（Tom's Obvious Minimal Language，场景文件格式），也无需工具链。
这种零安装层是一个刻意的立场：
- 触达：审阅者、学生或采购人员可以通过一个链接在任何设备上试用真正的引擎，无需任何设置。
- 可复现性：随浏览器发布的引擎，就是发布在crates.io、Python包索引（PyPI）和npm上的库；结果可根据
scenario + seed + engine version复现，运行也可作为URL（网址）分享。 - 诚实：亲自、公开地运行引擎，是对“相信这些数字”最有力的反驳：浏览器层就是审计界面。
浏览器层并不使Kshana成为桌面处理套件的替代品，它使性能权衡研究这一问题，对那些永远不会安装此类套件的人也变得容易上手。
另请参阅#
CAPABILITY.md：逐行的范围图（pvt求解器的完整范围和残差见 GNSS / PNT处理一行）。VALIDATION.md：哪些已核对，附证据。TELECOM-TIMING.md：电信授时类型及其模板。GLOSSARY.md：此处所用术语的通俗定义。web/README.md：浏览器演练场。