Part 2 of 2

This article is part two of a two-part series. The first feature, titled "A Business Scan of the Sensor Web", can be read here.

Sensors are pervasive: in space, in the air, on our streets, in our cars, in our homes, in our businesses. One estimate suggests that by 2010 there will be thousands of operational sensors for every human on the planet! At the same time, there is an increasing demand for better real-time information for use in critical economic, environmental, sustainability, traffic, emergency, military and many other applications. Sensors and web-accessible sensor networks can provide much of this information. Therefore, effective and timely integration of sensor observations into business and policy decisions is imperative.

One of the benefits of using sensor data is that the data typically can be re-purposed many times, thereby reducing cost and maximizing benefit. For example, weather observations (temperature, wind speed and direction, humidity and so on) can be used in climate modeling, weather forecasting, plume modeling, insurance risk analysis, ski area location decisions, and dozens of other applications. However, the ability to access and use the same sensors in multiple application domains, to share sensor data, and to maximize the full value of sensor networks and data is severely hindered by a lack of interoperability. Hundreds of sensor manufacturers build sensors for specific purposes, often using their own ‘language’ or encodings, different metadata, and so forth.

Dealing with Sensor Stovepipes

Over five years ago, the Open Geospatial Consortium (OGC) membership recognized the need to enable any sensor or sensor network that is web accessible to be described, discovered, tasked, and accessed in a standard way. We needed to break down the traditional sensor stovepipes and enable interoperability not only within communities but among traditionally disparate communities. For example:

• Different sensor types: stationary, moving or dynamic sensors, full motion video, satellites, and RFID.
• Different phenomenology (observables): temperature, insulation, pollutants, CBRN (Chemical, Biological, Radiological, Nuclear).
• Different disciplines: science, defense, intelligence, emergency management, utilities, etc.
• Different sciences: ocean, atmosphere, land, bio, target recognition, pattern recognition, etc.
• Different constituents: civil and defense government agencies, private, NGO.

Sensor data collected and analyzed is valuable only to the extent that it meets a specific business or organizational objective. Therefore the objectives for defining and standardizing these various sensor categories revolve around the critical abilities to:

The ability to access and use the same sensors in multiple application domains, to share sensor data, and to maximize the full value of sensor networks and data in applications is severely hindered by a lack of interoperability. Hundreds of sensor manufacturers build sensors for specific purposes, often using their own ‘language’ or encodings, different metadata, and so forth.

• Quickly discover sensors and sensor data (secure or public) that can “meet my needs when I need it and where I need it” based on location, observables, quality, ability to task, etc.
• Obtain sensor information in a standard format that is “understandable by my software” and enables assessment and processing without a-priori knowledge.
• Readily access sensor observations in a common manner, and “in a form specific to my needs.”
• Task sensors, when possible, “to meet my specific needs.”
• Subscribe to and receive alerts when a sensor measures a particular phenomenon.

The first step in the OGC standards development process for Sensor Web Enablement (SWE) was to define a vocabulary, or terms and definitions. Very specific terms are used in the sensor producer and user community, such as actuator, phenomenon, observation, measurement, and measure. Agreement on a common vocabulary is the first and perhaps most critical step in creating standards that enable interoperability.¹

For example, the OGC members define sensor as “…an entity that provides information about an observed property at its output. A sensor uses a combination of physical, chemical or biological means in order to estimate the underlying observed property. At the end of the measuring chain electronic devices produce signals to be processed.” The OGC developed the broadest possible definition to encompass every sensing entity ranging from simple temperature change detection to complex remote sensing satellites.²

The Enterprise Connection

The ability to effectively and efficiently integrate sensor data and sensor networks into existing and planned enterprise applications has tremendous business value. From reducing costs, to reducing risk, to improving modeling outputs, sensors will be a critical component in hundreds of business applications. A recent ISO/IEC document describes the roles of sensors in the following markets: logistics and supply chain management; energy and utilities; automation, monitoring, and control of industrial production processes; environmental monitoring and modeling; risk assessment and reduction; emergency services; health and hospitals; public safety; automation and control of commercial building and smart homes; intelligent transportation and traffic; defense and intelligence; asset management; retail, ship and airline monitoring and control; and homeland security. There are probably dozens of other application areas.

The bottom line is that the standards-based integration of sensor data into any application that supports these markets will not only reduce implementation costs, but will ensure the accuracy of integrating multiple data sources and the correlation and analysis of such data – accuracy that will drive operational efficiency, enhance revenue through product and service development, and, most importantly, result in more effective emergency response and improved public health and safety.

Emergency response and remediation scenario

Consider how OGC SWE-enabled Sensor Web capabilities can be integrated into an emergency response and remediation scenario. There is an explosion at a chemical plant and the subsequent burning of toxic materials. A toxic cloud is released into the atmosphere and a dispersion plume forms. A small sampling of the interactions with Web-enabled sensor components could include these scenarios:

1. A chemical sensor (CBRN) detects the release of toxic chemicals into the atmosphere. At the same time a temperature sensor detects a fire. Both sensor systems send alerts to the appropriate jurisdictions. The alerts contain the location of the sensors.
2. An alerted emergency management team immediately uses the information contained in the alert, including location, to generate an initial situational awareness map of the area in which the sensors are located in order to determine the extent and movement of the toxic chemical plume.
3. Using the location of the sensors as a search parameter, an online sensor registry is accessed to discover that a number of in-situ and airborne sensor platforms are available to be accessed, tasked, and so forth. NASA has an airborne sensor capable of providing thermal imaging through smoke and clouds. The team places a request for imagery acquisition through a sensor planning service interface, and within the hour receives notification through a notification service that task is approved and scheduled.
4. At the same time, the registry returns information about weather stations in the area that collect wind speed and direction. The team is able quickly to access these sensors to obtain measurements using a standard interface and feeds the wind, temperature, and humidity data into various plume-modeling applications. The results of the modeling showing the downwind dispersion in time increments is integrated into the situational awareness map. This information is used immediately to prepare an evacuation plan.
5. In the meantime, the team determines that biochemical “sniffers” are available using secure connections. This sensor network is part of the homeland security initiative. The sensor capabilities are queried and it is determined that these sensors are capable of detecting the chemical types in question and have high enough sensitivities to detect probable concen trations. The team requests and subscribes to alerts from these sensors whenever chemical concentrations above a specific value are detected. Notice is sent by email/SMS (Short Message Service) to team personnel and by URL to the plume simulation service for automatic updating and refinement of the model runs.
6. The emergency response team has access to vehicles that contain a variety of mobile sensors.3 These vehicles are deployed to the scene. The new sensor positions are displayed on the situation awareness map and the sensors are tasked to return various observations on a regular basis.
7. In the meantime, the team is alerted that thermal imager observations taken by the NASA UAV are available. The process descriptions allow on-demand geolocation and processing of the thermal data. The geo-registered and classified thermal data are “fused” into the situational awareness map, showing location of main hot spots and the source of main toxic containment. This information allows the first responders to focus their efforts more accurately.
8. Sensors onboard emergency response vehicles allow the EM team to monitor the location of these vehicles only periodically, though some also provide mobile measurement of airborne toxin concentrations. These vehicles can also provide real-time video streams from onboard sensors. Enhancing the video with geolocation allows for real-time hazard assessment and rescue monitoring.

This is, of course, only a single possible scenario of the application of a Sensor Web. Additional scenarios have been created for autonomous Sensor Webs, where sensor systems are capable of subscribing to alerts from other sensors and modifying their own sensing behavior based on these alerts.

Footnotes

(1) The OGC Agreement on terms and definitions is captured in the OGC Sensor Web Architecture Best Practice document.

(2) One could consider a RFID chip/reader combination as a sensor. However, an RFID chip by itself is not a sensor.

(3) Mobile sensor units for use in EM or other intelligence situations are already used by some organizations.