核电厂功能安全分类、软件可靠性以及相关标准
《核工程+數(shù)字化儀控+核安全+核動力》@EnzoReventon
核電廠功能安全分類以及相關(guān)標準
1 根據(jù)核電廠安全功能的重要性進行分類
參考 IEC61226-2005，核電廠的安全功能按其重要性分為 A、B 和C三類。
- A類
在發(fā)生任何一個DBC-2到DBC-4內(nèi)部事件后，將電廠帶入可控狀態(tài)的安全功能（包括支持功能）都定義為A類。此處DBC是指設(shè)計基準工況，按核電廠發(fā)生該工況的頻率大小，分為4級。數(shù)字越大，工況越稀有但后果越嚴重。
- B類
在發(fā)生任何一個DBC-2到DBC-4內(nèi)部事件，電廠達到可控狀態(tài)后，用于確保電廠進入安全停堆狀態(tài)的安全功能都定義為B類。
在電廠正常運行時故障可以導致DBC-3或DBC-4事件的控制功能（一回路隔離）也定義為B類。
- C類
在DEC-A事件序列后將確保電廠帶到并維持在最終狀態(tài)的安全功能定義為C類。
2 軟件可靠性要求
“軟件可靠性”是軟件質(zhì)量度量的六大屬性之一。軟件可靠性的定義是軟件系統(tǒng)在規(guī)定的時間內(nèi)及規(guī)定的環(huán)境條件下，完成規(guī)定功能的能力，表明一個由軟件構(gòu)建的儀控系統(tǒng)能夠按照核電安全設(shè)計要求和目標，正確執(zhí)行其功能的程度。
從軟件可靠性工程的角度，核安全級軟件的可靠性、性能以及安全性問題都需要通過軟件周期模型各個階段的設(shè)計工作予以解決。軟件生命周期各階段與軟件可靠性相關(guān)的主要活動和任務(wù)如下圖所示。
軟件可靠性要求，除生命周期模型，還需要考慮業(yè)內(nèi)相關(guān)法規(guī)、標準對安全級軟件的可靠性要求。國際上，IEEE 軟件可靠性標準主要涉及軟件可靠性度量體系和軟件可靠性評估兩方面內(nèi)容
IEEE 982.1-2005 為軟件可靠性度量標準，主要定義了度量軟件可靠性宜采用的12 個度量參數(shù)，包括失效率、平均失效間隔時間、缺陷密度、與需求的一致性、網(wǎng)絡(luò)可靠性等，借此可對軟件質(zhì)量、特別是軟件可靠性進行預(yù)測評估。
IEEE 1633-2008（軟件可靠性操作規(guī)程）重點規(guī)定了軟件可靠性評估的實施
程和可采用的軟件可靠性評估模型，該標準也是當前最新的、較為全面的有關(guān)軟件可靠性評估的國際標準。
最后，聚焦核電領(lǐng)域，核電的法規(guī)標準近幾年都在不斷強調(diào)核電安全級軟件的可靠性設(shè)計與評估要求，但是缺乏 IEEE 那樣具備具體操作指導的內(nèi)容：
HAD 102/16-2004基于“只有遵循系統(tǒng)化、文件化和可評審的工程步驟，才能夠預(yù)計并證明軟件可信性”的觀點，對核動力廠基于計算機的安全重要系統(tǒng)軟件的生命周期各個階段應(yīng)實施的活動、主要內(nèi)容、質(zhì)量保證、以及文件編制等方面提出詳細要求，從而以為安全性設(shè)計審查論證提供證據(jù)。
IEEE 7-4.3.2-2011在 5.15 可靠性一節(jié)中要求在論證核安全級數(shù)字化系統(tǒng)的可靠性時應(yīng)考慮軟件。當采用分析、現(xiàn)場經(jīng)驗或測試相結(jié)合的方法論證系統(tǒng)可靠性時，也將軟件錯誤記錄和趨勢納入其中。
IEC 61513-2011在 6.2.4.2.2 可靠性評定一節(jié)中要求：“軟件可能的設(shè)計缺陷對功能可靠性影響的評估宜基于定性評價，并考慮設(shè)計的復(fù)雜性、開發(fā)過程的質(zhì)量以及運行經(jīng)驗的反饋。評價宜基于先前認可的方法，宜證明軟件質(zhì)量符合可靠性目標。”
劉真. 核電廠安全級軟件可靠性設(shè)計審查、分析與測試方法研究[D].上海交通大學,2015.
3 軟件可靠性避錯設(shè)計審查
設(shè)計缺陷是軟件失效的根源之一，為避免軟件失效，軟件開發(fā)過程中盡可能避免或減少缺陷。軟件避錯設(shè)計審查要依據(jù)具體的技術(shù)審查條款，檢查是否將這些保障軟件可靠性的技術(shù)要求在軟件開發(fā)過程規(guī)范并加以實現(xiàn)。
以軟件設(shè)計與實現(xiàn)活動為例，通過梳理歸納美國核管會 NRC 技術(shù)報告NUREG/CR-6101、國際電工委員會核電標準 IEC60880、并結(jié)合核電工程建設(shè)經(jīng)驗，軟件可靠性設(shè)計技術(shù)審查需重點關(guān)注以下可靠性要求。包括：
- 在軟件需求書里面給出的每個需求能否追蹤到一個或者多個具體的實現(xiàn)該需求的設(shè)計元素？
- 每個設(shè)計元素能夠被追蹤到一個或者多個設(shè)計元素實現(xiàn)的具體需求？
- 是否有足夠的證據(jù)表明在設(shè)計中沒有計劃外的功能？
- 設(shè)計是否完整、協(xié)調(diào)、正確、無歧義且簡單？
- 靜態(tài)和動態(tài)結(jié)構(gòu)是否簡單，設(shè)計元素間有最小的聯(lián)系？
- 軟件結(jié)構(gòu)是否實質(zhì)上層次分明？
- 對于創(chuàng)建軟件結(jié)構(gòu)，每個層次的改進過程是否完整、自協(xié)調(diào)、以及與上一級協(xié)調(diào)（如果有）？
- 設(shè)計是否將重要的安全功能與正常操作功能分離，且它們之間設(shè)有定義明確的交互？
- 浮點算法比較
- 慎用遞歸算法
- 中斷，處理周期計時器中斷
- 單個處理器處理多過程
- 動態(tài)內(nèi)存管理
- 過程間的事件驅(qū)動通信
- 如果有多于一個正式的設(shè)計方法，它們是否相互協(xié)調(diào)？
- 是否確認重要安全數(shù)據(jù)條目，包括它們的類型、單位、范圍和誤差界？
- 設(shè)計元素間控制連接的設(shè)計是否正確，相協(xié)調(diào)？
- 是否已證明設(shè)計元素間經(jīng)過的所有參數(shù)在種類、結(jié)構(gòu)、物理單元和方向上都相協(xié)調(diào)？
- 是否有令人信服的證據(jù)表明在初始化之前沒有使用重要安全相關(guān)的數(shù)據(jù)條目？
- 在設(shè)計過程中，需求規(guī)范中所列出的設(shè)計限制是否已遵循？
- 已知的對設(shè)計的外部限制是否確認并包含進設(shè)計中？這包括硬件限制、設(shè)備限制、保護系統(tǒng)設(shè)備的操作、物理規(guī)律和相似的內(nèi)容
- 將代碼調(diào)入或者調(diào)出存儲器
- 無法保證終止的循環(huán)
- 某種方式存入數(shù)組，指數(shù)無法保證在數(shù)組指數(shù)范圍內(nèi)
- 無條件分支
- 分支進入循環(huán)或者模塊
- 分支出循環(huán)，除了直到循環(huán)結(jié)束后的聲明，或者知道錯誤程序
- 將“if”聲明嵌套超過 3-4 層
- 在“case”結(jié)構(gòu)中應(yīng)用默認條件
- 在子程序中使用多個入口點
- 變量過載（使用同一個變量超過一個目的）
- 動態(tài)指令修正
- 變量隱式類型
- 在 FORTRAN 中使用“equivalence”聲明
- 模塊帶有除了向執(zhí)行器輸出、終止或者入檔外的側(cè)放作用。
- 將程序以參數(shù)的形式輸給子程序
- 測試浮點數(shù)是否真的相等。
- 代碼的邏輯是否正確完成重要安全設(shè)計標準？
- 設(shè)計的方程和算法是否在代碼中正確實現(xiàn)
- 代碼是否正確實現(xiàn)誤差處理設(shè)計？
- 代碼是否正確實現(xiàn)非正常和緊急處理設(shè)計？
- 是否存在令人信服的證據(jù)表明被認為不重要的代碼能夠?qū)δ堋r序和重要安全代碼的可靠性產(chǎn)生不利影響。
- 是否存在令人信服的證據(jù)表明，程序中包含的任何中斷都不會優(yōu)先于或者組織重要安全代碼模塊的執(zhí)行
- 代碼中所定義和使用的數(shù)據(jù)條目是否與軟件設(shè)計中一致？
- 代碼中的每個數(shù)據(jù)條目是否表示為顯式類型？
- 是否存在令人信服的論據(jù)表明，沒有重要安全數(shù)據(jù)條目會以非計劃的方式或者被一個非預(yù)料到的模塊改變？
- 是否存在令人信服的論據(jù)表明，沒有中斷可以毀掉重要安全數(shù)據(jù)條目？
- 編碼模塊中參數(shù)的傳輸是否進行一致性分析，包括類型、結(jié)構(gòu)、物理單位以及參數(shù)的數(shù)值和順序？
4 軟件可靠性容錯設(shè)計審查
軟件避錯設(shè)計體現(xiàn)了以預(yù)防為主的思想，該方法適用一切類型的軟件，尤其是關(guān)鍵領(lǐng)域的軟件。但對于復(fù)雜的高可靠性、高安全性軟件，往往難以完全避免軟件的設(shè)計錯誤。軟件容錯設(shè)計體現(xiàn)了對軟件錯誤的包容思想。容錯設(shè)計審查是避錯設(shè)計審查的“縱深防御”措施，主要審查軟件錯誤的檢測、失效的避免，以及系統(tǒng)恢復(fù)等，下面主要從冗余設(shè)計審查、多樣性設(shè)計審查、故障檢測和自恢復(fù)等方面描述軟件容錯設(shè)計審查的要求。
5 軟件多樣性設(shè)計的審查
多樣性審查主要考慮人員多樣性、設(shè)計多樣性、軟件多樣性、功能多樣性、信號多樣性和設(shè)備多樣性 。
- 人員多樣性： 審查設(shè)計人員獨立性、維護人員分組，以減少同樣錯誤的發(fā)生。
- 設(shè)計多樣性： 審查硬件和軟件的不同設(shè)計方法以及設(shè)計的獨立性，以使設(shè)計擁有不同的失效模式。
- 軟件多樣性： 審查使用不同設(shè)計者和不同程序設(shè)計，以至同樣錯誤不會反復(fù)。
- 功能多樣性： 審查系統(tǒng)是否使用多個子系統(tǒng)來執(zhí)行不同的功能。
- 信號多樣性： 審查是否使用不同測量參數(shù)來啟動保護機制。
- 設(shè)備多樣性： 審查是否采用不同的設(shè)備來執(zhí)行相似的安全功能，以使受到失效影響的可能盡量減小。
6 軟件故障檢測與自恢復(fù)技術(shù)的設(shè)計審查
對軟件故障檢測與自恢復(fù)技術(shù)的設(shè)計審查應(yīng)重點考慮如下內(nèi)容：
- 系統(tǒng)中是否設(shè)置有看門狗定時器?
- 看門狗定時器是否可以對每一個執(zhí)行重要功能的進程的運行狀態(tài)進行監(jiān)控？
- 系統(tǒng)故障檢測和自恢復(fù)功能是否能及時捕捉到程序故障、中斷相應(yīng)保護功能子程序，并執(zhí)行內(nèi)部設(shè)定的、相應(yīng)故障識別修復(fù)功能？
- 系統(tǒng)故障檢測和自恢復(fù)功能能否實現(xiàn)以下功能的檢查，包括：
‐ 是否改寫系統(tǒng)設(shè)置的 RAM 保護區(qū)？
‐ 采樣數(shù)據(jù)是否在合理范圍內(nèi)？
‐ 能否重讀控制輸出的反饋狀態(tài)值，并與系統(tǒng)設(shè)置的標準范圍值進行一致性檢查？
‐ 系統(tǒng)故障檢測和自恢復(fù)功能能否對檢查出的錯誤進行危害嚴重性判斷，
并執(zhí)行預(yù)設(shè)的恢復(fù)功能、報警功能或其他必要的功能？
劉真. 核電廠安全級軟件可靠性設(shè)計審查、分析與測試方法研究[D].上海交通大學,2015.
總結(jié)
以上是生活随笔為你收集整理的核电厂功能安全分类、软件可靠性以及相关标准的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 我是如何入门机器学习的呢
- 下一篇： 显示日期的指令： date