Home » Publications » OpenGeo Sensor Web Enablement (SWE) Suite

OpenGeo Sensor Web Enablement (SWE) Suite

Dr. Mike Botts, Botts Innovative Research Inc., June

OGC SWE Overview

the Open Geospatial Consortium (OGC) has been engaged in developing a set of standards for web-enabling sensors and sensor observations. Version 1.0 of the Sensor Web Enablement (SWE) standards were approved and released. Versions 2.0 of these standards have either been approved, or will be approved by Fall. 

The suite of standards currently comprising SWE includes 3 standard XML encodings and 3 standard web service interfaces. These standards support discovery of sensors, observations, and processes surrounding measurement, as well as the tasking of assets, access to observations and observation streams, publication and subscription of sensor alerts, and on-demand processing of sensor observations. The standards include:

Encodings:

• SWE Common - common data models and schema used by all SWE standards
• SensorML - models and schema for describing sensor systems and processes surrounding measurement
• Observations and Measurements (O&M) - models and schema for packaging observations

Web Services:

• Sensor Observation Service (SOS) - standard web interface for accessing observations and subscribing to alerts
• Sensor Planning Service (SPS) - standard web interface for tasking sensor system, models, and actuators
• Web Notification Service (WNS) - standard web interface for support asynchronous web notification through various means

In addition, there are services and capabilities to support discovery, processing, and semantic mediation. Furthermore, various profiles are being developed to support a variety of applications, including for instance, the tasking of satellite sensors, the serving of ocean and weather observations, and multi-INT exchange of military and intelligence data.

SWE Software

There has been some commercial and industry-specific software developed to support SWE, but more importantly, there have been several pockets of open source software developed in support of SWE. This includes a collection of open source toolkits and applications developed at the University of Alabama in Huntsville (UAH) and now maintained on Google Code by Botts Innovative Research, Inc (Botts-Inc) and SPOT Image. Other open source software includes SWE web service support available at 52 North, as well as smaller development efforts under the Marine Metadata Initiative for support of ocean sensors.

Such software provides heavy-duty developers with tools needed to create web services and clients for supporting SWE functionality. However, it is currently still too difficult and time-consuming for potential SWE users to integrate sensors into an interoperable Sensor Web.  There is a strong need for an integrated, user-friendly open source suite of capabilities that will enable sensor operators to quickly and easily make these assets accessible on a secure or public web and to allow users to readily discover, access, and exploit these sensor assets.

The OpenGeo-SWE project has been initiated with the intent to enable a team of developers to provide such a suite of tools with an eye for security, versatility, modularity, and most importantly, ease of deployment. A draft roadmap for providing these capabilities is discussed in the following section.

SWE Development Roadmap

SWE Services Node

Enabling sensor operators to quickly and easily deploy and web-enable sensors is perhaps the most critical capability to develop under the OpenGeo umbrella. If properly designed, a SWE-service node would provide support for the discovery of dynamic assets and measurements, for access to real-time or archived observations, for tasking of sensors, models, or actuator systems, for publishing and subscribing to alerts, and for on-demand, on-board, configurable processing. In addition, such a node architecture would provide configurable security and plug-in-play modules to support an array of sensors and actuators.

An architecture design is illustrated below.

This diagram depicts a small footprint server node that can be easily configured to support a wide variety of sensor and actuator assets, as well as meet ancillary requirements for security, database storage, and communication. In addition, an internal SensorML process execution engine will enable uploadable and configurable processing at the node. Such software could be used to rapidly deploy new assets, as well as support legacy sensor deployments without interfering with existing operations.

The diagram also illustrates interoperability of the SWE node with a larger Data Server built on GeoServer. In this approach, one can consider a large number of SWE node deployments providing access to lower-level assets, while the larger capacity Data Server could provide higher-level information based on integration and portrayal of these sensor data through a host of web services.

The core of many of the software components for such a SWE node exists to some degree within the open source software available on Google Code and at 52N. The intent is to make the SWE node integrated with the OpenGeo Suite, so that a single configuration of data could enable W*S and SWE services when both are relevant.  The OpenGeo philosophy is to make configuration as easy as possible and 'standard by default' - all data exposed automatically compliant with relevant standards.  Bringing SWE interfaces in to the OpenGeo Suite would help increase SWE adoption by making it dead simple for potential sensor providers to share their information. 

Enabling SWE Clients

As sensor assets are made available through the SWE node, it is important that they can immediately and readily be discovered, accessed, and integrated into visualization and analysis tools along with other sensor and Geospatial data. By extending the OpenLayers, GeoExt and GXP libraries to support sensor assets in GeoExplorer and other OpenGeo Suite javascript applications we provide immediate benefits to those sensor owners who have deployed using SWE standards and to the users who are able to immediately exploit these assets.  They will have a powerful web and mobile toolkit to make custom applications that are relevant for their users.

To support SWE-enabled assets, extensions to the current client capabilities should include capabilities to:

• Enable web-service interface interaction with SOS and SPS
• Enable ability to parse SWE encodings (e.g. SensorML, SWE Common, O&M)
• Provide better support for handling highly-dynamic sensors and observations (for both real-time and archived modes)
• Enable default and configurable portrayal of sensor data, including for example, time plots, trajectories, vertical profiles, geolocated imagery and video
• Enable automatic and customized GUIs to support tasking of assets (SPS) and filtering of observations (SOS)
• Enable on-demand processing of observations within the client (more advanced)

Again, there is extensive geospatial javascript software developed by OpenGeo to build upon, as well as some SWE focused open source software that can serve as a basis for some of this functionality. Additionally, much experience has been gained through previous software development with tools such as Space Time Toolkit. These capabilities will be integrated in the OpenGeo Suite, but following the OpenGeo Architecture they will also be easily integrated in other software tools.

SensorML Editor for Sensors and Processes

SensorML provides the ability to fully describe sensor systems and others assets, as well as define the processes surrounding measurement and processing of observations. In such, it can be used to provide:

• electronic spec sheets for sensor systems, specifying a wide range of characteristics and capabilities (e.g. sensitivity and operational limits), as well as position, contacts, references, history, and of course measured properties
• a full mapping of components within a sensor system including explicit flow of data between the components
• a complete description of the lineage or pedigree of an observation, including processes such as tasking request, sensor systems, processing, QA testing, and analysis
• a explicitly defined process flow that can be executed to enable on-demand processing of observations or cross-queuing of sensor-actuator assets

Currently, most SensorML descriptions are created in XML by using generic XML editors which can be a tedious and error-prone exercise, or by editing a previously-defined SensorML template file which is limited to only those systems where templates have been created. Because of these complication and limitations, SensorML descriptions are often not created at all or do not use the full potential of SensorML.

There is a strong need for SensorML editors that allow simple creation of sensor and process descriptions, as well as aggregate systems and processes. An initial open source SensorML Process Editor was created at UAH but is in need of redesign, debugging, and refinement. This tool allows one to describe a single process or sensor component through a more human-friendly interface, and provides support for SensorML profiles defined in RelaxNG.

A simple tool for creating descriptions of complex sensor systems and aggregate processes is also needed and should actually be simpler to develop than the individual process editor.

In addition to editing, a very helpful tool is one that can parse a SensorML description and display the encoded information in a user-friendly view. Such a tool exists in the Open Source "Pretty View" tool developed at UAH and Botts-Inc, but it is in need of refinement and extension, and needs to be brought up to SensorML v2.0. It also needs to support a system or process network view that displays the components in an aggregate process, as well as the data flow between them.

Development of SWE-based Web Processing Services (SWE-WPS)

There is ongoing development of the OGC Web Processing Service (WPS) that is expected to be very general in its design.  GeoServer has a very efficient integrated WPS, and OpenGeo Suite's next major release will include it.  There is a strong need for a SWE-specific profile and implementation that is highly compatible with the SWE services and encoding. In particular, a SWE-WPS would constrain its input and output to being SWE Common Data and would utilize SensorML to define the process. This effort should define such a profile and develop software to support easy configuration and deployment of SWE-WPS instances.

SWE Discovery Services

The discovery capabilities for SWE are currently inadequate and no one has developed discovery services capable of dealing with the dynamics and complexity of sensor systems. Discovery needs in SWE can involve sensors and actuators, observations, alerts, processes, and of course the web services that enable these.

Discovery of SWE assets and products is made more complicated than most typical geospatial data due to the following characteristics:

• Sensor observations and tasking commands are typically highly dynamic and time-dependent, and thus vary on time frames as short as milliseconds.
• Sensor and actuator assets, themselves, are often highly dynamic. They may change location, orientation, modes, calibration, and other measurement parameters on scales of milliseconds to years. Thus, within any 5-minute period, the sensors available to a user at a particular location may partially or completely change.
• To be fully exploit a single observation, discovery requirements may include descriptions of the sensor and actuator assets involved, the set of tasking commands sent, related observation and alerts surrounding that measurement, the full lineage of that observation from tasking to measurement to processing to Q/A testing to analysis, and the availability of processes that can be applied to that observation in order to derive additional information.
• A coarse-grained discovery solution (typical for most geospatial data) is not by itself capable of fully supporting the needs for SWE

Discovery services for SWE may involve several technologies including:

• Traditional registries for sensors and services
• Tracking services that maintain a database of the state of all sensors
• Peer-to-peer (P2P) capabilities for querying a very large numbers of deployed sensors and actuators
• HTML-based textual discovery
• Semantic Mediation
• Other evolving technologies

It is critical that an integrated architecture be developed that can meet the requirements outline above and that easily-deployed services be provided in the open source community. Such an architecture will most likely consist of coarse-grained components that may reside at large data or control centers, augmented by smaller-footprint capabilities that reside nearer to the assets themselves.