未清潔滿瓶誤送維修廠事故｜拆閥前 Pressure Confirmation 的重要性

06-05｜未清潔滿瓶誤送維修廠造成壓力盤洩壓事故案例

鋼瓶進入 Maintenance Area（維修區域）之前，最重要的基本條件之一，是確認鋼瓶目前的實際狀態。

不能因為鋼瓶：

・已經送到維修廠
・掛有待維修標示
・進入維修流程
・外觀看起來與一般待修鋼瓶相同

就直接假設：

Cylinder Depressurized
（鋼瓶已無壓）

或：

Cylinder Ready for Maintenance
（鋼瓶已具備維修條件）。

本案例中，一支實際仍具有高壓內容物的 Full Cylinder（滿瓶／仍有高壓內容物鋼瓶）被誤送至維修端。

維修人員並未直接進行 Valve Removal（拆閥），而是依既有流程先連接 Pressure Panel（壓力盤）進行拆閥前 Pressure Confirmation（壓力確認）。

連接後發現鋼瓶仍具有高壓，過程中壓力盤上的 Protective Device（保護裝置）發生動作，同時造成 Pressure Gauge（壓力錶）損壞。

本案例最重要的經驗不是：

「壓力盤發生異常。」

而是：

一支狀態不符合維修條件的鋼瓶，為什麼能夠進入維修流程？

同時也證明：

Pressure Confirmation Before Valve Removal
（拆閥前壓力確認）

是一道非常重要的 Independent Safety Barrier
（獨立安全防護層）。

一、案例概要

事件類型：

Unexpected Cylinder Pressure
（非預期鋼瓶壓力）

鋼瓶狀態：

Full Cylinder / Pressurized Cylinder
（滿瓶／仍具有高壓內容物的鋼瓶）

異常流程：

鋼瓶在尚未完成前端必要處理的狀態下，被誤送至 Maintenance Area（維修區域）。

維修人員依流程進行：

Pressure Confirmation Before Valve Removal
（拆閥前壓力確認）

在 Pressure Panel（壓力盤）確認過程中發現高壓。

事件結果：

・Protective Device Activation
（壓力盤保護裝置作動）

・Pressure Gauge Damage
（壓力錶損壞）

・Valve Removal 未繼續進行

・未發生人員傷害

這起事故同時存在：

Upstream Process Failure
（上游流程失效）

以及：

Downstream Safety Barrier
（下游安全防護層）

兩個值得分析的部分。

二、鋼瓶送到維修廠不代表已經無壓

這是本案例最重要的第一個觀念。

在正常流程中，維修人員可能預期：

送到 Maintenance Area
（維修區域）

的鋼瓶已經完成前端必要處理。

但：

Expected Condition
（預期狀態）

不能取代：

Actual Condition Verification
（實際狀態確認）。

因此：

Cylinder in Maintenance Area
（鋼瓶位於維修區）
≠
Cylinder Depressurized
（鋼瓶已無壓）

同樣：

Maintenance Label
（維修標示）
≠
Physical Condition Confirmed
（實際物理狀態已確認）

這也是為什麼拆閥前仍需要進行獨立確認。

三、Pressure Panel 的作用是確認，不是預設

本案例中，Pressure Panel（壓力盤）的重要功能之一，是在 Valve Removal（拆閥）之前確認鋼瓶實際壓力狀態。

它回答的是：

「這支鋼瓶現在實際還有沒有壓力？」

而不是：

「上游說沒有壓力，所以應該沒有壓力。」

因此：

Upstream Status
（上游狀態）
＋
Label / Record
（標示／紀錄）

仍需要：

Physical Verification
（實際確認）

形成另一道 Safety Barrier（安全防護層）。

四、如果沒有拆閥前壓力確認，風險會更高

本案例中，維修人員並沒有直接進行 Valve Removal（拆閥）。

而是先執行：

Pressure Confirmation
（壓力確認）。

因此高壓異常是在拆閥前被發現。

這是一個非常重要的 Safety Barrier Success
（安全防護層成功攔截）。

如果流程只有：

Cylinder Received
（接收鋼瓶）
↓
Assume Empty
（假設無壓）
↓
Valve Removal
（拆閥）

那麼一旦上游狀態錯誤，後果可能更加嚴重。

因此正確的安全概念不是：

「上游已經確認，所以維修端不需要再確認。」

而是：

Independent Verification
（獨立確認）

可以防止單一道流程失效直接演變成更嚴重事件。

五、Pressure Panel 不是用來處理 Full Cylinder

這一點必須特別說清楚。

Pressure Panel（壓力盤）在本案例中的角色是：

Pressure Confirmation
（壓力確認）

以及：

Abnormal Condition Detection
（異常狀態偵測）。

不能因為這起案例中 Pressure Panel 發現了 Full Cylinder，就把它理解成：

「如果鋼瓶有壓，就利用維修壓力盤把內容物處理掉。」

這不是本文要表達的概念。

因此：

Pressure Panel
（壓力盤）
＝
Verification / Detection Tool
（確認／偵測工具）

而不是：

Full Cylinder Processing Equipment
（滿瓶處理設備）。

一旦發現鋼瓶仍具有異常壓力：

維修作業應停止，

並依核准程序進入適當的異常處理流程。

本文不提供高壓鋼瓶內容物排放或洩壓操作方式。

六、Protective Device Activation 代表什麼？

本事故中，Pressure Panel（壓力盤）上的 Protective Device（保護裝置）發生動作。

這裡必須避免寫得太具體。

因為如果沒有原始設備資料確認：

・Protective Device Type（保護裝置種類）
・Set Pressure（設定壓力）
・Operating Principle（作動原理）

就不應自行推測它是：

Safety Valve
Relief Valve
Burst Disc
或其他特定裝置。

因此公開文章比較正確的寫法是：

Pressure Panel Protective Device Activated
（壓力盤保護裝置發生作動）

而不是直接指定某一種設備名稱。

這也是技術文件的重要原則：

Unknown Device Type
（裝置種類尚未確認）

就保留：

Unknown
（未知）

不要為了讓文章看起來完整而自行補上答案。

七、Pressure Gauge Damage 是結果，不是 Root Cause

本案例造成：

Pressure Gauge Damage
（壓力錶損壞）。

但如果事故分析只寫：

Problem：
Pressure Gauge Damaged

Corrective Action：
Replace Pressure Gauge

就會漏掉真正重要的問題。

Pressure Gauge Damage 是：

Event Result
（事件結果）

而不是：

Root Cause
（根本原因）。

真正應該調查的是：

「為什麼高壓鋼瓶會進入維修流程？」

因此：

Damaged Gauge
（壓力錶損壞）
↓
不是調查終點

而應該繼續追查：

Why was a Pressurized Cylinder Sent to Maintenance?
（為什麼仍有高壓的鋼瓶會被送到維修端？）

【照片 06-05-02｜事故後損壞的 Pressure Gauge】

八、真正需要調查的是 Upstream Process

本案例的重要問題是：

一支仍具有高壓內容物的鋼瓶，

為什麼會進入：

Maintenance Process
（維修流程）？

因此 Root Cause Analysis（根本原因分析）不能只停在維修現場。

需要向上游追查：

・Cylinder Status Identification
（鋼瓶狀態識別）

・Process Routing
（流程路由）

・Cleaning / Preparation Status
（前端處理狀態）

・Label Status
（標示狀態）

・Work Record
（作業紀錄）

・Handover
（交接）

・Physical Verification
（實際狀態確認）

・其他相關 Safety Barrier
（安全防護層）

這起事件的核心問題屬於：

Wrong Process Entry
（錯誤流程進入）

或：

Status Control Failure
（狀態管理失效）

而不是單純：

Pressure Panel Failure
（壓力盤故障）。

九、這是一個 Safety Barrier 成功與失敗同時存在的案例

這起事故非常適合用多層 Safety Barrier（安全防護層）的方式分析。

上游：

Cylinder Status Control
（鋼瓶狀態管理）

沒有成功阻止一支仍有高壓的鋼瓶進入維修區。

這是一個：

Barrier Failure
（防護層失效）。

但是維修端：

Pressure Confirmation Before Valve Removal
（拆閥前壓力確認）

成功在 Valve Removal（拆閥）之前發現異常。

這是一個：

Barrier Success
（防護層成功）。

因此事故可以表示成：

Pressurized Cylinder
（仍有高壓的鋼瓶）
↓
Upstream Status Control Failed
（上游狀態管理失效）
↓
Cylinder Entered Maintenance Area
（鋼瓶進入維修區）
↓
Pressure Confirmation
（拆閥前壓力確認）
↓
Unexpected Pressure Detected
（發現非預期壓力）
↓
STOP
（停止後續維修）
↓
Valve Removal Prevented
（避免進一步拆閥）

這正是多層安全防護存在的目的：

不是假設前一道永遠不會出錯，

而是當前一道失效時，

下一道仍有機會攔截異常。

十、Label 不能取代 Physical Verification

即使鋼瓶具有：

Status Label
（狀態標籤）

或：

Work Record
（作業紀錄）

也不能完全取代實際確認。

因此：

Label Says Ready
（標籤顯示可維修）
≠
Cylinder Physically Ready
（鋼瓶實際已具備維修條件）

Record Complete
（紀錄顯示完成）
≠
Physical Condition Confirmed
（實際狀態已確認）

這個概念會在下一篇：

06-06｜標籤誤貼未清潔鋼瓶遭維修人員攔截未遂案例

再次出現。

06-05 是：

鋼瓶已經進入 Pressure Confirmation（壓力確認）階段才發現異常。

06-06 則是：

維修人員在進入 Pressure Panel（壓力盤）之前，就透過標示與紀錄不一致發現問題。

兩個案例放在一起，可以形成非常完整的 Safety Barrier 教材。

十一、Corrective Action 不應只更換壓力錶

本案例事故後當然需要處理：

Damaged Pressure Gauge
（損壞壓力錶）

但：

Replace Gauge
（更換壓力錶）

只是：

Equipment Restoration
（設備恢復）

不是完整的：

Corrective Action
（矯正措施）。

真正的改善應回到：

「如何防止狀態不符合維修條件的鋼瓶再次進入維修流程？」

因此可以從：

Prevention Barrier
（預防防護層）

Detection Barrier
（偵測防護層）

Mitigation Barrier
（減災防護層）

三個方向檢視。

Prevention：

防止不符合維修條件的鋼瓶進入維修區。

Detection：

即使上游失效，維修端仍進行 Pressure Confirmation。

Mitigation：

當發現異常壓力時，停止後續維修並依核准程序處理。

十二、Failure Mode Database（故障模式資料庫）建議紀錄

Failure Mode ID：

FM-011

Failure Mode：

Unexpected / Residual Cylinder Pressure
（非預期／殘留鋼瓶壓力）

Component / Process：

Cylinder / Maintenance Receiving
（鋼瓶／維修接收流程）

Observed Condition：

Unexpected High Pressure Detected Before Valve Removal
（拆閥前發現非預期高壓）

Detection Method：

Pressure Panel
（壓力盤）

Event Result：

Protective Device Activation
（保護裝置作動）

Pressure Gauge Damage
（壓力錶損壞）

Valve Removal Prevented
（避免進一步拆閥）

Safety Barrier：

Pressure Confirmation Before Valve Removal
（拆閥前壓力確認）

Possible Contributing Factors：

・Status Control
（狀態管理）

・Process Routing
（流程路由）

・Handover
（交接）

・Label / Record Control
（標示／紀錄管理）

・Upstream Verification
（上游確認）

・Other Factors
（其他因素）

Confirmed Root Cause：

依原始事故調查結果填寫。

Cause Status：

CONFIRMED（已確認）
PROBABLE（高度可能）
POSSIBLE（可能）
UNCONFIRMED（尚未確認）

十三、本案例的重要判斷觀念

本案例可以整理成：

Cylinder Sent to Maintenance
（鋼瓶送到維修區）
≠
Cylinder Depressurized
（鋼瓶已無壓）

Status Label
（狀態標示）
≠
Physical Condition
（實際物理狀態）

Pressure Gauge Damage
（壓力錶損壞）
≠
Root Cause
（根本原因）

Protective Device Activation
（保護裝置作動）
≠
Protective Device Failure
（保護裝置故障）

Pressure Panel
（壓力盤）
≠
Full Cylinder Processing Equipment
（滿瓶處理設備）

Pressure Confirmation
（壓力確認）
＝
Independent Safety Barrier
（獨立安全防護層）

最重要的是：

Never Assume Zero Pressure
（不要假設鋼瓶已經無壓）

而應：

Verify Actual Condition Before Valve Removal
（拆閥前確認鋼瓶實際狀態）。

十四、與 06-06 Near Miss 的差異

06-05：

Pressurized Cylinder
（仍有高壓的鋼瓶）

已經進入：

Pressure Panel Check
（壓力盤確認）

才發現異常。

結果：

・保護裝置作動
・Pressure Gauge 損壞
・Valve Removal 被阻止

06-06：

Status Label / Record Mismatch
（狀態標示／紀錄不一致）

維修人員在：

Valve Opening
（開閥）

以及：

Pressure Panel Connection
（壓力盤連接）

之前就發現異常。

因此：

06-05
＝
Safety Incident
（安全事件）

06-06
＝
Near Miss / Good Catch
（未遂事件／成功攔截）

兩個案例可以一起用來說明：

越早發現異常，

越能在較前端阻止事件進一步發展。

十五、相關文章

・04-01｜瓶閥拆卸與安裝
・04-05｜鋼瓶維修前接收與狀態確認
・06-06｜標籤誤貼未清潔鋼瓶遭維修人員攔截未遂案例
・07-04｜鋼瓶壓力測試盤與拆閥前壓力確認
・09-01｜Stop Work 與 Good Catch
・09-02｜多層安全防護
・09-04｜異常現象、直接原因與根本原因的判斷方法
・09-05｜鋼瓶維修經驗如何轉化為 Failure Mode Database

注意事項

本文為維修接收流程中 Unexpected Cylinder Pressure（非預期鋼瓶壓力）事故案例的技術經驗整理。

本案例中的 Pressure Panel Protective Device（壓力盤保護裝置）實際種類及設定值，在未確認原始設備資料前不作進一步推定。

Pressure Panel（壓力盤）在本文中的重點是拆閥前 Pressure Confirmation（壓力確認）與 Abnormal Condition Detection（異常狀態偵測），不應將其理解為處理 Full Cylinder（滿瓶）或高壓內容物的設備。

實際發現非預期壓力時，應停止後續維修作業，維持安全狀態並依公司核准的異常處理程序執行。

本文不提供高壓鋼瓶排放、洩壓、開閥或其他危險操作程序。

最後更新：2026-09-28