功能安全--安全分析

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

01

HARA

在概念阶段，功能安全要求进行HARA分析。
HARA（危害分析与风险评估）目的是识别项目的功能故障引起的危害，对危害事件进行分类，然后定义与之对应的安全目标，以避免不可接受的风险。
HARA分析步骤：
SEC说明：
ASIL等级说明：
QM指的是 质量管理，表示此项功能不影响安全，通过质量管理保证即可。

举例说明：

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

02

FMEA

在系统阶段，功能安全要求针对各种失效模式进行分析。
FMEA是一种自下而上的归纳分析方法，用于识别系统失效(failure)，找出失效原因(Fault)，以及分析失效影响(Effect)。
分析步骤（典型七步法）：
（参考：http://www.ts16949rz.org/fmeapx/2395.html）
目前新版的使用AP值代替了原来的RPN方法，以下进行说明。
SOD说明：
AP说明：
AP优先级定义：
典型FMEA表格（新老版的）：

03

FTA

在系统阶段，ISO26262还要求进行FTA（故障树分析）；
FTA是一种自上而下的演绎分析方法，用于识别失效原因及失效间的关系，目前针对FTA也只是做定性分析。
分析步骤：
1. 确定顶事件，一般为在整车角度描述的影响到安全目标的事件，如针对EPS，顶事件可定义为非驾驶员意图的转向，针对MCU，顶事件可定义为非预期的加速等。
2. 分解中间事件，针对顶事件，根据系统组成或特点，进行分解，系统外界以及系统内部一般都需要考虑在内。
3.基本事件，中间事件继续向下分析，得到无法再分解的事件，他们是组成系统顶事件失效的根本原因。
常用的符号：
典型FTA图：

04

FMEDA

在硬件设计阶段，ISO26262要求进行定量的安全分析。
由于功能安全标准中已有对其进行较为详细的介绍，本文更多的是从中进行汇总摘要。
故障类别：
失效分析过程：
失效率：
λS P F — — —与硬件要素单点故障相关联的失效率;
λRF — — —与硬件要素残余故障相关联的失效率;
λMPF— — —与硬件要素多点故障相关联的失效率;
λS — — —与硬件要素安全故障相关联的失效率。
单点故障度量：
潜伏故障度量：
总体计算过程：

05

SWFMEA

在软件阶段，ISO26262要求对软件架构进行安全分析，此处也是定性分析。
SWFMEA分析的目的在于找出影响到功能安全的软件失效，从而可以增加探测或诊断覆盖来提高系统的安全。
SWFMEA，分析过程可参考系统FMEA，只是这里的分析对象略有差异，以下针对差异进行说明。
SWFMEA，主要针对架构元素进行分析，如针对接口，分析其传入的参数的异常情况、错误调用接口情况等；针对函数，分析其传参的异常情况、调度的异常情况（没调用、调用过快、过慢等）、数据的一致性分析、资源消耗异常等情况。
安全机制的覆盖度，可参考ISO26262标准附录。

06

DFA

DFA指的是相关性分析，ISO26262要求从三个层面（系统、硬件、软件）分析，找出系统中的共因以及级联失效。
若系统进行了ASIL分解，则DFA必须分析，以此作为系统分解后的证据。
级联失效：
任一失效，系统都会失效；
共因失效：
失效后，冗余措施不起作用。
系统分析角度：
系统架构、系统边界、系统人员、系统环境、系统开发生产维护等过程。
硬件分析角度：
硬件架构、硬件选型、硬件人员、供电电源等。
软件分析角度：
CPU共享资源、软件架构、软件人员、软件工具、算法方案等
版权声明：本文为CSDN博主「AgingMoon」的原创文章，遵循CC 4.0 BY-SA版权协议，获作者转载许可。
赞 (0)

相关推荐