前言
Euro NCAP 2026 将 DMS 纳入评分体系，DMS 从”辅助功能”升级为”安全关键系统”。这意味着 DMS 软件开发必须符合 ISO 26262 功能安全标准，确保系统在失效情况下不会造成危害。
一、ISO 26262 概述
1.1 标准结构
| 部分 |
内容 |
| Part 1-3 |
管理与概念阶段 |
| Part 4 |
系统级开发 |
| Part 5 |
硬件开发 |
| Part 6 |
软件开发 |
| Part 7 |
生产与运行 |
| Part 8-10 |
支持流程 |
1.2 ASIL 等级
| ASIL |
安全完整性 |
典型应用 |
| QM |
无安全要求 |
娱乐系统 |
| ASIL-A |
最低 |
非关键控制 |
| ASIL-B |
中等 |
DMS 告警功能 |
| ASIL-C |
较高 |
ADAS 辅助 |
| ASIL-D |
最高 |
制动/转向 |
二、DMS 安全目标
2.1 危害分析与风险评估
| 危害场景 |
严重度 |
暴露度 |
可控性 |
ASIL |
| DMS 漏检疲劳 → 事故 |
S3 |
E4 |
C2 |
ASIL-B |
| DMS 误报 → 分心干扰 |
S1 |
E3 |
C3 |
QM/ASIL-A |
| DMS 失效 → 无警告 |
S2 |
E3 |
C2 |
ASIL-B |
2.2 安全目标定义
| 安全目标 |
ASIL |
说明 |
| SG-01: 正确检测疲劳 |
ASIL-B |
疲劳检测功能正常 |
| SG-02: 及时告警 |
ASIL-B |
检测后及时告警 |
| SG-03: 避免误报 |
ASIL-A |
减少错误告警 |
三、软件开发流程
3.1 V 模型开发
1
2
3
4
5
6
7
8
9
| 需求分析 ←─────────────→ 系统测试
↓ ↑
系统设计 ←─────────────→ 集成测试
↓ ↑
软件架构 ←─────────────→ 软件集成测试
↓ ↑
软件详细设计 ←─────────→ 单元测试
↓ ↑
编码 → 编码规范/代码审查
|
3.2 各阶段交付物
| 阶段 |
交付物 |
审核要求 |
| 需求分析 |
安全需求规范 |
安全评审 |
| 系统设计 |
技术安全概念 |
安全评审 |
| 软件架构 |
软件架构设计 |
架构评审 |
| 详细设计 |
详细设计文档 |
设计评审 |
| 编码 |
源代码 |
代码审查 |
| 测试 |
测试报告 |
测试评审 |
四、ASIL-B 开发要求
4.1 软件架构要求
| 要求 |
ASIL-B 具体内容 |
| 模块化 |
高内聚低耦合 |
| 接口定义 |
明确的数据流 |
| 错误处理 |
完善的异常处理 |
| 内存管理 |
避免动态分配 |
4.2 编码规范
| 规范 |
说明 |
| MISRA-C |
汽车软件编码标准 |
| CERT-C |
安全编码规范 |
| 命名规范 |
统一命名规则 |
4.3 测试要求
| 测试类型 |
覆盖率要求 |
| 单元测试 |
分支覆盖 100% |
| 集成测试 |
功能覆盖 100% |
| 系统测试 |
安全需求 100% |
| 故障注入 |
安全机制验证 |
五、安全机制设计
5.1 输入验证
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
bool validate_camera_input(camera_frame_t *frame) {
if (frame->size != EXPECTED_SIZE) {
log_error("Frame size mismatch");
return false;
}
if (frame->timestamp > current_time ||
frame->timestamp < last_frame_time) {
log_error("Invalid timestamp");
return false;
}
if (is_invalid_frame(frame)) {
log_error("Invalid frame content");
return false;
}
return true;
}
|
5.2 输出监控
1
2
3
4
5
6
7
8
9
| DMS 输出监控机制
├── 输出范围检查
│ └── 疲劳等级 ∈ [0, 100]
├── 输出频率检查
│ └── 检测频率 ≥ 10Hz
├── 合理性检查
│ └── 状态跳变不超过阈值
└── 心跳监控
└── 定期心跳信号
|
5.3 故障处理
| 故障类型 |
处理策略 |
| 摄像头故障 |
降级模式 + 告警 |
| 算法超时 |
返回安全状态 |
| 内存溢出 |
看门狗复位 |
| 通信故障 |
默认安全值 |
六、认证路径
6.1 认证流程
1
2
3
4
5
6
7
8
9
10
11
12
13
| 1. 危害分析与风险评估 (HARA)
↓
2. 功能安全概念 (FSC)
↓
3. 技术安全概念 (TSC)
↓
4. 软件安全需求 (SSR)
↓
5. 软件开发与测试
↓
6. 安全验证 (SAV)
↓
7. 功能安全评估 (FSA)
|
6.2 认证机构
| 机构 |
认证范围 |
| TÜV |
德国认证 |
| SGS |
国际认证 |
| Bureau Veritas |
国际认证 |
| CQC |
中国认证 |
6.3 认证成本
| 项目 |
预估成本 |
周期 |
| HARA |
¥10-20万 |
1-2月 |
| 软件开发流程 |
¥50-100万 |
6-12月 |
| 认证审核 |
¥30-50万 |
2-3月 |
| 总计 |
¥90-170万 |
9-17月 |
七、IMS 开发建议
7.1 安全等级划分
| 模块 |
建议 ASIL |
理由 |
| 疲劳检测核心 |
ASIL-B |
安全关键 |
| 分心检测核心 |
ASIL-B |
安全关键 |
| CPD 检测 |
ASIL-B |
安全关键 |
| 数据记录 |
QM |
非安全关键 |
| UI 显示 |
QM |
非安全关键 |
7.2 开发流程建议
| 阶段 |
建议 |
| 立项 |
明确 ASIL 目标 |
| 设计 |
安全需求分解 |
| 开发 |
遵循 MISRA-C |
| 测试 |
故障注入测试 |
| 认证 |
选择合适机构 |
7.3 工具链选择
| 工具类型 |
推荐工具 |
| 需求管理 |
DOORS / Polarion |
| 架构设计 |
EA / Cameo |
| 编码 |
VS Code + MISRA 插件 |
| 单元测试 |
Unity / CppUTest |
| 代码审查 |
SonarQube |
| 痕迹管理 |
Git + CI/CD |
总结
ISO 26262 功能安全对 DMS 开发的要求：
- ASIL-B 目标：疲劳/分心检测为核心功能
- V 模型开发：需求 → 设计 → 编码 → 测试
- MISRA-C 编码：遵循汽车软件编码标准
- 安全机制：输入验证、输出监控、故障处理
- 认证流程：HARA → FSC → TSC → SSR → SAV → FSA
IMS 开发需在项目初期明确功能安全要求，避免后期返工。
参考来源：
- ISO 26262 官方标准
- ISO 26262 Academy 指南
- CS Canada Edition 3 预览