1. 功能安全概述：ISO 26262标准背景、功能安全定义、ASIL等级概念、功能安全开发流程概览

1.1 为什么我们需要功能安全？——标准背景

说实话，我刚入行那会儿，功能安全这个概念在国内还不太受重视。大家更关心的是「功能能不能跑起来」、「性能够不够强」。直到有一次，我参与的一个项目在路试时出现了意外的非预期加速……嗯，从那以后，我对功能安全的态度彻底变了。

ISO 26262这个标准，全称叫「道路车辆功能安全标准」。它最早在2011年发布第一版，2018年更新了第二版。你想想看，一辆车上现在有上百个ECU（电子控制单元），代码量动辄上千万行。这么多电子系统，万一哪个出故障，后果可能是致命的。

这个标准的初衷很简单：把电子电气系统的故障风险，降低到一个可接受的水平。它不是教你如何把功能做得更炫，而是教你如何避免系统出问题——或者出了问题后，还能保证安全。

1.2 功能安全到底在说什么？——定义

功能安全的官方定义是：不存在由电子电气系统的功能异常表现所导致的不合理风险。

听起来有点绕？我换个说法。你开车时踩刹车，刹车必须能停下来。如果刹车系统因为某个传感器故障而失灵，这就是「功能异常表现」。如果这个失灵导致了事故，那就是「不合理风险」。

功能安全要做的，就是确保：

• 系统在正常工作时，不会产生危险
• 系统在发生故障时，也能进入安全状态
• 系统在故障被检测到后，能及时提醒驾驶员

我在项目中遇到过一种情况：某个ADAS（高级驾驶辅助系统）的摄像头被泥巴挡住了，系统没有检测到这个故障，仍然输出「前方无障碍」的信号。结果车辆自动加速……这就是典型的功能安全失效。后来我们加了一个摄像头脏污检测机制，才算真正解决问题。

1.3 ASIL等级——你的系统有多「危险」？

ASIL，全称是Automotive Safety Integrity Level，汽车安全完整性等级。说白了，就是给你的系统定个「危险等级」。

ASIL分为四个等级：ASIL A、ASIL B、ASIL C、ASIL D。从A到D，安全要求越来越高。还有一个等级叫QM（Quality Management），意思是「不需要做功能安全开发，按普通质量管理就行」。

怎么确定ASIL等级？标准里给了三个参数：

参数	含义	等级
S（Severity）	伤害的严重程度	S0~S3
E（Exposure）	危险场景的发生概率	E0~E4
C（Controllability）	驾驶员能否控制住局面	C0~C3

举个例子：

• 如果某个故障会导致车辆突然转向（S3），在高速公路上经常发生（E4），而且驾驶员几乎无法控制（C3），那这个功能就是ASIL D——最高等级。
• 如果只是车内氛围灯不亮了（S0），那可能就是QM，不用管功能安全。

1.4 功能安全开发流程概览——从想法到量产

ISO 26262把开发流程分成了几个阶段。我习惯把它理解成一条流水线：

1. 概念阶段：定义系统功能，识别危险，确定ASIL等级，制定安全目标。
2. 系统级开发：设计系统架构，分配安全需求，做系统级的FMEA/FTA分析。
3. 硬件级开发：设计硬件电路，做硬件故障分析，计算硬件随机故障概率。
4. 软件级开发：设计软件架构，写代码，做单元测试、集成测试。
5. 生产与运行：确保生产过程安全，监控运行中的故障。

每个阶段都有对应的输出物，比如：

• 概念阶段：HARA报告（危险分析与风险评估）
• 系统级：安全计划、系统FMEA
• 硬件级：硬件安全需求、FMEDA报告
• 软件级：软件安全需求、测试报告

你可能会问：「这么多文档，是不是形式主义？」

说实话，我刚开始也这么觉得。直到有一次，一个项目出了问题，我们翻出半年前写的FMEA报告，发现当时已经预见到了这个故障模式，只是没有落实整改措施。那一刻我才明白：文档不是给别人看的，是给自己留的后路。

1.5 一个小结

这一章我们聊了：

• ISO 26262的背景——为什么要有这个标准
• 功能安全的定义——避免不合理风险
• ASIL等级——从A到D，危险程度递增
• 开发流程概览——从概念到量产，步步为营

下一章，我们会深入讲HARA（危险分析与风险评估），这是功能安全开发的第一步，也是最关键的一步。我会用实际项目案例，带你走一遍完整的HARA流程。