1. 课程导入
汽车电子硬件从“能工作”走向“可被证明安全”，中间隔着一整套论证与认证工程。智能驾驶域控制器、线控底盘、电池管理系统等安全相关电子控制单元一旦失效，后果可能是人身伤害而非简单返修。因此，车规硬件安全不是可选的加分项，而是产品能否合法上市、能否被整车厂采信的前置条件。本课程围绕 ISO 26262 功能安全、ISO/SAE 21434 网络安全与 AEC-Q 可靠性认证三条主线，讲解如何把安全目标逐层分解为硬件指标，并用证据链证明其达成。
学习目标：从“会设计”到“能论证”
完成本课程后，学习者应具备四项能力：第一，能把整车安全目标（ASIL 等级）分解为硬件架构指标，如单点故障度量（SPFM）、潜伏故障度量（LFM）与硬件随机失效概率目标；第二，能读懂并编写硬件安全需求规范、安全分析报告与安全案例；第三，能组织 FMEDA、DFA、FTA 等分析活动并输出可审计证据；第四，能理解认证机构、整车厂与芯片供应商之间的证据传递关系，知道每一份文档“给谁看、证明什么”。
核心概念：安全、可靠与网络安全的边界
初学者最容易混淆三组概念。功能安全关注的是电子电气系统失效导致的危害，核心问题是随机硬件失效与系统性失效；可靠性关注的是产品在规定条件下保持功能的概率，AEC-Q100 等标准给出的是器件级应力与寿命验证；网络安全关注的是恶意攻击导致的非预期行为，ISO/SAE 21434 要求从威胁分析与风险评估（TARA）出发定义安全属性。三者共享硬件对象，但目标、方法与证据形态不同，不能互相替代。
另一个关键概念是 ASIL 等级。ASIL 由严重度（S）、暴露率（E）与可控性（C）三个维度评定，分为 A、B、C、D 四级，D 级最严。ASIL 等级直接决定硬件指标门槛，例如 ASIL D 通常要求 SPFM ≥ 99%、LFM ≥ 90%，而 ASIL B 要求明显更低。等级不是标签，而是贯穿架构、选型、诊断覆盖率与验证强度的约束。
方法流程：一条可执行的论证主线
工程实践中，硬件安全论证通常按以下顺序推进，每一步都产生下游可用的证据：
- 相关项定义与危害分析：明确硬件边界、功能与运行场景，识别危害事件并评定 ASIL。
- 安全目标与功能安全概念：把危害转化为安全目标，分配安全机制与初步架构假设。
- 技术安全需求与硬件安全需求：将概念落到具体信号、诊断、时序与容错要求。
- 硬件架构设计与安全分析：用 FMEDA 量化失效率与诊断覆盖率，用 DFA 检查共因失效。
- 验证与确认：通过故障注入、诊断测试、环境与可靠性试验收集证据。
- 安全案例与评估：整合证据链，接受内部审核与第三方评估。
这条主线不是一次性瀑布，而是迭代闭环。当 FMEDA 显示 SPFM 不达标时，往往需要回到架构增加诊断或更换器件，而不是在报告里“调整参数”。
案例场景：一个域控制器的安全论证片段
假设某智能驾驶域控制器需达到 ASIL D。硬件团队选用一颗具备安全手册的 MCU，但安全手册给出的 SPFM 仅覆盖部分模块。团队需要：对未覆盖模块补充外部看门狗与电压监控；对电源路径做 DFA，确认共因失效不会同时击穿主副供电；在 FMEDA 中逐条填写失效率、诊断覆盖率与残余失效率；最后把结果写入安全案例，并说明与整车厂 DIA 的接口责任划分。整个过程的关键不是“做了测试”，而是“每个安全目标都有对应证据，每个证据都能追溯到需求”。
常见误区与复盘
| 误区 | 表现 | 纠正方式 |
|---|---|---|
| 把认证当终点 | 拿到证书后不再维护安全案例 | 安全案例是活文档，变更需重新评估影响 |
| 用可靠性替代功能安全 | 只做 AEC-Q 试验，不做 FMEDA | 可靠性证明器件耐用，功能安全证明失效可控 |
| 诊断覆盖率凭经验填写 | FMEDA 数据无测试支撑 | 用故障注入与诊断测试报告支撑 DC 取值 |
| 忽视网络安全接口 | 安全机制被攻击绕过 | 将 TARA 结论纳入硬件安全需求 |
本课程后续将沿着“概念—需求—设计—分析—验证—认证”的路径逐层展开，每一章都对应硬件安全论证中的一个具体环节。掌握这条主线，才能在面对认证审核与整车厂质询时，清楚说明每一个安全结论从何而来、由谁负责、用什么证据支撑。