故障樹如何從可觀察症狀往可驗證原因展開

先把頂端事件寫得可以判定

故障樹從一個明確的不希望發生的事件往下推，整理哪些條件組合可能造成它。先不要寫「設備有問題」，改成「本次命令已被接受，但在指定時間內沒有完成回饋」。事件範圍清楚，後面每個分支才知道在解釋什麼。

頂端事件加上模式、時間窗與邊界。例如本文只討論自動模式下單次推料動作，命令識別與完成回饋可以對應。待機沒有完成回饋不算故障；命令根本未被接受則是另一個頂端事件，不能混在同一判定裡。

把現象與原因分開。HMI顯示逾時是觀察，感測器壞是原因假設。先核對現象是否可靠，再展開可能造成現象的路徑。如果警報邏輯使用錯誤計時起點，機構可能已按要求完成，卻被系統誤報。

本文是定性診斷入門，參考NASA故障樹手冊的事件與邏輯概念。它不構成機械安全等級、失效機率或法規符合性計算；正式安全分析需要完整設計、邊界、失效資料及合格審查。

本例先分成三個候選分支：機構沒有在期限內到位、機構到位但回饋未正確送達、判定邏輯錯誤。任一分支都可能讓本例頂端事件成立，所以用或關係連接。實際樹是否完整，要回到設備設計與事件記錄補查。

或關係表示任一輸入事件成立就足以使該層輸出成立；且關係表示所列事件必須一起成立。不要因兩個零件畫在一起，就用且關係連接，也不要把時間先後直接畫成且。每個邏輯門旁寫一句自然語言，可以快速發現自己是否真的理解。

例如本例定義有兩個任一可用就足夠的獨立通道，在其他必要條件正常的假設下，失去兩路才失去功能，所以兩路不可用以且關係表示。這只是教學假設；若實際設計要求兩路一致才能動作，頂端事件及關係就不同。

同一共用電源能同時影響兩通道時，把它以同一原因識別呈現，不把兩路故障當互不相關。正式機率計算尤其不能憑兩路各有一個數字就相乘；相關性與共同原因須另外建模，本文不估算安全可靠度。

完成這一步應能逐個回答：這個分支單獨成立，真的足以造成上一層嗎？需要哪些隱含條件？若答案說不清楚，先調整邊界或補中間事件，不急著畫出很大的樹。

將「感測器問題」往下拆成供電不符、安裝位置不符、目標未進感測範圍、輸出未到模組或映射錯誤等候選事件。不要一路拆到任何人都無法觀察的程度；先停在目前工具和文件可以查證的層級，保留尚未展開標記。

每個葉端加上測試、預期現象與反證。例如懷疑映射錯誤，就對照實際端子、模組通道及變數關聯，並在核准條件下觀察指定通道。只看HMI上的綠燈，可能仍是同一個錯誤映射的結果，不能算獨立證據。

診斷表另列資料時間與品質。今天量到供電正常，未必能排除昨天故障瞬間供電下降；若量測速度不足以捕捉短暫事件，也不能把平穩畫面當成反證。葉端狀態可分支持、排除、未測與資訊不足，避免只有對錯兩種。

把證據連到樹的事件識別，不以口頭說「那邊查過了」。一份波形若支持多個分支，標示同一證據編號；重複引用同一檔案不會自動變成多份獨立證明。保留原始檔與條件，方便下一位工程師覆查。

樹的停止條件也要寫清楚，例如目前只分析到模組或線路層，不包含元件內部失效機制。未展開不表示不可能，而是本次範圍尚未深入；交接時應讓讀者一眼看出這個限制。

先做風險低、能同時區分多個分支的觀察。例如同步看命令接受、實際位移與輸入狀態，可以先分開機構未動、回饋未到及判定錯誤。若只反覆更換感測器，其他分支仍沒有獲得任何新資訊。

假設影像顯示機構在八百毫秒到位，模組輸入在八百一十毫秒成立，但程式到兩秒仍判逾時。優先追查輸入到判定的映射、條件與命令關聯；目前資料削弱了「機構完全沒有到位」的解釋，但仍要核對三份紀錄是否同一次動作。

若機構與回饋都晚，則沿動作路徑查命令、能源與負載。不要用故障樹的版面位置當優先級；真正順序由現場風險、取得證據的成本及能排除多少候選解釋決定。需要拆機的測試另按停機及隔離程序。

故障樹會隨證據修改。發現樹外原因時新增分支並記版本，不把新資料硬塞進原先猜想。樹的用途是讓推理可檢查，不是證明第一位畫圖的人一定正確。完成後交付樹、葉端查證表及未解項。

練習：頂端是回饋未在兩秒內成立，記錄顯示輸入模組在一秒成立，而程式使用的變數始終假。下一步應核對通道映射、資料更新與實際使用條件，不能僅憑頂端逾時就更換致動器。若模組紀錄無法對應本次命令，先補事件關聯。

失敗時先檢查事件敘述是否混用了正常狀態與故障狀態，再查或與且的定義。分支都寫成「可能某某」卻沒有可觀察結果，表示樹還停在猜想清單，需要補查證動作。

問：故障樹等於排查流程圖嗎？答：它描述原因組合，實際檢查順序還要另外安排。

問：樹上列出的就是已確認原因嗎？答：不是，須用證據更新每個候選事件。

問：兩個事件同時出現就一定用且嗎？答：要看兩者是否共同必要，不能只靠同時發生。

問：可以直接填失效百分比嗎？答：沒有適用資料、共同原因及模型審查時，不應假裝已完成定量風險分析。