Euro NCAP 2026：EF 与 Unresponsive Driver 详细拆解
前言
在 Euro NCAP 2026 的 Driver Engagement 体系里，Unresponsive Driver 是最容易被低估、但又最能拉开系统成熟度差距的一项。
很多团队会把它理解成：
“就是 DMS 检测一下驾驶员是不是闭眼太久。”
这是远远不够的。
Euro NCAP 真正要考察的，不只是你能不能“看出来驾驶员没反应”，而是：
当驾驶员已经不响应时，整车能不能在规定时间内进入 Emergency Function（EF），把风险兜住。
一、EF 到底是什么
EF 是 Emergency Function。
协议里，它不是普通的告警动作，而是一种系统级干预：
- 自动减速
- 维持车道
- 与前车保持距离
- 将车辆导向安全停止位置，或者至少降低到 10 km/h 以下
可接受的停止区域包括：
- 当前车道
- 更慢车道
- 硬路肩
- 应急停车区
也就是说，EF 的核心不是“提醒驾驶员”，而是：
在驾驶员已经不具备接管能力时，由系统执行最小风险机动。
二、Unresponsive Driver 怎么定义
按照 Euro NCAP Driver Engagement Protocol v0.9，驾驶员可被判定为 unresponsive 的典型条件包括：
条件 1
在 distraction warning 发出后，驾驶员的 gaze 3 秒内仍未回到前向道路。
条件 2
驾驶员闭眼 ≥ 6 秒。
协议还说明：
- 也允许 OEM 使用其他更早判断无响应的方法
- 但最终必须能证明系统的判定逻辑合理且可验证
所以这项不只是“闭眼检测”，而是：
- gaze 返回逻辑
- warning 后反应逻辑
- 状态机升级逻辑
三者共同构成的系统能力。
三、为什么这不是普通 DMS 功能
普通 DMS 更多是：
- 疲劳提醒
- 分心提醒
- 手机提醒
这些大多停留在 warning 层。
但 Unresponsive Driver 不一样，它天然跨了三层：
1. DMS 层
负责识别：
- 长时间闭眼
- gaze 不回路
- 可能的昏厥 / 极端疲劳 / 医疗异常
2. HMI 层
负责 distinct warning：
- 更高等级的明确警告
- 视觉 + 声音 / 触觉组合
3. ADAS / Vehicle Control 层
负责 EF：
- 纵向控制
- 横向控制
- 安全减速与停车
所以它本质上不是“DMS 单模块拿分项”，而是：
DMS + HMI + ADAS + 车控 + 功能安全 的联合作战项。
四、关键时序要求
这项最容易失分的地方，就在时序。
4.1 warning 时序
协议要求：
- 当系统判定驾驶员 sleep / impairment / unresponsive 后
- 必须立即发出 warning
4.2 distinct warning
对于 unresponsive driver，必须有一个更明确、可区分的 warning 阶段。
4.3 EF 启动时限
这是最关键的一条：
Emergency Function 最晚要在 distinct warning phase 开始后 5 秒内启动。
这意味着：
- 不能无限等待驾驶员“也许会醒”
- 不能 warning 半天不接管
- 不能 HMI 和 ADAS 时序脱节
如果你的系统只能做到：
- 检测无响应
- 发告警
- 但 5 秒内不能切到 EF
那这项成熟度就不够。
五、EF 对 ADAS / 车控的真实要求
协议对 EF 的要求，不是“减速一下就算完成”。
至少应具备：
| 能力 | 要求 |
|---|---|
| 纵向控制 | 自动减速 |
| 横向控制 | 保持车道 |
| 跟车能力 | 维持与前车距离 |
| 安全目标 | 停到安全区域，或至少降到 <10 km/h |
这说明 EF 至少需要这些车端能力配合：
- ACC / longitudinal control
- LKA / lane centering / lateral control
- 对外部环境的最小感知支持
- 接管 HMI 与状态机支持
如果没有这些能力，DMS 再强，也没法真正完成 Euro NCAP 所说的 EF。
六、DMS 需要给 EF 提供什么输入
从系统设计角度，DMS 不应该直接输出“启动 AEB”“启动 ACC”这种控制命令。
更合理的是输出一组 Driver State 信号 给主机侧：
1. 判定信号
- unresponsive = true / false
- sleep / microsleep / drowsiness 状态
- gaze return timeout
2. 连续量
- 闭眼时长
- timeOffRoad
- cumulativeTimeOffRoad
- distractionLevel / drowsinessLevel
3. 质量信号
- cameraStatus
- frameState
- limitedPerformance
- fuSaViolation
4. 事件信号
- sleep entered
- unresponsive entered
- warning phase entered
- system degraded
主机侧再根据这些输入，做：
- HMI 升级
- FCW / AEB / LKA 增敏
- EF 切换
七、为什么 EF 是 Euro NCAP 2026 里最有“整车味”的项目
因为它把 DMS 从一个“提醒模块”升级成了“安全闭环入口”。
以前：
DMS 主要回答：
- 你困了吗？
- 你分心了吗？
现在：
DMS 还要回答：
- 你现在还有没有能力继续驾驶？
- 如果没有，车能不能马上接手？
这会直接推动 DMS 与 ADAS 的深度耦合。
所以对 IMS 团队来说，这项的真正价值在于：
它迫使舱内感知系统从“感知层”走向“系统协同层”。
八、最容易失分的 6 个坑
坑 1：只检测闭眼，不检测 warning 后 gaze 是否回路
这样只能做 sleep 检测，做不好 unresponsive。
坑 2：只有 warning，没有更高等级的 distinct warning
协议强调 warning 层级区分，不是同一种声音一直响。
坑 3：EF 启动超时
超过 distinct warning 后 5 秒才接管，风险很大。
坑 4：DMS 和 ADAS 没打通
算法能识别，但整车没有纵向/横向接管链路。
坑 5：没有质量门控
如果 cameraStatus 异常、limited performance、fuSaViolation 还继续触发高等级策略，系统可信度会出问题。
坑 6：把它当算法项，不当系统项
这项本质是系统工程，不是单模型 benchmark。
九、对 IMS / DMS / ADAS 团队的开发建议
建议 1：尽早定义状态机
至少要清楚：
- distracted
- sleep
- unresponsive
- distinct warning
- EF active
这些状态如何切换。
建议 2：把 DMS 输出标准化
建议形成统一接口：
- DriverMonitoringState
- DriverMonitoringEvent
- DriverMonitoringToAdasSignal
不要让 ADAS 直接吃底层视觉字段。
建议 3：把质量门控做成硬条件
比如：
cameraStatus != WORKINGisLimitedPerformance == YESfuSaViolation != NONE
这些都要影响是否允许触发高等级联动。
建议 4：EF 别等协议临门一脚再做
因为 EF 依赖：
- 车控接口
- HMI
- ADAS
- 功能安全
- 测试验证
越晚开始联调，越容易被时序问题卡死。
十、总结
如果只看名字，很多人会把 Unresponsive Driver 理解成一个“小功能”：
“检测驾驶员是不是没反应。”
但从 Euro NCAP 2026 的真实要求看，它根本不是一个小功能，而是：
DMS 把整车安全系统拉进来的一道门。
它要求你不仅要知道“驾驶员不行了”，还要在明确时限内完成：
- warning
- upgraded warning
- EF 接管
- 最小风险机动
所以这项真正考察的是：
你的系统是不是已经从“会检测”进化到了“会兜底”。
这也是 2026 之后 DMS / IMS 最值得提前布局的整车协同能力之一。
参考资料
- Euro NCAP, Safe Driving – Driver Engagement Protocol, Version 0.9, November 2024.
- Euro NCAP 2026 Protocol materials.
- Smart Eye, Driver Monitoring 2.0: How Euro NCAP is Raising the Bar in 2026, 2025.