汽车行业安全相关E/E系统的开发大都与功能安全息息相关，符合ISO 26262标准的安全分析是功能安全系统开发中的重点内容。ISO 26262针对安全分析方法相应给出了行业规范的标准建议，那么在汽车安全相关系统的分析方法都有哪些，如何理解区分并运用相应的分析方法进行安全系统分析，支持我们开发符合ISO 26262标准的产品，本文我们将就此展开，介绍常用汽车安全相关系统开发中的分析方法及其最佳应用实践。
符合ISO 26262标准的安全分析方法
安全分析的目的
首先从汽车安全分析的目的说起，为什么我们在开发与安全相关的汽车电子电气系统时需要进行安全分析。
ISO 26262对功能安全的定义为：不存在因电子电气系统的功能异常引起的危害而导致不合理的风险。通常电子电器系统的功能异常由两类失效引起：
- 系统性失效（systematicfailure）：肯定与某个起因有关的，只有通过修改设计或制造工艺，操作程序、文件或其他关联因素才能消除的失效。
- 随机硬件失效（randomhardwarefailure）：在硬件要素的生命周期中，非预期发生并服从概率分布的失效。
因此安全分析的目的就在于确保因系统性失效或随机硬件失效而导致违反安全目标的风险足够低。
值得注意的是，根据ISO 26262，系统性失效的分析不讨论其发生概率。然而，针对系统性失效的措施有助于降低违反安全目标或安全需求的总体风险。
安全分析的范围
安全分析的范围包括：
- 安全目标和/或安全概念的验证
- 安全概念和/或安全需求的验证
- 识别可能导致违反安全目标或安全需求的条件和起因（包括故障和失效）
- 确定额外的安全需求以检测故障或失效
- 确定对检测到的故障或失效所需的响应（行动、措施）
- 确定其他措施，以验证是否符合安全目标或安全需求
安全分析的实现
根据应用的不同，安全分析通过以下方式实现：
- 识别HARA分析期间尚未发现的新危害
- 识别可能导致违反安全目标/安全需求的故障或失效
- 确定故障或失效的潜在起因
- 支持定义故障预防/故障控制的安全措施
- 为安全概念的适用性提供证据
- 支持验证安全概念和安全需求
- 支持识别设计需求和测试需求的验证
即对于待分析的相关项来说，根据其安全概念，经HARA分析得到安全目标，派生安全需求，进一步考虑其故障和失效，确定额外的安全需求以检测这些失效或故障，然后对检测到的故障或失效，确定所需的响应行动或措施，最后，确定额外的措施来验证我们所采取的安全措施能否满足相应的安全需求和/或安全目标。
安全分析方法介绍
定性方法和定量方法
1. 定性安全分析方法
定性安全分析方法主要包括：
- 系统、设计或过程层面的定性FMEA
- 定性FTA
- 危险与可操作性分析HAZOP
- 定性ETA
定性分析方法适用于没有更合适的特定分析方法的软件安全分析。
2. 定量安全分析方法
定量安全分析方法是对定性安全分析方法的互补方面，主要用于根据硬件架构度量和随机硬件失效指标评估。导致的安全目标违反评估的定义目标验证硬件设计（详情请参考ISO26262-5：2018，第8条和第9条）。定量安全分析需要额外了解硬件要素的定量失效率。
定量安全分析方法包括：
- 定量FMEA分析
- 定量FTA分析
- 定量ETA分析
- 马尔可夫（Markov）模型
- 可靠性框图分析
3. 定性和定量分析的区别和联系
明确定性和定量分析的联系和区别。
3.1 定性分析和定量分析的区别
二者的区别是定量分析预测失效率，而定性分析识别故障但不预测其失效率。定性安全分析方法是通用的，可应用于系统层面，硬件级和软件层面。定量安全分析需要额外了解硬件要素的定量失效率。在ISO 26262中用于验证硬件架构设计指标的评估，评估因随机硬件失效而违反安全目标的情况。
3.2 定性和定量分析的联系
二者都依赖于对相关失效类型或失效模式的把握。定量安全分析是对定性分析的补充。工程应用中应交二者结合起来使用。
归纳分析和演绎分析
除了定性定量分类方法，安全分析方法的分类还可以通过它们的执行方式划分为归纳分析和演绎分析。
1. 归纳分析与演绎分析
归纳分析方法被称为自下而上的方法，从已知的起因开始，然后自下而上，推导可能来自这些起因的后果，以此确定可能的失效。与之相反，演绎分析是自上而下的方法，从已知后果开始并寻找可能的起因。
常用安全分析方法
工程应用中有多种安全分析方法。 比如常用的失效模式与影响分析（FMEA）方法和故障树分析（FTA）方法。ISO 26262框架中FMEA和FTA是分析相关项和要素失效的两种常用方法。如果开发的系统有相应的ASIL要求，我们通常运用失效模式影响与诊断覆分析技术（FMEDA），另外还可能运用如事件树分析（ETA）或可靠性框图（RBD）方法进行安全分析相关活动。
失效模式与影响分析
失效模式与影响分析（Failure Mode and Effects Analysis, FMEA）是最早的故障分析系统技术之一，20世纪40年代后期由可靠性工程师开发，用于研究军事系统性失效可能引起的问题。20世纪70年代作为国际标准引入汽车行业，目前业界多采用美国汽车工业行动小组AIAG和德国汽车工业协会VDA 联合编写的FMEA手册（图1），用于失效模式与影响分析，协助供应商的开发工作。
FMEA手册由OEM和一级供应商问题专家（SME）组成的全球团队开发，集成了AIAG和VDA方法的最佳实践，形成了统一的结构化方法，其中涵盖了设计FMEA，过程 FMEA以及监控和系统响应的补充FMEA内容。FMEA主要针对技术风险，是对产品设计和生产过程中进行预防性质量管理和监控的一种分析方法。
FMEA分析方法最大的特点是从系统各架构要素的失效原因分析开始推导要素失效对系统的影响，从而对潜在的不可接受的失效制定优化措施。如在汽车行业的典型应用，FMEA可通过定性或定量分析的方法用于安全系统设计中故障和失效的分析。FMEA通常作为一种归纳（自下而上，见图2）方法进行，重点关注系统的各组成元器件如何发生故障以及这些故障对系统的影响。
失效模式影响与诊断分析
失效模式影响与诊断分析(Failure Modes, Effects and Diagnostic Coverage Analysis，FMEDA）方法初版由exida在上世纪九十年代开发，2011年ISO26262功能安全标准采用 FMEDA 作为标准的推荐分析方法。FMEDA方法可以看作是FMEA方法的量化扩展，因为FMEDA考虑所分析硬件要素量化的失效率数据。 即失效率和这些要素的失效模式分布，并且考虑相应失效模式的安全机制及其诊断覆盖度，以此检测关键的失效模式。
FMEDA方法主要应用于硬件架构设计和硬件详细设计阶段。我们需要在硬件设计层面计算硬件架构指标如单点故障度量和潜伏故障度量。硬件设计过程中，FMEDA工作表用于计算统计硬件相关指标数据（如SPFM、LFM）。迭代使用FMEDA方法，可改善硬件设计。
故障树分析
故障树分析（Fault Tree Analysis, FTA），由贝尔实验室在1960年代初开发，用于评估弹道导弹的发射系统。该分析方法于2006年由IEC标准化，并为汽车行业标准引用如ISO26262，作为潜在或建议的分析方法。
我们可以定性或定量的方式应用FTA。 比如定性故障分析开始，之后我们用定量数据进一步加强分析，得到分析的定量变体。
与FMEA相反，FTA是一种演绎或自上而下的分析方法（见图 3），可以帮助我们确定可能导致定义的顶事件失效的基础事件或基础事件的组合。通常顶事件作为不良系统事件，会违反某个安全目标或违反安全目标派生的安全需求。
如果我们想创建故障树分析，我们可以从不良的顶事件开始，逐步创建一个图形树结构，其中可能导致不良事件的潜在起因的交互关系用布尔逻辑运算表示，也就是与门、或门和非门等图形符号来表征。FTA的定量变体分析可用于计算我们的第三个硬件相关指标PMHF指标，这也是ISO26262的推荐方法。
安全分析方法的综合应用
实际工程应用实践中，这两种分类方法可以相互组合，从而形成如图4中描述的分类方案。安全相关的EE系统开发中，通过结合自上而下（如FTA）和自下而上的方法（如FMEA），可确定详细的半导体元件的失效模式，并将它们组合应用到要素级别。从低级的抽像开始，对半导体元器件进行定量精确的失效分布评估，其失效分布基于定性的分布假设。
E/E系统由许多元器件和子元器件组成。FTA和FMEA可以结合起来，提供自上而下和自下而上方法的综合互补的安全分析。图5显示了将FTA与FMEA可能的组合形式。图中基本事件源自不同的FMEA（在本示例中标记为FMEA A-E），这些FMEA基本事件源于较低的抽象层面（例如子元器件、元器件或组件层面）进行的分析。在本例中，基本事件1和2源于FMEA D中发现的故障，而故障树中未使用FMEA B中的故障。
安全生命周期内的安全分析方法
安全分析与安全生命周期的映射
ISO 26262参考安全生命周期包括概念阶段的主要安全活动，即产品开发、生产、运营、服务和报废。安全分析应作为产品开发的重要内容需要在系统层面、硬件级和软件层面进行。安全分析中，故障模型描述的详细程度取决于相应开发子阶段分析的详细程度，并在该子阶段内保持一致性（图6）。例如在概念阶段，在适当的抽象级别基于初始架构执行安全分析。在产品开发阶段，分析的必要详细程度可取决于分析阶段与所应用的安全机制。
通常安全分析与设计阶段活动相关联（如概念阶段、系统和硬件开发阶段）。安全分析与概念阶段、系统和硬件开发阶段的活动（如系统硬件的架构设计和集成验证等活动）相关联（图7），类似地，在软件开发阶段，安全分析与软件开发活动如软件架构单元设计与验证活动相关联（图8）。
概念阶段的安全分析
在功能安全概念阶段，ISO 26262建议进行定性安全分析，支持推导一系列有效的功能安全需求，特别是标准中提到了FMEA，FTA或HAZOP分析方法。在系统开发的技术安全概念阶段，首先我们应该对系统架构设计进行定性安全分析，为系统设计的适用性提供证据，提供指定的安全相关功能和安全相关属性，如分析系统各部分或各部分之间的独立性要求或免干扰性的要求，确定失效的起因和故障的影响。其次，如果已经定义了与安全相关的要素和接口，那么安全分析帮助我们确认或识别未知的新的安全要素和接口。最后，安全分析支持改善安全设计的规范，根据确定的故障起因及失效影响来验证安全机制的有效性。
考虑预期功能安全与网络安全对实现功能安全的潜在不利影响，有助于安全E/E系统的整体开发。类似说明适用于后续开发的各个阶段，预期功能安全与网络安全分析内容不在本文讨论范围。
硬件设计阶段的安全分析
1. 硬件设计阶段的定性安全分析
硬件设计阶段，我们结合应用各种安全分析技术。一方面是硬件设计的定性安全分析。如定性FTA方法帮助我们确定失效的起因以及硬件故障的影响。对于与安全相关的硬件组件或硬件单元，定性FMEA帮助我们识别不同类型的故障，特别是哪些属于安全故障，哪些属于单点故障或残余故障，哪些属于多点故障。同样，根据ISO 26262R标准的规范建议，我们需要综合运用演绎和归纳的分析方法进行安全分析。
2. 硬件设计阶段的定量安全分析
另一方面，当我们讨论随机硬件故障时，我们需要进行与硬件设计相关的定量安全分析。定量安全分析帮助我们评估或计算硬件架构设计的相关指标。硬件架构设计指标包括单点故障度量指标（SPFM）、潜伏故障度量指标（LFM）和随机硬件失效率度量指标（PMHF）。通常我们运用失效模式影响与诊断分析（FMEDA）方法进行定量分析，评价验证给出的硬件架构设计在检测和控制安全相关随机硬件失效方面的适用性。这主要是通过分析因随机硬件失效而导致违反安全目标的场景，进而计算相关硬件架构设计的具体指标值来进行的。
2.1. 安全相关硬件元器件故障分类
安全相关硬件元器件中发生的故障应分类为：
a） 单点故障
b） 残余故障
c） 多点故障
d） 安全故障
多点故障需要区分潜伏的故障、可检测的故障和可感知的故障。于是，安全相关硬件元器件故障分类如图9。
其中：
-距离n表示同时出现的导致违背安全目标的独立故障数（单点或残余故障n=1，双点故障n=2等）
-距离为n的故障位于n环和n-1环之间
-除非在技术安全概念中显示相关，否则距离严格大于2的多点故障视为安全故障。
注意，在瞬态故障的情况下，安全机制将相关项恢复到无故障状态，即使从未通知驾驶员其存在，此类故障视为可检测的多点故障。如在使用纠错码保护存储器不受瞬态故障影响的情况下，安全机制除了向CPU提供正确的值之外，还修复存储器阵列内翻转位的内容（如通过写回校正值），则该相关项恢复到无故障状态。
2.1.1. 单点故障
没有任何安全机制预防的硬件要素的故障，该故障可直接导致违背安全目标。例如至少一种失效模式（例如开路）可能违背安全目标的无监控电阻。
2.1.2. 残余故障
有至少一个安全机制预防某硬件要素违背安全目标的故障，该故障可直接导致违背安全目标。例如仅用棋盘RAM测试的安全机制来检查随机存储器（RAM）模块，则不能检测出某些种类的桥接故障。 因这些故障导致的对安全目标的违背不能被安全机制s覆盖。这些故障即为残余故障，此时安全机制的诊断覆盖率低于100%。
2.1.3. 可检测的双点故障
被防止其潜伏的安全机制所检测的且仅与另一个（双点故障有关的）独立硬件故障联合才能导致违背安全目标的故障。例如被奇偶校验保护的闪存故障，按照技术安全概念对单个位故障进行检测并触发响应如：关闭系统并通过警示灯通知驾驶员。
2.1.4. 可感知的双点故障
在规定的时间内，驾驶员在安全机制可检测或未可检测的情况下可感知到且仅与另一个（双点故障有关的）独立硬件故障联合才能导致违背安全目标的故障。例如功能明显且明确地受到故障后果的影响，驾驶员可感知到的双点故障。
2.1.5. 潜伏的双点故障
不被安全机制检测也不被驾驶员感知，在第二个独立硬件故障发生前，系统始终可运行且驾驶员不被告知的故障。
例如对于被EDC保护的闪存：在读取时ECC纠正了单个位的永久性故障值，但这不是在闪存中纠正也无信号指示。在此情况中.故障不能导致安全目标的违背（因故障位已得到了纠正），但它既不可检测（因对单个位故障无信号指示）又不可感知（因对应用的功能性无影响）。如果在EDC逻辑中发生了额外的故障，它可导致失去对单个位故障的控制，从而导致潜在的安全目标的违背。
2.1.6. 安全故障
安全故障包括以下两类：
a）n>2的所有n点故障，除非安全概念表明它们是违背安全目标的相关因素；或
b）不会导致违背安全目标的故障。
例如在闪存受ECC和循环冗余校验（CRC）保护的情况下，由ECC纠正但未发出信号的单个位故障。ECC可以防止故障违背安全目标，但ECC不会发出信号。如果ECC逻辑出现故障，CRC将可检测故障，系统将关闭。只有当闪存中存在单个位故障且ECC逻辑失效并且CRC校验和监控失效时，才会违背安全目标（n=3）。
2.2. 硬件要素的失效模式和失效率
2.2.1. 硬件要素的失效模式
按照故障分类模式，硬件要素的失效模式分类如图10所示。
2.2.2. 硬件要素失效模式分类流程
失效模式分类流程如图11所示。
其中：
λSPF是与硬件要素单点故障相关的失效率
λRF是与硬件要素残余故障相关的失效率
λMPF是与硬件要素多点故障相关的失效率
λS是与硬件要素安全故障相关的失效率。
与硬件要素多点故障相关的失效率，λMPF，可根据公式（1‑1）表示，如下所示：
λMPF = λMPF,DP + λMPF,L（1‑1）
其中：
λMPF，DP是与硬件要素可感知或可检测的多点故障相关的失效率
λMPF，L是与硬件要素潜伏故障相关的失效率。
2.3. 硬件架构度量
硬件架构的度量用于评估相关项架构应对随机硬件失效的有效性。
硬件架构的度量目标在于：
- 客观上可评估：度最是可核实的，并且足够精确以区分不同的架构；
- 支持最终设计的评估（基于详细的硬件设计完成精确计算）；
- 为硬件架构提供基于ASIL等级的合格/不合格准则；
- 显示用于防止硬件架构中单点或残余故障风险的安全机制的覆盖率是否足够（单点故障度量）；
- 显示用于防止硬件架构中潜伏故障风险的安全机制的覆盖率是否足够（潜伏故障度量）；
- 处理单点故障、残余故障和潜伏故障；
- 确保硬件架构的鲁棒性；
- 仅限于安全相关要素；
- 支持不同要素层面的应用，例如可以为供应商的硬件要素分配目标值。例如为方便分布式开发.可为微控制器或者ECU分配目标值。
2.3.1. 单点故障度量
单点故障度量通过安全机制的覆盖率或设计（主要是安全故障）反映相关项对单点和残余故障的鲁棒性。较高的单点故障度量意味着相关项硬件中单点故障和残余故障的比例较低。
对安全目标为ASIL（B）、C和D等级的硬件设计，公式（1‑2）用于确定单点故障度量：
仅考虑相关项的安全相关硬件要素。安全故障或n阶多点故障（n>2）的硬件要素可从计算中省略，除非与技术安全概念明确相关。图12给出了单点故障度量的图示。
2.3.2. 潜伏故障度量
潜伏故障度量通过安全机制覆盖或驾驶员在违背安全目标之前识别到故障存在或通过设计（主要是安全故障）反映相关项对潜伏故障的鲁棒性。高潜伏故障度量意味着硬件中潜伏故障的比例较低。
对安全目标为ASIL（B）、（C）和D等级的硬件设计，公式（1‑3）用于确定潜伏故障度量：
仅考虑相关项的安全相关硬件要素。安全故障或n阶多点故障（n>2）的硬件要素从计算中省略，除非在技术安全概念中明确相关。图13给出了潜伏故障度量的图示。
2.3.3 随机硬件失效概率度量（PMHF）
PMHF值的计算公式如（1‑4）所示:
PMHFest = λSPF + λRF+ λDPF_det × λDPF_latent × Tlifetime（1‑4）
对于每种失效模式，以百分比为单位计算对整个PMHF值的贡献。
2.4 硬件架构度量目标值
对于硬件架构设计的具体指标度量，标准提供了相应目标值（如表1所示），这些目标值通常取决于硬件设计需要满足的最高ASIL等级。对ASIL A等级，标准并没有建议目标值，对ASIL D等级，标准建议最严格的目标值，对于ASIL B和ASIL C的某些情况下，这些指标是标准意义上的建议而不是强制性的要求。
软件设计阶段的安全分析
1. 安全相关功能和属性
软件安全需求的导出应考虑到软件所需的与安全相关功能和安全相关属性，安全相关功能失效或安全相关属性失效可能导致违反分配给软件的技术安全需求。
软件的安全相关功能通常包括：
- 能够安全执行标称功能的功能
- 使系统能够达到或维持安全状态或降级状态的功能
- 与检测、指示和缓解安全相关硬件要素故障相关的功能
- 与检测、指示和缓解操作系统、基础软件或应用软件本身失效相关的自检或监控功能
- 与生产、运行、服务和报废期间的板载或非板载测试相关的功能
- 允许在生产和服务期间修改软件的功能
- 与性能或时间关键型操作相关的功能
安全相关的属性通常包括：
- 对错误输入的鲁棒性
- 不同功能之间的独立性或免干扰性
- 软件的容错能力等
2. 软件架构设计阶段的安全分析
在软件架构设计阶段，我们应该进行相应的软件安全分析活动，标准称之为面向安全的分析方法。面向安全的分析本质上是定性分析。首先,面向安全的分析帮助提供证据，证明我们的软件是否适合根据所需的ASIL等级要求提供指定的安全相关功能和属性。其次，面向安全的分析帮助我们识别或确认与安全相关的软件内容。最后，面向安全的分析支持安全机制开发，进而验证安全措施的有效性。
依赖于安全相关要素间的免干扰性或充分独立性的要求，标准建议进行相关失效分析（DFA）。相关失效分析确认相关失效或潜在的相关失效及其影响。相关失效分析的目标和范围取决于子阶段和执行分析的抽象级别，相关失效的内容在进行分析之前(如在安全计划中)定义。这部分也属于定性分析的内容。
3. 软件架构层面安全相关失效分析
嵌入式软件提供指定功能、行为和属性的能力，以及指定ASIL所要求的完整性，通过在软件架构层面应用安全相关失效分析来检查或确认相应安全功能和属性及对应分配的ASIL要求的完整性。
3.1 软件架构层面安全分析目的
在软件架构设计阶段，通过进行相关失效分析，我们需要找出可能导致需要满足独立性的多个软件要素失效行为的可能的单一事件，故障或失效（如级联和/或共因失效，包括共模失效），和可能诱发因果链，导致违反安全需求，从一个软件要素传播到另一个软件要素的单一事件、故障或失效（如级联失效）。通过软件架构设计阶段的相关失效分析，检查相关软件架构要素间所达到的独立性或免干扰性的程度。
3.2 软件架构层面安全分析内容
软件架构层面相关失效分析考虑如下方面：
- 识别可能诱发因果链条导致违反安全需求的可能的设计弱点、条件、故障或失效（如使用归纳或演绎方法）
- 分析软件架构要素所需的功能和属性上可能出现的故障、失效或因果链的后果
3.3 软件架构层面相关失效分析的应用场景
以下场景可能需要进行软件架构层面相关失效分析：
- 在软件层面应用ASIL分解
- 实现软件安全需求，如为软件安全机制的有效性提供证据，被监控要素和监控要素之间需满足独立性要求
- 软件架构要素共存需要
4. 由软件架构层面安全分析导出安全机制
安全措施包括从面向安全分析中得出的安全机制，涵盖与随机硬件故障和软件故障相关的问题。在软件架构层面进行的安全分析的结果，需要实施错误检测安全机制和错误处理安全机制。
4.1 错误检测安全机制
错误检测的安全机制包括：
- 输入和输出数据的范围检查
- 合理性检查（如使用所需行为的参考模型，断言检查或比较不同来源的信号）
- 数据错误检测（如错误检测代码和冗余数据存储）
- 外部要素监控（如ASIC）或执行看门狗功能的另一个软件要素执行程序。监控可以是逻辑监控或时间监控，或两者兼有
- 程序执行的临时监控
- 多样化冗余设计
- 在软件或硬件中实现的访问违规控制机制，用于授权或拒绝对与安全相关共享资源的访问权限
图14示例说明了由共享资源（例如共享处理要素）的使用冲突引起的干扰。QM软件要素干扰并阻止ASIL软件要素的及时执行（这种干扰也可能发生在具有不同ASIL值的软件组件之间）。图示上半部分显示了在没有免干扰性机制的情况下软件执行的情况。通过将“检查点”引入软件并对检查点实施超时监控，可检测到定时干扰并启用适当的应对措施。
4.2 错误处理安全机制
错误处理安全机制包括：
- 停用以达到并保持安全状态
- 静态恢复机制（例如模块恢复、向后恢复、向前恢复和通过重复恢复）
- 通过优先处理功能来优雅地降级，以最大限度地减少潜在失效对功能安全的不利影响
- 设计中的同质冗余，主要侧重于控制执行类似软件的硬件中的瞬时故障或随机故障的影响（如软件的临时冗余执行）
- 设计中的多样化冗余，这意味着每个并行路径中的设计不同软件，并且主要侧重于预防或控制软件中的系统性故障
- 更正数据的代码
- 在与授予或拒绝与安全相关的共享资源的访问权限有关的软件或硬件中实施的访问权限管理
需要注意的是，可进行系统级软件安全机制（包括鲁棒性机制）审查来分析对系统行为的潜在影响以及与技术安全需求的一致性。
参考文献
- International Organization for Standardization. (2018). Road vehicles — Functional safety — (ISO 26262:2018). https://www.iso.org/standard
