一段式自动驾驶系统的功能安全如何考虑?

一段式端到端在功能安全上的核心矛盾是:ISO 26262 要求"需求可追溯、失效可定位、行为可预测",而一段式 DNN 是数据驱动的黑盒,三者天然冲突。实际工程中无法让 DNN 本身达到高 ASIL,可行的路径是**"DNN 降级 + 外部安全层升等"**的混合架构。

一、 核心矛盾

所以现实策略是:承认 DNN 本身做不到 ASIL_B/D，把它降为 QM~ASIL_A 的"功能单元",把安全责任转移到外部确定性、可解释、可独立验证的安全层上。

二、三条标准路线(并行使用)

• 路线 A — ISO 26262(系统/硬件随机失效)

仍适用,但 DNN 作为黑盒组件,FMEDA 落到功能链而非软件单元。

• 路线 B — ISO 21448 SOTIF(预期功能安全,非故障性危害)

一段式 DNN 的主要风险不是"硬件坏了",而是"没见过的场景下决策错误",这是 SOTIF 的核心战场:

• 触发条件(Trigger Conditions)识别 → 场景库 → 仿真/影子模式验证 → 数据闭环
• 这是 ISO 26262 替代不了的,必须并行做

• 路线 C — ISO/PAS 8800(2024)Road Vehicles — Safety and AI

针对 AI 系统的安全标准,DNN 全生命周期管理:数据质量、模型确认、运行时监控、在线学习更新。是把 DNN 当"AI 组件"管理的专门框架。

三、安全架构

       ┌─────────────────────────────────────────┐传感器 ─→│  传感器层(冗余/异构)                   │        └──────────────┬──────────────────────────┘                       ↓        ┌──────────────────────────────────────────┐        │  一段式 DNN 主路径(QM~ASIL_A)            │  ← 功能责任        │  传感器→方向盘/油门/刹车                  │        └──────────────┬───────────────────────────┘                       ↓ 控制候选        ┌──────────────────────────────────────────┐        │  运行时安全监控器(ASIL_B/D,确定性逻辑)   │  ← 安全责任        │  - 边界检查(物理极限)                    │        │  - 动力学可行性                          │        │  - 不确定性估计(集成/MC-Dropout 方差)    │        │  - 与先验地图/规则一致性                  │        │  - 硬件看门狗                            │        └──────────────┬───────────────────────────┘                  通过 ↓        否决 ↓                  正常执行      MRC(最小风险策略:减速、靠边、停车)

关键设计原则:

• DNN 与监控器功能独立、实现多样(不同算法、不同数据来源),满足 ISO 26262-9:2018 第 5 章的独立性要求
• 监控器必须确定性、可形式化验证,这样它才扛得起高 ASIL
• 监控器输出的故障反应路径(降级、MRC)走传统安全机制,与传统功能安全无缝衔接

四、结论

一段式端到端的功能安全实现,核心不是"让 DNN 更安全",而是"承认 DNN 不够安全,把安全责任外移到确定性的监控与冗余链路上"。两个个抓手:

1. 架构: DNN(QM)+ 运行时监控器(ASIL_D)+ 冗余/MRC 兜底
2. 标准组合: ISO 26262(随机失效)+ ISO 21448 SOTIF(预期功能不足)+ ISO/PAS 8800(AI 生命周期)