车载信号为什么会说谎：TTL、源时间与 500 ms 新鲜度阈值

一个显示错误的仪表，比一个不显示的仪表更危险。车载小仪表最常见的问题不是传感器失效，而是失效之后屏幕仍保留着上一次的有效数字——用户以为自己在看实时车速，实际看的是 3 秒前的残值。统一信号服务（Unified Signal Service）的 TTL 模型就是为消除这类误判而设计的。

过期数据为什么比没有数据更有害？

因为「看起来正常」会关闭人的怀疑。在我们的原型规范里，网关失联时车速与转速必须同时变为「–」，不允许回退到 GPS 速度冒充 OBD 速度；胎压接收器缺失时显示「–」与无数据状态，绝不显示默认的「正常」。这条规则背后的判断是：缺失状态是可操作的信息，伪造的正常值不是。

一个信号要带哪些字段才算可信？

至少要有命名空间、设备稳定 ID、指标定义、单位、数据类型、量程、源采样时间、接收时间、序号、质量状态、过期阈值、精度或置信信息、估算标记与隐私等级。缺任何一项都无法在跨设备融合时判断该值是否可用。

需要特别区分的语义差异包括：GPS 对地速度与车辆轮速、海拔相对平均海平面与椭球高、磁航向与真航向、轮胎表压与绝对压力、手表当前心率与最近一次历史同步值。正式适配器必须在语义层标注这些差异，不能靠显示名称区分。

显示刷新 30 次，等于收到 30 个独立样本吗？

不等于，这是最容易被混淆的一点。以 25 Hz GPS 为例，它对应 40 ms 的解算周期，适合保留原始样本供统计，但界面每秒重绘 30 次并不代表接收到 30 个独立定位样本。采样频率、传输频率、模型消费频率和显示频率必须分别记录。

同样需要警惕的是「宣称的 25 Hz」：模块必须真实支持指定的导航速率，输出速率不等于独立解算率。重复发送旧坐标、插值动画或手机补帧都不能宣称为 25 Hz 实测。

时间不同步时，跨信号判断还能做吗？

要分情况。源时钟、主机时钟与 UTC 三者分开管理；跨设备融合先估计时间偏移与漂移，必要时利用 PPS（秒脉冲）。没有同步条件时只能并排显示并在分析中明确误差，跨信号提醒不能把不同时间的样本当作严格同时测量。

这条限制直接影响组合告警的设计。例如在 上海国际赛车场 的长直道上，把「车速超过 200 km/h」与「胎压低于阈值」组合成一条告警，就必须确认两个样本的时间差在可接受范围内，否则结论不成立。我们的 SR-Telemetry 实时遥测云 把推送延迟控制在 500 ms 以内，正是为了让这类组合判断有可核算的时间基准；SR-RaceBox 车载数据采集器 则以 IMU 50 Hz、GPS 20 Hz 同步记录，为事后分析保留原始时间线。

FAQ

为什么胎压的 TTL 是 65 秒这么长？

因为胎压广播发送间隔可能从秒级到分钟级，静止与运动状态也可能不同。TTL 必须来自设备实际行为，不能对所有传感器套用演示里的 1 Hz。

数据过期后应该立刻清空显示吗？

应该标记无效而不是保留旧值。某一数据源失联只清空依赖它的指标，其余在线数据仍可显示；失联指标显示明确状态，不沿用上一次的有效样式。

500 ms 是精度保证吗？

不是。它是原型设定的新鲜度阈值，属于工程上的保守取值，正式版本需按链路实测制定，建议先评估 150–500 ms 区间。

换了一个同型号传感器，绑定还能沿用吗？

不能。设备替换后必须重新确认稳定 ID 与数据绑定，禁止仅按名称接管旧设备的信号。

参考资料

• 项目 05 —— D:/Backup/Documents/开发板侧端模型/LINK端侧传感器软件设计说明.md（V0.1，2026-09-13，第 5–6 节）
• 项目 05 —— EdgeForge自编译软件框架方案.md（V1.4，第 5.3 节设备能力清单）
• 项目 04 —— research/ui-screen-specs.md（数据源与失联规则）

更新记录

首次发布 2026-10-11 最近核对：2026-10-11