先定義事件資料與時鐘
事件時間線要把來源、時間戳、操作者、設備與證據放在同一脈絡。本文用虛構輸送帶在14:00前後停機案例；每列保存eventId、cycleId、sourceTimestamp、serverReceivedAt、operator、設備狀態與備註關聯。sourceTimestamp是來源產生時間，收取時間是系統收到時間，不能互換。來源時鐘未校準時，也不能用同一秒的排序宣稱因果。
| 欄位 | 例值 | 用途 | 限制 |
|---|---|---|---|
| eventId | EV-2041 | 辨識一筆事件 | 不可用時間代替 |
| cycleId | C-88 | 關聯一次停機週期 | 可含多事件 |
| sourceTimestamp | 13:57:12.400 | 來源順序 | 需核對時鐘 |
| serverReceivedAt | 13:57:12.920 | 觀察來源與接收差 | 非現場發生時間 |
| operator | 王O | 稽核操作 | 不等於設備執行者 |
時間精度也要寫清楚。毫秒只是欄位精度，不代表時鐘真的準到毫秒；若PLC只有秒級時間，事件應標示精度而非補出假毫秒。先用NTP或同一時間源核對偏差，再決定能否比較相鄰事件。
事件資料表要把原始欄位和計算欄位分開。相對時間、延遲估計與排序鍵都是分析產物，不能覆寫來源時間。報告若修正時鐘偏差，保存修正前值、偏差來源與套用版本。
若來源時間只有秒級而收取時間有毫秒，報告應顯示精度差異。不可用毫秒欄位填補來源未知的部分，否則讀者會誤以為設備時鐘更準。
重建三分鐘事件窗口
自訂時間線如下：13:57:00模式由Auto切Manual，13:57:12.400低速警報來源發生，13:57:13操作員收到並留下備註，13:58:05輸送帶停止回饋，13:59:10復歸命令送出，13:59:18回饋Ready。每一列仍保留原eventId與cycleId；備註引用EV-2041，另保存NOTE-17作為人工備註，type欄明示note，不冒充設備產生事件。
| 來源時間 | 事件 | eventId/cycleId | 解讀 |
|---|---|---|---|
| 13:57:00.000 | Mode Manual | EV-2039/C-88 | 模式切換 |
| 13:57:12.400 | Low speed | EV-2041/C-88 | 來源警報 |
| 13:57:13.100 | 操作備註 | NOTE-17/C-88 | 人員觀察 |
| 13:58:05.000 | Stop feedback | EV-2044/C-88 | 設備回饋 |
| 13:59:10.000 | Reset command | EV-2048/C-88 | 命令送出 |
| 13:59:18.000 | Ready | EV-2049/C-88 | 恢復證據 |
這條線只能支持「低速警報先於停止回饋，期間有人留下備註」，不能直接證明低速造成停止。要說因果，還需控制邏輯、輸入品質與其他事件證據。若兩事件時間相同，採來源序號或精度標記並列呈現，不靠畫面排序硬造先後。
本文eventId是自訂轉移識別，每次Active、Ack、Clear各有不同ID；同一次轉移的傳輸重送沿用ID。同一cycleId可包含多個警報週期和備註。Ignition原生eventid則關聯一次警報週期，匯入時要另外映射transitionId，不可直接套用本文eventId語意。若事件重新發生，建立新事件並以parent或cycle欄位關聯，不把兩次發生併成一條文字。
游標 備註與排錯
回看時先用cycleId篩出同一停機週期，再依sourceTimestamp顯示，最後疊serverReceivedAt與operatorAt。游標落在13:57:12.500可能只是圖表插值，不是原始樣點；報告要列nearest raw sample與cursor display value。備註要有作者、角色、時間、引用eventId及是否事後補寫。
| 症狀 | 先查 | 不要推論 |
|---|---|---|
| 事件倒序 | 時鐘偏差、來源序號 | 不代表設備逆序 |
| 備註找不到 | eventId/cycleId關聯 | 不代表未操作 |
| 同秒多事件 | 時間精度與序號 | 不以畫面上下判因果 |
| 收到晚很多 | source/receive差值與同步 | 不直接定義網路延遲 |
若警報在伺服器先到而操作備註後寫入，這是正常的兩種時間。若資料缺sourceTimestamp，保存缺值並標示不可排序，不用serverReceivedAt冒充現場時間。事件重發要保留原eventId與重發記錄；新的停機週期才建立新的cycleId。
時間線的空白也有意義。沒有資料不等於設備沒有動作，應標示缺測區間、來源斷線或權限不足。缺測期間的因果結論只能列為未確認。
交付報告與平台限制
報告頁首列資料來源、查詢起訖、時區、時鐘同步證據與資料品質。時間線下方分開寫觀察事實、待確認假設與處置；例如「EV-2041先於EV-2044」是觀察，「低速造成停止」是待驗證假設。Ignition Alarm Journal官方文件指出可保存警報來源、時間戳及事件屬性；其欄位能力不等於所有HMI都有相同事件API。
驗收可用同一組六列資料重建兩次，檢查eventId、cycleId、來源時間、接收時間與備註完全一致；再故意讓時鐘偏差一秒，確認畫面顯示警告而非改寫順序。涉及安全或停機決策時，事件時間線是證據整理工具，不代替安全控制。
完成結果是值班者能從三分鐘前看到模式切換、警報、備註、停止回饋與恢復命令，並知道哪些是原始證據、哪些仍待調查。
交班報告可把每列連到原始警報、趨勢樣點或操作紀錄，但連結失效時仍保留文字快照、查詢條件和資料版本，避免只剩一個無法開啟的網址。
事件時間線的資料品質要逐列標註。保留來源quality原碼，另以clockQuality、parseStatus與completeness記錄時鐘、格式和缺測；來源Good不證明時間已同步。排序畫面可以顯示相對位置，但報告必須保留品質與缺測原因。若操作員在13:57:13留下備註，不能倒推他在13:57:12.400已看到警報；只有操作記錄或確認事件能支持這個結論。
把窗口固定為2026-09-17的13:57:00至14:00:00，時區+08:00，含起點不含終點。這三分鐘包含停止前後，並不是停止回饋之前的三分鐘。若要改查13:58:05停止前的三分鐘，起點應為13:55:05，Ready與Reset將落在窗口之外；圖名和查詢範圍必須一起改。
以EV-2041的來源13:57:12.400及接收13:57:12.920計算，觀測差是520毫秒。它包含來源時鐘偏差與資料處理、排隊、傳輸，不等於網路單向延遲。只有時鐘和處理點定義足夠明確時，才能進一步拆解；否則報表欄名寫觀測時間差即可。
做去重練習時，重送EV-2041兩次，事件主表仍是一筆，但接收記錄增加兩筆並保留各自時間。接著新增同一警報的Ack轉移，應新增transitionId並保留同一alarmCycleId，不能因週期相同就刪掉。最後加入NOTE-17修改版，原備註仍可查而新版本標示作者與原因。
手動模式可能先於低速警報，卻不代表模式切換就是故障原因。把它列為待查假設，下一步讀控制邏輯中停止要求的來源、互鎖狀態與資料品質，再對照停止回饋。若缺少這些證據，結論維持「同一時間窗內先後發生」，不要由排得漂亮的時間線推導機械原因。
FAQ與來源
FAQ1：同一秒的事件可按資料庫插入順序判因果嗎？不可，先查來源序號、時鐘與精度。
FAQ2：serverReceivedAt可以當設備發生時間嗎？不可，它只代表系統收到資料的時間。
FAQ3：備註應修改原警報文字嗎？不應，備註應引用eventId並保留作者與時間。
FAQ4：游標顯示值就是實際樣點嗎？不一定，可能是插值或聚合，需回查原始列。
參考：Ignition Alarm Journal：警報來源、時間戳與事件資料。
參考：Ignition Alarm Associated Data：事件屬性、acknowledge與clear時間。
重建完成後由另一位人員用原始查詢條件重做，核對六筆事件的欄位、時間精度、關聯ID與備註文字。若兩次結果不同，先比較時區、資料範圍、快取與查詢排序，再判斷是否是資料變動。不要把畫面目前的排序當成永久且完整的證據；應把匯出檔、查詢版本與產出時間、資料版本與責任人一併保存。