当要求ASIL D时，我们在要求什么？

本文要点

ASIL等级是功能安全需求的核心属性之一，也是我们在进行功能安全开发过程中被提及最频繁的词之一。在功能安全的讨论中经常充斥着诸如 “这款ECU最高支持什么ASIL等级？” 、“XX信号能否满足ASIL D？”之类的问题。但是，当反问一句“ASIL D到底意味着什么需求？”时，提问者未必能够给出很好的答案。

“ASIL D到底意味着什么需求？”这是一个非常好的问题，既是一个功能安全刚入门的工程师会暗自发问的一个问题，同时也可以检验一个工程师对于功能安全的基本理解是否到位。本文将试图对这个问题给出答案。受限于笔者水平和文章篇幅，这个答案不会是全面而深入的，但是应该至少可以给功能安全刚入行的工程师一些参考。

1. ASIL等级从何而来？

ISO 26262中对 “Functional Safety 功能安全” 的定义如下：

absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.（不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险）

从中可以看出，功能安全追求的是将风险控制在合理的范围内。这意味着必须首先确定哪些风险是合理的，那些风险是不合理的。ISO 26262将这一活动定义为“危害分析与风险评估。”

危害分析与风险评估可以继续细分为两步：

step1: 确定相关项所有功能异常所有行为可能导致的整车危害。

在这一过程中需要注意：应以能在整车层面观察到的条件或行为来定义危害。那么既然是以整车层面观察到的行为来定义危害，首先需要了解车辆所有可能的运动行为。从整车动力学的角度，汽车所有的运动行为可以通过下图中的运动坐标系来准确描述。

车辆运动坐标系

而在每一个坐标系上，因为控制不当而可能产生的所有的整车表现也能被界定。思路如下图所示。

step2: 结合危害和场危害发生时刻车辆运行的场景来分析风险。

这一步骤对应“危害事件分类（Classification of hazardous events）”

举例来说，和制动控制相关的ESC系统（电子稳定性系统，Electric Stability Controller）存在一个危害：ESC错误建立轮缸压力导致车辆产生非预期的制动。如果这个危害发生在高速公路上时，很可能造成人员伤亡；但是如果危害仅仅发生在车速低于10kph的停车场，则不会有造成人员伤亡的风险。

从这个角度，功能安全需要结合危害和危害发生时刻车辆运行的场景来综合分析危害所导致的风险是否在可接受的范围内。车辆的运行场景，可以理解为是下图各个因素的排列组合。简单来说，运行场景 = 道路场景 驾驶场景，比如“高速公路 直行加速”或者“高速公路 直线制动”等。

车辆运行场景

当列出了相关项的所有场景与危害的组合后，接下来就是对其进行分类和筛选，确定哪些风险是可接受的，哪些是不可接受的。ISO 26262从三个维度来进行分类和筛选：

1. S（severity 严重度）：危害发生对驾驶员或乘客或路人或周边车辆中人员会造成的伤害等级。

2. E（Exposure 曝光度）：运行场景在日常驾驶过程中发生的概率。

3. C（controllability 可控度）：驾驶员或其他涉险人员控制危害以避免伤害的概率。

通过这三个维度的综合评分确定汽车安全完整性等级（ ASIL, automotive safety integrity level），如下图所示。ASIL D代表最高严格等级，ASIL A 代表最低严格等级。QM（quality management）则意味着只要按照企业流程开发就可以满足ISO 26262要求，无其他特殊要求。

总结

• ASIL等级通过危害分析与风险评估这一功能安全活动而来。通过对危害事件进行S/E/C三个维度的评估从而确定风险的ASIL等级
• 对每个具有ASIL等级的危害事件都导出一条Safety Goal，ASIL等级是Safety Goal的基本属性
• ASIL等级越高，危害事件造成的不合理的风险越大，因此功能安全开发要求也会越高

2. ASIL D到底在要求什么？

当确定了一条完整的Safety Goal，同时Safety Goal对应的safety criteria确定以后，接下来将基于系统架构识别出可能违背Safety Goal的系统要素（软件或硬件），从而对相应的要素分配功能安全需求，（在无法进行分解的情况下）这些功能安全需求都将继承Safety Goal的ASIL等级。ASIL等级越高，意味着功能安全开发的要求越严苛。

那么将引出本文开头的问题，当一条功能安全需求定义为ASIL D时，到底在要求什么？相比ASIL A或ASIL B，ASIL D的需求“严苛”体现在哪里？

要回答这个问题，还需要回到ISO 26262中对 “Functional Safety, 功能安全”的定义中。

absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.（不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险）

这次我们将目光聚焦在“功能异常表现”上。ASIL D意味着功能异常表现能导致的风险最高，那么反过来对功能开发的要求最严苛以避免异常表现。

2.1. 功能异常是如何发生的？

在确定如何避免功能异常表现之前，需要先搞清楚功能异常是如何发生的。

如果借助ISO 26262第10部分的说明图，我们很容易得出以下结论：

故障导致失效的示例，截图来自GB/T 34590, 第10部分

系统要素（软件或硬件）的三类故障最终可能引起系统的失效从而引起功能异常而导致风险：

• 系统性软件故障
• 系统性硬件故障
• 随机硬件故障

对于前两类统称为系统性故障，由它们导致的失效则称为“系统性失效”。后者则导致“随机硬件失效”。下面就这两类失效展开说明。

系统性失效（systematic failure）：以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其他相关因素进行变更后才可能排除这种失效。

关键点：

1) 确定的方式：不同于随机硬件失效的不可预知性，系统失效的形式是确定的，只要满足相应条件就一定会发生。从另一个角度，系统性失效是可以复现的。

2) 排除：当找到造成失效的确定方式后，可以采取对应的措施（如修复软件bug，完善软件开发流程等）有效避免系统性失效。

随机硬件失效(random hardware failure)：在硬件要素的生命周期中，非预期发生并服从概率分布的失效。

关键点：

1) 硬件要素：只有硬件才会产生这类失效，软件不会。

2) 非预期：尽管硬件的设计完全正确的，元器件也是符合质量标准的。但是却无法预知的故障，无法预知在哪里发生，以怎样的形式发生。

3) 服从概率分布：虽然失效的发生是非预期的，但是失效率可以在合理的精度范围内进行预测。也就是说硬件随机失效是可以进行定量评估的。

2.2. 如何将功能异常控制在可接受的范围内？

实际上需要先澄清，世界上没有100%安全的产品，功能异常不可能100%避免。功能安全追求的是将功能异常的可能性控制在可接受的范围内。

而通过上节我们可以得出结论：将功能异常控制在可接受的范围内，本质上就是将系统性失效和随机硬件失效控制在可接受的范围内。

2.2.1. 控制系统性失效

对于系统性失效而言，如果结合“V模型”开发来看，控制系统性失效主要就是两点：

• 在“V模型”左边设计阶段考虑尽可能周到
• 在“V模型”右边验证阶段验证尽可能完善

进一步地，保证“左边设计阶段考虑尽可能周到”，既体现在对开发者的要求上，也体现在对审核过程的要求上。

软件开发过程“V模型”

拿ISO 26262中对软件开发中的软件架构设计原则的要求举例，这些方法使用越多，软件架构设计出现的系统性失效必然越低。“ ”表示强烈推荐， ASIL等级越高对这些方法的推荐度也越高。

同样地，在审核软件架构设计的过程中，采用“对设计中的动态部分进行仿真”显然比“设计走查”更能避免系统性失效。相比其他ASIL等级，ASIL D对以下方式的推荐度最高。

为保证“右边验证阶段验证尽可能完善”，拿软件集成测试举例，显然下表中的方法贯彻地越多，对避免软件集成的系统性失效效果越好。相比其他ASIL等级，ASIL D对以下方式都强烈推荐。

2.2.2. 控制随机硬件失效

ISO 26262中从两个方面对随机硬件失效提出了要求：

1. 硬件架构度量的评估(Evaluation of the hardware architectural metrics)

2. 随机硬件失效导致违背安全目标的评估(Evaluation of safety goal violations due to random hardware failures)

简单来说，硬件架构度量用来评估相关项的架构应对随机硬件失效时的有效性。这些度量所针对的随机硬件失效仅限于相关项中某些安全相关电子和电气硬件元器件，即那些能对安全目标的违背或实现有显著影响的元器件，并限于这些元器件的单点故障、残余故障和潜伏故障。

硬件架构的度量旨在实现以下目标：

• 显示用于防止硬件架构中单点或残余故障风险的安全机制的覆盖率是否足够(单点故障度量)；
• 显示用于防止硬件架构中潜伏故障风险的安全机制的覆盖率是否足够(潜伏故障度量)

单点故障度量（single-point fault metric）

单点故障度量反映了相关项通过安全机制覆盖或通过设计手段(主要为安全故障) 实现的对单点故障和残余故障的鲁棒性。高的单点故障度量值意味着相关项硬件的单点故障和残余故障所占的比例低，系统可靠性更高。

单点故障度量的计算

单点故障度量的计算公式为：

式中分母即安全相关的失效率总和。单点故障度量公式图示如下。

单点故障度量图示

ISO 26262对单点故障度量的要求

ISO 26262中对单点故障度量的要求如下，对ASIL A的安全目标没有要求，对ASIL B的安全目标没有强制要求，对ASIL C和ASIL D的安全目标有强制要求。

潜伏故障度量

潜伏故障度量反映了相关项通过安全机制覆盖、通过驾驶员在安全目标违背之前识别或通过设计手段(主要为安全故障)实现的对潜伏故障的鲁棒性。高的潜伏故障度量值意味着硬件的潜伏故障所占的比例低，系统可靠性更高。

潜伏故障度量的计算

潜伏故障度量的计算公式为：

式中分母即安全相关的失效率总和。潜伏故障度量公式图示如下。

潜伏故障度量的图示

ISO 26262对潜伏故障度量的要求

ISO 26262中对潜伏故障度量的要求如下，对ASIL A的安全目标没有要求，对ASIL B的安全目标没有强制要求，对ASIL C和ASIL D的安全目标有强制要求。

随机硬件失效导致违背安全目标的评估

简单来说，对随机硬件失效导致违背安全目标的评估是用来确定违背安全目标的残余风险已经足够低。ISO 26262对这一评估推荐了两个方法：

• 第一个方法包括使用概率的度量,即“随机硬件失效概率度量”( Probabilistic Metric for random Hardware Failures，PMHF)，通过使用例如定量故障树分析(FTA)及将此计算结果与目标值相比较的方法，评估是否违背所考虑的安全目标。
• 第二个方法包括独立的评估每个残余和单点故障，及每个双点失效是否导致违背所考虑的安全目标。

因为在实际开发中所有的公司几乎都使用PMHF，所以本文只对PMHF展开说明，感兴趣的朋友可以参考ISO 26262，part5了解第二种方法。

PMHF表示在汽车运行周期中每小时平均失效概率。ISO 26262对PMHF的要求如下，从表格中可以看出两点：

1. PMHF对ASIL A没有要求；

2. PMHF对ASIL C和ASIL B的要求一样，同时与ASIL D的要求差一个数量级。