Sensor Web Enablement (SWE)

The concept of Sensor Webs was coined in the 1990’s: millions of connected on-line sensors monitoring the physical world, the sensor capabilities being described using metadata so they can be published and understood by anyone with web access and appropriate authentication. This model is similar in concept to the World Wide Web where a standard web browser can access this vast information space due to the adoption of key standards such as HTTP, HTML and XML. In 2001, a data modeling language for sensors, SensorML, was introduced into the OGC which led to the SWE working group. The group was tasked to produce a framework of open standards for Web connected sensors and all types of sensor systems. The SWE standards draw from a number of existing OGC standards from SensorML to Observations & Measurements and propose a number of services that use the HTTP protocol for access. The services are able to self-describe the data they represent and the access mechanisms they provide [139].

Version 1.0 of the Sensor Observation Service (SOS) was published as an OGC OpenGIS Implementation Standard in October 2007. Of particular interest to SAPHE are the proposed standards for SOS and SAS. Together they provide the ability to store data that can be accessed and queried by an external application and to detect simple conditions that can then generate an alert, published to the external network and various application subscribers.

The role of the SOS is to translate incoming sensor data into a data model that represents the sensor and the data as a series of observations of a particular feature of interest. This translated representation is then archived until an external client makes a request for data, providing a number of parameters that act as filters. The parameters for the SOS include the ability to specify a time constraint, for example, between two time periods, or after a time point, and the identification of the particular sensor cluster. In the case of multiple sets of data from a sensor cluster, the observed property (phenomenon) can be specified along with the features of interest. Once the request for data has been made, the application client receives a set of Observations and Measurements which encapsulate the sensor data in the data model. Sensor data can also be streamed into an SAS where a similar transformation occurs. An external application is able to specify conditions for data as it arrives at the SAS. When the data meets those conditions an event is sent to the application using the publisher/subscriber methodology. The conditions that can be applied in the current proposal for the SAS are limited to specifying whether a sensor data value is less than (or equal to), greater than (or equal to), equal to, not equal to a value, or between two values. For example, an application could specify that an alert should be sent when a PIR sensor detects movement, or when a temperature sensor reports a value over 40ºC which could be critical for certain medicines.

SOS -> Access sensor data, consistent for all kinds of sensor, returns O&M e.g. event time, FoI, observed property, procedure used (often a sensor).

At the time of the author’s experiments in 2007-08, SWE version 1.0 was released as an open set of “Issue 1” standards having been through many drafts and practical evaluations using prototype deployments [140]. The main standards of SWE 1.0 were as follows:

1. Observations & Measurements (O&M) - Standard models and XML Schema for encoding observations and measurements from a sensor, both archived and real-time;

2. Sensor Model Language (SensorML) - Standard models and XML Schema for describing sensors systems and processes associated with sensor observations; provides information needed for discovery of sensors, location of sensor observations, processing of low-level sensor observations, and listing of taskable properties, as well as supports on-demand processing of sensor observations;

3. Transducer Model Language (TransducerML) - The conceptual model and XML Schema for describing transducers and supporting real-time streaming of data to and from sensor systems; 4. Sensor Observation Service (SOS) - Standard web service interface for requesting, filtering,

and retrieving observations and sensor system information. This is the intermediary between a client and an observation repository or near real-time sensor channel;

5. Sensor Planning Service (SPS) - Standard web service interface for requesting user-driven acquisitions and observations. This is the intermediary between a client and a sensor collection management environment;

6. Sensor Alert Service (SAS) - Standard web service interface for publishing and subscribing to alerts from sensors;

7. Web Notification Services (WNS) - Standard web service interface for asynchronous delivery of messages or alerts from SAS and SPS web services and other elements of service workflows.

Within the SWE initiative, the enablement of such sensor webs and networks is being pursued through the establishment of several encodings for describing sensors and sensor observations, and through several standard interface definitions for web services. As shown in Figure 35, OGC members are building a unique and revolutionary framework of open standards for exploiting Web-connected sensors and sensor systems of all types: traffic monitoring (e.g. bridge stress gauges); satellite and airborne earth imaging devices; environmental monitoring (e.g. air pollution, flood gauges); stored sensor data; Webcams; industrial process monitoring; mobile heart monitors [141].

Figure 35 - SWE Discovering Sensors & Sensor Systems [142]

SWE Services

The goal of SWE is to enable all types of Web and/or Internet-accessible sensors, instruments, and imaging devices to be accessible and, where applicable, controllable via the Web. The vision is to define and approve the standards foundation for ‘plug-and-play’ Web-based sensor networks [143]. SWE 2.0 services enable the following functionality:

 XML / SOAP over HTTP;

 RESTful;

 Provide rich data - trust users to filter;

 Pre-organisation of data;

 All services are “self-descriptive” - SOS/SPS: spatial/temporal features, observed feature, phenomenon, sensor, etc [144].

Critical applications that will benefit from SWE include:

 Homeland security;

 Disaster management;

 Emergency services management;

 Military.

The Sensor Web

The term ‘sensor web’ has morphed into sometimes being associated with an additional layer connecting sensors to the World Wide Web. The SWE initiative of the OGC defines service interfaces which enable an interoperable usage of sensor resources by enabling their discovery, access, tasking, eventing and alerting. By defining standardised service interfaces, a sensor web based on SWE services hides the heterogeneity of an underlying sensor network, its communication details and various hardware components, from the applications built on top of it. OGC’s SWE initiative defines the term

‘sensor web’ as an infrastructure enabling access to sensor networks and archived sensor data that can be discovered and accessed using standard protocols and application programming interfaces. Through this abstraction from sensor details, their usage in applications is facilitated. The Sensor Web aims to enable different operating systems Java (Sun SPOT), Tangos (Xbow), Contiki and others to interface and operate as a unified system rather than a number of disparate systems.

Discovery of sensors relies on accurate and timely catalogue registration (up-to-date so sensors remain discoverable) whereas control of sensors depends on their primary purpose and related security constraints. The Internet infrastructure enables the sensor web to become feasible, however, security and privacy provide boundaries to restrict access to certain sensors and their data. For example, weather data is freely publishable (due in some part to low accuracy rates) as opposed to military sensor system data or medical sensor data, which are highly classified, or sensitive patient data respectively. Therefore, the concept of the sensor web enabling discovery, tasking and alerting of all sensors and sensor systems of all different types regardless of size, capabilities or location is unlikely according to the author, because of the necessary barriers.

However, as sensor network deployments grow and mature there emerge a common set of operations and transformations. These can be grouped into a conceptual framework called the Sensor Web. Sensor Web combines cyber infrastructure with a SOA and WSNs to provide access to heterogeneous sensor resources in a deployment independent manner. The Open Sensor Web Architecture (OSWA) is a platform independent middleware for developing sensor applications. OSWA is built upon a uniform set of operations and standard data representations as defined in the SWE Method by the OGC. OSWA uses open source and grid technologies to meet the challenging needs of collecting and analysing observational data and making it accessible for aggregation, archiving and decision making [145].

Integration of Observations from a Variety of Sensors

The SWE user desires the ability to discover and integrate observations from any sensor that meets their needs. The Sensor Web desires and vision are listed as follows [146]:

Sensor Web Desires

 Quickly discover sensors (secure or public) that can meet user needs – location, observables, quality, ability to task;

 Obtain sensor information in a standard encoding that is understandable by user and their software;

 Readily access sensor observations in a common manner, and in a form specific to user needs;

 Task sensors, when possible, to meet user specific needs;

The Sensor Web Vision

 Sensors will be web accessible;

 Sensors and sensor data will be discoverable;

 Sensors will be self-describing to humans and software (using a standard encoding);

 Most sensor observations will be easily accessible in real-time over the web;

 Standardized web services will exist for accessing sensor information and sensor observations;

 Sensor systems will be capable of real-time mining of observations to find phenomena of immediate interest;

 Sensors will be capable of issuing alerts based on observations, as well as be able to respond to alerts issued by other sensors;

 Sensors and sensor nets will be able to act on their own (autonomous);

 Software will immediately be capable of geo-locating and processing observations from a newly-discovered sensor.

OpenGIS Sensor Web Enablement

The following web services, encodings and client are based on open standards and standards bodies such as the W3C, OGC, ETSI, OData, ISO, IEEE, and OASIS. “Just as http:// is the dial tone of the World Wide Web, and HTML / XML are the standard encodings, the spatial web is enabled by OGC standards [147]. For example:

“High-level” OGC Services supporting sensor data [148]:

 Web Map Service (WMS) – request map (e.g. visualizations of geo data);

 Web Coverage Service (WCS) – request binary gridded or aggregated data (e.g. raster graphics);

 Web Feature Service (WFS) – request feature data (e.g. vector graphics). Sensor Web Enablement Framework – Schema:

 SensorML – models and schema for describing sensor characteristics (geo-location, response);

 Observation & Measurement (O&M) – models and schema for encoding sensor observations. Sensor Web Enablement Framework – Services:

 Sensor Observation Service (SOS) – access sensor information (SensorML) and sensor observations (O&M);

 Sensor Planning Service (SPS) – task sensors or sensor systems;

 Web Alert Service (SES) – asynchronous notification of sensor events (tasks, observation of phenomena);

Sensor Web Enablement Framework – Probable Additions:

 TransducerML (TML) – XML protocol for streaming data clusters from transducers (sensors, transmitters, actuators). Combined with SensorML, so TML discontinued in SWE 2.0;

 Common Alert Protocol (CAP) – developed by international emergency management community for XML publishing of events.