从 feature 测试转向 action 测试：IMS 下一阶段验证矩阵该怎么搭

发布时间： 2026-03-26
主题： IMS 验证 / action test / state machine / intervention layer
关键词： validation matrix、action correctness、state combination、escalation timing、multi-risk regression

---

一句话结论

IMS 过去大量验证工作，核心都围绕：

• 检测准不准
• F1/AUC 高不高
• 单个 feature 是否鲁棒

但当系统开始走向：

• 停车态安全状态机
• 统一干预层
• HMI / ADAS / MRM 联动

真正要验证的重点也必须改变：

下一阶段最关键的，不是 feature test，而是 action test。

也就是说，系统不仅要“看对”，还要：

• 做对动作
• 在对的时间做
• 在多风险并存时仍做对

---

1. 为什么 feature test 已经不够

因为越来越多的系统失效，并不是“没识别出来”，而是：

• 识别出来了，但动作没升级
• 升级了，但时机太晚
• 多个风险同时出现，仲裁错了
• HMI 和 ADAS 动作不一致
• 通知发出去了，但不是发给对的人

这些问题用单一 feature accuracy 根本测不出来。

---

2. Action test 要测什么

我建议最少覆盖四类对象：

2.1 Action Correctness

• 当前状态下，系统选择的动作是否正确
• 是否该 observe 却 prompt 了
• 是否该 escalate 却仍停留在弱提示

2.2 Escalation Timing

• 升级是否过早
• 升级是否过晚
• snooze 结束后是否按时恢复
• 高温/高风险事件是否正确打断原时序

2.3 Multi-risk Arbitration

• 疲劳 + 认知负荷时最终动作是什么
• 分心 + phone use 是否重复提醒
• impairment suspicion + response delay 时是否进入 assist-ready

2.4 End-to-end Traceability

• evidence → capability → action → HMI/ADAS/MRM 是否能串起来
• trace_id 是否完整
• 回放时是否能还原当时决策链路

---

3. 一个更实用的验证矩阵

建议把验证从：

• feature × scenario

升级到：

• state combination × action correctness × escalation timing × channel outcome

例如：

状态组合	期望动作	时序要求	结果检查
fatigue 中等	Prompt	立即	HMI 提示出现
fatigue 高 + response delay	Escalate	<2s	HMI增强 + ADAS预备
CPD suspicion + confirmation	Initial Warning	15s内	车外提醒触发
CPD 持续 + snooze结束	Escalation Loop	90s内	重复提醒恢复
impairment suspicion 高	Assist-ready	短时窗	HMI/ADAS联动

这类矩阵更接近真实系统行为。

---

4. 两条主线的验证都应这么改

停车态安全

验证重心：

• 状态跳转是否正确
• scheduler / router 是否稳定
• 通道是否可达
• intervention 是否按时执行

统一干预层

验证重心：

• recommended_action 是否合理
• arbiter 是否处理好多风险共存
• HMI/ADAS 是否消费一致
• trace_id 是否全链路可追踪

---

5. 研发优先级建议

P0：先定义 action-level expected behavior

P0：建立 state × action regression cases

P1：把 escalation timing 纳入自动回归

P1：把 trace_id 接入日志与回放工具

---

结语

IMS 下一阶段验证真正的升级方向，不是把 feature case 做得越来越多，
而是：

把系统在复杂状态下“最终做了什么动作”当成核心被测对象。

只有这样，系统才算真正从“识别产品”走向“安全控制产品”。