李曉偉+鄧紅霞+朱麗
摘要:物聯(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)階段的每組
此外,發(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í))