李曉偉+鄧紅霞+朱麗

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

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

DOIDOI：10.11907/rjdk.171647

中圖分類號：TP303

文獻標識碼：A 文章編號：1672-7800（2017）006-0019-03

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

2 架構(gòu)實例

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

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

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

按照所描述的設(shè)計原則，用戶可以通過不同方法開發(fā)和部署自己的應(yīng)用程序，如利用圖形編輯，通過連接WebSocket/CoAP協(xié)議代理，或通過安裝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ù)的過程中，WSNs根據(jù)路由算法找到傳感器中的簇頭節(jié)點，簇頭的個數(shù)與WSNs分布大小稠密有關(guān)。每個簇頭傳感器都作為資源在Erbium注冊，并以[resource_name]_handler的格式為其定義一個處理程序。在收到一個請求后，處理程序輪詢傳感器，并使用該傳感器狀態(tài)作為有效載荷構(gòu)建響應(yīng)消息。同樣的方法用于執(zhí)行器，但所定義的處理程序要求能夠響應(yīng)獲取和發(fā)布請求。定義在Erbium上的一個可訂閱傳感器，在它自身狀態(tài)發(fā)生變化時實現(xiàn)一個event_resource，將新的設(shè)備狀態(tài)生成一個通知，通知訂閱所有此傳感器的應(yīng)用程序。

2.2 擴展Actinium服務(wù)器

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

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

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

此外，發(fā)現(xiàn)網(wǎng)絡(luò)中的新節(jié)點或檢測當(dāng)前節(jié)點的斷開（或連接），在discover-motes應(yīng)用中以特定的線程集成。這個線程周期性輪詢，如在啟動階段邊界路由器在路由表中發(fā)現(xiàn)新的節(jié)點，通過查詢/.well- known/core資源檢查已知IP，如果沒有收到答復(fù)就說明沒有安裝相應(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消息中來自用戶接口的請求，并發(fā)送給運行在Actinium上的應(yīng)用程序，反之亦然。如圖4所示為代理服務(wù)器功能。

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

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

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

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

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

3 結(jié)語

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

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

參考文獻：

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

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

[4]呂林濤，胡雷雷，楊宇祥，譚芳.基于LEACH協(xié)議的安全節(jié)能路由算法研究[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]吳衍標，熊勇，姚煒，梅小青，基于RESTful Web的智能家居系統(tǒng)應(yīng)用[J].計算機應(yīng)用，2015，35（A2）：P284-289，314.

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