无响应驾驶员干预不是提醒功能，而是最小风险动作入口

前言

如果说这一晚前面的几篇文章，主要在回答 CPD 怎样从识别走向控制面、认知分心与 impairment 怎样走向统一干预仲裁层，那么这一篇要继续往前推进最后一步：

Euro NCAP 2026 里的 unresponsive driver，本质上已经不是提醒功能，而是 minimum risk maneuver（MRM）入口。

这不是文字游戏，而是系统边界真的变了。

过去很多团队理解“无响应驾驶员”时，脑子里还是：

• 多一级蜂鸣器
• 再加一点方向盘震动
• HMI 红一点
• 也许加个语音提醒

但现在协议和行业信号已经在逼迫架构升级：

• 如果驾驶员持续无响应，系统不能只提醒；
• 它必须能进入控制性动作链；
• 它必须和 ADAS / vehicle assistance 协同；
• 它最终要把车安全带到可控停下状态，或者至少走到这一链路的入口。

所以真正该重构的不是提醒策略，而是DMS 到 MRM 的系统责任链。

一、为什么我认为边界已经变了

1.1 ETSC 对 2026 协议变化的解读非常直接

ETSC 在解读 Euro NCAP 2026 新协议时用了一个很关键的表述：

• 测试将奖励 unresponsive driver interventions；
• 这些技术需要能够识别 medical emergency 或 extreme intoxication；
• 并把车辆 safely bring to a controlled halt。

这里的关键词不是 warning，而是：

• interventions
• controlled halt

一旦“受奖励”的对象从提醒变成“安全受控停车”，系统语义就已经从 HMI feature 变成 safety action chain。

1.2 Smart Eye 对供应侧要求的表述也说明它不是孤立告警

Smart Eye 对 2026 driver engagement 的解读里，同样给了很清楚的动作方向：

• impaired driver 时提高 FCW / AEB 灵敏度；
• distracted driver 时调整 LKA / LDW；
• driver unresponsive 时，触发 emergency stop function，把车辆带到 controlled stop。

这说明在供应商视角里，DMS 已经不再只是“生成告警”的感知模块，而是开始成为：

• 车辆控制参数的调节输入；
• emergency stop / MRM 的上游触发条件；
• 驾驶员能力不足时的安全接管入口。

1.3 Mobileye 的公开路线也在把 DMS 接到 takeover / vehicle behavior adaptation 上

Mobileye 的 DMS 路线更进一步，它公开强调：

• DMS 与 ADAS 在单芯片/单平台融合；
• 根据 driver attentiveness 动态调节跟车距离、巡航敏感度、变道限制；
• 在 hands-off / eyes-off 平台上，为 takeover request 提供更智能的决策支持。

这件事特别关键，因为它证明：

DMS 最值钱的输出，已经不是“司机状态标签”，而是“车辆动作策略该如何被约束或升级”。

无响应驾驶员干预正是这个逻辑的极端形态：当 driver capability 下降到足够低，系统就不该继续等待人接管，而应该切换到最小风险动作链。

二、为什么“无响应”本质上属于能力塌陷，而不是注意力问题

2.1 distraction / fatigue / impairment 还可能保留部分可交互性

很多状态虽然危险，但还没彻底丧失闭环：

• 分心的驾驶员可能还能被拉回注意；
• 疲劳驾驶员可能还能响应提醒；
• impairment 驾驶员虽然能力下降，但未必完全无法执行动作。

此时系统仍可以：

• 警告
• 加严 ADAS
• 限制某些机动
• 争取 human re-engagement

2.2 unresponsive driver 则意味着 human-in-the-loop 正在失效

一旦进入无响应场景，问题就变了。系统面对的不是“有没有风险”，而是：

• 这个人是否还在回路内？
• 还能不能承担接管责任？
• takeover request 是否已经失去意义？
• 是否该把“等人恢复”切换为“车辆自保”模式？

这意味着 unresponsive driver 的架构位置，天然更接近：

• takeover failure handling
• emergency stop function
• minimum risk maneuver
• post-stop safety handling

而不是传统 DMS 提醒逻辑。

三、为什么这会成为 DMS 与 ADAS 真正的耦合点

3.1 认知分心和 impairment 更多是“加严控制”

在前一篇文章里我已经判断：认知分心与 impairment 正在汇聚到统一 intervention arbiter。

但两者很多时候更偏向：

• 调高 warning sensitivity
• 限制 lane change
• 拉大跟车距离
• 缩短 takeover tolerance
• 提高 safe-state bias

3.2 unresponsive driver 则把系统从“辅助约束”推向“动作接管”

这是更高一级的转折点。

因为一旦判定 driver 无响应，系统就需要回答：

• 是否仍维持当前自动化模式？
• 是否进入 MRM 准备状态？
• 是否启动 controlled deceleration？
• 是否触发 hazard / eCall / post-stop procedure？

也就是说，unresponsive driver 是 DMS 正式进入 vehicle motion governance 的入口条件之一。

这就是我为什么认为，它不能再被当作提醒功能看待。

四、真正难点不在检测“闭眼”，而在决定何时放弃等人

4.1 检测只是第一步，真正难的是 action threshold

一个系统也许能看见：

• 眼闭合持续异常
• 头部姿态失稳
• gaze 无目标
• 手部无控制迹象
• 对 HMI / torque / audio 提醒无反应

但更难的是：

• 这些证据叠加到什么程度，才足以放弃继续等待人？
• 多久算 persistent？
• degraded quality 下能否做强动作？
• 在高速 / 低速 / 拥堵 / L2 / L3 下门限是否一致？

这其实是一个 abandon-human-loop thresholding 问题，而不是单纯视觉检测问题。

4.2 错误类型也变得更危险

unresponsive driver 场景下，误差不再是普通 feature 误报，而是两类高代价错误：

• 过早接管：人其实还在，只是短暂迟缓，系统却过度进入强动作；
• 过晚接管：人已经不在回路，系统却继续发送无意义提醒，错失最小风险窗口。

这说明验证目标必须从 detection accuracy 升级到：

• action timing correctness
• escalation appropriateness
• safe-stop entry threshold
• post-trigger stability

五、我更看好的架构：把 unresponsive driver 设计成 MRM gatekeeper

5.1 推荐链路：Evidence → Responsiveness State → Action Gate → MRM

相比把 unresponsive driver 做成 DMS 里的一个小标签，我更建议把它设计成一条明确的动作责任链：

1. Evidence Layer

   • eye closure / gaze absence / head slump
   • steering interaction absence
   • pedal / control inactivity
   • response-to-alert evidence
   • quality / occlusion / credibility

2. Responsiveness State Layer

   • responsive
   • delayed_response
   • suspected_unresponsive
   • persistent_unresponsive
   • medically_critical_or_unknown

3. Action Gate Layer

   • warning cadence selection
   • assisted-driving restriction
   • emergency stop preparation
   • MRM eligibility
   • eCall / hazard pre-trigger

4. MRM / Controlled Halt Layer

   • deceleration profile
   • lane holding / shoulder strategy
   • stop confirmation
   • hazard / unlock / call chain

这样定义的好处是：

• DMS 不会停在“看见了什么”；
• ADAS 不会缺少可解释上游；
• 验证团队能直接对 action gate 做断言；
• 后续把 impairment / medical emergency / takeover failure 接进来更自然。

5.2 Action Gate 应至少保留哪些状态

建议至少显式定义：

• responsiveness_state
• response_persistence
• alert_ack_state
• driver_capability_floor
• automation_context
• mrm_eligibility_state
• controlled_halt_state
• reason_code
• trace_id

这比只保留一个 unresponsive=true/false 有用得多。

六、对 IMS / DMS 开发的直接启示

6.1 不要把 unresponsive driver 放在 HMI 团队末端兜底

如果组织上把它理解成“提醒做重一点”，最后大概率会变成：

• 视觉算法给一个标签；
• HMI 负责响几次；
• ADAS 再单独做 emergency stop。

这会导致责任链断裂。

更合理的做法是从一开始就把它定义成 cross-domain safety path，让 DMS、ADAS、HMI、安全策略、eCall/后处理一起设计。

6.2 要把“响应缺失”纳入统一 schema，而不是独立例外

建议把以下对象正式化：

• alert_response_state
• human_loop_integrity
• driver_capability_floor
• mrm_gate_state
• controlled_halt_readiness
• post_stop_action_state

这样才能与 fatigue / distraction / impairment 共用统一仲裁框架。

6.3 验证资产应从“提醒有效性”升级为“最小风险动作入口正确性”

优先要补的不是更多静态视频，而是过程型回归：

• 司机短暂迟缓但可恢复
• impairment 持续恶化到无响应
• 医疗紧急状态下从 warnings 到 stop 的链路
• L2 / L3 takeover 请求无回应
• quality degraded 时是否保守进入强动作
• controlled halt 后 hazard / eCall / unlock 的联动一致性

真正应该被验证的是：

系统是否在正确的时刻，沿正确的路径，放弃等待人类并进入最小风险动作。

6.4 数据闭环也要围绕 action edge cases 建设

今后高价值数据不只是：

• 闭眼样本
• 低头样本
• 无表情样本

而是：

• alert issued but no acknowledgment
• acknowledgment delayed then recovered
• repeated no-response under different contexts
• transition from impairment to unresponsive
• takeover request unanswered

这些事件级数据，才真正决定 MRM gate 做得稳不稳。

七、下一轮 TrendRadar 关键词建议

基于这轮研究，后续更值得追的方向应该是：

• unresponsive driver intervention controlled halt
• DMS emergency stop function integration
• minimum risk maneuver driver monitoring
• takeover request unanswered driver readiness
• driver capability floor intervention policy
• DMS ADAS controlled stop architecture
• medical emergency in-cabin monitoring vehicle halt

这些词能把研究重心继续从“检测到了没有”推进到“系统何时、如何接管”。

总结

Euro NCAP 2026 把 unresponsive driver intervention 拉进正式奖励范围之后，这个能力的本质已经不再是提醒功能，而是：

DMS 接入 minimum risk maneuver 的入口。

所以真正要做的，不是把提示音做得更吓人，而是把整条责任链建出来：

• 从 responsiveness evidence
• 到 responsiveness state
• 到 action gate
• 到 MRM / controlled halt
• 再到 post-stop safety handling

谁能把这条链路做成稳定、可解释、可验证、可 OTA 的平台能力，谁才更可能在 2026 之后真正拿到 DMS / IMS 的系统护城河。

参考线索

• ETSC: Euro NCAP: New 2026 protocols target distraction, impairment, and speeding
• Smart Eye: Driver Monitoring 2.0: How Euro NCAP is Raising the Bar in 2026
• Mobileye: Presenting the Mobileye Driver Monitoring System, fusing road safety inside the cabin