提供本節(jié)內(nèi)容是為了幫助系統(tǒng)安全工程師和軟件開(kāi)發(fā)人員對(duì)軟件故障模式和影響分析技術(shù)進(jìn)行介紹性解釋。此處提供的信息是iSTD安全關(guān)鍵軟件分析課程的一部分。

故障模式和影響分析（FMEA）是一種自下而上的方法，用于在項(xiàng)目仍處于設(shè)計(jì)階段時(shí)發(fā)現(xiàn)潛在的系統(tǒng)問(wèn)題。檢查了系統(tǒng)中的每個(gè)組件，并列出了所有可能導(dǎo)致故障的方法。通過(guò)系統(tǒng)跟蹤每個(gè)可能的故障，以查看其將產(chǎn)生什么影響以及它是否會(huì)導(dǎo)致危險(xiǎn)狀態(tài)。考慮故障的可能性以及系統(tǒng)故障的嚴(yán)重性。

自1960年代以來(lái)，F(xiàn)MEA已被系統(tǒng)安全和其他工程學(xué)科使用。該方法已擴(kuò)展為檢查系統(tǒng)（SwFMEA）的軟件方面。

1術(shù)語(yǔ)

故障是指系統(tǒng)或組件無(wú)法在指定的性能要求內(nèi)執(zhí)行其所需的功能。使設(shè)備偏離使用或性能規(guī)定極限的事件也是失敗。故障可以是完全的，逐漸的或間歇的。

完整的系統(tǒng)故障表現(xiàn)為系統(tǒng)崩潰或鎖定。此時(shí)，系統(tǒng)通常無(wú)法部分或全部使用，并且可能至少需要重新啟動(dòng)。-需要采取哪些預(yù)防措施，如果不可避免，那么可以采取哪些措施來(lái)確保系統(tǒng)安全并可以安全恢復(fù)。

逐漸的系統(tǒng)故障可能通過(guò)降低系統(tǒng)功能來(lái)體現(xiàn)。功能可能開(kāi)始消失，而其他功能可能隨之消失，或者系統(tǒng)可能開(kāi)始降級(jí)（因?yàn)閳?zhí)行功能的速度可能會(huì)降低）。在這里，資源管理通常是一個(gè)錯(cuò)誤，CPU可能內(nèi)存不足或時(shí)間片可用性不足。

間歇性故障是一些最令人沮喪且難以解決的故障。其中一些可能是周期性的或事件驅(qū)動(dòng)的，或者某些情況會(huì)周期性發(fā)生，這是意外的和/或不可預(yù)測(cè)的。通常，在未知條件下會(huì)發(fā)生未實(shí)現(xiàn)的軟件路徑。

在考慮故障模式（如下所述）時(shí)，應(yīng)牢記這些類(lèi)型的故障。與大多數(shù)硬件故障不同，軟件故障通常不會(huì)表現(xiàn)為“硬”（系統(tǒng)完全鎖定）類(lèi)型的系統(tǒng)故障。軟件不會(huì)磨損或損壞。它要么功能正常，要么已經(jīng)損壞（但沒(méi)人知道）！

故障模式定義為導(dǎo)致故障的缺陷類(lèi)型（ASQC）；故障的物理或功能表現(xiàn)（IEEE Std 610.12-1990）。故障模式通常是故障發(fā)生的方式以及故障對(duì)正常所需系統(tǒng)操作的影響程度。失敗模式的示例包括：斷裂（硬件），數(shù)據(jù)值超出限制（軟件）和數(shù)據(jù)亂碼（軟件）。

故障影響是故障模式對(duì)項(xiàng)目或系統(tǒng)的操作，功能或狀態(tài)造成的后果。失效效應(yīng)分為局部效應(yīng)（在組件上），更高級(jí)別的效應(yīng)（組件所在的系統(tǒng)部分）和最終效應(yīng)（系統(tǒng)級(jí)）。

2為什么要進(jìn)行SwFMEA？

SwFMEA識(shí)別數(shù)據(jù)和軟件操作的關(guān)鍵軟件故障模式。它分析了異常對(duì)系統(tǒng)中其他組件以及整個(gè)系統(tǒng)的影響。從最低級(jí)別的組件的角度來(lái)看，該技術(shù)用于發(fā)現(xiàn)系統(tǒng)故障。這是一次“自下而上”（或“前進(jìn)”）的分析，將問(wèn)題從最低層傳播到整個(gè)系統(tǒng)中的故障。

軟件故障樹(shù)分析是一種“自上而下”（或“后退”）的方法。它確定可能的系統(tǒng)故障并詢問(wèn)可能是什么原因造成的。SFTA從故障向后看，其缺陷可能導(dǎo)致或?qū)е鹿收系慕M件。

SwFMEA詢問(wèn)“如果該組件操作不正確會(huì)產(chǎn)生什么影響？”假定該組件的故障，然后在系統(tǒng)中進(jìn)行跟蹤以查看最終結(jié)果。并非所有組件故障都會(huì)導(dǎo)致系統(tǒng)問(wèn)題。在一個(gè)好的防御性設(shè)計(jì)中，許多錯(cuò)誤將已經(jīng)由設(shè)計(jì)中的錯(cuò)誤處理部分進(jìn)行管理。

軟件FMEA采用系統(tǒng)方法，分析軟件對(duì)硬件故障的響應(yīng)以及異常軟件操作對(duì)硬件的影響。在軟件上執(zhí)行FMEA可以識(shí)別：

-隱藏的故障模式，系統(tǒng)交互和依賴性

-意外的故障模式

-未陳述的假設(shè)

-需求與設(shè)計(jì)之間的不一致

SwFMEA不是萬(wàn)能藥。他們不會(huì)解決您所有的問(wèn)題！您可能不會(huì)獲得上述所有結(jié)果，但是與沒(méi)有進(jìn)行分析的情況相比，您應(yīng)該更接近干凈的系統(tǒng)。

在執(zhí)行SwFMEA時(shí)，與團(tuán)隊(duì)其他成員進(jìn)行交互非常重要。沒(méi)有人能理解所有組件，軟件或硬件。讓硬件和軟件設(shè)計(jì)師/工程師在執(zhí)行分析時(shí)對(duì)其進(jìn)行檢查。他們的觀點(diǎn)將有助于發(fā)現(xiàn)隱藏的假設(shè)或闡明導(dǎo)致需求或設(shè)計(jì)要素的思維過(guò)程。SwFMEA不是靈丹妙藥，而是對(duì)沖您的賭注（降低風(fēng)險(xiǎn)）的工具。

3SwFMEA問(wèn)題

如果SwFMEA如此出色，為什么每個(gè)人都沒(méi)有這樣做？問(wèn)題在于技術(shù)是：

?耗時(shí)的

?乏味

?手動(dòng)方法（目前）

?取決于分析師的知識(shí)

?取決于文檔的準(zhǔn)確性

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

要獲得該技術(shù)最大優(yōu)勢(shì)的地方就是需求和設(shè)計(jì)分析。這可能會(huì)花費(fèi)一些時(shí)間，但是就您可以用來(lái)查看項(xiàng)目的不同角度（硬件，軟件，操作等）而言，值得付出很多努力。

某些人認(rèn)為該技術(shù)很乏味。但是，最終結(jié)果是獲得了更多，更詳細(xì)的項(xiàng)目和/或系統(tǒng)知識(shí)。在生命周期中更早使用（需求和設(shè)計(jì)）時(shí)，這是最正確的。由于已知組件及其邏輯關(guān)系，因此在項(xiàng)目后期使用SwFMEA更加容易，但是在這一點(diǎn)上（即詳細(xì)的設(shè)計(jì)和實(shí)現(xiàn)），通常太遲了（而且代價(jià)昂貴），無(wú)法影響需求或設(shè)計(jì)。在項(xiàng)目的早期，較低級(jí)別的組件是推測(cè)，可能是錯(cuò)誤的，但是此推測(cè)可用于盡早排除問(wèn)題。該方法必須平衡。試圖對(duì)尚未準(zhǔn)備就緒的產(chǎn)品進(jìn)行分析沒(méi)有任何價(jià)值。

該技術(shù)取決于分析師對(duì)系統(tǒng)的了解程度。但是，如前所述，該技術(shù)應(yīng)有助于在使用時(shí)帶出更多信息。包括更多對(duì)所涉及系統(tǒng)具有不同知識(shí)的審閱者。除了從不同角度審視項(xiàng)目之外，背景的多樣性還將使人們更加敏銳地意識(shí)到變化對(duì)所有組織的影響。

文檔對(duì)于使用這種分析技術(shù)也非常重要。因此，在審閱文檔時(shí)，使用許多不同類(lèi)型的資源（系統(tǒng)和軟件工程師，硬件工程師，系統(tǒng)操作人員等），以便在審閱過(guò)程中使用不同的觀點(diǎn)。顯而易見(jiàn)的好處是，從多個(gè)角度進(jìn)行了批判，結(jié)果是一種更好的產(chǎn)品。

同樣，不要在真空中工作！溝通對(duì)于成功至關(guān)重要。

您應(yīng)該在哪里使用SwFMEA技術(shù)？以下所有領(lǐng)域，盡管您應(yīng)重點(diǎn)關(guān)注安全關(guān)鍵方面。

-單次故障分析

-多重故障分析

-硬件/軟件接口

-要求

-設(shè)計(jì)

-詳細(xì)設(shè)計(jì)

4SwFMEA流程

圖C-1

FMEA分析從底部開(kāi)始（“結(jié)束”項(xiàng)目）。圖C-1顯示了一個(gè)子系統(tǒng)，指示每個(gè)組件如何與其他組件交互。此入門(mén)圖中未包含邏輯（與（或）與（或））。最后的項(xiàng)目是壓力傳感器和溫度傳感器。該圖顯示了故障如何在整個(gè)系統(tǒng)中傳播，從而導(dǎo)致危險(xiǎn)事件。

軟件FMEA遵循與硬件FMEA相同的過(guò)程，用軟件組件代替硬件。或者，如果系統(tǒng)/可靠性工程師熟悉軟件或FMEA團(tuán)隊(duì)中包括軟件工程師，則軟件可以包含在系統(tǒng)FMEA中。MIL-STD-1629是一種廣泛使用的FMEA程序，本附錄以此為基礎(chǔ)。

要執(zhí)行軟件故障模式和影響分析（SwFMEA），您需要確定：

-項(xiàng)目/系統(tǒng)組件

-基本規(guī)則，準(zhǔn)則和假設(shè)

-潛在的功能和接口故障模式

-每種故障模式的潛在后果

-故障/故障檢測(cè)方法和補(bǔ)償規(guī)定

-糾正設(shè)計(jì)或采取措施以消除或減輕故障/故障

-糾正性變更的影響

4.1識(shí)別項(xiàng)目/系統(tǒng)組件

工程師必須了解項(xiàng)目，系統(tǒng)和目的，并在進(jìn)行分析時(shí)牢記“全局”。狹窄的視角可以防止您看到組件之間的交互，尤其是軟件和硬件之間的交互。與具有不同背景和專(zhuān)業(yè)知識(shí)的人進(jìn)行交流。

在執(zhí)行FMEA時(shí)，定義要進(jìn)行的工作是第一要?jiǎng)?wù)。“無(wú)論是什么”都可以是項(xiàng)目，系統(tǒng)，子系統(tǒng)，“單元”或其他難題。根據(jù)項(xiàng)目在開(kāi)發(fā)生命周期中的位置（需求，設(shè)計(jì)，實(shí)施），希望您可以使用一些文檔。如果缺少文檔，則必須進(jìn)行一些偵探工作。通常會(huì)有關(guān)于軟件團(tuán)隊(duì)產(chǎn)生的需求或設(shè)計(jì)的半正式文書(shū)的集合，但是沒(méi)有寫(xiě)成正式的需求或設(shè)計(jì)文檔。查找“軟件開(kāi)發(fā)文件夾”，與開(kāi)發(fā)人員聯(lián)系，并積累您所能提供的所有信息。如果紙上寫(xiě)的很少，那么您將不得不采訪開(kāi)發(fā)人員（以及項(xiàng)目管理，硬件工程師，系統(tǒng)人員等）以創(chuàng)建自己的文檔。

一旦知道了系統(tǒng)是什么以及應(yīng)該做什么，就可以開(kāi)始將系統(tǒng)分解為小塊了。將項(xiàng)目分解為子系統(tǒng)。將子系統(tǒng)分解為其組件。該過(guò)程從一個(gè)高級(jí)項(xiàng)目圖開(kāi)始，該項(xiàng)目圖由系統(tǒng)，功能或?qū)ο蟮膲K組成。然后，系統(tǒng)中的每個(gè)塊都有其自己的圖，顯示構(gòu)成該塊（子系統(tǒng)）的組件。這是很多工作，但是您通常不必完成整個(gè)項(xiàng)目！并非每個(gè)子系統(tǒng)都需要詳細(xì)介紹到最低級(jí)別。決定哪些子系統(tǒng)需要進(jìn)一步分解取決于經(jīng)驗(yàn)。如有疑問(wèn)，請(qǐng)與最熟悉子系統(tǒng)或組件的項(xiàng)目成員交談。

在需求階段，最低級(jí)別的組件可能是功能或問(wèn)題域。在初步（架構(gòu)）設(shè)計(jì)階段，功能，計(jì)算機(jī)軟件配置項(xiàng)（CSCI）或?qū)ο?類(lèi)可能是組件。CSCI，單元，對(duì)象，實(shí)例等可以用于詳細(xì)的設(shè)計(jì)階段。

使用您創(chuàng)建的“塊”并將它們放到圖表中，使用邏輯符號(hào)顯示組件之間的交互作用和關(guān)系。您需要了解系統(tǒng)，其工作方式以及各部分之間的相互關(guān)系。重要的是要闡明一個(gè)組件可能會(huì)如何影響其他組件，并在整個(gè)系統(tǒng)中達(dá)到最高水平。生成此圖有助于分析師，將信息匯總在一起。當(dāng)您與團(tuán)隊(duì)的其他成員討論系統(tǒng)時(shí)，它也提供了一個(gè)“共同點(diǎn)”。他們可以提供有關(guān)您對(duì)系統(tǒng)了解的有效性的反饋。

4.2基本原則

開(kāi)始SwFMEA之前，您需要確定基本規(guī)則。沒(méi)有正確或錯(cuò)誤的規(guī)則，但是您需要提前知道什么將被視為故障，將包括哪些類(lèi)型的故障，容錯(cuò)級(jí)別以及其他信息。一些基本規(guī)則示例是：

1.所有故障模式都應(yīng)在適當(dāng)?shù)脑敿?xì)級(jí)別上進(jìn)行標(biāo)識(shí)：組件，子系統(tǒng)和系統(tǒng)。

2.應(yīng)評(píng)估每個(gè)實(shí)驗(yàn)任務(wù)，以確定所需的適當(dāng)分析水平。

3.基于可用文檔，將盡可能考慮跨接口的故障模式傳播。

4.在詳細(xì)設(shè)計(jì)期間，應(yīng)從功能和對(duì)象級(jí)別分析由缺陷軟件（代碼）導(dǎo)致的故障或錯(cuò)誤。

5.由人為錯(cuò)誤引起的故障模式不包括在本FMEA中。

6.硬件項(xiàng)目故障模式的關(guān)鍵性分類(lèi)應(yīng)基于最壞情況下的潛在故障影響進(jìn)行。

7.在相同環(huán)境（唯一的區(qū)別是位置）中，在相同環(huán)境下執(zhí)行相同功能的相同項(xiàng)目，只要故障模式效果相同，就只會(huì)記錄在工作表上。

8.將對(duì)諸如燃燒室和氣瓶之類(lèi)的安全殼結(jié)構(gòu)進(jìn)行分析。

9.對(duì)于災(zāi)難性危險(xiǎn)，雙部件故障（可容忍一故障的物品）是可信的。

10.對(duì)于災(zāi)難性危害，三重組件故障（具有兩個(gè)故障容限的項(xiàng)目）是不可信的。

11.對(duì)于嚴(yán)重危險(xiǎn)，單個(gè)組件故障是可信的。

12.對(duì)于嚴(yán)重危險(xiǎn)，雙組件故障不可信

13.如果所釋放的氣體是預(yù)燃燒氣體，則在單個(gè)安全氣瓶中釋放內(nèi)容物不會(huì)構(gòu)成任何危害（例如，易燃性，毒性，02耗竭）

14.不受故障模式和影響分析影響的項(xiàng)目包括：管道，安裝支架，二級(jí)結(jié)構(gòu)，電線和電子外殼。

除了基本規(guī)則外，您還需要識(shí)別并記錄所做的假設(shè)。您可能在某些方面沒(méi)有足夠的信息，例如系統(tǒng)接口端口上預(yù)期數(shù)據(jù)的速度。如果該假設(shè)不正確，則在對(duì)其進(jìn)行檢查時(shí)會(huì)發(fā)現(xiàn)它是錯(cuò)誤的，并且會(huì)（有時(shí)會(huì)大聲地）提供正確的信息。當(dāng)您描述您認(rèn)為系統(tǒng)正常運(yùn)行或系統(tǒng)如何處理其他項(xiàng)目成員的故障時(shí)，將進(jìn)行此檢查。

不要讓假設(shè)變得不成文。每一個(gè)都很重要。換句話說(shuō)，除非您將其寫(xiě)下來(lái)，否則為“假設(shè)沒(méi)有”。一旦寫(xiě)完，它將成為進(jìn)一步探索和擴(kuò)展的重點(diǎn)。

嘗試思考“框外” –超越表面現(xiàn)象。從整體上看項(xiàng)目，然后看各個(gè)部分。查看組件之間的交互，查找假設(shè)，限制和不一致。

圖C-2

圖C-2顯示了識(shí)別您的假設(shè)，將其記錄下來(lái)，找出現(xiàn)實(shí)情況并進(jìn)行澄清以供將來(lái)參考的過(guò)程。

4.3識(shí)別失效模式

一旦了解了系統(tǒng)，將其分解為各個(gè)組成部分，創(chuàng)建了基本規(guī)則并記錄了您的假設(shè)，就可以開(kāi)始研究有趣的部分了：識(shí)別可能的故障。故障可能是功能性的（它沒(méi)有按預(yù)期的方式工作），對(duì)不良數(shù)據(jù)或出現(xiàn)故障的硬件的不良響應(yīng)，或者與接口有關(guān)。

功能故障將源自初步危害分析（PHA）和后續(xù)危害分析，包括子系統(tǒng)HA。此列表中可能會(huì)有硬件項(xiàng)目。該分析著眼于軟件與硬件的關(guān)系。

識(shí)別需要保護(hù)的功能很重要。這些功能是“必須工作功能”和“必須不工作功能”。故障可能是較低級(jí)軟件單元對(duì)這些功能之一的損害。

還有一些接口需要處理。據(jù)一些研究人員稱(chēng)，與接口相關(guān)的問(wèn)題比軟件開(kāi)發(fā)的任何其他方面都多。接口包括軟件到軟件（函數(shù)調(diào)用，進(jìn)程間通信等），軟件到硬件（例如，將數(shù)模端口設(shè)置為指定的電壓），硬件到軟件（例如軟件讀取溫度）傳感器）或硬件到硬件。SwFMEA處理所有這些，除了硬件到硬件的接口。這些都包含在系統(tǒng)FMEA中。接口還（寬松地）包括狀態(tài)或操作模式之間的轉(zhuǎn)換。

在查看系統(tǒng)時(shí)，您會(huì)發(fā)現(xiàn)需要做出更多假設(shè)。記下來(lái)。當(dāng)所有其他方法都失敗了，并且沒(méi)有地方可以獲取有用的信息時(shí)，有時(shí)就可以猜測(cè)。再次寫(xiě)下來(lái)，并與他人討論。“其他”應(yīng)包括您專(zhuān)業(yè)領(lǐng)域之外的人員。如果您是軟件人員，請(qǐng)與安全和系統(tǒng)部門(mén)聯(lián)系。如果您是安全專(zhuān)家，請(qǐng)與系統(tǒng)，軟件和可靠性專(zhuān)家聯(lián)系。

4.3.1作為系統(tǒng)一部分的正常運(yùn)行檢查

系統(tǒng)的正常運(yùn)行包括按設(shè)計(jì)執(zhí)行，能夠處理已知問(wèn)題區(qū)域，以及其容錯(cuò)和故障響應(yīng)（如果已設(shè)計(jì)到系統(tǒng)中）。希望該系統(tǒng)旨在正確安全地處理所有預(yù)期的問(wèn)題。SwFMEA將發(fā)現(xiàn)那些無(wú)法預(yù)料的問(wèn)題導(dǎo)致失敗的區(qū)域。

此步驟確定軟件如何響應(yīng)故障。此步驟驗(yàn)證了產(chǎn)品“執(zhí)行其應(yīng)做的事情”的充分性或缺乏性。這具有確認(rèn)產(chǎn)品開(kāi)發(fā)人員對(duì)該問(wèn)題的理解的副作用。為了了解系統(tǒng)的操作，如果您是軟件工程師，則可能需要與系統(tǒng)工程部門(mén)進(jìn)行工作并進(jìn)行交流。系統(tǒng)工程還必須與軟件工程進(jìn)行通信，并且兩者都必須與安全和軟件保障（SA）進(jìn)行交流。

SwFMEA的此部分描述了作為系統(tǒng)或功能一部分的軟件的正常操作

4.3.2確定可能的故障區(qū)域

檢查可能出現(xiàn)的故障的區(qū)域包括：

v數(shù)據(jù)采樣率。數(shù)據(jù)的變化速度可能快于采樣率所允許的速度，或者對(duì)于實(shí)際的變化率而言，采樣率可能過(guò)高，從而使系統(tǒng)被不必要的數(shù)據(jù)阻塞。

v數(shù)據(jù)沖突。數(shù)據(jù)沖突的示例包括：由多個(gè)處理器同時(shí)通過(guò)LAN傳輸，由于相似性而不應(yīng)該修改記錄時(shí)，以及多個(gè)用戶以無(wú)組織方式修改表中的數(shù)據(jù)。

v命令失敗。該命令未發(fā)出或未收到。

v命令混亂。可能會(huì)有命令命令設(shè)備（進(jìn)入運(yùn)行狀態(tài)）的方式。例如，明智的做法是在通往高層辦公大樓的空氣處理單元之前，打開(kāi)通向地板的風(fēng)管的風(fēng)門(mén)，以及風(fēng)門(mén)以引入外部空氣。

v非法命令。傳輸問(wèn)題或其他原因可能導(dǎo)致接收到無(wú)法識(shí)別的命令。另外，可能會(huì)收到對(duì)于當(dāng)前程序狀態(tài)不合法的命令。

v定時(shí)。阻尼器（特別是大型阻尼器）需要很長(zhǎng)時(shí)間才能打開(kāi)，因此，時(shí)間選擇至關(guān)重要。通過(guò)過(guò)早打開(kāi)空氣處理器，必須有一定的時(shí)間延遲，以防止其爆裂（吸入）外部空氣阻尼器，或可能使供應(yīng)空氣阻尼器爆炸。

v安全模式。有時(shí)有必要將一個(gè)可能帶有或沒(méi)有軟件的系統(tǒng)置于一切安全的模式下（即，沒(méi)有東西崩潰或崩潰）。或軟件將自己和其他系統(tǒng)維護(hù)為無(wú)危險(xiǎn)模式。

v多個(gè)事件或數(shù)據(jù)。如果在短時(shí)間內(nèi)兩次獲取相同元素的數(shù)據(jù)，會(huì)發(fā)生什么情況？您使用第一個(gè)還是第二個(gè)值？

v不可能的。工程師或軟件開(kāi)發(fā)人員會(huì)告訴您“不可能發(fā)生”。嘗試區(qū)分真正不可能的故障或極不可能的故障，以及那些不太可能但可能的故障。如果您不為此計(jì)劃，那不可能的事情就會(huì)發(fā)生。

這些都是軟件可以引起系統(tǒng)或子系統(tǒng)故障的各種事情。并非每一個(gè)軟件故障都會(huì)導(dǎo)致系統(tǒng)故障或關(guān)閉，甚至發(fā)生的那些故障對(duì)安全性也不重要。故障的類(lèi)型比這些類(lèi)型多得多，但是在尋找可能出錯(cuò)的故障時(shí)，這些是一個(gè)好的開(kāi)始。

4.3.3可能的故障模式

確定事件表和數(shù)據(jù)表中可能的故障模式和影響，包括在4.8

失敗模式的示例包括：

硬件故障/設(shè)計(jì)缺陷

-傳感器損壞導(dǎo)致S / W路徑錯(cuò)誤

-沒(méi)有傳感器或傳感器不足-不知道硬件在做什么

-卡閥或其他執(zhí)行器

軟件

-重寫(xiě)的內(nèi)存（緩沖區(qū)或處理時(shí)間不足）。

-輸入?yún)?shù)丟失，命令錯(cuò)誤，輸出錯(cuò)誤，值超出范圍等

-在以前沒(méi)有考慮的條件下采取的意外路徑。

操作者

-意外輸入未知命令，或在錯(cuò)誤時(shí)間輸入正確命令。

-未能在要求的時(shí)間發(fā)出命令。

-在指定的時(shí)間內(nèi)未能響應(yīng)錯(cuò)誤情況。

環(huán)境

-伽瑪射線

-電磁干擾

-硬盤(pán)中的貓毛

-電源波動(dòng)

4.3.4從底部開(kāi)始

返回到您先前創(chuàng)建的框圖。從最低級(jí)別開(kāi)始，查看一個(gè)組件，并確定該組件在其故障模式之一中對(duì)其上一級(jí)組件的影響。

您可能需要考慮此組件的影響以及在更高層次上的所有受影響的組件。這必須在整個(gè)鏈條上一直進(jìn)行。

這是一個(gè)漫長(zhǎng)的過(guò)程。但是，如果安全關(guān)鍵部分在系統(tǒng)中被完全隔離，那么分析人員將只查看系統(tǒng)中可能導(dǎo)致嚴(yán)重故障的那些部分。對(duì)于此分析的詳細(xì)設(shè)計(jì)和實(shí)施階段/版本，這是正確的。對(duì)于需求和初步設(shè)計(jì)階段，系統(tǒng)更加抽象（因此更小，更易于管理）。

4.4確定每次失敗的后果

接下來(lái)要看的是已定義的故障/失敗的后果（后果）。考慮故障/故障的嚴(yán)重性或嚴(yán)重性也很重要。

到目前為止，在FMEA流程中，我們集中在安全性方面。但是，現(xiàn)在也該考慮可靠性了。像安全性，可靠性一樣，查看：

v嚴(yán)重性可能是災(zāi)難性的，嚴(yán)重的，微不足道的或可以忽略的。

v發(fā)生的可能性可能是偶然的，偶然的，稀少的或不可能的。

風(fēng)險(xiǎn)級(jí)別定義為1到5，其中1級(jí)別是禁止級(jí)別（即不允許，必須進(jìn)行要求或更改設(shè)計(jì)）。關(guān)鍵類(lèi)別包括添加的有關(guān)組件或功能是否具有冗余或?qū)⑹菃吸c(diǎn)故障的信息。

對(duì)于每個(gè)項(xiàng)目和中心，嚴(yán)重性級(jí)別和風(fēng)險(xiǎn)級(jí)別的排名可能會(huì)有所不同。畢竟，這并不是一門(mén)精確的科學(xué)，而是一門(mén)專(zhuān)業(yè)的最佳猜測(cè)（最佳工程判斷）。

下表列出了可靠性的關(guān)鍵類(lèi)別和安全風(fēng)險(xiǎn)等級(jí)之間的關(guān)系：

4.5檢測(cè)與補(bǔ)償

在這一步，您需要確定系統(tǒng)用于檢測(cè)危險(xiǎn)狀況的方法，以及系統(tǒng)中可以彌補(bǔ)該狀況的準(zhǔn)備。

對(duì)于每種故障模式，應(yīng)確定故障/故障檢測(cè)方法。故障檢測(cè)機(jī)制是一種方法，通過(guò)該方法，操作員可以在正常系統(tǒng)操作下或通過(guò)某些診斷來(lái)發(fā)現(xiàn)故障。硬件中的故障檢測(cè)是通過(guò)傳感設(shè)備或儀器進(jìn)行的。在軟件中，這可以通過(guò)檢錯(cuò)軟件對(duì)傳輸?shù)?a target="_blank">信號(hào)，數(shù)據(jù)或消息，內(nèi)存檢查，初始條件等進(jìn)行。

對(duì)于每種故障模式，應(yīng)確定補(bǔ)償性規(guī)定，如果不是危險(xiǎn)性故障，則應(yīng)接受風(fēng)險(xiǎn)。補(bǔ)償規(guī)定是設(shè)計(jì)規(guī)定或操作員采取的規(guī)避或緩解措施。在出現(xiàn)內(nèi)部故障故障時(shí)，需要執(zhí)行此步驟以記錄項(xiàng)目的真實(shí)行為。設(shè)計(jì)規(guī)定可以是多余的項(xiàng)目，也可以是功能減少的功能，以確保持續(xù)的安全運(yùn)行。操作員的動(dòng)作可以是在操作員控制臺(tái)上以有序方式關(guān)閉系統(tǒng)的通知。

一個(gè)示例：故障是由于斷電（硬件故障）或由于其他數(shù)據(jù)覆蓋了數(shù)據(jù)（軟件故障）而導(dǎo)致的數(shù)據(jù)丟失。

檢測(cè)：關(guān)鍵電源和CPU可能由UPS（不間斷電源）備份，也可能沒(méi)有。檢測(cè)到電源已丟失，系統(tǒng)現(xiàn)在已在此備用源上。在時(shí)間x將數(shù)據(jù)標(biāo)記為不可靠。這將是一種檢測(cè)方案。

補(bǔ)償此故障的發(fā)生：是否有該數(shù)據(jù)的另一個(gè)來(lái)源。可以重讀嗎？還是只是被標(biāo)記為可疑或被丟棄，然后等待下一個(gè)正常數(shù)據(jù)覆蓋它？擁有UPS，備用電池，冗余電源該怎么辦？當(dāng)然，這些都是硬件的答案。軟件能否檢測(cè)出是否可能懷疑數(shù)據(jù)并對(duì)其進(jìn)行標(biāo)記或扔掉，等待新輸入，請(qǐng)求新輸入，從備用來(lái)源獲取數(shù)據(jù)，從先前數(shù)據(jù)（趨勢(shì)）中進(jìn)行計(jì)算等？

如果輸入數(shù)據(jù)的輸入速度快于預(yù)期并且在處理之前覆蓋了先前的數(shù)據(jù)，該怎么辦。這個(gè)系統(tǒng)怎么知道？該怎么辦？例如，一個(gè)軟件系統(tǒng)通常會(huì)周期性地從40個(gè)源中接收數(shù)據(jù)輸入，然后由于部分故障或維護(hù)模式，現(xiàn)在只有20個(gè)源處于循環(huán)狀態(tài)，令牌的傳遞速度提高了2倍。緩沖區(qū)可以處理增加的數(shù)據(jù)速率嗎？

4.6設(shè)計(jì)變更

在確定了嚴(yán)重危害后，該項(xiàng)目需要

?確定糾正措施

?識(shí)別設(shè)計(jì)變更

?驗(yàn)證更改

?跟蹤所有更改以關(guān)閉

在確定了嚴(yán)重危害后，通常可以消除或減輕危害。這兩個(gè)動(dòng)作中任何一個(gè)的結(jié)果都是糾正措施。糾正措施可以通過(guò)記錄在案的新要求，設(shè)計(jì)，過(guò)程，程序等來(lái)實(shí)現(xiàn)。一旦實(shí)施，就必須進(jìn)行分析和驗(yàn)證以糾正故障或危害。

進(jìn)行更改后，務(wù)必查看新設(shè)計(jì)，以確認(rèn)沒(méi)有新的危險(xiǎn)產(chǎn)生。

4.7糾正性變更的影響

糾正措施將產(chǎn)生影響。影響可能是進(jìn)度，設(shè)計(jì)，功能，性能，過(guò)程等。如果糾正措施導(dǎo)致軟件設(shè)計(jì)發(fā)生變化，則該軟件的某些部分將受到影響。即使糾正措施是修改操作員使用系統(tǒng)的方式，也會(huì)產(chǎn)生影響。

您需要返回并分析更改對(duì)系統(tǒng)或操作過(guò)程的影響，以確保它們（單獨(dú)或共同）不會(huì)產(chǎn)生不利影響，并且不會(huì)為安全關(guān)鍵功能或組件創(chuàng)建新的故障模式。

修復(fù)程序通常會(huì)引入更多錯(cuò)誤，并且必須有一套確定的過(guò)程來(lái)確保在安全關(guān)鍵系統(tǒng)中不會(huì)發(fā)生這種情況。確保驗(yàn)證程序覆蓋受影響的區(qū)域。