CN1957583A

CN1957583A - 用于本地联网系统的设备抽象层

Info

Publication number: CN1957583A
Application number: CNA2005800169201A
Authority: CN
Inventors: A·阿达姆森; D·R·霍斯金斯; R·J·布莱克维尔; P·A·卢德兰德
Original assignee: Koninklijke Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 2004-05-24
Filing date: 2005-05-23
Publication date: 2007-05-02
Also published as: MXPA06013703A; KR20070033338A; JP2008501202A; TW200616398A; BRPI0511455A; WO2005117389A8; RU2006145862A; WO2005117389A1; GB0411528D0; EP1757060A1

Abstract

一种本地联网系统包括处理平台(110)和诸如家庭用具的目标设备(151－153)。所述平台支持诸如开放服务网关联盟(OSGi)的开放服务网关框架，执行应用(130)以控制目标设备(151－153)。目标设备每一个由实体(133)表示，该实体可以由应用(130)通过应用编程接口(API，134)来操纵。实体遵循设备类型的公共分层结构，在所述分层结构中代表较低层的设备类型的实体继承较高层的设备类型的属性，这对于应用表现出一致的API。所述实体可以构成使用诸如家庭统一控制语言(HUCL)的公共语言的抽象层的部分。每一个实体可以作为设备服务向框架登记，或者表示多个实体(147)的单个设备服务(146)可以向框架登记。

Description

用于本地联网系统的设备抽象层

本发明涉及一种本地联网系统、在该系统中使用的平台以及操作该平台的指令。

近几年，人们对于家庭环境中的联网应用具有很大的兴趣，并且已开发了多种联网协议。通用即插即用协议(UPnP)主要被采用在个人计算机的外围设备中，并且协议的音频视频(AV)扩展允许诸如媒体服务器和媒体播放器的AV设备来确定类似的设备上可以获得什么内容，以及控制设备间所述内容的传输。UpnP被认为是相当“重量级”的协议，可以对主机设备提出相当多的要求，包括处理功率和功率消耗。因此，该协议并不能理想地适用于低(电池)动力装备，所述设备只具有有限的资源和另外将仅要求最小处理能力。诸如欧洲家庭系统(EHS)协议、ZigBee和X10的其它协议每个都已被用来控制家庭用具。家庭网络可能包括各种类别的装备，将不同于具有强大处理能力的个人计算机和媒体播放器，而是仅需要简单开/关指令的简单设备，诸如小用具、恒温器和灯开关。

开放服务网关联盟(OSGi)是开放的，可管理的框架，旨在允许应用(或“服务”)被部署、安装和运行在诸如家庭、小汽车、和小型办公室的本地网络中。本地网络的核心是网关，其支持执行OSGi框架的OSGi服务平台。最新公布的OSGi服务平台规范的版本是2003年3月来自“OSGi联盟”版本3，并且更多的有关OSGi的信息可以在www.osgi.org找到。部分的服务平台规范涵盖了连接至该服务平台的设备的接入。该规范引入了两种类型的实体以实现这些：表示诸如“打印机”、“鼠标”、“灯”等概念的“设备”实体，以及表示诸如“USB”、“串口”等概念的“驱动器”实体。例如为了表示“USB鼠标”，OSGi驱动器选择器实体将选择合适的设备和驱动器，并将这些放在一起。

为了是开放的和可扩展的，OSGi没有定义从应用到这些设备实体的公共接口，也没有在设备和驱动器实体之间定义公共接口。这导致各个公司开发归它们自身所独有的应用编程接口(API)，这降低了该规范的开放性。

图1表示现有的OSGi设备接入规范的简化模型。应用10表示实现特定服务的软件。在这个简单的情况中，应用10控制家庭中的两盏灯20、30，在一天中的特定时间开关它们。需要被控制的第一盏灯20根据欧洲家庭系统(EHS)协议操作。需要被控制的第二盏灯30根据ZigBee协议操作。EHS和ZigBee两者都是现有的用于家庭联网的协议。用于灯20、30各自每一个的基本驱动器22、32发现新的硬件，并向OSGi框架登记对应的“设备服务”25、35。设备服务25、35的每一个是将被控制的实际硬件设备20、30的软件表示。应用10必须知道与之交互的每一个可能的灯设备25、35，且必须知道连接应用10与设备服务25、35的API 26、36的每一个的细节。灯设备的EHS表示25与灯设备的ZigBee表示35有很大不同。因此，即使对于简单应用，应用10变为一种复杂的软件。此外，因为设备服务没有标准化，不同的卖主自由地以不同的方式来表示相同的硬件设备(例如，灯20)，使用不同的驱动器21和设备服务表示25。考虑第二个应用11由不同的卖主提供的例子，但是同样需要开关灯20，第二个应用11的开发者必须也知道API 26的细节或必须提供他们自己的设备以及可以控制灯20的驱动器。

本发明寻求在诸如OSGi框架的本地联网体系结构中提供改进的接口。

因此，本发明的第一个方面是提供在本地网络中用于在控制目标设备中使用的平台，包括支持开放服务网关框架的处理器，其可以执行至少一种应用以控制目标设备，其中目标设备的每一个被表示为可以由应用通过应用编程接口(API)而操纵的实体，所述实体遵循设备类型的公共分层结构，在该分层结构中代表较低层的设备类型的实体继承较高层的设备类型的属性，由此对于应用表现出一致的API。

开放服务网关框架优选地是，尽管没有限制为，开放服务网关联盟(OSGi)框架。

带有一致的分层结构的实体的使用允许应用以简化、但仍强大的方式与目标设备通信。实体构成抽象层的部分，该抽象层从每一个设备特定(device-specific)和网络特定(network-specific)API抽象而来，并且优选地使用公共语言。优选地，分层结构作为诸如家庭统一控制语言(HUCL：Home Uniform Control Language)的轻量级(lightweight)协议被提供。这允许应用的开发者以标准且用户友好的方式访问系统中的每一个设备服务和因此访问目标设备。开发者可以独立地编写应用，具有确定它们可以在OSGi框架中可靠地用于目标设备。此外，在系统上“HUCL驱动器”和“HUCL设备服务”对象之间的接口被标准化，现在在所有的配对中使用公共HUCL接口。这允许简单的应用基于单个设备服务来控制通过不同的联网协议被连接到平台的目标设备。当还在使用现有的服务应用时，使用新的协议，新的目标设备可以被增加。HUCL可以被用作所有的设备服务和桥接驱动器间的公共语言，所述桥接驱动器对接到与目标设备相连的本地联网协议。使用HUCL的其它优点是协议的轻量级特性，对于主机装备提出的要求很低。HUCL可以使用压缩XML消息，提供基本的和扩展的描述，可以降低消息接发开销。HUCL的主要特征在国际专利申请：WO2004/015926、WO2004/015927、WO2004/015928和WO2004/015929中有描述。

HUCL最初是作为用于控制设备的轻量级协议被开发，但是意识到HUCL同样可以为在OSGi网关内的使用提供理想的协议。HUCL和较低级别的基本驱动器一起提供网络独立性(公共语言)和协议独立性(在所述语言中标准化设备命令，包括命令集、参数、功能性等)两者。其它的协议缺乏桥接、支持合成(composite)设备的能力，缺乏由HUCL提供的(provided afforded)支持多于一个层的子设备或开放规范的能力，因而不适合作为抽象层而使用。

应用经由目标设备的“设备服务”通信，所述“设备服务”对目标设备的设备类型是特定的，以类似于OSGi中用于UPnP的方式从HUCL束(Bundle)中获得。这些设备服务可以被视为“帮助者束(helperbundles)”，因为它们向应用提供设备特定Java接口，但是可以使用XML、或压缩XML消息与较低级别驱动器通信。如果目标设备使用例如UpnP、X10或ZigBee等非HUCL的协议，HUCL驱动器(桥接驱动器)将HUCL转换为所述目标设备使用的协议。

两种处理设备服务的主要方法被提出。在第一种方法中，每一个目标设备由向OSGi框架登记的HUCL设备服务表示。设备服务具有遵循目标设备的设备类型的分层结构，以及它们所代表的目标设备的功能性。实现分层结构的一个优选方式是通过使用分层的Java类结构，较低级别的Java类从它们所依赖的较高级别的类继承其属性。然而，如在下面的详述中更充分的描述，还有其它的方式来实现这个分层功能性。在第二种方法中，单个设备服务向OSGi框架登记，且所述设备服务为HUCL合成设备，其有能力表示大量的子设备。每一个子设备都通过标识符被引用，且包括在第一种方法中使用的设备服务的HUCL等价版本，其遵循同样的设备类型的分层结构和功能性。第二种方法具有减少需要由OSGi框架登记和跟踪的实体的数量的益处。

尽管实体或设备服务通常映射至单独的硬件目标设备，但是OSGi规范指出不仅限于此。

该发明应用于任何实现OSGi框架和控制目标设备的平台。其包括家庭网关、机顶盒(set top box)、PC机、个人数字助理(PDA)、媒体网关和其它的消费类电子产品或医学设备。

此处描述的功能性可以由软件、硬件或它们的组合实现。本发明可以由包括若干特定组件(distinct element)的硬件装置，以及通过适合的编程计算机装置实现。因而，本发明的另一方面是提供用于在本地网络中控制目标设备的平台的指令，所述指令使得平台的处理器支持开放服务网关框架，以及执行至少一个应用以控制目标设备，其中每一个目标设备由实体表示，所述实体可以由应用通过应用编程接口API来操纵，所述实体遵循设备类型的公共分层结构，在所述分层结构中代表较低层设备类型的实体继承较高层的设备类型的属性，由此对于应用表现出一致的API。

将被意识到的是，在装备生命期中的任何时间点，软件可以被安装在网关上。软件可以被存储在电子存储设备、硬盘、光盘或其它机器可读的存储介质上。软件可以作为机器可读载体上的计算机程序产品被传递，或者它可以通过网络连接被直接下载到平台上。

本发明更进一方面提供与平台一起使用的实体的库(library)，所述平台支持开放服务网关框架，且可以在本地网络中执行至少一个应用以控制目标设备，每一个实体表示网络中的目标设备，并且由应用通过应用编程接口(API)来操纵，其中所述实体遵循设备类型的公共分层结构，在所述分层结构中代表较低层设备类型的实体继承较高层的设备类型的属性，由此对于应用表现出一致的API。所述库可以寄放在网关或可由平台访问的远程服务器中。

本发明的实施方式将要参考附图，仅以举例的方式加以描述，其中：

图1示出使用传统的OSGi框架控制灯的示例场景；

图2示出OSGi家庭网关(residential gateway)的整个模型；

图3示出根据本发明的一个实施方式的OSGi框架；

图4示出在图3的框架中实现的和图1相同的场景；

图5A和5B示出实现图3的框架的两种方式；

图6A和6B示出当新目标设备加入所述网络时发生的消息流；

图7A和7B示出当现有目标设备从所述网络移除时发生的消息流；

图8A和8B示出当应用控制目标设备时发生的消息流；

图9A和9B示出框架内使用的设备服务分层的例子；

图10示出在目标设备内向应用通知事件的机制；

图11示出可以实现图3框架的平台的例子。

图2示出简化的用于开放服务网关联盟(OSGi)家庭网关的整个模型。服务网关110位于家庭、办公室、汽车或类似的位置中。服务网关110包括支持OSGi框架的服务平台112。在家庭中提供不同的服务的应用130由平台112执行以控制目标设备20-23。应用可以具有各种不同的目的，包括用具的控制，诸如消费类电子产品，大型家用电器(white goods)、供暖系统和通风装置、照明设备等。目标设备20-23可以包括灯20、电子用具21或其它任何的电子设备。网关110使用本地联网协议连接到目标设备20-23。典型的家庭将包括根据某个范围的目标网络协议操作的目标设备，诸如ZigBee、X10、UPnP、EHS、KNX和Echelon。每一个硬件设备的物理网络层可以是无线(例如在ZigBee情况下IEEE 802.15.4、IEEE 802.11或类似)或有线(例如串行总线、以太网电缆连接、电子电缆(X10))的。在图2中，网络40为ZigBee网络，网络45为X10网络。家庭之外的远程服务器50可以与网关110通信。服务可以通过服务器50被传递给网关，或者在某些情况下，服务器50上的应用120可以控制家庭内的目标设备20-23。远程服务器同样可以被用于网络管理以及向网关110提供新服务或更新的服务。

图3示出OSGi网关110的一般体系结构。服务平台112支持OSGi框架，其典型地由网关中处理器执行的软件提供。在网络中控制目标设备的应用也可以在服务器50(应用120)上远程地被执行，或者在服务平台112(应用130)上本地地被执行。根据本发明的实施方式，家庭统一控制语言(HUCL)被用作由服务平台112所支持的OSGi框架中的抽象层。本地网络中存在的每一个目标设备151-153由“设备服务”133表示。这是实际的物理设备151-153以软件形式的表示。完整的设备服务包括下述信息：

-用于与设备交互的基本信息，包括HUCL版本和最低支持的HUCL版本；

-用于识别设备的基本信息，包括：设备类型列表(HUCL设备类型码的列表，每一个标准化地表示特定设备类型，例如，灯)，该设备可以控制的设备类型的类似列表；

-多种扩展数据，例如，设备名称、位置信息串(locationstring)、厂商、型号名称、序列号、UI URL(用户接口URL)；

-向目标设备发送命令、接收响应和事件的功能。

此外，可以表示多个目标设备的合成设备(composite device)包括对其表示的子设备的引用。

与图1中使用的设备25、35不同，设备服务133具有分层结构。如下面将要解释的，这允许应用130以尽可能的大的程度来控制目标设备。诸如灯、电视、冰箱等的目标设备(用具)的类型的每一个都具有标准化的设备服务133。允许应用130与每一个设备服务133通信的API已被很好地定义，且不再在是专有的某种东西。这允许应用130与设备服务133以简单、标准化的方式通信。一种实现分层结构的方式是使用标准化的Java^TM对象集或另一种提供类类型分层的编程语言，尽管其它的方法也可使用。在OSGi框架中运行的应用120、130无需知道它们的目标设备所使用的联网协议的类型(例如，UPnP、ZigBee)，这大大简化了应用。多个应用可以使用同样的设备服务133和API。

HUCL束140连接驱动器141、142、143，向OSGi框架登记设备服务133以及提供诸如HUCL消息接发系统(HUCL Messaging System)的一般的管理特征。用于ZigBee和UPnP的驱动器141、143每一个都表示为单个实体。然而它们可以采用与针对X10的驱动器所示方式同样的方式被分解为基本驱动器163和细化(refinement)驱动器142，所述细化驱动器可以使用基本驱动器163的某些功能。通过允许设备服务133向OSGi框架登记其自身、管理事件预订(subscription)(后面将更全面地描述)、传递HUCL消息给驱动器，以及允许所述驱动器来执行所有的向目标网络所使用的协议的转换，使中央管理实体的职责最小化成为可能。在这种情况下，HUCL束140的主要任务为：

-中央管理——存储版本ID等；

-跟踪驱动器和设备服务(诸如通过使用OSGi框架的相关的预订机制)；

-登记设备服务(用于图5A中的每一个设备服务；图5B中，设备服务可以仅被登记用于合成设备)；

-参与OSGi驱动器定位器(locator)交互(或者和充当低级别基本驱动器的HUCL驱动器的网络交互)；

-管理事件预订(如此使得可以应请求发送事件)；

-使用HUCL通信；

-执行协议转换(在HUCL和目标网络协议之间)；

-编组(marshall)/未编组(unmarshall)来自/去往程序员友好的Java API的HUCL消息串。

驱动器141、142、143在目标网络上管理目标设备，并在OSGi框架中将它们引入作为HUCL设备服务133。这允许设备服务133与驱动器141、142、143通过标准化的HUCL接口通信。驱动器141、142、143可以以Java、本地代码(native code)来编写，或者可以以Java和本地代码混合的形式来编写。当存在目标网络驱动器时，HUCL桥接驱动器转换到标准HUCL API以使得其它的网络也可以使用HUCL。

图4表示与图1相同的实现HUCL抽象层的网关中的场景。灯控制应用130在预定的时刻打开/关闭两盏灯20、30。灯20、30的每一个现在被表示为公共的、一般的具有标准化的API 134的灯设备服务133。应用130可以通过API 134传送指令给灯设备133，以同样的方式进行而不管目标硬件设备是连接到EHS网络的灯20还是连接到ZigBee网络的灯30。HUCL/EHS驱动器144将HUCL层桥接到用于EHS协议的驱动器。类似的，HUCL/ZigBee驱动器141将HUCL层桥接到用于ZigBee协议的驱动器。

图5A和5B表示用于HUCL束140的两个主要选项。第一个，在图5A中，HUCL束140充当基本驱动器以及向OSGi框架登记个别的HUCL设备服务133，每个设备服务表示目标设备20。OSGi框架提供服务储存，即登记的设备服务133的可查询列表。作为一种替换方式，HUCL束(140)可以侦听(listen)由EHS基本驱动器160发现的新设备，并然后将其转换为HUCL设备。在这种情况下，HUCL束140不是基本驱动器而是细化驱动器。在HUCL束140和设备服务之间所有通过接口160的通信都是以API调用的形式进行，诸如SendHUCLMsg()和ReceiveHUCLMsg()。应用130调用HUCL设备服务133上的功能，它直接或间接地与桥接驱动器144通信。HUCL束140跟踪所有现有的桥接驱动器144。

在图5B中，HUCL束140作为HUCL设备服务向OSGi框架登记其自身。在这种情况下，HUCL设备服务是HUCL合成设备146。合成设备146可以表示大量的设备服务147，如果在目标网络上具有大量的目标设备20，合成设备具有使用较少系统资源的优点。作为示例，如果有十个不同的目标设备20，在图5A所示的方案中，需要向OSGi框架登记十个设备服务。相反，在图5B所示的合成设备的方案中，仅需要向OSGi框架登记一个合成设备146。HUCL合成设备的概念在国际专利申请WO 2004/015927中被描述了。由于系统可以更容易地应付大量的目标设备20，这使得系统可伸缩性更好。HUCL束140和应用130之间的API 165(等价于图5A中的API 160)的主要组件是命令SendHUCLMsg()和ReceiveHUCLMsg()。当在这些调用中需要额外的地址信息以识别在每一个消息中标识了HUCL合成设备146的哪一个子设备147，整个消息接发的总量降低了。除了少量的家务管理命令，这是仅有的API 165所需的命令。合成设备146的使用同样可以允许更简单的接口，在网关110和后端(back-end)服务器50之间，或者穿过Java-本地接口(JNI：Java-Native Interface)。根据HUCL协议的特征，如国际专利申请WO 2004/015956中所描述的，应用130可以向合成设备146查询对设备服务的简单描述和扩展描述。

图6A-8B表示在图3的框架中对于三种典型动作的消息流的示例。在每一个例子中，消息流对于个别设备服务被使用的情形(如图5A)以及一般HUCL束和合成设备146在被使用(如图5B)的情形这两种情形示出。为了清楚起见，在这些以及后面的例子中使用了伪代码。为了简单起见，该例子将灯20示为目标设备，但是可以意识到的是目标设备可以更为复杂。

图6A和6B示出当新的目标设备20加入系统时发生的消息流。图6A示出个别设备服务被使用时的消息流。当新设备(灯20)被第一次加入到系统中，其由EHS驱动器160认出，并且在步骤201有总线活动。

驱动器160经由HUCL/EHS驱动器144以下述形式发送消息202到HUCL束140：

eventListener.indicate(

EHSDriver，NEW_DEVICE，<type>)

在步骤203，表示灯的新的设备服务133以名称“myHUCLLamp2”被创建，并且在OSGi框架上调用函数：

Framework.registerNewDevice(myHUCLLamp2)以便登记新的设备服务133。所述函数可以由驱动器144、HUCL束140、或设备服务133其自身所调用。

应用130中的服务跟踪器在步骤204被通知新的设备服务“myHUCLLamp2”。OSGi的服务跟踪器特征在OSGi服务平台规范(版本3第19章)有更为全面的描述。

转而参考步骤201，新的目标设备加入系统采用的准确方式根据目标网络协议的不同而不同，在一些协议中新的目标设备20导致总线上“新设备”事件。在其它协议中，新的目标设备由目标网络中的轮询机制发现。对于X10，没有新设备的指示，必须由用户手动地加入到系统中。日益增加的安全性的需求要求用户加入到交互中。对于WiFi，一旦用户输入用于新目标设备的加密密钥，网关上的低级别驱动器160识别新设备，并且可以请求描述。HUCL/UPnp桥接驱动器143将认出该新设备，所述新设备的识别沿堆栈(stack)向上继续。

图6B示出了一般的HUCL束和合成设备146被使用时的消息流。当新设备(灯20)第一次加入系统时，其由EHS驱动器160认出，并且在步骤211有总线活动。如前，驱动器160经由HUCL/EHS驱动器144以下述形式发送消息212到HUCL束140：

eventListener.indicate(

EHSDriver，NEW_DEVICE，<type>)然而，在这个情况下，新设备被表示为HUCL合成设备146中的子设备。如先前所描述的，为子设备所存储的信息是为服务设备所存储信息的HUCL等价，并且包括在实际设备之上分层中设备类型的列表。作为HUCL束的侦听器被预订的所有应用130发送消息213：

HUCLEvent(“<deviceDescriptionChanged>”)应用130被作为HUCL束140的侦听器被预订。在步骤214应用130中的事件侦听器被通知HUCL束的更新以及发现新增加的子设备。所述新增加的子设备没有明确地向OSGi框架登记。

图7A和7B示出了当已有设备被从系统中移除时发生的消息流。图7A示出了当个别设备服务133被使用时的消息流。当现有设备(灯20)被从系统中移除时，由EHS驱动器160认出并且在步骤221有总线活动。驱动器160经由HUCL/EHS驱动器144以下述形式发送消息222到HUCL束140：

eventListener.indicate(

EHSDriver，GONE_DEVICE，ID)在步骤223，“myHUCLLamp2”设备服务被停止。在步骤224应用130的服务跟踪器被通知设备服务“myHUCLLamp2”的移除。

图7B现在示出了当一般HUCL束被使用时的消息流。当现有设备(灯20)被从系统中移除时，由EHS驱动器160认出并且在步骤231有总线活动。再一次，驱动器160经由HUCL/EHS驱动器144以下述形式发送消息232到HUCL束140：

eventListener.indicate(

EHSDriver，GONE_DEVICE，ID)子设备表示在步骤223灯从HUCL合成设备146被移除。格式为：

HUCLEvent(“<deviceDescriptionChanged>”)的消息被发送给所有的已预订侦听器，通知它们该移除。在步骤234，应用130中的事件侦听器被通知该更新以及发现该已移除的子设备。再次，OSGi框架没有被明确地通知该移除。优选地用户确认设备的移除，诸如通过点击用户界面上的确认图标。

在第三个例子中，图8A和8B示出了当应用130希望控制已向系统登记的设备时发生的消息流。在该例子中，应用130发送控制消息以打开灯20且灯20以名称“myHUCLLamp”向系统登记。图8A示出了当使用个别设备服务133时的消息流。首先，在步骤241应用130以下述形式向HUCL灯设备服务133发送消息：

myHUCLLamp.on()在步骤242，所述灯设备服务133以下述格式发送HUCL消息：

sendHUCLMsg(“…

<param1>255</param1>…”)这由HUCL/EHS驱动器144转换为消息，以下述形式发送243给驱动器160：

EHSDev5.sendEHSMsg(

TURN_ON)该转换可以简单地为消息的普通重组，或者可以涉及通过使用查找表(look-up table)的转换命令。最终，驱动器160以目标网络的格式发送消息244给灯20，以使得灯20打开。

图8B示出了当一般HUCL束140被使用时的消息流。首先，在步骤251应用130以下述形式向HUCL束140发送消息：

sendHUCLMsgAddressedTo(DevID，“…

<param1>255</param1>…”)这被传递给合成设备服务146的特定子设备147，其中‘DevID’是标识表示灯20的HUCL合成设备146的子设备147的标识符。在步骤252，HUCL束140以下述形式发送由HUCL/EHS驱动器144转换为EHS消息的控制消息：

EHSDev5.sendEHSMsg(TURN_ON)该消息被传送给EHS驱动器160。最终，驱动器160以目标网络的格式发送消息253给灯20，以使得灯20打开。

转而参照图5A，通过API 134在应用130和HUCL设备对象之间传送的消息是标准化的，诸如LampOn()、LampOff()、TVOn()、TVOff()、SetChannel(int num)、SetVolumn(int level)。应用130的开发者将被提供这些标准集。

如上所述，HUCL具有设备服务的分层排列。图9示出了设备服务300的示例性分层，一般HUCL设备301在顶部。函数‘getSubDevices()’返回下一层子设备的设备服务，如果存在的话。随分层结构往下，设备服务具有增加的细节/功能性水平。因而，设备服务302表示具有打开/关闭能力的目标设备。随该分层结构左侧往下，设备服务303定义了基本灯，继承了在其之上的类的特征，即也可以打开/关闭。设备服务304定义了可变暗的灯，即具有在可能值的范围内被设置为特定亮度值的功能的灯。设备服务304同样继承其上的302和303的特征，即其为灯且能打开/关闭。随该分层结构右侧往下，设备服务305定义了门铃，继承了HUCL开/关设备302的特征。在这个例子中，如果应用(例如应用130)不知道如何与“HUCLDimmableLamp”类型的设备对话，它仍然可以使用“HUCLBasicDevice”定义甚或基本“HUCLDevice”定义，带有所述设备服务能懂得该功能的确定。有效地，HUCL允许应用“顺分层树而行(walk up the hierarchy tree)”，如果应用发现其不能认出设备类型(例如，可变暗灯)则所述应用检查作为设备服务133的一部分而提供的设备类型列表中所列出的其它设备类型。类似的，由于设备服务表示所有符合该分层的目标设备，具有开/关某物能力的应用可以驱动灯、门铃或任何其它的可以被打开/关闭的设备类型。目标设备被表示在其“最低的”最精确的表示之上的每一个级别。这种方法允许设备以最大范围的可能性被操纵，即使开发者不知道特定设备的所有细节。

图9B示出了分层体系的进一步例子。平台(在此情况下为个人电子助理(PDA)320)支持上述的OSGi框架和控制应用。运行在PDA 320上的应用不能认出可变暗灯304或灯303所使用的特定命令，但是其可以认出用于OnOffDvice(开关设备)的设备类型代码(即，表示可以被打开/关闭的设备的类型的代码)，因而在有用的范围内其能够控制灯，尽管其不能控制灯304可变暗的功能。类似的，运行在PDA 320上的应用只支持“恒温器”308级别的设备服务，且缺乏控制医用或工业恒温器特征的能力。运行在PDA 320上的应用不能使用医用恒温器309或工业恒温器310的先进特征，但是其仍可以打开和关闭恒温器357、358的每一个，且获得基本的温度读数。这使得目标设备的厂商提供在特定级别互操作的产品，但是同样给它们的产品添加能够区别于其它产品的独特特征。在先前参考图5B所描述的合成设备模型中，为合成设备146中每一个子设备147存储的信息遵循同样的分层结构。

如上所述，许多编程语言提供相关功能性。例如，在Java^TM中每一个对象是“类”的实例，且类可以扩展其它的类形成类分层体系。图9A和9B中所示的分层体系可以使用Java或另一个编程语言中对象集的这种类分层体系来实现。可替换地，该分层体系可以以不使用编程语言“内建”的类分层体系的方式被实现。一种不使用编程语言的类分层体系而操作设备分层体系的方法是通过单一固定的类实例表示设备来实现的，该单一固定的类实例或许称为HUCLDevice，其只具有一般的、非设备特有的方法，诸如“sendMessage(commandText)”、“setVariable(variableID，variableValue)”、或“invokeCommand(commandID，commandParameter1，…)”。在这种情况下，所述分层体系书面记录为文档，以软件组件的编程实现，通过为每一个个别调用的响应编码(即，非面向对象代码)或通过非暴露(non-exposed)的API的面向对象的设计(即，使用面向对象的代码但不将其在API中表示)。在每一种情况中，我们可以希望扩展的设备能够对于更简单的设备懂得的所有消息、变量和/或命令调用正确地反应，且同样懂得附加的命令和功能并实现对它的响应。在第二种情况下，设备分层体系仍然存在(在最基本的概念上)并且是有用的，但不是直接地通过使用编程语言的内置类分层体系实现。

作为例子，考虑到基本的支持函数On()和Off()的灯，以及还支持函数Dim()的复杂灯(ComplexLamp)。在非面向对象代码中，我们可以使用开关声明来实现。下面的例子是用于基本灯的HUCLdevice软件伪代码：

　　#include＜lamp.h＞   //包含用于CMD_LAMP_*的#define，且

　　声明函数  On()and Off().

　　invokeCommand(commandID,commandParamList[])

　　{

　　     switch(commandID)

　　      {

　　        case CMD_LAMP_ON:

　　           On();

　　           break;

　　        case CMD_LAMP_OFF;

　　           Off();

　　           break;

　　        default:

　　           UnknownCommand(commandID,commandParamList[]);

　　      }

　　  }

用于复杂灯HUCLDevice的伪代码为：

　　#include＜lamp.h＞      //包含用于CMD_LAMP_*的#define，且

　　声明函数  On()and Off().

　　#include  ＜complexLamp.h＞     //包含用于CMD_COMPLEX_LAMP_*

　　的#define，且声明函数  Dim().

　　invokeCommand(commandID，commandParamList[])

　　{

　　      switch(commandID)

　　      {

　　        case CMD_LAMP_ON:

　　          On();

　　          break;

　　       case CMD_LAMP_OFF:

　　          Off();

　　          break;

　　       case CMD_COMPLEX_LAMP_DIM:

　　          Dim(commandParamList[0]);

　　          break;

　　       default:

　　          UnknownCommand(commandID,commandParamList[]);

　　    }

　　}

此处用于“ComplexLamp(复杂灯)”的代码实现“lamp(灯)”所有的功能，并且附加的命令也在ComplexLamp(复杂灯)的规范中定义。两个程序都实现了函数On()、Off()和UnknownCommand(…)，且ComplexLamp(复杂灯)将额外实现函数Dim(dimLevel)。这个例子不使用编程语言的类分层体系来实现设备分层体系。还可能以第二种方式来实现该分层体系，但是带有一些面向对象编程特征。用于复杂灯的HUCLdevice(HUCL设备)软件的伪代码例子为：

　　#include＜lamp.h＞    //包含用于CMD_LAMP_*的#define，

　　且声明Lamp类.

　　#include  ＜complexLamp.h＞//包含用于CMD_COMPLEX_LAMP_*

　　的#define，且声明扩展Lamp类的ComplexLamp类.

　　invokeCommand(commandID,commandParamList[])

　　{

　　    ComplexLamp myComplexLamp=environment.getTargetDevice();

　　    switch(commandID)

　　    {

　　      case CMD_LAMP_ON:

　　            myComplexLamp.On();

　　            break;

　　      case CMD_LAMP_OFF:

　　            myComplexLamp.Off();

　　            break;

　　      case CMD_COMPLEX_LAMP_DIM:

　　            myComplexLamp.Dim(commandParamList[0]);

　　            break;

　　     default:

　　            UnknownCommand(commandID,commandParamList[]);

　　   }  

　　}

此处引入应用的API与前面例子的相同，且仍没有直接使用编程语言的类分层体系。然而在这个例子中ComplexLamp和Lamp类在用于复杂灯的伪代码中被使用，以使得软件更清楚，或者说更易维护。

目标设备以向开发者隐藏任何低级别HUCL代码的方式被控制。在图5A的模型中，设备服务类它们自身负责将高级别的方法调用(例如，LampOn()、SetChannel(int num))转换为低级别的HUCL代码，在图5B中包装(wrapper)函数可能被使用。包装函数执行开发者友好的、高级别的Java命令到低级别的HUCL代码的转换。

在图8A和图8B中示出了应用130如何可以发送控制消息以控制目标设备20。在应用130已知的时间，应用被请求打开/关闭目标设备则可以发生这个。然而，存在希望应用响应发生在目标设备上的特定事件的情况。例如，当运动传感器形式的目标设备检测房间中的运动时，期望通知运行在网关110上的安全应用，以使得所述应用可以警告用户。现有的OSGi框架不能提供支持这种类型通知的机制。

图10示出了用于向应用告警事件的简单机制。在最低级别，驱动器160在诸如每两秒钟的周期的基础上轮询目标设备20。如果所述目标设备20的状态存在变化，驱动器160通知设备服务133。这可能从驱动器的API来检测状态的任何变化。这可以依靠从驱动器160向HUCL束140的方法调用来完成，或者依靠HUCL束140轮询驱动器160以观测其状态来完成。HUCL束140将从驱动器160得到的信息组成HUCL事件消息。这些事件然后被传送到设备服务133，由该设备服务将所述事件用Java事件对象的形式表述。应用130预订它们所控制的，或者它们对被通知其状态感兴趣的那些设备束。每一个设备服务133保持侦听预订列表180，该列表列出了那些登记了兴趣的应用(例如，将每一个如它所登记的那样加到java.util.Vector)。应用130的每一个包括用于接收事件的通知的事件侦听器182。所述由驱动器160发送的指示灯的新状态的消息由设备服务133接收。设备服务133决定183可报告的事件是否发生，如果有，则通知所有登记180的感兴趣的应用。

使用该机制的例子现在将对于是可变暗灯的目标设备来描述。根据图9A所示的分层体系，可变暗灯设备304扩展了HUCL基本灯设备303和开关设备302的功能。因此优选地所述事件分层体系镜像了该对象的分层体系。这意味着预订了可变暗灯设备服务的应用也接收任何的开/关事件通知。对于更复杂的目标设备，其表示为继承了许多更高级别类的事件的设备服务，应用将接收该设备服务继承的所有的事件的通知。与分层设备服务结构一样，这为应用开发者提供了简单但强大的工具。附录包括了用于实现该例中事件分层体系的代码的更多细节。

如上所述，HUCL管理实体负责登记驱动器和设备服务。OSGi框架提供用于向任何感兴趣的束通知任何新设备服务到达系统的机制。通过在系统中提供HUCL管理束可以侦听任何新设备服务的到达，并且如果它们表示HUCL设备则将它们添加到设备服务的集合(collection)中。该束然后向有兴趣使用这些设备服务的任何其它束提供对该集合的访问。

　　HUCLDevice[]devices=huclBundle.getDevices();

　　for(int a=0;a＜devices.length;a++){

　　 If(devices[a]instanceof HUCLLamp){

　　  HUCLLamp lamp=(HUCLLamp)devices[a];

　　  lamp.turnOn();

　　 }else if(devices[a]instanceof HUCLDoorbell){

　　  HUCLDoorbell bell=(HUCLDoorbell)devices[a];

　　  bell.activate();

　　 }

　　}

上述代码片断显示了对使用这些设备服务感兴趣的束如何能随后获得来自HUCL管理束的所有设备服务的列表。设备服务可以为它们实现的HUCL设备接口所查询，并可以被相应地使用。该代码是开发者如何使用多态性(polymorphism)来发现他是否对设备感兴趣的实例说明。在这个例子中，开发者对HUCLLamp(HUCL灯)和HUCLDoorbell(HUCL门铃)感兴趣。操作符“instanceof”被用来查看当前HUCLDevice(HUCL设备)是否是感兴趣设备“的实例”。如果是，HUCLDevice(HUCL设备)被分派到已发现的设备类。分派对象现在可以用来控制该设备。

上述的网关可以在多种处理平台上实现，诸如通用PC或专用处理单元。图11示出了处理平台的主要组件。如前所述，中央处理单元401执行软件以支持OSGi框架、应用以及HUCL抽象层。典型的，中央处理单元401具有本地的操作系统(例如，基于Linux)，其支持Java虚拟机(JVM)。该JVM驻留(host)OSGi框架和应用。非易失性存储器402和诸如硬盘之类易失性存储器403存储操作软件和设备服务的库(libraries)，且被处理单元401使用。诸如宽带ADSL或电缆调制解调器的调制解调器406连接到通信线路407，该通信线路407将网关连接到应用也可以在其上被支持的远程服务器(50，图2)。宽带调制解调器406可以在网关110的外部。由使用有线412和无线411技术组合的本地网络连接415携带去往/来自被控制的设备的控制消息。适当硬件可以被提供以支持特定本地网络，例如局域网卡、无线、红外或电力线(X10)调制解调器的。用户输入可以通过诸如键区、键盘、鼠标或写字板的输入设备410被直接提供给网关。可替换地，用户输入可以从与网关110本地联网的远程控制单元被接收，或从通信链路407被接收。作为例子，如果用户离家在外且希望发送指令给网关以控制家中的用具，用户将与远程终端交互并通过线路407发送指令给网关110。输出可以通过显示驱动器408和显示器409直接呈现给用户，通过链路407呈现给本地远程控制单元或远程终端。总线405或不同类型总线的组合连接上述单元。

各种各样的应用130可以在网关110或远程服务器50上被执行。这些例子包括：家庭控制，诸如通过在预定时间打开和关闭灯模拟建筑物有人(occupancy of a building)、控制供暖系统和通风装置、录像机编程、控制娱乐和消费类电子设备；远程监控建筑物的安全或屋主的健康；远程错误报告/诊断。

应当注意的是上面提及的实施方式示出了但不是限定了本发明，且本领技术人员可以不脱离所附的权利要求的保护范围作出多种可替换实施方式。在权利要求书中，任何放于圆括号内的附图标记不能解释为对权利要求的限定。词语“包含”和“包括”不排除在权利要求中列出的部件或步骤之外的其它部件或步骤的存在。

在上面的描述中，以及参考附图，描述了包括处理平台(110)和诸如家庭用具的目标设备(151-153)的本地联网系统。所述平台支持诸如开放服务网关联盟(OSGi)的开放服务网关框架，执行应用(130)以控制目标设备(151-153)。目标设备每一个都由实体(133)表示，该实体可以由应用(130)通过应用编程接口(API，134)来操纵。实体遵循设备类型的公共分层结构，在所述分层结构中代表较低层设备类型的实体继承较高层设备类型的属性。这对于应用表现出一致的API。所述实体可以构成使用诸如家庭统一控制语言(HUCL)的公共语言的抽象层的部分。每一个实体可以作为设备服务向框架登记，或者表示多个实体的单个设备服务可以向框架登记。

附录

用于事件报告特征的进一步解释材料。

基本事件类可以是：

　　public class OnOffDeviceEvent extends java.util.EventObject{

　　/*通过getEventTrigger()使用，指示设备开(ON)事件*/

　　 stat ic int DEVICE_ON；

　　/*通过getEventTrigger()使用，指示设备关(OFF)事件*/

　　 static int DEVICE_OFF；

　　/*返回事件常量之一，解释是什么触发了该事件*/

　　 public int getEventTrigger()；

　　/*创建新的开关设备事件(OnOffDeviceEvent)*/

　　 public OnOffDeviceEvent(int trigger)；

　　}

将向预订的应用通知可变暗灯设备上事件的可变暗灯事件(DimmableLampEvent)可以通过下面的类来定义：

public class DimmableLampEvent extends OnOffDeviceEvent{

static int BRIGHTNESS_CHANGED；

/*覆盖开关设备事件(OnOffDeviceEvent)*/

public int getEventTrigger()；

public DimmableLampEvent(int trigger)；

}

应用通过实现适当的事件侦听者接口来登记它们对这些事件的兴趣。这种用于开关设备(OnOffDevice)的接口的示例是：

public interface OnOffDeviceListener extends EventListener{

public void onOffDeviceEventOccurred(OnOffDeviceEvent e)；

}

Claims

1.一种用于在本地网络中使用以控制目标设备(151-153)的平台(110)，包括支持开放服务网关框架的处理器(401)，其可以执行至少一个应用(130)以控制目标设备，其中目标设备(151-153)中的每一个由应用可以通过应用编程接口(API)操纵的实体(133)来代表，所述实体(133)遵循设备类型的公共分层结构，在所述分层结构中代表较低层设备类型的实体(133)继承较高层设备类型的属性，由此对于应用(130)表现出一致的API。

2.根据权利要求1的平台，其中，实体(130)构成使用公共语言的设备抽象层的一部分。

3.根据权利要求2的平台，其中，抽象层进一步包括桥接驱动器(141-143)，所述桥接驱动器在公用语言和用来与目标设备(151-153)对接的协议之间转换消息。

4.根据权利要求2或3的平台，其中，公共语言为家庭统一控制语言(HUCL)。

5.根据前面任何一个权利要求的平台，其中，代表目标设备的实体(133)作为设备服务向框架登记。

6.根据前面任何一个权利要求的平台，其中，能够代表多个目标设备的设备服务(146)向框架登记，每个目标设备由设备服务中的个别实体代表。

7.根据权利要求6的平台，其中，设备服务包括HUCL合成设备(146)，每个目标设备通过是合成设备(146)中子设备(147)的实体来代表。

8.根据权利要求6或7的平台，其中，设备服务和应用之间的API(165)包括发送消息给设备服务的命令和从设备服务接收消息的命令。

9.根据权利要求6至8之一的平台，其中，在应用(130)中提供包装函数(162)以便将高级别的命令转换为通过API(165)使用的低级别的消息。

10.根据前面任何一个权利要求的平台，其中，如果应用(130)确定其在设备类型分层体系中的特定级别不能够控制目标设备，则在该分层体系中查找其能够控制目标设备的的较低级别。

11.根据权利要求10的平台，其中，实体(133)包括其属性已被继承的较高层设备类型的列表。

12.根据权利要求10的平台，其中，应用(130)通过使用设备类型的分层体系的知识来确定该分层体系中其能够控制目标设备的较低级别。

13.根据前面任何一个权利要求的平台，其中，实体(133)被安排向应用通知目标设备上发生的事件。

14.根据权利要求13的平台，其中，实体(133)维护希望被通知事件发生的应用(130)的列表，且当事件发生时通知那些应用。

15.根据权利要求13或14的平台，其中，实体(133)具有事件通知的一致的分层结构，其中实体继承了该结构的更高成员的事件。

16.根据前面任何一个权利要求的平台，以家庭网关的形式出现。

17.根据权利要求16的家庭网关，可连接至通信链路以便与远程服务器(50)通信，其中在网关处支持的框架提供到远程服务器执行的应用(120)的接口。

18.一种用于平台(110)在本地网络中控制目标设备(151-153)的指令，所述指令使得平台的处理器支持开放服务网关框架，执行至少一个应用(130)以控制目标设备，其中每个目标设备(151-153)由应用(130)可以通过应用编程接口(API)操纵的实体(133)来代表，所述实体(133)遵循设备类型的公共分层结构，在所述分层结构中代表较低层设备类型的实体(133)继承较高层设备类型的属性，由此对于应用表现出一致的API。

19.根据权利要求18的指令，其中，实体构成使用公共语言的设备抽象层的一部分。

20.根据权利要求19的指令，其中，抽象层进一步包括桥接驱动器(141-143)，所述桥接驱动器在公用语言和用来与目标设备(151-153)对接的协议之间转换消息，该协议被用作接口。

21.根据权利要求19或20的指令，其中，公共语言为家庭统一控制语言(HUCL)。

22.根据权利要求18至21任一个的指令，其中，代表目标设备的实体(133)作为设备服务向框架登记。

23.根据权利要求18至22任一个的指令，其中，能够代表多个目标设备的设备服务(146)向框架登记，每个目标设备由设备服务中的个别实体(147)来代表。

24.根据权利要求23的指令，其中，设备服务包括HUCL合成设备(146)，每个目标设备通过是合成设备中子设备(147)的实体来代表。

25.根据权利要求23或24的指令，其中，设备服务和应用之间的API(165)包括发送消息给设备服务的命令和从设备服务接收消息的命令。

26.根据权利要求23至25任一个的指令，其中，在应用(130)提供包装函数(162)以将高级别的命令转换为通过API(165)使用的低级别的消息。

27.根据权利要求18至26任一个的指令，其中，如果应用确定其在设备类型的分层体系的特定级别不能够控制目标设备，则在该分层体系中查找其能够控制目标设备的的较低级别。

28.根据权利要求27的指令，其中，实体包括其属性已经被继承的较高层设备类型的列表。

29.根据权利要求27的指令，其中，应用通过使用设备类型的分层体系的知识来确定该分层体系中其能够控制的目标设备的较低级别。

30.根据权利要求18至29任一个的指令，其中，设备服务被安排向应用通知目标设备上发生的事件。

31.根据权利要求30的指令，其中，实体维护希望被通知事件发生的应用的列表，且当事件发生时通知这些应用。

32.根据权利要求30或31的指令，其中，实体具有事件通知的一致的分层结构，其中该实体基继承该结构中更高成员的事件。

33.一种计算机程序产品，包括携带有根据权利要求18-32任一的指令的机器可读介质。

34.一种用于与平台一起使用的实体(133)的库，所述平台支持开放服务网关框架，执行至少一个应用以控制本地网络中的目标设备，其中每个实体代表该网络中的目标设备并且可以由应用通过应用编程接口(API)来操纵，所述实体遵循设备类型的公共分层结构，在所述分层结构代表较低层设备类型的实体继承较高层的设备类型的属性，由此对于应用表现出一致的API。

35.一种根据前述任一权利要求的平台、指令、计算机程序产品或实体库，其中，开放服务网关框架为开放服务网关联盟(OSGi)框架。