功能安全--安全分析

在ISO26262功能安全中，有多个地方需要进行安全分析，安全分析的质量很重要的决定了功能安全项目的成败，本文针对ISO26262中提到的各种安全分析进行汇总说明（HARA、FMEA、FTA、FMEDA、SWFMEA、DFA）。

1. HARA

在概念阶段，功能安全要求进行HARA分析。

 HARA（危害分析与风险评估）目的是识别项目的功能故障引起的危害，对危害事件进行分类，然后定义与之对应的安全目标，以避免不可接受的风险。

HARA分析步骤：

SEC说明： 

ASIL等级说明： 

QM指的是 质量管理，表示此项功能不影响安全，通过质量管理保证即可。

 举例说明：

HARA分析示例

危害事件	场景分析	S	E	C	ASIL
EPS按照非预期的方向转向	在城市道路，车辆正常匀速行驶（E4），车辆方向按照非预期转向，此时驾驶员很难控制(C3)，道路两边人员较多，可能造成路人或者驾驶员的伤亡(S3)	3	4	3	D

2. FMEA

在系统阶段，功能安全要求针对各种失效模式进行分析。

FMEA是一种自下而上的归纳分析方法，用于识别系统失效(failure)，找出失效原因(Fault)，以及分析失效影响(Effect)。

分析步骤（典型七步法）：

（参考：http://www.ts16949rz.org/fmeapx/2395.html） 

 目前新版的使用AP值代替了原来的RPN方法，以下进行说明。

SOD说明：

 

AP说明：

AP	H	M	L
说明	高优先级，表示需有必要措施（shall），以改进预防或探测控制	中优先级，应有必要的措施（should），以改进预防或探测控制	低优先级，可有(could)措施进行改进预防或探测控制

 AP优先级定义：

典型FMEA表格（新老版的）：

 

3. FTA

在系统阶段，ISO26262还要求进行FTA（故障树分析）；

FTA是一种自上而下的演绎分析方法，用于识别失效原因及失效间的关系，目前针对FTA也只是做定性分析。

分析步骤：

1. 确定顶事件，一般为在整车角度描述的影响到安全目标的事件，如针对EPS，顶事件可定义为非驾驶员意图的转向，针对MCU，顶事件可定义为非预期的加速等。

2. 分解中间事件，针对顶事件，根据系统组成或特点，进行分解，系统外界以及系统内部一般都需要考虑在内。

3.基本事件，中间事件继续向下分析，得到无法再分解的事件，他们是组成系统顶事件失效的根本原因。

常用的符号：

典型FTA图： 

4.FMEDA 

在硬件设计阶段，ISO26262要求进行定量的安全分析。

 由于功能安全标准中已有对其进行较为详细的介绍，本文更多的是从中进行汇总摘要。

故障类别：

失效分析过程：

 

 失效率：

λS P F — — —与硬件要素单点故障相关联的失效率;
λRF — — —与硬件要素残余故障相关联的失效率;
λMPF— — —与硬件要素多点故障相关联的失效率;
λS — — —与硬件要素安全故障相关联的失效率。

 

 

 单点故障度量：

潜伏故障度量：

总体计算过程：

 5. SWFMEA

在软件阶段，ISO26262要求对软件架构进行安全分析，此处也是定性分析。

SWFMEA分析的目的在于找出影响到功能安全的软件失效，从而可以增加探测或诊断覆盖来提高系统的安全。

SWFMEA，分析过程可参考系统FMEA，只是这里的分析对象略有差异，以下针对差异进行说明。

SWFMEA，主要针对架构元素进行分析，如针对接口，分析其传入的参数的异常情况、错误调用接口情况等；针对函数，分析其传参的异常情况、调度的异常情况（没调用、调用过快、过慢等）、数据的一致性分析、资源消耗异常等情况。

安全机制的覆盖度，可参考ISO26262标准附录。

6.DFA

DFA指的是相关性分析，ISO26262要求从三个层面（系统、硬件、软件）分析，找出系统中的共因以及级联失效。

若系统进行了ASIL分解，则DFA必须分析，以此作为系统分解后的证据。

级联失效：

任一失效，系统都会失效；

 

共因失效：

失效后，冗余措施不起作用。

 系统分析角度：

        系统架构、系统边界、系统人员、系统环境、系统开发生产维护等过程。

硬件分析角度：

      硬件架构、硬件选型、硬件人员、供电电源等。

软件分析角度：

      CPU共享资源、软件架构、软件人员、软件工具、算法方案等。