The Big Picture: Sensor Webs in Disaster Response Demo

In an increasingly wired world, knitting together data from disparate sources into an interoperable whole can present disaster managers and first responders with critical information during a major emergency or crisis.

Figure 1. The OGC's Sensor Web Enablement (SWE) standards enable any kind of sensor system to be deployed on the Web in a way that makes the sensors discoverable and useable through open standard interfaces (Figure courtesy of the OGC)

Countless sensors and security cameras are deployed in cities and major facilities such as ports and airports around the world. In many cases, owners of these sensors and cameras are making the systems accessible via the Web. By implementing standards in the devices' Web interfaces, disaster managers and first responders can then find and use these devices in a crisis (Figure 1).

Setting the Scene
In the demonstration's fictional scenario, an unknown adversary smuggles a radiological dispersal device, or “dirty bomb,” containing shielded cesium 137 inside a shipping container. When it arrives in this country by freighter at Port Newark, NJ, the bomb explodes as the container is being unloaded, releasing the highly toxic radioactive cesium. The explosion injures workers and starts a fire that spreads to other damaged containers. A wind-borne plume of radioactivity begins to drift across the metropolitan region.

Figure 2. OWS-4 showed how diverse kinds of sensors can be found on the Web, evaluated, and controlled, sometimes in a thoroughly automated fashion

In this demonstration, sensor webs played an important role in the scenario, both by alerting emergency authorities to the event and helping them assess the damage and plan their response. The sensor webs rely on OGC's Sensor Web Enablement (SWE) specifications as well as specifications for access to map images and raster and vector data. The demonstration showed geospatial Web services invoking other geospatial Web services (“service chaining”) and it showed working prototypes of geospatial digital rights management (GeoDRM) specifications that are being developed in the OGC. This standards framework facilitated the flow of information from many different data sources, through Web services, to many users of the data (Figure 2). OGC members participating in the demonstration used live, off-the-shelf, standards-based systems to show how decision makers can quickly find, access, and integrate information from diverse geospatial and sensor resources on the Web.

Sensors in the OWS-4 Demo Scenario
OGC's Sensor Web Enablement specifications make it possible to use a standards-based online catalog to publish information about devices as diverse as radiation counters, anemometers, security cameras, and NASA imaging satellites. These standards also provide the “hooks” to control sensor and camera platform motion and data collection. The standards are comprehensive enough to work with IEEE smart sensor systems as well as provide for all of the motion control associated with complex Earth imaging satellites (sidebar “The SWE Standards Framework”).

In the OGC Web Services, Phase 4 (OWS-4) demonstration, a radiological sensor located at Port Newark reaches its alarm level and sends automatic notification to a regional Emergency Operations Center (EOC). This step uses an implementation of the OGC's OpenGIS sensor alert service (SAS) specification. The EOC operator investigates the source of the radiological alarm, records its latitude and longitude, and investigates the radiological alarm condition to determine its accuracy and reading. While the operator is checking the radiation sensor alarm condition, a motion sensor reports activity in the vicinity of the radiation sensor.

The operator queries a catalog for a map of the area and adds the sensors' locations (sidebar “Sensors Integrated in the SWE Demo Network”) to a map display. This uses implementations of the OGC's OpenGIS Catalog Services—Web (CSW) and OpenGIS Web Mapping Service (WMS) specifications. The operator finds that a video camera is located in the area and points the camera toward the location of the sensor where the fire and the damage from the blast are visible.

Meanwhile, the automated alert has also been received by a servlet that initiates construction of a plume model, using the OpenGIS sensor planning service specification (SPS). Web-based integration of live sensor data in computer simulation and modeling is a high priority for several of the OWS-4 sponsors (sidebar “OWS-4 Sponsors”).

The operator calls an analyst who, knowing the location of the event and having access to the online catalog of spatial data, discovers recent, high-resolution imagery of the affected area using CSW and WMS.

Anticipating the need for real-time weather information, the analyst accesses NASA's Earth Observing-1 (EO-1) satellite ground system, instructing the satellite through an open SPS interface to provide images of the New York/New Jersey area over the next several days. (This real acquisition request was in fact accepted by the EO-1 planning systems and the image was acquired on December 8, 2006, during the OWS-4 demonstration.) The analyst further builds up the regional weather view using Doppler radar and GOES satellite data, using the sensor observation service and Web coverage service (WCS) specifications.

The analyst receives notice—using the Web Notification Service specification (WNS)—that the plume model is ready. The analyst is able to view plume projections for each of the next 24 hours, using an implementation of the Sensor Observation Service (SOS). Evaluating the impact of these regional weather and environmental observations, the analyst writes up an atmospheric conditions assessment and submits it, with the plume image series, to the EOC director.

Figure 3. Online sensors near the event site

Having established a “common operating picture” map display—including icons with information drop-downs for sensors in the incident area and for video display pop-ups from cameras in the area (Figure 3)—the operator can provide this resource to others to support coordination and collaboration with regional agencies during the emergency response.

Another analyst looks at data from various sources to find a site for a temporary field hospital and decontamination unit, using an application that implements the Web coverage service (WCS) standard with “JPIP” image streaming capability. JPIP is a JPEG streaming specification developed in OWS-4. The JPIP streaming client zooms within the image to show more details of candidate sites. Potentially suitable buildings for the temporary hospital are found at a nearby airport.

In addition to the emphasis on SWE, the OWS-4 test bed resulted in other technological advances, including GeoDRM. The OWS-4 GeoDRM thread focused on identity-based access control and licensing. The use cases demonstrated a click-through license, triggered automatically; “cascaded” data layers under different distributor licenses and user licenses; an authenticated end-user license; and a license to update features.

SWE in Action
Capabilities similar to those shown in the OWS-4 demonstration (sidebar “OSW-4 Participants”) have been provided in the past by integrators using mainly proprietary or custom interfaces and encodings to provide “tightly coupled” distributed systems. The demonstration showed how it is now possible and practical to build a much more scalable system using distributed, heterogeneous, “loosely coupled” components that implement open interfaces and encodings. The new service oriented architecture (SOA) is much cheaper to implement and requires less project management and less coordination among the users of the distributed resources. The main requirement for all is that they put their resources on the Internet and make them discoverable and accessible through components that implement open schemas and interfaces. Weather-event warning, monitoring of driving habits, climate research, property tagging and tracking, plant operation and security, equipment monitors, motion detectors, and energy efficiency devices can all be made more effective through use of the SWE standards.

Additional Resources
The OGC is producing an OWS-4 video and is making it available to the public in early 2007. This video will be similar to the OWS-3 demonstration available at http://www.opengeospatial.org/pub/www/ows3/index.html

For an explanation of the SensorNet project, please read “Advancing Sensor Web Interoperability,” which appeared in the April 2005 issue of Sensors. http://www.sensorsmag.com/sensors/article/articleDetail.jsp?id=185897

Sam Bacharach can be reached at the Open Geospatial Consortium (OGC) Inc., Wayland, MA; 703-707-0261, sbacharach@opengeospatial.org, www.opengeospatial.org.

• Home
• News
• E-Mail Newsletters
  • Subscribe to e-mail newsletters
  • Newsletter Archives
• White Paper Library
• Sensors TV
• Opinion
  • Sensors Insights
  • Mel's Picks
  • Older Departments
• Technical Articles
  • Tutorials
  • Technologies in Depth
  • Case Studies
  • Intelligent Systems
• Inside Sensors
  • About Us
  • Sensors News
  • Sensors TV
  • White Paper Library
  • Sensors Expo
  • Resources
  • Contact Us
  • Award Program
  • Events Calendar
  • Discussion Forum
  • Media Kit
  • Advertising
• Browse by Topic
  • Sensor Type
  • New Products
  • Tutorials
  • Technology in Depth Articles
  • Case Studies
  • DA & Control
  • Industrial Networking
  • Archives
• Sensors Expo