停车态低功耗与Always-On能力正在成为UWB-CPD量产落地的真正门槛

前言

前一篇已经把 UWB Digital Key 硬件复用写成了 CPD 的软件定义部署机会。但如果继续往量产条件里深挖，会发现真正难点还没结束。

UWB-CPD 能不能真正落地，关键不只在“这套硬件能不能做检测”，而在 停车态低功耗 + always-on 监测 + 模式切换策略 能不能被工程化实现。

这条线之所以重要，是因为 CPD 的核心价值恰好发生在：

• 车已经停下
• 乘员可能已离开
• 车辆进入低功耗状态
• 但系统又必须继续看、继续等、继续能升级动作

这正好把平台功耗策略推到台前。

一、为什么 parked mode 是 CPD 真正的主战场

1.1 行驶中能看，不代表停车后还能看

很多感知功能默认依赖“车已经唤醒、算力在线、供电宽松”。但 CPD 不一样，它最关键的时间段往往发生在：

• 驾驶结束之后
• ECU 逐步休眠之后
• 车内只剩低功耗域仍在工作时

这意味着如果系统只在正常点火/高功耗模式下工作，那它恰恰会错过最需要它的时刻。

1.2 parked-mode always-on 不是锦上添花，而是功能定义本身

公开白皮书反复强调 UWB 复用路线的一个核心卖点：

• always-on capability even in low-power parked modes

这其实不是宣传点，而是 CPD 能否成立的前提。因为：

• 没有 always-on，就无法持续确认 child presence 是否仍在
• 没有低功耗监测，就无法承受长期待机成本
• 没有 parked-mode 策略，就无法稳定触发后续 warning / escalation / intervention

二、低功耗与安全连续性为什么天然冲突

2.1 功耗策略倾向“尽快睡”，CPD 倾向“必须醒着”

车辆平台做低功耗时，天然目标通常是：

• 尽快关更多域
• 减少 RF / compute / memory 活动
• 尽量避免长时间持续采样

但 CPD 的目标几乎正相反：

• 关键停车阶段要持续存在感知
• 还要能做微动检测
• 还要在温度风险变化时立即响应
• 还要支持外部通知或车内联动

所以 CPD 和低功耗策略之间天然就存在张力。

2.2 真正难点是“怎么持续地省着看”

量产里最难的不是二选一，而是找到中间层：

• 哪个域必须常开
• 哪个域可以事件驱动唤醒
• 采样频率如何分级
• 什么时候可以低分辨巡航，什么时候必须切高精度确认
• warning / escalation 触发时系统如何快速拉起更多能力

这说明 parked-mode CPD 真正需要的是 power-aware state machine。

三、UWB 为什么比“新增专用传感器”更有机会把这件事做成

3.1 既有硬件复用意味着更容易进低功耗主架构

如果 CPD 靠新增独立硬件，通常要重新争取：

• 停车态供电
• 唤醒链路
• 平台接口
• 功耗预算

而如果复用的是已经为了 Digital Key 存在的 UWB 基础设施，那么它天然更容易进入：

• parked-mode 域
• secure ranging 相关低功耗策略
• 现有 mode management 架构

这也是为什么 UWB 复用路线的价值不只是降本，更是 更容易接进平台原生低功耗体系。

3.2 软件定义能力让分级监测成为可能

如果同一套 UWB 基础设施既能做 ranging，又能做 radar sensing，那么就有机会设计：

• 低占空比巡航监测
• 条件触发增强采样
• 风险升高后提升 sensing fidelity
• escalation 阶段临时拉起更多 compute / notification 能力

这比“固定一直高功耗扫描”要更符合量产逻辑。

四、对平台团队的直接启示

4.1 必须先定义 parked-mode power policy，而不是事后补丁

CPD 项目里最容易犯的错，是先把检测链做出来，再让平台团队“想办法省电”。这种顺序通常会导致：

• 算法假设和实际电源策略冲突
• 采样连续性被打断
• 升级动作延迟不可控
• debug 极其困难

更合理的做法是从一开始就正式定义：

• parked_mode_state
• sensing_duty_cycle
• wake_trigger_policy
• escalation_power_budget
• notification_power_path

4.2 mode management 必须和 CPD 状态机绑在一起

如果 UWB 同时承载 Digital Key 和 CPD，那么 mode management 不能只是硬件驱动层逻辑，而要和安全状态机联动：

• 正常停车 → 低功耗巡航
• 检测到可疑微动 → 提升采样与确认级别
• 确认 child presence → 拉起 warning / scheduler / routing
• 高温或升级阶段 → 进入高优先保障模式

这本质上已经不是传感器配置，而是平台级状态机协同。

4.3 验证必须把功耗和安全动作一起测

以后测 UWB-CPD，不能只看 detect accuracy，还要测：

• parked mode 下功耗曲线
• wake-up latency
• sensing 断续是否影响 persistence 判断
• escalation 时是否能及时拉起高功耗路径
• OTA 后 parked-mode 策略是否退化

也就是说，验证对象应升级为：

• safety × power × timing 联合验证

五、我更看好的技术路线

短期内更现实的路线不是“永远高精度常开”，而是：

1. 低功耗巡航层：保持存在性粗检测
2. 确认层：在可疑事件下提升分辨率与采样强度
3. 干预层：在确认后拉起 warning、notification、temperature override 所需链路
4. 回退层：风险解除后重新降回低功耗状态

这个架构的好处是，它把：

• 功耗
• 安全连续性
• 平台资源调度

统一进一个工程框架里。

六、下一轮值得继续追的关键词

基于这轮研究，后续更值得追的不是泛泛的 UWB 方案，而是：

• parked mode wake policy child presence detection
• always-on sensing low power vehicle safety architecture
• UWB radar duty cycle strategy CPD
• dual-use digital key radar mode management
• power-aware safety state machine in-cabin sensing

总结

UWB-CPD 的真正量产门槛，正在从“能否复用硬件”进一步推进到“能否在 parked mode 下持续、安全、低功耗地工作”。

这意味着接下来真正决定成败的，不只是雷达算法本身，而是：

• parked-mode power policy
• always-on duty-cycle strategy
• wake trigger design
• mode management
• safety × power × timing 联合验证

谁先把这套机制做实，谁更有可能把 UWB-CPD 从可行性概念，推进成真正可量产的平台能力。

---

参考来源

• CEVA, Robust In-Cabin Vital Signs Monitoring Using UWB Radar, 2026
• CEVA, Ceva Unveils UWB Radar for Automotive Child Safety Detection, 2023