3、ISO 26262标准概览：标准各部分内容、适用范围、与IEC 61508的关系
ISO 26262《道路车辆——功能安全》是全球汽车行业功能安全领域的核心标准，其前身可追溯至工业领域的功能安全基础标准IEC 61508。理解ISO 26262的整体架构、适用范围及其与IEC 61508的渊源，是开展任何功能安全活动的起点。本章将系统梳理标准的12个部分（Part 1~Part 12）各自的内容定位、标准适用的产品与系统边界，并深入剖析ISO 26262作为IEC 61508在道路车辆领域的行业化裁剪，二者在管理框架、技术要求和安全生命周期上的继承与差异。
3.1 ISO 26262标准的整体架构与各部分内容
3.1.1 标准各部分的核心定位
ISO 26262:2018版共分为12个部分，每个部分对应功能安全生命周期中的一个特定领域或视角。理解各部分之间的逻辑关系，是高效使用标准的前提。标准并非按时间顺序线性排列，而是围绕安全生命周期、管理框架、技术开发、支持过程四条主线展开。
| 部分 | 标题 | 核心内容 | 关键输出物 |
|---|---|---|---|
| Part 1 | 术语 | 统一标准中使用的技术术语和定义 | 术语表、缩略语 |
| Part 2 | 功能安全管理 | 组织级和项目级安全管理要求，包括安全文化、角色职责、评审与评估 | 安全计划、安全案例、评审报告 |
| Part 3 | 概念阶段 | 项目定义、HARA分析、功能安全概念（FSC） | HARA报告、安全目标、功能安全概念 |
| Part 4 | 系统级开发 | 技术安全概念（TSC）、系统架构设计、集成与测试 | 技术安全需求、系统验证报告 |
| Part 5 | 硬件级开发 | 硬件设计、硬件架构度量、随机硬件失效评估 | 硬件安全需求、FMEDA报告、硬件集成测试 |
| Part 6 | 软件级开发 | 软件安全需求、软件架构设计、单元/集成测试 | 软件安全需求规格、软件测试报告 |
| Part 7 | 生产与运行 | 生产过程中的安全相关特性控制、运行维护与报废 | 生产控制计划、运行维护手册 |
| Part 8 | 支持过程 | 分布式开发、需求管理、配置管理、变更管理、验证、文档化、工具可信度 | 配置管理计划、工具鉴定报告 |
| Part 9 | ASIL导向分析 | ASIL分解、安全相关性与冗余分析、ASIL能力评估 | ASIL分解方案、相关性分析报告 |
| Part 10 | ISO 26262指南 | 对标准的整体解释、示例和补充说明 | 应用指南文档 |
| Part 11 | 半导体指南 | 半导体器件（IC、FPGA、ASIC）的功能安全开发指南 | 半导体安全案例、IP安全评估 |
| Part 12 | 摩托车适用性 | 针对摩托车（L类车辆）的裁剪与调整 | 摩托车安全计划、HARA调整 |
3.1.2 各部分之间的逻辑关系
从工程实践角度看，Part 2（管理）是贯穿整个生命周期的“骨架”，Part 3至Part 7是“血肉”即技术开发主线，Part 8和Part 9是“韧带”即支持性过程与分析方法，Part 10至Part 12则是“辅助工具”即指南与行业裁剪。这种结构设计使得标准既能覆盖完整的安全生命周期，又能灵活适应不同开发场景。
3.2 ISO 26262的适用范围与对象
3.2.1 适用车辆类型与系统边界
ISO 26262:2018版明确其适用范围为“安装在最大总质量不超过3500 kg的量产乘用车上的E/E（电气/电子）系统”。2018年第二版将范围扩展至摩托车（L类）、卡车、巴士等商用车，并新增了半导体器件（Part 11）的专项指南。需要注意的是，标准并不直接适用于非E/E系统（如纯机械制动拉索），但当机械系统与E/E系统交互并可能影响安全功能时，机械部分也应纳入分析范围。
3.2.2 适用对象与组织角色
标准的适用对象不仅限于整车厂（OEM），还包括各级供应商、半导体厂商、工具提供商、独立安全评估机构等。每个组织在安全生命周期中承担不同角色，但都必须遵循相应的管理要求和技术要求。例如，半导体IP提供商需要按照Part 11的要求开发IP，而系统集成商则需要验证IP在目标应用中的安全性。
3.2.3 适用生命周期阶段
ISO 26262覆盖从概念阶段到报废的完整生命周期，包括：概念阶段（Part 3）、系统开发（Part 4）、硬件开发（Part 5）、软件开发（Part 6）、生产与运行（Part 7）。这种全生命周期覆盖意味着功能安全不是一次性的设计活动，而是持续的过程管理。例如，在生产阶段需要控制安全相关特性的工艺参数，在运行阶段需要监控安全功能的实际表现并反馈改进。
3.3 ISO 26262与IEC 61508的关系
3.3.1 IEC 61508的基础地位
IEC 61508是功能安全的“母标准”，由国际电工委员会（IEC）于1998年发布，2010年修订为第二版。它提供了通用的功能安全框架，适用于所有行业，包括工业过程控制、机械、医疗、轨道交通等。IEC 61508的核心概念包括：安全生命周期、安全完整性等级（SIL）、危险与风险分析、安全功能分配等。
3.3.2 ISO 26262对IEC 61508的继承与裁剪
ISO 26262在制定时充分借鉴了IEC 61508的框架，但针对汽车行业的特点进行了大量裁剪和深化。两者的关系可以概括为“继承框架、深化方法、调整指标、增加行业特色”。
| 对比维度 | IEC 61508 | ISO 26262 | 差异说明 |
|---|---|---|---|
| 安全完整性等级 | SIL 1~4 | ASIL A~D | ASIL D对应SIL 3+，但增加了汽车特有的暴露度、可控性维度 |
| 风险分析 | 通用风险矩阵 | HARA（危害分析与风险评估） | HARA引入S（严重度）、E（暴露度）、C（可控性）三维评估 |
| 安全生命周期 | 16个阶段 | 概念→开发→生产→运行 | ISO 26262更强调概念阶段和ASIL分解 |
| 硬件失效度量 | PFH/PFD指标 | SPFM、LFM、PMHF | ISO 26262引入单点故障度量（SPFM）和潜伏故障度量（LFM） |
| 软件安全要求 | 通用软件安全生命周期 | 基于ASIL的软件安全要求分级 | ISO 26262对软件架构、单元测试、集成测试有更细粒度要求 |
| 管理要求 | 功能安全管理 | Part 2 功能安全管理 | ISO 26262增加安全文化、分布式开发管理、安全案例要求 |
| 行业特定指南 | 无 | Part 11（半导体）、Part 12（摩托车） | ISO 26262针对汽车子行业提供专项指南 |
3.3.3 从SIL到ASIL的映射逻辑
在IEC 61508中，SIL的确定主要基于风险频率和后果严重度的组合。而ISO 26262的ASIL确定则引入了三个独立参数：S（Severity，严重度）、E（Exposure，暴露度）、C（Controllability，可控性）。每个参数分为0~3级，三者组合后映射到ASIL A~D或QM（Quality Management，仅需质量管理）。这种映射逻辑更贴合汽车驾驶场景，例如：一个危害事件即使严重度很高（S3），但如果驾驶员完全可控（C1）且暴露概率极低（E1），仍可能被评定为QM或ASIL A。
3.4 案例拆解：从IEC 61508到ISO 26262的转换实践
3.4.1 案例背景与初始目标
某汽车电子供应商（以下简称A公司）长期为工业领域提供安全继电器模块，产品基于IEC 61508开发，已获得SIL 2认证。现A公司计划将该产品线拓展至汽车市场，目标应用为电动汽车的电池管理系统（BMS）中的高压互锁回路（HVIL）检测功能。A公司需要评估现有产品开发流程和设计是否能满足ISO 26262的要求，并制定转换计划。
3.4.2 初始状态与差距分析
A公司现有的开发流程基于IEC 61508，主要差距体现在以下方面：
- 风险分析方法：IEC 61508使用通用风险矩阵，而ISO 26262要求进行HARA分析，需要重新定义车辆运行场景、驾驶工况和驾驶员可控性。
- 安全完整性指标：SIL 2对应的硬件失效度量（PFH）与ASIL B对应的SPFM/LFM/PMHF指标不同，需要重新计算。
- 文档体系：ISO 26262要求输出安全计划、安全案例、HARA报告、功能安全概念等特定文档，A公司现有文档模板不匹配。
- 工具链：ISO 26262 Part 8要求对软件工具进行可信度评估（Tool Confidence Level），A公司使用的部分开发工具未做过评估。
3.4.3 转换实施步骤
- 建立项目安全计划：按照ISO 26262 Part 2要求，制定项目安全计划，明确安全活动、时间表、职责分工。
- 执行HARA分析：针对HVIL检测功能，定义车辆运行场景（如充电、行驶、碰撞后），评估S、E、C参数，确定ASIL等级。经分析，HVIL检测功能被评定为ASIL B。
- 重新设计硬件架构：根据ASIL B要求，计算SPFM≥90%、LFM≥60%、PMHF≤100 FIT。原设计使用单通道继电器+MCU检测，经FMEDA分析后，SPFM仅为82%，不满足要求。增加冗余检测路径（双通道比较）后，SPFM提升至94%。
- 更新软件安全需求：按照ASIL B的软件要求，增加软件架构设计中的错误检测与处理机制，并补充单元测试和集成测试的覆盖率要求。
- 工具评估与鉴定：对使用的编译器、静态分析工具进行工具可信度评估，其中编译器被评定为TCL 2，需要增加额外的验证措施。
- 编制安全案例：汇总所有安全活动证据，编制完整的安全案例，提交独立评估机构审查。
3.4.4 结果对比与复盘
转换完成后，A公司产品成功获得ISO 26262 ASIL B认证，并进入某OEM的BMS供应链。整个转换周期耗时约8个月，其中HARA分析和硬件架构重新设计占据了60%的工作量。复盘经验表明：
- 早期差距分析越充分，后期返工越少；建议在项目启动前进行详细的差距评估。
- HARA分析需要跨职能团队（系统、安全、整车、售后）共同参与，单靠安全工程师难以覆盖所有场景。
- 硬件失效度量（SPFM/LFM）的计算需要精确的失效率数据，建议尽早与元器件供应商确认数据来源。
3.5 常见误区与注意事项
3.5.1 误区一：认为ISO 26262仅适用于“安全关键”系统
实际上，ISO 26262要求对所有E/E系统进行危害分析，即使最终评定为QM（仅需质量管理），也需要执行HARA分析并记录评定过程。不能因为“这个功能不涉及安全”就跳过分析，因为“是否涉及安全”恰恰需要通过分析来确定。
3.5.2 误区二：混淆ASIL与SIL的对应关系
ASIL D并不等同于SIL 4，ASIL B也不等同于SIL 2。两者的风险模型、度量指标、开发要求均有差异。在跨行业合作或供应链沟通中，必须明确使用正确的术语和指标。
3.5.3 误区三：忽视Part 8支持过程的重要性
许多项目团队将精力集中在Part 3~Part 6的技术开发上，而忽视了Part 8中的配置管理、变更管理、需求管理、工具可信度等支持过程。实际上，这些支持过程是确保技术开发结果可追溯、可验证、可维护的基础。没有有效的配置管理，安全案例的证据链将无法建立。
3.5.4 误区四：认为ISO 26262是“一次性认证”
ISO 26262要求在整个生命周期中持续维护安全案例。任何变更（设计变更、元器件变更、生产流程变更）都可能影响安全完整性，需要重新评估。认证不是终点，而是持续安全管理的起点。