CN103713612B - 一种便于个性化定制和扩展的智能家居***解决方案 - Google Patents

Abstract

本发明涉及一种智能家居***的解决方案，实现了用户可灵活地接入或增减各种家电设备，并根据各自的偏好或习惯定制家电设备的各种监控组合，满足家居***个性化、动态化、安全性和隐私保密的要求。为了实现上述目的，本方案对智能家居***作出了清晰的子***划分和层次化的架构设计；同时，基于分解和映射技术，建立了监控器和监控对象的控制抽象模型及其描述形式；并利用再组合技术实现了用户对情景的自由定制；还提出了一种内外网一致性访问的用户终端实现技巧；最后在***的发布、静态代码的存储、通信通道等各个环节，分别采用了不同的加密技术和安全措施，最大限度地保护了用户隐私、运营商利润、以及***的安全。

Description

一种便于个性化定制和扩展的智能家居***解决方案

技术领域

本发明属于智能家居领域，具体涉及智能家居***的一种解决方案。

背景技术

随着物联网概念及其应用技术的发展，作为物联网在家居领域的一个应用，智能家居***也从过去少数几个家用电器设备所组成的简单的直接的灯光控制功能或安防报警功能，向复杂的智能化的多设备***的联动监控发展。同时，现代家居生活的个性化和动态化特点，也要求智能家居***能便捷灵活地接入或增减各种具有不同电气接口和实现不同功能的家用电器设备，并根据用户的习惯和偏好，随时地增减、调整、或定制不同的多设备的智能控制功能组合。此外，互联网的发展和移动互联设备的普及，以及智能小区和智慧城市概念的兴起，过去单纯地局限于单个家居范围内的智能家居***，也增加了通过外网远程监控和通信的实用需求。最后，用户个人隐私意识的增强，以及基于运营商利润和***运行安全性等方面的考虑，也对数据通信通道尤其是外网互联通道以及产品本身的安全性和保密性提出一定的要求。

发明内容

本发明提出了一种支持家用电器设备(监控对象)的灵活接入和扩展、支持用户自定制智能控制功能组合(情景)、支持内网外网的一致性监控、并确保通信通道以及***本身的安全性和保密性的智能家居解决方案。

本方案基于***架构的层次化定义，以及监控器与监控对象的模型抽象、分解和再组合技术。该方案包括以下要点：

(1)智能家居***的子***划分与层次化架构；

(2)监控器和监控对象的模型抽象：分解与映射技术；

(3)监控对象元的再组合和情景的实现和控制技术；

(4)内外网一致性访问的用户终端实现技巧；

(5)***和通信通道的加密和安全机制。

附图说明

本说明书共附有7张图：图1是智能家居***的***架构图，图2是智能家居控制***的软件架构图，图3是监控对象元和监控器端口的监控模型示意图，图4是监控对象元和监控器端口监控模型的一个举例图，图5是监控器数据库的树状描述示意图，图6是监控对象数据库树状描述示意图，图7是情景的状态转化示意图。

具体实施方式

一、智能家居***的子***划分与层次化架构

区别于其他的由用户终端直接控制家用电器设备的***架构，本发明提出了一种清晰的子***划分以及层次化的智能家居***架构。

首先，智能家居***分成用户终端、智能家居网关、智能监控器、监控对象四个子***。每个子***之间的接口做标准化的抽象处理，确保各个子***在软硬件上的一定程度的独立性。如图1所示。其中，

1、用户终端(以下简称“终端”)是用户操控整个智能家居***的接入点，一般为通用的智能手机、平板、个人电脑PC、或其他电子设备，在这些电子设备上运行着智能家居用户终端软件，向用户提供操作界面，并通过标准的以太网报文协议和智能家居网关之间进行命令和数据交互，来向网关发送操控监控器的命令或获取来自监控器的数据；

2、智能家居网关(以下简称“网关”)是整个智能家居***的核心，除了①实现以太网和监控器总线网之间的报文协议转化的网关功能之外，还发挥着②实现监控对象和监控对象元向监控器和监控器总线的映射转化、③情景的解释、执行和监控、④监控器和监控对象的动态监控和管理等功能；

3、智能监控器(以下简称“监控器”)是整个智能家居***的执行中枢，负责把来自监控器总线(以下简称“总线”)网上的报文命令和数据，转化成对监控器端口(及其相连接的监控对象元)的相关操作，同时，把通过监控器端口检测到的(监控对象的)状态或其他数据，转化为符合总线网通信协议的报文命令或数据，发送到总线网上；

4、监视控制对象(以下简称“监控对象”)，指的是那些最终受控的家用家电设备或输入传感器等，比如电灯、电视、空调、窗帘、冰箱、面板、触控开关、热水器、换气扇、洗衣机、电饭煲、微波炉、洗碗机、气感、烟感、红外探头、门磁、电子锁、监控摄像头等。监控对象可分为检测输入对象、控制输出对象，以及数据对象等。比如大厅里的电视机就是一个控制输出对象：通过监控器输出开关信号控制电视机电源的开启和关闭，通过监控器输出红外信号来控制电视机的音量调节和换台等操作；而卧室床头的触控开关则是一个检测输入对象，当按下触控开关的时候，触控开关向监控器输入边沿信号；而提供采集视频或图像流的摄像头，则可定义为一个数据对象，通过其对应的监控器上传图片或视频数据流。本方案提出了一种抽象分解及映射的技术，来对监控对象的进行抽象建模与描述，详情请参考下一节“监控器和监控对象的模型抽象：分解与映射技术”。

其次，智能家居的***软件架构，可分为应用层、核心层、以及网络层，如图2所示。其中，

1、应用层面向的对象是监控对象、监控对象元、或他们的控制组合(称为“情景”)。监控对象经过分解后得到监控对象元，对监控对象元建立标准化的处理模型，在应用层和核心层之间，定义统一的数据接口定义格式，这些接口定义格式与监控对象及其接入的总线类型或端口编号无关；

2、核心层负责协议报文的生成、解析、转化，以及其他一些核心功能的实现，包括总线转化、监控对象的分解与映射转化、权限管理、情景的解释执行、监控器和监控对象的动态监控与管理等功能。当核心层需要向网络层传递数据时，会根据上行或下行的区别以及监控对象所在的总线类型，自动选择正确的网络层接口(以太网、CAN、485、RF433/315、Zigbee、WIFI、….)进行通信；

3、网络层负责用户终端与网关、网关与监控器之间的底层通信的实现。各种总线类型的收发模块与核心层之间按照统一的接口格式定义，各种的监控器和网关之间定义了统一的通信接口格式。

二、监控器和监控对象的模型抽象：分解与映射技术

1、监控器的建模

(1)如图3中间监控器部分所示，在智能家居***中，监控器的对外接口可以简化描述为：①一个监控器总线接口，实现监控器和智能家居网关之间通过总线连接和通信，总线类型可为CAN、RS485、RF315/433、Zigbee、WIFI等各种类型其中的一种，每个监控器在其总线上都分配有唯一的总线地址，因此，对于一个安装好的智能家居***，数据组<总线类型，总线地址>和监控器之间建立了一一对应的映射关系；②一个或多个端口，每个端口都一个监控对象元相连，实现对监控对象的输入检测或输出控制，而每个端口可以通过端口位号唯一标识。因此，对于一个安装好的智能家居***，描述符<总线类型，总线地址，端口号>和监控对象元之间也建议了一一对应的映射关系。这里的端口，可以是物理上的端口，比如监控器上某个实际IO口的输入或输出，也可以逻辑上的端口，比如某个实际的物理端口通过寻址等方式派生出来的每个逻辑端口。例如一个红外收发器的全部红外输出，根据编码的逻辑分组，可定义出多个逻辑端口，每个逻辑端口分别遥控不同的家用电器；

(2)根据家用电器设备的特点，监控器的类型大体包括：①智能红外转发器，用于实现对电视、空调等电器的红外遥控；②智能调光器，用作灯光的亮度调节；③智能插座/开关，用于控制电器设备的电源的接通和关断；④智能驱动器，用于输出一些逻辑高低电平，来控制外部的一些需要直接IO控制的继电设备比如窗帘等；⑤智能传感器，用于输入一些家电设备的数字开关量或检测模拟输入量，比如光电脉冲、触控开关、门磁、气感、烟感的输入等；⑥智能安防，用于配合视频摄像头等的控制和数据的边带传输；⑦其他一些特殊类型的监控器等等。

2、监控对象的建模

如图3的右部分所示，针对家居内的各种监控对象，从电气控制的便利性(容易接入监控器的某个标准化的端口)以及用户操作的自然习惯的角度，进行模型分解和标准化抽象，将目标监控对象分解抽象成一个或多个便于接入标准化监控器端口的监控对象子单元(称为“监控对象元”)。例如，对于电视机、机顶盒、空调等电器设备，最直观的控制分解“电源开关”和“遥控”两个监控对象元，并分别接入某个智能插座/开关的一个端口和智能红外转发器的某个端口，***只需通过监控器对应的这两个端口操控这两个监控对象元，即可实现对这台电视机的操控，如图4举例所示；对于带电池的烟雾传感器，只有一个“烟感输入”的输入检测的监控对象元；对于煤气阀，则有一个“继电控制”的输出控制的监控对象元；而对于监控摄像，包括一个“控制通道”的监控对象元，来实现下发命令或提取状态，以及一个“数据通道”的监控对象元，用于通过边带传输大数据量的视频流或图像流，这两个监控对象元，使用的可能是某几个监控设备的某几个逻辑端口。

3、监控器/监控器端口、监控对象/监控对象元的属性及其映射关系的数据库描述和关系运算

根据以上分析，我们通过两个简单明了的数据库来描述这些模型的属性以及他们之间的从属和映射关系。这些数据库文件保存在智能家居网关上，用户终端可以通过以太网获得实时更新：

(1)一个监控器数据库文件，包含了对当前智能家居***中所使用的所有监控器的描述，每个监控器对应一条数据库记录。如图5所示，每个数据库记录包含：标识名(用于标识该监控器的一个表意的名字，比如“大厅里的电源插座1”、“大厅里的红外转发器”等)、该监控器所属的总线类型(比如RF433MHz总线，表示该监控器通过RF433MHz总线和网关进行通信)、总线地址(分配给该监控器的总线地址，用于区别于同一条总线上的其他设备进行寻址)、监控器类型(标识该监控器所属的设备类型，可配合总线地址实现进一步的寻址过滤或操作过滤等扩展功能，比如“智能插座/开关”、“无线红外转发器”等)、以及其他一些可实现辅助功能的数据库记录项

(2)一个监控对象和监控对象元数据库文件，包含了对当前智能家居***中所使用的所有监控对象及其监控对象元的描述。如图6所示，本数据库采用二级树目录的形式排布，树干节点代表一个监控对象，每个树干节点下面跟随多个树叶节点，每个树叶节点包含一条数据库记录，每个记录对应该监控对象的一个监控对象元。每个树干节点有一个唯一的标识，对应监控对象的标识，如“大厅里的电视机”。每片树叶代表的监控对象元所对应的数据库记录包含：标识名(用于表示该监控对象元的一个表意的名字，比如“遥控”、“电源插座”等)、该监控对象元所接入的监控器的标识名(如“大厅里的红外转发器”、“大厅里的电源插座1”等)、该监控对象元所接入的监控器的端口号(如“端口1”)、以及其他一些可实现辅助功能的数据库记录项(比如操作该端口的用户权限等)

(3)关系映射与查找解析：

通过对“监控器数据库文件”和“监控对象和监控对象元数据库文件”的关系运算，网关可以方便地将来自用户终端的操作描述，转化为总线报文发给监控器，或者将来自监控器的总线报文，转化为用户终端可会意的操作或状态描述；

对于下行的操作，具体的做法描述如下：①用户终端通过以太网向智能家居网关发送一个操作描述(比如：“接通大厅里的电视的电源插座”)，该描述最基本的核心包含一个监控对象元(比如“大厅里的电视的电源插座”)和一个针对这个监控对象元的操作码和操作参数(比如“接通”电源)。②智能家居网关接收到这个操作描述后，从“监控对象和监控对象元数据库文件”里根据监控对象标识和监控对象元标识找到对应的记录，得到该记录中的“所接入的监控器标识”(比如“大厅里的智能插座1”)、“所接入监控器端口号”(比如“m”)、以及其他辅助功能的参数(比如“操作权限”为“普通用户”)等。③接着，根据得到的“所接入的监控器标识”，从“监控器数据库文件”查找得到该监控器所对应的“总线类型”(比如“CAN”)、“总线地址”(比如地址为“2”)、以及“监控器类型”(比如“智能插座开关”)。④于是，智能家居网关根据简单的关系运算，将来自用户终端的操作描述(即：监控对象元+操作码和操作参数)转化成了一个适合在总线上发送出去的数据报文的核心体部分(即：总线类型+总线地址+监控器类型+报文数据，其中报文数据＝监控器端口号+操作码和操作参数)，并按照规定的报文协议发送到总线上。⑤“总线类型+总线地址+监控器类型”实现对目标监控器的寻址，而“监控器端口号+操作码和操作参数”由监控器负责解析并转化，在该监控器的目标端口，执行输出控制或输入检测等操作。而由于该监控器的这个端口，和目标监控对象元相连，于是，最终实现了对该监控对象元的监控；

对于上行的操作，具体的做法相当于上面下行的一个逆过程，简要描述如下：①监控对象元通过其连接的监控器端口向监控器发送数据，该数据的核心体包括操作状态码和操作状态参数。监控器在接收到该数据后，和该端口号以及总线地址组合之后，通过该监控器所在的总线，以总线报文的格式发送给智能家居网关。②智能网关在某个总线接口接收到该总线报文后，根据其中的“总线类型+总线地址+监控器类型”，从“监控器数据库文件”查找到对应的监控器标识，然后从“监控对象和监控对象元数据库文件”里根据“监控器标识和端口号，得到监控对象元标识。③智能家居网关将“监控对象元标识+操作状态码和操作状态参数”通过以太网发送给用户终端。

4、监控器和监控对象的增减或修改

(1)监控器和监控对象的增减和修改，等效于上述两个数据库文件的生成和修改

(2)为了方便用户操作的可读性，那些与用户终端应用层有关的一些元素标识，包括监控器、监控对象的标识、监控对象元的标识，都采用直接表意的方式(如“大厅里的智能插座1”、“大厅里的电视”、“电源开关”等)；而那些处于核心层或网络层的元素，则可以使用枚举赋值的形式简化处理，比如总线类型CAN定义成“0”，总线类型RF433定义成“1”，其他监控器总线类型依此类推

(3)特别地，对于各种监控对象元的操作状态码和参数的定义和解析，交给应用层完成。在用户终端的应用层，针对各个监控对象，都有数据库文件与之对应，这个数据库文件实现数字化的操作码及参数和表意化的操作码及参数之间的一一映射，称之为“监控对象表意描述数据库文件”。当用户终端软件需要向某个监控对象下发命令时，通过表意化的操作码及参数查找得到数字化的操作码及参数，通过网关和监控器发送给监控对象；当用户终端软件接收到来自某个监控对象经过监控器和网关所传递上来的操作状态码及参数时，通过数字化的操作码及参数反查得到表意化的操作码及参数，并在用户终端软件的用户界面显示。因此，当增加一个新类型的监控对象时，主要是在用户终端软件里增加一个针对该监控对象的“表意描述数据库文件”，这样处理后，在增减或修改监控对象时，不仅做到了与核心层和网络层的无关性，而且保证用户终端应用软件核心体和监控对象的无关性，从而极大地增加了向智能家居***增减或修改监控对象的简便性

(4)监控对象的分解抽象以及数据库的生成和修改，在首次安装、后期增减或更改监控对象时动态完成。用户可以通过一个简单的小工具来完成这项工作，也可以交由供应商根据用户使用监控对象的方式，离线生成后上述三个数据库文件后，下载到用户终端软件包里和智能家居网关里。

5、小结

经过上述建模过程后，包括对监控对象分解抽象和数据库映射和关系运算，监控对象可以灵活简便的接入各种标准化的监控器，同时，也很容易组合得到更高层次的监控组合和实现对情景控制模式的支持。

三、监控对象元的再组合和情景的实现和控制技术

1、监控对象元的再组合和情景的概念

将上述经过抽象分解并和监控器端口之间建立起映射关系的监控对象元，如果按照单个监控对象的基本组成，在应用层重新组合监控，称为简单再组合，可以实现对单个监控对象的监控。如果进一步，将多个监控对象或多个监控对象的监控对象元，按照一定的用户习惯或功能目的进行组合，同时加入程序化的执行顺序和逻辑判断条件，则称之为复杂再组合，或称为情景。情景属于高层次的用户意图的一种组合表现形式，例如用户希望在回家的时候可能希望门厅能播放音乐，开启门厅廊灯，并打开窗帘。将用户的这些对于电器进行操作的意图进行组合描述，就是一种情景。对单个监控对象的监控的简单再组合，也被作为一种最简单的情景来处理。

2、情景的状态属性及其转化

(1)情景依据其当前所处于的状态，可主要分为静止、激活，和执行状态，以及一些方便功能扩展的其他可进一步自定义的状态：

①静止态：情景最初以静态文件流的形式保存与***的文件***里，情景的这种状态被称为情景的静止态

②激活态：要让一个情景在***中起作用，首先应将该情景载入***内存。如果情景在被载入内存后，并不马上执行而是进入监视等待状态(等待一个被称为“触发因子”的动因)，那么该情景被载入后的这种状态被称为激活态。这种将该情景载入***内存的动作被称为情景的“激活”，它一般来自于外部用户的激活命令，也可能来自另外一个情景内部对这个情景的嵌套调用命令。处于激活态的情景是一种“就绪监视”态，它时刻监视着其触发条件是否得到满足，以及是否有外部触发命令到来。在触发条件得到满足时，或当接收到外部触发命令，情景会从激活态进入执行态

③执行态：处于执行态的情景，会执行情景所定义的一些列操作序列。在执行完毕后，会依据情景的定义的退出条件，自动回到静止态或激活态

④扩展态：静止态、激活态、执行态是情景最主要的三个状态。为了给***增加或扩展一些功能，在这些状态之外，可以扩展一些过渡性或描述性的状态，称之为情景的扩展态。情景的扩展态主要发挥一些辅助性的作用

(2)情景的状态转化：

如图7所示，情景的三种主要状态之间的转化示意图。处于静止态的情景，通过激活命令或触发命令，而进入激活或执行状态。处于激活态的情景，通过撤销命令而退回静止状态；通过触发命令或监视到触发因子，而进入执行态。处于执行状态的情景，通过撤销命令或在其操作序列执行完毕后，依据情景本身的属性或撤销参数，或进入静止状态，或进入激活状态而重新开始对触发因子的监视。这里所说的命令，或者是外部用户的操作命令，或者是来自另外一个情景的嵌套调用命令。

3、情景的构成要素

构成情景的要素，包括：

(1)情景的标识名称：

一个用来唯一标识某个情景的表意的名称，比如“回家模式”

(2)情景被触发的条件---触发因子、触发前提、触发保留时间：

触发因子、触发前提、触发保留时间，用于指定激活态情景的被触发的因素以及约束

①触发因子：处于激活态的情景，在出现某个或某几个因素时会自动被触发而进入执行态，这个因素被称为触发因子。比如，执行某个报警功能的情景，平时一般处于监控就绪的激活态；当检测到有人进来时候，就会将转入执行态开始执行播放警告、发送短信通知等操作；每天夜晚8点都会自动开启大厅灯等模拟有人在家的操作。在这里，“检测到有人进来”、以及“每天到夜晚8点”分别各是两个触发因子。触发因子是一个“点”的概念，分为状态变更和定时触发两种。如果是状态变更触发，在电气上表现为检测到一个数字信号的跳变边沿，或者某个模拟量穿越某个阈值；如果是定时触发，在时间上表现为当前时间到达或正在越过某个时刻点。触发因子可以有多个，它们之间是“或逻辑”的关系

②触发前提：触发因子能发挥作用的前提条件，只有在触发前提条件被满足时，触发因子才被接受而触发情景进入执行状态。比如，某个浇花情景，要求只在每周二和四的上午九点且室温在10-30摄氏度时才执行浇水动作，在这里上午九点可以作为一个触发因子，“周二、四”和“室温在10-30摄氏度”就是两个触发前提，这两个前提之间是“与逻辑”的关系。触发前提是一个“区间”的概念，包括状态前提和时间前提两种。如果是状态前提，在电气上表现为检测到一个数字信号的高低电平状态或者一个模拟量落在某个区间，如果是时间前提，在时间上表现为，当前时间位于某个时间区间。出发前提可以有多个，它们之间是“或逻辑”的关系

③触发保留时间：在某些特殊应用的场合，需要在情景被激活后的一段时间内，即使存在触发因子且满足触发前提，也不触发该情景进入执行状态。只有当情景被激活超过这段时间后，情景才可以在存在触发因子且满足触发前提的条件下被触发。这段时间，被称为“触发保留时间”

(3)操作序列集：

①操作序列集是情景作用的核心部分。情景通过解释执行操作序列里的一系列操作，完成情景所描述的一系列用户意图

②操作序列集由多条操作序列组成，每条最基本的组成包括：操作对象、操作码与参数、序列执行的时间偏移、重复执行的次数和间歇、执行的前提条件等。其中，“操作对象”的类型包括监控对象元(比如“大厅里的电视机的电源开关”)、监控器(比如“大厅里的所有监控器”)、情景(比如“离家模式”)、以及其他需要用到的目标实物(比如“短信”、“总线”、“用户终端”)等；“操作码与参数”代表的附加给操作对象的操作类型和参数，比如“开启”、“复位”、“触发且执行完毕后进入激活态”、“短信通知，内容是XXXX”、“通过总线上传数据XXXX”、“通知用户终端，数据为XXXX”等；序列执行的时间偏移，指的是在情景被激活后多长时间才开始执行本操作序列，每个操作序列的时间偏移不同，从而实现了多操作的逻辑顺序以及时延执行；有些场合某个操作需要重复执行，“重复执行的次数和间歇”用来支持操作序列的这种属性；执行的前提条件，是该序列会被执行的前提条件，比如某个操作序列是这样描述“目标对象是大厅的窗帘、操作码是开启、时间偏移等于10秒、执行的前提条件是户外亮度超过3级”，其中“户外亮度超过3级”就是执行开启窗帘动作的前提条件，即只有户外的足够亮的时候，才需要执行这个操作序列去开启窗帘

③情景不仅完成了对监控对象元及其组合的一系列操作描述，而且也支持除监控对象之外的其他一些目标对象的管理和维护，如上面的例子中，通过操作序列“复位大厅里所有监控器”、“撤销离家模式”、“短信通知，内容是XXXX”等等，就不局限于对监控对象的操作

(4)操作序列执行完毕后的情景状态：

当情景所有的操作序列被执行完毕后，情景可以从执行状态向两个不同的状态转化，分别是激活态和静止态。有些情景，当所有的操作序列执行完毕后希望它能彻底退出，比如“回家情景”，在触发回家模式执行完开灯、播放完音乐、换气、开窗帘等动作后，我们不再需要这个情景继续存在，于是可以彻底推出这个情景。而另外一些情景，我们希望当所有的操作序列执行完毕后，继续回到“就绪监视”的激活态来继续监视触发因子，当收到触发因子的时候，操作序列集会被再次执行，比如“离家安防情景”，今天9点浇完花后，以后的日子如果触发满足要求，则需要再次执行这个操作序列，于是当执行这个情景后，我们希望它回到激活状态继续监视触发因子和条件

这项功能，可以通过一个“操作序列执行完毕后的状态”标志来实现。

4、情景的描述和解释执行

(1)本方案采用脚本文件(称为情景描述脚本)的方式对情景进行描述。脚本文件里依次包含多个情景描述脚本项目，每个情景描述脚本对应一个情景，定义一些关键字来表征情景的各个构成要素

(2)通过对情景描述脚本的载入和解释执行，来实现用户的各种意图

①情景的激活：扫描情景描述脚本文件，根据情景的“标识名称”匹配得到的对应的情景项，将该情景的构成要素以一个结构体实例的形式载入内存，将该情景的状态设置为“激活态”，并开始监控该情景被触发的条件

②情景的触发：当接收到外部触发命令或者激活态的情景的被触发条件得到满足，则该情景需要被触发。如果该情景尚未被激活，则先按照上述“①情景的激活”的方法激活该情景，然后触发该情景。情景被触发后，***顺序扫描操作序列集里的每一个操作序列，依据“3、情景的构成要素”中的定义解释，依次解释执行。当所有的操作序列(包含其重复的次数)被执行完毕后，依据情景本身的“操作序列执行完毕后的情景状态”属性，或者在发送“触发命令”时，所携带的“操作序列执行完毕后的情景状态”参数，确定情景下一步是进入静止态或激活态

③情景的撤销：处于激活态或执行态的情景，可以通过外部的撤销命令，退出当前的状态，而进入静止态或激活态。

四、内外网一致性访问的用户终端实现技巧

如图1中所示，用户终端包括内网用户终端和外网用户终端；

对于内网用户终端，在智能家居网关上开辟一个服务器端守护线程，每个局域网用户终端作为客户端，直接向同一个局域网段内的智能家居网关发起连接(connect)，然后通过套接字(socket)进行通信；

对于外网用户终端，却无法直接从外网向内网内的智能家居网发起连接。为了解决这个问题，本发明提供了两种解决方案，这两种方案可以并列存在。

(1)基于路由器内外网端口映射技术的解决方案

方案的描述：有一些路由器本身具备一种称之为“虚拟服务器”的端口转发功能，实现外网数据向内网内指定ip地址的服务器端口进行映射，从而实现将外网的用户终端映射到内网内。如果在这种类型的路由器上，将路由器的某个端口映射到智能家居网关的服务器端口上，外网用户终端访问路由器对应的外网ip地址和端口时，就好象在内网内的用户终端一样连接智能家居网关服务器端守护线程

这种方案的优势：实现起来比较简单

这种方案的局限性：①家居内局域网接入外网必须通过支持“虚拟服务器”的端口转发功能的路由器来完成，当路由器不支持这个功能，或者，当家居内局域网通过小区宽带或cable modem等形式接入外网时，该方法可能失效。所以，这种方法依赖于接入外网的方法，不具备普遍适用性，尤其是在很多家居内局域网接入外网的方式已经确定的前提下来新增部署智能家居***时，这种方法将受到极大的限制。②路由器在外网上的IP地址必须固定，或者必须采用动态域名技术来确保路由器的域名固定，只有这样，外网客户终端才可以正确的IP地址或域名链接路由器。即便如此，向外网服务提供商ISP申请固定IP往往会增加用户的租费；而采用动态域名技术，除了会增加一定的运营成本之外，往往也很难确保域名和ISP分配的动态IP之间对应关系的实时更新，所以在实际运营中，即使域名固定，也可能会出现无法成功连接的问题。③这种方法也不利于对于外网用户终端区别于内网用户终端的统一管理。

(2)智能家居网关“主动连接外网”的外网用户终端接入技术

方案的描述：实现为了克服上述“(1)路由器内外网端口映射技术”中的局限性，①在外网节点(或等效的内网向外网映射节点)上放置一台“外网服务器”(如图1中所示)，并在这个外网服务器的两个端口分别运行两个服务器端。②智能家居网关在开机后，作为客户端主动去连接其中一个端口对应的服务器端，并在连接成功后建立套接字，实现智能家居网关和外网服务器之间的通信。为了确保智能家居网关和外网服务器时刻保持连接，即使因为路由器的外网地址发生了改变，也确保智能家居网关和外网服务器的连接也是实时更新的，在智能家居网关和外网服务器之间建立了一种“心跳机制”，即：智能家居网关周期性地向外网服务器发送心跳查询命令，在接收到心跳查询命令后，外网服务器向智能家居网关返回一个心跳确认，当长时间没有接收到来自外网服务器的心跳确认时，智能家居网关即认为和外网服务器的连接已经失效，并重新发起新的连接和建立新的套接字通信，而外网服务器则始终用最新的连接套接字和智能家居网关通信。③外网用户终端需要访问智能家居网关的时候，先向外网服务器的另外一个端口对应的服务器端发起连接，并在连接成功后建立套接字，实现外网用户终端和外网服务器之间的通信。④外网服务器完成来自智能家居网关的套接字数据和来自外网终端的套接字数据之间的转发交换

这种方案的优势：①因为局域网节点主动访问外网一般没有什么限制，所以这种方案完全不受家居内网接入外网的方式的限制。②由外网服务器对来自智能家居网关的套接字数据和来自外网用户终端的套接字数据之间进行转发交换，便于实现对外网用户终端的统一管理，也便于在外网服务器和智能家居网关之间的通信建立严格的安全机制。③外网服务器可以是一个或多个，而外网服务器的引入，方便实现智能家居***向智慧小区和智慧城市的扩展。比如一个位于小区中心服务器上，一个位于运营商的中心服务器上，则可以很方便地实现小区内地统一维护管理以及运营商范围内的统一维护管理。

五、***以及通信通道的加密和安全机制

在智能家居网关上增加一颗硬件安全芯片，辅助实现一些安全加密功能。本发明提出了三个方面的安全加密机制，增强和软件逆向工程的难度，最大程度地确保了通信通道的安全性。

1、基于用户自定义的二进制文件加密发布机制

源始的软件二进制文件很容易被逆向工程所破解。一个获取得到源始的软件二进制文件的途径出现在二进制文件的发布过程中，包括生产、更新(含下载升级)等发布环节。本发明提出一种方案，让二进制文件在被发布的时候，采用用户自定义的加密算法进行加密，而其对应的解密算法在生产前，已固化在安全芯片内。在下载加密的二进制文件后编程写入智能家居网关的ROM中前，先由安全芯片进行解密。为了便于统一生产和维护，这里的加解密算法，对于一个批次或者一个运营商领域内的所有智能家居***，都是一致的。这种机制，有助于增加逆向工程的难度，确保运营商的利润，保护终端用户的隐私与利益。

2、基于硬件唯一性的加解密的代码存储和加载机制

源始的软件二进制文件很容易被逆向工程所破解。一个获取得到源始的软件二进制文件的途径出现在保存二进制文件的产品板的ROM里。本发明提出一种方案，让下载到智能家居网关的二进制代码，在烧写入ROM之前，先通过安全芯片进行加密处理，而在智能家居网关启动从ROM中加载代码后和执行代码之前，由安全芯片进行解密。这种加解密的参数预先固化在安全芯片内。每颗安全芯片所使用的加密参数都不一样，因此每个智能家居网关经过加密后保存到ROM中的二进制文件都不一样。所以，即使从某个智能家居网关的ROM读取出了二进制文件，也很难在烧入后在其他智能家居网关或者没有安全芯片的智能家居网关上执行。这种机制，极大地增加了逆向工程的难度，确保运营商的利润，保护终端用户的隐私与利益。

3、基于硬件唯一性和非对称算法的动态加解密通信机制

确保数据通信通道的加密安全，尤其是确保智能家居网关和外网服务器以及外网终端之间通信通道的加密安全，对于保证***运行的安全性和保护用户的隐私，发挥着极大的作用。本发明提出了一种基于硬件和非对称算法的动态加解密通信机制，具体描述如下：

①在每颗安全芯片内植入一对非对称加密算法的密钥对(私钥和公钥)，密钥对长度不少于1024位，称为固有密钥对。每颗安全芯片被分配一个唯一的芯片ID，且其内植入的密钥对也都各不相同。②将相关范围内的安全芯片的芯片ID及其公钥，组成一个数据库，保存在一个安全硬件(较高安全级别)或加密文件(较低安全级别)里，发到智能家居网关通信的对方(外网服务器或局域网用户终端)。③智能家居网关在和远端服务器建立连接后，或者在侦听到内网用户终端的成功连接后，在本地动态生成一对新的密钥对，将其中的动态公钥用固有密钥对的私钥加密后，连同自己的芯片ID一同发送给远端服务器或局域网用户终端。④远端服务器或局域网用户终端在收到③中来自智能家居网关的数据后，根据芯片ID查找安全硬件或加密文件里数据库，找到该芯片ID对应固有公钥，然后用这个公钥对加密后的动态公钥解密出来并保存在本地。接着，远端服务器或局域网用户终端也在本地动态生成一个密钥对，并用其中的公钥用上面查找得到的固有公钥加密发送给智能家居网关。⑤智能家居网关在接收到用自己的固有公钥加密后的远端服务器或局域网用户终端的动态公钥后，用自己的固有私钥解密出来。至此，智能家居网关和远端服务器或局域网用户终端，都获得了各自对方的动态公钥，同时保存着各自的动态私钥。于是，智能家居网关和远端服务器或局域网用户终端在发送或接收数据的时候，用各自的动态密钥加密，而用对方的公钥进行解密。⑥为了进一步增强安全性，对于动态密钥对的实效作出规定，当某次动态密钥使用的时间超过某个规定的时间后，通信的双方重新生成各自的密钥对，并重复上面的③～⑤的类似过程，将各自的动态公钥发送给对方

这种机制的优势除了充分发挥了非对称算法的本身优势之外，还在于：①由于各个智能家居网关的安全芯片里保存的固有密钥对各不相同且不对外泄漏，所以，即使某台智能家居网关的加密通道被攻破解，也不影响其他智能家居网关的通信通道；②由于通信过程中，绝大部分时间所使用的密钥对为现场动态生成的临时密钥，所以***本身的固有密钥对被暴露和破解的几率很低；同时，③由于动态密钥对具有时效性，所以，将难以获取得到同一加密参数的足够数量的密文，因此而增加了破解的难度；另外，即使某台智能家居网关的加密通信通道被攻破解，也仅仅只是在那段时间内破解有效而已。用户可以自由调节密钥对动态变化的频率，并在因动态密码交换所占用的带宽和增强的安全性之间寻求平衡。

Claims (4)

1.一种基于***架构的层次化定义和监控对象的抽象分解与再组合技术的智能家居解决方法，其特征在于，该方法包括如下步骤：

(1)智能家居***由用户终端、智能家居网关、智能监控器和监控对象四部分组成；用户终端通过以太网基于以太网报文协议和智能家居网关相连，智能家居网关通过监控器总线基于总线报文协议和智能监控器相连，智能监控器通过端口和监控对象相连；

(2)在应用层根据用户对监控对象的操作习惯以及与智能监控器的连接方式，将智能监控器被分解成多个监控端口，对监控对象进行抽象分解得到监控对象元，于是对监控对象的监控被抽象转化成对各个智能监控器的多个端口的监视和控制；具体地说，一个监控器被抽象成一个总线接口和多个端口组成，并对每个端口进行编号；一个监控对象被抽象成由多个监控对象元所组成，每个监控对象元接入一个特定的监控器端口，于是，对于一个监控对象元的监控，被抽象成对一个描述符的监控，而该描述符由总线类型、总线地址、端口号三个数据域组成，同时，对于一个监控对象的监控，则被抽象成多个对象元描述符的组合；在这里，监控器描述数据库和监控对象描述数据库分别描述了本***所有的智能监控器的属性和监控对象元所连接的监控器端口信息，并兼容监控器的多种总线类型，于是，对于监控对象的增减或变更，就变成了简单地对这两个数据库的相应修改；而将监控对象元的表意标识转化为其所对应的监控器端口，就成了对这两个数据库进行关系运算，来得到监控对象元所对应的描述符；

(3)对于从监控对象分解而得到的对象元，按照一定的用户习惯或功能目的进行高出监控对象本身的再组合，同时加入程序化的执行顺序和逻辑判断条件，来实现对用户复杂意图的情景模式的技术，包括情景的定义、情景的状态属性及其转化的规定、情景的构成要素、情景的描述方法和情景解释执行的方法，实现对情景的描述、执行和监控；

(4)在智能家居网关上保存有两个数据库，分别描述当前智能家居***中的智能监控器及其和监控对象元的映射情况，同时还保存着由用户自定制的用来描述情景的脚本文件；智能家居软件在其核心层对以太网报文命令和情景描述脚本进行解释，并转化为总线报文发送给智能监控器；智能监控器解释总线报文，并转化为对其相应端口的监控。

2.根据权利要求1所述的基于***架构的层次化定义和监控对象的抽象分解与再组合技术的智能家居解决方法，其特征是：清晰的智能家居***的子***划分与层次化架构，每个子***之间以及每个软件层之间，都有规范清晰的接口定义；具体地说，智能家居***分为用户终端、智能家居网关、智能监控器、监控对象四个子***；用户终端和智能家居网关之间有统一规范的以太网报文协议的定义；智能家居网关和智能监控器之间有统一规范的总线报文 协议的定义，兼容多种总线类型；智能监控器和监控对象之间有统一规范的端口编号和类型定义；同时在软件架构上，智能家居***又划分为应用层、核心层和网络层，在应用层进行监控对象的抽象分解和再组合定义，以及标准的以太网报文协议的生成或解析；在核心层将以太网协议或情景描述进行解释并转化为相应总线上的总线协议报文发送到各自对应的总线上去，并兼容多种监控器总线类型及其同时并存。

3.根据权利要求1所述的基于***架构的层次化定义和监控对象的抽象分解与再组合技术的智能家居解决方法，其特征是：内外网一致性访问的用户终端的实现技巧；内网用户端通过网关的服务器端主动式连接；外网用户则根据家居内网连接外网的方式，可采用“基于路由器内外网端口映射技术的解决方案”或“智能家居网关‘主动连接外网’的外网用户终端接入技术”；一旦建立连接之后，在TCP层采用相同的以太网报文协议，于是可采用相同的用户端软件实现内外网的一致性访问。

4.根据权利要求1所述的基于***架构的层次化定义和监控对象的抽象分解与再组合技术的智能家居解决方法，其特征是：***以及通信通道的加密和安全机制；具体地说，在代码的发布阶段，采用基于用户自定义的二进制文件加密发布机制，在代码的烧写和加载阶段，采用基于硬件唯一性的加解密的代码存储和加载机制，在数据通信环节，采用基于硬件唯一性和非对称算法的动态加解密通信机制。