常中龍 趙麗媛 鄢鵬程

北京起重運輸機械設計研究院有限公司 北京 100007

0 引言

由于基礎數據的缺失，加之起重機總處于移動狀態(tài)、設備分散等自身特點，難以被在線監(jiān)控，而起重機作為相對典型的控制離散物流設備。與離散設備對應的，是采集數據實時性的要求較高，且數據應保持一致性。如采集到的起重機起升機構位置與起升機構的運行電流應在基本保持一個時刻，而對于與離散設備對應的連續(xù)控制設備（如加熱系統(tǒng)），其一致性要求就會小很多。

目前，由于缺乏細致的運行數據，絕大多數起重機的維保采用亡羊補牢式的方案，即任由起重機的使用而不記錄故障原因、更換時間、工作時間等參數，只有當設備巡檢時或發(fā)生停機后尋找故障原因。隨著目前國內物流成本和起重機定制化、智能化需求的日益提高，最終用戶對停機時間要求越來越嚴格，起重機制造廠和物料搬運解決方案供應商難以滿足對日益增加的服務要求，由于供應鏈、物流因素、定制化元器件制造周期、老型號部件升級等問題讓企業(yè)和最終用戶付出了許多額外的費用和時間。本文通過建立相對完善、統(tǒng)一的數據管理平臺，結合工程實踐、采用異步通訊采集和數據庫報表實現數據采集和數據分析，實現起重機數據采集和分析系統(tǒng)。

1 異步通訊采集

根據起重機的特點，采用實時采集起重機運行數據并異步傳輸的方案，根據以下要求設計采集系統(tǒng)：

1）起重機機械控制系統(tǒng)支持

目前起重機控制系統(tǒng)選用中低配PLC，如西門子S7-1500系列或S7-300系列，通用型起重機可采用磁力控制站的方式，少部分起重機使用專用控制器。為了最大滿足數據采集，涵蓋面最廣的通訊方式一般為OPC，然而該協(xié)議為過程控制而設立，難以保證離散設備的實時性，且綁定了微軟的DCOM技術，難以在嵌入式系統(tǒng)中實現。其下一代系統(tǒng)OPC UA目前仍在快速發(fā)展中。

基于RS485的系統(tǒng)總線（如Profibus）和基于以太網（如Profinet或Modbus TCP）的總線系統(tǒng)均在起重機上應用，從實際應用來看，基于RS485的總線系統(tǒng)由于起重機電機功率太大造成通訊錯碼過多，且計算機需要專用的芯片或擴展卡（如CP 5622），一般只在改造項目中使用。通常情況下使用基于以太網通訊方式，這種方式使用軟件定義，比直接基于7層網絡協(xié)議中3層的RS485要更加靈活。

2）網絡帶寬

唐飛霄見來者不善，忙抬起另一只前足向外撥打，二者交碰一處，伴著一串火星，節(jié)足被撥彈開，旋轉著飛向空中。忽見幾縷細絲疾射而至，半空中將節(jié)足粘住，隨即向后一拽，節(jié)足便飛入了唐飛霄的手中。

起重機總是處于移動狀態(tài)，接入互聯(lián)網和物聯(lián)網存在困難，為了保障數據的一致性，選擇低帶寬的通訊額、且自帶重試重發(fā)的協(xié)議，亦被稱為帶自愈合的協(xié)議。

3）數據集中并離散傳輸，起重機一般為多臺獨立運行，廠區(qū)內一般存在多種類型的起重機，每臺起重機配置一臺邊緣計算網關顯然不夠經濟，且不符合集中管理的要求，故建立集中數據庫結構。

4）傳輸數據量

起重機數據量不大，單臺起重機不會超過256 bytes，但每包數據均包含各個設備運行狀態(tài)，由于存在網絡中斷的可能性，故PLC需要用到緩沖，此時對PLC緩沖將有一定要求。

綜上結合現場實際情況和經濟特性，經過調研多種現場總線和通訊協(xié)議，將相關總線和通訊協(xié)議根據以上要求做了調研，如表1所示。

表1 總線和通訊協(xié)議總結

根據起重機數據采集特點，結合典型起重機工程特點，可選擇MQTT協(xié)議和TDS數據連接作為采集協(xié)議，根據所選擇協(xié)議設計分析系統(tǒng)架構。

1.1 基于MQTT的異步通訊

MQTT（Message Queuing Telemetry Transport） 消息隊列遙測傳輸是ISO 標準（ISO/IEC PRF 20922）下基于發(fā)布、訂閱范式的消息協(xié)議，可視為資料傳遞的橋梁。其工作在TCP/IP協(xié)議族上，是為硬件性能低下的遠程設備以及網絡狀況糟糕的情況下設計的發(fā)布、訂閱型消息協(xié)議。為此，需要一個消息中間件以解決當前繁重的資料傳輸協(xié)議，如HTTP[2]。由于起重機移動性，可能無法穩(wěn)定地連接內外網服務器，因此選用適用于起重機傳輸的基于TCP/IP的socket。

MQTT協(xié)議定義了2種網絡實體：消息代理（message broker）和客戶端（client）。其中，消息代理用于接收來自客戶端的消息并轉發(fā)至目標客戶端。MQTT客戶端可以是任何運行有MQTT庫并通過網絡連接至消息代理的設備，例如微型控制器或大型服務器。采用S7-1500作為客戶端，通過狀態(tài)機實現MQTT需要的功能。其他起重機控制器可參照實現。

信息的傳輸通過主題（topic）管理。發(fā)布者有需要分發(fā)的數據時，其向連接的消息代理發(fā)送攜帶有數據的控制消息。代理會向訂閱此主題的客戶端分發(fā)此數據。發(fā)布者不需要知道訂閱者的數據和具體位置；同樣，訂閱者不需要配置發(fā)布者的相關信息。如果消息代理接收到某個主題上的消息，且該主題沒有任何訂閱，則代理會丟棄它，除非發(fā)布者將其標記為保留消息（retained message）。

當發(fā)布客戶端首次與代理連接時，客戶端可以設置1個默認消息。當代理發(fā)現發(fā)布者意外斷開，其會向訂閱者發(fā)送此預設的消息。客戶端僅與代理有直接的數據傳輸，但整個系統(tǒng)中可能有多個代理，同一時刻鎖定主題與當前訂閱者的交換數據。

MQTT控制消息最小僅2 字節(jié)的數據，最多可以承載256 Mb的數據，很顯然PLC不需要那么大的數據量，根據采集周期100 ms，留有5 s重新連接。MQTT協(xié)議使用普通文本發(fā)送連接認證書，且并不包含任何安全或認證相關的措施。但可使用傳輸層安全加密以保護發(fā)送的數據，以防止攔截、修改或偽造，綜合考慮PLC性能和系統(tǒng)架構，在本項目中采用AES簽名數據。服務質量指的是交通優(yōu)先級和資源預留控制機制，而不是接收的服務質量。服務質量是為不同應用程序、用戶或數據流提供的不同優(yōu)先級的能力，或是為數據流保證一定性能水平的能力[3]。

對于網絡端需要1個Broker服務器，具體實施時采用Eclipse的Mosquitto做測試，MQTT有3個服務質量級別，即最多1次傳送(只負責傳送，發(fā)送過后就不管數據的傳送情況)，至少1次傳送(確認數據交付)，正好1次傳送(保證數據交付成功)。起重機適用于至少1次傳送和正好一次傳送，經過現場實際測試，采用至少1次傳送效果較好。

圖1 MQTT的三狀態(tài)圖

在PLC中實現和調試MQTT客戶端，編程采用狀態(tài)機的模式，編程語言采用S7-SCL，基于西門子PLC進行優(yōu)化，典型占用CPU時間為5 ms，內存占用16 k，對于一般應用的起重機是滿足的。

1.2 基于表格數據流協(xié)議Tabular Data Stream protocol (TDS)通訊協(xié)議連接數據庫

采用MQTT數據保證了數據鏈路上傳輸可靠性，但仍需要在邊緣計算網關或現場工控機上安裝MQTT的Broker來解析并將數據寫入數據庫，這個過程優(yōu)化了數據傳輸，但是使得系統(tǒng)變得更加復雜，對于數據采集往往采用使用中間件讀寫數據庫，這種采集方式適用于連續(xù)的采集，占用大量CPU資源[4]，在研究數據庫協(xié)議后，發(fā)現TDS協(xié)議可以直接寫入數據庫，表格數據流協(xié)議(TDS)使PLC能夠與Microsoft SQL服務器建立直接連接。使用TDS可登錄SQL Server 數據庫并傳輸SQL指令，即可從數據庫中讀取數據，或將其發(fā)送到數據庫進行存儲，通過TDS建立與Microsoft SQL服務器的連接，并使用開放用戶通信塊（TCON、TSEND、TRCV和TDISCON）將數據發(fā)送到數據庫可直接達到采集數據的目的。

但是，表格數據流協(xié)議 TDS協(xié)議較復雜，實現數據庫的插入需要加入較多冗余字符，而PLC一般限制文本結構為256個字符，所以需要對寫入的字符拼接后調用存儲過程（stored procedure），從而省去MQTT的服務器，且經過測試占用帶寬不大，可適用于局域網內數據傳輸，此時異步傳輸通過用戶程序實現?；诖耍O定了如圖2所示的流程，并完成核心編程。

圖2 PLC實現TDS數據庫操作

采用狀態(tài)機的模式編寫TDS解析程序，command就是sql執(zhí)行語句。進過實際測試這種方式相比MQTT占用更多的資源。

2 建立數據分析系統(tǒng)

進過設計異步采集后，對于采用MQTT協(xié)議采集的，則配合MQTT Broker可將起重機運行數據寫入緩沖表中；而使用TDS協(xié)議的采集數據則已經將數據傳入緩沖表中。

2種數據寫入方式在結構上有較大的差異，為了保障數據在系統(tǒng)中的一致性，分別根據報文和表結構在數據庫存儲過程中設定觸發(fā)器將兩者數據統(tǒng)一為同一種表結構，并統(tǒng)一時間戳和增加數據校驗。同時設定數據庫定時器清理緩沖表。

統(tǒng)一數據格式后，整個系統(tǒng)使用前后臺分離技術，后端（服務器端）提供Web Api服務，采用Asp.Net Core實現，開發(fā)語言為C#。前端分客戶端與管理員端，客戶端采用桌面APP展示，管理員端采用B/S架構的管理網站，并使用Angular框架及Typescript技術開發(fā)，前后端使用Http協(xié)議交互，使用JWT做權限控制。前后端分離的主要優(yōu)勢在于復用與管理網站端近似相同的API，以減少維護與開發(fā)成本。

在實施過程中為解決設備傳輸數據表歷史數據量大的問題，使用高版本的SQL Server，對歷史數據表按時間做分割并對歷史表按設備與時間建立索引，前期設備數量較少可以使用每年1次的分割，分割的主要目的是減少索引所占用的內存，以減少磁盤IO，減少查詢時間并增加寫入效率。由于采集數據使用了異步采集數據相對完整，擬采用基于狀態(tài)的維護（OSM-CBM）方式來進行運維，數據庫核心部件表設計按照表2設計，目前收集數據偏少，需要根據較多的數據設定維護閾值。該管理平臺基于.NET Core開發(fā)[5]。整個系統(tǒng)使用前后臺分離技術，后端（服務器端）提供Web Api服務，系統(tǒng)簡化后如圖3所示。

圖3 分析系統(tǒng)架構

表2 數據庫中狀態(tài)維護部件表

客戶端為基于C# 4.5的桌面APP；管理員端使用B/S架構的管理網站，開發(fā)語言：C#.NET；服務器選型為4核16 G內存、硬盤采用SSD固態(tài)硬盤。根據目前確定的1條/min存儲歷史數據速度，每年覆蓋1次的數據量做計算，該服務器內存能支持20個起重機數據采集和分析，后期再增加30臺設備時需要再增加16 G內存。

3 結語

進過設計異步離散異步起重機數據采集，實現了針對起重機特點根據異步特點建立了數據分析系統(tǒng)，解決了起重機數據不連續(xù)的問題，不同于其他分析系統(tǒng)，本系統(tǒng)之后可設定為僅在數據變化和關鍵點進行分析，使得起重機數據采集更為高效，從源頭將部件型號和運行數據聯(lián)系起來，使得系統(tǒng)可以更為高效。后續(xù)隨著數據采集不斷地增大，由于是異步采集，可以動態(tài)調整采集數據內容和周期，以達到更高效的應用，這些數據可在在生產實踐中可在不停機情況下逐步增加完善。