统一干预层工程框架-把driver-capability转成可执行动作策略

统一干预层工程框架：把 driver capability 转成可执行动作策略

发布时间： 2026-03-26
主题： driver capability / intervention layer / HMI / ADAS / MRM / 工程框架
关键词： capability model、action policy、recommended action、warning escalation、assist-ready、safety action

一句话结论

driver capability model 如果最后只是输出一串更复杂的状态分数，工程价值其实有限。

真正能落地的关键在于：

把多种驾驶风险统一映射成一套稳定、可解释、可验证的动作策略。

也就是说，系统真正要对外输出的，不该只是“你现在有多危险”，而应该是：

  • 该不该提醒
  • 提醒强度多大
  • 是否升级
  • 是否需要 ADAS 提前介入
  • 是否进入安全动作路径

这就是统一干预层（intervention layer）的价值。

1. 为什么单独功能会越来越难维护

如果疲劳、分心、认知负荷、损伤、突发疾病、接管失败都各自拥有一套独立告警逻辑，那么系统迟早会遇到：

  • HMI 冲突
  • 多个 feature 重复发声
  • 阈值体系无法统一
  • ADAS 接口混乱
  • 验证矩阵爆炸

所以真正该统一的，往往不是所有底层特征，
而是 输出动作语义。

2. 三层式工程框架

第一层：Evidence Layer

输入证据包括：

  • 眼动 / gaze / head pose
  • 眼睑 / blink / PERCLOS
  • 行为与姿态
  • 路况与 hazard 上下文
  • 生命体征 / 雷达 / 额外模态
  • 车辆动态 / 操作迟滞

这一层的目标是形成稳定证据流，不直接决定动作。

第二层：Capability Layer

把证据映射成更稳定的能力维度：

  • alertness
  • attention allocation
  • response readiness
  • cognitive spare capacity
  • impairment suspicion
  • health anomaly risk

这层输出的是“能力状态”，而不是最终动作。

第三层：Intervention Layer

将 capability 状态映射成统一动作策略：

  • Observe：记录 / 不打扰
  • Prompt：标准提醒
  • Escalate：增强提醒 / 缩短容忍窗口
  • Assist-ready：提升 ADAS / HMI 敏感度
  • Safety-action：进入 MRM / emergency path

这一层才是整个系统真正对外的标准接口。

3. 推荐的正式输出接口

统一干预层建议至少输出：

1
2
3
4
5
6
7
8
9
{
  "capability_risk": 0.81,
  "dominant_factors": ["cognitive_load", "response_delay"],
  "recommended_action": "escalate",
  "escalation_policy": "shorten_warning_window",
  "assist_ready": true,
  "time_budget_ms": 2500,
  "trace_id": "evt_..."
}

这类接口的价值是：

  • HMI 容易消费
  • ADAS 容易联动
  • 日志容易追踪
  • 验证容易建矩阵

4. 统一干预层的关键设计原则

原则 1：feature 不直接控制 HMI

所有 feature 都应先进入 intervention layer 仲裁，避免各自抢 UI。

原则 2：动作优先于标签

标签可以很多，但动作语义要尽量收敛，不然系统会越来越碎。

原则 3：允许多风险共存，但必须统一仲裁

系统应能处理：

  • 疲劳 + 认知负荷
  • 分心 + phone use
  • 损伤 + response delay

而不是每个 feature 单独拉警报。

原则 4：把时间预算纳入动作

很多风险不是“有没有”，而是“还能给驾驶员多少反应时间”。

因此 recommended action 应带时间预算，而不是纯类别。

5. HMI / ADAS / MRM 如何接这个层

HMI

根据 recommended_action 选择：

  • 弱提示
  • 强提示
  • 持续提示
  • 多模态提示

ADAS

根据 assist-ready / safety-action 选择：

  • 提高警觉
  • 缩短容忍阈值
  • 准备最小风险动作

MRM / emergency path

当 capability risk 进入高危险区间，直接进入安全动作路径。

6. 验证矩阵该怎么升级

从现在开始，更值得验证的是：

  • 某种状态组合下，动作是否正确
  • 升级是否过早或过晚
  • 多个风险共同出现时仲裁是否合理
  • 是否会造成过度打扰
  • trace_id 是否能串起完整链路

也就是从：

  • feature × accuracy

升级到：

  • state combination × action correctness × escalation timing

7. 为什么这是下一阶段的真正分水岭

未来真正有价值的系统，不一定是“多识别一种状态”的系统，
而更可能是：

更会把复杂状态转成一致动作的系统。

因为 OEM 最终买的是：

  • 更低集成复杂度
  • 更一致的人机体验
  • 更清晰的安全边界
  • 更低的验证成本
  • 更可扩展的平台

这些几乎都落在 intervention layer 上。

8. 研发优先级建议

P0：禁止 feature 直接下发 HMI 行为

P1：建设 intervention 仲裁器与 trace_id 时间线

P1：建立 state × action 验证矩阵

P2：逐步把 impairment / sickness / takeover readiness 接入同一干预层

参考资料

Euro NCAP > DMS
#DMS #OMS #CPD #Euro NCAP 2026
统一干预层工程框架-把driver-capability转成可执行动作策略
https://dapalm.com/2026/03/26/2026-03-26-统一干预层工程框架-把driver-capability转成可执行动作策略/
作者
Mars
发布于
2026年3月26日
许可协议