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

0 前言

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

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

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

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

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

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

1.3 工程機械產品地理位置信息的采集

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

1.4 租賃工程機械設備的結算管理

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

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

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

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

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

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

2.1 系統(tǒng)的結構框圖

基于NB-IoT的機械設備物聯(lián)網系統(tǒng)結構框圖如圖1所示，它包括感知層、網絡層、應用層三個部分。

圖1 系統(tǒng)結構框圖

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

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

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

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

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

圖2 監(jiān)控終端結構框圖

2.4 地理位置信息采集方案

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

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

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

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

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

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

3.1 中央服務器的設計

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

3.2 服務器邏輯層

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

圖3 服務器邏輯部分工作流程圖

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

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

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

圖4 服務器系統(tǒng)結構框圖

3.4 PC控制臺程序設計

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

圖5 客戶端系統(tǒng)結構框圖

客戶端系統(tǒng)設計了一種基于改進型MVC架構的應用軟件。這種架構是一種由事件驅動的程序架構?？蛻舳瞬糠窒到y(tǒng)結構框圖如圖5所示。

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

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

3.5 APP設計

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

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

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

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

圖7 Netty框架工作流程如圖

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

4 結語

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