物聯(lián)網(wǎng)系統(tǒng)中的網(wǎng)關(guān)內(nèi)部程序應(yīng)該如何設(shè)計(jì)？物聯(lián)網(wǎng)系統(tǒng)中,設(shè)備之間是如何通信的;網(wǎng)關(guān)中的進(jìn)程之間消息總線通信模型;網(wǎng)關(guān)內(nèi)部消息總線上的數(shù)據(jù)如何與服務(wù)器進(jìn)行通信;作為消遣,了解一下物聯(lián)網(wǎng)系統(tǒng)中的一些基本知識。

　　物聯(lián)網(wǎng)這個(gè)詞語的范疇太廣,似乎所有的硬件設(shè)備,只要能夠接入網(wǎng)絡(luò),就可以稱之為物聯(lián)網(wǎng)產(chǎn)品,似乎物聯(lián)網(wǎng)這個(gè)詞可以把一切都納入到其中。

在設(shè)計(jì)一個(gè)應(yīng)用程序的架構(gòu)時(shí),可以通過多線程來實(shí)現(xiàn),也可以通過多進(jìn)程來實(shí)現(xiàn),每個(gè)人的習(xí)慣都不一樣,各有各的好處。我們這里不去討論孰優(yōu)孰劣,因?yàn)槲覍Χ噙M(jìn)程這樣的設(shè)計(jì)思想比較偏愛,所以就直接按照多進(jìn)程的程序架構(gòu)來討論。

3．1 網(wǎng)關(guān)中需要哪些進(jìn)程

網(wǎng)關(guān)中需要執(zhí)行的所有進(jìn)程,是根據(jù)網(wǎng)關(guān)的功能來決定的,假設(shè)包括如下的功能:

(1)連接外網(wǎng)的進(jìn)程 Proc_Bridge

網(wǎng)關(guān)需要連接到云端的服務(wù)器,需要一個(gè)進(jìn)程與服務(wù)器之間保持長連接,這樣就可以及時(shí)接收到服務(wù)器發(fā)來的控制指令,以及把系統(tǒng)內(nèi)部數(shù)據(jù)及時(shí)上報(bào)給服務(wù)器。

這個(gè)進(jìn)程需要把從服務(wù)器接收到的指令轉(zhuǎn)發(fā)到網(wǎng)關(guān)系統(tǒng)內(nèi)部,把從系統(tǒng)內(nèi)部接收到的信息轉(zhuǎn)發(fā)給服務(wù)器,類似于橋接的功能,因此命名為 Proc_Bridge。

(2)設(shè)備管理進(jìn)程 Proc_DevMgr

這個(gè)進(jìn)程用來執(zhí)行設(shè)備管理功能,設(shè)備的添加(入網(wǎng))、刪除(退網(wǎng)),都由此進(jìn)程來管理。

(3)協(xié)議轉(zhuǎn)換進(jìn)程 Proc_Protocol

下行:把應(yīng)用層的統(tǒng)一通信協(xié)議,轉(zhuǎn)換成不同類型無線通信協(xié)議,發(fā)送給相應(yīng)的無線模塊。

上行:把設(shè)備上報(bào)的、不同類型的無線通信協(xié)議,轉(zhuǎn)換成應(yīng)用層的統(tǒng)一通信協(xié)議。

(4)邊沿計(jì)算進(jìn)程(自動化控制) Proc_Auto

很明顯,這需要一個(gè)獨(dú)立的進(jìn)程來處理各種計(jì)算,這個(gè)進(jìn)程就相當(dāng)于系統(tǒng)的大腦。

(5)無線通信協(xié)議相關(guān)的進(jìn)程 Proc_ZigBee, Proc_RF, Proc_ZWave

在硬件上,每一種無線通信模塊通過串口或其他硬件連接方式與到網(wǎng)關(guān)的 CPU 進(jìn)行通信,因此,每一種無線通信模塊都需要一個(gè)相應(yīng)的進(jìn)程來處理。

(6)其他“軟設(shè)備”進(jìn)程 Proc_Xxx

在之前的項(xiàng)目中,還遇到一些硬件設(shè)備,它們與門磁、插座等設(shè)備在邏輯上處于同一個(gè)層次,但是與網(wǎng)關(guān)之間是通過 TCP 來連接。對于這樣的設(shè)備,也可以使用一個(gè)獨(dú)立的進(jìn)程來進(jìn)行管理。

上面的這些進(jìn)程,在網(wǎng)關(guān)中的運(yùn)行模型如下:

3．2 MQTT消息總線

以上這些進(jìn)程之間需要相互通信,不是簡單的點(diǎn)對點(diǎn)通信,而是一個(gè)網(wǎng)狀的通信模型。比如:

設(shè)備管理進(jìn)程 Proc_DevMgr:當(dāng)任何一種設(shè)備被添加到系統(tǒng)中時(shí),都需要處進(jìn)行處理,因此它需要與 Proc_ZigBee, Proc_RF, Proc_ZWave 這些進(jìn)程進(jìn)行通信;當(dāng)某個(gè)設(shè)備上報(bào)數(shù)據(jù)時(shí)(例如:Proc_ZigBee),Proc_Protocol 進(jìn)程需要把數(shù)據(jù)進(jìn)行協(xié)議轉(zhuǎn)換,然后 Proc_Bridge 進(jìn)程把轉(zhuǎn)換后的數(shù)據(jù)上報(bào)給服務(wù)器,同時(shí) Proc_Auto 進(jìn)程需要檢查這個(gè)設(shè)備上報(bào)的數(shù)據(jù)是否觸發(fā)了其他相關(guān)聯(lián)的設(shè)備;

也就是說,這些進(jìn)程中間的通信是相互交叉的,如果通過傳統(tǒng)的 IPC 方式(共享內(nèi)存、命名管道、消息隊(duì)列、Socket)等,處理起來比較復(fù)雜。

引入了 MQTT 消息總線之后,每個(gè)進(jìn)程只需要掛載到總線上。每個(gè)進(jìn)程只需要監(jiān)聽自己感興趣的 topic,就可以接收到相應(yīng)的數(shù)據(jù)。

既然這些進(jìn)程之間的通信關(guān)系比較復(fù)雜,那么一個(gè)良好的 topic 設(shè)計(jì)規(guī)范就顯得很重要了!

3．3 Topic 的設(shè)計(jì)

MQTT 的通信模型是基于訂閱/發(fā)布的模式,一個(gè)客戶端(進(jìn)程)接入到消息總線之后,需要注冊自己感興趣的 主題 topic,其他客戶端(進(jìn)程)往這個(gè) topic 發(fā)送消息,即可被訂閱者接收到。

主題 topic 是一個(gè)以反斜線(/)分割的字符串,用來表示多層的分級結(jié)構(gòu),例如下面的這 2 個(gè) topic,是亞馬遜 AWS 平臺中在線升級(OTA)相關(guān)的 topic:

$aws/things/MyThing/jobs/get/accepted$aws/things/MyThing/jobs/get/rejected

在我們的示例場景中,可以按照下面這樣來設(shè)計(jì)主題 topic:

(1) Proc_DevMgr

訂閱主題:

$iot/v1/ZigBee/Register  $iot/v1/ZigBee/UnRegister  $iot/v1/RF/Register  $iot/v1/RF/UnRegister  $iot/v1/ZWave/Register  $iot/v1/ZWave/UnRegister

(2) Proc_Bridge

訂閱主題:

$iot/v1/Device/Report

發(fā)出數(shù)據(jù)的主題:

$iot/v1/Device/Control  $iot/v1/Device/Remove  $iot/v1/Auto/AddRule  $iot/v1/Auto/RemoveRule

(3) Proc_Protocol

訂閱主題:

$iot/v1/Device/Control  $iot/v1/Device/Remove  $iot/v1/ZigBee/Report  $iot/v1/RF/Report  $iot/v1/ZWave/Report  

發(fā)送數(shù)據(jù)主題:

$iot/v1/Device/Report  $iot/v1/ZigBee/Control  $iot/v1/ZigBee/Remove  $iot/v1/RF/Control  $iot/v1/RF/Remove  $iot/v1/ZWave/Control  $iot/v1/ZWave/Remove  

(4) Proc_Auto

訂閱主題:

$iot/v1/Auto/AddRule  $iot/v1/Auto/RemoveRule  $iot/v1/Device/Report  

發(fā)送數(shù)據(jù)主題:

$iot/v1/Device/Control

(5) Proc_ZigBee

訂閱主題:

$iot/v1/ZigBee/Control  $iot/v1/ZigBee/Remove  

發(fā)送數(shù)據(jù)主題:

$iot/v1/ZigBee/Register  $iot/v1/ZigBee/UnRegister  $iot/v1/ZigBee/Report  

(6) Proc_RF

訂閱主題:

$iot/v1/RF/Control  $iot/v1/RF/Remove

發(fā)送數(shù)據(jù)主題:

$iot/v1/RF/Register  $iot/v1/RF/UnRegister  $iot/v1/RF/Report  

(7) Proc_ZWave

訂閱主題:

$iot/v1/ZWave/Control  $iot/v1/ZWave/Remove  

發(fā)送數(shù)據(jù)主題:

$iot/v1/ZWave/Register  $iot/v1/ZWave/UnRegister  $iot/v1/ZWave/Report  

以上這些主題 topic 的設(shè)計(jì),還是有些粗略的。如果借助通配符(#, +, $),可以設(shè)計(jì)出更靈活的層次結(jié)構(gòu)。

多層通配符: “#”是用于匹配主題中任意層級的通配符,多層通配符表示它的父級和任意數(shù)量的子層級。單層通配符:“+”加號是只能用于單個(gè)主題層級匹配的通配符,在主題過濾器的任意層級都可以使用單層通配符,包括第一個(gè)和最后一個(gè)層級。通配符:“$”表示匹配一個(gè)字符,只要不是放在主題的最開頭,其它情況下都表示匹配一個(gè)字符。

我們以一個(gè)控制指令為例,來梳理一下數(shù)據(jù)是如何通過 topic 進(jìn)行流動:

Proc_Bridge 進(jìn)程從服務(wù)器接收到控制指令后,發(fā)送到消息總線上的 topic: $iot/v1/Device/Control。由于 Proc_Protocol 進(jìn)程訂閱了這個(gè) topic,所以立刻接收到指令。Proc_Protocol 分析指令內(nèi)容,發(fā)現(xiàn)是一個(gè) ZigBee 設(shè)備,于是進(jìn)行協(xié)議轉(zhuǎn)換,發(fā)送一個(gè) ZigBee 控制指令到消息總線上的 topic: $iot/v1/ZigBee/Control。由于 Proc_ZigBee 進(jìn)程訂閱了這個(gè) topic,因此它接收到這個(gè)控制指令。Proc_ZigBee 把控制指令轉(zhuǎn)換成 ZigBee 無線通信模塊要求的格式,通過硬件發(fā)送給設(shè)備燈泡。

我們再分析一下設(shè)備數(shù)據(jù)上報(bào)的場景:

先關(guān)注圖中紅色箭頭,忽略藍(lán)色箭頭:

門磁打開后,通過無線通信把信息上報(bào)給進(jìn)程 Proc_CF。Proc_RF 進(jìn)程接收到 RF433 通信模塊上報(bào)的數(shù)據(jù),把“門磁打開”這個(gè)信息發(fā)送到消息總線上的 topic:$iot/v1/RF/Report。由于 Proc_Protocol 進(jìn)程訂閱了這個(gè) topic,因此接收到上報(bào)的門磁數(shù)據(jù)。Proc_Protocol 分析數(shù)據(jù),把 RF433 協(xié)議的數(shù)據(jù)轉(zhuǎn)成統(tǒng)一的應(yīng)用層協(xié)議的數(shù)據(jù),發(fā)送到消息總線上的 topic:$iot/v1/Device/Report。由于 Proc_Bridge 進(jìn)程訂閱了這個(gè) topic,因此就接收到了這次上報(bào)的數(shù)據(jù)。Proc_Bridge 進(jìn)程把數(shù)據(jù)上報(bào)給服務(wù)器。

再來看一下藍(lán)色箭頭流程:

在上面的第 4 步:Proc_Protocol 進(jìn)程把 RF433 協(xié)議數(shù)據(jù)轉(zhuǎn)成應(yīng)用層統(tǒng)一協(xié)議之后,把數(shù)據(jù)發(fā)送到消息總線上的 topic:$iot/v1/Device/Report 之后,Proc_Auto 進(jìn)程同時(shí)進(jìn)行如下操作:

由于 Proc_Auto 也訂閱了這個(gè) topic,因此它也接收到了門磁上報(bào)的這個(gè)應(yīng)用層協(xié)議的數(shù)據(jù)。Proc_Auto 查找自己的配置信息(假設(shè)用戶已經(jīng)提前配置好了一條規(guī)則:當(dāng)門磁打開的時(shí)候,就觸發(fā)聲光報(bào)警器),發(fā)現(xiàn)匹配到了“門磁->報(bào)警器”這條規(guī)則,于是發(fā)出一條控制報(bào)警器的指令,發(fā)送到消息總線上的 topic: $iot/v1/Device/Control。

后面的 7,8,9,10 這四個(gè)步驟就與上面的控制指令流程完全一樣了。

3．4 與 DBUS 總線的對比

從上面描述的 3 個(gè)數(shù)據(jù)流向的場景中,是不是感覺到使用 topic 為“數(shù)據(jù)管道”的這種通信方式,與 Linux 系統(tǒng)中的 DBUS 總線特別的相似?

DBUS 總線也是用于進(jìn)程之間的通信,按照我個(gè)人的理解,DBUS中其實(shí)是把進(jìn)程之間的兩種通信組織在一起了:

基于信號的數(shù)據(jù)傳輸;基于方法的 RPC 遠(yuǎn)程調(diào)用;

DBUS 總線包含的概念更復(fù)雜一些,包括:路徑、對象、接口、方法等等,這些概念組織在一起共同定位到一個(gè)具體的服務(wù)提供者了。

相比較而言,我感覺 MQTT 這樣的方式更簡潔一些。

所謂的 RPC 遠(yuǎn)程調(diào)用,就是調(diào)用位于遠(yuǎn)程機(jī)器上的一個(gè)函數(shù),主要解決兩個(gè)問題:

網(wǎng)絡(luò)連接;數(shù)據(jù)的序列化和反序列化;

后面我會專門寫一篇文章,利用 protobuf 框架來實(shí)現(xiàn) RPC 調(diào)用。

四、網(wǎng)關(guān)與云平臺之間的通信

上面講解的設(shè)計(jì)過程,是網(wǎng)關(guān)內(nèi)部的各功能模塊之間通信方式,這也是我們作為嵌入式開發(fā)者能充分發(fā)揮的部分。

網(wǎng)關(guān)與云平臺之間的通信方式一般都是客戶指定的,就那么幾種(阿里云、華為云、騰訊云、亞馬遜AWS平臺)。一般都要求網(wǎng)關(guān)與云平臺之間處于長連接的狀態(tài),這樣云端的各種指令就可以隨時(shí)發(fā)送到網(wǎng)關(guān)。

當(dāng)然了,這些云平臺都會提供相應(yīng)的 SDK 開發(fā)包,一般使用的 MQTT 協(xié)議來連接云平臺更多一些。在一些文檔中,會把位于云端的 MQTT 服務(wù)器稱作 Broker,其實(shí)就是一個(gè)服務(wù)器。

進(jìn)程 Proc_Bridge 的功能主要有 2 點(diǎn):

與云平臺的數(shù)據(jù)傳輸通道;協(xié)議轉(zhuǎn)換:把云平臺相關(guān)的協(xié)議轉(zhuǎn)換成網(wǎng)關(guān)內(nèi)部的協(xié)議,以及相反的轉(zhuǎn)換。

也就是說:Proc_Bridge 進(jìn)程需要同時(shí)連接到云平臺的 MQTT Broker 和網(wǎng)關(guān)內(nèi)部的 MQTT 消息總線。在下一篇文章中,我們來專門講解這部分的內(nèi)容,并提供一個(gè)實(shí)現(xiàn)橋接功能的代碼模板。