在ISO26262功能安全中，有多个地方需要进行安全分析，安全分析的质量很重要的决定了功能安全项目的成败，本文针对ISO26262中提到的各种安全分析进行汇总说明（HARA、FMEA、FTA、FMEDA、SWFMEA、DFA）。HARA
HARA（危害分析与风险评估）目的是识别项目的功能故障引起的危害，对危害事件进行分类，然后定义与之对应的安全目标，以避免不可接受的风险。QM指的是 质量管理，表示此项功能不影响安全，通过质量管理保证即可。
举例说明：
EPS按照非预期的方向转向 在城市道路，车辆正常匀速行驶（E4），车辆方向按照非预期转向，此时驾驶员很难控制(C3)，道路两边人员较多，可能造成路人或者驾驶员的伤亡(S3) 3 4 3 DFMEA
在系统阶段，功能安全要求针对各种失效模式进行分析。FMEA是一种自下而上的归纳分析方法，用于识别系统失效(failure)，找出失效原因(Fault)，以及分析失效影响(Effect)。（参考：http://www.ts16949rz.org/fmeapx/2395.html） 目前新版的使用AP值代替了原来的RPN方法，以下进行说明。FTA
在系统阶段，ISO26262还要求进行FTA（故障树分析）；FTA是一种自上而下的演绎分析方法，用于识别失效原因及失效间的关系，目前针对FTA也只是做定性分析。1. 确定顶事件，一般为在整车角度描述的影响到安全目标的事件，如针对EPS，顶事件可定义为非驾驶员意图的转向，针对MCU，顶事件可定义为非预期的加速等。2. 分解中间事件，针对顶事件，根据系统组成或特点，进行分解，系统外界以及系统内部一般都需要考虑在内。3.基本事件，中间事件继续向下分析，得到无法再分解的事件，他们是组成系统顶事件失效的根本原因。FMEDA
在硬件设计阶段，ISO26262要求进行定量的安全分析。 由于功能安全标准中已有对其进行较为详细的介绍，本文更多的是从中进行汇总摘要。λS P F — — —与硬件要素单点故障相关联的失效率;λRF — — —与硬件要素残余故障相关联的失效率;λMPF— — —与硬件要素多点故障相关联的失效率;λS — — —与硬件要素安全故障相关联的失效率。SWFMEA
在软件阶段，ISO26262要求对软件架构进行安全分析，此处也是定性分析。SWFMEA分析的目的在于找出影响到功能安全的软件失效，从而可以增加探测或诊断覆盖来提高系统的安全。SWFMEA，分析过程可参考系统FMEA，只是这里的分析对象略有差异，以下针对差异进行说明。SWFMEA，主要针对架构元素进行分析，如针对接口，分析其传入的参数的异常情况、错误调用接口情况等；针对函数，分析其传参的异常情况、调度的异常情况（没调用、调用过快、过慢等）、数据的一致性分析、资源消耗异常等情况。安全机制的覆盖度，可参考ISO26262标准附录。DFA
DFA指的是相关性分析，ISO26262要求从三个层面（系统、硬件、软件）分析，找出系统中的共因以及级联失效。若系统进行了ASIL分解，则DFA必须分析，以此作为系统分解后的证据。系统架构、系统边界、系统人员、系统环境、系统开发生产维护等过程。CPU共享资源、软件架构、软件人员、软件工具、算法方案等
版权声明：本文为CSDN博主「AgingMoon」的原创文章，遵循CC 4.0 BY-SA版权协议，获作者转载许可。想转岗自动驾驶，一文告诉你该如何开始
车辆诊断系统中的安全挑战
关于 ASPICE 的理解
详解汽车Bootloader设计
特斯拉Autopilot系统安全研究|附dbc下载
详解功能安全概念阶段
详细揭秘大众ID.4的高压系统
特斯拉Model 3的BMS系统
