設備必需先符合原產國（Country of Origin）及中華民國之法規與標準。龍門NSSS原產國為美國，故其DCIS儀控軟體SSA須遵照美國相關法規與標準來執行，簡述如下：

2.1. 適用龍門計畫SSA之法規與標準

1. Regulatory Guide 1.173 “Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Poser Plants.”, Section 3, Software Safety Analysis.

2. NUREG 0800, BTP-14, Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems, USNRC, Washington D.C., USA, 1997。其第3.1.i節說明軟體安全計畫組織架構可參考IEEE 1228-1994

3. IEEE Std 1228-1994 Standard for Software Safety Plan.
IEEE 1228-1994被下列相關檔要求參考

(1) 初期安全分析報告（PSAR）第1章表1.8-21工業法規與標準

(2) 初期安全分析報告第7.1.1.2.1.3 SSLC設備第2項有關軟體發展中軟體管理計畫書(SMP)內說明其可接受之方法與程式書。

4. IEEE Std 7-4.3.2-1993 Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations.

5. NUREG/CR-6430, Software Safety Hazard Analysis UCRL-ID-122514. Lawrence Livermore National Laboratory Lawrence, J. Dennis. 1995.

又依合約要求，GE承諾按R. G. 1.173、BTP-14及IEEE-1228 1994年版執行SSA

2.2. SSA之執行方法研議

龍門計畫適用之法規與標準雖然包括應執行SSA，且在合約上GE亦有承諾，但由於法規與標準自頒佈後並無實際在全數位化之新核電廠執行之前例可供參考。故在SSA執行過程中，即因廠家（GE）/業主（台電）/管制單位（原子能委員會，AEC）對法規與標準所要求之執行方法有不同之解讀，以致對GE在SSA之做法未能達成共識。經GENE獨立驗証與確認小組（IVVT）聘雇其顧問公司CDA (Computer Dependability Associates)諮詢，台電亦聘雇顧問公司MPR諮詢，並經冗長的協商討論，最後在2004年5月GE/台電/AEC三方在台電DCIS會議中．對龍門計畫DCIS儀控軟體SSA之執行方法討論後達成共識。

參、龍門計畫DCIS儀控軟體SSA之執行

台電龍門計畫SSA工作目前除工地安裝及涉及設計修改部份外，已全部完成，下面將針對SSA執行之整體架構與方法，以及SSA在廠家之執行與完成後之審查機制做一簡述：

3.1. SSA之執行架構與方法

經前述之協商討論，龍門計畫SSA作業之架構如圖一，並介紹如下：

1. 軟體安全計畫書之準備

依IEEE 1228-1994年版之要求與格式，編寫軟體安全相關計畫書，特別是第4章有關軟體安全計畫書之內容，應包括軟體安全管理、軟體安全分析事故發展等，同時在附錄之「軟體安全分析討論」亦詳述軟體發展生命週期之各階段作業，如軟體需求、設計、編碼、測試各階段需執行那些軟體安全分析工作。

2. SSA第一階段作業：

下面將說明SSA在第一階段作業之執行須遵行的法規需求及GENE的作法：

(1) 執行SSA第一階段之法規需求

依IEEE 1228-1994第4.4.1節軟體安全分析準備（SSA Preparation）之安全相關作業，其需求如下：

A.        初期風險分析（Preliminary Hazard Analysis, PHA）是辨識

(A) 有風險之電廠狀態

(B) 會造成系統進入有風險狀態之行動的順序

(C) 意圖將系統從有風險狀態帶回到沒有風險狀態之動作的順序

(D) 執行緩和（Mitigate）意外事故後果之行動

B. 在此階段之工作是指出系統設計能辨認那些功能是由軟體來執行，以及說明軟體安全有關功能如何預防系統進入風險狀態，或將系統從一個有風險狀態帶回到無風險狀態，或將可能意外事故之後果緩和等之安全有關行動。此外，為確保龍門電廠安全功能在面臨軟體共因失效時，可透過核電廠多樣化與深度防禦之設計不致失效（Disable），以確保核電廠安全。GENE針對龍門電廠實際設計，依BTP-19之最佳估算法進行數位元儀控系統多樣化與深度防禦（D3）評估，以驗證龍門電廠之多樣化與深度防禦符合BTP-19之驗收準則。最後，對整個非安全系統亦執行HA&DID評估，以確保非安全系統所有功能不會造成安全系統功能之失效，且確認其暫態皆被涵蓋在請照之初期安全分析報告範圍內。

C. 辨識系統內軟體與其他組件間之介面

(2) GENE執行SSA第一階段之作法

GE SSA透過下述二個方法來執行第一階段工作，簡述如下:

A.建立龍門DCIS需執行SSA之系統與系統功能
此作業是建立龍門DCIS需執行SSA之系統與系統功能，以供後續執行風險分析與深度防禦（Hazard Analysis and Defense in Depth，HA&DID）評估，及軟體發展各階段之SSA時使用，其作法如下：

(A)確認那些系統需執行SSA

a. 辨識全廠系統

可透過下面幾個管道配合執行辨識全廠系統

(a)   主要以龍門計畫設計手冊（Project Design Manual, PDM）為主所發展之龍門電廠系統。

(b)同時透過初期安全分析報告（PSAR）Table 3.2-1a、龍門可靠度安全評估（PRA）以及台電/GE間往返信函來補足PDM。

依上所述找出龍門電廠全廠之系統後，再依其系統找出龍門計畫DCIS安全相關與安全關鍵（Critical, C）系統，以供後續SSA執行時使用

b.安全相關（Safety Related, S）系統定義

(a)   PSAR Table 3.1-1b與1c所有列為Safety Class 1, 2或3都被指定為S等級。

(b)   其對每S等級系統之查對

˙系統有系統設計說明書（SDD）則用SDD確認。

˙系統沒有SDD則可用系統說明書（SD）或採購規範書來確認或決定。

c.安全關鍵（Safety Critical, C）系統定義

(a)   PRA決定

˙在PRA有發展Fault Tree之系統

˙在 PRA Section A.3之Dependence Table所列之系統。

˙有時為保守起見有些系統在PRA可能不是很重要，但亦被列入。

(b)   Direct Initiators決定

組件或系統之失效而Initiate Trip，此組件或系統之失效是被列為Direct Initiator.

(c)上述非安全系統若滿足任何(a)或(b)項即列為安全關鍵等級

d. 辨識與有Logic-Based系統之介面的系統

龍門計畫每個SDD均有一章節說明此系統與電廠其他系統之介面；故，透過審查DCIS每個系統之SDD，以辨織任何與DCIS有Logic-Based系統介面之系統將其列出。

e.執行SSA之系統的篩選準則（Screening Criteria）

(a)   系統本身沒有軟體或沒有直接與DCIS Logic-Based系統有介面之系統不納入SSA執行。

(b)   與DCIS Logic-Based系統有介面之系統，若其為S或C則需執行SSA。

(B) 訂定需執行SSA之系統功能

a. 辨識DCIS之系統功能:依

(a)   所訂出需執行SSA評估之S與C等級系統。

(b)   執行人因工程評估所產出之系統功能需求分析（SFRA）所列之各系統功能。

(c)   列出DCIS之所有系統功能。

b. 列出需執行SSA之系統（S與C級）功能

(a)   辨識S與C級之系統功能是審查SDD及SFRA來決定，其方法與辨識S及C系統一樣，只要上述兩份檔中有一份是屬S級則列為S級。若無SDD則依SD或採購規範書來評估。

(b)   若系統功能為Passive（未使用軟體執行功能）則毋需執行SSA。

B. 執行初期風險分析（Preliminary Hazard Analysis, PHA）
針對IEEE 1228-1994第4.4.1節軟體安全分析準備中，有關PHA四個需求及其它相關作業，GE SSA是以PSAR第6章與第15章以及龍門PRA三份檔為基礎執行分析與評估。其作法是發展電廠、系統、及組件層級之風險分析，並將之整合為初期風險分析。其目的除確保PSAR第6與第15章以及龍門PRA符合初期風險分析四個需求外，並在電廠、系統、及組件層級之風險分析過程中發現規範書與設計文件（如SDD, P&ID,CLD等）有不一致之Findings（即Errors或Inconsistence）加以更正，簡述如下：

(A) 電廠層級風險分析是找出在執行SRP第6與第15章，以及龍門PRA分析事件時，以軟體為基礎的系統功能過程中之Findings。其做法是先找出DCIS需執行SSA之系統。再以此系統為基礎下找出各系統需執行SSA之系統功能。

(B) 系統層級風險分析是找出DCIS執行系統功能之軟體控制組件過程中的Findings。其作法是將需執行SSA之系統功能，依管路儀控圖（P&ID）準備系統功能方塊圖，找出其將執行此系統功能之軟體控制組件。

(C) 組件層級風險分析是找出DCIS需執行SSA之各軟體控制組件的失效模式過程中之Findings。以在事件期間必需打開閥門（Valve）例子來說明軟體控制組件之失效模式，其大致上可分4個狀況：

a. 系統之起始（Initiation）信號失效，即未接收到起始信號。

b. 接收到起始信號但系統邏輯未能成功直接打開閥門。

c. 系統邏輯直接使得閥門再關閉。

d. 邏輯信號未能正確輸出到硬體。

其中Item a與d屬介面失效，Item b與c屬系統軟體失效，故此軟體組件之失效模式可由上述之失效所組成。

此階段分析是將DCIS所有需執行SSA之軟體控制組件間介面找出，透過GENE自行開發軟體工具讀取控制邏輯圖(CLD)，以建立專供SSA分析使用之I/O資料庫，去查對各個軟體組件間介面連接是否正確。

GE從上述電廠、系統及組件層級之風險分析作業，找出與目前設計相關資料中有Errors或文件不符之處，訂為Findings並列入修正與追蹤。GE在此第一階段執行SSA作業，共發現324個Findings。

圖一、龍門計畫DCIS SSA之執行架構圖與方法 

3. 安全系統需執行之作業

依圖一龍門計畫DCIS SSA之執行架構圖，其所列在此階段應執行每一安全系統之系統風險分析與深度防禦、在第2 ~ 6軟體發展階段之已發展與新發展之軟體、DRS Plus 32系統之風險分析與深度防禦評估，以及依BTP-19對龍門電廠進行DCIS多樣化與深度防禦（D3）評估。說明如下：

(1) DCIS所有安全系統皆需執行系統之系統風險分析與深度防禦（HA&DID）評估

DCIS安全系統以失效模式及其影響分析（FMEA）方法，在軟體”假設失效”下辨識與評估風險，進而分析系統與電廠層級之深度防禦是否有適當之設計，予以緩和至可接受之程度或終止其風險。其做法為：

A.        首先，依據軟體安全分析第1階段（SSA Phase 1）對系統安全功能分析之結論，訂定各安全系統之安全相關與安全關鍵功能。

B. 再依SSA Phase 1之結果，對安全相關及安全關鍵功能，依控制邏輯圖，找出各系統內軟體驅動之輸出，如圖二所示之F00-a~e及軟體失效F00-f~g例子。

 

C. 進而假設可能影響安全相關及關鍵系統輸出之軟體輸出失效模式,如表一F00-a~e之Hazard Identification欄所示。

D.        下一步，再檢查軟體失效之衝擊以評估是否對系統造成風險，如表一F00-a~e之Hazard Assessment欄所示。

E. 同時，為了限制假設失效之潛在影響，先在系統層級找出任何可終止或緩和風險之功能，如表一F00-a~e之Hazard Mitigation欄所示。

F. 進而檢查所提出之風險是否會衝擊到全廠層級之安全，找出全廠層級是否可提供深度防禦之多樣化功能，以緩和假設軟體失效之後果，如表一F00-a~e之Plant Hazard Evaluation欄所示。

G.        最後，評估設計是否適當，即若任何系統設計或全廠層級設計可終止或緩和假設軟體失效所產生之風險，則視為設計適當，反之則需進一步修改設計或重做分析以確保安全無虞。亦即此風險分析之可接受準則，是潛在失效之後果可被現有電廠Licensing Basis涵蓋，如表一F00-a~e之Accept Design欄所示。

H.        同時，將相關之緩和或終止功能予以列出相對應之文件及其章節以供追蹤。台電並將其列入業主獨立驗証與確認小組（OIVVT）稽查重點，以追蹤此功能是否有實際落實在軟體設計，並確保此緩和或終止風險之功能有被正確執行。GE執行所有DCIS安全系統之風險分析與深度防禦評估，共發現95個Findings。

(2) 軟體生命週期階段2~6之軟體安全分析作業

因GE將DCIS安全系統軟體分包給NUMAC及DRS兩廠家建置，故此兩軟體發展廠家，將其軟體分成已有使用實績（Proven），且成功被使用過之已發展軟體（Previously Developed Software, PDS）與新發展軟體兩類，其做法說明如下：

A.        已發展之軟體
GE採用Pareto Chart 評估方法來做分析，由於PRMS、CMS及NMS三個安全系統之軟體發展係採用PDS設計，因此很難再將以前已完成之軟體設計再逐項重新依IEEE 1228-1994 附錄要求去執行Type 分析。故，採用折衷之Pareto Chart方法來評估，說明如下:

(A) 目的：此為針對採用NUMAC PDS之安全系統如NMS/PRMS/CMS等執行軟體需求、設計、編碼與單元測試、整合測試及驗証測試共5個階段（Phase 2~6）之軟體安全分析方法。

(B) 分析方法：其分析方法說明如下

 

a. 收集審查意見：

首先，GE SSA小組收集下列各相關單位對此階段設計文件之審查與評估意見

(a)   GE內部設計審查意見

(b)   檔修正意見

(c)   GE IVVT審查意見

(d)   台電/S&W/OIVVT審查意見

b. 準備審查意見分類之核對表：

依BTP-14 A.3及IEEE 610.12所定義各軟體特性以準備對各審查意見做分類之核對表。例如，核對審查意見是否對軟體規範要求之功能符合完整性（Completeness）、一致性（Consistency）、精確性（Accuracy）、功能性（Functional）、可追蹤性（Traceability）等以及反應時間與記憶體大小功能（Timing & Sizing）分析等。

c.訂定風險項目(Hazard Item)

GE SSA小組再用人工將第a項所收集之審查意見依第b項所準備之查核表分別歸類。當然，所有諸如打字錯誤等不具特別意義之意見皆被剔除，不列入風險項目之計算。當上述所有審查意見被歸類完成後，則可透過Pareto Chart（如圖三）檢出各軟體特性的審查意見數目來訂出風險項目，其做法如下：

(a)   超過所有審查意見數目10%之項目

如果各軟體特性數目超過總共審查意見數目10%以上則視為風險項目，因為審查意見數量過多有可能是設計或設計程式不當所致。

(b)   完全沒有審查意見之項目

如果某軟體特性項目完全沒有審查意見，亦視為風險項目，因有可能是審查者未特別注意這些特性，或審查程式不當所致。

(c)   共通意見之項目

同時，SSA小組對於所列之審查意見檢查是否同樣問題會發生在不同系統間，而產生共通問題，即此問題可能會造成不同系統間之共模失效（Common Mode Failure）。如有，則需很小心更進一步在風險評估時加以檢查。

d. 風險評估（Hazard Assessment）

經上述方法訂出風險項目後，如何執行其風險評估說明如下：

(a)   超過所有審查意見10%之風險項目

SSA工程師將對此軟體特性之審查意見逐項加以檢查，以確保設計

 

工程師已適當將此風險項目處理過。同時，也將評估其審查意見以找出其共通性或錯誤之根源（root cause）。依上述評估再對被審查之檔依核對表增加取樣審查，以瞭解是否問題有被擴大，如有則需執行妥當之矯正動作。

(b)   完全沒有審查意見之風險項目

SSA工程師檢查被審查設計檔是否設計工程師有注意到或被忽略，若此軟體特性有被設計工程師考慮到，則SSA工程師依核對表之軟體特性加以審查，如果審查結果其設計是適當，則不再進一步評估，反之則有可能因設計工程師忽略此軟體特性或審查者因設計工程師之疏漏而無法指出其缺失，SSA工程師將對設計檔進一步評估。

(c)   共通意見之風險項目

有些審查意見可能指出有潛在性之Intersystem Hazard，此共通性意見將用類似上述評估方法作各別審查，應評估是否要擴及到其他系統。

所有上述之檢查與分析過程中如有發現任何審查意見未被妥善處理、各設計檔間不一致或認為設計有危害到安全之疑慮等，皆視為Finding並送設計小組解決與回覆，並在各Phase列出追蹤表追蹤直至結案。

GENE為說明符合IEEE 1228要求，對於IEEE 1228-1994 Annex所建議之Type 分析項目，如軟體在軟體設計階段之邏輯分析資料分析及系統內部介面分析等，皆在其各Phase之Table 1 Conclusion詳加說明，以及對於在Type分析完成後依IEEE 1228 Section 4.4 要求應提供那些相關分析資訊之說明與結論。GENE為此準備對照表（Cross Reference Matrix）以說明IEEE 1228要求與GENE相對應之做法，此表列於PRMS/CMS系統之Phase3軟體階段SSA評估報告Table A1：SSA Phase 3 Treatment of IEEE 1228 Topics與Table 1：Type分析之結論，以供各相關單位審查。

(C) CDA及MPR對Pareto Chart方法之意見

此方法亦被GE IVVT 顧問CDA (Computer Dependability Associates)及OIVVT顧問MPR所認同,其提供相關意見如下：

a. CDA顧問之意見

CDA顧問Dr. Gary Johnson及Dr. Dennis Lawrence認為GE採用Pilot Program之Pareto Chart方法使用在PRMS/CMS/NMS之PDS是可接受的，其理由為

(a)   此PDS已依10 CFR 50 App. B之QA要求發展

(b)   此PDS已被NRC所接受

(c)   此PDS已經廣泛使用在運轉中之BWR核電廠獲得証明其使用實績

(d)   龍門計畫PRMS、CMS及NMS僅小部份修改

˙對設計與編碼之影響可經由V&V評估認可

˙在GENE PDS之評估報告已有很詳細的分析

˙故，進一步的分析並無加分效果

b. MPR顧問之意見

OIVVT顧問MPR也針對GENE軟體安全分析執行Thread Audit，其報告為TAR-SSA-003。其結論對GENE PDS採用Pareto Chart方法執行之Pilot Program是可接受。且MPR對安全系統SSA建議除執行Pareto Chart外也應執行風險分析與深度評估（Hazard Analysis and Defense in Depth，HA&DID），GE遵照此建議已各提出PRM/CMS/NMS 之風險分析與深度防禦評估報告符合MPR建議。

GE SSA小組對NUMAC已發展之軟體執行SSA作業，共發現27個Findings。

B. 新發展之軟體
NUMAC之反應器跳脫隔離功能（RTIF）系統與DRS公司所發展之螢幕顯示單元（Video Display Unit, VDU）軟體係新發展軟體，需依IEEE 7-4.3.2-1993之Annex. F.2.3異常狀況事件（Abnormal Condition Event, ACE）要求，從軟體發展階段2~6逐階段執行評估，其亦採用失效模式及影響分析（FMEA）方法來執行。
GE SSA小組對NUMAC及DRS新發展之軟體執行ACE，共發現39個Findings。

(3) DRS Plus 32系統之風險分析與深度防禦評估

分析步驟：Plus 32平臺系統透過下述步驟執行評估

A.        審查”System Design Basis Specification for GE Lungmen Project NPP Unit 1&2 for TPC”之DRS系統需求文件，以發展出一個DRS Plus 32平臺的拓普邏輯（Topology）架構圖（圖四）以備分析之用。

B. 使用上述所建好之拓普邏輯架構圖定義其邏輯工作範圍之層級，此共列出3個層級

(A) 機櫃內之組件到機櫃（local to cabinet）

(B) 機櫃內之組件到Division (local to Division)

(C) Division與Division間

    從最低的邏輯工作範圍層級開始對每層級執行下述D~G之步驟。

C. 假設可能影響關鍵系統輸出之軟體輸出失效。

D.        評估每個失效之衝擊來決定是否會對系統產生一個風險。

E. 列出限制假設失效之潛在影響的軟體平臺與軟體發展程式之救援功能。

F. 為將來在系統層級風險分析與深度防禦報告之評估，描述在資料失效之影響。

G.        此外，為確保龍門設計有充分之完整性以承受任何潛在失效，將增加檢查下述二個狀況：

(A) 在單一Division內所有Plus 32設備失效

(B) 整個Plus 32平臺失效（所有Divisions），包括配置在Plus 32平臺設備之手動控制

    對於DRS所建置在Plus 32系統上之安全系統之風險分析與深度防禦評估，可增加下述兩主要工作以完成風險分析：

(A) 在電廠層級檢查已被辨識之風險的衝擊，包括考慮可提供深度防禦以緩和假設軟體失效之多樣化功能。

(B) 評估設計之適當性，包括考慮在現有電廠設計之深度防禦。

(4) 依BTP-19對龍門電廠進行DCIS多樣化與深度防禦評估

進步型輕水式反應器（ALWR）採用全數位化儀控系統，其軟體共因失效有可能會擊潰安全系統之雙重設計之潛在風險。故，在1993年7月美國核能管制委員會（USNRC）對SECY-93-087之SRM (Staff Requirements Memorandum)第II.Q項將此共因失效列為Beyond Design-Basis Events。即，其雖無法依PSAR第15章暫態與事故分析採用保守的假設來執行分析，但可採用最佳估算法（Best-Estimate Method）來計算。基於此，USNRC對此議題在1997年6月頒佈BTP-19”數位電腦化儀控系統之深度防禦與多樣化評估指引”第四版，採用實際的假設（Realistic Assumption）以最佳估算法執行第15章暫態與事故分析。使核電廠之安全功能在遭逢軟體共因失效時，可透過核電廠多樣化與深度防禦之設計不致Disable，以確保核電廠安全。

為確保龍門電廠數位儀控系統之實際設計符合BTP-19之要求。GENE依BTP-19執行龍門電廠控制系統多樣化及深度防禦之完整的評估，包括對自動的作動（Action）、手動的作動以及電廠反應在龍門FSAR所說明之暫態（Transient）與事故（Accident）的多樣化控制的可用度。同時，針對龍門電廠之實際設計挑選出在FSAR第15章暫態與事故之20個事件（Events），並以上述控制系統之多樣化及深度防禦評估為Base重新計算。摘述如下：

A.        首先發展Lungmen Digital Control and Instrument-Basis for Diversity Evaluation

此報告說明Lungmen DCIS系統多樣化之結構、配置及資料流，以暸解在龍門電廠數位元控制系統承受一個假設共因失效之能力。同時，依龍門電廠DCIS之設計，在熱流（Thermal Hydraulic）評估時，其反應度控制（Reactivity Control）與爐心冷卻（Core Cooling）之Primary functions可被視為分離的，以做為評估龍門電廠I&C多樣化之適當性。

B. 接著，對於Lungmen FSAR第15章之暫態（Transient）與事故（Accident）選出20個事件，並依上所述為基礎重新計算與評估。同時，每個事件分析之資訊，依下述格式執行：

(A) Automated Action

(B) EOP Entry Conditions

(C) Operator Actions per EOPs

(D) DeＳcription of the Reactor System response

(E) Summary

C. 執行方法與可接受準則

(A) 執行方法：

GE是配合Design Basis Analysis Codes採用Best-estimate Assumption。其有關LOCA分析是使用SAFER Basedeck分析程式， Transient分析是使用ODYN分析程式，Inadvertent Control Rod Withdrawal During Startup分析是使用PANACEA分析程式。

(B)可接受準則：

所有計算結果需符合BTP-19 Acceptance Criteria

D.        OIVVT赴GENE稽查結果

因有關GENE對重新評估各事件之暫態圖（Plot）及Design Record File之資訊屬GENE智慧財產，無法送台電審查而需赴GENE現場實際查驗其所分析之相關資料。台電OIVVT於2008年11月3~4日赴GENE San Jose與SSA小組討論。稽查結果說明如下：

GE公司於2008年7月起針對ESFAS共因失效，以SAFER及ODYN安全分析程式提出一系列最佳估算方法分析。其分析報告係以文字敘述的方式說明，對於在ESFAS發生軟體共因失效時，運轉員依據緊急運轉程式書執行手動高壓注水仍可順利注水，使燃料護套溫度不致超過2200°F發生metal-water reaction臨界值。由於分析報告僅有文字說明；故，本項重點在稽查其分析之暫態圖，以及瞭解GE公司如何假設運轉員手動時機。

GE公司在稽查時提出完整之暫態圖，運轉員手動起動高壓注水時機為水位下降至L3後5分鐘。此項假設雖屬保守，然而分析結果，部份分析案例雖發生Core Uncovery，然而燃料護套溫度皆在2200℉之下，符合法規要求。

此外並詢問在完全沒有緊急注水的情形下，由事件發生到水位降至TAF的時間。GE公司答覆在最嚴重的蒸汽管路斷裂案例，時間約為3分鐘，亦即發生假設ESFAS軟體共因失效時，必須有運轉員手動動作，始可將反應器帶回安全的狀況。由分析顯示最嚴重之案例為Steam Line Break，燃料護套溫度可達1951℉，仍低於2200°F發生Metal-water Reaction臨界值。

E. 結論：

經上說明，GENE依台電/原能會建議執行龍門電廠控制系統多樣化及深度防禦之評估。並針對龍門電廠之實際設計選取有關Lungmen FSAR第15章暫態與事故之20個事件（Events），依BTP-19之Best-estimate Assumption與Acceptance Criteria及控制系統多樣化與深度防禦之評估為Base重新計算與評估。其重新評估報告除經台電OIVVT（包括INER人員）、核技處核析組及核四廠審查外，其有疑義部份台電OIVVT亦赴GENE現場討論及查驗，結果是符合相關法規要求。

4. 非安全系統需執行之“假設失效”風險分析

非安全系統在第一階段軟體安全分析，列出有些安全關鍵功能（Safety Critical Function）有可能會影響安全系統功能而引起失效之風險，故此分析確保非安全系統所有功能不會造成安全系統功能之失效，且確認其暫態皆被涵蓋在請照之初期安全分析報告範圍內。

故本報告對非安全系統執行之軟體安全分析工作分為2部份，說明如下：

(1) 深度防禦評估

此評估証明分散式控制暨資訊系統（DCIS）已有充分之雙重與多樣化設計，使得任何非安全有關功能在龍門初期安全分析報告或安全度分析（PRA）事件所引起之起始（Initiation）、弱化或終結都已被涵蓋在龍門請照之初期安全分析報告與安全度分析報告內。

其作法是首先建立一個適當的深度防禦準則之清單。此準則是評估可緩和關鍵系統功能失效的電廠能力，共得出25項。若非安全系統任何安全關鍵功能可引用到上述25項任何一項準則，則勿需再執行暫態分析，因其已涵蓋在初期安全分析報告範圍內。

經由上述分析；得出之結果是非安全系統之安全關鍵功能皆有適切之深度防禦。

(2) 軟體風險分析

因非安全系統是由Invensys負責建置。故，此針對Invensys設備執行軟體安全評估，以保証此非安全有關設備不會造成安全有關設備之潛在失效。同時，也檢查非安全系統其安全關鍵功能潛在之軟體風險，以確保軟體風險已被適當的處理。其作法如下：

A.        一般性平臺分析（Generic Platform Analysis）

首先對Invensys一般性之軟體平臺及架構（圖五）執行評估，以備接下來將結果應用在系統之特定安全關鍵功能的軟體假設失效評估。即評估其一般性平臺與架構所使用之軟體組件（如控制處理器、現場通訊模組、現場匯流排模組、工作站等），其由軟體驅動之輸出在假設資料不正確、無效、過時等失效模式下，經評估是否可由系統層級來緩和此假設失效之軟體風險，此項作業是由GE軟體安全分析小組與Invensys工程師依設計與發展檔之分析來評估，若結果是否定，則需到電廠層級來做進一步之深度防禦，此將在特定安全關鍵功能評估時執行。

B. Invensys系統特定安全關鍵功能分析

此為針對Invensys系統之特定安全關鍵功能，在假設其軟體驅動之輸出資料不正確、無效等失效情形下，應用上述一般性平臺評估結果來核對其假設失效是否可在系統層級與電廠層級之深度防禦，來緩和其風險或控制在一可接受的程度。

透過上述非安全系統之深度防禦評估以及軟體風險分析，對於假設失效下之軟體風險，其結果是未發現有風險或其風險是可被緩和到一可接受程度。同時，分析所使用之可接受準則為其假設失效的後果，亦是在現有電廠之請照基準範圍內。

3.2. 廠家SSA之執行與審查機制

1. NUMAC SSA之執行與審查

有關在NUMAC對所發展之軟體設計輸出執行軟體安全分析部分，因NUMAC所負責之安全系統軟體發展，除SSLC/RTIF之軟體大部分採用新發展外，其他NMS/CMS/PRMS/SLC等系統皆採用PDS。涉及NUMAC軟體安全分析之評估及審查工作，包括NUMAC軟體設計小組、GE SSA小組、GE IVVT及台電OIVVT，其參與之工作概況，簡述如下：

(1) SSLC/RTIF SSA之執行

A.        NUMAC軟體設計小組

因，此系統之應用軟體大部份係新開發，故在軟體需求與設計階段，其設計規範書皆已納入對軟體安全之考量。如軟體需求階段之Critical Analysis、Timing Analysis及Abnormal Condition Events等，以及在軟體設計階段納入軟體安全設計指引等。

B. GENE SSA小組

GENE SSA對此系統提出

(A) SSLC/RTIF風險分析與深度防禦評估報告

(B) 軟體各階段之異常狀況事件（ACE）分析報告，其皆以失效模式與影響分析（FMEA）方法執行

(2) NMS/CMS/PRMS/SLC SSA之執行

因NMS/CMS/PRMS/SLC等系統之軟體採用PDS，故對軟體安全分析之執行與審查，除在NUMAC軟體設計小組未特別在軟體規範書納入相關安全議題，以及GENE SSA小組未對軟體各發展階段執行ACE分析外，其餘皆與SSLC/RTIF系統一樣。其理由除了PDS很難再將以前已完成之軟體設計再逐項執行ACE分析外；同時，GE IVVT顧問CDA (Computer Dependability Associates)之Dr. Gary Johnson及Dr. Dennis Lawrence與OIVVT顧問MPR亦認為可接受，其理由見第參.3.1.3.(2).A.(C)節所述。

(3) NUMAC SSA報告之審查

A.        GENE IVVT小組

GENE IVVT小組對GE SSA小組所產出之軟體安全分析報告皆依IVVP執行獨立之審查並將其審查紀錄納入IRT追蹤系統（IRT ReTrad）之資料庫內可供查閱。

B. 台電OIVVT小組

GE SSA小組完成之軟體安全分析報告皆須送台電OIVVT小組審查，所有審查意見均逐項追蹤並接受後才結案。

2. DRS SSA之執行與審查

有關在DRS對ESF系統所發展之軟體設計輸出執行軟體安全分析部分，因DRS所負責之ESF安全系統軟體發展，除VDU之軟體大部分是新發展外，其他Plus 32系統之軟體皆採用PDS。涉及DRS軟體安全分析之評估及審查工作，包括DRS軟體小組、GE SSA小組、GE IVVT小組及台電OIVVT其參與之工作概況，簡述如下：

(1) DRS SSA之執行

A.        DRS之PDS與新發展軟體

(A) Plus 32系統採用之軟體約90%為PDS，10%為新發展軟體.。

(B) VDU系統採用之軟體約10%為PDS，90%為新發展軟體。

B. DRS對PDS及新發展之軟體皆依IEEE 7-4.3.2之要求執行ACE分析。

(2) GENE SSA之執行

GENE對ESF各安全系統及其有關Plus 32與VDU系統皆執行風險分析與深度防禦評估，且對VDU各軟體發展階段亦依IEEE 7-4.3.2之ACE要求執行分析，GENE對上述各軟體安全分析皆採FMEA方法來執行。

(3) DRS SSA報告之審查

A.        GENE IVVT小組對軟體安全分析之審查

依龍門DCIS獨立驗證與確認計畫（IVVP）要求，安全系統及VDU各軟體發展階段之軟體安全分析報告完成後，須送GENE獨立驗證與確認小組（IVVT）審查，其審查意見需由GENE SSA小組解決後方可結案。

B.台電OIVVT審查

(A) 台電OIVVT對GENE所提ESF與VDU之風險分析與深度防禦評估報告、各軟體發展階段之VDU SSA ACE 報告，以及各相關共同檔（Plus 32系統平臺）之SSA評估報告，皆依相關法規與工業標準進行審查；同時，對風險分析與深度防禦評估報告特別加入核能安全分析專家對於GENE在系統與全廠層級對各假設軟體失效所引起之風險，及相對之緩和功能及分析是否正確特別加重審查。

(B) 對於VDU軟體各階段之ACE審查，是依IEEE 7-4.3.2-1993 App. F ACE辨識與解決之要求來審查GENE所提VDU SSA ACE報告。GENE各軟體發展階段執行ACE之方法與步驟，皆詳列在各階段SSA報告中供查閱與追蹤，以確認其符合IEEE 7-4.3.2-1993標準之要求。

(C) ESF各系統所有相關之SSA 評估報告皆已送台電OIVVT審查並提出意見，台電對GENE回覆OIVVT審查意見均逐項追蹤並接受後才結案。

(D) 台電OIVVT小組除審查DRS/GENE所提軟體安全分析報告外，亦赴DRS與GENE廠家稽查其相關SSA記錄，結果與報告所述相符。

3. 台電”軟體安全分析平行驗證”研發案執行平行驗證

GENE SSA作業除透過上述OIVVT與IVVT審查程式管控外，台電亦另撥預算從94～96年（共3年）由核研所執行”軟體安全分析平行驗證”計畫，對所有DCIS安全儀控系統以取樣方式，選取RTIF (NUMAC)與HPCF (DRS)兩系統獨立執行系統之風險分析、軟體需求、設計、編寫程式碼，一路到軟體測試完成，以與GENE之SSA作業及結果作平行驗證，以確認GENE對所有安全儀控系統在軟體發展階段之SSA作業是符合法規與標準要求。核研所工作同仁並分別於95與96年赴NUMAC與DRS，針對RTIF與HPCF系統之SSA作業執行循線稽查（Thread Audit），稽查結果與GENE所提之RTIF與HPCF SSA報告所述相符。

肆、台電提升自我管制之相關作業

台電為確保龍門計畫DCIS軟體安全分析之品質符合相關法規與標準之要求，從1997年龍門計畫安全系統儀控軟體之發展廠家陸續展開工作以來，陸續編列預算執行下述專案工作與研發案，來支援軟體（包括SSA）之審查與稽核等作業，以自我管制之方式提升軟體安全分析之品質：

4.1.「龍門計畫數位儀控系統軟體設計文件審查」專案

1.目的：本專案之目的為委託核研所協助台電公司執行龍門計畫數位儀控系統軟體設計相關文件（包括軟體設計輸出文件、SSA報告及GE IVVT之審查報告等）之審查工作，以確保龍門計畫數位儀控系統設計過程產出之軟體有關文件符合法規要求。

2.工作成果：本計劃自民國88年8月~96年12月已完成龍門計畫數位儀控系統規劃階段、設計定義階段、軟體設計階段、軟體程式碼階段、整合測試階段及確認測試階段之軟體設計文件、安全相關系統之SSA報告以及軟體驗證與確認報告約六百餘份文件，包括62份SSA報告。

4.2.「龍門計畫數位儀控系統軟體業主獨立驗証與確認」專案

1.目的：本專案之目的為落實龍門計畫安全系統儀控軟體（此包括軟體安全分析報告）之驗証與確認作業，以符合R.G. 1.168, Section 3有關時程與Resource（包括管理、財務及技術等）獨立性之需求，台電除要求GE IVVT小組人員需獨立於GENE龍門計畫設計團隊外之第三者外；亦另成立業主獨立驗証與確認小組（OIVVT）執行獨立驗証與確認作業，除落實龍門計畫安全系統儀控軟體（此包括SSA報告）驗証與確認之獨立精神外，更增進各方對於軟體安全分析作業之信心。

2.工作成果：本專案自民國88年3月~95年12月執行業主獨立驗証與確認作業，對於SSA之作業除審查SSA報告符合相關法規要求外，OIVVT亦赴軟體發展廠家與GENE執行現場訪談與查驗，以及針對SSA議題執行循線稽查（Thread Audit），循線稽查SSA Practices以及NMS、RTIF及ESF等安全系統之SSA做法，其報告為TAR-SSAP-001~5共5份。當然在執行上述獨立驗証與確認作業過程中所發現之異常項目，均會建立異常報告，並由台電移送至GENE及其下包廠家追蹤管制，目前均已改正到可接受。

4.3.「龍門計畫數位儀控系統軟體安全分析平行驗證」研發案

1.目的：由於龍門計畫執行軟體安全分析係大規模應用在全廠儀控系統，在全球核能界係屬首次，故包括美國核能管制委員會與台灣原子能委員會都非常關注此議題，並將其列為審照重點。GENE雖已依相關法規要求執行軟體安全分析，但因法規之規定未能詳盡完備，同時又是首次使用；以致管制單位、業主及廠家在法規引用及作業執行要求方面時有不同解讀。故，長期以來軟體安全分析執行情形一直是各方討論關注的焦點。因此台電公司為增進各方對軟體安全分析工作品質的認識與信心，並確保軟體安全分析之執行能落實而有效保障核能安全，特別成立「核四廠數位儀控系統軟體安全分析平行驗證」研發案，委託核研所對龍門DCIS系統執行平行抽樣軟體安全分析。

2.範圍：本計畫從NUMAC與DRS負責之軟體建置系統中分別選定RTIF及HPCF 2個安全系統，執行軟體安全分析平行驗證。

3.執行方式：在DCIS中選取RTIF (NUMAC)與HPCF (DRS)兩安全系統，在初期風險分析（Preliminary Hazard Analysis, PHA）中以分析表格，探討安全分析報告第15章事件分析與RTIF/HPCF之關連性分析，並以序列樹（Sequence Tree）分別以RTIF/HPCF正常反應及RTIF/HPCF失效情況下，探討系統層級各個事件中所參與儀控系統關聯性。同時，以不含失效率之軟體失效故障樹（Fault Tree Analysis, FTA），建立包含在兩系統各組件內各項失效之架構關係，及以失效模式及效應分析（Failure Mode and Effect Analysis, FMEA），平行執行軟體需求、設計、編寫程式碼，一路到軟體測試完成之軟體安全分析，以與GENE之SSA作業及結果作平行驗證，確認GENE對所有安全儀控系統在軟體發展階段之SSA作業是符合法規與標準之要求。

4.工作成果：本計劃自民國94~96年共3年完成兩系統各階段之軟體安全分析報告。同時，平行驗證GENE所提之SSA作業與報告，其結果是相符合。並各於95與96年赴NUMAC與DRS各針對RTIF與HPCF系統之SSA作業執行循線稽查（Thread Audit）。稽查結果與GENE所提之RTIF與HPCF SSA報告內容所述相符。故，經此平行驗證計畫案確認GE SSA小組對於SSA作業已依據相關法規與工業標準執行外，且其所產出之結果亦是可接受。

4.4.「龍門計畫數位儀控系統軟體安裝作業之評估分析」研發案

1.目的：目前龍門計畫合約，對於BTP-14所列之軟體需求階段到軟體確認階段之作業屬GE負責之範圍，而在龍門工地執行之軟體安裝階段工作屬台電責任，需由台電負責執行。因此台電公司為確保軟體安裝階段之作業符合法規之要求及對原能會之承諾，另撥預算提出研發案以發展對應的軟體安裝驗證與安全分析技術；來支援龍門計畫安全系統儀控軟體在安裝階段之工作，以確保所建置完成之各系統均能正確執行功能而有效保障核能安全。

2.目前現況：本計劃自民國96年9月執行迄今已完成：

(1)   「軟體安裝活動相關法規與工業標準整理分析報告」

(2)   「國外數位儀控系統安裝失誤相關事件報告」

(3)   「軟體安裝作業評估方法與接受準則分析報告」

(4)   「軟體安裝作業驗證工作程式書」

(5)   「軟體安裝作業安全分析工作程式書」

    現正待工地完成儀控設備安裝作業後，再依軟體安裝工作程式書執行39個安全系統之安裝後測試作業。最後依測試結果完成：

(1)   39個安全系統「軟體安裝作業驗證工作報告」

(2)   39個安全系統「軟體安裝作業安全分析工作報告」

(3)   39個安全系統「軟體安裝作業總結報告」

    本案執行完成後應可確保龍門計畫安全系統軟體安裝階段之V&V與SSA作業符合BTP-14之要求。

4.5.「龍門計畫分散控制暨資訊系統（DCIS）技術諮詢服務」專案（有關軟體部分）：

1.目的：台電為確保軟體生命週期各階段之SSA、V&V及CM作業符合BTP-14之要求，故除針對廠家在執行工地現場修改（FDI）之軟體修改、SSA、V&V及CM報告執行審查及稽查外，亦另對軟體安裝後測試（Post Construction Test, PCT）、試運轉測試（Pre-operation Test, Pre-OP）及起動測試（Start Up Test）等過程中有任何涉及軟體修改，以及需執行SSA、V&V及CM作業執行評估及審查作業。

2.目前現況：本計劃自民國97年5月開始到一號機商轉，目前廠家正執行FDI中，且陸續將FDI相關程式書送台電審查。後續執行龍門工地FDI、PCT及Pre-Op等有涉及軟體修改，台電亦將完成之軟體V&V、SSA及CM作業之相關報告送原能會核備。

伍、核能管制單位之監督

原子能委員會核管處對龍門計畫DCIS數位儀控之軟體發展（包括SSA作業）亦依BTP-14要求，在龍門計畫PSAR審查時即開始執行下述相關管制作業：

5.1.PSAR追蹤管制事項：

此為對數位儀控軟體特別重要項目，如軟體發展（包括SSA作業）作業（LM-P-07-01）與軟體獨立V&V (LM-P-07-02)等，要求每季提工作進度與特定議題說明，直至軟體發展工作完成為止。

5.2.龍門計畫注意改進事項

原子能委員會在審查相關軟體發展過程或文件發現有不符事項或需特別注意事項，則要求台電提出說明及改進，如與SSA議題有關為AN-LM-90-30與AN-LM-91-49等。

5.3.赴台電及軟體發展廠家現場稽查

原子能委員會為瞭解龍門計畫安全系統數位儀控之軟體發展作業（包括SSA作業）是否符合法規與標準之要求，不定期赴台電及軟體發展廠家現場稽查。如

1. 2000、20003及2006年各一次赴台電執行稽查作業

2. 2000及2003年配合OIVVT赴軟體發展廠家各執行一次稽查作業

3. 2004及2006年配合OIVVT赴軟體發展廠家各執行一次觀察（Observation）作業

5.4.審查廠家文件及台電審查報告

原能會依安全系統儀控軟體之重要性及BTP-14之要求，要求台電提送相關設計檔及台電審查報告給原子能委會審查。台電已陸續提送如廠家軟體發展計畫書及PRMS/CMS, RTIF, NMS,HPCF及SRV/ADS等系統之廠家SSA報告及台電審查報告，並回覆原能會審查意見直至結案。

5.5.定期/不定期報告

原子能委員會為瞭解龍門計畫安全系統儀控軟體之發展現況以及軟體特定議題處理情形，要求併隨DCIS定期或不定期提出報告，包括：

1. 每月提月報

2. 每季赴原子能委員會進行現況報告

3. 如有特定議題，則不定期赴原子能委員會報告，如台電於93年5月27日赴原子能委員會報告龍門計畫SSA之執行。

< 上一則

下一則 >