车内感知正在需要Power-Aware Safety State Machine而不只是感知模型

前言

这一晚连续写了多篇 CPD / UWB / parked-mode 相关文章后，一个更上层的结构性判断越来越清楚：

车内感知系统接下来真正需要的，不只是更强的 perception model，而是一个 Power-Aware Safety State Machine。

原因很简单。现在越来越多 IMS 功能已经不再停留在“感知一下然后报个结果”，而是要同时处理：

• 停车态与行驶态切换
• 低功耗与 always-on 的冲突
• 证据弱时的保持/复查
• 高温或风险升级时的资源拉起
• 多模态融合与冲突仲裁
• 干预动作与通知路由

这些都不是模型能单独解决的，它们需要状态机层来统一治理。

一、为什么感知模型已经不够解释系统行为

1.1 模型回答“看到了什么”，系统还要回答“现在该怎么运行”

一个模型可以输出：

• 有无 child presence
• 有无微动
• 置信度多高
• 相机语义是否完整

但系统还必须继续做决定：

• 现在是低功耗巡航还是高精度确认？
• 证据中断后是立即回退还是先 hold-safe-state？
• parked mode 下是否唤醒更多计算资源？
• 高温是否覆盖原本的 delay/snooze 逻辑？
• 通知链是否需要升级？

这些都不是 perception score 本身能给出来的。

1.2 量产问题越来越像运行时编排问题

从 CPD、认知分心、impairment detection 到 adaptive restraint，这一晚反复出现同一个模式：

• 真正难点从 detect 转到 act
• 从单次分类转到持续状态治理
• 从感知精度转到动作正确性与解释性

换句话说，runtime orchestration 正在取代单点识别，成为更稀缺的能力。

二、为什么要把 power-aware 和 safety 绑在一起

2.1 低功耗不再只是平台优化，而是安全行为的一部分

过去平台做功耗，很多时候是系统优化问题；但在 parked-mode CPD 场景里，功耗策略会直接影响安全结果：

• 采样太稀 → 容易错过持续存在证据
• 唤醒太慢 → 错过首报或升级窗口
• 过早休眠 → 破坏 alert cadence
• 资源拉起不稳 → 干预链路失效

所以功耗策略本身已经变成安全策略的一部分。

2.2 安全状态如果不理解电源状态，就会变成空想

同样地，纯安全状态机如果不理解底层电源域、采样周期、唤醒时延，也只是纸上设计。真正可落地的状态机必须同时知道：

• 车处于哪个 power domain
• 当前 sensing duty cycle 是多少
• 哪些模块能常驻、哪些要按需唤醒
• 哪条路径最省电但仍可满足安全时序

这就是为什么我认为下一阶段需要的不是单纯 safety state machine，而是 power-aware safety state machine。

三、这个状态机至少应该长什么样

3.1 推荐的分层思路

更合理的架构不是把所有逻辑搅在一起，而是至少分成三层：

1. Evidence Layer

   • 传感器证据
   • 质量状态
   • 冲突状态
   • confidence / false-positive risk

2. Power-Aware Runtime Layer

   • parked_mode_state
   • sensing_duty_cycle
   • wake_trigger_policy
   • resource escalation / rollback

3. Safety Action Layer

   • warning scheduler
   • escalation policy
   • intervention executor
   • notification routing
   • traceability

这样做的好处是：

• 感知演进不会频繁打碎功耗与动作逻辑
• 平台团队和算法团队能在清晰接口上协作
• 回归测试也更容易分层定位

3.2 CPD 场景下的典型状态

以 CPD 为例，一个更完整的状态机至少可能包括：

• sleep_cruise
• low_power_monitoring
• suspected_presence
• high_fidelity_confirmation
• confirmed_presence
• warning_active
• escalation_active
• temperature_override
• intervention_active
• recovery_or_fallback

每个状态都需要同时绑定：

• power policy
• sensing fidelity
• allowed transitions
• timeout / persistence
• trace requirements

四、为什么这会成为车内感知平台的新护城河

4.1 团队之间真正拉不开差距的不是单个模型，而是系统行为稳定性

模型可以很快被追平，但真正难复制的是：

• parked mode 下何时升、何时降
• 证据间断时如何不抖动
• 模态冲突时如何保守决策
• 高风险时如何及时拉起资源与动作
• OTA 之后如何不破坏旧有时序

这些全都依赖状态机设计与验证资产，而不是单个网络结构。

4.2 状态机一旦做对，会带来平台复用红利

如果 Power-Aware Safety State Machine 做成平台能力，它就不只服务 CPD，还能服务：

• impairment detection
• occupant monitoring
• sudden sickness / vital signs
• adaptive restraint preconditions
• future unified in-cabin intervention

这意味着未来最值钱的，不一定是某个单 feature，而是 统一运行时控制底座。

五、对 IMS 开发的直接启示

5.1 先把正式状态和事件定义清楚

建议先把下面这些对象正式化：

• power_domain_state
• monitoring_mode
• evidence_confidence
• conflict_state
• risk_level
• resource_escalation_state
• action_state

以及关键事件：

• weak_evidence_detected
• evidence_reconfirmed
• temperature_override_triggered
• power_budget_limited
• wake_path_failed
• intervention_completed

5.2 把验证从 perception benchmark 升级到 runtime regression

真正该测的不只是算法输出，而是：

• 状态转移是否正确
• 转移时间是否满足要求
• 不同 power mode 下行为是否一致
• 资源回退是否安全
• OTA 后状态机是否回归稳定

5.3 ownership 也必须跟着重画

如果状态机既含 power 又含 safety，那 ownership 不能再只归某一侧。至少要明确：

• 平台 / 电源管理
• 传感器与算法
• safety policy
• HMI / notification
• validation / service

否则最后很容易出现“每一块都有人负责，但整个系统没人真正负责”的问题。

总结

车内感知系统接下来的关键升级，不只是更强的感知模型，而是形成一个真正可量产的 Power-Aware Safety State Machine。

它之所以重要，是因为未来的关键问题几乎都发生在模型之外：

• 什么时候监测
• 监测多频还是低频
• 什么时候升级资源
• 什么时候触发动作
• 风险变化时怎么覆盖默认策略
• 功耗受限时怎么依然守住安全底线

谁先把这套状态机做成平台能力，谁就更可能在下一阶段的 IMS / CPD / UWB 量产竞争里形成真正的系统护城河。

---

参考来源

• CEVA, Robust In-Cabin Vital Signs Monitoring Using UWB Radar, 2026
• CEVA, Ceva Unveils UWB Radar for Automotive Child Safety Detection, 2023
• Anyverse, Euro NCAP 2026 In-Cabin Monitoring: OEM Guidelines to Readiness, 2025