引言
ISO 26262 是汽车电子的功能安全标准，2011 年首版，2018 年第二版扩展到摩托车并把范围从乘用车放宽到所有道路车辆。它的核心逻辑很清晰：先识别「什么危险」，再评估「危险多严重」，据此定「安全等级（ASIL）」，最后用相应强度的手段把风险降到可接受水平。
功能安全的难点不在标准条文（条文是清晰的），而在「如何证明做到了」。它要求全生命周期的追溯链：从危害 → 安全目标 → 功能安全需求 → 技术安全需求 → 实现 → 验证证据，每一环都要可追溯。这不是「写文档」，而是「让安全可论证」。
对软件工程师而言，26262 意味着具体约束：语言子集（MISRA C）、无动态内存、覆盖率要求（ASIL D 要求 MC/DC 100%）、安全机制（看门狗、E2E、锁步核）、以及严格的变更管理。这些约束会显著增加工作量，但正是「确定性」的代价。本文按工程落地顺序拆解。
目录
- ISO 26262 概览与 ASIL 分级
- 危害分析与风险评估 HARA
- 安全目标与功能安全概念
- 技术安全需求与架构设计
- 安全机制：看门狗、锁步核与 E2E
- 软件安全开发与度量
- 安全分析 FMEA 与 FTA
- 验证确认与安全案例
- SOTIF 预期功能安全
1. ISO 26262 概览与 ASIL 分级
26262 覆盖从概念到报废的全生命周期，分 12 个部分：
Part 1 词汇
Part 2 功能安全管理
Part 3 概念阶段（HARA、安全目标）
Part 4 系统层开发（技术安全需求）
Part 5 硬件层开发
Part 6 软件层开发
Part 7 生产与运行
Part 8 支持过程（配置管理、变更管理）
Part 9 ASIL 导向与安全分析
Part 10 指南
Part 11 半导体应用
Part 12 摩托车
ASIL 分级（Automotive Safety Integrity Level）：
ASIL A：最低（如后视镜调节）
ASIL B
ASIL C
ASIL D：最高（如制动、转向、安全气囊）
QM：非安全相关（Quality Management）
由三个维度决定：
S（Severity，严重度）：S0~S3
E（Exposure，暴露度）：E0~E4
C（Controllability，可控性）：C0~C3
组合映射到 ASIL：
S3 + E4 + C3 → ASIL D
S1 + E1 + C1 → ASIL A
含 S0/E0/C0 或 S1+E1+C1 以下 → QM
ASIL 等级直接决定开发强度：ASIL D 要求最严格的覆盖率、最完整的安全机制、最高的诊断覆盖率（硬件 SPFM ≥ 99%、LFM ≥ 90%）。
2. 危害分析与风险评估 HARA
HARA 是功能安全的起点，输出安全目标：
HARA 步骤：
1. 定义 Item（待分析的系统，如电子驻车制动）
2. 定义功能（Function）与故障行为
3. 识别 Malfunction（故障行为导致的危害）
如「EPB 意外释放」→ 车辆溜车
4. 评估 S / E / C
5. 得出 ASIL
6. 定义安全目标（Safety Goal）
示例（EPB 意外释放）：
危害：车辆在坡道驻车时意外释放制动
S3：可能造成人员伤亡
E4：驻车是常见场景（高暴露）
C3：驾驶员几乎无法控制（不可控）
→ ASIL D
安全目标：
「EPB 不应在未收到驾驶员指令时释放」
ASIL D
FTTI（故障容忍时间间隔）：200 ms
← 从故障发生到必须被处理的时限
FTTI 是关键概念：它把「安全」翻译成「时间预算」，后续设计都要在 FTTI 内完成故障检测与响应。
3. 安全目标与功能安全概念
安全目标（SG）分解为功能安全概念（FSC），再分解为技术安全概念（TSC）：
分解层次：
安全目标（SG）
↓ 分配
功能安全需求（FSR）
↓ 分配
技术安全需求（TSR）
↓ 分配
硬件/软件安全需求（HSR/SSR）
示例（EPB）：
SG: EPB 不应意外释放（ASIL D）
FSR1: 系统应检测 EPB 控制器的失效
FSR2: 检测到失效时，系统应保持制动
FSR3: 系统应检测驾驶员意图
TSR1: 用双通道监控电磁阀驱动电流
TSR2: 失效时切断电磁阀供电（保持制动）
TSR3: 驾驶员指令需经 E2E 保护与合理性校验
分解原则：
一个 ASIL D 需求可分解为两个 ASIL B(D) 需求
（带 ASIL 分解标记，需满足独立性）
分解降低单个组件的开发强度，但要求独立性论证
需求的可追溯性是评审重点：每条 TSR 都要能追溯到 FSR，再追溯到 SG。
4. 技术安全需求与架构设计
技术安全架构决定安全机制如何落地：
架构模式：
1. 双通道（Dual Channel）
两个独立通道计算，比较结果
一致才执行，不一致则安全状态
用于 ASIL D（如线控转向）
2. 监控通道（Monitor Channel）
主通道执行，监控通道检查
监控更简单、更可信（用不同实现）
如主 CPU + 安全监控芯片
3. 多样化冗余（Diverse Redundancy）
两个通道用不同算法/硬件实现
避免共因失效（common cause failure）
4. 降级（Degradation）
失效时进入降级模式而非完全关闭
如 EPS 助力失效 → 保留机械转向
示例（线控转向 ASIL D）：
主 MCU：AURIX TC3xx 锁步核，计算转向角
监控：独立 MCU 检查主 MCU 输出
通信：E2E 保护转向指令
电源：双路供电
失效：进入安全状态（保持当前转向或机械备份）
5. 安全机制：看门狗、锁步核与 E2E
三类基础安全机制：
看门狗（Watchdog）：
外部看门狗（Window Watchdog）：
应用必须在一定时间窗内喂狗
太早喂（程序跑飞）或太晚喂（程序卡死）都触发复位
ASIL D 用外部看门狗芯片（独立时钟源）
内部看门狗：
MCU 内置，成本低，独立性弱
程序流监控：
用挑战-应答（Question-Answer）机制
看门狗问一个随机问题，程序必须答对
答对说明程序逻辑正常（不只是没卡死）
锁步核（Lockstep）：
两个 CPU 核执行相同指令，比较输出
延迟 1~2 周期比较，不一致则报错
AURIX 的锁步核延迟 2 周期
覆盖瞬态与永久故障（用 DCLS 延迟锁步）
不能覆盖共因失效（同一时钟、同一电源）
E2E 保护（End-to-End）：
数据在传输前后加 CRC + 计数器 + 数据 ID
接收端校验，检测损坏、丢失、重复、乱序
详见车载中间件一章
三类机制的诊断覆盖率不同：锁步核覆盖 CPU 故障，看门狗覆盖程序流，E2E 覆盖通信。
6. 软件安全开发与度量
Part 6 对软件开发有具体约束：
语言与编码：
MISRA C:2012（ASIL D 强制）
- 禁动态内存（malloc/free）
- 禁递归
- 禁 goto（受限）
- 强制类型、边界检查
C++ 用 MISRA C++ 或 AUTOSAR C++14
度量指标：
圈复杂度（Cyclomatic Complexity）：每函数 ≤ 10（ASIL D）
函数长度：建议 ≤ 50 行
静态分析：零阻断告警
覆盖率（Part 6 Table 12）：
ASIL D：
语句覆盖 100%
分支覆盖 100%
MC/DC（修正条件/判定覆盖）100%
ASIL B：
语句 + 分支覆盖 100%
ASIL A：
语句覆盖 100%
MC/DC 是最难达标的：
要求每个条件的独立影响被测试
`if (a && b)` 需要 3 个用例覆盖
工具：VectorCAST、Cantata、CTC++
防御性编程：
输入合理性检查
范围检查
冗余计算与交叉校验
默认安全（fail-safe）
MC/DC 100% 是 ASIL D 软件最大的工作量来源，往往需要专门设计测试用例。
7. 安全分析 FMEA 与 FTA
两类分析从不同方向逼近安全：
FMEA（Failure Mode and Effects Analysis）：
自底向上：从组件失效推影响
分析每个组件的失效模式 → 局部影响 → 系统影响
输出：RPN（风险优先数）= 严重度 × 发生度 × 检测度
改进：降低高 RPN 项
FTA（Fault Tree Analysis）：
自顶向下：从顶事件推原因
顶事件（如「制动失效」）→ 逻辑门 → 基本事件
输出：最小割集（导致顶事件的最小组合）
定量：计算顶事件概率
FMEDA（Failure Modes, Effects and Diagnostic Analysis）：
硬件层的定量分析
计算 SPFM（单点故障度量）与 LFM（潜伏故障度量）
ASIL D 要求：
SPFM ≥ 99%
LFM ≥ 90%
PMHF（随机硬件失效概率）< 10^-8 /h
这些指标要求每个硬件组件的失效率（FIT）与诊断覆盖率
由芯片厂商提供安全手册（Safety Manual）
8. 验证确认与安全案例
安全案例（Safety Case）是论证「系统足够安全」的完整证据链：
安全案例结构（GSN，Goal Structuring Notation）：
G1: 系统满足安全目标（顶层）
├─ G2: 安全需求已正确实现
│ ├─ E1: 需求追溯矩阵
│ ├─ E2: 测试报告
│ └─ E3: 静态分析报告
├─ G3: 安全机制有效
│ ├─ E4: FMEA 报告
│ └─ E5: 故障注入测试
└─ G4: 过程合规
├─ E6: 配置管理记录
└─ E7: 工具认证
验证与确认（V&V）：
验证（Verification）：产品做对了吗？（符合需求规格）
确认（Validation）：做对的产品了吗？（满足实际用途）
手段：单元测试、集成测试、HIL、实车、故障注入
故障注入（Fault Injection）：
主动注入故障验证安全机制
如：翻转内存位、断开信号、延迟消息
验证安全机制能在 FTTI 内响应
独立评估（Assessment）：
ASIL D 通常需第三方独立评估
评估员检查过程与证据
9. SOTIF 预期功能安全
SOTIF（ISO 21448）处理「功能正常但性能不足」的风险，是 26262 的补充：
26262 vs SOTIF：
26262：失效导致的风险（东西坏了）
SOTIF：无失效但性能不足导致的风险（东西没坏但不够好）
例：摄像头没坏，但雨天识别不出行人
→ 不是失效，是性能边界
→ SOTIF 范畴
SOTIF 的核心概念：
场景四象限：
区域 1：已知安全场景
区域 2：已知不安全场景（测试覆盖）
区域 3：未知不安全场景（危险，需减少）
区域 4：未知安全场景（需转化为已知）
目标：
减少区域 2 与区域 3（通过测试与设计）
把区域 4 转化为区域 1
SOTIF 流程：
1. 功能与场景定义
2. 危害识别（性能局限导致的）
3. 风险评估
4. 功能改进（算法、传感器融合、降级）
5. 验证（海量场景测试）
验证方法：
场景库（Scenario Database）
仿真测试（百万公里虚拟里程）
封闭场地测试
实车路测（SOTIF 要求累计里程）
SOTIF 对 ADAS/AD 尤其重要，感知的边界场景（corner case）是核心挑战。
权衡取舍
| 决策点 | 选项 A | 选项 B | 建议 |
|---|---|---|---|
| 架构冗余 | 双通道 | 监控通道 | ASIL D 用双通道，ASIL B 用监控 |
| 看门狗 | 内部 | 外部 | ASIL C/D 用外部看门狗芯片 |
| 覆盖率 | MC/DC 100% | 分支 100% | ASIL D 强制 MC/DC，ASIL B 分支即可 |
| 分解 | 不分解 | ASIL 分解 | 分解降低单件强度，但需独立性论证 |
| 分析 | FMEA | FTA | 两者结合，FMEA 查漏、FTA 定顶事件 |
| 验证 | 仿真 | 实车 | 仿真覆盖广，实车验证真实性，结合使用 |
常见坑清单
- 安全活动后置：开发完再补安全分析，需求已冻结，返工巨大，必须贯穿全流程。
- FTTI 未定义：没有时间预算，安全机制响应时间无法验证，先定 FTTI 再设计。
- 分解未论证独立性：两个 ASIL B 需求共享同一实现，分解无效，需独立性证据。
- MC/DC 事后补测：代码写死无法覆盖，需在设计时就考虑可测试性。
- 安全机制未验证：只看设计文档，未做故障注入，实际不生效。
- 共因失效忽视：双通道共享时钟/电源，同时失效，需多样化设计。
- 芯片安全手册未用：忽略 FIT 与诊断覆盖率数据，FMEDA 无法计算。
- 变更未走安全流程：小改动引入新风险，所有变更需安全影响评估。
- SOTIF 当 26262 处理：性能不足不是失效，分析框架不同，需分别处理。
- 安全案例堆文档：证据之间无逻辑链，评估时无法论证，用 GSN 组织。
小结
ISO 26262 的本质是「把安全变成可论证的工程」：从 HARA 识别危害，定 ASIL 与安全目标，分解为技术需求，用安全机制实现，最后用安全案例把证据串成链。对软件工程师，它意味着具体约束——MISRA、无动态内存、MC/DC 覆盖、看门狗与 E2E。
实践路径：先理解 ASIL 分级与 HARA，再学安全需求分解，然后掌握三类安全机制（看门狗、锁步、E2E），最后接触安全案例与 SOTIF。安全机制的实现细节见 AUTOSAR Classic 平台与 RTE ；E2E 保护见 SOME/IP 与车载中间件 ；刷写的安全合规见 车载 OTA 升级与安全 。
ADAS 的 SOTIF 落地见 ADAS 感知一章；若关注整体安全体系与网络安全的交叉，可参考 车载网络安全加固 。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。