DMS-ADAS 深度协同：从独立告警到最小风险机动链路

前言

传统 DMS 只能”告警”驾驶员，无法”干预”。

Euro NCAP 2026 提出的无响应驾驶员干预要求，本质上是：

DMS 必须与 ADAS 深度协同，形成从”检测→告警→增强→干预→停车的完整链条。

这不是单一功能的升级，而是系统架构的重构。

一、DSS：DMS 输出的标准化接口

1.1 为什么需要 DSS

传统架构问题：

DMS 模块 ─┐
│ 眼动追踪 │
│ 疲劳检测 │
│ 分心检测 │
└─────┘
  │ 仅告警输出（声音/视觉）
  │ 无法传递结构化状态
  ↓
ADAS 控制器 ─┐
│ ACC │ LKA │ AEB │ APA
└─────┘
  │ 不了解驾驶员状态
  │ 只能"被动"执行

问题： ADAS 不知道”为什么”要增强辅助灵敏度，无法做出最优决策。

1.2 DSS 协议设计

字段	类型	说明	示例
state_code	enum	驾驶员状态	0=正常/1=疲劳/2=分心/3=认知分心/4=无响应/5=医疗紧急/6=醉酒
confidence	float	0.0-1.0	0.85 表示 85% 置信度
timestamp	uint64	毫秒级时间戳	1712345678900
driver_id	string	驾驶员标识	“driver_001”
intervention_level	enum	建议干预等级	0=无/1=警告/2=增强辅助/3=最小风险机动
gaze_region	enum	注视区域	0=道路/1=左侧/2=右侧/3=仪表/4=车外
head_pose	struct	头部姿态	pitch/roll/yaw
response_latency	float	警告响应延迟（毫秒）	250

更新频率： ≥10 Hz（满足 ADAS 实时控制需求）

1.3 DSS 消息格式

{
  "header": {
    "version": 1.0,
    "timestamp": 1712345678900,
    "sender_id": "dms_module_001"
  },
  "payload": {
    "driver_id": "driver_001",
    "state_code": 4,
    "confidence": 0.92,
    "intervention_level": 2,
    "gaze_region": 0,
    "head_pose": {"pitch": 0.0, "roll": 0.0, "yaw": 0.0},
    "response_latency": 180
  }
}

二、DMS-ADAS 信息流架构

2.1 分层架构

┌──────────────────────────────────────────────┐
│               DMS 模块                      │
│ 眼动追踪 │ 头姿估计 │ 疲劳检测 │ 分心检测 │ 响应检测        │
└──────────────────────────────────────────────┘
                    ↓ 输出结构化 DSS
         ┌────────────────────────────────────┐
         │     DSS 信号 (DSS Signal)           │
         │   - 状态码
         │   - 置信度
         │   - 建议干预等级
         │   - 注视区域
         │   - 头部姿态
         │   - 响应延迟
         └────────────────────────────────────┘
                           ↓ 标准化输出
         ┌──────────────────────────────────┐
         │      ADAS 控制器                   │
         │   - 接收 DSS 消息                │
         │   - 根据状态码调整参数            │
         │   - 执行 ADAS 功能                │
         │   - 反馈车辆状态                  │
         └──────────────────────────────────┘

2.2 总线协议选择

协议	特点	适用场景
CAN FD	低延迟、可靠	DSS 信号优先
Ethernet (SOME/IP）	高带宽、复杂数据	图像传输
FlexRay	高可靠性、确定性	安全关键功能

推荐： 对于 DSS 信号，CAN FD 足够；对于复杂数据（图像/点云），使用 Ethernet。

三、最小风险机动（MRM）策略

3.1 MRM 定义

最小风险机动（Minimum Risk Maneuver, MRM）是指：

当驾驶员无法接管车辆时，系统自动执行的安全停车策略。

3.2 MRM 执行流程

阶段	系统行为	时间窗口
1. 状态检测	DMS 检测无响应	0s
2. 升级警告	视觉+声音+触觉告警	0-5s
3. 辅助增强	提高 ACC/LKA 灵敏度	5-10s
4. 减速停车	开始减速、寻找安全停车点	10s+
5. 安全停车	停车、开启双闪、解锁车门	30s 内
6. 紧急呼叫	自动拨打紧急电话	停车后

3.3 停车策略选择

场景	停车策略
高速公路	减速至停车、保持车道、开启双闪
城市道路	减速、靠边停车、开启双闪
隧道/桥梁	减速更早、尽快驶出危险区域后停车
恶劣天气	减速更早、停车更稳、开启双闪

3.4 与 L3 自动驾驶关系

L3 自动驾驶要求车辆具备 MRM 能力：

| SAE 等级 | 驾驶员角色 | MRM 要求 |
|———-|————|———-|——–|
| L2 | 必须监控 | 无强制要求 |
| L3 | 接管请求后接管 | 必须有 MRM |
| L4 | 无需监控 | 更完善的 MRM |

启示： 满足 Euro NCAP 2026 MRM 要求的系统，可以复用到 L3 自动驾驶。

四、接管时间预算（TOTB）计算

4.1 TOTB 定义

接管时间预算（Take-Over Time Budget, TOTB）是指：

从系统发出接管请求，到驾驶员实际接管，系统需要预留的时间。

4.2 DMS 对 TOTB 的贡献

DMS 信号	TOTB 估计贡献
眼动追踪	判断驾驶员是否在监控道路
头姿估计	判断驾驶员头部姿态是否正常
响应延迟	判断驾驶员反应速度
警告响应	判断驾驶员是否对警告有反应

动态 TOTB 策略：

IF 眼动正常 AND 头姿朝前 AND 响应延迟 <300ms
THEN TOTB = 4s
ELSE IF 眼动正常 AND 头姿朝前 AND 响应延迟 300-500ms
THEN TOTB = 8s
ELSE IF 轻度疲劳 OR 眼动异常 OR 头姿异常
THEN TOTB = 15s + MRM 准备
ELSE IF 无响应
THEN 立即触发 MRM

4.3 环境因素影响

五、DMS-ADAS 协同场景

5.1 场景 1：高速公路稳定巡航

场景描述： 驾驶员疲劳度低，道路稳定，ACC 开启。

系统行为	DMS	ADAS
状态检测	检测轻中度疲劳	ACC 保持正常设置
DSS 输出	intervention_level=1（警告）	不干预 ACC 参数
增强策略	-	提高跟车距离灵敏度

5.2 场景 2：检测到无响应

场景描述： 驾驶员突然失去意识（医疗紧急/极端醉酒）。

系统行为	DMS	ADAS
状态检测	检测无响应（state_code=4）	intervention_level=3（MRM）
DSS 输出	confidence>0.9	立即触发 MRM 流程
增强策略	-	全系统能力进入 MRM 模式
停车执行	-	自动执行减速、停车、呼叫

5.3 场景 3：认知分心 + 道路风险

场景描述： 驾驶员认知分心，同时道路变复杂（拥堵/施工）。

系统行为	DMS	ADAS
状态检测	检测认知分心（state_code=3）	intervention_level=2（增强）
DSS 输出	gaze_region=0（看路）但 confidence 中等	提高 ACC 跟车距离、LKA 灵敏度
增强策略	-	提前预警、车道保持增强

六、技术实现要点

6.1 DMS 端

功能	技术要点
多信号融合	眼动 + 头姿 + 眨眼 + 响应延迟
状态估计机	LSTM/Transformer 时序模型
置信度校准	在线学习、驾驶员自适应
DSS 编码	结构化 JSON、支持 CAN FD/Ethernet
响应延迟测量	时间戳对比、实时计算

6.2 ADAS 端

功能	技术要点
DSS 解码	JSON 解析、状态机实现
参数动态调整	根据 state_code/intervention_level
功能级控制	独立功能开关（ACC 增强可关/开）
车辆状态反馈	实时速度、方向盘转角、油门状态

6.3 功能安全设计

功能	ASIL 等级
DMS 检测	ASIL-B
DSS 输出	ASIL-B
MRM 触发	ASIL-D
停车执行	ASIL-D

七、对 IMS 开发的直接启示

启示 1：DMS 必须输出结构化状态信号

不能只输出”报警”，需要输出”状态码+置信度”
需要定义与 ADAS 的标准接口
需要保证信号实时性和可靠性

启示 2：DSS 是 DMS 与 ADAS 协同的核心接口

定义了标准化的驾驶员状态描述
支持多模块集成
支持 ASIL-D 功能安全设计

启示 3：MRM 需要 DMS 和 ADAS 深度协同

DMS 负责”判断什么时候触发”
ADAS 负责”如何执行安全停车”
需要 OEM 层面的系统架构支持

启示 4：TOTB 动态估计是优化接管体验的关键

DMS 需要实时估计驾驶员接管能力
需要融合多种信号（眼动、头姿、响应延迟）
需要考虑环境因素（道路复杂度、天气）

八、开发优先级建议

优先级	任务	说明
P0	定义 DSS 接口协议	与 ADAS 团队协同
P0	无响应检测算法	多信号融合
P1	警告响应检测	设计测试场景
P1	MRM 触发逻辑	状态机设计
P2	功能安全评估	ASIL 分解
P2	冗余设计	根据成本权衡

九、结论

DMS-ADAS 深度协同是 Euro NCAP 2026 最具系统性的新功能，其核心不在于 DMS 单一模块的升级，而在于 DMS 与 ADAS 的系统级协同。

对于 IMS 开发团队：

短期任务：实现 DSS 协议 + 无响应检测 + 分级警告
中期任务：与 ADAS 对接 DSS 接口
长期任务：参与 MRM 系统设计与验证

这不仅是 DMS 的功能扩展，更是 IMS 在智能驾驶系统中定位升级的关键一步。

参考资料

Euro NCAP 2026 Assessment Protocols - Driver Monitoring.
SAE J3016 - Levels of Driving Automation.
CarADAS, Understanding ADAS: Driver Monitoring Systems, 2025-12-22.

技术路线分析 > IMS开发

#Euro NCAP #DMS-ADAS融合 #最小风险机动 #协同 #DSS #CAN FD

DMS-ADAS 深度协同：从独立告警到最小风险机动链路

https://dapalm.com/2026/03/12/2026-03-12-DMS-ADAS深度协同：从独立告警到最小风险机动链路/

作者

Mars

发布于

2026年3月12日

许可协议

安全带错误佩戴检测：从简单检测到深度学习方案的演进上一篇

自适应约束系统：Euro NCAP 2026 如何重塑乘员保护逻辑下一篇