基于SWE的传感规划服务研究与实现

王建国，许任杰

（西安工业大学 计算机科学与工程学院，陕西 西安 710032）

随着微机电系统、片上系统、无线通信和低功耗嵌入式技术的飞速发展，孕育出了无线传感器网络（Wireless Sensor Network，WSN），并以其低功耗、低成本、分布式和自组织的特点带来了信息感知的一场变革。但随着无线传感器网络的发展也暴露出来异构传感器网络之间缺乏互通性和互操作性的问题。由于传感器网络的异构性，即组成传感器网络的设备、通信协议、数据采集、存储及处理方式等方面的不同，使得这些传感器网络成为仅供特定用户或平台使用的信息源，资源的合理配置和共享成为难题，造成了严重的资源浪费。为解决这一问题，2005年，开放地理空间联盟（Open Geos-patial Consortium，OGC）提出了一种新型的传感器Web标准——传感器 Web 整合框架（Sensor Web Enablement，SWE）[2]。 SWE 是一个全新的标准框架，为构建“即插即用”（plug-and-play）的基于WEB的传感器网络提供一个标准的平台[1]。

SWE由7个规范组成：观测与测量（Observation&Measurement，O&M）[4]、传感器建模语言（Sensor Model Language，SensorML）[5]、 转换器标记语言 （Transducer Markup Language，TML）[7]、传感规划服务（Sensor Planning Service，SPS）[3]、传感观测服务 （Sensor Observation Service，SOS）[8]、 传 感告 警 服务（Sensor Alert Service，SAS）[6]、Web 通知服务（Web Notification Service，WNS）[9]。其中，O&M、SensorML、TML 是信息模型，SPS、SOS、SAS、WNS是功能模型，即SWE规定的4大服务。其中SPS用于和用户交互，并对用户请求进行可行性判定和任务规划。SOS用于获取异构传感器网络的传感观测数据。WNS负责向用户发送观测结果。SAS负责为用户请求任务提供告警服务。这些Web服务使得用户通过Internet就可以实现对传感设备的操控以及传感数据的获取。

在SWE的框架中，SPS是用户和其他SWE服务之间的桥梁，负责评估用户请求集合的可行性并帮助用户建立可行的传感器收集计划和为传感器和传感器平台规划任务请求。有效的传感信息收集及处理，要求一个准确而特定的问题或任务的描述和持续的更新，从而去保证最全面而准确的收集传感数据的可能性，因此SPS是SWE系统能否满足用户需求的关键。

1 SPS的核心操作

从功能上来讲SPS在SWE的各个服务中扮演一个 “控制中枢”的角色，类似大脑对于人的作用，负责“思维”并指导动作。 其核心操作有：Get Capabilities、Describe Tasking、Get Feasibility和Submit。SPS的业务流程图如图1所示。

图1 SPS业务流程图Fig.1 The business processes of SPS

Get Capabilities用于获取服务实例的元数据文档，文档包括SPS服务的版本号、标识信息、所支持的操作、操作的参数描述（Operations Metadata）以及服务提供者的信息（Service Provider）等。用户启动Get Capabilities操作，得到SPS服务实例可能提供的信息后，详细的传感元数据才能被获得。

Describe Tasking用于客户端对具体需要实现目标任务的参数设置，并由SPS进行任务规划，以执行一个提交（Submit）操作。任务规划是SPS最为核心的操作，该操作是为了将任务准确定位到传感器。

GetFeasibility用于用户在提交任务前SPS对任务请求进行可行性判定。结果依赖于用户的请求和SPS所知道的信息（传感器资源、传感器Web服务和可行性判定算法）。可行性判定使得在任务提交前用户对任务可能的执行结果有一个预先的了解以便与用户进行下一步操作，同时也提升了系统的执行效率。

Submit操作用于提交已经SPS规划的任务请求。在执行Submit操作后可以根据响应返回的任务编号（task ID）对已提交任务进行其他操作，如查询任务执行状态（Get Status）、更新任务（Update）、取消任务（Cancel）等。

2 SPS体系结构的设计

SWE规范试图把每一个异构传感器网络都放在Web上，通过标准操作发现和获取他们提供的服务，即服务提供者和服务请求者之间是低耦合的，因此原型系统可以采用面向服务的体系架构（SOA，Service-Oriented Architecture）。

系统为基于Java Web的SOA架构，分为应用层、业务逻辑层、数据层如图2所示。

图2 SPS原型系统体系结构Fig.2 Architecture of SPSprototype system

应用层提供用户界面，负责与用户交互。业务逻辑层则提供服务接口，用户通过业务逻辑层实现具体的操作。在业务逻辑层设计了两个核心类是SPS Servlet和Request Operation。其中SPSServlet类负责处理HTTP请求和返回响应。Request Operation类用于接收来自SPSServlet的请求，并检查请求的有效性，如果是合法有效的请求，则把它交给相应的监听类，再由监听类执行相应的操作。数据访问层设计若干DAO类和工厂类，负责与数据库的交互，为系统所涉及到的每一个业务对象收集数据。

3 原型系统的实现

根据上述设计，并在已经设计实现的基于SWE的传感观测服务SOS和Web通告服务WNS的基础上，实现了一个原型系统。

3.1 应用层实现

应用层采用了“瘦客户端”——通用的浏览器，从而使用户通过Internet就可以控制传感器网络目标。更重要的是将所有的数据处理集中于服务器上，从而使所有的服务于服务请求者无关，而且对服务和数据的更新变得比较容易。

3.2 业务逻辑层实现

业务逻辑层按照SWE对SPS的规范设计了如下列类：

1）SPSServlet类：在SPS系统中担任控制器的角色，主要有两个功能：①根据初始化系统配置文件和数据库配置文件的内容进行系统初始化。②接收HTTP请求并返回响应。

2） Request Operation：接收来自 SPSServlet的请求，进行合法性检查，如果是合法有效的请求，则把它交给响应的监听类，由监听类进行响应的操作，如果调用相应的DAO对象获取结果数据，则对结果数据进行O&M编码，返回响应对象。

3）SPSRequest:代表 SPS的所有请求，如 GetCapabilities Request、DescribTasking、Submit等。所有的 SPS 请求类继承自同一个抽象类Abstract SPSRequest，这个抽象类中定义了SPS请求所共有的特征。

4）SPSRequestListener:对应每个 SPS请求的监听，如GetCapabilitiesListener、GetFeasibilityListener等。 这些监听用于处理相应的请求。

5）SPSFeasibility:负责对用户提交的任务请求进行可行性判定。对于不同的任务请求，可行性判定算法可能和检测请求参数的有效性一样简单，也可能是一个复杂的操作，计算在特定时间、地点完成特定任务的资产可用性。

6）Register:该类负责对传感器资源和传感器服务 （如SOS）进行注册。基于SWE的传感网络所提供的服务、SPS的可行性判定算法均依赖于已注册的资源及服务信息。

7）SPSEncoder:主要是SPS接收用户请求参数以及从数据库调取数据并进行O&M或SensorML编码。8）SPSResponse:用户请求操作后返回相应的请求响应。9）SOS异常类:当请求不合法或者规划任务出错时产生的异常。

3.3 数据层实现

数据层使用工厂模式，由工厂类来创建每个业务对象的DAO。这些DAO中提供了访问数据库的方法。主要方法有：

1）SPSConnectionPool：数据库连接池，用于创建和获取数据库连接。当程序访问数据库需要进行数据库连接时，通过该类获取数据库连接。数据库访问结束后由该类释放数据库连接资源。

2）SPSSQLDAOFactor：工厂类，该类包含了 SPS所有请求的DAO对象，并提供存取这些对象的方法。

3）SPS请求DAO：主要是执行查询操作。根据具体的SPS请求，实现对数据库的访问。用户通过该类可以获取所需的数据，主要包含GetCapabilitiesDAO、DescribeTaskingDAO、SubmitDAO等。

4）insertDAO：数据添加操作，主要是存储、插入和更新各类传感器资源、传感器服务、现象和任务数据等。

通过3.1~3.3对SPS原型系统的具体实现，并在红外楼宇监测网络系统中得到实践，红外楼宇监测网络体系结构如图3所示。

图3 红外楼宇监测网络体系结构Fig.3 Structure of infrared building monitoring network

网络用户可以通过Internet调用SPS服务提出观测请求，并由SPS对用户请求进行任务规划最终完成传感观测并将观测结果以邮件的方式发送给用户。

4 结束语

文中主要通过设计和实现基于SWE的SPS原型系统，实现SPS的核心操作，使用户通过互联网就能访问到来自传感器网络的即时传感数据和来自数据库的历史传感数据的查询。但是关于传感器Web的研究仍然处于起步阶段，笔者所实现的原型系统功能并不完善，对传感器资源及传感服务的自动发现未能实现还需要人为的进行注册。此外系统的任务分配算法也有待优化以提升系统的执行效率，这两方面是今后研究的重点。

[1]王建国.一种新型的传感器Web标准——传感器Web整合框架[J].小型微型计算机系统，2008，29（9）:1647-1651.WANG Jian-guo.A new type of sensor Web standards——sensor Web enablement[J].Journal of Chinese Computer Systems，2008，29（9）:1647-1651.

[2]Botts M，Percivall G，Reed C，et al.OGC Sensor Web Enablement:Overview And High Level Architecture[EB/OL].OGC，Inc，2006，OGC 06-050r2.http://www.opengeospa tial.org/standards/swes.

[3]Ingo Simonis.OpenGISSensor Planning Service Implementation Specification[EB/OL].OGC，Inc，2007，OGC 07-014r3.http://www.opengeospatial.org/standards/sps.

[4]Simon Cox.Observations and Measurements （O&M）-XML Implementation[EB/OL].OGC，Inc，2011，OGC 10-025r1.http://www.opengeospatial.org/standards/om.

[5]Mike Bots.OpenGIS Sensor Model Language （SensorML）Implementation Specification[EB/OL].OGC，Inc，2007，OGC 07-0000.http://www.opengeospatial.org/standards/sensorm l.

[6]Ingo Simonis，Johannes Echterhoff.OGC Sensor Alert Service Implementation Specification[EB/OL].OGC，Inc，2006，OGC 06-028r5.http://www.opengeospatial.org/standards/requests/44.

[7]Steve Havens.OpenGISTransducer Markup Language（TML）Implementation Specification[EB/OL].OGC Inc，2007，OGC 06-010r6.http://www.opengeospatial.org/standards/tml.

[8]Arthur Na，Mark Priest.OpenGISSensor Observation Service ImplementationSpecification[EB/OL].OGC，Inc，2006，OGC06-009r1，http://www.opengeospatial.org/standards/requests/32.

[9]Ingo Simonis，Andreas Wytzisk.Web Notification Service[EB/OL].OGC，Inc，2003，OGC 03-008r2.http://www.opengeospatial.org/standards/wns.

[10]CHU Xing-chen.Open Sensor Web Architecture:Core Services[D].Australia:The University o f Melbourne，2005.