Log in
  
Home > Networking & Communications > Wireless > Wireless Applications > Government/Military
Related topics: Government/Military,Aerospace/Military/HS, Environmental Monitoring, Feature, Homeland Security, Intelligent Systems, Networking & Communications, Process Industries, Sensor Applications, Sensors At Work, Sensors Mag, Software, Standards & Protocols, Wireless
Government/Military

New Implementations of OGC Sensor Web Enablement Standards

December 1, 2007 By: Sam Bacharach, Open Geospatial Consortium Inc. (OGC) Sensors

Wildfires, river basins, tsunami alerts, and environmental risk management are just some of the projects using OGC's interoperability framework for Web-based access and control of sensors and sensor data.


In March 2007 we reported on the role of sensor webs in the OGC's OWS-4 disaster response demonstration. In this follow-up article, we highlight some of the projects that have been implementing sensor webs using the OGC's vendor-neutral interoperability framework for Web-based discovery, access, control, integration, and visualization of online sensors and sensor data (see sidebar "OGC Sensor Web Enablement Standards").

NASA
Adopting sensor webs as a strategic goal, the U.S. National Aeronautics and Space Administration (NASA) has funded a variety of projects to advance sensor web technology for satellites. A number of these projects have adopted the OGC's Sensor Web Enablement (SWE) suite of standards. Central to many of these efforts has been the collaboration between the NASA Jet Propulsion Lab and the NASA Goddard Space Flight Center (GFSC) using the Earth Observing 1 (EO-1) and assorted other satellites to create sensor web applications which have evolved from prototype to operational systems.

In the OWS-4 test bed activity, GSFC, Vightel Corp., and Noblis initiated a sensor web scenario to provide geographic information system (GIS)-ready sensor data and other infrastructure data to support a response to a simulated wildfire emergency. One of the satellites used in the demonstration was NASA's EO-1, which had the nearest next in-time view for the target, and so provided the real-time data used. An OWS-4 team prototyped the preliminary transformation to SWE implementation using the Open Source GeoBliki framework they developed for this purpose. Both JPL and GSFC are in the process of changing the remaining interfaces to OGC SWE compatibility (Figure 1). NASA is using the SWE standards to standardize and thus simplify sending commands to satellites.

Click for larger image Figure 1. All of these satellite and airborne sensors are, at least some of the time, using SensorML for geolocation and other purposes. See NASA's JPL and GSFC SensorWeb/EO-1 pages (Click image for larger version)

Northrop Grumman's PULSENet
Northrop Grumman Corp. (NGC) has been using the SWE standards in a major internal research and development (IRAD) project called Persistent Universal Layered Sensor Exploitation Network (PULSENet) (Figure 2).

Click for larger image Figure 2. PULSENet clients in multiple Web locations can enable heterogeneous sensors and sensor systems to work together (Click image for larger version)

This real-world test bed's objective is to prototype a global sensor web that enables users to:

  • Discover sensors (secure or public) quickly, send commands to them, and access their observations in ways that meet user needs
  • Obtain sensor descriptions in a standard encoding that is understandable by a user and the user's software
  • Subscribe to and receive alerts when a sensor measures a particular phenomenon

In its first year, PULSENet was successfully field tested under a real-life scenario that fused data from four unattended ground sensors, two tracking cameras, 1800 NOAA weather stations and the EO-1 satellite.

SANY Sensors Anywhere
SANY IP (Figure 3) is co-funded by the Information Society and Media Directorate General of the European Commission. SANY IP intends to contribute to Global Monitoring for Environment and Security (GMES, a major European space initiative), and the Global Earth Observation System of Systems (GOESS) by developing a standard open architecture and a set of basic services for in situ sensor integration of all kinds of sensors, sensor networks, and other sensor-like services. It aims to improve the interoperability of in situ sensors and sensor networks and to allow quick and cost-efficient reuse of data and services from currently incompatible sources for future environmental risk management applications. Although SANY addresses interoperability in monitoring sensor networks in general, it focuses on air quality, bathing water quality, and urban tunnel excavation monitoring.

 

figure
Figure 3. SANY project inheritance and activities (From an Enviroinfo 2006 article, Denis Havlik et al., "Introduction to SANY (Sensors Anywhere)Integrated Project," Klaus Tochtermann, Arno Scharl (eds.)

The SANY Consortium recognizes the OGC's SWE suite of standards as one of the key technologies that can eventually lead to self-organizing, self-healing, ad-hoc networking of in situ and earth observation sensor networks. Earlier this year, SANY evaluated the capabilities of SWE services with the intention of actively contributing to further development of the SWE standard specifications. As reported at the OGC TC meeting in Ispra (December 2007), the SANY Consortium has described the common architecture used in SANY baseline applications; included architectural requirements inherited from ORCHESTRA, GEOSS, etc.; and published a road map for v1, v2, and v3 versions of the architecture.

52°North
The German organization 52°North provides a complete set of SWE services under GPL license. This open source software is being used in a number of real-world systems, including a monitoring and control system for the Wupper River watershed in Germany and the Advanced Fire Information System (AFIS), wildfire monitoring system in South Africa.

One of several research projects using 52°North's software is the German Indonesian Tsunami Early Warning System (GITEWS) (Figure 4), a 35-million-euro project of the German aerospace agency, DLR, and the GeoForschungsZentrum Potsdam (GFZ), Germany's National Research Centre for Geosciences. GITEWS will use SWE services as a front-end for sharing Tsunami-related information among the various components of the GITEWS software itself. GITEWS uses real-time sensors, simulation models, and other data sources, all of which must be integrated into a single system. SANY, mentioned earlier, is also using 52°North's software.

 

figure
Figure 4. German Indonesian Tsunami Early Warning System (GITEWS) components

HMA in Europe
The European Space Agency and various partner organizations in Europe are collaborating on the Heterogeneous Mission Accessibility (HMA) project. HMA's high-level goals include consolidating earth imaging and other geospatial interoperability requirements; defining interoperable protocols for cataloging, ordering, and mission planning; and addressing interoperability requirements arising from security concerns such as authorization and limiting reuse. HMA involves a number of OGC standards, including the Sensor Planning Service, which supports the feasibility analysis requirements of Spot Image optical satellite missions (Figure 5).

Click for larger image Figure 5. SPS GetFeasibility operation in a single and multiple satellite environment (Click image for larger version)

Access to U.S. Hydrologic Data
The Consortium of Universities for the Advancement of Hydrologic Science Inc. (CUAHSI) is an organization founded to develop cyber-infrastructure to support advanced hydrologic research and education. CUAHSI represents more than 100 U.S. universities and is supported by the U.S. National Science Foundation. Its Hydrologic Information System (HIS) project involves several research universities and the San Diego Supercomputer Center as the technology partner. For three years, the CUAHSI HIS team has been researching, prototyping, and implementing Web services for discovering and accessing different hydrologic data sources, and developing online and desktop applications for managing and exploring hydrologic time series and other hydrologic data.

The core of the HIS design is a collection of WaterOneFlow SOAP services for uniform access to heterogeneous repositories of hydrologic observation data. (SOAP is a protocol for exchanging XML-based messages over computer networks. SOAP forms the foundation layer of the Web services stack, providing a basic messaging framework that more abstract layers can build on.) The services follow a common XML messaging schema named CUAHSI WaterML, which includes constructs for transmitting observation values and time series, as well as observation metadata including information about sites, variables, and networks.

The WaterML specification (Figure 6) is available as an OGC discussion paper (document 07-041). The CUAHSI HIS team is working with OGC to harmonize it with OGC standards such as GML and the OGC Observations and Measurements specification to make the next version of CUAHSI Web services OGC-compliant.

Click for larger image Figure 6. WaterOneFlow Web services will provide a standard mechanism for flow of hydrologic data between hydrologic data servers (databases) and users (Click image for larger version)

Coordination with Other Sensor Standards Efforts
The OGC has an active coordination program with many other standards groups and has been active in the Sensor Standards Harmonization WG (SSHWG) led by the National Institute of Standards and Technology (NIST). The broad challenge of SSHWG is "to integrate sensor and non-sensor data in a decision support network."

The OGC's current major test bed activity, OWS-5, includes a SWE thread designed to leverage the results of OWS-4. In the OWS-5 scenario, SWE is being integrated into realistic enterprise workflow scenarios that include IEEE 1451 sensor arrays.


OGC Sensor Web Enablement Standards

Adopted OpenGIS Specifications:

  • Sensor Model Language (SensorML) —Standard models and XML schema for describing sensors systems and processes; provides information needed for discovery of sensors, location of sensor observations, processing of low-level sensor observations, and listing of sensor system operations that can be invoked by a client process.
  • Transducer Markup Language (TransducerML or TML) —Conceptual model and XML schema for describing transducers and supporting real-time streaming of data to and from sensor systems.
  • Observations & Measurements Schema (O&M) — Standard models and XML schema for encoding observations and measurements from a sensor, both archived and real-time.
  • 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.
  • Sensor Registries —These enable publishing and discovery of sensors and observed values and are implementations of the OpenGIS Catalogue Service Implementation Specification, which has many applications beyond sensor webs.

OGC Best Practices:

  • Sensor Alert Service (SAS) —Standard Web service interface for publishing and subscribing to alerts from sensors.
  • Web Notification Service —Service by which a client may conduct asynchronous dialogues (message interchanges) with one or more other services. Useful in many SWE scenarios, this service also has broad applicability in nonsensor domains.
  • Units of Measure Recommendation —Common semantic for units of measurement to be used across all OGC specifications.
  • Sensor Planning Service Application Profile for EO Sensors —Specifies the interfaces and parameters for earth observation (EO) sensors, for determining the feasibility of an intended planning request, for submitting and managing it, and for requesting information about further OGC Web services that provide access to the EO data collected by the requested task.

OGC Discussion Papers:

  • CUAHSI WaterML —Specifies the WaterML messaging schema implemented in version 1 of WaterOneFlow Web services.
  • Sensor Web Enablement Architecture Document —An overview description of the Sensor Web Enablement (SWE) general architecture.
  • Sensor Observation Service —Standard Web service interface for requesting, filtering, and retrieving observations and sensor system information.






Sensors.tv