智能家居监控平台的研究与实现
申请发明专利，并在实际项目中得到了良好的应用。
关键词：智能家居；物联网；中间件；设备监控驱动；设备对象
中图分类号：TP277 文献标识码：A 文章编号：2095-1302（2016）11-00-04
0 引 言
物联网把万物接入互联网，使得人类监控这些物理设备的愿望得以实现。但前提是这些物理设备需要具备一定的智能特性，并符合生产厂商的通信规范才能在厂商提供的特定应用中与人类进行交互。如众多的智能家居设备厂商，其家居产品能通过互联网和智能终端设备（手机、平板电脑）与用户远程交互，极大地方便了主人对家庭电气电子设备的监控。但互联互通的问题仍未得到很好的解决。
如果购买了智能空调、智能冰箱、智能电视机、智能洗衣机、智能安防系统、智能门锁、智能传感器、智能穿戴式健康监护设备等众多未来家庭必须的产品，那么主人的智能手机上可能需要安装众多厂商提供的App，只有通过它才能与各自的设备交互，使用极为不便。而这就是目前智能家居的现状。
更为糟糕的是，这些异构的设备之间互不认识，无法“物物相连”进行交互，更无法满足设备之间的联动以达到主人需要的功能。如果检测到火灾发生，却无法自动把家里的门锁打开，若要满足这个要求，只有使用一个厂商的整套设备才可以实现，而垄断和价格高昂就成为必然，公民利益被绑架，也由此导致居民不愿意购买价格较高的“智能”设备，恶性循环，致使产业发展缓慢。因此设计一个亲民的智能家居监控系统势在必行。
1 解决监控平台通用的方案
消费者自然希望通过单个App就可以监控家庭中的所有智能设备，不管这些设备来自哪个厂商。更加期望随心所欲的定制设备间的联动来自动完成主人需要的任务，即智能家居DIY，包括硬件DIY和监控行为DIY。
由于各厂商的设备通信协议不同或数据格式不同，用一个程序去满足众多设备的数据通信要求是极不现实的。正如互联网络和终端的多样性，通过Web服务器可把异构网络连接在一起实现数据共享。智能监控系统可提供类似的服务平台，把不同设备系统的通信数据规范化，对外提供统一的监控协议（Smart Monitor Protocol，SMProtocol），任何移动终端设备（Mobile Terminal，MT）只要遵循SMProtocol的规范，就可与智能监控系统内部的各种异构的设备交互。这个轻量级协议就是物联网中间件的主要组成部分之一。
尽管有很多智能家居监控的研究方案[1-3]，但大多注重云平台的研究。我们的方案则基于家庭微型服务器，在其中搭建运行中间件的智能家居监控服务平台（SmatHome Platform，SHP），这是一种低成本、安全、扩展灵活的解决设备互联互通的有效方案。智能家居服务平台（SHP）由多个服务程序组成，可运行在低成本的微型PC、平板电脑或服务器中。SHP基于目前家庭最常用的网络环境部署，其运行环境如图1所示。
由图1可知，移动终端通过互联网或局域网与SHP交互。设备子系统（Equipment SubSystem，ESS）可以通过无线或有线方式与SHP通信。设备系统内部的通信与SHP无关，可选用ZigBee、蓝牙、RS 232等方式。SHP通过中间件与设备系统交互。这种结构可以方便地把各种异构设备系统接入监控平台，智能家居DIY得以实现，而我们只需要在SHP上安装一个中间件。分析这个结构发现，我们完全不需要设备厂商提供的云平台服务，同时无线设备系统不使用UPNP协议与智能移动终端直接通信。
2 通用监控平台中间件的功能和设计
监控中间件必须具备以下几点功能：
（1）对外提供统一的监控接口。
（2）监控子系统的内部设备系统负责把外部监控协议翻译成特定设备系统的指令，从而实现对设备的监控。
（3）为监控服务平台的其他程序提供设备状态数据变化事件（DataChanged），以便服务平台对设备状态变化做出反应，从而实现设备间的联动。
（4）中间件的通信足够简单，尽可能少修改设备系统的原有控制程序的工作量。
2.1 监控设备驱动程序中间件
各厂商内部的智能监控设备子系统（ESS）对外的通信方式有差别，有些使用串口设备通信，而有些使用TCP网络通信协议，或采用有线或无线的方式通信。通信的数据格式更是千差万别。这给中间件的开发设计带来了困难。
借鉴操作系统管理硬件设备的方式，我们设计了一个应用层面的通用监控接口，用特定程序实现，即“监控设备驱动程序”（Monitor Device Driver，MDD）。每个监控驱动程序可与特定厂商的设备系统ESS交互，一个实例化的中间件可以监控一个设备子系统。
当SHP加入一个新的设备子系统时，我们只需要动态加载其监控驱动程序。由监控服务平台统一协调管理各监控驱动程序。
2.2 监控驱动程序中间件的设计
监控驱动程序必须实现一个智能设备子系统ESS的接口，以便管理其中的所有设备。每个设备也必须实现一个接口，使其能对设备进行监控。监控驱动程序接口设计类图如图2所示。
（1）ISmartHome接口定义了特定厂家某个产品的设备或设备子系统，其中可以包含多种不同的设备IhomeDevice。
（2）IHomeDevice由六类不同的子设备组成。目前看来，六类子设备能很好的抽象家居设备系统。它们是数值量输入输出设备IDeviceDI，IDeviceDO；模拟量输入输出设备IDeviceAI， IDeviceAO；流输入输出设备IDeviceSI， IDeviceSO。理论上，这六类子设备的组合可以描述任意复杂的设备。
（3）IBaseDevice接口是六类设备的父接口，描述了设备的通用接口规范。
（4）IWriteReadInterface接口用于设备数据的存储、读取。
设计实现了图2接口的监控驱动程序，完整的描述了一个设备子系统，具备对其中任意一个子设备的监控能力。在应用驱动程序中，按照智能监控的通用协议（SHProtocol）把外来监控数据转换为控制设备的指令，同时把设备的状态数据转换为SHProtocol规范格式，并回送给移动终端，从而完成监控交互。
在六类设备中，引入了事件接口（Event），使得设备状态发生变化时，SHP能及时获得通知，从而有机会对设备进行控制。
2.3 监控驱动程序中间件协议的设计
已有厂商的设备系统通信数据格式众多且不统一。为了尽可能减少设备嵌入式程序的修改，又能方便数据转换，设计一个数据字典来规范数据格式，SHP设计的通信数据包程序如下：
public class stringJson
{
public Dictionary
Int32 smarthomeflag = 0xAA11； //某厂商设备系统通信的标志，不是的，不处理
public stringJson（Int32 _flag）
{
mDictionary = new Dictionary
smarthomeflag = _flag；
}
……
}
字典结构为Dictionary
3 通用监控平台设计及实现
虽然监控驱动程序中间件在SHP中扮演着重要角色，但管理这些驱动也极其重要。SHP针对每个设备系统启动一个监控服务程序（SmartHome Monitor，SHM），SHM加载相应的监控驱动程序与设备子系统交互。通过SHP与SHM的隔离，移动控制终端对ESS的监控就能统一。智能监控系统的结构示意图如图3所示。
由图3可知，SHM可能有多个，ESS可以包含N个子设备（SubDevice，SD），该架构由移动应用层、监控管理层、设备监管层、硬件设备层组成。
3.1 移动应用层
MT或PC使用规范的SMProtocol和TCP/IP协议与SHP交互。如果MT与SHP在同一局域网内，MT使用指定的端口号和IP地址登录SHP；否则使用域名与SHP连接。MT使用一个App就可以通过SHP监控所有设备。
3.2 监控管理层
监控管理层（Management Layer）是局域网内的一台服务器（Smart Home Server，SHS），通过路由器、网关接入互联网。服务器程序由多个服务模块组成。SHS的组成及其关系如图4所示。
User Management维护可以接入平台的人员信息，赋予账号、密码和权限。只有登录系统，用户才能接入SHP平台监控智能家居系统。User Management的UI界面如图5所示。
Session Management可实现通信会话管理。使用TCP/IP接收Application Layer发来的协议指令，使用进程间通信方式（IPC）转发数据给处在Monitor Layer中的对应SHM。同时接收Monitor Layer发来的设备状态数据，然后转发给所有在线的MT。对非法连接的MT，自动断开回话。Session Management定义的连接端口如图6所示。
PNP Management：SHProtocol定义了PNP消息广播协议。当ESS在局域网广播此消息时，SHP就获取ESS的监控驱动程序名称、驱动下载地址、通信方式等信息，SHP会自动下载ESS的驱动程序，注册并启动一个SHM来与设备系统交互。PNP Management定义的广播端口如图7所示。
图7 PNP Magagement定义了广播端口
Device Management用以管理所有符合ISmartHome接口规范的监控驱动程序，提取并保存所有ESS的数据信息。对不支持PNP的设备系统可以人工注册。Device Management还负责启动并传递适当参数给SHM，必要时可以强行结束SHM。Driver Management实现UI界面如图8所示。
Device Management可以自动搜索所有MDD，注册登记需要接入平台的设备驱动或移去注册的驱动。
Task Management：用户需要的操作功能有时需要对不同设备进行一连串的操作才能实现。可以定制任意数量的设备操作步骤，即通过任务来达到目的。定时任务也可以指定实现主人在特定时间启动设备控制的要求。还可以为每天指定不同的定时任务，更加精细的满足主人要求。因为SHS知晓所有ESS的信息，所以Task Management可以直接操控设备，这为设备间的复杂联动提供了基础。Task Management的实现UI如图9所示。
一个任务可以包含多个不同设备的控制，指定其先后次序和延时。
Event Monitor Management负责监视设备的状态是否发生变化。可以对感兴趣的数据设置变化响应机制，为自动控制提供了触发机制。事件响应的设置界面如图10所示。
对所有设备系统的输入设备（DI，AI，SI）进行响应设置，为其指定一个任务。
可以看出，Device river Management在SHS中扮演着重要角色。而现在可以轻松实现诸多家庭任务。比如周三早晨10点自动启动花园的浇水系统，如果下雨，则自动停止浇水。
3.3 设备监控层
设备监控层（Monitor Layer）由多个智能监控服务程序SHM组成。它与SHP之间使用规范的SMProtocol和进程间通信机制进行通信。SHM运行时的通用监控画面如图11所示。
SHM动态加载设备子系统的监控驱动程序，并根据驱动通信要求启动适当的通信程序，它接收来自SHS的指令，并传递给驱动程序，由驱动程序翻译成能控制设备系统的具体指令，从而达到控制设备的目的。驱动程序收到的设备状态数据转换为符合SMProtocol协议的规范数据，通过SHM上传给SHS，最终传递到移动终端。
SHM与ESS的通信方式根据ESS驱动程序的要求来制定。SHM可以作为服务器工作，也可以作为客户端工作，这些均由驱动程序决定。SHM作为TCP/IP通信服务端的设置界面如图12所示。
3.4 硬件设备层
硬件设备层（Device Layer）由不同类型的子设备系统组成。它们可以是智能的、非智能的硬件系统，也可以是虚拟设备系统。它需要根据相应的驱动程序的规范，做一些程序上的修改来满足通信要求。如车载导航系统，在修改程序后可远程接入SHM，这样家庭成员可以随时了解小车的位置和状态。健康监护腕带设备在编写监控驱动程序并适当修改原来的通信程序后，可以接入SHM，方便的将家庭老人或病人的信息及时传递给家庭成员或者远方的医疗监护系统。
ESS与其内部子设备的交互几乎不变，可以最大限度保护已有投资。把现有很多应用程序按SMProtocol协议为其编写监控驱动程序，适当修改应用程序的通信方式，将其改造为一个虚拟设备系统，可以接入SHP，由MT进行监控。如运行在PC机上的家庭影院或背景音乐系统，都可以设计成虚拟设备系统。
4 SHP的优势
SHP提供了一个安全、易于实现、易于使用、低成本的智能家居运行环境。其具有如下优点：
（1）安全性。MT与内部设备系统交互的唯一方式是通过登录SHP接入监控平台。登录需要账号与密码。在监控驱动程序级别，还可以设置授信名单和黑名单，防止非法授权操作设备。SHP运行在家庭内部的PC或服务器上，安全性较高。也可断开与外界的通信，仅在家庭局域网内工作。这与传统的在Web服务器上部署Web服务的方式不同，与设备通过蓝牙与手机进行直连交互的方式更不同。
（2）易于实现。任何实现IsmartHome规范的设备监控驱动程序都可以接入SHP。理论上，只需要在SHP安装设备监控驱动程序，就可以方便监控任意复杂的设备系统，同时数据存储和挖掘功能也可以在SHP实现。SHP可能是未来家庭服务器的重要组成部分。而SMProtocol通信协议足够简单且能满足任意复杂监控的需求，硬件设备的原有嵌入式程序只需修改或增加通信部分即可接入SHP。设备厂商投入较小的成本就可升级传统产品为智能家居产品。原来需要厂商搭建的云服务平台或可取消，极大地减轻了厂商的负担和运行费用。
（3）易于使用。SMProtocol协议保证了监控系统对外交互的统一界面。只需一个应用App就能方便监控整个智能家居系统，并任意指定设备间的联动操作需求。通过监视感兴趣的事件，可以实现自动报警。用户对智能家居DIY成为现实，包括硬件DIY，监控需求DIY等。
（4）低成本。SHP可部署在200美元内的平板电脑、低端PC或服务器上（功率<20 W），Windows或Linux操作系统都可以。一个家庭只需一个SHP即可智能家居DIY。这也许是SHP的缺点——微型服务器必不可少。如果把网关、路由器等功能集成在专用的微型服务器上，或可降低成本。
5 结 语
该智能家居联网技术已经申请了发明专利，并在特定行业得到了应用。若该方案能得到大力推广，那么其在智能家居行业的意义将不亚于TCP协议对于互联网的重要性。因为缺少统一的智能家居行业标准，开放式智能家居永远都不可能实现井喷式发展。
参考文献
[1]E. Kaldei， E.U. Warriach， J. Bresser， et al. Interoperation， composition and simulation of services at home [C]. 8th Int. Conf. on Service Oriented Computing（ICSOC-10）， Springer， vol. LNCS 6470， （2010）： 167-181.
[2]Muhammad Waqar Aziz. Service-Oriented Layer Atchitecture for Smart Home[J]. International Journal of Smart Home， 2013， 7（6） ： 409-418.
[3]NamKyung Lee， Hyum Woo Lee， Won Ryu.Consideration for Web of Object Service Architecture on IoT Environment[J]. International Journal of Smart Home， 2015， 9（1） ： 195-202.
推荐访问： 智能家居 监控 研究 平台
