保護系統1E級軟件獨立驗證實施管理

魏 鵬 黃平兒 吳 俊

（海南核電有限公司 海南昌江）

隨著數字化儀控技術的快速發展，在我國新建電廠中，反應堆保護系統及事故后監視等安全重要功能均已采用數字化儀控系統（以下簡稱DCS）來實現。DCS系統的可靠性取決于設備硬件和軟件兩方面。為保證安全性和可靠性，數字化保護系統除必須通過通常的質量鑒定程序確認其硬件質量外，還必須對執行安全功能的1E軟件遵循國家的各項核安全法規、導則及標準，進行獨立驗證與確認活動（即Independent Verification&Validation）。

1E軟件獨立驗證和確認是一種綜合性的軟件質量保證方法。驗證（verification）是通過檢查和提供客觀證據，證實規定的需求已經得到滿足；確認（validation）用于證實特定預期用途的需求是否得到滿足。驗證側重于過程性檢查測試，即白盒測試，確保前一個活動輸出的產品合格地成為后一個活動的輸入；確認側重于對結果的檢查測試，保證系統和軟件所做的符合需求規格說明書和合同的規定，從而滿足用戶的預期，即黑盒測試。兩者結合起來形成一個套IV&V方法論，它包括了對軟件產品和過程的分析、評價、評審、審查、評估和測試等活動，集中了許多技術和方法，覆蓋了軟件生存周期過程的所有基本過程，具有較高的獨立性和可操作性。

對于每項具體的IV&V活動，需結合相應設計、測試、分析等技術領域的通用標準并將其與核安全領域的法規、導則、標準的特定要求相結合，制定出符合要求并且可行的具體執行方法。在IV&V活動的執行過程中，應嚴格遵循法規及標準的要求，并將該要求貫徹落實到每項具體的IV&V行動中。

一、海南項目IV&V實施概況

海南項目1E IV&V活動，根據核安全法規HAF 102-2004中的要求，基于核安全導則HAD102/16-2004中的驗證與確認的基本流程及相應的要求，并參考IEEE Std 1012-1998軟件V&V、IEEE Std 1028-1997軟件審查，Nureg 1.168-2004用于核電廠安全級系統數字化計算機軟件驗證、確認、審查、審計導則等，編制SVVP（軟件驗證確認大綱）。

海南項目RPS系統平臺設備Triconex V10已經過美國核管會、中國核安全局驗證、審查，取得核級鑒定證明，故海南項目軟件IV&V活動僅針對應用軟件，不包括操作系統、硬件、平臺軟件。本文僅針對在出廠測試階段的IV&V活動，其他獲取、供應、開發、運作、維護、組織、文檔編制、配置管理、質量保證、審核等軟件生命周期階段的IV&V活動和任務，不在本文論述范圍內。

1.IV&V團隊組織和責任

根據法規要求、海南項目合同約定，并基于供貨商項目管理架構，海南項目由設計團隊、質保團隊、IV&V團隊等共同開展IV&V活動管理工作。為保證海南項目IV&V活動的獨立性，在1E應用軟件的開發過程中，由滿足技術、管理和財務獨立的團隊組成IV&V測試團隊。

IV&V測試團隊負責實施獨立設計文件審查、軟件設計驗證、需求跟蹤、開發和審查IV&V文件，準備和執行IV&V分析任務，并負責IV&V測試執行。確保應用軟件開發每個階段的輸出滿足上一階段的約束，確保每個階段的輸出滿足用戶需求和法規要求，確保最終產品滿足用戶需求。為保證獨立性，IV&V測試團隊根據IV&V活動自身的情況來制定計劃，而不受來自軟件設計團隊的任何限定、財務約束、直接或間接的壓力。

對于項目工程設計團隊，在整個核級應用軟件開發生命周期中，僅負責依據設計輸入，完成項目軟件和硬件設計，系統集成發貨等工作，完全獨立于IV&V活動。

在整個IV&V活動中，項目QA團隊依據項目的質保大綱和軟件IV&V大綱監督和檢查IV&V活動，審查測試規程確保符合項目質保程序，執行獨立核查和監督，管理IV&V活動中的不符合項，審查和關閉測試活動中的異常報告（Anomaly Report）。

2.軟件完整性

IEEE 1012-1998標準對保護系統軟件完整性Software Integrity Level（ SIL）建立了分類模型，在 IEC 61508（ 2.18）和IEC 61513（2.20）中也援引此模型。完整性模型將1E軟件錯誤的后果分為災難性的、嚴重性的、微小的、可以忽略的，并依據導致該錯誤運行狀態的概率，將應用軟件歸為4類，根據Nureg 1.168-2004導則建議，將 RTS（反應堆停堆功能）和 ESFAS（專設安全功能）歸為SIL-4級。不管其是否執行安全功能，依照Nureg 1.152-2006（2.3）導則要求，任何1E級計算機系統的軟件模塊都將被歸為SIL-4級。

故保護系統IV&V過程中任何微小的、可以忽略的，即便不經常發生的軟件錯誤都必須經過驗證和確認。

3.IV&V活動工具、技術、方法等資源管理

為了保證IV&V活動過程的高效性、準確性、獨立性，并保證活動符合發揮、導則、標準要求，IV&V引入了先進的軟件工具、技術、測試方法，實踐中采取了一系列的措施，以支持軟件的驗證和確認過程。各階段使用的工具、技術、方法分別介紹如下。

需求跟蹤環節，供貨商采用IBM Rational DOORS軟件，將需求以具體的條目形式保存，通過創建RTM（Requirement Traceability Matrix）跟蹤需求矩陣，整個需求分為從系統需求SyRS（系統需求規格書）、子系統設計需求、軟件需求SRS（軟件需求規格書）和軟件設計需求SDD等幾個等級，在每一個等級中，所有的需求都以條目形式管理。每個條目都具有相應的創建、修訂和變更歷史，并維持了與上下級需求之間的鏈接關系。RTM跟蹤器中中每一條獨立的設計需求。并據此生成每個子系統的SDD（軟件設計描述），以及單獨的測試規程文件TP。V&V環節通過跟蹤RTM文件，來證明應用軟件100%的依照設計需求來實施，從上下游跟蹤需求也證明了其可追溯性，并為需求追溯分析提供支持。

軟件部件測試（Software component test）、集成測試（Software Integration test）環節的工具主要包括：TriStation 1131 4.7.0，Triconex Emulator 1.1.0，Triconex 動態數據交換（ DDE）客戶端4.7.0，TS1131仿真測試驅動，供貨商開發的SCT、SIT自動測試腳本，微軟Excel等工具；驗收測試環節IV&V活動包括一些經過驗證的供貨商內部軟件、CAPE商用貨架測試軟件和硬件，如利用商用計算機仿真電站傳感器、執行機構輸入輸出，利用Tristation IVU工具檢查Triconex硬件之間的連接，利用經過驗證的VP-link仿真工具模擬現場設備輸入、提供GUI圖形接口畫面，測試人員可以手動改變現場設備的輸入輸出值。其他IV&V工具還包括：UCM文檔管理系統、SVN版本管理軟件、eroom文檔交換系統、其他辦公軟件和工具。

二、IV&V開發生命周期

為了確保系統的軟件安全可靠，針對軟件的V&V必須貫穿軟件的生存周期，以驗證各項需求被滿足且未引入新的風險。從軟件最初的需求獲取到最終的運行、維護，V&V均需全程參與。并且涵蓋軟件、硬件和外部運行環境綜合進行考慮。在當前階段，V&V更多是從軟件角度來考慮，但由于軟件的可靠性等與硬件及外部運行環境密不可分，為此，目前的趨勢越來越多的將三者一并考慮。在本文中描述的內容是以軟件為主，同時考慮了相關的硬件及外部運行環境。

1.管理活動

IV&V管理活動也屬于IV&V開發流程中的一個環節。這個活動將持續地評審V&V工作，應用軟件開發是一個循環和交互的過程，管理活動基于更新的項目進度和開發狀態對SVVP進行必要的修訂，并與開發方以及諸如質量保證、配置管理、評審和審核等其他支持過程協調V&V結果。根據IEEE 1012-1998標準要求SVVP軟件驗證確認大綱編制作為SIL-4級的任務在IV&V管理活動中進行。SVVP作為整個IV&V活動開始后的第一項工作，其他管理工作將伴隨整個IV&V開發生命周期過程。

2.軟件IV&V開發流程

根據IEEE 1012-1998標準，軟件IV&V開發過程，包括需求分析、設計、代碼編制、集成、測試、安裝、驗收測試活動；這些活動被劃分為6個階段：概念V&V、需求V&V、設計V&V、實施V&V、測試V&V、安裝和檢驗V&V。

其中概念V&V活動涉及系統體系結構設計和系統需求分析，概念V&V的目標是驗證系統需求的分配，確認選定的解決方案，確保沒有采納錯誤的解決方案。安裝和檢驗V&V活動是指在目標環境下對軟件產品的安裝、以及需方對軟件產品的驗收評審和測試。安裝和檢驗V&V活動涉及軟件安裝和軟件驗收支持。V&V的目標是驗證和確認在目標環境下軟件安裝的正確性。

基于SVVP大綱，由于概念V&V在參考機組中已完成，安裝檢查V&V由電站運營單位自主實施，所以不在IV&V開發流程內。

根據IV&V流程，每個階段都需要完成相應的確認和驗證工作，包括關鍵性、安全性、危害、風險和追溯性（Criticality/Hazard/Risk/Interface/Traceability）分析，并完成相應階段的IV&V報告。

①關鍵性分析（criticality analysis）。針對系統失效、系統老化或未能滿足軟件要求或系統目標所造成影響的嚴重性而進行的軟件特性（例如，安全性、安全保密性、復雜性和性能）的結構化評估。

②危險（hazard analysis）。危險性分析是指在人身傷害和健康、財產、環境的損害等方面的潛在傷害來源或具有潛在傷害的情形。在概念階段需通過故障樹等多種方法來確定系統潛在的危險源，并評估其嚴重性、概率等。在其后的每個階段的危險分析活動中，均需對每項危險源的后繼處理進行分析，以確定該危險已被系統明確的定義了相應的需求項來緩解或消除，并且該需求被正確地設計和實現；同時還需確保在軟件的研發活動過程中沒有引入新的危險。

③風險（risk analysis）。特定危險事件的頻率或概率與后果的綜合。

④接口分析（interface analysis）。當信息橫穿邊界時（例如硬件到軟件、軟件到軟件、軟件到用戶），總有丟失一些信息或改變信息內容的可能性。接口分析的目的是在接口需求的正確的、一致的、完整的和精確的描述方面去評價具體的軟件可交付產品（ 例如，需求、設計、代碼）。

⑤可追溯性分析（traceability analysis）。可追蹤性是標識初始需求與最后所得到的系統特征之間關系的能力，它提供了把一個要素與另一個要素聯系起來的線索。在需求、設計和實現活動中，要進行可追蹤性分析。

（1）需求V&V。軟件需求V&V活動構成設計和驗證活動的基礎，用于整個軟件生命周期，也同樣是設計、實施環節的基礎。需求V&V活動確定了功能性和性能需求、軟件外部接口、合格性需求、安全性和安全保密性需求、人因工程、數據定義、軟件用戶文檔、安裝和驗收需求、用戶操作和執行需求、用戶維護需求。軟件需求V&V活動的目標是確保軟件需求的完整性、正確性、一致性、清晰、可追溯性和可測性。軟件需求跟蹤文件的主要目的是，清除的定義系統誰就和開發過程的對象和需求，并作為作為設計V&V環節的基礎。

根據IEEE 1012-1998標準的分級，SIL-4級系統的需求V&V活動最低限度需要完成以下任務：可追蹤性分析；軟件需求評價；接口分析；關鍵性分析；系統V&V測試計劃生成和驗證；驗收V&V測試計劃生成和驗證；配置管理評估；危險分析；風險分析。

以上任務將產生如下輸出文件：系統V&V測試大綱文件、驗收V&V測試大綱文件、任務報告-軟件配置管理評估報告，需求V&V環節的關鍵性、安全性、危害、風險（Criticality/Hazard/Risk/Interface）分析報告文件，任務報告-追溯性分析報告，任務報告-本階段需求評估報告，以及各任務的異常項報告（ Anomaly Report）。本環節結束后，將完成需求V&V活動總結報告。

（2）設計V&V。在1E軟件設計IV&V活動中，軟件需求被轉化為系統體系結構、信息流、處理步驟、每個軟件部件的結構和詳細設計以及其他需要實施方面。設計包括數據庫和接口（軟件外部、軟件部件間、軟件單元間）。設計V&V活動涉及軟件體系結構設計和軟件詳細設計。V&V的目標是驗證設計輸出文件可理解、清晰、正確、準確、一致、完整、可測試、可追溯的轉化了來自于上一環節的設計輸入，而且沒有引入非預期的特征。

根據IEEE 1012-1998標準的分級，SIL-4級系統的設計V&V活動最低限度需要完成以下任務：可追蹤性分析；軟件設計評價；接口分析；關鍵性分析；部件V&V測試計劃生成和驗證；集成V&V測試計劃生成和驗證；V&V測試設計生成和驗證；危險分析；風險分析。

以上任務將產生如下輸出文件：更新SVVP文件、部件級V&V測試大綱、集成V&V測試大綱、測試規格書（包含測試規程和用例）、任務報告-軟件設計評估報告，設計V&V環節的關鍵性、安全性、危害、風險（ Criticality/Hazard/Risk/Interface）分析報告文件，任務報告-追溯性分析報告，任務報告-本環節需求評估報告，以及各任務的異常項報告（Anomaly Report）。本環節結束后，將完成設計V&V活動總結報告。

（3）實施V&V。實施V&V活動將設計轉化為代碼、數據庫結構和相關的可執行機器表示。實施階段文件的客觀性促進了有效的生產、測試、使用、傳遞和轉化到不同的環境，為后續修改、設計文件的追蹤性提供便利。實施V&V活動涉及軟件編碼和測試，通過確認軟件的源代碼、數據結構等，進行部件級測試和軟件集成測試SIT，驗證整個設計過程，屬于白盒測試。實施V&V的目標是驗證和確認這些轉化是正確、準確和完備的，回答了以下問題：①軟件實施是否滿足設計文件；②軟件實施是否符合相關設計標準；③軟件實施是否符合相關文檔標準；④軟件實施是否滿足用戶的生產、測試、使用、傳遞等需求。

根據IEEE 1012-1998標準的分級，SIL-4級系統的實施V&V活動最低限度需要完成以下任務：可追蹤性分析；源代碼和源代碼文檔評價；接口分析；關鍵性分析；V&V測試用例生成和驗證；V&V測試規程生成和驗證；部件V&V測試執行和驗證；危險分析；風險分析。

以上任務將產生如下輸出文件：更新SVVP文件、部件級測試規格書/測試規程/用例、集成測試規格書/測試規程/用例、系統&驗收測試規格書/測試規程/測試用例，執行的部件級測試規程和測試用例，部件級別測試結果，實施V&V環節的關鍵性、安全性、危害、風險（Criticality/Hazard/Risk/Interface）分析報告文件，任務報告-源代碼和源代碼文件評估報告，任務報告-本環節追溯性分析報告，以及各任務的異常項報告（Anomaly Report）。本環節結束后，將完成實施V&V活動總結報告。

（4）測試V&V。通過以上需求、設計、實施環節的IV&V活動，能夠保證軟件在一定程度上適當、準確的轉化了設計需求。測試IV&V活動用來確定保護系統軟件是否滿足其邏輯功能、運行、系統級性能、外部接口（包括第三方及I/A）、內部接口、可測性等設計指標；系統確認通過在目標軟件、硬件設備上測試，評估了軟件在實際運行環境下的性能。

測試V&V活動覆蓋軟件邏輯功能測試、軟件集成、軟件合格性測試、系統集成和系統合格性測試。測試通過驅動系統輸入確認輸出來驗證，屬于黑盒測試，V&V的目標是確保通過執行集成測試、系統測試和驗收測試使軟件需求和分配給軟件的系統需求得到滿足。

根據IEEE 1012-1998標準的分級，SIL-4級系統V&V工作應生成自己的V&V軟件和系統測試產品（例如，計劃、設計、用例、規程），執行并記錄自己的測試，并對照軟件需求驗證開發過程的測試計劃、設計、用例、規程和結果。測試V&V活動最低限度需要完成以下任務：可追蹤性分析；驗收V&V測試規程生成和驗證；集成V&V測試執行和驗證；系統V&V測試執行和驗證；驗收V&V測試執行和驗證；危險分析；風險分析。

以上任務將產生如下輸出文件：更新SVVP文件、集成測試規格書/測試規程/用例/任務報告-測試結果、驗收測試規格書/測試規程/測試用例，執行的系統測試規程和用例/任務報告-測試結果，執行驗收測試規程/測試用例/任務報告-測試結果，測試V&V環節的危害、風險（Hazard/Risk）分析報告文件，任務報告-本環節追溯性分析報告，以及各任務的異常項報告（Anomaly Report）。本環節結束后，將完成測試V&V活動總結報告。并完成IV&V活動最終報告。

（5）其他任務。根據標準中列出的可選任務，海南項目1E反應堆保護系統軟件還進行了安全評價（Security Assessment），用來評估系統是否安全可控，保證系統的硬件、軟件的部件不會被未授權使用、修改、披露，并驗證用戶權限管理。驗證系統安全相關對象的存儲、歸檔是否受控等。本任務在各階段都需執行，并形成相應分析報告。

三、IV&V 過程管理

在開展IV&V開發各生命周期各環節活動中，都有可能出現各種問題，海南項目主要出現的問題有：AR、任務重新執行、TRB審查。

關于AR異常項（Anomaly Reports），每個環節出現的AR將都會被統計在相應環節的IV&V總結報告中。但在測試階段，發現有SRS的AR需要處理，則僅需在測試環節總結報告中描述即可，無需返回修前幾個階段的總結報告。對于AR解決，依據Nureg-1.168-2004（2.4）的推薦，采用回歸測試作為處理AR、復測的手段。如果測試過程中發現與測試規程之間存在差異或偏離，也將需生成AR，在經過充分的分析后，將需要修改測試步驟或者驗收標準，在修改前，須要經過AR處理和確認過程，包括測試文件確認、受影響文件的獨立審查等工作。在執行過程中，IV&V團隊辨識軟件AR和工程設計團隊處理軟件AR、IV&V測試AR均需獨立進行。在完成復測后，測試結果將作為AR報告的一部分，完成

關于任務確認工作，在IV&V活動中，由于本環節的輸入變更，應基于對應用質量和軟件完整性的影響兩方面的評估，來決定V&V任務重復執行的范圍。如果輸入變更僅限于軟件需求版本、性能準則，此時評估僅影響軟件功能，需要復測，為確認修改沒有引入其他非預期性副作用。但如果修改涉及到計算機的基本性能要求，比如程序執行時間，通訊負荷、自診斷路線，評估工作應包含所有受影響的安全級計算機。

關于測試文件審查工作，根據Nureg-1.168-2004導則建議，海南項目IV&V活動建立了Test Review Board（TRB）機構，TRB機構由項目經理、質保工程師、IV&V測試工程師等組成。所有項目測試文件的重大修改都需要經過TRB審批。包括測試大綱、規程、用例、分析報告、測試記錄、測試報告等文件。

四、結論

討論了IV&V的方法論及其在對數字化核安全級儀控系統開展軟件驗證與確認過程中的具體應用，同時也介紹了為確保該活動的有效開展而制定或建立的驗證與確認工作流程、技術規范體系以及V&V工作平臺等，這些不但推動了驗證與確認工作的開展，還可使得驗證與確認的工作更規范、更可信。這套方法及相應的平臺將有助于在產品功能、性能、安全性及可靠性等指標的符合性方面給出客觀、可信的評價。

針對數字化核安全級儀控系統的驗證與確認的過程及技術、平臺等也可應用到諸如鐵路信號、航空航天、軍工等其他多個安全領域。