|
OGC Sensor Web Enablement
Summary, Current Status and Comments
Galip Aydin, November 08 2004
OGC SWE is intended to be a revolutionary approach for exploiting Web-connected sensors such as flood gauges, air pollution monitors, satellite-borne earth imaging devices etc [1].
The goal of SWE is to creation of Web-based sensor networks. That is to make all sensors and repositories of sensor data discoverable, accessible and where applicable controllable via the WWW [1].
OGC defines a set of specifications and services for this goal. Below are short descriptions of these services and the names and dates of the OGC documents I have covered.
- Sensor Web Enablement White Paper; Mike Botts, Mark Reichardt.
A summary of the OGC’s SWE vision and the Sensor Web Services.
- SensorML: XML encoding language for sensors. Used to discover, query and control Web-resident sensors.
ref# : 04-19
date : 2004-09-24
- Observations & Measurements: The general models and an XML encoding for what a sensor observes or measures (The value returned by or derived from a sensor observation -e.g. quantity, count, boolean, category, ordered category, position-).
ref# : 03-022r3
date : 2003-02-04
- Sensor Collection Service: A service to fetch observations from a sensor or constellation of sensors. Provides real time or archived observed values. Clients can also obtain information that describes the associated sensors and platforms. This is the intermediary between a client and a sensor collection management environment.
ref# : 03-023r1
date : 2003-01-21
- Sensor Planning Service: A service by which a client can determine collection feasibility for a desired set of collection requests for one or more mobile sensors/platforms, or the client may submit collection requests directly to these sensors/platforms. SPS enables sensor tasking, acquisition requests, processing and simulation requests, and registration for alert notification.
ref# : 03-011r1
date : 2003-01-14
- Web Notification Service: A service by which a client may conduct a dialog with one or more other services. This service is useful when many collaborating services are required to satisfy a client request, and/or when significant delays are involved is satisfying the request. Provides a means for Sensor Planning Services to alert people, software, or other sensor systems of SPS results or alerts regarding phenomena of interest.
ref# : 03-008r2
date : 2003-01-21
Figure 1. Possible Configuration of Sensor Web Components for In-Situ Sensors [2]
SWE process and the documents have undergone significant changes; some of these changes and my comments (in blue) services are given here, each description is from the corresponding specification:
- The latest SensorML Recommendation Paper is expected to be released on 11-02-04 as document # 04-019.
Other SWE specifications refer to older versions of SensorML we should try to use the latest version as long as XML Schemas of other services validate.
- The Observations & Measurements draft document brings some enhancements to GML3 Observations schema. The goal of these additions is to make the Observation concept more compatible with the sensor data. Thus the data retrieved from the sensors would easily be described.
New complex types like ObservationArray and ObservationCollection are useful for defining Time-series data fetched from GPS stations.
- Sensor Collection Service is perhaps the center piece of the SWE architecture. It is supposed to provide information about the sensors or sensor platforms, return the capabilities of the sensors or constellations, and fetch observed values either directly from the sensors or from the data archives.
This service is constructed based on OGC OWS1.2 specification and not defined in detail. The specification is not up to date, for instance the Query element in the schemas are based on Web Registry Service (WRS)0.7.1 which is not available online or does not have a chance to become a recommendation anymore. I used OGC Filter Encoding to provide the Filter capabilities for Query.
The capabilities document is based on OWS-1.2 specification, which provides schemas to generate an OGC_Capabilities document.
- Web Notification Service. This is an asynchronous service description which is intended to be a generic implemenation for all OGC services that might require notification services.
A Notification service is especially useful in the cases where the service trading (publish-find-bind) paradigm is not sufficient. Observations that require preceding control activities or intermediate and/or subsequent user notifications favor asynchronous operations.
For instance in the case of an Earthquake Observation process the client of the sensors must be notified of any extraordinary activy. Thus a notification mechanism becomes necessary.
To make use of the notification capabilities, users have to be registered to WNS beforehand. The registration procedure will be performed by a user or by an OGC Service that can act as a proxy for the user. For the registration users must provide identification information and the notification target (e.g. user’s e-mail address, phone number etc.).
WNS does not provide a user data verification mechanism.
The registration procedure is not explained in detail. We can extend FTHPIS to provide a user/service registration framework for any particular WNS. Although the role of the registries appears to be very central in SWE it is discussed very briefly in a white paper and there are no implementation specific discussions avvailable.
Basically we need registries (or databases) for keeping information about Sensors/Platforms, Sensor/Platform Types, Observable Types, Observable instances etc. A basic implementation is to have tables for each registry in a MySQL database.
Although the OGC provides a WNS the WS-Notification can be considered here as an alternative. Thus we would include other benefits provided by WS-Notification.
We can also include Narada Brokering in this framework to pass asynchronous notifications from the sensors/constellations to the registered parties.This would provide us with features like reliable delivery, archiving messages etc.
- Sensor Planning Service.
SPS is developed to support the information asset manager role. Collection feasibility plans and collection requests for a sensor or a sensor constellation is managed by SPS
It looks like this is not one of the crucial parts of SWE we need to implement immediately. We need to find a new approach for some of the tasks SPS is supposed to do. A probable approach is to use Information System to find and appropriate SCS for the user’s request.
 |
The request-response dialog between SCS and the Sensors/SensorPlatforms is handled with XML messages. The Sensors are described using SensorML but the actual observations or measurements obtained from sensors are encoded in GML3.
As in the other OGC services a SCS provides information about the sensors it can communicate or collect data from. The client issues a GetCapabilities request to the SCS and in return receives a Service Instance (e.g. Capabilities) document. The capabilities document provides a list of sensor platforms supporting multiple sensors or a list of sensors associated with this particular SCS.
After receiving the capabilities document the client may ask a description of the Sensor or the Sensor Platform from the SCS by issuing a DescribeSensor or DescribePlatform request. The response model of this operation is described by SensorML elements DescribePlatform and DescribeSensor.
Asyncronous Communication
One important difference of the Sensor Services from other OGC Web Services is that asyncronous communication might be required between Sensors and the Clients. For instance we might want to know any earthquake activity for a certain area and thus the system should be able to notify us about the observations picked up from the sensors.
OGC Web Notification Service is described for this purpose. The user registers with the WNS by providing an identification and type of the notification he/she wants to receive, i.e. e-mail, http-call, sms etc. WNS then sends a notification to the registered users whenever an event occurs.
In the SWE context the WNS communicates with the Sensor Planning Service. Whenever a previously requested job is completed the SPS sends a ‘job ready’ message that includes the job id to the WNS. WNS notifies the registered user of that job about the situation.
References
1 – Sensor Web Enablement White paper
2 – OGC WS2 SWE-General Document
|
