停车态安全总架构-从UWB常开筛查到CPD干预闭环

停车态安全总架构：从 UWB 常开筛查到 CPD 干预闭环

发布时间： 2026-03-26
主题： 停车态安全 / CPD / UWB / 远程通知 / 干预闭环
关键词： parked-state safety、UWB always-on、child presence detection、warning escalation、remote notification、intervention

一句话结论

如果把 CPD 只理解成“检测车里有没有孩子”，那只完成了问题的前半段。

更完整、也更接近量产现实的视角是：

CPD 应被重构为一条停车态安全闭环，而不是单一检测功能。

这条闭环至少应包括：

  1. 低功耗常开筛查
  2. 二阶段确认
  3. 分级告警升级
  4. 远程通知路由
  5. 主动干预动作

而当前最有现实感的一条架构路线，是：

UWB / 雷达常开筛查 + Camera 二阶段确认 + 状态机驱动的告警/通知/干预闭环

1. 为什么要从“检测功能”升级为“停车态安全架构”

停车态和行车态完全不是一类系统问题。

停车态有三个非常现实的约束：

  • 车里可能没人，无法依赖驾驶员作为第一响应者
  • 系统要常开，但功耗必须极低
  • 即便检测到了，也必须把告警送到真正能干预的人

这意味着 CPD 的真正难点不只在感知，而在完整链路：

  • 低功耗 watch
  • 正确首报
  • 重复升级
  • 远程通知
  • 干预收口

所以更合理的定义是：

停车态安全 = 感知 + 状态机 + 路由 + 干预

2. 为什么 UWB 常开筛查是很强的起点

从过去一年的产业信号看，UWB 越来越值得关注的价值不是 access，而是：

  • 已量产于 digital key 场景
  • 低功耗常开更现实
  • 可探测微动 / 呼吸 / 生命体征
  • 不依赖光照
  • 可作为软件定义雷达复用

这使它非常适合承担 停车态第一层哨兵 的角色。

第一层：Always-on Watch

职责：

  • 在车辆熄火后持续低功耗监测
  • 发现疑似存在、微动、呼吸等直接信号
  • 过滤明显无风险状态

这一层的目标不是做最强语义识别，而是：

  • 稳定
  • 省电
  • 不漏高风险

3. 为什么必须有二阶段确认

停车态安全最怕两个极端：

  • 漏报：真的有儿童却没进入告警
  • 误报：经常把无害物体或噪声当风险，导致用户麻木

因此一个工程上更稳妥的路线是：

第二层：Second-stage Confirmation

当 always-on watch 发现疑似存在后，再拉起高信息量模态：

  • Camera / IR
  • Cabin light
  • 其他高算力确认模态

这一层负责：

  • 区分儿童/乘员/物体
  • 判断座位位置或空间位置
  • 为通知/留痕提供更清晰证据
  • 显著降低误报成本

所以架构不应该是“所有传感器一直全开”，而应是：

低功耗筛查和高信息量确认分层运行。

4. 告警升级不是附属功能，而是主链路

Euro NCAP 2026 对 CPD 的公开要求已经说明：

  • 锁车后 15 秒内首报
  • 未锁车 10 分钟内首报
  • 延迟/取消后，若风险持续，90 秒内升级
  • 每分钟重复告警至少 20 分钟
  • 车外可感知
  • 可加入 App、钥匙、connected services

这本质上要求系统必须拥有完整 告警升级调度器。

第三层：Escalation Scheduler

职责：

  • 管理首报时间窗
  • 管理一次延迟/取消规则
  • 管理重复频率与持续时长
  • 根据温度/风险动态加速升级

在这一层，系统的重点不再是“看见了没有”，而是：

  • 什么时候报
  • 报给谁
  • 报多久
  • 什么时候升级成更强动作

5. 远程通知为什么必须单独设计

CPD 和 DMS 的一个根本差异是：

  • DMS 多数时候提醒车内驾驶员
  • CPD 的高风险场景里，车内很可能已经没人

所以远程通知不是锦上添花，而是核心链路。

第四层：Notification Routing

建议最少拆成四条通道：

  1. 车外本地提醒：喇叭、灯光、车窗/车内可见文字
  2. owner channel：手机 App、车钥匙反馈
  3. service channel：connected services / 云端记录
  4. third-party channel：照护者、紧急联系人（若策略允许）

系统设计要回答：

  • 哪条是默认通道？
  • 网络失效时如何兜底？
  • 钥匙离得近时是否优先？
  • 哪些场景必须多通道并发？

这其实已经是消息路由系统，而不是简单 HMI。

6. 干预动作才是闭环真正闭合的地方

只有检测和提醒，系统仍可能止步于“知道有问题”。

要真正向高分和高价值靠拢，必须把动作做实。

第五层：Intervention Layer

可选动作包括：

  • 开启空调/通风
  • 解锁车门
  • 提高外部提醒强度
  • 触发更高优先级远程通知

干预层的设计原则是：

  • 以风险为中心，而不是以功能为中心
  • 高温、长时间无响应、生命体征异常都应影响动作升级
  • 误报代价要被纳入策略

7. 推荐的六态状态机

一个比较实用的抽象是：

1
2
3
4
5
6
S0 Trip Active
S1 Parked Low-Power Watch
S2 Presence Suspicion
S3 Initial Warning
S4 Escalation Loop
S5 Intervention / Remote Assistance

状态跳转关键事件

  • ignition off / lock / door close
  • UWB/radar suspicious presence
  • camera confirmation success/fail
  • initial warning timeout
  • user snooze / cancel
  • temperature hazard
  • no-response timeout

有了这套状态机，团队才能把：

  • 感知
  • HMI
  • 云通知
  • 空调/车门控制
  • 验证测试

统一到一张图上。

8. 对 IMS 开发最直接的优先级建议

P0：把 CPD 从 detector 需求改写成 parked-state state machine 需求

P0：建立 always-on watch 与 second-stage confirmation 的分层架构

P1：建设 escalation scheduler 与 notification routing

P1：把高温/长时间未响应作为风险并行支路

P2：把 intervention 接入空调、门锁、远程通知策略

9. 最后判断

未来停车态安全的竞争重点，未必是谁的单点检测论文指标更高，
而更可能是谁先把下面这条链路做顺：

低功耗常开 → 可靠确认 → 分级升级 → 远程通知 → 风险干预

这才是真正像产品、像量产系统的 CPD。

参考资料

Euro NCAP > DMS
#DMS #OMS #CPD #Euro NCAP 2026
停车态安全总架构-从UWB常开筛查到CPD干预闭环
https://dapalm.com/2026/03/26/2026-03-26-停车态安全总架构-从UWB常开筛查到CPD干预闭环/
作者
Mars
发布于
2026年3月26日
许可协议