核電儀控軟件質量支持過程的探討和實踐

吳 彬

（國核自儀系統工程有限公司，上海 200000）

0 引言

日本福島核事故發生后，全球對核電安全要求提高，作為核電站的神經系統，數字化儀控系統的設計、制造、調試、維護工作面臨了新的發展機遇和考驗。在安全級和非安全級數字化儀控系統中，計算機軟件均高度集成了數據和算法，其質量直接受制于開發體系和工程師的素質。

數字化儀控系統由于安全性、可靠性非常高，如果軟件產生故障或帶有潛在的缺陷，將可能造成人身、財產安全的巨大損失。若軟件質量不高，對業主來說維護費用將十分龐大，并且維護工作的難度也會非常高。

AP1000非能動壓水堆核電站中的安全相關軟件遵循美國聯邦法10CFR50附錄A“核電廠通用設計準則”和附錄B“核電廠和燃料后處理工廠質保準則”中的要求。為了保證質量，還引入軟件工程領域的眾多過程領域作為工作導則，例如需求管理、配置管理等。

1 軟件質量評價與能力成熟度模型集成

IEEE對于軟件質量的定義為：①系統、組件、過程滿足指定需求的程度；②系統、組件、過程滿足客戶或用戶需要或期望的程度。軟件質量評價是一項系統活動[1]，包括開發過程的評價、最終產品的評價、若干相似功能軟件的相互比較。軟件質量評價的標準主要有ISO 9126“軟件工程產品質量模型”和IEEE Std 1061“軟件質量度量方法”。

圖1 軟件模型與IEEE過程域的聯系Fig.1 The connection of Software model and IEEE process area

ISO 9126采用6個軟件質量特性：功能性、可靠性、易使用性、效率、維護性、可移植性。

功能性是與一組功能及其指定的性質有關的一組屬性，這組屬性描述軟件滿足什么需求?？煽啃允桥c在規定的一段時間和條件下，軟件維持其性能水平的能力有關的一組屬性，可靠性是由于軟件需求、設計、實現中的缺陷所致。

根據以上6個質量特性，可以再進行子特性的細分，如可以將可靠性細分為成熟性、容錯能力、故障恢復性等。每一個子特性都和一個質量特性所對應，其特定組合反映了某一軟件質量特性。對于特性和子特性，應設置度量單元，用于在開發過程中評估和預測軟件質量。度量單元是一些具體的問題，被用于開發過程中評估和預測軟件的質量，對這些問題的答案進行計分，可以反映出質量子特性與特性的得分。

例如，對于控制軟件中的控制邏輯來說，功能性可以采用白盒測試進行驗證，在其中可以運行各種測試用例，對邏輯中的條件覆蓋、分支覆蓋、語句（簡單邏輯）覆蓋進行檢查。測試的統計結果以覆蓋率百分數的形式進行記錄，對覆蓋率進行等級劃分，可以確定相應的評價級別。

對于儀控軟件開發和維護組織而言，軟件質量評價的結果往往取決于組織的能力成熟度?？▋然っ仿〈髮W軟件工程研究所給出了能力成熟度模型集成（CMMI）的框架，描述了有效的軟件過程的關鍵元素，給出了軟件開發和維護組織從不成熟的開發過程向成熟規范的開發過程上升的通道，覆蓋了軟件開發維護相關的策劃、工程、管理實踐。核電儀控企業可參考CMMI中的過程域，對標IEEE相關標準，制定和修改軟件開發和維護過程。

2 需求開發與管理

2.1 概述

從監管的角度，美國NRC導則RG 1.173-1997“核電廠安全系統中使用的數字計算機軟件的軟件壽命周期過程開發”中背書了IEEE Std 1074-1995“開發軟件生命周期過程”[2]，在標準的5.1節描述了需求過程。從質保的角度，ASME NQA-1-2004中對軟件開發過程進行了描述，即要求3的801部分。其中，規定的軟件設計需求的識別、軟件設計、軟件設計的實現、軟件設計驗證、計算機程序測試過程涵蓋了需求開發和管理的內容。

2.2 需求開發活動

核電儀控項目中需求開發過程的目的是產出并分析業主、交付物及其組件的需求，用來表達相關方的需要，包括與儀控系統生命周期各階段及產品屬性有關的需要，也包括選擇某設計解決方案而產生的限制條件。

需求開發的過程是循環迭代的，結合IEEE Std 1233-1996[3]的定義，儀控軟件需求開發的4個子過程包括：從輸入資料、業主/設計院/其它相關方的技術團隊處識別需求；創建形式良好的需求；組織需求，進行結構化調整，寫入軟件需求規范書；將軟件需求規范書以不同的表達形式展示給各相關方。結合軟件需求規范，對軟件架構更細層次不斷分析，直到可以獲得足夠的細節進行詳細設計和測試。儀控EPC項目中會存在產生多層子系統需求的情況，但無論規模大小，需求都應當分解到最小的可實現單元。對于項目的軟件部分，最小的可實現單元為計算機軟件配置項。在此過程中，軟件開發組織還應當定義功能和實體之間的接口。

2.3 需求管理活動

需求管理過程的目的是在項目啟動后，在設計活動開始前和執行中，通過結構化的過程定義，保證能識別出所有需求，以此保證客戶需求得以實現，減少或消除返工，避免在測試階段變更系統配置。作為一個迭代過程，需求管理要求軟件開發和維護組織具備系統工程的實踐能力。

需求管理過程應根據項目規模確定活動粒度，可以通過兩種維度進行度量：需求分解的層次，為完成某項功能指派的人員數。

需求管理包括需求追溯、需求變更控制、界定項目工作與需求間的差異。通過維護需求追溯性，可以建立原始需求和衍生需求之間雙向的追溯性，也可以涵蓋需求和設計、測試、最終產品等實體之間的追溯性。需求追溯可以采用需求追溯表和需求追蹤系統的途徑來實現。

需求變更作為一種重要的變更形式，在軟件開發過程中十分常見，但若處理不當，容易造成軟件設計缺陷、項目延期、超支等后果。因此，需求變更應符合變更控制的要求。

3 配置管理

3.1 概述

在ASME NQA-1-2004要求3設計控制的802部分，詳細描述了軟件配置管理過程，對配置管理活動提出了相關要求。配置管理過程體現了PDCA全面質量管理的精髓，從計劃、執行到檢查、處理，再回到計劃，通過螺旋式的逐步改進提升，使整個項目質量能夠達到預期目標并維持在較高水準。

3.2 配置管理活動

根據IEEE Std 828-2005[4]，軟件配置管理計劃中需要涵蓋配置管理所執行的活動，主要包括配置標識、配置控制、配置狀態記錄、配置審計、接口控制、供應商控制以及釋放的管理和交付。配置管理與需求管理、文件控制有著緊密的聯系，但彼此又有區別。在軟件產品向前演進的過程中，三者的關系能夠明確地體現出來。

3.2.1 配置標識

配置標識是軟件配置管理的基礎性工作，是優化配置的前提。配置標識目的是要識別項目中的所有配置項（Configuration Item），配置項包括但不限于軟件、軟件文檔以及與軟件集成的硬件，對識別出的配置項進行命名以便及時準確地獲取某個狀態下軟件的配置。如果配置標識不合理，基線（Baseline）管理將難以操作，隨之而來的版本控制和變更控制也將成為棘手的問題。

3.2.2 配置控制

配置控制是配置管理活動日常管理的重點，而變更管理又是配置控制的關鍵。變更可能在項目任何階段發生，并且任何項目成員都可能成為變更的發起者。因此，對于變更控制組織必須建立一套有效方案來加以控制。手段可包括制定變更程序，成立變更管理委員會，委派專員采用變更管理軟件對變更進行管理。

變更可能會牽涉多個專業領域，如必要，需對受影響的各專業領域進行評估，方能確定變更的范圍。對變更的結論進行決議時，可根據變更影響范圍、優先級程度，結合開發組織結構特點來決定。當決議生效后，變更內容需要以文檔的形式記錄。變更文檔需經過軟件開發組織的審查，確保變更內容正確無誤可以實施。

3.2.3 配置狀態記錄

配置狀態記錄反應配置項的狀態，特別在形成基線或釋放（Release）時，可確保軟件開發組織成員及時獲知配置項的最新狀態，避免產生不適當的軟件分支和歸并。

3.2.4 配置審計

配置審計是對配置管理執行情況的檢查，執行一般為軟件質量保證人員（SQA）。SQA對當時軟件配置的質量情況與質量改進建議負責。項目對于審計出的不符合項應分析原因，識別職責，避免相同質量問題在本項目或其他項目的再次發生。

3.2.5 接口控制

接口控制主要反映配置項之間的聯系，某配置項的變更會引發其他配置項的改變，這類配置項在配置管理計劃中應加以標識。

3.2.6 供應商控制

供應商提供的配置項一般不列入項目本身直接管理的范圍。對于這些配置項，需評估供應商對其進行配置管理的計劃以及執行的結果，經開發組織確認的外來配置項才會被納入配置管理中。供應商配置項變更也需符合3.2.2的變更控制。

3.2.7 釋放管理與交付

釋放管理與交付關注軟件代碼、目標碼、二進制文件和軟件文檔。對于那些涉及安全的關鍵性功能需保存所有記錄，保證釋放或交付的產品正確可靠。

4 文件控制

4.1 概述

在ASME NQA-1-2004的要求6中，定義了文件控制：“確定質量要求或規定影響質量活動的文件，如細則、程序、圖紙等，它的形成、發放和變更都應予以控制，以保證使用正確的文件。如該文件需變更，應審查其合適性，并由授權的人批準后發布?！?/p>

針對軟件，文件控制會貫穿其生命周期各階段，全面記錄了軟件需求、軟件設計、軟件實現、軟件測試、發布軟件產品、運行維護等過程。在軟件開發組織的質量體系框架內，文件控制的策略和具體措施很大程度影響了核電儀控軟件的質量。各公司對文件控制的方法不盡相同，建立一套符合自身實際狀況的文控流程才能保障項目有效推進。結合NQA-1-2004以及ISO 9001-2008提煉出以下要求，這些要求不僅適用于軟件文檔：

1）文件發布前需得到批準，以確保文件充分且適宜。

2）必要時對文件進行評審與更新，并再次批準。

3）確保文件的更改和現行修訂狀態得到識別。

4）確保在使用處可獲得適用文件的有關版本。

5）確保文件保持清晰、易于識別。

6）確保策劃和運作質量管理體系所需的外來文件得到識別，并控制其分發。

7）防止作廢文件的非預期使用，若因任何原因而保留作廢文件時，對這些文件進行適當的標識。

4.2 軟件文檔

在項目啟動前，組織根據客戶要求和軟件產品需求構劃軟件文檔類型，主要包括軟件質量計劃、軟件需求文件、軟件設計與實現文件、軟件驗證和確認文件、用戶文件。具體的軟件文檔范圍和分類定義可參考GB/T 8567-2006《計算機軟件文檔編制規范》，與軟件文檔相關的其它技術文件包括但不限于各類圖紙、軟件設計文件等。這些文件之間彼此相互依賴，相互聯系，保證軟件產品能夠符合原始需求且具有傳遞性。

軟件文檔的編制可依據模板規范文件內容形式，對于軟件設計文件和記錄不但應包括最終設計文件，如圖紙、規范書及其相關修訂，還應包括確定設計過程重要步驟的文件，如支持最終設計的初始輸入資料。

4.3 文件的形成、發放與變更

4.3.1 文件形成

為保證儀控軟件文檔的合規性、正確性、完整性和可用性，正式的軟件文檔，與之相關的其它技術文件應經過編制、校核、審核和批準等步驟。

文控人員在文件編制過程中，有必要追蹤文件當前狀況，記錄編制、校核、審核和批準的開始和完成時間，以跟蹤計劃進度的完成情況。

4.3.2 文件發放

文件在經過批準后，軟件開發組織負責對文件執行保密性評定并進行歸檔入庫，并由專門的檔案管理人員妥善保存檔案原件。軟件開發組織成員可通過一種或多種途徑獲取已發布文件的信息，并且符合公司文件控制流程。

已失效的文件由檔案管理人員及時回收，統一存放管理，以保證不被誤用。對于無必要保留的作廢文件，執行銷毀處理，保證文件內容無法還原。

4.3.3 文件變更

文件的變更參考配置控制的要求和控制手段進行，可見3.2.2節。

5 實例

圖2以核電廠控制系統中的化學與容積控制系統（CVS）由輸入工藝系統文件升版導致的變更為例，描述和分析了儀控系統軟件設計由需求管理、配置管理、實施至文件控制的流程。

5.1 輸入文件升版

在控制軟件詳細設計階段，軟件開發組織接收到新版的CVS系統規格書，其中修改增加了電廠水實體模式下CVS系統的控制策略。由于控制軟件的功能需求來自于工藝系統規格書，因而輸入文件的升版將直接影響需求。

5.2 對比需求基線，統計差異

通過與需求基線中CVS系統部分進行對比，發現新版CVS系統規格書主要影響了水實體模式下CVS補水泵的控制邏輯需求。

5.3 輸入基線變更

配置控制委員會（Configuration Control Board，簡稱CCB）將新版CVS需求規格書加入輸入基線，替代原版文件。

5.4 提出需求變更建議

圖2 CVS軟件開發管理Fig.2 CVS software development manage

負責控制軟件需求開發的工程師針對CVS系統規格書中的變化提出名為“CVS水實體模式控制策略變更”的需求變更建議，進入變更管理過程。在此過程中，變更的初步影響范圍（對系統架構、硬件I/O分配、軟件設計、測試）、變更等級、原因及依據等信息被識別。根據變更等級的不同，相應的責任人需確認變更信息完整性和正確性，變更正式建立。

5.5 評審變更，分解變更任務

配置管理員在總結變更信息后，分發相關專業組織進行詳細評估。特別地，負責CVS軟件設計和測試的組織將對受影響的軟件組件、單元進行分析，識別受影響的控制邏輯、畫面顯示等，并明確受影響的程度，提出同意/否決該變更的意見，反饋給配置管理員。配置管理員在集齊所有專業組對變更的評估后，組織CCB會議。在此會議中，CCB成員將根據影響范圍、成本、進度等方面進行綜合評估，并對變更進行決議。在此例中，CCB會議通過了CVS水實體模式控制需求的變更，將根據新版CVS系統規格書更新需求基線。

5.6 修改CVS功能需求

需求開發人員負責根據新版規格書提出與之符合的控制功能需求。

5.7 確立新CVS系統需求基線

需求管理員根據變更評審過程中提出的評估意見，聯合架構設計工程師、硬件工程師、軟件工程師對需求進行分解，保證增加、修改的需求分配到特定的配置項，同時確保刪除的需求從配置項需求中除去。

5.8 發布升版后的需求文件

文件控制人員發布升版的需求文件。

5.9 變更分解任務執行完成，關閉變更

配置管理員在變更過程中，保持對變更狀態的跟蹤，并在所有變更分解任務完成后，關閉變更。

5.10 發布變更文件

文件控制人員發布變更文件，此文件記錄了此次變更中涉及的所有內容，包括原因、過程、結果。CVS水實體模式控制策略變更全部完成，其理由充分、過程完整、結果正確，從需求到設計、需求到測試具備可追溯性，在保證高效完成任務的同時，為產品的優良質量打下了堅實的基礎。

5.11 CVS控制邏輯與畫面設計

負責CVS系統的控制軟件工程師依據重新分配后的軟件需求，對現有邏輯與畫面設計實現進行修改，維護需求追溯關系，以證明更新后的軟件設計實現可以滿足新需求基線。

5.12 發布升版后的設計文件

軟件工程師應保證提交的設計文件真實完整地記錄了軟件的設計實現過程和結果，文件控制人員發布升版的設計文件。

5.13 修改測試規程重新執行測試

軟件測試人員根據新需求基線設計CVS測試規程，并對新CVS邏輯與畫面重新執行測試。實際執行過程中，軟件測試和設計是一個迭代的過程，迭代的出口是軟件質量評價結果符合業主和設計院提出的要求。

5.14 發布升版后的測試文件

文件控制人員發布升版的測試規程，以及相應的測試報告。

6 結束語

在開展需求開發和管理、配置管理和文件控制的研究基礎上，核電儀控軟件開發組織根據自身的能力水平采取針對性的措施，將有力地支持軟件開發過程。開發過程中，開發組織若能夠及時對軟件質量進行評價，反饋并解決遺留的問題，將持續提升儀控軟件質量和開發組織的能力。