基于無(wú)線傳感網(wǎng)絡(luò)分簇結(jié)構(gòu)的軟件架構(gòu)

李曉偉+鄧紅霞+朱麗

摘要：物聯(lián)網(wǎng)將數(shù)十億的“物”連接到互聯(lián)網(wǎng)上，具有傳感、驅(qū)動(dòng)及數(shù)據(jù)處理的能力。在物聯(lián)網(wǎng)中，用戶可以收集感知的信息，并最大化利用其價(jià)值。然而，在目前的應(yīng)用解決方案中，對(duì)物理對(duì)象訪問(wèn)的可擴(kuò)展性和有效性并不高，只有專業(yè)人員才能夠開發(fā)應(yīng)用程序?；谏鲜鰡?wèn)題，利用約束應(yīng)用協(xié)議（CoAP）對(duì)已存在的軟件架構(gòu)進(jìn)行改進(jìn)，虛擬化無(wú)線傳感設(shè)備的簇頭，使其通過(guò)上層的表述性狀態(tài)傳遞（REST）接口，只與自身的虛擬化設(shè)備交互。此外，該系統(tǒng)提供了便捷的開發(fā)工具，允許不同技術(shù)層次的用戶進(jìn)行應(yīng)用程序開發(fā)。

關(guān)鍵詞：物聯(lián)網(wǎng)；無(wú)線傳感網(wǎng)絡(luò)；約束應(yīng)用協(xié)議（CoAP）

DOIDOI：10.11907/rjdk.171647

中圖分類號(hào)：TP303

文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1672-7800（2017）006-0019-03

0 引言

無(wú)線傳感器網(wǎng)絡(luò)（WSNs）在檢測(cè)系統(tǒng)方面，作為主要類型的分布式系統(tǒng)[1]正在迅速崛起。然而，WSNs的發(fā)展因存在一些缺點(diǎn)而受到阻礙，主要涉及到節(jié)點(diǎn)功耗、網(wǎng)絡(luò)編程和訪問(wèn)物理資源。目前絕大部分解決方案主要集中于最大限度地減少不同層次的協(xié)議棧功耗，對(duì)于其它問(wèn)題，還沒(méi)有真正得到解決。基于智能物的物聯(lián)網(wǎng)應(yīng)用開發(fā)目前尚處于起步階段，并且對(duì)物理資源的訪問(wèn)往往缺乏可擴(kuò)展性且效率較低。盡管許多解決方案提供了高層次的接口以簡(jiǎn)化物聯(lián)網(wǎng)應(yīng)用，但絕大多數(shù)是基于超文本傳輸協(xié)議（HTTP），對(duì)于嵌入式設(shè)備來(lái)說(shuō)成本過(guò)高。

基于CoAP方案[2]在訪問(wèn)物理資源方面存在與嵌入式設(shè)備直接交互或者僅通過(guò)中間數(shù)據(jù)庫(kù)公開資源問(wèn)題。顯然，對(duì)于嵌入式設(shè)備來(lái)說(shuō)計(jì)算和存儲(chǔ)的要求太高或者提供給用戶的信息可能不是最新的。采用分簇的方法對(duì)CoAP方案的架構(gòu)進(jìn)行改進(jìn)，可以很好地解決該問(wèn)題。所謂分簇，就是將WSN的節(jié)點(diǎn)劃分為許多組（稱為簇），每個(gè)簇由一個(gè)簇頭節(jié)點(diǎn)和成員節(jié)點(diǎn)組成。成員節(jié)點(diǎn)感知收集數(shù)據(jù)并發(fā)送給簇頭，簇頭對(duì)數(shù)據(jù)進(jìn)行融合發(fā)送到上層簇頭或基站[3]。

本系統(tǒng)采用單層分簇[4]，旨在說(shuō)明系統(tǒng)架構(gòu)底層對(duì)簇頭虛擬化的方法，以及減少WSNs節(jié)點(diǎn)的能量損耗與計(jì)算量。首先，它能夠抽象物理設(shè)備并對(duì)其虛擬化，再通過(guò)共同接口顯示虛擬設(shè)備。其次，要求物聯(lián)網(wǎng)應(yīng)用面向不同技術(shù)用戶和異構(gòu)實(shí)現(xiàn)平臺(tái)。該系統(tǒng)共有4層架構(gòu)組成，如圖1所示。第一層是組件層，即最接近用戶的層，由應(yīng)用程序組成。第二層是WebSocket /CoAP協(xié)議代理服務(wù)器，實(shí)現(xiàn)用戶環(huán)境與運(yùn)行應(yīng)用程序之間的通信。第三層是執(zhí)行層，用于體系結(jié)構(gòu)處理：①物理設(shè)備的虛擬化；②監(jiān)控物聯(lián)網(wǎng)所連接的“物”；③執(zhí)行運(yùn)行應(yīng)用程序的業(yè)務(wù)邏輯。第四層是訪問(wèn)層，物理設(shè)備必須通過(guò)一個(gè)共同接口為物聯(lián)網(wǎng)應(yīng)用共享資源。

1 架構(gòu)原理和設(shè)計(jì)

物聯(lián)網(wǎng)架構(gòu)的整體目標(biāo)是方便用戶開發(fā)應(yīng)用程序。為此，架構(gòu)需遵循以下原則：

（1）降低開發(fā)難度和促進(jìn)快速成型。擴(kuò)大開發(fā)用戶范圍，專業(yè)用戶、研究人員以及普通終端用戶都可以在智能對(duì)象上開發(fā)，并有助于促進(jìn)使用智能對(duì)象的第三方創(chuàng)新。

（2）高可用性的體系結(jié)構(gòu)，以保證用戶直接且無(wú)處不在的訪問(wèn)。用戶應(yīng)該能夠通過(guò)不同類型的平臺(tái)和系統(tǒng)訪問(wèn)使用智能對(duì)象和服務(wù)。

（3）輕量級(jí)訪問(wèn)智能對(duì)象數(shù)據(jù)。允許創(chuàng)建應(yīng)用程序，對(duì)于資源受限的設(shè)備（如手機(jī)）不需要很多的計(jì)算和存儲(chǔ)資源。

（4）嵌入式設(shè)備的低計(jì)算負(fù)載特點(diǎn)往往是低的計(jì)算和內(nèi)存資源。

上述條件給設(shè)計(jì)帶來(lái)很多挑戰(zhàn)。

嵌入式設(shè)備必須免于任何應(yīng)用程序的業(yè)務(wù)邏輯，僅需要通過(guò)常見的抽象異構(gòu)硬件功能的接口公開它們的資源。這種方法完全符合嵌入式設(shè)備的需求。因此，架構(gòu)應(yīng)忽略業(yè)務(wù)邏輯，以保證計(jì)算和內(nèi)存資源。

該體系結(jié)構(gòu)的核心部分必須能夠發(fā)現(xiàn)和索引可用的資源。此外，它應(yīng)該負(fù)責(zé)業(yè)務(wù)邏輯的執(zhí)行。事實(shí)上，為了保持物理設(shè)備不受計(jì)算任務(wù)影響，執(zhí)行的應(yīng)用程序應(yīng)該在物理層外運(yùn)行，并且進(jìn)行數(shù)據(jù)處理，并將結(jié)果發(fā)送給客戶端應(yīng)用程序。該架構(gòu)的上部應(yīng)提供簡(jiǎn)單的接口，允許開發(fā)人員快速部署應(yīng)用程序，從嵌入式網(wǎng)絡(luò)收集信息，并通過(guò)改變狀態(tài)來(lái)控制物理設(shè)備。開發(fā)這些應(yīng)用程序，技術(shù)嫻熟的用戶可以使用高級(jí)編程語(yǔ)言開發(fā)自己的應(yīng)用程序，而一般用戶可以利用簡(jiǎn)單的軟件工具，如圖形編輯器，實(shí)現(xiàn)應(yīng)用。

需要強(qiáng)調(diào)的是架構(gòu)不應(yīng)該是一個(gè)“黑盒子”，而是每一層都必須提供用于共享其資源的能力。這樣，應(yīng)用根據(jù)特定用戶的需求可以建立在任何層之上。

2 架構(gòu)實(shí)例

對(duì)于所設(shè)計(jì)的體系結(jié)構(gòu)主要由3個(gè)組件實(shí)現(xiàn)，第一個(gè)組件是CoAP服務(wù)器Erbium[5]，是CoAP對(duì)Contiki的實(shí)現(xiàn)[6]。第二個(gè)組件是應(yīng)用程序服務(wù)器Actinium，處理JavaScript應(yīng)用與CoAP設(shè)備的交互執(zhí)行。最后一個(gè)組件腳本編輯器是實(shí)現(xiàn)運(yùn)行于瀏覽器中的應(yīng)用程序的圖形工具。

最底層由于Erbium的瘦服務(wù)器適應(yīng)于現(xiàn)有的硬件，所以它為每一個(gè)嵌入式設(shè)備提供了RESTful接口[7]。而中間層解決了物理網(wǎng)絡(luò)通信優(yōu)化問(wèn)題，特別是應(yīng)用程序服務(wù)器Actinium擴(kuò)展延伸，為該體系結(jié)構(gòu)上下層提供了關(guān)鍵功能。

架構(gòu)能夠不斷發(fā)現(xiàn)可用的節(jié)點(diǎn)及其資源：節(jié)點(diǎn)的離開、重新連接到網(wǎng)絡(luò)、新的節(jié)點(diǎn)連接。此外，無(wú)線傳感網(wǎng)絡(luò)中每一個(gè)簇頭所在設(shè)備由軟件克隆虛擬化從而避免資源過(guò)度負(fù)擔(dān)。Actinium集成了服務(wù)器推送的管理模式，使智能設(shè)備在事件發(fā)生時(shí)發(fā)出通知。這種操作模式由CoAP在本地提供，是許多物聯(lián)網(wǎng)方案的一個(gè)重要方面，但不是由Actinium管理。為了使組件層和應(yīng)用程序服務(wù)器之間進(jìn)行通信，定義ad hoc層并集成到體系結(jié)構(gòu)中，這一層還包含了一個(gè)WebSocket /CoAP協(xié)議的代理服務(wù)器。在CoAP協(xié)議方面與Actinium通信，在WebSocket通信方面向用戶界面提供實(shí)時(shí)通知。在最上層改進(jìn)和擴(kuò)展編輯器的結(jié)構(gòu)。新的圖形用戶界面（GUI）為用戶提供了圖形元素，其模型是典型的物聯(lián)網(wǎng)組件，如傳感器和執(zhí)行器。該體系結(jié)構(gòu)體描述如圖2所示。

按照所描述的設(shè)計(jì)原則，用戶可以通過(guò)不同方法開發(fā)和部署自己的應(yīng)用程序，如利用圖形編輯，通過(guò)連接WebSocket/CoAP協(xié)議代理，或通過(guò)安裝Actinium應(yīng)用程序。當(dāng)然，也可以使用Erbium提供的RESTful接口直接與嵌入式設(shè)備交互。

2.1 調(diào)整Erbium瘦服務(wù)器

根據(jù)瘦服務(wù)器模式，Erbium可獲得當(dāng)前傳感器和執(zhí)行器的狀態(tài)，并且可以改變后者狀態(tài)。在獲取傳感器數(shù)據(jù)的過(guò)程中，WSNs根據(jù)路由算法找到傳感器中的簇頭節(jié)點(diǎn)，簇頭的個(gè)數(shù)與WSNs分布大小稠密有關(guān)。每個(gè)簇頭傳感器都作為資源在Erbium注冊(cè)，并以[resource_name]_handler的格式為其定義一個(gè)處理程序。在收到一個(gè)請(qǐng)求后，處理程序輪詢傳感器，并使用該傳感器狀態(tài)作為有效載荷構(gòu)建響應(yīng)消息。同樣的方法用于執(zhí)行器，但所定義的處理程序要求能夠響應(yīng)獲取和發(fā)布請(qǐng)求。定義在Erbium上的一個(gè)可訂閱傳感器，在它自身狀態(tài)發(fā)生變化時(shí)實(shí)現(xiàn)一個(gè)event_resource，將新的設(shè)備狀態(tài)生成一個(gè)通知，通知訂閱所有此傳感器的應(yīng)用程序。

2.2 擴(kuò)展Actinium服務(wù)器

物聯(lián)網(wǎng)需要一個(gè)資源發(fā)現(xiàn)機(jī)制。在所提出的架構(gòu)中，發(fā)現(xiàn)過(guò)程由JavaScript應(yīng)用程序執(zhí)行，稱為discover-motes。它在Actinium啟動(dòng)時(shí)運(yùn)行并且存儲(chǔ)資源目錄中的可用資源。資源發(fā)現(xiàn)機(jī)制從邊界路由器檢索可用的WSNs簇頭設(shè)備IP地址的列表，對(duì)于每個(gè)IP它向特定的資源發(fā)送一個(gè)GET請(qǐng)求，如coap：//board_ip：coap_port/.wellknown/core。這些資源通常運(yùn)行于Erbium瘦服務(wù)器上的嵌入式設(shè)備中，通過(guò)返回一個(gè)描述簇頭節(jié)點(diǎn)以及所在簇內(nèi)其它成員節(jié)點(diǎn)資源的特定的字符串進(jìn)行響應(yīng)。對(duì)于每一個(gè)響應(yīng)，discover-motes應(yīng)用程序在Actinium安裝一個(gè)克隆應(yīng)用程序作為相應(yīng)的嵌入式設(shè)備的“代理”。每個(gè)代理應(yīng)用程序都有與之對(duì)應(yīng)簇頭所在簇的（傳感器、執(zhí)行器等）全部資源，從而實(shí)現(xiàn)對(duì)Actinium上物理資源的映射。這樣，客戶端應(yīng)用程序可以有效訪問(wèn)到物理資源。

代理應(yīng)用程序的訂閱或通知方案很明確。在發(fā)現(xiàn)階段，Actinium檢測(cè)物理節(jié)點(diǎn)感知的信息，用于代理應(yīng)用程序?qū)π畔①Y源的訂閱。因此每個(gè)客戶端應(yīng)用程序可以向代理應(yīng)用程序訂閱可感知的信息而不是具體的物理設(shè)備。這樣嵌入式設(shè)備只需向他們的代理應(yīng)用程序發(fā)送通知，該應(yīng)用程序?qū)⑺袛?shù)據(jù)轉(zhuǎn)發(fā)給提出訂閱的用戶（見圖3）。如果沒(méi)有代理應(yīng)用程序，每個(gè)客戶端應(yīng)用程序?qū)⑺挠嗛喰枨蟀l(fā)送到Erbium服務(wù)器，服務(wù)器將存儲(chǔ)大量的客戶訂閱關(guān)系，不僅增加計(jì)算成本而且嚴(yán)重浪費(fèi)內(nèi)存，也導(dǎo)致從物理設(shè)備到Actinium的數(shù)據(jù)流量的明顯增加，從而影響設(shè)備的性能。

如圖3所示，discover-motes鏈接發(fā)現(xiàn)的每一個(gè)具有唯一名稱的IP地址，用來(lái)確定相應(yīng)的Actinium上的代理應(yīng)用，通過(guò)簡(jiǎn)單標(biāo)記名稱來(lái)識(shí)別使用物理資源。例如，要指向一個(gè)溫度傳感器，用戶必須寫一個(gè)路徑如/apps/running/board3/sensors/temp，而不是一個(gè)冗長(zhǎng)而不重要的IPv6地址。當(dāng)用戶想運(yùn)行一個(gè)應(yīng)用程序，每個(gè)編輯器組件（傳感器、執(zhí)行器）必須與相應(yīng)的物理資源路徑相關(guān)聯(lián)。將定義在發(fā)現(xiàn)階段的每組存儲(chǔ)下來(lái)，如果Actinium重新啟動(dòng)，物理設(shè)備集合中的任何變化都必須是一致的。

此外，發(fā)現(xiàn)網(wǎng)絡(luò)中的新節(jié)點(diǎn)或檢測(cè)當(dāng)前節(jié)點(diǎn)的斷開（或連接），在discover-motes應(yīng)用中以特定的線程集成。這個(gè)線程周期性輪詢，如在啟動(dòng)階段邊界路由器在路由表中發(fā)現(xiàn)新的節(jié)點(diǎn)，通過(guò)查詢/.well- known/core資源檢查已知IP，如果沒(méi)有收到答復(fù)就說(shuō)明沒(méi)有安裝相應(yīng)的代理應(yīng)用程序。

2.3 WebSocket/CoAP proxy

WebSocket /CoAP協(xié)議代理服務(wù)器是體系結(jié)構(gòu)的中間件，用于編輯器應(yīng)用程序和Actinium服務(wù)器之間的通信。WebSocket /CoAP協(xié)議代理服務(wù)器直接翻譯CoAP消息中來(lái)自用戶接口的請(qǐng)求，并發(fā)送給運(yùn)行在Actinium上的應(yīng)用程序，反之亦然。如圖4所示為代理服務(wù)器功能。

為了實(shí)現(xiàn)CoAP端的協(xié)議服務(wù)器，使用JavaScript語(yǔ)言開發(fā)的Node.js框架功能。需要特別注意的是發(fā)送所謂的分組信息，即負(fù)載的消息被分散成幾個(gè)連續(xù)的數(shù)據(jù)包。發(fā)送一個(gè)響應(yīng)數(shù)據(jù)包到WebSocket客戶端之前，包本身必須能夠被正確地接收。因此，需要集成一個(gè)特定的過(guò)程用來(lái)聚集零散的數(shù)據(jù)包。最后實(shí)施ad hoc機(jī)制，以同時(shí)觀察多線程資源。

WebSocket請(qǐng)求中的代碼完成協(xié)議服務(wù)器所管理的兩個(gè)協(xié)議之間的轉(zhuǎn)換，每一個(gè)代碼對(duì)應(yīng)協(xié)議的CoAP接口的特定命令。一旦接收到WebSocket請(qǐng)求，調(diào)用適當(dāng)?shù)腃oAP方法，基于WebSocket請(qǐng)求的其它參數(shù)創(chuàng)建CoAP消息。然后，通過(guò)UDP套接字將消息發(fā)送到CoAP服務(wù)器Actinium。反之，一旦代理服務(wù)器CoAP端接收到來(lái)自Actinium的響應(yīng)，用這個(gè)信息為WebSocket客戶端創(chuàng)建響應(yīng)的有效載荷。這樣CoAP通信對(duì)客戶端完全透明。

2.4 新的編輯器架構(gòu)

該編輯器建立的應(yīng)用程序不在本地瀏覽器中執(zhí)行，而是轉(zhuǎn)移到Actinium并通過(guò)圖形化界面控制。編輯器和代理服務(wù)器之間的相互作用是通過(guò)WebSocket通信的。

如圖5所示，新的架構(gòu)反映了使用編輯器的不同階段，前三層在編程階段使用。首先，庫(kù)層對(duì)編輯器的每個(gè)可視化組件的圖形和功能結(jié)構(gòu)就輸入、輸出的數(shù)量及配置方面進(jìn)行定義。數(shù)據(jù)模型層處理應(yīng)用程序控制流的創(chuàng)建和相關(guān)數(shù)據(jù)及依賴于組件之間的控件。其次，編碼層允許用戶在視覺(jué)上定義應(yīng)用程序及其儀表板的結(jié)構(gòu)。映射層負(fù)責(zé)映射算法的實(shí)現(xiàn)，它將視覺(jué)腳本翻譯為單一的JavaScript腳本文件。在執(zhí)行階段，用戶界面層處理用戶與圖形界面的交互。一方面，截取用戶的動(dòng)作并將其轉(zhuǎn)換為代理服務(wù)器的消息；另一方面在顯示界面中顯示來(lái)自服務(wù)器的更新消息，如推送通知。最后，通信層與代理服務(wù)器交互實(shí)現(xiàn)WebSocket客戶端。

3 結(jié)語(yǔ)

本文定義并實(shí)現(xiàn)了物聯(lián)網(wǎng)架構(gòu)，可與基于CoAP的WSNs進(jìn)行靈活通信。該架構(gòu)支持與無(wú)線傳感器網(wǎng)絡(luò)在不同層次相互作用，即從直接與物理設(shè)備通信到簡(jiǎn)化的組件層的節(jié)點(diǎn)的相互作用。應(yīng)用層提供了簡(jiǎn)單的APIs，專業(yè)的技術(shù)用戶可以使用任何編程語(yǔ)言開發(fā)應(yīng)用程序，而普通用戶可以使用簡(jiǎn)單圖形編輯器。架構(gòu)的核心組成部分是執(zhí)行系統(tǒng)所有業(yè)務(wù)邏輯的中間件，它將物理設(shè)備虛擬化，從而提高物理設(shè)備與用戶之間的通信效率。

通過(guò)一些技術(shù)和軟件支持，對(duì)所設(shè)計(jì)的解決方案進(jìn)行評(píng)估，雖然沒(méi)有完全解決物聯(lián)網(wǎng)智能對(duì)象之間的相互操作，但已實(shí)現(xiàn)了對(duì)物聯(lián)網(wǎng)體系結(jié)構(gòu)實(shí)例的改進(jìn)。

參考文獻(xiàn)：

[1]MAINETTI L，PATRONO L，VILEI A.Evolution of wireless sensor networks towards the internet of things：a survey[C].Software，Telecommunications and Computer Networks （SoftCOM），2011 19th International Conference on，Split，2011.

[2]湯春明，張熒，吳宇平.無(wú)線物聯(lián)網(wǎng)中CoAP協(xié)議的研究與實(shí)現(xiàn)[J].現(xiàn)代電子技術(shù)，2013，36（1）.

[3]古欣，禹繼國(guó)，王光輝.無(wú)線傳感器網(wǎng)絡(luò)分簇路由協(xié)議綜述[J].通信技術(shù)，2013，46（8）：P88-90.

[4]呂林濤，胡雷雷，楊宇祥，譚芳.基于LEACH協(xié)議的安全節(jié)能路由算法研究[J].計(jì)算機(jī)工程，2014，40（5）：P59-61，67.

[5]KOVATSCH M，DUQUENNOY S，DUNKELS A.A low-power CoAP for Contiki[C].IEEE Eighth International Conference on Mobile Ad-hoc & Sensor Systems，2011：855-860.

[6]DUNKELS A，GRONVALL B，VOIGT T.Contiki—A lightweight and flexible operating system for tiny networked sensors[C].Computational Systems Bioinformatics Conference，CSB，2004.USA：IEEE，2004：455-462..

[7]吳衍標(biāo)，熊勇，姚煒，梅小青，基于RESTful Web的智能家居系統(tǒng)應(yīng)用[J].計(jì)算機(jī)應(yīng)用，2015，35（A2）：P284-289，314.

（責(zé)任編輯：陳福時(shí)）