1、功能安全基础:ISO 26262标准概述、功能安全概念、ASIL等级定义与分解

各位同学,咱们今天聊聊功能安全的基础。说实话,我刚入行那会儿,觉得ISO 26262就是一本天书。后来啃了几年,踩了不少坑,才慢慢摸到门道。今天我把这些经验掰开了讲给你听。

1.1 ISO 26262标准概述

ISO 26262,全称是「道路车辆功能安全标准」。它源自工业界的IEC 61508,但专门针对汽车电子电气系统做了裁剪。说白了,它就是一套规则,告诉你如何把「系统出故障导致人受伤」的风险降到可接受的水平。

我个人习惯把ISO 26262分成三大部分:

  • 管理部分(Part 2, Part 8):讲的是项目计划、安全文化、文档管理这些「软」东西。
  • 产品开发部分(Part 3-7, Part 9):从概念阶段到系统、硬件、软件,再到生产、运维,全链条覆盖。
  • 支持部分(Part 10-12):包括ASIL分解、半导体指南、摩托车适用性等专项内容。

嗯,这里要注意:ISO 26262不是让你一次性读完的。我建议你从Part 3(概念阶段)和Part 6(软件层面)入手,这两个是实际工作中最常碰到的。

我的小技巧: 刚接触标准时,别死磕每个单词。先画一张「V模型」图,把每个阶段对应的Part编号标上去。这样你脑子里就有了一张地图。

1.2 功能安全概念

功能安全的核心思想是什么?就一句话:系统在出现故障时,仍然能保证安全。你想想看,一辆车的刹车系统,如果电子控制器坏了,刹车不能完全失效——这就是功能安全要解决的问题。

这里有两个关键概念:

  • 安全目标(Safety Goal):最高层级的安全要求。比如「刹车灯必须在驾驶员踩下刹车踏板后100ms内点亮」。
  • 功能安全概念(Functional Safety Concept, FSC):为了实现安全目标,系统层面要做什么。比如「采用双通道冗余设计,一个通道失效时另一个通道接管」。

我在项目中遇到过一种典型错误:工程师把安全目标写得太笼统。比如「确保刹车安全」——这等于没写。正确的写法应该是「当车速大于30km/h时,制动助力失效后,驾驶员施加的踏板力必须能在5m内将车速降至10km/h以下」。你看,时间、条件、阈值都明确了。

避坑指南: 我曾经在一个项目里,安全目标写得不够细,结果到了测试阶段才发现「哦,原来这个场景没覆盖到」。最后不得不返工,浪费了两个月。所以,安全目标一定要可验证、可测试。

1.3 ASIL等级定义与分解

ASIL,全称是Automotive Safety Integrity Level,汽车安全完整性等级。它分为四个等级:ASIL A、ASIL B、ASIL C、ASIL D。其中ASIL D要求最严格,ASIL A相对宽松。还有一个QM(Quality Management),表示对功能安全无特殊要求,按普通质量管理即可。

ASIL等级是怎么定的?看三个参数:

参数 含义 等级(高/中/低)
Severity (S) 伤害的严重程度 S0(无伤害)~ S3(致命)
Exposure (E) 危险场景发生的概率 E0(几乎不)~ E4(非常高)
Controllability (C) 驾驶员能否控制局面 C0(完全可控)~ C3(不可控)

举个例子:如果某个故障导致车辆突然加速(S3),而且这种情况在高速公路上经常发生(E4),驾驶员几乎无法控制(C3),那么ASIL等级就是D。反过来,如果只是车内氛围灯不亮(S0),那直接QM就行。

1.4 ASIL分解

ASIL分解,说白了就是「把一个大安全要求拆成几个小安全要求」。为什么要拆?因为有时候单个组件很难达到ASIL D,但拆成两个ASIL B的组件,各自独立开发,反而更容易实现。

分解规则是这样的:

  • ASIL D 可以分解为:ASIL D(D) + QM(D),或者 ASIL C(D) + ASIL A(D),或者 ASIL B(D) + ASIL B(D)
  • ASIL C 可以分解为:ASIL C(C) + QM(C),或者 ASIL B(C) + ASIL A(C)
  • ASIL B 可以分解为:ASIL B(B) + QM(B),或者 ASIL A(B) + ASIL A(B)
  • ASIL A 只能分解为:ASIL A(A) + QM(A)

注意括号里的字母表示「原始ASIL等级」。比如ASIL B(D)表示:这个组件原本属于ASIL D的分解结果,但它自己只需要满足ASIL B的要求。

重点来了: 分解不是随便分的。你必须保证两个组件之间是「相互独立」的。如果它们共享同一个电源、同一个时钟、甚至同一段代码,那就不算独立。我曾经见过一个团队把ASIL D分解成两个ASIL B,结果两个组件用的是同一个MCU——这等于没分解。

我个人习惯在分解时画一张「安全架构图」,把每个组件的ASIL等级、依赖关系、故障传播路径都标清楚。这样评审时一目了然,也方便后续做FMEA(失效模式与影响分析)。

1.5 小结

好了,这一章的内容就这些。总结一下:

  • ISO 26262是汽车功能安全的「宪法」,你得知道它长什么样。
  • 功能安全概念是「做什么」,安全目标是「做到什么程度」。
  • ASIL等级告诉你「多严格」,分解告诉你「怎么偷懒但又不违规」。

下一章咱们聊「危害分析与风险评估(HARA)」,这是定ASIL等级的关键步骤。到时候我会拿一个真实案例——电动助力转向系统的HARA——带你走一遍流程。记得提前预习Part 3的内容。

课后作业: 找一份你手头的系统需求文档,试着给每个功能定一个ASIL等级。不用太精确,关键是体会一下「S、E、C」三个参数怎么影响最终结果。