CPD正在从检测功能升级为多通道干预与通知编排系统
CPD 正在从检测功能升级为多通道干预与通知编排系统
发布时间： 2026-03-27
主题： CPD / child presence detection / notification / intervention / Euro NCAP 2026
关键词： CPD、child left alone、notification routing、intervention、escalation、Euro NCAP 2026、Tesla radar
一句话结论
过去谈 CPD（Child Presence Detection）时，很多团队的默认理解还是：
- 先解决“能不能检测到孩子”
- 检到之后车里响一声
- 再加个 App 推送就差不多了
但 2025-2026 的法规和产业信号已经把这件事彻底改写了：
CPD 的真正系统对象，不再只是 child detector，而是一个跨车内外、多通道、带升级时序的 notification + intervention orchestration system。
也就是说，量产系统真正要做好的不是“发现孩子”这一刻，而是：
- 什么时候发出第一轮外部可感知告警
- 允许怎样的延时或 snooze
- 什么时候进入 escalation loop
- 通知应该发给车外的人、车主 App、钥匙还是第三方联系人
- 什么时候必须切到 intervention，例如开空调、解锁车门
对 IMS / OMS 团队来说，这意味着：
- CPD 已经从 detector feature 升级为编排系统问题
- 真正高价值模块是 scheduler、router、policy engine，而不是单一感知器
- 法规评分和量产体验的分水岭，在于通知与干预链是否稳定、及时、可验证
1. 为什么现在必须重新定义 CPD
只把 CPD 当成“儿童检测器”，很容易忽略一个事实：
孩子真正面临风险的，不是被检测到的那一瞬间，而是后续数分钟内系统有没有把正确的人叫来、有没有做出正确干预。
检测只是第一步。
真正决定结果的，是后面的全链路：
- initial warning
- escalation warning
- repeat loop
- owner notification
- remote contact routing
- climate / unlock intervention
- temperature override
一旦把这些都纳入考虑，CPD 就不再像一个普通视觉/雷达 feature，而更像一套停车态安全编排系统。
2. Euro NCAP 2026 已经把“检测后怎么办”写得越来越清楚
Smart Eye 2025 对 Euro NCAP 2026 CPD 协议的公开解读，已经把这一点表达得很明确。
2.1 首先，CPD 不再接受“间接猜测”
2026 协议强调：
- 必须使用 direct sensing
- 直接感知对象包括：
- movement
- breathing
- heartbeat
- 覆盖范围需要包括所有相关座位、脚坑、驾驶位，行李厢可排除
- 检测对象覆盖到 6 岁及以下儿童
- 系统默认应 ON
这件事把很多老式后排提醒方案排除了。
因为后排提醒只能猜“也许后排有人”，但 CPD 要求系统真正知道“有一个活体儿童在车里”。
2.2 更关键的是：协议细化到了告警时序
公开解读中明确给出了关键时间要求：
- 锁车后：检测到儿童后 15 秒内 必须开始 warning
- 未锁车但车门关闭：可延迟，但需在 10 分钟内 发出 warning
- 初始告警必须：
- 车辆发出视觉或声音信号
- 车外可察觉
- 至少持续 3 秒
- 驾驶员可主动延迟一次，最长 10 分钟
- 若儿童仍在车内：
- 首轮告警结束/被取消后 90 秒内 必须开始升级告警
- 告警至少 每分钟重复一次
- 至少持续 20 分钟
- 每次持续至少 15 秒
- 车内还应显示可从车外读取的信息，如 “Check the seats”
这套条款说明了什么？
说明 Euro NCAP 看待 CPD 的方式已经不是：
- detect yes/no
而是：
- detect
- warn on time
- allow deliberate delay once
- escalate correctly
- repeat reliably
- keep message externally actionable
这就是典型的 orchestration 问题。
3. 满分门槛其实不在检测，而在 intervention 编排
更值得注意的是，协议与公开解读都指出：
仅检测 + 告警，不足以拿满分。
若要拿更高分，系统还必须具备 intervention features，例如：
- 开启空调 / climate control
- 解锁车门
- 通过 connected app 发出远程提醒
- 必要时联动更远端联系人
并且有明确的 intervention 时序：
- 必须在 锁车后 10 分钟内 开始，或
- 在 首轮升级告警后 5 分钟内 开始，
- 两者取更早者
- 若温度进入危险水平，应立即响应
这件事把 CPD 又往前推了一层。
因为从这里开始，它已经不只是 notification system，而是：
notification + intervention co-orchestration system
4. 产业落地也证明：真正的差异不在 detector，而在多通道通知与升级链
Tesla 2025 推出的 Child Left Alone Detection，虽然不是法规原文，但它提供了一个很强的产品化参考。
公开报道提到，Tesla 的系统一旦识别到 unattended child，会：
- 启动车外 hazard lights
- 发出 audible alert
- 给车主 App 推送消息
- 按间隔重复告警，直到有人回车
- 数据在本地处理，不上传云端原始感知数据
这套产品行为本质上已经非常接近“法规化编排系统”的雏形：
- 本地检测
- 车外可察觉告警
- 远程个人通知
- 重复升级
- 隐私本地化处理
它的启示不是“Tesla 用了雷达”，而是：
量产体验的关键，在于 detector 输出之后，系统能不能启动稳定的多通道动作链。
5. 为什么 scheduler 与 router 才是 CPD 真正的主模块
把法规与产业动作放在一起看，CPD 至少需要三个正式模块。
5.1 Escalation Scheduler
负责回答：
- 锁车后 15 秒窗口怎么计时
- 未锁车 10 分钟窗口怎么计时
- 用户延迟 10 分钟如何处理
- 何时进入 escalation
- 重复告警每分钟如何稳定触发
- 干预最晚何时必须启动
- 高温是否打断原时间线
这不是 detector 能解决的问题，而是正式的状态机/调度器问题。
5.2 Notification Router
负责回答：
- 车外视觉/声音通道是否已触发
- 车内文本信息是否可从外部读取
- App 是否已成功送达
- 钥匙提醒是否可用
- connected service 是否可用
- 第三方联系人是否应接管
- 某一通道失败后是否需要兜底改路由
它其实更像一套 message routing policy。
5.3 Intervention Policy Engine
负责回答：
- 什么时候开空调
- 什么时候解锁
- 干预是否受气温、车门状态、用户返回事件影响
- 哪些 intervention 可以并行做，哪些需要互斥
这层如果没有被显式设计出来，CPD 最后就会被一堆 if-else 写散。
6. 对 IMS 开发最关键的启示：要把 CPD 从“感知专题”升级为“停车态安全 control plane”
如果还把 CPD 放在感知团队独立负责，最后通常会出现这些问题：
- detector 很强，但告警乱
- 有车外提示，但没有远端兜底
- 有 App，但时间线不符协议
- 有 intervention，但缺乏清晰触发条件
- 无法解释一次真实事件为什么没有升级或为什么升级过快
真正更合理的系统拆法应该是：
6.1 感知层
- 雷达 / camera / seat / physiological presence signal
- child-presence confidence
- seat/zone localization
6.2 状态层
- parked-state status
- locked/unlocked
- occupant_still_present
- snoozed / cancelled / resumed
- temperature risk level
6.3 编排层
- escalation scheduler
- notification router
- intervention policy engine
6.4 动作层
- exterior lights
- horn/chime
- cabin message
- app push
- key feedback
- third-party contact
- HVAC
- unlock
把这四层拆出来后，CPD 才从 feature 变成平台能力。
7. 下一阶段最值得建设的是“谁能来救”的路由逻辑，而不是更复杂的 detector
我越来越明确地觉得，CPD 真正的系统难点不是“检测率再提升 1%”，而是：
在停车态风险发生后，系统能否迅速找到“最可能改变结果的人或动作”。
这就要求系统的通知设计不只是“多发几个通道”，而是要考虑：
- 当前离车最近的人是谁
- 车主是否在线
- 钥匙是否在附近
- App 是否送达
- 车外行人是否更容易第一时间响应
- 高温时是否应先 intervention 再继续找人
这已经明显不是 detector thinking，而是 routing thinking。
8. 我的路线判断：CPD 的竞争重点会从 direct sensing 转向 orchestration maturity
2023-2025 的第一阶段，行业主要在争：
- direct sensing 还是 indirect sensing
- radar、camera、UWB、seat sensor 哪条路线更稳
- 如何覆盖脚坑、不同年龄 dummy、呼吸/心跳/微动
但到 2026 之后，我更倾向于判断竞争重点会进一步转移为：
8.1 谁的 escalation 更可靠
不是谁先 detect，而是谁更少漏掉升级时机、少打乱时序。
8.2 谁的 notification 更可达
不是谁支持更多通道，而是谁真正把消息送到了最可能介入的人手里。
8.3 谁的 intervention 更像正式策略层
不是单一“开空调”功能，而是能根据风险与上下文稳定决策。
8.4 谁的 traceability 更强
法规和量产都会要求解释：
- 什么时候检测到
- 为什么延迟
- 为什么升级
- 哪些通道已尝试
- 干预什么时候启动
- 温度是否触发 override
所以最终胜出的，往往会是 orchestration maturity 更高的团队。
9. 对当前 IMS 团队的优先级建议
P0：把 CPD 需求文档改写成 orchestration spec
明确写出：
- scheduler state
- delay/snooze rules
- escalation timing
- repeat cadence
- intervention deadlines
- temperature override
- routing fallback
P1：把 notification router 设计成正式模块
不要把 App、车外告警、钥匙提醒散在业务代码里。
P1：把 intervention 作为一等能力接入
至少显式建模：
- climate action
- unlock action
- remote alert action
- action preconditions / cooldown / override
P2：验证矩阵升级为 time-sequence × channel-outcome
建议至少覆盖：
- locked/unlocked × snooze/no-snooze × temperature-normal/high × channel-success/failure × user-return timing × intervention outcome
P2：把 trace_id 与事件时间线做成正式回放资产
这会极大降低后期量产和法规解释成本。
10. 下一轮 TrendRadar 关键词建议
这一轮之后，CPD 方向的搜索词建议继续进化：
- child presence detection escalation scheduler
- CPD notification routing intervention policy
- child left alone detection app notification HVAC unlock
- parked-state safety orchestration in-cabin monitoring
- CPD time sequence validation Euro NCAP 2026
- temperature override child presence detection
因为真正值得追踪的，不再只是“哪个传感器更准”，而是：
谁在把 CPD 做成一套成熟的停车态安全编排系统。
总结
我对这条线的判断已经很明确：
CPD 正在从检测功能，升级为多通道通知与干预编排系统。
未来高价值的 CPD 平台，不会只强调：
- 我能检测到孩子
而会强调：
- 我能在正确时间发出第一轮车外告警
- 我能按协议稳定升级
- 我能把通知路由给最可能介入的人
- 我能在必要时自动开启 climate / unlock 等 intervention
- 我能完整回放整个时间线并经得起审计
谁先把这套 orchestration 层做成正式平台能力，谁就更接近真正可量产、可验证、可高分的停车态安全主路线。
参考资料
- Smart Eye, What Euro NCAP 2026 Says About Child Presence Detection, 2025-05-14
https://www.smarteye.se/blog/what-euro-ncap-2026-says-about-child-presence-detection/ - CPD Project, Project Description, 2025
https://www.child-presence-detection.org/ - Drive Tesla, Tesla Rolls Out ‘Child Left Alone Detection’ Feature in 2025.14.12 Software Update, 2025-05-28
https://driveteslacanada.ca/news/tesla-rolls-out-child-left-alone-detection-feature-in-2025-14-12-software-update/