陳帝旭 鄭 湃 王曉峰
(①中國科學院沈陽計算技術研究所,遼寧 沈陽 110168;②中國科學院大學,北京 101408)
隨著2015 年國務院出臺《中國制造2025》等一系列指導性文件[1],我國開始全面部署推進制造強國戰(zhàn)略。提升我國高鐵吊弦預配的智能制造水平,符合《中國制造2025》的智能制造發(fā)展方向,常州數(shù)控技術研究所發(fā)揮其在數(shù)控技術和自動化方面的技術優(yōu)勢,聯(lián)合中鐵建電氣化局集團軌道交通器材有限公司,于2021 年成功開發(fā)融合了可以生產(chǎn)鋁腕臂、鋼腕臂和簡統(tǒng)化腕臂的高鐵智能化接觸網(wǎng)腕臂柔性預配平臺[2]。但目前高鐵接觸網(wǎng)吊弦預配的自動化和智能化水平發(fā)展依然不對稱,該高鐵接觸網(wǎng)整體吊弦壓接檢一體化智造單元還是以人工輔助平臺和半自動化為主,智能判斷故障、生產(chǎn)數(shù)據(jù)信息化等智能制造技術的融入程度不高。究其原因是高鐵接觸網(wǎng)腕臂柔性預配生產(chǎn)線多設備多工藝的環(huán)境下,設備數(shù)據(jù)結構復雜和協(xié)議多樣[3],僅伺服電機就有20 余個,嚴重阻礙了設備數(shù)據(jù)的及時采集。包含電機振動數(shù)據(jù)等大量復雜的設備高頻數(shù)據(jù)未經(jīng)處理就直接傳輸?shù)皆贫诉M行故障分析[4],將導致數(shù)據(jù)傳輸帶寬占用極高,不僅阻礙設備數(shù)據(jù)網(wǎng)絡共享,還會使設備故障發(fā)現(xiàn)不及時,嚴重時會給制造企業(yè)帶來巨大的經(jīng)濟損失。因此,有必要設計一種基于邊云協(xié)同服務框架,靠近車間現(xiàn)場高效采集和預處理數(shù)據(jù),并對設備故障實時預測的完整架構,以達到制造車間生產(chǎn)數(shù)據(jù)標準化、統(tǒng)一化的目的,推動高鐵接觸網(wǎng)整體吊弦壓接檢智造單元加速邁向智能化。
綜上所述,數(shù)據(jù)是智造車間的核心[5],實現(xiàn)對設備數(shù)據(jù)的高效采集和實時處理是完成設備工作狀態(tài)監(jiān)控和數(shù)據(jù)分析的首要條件。但目前為止,大部分設備數(shù)據(jù)采集與振動故障分析方法沒有兼顧數(shù)據(jù)采集效率、采集準確性和設備業(yè)務執(zhí)行實時性的要求[6-10]。因此本文提出基于邊云協(xié)同的設備數(shù)據(jù)統(tǒng)一采集與故障分析應用方法。邊緣設備與云平臺協(xié)同運行,既利用邊緣計算的數(shù)據(jù)采集和局部數(shù)據(jù)處理能力,又利用云平臺的數(shù)據(jù)分析和數(shù)據(jù)共享能力[11],邊云協(xié)同運行極大釋放網(wǎng)絡的帶寬,從而實現(xiàn)設備業(yè)務的快速響應。同時,運用OPC UA(OPC unified architecture,OPC UA)設備建模對采集項進行靈活定義,能兼容多種協(xié)議數(shù)據(jù)格式進行采集,使邊緣設備數(shù)據(jù)采集的內(nèi)容和時間可控,從而滿足不同的需求。
當前智造單元設備網(wǎng)絡中存在大量協(xié)議繁雜且智能化程度不同的感知設備[12],傳統(tǒng)數(shù)據(jù)采集方法堆砌各種協(xié)議進行采集,難以采集到實時、完整和準確的數(shù)據(jù)。針對這個問題,本文設計基于邊云協(xié)同的數(shù)據(jù)采集架構,采用可兼容、可擴展的分層設計。如圖1 所示,設計為設備網(wǎng)絡、邊緣數(shù)據(jù)中心和云中心3 層,包括異構設備數(shù)據(jù)采集、時序數(shù)據(jù)存儲與預處理、邊云數(shù)據(jù)協(xié)同3 個功能,負責將底層設備的原始協(xié)議數(shù)據(jù)采集并轉(zhuǎn)換為OPC UA 格式協(xié)議數(shù)據(jù),傳輸至時序數(shù)據(jù)庫高效存儲和實時處理,然后制定數(shù)據(jù)同步策略,將預處理后的數(shù)據(jù)協(xié)同到云端。接下來對以上功能進行實現(xiàn)。

圖1 邊云協(xié)同數(shù)據(jù)采集架構圖
本文基于OPC UA 技術,通過設計協(xié)議轉(zhuǎn)換中間件,采集、解析和封裝原始設備數(shù)據(jù)協(xié)議,并映射到OPC UA 服務器地址空間對應節(jié)點,實現(xiàn)使用標準OPC UA 協(xié)議信息在車間網(wǎng)絡進行通信,以完成統(tǒng)一采集各類智造單元設備數(shù)據(jù)。
1.1.1 OPC UA 服務器搭建
設計良好的數(shù)據(jù)模型是搭建OPC UA 服務器的基礎,也是將生產(chǎn)現(xiàn)場數(shù)據(jù)統(tǒng)一進行管理的關鍵[13]。根據(jù)數(shù)據(jù)采集需求,本文對智造單元設備的機械運動數(shù)據(jù)、伺服參數(shù)、傳感器數(shù)據(jù)等,使用可視化信息建模工具UaModeler,根據(jù)設備實際情況描述設備對象和抽象建模,分別對設備創(chuàng)建各自的對象節(jié)點類型。建模后的智造單元某數(shù)控設備信息模型部分變量節(jié)點見表1。

表1 設備部分信息模型節(jié)點表
最后通過UaModeler 工具,將建模好的設備信息,導出為XML 格式的模型定義節(jié)點集文件保存待用。
設備信息模型配置好后,本文選擇成熟的SDK 快速開發(fā)OPC UA 服務器,open62541 是開源的OPC UA 協(xié)議棧,使用C 語言開發(fā),在實時性、嵌入式開發(fā)方面更具優(yōu)勢[14]。使用open62541 的開發(fā)工具節(jié)點集編譯器加載XML 格式的設備信息模型,將節(jié)點信息轉(zhuǎn)換為OPC UA 服務器可識別的類文件代碼,并提供.c 和.h 庫文件形式的調(diào)用接口,通過調(diào)用該接口方法,OPC UA 服務器將信息模型節(jié)點集實例化為OPC UA 節(jié)點,為服務器生成設備地址空間。
圖2 所示為服務器的運行邏輯,首先通過UA_Server_new()方法創(chuàng)建OPC UA 服務器對象,在UA_Server_setConfig(server)方法中為OPC UA 服務器配置安全證書、名稱、端口號等參數(shù),再啟動服務器監(jiān)聽程序,方法是UA_Server_run(server,&running),開啟服務器對象實例,OPC UA 服務器啟動并運行后,OPC UA 客戶端連接服務器即可開始通信。

圖2 OPCUA 服務器搭建流程圖
底層設備使用OPC UA 通信,可以最大程度保證數(shù)據(jù)的可靠性。OPC UA 定義了一套統(tǒng)一的數(shù)據(jù)模型并使用強類型定義,用于描述和表示設備數(shù)據(jù)。統(tǒng)一的數(shù)據(jù)模型和明確定義的數(shù)據(jù)類型,確保了數(shù)據(jù)的格式和語義在不同系統(tǒng)和設備之間的一致性和完整性。同時,OPC UA 使用基于規(guī)范的TCP/IP 通信協(xié)議,避免了數(shù)據(jù)丟失、重復或損壞的情況,確保了數(shù)據(jù)在傳輸過程中的正確性和可靠性。
1.1.2 底層設備協(xié)議轉(zhuǎn)換
本節(jié)設計一種具備擴展性和通用性的協(xié)議轉(zhuǎn)換中間件實現(xiàn)協(xié)議轉(zhuǎn)換功能,完成連接底層設備采集原始數(shù)據(jù),再按對應設備的通信協(xié)議格式解析封裝為OPC UA 格式的數(shù)據(jù)供OPC UA 服務器讀取。實現(xiàn)數(shù)控設備原始數(shù)據(jù)的兼容采集。
協(xié)議轉(zhuǎn)換中間件的設計包含通信配置模塊、協(xié)議庫模塊、數(shù)據(jù)請求模塊和解析封裝模塊。通信配置模塊為各設備的通信提供初始化配置參數(shù),包括連接設備所需的接口參數(shù)和數(shù)據(jù)項請求參數(shù)。如針對Modbus RTU 協(xié)議進行通信,數(shù)據(jù)請求配置需要知道一次讀取請求的字節(jié)數(shù)、數(shù)據(jù)的起始寄存器地址等關鍵參數(shù)。協(xié)議庫模塊集成多種協(xié)議的通用操作函數(shù)和各設備廠家提供的專用設備通信函數(shù),并提供統(tǒng)一調(diào)用接口。數(shù)據(jù)請求模塊調(diào)用協(xié)議庫中對應設備通信函數(shù),加載通信配置中的參數(shù)信息,建立設備連接,并請求設備原始協(xié)議格式的字節(jié)碼數(shù)據(jù),實現(xiàn)對原始數(shù)據(jù)的采集。解析封裝模塊把每次數(shù)據(jù)請求返回的原始字節(jié)流數(shù)據(jù)分割為獨立的數(shù)據(jù)片段,如圖3 所示。

圖3 數(shù)據(jù)片段分割示意圖
最后將各個數(shù)據(jù)片段轉(zhuǎn)換為可理解的數(shù)據(jù)后,按語義取出此次傳輸需要對OPC UA 服務器進行數(shù)據(jù)填充的設備數(shù)據(jù),封裝為OPC UA 數(shù)據(jù)格式由OPC UA 服務器進行讀取。車間不同設備使用的通信協(xié)議和官方SDK 大都不同,故分別開發(fā)對應的協(xié)議轉(zhuǎn)換驅(qū)動程序,通過接口的方式為OPC UA 服務器提供規(guī)范的調(diào)用,使OPC UA 服務器能同步讀取設備最新的OPC UA 格式數(shù)據(jù)。
車間設備的運行狀態(tài)數(shù)據(jù)大多是帶時間戳,并按順序產(chǎn)生的高頻時序數(shù)據(jù)[15]。傳統(tǒng)關系型數(shù)據(jù)庫數(shù)據(jù)存儲和查詢低效,難以滿足車間實時性的要求,所以本文選型時序數(shù)據(jù)庫存儲時序數(shù)據(jù)。TDengine開源時序數(shù)據(jù)庫具有低成本、部署快和讀寫性能遠高于其他時序數(shù)據(jù)庫的特點,所以本文在離車間現(xiàn)場較近的邊緣數(shù)據(jù)中心服務器部署TDengine 時序數(shù)據(jù)庫集群,通過TDengine 數(shù)據(jù)庫的接口與TDengine 建立連接,發(fā)送數(shù)據(jù)寫入請求,完成OPC UA 格式設備信息數(shù)據(jù)到TDengine 設備數(shù)據(jù)表的持久性存入。
時序數(shù)據(jù)是按時間順序密集分布并存儲的。在邊緣層對數(shù)據(jù)進行清洗、預處理,讓絕大部分數(shù)據(jù)靠近數(shù)據(jù)源高效處理,可以保障車間任務執(zhí)行的實時性。相比于批處理,本文選擇更高效、實時的流式計算作為數(shù)據(jù)預處理方式。TDengine 提供流式計算功能,用戶可以通過設置聚合函數(shù)、表名、滑動窗口等參數(shù)定義1 個流處理事件,持續(xù)對流入窗口的數(shù)據(jù)進行預處理。以需要預處理的數(shù)據(jù)表作為流計算的源表,數(shù)據(jù)會被以定義的方式自動處理,并根據(jù)定義的觸發(fā)模式將計算結果推送到目的表保存。
邊云數(shù)據(jù)協(xié)同是指在邊緣計算和云計算結合的環(huán)境中,實現(xiàn)數(shù)據(jù)的協(xié)同和共享。通過將云端計算和存儲能力推進至邊緣數(shù)據(jù)源頭,以提高數(shù)據(jù)處理和響應的效率。首先,在邊緣端統(tǒng)一采集設備數(shù)據(jù)并在本地存儲后,經(jīng)過分析,邊緣數(shù)據(jù)庫中的數(shù)據(jù)包含3 個階段:①M-data,結構化數(shù)據(jù)類型的數(shù)據(jù)源元數(shù)據(jù);②C-data,對海量的M-data 數(shù)據(jù)進行清洗和預處理后的精煉數(shù)據(jù);③K-data,將邊緣存儲的預處理數(shù)據(jù)匯聚進行融合和分析的云端數(shù)據(jù)。因此,僅將必要的經(jīng)過預處理后的C-data 類型數(shù)據(jù),通過以太網(wǎng)協(xié)同到云端,云端匯集C-data 整理為Kdata 數(shù)據(jù)進行深入分析,邊云共享數(shù)據(jù)存儲資源,減少了數(shù)據(jù)傳輸?shù)难舆t和帶寬消耗。本文選擇以從TDengine 數(shù)據(jù)庫導出CSV 格式數(shù)據(jù)文件的方式,與云端通過HTTP 傳輸同步數(shù)據(jù),云端TDengine 數(shù)據(jù)庫將表導入進行持久化存儲,邊云在數(shù)據(jù)層面進行協(xié)同,減輕數(shù)據(jù)上傳至云端的帶寬壓力,數(shù)據(jù)同步過程如圖4 所示。

圖4 邊云數(shù)據(jù)協(xié)同示意圖
電機振動故障預測性維護對腕臂預配生產(chǎn)線設備健康十分重要,然而云端網(wǎng)絡通信面臨巨大的流量壓力,電機端采集的振動信號很難實時上傳至云端進行故障診斷應用,且傳統(tǒng)故障診斷方法通過單時頻分析的方式,人工提取時頻圖中的顯著特征進行故障診斷的做法費時費力,不利于在邊緣端實時自動化推理[16]。本文基于預處理后同步至云端的振動數(shù)據(jù),設計一款邊云智能協(xié)同的端到端電機振動故障識別算法。利用卷積神經(jīng)網(wǎng)絡(convolutional neural network,CNN)[17]能從大規(guī)模數(shù)據(jù)中自動學習特征的特點,結合CNN 與二維時頻圖,實現(xiàn)在邊緣資源受限設備智能實時診斷電機故障的神經(jīng)網(wǎng)絡。
從智造單元設備的伺服電機采集到的原始電機振動信號數(shù)據(jù)需要經(jīng)過樣本集切割和時頻圖轉(zhuǎn)換處理才能作為卷積神經(jīng)網(wǎng)絡的訓練輸入。本文的電機振動數(shù)據(jù)集是由1 臺數(shù)控機床電機模擬正常工作狀態(tài)、電機轉(zhuǎn)子受阻故障以及電機基座松動故障3 種電機運行狀態(tài)的實驗采集到的。在負載1 HP、轉(zhuǎn)速600 r/min 的工況下,采樣頻率設為100 Hz,每次采集不少于720 000 個采樣點,選擇512 個采樣點作為數(shù)據(jù)樣本長度,使用步長500 的重疊采樣法對振動信號數(shù)據(jù)集進行切割,以增強訓練數(shù)據(jù)數(shù)量,最后得到正常狀態(tài)和兩種故障狀態(tài)下的樣本各1 200 個。
接著采用cmor3-3 小波基函數(shù)對電機樣本數(shù)據(jù)集中的信號進行連續(xù)小波變換,通過不同尺度變換將一維時序信號轉(zhuǎn)化為二維時頻信號。以3 種類型信號時頻圖為例,圖5 和圖6 所示為一組相互對應的電機振動數(shù)據(jù)的時域圖和轉(zhuǎn)換后的時頻圖。

圖5 3 種信號的時域波形圖

圖6 3 種信號的時頻變換結果圖
最終,得到電機不同狀態(tài)的特征圖樣本各1 200 個,選取其中的720 個作為訓練樣本,剩余的480 個作為測試樣本。不同故障樣本數(shù)量及標簽配置見表2。

表2 不同故障樣本的數(shù)量及標簽配置表
時頻變換讓故障信號轉(zhuǎn)換為具有不同紋理及細節(jié)特征的時頻圖,而相較于其他淺層神經(jīng)網(wǎng)絡,CNN 具有充分學習和表達小波時頻圖復雜特征的能力,同時具備更快的運算速度,并避免了訓練陷入局部極值等問題。故本文選擇CNN 自動提取時頻圖像中的輪廓及差異信息,從而實現(xiàn)不同故障類型的準確識別。時頻圖轉(zhuǎn)換方法主要采用了連續(xù)小波變換(continuous wavelet transform,CWT)方法。在上一節(jié)中,采用連續(xù)小波變換成功將一維振動信號轉(zhuǎn)換為到二維時頻特征圖后,將其作為深度神經(jīng)網(wǎng)絡的輸入,建立CNN 模型進行測試,完成基于時頻圖結合卷積神經(jīng)網(wǎng)絡的故障診斷方法,實現(xiàn)對電機故障的準確、智能診斷,故障診斷方法總體過程如圖7 所示。

圖7 時頻圖結合神經(jīng)網(wǎng)絡的故障診斷方法
主要流程包括:①對采集到的振動信號數(shù)據(jù)集進行故障分類,獲得不同故障類型的原始振動信號;②對原始時域信號進行連續(xù)小波變換,以得到二維時頻圖,并調(diào)整時頻圖尺寸;③將生成的二維時頻圖按一定比例隨機分為訓練集、測試集和驗證集;④建立CNN 模型,并初始化網(wǎng)絡參數(shù);⑤利用訓練集訓練CNN,直到損失函數(shù)收斂;⑥利用測試集驗證訓練好的CNN 模型的性能;⑦得到CNN 模型的識別結果。
云端接收邊緣數(shù)據(jù)訓練模型再下放邊緣端部署,以邊云智能協(xié)同推理的方式將模型部署應用于邊緣生產(chǎn)線故障預測場景,減小帶寬波動帶來的影響,協(xié)同過程如圖8 所示。

圖8 邊云智能協(xié)同示意圖
針對邊緣設備在資源不足的邊云智能協(xié)同應用場景下,執(zhí)行大參數(shù)模型低效的問題,本文采取模型壓縮策略,使用8 位模型量化方法,使其變得更加輕量化。TensorFlow 模型優(yōu)化工具包提供了模型量化的工具,本文使用該工具量化經(jīng)訓練并已轉(zhuǎn)換為 TensorFlow Lite 模型的電機故障診斷模型。量化前的.h 模型文件大小為1 074 kB,量化后的.tflite 模型壓縮到了347 kB,減少了75 %的存儲空間。
最后,壓縮后的故障預測模型通過以太網(wǎng)傳輸?shù)竭吘墧?shù)據(jù)中心存儲,在邊緣樹莓派服務器部署Tensorflow Lite 框架,以實現(xiàn)模型的遷移協(xié)同推理,并在其中運行輕量化后的模型進行故障預測。
本文依托于高鐵吊弦預配智造單元某條生產(chǎn)線,在設備運行加工期間,連續(xù)采集10 天的設備狀態(tài)數(shù)據(jù)進行試驗。各實驗設備使用C 語言和Python語言的協(xié)議轉(zhuǎn)換驅(qū)動程序、故障定時診斷程序已安裝在樹莓派armhf 系統(tǒng),OPC UA 服務器監(jiān)聽進程也已配置啟動,且設備都已處于同一個局域網(wǎng)中。使用開源OPC UA 客戶端輸入服務器的URL 地址連接到OPC UA 服務器。本實驗中,測試服務器URL 訪問地址配置為opc.tcp://10.0.0.6:4 840。
3.1.1 數(shù)據(jù)采集準確性測試
以使用OPC UA 客戶端瀏覽生產(chǎn)線某臺西門子數(shù)控設備信息為例,為其設置的命名空間為2,進入該設備地址空間監(jiān)控實時更新的節(jié)點變量數(shù)據(jù)。如圖9 所示,可以看到數(shù)控系統(tǒng)的編程坐標、切削和主軸倍率等設備節(jié)點值,將本文方法讀取到的編程坐標值,與西門子數(shù)控系統(tǒng)面板上的數(shù)值在同一時刻進行比較,二者得到的數(shù)據(jù)一致且完整。此外,本實驗還測試了數(shù)控設備緊急停機時,對應OPC UA 節(jié)點值的變化,結果表明,從客戶端讀取的數(shù)據(jù)項的值,與急停時數(shù)控系統(tǒng)面板觀察到的數(shù)據(jù)值一致。

圖9 OPCUA 客戶端節(jié)點通信圖
3.1.2 數(shù)據(jù)采集時延測試
由于OPC UA 協(xié)議格式數(shù)據(jù)帶時間戳,可以借此測試數(shù)據(jù)從請求開始,再到傳輸至時序數(shù)據(jù)庫存儲所消耗的數(shù)據(jù)采集總時延。本實驗針對生產(chǎn)線上包含不同協(xié)議的3 臺智能數(shù)控裝備分別采集X軸編程坐標數(shù)據(jù)項,得到3 臺設備采集該數(shù)據(jù)項的平均時延。如表3 所示,與傳統(tǒng)數(shù)據(jù)采集方式對比,本文所用的數(shù)據(jù)采集方法時延更低,平均在1.31 ms左右,比傳統(tǒng)方法快了約2.5 ms。

表3 邊云協(xié)同設備數(shù)據(jù)采集時延測試表
采用YDAT501 型壓電加速度傳感器垂直于數(shù)控機床電機驅(qū)動端上側(cè)磁吸安裝。分別采用拆卸基座螺絲、轉(zhuǎn)子人為增阻的方式引入損傷。在云平臺上,本文使用了Windows 10 的64 位操作系統(tǒng)、i5-11300H@ 3.10 GHz 的CPU 以及Pycharm 作為模型訓練環(huán)境。在訓練神經(jīng)網(wǎng)絡過程中,得到了誤差收斂曲線和準確率曲線,如圖10 所示。

圖10 accuracy 準確率與Loss 損失值圖
將訓練好的模型經(jīng)壓縮后傳輸?shù)竭吘壎耍渴鹪谶吘墭漭葾RM 處理器上,定義一個定時任務,每隔一段時間執(zhí)行故障分析程序,從時序數(shù)據(jù)庫中讀取電機振動信號數(shù)據(jù),通過set_tensor()函數(shù)輸入,調(diào)用invoke()運行模型得到故障分類,輸出診斷結果。診斷結果顯示,CNN 表現(xiàn)出了較強的泛化能力和聚類能力,成功將具有較大時頻圖差異的同類故障樣本識別為一類。同時,CNN 也展現(xiàn)了較強的特征提取和識別能力,成功地區(qū)分了具有相似時頻圖的異類故障樣本。測試結果見表4 所示,與傳統(tǒng)集中式云中心故障分析方法相比,本文應用在邊云智能協(xié)同場景,基于小波時頻圖的CNN 的電機振動故障方法在準確率不受影響的情況下,故障分析響應時間明顯變得更短。

表4 邊云協(xié)同振動故障分析應用性能測試表
本文對高鐵吊弦預配智造單元傳統(tǒng)數(shù)據(jù)采集技術的研究進行了創(chuàng)新,提出基于邊云數(shù)據(jù)協(xié)同的異構數(shù)控設備數(shù)據(jù)統(tǒng)一采集和預處理方法,兼容異構設備協(xié)議實現(xiàn)到OPC UA 標準數(shù)據(jù)協(xié)議的轉(zhuǎn)換,以時序存儲服務器為核心,高效存入OPC UA 時序數(shù)據(jù)實時進行預處理。隨后改進傳統(tǒng)人工故障檢測方法,提出結合卷積神經(jīng)網(wǎng)絡與小波變換時頻圖的電機振動故障診斷方法,訓練并輕量化壓縮模型,便于下放到邊緣端進行部署,邊云協(xié)同完成邊緣電機故障的實時智能推理。最后將所提方法在現(xiàn)實智造單元生產(chǎn)線中驗證,實驗結果表示,本文提出的基于邊云協(xié)同框架下的設備數(shù)據(jù)統(tǒng)一采集架構與故障分析應用,以較低成本,提升了數(shù)據(jù)采集和傳輸效率,不僅減少該智造單元中數(shù)據(jù)傳輸?shù)木W(wǎng)絡帶寬占用,也滿足了設備故障分析響應的實時需求,具有通用性和高效性。