分類: 故障診斷

  • 新人異常判斷與技術知識傳承|從 Recognize、Stop 到 Diagnose 的鋼瓶維修訓練架構

    09-06|新人異常判斷與技術知識傳承|從 Recognize 到 Diagnose 的維修訓練架構

    特殊氣體鋼瓶維修具有:

    Cylinder
    (鋼瓶)

    Valve
    (瓶閥)

    PRD
    (壓力釋放裝置)

    Thread
    (螺紋)

    Pressure
    (壓力)

    Gas Service
    (氣體服務)

    Tool
    (工具)

    Equipment
    (設備)

    Regulation
    (法規)

    以及:

    Failure Mode
    (故障模式)

    等大量專業知識。

    對剛進入維修工作的新人而言,

    不可能在短時間內:

    Remember Everything
    (記住所有事情)。

    因此新人教育最重要的目標,

    不應該是:

    「讓新人趕快可以獨立處理所有異常。」

    而應該先建立:

    Safe Judgment
    (安全判斷能力)。

    也就是:

    看到不正常的狀況時,

    知道:

    Something Is Different
    (某些地方不一樣)

    並知道:

    Do Not Guess
    (不要猜)

    Do Not Continue Automatically
    (不要自動繼續)

    Do Not Alter the Evidence Immediately
    (不要立即改變證據)

    以及:

    Ask for Help
    (尋求協助)。

    因此本篇最核心的訓練流程是:

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

    這套能力,

    比新人背下所有答案更加重要。

    一、新人第一個能力不是 Repair,而是 Recognize

    新人教育常見的問題是:

    過早把重點放在:

    How to Repair
    (如何修理)。

    但是在真正進行 Repair / Maintenance

    之前,

    更重要的是:

    Recognize Abnormality
    (辨識異常)。

    例如新人應該逐漸能辨識:

    正常 Thread

    與:

    Damaged Thread
    (受損螺紋)

    正常 PRD Position

    與:

    PRD Position Abnormality
    (PRD 位置異常)

    正常 Outlet

    與:

    Outlet Thread Damage
    (出口螺紋損傷)

    正常 Toroid / Sealing Surface

    與:

    Surface Damage
    (密封面損傷)

    正常 Status Label

    與:

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

    因此新人第一階段不是:

    「知道怎麼修。」

    而是:

    「知道這個看起來不對。」

    二、Recognize 不代表必須知道 Root Cause

    新人發現:

    PRD Position

    與正常照片不同。

    他不需要立刻知道:

    為什麼。

    只需要能說:

    「這個 PRD 的位置和正常狀態不一樣。」

    這就是有效的:

    Abnormality Recognition
    (異常辨識)。

    因此:

    Recognize Abnormality
    (辨識異常)
    ≠
    Know the Root Cause
    (知道根本原因)

    如果要求新人:

    「不知道原因就不能回報。」

    反而容易讓新人:

    Guess the Cause
    (猜原因)。

    三、新人最重要的一句話:「這個跟正常的不一樣」

    對新人而言,

    非常有價值的一句話是:

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

    這句話看起來簡單,

    實際上代表:

    新人已經開始建立:

    Normal Reference
    (正常基準)。

    沒有 Normal Reference,

    就很難辨識:

    Abnormal Condition
    (異常狀態)。

    因此教育訓練應大量建立:

    Normal vs Abnormal
    (正常 vs 異常)

    的比較資料。

    四、先教 Normal,再教 Failure

    如果新人從第一天開始

    只看:

    事故照片

    故障照片

    損傷照片,

    他可能知道:

    「這些看起來很嚴重。」

    但是仍然不知道:

    正常應該長什麼樣子。

    因此比較有效的訓練順序是:

    Normal Condition
    (正常狀態)
    ↓
    Normal Variation
    (正常差異)
    ↓
    Abnormal Condition
    (異常狀態)
    ↓
    Failure Mode
    (故障模式)

    例如:

    Normal Cylinder Neck Thread

    ↓

    Acceptable Normal Variation

    ↓

    Foreign Material

    ↓

    Material Adhesion

    ↓

    Thread Deformation

    ↓

    Missing Thread。

    如此新人才能建立:

    Visual Reference
    (視覺基準)。

    五、照片是新人教育最重要的工具之一

    特殊氣體鋼瓶維修

    很多異常:

    只靠文字很難理解。

    例如:

    Thread Damage

    Toroid Damage

    PRD Position Change

    Tool Mark

    Material Adhesion

    Weld Area Leak Location。

    如果只有文字:

    「牙型異常」

    新人可能不知道:

    到底異常在哪裡。

    因此:

    Photo-based Training
    (照片式教育)

    非常適合這類工作。

    照片最好包含:

    Overview
    (整體)

    Location
    (位置)

    Close-up
    (特寫)

    並盡可能搭配:

    Normal Example
    (正常範例)

    與:

    Abnormal Example
    (異常範例)。

    六、正常照片與異常照片應成對保存

    例如:

    PHOTO-NORMAL-PRD-001

    正常 PRD Position。

    搭配:

    FM007-PRD-ABNORMAL-001

    PRD Position Abnormality。

    或者:

    Normal Neck Thread

    對照:

    FM005 Neck Thread Damage。

    如此新人可以直接進行:

    Side-by-side Comparison
    (並排比較)。

    這比:

    單獨看一張異常照片

    更容易建立:

    Pattern Recognition
    (模式辨識)。

    七、第二步是 Stop

    新人發現:

    Something Is Abnormal

    之後,

    第二個能力不是:

    Fix It。

    而是:

    Stop。

    也就是:

    Recognize
    ↓
    Stop

    這與 09-01:

    Stop Work

    完全一致。

    例如:

    Label / Record Mismatch

    Unexpected Pressure

    PRD Position Abnormality

    Thread Damage

    Missing Component

    Unknown Cylinder Status。

    新人如果:

    不知道能不能繼續,

    不應該自行假設:

    Safe to Continue。

    因此:

    UNKNOWN
    (未知)
    ≠
    SAFE
    (安全)

    這應該成為新人訓練的基本原則。

    八、Stop Work 不應被新人理解成「我不會做」

    新人有時候不敢停止,

    因為擔心:

    「停下來是不是代表我能力不好?」

    這會造成非常危險的:

    Continue to Prove Competence
    (為證明能力而繼續作業)

    心理。

    因此教育訓練應明確建立:

    Stop Work
    (停止作業)
    ≠
    Lack of Skill
    (能力不足)

    在異常狀態下:

    知道停止,

    本身就是:

    Professional Judgment
    (專業判斷)。

    九、第三步是 Describe,而不是 Diagnose

    新人發現異常後,

    最重要的是:

    Describe What You See
    (描述看到什麼)。

    例如不應直接說:

    「這個一定鎖太緊。」

    而應該說:

    「Toroid Surface 發現局部損傷。」

    不要說:

    「活動扳手把 PRD 弄鬆了。」

    應該說:

    「PRD Position 與 Witness Mark 位置不一致。」

    不要說:

    「這支鋼瓶一定沒有清潔。」

    應該說:

    「Status Label 與 Work Record 無法對應。」

    這就是:

    Observation Language
    (觀察語言)。

    十、教新人分開 Fact 與 Assumption

    新人紀錄可以簡單分成兩欄:

    FACT
    (事實)

    與:

    ASSUMPTION / POSSIBLE CAUSE
    (推測/可能原因)。

    例如:

    FACT:

    PRD Witness Mark Position Changed.

    POSSIBLE:

    Tool Interference.

    或者:

    FACT:

    Gauge Pass.

    FACT:

    Visual Thread Damage Observed.

    而不是:

    「Gauge Pass,所以螺紋正常。」

    這種訓練可以大幅降低:

    Assumption Becomes Fact
    (推測變成事實)

    的問題。

    十一、第四步是 Collect Evidence

    新人發現異常後,

    如果安全且符合現場程序,

    應學習:

    Preserve Evidence
    (保存證據)。

    可能包括:

    Photo
    (照片)

    Gauge Result
    (量規結果)

    Pressure Reading
    (壓力讀值)

    Label
    (標籤)

    Work Record
    (作業紀錄)

    Witness Mark
    (見證標記)

    Tool Mark
    (工具痕跡)

    Component Position
    (零件位置)

    以及:

    Before / After Condition
    (作業前後狀態)。

    這些資料可能成為:

    Failure Analysis

    最重要的基礎。

    十二、不要教新人「先修好再說」

    發現異常後,

    立即:

    Clean

    Adjust

    Retighten

    Replace

    Remove

    可能會破壞:

    Original Evidence
    (原始證據)。

    因此在安全且符合核准程序的前提下:

    Recognize
    ↓
    Stop
    ↓
    Record
    ↓
    Preserve Evidence

    通常應先於:

    Modify the Condition
    (改變狀態)。

    這並不是:

    什麼都不能處理。

    而是避免:

    在還沒有紀錄之前,

    把最重要的故障證據消失掉。

    十三、第五步是 Escalate

    新人不需要:

    Solve Everything Alone
    (獨自解決所有問題)。

    當異常:

    超出:

    Training Level
    (訓練程度)

    Authorization
    (授權範圍)

    Procedure
    (程序範圍)

    或:

    Technical Knowledge
    (技術知識)

    時,

    應該:

    Escalate
    (回報/升級)。

    例如交由:

    Senior Technician
    (資深技術員)

    Supervisor
    (主管)

    Engineer
    (工程人員)

    Quality
    (品質單位)

    Safety
    (安全單位)

    或:

    Qualified External Facility
    (具資格之外部單位)

    依實際情況判斷。

    十四、Escalation 不是把問題丟給別人

    好的 Escalation

    不是只說:

    「這支有問題。」

    而是帶著:

    Structured Information
    (結構化資訊)

    回報。

    例如:

    Cylinder ID:
    已確認

    Process Step:
    Valve Inspection

    Observed Condition:
    PRD Position Abnormal

    Evidence:
    Photo + Witness Mark

    Work Status:
    Stopped

    Cause:
    Unknown

    這樣資深人員可以快速理解:

    Current Situation
    (目前狀況)。

    十五、不要要求新人在回報前一定要提出答案

    如果公司的回報文化要求:

    「你不能只說有問題,你一定要提出原因。」

    新人很容易:

    Invent a Cause
    (自行補原因)。

    因此更好的方式是允許:

    Cause = UNKNOWN。

    新人可以說:

    「我不知道原因,但這個狀態和正常不同。」

    這是一個:

    Valid Technical Statement
    (有效的技術陳述)。

    十六、第六步才是 Diagnose

    Diagnose
    (診斷)

    應建立在:

    Observation

    Evidence

    History

    Measurement

    Inspection

    Applicable Criteria

    之上。

    而不是:

    Experience Guess
    (憑經驗猜測)。

    診斷流程可以使用:

    09-04 的:

    Five-level Failure Analysis Model
    (五層故障分析模型)。

    Observed Condition
    (觀察狀態)
    ↓
    Failure Mode
    (故障模式)
    ↓
    Direct Cause
    (直接原因)
    ↓
    Contributing / System Factors
    (促成/系統因素)
    ↓
    Root Cause
    (根本原因)

    並附:

    Cause Status。

    十七、新人不應直接從現象跳到 Root Cause

    例如:

    Neck Leak
    ↓
    Over-torque

    這中間跳過了大量資訊。

    比較好的訓練方式是:

    Neck Leak Detected
    (發現瓶頸洩漏)
    ↓
    Failure Location Confirmed
    (確認故障位置)
    ↓
    Visual Inspection
    (目視檢查)
    ↓
    Applicable Gauge Result
    (適用量規結果)
    ↓
    Thread Condition
    (螺紋狀態)
    ↓
    Other Evidence
    (其他證據)
    ↓
    Cause Evaluation
    (原因評估)

    因此:

    Symptom
    (現象)
    ≠
    Root Cause

    十八、Gauge Pass 是新人最容易誤判的地方之一

    新人看到:

    PASS

    很容易認為:

    Everything Is Good。

    因此新人訓練必須建立:

    Gauge Pass
    ≠
    Thread Integrity Confirmed

    Gauge Pass
    ≠
    Leak Tightness Confirmed

    Gauge Pass
    ≠
    Cylinder Accepted

    同樣:

    No Leak
    ≠
    No Damage

    Visual Normal
    ≠
    Dimensional Condition Confirmed。

    不同檢查工具:

    回答不同問題。

    十九、教新人理解「工具能告訴你什麼」

    例如:

    Plug Gauge

    不是:

    「鋼瓶合格檢測器。」

    它是:

    針對 Cylinder Neck Internal Thread

    特定尺寸/配合特性的:

    Inspection Tool。

    Ring Gauge

    也不是:

    「瓶閥合格檢測器。」

    因此新人使用工具之前,

    應該先知道:

    What Does This Tool Check?
    (這個工具檢查什麼?)

    以及:

    What Does It Not Check?
    (它不能檢查什麼?)

    這比單純教:

    How to Use the Tool

    更重要。

    二十、Failure Mode Database 可以成為新人教材

    09-05 建立的:

    FM-001~FM-013

    可以直接轉換成:

    Training Module
    (訓練模組)。

    例如:

    FM-001
    Neck Leak

    新人教材可以包含:

    Normal Photo

    Failure Photo

    Failure Location

    Observed Condition

    Gauge Result Example

    Possible Causes

    Confirmed Case

    Cause Status

    Stop Work Point

    Evidence to Preserve

    Safety Barrier

    Lesson Learned。

    如此每個 Failure Mode

    都可以變成:

    One Training Unit
    (一個訓練單元)。

    二十一、Failure Mode 教材不要把 Possible Cause 寫成固定答案

    例如 FM-001:

    Neck Leak。

    教材可以列:

    Investigation Direction
    (調查方向):

    Thread Condition

    Alignment

    Foreign Material

    Sealing Condition

    Assembly Condition。

    但是不能教新人:

    「看到 Neck Leak,就是 Over-torque。」

    否則新人之後每一次看到:

    FM-001

    都可能:

    Anchor on One Cause
    (被單一原因錨定)。

    因此:

    Failure Mode Training
    ≠
    Memorize One Cause

    而是:

    Learn How to Investigate
    (學習如何調查)。

    二十二、Good Catch 應該成為新人教材

    教育訓練不能只有:

    Accident Case
    (事故案例)。

    也應該大量加入:

    Good Catch
    (良好攔截)。

    例如:

    FM-012
    Status Label / Record Mismatch。

    新人可以看到:

    某位維修人員:

    沒有因為標籤顯示完成

    就直接繼續。

    而是:

    發現紀錄不一致
    ↓
    Stop Work
    ↓
    Verify
    ↓
    成功攔截異常。

    這會讓新人理解:

    「提出疑問」

    不是:

    Troublemaking
    (製造麻煩)。

    而是:

    Safety Behavior
    (安全行為)。

    二十三、事故案例要教「哪一道 Barrier 失效」

    例如:

    PRD Missing Component。

    不能只讓新人記:

    「不要忘記 Burst Disc。」

    還應該分析:

    Failed Barrier
    (失效屏障)

    與:

    Required Barrier
    (需要的屏障)。

    例如:

    Part Identification

    Component Completeness

    Assembly Verification

    Independent Check

    Final Inspection。

    如此新人學到的不是:

    One Accident Story
    (一個事故故事)

    而是:

    System Thinking
    (系統思考)。

    二十四、資深人員的經驗必須從「腦中」移到資料庫

    很多維修現場真正重要的知識,

    存在:

    Senior Technician’s Memory
    (資深技術員的記憶)

    中。

    例如:

    「這種痕跡以前看過。」

    「這個位置通常不會長這樣。」

    「這個 Valve 的 PRD 要特別注意工具空間。」

    「這種牙屑看起來像瓶牙,其實可能是 Valve Material Adhesion。」

    如果沒有記錄,

    當資深人員:

    Retire
    (退休)

    Transfer
    (調職)

    Leave
    (離職)

    時,

    Knowledge Leaves with the Person
    (知識跟著人離開)。

    因此:

    Experience
    ↓
    Document
    ↓
    Classify
    ↓
    Link to Evidence
    ↓
    Store in Knowledge Base

    是技術傳承的重要流程。

    二十五、技術知識不能只有文字

    對維修工作而言,

    最有價值的 Knowledge Package

    通常包含:

    Text
    (文字)

    +

    Photo
    (照片)

    +

    Diagram
    (示意圖)

    +

    Measurement
    (量測資料)

    +

    Case
    (案例)

    +

    Decision Logic
    (判斷邏輯)。

    例如:

    FM-005
    Cylinder Neck Thread Damage。

    如果只有:

    「瓶牙缺損不可接受」

    新人可能仍然不知道:

    什麼叫缺損。

    如果加入:

    Normal Thread Photo

    Foreign Material Photo

    Material Adhesion Photo

    Actual Missing Thread Photo

    Gauge Result

    Case History,

    教育價值會大幅提高。

    二十六、建立 Normal Reference Library

    除了 Failure Mode Database,

    非常建議另外建立:

    Normal Reference Library
    (正常基準資料庫)。

    例如:

    Normal Cylinder Neck Thread

    Normal Valve Thread

    Normal Outlet

    Normal Toroid

    Normal PRD Position

    Normal Witness Mark

    Normal Neck Ring

    Normal Collar

    Normal DOT Marking

    Normal Gauge Result

    Normal Tool Condition。

    新人遇到:

    Unknown Condition

    時,

    可以先:

    Compare with Normal Reference
    (與正常基準比較)。

    這會比:

    「憑感覺判斷」

    可靠得多。

    二十七、正常照片必須標示適用範圍

    但是:

    Normal Reference

    也不能只有:

    一張照片。

    不同:

    Manufacturer

    Model

    Cylinder Specification

    Valve Design

    PRD Configuration

    可能本來就不同。

    例如:

    Neriki Valve

    與:

    Rotarex Valve

    的 PRD 周圍結構

    就可能不同。

    因此:

    Normal for Model A
    (A 型號正常)
    ≠
    Universal Normal
    (所有型號都正常如此)

    正常基準照片應盡可能記錄:

    Manufacturer

    Model

    Component

    View

    以及必要的:

    Applicable Scope
    (適用範圍)。

    二十八、新人教育應分階段授權

    新人訓練可以建立:

    Progressive Qualification
    (漸進式資格/能力確認)。

    例如:

    Level 1:

    Recognize & Stop
    (辨識與停止)

    Level 2:

    Describe & Record
    (描述與紀錄)

    Level 3:

    Use Inspection Tools
    (使用檢查工具)

    Level 4:

    Classify Failure Mode
    (分類故障模式)

    Level 5:

    Assist Diagnosis
    (協助診斷)

    Level 6:

    Independent Judgment Within Authorized Scope
    (在核准範圍內獨立判斷)

    這樣比:

    「做滿幾個月就算會了」

    更容易建立:

    Competency-based Training
    (能力導向訓練)。

    二十九、Level 1|Recognize & Stop

    第一階段新人至少應能:

    辨識明顯異常

    知道 UNKNOWN ≠ SAFE

    知道什麼時候停止

    知道不能自行改變異常狀態

    知道如何尋求協助。

    這個階段:

    不要求 Root Cause Analysis。

    核心能力是:

    Do Not Let an Unknown Abnormality Move Forward
    (不要讓未知異常繼續向後流動)。

    三十、Level 2|Describe & Record

    第二階段應能:

    使用:

    Observation Language

    描述:

    What Was Seen。

    並學會保存:

    Photo

    Location

    Label

    Gauge Result

    Record

    Before / After Condition。

    這個階段最重要的是:

    Fact
    ≠
    Assumption。

    三十一、Level 3|Use Inspection Tools

    第三階段才逐步建立:

    Plug Gauge

    Ring Gauge

    Pressure-related Inspection Equipment

    以及其他:

    Approved Inspection Tool

    的正確理解。

    不只要知道:

    How to Use

    還要知道:

    Purpose

    Limitation

    Result Interpretation。

    尤其必須理解:

    PASS
    ≠
    Everything Accepted。

    三十二、Level 4|Classify Failure Mode

    第四階段可以開始學習:

    FM-001~FM-013。

    例如看到:

    Neck Leak

    能分類:

    FM-001。

    看到:

    PRD Position Abnormal

    能分類:

    FM-007。

    看到:

    Label / Record Mismatch

    能分類:

    FM-012。

    但是:

    Classify Failure Mode
    ≠
    Determine Root Cause。

    這兩項能力應分開訓練。

    三十三、Level 5|Assist Diagnosis

    具備基本經驗後,

    新人可以開始協助:

    Evidence Collection

    Timeline Building

    Before / After Comparison

    Cause Hypothesis

    Barrier Analysis。

    但是原因仍應標示:

    Cause Status。

    例如:

    Tool Interference
    POSSIBLE

    而不是:

    Tool Interference
    CONFIRMED。

    除非證據真正支持。

    三十四、Level 6|Authorized Independent Judgment

    最後才進入:

    Independent Judgment
    (獨立判斷)。

    而且仍然必須限定:

    Within Authorized Scope
    (核准範圍內)。

    因為:

    Experience
    (經驗)

    不等於:

    Unlimited Authorization
    (無限制授權)。

    某些:

    Repair

    Requalification

    Rethreading

    Pressure-containing Body Evaluation

    DOT Special Permit Requirement

    或其他受規範事項,

    可能仍需要:

    Qualified Person / Facility
    (具資格人員/單位)

    處理。

    三十五、資深人員也需要同一套語言

    這套系統不只是:

    New Technician Training。

    資深人員也應統一使用:

    Observed Condition

    Failure Mode

    Evidence

    Direct Cause

    Root Cause

    Cause Status

    Safety Barrier

    Corrective Action

    Preventive Action。

    否則可能出現:

    同一件事情,

    A 技術員叫:

    「牙壞掉。」

    B 技術員叫:

    「牙屑。」

    C 技術員叫:

    「Cross Thread。」

    D 技術員叫:

    「Neck Leak。」

    結果資料庫無法:

    Search

    Compare

    Analyze。

    因此:

    Common Technical Language
    (共同技術語言)

    本身就是:

    Knowledge Infrastructure
    (知識基礎設施)。

    三十六、教新人問五個問題

    當新人遇到異常時,

    可以先問:

    What Is Different?
    (哪裡不一樣?)

    What Do I Actually Know?
    (我真正知道什麼?)

    What Is Still Unknown?
    (什麼還不知道?)

    Is It Safe and Authorized to Continue?
    (是否安全且在授權範圍內可以繼續?)

    What Evidence Should Be Preserved?
    (哪些證據需要保存?)

    這五個問題,

    比直接問:

    「這個要怎麼修?」

    更適合作為:

    First Response
    (第一反應)。

    三十七、再教新人問診斷問題

    進入 Diagnose 階段後,

    再問:

    What Is the Failure Mode?
    (故障模式是什麼?)

    Where Is the Failure Location?
    (故障位置在哪裡?)

    What Evidence Supports the Cause?
    (什麼證據支持原因?)

    Are There Alternative Causes?
    (是否存在其他原因?)

    What Is the Cause Status?
    (原因確認狀態為何?)

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

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

    What Prevents Recurrence?
    (如何避免再次發生?)

    這樣可以避免:

    Jump to Conclusion
    (直接跳到結論)。

    三十八、建立「不知道」的正確處理方式

    技術工作中:

    I Don’t Know
    (我不知道)

    並不可怕。

    真正危險的是:

    I Don’t Know
    ↓
    But I Will Assume
    (但我自行假設)

    因此知識庫應允許:

    UNKNOWN

    UNCONFIRMED

    NOT RECORDED

    NOT APPLICABLE。

    這些都應該是:

    Valid Data State
    (有效資料狀態)。

    而不是逼每個欄位:

    一定要有答案。

    三十九、GasPro AI 在新人教育中的角色

    未來 GasPro AI

    可以協助新人:

    搜尋:

    Normal Reference

    Failure Mode

    Past Case

    Tool Purpose

    Inspection Logic

    Regulatory Reference

    以及:

    Known Lessons Learned。

    例如新人輸入:

    「Plug Gauge 通過,但瓶牙看起來缺一角,可以繼續嗎?」

    AI 不應只回答:

    「Gauge Pass,所以正常。」

    而應從知識庫找到:

    Gauge Pass
    ≠
    Thread Integrity Confirmed

    並提醒:

    Observed Physical Damage

    不能因:

    Gauge Pass

    而被忽略。

    接著引導:

    Stop

    Describe

    Preserve Evidence

    Escalate

    依適用標準判斷。

    四十、GasPro AI 不能取代現場判斷

    AI 可以:

    Retrieve
    (檢索)

    Compare
    (比較)

    Summarize
    (整理)

    Suggest Investigation Direction
    (提供調查方向)。

    但是不能把:

    Incomplete Evidence
    (不完整證據)

    自動變成:

    Confirmed Diagnosis
    (確定診斷)。

    因此:

    AI Suggestion
    (AI 建議)
    ≠
    Authorized Technical Decision
    (核准技術判定)

    尤其涉及:

    Unknown Pressure

    Gas Release

    PRD

    Cylinder Structural Damage

    Repair

    Requalification

    Rethreading

    或:

    Regulatory Compliance

    時,

    仍需要:

    Appropriate Human / Qualified Facility
    (適當人員/具資格單位)

    進行判定。

    四十一、技術傳承的真正目標

    Knowledge Transfer
    (技術傳承)

    不是讓新人:

    Memorize the Senior Technician’s Answers
    (背下資深人員的答案)。

    真正應該傳承的是:

    How to Observe
    (如何觀察)

    How to Question
    (如何提出疑問)

    How to Stop
    (何時停止)

    How to Describe
    (如何描述)

    How to Preserve Evidence
    (如何保存證據)

    How to Use Tools
    (如何理解工具)

    How to Separate Fact from Assumption
    (如何區分事實與推測)

    How to Diagnose
    (如何診斷)

    以及:

    How to Know When You Don’t Know
    (如何知道自己還不知道答案)。

    這才是真正可以延續:

    20 Years of Experience
    (多年維修經驗)

    的方式。

    四十二、CylinderTech 的知識循環

    整個 CylinderTech

    最終可以形成:

    Maintenance Work
    (維修作業)
    ↓
    Abnormality Found
    (發現異常)
    ↓
    Stop Work
    (停止作業)
    ↓
    Evidence Collected
    (收集證據)
    ↓
    Failure Mode Classified
    (故障模式分類)
    ↓
    Cause Analyzed
    (原因分析)
    ↓
    Safety Barrier Reviewed
    (安全屏障檢討)
    ↓
    Case Stored
    (案例保存)
    ↓
    Failure Mode Database Updated
    (更新故障模式資料庫)
    ↓
    Training Material Updated
    (更新教育教材)
    ↓
    New Technician Learns
    (新人學習)
    ↓
    Future Good Catch
    (未來成功攔截新的異常)
    ↓
    Knowledge Base Continues to Grow
    (知識庫持續成長)

    這就是:

    Closed-loop Knowledge Management
    (閉環式知識管理)。

    四十三、第 09 章六篇文章的完整關係

    09-01:

    Stop Work & Good Catch

    回答:

    「發現異常後,第一步應該做什麼?」

    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:

    Technician Training & Knowledge Transfer

    回答:

    「如何把這些知識真正傳給下一位技術人員?」

    因此第 09 章實際形成:

    Recognize
    ↓
    Stop
    ↓
    Protect
    ↓
    Inspect
    ↓
    Analyze
    ↓
    Record
    ↓
    Learn
    ↓
    Teach

    四十四、本篇的重要判斷觀念

    Recognize Abnormality
    (辨識異常)
    ≠
    Know the Root Cause
    (知道根本原因)

    Stop Work
    (停止作業)
    ≠
    Lack of Skill
    (能力不足)

    UNKNOWN
    (未知)
    ≠
    SAFE
    (安全)

    Describe
    (描述)
    ≠
    Diagnose
    (診斷)

    Fact
    (事實)
    ≠
    Assumption
    (推測)

    Failure Mode
    (故障模式)
    ≠
    Root Cause
    (根本原因)

    Gauge Pass
    (量規通過)
    ≠
    Cylinder Accepted
    (鋼瓶接受)

    No Leak
    (沒有洩漏)
    ≠
    No Damage
    (沒有損傷)

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

    Experience
    (經驗)
    ≠
    Unlimited Authorization
    (無限制授權)

    AI Suggestion
    (AI 建議)
    ≠
    Authorized Technical Decision
    (核准技術判定)

    UNKNOWN
    (未知)
    ≠
    Invalid Data
    (無效資料)

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

    Training
    (教育訓練)
    ≠
    Memorizing Answers
    (背答案)

    Knowledge Transfer
    (技術傳承)
    ≠
    Passing Down Assumptions
    (把推測傳下去)

    新人最重要的基本流程:

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

    四十五、相關文章

    ・05-04~05-08|Failure Mode 故障診斷案例

    ・06-01~06-08|Incident、Near Miss 與 Good Catch 案例

    ・07-01|Ring Gauge

    ・07-02|Plug Gauge

    ・07-03|Cut Tap 與 Form Tap

    ・07-04|Pressure Test Panel

    ・07-06|Fixed-size Wrench、PRD 干涉與防錯設計

    ・08-01~08-06|DOT / 49 CFR 與相關法規架構

    ・09-01|Stop Work 與 Good Catch

    ・09-02|Multiple Safety Barriers

    ・09-03|Gauge Pass ≠ Cylinder Accepted

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

    ・09-05|Failure Mode Database

    注意事項

    本文所建立的 Recognize(辨識)、Stop(停止)、Describe(描述)、Collect Evidence(收集證據)、Escalate(回報/升級)、Diagnose(診斷)與 Learn(學習)架構,主要用於 CylinderTech 的維修教育與知識管理。

    實際 Technician Qualification(技術人員資格)、Authorization(授權)、Training Requirement(訓練要求)及 Work Scope(作業範圍),仍應依公司正式制度、設備製造商資料、適用法規及工作場所要求建立。

    本文所述 Level 1~Level 6 為知識庫建議的 Competency-based Training(能力導向訓練)架構,不代表 DOT、PHMSA 或其他主管機關的官方人員資格分級。

    Failure Mode Database 中的 FM ID、Cause Status 及 Safety Barrier Classification 亦屬 CylinderTech / GasPro AI 的內部知識管理架構。

    新人或 AI 發現 UNKNOWN Condition(未知狀態)時,不應自行推定為安全、正常或可接受。

    涉及 Unknown Pressure(未知壓力)、Gas Release(氣體釋放)、PRD Abnormality(PRD 異常)、Cylinder Structural Damage(鋼瓶結構損傷)、Repair(修理)、Requalification(再檢驗)、Rethreading(重新加工螺紋)或其他超出授權範圍的事項,應依正式安全制度與適用資格要求交由適當人員/單位判斷。

    本文為異常辨識、教育訓練及技術知識傳承架構,不提供特殊氣體鋼瓶洩壓、排放、充填、PRD 拆裝、瓶閥拆卸、重新攻牙或其他危險操作程序。

    最後更新:2026-09-30

  • Failure Mode Database|特殊氣體鋼瓶故障模式資料庫與案例知識管理

    09-05|Failure Mode Database|特殊氣體鋼瓶故障模式資料庫與案例知識管理

    特殊氣體鋼瓶維修累積多年之後,

    真正有價值的資料,

    不只是:

    「發生過多少事故。」

    更重要的是:

    What Failed?
    (什麼失效?)

    Where Did It Fail?
    (在哪裡失效?)

    How Was It Detected?
    (如何被發現?)

    What Evidence Was Available?
    (有哪些證據?)

    What Was the Cause Status?
    (原因確認到什麼程度?)

    Which Safety Barrier Failed?
    (哪一道安全屏障失效?)

    Which Barrier Caught It?
    (哪一道屏障成功攔截?)

    以及:

    Has This Failure Happened Before?
    (這種故障以前是否發生過?)

    如果每一件案例:

    各自寫一份報告,

    卻沒有共同分類,

    幾年之後就會形成:

    Many Reports
    (很多報告)

    but

    Little Structured Knowledge
    (很少結構化知識)。

    因此需要建立:

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

    它的目的不是取代:

    Incident Report
    (事故報告)

    或:

    Maintenance Record
    (維修紀錄)。

    而是把不同案例中:

    Repeated Failure Patterns
    (重複出現的故障模式)

    整理成可以:

    Search
    (搜尋)

    Compare
    (比較)

    Analyze
    (分析)

    Train
    (教育)

    以及:

    Reuse
    (重複利用)

    的:

    Maintenance Knowledge
    (維修知識)。

    一、什麼是 Failure Mode Database?

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

    是一套依:

    Failure Mode
    (故障模式)

    整理維修異常與案例的知識系統。

    例如:

    十支不同鋼瓶

    可能在不同年份、

    不同氣體服務、

    不同瓶閥、

    不同作業人員、

    不同原因下,

    都曾發生:

    Neck Leak
    (瓶頸洩漏)。

    如果只按照:

    Incident Date
    (事故日期)

    存檔,

    這十件案例可能分散在:

    十個不同資料夾。

    但是如果建立:

    FM-001
    Neck Leak

    就可以把相關案例:

    Link
    (連結)

    到同一個:

    Failure Mode。

    未來就能快速回答:

    「以前有沒有發生過 Neck Leak?」

    「當時 Gauge 結果如何?」

    「是否曾經 Gauge Pass 但仍發生 Leak?」

    「常在哪個位置發現?」

    「過去有哪些 Possible Cause?」

    「哪些原因曾經真正 Confirmed?」

    這就是:

    Failure Mode Database

    的價值。

    二、Failure Mode Database ≠ Incident Database

    Failure Mode Database

    與:

    Incident Database
    (事故資料庫)

    不能完全視為相同。

    Incident Database

    通常以:

    Event
    (事件)

    為中心。

    例如:

    2026-XX-XX
    某鋼瓶發生某事件。

    Failure Mode Database

    則以:

    Failure Pattern
    (故障模式)

    為中心。

    例如:

    FM-001
    Neck Leak。

    因此:

    One Incident
    (一件事故)

    可能包含:

    Multiple Failure Modes
    (多個故障模式)。

    反過來:

    One Failure Mode

    也可能連結:

    Many Incidents
    (很多不同事件)。

    三、Case ID 與 FM ID 必須分開

    為了避免混亂,

    建議未來資料庫使用兩種編號。

    第一種:

    Case ID
    (案例編號)

    代表:

    某一次實際事件。

    例如:

    CASE-2026-001

    第二種:

    FM ID
    (故障模式編號)

    代表:

    某一種 Failure Mode。

    例如:

    FM-001
    Neck Leak。

    所以:

    CASE-2026-001

    可能包含:

    FM-001。

    而:

    FM-001

    下面可能包含:

    CASE-2023-004

    CASE-2024-012

    CASE-2025-008

    CASE-2026-001。

    這樣才能分清楚:

    Event Identity
    (事件身分)

    與:

    Failure Classification
    (故障分類)。

    四、目前 Failure Mode Database 的 13 個核心分類

    CylinderTech 目前可以先建立:

    13 個主要 Failure Mode。

    FM-001

    Neck Leak
    (瓶頸洩漏)

    FM-002

    Cross Port Leak
    (閥內串漏)

    FM-003

    Outlet Thread Damage
    (出口螺紋損傷)

    FM-004

    Toroid Damage
    (超環面/特定密封接觸面損傷)

    FM-005

    Cylinder Neck Thread Damage / Missing Thread
    (鋼瓶瓶頸螺紋損傷/牙紋缺損)

    FM-006

    Valve Thread Material Adhesion / Foreign Material
    (瓶閥螺紋材料沾黏/異物)

    FM-007

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

    FM-008

    PRD Missing Component
    (PRD 零件缺失)

    FM-009

    PRD Leak / Abnormal Release
    (PRD 洩漏/異常釋放)

    FM-010

    Cylinder Body Weld Area Leak
    (鋼瓶本體焊縫區域洩漏)

    FM-011

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

    FM-012

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

    FM-013

    PRD Fuse Metal Activation
    (PRD Fuse Metal 動作)

    這 13 個 FM ID

    可以作為:

    Initial Database
    (初始資料庫)。

    未來如果發現:

    New Failure Pattern
    (新的故障模式),

    再新增:

    FM-014

    FM-015

    FM-016……

    而不是一開始建立大量沒有實際案例的分類。

    五、FM ID 不應因為原因改變而改變

    假設兩件:

    Neck Leak。

    第一件最後確認與:

    Thread Damage

    有關。

    第二件最後確認與:

    Assembly Alignment

    有關。

    它們的:

    Root Cause

    可能不同。

    但是 Failure Mode

    仍然都是:

    FM-001
    Neck Leak。

    因此:

    Different Cause
    (不同原因)
    ≠
    Different Failure Mode ID
    (不同故障模式編號)

    這樣才能比較:

    Same Failure Mode, Different Causes
    (相同故障模式、不同原因)。

    六、同樣原因也可能產生不同 Failure Mode

    反過來也可能發生。

    例如:

    Tool Interference
    (工具干涉)

    可能造成:

    PRD Position Abnormality

    也可能造成:

    Component Damage

    或其他異常。

    因此:

    Same Cause
    (相同原因)
    ≠
    Same Failure Mode
    (相同故障模式)

    這再次證明:

    Failure Mode

    與:

    Root Cause

    必須分開存放。

    七、Failure Mode 名稱應描述失效,不要偷偷加入原因

    例如:

    好的 Failure Mode 名稱:

    PRD Loose

    較不理想:

    PRD Loose Caused by Wrench

    因為後者已經把:

    Cause

    寫入:

    Failure Mode Name。

    如果日後證據證明:

    不是 Wrench,

    整個分類就會失去一致性。

    因此 FM 名稱應盡量:

    Cause-neutral
    (原因中立)。

    例如:

    Cylinder Body Weld Area Leak

    比:

    Manufacturing Weld Defect

    更適合當 Failure Mode。

    因為:

    Weld Area Leak

    是已觀察到的失效位置/模式。

    而:

    Original Manufacturing Defect

    需要額外證據才能確認。

    八、Failure Location 應獨立建立欄位

    除了 Failure Mode,

    還建議建立:

    Failure Location
    (故障位置)。

    例如:

    Cylinder Body
    (鋼瓶本體)

    Cylinder Neck
    (瓶頸)

    Cylinder Neck Thread
    (瓶頸螺紋)

    Valve Inlet Thread
    (瓶閥入口螺紋)

    Valve Outlet
    (瓶閥出口)

    Toroid / Sealing Surface
    (超環面/密封面)

    PRD

    Weld Area
    (焊縫區域)

    Pressure Panel

    Label / Record System。

    如此未來可以分析:

    「哪些位置最常出現異常?」

    而不是只能靠:

    Failure Mode Name

    猜位置。

    九、Observed Condition 必須保留原始描述

    資料庫不能只有:

    FM ID。

    例如:

    FM-007
    PRD Loose / Position Abnormal

    仍然需要保留:

    Observed Condition。

    例如:

    「PRD Witness Mark 與原記錄位置不一致。」

    或:

    「PRD 外側部件位置與正常狀態比較出現偏移。」

    這些:

    Original Observation
    (原始觀察)

    不能被:

    FM Classification
    (故障分類)

    取代。

    因為未來重新分析時,

    原始證據可能非常重要。

    十、Evidence 應該成為正式欄位

    每一筆案例建議建立:

    Evidence
    (證據)

    欄位。

    例如:

    Photo
    (照片)

    Gauge Result
    (量規結果)

    Leak Test Result
    (洩漏檢查結果)

    Pressure Reading
    (壓力讀值)

    Work Record
    (作業紀錄)

    Label
    (標籤)

    Witness Mark
    (見證標記)

    Tool Mark
    (工具痕跡)

    Before / After Record
    (作業前後紀錄)

    Manufacturer Information
    (製造商資料)

    以及其他:

    Physical Evidence
    (實體證據)。

    這樣可以區分:

    What We Know
    (已知)

    與:

    What We Think
    (推測)。

    十一、照片應連結案例,不要只有照片資料夾

    照片如果只有:

    IMG_9548.jpg

    IMG_9549.jpg

    幾年後很難知道:

    它們代表什麼。

    因此照片最好至少能連結:

    Case ID

    FM ID

    Component

    Photo Type。

    例如:

    FM007_CASE2026-003_PRD_Position_01.jpg

    或由照片管理資料表建立:

    Photo ID:

    PHOTO-000231

    Case ID:

    CASE-2026-003

    Failure Mode:

    FM-007

    Subject:

    PRD Position

    Photo Type:

    Before Condition。

    如此照片才會成為:

    Searchable Evidence
    (可搜尋證據)。

    十二、Master Photo 與 Web Photo 必須分開

    原始案例照片可能包含:

    Cylinder Serial Number

    Customer Name

    Internal Label

    Work Order

    Employee Information

    或其他敏感資料。

    因此建議分成:

    MASTER
    (原始證據版本)

    與:

    WEB
    (網站公開版本)。

    MASTER:

    保留原始內容,

    不得為了網站美觀破壞證據。

    WEB:

    可以:

    Crop
    (裁切)

    Redact
    (遮蔽)

    De-identify
    (去識別化)

    Add Watermark
    (加入浮水印)。

    因此:

    MASTER Evidence
    ≠
    WEB Publication Image

    兩者應建立:

    Reference Link
    (關聯)

    而不是互相取代。

    十三、Gauge Result 要與 Visual Result 分開

    延續 09-03:

    Gauge Pass ≠ Cylinder Accepted。

    資料庫不能只有:

    Inspection Result = PASS。

    應拆成:

    Gauge Result
    (量規結果)

    Visual Result
    (目視結果)

    Leak / Functional Result
    (洩漏/功能結果)

    例如:

    Gauge Result:

    PASS

    Visual Result:

    Localized Thread Profile Abnormality
    (局部牙型異常)

    Leak Result:

    Neck Leak Detected
    (發現瓶頸洩漏)

    這三個結果:

    可以同時存在。

    如果資料庫只有:

    PASS

    就會失去最重要的技術資訊。

    十四、Cause 與 Cause Status 必須是兩個欄位

    這是整個 Failure Mode Database

    非常重要的設計。

    不要只建立:

    Cause:

    Tool Interference

    應該建立:

    Cause:

    Tool Interference
    (工具干涉)

    Cause Status:

    POSSIBLE
    (可能)

    如此未來:

    GasPro AI

    才知道:

    這不是:

    Confirmed Fact
    (已確認事實)。

    因此:

    Cause
    +
    Cause Status

    必須綁在一起。

    十五、Cause Status 統一使用四級

    目前 CylinderTech 建議使用:

    CONFIRMED
    (已確認)

    PROBABLE
    (較可能)

    POSSIBLE
    (可能)

    UNCONFIRMED
    (未確認)

    例如:

    Cause:

    Tool Interference

    Cause Status:

    POSSIBLE

    或者:

    Cause:

    Temperature Sensor Malfunction

    Cause Status:

    CONFIRMED。

    這可以大幅降低:

    Assumption Becomes Fact
    (假設逐漸變成事實)

    的問題。

    十六、Cause Status 必須允許更新

    新的證據出現後,

    Cause Status

    可能改變。

    例如:

    Version 1:

    Tool Interference
    POSSIBLE

    後續找到:

    Before / After Photo

    Tool Contact Mark

    Work Sequence Evidence。

    可能更新成:

    Version 2:

    Tool Interference
    PROBABLE。

    如果再取得直接證據,

    才可能變成:

    CONFIRMED。

    因此資料庫最好保留:

    Revision History
    (修訂歷程)。

    而不是:

    直接覆蓋舊結論,

    讓人不知道:

    判斷為什麼改變。

    十七、Corrective Action 與 Preventive Action 必須分開

    Corrective Action
    (矯正措施)

    主要處理:

    Current Condition
    (目前異常)。

    Preventive Action
    (預防措施)

    則著重:

    Prevent Recurrence
    (避免再次發生)。

    例如:

    PRD Position Abnormality。

    Corrective Action:

    依核准程序處理目前異常。

    Preventive Action:

    Tool Control

    Physical Guard

    Clearance Check

    Post-work Inspection

    Training

    或其他適用措施。

    因此:

    Problem Fixed
    (問題處理完成)
    ≠
    Recurrence Prevented
    (已避免再次發生)。

    十八、Corrective Action Success 不應自動更新 Cause Status

    假設:

    更換某個零件後,

    Leak 消失。

    資料庫不能自動把:

    Cause Status

    改成:

    CONFIRMED。

    因為:

    Corrective Action Success
    ≠
    Root Cause Proof

    所以:

    Cause Status

    應由:

    Evidence

    決定,

    不是由:

    Repair Outcome
    (維修結果)

    自動決定。

    十九、加入 Safety Barrier 欄位

    延續 09-02,

    資料庫可以加入:

    Preventive Barrier
    (預防屏障)

    Detection Barrier
    (偵測屏障)

    Failed Barrier
    (失效屏障)

    Successful Barrier
    (成功屏障)。

    例如:

    FM-012
    Status Label / Record Mismatch

    Failed Barrier:

    Status Label Control
    (狀態標籤管理)

    Successful Barrier:

    Technician Record Verification
    (技術人員紀錄確認)

    如此可以分析:

    「我們最常靠哪一道屏障發現問題?」

    以及:

    「哪一道屏障最常失效?」

    二十、加入 Stop Work / Good Catch 資訊

    資料庫也可以記錄:

    Was Stop Work Initiated?
    (是否停止作業?)

    Yes / No

    Was This a Good Catch?
    (是否屬於 Good Catch?)

    Yes / No

    Was an Incident Prevented?
    (是否在事故前成功攔截?)

    如此 09-01 的概念

    就可以真正進入資料庫。

    未來可以分析:

    Good Catch Rate

    以及:

    Where Good Catches Occur
    (Good Catch 最常在哪一站發生)。

    二十一、不要把「沒有事故」當成沒有 Failure Mode

    例如:

    維修人員發現:

    Status Label / Record Mismatch

    並立即停止。

    沒有:

    Gas Release

    沒有:

    Equipment Damage

    沒有:

    Injury。

    但是:

    FM-012

    仍然存在。

    因此:

    No Incident
    (沒有事故)
    ≠
    No Failure Mode
    (沒有故障模式)

    Near Miss

    Good Catch

    Abnormal Finding

    都應具有:

    Knowledge Value
    (知識價值)。

    二十二、Severity 與 Failure Mode 應分開

    同一 Failure Mode

    可能有:

    不同嚴重程度。

    例如:

    PRD Leak

    可能只是:

    早期檢查發現的微小異常,

    也可能發展成:

    Large Gas Release
    (大量氣體釋放)。

    因此:

    Failure Mode ID

    不應直接等於:

    Severity
    (嚴重度)。

    如果未來需要,

    可以另設:

    Consequence
    (後果)

    或:

    Severity Classification
    (嚴重度分類)。

    不要因為後果不同,

    就建立:

    FM-009A

    FM-009B

    FM-009C

    除非真的存在不同:

    Failure Mechanism
    (失效機制)

    需要分類。

    二十三、Gas Service 應獨立記錄

    對特殊氣體鋼瓶而言:

    Gas Service
    (氣體服務)

    具有很高的分析價值。

    例如:

    SiH4

    PH3

    AsH3

    BF3

    DCS

    CO

    GeF4

    H2 Mixture

    C2H2

    NH3。

    但是:

    Gas Service

    不應直接寫入所有:

    Failure Mode Name。

    例如:

    SiH4 Neck Leak

    本質仍可以分類:

    FM-001 Neck Leak。

    另外記錄:

    Gas Service = SiH4。

    如此才能分析:

    「FM-001 是否在某些 Gas Service 中較常出現?」

    而不會建立大量:

    SiH4 Neck Leak

    PH3 Neck Leak

    AsH3 Neck Leak

    等重複 FM。

    二十四、Cylinder 與 Valve 資訊也應結構化

    每一案例若資料允許,

    可以建立:

    Cylinder Specification
    (鋼瓶規格)

    Cylinder Material
    (鋼瓶材質)

    Cylinder Capacity
    (鋼瓶容積)

    Valve Manufacturer
    (瓶閥製造商)

    Valve Model
    (瓶閥型號)

    Valve Material
    (瓶閥材質)

    PRD Type / Configuration
    (PRD 類型/配置)

    但是公開網站:

    不一定需要全部公開。

    尤其:

    Full Cylinder Serial Number

    Customer Information

    Internal Part Number

    Supplier-sensitive Information

    應保留在:

    Private Database
    (私人資料庫)。

    二十五、Public Database 與 Private Database 要分層

    Failure Mode Database

    最好建立:

    Two-layer Structure
    (雙層架構)。

    第一層:

    Public Knowledge
    (公開知識)

    可以包含:

    FM ID

    Failure Mode

    Generic Component

    Anonymized Case

    General Evidence

    Cause Status

    Lessons Learned。

    第二層:

    Private Evidence
    (私人證據)

    可以包含:

    Full Serial Number

    Customer

    Supplier

    Work Order

    Exact Internal Record

    Original Photo

    Employee Information

    Internal Torque Data

    Detailed Investigation

    以及其他:

    Confidential Information
    (機密資訊)。

    因此:

    Public Knowledge Base
    ≠
    Complete Internal Investigation Database

    這樣比較適合:

    CylinderTech Website

    與:

    GasPro AI

    分別使用。

    二十六、不要直接刪除「未確認案例」

    資料庫很容易出現一個問題:

    大家只想保存:

    Solved Case
    (已解決案例)。

    但是:

    Unconfirmed Case
    (未確認案例)

    同樣非常有價值。

    例如:

    五件 PRD Loose

    其中:

    一件 CONFIRMED

    兩件 PROBABLE

    兩件 UNCONFIRMED。

    這樣的資料:

    比只留下那一件 CONFIRMED

    更接近真實世界。

    因為它可以顯示:

    Evidence Quality
    (證據品質)

    以及:

    Investigation Limitation
    (調查限制)。

    二十七、資料庫不能把「未知」自動補成「正常」

    如果某案例:

    Valve Material

    沒有紀錄。

    應該寫:

    UNKNOWN

    或留作:

    Not Recorded
    (未記錄)。

    不能因為:

    「通常都是 Stainless Steel」

    就自動填入:

    Stainless Steel。

    同樣:

    PRD Type Unknown

    不能由 AI

    根據照片名稱或相似案例

    自行補成:

    Burst Disc。

    因此:

    Missing Data
    (缺少資料)
    ≠
    Normal / Typical Value
    (正常/常見值)

    這對 GasPro AI

    尤其重要。

    二十八、資料庫的基本欄位建議

    CylinderTech 的 Failure Mode Database

    可以先建立以下核心欄位:

    Case ID
    (案例編號)

    FM ID
    (故障模式編號)

    Date
    (日期)

    Process Step
    (作業階段)

    Gas Service
    (氣體服務)

    Cylinder Type / Specification
    (鋼瓶類型/規格)

    Cylinder Material
    (鋼瓶材質)

    Valve Manufacturer / Model
    (瓶閥製造商/型號)

    Failure Location
    (故障位置)

    Observed Condition
    (觀察狀態)

    Failure Mode
    (故障模式)

    Gauge Result
    (量規結果)

    Visual Result
    (目視結果)

    Leak / Functional Result
    (洩漏/功能結果)

    Evidence
    (證據)

    Photo ID
    (照片編號)

    Direct Cause
    (直接原因)

    Contributing Factor
    (促成因素)

    Root Cause
    (根本原因)

    Cause Status
    (原因確認狀態)

    Corrective Action
    (矯正措施)

    Preventive Action
    (預防措施)

    Failed Barrier
    (失效屏障)

    Successful Barrier
    (成功屏障)

    Stop Work
    (停止作業)

    Good Catch
    (良好攔截)

    Disposition
    (處置結果)

    Lesson Learned
    (經驗教訓)

    Revision
    (修訂版本)。

    不需要一開始每個欄位都有資料。

    Unknown

    本身也是有效資訊。

    二十九、FM-001~FM-013 初始索引

    目前可以先建立以下:

    Failure Mode Index
    (故障模式索引)。

    FM-001|Neck Leak
    瓶頸洩漏

    FM-002|Cross Port Leak
    閥內串漏

    FM-003|Outlet Thread Damage
    出口螺紋損傷

    FM-004|Toroid Damage
    超環面/特定密封接觸面損傷

    FM-005|Cylinder Neck Thread Damage / Missing Thread
    鋼瓶瓶頸螺紋損傷/牙紋缺損

    FM-006|Valve Thread Material Adhesion / Foreign Material
    瓶閥螺紋材料沾黏/異物

    FM-007|PRD Loose / Position Abnormal
    PRD 鬆動/位置異常

    FM-008|PRD Missing Component
    PRD 零件缺失

    FM-009|PRD Leak / Abnormal Release
    PRD 洩漏/異常釋放

    FM-010|Cylinder Body Weld Area Leak
    鋼瓶本體焊縫區域洩漏

    FM-011|Unexpected / Residual Cylinder Pressure
    非預期/殘留鋼瓶壓力

    FM-012|Status Label / Record Mismatch
    狀態標籤/紀錄不一致

    FM-013|PRD Fuse Metal Activation
    PRD Fuse Metal 動作

    三十、FM-001 範例資料結構

    以:

    FM-001 Neck Leak

    為例。

    FM ID:

    FM-001

    Failure Mode:

    Neck Leak

    Failure Location:

    Cylinder Neck / Valve Connection

    Possible Observed Conditions:

    Leak detected near neck connection

    Thread profile abnormality

    Material adhesion

    Visible thread damage

    Possible Evidence:

    Leak test result

    Plug Gauge result

    Ring Gauge result

    Visual inspection

    Thread photo

    Before / After photo

    Maintenance record

    Possible Cause:

    Thread damage

    Alignment issue

    Foreign material

    Assembly-related condition

    Other factors

    Cause Status:

    依個別 Case 分別記錄。

    注意:

    上面列出的 Possible Cause

    只是:

    Investigation Direction
    (調查方向)

    不是:

    FM-001 的固定 Root Cause。

    三十一、FM-007 範例資料結構

    FM ID:

    FM-007

    Failure Mode:

    PRD Loose / Position Abnormal

    Failure Location:

    PRD

    Possible Evidence:

    Witness Mark

    Before / After Photo

    Tool Mark

    Contact Mark

    Tool Clearance

    Fixture Position

    Work Record

    Possible Cause:

    Tool interference

    Machine / fixture contact

    Previous abnormal condition

    Assembly-related condition

    Cause Status:

    依案例證據決定。

    不能建立:

    FM-007

    Tool Interference

    因為:

    Failure Mode
    ≠
    Cause。

    三十二、FM-012 範例資料結構

    FM ID:

    FM-012

    Failure Mode:

    Status Label / Record Mismatch

    Failure Location:

    Information / Process System

    Observed Condition:

    Label status inconsistent with completion/work record

    Possible Failed Barrier:

    Status Control

    Possible Successful Barrier:

    Technician Verification

    Record Cross-check

    Possible Event Type:

    Good Catch

    Near Miss

    這個案例非常重要,

    因為它證明:

    Failure Mode Database

    不應只記錄:

    Mechanical Failure
    (機械故障)。

    Process / Information Failure
    (製程/資訊失效)

    同樣可能直接影響:

    Cylinder Maintenance Safety
    (鋼瓶維修安全)。

    三十三、FM-013 範例資料結構

    FM ID:

    FM-013

    Failure Mode:

    PRD Fuse Metal Activation

    Observed Condition:

    Fuse Metal activated following abnormal thermal exposure

    Known Case:

    NH3 Drum overheating event

    Confirmed Cause in That Specific Case:

    Temperature Sensor Malfunction

    Cause Status:

    CONFIRMED

    但是這不代表:

    所有 FM-013

    都必須具有相同 Root Cause。

    未來另一件 Fuse Metal Activation

    可能具有:

    Different Cause。

    因此:

    Case-specific Root Cause
    (個案根本原因)

    不能變成:

    Failure Mode-wide Root Cause
    (整個故障模式的固定根本原因)。

    三十四、資料庫最重要的是「可以比較」

    建立資料庫之後,

    未來可以開始回答:

    Which Failure Mode Occurs Most Often?
    (哪種故障模式最常出現?)

    Which Process Detects It?
    (在哪個流程最常被發現?)

    Which Barrier Catches It?
    (哪一道屏障最常攔截?)

    Which Cause Is Actually Confirmed?
    (哪些原因真正被確認?)

    Which Cause Is Only Assumed?
    (哪些原因只是推測?)

    Which Gas Service Is Involved?
    (涉及哪些氣體服務?)

    Which Valve / Cylinder Combination Appears Repeatedly?
    (哪些瓶閥/鋼瓶組合重複出現?)

    How Often Does Gauge Pass Despite Visual Abnormality?
    (量規通過但目視異常的情況有多少?)

    這些問題:

    單靠個別 Incident Report

    很難回答。

    Failure Mode Database

    就是把:

    Experience
    (經驗)

    轉換成:

    Data
    (資料)

    再轉換成:

    Knowledge
    (知識)。

    三十五、不要過早做統計結論

    資料庫剛開始建立時,

    案例數可能很少。

    例如:

    FM-001 有 8 件,

    FM-007 有 2 件。

    不能直接說:

    「Neck Leak 的風險是 PRD Loose 的四倍。」

    因為還需要考慮:

    Exposure
    (暴露量)

    Number of Cylinders Processed
    (處理鋼瓶數)

    Inspection Frequency
    (檢查頻率)

    Detection Method
    (偵測方式)

    Gas Service

    Valve Population

    以及:

    Reporting Bias
    (通報偏差)。

    因此:

    Case Count
    (案例數)
    ≠
    Risk Rate
    (風險率)

    這點未來如果開始做:

    Failure Trend Analysis
    (故障趨勢分析)

    尤其重要。

    三十六、資料庫的目的不是找「最常犯錯的人」

    Failure Mode Database

    如果最後變成:

    Operator Ranking
    (作業人員排名)

    很容易破壞:

    Good Catch

    與:

    Stop Work

    文化。

    資料庫真正應該尋找的是:

    Repeated Pattern
    (重複模式)

    Weak Barrier
    (薄弱屏障)

    Common Failure Location
    (常見故障位置)

    Recurring Cause
    (重複原因)

    以及:

    Improvement Opportunity
    (改善機會)。

    因此:

    Analyze the System
    (分析系統)

    比:

    Rank the People
    (排列人員)

    更有技術價值。

    三十七、GasPro AI 如何使用 Failure Mode Database

    未來 GasPro AI

    收到問題:

    「Neck Leak 有哪些可能原因?」

    不應直接回答:

    「Neck Leak 是過扭力造成。」

    正確的知識結構應該讓 AI 找到:

    FM-001
    Neck Leak

    然後分開讀取:

    Known Cases
    (已知案例)

    Confirmed Causes
    (已確認原因)

    Probable Causes
    (較可能原因)

    Possible Causes
    (可能原因)

    Unconfirmed Cases
    (未確認案例)

    最後回答:

    「過去案例曾出現哪些相關因素,以及各因素的 Cause Status。」

    這比:

    單純把所有維修經驗寫成文章

    更適合:

    AI Retrieval
    (AI 檢索)。

    三十八、GasPro AI 必須遵守的資料庫規則

    未來可以建立以下基本規則:

    Rule 1:

    Failure Mode ≠ Root Cause

    Rule 2:

    Possible ≠ Confirmed

    Rule 3:

    Unknown ≠ Normal

    Rule 4:

    Missing Data ≠ Typical Value

    Rule 5:

    Corrective Action Success ≠ Root Cause Proof

    Rule 6:

    Gauge Pass ≠ Cylinder Accepted

    Rule 7:

    One Case ≠ Universal Rule

    Rule 8:

    Company Practice ≠ DOT Requirement

    Rule 9:

    Case-specific Cause ≠ Failure Mode-wide Cause

    Rule 10:

    Original Evidence Has Priority Over AI Inference
    (原始證據優先於 AI 推論)

    這十條規則,

    可以成為:

    GasPro AI

    最重要的:

    Knowledge Guardrail
    (知識護欄)。

    三十九、本篇的重要判斷觀念

    Failure Mode
    (故障模式)
    ≠
    Incident
    (事故)

    Case ID
    (案例編號)
    ≠
    FM ID
    (故障模式編號)

    Failure Mode
    ≠
    Root Cause

    Different Cause
    ≠
    Different Failure Mode

    Same Cause
    ≠
    Same Failure Mode

    Failure Mode Name
    ≠
    Cause Conclusion

    Observed Condition
    ≠
    Cause

    Photo
    ≠
    Root Cause

    Gauge Result
    ≠
    Visual Result

    Cause
    ≠
    Cause Status

    Corrective Action
    ≠
    Preventive Action

    Corrective Action Success
    ≠
    Root Cause Proof

    No Incident
    ≠
    No Failure Mode

    Case Count
    ≠
    Risk Rate

    Missing Data
    ≠
    Normal

    UNKNOWN
    ≠
    SAFE

    One Case
    ≠
    Universal Rule

    Case-specific Root Cause
    ≠
    Failure Mode-wide Root Cause

    Public Knowledge
    ≠
    Complete Internal Evidence

    真正的 Failure Mode Database 應建立:

    Case
    (案例)
    ↓
    Observed Condition
    (觀察狀態)
    ↓
    Failure Mode
    (故障模式)
    ↓
    Evidence
    (證據)
    ↓
    Cause
    (原因)
    +
    Cause Status
    (原因確認狀態)
    ↓
    Safety Barrier
    (安全屏障)
    ↓
    Corrective / Preventive Action
    (矯正/預防措施)
    ↓
    Lesson Learned
    (經驗教訓)
    ↓
    Knowledge Base
    (知識庫)

    四十、相關文章

    ・05-04|Neck Leak 故障診斷

    ・05-05|Cross Port Leak

    ・05-06|Outlet Thread Damage

    ・05-07|Toroid Damage

    ・05-08|SiH4 Neck Leak 與 Thread Profile

    ・06-01~06-08|實際事故與 Good Catch 案例

    ・09-01|Stop Work 與 Good Catch

    ・09-02|Multiple Safety Barriers

    ・09-03|Gauge Pass ≠ Cylinder Accepted

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

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

    注意事項

    本文所建立之 FM-001~FM-013、Cause Status(原因確認狀態)、Safety Barrier(安全屏障)及 Failure Mode Database(故障模式資料庫)架構,主要用於 CylinderTech / GasPro AI 的內部技術知識管理。

    FM ID 並非 DOT、PHMSA、CGA 或瓶閥/鋼瓶製造商的官方故障分類編號。

    CONFIRMED、PROBABLE、POSSIBLE、UNCONFIRMED 亦為本知識庫使用的原因確認分類,不代表主管機關的統一事故調查分類。

    Failure Mode Database 應保存 Observed Condition(觀察狀態)與 Evidence(證據),不得因後續推測而覆蓋原始事實。

    公開 CylinderTech 網站使用案例資料時,應移除或遮蔽 Customer Information(客戶資訊)、完整 Cylinder Serial Number(鋼瓶序號)、Employee Information(人員資訊)、Internal Work Order(內部工單)及其他不適合公開的資訊。

    資料庫中的 Possible Cause(可能原因)僅作為調查方向,不得直接轉換為 Confirmed Root Cause(已確認根本原因)。

    本文為故障資料管理與技術知識架構,不提供特殊氣體鋼瓶洩壓、排放、充填、PRD 拆裝、瓶閥拆卸、螺紋重新加工或其他危險操作程序。

    最後更新:2026-09-30

  • Observed Condition ≠ Root Cause|特殊氣體鋼瓶故障模式、直接原因與根本原因判斷

    09-04|Observed Condition、Direct Cause 與 Root Cause|異常現象、故障模式與根本原因判斷

    特殊氣體鋼瓶維修中,

    最常見的診斷錯誤之一,

    不是:

    「沒有看到異常。」

    而是:

    「看到異常後,太快決定原因。」

    例如:

    發現 Neck Leak
    (瓶頸洩漏)

    就寫:

    「安裝扭力過大。」

    發現 PRD Loose
    (PRD 鬆動)

    就寫:

    「工具碰到了 PRD。」

    發現 Toroid Damage
    (超環面損傷)

    就寫:

    「Gasket 鎖太緊。」

    發現 Outlet Thread Damage
    (出口螺紋損傷)

    就寫:

    「接頭沒有對準。」

    這些原因:

    可能是對的,

    也可能只是:

    Hypothesis
    (假設)。

    因此真正的故障分析,

    第一步不是:

    Guess the Cause
    (猜原因)。

    而是先分清楚:

    What Did We Observe?
    (我們看到什麼?)

    What Failed?
    (什麼失效?)

    What Directly Produced the Failure?
    (什麼直接造成失效?)

    Why Was That Condition Allowed to Occur?
    (為什麼這個狀況會發生?)

    以及:

    How Strong Is the Evidence?
    (證據有多充分?)

    本篇建立的核心原則是:

    Observed Condition
    (觀察狀態)
    ≠
    Failure Mode
    (故障模式)
    ≠
    Direct Cause
    (直接原因)
    ≠
    Root Cause
    (根本原因)

    而且:

    Possible
    (可能)
    ≠
    Confirmed
    (已確認)

    一、Observed Condition 是「實際看到什麼」

    Observed Condition
    (觀察狀態)

    應該是:

    Evidence-based Description
    (以證據為基礎的描述)。

    例如:

    「PRD 六角部位位置與原 Witness Mark 不一致。」

    「Cylinder Neck Area 發現洩漏。」

    「Outlet Thread 局部牙紋變形。」

    「Burst Disc 不存在於應有的 Assembly 中。」

    「Pressure Panel 顯示非預期壓力。」

    「Status Label 與 Work Record 不一致。」

    這些描述的共同特點是:

    不需要先知道原因,

    也可以成立。

    因此:

    Observed Condition

    應盡可能描述:

    What Is Present
    (存在什麼)

    而不是:

    Why It Happened
    (為什麼發生)。

    二、好的異常描述不要偷偷放入原因

    例如:

    「因為工具碰撞造成 PRD 鬆動。」

    這一句同時混合了:

    Observed Condition
    +
    Cause Conclusion。

    如果目前只有:

    PRD Position Abnormality

    以及:

    附近存在 Tool Mark,

    比較精確的寫法應該是:

    Observed Condition:

    PRD Position Abnormality
    (PRD 位置異常)

    Evidence:

    Tool / Contact Mark Observed Near PRD
    (PRD 附近發現工具/接觸痕跡)

    Cause Status:

    Tool Interference Possible
    (工具干涉:可能)

    如此可以避免:

    Evidence
    (證據)

    被:

    Conclusion
    (結論)

    取代。

    三、Failure Mode 是「以什麼方式失效」

    Failure Mode
    (故障模式)

    回答的不是:

    Why?
    (為什麼?)

    而是:

    How Did the Item Fail?
    (這個項目以什麼形式失效?)

    例如:

    Neck Leak

    Cross Port Leak

    Outlet Thread Damage

    Toroid Damage

    PRD Loose

    PRD Missing Component

    PRD Leak

    Cylinder Body Weld Area Leak

    Unexpected Cylinder Pressure

    Status Label / Record Mismatch

    PRD Fuse Metal Activation。

    這些都可以建立:

    Failure Mode ID
    (故障模式編號)。

    但是:

    Failure Mode
    ≠
    Root Cause

    這是整個故障資料庫最重要的原則之一。

    四、Neck Leak 是 Failure Mode,不是 Root Cause

    例如:

    FM-001

    Neck Leak
    (瓶頸洩漏)。

    它告訴我們:

    Failure Location / Failure Behavior
    (故障位置/失效表現)

    發生在:

    Cylinder Neck / Valve Connection Area
    (鋼瓶瓶頸/瓶閥連接區域)。

    但是 Neck Leak 本身沒有回答:

    Why?

    可能需要進一步調查:

    Cylinder Neck Thread Condition
    (瓶頸螺紋狀態)

    Valve Thread Condition
    (瓶閥螺紋狀態)

    Thread Profile
    (牙型)

    Foreign Material
    (異物)

    Material Adhesion
    (材料沾黏)

    Assembly Alignment
    (組裝對準)

    Sealing Material
    (密封材料)

    Component Compatibility
    (零件相容性)

    以及其他可能因素。

    所以:

    Neck Leak
    ≠
    Over-torque

    Neck Leak
    ≠
    Cross Thread

    Neck Leak
    ≠
    Damaged Cylinder Thread

    除非:

    Evidence Supports the Conclusion
    (證據支持該結論)。

    五、Direct Cause 是什麼?

    Direct Cause
    (直接原因)

    可以理解為:

    直接導致 Failure Mode

    發生的條件或事件。

    例如:

    Outlet Thread Damage

    如果有充分證據顯示:

    Connector
    (接頭)

    在未正確對準的狀態下被強制咬合,

    則:

    Misalignment During Engagement
    (咬合時未正確對準)

    可能成為:

    Direct Cause。

    但是 Direct Cause

    仍然不一定是:

    Root Cause。

    因為下一個問題是:

    Why Was Misalignment Allowed to Continue?
    (為什麼未對準的狀態仍然繼續?)

    六、Root Cause 是更深一層的問題

    Root Cause
    (根本原因)

    通常需要回答:

    為什麼系統允許:

    Direct Cause

    發生並一路發展成:

    Failure Mode。

    例如:

    Connector Misalignment
    (接頭未對準)

    可能是 Direct Cause。

    但更深層可能需要調查:

    Tool / Fixture Design
    (工具/治具設計)

    Work Method
    (作業方法)

    Training
    (教育訓練)

    Inspection Barrier
    (檢查屏障)

    Component Identification
    (零件識別)

    Work-space Limitation
    (作業空間限制)

    或:

    Process Control
    (製程控制)。

    因此:

    Operator Action
    (作業人員動作)

    也不應自動被當成:

    Root Cause。

    七、「人員操作錯誤」通常不是分析的終點

    如果事件報告最後只有:

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

    那麼通常還可以繼續問:

    Why Was the Error Possible?
    (為什麼這個錯誤可以發生?)

    Was the Tool Appropriate?
    (工具是否適合?)

    Was the Component Easy to Misidentify?
    (零件是否容易誤認?)

    Was There a Physical Guard?
    (是否有實體防護?)

    Was There Independent Verification?
    (是否有獨立確認?)

    Was the Procedure Clear?
    (程序是否清楚?)

    Was the Work Condition Different from Normal?
    (作業條件是否不同?)

    也就是:

    Human Error
    (人為錯誤)

    往往是:

    Starting Point for Deeper Analysis
    (深入分析的起點)

    而不是:

    Automatic Root Cause
    (自動等於根本原因)。

    八、Cause Status|原因確認狀態

    CylinderTech 後續案例建議統一使用:

    Cause Status
    (原因確認狀態)。

    可以分成:

    CONFIRMED
    (已確認)

    PROBABLE
    (較可能)

    POSSIBLE
    (可能)

    UNCONFIRMED
    (未確認)。

    這套分類主要用於:

    Internal Knowledge Management
    (內部知識管理)

    與:

    Failure Analysis
    (故障分析),

    不是 DOT / PHMSA 的官方事故分類。

    九、CONFIRMED|已確認

    CONFIRMED

    代表:

    目前存在足夠證據,

    可以支持該原因判斷。

    例如 06-08:

    NH3 Drum Overheating
    (NH3 Drum 過熱)

    案例。

    已確認:

    Temperature Sensor
    (溫度偵測器)

    回傳的溫度資訊

    與實際狀態不符,

    造成控制系統:

    Continued Heating
    (持續加熱)。

    事件鏈可以建立為:

    Temperature Sensor Malfunction
    (溫度偵測器異常)
    ↓
    Incorrect Temperature Feedback
    (錯誤溫度回饋)
    ↓
    Heating Continues
    (持續加熱)
    ↓
    Drum Overheating
    (Drum 過熱)
    ↓
    PRD Fuse Metal Reaches Activation Condition
    (PRD Fuse Metal 達到動作條件)
    ↓
    Fuse Metal Activation
    (Fuse Metal 動作)
    ↓
    NH3 Gas Release
    (NH3 氣體釋放)

    在這個案例中:

    Temperature Sensor Malfunction

    具有已確認的證據支持。

    因此:

    Cause Status = CONFIRMED。

    十、PRD Fuse Metal Activation 不是 Root Cause

    同一個 NH3 Drum 案例,

    如果只看到:

    Fuse Metal Melted
    (Fuse Metal 熔化)

    就寫:

    Root Cause = PRD Failure

    會把:

    Safety Device Response
    (安全裝置反應)

    誤認成:

    Cause
    (原因)。

    實際上:

    Fuse Metal Activation

    是事件鏈後段的:

    Observed / Functional Response
    (觀察到的/功能性反應)。

    因此:

    PRD Activation
    ≠
    Root Cause

    Fuse Metal Melted
    ≠
    PRD Defect

    Replace PRD
    ≠
    Root Cause Corrected

    這是一個非常典型的:

    Failure Mode / Cause Confusion
    (故障模式與原因混淆)。

    十一、PROBABLE|較可能

    PROBABLE

    代表:

    目前證據較支持某個原因,

    但是:

    Critical Evidence
    (關鍵證據)

    仍不足以將它提升為:

    CONFIRMED。

    例如:

    某個 PRD Position Abnormality

    同時存在:

    Tool Mark

    工作位置吻合

    時間順序吻合

    且其他可能原因較少。

    這時:

    Tool Interference

    可能被評估為:

    PROBABLE。

    但是如果:

    沒有直接觀察

    沒有 Before / After Photo

    沒有明確接觸證據,

    仍不應寫成:

    CONFIRMED。

    十二、POSSIBLE|可能

    POSSIBLE

    代表:

    這個原因在技術上:

    Can Explain the Failure
    (可以解釋故障)

    但目前證據不足以表示:

    它比其他原因更有可能。

    例如:

    PRD Loose

    可能與:

    Tool Interference

    Machine Interference

    Fixture Contact

    Previous Condition

    Assembly Condition

    等因素有關。

    如果只有:

    「這個工具曾經在附近使用。」

    那麼:

    Tool Interference

    最多可能只是:

    POSSIBLE。

    因此:

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

    十三、UNCONFIRMED|未確認

    有些案例經過調查後,

    仍然無法確認:

    Why It Happened。

    這並不代表:

    調查失敗。

    正確做法可能就是:

    Cause Status = UNCONFIRMED。

    例如:

    已確認:

    Neck Leak。

    也確認:

    某區域存在:

    Thread Profile Abnormality。

    但是如果沒有足夠資料判斷:

    這個牙型異常是在:

    Manufacturing

    Previous Service

    Valve Installation

    Previous Maintenance

    或其他階段形成,

    就不應自行補上一個:

    Root Cause。

    因此:

    Unknown
    (未知)

    是可以接受的技術結論。

    Invented Certainty
    (虛構的確定性)

    才是更大的問題。

    十四、Possible ≠ Confirmed

    這一句值得在整個網站反覆使用:

    Possible
    (可能)
    ≠
    Confirmed
    (已確認)

    例如:

    Over-torque Can Cause Damage
    (過扭力可能造成損傷)

    是一個:

    Technical Possibility
    (技術可能性)。

    但:

    Damage Observed
    (發現損傷)
    ≠
    Over-torque Confirmed
    (已確認過扭力)

    除非具有:

    Torque Record
    (扭力紀錄)

    Physical Evidence
    (實體證據)

    Process Evidence
    (製程證據)

    或其他:

    Supporting Evidence
    (支持證據)。

    十五、案例:Toroid Damage

    FM-004:

    Toroid Damage
    (超環面損傷)。

    現場可能看到:

    Sealing Surface Damage
    (密封面損傷)

    以及:

    Damaged Gasket
    (墊片損傷)。

    但是:

    Damaged Gasket
    ≠
    Gasket Caused the Damage

    同樣:

    Toroid Damage
    ≠
    Over-torque Confirmed

    需要進一步確認:

    Gasket Condition

    Gasket Material

    Surface Condition

    Foreign Material

    Assembly History

    Alignment

    Applied Load

    Tool / Fixture

    以及其他證據。

    因此在原因沒有確認前,

    文章應寫:

    Possible Contributing Factor
    (可能影響因素)

    而不是:

    Confirmed Root Cause。

    十六、案例:PRD Loose

    FM-007:

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

    已觀察到:

    PRD Position Changed
    (PRD 位置改變)

    這是:

    Observed Condition。

    Failure Mode:

    PRD Loose / Position Abnormal。

    但是:

    Tool Interference

    仍需要證據。

    因此:

    Position Change
    ≠
    Tool Contact Confirmed

    Tool Mark
    ≠
    Root Cause Confirmed

    Tool Used Near PRD
    ≠
    Tool Caused PRD Movement

    Retightened Successfully
    ≠
    Root Cause Confirmed

    這個案例非常適合訓練:

    Evidence vs Assumption
    (證據與假設)

    的區別。

    十七、案例:Burst Disc Missing

    FM-008:

    PRD Missing Component
    (PRD 零件缺失)。

    如果已確認:

    Burst Disc

    在 Assembly 中缺失,

    那麼:

    Missing Burst Disc

    就是:

    Observed Condition / Failure Mode。

    但是如果直接寫:

    Root Cause = Operator Forgot
    (根本原因=作業員忘記)

    仍然太快。

    還需要問:

    Was the Correct Part Available?
    (正確零件是否可取得?)

    Was Component Verification Required?
    (是否要求零件確認?)

    Was Assembly Completeness Checked?
    (是否確認組裝完整性?)

    Was There an Independent Check?
    (是否有獨立確認?)

    Could Exterior Inspection Detect It?
    (外觀檢查能否發現?)

    Was the Work Instruction Adequate?
    (作業文件是否足夠?)

    因此:

    Missing Component
    ≠
    Operator Forgot

    即使最後證明:

    Operator Omission
    (人員遺漏)

    確實是 Direct Cause,

    仍可能存在更深層:

    System Cause
    (系統原因)。

    十八、Corrective Action ≠ Cause

    這是另一個很常見的錯誤。

    例如:

    發現洩漏後:

    Replace Gasket
    (更換墊片)

    結果:

    Leak Stops
    (洩漏停止)。

    不能因此直接推論:

    Root Cause = Bad Gasket。

    因為:

    Corrective Action

    可能同時改變了:

    Contact Condition

    Alignment

    Surface Cleanliness

    Assembly Condition

    以及其他因素。

    因此:

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

    十九、Replace Part ≠ Root Cause Corrected

    如果每次發生問題都:

    Replace the Part
    (更換零件)

    事件可能暫時消失。

    但是如果真正 Root Cause 是:

    Tool Interference

    Wrong Assembly Method

    Incorrect Part Identification

    Process Control Weakness

    Temperature Sensor Failure

    或:

    Missing Verification Barrier,

    只換零件並沒有真正解決問題。

    因此:

    Part Replaced
    (零件已更換)
    ≠
    System Cause Removed
    (系統原因已消除)

    二十、Evidence 應該先於 Conclusion

    故障分析最好建立:

    Evidence First
    (證據優先)

    的順序。

    例如:

    Evidence 1:

    PRD Witness Mark Position Changed

    Evidence 2:

    Tool Mark Observed

    Evidence 3:

    Work Record Shows Valve Installation Performed

    Evidence 4:

    No Before-work Photo Available

    然後才進行:

    Cause Evaluation
    (原因評估)。

    而不是:

    先決定:

    「一定是工具碰到。」

    再去找:

    Supporting Evidence。

    後者容易形成:

    Confirmation Bias
    (確認偏誤)。

    二十一、Before / After Evidence 非常重要

    很多維修案例最大的問題是:

    只有:

    After Condition
    (事後狀態)。

    沒有:

    Before Condition
    (事前狀態)。

    例如:

    作業後發現 PRD Position Abnormal。

    但是如果沒有:

    Before-work Photo

    Before-work Witness Mark Record

    Before-work Inspection Record,

    就很難回答:

    Was It Already Like This?
    (原本是否已經如此?)

    因此對:

    Critical Component
    (關鍵零件)

    建立適當的:

    Before / After Evidence

    可以大幅提高:

    Cause Analysis Quality
    (原因分析品質)。

    二十二、照片不是 Root Cause,但可以是 Evidence

    照片可以證明:

    At This Time, This Condition Existed
    (在這個時間點存在這個狀態)。

    例如照片可以顯示:

    Missing Component

    Thread Damage

    Tool Mark

    PRD Position

    Label

    Weld Leak Location。

    但是照片本身通常不能直接證明:

    Why It Happened。

    因此:

    Photo Evidence
    (照片證據)
    ≠
    Root Cause

    但:

    Photo Evidence
    +
    Process Record
    +
    Before / After Comparison
    +
    Physical Evidence

    可以共同建立更強的:

    Causal Evidence
    (因果證據)。

    二十三、時間順序也是重要證據

    Cause

    必須在:

    Failure

    之前存在或發生。

    因此:

    Timeline
    (時間線)

    非常重要。

    例如:

    Before Valve Installation:
    PRD Position Normal

    After Valve Installation:
    PRD Position Changed

    這比只有:

    After Photo

    具有更高的分析價值。

    但是:

    Temporal Sequence
    (時間先後)
    ≠
    Causation Confirmed
    (因果關係已確認)

    也就是:

    A Happened Before B
    ≠
    A Definitely Caused B

    仍然需要其他證據。

    二十四、Correlation ≠ Causation

    如果十次 Neck Leak

    有八次都發生在某個:

    Valve Model

    不能直接說:

    Valve Model Is the Root Cause。

    這只能表示:

    Correlation
    (相關性)

    值得進一步研究。

    還需要排除:

    Usage Frequency
    (使用頻率)

    Gas Service

    Cylinder Type

    Installation Method

    Maintenance History

    Operator

    Tool

    Batch

    Age

    以及其他:

    Confounding Factors
    (混雜因素)。

    因此:

    Correlation
    (相關)
    ≠
    Causation
    (因果)

    Failure Mode Database

    累積資料之後,

    這一點會越來越重要。

    二十五、Root Cause 可以不只一個

    實際事故不一定只有:

    One Root Cause。

    例如一件 Missing Component Event

    可能同時存在:

    Work Instruction Weakness

    No Independent Verification

    Poor Component Identification

    以及:

    Training Gap。

    因此不要強迫所有事件:

    一定只能填一個:

    Root Cause。

    更適合的方式可能是區分:

    Direct Cause
    (直接原因)

    Contributing Factor
    (促成因素)

    System Cause
    (系統原因)

    以及:

    Root Cause
    (根本原因)。

    二十六、Contributing Factor 不是 Root Cause

    Contributing Factor
    (促成因素)

    代表:

    它增加事件發生的可能性或嚴重程度,

    但不一定是主要根本原因。

    例如:

    Limited Tool Clearance
    (工具操作空間有限)

    可能增加:

    Tool Interference

    的可能性。

    但是:

    Limited Clearance

    不一定單獨足以造成:

    PRD Movement。

    因此它可能更適合標示:

    Contributing Factor。

    這比硬把所有因素都叫:

    Root Cause

    更精確。

    二十七、建立標準 Failure Analysis Record

    CylinderTech / GasPro AI

    未來可以統一使用:

    Failure Analysis Record
    (故障分析紀錄)。

    建議欄位:

    Case ID
    (案例編號)

    Failure Mode ID
    (故障模式編號)

    Observed Condition
    (觀察狀態)

    Failure Location
    (故障位置)

    Evidence
    (證據)

    Before Condition
    (事前狀態)

    After Condition
    (事後狀態)

    Direct Cause
    (直接原因)

    Contributing Factor
    (促成因素)

    Root Cause
    (根本原因)

    Cause Status
    (原因確認狀態)

    Corrective Action
    (矯正措施)

    Preventive Action
    (預防措施)

    Failed Barrier
    (失效屏障)

    Successful Barrier
    (成功屏障)

    Lesson Learned
    (經驗教訓)

    如此每一件案例

    都可以用同一套:

    Diagnostic Language
    (診斷語言)

    記錄。

    二十八、不要讓 AI 把 Possible 自動改成 Confirmed

    未來 GasPro AI

    整理案例時,

    這是一條非常重要的規則。

    原始紀錄如果寫:

    「疑似工具干涉」

    AI 不應潤飾成:

    「工具干涉造成 PRD 鬆動。」

    原始紀錄如果寫:

    「可能為過扭力」

    AI 不應整理成:

    「原因為過扭力。」

    因此 AI Knowledge Base

    應保留:

    Cause Status。

    例如:

    Cause:
    Tool Interference

    Cause Status:
    POSSIBLE

    而不是只存:

    Cause:
    Tool Interference。

    這樣可以避免:

    AI-generated Certainty
    (AI 產生不存在的確定性)。

    二十九、網站文章也應保留不確定性

    公開技術文章中,

    不需要為了讓文章看起來:

    「比較專業」

    就把所有原因寫得非常肯定。

    真正專業的寫法反而是:

    Confirmed Evidence
    (已確認證據)

    Possible Cause
    (可能原因)

    Unconfirmed Factor
    (未確認因素)

    分開。

    例如:

    「本案例已確認 PRD 發生位置異常;工具干涉屬可能原因,但現有資料不足以確認其為唯一根本原因。」

    這比:

    「作業人員使用工具撞到 PRD,導致 PRD 鬆動。」

    更符合:

    Evidence-based Failure Analysis
    (證據導向故障分析)。

    三十、UNKNOWN 是可以接受的答案

    故障分析最重要的紀律之一是:

    Do Not Invent the Missing Evidence
    (不要替不存在的證據補答案)。

    如果:

    Evidence Insufficient
    (證據不足),

    最正確的結果可能就是:

    Root Cause:
    UNCONFIRMED。

    但是仍然可以做:

    Risk Reduction
    (風險降低)。

    例如:

    雖然無法確認某次 PRD Loose

    一定由 Adjustable Wrench

    造成,

    但過去案例已顯示:

    Tool Interference

    具有實際風險。

    因此公司仍然可以:

    Restrict Tool Selection
    (限制工具)

    增加:

    Physical Guard

    Post-work Inspection

    或:

    Tool Clearance Control。

    也就是:

    Root Cause Unconfirmed
    (根本原因未確認)
    ≠
    No Preventive Action Possible
    (無法採取預防措施)

    三十一、Cause Status 可以隨新證據更新

    Cause Status

    不是永久固定。

    例如最初:

    Tool Interference = POSSIBLE

    之後取得:

    Before / After Photo

    Tool Contact Mark

    Witness Statement

    Fixture Position Evidence

    以及其他一致證據。

    可能提升為:

    PROBABLE

    甚至:

    CONFIRMED。

    反過來,

    如果新的證據否定原假設,

    也應:

    Downgrade / Reject the Hypothesis
    (降低或排除原假設)。

    因此:

    Knowledge Base

    應保留:

    Evidence History
    (證據歷程)

    而不是只保留:

    Final Sentence
    (最後一句結論)。

    三十二、建立「五層故障分析模型」

    CylinderTech 後續可以統一使用:

    Five-level Failure Analysis Model
    (五層故障分析模型)。

    Level 1:

    Observed Condition
    (觀察狀態)

    我們看到什麼?

    ↓

    Level 2:

    Failure Mode
    (故障模式)

    什麼以什麼方式失效?

    ↓

    Level 3:

    Direct Cause
    (直接原因)

    什麼直接造成失效?

    ↓

    Level 4:

    Contributing / System Factors
    (促成/系統因素)

    哪些條件讓失效更容易發生或沒有被攔截?

    ↓

    Level 5:

    Root Cause
    (根本原因)

    為什麼系統允許這個事件發生?

    然後所有 Cause

    再附上:

    Cause Status
    (原因確認狀態):

    CONFIRMED

    PROBABLE

    POSSIBLE

    UNCONFIRMED。

    三十三、本篇的重要判斷觀念

    Observed Condition
    (觀察狀態)
    ≠
    Root Cause
    (根本原因)

    Failure Mode
    (故障模式)
    ≠
    Root Cause

    Direct Cause
    (直接原因)
    ≠
    Automatically Root Cause

    Human Error
    (人為錯誤)
    ≠
    Automatic Root Cause

    Neck Leak
    ≠
    Over-torque Confirmed

    Toroid Damage
    ≠
    Over-torque Confirmed

    PRD Loose
    ≠
    Tool Interference Confirmed

    Tool Mark
    ≠
    Root Cause Confirmed

    Tool Used Nearby
    ≠
    Tool Contact Confirmed

    Missing Component
    ≠
    Operator Forgot

    Fuse Metal Activation
    ≠
    PRD Defect

    PRD Activation
    ≠
    Root Cause

    Corrective Action Success
    ≠
    Root Cause Proof

    Part Replaced
    ≠
    Root Cause Corrected

    Photo Evidence
    ≠
    Root Cause

    A Happened Before B
    ≠
    A Caused B

    Correlation
    ≠
    Causation

    Possible
    ≠
    Confirmed

    UNKNOWN
    ≠
    Failure of Analysis

    Root Cause Unconfirmed
    ≠
    No Preventive Action Possible

    真正完整的分析流程是:

    Observe
    (觀察)
    ↓
    Describe
    (描述)
    ↓
    Classify Failure Mode
    (分類故障模式)
    ↓
    Collect Evidence
    (收集證據)
    ↓
    Build Timeline
    (建立時間線)
    ↓
    Develop Hypotheses
    (建立原因假設)
    ↓
    Test Against Evidence
    (以證據驗證)
    ↓
    Assign Cause Status
    (設定原因確認狀態)
    ↓
    Determine Corrective / Preventive Action
    (決定矯正/預防措施)
    ↓
    Update Knowledge Base
    (更新知識庫)

    三十四、相關文章

    ・05-04|Neck Leak 故障診斷

    ・05-05|Cross Port Leak

    ・05-06|Outlet Thread Damage

    ・05-07|Toroid Damage

    ・05-08|SiH4 Neck Leak 與 Thread Profile

    ・06-02|PRD Burst Disc 遺漏事故

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

    ・06-08|NH3 Drum 過熱與 PRD Fuse Metal 動作事故

    ・09-01|Stop Work 與 Good Catch

    ・09-02|Multiple Safety Barriers

    ・09-03|Gauge Pass ≠ Cylinder Accepted

    ・09-05|Failure Mode Database

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

    注意事項

    本文所使用的 Observed Condition(觀察狀態)、Failure Mode(故障模式)、Direct Cause(直接原因)、Contributing Factor(促成因素)、Root Cause(根本原因)及 Cause Status(原因確認狀態),主要用於 CylinderTech / GasPro AI 的故障分析與知識管理架構。

    CONFIRMED、PROBABLE、POSSIBLE、UNCONFIRMED 為本知識庫的內部原因確認分類,不代表 DOT、PHMSA 或其他主管機關的統一官方事故分類。

    故障原因應以 Evidence(證據)為基礎。若現有資料不足以支持特定原因,應保留 Possible 或 Unconfirmed 狀態,不應為了完成報告而將假設描述成已確認事實。

    Corrective Action(矯正措施)成功不能單獨證明 Root Cause;同樣,更換零件、重新調整或檢查結果恢復正常,也不能單獨證明原始故障原因。

    涉及特殊氣體、承壓鋼瓶、PRD、Cylinder Body、Thread Damage 或其他安全關鍵異常時,實際處置仍應依公司核准程序、製造商資料、適用法規及相關專業資格要求進行。

    本文重點為 Failure Analysis(故障分析)與 Evidence Management(證據管理),不提供特殊氣體鋼瓶洩壓、排放、PRD 拆裝、瓶閥拆卸、重新攻牙或其他危險操作程序。

    最後更新:2026-09-30

  • Gauge Pass ≠ Cylinder Accepted|量規通過、螺紋完整性與鋼瓶接受判定

    09-03|Gauge Pass ≠ Cylinder Accepted|量規通過、螺紋完整性與鋼瓶接受判定

    在特殊氣體鋼瓶維修中,

    Plug Gauge
    (塞規)

    與:

    Ring Gauge
    (環規)

    是非常重要的:

    Inspection Tool
    (檢查工具)。

    但是量規最容易產生的一個錯誤觀念是:

    「Gauge Pass,所以沒有問題。」

    實際上:

    Gauge Pass
    (量規通過)

    只能回答:

    Gauge Was Able to Verify Its Intended Inspection Characteristic
    (量規所設計檢查的特定特性是否符合相應判定)。

    它不能單獨回答:

    Thread Material 是否完整?

    Thread Profile 是否完全正常?

    是否存在局部損傷?

    是否存在 Foreign Material?

    是否具有 Leak Tightness?

    Valve 與 Cylinder 是否正確匹配?

    整支 Cylinder 是否可以接受?

    因此本篇最重要的觀念是:

    Gauge Pass
    ≠
    Thread Integrity Confirmed
    ≠
    Leak Tightness Confirmed
    ≠
    Cylinder Accepted

    這四個判斷層級必須分開。

    一、Gauge 是 Measurement / Inspection Tool

    Gauge
    (量規)

    首先是一種:

    Measurement / Inspection Tool
    (量測/檢查工具)。

    它有:

    Specific Purpose
    (特定用途)。

    例如:

    Plug Gauge
    (塞規)

    主要用於:

    Internal Thread
    (內螺紋)

    的特定尺寸/配合狀態檢查。

    Ring Gauge
    (環規)

    則用於:

    External Thread
    (外螺紋)

    的特定尺寸/配合狀態檢查。

    因此:

    Plug Gauge
    →
    Cylinder Neck Internal Thread
    (鋼瓶瓶頸內螺紋)

    Ring Gauge
    →
    Valve External Thread
    (瓶閥外螺紋)

    兩者:

    Inspection Target
    (檢查對象)

    不同。

    二、Plug Gauge 與 Ring Gauge 不能互相替代

    本維修現場的基本判斷邏輯是:

    Cylinder Neck Internal Thread
    (鋼瓶瓶頸內螺紋)
    →
    Plug Gauge
    (塞規)

    Valve Inlet External Thread
    (瓶閥入口外螺紋)
    →
    Ring Gauge
    (環規)

    因此:

    Plug Gauge Pass
    (塞規通過)

    不能證明:

    Valve External Thread
    (瓶閥外螺紋)

    正常。

    同樣:

    Ring Gauge Pass
    (環規通過)

    不能證明:

    Cylinder Neck Internal Thread
    (鋼瓶瓶頸內螺紋)

    正常。

    這兩個:

    Mating Components
    (配合零件)

    需要分別確認。

    三、Gauge Pass 到底代表什麼?

    最安全的說法不是:

    「螺紋完全正常。」

    而是:

    在該量規的:

    Applicable Inspection Characteristic
    (適用檢查特性)

    範圍內,

    沒有顯示相應的尺寸/配合異常。

    因此:

    Gauge Pass

    應被理解為:

    One Inspection Result
    (一項檢查結果)

    而不是:

    Final Acceptance
    (最終接受判定)。

    這個差異非常重要。

    四、Gauge Pass ≠ Thread Integrity Confirmed

    Thread Integrity
    (螺紋完整性)

    包含的不只是:

    Gauge Fit
    (量規配合)。

    還可能包含:

    Thread Material
    (螺紋材料)

    Thread Form / Profile
    (牙型/輪廓)

    Local Damage
    (局部損傷)

    Missing Thread
    (牙紋缺損)

    Deformation
    (變形)

    Material Adhesion
    (材料沾黏)

    Foreign Material
    (異物)

    Corrosion
    (腐蝕)

    以及其他:

    Surface Abnormality
    (表面異常)。

    量規不一定能完整辨識上述所有問題。

    因此:

    Gauge Pass
    ≠
    No Thread Damage

    五、實際案例:SiH4 Neck Leak

    05-08 的:

    SiH4 Cylinder Neck Leak
    (SiH4 鋼瓶瓶頸洩漏)

    就是這個觀念非常重要的實際案例。

    當時:

    Gauge Inspection
    (量規檢查)

    沒有顯示明顯異常。

    但是後續:

    Visual Inspection
    (目視檢查)

    仍發現:

    Thread Profile Abnormality
    (螺紋牙型異常)。

    因此這個案例證明:

    Gauge Pass

    與:

    Thread Profile Normal

    不是完全相同的判斷。

    也就是:

    Gauge Pass
    ↓
    Does Not End the Inspection
    (不能因此結束所有檢查)

    仍需要:

    Visual Condition
    (目視狀態)

    以及其他適用檢查結果

    共同判斷。

    六、為什麼局部損傷可能無法由 Gauge 單獨反映?

    Gauge

    與螺紋接觸時,

    主要確認的是:

    特定:

    Dimensional / Fit Relationship
    (尺寸/配合關係)。

    但是某些:

    Localized Damage
    (局部損傷)

    可能沒有大到足以:

    Prevent Gauge Engagement
    (阻止量規正常配合)。

    例如:

    局部牙頂損傷

    局部材料缺失

    單一區域變形

    局部表面異常。

    因此:

    Gauge Can Enter
    (量規可以進入)
    ≠
    Every Thread Surface Is Intact
    (每一處螺紋表面都完整)

    這也是:

    Visual Inspection

    仍然不可缺少的原因。

    七、Visual Inspection 與 Gauge Inspection 是不同屏障

    延續 09-02:

    Multiple Safety Barriers
    (多層安全屏障)

    的觀念。

    Gauge Inspection

    與:

    Visual Inspection

    應該視為:

    Different Detection Barriers
    (不同偵測屏障)。

    Gauge 可以發現:

    某些尺寸/配合異常。

    Visual Inspection

    則可以發現:

    Material Loss
    (材料缺失)

    Damage
    (損傷)

    Adhesion
    (沾黏)

    Foreign Material
    (異物)

    Corrosion
    (腐蝕)

    以及其他:

    Surface Condition
    (表面狀態)。

    因此:

    Gauge Inspection
    +
    Visual Inspection

    比:

    Gauge Inspection Only

    具有更完整的資訊。

    八、Visual Pass 也不能反過來取代 Gauge

    同樣的邏輯也適用於:

    Visual Inspection。

    不能因為:

    「看起來很好。」

    就省略:

    Applicable Gauge Inspection
    (適用量規檢查)。

    因為某些:

    Dimensional Abnormality
    (尺寸異常)

    可能不是肉眼容易判斷。

    所以:

    Looks Normal
    (外觀看起來正常)
    ≠
    Dimensional Condition Confirmed
    (尺寸狀態已確認)

    真正合理的方式是:

    Visual Inspection
    +
    Applicable Gauge Inspection

    而不是:

    二選一。

    九、Gauge Pass ≠ Leak Tightness Confirmed

    這是本篇第二個非常重要的觀念。

    Gauge

    不是:

    Leak Detector
    (洩漏檢測器)。

    即使:

    Cylinder Neck Thread

    與:

    Valve Thread

    各自通過相應量規,

    也不能單憑這件事證明:

    Assembled Connection
    (組裝後連接)

    一定:

    Leak-tight
    (無洩漏)。

    因為密封結果還可能受到:

    Thread Engagement
    (螺紋咬合)

    Component Condition
    (零件狀態)

    Sealing Material
    (密封材料)

    Assembly Condition
    (組裝狀態)

    Mating Relationship
    (配合關係)

    以及其他因素影響。

    因此:

    Gauge Pass
    ≠
    Leak Test Pass

    十、Leak Test Pass 也不能反過來證明 Thread 完整

    反方向也一樣。

    假設:

    Leak Check
    (洩漏檢查)

    結果沒有發現洩漏。

    不能因此直接說:

    Thread Profile Is Normal
    (螺紋牙型正常)

    或:

    No Thread Damage Exists
    (不存在螺紋損傷)。

    因為:

    Leak Tightness

    與:

    Thread Integrity

    雖然相關,

    但不是同一個:

    Inspection Characteristic
    (檢查特性)。

    因此:

    No Leak
    ≠
    No Thread Damage

    十一、No Leak Today ≠ No Future Risk

    這也是實務上需要避免的推論。

    某個:

    Damaged Thread
    (受損螺紋)

    可能在目前組裝狀態:

    沒有明顯洩漏。

    但是:

    No Leak at Current Check
    (目前檢查沒有洩漏)

    不能自動證明:

    Damaged Condition Is Acceptable
    (受損狀態可接受)。

    尤其當已經觀察到:

    Actual Material Loss
    (實際材料缺失)

    或:

    Abnormal Thread Profile
    (異常牙型)

    時,

    不能用:

    「現在沒漏。」

    取代:

    Condition Evaluation
    (狀態判定)。

    十二、瓶牙缺損不能只靠 Gauge 結果判斷

    本維修現場已建立一項重要原則:

    如果:

    Cylinder Neck Thread
    (鋼瓶瓶頸螺紋)

    出現實際:

    Thread Material Loss
    (牙紋材料缺失)

    即使:

    Plug Gauge

    仍可通過,

    也不能只用:

    Gauge Pass

    把已觀察到的損傷忽略。

    因此:

    Visible Thread Damage
    (可見螺紋損傷)

    不能被:

    Gauge Pass

    「取消」。

    換句話說:

    Physical Evidence
    (實體證據)

    不會因為另一項檢查結果正常

    就自動消失。

    十三、Foreign Material 與 Missing Thread 必須區分

    Thread Inspection

    中非常重要的一項工作,

    就是區分:

    Foreign Material
    (異物)

    Material Adhesion
    (材料沾黏)

    與:

    Missing Thread
    (牙紋缺損)。

    例如:

    Valve Thread Material
    (瓶閥牙屑)

    可能附著於:

    Cylinder Neck Thread。

    這種狀態:

    看起來可能像螺紋損傷,

    但實際上可能是:

    Foreign Material / Adhesion。

    相反地:

    真正的 Thread Material Loss

    也不能被誤認為:

    「只是髒了。」

    因此:

    Abnormal Appearance
    ↓
    Identify the Condition
    ↓
    Do Not Assume the Cause

    十四、Cut Tap / Form Tap 不是「讓 Gauge Pass」的工具

    這一點必須延續 07-03 與 08-04 的原則。

    Cut Tap

    Form Tap

    不能被理解為:

    「Gauge 不過時,就加工到它會過。」

    這會把:

    Inspection Result
    (檢查結果)

    錯誤轉換成:

    Repair Target
    (修理目標)。

    也就是:

    Gauge Fail
    ↓
    Machine Until Gauge Pass

    這不是本網站要建立的判斷方式。

    正確概念應該是:

    Abnormal Gauge Result
    (量規結果異常)
    ↓
    Stop
    (停止)
    ↓
    Inspect
    (檢查)
    ↓
    Identify Condition
    (辨識狀態)
    ↓
    Determine Cause Status
    (確認原因狀態)
    ↓
    Determine Applicable Action
    (判定適用處置)

    十五、Gauge Pass After Cleaning ≠ Root Cause Confirmed

    假設:

    Gauge Initially Abnormal
    (最初量規異常)

    之後發現:

    Foreign Material

    並依適用程序處理。

    後續:

    Gauge Pass。

    這可以證明:

    目前量規檢查結果發生改變。

    但是不能只靠:

    Before / After Gauge Result

    就證明:

    Foreign Material 最初來自哪裡。

    因此:

    Gauge Pass After Cleaning
    (清潔後量規通過)
    ≠
    Root Cause Confirmed
    (根本原因已確認)

    這仍然符合:

    Corrective Action Success
    ≠
    Root Cause Proof

    的原則。

    十六、Ring Gauge Pass 也有相同限制

    Valve External Thread

    使用:

    Ring Gauge

    時,

    也不能因為:

    Ring Gauge Pass

    就直接判斷:

    Valve Is Fully Acceptable
    (瓶閥完全可接受)。

    仍然可能需要確認:

    Thread Surface
    (螺紋表面)

    Thread Damage
    (螺紋損傷)

    Material Adhesion
    (材料沾黏)

    Valve Body
    (閥體)

    Outlet
    (出口)

    PRD

    Toroid / Sealing Surface
    (超環面/密封面)

    以及其他適用項目。

    因此:

    Ring Gauge Pass
    ≠
    Valve Accepted

    十七、Valve Thread Pass + Cylinder Thread Pass 仍不是最終答案

    即使:

    Valve Ring Gauge Pass

    而且:

    Cylinder Plug Gauge Pass,

    也只能得到:

    兩個分別的量規結果。

    不能直接寫成:

    Valve-to-Cylinder Connection Accepted
    (瓶閥與鋼瓶連接已接受)。

    因為還有:

    Component Compatibility
    (零件相容性)

    Thread Engagement
    (螺紋咬合)

    Assembly Condition
    (組裝狀態)

    Sealing Condition
    (密封狀態)

    以及:

    Applicable Final Verification
    (適用最終確認)。

    因此:

    Valve Gauge Pass
    +
    Cylinder Gauge Pass
    ≠
    Complete Connection Acceptance

    十八、Measurement Result 與 Acceptance Decision 不同

    這是技術判斷中非常重要的層級概念。

    Measurement Result
    (量測結果)

    回答:

    「測到了什麼?」

    Inspection Finding
    (檢查發現)

    回答:

    「看到了什麼?」

    Acceptance Criteria
    (接受標準)

    回答:

    「什麼條件可以接受?」

    Acceptance Decision
    (接受判定)

    才回答:

    「這個零件/鋼瓶是否可以接受?」

    因此流程應該是:

    Measurement
    (量測)
    +
    Inspection
    (檢查)
    ↓
    Compare with Applicable Criteria
    (與適用標準比較)
    ↓
    Acceptance Decision
    (接受判定)

    而不是:

    One Measurement Pass
    ↓
    Everything Accepted

    十九、Cylinder Acceptance 是多項資訊的結果

    一支 Cylinder

    是否可以接受,

    通常不會只由:

    One Gauge

    決定。

    依實際工作範圍,

    可能需要考慮:

    Cylinder Identification
    (鋼瓶識別)

    Specification / Special Permit
    (規格/特殊許可)

    Requalification Status
    (再檢驗狀態)

    Cylinder Body Condition
    (鋼瓶本體狀態)

    Neck Thread Condition
    (瓶頸螺紋狀態)

    Valve Condition
    (瓶閥狀態)

    PRD Condition
    (PRD 狀態)

    Applicable Leak Verification
    (適用洩漏確認)

    以及:

    Other Applicable Requirements
    (其他適用要求)。

    因此:

    Cylinder Acceptance

    是一個:

    Integrated Decision
    (整合判定)。

    二十、Requalification Valid ≠ Cylinder Accepted

    這個概念與 08 章也有直接關係。

    即使鋼瓶的:

    Requalification Date
    (再檢驗日期)

    仍然有效,

    也不能代表:

    目前一定沒有:

    Damage
    (損傷)

    Leak
    (洩漏)

    Thread Abnormality
    (螺紋異常)

    Valve Problem
    (瓶閥問題)

    或:

    PRD Abnormality
    (PRD 異常)。

    因此:

    Requalification Valid
    ≠
    Current Condition Acceptable

    法規資格狀態

    與:

    目前實體狀態

    必須分開判斷。

    二十一、同樣地,Cylinder Accepted ≠ Every Component Is New

    Acceptance

    也不是要求:

    所有零件看起來像新品。

    真正需要判斷的是:

    Applicable Acceptance Criteria
    (適用接受標準)。

    因此不能把:

    Cosmetic Appearance
    (外觀美觀程度)

    直接等同:

    Safety Condition
    (安全狀態)。

    例如:

    Surface Discoloration
    (表面變色)

    Scratch
    (刮痕)

    Tool Mark
    (工具痕跡)

    Corrosion

    Deformation

    Material Loss

    在技術意義上可能完全不同。

    所以:

    Looks Old
    (看起來舊)
    ≠
    Automatically Reject

    同樣:

    Looks New
    (看起來新)
    ≠
    Automatically Accept

    二十二、Gauge Result 必須可以追溯

    量規結果如果要具有技術價值,

    至少需要知道:

    Which Gauge?
    (哪一個量規?)

    What Was Inspected?
    (檢查什麼?)

    Which Component?
    (哪一個零件?)

    What Was the Result?
    (結果如何?)

    Was Any Abnormality Observed?
    (是否發現其他異常?)

    必要時還要能追溯:

    Gauge Identification
    (量規識別)

    以及適用的:

    Calibration / Verification Status
    (校正/確認狀態)。

    否則只記:

    PASS

    資訊價值非常有限。

    二十三、PASS / FAIL 之外還需要 Observation

    如果檢查表只有:

    PASS

    FAIL

    可能會失去大量資訊。

    例如:

    Gauge = PASS

    但是:

    Visual = Local Thread Damage Observed

    如果只記:

    PASS

    下一位人員可能誤以為:

    Everything Normal。

    因此建議:

    Gauge Result
    (量規結果)

    與:

    Visual Observation
    (目視觀察)

    分開記錄。

    例如:

    Gauge Result:PASS

    Visual Observation:
    Localized Thread Profile Abnormality Observed
    (發現局部牙型異常)

    這比單純:

    PASS

    更接近實際狀態。

    二十四、異常結果不要被平均掉

    假設有:

    五項檢查。

    四項 PASS

    一項發現:

    Critical Abnormality
    (重要異常)。

    不能用:

    「五項裡面四項都正常。」

    來推論:

    Overall Condition Is Probably Fine
    (整體應該沒問題)。

    安全判斷不是:

    Average Score
    (平均分數)。

    因此:

    Multiple Pass Results
    (多項通過)
    ≠
    One Critical Abnormality Can Be Ignored
    (一項重要異常可以忽略)

    只要某項異常:

    需要停止或進一步確認,

    就應依:

    Applicable Criteria

    處理。

    二十五、不同檢查結果發生衝突時怎麼辦?

    例如:

    Gauge = PASS

    Visual = Abnormal

    或:

    Gauge = PASS

    Leak Check = Leak Detected

    這時不能選:

    「比較喜歡的結果。」

    而應該認為:

    Inspection Results Conflict
    (檢查結果存在衝突)。

    接下來:

    Stop Acceptance Decision
    (暫停接受判定)
    ↓
    Preserve Evidence
    (保存證據)
    ↓
    Verify Inspection Method
    (確認檢查方式)
    ↓
    Identify Failure Mode
    (辨識故障模式)
    ↓
    Apply Applicable Criteria
    (套用適用標準)
    ↓
    Determine Disposition
    (決定處置)

    也就是:

    Conflicting Evidence
    (證據衝突)
    ≠
    Choose the PASS Result
    (選擇 PASS 的結果)

    二十六、Gauge 是 Safety Barrier,但不是 Final Authority

    延續 09-02 的觀念:

    Gauge Inspection

    是一道:

    Detection Barrier
    (偵測屏障)。

    它非常重要。

    但它的功能是:

    提供特定檢查資訊。

    不是:

    Final Authority for the Entire Cylinder
    (整支鋼瓶的唯一最終判定者)。

    因此:

    Gauge Is Important
    (量規很重要)

    與:

    Gauge Is Not Enough by Itself
    (量規單獨不足)

    可以同時成立。

    這兩句並不矛盾。

    二十七、建立「四層判斷」會最清楚

    CylinderTech 後續可以統一使用:

    Four-level Decision Model
    (四層判斷模型)。

    Level 1:

    Gauge Result
    (量規結果)

    ↓

    Level 2:

    Thread Condition
    (螺紋狀態)

    ↓

    Level 3:

    Leak / Functional Condition
    (洩漏/功能狀態)

    ↓

    Level 4:

    Component / Cylinder Acceptance
    (零件/鋼瓶接受判定)

    這四層不能互相取代。

    最簡單的表示方式就是:

    Gauge Pass
    ↓
    Does Not Automatically Prove
    ↓
    Thread Integrity
    ↓
    Does Not Automatically Prove
    ↓
    Leak Tightness
    ↓
    Does Not Automatically Prove
    ↓
    Cylinder Acceptance

    二十八、Failure Mode Database 也應分開記錄

    未來 09-05:

    Failure Mode Database

    不應只有:

    PASS / FAIL。

    例如 FM-001:

    Neck Leak。

    可以分別記錄:

    Gauge Result
    (量規結果)

    Visual Condition
    (目視狀態)

    Leak Condition
    (洩漏狀態)

    Failure Location
    (故障位置)

    Failure Mode
    (故障模式)

    Cause Status
    (原因確認狀態)

    Disposition
    (處置結果)。

    如此未來才可能分析:

    「有多少 Neck Leak 案例其實 Gauge Pass?」

    「有多少 Thread Damage 是由 Visual Inspection 發現?」

    「哪些 Failure Mode 無法只靠 Gauge 發現?」

    這些才是真正有價值的:

    Maintenance Knowledge
    (維修知識)。

    二十九、照片也是 Thread Condition 的重要紀錄

    對 Thread Abnormality

    而言,

    照片可以保存:

    Original Condition
    (原始狀態)

    Damage Location
    (損傷位置)

    Thread Profile
    (牙型)

    Foreign Material
    (異物)

    Material Adhesion
    (材料沾黏)

    Missing Thread
    (牙紋缺損)

    以及:

    Before / After Condition
    (處理前後狀態)。

    尤其:

    Gauge Pass + Visual Abnormality

    的案例,

    非常適合作為:

    Training Example
    (教育案例)。

    它可以直接讓新人理解:

    「量規通過」和「看不到任何問題」

    不是同一句話。

    三十、新人最需要記住的一句話

    如果要把整篇濃縮成一句現場判斷:

    「量規告訴你量規能檢查到的事情,不會替你完成整支鋼瓶的判定。」

    因此新人看到:

    PASS

    不能停止思考。

    而應繼續問:

    What Was Tested?
    (測了什麼?)

    What Was Not Tested?
    (什麼沒有被測到?)

    What Else Was Observed?
    (還看到什麼?)

    Are There Conflicting Results?
    (是否存在衝突結果?)

    What Criteria Determine Acceptance?
    (真正的接受標準是什麼?)

    三十一、本篇的重要判斷觀念

    Gauge Pass
    (量規通過)
    ≠
    Thread Integrity Confirmed
    (螺紋完整性已確認)

    Gauge Pass
    ≠
    No Thread Damage
    (沒有螺紋損傷)

    Plug Gauge Pass
    (塞規通過)
    ≠
    Valve Thread Pass
    (瓶閥外螺紋通過)

    Ring Gauge Pass
    (環規通過)
    ≠
    Cylinder Neck Thread Pass
    (瓶頸內螺紋通過)

    Gauge Pass
    ≠
    Leak Tightness Confirmed
    (密封性已確認)

    No Leak
    (沒有洩漏)
    ≠
    No Thread Damage
    (沒有螺紋損傷)

    Visual Pass
    (目視正常)
    ≠
    Dimensional Condition Confirmed
    (尺寸狀態已確認)

    Gauge Fail
    (量規異常)
    ≠
    Machine Until It Passes
    (加工到量規通過)

    Gauge Pass After Cleaning
    (清潔後量規通過)
    ≠
    Root Cause Confirmed
    (根本原因已確認)

    Ring Gauge Pass
    (環規通過)
    ≠
    Valve Accepted
    (瓶閥整體已接受)

    Valve Gauge Pass
    +
    Cylinder Gauge Pass
    ≠
    Complete Connection Acceptance
    (完整連接判定)

    Requalification Valid
    (再檢驗有效)
    ≠
    Current Cylinder Condition Acceptable
    (目前鋼瓶狀態可接受)

    Multiple PASS
    (多項通過)
    ≠
    Critical Abnormality Can Be Ignored
    (重要異常可以忽略)

    Conflicting Evidence
    (證據衝突)
    ≠
    Choose the PASS Result
    (選擇 PASS 結果)

    Measurement Result
    (量測結果)
    ≠
    Acceptance Decision
    (接受判定)

    最終應建立:

    Gauge Result
    (量規結果)
    +
    Visual Condition
    (目視狀態)
    +
    Thread Integrity
    (螺紋完整性)
    +
    Leak / Functional Condition
    (洩漏/功能狀態)
    +
    Applicable Acceptance Criteria
    (適用接受標準)
    ↓
    Final Acceptance Decision
    (最終接受判定)

    三十二、相關文章

    ・03-02|TE、PE、EE 與 REE

    ・03-04|Hydrostatic Test Accept / Reject / Condemn

    ・04-02|Valve External Thread Inspection

    ・05-04|Neck Leak 故障診斷

    ・05-06|Outlet Thread Damage

    ・05-08|SiH4 Neck Leak 與 Thread Profile

    ・07-01|Valve External Ring Gauge

    ・07-02|3/4-14 NGT Plug Gauge

    ・07-03|Cut Tap 與 Form Tap

    ・08-02|49 CFR §180.205 再檢驗一般要求

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

    ・09-01|Stop Work 與 Good Catch

    ・09-02|Multiple Safety Barriers

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

    ・09-05|Failure Mode Database

    注意事項

    本文所稱 Gauge Pass(量規通過)僅代表相應量規檢查所取得的結果,不應單獨解讀為 Thread Integrity(螺紋完整性)、Leak Tightness(洩漏密封性)、Valve Acceptance(瓶閥接受判定)或 Cylinder Acceptance(鋼瓶接受判定)。

    Plug Gauge(塞規)與 Ring Gauge(環規)具有不同 Inspection Target(檢查對象)與用途,不得互相替代。

    實際 Thread Acceptance(螺紋接受判定)應依鋼瓶/瓶閥規格、適用量規、製造商資料、核准程序及適用 Acceptance Criteria(接受標準)進行。

    本文所述「瓶牙缺損不能因 Gauge Pass 而忽略」為本維修現場的重要保守判斷原則;若涉及正式 DOT Cylinder Requalification、Repair、Rethreading 或 Condemnation,仍應依適用 49 CFR、IBR Technical Standard(引用納入技術標準)、PHMSA 要求及具適用資格之單位判定,不應把公司內部判斷直接描述成所有 DOT Cylinder 的通用法定 Condemnation Criteria(報廢標準)。

    Cut Tap / Form Tap 不應被理解為將受損 Cylinder Neck Thread 加工至 Gauge Pass 的一般修復方法。

    本文不提供 Rethreading(重新加工螺紋)、瓶閥安裝扭力、鋼瓶修理或其他受管制作業的操作程序。

    最後更新:2026-09-30

  • Multiple Safety Barriers|特殊氣體鋼瓶維修的多層安全屏障設計

    09-02|Multiple Safety Barriers|特殊氣體鋼瓶維修的多層安全屏障設計

    特殊氣體鋼瓶維修中,

    最危險的安全觀念之一是:

    「只要這一步不要出錯就好了。」

    因為任何單一:

    Operator
    (作業人員)

    Label
    (標籤)

    Tool
    (工具)

    Inspection
    (檢查)

    Machine
    (設備)

    或:

    Procedure
    (程序)

    都有可能失效。

    因此成熟的安全系統不應建立在:

    One Perfect Barrier
    (一道永遠不失效的屏障)

    之上,

    而應建立:

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

    也就是:

    第一道屏障失效
    ↓
    第二道仍可攔截

    第二道也失效
    ↓
    第三道仍有機會發現

    直到危害真正發生之前,

    盡可能存在:

    Independent Opportunity to Detect or Stop
    (獨立發現或停止異常的機會)。

    這就是本篇要建立的核心觀念。

    一、什麼是 Safety Barrier?

    Safety Barrier
    (安全屏障)

    可以理解為:

    用來:

    Prevent
    (預防)

    Detect
    (偵測)

    Control
    (控制)

    或:

    Stop
    (停止)

    危害或錯誤向後發展的措施。

    它不一定是一個實體零件。

    Safety Barrier 可以是:

    設備

    機械結構

    工具設計

    標籤

    紀錄

    檢查

    程序

    人員判斷

    或:

    獨立驗證。

    因此:

    Barrier
    ≠
    Only Physical Guard
    (安全屏障不只是實體護罩)

    任何能夠:

    Break the Error Chain
    (切斷錯誤鏈)

    的控制措施,

    都可能成為安全系統中的一層 Barrier。

    二、為什麼不能只依賴一道屏障?

    假設一支鋼瓶的安全完全依賴:

    Status Label
    (狀態標籤)。

    只要標籤貼錯,

    後面的所有人都可能得到錯誤資訊。

    如果系統另外還有:

    Work Record Verification
    (作業紀錄確認)

    以及:

    Pressure Confirmation
    (壓力確認),

    即使標籤失效,

    後面仍有:

    Independent Detection Opportunity
    (獨立偵測機會)。

    因此:

    One Barrier Failure
    (一道屏障失效)
    ≠
    Immediate Incident
    (立即形成事故)

    前提是:

    後面還存在其他有效屏障。

    三、多層安全屏障不是重複做同一件事

    Multiple Safety Barriers

    不是單純:

    「同樣的檢查做三次。」

    真正有價值的是:

    不同屏障使用不同方式,

    去攔截不同類型的失效。

    例如:

    Label
    (標籤)

    提供:

    Status Information
    (狀態資訊)。

    Work Record
    (作業紀錄)

    提供:

    Traceability
    (可追溯性)。

    Pressure Confirmation
    (壓力確認)

    則直接確認:

    Physical Condition
    (實際物理狀態)。

    三者目的相關,

    但偵測原理不同。

    因此:

    Three Checks
    (做三次檢查)
    ≠
    Three Independent Barriers
    (三道獨立屏障)

    是否真正獨立,

    要看:

    Failure Mechanism
    (失效機制)

    是否不同。

    四、本網站將 Safety Barrier 分成五類

    為了方便 CylinderTech

    後續案例分析,

    可以將維修現場的 Safety Barrier

    整理成五個主要類型:

    Process Barrier
    (製程屏障)

    Information Barrier
    (資訊屏障)

    Engineering / Physical Barrier
    (工程/實體屏障)

    Detection Barrier
    (偵測屏障)

    Human Barrier
    (人員屏障)

    這不是 DOT / PHMSA 的官方分類,

    而是本網站為:

    Maintenance Analysis
    (維修分析)

    與:

    Knowledge Management
    (知識管理)

    建立的分類架構。

    五、Process Barrier|製程屏障

    Process Barrier
    (製程屏障)

    是透過:

    Work Sequence
    (作業順序)

    Procedure
    (程序)

    Approval
    (核准)

    Hold Point
    (停留/確認點)

    或:

    Process Separation
    (流程區隔)

    避免錯誤進入下一站。

    例如:

    鋼瓶必須完成前段處理,

    確認符合進入維修階段的條件後,

    才能送入:

    Maintenance Area
    (維修區)。

    這本身就是:

    Process Barrier。

    如果這一道失效,

    未完成前段處理的鋼瓶

    就可能進入維修流程。

    因此:

    Procedure Exists
    (有程序)
    ≠
    Process Barrier Worked
    (程序屏障成功)

    還必須確認程序:

    Was Actually Followed
    (確實被執行)。

    六、Information Barrier|資訊屏障

    Information Barrier
    (資訊屏障)

    包括:

    Label
    (標籤)

    Tag
    (吊牌/標示)

    Work Record
    (作業紀錄)

    Cylinder Identification
    (鋼瓶識別)

    Status Marking
    (狀態標記)

    以及:

    System Record
    (系統紀錄)。

    它們的主要功能是:

    讓下一位作業人員知道:

    What Is This?
    (這是什麼?)

    What Has Been Done?
    (已經做過什麼?)

    What Is Its Current Status?
    (目前狀態是什麼?)

    但是:

    Information Barrier

    有一個重要限制:

    Information
    (資訊)
    ≠
    Physical Reality
    (實際物理狀態)

    因此:

    Label Says Cleaned
    (標籤顯示已完成處理)
    ≠
    Cylinder Physical Condition Automatically Verified
    (鋼瓶實際狀態自動被確認)

    這也是為什麼不能只依賴標籤。

    七、Engineering / Physical Barrier|工程與實體屏障

    Engineering / Physical Barrier
    (工程/實體屏障)

    是利用:

    Design
    (設計)

    Geometry
    (幾何結構)

    Guard
    (防護結構)

    Interlock
    (連鎖)

    Dedicated Tool
    (專用工具)

    或其他實體方式,

    降低錯誤發生的可能。

    它最大的優點是:

    不完全依賴人員每次都做出正確判斷。

    例如:

    某個零件如果透過結構設計,

    使錯誤工具不容易接觸,

    就比:

    「提醒大家不要碰到」

    多了一層:

    Design-based Protection
    (設計型防護)。

    八、Neriki PRD 防護結構就是實際例子

    本維修現場實際接觸的部分:

    Neriki Valve
    (Neriki 瓶閥)

    在 PRD 周圍具有:

    Metal Guard Structure
    (金屬防護結構)。

    這個結構使 PRD 外側部位:

    不容易被一般工具直接接觸。

    從 Safety Barrier 的角度,

    它可以理解為:

    Physical Access Restriction
    (實體接近限制)

    以及:

    Design-based Poka-Yoke
    (設計型防錯)。

    這與:

    「規定作業人員不要碰到 PRD」

    屬於不同層次。

    前者:

    Design Tries to Prevent the Error
    (設計本身降低錯誤機會)

    後者:

    Person Must Remember Not to Make the Error
    (依賴人員記得不要犯錯)

    兩者可以同時存在。

    九、Rotarex 實際案例可以用來理解 Barrier 差異

    本維修現場實際接觸並拍攝的部分:

    Rotarex Valve
    (Rotarex 瓶閥)

    其 PRD 外側六角部位

    相較於前述 Neriki 實例:

    Tool Accessibility
    (工具接近性)

    較為直接。

    這不代表:

    Rotarex Valve Is Unsafe
    (Rotarex 瓶閥不安全)。

    真正代表的是:

    不同 Valve Design
    (瓶閥設計)

    可能需要不同的:

    Risk Control Strategy
    (風險控制策略)。

    當:

    Physical Access Restriction
    (實體接近限制)

    較少時,

    其他屏障的重要性可能提高。

    例如:

    Tool Selection
    (工具選擇)

    Component Identification
    (零件識別)

    Tool Clearance
    (工具間隙確認)

    Post-work Inspection
    (作業後檢查)。

    因此:

    Different Design
    (不同設計)
    →
    Different Barrier Combination
    (不同安全屏障組合)

    而不是:

    Different Design
    →
    Safe / Unsafe
    (直接判斷安全/不安全)。

    十、Tool Control 也是一道 Barrier

    本維修現場在部分瓶閥/PRD 相關作業中,

    限制:

    Adjustable Wrench
    (活動扳手)

    並使用:

    Specified Fixed-size Wrench
    (指定固定尺寸扳手)。

    這是一種:

    Tool / Process Barrier
    (工具/製程屏障)。

    目的不是:

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

    而是降低:

    Wrong Tool Fit
    (工具配合不當)

    Slipping
    (滑脫)

    Unexpected Contact
    (非預期接觸)

    Wrong Component Engagement
    (誤作用於其他零件)

    以及:

    Tool Interference
    (工具干涉)

    的可能性。

    因此:

    Approved Tool
    (核准工具)

    本身就是:

    Error-reduction Barrier
    (降低錯誤的屏障)。

    十一、但是 Fixed-size Wrench 也不是完美屏障

    即使使用:

    Fixed-size Wrench

    仍然可能:

    選錯尺寸

    接觸錯誤零件

    操作角度不當

    與鄰近零件干涉

    或:

    工具本身狀態異常。

    因此:

    Fixed-size Wrench
    ≠
    Zero Risk

    Correct Tool Size
    (正確工具尺寸)
    ≠
    Correct Component Confirmed
    (已確認正確零件)

    這也是 Multiple Safety Barriers

    存在的原因。

    工具控制後面仍需要:

    Component Identification
    (零件識別)

    +

    Clearance Check
    (間隙確認)

    +

    Post-work Inspection
    (作業後檢查)。

    十二、Detection Barrier|偵測屏障

    Detection Barrier
    (偵測屏障)

    的目的不是:

    阻止錯誤發生,

    而是:

    在錯誤已經存在後,

    盡早把它發現。

    例如:

    Pressure Confirmation
    (壓力確認)

    Leak Check
    (洩漏檢查)

    Gauge Inspection
    (量規檢查)

    Visual Inspection
    (目視檢查)

    Record Cross-check
    (紀錄交叉確認)

    以及:

    Post-work Inspection
    (作業後檢查)。

    它們都可能屬於:

    Detection Barrier。

    這類屏障非常重要,

    因為現實中:

    Prevention Can Fail
    (預防措施可能失效)。

    十三、Pressure Confirmation 是典型 Detection Barrier

    06-05 案例中,

    未完成前段處理的鋼瓶

    進入了維修流程。

    代表前面的某些:

    Process / Information Barrier

    沒有成功阻止它。

    但是後續:

    Pressure Confirmation

    發現:

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

    因此:

    Pressure Confirmation

    在這個事件中就是:

    Detection Barrier。

    它沒有讓上游錯誤消失,

    但是成功提供:

    Another Opportunity to Detect the Hazard
    (另一個發現危害的機會)。

    十四、Human Barrier|人員屏障

    最後一道非常重要的屏障是:

    Human Barrier
    (人員屏障)。

    人員可以:

    Recognize
    (辨識)

    Question
    (提出疑問)

    Compare
    (比較)

    Stop
    (停止)

    Report
    (回報)

    以及:

    Escalate
    (升級處理)。

    06-06 的:

    Label / Record Mismatch

    就是典型例子。

    即使:

    Wrong Label

    已經存在,

    維修人員仍然沒有:

    Blindly Trust the Label
    (盲目相信標籤)。

    而是發現:

    Information Does Not Match
    (資訊不一致)

    並:

    Stop Work。

    這就是:

    Human Barrier Worked
    (人員屏障成功)。

    十五、Human Barrier 很重要,但不能成為唯一屏障

    如果事故調查最後只得到:

    「提醒作業人員注意。」

    通常代表安全改善仍然很弱。

    因為:

    Be More Careful
    (更加小心)

    完全依賴:

    Memory
    (記憶)

    Attention
    (注意力)

    Experience
    (經驗)

    以及:

    Individual Judgment
    (個人判斷)。

    人會:

    疲勞

    分心

    誤判

    忘記

    或:

    缺乏經驗。

    因此:

    Training
    (教育訓練)

    很重要,

    但最好不要成為:

    Only Barrier
    (唯一屏障)。

    十六、一道好的 Barrier 應盡量不依賴上一道 Barrier

    假設:

    Label

    與:

    Work Record

    其實都是由:

    同一個人

    在同一時間

    依同一份資料輸入。

    如果原始資料錯誤,

    兩者可能:

    Simultaneously Wrong
    (同時錯誤)。

    此時看起來有:

    Two Checks
    (兩個檢查)

    實際上可能只有:

    One Information Source
    (一個資訊來源)。

    這就是:

    Common Cause Failure
    (共同原因失效)

    的概念。

    因此真正的:

    Independent Barrier
    (獨立屏障)

    最好使用不同:

    Information Source
    (資訊來源)

    Detection Method
    (偵測方法)

    或:

    Physical Principle
    (物理原理)。

    十七、Independent Check 的真正意義

    Independent Check
    (獨立檢查)

    不是:

    第二個人再看一次第一個人的答案。

    更理想的方式是:

    第二道檢查可以:

    Independently Determine the Condition
    (獨立判定狀態)。

    例如:

    Label Says Process Complete
    (標籤顯示程序完成)

    是一道資訊。

    Pressure Confirmation
    (壓力確認)

    則是直接取得:

    Physical Evidence
    (物理證據)。

    因此兩者具有較高:

    Independence
    (獨立性)。

    十八、PRD Missing Component 案例的 Barrier 分析

    06-02 案例中,

    發生:

    PRD Missing Burst Disc
    (PRD 缺少 Burst Disc)

    並造成大量氣體釋放。

    這類事件可以用 Barrier 思維重新分析。

    可能需要的安全屏障包括:

    Correct Part Identification
    (正確零件識別)

    ↓

    Component Completeness
    (零件完整性)

    ↓

    Assembly Verification
    (組裝確認)

    ↓

    Independent Check
    (獨立確認)

    ↓

    Final Inspection / Test
    (最終檢查/測試)

    如果只依賴:

    「組裝人員記得放入所有零件。」

    那就是:

    Single Human Barrier
    (單一人員屏障)。

    而:

    Multiple Verification Opportunities
    (多重確認機會)

    能降低:

    Missing Component

    一路流到最終使用階段的機會。

    十九、Exterior Appearance 不是完整性屏障

    PRD 外觀看起來:

    Complete
    (完整)

    不代表:

    Internal Components
    (內部零件)

    一定完整。

    因此:

    Exterior Visual Inspection
    (外觀目視檢查)

    對某些 Failure Mode

    可能不是足夠有效的:

    Detection Barrier。

    這就是 Barrier Analysis

    需要問的問題:

    Can This Barrier Actually Detect This Failure Mode?
    (這道屏障真的能發現這個故障模式嗎?)

    如果答案是:

    No

    就不能把它算成:

    有效的防線。

    二十、Barrier 必須對應 Failure Mode

    安全屏障不是:

    越多越好

    就一定有效。

    真正重要的是:

    Barrier
    (屏障)

    是否能對應:

    Failure Mode
    (故障模式)。

    例如:

    Plug Gauge
    (塞規)

    可以提供:

    Thread Dimensional / Fit Information
    (螺紋尺寸/配合資訊)。

    但是它不能單獨證明:

    Leak Tightness
    (洩漏密封性)。

    因此:

    Plug Gauge Pass

    不是:

    Neck Leak Detection Barrier

    的完整替代品。

    同樣:

    Leak Test Pass

    也不能完整判斷:

    Thread Profile
    (牙型狀態)。

    所以:

    Different Failure Mode
    →
    Different Detection Barrier

    這會在 09-03:

    Gauge Pass ≠ Cylinder Accepted

    進一步說明。

    二十一、Barrier 存在不代表 Barrier 有效

    公司可能有:

    SOP

    Checklist

    Label

    Inspection

    Training。

    但真正需要問的是:

    Does It Actually Prevent or Detect the Failure?
    (它真的能預防或發現這個失效嗎?)

    例如:

    Checklist 上有一個勾選欄,

    但是:

    沒有明確檢查內容

    沒有人確認

    沒有紀錄

    或:

    所有人習慣直接打勾。

    這個 Barrier

    雖然:

    Exists on Paper
    (紙面存在)

    但可能:

    Weak in Practice
    (實際效果很弱)。

    因此:

    Barrier Exists
    ≠
    Barrier Effective
    (屏障存在不等於屏障有效)

    二十二、事故後不要只增加 Checklist

    事故發生後,

    最容易採取的措施是:

    「Checklist 再增加一欄。」

    但如果根本問題是:

    Tool Can Physically Contact the Wrong Component
    (工具可以直接接觸錯誤零件),

    增加 Checklist

    可能仍然只是:

    Administrative Control
    (管理控制)。

    如果可以從:

    Design
    (設計)

    Tool Geometry
    (工具幾何)

    Physical Guard
    (實體防護)

    或:

    Fixture
    (治具)

    降低接觸可能,

    通常是不同層次的 Barrier。

    因此事故改善應該問:

    Can We Prevent the Error by Design?
    (能否從設計避免錯誤?)

    而不只是:

    Can We Remind the Operator Again?
    (能否再提醒作業人員一次?)

    二十三、Preventive Barrier 與 Detection Barrier 要一起存在

    Preventive Barrier
    (預防屏障)

    目的:

    Prevent Failure
    (避免失效發生)。

    Detection Barrier
    (偵測屏障)

    目的:

    Detect Failure After It Exists
    (失效存在後把它發現)。

    例如:

    Specified Fixed-size Wrench
    (指定固定尺寸扳手)

    可以屬於:

    Preventive Barrier。

    而:

    Post-work PRD Inspection
    (作業後 PRD 檢查)

    可以屬於:

    Detection Barrier。

    兩者一起使用,

    比只依賴其中一個更完整。

    因此:

    Prevent
    +
    Detect

    通常比:

    Prevent Only

    更具有韌性。

    二十四、Multiple Barriers 不代表可以降低每一道要求

    這也是容易產生的誤解。

    不能因為:

    「後面還有檢查。」

    就認為:

    前面的程序可以隨便。

    例如:

    後面有 Pressure Confirmation

    不能成為:

    前站狀態管理失效

    可以被接受的理由。

    同樣:

    最後有 Leak Test

    不能成為:

    前面 Thread Inspection

    可以省略的理由。

    因此:

    Backup Barrier Exists
    (存在備援屏障)
    ≠
    Primary Barrier Can Be Ignored
    (主要屏障可以忽略)

    每一道 Barrier

    仍然應完成自己的功能。

    二十五、Barrier Failure 也是重要資料

    如果一件事故或 Near Miss

    成功穿過三道屏障,

    直到第四道才被發現,

    真正值得研究的不只是:

    「第四道做得很好。」

    還包括:

    Why Did Barrier 1 Fail?
    (第一道為何失效?)

    Why Did Barrier 2 Fail?
    (第二道為何失效?)

    Why Did Barrier 3 Fail?
    (第三道為何失效?)

    這樣才能找出:

    System Weakness
    (系統弱點)。

    因此 Good Catch 紀錄中,

    可以增加:

    Failed Barrier
    (失效屏障)

    以及:

    Successful Barrier
    (成功屏障)。

    二十六、Failure Mode Database 可以加入 Barrier 資訊

    未來 09-05 建立:

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

    時,

    每一個 FM ID

    除了:

    Failure Mode

    Location

    Observed Condition

    Cause Status

    之外,

    還可以加入:

    Preventive Barrier
    (預防屏障)

    Detection Barrier
    (偵測屏障)

    Failed Barrier
    (失效屏障)

    Successful Barrier
    (成功屏障)。

    例如:

    FM-012
    Status Label / Record Mismatch

    Preventive Barrier:

    Status Control
    (狀態管理)

    Detection Barrier:

    Record Cross-check
    (紀錄交叉確認)

    Successful Barrier:

    Technician Verification
    (技術人員確認)

    如此資料庫就不只是:

    「發生過什麼問題。」

    而是開始回答:

    「我們靠什麼把問題攔下來?」

    二十七、建立 Barrier Map

    對重要作業,

    可以建立:

    Barrier Map
    (安全屏障圖)。

    例如瓶閥維修流程:

    Cylinder Identification
    (鋼瓶識別)
    ↓
    Process Status Verification
    (製程狀態確認)
    ↓
    Record Verification
    (紀錄確認)
    ↓
    Pressure Confirmation
    (壓力確認)
    ↓
    Component Identification
    (零件識別)
    ↓
    Approved Tool
    (核准工具)
    ↓
    Tool Clearance
    (工具間隙)
    ↓
    Maintenance Work
    (維修作業)
    ↓
    Post-work Inspection
    (作業後檢查)
    ↓
    Applicable Final Verification
    (適用最終確認)

    每發生一件:

    Incident

    Near Miss

    Good Catch

    就可以回到這張圖,

    確認:

    Which Barrier Failed?
    (哪一道失效?)

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

    二十八、Barrier 的目標不是追求「零錯誤的人」

    真正成熟的安全系統

    不應假設:

    People Never Make Mistakes
    (人永遠不會犯錯)。

    而應假設:

    Mistakes Are Possible
    (錯誤可能發生)

    然後設計:

    How Will We Prevent It?
    (如何預防?)

    If Prevention Fails, How Will We Detect It?
    (預防失效後如何發現?)

    If Detection Occurs, How Will We Stop It?
    (發現後如何停止?)

    因此:

    Safety
    (安全)

    不是:

    Perfect Operator
    (完美作業人員)

    而是:

    Resilient System
    (具有韌性的系統)。

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

    One Barrier
    (一道屏障)
    ≠
    Complete Safety System
    (完整安全系統)

    More Checks
    (更多檢查)
    ≠
    Independent Barriers
    (獨立屏障)

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

    Procedure Exists
    (程序存在)
    ≠
    Procedure Was Followed
    (程序確實執行)

    Barrier Exists
    (屏障存在)
    ≠
    Barrier Effective
    (屏障有效)

    Fixed-size Wrench
    (固定尺寸扳手)
    ≠
    Zero Risk
    (零風險)

    Physical Guard
    (實體防護)
    ≠
    Zero Risk
    (零風險)

    Exposed PRD
    (PRD 相對暴露)
    ≠
    Unsafe Valve
    (不安全瓶閥)

    Exterior Complete
    (外觀看起來完整)
    ≠
    Internal Components Confirmed
    (內部零件已確認完整)

    Backup Barrier Exists
    (存在備援屏障)
    ≠
    Primary Barrier Can Be Ignored
    (主要屏障可以忽略)

    Human Barrier
    (人員屏障)
    ≠
    Only Barrier
    (唯一屏障)

    Checklist Added
    (增加檢查表)
    ≠
    Root Risk Eliminated
    (根本風險已消除)

    Good Catch
    (良好攔截)
    ≠
    System Has No Weakness
    (系統沒有弱點)

    真正完整的安全架構是:

    Prevent
    (預防)
    +
    Detect
    (偵測)
    +
    Stop
    (停止)
    +
    Verify
    (確認)
    +
    Learn
    (學習)

    三十、相關文章

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

    ・06-02|PRD Burst Disc 遺漏事故

    ・06-05|未完成前段處理鋼瓶與 Pressure Confirmation

    ・06-06|Status Label / Record Mismatch Good Catch

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

    ・07-04|Pressure Test Panel

    ・07-06|Fixed-size Wrench、Adjustable Wrench 與 PRD 防錯設計

    ・09-01|Stop Work 與 Good Catch

    ・09-03|Gauge Pass ≠ Cylinder Accepted

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

    ・09-05|Failure Mode Database

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

    注意事項

    本文所使用的 Process Barrier(製程屏障)、Information Barrier(資訊屏障)、Engineering / Physical Barrier(工程/實體屏障)、Detection Barrier(偵測屏障)及 Human Barrier(人員屏障)分類,主要用於 CylinderTech 的維修安全分析與知識管理,不代表 DOT / PHMSA 的統一法定分類。

    不同 Valve、PRD、Cylinder、Tool、Equipment 與 Process 具有不同設計與風險條件,本文所述 Barrier Example(屏障案例)不能直接視為所有設備的通用要求。

    本文提及 Neriki 與 Rotarex 的 PRD 結構差異,僅描述本維修現場實際接觸及拍攝之特定瓶閥實例,不代表各品牌所有型號均採用相同設計,也不構成品牌安全性排名。

    實際安全屏障應依設備設計、製造商資料、公司核准程序、適用法規、氣體危害及現場 Risk Assessment(風險評估)建立。

    本文不提供特殊氣體鋼瓶洩壓、排放、PRD 拆裝、瓶閥拆卸或其他危險操作程序。

    最後更新: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