| 開始列印 | 關閉本頁 |
此頁面的列印功能,你可使用瀏覽器上的網頁列印功能或使用快速鍵(Ctrl + p)來替代。
此頁面的關閉視窗功能,可使用快速鍵(Ctrl + w)來替代。
編號:
AN - LM - 99 - 006
開立單位:
核安管制組
廠別:
核四廠
日期:
2010 年 01 月 22 日
注意改進事項:
龍門核電廠安全系統軟體構型管理作業視察發現
注意改進內容:
請針對本次視察發現及建議,進行檢討改善,請於文到之日起一個月內,以全案方式提出第一次處理改善答覆及澄清說明。爾後於二、五、八及十一月份,依第十七次龍門核管會議結論,以全案方式併每季注改事項現況表及統一提送處理改善答覆表審查要求,提出後續追蹤答覆,至全案結案為止。
(一)建廠階段
(1)在龍門電廠建廠階段,台電公司雖可透過ReTrad與IMS系統有效地掌控DCIS各廠家軟體發展過程之SSA、IV&V、HFE、BRR等審查文件及各式軟體發展計畫與安全分析報告等,然對於軟體較具體之數量與版次等資訊則應作更有效地管控,建議台電公司應檢討目前機制並收集此方面的資訊。
(2)依BTP14之定義 (P.42, Fig 7A1),在安裝階段System Build Documents及Installation Configuration Tables兩份文件擔負重要任務,前者敘述如何由程式碼 (Source Codes) 製作目的碼 (Object Codes),後者敘述如何將目的碼與現場環境設備 (sensors, memory, communication, actuators, etc.) 結合完成可執行機器碼 (executable core image)。負責安裝之單位必須能充分掌握這兩份文件,才能正確將各廠家的設備組合成一完整 (complete)、相容 (consistent) 的整合系統 (integrated system)。然由此次台電公司所提供之資料中並未發現此兩份文件,建議台電公司確認廠家是否已建立此兩份文件,並澄清此兩份文件包含哪些資訊。
(3)經查證安全軟體開發過程有使用軟體工具 (例如DRS軟體開發工具Orcad),由於軟體工具的版次變更有可能會影響軟體開發,建議台電公司應補充說明軟體工具的軟體構型管理之管控情形。
(4)針對SCM查核表所列之27項問題 (如附件一),分為與SCM工作程序相關15題及與SCM執行結果相關12題。前者較無問題,後者目前台電公司答覆僅列出SCMP規畫工作項目而非執行成果。請台電提供與執行結果相關之文件編號名稱,再根據文件內容作進一步評估。
(5)GE在SCMP 3.7節承諾執行Configuration Audit,其中包含Functional Configuration Audit (FCA, SCMP 3.7.2) 及 Physical Configuration Audit (PCA, SCMP 3.7.3)。由此兩項內部稽查活動可判斷GE SCM之工作效率、效能 (efficiency and effectiveness),也是整個SCM活動中實質發揮防堵「不正確或有缺陷之材料、零件及(軟、硬體)組件」被納入安全系統之組態中的關鍵動作;因此報告內容對於研判GE是否確實依其自訂之計畫內容執行SCM工作極具參考價值,建議台電公司應設法取得這兩份內部稽查報告,並補充提供進行這些audit所完成工作項目之completed checklist。
(6)目前安全軟體構型管理作業主要由核技處與電廠相關人員參與,建議台電公司應建立適當的安全軟體構型管理品保制度,將建廠階段之軟體與軟體設計修改文件列為必要的移交項目,並明確訂定軟體構型管理的管制點、管制權責及驗收機制等。廠家設備交運的驗收作業及施工處移交系統設備給電廠的移交作業都應該把軟體列為驗收及移交項目。
(7)針對安全軟體,目前台電公司係以EPROM為管制單元。此次視察至FID programming station實地瞭解DRS FID燒錄至EPROM製作firmware的控管過程。訪談過程得知DRS Div 0 0H23-PL-2301S RMU盤之其中一片卡片,其EPROM由於需disable二號機之訊號,乃直接由DRS駐廠TA進行臨時性修改,並於設備上吊掛臨時修改標籤。此DRS FID臨時性修改雖不違反程序上的規定,然由於整個過程涉及EPROM (內含軟體) 的更換,為降低相關作業的風險,請台電公司慎重考量加強涉及EPROM燒錄的軟體管控機制。
(二)商業運轉階段
(1)目前龍門電廠委託核研所所建置的龍門核電廠DCIS數位儀控構型管理系統較偏重軟體的儲存、管理及復原,並無法窺知各軟體之發展流程。為因應未來軟體修改與更新的需求,建議此系統應考量加入software configuration之概念。又該構型管理系統設定於商轉後才上線使用,無助於目前一般軟體欠缺軟體構型管理管控機制之改善,台電公司宜對一般軟體補齊目前軟體構型管理管控機制之空窗期。
(2)目前龍門電廠在軟體構型管理的規劃是將多個構型管理相關程序分散在幾份程序書中,並沒有統一、整體之規劃。建議台電公司建立一上位型之構型管理計畫,整合未來軟體維護工作,並將構型管理及Configuration Control Board (CCB)、Responsible Configuration Control Engineer (RCCE) (GE發展階段有此組織與專人) 等專有名詞和既有軟體更換等流程作適當的關聯及說明。
(3)台電公司核一、二、三廠執行維護方案 (Maintenance Rule,簡稱MR) 有專人擔任MRC (MR Coordinator)。建議龍門電廠構型管理作業亦應有受過專業訓練之專責人員,以configuration control coordinator身分提供表格、流程協助、軟體configuration item現況管控、status accounting及協助QC/QA人員進行review與audit。
(4)DCIS數位儀控構型管理系統未來將接收各廠家移交之各類軟體,請台電公司評估此系統與各廠家系統之間的銜接性,並補充說明此系統未來如何管控這麼多不同廠家的軟體。
(5)目前台電公司委由核研所開發之DCIS數位儀控構型管理系統之軟體管控方式係採隨機接收之機制,很難確認此系統是否已完全涵蓋所有之軟體,請台電公司檢討目前之機制以確保此系統的完整性。
處理狀態:
已結案
處理情形:
台電已完成相關改善,同意結案。
參考文件: