1 从规避股市风险讲起

通常大家在讨论功能安全时，会从功能安全的标准ISO26262讲起。但是我逐渐发现这样的做法有个不好的点，就是会让听众误以为功能安全是个横空出世的概念，功能安全的方法论也是个新的方法论。但是功能安全本质上也是在回答一个关于‘如何降低风险’的问题，只不过分析的对象有针对性地变成了汽车的电气/电子系统(E/E系统)。而关于‘如何降低风险’，这个问题早在很多行业或者领域都被回答过了，而且无论分析对象是什么，我们都可以抽象出相同的方法论（或步骤）；更有意思的一个事实是，即使没有任何理论指导，我们在日常生活中就经常在不知不觉中运用着相同的方法论了。

这个结论听起来似乎有些不可置信？那接下来看一个生活中的案例就有体会了。

当听到股票跌破3000点的消息时，小A和小B都不约而同的打开了股票账户查看余额。当只是抱着玩一玩心态的小A发现自己只存了100元时，心态平和地接受了这个消息；而小B的账户还剩100万，这一消息让他警觉万分，一番市场走势分析下来，小B觉得应该马上离场及时止损。于是果断地选择了抛售。在接下来的几天里虽然股票偶有回升，但是小B相信自己的判断，忍住了买入的想法继续观望。一周后股票跌破2700点，小B为自己的决定感到庆幸。

这个案例中就包含了关于‘如何降低风险’的通用的方法论，主要为三个步骤：

识别风险

制定安全措施

验证安全措施的有效性

可以说，不论应对何种风险，都能提炼出同样的降低风险的步骤。功能安全开发也同样如此。

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

absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.

不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险。

那我们接下来就顺着通用的方法论的三个步骤，逐个说明功能安全是如何执行的。

2功能安全与‘风险识别’

ISO26262将识别风险这一活动定义为‘危害分析与风险评估’。

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

Step 1: 确定电气电子产品功能异常可能导致的整车危害 (Hazard)

Step 2: 危害识别分类以识别不合理的风险 (Risk)

Step 3: 导出安全目标（Safety Goal）

接下来分别对这三步进行说明。

Step 1：确定电气电子产品功能异常可能导致的整车危害 (Hazard)

在这一过程中需要注意：应以能在整车层面观察到的条件或行为来定义危害。既然是以整车层面观察到的行为来定义危害，首先需要了解车辆所有可能的运动行为。从整车动力学的角度，汽车所有的运动行为可以通过下图中的X/Y/Z运动坐标系对应的六个自由度来表征。

注：对于一些特殊的电气电子产品，也要考虑车辆在静止状态下的潜在危害，本文对此不做拓展。

车辆运动XYZ坐标系与六个自由度，图片来自J2980

而在每一个坐标系上，因为功能异常不当而可能产生的所有的整车异常表现（整车危害）也能被罗列出来。思路如下图所示。

整车危害分析示例，图片来自J2980

Step 2：危害事件分类以识别不合理的风险(Risk)

为什么要进行危害事件分类呢？和其他领域的安全设计追求的目标一样，功能安全关注的是不合理的风险(Unreasonable Risk)。我们分别来理解‘Unreasonable’ 和‘Risk’便可以得到答案。

‘Unreasonable’

没有100%安全的系统，有风险但是如果风险发生的概率极低，也是可以被接受的。比如飞机失事虽然历史上有发生，一旦发生就是灾难性的事故，但是在发生概率足够低的情况下，飞机依旧是受大众欢迎的出行选择方式。

‘Risk’

有危害(Hazard)不一定100%产生风险(Risk)，比如如果汽车在高速上突然减速，但是减速度最大只有0.1g，那么驾驶员是充分可控的（这个减速度大小和纯电常见的滑行回收功能的减速度相当），对驾驶员以及周边车辆都没有会造成人员伤害的风险。

危害与风险的区别，图片来自网络

从这个角度，进行危害事件分类，旨在筛选出能造成不合理的风险的危害事件，进而将安全开发的工作重心集中在对造成不合理风险的潜在故障的限制或消除上。

早在2010年发布的标准ISO 12100‘Safety of machinery —General principles for design — Risk assessment and risk reduction’中就指出了评估风险的通用的准则:

风险 = 危害能造成伤害的严重程度 * 危害造成伤害的概率

ISO26262遵循同样的风险评估准则，并通过三个指标来衡量衡量风险，具体对应如下：

Note：危害能造成伤害的概率，取决于危害能造成伤害所对应车辆运行场景的概率以及驾驶员对风险的可控性，车辆运行场景的暴露概率低或者道路参与人员对风险的可控性高都能降低造成伤害的概率。

S (severity 严重度)：危害发生对驾驶员或乘客或路人或周边车辆中人员会造成的伤害等级。评分表如下：

E（Exposure 暴露概率）：运行场景在日常驾驶过程中发生的概率。评分表如下：

C (controllability 可控性)：驾驶员或其他涉险人员控制危害以避免伤害的概率。评分表如下：

基于这三个指标的评分，即可确定汽车安全完整性等级（Automotive Safety Integrity Level, ASIL等级)。ASIL一共分为四个等级，D代表最高严格等级，即风险最高，A 代表最低严格等级，即风险最低。

如果相关项对应的危害事件的ASIL等级为ASIL A及以上，则功能安全开发需要予以考虑；对于QM(Quality Management 质量管理)，只要按照企业流程开发就认为可以满足ISO26262要求，无需额外进行功能安全开发。

Step 3：导出安全目标(Safety Goal)

通过危害事件分类识别出的不合理的风险，正是功能安全开发所要避免的风险，这也是功能安全的开发目标。

ISO26262对导出安全目标(Safety Goal)的要求如下。

part3,6.4.4.2

The ASIL determined for the hazardous event shall be assigned to the corresponding safety goal. If similar safety goals are combined into a single one, in accordance with 6.4.4.1, the highest ASIL shall be assigned to the combined safety goal.

应将为危害事件所确定的ASIL等级分配给对应的安全目标。如果将类似的安全目标合并为一个安全目标，按照6.4.4.1,应将最高的ASIL等级分配给合并后的安全目标。

拿大家熟知的ACC(Adaptive Cruse Control)功能举例，假如ACC功能错误控制车辆减速，其危害分析与风险评估如下表所示。

ACC功能错误减速危害分析与风险评估示例

基于危害分析与风险评估结果，可以导出如下安全目标：

SG: ACC应该避免非预期的减速, ASIL C

安全目标可以认为是整车层的功能安全需求，在确定了安全目标以及安全目标对应的安全接受准则以后，接下来便结合相关项（即所开发的电气电子产品）的架构将功能安全需求进一步拆解到组成相关项的要素（软件或者硬件）上，并进行功能安全设计。

先导出安全目标，再导出对相关项的软件或硬件的功能安全需求，截图来自GB/T 34590, 第3部分

3功能安全与‘制定安全措施’

制定安全措施的前提，是找到引起功能异常的源头，道理很简单，只有清楚了‘症结’，方能‘对症下药’。

那么接下来的问题是：

功能异常是如何发生的？

借助ISO26262第10部分的说明图，我们很容易得出以下结论。

相关项分解示例，截图来自GB/T 34590, 第10部分

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

总结来说，相关项（电气电子产品）是由两类基础的要素软件和硬件组成的，功能的异常则是由软件或者硬件的故障造成的。软件和硬件的故障可以分为三类:

系统性软件故障

系统性硬件故障

随机硬件故障

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

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

关键点：

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

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

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

关键点：

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

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

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

随机硬件失效与系统性失效举例

现在我们清楚了‘症结’：引起功能异常的源头是要素故障引起的系统性失效或者随机硬件失效，而这也决定了定义的安全措施必须尊重这两类失效的本质区别，才能真正做到‘对症下药’。

避免系统性失效的安全措施

无论是软件要素还是硬件要素，避免系统性失效都可以归为两点：

要点1：安全措施设计充分且合理

要点2：安全措施在实施阶段没有偏差

接下来就这两点展开讨论。

要点1：安全措施设计充分且合理

这一点主要取决于开发人员或者开发团队的know-how，比如对产品的了解程度以及对ISO26262方法论的理解程度等。当然，一些成熟的开发原则或指南有助于开发人员更好地展开安全措施的设计，这些方法落实越到位，软件或者硬件设计出现系统性失效的可能性必然越低，这也是为什么ASIL等级越高，ISO26262越推荐这些方法的应用。

ISO26262中对应用相关方法的推荐说明

比如对软件开发而言，遵循好的软件架构设计原则，能够保证软件的可靠性，也有利于开展软件层级的安全分析等活动。

截图来自GB/T 34590, 第6部分

对硬件开发同样如此，遵循一好的硬件架构设计原则能够保证硬件设计的可靠性，也有利于开展硬件层级的安全分析等活动。

截图来自GB/T 34590, 第5部分

要点2：安全措施在实施阶段没有偏差

举例来说，一个安全措施设计得再好，在落实到代码上出现了bug，一切都是白费，基于此，功能安全要求安全措施在实施阶段没有偏差。这一点主要取决于开发流程。以基于‘V模型’ 的开发工作为例，完善的开发流程的体现为：

在‘V模型’左边设计阶段考虑尽可能周到

在‘V模型’右边验证阶段验证尽可能完善

需要指出的是，保证以上两点，既体现在对开发者的要求上，也体现在对审核过程的要求上。

截图来自GB/T 34590

另外，开发工具的可靠性也会影响安全措施在实施时的偏差。举例来说，如果软件工程师使用的软件编译软件可靠性低，导致正确的代码在编译过程中出现问题，则可能使得软件中安全措施无效。基于此，ISO26262对开发所使用的软件工具的置信度也提出了要求，需要建立证据证明软件工具适合用于支持ISO26262要求的活动或任务。

工具评估与鉴定流程，截图来自GB/T 34590, 第8部分

最后必须强调一点，通过上面对避免系统性失效的方法的介绍，可以看出这些安全措施并不是新的东西，只不过在ISO26262中对它们进行了一些概念上的定义和要求上的细化。即使没有ISO26262，一些成熟的公司早已在自己的开发流程或者开发指南中体现了这些安全措施，因为说到底，避免系统性失效就是确保在设计的各个环节都合理可靠，ISO26262依旧符合这个安全思路。

限制随机硬件失效的安全措施

要想限制随机硬件失效，首先要对ECU中的电子元器件进行分析，了解元器件的故障模式与失效率分布，以及在故障发生后对安全目标的影响。FMEDA (Failure Modes, Effects and Diagnostic Coverage Analysis) 作为对电子元器件的随机硬件故障的分析方法而被广泛熟知。FMEDA的第一步是识别出电子元器件的每一个故障模式对系统造成的影响，并由此将电子元器件分为两类：

安全相关的电子元器件：某个电子元器件的某个或某些故障模式影响功能安全需求 （功能安全需要考虑）

非安全相关的电子元器件：某个电子元器件的所有故障模式均不影响功能安全 （功能安全不需要考虑）

截图来自GB/T 34590, 第5部分

任何一个电子元器件的故障，都可以基于故障模式对系统造成的失效影响归类为下表中的某个故障类型：

而为了达到限制随机硬件失效的目的，安全措施的设计方向通常包含三类：

设计合适的故障监控措施，将单点故障变成残余故障

冗余设计，将单点故障变成多点故障

必要时设计合适的故障监控措施，将多点故障变成可探测的或驾驶员可感知的多点故障，减少潜伏故障的失效率

4功能安全与‘验证安全措施的有效性’

验证避免系统性失效相关的安全措施——安全确认 (Safety Validation)

ISO26262中将安全确认的目的概括为：

提供符合安全目标的证据及功能安全概念适合相关项的功能安全的证据。

提供安全目标在整车层面上是正确的、完整的并得到完全实现的证据。

由此可以看出,安全确认中的‘确认’在于确认在安全措施的作用下，安全目标及对应的安全接受准则是否被满足。结合安全目标与软件或硬件层级的安全需求之间的关系可以看出，只有当整车层的安全目标被满足了，才能说明由安全目标导出的安全需求是合理且充分的。

安全确认的目标

在这里需要强调一个容易被误解的点，安全目标的确认不是只有测试这一种方式，而是可以使用以下方法的适当组合:

已定义了测试流程、测试案例和通过/未通过准则的可重复性测试(功能和安全要求的正向测试、黑盒测试、仿真、边界条件下的测试、故障注入、耐久测试、压力测试、高加速寿命测试、外部影响模拟)

分析（如FMEA、FTA、ETA）

长期测试,例如车辆驾驶日程安排和受控测试车队

实际使用条件下的用户测试、抽测或盲测、专家小组

评审

验证限制随机硬件失效相关的安全措施——SPFM/LFM/PMHF

ISO26262中从两个维度对相关项的随机硬件失效提出了要求：

维度一：硬件架构度量的评估

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

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

显示用于防止硬件架构中潜伏故障风险的安全机制的覆盖率是否足够（潜伏故障度量）

单点故障度量 (Single-Point FaultMetric, SPFM)

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

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

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

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

潜伏故障度量 (Latent FaultMetric, LFM)

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

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

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

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

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

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

方法1：‘随机硬件失效概率度量’( Probabilistic Metric for random Hardware Failures, PMHF)，代表一种评估硬件要素随机失效是否违背所考虑的安全目标的定量分析方法。这种定量分析结果会与目标值作对比。

方法2：‘对违背安全目标的每个原因的评估’(Evaluation of Each Cause of safety goal violation, EEC), 基于对每个硬件元器件及其在单点失效、残余失效和合理的双点失效方面对违背所考虑的安全目标的影响的独立评估。

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

PMHF表示在汽车运行周期中每小时平均失效概率。ISO26262对PMHF的要求如下，这里必须强调下ISO26262对PMHF的要求的完整内容，以消除对PMHF的常见误解。

ISO26262对PMHF的要求

通过上面的需求可以看出，首先，PMHF的目标值不仅仅来自表格6，还有其他不同的来源，比如参考b)和c)；其次，PMHF的定量目标值没有绝对的意义，仅有助于将一个新的设计与已有设计相比较。所以在实际开发中，千万不要将表格6视为必须满足的绝对标准来指导内部开发或者和合作方沟通。

5总结

本文试图在说明一件事：

功能安全方法论的核心思想不是全新的，它依旧符合为大众所熟知的通用的降低风险的通用步骤：‘识别风险 → 制定安全措施 → 验证安全措施的有效性’。

可以说，从功能安全开发的角度，所有的开发活动都是在通过实施这些步骤来避免或者降低E/E系统发生安全相关的系统性失效和随机硬件失效的概率，从而达到将风险降低到可接受的范围内的目的。

在这个通用的步骤的指导下，功能安全开发活动的要点可以总结如下。

没有ISO26262，流程体系完整的公司或者安全思维成熟的工程师，依旧可以找到不同的尽可能降低E/E系统发生故障造成的风险的方式，这是一个被忽略的事实。

但是，有了ISO26262，我们相当于有了一个更加系统更加完整的指南，而且这个指南标准化了企业内部合作以及不同的企业之间合作的‘沟通语言’，规范了不同企业对安全措施的选择的方向。

个人觉得，以上两点是ISO26262对汽车行业的最大的意义。至于使用通用的‘语言’，能够写出多么脍炙人口的‘诗歌’，那就取决于公司或者工程师的know-how以及对功能安全方法论的运用。

值得指出的是，本文的全部讨论都是聚焦‘功能安全开发，Safety Engineering’，ISO26262还对另一个维度‘功能安全管理，Safety Management’提出了要求并给出了指南。‘安全开发’和‘安全管理’涵盖了ISO 26262这个系列标准的全部内容。

6引申

本文是站在一个产品的角度来完整地展示功能安全开发的活动，但是一个产品背后可能关联众多的供应商，供应商的产品可能是一块芯片，可能是一个电子元器件，也可能是一个功能软件包，不同的供应商需要基于自己产品的范围对功能安全开发活动进行裁剪。比如对于一个自身没有任何故障诊断机制的简单传感器来说，对它的功能安全需求就不应该有SPFM/LFM等指标要求；又比如芯片供应商没有理由进行整车层级的安全确认活动。

不同的产品供应商如何对产品层级的功能安全需求进行裁剪，不同层级的供应商之间如何通力合作满足产品层级的功能安全需求，这又是一个很大的话题，限于篇幅无法进行拓展，欢迎关注公众号‘Leo的底盘世界’，后面继续更新文章讨论功能安全。