1. 功能安全基础：ISO26262标准概述、功能安全概念、ASIL等级定义、硬件开发流程总览
1.1 为什么我们需要功能安全？
先聊个我亲身经历的事。几年前我参与一个ADAS摄像头项目，路测时车辆突然误刹车。查了三天，发现是电源管理芯片的电压监测模块在特定温度下输出错误信号。你说这算不算安全风险？当然算。但如果没有一套标准流程，这种问题大概率会被当作“偶发软件bug”处理掉。
功能安全的核心就一句话：当系统出故障时，它不能伤人。不是保证系统永远不出错——那不可能——而是保证出错后的行为是可预测、可接受的。
功能安全的本质：不是防止故障发生，而是控制故障后果。
1.2 ISO26262到底在管什么？
ISO26262是汽车电子系统的功能安全标准。它脱胎于工业领域的IEC61508，但针对汽车做了大量定制。说白了，它是一套“如何把安全做进芯片和系统里”的方法论。
标准分11个部分，从管理、开发、生产到运维全覆盖。但对我们硬件工程师来说，最核心的是第5部分（硬件开发）和第4部分（系统级开发）。
| 部分 | 内容 | 硬件工程师关注度 |
|---|---|---|
| Part 1 | 词汇表 | 中 |
| Part 2 | 功能安全管理 | 低 |
| Part 3 | 概念阶段 | 中 |
| Part 4 | 系统级开发 | 高 |
| Part 5 | 硬件开发 | 最高 |
| Part 6 | 软件开发 | 低 |
| Part 7 | 生产与运维 | 低 |
| Part 8-11 | 支持流程、ASIL、半导体指南等 | 高 |
我的习惯：做硬件设计时，Part 5和Part 11（半导体指南）必须打印出来放在桌上。Part 11专门讲芯片级功能安全，很多细节Part 5没覆盖到。
1.3 ASIL等级——你的系统有多“要命”？
ASIL（Automotive Safety Integrity Level）是ISO26262的核心概念。它把安全风险分成四个等级：ASIL A、B、C、D，外加一个QM（质量管理级）。
怎么定级？看三个维度：
- Severity（严重度）：故障导致人员受伤的程度
- Exposure（暴露率）：故障场景发生的概率
- Controllability（可控性）：驾驶员能否避免伤害
举个例子。安全气囊的误爆——严重度S3（致命伤），暴露率E4（随时可能），可控性C3（驾驶员无法控制）。三个维度组合下来，妥妥的ASIL D。
而一个车窗升降电机，最坏情况也就是夹一下手，严重度S1，暴露率E2，可控性C2，大概率是ASIL A甚至QM。
| 等级 | 典型系统 | 硬件失效率目标（FIT） | 开发严格度 |
|---|---|---|---|
| QM | 信息娱乐、车内灯 | 无硬性要求 | 低 |
| ASIL A | 尾灯、门锁 | < 1000 FIT | 中低 |
| ASIL B | 刹车灯、雨刮 | < 100 FIT | 中 |
| ASIL C | ACC自适应巡航 | < 100 FIT | 高 |
| ASIL D | EPS转向、线控制动 | < 10 FIT | 最高 |
避坑指南：我曾经见过一个团队把EPS转向系统定成ASIL B，理由是“我们有机械备份”。结果评审时被安全专家怼回来——EPS失效时驾驶员根本打不动方向盘，可控性C3，必须ASIL D。ASIL定级不能靠“我觉得”，必须走正式的HARA（危害分析与风险评估）。
1.4 硬件开发流程总览——从概念到量产
ISO26262的硬件开发流程，我习惯把它分成五个阶段。你想想看，做一块安全芯片，跟做普通芯片最大的区别在哪？
普通芯片：功能对了就行。
安全芯片：功能对了只是起点，你还得证明“它坏了也不会出事”。
这五个阶段就是：
- 硬件安全需求定义：从系统级安全目标分解到硬件安全需求
- 硬件设计：架构设计、详细设计、安全机制植入
- 硬件安全分析：FMEA、FTA、DFA——找漏洞、算失效率
- 硬件集成与测试：验证安全机制是否生效
- 安全案例编制：把所有证据打包，给评审专家看
下面这张图是我自己画的标准流程，每次做新项目都贴在白板上。
1.5 硬件安全需求——别写废话
很多新手写安全需求，上来就是“系统应保证安全”。这种需求没法验证，评审时直接被退回。
好的硬件安全需求长什么样？我举个例子：
Hw-SR-001：当主电源电压低于2.7V时，看门狗必须在5ms内输出复位信号。
- 关联安全目标：SG-01（防止MCU在欠压下误动作）
- ASIL等级：ASIL B
- 验证方法：测试 + 仿真看到了吗？可量化、可测试、可追溯。每个需求都要能回答三个问题：
- 什么条件下触发？
- 什么时间内响应？
- 输出什么结果？
我的习惯：用Excel管理硬件安全需求，每一条都带唯一编号、ASIL等级、验证方法、关联安全目标。项目后期做追溯矩阵时，你会感谢自己当初的“强迫症”。
1.6 硬件设计——安全机制不是“加个看门狗”那么简单
硬件设计阶段，核心任务是植入安全机制。常见的安全机制包括：
- 冗余：双核锁步、三模冗余
- 监控：电压监测、温度监测、时钟监测
- 自检：LBIST、MBIST
- 错误处理：ECC、CRC、奇偶校验
但要注意，安全机制本身也会失效。你想想看，如果一个电压监测器自己坏了，它还能正确报告欠压吗？所以安全机制也需要被监控——这就是所谓的“诊断覆盖率”概念。
避坑指南：我曾经在一个项目中，给ADC加了一个自检模式，但自检只覆盖了30%的电路。评审时安全专家问：“剩下70%怎么办？” 嗯，从那以后我设计安全机制时，一定会先算诊断覆盖率，不够就加冗余或补充机制。
1.7 安全分析——找漏洞是门手艺
硬件安全分析主要有三种方法：
| 方法 | 全称 | 分析方向 | 适用场景 |
|---|---|---|---|
| FMEA | 失效模式与影响分析 | 自下而上（从器件到系统） | 识别单点故障 |
| FTA | 故障树分析 | 自上而下（从顶事件到根因） | 分析故障组合 |
| DFA | 依赖失效分析 | 横向（共因/共模失效） | 检查冗余是否真的独立 |
我个人习惯的顺序是：先做FMEA扫一遍所有可能的失效模式，再用FTA深挖关键安全目标的故障组合，最后用DFA检查冗余设计有没有“假独立”。
1.8 集成与测试——故障注入是必修课
硬件测试分两类：
- 功能测试：验证安全机制在正常工况下是否工作
- 故障注入测试：人为制造故障，看安全机制能否正确响应
故障注入是功能安全测试的灵魂。没有故障注入，你永远不知道安全机制在“真出事”时会不会掉链子。
常见的故障注入方法：
- 电压拉偏（模拟电源故障）
- 时钟抖动注入（模拟时钟故障）
- 信号短路/开路（模拟引脚故障）
- 电磁干扰（模拟EMC场景）
核心原则：测试覆盖率必须覆盖所有安全机制的所有诊断模式。漏掉一个，安全案例就不完整。
1.9 安全案例——你的“毕业答辩”
安全案例是功能安全开发的最终交付物。它是一份文档，证明你的系统满足所有安全目标。
安全案例通常包含：
- 安全目标与硬件安全需求的追溯矩阵
- 硬件架构描述与安全机制清单
- 安全分析报告（FMEA/FTA/DFA）
- 失效率计算与FMEDA
- 测试报告（含故障注入结果）
- 偏差说明（如果有未满足的需求）
评审专家会逐条核对。我见过最狠的评审，专家拿着安全案例，一条一条对着原理图查。所以别想着糊弄，每一句话都要有证据支撑。
嗯，这就是功能安全硬件开发的基础框架。后面29章，我们会一步步把这些概念落地成可执行的工程实践。