CPD真正开始变成系统能力的标志是Escalation-Orchestration

CPD 真正开始变成系统能力的标志，是 Escalation Orchestration

日期： 2026-03-31
主题： CPD / Child Presence Detection / Escalation / Intervention / Caregiver Notification / Euro NCAP 2026

一句话结论

CPD 发展到 2026，真正拉开差距的已经不再只是“能不能检测到孩子”，而是：在检测成立之后，系统能否把 车内提示、外部可见告警、重复升级、远程通知、气候/解锁干预 串成一条可靠、按时、可追溯的 escalation orchestration 链路。

也就是说，CPD 正从 detection feature 变成一个完整的系统编排能力。

为什么这件事现在变成主问题

Euro NCAP 2026 对 CPD 的要求，已经明确不只停留在 sensing：

锁车后 15 秒内开始告警
未锁车但门已关后，10 分钟内也要处理 trapped child 场景
初始告警后，如果孩子仍存在，需要继续 escalation
告警要持续至少 20 分钟、每分钟重复
要求外部可见/可听
为拿满分，还需要 intervention：气候控制、解锁、远程通知等
干预必须在锁车后 10 分钟内，或第一次 escalation 后 5 分钟内开始

这些要求组合起来释放出一个清晰信号：

Euro NCAP 正在考核的，不只是 detection 成功率，而是“发现后整个升级链路是否真正能把信息送达并促成干预”。

所以 CPD 的核心问题不再只是 sensing robustness，而是 post-detection control plane。

为什么 detection 做对了仍然不够

很多团队会觉得：只要 detection 足够准，后面的告警不过是“触发几个动作”。但这在 CPD 上是危险的低估。

1. 真正的风险来自“人没有被叫回来”

CPD 的最终目标不是模型分数，而是让某个能干预的人在危险升级前知道并采取动作。

如果系统只是：

车里响了一次
屏幕亮了一次
app 偶尔发了通知

但实际 caregiver 没注意到，或者告警链路中断，那 detection 再准也没有转化成安全结果。

2. 多通道告警之间天然存在时序与仲裁问题

CPD 后链路往往涉及：

车内 HMI
车外可见/可听告警
手机 App 推送
钥匙反馈
connected service / 第三方联系人
climate / door unlock 干预

这些动作不是简单并列执行，而是要回答：

先触发谁
何时重复
何时升级
何时允许用户延迟一次
哪个链路失败后如何切换到备用路径
温度快速上升时是否跳过正常节奏直接强干预

这本质上已经是编排系统，而不是通知脚本。

3. 真正难的是“长时间持续的责任闭环”

CPD 不像 DMS 很多场景只需要几秒内做判断。它有明显的长尾治理特性：

需要持续 20 分钟以上的重复提醒
需要跨车内、车外、远端多个域
需要支持 driver deliberate delay 但不能被轻易规避
需要在 cabin temperature 升高时切换策略

这意味着 CPD 要维护的不是单次 state，而是一整条 escalation lifecycle。

真正该建设的是 CPD Control Plane

更合理的架构，不应只是：

CPD detector -> trigger alert

而应该是：

Presence Evidence → Risk Confirmation → Escalation State Machine → Notification Arbiter → Intervention Controller

A. Escalation State Machine

负责：

initial_warning_pending
initial_warning_active
escalation_active
remote_notification_active
intervention_active
manual_delay_consumed
temperature_emergency_override

B. Notification Arbiter

负责：

选择车内/车外/手机/钥匙/connected service 的触发顺序
避免所有通道同时乱发导致噪声
当某一通道失败或无人响应时切换备用路径

C. Intervention Controller

负责：

door unlock
climate control
caregiver escalation
高温条件下的 immediate response

这三层加起来，才是真正决定 CPD 是否能从“感知功能”升级为“有效救援入口”的部分。

对 IMS / CPD 开发的直接启示

优先级 1：显式定义 escalation schema

建议至少正式定义：

cpd_presence_state
escalation_stage
next_escalation_deadline
manual_delay_consumed
external_visibility_state
notification_channel_state
intervention_state
temperature_override_state
reason_code

优先级 2：把“通知送达”视为正式系统目标

不要只统计 detection 和 alert trigger。建议单独评估：

warning delivered
warning perceivable outside
repeated escalation success
caregiver notified
intervention started on time

优先级 3：把温度与时间约束纳入统一仲裁

CPD 的升级策略不能只看 presence。还要联合：

locked / unlocked 状态
time since detection
time since warning cancellation
cabin temperature trend
channel availability

优先级 4：把远程通知失败作为正式回归场景

很多系统只测 happy path，但真正危险的是：

App 没连上
key 不在附近
connected service 延迟
warning 被延迟一次后仍无人处理
高温快速上升时原节奏来不及

这些都应成为 mandatory regression。

一个更现实的判断

未来 CPD 的护城河，不会主要由“哪家雷达更灵”单独决定，而会越来越由下面三件事决定：

谁能把 detection 后的升级链路做成按时、可追溯、可恢复的 orchestration
谁能把 notification / intervention / temperature override 串成统一控制面
谁能把 caregiver reachability 做成正式安全目标，而不是附属体验功能

所以 CPD 真正开始变成系统能力的标志，不是更高 recall，而是 escalation orchestration。

可直接执行的研发清单

本周可做

为 CPD 增加 escalation_stage / next_escalation_deadline / intervention_state
梳理现有通知通道与失败回退关系
把高温 override 场景单独列出

本月可做

建立 CPD escalation lifecycle regression suite
补“通知送达率/干预准时率”指标
将车内/车外/远程通道纳入统一 arbiter

下一阶段必须做

把 CPD 后链路做成正式 control plane
把 caregiver reachability 写入设计目标
把 escalation / intervention trace 纳入 dossier 资产

参考来源

Smart Eye, What Euro NCAP 2026 Says About Child Presence Detection
https://smarteye.se/blog/what-euro-ncap-2026-says-about-child-presence-detection/
Smart Eye, What’s Changing in Euro NCAP’s 2026 Safety Ratings?
https://smarteye.se/blog/euro-ncap-2026-whats-changing/