基于NB-IoT技術(shù)的施工現(xiàn)場工程機(jī)械監(jiān)控系統(tǒng)設(shè)計

趙靜文 （中鐵四局集團(tuán)管理研究院，安徽 合肥 230022）

0 前言

工程機(jī)械設(shè)備是施工建造中不可或缺的生產(chǎn)工具，目前傳統(tǒng)的工程機(jī)械設(shè)備管理，主要依賴人工錄入，存在耗時長、工作量大、成本高、信息更新不及時、數(shù)據(jù)不準(zhǔn)確、無法依據(jù)信息做出管控調(diào)配等缺點，制約了施工現(xiàn)場工程機(jī)械設(shè)備的集中統(tǒng)計與統(tǒng)一調(diào)撥。窄帶物聯(lián)網(wǎng)（NB-IoT）技術(shù)是2017年新興的物聯(lián)網(wǎng)技術(shù)，具有功耗低、信號穩(wěn)定、數(shù)據(jù)傳輸可靠、可以適應(yīng)復(fù)雜定位環(huán)境和通信環(huán)境、擴(kuò)展性好等眾多優(yōu)點。應(yīng)用窄帶物聯(lián)網(wǎng)技術(shù)開發(fā)工程機(jī)械監(jiān)控系統(tǒng)，將會實現(xiàn)施工現(xiàn)場工程機(jī)械全天候、全方位的監(jiān)控。

1 系統(tǒng)功能設(shè)計

1.1 工程機(jī)械靜態(tài)信息的采集、存儲和查詢

系統(tǒng)能夠采集工程機(jī)械產(chǎn)品整機(jī)及其零部件的設(shè)備名稱、規(guī)格型號、銘牌信息、牌照號、發(fā)動機(jī)型號等靜態(tài)信息，使用RFID或近場通信技術(shù)實現(xiàn)對設(shè)備的靜態(tài)信息采集，以保證外租設(shè)備管理的唯一性。

1.2 狀態(tài)信息的實時采集

提供用戶方便的查詢工程機(jī)械設(shè)備的運行時間、故障報警、燃油消耗、工作時長、工作狀態(tài)、通信狀況等各類信息以及匯總分析的情況，提供地圖、圖表和多層數(shù)據(jù)列表展示的功能。

1.3 工程機(jī)械產(chǎn)品地理位置信息的采集

針對工程機(jī)械作業(yè)趨于分散以及工程機(jī)械租賃性使用的特點，系統(tǒng)能夠?qū)崟r地確定產(chǎn)品的地理位置，實現(xiàn)工程機(jī)械產(chǎn)品的實時定位、軌跡記錄、里程統(tǒng)計等功能。

1.4 租賃工程機(jī)械設(shè)備的結(jié)算管理

系統(tǒng)能夠?qū)⑼庾庠O(shè)備的每月燃油消耗與加油數(shù)據(jù)、運轉(zhuǎn)時間、工作量自動生成月度或季度報表，報表信息將作為現(xiàn)場管理部門對外租設(shè)備費用結(jié)算的依據(jù)。

1.5 工程故障信息的智能化處理

系統(tǒng)對于狀態(tài)異常的信息，能夠自動報警，能夠為維護(hù)人員提供解決方案，實現(xiàn)故障信息的智能化處理。

1.6 遠(yuǎn)程監(jiān)控功能

系統(tǒng)能夠提供過程信息和產(chǎn)品信息的遠(yuǎn)程監(jiān)控功能，系統(tǒng)操作人員通過遠(yuǎn)程監(jiān)控系統(tǒng)與設(shè)備和現(xiàn)場人員實現(xiàn)交互。

2 系統(tǒng)方案設(shè)計

2.1 系統(tǒng)的結(jié)構(gòu)框圖

基于NB-IoT的機(jī)械設(shè)備物聯(lián)網(wǎng)系統(tǒng)結(jié)構(gòu)框圖如圖1所示，它包括感知層、網(wǎng)絡(luò)層、應(yīng)用層三個部分。

圖1 系統(tǒng)結(jié)構(gòu)框圖

2.2 系統(tǒng)的工作流程

通過遠(yuǎn)程終端模塊采集各種傳感器所得到的數(shù)據(jù)內(nèi)容，然后將采集結(jié)果通過NB-IoT發(fā)送至中心服務(wù)器，服務(wù)器在收到這些數(shù)據(jù)后，將對其進(jìn)行解析和處理，最后，存儲至數(shù)據(jù)庫。與此同時，用戶還可以使用相應(yīng)的用戶管理平臺查詢各種歷史數(shù)據(jù)，將查詢結(jié)果以表格、圖表等形式打印，為后續(xù)的現(xiàn)場管理提供真實的數(shù)據(jù)保障。

2.3 系統(tǒng)監(jiān)控終端設(shè)計

系統(tǒng)的監(jiān)控終端結(jié)構(gòu)框圖如圖2所示。系統(tǒng)結(jié)構(gòu)采用雙重總線結(jié)構(gòu)，其中內(nèi)部的板級總線掛載窄帶物聯(lián)網(wǎng)模塊、九軸姿態(tài)模塊、精確授時的北斗定位模塊、高精度RTC模塊和電源管理模塊；外部的設(shè)備級總線掛載油料傳感器、正反轉(zhuǎn)傳感器等外設(shè)。

這種系統(tǒng)結(jié)構(gòu)的優(yōu)勢是提供了系統(tǒng)優(yōu)秀的擴(kuò)展性，為未來系統(tǒng)的升級打下基礎(chǔ)。

圖2 監(jiān)控終端結(jié)構(gòu)框圖

2.4 地理位置信息采集方案

遠(yuǎn)程終端采用基于Ublox-M8n的北斗定位系統(tǒng)，Ublox-M8n系統(tǒng)可以支持國際上現(xiàn)有的三種GNSS系統(tǒng)（GPS、北斗和GLONASS），最多可支持72路通信信道，并且可以同時識別多個衛(wèi)星定位系統(tǒng)，非常適合應(yīng)用在車輛定位方面，它具有高靈敏度、低功耗、小型化、極其高追蹤靈敏度，大大擴(kuò)大了其定位的覆蓋面，在普通北斗接收模塊不能定位的地方，如狹窄都市天空下、密集的叢林環(huán)境，模塊的高靈敏度、小靜態(tài)漂移、低功耗及輕巧的體積，非常適合于車輛監(jiān)控移動定位系統(tǒng)的應(yīng)用。

2.5 終端系統(tǒng)的電源管理

系統(tǒng)采用基于BQ24266的電源管理系統(tǒng)，BQ24266是一款高度集成的鋰離子電源路徑管理器件，它不僅可以監(jiān)控電池剩余電量，同時還可以在有外部供電的情況下根據(jù)電池自身電量剩余情況，對電池進(jìn)行充電，這樣可以有效的延長脫機(jī)情況下遠(yuǎn)程終端硬件的工作時長。

2.6 外部數(shù)據(jù)存儲與IAP設(shè)計

系統(tǒng)采用外部掉電非易失性數(shù)據(jù)存儲器。在一些通信環(huán)境較為惡劣的環(huán)境，遠(yuǎn)端數(shù)據(jù)無法傳回中央服務(wù)器，這樣可以采用一種掉電非易失型數(shù)據(jù)存儲器，當(dāng)數(shù)據(jù)無法回傳時，暫時將采集結(jié)果存儲起來，直到數(shù)據(jù)傳輸恢復(fù)后，再打包傳輸所有的數(shù)據(jù)。

3 數(shù)據(jù)庫及用戶平臺設(shè)計

3.1 中央服務(wù)器的設(shè)計

根據(jù)java語言在網(wǎng)絡(luò)編程方面的優(yōu)勢，采用java編寫服務(wù)器基本框架，實現(xiàn)客戶端與服務(wù)器之間的連接，同時采用java與Mysql之間的接口設(shè)計數(shù)據(jù)庫基本框架，進(jìn)一步實現(xiàn)客戶端訪問服務(wù)器，對數(shù)據(jù)庫進(jìn)行操作。

3.2 服務(wù)器邏輯層

對應(yīng)于與APP與PC客戶端(統(tǒng)稱客戶端)，采用TCP服務(wù)器，可以保證連接的可靠性與穩(wěn)定性。采用反射的方法完成邏輯架構(gòu)，其同樣具有優(yōu)越的維護(hù)性能，在損失極小性能的代價之上，完成了服務(wù)器邏輯的模塊化。服務(wù)器從客戶端處得到XML格式的命令之后，對其進(jìn)行解析，得到用戶名、密碼、查詢命令、查詢參數(shù)等信息。在查詢開始前，將會對用戶進(jìn)行校驗，首先檢測數(shù)據(jù)庫內(nèi)是否有相應(yīng)的用戶名，若沒有則向客戶端報告“沒有該用戶”的錯誤，并終止與客戶端的連接。若用戶名存在，服務(wù)器進(jìn)一步驗證用戶密碼，若用戶密碼錯誤，同樣向客戶端報告錯誤并中斷連接。只有用戶名與密碼同時正確時，才能開始具體的查詢操作。服務(wù)器首先根據(jù)需要查詢的信息類型，定位到相應(yīng)的數(shù)據(jù)庫模型，接著利用命令名稱與相應(yīng)參數(shù)找到具體的查詢方法，在二者被同時找到之后，執(zhí)行命令并按照特定的格式向客戶端返回信息。信息中包含查詢命令XML中的信息，以及查得數(shù)據(jù)及其日期、時間信息。

圖3 服務(wù)器邏輯部分工作流程圖

服務(wù)器與下位機(jī)之間的通信采用了UDP通信協(xié)議。盡管這種方式犧牲了少量的連接可靠性，但他卻只需消耗少量系統(tǒng)資源，就可以實現(xiàn)多節(jié)點下位機(jī)同時向服務(wù)器傳送數(shù)據(jù)。服務(wù)器解析下位機(jī)發(fā)送至服務(wù)器的UDP包，將所有的數(shù)據(jù)信息計算得出，按條依次存入數(shù)據(jù)庫中。其中每一個包中包含多條下位機(jī)采集的數(shù)據(jù)，降低了服務(wù)器對數(shù)據(jù)處理的壓力。為了規(guī)避數(shù)據(jù)的丟失，本項目建立了壞數(shù)重傳的機(jī)制保證了數(shù)據(jù)包的可靠性。服務(wù)器維護(hù)了一個隊列用于存儲每臺下位機(jī)的最新20條數(shù)據(jù)，每次處理信息時，先比對隊列中有無重復(fù)信息。實現(xiàn)了對下位機(jī)重復(fù)發(fā)至服務(wù)器的冗余信息進(jìn)行過濾，保證了數(shù)據(jù)庫的數(shù)據(jù)不會被輕易污染。兩個服務(wù)器分別建立各自的線程，彼此之間互不干擾，由數(shù)據(jù)庫本身的機(jī)制進(jìn)行數(shù)據(jù)操作的協(xié)調(diào)。

3.3 數(shù)據(jù)庫層

數(shù)據(jù)庫采用MYBATIS架構(gòu)整體搭建，其具有維護(hù)性好，性能高等特點。總體上數(shù)據(jù)庫分為三層，模型層、命令層和DAO層：模型層對應(yīng)數(shù)據(jù)庫內(nèi)不同的表的信息，將數(shù)據(jù)庫中的每一個表設(shè)計為一個具體的類，其包含的詳細(xì)信息則抽象為字段；命令層則涵蓋了對應(yīng)于數(shù)據(jù)庫每一個表的查詢方法，依據(jù)數(shù)據(jù)庫表內(nèi)信息的不同，分別為三張表獨立設(shè)計了對應(yīng)的查詢條件，滿足各種查詢需要；DAO層則封裝數(shù)據(jù)庫接口，將繁雜的數(shù)據(jù)庫操作簡化為連接數(shù)據(jù)庫，執(zhí)行需要的命令的簡單模式，同時在工具類中封裝了一些常用的小工具，方便后期維護(hù)與進(jìn)一步開發(fā)。需要注意的是，MYBATIS將具體的數(shù)據(jù)庫操作語句封裝在XML文件中，將具體數(shù)據(jù)庫的操作集中起來，并簡化為數(shù)據(jù)庫SQL語句，輸入?yún)?shù)，輸出參數(shù)三者之結(jié)合，最終在總XML文件中將前述文件與命令層相對接，即可完成數(shù)據(jù)庫全部操作。為了提高數(shù)據(jù)庫的操作性能，引入了數(shù)據(jù)庫連接池的機(jī)制，以實現(xiàn)讀寫的高效處理；同時實現(xiàn)了按日期分表的功能，將大量的數(shù)據(jù)分散在多個表中，以實現(xiàn)查詢功能的進(jìn)一步提升。數(shù)據(jù)庫系統(tǒng)框圖如圖4所示。

圖4 服務(wù)器系統(tǒng)結(jié)構(gòu)框圖

3.4 PC控制臺程序設(shè)計

本項目客戶端部分使用.NetFramework 4.6程序框架，建立基于C#WPF的客戶端應(yīng)用程序，在保證功能實現(xiàn)和性能優(yōu)化的前提下，還提供了一種簡潔美觀的用戶界面。

圖5 客戶端系統(tǒng)結(jié)構(gòu)框圖

客戶端系統(tǒng)設(shè)計了一種基于改進(jìn)型MVC架構(gòu)的應(yīng)用軟件。這種架構(gòu)是一種由事件驅(qū)動的程序架構(gòu)。客戶端部分系統(tǒng)結(jié)構(gòu)框圖如圖5所示。

這種框架的業(yè)務(wù)流程是，當(dāng)用戶發(fā)生一個命令查詢請求時，首先，UI層會將這條命令進(jìn)行編碼，傳輸給業(yè)務(wù)邏輯層；業(yè)務(wù)邏輯層在收到事件請求后，會記錄下發(fā)出請求的頁面ID，然后將這條命令進(jìn)一步傳輸給網(wǎng)絡(luò)通信層傳輸給遠(yuǎn)端服務(wù)器，同時業(yè)務(wù)邏輯層會將頁面ID和查詢命令種類共同在消息等待隊列中登記；網(wǎng)絡(luò)層在收到服務(wù)器的回復(fù)信息后直接將結(jié)果直接打包傳輸給業(yè)務(wù)邏輯層；邏輯層再從消息等待隊列中獲取信息源，然后將查詢結(jié)果打包傳輸給UI層，最后，UI層最終將查詢結(jié)果顯示。

這種框架具有非阻塞、多并發(fā)的結(jié)構(gòu)特點，可以為用戶提供在不同頁面同時查詢數(shù)據(jù)的良好用戶體驗。同時由于軟件系統(tǒng)采用了基于TCP短連接的技術(shù)，減少了服務(wù)器的維護(hù)長連接的業(yè)務(wù)邏輯，很大程度上降低了服務(wù)器工作壓力。

3.5 APP設(shè)計

本項目的APP開發(fā)過程中共包含三個層次，它們分別是UI顯示層、業(yè)務(wù)邏輯處理層和網(wǎng)絡(luò)通信層。各層次之間的業(yè)務(wù)邏輯如圖6所示。

圖6 APP系統(tǒng)邏輯框圖

如圖6所示，APP系統(tǒng)的業(yè)務(wù)流程是當(dāng)用戶產(chǎn)生一個查詢請求后，UI層會將這個請求傳送給業(yè)務(wù)邏輯層；業(yè)務(wù)邏輯層會進(jìn)一步將這個請求命令編碼為XML格式命令，并且進(jìn)一步傳輸給網(wǎng)絡(luò)通信層；在網(wǎng)絡(luò)通信層接收到服務(wù)器的返回結(jié)果后，邏輯層會將結(jié)果解碼，然后驅(qū)動UI層進(jìn)行顯示。

本項目中APP網(wǎng)絡(luò)層開發(fā)的一大特點是采用了Netty框架。Netty是一種提供異步的、事件驅(qū)動的網(wǎng)絡(luò)應(yīng)用程序框架，用于快速開發(fā)高性能、高可靠性的網(wǎng)絡(luò)服務(wù)器和客戶端程序。傳輸層協(xié)議采用TCP協(xié)議。表示層協(xié)議采用XML格式。Netty框架實現(xiàn)了上述兩種協(xié)議。采用TCP這一面向連接的協(xié)議保證了APP接收服務(wù)器數(shù)據(jù)的實時性，而傳統(tǒng)http協(xié)議查詢方式若查詢頻率過高，將導(dǎo)致APP性能下降。若查詢頻率過低，將帶來消息通知不及時的問題。采用xml格式保證了不同客戶端（如安卓端、IOS端、PC端）的通信格式的統(tǒng)一。APP在接收到數(shù)據(jù)并解析后，將接收到的數(shù)據(jù)發(fā)送給邏輯處理模塊。

圖7 Netty框架工作流程如圖

Netty將數(shù)據(jù)的傳入傳出抽象為“事件”，如數(shù)據(jù)的打包、發(fā)送、解析等。每個事件要經(jīng)過對應(yīng)的事件處理器進(jìn)行操作，轉(zhuǎn)換為下一事件繼續(xù)由其他事件處理器進(jìn)行處理。

4 結(jié)語

工業(yè)物聯(lián)網(wǎng)技術(shù)是目前先進(jìn)制造領(lǐng)域研究的熱點，本文對物聯(lián)網(wǎng)技術(shù)在工程機(jī)械監(jiān)控領(lǐng)域的應(yīng)用進(jìn)行了探索，設(shè)計了系統(tǒng)的功能，并對系統(tǒng)功能實現(xiàn)的技術(shù)方案進(jìn)行設(shè)計，進(jìn)而提出了系統(tǒng)的架構(gòu)和體系結(jié)構(gòu)，本研究將為基于物聯(lián)網(wǎng)技術(shù)的工程機(jī)械監(jiān)控系統(tǒng)的開發(fā)建立基礎(chǔ)。