北京郵電大學 北京 100876
智能家居是以住宅為平臺,兼備建筑、網絡通信、信息家電、設備自動化,集系統、結構、服務、管理為一體的高效、舒適、安全、便利、環保的居住環境。它能夠利用綜合布線技術、智能家居系統設計方案、網絡通信技術、自動控制技術、音頻視頻技術、安全防范技術等將與家居生活有關的設施有機地結合在一起,構建一個高效的住宅設施與家庭日程事務的管理系統[1]。
物聯網(Internet of Things,IoT)是在信息社會中基于已有的以及發展中的相互協作的信息和通信技術,利用物理上或虛擬互聯的物體提供高層服務的全球性網絡[2]。而住宅的封閉性則非常適于局域網絡的搭建,實現特定區域內的物聯網。近年來,基于IoT技術的智能家居系統發展迅猛,特別是2014年,隨著谷歌公司收購Nest和蘋果公司推出HomeKit智能家居平臺,智能家居再次成為IoT產業的焦點。目前,制約智能家居系統普及的重要原因之一是接入設備眾多卻無統一標準,造成不同設備間難以互聯互通,更難實現聯動控制和綜合服務。盡管很多設備制造商正逐步開放其設備訪問操作接口API,很多智能設備管理平臺也提供開放接口,但設備之間、設備與用戶之間的互操作問題依然是智能家居系統面臨的一個重大考驗。
本文提出一種面向場景服務的智能家居中間件系統,該系統采用基于腳本解析的通用API適配技術,可將不同通信方式、不同操作接口標準的家電設備接入智能家居網絡中,進行統一控制;同時,系統通過對服務規則的形式化描述,提供用戶自定義規則與場景的功能,能夠讓用戶對多個設備操作進行組合,并利用時間或環境條件加以限定,實現智能化的環境控制。
智能家居系統通常由三部分構成:智能控制終端、智能家電設備和智能家居網關。其中,智能控制終端包含智能手機、平板電腦、個人電腦等常用電子產品,其作用相當于“遙控器”,用戶可以借助與系統配套的應用程序APP進行遠程操作,實現對家電設備的控制、對居家環境的觀測、對異常情況的監察等功能。
智能家電設備通常意義上指具有智能控制功能的家電設備,相比于傳統家電,智能家電設備往往在設計之初就預留了智能控制的接口。例如很多智能電視提供了網絡(IP、串口)控制的指令接口;一些智能空調更是自帶相應的手機APP,實現智能化控制。傳統家電可以通過附加智能控制器的方式進行智能化改造,例如只能接收紅外信號的家電,只需要安裝一個Wi-Fi轉紅外的轉換模塊,即可通過Wi-Fi實現對家電的控制。
除此之外,智能家電設備還包括一些專門負責采集環境數據的感知器節點。這類設備僅對環境的狀態如光照、濕度等進行數據采集和上報,但不會對環境產生直接影響,而是結合用戶所制定的規則與場景,配合智能家電設備,實現對環境的調節;因此,這些感知器也可以被內置于空調、智能溫度計等設備當中。
智能家居網關不僅為智能家電設備提供網絡通信接口,還可以成為智能家居系統的控制中心。一方面,它可以為智能控制終端提供數據訪問與操作控制接口,向用戶呈現相關的數據信息以及將用戶的控制命令轉發至相應設備;另一方面,它可以對所有接入設備進行統一管理,并通過提供用戶自定義規則與場景的功能讓用戶對多個設備操作進行組合,并利用時間或環境條件加以限定,實現個性化、自動化的環境控制。
工信部在2012年2月發布的《物聯網“十二五”發展規劃》中指出“物聯網已成為當前世界新一輪經濟和科技發展的戰略制高點之一,發展物聯網對于促進經濟發展和社會進步具有重要的現實意義”[3]。智能家居作為物聯網的重要新興產業之一,將得到資金、資源、技術、政策等多個方面的重點扶持,在用戶需求的激勵和國家政策的支持下,智能家居將進入一個前所未有的快速發展階段。國際物聯網貿易與應用促進協會在2014年1月發布的《2013年度中國智能家居行業研究報告》中顯示,未來三年,中國智能家居市場增速不斷提升,到2016年預計可達到29.17%,預測2017年中國智能家居行業市場規模將達80億元。
智能家居行業的巨大發展潛力也吸引了眾多廠商。2014年1月15日,谷歌宣布32億美金收購了美國的智能家居設備制造商Nest Labs;京東投資智能家居解決方案服務商BroadLink,并推出智能家居控制產品;2014年3月,小米公司的智能路由器開始內測,意圖成為智能家居的控制中心;2014年3月17日,美的與阿里巴巴簽署戰略合作協議,制造智能家電的同時,構建基于阿里云的物聯網開放平臺;2014年6月3日,蘋果公司在其全球開發者大會上發布HomeKit智能家居平臺,打造一個使用“通用協議”的多設備連接、管理平臺,以提升設備互聯的便捷性。同時,終端廠家為了使產品可以接入更多的系統,開放操作API已成為一種趨勢。
從提供整套解決方案的傳統智能家居系統Control4,到提供單一解決方案的飛利浦Hue Light(照明系統)和Nest Labs(溫控系統),再到提供智能終端設備的家電廠商和提供現有終端設備控制器的BroadLink,我們可以看出各個廠商都在從不同角度入手占領市場份額。集成了路由器功能的智能家居網關尤其受到青睞,其作為客廳入口和智能控制中心已經成為智能家居行業的一個重要切入點。
1) 便利性。智能家居系統首先要能夠為用戶提供便利的服務,實現隨時隨地的控制。無論在家中或在戶外,無論即時還是預定,無論人工操作還是自動觸發,用戶均能以簡單的操作完成對家居環境的智能調控。同時提供復雜場景的編程功能,一次編輯,隨后一鍵操作。
2) 兼容性。采用新技術的家居產品層出不窮,接口標準難以統一,設備間互操作性差,需要智能家居網關提供有效方法連接并打通接口各異的各種設備,并以邏輯設備的形式向用戶提供統一操控接口。
3) 穩定性。智能家居系統中所有設備通過網絡與智能家居網關連接,因此,網絡的穩定性將左右整個系統的運行狀態。系統要保障通信通道的暢通,保證設備始終處于已連接的可控狀態,使得用戶發出的指令能夠正確執行。
4) 安全性。智能家居系統中不僅涉及到常用智能家電設備,還包括智能感知節點,可以采集環境數據,并以數值、圖像、音頻、視頻等格式進行存儲,因此,可能包含大量的隱私信息,智能家居系統必須保證用戶信息不外泄。
上述特點中,便利性與兼容性是首先要解決的兩個重要問題。本文研究的智能家居中間件系統針對這兩方面的需求提出解決方案。
智能家居服務中間件系統是對現有家庭網關的智能化提升,使之不僅可以支持更多的通信方式和更多種類的設備,而且可以支持復雜的規則處理與場景設置,從而實現不同設備間的聯動與自動化控制。智能家居服務中間件系統的功能結構如圖1所示,主要包括通信管理、數據收發、事件驅動引擎、規則解析、驅動腳本解析和消息處理等模塊,以及設備與規則數據庫、設備驅動API腳本庫。

圖1 網關系統功能結構圖
設備與規則數據庫中存貯聯入網關的設備信息、用戶自定義的自動控制規則、場景模式和環境監測數據。設備驅動API腳本庫中以xml文件形式存貯了每種設備每個操作所對應的指令API,家居系統增加一種新類型的設備,只需加載一個新的設備驅動API腳本文件即可。
通信管理模塊負責維護各種設備與網關的網絡連接,數據收發模塊負責通信協議轉換,從而實現不同通信接口的消息格式與內部統一消息格式的轉換,完成基礎網關功能。
事件驅動引擎是服務中間件的核心模塊,它通過規則解析模塊分析用戶自定義規則或場景的觸發條件和操作目標,自動檢測環境數據的變化是否滿足這些觸發條件,如果滿足條件,則根據操作目標的設備類型選擇對應的驅動腳本API文件,自動解析API指令,并通過數據收發模塊將指令發給對應的設備。
消息處理模塊是服務中間件向智能控制終端提供的開放接口模塊,通過Rest風格的Web服務接口,用戶可以向系統添加設備、加載驅動腳本、設置服務規則和場景、發布控制命令、獲取環境數據等。
下面將重點介紹基于腳本解析的通用API適配機制、服務規則的形式化描述方法和基于事件驅動的規則執行引擎。
大量廠商進入智能家居市場導致的后果是各個廠家的智能設備依照自己的標準設計制造,無法進行統一,智能家居系統無法對其進行兼容;因此,我們設計了一種基于腳本解析的通用API適配方法。每添加一種新的品牌設備,只需加載一個新的設備驅動腳本文件;之后再添加一個該品牌的新設備,只需選擇其相應類型的驅動腳本文件,隨后,網關會對該類型的驅動腳本進行解析,依照腳本內容進行相應處理;因此,對于同類型的設備只需要選擇同樣的腳本文件,不必進行重復加載;對于新類型的設備,只需按照驅動模板編寫一個新的類型驅動腳本,不必在網關中進行復雜的設置。這種方法在很大程度上能夠解決網關的兼容性問題。驅動腳本文件包括設備信息配置和功能函數描述兩部分。
設備信息配置包含設備類型、通信方式、控制命令集、設備變量集、觸發事件集等信息。
1) 設備類型與通信方式。不同設備具有不同的通信方式,需要配置相應的通信參數。例如IP通信,需要配置通信端口; Zigbee通信,需要設置默認MAC地址;而串口等其它通信方式,則根據設備需要進行相應設置。
2) 控制命令集。不同設備提供不同的操作,例如燈光操作可有開、關、調亮、調暗,空調操作有設定溫度、制冷、制熱等,各個廠商在同類設備上可進行的操作有很大的相似性;因此,我們根據設備類型,在腳本中配置該種設備的控制命令的最大集合,保證支持大部分操作。
3) 設備變量集。部分智能設備在接收控制命令后會就自身狀態給出反饋,感知設備也會收集環境數據進行上報。為了記錄這些信息,我們引入變量,在腳本中設置設備相關的變量、類型與初始值,用于狀態描述。如燈光設備的變量為亮度,空調設備的變量包括溫度、模式、風速等。
4) 觸發事件集。腳本中還預留了一部分事件接口,以事件驅動的方式執行事件內容,以實現設備的直接控制、設備之間的聯動、感知設備的環境觸發等功能。
驅動腳本中的功能函數描述部分主要描述設備控制命令的適配方法。即使對于同樣的操作(如打開電器),不同設備接受的API數據格式也不同,因此,針對每種控制命令,其功能函數部分將描述如何將控制命令參數轉化為規定格式的數據包,并通過預先建立的通信線路發送至設備。針對接收設備反饋或接收監測數據的命令,功能函數部分將描述如何對接收數據包解析,并寫入數據庫或觸發相應事件等操作。
在智能家居環境中,用戶不僅希望對家電設備進行遠程操控,也希望能夠實現定時等自動服務,只需要預先設置好參數,不必親自動手也可以營造出想要的居家環境。比如在下班回到家后只需要開啟回家模式,客廳燈光會自動亮起,CD機開始播放音樂,熱水器也開始運轉,所有操作只需一鍵。又或者在炎炎夏日,當室內溫度超過25攝氏度,空調就會自動打開,省去人工步驟。這就是服務規則和自定義場景的作用。
為便于規則的管理與執行,本文參考了“事件—條件—動作”(ECA)模型來描述服務規則。ECA模型常被引入智能家居系統用于規則的描述與沖突檢測[4-5]。其語義為當事件發生時,觸發對條件的評估,若條件成立,觸發動作的執行[6]。在智能家居系統中,我們規定:一條服務規則是一個實現在特定條件下對設備的操作,而自定義場景是一條或多條服務規則的組合。例如我們希望在就寢時關燈,起床時打開窗簾。此時只需定義兩條規則,可分別執行;同時可以將其組合為一個場景,實現一鍵操作。
服務規則分為兩類:定時規則和即時規則。定時規則包含時間條件和規則動作兩部分,而即時規則僅包含規則動作。圖2展示了規則的組成與分類。

圖2 規則分類與組成
時間條件由多個時間屬性組成,如圖3所示。其中,起始時間和終止時間代表該條規則的有效期,只有在這兩個時間點之間的時間段內,時間條件才會被觸發;觸發時間是24小時制的一個時間點,表示規則動作部分會在該時間點被觸發;重復類型表示時間條件可以周期執行,分為星期重復和間隔重復兩種,相對應的,重復周期表示每周的星期幾或每幾天。

圖3 時間條件組成
規則動作包括環境觸發條件和設備動作。環境觸發條件由若干條件組組成,如圖4所示,條件組內可以有若干原子條件。原子條件之間、條件組之間均由一個連接符連接,連接符為“與”或“或”操作。原子條件由三部分組成:變量、邏輯運算符和變量參數,邏輯運算符包括:等于、不等于、大于、大于等于、小于、小于等于。對于用自然語言描述的條件,規則解析模塊負責轉換。如條件“當燈光亮度大于200lux時”,系統中以{LightLevel, >, 200 lux}的三元組形式記錄。設備動作由若干設備與對應的設備操作組成,以{設備, 動作名稱}的二元組描述。

圖4 環境條件組成
規則的執行依靠事件驅動,如“定時時間到”、“場景開啟”、“物理環境改變”等。基于ECA模型,事件驅動引擎將分析觸發條件和操作目標,如果滿足條件,則根據操作目標的設備類型選擇對應的驅動腳本API文件,自動解析API指令,并通過數據收發模塊將指令發給對應的設備。
根據服務規則的定義,觸發條件可以是場景啟動操作、定時觸發或變量觸發。圖5展示了規則觸發判定流程。

圖5 規則觸發流程圖
當用戶執行場景啟動命令時,系統查詢該場景所包含的規則并將之標記為有效;若為定時規則,則交由時間線程處理;若為即時規則,則觸發該規則。
時間線程負責定時觸發的判別,該線程定時遍歷所有定時規則的時間條件,若規則有效且當前時間與時間觸發點相符,則觸發該規則。
變量監測線程負責變量觸發,當接收到某環境或設備變量的數據后,該線程查詢所有與該變量相關的原子條件以及所有包含此原子條件的規則,若當前規則有效,則觸發該規則。
規則觸發過程包括環境條件的判斷以及環境條件成立時設備動作的執行。環境條件成立與否依賴于對其包含的所有條件組的判斷。系統首先將條件組轉換為析取范式,即將規則條件拆分為以“或”連接的形式,其中每一個合取子句被稱為原子條件串。然后對同一環境條件下的原子條件串、同一原子條件串下的原子條件分別進行遍歷。對原子條件進行解析,根據當前對應的變量數值判斷該原子條件成立與否。若任一原子條件不成立,則該原子條件串不成立。只要任一原子條件串成立,則環境條件成立。在規則中未設置環境條件以及環境條件成立的情況下,系統將執行預設的設備動作。
如圖6所示,設備動作執行時,首先根據設備信息查找其在建立網絡連接時所產生的句柄,確認連接的暢通,用于進行數據的傳遞。而后根據控制命令與驅動腳本中控制命令集的對應關系,通過腳本中的控制命令適配函數,將命令組裝為指定格式。最后將封裝好的數據包加入消息隊列,等待發送至指定設備。

圖6 設備動作執行流程
本文設計并實現了一種智能家居中間件系統,其主要優勢在于采用了通用API適配的方法對不同廠商的不同設備進行設備管理,提高了兼容性;引入了可進行時間、物理環境條件限定的服務規則以及對規則加以組合形成的場景,簡化了用戶的操作,提高了便利性。下一步將在中間件系統中增加安全管理組件,使之更加實用化。
參考文獻
[1]李成大,張京,倪繼烈.基于ZigBee無線通信技術的智能家居系統[J].電訊技術,2007,47(5):63-66
[2]ITU-T Y.2060-2012.Overview of the Internet of things[S].Switzerland Geneva:ITU-T,2012
[3]物聯網“十二五”發展規劃[EB/OL].(2012-02-14)[2014-09-07].http://www.gov.cn/zwgk/2012-02/14/content_2065999.htm
[4]Feng W,Turner K.Policy conflicts in home care systems[J].Feature Interactions in Software and Communication Systems IX,2008:54
[5]Ter Beek M H,Gnesi S,Montangero C,et al.Detecting policy conflicts by model checking UML state machines[C]//ICFI.2009:59-74
[6]McCarthy D,Dayal U.The architecture of an active database management system[C]//ACM Sigmod Record.ACM,1989,18(2):215-224