李松濤

(河南工程學院 計算機學院,河南 鄭州 451191)

0 引言

在早期的設備中，大多使用串口與控制器進行通信，而控制器對串口設備數(shù)據(jù)的讀取，一般采用輪詢的方式，在對實時性要求比較高的場合，這種方式無法有效地滿足系統(tǒng)要求[1-3],串口參數(shù)一旦配置完成，無法對其進行動態(tài)配置。物聯(lián)網(wǎng)技術的發(fā)展，要求對設備進行統(tǒng)一的管理和控制，控制器不僅能快速獲取設備數(shù)據(jù)，還要求通過網(wǎng)絡與云平臺通信。由于串口控制器功能比較單一，如果需要連接外網(wǎng)，還要配置通信模塊，且編程復雜，系統(tǒng)的靈活性和可擴展性也不能滿足實際使用的要求。

針對這些問題，本文提出一種動態(tài)可配置串口物聯(lián)網(wǎng)網(wǎng)關。網(wǎng)關上運行可配置、可插拔的OSGi(Open Services Gateway initiative)插件，插件實現(xiàn)多個串口設備的數(shù)據(jù)采集和通信功能。由于OSGi插件具有動態(tài)和并行的特性，與網(wǎng)關相連的串口設備可以獨立、并行地與網(wǎng)關進行數(shù)據(jù)通信。網(wǎng)關運行通信模塊，對通信數(shù)據(jù)遵循消息隊列遙測傳輸協(xié)議(Message Queuing Telemetry Transport，MQTT)協(xié)議進行格式轉換，并將來自不同串口設備的數(shù)據(jù)封裝成消息的形式，發(fā)布到不同的主題上。

1 Kura平臺及插件機制

Kura是Eclipse基金會發(fā)布的物聯(lián)網(wǎng)項目，用于構建IoT(Internet of Things)網(wǎng)關框架。體系結構如圖1所示。Kura由基本服務、遠程連接服務、網(wǎng)絡配置、用戶管理界面等模塊組成。它支持基于事件的消息通信機制，可以在不同組件之間通過事件進行通信。Kura可在樹莓派等多種硬件平臺上部署。

圖1 Kura體系架構

Kura使用OSGi技術實現(xiàn)模塊設計和管理。OSGi基于構件的軟件設計方法和面向服務的模塊化設計思想，定義了一個開放、統(tǒng)一的體系結構[4]。OSGi采用層次結構，其中OSGi內(nèi)核框架、bundle(插件)和服務是其核心要素。插件是OSGi框架下模塊化設計的主要體現(xiàn)。在形式上，插件就是一個Jar文件，OSGi所有基本服務和功能模塊，都是通過插件實現(xiàn)的。插件之間實現(xiàn)物理隔離，系統(tǒng)運行期可以遠程安裝、啟動、升級和卸載，實現(xiàn)軟件熱插拔、多版本控制。

利用插件的動態(tài)模塊化、面向服務架構等特性[5]，用戶可以很方便地創(chuàng)建自己的功能插件，并集成到系統(tǒng)中實現(xiàn)網(wǎng)關功能，可根據(jù)需要對功能模塊擴展[6-7]。

2 MQTT協(xié)議

MQTT是一種基于TCP/IP的議通信協(xié)議，為低帶寬、不穩(wěn)定網(wǎng)絡環(huán)境中的物聯(lián)網(wǎng)應用提供可靠的網(wǎng)絡服務[8]。由于其在網(wǎng)絡連接、可靠性、靈活性及成本等方面突出的優(yōu)點，目前已經(jīng)被國際標準化組織采用，成為物聯(lián)網(wǎng)行業(yè)的一個標準。MQTT協(xié)議使用發(fā)布/訂閱消息模式，提供一對多的消息分發(fā)服務。MQTT協(xié)議由客戶端和代理服務器兩部分組成，代理服務器主要完成消息路由功能，它連接了多個客戶端，客戶端是消息的發(fā)布者和接收者。

3 系統(tǒng)設計及實現(xiàn)

3.1 硬件結構

系統(tǒng)硬件如圖2所示，網(wǎng)關采用開源硬件樹莓派3B。樹莓派集成四個USB接口和WiFi模塊,可以直接通過USB接口與底層設備連接，若連接設備數(shù)量較多，也可以使用USB-hub對串口擴展。樹莓派使用WiFi與MQTT消息代理服務器連接。將串口獲取的數(shù)據(jù)上傳到云端，實現(xiàn)設備端到云端的數(shù)據(jù)傳送。

圖2 系統(tǒng)硬件架構

由于網(wǎng)關與底層設備通過標準的USB串口連接，同時與云端的通信也是基于WiFi技術實現(xiàn)，這時網(wǎng)關的硬件連接基于標準化的接口，系統(tǒng)擴展和連接都很方便，具有更強的適應性。

3.2 軟件設計

3.2.1 軟件整體框架

軟件設計基于Kura框架，采用符合OSGi4標準規(guī)范的模塊化設計，用Java語言編程實現(xiàn)[9]。每一個bundle可以獨立進行開發(fā)和部署。插件根據(jù)需要調(diào)用OSGi和Kura提供的基礎服務。軟件整體框架如圖3所示。

圖3 軟件整體框架

插件需要實現(xiàn)的主要功能是與串口設備的連接和與云端服務器的通信，這兩部分功能分別由串口bundle和通信bundle具體實現(xiàn)。其次，還需要實現(xiàn)插件的動態(tài)配置和可視化管理以及插件之間的通信。

(1)串口bundle。串口bundle實現(xiàn)與多路串口設備連接，并根據(jù)串口設備的不同動態(tài)配置串口通信數(shù)據(jù)格式、波特率等參數(shù)，串口bundle還要支持設備的熱插拔和在線升級。

(2)通信bundle。根據(jù)數(shù)據(jù)來源不同，通信bundle按照不同的主題將數(shù)據(jù)以消息的形式發(fā)送到MQTT代理服務器。

(3)插件的可視化管理。bundle需要實現(xiàn)ConfigurableComponent接口，調(diào)用Kura框架提供的可配置服務，配置參數(shù)來自XML文件。

(4)網(wǎng)關連接的串口可動態(tài)設置。網(wǎng)關支持多串口設備同時連接到一個網(wǎng)關，每一個串口的參數(shù)信息可以動態(tài)改變，包括串口名稱、波特率等。且要求在串口設備工作時動態(tài)完成不同設備之間的切換，即實現(xiàn)所謂的熱插拔。

(5)串口bundle與通信bundle之間的通信。插件之間的通信采用基于事件的實時通信。串口bundle將實時獲取的數(shù)據(jù)以事件的方式發(fā)送給通信bundle。

3.2.2 系統(tǒng)設計及實現(xiàn)

(1)串口bundle

串口bundle需要與底層串口設備連接，由于不同設備的波特率及數(shù)據(jù)格式各異，在設計插件時，必須將串口bundle設計成可動態(tài)可配置的。串口bundle的功能實現(xiàn)，需要調(diào)用OSGi容器和Kura框架提供的一些功能插件，如圖4所示。串口bundle主要依賴連接服務和事件管理服務。同時，它也提供可配置服務，供Web管理程序使用。串口bundle啟動時，引用一個連接服務的實例，建立與串口設備的邏輯連接。隨后讀取串口配置文件，串口配置參數(shù)作為插件的元數(shù)據(jù)，以XML文件的形式保存，串口bundle根據(jù)這些參數(shù)設置串口的工作模式。為實現(xiàn)串口數(shù)據(jù)收發(fā)，在串口bundle中啟動一個新線程用來監(jiān)聽串口，接收來自串口設備的數(shù)據(jù)，這些數(shù)據(jù)被封裝成事件，每一個事件與一個主題相關聯(lián)，對于通信bundle來說，這個主題也是區(qū)分不同串口bundle的一個主要依據(jù)。借助于事件管理服務，由OSGi容器負責事件的路由分發(fā)。

由于插件繼承了可配置接口，可對外發(fā)布ConfigurableComponent服務，當插件激活后，插件的運行狀態(tài)出現(xiàn)在Web管理界面，通過可視化界面可以對串口插件的參數(shù)進行動態(tài)配置。同時，插件的生命周期也可以在這里統(tǒng)一管理。

(2)通信bundle

通信bundle基于Kura內(nèi)置的MQTT service，根據(jù)連接MQTT代理服務器的不同可以在可視化界面中配置MQTT服務代理的參數(shù)。通信bundle接收來自串口bundle的事件。通過解析事件的主題，提取出來自串口bundle的數(shù)據(jù)，并根據(jù)事件主題，建立相應的消息主題，程序流程圖如圖5所示。

圖5 消息處理插件流程圖

(3)插件間通信

插件之間的通信使用事件實現(xiàn)，這是一種松耦合的通信方式，最大限度地減少了插件之間的依賴性。OSGi提供了事件管理服務，如圖6所示。具體實現(xiàn)時，插件需要應用OSGi框架內(nèi)置的事件管理服務。管理服務采用發(fā)布/訂閱模型。事件發(fā)布者將要傳輸?shù)臄?shù)據(jù)封裝成事件的形式，并以特定的主題向外發(fā)布。由OSGi框架對事件進行管理，將事件向所有訂閱該主題的訂閱者發(fā)布。訂閱者實現(xiàn)事件監(jiān)聽接口，接收特定主題，對事件進行解析，獲得發(fā)布者發(fā)送的數(shù)據(jù)。

圖6 事件管理服務模型

事件管理服務以聲明的方式注入，需要在bundle配置文件添加以下內(nèi)容。

cardinality="1..1"

interface="org.osgi.service.event.EventAdmin"

name="EventAdmin"

policy="static"

unbind="unbind"/>

在bind和unbind方法中就可以獲取事件管理服務的實例并通過postEvent()和handleEvent()發(fā)布和接收事件。

(4)插件的動態(tài)配置和可視化管理

為符合底層設備遷移及參數(shù)變化的需要，將插件設計為可熱插拔形式，用戶可通過可視化管理界面管理插件的生命周期，對插件的參數(shù)進行動態(tài)配置，這些操作可以在插件運行時實施?？紤]到插件的倚賴性，同一個插件的不同版本可以同時運行。

插件的配置信息主要是串口的屬性數(shù)據(jù)。這些數(shù)據(jù)定義為元數(shù)據(jù)(Metadata)，并在配置文件中設置其默認值或可選項，也可以由用戶根據(jù)需要設置。首先建立XML格式元數(shù)據(jù)文件，文件中定義了每一個參數(shù)的Id、Name、Type、Cardinality、Tequired、Default等信息。這些信息最終以可視化的形式顯示在管理界面，如圖7所示。

圖7 動態(tài)設置串口設備及參數(shù)界面

4 系統(tǒng)測試

4.1 測試環(huán)境

網(wǎng)關硬件使用開源硬件平臺Raspberry Pi，運行Linux操作系統(tǒng)。Kura框架采用4.1版本，測試時同時連接了四個USB串口設備，每臺設備工作在不同的波特率下。為實現(xiàn)遠程配置，使用PC在局域網(wǎng)內(nèi)與網(wǎng)關連接，登錄Web服務器進入管理界面對插件進行可視化管理。使用WMQTT-utility客戶端訂閱云端數(shù)據(jù)。

4.2 功能測試

通信bundle根據(jù)串口數(shù)據(jù)的來源不同將數(shù)據(jù)發(fā)布到不同的主題上，可以選擇不同的MQTT代理服務器將消息發(fā)布到局域網(wǎng)或云端。這里測試了兩種不同的代理服務器設置，分別是Kura內(nèi)置的Apache ActiveMQ Artemis代理服務器和Eclipse提供的MQTT測試代理服務器。測試結果表明，在兩種不同的網(wǎng)絡環(huán)境中，插件都能夠很好地工作，數(shù)據(jù)接收界面如圖8所示。

圖8 客戶端接收數(shù)據(jù)

5 結論

本文設計并開發(fā)了一種動態(tài)可配置多路串口的網(wǎng)關，網(wǎng)關軟硬件都基于開源項目，具有可擴展性強、開發(fā)快捷、使用靈活等特點。解決了網(wǎng)關與早期設備的聯(lián)網(wǎng)問題，在快速網(wǎng)關原型設計中具有一定的實用價值。系統(tǒng)的插件設計方法，也為未來網(wǎng)關兼容更多的底層設備和通信協(xié)議提供了一種有效的方法。