吳志輝



摘 要:智能家居是未來最大的市場之一,但其發展速度差強人意。文中對目前智能監控平臺,特別是智能家居系統的現狀進行了分析,研究并提出了一個設備互聯互通的解決方案,從而實現了通用智能監控系統。同時還描述了基于監控驅動程序中間件的監控平臺的架構、特性和工作原理,為智能家居的發展提供了不同的解決方案。該技術已申請發明專利,并在實際項目中得到了良好的應用。
關鍵詞:智能家居;物聯網;中間件;設備監控驅動;設備對象
中圖分類號:TP277 文獻標識碼:A 文章編號:2095-1302(2016)11-00-04
0 引 言
物聯網把萬物接入互聯網,使得人類監控這些物理設備的愿望得以實現。但前提是這些物理設備需要具備一定的智能特性,并符合生產廠商的通信規范才能在廠商提供的特定應用中與人類進行交互。如眾多的智能家居設備廠商,其家居產品能通過互聯網和智能終端設備(手機、平板電腦)與用戶遠程交互,極大地方便了主人對家庭電氣電子設備的監控。但互聯互通的問題仍未得到很好的解決。
如果購買了智能空調、智能冰箱、智能電視機、智能洗衣機、智能安防系統、智能門鎖、智能傳感器、智能穿戴式健康監護設備等眾多未來家庭必須的產品,那么主人的智能手機上可能需要安裝眾多廠商提供的App,只有通過它才能與各自的設備交互,使用極為不便。而這就是目前智能家居的現狀。
更為糟糕的是,這些異構的設備之間互不認識,無法“物物相連”進行交互,更無法滿足設備之間的聯動以達到主人需要的功能。如果檢測到火災發生,卻無法自動把家里的門鎖打開,若要滿足這個要求,只有使用一個廠商的整套設備才可以實現,而壟斷和價格高昂就成為必然,公民利益被綁架,也由此導致居民不愿意購買價格較高的“智能”設備,惡性循環,致使產業發展緩慢。因此設計一個親民的智能家居監控系統勢在必行。
1 解決監控平臺通用的方案
消費者自然希望通過單個App就可以監控家庭中的所有智能設備,不管這些設備來自哪個廠商。更加期望隨心所欲的定制設備間的聯動來自動完成主人需要的任務,即智能家居DIY,包括硬件DIY和監控行為DIY。
由于各廠商的設備通信協議不同或數據格式不同,用一個程序去滿足眾多設備的數據通信要求是極不現實的。正如互聯網絡和終端的多樣性,通過Web服務器可把異構網絡連接在一起實現數據共享。智能監控系統可提供類似的服務平臺,把不同設備系統的通信數據規范化,對外提供統一的監控協議(Smart Monitor Protocol,SMProtocol),任何移動終端設備(Mobile Terminal,MT)只要遵循SMProtocol的規范,就可與智能監控系統內部的各種異構的設備交互。這個輕量級協議就是物聯網中間件的主要組成部分之一。
盡管有很多智能家居監控的研究方案[1-3],但大多注重云平臺的研究。我們的方案則基于家庭微型服務器,在其中搭建運行中間件的智能家居監控服務平臺(SmatHome Platform,SHP),這是一種低成本、安全、擴展靈活的解決設備互聯互通的有效方案。智能家居服務平臺(SHP)由多個服務程序組成,可運行在低成本的微型PC、平板電腦或服務器中。SHP基于目前家庭最常用的網絡環境部署,其運行環境如圖1所示。
由圖1可知,移動終端通過互聯網或局域網與SHP交互。設備子系統(Equipment SubSystem,ESS)可以通過無線或有線方式與SHP通信。設備系統內部的通信與SHP無關,可選用ZigBee、藍牙、RS 232等方式。SHP通過中間件與設備系統交互。這種結構可以方便地把各種異構設備系統接入監控平臺,智能家居DIY得以實現,而我們只需要在SHP上安裝一個中間件。分析這個結構發現,我們完全不需要設備廠商提供的云平臺服務,同時無線設備系統不使用UPNP協議與智能移動終端直接通信。
2 通用監控平臺中間件的功能和設計
監控中間件必須具備以下幾點功能:
(1)對外提供統一的監控接口。
(2)監控子系統的內部設備系統負責把外部監控協議翻譯成特定設備系統的指令,從而實現對設備的監控。
(3)為監控服務平臺的其他程序提供設備狀態數據變化事件(DataChanged),以便服務平臺對設備狀態變化做出反應,從而實現設備間的聯動。
(4)中間件的通信足夠簡單,盡可能少修改設備系統的原有控制程序的工作量。
2.1 監控設備驅動程序中間件
各廠商內部的智能監控設備子系統(ESS)對外的通信方式有差別,有些使用串口設備通信,而有些使用TCP網絡通信協議,或采用有線或無線的方式通信。通信的數據格式更是千差萬別。這給中間件的開發設計帶來了困難。
借鑒操作系統管理硬件設備的方式,我們設計了一個應用層面的通用監控接口,用特定程序實現,即“監控設備驅動程序”(Monitor Device Driver,MDD)。每個監控驅動程序可與特定廠商的設備系統ESS交互,一個實例化的中間件可以監控一個設備子系統。
當SHP加入一個新的設備子系統時,我們只需要動態加載其監控驅動程序。由監控服務平臺統一協調管理各監控驅動程序。
2.2 監控驅動程序中間件的設計
監控驅動程序必須實現一個智能設備子系統ESS的接口,以便管理其中的所有設備。每個設備也必須實現一個接口,使其能對設備進行監控。監控驅動程序接口設計類圖如圖2所示。
(1)ISmartHome接口定義了特定廠家某個產品的設備或設備子系統,其中可以包含多種不同的設備IhomeDevice。
(2)IHomeDevice由六類不同的子設備組成。目前看來,六類子設備能很好的抽象家居設備系統。它們是數值量輸入輸出設備IDeviceDI,IDeviceDO;模擬量輸入輸出設備IDeviceAI, IDeviceAO;流輸入輸出設備IDeviceSI, IDeviceSO。理論上,這六類子設備的組合可以描述任意復雜的設備。
(3)IBaseDevice接口是六類設備的父接口,描述了設備的通用接口規范。
(4)IWriteReadInterface接口用于設備數據的存儲、讀取。
設計實現了圖2接口的監控驅動程序,完整的描述了一個設備子系統,具備對其中任意一個子設備的監控能力。在應用驅動程序中,按照智能監控的通用協議(SHProtocol)把外來監控數據轉換為控制設備的指令,同時把設備的狀態數據轉換為SHProtocol規范格式,并回送給移動終端,從而完成監控交互。
在六類設備中,引入了事件接口(Event),使得設備狀態發生變化時,SHP能及時獲得通知,從而有機會對設備進行控制。
2.3 監控驅動程序中間件協議的設計
已有廠商的設備系統通信數據格式眾多且不統一。為了盡可能減少設備嵌入式程序的修改,又能方便數據轉換,設計一個數據字典來規范數據格式,SHP設計的通信數據包程序如下:
public class stringJson
{
public Dictionary
Int32 smarthomeflag = 0xAA11; //某廠商設備系統通信的標志,不是的,不處理
public stringJson(Int32 _flag)
{
mDictionary = new Dictionary
smarthomeflag = _flag;
}
……
}
字典結構為Dictionary
3 通用監控平臺設計及實現
雖然監控驅動程序中間件在SHP中扮演著重要角色,但管理這些驅動也極其重要。SHP針對每個設備系統啟動一個監控服務程序(SmartHome Monitor,SHM),SHM加載相應的監控驅動程序與設備子系統交互。通過SHP與SHM的隔離,移動控制終端對ESS的監控就能統一。智能監控系統的結構示意圖如圖3所示。
由圖3可知,SHM可能有多個,ESS可以包含N個子設備(SubDevice,SD),該架構由移動應用層、監控管理層、設備監管層、硬件設備層組成。
3.1 移動應用層
MT或PC使用規范的SMProtocol和TCP/IP協議與SHP交互。如果MT與SHP在同一局域網內,MT使用指定的端口號和IP地址登錄SHP;否則使用域名與SHP連接。MT使用一個App就可以通過SHP監控所有設備。
3.2 監控管理層
監控管理層(Management Layer)是局域網內的一臺服務器(Smart Home Server,SHS),通過路由器、網關接入互聯網。服務器程序由多個服務模塊組成。SHS的組成及其關系如圖4所示。
User Management維護可以接入平臺的人員信息,賦予賬號、密碼和權限。只有登錄系統,用戶才能接入SHP平臺監控智能家居系統。User Management的UI界面如圖5所示。
Session Management可實現通信會話管理。使用TCP/IP接收Application Layer發來的協議指令,使用進程間通信方式(IPC)轉發數據給處在Monitor Layer中的對應SHM。同時接收Monitor Layer發來的設備狀態數據,然后轉發給所有在線的MT。對非法連接的MT,自動斷開回話。Session Management定義的連接端口如圖6所示。
PNP Management:SHProtocol定義了PNP消息廣播協議。當ESS在局域網廣播此消息時,SHP就獲取ESS的監控驅動程序名稱、驅動下載地址、通信方式等信息,SHP會自動下載ESS的驅動程序,注冊并啟動一個SHM來與設備系統交互。PNP Management定義的廣播端口如圖7所示。
圖7 PNP Magagement定義了廣播端口
Device Management用以管理所有符合ISmartHome接口規范的監控驅動程序,提取并保存所有ESS的數據信息。對不支持PNP的設備系統可以人工注冊。Device Management還負責啟動并傳遞適當參數給SHM,必要時可以強行結束SHM。Driver Management實現UI界面如圖8所示。
Device Management可以自動搜索所有MDD,注冊登記需要接入平臺的設備驅動或移去注冊的驅動。
Task Management:用戶需要的操作功能有時需要對不同設備進行一連串的操作才能實現。可以定制任意數量的設備操作步驟,即通過任務來達到目的。定時任務也可以指定實現主人在特定時間啟動設備控制的要求。還可以為每天指定不同的定時任務,更加精細的滿足主人要求。因為SHS知曉所有ESS的信息,所以Task Management可以直接操控設備,這為設備間的復雜聯動提供了基礎。Task Management的實現UI如圖9所示。
一個任務可以包含多個不同設備的控制,指定其先后次序和延時。
Event Monitor Management負責監視設備的狀態是否發生變化。可以對感興趣的數據設置變化響應機制,為自動控制提供了觸發機制。事件響應的設置界面如圖10所示。
對所有設備系統的輸入設備(DI,AI,SI)進行響應設置,為其指定一個任務。
可以看出,Device river Management在SHS中扮演著重要角色。而現在可以輕松實現諸多家庭任務。比如周三早晨10點自動啟動花園的澆水系統,如果下雨,則自動停止澆水。
3.3 設備監控層
設備監控層(Monitor Layer)由多個智能監控服務程序SHM組成。它與SHP之間使用規范的SMProtocol和進程間通信機制進行通信。SHM運行時的通用監控畫面如圖11所示。
SHM動態加載設備子系統的監控驅動程序,并根據驅動通信要求啟動適當的通信程序,它接收來自SHS的指令,并傳遞給驅動程序,由驅動程序翻譯成能控制設備系統的具體指令,從而達到控制設備的目的。驅動程序收到的設備狀態數據轉換為符合SMProtocol協議的規范數據,通過SHM上傳給SHS,最終傳遞到移動終端。
SHM與ESS的通信方式根據ESS驅動程序的要求來制定。SHM可以作為服務器工作,也可以作為客戶端工作,這些均由驅動程序決定。SHM作為TCP/IP通信服務端的設置界面如圖12所示。
3.4 硬件設備層
硬件設備層(Device Layer)由不同類型的子設備系統組成。它們可以是智能的、非智能的硬件系統,也可以是虛擬設備系統。它需要根據相應的驅動程序的規范,做一些程序上的修改來滿足通信要求。如車載導航系統,在修改程序后可遠程接入SHM,這樣家庭成員可以隨時了解小車的位置和狀態。健康監護腕帶設備在編寫監控驅動程序并適當修改原來的通信程序后,可以接入SHM,方便的將家庭老人或病人的信息及時傳遞給家庭成員或者遠方的醫療監護系統。
ESS與其內部子設備的交互幾乎不變,可以最大限度保護已有投資。把現有很多應用程序按SMProtocol協議為其編寫監控驅動程序,適當修改應用程序的通信方式,將其改造為一個虛擬設備系統,可以接入SHP,由MT進行監控。如運行在PC機上的家庭影院或背景音樂系統,都可以設計成虛擬設備系統。
4 SHP的優勢
SHP提供了一個安全、易于實現、易于使用、低成本的智能家居運行環境。其具有如下優點:
(1)安全性。MT與內部設備系統交互的唯一方式是通過登錄SHP接入監控平臺。登錄需要賬號與密碼。在監控驅動程序級別,還可以設置授信名單和黑名單,防止非法授權操作設備。SHP運行在家庭內部的PC或服務器上,安全性較高。也可斷開與外界的通信,僅在家庭局域網內工作。這與傳統的在Web服務器上部署Web服務的方式不同,與設備通過藍牙與手機進行直連交互的方式更不同。
(2)易于實現。任何實現IsmartHome規范的設備監控驅動程序都可以接入SHP。理論上,只需要在SHP安裝設備監控驅動程序,就可以方便監控任意復雜的設備系統,同時數據存儲和挖掘功能也可以在SHP實現。SHP可能是未來家庭服務器的重要組成部分。而SMProtocol通信協議足夠簡單且能滿足任意復雜監控的需求,硬件設備的原有嵌入式程序只需修改或增加通信部分即可接入SHP。設備廠商投入較小的成本就可升級傳統產品為智能家居產品。原來需要廠商搭建的云服務平臺或可取消,極大地減輕了廠商的負擔和運行費用。
(3)易于使用。SMProtocol協議保證了監控系統對外交互的統一界面。只需一個應用App就能方便監控整個智能家居系統,并任意指定設備間的聯動操作需求。通過監視感興趣的事件,可以實現自動報警。用戶對智能家居DIY成為現實,包括硬件DIY,監控需求DIY等。
(4)低成本。SHP可部署在200美元內的平板電腦、低端PC或服務器上(功率<20 W),Windows或Linux操作系統都可以。一個家庭只需一個SHP即可智能家居DIY。這也許是SHP的缺點——微型服務器必不可少。如果把網關、路由器等功能集成在專用的微型服務器上,或可降低成本。
5 結 語
該智能家居聯網技術已經申請了發明專利,并在特定行業得到了應用。若該方案能得到大力推廣,那么其在智能家居行業的意義將不亞于TCP協議對于互聯網的重要性。因為缺少統一的智能家居行業標準,開放式智能家居永遠都不可能實現井噴式發展。
參考文獻
[1]E. Kaldei, E.U. Warriach, J. Bresser, et al. Interoperation, composition and simulation of services at home [C]. 8th Int. Conf. on Service Oriented Computing(ICSOC-10), Springer, vol. LNCS 6470, (2010): 167-181.
[2]Muhammad Waqar Aziz. Service-Oriented Layer Atchitecture for Smart Home[J]. International Journal of Smart Home, 2013, 7(6) : 409-418.
[3]NamKyung Lee, Hyum Woo Lee, Won Ryu.Consideration for Web of Object Service Architecture on IoT Environment[J]. International Journal of Smart Home, 2015, 9(1) : 195-202.