導讀：2012年伴隨“工業4.0”概念的出現，工業大數據能夠創造更大的潛在商業價值，核心就是將工業技術與IT技術進行結合，以挖掘工業大數據的價值。本文主要從工業設備的預測性維護（Predictive Maintenance），文中簡稱（PdM）這一角度出發展開詳細介紹。

全文將會圍繞下面五點展開：

PdM價值及發展歷程

PdM的常見技術路線

PdM時序數據庫選型

PdM案例與價值故事

一點思考

01PdM價值及發展歷程

1. PdM的主要價值

①減少事故，減少故障停機

保障卡特彼勒300萬設備在線。

日立故障預警率可達58%。

GE在風電和火電這兩個領域，被動維護減少10%-40%，可利用率提升2%-6%（可利用率每提升1%，可帶來上萬戶家庭1年的用電量）。

②降低維護成本

GE降低維護服務負荷40%，降低維護成本10~40%。

徐工故障率降低了一半。

③商業模式轉變

以GE為例，早先的商業模式是產品制造商，20世紀80年代中期轉變成為客戶提供服務導向的整體解決方案。比較直觀的理解就是從單純賣發動機這個實體，變成了賣可以保障穩定運行 1000KM 的發動機這樣帶有業務價值的實體。這其中 PdM 占據了舉足輕重的地位。

對于風電行業，在 PdM 的支持下，可以將商業模式從賣風機轉變為賣發電量。打破了產品本身因為制造能力擴張和過剩導致的利潤轉移的約束。

2. PdM 的發展歷程

PdM 是工業設備維護歷經百年后的終極產物，發展歷程如下：

①事后維護

早期的設備維護都是事后維護，即事故或故障發生后才維修。

這種維護方式屬于被動維護，成本高，效率低。

②預防性維護

根據設備廠商的建議以及現場人員的經驗，定期進行維護。

雖然相較于被動維護有了很大的進步，然而對于運行完好的設備，過多次數的維護會顯得冗余且意義不大，而且人工維護也難免造成細節的疏漏，因此這種維護方式依然存在成本較高和效率較低這類問題。

③基于狀態的維護

基于設備運行狀態的實時監控，并結合設備機理模型，在性能評估異常時主動維護。

這種維護方式較為先進，然而仍然免不了突發故障停機的風險。

④PdM

基于數理統計、數據挖掘模型，對初期部件故障預測及定位，指導設備維護工作。

這種維護方式，可以在故障未發生時提前介入，最大程度地避免故障及事故的發生。

02PdM的常見技術路線

基于前文所述，PdM的技術路線部分主要會詳細介紹基于狀態的維護和PdM 這兩個部分，主要技術涵蓋大數據、物聯網以及人工智能等諸多方面；基于狀態的維護又被稱為故障診斷，PdM 又被稱為故障預測。

1. PdM常用技術路線

業內常用4種方法：

①信號處理

主要是基于IoT高頻采集信號，使用時域、頻域、包絡、小波分解等經典方法，對測量信號和噪聲進行分析。

該方法無需對數據進行訓練，且分析結果準確性高，方法成熟度高，在業內的使用超過50%。

然而從工程應用的角度看，傳感器具有較高的安裝和維護成本，且難以覆蓋全面測點，因此該方法的適用范圍具有較大的局限性。

②機理 + 大數據

對于成本較敏感的行業（例如工程機械領域），可以使用機理建模方法，結合大數據方法進行分析。

首先建立基礎的機理模型（例如氣動方程、液壓動力方程等），通過采集關鍵信號（例如轉速、壓力、電壓、電流等），從而擬合方程中的參數。

該方法可解釋性強，結果準確性高，且不易出現過擬合現象，不過機理建模的過程具有挑戰性。

③數字孿生

數字孿生方法，擺脫了前兩種方法對于機理的依賴。

該方法基于歷史運行數據，通過一系列相似性模型構建設備的基準狀態（baseline）并進行預測；將預測的結果與設備的實時運行狀態進行對比，對狀態偏移進行預警。

該方法是一種自適應的建模方法，可解釋性弱于機理模型，且需要一定的技術門檻。

④AI

最后一種方法是使用AI領域的一些技術（例如機器學習、深度學習、CV、NLP等方法）。

該方法場景清晰且易得，圖像所見即所得，然而該方法可解釋性差，且容易過擬合。

綜上所述，機理+大數據的方法和數字孿生方法，應該會成為未來的趨勢。

2. 信號處理

針對一臺工程機械，以大軸承為例，長期運轉會不可避免地帶來一些損壞。通過采集振動信號（如圖所示，采集了4路振動信號），通過傅里葉變換、EMD、小波、包絡等方法進行信號分解得到某時段內的時頻譜；通過分析信號的頻域特征，來推斷軸承在什么時段可能會出現問題。

3. 機理+大數據

以某液壓系統為例，左下圖中的紅色直線為該液壓系統的基準線，然而事先并不知道斜率、截距等參數的具體取值；此時可以基于樣本數據進行擬合，以推測出實際的參數值。如果設備運行良好，則散點應該集中分布在擬合直線的周圍；圖中列舉了兩種擬合不理想的情況：左圖中，由于參數控制不當，圖的右側出現了“死區”，右圖中，由于系統出現內泄，直線和紅線的趨勢產生了差異（說明在高壓和低壓狀態下系統的特性是有所不同的）。基于此，我們可以通過斜率的絕對值與原廠的油泵特性理論值對比判斷油泵整體效率，再通過高低壓模式差異值反應液壓系統內泄程度（性能退化程度）。

使用機理+大數據這種方法可以很大程度地減少對數據標簽的依賴。

4. 數字孿生

（1）數字孿生介紹

數字孿生是個很寬泛的概念，這里所講的數字孿生，主要是基于國際標準ISO23247/TC184工作組定義的數字孿生，包括數字孿生體和數字線程兩個部分。數字孿生體是在虛擬空間構建的表征物理實體或業務過程實時運行狀態的虛擬體，數字線程是連接物理世界和數字孿生體的通道。

通過設備的原理和運行數據，將數據給到模型，模型通過自我學習和動態調整將分析結果輸出到終端軟件中，由終端軟件控制和反饋物理對象和業務過程，最終形成閉環。上述閉環以數據為基礎，以模型為核心，以軟件為執行載體，這是數字孿生的主要實現手段，而實現閉環的鏈路通道就是我們常說的數字線程。

（2）使用數字孿生實現PdM

基本步驟如下：

歷史數據準備

數據預處理

特征提取/分析

異常分析/特征標注

模型啟用

對象狀態評估

模型優化

異常預警

健康度/穩定趨勢分析

相比機理建模或參數特征建模，該方法可節省50%以上時間。

（3）數字孿生PdM 技術原理

在數字孿生PdM 領域，常用的方法是相似性模型。

傳統方法的故障預警是預先設定報警閾值，一旦監控到數據超過閾值，就會發出警報；然而這種方法存在滯后性，即發出警報的時刻設備已經故障了，因此即使報警也無法避免設備的停機甚至損壞。更好的方法是將這個固定的閾值轉化成動態的閾值，不同時刻、不同工況下，監控信號的報警閾值都是動態變化的，這樣就可以基于設備的不同運行工況進行實時報警。

基于數字孿生的PdM ，主要包括異常識別（預測模型）和故障推導（故障機理）這兩個部分。

可以拿我們自身做一個形象地比喻：我們在跑100米的時候會有一個正常范圍的心跳值。同樣，在跑1公里、跑20公里的時候，以及在安靜狀態甚至睡眠狀態下，分別會有不同的心跳范圍。基于過去半年或者一年累計的數據進行統計，可以推算出當今某種特定狀態下（例如跑200米）身體的機能是否和往年比有所下降，進而而可以判斷出自己身體的是否健康。

因此，基于數字孿生做PdM 的核心思想是：

收集豐富工況下物理對象的狀態矩陣，并將它們匯聚成基準狀態空間，即為數據驅動的數字孿生模型。

此模型能夠根據當前工況，預測出這個工況下狀態“應該”是怎么樣的，通過它與現實狀態的偏差識別異常（即異常識別）。

根據異常指標的組合，結合專家知識，判定可能的異常根因和應對方法（即故障推導）。

03PdM時序數據庫選型

1. 原始需求

基于上述方法在IoT方向上做PdM ，無論是汽車行業還是工程機械、批量機械設備等方向，都會涉及大量設備的監測和分析；因此，如何在海量數據中應用上述方法對設備進行PdM，并精準分析出每臺設備的分析結果，都是一項具有挑戰性的工作。

例如，針對以下場景：

①對某現場2W臺設備進行維護

②每天會產生100~200G的數據量

③Kafka消費每秒可達1.5W條

④通常涉及低頻大查詢和高頻小查詢

大查詢：每臺車有200個指標，每個指標都要跑。

實時小查詢：例如挖機，需要實時查看我的挖機的工作量。

⑤往往需要進行周期性滾動計算

⑥每臺設備每天進行超過500個指標的計算

⑦涉及5類，累計超過20個算法模型

⑧算法邏輯往往通過python開發實現而不是SQL

2. 數據庫選型——窄表vs寬表

基于以上原始需求，帶來了一個核心問題——使用窄表存儲還是寬表存儲。從運維人員的角度考慮，使用窄表會更加便于維護，因為窄表的列名是固定的，不會發生改變；從業務應用的角度考慮，使用寬表會使業務語義更加清晰，可以快速獲得某一特定指標的某一段時間的數據。

從存儲角度來看：

行列混合存儲，可以對數據進行壓縮，對分析查詢更加友好。

同一類型的數據放在同一個列中，有利于數據壓縮。

同一個設備的數據，按時間順序存儲在一個block內，對設備的分析查詢和向量化來說更加友好。

基于以上需求，通過調研，對比了常用的PostgreSQL、GreenPlum、MatrixDB、TD-Engine等數據庫的優劣，最終選擇了MatrixDB作為存儲工具，可以實現2W臺設備，每天100~200G的數據量，每臺設備每天進行超過20個算法模型、超過500個指標的計算分析需求。

3. MatrixBD數據庫使用效果

MatrixDB數據庫是個超融合數據庫：

支持HTAP。對于導入數據庫的數據，既可以做實時查詢，也可以做離線OLAP分析。

支持 plpython 編程。實現了數據庫維護工作和算法開發工作的解耦，大大提高了算法開發的效率。

Nifi組件入庫速度比GP快3-4倍，1.5萬條/秒無壓力。

Plpython+UDF 的效率更高。例如：按編號分布，按天分區，全天巡檢從(Hadoop+hive+spark+orc) 6小時降低到30分鐘。

原生 Python 兼容，融入于SQL語句中實現分析。

內存數據庫緩沖實時數據，結合離線數據實現HTAP。

04PdM案例與價值故事

1. 堵管問題分析

無論是數據庫的提供方，還是作為使用數據庫的甲方，甲方會關心收益。因此，PdM需要更多地聚焦在客戶的痛點上，抓住要點，給客戶提供看得到的價值，客戶的問題會逐漸得到解決。

2. 故障問題線下閉環

05一點思考

無論企業規模大小，制造業的數字化轉型人才大多來自互聯網，首先帶來的必然是互聯網的最佳實踐：圍繞Hadoop + Spark + HIVE 等搭建生態，這是第一層認知。

轉型初期，上述生態的確可以承載企業急需解決的部分數字化的問題，比如“研產供銷服”對應的業務數據的打通、各種KPI的計算、BI類的報表等，解決一部分問題，這是第二層認知。

當轉型進入深水區，比如在研發側，公司研發的設備客戶哪里不滿意，我需要怎樣的改進，改進的效果如何？在生產側，我的生產管理流程如何優化，我如何提升工廠生產的各類指標？當我們面臨這些問題時，才發現，每一個問題都需要分析海量的數據，并且分析的方式再也不是統計、聚合類的，而是要結合工業機理的，甚至是要逐條地分析，基于Hadoop的那套生態幾乎徹底不能承載我們快速開發算法、調度算法的性能需求。此時，公司面臨的將是要么不斷貼膏藥勉強維持，要么再斥巨資引入適應這些需求的IT技術，這是第三層認知。

令人遺憾的是，大多數先驅公司都是從第1條慢慢往后演進的，不過同樣令人欣慰的是，也有越來越多的人看到這個過程，在業務初期就嘗試運用像MatrixDB這樣的跨界產品來一站式解決問題。

06問答環節

Q：為什么TDengine+Spark不是最優選擇？

A：TDengine需要用Spark集群做分析，而Spark從數據入庫到分析，存在諸多的不穩定性。而使用Hadoop+Spark的方式，要比使用MatrixDB分析效率慢7-10倍。

Q：在工業領域，除了時序數據，是否還有其他數據類型和時序數據協同分析？

A：在PdM 方面，大部分還是來自IoT時序數據；在一些極端情況下，會有描述設備本身標識的維度數據，比如設備的每個子系統、每個零部件的供應商、編號、部件特性等的維度數據。這類數據作為關系型數據庫，可以被兼容到MatrixDB這樣的超融合數據庫中。

Q：頻域能否做PdM 研究？

A：雖然在風電等領域，頻域分析仍占半壁江山。但是由于其成本的原因，其擴張速度正在收斂，甚至呈現出下降的趨勢。隨著成本競爭日趨激烈，很難大規模部署傳感器；另一方面，從存儲成本角度考慮，也很難支持大量1kHz甚至10kHz這類高頻數據上云。因此，在物聯網、大數據領域，更多地會使用機理+大數據，以及數字孿生這兩種方式進行PdM。

Q：是否分析過 IoTDB 或者 MatrixDB 結合 model in 將數據下載做離線計算？

A：這方面沒有具體嘗試。不過只要是先將數據下載進而離線分析計算，這類工作都會增加工作的難度，降低工作的效率。團隊之所以放棄Hadoop+Spark的方式，正是因為這類方式需要預先下載數據進而分析計算。分析和存儲查詢分離的方式，一般會出現大量的數據遷移，通常情況下會降低分析的效率。

Q：工業時序領域哪些時序類函數是強需求？例如異常檢測、預測類算法等，如果集成在數據中，開發效率會不會更友好？

A：工業領域的數據分析和互聯網領域存在截然的不同：工業數據分析，很難用一個公式解決大量設備通用問題。信號處理方法在一定程度上可以解決一大類通用問題的分析，但是采樣率要求很高，因此會帶來成本的增加，從而導致適用范圍的局限性；因此，大部分企業會使用機理+大數據，以及數字孿生這兩種方式，而這兩種方式不具備通用性，對于不同設備甚至同一設備不同型號，機理模型都會發生變化。因此，工業領域的機理模型或者數據模型，很難得到抽象的、通用的、能夠注入到數據中的模型；因此通常做法是先獲取相關數據，進而通過不同的嘗試，最終確定模型。