1. ISO26262 概述：功能安全背景、标准体系结构与 ASIL 等级定义
大家好，我是你们这门课的老朋友。咱们今天正式开篇，聊聊 ISO26262 到底是个啥。
说实话，我最早接触功能安全那会儿，这标准还没现在这么火。当时我在一家 Tier 1 做电控系统，客户突然要求我们提供“安全证据”，我整个人是懵的。后来才明白，原来汽车电子已经不再是“代码能跑就行”的时代了。
1.1 功能安全背景：为什么我们需要它？
先问个问题：你开车时，敢不敢把方向盘完全交给电脑？
不敢，对吧？因为系统一旦失效，后果可能是致命的。这就是功能安全要解决的问题——当系统发生故障时，它不能伤害人。
核心定义：功能安全是指不存在由电子/电气系统故障行为导致的不可接受风险。说白了，就是系统要“坏得起”，不能一坏就出人命。
我经历过一个项目，客户抱怨刹车踏板偶尔会“咯噔”一下。排查到最后，发现是软件里一个变量溢出，导致助力电机瞬间反向输出。嗯，这种问题如果不从设计源头控制，测试阶段根本测不完。
所以，功能安全不是“加个冗余”那么简单。它是一套从需求、设计、验证到生产的完整方法论。ISO26262 就是这套方法论的集大成者。
1.2 ISO26262 标准体系结构：它长什么样？
ISO26262 的体系结构，我习惯把它想象成一棵大树。树根是管理，树干是流程，树枝是产品开发，树叶是具体方法。
标准一共分为 12 个部分（Part 1 ~ Part 12），但咱们实战最常用的是前 9 部分：
| 部分 | 标题 | 核心内容 |
|---|---|---|
| Part 1 | 词汇 | 术语定义，统一语言 |
| Part 2 | 功能安全管理 | 项目计划、评审、配置管理 |
| Part 3 | 概念阶段 | HARA、安全目标定义 |
| Part 4 | 系统级开发 | 系统架构、FMEA、FTI |
| Part 5 | 硬件级开发 | 硬件设计、FMEDA、随机硬件失效 |
| Part 6 | 软件级开发 | 软件架构、单元测试、覆盖率 |
| Part 7 | 生产与运行 | 制造、维护、报废 |
| Part 8 | 支持过程 | 工具置信度、配置管理、变更管理 |
| Part 9 | ASIL 导向分析 | ASIL 分解、安全分析 |
你想想看，这 9 个部分其实覆盖了一个产品从“概念”到“报废”的全生命周期。我见过很多团队只盯着 Part 6（软件）做，结果系统级安全分析一塌糊涂，最后评审被怼得哑口无言。
我的建议：刚开始学 ISO26262，别急着看细节。先把 Part 3（概念阶段）和 Part 9（ASIL 分解）吃透。这两个是“定调子”的，调子定歪了，后面全白干。
下面这张图，是我自己总结的 ISO26262 核心流程框架，你一看就明白：
1.3 ASIL 等级定义与分解原则
ASIL，全称 Automotive Safety Integrity Level，汽车安全完整性等级。它是 ISO26262 的灵魂。
ASIL 分为四个等级：A、B、C、D。D 是最严格的，A 是最宽松的。另外还有一个 QM（Quality Management），表示仅需质量管理，无需功能安全措施。
怎么定级？标准给出了三个参数：
- Severity (S)：伤害严重度。分 S0（无伤害）到 S3（致命）。
- Exposure (E)：暴露概率。分 E0（几乎不暴露）到 E4（高概率）。
- Controllability (C)：驾驶员可控性。分 C0（完全可控）到 C3（几乎不可控）。
三个参数组合，查表得到 ASIL 等级。举个例子：
实例：电动助力转向系统（EPS）完全失效。S=3（可能致命），E=3（行驶中高概率），C=3（驾驶员几乎无法控制）。查表 → ASIL D。
定完 ASIL 之后，还有一个非常重要的概念——ASIL 分解。
为什么要分解？因为有时候一个 ASIL D 的要求太高，单个组件很难实现。我们可以把它分解到多个冗余通道上，每个通道承担一部分安全要求。
分解原则很简单：
- ASIL D 可以分解为：ASIL C(D) + ASIL A(D)，或者 ASIL B(D) + ASIL B(D)。
- ASIL C 可以分解为：ASIL B(C) + ASIL A(C)。
- ASIL B 可以分解为：ASIL A(B) + ASIL A(B)。
- ASIL A 不能分解。
括号里的字母表示原始等级，括号外是分解后的要求。我举个例子：
| 原始 ASIL | 分解方案 1 | 分解方案 2 |
|---|---|---|
| ASIL D | ASIL C(D) + ASIL A(D) | ASIL B(D) + ASIL B(D) |
| ASIL C | ASIL B(C) + ASIL A(C) | — |
| ASIL B | ASIL A(B) + ASIL A(B) | — |
| ASIL A | 不可分解 | |
注意：分解不是“降级”。分解后的每个通道必须独立，不能有共因失效。我曾经见过一个团队把 ASIL D 分解成两个 ASIL B，结果两个通道用了同一个传感器——嗯，评审直接被判无效。
我个人习惯，在做系统架构时，先画一个安全架构图，标出每个组件的 ASIL 等级。然后问自己：如果这个组件失效，另一个能兜住吗？如果兜不住，说明分解不成立。
好了，这一章的内容就到这里。记住三个关键词：背景、结构、ASIL。后面我们会一步步深入，从 HARA 开始，带你走完整个实战流程。