詳細介紹：
?
在功能安全設計過程中，執(zhí)行失效分析是必要的環(huán)節(jié)之一，傳統(tǒng)的基于硬件器件的失效分析已經(jīng)較為成熟，但基于軟件設計的失效分析還不為很多人了解，本文對軟件失效分析進行初步的概述，后續(xù)將持續(xù)推出更多的詳細介紹文章。
1、基本原理
軟件HAZOP的基本流程和方法說明見標準《危險與可操作性分析(HAZOP)應用指南》。
軟件FMEA和FTA的基本流程見《Software FMECA and FTA Guidance》。
2、對于可編程電子（PES）相關的HAZOP引導詞
引導詞 | 標準解釋 | 在PES中的解釋 |
No | 完全沒有達到設計意圖 | 沒有信號（信息）通過 |
More | 數(shù)量上的增加 | 比預期有更多的信號（信息）通過。 對于某個特定的值（變量），意味著這個值（變量）太高了。 |
Less | 數(shù)量上的減少 | 和PART OF是相同的 |
As well as | 性質上的變化（增多） | 和MORE是相同的 |
Part of | 性質上的變化（減少） | 信號信息不完整 |
Reverse | 與設計意圖邏輯相反 | 一般不使用 |
Other than | 完全替代 | 信號信息是完整的并且語法正確，但內容/功能/語義不正確 |
Early | 早 | 信號到達得過早，相對于參考時鐘時間 |
Before | 晚 | 信號比預期的順序達到得要早 |
Late | 先 | 信號到達得過晚，相對于參考時鐘時間 |
After | 后 | 信號比預期的順序達到得要晚 |
3、軟件失效分析的目的
在IEC61508的生命周期模型中，明確給出了需要執(zhí)行軟件驗證。軟件驗證一般可以采用設計復審的方式，但該方法的缺點是如果沒有一套專門的導則，復審可能難以按照一套系統(tǒng)化的方式實施（可能只能零散的檢查、討論等）。因此復審的輸出非常依賴于開展該工作的人員。采用軟件失效分析可以采用更加系統(tǒng)化的方式實施驗證活動。
另一方面，由于系統(tǒng)性失效不能在軟件開發(fā)過程中完全避免，因此必須采用特定的故障措施（例如斷言）來控制可能發(fā)生的軟件失效，這些故障控制措施在對軟件進行修改時，也可以起到一定的提示作用。因此在對軟件架構進行驗證時，需要知道那些部分的軟件需要通過引入附加的措施實現(xiàn)故障控制，這些都可以通過軟件失效分析獲得。為了知道軟件組件可能發(fā)生那些故障，需要采用軟件HAZOP來確定軟件組件的失效模式和相關安全措施的有效性。執(zhí)行軟件失效分析，以證明關鍵軟件模塊不會由于其他部分的失效（導致對該模塊的輸入異常）對該模塊的功能造成不良影響。軟件失效分析的目的還包括：
加深對系統(tǒng)/軟件的認識，從而能夠識別出系統(tǒng)/軟件中最為關鍵和重要的模塊；
實現(xiàn)對軟件架構設計的驗證；
識別出系統(tǒng)/軟件中安全和非安全模塊，不同SIL要求模塊之間的獨立性和解耦；
識別出用于檢測失效的安全控制措施，如果某個模塊具有獨立的安全控制措施，那么該模塊的關鍵度可能就可以降低：
故障檢測和診斷措施；
錯誤檢測和糾正代碼；
失效斷言編程；
防御性編程；
作為優(yōu)化V&V活動的基礎。
4、關鍵度等級的定義
C1：無影響 interferencefree
模塊不會執(zhí)行安全相關或安全關鍵的功能，可能只會通過接口從關鍵模塊讀取一些信息；
C2：安全相關 safety relevant
模塊出現(xiàn)單個的信息錯誤或偏差不會導致不安全的狀態(tài)，但其他模塊的再發(fā)生失效將導致不安全的狀態(tài)；
C3：安全關鍵 safety critical
單個信息措施或偏差即會導致不安全狀態(tài)
5、典型實施流程
軟件失效分析的前提是軟件已經(jīng)被非常清楚的進行了層次和模塊細分，例如模塊、單元、實體、對象、類等等，并且所有組件之間的功能和接口非常清晰，這些可能在軟件架構設計/軟件安全要求規(guī)范文件中進行了說明。
對于這些組件的分析是通過發(fā)起假設：當其發(fā)生設計偏離時是否會導致危險的系統(tǒng)行為（當然這些首先取決于對于安全狀態(tài)和危險狀態(tài)有非常清晰的定義）。一個分析過程的示例是：某個組件可能最初被定義為C3級別，即當其發(fā)生單個失效時會導致危險場景，如果增加了某個診斷組件，可以對原來組件的失效進行檢測，那么此時需要當診斷組件和原來組件都發(fā)生失效才會導致危險場景，因此該組件降低為C2級別。不同關鍵度的典型功能如下表：
關鍵度 | 典型功能 | 理由 |
C1 | 歷史記錄 非安全相關的數(shù)據(jù)顯示 | 歷史記錄會讀取但不會修改安全數(shù)據(jù) 即是顯示組件與安全關鍵組件斷開了連接，安全功能仍能繼續(xù)正常運行 |
C2 | 看門狗觸發(fā)功能 錯誤處理功能 | 僅當檢測到錯誤時，兩個功能才起作用 |
C3 | 安全相關變送器的測量功能 | 安全功能完全取決于輸入信號的正確性 |
注：上表僅是一個通用性的說明，對于具體的軟件需要分析才能確定其具體的組件關鍵度。
6、關鍵度等級與SIL的關系
一般對于定義的關鍵度組件需要滿足的SIL要求如下表：
組件的SIL能力要求 | 組件關鍵度 |
C1 | C2 | C3 | 備注 |
SIL1 | 滿足獨立性和無影響性即可 | 滿足SIL1的適用性要求 | 滿足SIL1的適用性要求 |
|
SIL2 | 滿足獨立性和無影響性即可 | 滿足SIL1的適用性要求，且對于更高SIL的組件無影響 | 滿足SIL2的適用性要求 |
|
SIL3 | 滿足獨立性和無影響性即可 | 滿足SIL2的適用性要求，，且對于更高SIL的組件無影響 | 滿足SIL3的適用性要求 |
|
7、軟件HAZOP
軟件HAZOP的目的是識別哪些與設計意圖的偏離可能是潛在危險，以及系統(tǒng)內各個組件之間的相關關系。一般情況下對于軟件有如下劃分和定義：
軟件組件（software component）:一組軟件模塊用以執(zhí)行一組特定的功能（例如文件處理），軟件組件一般用接口進行描述；
軟件模塊：一個完整的軟件單元以執(zhí)行某個特定的功能（例如讀文件），軟件模塊用功能和接口進行描述；
通過軟件HAZOP可以系統(tǒng)性定義出“反向”測試用例。同軟件失效分析確定軟件代碼中哪些地方需要進行斷言編程或防御性編程。需要開展軟件HAZOP的代碼是不同的：
原則上關鍵度分析中，所有存在SIL降低情況（C2，C1）的軟件組件都需要執(zhí)行HAZOP；
對于C1的軟件組件，重點分析這些組件發(fā)生故障時，不會對C2，C3造成負面影響（這可能會包括對這些組件防護措施的分析，例如通過對指針范圍的檢查，確保其不會將數(shù)據(jù)寫入C2，C3分類的組件中）；
對于C2組件需要驗證其功能的實現(xiàn)不會到C3造成安全關鍵影響（例如某個RAM測試功能可能會在測試中造成RAM存儲的數(shù)據(jù)損壞，而且沒有辦法恢復）；
對于C3組件需要通過分析考慮是否存在C2的組件（監(jiān)視、診斷等功能）實現(xiàn)對其關鍵度的降級；
軟件HAZOP的基本流程如下：
1、初始化分析，定義范圍和目標
2、計劃分析的會議
3、執(zhí)行分析
4、審核分析，執(zhí)行改進
5、形成最終分析報告
分析過程中，一些典型的屬性和引導詞結合如下：
消息流圖表達軟件功能時的相關屬性：
屬性 | 引導詞 | 組合解釋 |
消息message | No | 沒有消息 某個對象沒有消息發(fā)出 某個對象沒有消息到達 |
Part of | 消息到達得不完整 |
Other than | 消息完整且語法正確，但內容或語義不正確 |
Early | 消息比起預期的早到 |
Late | 消息比其要求的晚到 |
More | 比預期的更多消息到來 |
Less | 比預期的更少的消息到來 |
數(shù)據(jù)里圖的表達時
屬性 | 引導詞 | 組合解釋 |
數(shù)據(jù)流data flow | No | 沒有信息流 |
Part of | 信息沒有完整的通過 |
Reverse | 信息流方向錯誤 |
Other than | 信息完整且語法正確，但內容或語義不正確 |
Early | 信息流發(fā)生得比其要求的早 |
Late | 信息流發(fā)生得比其要求的晚 |
More | 比預期的更多數(shù)據(jù)通過 |
數(shù)據(jù)率 | More | 數(shù)據(jù)率太高 |
Less | 數(shù)據(jù)率太低 |
數(shù)據(jù)值 | More | 數(shù)據(jù)值太高 |
Less | 數(shù)據(jù)值太低 |
對于狀態(tài)轉移圖
屬性 | 引導詞 | 組合解釋 |
事件 Event | No | 事件沒有發(fā)生 |
As well as | 另外的事件同時發(fā)生 |
Other than | 不同于預期事件的不期望事件發(fā)生 |
動作 Action | No | 沒有動作發(fā)生 |
As well as | 附加的動作發(fā)生 |
Part of | 動作執(zhí)行不完整 |
Other than | 錯誤的動作發(fā)生 |
