核電廠保護系統軟件危害分析輔助模型的構建方法研究

張杰穎 ,李 亮 ,張亞棟 ,杜喬瑞 ,張冬偉

(1.北京廣利核系統工程有限公司，北京 100089；2.生態環境部核與輻射安全中心，北京 102400)

0 引言

核電廠基于計算機的保護系統(數字化保護系統)功能主要通過其軟件實現相關設備安全功能必需的特點或特征。對執行安全功能的軟件進行獨立的驗證與確認，是保證軟件質量的必要手段之一[1]。危害分析是軟件驗證中的一項分析任務。識別危害是危害分析的第一步。基于數字化保護系統結構特點、軟件關鍵特性和軟件開發特點，從保護功能信號流邏輯路徑上可能引入的不希望的信號變化入手，構建關于每個功能的、以識別潛在危害為目的的多維度軟件質量度量模型。該思路奠定了建模方法的理論基礎。基于采用該理論構建的軟件質量度量模型已經過工程實踐檢驗，可大大提高危害分析效率和作業質量，對輔助危害分析具有重要意義。

1 危害分析輔助模型的構建意義

1.1 軟件與數字化保護系統的置信度

核電廠保護系統是監測反應堆運行，并根據接收到的異常工況信號自動觸發動作，以防止發生不安全或潛在不安全工況的系統[2]。與單純的硬件模擬系統相比，核電廠數字化保護系統是由軟件和硬件組成的可編程系統，軟件的實現更復雜，也更容易發生設計錯誤，軟件對“小”錯誤更敏感[3]。系統在設計上采用了更大范圍、更高程度的共享技術(除了更大程度上共享設備外，還共享代碼和數據)，代碼、數據共享使得軟件有傳播共因故障的可能，從而可能導致冗余硬件失效[4]。同時，由于系統分配給軟件實現的功能組合在一個或多個處理單元中，致使一個處理單元中的組合功能可能出現非常難以分析的情況，且一個處理單元的故障會導致單元中多個功能同時失效。此外，一個功能也可能會通過不希望的交互影響另一個功能的執行。因此，軟件的置信度會影響數字化保護系統的置信度。

1.2 危害分析與輔助模型

為了保證數字化保護系統軟件設計質量與所需的安全功能相適應，提高軟件置信度，必須在軟件開發中應用軟件驗證與確認技術[2]。常規的軟件驗證與確認是根據核電廠設計基準要求，通過設計評審和測試評估不同失效組合及其對系統的影響，以確認系統是否滿足設計需求[5]。而軟件驗證中危害分析的范圍不僅包括電廠設計基準事件，還包括異常事件、工廠設備和系統降級運行[5]。分析人員將危害分析結論(含軟件薄弱點)傳遞給軟件設計人員，促進軟件設計變更，并通過迭代分析確認針對危害的解決方案。

危害分析輔助模型又稱危害導出模型，涵蓋了識別危害的7個軟件功能特性。7個軟件功能特性包括功能性(functionality)、準確性(accuracy)、可靠性(reliability)和魯棒性(robustness)、容量(capacity)、安全性(safety)和安保(security)，因此危害分析輔助模型可簡稱為FARCS度量模型。基于數字化保護系統模塊化結構特點、軟件關鍵特性和軟件開發特點構建，以7個軟件功能特性為維度度量軟件質量，并在不同維度下基于多個考量標準(完備性、一致性、正確性、可追溯性、無歧義、可核實性、樣式等)、針對功能信號可能的突變部位，構建軟件設計過程中由系統環境、操作員/用戶、軟件組件、硬件組件及其連接可能引入的潛在危害度量模型，能夠更全面、系統地識別危害,為后續的危害分析工作奠定良好基礎。

2 建模理論基礎

2.1 數字化保護系統結構特點

根據HAD102/16—2004[3]中的定義“計算機系統結構是計算機系統的硬件部件(處理器、存儲器、輸入輸出設備)，它們的連接，通信系統以及軟件功能在這些部件上的映像”，對于由軟件和硬件組成的核電廠數字化保護系統，硬件是軟件的載體，軟件的各種進程、數據存儲、邏輯通信路徑、數據顯示屏布局通過映射與硬件建立聯系。軟件不是獨立存在的。軟件組件的表現形式是系統組件。

核電廠保護系統應用軟件中包含大量軟件邏輯。每條軟件邏輯路徑對應一個功能回路，即對應一個系統功能。單個功能的觸發往往需要一定數量的探測信號以達到閾值條件。探測信號由系統通過輸入單元(輸入設備)采集現場儀表信號獲得，通過中央處理單元(處理器)進行閾值等算法處理。處理結果通過人機接口單元(輸入輸出設備)傳輸給系統操作員，并通過輸出單元(輸出設備)輸出至現場對應設備。各系統組件間的信號傳輸通過通信單元和系統總線完成。

2.2 數字化保護系統軟件開發特點

數字化保護系統軟件開發遵循預定義的生命周期[6]，參考HAD102/16—2004，核電廠數字化保護系統軟件開發生命周期始于系統需求階段，歷經系統設計、軟件需求、軟件設計、軟件實現、系統集成、安裝和調試、運行和交付后修改這幾個階段。因此，必須對計算機系統設計、軟件需求、軟件設計和軟件實現階段的產品實施驗證[3]。軟件驗證中的危害分析與設計活動如圖1所示。

圖1 軟件驗證中的危害分析與設計活動

對基于計算機的系統的開發，HAD102/16—2004提出了自頂至底分解、抽象化層級和模塊化結構的開發原則。在這種開發原則下，從概念提出到過程實現是設計不斷深化、細化的過程。因此，隨著設計的進展，危害分析的顆粒度會逐漸細化并與設計對象相匹配。

2.3 數字化保護系統軟件關鍵特性

核電廠數字化保護系統是人機相結合的系統，包含軟件、硬件和操作員。軟件關鍵特性可分為功能特性和過程特性[7]。其中，功能特性直接與功能相關，包括功能性、準確性、可靠性、魯棒性、時間、安全性和安保。軟件功能特性如表1所示。過程特性是確保功能執行的軟件開發過程特性，包括完備性、一致性、正確性、可追溯性、無歧義、可核實性和樣式。軟件過程特性如表2所示。為便于描述，將系統設計到軟件實現各階段的設計輸出稱為軟件產品。軟件產品包含軟件文檔、軟件代碼。

表1 軟件功能特性

表2 軟件過程特性

作為安全系統的核電廠數字化保護系統具有確定性的運行特性。系統的數據通信具有確定的傳輸時間，且在系統規格書范圍內對于任何給定的輸入信號序列將始終產生相同的輸出和響應時間[8]。

3 建模方法

3.1 方法概述

依據HAD102/16—2004“應對計算機系統的結構和功能進行危害分析，以便確定可能危及安全功能的任何特定風險，并指出需要更改的結構或附加功能(例如自檢)以減緩危害的影響”，危害分析是識別、評估危害并提供緩解或消除危害影響方法的一項分析。其目標是保證軟件完成系統分配給軟件的功能以及系統功能的實現不受任何潛在危害的影響。

功能實現是危害分析中的重點。核電廠數字化保護系統屬于大型復雜系統。根據數字化保護系統承擔的功能(總功能)將系統逐步分解為子系統，然后再將子系統分解為多個功能回路。每個回路承擔特定子功能。系統分配給軟件實現的功能由軟件邏輯路徑上不同的軟件組件共同完成。這些軟件組件以對應的硬件部件為載體。功能的實現不僅與其自身質量相關，還受其硬件載體及硬件載體間連接的影響。因此，可在每個開發階段將關系系統功能實現的軟件危害分析轉化為與該功能實現相關的、影響軟件/系統組件功能實現的潛在危害分析。

3.2 方法具體實施

對應系統設計階段的FARCS度量模型如圖2所示。

圖2 對應系統設計階段的FARCS度量模型

圖2中，根據軟件功能特性定義，軟件/系統組件可能是信號輸入單元、通信單元、處理單元、輸出單元、人機接口單元或它們的任意組合。

將軟件功能特性作為識別危害的質量度量指標，而將保證軟件功能實現的過程特性在識別危害時作為判據使用。例如：可將識別到的系統規格書內容相關的“每種運行模式下的功能描述不全”(涉及軟件功能特性的“功能性”，軟件過程特性的“完備性”)作為軟件“功能性”度量維度下關于“完備性”不足而引入的潛在危害。

在數字化保護系統中，輸入信號在離散的時間點進行采集。采集的輸入信號在系統組件間周期性地傳輸，并周期性地產生并輸出信號。如果數字化保護系統的設計不正確，系統處理負載或通信負載的變化可能會影響信號傳輸速度和響應時間。由此可見，軟件實現其特定目標的能力受到存儲空間(負載率相關)的限制。因此，考慮將存儲空間作為度量軟件質量的一個指標，并將其與功能特性中的“時間”合并為一個質量度量指標“容量”。

綜上所述，在從系統設計到軟件實現的每個開發階段，從功能性、準確性、可靠性、魯棒性、容量、安全性和安保這7個功能特性維度度量軟件產品；針對每個度量指標，又分別從完備性、一致性、正確性、可追溯性、無歧義、可核實性和樣式這7個過程特性維度考察軟件中是否存在使指標惡化的潛在危害。通過軟件功能特性與過程特性的共同度量，形成一個關于軟件潛在危害的度量矩陣，并通過FARCS度量模型展示。

被度量的每個開發階段的軟件產品是核電廠數字化保護系統總功能層層分解后得到的單個功能所對應的軟件/系統組件，一般包含輸入單元、通信單元、處理單元、輸出單元、人機接口單元。

根據軟件功能特性的含義(見表 1)，每個功能特性相關的軟件/系統組件不同，如“功能性”涉及處理單元，“準確性”涉及輸入單元、處理單元、輸出單元、人機接口單元。由于電源是軟件/系統組件工作的使能組件，電源故障、電壓/頻率波動能夠影響軟件/系統組件功能的實現，因此將電源質量也納入相關軟件質量度量維度下的考察指標。圖2是對應于系統設計階段的FARCS度量模型，只列出了每個軟件/系統組件的功能特性以及不同功能特性下能夠判斷危害是否產生的軟件過程特性，未列出軟件/系統組件電源異常情況。對應于軟件需求階段、軟件設計階段和軟件實現階段的FARCS度量模型與此類似。

4 模型優勢

FARCS度量模型以核電廠數字化保護系統模塊化結構為基礎。系統自頂至底分解、抽象化層級、模塊化結構開發的特點使軟件/系統組件與通過功能分解得到的單個功能間能夠建立聯系，從而可以將單個功能失效歸因為相關軟件/系統組件及其連接、所處環境引入到功能回路中的潛在危害。從系統設計到軟件實現階段，對于每個開發階段中的軟件/系統組件設計，設計深度不同則對應的設計對象或設計對象顆粒度不同。軟件功能特性(結果)結合軟件過程特性(過程)的軟件質量度量方法能夠統一危害識別思路，使危害識別覆蓋率更高并且系統化。

5 模型實例及其應用方法

核島一回路穩壓器壓力超過高3限值(閾值)觸發緊急停堆，是保護系統適應核電廠工況完成的一項重要安全保護功能。國內某核電廠數字化保護系統采用基于FirmSys平臺的安全級分布式控制系統(distributed control system,DCS)。FirmSys平臺為安全級DCS軟件開發人員提供了面向應用的語言編程環境。該開發環境決定了由系統設計文檔和軟件需求文檔中的錯誤引入到系統中的潛在危害遠比軟件設計文檔和代碼中的錯誤本身對整個系統的危害大得多。因此，在安全級DCS軟件驗證的危害分析中，將危害識別的重點放在系統設計和軟件需求階段，而在軟件設計和實現階段主要關注因編程語言不合規而產生的相關危害。下面以對軟件需求文檔(軟件需求階段輸出的軟件產品)的危害分析引出FARCS模型實例并介紹模型應用方法。

軟件需求邏輯如圖3所示。圖3中，一個輸出信號、與輸出信號具有邏輯相關性的采集信號及它們間的處理邏輯共同組成一個軟件邏輯路徑，對應一個系統功能。取決于信號源，采集信號可能由系統輸入單元、系統間通信單元、人機接口單元獲得，輸出信號通過系統輸出單元、系統間通信單元、人機接口單元輸出到現場設備、其他系統或系統操作員，采集信號與輸出信號間的功能邏輯在系統處理單元中計算處理。將軟件邏輯路徑映射到系統硬件組件及其連接，對應系統輸入單元、通信單元、處理單元、輸出單元、人機接口單元及存在輸入輸出關系的各系統組件間的連接。軟件需求危害分析的范圍是系統負責完成的保護功能(系統功能)、對應保護功能回路，與保護功能相關的輔助功能不作為分析的重點，其他功能(如單純的顯示、報警功能)則被排除在危害分析范圍外。

圖3 軟件需求邏輯

以RPC1子組2反應堆停堆觸發功能的軟件需求邏輯為例。保護功能軟件需求邏輯如圖4所示。

對圖4中的9個輸出信號進行分析，只有HDO3信號為保護功能信號，是反應堆停堆功能回路的輸出信號。分析與HDO3信號相關的采集信號，HAI1、HDI1信號來自于系統輸入單元，分別為現場的穩壓器壓力儀表RCP005MP探測信號、壓力儀表RCP005MP維護時使用的旁通信號；NDI1～NDI8 2組8個信號來自于系統間通信單元，分別與穩壓器壓力信號RCP006MP、RCP013MP相關，并分別從RPC2子組2、RPC3子組2通信傳輸進入RPC1子組2。上述信號及其相關邏輯共同完成反應堆停堆功能，是危害分析的主要對象，如圖3所示。其余信號及相關邏輯(完成反應堆停堆功能相關的顯示功能、系統間信號傳輸功能)為反應堆停堆功能的輔助功能。

圖4 保護功能軟件需求邏輯圖

針對圖3所示的軟件需求邏輯，軟件驗證/分析人員可通過本文介紹的建模方法構建FARCS度量模型。建模時，分析并列出模型中每個度量維度下反應堆停堆功能軟件邏輯路徑上所有可能的潛在危害(異常的信號變化)，注意考慮系統運行環境以及可能的人員誤操作、設計錯誤的影響，例如系統各種運行模式下功能的觸發/執行/結束異常、數據處理異常、系統平臺自診斷信息未及時上報給操作員/用戶、違背行業設計準則等。

軟件危害分析宜將輸入信號作為分析的起點，以信號流向及傳輸路徑為導向、以輸出信號為終點開展分析。圖3中，與反應堆停堆功能信號HDO3直接相關的2/3D1(3取2)算法模塊稱為主算法模塊。3取2算法模塊有6個輸入信號，其中3個輸入信號為其他算法模塊的輸出信號，因此3取2算法模塊共涉及11個輸入信號。對于3取2算法模塊涉及的11個輸入信號，在危害識別和判斷時均要從數字化保護系統信號采集開始。

FARCS度量模型構建完成后，軟件驗證/分析人員在模型的引導下結合其他圖紙，如接口信號所在的其他軟件需求邏輯圖、接口信號相關的硬件接口圖、FirmSys硬件產品手冊、系統設計規格書、FirmSys軟件產品手冊等，逐項、依次識別圖3中軟件需求邏輯中是否存在模型中列出的潛在危害。對于多個采集信號，根據其信號來源確定每個采集信號對應到FARCS模型中的系統單元(輸入單元、通信單元、人機接口單元)。對于每個潛在危害，均在假定不存在其他潛在危害的條件下(即遵循單一故障準則)，展開分析和判斷。逐項定性分析、判斷每個度量維度下的每個軟件/系統組件相關的潛在危害。如果軟件需求邏輯中存在模型中列出的潛在危害，則需要軟件驗證/分析人員結合需求邏輯，評估所存在危害的影響后果，確定是否需要在軟件中解決。如果潛在危害需要在軟件中解決，則要對軟件需求邏輯進一步分析，判斷需要在軟件中解決的潛在危害是否在軟件中設計了預防或緩解措施，最后給出軟件質量評估結果、提出軟件改進建議。

6 結論

全面、準確地識別可能存在于核電廠數字化保護系統中的潛在危害是進行危害分析的必要條件，要求分析人員具備多方面的能力，如了解系統運行環境、熟悉整個系統結構及接口、清楚軟件功能實現原理、理解并精通法規標準對系統的設計原則要求，并需具備豐富的功能安全、軟件工程、系統設計和維護等方面的經驗。在危害分析中使用FARCS度量模型輔助分析，可以避免由分析人員導致的對較重要的潛在危害的遺漏，識別軟件設計中的每個薄弱點；同時，能夠顯著縮短危害分析所耗費的時間，提高分析效率。

軟件驗證與確認是系統工程的一門技術學科，能夠幫助開發組織在軟件生命周期內提高軟件質量[9]。本文介紹的模型構建方法不僅有利于核電廠保護系統軟件驗證中的危險分析，而且為軟件工程領域各行業軟件的質量度量提供了思路，對相關研究具有借鑒和啟示意義。