CPD真正的分水岭正在从能否检测儿童转向温度覆盖与升级调度控制面

前言

昨天刚把 CPD 的主线梳理成“雷达+相机融合 + 动态验证资产”，继续往下看后，我更确定另一个判断：

CPD 真正的分水岭，正在从“有没有检测到儿童”转向“系统能不能把检测结果变成按时、按级、按风险变化运行的升级调度控制面”。

这件事很关键，因为很多团队把 CPD 仍然当作一个 detector feature。但从 Euro NCAP 2026 的公开要求看，它其实已经更像一个 停车态安全状态机。

一、为什么说 CPD 已经不是单纯检测功能

1.1 协议关心的不只是 detect，还关心 react

公开解读已经把时间要求说得非常明确：

• 车辆锁车后检测到儿童，15 秒内必须开始 warning
• 车辆未锁但车门关闭后，10 分钟内必须 warning
• 初次 warning 结束或被取消后，若儿童仍存在，90 秒内必须进入 escalation
• escalation 必须 每分钟重复一次，至少持续 20 分钟
• 若舱内温度到达危险水平，系统需要 立即响应

这意味着 CPD 的考核对象不是“识别是否存在”这么简单，而是：

• 首报时机
• 重复节奏
• 延迟逻辑
• 取消后的再次升级
• 高温条件下的 override
• 多通道告警是否真的能触达干预者

1.2 这本质上已经是 scheduler 问题

如果把这些要求翻译成工程语言，CPD 至少需要以下模块：

• presence state machine
• warning scheduler
• escalation scheduler
• temperature override
• notification router
• intervention executor

所以真正难点已经不是模型推理，而是：

检测结果如何进入一个可靠、可回放、可审计的控制面。

二、高温覆盖为什么会成为系统分水岭

2.1 高温不是普通条件，而是风险加速器

很多系统设计默认是线性时间逻辑：

• 检测到儿童
• 等一会儿
• 提醒
• 再等一会儿
• 升级

但高温场景打破了这个线性顺序。因为风险不是均匀增长，而可能突然加速。

也就是说：

• 在常规场景下，系统可以按默认节奏运行
• 一旦温度进入危险区间，调度器必须切到 risk acceleration mode
• 原先的 snooze、repeat、delay 规则都可能需要被打断或重排

这就是为什么我更愿意把 temperature 看成 override input，而不是普通环境变量。

2.2 没有 temperature override，就很难称得上完整 CPD

如果系统已经确认 child presence，但因为沿用原先的时序而错过高温窗口，那就说明它虽然“会检测”，但不会真正保护。

所以高温相关设计至少应显式包含：

• 当前温度风险等级
• 风险加速阈值
• 哪些调度动作会被立即覆盖
• 是否触发空调 / 解锁 / 远程通知等 intervention
• 是否要求保留更强的 safe-state

这部分实际上决定了 CPD 是“提醒功能”还是“安全功能”。

三、升级调度正在成为真正的控制面

3.1 首报不是结束，而是一个阶段切换点

传统思路里，首报像一个单点事件。但更合理的理解是：

• 首报 = 系统进入 active mitigation session 的起点

之后系统要持续管理：

• 是否还持续检测到 child presence
• 是否收到人工确认/取消
• 是否进入高温加速
• 外部通知是否成功
• 是否需要切换到更激进 intervention

因此 CPD 更像一个 session-based safety controller，而不是一次事件触发器。

3.2 notification router 也在变成正式模块

协议允许且鼓励的升级通道包括：

• 车外可见/可听告警
• 手机 App
• 钥匙反馈
• connected services / 第三方联系人

这意味着“告警”已经不是蜂鸣器 alone，而是一个 multi-channel router：

• 谁能最快收到？
• 哪个通道当前可用？
• 哪个通道失败后怎么兜底？
• 是否要根据风险级别动态切换？

这和停车态安全体系里的 notification router 完全是一回事。

四、验证体系为什么也必须跟着升级

4.1 CPD 最大的失败并不一定是漏检，而是错过正确动作时机

举几个最典型的失败模式：

• 检到了，但 warning 太慢
• warning 发了，但 escalation 太迟
• 温度升高了，但系统没打断 snooze
• 远程通知链路失败，没有通道兜底
• 取消后又持续存在，却没有再次升级

这些问题全都不是 perception benchmark 能测出来的。

4.2 真正需要的是 action-level regression

所以 CPD 测试矩阵需要从“有没有检测到”升级成：

• presence × lock state × temperature × timer phase × notification availability × intervention outcome

并重点验证：

• warning latency
• escalation timing
• override correctness
• repeated alert cadence
• safe-state holding
• trace completeness

4.3 可编程 CPD surrogate 会越来越重要

这轮搜索里还有一个很有价值的信号：行业已经开始强调 benchmark-grade CPD surrogate / test targets，支持：

• 呼吸/心跳模拟
• 周期性呼吸暂停
• 年龄段 target library
• 雷达 / UWB / Wi-Fi / vision 多模态兼容
• 14 DOF 行为模拟

这说明验证对象已不再只是拍几段真实视频，而是需要 可重复、可编排、可控参数的测试资产。这类资产越成熟，团队越容易把 scheduler 和 override 逻辑做稳。

五、对 IMS 开发的直接启示

5.1 把 CPD 设计成正式控制面

我会建议至少抽出这些正式对象：

• cpd_presence_state
• warning_phase
• temperature_override_state
• notification_route_state
• intervention_state
• trace_id

5.2 snooze / cancel / repeat 都要有正式语义

不要把这些交互做成零散 if-else。更好的做法是把它们定义为状态机事件：

• warning_acknowledged
• warning_delayed
• presence_reconfirmed
• escalation_started
• temperature_override_triggered
• intervention_executed

这样后续验证、追责、售后、法规解释都更容易。

5.3 先做四类核心回归场景

如果只能先做一批回归资产，我会优先做：

1. 锁车后短时检测 → 15 秒首报
2. 未锁场景 → 10 分钟告警路径
3. warning 取消/延迟后 → 90 秒内升级
4. 高温触发 → 立即 override + intervention

5.4 让 CPD 与统一干预层对齐

长期看，CPD 不应孤立存在。它应和其他 IMS 风险一样，接入统一的：

• scheduler
• notification router
• intervention executor
• traceability framework

这样才能避免每个功能各自维护一套告警小系统。

六、下一轮关键词怎么进化

基于这轮研究，我认为后续搜索词应继续演化为：

• CPD temperature override immediate intervention
• child presence detection alert cadence validation
• CPD notification routing connected services
• programmable CPD surrogate vital signs validation
• parking safety scheduler occupant monitoring

总结

CPD 正在从“儿童检测功能”升级为“停车态安全控制面”。

真正决定量产能力的，越来越不是 detector 分数，而是：

• 能否按时首报
• 能否稳定重复升级
• 能否在高温时立即覆盖默认调度
• 能否把通知送到真正能干预的人
• 能否用可编程测试目标与 action-level regression 把整条链路反复验证

这意味着 CPD 的下一个主战场，不是单传感器精度，而是 scheduler + router + temperature override + intervention 的系统工程。

---

参考来源

• Smart Eye, What Euro NCAP 2026 Says About Child Presence Detection, 2025
• IVSafes, Benchmark-Grade CPD (Child Presence Detection) Surrogates for Next-Generation In-Cabin Safety, 2025