一、何為智慧運維 ？
生產裝置/裝備是工業的重要生產工具，其可靠性、效能對工業生產有重大影響。隨著工業大資料推進，裝置的智慧運維被定義為一個重要的應用領域。但何為智慧運維？目前還沒有一個明確的定義，但有不少提法，我們將其初略歸納為4種模式：
智慧決策，如預測性維修、故障診斷等PHM、運維運作優化；
智慧裝備，將雲端分析結果直接作用到端（如感測器偏差矯正）；
新業務模式，如共享備件庫存等；
結合其他新興技術的新能力（如基於無人機的自動巡檢、基於AR的協同運維）。
智慧運維運維只所以很難給出一個明確定義，是因為運維業務涉及的維度複雜性。下圖我們從業務使用者、過程環節和業務目標3個維度去描述，不同維度組合決定了智慧運維的內涵的不同。我們可以廣義認為只要能夠提高運維業務目標的措施都可以稱為智慧運維。
以使用者角色為例，裝置製造商與業主的動機不同。裝置製造商主要從降低事故損失（包括直接損失、生產影響/產品形象等間接性損失）角度去看，落在預測性維修、提高維修效率（或降低MTTR）等方面。業主（生產企業）主要從保證生產連續性（或提高裝置OEE）的角度去看。即使在同一個生產企業內部，生產執行部的關注和裝置部也有微妙差別，生產執行部更加關心生產的穩定性和連續性，而裝置部則關注裝置延壽、裝置狀態維修和維修效率。
二、大資料平臺能提供什麼？
智慧運維通常涉及到大量裝備的高頻感測資料（機器狀態、工況等）以及豐富的上下文資訊（環境、運維等），屬於典型的工業大資料應用。除了大資料平臺的共性需求之外（提供動態接入、質量線上處理、時序資料壓縮與索引等資料儲存，以及並行化計算功能），智慧運維還有不少工業裝置的特有需求。下面從行業資料模型、行業演算法、行業知識庫三個角度進行闡述。
行業資料模型：裝置全生命週期檔案
裝置智慧運維的一個前提就是裝置的全生命週期檔案，記錄裝置的過往今生以及不同維度的資訊。這是大資料應該解決的基礎問題。包括裝置結構（BOM）、維修履歷、故障記錄、異常預警記錄、工況、檔案、基本資訊等維度。
裝置全生命週期檔案，不僅僅是多個資料來源Data Schema層面的關聯，還包括業務語義層面的處理，包括編碼間的對映關係（例如，裝置編碼規則改變前後的對映）、同義詞（例如，風速在不同時期資料標準中的欄位名可能不同）、欄位名稱相同但業務語義不同（以油氣生產中的“產量”為例，井下產量、井口產量、集輸產量等不同口徑的“產量”，因為測量方式、測量環境、測量標準不同存在很大差別）。大資料平臺在提供行業建模工具時候一定要注意業務語義層面的需求。
以裝置檔案資料模型為基礎，大資料平臺提供基於圖搜尋技術的語義查詢模型，以友好的方式支撐裝置管理分析。以風機為例，當葉片斷裂事故發生後，整機制造商運維主管想檢視確認是否為葉片批次問題（即和當前風機使用同一葉片廠商的風機最近機艙加速度是否正常？），有了圖語義模型的支援，後臺可以自動跨越多個表格進行查詢（而不需要使用者/應用開發者寫複雜的表間關聯語句），這樣將大大降低應用開發的工作量。
行業資料模型：工業知識圖譜
在裝置運維中，除了裝置檔案資料，通常還存在大量的故障案例、裝置維修過程記錄等非結構資料。這些記錄中蘊含著大量的故障徵兆、排查方法等實操經驗，對後續的運維有很大指導和借鑑作用。通用的文字分析，由於缺乏行業專有名詞（專業術語、廠商、產品型號、量綱等）、語境上下文（包括典型工況描述、故障現象等），分析效果欠佳。這就需要構建特定領域的行業知識圖譜（即工業知識圖譜），並將工業知識圖譜與結構化資料圖語義模型融合，實現更加靈活的查詢。
行業分析演算法：已有分析資產（Matlab/Python/R）的並行化
大資料平臺也需要支援已有分析模型的快速成熟。在大資料興起之前，企業就開發了不少基於Matlab/Python/R語言的單機分析模型，只不過缺乏大量資料驗證。經典的大資料並行化系統（Map-reduce）要求重新編寫分析程式，但通用平臺演算法庫（如MLib/Mahout）對工業分析的分析函式（比如，訊號處理、系統辨識）支援有限。而在很多工業分析場景中，記錄間存在著時序關係，並行化分組通常是有明確業務語義的欄位（比如，風功率曲線計算是按照風機、月份進行並行化），而不是記錄條數。因此，工業大資料平臺應該支援非侵入式的Matlab/Python/R並行化，使用者只需指定可並行化的資料欄位，對單機分析程式做簡單適配之後，就可以直接甩到大資料平臺上做全量並行化，通過大資料的迭代，去偽存真，探究海量資料後面的一般性規律，實現企業已有分析資產和實踐經驗的快速變現。
行業分析演算法：工況特徵庫與時序分析演算法庫
在經典分析演算法庫（包括深度學習）和非結構化資料（文字、音訊、影象/視訊等）演算法的基礎上，提供裝置故障和執行狀態分析所需的特徵庫或演算法庫。
針對工況時序資料，提供時序切割、時序分解、時序聚類、時序聚類、典型模式挖掘等共性分析演算法。
動力學系統分析所需的演算法（系統辨識、ODE模擬等）。
針對典型工業單元（如電機、齒輪箱、反應釜等）的FTA（Fault Tree Analysis），包括典型故障型別、特徵變數，以及故障的研判方法。例如，對高速旋轉部件的振動分析演算法庫（時域、頻域和時頻分析）。
行業知識庫：故障診斷/運維案例庫
針對典型裝置的故障診斷和運維，企業和社群通常存在著大量運維工單、經驗總結報告、社群討論等。基於工業知識圖譜分析和行業專家的梳理，形成針對特定領域的案例庫，並形成半結構化的維度標籤，方便檢索和語義推理。
行業知識庫：診斷模版庫
針對典型裝置的故障診斷，形成診斷模板，並與裝置資產檔案欄位關聯。在應用開發時，只需要資料例項化，就有了60～70%的成熟度，後面只需要根據實際資料和特定控制邏輯做一定定製化。
三、智慧運維大資料分析的CRAB規劃方法
正如第一節討論，不同行業、不同裝置、不同角色企業的智慧運維差異很大，在智慧運維的實踐中，我們初步歸納出CRAB四部法。在規劃上，運維大資料相對質量大資料要輕鬆一些，因為裝置運維與生產工藝的耦合度沒有質量分析那麼大，且裝置通常有很多共性基礎單元構成。
業務上下文（Context）理解
業務上下文包括如下四個方面。缺乏這些基本面的把控，智慧運維大資料分析很容易與業務脫節。
維度 | 內容 |
行業生態 | 產業價值鏈（核心價值與挑戰在何處？不同角色的核心能力是什麼） |
裝置物件特點 | 裝置是定製化裝置還是大量類似裝置 裝置的數字化程度 |
當前運維體系 | 瞭解當前的運維職責劃分、成本結構 當前裝置的主要故障模式與診斷經驗 |
業務痛點與目標 | 當前的業務挑戰和改進目標 |
主導企業的資源能力（Resource）分析
主要從如下三個方面進行分析：
（1）主導企業在產業鏈中的獨到能力：決定了智慧運維的側重點在什麼地方。
不同裝置特徵（機理/結構複雜度、失效模式、數字化程度）、不同角色的知識/資訊資源程度也會決定智慧運維的著力點。對於比如風力發電機、航空發動機等主力生產裝置，並且生產過程也是透明的，則裝置製造商可以掌握大量類似裝置的資料，從而在資料技術和知識基礎較業主有很大優勢。但對鼓風機、機床等裝備，只是生產製造裝置中的一環，裝置製造商即使可以掌握裝置自身的狀態資訊，但對整個生產的工況、生產控制、工藝以及其他相關裝置狀態缺乏瞭解，裝置故障預警對裝置製造商來說有一定的限制。因此，在進行裝置運維業務規劃時候，要充分了解業務上下文（Context），決定了智慧運維的側重點在什麼地方。
（2）資料資產
在瞭解相關IT系統（SCADA、MRO等）基礎上，還應該從CPS（Cyber-Physical System）思維的角度，去審思Cyber在多大程度上反映了Physical?在哪些地方有較大差距？這就需要
邏輯層面的融合：在瞭解裝置的數字化程度之上，將IT系統中的資料與裝置動力學機理、控制邏輯、環境、工況、生產控制等資訊融合起來，去看現實世界中的例外情形。比如，MRO訂單中寫的保養項在大多數情形下是否忠實執行（用明確的資料記錄，但不一定真實）；備件需求是否存在囤貨行為（永遠不會有明確的資料記錄，但切實影響到了備件銷售量的這個數字）。
資料的場景化：在資料中重現所有業務場景，更直觀地瞭解這些場景下資料的分佈和走勢。如下圖所示，當風機重啟或個別變槳PLC重啟時，可以在資料中清楚地看出槳距角的初始化過程。
同時，也盡力去發現業務訪談中沒有提到的“異常”場景。以下圖為例，在早期業務訪談中，大家一直認為低風速下風機應該處於停機狀態（槳距角在90度左右），但實際資料表明，低風速下風機也可能處於待機狀態。這對於業務人員來說是預設的常識（但發生頻度低），故而早期業務訪談中客戶沒有提及，若資料探索不夠細緻，這樣的風險將傳遞給後續的建模環節。
技術領域常識對資料能力的基本指導：在如下所示的P-F圖，給出了在不同失效階段，哪些表徵量（紅外、振動、油質、聲波、溫度等）是顯著的。可以給大家一個基本面的判斷，消除很多不必要的“幻想”。
source:https://production-technology.org/tag/probability-of-an-injury/
（3）行業經驗與知識
對於不少問題，一線業務人員或行業專家已經有了相對清晰的認識，這時候沒有必要走純粹資料探勘的思路。但大資料仍有很多價值，因為很多專家經驗通常不夠精確（模糊、歧義、不完備、多個邏輯間的衝突），大資料平臺通過支援“大-小資料”迭代，快速支援行業經驗在全量資料上的驗證與精化。
針對典型的裝置故障以及診斷的問題，大資料平臺或資料分析案例庫通常積累了很多故障模式、故障原因、故障因素/表徵以及常用的診斷模版，但FMEA（Failure mode and effectsanalysis）、FTA（Failure Tree Analysis）經典方法對於細化一個具體裝置的故障模式很有幫助。
針對典型的裝置故障以及診斷的問題，大資料平臺或資料分析案例庫通常積累了很多故障模式、故障原因、故障因素/表徵以及常用的診斷模版，但FMEA（Failure mode and effectsanalysis）、FTA（Failure Tree Analysis）經典方法對於細化一個具體裝置的故障模式很有幫助。
業務模式與技術方案（Analysis）設計
主要包括如下3個方面。技術方案設計在前面質量大資料分析的文章中討論過，這裡不再贅述。
業務模式 | 如何運作智慧運維業務、如何度量成功 |
技術方案設計 | 大資料平臺設計、資料分析技術路線、應用設計 |
推進階段 | 推進階段 |
在業務模式設計上，要從業務應用場景的角度去思考智慧運維的業務需求。例如，有很多裝置運維過程，雖然實現了遠端“監視“（而不是“監控”），但異常/故障判斷仍然全部靠大量的人工，業務需求就是降低監視的人力工作量。該業務需求的技術方案從表面看起來是一套故障/異常自動研判系統（構建一個高精度的機器學習模型自動研判），但若深一點思考，就會發現很多關鍵生產中要求“零誤判、零漏判”。此時，“輔助決策”是唯一的現實方式。再深入一層，“輔助決策“又可分為2種方式：
機器學習模型研判供參考，人工終判；
構建一個自動研判模型（機器學習+行業經驗）實現對相當大比例樣本的100%精度的自動研判，其餘的樣本留給人工去判斷。在很多實時性強或人力消耗大的業務場景，這種方式通常更受歡迎。
在技術方案設計上，同樣要考慮到應用場景的需求與限制。例如，“雲+端”是個很好的提法，但要考慮網路延遲、資料安全、模型穩定性等現實限制。
執行路線圖（Blueprint）
根據課題定位，進行關鍵技術攻關，從模型的精度、穩定性等維度快速評價工藝落地的可行性。對於技術可行的課題，選擇合適的產品型別和地點，進行控制性實驗，最後進行大規模的應用推廣工作（以及對應的大資料應用開發）。在分析模型投入試點之前，最好能夠跳出技術，迴歸到業務角度進行再“再思考”,至少回答以下3個問題：
模型的應用場景：給誰用？對於預警/預測，提前量是多少？是否足夠採取必要的干預動作？模型的漏報率、誤報率對生產意味著什麼？使用者使用時傾向於的互動介面是什麼（比如，在高空運維時，語音也許比觸控式螢幕好）？
模型所需輸入的可獲得性：在模型執行時，這些資訊是否能夠全部獲得？
模型的適用範圍，以及例外情形處理策略：如果遇到未建模情形，如何處理？模型結果的Worst-case是什麼？應對措施是什麼？
四、總結
本文簡要討論了我們在應用KMX大資料平臺實施智慧運維專案中的部分經驗與感想。和很多其他大資料應用一樣，智慧運維應從業務出發，將大資料技術融入到企業的運營與技術體系，融入的具體業務流程與環節。
