物聯(lián)網(wǎng)通用應用層架構設計
引言
物聯(lián)網(wǎng)系統(tǒng)通??捎蒑2M應用平臺、用戶側的匯聚網(wǎng)關和用戶側若干傳感器組成。由于物聯(lián)網(wǎng)設計的行業(yè)種類繁多,目前的應用平臺和匯聚網(wǎng)關一般都由一個廠家提供,他們之間的通信協(xié)議也是私有的。而這又限制了應用的迅速開發(fā)和升級開發(fā)。
為此,本文設計了一種在匯聚網(wǎng)關上的通用應用層(CAL)架構。通用應用層(CAL)可對外提供統(tǒng)一的應用編程接口(API),并可屏蔽傳感器通信差異的技術細節(jié)。文中詳細介紹了通用應用層的分層架構模型,并針對不同性質的傳感器應用設計了不同的API。采用該通用應用層架構的物聯(lián)網(wǎng)系統(tǒng)可以進行匯聚網(wǎng)關和業(yè)務平臺的獨立開發(fā)和部署。
1 技術背景
物聯(lián)網(wǎng)(M2M)作為當前迅猛發(fā)展的新技術,已經(jīng)成為當前的熱點話題。物聯(lián)網(wǎng)技術必將帶來一場深刻的科技變革,帶來人類科技文明的飛躍。物聯(lián)網(wǎng)的范圍非常廣,業(yè)內(nèi)預測:物聯(lián)網(wǎng)終端用戶將是手機等移動通信終端用戶數(shù)量的數(shù)十倍。物聯(lián)網(wǎng)的種類和跨行業(yè)十分廣泛,從家庭、企業(yè)、到各個行業(yè)。應用范圍包括電力行業(yè)的遠程抄表、配輸電設備監(jiān)控、重點污染源監(jiān)控、氣象檢測、車輛管理、水文檢測、物流運輸、移動POS等業(yè)務,而且其它行業(yè)的物聯(lián)網(wǎng)應用還有不少。物聯(lián)網(wǎng)的實質是利用無線或有線通信技術,通過互聯(lián)網(wǎng)實現(xiàn)各種物品的管理控制和信息共享。物聯(lián)網(wǎng)數(shù)量龐大、行業(yè)眾多,實現(xiàn)的技術多種多樣。物聯(lián)網(wǎng)設備接入網(wǎng)絡的通信協(xié)議一般有Zig-Bee、藍牙、Wi-Fi、Z-Wave等。
2 目前物聯(lián)網(wǎng)體系框架存在的弊端
物聯(lián)網(wǎng)(M2M)實現(xiàn)中,一般要在家庭或企業(yè)側部署一個M2M網(wǎng)關,該網(wǎng)關可以是單獨設備,也可以和路由器、寬帶網(wǎng)關集成,主要負責傳感器和應用平臺之間的通信,它一方面由M2M網(wǎng)關接收應用平臺的管理或操作指令,另一方面,M2M網(wǎng)關還負責傳感器狀態(tài)的監(jiān)視和數(shù)據(jù)的采集。
物聯(lián)網(wǎng)在各個行業(yè)都有非常專業(yè)的需求,因而每個行業(yè),甚至每個部門都有自己的M2M應用平臺。M2M網(wǎng)關給M2M應用平臺提供的通信接口沒有統(tǒng)一的標準,這樣,應用平臺就必須對M2M網(wǎng)關作定制開發(fā)。在沒有統(tǒng)一接口標準的情況下,應用平臺接口開發(fā)、調試工作量很大,另外,當M2M更換設備時,平臺也要重新作適配開發(fā)。因此,物聯(lián)網(wǎng)的飛速發(fā)展迫切需要定義統(tǒng)一的接口標準和通用的M2M網(wǎng)關架構。目前業(yè)界設計的平臺開發(fā)架構多側重于物聯(lián)網(wǎng)運營支撐的平臺架構,其結構如圖1所示。
3 通用應用層的架構和關鍵技術
3.1 通用應用層架構和系統(tǒng)接口
M2M網(wǎng)關引入通用應用層(CAL)架構有助于解決應用平臺和網(wǎng)關之間的標準統(tǒng)一,也有助于M2M網(wǎng)關的標準化。通用應用層可向M2M應用平臺提供通用的應用編程接口(API),以便應用平臺不再關心M2M網(wǎng)關的差異。通用應用層(CAL)的系統(tǒng)接口如圖2所示。
傳感器管理平臺也可使用通用應用層提供的API,其中管理平臺可能是應用平臺的一部分,也可能是獨立的平臺。不同行業(yè)甚至可以共享一個管理平臺,比如由電信運營商提供M2M網(wǎng)關的情形,設備的管理即由電信運營商管理,而業(yè)務采用各行業(yè)自建的平臺。
通用應用層可提供不同形式的API:其一是對實時性要求較高的應用,可采用基于TCP/UDP的私有協(xié)議;其二是對實時性要求較低的應用,如管理、配置類通信請求,采用業(yè)界通用的WebService接口。
通用應用層技術還可以提供應用平臺SDK開發(fā)包,開發(fā)者無需關心通信的底層協(xié)議,從而可以讓開發(fā)者專注于M2M應用開發(fā)。
3.2 通用應用層的分層結構
圖3所示是通用應用層的分層邏輯架構。由圖可見,該應用層分為四層架構,現(xiàn)分別描述如下:
(1) 接口層
接口層主要是和各種傳感器的接口。該層能適配各種傳感器通信協(xié)議,如Zigbee、Z—Wave、UPnP、LON、DLNA等。
(2) 數(shù)據(jù)分析層
數(shù)據(jù)分析層主要是對主動采集的信息、設備上報的告警信息、事件信息等進行統(tǒng)一過濾和分析,只有超過用戶設置的閾值才會向用戶發(fā)送告警信息;同時對釆集的數(shù)據(jù)進行預處理,丟棄無用信息,并可轉換采集的數(shù)據(jù)格式;另外就是進行簡單的統(tǒng)計分析,供應用査詢;再就是提供數(shù)據(jù)的短時間的存儲。設計這一個策略層的目的就是減輕應用邏輯層的數(shù)據(jù)過濾和處理的壓力,提高系統(tǒng)的整體性能。
(3) 應用邏輯層
應用邏輯層主要是對應用的請求進行處理。主要包含應用認證、傳感器監(jiān)控定制、傳感器狀態(tài)察看、傳感器遠程控制、傳感器變化通知、傳感器管理、傳感器報警、傳感器配置等八大類業(yè)務邏輯處理模塊。應用認證模塊的目的是防止未經(jīng)授權的應用來訪問傳感器;傳感器監(jiān)控定制模塊用于接收應用的訂購監(jiān)控請求,并保存;傳感器狀態(tài)察看模塊接收應用的傳感器狀態(tài)査詢請求,并從傳感器獲得相應狀態(tài),然后返回給應用;傳感器變化通知模塊根據(jù)傳感器監(jiān)控定制模塊存儲的定制請求,定期查詢傳感器狀態(tài),有符合應用定制要求的,就主動通知應用;傳感器管理主要關注傳感器工作狀態(tài)的管理,而不是對傳感器業(yè)務的管理;傳感器報警模塊接收數(shù)據(jù)分析層的告警信息,并發(fā)送到管理平臺;傳感器配置用于接收管理平臺的配置工單,并正確配置傳感器的參數(shù)。
(4) API層
API層可提供一系列的API,以供應用平臺和管理平臺調用。API主要包括認證API、訂購API、査詢API、控制API、通知API、告警API和配置API等。
3.3通用應用層API
通用應用層提供有一系列的APL可根據(jù)應用的不同提供WebserviceAPI和實時響應的自定義API。與管理相關的API對實時性要求不高,可以采用WebServiceAPI0而傳感器狀態(tài)監(jiān)控、控制命令下發(fā)則對實時性要求很高,故需要釆用實時性較強的通信技術。表1所列是通用應用層編程接口(API)的主要分類。
4 輪渡和大橋交勇監(jiān)控中的通用應用層應用
大江、大河的輪渡和大橋的交通運輸一般都部署了各種傳感器,如車輛載重傳感器、擋竿傳感器、風速傳感器、路燈傳感器等。因此,在大橋或輪渡監(jiān)控中心部署交通監(jiān)控應用平臺,若沒有使用具有通用應用層技術的采集網(wǎng)關,應用平臺就必須開發(fā)和釆集網(wǎng)關的私有接口,而且開發(fā)調試比較困難,另外,應用平臺的通用性也將受到限制。使用具有通用應用層技術的采集網(wǎng)關可簡化開發(fā)周期,應用平臺直接集成有通用應用層技術可提供的SDK。圖4所示是通用應用層技術在輪渡大橋監(jiān)控系統(tǒng)中的應用示例。
在圖4所示的示例中沒有部署單獨的管理平臺,其采用通用應用層技術的輪渡和大橋交通監(jiān)控的應用流程如下:
(1) 應用平臺通過通用應用層API接口配置傳感器參數(shù);
(2) 應用平臺通過通用應用層API接口訂購應用平臺要監(jiān)測的傳感器及相關的狀態(tài);
(3) 通用應用層監(jiān)測應用平臺訂購的傳感器,并把符合應用平臺監(jiān)測要求的狀態(tài)發(fā)送給應用平臺;
(4) 應用平臺通過通用應用層API接口查詢傳感器的狀態(tài)(該步驟和2,3步無前后關系)。
5結語
通用應用層的提出能促進物聯(lián)網(wǎng)業(yè)務平臺的快速開發(fā)和部署,幫助物聯(lián)網(wǎng)應用開發(fā)者屏蔽傳感器通信差異的技術細節(jié)。然而,為促進物聯(lián)網(wǎng)網(wǎng)關的標準化,通用應用層內(nèi)部的技術細節(jié)還有待進一步研究。