CPD真正的量产门槛不是检测而是告警升级状态机

CPD 真正的量产门槛，不是检测，而是告警升级状态机

发布时间： 2026-03-25
主题： CPD / Euro NCAP 2026 / parked-vehicle safety / 告警升级 / 状态机
关键词： child presence detection、warning escalation、notification、intervention、state machine、parked vehicle

一句话结论

很多团队做 CPD 时，第一反应是：

  • 能不能检测到孩子
  • 呼吸能不能测出来
  • 雷达还是摄像头更准

这些当然重要。

但如果把 Euro NCAP 2026 的要求认真拆开看，会发现一件更关键的事：

CPD 真正进入量产后，最难的不只是“检测到”，而是“检测到之后如何持续、正确、分级、可验证地把警报送到能采取行动的人”。

也就是说，CPD 在工程上更像：

  • 一个 停车态安全状态机
  • 而不是一个孤立 detector

检测只是入口；
真正决定系统成败的，是：

  • 何时首报
  • 如何延迟/取消
  • 何时升级
  • 如何循环提醒
  • 哪些外部通道要联动
  • 何时触发干预动作

1. Euro NCAP 2026 实际上在考什么

根据围绕 2026 协议的公开解读，CPD 现在不再只是“发现车里有小孩”这么简单，而是要求系统覆盖完整链路：

1.1 检测场景更完整

至少要覆盖：

  • 锁车后 车内遗留儿童
  • 未锁车但儿童进入后被困 的场景

这意味着系统不能只围绕“成年人下车忘孩子”这一种脚本设计。

1.2 检测范围更完整

需要覆盖：

  • 所有座位
  • 可选/可拆卸座位
  • 脚坑
  • 驾驶员位
  • 行李舱一般不算

这意味着 CPD 不是一个“后排提醒小功能”，而是完整的舱内空间覆盖问题。

1.3 时间要求非常具体

公开解读里提到的关键时序包括：

  • 锁车后检测到儿童：15 秒内开始警告
  • 未锁车但门关闭后检测到儿童：10 分钟内发出警告
  • 首次警告结束或被取消后，如仍持续存在：90 秒内进入升级告警
  • 升级告警：至少 20 分钟、每分钟重复一次、每次至少 15 秒

请注意，这已经不是“有个提示音就行”，而是清晰的 状态机时序规范。

1.4 告警通道更丰富

不仅车内/车外声光，公开解读还提到：

  • 车钥匙反馈
  • 手机 App 通知
  • connected service
  • 第三方联系人

这说明 CPD 的目标不是“车自己知道”，而是：

确保警报能抵达真正能干预的人。

1.5 满分还要求干预动作

要拿到更完整得分，系统不应只检测 + 警报，
还应考虑：

  • 开空调
  • 解锁车门
  • 远程通知照护者
  • 高温危险时立即响应

这已经明显超出了传统 detector 的边界。

2. 为什么这会把 CPD 从“感知问题”升级成“系统问题”

2.1 因为误报/漏报不再只影响算法指标，而会直接影响用户信任

如果系统：

  • 经常误报
  • 提醒过早/过晚
  • 升级逻辑混乱
  • 无法正确取消

用户很快就会：

  • 忽略它
  • 关闭相关联动
  • 对通知麻木

所以 CPD 的难点不是只把 recall 做高，
而是让 整个告警链路在真实使用中不失真、不扰民、不失效。

2.2 因为“谁来接警”本身就是架构问题

CPD 和很多车内功能不同。

DMS 多数时候提醒的是车内驾驶员本人；
而 CPD 的关键时刻，车里可能已经没人了。

所以系统必须回答：

  • 谁是第一接警对象？
  • 车外附近的人能否感知？
  • 手机是否是主要链路？
  • 网络断了怎么办？
  • 车钥匙是否可作为低依赖通道？

这就是一个典型的 多通道路由与升级策略 问题。

2.3 因为干预动作会牵涉功能安全与责任边界

比如：

  • 何时自动解锁？
  • 高温阈值怎么设？
  • 开空调多久？
  • 误报时是否会造成新的风险？

这些都说明，CPD 已经不只是 sensing feature，而是跨越：

  • 感知
  • HMI
  • 车身控制
  • 连接服务
  • 法规验证

的系统工程问题。

3. 更合理的工程拆法：把 CPD 设计成 6 态状态机

我更建议把 CPD 理解成下面这类状态机，而不是一个布尔检测器：

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

S0：Trip Active

  • 正常行车或停车准备中
  • 系统准备进入 parked-state watch

S1：Vehicle-Off Low-Power Watch

  • 熄火/锁车后进入低功耗监护
  • 依赖 UWB / radar / 低功耗传感常开
  • 维持基础存在检测

S2：Presence Suspicion

  • 检测到疑似儿童/生命体征/持续微动
  • 进入二阶段确认
  • 防止单次噪声直接触发告警

S3：Initial Warning

  • 在协议要求时间窗内发出首报
  • 声光对车外可见
  • 允许一次明确延迟/取消操作

S4：Escalation Loop

  • 若存在持续，进入重复升级
  • 每分钟循环一次
  • 至少持续一段规定时间
  • 车内/车外/钥匙/App 多通道同步

S5：Intervention / Remote Notification

  • 触发空调、解锁、远程通知
  • 在高温或高风险情境下加速执行

这个拆法的好处是：

  • 感知团队知道自己输出什么
  • 平台团队知道何时切换功耗状态
  • HMI 团队知道哪些消息在哪个态触发
  • 验证团队可以逐态建立测试用例

4. 对 IMS/OMS 开发最直接的启示

4.1 不要把 CPD 设计成“检测到就报警”

中间至少要有：

  • suspicion
  • confirmation
  • debounce / hysteresis
  • cancel / snooze rule
  • escalation scheduler

否则误报和用户骚扰会非常难控。

4.2 通知系统必须作为一等模块设计

CPD 的通知链路不该是后补的。

建议至少拆成：

  • local external alert：灯光/喇叭/车外可感知提示
  • owner channel：App / 车钥匙 / 远程推送
  • service channel：connected service / 后台记录
  • intervention channel：空调 / 解锁 / 温控策略

4.3 “允许一次延迟”会显著提高状态机复杂度

一旦协议允许：

  • 明确延迟一次
  • 然后 90 秒内继续升级

那系统就必须严谨处理：

  • 谁触发的延迟
  • 延迟持续多久
  • 何时恢复升级链路
  • 延迟期间如何监测高温突变

这是纯 detector 思维很容易漏掉的地方。

4.4 高温风险应该作为并行加速器，而不是普通条件

公开解读提到：

  • 若温度达到危险水平，应立即响应

这说明状态机里不能只有“按固定时间表升级”，
还要有一条并行风险支路：

  • 温度上升过快
  • 高温阈值越过
  • 生命体征异常削弱

这些事件可以直接推动状态跳转。

5. 一个更现实的量产策略：分层构建，而不是一步到位

第一层：先把 detection + initial warning 做稳

这是最基础合规层。

第二层：补 escalation scheduler

解决持续提醒、重复频率、取消/延迟恢复等逻辑。

第三层：补 remote notification

把人找回来，而不是只在车旁边喊。

第四层：补 intervention

包括：

  • 解锁
  • 空调
  • 远程升级链路

第五层：做高温/风险上下文加速

让系统从“定时器逻辑”升级成“风险驱动状态机”。

这样做的好处是：

  • 可以逐层量产
  • 可以逐层验证
  • 也更适合不同配置车型分级落地

6. 我对技术路线的判断

如果说前几年的 CPD 竞争重点是：

  • 用什么传感器
  • 检测能力谁更强

那么 2026 往后，竞争重点会逐步迁移到：

谁能把检测、提醒、升级、干预、连接服务做成一条真正可验证、可量产的停车态安全链路。

所以我会把优先级这样排：

  1. 可靠 direct sensing
  2. 低功耗 parked-state watch
  3. 告警升级状态机
  4. 多通道通知
  5. 干预动作与风险加速逻辑

其中第 3 和第 4 项，往往比大家直觉里更决定量产成败。

7. 对 TrendRadar 的下一轮搜索建议

下一轮更值得关注的关键词：

  • CPD warning escalation state machine
  • child presence detection remote notification architecture
  • parked vehicle safety intervention climate unlock
  • second-stage confirmation CPD alert policy
  • connected services child presence detection automotive

配图建议

  1. Euro NCAP 2026 CPD 时间轴图（自绘）

    • 15s / 10min / 90s / every minute / 20min

  2. CPD 六态状态机图（自绘）

  3. 多通道通知链路图（自绘）

    • 车外声光 / 钥匙 / App / 云服务 / 干预控制

参考资料

结语

如果把 CPD 只理解成“探测有没有孩子”，
那只完成了最前面的 20%。

真正决定它能不能拿高分、能不能量产、能不能在真实事故里发挥作用的，
其实是后面的 80%：

告警升级、通知路由、干预时机，以及这一切背后的状态机设计。

Euro NCAP > CPD
#Euro NCAP 2026 #CPD #告警升级 #状态机 #parked-vehicle safety
CPD真正的量产门槛不是检测而是告警升级状态机
https://dapalm.com/2026/03/25/2026-03-25-CPD真正的量产门槛不是检测而是告警升级状态机/
作者
Mars
发布于
2026年3月25日
许可协议