《核工程+數字化儀控+核安全+核動力》@EnzoReventon

核電廠功能安全分類以及相關標準

1 根據核電廠安全功能的重要性進行分類

參考 IEC61226-2005，核電廠的安全功能按其重要性分為 A、B 和C三類。

- A類

在發生任何一個DBC-2到DBC-4內部事件后，將電廠帶入可控狀態的安全功能（包括支持功能）都定義為A類。此處DBC是指設計基準工況，按核電廠發生該工況的頻率大小，分為4級。數字越大，工況越稀有但后果越嚴重。

- B類

在發生任何一個DBC-2到DBC-4內部事件，電廠達到可控狀態后，用于確保電廠進入安全停堆狀態的安全功能都定義為B類。
在電廠正常運行時故障可以導致DBC-3或DBC-4事件的控制功能（一回路隔離）也定義為B類。

- C類

在DEC-A事件序列后將確保電廠帶到并維持在最終狀態的安全功能定義為C類。

2 軟件可靠性要求

“軟件可靠性”是軟件質量度量的六大屬性之一。軟件可靠性的定義是軟件系統在規定的時間內及規定的環境條件下，完成規定功能的能力，表明一個由軟件構建的儀控系統能夠按照核電安全設計要求和目標，正確執行其功能的程度。

從軟件可靠性工程的角度，核安全級軟件的可靠性、性能以及安全性問題都需要通過軟件周期模型各個階段的設計工作予以解決。軟件生命周期各階段與軟件可靠性相關的主要活動和任務如下圖所示。

軟件可靠性要求，除生命周期模型，還需要考慮業內相關法規、標準對安全級軟件的可靠性要求。國際上，IEEE 軟件可靠性標準主要涉及軟件可靠性度量體系和軟件可靠性評估兩方面內容

IEEE 982.1-2005 為軟件可靠性度量標準，主要定義了度量軟件可靠性宜采用的12 個度量參數，包括失效率、平均失效間隔時間、缺陷密度、與需求的一致性、網絡可靠性等，借此可對軟件質量、特別是軟件可靠性進行預測評估。

IEEE 1633-2008（軟件可靠性操作規程）重點規定了軟件可靠性評估的實施
程和可采用的軟件可靠性評估模型，該標準也是當前最新的、較為全面的有關軟件可靠性評估的國際標準。

最后，聚焦核電領域，核電的法規標準近幾年都在不斷強調核電安全級軟件的可靠性設計與評估要求，但是缺乏 IEEE 那樣具備具體操作指導的內容：

HAD 102/16-2004基于“只有遵循系統化、文件化和可評審的工程步驟，才能夠預計并證明軟件可信性”的觀點，對核動力廠基于計算機的安全重要系統軟件的生命周期各個階段應實施的活動、主要內容、質量保證、以及文件編制等方面提出詳細要求，從而以為安全性設計審查論證提供證據。

IEEE 7-4.3.2-2011在 5.15 可靠性一節中要求在論證核安全級數字化系統的可靠性時應考慮軟件。當采用分析、現場經驗或測試相結合的方法論證系統可靠性時，也將軟件錯誤記錄和趨勢納入其中。

IEC 61513-2011在 6.2.4.2.2 可靠性評定一節中要求：“軟件可能的設計缺陷對功能可靠性影響的評估宜基于定性評價，并考慮設計的復雜性、開發過程的質量以及運行經驗的反饋。評價宜基于先前認可的方法，宜證明軟件質量符合可靠性目標。”

劉真. 核電廠安全級軟件可靠性設計審查、分析與測試方法研究[D].上海交通大學,2015.

3 軟件可靠性避錯設計審查

設計缺陷是軟件失效的根源之一，為避免軟件失效，軟件開發過程中盡可能避免或減少缺陷。軟件避錯設計審查要依據具體的技術審查條款，檢查是否將這些保障軟件可靠性的技術要求在軟件開發過程規范并加以實現。

以軟件設計與實現活動為例，通過梳理歸納美國核管會 NRC 技術報告NUREG/CR-6101、國際電工委員會核電標準 IEC60880、并結合核電工程建設經驗，軟件可靠性設計技術審查需重點關注以下可靠性要求。包括：

• 在軟件需求書里面給出的每個需求能否追蹤到一個或者多個具體的實現該需求的設計元素？
• 每個設計元素能夠被追蹤到一個或者多個設計元素實現的具體需求？
• 是否有足夠的證據表明在設計中沒有計劃外的功能？
• 設計是否完整、協調、正確、無歧義且簡單？
• 靜態和動態結構是否簡單，設計元素間有最小的聯系？
• 軟件結構是否實質上層次分明？
• 對于創建軟件結構，每個層次的改進過程是否完整、自協調、以及與上一級協調（如果有）？
• 設計是否將重要的安全功能與正常操作功能分離，且它們之間設有定義明確的交互？
• 浮點算法比較
• 慎用遞歸算法
• 中斷，處理周期計時器中斷
• 單個處理器處理多過程
• 動態內存管理
• 過程間的事件驅動通信
• 如果有多于一個正式的設計方法，它們是否相互協調？
• 是否確認重要安全數據條目，包括它們的類型、單位、范圍和誤差界？
• 設計元素間控制連接的設計是否正確，相協調？
• 是否已證明設計元素間經過的所有參數在種類、結構、物理單元和方向上都相協調？
• 是否有令人信服的證據表明在初始化之前沒有使用重要安全相關的數據條目？
• 在設計過程中，需求規范中所列出的設計限制是否已遵循？
• 已知的對設計的外部限制是否確認并包含進設計中？這包括硬件限制、設備限制、保護系統設備的操作、物理規律和相似的內容
• 將代碼調入或者調出存儲器
• 無法保證終止的循環
• 某種方式存入數組，指數無法保證在數組指數范圍內
• 無條件分支
• 分支進入循環或者模塊
• 分支出循環，除了直到循環結束后的聲明，或者知道錯誤程序
• 將“if”聲明嵌套超過 3-4 層
• 在“case”結構中應用默認條件
• 在子程序中使用多個入口點
• 變量過載（使用同一個變量超過一個目的）
• 動態指令修正
• 變量隱式類型
• 在 FORTRAN 中使用“equivalence”聲明
• 模塊帶有除了向執行器輸出、終止或者入檔外的側放作用。
• 將程序以參數的形式輸給子程序
• 測試浮點數是否真的相等。
• 代碼的邏輯是否正確完成重要安全設計標準？
• 設計的方程和算法是否在代碼中正確實現
• 代碼是否正確實現誤差處理設計？
• 代碼是否正確實現非正常和緊急處理設計？
• 是否存在令人信服的證據表明被認為不重要的代碼能夠對功能、時序和重要安全代碼的可靠性產生不利影響。
• 是否存在令人信服的證據表明，程序中包含的任何中斷都不會優先于或者組織重要安全代碼模塊的執行
• 代碼中所定義和使用的數據條目是否與軟件設計中一致？
• 代碼中的每個數據條目是否表示為顯式類型？
• 是否存在令人信服的論據表明，沒有重要安全數據條目會以非計劃的方式或者被一個非預料到的模塊改變？
• 是否存在令人信服的論據表明，沒有中斷可以毀掉重要安全數據條目？
• 編碼模塊中參數的傳輸是否進行一致性分析，包括類型、結構、物理單位以及參數的數值和順序？

4 軟件可靠性容錯設計審查

軟件避錯設計體現了以預防為主的思想，該方法適用一切類型的軟件，尤其是關鍵領域的軟件。但對于復雜的高可靠性、高安全性軟件，往往難以完全避免軟件的設計錯誤。軟件容錯設計體現了對軟件錯誤的包容思想。容錯設計審查是避錯設計審查的“縱深防御”措施，主要審查軟件錯誤的檢測、失效的避免，以及系統恢復等，下面主要從冗余設計審查、多樣性設計審查、故障檢測和自恢復等方面描述軟件容錯設計審查的要求。

5 軟件多樣性設計的審查

多樣性審查主要考慮人員多樣性、設計多樣性、軟件多樣性、功能多樣性、信號多樣性和設備多樣性 。

- 人員多樣性： 審查設計人員獨立性、維護人員分組，以減少同樣錯誤的發生。
- 設計多樣性： 審查硬件和軟件的不同設計方法以及設計的獨立性，以使設計擁有不同的失效模式。
- 軟件多樣性： 審查使用不同設計者和不同程序設計，以至同樣錯誤不會反復。
- 功能多樣性： 審查系統是否使用多個子系統來執行不同的功能。
- 信號多樣性： 審查是否使用不同測量參數來啟動保護機制。
- 設備多樣性： 審查是否采用不同的設備來執行相似的安全功能，以使受到失效影響的可能盡量減小。

6 軟件故障檢測與自恢復技術的設計審查

對軟件故障檢測與自恢復技術的設計審查應重點考慮如下內容：

• 系統中是否設置有看門狗定時器?
• 看門狗定時器是否可以對每一個執行重要功能的進程的運行狀態進行監控？
• 系統故障檢測和自恢復功能是否能及時捕捉到程序故障、中斷相應保護功能子程序，并執行內部設定的、相應故障識別修復功能？
• 系統故障檢測和自恢復功能能否實現以下功能的檢查，包括：
  ‐ 是否改寫系統設置的 RAM 保護區？
  ‐ 采樣數據是否在合理范圍內？
  ‐ 能否重讀控制輸出的反饋狀態值，并與系統設置的標準范圍值進行一致性檢查？
  ‐ 系統故障檢測和自恢復功能能否對檢查出的錯誤進行危害嚴重性判斷，
  并執行預設的恢復功能、報警功能或其他必要的功能？

劉真. 核電廠安全級軟件可靠性設計審查、分析與測試方法研究[D].上海交通大學,2015.

總結

以上是生活随笔為你收集整理的核电厂功能安全分类、软件可靠性以及相关标准的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。