一文解析软件故障模式和影响

提供本节内容是为了帮助系统安全工程师和软件开发人员对软件故障模式和影响分析技术进行介绍性解释。此处提供的信息是iSTD安全关键软件分析课程的一部分。

故障模式和影响分析（FMEA）是一种自下而上的方法，用于在项目仍处于设计阶段时发现潜在的系统问题。检查了系统中的每个组件，并列出了所有可能导致故障的方法。通过系统跟踪每个可能的故障，以查看其将产生什么影响以及它是否会导致危险状态。考虑故障的可能性以及系统故障的严重性。

自1960年代以来，FMEA已被系统安全和其他工程学科使用。该方法已扩展为检查系统（SwFMEA）的软件方面。

1术语

故障是指系统或组件无法在指定的性能要求内执行其所需的功能。使设备偏离使用或性能规定极限的事件也是失败。故障可以是完全的，逐渐的或间歇的。

完整的系统故障表现为系统崩溃或锁定。此时，系统通常无法部分或全部使用，并且可能至少需要重新启动。-需要采取哪些预防措施，如果不可避免，那么可以采取哪些措施来确保系统安全并可以安全恢复。

逐渐的系统故障可能通过降低系统功能来体现。功能可能开始消失，而其他功能可能随之消失，或者系统可能开始降级（因为执行功能的速度可能会降低）。在这里，资源管理通常是一个错误，CPU可能内存不足或时间片可用性不足。

间歇性故障是一些最令人沮丧且难以解决的故障。其中一些可能是周期性的或事件驱动的，或者某些情况会周期性发生，这是意外的和/或不可预测的。通常，在未知条件下会发生未实现的软件路径。

在考虑故障模式（如下所述）时，应牢记这些类型的故障。与大多数硬件故障不同，软件故障通常不会表现为“硬”（系统完全锁定）类型的系统故障。软件不会磨损或损坏。它要么功能正常，要么已经损坏（但没人知道）！

故障模式定义为导致故障的缺陷类型（ASQC）；故障的物理或功能表现（IEEE Std 610.12-1990）。故障模式通常是故障发生的方式以及故障对正常所需系统操作的影响程度。失败模式的示例包括：断裂（硬件），数据值超出限制（软件）和数据乱码（软件）。

故障影响是故障模式对项目或系统的操作，功能或状态造成的后果。失效效应分为局部效应（在组件上），更高级别的效应（组件所在的系统部分）和最终效应（系统级）。

2为什么要进行SwFMEA？

SwFMEA识别数据和软件操作的关键软件故障模式。它分析了异常对系统中其他组件以及整个系统的影响。从最低级别的组件的角度来看，该技术用于发现系统故障。这是一次“自下而上”（或“前进”）的分析，将问题从最低层传播到整个系统中的故障。

软件故障树分析是一种“自上而下”（或“后退”）的方法。它确定可能的系统故障并询问可能是什么原因造成的。SFTA从故障向后看，其缺陷可能导致或导致故障的组件。

SwFMEA询问“如果该组件操作不正确会产生什么影响？”假定该组件的故障，然后在系统中进行跟踪以查看最终结果。并非所有组件故障都会导致系统问题。在一个好的防御性设计中，许多错误将已经由设计中的错误处理部分进行管理。

软件FMEA采用系统方法，分析软件对硬件故障的响应以及异常软件操作对硬件的影响。在软件上执行FMEA可以识别：

­ 隐藏的故障模式，系统交互和依赖性

­ 意外的故障模式

­ 未陈述的假设

­ 需求与设计之间的不一致

SwFMEA不是万能药。他们不会解决您所有的问题！您可能不会获得上述所有结果，但是与没有进行分析的情况相比，您应该更接近干净的系统。

在执行SwFMEA时，与团队其他成员进行交互非常重要。没有人能理解所有组件，软件或硬件。让硬件和软件设计师/工程师在执行分析时对其进行检查。他们的观点将有助于发现隐藏的假设或阐明导致需求或设计要素的思维过程。SwFMEA不是灵丹妙药，而是对冲您的赌注（降低风险）的工具。

3SwFMEA问题

如果SwFMEA如此出色，为什么每个人都没有这样做？问题在于技术是：

Ô 耗时的

Ô 乏味

Ô 手动方法（目前）

Ô 取决于分析师的知识

Ô 取决于文档的准确性

Ô 不完整故障模式列表的可疑收益

要获得该技术最大优势的地方就是需求和设计分析。这可能会花费一些时间，但是就您可以用来查看项目的不同角度（硬件，软件，操作等）而言，值得付出很多努力。

某些人认为该技术很乏味。但是，最终结果是获得了更多，更详细的项目和/或系统知识。在生命周期中更早使用（需求和设计）时，这是最正确的。由于已知组件及其逻辑关系，因此在项目后期使用SwFMEA更加容易，但是在这一点上（即详细的设计和实现），通常太迟了（而且代价昂贵），无法影响需求或设计。在项目的早期，较低级别的组件是推测，可能是错误的，但是此推测可用于尽早排除问题。该方法必须平衡。试图对尚未准备就绪的产品进行分析没有任何价值。

该技术取决于分析师对系统的了解程度。但是，如前所述，该技术应有助于在使用时带出更多信息。包括更多对所涉及系统具有不同知识的审阅者。除了从不同角度审视项目之外，背景的多样性还将使人们更加敏锐地意识到变化对所有组织的影响。

文档对于使用这种分析技术也非常重要。因此，在审阅文档时，使用许多不同类型的资源（系统和软件工程师，硬件工程师，系统操作人员等），以便在审阅过程中使用不同的观点。显而易见的好处是，从多个角度进行了批判，结果是一种更好的产品。

同样，不要在真空中工作！沟通对于成功至关重要。

您应该在哪里使用SwFMEA技术？以下所有领域，尽管您应重点关注安全关键方面。

­ 单次故障分析

­ 多重故障分析

­ 硬件/软件接口

­ 要求

­ 设计

­ 详细设计

4SwFMEA流程

图C-1

FMEA分析从底部开始（“结束”项目）。图C-1显示了一个子系统，指示每个组件如何与其他组件交互。此入门图中未包含逻辑（与（或）与（或））。最后的项目是压力传感器和温度传感器。该图显示了故障如何在整个系统中传播，从而导致危险事件。

软件FMEA遵循与硬件FMEA相同的过程，用软件组件代替硬件。或者，如果系统/可靠性工程师熟悉软件或FMEA团队中包括软件工程师，则软件可以包含在系统FMEA中。MIL-STD-1629是一种广泛使用的FMEA程序，本附录以此为基础。

要执行软件故障模式和影响分析（SwFMEA），您需要确定：

­ 项目/系统组件

­ 基本规则，准则和假设

­ 潜在的功能和接口故障模式

­ 每种故障模式的潜在后果

­ 故障/故障检测方法和补偿规定

­ 纠正设计或采取措施以消除或减轻故障/故障

­ 纠正性变更的影响

4.1识别项目/系统组件

工程师必须了解项目，系统和目的，并在进行分析时牢记“全局”。狭窄的视角可以防止您看到组件之间的交互，尤其是软件和硬件之间的交互。与具有不同背景和专业知识的人进行交流。

在执行FMEA时，定义要进行的工作是第一要务。“无论是什么”都可以是项目，系统，子系统，“单元”或其他难题。根据项目在开发生命周期中的位置（需求，设计，实施），希望您可以使用一些文档。如果缺少文档，则必须进行一些侦探工作。通常会有关于软件团队产生的需求或设计的半正式文书的集合，但是没有写成正式的需求或设计文档。查找“软件开发文件夹”，与开发人员联系，并积累您所能提供的所有信息。如果纸上写的很少，那么您将不得不采访开发人员（以及项目管理，硬件工程师，系统人员等）以创建自己的文档。

一旦知道了系统是什么以及应该做什么，就可以开始将系统分解为小块了。将项目分解为子系统。将子系统分解为其组件。该过程从一个高级项目图开始，该项目图由系统，功能或对象的块组成。然后，系统中的每个块都有其自己的图，显示构成该块（子系统）的组件。这是很多工作，但是您通常不必完成整个项目！并非每个子系统都需要详细介绍到最低级别。决定哪些子系统需要进一步分解取决于经验。如有疑问，请与最熟悉子系统或组件的项目成员交谈。

在需求阶段，最低级别的组件可能是功能或问题域。在初步（架构）设计阶段，功能，计算机软件配置项（CSCI）或对象/类可能是组件。CSCI，单元，对象，实例等可以用于详细的设计阶段。

使用您创建的“块”并将它们放到图表中，使用逻辑符号显示组件之间的交互作用和关系。您需要了解系统，其工作方式以及各部分之间的相互关系。重要的是要阐明一个组件可能会如何影响其他组件，并在整个系统中达到最高水平。生成此图有助于分析师，将信息汇总在一起。当您与团队的其他成员讨论系统时，它也提供了一个“共同点”。他们可以提供有关您对系统了解的有效性的反馈。

4.2基本原则

开始SwFMEA之前，您需要确定基本规则。没有正确或错误的规则，但是您需要提前知道什么将被视为故障，将包括哪些类型的故障，容错级别以及其他信息。一些基本规则示例是：

1. 所有故障模式都应在适当的详细级别上进行标识：组件，子系统和系统。

2. 应评估每个实验任务，以确定所需的适当分析水平。

3. 基于可用文档，将尽可能考虑跨接口的故障模式传播。

4. 在详细设计期间，应从功能和对象级别分析由缺陷软件（代码）导致的故障或错误。

5. 由人为错误引起的故障模式不包括在本FMEA中。

6. 硬件项目故障模式的关键性分类应基于最坏情况下的潜在故障影响进行。

7. 在相同环境（唯一的区别是位置）中，在相同环境下执行相同功能的相同项目，只要故障模式效果相同，就只会记录在工作表上。

8. 将对诸如燃烧室和气瓶之类的安全壳结构进行分析。

9. 对于灾难性危险，双部件故障（可容忍一故障的物品）是可信的。

10. 对于灾难性危害，三重组件故障（具有两个故障容限的项目）是不可信的。

11. 对于严重危险，单个组件故障是可信的。

12. 对于严重危险，双组件故障不可信

13. 如果所释放的气体是预燃烧气体，则在单个安全气瓶中释放内容物不会构成任何危害（例如，易燃性，毒性，02耗竭）

14. 不受故障模式和影响分析影响的项目包括：管道，安装支架，二级结构，电线和电子外壳。

除了基本规则外，您还需要识别并记录所做的假设。您可能在某些方面没有足够的信息，例如系统接口端口上预期数据的速度。如果该假设不正确，则在对其进行检查时会发现它是错误的，并且会（有时会大声地）提供正确的信息。当您描述您认为系统正常运行或系统如何处理其他项目成员的故障时，将进行此检查。

不要让假设变得不成文。每一个都很重要。换句话说，除非您将其写下来，否则为“假设没有”。一旦写完，它将成为进一步探索和扩展的重点。

尝试思考“框外” –超越表面现象。从整体上看项目，然后看各个部分。查看组件之间的交互，查找假设，限制和不一致。

图C-2

图C-2显示了识别您的假设，将其记录下来，找出现实情况并进行澄清以供将来参考的过程。

4.3识别失效模式

一旦了解了系统，将其分解为各个组成部分，创建了基本规则并记录了您的假设，就可以开始研究有趣的部分了：识别可能的故障。故障可能是功能性的（它没有按预期的方式工作），对不良数据或出现故障的硬件的不良响应，或者与接口有关。

功能故障将源自初步危害分析（PHA）和后续危害分析，包括子系统HA。此列表中可能会有硬件项目。该分析着眼于软件与硬件的关系。

识别需要保护的功能很重要。这些功能是“必须工作功能”和“必须不工作功能”。故障可能是较低级软件单元对这些功能之一的损害。

还有一些接口需要处理。据一些研究人员称，与接口相关的问题比软件开发的任何其他方面都多。接口包括软件到软件（函数调用，进程间通信等），软件到硬件（例如，将数模端口设置为指定的电压），硬件到软件（例如软件读取温度）传感器）或硬件到硬件。SwFMEA处理所有这些，除了硬件到硬件的接口。这些都包含在系统FMEA中。接口还（宽松地）包括状态或操作模式之间的转换。

在查看系统时，您会发现需要做出更多假设。记下来。当所有其他方法都失败了，并且没有地方可以获取有用的信息时，有时就可以猜测。再次写下来，并与他人讨论。“其他”应包括您专业领域之外的人员。如果您是软件人员，请与安全和系统部门联系。如果您是安全专家，请与系统，软件和可靠性专家联系。

4.3.1作为系统一部分的正常运行检查

系统的正常运行包括按设计执行，能够处理已知问题区域，以及其容错和故障响应（如果已设计到系统中）。希望该系统旨在正确安全地处理所有预期的问题。SwFMEA将发现那些无法预料的问题导致失败的区域。

此步骤确定软件如何响应故障。此步骤验证了产品“执行其应做的事情”的充分性或缺乏性。这具有确认产品开发人员对该问题的理解的副作用。为了了解系统的操作，如果您是软件工程师，则可能需要与系统工程部门进行工作并进行交流。系统工程还必须与软件工程进行通信，并且两者都必须与安全和软件保障（SA）进行交流。

SwFMEA的此部分描述了作为系统或功能一部分的软件的正常操作

4.3.2确定可能的故障区域

检查可能出现的故障的区域包括：

v 数据采样率。数据的变化速度可能快于采样率所允许的速度，或者对于实际的变化率而言，采样率可能过高，从而使系统被不必要的数据阻塞。

v 数据冲突。数据冲突的示例包括：由多个处理器同时通过LAN传输，由于相似性而不应该修改记录时，以及多个用户以无组织方式修改表中的数据。

v 命令失败。该命令未发出或未收到。

v 命令混乱。可能会有命令命令设备（进入运行状态）的方式。例如，明智的做法是在通往高层办公大楼的空气处理单元之前，打开通向地板的风管的风门，以及风门以引入外部空气。

v 非法命令。传输问题或其他原因可能导致接收到无法识别的命令。另外，可能会收到对于当前程序状态不合法的命令。

v 定时。阻尼器（特别是大型阻尼器）需要很长时间才能打开，因此，时间选择至关重要。通过过早打开空气处理器，必须有一定的时间延迟，以防止其爆裂（吸入）外部空气阻尼器，或可能使供应空气阻尼器爆炸。

v 安全模式。有时有必要将一个可能带有或没有软件的系统置于一切安全的模式下（即，没有东西崩溃或崩溃）。或软件将自己和其他系统维护为无危险模式。

v 多个事件或数据。如果在短时间内两次获取相同元素的数据，会发生什么情况？您使用第一个还是第二个值？

v 不可能的。工程师或软件开发人员会告诉您“不可能发生”。尝试区分真正不可能的故障或极不可能的故障，以及那些不太可能但可能的故障。如果您不为此计划，那不可能的事情就会发生。

这些都是软件可以引起系统或子系统故障的各种事情。并非每一个软件故障都会导致系统故障或关闭，甚至发生的那些故障对安全性也不重要。故障的类型比这些类型多得多，但是在寻找可能出错的故障时，这些是一个好的开始。

4.3.3可能的故障模式

确定事件表和数据表中可能的故障模式和影响，包括在4.8

失败模式的示例包括：

硬件故障/设计缺陷

­ 传感器损坏导致S / W路径错误

­ 没有传感器或传感器不足-不知道硬件在做什么

­ 卡阀或其他执行器

软件

­ 重写的内存（缓冲区或处理时间不足）。

­ 输入参数丢失，命令错误，输出错误，值超出范围等

­ 在以前没有考虑的条件下采取的意外路径。

操作者

­ 意外输入未知命令，或在错误时间输入正确命令。

­ 未能在要求的时间发出命令。

­ 在指定的时间内未能响应错误情况。

环境

­ 伽玛射线

­ 电磁干扰

­ 硬盘中的猫毛

­ 电源波动

4.3.4从底部开始

返回到您先前创建的框图。从最低级别开始，查看一个组件，并确定该组件在其故障模式之一中对其上一级组件的影响。

您可能需要考虑此组件的影响以及在更高层次上的所有受影响的组件。这必须在整个链条上一直进行。

这是一个漫长的过程。但是，如果安全关键部分在系统中被完全隔离，那么分析人员将只查看系统中可能导致严重故障的那些部分。对于此分析的详细设计和实施阶段/版本，这是正确的。对于需求和初步设计阶段，系统更加抽象（因此更小，更易于管理）。

4.4确定每次失败的后果

接下来要看的是已定义的故障/失败的后果（后果）。考虑故障/故障的严重性或严重性也很重要。

到目前为止，在FMEA流程中，我们集中在安全性方面。但是，现在也该考虑可靠性了。像安全性，可靠性一样，查看：

v 严重性可能是灾难性的，严重的，微不足道的或可以忽略的。

v 发生的可能性可能是偶然的，偶然的，稀少的或不可能的。

风险级别定义为1到5，其中1级别是禁止级别（即不允许，必须进行要求或更改设计）。关键类别包括添加的有关组件或功能是否具有冗余或将是单点故障的信息。

对于每个项目和中心，严重性级别和风险级别的排名可能会有所不同。毕竟，这并不是一门精确的科学，而是一门专业的最佳猜测（最佳工程判断）。

下表列出了可靠性的关键类别和安全风险等级之间的关系：

4.5检测与补偿

在这一步，您需要确定系统用于检测危险状况的方法，以及系统中可以弥补该状况的准备。

对于每种故障模式，应确定故障/故障检测方法。故障检测机制是一种方法，通过该方法，操作员可以在正常系统操作下或通过某些诊断来发现故障。硬件中的故障检测是通过传感设备或仪器进行的。在软件中，这可以通过检错软件对传输的信号，数据或消息，内存检查，初始条件等进行。

对于每种故障模式，应确定补偿性规定，如果不是危险性故障，则应接受风险。补偿规定是设计规定或操作员采取的规避或缓解措施。在出现内部故障故障时，需要执行此步骤以记录项目的真实行为。设计规定可以是多余的项目，也可以是功能减少的功能，以确保持续的安全运行。操作员的动作可以是在操作员控制台上以有序方式关闭系统的通知。

一个示例：故障是由于断电（硬件故障）或由于其他数据覆盖了数据（软件故障）而导致的数据丢失。

检测：关键电源和CPU可能由UPS（不间断电源）备份，也可能没有。检测到电源已丢失，系统现在已在此备用源上。在时间x将数据标记为不可靠。这将是一种检测方案。

补偿此故障的发生：是否有该数据的另一个来源。可以重读吗？还是只是被标记为可疑或被丢弃，然后等待下一个正常数据覆盖它？拥有UPS，备用电池，冗余电源该怎么办？当然，这些都是硬件的答案。软件能否检测出是否可能怀疑数据并对其进行标记或扔掉，等待新输入，请求新输入，从备用来源获取数据，从先前数据（趋势）中进行计算等？

如果输入数据的输入速度快于预期并且在处理之前覆盖了先前的数据，该怎么办。这个系统怎么知道？该怎么办？例如，一个软件系统通常会周期性地从40个源中接收数据输入，然后由于部分故障或维护模式，现在只有20个源处于循环状态，令牌的传递速度提高了2倍。缓冲区可以处理增加的数据速率吗？

4.6设计变更

在确定了严重危害后，该项目需要

Ô 确定纠正措施

Ô 识别设计变更

Ô 验证更改

Ô 跟踪所有更改以关闭

在确定了严重危害后，通常可以消除或减轻危害。这两个动作中任何一个的结果都是纠正措施。纠正措施可以通过记录在案的新要求，设计，过程，程序等来实现。一旦实施，就必须进行分析和验证以纠正故障或危害。

进行更改后，务必查看新设计，以确认没有新的危险产生。

4.7纠正性变更的影响

纠正措施将产生影响。影响可能是进度，设计，功能，性能，过程等。如果纠正措施导致软件设计发生变化，则该软件的某些部分将受到影响。即使纠正措施是修改操作员使用系统的方式，也会产生影响。

您需要返回并分析更改对系统或操作过程的影响，以确保它们（单独或共同）不会产生不利影响，并且不会为安全关键功能或组件创建新的故障模式。

修复程序通常会引入更多错误，并且必须有一套确定的过程来确保在安全关键系统中不会发生这种情况。确保验证程序覆盖受影响的区域。