核電廠RPS應用軟件V&V危險分析的研究

★北京廣利核系統工程有限公司 周良，張磊，杜喬瑞，梁中起

核電廠RPS應用軟件V&V危險分析的研究

★北京廣利核系統工程有限公司 周良，張磊，杜喬瑞，梁中起

在核電廠反應堆保護系統（RPS）儀表控制設備的數字化過程中，如何保證核安全級軟件的安全性是一個重要問題。危險分析是識別系統潛在的危險，以及采取適當的手段來消除、防止或控制危險，提高安全性的一種有效方法。它在傳統模擬技術儀表控制系統中已經廣泛使用，但應用于針對數字化儀表控制系統的危險分析時，目前為止還沒有可操作的指導標準與規范。本文提出一種適用于核電廠RPS應用軟件V&V危險分析的方法，結合某堆型RPS具體論述了軟件開發各階段的V&V危險分析內容，可為相關組織制定可操作性較強的危險分析規范提供參考。

核電站；保護系統；驗證與確認；危險分析

1 引言

基于計算機的系統已經在核動力廠日益廣泛應用，它們對核動力廠安全的重要性也正在增加[1]。這類系統既用于安全有關級系統，也用于安全系統（例如反應堆保護或安全設施的驅動）。核電站反應堆保護系統屬于核電廠1E級儀表控制設備，用以保護三大核安全屏障（即燃料包殼、一回路壓力邊界和安全殼）的完整性。

在核電站保護系統儀表控制設備的數字化過程中，一個必然要解決的重要問題是核安全軟件的安全性。特別是福島核電站事故發生后，國家安全監管當局根據核行業法規，對后續新建核電站數字化保護系統的安全性提出更高要求。從系統的觀念出發，運用科學分析方法識別、評價、控制危險，使系統達到最佳安全。

識別系統潛在的危險，以及采取適當的需求、設計和其它制約因素來消除、防止或控制發現的危險的一個過程就是危險分析[2]，以達到預防事故、實現系統安全的目的。人們在實踐中形成了多種與傳統模擬儀表控制系統有關的危險分析技術，并形成了一些重要的與危險分析相關的標準或規范（例如IEEE Std 577TM-2004[3]，IEEE Std 352TM-1987[4]，IEEE Std1228TM-1994[5]和 MIL-Std-882B[6]）。而目前為止還沒有可操作的軟件危險分析的程序與規范，因此研究適合核電站數字化保護系統軟件危險分析的程序與規范以及相關的各項技術意義重大。

2 軟件危險性內涵

危險性多用于刻畫具有能量、毒性或能夠進行質量運動的物理設備或系統，與硬件設備不同，軟件作為一種寄生性邏輯實體，軟件自身不會直接對人造成傷害或對環境造成破壞。盡管作為系統重要組成要素的軟件不會直接危及生命、財產和環境等安全，但由于軟件設計存在缺陷，軟件運行時控制設備運行不當或者軟件未能控制設備運行，會形成危險。

目前標準沒有明確給出軟件危險性的定義，根據對軟件危險性的理解，給出軟件危險性的下述定義：

軟件危險性是指特定軟件對特定系統危險性的貢獻，衡量的是在特定環境下和規定時間內因軟件功能失效或需求缺陷等引發系統危險的能力。其中系統危險性受到軟件（SW）、硬件（HW）、人員（Human）、外部環境（Env）的共同作用。外部環境泛指與該系統交互作用的外部系統或其他因素。比如，對于反應堆保護系統軟件而言，其危險性研究涉及到保護系統軟件內部組件之間的交互，保護軟件與保護系統底層硬件之間的交互，保護軟件與操縱員、非安全級系統等其它系統之間的交互。

保護系統中事故的發生是硬件（設備）部分、人員、外部環境和軟件共同作用的結果。事件是事故的重要因素，包括引發事件、中間過程事件和后果事件。引發事件是事故過程中的第1個不希望事件，其發生標志著事故過程的開始；后果事件是造成某種惡性后果的不希望事件，它直接導致人員傷亡、財產損失、環境破壞等損失；事變事件是指在引發事件后可能發生的惡性事件，如果未得到緩減控制，這些事件將導向后果事件。引發事件、事變事件和后果事件都是事故場景過程中的一個環節，都是系統運行中的不期望事件。[7]軟件之所以導致事故，就是因為軟件中潛在的缺陷造成引發事件發生，或致使緩減控制措施失效。盡量避免上述情況的出現正是軟件危險分析的目的。

3 軟件危險分析框架

保護系統的軟件危險分析應當與整個系統設計緊密結合，成為系統危險分析的一部分。系統軟件危險分析的目的是精確地分析和評估系統軟件引發的真實危險，并采取相應的措施，以確保把這種危險的發生概率降低到最低可接受的程度。

為了進行危險分析，必須建立相應的分析程序，以便系統、全面地規劃危險分析工作。本文依據保護系統的特點以及工程經驗，提出了一種適用于保護系統的軟件V&V危險分析的策略和程序，如圖1所示。

（1）分析策略

危險分析的成功很大程度取決于良好的方案，應使危險分析作為系統設計過程的一個組成部分，在框架下滲入各級組織的活動。在系統研制成功以后則把危險分析作為改進過程的組成部分，從而使危險分析成為生命周期的組成部分。制定“危險分析”方案幫助危險分析過程的順利開展。

（2）分析程序

危險分析貫穿系統全生命周期。在不同的生命階段，系統設計的詳細程度不同，分析人員可利用的數據不同，因此危險性分析的過程及其詳細程度也不一樣，應該是一個不斷深入、不斷細化的迭代過程。軟件危險分析人員不僅必須理解軟件在系統運行中的各種作用，而且必須知道軟件運行時對系統安全的影響。

圖1所示的分析程序不僅給出了各項分析工作的關系，而且也給出了各項工作的角色。

下面，按分析程序論述各項分析工作。

4 RPS應用軟件V&V危險分析過程

4.1 系統設計危險分析

（1）安全功能

反應堆保護系統危險的識別過程開始于對要求的安全功能、設計基準工況、選定的系統設計要素（如子系統、多樣化系統等）和法規標準要求的理解。根據分析結果，可確定計算機系統的某些安全功能、設計條件、限制及未解決的危險。

反應堆保護系統指監測反應堆的運行，并根據接收到的異常工況信號，自動觸發動作以防止發生不安全或潛在的不安全工況的系統。[8]反應堆保護系統主要包括反應堆事故停堆系統（RTS）和專設安全驅動系統（ESFAS）。其中運行的核安全級軟件也必然要包括兩部分，一部分用于執行反應堆停堆功能，當需要時產生控制動作觸發反應堆停堆。另一部分用于執行專設安全設施驅動功能，安全設施包括驅動單元及適當的設備布置，根據驅動系統或者操作員發出的信號實現保護功能。

（2）功能危險分析

A. 分析對象：包括系統設計、專項功能設計、子系統設計等技術規格書。

B. 分析目標：由總體人員進行系統危險性分析，獲得與軟件相關的系統危險模式，確定影響系統運行的關鍵危險事件，及其應對措施。

C. 分析要點：

RPS系統設計危險分析應考慮安全功能的要求，進行功能危險分析，只是把重點放在硬件和軟件的初步設計上。例如應把下述各項作為可能的危險：

· 硬件和軟件之間的相互依賴性（例如中斷和操作系統）；

· 可能使系統進入危險狀態的動作序列，系統架構對可靠性指標分配的影響；

· 系統特有的可信危險，例如超前或滯后的輸出、傳感器輸入處理故障、準確度和舍入問題、例外情況的不恰當處理、恢復動作、系統中斷、輸入電壓或頻率的波動、符合信號改變的最大可信數目、電磁干擾和超量程數值（如被零除或未初始化的指示）、CPU重啟、程序下裝。

系統功能危險分析，主要致力于RPS中相應軟件的功能安全性分析。

RRS系統設計應規定為了阻止系統進入危險狀態或者使系統從危險狀態進入到非危險狀態而需要由硬件或軟件完成的那些功能，而且應識別和規定軟件和計算機系統之間的接口。

RPS系統的危險識別由粗到細，逐步細化。危險的識別通過制定初步危險表（PHL）來完成，從而為初步危險分析（ PHA）確定了范圍。在系統設計的早期進行PHA，可以確定構成系統中事故的潛在條件和可能的事故，但此時的分析是不詳細的，不能準確地描述事故發展的過程，在系統設計階段，分系統設計一旦確定，就需進行分系統危險分析。分系統危險分析深入到具體的分系統內部，通過選擇具體的危險分析技術，FMEA、FTA等來確定造成潛在條件的原因和事故發展過程。

4.2 軟件開發危險分析

（1）軟件需求危險分析

A. 分析對象：軟件需求規格書，內容包括軟件頂層架構、軟件接口設計、軟件功能和性能需求。

B. 分析目標：在系統設計危險分析的基礎上進行軟件需求危險分析，確定系統不應做什么，即軟件應滿足哪些安全需求，同時提出軟件確認測試計劃中的安全要求。

C. 分析要點：

在軟件需求的危險識別過程中評價軟件和接口需求，并識別出可能成為危險產生原因的差錯和缺陷。此階段首先確定與安全功能相關的每一項軟件需求，識別由于需求不滿足可能導致的事故，并評估相應的風險。如果風險不可接受，則系統設計必須進行一定的更改，使得軟件在所有的運行模式和條件下，其性能、功能和接口設計都能達到所要求的安全水平。

在進行軟件需求危險識別時應將軟件需求與硬件設計的相容性作為一個基本問題。例如包括下述活動：

· 分析I&C功能分站對可靠性指標的影響。

· 確信沒有引入有害的“未預期功能”。例如無用的駐留功能、對外部或內部條件的不可預測響應、由于設計或實現錯誤產生的缺陷、未從軟件中消除的研制輔助手段。

軟件故障樹（SFTA）、故障模式和影響分析（FMEA）等技術都可用來進行需求危險分析。需求危險分析結果是下一步設計危險分析的基礎。

（2）軟件設計危險分析

A. 分析對象：軟件設計階段工作一般分為概要設計和詳細設計二個階段。

B. 分析目標：檢查軟件設計是否體現了安全需求以及在設計過程中是否引入新的安全需求。

C. 分析要點：

一項軟件需求可能由多個設計部分（如模塊、文件等）來完成；每一個設計部分也可能與多項軟件需求相關，需求部分和設計部分之間存在多對多的映射關系。如果設計部分風險不可接受，則需要考慮重新設計，以降低設計的風險，或采取其它措施以降低整個應用系統的風險。

某些系統的設計危險分析還涉及到軟件所運行的計算機系統的硬件體系結構。此時還需要考慮硬件體系結構設計是否會引入復雜的功能，是否存在新的失效模式。這些新的失效模式在系統危險分析和需求危險分析時不能發現，但在設計分析階段必須予以識別。

軟件設計階段的危險識別所包括的活動應確信沒有引進新的危險。例如在這一階段應進行下列活動：

· 應對可能存在的計算問題進行評價，這些問題包括錯誤的算法、不夠的精度（錯誤的數據類型）、掃描速率和符號約定錯誤。

· 對控制邏輯中可能存在的問題進行評價，這些問題包括邏輯錯誤、遺漏的情況或步驟、重復邏輯、忽略的極端情況、不必要的功能、錯誤解釋需求、遺漏條件測試、未檢查變量和不正確的迭代循環等。

· 對數據結構和預期使用中的數據從屬性進行評價，這種從屬性損害隔離分區、數據別名使用和故障抑制問題，從而會影響安全和對危險的控制或緩解。

· 應對接口設計進行審查，包括內部接口以及同系統其他模塊之間的外部接口，對接口關注的主要方面是適當規定的協議以及控制和數據鏈接。對外部接口應進行評價，以便核實設計中的通信協議同接口要求是相容的，接口的評價應支持冗余管理分區和危險抑制的要求，可能存在的接口和定時問題包括錯誤地處理接口、不正確的輸入和輸出時序，以及子程序/模塊不匹配。

· 應確信設計符合已確定的系統限制。

· 應對非安全模塊進行評價，以便確信它們不會對安全軟件產生有害的影響。

本階段主要的危險分析技術有SFTA、SHAZOP。設計危險分析的結果確定了軟件實現危險分析的重點，為下一步的軟件實現危險分析提供輸入。

（3）軟件實現危險分析

A. 分析對象：源代碼和可執行代碼。

B. 分析目標：軟件實現危險分析主要檢查在實現需求安全要求和設計安全要求以及軟件實現過程中是否引入新的危險。

C. 分析要點：

軟件實現工具、軟件實現語言和軟件實現技術是本階段檢查的重點，例如在這一階段應進行下列活動：

· 對控制邏輯中可能存在的問題進行評價，這些問題包括邏輯錯誤、遺漏的情況或步驟、重復邏輯、忽略的極端情況、不必要的功能、錯誤解釋需求、遺漏條件測試、未檢查變量和不正確的迭代循環等。

· 確認算法的正確性，包括準確度、精確度，以及方程的不連續性、超量程條件、斷點、錯誤的輸入、掃描速率等。

· 評價代碼中的數據結構和使用，以便確信對數據項已適當定義和使用。

· 確認軟件模塊與硬件和其它軟件之間接口的兼容性。

· 確認軟件在由需求、設計和目標計算機系統對軟件提出的約束范圍內運行，以便確保程序在這些約束范圍內運行。

· 檢查非關鍵代碼，以便保證它不會對關鍵軟件的功能產生有害影響，作為通用規定，安全軟件與非安全軟件相隔離，檢查的目的是證明這種隔離是完整的。

· 核實良好的軟件實踐（例如代碼量的限制、可重復使用代碼的控制、代碼初始化等）的使用。

總的來說，在軟件實現階段，軟件開發人員更關心的是代碼的正確性。只要需求危險分析和設計危險分析全面，所編寫的代碼正確且完全實現了設計要求，就能保證安全。

SFTA、SHAZOP也適用于軟件實現危險分析，分析結果需形成文檔，成為軟件危險分析報告的一部分。代碼必須經過安全驗證和測試，才能投入實際使用。

4.3 危險性測試

危險性測試核實各種危險要求（禁止、俘獲和聯鎖）已經正確實現，這種測試可驗證軟件在其規定的環境內正確工作。在危險性測試中應進行下述活動：

· 軟件單元級測試，以檢驗安全軟件各組成部分的正確執行。

· 接口測試，以檢驗安全軟件各單元按預期要求運行。

· 計算機軟件配置項測試，以檢驗軟件作為一個單元的執行情況。

· 系統級測試，以檢驗軟件在整個系統內的性能。

· 承受能力測試，以檢驗軟件在異常情況下（例如未預期的輸入值）不會引起危險。

· 驗證測試工具是否引入新的危險。

5 結語

危險分析方法是傳統模擬技術儀表控制系統中成功使用的一類方法，這類方法應用于數字化保護系統還處于初級階段。核電站數字化保護系統軟件開發過程中不僅要考慮軟件的任務需求，也必須考慮安全需求，進行軟件危險分析。本文提出了軟件V&V危險分析的策略和程序，以軟件開發過程常用的瀑布模型為基礎，論述了軟件開發各階段的危險分析工作，為開發安全的保護系統軟件提供了有益的思路。此方法應用到工程實踐中，旨在為核電站數字化保護系統的設計與實現提供更加準確和全面的依據。該分析方法能夠給出軟件設計差錯或缺陷，并通過相應措施，消除安全性隱患或將軟件安全性危險控制在最低可接受的范圍。

[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] 顏兆林, 龔時雨. 集成系統的軟件安全分析 [J]. 計算機工程，2005, ( 6 ) ：141 - 142.

[8] HAF102 — 2004，核動力廠設計安全規定 [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-），男，湖南湘鄉人，工程師，碩士，現就職于北京廣利核系統工程有限公司，主要從事核電站安全級DCS驗證與確認工作。