林錦銘
台電公司核能技術處
摘要: 本文為討論如何執行核電廠安全系統數位儀控軟體驗証與確認（Verification & Validation, V&V）作業，以確保核電廠安全系統數位儀控軟體之品質。故，對軟體獨立V&V (IV&V) 作業之規劃與執行，包括所需遵循之法規與標準、執行V&V之獨立性、V&V作業之執行與審查(驗收)準則等提出探討，進而介紹國內外核電廠執行IV&V之作法，並由龍門計畫執行IV&V之經驗，提出需考量之相關事宜，供安全級儀控系統將來在舊廠之更新與新建核電廠參酌，以增進IV&V工作的效能與工期之掌握，進而確保核電廠運轉之安全與順利。
壹、前言
新一代輕水式反應器之設計要求採用數位化儀控系統，其理由是採用數位化較傳統類比式在資訊、控制及保護方面能提供更精確及廣泛服務，在信號處理方面對複雜功能可有更快及更短之反應時間，在數位設備方面可在線上即時測試、校正且不會因老化問題而造成漂移．．．等優點。但，並非數位系統就沒有缺點存在，目前較重要問題之一就是軟體可靠度的量測問題，其無法採用傳統硬體之機率方法來決定其可靠度以確保軟體之品質。故，現歐美的法規對數位軟體在設計與建置可靠度的信心上，是採用限定的(Deterministic)方法，即執行軟體驗証與確認的方法來提高對其軟體可靠度之信心。
軟體 V&V 目的是幫助軟體發展組織在軟體生命週期建立軟體品質，即在軟體發展過程中，V&V作業是透過〝驗証〞來檢視其功能是否為所需要的，即執行正確的功能。另透過〝確認〞去測試、評估是否能符合當初所要求的功能，即所要求的功能能正確的被執行，進而提供正確而又可追蹤之品管文件以支援系統之運作。目前法規與標準即朝此方向發展， 最後目的是在獲得一可靠的品質。同時，其目標是對軟體的錯誤可較早偵測及矯正，並加強程序之洞查力(insight)與產品風險的管理，進而支援軟體生命週期程序以確保符合計畫之效能、時程及預算的需求。
以下各節將就軟體IV&V作業之規劃與執行，國內外(龍門計畫、日本KK 6&7與英國Sizewell B)核電廠IV&V之作法，以及從龍門計畫執行IV&V之經驗提出建議，分別提出討論。
貳、軟體IV&V作業之規劃與執行
本節將對核電廠安全系統數位儀控軟體IV&V作業需遵循之法規與標準、IV&V之獨立性、以及IV&V作業之執行與驗收(審查)準則等重要項目來討論：
一、IV&V之法規與標準
IV&V需遵循之法規與標準為
1. IEEE Std. 1012-1998, “Standard for Software Verification and Validation”
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. 7-4.3.2-2003, “Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations”
5. NUREG/CR-6101-1993, “Software Reliability and Safety in Nuclear Reactor Protection Systems”
歐洲之法規與標準為
1. IEC 60880-2006 “Software for Computers in the Safety Systems of Nuclear Power Stations”
二、IV&V之獨立性
依IEEE 1012-1998之附件C對IV&V之作業增訂有關技術(Technical)、管理(Managerial)及財務(Financial)之「獨立」的定義，做出非常明確之說明與要求，摘錄如下:
(一) 技術獨立：
對於技術獨立，指執行V&V的人是不能涉及軟體發展者。同時，用來執行IV&V作業之工具(軟體)及技術不能與發展者的工具一樣。但電腦支援環境(如compiler, Assembler, Utility)或系統模擬共用之工具是可被允許，因要採用不同之工具其花費太過昂貴。同時，如果要共用軟體工具， IV&V小組要對軟體工具執行Qualification Test以確保共用之軟體工具不會有瑕疵。
(二) 管理獨立：
管理的獨立，即在組織上負責IV&V作業的人要與發展(Development)及計畫案(Program)之管理的組織分開。管理的獨立也意謂IV&V工作可獨立的選取軟體段落及系統來分析與測試、選擇IV&V技術、定義IV&V作業之時程以及選取特定之技術議題與問題執行。IV&V應適時提供它的Findings給發展與計畫管理組織。最後，IV&V Effort必需不受發展組織之任何限制或負面壓力之下提出IV&V結果、異常事項以及Findings給計畫管理組織。
(三) 財務獨立：
要求控制IV&V預算之組織要與發展組織獨立。此財政之獨立是避免因預算之掌控偏離，而有負面之財政壓力的影響，造成IV&V無法完成它的分析與測試或移送適切之結果的立場。
同時，對於IV&V作業執行之等級，可分Classical、Modified、Internal及Embedded四個等級的型態來決定在技術、管理及財務上之獨立的程度。對於核電廠安全級系統軟體之IV&V屬最高之Classical等級，其執行IV&V之組織【如供給廠家(Supplier)】與發展之組織【如其下包廠家(Another Vendors)】是完全分開，即技術、管理及財務皆需符合獨立之要求。
最後，其它涉及軟體IV&V相關指引與法規，如R.G. 1.168及BTP-14等，亦依此IEEE 1012-1998所訂定之「獨立」的定義交互參酌，使得對軟體V&V獨立之定義以及執行方法的要求上，在各法規間更趨一致性(Consistency)。
三、IV&V作業之審查準則與執行方法
安全系統軟體獨立V&V作業除需遵循相關法規與標準之要求外，部份需視其計畫案之複雜度、範圍及目的等而有不同程度之作法。下將簡述法規與標準所要求之基本的審查準則與執行方法以及執行的對象及其它。
(一)審查(驗收)準則
軟體IV&V作業審查準則，大致可依下述二個方式：
1. BTP-14 Rev.5:
依BTP-14 第B.3節，對軟體計畫書、建置及設計輸出所述之驗收準則執行審查。但此BTP-14亦告知可參酌其Endorse之NUREG/CR-6101-1993, “Software Reliability and Safety in Nuclear Reactor Protection Systems” 所對應相關章節之查對表執行審查。
2. IEEE 1012-1998:
依IEEE 1012-1998第5節V&V Process及表一所列各軟體V&V階段需執行之分析與評估作業執行審查。IEEE 7-4.3.2-2003第5.3.3節所述之V&V作業及工作亦是參考IEEE 1012-1998之要求執行。
(二) 執行方法
軟體生命週期之軟體發展包括軟體需求、軟體設計、編碼與單元測試、整合測試及確認測試等階段。為了確保每軟體發展階段之軟體品質，則可透過驗証與確認(V&V)的方法來執行。此「驗証」是透過文件審查或軟體工具查對本階段之設計輸出與上階段之需求是否一致；而「確認」是透過測試的方法來展示所設計之軟體能正確執行系统需求規範書之要求(如圖一所示)。V&V作業之執行簡述如下：
1. 文件審查
對軟體各發展階段所產生之設計輸出文件、軟體安全分析報告、廠家內部審查文件(Internal V&V)、Acquired軟體(如Support Software、Third Party及Previous Developed Software, PDS)以及測試計畫書/程序書/報告等皆需執行審查。
2. 執行測試
此可依上節審查(驗收)準則準備測試計畫書及測試案例(Test Case)執行相關測試，如單元測試、整合測試及確認測試等，以確認軟體是否能正確執行所要求之功能。
3. 現場稽查
即赴軟體發展廠家查核及訪談其軟體發展之組織、計畫、方針與程序是否遵照相關法規要求以及業主/管制單位之承諾執行。
4. 循線稽查
循線稽查的目的是從相關文件與設計過程去追查、評估其下游設計與上游規範是否相符。挑選循線稽查項目之原則是根據功能需求與程序需求，透過危害評估(Hazard Assessment)、風險評估(Risk Analysis)、參酌審查相關文件、業主過去執行經驗、特定之考量以及特定要求項目而訂定。
(三) 執行之對象
IV&V執行之對象，包括如下:
1. 軟體設計文件(Design Output)：此為軟體各發展階段所產出之設計文件。包括各軟體計畫書(如軟體管理/發展/構型管理/安全分析等計畫書)、軟體需求規範書(SRS)、軟體設計規範書(SDS)、通訊協定規範書、原始程式碼、設計團隊之內部審查文件(Internal V&V)、測試計畫書/程序書以及各類有關之軟體評估報告(如軟體安全分析報告)等。
2. 支援軟體：包括編譯器(Compiler),公用程式(Utility), Library以及其它相關軟體發展與測試工具等
3. Third Party軟體,如架上商用軟體(COTS)
4. 以前發展且使用過之軟體(Pre-developed Software, PDS)
(四) 其它
除了上所述IV&V作業之基本要求外，另對於軟體工具之V&V及V&V作業之評量(Metrics)等，在新版之相關法規亦有較明確的要求，簡述如下：
1. 軟體工具之V&V
IEEE 7-4.3.2 2003年版要求對於在發展及V&V程序所用之軟體工具要執行下述任一方法：
(1) 發展一個測試工具之確認計畫(test tool validation program)，以對所要求的軟體工具之功能，提供其應具備之性能的信心。
(2) 在軟體發展作業，如有使用軟體工具而有未被軟體工具偵測出之瑕疵(defect)，在V&V作業必須有方法使此瑕疵能被偵測出來。
2. V&V作業之評量
軟體V&V之作業經上所述執行後，對於軟體發展程序與產品所發現的問題以及對V&V作業之效能及品質等據以評量，以利隨時調整其V&V資源(如人力、時程及財務等)。此是針對V&V工作品質之評量，除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)之評量。
參、探討國內外核電廠執行IV&V之作法
對於各核電廠安全系統之數位化之儀控軟體，皆需透過IV&V作業之執行來提升其品質。但因各核電廠在安全系統數位化之規模、構型(Configuration)及軟體建置方法等有所不同。故，如要對各核電廠IV&V之作業做一比較，是有某種程度的困難。但本文乃就蒐集所得資料，介紹英國Sizewell B、日本KK 6/7及龍門計畫在RPS/ESF安全儀控系統軟體IV&V之作業。但在此之前，就上所述3個核電廠之數位化規模、安全儀控系統之人機介面以及軟體建置方法等先做介紹如下：
一、數位化之規模
1. 龍門計畫: 所有安全系統全數位化。
2. 英國Sizewell B: RPS/ESF之一次保護系統(PPC)是採數位化，但二次保護系統(SPC)是採類比控制。
3. 日本KK 6/7: RPS/ESF使用全數位化。
二、安全儀控系統之人機介面:
1. 龍門計畫:安全系統採用畫面顯示單元(Video Display Unit, VDU)執行顯示及控制功能。
2. Sizewell B: RPS/ESF未使用VDU執行顯示及控制功能。
3. KK 6/7: RPS/ESF使用VDU之顯示功能，但僅在ESF使用VDU控制功能。
三、軟體建置方法
1. 龍門計畫: NUMAC廠家負責RPS, NMS, PRMS及CMS等安全系統之軟體，採用傳統之人工發展方法。同時，大部份是使用已發展過之軟體 (PDS)。ESF系統是DRS公司直接從控制邏輯圖(CLD)透過軟體工具(OrCAD)轉換為功能連接圖(FID)，再經編譯器直接翻譯為C語言、Object file及Binary file，最後再燒置於PROM上之圖型建置方式。VDU是採用以人工發展之安全級軟體配合DRS所建之Utility自動產生。
2. 英國Sizewell B: 軟體採用人工發展，軟體是使用問題為導向之高階語言PL/M-86，部份為配合硬體介面及時間反應之限制而採用組合(Assemble)語言。
3. 日本KK 6/7: RPS/ESF系統是透過軟體工具(CAD)建置，其採用圖型化之問題導向語言(Problem Oriented Language, POL)來建置可見式(Visual)之軟體圖面(Software Diagram, SD)。VDU之顯示功能是以傳統之人工發展方法。
四、IV&V作業之介紹
對於上述3個核電廠安全系統之軟體建置規模及方法等，有概括概念後。接著對於各核電廠執行IV&V作業所遵循之法規與標準提出說明為:英國Sizewell B是採用IEC 880 -1986，日本KK6&7是遵循JEAG 4609 –1989以及龍門計畫是依IEEE 1012-1986 (R.G. 1.168及BTP-14)之要求執行。此三種法規與標準對IV&V作業之要求，大致上是相同並未有太多差異。僅各廠家或電力公司面臨不同之境遇與使用情形而有不同之作法。簡述如下：
(一) 英國Sizewell B:
由於Sizewell B係英國首次採用軟體執行安全保護系統之核電廠，曾引起學術界及社會其它各界之疑慮與反對，故針對RPS/ESF之一次保護系統(PPS)，再度投入人力大規模執行軟體IV&V作業，以確保其軟體品質之信心與消除各方之疑慮。其IV&V總共投入300人年，包括：原在西屋公司軟體設計及發展時已投入之50人年，英國核能電氣公司(Nuclear Electric, NE)在Sizewell Ｂ另外再投入250人年。同時，英國核能電氣公司在完成IV&V工作後，由英國Royal Academy of Engineering所舉辦之研討會上開誠佈公接受各界之質疑與討論。
英國核能電氣公司在Sizewell B所執行之IV&V作業，大致可分為下列四個主要工作(如圖一所示)，簡述如下：
1. 工程設計認可分析：
此部份是由NNC公司及NE技術部門所執行，其工作目標是以人工對所有設計文件及軟體之符合性審查。
2.MALPAS測試工具之確認分析
MALPAS靜態分析是由TACS公司及其下游合約商共同執行，其目標是採用靜態的方法分析其軟體符合規格需求。此MALPASエ具由語法、語意及符合性三部份之分析所組成。其驗證包括用人工比對設計規格與分析結果，以及將設計規格以數學表示式與程式碼對照。
3. 程式碼比較器
此比較器是由核能電氣公司技術部門所設計之工具，此技術也是第一次被用來對安全程式碼之評估。其目的是用來核對安裝在PROM之可執行程式碼與原始程式碼是否相符。
4. 動態測試
PPS之動態測試是由R, R &A公司在Test Guardline (此設備與安裝在Sizewell B PPS上之設備完全相同)上執行。其從反應器暫態分析之故障研究得出11個劇本(Scenario)，每個劇本有5000個測試方案(Test Case)，總共約執行60000個測試方案。其測試方案之輸入參數是透過測試方案產生器隨機產生。最後，實際測試結果與輸進模擬PPS之邏輯模式內而產生預期之結果相比較，並作時間反應之核對，結果並未發現有軟體因編碼上之錯誤而造成安全功能之作動系統失效。同時，為了證明測試設備及PPS邏輯模式之正確性，也花一個月的時間執行6000個測試，結果沒有發現任何錯誤。
此一次保護系統(PPS)在西屋公司軟體設計及V&V所投入的人力約250人年(其中軟體設計為200人年及50人年為V&V)。經統計此PPS執行之原始程式碼約10萬行，在西屋所執行之設計與IV&V及Sizewell B所投入之IV&V人力共花費約US$ 8仟萬元，每行之程式碼約花費US$ 800元，其花費所產生之軟體品質可媲美Aerospace industry。但事後被評估其軟體品質之投入為過度(Overdo)的執行IV&V作業。
(二) 日本KK 6/7:
經收集日本KK 6&7所發表之相關文章及日本東電公司等在台電簡報之資料，其KK6所投入RPS及ESF安全系統之獨立V&V作業約共11.7人年(3050人天)。日本Toshiba公司在KK6核電廠所執行之IV&V作業，大致可分為下列6個主要步驟，其中5個步驟是驗証工作及及另一個確認測試，如圖二所示。簡述如下：
1. 系統規範書(步驟1)之驗証
此係檢查系統規範書與上層文件之一致性，如安全分析報告及各種管制標準與指引。
2. 軟體設計規範書(步驟2)之驗証
此步驟係查驗軟體設計規範書[即邏輯設計規範書,在日本稱Interlock Block Diagram (IBD), 在龍門計畫稱控制邏輯圖(CLD)]之邏輯符合系統規範書之要求。
3. 軟體設計與製造(步驟3&4)之驗証
在此階段之軟體設計與製造團隊係透過電腦輔助工具(CAD)將IBD轉換為類似IBD之可見的軟體圖面(Software Diagram, SD)。故，此階段之驗証係查驗透過由POL所顯示之軟體圖面與IBD是否有不一致，即逐步查對在軟體圖面上之所有路徑及邏輯。
4. 軟體安裝(步驟5)之驗証
此階段之驗証係查對軟體是否已妥當安装在標的(Target)系统上，即比較燒置在ROM內之位元與軟體圖面之原始資料的一致性。
5. 確認測試
在KK6所執行之確認測試包含下述各項：
(1) I/O Matrix Test: 包括I/O之接線檢視及特性測試等。
(2) Instrumentation Loop Test: 指信號範圍與精確性的查驗等。
(3) System Logic Test: 確認軟體圖面所有路徑之邏輯符合系統要求。其可由自動測試工具的信號模擬器及維護工具將待測信號輸入，可在維護エ具上之狀態顯示查驗系統對測試輸入的反應，同時也查驗在平板顯示器(Flat Display)上顯示狀態之改變
(4) System Failure Test:確認系統反應與設計基礎系統失效相符合
(5) System Response Time Test: 量測輸入信號碰到設定點到啟動信號輸出之反應時間的確認。
(6) Dynamic Transients Test:確認模擬暫態資料與系統反應之相符性。測試案例納入設計基礎暫態事件與現有電廠之暫態經驗。
(7) Random Input Test: 確認4個Division隨機輸入信號的組合與系統反應相符合。此測試可視測試時程來决定是否需要執行。
上述僅第(3), (6)及(7)項是採用自動測試工具執行，其中第(6)及(7)項測試是廠家Toshiba基於第一次建置全數位化之安全系統的責任與エ程判斷而增加的額外測試。在此2項之自動測試中，動態之暫態測試RPS與ESF各有665個與232個劇本，每個劇本各有10個測試案例，總共8970個測試案例。在隨機輸入測試共有5240個測試案例，此2個測試利用自動測試工具共費了20天執行14210個測試案例，大大縮減原預計原至少需50個工作天之測試。
雖KK6採用POL之可見式的軟體語言發展安全系統，但其驗証(Verification)所費之人時約佔整個IV&V Effort的83%，因其需花費較多的時間檢查不同型態文件間之一致性，以及準備可供稽查之報告。
KK6核電廠IV&V所花費之人時較龍門及Sizewell B少很多的原因，除採用設計標準化與再使用(Reuse)軟體外，最重要是採用圖型化之問題導向語言(POL)來設計與發展應用軟體，使得在驗證軟體圖面(Software Diagram, SD)及系統邏輯測試時可如類比系統之可追蹤及透明化容易執行。同時，另發展自動測試工具可自動執行測試及準備測試報告，大大縮短確認(Validation)的時程。
(三) 龍門計畫:
龍門計畫IV&V作業除內部審查(Internal V&V)及所有測試エ作是由原廠家(獨立於軟體發展團隊)執行外，其餘是由GE IVVT及台電之業主獨立與確認小組(OIVVT)負責執行。同時，除動態之暫態測試未在廠家驗收測試(FAT)執行外，其餘IV&V作業與日本KK6較為類似，共分為5個階段執行，特別是較偏重於設計文件之審查。台電OIVVT之工作除執行相關軟體文件審查外，另赴軟體發展廠家執行現場稽查及循線稽查等工作，以確保其軟體發展之組織、計畫、方針與程序是否遵照相關法規要求以及業主/管制單位之承諾執行。對於測試作業，龍門計畫IV&Vエ作除審查其測試計畫書、程序書及測試報告外，台電並派員赴廠家Observe其有關之測試作業，如單元、整合、確認及廠家驗收測試等。龍門計畫軟體IV&V執行架構圖如圖三所示，從圖上可看出對軟體IV&V工作之投入以軟體發展廠家比重最高，再依序為GE IVVT、台電OIVVT及核能管制單位逐步減少。
針對DCIS安全系統包括NUMAC所負責之NMS, PRMS/CMS, SSLC/RTIF等系統及DRS負責之SSLC/ESF系統，龍門計畫IV&V投入之人力約共81人年，包括: GE IVVT 35.5人年及台電OIVVT 45.2人年[此人年還包括5個reliability(R)級重要控制系統(非安全系統)之IV&V作業]。
(四) 感想：
英國Sizewell B因境遇特殊，為了澈底解決各方疑慮，雖花費大量人力在IV&V做得很澈底，但其投入過度之Effort並非最佳的範本。另，日本在KK6&7核電廠安全系統數位化所投入之V&V人時可能不是最多，但其有前瞻性的規畫：首先選取可追蹤性以及可如類比式電路建置之透明化與可見式的圖型化之軟體語言POL，除可减少在設計上人為之疏失外，並使得在V&V執行時可很清楚且容易被執行。同時，其儀控系统之架構以及軟體之建置與V&V是先在火力電廠及核電廠之非安全系統累積相當之成熟的(Proven)經驗後，才再應用在核電廠之安全系统；以確保其技術之可行及核電廠之安全。龍門計畫之儀控軟體因由GE下包不同之廠家建置。故，是採用傳統及軟體工具(如日本KK6之CAD)發展，雖其IV&V作業類似日本KK6之作法，但較偏重於文件審查。
肆、龍門計畫之IV&V經驗與建議
龍門計畫在執行安全系統數位儀控軟體IV&V作業時，因涉及法規釋意及軟體建置採用不同方法等議題，使IV&V之執行面臨相當多之挑戰。下將簡述所遭遇之問題並提出建議，以備將來在執行舊廠之更新與新建電廠安全系統軟體IV&V之執行，需考慮之相關事宜：
1. 法規對V&V“獨立”之解讀
因在10CFR 50 App.B、BTP-14、IEEE 1012-1986及R.G. 1.168法規與工業標準間對“獨立”要求不一致，使得各方(AEC/GE/TPC)有不同解讀，造成在IV&V作業執行之爭議。
建議：
選用適當法規與標準，並在發包前先與管制單位溝通法規之版本、V&V獨立及工作範圍等議題。在準備招標規範書及審查廠家Proposal時，除需澄清上述問題外，亦需考量文件送審、稽查及下包等問題。
2. 軟體建置採用不同方法
廠家採用軟體工具取代傳統流程之建置，使軟體發展某些階段無法執行V&V作業，致未能符合目前法規要求，而需花費大量人力向管制單位澄清，曠日費時。
建議：
準備規範書時需與管制單位溝通以及對廠家之Proposal需特別注意與澄清，避免日後造成V&Vエ作之困擾。
3. 業主獨立V&V小組(OIVVT)之定位
台電為使龍門計畫軟體獨立V&V之執行能更落實而另成立OIVVT，其工作範圍與GE IVVT有某種程度之重疊。因此,造成GE軟體設計團隊須花費更多精神處理GE IVVT與OIVVT兩次審查，造成設計團隊在發展時程上深受影響。同時，台電與GE在訂定NSSS合約時，未明言將有OIVVT之相關工作要求，故在OIVVT初次執行相關工作(如赴廠家執行現場稽查)時，GE認為此項工作會影響其工作進度有相當程度反彈，造成執行上困擾。
建議：
台電將來對OIVVT之需求及定位需及早規畫，並於準備招標規範書與在廠家Proposal澄清時需特別注意。同時，亦需及早規晝OIVVT的預算等。
4. 安全系統數位儀控之軟體業主自行維護問題
將來對於現有核電廠之數位化更新或新建核電廠，台電在準備規範書之前，應先評估安全系統數位儀控軟體是否需自行維護，因其影響自行維護所需之設計文件、軟體、測試報告及相關程序書等之移交及智慧財產權(Proprietary)等問題。
5. 執行動態之暫態測試
計畫案如有涉及RPS/ESF等重要之安全系統時，在時程允許下最好規畫如Sizewell B及KK6核電廠在廠家驗收測試(FAT)時用模擬信號執行動態之暫態測試，以確保安全系統功能符合設計基礎暫態事件之反應。
6. 建立IVVT追蹤系統
IVVT追蹤系統非常有益於IV&V工作，特別是對審查之驗收準則、會議紀錄、評估報告、異常項目及懸案事項都可透過此追蹤系統予以管制，不但透明，且有助於業主與管制單位瞭解IV&V作業之過程及執行狀況。
伍、結語
軟體 IV&V 目的是幫助軟體發展組織在軟體生命週期建立良好之軟體品質。同時，其目標是對軟體的錯誤可較早偵測及矯正，並加強程序之洞查力(insight)與產品風險的管理，進而支援軟體生命週期程序以確保符合計畫之效能、時程及預算的需求。
基於此，對於上所討論之安全系統儀控軟體IV&V作業，從個人觀點是覺得日本KK6之作法較值得借鏡。因軟體最大的問題是設計與建置的錯誤，其選取可追蹤性與透明化之可見式的圖型化軟體語言POL，除可減少人為因素造成設計錯誤外；對於V&V之工作又可很清楚且容易被執行。同時，從龍門計畫IV&V作業所遭遇過之問題，除部份已由法規與標準之進版將其修正為更有一致性之要求外(如IV&V獨立性之釋意、軟體工具之V&V等)，最重要的是在執行IV&V計畫前應先與管制單位充分溝通有關軟體發展與IV&V作業適用法規與版本，以及對法規內容之定義相互間有充份共識後，再進行規劃IVVT及執行方式。同時，在準備規範書、審標以及與廠家澄清Proposal時，亦應特別考量上所建議之相關事項，相信在IV&V執行時可避免很多無謂紛擾，同時可增進對軟體發展與IV&V工作的效能以及工期之掌握。
陸、參考文件
1. Fukumtomo, A., et, 1998. A Verification and Validation Method and Its Application to Digital Safety Systems in ABWR Nuclear Power Plants. Nuclear Engineering and Design 183 (1998) 117-132.
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. 7-4.3.2-2003, “Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations”
6. NUREG/CR-6101-1993, “Software Reliability and Safety in Nuclear Reactor Protection Systems”
7. P. A. Tooley CEng MIEE, “The Primary Protection System Software,” Proceedings of a Forum on Safety Related Systems in Nuclear Application, 1992, pp. 24-35.
8. Rob Welsh, “ Primary Protection System Pass Its Dynamic Test” ATOM 433, March 1994, pp.39-43.
9. Japan Electrical Society, 1989. JEAG 4609, Guidelines for Application of Digital Computer to Safety Protection system.
