智能家居情境感知服务的运行时建模与执行方法∗

陈 星 , 黄志明 , 叶心舒 , 马 郓 , 陈艺燕 , 郭文忠

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]对智能家居知识图谱实例模型进行深度分析,以保证实例模型和知识推理的正确性及完整性;另一方面,将方法运用到实际的智能家居场景中,并完善特定场景下的支撑机制.