什麼是軟件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 案例-代碼層

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!