核電廠安全級軟件的獨立驗證與確認

樊曉東

（國核工程有限公司，上海 200233）

三代核電的代表堆芯APl000系列采用非能動安全理念，通過簡化電廠配置，降低對能動裝置的需求，進一步提高了核電廠的安全性。全廠唯一的安全級儀控系統—保護和安全監測系統(PMS)采用全數字化儀控平臺，簡化了控制邏輯，提高了集約化、智能化水平。為進一步提高核電運行的安全性、可靠性及經濟性，核電廠儀控系統的主流趨勢是從模擬系統向數字系統過渡。數字化儀控系統由于硬軟件集成度高，系統質量驗證的難度大為提高。其中軟件準確性、可靠性保證主要依靠的是貫穿整個安全級軟件生命周期的質量管理，主體工作為獨立驗證與確認（IV & V）。

1 安全級軟件開發的質量管理

1.1 安全級軟件的特點

以AP1000保護與安全監測系統為例，核電廠數字化保護系統實現反應堆事故停堆功能、專設安全觸發功能以及1E級數據處理功能。安全級儀控系統的軟件用于驅動硬件實現核電廠安全功能。根據設計要求，為保證可以對軟件功能進行可靠驗證，保護與安全監測系統中運行的軟件必須采用明確的模塊化功能結構，基于安全功能單元實現。為了便于驗證與測試，每一個安全功能單元內部按照數據處理的不同邏輯以子模塊的形式劃分，一般情況下，每一個安全功能單元都要經過信號輸入、初步處理、表決邏輯、優先級選擇及數據控制等幾個步驟，這些都需要通過軟件來實現。軟件是數字化儀控系統相較基于模擬技術實現的儀控系統的最大不同。軟件錯誤僅靠系統集成后的外部功能測試是難以被完全識別的，因而軟件設計者必須關注軟件開發過程中的質量控制，與整個軟件開發過程緊密結合、貫穿軟件全生命周期的獨立驗證與確認活動是保證軟件功能完備、具有高可信度、高質量水平的重要手段。

1.2 安全級系統軟件IV & V活動

在基于核質保體系的管理框架下，針對安全級軟件的IV & V要求嚴格按照既定程序對軟件對象進行質量控制，是平行于整個軟件開發工作中的長期獨立的任務。IV & V工作必須覆蓋軟件設計、開發、測試、維護整個生命周期，以驗證符合性且排除潛在問題，涵蓋從最初的軟件定義到后期的維護升級的全程，并且需要同時考慮軟件本身以及其與整個系統的集成。

1.3 IV & V活動相關法規標準要求

保護與安全監測系統是在AP1000核電廠中唯一的安全級系統，集成了電廠所有的安全功能的控制功能，直接關系到整個核電廠的安全。原則上，軟件開發包括IV & V活動必須遵循我國核安全法規相關規定以及被其背書的行業標準，這意味著每項具體的V & V活動均需對照相應的要求進行全面策劃并精準執行。我國核安全法規HAF102中針對核安全級軟件的開發明確提出了獨立驗證與確認要求，并在核安全法規配套的導則HAD102第16分卷中提供了指導性的參考模型。在實際運用中，HAD102/16因缺乏具體的實施細則指導，實踐性較差，因此國內外廠家在開展軟件IV & V活動過程中更多是使用成熟的行業標準，如IEC 60880—2006以及IEEE 1012—2004等。在AP1000安全級儀控系統軟件開發過程中，相應的IV & V活動參照IEEE體系開展。

1.4 IV & V團隊的組織要求

獨立性是安全級軟件IV & V工作的前提，只有確保相關活動在技術、財務以及行政上的獨立性，才能使IV & V發揮作用，給出客觀有效的結論。AP1000儀控系統供貨商在軟件開發實踐中組建了在行政、財務和技術方面（指的是測試技術）獨立于研發部門的V & V團隊，以實現IEEE標準中對IV & V獨立性的要求。事實上，IV & V團隊在開展相關工作時需要與設計研發團隊緊密合作，然而IV & V獨立性要求又使得V & V團隊必須與研發團隊在業務上進行隔離，因此相關管理架構的制定一般需要由企業高級別管理者直接介入。

2 貫穿軟件全生命周期的IV & V活動

為了規范數字化核電廠安全級系統軟件的獨立驗證與確認工作，美國核管會通過引用IEEE的相關標準推出了一些可被用于開發安全級軟件的過程模型。AP1000保護與安全監測系統(PMS)的軟件開發過程應用了其中的瀑布模型。相應的，其IV & V活動參照IEEE 1012—1988標準中的各項要求開展。瀑布模型將軟件系統開發的生命周期過程分為定義階段、需求階段、設計階段（也可以進一步拆分為概念設計、基礎設計和詳細設計）、開發階段、測試階段以及運維階段。此模型通過將復雜的軟件開發過程劃分為承上啟下、互相作用的幾個階段，以便開發團隊根據不同的階段制定開發計劃以及相對應的IV & V計劃，提高了管理效率。

2.1 定義階段

項目定義階段又稱項目啟動策劃階段，軟件開發項目定義階段主要工作內容為項目范疇定義、初步項目開展計劃以及確定初始需求基線。從IV & V的角度來看，此階段的主要任務是確定IV & V工作范圍以及初步開展計劃，主要有以下幾個工作內容：①通過項目大綱確定IV & V的工作內容，制定軟件IV & V計劃；②確立IV & V團隊與項目管理團隊的聯絡接口以及管理關系；③審核初步需求基線，確定所有制定的系統要求與用戶的需求文件（系統規格書）相符，所有的要求足夠明確，可以通過測試或分析來驗證。

2.2 需求核對階段

需求核對階段開展的基礎是系統需求文件的發布，安全級軟件項目需求文件一般以系統規格書的形式出現。其V & V活動主要是驗證設計團隊根據上級系統需求文件制定，細化的各類技術要求文件是否覆蓋了系統設計規格書中所有的需求。從宏觀層面看，軟件需求包括軟件功能邏輯需求、硬件對軟件需求和軟件集成需求。在開展此階段工作時開發者需確認這3方面的需求是否滿足系統需求說明，同時也要確保識別的需求可以通過某種方法進行有效的驗證。因此需求驗證的關鍵任務之一是要制定出一個可追溯的技術要求體系，建立所有技術要求與上級需求間的映射關系，從而便于驗證與確認工作的開展。

2.3 系統設計階段

系統設計階段的軟件IV & V工作主要是針對各模塊的概要設計與詳細設計的驗證，通過審查、評估等活動，確認軟件的設計實現了需求核對階段所制定的軟件功能要求，這不僅包括了功能性需求，同時也包括非功能性需要。在針對安全級軟件設計文件進行審核的過程中，除了可以采用軟件設計規范以及系統技術要求規范書進行審查外，還需依據核領域的國家法規和行業標準進行審查，以保證所設計的軟件可以實現既定的核安全相關功能。

2.4 軟件開發階段

軟件開發IV & V階段的目標是驗證軟件設計是否準確地轉化為成品代碼、是否全面實現功能，同時還要核實是否引入了額外的可能會影響到所需求功能的代碼。在此階段IV & V活動的常見的實現形式為靜態分析和人工代碼走查，以確保源代碼準確、有序及可被測試等特性，同時也需要對可追溯性進行驗證。在針對代碼進行審查后，需要根據每一項功能需求制定系統集成測試的測試案例以及相應的接受準則。

2.5 集成測試階段

此階段IV & V工作的重點是確認所有既定的功能要求已得到實現，并通過前一階段制定的測試案例以及驗收準則進行驗證，即通常所說的系統集成測試。在集成測試過程中，一般通過獨立運行每一個功能邏輯通道來驗證軟件與相應的硬件可以可靠實現所要求執行的功能。在驗證與確認過程中，IV & V需關注軟件對需求的符合性、覆蓋性，即軟件可以正確地實現系統需求，而又不引入新的不確定性。

2.6 維護升級階段

維護升級階段的V & V活動主要針對的是軟件投用后的維護工作。軟件開發工作的結束并不意味著軟件生命周期的結束，由于功能擴展需要、設計變更需要，軟件即使在開發完成投運后還是可能會有大量的修改或升級。此階段IV & V的工作主要是確認軟件的修改不會影響以往軟件IV & V相關工作的有效性，同時對軟件中新的功能要素進行補充的IV & V。

3 主要的IV & V驗證與確認方法

在安全級軟件研發過程中，審查、分析和測試是IV & V的3種主要方法。

3.1 審查

對軟件研發過程各階段產生的文檔以及產品的審查，主要包括各階段任務輸入輸出文件。常見的審查對象如系統需求規范書、軟件功能說明書、需求矩陣、第三方工具認證文件、設計規范、代碼文本、測試大綱、測試規程、工廠測試報告、回歸分析報告、階段總結報告，任務報告等。審查工作的有效性取決于IV & V團隊的能力與經驗，常用的手段為核對表。IV & V團隊中高級別管理人員會在核對表中逐項列出要求審查人員關注的要素，并對審查結果進行復核。核對表適用于所有IV & V任務。

3.2 分析

（1）需求跟蹤。需求跟蹤分析的作用是確保所有較低層次的需求（含延伸需求、隱性需求和集合需求）和要求與高一層次的需求相對應，確保所有上級需求均通過低層次的要求的滿足得到了實現。需求可跟蹤性分析一般通過需求跟蹤矩陣的工具實現，通過在矩陣中記錄各個階段的需求以及其與需求源之間的關系。

（2）問題跟蹤系統。問題跟蹤系統（RITS）是一種類似不符合項管理流程的工具，用于記錄與跟蹤所有在IV & V審核分析以及系統測試過程中發生的問題，包括問題整改以及關閉驗證。軟件研發過程中產生的問題從本質上說就是需求的不滿足。問題跟蹤系統與需求跟蹤矩陣作用互補，主要用于軟件開發后期及測試階段，對尚未得到滿足的需求以及技術要求進行跟蹤處理。

（3）風險／影響分析。風險/影響分析是對某一階段或任務進行定性分析、定量分析、評價和規劃風險應對，避免軟件開發前期過程中的潛在隱患進一步擴大進而演變成后期無法解決的問題，及時地采取保守措施或是建立監控機制，從而有效管控風險。風險/影響分析矩陣是最常用的工具，目前已有較多的第三方軟件提供具備相應功能的管理平臺。風險／影響分析結論是軟件開發決策以及項目管理的重要參考依據。

3.3 測試

用于實現特定功能的軟件都需要通過測試進行驗證。對于安全級軟件，其測試必須覆蓋所有的功能分支，即測試案例應保證使每一個軟件模塊內的所有分支均至少得到一次驗證。另外，除了針對功能進行的測試外，也需要設計一定的框架測試以確保程序中不包含不需要的額外功能，并對非功能性的軟件要求（如穩定性）進行驗證。系統測試采用從下至上的方式。先進行低層次部件級測試，然后再逐層開展高一級的測試。

（1）軟件子模塊測試。軟件子模塊測試是對系統中的一個處理器或控制節點的軟件功能進行的獨立測試。軟件子模塊測試主要目的是根據軟件子模塊的單一功能要求對一定范圍內的代碼集合進行功能測試，包括軟件模塊響應時間，確保底層的功能符合性。

（2）通道集成測試。通道集成測試在硬軟件集成后開展，通常以一組機柜或單一功能通道為單位，先測試每個機柜，然后將執行某一類特定功能回路相關的所有機柜連接起來進行整個功能通道的測試。機柜的輸入和輸出間關系是通道集成測試對象，包括一定范圍內系統內部的通信、通道級的響應時間等。

（3）系統集成測試。系統集成測試在儀控系統集成完成后開展，對所有機柜以及功能通道之間的通信、數據傳遞、控制邏輯、冗余特性、負荷裕度、容錯性能、魯棒性進行整體驗證，并測試系統級應用整體響應時間、人機接口界面（包括操控性）與外部儀控系統的接口通訊等。

4 結語

不同于常規核電設備，安全級儀控系統軟件需要通過專門的獨立驗證與確認活動來確保軟件質量。對核安全級軟件IV & V，核電技術領先的發達國家已建立了較為完善的法規標準體系、具備較高的可操作性，因此深入研究國外現有成熟的IV & V管理體系，并參照制定適合我國的核電廠數字化儀控系統IV & V標準體系具有十分重要的現實意義。