fmea提出的分析方法（逻辑应该这样分析）

什么是软件FMEA？

软件FMEA评估系统设计的能力，通过它的软件设计来表达，以可预测的方式进行反馈以确保系统安全

软件FMEA的应用范围？

软件FMEA的三个应用层级：

1>. 系统功能层（system functional Level）

第一层： 软件系统故障模式和效果分析（SSFMEA）适用于软件控制硬件的软件系统。大多数技术产品属于这一类，如飞机、发电厂、改装系统和复杂系统。在SSFMEA中，重点是通过软件的流程图来识别系统的弱点，这样软件的特殊化就可以变得完整、清晰、全面和明确。

目标是 1）, 来确定软件是否是错误的，关于硬件故障和

2） 以确定系统的规格中缺失的需求。

2>.逻辑层 (Logic Level)

第二层： (Detailed or Logic Software FMEA)用于验证软件设计是否达到了特定的软件需求，并提供了所有需要的系统安全保护。详细的软件FMEA“是冗长的和劳动密集型的。主要适用于具有最小或没有硬件保护的内存、处理结果或通信的关键系统。”

3>.代码层 (code Level)

第三层是在代码级别执行的软件FMEA。对软件输入和输出进行分析，以确定可能出现的问题，并确定异常情况。目标是确保输入和输出是可接受和正确处理的，如果出现故障，产品就会以失败-安全模式失败。与在细节级别执行的软件FMEAs类似，代码级软件FMEA对于关键系统是最合适的。

正如在所有类型的FMEAs中一样，重要的是要消除什么是失败。“软件故障可能是由于软件的特殊环境暴露或短暂或永久的硬件故障导致的软件设计错误的结果。”[13]

备注：对于关键的软件应用，应确保在三个层级开展应用！

软件FMEA的目的是什么？

以下是软件FMEA的一些可能的目标：

--确定缺失的软件需求，

--分析产出变量，

--分析系统的行为，因为它响应来自该系统外部的请求。

--确定（和减轻）单点故障，可能导致灾难性的失败，在功能之外，除了功能之外，

--还可以识别软件对硬件异常的反应。

软件FMEA的重要前提是什么？

建议在开始软件FMEA 之前执行软件危害分析：

与硬件和系统FMEAs不同，软件FMEA不容易被用来识别系统级别的危险。由于软件是一种逻辑结构，而不是物理实体，所以在分析之前，必须将危险识别并转换为软件术语。在开始开发软件FMEA之前，系统应该存在系统的初步险分析（PHA）。该树需要包含所有的危险，这可能会导致软件成为潜在的原因。

第一步是识别系统危害分析中的每一个危害。对于每一个潜在的危险和危险原因，可能是软件故障的结果，确定了一组适当的软件输入和输出变量值。与每个危险原因相关的值被识别为潜在的软件危害，这将成为软件FMEA的输入。

软件FMEA的一般流程？

第一：软件FMEA的准备阶段

下面总结了软件FMEA准备工作的步骤：

-- 通过修改FMEA P图或单独提供一个显示软件功能如何与硬件集成的图表，以图形方式描述分析的范围。对于复杂的系统，可以使用数据流l图。

-- 在开始软件FMEA之前，确保软件需求是良好的

-- 收集开始分析所需的所有信息。

-- 在基本规则、假设和限制上达成一致。

-- 组装正确的软件FMEA团队，确保它包括来自软件开发、硬件设计、系统工程、测试、制造和服务的专家。

-- 在适合于软件分析的等级量表上达成一致。

-- 在分析级别上达成一致，即系统功能级别、逻辑级别和/或代码级别。

第二：软件FMEA的流程步骤：

在软件设计团队确定最初的软件架构并将功能需求转移到软件设计的过程中，应该在设计过程的早期就执行软件系统FMEAs。在细节级别上的软件FMEAs通常在软件设计过程的后期完成，当详细的设计描述和初步代码存在时。

1>. 定义软件的主要功能——硬件集成系统。无论什么原因导致软件出现故障，软件都应该达到预期的状态。如果在特殊情况下没有识别出想要的状态，那么软件应该总是处于失败-安全状态。一个失效-安全的状态是，在失效的情况下，以一种对其他设备造成最小伤害或对人员造成危险的方式做出反应。

2>.在传统的FMEAs中，每个功能都被分析出功能的错误。使用适用于软件的“失效”的缺点。可能出现的软件故障的例子：

a.没有可靠地执行一个功能.

b.如果不成功执行一个功能.

c.则不能在需要时执行一个功能.

d.在不需要的时候执行一个功能，比如在没有事故发生的情况下在车里部署一个气囊。

e.执行不在特殊情况下的功能

f.未能在正确的时间停止任务

g.输入或输出的缺失

h.不执行一个功能或任务

i.间歇行为

j.破坏了操作环境

k.由用户不正确的请求失败。

i.不完全执行

m.无法执行临界中断。

n.退化的能力

3>.识别失效的影响，就像传统的FMEAs一样。对于系统级的软件FMEAs，将每个故障模式对软件输出的影响与软件危险分析（如果可用）的结果进行比较，以确定危险的结果。对于详细的l软件FMEAs，对每一个假定的故障模式的影响都可以追溯到“代码和输出信号”。然后将产生的软件状态与详细的软件危害进行比较，以允许潜在的危险故障的识别。”

4>.使用商定的-按比例对失败影响的严重性进行排序。

5>.我找出了失败的原因。在分析的范围内达成一致的原因是很有帮助的。

a.EMI/RFI（电磁干扰和无线电频率干扰）

b.编码或逻辑错误

c.输入/输出错误

d.数据处理

e.变量的定义

f.接口失效

g.失效的硬件

h.通信失败

i.停电

g.在特殊情况下的遗漏

k.不充分的或损坏的记忆

l.操作环境

m.松散的电线和电缆

n.不准确的输入，例如来自传感器的输入

6>.使用商定的-按比例对发生和发现进行排序。

7>.识别当前的控制，类似于传统的FMEA。

8>.在软件问题的解决方案中使用以下优先原则：

a.设计出故障模式

b.使用冗余来实现容差

c.进入失效-安全模式（例如，“跛行”的能力）

d.实施早期预测预警

e.实施培训以减少人为失误的风险

9>.建议的操作应该使用上面的优先级建议，并确保软件的安全，并完成它的功能，并将重点放在潜在的危险结果上。应该特别注意识别任何对新的或修改的软件需求的需求。关于制定有效的行动策略.

10>.实现推荐的操作并确保软件-硬件风险降低到可接受的水平。

软件FMEA案例：

软件FMEA 案例-功能层

软件FMEA 案例-逻辑层

软件FMEA 案例-代码层

,