CN104618357A - 一种基于改进的knx/eib协议栈的智能家居管理*** - Google Patents

Abstract

一种基于改进的KNX/EIB协议栈的智能家居管理***，包括：标准设备、智能设备、KNX路由器、中央模块CU、移动智能终端；标准设备通过KNX总线与KNX路由器连接；KNX路由器与CU互联；CU和智能设备接入骨干网，CU同时与智能终端无线连接；标准设备符合ISO/IEC 14543-3标准；智能设备包括额外硬件接口，用于向外广播该设备的概要注解状态和功能，向CU发送基于概要的请求以获得服务；KNX路由器用于将KNX/EIB帧和IP帧的相互转化发送，用于缓存报文；CU用于网络的配置、监控、以及标准设备和智能设备的服务/资源发掘和远程控制的任务，为标准设备和智能设备提供运算能力；标准设备、智能设备、KNX路由器、CU以及智能终端之间通过基于改进的KNX/EIB协议通信，协议包括微概要层。

Description

一种基于改进的KNX/EIB协议栈的智能家居管理***

技术领域

本发明涉及物联网技术和计算机应用技术领域，特别涉及一种基于改进的KNX/EIB协议栈的智能家居管理***。

背景技术

在物联网总线方面，欧洲KNX标准是一个被国际广泛采纳的标准，KNX被广泛应用于智能家居***，KNX/EIB协议是由欧洲安装总线(EIB)、欧洲家庭***(EHS)和BatiBus协议这三个现有的协议综合优化而得到的。该协议是对EIB协议进行向后兼容改进后得到的，故名KNX/EIB。智能家居是智能环境的子集，智能环境(AmI)是指人们被部署在环境中的各式智能化的微小芯片包围，这些小芯片反应灵敏，能够识别用户概要文件，并且能根据识别的内容和感知到的环境参数进行自适应。无需用户的直接干涉，设备之间能够根据各种因素(例如用户是否在场和用户的喜好等)进行自主的交互，其中有一个单独的智能***负责协调这些设备。目前的HBA方案离这个目标还很遥远，远没有达到上述的灵活性和自动化水平。

现有的智能家居管理方法需与用户进行繁琐的交互，且大多是在方案部署时预置一系列操作的静态方案，灵活性和自动化程度不高。

发明内容

为了实现代化的、智能的HBA***，使之能够根据环境参数自主调节各种设备，需要考虑普适计算、移动计算、人工智能理论和基于代理的软件设计等技术，克服现有的智能家居管理方法需与用户进行繁琐的交互，且大多是在方案部署时预置一系列操作的静态方案，灵活性和自动化程度不高的缺陷，在基于一种使用最广泛的HBA标准-KNX/EIB协议，提供一种基于改进的KNX/EIB协议的智能家居管理***。

一种基于改进的KNX/EIB协议栈的智能家居管理***，其包括：

标准设备、智能设备、KNX路由器、中央模块CU、移动智能终端；标准设备通过KNX总线与KNX路由器连接；KNX路由器与CU通过局域网互联；CU和智能设备接入骨干网，CU同时与智能终端无线连接；

标准设备符合ISO/IEC 14543-3标准；智能设备包括能够与IP网络直接通信的额外硬件接口，智能设备用于向外广播该设备的概要注解状态和功能，并用于向CU发送基于概要的请求以获得服务；KNX路由器用于将KNX/EIB帧和IP帧的相互转化并发送，同时用于缓存报文；CU用于网络的配置、监控、以及标准设备和智能设备的服务/资源发掘和远程控制的任务，并用于为标准设备和智能设备提供运算能力；

标准设备、智能设备、KNX路由器、CU以及智能终端之间通过基于改进的KNX/EIB协议通信，改进的KNX/EIB协议包括微概要层。

在本发明所述的基于改进的KNX/EIB协议栈的智能家居管理***中，所述CU包括图形用户接口模块、客户端管理器、数据库管理器、自动推理模块、KNX管理器、设备代理模块；

图形用户接口模块用于提供用户与***的交互接口，并用于显示以概要注解格式组织的基本家居参数、设备状态和接收到的请求以及针对请求的响应；

客户端管理器用于将移动智能终端连接到CU，通过移动智能终端来查看家居环境的状态，以及用来提交移动智能终端的概要文件；

数据库管理器用于在CU启动阶段解析由软件工程工具ETS3生成的XML文档以检测家居的配置和网络拓扑；

自动推理模块用于通过在CU中嵌入目的匹配器进行自动推理，在ALN描述逻辑中使用标准和非标准的推理程序实现概要请求和服务/资源的匹配过程；

KNX管理器包括与物理网络连接的接口，用于使用Calimero NG库来控制标准设备、智能设备，控制包括激活/禁用该标准设备、智能设备的服务；

设备代理模块，用于存储标准设备概要注解，并为标准设备提供运算功能。

在本发明所述的基于改进的KNX/EIB协议栈的智能家居管理***中，改进的KNX/EIB协议是在标准的KNX/EIB协议栈的顶层加入了一个微概要层；微概要层添加了两个新的接口对象用于保存用户概要的配置文件以及设备功能概要配置文件；

新的接口对象格式包括：16位的对象类型字段，用于描述标准设备或智能设备的通用概要GPD和专用概要SPD；通用概要GPD用于描述设备的通用特征，每一台标准设备或智能设备关联一个唯一的GPD；专用概要SPD用于描述标准设备或智能设备的特有功能和操作模式，一台标准设备或智能设备拥有一个或一个以上的SPD，每个SPD对应该设备的一个开放服务/功能；

16位本体通用唯一标识符OUUID，用于标识设备概要注解所依赖的参考本体；在每次的匹配过程中，通用唯一标识符OUUID可以从***运行的知识域上进行初步选取；

OUUID组的属性标识码PID_OUUIDs，该字段仅指GPD，并且包含设备SPD的OUUID列表；

设备注解编码头部PID_SEMANTIC_HEADER，其以变长字符串形式存储；

设备注解编码主体PID_SEMANTIC_BODY，以字符串形式存储。

在本发明所述的基于改进的KNX/EIB协议栈的智能家居管理***中，在改进的KNX/EIB协议中，其包括两个服务原语，其中一个用于发送设备代理模块根据环境中侦测到的事件而生成的概要描述；另一个服务原语用于对上述概要请求的响应。

在本发明所述的基于改进的KNX/EIB协议栈的智能家居管理***中，上述两个原语的类型以编码的形式包含在应用层协议数据单元APCI中，编码的值从改进的KNX/EIB协议的APCI保留字中选取。

本发明在KNX协议中整合了微概要层，使HBA具有资源发掘和决策支持功能，从而使***具有较高的自主性和灵活性，同时保持完全向后兼容。采用对用户透明且由设备驱动的交互，而不是当前常用的静态配置方法。由于KNX支持基于KNXnet/IP协议的IP通讯，本方法以此作为骨干网通讯协议可以扩展出很多本地总线没有的控制和管理功能，与用户的交互使用IEEE802.11和蓝牙等无线通讯协议。本发明避免了现有的智能家居管理方法需与用户进行繁琐的交互，灵活性和自动化程度高。

附图说明

图1是本发明实施的基于改进的KNX/EIB协议栈的智能家居管理***结构框图；

图2是图1中中央模块的结构框图；

图3为设备代理模块概要增强通信示意图。

具体实施方式

为了提高可行性并充分利用行业的支持，本发明基于一种使用最广泛的HBA标准-KNX/EIB协议，对用户管理和设备属性/服务管理进行概要增强，利用KR技术和推理技术制定了一个自适应的框架。KNX/EIB协议是由欧洲安装总线(EIB)、欧洲家庭***(EHS)和BatiBus协议这三个现有的协议综合优化而得到的。该协议是对EIB协议进行向后兼容改进后得到的，故名KNX/EIB，支持以下几种物理介质：双绞线(TP)、电力线(PL)、无线电(RF)和以太网，遵守KNXnet/IP协议。KNX网络使用分层的拓扑结构和寻址结构来识别访问设备或整个域。在建议的部署方案中，所有的设备共享相同的域地址，因为他们属于同一组部署。KNX也支持组播所需的多地址空间。使用统一的main.middle.little分组格式描述多个设备或者不同设备的多个功能。

为了提高可行性并充分利用行业的支持，本发明是基于一种使用最广泛的HBA标准-KNX/EIB协议，对用户管理和设备属性/服务管理进行概要增强，利用KR技术和推理技术制定了一个自适应的框架。本发明在协议栈的顶层加入一个微概要层，添加了两个新的接口对象以保存设备与功能(即给定本体的DIG片段)的概要注解。为了遵循标准，新加入的接口对象完全根据标准协议的要求而定。接口对象是包含设备特征的数据结构，由设备属性组成，每一个属性描述包括：(1)属性标识码(PID)；(2)属性数据类型(PDT)；(3)属性值中可包含元素的最大数量(max_no_of_elem)；(4)属性访问权限字段。属性值由max_no_of_elem+1个元素组成：元素0表示有效元素的个数。有一个属性对所有接口对象都是强制的：一个16位的唯一标识码。KNX协议根据对象的目的为这个标识码定义了不同的值范围。为了减少设备功能概要和用户概要的注解长度，本发明运用了基于XML本体语言的压缩算法，为每一个已编码的文档生成文档头和文档主体，使用设备通用概要(GPD)描述设备的通用特征，例如：设备类型，制造商或者型号等。每一台设备关联一个唯一的GPD。使用设备专用概要(SPD)来描述设备的特有功能和操作模式。一台设备可以拥有多个SPD，每个SPD对应该设备的一个开放服务/功能。新加入的接口对象格式如下：(1)PID_OBJ_TYPE：16位的对象类型字段，GPD和SPD最多分别有1200和1205个字符，这些值都在KNX/EIB协议的接口对象值范围之内。(2)PID_OUUID：16位本体通用唯一标识符(OUUID)，用于标识设备概要注解所依赖的参考本体；在每次的匹配过程中，该参数可以从***运行的知识域上进行初步选取。进行任何发掘之前，用户代理和家居代理必须就参考本体达成一致，因为该本体提供了特定知识域的通用概念。(3)PID_OUUIDs：OUUID组。该字段仅指GPD，并且包含设备SPD的OUUID列表。(4)PID_SEMANTIC_HEADER：设备注解编码头部。以变长字符串形式存储。(5)PID_SEMANTIC_BODY：设备注解编码主体。同样是字符串类型的属性。

如图1所示，一种基于改进的KNX/EIB协议栈的智能家居管理***，其包括：

标准设备、智能设备2、KNX路由器3、中央模块CU4、移动智能终端；标准设备通过KNX总线与KNX路由器3连接；KNX路由器3与CU4通过局域网互联；CU4和智能设备2接入骨干网，CU4同时与智能终端无线连接。移动智能终端可以是平板电脑51和/或智能手机52。标准设备可以是风扇11、音响12、电灯13。

标准设备符合ISO/IEC 14543-3标准；智能设备2包括能够与IP网络直接通信的额外硬件接口，智能设备2用于向外广播该设备的概要注解状态和功能，并用于向CU4发送基于概要的请求以获得服务；KNX路由器3用于将KNX/EIB帧和IP帧的相互转化并发送，同时用于缓存报文；CU4为一个轻量级的软件组件-中央单元，用于网络的配置、监控、以及标准设备和智能设备2的服务/资源发掘和远程控制的任务，并用于为标准设备和智能设备2提供运算能力。

标准设备、智能设备2、KNX路由器3、CU4以及智能终端之间通过基于改进的KNX/EIB协议通信，改进的KNX/EIB协议包括微概要层。

IP网络作为高速骨干网。在家居配置文件中，KNX设备(标准设备、智能设备2)通过KNX总线连接到一个或多个KNX/IP路由器上，而每个路由器又连接到骨干网，从而形成多个子网络。***中包含标准设备和智能设备2，前者符合ISO/IEC 14543-3标准，后者则与虚拟KNX/EIB设备性质相同，被赋予了额外的硬件接口从而能够与IP网络直接通信。此类设备符合上文所述对标准协议的概要增强。

如图2所示，在本发明所述的基于改进的KNX/EIB协议栈的智能家居管理***中，所述CU4包括图形用户接口模块41、客户端管理器46、数据库管理器42、自动推理模块43、KNX管理器44、设备代理模块45。

图形用户接口模块41用于提供用户与***的交互接口，并用于显示以概要注解格式组织的基本家居参数、设备状态和接收到的请求以及针对请求的响应。

客户端管理器46用于将移动智能终端连接到CU4，通过移动智能终端来查看家居环境的状态，以及用来提交移动智能终端的概要文件。移动智能终端通过IEEE802.11无线协议或者蓝牙协议与CU4通信。本发明可以使用基于Android***的智能手机作为客户端来测试相应的模块。

数据库管理器42用于在CU4启动阶段解析由软件工程工具ETS3生成的XML文档以检测家居的配置和网络拓扑。

由于ETS3(Engineering Tool Software)本身并不负责管理本发明所述的概要增强部分，因此需要对ETS3生成的基本配置文件进行扩展，这样才能将它们导入数据库管理器42。本文通过在每一个设备服务中添加一行实现：<func type＝”A|S|I”value＝”VAL”desc＝”NAME”>。其中，类型属性选项中的A表示执行器，“S”表示传感器，“I”(即“Intelligent”)表示智能设备2。“desc”是参考SPD接口对象的一个标签，该接口对象包括服务的概要注解，这样就可以通过设备访问该服务了。每一个服务都通过一个变量与标准KNX数据类型关联，当服务启动时时，该变量被发送到其所在设备。上述的描述允许使用面向用户的高级表示法描述服务/资源，而由低级的面向设备的服务/资源执行单元触发执行。解析后的网络拓扑数据(包括组地址，数据类型和各个设备可用的功能/服务等)保存进数据库作为设备缓存。本程序中使用SQLite作为数据库管理器42，SQLite是一款轻量级的SQL数据库引擎。在程序启动阶段，从各个设备相应的接口获取每个可用服务/资源的概要描述，然后存进数据库，从而减少网络阻塞和响应延时。需要说明的是，无论使用配置文件还是数据库都是为了提高设备性能，向网络中添加设备或者从中移除设备/服务都是通过KNX/EIB标准协议原语实现，然后更新相应的缓存信息。

自动推理模块43用于通过在CU4中嵌入目的匹配器进行自动推理，在ALN描述逻辑中使用标准和非标准的推理程序实现概要请求和服务/资源的匹配过程。

本发明同时结合环境中的可用服务，使用一种基于概念覆盖的算法来尽可能多的覆盖请求中描述的特征。由用户或设备启动交互顺序，执行步骤如下：(a)查询数据库，获取所有设备(标准设备/智能设别)的可用服务并与他们的地址(开机时填充缓存以减少延时)关联。(b)通过KNX管理器44中的一个特殊方法读取每个设备的状态，根据状态数据类型，使用字符串、数值或布尔类型表示。(c)使用<address,staus>键值对作为Key从数据库中提取概要注解，然后将服务分为可用组和不可用组。(d)通过的概念收缩算法，查找出与请求不兼容的服务，然后将其禁用。(e)使用概念诱导算法，检查请求是否已经被可用服务完全覆盖。(f)如果请求没有被完全覆盖，使用CCoP方法选择激活一个或多个服务(执行一次基本检查来跳过当前可用的服务)，使用它(或者它们的组合)来覆盖请求中未被满足的特征。算法的返回值是可用和不可用的两组服务，同时还有请求中未被覆盖的部分(如果存在)。

KNX管理器44包括与物理网络连接的接口，用于使用Calimero NG库来控制标准设备、智能设备2，控制包括激活/禁用该标准设备、智能设备2的服务。

Calimero NG(基于Java语言)库还包含几个工具和方法以简化网络管理。本发明通过对其扩展来访问设备上的标准属性和概要属性。KNX管理器44还可以包括消息管理器(Message Manager,MM),负责执行以下几个基本任务：(a)分析和提取KNXnet/IP帧中的字段从而控制CU4和设备之间的通信；(b)识别概要框架并管理其内容。需要特别注意的是，CU4使用统一的方式管理标准KNX数据和概要注解，所以必须要遵守协议规范。

设备代理模块45，用于存储标准设备概要注解，并为标准设备提供运算功能。如图3所示，设备代理模块45还能够支持概要改进，同时能够简化本方法中模块。这样一来，如果CU4需要标准设备属性，相应的请求将被路由器通过网络传送到指定的设备。反之，如果请求需要概要注解，代理则做出响应。

在本发明所述的基于改进的KNX/EIB协议栈的智能家居管理***中，改进的KNX/EIB协议是在标准的KNX/EIB协议栈的顶层加入了一个微概要层；微概要层添加了两个新的接口对象用于保存用户概要的配置文件以及设备功能概要配置文件。

新的接口对象格式包括：16位的对象类型字段，用于描述标准设备或智能设备2的通用概要GPD和专用概要SPD；通用概要GPD用于描述设备的通用特征，每一台标准设备或智能设备2关联一个唯一的GPD；专用概要SPD用于描述标准设备或智能设备2的特有功能和操作模式，一台标准设备或智能设备2拥有一个或一个以上的SPD，每个SPD对应该设备的一个开放服务/功能。

16位本体通用唯一标识符OUUID，用于标识设备概要注解所依赖的参考本体；在每次的匹配过程中，通用唯一标识符OUUID可以从***运行的知识域上进行初步选取。

OUUID组的属性标识码PID_OUUIDs，该字段仅指GPD，并且包含设备SPD的OUUID列表。

设备注解编码头部PID_SEMANTIC_HEADER，其以变长字符串形式存储。

设备注解编码主体PID_SEMANTIC_BODY，以字符串形式存储。

本发明在协议栈的顶层加入一个微概要层，添加了两个新的接口对象以保存设备与功能(即给定本体的DIG片段)的概要注解。为了遵循标准，新加入的接口对象完全根据标准协议的要求而定。接口对象是包含设备特征的数据结构，由设备属性组成，每一个属性描述包括：(1)属性标识码(PID)；(2)属性数据类型(PDT)；(3)属性值中可包含元素的最大数量(max_no_of_elem)；(4)属性访问权限字段。属性值由max_no_of_elem+1个元素组成：元素0表示有效元素的个数。有一个属性对所有接口对象都是强制的：一个16位的唯一标识码。KNX协议根据对象的目的为这个标识码定义了不同的值范围。为了减少设备功能概要和用户概要的注解长度，本发明运用了基于XML本体语言的压缩算法，为每一个已编码的文档生成文档头和文档主体，使用设备通用概要(GPD)描述设备的通用特征，例如：设备类型，制造商或者型号等。每一台设备关联一个唯一的GPD。使用设备专用概要(SPD)来描述设备的特有功能和操作模式。一台设备可以拥有多个SPD，每个SPD对应该设备的一个开放服务/功能。新加入的接口对象格式如下：(1)PID_OBJ_TYPE：16位的对象类型字段，GPD和SPD最多分别有1200和1205个字符，这些值都在KNX/EIB协议的接口对象值范围之内。(2)PID_OUUID：16位本体通用唯一标识符(OUUID)，用于标识设备概要注解所依赖的参考本体；在每次的匹配过程中，该参数可以从***运行的知识域上进行初步选取。进行任何发掘之前，用户代理和家居代理必须就参考本体达成一致，因为该本体提供了特定知识域的通用概念。(3)PID_OUUIDs：OUUID组。该字段仅指GPD，并且包含设备SPD的OUUID列表。(4)PID_SEMANTIC_HEADER：设备注解编码头部。以变长字符串形式存储。

在本发明所述的基于改进的KNX/EIB协议栈的智能家居管理***中，在改进的KNX/EIB协议中，其包括两个服务原语，其中一个用于发送设备代理模块45根据环境中侦测到的事件而生成的概要描述；另一个服务原语用于对上述概要请求的响应。

为了达到设备交互与用户独立，有两个特定的应用层服务原语非常重要：(1)A_SEMANTIC_SUBMISSION.req，用来发送设备代理根据环境中侦测到的事件而生成的概要描述。(2)A_SEMANTIC_SUBMISSION.res，包含对上述概要请求的响应。原语的类型以编码的形式包含在应用层协议数据单元(APCI)中，编码的值从KNX/EIB协议的APCI保留字中选取。该服务允许设备使用通用KNX帧的协议数据单元(APDU)自动交换概要元数据。尽管概要注解描述被压缩过，长度仍可能超过14个字节，因此本发明使用了KNX标准支持的扩展帧，长度可达255个字节，其中249个字节用来存储数据。另外，本发明定义了一个新的PDT，名为PDT_GENERIC_EXT，用来指定变长字符串的最大长度。如果被压缩过的概要注解的长度超过KNX扩展帧的最大长度，则将其分割为多个不同的帧，这样一来，分割后的帧数目将作为“number_of_elements”字段保存在相关的接口对象中。接收端通过顺序访问属性值数组中的元素将其组合成完整帧。

在本发明所述的基于改进的KNX/EIB协议栈的智能家居管理***中，上述两个原语的类型以编码的形式包含在应用层协议数据单元APCI中，编码的值从改进的KNX/EIB协议的APCI保留字中选取。

本发明在KNX协议中整合了微概要层，使HBA具有资源发掘和决策支持功能，从而使***具有较高的自主性和灵活性，同时保持完全向后兼容。采用对用户透明且由设备驱动的交互，而不是当前常用的静态配置方法。由于KNX支持基于KNXnet/IP协议的IP通讯，本方法以此作为骨干网通讯协议可以扩展出很多本地总线没有的控制和管理功能，与用户的交互使用IEEE802.11和蓝牙等无线通讯协议。本发明避免了现有的智能家居管理方法需与用户进行繁琐的交互，灵活性和自动化程度高。

基于上述理论框架，建立了测试平台用来验证框架的可行性并评估其能力，平台模拟了一块家居区域，即：大厅的门、卧室、厨房、一小块室外空间。目前该平台集成了13个设备/电器，包括传统的电气设备和符合KNX标准的设备，如表1所示。

表1 设备列表

设备通过双绞线作为总线使用分层的结构相连。这些设备一共开放42种不同的服务/功能，每个服务/功能都绑定一个组地址。因为KNX标准没有强制的地址分配规定，本平台使用以下规则：main组表示区域；middle组表示服务类型，“0”仅表示输入，“1”仅表示I/O服务；little组用于标识给定区域的服务/资源。主面板中包含各种设备，包括KNX路由器，根据KNXnet/IP标准，路由器负责将标准KNX/EIB帧转换为IP帧，反之亦然。此外，它还能缓存报文以保持总线低负载。面板包含4个过载保护断路器，还有常见的数字(on/off)和模拟开关等。特别是面板模拟了卧室和厨房，包含传统灯和调光灯。此外，面板上还有一个模拟驱动器用来模拟电动窗帘。最后，测试平台上有一个报警***，由外部警报器和内部警报器组成，外部警报器通过部署在家居周围的传感器实现。CU负责管理报警器。内部报警器由一个摄像头和红外传感器实现。为了模拟室外区域，平台中加入了一个气象站装置。用来测量风速、亮度、天气、和温度等。以下是在上述测试平台上进行的测试过程和结果。

本发明的案例研究包括几种不同的方案，能够最大程度的利用本框架所带来的好处。假设有一个能与家居设备交互的智能气象站，家中有两个不同的用户，测试平台是一个全功能KNX安装。在智能设备的可编程稳定存储器(也就是，EEPROM或固态硬盘)里存有它们的服务描述的概要注解。从技术产品化的角度来看，服务概要在出厂时被预设，而后，智能设备本身如果与主网络相连，很容易进行修改，而概要请求则在数据收集阶段产生，概要的分析和注解算法则嵌入在设备中。另一方面，传统设备的默认概要注解应该从ETS数据库中提取，然后修改；在***正常运行期间，相关的设备代理负责管理它们。测试平台中使用了一个软件代理以实现气象站的智能化。基于从气象站获得的数据，可以侦测到环境的变化，然后适应环境变化的请求被发送到决策设备，该设备根据请求，同时参考用户概要对家居***和设备做出相应的调整。以下是一个简单的例子：

一个阳光明媚、天气温和的早晨，家居环境中使用了一种典型的设置，空调打开，所有窗帘打开。到了中午，天气开始多云，看起来好像要下雨。此时，智能气象站感知到温度和亮度下降，而风速和湿度升高。通过这个数据收集过程，气象站处理信息，得知天气将变坏，从而产生一个概要注解的事件描述。

表2 测试用例比较

该案例中涉及几个自动化本体的主要分类，第一级分大致将本体分为以下几组：设备、服务、用户状态和天气状况，第二部分主要表示HBA应用程序中建模和推理所需的概念；属性则大多用来关联用户概要和有类似概念请求的设备。根据AmI范例，不需要用户干预就可以获得***的某个服务；例如当气象站检测到天气变化时，触发代理使其做出相应调整以适应变化，期间CU充当协调器和基于概要的分析器。

在第一个测试中，由于天气变化，***关闭空调并放下窗帘。此外由于亮度变低，***打开房间的灯，然而从用户概要得知用户感觉头痛，***则关闭音乐播放器，并选择使用柔和的灯光以适应用户需求。在第二个测试中窗帘同样被放下。温度的突变使用户感觉到冷，从而***启动空调加热功能而不是简单的关闭空调制冷。此外，由于室外光线较暗，灯光需要设置为较明亮的级别，考虑到用户概要中没有发现与此项设置冲突的配置，因此这项设置生效。最后，由于用户生病导致行动不便，外部警报器被激活；而音乐播放器没有执行任何操作，因为用户没有对其进行配置。

结合本发明中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机储存器、内存、只读存储器、电可编程ROM、电可檫除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其他形式的存储介质中。

可以理解的是，对于本领域的普通技术人员来说，可以根据本发明的技术构思做出其它各种相应的改变与变形，而所有这些改变与变形都应属于本发明权利要求的保护范围。

Claims (5)

1.一种基于改进的KNX/EIB协议栈的智能家居管理***，其特征在于，其包括：

标准设备、智能设备、KNX路由器、中央模块CU、移动智能终端；标准设备通过KNX总线与KNX路由器连接；KNX路由器与CU通过局域网互联；CU和智能设备接入骨干网，CU同时与智能终端无线连接；

标准设备符合ISO/IEC 14543-3标准；智能设备包括能够与IP网络直接通信的额外硬件接口，智能设备用于向外广播该设备的概要注解状态和功能，并用于向CU发送基于概要的请求以获得服务；KNX路由器用于将KNX/EIB帧和IP帧的相互转化并发送，同时用于缓存报文；CU用于网络的配置、监控、以及标准设备和智能设备的服务/资源发掘和远程控制的任务，并用于为标准设备和智能设备提供运算能力；

标准设备、智能设备、KNX路由器、CU以及智能终端之间通过基于改进的KNX/EIB协议通信，改进的KNX/EIB协议包括微概要层。

2.如权利要求1所述的基于改进的KNX/EIB协议栈的智能家居管理***，其特征在于，所述CU包括图形用户接口模块、客户端管理器、数据库管理器、自动推理模块、KNX管理器、设备代理模块；

图形用户接口模块用于提供用户与***的交互接口，并用于显示以概要注解格式组织的基本家居参数、设备状态和接收到的请求以及针对请求的响应；

客户端管理器用于将移动智能终端连接到CU，通过移动智能终端来查看家居环境的状态，以及用来提交移动智能终端的概要文件；

数据库管理器用于在CU启动阶段解析由软件工程工具ETS3生成的XML文档以检测家居的配置和网络拓扑；

自动推理模块用于通过在CU中嵌入目的匹配器进行自动推理，在ALN描述逻辑中使用标准和非标准的推理程序实现概要请求和服务/资源的匹配过程；

KNX管理器包括与物理网络连接的接口，用于使用Calimero NG库来控制标准设备、智能设备，控制包括激活/禁用该标准设备、智能设备的服务；

设备代理模块，用于存储标准设备概要注解，并为标准设备提供运算功能。

3.如权利要求2所述的基于改进的KNX/EIB协议栈的智能家居管理***，其特征在于，改进的KNX/EIB协议是在标准的KNX/EIB协议栈的顶层加入了一个微概要层；微概要层添加了两个新的接口对象用于保存用户概要的配置文件以及设备功能概要配置文件；

新的接口对象格式包括：16位的对象类型字段，用于描述标准设备或智能设备的通用概要GPD和专用概要SPD；通用概要GPD用于描述设备的通用特征，每一台标准设备或智能设备关联一个唯一的GPD；专用概要SPD用于描述标准设备或智能设备的特有功能和操作模式，一台标准设备或智能设备拥有一个或一个以上的SPD，每个SPD对应该设备的一个开放服务/功能；

16位本体通用唯一标识符OUUID，用于标识设备概要注解所依赖的参考本体；在每次的匹配过程中，通用唯一标识符OUUID可以从***运行的知识域上进行初步选取；

OUUID组的属性标识码PID_OUUIDs，该字段仅指GPD，并且包含设备SPD的OUUID列表；

设备注解编码头部PID_SEMANTIC_HEADER，其以变长字符串形式存储；

设备注解编码主体PID_SEMANTIC_BODY，以字符串形式存储。

4.如权利要求3所述的基于改进的KNX/EIB协议栈的智能家居管理***，其特征在于，在改进的KNX/EIB协议中，其包括两个服务原语，其中一个用于发送设备代理模块根据环境中侦测到的事件而生成的概要描述；另一个服务原语用于对上述概要请求的响应。

5.如权利要求4所述的基于改进的KNX/EIB协议栈的智能家居管理***，其特征在于，上述两个原语的类型以编码的形式包含在应用层协议数据单元APCI中，编码的值从改进的KNX/EIB协议的APCI保留字中选取。