1. 功能安全基础：ISO 26262概述、功能安全概念、ASIL等级定义、安全生命周期模型

1.1 ISO 26262到底在讲什么？

说实话，我刚入行那会儿，看到ISO 26262这本标准，第一反应是——这也太厚了吧？

但干久了你会发现，它其实就讲一件事：怎么把汽车电子系统的风险降到可接受的水平。

ISO 26262是专门针对道路车辆的功能安全标准。它脱胎于工业领域的IEC 61508，但针对汽车行业做了大量定制。我记得2011年第一版发布时，很多同行还在观望。到了2018年第二版，几乎所有的Tier 1和OEM都在推了。

为什么？因为电子系统越来越复杂。你想想看，一个L3级别的自动驾驶系统，代码量可能上亿行。不出错？不可能的。我们能做的，就是让出错后的后果不那么严重。

1.2 功能安全概念——别被名字吓到

功能安全概念（Functional Safety Concept，FSC），说白了就是回答三个问题：

1. 什么东西会出问题？（危害识别）
2. 出问题后会怎样？（风险评估）
3. 怎么防止或减轻后果？（安全措施）

我在一个线控制动项目中遇到过这样的情况：团队花了两周做FSC，结果发现一个关键场景被遗漏了——电池亏电时制动助力失效。嗯，这个场景后来被加进了安全目标，否则实车测试时肯定要出大事。

所以我的建议是：FSC不要闭门造车。拉上系统、硬件、软件、测试的人一起过一遍。一个人想不全的。

1.3 ASIL等级——你的系统有多“危险”？

ASIL（Automotive Safety Integrity Level）是ISO 26262里最出圈的概念。它把系统的安全风险分成四个等级：

ASIL等级	严重度（S）	暴露概率（E）	可控性（C）	典型应用
ASIL A	轻伤	低	容易控制	车窗升降
ASIL B	轻伤~重伤	中	一般可控	雨刮控制
ASIL C	重伤~生命危险	中~高	较难控制	ACC自适应巡航
ASIL D	生命危险	高	几乎不可控	制动、转向、EPS

还有一个特殊的——QM（Quality Management）。意思是这个功能出问题也不会造成人身伤害，按普通质量管理就行。

ASIL的确定靠三个参数：

• S（Severity）：伤害的严重程度
• E（Exposure）：危险场景发生的概率
• C（Controllability）：驾驶员或其他人员能否控制住局面

举个例子：转向系统失效。S=3（可能致命），E=4（每次开车都可能遇到），C=3（高速上几乎无法控制）。查表得出ASIL D。嗯，这就是为什么EPS系统要做双路冗余。

1.4 安全生命周期——从摇篮到坟墓

ISO 26262把整个开发过程划分成几个阶段，这就是安全生命周期。我个人习惯把它分成三大块：

1.4.1 概念阶段

• 定义项目范围
• 进行危害分析和风险评估（HARA）
• 制定安全目标
• 编写功能安全概念

这个阶段最容易犯的错是什么？我曾经见过一个项目，HARA只做了正常驾驶场景，完全没考虑维修模式下的操作。结果维修工在换零件时触发了安全机制，差点出事故。所以，场景覆盖要全面。

1.4.2 产品开发阶段

• 系统级设计（技术安全概念）
• 硬件开发（硬件安全需求、FMEDA）
• 软件开发（软件安全需求、单元测试）

这里我要多说一句：安全需求不是写出来就完事了。你得跟踪它，验证它。我在一个项目中用DOORS管理需求，每个安全需求都关联了测试用例。最后做安全案例时，这些关联关系帮了大忙。

1.4.3 生产与运维阶段

• 生产过程中的安全控制
• 售后故障监控
• 安全相关的召回处理

很多人觉得功能安全只跟研发有关。其实不是。生产线上一个螺丝拧紧力矩不对，都可能导致安全功能失效。运维阶段收集的故障数据，更是优化下一代产品的重要输入。

1.5 一个简单的安全需求示例

光说不练假把式。我写一个简单的安全需求示例，大家感受一下：

安全需求编号：SR_BRAKE_001
安全目标：防止非预期的制动介入
ASIL等级：ASIL D
描述：当制动系统检测到非预期的制动请求时，
      应在100ms内切断制动执行器的电源，
      并进入安全状态（制动释放）。
验证方法：① 故障注入测试
          ② 时序分析
          ③ 硬件监控电路验证

你看，一个安全需求要包含：编号、目标、等级、具体描述、验证方法。缺一不可。

1.6 小结

这一章我们聊了ISO 26262的来龙去脉、功能安全概念、ASIL等级和安全生命周期。说白了，功能安全就是一套系统化的方法论，帮你把“万一出事怎么办”这个问题想清楚、做扎实。

下一章我们会深入讲HARA（危害分析和风险评估），那是整个安全工作的起点。我建议你先把ASIL的查表逻辑搞熟，后面会轻松很多。