MUNIK解读ISO26262--什么是系统安全分析

功能安全之系统阶段-系统安全分析

安全分析在ISO26262标准中横跨了多个阶段例如：概念阶段、系统架构阶段、硬件详设阶段和软件详设阶段，其中part5中的安全分析工具FMEDA是标准中唯一一个和ASIL等级挂钩的，在Part5中也用了很大篇幅在介绍该安全分析的实施。我们本篇是写系统阶段的安全分析，我会用以下几个话题来讨论系统阶段的安全分析是怎样的。

1. 为什么要做安全分析？
2. 标准中对于系统阶段安全分析的定义
3. 系统层级安全分析的示例说明

1.为什么要做安全分析

在ISO 26262标准中，安全分析是一个关键的过程，旨在确保汽车电子系统的安全性。

安全分析的目的是识别潜在的危险和风险，评估这些风险的严重性和可能性，并制定相应的措施来减轻或消除这些风险，以保证系统在各种情况下都能维持在安全状态。

简单来讲就是安全分析和仿真一样属于产品研发阶段做的事前的分析，它可以预测产品的可靠性，判断系统的鲁棒性并且依据当前的薄弱点设计安全措施并制定持续优化的改进过程。因此，安全分析并非是一蹴而就的事情。

2. 标准中对于系统阶段安全分析的定义

在ISO26262标准的Part4 中的Table 1中给出了在系统阶段安全分析的方法，如下图所示。

演绎法（Deductive Analysis Method）：通常使用FTA的方法，是一种自上而下的分析方法，它从已知的影响出发，通过逻辑推理来寻找可能的原因。

归纳法（Inductive Analysis Method）：在系统层级使用方法通常是FMEA，归纳法是一种自下而上的分析方法，它从已知的原因出发，通过观察和实验来预测可能的影响。

上述两种方法是系统阶段的两种方法对用的工具，为了清晰表达出来每个阶段的安全分析方法，我总结了如下的表格：

 

在此篇中我们着重介绍系统阶段的安全分析，其他的不在此处赘述（会在其他的文章中体现，DFA可参考我们之前的文章：“功能安全之DFA相关失效分析”，其余的安全分析类的解读文章会陆续更新）

标准中要求在进行系统架构的安全分析时参考：“ISO 26262-9:2018, Clause 8”,其目的在于:

（1）为系统设计的适合性提供证据,以证明其适合提供与ASIL等级相适应的特定安全相关功能和特性;

（2）识别失效原因和故障影响;

识别或确认安全相关系统要素和接口;

（3）支持设计规范,并基于已识别的故障原因和失效影响验证安全机制的有效性。

3. 系统层级安全分析的示例说明

  FTA

FTA在系统阶段的作用是通过SG导出FSR，通过FSR导出TSR，适用于复杂的系统，该方法是可选择的（不一定必须使用），在我们的前期分享的标准解读文章（链接点击此处：MUNIK解读ISO26262：功能安全之概念阶段-FSC-FSR-MUNIK），文章中图二有提到使用FTA的方法从SG导出FSR的过程，在此不在赘述，大家感兴趣的可以去看看。

FMEA

FMEA在系统阶段和详设阶段主要的不同是“层级”不同，分析方法完全是一致的，以MCU举个例子来讲：

MCU架构

以上述MCU为例，对比下在系统阶段的FMEA和详设阶段的不同。

系统阶段FMEA的层级，核心本质是分析子系统之间的失效及其影响，包括各个子系统之间的交互相关的故障模式。

详设阶段FMEA的层级，可以理解为分析到最底层的失效器件，找出失效原因及失效风险，依据失效导出详设层级的安全机制。

注释：后续会有更详细的安全分析类的文章，如果想了解更多内容，请关注Munik网站或公众号。

DFA

   DFA相关性分析在系统层级的本质是分析系统层级存在的级联失效以及共因失效，共因失效及级联失效图如下所示：

共因失效图                      级联失效图

共因失效：共同原因导致的一个相关项的两个或多个要素的失效

级联失效：Element A 的实效结果导致了Element B的失效，失效有先后。

在系统层面的分析可以参考以下几个维度：

（1）共享资源：例如共同的看门狗电路，共用时钟模块等

（2）共享信息输入：共同的模拟供电等

（3）环境免疫：EMC、EMI、ESD干扰、温度和振动等

（4）系统耦合：相同的生产过程、修复过程等

（5）通讯：相同的通讯类型（SPI、CAN等）

总结：通过安全分析，ISO 26262标准确保汽车电子系统在整个生命周期内都能保持高水平的安全性，从而保护驾驶员、乘客和其他道路用户免受伤害。