ISO 26262 整体综述：汽车功能安全的完整体系

引言

在汽车电子化、智能化迅猛发展的今天，一辆现代汽车可能包含上百个电子控制单元（ECU），数千行软件代码，以及复杂的传感器和执行器网络。当这些系统失效时，后果可能是灾难性的。这就是为什么 ISO 26262——道路车辆功能安全标准——成为汽车行业的圣经。

ISO 26262 不是一本简单的操作手册，而是一个完整的体系，包含 12 个相互关联的标准文件。这 12 个文件就像乐高积木，每个都有其特定的功能和位置，只有将它们正确地组合在一起，才能构建出功能安全的汽车电子系统。

在本系列文章中，我们已经深入解读了 ISO 26262 的每一个部分。在本文中，我们将从整体视角审视这个标准，理解它们如何协同工作，形成一个完整的汽车功能安全体系。

ISO 26262 的诞生与演进

为什么需要功能安全标准？

在 ISO 26262 诞生之前，汽车行业使用的是 IEC 61508——通用的功能安全标准。然而，汽车电子有其特殊性：

1. 安全性要求高：汽车故障可能导致人员伤亡
2. 成本敏感：汽车是大宗消费品，必须控制成本
3. 供应链复杂：涉及 OEM、Tier 1、Tier 2、半导体供应商等多方
4. 使用环境苛刻：温度、湿度、振动、电磁干扰等

因此，ISO 于 2011 年发布了专门针对道路车辆的 ISO 26262 标准，并于 2018 年进行了全面更新（第二版）。

标准的总体目标

ISO 26262 的核心目标可以用一句话概括：

确保电子电气系统在发生故障时，不会导致不合理的安全风险

这个目标分解为三个关键要素：

1. 预防性开发：通过系统化的开发过程，预防系统性故障
2. 故障控制：通过安全机制，检测和控制随机硬件故障
3. 全生命周期管理：从概念到报废的全程安全管理

与 IEC 61508 的关系

ISO 26262 是 IEC 61508 在汽车领域的应用和裁剪，两者关系如下：

ISO 26262 的 12 个部分：全景图

ISO 26262 分为 12 个部分，每个部分都有其特定的职责和范围：

各部分的核心内容与关联

Part 1: 词汇——基础语言

简要介绍：ISO 26262-1 词汇 定义了整个标准使用的术语和概念，包括功能安全、ASIL、安全目标、故障模型等核心术语。

在体系中的作用：作为其他所有部分的基础，确保全行业使用统一的语言进行沟通。

关键术语回顾：

• ASIL：汽车安全完整性等级（A, B, C, D）
• 功能安全：不存在因 E/E 系统故障导致的不合理风险
• 安全目标：顶层安全要求
• 单点故障：直接导致安全目标违反的故障

Part 2: 功能安全管理——组织与文化

简要介绍：ISO 26262-2 功能安全管理 建立了从组织层面到项目层面的完整管理框架，强调安全文化的重要性。

在体系中的作用：为整个安全生命周期提供管理保障，确保安全要求得到系统化实施。

关键要点：

• 安全文化是功能安全的基石
• 明确的角色和职责（安全总监、安全经理、安全工程师）
• 安全计划和安全档案的管理
• 变更管理和供应商管理

实践案例：丰田召回事件的教训——没有良好的安全文化，再好的技术也难以保证安全。

Part 3: 概念阶段——安全之源

简要介绍：ISO 26262-3 概念阶段 定义了危害分析和风险评估（HARA）方法，确定安全目标和 ASIL 等级。

在体系中的作用：作为整个安全生命周期的起点，ASIL 等级在此确定，后续所有开发活动都基于此等级。

核心活动：

1. 项目定义：描述系统的功能、交互、法律要求
2. 危害分析：识别所有潜在危害
3. 风险评估：评估严重性（S）、暴露率（E）、可控性（C）
4. ASIL 确定：基于 S、E、C 矩阵确定 ASIL 等级
5. 功能安全概念：定义功能安全需求

实践案例：制动系统 HARA 分析——将制动失效定为 ASIL C/D，要求高安全等级。

Part 4: 系统级开发——架构桥梁

简要介绍：ISO 26262-4 系统级开发 将概念阶段的输出转化为技术安全概念，设计系统架构，协调硬件和软件开发。

在体系中的作用：承上启下，连接概念阶段和具体实现，确保系统架构满足安全要求。

关键活动：

1. 技术安全概念：定义技术实现方案
2. 系统架构设计：设计 E/E 系统结构
3. 软硬件接口（HSI）：定义硬件和软件的交互
4. 系统集成：将硬件和软件组合成系统
5. 系统测试：验证技术安全需求

实践案例：AEB 系统的架构设计——采用三模冗余架构，可靠度从 99% 提升到 99.97%。

Part 5: 硬件级开发——量化指标

简要介绍：ISO 26262-5 硬件级开发 定义了硬件开发的量化指标和方法，包括 FMEDA 分析和硬件架构指标。

在体系中的作用：通过量化指标（SPFM、LFM、PMHF）评估硬件安全能力，确保满足 ASIL 要求。

核心指标：

核心方法：

• FMEDA 分析：失效模式、影响及诊断分析
• 诊断覆盖率：评估安全机制检测故障的能力

实践案例：BMS 系统 FMEDA 分析——计算单点故障度量 99.2%，满足 ASIL C 要求。

Part 6: 软件级开发——编码规范

简要介绍：ISO 26262-6 软件级开发 定义了软件开发的严格要求，包括架构设计、编码规范和测试方法。

在体系中的作用：确保软件满足安全需求，通过规范化的开发过程预防软件错误。

关键活动：

1. 软件架构设计：分层设计、模块化
2. 编码规范：MISRA C、AUTOSAR C++14
3. 单元测试：测试覆盖率要求（ASIL D: 100% MC/DC）
4. 集成测试：软件组件集成
5. 静态分析：代码质量检查

实践案例：AEB 系统软件——三模冗余决策算法，确保任一通道故障不影响安全。

Part 7: 生产和运行——持续安全

简要介绍：ISO 26262-7 生产和运行 确保功能安全要求在生产、运营、服务和报废阶段得到维持。

在体系中的作用：完成安全生命周期的闭环，确保生产一致性和现场运行安全。

关键活动：

• 生产一致性：确保生产过程维持安全完整性
• 过程能力（Cpk）：量化生产过程能力
• 服务手册：安全维护和维修程序
• 运行监控：跟踪现场安全事件
• 软件更新：安全更新流程

实践案例：生产 Cpk ≥ 1.33 的要求，确保关键特性满足规格。

Part 8: 支持过程——基础设施

简要介绍：ISO 26262-8 支持过程 提供支持所有开发阶段的基础设施，包括配置管理、文档管理和工具置信度评估。

在体系中的作用：为整个安全生命周期提供工具和过程支持，确保开发活动的可控性和可追溯性。

关键过程：

1. 配置管理：版本控制、变更管理
2. 文档管理：追溯性、完整性
3. 工具置信度评估：TCL 1-4 级评估

实践案例：TÜV SÜD 认证的代码静态分析工具，可用于 ASIL D 开发。

Part 9: ASIL 导向的分析——深度分析

简要介绍：ISO 26262-9 ASIL 导向分析 提供了 ASIL 分解、FMEA、FTA 等分析方法。

在体系中的作用：支持 ASIL 等级的管理和优化，通过分析提高系统安全性。

核心方法：

1. ASIL 分解：高 ASIL 降级为低 ASIL 元素 $$ \text{ASIL D} \to \text{ASIL C + ASIL A} $$
2. FMEA 分析：风险优先数（RPN）计算 $$ \text{RPN} = S \times O \times D $$
3. FTA 分析：故障树定量分析
4. STPA 分析：系统理论过程分析

实践案例：AEB 系统 ASIL D 分析——识别单点故障，引入冗余机制。

Part 10: 指南——实践参考

简要介绍：ISO 26262-10 指南 提供了解释、示例和最佳实践，帮助理解标准要求。

在体系中的作用：作为指导性文档，补充 Parts 1-9 的要求，提供实际应用示例。

主要内容：

• 各阶段的具体示例
• 常见问题解答
• 最佳实践建议
• SEooC 开发指南

Part 11: 半导体——IC 特殊要求

简要介绍：ISO 26262-11 半导体 专门针对半导体组件的开发和应用提供指南。

在体系中的作用：满足汽车 IC 开发的特殊要求，适配半导体行业的特点。

特殊考虑：

• IP 核安全分析：软 IP、硬 IP 的安全评估
• SoC 安全分析：片上系统的综合分析
• 半导体 FMEDA：IC 特定的失效模式分析
• 软错误：瞬态故障的评估

实践案例：汽车级 SoC 的软错误分析——FIT 率 100，满足 ASIL D 要求。

Part 12: 摩托车——两轮车的适配

简要介绍：ISO 26262-12 摩托车 专门针对摩托车调整了 ISO 26262 的要求。

在体系中的作用：适配两轮车的特殊特性，包括动力学差异、使用场景差异。

特殊考虑：

• 摩托车特定危害：侧翻、摆动、跳跳
• 可控性评估：摩托车特有评估方法
• MSIL 等级：摩托车安全完整性等级

实践案例：电动踏板车——针对两轮车的特殊安全机制。

安全生命周期：V 模型详解

ISO 26262 采用经典的 V 模型作为安全生命周期的框架。让我们从整体视角理解这个模型。

V 模型的左侧（设计和规划）

第0阶段：安全计划（Part 2）
│
├─ 项目定义
├─ 组织架构
└─ 资源计划
│
第1阶段：概念阶段（Part 3）
│
├─ 危害分析（HARA）
├─ ASIL 确定
└─ 功能安全概念
│
第2阶段：系统级设计（Part 4）
│
├─ 技术安全概念
├─ 系统架构
└─ 软硬件接口
│
第3阶段：硬件设计（Part 5）和 软件设计（Part 6）
│
├─ 硬件安全需求
├─ 软件安全需求
├─ FMEDA 分析
└─ 软件架构

V 模型的右侧（实现和验证）

V 模型的支撑（Part 8）

ASIL 等级体系：风险驱动的分类

ASIL 的确定矩阵

ISO 26262 的核心创新之一是 **ASIL（汽车安全完整性等级）**体系。ASIL 等级基于三个维度的评估：

ASIL 确定矩阵

ASIL 等级的要求差异

典型系统的 ASIL 分配

高 ASIL 系统（ASIL C/D）

典型应用：

• 安全气囊系统（ASIL D）
• 制动系统（ABS, ESP）（ASIL D）
• 转向系统（ASIL C/D）
• 动力系统（ASIL C/D）

案例：安全气囊系统

• 危害：气囊意外展开或展开失败
• 严重性：S3（致命）
• 暴露率：E4（每次驾驶都可能碰撞）
• 可控性：C3（不可控）
• ASIL D

中 ASIL 系统（ASIL B/C）

典型应用：

• 发动机控制（ASIL C）
• 照明系统（ASIL B）
• 座椅调节（ASIL B）
• 车窗控制（ASIL A）

案例：发动机控制

• 危害：发动机失控
• 严重性：S2（严重）
• 暴露率：E4（每次驾驶）
• 可控性：C2（正常可控）
• ASIL C

低 ASIL 系统（ASIL A）

典型应用：

• 仪表显示（ASIL A）
• 倒车雷达（ASIL A）
• 信息娱乐系统（QM）

案例：仪表显示

• 危害：错误信息误导
• 严重性：S1（轻微）
• 暴露率：E4（每次驾驶）
• 可控性：C1（简单可控）
• ASIL A

安全机制：检测与控制故障

安全机制的分类

ISO 26262 要求系统采用多种安全机制来检测和控制故障。

1. 故障检测机制

看门狗定时器：

• 最常见的安全机制
• 检测软件死锁、死循环
• ASIL C/D 要求外部看门狗

奇偶校验和 ECC：

• 检测存储器错误
• ECC 可以纠正单位错误

心跳监测：

• 检测处理器运行状态
• 定期发送心跳信号

2. 故障容错机制

冗余架构：

• 双通道冗余：容忍一个通道故障
• 三模冗余（TMR）：容忍一个通道故障

投票机制：

• 多个冗余单元输出进行投票
• 少数服从多数原则

3. 故障响应机制

安全状态切换：

• 检测到故障后进入安全状态
• 例如：制动系统降级为纯机械制动

报警机制：

• 通过仪表盘、声音等方式报警
• 提醒驾驶员采取行动

实战案例：三模冗余的可靠性分析

假设单个控制器的可靠度为 $R = 0.99$。

三模冗余系统的可靠度： $$ R_{\text{TMR}} = R^3 + 3 \times R^2 \times (1-R) $$

代入数值： $$ R_{\text{TMR}} = 0.99^3 + 3 \times 0.99^2 \times 0.01 = 0.999702 $$

结论：通过三模冗余，可靠度从 99% 提升到 99.97%。

实战案例：特斯拉 Model S 电池管理系统

让我们通过一个真实案例，理解 ISO 26262 各部分如何协同工作。

1. 概念阶段（Part 3）

项目定义：

• 电池管理系统（BMS）监控和管理高压电池组
• 功能：电压监控、温度监控、SOC 估算、均衡管理

危害分析（HARA）：

安全目标：

1. 防止热失控（ASIL D）
2. 防止过充电（ASIL C）
3. 防止放电过深（ASIL B）

2. 系统设计（Part 4）

技术安全概念：

• 主 BMS 控制器 + 冗余监控控制器
• 双通道 CAN 通信
• 硬件切断开关（接触器）

系统架构：

电池组 → 传感器 → 主 BMS (ASIL D) → CAN 总线 → 整车控制
                ↓
             冗余监控 (ASIL C)
                ↓
             接触器控制

3. 硬件开发（Part 5）

硬件安全需求：

• 电压监测精度：±5mV
• 温度监测精度：±1°C
• 诊断覆盖率：≥99%（满足 ASIL D）

FMEDA 分析：

• 单点故障度量（SPFM）：99.2%
• 潜伏故障度量（LFM）：91.5%
• 平均概率危害失效率（PMHF）：8.5 FIT

硬件架构：

• 专用的电池管理芯片（BMS IC）
• 独立的电压和温度监测通道
• 硬件过流保护

4. 软件开发（Part 6）

软件安全需求：

1. 每 10ms 读取一次电压和温度
2. 检测到异常，在 100ms 内断开接触器
3. 软件故障时自动重启

软件架构：

应用层
├─ SOC 估算算法
├─ 均衡控制
└─ 安全监测层
    ├─ 过压监测
    ├─ 欠压监测
    └─ 过温监测

测试：

• 单元测试覆盖率：MC/DC 100%（ASIL D）
• 集成测试：HIL 测试
• 故障注入测试：注入各种故障，验证响应

5. 支持过程（Part 8）

配置管理：

• 使用 Git 进行版本控制
• 每个需求都有唯一 ID
• 追溯矩阵：需求 → 设计 → 测试用例

工具置信度评估：

• 编译器：GCC（TCL 2）
• 静态分析工具：Coverity（TCL 3，已通过 TÜV 认证）
• 测试工具：Vector Test（TCL 2）

6. 生产（Part 7）

生产一致性：

• 每个电池包进行 EOL（End of Line）测试
• 关键特性 Cpk ≥ 1.33
• 校准数据存储在 ECU 中

服务：

• 软件更新通过 OTA（Over-The-Air）
• 更新过程确保安全：
  1. 下载验证（加密签名）
  2. 安装前备份
  3. 安装后验证
  4. 失败则回滚

运行监控：

• 收集电池包故障数据
• 定期分析，发现设计改进机会

学习 ISO 26262 的建议路径

初学者路径

如果你是功能安全的新手，建议按照以下顺序学习：

1. Part 1: 词汇（2-3天）

   • 掌握基本术语
   • 理解 ASIL、安全目标等核心概念

2. Part 2: 功能安全管理（3-5天）

   • 理解安全文化的重要性
   • 掌握安全计划和安全档案

3. Part 3: 概念阶段（5-7天）

   • 学习 HARA 方法
   • 练习 ASIL 确定

4. Part 10: 指南（3-5天）

   • 看示例，加深理解

进阶开发者路径

如果你是汽车电子开发者，建议：

1. Part 4: 系统级开发（7-10天）

   • 掌握技术安全概念
   • 理解系统架构设计

2. Part 5/6: 硬件/软件开发（10-15天）

   • 学习 FMEDA 分析
   • 掌握硬件/软件架构指标
   • 练习测试方法

3. Part 9: ASIL 导向分析（5-7天）

   • 学习 FMEA、FTA 方法
   • 理解 ASIL 分解

高级专家路径

如果你是功能安全专家或架构师：

1. Part 7: 生产和运行（3-5天）

   • 理解生产一致性
   • 掌握运行监控

2. Part 8: 支持过程（3-5天）

   • 学习配置管理
   • 掌握工具置信度评估

3. Part 11/12: 半导体/摩托车（3-5天）

   • 理解特殊领域的适配

综合应用

在掌握了所有部分后，通过实际项目综合应用：

1. 选择一个实际的汽车电子系统（如 EPS、ABS、BMS）
2. 从 Part 3 开始，完成完整的 HARA
3. 按照 Parts 4-6 的要求，完成系统、硬件、软件设计
4. 进行 FMEA、FTA 分析
5. 编写完整的测试计划和报告
6. 最终形成安全档案

常见误区与最佳实践

常见误区

误区 1：功能安全就是多做一些测试

真相：功能安全是全生命周期的系统工程，包括需求分析、架构设计、开发过程、测试验证等多个环节。测试只是其中的一个部分。

误区 2：ASIL D 的系统不需要 ASIL A/B 的部分

真相：ASIL D 的系统可能包含多个子系统，其中一些子系统可能是 ASIL A 或 ASIL B。需要通过 ASIL 分解和依赖性分析管理不同等级的共存。

误区 3：硬件满足指标就足够了

真相：硬件指标（SPFM、LFM、PMHF）只是硬件安全能力的量化指标，还需要考虑软件、系统架构、安全机制等多个方面。

误区 4：工具置信度评估不重要

真相：工具置信度评估确保开发工具本身不会引入错误，对于 ASIL C/D 的项目，使用未评估的工具可能导致严重的系统性错误。

最佳实践

1. 建立强大的安全文化

• 最高管理层的承诺是关键
• 鼓励透明的问题报告
• 定期安全培训和意识提升

2. 采用增量式 ASIL 方法

• 不要一开始就追求 ASIL D
• 从 ASIL A/B 开始，积累经验
• 逐步提升能力，承担更高 ASIL 项目

3. 注重文档和追溯性

• 每个决策都有依据
• 每个需求都能追溯到测试用例
• 使用专业工具（DOORS、Codebeamer 等）管理需求

4. 持续改进

• 从现场事故中学习
• 定期更新安全档案
• 优化开发流程

5. 充分利用工具和自动化

• 静态分析工具：Coverity、Polyspace
• 测试工具：Vector Test、LabVIEW
• 需求管理工具：DOORS、Codebeamer
• 配置管理工具：Git、SVN

未来展望

ISO 26262 的演进

ISO 26262 标准在不断演进，未来可能的发展方向：

1. 与 SOTIF 的集成

   • SOTIF（ISO 21448）关注可预见的误用
   • 未来可能与 ISO 26262 更好地融合

2. 支持自动驾驶

   • 更高 ASIL 等级的需求
   • 人工智能的功能安全

3. 网络安全融合

   • 功能安全和网络安全越来越相关
   • ISO 21434（汽车网络安全）的集成

4. 半导体标准的细化

   • Part 11 可能进一步细化
   • 更明确的 IC 开发要求

新技术带来的挑战

1. 人工智能

   • 如何评估 AI 模型的安全性
   • 如何量化 AI 的故障概率

2. OTA 更新

   • 如何保证更新的安全性
   • 如何追踪历史版本

3. 域控制器和中央计算

   • 复杂架构的安全分析
   • 多 ASIL 元素的共存

4. 电动汽车特有功能

   • 高压安全
   • 热管理安全

总结

ISO 26262 是一个完整的、系统的、量化的功能安全标准。通过本文和系列文章的深入解读，我们理解了：

1. 标准的整体架构：12 个部分相互关联，形成完整的体系

2. 安全生命周期：从概念到报废的全程管理

3. ASIL 等级体系：风险驱动的分类方法

4. 各部分的核心内容：

   • Part 1: 词汇基础
   • Part 2: 安全文化和管理
   • Part 3: 概念分析和 ASIL 确定
   • Part 4: 系统架构
   • Part 5/6: 硬件和软件开发
   • Part 7: 生产和服务
   • Part 8: 支持过程
   • Part 9: 分析方法
   • Part 10-12: 指南和特殊领域

5. 实战应用：通过特斯拉 BMS 案例，理解标准的实际应用

6. 学习路径：提供了初学者、进阶、专家的学习建议

核心要点：

• 功能安全是系统工程，不仅仅是技术问题
• 安全文化是功能安全的基石
• ASIL 等级是风险驱动的，决定了所有后续要求
• 量化指标（SPFM、LFM、PMHF）是硬件安全的核心
• 文档和追溯性是功能安全的关键证据
• 持续改进是功能安全的本质

掌握 ISO 26262，不仅是为了通过认证，更是为了真正提升汽车电子系统的安全性，保护生命财产安全。希望这个系列文章能帮助你全面理解和应用 ISO 26262 标准。

延伸阅读

本系列文章完整覆盖了 ISO 26262 的所有 12 个部分，你可以根据需要深入阅读：

• ISO 26262-1: 词汇
• ISO 26262-2: 功能安全管理
• ISO 26262-3: 概念阶段
• ISO 26262-4: 系统级开发
• ISO 26262-5: 硬件级开发
• ISO 26262-6: 软件级开发
• ISO 26262-7: 生产和运行
• ISO 26262-8: 支持过程
• ISO 26262-9: ASIL 导向分析
• ISO 26262-10: 指南
• ISO 26262-11: 半导体
• ISO 26262-12: 摩托车