面向场景服务的智能家居中间件系统

2014-05-18

信息通信技术 2014年5期

北京邮电大学北京 100876

引言

智能家居是以住宅为平台，兼备建筑、网络通信、信息家电、设备自动化，集系统、结构、服务、管理为一体的高效、舒适、安全、便利、环保的居住环境。它能够利用综合布线技术、智能家居系统设计方案、网络通信技术、自动控制技术、音频视频技术、安全防范技术等将与家居生活有关的设施有机地结合在一起，构建一个高效的住宅设施与家庭日程事务的管理系统[1]。

物联网(Internet of Things，IoT)是在信息社会中基于已有的以及发展中的相互协作的信息和通信技术，利用物理上或虚拟互联的物体提供高层服务的全球性网络[2]。而住宅的封闭性则非常适于局域网络的搭建，实现特定区域内的物联网。近年来，基于IoT技术的智能家居系统发展迅猛，特别是2014年，随着谷歌公司收购Nest和苹果公司推出HomeKit智能家居平台，智能家居再次成为IoT产业的焦点。目前，制约智能家居系统普及的重要原因之一是接入设备众多却无统一标准，造成不同设备间难以互联互通，更难实现联动控制和综合服务。尽管很多设备制造商正逐步开放其设备访问操作接口API，很多智能设备管理平台也提供开放接口，但设备之间、设备与用户之间的互操作问题依然是智能家居系统面临的一个重大考验。

本文提出一种面向场景服务的智能家居中间件系统，该系统采用基于脚本解析的通用API适配技术，可将不同通信方式、不同操作接口标准的家电设备接入智能家居网络中，进行统一控制；同时，系统通过对服务规则的形式化描述，提供用户自定义规则与场景的功能，能够让用户对多个设备操作进行组合，并利用时间或环境条件加以限定，实现智能化的环境控制。

1 智能家居系统及其发展现状

1.1 智能家居系统结构

智能家居系统通常由三部分构成：智能控制终端、智能家电设备和智能家居网关。其中，智能控制终端包含智能手机、平板电脑、个人电脑等常用电子产品，其作用相当于“遥控器”，用户可以借助与系统配套的应用程序APP进行远程操作，实现对家电设备的控制、对居家环境的观测、对异常情况的监察等功能。

智能家电设备通常意义上指具有智能控制功能的家电设备，相比于传统家电，智能家电设备往往在设计之初就预留了智能控制的接口。例如很多智能电视提供了网络(IP、串口)控制的指令接口；一些智能空调更是自带相应的手机APP，实现智能化控制。传统家电可以通过附加智能控制器的方式进行智能化改造，例如只能接收红外信号的家电，只需要安装一个Wi-Fi转红外的转换模块，即可通过Wi-Fi实现对家电的控制。

除此之外，智能家电设备还包括一些专门负责采集环境数据的感知器节点。这类设备仅对环境的状态如光照、湿度等进行数据采集和上报，但不会对环境产生直接影响，而是结合用户所制定的规则与场景，配合智能家电设备，实现对环境的调节；因此，这些感知器也可以被内置于空调、智能温度计等设备当中。

智能家居网关不仅为智能家电设备提供网络通信接口，还可以成为智能家居系统的控制中心。一方面，它可以为智能控制终端提供数据访问与操作控制接口，向用户呈现相关的数据信息以及将用户的控制命令转发至相应设备；另一方面，它可以对所有接入设备进行统一管理，并通过提供用户自定义规则与场景的功能让用户对多个设备操作进行组合，并利用时间或环境条件加以限定，实现个性化、自动化的环境控制。

1.2 智能家居行业现状

工信部在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.3 未来智能家居系统的特点

1) 便利性。智能家居系统首先要能够为用户提供便利的服务，实现随时随地的控制。无论在家中或在户外，无论即时还是预定，无论人工操作还是自动触发，用户均能以简单的操作完成对家居环境的智能调控。同时提供复杂场景的编程功能，一次编辑，随后一键操作。

2) 兼容性。采用新技术的家居产品层出不穷，接口标准难以统一，设备间互操作性差，需要智能家居网关提供有效方法连接并打通接口各异的各种设备，并以逻辑设备的形式向用户提供统一操控接口。

3) 稳定性。智能家居系统中所有设备通过网络与智能家居网关连接，因此，网络的稳定性将左右整个系统的运行状态。系统要保障通信通道的畅通，保证设备始终处于已连接的可控状态，使得用户发出的指令能够正确执行。

4) 安全性。智能家居系统中不仅涉及到常用智能家电设备，还包括智能感知节点，可以采集环境数据，并以数值、图像、音频、视频等格式进行存储，因此，可能包含大量的隐私信息，智能家居系统必须保证用户信息不外泄。

上述特点中，便利性与兼容性是首先要解决的两个重要问题。本文研究的智能家居中间件系统针对这两方面的需求提出解决方案。

2 智能家居服务中间件系统

2.1 系统结构

智能家居服务中间件系统是对现有家庭网关的智能化提升，使之不仅可以支持更多的通信方式和更多种类的设备，而且可以支持复杂的规则处理与场景设置，从而实现不同设备间的联动与自动化控制。智能家居服务中间件系统的功能结构如图1所示，主要包括通信管理、数据收发、事件驱动引擎、规则解析、驱动脚本解析和消息处理等模块，以及设备与规则数据库、设备驱动API脚本库。

图1 网关系统功能结构图

设备与规则数据库中存贮联入网关的设备信息、用户自定义的自动控制规则、场景模式和环境监测数据。设备驱动API脚本库中以xml文件形式存贮了每种设备每个操作所对应的指令API，家居系统增加一种新类型的设备，只需加载一个新的设备驱动API脚本文件即可。

通信管理模块负责维护各种设备与网关的网络连接，数据收发模块负责通信协议转换，从而实现不同通信接口的消息格式与内部统一消息格式的转换，完成基础网关功能。

事件驱动引擎是服务中间件的核心模块，它通过规则解析模块分析用户自定义规则或场景的触发条件和操作目标，自动检测环境数据的变化是否满足这些触发条件，如果满足条件，则根据操作目标的设备类型选择对应的驱动脚本API文件，自动解析API指令，并通过数据收发模块将指令发给对应的设备。

消息处理模块是服务中间件向智能控制终端提供的开放接口模块，通过Rest风格的Web服务接口，用户可以向系统添加设备、加载驱动脚本、设置服务规则和场景、发布控制命令、获取环境数据等。

下面将重点介绍基于脚本解析的通用API适配机制、服务规则的形式化描述方法和基于事件驱动的规则执行引擎。

2.2 基于脚本解析的通用API适配机制

大量厂商进入智能家居市场导致的后果是各个厂家的智能设备依照自己的标准设计制造，无法进行统一，智能家居系统无法对其进行兼容；因此，我们设计了一种基于脚本解析的通用API适配方法。每添加一种新的品牌设备，只需加载一个新的设备驱动脚本文件；之后再添加一个该品牌的新设备，只需选择其相应类型的驱动脚本文件，随后，网关会对该类型的驱动脚本进行解析，依照脚本内容进行相应处理；因此，对于同类型的设备只需要选择同样的脚本文件，不必进行重复加载；对于新类型的设备，只需按照驱动模板编写一个新的类型驱动脚本，不必在网关中进行复杂的设置。这种方法在很大程度上能够解决网关的兼容性问题。驱动脚本文件包括设备信息配置和功能函数描述两部分。

设备信息配置包含设备类型、通信方式、控制命令集、设备变量集、触发事件集等信息。

1) 设备类型与通信方式。不同设备具有不同的通信方式，需要配置相应的通信参数。例如IP通信，需要配置通信端口； Zigbee通信，需要设置默认MAC地址；而串口等其它通信方式，则根据设备需要进行相应设置。

2) 控制命令集。不同设备提供不同的操作，例如灯光操作可有开、关、调亮、调暗，空调操作有设定温度、制冷、制热等，各个厂商在同类设备上可进行的操作有很大的相似性；因此，我们根据设备类型，在脚本中配置该种设备的控制命令的最大集合，保证支持大部分操作。

3) 设备变量集。部分智能设备在接收控制命令后会就自身状态给出反馈，感知设备也会收集环境数据进行上报。为了记录这些信息，我们引入变量，在脚本中设置设备相关的变量、类型与初始值，用于状态描述。如灯光设备的变量为亮度，空调设备的变量包括温度、模式、风速等。

4) 触发事件集。脚本中还预留了一部分事件接口，以事件驱动的方式执行事件内容，以实现设备的直接控制、设备之间的联动、感知设备的环境触发等功能。

驱动脚本中的功能函数描述部分主要描述设备控制命令的适配方法。即使对于同样的操作(如打开电器)，不同设备接受的API数据格式也不同，因此，针对每种控制命令，其功能函数部分将描述如何将控制命令参数转化为规定格式的数据包，并通过预先建立的通信线路发送至设备。针对接收设备反馈或接收监测数据的命令，功能函数部分将描述如何对接收数据包解析，并写入数据库或触发相应事件等操作。

2.3 服务规则和场景的形式化描述方法

在智能家居环境中，用户不仅希望对家电设备进行远程操控，也希望能够实现定时等自动服务，只需要预先设置好参数，不必亲自动手也可以营造出想要的居家环境。比如在下班回到家后只需要开启回家模式，客厅灯光会自动亮起，CD机开始播放音乐，热水器也开始运转，所有操作只需一键。又或者在炎炎夏日，当室内温度超过25摄氏度，空调就会自动打开，省去人工步骤。这就是服务规则和自定义场景的作用。

为便于规则的管理与执行，本文参考了“事件—条件—动作”(ECA)模型来描述服务规则。ECA模型常被引入智能家居系统用于规则的描述与冲突检测[4-5]。其语义为当事件发生时，触发对条件的评估，若条件成立，触发动作的执行[6]。在智能家居系统中，我们规定：一条服务规则是一个实现在特定条件下对设备的操作，而自定义场景是一条或多条服务规则的组合。例如我们希望在就寝时关灯，起床时打开窗帘。此时只需定义两条规则，可分别执行；同时可以将其组合为一个场景，实现一键操作。

服务规则分为两类：定时规则和即时规则。定时规则包含时间条件和规则动作两部分，而即时规则仅包含规则动作。图2展示了规则的组成与分类。

图2 规则分类与组成

时间条件由多个时间属性组成，如图3所示。其中，起始时间和终止时间代表该条规则的有效期，只有在这两个时间点之间的时间段内，时间条件才会被触发；触发时间是24小时制的一个时间点，表示规则动作部分会在该时间点被触发；重复类型表示时间条件可以周期执行，分为星期重复和间隔重复两种，相对应的，重复周期表示每周的星期几或每几天。

图3 时间条件组成

规则动作包括环境触发条件和设备动作。环境触发条件由若干条件组组成，如图4所示，条件组内可以有若干原子条件。原子条件之间、条件组之间均由一个连接符连接，连接符为“与”或“或”操作。原子条件由三部分组成：变量、逻辑运算符和变量参数，逻辑运算符包括：等于、不等于、大于、大于等于、小于、小于等于。对于用自然语言描述的条件，规则解析模块负责转换。如条件“当灯光亮度大于200lux时”，系统中以{LightLevel, >, 200 lux}的三元组形式记录。设备动作由若干设备与对应的设备操作组成，以{设备, 动作名称}的二元组描述。

图4 环境条件组成

2.4 事件驱动的规则执行引擎

规则的执行依靠事件驱动，如“定时时间到”、“场景开启”、“物理环境改变”等。基于ECA模型，事件驱动引擎将分析触发条件和操作目标，如果满足条件，则根据操作目标的设备类型选择对应的驱动脚本API文件，自动解析API指令，并通过数据收发模块将指令发给对应的设备。

2.4.1 服务规则的触发

根据服务规则的定义，触发条件可以是场景启动操作、定时触发或变量触发。图5展示了规则触发判定流程。

图5 规则触发流程图

当用户执行场景启动命令时，系统查询该场景所包含的规则并将之标记为有效；若为定时规则，则交由时间线程处理；若为即时规则，则触发该规则。

时间线程负责定时触发的判别，该线程定时遍历所有定时规则的时间条件，若规则有效且当前时间与时间触发点相符，则触发该规则。

变量监测线程负责变量触发，当接收到某环境或设备变量的数据后，该线程查询所有与该变量相关的原子条件以及所有包含此原子条件的规则，若当前规则有效，则触发该规则。

规则触发过程包括环境条件的判断以及环境条件成立时设备动作的执行。环境条件成立与否依赖于对其包含的所有条件组的判断。系统首先将条件组转换为析取范式，即将规则条件拆分为以“或”连接的形式，其中每一个合取子句被称为原子条件串。然后对同一环境条件下的原子条件串、同一原子条件串下的原子条件分别进行遍历。对原子条件进行解析，根据当前对应的变量数值判断该原子条件成立与否。若任一原子条件不成立，则该原子条件串不成立。只要任一原子条件串成立，则环境条件成立。在规则中未设置环境条件以及环境条件成立的情况下，系统将执行预设的设备动作。