★ FEATURED ARTICLE 我第一次在供应商的安全手册里看到“ASIL D”这个缩写时第一反应是这是什么考试等级D是不是比C高一级后来去翻ISO 26262才发现不少工程师都在这个缩写面前懵过。ASIL的全称是Automotive Safety Integrity Level中文叫汽车安全完整性等级它是ISO 26262功能安全标准里用来给“风险”定级别的一套核心语言。它不是产品评级不是考试分数更不是供应商用来唬人的名词。这篇文章想把这个概念彻底讲透它为什么出现、怎么定级、定级之后对项目意味着什么以及实际开发中最容易踩的坑。1. 从“刹不住”的电子系统说起ASIL为什么会被发明出来1.1 机械时代的失效是可数得清的电子时代不是老一辈工程师做机械底盘出身的人对“安全设计”的理解通常是这样的刹车油管可以搞双回路转向杆可以加粗制动片磨损可以通过定期保养检查。机械系统的失效模式相对可控——磨损、疲劳、断裂、卡滞都有一套成熟的工程计算兜底。但电子系统不一样一个软件bug可能只在一个罕见的时序组合下出现一颗传感器可能因为电磁干扰或泥水遮挡而报出错误数据一颗芯片的随机硬件失效概率需要靠统计学去推算。失效不再是“看得见的磨损”而是“测不准的异常”。特别是2000年前后电子油门、ESP、线控底盘开始大规模上车。系统越复杂越需要一套统一的“安全语法”否则每家供应商各说各话OEM没办法判断“这个零部件到底安不安全、要投入多大力度去验证”。说白了行业缺的不是技术而是一套大家都能听懂的风险分级标准。1.2 从IEC 61508到ISO 26262汽车行业搞出了一套自己的标准很多人不知道ISO 26262的“祖宗”是IEC 61508这是一套面向工业控制、核电、机械等领域的功能安全通用标准。它里面有一个SILSafety Integrity Level安全完整性等级的概念从SIL 1到SIL 4。但汽车行业很快发现直接套用IEC 61508有不少别扭的地方汽车不是固定安装的工业设备车上坐的是普通用户不是一个经过培训的操作员整车要面对极端温度、振动、电磁干扰还要考虑量产一致性。于是汽车行业决定基于IEC 61508搞一套属于自己的标准这就是ISO 26262。第一版ISO 26262在2011年发布2018年出了第二版。第二版把适用范围从乘用车扩展到了摩托车、公交车、卡车等所有量产道路车辆还增加了半导体应用指南。ASIL就是这套标准里最核心的概念全称Automotive Safety Integrity Level。它的作用是把一个电子电气系统在某个危害场景下“需要把风险降到什么程度”进行等级化等级从低到高分别是ASIL A、ASIL B、ASIL C、ASIL D另有一个QM等级意思是只按普通质量管理体系开发即可不需要额外上功能安全手段。1.3 ASIL衡量的不是“风险有多大”而是“手段要有多严”这里有个很微妙、也很容易被误解的点ASIL不是用来描述“这个系统失效概率有多大”的标签而是描述“为了把这个系统相关的风险降到社会可接受水平开发过程和安全措施需要达到多严格的程度”的标签。打个比方一座核电站和一个街边便利店里面都有空调但安保等级完全不同不是因为空调本身差别多大而是因为“空调故障在核电站和便利店造成的后果天差地别”。ASIL干的就是这件事根据失效可能造成的后果严重程度决定你要用多高级别的开发流程、多强的安全机制、多高的验证标准。所以你会发现同样是“一个传感器失效”在车窗升降系统里可能是QM或ASIL A在转向系统里就可能是ASIL D。等级变高了不代表传感器一定会坏只是说一旦坏起来后果很严重所以需要用更严格的手段把它管住。这个思路贯穿整个ISO 26262理解了它后面所有内容都会顺很多。2. 给风险打分的三把尺子S、E、C怎么量出一个ASIL2.1 S——严重度最直观但也最容易拍脑袋ASIL的定级不是凭感觉而是来自一场叫做HARAHazard Analysis and Risk Assessment危害分析与风险评估的分析。分析过程中工程师要针对每个“危害事件”做三维评分第一个维度就是SSeverity严重度。它衡量的是当危险事件发生时人员受伤的最坏合理情况是什么。ISO 26262里把S分成S0到S3四档S0是无伤害S1是轻伤S2是可能危及生命的重伤S3是致命伤。实际评分时S通常可以借助参考表格来判断比如碰撞速度区间、安全带使用情况、车内乘员位置等。这里最忌讳的就是“拍脑袋定S3”因为一旦S给高了后面的ASIL会水涨船高项目成本直线上升给低了又会造成安全措施不足。我见过不少项目在S评分时吵成一团最后靠事故统计数据和仿真碰撞结果说话才达成一致。另一个常见误区是拿“功能级别”代替“危害后果”。比如很多人觉得“转向功能很重要所以S一定是3”这是不对的。应该描述成“高速行驶中转向失效导致车辆偏离车道与对向车辆碰撞驾驶员和乘员可能致命”最后定S3。同样的转向功能如果在停车状态下失效可能只是车辆无法移动危害后果完全不同S的评分自然也不一样。2.2 E——暴露概率看的是“场景占比”不是“失效概率”第二个维度是EExposure暴露概率。但这里的“暴露”非常容易被搞混。它评的不是“某个电子器件坏的概率”而是“车辆处于一个可能发生危害的相关场景中的概率或时间占比”。也就是说E评的是场景不是事件。比如“高速公路上以120km/h巡航”这个场景如果该车主要在城市通勤暴露率不算高如果经常跑长途高速那么暴露率就上去了。标准里E档位的定义在ISO 26262第一版和第二版中表述略有差异核心维度不变从极低到高大致对应E1、E2、E3另一版里是E1到E4。在评估时要有实际的数据支撑比如行驶里程统计、用户画像、路况调研、事故数据库。为什么要求这么严因为E评级直接左右最终ASIL如果仅凭“我觉得这种情况挺常见的”就给了高E后续查表得到的ASIL可能高得离谱评审时一追问数据来源就露馅了。2.3 C——可控性这一项最能体现“人机共驾”的差异第三把尺子是CControllability可控性。它衡量的是当危害事件发生时驾驶员、乘客或其他交通参与者能否通过及时、合理的反应来避免伤害。C1表示绝大部分人能够轻松控制住局面C2表示一部分人能勉强避免但存在相当比例的人反应不过来C3表示无论怎么操作都很难避免伤害。C是三个维度里最难评的因为它涉及“人的反应”。评估手段也比较多样可以参考实车测试、驾驶模拟器实验、同类型事故统计。到了自动驾驶时代C的评级发生了很大变化——L2级辅助驾驶驾驶员在环C可以评得相对乐观L3级以上驾驶员可能正在刷手机甚至睡觉系统要求他接管都来不及反应那么同一个失效模式的C就会从C2滑向C3ASIL也随之升高。这也是为什么很多智能驾驶功能的安全目标最终都落在了ASIL D上不是系统更容易坏而是人越来越难充当“最后一道防线”。2.4 查表定级S、E、C三个档位组合出最终ASIL三个维度分别打完分之后查一张组合表就可以得到最终的ASIL等级。下表是ISO 26262中ASIL查表逻辑的经典版本注意不同年份版本在E档位具体定义上略有调整但组合思路是一致的S等级E等级可控性C1可控性C2可控性C3S1E1QMQMQMS1E2QMQMASIL AS1E3ASIL AASIL AASIL BS2E1QMQMASIL AS2E2ASIL AASIL AASIL BS2E3ASIL BASIL BASIL CS3E1ASIL AASIL BASIL CS3E2ASIL BASIL CASIL DS3E3ASIL CASIL DASIL D这张表的信息量很大值得盯着看几遍。你会发现同样是S3致命伤级别如果暴露率低E1且驾驶员可控性好C1只落到ASIL A但暴露率提高E2加上可控性变差C3就直接冲到ASIL D。这说明ASIL不是某个功能的固有属性而是“场景失效人”这三者组合出来的结果。2.5 一个实例ACC传感器被遮挡定A还是定D全靠场景拿自适应巡航ACC举例子。假设ACC的毫米波雷达被泥浆遮挡导致系统丢失前方目标车辆在高速行驶中无法识别静止障碍物存在追尾风险。先看严重度高速追尾大概率重伤甚至致命S评为S3。再看暴露概率泥浆遮挡多发生在雨雪天气和特定地区普通用户一年碰上的次数有限E评E2比较合理。可控性呢如果是L2级辅助驾驶驾驶员被要求保持监控发现巡航异常后可以踩刹车接管多数人做得到C评C2。查表S3/E2/C2 ASIL C。如果把场景换成L3级系统允许驾驶员长时间脱手。此时驾驶员注意力可能完全不在路上从发现异常到接管往往来不及C评C3。查表S3/E2/C3 ASIL D。同一个传感器、同一个失效模式因为驾驶员在环状态不同最终等级从C升到D。这就是为什么行业里常说“自动驾驶把很多功能的ASIL‘顶’到了D”——不是硬件变危险了而是人的兜底能力大幅下降系统自己必须承担更高的安全要求。3. 定完ASIL之后开发和验证差在哪里3.1 硬件随机失效从“能用就行”到“低到离谱的数量级”很多人以为ASIL等级只是写在文档里的一个字母顶多影响论文评审其实它直接决定了硬件设计要怎么选型、怎么加保护。ISO 26262对不同等级提出了不同的硬件随机失效量化目标业界一般用PMHFProbabilistic Metric for Random Hardware Failures随机硬件失效概率度量来衡量通俗讲就是一个功能在一小时内出现随机硬件失效的平均概率也常换算成FITFailures In Time每十亿小时失效次数来说。常见的参考目标值如下ASIL B对应PMHF小于10^-6/h折合约1000 FITASIL C对应小于10^-7/h约100 FITASIL D对应小于10^-8/h约10 FIT也就是平均一亿小时才允许出现一次由随机硬件失效导致的严重事件。ASIL A通常不强制做严格的定量评估。这个数量级差距是巨大的10 FIT意味着你对MCU、电源芯片、传感器、通信链路每一个环节都要做FMEDA失效模式、影响和诊断分析算出每个模块的失效率并靠安全机制把失效覆盖率提到足够高才可能把这笔“预算”花完。3.2 安全机制与诊断覆盖率低等级靠运气高等级靠设计为了把随机硬件失效压到可接受的范围系统必须加装安全机制比如电压监测、时钟监测、程序流监控、看门狗、内存ECC、双核锁步比较等。这里的核心指标是诊断覆盖率也就是“当故障发生时安全机制能检测出来的比例”。ISO 26262一般把诊断覆盖率分成低、中、高三档低约60%到90%中约90%到99%高则大于99%。对不同ASIL等级安全机制的最低要求明显不同。ASIL B通常要求中等诊断覆盖率90%级别ASIL C要往97%上靠ASIL D基本要求99%以上。单是MCU选型这一条就很直观ASIL D项目几乎都会选带锁步核心Lockstep或双核比较能力的车规MCU再配合外部看门狗和电源监测ASIL A项目往往一个普通MCU加简单看门狗就够了。我见过不少团队做ASIL B项目时还挺从容一到ASIL D就发现做诊断覆盖率的计算表做到怀疑人生——每一条失效路径都要算覆盖率算不清评估时就会被挂起。3.3 软件流程从“能跑就行”到MC/DC、独立评估、证据链硬件之外软件侧的要求差异同样惊人。ASIL A项目做好代码规范、基本单元测试就能过ASIL B往上代码覆盖率的要求开始提高到了ASIL C一般要求分支覆盖率ASIL D则要求MC/DC覆盖率修正条件判定覆盖也就是要证明每个条件都独立地影响过判定结果这个测试工作量比语句覆盖大好几倍。过程方面ASIL C和D的项目往往需要独立安全评估要么由组织内完全不参与项目开发的独立团队要么直接请第三方评估机构。评估员会逐条检查你的安全目标、功能安全概念、详细设计、测试报告连起来形成一条完整的证据链。ASIL A和B通常内部评审即可工作量差距肉眼可见。再加上MISRA C规范在ASIL D项目里几乎是强制的很多公司还会额外上静态分析工具和形式化验证工具软件开发的整体成本比ASIL A高出数倍是常态。3.4 一张表看清A到D的差距对比维度ASIL AASIL BASIL CASIL D典型SPFM单点故障度量目标不强制≥90%≥97%≥99%典型LFM潜在故障度量目标不强制≥60%≥80%≥90%硬件随机失效目标约无硬性量化10^-6/h10^-7/h10^-8/h诊断覆盖率倾向低中高高99%级软件测试覆盖要求基础语句/判定分支/判定MC/DC独立性评估常规评审常规评审常需独立评估严格独立评估安全证据链要求较简中强最强这张表不用背但要建立个直觉ASIL每升一级开发成本不是线性增长而是近似指数级增长。所以定级这件事情必须严谨定错了高项目哭定错了低出了安全事故要背责任。两头的风险都真实存在。4. 架构上的“拆解术”ASIL分解与独立性4.1 冗余换等级为什么D可以拆成CC当一个安全目标被定为ASIL D而某个子系统却完全无法达到ASIL D的开发成本时行业里有一个合法的“降级”手段叫ASIL分解。它的底层逻辑很朴素如果两条相互独立的通道都能执行同一项安全功能一条通道失效另一条还能兜底那么系统整体的失效率取决于两条通道“同时失效”的概率。只要两条通道足够独立每条通道不需要做到D级开发的强度组合起来也能满足D级的目标。最常见的原则是“对半拆”ASIL D可以拆解为两个ASIL C(D)的组合。括号里的D表示“这两个C是为了最终满足D级目标而约定的分解等级”。同理ASIL C可以拆成两个ASIL B(C)ASIL B可以拆成两个ASIL A(B)。拆完之后每条通道只要按照拆解后的较低等级去做开发和验证总体仍然能通过ASIL D的论证。4.2 标准允许的组合和后缀写法别自己乱编ISO 26262-9里对ASIL分解有明确的规则和组合表项目里使用时要先查标准原文不要自己拍脑袋组合。除了最经典的“D拆CC”“C拆BB”“B拆AA”标准里对组合数量和适用条件是有限制的某些场景下可能还有三路分解但前提非常严苛业界并不常用。有一点必须强调分解之后后缀写法不能省。例如ASIL C(D)这个表达看的人立刻就能明白“这不是普通ASIL C是为了满足D目标而拆出来的C”。在安全文档、架构图、接口定义里如果只写“ASIL C”评估员会认为你擅自降低了原安全目标的要求。这种细节是评审时最容易被抓到的规范性错误。4.3 独立性是分解的命门共因失效会让分解直接失效分解能成立的前提是两条通道“足够独立”。如果两条通道用了同一个电源芯片、同一个时钟源、同一块PCB上的相邻走线或者共享同一段内存那么一个故障就可能同时击穿两条通道这就是共因失效。一旦存在共因失效分解在逻辑上就崩塌了。ISO 26262里对共因失效分析有专门的检查要求会从电源、时钟、通信、存储、物理隔离、电磁干扰防护、软件运行机制等多个维度逐项打分看两条通道之间的独立性是否达标。拿一个真实的EPS电动助力转向系统举例主转向控制MCU跑转向算法冗余MCU跑独立监控和备份输出两路供电必须来自不同域时钟要独立两个芯片物理上分开布局软件栈不能共享同一块易失存储区域。为了证明独立性项目组还要做故障注入测试——真的把一个通道搞坏看另一个通道是否还能正常兜底才有底气去跟评估员说“分解成立”。4.4 分解要趁早架构定死之后再想补就晚了ASIL分解这件事必须在概念阶段和系统架构设计阶段就规划进去。因为分解需要物理隔离、独立供电、独立通信这些硬约束这些必须体现在系统架构、硬件架构、软件架构的顶层设计里。我见过太多项目是硬件原理图都画完、软件模块都分好了才被评估员问“你这个ASIL D的安全目标是怎么实现的”然后才想起做分解结果发现两路功能都必须用同一个MCU的同一组引脚根本没法隔离只能重新改板或者接受ASIL D的全部开发要求工期和成本双双爆炸。所以做功能安全规划先想清楚“要不要分解、怎么分解、独立性怎么实现”再去铺开详细设计。这不是流程癖而是工程现实中代价最小的路线。5. 实战里绕不开的ASIL误读与排雷经验5.1 三个最常见的误读ASIL D≠绝对安全、≠产品分级、≠见者有份第一个误读是“ASIL D绝对安全”。刚才说过ASIL D只是把随机硬件失效压到10 FIT级别残余风险依然存在。它代表“风险低到社会可接受程度”不是“永远不出事”。把ASIL D当成免死金牌是很多项目在宣传材料和对外沟通时翻车的根源。第二个误读是“ASIL是产品分级标签”。一个ECU不会有一个统一的ASIL它内部不同安全目标可以分别对应不同等级。比如一个车身域控制器管电动门窗的安全目标可能是QM管刹车通信的安全目标可能是ASIL D。对外说“我们这款控制器达到ASIL D”只有在特指某个安全目标时才成立泛泛地挂标签容易误导别人。第三个误读是“为了保险起见所有功能都按ASIL D做”。这看起来是过度谨慎实际是能力和逻辑不足的体现。评级必须有S/E/C分析过程支撑如果全部按D做一方面成本爆炸另一方面评审时必被追问“你这个车窗升降的S/E/C为什么评出D来”答不上来反而暴露分析能力有问题。正确的做法是按风险走分析流程该是什么等级就是什么等级。5.2 ASIL和SOTIF的边界谁管“没坏但就是不行”的功能做ADAS和自动驾驶的工程师这两年一定绕不开另一个标准ISO 21448预期功能安全简称SOTIF。很多人把ASIL和SOTIF搞混其实它们管的不是同一类风险。ASIL管的是“系统发生故障”——随机硬件失效、软件bug、系统异常SOTIF管的是“系统没坏但功能本身能力不足或被人误用”——比如AEB在暴雨天识别不到行人、传感器在极端逆光下输出错误、驾驶员误触发自动驾驶。举个具体例子倒车影像黑屏。如果黑屏是因为一颗图像芯片随机失效那是功能安全问题走ASIL如果芯片没坏但摄像头在低照度情况下画质太差导致看不清后方障碍物那是预期功能不足走SOTIF。智能驾驶项目现在通常要同时做两套分析ASIL覆盖电子系统的失效SOTIF覆盖算法的能力边界。分清这个边界才能把问题放到正确的位置去论证。5.3 给刚开始碰ASIL的人几句实在话第一HARA要尽早做最好在概念阶段就启动。定级结论会影响整个系统的架构选型晚一步后面全是返工。第二评级依据要写清楚尤其是E和C。没有数据支撑的E/C评分在评审会上撑不过三轮。第三供应商链条也要管住ASIL要求。很多项目本体开发做得不错结果一个二级供应商提供的芯片没有按对应等级开发导致整个安全评估失败。对外采购时把ASIL要求写进技术协议是成本最低的风险控制。最后分享一个我自己的体会真正把ASIL看懂的人不是急着背那张S/E/C查表而是能清醒地讲清楚“某个危害场景下最坏会发生什么、这种情况出现多频繁、人还有多大机会兜底”。这三个问题想透了ASIL自然就浮出水面。之后再看到文档里任何一个ASIL字母你都能立刻判断它到底是经过严谨推演的结论还是拍脑袋贴上去的标签——这两种文档我这些年都见过太多。
阅读完成 · 觉得有帮助？
