智能家居情境感知服務的運行時建模與執行方法?

陳 星 , 黃志明 , 葉心舒 , 馬 鄆 , 陳藝燕 , 郭文忠

1(福州大學 數學與計算機科學學院,福建 福州 350108)

2(福建省網絡計算與智能信息處理重點實驗室(福州大學),福建 福州 350108)

3(清華大學 軟件學院,北京 100084)

隨著智能家居基礎設施的不斷發展,智能家居逐漸進入以智能服務為特征的新時期,智能機器人、智能穿戴設備和智能家電等大量復雜、異構的新設備接入網絡,進行交互和協同,以實現智能化識別、監控等海量應用[1-3].其中,溫度調節、空氣調節等情境感知服務,根據服務對象所處情境的變化為其提供準確的溫度控制、空氣凈化等服務,是智能家居應用的典型代表.目前,情境感知服務往往面向場景進行構建,主要面臨兩個方面的挑戰.

?一是設備的多樣性:智能設備在其功能、品牌和型號等方面存在差異,往往提供不同的數據讀取和功能調用方式,給設備的交互、協同帶來極大復雜度.

?二是服務的隨需性:存在不同類型的服務需求,需要建立情境知識與智能設備間的關聯關系,給服務的管理邏輯編寫帶來極大的復雜度.

智能家居情境感知服務實際上是對服務對象所處情境的各種信息進行收集、分析、決策和實施的過程.從系統實現的角度看,需要使用場景中智能設備的管理接口來獲取各種信息,并根據具體的服務需求對這些信息進行分析、決策和實施.例如在環境監控服務中,通過對房間的光亮、溫度和空氣質量等條件進行監測,從而自動地對電燈、空調和空氣凈化器等智能設備進行管理.然而,目前的情境感知服務開發,往往使用C/Java 等通用語言直接調用智能設備提供的管理接口,這種編程方式具有良好的適應性,但會帶來高昂的編程開銷.開發者必須熟悉不同智能設備的管理接口,才能實現它們的交互.此外,由于應用系統建立在與特定智能設備綁定的底層代碼的基礎上,其管理邏輯無法復用;即使管理機制類似,開發者仍需要開發多個應用系統來適應不同場景.

智能家居情境感知服務開發面臨的主要問題是:其問題域與系統實現間存在著鴻溝,通過手工編碼實現問題域到系統實現的映射,會帶來巨大的編程復雜性.知識圖譜用來描述客觀世界的概念、實體、事件及其之間的關系[4-6],能夠扮演系統需求與系統實現之間的橋梁,可以用來解決智能家居情境感知服務需求到實現的映射過程中,系統復雜性所帶來的問題.然而,將知識圖譜引入到情境感知服務的開發過程中,仍面臨以下兩個方面的挑戰.

?一方面,知識圖譜難以表示服務對象所處情境的變化.知識圖譜能夠組織結構化數據,用實體和關系進行知識表示.但是情境知識表示要求知識圖譜能夠感知實時場景信息,而現有的知識圖譜技術難以反映數據的實時變化.

?另一方面,面向不同服務需求構建推理規則工作量大.知識圖譜用來表示情境信息,并通過推理規則實現情境感知服務的自動執行.但是智能家居服務具有開放、動態、多變的特點,給推理規則的構建帶來極大復雜度.

為了能夠根據場景快速定制和開發智能家居情境感知服務,本文提出一種智能家居情境感知服務的運行時建模與執行方法.首先提出智能家居情境感知服務知識圖譜概念模型,定義其情境中的各種概念和關系;其次,提出智能家居情境感知服務知識圖譜實例模型的構造與維護機制,通過運行時概念、關系實例表示情境知識;最后,提出基于知識推理的智能家居情境感知服務執行方法,通過知識推理自動執行設備功能.面向實際場景,構建智能家居原型系統.實驗結果顯示,該方法能夠實現情境感知服務運行時建模與執行,其代碼減少量超過90%.

本文第1 節概述方法的整體框架.第2 節介紹智能家居情境感知服務知識圖譜概念模型.第3 節介紹智能家居情境感知服務知識圖譜實例模型的構造與維護機制.第4 節介紹基于知識推理的智能家居情境感知服務的執行方法.第5 節介紹實例研究并對方法進行評估.第6 節與相關工作進行比較.第7 節總結全文并展望未來的工作.

1 方法概覽

圖1 是智能家居情境感知服務的運行時建模與執行方法概覽.方法將知識圖譜引入到服務開發過程中,通過情境知識定義、情境知識表示和情境知識推理,實現情境感知服務的開發自動化.該方法主要包含3 部分工作:1)智能家居情境感知服務知識圖譜概念模型;2)智能家居情境感知服務知識圖譜實例模型運行時建模方法;3)基于知識推理的智能家居情境感知服務執行方法.

Fig.1 Overview of approach to modeling and executing context-aware services of smart home at runtime圖1 智能家居情境感知服務的運行時建模與執行方法概覽

?首先提出智能家居情境感知服務知識圖譜的概念模型.概念模型是描述智能家居場景中概念和關系等抽象元素的統一模型,定義了位置、用戶、環境、設備、服務等概念以及位于、感知、提供、監測、提高、降低等關系;其實例模型是各抽象元素的具體實例,而情境感知服務的知識推理則基于概念層次的知識抽象.

?其次,提出智能家居情境感知服務知識圖譜實例模型的運行時建模方法.實例模型通過概念、關系實例表示智能家居的情境知識,描述具體場景中客觀存在的事實;基于前期工作運行時軟件體系結構模型[7,8],設計不同類型概念、關系實例的運行時建模方法,并建立知識圖譜實例模型與具體智能家居場景的雙向同步機制.

?最后,提出基于知識推理的智能家居情境感知服務執行方法.情境感知服務執行建立在上述智能家居運行時知識圖譜的基礎上,通過知識推理自動執行設備功能;服務需求本質上是智能家居情境需要滿足的一組條件,將其描述為運行時知識圖譜的一組約束;基于概念層次的知識抽象,設計情境感知服務的知識推理方法,自動決策需要執行的設備功能.

基于上述方法,開發者僅聲明面向場景的情境知識,配置概念實例與智能設備的映射關系,描述服務對象所處情境的約束條件,就能夠自動構建智能家居情境感知服務,極大地降低服務開發的難度和復雜度.

2 智能家居情境感知服務知識圖譜概念模型

知識圖譜概念模型是智能家居情境感知服務概念層次的知識抽象,描述了智能家居場景中概念和關系等抽象元素,如圖2 所示.

Fig.2 Concept model of knowledge map for context-aware services of smart home圖2 智能家居情境感知服務知識圖譜概念模型

概念模型定義了位置、用戶、環境、設備、服務等智能家居場景中概念,見表1.其中,位置(location)表示具體區域,屬性LName表示區域名稱.用戶(user)表示服務對象,屬性UName表示用戶名稱,屬性LName表示用戶所在區域.環境(context)表示用戶敏感的某種環境狀態,屬性UName表示環境狀態所屬用戶,屬性LName表示環境狀態所在區域,屬性CType表示環境狀態類型(例如光亮、溫度等),屬性CValue表示狀態值,屬性RMin和RMax表示狀態值需要滿足的范圍.設備(device)表示智能設備,屬性DName表示設備名稱,屬性LName表示設備所在區域,屬性Keyi表示設備的配置參數或系統指標.服務(service)表示智能設備提供的監測或改變環境狀態的某種服務,屬性DName表示提供該服務的設備,屬性LName表示服務所在區域,屬性CType表示服務監控的環境狀態類型,屬性Effect表示服務對環境狀態的作用,主要包括監測(monitor)、提高(increase)、降低(reduce)、賦值(assign)這4 種類型.Status表示服務是否開啟,SValue表示環境狀態指標(監測)或服務配置參數(賦值).

Table 1 Concepts and their attributes in concept model of knowledge map for smart home表1 智能家居知識圖譜概念模型中的概念及其屬性

概念模型還定義了位于、感知、提供、監測、提高、降低、賦值等上述概念之間的關系,如圖2 所示.其中,位于表示用戶U、環境C、設備D、服務S等位于位置L,感知用戶U感知環境C的狀態,提供表示設備D提供服務S,監測表示服務S用來監測環境C的狀態值,提高表示服務S用來提高環境C的狀態值,降低表示服務S用來降低環境C的狀態值,賦值表示服務S用來改變環境C的狀態值.

3 智能家居情境感知服務知識圖譜實例模型運行時建模方法

知識圖譜實例模型通過概念、關系實例表示智能家居情境感知服務的情境知識,設計概念、關系實例的運行時建模方法,實現知識圖譜實例模型與具體智能家居場景的雙向同步.

3.1 概念實例的運行時建模

知識圖譜概念模型定義了位置、用戶、環境、設備、服務等智能家居場景中概念,基于開發者配置構造其概念實例,并通過模型操作轉換實現概念實例屬性與場景實時信息的雙向同步.

開發者提供的相關配置包括面向場景的情境知識、概念實例與智能設備的映射關系、服務對象所處情境的約束條件,描述了場景中具體的位置、用戶、環境、設備和服務等客觀事物.面向場景的情境知識提供了具體場景中的位置集合{L1,L2,…,Ln};概念實例與智能設備的映射關系提供了具體場景中的設備集合{D1,D2,…,Dn}、其提供服務的集合{S1,S2,…,Sn}以及設備與服務的關聯關系;服務對象所處情境的約束條件描述了具體場景中的用戶集合{U1,U2,…,Un}、其定位裝置的集合{T1,T2,…,Tn}以及用戶敏感的環境狀態集合{C1,C2,…,Cn}.于是,根據位置集合L、用戶集合U、環境集合C、設備集合D和服務集合S,構造相應類型的概念實例.同時,本文使用SM@RT 工具[7,8]構造智能設備和定位裝置的運行時模型,并通過運行時模型實現在模型層對智能設備和定位裝置進行管理[9].

概念實例的模型操作主要包括3 種類型,分別是List、Get和Set.其中,List表示獲取該類型概念的所有實例及其屬性,Get表示讀取概念實例的屬性值,Set表示寫入概念實例的屬性值.為了維護知識圖譜概念實例屬性與場景實時信息的雙向同步,定義概念實例的模型操作轉換規則,見表2.

Table 2 Mapping rules for model operations of concept instances表2 概念實例的模型操作映射規則

?位置實例Li,其屬性LName的值來自配置信息.

?用戶實例Ui,其屬性UName的值來自配置信息;其屬性LName,與定位裝置運行時模型中對應元素Ti的屬性LName保持值的一致,當讀取Ui屬性LName的值時,自動讀取Ti的屬性LName的值,即

?環境實例Ci,其屬性Uname,CType的值來自配置信息;其屬性LName,與對應用戶實例的屬性LName保持值的一致,當讀取Ci屬性LName的值時,自動讀取Uj屬性LName的值,即;其屬性CValue,與對應服務實例的屬性SValue保持值的一致,當讀取Ci屬性CValue的值時,自動讀取Sj屬性SValue的值,即;其屬性RMin和RMax來自配置信息.

?設備實例Di,其屬性Dname,LName的值來自配置信息;其屬性Keym,與智能設備運行時模型中對應元素Di的屬性Keym保持值的一致,當讀取/寫入Di屬性Keym的值時,自動讀取/寫入運行時模型中對應元素Di屬性Keym的值,即GetDi.keym→RTModel(GetDi.keym)/SetDi.keym→RTModel(SetDi.keym).

?服務實例Si,其屬性Dname,Ctype,Effect的值來自配置信息;其屬性LName,與對應設備實例Dj的屬性LName保持值的一致,當讀取Si屬性LName的值時,自動讀取Dj屬性LName的值,即;其屬性Status,與對應設備實例Dj中表示設備是否開啟的屬性Keym保持值的一致,當讀取/寫入Si屬性Status的值時,自動讀取/寫入Di屬性Keym的值,即;其屬性SValue,與對應設備實例Dj中表示對應環境狀態的屬性Keyn保持值的一致,當讀取/寫入Si屬性SValue的值時,自動讀取/寫入Di屬性Keyn的值,即

3.2 關系實例的運行時建模

知識圖譜概念模型定義了位于、感知、提供、監測、提高、降低、賦值等智能家居場景中概念之間的關系,進一步定義關系實例的運行時構造規則,見表3.當兩個概念實例滿足特定前置條件時,即構造它們之間的關系實例.其中,存在用戶、環境、設備、服務等類型的實例Xi與位置實例Lj,Xi屬性LName的值與Lj屬性LName的值相同時,構造關系實例,表示概念實例Xi位于位置實例Lj.關系實例表示用戶實例Ui感知環境實例Cj,關系實例表示設備實例Di提供服務實例Sj均來自配置信息.存在服務實例Si與環境實例Cj,Si屬性Lname,CType的值與Cj屬性Lname,CType的值均相同,且Si屬性Effect的值為Monitor時,構造關系實例,表示服務實例Si用來監測環境實例Cj的狀態值.存在服務實例Si與環境實例Cj,Si屬性Lname,CType的值與Cj屬性Lname,CType的值均相同,且Si屬性Effect的值為Increase時,構造關系實例,表示服務實例Si用來提高環境實例Cj的狀態值.存在服務實例Si與環境實例Cj,Si屬性Lname,CType的值與Cj屬性Lname,CType的值均相同,且Si屬性Effect的值為Reduce 時,構造關系實例,表示服務實例Si用來降低環境實例Cj的狀態值.存在服務實例Si與環境實例Cj,Si屬性Lname,CType的值與Cj屬性Lname,CType的值均相同,且Si屬性Effect的值為Assign 時,構造關系實例,表示服務實例Si用來改變環境實例Cj的狀態值.此外,由于概念實例屬性與場景實時信息保持雙向同步,其關系實例將隨其屬性值變化而發生改變.

Table 3 Rules for constructing relation instances表3 關系實例的構造規則

3.3 實例模型的狀態更新

為了維護智能家居知識圖譜實例模型與場景實時信息的雙向同步,實例模型自動持續更新狀態.

(1)更新概念實例,依次為位置實例、用戶實例、設備實例、服務實例和環境實例.

(2)更新關系實例,依次為“位于”實例、“監測”實例、“提高”實例、“降低”實例和“賦值”實例.

(3)重復執行步驟(1).

4 基于知識推理的智能家居情境感知服務執行方法

智能家居情境感知服務的執行,建立在上述智能家居知識圖譜實例模型的基礎上,面向服務對象所處情境的約束條件,通過知識推理,自動決策需要執行的設備功能.

情境感知服務需求本質上是服務對象所處情境的一些約束條件,即服務對象敏感的某些環境狀態.在智能家居知識圖譜實例模型中,用戶實例Ui表示服務對象;環境實例Cj表示用戶敏感的環境狀態;環境實例Cj的屬性CType表示狀態類型;屬性CValue表示狀態值;屬性RMin和RMax表示其狀態值需要滿足的范圍,即情境感知服務的服務需求.同時,設備實例Di表示智能設備;服務實例Sj表示設備提供的功能;服務實例Sj的屬性CType表示監控的狀態類型;屬性Effect表示對狀態值的影響,主要包括Monitor、Increase、Reduce、Assign 這4 種類型,即情境感知服務的設備功能.于是,情境感知服務的執行可以表示為:在智能家居知識圖譜實例模型基礎上,根據環境實例的狀態值及其約束來決策相關服務實例是否開啟的過程.

為了實現上述決策過程的自動化,針對不同類型的設備服務,提出通用的知識推理規則,見表4.

Table 4 Rules for knowledge reasoning of context-aware services表4 情境感知服務的知識推理規則

第1 組規則描述Monitor 服務是否開啟的推理過程:規則1-1,存在服務實例Si和環境實例Cj以及關系實例,則Si屬性Status的值為On;規則1-2,存在服務Si且屬性Effect的值為Monitor,對于任一狀態Cj,不存在關系實例,則Si屬性Status 的值為Off.第2 組規則描述Increase 服務是否開啟的推理過程:規則2-1,存在服務實例Si和環境實例Cj以及關系實例,且環境狀態值Cj.CValue小于其需要滿足的范圍的下限Cj.RMin時,則Si屬性Status的值為On;規則2-2,存在服務實例Si和環境實例Cj以及關系實例,且環境狀態值Cj.CValue大于其需要滿足的范圍的中值(Cj.RMin+Cj.RMax)/2 時,則Si屬性Status的值為Off;規則2-3,存在服務Si且屬性Effect的值為Increase,對于任一狀態Cj,不存在關系實例,則Si屬性Status的值為Off.第3 組規則描述Reduce 服務是否開啟的推理過程:規則3-1,存在服務實例Si和環境實例Cj以及關系實例,且環境狀態值Cj.CValue大于Cj.RMax時,則Si屬性Status的值為On;規則3-2,存在服務實例Si和環境實例Cj以及關系實例,且環境狀態值Cj.CValue小于(Cj.RMin+Cj.RMax)/2 時,則Si屬性Status的值為Off;規則3-3,存在服務Si且屬性Effect的值為Reduce,對于任一狀態Cj,不存在關系實例,則Si屬性Status的值為Off.第4 組規則描述Assign 服務是否開啟的推理過程:規則4-1,存在服務實例Si和環境實例Cj以及關系實例,且環境狀態值Cj.CValue大于Cj.RMax時,則Si屬性Status的值為On 且屬性SValue賦值為(Cj.RMin+Cj.RMax)/2;規則4-2,存在服務實例Si和環境實例Cj以及關系實例,且環境狀態值Cj.CValue小于Cj.RMin時,則Si屬性Status的值為On 且屬性Svalue賦值為(Cj.RMin+Cj.RMax)/2;規則4-3,存在服務Si且屬性Effect的值為Assign,對于任一狀態Cj,不存在關系實例,則Si屬性Status的值為Off.

5 實例研究

面向實際場景,構建智能家居原型系統,對方法進行評估.首先,驗證方法是否能夠實現智能家居情境感知服務的運行時建模與執行;其次,與傳統方法進行對比,比較服務開發難度和執行性能.

5.1 智能家居場景

圖3 所示為智能家居場景示例.

Fig.3 Example scenario of smart home圖3 智能家居場景示例

場景包括3 個區域,分別是客廳、臥室和陽臺.各區域布置了不同的智能設備,見表5.例如,客廳布置了智能空調、智能燈管、PM2.5 監測儀和空氣凈化器等設備.場景包括4 種類型的環境狀態,分別是溫度、濕度、光強和PM2.5.智能設備能夠針對不同類型的環境狀態,提供監測(monitor)、提高(increase)、降低(reduce)和賦值(assign)等服務,見表6.例如,智能空調能夠提供溫度的監測、提高、降低和賦值等服務,空氣凈化器能夠提供PM2.5 的降低服務.

場景包括5 個服務對象,分別是家庭成員Jack 和人Ken 以及盆栽虎尾蘭、仙人掌和百合花,各服務對象位于不同區域,且具有不同的敏感環境狀態,見表7.例如,Jack 和Ben 能夠在不同區域間移動,要求溫度高于19°C且低于26°C,光強高于20%,PM2.5 低于35μg/m3;虎尾蘭布置在客廳,要求溫度高于10°C 且低于35°C,光強高于20%;仙人掌布置在陽臺,要求濕度高于20%,光強高于90%;百合花布置在陽臺,要求濕度高于60%,光強高于70%.

Table 5 Smart devices in each locations表5 各區域布置的智能設備

Table 6 Services provided by each smart devices表6 各智能設備提供的服務

Table 7 Users’ locations and requirements表7 各用戶所在區域及其需求

5.2 智能家居情境感知服務的運行時建模與執行

5.2.1 情境感知服務的運行時建模

根據上述智能家居場景知識,構造知識圖譜實例模型,并維護其與場景實時信息的雙向同步.

首先,根據場景知識構造知識圖譜概念實例,見表8.其中,

?存在3 個位置實例,分別對應場景中的3 個區域.

?存在5 個用戶實例,分別對應場景中的5 個服務對象:U1和U2分別對應Jack 和Ken,其屬性LName表示所在區域,與定位裝置運行時模型中對應的元素屬性保持值的一致;U3,U4和U5分別對應虎尾蘭、仙人掌和百合花.

?存在12 個環境實例,分別對應場景中各服務對象的敏感環境狀態.例如,Jack(U1)的敏感環境狀態C11,其所在區域LName與U1的屬性LName保持值的一致;環境狀態類型為溫度,狀態值與對應服務實例的屬性SValue保持值的一致,狀態值的約束范圍是[19°C,26°C].

?存在9 個設備實例,分別對應場景中各智能設備.例如,位于客廳的PM2.5 檢測儀(D3),其屬性LName表示所在區域,其屬性On_Off 和PM2.5 分別與智能設備運行時模型中對應元素D3的屬性On_Off 和PM2.5,保持值的一致.

?存在21 個服務實例,分別對應場景中各智能設備提供的服務.例如,位于陽臺的花草檢測儀設備(D7)提供的服務S71,其所在區域LName與D7的屬性LName保持值的一致;環境狀態類型為濕度(humidity);服務類型為監測(monitor),其屬性Status與對應設備實例D7的屬性On_Off 保持值的一致,其屬性SValue與對應設備實例D7的屬性Humidity保持值的一致.

Table 8 Concept instances in the knowledge graph for smart home表8 智能家居知識圖譜概念實例

其次,根據場景知識構造知識圖譜關系實例,見表9.

此時,Ken 位于客廳,而盆栽分別位于相應區域.其中,

?存在43 個“位于”實例,對應場景中各事物位于不同區域.例如,D1屬性LName的值為Sitting Room,則

?存在12 個“感知”實例,對應場景中各服務對象敏感不同環境狀態.例如,U1敏感的環境狀態C1,則

?存在21 個“提供”實例,對應場景中各設備對象提供不同服務.例如,D1提供服務S11,則

?存在9 個“監測”實例,對應場景中各服務對象能夠監測相應環境狀態值.例如,S11的屬性Lname,Ctype與C21,C31對應屬性的值相同,且S11屬性Effect的值為Monitor,則

?存在8 個“提高”實例,對應場景中各服務對象能夠提高相應環境狀態值.例如,S81的屬性Lname,Ctype與C52對應屬性的值相同,且S81屬性Effect的值為Increase,則

?存在3 個“降低”實例,對應場景中各服務對象能夠降低相應環境狀態值.例如,S13的屬性Lname,Ctype與C21,C31對應屬性的值相同,且S13屬性Effect的值為Reduce,則

?存在6 個“賦值”實例,對應場景中各服務對象能夠改變相應環境狀態值.例如,S23的屬性Lname,Ctype與C23,C33對應屬性的值相同,且S23屬性Effect的值為Assign,則

Table 9 Relation instances in the knowledge graph for smart home表9 智能家居知識圖譜關系實例

最后,根據上述概念實例和關系實例構造知識圖譜實例模型,如圖4 所示.

Fig.4 Instance model of the knowledge graph for smart home圖4 智能家居知識圖譜實例模型

5.2.2 情境感知服務的執行

為了維護智能家居知識圖譜實例模型與場景實時信息的雙向同步,實例模型自動持續更新狀態.

(1)更新概念實例,依次為位置實例、用戶實例、設備實例、服務實例和環境實例.

(2)更新關系實例,依次為“位于”實例、“監測”實例、“提高”實例、“降低”實例和“賦值”實例.

(3)進行知識推理,依次為Rule 1～Rule 4,重復執行步驟(1).

以Jack 進入客廳時實例模型的狀態變化為例,介紹智能家居情境感知服務的執行過程,如下所示.

?首先,執行步驟1.

更新Jack(U1)的位置信息,執行“GetUi.LName→RTModel(GetTi.location)”.此時,U1:〈UName:Jack,LName:sitting room〉.更新C11,C13和C14的位置信息,執行“GetCi.LName→GetUj.LName”(存在關系).此時,C11:〈UName:Jack,LName:sitting room,CType:Temperature,CValue:?,{RMin:19°C,RMax:26°C}〉,C13:〈UName:Jack,LName:sitting room,CType:Brightness,CValue:?,{RMin:20%,RMax:*}〉,C14:〈UName:Jack,LName:sitting room,CType:PM2.5,CValue:?,{RMin:*,RMax:35μg/m3}〉.

?其次,執行步驟2.

根據“Si.LName=Cj.LName∧Si.CType=Cj.CType∧Si.Effect=“Monitor””,構造“監測”關系實例,得到;根據“Si.LName=Cj.LName∧Si.CType=Cj.CType∧Si.Effect=“Increase””,構造“提高”關系實例得到;根據“Si.LName=Cj.LName∧Si.CType=Cj.CType∧Si.Effect=“Reduce””,構造“降低”關系實例,得到以及;根據“Si.LName=Cj.LName∧Si.CType=Cj.CType∧Si.Effect=“Assign””,構造“賦值”關系實例,得到

?再次,執行步驟3.

?然后,重復執行步驟1.

更新C11,C13和C14的狀態信息,執行“GetCi.CValue→GetSj.CValue→GetDk.Keym”(存在關系).此時,C11:〈UName:Jack,LName:sitting room,CType:Temperature,CValue:24°C,RMin:19°C,RMax:26°C〉,C13:〈UName:Jack,LName:sitting room,CType:Brightness,CValue:30%,RMin:20%,RMax:*〉,C14:〈UName:Jack,LName:sitting room,CType:PM2.5,CValue:40μg/m3,RMin:*,RMax:35μg/m3〉.

?最后,執行步驟3.

5.3 方法評估

為了驗證方法的有效性,基于通用語言Java 開發上述智能家居服務,并在服務開發過程、開發難度和執行性能等方面與本文方法進行比較.

5.3.1 智能家居情境感知服務的開發過程比較

基于通用語言Java 進行服務開發,開發者必須熟悉不同智能設備的管理接口,并實現其交互.此外,由于服務建立在這些管理接口的基礎上,其管理邏輯無法復用.

本文借助SM@RT 工具[7,8]構造智能設備運行時模型,以統一的方式對設備進行數據讀寫和功能調用(SM@RT 源代碼可以從文獻[10]下載獲得).SM@RT(supporting model at run time)是一種模型驅動的運行時軟件體系結構構造方法及工具,包括特定領域建模語言(SM@RTlanguage)和代碼生成器(SM@RT generator).SM@RT language 允許用戶定義運行時軟件體系結構的元模型及訪問模型:元模型定義了目標系統的結構及可管理的元素;訪問模型聲明了元模型中管理這些元素的方法,即調用目標系統的API.SM@RT generator 在元模型和訪問模型的基礎上,能夠自動生成維護運行時軟件體系結構的基礎設施,將底層系統的實時狀態反映到運行時模型.同時,智能設備運行時模型只需要構造1 次,就能在不同的智能家居場景中復用.因此,基本不會帶來額外的工作量.

在智能設備運行時模型基礎上,開發者僅聲明面向場景的情境知識,配置概念實例與智能設備的映射關系,描述服務對象所處情境的約束條件,就能夠自動構建智能家居情境感知服務.

5.3.2 智能家居情境感知服務的開發難度比較

表10 對使用兩種方法開發的智能家居情境感知服務的代碼行數進行比較,其中,使用Java 語言開發服務,每個服務獨立開發,使用本文方法時,開發者則需要先實現面向場景的相關配置,即基礎代碼為115 行.例如,C11是Jack 的溫度調節服務,Java 程序的代碼行數為220 行,其中,接口調用相關代碼為136 行,管理邏輯相關代碼為84 行,本文方法的新增配置行數為6 行;C24是Ken 的空氣調節服務,Java 程序的代碼行數為140 行,其中,接口調用相關代碼為68 行,管理邏輯相關代碼為72 行,本文方法的新增配置行數為6 行.Java 程序的平均代碼行數為186 行,而本文方法的平均配置行數為16 行,其代碼減少量超過90%.

Table 10 Comparison in lines of code of two approaches表10 兩種方法的服務代碼行數比較

圖5 對使用兩種方法的服務開發時間進行比較:使用Java 語言開發單個服務的平均時間是40min,且每個服務獨立開發,開發時間隨服務數量的增加而線性增長;使用本文方法時,開發者需要先花費固定時間配置面向場景的情境知識、概念實例與智能設備的映射關系,再根據服務需求,逐個配置服務對象所處情境的約束條件,配置每個約束的平均時間是5min.因此,對于絕大多數智能家居場景,當智能設備充分發揮作用時(即服務達到一定數量),相對于使用通用語言進行服務開發,本文方法能夠大幅度降低其開發時間.

Fig.5 Comparison in development time of two approaches圖5 兩種方法的服務開發時間比較

5.3.3 智能家居情境感知服務的執行性能比較

為了比較兩種方法的服務執行性能,在配置“CPU:3.1GHz;Memory:4GB”的系統環境下,執行不同數量的智能家居情境感知服務,并統計其平均響應時間,如圖6 所示.在Java 程序中,每個服務順序執行,分別執行管理邏輯并調用設備API,因此,其平均響應時間隨服務數量的增加而線性增長.使用本文方法時,知識圖譜實例模型通過模型操作轉換及設備API 調用,實現與場景實時信息的雙向同步,在此基礎上,根據服務需求進行知識推理:一方面,由于需要額外操作來維護實例模型與智能家居場景的運行時同步,當服務數量少時,與Java 程序相比,本文方法平均響應時間較高,從智能服務的角度看,這種性能上的差異是可以被接受的;另一方面,由于Java 程序中服務獨立執行,當服務達到一定數量時,會出現不同情境感知服務調用相同設備API 獲取場景信息的情況(例如,C11、C21和C31均要監測客廳溫度),當存在大量服務時,與Java 程序相比,本文方法能夠有效降低設備API重復調用產生的額外開銷,平均響應時間較低.

Fig.6 Comparison in execution time of two approaches圖6 兩種方法的服務執行性能比較

6 相關工作

在當前的物聯網應用開發過程中,編程工作一般都接近操作系統級別,這要求程序員對底層系統的相關技術有非常深入的了解,使程序員將注意力集中在底層系統的相關問題上,而不是應用邏輯本身[11].存在一些研究工作,希望在保證效率的前提下,盡可能地簡化物聯網應用的開發過程.文獻[12]提出一種面向物聯網的認知管理框架,框架使用虛擬對象(virtual object)表示現實世界的對象,并使用組合虛擬對象(composite virtual object)表示一組可互操作的虛擬對象的聚合體,于是,可以面向組合虛擬對象開發物聯網應用.文獻[9,13]提出一種基于運行時軟件體系結構模型的物聯網應用開發方法,將設備能力抽象為運行時模型,通過模型轉換實現應用場景模型與設備運行時模型的雙向同步,于是,可以面向應用場景模型開發物聯網應用.文獻[14,15]提出一種基于ECA 規則的物聯網應用開發方法及支撐系統,給定一組面向應用場景的ECA 規則,系統能夠對其校驗并自動生成面向底層系統的執行代碼.文獻[16]提出一種自頂向下的物聯網應用開發方法及支撐系統,給定平臺獨立的應用管理邏輯,系統能夠自動生成平臺相關的具體配置和執行代碼.此外,一些研究工作[17-19]提出了基于面向服務體系結構的解決方案,提供RESTFul 服務形式的設備訪問接口,以屏蔽底層系統的異構性和復雜性.盡管上述工作有效提高了物聯網應用開發的抽象層次,但是開發者仍需面向場景手工編寫物聯網應用的管理邏輯.

為了支持物聯網應用的服務組裝和知識推理,一些研究工作提出將語義網的概念移植到物聯網中,以提供物聯網語義服務.文獻[20]將注釋嵌入到用XML 表示的觀測數據中,以準確地描述數據的語義,采用OWL[21]建立物聯網本體,并采用規則語言進行本體推論.文獻[22]面向物聯網領域提出統一的語義知識基礎,包括資源、位置、環境、領域、規則和服務等本體,用于服務發現和組裝.文獻[23]面向物聯網應用提出基于本體的語義建模與演化方法,包括通用上層本體以及一組用于領域本體擴展的柔性接口.上述工作在物聯網傳感數據、軟件服務的基礎上進行語義建模,但是缺乏其語義模型與底層數據、服務的聯動機制.

北京大學團隊在運行時模型理論及構造方法方面進行了研究[7,8,24-26]:給定系統元模型與一組管理接口,SM@RT 工具[10]就能自動生成代碼,在保證性能的前提下實現模型到管理接口的映射;當系統元模型發生變化時,SM@RT 可以自動生成新的映射代碼.我們進一步提出了基于運行時模型的物聯網應用開發方法[9,13].在上述前期工作基礎上,本文面向智能家居場景進行語義建模,并建立語義模型與底層系統的運行時同步機制.

7 總結

智能家居情境感知服務需要面向場景進行開發,智能設備的多樣性和智能服務的隨需性,給其開發帶來極大的難度和復雜度.本文提出一種智能家居情境感知服務的運行時建模與執行方法,通過知識圖譜概念模型描述智能家居場景中概念和關系等抽象元素,通過運行時知識圖譜實例模型表示智能家居情境知識,通過建立在上述模型上的知識推理自動執行設備功能.于是,開發者僅聲明面向場景的情境知識,配置概念實例與智能設備的映射關系,描述服務對象所處情境的約束條件,就能自動構建智能家居情境感知服務.本文方法能夠極大地降低開發智能家居情境感知服務的難度和復雜度.

未來工作的重點主要包含以下兩個方面:一方面,基于模型檢測技術[27,28]對智能家居知識圖譜實例模型進行深度分析,以保證實例模型和知識推理的正確性及完整性;另一方面,將方法運用到實際的智能家居場景中,并完善特定場景下的支撐機制.