分類: 實際案例

  • Stop Work 與 Good Catch|特殊氣體鋼瓶維修的異常攔截與停止作業判斷

    09-01|Stop Work 與 Good Catch|維修現場的異常攔截與停止作業判斷

    特殊氣體鋼瓶維修中,

    真正重要的能力不只是:

    Can Perform the Work
    (能夠完成作業)

    更包括:

    Can Recognize When Not to Continue
    (知道什麼時候不應繼續)。

    很多嚴重事故並不是因為:

    「完全沒有作業程序。」

    而是異常訊號已經出現,

    作業人員卻仍然:

    Continue the Task
    (繼續作業)。

    因此維修現場需要建立兩個非常重要的安全觀念:

    Stop Work
    (停止作業)

    與:

    Good Catch
    (良好攔截)。

    Stop Work 的核心是:

    異常尚未確認之前,
    不要讓下一個高風險步驟繼續。

    Good Catch 的核心則是:

    在異常演變成事故之前,
    有人成功辨識並攔截了風險。

    這兩者共同形成:

    Human Safety Barrier
    (人員安全屏障)。

    一、什麼是 Stop Work?

    Stop Work
    (停止作業)

    不是單純:

    「停止工作。」

    而是在作業過程中發現:

    Abnormal Condition
    (異常狀態)

    Unknown Condition
    (未知狀態)

    Procedure Mismatch
    (程序不一致)

    Equipment Abnormality
    (設備異常)

    Identification Mismatch
    (識別資訊不一致)

    或其他可能影響安全的情況時,

    停止目前作業的進一步發展。

    基本邏輯是:

    Abnormality Detected
    (發現異常)
    ↓
    Stop Work
    (停止作業)
    ↓
    Preserve Current Condition
    (保留目前狀態)
    ↓
    Report / Escalate
    (回報/升級處理)
    ↓
    Verify
    (確認)
    ↓
    Determine Next Action
    (決定後續處置)

    而不是:

    Abnormality Detected
    ↓
    Guess the Cause
    ↓
    Continue Working

    因此:

    Stop Work
    ≠
    Failure to Complete the Job
    (不是工作失敗)

    在很多情況下,

    Stop Work 本身就是:

    Correct Safety Action
    (正確的安全行動)。

    二、UNKNOWN ≠ SAFE

    維修現場最危險的判斷之一,

    就是:

    「不知道有沒有問題,所以應該沒問題。」

    正確觀念應該是:

    UNKNOWN
    (未知)
    ≠
    SAFE
    (安全)

    例如:

    不知道鋼瓶內是否還有壓力

    不知道前站作業是否真正完成

    不知道標籤是否正確

    不知道 PRD 是否已經受到工具干涉

    不知道螺紋上的材料是 Foreign Material(異物)還是 Thread Material Loss(螺紋材料缺失)

    不知道某個 DOT-SP 是否仍然有效。

    這些情況都不能直接轉換成:

    「應該可以繼續。」

    更合理的判斷是:

    Unknown Condition
    (未知狀態)
    ↓
    Information Insufficient
    (資訊不足)
    ↓
    Do Not Assume Safe
    (不得自行假設安全)
    ↓
    Verify Before Continuing
    (確認後再決定是否繼續)

    三、Stop Work 不等於 Emergency Stop

    Stop Work

    與:

    Emergency Stop
    (緊急停止)

    不能完全視為相同概念。

    Emergency Stop

    通常是設備或系統面對:

    Immediate Hazard
    (立即危害)

    時的緊急功能。

    Stop Work

    則可以發生在:

    事故還沒有發生之前。

    例如維修人員發現:

    Label
    (標籤)

    與:

    Work Record
    (作業紀錄)

    不一致。

    此時:

    沒有洩漏

    沒有設備故障

    沒有人員受傷。

    但仍然可以:

    Stop Work。

    因此:

    No Accident Yet
    (事故尚未發生)
    ≠
    No Reason to Stop
    (沒有停止理由)

    這正是預防性安全管理的重要觀念。

    四、什麼是 Good Catch?

    Good Catch
    (良好攔截)

    是指:

    潛在危害或異常已經存在,

    但是在真正造成:

    Incident
    (事故)

    Equipment Damage
    (設備損壞)

    Gas Release
    (氣體釋放)

    Wrong Operation
    (錯誤操作)

    或:

    Personnel Exposure
    (人員暴露)

    之前,

    被人員成功辨識並攔截。

    Good Catch 的價值在於:

    The Barrier Worked
    (安全屏障成功發揮作用)。

    因此 Good Catch 不應被理解成:

    「反正沒有出事。」

    更重要的是:

    Why Was the Abnormality Present?
    (為什麼異常會存在?)

    以及:

    Which Barrier Caught It?
    (是哪一道屏障攔截了它?)

    五、Good Catch 與 Near Miss 的關係

    Near Miss
    (未遂事件/虛驚事件)

    通常代表:

    事件已經接近造成不良結果,

    但最後沒有形成實際傷害或損失。

    Good Catch

    則更強調:

    Detection and Intervention
    (辨識與介入)。

    兩者可能重疊,

    但觀察角度不同。

    例如:

    錯誤狀態標籤貼在尚未完成前站處理的鋼瓶上,

    鋼瓶已經送到維修區。

    這可以從事件角度描述為:

    Near Miss。

    如果維修人員在進一步操作前:

    發現標籤與紀錄不一致,

    停止作業並回報,

    則可以同時描述為:

    Good Catch。

    因此:

    Near Miss

    What Almost Happened
    (差點發生什麼)

    Good Catch

    What Successfully Stopped It
    (什麼成功阻止了它)

    六、實際案例:Status Label / Record Mismatch

    本維修現場曾發生:

    鋼瓶狀態標籤顯示前段處理已完成,

    但是維修人員進一步確認時,

    發現:

    Label
    (標籤)

    與:

    Completion / Work Record
    (完成/作業紀錄)

    無法對應。

    維修人員沒有直接相信:

    Status Label
    (狀態標籤)

    而是停止後續作業並進一步確認。

    最後確認:

    前段處理並沒有按照標籤所表示的狀態完成。

    這個案例已建立為:

    FM-012

    Status Label / Record Mismatch
    (狀態標籤/紀錄不一致)。

    七、這個案例真正重要的不是「貼錯標籤」

    如果只把事件寫成:

    Root Cause = Wrong Label
    (根本原因=貼錯標籤)

    就會過早結束調查。

    因為還需要問:

    Why Could the Wrong Label Be Applied?
    (為什麼錯誤標籤能被貼上?)

    Why Was It Not Detected Earlier?
    (為什麼前面沒有被發現?)

    Was Completion Verification Required?
    (是否要求完成確認?)

    Was the Label Linked to a Record?
    (標籤是否與紀錄連結?)

    Was Independent Verification Available?
    (是否存在獨立確認?)

    因此:

    Wrong Label
    (錯誤標籤)

    Observed Abnormality
    (觀察到的異常)

    不一定等於:

    Root Cause
    (根本原因)。

    這也是後續 09-04:

    Abnormality / Direct Cause / Root Cause
    (異常/直接原因/根本原因)

    要進一步建立的觀念。

    八、Status Label 是 Information Barrier

    Label
    (標籤)

    非常重要。

    但它本質上屬於:

    Information Barrier
    (資訊屏障)。

    它告訴下一站人員:

    這支鋼瓶目前被認為處於什麼狀態。

    但是:

    Label
    ≠
    Physical Condition
    (標籤不等於實際物理狀態)

    因此:

    Label Says Completed
    (標籤顯示完成)
    ≠
    Physical Condition Automatically Verified
    (實際狀態自動完成確認)

    這也是為什麼:

    Record Verification
    (紀錄確認)

    Independent Check
    (獨立檢查)

    以及:

    Physical Safety Barrier
    (實體安全屏障)

    仍然具有價值。

    九、第二個實際案例:Pressure Confirmation

    本維修現場早期曾發生:

    未完成前段處理的鋼瓶被送入維修區。

    在進一步進行瓶閥相關作業之前,

    維修人員依既有流程,

    先透過:

    Pressure Panel
    (壓力盤面)

    確認鋼瓶壓力狀態。

    結果發現:

    Unexpected / Residual Cylinder Pressure
    (非預期/殘留鋼瓶壓力)。

    該案例後續造成:

    Pressure Protection Device
    (壓力保護裝置)

    動作,

    並造成:

    Pressure Gauge
    (壓力錶)

    損壞。

    但這個案例同時證明:

    Pressure Confirmation
    (壓力確認)

    是一道重要的:

    Independent Safety Barrier
    (獨立安全屏障)。

    十、Pressure Confirmation 不是前站工作的替代品

    這裡必須特別注意:

    Pressure Confirmation

    成功發現異常,

    不代表:

    前站可以省略原本應完成的工作。

    也就是:

    Downstream Barrier Worked
    (下游屏障成功)
    ≠
    Upstream Failure Is Acceptable
    (上游失效可以接受)

    正確的安全架構應該是:

    Upstream Process Control
    (上游製程控制)
    ↓
    Status Identification
    (狀態識別)
    ↓
    Record Verification
    (紀錄確認)
    ↓
    Independent Pressure Confirmation
    (獨立壓力確認)
    ↓
    Maintenance Work
    (維修作業)

    每一層都有自己的功能。

    十一、Multiple Safety Barriers

    安全系統不應只依賴:

    One Perfect Person
    (一個永遠不犯錯的人)

    或:

    One Perfect Label
    (一張永遠不會貼錯的標籤)。

    比較可靠的方式是:

    Multiple Safety Barriers
    (多層安全屏障)。

    例如:

    Process Barrier
    (製程屏障)

    Information Barrier
    (資訊屏障)

    Physical Barrier
    (實體屏障)

    Detection Barrier
    (偵測屏障)

    Human Barrier
    (人員屏障)。

    以未完成前站處理的鋼瓶為例:

    前站程序
    ↓
    狀態標籤
    ↓
    作業紀錄
    ↓
    維修人員確認
    ↓
    Pressure Confirmation

    即使其中一道屏障失效,

    後面的屏障仍有機會:

    Catch the Error
    (攔截錯誤)。

    十二、Good Catch 不是靠運氣

    如果每一次成功攔截異常,

    公司都只說:

    「還好這次被發現。」

    就沒有真正學到東西。

    Good Catch 應該進一步分析:

    What Was Detected?
    (發現了什麼?)

    Who / What Detected It?
    (誰/什麼機制發現?)

    At Which Process Step?
    (在哪一站發現?)

    Which Barrier Failed Earlier?
    (前面哪一道屏障失效?)

    Which Barrier Worked?
    (哪一道屏障成功?)

    What Could Have Happened?
    (如果沒有攔截可能發生什麼?)

    Can the Successful Barrier Be Strengthened?
    (成功的屏障是否可以強化?)

    如此 Good Catch 才能轉換成:

    Organizational Learning
    (組織學習)。

    十三、Stop Work 的觸發條件不應只限於洩漏

    維修人員不應認為:

    只有:

    Gas Leak
    (氣體洩漏)

    才能 Stop Work。

    以下情況都可能構成停止並確認的理由:

    Identification Mismatch
    (識別資訊不一致)

    Label / Record Mismatch
    (標籤/紀錄不一致)

    Unexpected Pressure
    (非預期壓力)

    Unknown Cylinder Status
    (鋼瓶狀態未知)

    Unexpected Component
    (非預期零件)

    Missing Component
    (零件缺失)

    Tool Interference
    (工具干涉)

    PRD Position Change
    (PRD 位置改變)

    Thread Damage
    (螺紋損傷)

    Abnormal Gauge Result
    (量規結果異常)

    Structural Damage
    (結構損傷)

    Unknown DOT-SP Requirement
    (DOT-SP 要求未知)

    Procedure Conflict
    (程序衝突)

    或其他:

    Condition Outside the Approved Work Scope
    (超出核准作業範圍的狀況)。

    十四、Stop Work 之後不要急著「修掉異常」

    這一點對故障診斷非常重要。

    發現異常之後,

    如果立即:

    Retighten
    (重新鎖緊)

    Clean
    (清潔)

    Adjust
    (調整)

    Replace
    (更換)

    或:

    Remove the Abnormal Evidence
    (移除異常證據),

    可能會破壞:

    Failure Evidence
    (故障證據)。

    例如發現:

    PRD Position Abnormality
    (PRD 位置異常)。

    如果第一個動作就是:

    「把它鎖回去。」

    可能失去:

    Original Position
    (原始位置)

    Tool Mark
    (工具痕跡)

    Contact Mark
    (接觸痕跡)

    Witness Mark Relationship
    (見證標記關係)

    等重要資訊。

    因此在安全且符合現場規範的前提下:

    Stop
    ↓
    Observe
    ↓
    Record
    ↓
    Preserve Evidence
    ↓
    Then Determine Corrective Action

    比:

    See
    ↓
    Fix Immediately

    更有利於後續:

    Root Cause Analysis
    (根本原因分析)。

    十五、Corrective Action Success ≠ Root Cause Proof

    假設:

    PRD 鬆動

    重新處理後:

    Leak Test Pass
    (洩漏測試通過)。

    這只能證明:

    目前處置後的狀態符合該項檢查結果。

    不能直接證明:

    「原本一定就是因為某個人沒鎖好。」

    同樣:

    清掉螺紋上的材料後恢復正常,

    也不能單憑這件事證明:

    Foreign Material

    最初是由哪個流程產生。

    因此:

    Corrective Action Success
    (矯正措施成功)
    ≠
    Root Cause Proof
    (根本原因證明)

    Good Catch 的紀錄應盡可能保留:

    Before Condition
    (處理前狀態)。

    十六、Stop Work 不是找人負責

    如果現場文化把:

    Stop Work

    理解成:

    「一停止,就一定有人要被處罰。」

    人員很容易形成:

    Continue and Hope
    (繼續做並期待沒事)

    的行為。

    Stop Work 應首先處理:

    Condition
    (狀態)

    而不是先處理:

    Blame
    (責任歸屬)。

    第一個問題應該是:

    Is It Safe to Continue?
    (是否可以安全繼續?)

    而不是:

    Who Made the Mistake?
    (誰犯錯?)

    責任與原因分析可以在:

    Condition Controlled
    (狀態受到控制)

    之後再進行。

    十七、Good Catch 應該被記錄

    沒有記錄的 Good Catch

    很容易只存在於:

    某位資深技術人員的記憶。

    幾年後:

    人員調職

    退休

    離職

    或新人接手,

    這項經驗就消失了。

    因此 Good Catch

    最好建立基本紀錄:

    Date
    (日期)

    Process Step
    (作業階段)

    Observed Condition
    (觀察狀態)

    Expected Condition
    (預期狀態)

    Mismatch
    (差異)

    Stop Point
    (停止位置)

    Immediate Action
    (當下處置)

    Evidence
    (證據)

    Failure Mode
    (故障模式)

    Cause Status
    (原因確認狀態)

    Corrective Action
    (矯正措施)

    Preventive Action
    (預防措施)

    以及:

    Lesson Learned
    (經驗教訓)。

    十八、照片是 Good Catch 的重要證據

    在不影響安全的前提下,

    照片可以保存:

    Before Condition
    (處理前狀態)。

    例如:

    Wrong Label
    (錯誤標籤)

    PRD Position
    (PRD 位置)

    Thread Damage
    (螺紋損傷)

    Outlet Damage
    (出口損傷)

    Toroid Damage
    (超環面損傷)

    Tool Mark
    (工具痕跡)

    Weld Area Leak Location
    (焊縫洩漏位置)

    以及:

    Component Missing
    (零件缺失)。

    照片應盡量保留:

    Overview
    (整體)

    +

    Location
    (位置)

    +

    Close-up
    (特寫)。

    而不是只拍:

    一張極近距離照片,

    最後無法判斷:

    「這到底是哪個位置?」

    十九、公開網站照片與內部證據要分開

    Good Catch / Incident Photo

    可能包含:

    Cylinder Serial Number
    (鋼瓶序號)

    Customer Information
    (客戶資訊)

    Company Label
    (公司標籤)

    Employee Information
    (人員資訊)

    Internal Work Order
    (內部工單)

    或其他敏感資訊。

    因此:

    Original Evidence Photo
    (原始證據照片)

    應保存於:

    Internal Evidence Library
    (內部證據資料庫)。

    CylinderTech 公開網站使用的照片,

    則應建立:

    Public / Web Version
    (公開/網站版本)

    並依需要:

    Crop
    (裁切)

    Redact
    (遮蔽)

    De-identify
    (去識別化)

    Watermark
    (加浮水印)。

    因此:

    Original Evidence
    ≠
    Public Website Image
    (原始證據不等於公開網站圖片)

    二十、Good Catch 可以連結 Failure Mode Database

    本網站建立:

    Failure Mode Database
    (故障模式資料庫)

    之後,

    每一件 Good Catch

    可以與相對應的:

    FM ID

    連結。

    例如:

    Neck Leak
    → FM-001

    Cross Port Leak
    → FM-002

    Outlet Thread Damage
    → FM-003

    PRD Loose
    → FM-007

    Unexpected Pressure
    → FM-011

    Label / Record Mismatch
    → FM-012

    如此可以慢慢累積:

    同一 Failure Mode

    曾經出現多少次、

    在哪些流程出現、

    由哪一道 Barrier 發現。

    這會比:

    每一次事件各自寫一份報告

    更容易建立:

    Knowledge Base
    (知識庫)。

    二十一、Good Catch 與 Incident 都值得學習

    不能只有:

    事故真的發生

    才建立案例。

    如果只記錄:

    Gas Release

    Equipment Damage

    Personnel Injury

    等事故,

    會失去大量:

    Early Warning Information
    (早期警訊資訊)。

    因此知識庫應同時保存:

    Incident
    (事故)

    Near Miss
    (未遂事件)

    Good Catch
    (良好攔截)

    Abnormal Finding
    (異常發現)。

    這四類資料的嚴重程度可能不同,

    但都具有:

    Learning Value
    (學習價值)。

    二十二、Good Catch 不等於 Root Cause 已確認

    一件 Good Catch

    可能只知道:

    「發現什麼問題。」

    並不知道:

    「為什麼會發生。」

    例如:

    發現 PRD 位置改變。

    目前可以確認:

    Observed Condition

    PRD Position Abnormality

    但:

    Was It Caused by Tool Contact?
    (是否由工具接觸造成?)

    Was It Caused by Machine Interference?
    (是否由設備干涉造成?)

    Was It Already Abnormal Before Work?
    (作業前是否已經異常?)

    如果沒有證據,

    就不能自行選一個答案。

    因此可以標記:

    Cause Status
    (原因確認狀態)

    例如:

    CONFIRMED
    (已確認)

    PROBABLE
    (較可能)

    POSSIBLE
    (可能)

    UNCONFIRMED
    (未確認)。

    這些是:

    Internal Knowledge-management Classification
    (內部知識管理分類),

    不是 DOT 官方事故分類。

    二十三、Stop Work Authority

    成熟的安全管理系統中,

    Stop Work

    不能只屬於:

    Manager
    (主管)

    或:

    Senior Technician
    (資深技術員)。

    第一線工作人員如果發現:

    Unexpected Condition
    (非預期狀態),

    應該有能力依公司制度:

    Stop
    (停止)

    Report
    (回報)

    Verify
    (確認)。

    因為真正看到異常的人,

    往往就是:

    Person Closest to the Work
    (最接近作業的人)。

    如果所有異常都必須:

    「先做完再跟主管說。」

    Stop Work 就失去預防作用。

    二十四、新人最需要學的不是所有答案

    新人不可能在短時間內記住:

    所有 Cylinder Specification

    所有 Valve

    所有 PRD

    所有 Failure Mode

    所有 DOT Regulation。

    因此新人教育的第一階段,

    更重要的是:

    Recognize
    (辨識)
    ↓
    Stop
    (停止)
    ↓
    Describe
    (描述)
    ↓
    Collect Evidence
    (收集證據)
    ↓
    Escalate
    (回報)
    ↓
    Diagnose
    (診斷)

    而不是:

    Recognize
    ↓
    Guess
    ↓
    Repair

    也就是:

    新人可以不知道答案,

    但必須知道:

    「這個狀態跟正常的不一樣。」

    二十五、Stop Work 的價值在於阻止錯誤向後傳遞

    一個流程錯誤如果沒有被攔截,

    可能會一路傳遞。

    例如:

    Upstream Process Error
    (上游製程錯誤)
    ↓
    Wrong Status Label
    (錯誤狀態標籤)
    ↓
    Cylinder Sent to Maintenance
    (鋼瓶送至維修)
    ↓
    Technician Trusts Label
    (技術員相信標籤)
    ↓
    Next Operation Begins
    (下一步作業開始)
    ↓
    Potential Incident
    (潛在事故)

    如果維修人員在:

    Label / Record Verification

    階段 Stop Work,

    錯誤鏈就被切斷。

    因此:

    Stop Work

    Break the Error Chain
    (切斷錯誤鏈)。

    二十六、一道屏障成功,不代表系統沒有問題

    Good Catch 發生後,

    很容易產生:

    「還好有人發現,所以系統沒問題。」

    這是錯誤的結論。

    事實上:

    Good Catch

    通常同時代表兩件事情:

    第一:

    A Downstream Barrier Worked
    (下游屏障成功)

    第二:

    An Upstream Barrier May Have Failed
    (上游屏障可能失效)

    因此 Good Catch

    不是:

    Close the Case
    (結案理由)。

    而是:

    Start Learning
    (開始學習的訊號)。

    二十七、本篇的重要判斷觀念

    UNKNOWN
    (未知)
    ≠
    SAFE
    (安全)

    Stop Work
    (停止作業)
    ≠
    Failure
    (工作失敗)

    No Leak
    (沒有洩漏)
    ≠
    No Abnormality
    (沒有異常)

    No Accident
    (沒有事故)
    ≠
    No Need to Stop
    (不需要停止)

    Label Says Completed
    (標籤顯示完成)
    ≠
    Physical Condition Verified
    (實際狀態已確認)

    Good Catch
    (良好攔截)
    ≠
    Nothing Happened
    (什麼都沒發生)

    Near Miss
    (未遂事件)
    ≠
    Good Catch
    (良好攔截)

    Corrective Action Success
    (矯正措施成功)
    ≠
    Root Cause Proof
    (根本原因證明)

    Downstream Barrier Worked
    (下游屏障成功)
    ≠
    Upstream Failure Acceptable
    (上游失效可以接受)

    One Barrier Worked
    (一道屏障成功)
    ≠
    System Has No Weakness
    (系統沒有弱點)

    Stop Work
    (停止作業)
    ≠
    Immediately Modify the Evidence
    (立即改變異常證據)

    Good Catch Recorded
    (記錄 Good Catch)

    Knowledge Preserved
    (保存知識)

    真正的安全判斷流程是:

    Recognize
    (辨識)
    ↓
    Stop
    (停止)
    ↓
    Describe
    (描述)
    ↓
    Preserve Evidence
    (保存證據)
    ↓
    Report
    (回報)
    ↓
    Verify
    (確認)
    ↓
    Diagnose
    (診斷)
    ↓
    Correct
    (矯正)
    ↓
    Learn
    (學習)

    二十八、相關文章

    ・05-01|Failure Mode 故障診斷基本概念

    ・06-01|誤拆 PRD 造成大量氣體洩漏事故

    ・06-05|未清潔鋼瓶誤送維修廠與 Pressure Confirmation

    ・06-06|標籤誤貼未清潔鋼瓶遭維修人員攔截

    ・06-07|瓶閥安裝後 PRD 鬆動案例

    ・07-04|Pressure Test Panel

    ・08-04|Repair、Rebuild 與 Maintenance 法規界線

    ・09-02|Multiple Safety Barriers 多層安全屏障

    ・09-03|Gauge Pass ≠ Cylinder Accepted

    ・09-04|Observed Condition、Direct Cause 與 Root Cause

    ・09-05|Failure Mode Database

    ・09-06|新人異常判斷與技術知識傳承

    注意事項

    本文所稱 Stop Work(停止作業)、Good Catch(良好攔截)、Cause Status(原因確認狀態)及相關分類,主要用於本網站的維修安全與知識管理架構,不應直接理解為 DOT / PHMSA 的統一法定事故分類。

    實際特殊氣體鋼瓶異常應依現場安全制度、氣體危害、設備狀態、公司核准程序及適用法規進行處理。

    本文重點為異常辨識、停止作業、證據保存與安全屏障概念,不提供特殊氣體鋼瓶洩壓、排放、拆閥、緊急處置或其他危險操作程序。

    若異常涉及 Cylinder Pressure Part(鋼瓶承壓本體)、Unknown Pressure(未知壓力)、Gas Release(氣體釋放)、PRD Abnormality(PRD 異常)、Structural Damage(結構損傷)或超出維修人員核准作業範圍的狀況,應依現場安全制度停止並交由適當人員/單位判斷。

    最後更新:2026-09-30

  • NH3 Drum 溫度偵測器異常造成過熱|PRD Fuse Metal 動作事故案例

    06-08|NH3 Drum 溫度偵測器異常造成過熱與 PRD Fuse Metal 動作事故案例

    NH3(Ammonia,氨)Drum 的加熱系統通常需要依靠 Temperature Sensor(溫度偵測器)提供溫度資訊,讓控制系統判斷目前實際加熱狀態。

    但是:

    Temperature Signal
    (溫度訊號)

    不一定永遠等於:

    Actual Temperature
    (實際溫度)。

    本案例中,客戶端 NH3 Drum 加熱系統的 Temperature Sensor(溫度偵測器)發生異常。

    偵測器傳回控制系統的溫度數值並非 Drum 當時的真實溫度。

    因此控制系統依據錯誤的 Temperature Feedback(溫度回授)持續進行加熱,使 NH3 Drum 的 Actual Temperature(實際溫度)持續升高。

    最終造成:

    Overheating
    (過度加熱)

    並使 PRD(Pressure Relief Device,壓力釋放裝置)的 Fuse Metal(熔融式安全元件)達到動作條件而熔化/動作,形成氣體釋放路徑。

    本案例最終確認的 Root Cause(根本原因)為:

    Temperature Sensor Malfunction
    (溫度偵測器異常)

    而不是:

    PRD Failure
    (PRD 故障)。

    一、案例概要

    氣體:

    NH3
    (Ammonia,氨)

    容器:

    NH3 Drum

    事件類型:

    Temperature Sensor Malfunction
    (溫度偵測器異常)

    Drum Overheating
    (Drum 過度加熱)

    PRD Fuse Metal Activation
    (PRD 熔融式安全元件動作)

    NH3 Gas Release
    (NH3 氣體釋放)

    最終確認的事件原因鏈:

    Temperature Sensor Malfunction
    (溫度偵測器異常)
    ↓
    Incorrect Temperature Feedback
    (回傳錯誤溫度)
    ↓
    Control System Received Incorrect Temperature Information
    (控制系統接收到錯誤溫度資訊)
    ↓
    Heating Continued
    (持續加熱)
    ↓
    Actual Drum Temperature Continued to Rise
    (Drum 實際溫度持續升高)
    ↓
    Drum Overheating
    (Drum 過度加熱)
    ↓
    PRD Fuse Metal Reached Activation Condition
    (PRD Fuse Metal 達到動作條件)
    ↓
    Fuse Metal Melted / Activated
    (Fuse Metal 熔化/動作)
    ↓
    NH3 Gas Release
    (NH3 氣體釋放)

    Confirmed Root Cause:

    Temperature Sensor Malfunction
    (溫度偵測器異常)

    Cause Status:

    CONFIRMED
    (已確認)

    二、控制系統看到的溫度不等於真實溫度

    這是本案例最重要的技術觀念。

    正常情況下:

    Actual Temperature
    (實際溫度)
    ↓
    Temperature Sensor
    (溫度偵測器)
    ↓
    Temperature Signal
    (溫度訊號)
    ↓
    Control System
    (控制系統)
    ↓
    Heating Control
    (加熱控制)

    控制系統本身並不是直接感受到 Drum 的實際溫度。

    它實際取得的是:

    Temperature Sensor Signal
    (溫度偵測器訊號)。

    因此如果 Sensor(偵測器)發生異常:

    Actual Temperature
    (實際溫度)

    與:

    Displayed / Feedback Temperature
    (顯示/回授溫度)

    就可能產生差異。

    也就是:

    Temperature Reading
    (溫度讀值)
    ≠
    Actual Temperature Guaranteed
    (保證等於實際溫度)

    三、本案例真正危險的是「看起來溫度正常」

    Temperature Sensor 完全失去訊號時,系統可能比較容易察覺:

    Sensor Failure
    (偵測器故障)。

    但本案例更值得注意的是:

    Sensor 仍然提供 Temperature Feedback
    (溫度回授),

    只是:

    Feedback Value
    (回授數值)

    並不代表真實溫度。

    因此控制系統可能仍認為:

    Temperature Below Target
    (溫度尚未達到設定條件)

    而持續進行 Heating(加熱)。

    實際上:

    Actual Drum Temperature
    (Drum 實際溫度)

    已經持續升高。

    因此:

    Signal Present
    (有訊號)
    ≠
    Signal Correct
    (訊號正確)

    Reading Available
    (有讀值)
    ≠
    Measurement Valid
    (量測有效)

    這也是本案例非常重要的 Failure Mode(故障模式)。

    【H2】四、為什麼會造成 Overheating?

    正常 Closed-loop Temperature Control
    (閉迴路溫度控制)的基本概念是:

    Sensor
    ↓
    Measure Temperature
    (量測溫度)
    ↓
    Controller
    (控制器)
    ↓
    Determine Heating Requirement
    (判斷是否需要繼續加熱)
    ↓
    Heater
    (加熱器)
    ↓
    Temperature Changes
    (溫度改變)
    ↓
    Sensor Feedback
    (偵測器再次回授)

    但是當 Sensor Feedback(偵測器回授)錯誤時:

    Actual Temperature Rising
    (實際溫度升高)
    ↓
    Sensor Reports Incorrect Temperature
    (Sensor 回報錯誤溫度)
    ↓
    Controller Believes More Heating Is Required
    (控制器判斷仍需要加熱)
    ↓
    Heating Continues
    (持續加熱)
    ↓
    Actual Temperature Rises Further
    (實際溫度進一步升高)

    最後形成:

    Overheating
    (過度加熱)。

    因此本案例不是單純:

    Heater Failure
    (加熱器故障)

    而是:

    Temperature Feedback Failure
    (溫度回授失效)

    造成錯誤的 Heating Control(加熱控制)。

    五、PRD Fuse Metal 在事件中的角色

    當 NH3 Drum 因為錯誤的溫度回授而持續受熱後:

    Actual Temperature
    (實際溫度)

    逐漸升高。

    最後 PRD 中的:

    Fuse Metal
    (熔融式安全元件)

    受到 Thermal Exposure(熱暴露),並達到其動作條件。

    之後:

    Fuse Metal Melted / Activated
    (Fuse Metal 熔化/動作)

    形成 Pressure Relief Path
    (壓力釋放路徑)。

    因此本案例中的 PRD 不應直接分類成:

    Failed Component
    (故障零件)。

    比較正確的事件角色是:

    Safety Device Activated Following Overheating
    (過熱後安全裝置發生動作)。

    六、PRD Activation 不等於 PRD Failure

    本案例已經可以非常清楚地區分:

    Root Cause:

    Temperature Sensor Malfunction
    (溫度偵測器異常)

    Intermediate Event:

    Drum Overheating
    (Drum 過度加熱)

    Safety Device Response:

    PRD Fuse Metal Activation
    (PRD Fuse Metal 動作)

    Final Event:

    NH3 Gas Release
    (NH3 氣體釋放)

    因此:

    PRD Activation
    (PRD 動作)
    ≠
    PRD Failure
    (PRD 故障)

    Fuse Metal Melted
    (Fuse Metal 熔化)
    ≠
    Material Defect
    (材料缺陷)

    NH3 Released through PRD
    (NH3 經 PRD 釋放)
    ≠
    PRD Root Cause
    (PRD 是根本原因)

    這也是本案例最值得保留的事故分析觀念。

    七、Root Cause 與 Event Mechanism 必須分開

    如果只從事故最後看到:

    Fuse Metal Melted
    (Fuse Metal 熔化)

    很容易把原因寫成:

    「Fuse Metal 熔化造成 NH3 洩漏。」

    這句話只能描述部分 Event Mechanism(事件機制)。

    它沒有回答:

    「為什麼 Fuse Metal 會熔化?」

    繼續往前追查後:

    Fuse Metal Melted
    ↓
    Because Drum Overheated
    (因為 Drum 過熱)
    ↓
    Why did Drum Overheat?
    (為什麼 Drum 過熱?)
    ↓
    Heating Continued
    (持續加熱)
    ↓
    Why did Heating Continue?
    (為什麼持續加熱?)
    ↓
    Incorrect Temperature Feedback
    (錯誤溫度回授)
    ↓
    Why was Feedback Incorrect?
    (為什麼回授錯誤?)
    ↓
    Temperature Sensor Malfunction
    (溫度偵測器異常)

    因此最終確認:

    Root Cause:
    Temperature Sensor Malfunction
    (溫度偵測器異常)

    八、本案例揭露的是 Sensor Plausibility 問題

    如果控制系統只有單一 Temperature Sensor(溫度偵測器)提供溫度資訊:

    Sensor Failure
    (偵測器異常)

    可能同時影響:

    Monitoring
    (監控)

    以及:

    Control
    (控制)。

    也就是:

    同一個錯誤訊號,

    可能既被用來顯示溫度,

    又被用來決定是否繼續加熱。

    因此本案例值得進一步思考:

    Sensor Plausibility
    (偵測器合理性)

    也就是:

    「這個溫度數值是否合理?」

    而不只是:

    「系統有沒有收到溫度數值?」

    安全管理上應依實際設備設計評估是否需要:

    Independent Temperature Verification
    (獨立溫度確認)

    Sensor Diagnostic
    (偵測器診斷)

    Alarm Logic
    (警報邏輯)

    Interlock
    (連鎖保護)

    或其他適當的 Independent Safety Barrier
    (獨立安全防護層)。

    實際控制方式仍應由設備設計與工程安全評估決定。

    九、Signal Present 不代表 Sensor 正常

    設備維護中很容易把:

    No Signal
    (沒有訊號)

    視為 Sensor Failure。

    但本案例說明另一種更需要注意的情況:

    Wrong Signal
    (錯誤訊號)。

    例如:

    Sensor 有輸出
    ↓
    Controller 有收到數值
    ↓
    Display 有顯示溫度
    ↓
    但數值不代表實際溫度

    因此:

    Signal Present
    (存在訊號)
    ≠
    Sensor Healthy
    (偵測器正常)

    Display Normal
    (畫面顯示正常)
    ≠
    Process Condition Normal
    (實際製程狀態正常)

    這也是 Process Safety(製程安全)中非常重要的概念。

    十、事故後不能只更換 PRD

    事故發生後:

    PRD Fuse Metal 已經動作,

    因此相關 PRD 組件需要依適用要求處理。

    但是:

    Replace PRD
    (更換 PRD)

    並沒有解決:

    Temperature Sensor Malfunction
    (溫度偵測器異常)。

    如果只更換 PRD 而沒有處理真正的 Root Cause:

    新的 PRD 仍可能再次面對相同的 Overheating Condition(過熱條件)。

    因此 Corrective Action(矯正措施)必須至少區分:

    Event Recovery
    (事件後恢復)

    與:

    Root Cause Correction
    (根本原因矯正)。

    PRD Replacement:

    屬於事件後設備恢復的一部分。

    Temperature Detection / Control Correction:

    才是針對事故原因的重要改善方向。

    十一、Drum 本體沒有發現損傷應如何理解?

    依本案例實際結果:

    事故後對 NH3 Drum Body(NH3 Drum 本體)進行相關確認,未發現已知損傷。

    可以記錄為:

    No Damage Detected During Post-event Inspection
    (事故後檢查未發現損傷)。

    但不能因此建立:

    「過熱後只要外觀看起來正常,換 PRD 就可以繼續使用。」

    這種通用結論。

    因為:

    No Visible Damage
    (沒有可見損傷)
    ≠
    Return-to-Service Approved
    (已核准恢復使用)

    受到 Abnormal Thermal Exposure(異常熱暴露)的容器,仍應依其規格、受熱狀態及適用要求完成必要的 Inspection / Test / Evaluation(檢查/測試/評估)。

    最後才能進行:

    Return-to-Service Decision
    (恢復使用判定)。

    本案例最終確實恢復使用的結果,應理解為:

    經事故後相關確認與必要處置後作出的個案判定,

    而不是所有相似事故都可以直接套用。

    十二、Safety Barrier 分析

    本案例可以重新整理成以下 Safety Barrier(安全防護層):

    Barrier 1:

    Temperature Sensor
    (溫度偵測器)

    功能:

    量測 Drum 溫度並提供控制系統 Temperature Feedback(溫度回授)。

    本案例:

    FAILED
    (失效)

    Barrier 2:

    Temperature Control
    (溫度控制)

    功能:

    依溫度回授控制加熱。

    本案例中:

    控制系統取得的輸入資訊不正確,因此持續加熱。

    Barrier 3:

    Temperature Monitoring / Alarm
    (溫度監控/警報)

    應檢查:

    是否能獨立發現 Actual Temperature(實際溫度)與 Sensor Feedback(偵測器回授)之間的異常。

    Barrier 4:

    Independent Protection / Interlock
    (獨立保護/連鎖)

    應檢查:

    是否存在不依賴同一個錯誤溫度訊號的獨立保護。

    Barrier 5:

    PRD Fuse Metal
    (PRD 熔融式安全元件)

    本案例:

    ACTIVATED
    (發生動作)

    因此:

    Temperature Sensor Failure
    ↓
    Control Barrier Compromised
    ↓
    Drum Overheated
    ↓
    PRD Safety Barrier Activated

    這比單純記錄:

    「PRD Fuse Metal 熔化」

    更能呈現完整事故機制。

    十三、Failure Mode Database(故障模式資料庫)建議紀錄

    Failure Mode ID:

    FM-013

    Failure Mode:

    PRD Fuse Metal Activation Following Drum Overheating
    (Drum 過熱後 PRD Fuse Metal 動作)

    Gas Service:

    NH3
    (Ammonia,氨)

    Container:

    NH3 Drum

    Initiating Failure:

    Temperature Sensor Malfunction
    (溫度偵測器異常)

    Cause Status:

    CONFIRMED
    (已確認)

    Failure Mechanism:

    Incorrect Temperature Feedback
    (錯誤溫度回授)
    ↓
    Continued Heating
    (持續加熱)
    ↓
    Drum Overheating
    (Drum 過熱)
    ↓
    PRD Fuse Metal Activation
    (PRD Fuse Metal 動作)

    Observed Condition:

    Fuse Metal Melted / Activated
    (Fuse Metal 熔化/動作)

    Event Result:

    NH3 Gas Release
    (NH3 氣體釋放)

    Root Cause:

    Temperature Sensor Malfunction
    (溫度偵測器異常)

    Relevant Evidence:

    ・Temperature Sensor Condition
    (溫度偵測器狀態)

    ・Temperature Feedback Record
    (溫度回授紀錄)

    ・Actual Thermal Condition
    (實際受熱狀態)

    ・Heating System Record
    (加熱系統紀錄)

    ・PRD Condition
    (PRD 狀態)

    ・Drum Body Inspection
    (Drum 本體檢查)

    ・Event Timeline
    (事件時間線)

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

    本案例可以整理成:

    Temperature Reading
    (溫度讀值)
    ≠
    Actual Temperature Guaranteed
    (保證等於實際溫度)

    Signal Present
    (有訊號)
    ≠
    Sensor Healthy
    (偵測器正常)

    Display Normal
    (顯示正常)
    ≠
    Actual Process Normal
    (實際製程正常)

    Fuse Metal Melted
    (Fuse Metal 熔化)
    ≠
    PRD Defect
    (PRD 缺陷)

    PRD Activation
    (PRD 動作)
    ≠
    Root Cause
    (根本原因)

    Replace PRD
    (更換 PRD)
    ≠
    Root Cause Corrected
    (根本原因已改善)

    本案例最重要的安全經驗是:

    Do Not Only Verify That a Sensor Has a Signal
    (不能只確認偵測器有訊號)

    還需要考慮:

    Is the Signal Plausible?
    (這個訊號是否合理?)

    以及:

    Does an Independent Barrier Exist if the Sensor Is Wrong?
    (當偵測器提供錯誤訊號時,是否還有獨立的安全防護層?)

    十五、與其他 PRD 案例的差異

    06-01:

    Tool-related PRD Event
    (工具相關 PRD 事件)

    06-02:

    Missing PRD Component
    (PRD 零件缺失)

    06-07:

    PRD Loose / Position Abnormality
    (PRD 鬆動/位置異常)

    06-08:

    Temperature Sensor Malfunction
    (溫度偵測器異常)
    ↓
    Drum Overheating
    (Drum 過熱)
    ↓
    PRD Fuse Metal Activation
    (PRD Fuse Metal 動作)

    因此 06-08 與其他 PRD 案例最大的差異是:

    PRD 本身不是已確認的事故 Root Cause。

    真正已確認的 Root Cause 位於:

    Temperature Detection System
    (溫度偵測系統)。

    十六、相關文章

    ・02-02|瓶閥 PRD 種類與基本原理
    ・05-03|鋼瓶瓶閥常見故障模式總覽
    ・06-01|誤拆 PRD 造成大量氣體洩漏事故案例
    ・06-02|PRD Burst Disc 遺漏造成大量氣體洩漏事故案例
    ・06-07|瓶閥安裝後 PRD 鬆動案例
    ・09-02|多層安全防護
    ・09-04|異常現象、直接原因與根本原因的判斷方法
    ・09-05|鋼瓶維修經驗如何轉化為 Failure Mode Database

    注意事項

    本文為 NH3 Drum 因 Temperature Sensor Malfunction(溫度偵測器異常),造成 Incorrect Temperature Feedback(錯誤溫度回授)、持續加熱、Drum 過熱,最終導致 PRD Fuse Metal(PRD 熔融式安全元件)動作及 NH3 氣體釋放的實際事故案例整理。

    本案例事故調查確認的 Root Cause(根本原因)為 Temperature Sensor Malfunction,而不是 PRD Failure(PRD 故障)。

    不同 NH3 Drum、Heating System(加熱系統)、Temperature Control System(溫度控制系統)與 PRD Design(PRD 設計)可能不同,因此本文事故原因與改善觀念不應直接套用為所有設備的通用設計要求。

    受到 Abnormal Thermal Exposure(異常熱暴露)的 Drum,仍應依實際狀態、容器規格及適用要求完成必要 Inspection / Test / Evaluation(檢查/測試/評估),再由具適當資格或權限的單位進行 Return-to-Service Decision(恢復使用判定)。

    本文不提供 NH3 排放、PRD 更換、Fuse Metal 維修、Temperature Sensor 調校、控制系統修改或加熱設備操作程序。

    最後更新:2026-09-28

  • 瓶閥安裝後 PRD 鬆動案例|工具干涉、Witness Mark 與作業前後檢查

    06-07|瓶閥安裝後 PRD 鬆動案例

    PRD(Pressure Relief Device,壓力釋放裝置)是部分鋼瓶瓶閥上的重要安全組件。

    在 Valve Installation(瓶閥安裝)或其他瓶閥相關作業完成後,如果發現:

    PRD Position Abnormality
    (PRD 位置異常)

    或:

    PRD Loose Condition
    (PRD 鬆動狀態)

    不能只將 PRD 恢復原來位置後就直接結案。

    因為真正需要確認的是:

    PRD 是在什麼階段發生狀態改變?

    是否存在 Tool Interference(工具干涉)?

    是否存在 Equipment Contact(設備接觸)?

    是否原本就存在鬆動?

    還是有其他原因?

    本案例中,Valve Installation(瓶閥安裝)完成後,在後續壓力相關檢查/測試階段發現 PRD 出現鬆動或位置異常。

    因此停止後續正常流程並進行確認。

    本案例最重要的觀念是:

    PRD Loose
    (PRD 鬆動)
    =
    Observed Condition
    (觀察到的異常)

    但:

    PRD Loose
    (PRD 鬆動)
    ≠
    Tool Interference Confirmed
    (已確認為工具干涉)

    一、案例概要

    相關部位:

    Valve
    (瓶閥)

    PRD
    (Pressure Relief Device,壓力釋放裝置)

    異常類型:

    PRD Loose / Position Abnormality
    (PRD 鬆動/位置異常)

    發現階段:

    After Valve Installation
    (瓶閥安裝完成後)

    在後續壓力相關檢查/測試階段發現異常。

    主要觀察:

    PRD 的位置或固定狀態與預期不同。

    初步調查方向包括:

    ・Tool Interference(工具干涉)
    ・Equipment Contact(設備接觸)
    ・Clamping Position(夾持位置)
    ・Component Clearance(零件間隙)
    ・Original PRD Condition(PRD 原始狀態)
    ・Previous Service History(過去使用狀態)
    ・其他可能因素

    目前如果沒有足夠 Evidence(證據),就不應將其中任何一項直接寫成 Confirmed Root Cause(已確認根本原因)。

    【照片 06-07-01|PRD 正常位置】

    照片建議:

    使用相同或相近型號瓶閥,拍攝 PRD 正常狀態。

    可標示:

    Valve Body
    (閥體)

    PRD
    (壓力釋放裝置)

    Outlet
    (出口)

    照片目的:

    建立 Normal Condition
    (正常狀態)

    作為後續異常比較基準。

    不同 Valve Model(瓶閥型號)的 PRD 位置與結構可能不同,因此照片應標示為特定型號示例,而不是所有 PRD 的通用位置。

    二、發現 PRD 位置改變代表什麼?

    如果原本 PRD 的位置具有可確認的基準,而作業完成後發現位置發生變化,至少可以確認:

    Component Position Changed
    (零件位置發生改變)。

    但是這項 Evidence 只能回答:

    「它的位置改變了。」

    不能單獨回答:

    「是什麼力量讓它改變?」

    因此:

    Position Change
    (位置改變)
    ≠
    Cause Confirmed
    (原因已確認)

    這個區分非常重要。

    三、Tool Interference 是重要調查方向,但不是直接結論

    瓶閥安裝過程可能使用:

    Valve Machine
    (瓶閥拆裝設備)

    Wrench
    (扳手)

    Fixture
    (治具)

    Clamp
    (夾持裝置)

    或其他工具。

    如果工具、設備或治具與 PRD 之間存在 Clearance(間隙)不足,就需要調查是否可能發生:

    Tool Interference
    (工具干涉)。

    但是:

    Tool Used Near PRD
    (工具在 PRD 附近使用)
    ≠
    Tool Contact Confirmed
    (已確認工具接觸 PRD)

    更不能直接寫成:

    Root Cause:
    Valve Machine Hit PRD
    (瓶閥機撞到 PRD)

    除非存在足夠證據,例如:

    ・Tool Mark(工具痕跡)
    ・Contact Mark(接觸痕跡)
    ・位置對應
    ・設備夾持位置紀錄
    ・作業前後照片
    ・其他直接證據

    因此 Tool Interference 應先列為:

    Possible Cause
    (可能原因)。

    四、為什麼 Before / After Condition 很重要?

    如果只有事故後的照片:

    After Condition
    (作業後狀態)

    看到 PRD 位置異常,

    仍然會遇到一個問題:

    「它在作業前是不是就已經這樣?」

    因此比較完整的 Evidence(證據)應包含:

    Before Work
    (作業前)

    以及:

    After Work
    (作業後)

    的狀態。

    例如:

    Before Valve Installation
    (瓶閥安裝前)
    ↓
    PRD Position Recorded
    (記錄 PRD 位置)
    ↓
    Valve Installation
    (瓶閥安裝)
    ↓
    After Installation Inspection
    (安裝後檢查)
    ↓
    Compare PRD Position
    (比較 PRD 位置)

    如果:

    Before = Normal
    After = Changed

    就可以更明確確認:

    Position Change Occurred During the Process Window
    (位置變化發生於該作業時間區間內)。

    但仍需要進一步確認是哪一個步驟造成。

    【照片 06-07-02|PRD 作業前後位置比較】

    建議未來如果有合適案例照片,可製作:

    左:

    Before
    (作業前)

    右:

    After
    (作業後)

    並使用相同角度拍攝。

    這會比單獨一張異常照片更具有 Evidence Value(證據價值)。

    五、Witness Mark 的用途

    針對可能發生位置變化的組件,可以使用:

    Witness Mark
    (見證標記/位置標記)

    作為 Visual Reference
    (目視參考)。

    例如作業前建立可辨識的相對位置基準,作業後再次確認。

    其主要用途是協助判斷:

    Relative Position Changed?
    (相對位置是否改變?)

    因此:

    Witness Mark Aligned
    (見證標記位置一致)

    可以提供:

    Position Reference
    (位置參考)。

    而:

    Witness Mark Misaligned
    (見證標記位置不一致)

    則表示:

    Possible Relative Movement
    (可能發生相對位移)。

    六、Witness Mark 不是 Torque Proof

    這一點非常重要。

    Witness Mark(見證標記)只能協助確認:

    Relative Position
    (相對位置)。

    它不能證明:

    Actual Torque
    (實際扭力)

    是多少。

    因此:

    Witness Mark Aligned
    (見證標記對齊)
    ≠
    Correct Torque Confirmed
    (已確認正確扭力)

    同樣:

    Witness Mark Misaligned
    (見證標記錯位)
    ≠
    Under Torque Confirmed
    (已確認扭力不足)

    因為位置變化可能涉及不同因素。

    所以 Witness Mark 的定位應該是:

    Visual Detection Aid
    (目視偵測輔助)

    而不是:

    Torque Measurement
    (扭力量測)。

    七、發現 PRD 鬆動不能只重新鎖緊

    當發現 PRD Loose(PRD 鬆動)時,如果只做:

    PRD Loose
    ↓
    Retighten
    (重新鎖緊)
    ↓
    Leak Test
    (洩漏檢查)
    ↓
    Pass
    ↓
    Close Case

    可能會失去非常重要的事故資訊。

    因為重新鎖緊之前應先確認:

    ・Original Position(原始位置)
    ・Current Position(目前位置)
    ・是否存在 Tool Mark(工具痕跡)
    ・是否存在 Contact Mark(接觸痕跡)
    ・周圍零件是否有異常
    ・PRD 本身是否有 Damage(損傷)
    ・是否存在 Assembly Abnormality(組裝異常)

    因此:

    Retightening
    (重新鎖緊)

    屬於可能的 Corrective Action(矯正措施)之一,

    但:

    Retightening
    ≠
    Root Cause Analysis
    (根本原因分析)。

    八、先保存 Evidence 再進行處置

    發現 PRD 異常時,如果安全條件與核准程序允許,應優先保存:

    Original Condition Evidence
    (原始狀態證據)。

    例如:

    ・PRD 位置
    ・Witness Mark 狀態
    ・Valve Body 狀態
    ・Tool Mark
    ・Contact Mark
    ・設備夾持位置
    ・作業前後照片
    ・相關作業紀錄

    原因是:

    一旦重新調整 PRD,

    原始位置資訊可能消失。

    因此:

    Preserve Evidence
    (保存證據)

    應該在不影響安全的前提下,優先於:

    Restore Appearance
    (恢復外觀)。

    九、設備與零件之間的 Clearance 需要確認

    如果調查懷疑 Tool Interference(工具干涉),其中一個重要方向是:

    Clearance
    (間隙)。

    需要確認:

    Valve
    (瓶閥)

    PRD
    (壓力釋放裝置)

    Tool
    (工具)

    Fixture
    (治具)

    Clamp
    (夾持裝置)

    之間的相對位置。

    尤其不同 Valve Model(瓶閥型號)的:

    ・Valve Body Shape(閥體形狀)
    ・PRD Position(PRD 位置)
    ・Outlet Position(出口位置)
    ・Component Protrusion(零件突出程度)

    可能不同。

    因此某一套設備對 A 型瓶閥沒有干涉,

    不代表:

    對 B 型瓶閥也一定具有足夠 Clearance。

    【照片 06-07-03|Valve / PRD / Tool Clearance】

    照片建議:

    未來可以使用實際設備與瓶閥,在非操作狀態下拍攝相對位置。

    標示:

    PRD
    Valve Body
    Tool / Fixture
    Clearance

    目的只是說明:

    Potential Interference Area
    (可能干涉區域)。

    不要為了拍攝照片故意讓工具碰撞 PRD。

    十、這與 06-01 的事故有什麼不同?

    06-01:

    誤拆 PRD 造成大量氣體洩漏事故

    已知:

    工具操作過程影響 PRD 相關組件,

    並造成大量 Gas Release(氣體釋放)。

    事件已經發展成:

    Actual Release Event
    (實際洩漏事件)。

    06-07:

    瓶閥安裝完成後發現 PRD Loose / Position Abnormality
    (PRD 鬆動/位置異常)。

    目前重點是:

    在後續檢查階段發現組件狀態改變,

    但 Tool Interference(工具干涉)是否為真正原因仍需要 Evidence 支持。

    因此:

    06-01
    =
    已發生 Gas Release 的事故案例

    06-07
    =
    作業後 Component Condition Abnormality
    (零件狀態異常)案例

    兩者都可以用來建立:

    Tool Selection
    (工具選擇)

    Tool Contact Area
    (工具接觸區域)

    Component Clearance
    (零件間隙)

    Post-work Inspection
    (作業後檢查)

    的重要性。

    十一、Post-work Inspection 為什麼重要?

    如果瓶閥安裝完成後,只確認:

    Valve Installed
    (瓶閥已安裝)

    就直接進入下一階段,

    可能忽略周圍零件在安裝過程中發生的狀態變化。

    因此 Post-work Inspection(作業後檢查)的概念不只是:

    「主作業完成了嗎?」

    還應確認:

    「周圍有沒有因為這次作業產生新的異常?」

    這種思考可以稱為:

    Secondary Damage Check
    (次生損傷確認)。

    也就是:

    Primary Task Completed
    (主要作業完成)
    ≠
    No Secondary Abnormality
    (沒有產生其他異常)。

    十二、Corrective Action 應針對不同層次

    如果最後調查確認 Tool Interference(工具干涉),改善措施不應只有:

    「提醒作業人員小心。」

    可以進一步檢查:

    Tool Selection
    (工具選擇)

    Tool Geometry
    (工具幾何形狀)

    Fixture Design
    (治具設計)

    Clamping Position
    (夾持位置)

    Component Clearance
    (零件間隙)

    Work Method
    (作業方式)

    Before / After Inspection
    (作業前後檢查)

    Error Proofing / Poka-Yoke
    (防錯設計)

    等方向。

    但如果 Root Cause 尚未確認,

    就不應先假設一定是設備問題,再針對錯誤原因進行改善。

    十三、Failure Mode Database(故障模式資料庫)建議紀錄

    Failure Mode ID:

    FM-007

    Failure Mode:

    PRD Loose / Position Abnormality
    (PRD 鬆動/位置異常)

    Component:

    PRD
    (Pressure Relief Device,壓力釋放裝置)

    Detection Stage:

    After Valve Installation
    (瓶閥安裝完成後)

    Observed Condition:

    PRD position / fastening condition differed from expected condition.
    (PRD 位置/固定狀態與預期不同。)

    Detection Method:

    Post-work Inspection / Pressure-related Check
    (作業後檢查/後續壓力相關檢查)

    Possible Causes:

    ・Tool Interference
    (工具干涉)

    ・Equipment Contact
    (設備接觸)

    ・Fixture / Clamp Interference
    (治具/夾持干涉)

    ・Pre-existing Loose Condition
    (原本即存在鬆動)

    ・Assembly-related Condition
    (組裝相關因素)

    ・Other Factors
    (其他因素)

    Evidence to Check:

    ・Before / After Photos
    (作業前後照片)

    ・Witness Mark
    (見證標記)

    ・Tool Mark
    (工具痕跡)

    ・Contact Mark
    (接觸痕跡)

    ・Fixture Position
    (治具位置)

    ・Work Record
    (作業紀錄)

    Confirmed Root Cause:

    依實際事故調查證據填寫。

    Cause Status:

    CONFIRMED(已確認)
    PROBABLE(高度可能)
    POSSIBLE(可能)
    UNCONFIRMED(尚未確認)

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

    本案例可以整理成:

    PRD Loose
    (PRD 鬆動)
    ≠
    Tool Interference Confirmed
    (已確認工具干涉)

    Position Changed
    (位置改變)
    ≠
    Cause Confirmed
    (原因已確認)

    Tool Near PRD
    (工具位於 PRD 附近)
    ≠
    Tool Contact Confirmed
    (已確認工具接觸)

    Witness Mark
    (見證標記)
    ≠
    Torque Proof
    (扭力證明)

    Retightened and Leak-free
    (重新固定後無洩漏)
    ≠
    Root Cause Confirmed
    (根本原因已確認)

    Primary Task Completed
    (主要作業完成)
    ≠
    No Secondary Abnormality
    (沒有次生異常)

    因此本案例最重要的原則是:

    Compare Before and After
    (比較作業前後狀態)

    Preserve Evidence
    (保存原始證據)

    Check for Interference
    (確認是否存在干涉)

    再依 Evidence(證據)判斷原因。

    十五、相關文章

    ・02-02|瓶閥 PRD 種類與基本原理
    ・04-01|瓶閥拆卸與安裝
    ・05-03|鋼瓶瓶閥常見故障模式總覽
    ・06-01|誤拆 PRD 造成大量氣體洩漏事故案例
    ・06-02|PRD Burst Disc 遺漏造成大量氣體洩漏事故案例
    ・07-06|固定尺寸扳手與活動扳手的使用風險
    ・09-02|多層安全防護
    ・09-04|異常現象、直接原因與根本原因的判斷方法
    ・09-05|鋼瓶維修經驗如何轉化為 Failure Mode Database

    注意事項

    本文為 Valve Installation(瓶閥安裝)完成後發現 PRD Loose / Position Abnormality(PRD 鬆動/位置異常)的案例整理。

    目前案例所能確認的是 PRD 在後續檢查階段發現位置或固定狀態異常。

    Tool Interference(工具干涉)、Valve Machine(瓶閥拆裝設備)接觸、Fixture / Clamp Interference(治具/夾持干涉)等,應依實際 Evidence(證據)判定,不應在證據不足時直接指定為 Root Cause(根本原因)。

    Witness Mark(見證標記)僅作為 Relative Position(相對位置)的目視參考,不代表 Actual Torque(實際扭力)已經確認。

    發現 PRD 異常時,應依核准程序停止相關作業並進行適當確認。本文不提供 PRD 拆卸、重新固定、壓力釋放或其他危險操作程序。

    最後更新:2026-09-28

  • 標籤誤貼未清潔鋼瓶遭維修人員攔截|Near Miss 與 Good Catch 案例

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

    在鋼瓶維修流程中,Status Label(狀態標籤)是辨識鋼瓶目前作業狀態的重要資訊之一。

    但是:

    Label
    (標籤)

    只能代表一項 Status Information(狀態資訊),不能單獨取代鋼瓶實際狀態與相關作業紀錄的確認。

    本案例中,一支鋼瓶被貼上表示前端作業已完成的狀態標籤,並送往 Maintenance Area(維修區域)。

    維修人員在後續作業前進行資料確認時,發現:

    Status Label
    (狀態標籤)

    與:

    Work Record
    (作業紀錄)

    無法相互對應。

    進一步確認後發現,該鋼瓶實際並未完成標籤所表示的前端清潔/處理程序。

    維修人員因此立即停止後續作業。

    異常是在:

    Valve Opening
    (開閥)

    以及:

    Pressure Panel Connection
    (壓力盤連接)

    之前被發現。

    因此沒有進一步進入拆閥相關作業。

    這起案例屬於:

    Near Miss
    (未遂事件)

    同時也是:

    Good Catch
    (成功攔截)

    的重要案例。

    一、案例概要

    事件類型:

    Status Label / Record Mismatch
    (狀態標籤/紀錄不一致)

    主要異常:

    鋼瓶上的 Status Label(狀態標籤)顯示前端作業已完成,

    但維修人員查核相關 Work Record(作業紀錄)時,沒有找到可以支持該狀態的對應紀錄。

    進一步確認後發現:

    Actual Cylinder Status
    (鋼瓶實際狀態)

    與:

    Label Status
    (標籤所表示的狀態)

    不一致。

    發現時機:

    ・Valve Opening(開閥)之前
    ・Pressure Panel Connection(壓力盤連接)之前
    ・Valve Removal(拆閥)之前

    事件結果:

    ・維修人員停止後續作業
    ・異常鋼瓶未繼續進入維修程序
    ・沒有進一步發展成設備或人員事件

    因此本案例可以分類為:

    Near Miss / Good Catch
    (未遂事件/成功攔截)

    【照片 06-06-01|鋼瓶 Status Label 示意】

    二、Label Says Complete 不等於 Process Actually Complete

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

    如果鋼瓶貼有:

    Cleaning Completed
    (清潔完成)

    或其他表示前端處理已完成的狀態標籤,

    後端人員很容易產生:

    「既然已經貼標籤,就代表前面的作業已經完成。」

    這種預期。

    但是:

    Label Says Complete
    (標籤顯示完成)
    ≠
    Process Actually Complete
    (實際作業已完成)

    同樣:

    Label Present
    (標籤存在)
    ≠
    Record Exists
    (作業紀錄存在)

    因此 Status Label(狀態標籤)與 Work Record(作業紀錄)最好能夠相互支持。

    三、本案例為什麼沒有進入 Pressure Panel?

    06-05 的案例中:

    鋼瓶已經進入 Pressure Confirmation(壓力確認)階段,

    才發現實際狀態與預期不符。

    但 06-06 不同。

    本案例中,維修人員在進一步操作之前就發現:

    Label
    (標籤)

    與:

    Record
    (紀錄)

    存在不一致。

    因此:

    Status Mismatch Detected
    (發現狀態不一致)
    ↓
    STOP
    (停止)
    ↓
    No Valve Opening
    (未開閥)
    ↓
    No Pressure Panel Connection
    (未連接壓力盤)
    ↓
    No Valve Removal
    (未拆閥)

    異常被攔截在更前端的位置。

    這也是為什麼本案例可以被視為:

    Good Catch
    (成功攔截)。

    四、這個案例不能直接寫成「滿瓶誤送」

    這一點需要特別區分。

    06-05 已知的事實是:

    Full / Pressurized Cylinder
    (滿瓶/仍具有高壓內容物的鋼瓶)

    實際進入維修流程。

    因此 06-05 可以明確記錄:

    Unexpected High Pressure
    (非預期高壓)。

    但是 06-06 目前已知的是:

    ・標籤顯示前端處理已完成
    ・沒有相符的完成紀錄
    ・進一步確認實際沒有完成標籤所表示的清潔/處理程序
    ・維修人員在開閥及接壓力盤前停止作業

    因此不能從這些資料直接推論:

    Full Cylinder
    (滿瓶)

    或:

    High Pressure Cylinder
    (高壓鋼瓶)。

    比較正確的描述是:

    Cylinder Status Not Verified / Process Not Completed
    (鋼瓶狀態未獲確認/前端程序未完成)

    這是技術案例紀錄非常重要的原則:

    Unknown
    (未知)

    不要自行補成:

    Known Fact
    (已知事實)。

    五、Status Label 是 Information Barrier,不是 Physical Barrier

    Status Label(狀態標籤)的主要功能是:

    Communication
    (資訊傳遞)

    與:

    Status Identification
    (狀態識別)。

    因此它可以被視為:

    Information Barrier
    (資訊型防護層)。

    但標籤本身不能:

    ・確認鋼瓶實際壓力
    ・證明前端作業確實完成
    ・證明鋼瓶內容物狀態
    ・防止錯誤鋼瓶進入流程
    ・取代 Physical Verification(實際確認)

    所以:

    Information Barrier
    (資訊防護)
    +
    Record Verification
    (紀錄確認)
    +
    Physical Verification
    (實際狀態確認)

    應該是不同層次的防護。

    六、為什麼 Work Record 很重要?

    Work Record(作業紀錄)的價值,不只是留下:

    「有人做過。」

    而是建立:

    Traceability
    (追溯性)。

    例如當 Status Label 顯示:

    Process Complete
    (作業完成)

    時,相關紀錄應能協助確認:

    ・是哪一支鋼瓶?
    ・進行了什麼程序?
    ・程序是否完成?
    ・相關狀態是否可以追溯?
    ・標籤與紀錄是否指向同一支鋼瓶?

    本案例正是因為:

    Label Status
    (標籤狀態)

    與:

    Available Record
    (現有紀錄)

    無法相互支持,

    才讓維修人員察覺:

    Something Is Wrong
    (狀態可能有問題)。

    因此紀錄本身也形成了一道:

    Detection Barrier
    (偵測防護層)。

    七、不要因為標籤存在就跳過確認

    在重複性的維修工作中,很容易形成:

    「以前送來的都是處理完成的。」

    或:

    「有這張標籤就代表沒問題。」

    這類 Assumption(假設)。

    但事故往往發生在:

    Expected Condition
    (預期狀態)

    與:

    Actual Condition
    (實際狀態)

    不同的時候。

    因此:

    Routine Work
    (例行工作)
    ≠
    No Verification Needed
    (不需要確認)

    Label Present
    (有標籤)
    ≠
    Verification Complete
    (確認已完成)

    越是每天重複的工作,越需要避免:

    Assumption-based Work
    (依賴假設進行作業)。

    八、Good Catch 的價值不是「剛好被看到」

    Good Catch(成功攔截)不應被簡化成:

    「還好有人發現。」

    如果維修人員是透過:

    ・Status Check(狀態確認)
    ・Record Check(紀錄確認)
    ・Information Cross-check(資訊交叉確認)

    發現異常,

    代表原本流程中仍存在有效的 Detection Barrier(偵測防護層)。

    因此 Good Catch 應該被記錄:

    What Was Found?
    (發現什麼?)

    How Was It Found?
    (怎麼發現?)

    At What Stage?
    (在哪個階段發現?)

    What Was Prevented?
    (避免了什麼後續操作?)

    Which Barrier Worked?
    (哪一道防護層發揮作用?)

    這些資訊可以用來改善其他流程。

    九、Near Miss 不代表可以不用調查

    因為本案例沒有造成:

    ・人員受傷
    ・設備損壞
    ・大量氣體洩漏

    很容易被當成:

    「沒有發生事故。」

    但 Near Miss(未遂事件)的價值就在於:

    Failure Path
    (失效路徑)

    已經開始形成,

    只是被其中一道 Safety Barrier(安全防護層)成功阻止。

    因此應該問:

    「如果維修人員沒有發現 Label / Record Mismatch,下一步會發生什麼?」

    可能的下一步原本會是:

    Pressure Panel Connection
    (壓力盤連接)

    甚至:

    Valve-related Work
    (瓶閥相關作業)。

    因此 Near Miss 是非常重要的 Learning Opportunity(學習機會)。

    十、不要急著把 Root Cause 寫成「貼錯標籤」

    本案例已知:

    Status Label
    (狀態標籤)

    與實際流程狀態不一致。

    但:

    Wrong Label
    (錯誤標籤)

    可能只是:

    Direct Condition
    (直接異常)

    而不一定是:

    Root Cause
    (根本原因)。

    後續仍應調查:

    ・為什麼錯誤標籤會出現在這支鋼瓶?
    ・標籤如何產生?
    ・標籤由誰、在什麼條件下使用?
    ・是否需要對應 Work Record 才能建立完成狀態?
    ・Cylinder Identification(鋼瓶識別)是否可能混淆?
    ・Process Routing(流程路由)是否存在漏洞?
    ・Handover(交接)是否完整?
    ・是否有 Independent Verification(獨立確認)?

    因此:

    Wrong Label
    (錯誤標籤)
    ≠
    Root Cause Confirmed
    (根本原因已確認)

    十一、不要只靠「提醒人員注意」作為改善

    如果事故改善最後只有:

    「提醒作業人員不要貼錯。」

    這種措施通常仍高度依賴 Human Memory(人員記憶)。

    更值得檢查的是:

    是否能讓:

    Label
    (標籤)

    Record
    (紀錄)

    Cylinder Identification
    (鋼瓶識別)

    Process Status
    (流程狀態)

    彼此產生更強的關聯。

    例如改善方向可以從:

    Traceability
    (追溯性)

    Status Verification
    (狀態確認)

    Independent Check
    (獨立確認)

    Error Proofing / Poka-Yoke
    (防錯設計)

    等角度評估。

    但實際採用何種方法,仍應依公司流程與核准制度決定。

    十二、本案例中的 Safety Barrier

    本案例可以整理出多層防護:

    Barrier 1:

    Correct Process Completion
    (正確完成前端程序)

    目的:

    只有真正完成必要前端程序的鋼瓶,才能進入下一階段。

    Barrier 2:

    Correct Status Label
    (正確狀態標示)

    目的:

    讓後續人員辨識鋼瓶目前狀態。

    Barrier 3:

    Work Record
    (作業紀錄)

    目的:

    提供可追溯的完成證據。

    Barrier 4:

    Label / Record Cross-check
    (標籤/紀錄交叉確認)

    目的:

    發現資訊不一致。

    Barrier 5:

    Pressure Confirmation Before Valve Removal
    (拆閥前壓力確認)

    目的:

    即使前面的 Information Barrier(資訊防護層)全部失效,仍透過實際狀態確認建立最後一道重要防線。

    在本案例中:

    Barrier 1 / 2
    存在異常

    但:

    Barrier 3 / 4
    協助維修人員成功發現問題。

    因此事件在進入 Pressure Panel 之前被停止。

    十三、與 06-05 案例比較

    06-05:

    Unexpected / Residual Cylinder Pressure
    (非預期/殘留鋼瓶壓力)

    異常發現階段:

    Pressure Panel
    (壓力盤)

    事件結果:

    ・Protective Device Activation
    (保護裝置作動)

    ・Pressure Gauge Damage
    (壓力錶損壞)

    ・Valve Removal 被阻止

    06-06:

    Status Label / Record Mismatch
    (狀態標籤/紀錄不一致)

    異常發現階段:

    Before Valve Opening
    (開閥之前)

    Before Pressure Panel Connection
    (連接壓力盤之前)

    事件結果:

    ・後續作業停止
    ・沒有進入壓力盤確認階段
    ・沒有進一步發展成設備事件

    因此可以看到:

    Earlier Detection
    (越早發現)
    ↓
    Lower Event Progression
    (事件發展程度越低)

    這就是 Prevention Barrier(預防防護層)與 Detection Barrier(偵測防護層)往前移的重要性。

    十四、Failure Mode Database(故障模式資料庫)建議紀錄

    Failure Mode ID:

    FM-012

    Failure Mode:

    Status Label / Record Mismatch
    (狀態標籤/紀錄不一致)

    Process:

    Cylinder Maintenance Receiving
    (鋼瓶維修接收)

    Observed Condition:

    Status Label indicated process completion, but corresponding completion record could not be confirmed.
    (狀態標籤顯示程序完成,但無法確認相符的完成紀錄。)

    Actual Condition:

    Required upstream process had not been completed as indicated by the label.
    (實際未完成標籤所表示的前端程序。)

    Detection Method:

    Label / Record Cross-check
    (標籤/紀錄交叉確認)

    Detection Stage:

    Before Valve Opening
    (開閥之前)

    Before Pressure Panel Connection
    (壓力盤連接之前)

    Event Classification:

    Near Miss / Good Catch
    (未遂事件/成功攔截)

    Safety Barrier:

    Status Verification
    (狀態確認)

    Record Verification
    (紀錄確認)

    Information Cross-check
    (資訊交叉確認)

    Possible Contributing Factors:

    ・Label Control
    (標籤管理)

    ・Process Routing
    (流程路由)

    ・Cylinder Identification
    (鋼瓶識別)

    ・Handover
    (交接)

    ・Record Control
    (紀錄管理)

    ・Other Factors
    (其他因素)

    Confirmed Root Cause:

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

    Cause Status:

    CONFIRMED(已確認)
    PROBABLE(高度可能)
    POSSIBLE(可能)
    UNCONFIRMED(尚未確認)

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

    本案例可以整理成:

    Label Says Complete
    (標籤顯示完成)
    ≠
    Process Actually Complete
    (實際程序已完成)

    Label Present
    (標籤存在)
    ≠
    Record Verified
    (紀錄已確認)

    Wrong Label
    (錯誤標籤)
    ≠
    Root Cause Confirmed
    (根本原因已確認)

    Process Not Completed
    (程序未完成)
    ≠
    Full Cylinder Confirmed
    (已確認為滿瓶)

    Near Miss
    (未遂事件)
    ≠
    No Investigation Needed
    (不需要調查)

    Good Catch
    (成功攔截)
    =
    Valuable Safety Information
    (有價值的安全資訊)

    因此本案例最重要的經驗是:

    Do Not Trust a Single Indicator
    (不要只依賴單一狀態指標)

    而應:

    Cross-check Label, Record and Actual Condition
    (交叉確認標籤、紀錄與實際狀態)。

    十六、相關文章

    ・04-05|鋼瓶維修前接收與狀態確認
    ・06-05|未清潔滿瓶誤送維修廠造成壓力盤洩壓事故案例
    ・07-04|鋼瓶壓力測試盤與拆閥前壓力確認
    ・09-01|Stop Work 與 Good Catch
    ・09-02|多層安全防護
    ・09-04|異常現象、直接原因與根本原因的判斷方法
    ・09-05|鋼瓶維修經驗如何轉化為 Failure Mode Database
    ・09-06|新進維修人員的鋼瓶異常判斷與經驗傳承

    注意事項

    本文為 Status Label / Record Mismatch(狀態標籤/紀錄不一致)的 Near Miss / Good Catch(未遂事件/成功攔截)案例整理。

    本案例已知的是:

    鋼瓶實際未完成標籤所表示的前端清潔/處理程序,且維修人員在 Valve Opening(開閥)與 Pressure Panel Connection(壓力盤連接)之前發現異常並停止後續作業。

    本文不將該鋼瓶進一步推定為 Full Cylinder(滿瓶)或具有特定壓力,除非原始事故紀錄能提供相關證據。

    Status Label(狀態標籤)、Work Record(作業紀錄)與 Physical Condition(實際狀態)應視為不同層次的資訊與安全防護,不應以單一標籤取代必要的實際確認。

    最後更新:2026-09-28

  • 未清潔滿瓶誤送維修廠事故|拆閥前 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
    (下游安全防護層)

    兩個值得分析的部分。

    照片 06-05-01|維修廠 Pressure Panel

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

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

    在正常流程中,維修人員可能預期:

    送到 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

  • C2H2 鋼瓶壓力異常與 PRD 洩漏案例|DMF 與充填重量來源端管理

    06-03|C2H2 鋼瓶壓力異常與 PRD 洩漏事故案例

    C2H2(Acetylene,乙炔)鋼瓶與一般壓縮氣體鋼瓶具有不同的儲存與充填特性。

    乙炔鋼瓶內部通常具有 Porous Mass(多孔填料)與指定 Solvent(溶劑),乙炔則溶解於溶劑中儲存。

    因此,當 C2H2 鋼瓶出現異常高壓時,不能只看到 Pressure Reading(壓力讀值),就直接判定為 Overfill(過量充填)。

    本案例中,一支海外來源的 C2H2 鋼瓶在接收/檢查過程中發現:

    ・Cylinder Pressure(鋼瓶壓力)異常偏高
    ・壓力曾超過公司正常使用經驗範圍
    ・同時存在 PRD Leak(壓力釋放裝置洩漏)

    事故後,公司進一步與供應商確認 C2H2 充填管理方式,並從 Filling Source(充填來源端)建立兩項重要控制:

    第一:

    DMF Quantity Control
    (DMF 溶劑量管理)

    充填 C2H2 前確認 DMF 是否減少;若 DMF 不足,應先依核准要求處理 DMF 補充與相關確認,而不是直接按照原有條件繼續充填 C2H2。

    第二:

    C2H2 Filling Weight Control
    (C2H2 充填重量管理)

    要求供應商建立 Filling Record(充填紀錄),確認公司這項特定鋼瓶配置的 C2H2 充填量不得超過 11.8 kg。

    因此,本案例不只是「發現高壓」,更重要的是事故後如何把控制點由接收端往前移至充填來源端。

    一、案例概要

    氣體:

    C2H2(Acetylene,乙炔)

    異常類型:

    Cylinder Pressure Abnormality
    (鋼瓶壓力異常)

    同時發現:

    PRD Leak
    (壓力釋放裝置洩漏)

    鋼瓶來源:

    Overseas Cylinder
    (海外來源鋼瓶)

    主要調查方向:

    ・Cylinder Pressure(鋼瓶壓力)
    ・Cylinder Temperature(鋼瓶溫度)
    ・Filling Weight(充填重量)
    ・DMF Quantity(DMF 溶劑量)
    ・Cylinder Marking(鋼瓶標示)
    ・PRD Condition(PRD 狀態)
    ・Original Filling Record(原始充填紀錄)

    本案例最初觀察到的是:

    Pressure Abnormality
    (壓力異常)

    以及:

    PRD Leak
    (PRD 洩漏)

    因此在證據尚未完整前,不宜單靠壓力讀值直接將案例定義為:

    Overfill Incident
    (過量充填事故)

    比較適當的公開案例名稱是:

    C2H2 Cylinder Pressure Abnormality and PRD Leak
    (C2H2 鋼瓶壓力異常與 PRD 洩漏)

    照片 06-03-01|C2H2 案例鋼瓶

    二、C2H2 鋼瓶與一般壓縮氣體鋼瓶不同

    乙炔鋼瓶不能單純理解為:

    「鋼瓶裡裝著高壓乙炔氣體。」

    其內部儲存系統通常包含:

    Cylinder Body(鋼瓶本體)
    +
    Porous Mass(多孔填料)
    +
    Solvent(溶劑)
    +
    Dissolved Acetylene(溶解乙炔)

    因此:

    Pressure(壓力)

    只是判斷 C2H2 鋼瓶狀態的一項資訊。

    還需要考慮:

    ・Temperature(溫度)
    ・Solvent Condition(溶劑狀態)
    ・Acetylene Content(乙炔含量)
    ・Filling Weight(充填重量)
    ・Cylinder Condition(鋼瓶狀態)

    等因素。

    也就是說:

    High Pressure
    (高壓)

    是一個需要調查的異常訊號,

    但不是單獨證明 Overfill(過量充填)的全部證據。

    三、事故後建立的 DMF 溶劑量管理

    公司實際使用的部分 C2H2 鋼瓶配置中,採用:

    DMF(Dimethylformamide,二甲基甲醯胺)

    作為 Solvent(溶劑)。

    針對過去 C2H2 鋼瓶壓力異常問題,公司後續已與供應商確認:

    再次充填 C2H2 前,應確認 DMF 的狀態與數量是否符合該鋼瓶的充填要求。

    如果確認 DMF 有減少或不足:

    不應在未處理溶劑不足問題的情況下,直接按照原有條件繼續充填 C2H2。

    而應先依該鋼瓶適用的核准要求,處理 DMF 補充及相關確認。

    其管理概念可以整理為:

    Before C2H2 Filling
    (C2H2 充填前)
    ↓
    Check DMF Condition / Quantity
    (確認 DMF 狀態/數量)
    ↓
    DMF Reduced?
    (DMF 是否減少?)
    ↓
    如果不足
    ↓
    依核准要求處理 DMF 補充
    ↓
    Confirm Filling Condition
    (確認符合充填條件)
    ↓
    C2H2 Filling
    (進行 C2H2 充填)

    這項改善的重點,是避免只依照過去的 C2H2 充填量直接重新充填,而忽略鋼瓶內 Solvent Condition(溶劑狀態)可能已經發生變化。

    四、C2H2 充填重量管理

    除了 DMF 之外,公司也針對 C2H2 Filling Weight(C2H2 充填重量)與供應商建立管理要求。

    針對公司目前這項特定鋼瓶配置:

    C2H2 Filling Weight
    (C2H2 充填重量)

    不得超過:

    11.8 kg

    同時要求供應商建立:

    Filling Record
    (充填紀錄)

    記錄每次實際 C2H2 充填量。

    因此公司可以從來源端確認:

    這一次實際充填多少 C2H2?

    而不是等鋼瓶回到使用端,發現壓力異常後,才回頭追查是否可能存在充填量問題。

    管理方式可以簡化為:

    C2H2 Filling
    (C2H2 充填)
    ↓
    Record Actual Filling Weight
    (記錄實際充填重量)
    ↓
    Verify Filling Weight
    (確認充填重量)
    ↓
    Confirm ≤ 11.8 kg
    (確認不超過 11.8 kg)

    這使 Filling Weight(充填重量)成為可以追溯的客觀資料。

    五、DMF 與 C2H2 充填量必須一起管理

    本案例後續最重要的改善之一,是不再只管理:

    「C2H2 灌了多少?」

    而是同時管理:

    DMF
    +
    C2H2

    也就是:

    Control A:

    DMF Quantity Control
    (DMF 溶劑量管理)

    確認充填 C2H2 前,鋼瓶內 DMF 是否符合該鋼瓶的充填要求。

    Control B:

    C2H2 Filling Weight Control
    (C2H2 充填重量管理)

    透過供應商 Filling Record(充填紀錄),確認實際 C2H2 充填重量不超過公司該配置設定的 11.8 kg。

    兩項控制結合後:

    Cylinder Returned for Filling
    (鋼瓶返回充填)
    ↓
    Check DMF
    (確認 DMF)
    ↓
    DMF 不足時依核准要求處理
    ↓
    Confirm Filling Condition
    (確認充填條件)
    ↓
    Fill C2H2
    (充填 C2H2)
    ↓
    Record Filling Weight
    (記錄充填重量)
    ↓
    Confirm ≤ 11.8 kg
    (確認不超過 11.8 kg)

    這比單純在鋼瓶回到使用端後量測 Pressure(壓力),多了一層來源端的預防控制。

    六、為什麼 11.8 kg 不能當成所有 C2H2 鋼瓶的標準?

    11.8 kg 是公司針對目前特定 C2H2 鋼瓶配置,與供應商確認後所採用的 Filling Weight Control Limit(充填重量管理上限)。

    因此:

    11.8 kg
    ≠
    所有 C2H2 鋼瓶的通用最大充填量

    不同 C2H2 鋼瓶可能具有不同的:

    ・Cylinder Capacity(鋼瓶容量)
    ・Porous Mass(多孔填料)
    ・Solvent Type(溶劑種類)
    ・Solvent Quantity(溶劑量)
    ・Approved Acetylene Capacity(核准乙炔容量)
    ・Manufacturer Requirement(製造商要求)

    因此其他 C2H2 鋼瓶不能直接套用:

    11.8 kg

    作為充填標準。

    本數值代表的是:

    Company-specific Configuration
    (公司特定配置)

    的管理要求。

    七、為什麼看到高壓不能直接判定 Overfill?

    Pressure Reading(壓力讀值)會受到多種條件影響。

    因此:

    High Pressure Reading
    (高壓讀值)
    ≠
    Overfill Confirmed
    (過量充填已確認)

    如果要進一步確認是否存在 Overfill(過量充填),仍需要比較:

    ・Filling Weight(充填重量)
    ・Cylinder Temperature(鋼瓶溫度)
    ・Settled Pressure(穩定後壓力)
    ・DMF Condition(DMF 狀態)
    ・Cylinder Marking(鋼瓶標示)
    ・Original Filling Record(原始充填紀錄)

    例如:

    Pressure Abnormal
    (壓力異常)
    +
    Filling Record Normal
    (充填紀錄正常)

    就代表調查不能只停留在「過量充填」這一個假設。

    相反地,如果 Filling Record 顯示實際充填重量超過該鋼瓶核准/管理條件,就會形成更直接的 Evidence(證據)。

    因此:

    Pressure 是異常訊號,

    Filling Record 則可以提供來源端的實際充填證據。

    八、250 psig 應該如何理解?

    C2H2 鋼瓶相關資料中經常會看到:

    250 psig

    這個重要數值。

    但不能簡化成:

    「任何時候量到超過 250 psig,就是過量充填。」

    壓力判讀需要考慮:

    ・Pressure(壓力)
    ・Temperature(溫度)
    ・是否為 Settled Pressure(穩定後壓力)
    ・Cylinder Marked Pressure(鋼瓶標示壓力)
    ・實際適用的充填要求

    因此:

    Pressure > 250 psig
    (壓力高於 250 psig)
    ≠
    單獨足以證明 Overfill
    (過量充填)

    比較適當的判斷是:

    Abnormal Condition Requiring Investigation
    (需要進一步調查的異常狀態)

    如果鋼瓶本身具有更低的適用壓力限制,則仍應依實際鋼瓶標示及適用要求判斷。

    九、從事後偵測改成來源端預防

    本案例後續改善的一個重要意義,是將 Safety Barrier(安全防護層)往前移。

    如果只依靠鋼瓶到廠後:

    Pressure Inspection
    (壓力檢查)

    才發現異常,這主要屬於:

    Detection Control
    (偵測型控制)

    也就是異常可能已經存在,之後才被發現。

    而要求供應商:

    ・充填前確認 DMF
    ・DMF 不足時先依要求處理
    ・建立 C2H2 Filling Record
    ・控制 C2H2 充填量不超過 11.8 kg

    則是將控制點提前至:

    Filling Source
    (充填來源端)

    形成:

    Prevent
    (預防)
    ↓
    Record
    (紀錄)
    ↓
    Verify
    (確認)
    ↓
    Receive / Inspect
    (接收/檢查)

    這比單純依賴最終 Pressure Inspection,多建立了一層 Preventive Barrier(預防防護層)。

    十、PRD Leak 與高壓不能直接畫上等號

    本案例同時存在:

    High Pressure
    (壓力偏高)

    以及:

    PRD Leak
    (PRD 洩漏)

    兩項異常同時存在,並不代表已經證明:

    High Pressure
    ↓
    直接造成
    ↓
    PRD Failure

    因為 PRD Leak 還可能需要確認:

    ・PRD Component Condition(PRD 零件狀態)
    ・Seal Condition(密封狀態)
    ・Installation Condition(安裝狀態)
    ・Component Damage(零件損傷)
    ・Previous Service History(過去使用紀錄)
    ・其他相關因素

    因此:

    High Pressure + PRD Leak
    (高壓+PRD 洩漏)
    ≠
    Causal Relationship Confirmed
    (因果關係已確認)

    應先將:

    Observed Condition
    (觀察到的異常)

    與:

    Confirmed Cause
    (已確認原因)

    分開記錄。

    照片 06-03-02|PRD Leak 異常位置

    十一、PRD Activation 與 PRD Leak 不同

    PRD Activation
    (PRD 依設計條件動作)

    與:

    PRD Leak
    (PRD 發生洩漏)

    不是完全相同的概念。

    PRD Activation 表示:

    安全裝置在符合其設計條件時產生預定的壓力釋放功能。

    PRD Leak 則表示:

    在 PRD 相關位置檢測到非預期的洩漏現象。

    因此看到 PRD 區域有氣體釋出時,需要進一步確認:

    ・是否屬於正常設計條件下的 Activation(動作)
    ・是否為 Sealing Leak(密封洩漏)
    ・是否存在 Component Damage(零件損傷)
    ・是否存在 Assembly Abnormality(組裝異常)
    ・是否存在其他因素

    不能全部統稱為:

    PRD Failure
    (PRD 故障)。

    十二、不要讓案例名稱先決定 Root Cause

    如果一開始就把案例命名為:

    C2H2 Overfill Incident
    (C2H2 過量充填事故)

    後續調查容易只朝「過量充填」方向尋找證據。

    因此在原因尚未完整確認前,本網站採用較中性的名稱:

    C2H2 Cylinder Pressure Abnormality and PRD Leak
    (C2H2 鋼瓶壓力異常與 PRD 洩漏)

    這個名稱描述的是:

    「實際發現了什麼。」

    而不是:

    「我們先認為原因是什麼。」

    也就是:

    Incident Title
    (事故名稱)

    優先描述:

    Observed Condition
    (觀察到的狀況)

    而不是尚未確認的:

    Root Cause
    (根本原因)。

    十三、本案例的調查邏輯

    本案例可以整理為:

    C2H2 Cylinder Received
    (接收 C2H2 鋼瓶)
    ↓
    Pressure Abnormality Detected
    (發現壓力異常)
    ↓
    PRD Leak Detected
    (發現 PRD 洩漏)
    ↓
    Record Original Condition
    (記錄原始狀態)
    ↓
    確認:

    Pressure(壓力)
    Temperature(溫度)
    Cylinder Marking(鋼瓶標示)
    DMF Quantity(DMF 數量)
    C2H2 Filling Weight(C2H2 充填重量)
    Filling Record(充填紀錄)
    PRD Condition(PRD 狀態)

    ↓
    Compare Evidence
    (比較各項證據)
    ↓
    建立 Possible Cause
    (可能原因)
    ↓
    確認是否有足夠證據支持
    ↓
    Confirmed Cause
    (已確認原因)

    或:

    Cause Unconfirmed
    (原因尚未確認)

    十四、事故後建立的多層 Safety Barrier

    經過本案例後,可以將改善措施整理成多層 Safety Barrier(安全防護層):

    Barrier 1:

    DMF Quantity Confirmation
    (DMF 數量確認)

    目的:
    避免忽略 Solvent Loss(溶劑減少)。

    Barrier 2:

    DMF Replenishment Control
    (DMF 補充管理)

    目的:
    發現 DMF 不足時,不直接進入 C2H2 充填,而是先依核准要求處理。

    Barrier 3:

    C2H2 Filling Weight Control
    (C2H2 充填重量管理)

    目的:
    公司特定配置控制不超過 11.8 kg。

    Barrier 4:

    Filling Record
    (充填紀錄)

    目的:
    保留每次實際充填重量,使來源端資料可以追溯。

    Barrier 5:

    Receiving Pressure Inspection
    (接收壓力檢查)

    目的:
    鋼瓶回到接收端後,再建立一道異常偵測防線。

    因此:

    Source Control
    (來源端控制)
    +
    Record Control
    (紀錄管理)
    +
    Receiving Inspection
    (接收檢查)

    形成多層防護。

    這比只依靠最後一道 Pressure Check(壓力確認)更完整。

    十五、Failure Mode Database(故障模式資料庫)建議紀錄

    本案例不建議只建立一個「Overfill」Failure Mode。

    可以分開記錄:

    Failure Mode A:

    Cylinder Pressure Abnormality
    (鋼瓶壓力異常)

    Observed Condition:
    Pressure Higher Than Expected
    (壓力高於預期)

    Possible Causes:
    Overfill
    Temperature Condition
    DMF / Solvent Condition
    Other Factors

    (過量充填、溫度條件、DMF/溶劑狀態或其他因素)

    Evidence:

    ・Pressure Record(壓力紀錄)
    ・Temperature Record(溫度紀錄)
    ・DMF Record(DMF 紀錄)
    ・C2H2 Filling Record(C2H2 充填紀錄)
    ・Cylinder Data(鋼瓶資料)

    Failure Mode B:

    PRD Leak
    (PRD 洩漏)

    Failure Mode ID:
    FM-009

    Component:
    PRD
    (壓力釋放裝置)

    Observed Condition:
    Leak Detected at PRD Area
    (PRD 區域檢測到洩漏)

    Possible Causes:

    ・Seal Condition(密封狀態)
    ・Installation Condition(安裝狀態)
    ・Component Damage(零件損傷)
    ・Pressure-related Condition(壓力相關條件)
    ・Other Factors(其他因素)

    Confirmed Cause:
    依實際調查證據填寫。

    Cause Status(原因確認狀態):

    CONFIRMED(已確認)
    PROBABLE(高度可能)
    POSSIBLE(可能)
    UNCONFIRMED(尚未確認)

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

    本案例可以整理成:

    High Pressure
    (高壓)
    ≠
    Overfill Confirmed
    (已確認過量充填)

    Pressure > 250 psig
    (壓力高於 250 psig)
    ≠
    單獨足以證明過量充填

    PRD Leak
    (PRD 洩漏)
    ≠
    PRD Root Cause Confirmed
    (已確認 PRD 本身就是根本原因)

    11.8 kg
    ≠
    所有 C2H2 鋼瓶的通用充填上限

    Pressure Inspection
    (壓力檢查)
    ≠
    可以取代來源端充填管理

    本案例事故後真正重要的改善,是:

    DMF Quantity Control
    (DMF 數量管理)
    +
    C2H2 Filling Weight Control
    (C2H2 充填重量管理)
    +
    Filling Record
    (充填紀錄)
    +
    Receiving Inspection
    (接收檢查)

    將安全控制從「發現異常」往前推進到「預防異常」。

    十七、相關文章

    ・02-02|瓶閥 PRD 種類與基本原理
    ・02-04|C2H2 乙炔鋼瓶構造與特殊性
    ・05-03|鋼瓶瓶閥常見故障模式總覽
    ・06-01|誤拆 PRD 造成大量氣體洩漏事故案例
    ・06-02|PRD Burst Disc 遺漏造成大量氣體洩漏事故案例
    ・06-04|C2H2 鋼瓶焊縫洩漏事故案例
    ・09-02|多層安全防護
    ・09-04|異常現象、直接原因與根本原因的判斷方法
    ・09-05|鋼瓶維修經驗如何轉化為 Failure Mode Database

    注意事項

    本文為 C2H2(Acetylene,乙炔)鋼瓶壓力異常與 PRD Leak(壓力釋放裝置洩漏)案例的技術經驗整理。

    本文所提及 DMF(Dimethylformamide,二甲基甲醯胺)與 C2H2 充填量不超過 11.8 kg,屬於公司針對特定 C2H2 鋼瓶配置,與供應商確認後建立的管理要求,不代表所有 C2H2 鋼瓶均採用相同溶劑或相同充填重量。

    不同 C2H2 鋼瓶的 Cylinder Capacity(鋼瓶容量)、Porous Mass(多孔填料)、Solvent Type(溶劑種類)、Solvent Quantity(溶劑量)及 Approved Acetylene Capacity(核准乙炔容量)可能不同,實際充填條件應依該鋼瓶設計、標示、製造商資料、供應商核准程序及適用要求確認。

    本文不以單一 Pressure Reading(壓力讀值)判定 Overfill(過量充填),也不提供 C2H2 鋼瓶充填、DMF 補充、洩壓、排放或 PRD 維修的實際操作程序。

    最後更新:2026-09-28

  • 誤拆 PRD 造成大量氣體洩漏事故|工具干涉與安全防護案例

    06-01|誤拆 PRD 造成大量氣體洩漏事故案例

    PRD(Pressure Relief Device,壓力釋放裝置)是部分高壓氣體鋼瓶與瓶閥系統中的重要安全裝置。

    在鋼瓶維修或瓶閥相關作業中,如果工具使用位置錯誤,或工具同時接觸到原本不應被帶動的零件,就可能造成意外旋轉、鬆動或密封狀態改變。

    本案例中,作業人員在瓶閥相關作業時使用 Adjustable Wrench(活動扳手),工具意外影響 PRD 組件,使 PRD 發生鬆動/位置改變,隨後造成大量氣體洩漏。

    這起案例最重要的經驗並不是:

    「活動扳手一定會造成事故。」

    而是:

    Tool Selection(工具選擇)
    +
    Tool Contact Area(工具接觸位置)
    +
    Component Clearance(零件間隙)
    +
    Work Method(作業方式)

    都可能成為影響 PRD 安全狀態的重要因素。

    一、案例概要

    異常類型:

    PRD Loose / Position Abnormal
    (PRD 鬆動/位置異常)

    事故結果:

    Large Gas Release
    (大量氣體洩漏)

    主要相關部位:

    ・Cylinder Valve(鋼瓶瓶閥)
    ・PRD(壓力釋放裝置)
    ・PRD Sealing Area(PRD 密封區域)
    ・Hand Tool(手工具)

    本案例在瓶閥相關作業過程中,使用 Adjustable Wrench(活動扳手)進行操作。

    過程中工具影響到 PRD 相關組件,使原本的安裝/密封狀態發生改變,最終造成氣體大量洩漏。

    照片 06-01-01|案例相關 Valve / PRD 位置

    二、什麼是 PRD?

    PRD 是 Pressure Relief Device(壓力釋放裝置)的縮寫。

    依鋼瓶、瓶閥與氣體用途的不同,PRD 的實際設計可能不同。

    例如可能涉及:

    ・Burst Disc(爆破片)
    ・Fusible Element / Fuse Metal(易熔元件/易熔金屬)
    ・Combination Device(組合式裝置)
    ・其他經核准的壓力釋放設計

    並不是所有鋼瓶都使用相同 PRD,也不是所有氣體服務都一定配置 PRD。

    因此在討論 PRD 異常時,必須先確認實際:

    Cylinder Specification(鋼瓶規格)
    Valve Model(瓶閥型號)
    Gas Service(使用氣體)
    PRD Design(PRD 設計)

    不能把某一種 PRD 結構直接套用到所有鋼瓶。

    三、事故是如何發生的?

    本案例可簡化為:

    Valve Related Work
    (瓶閥相關作業)
    ↓
    使用 Adjustable Wrench
    (活動扳手)
    ↓
    工具影響 PRD 相關組件
    ↓
    PRD Position Changed / Loosened
    (PRD 位置改變/鬆動)
    ↓
    Sealing Condition Changed
    (密封狀態改變)
    ↓
    Large Gas Release
    (大量氣體洩漏)

    這條事故鏈的重要之處,在於:

    最初的異常並不是鋼瓶本體突然失效。

    而是作業過程中,原本不應被改變的 PRD 安裝/密封狀態受到影響。

    四、為什麼 Adjustable Wrench 需要特別注意?

    Adjustable Wrench(活動扳手)的開口可以調整,因此適用範圍很廣。

    但在零件密集、間隙有限的瓶閥區域使用工具時,需要考慮的不只是:

    「能不能夾住。」

    還需要確認:

    ・工具實際接觸哪一個零件
    ・工具旋轉時的活動範圍
    ・是否可能碰到鄰近組件
    ・是否可能同時帶動其他零件
    ・工具尺寸與作業空間是否適當

    因此:

    Tool Fits
    (工具夾得住)

    ≠

    Tool Is Appropriate
    (工具就一定適合這項作業)

    這是本案例非常重要的經驗。

    五、Fixed-size Wrench(固定尺寸扳手)作為公司改善措施

    本案例發生後,公司針對相關作業調整 Tool Control(工具管理)方式。

    其中一項改善措施是:

    限制相關作業使用 Adjustable Wrench(活動扳手),改採符合指定尺寸的 Fixed-size Wrench(固定尺寸扳手)。

    這項措施的目的,不只是更換工具,而是利用工具本身的尺寸限制,降低:

    ・錯誤接觸位置
    ・不適當夾持
    ・工具干涉鄰近零件
    ・誤帶動 PRD

    等風險。

    這類設計可以視為:

    Error Proofing / Poka-Yoke
    (防錯設計)

    的一種實務概念。

    需要注意:

    「禁止活動扳手、改用固定尺寸扳手」

    是本案例後續建立的 Company Practice(公司實務措施),不應直接描述成所有 DOT 鋼瓶維修作業的通用法規要求。

    照片 06-01-02|Adjustable Wrench 與 Fixed-size Wrench 比較

    主要用來說明 Tool Control(工具管理)的差異,不需要重現事故操作。

    六、不要為了拍照重新模擬事故

    本案例照片的目的,是讓讀者理解:

    Tool Interference(工具干涉)

    而不是重新演示如何讓 PRD 鬆動。

    因此後續補照片時:

    可以:
    ・拍攝工具外觀
    ・拍攝 Valve / PRD 相對位置
    ・使用不接觸實際零件的示意圖
    ・以箭頭標示可能的 Tool Interference Area(工具干涉區域)

    不建議:

    為了拍攝案例照片,實際使用工具去模擬 PRD 被帶動的狀況。

    如果沒有適合的事故原始照片,以 Illustration(示意圖)取代即可。

    七、PRD Witness Mark(PRD 見證標記)的用途

    部分設備或公司實務可能利用 Witness Mark(見證標記/位置標記),協助目視確認零件的相對位置是否發生變化。

    例如:

    Before:
    Mark Alignment Normal
    (標記位置正常)

    After:
    Mark Misalignment
    (標記位置偏移)

    這可以作為:

    Visual Evidence(目視證據)

    協助發現 PRD 可能曾發生旋轉或位置改變。

    照片 06-01-03|PRD Witness Mark 示意

    八、Witness Mark 不等於 Torque Proof

    這一點非常重要。

    Witness Mark(見證標記)可以協助確認:

    「相對位置有沒有發生變化。」

    但是它不能單獨證明:

    ・實際安裝扭力是多少
    ・目前殘留扭力是多少
    ・零件一定符合指定 Torque Requirement(扭力要求)

    因此:

    Witness Mark Normal
    (見證標記正常)
    ≠
    Torque Confirmed
    (扭力已確認)

    同樣地:

    Witness Mark Shift
    (見證標記偏移)
    ≠
    已經知道實際旋轉量或鬆動扭力

    Witness Mark 是:

    Visual Indicator(目視指示)

    而不是:

    Torque Measuring Device(扭力測量工具)。

    九、Failure Mode(故障模式)與 Root Cause(根本原因)需要分開

    如果事故紀錄只寫:

    Root Cause:
    PRD Loose(PRD 鬆動)

    技術上並不完整。

    因為:

    PRD Loose

    描述的是發生了什麼異常,比較接近 Failure Mode(故障模式)或 Observed Condition(觀察到的狀態)。

    真正需要進一步分析的是:

    「為什麼 PRD 會鬆動?」

    本案例已知的重要資訊包括:

    ・相關作業正在進行
    ・使用 Adjustable Wrench
    ・PRD 位置受到影響
    ・之後發生大量氣體洩漏

    因此原因分析應從這些 Evidence(證據)繼續往下追。

    十、Direct Cause(直接原因)與 Root Cause(根本原因)

    可以將本案例概念化為:

    Observed Condition(觀察到的狀況):
    Large Gas Release
    (大量氣體洩漏)

    Failure Mode(故障模式):
    PRD Loose / Position Abnormal
    (PRD 鬆動/位置異常)

    Direct Cause / Causal Factor
    (直接原因/因果因素):

    PRD Sealing Condition Changed
    (PRD 密封狀態受到改變)

    Contributing Factor
    (促成因素):

    Tool Contact / Tool Interference
    (工具接觸/工具干涉)

    接著才需要問:

    為什麼工具能夠影響 PRD?

    可能涉及:

    ・Tool Selection(工具選擇)
    ・Work Method(作業方式)
    ・Tool Control(工具管理)
    ・Component Clearance(零件間隙)
    ・Training(訓練)
    ・Inspection Barrier(檢查防護層)
    ・其他因素

    因此完整的 Root Cause Analysis(根本原因分析)不能只停在:

    「Worker used wrong tool」
    (人員使用錯誤工具)

    而應繼續確認系統為什麼允許這個錯誤發展成事故。

    十一、Safety Barrier(安全防護層)的概念

    本案例可以用 Safety Barrier(安全防護層)的方式分析。

    例如:

    Barrier 1:
    Approved Tool Selection
    (核准工具選擇)

    目的:
    降低錯誤工具使用風險。

    Barrier 2:
    Tool Clearance Check
    (工具操作空間確認)

    目的:
    避免工具接觸鄰近零件。

    Barrier 3:
    PRD Position Inspection
    (PRD 位置檢查)

    目的:
    發現 PRD 是否發生位置改變。

    Barrier 4:
    Witness Mark
    (見證標記)

    目的:
    提供快速 Visual Indicator(目視指示)。

    Barrier 5:
    Post-work Inspection / Leak Check
    (作業後檢查/洩漏確認)

    目的:
    在設備進入下一階段前發現異常。

    單一 Barrier 可能失效。

    因此較可靠的安全設計通常不是依靠:

    「操作人員一定不會犯錯。」

    而是建立多層防護。

    十二、不要只寫「Operator Error」

    事故發生後,如果調查報告只寫:

    Root Cause:
    Operator Error(人員操作錯誤)

    通常不足以支持有效改善。

    因為這沒有回答:

    ・為什麼錯誤工具可以取得?
    ・為什麼工具能接觸 PRD?
    ・是否有工具選擇標準?
    ・是否有作業前檢查?
    ・是否有位置確認?
    ・是否有第二道檢查?
    ・是否能用工具設計直接降低誤用可能?

    如果只要求:

    「以後小心一點。」

    相同 Failure Mode 仍可能再次發生。

    本案例後續採用固定尺寸工具的價值就在於:

    把部分風險控制從「依賴人的注意力」

    轉變成:

    Tool-based Error Proofing
    (以工具進行防錯)。

    十三、本案例的事故鏈

    可以整理為:

    Valve Related Work
    (瓶閥相關作業)
    ↓
    Adjustable Wrench Used
    (使用活動扳手)
    ↓
    Tool Interference
    (工具發生干涉)
    ↓
    PRD Position Changed
    (PRD 位置改變)
    ↓
    PRD Sealing Condition Changed
    (PRD 密封狀態改變)
    ↓
    Gas Release
    (氣體洩漏)

    改善後希望建立:

    Approved Fixed-size Tool
    (核准的固定尺寸工具)
    ↓
    Reduced Wrong Contact Opportunity
    (降低錯誤接觸機會)
    ↓
    PRD Position Check
    (PRD 位置確認)
    ↓
    Visual / Witness Mark Check
    (目視/見證標記確認)
    ↓
    Applicable Leak Check
    (適用的洩漏確認)
    ↓
    Multiple Safety Barriers
    (多層安全防護)

    【照片 06-01-04|PRD Tool Interference 示意圖】

    建議:

    使用 Illustration(示意圖)呈現:

    Valve Body
    PRD
    Tool
    Possible Interference Area

    不需要畫出詳細拆卸方法或工具旋轉步驟。

    十四、Failure Mode Database(故障模式資料庫)建議紀錄

    Failure Mode ID(故障模式編號):
    FM-007

    Failure Mode(故障模式):
    PRD Loose / Position Abnormal
    (PRD 鬆動/位置異常)

    Component(相關部位):
    PRD / Cylinder Valve
    (壓力釋放裝置/鋼瓶瓶閥)

    Observed Condition(觀察到的異常):
    PRD Position Changed
    (PRD 位置發生改變)

    Event Result(事件結果):
    Large Gas Release
    (大量氣體洩漏)

    Detection Method(發現方式):
    Visual Inspection / Leak Detection
    (目視檢查/洩漏檢測)

    Known Evidence(已知證據):
    Tool interaction with PRD area
    (工具與 PRD 區域發生接觸/干涉)

    Contributing Factor(促成因素):
    Tool Selection / Tool Interference
    (工具選擇/工具干涉)

    Corrective / Preventive Measure
    (改善/預防措施):
    Fixed-size Tool Control
    (固定尺寸工具管理)

    Cause Status(原因確認狀態):
    依原始事故調查資料判定。

    十五、實務判斷重點

    本案例可以整理成以下幾個重要觀念:

    Tool Fits
    (工具夾得住)
    ≠
    Tool Is Appropriate
    (工具適合這項作業)

    PRD Loose
    (PRD 鬆動)
    ≠
    Root Cause
    (根本原因)

    Witness Mark
    (見證標記)
    ≠
    Torque Proof
    (扭力證明)

    Operator Error
    (人員操作錯誤)
    ≠
    Root Cause Analysis Completed
    (根本原因分析已完成)

    更重要的是:

    不要只要求人員「更加小心」,

    而是思考能否透過:

    Tool Selection(工具選擇)
    +
    Error Proofing(防錯設計)
    +
    Inspection(檢查)
    +
    Leak Detection(洩漏確認)

    建立多層 Safety Barrier(安全防護層)。

    十六、相關文章

    ・02-02|瓶閥 PRD 種類與基本原理
    ・04-01|瓶閥拆卸與安裝
    ・05-03|鋼瓶瓶閥常見故障模式總覽
    ・06-02|PRD Burst Disc 遺漏造成大量氣體洩漏事故案例
    ・06-07|瓶閥安裝後 PRD 鬆動案例
    ・07-06|固定尺寸扳手與活動扳手的使用風險
    ・09-01|Stop Work / Good Catch
    ・09-02|多層安全防護
    ・09-04|異常現象、直接原因與根本原因的判斷方法
    ・09-05|鋼瓶維修經驗如何轉化為 Failure Mode Database

    注意事項

    本文為特殊氣體鋼瓶維修事故案例的技術經驗整理,目的在於說明 Tool Control(工具管理)、PRD Position(PRD 位置)、Safety Barrier(安全防護層)與 Root Cause Analysis(根本原因分析)的重要性。

    本文所述「限制使用活動扳手、改採固定尺寸扳手」屬於本案例後續建立的 Company Practice(公司實務措施),不代表所有 DOT 鋼瓶、所有 PRD 或所有瓶閥作業均具有相同工具要求。

    不同 Cylinder、Valve、PRD 與 Gas Service 的結構及要求可能不同,實際作業應依製造商技術資料、適用規範及經核准的作業程序執行。

    本文不提供 PRD 拆卸、洩壓、排放或現場事故處置操作程序。

    最後更新:2026-09-28

  • C2H2 鋼瓶焊縫洩漏事故|Cylinder Body Weld Area Leak 案例

    06-04|C2H2 鋼瓶焊縫洩漏事故案例

    C2H2(Acetylene,乙炔)鋼瓶除了 Valve(瓶閥)、PRD(Pressure Relief Device,壓力釋放裝置)及 Neck Area(瓶頸區域)之外,Cylinder Body(鋼瓶本體)本身也是重要的檢查區域。

    本案例中,一支 C2H2 鋼瓶發生 Gas Leak(氣體洩漏)。

    經過 Leak Location Identification(洩漏位置確認)後,發現洩漏並不是來自:

    ・Valve(瓶閥)
    ・PRD(壓力釋放裝置)
    ・Neck Area(瓶頸區域)
    ・Outlet Connection(出口連接部)

    而是位於:

    Cylinder Body Weld Area
    (鋼瓶本體焊接區域)

    這類異常與一般瓶閥洩漏具有完全不同的技術意義。

    最重要的第一步不是立即判斷:

    「焊接不良。」

    而是先確認:

    Leak Location
    (洩漏位置)

    以及:

    Cylinder Body Integrity
    (鋼瓶本體完整性)

    是否已受到影響。

    一、案例概要

    氣體:

    C2H2(Acetylene,乙炔)

    鋼瓶類型:

    Welded Steel Cylinder
    (焊接式鋼製鋼瓶)

    異常類型:

    Cylinder Body Leak
    (鋼瓶本體洩漏)

    洩漏位置:

    Cylinder Body Weld Area
    (鋼瓶本體焊接區域)

    主要已知事實:

    ・鋼瓶發生氣體洩漏
    ・洩漏位置經確認位於鋼瓶本體焊接區域
    ・不是一般 Valve Leak(瓶閥洩漏)
    ・不是 Neck Leak(瓶頸洩漏)
    ・不是 PRD Leak(PRD 洩漏)

    因此,本案例首先可以確認的是:

    Failure Mode
    (故障模式)

    屬於:

    Cylinder Body Weld Area Leak
    (鋼瓶本體焊接區域洩漏)

    但:

    Leak at Weld Area
    (焊接區域發生洩漏)

    並不能單獨證明:

    Original Welding Defect
    (原始焊接缺陷)

    就是 Root Cause(根本原因)。

    照片 06-04-01|C2H2 焊接式鋼瓶整體

    二、什麼是 Welded Cylinder(焊接式鋼瓶)?

    部分 C2H2 鋼瓶採用 Welded Steel Cylinder(焊接式鋼製鋼瓶)結構。

    這類鋼瓶的 Cylinder Body(鋼瓶本體)製造過程中存在 Welding Joint(焊接接合部)。

    因此在進行 Cylinder Body Inspection(鋼瓶本體檢查)時:

    Weld Area
    (焊接區域)

    也是重要的檢查位置之一。

    但需要注意:

    「鋼瓶具有焊縫」

    本身不是異常。

    真正需要關注的是:

    Weld Area 是否存在:

    ・Leak(洩漏)
    ・Crack-like Indication(疑似裂紋跡象)
    ・Corrosion(腐蝕)
    ・Abnormal Deformation(異常變形)
    ・Mechanical Damage(機械損傷)
    ・其他異常狀況

    因此:

    Weld Present
    (存在焊縫)
    ≠
    Weld Defect
    (焊接缺陷)

    三、第一步應先確認 Leak Location(洩漏位置)

    當鋼瓶發生 Leak(洩漏)時,不能只記錄:

    「Cylinder Leak」

    因為不同洩漏位置代表不同的 Failure Mode(故障模式)。

    例如:

    Neck Leak
    (瓶頸洩漏)

    可能涉及:

    Cylinder Neck Thread
    (鋼瓶瓶牙)

    或:

    Valve Inlet Thread
    (瓶閥入口螺紋)

    等相關部位。

    Cross Port Leak
    (閥內串漏)

    主要涉及:

    Valve Internal Sealing
    (瓶閥內部密封)

    Outlet Connection Leak
    (出口連接洩漏)

    主要涉及:

    Outlet Thread / Sealing Interface
    (出口螺紋/密封介面)

    PRD Leak
    (PRD 洩漏)

    主要涉及:

    Pressure Relief Device
    (壓力釋放裝置)

    Cylinder Body Leak
    (鋼瓶本體洩漏)

    則代表:

    異常已經出現在 Pressure-containing Body
    (承壓本體)

    相關區域。

    因此:

    Leak Location Identification
    (洩漏位置確認)

    是後續判斷非常重要的第一層資訊。

    四、焊縫位置洩漏不等於已確認 Welding Defect

    本案例已確認:

    Leak Location
    (洩漏位置)

    位於:

    Cylinder Body Weld Area
    (鋼瓶本體焊接區域)

    但是:

    Leak at Weld Area
    (焊接區域洩漏)

    只是在描述 Observed Condition(觀察到的異常)。

    不能直接改寫成:

    Root Cause:
    Poor Welding
    (焊接不良)

    因為造成焊接區域失去完整性的因素可能不只一種。

    例如可能需要調查:

    ・Original Manufacturing Condition
    (原始製造狀態)

    ・Weld Quality
    (焊接品質)

    ・Corrosion
    (腐蝕)

    ・Material Degradation
    (材料劣化)

    ・Mechanical Damage
    (機械損傷)

    ・Fatigue-related Damage
    (疲勞相關損傷)

    ・Thermal History
    (熱歷史)

    ・Service History
    (使用歷史)

    ・其他可能因素

    因此:

    Failure Location
    (故障位置)
    ≠
    Root Cause
    (根本原因)

    照片 06-04-02|實際 Weld Area Leak 位置

    五、Observed Condition、Failure Mode 與 Root Cause 要分開

    這個案例非常適合說明三個不同層級。

    第一層:

    Observed Condition
    (觀察到的異常)

    Gas Leak Detected
    (檢測到氣體洩漏)

    第二層:

    Failure Mode
    (故障模式)

    Cylinder Body Weld Area Leak
    (鋼瓶本體焊接區域洩漏)

    第三層:

    Root Cause
    (根本原因)

    必須依實際調查證據確認。

    因此不能寫成:

    「因為焊接不良,所以鋼瓶漏氣。」

    除非已經有足夠 Evidence(證據)支持。

    比較正確的紀錄方式是:

    Gas Leak Detected
    ↓
    Leak Location Confirmed
    ↓
    Cylinder Body Weld Area
    ↓
    Failure Mode Identified
    ↓
    Evidence Collection
    ↓
    Cause Investigation
    ↓
    Root Cause Confirmed / Unconfirmed

    六、為什麼 Cylinder Body Leak 的意義不同?

    Valve、PRD 或 Connection(連接部)發生洩漏時,異常主要位於附屬零組件或連接介面。

    但:

    Cylinder Body Leak
    (鋼瓶本體洩漏)

    涉及的是:

    Pressure-containing Body
    (承壓本體)

    本身的完整性。

    因此不能把它當成一般:

    Valve Maintenance Issue
    (瓶閥維修問題)

    處理。

    尤其當洩漏位於:

    Weld Area
    (焊接區域)

    時,更需要保留原始狀態與相關資料,進行適當的技術判定。

    七、不要以現場研磨或補焊方式直接處理

    如果在 Cylinder Body Weld Area(鋼瓶本體焊接區域)發現洩漏,不應因為洩漏點很小,就把它視為一般表面缺陷。

    例如不應自行採取:

    Grinding
    (研磨)

    Welding
    (補焊)

    Adhesive Repair
    (黏著劑修補)

    Surface Filling
    (表面填補)

    等方式,企圖讓洩漏暫時消失後繼續使用。

    原因是:

    Leak Disappeared
    (洩漏消失)
    ≠
    Pressure Boundary Integrity Restored
    (承壓邊界完整性已恢復)

    而且未經適當評估的加工,可能破壞原始 Evidence(證據),使後續原因調查更加困難。

    因此這類異常的核心原則是:

    Preserve Evidence
    (保存證據)

    以及:

    Qualified Evaluation
    (由適當資格/權限進行評估)

    而不是:

    Field Repair
    (現場自行修補)。

    八、案例調查時應保留哪些 Evidence?

    如果發現 Cylinder Body Weld Area Leak,建議保留的調查資料包括:

    Cylinder Identification
    (鋼瓶識別資料)

    Cylinder Specification
    (鋼瓶規格)

    Manufacturing Information
    (製造資訊)

    Requalification History
    (再檢驗歷史)

    Service History
    (使用歷史)

    Gas Service
    (使用氣體)

    Leak Location
    (洩漏位置)

    Weld Area Condition
    (焊接區域狀態)

    Corrosion Condition
    (腐蝕狀態)

    Mechanical Damage
    (機械損傷)

    Original Photos
    (原始照片)

    以及其他與事故相關的紀錄。

    尤其照片應優先保存:

    Original Condition
    (原始狀態)

    不要先進行:

    Cleaning
    Grinding
    Polishing
    Painting
    Repair

    (清潔、研磨、拋光、重新塗裝或修補)

    之後才拍攝。

    【照片 06-04-03|Weld Area 局部放大】

    照片 06-04-03|Weld Area 局部放大

    九、Corrosion(腐蝕)也是需要調查的方向

    如果洩漏位置位於 Weld Area(焊接區域),Corrosion(腐蝕)也是可能需要調查的因素之一。

    但同樣需要避免反向推論。

    例如:

    看到 Rust
    (鏽蝕)

    不代表:

    Rust Caused Leak
    (鏽蝕就是洩漏原因)

    必須進一步確認:

    ・腐蝕位置
    ・腐蝕程度
    ・是否與洩漏位置一致
    ・材料是否存在減薄
    ・周圍是否有其他損傷
    ・使用環境與歷史

    因此:

    Corrosion Present
    (存在腐蝕)
    ≠
    Corrosion Confirmed as Root Cause
    (腐蝕已確認為根本原因)

    十、Age(鋼瓶年齡)也不能直接當成原因

    另一個常見錯誤是:

    看到較舊的鋼瓶發生洩漏,就直接寫:

    「因為鋼瓶太老。」

    Cylinder Age(鋼瓶年齡)可以是調查資訊之一,但不能單獨證明:

    Age
    ↓
    caused
    ↓
    Weld Leak

    應進一步查看:

    ・Manufacturing Date(製造日期)
    ・Requalification History(再檢驗歷史)
    ・Service Condition(使用條件)
    ・Corrosion Condition(腐蝕狀態)
    ・Mechanical History(機械損傷歷史)
    ・Material Condition(材料狀態)

    因此:

    Old Cylinder
    (舊鋼瓶)
    ≠
    Age-related Failure Confirmed
    (已確認為老化造成故障)

    十一、Failure Mode Database(故障模式資料庫)建議紀錄

    Failure Mode ID:
    FM-010

    Failure Mode:
    Cylinder Body Weld Area Leak
    (鋼瓶本體焊接區域洩漏)

    Component:
    Cylinder Body
    (鋼瓶本體)

    Location:
    Weld Area
    (焊接區域)

    Gas Service:
    C2H2
    (Acetylene,乙炔)

    Observed Condition:
    Gas Leak Detected at Weld Area
    (焊接區域檢測到氣體洩漏)

    Detection Method:
    Leak Detection / Visual Inspection
    (洩漏檢測/目視檢查)

    Possible Causes:

    ・Manufacturing-related Condition
    (製造相關因素)

    ・Weld-related Condition
    (焊接相關因素)

    ・Corrosion
    (腐蝕)

    ・Material Degradation
    (材料劣化)

    ・Mechanical Damage
    (機械損傷)

    ・Fatigue-related Damage
    (疲勞相關損傷)

    ・Thermal History
    (熱歷史)

    ・Other Factors
    (其他因素)

    Confirmed Root Cause:
    依實際事故調查結果填寫

    Cause Status:
    CONFIRMED(已確認)
    PROBABLE(高度可能)
    POSSIBLE(可能)
    UNCONFIRMED(尚未確認)

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

    本案例可以整理成:

    Gas Leak
    (氣體洩漏)
    ≠
    Valve Leak
    (瓶閥洩漏)

    Weld Area Leak
    (焊接區域洩漏)
    ≠
    Welding Defect Confirmed
    (已確認焊接缺陷)

    Corrosion Present
    (存在腐蝕)
    ≠
    Corrosion Root Cause Confirmed
    (已確認腐蝕為根本原因)

    Old Cylinder
    (舊鋼瓶)
    ≠
    Age-related Failure Confirmed
    (已確認老化故障)

    Leak Stopped After Repair
    (修補後不再洩漏)
    ≠
    Cylinder Integrity Restored
    (鋼瓶本體完整性已恢復)

    因此這類事故的正確思考順序應該是:

    Where is the Leak?
    (洩漏在哪裡?)
    ↓
    What Component Failed?
    (哪一個部位發生異常?)
    ↓
    What Evidence Exists?
    (有哪些證據?)
    ↓
    What are the Possible Causes?
    (有哪些可能原因?)
    ↓
    Which Cause is Supported by Evidence?
    (哪個原因有證據支持?)
    ↓
    Confirmed / Unconfirmed
    (確認/尚未確認)

    十三、與 06-03 案例的差異

    06-03:

    C2H2 Cylinder Pressure Abnormality and PRD Leak
    (C2H2 鋼瓶壓力異常與 PRD 洩漏)

    主要調查:

    ・Pressure
    ・Temperature
    ・DMF
    ・Filling Weight
    ・Filling Record
    ・PRD Condition

    06-04:

    Cylinder Body Weld Area Leak
    (鋼瓶本體焊接區域洩漏)

    主要調查:

    ・Leak Location
    ・Cylinder Body
    ・Weld Area
    ・Corrosion
    ・Material Condition
    ・Manufacturing / Service History

    因此即使兩起事故使用的都是:

    C2H2 Cylinder
    (乙炔鋼瓶)

    Failure Mode(故障模式)與調查方向仍完全不同。

    十四、相關文章

    ・02-04|C2H2 乙炔鋼瓶構造與特殊性
    ・05-03|鋼瓶瓶閥常見故障模式總覽
    ・06-03|C2H2 鋼瓶壓力異常與 PRD 洩漏事故案例
    ・08-02|DOT 鋼瓶再檢驗與判定
    ・08-04|Repair、Rebuild、Requalification 與 Maintenance 的差異
    ・09-04|異常現象、直接原因與根本原因的判斷方法
    ・09-05|鋼瓶維修經驗如何轉化為 Failure Mode Database

    注意事項

    本文為 C2H2(Acetylene,乙炔)鋼瓶 Cylinder Body Weld Area Leak(鋼瓶本體焊接區域洩漏)的事故案例整理。

    本文所稱 Weld Area Leak(焊接區域洩漏)是 Failure Location / Failure Mode(故障位置/故障模式)的描述,不代表已確認原始製造焊接缺陷為 Root Cause(根本原因)。

    實際 Cylinder Body(鋼瓶本體)異常的判定、再檢驗、維修、報廢或其他處置,應依鋼瓶規格、實際狀態、適用法規/標準及具適當資格或權限的單位判定。

    本文不提供承壓鋼瓶本體的現場焊接、研磨、補漏或其他修補操作程序。

    最後更新:2026-09-28

  • PRD Burst Disc 遺漏造成氣體洩漏事故案例

    06-02|PRD Burst Disc 遺漏造成大量氣體洩漏事故案例

    PRD(Pressure Relief Device,壓力釋放裝置)的安全功能,不只是取決於外部零件是否存在,也與內部組件是否完整、規格是否正確以及組裝狀態有關。

    本案例中,從外觀上可以看到 PRD 相關組件,但實際內部缺少 Burst Disc(爆破片)。

    最終在後續使用/壓力條件下發生大量氣體洩漏,並造成現場人員疏散。

    這起案例帶來一個非常重要的觀念:

    PRD Present(PRD 外觀存在)
    ≠
    PRD Assembly Complete(PRD 組件完整)

    同樣地:

    Component Present(零件存在)
    ≠
    Correct Component Installed(安裝的是正確零件)

    因此,PRD 的判斷不能只停留在「外觀看得到安全裝置」。

    一、案例概要

    異常類型:

    PRD Missing Component
    (PRD 組件缺件)

    主要異常:

    Burst Disc Missing
    (爆破片遺漏)

    事故結果:

    Large Gas Release
    (大量氣體洩漏)

    並造成:

    Personnel Evacuation
    (人員疏散)

    本案例的核心問題並不是:

    「PRD 整組完全沒有安裝。」

    而是:

    PRD 外部相關零件存在,
    但內部應有的 Burst Disc(爆破片)並未正確存在於組件中。

    因此,單純進行 Exterior Visual Inspection(外觀目視檢查),不一定能發現這類內部缺件問題。

    照片 06-02-01|案例 PRD 外觀

    二、什麼是 Burst Disc(爆破片)?

    Burst Disc(爆破片)是一種壓力作用型的非重閉式安全元件。

    在採用這類設計的 PRD 中,Burst Disc 是安全裝置的一部分。

    當系統達到其設計條件時,爆破片會依其設計功能動作,形成壓力釋放路徑。

    但需要特別注意:

    並不是所有鋼瓶都使用 Burst Disc。

    也不是所有 PRD 都具有完全相同的內部結構。

    實際配置必須依:

    ・Cylinder Specification(鋼瓶規格)
    ・Valve Model(瓶閥型號)
    ・Gas Service(使用氣體)
    ・PRD Design(PRD 設計)
    ・Manufacturer Requirement(製造商要求)
    ・Applicable Requirement(適用要求)

    確認。

    因此本文只討論本案例所使用的 PRD 結構,不將它延伸成所有鋼瓶的通用設計。

    三、事故中的主要異常

    本案例可以簡化為:

    PRD Exterior Present
    (PRD 外部組件存在)
    ↓
    Internal Component Missing
    (內部組件缺件)
    ↓
    Burst Disc Missing
    (爆破片遺漏)
    ↓
    PRD Assembly Incomplete
    (PRD 組件不完整)
    ↓
    後續壓力/使用條件
    ↓
    Gas Release
    (氣體洩漏)
    ↓
    Personnel Evacuation
    (人員疏散)

    因此,本案例最值得注意的是:

    Exterior Presence(外部存在)
    不能證明
    Internal Completeness(內部完整性)。

    四、外觀正常不代表內部組件完整

    在許多設備檢查中,Visual Inspection(目視檢查)是非常重要的第一道防線。

    但是 Visual Inspection 也有其限制。

    如果某一個零件位於組件內部,從外部無法直接看到,就不能因為:

    外殼存在
    +
    外觀正常

    就推論:

    內部所有零件都存在且正確。

    因此:

    Exterior Visual Pass
    (外觀目視無明顯異常)
    ≠
    Internal Component Complete
    (內部組件完整)

    這個觀念不只適用於 PRD,也適用於許多由多個零件組成的安全裝置。

    照片 06-02-02|PRD 組件構成

    注意:

    不同 PRD Design(PRD 設計)的零件組成可能不同。

    照片只能代表該實際型號,不能標示成所有 PRD 的標準結構。

    五、Missing Component、Wrong Component 與 Assembly Error 要分開

    在 Failure Analysis(故障分析)中,「PRD 有問題」這種描述太籠統。

    至少應區分:

    Missing Component(零件遺漏)
    → 原本應存在的零件沒有安裝

    Wrong Component(錯誤零件)
    → 有安裝零件,但規格或型式不正確

    Assembly Error(組裝異常)
    → 零件存在且可能正確,但安裝方式或組裝狀態不符合要求

    Component Damage(零件損傷)
    → 零件存在,但本身已受損

    這四種 Failure Condition(故障狀態)的調查方向並不相同。

    本案例目前已知的核心異常是:

    Missing Component
    (零件遺漏)

    更具體來說:

    Burst Disc Missing
    (爆破片遺漏)。

    六、為什麼「有裝 PRD」仍不足以判定合格?

    假設檢查紀錄只寫:

    PRD:Installed
    (PRD:已安裝)

    這項資訊只能說明:

    外部看起來存在 PRD 相關組件。

    但它不能單獨證明:

    ・內部零件完整
    ・零件規格正確
    ・零件方向正確
    ・組裝狀態正確
    ・密封狀態正常
    ・整體符合該型號要求

    因此:

    PRD Installed
    (PRD 已安裝)
    ≠
    PRD Verified
    (PRD 已完成適當確認)

    這也是本案例非常重要的經驗。

    七、Burst Disc Rating(爆破片額定值)也需要正確確認

    除了「有沒有 Burst Disc」之外,另一個重要問題是:

    安裝的是不是正確規格的 Burst Disc?

    公司實務中曾接觸到例如:

    Cylinder Service Pressure(鋼瓶工作壓力)
    2015 psig

    搭配:

    Burst Disc
    3360 psig

    以及:

    Cylinder Service Pressure
    2400 psig

    搭配:

    Burst Disc
    4000 psig

    這些數值是特定鋼瓶/瓶閥配置的實際案例資料。

    它們不代表可以建立:

    「Service Pressure × 固定倍率 = Burst Disc Rating」

    這種通用規則。

    因此:

    2015 → 3360
    2400 → 4000

    應視為:

    Specific Configuration Example
    (特定配置案例)

    而不是:

    Universal Selection Formula
    (通用選擇公式)。

    實際 PRD / Burst Disc 規格仍應依鋼瓶、瓶閥、氣體用途、製造商資料及適用要求確認。

    八、完整性檢查與規格確認是兩個不同問題

    PRD 的確認至少可以分成兩個不同方向:

    第一個問題:

    Component Complete?
    (零件是否完整?)

    例如:

    Burst Disc 是否存在。

    第二個問題:

    Correct Component?
    (零件是否正確?)

    例如:

    Burst Disc 的型式、規格是否符合該配置要求。

    因此可能存在:

    情況 A:

    Burst Disc Missing
    (爆破片遺漏)

    → Completeness Problem
    (完整性問題)

    情況 B:

    Burst Disc Present but Incorrect
    (有爆破片,但規格不正確)

    → Specification Problem
    (規格問題)

    情況 C:

    Burst Disc Correct but Assembly Abnormal
    (零件正確,但組裝異常)

    → Assembly Problem
    (組裝問題)

    這三種情況不能全部只記錄成:

    「PRD NG」。

    九、事故後不能只補上一片 Burst Disc 就結案

    當事故已經發生後,如果調查只做:

    發現 Burst Disc Missing
    ↓
    補裝 Burst Disc
    ↓
    結案

    可能會錯過更重要的問題:

    「為什麼會漏裝?」

    因此 Corrective Action(矯正措施)與 Root Cause Analysis(根本原因分析)應分開。

    補上遺漏零件,可以處理:

    Immediate Condition
    (眼前異常)

    但 Root Cause Analysis 還需要確認:

    ・組裝流程如何控制零件完整性?
    ・是否有零件清單?
    ・是否有組裝後確認?
    ・是否有第二人確認?
    ・是否能從外觀辨識缺件?
    ・是否有防錯機制?
    ・是否有供應/包裝錯誤?
    ・是否有紀錄可以追溯?

    因此:

    Corrective Action Completed
    (矯正措施完成)
    ≠
    Root Cause Confirmed
    (根本原因已確認)

    十、不要直接將責任歸給組裝人員

    即使最後確認某個零件確實沒有安裝,也不能只寫:

    Root Cause:
    Operator Forgot Component
    (作業人員忘記零件)

    因為這仍然需要繼續問:

    為什麼一個 Safety-critical Component(安全關鍵零件)可以被遺漏,而系統沒有發現?

    可能需要檢查:

    ・Parts Control(零件管理)
    ・Assembly Sequence(組裝順序)
    ・Visual Control(目視管理)
    ・Checklist(檢查表)
    ・Independent Verification(獨立確認)
    ・Training(訓練)
    ・Traceability(追溯性)
    ・Supplier Condition(供應狀態)
    ・其他 Safety Barrier(安全防護層)

    真正有效的改善,是降低「單一人員漏裝」直接發展成事故的可能性。

    十一、Safety Barrier(安全防護層)的建立

    本案例可以建立多層防護概念。

    Barrier 1:

    Correct Part Identification
    (正確零件識別)

    確認實際使用的是指定零件。

    Barrier 2:

    Component Completeness Check
    (組件完整性確認)

    確認應有零件沒有遺漏。

    Barrier 3:

    Assembly Verification
    (組裝確認)

    確認零件安裝狀態符合要求。

    Barrier 4:

    Independent Check
    (獨立複核)

    對安全關鍵組件建立適當的第二道確認。

    Barrier 5:

    Final Inspection / Applicable Test
    (最終檢查/適用測試)

    在設備進入下一階段前,再確認是否存在異常。

    重點不是:

    「增加越多檢查越安全。」

    而是:

    每一道 Barrier 都應針對不同的 Failure Mode 提供實際防護。

    十二、事故照片應保存哪些 Evidence(證據)?

    如果未來遇到類似案例,在安全與核准程序允許的情況下,建議優先保存原始狀態資料,例如:

    ・PRD 外觀
    ・拆解前狀態
    ・拆解後組件排列
    ・缺少零件的位置
    ・實際發現的所有零件
    ・零件標示
    ・相關包裝/標籤
    ・工作紀錄
    ・檢查紀錄

    因為:

    先補裝零件
    ↓
    再拍照

    會失去非常重要的 Original Condition Evidence(原始狀態證據)。

    照片 06-02-03|正常 PRD 組件與 Missing Burst Disc 比較, 主要缺少了中間的burst disc。

    十三、Failure Mode Database(故障模式資料庫)建議紀錄

    Failure Mode ID(故障模式編號):
    FM-008

    Failure Mode(故障模式):
    PRD Missing Component
    (PRD 組件缺件)

    Component(相關部位):
    PRD Assembly
    (PRD 組件)

    Observed Condition(觀察到的異常):
    Burst Disc Missing
    (爆破片遺漏)

    Event Result(事件結果):
    Large Gas Release
    (大量氣體洩漏)

    Additional Result(其他結果):
    Personnel Evacuation
    (人員疏散)

    Detection Method(發現方式):
    Incident Investigation / Component Inspection
    (事故調查/組件檢查)

    Known Evidence(已知證據):
    Burst Disc was not present in the assembly
    (組件內未發現應有的爆破片)

    Possible Contributing Factors(可能促成因素):
    Assembly Control
    Parts Control
    Verification Process
    Traceability
    Other Factors

    (組裝管理、零件管理、確認流程、追溯性或其他因素)

    Confirmed Root Cause(已確認根本原因):
    依原始事故調查資料填寫

    Cause Status(原因確認狀態):
    CONFIRMED(已確認)
    PROBABLE(高度可能)
    POSSIBLE(可能)
    UNCONFIRMED(尚未確認)

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

    本案例可以整理成:

    PRD Present
    (PRD 外觀存在)
    ≠
    PRD Complete
    (PRD 組件完整)

    PRD Complete
    (組件完整)
    ≠
    Correct Components
    (零件規格全部正確)

    Correct Components
    (零件正確)
    ≠
    Assembly Correct
    (組裝狀態正確)

    Corrective Action
    (矯正措施)
    ≠
    Root Cause
    (根本原因)

    Missing Burst Disc
    (爆破片遺漏)
    ≠
    已經知道為什麼會遺漏

    因此完整的事故分析應繼續追查:

    「缺了什麼?」
    ↓
    「為什麼會缺?」
    ↓
    「為什麼沒有被發現?」
    ↓
    「哪一道 Safety Barrier 應該阻止它?」
    ↓
    「如何降低再次發生的可能?」

    十五、相關文章

    ・02-02|瓶閥 PRD 種類與基本原理
    ・05-03|鋼瓶瓶閥常見故障模式總覽
    ・06-01|誤拆 PRD 造成大量氣體洩漏事故案例
    ・06-03|C2H2 過充造成 PRD 洩漏事故案例
    ・06-07|瓶閥安裝後 PRD 鬆動案例
    ・06-08|NH3 Drum 過熱造成 PRD Fuse Metal 熔化洩漏案例
    ・09-02|多層安全防護
    ・09-04|異常現象、直接原因與根本原因的判斷方法
    ・09-05|鋼瓶維修經驗如何轉化為 Failure Mode Database

    注意事項

    本文為 PRD Missing Component(PRD 組件缺件)事故案例的技術經驗整理。

    不同 Cylinder(鋼瓶)、Valve(瓶閥)、PRD(壓力釋放裝置)與 Gas Service(使用氣體)的設計與適用要求可能不同。

    本文所列 2015 psig/3360 psig 與 2400 psig/4000 psig,僅代表特定公司實務中曾使用的配置案例,不應作為其他鋼瓶選擇 Burst Disc Rating(爆破片額定值)的計算公式或通用標準。

    實際 PRD 結構、零件、規格、安裝及判定,應依實際鋼瓶與瓶閥配置、製造商技術資料、適用規範及經核准的作業程序確認。

    本文不提供 PRD 拆裝、壓力釋放或事故現場處置操作程序。

    最後更新:2026-09-28

  • SiH4 鋼瓶 Neck Leak 案例|Gauge Pass 為何仍可能發生瓶頸洩漏

    05-08|SiH4 鋼瓶 Neck Leak 與瓶牙牙型異常案例

    在鋼瓶螺紋檢查中,Plug Gauge(塞規)是重要的檢查工具。

    但實務案例顯示:

    Gauge Inspection(量規檢查)沒有發現明顯異常,
    並不代表 Thread Profile(螺紋牙型)一定完全正常,
    更不代表實際組裝後一定不會發生洩漏。

    本案例為 SiH4(Silane,矽甲烷)鋼瓶發生 Neck Leak(瓶頸洩漏)的實際異常案例。

    案例中特別值得注意的是:

    瓶牙使用 Plug Gauge(塞規)檢查時,並未發現足以直接判定異常的結果;

    但後續實際 Leak Test(洩漏檢查)仍確認存在 Neck Leak,而進一步觀察瓶牙後,又發現局部 Thread Profile(螺紋牙型)存在值得注意的外觀異常。

    因此,本案例成為本資料庫中非常重要的實務案例:

    Gauge Pass(量規檢查通過)
    ≠
    Thread Profile Normal(螺紋牙型完全正常)
    ≠
    Leak Tightness Confirmed(氣密性已確認)

    一、案例背景

    氣體:

    SiH4(Silane,矽甲烷)

    異常類型:

    Neck Leak(瓶頸洩漏)

    主要檢查區域:

    Cylinder Neck Thread(鋼瓶瓶頸內螺紋)
    Valve Inlet Thread(瓶閥入口外螺紋)
    Cylinder / Valve Sealing Area(鋼瓶與瓶閥密封接合區域)

    本案例在洩漏檢查中確認瓶頸區域存在異常。

    由於洩漏位置位於 Cylinder Neck(鋼瓶瓶頸)與 Valve Inlet(瓶閥入口)的接合相關區域,因此進一步針對:

    ・Cylinder Neck Thread(鋼瓶瓶頸內螺紋)
    ・Valve Inlet Thread(瓶閥入口外螺紋)
    ・Thread Profile(螺紋牙型)
    ・Gauge Result(量規檢查結果)
    ・相關接觸與密封狀態

    進行確認。

    照片 05-08-01|SiH4 Neck Leak 異常位置

    二、第一個重要問題:Leak Location(洩漏位置)在哪裡?

    發現瓶閥附近存在洩漏時,第一步並不是立即判定:

    「瓶牙損傷。」

    而是先確認實際 Leak Location(洩漏位置)。

    因為瓶閥附近可能存在不同的 Failure Mode(故障模式),例如:

    Neck Leak(瓶頸洩漏)
    → Cylinder Neck 與 Valve Inlet 接合相關區域

    Cross Port Leak(閥內串漏)
    → Valve 關閉後,內部仍有氣體通往 Outlet(出口端)

    Outlet Connection Leak(出口接頭洩漏)
    → Valve Outlet 與 Connector(接頭)連接區域洩漏

    PRD Leak(壓力釋放裝置洩漏)
    → Pressure Relief Device,PRD(壓力釋放裝置)相關位置洩漏

    因此:

    Leak Near Valve(瓶閥附近發現洩漏)
    ≠
    Neck Leak(瓶頸洩漏)已確認

    必須先確認真正的洩漏位置。

    本案例經檢查後,異常位置集中於 Neck / Valve Inlet(瓶頸/瓶閥入口)接合相關區域,因此歸類為:

    Neck Leak(瓶頸洩漏)

    三、確認瓶牙與閥牙狀態

    確認 Neck Leak(瓶頸洩漏)後,不能只檢查 Cylinder Thread(鋼瓶螺紋)。

    因為這是一個互相配合的系統:

    Cylinder Neck Internal Thread(鋼瓶瓶頸內螺紋)
    ↕
    Valve Inlet External Thread(瓶閥入口外螺紋)

    因此需要分別確認:

    Cylinder Side(鋼瓶側):
    Cylinder Neck Thread(鋼瓶瓶頸內螺紋)

    Valve Side(瓶閥側):
    Valve Inlet Thread(瓶閥入口外螺紋)

    並觀察是否存在:

    ・Thread Damage(螺紋損傷)
    ・Missing Thread(螺紋缺損/缺牙)
    ・Deformation(變形)
    ・Material Adhesion(材料沾黏)
    ・Foreign Material(異物)
    ・Cross Thread Evidence(錯牙痕跡)
    ・Abnormal Thread Profile(異常螺紋牙型)

    四、Plug Gauge(塞規)檢查沒有發現明顯異常

    本案例的重要特徵之一,是 Cylinder Neck Thread(鋼瓶瓶頸內螺紋)使用適用的 Plug Gauge(塞規)進行檢查時,並沒有出現足以直接判定瓶牙異常的結果。

    也就是說:

    Gauge Result(量規檢查結果)
    → 未顯示明顯不合格

    如果只看到這項結果,很容易產生:

    「Gauge 沒問題,所以瓶牙應該沒問題。」

    這樣的判斷。

    但是實際上,Neck Leak(瓶頸洩漏)已經存在。

    因此這裡必須建立一個非常重要的觀念:

    Gauge Result(量規檢查結果)
    只是其中一項 Evidence(證據)

    而不是所有螺紋狀態與氣密性的最終答案。

    照片 05-08-02|Cylinder Neck Plug Gauge 檢查

    照片主要用來說明:

    Gauge Inspection(量規檢查)

    與

    Visual Inspection(目視檢查)

    屬於不同類型的檢查證據。

    五、Visual Inspection(目視檢查)發現 Thread Profile(螺紋牙型)異常

    在進一步觀察 Cylinder Neck Thread(鋼瓶瓶頸內螺紋)後,發現部分牙型外觀與正常狀態存在差異。

    這類異常不能只用:

    「Gauge 可以通過」

    就直接排除。

    因為 Plug Gauge(塞規)主要是在特定量規設計與判定方式下,提供螺紋配合狀態相關的檢查資訊。

    Visual Inspection(目視檢查)則可以觀察:

    ・局部牙型
    ・牙峰狀態
    ・牙谷狀態
    ・表面損傷
    ・材料缺失
    ・材料沾黏
    ・局部變形
    ・其他不正常外觀

    兩種檢查取得的是不同的 Evidence(證據)。

    照片 05-08-03|正常瓶牙與異常 Thread Profile 比較

    六、為什麼 Gauge Pass(量規檢查通過)仍可能存在問題?

    Gauge(量規)的作用非常重要,但必須了解它的用途與限制。

    Gauge Inspection(量規檢查)可以提供:

    螺紋尺寸與配合狀態相關的檢查資訊。

    Visual Inspection(目視檢查)可以提供:

    局部牙型、表面與外觀狀態的資訊。

    Leak Test(洩漏檢查)則可以提供:

    實際密封結果的資訊。

    因此這三種 Evidence(證據)不應互相取代。

    可以整理成:

    Visual Inspection(目視檢查)
    → 觀察 Thread Condition / Thread Profile(螺紋狀態/牙型)

    Gauge Inspection(量規檢查)
    → 確認指定量規條件下的螺紋配合狀態

    Leak Test(洩漏檢查)
    → 確認實際密封結果

    三者回答的是不同問題。

    七、Gauge Pass ≠ Thread Profile 完全正常

    假設 Gauge Result(量規檢查結果)沒有發現明顯異常,但 Visual Inspection(目視檢查)發現:

    ・局部牙型異常
    ・Missing Thread(螺紋缺損/缺牙)
    ・Thread Damage(螺紋損傷)
    ・Surface Damage(表面損傷)
    ・Deformation(變形)

    不能因為 Gauge Result 正常,就直接忽略目視檢查結果。

    因此:

    Gauge Pass(量規檢查通過)
    ≠
    Visual Pass(目視檢查合格)

    同樣地:

    Visual Pass(目視檢查合格)
    ≠
    Gauge Pass(量規檢查通過)

    兩種檢查應分別記錄。

    八、Gauge Pass ≠ Leak Tightness Confirmed

    本案例另一個非常重要的觀念是:

    Plug Gauge(塞規)不是 Leak Detector(洩漏檢測器)。

    Gauge Result(量規檢查結果)不能直接證明實際組裝後:

    「一定不會洩漏。」

    因此:

    Gauge Pass(量規檢查通過)
    ≠
    Leak Tightness Confirmed(氣密性已確認)

    反過來說:

    Leak Detected(檢測到洩漏)
    +
    Gauge Pass(量規檢查通過)

    兩者也不互相矛盾。

    這代表:

    不同檢查方法正在提供不同種類的 Evidence(證據)。

    九、不要因 Gauge 正常就否定已經確認的 Leak

    如果實際檢查已經確認:

    Neck Leak(瓶頸洩漏)

    但 Gauge Result(量規檢查結果)沒有顯示明顯異常,不應因此推論:

    「既然 Gauge 正常,所以 Leak 應該不存在。」

    較合理的邏輯是:

    Leak Confirmed(洩漏已確認)
    ↓
    Leak Location Confirmed(洩漏位置已確認)
    ↓
    Gauge Result 無明顯異常
    ↓
    代表原因仍需要繼續調查

    而不是:

    Gauge Pass
    ↓
    否定 Leak Evidence(洩漏證據)

    因此在故障分析中:

    Direct Evidence(直接證據)

    不應被另一項不同目的的檢查結果直接推翻。

    十、Thread Profile Abnormality 是 Evidence,不一定就是 Root Cause

    本案例發現:

    Neck Leak(瓶頸洩漏)
    +
    Thread Profile Abnormality(螺紋牙型異常)

    這兩項資訊之間具有技術上的關聯性。

    但是如果沒有足夠的因果證據,仍不應直接寫成:

    Root Cause(根本原因):
    Thread Profile Abnormality(螺紋牙型異常)

    較適當的紀錄方式是:

    Observed Condition(觀察到的異常):
    Neck Leak(瓶頸洩漏)

    Visual Evidence(目視證據):
    Abnormal Thread Profile(異常螺紋牙型)

    Gauge Evidence(量規檢查證據):
    量規檢查未發現明顯異常

    Possible Cause(可能原因):
    Thread / Sealing Interface Abnormality
    (螺紋/密封接合面異常)

    Cause Status(原因確認狀態):
    依實際證據判定

    這樣可以避免把「同時存在的異常」直接當成「已證明的根本原因」。

    十一、不要為了符合假設而忽略不同的檢查結果

    本案例最有價值的地方,正是不同檢查結果之間存在差異:

    Leak Test(洩漏檢查)
    → 發現異常

    Gauge Inspection(量規檢查)
    → 沒有發現明顯異常

    Visual Inspection(目視檢查)
    → 發現 Thread Profile(螺紋牙型)值得注意

    如果只保留支持自己假設的資料,就可能產生錯誤判斷。

    例如:

    先認為「一定是瓶牙問題」
    → 只看 Visual Evidence(目視證據)

    或者:

    先認為「Gauge Pass 就代表正常」
    → 忽略 Leak Evidence(洩漏證據)

    都不適合。

    較完整的方式應該是:

    保留所有 Evidence(證據)
    ↓
    比較不同檢查結果
    ↓
    分析結果為什麼不同
    ↓
    再建立 Cause Hypothesis(原因假設)

    十二、本案例的基本診斷邏輯

    可以整理為:

    發現 Leak(洩漏)
    ↓
    確認 Leak Location(洩漏位置)
    ↓
    分類為 Neck Leak(瓶頸洩漏)
    ↓
    記錄原始狀態
    ↓
    檢查 Valve Inlet Thread(瓶閥入口外螺紋)
    +
    Cylinder Neck Thread(鋼瓶瓶頸內螺紋)
    ↓
    Visual Inspection(目視檢查)
    ↓
    Applicable Gauge Inspection(適用量規檢查)
    ↓
    比較:

    Visual Evidence(目視證據)
    Gauge Evidence(量規證據)
    Leak Evidence(洩漏證據)

    ↓
    發現 Thread Profile Abnormality(螺紋牙型異常)
    ↓
    建立 Possible Cause(可能原因)
    ↓
    確認是否有足夠證據支持因果關係
    ↓
    Confirmed Cause(已確認原因)

    或

    Cause Unconfirmed(原因尚未確認)

    十三、本案例帶來的重要經驗

    這個 SiH4 Neck Leak 案例可以整理成三句非常重要的技術原則:

    Gauge Pass(量規檢查通過)
    ≠
    Thread Profile 完全正常

    Gauge Pass(量規檢查通過)
    ≠
    Leak Tightness Confirmed(氣密性已確認)

    Leak Confirmed(洩漏已確認)
    ≠
    Root Cause Confirmed(根本原因已確認)

    因此,螺紋相關異常不能只依靠單一檢查方法。

    十四、Failure Mode Database(故障模式資料庫)建議紀錄

    Failure Mode ID(故障模式編號):
    FM-001

    Failure Mode(故障模式):
    Neck Leak(瓶頸洩漏)

    Gas Service(使用氣體):
    SiH4

    Component(相關部位):
    Cylinder Neck / Valve Inlet
    (鋼瓶瓶頸/瓶閥入口)

    Observed Condition(觀察到的異常):
    Neck Area Leak Detected
    (瓶頸區域檢測到洩漏)

    Visual Evidence(目視證據):
    Abnormal Thread Profile
    (螺紋牙型異常)

    Gauge Evidence(量規證據):
    No Obvious Abnormality Detected
    (量規檢查未發現明顯異常)

    Leak Evidence(洩漏證據):
    Neck Leak Confirmed
    (瓶頸洩漏已確認)

    Possible Cause(可能原因):
    Thread / Sealing Interface Abnormality
    (螺紋/密封接合面異常)

    Confirmed Cause(已確認原因):
    依原始調查證據填寫

    Cause Status(原因確認狀態):
    CONFIRMED(已確認)
    PROBABLE(高度可能)
    POSSIBLE(可能)
    UNCONFIRMED(尚未確認)

    Related Evidence(相關證據):

    ・Leak Location Photo(洩漏位置照片)
    ・Cylinder Neck Thread Photo(鋼瓶瓶牙照片)
    ・Valve Inlet Thread Photo(瓶閥外牙照片)
    ・Plug Gauge Result(塞規檢查結果)
    ・Normal / Abnormal Thread Profile Comparison(正常/異常牙型比較)
    ・Original Leak Test Record(原始洩漏測試紀錄)

    十五、實務判斷重點

    本案例最重要的不是:

    「Gauge 不可靠。」

    而是:

    「Gauge 有它負責回答的問題。」

    同樣地:

    Visual Inspection(目視檢查)
    有它負責回答的問題。

    Leak Test(洩漏檢查)
    也有它負責回答的問題。

    因此正確的概念是:

    Visual Inspection(目視檢查)
    +
    Gauge Inspection(量規檢查)
    +
    Leak Test(洩漏檢查)
    =
    Cross-check Evidence(交叉比對證據)

    而不是:

    只選其中一項結果,
    取代其他所有檢查。

    十六、相關文章

    ・01-05|DOT 鋼瓶瓶口與螺紋
    ・04-01|瓶閥拆卸與安裝
    ・04-02|瓶閥外牙檢查
    ・04-03|鋼瓶瓶牙檢查
    ・05-01|瓶牙缺損與閥牙材料沾黏判別案例
    ・05-03|鋼瓶瓶閥常見故障模式總覽
    ・05-04|Neck Leak 瓶頸洩漏故障診斷
    ・07-02|3/4-14 NGT 瓶牙塞規
    ・09-04|異常現象、直接原因與根本原因的判斷方法
    ・09-05|鋼瓶維修經驗如何轉化為 Failure Mode Database

    注意事項

    本文整理實際 SiH4 鋼瓶 Neck Leak(瓶頸洩漏)案例的故障診斷觀念。

    公開版本以 Failure Mode(故障模式)、Inspection Evidence(檢查證據)與 Cause Analysis(原因分析)為主要內容,不公開完整鋼瓶序號、客戶資訊、公司內部紀錄或其他可識別來源的資料。

    本文所述 Gauge Inspection(量規檢查)、Visual Inspection(目視檢查)與 Leak Test(洩漏檢查)分別提供不同種類的技術證據,不能以其中單一結果取代其他檢查。

    實際鋼瓶與瓶閥的檢查、判定、維修及後續處置,仍應依適用規範、製造商技術資料及經核准的作業程序執行。

    最後更新:2026-09-28