預測性維護 AI：在本地端準備感測器與文件資料

預測性維護承諾以基於狀態的維護取代計劃性維護——只在設備真正出現退化跡象時才介入，而非按任意的日曆間隔進行。實現這一目標的 AI 模型需要結合感測器讀數（振動、溫度、壓力、電流）和維護記錄（故障內容、原因及處理措施）的訓練資料。

準備這些訓練資料比聽起來更難。感測器資料和維護日誌存在於不同的系統中，使用不同的格式，由不同的團隊管理。在本地端、在氣隙製造環境中，將它們整合成統一的訓練資料集，需要一個周密的資料準備管道。

兩個資料流

感測器時間序列資料

製造設備持續產生感測器讀數：

振動感測器：加速度、速度、位移——軸承和旋轉機械健康狀況的主要指標
溫度感測器：軸承溫度、電機繞組溫度、工藝溫度
壓力感測器：液壓壓力、氣壓、冷卻劑壓力
電氣感測器：電機電流、電壓、功率因數——電氣和機械負載的指標
流量感測器：冷卻劑流量、潤滑劑流量、工藝材料流量

這些資料通常以每秒一次到每秒數百次的採樣率存儲在歷史資料庫中（OSIsoft PI、Aveva、InfluxDB）。資料量相當可觀——一台具有 20 個感測器、以 1Hz 採樣的機器每天產生 170 萬個資料點。

維護記錄

維護日誌記錄了設備發生的事情：

工單：計劃和非計劃維護活動的結構化記錄
技術員備注：對症狀、觀察和採取行動的自由文本描述
故障報告：將故障與促成因素聯繫起來的根本原因分析
零件更換記錄：更換了什麼、何時更換、為何更換
設備手冊：製造商維護程序和故障模式描述

這些資料通常存儲在電腦化維護管理系統（CMMS）中，如 SAP PM、Maximo 或 Fiix——而自由文本欄位是真正智慧所在之處。

資料準備的挑戰

時間序列與事件的對齊

核心挑戰：將感測器模式與維護結果連接起來。3 月 15 日的振動峰值需要與 3 月 17 日的軸承更換相連接，才能創建帶標籤的訓練範例。

這種對齊需要：

時間戳同步：歷史資料庫和 CMMS 之間（它們通常使用不同的時區或時鐘來源）
事件窗口化：定義故障前的時間窗口，即構成「故障前」模式的時間（幾小時？幾天？幾週？）
正常 vs. 退化：標記哪些感測器窗口代表正常運行，哪些代表逐漸退化
多種故障模式：相同設備可能以不同方式發生故障，每種方式有不同的感測器特徵

從維護日誌中提取智慧

技術員備注以非結構化形式包含關鍵資訊：

「檢查了 3 號生產線的壓力機電機。運行時發現異常振動。更換了上軸承總成。發現內圈有明顯磨損。可能是上個月冷卻劑洩漏造成的污染。」

從這條備注中，受過訓練的維護專業人員能提取：

故障模式：軸承磨損
根本原因：冷卻劑污染
設備：3 號生產線壓力機電機
部件：上軸承總成
嚴重程度：嚴重（需要更換）

沒有維護經驗的 ML 工程師會錯過冷卻劑洩漏和軸承故障之間的因果鏈。這就是為什麼領域專家標記至關重要。

處理類別不平衡

設備故障（希望）是罕見事件。在健康的製造運營中，95-99% 的感測器讀數代表正常運行。預測性維護需要檢測的故障模式僅佔剩餘的 1-5%。

訓練資料準備必須解決這個問題：

對故障窗口進行過採樣
為罕見故障模式生成合成資料
謹慎的窗口化，以最大化對退化資料的使用（故障前的逐漸衰退比故障時刻本身更有用）

管道

第一步：感測器資料導出和清理

從歷史資料庫導出相關時間範圍的資料（通常每台設備 6-24 個月）
如果感測器採樣率不同，重新採樣到一致的間隔
處理缺失資料（感測器中斷、歷史資料庫空缺）
刪除由感測器故障引起的異常值（不是設備問題）
跨不同感測器類型和量程進行標準化

第二步：維護記錄處理

從 CMMS 導出工單和技術員備注
解析自由文本欄位以獲取故障模式、根本原因、部件和嚴重程度
標準化術語（不同技術員以不同方式描述相同的故障）
將維護事件映射到與感測器資料匹配的設備識別符
為每台設備建立維護事件時間線

第三步：資料融合

將感測器時間序列與維護事件時間線對齊
創建帶標籤的窗口：「正常」（之後無維護事件）、「故障前」（N 天內有維護事件）、「維護後」（最近完成維護）
將維護上下文附加到感測器窗口（故障模式、根本原因）
創建結合感測器統計（均值、標準差、峰值、RMS、頻率特徵）和設備元資料的特徵向量

第四步：標記和驗證

維護工程師驗證感測器模式與故障事件之間的對齊
領域專家審查邊緣案例：這真的是故障，還是計劃性維護？感測器讀數是真實的，還是測量偽影？
在設備記錄支持的情況下，標記剩餘使用壽命（RUL）

第五步：導出

用於時間序列分類模型的結構化資料集
用於傳統 ML 模型（Random Forest、XGBoost）的特徵矩陣
用於 LSTM/Transformer 模型的序列資料
用於模型可解釋性的感測器到故障映射文件

為何必須在本地端進行

預測性維護資料準備有三個嚴格的本地端處理要求：

OT 網路隔離：感測器資料存在於操作技術網路上，通常與 IT 網路和互聯網氣隔
商業機密保護：設備配置、工藝參數和故障模式是競爭情報
資料量：來自數百台機器的高頻感測器資料，時間跨度數月，對實際雲端傳輸而言過於龐大

資料準備工具必須在這些限制內工作——完全離線，在本地基礎設施上，無需任何雲端依賴。

Ertas Data Suite 正是為這種環境設計的：一個原生桌面應用程式，在氣隙環境中運行，處理結構化感測器資料和非結構化維護日誌，並導出適合預測性維護模型的格式。介面對了解設備的維護工程師和可靠性專業人員都能輕鬆使用——而不僅僅是了解算法的資料科學家。