1. 功能安全基础与ISO 26262概述

各位同学，咱们今天聊聊功能安全。说实话，我刚入行那会儿，觉得安全就是“别着火、别短路”。后来做了几个项目，才发现事情远没那么简单。

功能安全，说白了就是：当系统出故障时，它不能伤害人。不是保证系统永远不坏——那不可能——而是保证它坏了之后，后果可控。

1.1 为什么我们需要功能安全？

你想想看，现在的ECU（电子控制单元）控制着刹车、转向、油门。如果这些模块在高速上突然“抽风”，后果是什么？

我2018年参与过一个项目，客户反馈某款车的EPS（电动助力转向）在特定工况下会突然失去助力。排查了三个月，最后发现是软件栈溢出导致看门狗没喂上。嗯，这就是典型的功能安全失效——系统没按预期工作，而且后果严重。

所以，ISO 26262应运而生。它不是什么“建议”，而是汽车电子开发的“交规”。不遵守，车就上不了路。

1.2 ASIL等级：你的系统有多“危险”？

ISO 26262把风险分成四个等级：ASIL A、B、C、D。还有一个QM（质量管理级），基本等于“坏了也没事”。

怎么定级？看三个参数：

• Severity（严重度）：故障对人造成伤害的程度。轻伤？重伤？致命？
• Exposure（暴露率）：故障发生的场景有多常见。天天遇到？一年一次？
• Controllability（可控性）：驾驶员能不能在故障时接管控制。能轻松应对？完全失控？

这三个参数组合，就得出ASIL等级。举个例子：

系统	严重度	暴露率	可控性	ASIL
电动助力转向	S3（致命）	E4（高）	C3（难控）	D
车窗升降	S1（轻伤）	E2（中）	C1（易控）	QM
自动紧急刹车	S3（致命）	E3（较高）	C2（可控）	C

1.3 安全生命周期：从概念到退役

ISO 26262把整个开发过程定义为一个安全生命周期。它不是只管设计阶段，而是覆盖了从概念到报废的全过程。

我把它分成三大阶段：

1. 概念阶段：定义系统、识别危险、制定安全目标。
2. 开发阶段：硬件设计、软件设计、集成测试。
3. 生产与运维：生产控制、售后监控、报废处理。

你可能会问：“硬件设计只是其中一小块，为什么还要专门学？”

因为硬件是安全的基础。软件可以OTA升级，硬件一旦流片，改不了。我在项目中见过太多“软件补丁”来掩盖硬件缺陷的案例——说实话，那都是定时炸弹。

1.4 硬件开发中的安全活动

在硬件开发阶段，ISO 26262要求我们做以下几件事：

• 硬件安全需求定义：把安全目标翻译成具体的硬件指标。比如“电源必须在10ms内切换到备份”。
• 硬件架构设计：决定冗余、诊断覆盖、故障响应策略。
• 硬件详细设计：选型、原理图、PCB布局。
• 硬件安全分析：FMEA、FTA、FMEDA——这些工具用来评估硬件是否满足安全目标。
• 硬件集成与测试：验证硬件是否按预期工作，故障注入测试是重头戏。

1.5 本章知识体系

下面这张图，是我自己总结的本章知识结构。你可以把它当作一个“地图”，后面每章都会对应到其中的某个节点。

1.6 本章小结

这一章，我们打下了功能安全的基础。记住三个核心点：

• 功能安全不是“不坏”，而是“坏了也不伤人”。
• ASIL等级决定了你的设计投入——ASIL D意味着冗余、诊断、验证，一样都不能少。
• 安全生命周期贯穿整个项目，硬件设计只是其中一环，但也是最关键的一环。