先定義要預測的事件與可採取的行動
專案起點不應是「收集所有感測器資料」，而是把目標寫成工程上可驗證的問題：要預測的是軸承劣化、馬達過熱、幫浦效率下降，還是任何會造成停機的異常？不同目標需要不同資料、時間尺度與標記方式。把多種故障合併成單一「異常」類別，雖然容易開始，卻可能產生無法對應維修措施的警報。
還要先決定預警必須提前多久才有價值。若備品需要安排、設備只能在換線時停機，就需要較長的預警窗口；若控制系統能立即降載，較短但更準確的警報也可能足夠。預警時間越長，早期徵兆通常越弱，誤報風險也越高。因此，模型目標應與維修流程、排程限制及現場可執行的處置一起設計。
建立涵蓋設備、製程與維修的資料層
單看振動、溫度或電流通常不足以判斷設備健康。相同的訊號變化可能來自故障，也可能只是轉速、負載、產品配方或環境改變。實務上需要把感測資料與控制狀態、生產條件及維修事件放到同一條時間軸，才能讓模型區分正常工況切換與真正的劣化。
- 設備識別與結構：固定的設備、機台、子系統與零組件 ID，以及感測點和零件之間的關係。更換馬達或感測器時也要保留版本與生效時間。
- 感測器訊號：振動、溫度、壓力、流量、電流、電壓、聲學或油品資料，並記錄單位、量測範圍、取樣頻率、校正狀態與缺值原因。
- 控制與運轉狀態：啟停、待機、警報碼、轉速、設定值、閥門位置、控制模式及 PLC 狀態。這些欄位常是切分有效分析區段的關鍵。
- 製程與環境條件：產量、負載、配方、批次、班別，以及環境溫濕度等可能改變訊號基準的因素。
- 維修與事件紀錄：報修時間、故障確認、檢查結果、更換零件、處置內容、復機時間與技師備註，而不只是工單結案日期。
取樣頻率應依故障機制決定。振動波形可能需要高頻資料，但將所有原始波形永久上傳雲端會增加頻寬、儲存與治理成本；溫度或壓力趨勢則常不需要同樣的解析度。可在邊緣端保存事件前後的原始波形，平時上傳頻域、峰值或統計特徵，但必須保留特徵算法版本，避免日後無法重現。
時間品質與資料情境比資料量更重要
各來源的時間戳必須能被可靠對齊。PLC、IoT 閘道器、雲端平台與維修系統可能使用不同時區、不同時鐘，網路中斷後也可能補傳資料。如果只依資料抵達時間排序，故障前的訊號可能被錯放到故障後。建議保存設備事件時間、接收時間與時區，監控時鐘偏移，並明確定義延遲資料的處理規則。
缺值、固定值與突波不應一律補值或刪除。它們可能代表通訊失敗、感測器脫落、設備停機，也可能正是故障徵兆。資料管線應另外產生品質旗標，保留原始值，並區分計畫停機、非計畫停機與未知狀態。模型訓練時可排除不可信區段，但營運端仍要能辨認「無法判斷」而不是把資料缺失當成設備正常。
把維修紀錄轉成可稽核的故障標記
故障標記至少要回答故障類型、影響零件、首次可確認時間、實際停機時間、處置方式與復機時間。工單的建立或結案時間只是行政事件，不一定等於故障開始或修復完成。若現場只能確定一個時間範圍，應保存範圍與信心等級，不要製造看似精確的單一時間點。
- 已確認故障：有檢查結果、零件損壞或明確故障碼支持，可作為較高可信度的正樣本。
- 預防性更換：零件被換掉不代表已經故障，應與故障維修分開標記，並記錄更換原因。
- 未發現異常：警報後檢查正常，可用於分析誤報，但不能直接推論整段設備歷史都是健康資料。
- 原因不明或複合故障：保留未知、主要原因與伴隨原因，避免為了訓練方便而強迫歸類。
- 維修後觀察期：只有在設備回到穩定工況並完成必要驗證後，才能視為新的健康週期起點。
建立訓練資料時，可依事件向前定義預警窗口，並排除維修中、啟停過渡與標記不確定的區段。切分訓練與測試資料應以時間、設備或維修週期為單位，避免同一故障前後的高度相似資料同時出現在兩邊。否則離線結果會很好看，上線後卻無法泛化。
用資料就緒檢查決定是否開始建模
在訓練模型前，團隊應先完成幾項檢查：目標故障是否有一致定義；設備與零件 ID 能否跨系統對應；關鍵訊號是否涵蓋正常、異常與不同負載；時間戳是否可信；維修結果能否追溯；上線時能否取得與訓練時相同的欄位。若答案多半是否定的，先改善資料採集與工單流程，通常比更換模型更有效。
第一版可以從少數關鍵設備與一種可確認的故障模式開始，建立資料字典、標記規則與回饋流程，再逐步擴充。評估時除了模型指標，也要檢查每台設備的警報頻率、可用預警時間、未知狀態及維修人員是否能理解警報依據。預測性維護的交付物不只是模型，而是一套能持續取得證據、修正標記並連結維修決策的系統；若資料散落在 PLC、IoT、ERP 與工單平台，整合團隊的首要工作也應是建立這條可追溯的資料鏈。