接收机信任度：评估真实的GNSS接收机日志

kshana receiver-trust读取真实全球导航卫星系统（GNSS）接收机的日志，逐历元运行信任度监测器，并说明接收机的定位何时、因何不再可信。它还可以对照你在运行之前声明的事件和预测为日志评分：每个事件是否被及时检测到，以及建模的载噪密度比（C/N0）下降是否与接收机的实测相符。

观测量来自接收机自身；监测器及其阈值来自引擎和你自己。每个结果都带有这一标注、日志的SHA-256，以及运行时所用的每个阈值，因此运行可以重复并接受审计。

对于航行中的船舶，带有实时评分以及可选的海图系统前置门限，请见MARITIME-TRUST.md。

运行#

kshana receiver-trust examples/receiver-trust/session.toml

这会在场景旁写出session.result.json、session.trust.csv（每个历元一行）和session.trust.svg（平均C/N0随时间的变化，下方为信任状态），并打印一行式的判定。示例日志是为展示格式而合成的；请将path指向你自己接收机的日志。

上图是MARITIME-TRUST.md的船舶演示：一份虚构的日志，一个咨询性（仅供参考）的评分。

同一场景可在Python（kshana.receiver_trust(toml)）、WebAssembly包（receiver_trust(toml)，日志内嵌）以及模型上下文协议（MCP）服务器的assess_receiver_log工具中运行。

可读取的日志#

这三种的详情、来源和限制：MACHINE-INPUTS.md。

读取器生成的每个历元还带有source_span、[start, end)输入字节偏移：即包含对其有贡献的各记录的最小连续范围，因此可对事件窗口的确切原始切片计算哈希。NMEA：该历元为当前历元期间读取的每一行（若有无关的行夹在其各语句之间，则为超集）。UBX：该历元的各帧。RINEX 3：从每个>行到下一行的历元记录。Android：该历元的Raw行（仅当某历元没有Raw行时才用Fix行）。对于实时流以及定义不明确之处（RINEX 2）则不存在。

文件通过path（相对于场景自身所在文件夹解析）传入，或以text或base64内嵌（浏览器中仅有这两种选择）。

作为第二传感器的IMU日志#

[log.imu]在同一时钟上加入惯性日志：

[log.imu]
format = "csv"          # or "euroc"
path = "imu.csv"        # or text / base64
heading0_deg = 90.0     # heading at the first IMU sample
yaw_axis_down = true    # body z down (NED/FRD); false for z up (ENU/FLU)
time_offset_s = 0.0     # added to the IMU clock to reach the log's t_s

偏航角速度由heading0_deg积分得到，并在接收机日志没有航向的地方填充航向，因此heading-course监测器（要求平台上设有heading_sensor = true）会将陀螺航向与对地航向作比较。陀螺会漂移：航向的好坏取决于积分窗口，而hdg_cog_tol_deg决定什么算作不一致。csv的布局记录在MACHINE-INPUTS.md中。IMU的字节是场景哈希以及证据包的场景哈希的一部分。内嵌（text／base64）适用于所有界面；不读取文件之处会拒绝path。

平台：静止或船舶#

上述监测器假定天线固定。场景在运行前于顶层[platform]表中声明平台；没有该表时，平台为static，一切不变。

[platform]
kind = "vessel"            # "static" (default) or "vessel"
max_speed_kn = 30.0        # default 30
max_accel_mps2 = 0.5       # default 0.5
max_turn_rate_dps = 6.0    # default 6
antenna_height_m = 18.0    # no default: without it the sea-level monitor does not run
heading_sensor = false     # true: the stream carries a gyro heading (HDT or THS)

在kind = "static"下，船舶键会被拒绝。对于船舶，position-jump监测器不运行，因为它测量的是与标定均值的距离，这对移动的天线并不正确；结果的monitor_config记录了所用的平台和限值。

由kshana nmea-scenario生成、为船员培训而制作的合成NMEA数据流，可被NMEA读取器接受，并可像任何NMEA日志一样用本类别运行。

监测器#

每个监测器都需要自己的数据；日志中没有其数据的监测器不会运行，也不会列在monitors_run中。前calibration_s秒（默认60）用于确立基线，绝不报警。

标定配置（需主动启用）。 [monitors] profile = "jammertest-2024-calibrated"以在公开的JammerTest 2024数据集上标定的值（每个场景一台u-blox ZED-F9P；Zenodo 15911589）替换这3个干扰阈值：cn0_drop_db = 1.5、agc_k_sigma = 3.5、jam_ind_threshold = 29。该标定已预先登记（xval/jammertest-trust/PREREGISTRATION.md），而该配置为MODELLED，仅在一次公开测评活动上拟合：其cn0_drop_db阈值未达到预先登记的保留集虚警判据（0.0231，判据为0.02）；AGC和压制干扰指示的判据以及联合判据（虚警0.033，检测率0.81）均已通过（xval/jammertest-trust/RESULTS.md）。它仅适用于该事件中的该接收机型号，是对照计划的攻击时段得出的，并且是在数据集的CSV日志上标定的（其UBX日志在两个文件夹上给出更多虚警）。使用该配置运行的结果会回显所应用的阈值，并带有一条说明上述全部内容的profile_note。不使用该配置时，适用上述默认值，所有输出均不变。

对于vessel平台，移动平台监测器也会运行（阈值位于顶层[maritime]表中，每个默认值均记录在src/receiver_trust/maritime.rs中）；每个监测器都需要其数据，且只有在作出判定时才列入monitors_run：

当RAIM、时钟监测器、求解失败或位置跳变报警，或C/N0下降达到其阈值的两倍时，历元为不可信；出现任何其他报警时为降级；其余情况为正常。

引擎路径（raim、solve-failure、clock）与tests/jammertest_spoof_oracle_support中的JammerTest 2024欺骗干扰参考基准（oracle）是同一计算：tests/receiver_trust_jammertest.rs检查在全部8个已发表的起始时刻上，首次报警都落在同一历元且类别相同。

信任度评分（船舶平台）#

对于船舶，标定之后的每个历元还会得到一个0至100的评分，以及评分不是100的原因。该映射是确定性的，并在对任何日志评分之前就已固定：没有学习，也没有对事件做任何拟合。每个监测器把其证据归约为一个比值statistic / threshold（比值为1或更高即报警）；一个比值会使评分扣减

points = weight * clamp((ratio - onset_ratio) / (full_ratio - onset_ratio), 0, 1)
score  = round_to_0.1( clamp(100 - sum of points, 0, 100) )

因此，监测器在低于其阈值的onset_ratio（默认0.5）时不扣分，在阈值处扣除其一半权重，在阈值的full_ratio倍（默认1.5）时扣除全部权重；评分对每个统计量都是非递增的。在某历元没有上报的来源，会在evidence_hold_s（默认10 s：即每5 s发送一次的C/N0语句的两个周期）内保留其最近的统计量，无论用于报警还是扣分均如此。

四舍五入取“半数进位”（floor(x * 10 + 0.5) / 10），分档依据取整后的评分，钳位在取整之前进行。扣分项中只列出点数大于零的监测器，附其比值和未取整的点数，点数大者在前；点数相同的扣分项按监测器名称cn0-drop、agc、jam-ind、loss-of-lock、position-jump、raim、clock、solve-failure、kinematic、heading-course、speed-log、sea-level、cn0-spread、cn0-rise、time-consistency、osnma、geometry的顺序列出。其检验结果为通过或失败的监测器（求解失败、认证失败）按比值1.5处理，即全额权重。所列点数是在0处钳位之前的点数。

[score]
nominal_min = 90.0         # score >= 90: nominal
degraded_min = 55.0        # 55 <= score < 90: degraded; below 55: untrusted
onset_ratio = 0.5
full_ratio = 1.5
evidence_hold_s = 10.0
[score.weights]            # overrides; a monitor not listed keeps its default
sea-level = 30.0

各分档的边界由权重推出：会报警的最轻监测器在其阈值处扣12.5点，因此任何报警都会使评分离开正常档；任何低于60点的单个监测器都不能单独使评分进入不可信档（多个监测器合在一起则可以）。结果记录了评分模型（score_model），每个历元带有score.deductions：哪些监测器扣了分、它们的比值及其点数。对于船舶，历元的状态即其评分所在的档。

几何：自然劣化，有别于类似攻击的不一致#

位于码头起重机旁、船闸中或高大船体下的接收机会丢失卫星，其定位变差，而原因并非攻击。自0.36起，依据几何设计说明（docs/design/2026-10-12-geometry-and-skyline-design.md，第4节），每个历元都带有其卫星几何，船舶评分设有几何监测器，每个扣分项都带有一个类别：geometry（天空）、environment（信号环境）或inconsistency（类似攻击的证据）。

几何从何而来。来自每颗被跟踪卫星的高度角和方位角（NMEA GSV、UBX NAV-SAT），再用引擎唯一的DOP内核（orbit::dop，已对照gnss_lib_py实现VALIDATED）推导出精度因子（DOP）：source = derived。若无此信息，则采用接收机自己给出的DOP和所用卫星数（NMEA GSA）：source = reported。天空位置和GSA在评分的evidence_hold_s（默认10 s）内有效，因为许多总线每隔几秒才发送一次GSV；某历元中不完整的GSV集（摘录的末尾、丢失的语句）不被使用。两者都没有的日志，例如只有GGA和RMC的NMEA，或目前的Android和RINEX日志，其状态为unknown，并附注“geometry unknown”：引擎不会猜测未曾给定的几何，且几何监测器不运行。

状态是描述性的，对评分起作用的是下文的标签：degraded包含仅供参考的sky-blocked情形，它可能伴随良好或一般的DOP，而只有poor标签才计入评分。

标签（始终报告，从不计分）。每个历元的geometry.label为good（HDOP不超过hdop_good 2，PDOP不超过pdop_good 3，且至少used_good 6颗卫星）、poor（HDOP高于hdop_max 4，PDOP高于pdop_max 6，或少于min_used 5颗卫星）、介于两者之间的fair，或unknown。历元的附注总是以标签和数值开头，例如“geometry fair: HDOP 1.105, PDOP 1.831, VDOP 1.410, 8 satellites; not scored (the score deducts only above HDOP 4, PDOP 6 or below 5 satellites)”，并在信号丢失成立时追加“, signal loss”。

几何监测器（船舶评分）。除非几何条件差，否则它不扣任何分：其比值为max(hdop / hdop_max, pdop / pdop_max, min_used / n_used)，在比值不超过1时（几何良好或一般，包括有8颗卫星的仅GPS开阔天空）不扣分，因此这样的日志评分与0.35完全相同。比值超过1后，扣分按线性斜坡上升，在full_ratio（阈值的1.5倍：HDOP 6，PDOP 9，3颗卫星）处达到cap_points（15）：比值1.25时（HDOP 5，或4颗卫星）扣7.5点，自1.5起扣15点（评分85，降级）。仅凭它自身，永远不会使评分低于floor（默认：评分的degraded_min，55），因此仅几何因素至多到达降级档，绝不会到达不可信档：生效的上限为min(cap_points, 100 - floor)，所以若[score]表提高了degraded_min（例如一个degraded_min为90的0.35表），上限会降为100 - degraded_min，而不会被拒绝；而把floor设得低于degraded_min则会被拒绝。该监测器不触发报警；当它在任一历元作出判定时（日志给出了几何的船舶），它被列在monitors_run的最后，并且不计入0.35的同一性；它不是[score.weights]的条目（设置会被拒绝），生效的上限和下限记录在geometry_model.cap_in_force和geometry_model.floor_in_force中。差历元的附注会说明原因，例如“geometry poor: HDOP 5.200, PDOP 7.900, VDOP 4.100, 7 satellites; degraded by geometry: HDOP 5.200 above 4 (derived from 7 logged satellites); not an inconsistency”。

类别。每个扣分项（score.deductions[].class）：

防范伪造的恶劣天空。欺骗者可能发送稀疏的GSV，或报告很高的HDOP，以换取容忍度。引擎只标注而不宽宥：不会因几何条件差而放宽任何其他检查，并且把接收机所报告的HDOP（保持期内的GSA，否则为GGA）与由其所报告的天空推导出的HDOP作比较。当二者相差超过max(reported_vs_derived_tol, reported_vs_derived_rel × derived HDOP)（1.0，或推导出的HDOP的25 %，取较大者）时，该历元带有reported_derived_mismatch: true，并且当几何条件差时，其扣分项归类为inconsistency。几何良好或一般时，这种不一致会被报告但不计分：除非几何条件差，否则不扣分。这是一项有意的选择（0.36）：“除非差，否则为零”对每个历元都成立，因此良好和一般的几何与0.35完全一样计分，而伪造的HDOP绝不会悄无声息。该标志（reported_derived_mismatch）出现在结果的每个历元和每条实时行中，附注写明“…beyond the tolerance: reported, not scored (the geometry is not poor)”或“…: the geometry deduction is classed an inconsistency”，geometry_summary.hdop_mismatch统计这类历元数，证据摘要页显示该计数，为零时也显示。这个25 % 是一项REPRESENTATIVE的工程选择，不是实测值或标准数值：对每个星座求解一个钟差的接收机，或只用其所跟踪卫星的一个子集（高度角掩模、C/N0截止、RAIM排除）的接收机，所报告的HDOP与全部被跟踪卫星的单钟HDOP相比会有差异，该差异随HDOP增大，因此单靠固定容差会把自然的恶劣几何误判为不一致。更大的差异则仍被视为不一致。归类为geometry的扣分项是对天空的陈述，而不是未发生攻击的结论。

信号丢失不等于天空条件差。当接收机列为可见（高于low_elev_deg）的卫星未被跟踪时，引擎还会推导所有可见卫星的DOP。若该可见DOP在阈值之内，且要么没有任何被跟踪卫星，要么未跟踪的卫星分布在整个地平线周围（并非局限于其中一半），则说明天空是有的而信号没有：该历元带有signal_loss: true，附注为“satellites in view but not tracked: signal environment, not geometry”，几何扣分项归类为environment。局限于地平线一半的未跟踪卫星仍被视为天空被遮挡（墙、悬崖、码头）。两侧遮挡（峡谷或狭窄的峡湾）在配置天际线之前被视为信号丢失。接收机的无定位哨兵值不是DOP：所报告的HDOP或PDOP为99或更大、GGA质量为0以及GSA模式为1，都表示没有给出DOP。

输出中变了什么，没变什么。除非几何条件差，否则没有任何评分发生变化；标签始终报告。追加的键：epochs[].geometry（status、reasons、source、n_used、hdop、pdop、取整到0.001的vdop、open_fraction（配置天际线之前为null）、max_azimuth_gap_deg、age_s、reported_hdop、reported_derived_mismatch、note、in_view（高于low_elev_deg所列的卫星）、signal_loss、label），每个扣分项上的class，以及末尾的geometry_model（阈值、保持期、生效的上限和下限、出处、类别规则）和geometry_summary（按状态、标签和扣分类别统计的历元，以及所报告HDOP不符的历元）；score_model.weights与0.35相同。有两项测试把这一点约束到“0.36 portable”基线的字节级一致（去掉这些键之后）（即0.35.0的哈希值，在引擎改用可移植数学运算时重新设定基线，并作为0.35.0发布内容的记录保存在测试中：docs/revisions/STUDIO15-portable-math-rebaseline.md）。tests/geometry_trust_no_change.rs约束两个示例会话的全部输出（结果JSON、CSV、SVG、判定、回放的实时行、$PKSHT、Prometheus、CEF、LEEF）。tests/geometry_corpus_identity.rs约束每个已提交的船舶NMEA语料的批处理结果、摘要、实时行和$PKSHT（演示和海事参考测试数据，各自也有8颗卫星的仅GPS开阔天空版本，以及由其随机种子生成的船员培训场景）；在两个因压制干扰而使几何条件变差的培训场景中，每个不差的历元完全相同，每个差的历元仅因几何扣分而不同。几何条件差的日志最多会损失15点在0.35中不会损失的点数；这是预期的变化。在演示中，拖离读作inconsistency；tests/geometry_trust.rs编辑日志以遮挡西侧天空（一般：加标签，不计分）、遮挡西侧天空并再遮挡两颗东侧卫星（差：几何扣分，因高仰角卫星也丢失而归为失锁environment）、只丢失低于15° 的卫星（失锁归为geometry），以及给出一个天空无法解释的HDOP（几何差扣分变为inconsistency）。这些阈值为MODELLED：是选定的，并未对任何日志拟合；这里的任何内容都不断言在真实数据上区分自然劣化与攻击的频率有多高。

声明事件和预测#

[[events]]
label = "jammer on"
kind = "jamming"            # jamming, spoofing or other
onset_s = 120.0             # seconds since the first epoch of the log
end_s = 240.0               # optional; otherwise onset_s + compare.horizon_s
predicted_cn0_drop_db = 12.0  # optional, e.g. from a `jamming` scenario's link budget

[compare]
detect_tol_s = 10.0         # an alarm this soon after onset counts as a detection
cn0_tol_db = 3.0            # predicted and observed drops agree within this

对每个事件，结果给出标定与起始之间的虚警、首次报警及其监测器、延迟、结局（detected、late、missed或not-evaluable），以及观测到的C/N0下降中位数与预测的对比（agree、disagree、no-prediction或not-evaluable）。不一致会被如实报告，绝不会被调参抹去：容差在场景中，而场景在结果的哈希中。

这并未声称的内容#

信任度监测器为MODELLED：其阈值是输入，其在真实干扰上的检测性能由事件评分来衡量，而不是本类别所能断言的。在JammerTest 2024的欺骗干扰会话上，引擎路径监测器在10 s内捕获了一些起始时刻，对另一些则迟到；具体数值见VERIFICATION-MATRIX.md中“Clock-aided χ², RAIM, AGC, SQM fused per-epoch security FoM”一行。与一份日志相符的预测只是一个数据点，不是验证。