林錦銘（台電公司核能技術處）

摘要: 本文從龍門計畫依循美國核管會（USNRC）管制法規、指引及標準，執行安全系統數位儀控軟體發展之實際經驗來檢視近十餘年來此等法規、指引及標準之演進，並探討其完備性。內容包括龍門計畫安全系統數位儀控軟體發展遭遇的重要議題、美國核管會核電廠安全系統數位儀控軟體管制法規之演進、以及筆者對其完備性提出討論等之說明。

壹、前言

龍門計畫儀控系統採數位化方式，透過軟體來執行整廠之保護、控制、警報及顯示等功能。由於安全數位儀控系統之建置影響核能電廠之安全運轉特性，故龍門計畫所有安全儀控系統軟體之設計、建置、測試及審查等作業，皆須遵循相關軟體管制法規（本文所述之管制法規，包括核能法規、法規指引（R.G.）及其所Endorse之工業標準(如IEEE）等）之要求來執行，以確保其軟體品質及核能安全。

同時，由於近二十年來在美國未有新建之核電廠，因緣際會使得龍門計畫成為許多安全系統數位儀控軟體管制法規之先驅使用者，相關之主要管制法規包括：SRP BTP-14 Rev. 4, 1997年版、R.G. 1.168~1.173, 1997年版、以及IEEE 1028, 1994年版之軟體安全分析（SSA）等。由於管制法規係首次應用，龍門計畫在執行過程中，曾遭遇到因法規之要求不夠明確，導致業主/廠家/管制單位對法規有不同之解讀，因而造成執行上之困擾，例如:軟體安全分析（SSA）之做法、獨立驗證與確認（IV&V）組織之「獨立」的定義等。

美國核管會有鑒於龍門計畫係其數位儀控軟體管制法規首次之應用，特別在原能會及台電業主獨立驗證與確認小組（OIVVT）於2000及2002年赴龍門計畫分散控制暨資訊系統（DCIS）廠家執行稽查時，兩度派員以觀察員（Observer）身分參與，以蒐集第一手資訊，做為檢討改進之用。除此之外，美國核管會亦透過與原能會的合作計畫，繼續蒐集龍門計畫之經驗回饋。經檢視近十幾年美國核管會對數位儀控軟體管制法規所做之增修，已經將龍門計畫之大部分經驗回饋予以納入。

以下將就龍門計畫安全系統數位儀控軟體發展遭遇的重要議題、美國核管會核電廠安全系統數位儀控軟體管制法規之演進、以及新法規有疑義部份，分別提出討論。

貳、龍門計畫安全系統數位儀控軟體發展遭遇的重要議題

龍門計畫安全系統數位儀控軟體從1998年開始執行以來，因有部分法規在核能界係首次使用，故在軟體發展過程中曾發生業主與廠家間對法規要求解讀不同產生的爭議問題。此種現象，一部分原因是由於相關法規與標準本身並未有很明確之要求，或未進一步提供審查指引以供遵循，此外，又因未有前例可供執行參考，乃造成管制單位/業主/廠家對法規與標準所要求之執行方法各自有不同之解讀。本節除了對龍門計畫安全系統數位儀控軟體發展遭遇的重要議題逐一說明其發生之原由與解決辨法外，亦簡要說明新版法規與標準已做之相關修訂，並整理如表1所示：

一、軟體安全分析作業之執行

（一）法規原本之要求

SSA需遵循之法規與標準為IEEE 1228-1994、R.G. 1.173-1997，Rev.0、及BTP-14，Rev. 4。

（二）議題原由與解決辨法

龍門計畫適用之法規與標準（IEEE 1228-1994、R.G. 1.173及BTP-14 Rev. 4）雖然要求應執行SSA，且GE在合約亦有承諾，但由於法規與標準自頒布後並無實際在全數位化之新核電廠執行之前例可供參考，故在SSA執行過程中，即因廠家（GE）/業主（台電）/管制單位（原子能委員會，AEC）對法規與標準所要求之執行方法有不同之解讀；同時，BTP-14亦未訂有明確之審查指引，以致在計畫初期，對GE在SSA之做法未能達成共識。經GE獨立驗證與確認小組（IVVT）聘雇其顧問公司CDA （Computer Dependability Associates）提供諮詢，台電亦聘雇顧問公司MPR提供諮詢，並經冗長的協商討論，終於在2004年5月，GE/台電/AEC三方在台電DCIS會議中，對龍門計畫DCIS儀控軟體SSA之執行方法，達成共識，即對所有安全系統與新發展軟體採「Failure-Based」之假設的風險因子（Hazard）分析。

（三）法規修訂後之要求

美國核能管制委員會於2007年3月，在SRP BTP-14 Rev. 5，第B.3.2.1節增訂軟體各發展階段之SSA的審查指引。依其指引，SSA作業之審查，可依NUREG/CR 6101 1993年版，Section 3.2.2~4.7.1以及R.G. 1.173，Section C3之要求執行。此項增訂雖可解決龍門計畫所發生對SSA執行方法之爭議；但經分析其所提審查指引之方法，相較於加拿大達靈頓核電廠停機系統更新案及龍門計畫安全系統數位儀控軟體SSA之執行，新版所提供之審查指引似較不具有效性，此將於第肆節說明。

二、對法規要求之“獨立”詮釋問題

（一）法規原本之要求

軟體IV&V作業需遵循IEEE 1012-1986、R.G.1.168-1997 Rev.0及BTP-14 Rev.4之要求。

（二）議題原由與解決辨法

龍門計畫GE IVVT是架構在GE核能部門（GENE）之下而獨立（平行）於GE龍門計畫設計團隊，但對於是否符合法規10CFR 50 APP. B、BTP-14及R.G.1.168之規定，因對「獨立」之要求，相關人員有不同的解讀，以致造成執行上的困擾。上述法規之相關要求簡述如下：

1. 10CFR 50 APP. B第3條準則：「…對設計的證實或核對工作，必須由原設計者以外之人員或團體執行之，但可屬於同一機構。…」。

2. BTP-14.1.J節：「…V&V機構是獨立於發展機構。…」

3. R.G.1.168 C.3節：「IEEE 1012-1986未要求獨立執行軟體之V & V，但NRC要求獨立。…V&V的負責人必須獨立於設計的負責人，且此獨立性必須足夠保證V&V程序之執行，在時程（schedule）及資源（resource）方面，不會與設計程序有所妥協。…」。

綜上所述，10CFR 50 App. B並未要求V&V人員完全獨立於發展機構，但BTP-14則要求完全獨立；而依R.G.1.168，NRC亦有要求獨立。由於法規規定散見於多處，且不完全一致，故對GE IVVT是否完全符合獨立之要求，GE與台電業主獨立驗證與確認小組（OIVVT）各自有所解讀。基於此，1999年7月，台電、MPR、GE IVVT及其所聘之顧問公司CDA，特別就「獨立」之議題開會討論，最後一致認同CDA專家對R.G.1.168「獨立」之精神的詮釋，以「目前GE IVVT的負責人是獨立於龍門計畫軟體之發展團隊負責人是可接受…」，做為最後之結論。值得一提的是，台電在龍門計畫初期就曾對軟體IV&V作業在法國、英國之執行情形做過調查，瞭解其重要性；乃特別聘雇MPR公司負責主導及推動，並由台電及核研所派員參與組成業主獨立驗證與確認小組（OIVVT）執行軟體IV&V工作。故在實質上，除符合法規對獨立性之要求外，也紓解大家對GE IVVT執行軟體V&V獨立性之疑慮。

此外，因BTP-14在軟體發展生命週期所要求產出之大量軟體，包括設計輸出文件及SSA與V&V等報告須執行獨立審查，台電亦另委請核研所全程參與軟體各階段輸出文件之審查，亦是執行獨立IV&V作業之一部分。

（三）法規修訂後之要求

IEEE 1012-1998之附件C對IV&V之作業增訂有關技術（Technical）、管理（Managerial）及財務（Financial）之「獨立」的定義，做出更明確之說明與要求。同時，各相關新法規、指引及標準亦交互參酌對獨立之定義及執行的方法，使各法規間對要求更趨一致（Consistency）。

三、透過軟體工具執行軟體發展

（一）法規原本之要求

安全系統軟體發展之生命週期需依BTP-14 Rev.4與R.G.1.173-1997 Rev. 0及其Endorse之IEEE 1074-1995之要求執行。

（二）議題原由與解決辨法

美國核管會所頒布安全系統軟體發展之生命週期需依SRP BTP-14之要求執行，即需從軟體需求、軟體設計、編寫程式碼與單元測試、軟體整合測試，到確認測試各階段，逐步執行其軟體發展作業。

但龍門計畫ESF安全系統之軟體建置廠家DRS，在其軟體建置過程，係先將GE所發行之ESF系統之控制邏輯圖（CLD），透過軟體工具（OrCAD）轉換為功能連接圖（FID），再透過DRS依安全等級軟體要求所發展之PLuS 32平台系統FID編譯器（Compiler），直接翻譯為C語言之原始程式碼後，燒製在EPROM成韌體，再執行FID測試，即完成系統功能之測試。此FID之建置程序，因跳過BTP-14所述之軟體設計、編碼及單元測試階段，而未能完全依BTP-14所要求之軟體生命週期各階段逐一執行。

對此議題，管制單位特別關注，且要求台電解釋如何符合BTP-14要求。台電從DRS FID之建置及其V&V作業、現階段核能工業界之作法、以及如何符合BTP-14要求及建議等，詳加說明，為原能會所接受後，此議題才告結案。

（三）法規修訂後之要求

新法規除要求軟體工具需執行V&V作業外，對此議題並未有更具體的法規要求或審查指引供遵循。

四、軟體工具之V&V作業

（一）法規原本之要求

軟體工具之V&V作業需遵循R.G. 1.152 Rev.1及其Endorse之IEEE 7-4-3.2 1993之要求執行。

（二）議題原由與解決辨法

GE NUMAC所發展之安全系統軟體係採傳統發展模式，從軟體需求、設計、編碼、測試一路下來，其V&V之程序均依傳統V&V模式執行，故沒有不符合法規的問題。但DRS承包之安全系統ESF軟體，因係採OrCAD之軟體工具，將GE所發展之控制邏輯圖（CLD），直接轉換為FID，再透過DRS所發展之FID Compiler轉換為C Code，故執行ESF軟體產品之V&V時，除應執行確認（Validate）測試，以確保最終軟體之功能能正確被執行外，是否亦需對OrCAD執行V&V，以確保其軟體發展過程使用工具之可靠性，乃成為一項重要的考量。

在IEEE 7-4-3.2 1993第5.3.3節述及：「對軟體工具是不須執行V&V工作，因為用軟體工具所發展之軟體產品仍能透過V&V而找出軟體工具所產生之瑕疵。」。但依10CFR 50 APP. B第3條準則：「…同時對結構、系統和組件的安全功能有重大影響的材料、零件、”設備”，以及製程的選擇與其適用性之審查，亦需”建立管制辦法”。…」；第10條準則：「…對製程中之材料或產品若無法或不利於執行檢驗時，可藉監視”製造方法”、”設備”和人員予以”間接管制”。…」。此二條準則中之說明，其語意皆有隱含對軟體發展之軟體工具應以「建立管制辦法」與「監視製造方法、設備予以間接管制」方式來執行V&V作業之要求。在龍門計畫對是否應對OrCAD執行V&V雖無定論，惟DRS在龍門計畫對OrCAD及其它相關之軟體工具均有依照DRS所提之DRS Software Tools V&V Plan (ER7348/54)執行軟體工具之V&V作業，此為較嚴謹的做法。

（三）法規修訂後之要求

IEEE 7-4.3.2 1993年版僅要求軟體工具要在構型管理（CM）下Identify及Control，並未要求執行Witness、Review 及 Testing之V&V作業。2003年版要求對在發展及V&V程序所用之軟體工具要執行下述任一方法：

1. 發展一個測試工具之確認計畫（test tool validation program），以對所要求的軟體工具之功能，提供其應具備之性能的信心。

2. 在軟體發展作業，如有使用軟體工具而有軟體工具未偵測出之瑕疵（defect）時，在V&V作業必須有偵測出此瑕疵的方法。

至此，新法規對軟體工具須執行V&V作業已有明確之規定。

五、軟體評量（Metrics）

（一）法規原本之要求

軟體評量須遵循SRP BTP-14 Rev.4軟體計畫書階段之建置特性中所列之量測（Measurement）。

（二）議題原由與解決辨法

原能會對數位儀控之軟體發展提出之注意改進事項中，以編號AN-LM-90-11-3，要求在DCIS軟體品保各階段審查所發現各種缺失紀錄，進一步進行統計分析，以明瞭缺失處理，並要求加強注意軟體品質量測（Measurement）之正確性、代表性等之考量。

SRP BTP-14 Rev.4在軟體計畫書階段之建置特性中所列之量測（Measurement），是要求對各項不同之軟體作業（如V&V、CM、SSA、QA等）有一指標（indicator）做為決定執行各種不同軟體作業之effort是成功，抑或失敗。其主要做法是系統化蒐集與分析各軟體作業之相關資訊，來決定各軟體作業之品質，以及是否有效（Effectiveness）。除此之外，並未提供明確的指引或標準供遵循或參酌。

1. 龍門計畫對軟體評量之執行

(1) 台電OIVVT赴GENE及其協力廠家執行現場稽查時，特別針對軟體發展品質之評量（Metrics）做法，要求廠家提出說明，並進行實地查核後，經整理說明如下表：

廠家 軟體型式	Invensys	GEIS	NUMAC	DRS	IVVT
平台系統 應用系統	ü(1) ü(2)	ü(1) ü(2)	ü(1) ü(1)	ü(3) ü(3)	ü(1) ü(1)

註 1：表示用不同的評量方法執行

2：表示採用定性的（qualitative）評量，即透過類似：

(A)  差異報告（DR）：解決外部發生之缺失（errors），如GE之設計輸入（邏輯圖）。

(B) 內部驗證審查記錄（VRR）：解決軟體發展廠家內部產生之缺失，如程式碼錯誤。

來追蹤與解決軟體建置過程中之缺失。

3：DRS為配合申請SEI CMM-I第3級之資格，2003年4月以後，開始執行軟體評量。在此之前的軟體發展缺失，是遵循DRS NQA軟體品質保證計畫去追蹤與解決。

(2) 針對各軟體發展廠家之評量做法，MPR特別執行Thread Audit，其報告為：「TAR-MGMT-005, Use of Metrics in Software Design Organization」，其結論為：

A.定量的（Quantitative）評量較適用於現有計畫所執行之軟體發展計畫、程序及設計輸入與以前之計畫相類似者。因其較易於互相比較，且缺失之追蹤有過去歷史資料來比對，將會更具說服力。

B.平台系統之發展，因每個計畫之變動不大，且具有上述第1項特質，同時，大部分用程序化（Procedural）的語言來建置，如”C”語言。故用定量評量來評估品質之趨勢較適切。

C.應用系統（特定為龍門計畫）之發展，因其每個計畫之差異性較大，故採定性評量來評估其品質較適當。同時，龍門計畫大部分廠家採用繪圖工具來建置軟體與畫面，故評量用於平台系統之程序化方法，要轉化為用在應用系統之圖型化上，並不適當，因兩者發生缺失之背景不盡相同，很難用同一基準比較。故各廠家之應用系統，採用其軟體品質計畫之缺失追蹤方法所執行之定性評量，應可接受。

D.經上述評估，OIVVT結論為龍門計畫軟體發展廠家與IVVT之評量做法與缺失追蹤具有效性，應可保證其發展程序可控制且可提供高品質之軟體，故其做法應可接受。

最後，台電依NUMAC、DRS、Invensys及GEIS各廠家所提之定性與定量的軟體評量資料送管制單位審查，並獲原能會准予核備。

（三）法規修訂後之要求

法規經修訂後，SRP BTP-14 Rev. 5有關軟體評量（Metrics）之要求是在C.3.1節計畫書驗收準則有關量測（Measurement）中說明，其要求參照：

1. R.G. 1.152 Endorse IEEE 7-4-3.2 2003，Clause 5.3.1.1，以及

2. IEEE 1061-1998“IEEE Standard for Software Quality Metrics Methodology”，以及

3. R.G. 1.173 Endorse IEEE 1074-1995，Clause A.1.1.4、A.1.3.5及A.5.1.1.2包含有關Metrics可接受的方法。

因此，除SRP BTP-14 Rev. 5有明確之審查指引供參酌外，同時各相關新法規、指引及標準之要求更趨一致。

六、GE IV&V作業之評量

（一）法規原本之要求

軟體V&V作業之評量須遵循SRP BTP-14 Rev.4軟體計畫書階段之建置特性中所列之量測(Measurement)。

（二）議題原由與解決辨法

有關V&V作業之評量在BTP-14 Rev.4之3.1.j節，軟體V&V計畫書之量測（Measurement）提出其驗收準則，但1986年舊版之IEEE 1012並未有任何要求。台電依原能會所開列龍門計畫注意改進事項，編號為AN-LM-90-11-3之要求，要求GE IVVT提出其對IV&V作業之評量如下:

GE IVVT是以其審查文件之「有效性（Effectiveness）」與「效率（Efficiency）為評量的指標項目：

(1) 效率: No. of Substantiated Anomalies/Total No. of Closed Anomalies(表IVVT之審查效率)

(2) 有效性：No. of Closed Anomalies/Total No. of Anomalies, 此Anomalies指IVVT審查時所提之意見。（當IVVT接受由設計團隊Resolution時表示一個Anomaly已結案，故此有效性表示IVVT之作業有效地解決設計程序之問題。）。

（三）法規修訂後之要求

法規經修訂後，除SRP BTP-14 Rev. 5有關軟體評量（Metrics）之要求在C.3.1節計畫書驗收準則有關量測（Measurement）中有說明外，IEEE 1012 1998年新版Annex E V&V Metrics，亦有要求應考慮兩個評量類別，即：

1. 評估軟體發展程序與產品的評量。

2. 評估V&V作業之結果，以及改進V&V作業品質與涵蓋度（Coverage）之評量。

參、美國核管會核電廠安全系統數位儀控軟體管制法規之演進

核電廠安全系統數位儀控軟體採用之法規，包括R. G. 1.152、R.G. 1.168~1.173及其各自Endorse之工業標準（IEEE Standard），以及標準審查指引（SRP）第7章BTP-14 Rev.4等。近幾年美國核管會為配合工業標準之進版，以及針對數位科技應用在核能界的研究、軟體安全之考量，與從核能界回饋經驗等，而對相關法規做了部分的增修，並發行新的版本供業界遵循。經觀察核電廠安全系統主要使用之數位儀控軟體法規，大約每10至12年會更新一次。以下將就上所述已有增修且較為重要議題之相關法規、指引以及工業標準的內容做一說明：

一、IEEE 7-4.3.2-2003年版（舊版為1993年版）

在此將本工業標準新版增修的部分，摘錄如下：

（一）第5.3節,有關品質（Quality）部分

1. Software development:

對於有關軟體之發展、修改或驗收須遵循的法規是由IEEE/EIA 12207.0-1996取代舊版所列ASME NQA-2a-1990，Part 2.7及ASME NQA-1-1989之要求。

2. 增加軟體品質評量（Software Quality Metrics）：

要求參照IEEE Std. 1061-1998 (Software Quality Metrics Methodology)執行。

3. 增加對軟體工具之V&V作業。

2003年版要求對在發展及V&V程序所用之軟體工具要執行下述任一方法：

(1) 發展一個測試工具之確認計畫（test tool validation program），以對所要求的軟體工具之功能，提供其應具備之性能的信心。

(2) 在軟體發展作業，如有使用軟體工具而有軟體工具未偵測出之瑕疵（defect）時，在V&V作業必須有偵測出此瑕疵的方法。

4. 驗證與確認（V&V）：

將舊版附件（Annex）E之V&V拿掉，並要求V&V作業依IEEE 1012 1998年版執行，同時對技術、管理及財務獨立（Independence）之要求亦同。

5. 增加軟體計畫案風險管理（Software Project Risk Management）：

除在本節列出7個風險管理的步驟外，並參照IEEE 1540-2001(Life Cycle Process Risk Management)之風險管理及IEEE/EIA 12207.0-1996之軟體生命週期程序。

（二）第5.4節，有關設備檢定（Qualification）部分

將舊版5.3.1節，商業級電腦檢定移到新版之5.4.2節，並在本標準之附件C，商業級電腦檢證（Dedication）內更完整說明商業級之架上軟體（COTS）議題。

（三）第5.5節，有關系统完整度（System Integrity）部分

此章節除原有之電腦完整度之設計以及測試與校正之設計外，增加故障偵測與自我診斷之要求。

（四）危險因子分析（Hazard Analysis）

舊版之附件F，有關異常狀況事件（ACE）之辨識與解決方法，在新版之附件D，改為危險因子之辨識與解決方法。同時，舊版之ACE內容亦被納入在新版之系統生命週期危險因子辨識章節內，且此2003年版本增加危險因子之迴避（Avoidance）、危險因子之辨識與評估、以及危險因子之解決方法三個部分。

（五）因在IEEE 603-1998之Annex B已有說明相同之EMC主題，故2003年之新版將1993年版之附件C, Electromagnetic Compatibility (EMC)移除。

二、R.G. 1.152-2006年版 Rev.2（舊版為1996年版 Rev.1）

此指引是Endorse IEEE 7-4.3.2-2003年版，特別在管制立場增加數位安全系統資安指引（Security Guidance）

（一）IEEE 7-4.3.2 2003未提供電腦化系統設備與軟體系統有關資安量測（Security Measure）之指引。而在RG 1.152 Rev.2之C節管制立場，提供電腦化安全系統軟體生命週期在概念、需求、設計、建置、測試、安裝與驗收測試、運轉、維護到除役階段，各階段之資安管制立場。

（二）此載於R. G. 1.152 Rev. 2之資安指引，是符合Digital I&C-ISG-01 Cyber Security Associate with Digital I&C要求，可作為核電廠在發展與建置電腦資安計畫或設計、製造、執行或安全系統更新時之參考依據。

三、IEEE 1012-1998年版（舊版為1986年版）

本工業標準新版增修的部分，摘錄如下：

（一）訂出四個軟體完整度層級（software integrity levels，分High、Major、Moderate、Low）以提供V&V作業分級處理。同時，對四個軟體完整度層級訂出各層級至少應執行之V&V工作。

（二）訂出V&V工作（Task）之執行準則（detailed criteria)如completeness、correctness
、consistency、accuracy、 testability等。

（三）以系統觀點在生命週期V&V作業增加危險因子分析（Hazard Analysis）、風險分析（Risk Analysis）及Migration Assessment。並在概念、需求、設計、建置、運轉與維護階段增加關鍵分析（Critical Analysis）。

（四）增加符合國際及IEEE標準之對照表，如ISO/IEC Std. 12207、IEEE Std. 1074-1997、以及IEEE/EIA Std. 12207-1996之軟體工程發展標準。

（五）對IV&V作業增加取得（Acquisition）及供給（Supply）兩階段工作，以確保安全系統如分散在不同廠家執行時，其IV&V作業之完整性。

（六）增加6個附件（Annex），以提供建置此標準之有用的資訊，簡述如下：

1. 提供ISO/IEC Std. 12207及IEEE Std. 1074-1997、V&V Requirements與IEEE 1012 1998之V&V Activities and Tasks之對照表。

2. Software Integrity Level Scheme

提供四個軟體完整度層級之定義，以及說明每個層級軟體錯誤之後果（分Catastrophic、Critical、Marginal及Negligible）。

3. IV&V獨立之定義

此附件對執行IV&V程序之組織與軟體發展組織在技術、管理及財務上之獨立的精神有更明確之訂定。同時，依IV&V 之Classical、Modified、Internal及Embedded四個等級的型態（Type）來決定在技術、管理及財務上之獨立的程度。

4. 可再使用（Reusable)）軟體之V&V作業

可再使用軟體是指software libraries、PDS、Legacy software及COTS。其V&V工作與新發展的一樣，但如果有些資訊，如原始程式碼及文件，無法取得時，可用許多方法取得，如稽查的紀錄、運轉的經驗、及Engineering Judgment等。若可再使用軟體之V&V無法適切地實施，只要能辨識出使用時之相關風險，以及說明風險之緩和（Mitigation）策略，則也可被使用。

5. 軟體V&V作業之評量（Metrics）

軟體V&V作業評量應考量2個評量的類別：

(1) 評估軟體發展程序與產品的評量。

其附件E列出14個評量項目供參照使用，例如修改之數量、瑕疵之種類（Defect Category）、發展期間偵測到之瑕疵、全程所發現之瑕疵數量等。故並無標準之評量項目組合可被用在所有計畫案。因此，評量的使用也可依應用之領域以及軟體發展環境而有所變化。

(2) 評估V&V工作之結果，以及改進V&V工作品質與涵蓋度（Coverage）之評量。

目前V&V工作之評量沒有共識，其大致可分為：

A. V&V品質：量測V&V工作之品質及有效性（The Ratio of number of defects identified by V&V to the Number of defects missed）。

B. V&V涵蓋度：量測V&V應用之程度（extent）與廣度（Breadth)（The Ratio of the number of software modules verified to the total number of modules）。

6. V&V組織、計畫與其他組織之責任

此說明V&V組織、發展組織及Users（監督或委員會）間之相互間的角色與責任。

四、R.G. 1.168-2004年版 Rev.1（舊版為1997年版 Rev.0）

此指引是Endorse IEEE 1012-1998年版，以下就舊版之NRC管制立場（Regulatory Position）有增修之部分提出說明：

（一）關鍵軟體（Critical Software）

IEEE 1012-1998新版定義關鍵軟體為4個層級（High、Major、Moderate、Low），核電廠安全系統軟體是第4級最高。而舊版僅訂定關鍵軟體與非關鍵軟體（Critical software、Non-critical software）兩種。

（二）軟體可靠度（Software Reliability）

在本指引新版NRC staff接受電腦化安全系統之量化可靠度目標是對整個電腦系統（包括硬體、系統軟體、Firmware、應用程式及相互連結）用Deterministic Criteria來預測。而與舊版所述之NRC Staff不推薦量化可靠度的觀念做為符合數位電腦使用在安全系統之唯一的方法有些許不同的態度。

（三）軟體V&V之獨立的定義

本指引之新版Endorse IEEE 1012-1998，對於建立軟體V&V作業有關技術、管理及財務上之獨立性以符合10 CFR 50 App. B Criteria I（管理及財務）及Criteria III（技術），較舊版對技術、管理及財務上之獨立的精神有更明確與清楚的闡述。

（四）資安評估（Security Assessment）

NRC Staff考量對於安全系統軟體之資安評估，在V&V之作業是視為最基本應執行的工作（Minimum set），此項為新增。

五、SRP BTP-14-2007年版 Rev.5（舊版為1997年版 Rev.4）

在新版各章節所有審查須遵循之說明皆較舊版更明確，並指出須遵循之法規、標準或指引（如R.G.1.168~1.173及NUREG/CR 6101等）。以下將新版增修之相關部分加以整理，並集中說明：

（一）舊版第2節，與被審查之資訊（Information to be reviewed）有關：「請照者勿需為每個主題（Topic）發展一個各別（Separate）的文件，然而，計畫案（Project）的文件應涵蓋所有的主題…」。這一段說明被删除，是否意謂新版與舊版要求不一樣，即每個主題各需一份文件，但新版並未加以說明。

（二）在此新版特別增加有關軟體測試作業，說明如下：

1. 在B.2.1節軟體生命週期計畫書階段，增加軟體測試計畫書，並在B.3.1.12節增加軟體測試計畫書審查的驗收準則。

2. 在B.2.2節軟體生命週期建置階段增加軟體測試作業（原僅有SSA、V&V、及CM），並在B.3.2.4節增加軟體測試作業審查之驗收準則。

3. 在圖7-A-1，軟體生命週期文件流程圖，未列出軟體測試計畫書。同時，在此圖有關程序作業（Process Activities），亦未顯示軟體測試作業。

（三）在新版第B.3節，增加對法規指引（Regulatory guides）之符合性（Conformance）說明，即：

1. 部分符合（Partial Conformance）：以計畫書為例子，如格式符合（Format Conformance），係指計畫書符合特定之格式。內容符合（Content Conformance），係指完成指引所詳述之所有內容，但勿需顯示特定之格式。

2. 完全符合（Complete Conformance）：如完全符合一個法規指引，僅要求審查者決定是否已達成符合性，同時系統是安全的。

（四）在第B.3.1節，在計畫書階段之驗收準則增加多個廠家（Multiple Vendor）與多份計畫書文件之問題的說明:

1. 未來之核電廠可能有多個廠家參與電廠數位儀控系統與相關軟體之設計與建置，計畫書文件以及不同廠家有關之建置作業應由負責電廠計畫案設計的主要廠家（Principal Vendor）協調。其中在不同廠家之系統的介面需求，以及系統的整合是特別的重要。

2. 有可能請照者（Applicant）/持照者（Licensees）在硬體、軟體或系統發展與一個廠家簽約。在此情形，也許有兩組計畫書文件，一組為請照者/持照者，另一組為廠家研擬。依10 CFR 50 App. B說明，持照者可代表其它的人，比如合約商、代理人、或顧問，建立與執行品保計畫工作，或任何有關此部份，持照者應為此保留責任。同時，對於執行影響結構體（Structure）、系統及組件安全有關功能作業之組識與個人的權利與責任，應很清楚地建立與劃分，並記錄之。

3. 上述之意義是請照者/持照者將需一個保證適當之品保計畫被建立且有效的執行的方法，以及一個驗證的方法。比如透過查核、稽查、與檢視其已正確地執行會影響安全有關功能之作業。

4. 在請照者/持照者與一個廠家簽約情形下，有兩組計畫書文件應被一起審查，以確保不僅廠家執行妥當的作業，同時請照者/持照者亦有保證正確地完成這些作業的方法。

（五）有關計畫書及設計輸出階段審查之驗收準則的增修:

1. 在第B.3.1節，計畫書階段驗收準則增加計畫書文件在管理、建置及資源3個特性審查之驗收的一般指引（General Guidance），其對驗收準則之要求更為明確（因引用R.G.、NUREG、IEEE等）。如資安（Security）需遵行R.G.1.152 Rev.2之資安要求。

2. 在各計畫書文件（SMP、SDP、SCMP等）驗收準則章節內，除與舊版一樣針對該計畫書文件在管理、建置及資源3個特性審查外，皆特別增加審查該計畫書文件指引，以強調其審查目的、執行審查的方法，及應注意事項等，如在第B.3.1.1.4 SMP審查指引。

3. 在第B.3.3節，設計輸出階段之驗收準則章節與上列1及2項目所述一樣，僅審查的對象改為設計輸出文件（Design output documentation），如SRS、SAD、SDS、Coding等。

（六）有關SSA新增之驗收準則

1. 在第B.3.1.9節，SSA計畫書階段審查之驗收準則，增加SSA各階段作業之審查指引，其適當之軟體安全分析作業是依NUREG/CR 6101 Section 3.2.2~4.7.1，以及R.G. 1.173 C3之要求執行審查。

2. 在第B.3.2.1節，SSA作業之審查的驗收準則也增加需考慮電腦資安風險（Cyber Security Risk）作業。

（七）在第B.3.2.2節，對於V&V作業之審查，其驗收準則也增加審查者必須執行循線稽查（Thread Audit），對於軟體需求及軟體程式碼之循線稽查最少應取樣約5%。

（八）軟體評量（Metrics）在新版計畫書階段之建置特性量測（Measure）部分參照：

1. R.G. 1.152 Endorse IEEE 7-4-3.2 2003，Clause 5.3.1.1

2. IEEE 1061-1998“IEEE Standard for Software Quality Metrics Methodology”。

3. R.G. 1.173 Endorse IEEE 1074-1995，Clause A.1.1.4、Clause A.1.3.5,以及Clause A.5.1.1.2，包含有關Metrics可接受的方法。

4. 在舊版是在計畫書階段之建置特性中，依各種軟體計畫書列出各所要求之量測（Measurement）來說明。

肆、新法規之探討與建議

本節將以筆者個人觀點，從龍門計畫安全系統數位儀控軟體發展之經驗，來探討新修正之相關法規、指引及標準等之完備性。並整理於表1之「新法規之意見」欄所示：

一、新版SSA所要求之審查指引仍不夠有效性（Effective）

SSA主要目的是指評估軟體在其「假設失效」下，不會影響系统之安全。

1. BTP-14 Rev.5第B.3.2.1節增加SSA各軟體階段之分析的審查指引，其可參考NUREG/CR 6101，1993年版節第3.2.2~4.7.1節所列之分析方法，與透過查核表查對。其大部分僅針對「安全關鍵」項目再做一次查驗，內容與執行V&V作業類似，無法達到SSA作業之效果。

2. 龍門計畫SSA之做法為「假設失效」情況下，以失效模式及影響分析（FMEA）方法，對所有安全糸統及新發展軟體之各軟體生命週期階段，執行危險因子分析（Hazard Analysis）。

3. 加拿大達靈頓（Darlington）核電廠停機（Shut down）系統之更新案所執行之危險因子分析，是以FMEA的方法，來辨識影響功能之系統的危險因子。接著，將此危險因子，做為故障樹（FTA）最高層事件（Top Event），再以故障樹（FTA）分析方法，得到潛在之失效模式，並找出安全關鍵的變數。最後，對此失效模式及安全關鍵的變數，加入保護裝置（Safeguard），以保證所辨識出之危險因子不會出現，增加軟體程式之信心。

從上瞭解龍門計畫及加拿大達靈頓核電廠危險因子分析之做法，相較BTP-14 Rev.5參酌NUREG/CR 6101之類似V&V方法，在SSA的目的上更具有效性。

二、新法規未對採用軟體工具執行軟體發展提出新的指引

拜數位科技之進步，龍門計畫軟體發展廠家中，如DRS及Hitach等公司，皆採用軟體工具執行軟體之設計及建置，跳過BTP-14所述之軟體設計、編碼及單元測試階段，而未完全依BTP-14所要求之軟體生命週期各階段逐一執行。但至目前為止，新法規除要求軟體工具須執行V&V作業外，對此議題並未有更具體的法規要求或審查指引供遵循。

三、新版IEEE 1012-1998 V&V作業之內容有錯誤之處

經查IEEE 1012-1998年版，其表1內第5.4.3節，有關設計V&V作業之正確性（第2.1項）及一致性（第2.2項），兩項所述及原始程式碼組件（SCC）均須更正為軟體設計說明（SDD），而有關軟體設計（SD）部分須更正為軟體需求（SR）。其原因為，此章節之要求係針對設計階段之V&V作業，而非建置（程式編碼）階段之V&V作業。

四、IV&V財務之獨立未明確說明是否可在計畫團隊之下

在新版，對IV&V作業在財務上之獨立，僅述及「要求控制IV&V預算（Budget）之組織要與發展組織獨立」，但未明確說明是否需與計畫案（Project）之管理的組織獨立？因發展組織是由計畫案之負責的人所管理及提供預算，若IV&V組織之預算也由計畫案之負責人所控制，有可能會影響IV&V作業之工作範圍以及選擇特定之技術議題與問題之執行等，造成其獨立性不足。此財務之獨立是預防IV&V Efforts會因為預算受IV&V管理組織所牽制，有可能造成無法「獨立」地完成其想要執行的分析或測試，以及移送適切之結果的立場。

五、BTP-14 Rev. 5內容之疑義

1. 計畫書與設計輸出文件之主題與內容
　　BTP-14 Rev.5，第B.2節，已將舊版之要求:需被審查之資訊（information to be reviewed）所說明之「請照者勿需為每個主題（Topic）發展各別（Separate）的文件，然而，計畫案（Project）的文件，應涵蓋所有的Topics…。」。這一段說明已被移除，此是否意謂每個主題各需一份文件？新版未有明確的說明。

2. 內容與圖表之內容不一致

A.    在B.2.1節軟體生命週期計畫書階段，已增加軟體測試計畫書（STP），但在圖7-A-1未列出。

B.    在B.2.2節軟體生命週期建置階段，增加軟體測試作業（原僅有SSA、V&V及CM），但在圖7-A-1，卻未顯示出來。

六、增修部分皆為正面且有意義

除上所討論之項目外，其餘在本文第參節所述及增修的部分，都已補充舊版法規不足之處，特別是BTP-14 Rev. 5，對於在一個計畫案有多廠家與多份計畫書文件之要求，以及IEEE 1012-1998對IV&V作業增加取得（Acquisition）與供給（Supply）兩階段之作業，使對軟體發展及IV&V作業考慮得更加周詳。同時，各法規、指引及標準間之規定與要求也已經較有一致性（Consistency）。

伍、結論

本文從龍門電廠引用美國核管會管制法規發展數位儀控軟體之經驗，來說明其要求不明確所衍生之議題的原由與解決辨法,以及新法規修訂後之要求，並整理出美國核管會核電廠安全系統數位儀控軟體近十餘年來相關法規、指引以及標準之增修主要內容。最後，再對新法規之完備性及有疑義部分提出討論。

有關上述所討論新增修之相關法規、指引以及標準，除尚有未訂定或不明確的部分，需美國核管會提供更明確之指引供參酌及遵循外，其它在龍門計畫執行時曾遭遇之不足、有爭議或不明確的部分，均已增修補充，使得今後業主/廠家/管制機構在作業之執行上更為便利，不至因各有不同之解讀，增加執行上之困擾，而造成業主/廠家在發展時程上之延宕。

當然，核能法規因涉及生命與財產之社會安全的考量，以致在面對數位科技之快速發展，而有較保守之做法，無法與時俱進，其來有自。但從龍門計畫執行之經驗顯示，法規之不明確或不足之處，確實會造成執行上之困擾。業主及廠家的立場，當然希望管制單位可提供合理且明確之指引，以供遵循，否則，不只是業主/廠家有執行上之困難，連管制機構也因需為不明確或不足之處做個案審查，曠日費時，亦增加其本身額外之負擔。

陸、參考文件

1. R.G.-1.152, Rev.2, “Criteria for Use of Computers in Safety Systems of Nuclear Power Plants”, Office of Nuclear Regulatory Research, U.S. Nuclear Regulatory Commission, 2006.

2. R.G.-1.168, Rev.1, “Verification, Validation, Reviews, and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants”, Office of Nuclear Regulatory Research, U.S. Nuclear Regulatory Commission, 2004.

3. BTP-14, Rev. 5, “Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems”, USNRC, Washington D.C., USA, 2007.

4. IEEE Std. 1012-1998, “Standard for Software Verification and Validation”

5. IEEE Std. 1228-1994, “Standard for Software Safety Plan”

6. IEEE Std. 7-4.3.2-2003, “Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations”

7. NUREG/CR-6101-1993, “Software Reliability and Safety in Nuclear Reactor Protection Systems”

表1：龍門儀控軟體議題與解決辦法以及新頒法規意見之彙總表

 

< 上一則

下一則 >