功能安全思考——当要求ASIL D时，我们在要求什么？
写在前面
从ISO 26262标准从2011年正式发布至今，汽车E/E系统开发中已经渗透着各种功能安全相关的概念。无论是软件工程师还是系统工程师还是测试工程师，在日常工作中或多或少都和ASIL等级、FTTI、安全目标（safety goal）、安全状态（safe state）这些概念打过交道。
而在众多概念中，ASIL等级作为功能安全需求的核心属性之一，应该是被提及最频繁的词。在功能安全的讨论中经常充斥着诸如 “这款ECU最高支持什么ASIL等级？” 、“XX信号能否满足ASIL D？”之类的问题。但是，当反问一句“ASIL D到底意味着什么需求？”时，被提问者未必能够给出很好的答案。
“ASIL D到底意味着什么需求？”这是一个非常好的问题，既是一个功能安全刚入门的工程师会暗自发问的一个问题，同时也可以检验一个工程师对于功能安全的基本理解是否到位的问题。本文将试图对这个问题给出答案。
本文旨在从功能安全方法论的本质出发做出总结，不会深入到软硬件的设计细节，希望能给想了解功能安全的汽车工程师提供一些参考，同时也能够更加准确地了解功能安全不只是文档工作而已。
受限于作者水平，这个回答不会非常全面，如果文章有不当之处也请留言指出，不胜感激。
1. ASIL等级从何而来？
ISO 26262中对 “Functional Safety 功能安全” 的定义如下：
ISO 26262：absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems. GB/T 34590：不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险。
从定义中可以看出，功能安全追求的是将风险控制在合理的范围内。这意味着必须首先确定哪些风险是合理的，那些风险是不合理的。ISO 26262将这一活动定义为“危害分析与风险评估。”
危害分析与风险评估可以继续细分为两步：
step1: 确定相关项所有功能异常所有行为可能导致的整车危害
在这一过程中需要注意：应以能在整车层面观察到的条件或行为来定义危害。那么既然是以整车层面观察到的行为来定义危害，首先需要了解车辆所有可能的运动行为。从整车动力学的角度，汽车所有的运动行为可以通过下图中的运动坐标系来准确描述。
而在每一个坐标系上，因为控制不当而可能产生的所有的整车表现也能被界定。思路如下图所示。
step2: 结合危害和场危害发生时刻车辆运行的场景来分析风险。
这一步骤对应“危害事件分类（Classification of hazardous events）”
举例来说，和制动控制相关的ESC系统（电子稳定性系统，Electric Stability Controller）存在一个危害：ESC错误建立轮缸压力导致车辆产生非预期的制动。如果这个危害发生在高速公路上时，很可能造成人员伤亡；但是如果危害仅仅发生在车速低于10kph的停车场，则不会有造成人员伤亡的风险。
从这个角度，功能安全需要结合危害和危害发生时刻车辆运行的场景来综合分析危害所导致的风险是否在可接受的范围内。车辆的运行场景，可以理解为是下图各个因素的排列组合。简单来说，运行场景 = 道路场景 + 驾驶场景，比如“高速公路+直行加速”或者“高速公路+直线制动”等。
当列出了相关项的所有场景与危害的组合后，接下来就是对其进行分类和筛选，确定哪些风险是可接受的，哪些是不可接受的。ISO 26262从三个维度来进行分类和筛选：
- S（severity 严重度）：危害发生对驾驶员或乘客或路人或周边车辆中人员会造成的伤害等级。
- E（Exposure 曝光度）：运行场景在日常驾驶过程中发生的概率。
- C（controllability 可控度）：驾驶员或其他涉险人员控制危害以避免伤害的概率。
通过这三个维度的综合评分确定汽车安全完整性等级（ ASIL, automotive safety integrity level），如下图所示。ASIL D代表最高严格等级，ASIL A 代表最低严格等级。QM（quality management）则意味着只要按照企业流程开发就可以满足ISO 26262要求，无其他特殊要求。
ASIL等级意义总结
- ASIL等级通过危害分析与风险评估这一功能安全活动而来。通过对危害事件进行S/E/C三个维度的评估从而确定风险的ASIL等级
- 对每个具有ASIL等级的危害事件都导出一条Safety Goal，ASIL等级是Safety Goal的基本属性
- ASIL等级越高，危害事件造成的不合理的风险越大，因此功能安全开发要求也会越高
2. 一条ASIL D的需求在要求什么？
按照功能安全的开发思路，当确定了一条完整的Safety Goal以及对应的safety criteria以后，接下来将基于系统架构识别出可能违背Safety Goal的系统要素（软件或硬件），从而对相应的要素分配功能安全需求，（在无法进行分解的情况下）这些功能安全需求都将继承Safety Goal的ASIL等级。ASIL等级越高，意味着功能安全开发的要求越严苛。
那么这就回到文章一开始提出的问题中来：
- 一条ASIL D的功能安全需求到底在要求什么？
更进一步地，另一个被工程师关注的问题是：
- “ASIL等级越高，功能安全开发要求也会越高”，要求的严苛体现在哪里？
要回答这个问题，还需要回到ISO 26262中对 “Functional Safety, 功能安全”的定义中。
absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.（不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险）
这个定义中的关键词“功能异常表现"实际上暗含了对这个问题的回答。因为ASIL D意味着功能异常表现能导致的风险最高，那么反过来理解，功能开发应该按照最严苛的标准来以尽可能避免功能可能出现的异常表现。
那么顺着这个思路，引申出两个子问题：
- 功能异常表现是如何发生的？
- 如何有效地限制功能异常表现？
接下来将对这两个子问题更深入地挖掘ISO 26262中的答案。
1） 功能异常是如何发生的？
在确定如何避免功能异常表现之前，需要先搞清楚功能异常是如何发生的。
如果借助ISO 26262第10部分的说明图，我们很容易得出以下结论：
系统要素（软件或硬件）的三类故障最终可能引起系统的失效从而引起功能异常而导致风险：
- 系统性软件故障
- 系统性硬件故障
- 随机硬件故障
对于前两类统称为系统性故障，由它们导致的失效则称为“系统性失效”。后者则导致“随机硬件失效”。下面就这两类失效展开说明。
系统性失效（systematic failure）：以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其他相关因素进行变更后才可能排除这种失效。
关键点：
- "确定的方式"：不同于随机硬件失效的不可预知性，系统失效的形式是确定的，只要满足相应条件就一定会发生(如软件中将一个常量赋值'a = 20;'错误写成了'a = 200;'；又比如硬件设计手册中将使用2Ω电阻错误写成了20Ω)。从另一个角度，系统性失效是可以复现的。
- “排除”：当找到造成失效的确定方式后，可以采取对应的措施（如修复软件bug，完善软件开发流程，更新硬件开发手册等）有效避免系统性失效。
随机硬件失效(random hardware failure)：在硬件要素的生命周期中，非预期发生并服从概率分布的失效。
关键点：
- "硬件要素"：只有硬件才会产生这类失效，软件不会。
- "非预期"：尽管硬件的设计完全正确的，元器件也是符合质量标准的。但是却无法预知的故障，无法预知在哪里发生，以怎样的形式发生。
- "服从概率分布"：虽然失效的发生是非预期的，但是失效率可以在合理的精度范围内进行预测。也就是说硬件随机失效是可以进行定量评估的。
2）如何将功能异常控制在合理的范围内
世界上没有100%安全的产品，功能异常不可能100%避免。功能安全追求的是将功能异常的可能性控制在合理的（或者说可接受的）范围内。
而通过上节我们可以得出结论：
- 将功能异常控制在可接受的范围内，本质上就是将系统性失效和随机硬件失效控制在可接受的范围内。
2.1）控制系统性失效
对于系统性失效而言，如果结合“V模型”开发来看，控制系统性失效主要就是两点：
- 在“V模型”左边设计阶段考虑尽可能周到
- 在“V模型”右边验证阶段验证尽可能完善
进一步地，保证“左边设计阶段考虑尽可能周到”，既体现在对开发者的要求上，也体现在对审核过程的要求上。拿软件开发来说，"V模型"中的各个阶段及要点示意如下。
拿ISO 26262中对软件开发中的软件架构设计原则的要求举例，这些方法使用越多，软件架构设计出现的系统性失效必然越低。“++”表示强烈推荐， ASIL等级越高对这些方法的推荐度也越高。
同样地，在审核软件架构设计的过程中，采用“对设计中的动态部分进行仿真”显然比“设计走查”更能避免系统性失效。相比其他ASIL等级，ASIL D对以下方式的推荐度最高。
为保证“右边验证阶段验证尽可能完善”，拿软件集成测试举例，显然下表中的方法贯彻地越多，对避免软件集成的系统性失效效果越好。相比其他ASIL等级，ASIL D对以下方式都强烈推荐。
2.2）控制随机硬件失效
ISO 26262中从两个方面对随机硬件失效提出了要求：
- 硬件架构度量的评估(Evaluation of the hardware architectural metrics)
- 随机硬件失效导致违背安全目标的评估(Evaluation of safety goal violations due to random hardware failures)
2.2.1）硬件架构度量的评估
简单来说，硬件架构度量用来评估相关项的架构应对随机硬件失效时的有效性。这些度量所针对的随机硬件失效仅限于相关项中某些安全相关电子和电气硬件元器件，即那些能对安全目标的违背或实现有显著影响的元器件，并限于这些元器件的单点故障、残余故障和潜伏故障。
硬件架构的度量旨在实现以下目标：
- 显示用于防止硬件架构中单点或残余故障风险的安全机制的覆盖率是否足够(单点故障度量)；
- 显示用于防止硬件架构中潜伏故障风险的安全机制的覆盖率是否足够(潜伏故障度量)
对于单点故障度量来说，它反映了相关项通过安全机制覆盖或通过设计手段(主要为安全故障) 实现的对单点故障和残余故障的鲁棒性。高的单点故障度量值意味着相关项硬件的单点故障和残余故障所占的比例低，系统可靠性更高。其计算公式为：
式中分母即安全相关的失效率总和。单点故障度量公式图示如下。
ISO 26262中对单点故障度量的要求如下，对ASIL A的安全目标没有要求，对ASIL B的安全目标没有强制要求，对ASIL C和ASIL D的安全目标有强制要求。
对潜伏故障度量来说，它反映了相关项通过安全机制覆盖、通过驾驶员在安全目标违背之前识别或通过设计手段(主要为安全故障)实现的对潜伏故障的鲁棒性。高的潜伏故障度量值意味着硬件的潜伏故障所占的比例低，系统可靠性更高。计算公式为：
式中分母即安全相关的失效率总和。潜伏故障度量公式图示如下。
ISO 26262中对潜伏故障度量的要求如下，对ASIL A的安全目标没有要求，对ASIL B的安全目标没有强制要求，对ASIL C和ASIL D的安全目标有强制要求。
2.2.2）随机硬件失效导致违背安全目标的评估
简单来说，对随机硬件失效导致违背安全目标的评估是用来确定违背安全目标的残余风险已经足够低。ISO 26262对这一评估推荐了两个方法：
- 第一个方法包括使用概率的度量,即“随机硬件失效概率度量”( Probabilistic Metric for random Hardware Failures，PMHF)，通过使用例如定量故障树分析(FTA)及将此计算结果与目标值相比较的方法，评估是否违背所考虑的安全目标。
- 第二个方法包括独立的评估每个残余和单点故障，及每个双点失效是否导致违背所考虑的安全目标。
因为在实际开发中所有的公司几乎都使用PMHF，所以本文只对PMHF展开说明，感兴趣的朋友可以参考ISO 26262，part5了解第二种方法。
PMHF表示在汽车运行周期中每小时平均失效概率。ISO 26262对PMHF的要求如下，从表格中可以看出两点：
- PMHF对ASIL A没有要求；
- PMHF对ASIL C和ASIL B的要求一样，同时与ASIL D的要求差一个数量级。
但是，现实中很多工程师对于这个表格存在太多“误解”。此处指出两个尤为常见的理解误区供读者参考。
（1）PMHF的目标值不等同于失效率 (failure rate)
失效率和PMHF的单位虽然都是“/h”，但是意义不同。也正是由于两者太容易被混淆，在ISO 26262-2018版中对其进行了补充。比如part5中的附录F和part10中的第8节就专门针对PMHF补充了解释。
附录F中提供的PMHF计算公式如下，通过公式可以清楚理解PMHF和失效率的单位都是“/h”，但是两者的意义不同。最大的不同点在于PMHF需要考虑双点故障的暴露持续时间 (Lifetime) ：
前面提到，PMHF表示在汽车运行周期中每小时平均失效概率。因此对于这个公式的理解如下：
- 对于单点故障，一旦发生将直接违背安全目标，因此每小时平均失效概率即为单点故障的失效率
- 对于残余故障，一旦发生将直接违背安全目标，因此每小时平均失效概率即为残余故障的失效率
- 对于双点故障，当故障A发生且没有被safety mechanism或者驾驶员探测出来，并不会立刻违背安全目标；但是在接下来的运行时间内，如果故障B发生将违背安全目标，因此故障A和故障B组合违背安全目标的每小时平均失效概率为以下三个因素的乘积：
- 故障A的潜伏故障失效率；
- 故障B的双点故障失效率；以及
- 从故障A发生开始到故障B发生之前车辆运行时间（或者称故障暴露持续时间）
暴露持续时间从故障可能发生时开始，包括：
a) 与每个安全机制有关的多点故障探测时间间隔，或者当故障不对驾驶员显示(潜伏故障)时的车辆生命周期;
b) 单次行程的最长持续时间(对于驾驶员被要求以一种安全方式停车的情况)；及
c) 直到车辆进入车间维修前的平均时间间隔(对于驾驶员被警示要去维修车辆的情况)。
与此同时，对车辆去维修的平均时间的假设取决于故障的类型:
a) 对舒适性功能的降级，200次车辆行程;
b) 对驾驶辅助功能的降级，50次车辆行程;
c) 对黄色警告灯或影响驾驶表现时，20次车辆行程;
d) 对红色警告灯，1次车辆行程。
对于乘用车而言，1次车辆行程通常假设为1小时。
（2）PMHF的目标值没有绝对意义
我认为ISO 26262中对这一点的说明是整个ISO 26262中最关键的一个说明。但是可惜这个说明总是被忽略。
These quantitative target values derived from sources ... do not have an absolute significance but are useful for comparing a new design with existing ones. They are intended to make available design guidance as described in 9.1 and to make available evidence that the design complies with the safety goals.
换句话说，对研究对象进行PMHF计算的目的在于验证新设计的可靠性比上一代更好。
如果ASIL D的安全目标计算出来的PMHF = 25E-9/h, 并不意味着这个产品就不安全，假如上一代产品同一个安全目标下的PMHF = 40E-9/h，依旧可以认为符合功能安全要求，因为新设计显然比上一代更加安全。
只有当设计一个全新的产品，找不到任何可参照对比的PMHF值时，我们才会采用ISO 26262中推荐的表格进行评定，而且这个评定不是死板的，即使超过了表格里的值，只要有可信度高的证据依然可以认为符合功能安全要求。
结尾——对问题的答案
回到文章开头的问题上，通过全文的说明，我们可以给出以下答案：
| 问题 | 回答 |
|---|---|
| 一条ASIL D的功能安全需求到底在要求什么？ | 1. 本质上是在要求将可能违背这条功能安全的要素（软件、硬件）中可能存在的系统性失效和随机硬件失效限制在合理的范围内 2. 对系统性失效的限制体现在“V模型”开发的各个环节3. 对随机硬件失效的限制的指标主要是SPFM/LFM/PMHF |
欢迎关注专栏《功能安全工程师的笔记》。
专栏主题：功能安全问题总结，行业动态见闻分享
如果文章对你起到了一些帮助，请点赞支持，同时欢迎留言讨论，你的反馈是我更新的最大动力~
697
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
