3. ISO 26262 概览
ISO 26262 是道路车辆功能安全领域的核心国际标准，它并非一份单一文档，而是由 12 个部分（Part 1～Part 12）组成的结构化标准族。理解这 12 个部分各自解决什么问题、彼此如何衔接，以及软件与硬件协同工作究竟落在哪些条款上，是开展功能安全工程的第一道门槛。很多团队在项目初期只盯着 Part 4（系统）和 Part 6（软件），结果在安全计划、安全论证和分布式开发接口上反复返工，根源就在于没有把标准当成一个整体来看。
一、核心原理：12 个部分的分层结构
ISO 26262 的 12 个部分可以按“总纲—概念—开发—支持—专用—指南”六个层次来理解。Part 1 是词汇，统一术语；Part 2 是功能安全管理，规定组织级和项目级的安全管理要求；Part 3 是概念阶段，输出相关项定义、危害分析与风险评估（HARA）以及安全目标；Part 4 到 Part 7 是产品开发主体，分别覆盖系统、硬件、软件和生产运行；Part 8 是支持过程，包括分布式开发接口、变更管理、配置管理、验证确认等；Part 9 是 ASIL 导向与安全分析；Part 10 是指南；Part 11 是半导体应用指南；Part 12 是摩托车专用要求。
这 12 个部分不是并列关系，而是“纵向贯穿、横向支撑”的矩阵。Part 3 的安全目标向下分解到 Part 4 的系统架构，再进一步分解到 Part 5 的硬件和 Part 6 的软件；Part 8 的支持过程横向服务于所有开发阶段；Part 9 的安全分析方法贯穿 HARA、系统设计和软硬件设计；Part 11 则为芯片级开发提供补充解释。
二、方法流程：从安全目标到软硬件需求的分解路径
标准的核心工作流可以概括为一条“自上而下分解、自下而上验证”的链条。Part 3 通过 HARA 确定 ASIL 等级和安全目标，随后导出功能安全概念（FSC）。Part 4 将 FSC 细化为技术安全概念（TSC），并分配到系统架构元素上，形成技术安全需求（TSR）。TSR 再分别流向 Part 5 和 Part 6，转化为硬件安全需求和软件安全需求。
在硬件侧，Part 5 要求计算单点故障度量（SPFM）、潜伏故障度量（LFM）和随机硬件失效概率度量（PMHF），以证明硬件架构满足对应 ASIL 的量化目标。在软件侧，Part 6 要求建立软件安全需求、软件架构，并按照 ASIL 等级选择相应的设计原则和测试方法。两者最终在 Part 4 的系统集成阶段汇合，通过系统级测试验证安全目标是否达成。
软硬件协同的关键接口：硬件提供的安全机制（如看门狗、ECC、锁步核、电压监控）必须由软件正确配置、周期性检测和响应；软件的安全机制（如程序流监控、内存保护、双通道比较）又依赖硬件资源实现。Part 4 的 TSR 分配表就是软硬件协同的“合同”，它明确了每条安全需求由硬件、软件还是两者共同承担。
三、案例/场景：一个 EPS 项目的标准落地
以电动助力转向（EPS）为例。Part 3 的 HARA 识别出“非预期助力扭矩”危害，评定为 ASIL D，安全目标为“避免非预期助力扭矩导致车辆失控”。Part 4 将安全目标分解为 TSR，例如“扭矩传感器信号应具备冗余校验”“电机驱动应具备独立关断路径”。
其中“扭矩传感器冗余校验”被分配给硬件和软件共同实现：硬件提供双路传感器信号采集通道，软件执行信号范围检查、相关性比较和故障响应。硬件侧需要计算 SPFM 以证明单点故障覆盖充分；软件侧需要按照 ASIL D 要求采用防御性编程、程序流监控和独立看门狗。Part 8 则规定供应商与整车厂之间的分布式开发接口（DIA），明确双方在需求、验证和变更上的责任边界。
四、误区与复盘
- 误区一：只做 Part 6 软件，忽略 Part 5 硬件。ASIL D 项目中硬件随机失效度量不达标，软件再完善也无法通过安全论证。
- 误区二：把 Part 8 当成“文档工作”。分布式开发接口、变更管理和配置管理直接决定安全需求在供应链上是否可追溯。
- 误区三：安全分析只在 Part 3 做一次。Part 9 要求安全分析贯穿系统、硬件和软件设计，并随设计迭代更新。
- 误区四：软硬件需求分配模糊。TSR 未明确软硬件责任边界，导致集成阶段出现“双方都以为对方实现”的真空地带。
五、12 个部分速查清单
| 部分 | 名称 | 核心作用 | 与软硬件协同的关系 |
|---|---|---|---|
| Part 1 | 词汇 | 统一术语定义 | 协同沟通的基础语言 |
| Part 2 | 功能安全管理 | 组织与项目级安全管理 | 定义安全文化、角色与职责 |
| Part 3 | 概念阶段 | HARA、安全目标、FSC | 确定 ASIL，决定软硬件投入强度 |
| Part 4 | 系统级开发 | TSR、系统架构、集成测试 | 软硬件需求分配的核心枢纽 |
| Part 5 | 硬件级开发 | 硬件安全需求、架构度量 | 提供硬件安全机制与量化证据 |
| Part 6 | 软件级开发 | 软件安全需求、架构、测试 | 实现软件安全机制与诊断响应 |
| Part 7 | 生产运行 | 生产、服务、报废 | 保证量产一致性 |
| Part 8 | 支持过程 | DIA、变更、配置、验证 | 支撑软硬件协同的可追溯性 |
| Part 9 | 安全分析 | ASIL导向、FMEA、FTA | 验证软硬件安全机制有效性 |
| Part 10 | 指南 | 补充解释与示例 | 帮助理解协同条款 |
| Part 11 | 半导体指南 | 芯片级安全机制 | 硬件安全的基础层 |
| Part 12 | 摩托车 | 摩托车专用要求 | 特定场景的补充 |
学习建议：先通读 Part 1、Part 2、Part 3 和 Part 4，建立“安全目标—技术安全需求—软硬件需求”的主干；再深入 Part 5 和 Part 6 理解各自的方法论；最后用 Part 8 和 Part 9 检查协同接口和安全分析是否闭环。Part 10、Part 11、Part 12 作为参考手册按需查阅即可。
把 12 个部分看成一张互相咬合的网，而不是 12 份独立文档，才能真正理解 ISO 26262 对软硬件协同安全工程的要求。Part 4 是分配中枢，Part 5 和 Part 6 是执行双翼，Part 8 和 Part 9 是支撑与验证，Part 3 则是所有工作的起点。只有这条链条完整贯通，安全目标才能从概念落到可运行、可验证的产品上。