面向情景感知的物联网设备智能控制系统

李敏波，吴 宇，卢晨耀

1(复旦大学 软件学院，上海 200433) 2(复旦大学 上海市数据科学重点实验室，上海 200433) E-mail：limb@fudan.edu.cn

1 引 言

随着智能硬件的发展，物联网领域中涌现出了更多样化的传感设备，如温湿度传感器;监测指标也从原来的几十种到现在的上百种甚至更多.智能音箱，智能家电、智能门锁安防等智能设备也出现井喷式增长.智能硬件的发展使得智能控制具备了一定的可行性[1].现阶段物联网的基础设施仅能提供设备的基本通信功能[2]，对于在复杂环境下的智能化交互和服务缺乏相应的实现机制和应对方案[3].

智能家居场景中同样存在这一问题[4]，一方面智能化程度不够，无法实现自动控制;另一方面在自动控制中，偏向于工程代码实现，在数据抽象、情景表达等方面还不够成熟，无法达到智能控制的目的.

为了提供个性化智能服务，需要将设备提供的服务与用户的需求进行绑定，要求系统能够描述用户所处场景的完整信息，这涉及到情景建模.SCHILIT 和 THEIMER最早提出情景感知建模[5]，将情景感知分为显式感知和隐式感知两类，显式感知是通过设备或是网络服务直接感知得到，如环境各参数的信息、时间信息等;隐式感知需要用户手动输入或是需要系统深层分析才能得到，如用户偏好习惯.SUN J.Z使用四元组模式(Entity Name，Feature，Value，Time)来描述与物理实体对应的数据对象[6]，用唯一标识来区分物理实体，并使用特征、值和时间来表征情景.STRANG使用CoOL(Context Ontology Language)模型语言构建了本体推理器[7]，从而共享与重用实体情景信息.GELLERSEN H-W，SCHMIDTA 和 BEIGLM 的TEA 项目[8]使用了面向对象的方法进行情景建模.上述内容都为智能控制策略的研究提供了基础.

根据当前情景采取最符合用户需求的措施是实现物联网智能控制的关键.莫同[9]提出了一种情景感知服务系统框架，通过配置模型将情景数据模型与业务服务绑定.都灵理工开发的DogOnt[10]通过语义模型支持用户对家居设备的控制.基于用户生活习惯，Zhenyu Chen提出BP-Mine框架[11]来推荐相应的生活服务.Berkane通过模式匹配的方式来映射情景和服务[12].Uddi引入推理引擎[13]，通过定义规则来描述情景与服务的对应关系.这些研究为物联网设备智能控制提供了良好的思路.

一些学者对手势控制、语音控制等交互技术进行了研究.用户可以通过手势对家用电器设备进行控制[14]，手势与控制命令的映射关系被存储在其数据库中，通过随机森林方法训练出分类器来识别深度成像传感器感知的手势信息.Vacher等人[15]提出了基于语音的家居控制系统，其利用深度学习方法识别用户语音，Mofrad等人[16]给出了在多用户、多语音场景下对语音的分离和识别方法.

在上述研究基础上，通过调研物联网情景建模方法，对智能家居交互场景中涉及的各实体进行分类和抽象，提出了一种新型的基于对象和属性图模型的情景建模方法，通过定义家居交互的规则控制、模式控制和语音控制方式实现物联网设备的自动化控制服务.相较于现存建模方法提高了系统性能和扩展性，多种控制方式的引入使得该系统更智能.

2 情景感知的智能控制系统架构

物联网智能控制重点在于根据当前情景分析用户的潜在需求，调用相应设备的控制服务，达到自动化控制的目标.其可分为3步，首先是对应用情景建模，根据传感数据得到当前人与环境交互的情景信息;其次是根据情景信息进行控制模式或服务匹配得到控制决策;最后是根据决策调用具体设备完成控制服务.

2.1 智能控制模型

情景感知的智能控制基本流程为：数据采集、数据处理、情景生成以及情景推理，如式(1)所示：

C=MD→C(D_S)

(1)

D_S为情景环境下的数据空间(Data Space)，包括所有可采集、能被提供给系统的数据，以键值对的形式给出，如式(2)所示：

DS={(key1：value)，…，(keyn：value)}

(2)

其中key指代所监测的指标，如温度传感器对应的是温度，天气服务对应的是天气，而它们的值也随指标类型而变化.

M将底层的原生数据空间D_S映射到情景空间C.每一个情景都是由原始的传感数据作为输入，通过该映射得到某种类型情景.例如：

C={Environment，Time，Subject，Activity}

家居领域的情景集，情景由Environment环境、Time时间、Subject主体以及其Activity活动(状态)构成，反映了家居环境中的实时温度湿度、空气质量等环境信息.

情景信息经过采集、预处理和推理后，得到对应的高级情景，其可以作为系统服务调用的依据，因此系统需要由情景到服务的映射，如式(3)所示：

S=TC→S(C)

(3)

C为情景集合，S为可调用的服务集，T为由情景到服务的映射.获取情景到服务的映射方法有基于规则方法和基于机器学习的方法.基于规则的方法准确性高，但是泛化能力弱;机器学习方法泛化能力高，但需要初始训练数据集以及较大的算力.由于物联网的计算资源有限以及家居领域数据集较少，本文使用基于规则的推理方法来实现情景到服务的映射，在高级情景信息传输至推理引擎后，通过规则配置模型将情景信息作为输入，需要调用的业务服务标识符作为输出，再通过调用控制器完成智能控制的服务调用.

规则配置模型用一个三元组标识,如式(4)所示：

conf=〈conf_ID，CXT-V，BS〉

CXT-V={〈cxt1，v1〉，〈cxt2，v2〉，…，〈cxtn，vn〉}

(4)

其中conf_ID标识配置规则，CXT-V是情景子信息-值对的集合，BS是业务服务，如对智能电器设备的远程控制服务.物联网设备根据其功能通常分为3类：感知设备、控制设备和带有通讯功能的物联网网关.感知设备的主要功能是采集周围环境指标数据，感知设备的虚拟化要素包含感知设备采集指标数据的特征，如指标名称、指标值、采集时间以及数据单位.控制设备用于接收和转发指令，包括指令数据、指令执行结果以及行为操作时间.

2.2 智能控制系统结构

如图1所示，根据情景感知系统中情景的周期，本文设计了物联网场景下的智能控制框架，其分为4层：感知层、中间件层、决策控制层与服务层.

图1 物联网智能控制系统框架Fig.1 Framework of IOT smart control system

感知层用于物联网数据采集.中间件层用于屏蔽底层设备的异构性，将底层感知数据进行协议解析，转化为上层能够处理的统一数据结构.

控制决策层为系统框架的核心，其根据底层设备传输的数据进行相关处理，得到对相应服务的调用策略，并完成情景感知控制服务.该层作为情景感知引擎，包括数据访问接口DAI(Data Access Interface)、轮询器、推理引擎以及调用控制器.虽然中间件层协助系统识别各注册设备传输来的数据，由于数据的情景信息来源差异较大，为进一步将数据分类处理以供情景推理引擎使用，DAI与轮询器共同作用使得输入到情景推理引擎的数据符合情景信息模型的标准.情景信息模型来源于情景建模方法，不同的情景建模方法具有不同的特点，应根据业务的不同来选择合适的情景建模方法.推理引擎根据情景信息搜索出符合当前情景的业务服务，再通过调用控制器完成服务调用.服务层包含向用户提供的各种业务服务，可以是以WebService形式封装的业务服务，也可以是各智能设备提供的远程控制服务接口API.

3 情景建模方法

情景建模是将数据映射为智能控制的交互场景，从而使得控制系统可以理解当前情景状态，作为后续控制决策的基础.

3.1 现有建模方法

情景建模的方法主要分为3类：基于键值对形式的建模、基于对象的建模以及基于本体的建模.

基于键值对的建模方法通过将交互场景的数据以键值对的形式进行存储来表达不同的场景,如式(5)所示：

context={(key1：value1)…(keyn：valuen)}

(5)

基于对象的建模方法是在面向对象编程的基础上发展而来，其符合系统构建的思路，其一般将情景抽象成式(6)形式：

(6)

通过将交互场景中涉及的关键实体抽象出对应的类别，为不同的类别构建对应的属性与方法，根据场景中各类别实体的数量和实体内部的属性方法表达当前情景，但其对实体类别间关系的表达能力较弱，只有内置的几种关系可供使用.

基于本体的建模是当前主流方法，通过抽象出交互场景中的关键概念，并可根据实际业务定义各概念之间的关联关系，其表达能力较于前两者更强，建模结果的基本组成如式(7)所示：

(7)

该式称为SPO三元组，Subject为类别或是实体，Object是相应类别或是实体的属性值，Predicate则为类别间的关系或是属性名.通过该基本元素，构成了各概念以及相应实体之间关联关系图，从而表达相应的情景.本体方法对硬件设备的要求较高，执行性能较弱，不适合在物联网实时控制中使用.

以下设计了一种针对家居环境的新型建模方法，相比于主流方法更适合智能家居领域.

3.2 基于对象与属性图的建模方法

为了探究新的适合智能家居领域的建模方法，引入图数据库中的属性图模型来弥补面向对象方法表达能力的不足，同时保留了面向对象方法的高移植性和高性能特点，更符合物联网家居资源有限的实际情况.

基于家居交互环境的特征以及交互任务的分析，提取家居各交互场景下涉及的关键要素，将其抽象成对应的实体类，如家居空间类、房间类、家居用户类、感知设备、可控设备共5大实体类.智能设备分为感知设备与可控设备.图2为基于对象的家居交互实体类别属性图.

图2 家居交互实体类别属性Fig.2 Entity category attribute of home interaction

家居空间类用于描绘智能家居终端所属商品房空间，代表了设备监控与交互服务所处的环境，包含该居住空间所属的用户、所在的物理位置经纬度和门牌号码地址.其定义如式(8)所示：

(8)

房间类是家居空间在物理上的划分，用于标识各具体交互活动所处的位置，除了包括家居场景中真实的房间外，还包括家中的过道、走廊等特定位置.房间类的标签标记了其所属类别，所属用户的属性，如式(9)所示：

Room={id，owner，tag}

(9)

用户类描述用户与环境、设备交互时的用户身份id，年龄age、性别gender属性、喜好属性preference(水温、室温、空气湿度、亮度的偏好)以及对应角色role权限等，从而为用户的个性化服务提供支持.其设置如式(10)所示：

User={id，age，gender，role，preference}

(10)

传感器类用于感知情景信息，包括周围环境对应的参数信息、设备状态、用户位置等.如式(11)所示：

Sensor={id，target，value}

(11)

sensor标识了传感器所监测的指标类别target与其值value.

可控设备类是指可通过网络或其他方式进行远程控制的智能设备，如智能门锁，智能冰箱、智能开关等，其定义如式(12)所示：

(12)

可控设备类包含了其提供的所有操作Action，以及各操作对应的参数para.

由于面向对象方法内置的关系不足以描述交互任务，如设备与房间之间的从属关系.通过引入图数据库的属性图模型，在面向对象的基础上来描绘各对象间的关系，从而使得情景模型更加完备，同时在性能上比本体方法更强.

属性图模型是由节点、边、标签、关系类型和属性组成的有向图，边也可以称为关系，上文中抽象出来的实体类可以作为属性图模型中的节点的标签属性，拥有相同标签的节点属于同一类型，而实例对象则与属性图模型中的节点一一对应，不同的节点拥有不同的属性.属性图模型提供了节点之间关系的定义，关系由起始节点指向结束节点，双向关系是通过两个相反方向的关系来标识.

如图3所示，在基于对象方法得到的5类实体的基础上，在家居场景下分析实体间的关联关系，并使用属性图模型描述.从图3中可看出，用户拥有房子(User-[：HAS_HOUSE]->House)，逆向的关系则是房子属于用户;房子由房间组成(House-[：COMPOSED_OF]->Room)，反之则定义为房间位于房子中(Room-[：LOCATE_IN]->House);不同的房间部署着不同的感知设备和可控设备：(Room-[：HAS_SENSOR]->Sensor);(Room-[：HAS_DEVICE]->Device)，反之即设备位于不同房间：(Sensor-[：LOCATE_IN]->Room);(Device-[：LOCATE_IN]->Room).除了描述各实体类别的关系，属性图模型还能为定义的关系提供属性的定义，如图中商品房之间的位置关系中，定义了两房子之间的方位属性以及距离属性：(House-[：LOCATION{ direction：“north”，distance：“10km”}]->House).可控设备以及感知设备位于房间时，其属性也定义了设备在房间的位置，这也是属性图模型较于本体建模方法的优势所在.

图3 基于属性图的家居实体关系Fig.3 Home entity relationships based on attribute

图3展示了以实体类别为粒度单位的相关关系.图4标识了标准两室一厅一卫的商品房属性模型图，每一个节点代表一个实体对象.为方便观看，图中只标识了各实体对象的基本关联关系.

图4 两室一厅一卫的属性模型Fig.4 Attribute model of two rooms，one room，one guard

3.3 家居建模结果

新型情景建模方法在面向对象的基础上融合了属性图模型的优势，从而使得传感器感知的原生数据在经过预处理后生成相应类型实体的对象实例，但这些实例对象并不是系统的最终目标，其仍然不足以表达某个具体的家居交互场景.因此参照本体自上而下的设计思路，通过在五大基本实体类别的基础上提出环境、行为和主体模型，以充分地描述当前用户所处的情景，式(13)给出了家居情景的表达：

Context=(Environment，Time，Subject，Activity)

(13)

即最高抽象层次的情景包括交互所处的环境、当前时间、所涉及主体以及主体行为，如式(14)所示：

Environment={Location||Weather||…(SensorType)}

Location={Space，Room，Position}

(14)

环境模型包含了交互的位置，天气以及所有能感知环境因素的传感器指标，其中位置信息由数据库中的商品房地址以及空间-房间-地点层次结构标识.

时间模型分为DateTime格式的数值和标签两部分，通过标签将绝对的数值转变为业务相关的语义信息，如季节、早中晚、工作日等，通过添加与交互有关的语义标签信息，使得以后的自适应控制更加精准.

Subject={User||Device||Environment}

(15)

Subject主体模型标识交互活动中的主体对象，大部分情况下包含用户对象，小部分情况也会存在设备对象和环境对象，如设备故障将会引起系统推送消息至用户手机;环境感知到下暴雨时将会引起关窗等行为，如式(15)所示：

Activity=

{UserActivity||DeviceAction||EnvironmentAction}

(16)

行为模型UserActivity与主体模型相对应，随主体模型的不同，其取值范围也会相应变化，如用户行为包括起床、睡觉、看书、离家、回家等一系列家居活动;设备行为DeviceAction则包含该智能设备所特有的行为，如智能空调的制冷、制热以及所有设备公共的开启、关闭;环境行为EnvironmentAction则包含下雨、打雷、大风、空气质量等自然因素.对Activity的定义如式(16)所示.至此，原生数据被转化为高级情景统一的结构.

4 家居智能控制

智能控制意味着在用户少参与的情况下，系统自主根据实时的情景信息，采取符合用户期望的控制行为，即系统将情景信息映射到设备控制服务.获取该映射的方法有基于规则的方法与基于机器学习的方法，基于规则的方法准确性高，但是泛化能力弱;机器学习的方法泛化能力高，但是需要初始训练数据集以及较大的算力.考虑到基于规则的系统具有较高准确性以及语义上的易理解性，其仍然是家居场景下首选的智能控制方法.

4.1 基于规则的控制

基于规则的控制把业务规则与底层代码分开存储.在构建基于规则的控制系统时，首先需要构建并初始化以情景模型对象为基础的规则库，通过在条件端和结果端组合不同的情景模型对象以及对象间的逻辑关系，来定义每一条与业务需求相对应的规则.当情景数据被处理为对应的情景对象模型时，其作为事实被传入规则推理引擎，推理引擎用于执行情景信息到控制服务映射的工具.

基于规则的控制方式使得系统可以根据情景信息得到对应的控制决策，而控制决策是由最细粒度的设备远程控制服务接口组合而成，使得智能控制系统可以调用任意智能设备提供的控制服务，也可将最细粒度的控制服务按照一定的业务逻辑进行组合构成更高级的控制.

采用RESTFUL接口将设备操作封装成相应的服务接口.通过将感知设备和控制设备对应的操作封装为对应资源标识符的增删改查，可以添加设备、获取设备感知信息、调用设备的控制服务等，通过标准的http协议即可实现.将最细粒度设备控制作为规则结果的组成单位，来构造业务逻辑规则.控制规则可被抽象为如式(17)的结构：

Rule=(name，priority，condition，result)

(17)

每条规则包含对应的标识符name，用于冲突解决的优先级值priority，条件端condition和结果端result.规则的条件端与结果端均是以情景建模后的模型库为组件以及其逻辑关系构成，条件端的结构如式(18)所示：

(18)

条件端包含了由各类情景模型对应属性值的范围判断所组成的原子条件，这些原子条件通过逻辑关系符组合在一起，形成一条规则的完整条件端，例如环境情景模型的温度值大于26摄氏度，并且时间值为晚上11点，用户位置值为卧室，这3个原子条件，共同构成了用户睡眠规则的条件端.

结果端的结构如式(19)所示：

(19)

结果端的结构与条件端类似，通过情景模型来设置对应设备的状态控制原子操作，进而调用相应的设备控制服务来达到智能控制目的.如下给出了安全规则的一个实例：

Rule gasSalence10 When $gasSen:gasSensor(densityVal>36) $window:Window(address==“kitchen”) Then $window.open()

4.2 基于模式的控制

基于规则的控制方式粒度较细，家居场景下业务的多样性需要创建大量的逻辑控制规则，因此需要比规则控制更高粒度的基于模式的控制方式.基于模式的控制组合了多条规则结果端的行为，条件端则由上文中的情景模型库以及用户根据自我偏好自行定义的偏好库组成，例如：上班模式、早起模式、睡眠模式等.上班模式包括每个工作日的叫醒服务、电视新闻的定时播放与关闭、电饭煲厨房电器定时开启等.模式控制的表达式如式(20)所示：

Mode={(Contextmodeli，attributei：val)⟹

(atomAction1，…，atomActionn)}

(20)

模式控制的结构包括了模式控制触发的条件以及对应结果端的操作，下述给出了阅读模式控制的实例.

Mode“readMode”When $user:User(location==“study”) $study:Room(flag==“study”&&duration>5) $tempSen:tempSensor(address==“study”) $lightSen:lightSensor(address==“study”)then if($lightSen.val<$user.LowLightPreference) $study.openLight(“read”) if($tempSen.val>$user.HighTempPreference) $study.openAirconditioner(“cold”) $study.closeAllWindow()

该模式考虑了用户阅读时的温度以及光线需求，根据其偏好来调节书房的环境.

4.3 智能控制方式

针对家居领域业务特点，设计了基于语音的家居控制APP，图5显示语音控制流程.

图5 语音控制流程Fig.5 Voice control process

通过麦克风检测到语音输入时，判断是否包含唤醒词，如果包含则进入语音控制方式，否则忽略.针对用户身份识别，使用第三方语音识别API进行用户语音识别，选择利用第三方离线jar包将语音文件转为文本文件，识别出当前用户的身份信息和用户语音文本.根据针对家居场景所定制的词典，基于双向最大匹配算法对文本数据进行分词.分词之后进行信息提取，并将提取出的信息构建成统一的数据结构，形成语音控制指令，然后调用控制规则引擎进行规则推理和控制服务调用.

对于家居场景下的定制词典，通过将家居领域常用的控制语句以及涉及到的设备，传感器，用户感知属性等名词抽取出来，构成家居场景领域下的词典，例如：空调，温度，打开，关闭.根据智能家居语义词典，系统可以对文本文件进行分词.对于语音控制指令中缺失的用户、时间、具体房间的设备以及操作参数信息，系统通过隐性信息提取相关数据，补充完整的控制指令，以提高系统的智能化程度.

4.4 智能控制方式

系统推理引擎中的规则结构，都包含了条件与结果这两部分.使用面向对象与属性图模型的情景建模方法，利用(type，object，attr，val)四元组来描述原子条件，分别为实体类别，具体对象，对象属性与属性值.通过原子条件的组合构成规则的条件.结果部分则是基于原子级控制方式，利用(device，action，para)三元组，通过指定设备标识，设备封装的服务以及服务参数完成原子级控制功能，最后组合成规则的结果部分.

家居的个性化、智能化控制分为两种方式，其一为用户少许参与下的自动化控制，根据情景变化预测用户需求，自主完成设备控制.另一种则是用户语音控制方式，在用户没有精确表达其需求时，通过提取当前情景的隐性信息来补充用户偏好和位置信息，完成设备控制.

自动化控制方式主要通过用户提前设置的控制规则、模式以及其对于家居交互中一些指标的偏好来实现.而用户偏好是针对用户某时间段对家居生活中控制指标的设置，如温湿度、水温等.通过引入用户偏好使得规则文件通过读取用户的偏好来降低系统耦合性.

对于语音控制，在云服务端通过将文本与家居字典匹配转变为统一结构的控制指令，对于语音控制指令中缺失的用户、时间、具体房间的设备以及操作参数信息，系统通过隐性信息提取相关数据，补充完整的控制指令，以提高系统的智能化程度.

5 原型系统及实验分析

5.1 原型系统结构

图6所示家居智能控制系统分为设备层、中间件层、数据预处理层、智能控制层与交互层五层，系统提供两类控制方式.第1种方式为用户主动控制，在手机APP中手动点击控制，或者使用手机语音输入指令.第2类控制方式是无需用户参与的系统自动控制，该方式通过将设备感知的情景数据处理为高级情景信息输入到推理引擎，与规则库中的规则匹配得到控制指令，再调用相应设备控制服务完成家居设备或环境的自动控制.各传感器感知的原始数据经由中间件筛选过滤后传入后台，后台通过将各数据源的数据作为相关情景模型的属性来构建情景对象，如上文提到的规则控制、模式控制、语音控制和智能化控制的高级情景模型.此时新产生的情景模型对象与当前系统缓存逐条属性对比，若属性有所改变，表明当前情景较于之前有了变化，将新生成的情景对象替代当前缓存并作为事实传入Drools规则引擎.Drools规则引擎基于RETE算法通过分解规则的条件端来形成条件网络，当事实作为输入节点传入时，该算法可以输出满足条件的规则，从而得到当前情景所需执行的指令.

图6 家居智能控制系统结构Fig.6 System architecture of smart home control

5.2 系统流程

家居智能控制系统的控制流程如下：

对于自动控制，首先解析来自异构设备感知的原始数据，即获取物联网Ruff开发板上的各传感器数据;然后将传感器数据与系统缓存中各对象属性数据对比，若各项数据都无变化，则本流程终止;否则进入第3步：将变化后的数据映射到对象中，即更改缓存中对象属性，并作为新事实fact传输到推理引擎.第4步将输入的事实与规则库匹配，若无匹配项，则不触发任何操作，否则进入第5步：从条件满足的规则集合中按优先级选择执行，第6步将规则执行的结果转化为对应的服务调用，由相应的智能设备根据指令执行操作.

对于主动控制，用户使用APP进行家具设备或模式控制，亦可通过语音识别进行控制，通过将文本与家居词典对比提取情景模型所需关键字，依托推理引擎生成操作指令;最后通过调用相应设备控制的服务.

5.3 性能测试

家居智能控制系统使用基于对象与属性图模型的建模方法，不同于基于本体的场景建模方法，通过测试系统性能并与基于本体建模方法所构成的系统进行对比，评估新型建模方法的性能与适用性.

实验环境：CPU为intel-corei5-3.2GHz，内存为4G.实验的控制变量为规则库中的规则、家居设备的数量，包括感知设备与可控设备，性能测试指标为系统的响应速度以及稳定性.

图7显示了系统性能测试与对比实验的结果，左侧为基于属性图模型建模方法的系统性能测试，右侧为基于本体方法构建的系统性能测试.从试验结果可知，随着规则数量的增加，两种建模方法的内存使用率都有明显增加，这是由于其使用的推理引擎都是基于RETE算法，将规则条件的中间状态存储在内存中，因此随规则数量的增加呈指数增长.同时两类系统响应时间均有所增加，但本体建模方法系统的响应时间平均在10秒以上的量级，而基于属性图和面向对象的建模方法的响应时间均在1秒左右，基于属性图和面向对象的建模方法更适合物联网实时智能控制.

图7 系统性能测试对比实验Fig.7 Contrasting experiments of system performance

随着用户使用该系统时间的增长和系统中的规则数量增加，基于本文建模方法构造的系统仍能提供稳定的服务.

家居智能控制系统通过绑定用户与规则文件、用户与偏好来实现个性化服务，将与用户身份匹配的规则文件调入推理引擎，而规则文件中各规则的条件端又需使用用户偏好数据，从而能根据用户身份、用户偏好提供个性化服务.原型系统选用Neo4j图数据库进行存储，从而提高了用户规则及偏好的搜索效率.实验通过提供用户数、用户规则数以及用户偏好数来对比Mysql传统关系型数据库与Neo4j图数据库对用户规则及偏好的搜索效率，实验结果如图8所示.在用户数、规则数以及单用户对应偏好数处于较低水平时，图数据库与关系型数据库的查询效率相差无几，但随着这3项指标的提升，Mysql数据库的查询效率显著降低，但Neo4j却能保持稳定在较低延迟水平.

图8 个性化服务性能测试对比实验Fig.8 Compare the performance of personalize service

6 结束语

在物联网智能家居场景下提出了基于对象和属性图模型的情景建模方法.使用该方法构建情景模型后，通过定义家居交互规则、模式控制和语音控制方式整合家居中的设备控制服务，设计了基于规则推理的智能控制方案，并通过提供多粒度、多方式的控制方法增强其智能化程度.

通过规则将情景感知数据映射到对应的设备控制服务以实现系统的自动控制.情景感知和情景建模作为规则的条件端，由智能设备抽象的控制服务作为结果端的原子组件，实现了从感知环境变化到调用目标服务的智能控制流程.相比于其他智能家居系统，本文提供了多粒度的控制方式，同时引入了用户偏好设置、场景隐性信息提取机制，使得本系统只需少量的指令，简捷且精准地为用户提供服务.在语音控制中添加了隐性信息提取策略来提升系统的智能化程度.

考虑到本系统受限于业务规则，而其主要来源于用户主动定义，因此系统的泛化能力较弱.未来将对系统规则执行的历史记录进行潜在规则挖掘以弥补该缺陷.