預測性維護 AI 落地劇本:用感測器資料把非計畫停機降低 30% 的完整流程

先講一個現場。去年冬天,我們進到一家中部的金屬沖壓廠,產線上有六台油壓機,其中兩台是全廠的瓶頸。廠長最頭痛的不是良率,是那種「早上開機才發現主軸抱死」的非計畫停機——一次少則四小時,多則整班報廢,連帶下游訂單全部往後推。他們不是沒買過方案。兩年前導入過一套振動監測,裝了、也亮燈,但沒人看,因為每天誤報三、四次,大家索性把告警關了。

這篇就是把「預測性維護 AI」從一台機、一組感測器,一路推到上線、有人真的在用的完整劇本。不是理論,是我們踩過雷後留下的流程。

先搞清楚:預測性維護 AI 到底在預測什麼

一句話定義:預測性維護 AI 是用機台的感測器資料(振動、電流、溫度、聲學、油壓),學習設備從正常劣化到故障的軌跡,在故障發生前給出「還剩多少時間」與「該修哪裡」的判斷。 它跟傳統的定期保養不同——定期保養是「不管壞沒壞,到期就拆」,浪費;事後維修是「壞了才修」,停機。預測性維護要打的,是中間那條線。

關鍵認知:它不是先進到需要換掉整條產線的技術,而是一套資料工程加上建模的紀律。難的從來不是模型,是資料和採用。

第一步:別急著全廠上,先挑一台會痛的機台

我們的第一動作永遠是坐下來跟維修班長算帳,不是裝感測器。挑試點只有一個標準:這台機停一小時,老闆會不會心痛。瓶頸機台、單點故障、又有維修歷史紀錄的,最理想。前面那家廠,我們只選了兩台油壓機當試點,把「降 30% 非計畫停機」這個目標綁死在這兩台上,而不是空泛地說「導入 AI」。

盤點資料時,九成的廠會發現同一件事:過去的故障根本沒被結構化記錄。維修單寫在紙上、或塞在 ERP 的備註欄,「異音更換軸承」六個字,沒有日期對應的感測讀值。這件事先講清楚——沒有標好的故障案例,模型就沒有東西可以學。

第二步:感測與資料管線,PoC 和上線是兩回事

這是最多專案陣亡的地方。PoC 階段大家用一台筆電、一顆 USB 振動計,跑得漂亮;要上線時才發現,現場根本沒有網路,PLC 是十年前的協定,資料一斷三天沒人知道。下面這張表,是我們對每個階段的實際要求:

我們在那家廠花在資料管線的時間,是花在建模時間的三倍。這很不性感,但這才是專案能不能活下去的分水嶺。

第三步:模型要給「可行動的判斷」,不是分數

一個 0.87 的異常分數,對維修師傅毫無意義。他要的是:「三號機主軸軸承,預估 8 到 12 天內劣化到需停機,建議下次計畫保養一併更換。」我們把模型輸出綁在維修工單的語言上——剩餘壽命、部位、建議動作、信心區間。閾值不是我們拍板,是跟班長一起校準:寧可漏報一次小異常,也不要每週吵醒他三次。誤報一旦超過忍耐線,系統就死了,這是我們用第一個失敗案例換來的教訓。

第四步:交接才是真正的上線

Demo 很美不算數,上線且有人在用才算數。我們判斷專案成功的標準,從來不是模型準確率,是三個月後維修班長還會不會自己打開那個看板。所以最後一段時間,我們做的是很土的事:把告警接進他們原本就在用的 LINE 群組、寫一頁「看到黃燈該做什麼」的處置卡、陪班長跑完兩個完整的預警到保養循環,直到他不需要我們也能判讀。

那家沖壓廠的結果:六個月後,兩台試點機的非計畫停機時數,從季度 46 小時降到 31 小時,降幅約 33%。誤報從每天三次壓到每週不到一次。更重要的是,維修班主動要求把第三、第四台也接上——採用發生了,擴機才有意義。

收尾:模型是最容易的部分

如果你正在評估預測性維護 AI,我最想提醒的是:別被 Demo 的準確率迷惑,先問「三個月後誰會打開它」。真正決定成敗的是資料管線的韌性、閾值的克制,以及有沒有人把它揉進現場既有的工作流。

我們在 Tenten 的做法,就是派工程師進場蹲在產線邊,把這套劇本從試點機一路扛到交接,而不是丟一份報告就走。因為讓一家工廠真的少停一次機,遠比讓 Demo 好看,難得多,也值得多。