Unifying Isolated Sensor Systems Using Web 2.0 and Open Standards

Oak Ridge National Laboratory (ORNL) has been actively involved in research to formalize the engineering principles and best practices behind emerging Web 2.0 concepts. These concepts are used to solve real-time data-sharing problems for national security and defense, public health and safety, environmental and infrastructure awareness, and emergency preparedness and response. The popularity of Web 2.0 and social media sometimes disguises the profound change that is occurring in the way we share information. The emergence of social media, in particular, signifies a major democratization of the way we get and share information.

As the use of Web sites such as Facebook, YouTube, Wikipedia, and Twitter grows, first responders, public safety officials, and researchers are implementing their own homegrown solutions using these social networking Web sites to share data and collaborate with other users. For example:

  • Firefighters used YouTube, Twitter, and Google Maps "mashups" to track the progress of containing the California wildfires.
  • Wikipedia was used by students to collect eyewitness reports and document incidents surrounding the Virginia Tech massacre.
  • Police departments have captured fugitives after placing their "Most Wanted" information on YouTube.
  • One of the first images of US Airways flight 1549 in the Hudson River came from a citizen journalist using his iPhone to post a photo on Twitter.

These innovative solutions—and many more like them—give great insight as to how Web 2.0 and social networking tools can be used to solve real problems. What is it about sites like Facebook and Twitter that encourages users to share information? Can we apply these same principles to other information-sharing systems to better enable data sharing and collaboration?

Introducing Sensorpedia
Sensorpedia, a program developed at Oak Ridge National Laboratory, enables individuals, communities, and enterprises to share, find, and use sensor data online. Instead of networking users based on mutual personal interests, Sensorpedia networks users based on mutual sensor information interests. Sensorpedia applies several design principles common to many popular Web 2.0 sites:

  • Use of a URL as the common denominator for referencing specific pieces of data
  • Access control based on social networking and groups of trusted users
  • A flexible tag-based classification scheme in place of a fixed hierarchy of information
  • Simple Application Programming Interface (API) supporting the creation of data "mashups" from multiple data sources
  • Publish-subscribe mechanism enabling automated notification of data updates

Sensorpedia is a Web-based application (Figure 1) consisting of a Google Maps interface where users can search and explore published sensor data. The interface is designed to be simple and intuitive to use. However, the real power of Sensorpedia is in the back-end services. The Sensorpedia API uses Web services designed to accept and publish data using established standards such as the Atom Syndication Format and GeoRSS (Figure 2). The API supports rapid development of customized third-party applications to meet specific needs users may have. Sensorpedia also relies on open data portability standards such as OpenSocial, OpenID, and OAuth to ensure current and future interoperability with other Web-based software applications.


Click image for larger version
Figure 1. Sensorpedia allows users to access published sensor data through a Web-based interface  (Click image for larger version)


Figure 2. Sensorpedia Web services accept and publish sensor data using established standards
Figure 2. Sensorpedia Web services accept and publish sensor data using established standards


Sensorpedia is currently in limited beta testing, but a sneak peek is available online at the Sensorpedia Web site. There are currently over 5000 individual sensors and data sources registered within the Sensorpedia framework. Sensorpedia contains a variety of sensor information; the tag cloud in Figure 3 gives an idea of what types of data users can find. Much of the data is weather related, coming from International Civil Aviation Organization (ICAO) and National Oceanic and Atmospheric Administration (NOAA) weather stations and buoys. Sensorpedia also has a number of feeds from traffic cameras located around the Southeast, including a concentration of cameras in Charleston, SC (thus its prominence in the tag cloud). Other important sensor types monitor seismic activity, energy efficiency, and water levels. Then there are the more obscure sensors like those used for monitoring the bacteria level at beaches. The greatest concentration of sensors is still in the United States, but several sensor systems are also included from Europe, Asia, and other parts of the world.


Figure 3. The tag cloud, generated using Wordle, shows the tags applied to the data, highlighting the range of data types available
Figure 3. The tag cloud, generated using Wordle, shows the tags applied to the data, highlighting the range of data types available


The loosely coupled Sensorpedia architecture is designed to support a variety of sensor types and formats. Sensorpedia does not force data publishers to use any particular data representation. Currently integrated sensors use GeoRSS, OGC KML (formerly Google Earth Keyhole Markup Language), HTML, plain text, and even proprietary binary formats. But in addition to supporting these ad hoc and proprietary data formats, it's also important that Sensorpedia interfaces easily with standards-based sensor systems, such as those defined by the Open Geospatial Consortium, Inc (OGC). The OGC Sensor Web Enablement (SWE) initiative is one such framework of open standards for designing interoperable systems. The suite of standards within SWE includes both encodings for describing sensors and sensor observations, and standard interface definitions for Web services.

Northrop Grumman has developed one such sensor Web framework, PULSENet, that implements an OGC SWE-based architecture. Similar to Sensorpedia, the objective of PULSENet is to provide a standards-based framework for the discovery, access, use, and control of heterogeneous sensors, their metadata, and their observation data. PULSENet uses a combination of open-source SWE code, commercial off-the-shelf (COTS) products, and custom development to construct a framework that provides an adaptive and flexible environment for integrating sensors without requiring its users to necessarily understand and be exposed to the OGC SWE standards. Neither Sensorpedia nor PULSENet is intended to be a centralized, stand-alone sensor Web system, but each serves an intermediary role with other sensor, processing, and decision support systems. The two systems are complementary in enabling both standards-based "down stream" components in workflows, such as processing services or existing data analysis and exploitation systems, as well as more ad hoc data "mashups" made popular by applications such as Google Maps. To date, PULSENet has been applied to a range of applications spanning the environmental, defense, and intelligence domains.

Interfacing Existing Systems with Sensorpedia
Substantial effort is ongoing to harmonize OGC SWE with other sensor-related standards. Realizing the importance of accommodating both legacy and non-SWE standards-based sensors in a sensor web system, Northrop Grumman and Oak Ridge National Laboratory worked to develop a tool for interfacing SWE systems with Sensorpedia. Using this translator tool, registering one or more SWE sensor systems with Sensorpedia is a simple process, as shown in Figure 4.


Figure 4. The translator tool enables simplified registration of SWE-compliant sensor systems with Sensorpedia
Figure 4. The translator tool enables simplified registration of SWE-compliant sensor systems with Sensorpedia


The initial translator implementation supports only the OGC Sensor Observation Service (SOS) Interface Standard, which provides an open API for accessing deployed sensors and retrieving data about sensors and from sensors. Given an SOS URL, the translator performs an SOS GetCapabilities request to obtain information about the SOS and the sensors that it offers. The translator then generates a Sensorpedia Atom feed from the information provided in the returned Capabilities document using eXtensible Stylesheet Language Transformations (XSLT). For each sensor described in the SOS Capabilities document, the translator issues a DescribeSensor request to the SOS to retrieve OGC Sensor Model Language (SensorML) Encoding Standard formatted sensor-specific metadata. Using these SensorML descriptions along with XSLT, the translator generates Sensorpedia entry elements and adds these elements to the feed to represent each individual sensor. The translator then submits the completed Atom feed to Sensorpedia for registration. Figure 5 illustrates this interaction. All of these actions are performed automatically for the user without having to understand the underlying mappings between SWE and Sensorpedia.


Figure 5. The translator tool maps existing sensor information into Sensorpedia formats
Figure 5. The translator tool maps existing sensor information into Sensorpedia formats


The SWE/Sensorpedia translation tool is still a work-in-progress. The current implementation has been tested against Northrop Grumman PULSENet SOS instances and some National Oceanic and Atmospheric Administration (NOAA) and oceans community SOS services. Some SWE services result in large Sensorpedia registration documents (e.g., the feed generated for an SOS with 2000 weather stations is 18 MB in size). The Sensorpedia services and UI may need to be optimized to handle such large sensor systems. Future versions of the translation tool will also support the OGC Sensor Planning Service (SPS) Interface Standard and other OGC SWE standards.

The Future of Sensor Web Systems
The Sensorpedia and OGC SWE communities are mutually beneficial to one another and developing the translation tool described above is the first step in realizing these benefits. In the future, Sensorpedia can serve as a simple, user-friendly catalog/registry of available SWE services and sensors. Because of its low barrier to entry, Sensorpedia can also provide a great avenue for promoting the use and benefits of SWE to the larger sensor community. The standard Web services and encodings provided by the OGC's SWE initiative enable many additional sensors to be published to Sensorpedia in an automated way and made readily available to a large audience. Since the SWE services provide standard, comprehensive sensor information, sensor feeds derived from SWE services can be presented to Sensorpedia users in a consistent manner and will often contain very detailed and useful information.

It is critical that the sensor community moves away from the use of isolated sensor webs that are only accessible by disparate and proprietary interfaces. Interoperability is essential to capture and analyze sensor data on a global, national, state, or even smaller scale. Sensor data, as with other intelligence, has even higher value when it can be fused with data from multiple sources. Open standards-based systems such as PULSENet go a long way toward addressing these capability gaps. However, to take full advantage of the available sensor data on the Web, systems must also be able to exploit legacy, ad hoc, and unstructured data as well. Sensorpedia formalizes the use of successful design principles and technologies used in Web 2.0 and social networking sites to bridge the gap between these two worlds.

This research was partially funded by the Department of Homeland Security-sponsored Southeast Region Research Initiative (SERRI) at Oak Ridge National Laboratory (ORNL), managed by UT-Battelle, LLC for the U. S. Department of Energy under Contract No. DE-AC05-00OR22725. Accordingly, the U.S. Government retains a nonexclusive, royalty-free license to publish or reproduce the published form of this contribution, or allow others to do so, for U.S. Government purposes.

PULSENet is a registered trademark of Northrop Grumman.

ABOUT THE AUTHORS David Resseguie, Computer and Information Research Scientist, Oak Ridge National Laboratory, Oak Ridge, TN, may be contacted at [email protected].

Scott Fairgrieve, Web Software Developer, Northrop Grumman, Chantilly, VA, may be contacted at [email protected].