摘要
廠務系統穩定運轉–警報管理
前言
為什麼警報管理對於廠務穩定運轉扮演重要角色?主要達成三件事、即早偵測、持需改善、有效緊急應變。警報管理機制中完整的警報資料整合為第一要務，早期建廠採用中央整合平台實體建點，受限點數容量限制缺乏完整度 ，改由地方監控電腦進行資料庫的整合，設計不可以隔離 ，只能在中央整合平台隔離網頁進行，資料有任何中斷都會反映在整合監控電腦。
為了能即時將重要訊息傳遞至簡訊系統，既有的警報即時通系統整合廠務設備藍皮書及製造部機台，將訊息傳遞至廠務、生產單位副理與機台值班手機進行聯合應變，為了因應台積電的擴廠，組織、人員、系統的異動，分別建立變更診斷功能與管理報表，解決組織與系統的變動，重要警報不遺漏，不怕找錯人，做對完整的應變。警報管理需含蓋三種等級警報與未覆歸警報100/200/300及資安高/中/低，以確保系統的可靠度與妥善率。為避免值班對於警報失去警覺，對於事先安排的施工、保養、維修、測試、停機需進行單點隔離、群組隔離或統計制程管制(SPC)點隔離，以確保警報的完整度，降低運轉的潛在風險，運轉中警報點不准隔離。資安警報重要性 : 將資安管納入日常運轉與應變，利用公司的病毒戰情資料庫，將病毒警報( 高/中/低)整合到廠務警報(100/200/300)中，縮短病毒應變時間。
為了讓以上警報管理系統發揮功效，參考ISA 18.2建構警報管理循環、警報原則、了解處理警報能力、建立警報健康量測指標及管理目標以利達到即早偵測、持需改善、有效緊急應變及穩定運轉的目的。
文獻探討
在撰寫廠務系統穩定運轉–警報管理季刊之前，我們需釐清目的就是需確保系統穩定運轉，我們有必要重新檢視警報管理系統的完整度，透過ISA 18.2警報管理標準重新檢視其法條，並印證我們在開關門十件事中警報/隔離/資安管理是否遺漏之處，並進行有效改善。達到廠務零中斷及協助製造部零客訴、零缺陷及完美晶圓產出的目的，警報管理促使廠務深度反思，有效改善、停止缺陷、立即改善及以身作則，重塑廠務品質管理文化。￫圖1為警報管理循環永續改善。
圖1、ISA18.2 Alarm Management Cycle [1][2]
文中談到警報管理最重要就是警報基本原則(Alarm Philosophy)，您面對如何進行警報管理是否感受到挑戰?您是否有計畫進行有效警報管理?您的警報基本原則文件是否有用?建構基本原則是有效警報管理的核心及警報專案管理計畫的起點。
它定義了警報系統的角色如何控制系統安全、品質、生產與風險。以ISA 18.2Alarm Management Cycle為核心 ，教您如何設計、操作與維護。
有用的警報基本原則文件必須涵蓋如下￫表1￫表2 :
| Alarm Philosophy Contents | Required | Recommended | Health Check |
|---|---|---|---|
| Purpose of Alarm System | Y | Y | |
| Defintions | Y | Y | |
| References | Y | ||
| Roles and rcsponsibilities for alarm management | Y | Y | |
| Alarm design principles | Y | Y | |
| Rationalization | Y | Y | |
| Alarm class definition | Y | Y | |
| Highly managed alarms(or site equipvalent) | Y | Y | |
| HMI design guidance | Y | Y | |
| Alarm Setpoint Determination | Y | Y | |
| Prioritization method | Y | Y | |
| Alarm system performance monitoring | Y | ||
| Alarm System maintenance | Y | Y | |
| Testing of alarms | Y | Y | |
| Approved advanced alarm management techniques | Y | ||
| Alarm documentation | Y | ||
| Implementation Guidance | Y | Y | |
| Management of Change | Y | Y | |
| Training | Y | Y | |
| Alarm history preservation | Y | Y | |
| Related site procedures | Y | ||
| Special Alarm Design Consideration | Y | Y |
| Practical limits to human capabilities | |
|---|---|
| Very likely to be acceptable | Maximum manageable |
| ~150 alarms per day | ~300 alarms per day |
| ~6 alarms per hour(average) | ~12 alarms per hour(average) |
| ~1 alarm per 10 minutes(average) | ~2 alarms per 10 minutes(average) |
| Metric | Target Value |
| Percentage of 10-minute periods containing more than 10 alarms | ~<1% |
| Maximum number of alarms in a 10-minute period | ≤10 |
| Percentage of time the alarm system is in a flood condition | ~<1% |
| Percentage contribution of the top 10 most frequent alarms to the alarm load | ~<1% to 5% maximum, with action plans to address deficiencies |
| Quantity of chattering and fleeting alarms | Zero, action plans to correct any that occur |
| Stale alarms | Less than 5 present on any day, with action plans to address |
| Annunciated priority distribution | 3 priorities:~80% low, ~15% medium, ~5% high 4 priorities:~80% low, ~15% medium, ~5% high, ~<1% highest Other special-purpose priorities excluded from the calculation |
- 定義管理警報系統的責任
- 建立系統持續改善的機制
- 確保新系統沒有增加過多的警報
- 對於系統安全性警報必須Highlights
- 促進系統一致性
- 建立設計標準
- 建立報告格式與應變SOP
- 定義警報重要的優先順序
- 建構有實戰經驗好的警報範本與模組
在維護警報管理系統常發生問題主要涵蓋如下￫表3 :
| Item | Other Useful Alarm System KPIs | Management Target |
|---|---|---|
| 1 | Top 10 most frequently occurring alarms | <5% of Total(over 30 days) |
| 2 | Number of long standing/stale alarms | <5 With plans to address |
| 3 | Unauthorized alarm property changes | 0 |
| 4 | Chattering alarms | 0 |
| 5 | Number of alarm peaks per time period(alarm floods) | (10 alarms/10 min)<1% |
| 6 | Priority distribution of alarms | 80% Low ; 15% Medium ; 5% High ; 1% Highest |
| 7 | Number of alarms per operating position | 6~12 Alarm/1 Hour |
| 8 | Suppressed alarms outside of approved methodologies | 0 |
- 不一致的系統設計
- 上線系統警報不完整
- 新系統擴充不一致的擴充與試車
- 操作者對於警報意義與管理系統不熟悉
- 管理者是否了解每小時發生多少警報及多少警報被隔離
- 警報隔離時間過長或忽略及警報聲被關掉 。警報多久才進行確認及靜音處理
- 移交後的警報處理不落實
研究方法
3.1.廠務監控系統_資料流確認完整度￫圖2
圖2、廠務監控系統_資料流
SI系統整合所有廠務監控電腦(SCADA)與分散式控制系統(DCS)系統警報(Alarm)與即時曲線(Trend)匯聚在資料庫(DB)。所有系統警報與品質管理報表依據權責與管理層級分派至工程師及主管。為了加速警報日後管理與整合在建廠的設計過程已將人機介面標準化符合ISA 18.2警報管理的要求包含廠務系統架構圖、網路通訊協定、軟硬體需求、共通檔案格式、畫面規劃、規格及命名原則、重覆刪除 、警報記錄及等級、字型、圖型處理規範、必須製作的圖面內容、 各廠家配合資料及方式報表資料。為了強化警報管理與應變有效性人機介面需含系統網路架構圖、系統盤位置圖、系統盤電源架構圖、系統控制電源/控制器/IO卡/通訊卡異/儀表/控制閥/VFD異常系統警報、系統控制流程圖、系統控制流程說明、環狀連結應變狀態檢查表、應變聯絡清單及系統變更流程。
3.2.警報系統與隔離100%整合架構￫圖3￫圖4
圖3、警報系統100%整合架構 [6]
圖4、隔離網頁100%整合所有Local SCADA
確保警報完整度、需以資料庫整合廠務、化學實驗室 、製造品質暨可靠單位及庫房原物料警報。確保廠區安全 、環境、品質、生產、系統穩定運轉。讓訊息能夠傳遞至有利害關係的單位，以利進行系統的保養、維修、改善及聯合緊急應變。端賴事前規劃以廠務警報來源為例分為三大部份 : DCS分散控制系統、SI整合系統及電力系統。SI整合系統運用環狀網路整合機電水氣化24套監控電腦，警報改採資料庫整合降低了中央整合平台(SI Intouch)實體建點負擔。警報隔離由SI改為網頁執行。警報建點只需建置一次減少重工、改善整合系統(SI)軟體點限制，改善完整度與變更負擔。以中科廠務為例約管理兩百萬個警報屬性。警報分為歷史警報與未復歸警報。警報資訊包含 : 警報100、警報100未回覆、警報200、300、資安High、Medium及Low。警報未復歸資訊包含總數、警報100、警報200及警報300未復歸。警報隔離資訊包含SPC隔離、SPC隔離逾期 、群組隔離、Tag隔離、Tag隔離逾期。警報隔離管理最大困難是隔離紀律，因隔離錯誤導致系統中斷，所以群組隔離需排除高風險警報100警報，系統需運用智能偵測機制提醒操作者，避免線上隔離造成誤操作。
3.3.警報資料流監視功能及警報設定的完整度
由於警報管理系統與日常運轉緊密結合，所以系統可靠度非常重要，開關門十件事平台，功能分為管理、檢查、作業層及管理報表，其中檢查層指標監視資料流是否正常，讓重要訊息不遺漏。ISA 18.2談到警報基本原則，定義系統製程警報與規格，警報選定決定系統那些需設為警報及合理化建立合理警報分類優先順序說明後，需定期檢視警報是否有功能，運用資料庫進行查核避免重要警報遺漏，造成無法掌握狀況，異常通報與應變。
3.4.警報定義與自動簡訊通報￫表4
| 等級 | 定義 | 處理時效 | 最高層級電話通報 | FAB廣播 | 最高層級SMS通報 | 範例 |
|---|---|---|---|---|---|---|
| 100 | Critical : 已造成或即將造成ESH事件及生產影響 | 立即通報工廠進行搶救，將生產與ESH影響降至最低或防堵造成立即生產影響，並立即進行系統復原 |
FAC : 副處長 部經理 事故副理 ERC : 副理，值班 |
ERC FAC (註1) |
FAC : 副處 ERC : 副理，值班 FAB : 參照異常簡訊通報原則 |
空污、水污、Quality OOC/S、三級以上地震 、15%以上壓降 or 10%>0.1sec、CB斷電 、UPS電池放電、PLC異常、安全Interlock |
| 200 | Alarm : 系統異常警報 | 立即處理，避免異常惡化造成100 警報，並於當日內完成系統復原 | - | - | 副理 | SPC OOC Pre Alarm 、Pump故障 N+1 OK |
| 300 | Warning : 矽統一般警報 | 值班工程師當班完成防堵，避免異常惡化造成200以上警報，並交接 系統工程 師於三日內完成改善 | - | - | 系統工程師 | Chiller油壓差、MAU filter壓差 |
註1 : Quality OOS需立即通報至副處長，若為真實狀況需通報ERC進行廣播
讓警報傳遞至負責主管與系統工程師及運轉廠商分層負責，運用廣播、電話與自動簡訊通報環保工安健康、生產品質 、系統警報，進行工安環保/製造/設備製程/品管單位聯合應變，有效降低應變時間。為了降低運轉負擔，警報簡訊分成日夜間模式，高風險警報100，夜間僅傳遞至值班人員，系統工程師及主管以利應變，也強化了徹底解決問題的動機，將系統改善好。但是若發生警報泛洪(Alarm Flooding)，緊急應變過程重要警報就可能被淹沒，針對廠務重要系統機電水氣化及電腦機房會影響廠務的運轉安全與製造部生產與品質，建立警報模擬燈號看板，以紅黃綠燈表示供應與品質的狀態。讓廠務值班第一手掌握廠務設施與生產環境的狀況、異常通報、成立ERT及安全防護。
3.5.警報管理作業層建立
需可追溯分析可管理需要有如下欄位 : 組織、系統與值班負責人 : 附件含蓋狀況原因、影響說明、影響範圍、處理說明、預防處理與結案日期及異常Trend Chart。警報分類應分成十大項一般警報(ALM)、操作失務(MO)、零件故障(CF)、軟體異常(SB)、雜訊干擾(NI)、待確認中(PS)、定期保養(PM)、施工造成(ENG)及系統測式(TEST)。警報處理需有警報群組成事件及資料剃除功能。但是由值班與系統工程師來進行，有人為的因素需進行管理，若能運用AI運算將能減少人為的因素在裏面可以運用系統、時間及Tag進行群組化及關連，讓我們警報事件分析不失焦。而資料剃除功能則必需被嚴格定義及簽審制度把關 。警報管理作業層具備報告與歷史曲線(Trend)及影響範圍，就能有效的追蹤與管理及持續的改善。為了解作業層填寫的紀律與品質，須建構管理報表，定期進行警報管理處理過程的稽核改善。
3.6.警報管理報表層發展￫圖5￫圖6
圖5、 tsmc FD開關門十件事平台-警報/隔離/資安管理
圖6、Critcal Raw Alarm Count系統與原因的佔比分析
目的是要降低管理的負擔，能快速提供管理者系統異常分析到底是人為因素，元件故障、設備故障、不可抗力及系統測試，做為主管管理與努力的方向。
3.7.警報管理平台後台參數設定與管理
- 警報減量目標設定與宿疾規則頻率的設定
- 組織/系統/原因/影響分類的設定
- 警報參數變更管理屬性設定 : 參數修改管制項目包含SP、alarm setting、range、Offset及其他會影響baseline之設定
3.8.警報管理統計與分析報表
- TOP10警報單點數量與群組事件數量統計與分析報表
- 宿疾警報數量統計與管理追蹤￫表5
表5、宿疾警報清單產生以利檢討改善
- 每日未復歸警報數量統計與管理追蹤
- 未填警報原因確認的統計及未結案的統計與管理追蹤￫圖7￫圖8￫圖9
圖7、 tsmc FD開關門十件事平台警報作業層
圖8、 tsmc FD開關門十件事平台警報每日確認率
圖9、tsmc FD開關門十件事平台警報作業層未確認清單及補填原因
- 警報資料庫異常的統計及異常的管理追蹤
3.9.警報基本原則及變更管理的建立
警報的基本原則定義在相關參數變更管理及警報定義O.I.，透過變更管理平台填寫申請單經過系統專家與主管審核同意後進行施作。變更申請內容包含申請日期、負責工程師、施工類別、工程師單位、系統、版本、施作地點、施作廠商、施作人員、工作項目、影響範圍、工作目的及工作內容。變更修改前準備文件包含一頁報告、修改前系統備份項目、施作項目圖控修改清單、施作步驟檢查表、管路儀表流程圖、程式控制邏輯異動說明、驗收檢核表系統、長期作業-行軍表及額外需要的附件。相關需變更系統平台清單包含SPC-Keynode/General、SPC-O.I.、SPC-Upload、SPC-iEDA、SPC-eO-CAP、SPC-FDC、DCS-參數/畫面/邏輯、SI-警報/畫面/ROFS/歷史資料、Auto Trend Chart、SMS(簡訊)、F-Charter、 Capacity、Tank Monitor、SPC Daily、300mm SMP、ISMP、Box Flow Chart、合一系統、Mimic、ICCI及開關門十件事 ，來確保警報管理完整度，當發生廠務重大異常也能即時掌握狀況，異常通報，成立ERT及安全防護，將廠務的運轉風險降至零。
結果與分析
台積電廠務處建構廠務開關門十件事平台建構了管理層、檢查層、作業層及報表層，其中警報管理涵蓋警報、隔離與資安警報的統計。警報涵蓋了每日廠務歷史警報與未復歸警報及機台警報。為了強化網路安全(Cyber Security)系統維護與應變， 將資安管理納入日常運轉與應變，利用公司的病毒戰情資料庫，將病毒警報(高/中/低)整合到廠務警報(100/200/ 300)中，縮短病毒應變時間。 資安警報分成三種等級 : 資安高度警報→病毒警報(如WanaCry)；資安中度警報→病毒警報 ，防毒碼更新>7天，補丁(Patch)更新逾期；資安低度警報→病毒警報，病毒碼伺服器連線中斷。資安警報需納入緊急簡訊系統以利快速應變。警報隔離則涵蓋SPC隔離與SPC隔離逾期、群組隔離、Tag隔離及Tag隔離逾期。
結論
若從ISA18.2警報管理目標進行檢討，我們需把TOP10警報數量統計及宿疾指標震顫報警(Chattering alarm)納人日常化運轉檢討降低值班負擔。讓弟兄持需掌握現在警報100、過去宿疾警報及Top10警報、未來警報200/300，持續改善系統 。對於未授權或未審核警報屬性變更需自動掌握警報標籤(Alarm Tag)並確認。重點的警報100隔離管理需再增加，避免重大異常無法掌握與應變，特別是需有機制自動偵測系統在線上(In Process)被隔離，強化最後防線的管理。針對警報泛洪單位時間產生警報統計及極高、高、中、低設置警報佔比健康指標納入各系統監控電腦，以利層別系統問題，再透過中央整合平台(SI)進行由Site、Phase、部、課及系統的統計，以維持警報管理系統的健康度。由於半導體發展速度非常的快，平均十一個月完成一個Phase建廠工作，所以警報管理分三個階段 :
第一階段建廠整合測試期間 :
應聚焦在廠區系統、環境與人員安全及功能完整。
第二階段成廠機台安裝期間 :
提供同母廠原物料、環境及廠務設施運轉警報參數，讓機台在3個月安全試車及生產。
第三階段廠務與機台穩定運轉期間 :
做好穩定運轉警報等級變更管理及系統容量警報管理。
第一個管理問題 :
報表需以Phase為單位澄別不同的運轉狀態，訂定各階段目標，避免重要問題被淹沒。
第二個管理問題 :
警報與測試如何澄別，這會模糊警報管理的焦點及造成警報管理的負擔，產生測試與真實警報統計，導入測試簡訊與真實警報簡訊系統，搭配驗收團隊(Sign Off)廠務/工安/機台設備做好完整測試後，系統自動導入真實警報管理系統。
第三個管理問題 :
如何讓保養、維修、測試隔離進行中排除線上高危警報100，避免人員操作錯誤造成安全與生產的影響。
總結以ISA18.2標準對於監控系統警報管理仍有努力空間包括警報健康度監視(Alarm Metric)、及警報指標管理目標達成。
參考文獻
- Understanding and Applying the ANSI/ISA 18.2 Alarm Management Standard Page 3 Bill Hollifield.
- ABB Alarm Management Lifecycle for the Process Industries-2019 Page 3.
- ABB General Facesheet alarm philosophy Page 2.
- Alarm Management for DeltaV™ :White Paper October 2019 Page1 & Page 6.
- Alarm Management and Best Practice Jason P. Wright Product Marketing Manager PlantPAx.
- TSMC FMCS Brief : 廠務監控系統簡介-2016王明富 Page 20。
- Lumax tsmc Fab15 P7Facility System Data Integration Requirement-2018 Page 26.
留言(0)