CN102790708A

CN102790708A - 一种应用于家庭网络的设备服务适配方法

Info

Publication number: CN102790708A
Application number: CN2012102810752A
Authority: CN
Inventors: 王晓东; 许晓伟; 陶冶; 丁香乾
Original assignee: Ocean University of China
Current assignee: Ocean University of China
Priority date: 2012-08-08
Filing date: 2012-08-08
Publication date: 2012-11-21

Abstract

本发明提出一种应用于家庭网络的设备服务适配方法，通过在资源受限设备所属的私有协议网络内部署设备服务代理，实现间接的设备Web服务化，从而解决家庭异构私有协议网络设备之间的互联互通和信息共享问题。通过该服务适配方法，可将私有协议网络内的一组资源受限设备抽象为对外提供标准的Web服务的虚拟设备，进而将对组内受限设备的专属操作，转换为基于Web服务技术的标准操作，为面向家庭物联网络的服务集成和应用开发提供一种便捷方式。

Description

一种应用于家庭网络的设备服务适配方法

技术领域

本发明属于网络通信设备领域，具体地讲涉及一种家庭设备服务适配方法。

背景技术

伴随着数字家庭产业的发展，越来越多的嵌入式家电设备和传感器网络设备在家庭空间内部署，以逐步满足人们对家庭生活自动化和智能化的需求。这些数字家庭设备按照自身的软硬件资源能力划分一般可以分为两大类：一类是丰富资源设备，主要包括个人电脑、智能移动通信终端和 PDA等；另一类是资源受限设备，主要包括白色家电、无线传感器网络设备以及随物联网发展而大量应用的 RFID读写设备和标签。

取决于不同的应用需求和软硬件环境，数字家庭内一般存在多个异构的网络，各网络内的设备基于有线或无线的方式进行连接，如高速多媒体网络、低速控制网络、传感器网络和电力线载波网络等。这些网络一般采用不同的私有通信协议和硬件接口规范构建，这些网络一般称之为私有协议网络。网络协议和接口的异构性，使得实现不同私有网络之间的互联和信息共享成为数字家庭技术领域一个亟待解决的问题。从目前家庭网络的总体状况来看，这些私有协议网络就像一个个“孤岛”，彼此之间基本是隔离的。

另外，为解决设备底层软件平台的异质性带来的设备交互困难的问题，各大数字家电厂商和开放标准联盟相继成立并推出各种数字家庭网络应用层协议标准规范（如 DLNA/UPnP、IGRS、ITopHome等）和制定数字家庭网络应用开发的中间件平台规范（如 OSGi、Jini等），这些工作为基于同类协议或中间件平台的应用开发带来了一定的便利性，但同时又产生了新的问题，即应用层协议和中间件平台的异构性使得不同设备之间实现资源共享依然存在较大难度。再次，即使不同厂商的设备基于同样的应用层协议或中间件平台进行开发，但由于缺乏统一的操作接口定义和标准的数据表示方式，设备之间的资源共享和互操作依然存在困难。

Web服务技术是用于解决异构组件的集成，提高软件架构灵活性的先进技术。面向服务的架构（Service Oriented Architecture, SOA）及 Web服务技术，由于其开放性、松耦合和跨平台的特性，在众多领域已经具有广泛的应用，如企业业务集成、电子商务等。面向服务的设备架构（SODA）基于 SOA的设计理念，利用 Web服务技术将设备实体的功能封装为服务对象，从而实现物理设备的 Web服务化，为设备功能的集成应用带来了便利。 DPWS是目前较为先进的资源受限 Web服务协议栈规范，它有效利用了核心的 Web服务标准（如 WS-Addressing、WS-Discovery、WS-Policy等），在嵌入式设备上实现一个可以运行 Web服务的中间件平台，使嵌入式设备兼容了主流的 Internet协议和标准，有利于实现嵌入式设备服务的集成应用。从这些技术出发，类比数字家庭网络的设备集成方案可以得出，基于 Web服务和 SOA技术整合家庭网络架构，实现家庭网络内设备和服务资源的无缝集成是一种行之有效的方法。

在资源受限设备上部署 Web服务基础架构是复杂和昂贵的，即使是针对专门面向嵌入式设备应用而开发的 DPWS框架来说。这里的复杂性是指，运行 Web服务协议栈需要复杂的软件环境支持，例如嵌入式操作***的部署（如嵌入式 Linux和 Windows CE），完善的基础网络协议栈（如 TCP/IP协议栈），完整的应用层协议支持（如 HTTP和 SOAP协议），对 XML描述语言的解析能力（如 WSDL和 SOAP解释），高效的应用软件运行能力（支持各种运行时库或虚拟机）等。而满足上述软件条件的底层硬件是“昂贵”的，这里的昂贵性主要包括两个方面：一方面是由于软件架构的复杂度带来的更高硬件载体复杂度，并需要更丰富的硬件资源来运行复杂的软件，这是硬件资源开销的昂贵；另一个方面，硬件资源开销的增加必然导致硬件成本的上涨，硬件复杂度的增加同时又导致可靠性的降低和设备后期维护的成本。举例来说，在一个功能单一的家用电器（如电热水器和空调）上配置一颗高性能 CPU和***组件来解决嵌入式设备 Web服务应用目前来看是不可取的。虽然，随着硬件的成本的降低，这种共识可能会逐渐发生改变。但在目前，硬件成本的控制和保持更高的产品可靠性依然是各个家电制造厂商着重考虑的问题。硬件成本的控制是建立在解决特定问题使用“够用的”器件之上，而可靠性的保证在很大程度上取决于对软硬件复杂度的控制。另外，随着“物联网”概念的兴起和射频通信技术的成熟，越来越多的传感器和 RFID装置（包括读写器和标签）被广泛的应用于家庭环境监测、人体健康监控以及物品身份标识等领域。由于这类设备大量采用板载电池供电，对能耗和有效工作时间具有很高的要求，结构复杂和高耗能的硬件是不宜采用的。所以，在未来较长的一段时间内，大量的资源受限设备（包括家电设备和“物联网”设备等）均不适合采用复杂的软硬件来支撑在其上直接部署 Web服务应用。

发明内容

本发明针对当前家庭网络异构性强、设备资源受限的情况，提出一种新型的家庭设备服务适配方法，其采用的技术方案如下：

一种应用于家庭网络的设备服务适配方法，其特征在于包括如下：

A、在资源受限设备所属的私有协议网络内部署设备服务代理，该设备服务代理将私有协议网络内的一组资源受限设备抽象为对外提供标准的 Web服务的虚拟设备；

B、构造应用于设备服务代理的设备驱动架构，用于定义设备服务代理与私有协议设备进行通信和交互的细节；

C、利用Web服务技术标准集成异构的家庭网络，实现家庭设备之间基于Web服务的资源共享和互操作模式。

如上所述的设备服务适配方法，所述设备服务代理包括以下四个核心组件：私有协议接口组件，该组件为设备服务代理的上层组件屏蔽底层私有网络协议的异质性；设备注册组件，该组件用于存储私有协议网络设备的相关配置信息，并管理当前在线的私有协议网络设备驱动的动态加载过程；驱动解析组件，该组件用于将基于驱动过程语言实现的设备驱动解析为针对特定私有协议设备的控制指令，用于实现该设备的控制；服务代理组件，该组件用于将设备服务代理对外暴露为一个提供标准Web服务的虚拟设备，并处理来自家庭服务中间件或外部设备/应用的服务调用请求和进行服务响应。

如上所述的设备服务适配方法，所述设备驱动架构包括三层模板机制驱动架构：位于最上层的抽象设备模板，由驱动解析器实现模板解析和有效性验证；位于中间层的标准设备模板，由设备驱动架构提供给设备制造商用于灵活方便的编写设备外部驱动；位于最底层的特定设备驱动，由设备制造商提交给设备服务代理用于支持代理和设备之间的互操作。

如上所述的设备服务适配方法，所述特定设备驱动由设备制造商在标准设备模板的基础上扩展其特定设备的描述细节和驱动细节来构造，扩展的内容包括以下两部分：扩展设备相关描述信息和扩展特定设备驱动。

如上所述的设备服务适配方法，所述设备服务代理各组件之间的通信采用基于事件的异步通知机制实现。

如上所述的设备服务适配方法，所述设备服务代理或分布部署在多个设备上，或集成在同一设备内部。

如上所述的设备服务适配方法，所述配置信息包括：由设备制造商提供的设备驱动；由下层私有协议接口组件提供的设备动态状态信息。

如上所述的设备服务适配方法，所述细节包括操作定义、消息定义和变量定义。

与现有技术相比，本发明的优点与积极效果如下：

本专利将服务计算技术应用于数字家庭网络，通过提出一种新型的适配方式，把设备的功能抽象为 Web服务，从而可以利用 Web服务相关的技术标准集成异构的数字家庭网络，实现家庭设备之间基于 Web服务的资源共享和互操作模式。该设备服务适配方式具有以下几项明显的优势：

1、基于Web服务，标准化了家庭设备的功能描述，统一了不同厂商、品牌的同类型设备的用户接口，极大方便了设备服务的集成化应用。

2、向家庭设备制造商提供了一种无依赖、易用的设备驱动方式，各厂商无需修改原有家电设备的驱动程序和交互方式，只需将原有设备接入网络模块，并将设备的控制指令基于本专利服务适配方式中设计的驱动过程语言进行再描述，即可支持设备服务的网络化操作。

3、该适配方式基于XML方式描述设备服务和设备驱动，实现了组网协议和硬件平台的无关性，为数字家庭网络内设备服务的集成化、智能化应用模式提供了一种低成本的标准化组网和交互方案。

结合附图阅读本发明的具体实施方式后，本发明的其他特点和优点将变得更加清楚。

附图说明

图1 为基于本发明设备服务代理的家庭网络架构；

图2 为本发明设备服务代理架构；

图3 为本发明三层设备驱动架构。

具体实施方式

下面结合附图和具体实施方式对本发明作进一步详细的说明。

针对当前数字家庭网络服务技术现状，本发明采用一种新型的服务适配方式，通过在资源受限设备所属的私有协议网络内部署设备服务代理，实现间接的设备 Web服务化，从而解决家庭异构私有协议网络设备之间的互联互通和信息共享问题。通过该服务适配方法，可将私有协议网络内的一组资源受限设备抽象为对外提供标准的 Web服务的虚拟设备，进而将对组内受限设备的专属操作，转换为基于 Web服务技术的标准操作，为面向家庭物联网络的服务集成和应用开发提供一种便捷方式。

在本专利设计的设备服务代理架构的支撑下，家庭网络环境将重组为如图1所示图的模式，从而实现了用户随时随地对数字家庭设备服务的访问和控制。

如下从设备服务代理，设备驱动架构以及驱动过程语言对本发明予以详细介绍。

1、设备服务代理

设备服务代理是基于服务计算的理念设计的设备服务适配中间件，用于将私有协议网络内的一组物理设备抽象为对外提供标准Web服务的虚拟设备。设备服务代理的架构设计如图2所示。

家庭内部可能存在多种私有协议网络，所以可以有服务于不同私有协议网络的多个设备服务代理同时存在。这些代理既可以分布部署在多个设备上（如机顶盒设备或移动终端），也可以集成在同一设备内部（如家庭服务网关）。

设备服务代理包含以下四个核心组件：

私有协议接口组件：私有协议接口作为协议适配器，其功能是为设备服务代理的上层组件屏蔽底层私有网络协议的异质性。而在私有协议网络内，接口组件会将自身暴露为与其它设备同类的私有协议设备。举例来说，面向ZigBee（IEEE 802.15.4）网络的设备服务代理，其私有协议接口必须支持ZigBee协议，并将自身配置为一个 ZigBee网络的节点设备，使其在该私有协议网络内可以被其它的节点所发现，从而实现与其它节点的交互通信。私有协议接口的任务是将服务代理组件发送的消息转发至私有协议网络内对应的节点设备，监听设备响应并将其反馈至服务代理组件。另外，私有协议接口还负责跟踪私有协议网络内设备的地址及在线状态信息的变化并将其转发至上层设备注册器模块进行存储。

设备注册组件：设备注册组件用于存储私有协议网络设备的相关配置信息，这些信息包括：由设备制造商提供的设备驱动；由下层私有协议接口组件提供的设备动态状态信息。设备注册组件管理当前在线的私有协议网络设备驱动的动态加载过程，并能够在设备制造商发布新的设备驱动时进行在线自动更新。

驱动解析组件：驱动解析组件用于将基于驱动过程语言（DPL）实现的设备驱动解析为针对特定私有协议设备的控制指令，从而构建该设备的控制流。驱动解析组件从设备注册组件中获取当前激活的设备驱动程序，将其实时解析为该设备的控制指令集，提供给服务代理组件，用于实现对实际私有协议设备的控制。

服务代理组件：服务代理组件用于将设备服务代理对外暴露为一个提供标准Web服务的虚拟设备，并处理来自家庭服务中间件（或外部设备/应用）的服务调用请求和进行服务响应。换句话说，服务代理实现了设备物理空间到Web服务信息空间的映射。服务代理包含子模块动态WSDL生成器，该模块可以基于当前私有协议网络内设备的离在线及使用状况，动态生成虚拟设备Web服务描述，此Web服务描述通过服务代理组件实现对一组在线私有协议网络设备功能服务的集成发布。

设备服务代理各组件之间的通信采用基于事件的异步通知机制实现。设备注册组件订阅私有协议接口组件的网络状态事件，当一个设备加入或离开私有协议网络时，私有协议接口组件会通知设备注册组件，从而进行信息库内相应设备动态信息的维护。类似的，服务代理组件会订阅设备注册组件的设备活动事件，从而根据当前代理网络内的全局设备信息进行虚拟设备描述文件的动态重构和向服务中间件发布通知消息。

2、设备驱动架构

如上所述，用于集成私有协议网络内一组设备功能服务的设备服务代理，需要基于一种预定义的模板机制来封装一系列的设备操作，从而实现与这类私有协议设备的交互，并驱动设备以进行特定的功能调用。本专利设计了设备服务代理所使用模板机制设备驱动架构（DDA），该架构用于定义与私有协议设备进行通信和交互的细节，包括操作定义、消息定义和变量定义等。在此架构支持下，设备开发商可以灵活的发布其设备驱动。设备驱动架构设计包含以下特性：

兼容性，基于设备驱动架构，设备制造商不需要重构其设备的内部软件，依然保留设备原有的控制命令和操作模式即可实现设备功能的服务化。但对于某些非网络化的家电设备（如传统空调、电冰箱等），必须首先通过安装特定的网络通信模块（如ZigBee模块）来实现设备的网络化。

跨平台，设备驱动架构是平台无关的，它保证了设备制造商实现特定设备驱动的跨平台一致性，而由设备服务代理的驱动解析组件屏蔽底层软硬件平台的异构性。

标准化，为确保对同类家电设备操作语义的一致性，设备制造商按照由设备驱动架构定制的标准化设备模板发布其设备驱动。

描述性，通过解析由设备制造商提供的设备驱动描述，设备服务代理能够生成控制设备的实际操作指令，并生成针对此设备功能服务的描述性片段，此片断扩展自WSDL描述。设备驱动的编写基于专利设计的驱动过程语言，此驱动语言同样遵循基于XML的描述性语言规范。

基于上述设计理念，如图3所示，设备驱动架构实现了三层的设备模板机制：最上层为抽象设备模板（ADT），由驱动解析器实现模板解析和有效性验证；中间层为标准设备模板（SDT），由设备驱动架构提供给设备制造商用于灵活方便的编写设备外部驱动；最底层为特定设备驱动（SDD），由设备制造商提交给设备服务代理用于支持代理和设备之间的互操作，分别描述如下。

抽象设备模板：抽象设备模板是三层设备驱动架构的基础模板，所有特定类型设备的标准设备模板均派生自抽象设备模板。抽象设备模板仅定义用于描述设备的接口，并没有填充关于设备的任何实际信息。模板的核心组成元素在WSDL核心元素的基础上扩展得到，这些元素从属于两个主要的命名空间（wsdl和 ddt），分别用于扩展实现私有协议设备服务的功能服务描述部分和设备驱动描述部分。抽象设备模板片段如下：

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://www.d-live.com.cn/ddt"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:ddt="http://www.d-live.com.cn/ddt">

<xs:import namespace="http://schemas.xmlsoap.org/wsdl/" schemaLocation="wsdl.xsd"/>

<xs:import namespace="http://www.w3.org/2001/XMLSchema" schemaLocation="xs.xsd"/>

<xs:element name="driverdef">

<xs:complexType>

<xs:all>

<xs:element ref="ddt:device"/>

<xs:element ref="wsdl:types"/>

<xs:element ref="wsdl:message"/>

<xs:element ref="wsdl:portType"/>

<xs:element ref="ddt:actions"/>

</xs:all>

</xs:complexType>

</xs:element>

<xs:element name="device">

<xs:complexType>

<xs:all>

<xs:element ref="ddt:deviceType"/>

<xs:element ref="ddt:modelName"/>

<xs:element ref="ddt:manufacturer"/>

</xs:all>

</xs:complexType>

</xs:element>

<xs:element name="deviceType">

<xs:complexType>

<xs:attribute name="name" use="required" type="xs:string"/>

</xs:complexType>

</xs:element>

... ...

<xs:element name="actions">

<xs:complexType>

<xs:all>

<xs:element ref="ddt:action"/>

</xs:all>

</xs:complexType>

</xs:element>

<xs:element name="action">

<xs:complexType>

<xs:attribute name="name" use="required" type="xs:string"/>

</xs:complexType>

</xs:element>

</xs:schema>

标准设备模板：标准设备模板派生自抽象设备模板，用于给出正式的设备服务定义。设备驱动架构维护了一个标准设备模板库，其中每个标准设备模板对应于一种标准设备类型，如空调类、湿度传感器类等。设计标准设备模板的目的是采用形式化的描述语言，预先定义一个标准设备类所必备或可选的服务操作类型，而此类设备的实际服务描述必须要实现这些必备的服务操作类型。采用标准设备模板是受限于当前语义标准和解析技术的发展，共享设备所提供服务的最直接和最有效的一种方式。

另外，使用标准设备模板一个显著的优势是可以大大提高构建特定设备驱动描述的效率。基于标准设备模板可以开发可视化的驱动配置工具，设备制造商可以通过简单的添加、重写某些参数值或填充某些空白区域即可以灵活方便的构建特定设备驱动。

在一个标准设备类的设备模板中定义了一些必备的信息，主要包括：标准设备类型、标准设备操作、标准参数类型、标准消息类型和一系列简单/复杂变量类型，这些信息用于在运行时表示设备各种属性和状态。以空调类型设备为例，其标准设备模板片段如下：

<ddt:device>

<xsd:deviceType name="air-conditioner" />

</ddt:device>

<wsdl:types>

<ddt:complexType name="powerType" />

<ddt:complexType name="temperatureType" />

</wsdl:types>

<wsdl:message name="setPowerReq">

<wsdl:part name="power" type="powerType" />

</wsdl:message>

<wsdl:portType>

<wsdl:operation name="setPower">

<wsdl:input message="setPowerReq" />

</wsdl:operation>

<wsdl:operation name="getMeasuredTemperature">

<wsdl:output message="getMeasuredTemperatureResp" />

</wsdl:operation>

</wsdl:portType>

<ddt:actions />

设备驱动架构维护一个标准设备模板库，并对各设备制造商发布。设备制造商基于标准设备模板构建其特定设备驱动。

特定设备驱动：特定设备驱动派生自标准设备模板，由设备制造商在标准设备模板的基础上扩展其特定设备的描述细节和驱动细节来构造。扩展的内容包括以下两部分：

Part1，扩展设备相关描述信息，包括如modelName, ModelURL, manufacturer, manufacturerURL, serialNumber等。

Part2，扩展特定设备驱动，即使用驱动过程语言（DPL）为每个设备操作的输入/输出消息定义基于流模式的消息处理动作，并使用ddt:action元素的operation和message属性将消息处理动作绑定至其对应的操作消息。

一种特定空调设备的驱动片段如下所示：

<ddt:device>

<ddt:deviceType name="air-conditioner" />

<ddt:modelName name="A" />

<ddt:manufacturer name="Haier" /> ...

</ddt:device>

<wsdl:types> ... </wsdl:types>

<wsdl:message name="setPowerReq"> ... </wsdl:message>

<wsdl:portType>

<wsdl:operation name="setPower">

<wsdl:input message="setPowerReq" />

</wsdl:operation>

</wsdl:portType>

<ddt:actions>

<ddt:action name="setPowerReqAction"

operation="setPower" message="setPowerReq">

<ddt:step>...</ddt:step>

</ddt:action>

<ddt:action name="getMeasuredTemperatureAction" ...>

</ddt:action>

</ddt:actions>

3、驱动过程语言

如上所述，设备服务代理基于WSDL对外发布其设备服务描述，并接收来自外界的Web服务调用。除此之外，本发明需提供一种方法，用于将针对Web服务接口的调用转译为面向设备私有接口的调用。另外，还需要一种数据转换的方式，将代理和设备之间的交互数据随时按需转换为合适的格式，如控制命令、数据格式、状态代码等。

基于上述考虑，本发明提出一种驱动过程语言（Driver Processing Language, DPL）。该语言基于一种简化的工作流模型，为私有协议设备的驱动方式提供一种规范化、描述性的建模能力。基于驱动过程语言，设备制造商可以向设备服务代理发布其特定设备驱动程序，包含了与此设备进行交互的所有细节。在设备服务代理内部，驱动过程语言被驱动解析组件解析为特定设备的控制指令，用于实现对此设备的控制。

驱动过程语言的设计目标主要包括：（1）DPL是解释性的语言，由设备服务代理的驱动解析组件屏蔽底层***的异构性；（2）DPL是面向过程的语言，可以使用内建的结构化模型组合设备驱动的原子操作，DPL支持多种结构化操作定义，如sequence和choice等；（3）DPL支持多种内建函数，如add, mask, chesksum, join, passby等，用于处理用户输入的/设备输出的/过程流中出现的各类数据。驱动过程语言的BNF范式定义片段如下所示。

DPL ::= "<ddt:actions>" < action > { action } "</ddt:actions>"

action ::= "<ddt:action name="< variable > "operation=" < variable > "message=" < variable > ">""<ddt:sequence>" < statement > { < statement > } "</ddt:sequence>" "</ddt:action>"

varStr ::= < string >

statement ::= < structure > | < step >

structure ::= < sequence > | < choice >

step ::= "<ddt:step name=" < variable > "cmd=" < function > [ return ] ">""<ddt:cmdIn value=" < variable > "/>" {"<ddt:cmdIn value=" < variable > "/>"} "</ddt:step>"

variable ::= < varStr > | < varInt > | < varFloat > ...

假设我们要使用驱动过程语言描述与一个空调设备进行交互的过程。空调设备类作为一种设备驱动架构定义的标准设备类型，在其标准设备模板定义了一些通用标准操作，如setPower，setModeType，getMeasuredTemperature等。每一个操作对应于此设备的一个交互动作，每个动作可能包含几个操作步骤。如对于setPower操作，采用驱动过程语言为其输入消息绑定一个消息处理动作 setPowerReqAction，用于将用户的输入（如ON）转换为实际的设备控制帧指令（如0xFF01FFFFFF）。此处，消息处理动作setPowerReqAction在接收用户输入消息之后触发。操作setPower和其绑定的动作setPowerReqAction的DPL片段如图所示。

<wsdl:operation name="setPower">

<wsdl:input message="setPowerReq" />

</wsdl:operation>

<ddt:action name="setPowerReqAction"

operation="setPower" message="setPowerReq">

<ddt:sequence>

<ddt:choice value="{power}" result="R">

<ddt:case value="_ON" result="0x01" />

<ddt:case value="_OFF" result="0x10" />

</ddt:choice>

<ddt:step cmd="join" result="Frame">

<ddt:cmdIn value="0xFF" />

<ddt:cmdIn value="{R}" />

<ddt:cmdIn value="0xFF" />

</ddt:step>

</ddt:sequence>

<ddt:action>

在上述代码片段中，setPower的输入消息为setPowerReq，它接收一个枚举类型的用户输入参数（ON或OFF）。设备服务代理的驱动解析模块基于以下的逻辑过程处理用户的输入：

1) 开始一个顺序结构，由<sequence>标签标识。

2) 开始一个分支结构，由<choice>标签标识，在此结构中，解析器将用户的输入自动赋值给变量<power>；若用户的选择为ON，则变量R=0x01。在DPL中，R代表一个变量，而{R}代表变量的引用。

3) 结束此分支结构，程序可以通过变量{R}获得此分支结构的输出。

4) 开始一个单步操作，由<step>标识。此单步操作执行一个内建的基本函数join，用于将函数的输入参数顺序组合为一个数据帧，如0xFF01FFFFFF，帧结构中包含了变量R的值。数据帧被赋值给变量 Frame。

5) 结束此单步操作，返回结果Frame。

6) 数据帧按需由服务代理发送至设备服务代理的私有协议接口组件，此步骤是自动操作。

7) 结束上述顺序结构。

类似的，对于操作getMeasuredTemperature的输出消息被绑定至一个消息处理动作getMeasuredTemperatureRespAction，此动作用于将设备输出帧转换为用于显示的可读格式。操作getMeasuredTemperature及其动作getMeasuredTemperatureRespAction的DPL片段如图所示。此处，消息处理动作在设备服务操作getMeasuredTemperature发送输出消息之前完成。代理的驱动解析模块基于以下的逻辑过程处理空调设备经由私有协议接口组件返回的数据帧：

1) 开始一个顺序结构，由<sequence>标签标识。

2) 开始一个单步操作，由<step>标识。此单步操作执行一个内建的基本函数byteMask，用于将设备返回的数据帧和获取温度的掩码数据帧进行按位与操作，将返回的设备格式的温度数据存储至变量R1。

3) 结束此单步操作，返回结果R1。

4) 开始一个单步操作，由<step>标识。此单步操作执行一个内建的基本函数add，将上步产生的数据{R1}和整型16作加法运算，将运算结果存储至变量{measuredTemperature}。

5) 结束此单步操作，返回结果{measuredTemperature}。

6) 结果经由服务操作getMeasuredTemperature的输出消息getMeasuredTemperatureResp发送，此步骤是自动操作。

7) 结束上述顺序结构。

<wsdl:operation name="getMeasuredTemperature">

<wsdl:output message="getMeasuredTemperatureResp" />

</wsdl:operation>

<ddt:action name="getMeasuredTemperatureRespAction"

operation="getMeasuredTemperature"

message="getMeasuredTemperatureResp">

<ddt:sequence>

<ddt:step cmd="byteMask" result="R1">

<ddt:cmdIn value="_out" />

<ddt:cmdIn value="0x000000FF000000" />

</ddt:step>

<ddt:step cmd="add" result="{measuredTemperature}">

<ddt:cmdIn value="{R1}" />

<ddt:cmdIn value="16" />

</ddt:step>

</ddt:sequence>

<ddt:action>

综上，本发明提出一种新型的家庭设备服务适配方法——设备服务代理，将私有协议网络内的一组设备抽象为对外提供标准Web服务的虚拟设备，可普遍适用于当前家庭网络异构性强、设备资源受限的环境；本发明构造并设计了应用于设备服务代理的三层设备驱动架构，提供标准化设备模板，实现灵活、方便的设备服务描述；另外提出一种基于简化工作流的设备驱动语言，设备制造商可以在不改变其设备内部软件***的条件下，利用标准设备模板和设备驱动语言发布跨平台的设备外部驱动程序，用于设备服务代理与设备之间的交互，包括设备服务的描述、发布和访问等服务操作。

以上所述，仅是本发明的较佳实施例而已，并非是对本发明作其它形式的限制，任何熟悉本专业的技术人员可能利用上述揭示的技术内容加以变更或改型为等同变化的等效实施例应用于其它领域有类似要求的液体、气体的控制，但是凡是未脱离本发明技术方案内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与改型，仍属于本发明技术方案的保护范围。

Claims

1.一种应用于家庭网络的设备服务适配方法，其特征在于包括如下：

2.根据权利要求1所述的设备服务适配方法，其特征在于：所述设备服务代理包括以下四个核心组件：

私有协议接口组件，该组件为设备服务代理的上层组件屏蔽底层私有网络协议的异质性；

设备注册组件，该组件用于存储私有协议网络设备的相关配置信息，并管理当前在线的私有协议网络设备驱动的动态加载过程；

驱动解析组件，该组件用于将基于驱动过程语言实现的设备驱动解析为针对特定私有协议设备的控制指令，用于实现该设备的控制；

服务代理组件，该组件用于将设备服务代理对外暴露为一个提供标准Web服务的虚拟设备，并处理来自家庭服务中间件或外部设备/应用的服务调用请求和进行服务响应。

3.根据权利要求2所述的设备服务适配方法，其特征在于：所述设备驱动架构包括三层模板机制驱动架构：

位于最上层的抽象设备模板，由驱动解析器实现模板解析和有效性验证；

位于中间层的标准设备模板，由设备驱动架构提供给设备制造商用于灵活方便的编写设备外部驱动；

位于最底层的特定设备驱动，由设备制造商提交给设备服务代理用于支持代理和设备之间的互操作。

4.根据权利要求3所述的设备服务适配方法，其特征在于：所述特定设备驱动由设备制造商在标准设备模板的基础上扩展其特定设备的描述细节和驱动细节来构造，扩展的内容包括以下两部分：扩展设备相关描述信息和扩展特定设备驱动。

5.根据权利要求4所述的设备服务适配方法，其特征在于：所述设备服务代理各组件之间的通信采用基于事件的异步通知机制实现。

6.根据权利要求5所述的设备服务适配方法，其特征在于：所述设备服务代理或分布部署在多个设备上，或集成在同一设备内部。

7.根据权利要求6所述的设备服务适配方法，其特征在于：所述配置信息包括：由设备制造商提供的设备驱动；由下层私有协议接口组件提供的设备动态状态信息。

8.根据权利要求7所述的设备服务适配方法，其特征在于：所述细节包括操作定义、消息定义和变量定义。