數據有了,但門檻設對了嗎?|GOOD科技報 Newsletter26007
工業物聯網不應只是收集設備數據,更重要的是將數據轉化為可判斷、可預測的決策資訊。AIoT 智慧監測系統整合多元感測器,透過特徵值分析、SPC 智慧門檻及 AI 模型學習,自動建立設備健康模型,分析劣化趨勢並提前預警異常。
翻找歷史資料盲人摸象?
企業物聯網的最大困境:資料海嘯與無效警報
近年來,許多製造業積極導入工業物聯網(IoT),希望透過感測器全面掌握設備狀況。然而,設備連上網並不代表設備變得更智慧,反而讓許多企業陷入另一個更大的困境——資料越來越多,真正能解決問題的資訊卻越來越少。
每天,工廠持續累積數百萬筆振動、溫度、壓力、電流等感測數據,但設備異常依然沒有提早發現。當設備停機時,管理者只能回頭翻找歷史資料;當產線良率下降時,也無法判斷究竟是哪一項設備參數開始偏移。企業投入大量成本建置 IoT,最後卻只是多了一套「會收資料」的系統,而不是能協助決策的智慧工具。
資料越多,異常反而越難找?
更大的問題在於,大多數企業仍然停留在「看數值」的階段,而不是「理解設備」。面對上百個監測點與數十種感測器,每一項數值都有不同的正常範圍,也會隨設備型號、製程條件、環境溫度及負載變化而改變。
若仍採用固定上下限作為異常判斷,不是每天收到大量誤報,就是錯過真正的異常徵兆,最後現場人員逐漸忽略告警,系統形同虛設。
真正困擾企業的,從來不是資料不足,而是不知道哪些資料才真正代表設備健康,也不知道如何建立可信賴的判斷依據。唯有先從大量原始訊號中擷取具有設備意義的特徵值,再建立符合設備運轉特性的智慧門檻,並透過 AI 持續學習設備正常與異常模式,才能讓 IoT 從單純的資料收集平台,真正成為預知保養與設備健康管理的核心。
數據無法真正反映設備狀態?
真正值得關注的從來不是絕對數字,而是速率與行為是否異常。若直接用數值高低判斷,不僅容易誤判,更會錯失劣化徵兆。
我們以為的狀況與機器真實表達的行為
許多人認為,只要設備安裝了感測器,就能即時掌握設備健康狀態。然而,感測器所取得的,其實只是大量的原始數據(Raw Data),這些數值本身並不代表設備是否正常。若直接依照溫度、壓力、振動或電流的數值高低進行判斷,不僅容易誤判,也難以真正發現設備開始劣化的徵兆。
舉例來說,一台馬達的溫度從 40°C 上升到 60°C,乍看之下只是溫度提高了 20°C,但如果這個過程是在 30 分鐘內緩慢上升,很可能仍屬於正常暖機;若相同的溫度變化卻只花了 3 分鐘,就可能代表散熱效率下降、軸承潤滑不足,或機械摩擦開始增加。真正值得關注的不是 60°C 這個數字,而是 升溫速率 是否異常。
同樣的道理也發生在其他感測器上。壓力感測器並非只看壓力大小,而是觀察設備在洩壓或切換製程時的降壓速率是否符合正常模式;位移感測器不只是量測移動距離,更重要的是分析設備是否產生傾斜、偏移或姿態改變;振動感測器也不是將全天候的振動資料全部分析,而是針對設備啟動、停止、搬送、加工等特定動作期間,擷取最具代表性的振動特徵,才能真正反映設備的健康狀態。
因此,智慧設備監測的第一步,並不是直接分析原始數據,而是透過邊緣運算(Edge Computing),將大量且複雜的感測訊號轉換成具有工程意義的特徵值(Feature)。這些特徵值不僅能大幅降低資料量,更能保留真正與設備健康相關的重要資訊,讓後續的智慧門檻與 AI 分析建立在可靠的基礎上。
例如,不同設備會擷取不同的特徵,包括:
• RMS(均方根值):反映設備整體振動能量。
• Peak(峰值):偵測瞬間衝擊或撞擊異常。
• FFT 頻譜分析:能夠找出不平衡、鬆動、軸承損傷等特定頻率特徵。
• 升溫/降溫速率:分析熱變化是否偏離正常模式。
• 升壓/降壓速率:判斷氣壓或液壓系統反應是否異常。
• 傾角與姿態變化:監測設備是否產生偏移或變形。
• 特定動作振動特徵:分析設備在啟動、搬送、加工等關鍵動作的運轉品質。
• 電流波形特徵:辨識負載變化、機械阻力增加或驅動系統異常。
真正能代表設備健康的,從來不是感測器量到的原始數值,而是經過工程分析所萃取出的特徵值。 只有建立在這些特徵值之上,後續的智慧門檻、Health Score 及 AI 學習模型,才能更精準地辨識設備異常、掌握劣化趨勢,真正發揮預知保養的價值。
搜集了數據,卻不會設定門檻?
傳統固定上下限門檻可能會引發大量誤報,現場人員最終選擇忽略系統。投入了大量成本,卻只是買了一套會收資料的儲存庫,無法輔助決策。
沒有正確的門檻,再多數據也無法發揮價值。完成感測器建置與特徵值分析後,企業接著面臨另一個更困難的問題——設備異常到底該從哪裡開始判斷?這也是許多 IoT 專案無法真正落地的原因。
許多設備監測系統在導入後,第一件事就是要求使用者自行設定上下限,例如溫度超過 80°C、壓力低於 5 bar 或振動超過某個數值就發出警報。
然而,大多數企業根本不知道合理的門檻應該是多少。設定過低,設備每天都在告警,現場人員疲於確認,最後乾脆忽略警報;設定過高,真正的設備劣化卻始終沒有被發現,直到停機、良率下降或設備損壞後才知道問題早已存在。沒有合理的門檻,再完整的 IoT 數據,也只是另一套資料收集系統。
SPC 的價值,不是統計,而是建立設備自己的「正常範圍」
最大的困難在於,每一台設備都有自己的運轉特性。
即使是相同品牌、相同型號的設備,受到安裝環境、負載、加工條件、零件磨耗及製程差異影響,其振動、溫度或電流特徵都可能不同。因此,單純套用固定上下限,往往無法適用於所有設備。為了解決這個問題,固德的AIoT系統導入 SPC(Statistical Process Control)統計製程管制概念,自動分析設備正常運轉期間的歷史資料,建立每台設備專屬的正常波動範圍。
系統透過 X-bar Chart、R Chart 等統計方法,自動計算設備特徵值的平均值、變異程度,並建立 UCL(Upper Control Limit) 與 LCL(Lower Control Limit) 管制界限。這代表門檻不是依靠工程師的經驗設定,而是根據設備實際運轉數據自動建立。
這樣的好處是,即使沒有豐富設備經驗,也能快速建立符合設備特性的異常判斷標準,大幅降低人工設定門檻的困難與主觀誤差。
三種智慧門檻,讓不同成熟度的企業都能快速導入
根據不同設備管理需求,平台提供三種門檻建立方式。
① 自訂門檻(Rule Base)
適合已有設備維護經驗或設備商已提供標準規範的應用,由使用者自行設定上下限,快速完成基本監測。
② SPC 統計門檻(Statistical Threshold)
當設備缺乏明確規範或不同設備存在個體差異時,系統會自動建立 X-bar Chart、R Chart 及 UCL/LCL 管制界限,讓每一台設備都擁有屬於自己的合理門檻,有效降低誤報與漏報。
③ AI 智慧門檻(Adaptive AI Threshold)
在 SPC 建立基礎後,AI 持續學習設備健康狀態與運轉模式,隨著設備老化、維修或製程改變,自動調整門檻,使監測結果更貼近設備實際狀況,進一步提升異常辨識能力。
這才是真正的智慧門檻
智慧門檻並不是把固定上下限改成另一組數字,而是建立一套能夠隨著設備特性、歷史數據與健康狀態持續優化的判斷機制。當特徵值分析、SPC 統計管制與 AI 學習三者結合後,設備監測不再只是「超過多少就告警」,而是真正理解設備什麼是正常、什麼開始偏離正常,才能更早發現異常徵兆,落實預知保養。
AI 真正學習的是設備運轉模式
完成特徵值擷取與智慧門檻建立後,真正發揮價值的,才是 AI 的學習能力。
許多人認為,AI 只是把大量感測器數據丟進模型,再由 AI 判斷設備是否異常。然而,真正的設備 AI 並不是學習數值,而是學習設備在不同工況下的正常運轉行為(Operating Behavior)。
換句話說,AI 並不是看到溫度 60°C、振動 1.2 mm/s,就直接判定設備故障。因為相同的數值,在不同設備、不同製程、不同負載甚至不同季節,都可能代表完全不同的狀態。
真正的 AI,是持續觀察設備在啟動、加速、穩定運轉、負載變化、停止等各個階段的完整運轉模式,分析不同特徵值之間的關聯性,建立屬於每一台設備的健康模型。
例如,一台設備在正常運轉時可能呈現以下特徵:振動 RMS 維持在固定範圍、溫度會在 15 分鐘內逐漸上升並趨於穩定、電流與負載呈現固定變化關係、壓力在切換製程時,以固定速率下降、FFT 頻譜能量集中於特定頻率。
AI 學習的並不是這些數值本身,而是這些特徵彼此之間長期形成的「正常行為模式」。
AI 真正找的是「偏離」,而不是「超標」
設備故障通常不是某一個數值瞬間超過門檻,而是多項特徵在很長一段時間內開始慢慢改變。 例如:振動增加只有 5%、電流增加 3%、溫度升溫速度變快、FFT 側頻開始出現、Health Score 持續下降。
如果單獨來看,每一項都可能仍在正常範圍內,因此傳統固定門檻完全不會發出警報。
但是 AI 會發現:這些特徵正在一起改變。這代表設備的運轉模式,已經開始偏離它過去數千次正常運轉所建立的模型。也因此,AI 可以在設備還沒有停機、沒有產生告警,甚至沒有影響產品品質之前,就提早辨識設備開始劣化的徵兆。
AI 的價值,不是告訴你設備壞了,而是告訴你設備開始改變了
當 AI 持續累積每一次設備運轉資料後,它會不斷修正健康模型,重新理解設備目前的健康狀態。
因此,它不只是判斷設備是否異常,而是能夠持續回答更重要的問題:
• 目前設備健康是否正在下降?
• 劣化速度是否開始加快?
• 哪一項特徵變化最快?
• 是否需要提前安排保養?
• 如果維持目前運轉條件,設備還能正常運作多久?
這也是 AI 能夠進一步提供:Health Score(設備健康評分)、設備劣化趨勢分析、異常風險預警、Remaining Useful Life(RUL)剩餘可用壽命預估。 讓企業從過去的故障後維修(Reactive Maintenance),逐步轉向預知保養(Predictive Maintenance)。
Dashboard 不只是看數據,而是快速找到需要關注的設備
對於一座工廠而言,同時監測數十台甚至數百台設備,每天可能產生數十萬甚至數百萬筆感測資料。如果仍然需要逐一查看每個感測器、每條趨勢線或每項特徵值,不僅耗時,也難以及時發現真正需要處理的設備。
因此,智慧物聯平台將所有監測資訊整合至同一個 Dashboard,讓管理者不再只是「看數據」,而是先找到問題,再深入分析問題。 平台可同時呈現:設備健康總覽、多感測器即時數據、特徵值分析結果、SPC 管制圖、Health Score 健康評分、AI 劣化趨勢、異常告警事件、歷史紀錄與分析。
管理者每天不需要花時間巡視所有設備,只需打開 Dashboard,就能立即知道哪些設備健康正常、哪些設備開始出現劣化趨勢,以及哪些設備需要優先安排點檢或保養,大幅提升設備管理效率。
Health Score:把上百個數據變成一個人人看得懂的分數
真正困擾設備管理人員的,不是沒有資料,而是資料太多,不知道該看哪一個。
以一台設備為例,可能同時監測:振動、溫度、電流、壓力、位移。每一種感測器又會衍生出 RMS、Peak、FFT、升溫速率、降壓速率、傾角等數十項特徵值。 當所有資料同時出現在畫面上,即使是經驗豐富的工程師,也需要花不少時間交叉比對才能判斷設備是否正常。
因此,平台透過 AI 將所有特徵值、SPC 分析結果及設備運轉模型整合後,轉換成一個直觀的 Health Score(設備健康評分)。
就像人每天做健康檢查,不需要先看血糖、血脂、肝功能或心電圖,而是先知道整體健康狀況是否正常。如果健康分數下降,再進一步查看是哪一項檢查出現異常。設備管理也是相同的概念。舉例來說:假設工廠有 100 台馬達。 過去,每天都需要查看:100 張振動趨勢圖、100 張溫度曲線、100 張電流圖、100 張壓力圖。即使全部看完,也未必知道哪一台設備最需要優先處理。
現在,Dashboard 首先呈現 Health Score:
管理者只要幾秒鐘,就能知道真正需要關注的是 D21。
接著再點進 D21,便能看到:振動 RMS 持續增加、FFT 開始出現軸承特徵頻率、升溫速度比過去快 20%、SPC 已接近 UCL、AI 判定設備健康持續下降。
這時,工程師不再需要從幾十萬筆數據開始找原因,而是直接掌握設備健康變化與可能的異常來源。Health Score 的價值,不只是「分數」。Health Score 並不是一個漂亮的數字,而是設備健康狀態的濃縮結果。它將原本需要工程師花費數十分鐘甚至數小時分析的大量資料,濃縮成一眼就能理解的健康指標,讓設備管理從「閱讀數據」,轉變為「管理風險」。
管理者每天關心的不再是數百萬筆感測數據,而是:
• 今天哪些設備開始變差?
• 哪些設備需要優先維護?
• 哪些設備還能安心持續運轉?
這才是 Dashboard 與 Health Score 最重要的價值,也是智慧設備管理真正希望解決的問題。
AI 預測,不是預測故障,而是預測設備正在走向故障
許多人認為,AI 預測就是告訴管理者「設備什麼時候會壞」,但真正的設備 AI 並不是預言未來,而是持續觀察設備健康如何變化,從細微的劣化趨勢中,提早辨識異常正在形成。
一台設備真正故障之前,通常不會只有一項數據突然超標,而是許多看似微小的變化同時發生。因此,平台不只是告訴管理者哪一項數值超標,而是持續分析設備健康趨勢,預測設備未來可能的劣化方向,並提前發出預警。企業便能在生產排程允許的時間安排維修、更換零件或調整製程,而不是等到設備突然停機後才緊急處理。
這也是 AIoT 智慧監測真正的價值。
從感測器取得原始訊號開始,系統先透過邊緣運算萃取設備真正重要的特徵值,再利用 SPC 建立符合每台設備特性的智慧門檻,接著由 AI 持續學習設備正常運轉模式,分析 Health Score 的變化與劣化趨勢,最終將原本難以理解的大量數據,轉換成可直接採取行動的維護建議。從「資料(Data)」到「資訊(Information)」,再到「決策(Decision)」,這才是 AIoT 與傳統 IoT 最大的差異。
傳統 IoT 解決的是「設備有沒有資料」;真正的 AIoT 解決的是「企業知道下一步該怎麼做」。當系統能理解設備健康、辨識異常徵兆、預測未來風險,維護策略便能從故障後維修(Reactive Maintenance)進化為預知保養(Predictive Maintenance),管理者不再只是看到設備運轉,而是真正掌握設備未來的健康走向。讓每一筆設備數據,都成為更精準決策的依據,而不只是儲存在資料庫中的數字。


留言
張貼留言