详细介绍：
?
在功能安全设计过程中，执行失效分析是必要的环节之一，传统的基于硬件器件的失效分析已经较为成熟，但基于软件设计的失效分析还不为很多人了解，本文对软件失效分析进行初步的概述，后续将持续推出更多的详细介绍文章。
1、基本原理
软件HAZOP的基本流程和方法说明见标准《危险与可操作性分析(HAZOP)应用指南》。
软件FMEA和FTA的基本流程见《Software FMECA and FTA Guidance》。
2、对于可编程电子（PES）相关的HAZOP引导词
引导词 | 标准解释 | 在PES中的解释 |
No | 完全没有达到设计意图 | 没有信号（信息）通过 |
More | 数量上的增加 | 比预期有更多的信号（信息）通过。 对于某个特定的值（变量），意味着这个值（变量）太高了。 |
Less | 数量上的减少 | 和PART OF是相同的 |
As well as | 性质上的变化（增多） | 和MORE是相同的 |
Part of | 性质上的变化（减少） | 信号信息不完整 |
Reverse | 与设计意图逻辑相反 | 一般不使用 |
Other than | 完全替代 | 信号信息是完整的并且语法正确，但内容/功能/语义不正确 |
Early | 早 | 信号到达得过早，相对于参考时钟时间 |
Before | 晚 | 信号比预期的顺序达到得要早 |
Late | 先 | 信号到达得过晚，相对于参考时钟时间 |
After | 后 | 信号比预期的顺序达到得要晚 |
3、软件失效分析的目的
在IEC61508的生命周期模型中，明确给出了需要执行软件验证。软件验证一般可以采用设计复审的方式，但该方法的缺点是如果没有一套专门的导则，复审可能难以按照一套系统化的方式实施（可能只能零散的检查、讨论等）。因此复审的输出非常依赖于开展该工作的人员。采用软件失效分析可以采用更加系统化的方式实施验证活动。
另一方面，由于系统性失效不能在软件开发过程中完全避免，因此必须采用特定的故障措施（例如断言）来控制可能发生的软件失效，这些故障控制措施在对软件进行修改时，也可以起到一定的提示作用。因此在对软件架构进行验证时，需要知道那些部分的软件需要通过引入附加的措施实现故障控制，这些都可以通过软件失效分析获得。为了知道软件组件可能发生那些故障，需要采用软件HAZOP来确定软件组件的失效模式和相关安全措施的有效性。执行软件失效分析，以证明关键软件模块不会由于其他部分的失效（导致对该模块的输入异常）对该模块的功能造成不良影响。软件失效分析的目的还包括：
加深对系统/软件的认识，从而能够识别出系统/软件中最为关键和重要的模块；
实现对软件架构设计的验证；
识别出系统/软件中安全和非安全模块，不同SIL要求模块之间的独立性和解耦；
识别出用于检测失效的安全控制措施，如果某个模块具有独立的安全控制措施，那么该模块的关键度可能就可以降低：
故障检测和诊断措施；
错误检测和纠正代码；
失效断言编程；
防御性编程；
作为优化V&V活动的基础。
4、关键度等级的定义
C1：无影响 interferencefree
模块不会执行安全相关或安全关键的功能，可能只会通过接口从关键模块读取一些信息；
C2：安全相关 safety relevant
模块出现单个的信息错误或偏差不会导致不安全的状态，但其他模块的再发生失效将导致不安全的状态；
C3：安全关键 safety critical
单个信息措施或偏差即会导致不安全状态
5、典型实施流程
软件失效分析的前提是软件已经被非常清楚的进行了层次和模块细分，例如模块、单元、实体、对象、类等等，并且所有组件之间的功能和接口非常清晰，这些可能在软件架构设计/软件安全要求规范文件中进行了说明。
对于这些组件的分析是通过发起假设：当其发生设计偏离时是否会导致危险的系统行为（当然这些首先取决于对于安全状态和危险状态有非常清晰的定义）。一个分析过程的示例是：某个组件可能最初被定义为C3级别，即当其发生单个失效时会导致危险场景，如果增加了某个诊断组件，可以对原来组件的失效进行检测，那么此时需要当诊断组件和原来组件都发生失效才会导致危险场景，因此该组件降低为C2级别。不同关键度的典型功能如下表：
关键度 | 典型功能 | 理由 |
C1 | 历史记录 非安全相关的数据显示 | 历史记录会读取但不会修改安全数据 即是显示组件与安全关键组件断开了连接，安全功能仍能继续正常运行 |
C2 | 看门狗触发功能 错误处理功能 | 仅当检测到错误时，两个功能才起作用 |
C3 | 安全相关变送器的测量功能 | 安全功能完全取决于输入信号的正确性 |
注：上表仅是一个通用性的说明，对于具体的软件需要分析才能确定其具体的组件关键度。
6、关键度等级与SIL的关系
一般对于定义的关键度组件需要满足的SIL要求如下表：
组件的SIL能力要求 | 组件关键度 |
C1 | C2 | C3 | 备注 |
SIL1 | 满足独立性和无影响性即可 | 满足SIL1的适用性要求 | 满足SIL1的适用性要求 |
|
SIL2 | 满足独立性和无影响性即可 | 满足SIL1的适用性要求，且对于更高SIL的组件无影响 | 满足SIL2的适用性要求 |
|
SIL3 | 满足独立性和无影响性即可 | 满足SIL2的适用性要求，，且对于更高SIL的组件无影响 | 满足SIL3的适用性要求 |
|
7、软件HAZOP
软件HAZOP的目的是识别哪些与设计意图的偏离可能是潜在危险，以及系统内各个组件之间的相关关系。一般情况下对于软件有如下划分和定义：
软件组件（software component）:一组软件模块用以执行一组特定的功能（例如文件处理），软件组件一般用接口进行描述；
软件模块：一个完整的软件单元以执行某个特定的功能（例如读文件），软件模块用功能和接口进行描述；
通过软件HAZOP可以系统性定义出“反向”测试用例。同软件失效分析确定软件代码中哪些地方需要进行断言编程或防御性编程。需要开展软件HAZOP的代码是不同的：
原则上关键度分析中，所有存在SIL降低情况（C2，C1）的软件组件都需要执行HAZOP；
对于C1的软件组件，重点分析这些组件发生故障时，不会对C2，C3造成负面影响（这可能会包括对这些组件防护措施的分析，例如通过对指针范围的检查，确保其不会将数据写入C2，C3分类的组件中）；
对于C2组件需要验证其功能的实现不会到C3造成安全关键影响（例如某个RAM测试功能可能会在测试中造成RAM存储的数据损坏，而且没有办法恢复）；
对于C3组件需要通过分析考虑是否存在C2的组件（监视、诊断等功能）实现对其关键度的降级；
软件HAZOP的基本流程如下：
1、初始化分析，定义范围和目标
2、计划分析的会议
3、执行分析
4、审核分析，执行改进
5、形成最终分析报告
分析过程中，一些典型的属性和引导词结合如下：
消息流图表达软件功能时的相关属性：
属性 | 引导词 | 组合解释 |
消息message | No | 没有消息 某个对象没有消息发出 某个对象没有消息到达 |
Part of | 消息到达得不完整 |
Other than | 消息完整且语法正确，但内容或语义不正确 |
Early | 消息比起预期的早到 |
Late | 消息比其要求的晚到 |
More | 比预期的更多消息到来 |
Less | 比预期的更少的消息到来 |
数据里图的表达时
属性 | 引导词 | 组合解释 |
数据流data flow | No | 没有信息流 |
Part of | 信息没有完整的通过 |
Reverse | 信息流方向错误 |
Other than | 信息完整且语法正确，但内容或语义不正确 |
Early | 信息流发生得比其要求的早 |
Late | 信息流发生得比其要求的晚 |
More | 比预期的更多数据通过 |
数据率 | More | 数据率太高 |
Less | 数据率太低 |
数据值 | More | 数据值太高 |
Less | 数据值太低 |
对于状态转移图
属性 | 引导词 | 组合解释 |
事件 Event | No | 事件没有发生 |
As well as | 另外的事件同时发生 |
Other than | 不同于预期事件的不期望事件发生 |
动作 Action | No | 没有动作发生 |
As well as | 附加的动作发生 |
Part of | 动作执行不完整 |
Other than | 错误的动作发生 |
