DMS真正需要的不是更多状态标签而是Unified-Temporal-Action-Ladder

DMS 真正需要的，不是更多状态标签，而是 Unified Temporal Action Ladder

日期： 2026-03-31
主题： DMS / Driver Monitoring / Distraction / Impairment / Unresponsive Driver / Temporal Persistence / Action Ladder

一句话结论

到 2026，DMS 真正难的地方已经不是把疲劳、分心、损伤、无响应拆成更多标签，而是：如何把这些状态按时间持续性、风险叠加、响应情况统一映射到一条动作阶梯上。

也就是说，DMS 更需要的是 unified temporal action ladder，而不是继续堆状态分类头。

为什么这个问题现在必须正视

Euro NCAP 2026 已经把多个 driver state 同时拉进正式评估链：

drowsiness
distraction（包括短时视觉注意转移）
phone use
impairment
unresponsive driver

不同公开材料还反复强调：

这些状态需要 behavioural analysis、eye tracking、reaction time 等证据
无响应场景会进入更强动作与 emergency function
ADAS / DMS / HMI 的联合反应越来越重要

这说明监管视角并不是要五六个互不相关的 feature，而是要一条从轻风险到重风险、从短时异常到持续异常、从提醒到干预的连贯响应路径。

所以如果系统内部仍然是：

fatigue 一套状态机
distraction 一套状态机
impairment 一套状态机
unresponsive 一套状态机

最终一定会撞上行为冲突：

一个司机又像疲劳又像损伤怎么办
认知分心持续时间很长但响应仍然存在，走哪条链
impairment 可疑但 driver 对提醒有回应，是否仍进入强动作
无响应前有哪些状态应该共享同一个 persistence ladder

这些都说明：真正需要统一的是 时间与动作关系。

为什么“更多状态标签”不够

1. 风险真正被区分的关键，不是类型，而是持续性与可恢复性

驾驶风险并不只由“是什么状态”决定，更由：

持续了多久
是否在加重
是否和其他风险叠加
司机是否对提醒有响应
当前质量是否足以支持强动作

比如：

2 秒短时 glance-away 和 30 秒持续认知分心，动作显然不同
轻度损伤疑似 + 有响应，和完全无响应，也不该同级处理
疲劳与 impairment 的 cause attribution 可能不确定，但 persistence ladder 仍可统一

2. 动作层真正需要的是 escalation slot，而不是 feature name

HMI / ADAS / MRM 层最关心的问题是：

现在只是 observation 还是该提醒
是轻提醒、强提醒、限制辅助，还是准备 MRM
风险是否恢复
强动作是否被质量门控阻止

这些决策更接近一个 action ladder，而不是一堆 feature labels。

3. 无响应不是孤立 feature，而是 temporal ladder 的终点之一

很多团队会把 unresponsive driver 单独看成一个 feature。但从系统角度，它更像是：

多类 driver state 在持续恶化、反复提醒无效、driver response 消失后，最终进入的高危动作区间。

也就是说，它不应该与 distraction / impairment / fatigue 割裂，而应该共享同一套 persistence-to-action 语义。

真正需要建设的是统一时间-动作骨架

更合理的 DMS 架构不应是“多个 feature 各自报分数”，而应是：

Evidence Layer → State Family Estimation → Temporal Persistence Layer → Action Ladder Gate → HMI/ADAS/MRM Arbiter

A. State Family Estimation

用于保留语义来源：

fatigue_like
visual_distraction_like
cognitive_distraction_like
impairment_like
responsiveness_drop

B. Temporal Persistence Layer

用于统一治理：

transient
recurrent
persistent
escalating
non_recovering

C. Action Ladder Gate

真正决定系统动作：

observe
soft_prompt
salient_warning
persistent_warning
assist_restriction
mrm_candidate
controlled_halt

这样一来，不同 state family 可以共享同一动作骨架，而不是互相打架。

对 IMS / DMS 开发的直接启示

优先级 1：把 state type 和 action tier 拆开

建议至少正式定义：

state_family
persistence_level
response_ack_state
action_tier
quality_gate_state
mrm_eligibility_state
reason_code

优先级 2：把“响应情况”变成动作阶梯核心变量

同样的风险分数，在以下情况下动作应完全不同：

driver 对提醒有快速响应
driver 有迟缓响应
driver 无响应
driver 恢复后又再次掉回风险态

所以 response_ack_state 必须进入 ladder gate。

优先级 3：把 overlap cases 作为主回归对象

重点不应只测单一 feature，而应优先测：

fatigue × distraction overlap
distraction × impairment ambiguity
impairment suspicion + driver responsive
repeated warning ignored → responsiveness drop

优先级 4：让 ADAS/MRM 只消费动作语义，不直接消费原始标签

真正稳定的接口应该是 action_tier / mrm_eligibility_state，而不是让下游自己理解 fatigue_score、impairment_score、distraction_score。

一个更现实的判断

未来 DMS 的系统成熟度，不会主要由“多识别几个状态”决定，而会更多由下面三件事决定：

谁能把不同 driver states 放进统一 temporal persistence ladder
谁能把动作阶梯做成可解释、可回退、可恢复的状态机
谁能让 ADAS / HMI / MRM 消费统一动作语义，而不是一堆彼此竞争的标签

因此 DMS 真正需要的，不是更多状态标签，而是 unified temporal action ladder。

可直接执行的研发清单

本周可做

定义第一版 state_family / persistence_level / action_tier
梳理现有 fatigue / distraction / impairment 输出与动作的映射冲突
选 5 个 overlap case 做 ladder 回放分析

本月可做

建立 unified temporal ladder regression suite
补 response_ack_state / mrm_eligibility_state
改造 ADAS/HMI 接口为 action-tier 驱动

下一阶段必须做

将 unresponsive driver 纳入统一 ladder 而非独立 feature
将 persistence / recovery / re-entry 做成正式状态机
将 temporal ladder trace 纳入 dossier 与系统级回归资产

参考来源

AB Dynamics, Euro NCAP 2026 protocols: What does it mean for ADAS testing and development?
https://www.abdynamics.com/euro-ncap-2026-what-does-it-mean-for-adas-testing-and-development/
indie / emotion3D, Regulatory Requirements
https://www.indie.inc/regulatory-requirements/
ETSC, Euro NCAP: New 2026 protocols target distraction, impairment, and speeding
https://etsc.eu/euro-ncap-new-2026-protocols-target-distraction-impairment-and-speeding/