传感器传感器观测的应用

服务接口_网络地理信息系统

10.2.2　服务接口

10.2.2.1　传感器观测服务(SOS)

SOS为管理已部署的传感器和检索传感器数据特别是“观测”数据提供了应用程序接口(API)，它的目的在于以一种标准的方式为来自于不同传感器和传感器系统的观测数据提供一致的访问接口，是SWE架构的关键要素。传感器系统中可以包括远程传感器、原位传感器、固定传感器以及移动传感器等。图10.16显示了一些不同类型的原位传感器可以组成不同星座(constellation)，通过SOS来访问。SOS提供了广泛的互操作能力，以发现、绑定和集成实时、归档或模拟环境下的单个传感器，传感器平台或网络传感器星座。

图10.15　TML的总体结构

图10.16　传感器星座(Na和Priest，2007)

1.SOS基本操作

SOS是连接客户和传感器观测的中介。客户可以访问SOS来获取描述相关联的传感器、平台、处理程序的元数据信息以及其他与观测结果相关联的元数据。在这个过程中涉及SOS的三个核心操作:GetObservation，DescribeSensor和GetCapabilities。

(1)GetObservation提供了通过可由现象筛选的时空查询访问传感器观测和量测数据的接口。图10.17和图10.18分别显示了GetObservation请求和返回的XML例子。

图10.17　GetObservation请求的XML描述

图10.18　GetObservation响应的XML描述

(2)DescribeSensor操作获取产生量测的有关传感器和过程的描述信息。图10.19和图10.20分别显示了DescribeSensor请求和返回的XML例子。

图10.19　DescribeSensor请求的XML描述

图10.20　DescribeSensor响应的XML描述

(3)GetCapabilities为访问SOS服务的元数据提供了方法。

除了以上三个操作之外，SOS为了支持各种处理，还提出了两个事务操作:注册传感器(RegisterSensor)和插入观测数据(InsertObservation)以及六个增强操作:提供有效机制不断请求传感器数据(GetResult)，与量测相关的感兴趣地物(FOI)的具体的描述(GetFeatureOfInterest)，FOI可获取量测的时间(GetFeatureOfInterestTime)，请求FOIs的XML模式(DescribeFeatureOfInterest)，请求观测类型的XML模式(DescribeObservationType)和请求量测结果的XML模式(DescribeResultModel)。

2.SOS的基本方法

SOS在所使用的方法以及其所依赖的SWE规范都旨在为传感器、传感器系统和观测结果构建模型，这个模型要覆盖所有种类的传感器并支持所有使用传感器数据的用户需求。具体来说，SOS利用O＆M规范来为传感器观测构建模型，利用TML和SensorML规范来为传感器和传感器系统构建模型。图10.21显示了用户与SOS交互过程中返回信息与其他SWE规范之间的联系。

图10.21　用户使用传感器数据的流程(Na和Priest，2007)

SOS为所有传感器、传感器系统和它们的观测定义了一种公共模型。这个模型是“平行的”，因为它可应用于所有使用传感器来采集数据的领域，特定领域的细节信息被封装到第二层(感兴趣的要素、观测属性、传感器描述)中，这样可以允许一个通用的客户处理基本的观测。

3.观测提供Observation Offerings

SOS将有关传感器系统观测的集合组织起来形成了观测提供Observation Offerings。Observation Offerings类似于Web地图服务(WMS)中的“层”，每一个offering都定义为一组不重叠的相关观测，通过一些参数限制，这些参数包括:

(1)报道观测的特定传感器系统;

(2)请求观测的时间段(支持历史数据);(3)被感知的现象;

(4)限制传感器的地理区域;

(5)传感器观测的要素的地理区域。

OGC SOS的规范得到了一些GIS相关机构的支持，目前遵循OGC SOS服务的实现软件有52 North SOS，GeoBliki，The VisAnalysis Systems Technologies Team(VAST)和Deegree SOS。

10.2.2.2　传感器规划服务(SPS)

SPS提供了传感器规划的标准接口，通过该接口客户端可以判断一个或多个传感器或平台满足数据采集需求的可行性，客户端也可以向这些传感器或平台提交数据采集的请求(Simonis，2007)。SPS不仅可以支持具有不同采集能力的各类传感器资源，还支持各种请求处理系统，实现对规划、调度、任务分配、采集、处理、归档、请求分发、观测结果和请求响应信息的访问。因此，SPS的设计必须具有充分的灵活性来处理各种各样的配置。

表10.1列出了SPS接口中的主要操作。由于完成任务的时间事先无法知晓，SPS使用了WNS以异步方式与客户端进行通信。

表10.1　SPS主要操作

10.2.2.3　传感器预警服务(SAS)

SAS是一种发布/订阅的事件通知系统。一个服务提供者(producer)可以在事件通知系统里发布新的事件类型并随后发布新事件。另一方面，服务消费者(consumer)可以订阅可访问的事件服务。消费者可以在符合其订阅条件的事件发生后自动收到通知。一个SAS可以提供一系列的关于传感器和传感器观测的预警，例如量测值超标、检测到某要素的活动或存在，以及传感器的状态(电量低、关闭、启动等)。

SAS类似于一个事件流处理器与事件通知系统的结合。传感器能动态地连接到SAS，并发布元数据和观测数据(使用SensorML和O＆M)。一个SAS可以不间断地处理输入的传感器数据。它利用某些算法，例如模式匹配算法，识别传感器数据是否满足预警条件，若满足就启动预警发送过程。

需要强调的是，SAS本身所起的作用更像是一个注册表而不是一个事件通知系统。不同的事件类型可以被标识出来，对每一个新定义的事件类型，SAS就会开启一个新的发送通道，并且将预警类型包含在能力文档里，例如由一个预警用户新定义的预警类型也可以被其他用户获得。

SAS主要操作类型包括:

(1)Advertise:SAS允许生产商对所提供的预警服务进行宣传，比如提供此预警的版本、预警时间、预警格式和效果等。

(2)Subscribe:消费者或者相关方可订阅SAS发布的预警服务并且可自定义预警服务。

(3)Publish:SAS允许生产商发行自己的预警服务，当事件发生时，SAS就将发送一个预警并通过消息服务告知所有已订阅此事件类型的用户。

传感器或其他数据生产者在SAS上用HTTP POST请求公布其数据类型。如果这些数据类型以前没有传感器发布过，SAS将指导消息服务器建立一个新的多用户组(Multiple User Chat，MUC)。否则，SAS提供一个已经存在的MUC。SAS通常和消息服务器在同一机器下工作。SAS内部维护了存储现有MUC信息的查询表。理论上，一个SAS实例可以使用一个MUC来服务各种传感器，但该情形下需要过滤的消息数量会显著增加。SAS接收到传感器的广告后，使用HTTP返回MUC，传感器用MUC进行注册并发布数据(图10.22)。这种注册实际上就是订阅MUC，并使用了可扩展通讯和表示协议(Extensible Messaging and Presence Protocol，XMPP)。XMPP协议可以用作预警通知的标准传输协议，但是客户端也可以通过WNS来通知。

客户端可能是人类用户或机器，甚至可以是另一个SAS。客户端通过HTTP发送GetCapabilities请求来了解SAS的能力。基于HTTP的GetCapabilitiesResponse主要包括传感器发布的所有信息以及一个SAS控制的SubscriptionOfferingID。这个ID用于标识一个唯一的MUC。

要订阅一个特定的SubscriptionOfferingID，客户需要发送两次订阅请求。第一次是基于HTTP并返回MUC，这只是一次查询而非真正的订阅。真正的订阅发生在基于XMPP的订阅过程执行后。有一个例外:如果用户希望通过WNS进行通知。只有在这种情况下，订阅处理在第一次请求后结束，SAS返回一个状态消息，表明订阅已经被成功处理(Simonis，2006)。

图10.22　SAS的操作(Simonis，2006)

10.2.2.4　网络通知服务(WNS)

Web服务提供了一种合适的方式来收集所需要的信息。同步传输协议比如HTTP提供了必要的功能来发送请求和接收相应的响应。HTTP是一种可靠的传输协议。通过每次传输到达或失败的确认，HTTP可以确保每个请求包的传递。例如，在简单的WMS里，用户在发送请求后，经过约定的时间，会接收到可视化图形信息或异常消息。然而随着服务变得越来越复杂，基本的请求—响应机制需要增加延时/失败信息(delays/ failures)。例如中期或者长期的操作需要支持用户和相应服务间或者两个服务间的异步通信机制。为了满足在SWE框架内的这一需要，WNS应运而生。

SWE中至少两个服务可以使用WN，SPS允许用户定制传感器任务或获取某种传感器数据集请求的可行性。任务定制和可行性研究都是长期过程。SPS使用WNS将原始查询结果转发给用户。SAS的客户端并不能访问网络时，SAS使用WNS来进行消息的传递。

WNS包括两种类型的通知:一是“单向通信”(one-way-communication)，它将消息发送给客户端而不需要任何响应;二是“双向通信”(two-way-communication)，它对客户端传递消息的同时需要接收异步响应。这种区别意味着简单WNS与复杂WNS之间的差异。简单WNS在某一特定事件发生时，便通知用户或者某服务;复杂WNS除了通知功能外，还可以接收来自用户的反馈。

WNS使用了两种消息容器(container)来交换消息。NotificationMessage用于oneway通信，而CommunicationMessage用于two-way通信。但需要回复消息时，消息的发送者可以使用CommunicationMessage。接收端应该知道需要哪种回复消息，建立相应的ReplyMessage并将其送回给定的CallbackURL。

One-way通信不支持返回值和out类型参数，但能解决一些传统同步阻塞调用模型浪费服务器端资源、降低系统吞吐率、容易因服务器之间调用形成回路而导致的死锁等难以解决的问题。Two-way方法指客户端和服务器端分别向对方发出one-way调用。客户端发送调用后不必阻塞等待应答而继续执行其他操作。服务端完成服务后，通过向客户端发送一个对应的one-way调用返回结果。这种方法不利用多线程而又能提高系统吞吐率，但该方法增加了服务端设计的复杂性，要求把应用和逻辑分割开来。

WNS支持使用不同传输协议的通知传递。可以通过HTTP、即时消息(例如XMPP)、Email、短信、传真和电话等方式来传递消息。WNS可以作为一个传输转化器:它可以在输入和输出消息协议之间进行转化。它与SAS不同，并不是一个主动预警服务。在SAS的接收者需要使用其他协议进行消息接收时可以使用WNS。WNS实例支持的协议在它的Capabilities文档中进行说明。

WNS可以看做是一个消息传输服务。它并不关心消息的具体内容，被传递的消息对WNS而言就是一个“黑盒子”。WNS通知的客户可以是一个用户或者是一个OGC服务。一旦客户注册为一个用户并且选择了某种通知方式，客户就会接收到一个唯一的注册ID(registrationID)。这个ID在每个WNS实例中是唯一的，用于WNS标识消息的接收方(例如SPS或SAS)。

表10.2列出了WNS接口中的主要操作(Simonis和Echterhoff，2006)。

表10.2　WNS主要操作