提供本節內容是為了幫助系統安全工程師和軟件開發人員對軟件故障模式和影響分析技術進行介紹性解釋。此處提供的信息是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糾正性變更的影響

糾正措施將產生影響。影響可能是進度，設計，功能，性能，過程等。如果糾正措施導致軟件設計發生變化，則該軟件的某些部分將受到影響。即使糾正措施是修改操作員使用系統的方式，也會產生影響。

您需要返回并分析更改對系統或操作過程的影響，以確保它們（單獨或共同）不會產生不利影響，并且不會為安全關鍵功能或組件創建新的故障模式。

修復程序通常會引入更多錯誤，并且必須有一套確定的過程來確保在安全關鍵系統中不會發生這種情況。確保驗證程序覆蓋受影響的區域。