程序要寫到可判定
HMI操作程序不能只列按鈕名稱。每一步要有前置條件、執行動作、預期結果、失敗處理、角色與確認窗口。操作員要知道何時停下來求助，工程師要知道需要哪些證據。畫面上的Ack不是把故障關掉的捷徑，非緊急告警也不能用Ack代替恢復。
警報要用兩個獨立軸判讀：Active或Clear，以及Unacknowledged或Acknowledged。Ignition因此有Active未確認、Active已確認、Clear未確認、Clear已確認四種組合。Ack代表已確認，不自動指派負責人，也不代表設備恢復；處置責任與工單結案要另外記錄。
| 步驟 | 前置 | 操作 | 預期/失敗 |
|---|---|---|---|
| 1確認 | 登入且角色合適 | 讀告警ID與來源 | 資訊一致；不一致停止 |
| 2評估 | 設備狀態可見 | 確認現場安全與互鎖 | 不安全則撤離升級 |
| 3處理 | 有批准程序 | 處理根因並觀察 | 仍Active則查處 |
| 4結案 | 狀態已Clear | 記錄結果後Ack/關閉 | 未Clear不得結案 |
程序文件的每一步都要說明資料來源。讀告警ID來自畫面事件、回饋值來自指定tag或歷史查詢；若來源不明，操作員無法判定畫面數字是否新鮮。欄位名稱可依產品不同，但意義要固定。
程序首頁先寫文件SOP-AL01、版本1.0、畫面P12、適用角色與非緊急製程提示範圍。本例只演示離線警報確認與追蹤，若遇緊急停機或安全相關警報，改按該機台核准程序。畫面按鈕名稱變動時，文件需能由P12和版本重新定位，不能只靠截圖顏色。
告警確認窗口
告警出現時先保存alarmId、source、active時間、priority、quality與當時畫面。角色只負責能否查看、確認或修改程序，不代表角色可以繞過互鎖。確認前檢查是否為測試、重複或來源Bad；來源品質不明時標記待查，不把它直接當成製程正常。
確認窗口存在狀態變化：打開確認框後，原事件可能已Clear或另一次Active已產生。送出前核對事件ID與來源，不能只用同名警報文字選事件。Ignition的事件ID辨識一次Active/Clear/Ack週期；自訂備註若要防止兩人覆寫，需後端版本檢查或追加式紀錄，不能假定標準Ack按鈕替自訂資料實現這個功能。
非緊急告警的正確流程是確認收到、通知owner、處理根因、觀察回饋、等待Clear，再以事件記錄結案。若告警仍Active，即使已Ack，也要保留在Active清單並升級。不得教人反覆Ack來讓畫面看似乾淨。
| 警報組合 | 畫面判讀 | 本例下一步 |
|---|---|---|
| Active/Unacked | 仍觸發且未確認 | 確認收到並分派 |
| Active/Acked | 仍觸發但已確認 | 追蹤原因與回饋 |
| Clear/Unacked | 已恢復但尚未確認 | 覆核事件後Ack |
| Clear/Acked | 恢復且已確認 | 處置紀錄核對後結案 |
操作前的安全確認包括角色、設備狀態、互鎖與現場許可；這些是前置條件，不能在操作失敗後才補做。若前置不滿足，程序結果應是Stopped或Escalated，不是Failed後繼續下一步。
完整操作案例
離線案例AL-196-01為非緊急溫度偏高提示，使用測試來源。09:00 Active/Unacked，操作員在P12核對來源與品質後09:01按Ack，預期Active/Acked。09:05測試來源恢復正常，平台產生Clear後成為Clear/Acked；操作員再記錄原因和回饋，結束本次處置。若09:05來源仍高，預期仍Active/Acked，不能按關閉讓它變正常。
第二個分支是來源在09:00:30先恢復，而操作員09:01才確認。此時先看到Clear/Unacked，Ack後變Clear/Acked，時間線合法，不要求Ack必須早於Clear。若確認框開著時又發生新週期，顯示新的事件ID，重新核對後處理；舊週期的Ack不能當作新事件已確認。
失敗處理要有明確分支：無法讀取來源則顯示品質錯誤並聯絡工程師；回饋未恢復則不清除；Clear後又重新Active則建立新事件或重開同一事件依平台規則，不把短暫Clear當作根因已解決。
告警確認與處置備註分開保存。Ack記錄看見事件的時間與人員，備註記錄採取的措施和結果；兩者不可合併成一個「已處理」勾選框。
若組織規定恢復後再觀察兩個週期，把它寫成工單的RecoveryObservation狀態及取樣週期，與平台警報Clear分開。這是本案可選處置規則，沒有通用的ClearPending警報狀態，也不能以兩個週期代替現場穩定判準。
若告警持續Active超過窗口，升級條件要寫在程序與值班表，避免操作員以反覆Ack代替處理。
角色測試應包括Operator只能確認、Supervisor依程序處理、Engineer查看診斷與Auditor讀取歷史。任何角色都不能靠Ack把Active告警變成已恢復；Clear必須由來源條件恢復與平台狀態共同證明。
驗收與限制
離線驗收覆蓋四種警報組合，並測Operator可確認、無授權帳號拒絕確認、Auditor僅讀歷史的本案權限需求。另測先Ack後Clear、先Clear後Ack、來源Bad及恢復後重發；每次記錄預期事件ID與實際結果。角色名稱與權限是設計條件，需在平台確實配置。
驗收證據包括alarmId、事件時間線、角色、按鈕結果、來源品質、回饋值與結案備註。Ignition Alarm Journal可供事件查詢，但不同版本與模組的欄位、清除方式要查指定文件；本文不杜撰命令或PLC位址。
程序只能支持判斷，不能取代現場安全規程、能源隔離或機械檢查。若操作人員沒有安全資格、現場回饋不可信或互鎖異常，停止操作並升級。
Clear判定要遵循來源和平台定義。若只有畫面數值暫時低於門檻，但來源品質Bad或回饋停止，不能把它當作可靠Clear；品質恢復後仍要觀察規定週期。
同一告警若有多個來源，程序要指定優先來源與衝突處理；不能只看最後刷新值。來源不一致時標記Conflict並升級，保留兩個時間戳與品質欄。
按鈕回應不明時先重新查詢原事件的Ack時間與操作者，保留回應未知紀錄，不能假定失敗再按。讀回失敗就顯示Unknown；現場狀態可能已變，不應宣稱「保持原狀態」。恢復查詢後再決定是否需確認，並查明權限或通訊錯誤。
兩人同時處理時，備註採新增觀察而非覆寫同一文字欄。若自訂表單使用revision=3，第一人提交成4後，第二人仍帶3應收到版本衝突，讀取最新內容再補註。這個案例只說明應用驗收，需自行實作並測試，不是Ignition告警原生版本API。
失敗時先查原事件ID和目前四態，再查來源品質、權限與請求回應。若警報表變空，取消篩選查看是否隱藏Clear或Acked，再查歷史；不要因列表消失就把設備判正常。工單仍需引用原事件和實際回饋。
FAQ與來源
完成後應能重建09:00觸發、09:01確認、09:05恢復的第一條時間線，以及先恢復後確認的第二條。交付本例程序表、角色矩陣及兩個預期結果，讓接手者能用隔離測試來源逐步走查。
FAQ1：按Ack會清除非緊急告警嗎？不會，Ack只記錄已確認，Active仍需處理。
FAQ2：什麼時候可結案？來源條件已恢復並進入Clear，完成處置記錄後才可結案。
FAQ3：兩人同時確認怎麼辦？先以事件ID辨識週期；自訂備註使用追加或後端版本檢查，讀回最新結果，不把未證實功能當平台保證。
FAQ4：畫面沒有告警就代表設備正常嗎？不一定，還要查來源品質、回饋與事件歷史。
參考：Ignition 8.1 Alarming：Active、Cleared、Acknowledged及四種事件狀態。
參考：Ignition 8.1 Alarm Journal Query：查詢告警事件與歷史記錄。
參考：Ignition 8.1 Alarm Journal：eventid代表一次Active/Clear/Ack週期。