未来智讯 > 智能家居论文 > 智能家居监控平台的研讨与实现

智能家居监控平台的研讨与实现

发布时间:2018-11-30 01:06:05 文章来源:未来智讯    
    智能家居监控平台的研讨与实现作者: 吴志辉   摘 要:智能家居是未来最大的市场之一,但其发展速度差强人意。文中对目前智能监控平台,特别是智能家居系统的现状进行了分析,研讨并提出了一个设备互联互通的解决方案,从而实现了通用智能监控系统。同时还描述了基于监控驱动程序中间件的监控平台的架构、特性和事务原理,为智能家居的发展提供了不同的解决方案。该技能已申请发明专利,并在实际项目中得到了良好的应用。
  关键词:智能家居;物联网;中间件;设备监控驱动;设备对象
  中图分类号: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 mDictionary = null;
  Int32 smarthomeflag = 0xAA11; //某厂商设备系统通讯的标志,不是的,不处理
  public stringJson(Int32 _flag)
  {
  mDictionary = new Dictionary();
  smarthomeflag = _flag;
  }
  ……
  }
  字典结构为Dictionary,由于“值”是字节数组,能够存储任意内容,包括多媒体信息、嵌套的字典结构。SHProtocol的制定针对各种监控相关操作,指定其对应的字典结构,如登录、获取设备状态数据、发送开关量抑制指令、执行任务指令等操作的字典词条。在监控驱动程序中处理数据时,需要对协议中制定的各种字典词条逐一进行判断。
  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或服务器上(功率
转载请注明来源。原文地址:https://www.7428.cn/page/2018/1130/49167/
 与本篇相关的热门内容: