📚 课程目录第3章电驱系统架构与安全边界

3. 电驱系统架构与安全边界

好，咱们进入正题。ASIL，全称是Automotive Safety Integrity Level，汽车安全完整性等级。说白了，它就是衡量一个功能到底有多“要命”的标尺。你想想看，一个刹车失灵和一个空调不制冷，风险能一样吗？ASIL就是用来量化这个差别的。

我个人习惯把ASIL理解成“安全紧箍咒”——等级越高，开发过程中要戴的“紧箍咒”就越多，流程越严，方法越狠。嗯，咱们先看看它到底有几个档位。

ISO 26262定义了四个等级，从低到高：ASIL A、ASIL B、ASIL C、ASIL D。还有一个特殊的QM（Quality Management），它不算ASIL等级，意思是“只要按质量管理做就行，没有额外安全要求”。

等级	风险程度	典型场景举例	开发严格程度
QM	无安全风险	车窗升降、车内氛围灯	仅需质量管理体系
ASIL A	轻度风险	尾灯故障、信息娱乐系统	较低
ASIL B	中度风险	雨刮器失控、大灯自动切换	中等
ASIL C	较高风险	自适应巡航（ACC）部分失效	较高
ASIL D	极高风险	制动系统、转向系统、安全气囊	最严格

核心要点：ASIL D是最高等级，不是所有功能都需要它。我见过不少团队一上来就给所有安全功能定D，结果开发成本爆炸，周期拉长。记住，够用就好，不要过度设计。

ASIL等级不是拍脑袋定的。ISO 26262给了三个参数，用来评估一个危害事件的严重程度。这三个参数是：

每个参数都分几个等级，咱们一个个看。

S评估的是：如果危害事件发生了，人会伤得多重？

我的经验：定S等级时，别只看最坏情况。比如刹车失灵，最坏是S3，但也要考虑车速、路况。我曾经在一个项目中，把“低速泊车时刹车失效”定成了S1，因为车速慢，最多撞保险杠。但高速场景下同样的问题就是S3。场景不同，S值可以不同。

E评估的是：驾驶员在正常驾驶中，有多大概率暴露在这个危险场景里？

举个例子：高速爆胎——E值很低，因为爆胎本身是小概率事件。但雨天刹车——E值就高，因为下雨天很常见。

避坑指南：我曾经见过一个团队把“车辆在冰雪路面行驶”的E值定成了E4，理由是“北方冬天经常下雪”。但仔细一想，车辆在冰雪路面行驶不等于一定会发生危害事件。E评估的是危险场景的暴露概率，不是天气概率。要结合功能使用场景来定，别偷懒。

C评估的是：当危险发生时，驾驶员或周围人员能不能控制住局面？

这里有个关键点：C3不代表完全失控，而是“很难控制”。比如高速行驶中突然爆胎，大部分驾驶员会手忙脚乱，这就是C3。

有了S、E、C三个值，怎么合成一个ASIL等级？ISO 26262给了一张查表矩阵。你想想看，就像查字典一样，找到对应的格子就行。

查表口诀：S越高、E越高、C越差，ASIL等级就越高。三个参数中，S是天花板——S3最多到D，S2最多到C，S1最多到B。E和C决定具体落在哪个格子里。

下面这张图，把整个ASIL等级确定的逻辑串起来了。从危害分析开始，到S/E/C赋值，再到查表得到ASIL等级，最后落到开发要求。我建议你把它存下来，做项目时对照着用。

讲到这里，我分享几个我在项目中踩过的坑，希望能帮你少走弯路。

问题一：S/E/C赋值过于保守

我曾经遇到一个团队，把所有涉及“刹车”的功能都定成了S3、E4、C3，结果全是ASIL D。但仔细分析后发现，有些刹车功能只在低速泊车时启用，S值其实只有S1。最后重新评估，把ASIL D降到了ASIL B，开发成本直接砍了一半。

问题二：忽略场景的多样性

同一个功能，在不同场景下S/E/C值可能不同。比如“自动紧急制动（AEB）”，在高速场景下S3、E3、C2 → ASIL C；但在城市低速场景下S2、E4、C1 → ASIL B。我建议的做法是：按最坏场景定ASIL等级，但要在安全目标中注明适用的场景范围。

问题三：混淆“危害”和“失效”

ASIL评估的是危害事件，不是失效模式。比如“刹车踏板断裂”是失效模式，而“车辆无法减速导致追尾”才是危害事件。很多新手直接拿失效模式去定ASIL，结果逻辑全乱。记住：先分析危害，再定ASIL。

ASIL等级确定，说白了就是三个步骤：