基于無線傳感網絡分簇結構的軟件架構

李曉偉+鄧紅霞+朱麗

摘要：物聯網將數十億的“物”連接到互聯網上，具有傳感、驅動及數據處理的能力。在物聯網中，用戶可以收集感知的信息，并最大化利用其價值。然而，在目前的應用解決方案中，對物理對象訪問的可擴展性和有效性并不高，只有專業人員才能夠開發應用程序。基于上述問題，利用約束應用協議（CoAP）對已存在的軟件架構進行改進，虛擬化無線傳感設備的簇頭，使其通過上層的表述性狀態傳遞（REST）接口，只與自身的虛擬化設備交互。此外，該系統提供了便捷的開發工具，允許不同技術層次的用戶進行應用程序開發。

關鍵詞：物聯網；無線傳感網絡；約束應用協議（CoAP）

DOIDOI：10.11907/rjdk.171647

中圖分類號：TP303

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

0 引言

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

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

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

1 架構原理和設計

物聯網架構的整體目標是方便用戶開發應用程序。為此，架構需遵循以下原則：

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

（2）高可用性的體系結構，以保證用戶直接且無處不在的訪問。用戶應該能夠通過不同類型的平臺和系統訪問使用智能對象和服務。

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

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

上述條件給設計帶來很多挑戰。

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

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

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

2 架構實例

對于所設計的體系結構主要由3個組件實現，第一個組件是CoAP服務器Erbium[5]，是CoAP對Contiki的實現[6]。第二個組件是應用程序服務器Actinium，處理JavaScript應用與CoAP設備的交互執行。最后一個組件腳本編輯器是實現運行于瀏覽器中的應用程序的圖形工具。

最底層由于Erbium的瘦服務器適應于現有的硬件，所以它為每一個嵌入式設備提供了RESTful接口[7]。而中間層解決了物理網絡通信優化問題，特別是應用程序服務器Actinium擴展延伸，為該體系結構上下層提供了關鍵功能。

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

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

2.1 調整Erbium瘦服務器

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

2.2 擴展Actinium服務器

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

代理應用程序的訂閱或通知方案很明確。在發現階段，Actinium檢測物理節點感知的信息，用于代理應用程序對信息資源的訂閱。因此每個客戶端應用程序可以向代理應用程序訂閱可感知的信息而不是具體的物理設備。這樣嵌入式設備只需向他們的代理應用程序發送通知，該應用程序將所有數據轉發給提出訂閱的用戶（見圖3）。如果沒有代理應用程序，每個客戶端應用程序將它的訂閱需求發送到Erbium服務器，服務器將存儲大量的客戶訂閱關系，不僅增加計算成本而且嚴重浪費內存，也導致從物理設備到Actinium的數據流量的明顯增加，從而影響設備的性能。

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

此外，發現網絡中的新節點或檢測當前節點的斷開（或連接），在discover-motes應用中以特定的線程集成。這個線程周期性輪詢，如在啟動階段邊界路由器在路由表中發現新的節點，通過查詢/.well- known/core資源檢查已知IP，如果沒有收到答復就說明沒有安裝相應的代理應用程序。

2.3 WebSocket/CoAP proxy

WebSocket /CoAP協議代理服務器是體系結構的中間件，用于編輯器應用程序和Actinium服務器之間的通信。WebSocket /CoAP協議代理服務器直接翻譯CoAP消息中來自用戶接口的請求，并發送給運行在Actinium上的應用程序，反之亦然。如圖4所示為代理服務器功能。

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

WebSocket請求中的代碼完成協議服務器所管理的兩個協議之間的轉換，每一個代碼對應協議的CoAP接口的特定命令。一旦接收到WebSocket請求，調用適當的CoAP方法，基于WebSocket請求的其它參數創建CoAP消息。然后，通過UDP套接字將消息發送到CoAP服務器Actinium。反之，一旦代理服務器CoAP端接收到來自Actinium的響應，用這個信息為WebSocket客戶端創建響應的有效載荷。這樣CoAP通信對客戶端完全透明。

2.4 新的編輯器架構

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

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

3 結語

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

通過一些技術和軟件支持，對所設計的解決方案進行評估，雖然沒有完全解決物聯網智能對象之間的相互操作，但已實現了對物聯網體系結構實例的改進。

參考文獻：

[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]湯春明，張熒，吳宇平.無線物聯網中CoAP協議的研究與實現[J].現代電子技術，2013，36（1）.

[3]古欣，禹繼國，王光輝.無線傳感器網絡分簇路由協議綜述[J].通信技術，2013，46（8）：P88-90.

[4]呂林濤，胡雷雷，楊宇祥，譚芳.基于LEACH協議的安全節能路由算法研究[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的智能家居系統應用[J].計算機應用，2015，35（A2）：P284-289，314.

（責任編輯：陳福時）