SWE

This is version 5. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Sensor Web Enablement: A synopsis

The SWE initiative seeks to provide interoperability between disparate sensors and sensor processing systems by establishing a set of standard protocols to enable a "Sensor Web," by which sensors of all types in the Web are discoverable, accessible, and taskable. The SWE standards allow the determination of the capabilities and quality of measurements from sensors, the retrieval of real-time observations in standard data formats, the specification of tasks to obtain observations of interest, and the asynchronous notification of events and alerts from remote sensors.

SWE components include models and XML Schemas (SensorML, Observations&Measurements, TransducerML) and Web service interfaces (SOS, SPS, SAS, WNS), which are briefly described as follows:

• SensorML, Sensor Model Language: An XML Schema to describe sensors and sensor platforms. SensorML provides a functional description of detectors, actuators, filters, operators, and other sensor systems, which are all treated as instances of process models.

• O&M, Observations & Measurements: A specification for encoding observations and measurements from sensors.

• TransducerML, Transducer Markup Language: A specification that supports real-time streaming of data to and from transducers and other sensor systems

• SOS, Sensor Observation Service: This Web service interface is used to request and retrieve metadata information about sensor systems as well as observation data.

• SPS, Sensor Planning Service: Using this Web interface,users can control taskable sensor systems and define tasks for the collection of observations and the scheduling of requests.

• SAS, Sensor Alert Service: Through this Web service interface, users are able to publish and subscribe to alerts from sensors.

• WNS, Web Notification Service: This Web service interface allows the asynchronous interchange of messages between a client and one or more services (eg, SAS and SPS).

Getting streaming observation data

Streams, SWE, and RBNB

Currently, we are investigating the feasibility and suitability of providing SWE-related interfaces to RBNB data. A possible goal in this direction is to design and implement Kepler actors to get sensor data using some of the SWE services, for example, an SosReaderActor to connect to an SOS server. In this case, an SOS server would be implemented on top of an RBNB server.

In COMET we are starting to get direct access to various data streams from BML, so we will be using these data sources as well in our testbed. We are considering setting up an RBNB server on COMET to handle the BML streams. This will provide us with more options for our tests.

TransducerML

From the specification:

7.4 Live and Historical Streaming Data

Because transducers are real world interfaces, their responses are representative of the changing world. This changing world is represented in live streaming transducer data. TML captures this living streaming data, which is representative of real world transducer events corresponding to multiple phenomena and maintains the relative and absolute temporal and spatial relationships of the data such that we can review the events exactly as they happened either live in real time or at a different place and/or a different time. TML data represents a continuous stream of data from or for possibly a multitude of different transducers, all interleaved randomly, in roughly chronological order. It is up to the data acquisition equipment to capture the data as precisely and accurately as possible such that the precision and accuracy capabilities of the transducers are fully recognized and the acquisition process is not degrading the data in any fashion. The task of data integration and understanding is left to the transducer processors.

Getstream.jpg

80902 bytes