一種用于起重機(jī)械的離散數(shù)據(jù)采集分析系統(tǒng)系統(tǒng)設(shè)計(jì)

常中龍 趙麗媛 鄢鵬程

北京起重運(yùn)輸機(jī)械設(shè)計(jì)研究院有限公司 北京 100007

0 引言

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

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

1 異步通訊采集

根據(jù)起重機(jī)的特點(diǎn)，采用實(shí)時(shí)采集起重機(jī)運(yùn)行數(shù)據(jù)并異步傳輸?shù)姆桨?，根?jù)以下要求設(shè)計(jì)采集系統(tǒng)：

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

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

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

2）網(wǎng)絡(luò)帶寬

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

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

3）數(shù)據(jù)集中并離散傳輸，起重機(jī)一般為多臺獨(dú)立運(yùn)行，廠區(qū)內(nèi)一般存在多種類型的起重機(jī)，每臺起重機(jī)配置一臺邊緣計(jì)算網(wǎng)關(guān)顯然不夠經(jīng)濟(jì)，且不符合集中管理的要求，故建立集中數(shù)據(jù)庫結(jié)構(gòu)。

4）傳輸數(shù)據(jù)量

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

綜上結(jié)合現(xiàn)場實(shí)際情況和經(jīng)濟(jì)特性，經(jīng)過調(diào)研多種現(xiàn)場總線和通訊協(xié)議，將相關(guān)總線和通訊協(xié)議根據(jù)以上要求做了調(diào)研，如表1所示。

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

根據(jù)起重機(jī)數(shù)據(jù)采集特點(diǎn)，結(jié)合典型起重機(jī)工程特點(diǎn)，可選擇MQTT協(xié)議和TDS數(shù)據(jù)連接作為采集協(xié)議，根據(jù)所選擇協(xié)議設(shè)計(jì)分析系統(tǒng)架構(gòu)。

1.1 基于MQTT的異步通訊

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

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

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

當(dāng)發(fā)布客戶端首次與代理連接時(shí)，客戶端可以設(shè)置1個(gè)默認(rèn)消息。當(dāng)代理發(fā)現(xiàn)發(fā)布者意外斷開，其會向訂閱者發(fā)送此預(yù)設(shè)的消息?？蛻舳藘H與代理有直接的數(shù)據(jù)傳輸，但整個(gè)系統(tǒng)中可能有多個(gè)代理，同一時(shí)刻鎖定主題與當(dāng)前訂閱者的交換數(shù)據(jù)。

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

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

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

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

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

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

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

圖2 PLC實(shí)現(xiàn)TDS數(shù)據(jù)庫操作

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

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

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

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

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

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

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

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

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

3 結(jié)語

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