安全分析方法
ISO 26262要求根据不同ASIL等级组合地使用“演绎分析”和“归纳分析”，如下表所示：

根据上表所列信息，开发团队会常常误认为ASIL B是不需要执行“演绎分析”。事实上，ISO 26262的要求对于连续数字（1，2，3……）所列方法，“+”、“++”分别是推荐、强烈推荐实施的。因此，ASIL B也是推荐实施“演绎分析”的（若没有实施，则需要提供理由）。
演绎分析：人们以一定反映客观规律的理论认识为依据，从服从该事物的已知部分，推理得到事物的未知部分的思维方法。即，从一般规律到个例。通常，“演绎分析”方法采用FTA（Fault Tree Analysis，故障树分析）。
归纳分析：人们以一系列经验事物或知识素材为依据，寻找出其服从的基本规律或共同规律，并假设同类事物中的其他事物也服从这些规律。即：从个例到一般规律。通常，“归纳分析”方法采用FMEA（Failure Mode and Effects Analysis，失效模式和影响分析）。

FMEA分析步骤
关于FMEA方法，建议参考AIAG-VDA FMEA手册，市面上已经有很多成熟的软件工具支持FMEA分析。值得一提的是，在根据AIAG-VDA第5版FMEA手册中，增加FMEA-MSR（Monitoring and System Response，监视和系统响应），作为DFMEA的补充。
通常，FMEA按下图所示的七步法进行：

1、DFMEA分析步骤
第1步-策划和准备：确定负责人和团队、项目名称、时间安排和分析工具等信息。
第2步-结构分析：结构化分析对象，例如设计系统架构。

第3步-功能分析：产品功能可视化，例如确定系统架构要素的功能。第3步是在第2步的基础上实施的，因此第2步的“要素”和第3步的“功能”是对应的。

第4步-失效分析：每个功能的潜在失效影响，失效模式和失效起因。

第5步-风险分析：分析针对失效起因的现行预防控制；分析针对失效起因和（或）失效模式的现行探测控制。

第6步-优化：识别、实施降低风险的必要措施。

第7步-结果文件化
将上述第1步～第6步的实施情况记录在FMEA模板或分析工具中，形成完整的FMEA报告。FMEA的总结与分析，包含以下内容：
a.文件化FMEA过程中的所有分析记录和采取的措施；
b.组织内部/顾客/供应商对结果和分析结论进行沟通，组织FMEA评审验证；
c.持续跟进预防措施和探测措施的实施情况，定期动态更新AP值，确保在设计定稿前风险已降到可接受的程度。

2、FMEA-MSR
2.1、FMEA-MSR决策流程
FMEA-MSR作为DFMEA的补充，更加关注产品在实际用户条件下的失效，因此进一步地完善了FMEA在安全相关机电系统（所谓机电系统就是系统中至少包括传感器、电子控制器和执行器或它们的组件）领域的应用。在实际项目开发过程中，研发人员容易把DFMEA和FMEA-MSR搞混，导致了许多重复或遗漏的分析工作。
下图展示了FMEA-MSR决策流程，提供了一个DFMEA和FMEA-MSR配合使用的思路。

1)在上述流程中，若一个失效模式的严重度被评为8、9、10分，则认为是违背法律法规或功能安全要求。
2)若上述1)不成立，继续执行第5、6步的DFMEA分析。可选择性地根据组织现有流程以及改进计划，增加MSR机制。
3)若上述1)成立，则此时需要分析系统是否已经存在针对客户操作期间发生该失效模式的MSR机制。
4)若上述3）不成立，继续执行第5、6步的DFMEA分析，必须增加MSR机制。增加MSR机制后，由于作了设计变更，因此更新DFMEA，更新后上述第3)点成立，执行第5)点。这里需要注意的是，作为MSR本身而言，通过DFMEA来分析即可。
5)若上述3）成立，则此时直接针对该失效模式进行FMEA-MSR分析。
总结上述内容，下图提供一个形成DFMEA文件和FMEA-MSR文件的思路。事实上，两者既可合并在一起，也可以单独形成文件，取决于开发组织自身的流程。

2.2、FMEA-MSR分析步骤
FMEA-MSR同样采用图1所示的七步法，且仅第5、6步与DFMEA不同，下面只针对这两个步骤的分析展开描述。
第5步-风险分析（FMEA-MSR）：分析失效模式发生频率F（也可称为频度），指系统在实际工作时间内产生失效的频率，该频率需要统计数据论证其合理性；分析针对失效起因的现行诊断监视；分析针对诊断到失效模式后的现行系统响应；分析MSR起作用后的失效影响严重度。

第6步-优化（FMEA-MSR）：识别、实施降低风险的必要措施。

FMEA分析示例
如下图所示，假设现有一个用于ADAS系统的ALC（自动车道居中）的ECU（电子控制单元）的系统架构，其主要功能是从Ext_01接口接收外部传感器SPI数据，作为MCU的路径规划决策输入。

1、DFMEA的分析示例
以下示例假设其中一个模块（Sys_element01）故障，假设ECU针对Sys_element01故障没有任何诊断监视措施，按照DFMEA的分析步骤展开。

1）识别每个模块的功能，例如Sys_element01的主要功能是向MCU传输传感器数据；（DFMEA第3步）
2）识别模块的失效行为，例如Sys_element01故障导致传感器数据错误、延迟、丢失等；（DFMEA第4步）
3）确定传感器数据错误将导致的后果严重程度（得到严重度S评分），例如：该故障发生时导致MCU路径规划错误，影响行车安全，严重度达到S=10；（DFMEA第4步）
4）确定是否存在预防控制措施，例如，该系统架构使用可信的设计方案、使用鲁棒性设计、通过设计评审等；（DFMEA第5步）
5）定在上述预防控制措施之下该模块的故障频度（得到频度O评分），例如：已使用可信设计、鲁棒性设计、设计评审后，故障频度可降至O=2；（DFMEA第5步）
6）确定是否存在探测控制措施，例如，功能测试、故障注入测试、DV测试、量产测试等；（DFMEA第5步）
7）确定上述探测控制措施的探测度（得到探测度D评分）；例如：实施功能测试、故障注入测试、DV测试、量产测试后，探测度可达D=3；（DFMEA第5步）
8）根据S、O、D评分，综合得出措施优先级AP值，AP=L；（DFMEA第5步）
9）必要时，根据AP值，制定进一步的风险降低措施；（DFMEA第6步）
10）文件化将上述分析步骤。（DFMEA第7步）
根据第3)步骤显示，该示例中的ECU是一个安全相关的机电系统，且存在失效模式导致违背功能安全，满足2.1节FMEA-MSR决策流程第4)的条件，在后续的设计优化中必须增加MSR机制。

2、FMEA-MSR的分析示例
本节基于前面1节DFMEA的分析示例的ECU示例，在其基础上增加了MSR机制，优化了该ECU的系统架构，如下图所示。其中绿色模块（安全相关）为分配了ASIL等级的安全需求，灰色模块（非安全相关）开发为QM要素。其中：
· Sys_element04开发为安全要素；
· 增加Sys_element06用于诊断来自Sys_element01的数据的正确性和一致性；
· 增加Sys_element07故障收集和诊断模块；
· 增加Sys_element08用于诊断MCU内部失效。

下面同样假设其中一个模块（Sys_element01）故障，假设ECU针对Sys_element01故障已经采取诊断监视措施，按照FMEA-MSR的分析步骤展开。

1）识别每个模块的功能，例如Sys_element01的主要功能是向MCU传输传感器数据；（FMEA-MSR第3步）
2）识别模块的失效行为；例如：假设Sys_element01（SPI通信模块）故障导致传感器数据错误；（FMEA-MSR第4步）
3）确定传感器数据错误将导致的后果严重程度（得到严重度S评分），例如：该故障发生时导致MCU路径规划错误，影响行车安全，严重度达到S=10；（FMEA-MSR第4步）
4）确定该模块的故障频率（得到频率F评分），例如，这里假设Sys_element01在其使用生命周期内故障发生的概率非常低（实际项目中应结合可靠性预测结果来评估），频率F=3；（FMEA-MSR第5步）
5）确定系统中是否有监控措施（即监视和系统响应，或者称之为安全机制）及其监控能力，例如，该Sys_element01发生故障时，不能通过Sys_element06的校验，由Sys_element07向上级系统发出错误警报（如图7红色曲线路径所示），假设该安全机制的诊断覆盖率为99%，监视则可评定为M=3。在汽车功能安全中，一个非常重要的概念是FTTI（故障容错时间间隔），如下图所示。

FTTI可以用来衡量安全机制的有效性，它来自车辆层面的安全目标，用于表示车辆部件在某个场景下发生故障直到产生对人身产生危害事件的这段时间间隔。进一步地细分，相关的时间概念还有FDTI（故障检测时间隔离）、FRTI（故障响应时间时间）以及FHTI（故障处理时间间隔）。在设计监视和系统响应机制时需要考虑上述时间约束，确保系统或子系统满足分配其的时间要求：FDTI + FRTI = FHTI < FTTI。（FMEA-MSR第5步）
6）分析在MSR起有效作用后，即系统响应安全机制后失效的严重度；例如，如上述第5)点的监控措施启动后，车辆通知向驾驶员发出接管方向盘的警示，尽管车道偏离可能已经偏离，但在FTTI的时间内驾驶员已经及时接管方向盘并将方向回正（假设驾驶员有能力处理这种情况），此时原先定义的严重度可适当降低到S=6；（FMEA-MSR第5步）
7）根据S、F、M评分，综合得出措施优先级AP值，AP=L；（FMEA-MSR第5步）
8）必要时，根据AP值，制定进一步的风险降低措施；（FMEA-MSR第6步）
9）文件化将上述分析步骤。（DFMEA第7步）
这里需要注意的是，如2.1FMEA-MSR决策流程第4）点所述，对比DFMEA的分析示例：
· Sys_element04由于设计变更（由原先的QM要素开发为安全要素），需要更新其先前的DFMEA结果；
· 新增Sys_element06~08的三个模块，需要新增它们的DFMEA。