★北京廣利核系統(tǒng)工程有限公司 周良,張磊,杜喬瑞,梁中起
核電廠RPS應(yīng)用軟件V&V危險分析的研究
★北京廣利核系統(tǒng)工程有限公司 周良,張磊,杜喬瑞,梁中起
在核電廠反應(yīng)堆保護系統(tǒng)(RPS)儀表控制設(shè)備的數(shù)字化過程中,如何保證核安全級軟件的安全性是一個重要問題。危險分析是識別系統(tǒng)潛在的危險,以及采取適當?shù)氖侄蝸硐?、防止或控制危險,提高安全性的一種有效方法。它在傳統(tǒng)模擬技術(shù)儀表控制系統(tǒng)中已經(jīng)廣泛使用,但應(yīng)用于針對數(shù)字化儀表控制系統(tǒng)的危險分析時,目前為止還沒有可操作的指導(dǎo)標準與規(guī)范。本文提出一種適用于核電廠RPS應(yīng)用軟件V&V危險分析的方法,結(jié)合某堆型RPS具體論述了軟件開發(fā)各階段的V&V危險分析內(nèi)容,可為相關(guān)組織制定可操作性較強的危險分析規(guī)范提供參考。
核電站;保護系統(tǒng);驗證與確認;危險分析
基于計算機的系統(tǒng)已經(jīng)在核動力廠日益廣泛應(yīng)用,它們對核動力廠安全的重要性也正在增加[1]。這類系統(tǒng)既用于安全有關(guān)級系統(tǒng),也用于安全系統(tǒng)(例如反應(yīng)堆保護或安全設(shè)施的驅(qū)動)。核電站反應(yīng)堆保護系統(tǒng)屬于核電廠1E級儀表控制設(shè)備,用以保護三大核安全屏障(即燃料包殼、一回路壓力邊界和安全殼)的完整性。
在核電站保護系統(tǒng)儀表控制設(shè)備的數(shù)字化過程中,一個必然要解決的重要問題是核安全軟件的安全性。特別是福島核電站事故發(fā)生后,國家安全監(jiān)管當局根據(jù)核行業(yè)法規(guī),對后續(xù)新建核電站數(shù)字化保護系統(tǒng)的安全性提出更高要求。從系統(tǒng)的觀念出發(fā),運用科學(xué)分析方法識別、評價、控制危險,使系統(tǒng)達到最佳安全。
識別系統(tǒng)潛在的危險,以及采取適當?shù)男枨?、設(shè)計和其它制約因素來消除、防止或控制發(fā)現(xiàn)的危險的一個過程就是危險分析[2],以達到預(yù)防事故、實現(xiàn)系統(tǒng)安全的目的。人們在實踐中形成了多種與傳統(tǒng)模擬儀表控制系統(tǒng)有關(guān)的危險分析技術(shù),并形成了一些重要的與危險分析相關(guān)的標準或規(guī)范(例如IEEE Std 577TM-2004[3],IEEE Std 352TM-1987[4],IEEE Std1228TM-1994[5]和 MIL-Std-882B[6])。而目前為止還沒有可操作的軟件危險分析的程序與規(guī)范,因此研究適合核電站數(shù)字化保護系統(tǒng)軟件危險分析的程序與規(guī)范以及相關(guān)的各項技術(shù)意義重大。
危險性多用于刻畫具有能量、毒性或能夠進行質(zhì)量運動的物理設(shè)備或系統(tǒng),與硬件設(shè)備不同,軟件作為一種寄生性邏輯實體,軟件自身不會直接對人造成傷害或?qū)Νh(huán)境造成破壞。盡管作為系統(tǒng)重要組成要素的軟件不會直接危及生命、財產(chǎn)和環(huán)境等安全,但由于軟件設(shè)計存在缺陷,軟件運行時控制設(shè)備運行不當或者軟件未能控制設(shè)備運行,會形成危險。
目前標準沒有明確給出軟件危險性的定義,根據(jù)對軟件危險性的理解,給出軟件危險性的下述定義:
軟件危險性是指特定軟件對特定系統(tǒng)危險性的貢獻,衡量的是在特定環(huán)境下和規(guī)定時間內(nèi)因軟件功能失效或需求缺陷等引發(fā)系統(tǒng)危險的能力。其中系統(tǒng)危險性受到軟件(SW)、硬件(HW)、人員(Human)、外部環(huán)境(Env)的共同作用。外部環(huán)境泛指與該系統(tǒng)交互作用的外部系統(tǒng)或其他因素。比如,對于反應(yīng)堆保護系統(tǒng)軟件而言,其危險性研究涉及到保護系統(tǒng)軟件內(nèi)部組件之間的交互,保護軟件與保護系統(tǒng)底層硬件之間的交互,保護軟件與操縱員、非安全級系統(tǒng)等其它系統(tǒng)之間的交互。
保護系統(tǒng)中事故的發(fā)生是硬件(設(shè)備)部分、人員、外部環(huán)境和軟件共同作用的結(jié)果。事件是事故的重要因素,包括引發(fā)事件、中間過程事件和后果事件。引發(fā)事件是事故過程中的第1個不希望事件,其發(fā)生標志著事故過程的開始;后果事件是造成某種惡性后果的不希望事件,它直接導(dǎo)致人員傷亡、財產(chǎn)損失、環(huán)境破壞等損失;事變事件是指在引發(fā)事件后可能發(fā)生的惡性事件,如果未得到緩減控制,這些事件將導(dǎo)向后果事件。引發(fā)事件、事變事件和后果事件都是事故場景過程中的一個環(huán)節(jié),都是系統(tǒng)運行中的不期望事件。[7]軟件之所以導(dǎo)致事故,就是因為軟件中潛在的缺陷造成引發(fā)事件發(fā)生,或致使緩減控制措施失效。盡量避免上述情況的出現(xiàn)正是軟件危險分析的目的。
保護系統(tǒng)的軟件危險分析應(yīng)當與整個系統(tǒng)設(shè)計緊密結(jié)合,成為系統(tǒng)危險分析的一部分。系統(tǒng)軟件危險分析的目的是精確地分析和評估系統(tǒng)軟件引發(fā)的真實危險,并采取相應(yīng)的措施,以確保把這種危險的發(fā)生概率降低到最低可接受的程度。
為了進行危險分析,必須建立相應(yīng)的分析程序,以便系統(tǒng)、全面地規(guī)劃危險分析工作。本文依據(jù)保護系統(tǒng)的特點以及工程經(jīng)驗,提出了一種適用于保護系統(tǒng)的軟件V&V危險分析的策略和程序,如圖1所示。
(1)分析策略
危險分析的成功很大程度取決于良好的方案,應(yīng)使危險分析作為系統(tǒng)設(shè)計過程的一個組成部分,在框架下滲入各級組織的活動。在系統(tǒng)研制成功以后則把危險分析作為改進過程的組成部分,從而使危險分析成為生命周期的組成部分。制定“危險分析”方案幫助危險分析過程的順利開展。
(2)分析程序
危險分析貫穿系統(tǒng)全生命周期。在不同的生命階段,系統(tǒng)設(shè)計的詳細程度不同,分析人員可利用的數(shù)據(jù)不同,因此危險性分析的過程及其詳細程度也不一樣,應(yīng)該是一個不斷深入、不斷細化的迭代過程。軟件危險分析人員不僅必須理解軟件在系統(tǒng)運行中的各種作用,而且必須知道軟件運行時對系統(tǒng)安全的影響。
圖1所示的分析程序不僅給出了各項分析工作的關(guān)系,而且也給出了各項工作的角色。
下面,按分析程序論述各項分析工作。
4.1 系統(tǒng)設(shè)計危險分析
(1)安全功能
反應(yīng)堆保護系統(tǒng)危險的識別過程開始于對要求的安全功能、設(shè)計基準工況、選定的系統(tǒng)設(shè)計要素(如子系統(tǒng)、多樣化系統(tǒng)等)和法規(guī)標準要求的理解。根據(jù)分析結(jié)果,可確定計算機系統(tǒng)的某些安全功能、設(shè)計條件、限制及未解決的危險。
反應(yīng)堆保護系統(tǒng)指監(jiān)測反應(yīng)堆的運行,并根據(jù)接收到的異常工況信號,自動觸發(fā)動作以防止發(fā)生不安全或潛在的不安全工況的系統(tǒng)。[8]反應(yīng)堆保護系統(tǒng)主要包括反應(yīng)堆事故停堆系統(tǒng)(RTS)和專設(shè)安全驅(qū)動系統(tǒng)(ESFAS)。其中運行的核安全級軟件也必然要包括兩部分,一部分用于執(zhí)行反應(yīng)堆停堆功能,當需要時產(chǎn)生控制動作觸發(fā)反應(yīng)堆停堆。另一部分用于執(zhí)行專設(shè)安全設(shè)施驅(qū)動功能,安全設(shè)施包括驅(qū)動單元及適當?shù)脑O(shè)備布置,根據(jù)驅(qū)動系統(tǒng)或者操作員發(fā)出的信號實現(xiàn)保護功能。
(2)功能危險分析
A. 分析對象:包括系統(tǒng)設(shè)計、專項功能設(shè)計、子系統(tǒng)設(shè)計等技術(shù)規(guī)格書。
B. 分析目標:由總體人員進行系統(tǒng)危險性分析,獲得與軟件相關(guān)的系統(tǒng)危險模式,確定影響系統(tǒng)運行的關(guān)鍵危險事件,及其應(yīng)對措施。
C. 分析要點:
RPS系統(tǒng)設(shè)計危險分析應(yīng)考慮安全功能的要求,進行功能危險分析,只是把重點放在硬件和軟件的初步設(shè)計上。例如應(yīng)把下述各項作為可能的危險:
· 硬件和軟件之間的相互依賴性(例如中斷和操作系統(tǒng));
· 可能使系統(tǒng)進入危險狀態(tài)的動作序列,系統(tǒng)架構(gòu)對可靠性指標分配的影響;
· 系統(tǒng)特有的可信危險,例如超前或滯后的輸出、傳感器輸入處理故障、準確度和舍入問題、例外情況的不恰當處理、恢復(fù)動作、系統(tǒng)中斷、輸入電壓或頻率的波動、符合信號改變的最大可信數(shù)目、電磁干擾和超量程數(shù)值(如被零除或未初始化的指示)、CPU重啟、程序下裝。
系統(tǒng)功能危險分析,主要致力于RPS中相應(yīng)軟件的功能安全性分析。
RRS系統(tǒng)設(shè)計應(yīng)規(guī)定為了阻止系統(tǒng)進入危險狀態(tài)或者使系統(tǒng)從危險狀態(tài)進入到非危險狀態(tài)而需要由硬件或軟件完成的那些功能,而且應(yīng)識別和規(guī)定軟件和計算機系統(tǒng)之間的接口。
RPS系統(tǒng)的危險識別由粗到細,逐步細化。危險的識別通過制定初步危險表(PHL)來完成,從而為初步危險分析( PHA)確定了范圍。在系統(tǒng)設(shè)計的早期進行PHA,可以確定構(gòu)成系統(tǒng)中事故的潛在條件和可能的事故,但此時的分析是不詳細的,不能準確地描述事故發(fā)展的過程,在系統(tǒng)設(shè)計階段,分系統(tǒng)設(shè)計一旦確定,就需進行分系統(tǒng)危險分析。分系統(tǒng)危險分析深入到具體的分系統(tǒng)內(nèi)部,通過選擇具體的危險分析技術(shù),F(xiàn)MEA、FTA等來確定造成潛在條件的原因和事故發(fā)展過程。
4.2 軟件開發(fā)危險分析
(1)軟件需求危險分析
A. 分析對象:軟件需求規(guī)格書,內(nèi)容包括軟件頂層架構(gòu)、軟件接口設(shè)計、軟件功能和性能需求。
B. 分析目標:在系統(tǒng)設(shè)計危險分析的基礎(chǔ)上進行軟件需求危險分析,確定系統(tǒng)不應(yīng)做什么,即軟件應(yīng)滿足哪些安全需求,同時提出軟件確認測試計劃中的安全要求。
C. 分析要點:
在軟件需求的危險識別過程中評價軟件和接口需求,并識別出可能成為危險產(chǎn)生原因的差錯和缺陷。此階段首先確定與安全功能相關(guān)的每一項軟件需求,識別由于需求不滿足可能導(dǎo)致的事故,并評估相應(yīng)的風(fēng)險。如果風(fēng)險不可接受,則系統(tǒng)設(shè)計必須進行一定的更改,使得軟件在所有的運行模式和條件下,其性能、功能和接口設(shè)計都能達到所要求的安全水平。
在進行軟件需求危險識別時應(yīng)將軟件需求與硬件設(shè)計的相容性作為一個基本問題。例如包括下述活動:
· 分析I&C功能分站對可靠性指標的影響。
· 確信沒有引入有害的“未預(yù)期功能”。例如無用的駐留功能、對外部或內(nèi)部條件的不可預(yù)測響應(yīng)、由于設(shè)計或?qū)崿F(xiàn)錯誤產(chǎn)生的缺陷、未從軟件中消除的研制輔助手段。
軟件故障樹(SFTA)、故障模式和影響分析(FMEA)等技術(shù)都可用來進行需求危險分析。需求危險分析結(jié)果是下一步設(shè)計危險分析的基礎(chǔ)。
(2)軟件設(shè)計危險分析
A. 分析對象:軟件設(shè)計階段工作一般分為概要設(shè)計和詳細設(shè)計二個階段。
B. 分析目標:檢查軟件設(shè)計是否體現(xiàn)了安全需求以及在設(shè)計過程中是否引入新的安全需求。
C. 分析要點:
一項軟件需求可能由多個設(shè)計部分(如模塊、文件等)來完成;每一個設(shè)計部分也可能與多項軟件需求相關(guān),需求部分和設(shè)計部分之間存在多對多的映射關(guān)系。如果設(shè)計部分風(fēng)險不可接受,則需要考慮重新設(shè)計,以降低設(shè)計的風(fēng)險,或采取其它措施以降低整個應(yīng)用系統(tǒng)的風(fēng)險。
某些系統(tǒng)的設(shè)計危險分析還涉及到軟件所運行的計算機系統(tǒng)的硬件體系結(jié)構(gòu)。此時還需要考慮硬件體系結(jié)構(gòu)設(shè)計是否會引入復(fù)雜的功能,是否存在新的失效模式。這些新的失效模式在系統(tǒng)危險分析和需求危險分析時不能發(fā)現(xiàn),但在設(shè)計分析階段必須予以識別。
軟件設(shè)計階段的危險識別所包括的活動應(yīng)確信沒有引進新的危險。例如在這一階段應(yīng)進行下列活動:
· 應(yīng)對可能存在的計算問題進行評價,這些問題包括錯誤的算法、不夠的精度(錯誤的數(shù)據(jù)類型)、掃描速率和符號約定錯誤。
· 對控制邏輯中可能存在的問題進行評價,這些問題包括邏輯錯誤、遺漏的情況或步驟、重復(fù)邏輯、忽略的極端情況、不必要的功能、錯誤解釋需求、遺漏條件測試、未檢查變量和不正確的迭代循環(huán)等。
· 對數(shù)據(jù)結(jié)構(gòu)和預(yù)期使用中的數(shù)據(jù)從屬性進行評價,這種從屬性損害隔離分區(qū)、數(shù)據(jù)別名使用和故障抑制問題,從而會影響安全和對危險的控制或緩解。
· 應(yīng)對接口設(shè)計進行審查,包括內(nèi)部接口以及同系統(tǒng)其他模塊之間的外部接口,對接口關(guān)注的主要方面是適當規(guī)定的協(xié)議以及控制和數(shù)據(jù)鏈接。對外部接口應(yīng)進行評價,以便核實設(shè)計中的通信協(xié)議同接口要求是相容的,接口的評價應(yīng)支持冗余管理分區(qū)和危險抑制的要求,可能存在的接口和定時問題包括錯誤地處理接口、不正確的輸入和輸出時序,以及子程序/模塊不匹配。
· 應(yīng)確信設(shè)計符合已確定的系統(tǒng)限制。
· 應(yīng)對非安全模塊進行評價,以便確信它們不會對安全軟件產(chǎn)生有害的影響。
本階段主要的危險分析技術(shù)有SFTA、SHAZOP。設(shè)計危險分析的結(jié)果確定了軟件實現(xiàn)危險分析的重點,為下一步的軟件實現(xiàn)危險分析提供輸入。
(3)軟件實現(xiàn)危險分析
A. 分析對象:源代碼和可執(zhí)行代碼。
B. 分析目標:軟件實現(xiàn)危險分析主要檢查在實現(xiàn)需求安全要求和設(shè)計安全要求以及軟件實現(xiàn)過程中是否引入新的危險。
C. 分析要點:
軟件實現(xiàn)工具、軟件實現(xiàn)語言和軟件實現(xiàn)技術(shù)是本階段檢查的重點,例如在這一階段應(yīng)進行下列活動:
· 對控制邏輯中可能存在的問題進行評價,這些問題包括邏輯錯誤、遺漏的情況或步驟、重復(fù)邏輯、忽略的極端情況、不必要的功能、錯誤解釋需求、遺漏條件測試、未檢查變量和不正確的迭代循環(huán)等。
· 確認算法的正確性,包括準確度、精確度,以及方程的不連續(xù)性、超量程條件、斷點、錯誤的輸入、掃描速率等。
· 評價代碼中的數(shù)據(jù)結(jié)構(gòu)和使用,以便確信對數(shù)據(jù)項已適當定義和使用。
· 確認軟件模塊與硬件和其它軟件之間接口的兼容性。
· 確認軟件在由需求、設(shè)計和目標計算機系統(tǒng)對軟件提出的約束范圍內(nèi)運行,以便確保程序在這些約束范圍內(nèi)運行。
· 檢查非關(guān)鍵代碼,以便保證它不會對關(guān)鍵軟件的功能產(chǎn)生有害影響,作為通用規(guī)定,安全軟件與非安全軟件相隔離,檢查的目的是證明這種隔離是完整的。
· 核實良好的軟件實踐(例如代碼量的限制、可重復(fù)使用代碼的控制、代碼初始化等)的使用。
總的來說,在軟件實現(xiàn)階段,軟件開發(fā)人員更關(guān)心的是代碼的正確性。只要需求危險分析和設(shè)計危險分析全面,所編寫的代碼正確且完全實現(xiàn)了設(shè)計要求,就能保證安全。
SFTA、SHAZOP也適用于軟件實現(xiàn)危險分析,分析結(jié)果需形成文檔,成為軟件危險分析報告的一部分。代碼必須經(jīng)過安全驗證和測試,才能投入實際使用。
4.3 危險性測試
危險性測試核實各種危險要求(禁止、俘獲和聯(lián)鎖)已經(jīng)正確實現(xiàn),這種測試可驗證軟件在其規(guī)定的環(huán)境內(nèi)正確工作。在危險性測試中應(yīng)進行下述活動:
· 軟件單元級測試,以檢驗安全軟件各組成部分的正確執(zhí)行。
· 接口測試,以檢驗安全軟件各單元按預(yù)期要求運行。
· 計算機軟件配置項測試,以檢驗軟件作為一個單元的執(zhí)行情況。
· 系統(tǒng)級測試,以檢驗軟件在整個系統(tǒng)內(nèi)的性能。
· 承受能力測試,以檢驗軟件在異常情況下(例如未預(yù)期的輸入值)不會引起危險。
· 驗證測試工具是否引入新的危險。
危險分析方法是傳統(tǒng)模擬技術(shù)儀表控制系統(tǒng)中成功使用的一類方法,這類方法應(yīng)用于數(shù)字化保護系統(tǒng)還處于初級階段。核電站數(shù)字化保護系統(tǒng)軟件開發(fā)過程中不僅要考慮軟件的任務(wù)需求,也必須考慮安全需求,進行軟件危險分析。本文提出了軟件V&V危險分析的策略和程序,以軟件開發(fā)過程常用的瀑布模型為基礎(chǔ),論述了軟件開發(fā)各階段的危險分析工作,為開發(fā)安全的保護系統(tǒng)軟件提供了有益的思路。此方法應(yīng)用到工程實踐中,旨在為核電站數(shù)字化保護系統(tǒng)的設(shè)計與實現(xiàn)提供更加準確和全面的依據(jù)。該分析方法能夠給出軟件設(shè)計差錯或缺陷,并通過相應(yīng)措施,消除安全性隱患或?qū)④浖踩晕kU控制在最低可接受的范圍。
[1] AEA NS - G - 1.1, Software for Computer Based Systems Important to Safety in Nuclear Power Plants, 2000 [S].
[2] ANSI/IEEE Std 7 - 4.3.2 - 2010, IEEE Standard Criteria for Programmable Digital Devices in Safety Systems of Nuclear Power Generating Stations [S].
[3] ANSI/IEEE Std 577 - 2004, IEEE Standard Requirements for Reliability Analysis in the Design andOperation of Safety Systems for Nuclear Power Generating Stations [S].
[4] IEEE Std 352-1987 (Reaff 1999), IEEE Guide for General Principles of Reliability Analysis ofNuclear Power Generating Station Safety Systems [S].
[5] IEEE Std 1228-1994 (Reaff 2002), IEEE Standard for Software Safety Plans[S].
[6] MIL- STD - 882B, System Safety Program Requirements [S].
[7] 顏兆林, 龔時雨. 集成系統(tǒng)的軟件安全分析 [J]. 計算機工程,2005, ( 6 ) :141 - 142.
[8] HAF102 — 2004,核動力廠設(shè)計安全規(guī)定 [S].
Application Software Hazard Analysis of Reactor Protection System for the Nuclear Power Plant
During the digital process of the instrumentation and control equipment for the Nuclear power plant reactor protection system (RPS), how to ensure the safety of the nuclear safety class software is an important issue. The Hazard analysis is an effective way to improve the software’s safety by identifying potential hazards and taking appropriate measures to eliminate, prevent or control hazards. This technical method has widespread used in the traditional analog instrumentation control system, but for digital instrumentation and control system, there are no actionable guidance standards. This paper proposes a method of software V&V Hazard analysis which applies to RPS application software. And it discusses the software Hazard analysis during all phases of the software development for one type of Reactor’s RPS. This method provides a useful reference for relevant organizations to writing the actionable standard of software Hazard analysis.
NPP;Protection system;Verification and validation;Hazard analysis
周良(1981-),男,湖南湘鄉(xiāng)人,工程師,碩士,現(xiàn)就職于北京廣利核系統(tǒng)工程有限公司,主要從事核電站安全級DCS驗證與確認工作。