Alarm 一直響,哪些才真正影響生產?用 MES 建立設備警報 Pareto 分析
一台設備每天可能產生數十甚至數百筆 Alarm,但發生最多次的警報,就一定最值得優先改善嗎?有些 Alarm 一天出現 50 次,每次只有幾秒;有些只發生 2 次,卻造成數小時停機。若只看警報次數,很容易排錯改善優先順序。本文將介紹如何利用 MES 串聯設備 Alarm Code、發生時間、持續時間、停機狀態與生產數據,建立 Alarm Pareto 分析,並進一步將警報轉換成停機時間與損失產量,找出真正影響設備可靠度與生產效率的 Top Alarm。
為什麼設備 Alarm 很多,現場卻不知道該先改善哪一個?
設備自動化程度越高,可產生的 Alarm Code 通常也越多。
常見包含:
- 送料異常
- 感測器異常
- 定位失敗
- 馬達過載
- 壓力不足
- 溫度異常
- 安全門開啟
- 通訊異常
- 模具異常
- Servo Alarm
問題是,如果 MES 只是把 Alarm 全部列出來,管理者最後得到的可能只是另一張「很長的異常清單」。
真正需要的是:
哪些 Alarm 對生產影響最大?
Alarm 發生次數最多,不代表影響最大
假設設備一個月發生:
| Alarm | 次數 | 累積時間 |
|---|---|---|
| A01 送料異常 | 180 | 45 分鐘 |
| A02 感測器異常 | 95 | 80 分鐘 |
| A03 Servo 異常 | 8 | 420 分鐘 |
| A04 馬達過載 | 3 | 300 分鐘 |
如果只看 Frequency,A01 應該優先改善。
但若按照 Downtime 排序,真正造成重大生產損失的反而是 A03 與 A04。
因此 Alarm 分析至少應同時考慮:
Frequency × Duration × Production Impact
Alarm Frequency 可以看出什麼?
找出重複性異常
Alarm Frequency 適合發現「一直發生,但每次很快恢復」的問題。
例如送料異常一天發生 60 次。
每次只需要操作員重新定位即可恢復,因此維修紀錄可能完全沒有留下資料。
但高頻率 Alarm 可能代表設備存在:
- 感測器位置問題
- 送料機構不穩
- 材料尺寸差異
- 治具定位問題
這類問題也可能與 Micro Stops 密切相關。
Alarm Duration 為什麼同樣重要?
另一種情況是:
某 Alarm 一個月只發生兩次。
但每次都造成設備停機 3 小時。
這種 Low Frequency、High Impact 的 Alarm 若只依次數排序,很容易被忽略。
因此 Dashboard 應同時呈現:
Alarm Count
以及:
Total Alarm Duration
才能避免只改善「很常發生但影響很小」的問題。
MES 如何建立 Alarm Pareto?
MES 可由 PLC、設備控制器或 IoT Gateway 自動取得:
- Machine ID
- Alarm Code
- Alarm Name
- Alarm Start Time
- Alarm End Time
- Duration
- Machine Status
- Product
- Work Order
- Process
- Mold
- Operator
再將 Alarm 依不同維度進行統計。
例如:
Alarm Code → 次數 → 累積時間 → 平均時間 → 損失產量
就能建立比傳統 Alarm Log 更有管理價值的 Pareto。
如何把 Alarm 轉換成損失產量?
假設:
A03 Servo Alarm
一個月累積:
420 分鐘
設備標準 Cycle Time:
7 秒/件
理論產量損失:
420 × 60 ÷ 7 = 3,600 件
因此 Dashboard 不應只顯示:
A03:停機 420 分鐘
還可以進一步呈現:
Estimated Lost Output:3,600 件
管理者便能更直接理解這個 Alarm 對產能造成的影響。
哪些 Alarm 值得優先改善?
可將 Alarm 分成四種類型。
高頻率、高影響
發生很多次,而且累積停機時間長。
這通常是最優先改善的問題。
高頻率、低影響
大量 Micro Stops 或短暫異常。
單次影響不大,但可能持續侵蝕設備效率。
低頻率、高影響
不常發生,但一旦發生就造成長時間停機。
適合建立備品、維修 SOP 與預防措施。
低頻率、低影響
可列入觀察,但改善優先順序通常較低。
如此比單純按照 Alarm Count 排序更符合實際管理需求。
Alarm 與 MTBF/MTTR 如何結合?
Alarm Analysis 可以進一步與設備可靠度指標串聯。
例如某設備 MTBF 持續下降,MES 可以再往下分析:
MTBF 下降 → 哪些 Alarm 增加?
若發現 Servo Alarm:
上月:3 次
本月:8 次
下月:15 次
就可能代表設備某個部件正在逐步劣化。
另一方面,若特定 Alarm 的 MTTR 特別高,也可檢查:
- 是否缺乏維修 SOP
- 是否等待備品
- 是否故障診斷困難
- 是否需要原廠支援
讓 MTBF/MTTR 從 KPI 進一步連結到具體改善原因。
Alarm Pareto Dashboard 應呈現哪些資訊?
建議包含:
- 今日 Alarm Count
- Alarm 累積時間
- Alarm Frequency Pareto
- Alarm Duration Pareto
- Alarm Lost Output Pareto
- 設備 Alarm 排行
- Alarm Code 趨勢
- 平均 Alarm Duration
- Alarm 與停機關聯
- Alarm 與 Micro Stops 關聯
- MTBF/MTTR
- 改善前後比較
其中最推薦同時建立三張 Pareto:
發生次數 Top 10
停機時間 Top 10
損失產量 Top 10
三個排行不一定相同,而這個差異本身就是很有價值的設備改善資訊。
如何建立設備 Alarm 改善流程?
建議形成:
設備產生 Alarm → MES 自動蒐集 → Alarm 分類 → Frequency/Duration 分析 → 換算 Lost Output → Pareto 找出 Top Alarm → Root Cause Analysis → 執行改善 → 比較改善前後 Alarm
如此 Alarm Log 才不只是設備故障歷史,而能真正成為持續改善資料。
導入 Alarm Pareto 分析有哪些效益?
- 找出真正影響生產的設備警報
- 避免只依 Alarm 次數判斷問題
- 降低重複性設備異常
- 找出高影響低頻率故障
- 降低設備非計畫停機
- 改善 Micro Stops
- 提升 MTBF
- 降低 MTTR
- 建立設備改善優先順序
- 提供預防保養數據依據
本著作係採用創用 CC 姓名標示-相同方式分享 3.0 台灣 授權條款授權.
