SensorNet is a vendor-neutral interoperability framework for Web-based discovery, access, control, integration, analysis, and visualization of online sensors, sensor-derived data repositories, and sensor-related processing capabilities. In other words, SensorNet attempts to create a wide-area system to collect and analyze data from sensors all over the country to monitor and detect threats, and then alert agencies, emergency responders, and others as necessary. It is being designed and developed by the Computational Sciences and Engineering Division at the Oak Ridge National Laboratory (ORNL), in collaboration with the National Oceanic and Atmospheric Administration (NOAA), the Open Geospatial Consortium (OGC), the National Institute for Standards and Technology (NIST), the Department of Defense, and numerous universities and private-sector partners. The purpose of SensorNet is to provide building blocks for a comprehensive nationwide system for real-time detection, identification, and assessment of chemical, biological, radiological, nuclear, and explosive hazards.



The SensorNet team is developing prototypes to network a variety of sensors for strategic test beds at military installations, traffic control points, and truck weighing stations. The sensor networks are connected by secure and redundant communication channels to local, regional, and national operations centers. These network test beds will provide a basis for interfaces to 911 centers, mass-notification networks, automated predictive plume modeling applications, and evacuation models (see Figure 1).

 Figure 1. SensorNet lays the groundwork for rapid deployment of a nationwide real-time detection system.
Figure 1. SensorNet lays the groundwork for rapid deployment of a nationwide real-time detection system.

From a national security perspective, SensorNet addresses the problem of isolated, custom-designed, single-application sensor networks, incompatible sensor standards, lack of real-time availability of data, and lack of common and consistent schemas for sensor description, control, and data. Homeland security and force protection are areas of particular interest, but the same issues apply in many other public and private sector domains.

Transducer and Application Interfaces

In developing an open standards framework for interoperable sensor networks, there needs to be a universal way to connect two basic interface types—transducer interfaces and application interfaces. Operational specifications for sensor interfaces generally mirror hardware constraints, while specifications for service interfaces are closer to application requirements. The sensor interfaces and application services need to work together and thus may need to be bridged at any of the various locations in the deployment hierarchy.

For the transducer interfaces, SensorNet adopts the methodology advocated by the IEEE 1451 working groups that are developing plug-and-play standards for smart transducers. A transducer is "smart" when it includes sufficient descriptive information to allow control software to automatically determine the transducer's operating parameters, decode its electronic data sheet, and issue commands to read and actuate the transducer. The IEEE 1451 standard data sheet encoding scheme is critical. In the past, when each transducer had a separate and nonstandard data sheet, it was necessary to write custom software to talk to each transducer.

For application interfaces, SensorNet builds on Web services. Although control granularity and latency constraints preclude the use of Web services for some end-to-end control tasks, SensorNet uses them for most interactions including user-directed control. Web-resident service directories and data dictionaries provide consistent terminology so application services can work together.

The Geospatial Component

For a system such as this, it is important to know the location of every sensor and measurement, so geospatial standards are an integral part of the interoperability framework. The SensorNet team has adopted service specifications developed by the OGC because OGC's sensor interface standards approach is compatible with ORNL's service-oriented national architecture. In 2004 ORNL joined the OGC to support its Sensor Web Enablement (SWE) interoperability standards effort to ensure that SWE standards align with SensorNet requirements. SWE envisions Web-accessible sensors with discoverable sensors and sensor data; sensors will be self-describing to humans and software (using a standard encoding), and most sensor observations will be easily accessible in a timely fashion over the Web. The SWE framework involves several OGC encoding and service specifications designed for general geospatial uses as well as schema and service specifications that are specifically sensor related.

For example, OGC's SensorML describes models and schema for describing sensor characteristics, and OGC's Observations & Measurements (O&M) provides models and schema for encoding sensor observations. The Sensor Observation Service specifies access to sensor information encoded in SensorML and sensor observations encoded in O&M, while Sensor Planning Service specifies a service to task sensors or sensor systems. (None of these standards has yet been completed or adopted by the OGC membership.)

ORNL is serving as the catalyst for bridging the SensorML and IEEE P1451 standards, as well as helping develop an OGC Sensor Alert Service through the use of existing standards, particularly the OASIS Common Alerting Protocol (CAP).

The SensorNet Node

SensorNet developers placed the implementation middleware for bridging and interoperability in the SensorNet node to ensure localized sensor control while at the same time providing remote users and applications access to lower-frequency application-level messages.

Since it often doesn't make sense to connect a transducer directly to the Internet, the SensorNet node addresses the common situation where a computer must manage those higher-layer services that provide remote access to a locality's sensors and actuators; this situation can be due to cost, size, legacy proprietary interfaces, or real-time latency constraints. The node provides the last-mile intelligence functions (e.g., control, cache, management) needed in a wide-area sensor network. The ORNL team prototyped the node using commercially available products.

Figure 2 shows how nodes fit into the SensorNet architecture. Nodes connect to sensors and collect data from them. These sensors could also be soft sensors, i.e., the node may simply be a software actor at the site of a source of stored data. The distance between sensors and node varies from a few feet to a few thousand feet. Collected data may be preprocessed at the node before they are passed into the central infrastructure.

Figure 2. This diagram shows node-related architecture components. Nodes act as gateways to sensors. Data are stored in similarly configured servers to enable information sharing.
Figure 2. This diagram shows node-related architecture components. Nodes act as gateways to sensors. Data are stored in similarly configured servers to enable information sharing.

A deployment comprises a collection of regional data repositories along with their accompanying services serving regional applications. The data repositories use Web-based services to share information with regional peers. Directed by applications, services at the regional data centers instruct collector software within the node to collect sensor data periodically. Application services may also directly interact with the node, e.g., if shorter turnaround times are needed to actuate transducers.

Sensor Interface

IEEE 1451 working groups have been defining communication protocols for different hardware media (1451.2 point-to-point asynchronous, 1451.3 bus-based, 1451.4 analog, and 1451.5 wireless) and have proposed an object-based protocol (1451.1) to make sensors accessible to clients over a network.

A principal contribution of the 1451 groups is the idea of Transducer Electronic Data Sheets (TEDS). The TEDS bundled with the transducer encapsulates the transducer identification, command set, data formats, units, status, etc., so that the control software can autonomously read and actuate the transducer, and thus support plug-and-play connectivity. A transducer-resident smart transducer interface module (STIM) controls a set of channels, each of which corresponds to one source of measurement or actuation. The 1451.1 standard lays out a card bus–based model to include sensor functionality and connectivity within a Network-Capable Application Processor (NCAP). Consumers access the transducer functionality via a set of exposed ports and operations defined in an interface definition language but implemented in the NCAP's vendor-specific implementation language. The 1451.1 standard does not mandate mechanisms to publish the NCAP's capabilities to consumers. Since the sensors in current deployments do not have built-in TEDS at this time, the node emulates their behavior using software wrappers. This allows SensorNet developers to subsequently move the wrappers into the sensor while retaining the interface portions of the code.

Node Server

Web services provide applications access to transducers. The node contains a Web server, shown in the upper right corner of Figure 3, which supports a container for programs to process sensor data locally. Filtering, averaging, and data-validation functions are performed within this server, as is intelligent processing for activities such as image recognition. Basic service APIs used by the node server include identity management, registration (of TEDS and sensor capabilities), data submission, and services for sensor control (configure/ dynamically reconfigure/start/stop), and task instantiation. To track sensor state and data with contextual information, an application can capture spatial and temporal features of sensor data. The Web service interfaces use XML schema-based formats to publish sensor data, enact alerts, and expose service capabilities. Critical services outside the data and control plane, such as security and network management, are also a part of the server.

Figure 3. The node prototype includes components to communicate with sensors through standard interfaces, reliably store and transmit data, and support local processing.
Figure 3. The node prototype includes components to communicate with sensors through standard interfaces, reliably store and transmit data, and support local processing.

Feature Representation

A fundamental unit in SensorNet data messages is the feature, a descriptive container for almost all data and sensor entities. Each data entity submitted, stored, and operated upon, and each physical entity (e.g., node platforms, sensors) in the infrastructure has a feature type associated with it.

Each feature type has one or more data genres associated with it, e.g., attributes such as wind, gamma counts, and concentration are associated with data genres such as met, rad, and chem. These data genres are used in classifying and storing data within the SensorNet regional data centers. SensorNet includes a list of known feature types beginning with a constant snet prefix, such as snet:Feature (associated with all features), snet:node, snet:SensorType, and snet:Drawable. Data suppliers may provide custom feature types.

The features are organized hierarchically and stored in an application-accessible directory. A dictionary contains the mapping between terms and features so that applications can correlate them in meaning and operate across data sets. Features are encoded in Geography Markup Language (GML), the OGC open-standard encoding for geospatial data. The data themselves are encoded in OGC's O&M schema. OGC Observations are semantic objects consisting of measurements at a location. Features may also carry references to the dictionary (in some cases, using the xlink:href XML schema reference mechanism).

Feature Transport and Access

To facilitate passage of feature data between clients and servers, OGC developed the Web Feature Service (WFS) interface specification. This specification describes request and response documents for Web services and uses HTTP as the distributed messaging mechanism for creating or modifying feature instances and for storing and querying features. SensorNet provides a WFS interface for access to node, sensor, and O&M data. The SensorNet nodes use transactional WFS services to insert and update O&M data at the regional data center. WFS transactions are only accepted from known data suppliers, each identified by a unique data source ID.

Figure 4. This packet snippet illustrates a Web Feature Service (WFS) query for data.
Figure 4. This packet snippet illustrates a Web Feature Service (WFS) query for data.

WFS transactions support a rich query language. Applications make a series of queries to obtain data of interest. The XML snippet in Figure 4 gives an example of a search query made to a regional data center to retrieve a specific node's information, given its name and location.

The query searches for a node satisfying a nodeID and a spatial constraint. The returned set of features is packaged in a generic feature collection (see Figure 5) enclosing the result features.

Figure 5. This packet snippet illustrates the WFS query response.
Figure 5. This packet snippet illustrates the WFS query response.

The Role of Prototyping

ORNL has created prototype nodes and test beds with commercially available hardware and software. Test beds exercise different kinds of queries for different kinds of applications and help answer questions such as what services need to exist, how to store the data, and how to parse a SensorML document to get real-time performance.

In other activities, the Directorate of Emergency Services, Fort Bragg, NC, is working with ORNL to establish a next-generation public safety answering point (a generic term for systems such as 911) with integrated sensor management capability. Intergraph Corp. is developing a consolidated E.911 emergency dispatch system for Fort Bragg capable of interconnecting emergency alerts, critical data, and predictions of potential incidents to E.911 centers. Sensor types range from fire alarms to anti-intrusion sensors on arms rooms to NOAA and PM GUARDIAN sensors.

The Memphis Operational SensorNet Testbed, funded by the U.S. Department of Homeland Security, is an industry test bed that will "leave behind" deployed capabilities for protecting chemical facilities and surrounding communities.

ORNL is participating in the OGC Web Services Phase 3 (OWS-3) test bed, which begins April 22, 2005. One OWS-3 aim is to extend the SWE architecture to access a variety of sensor types and to achieve scalability for nationwide sensor deployment. OWS-3 will focus on developing methods to make sensor descriptions in the hardware-oriented IEEE 1451 available in Web-oriented SensorML. The work will also address TransducerML.

SensorNet Status, Schedule, and Needs

Current prototypes are bringing data into the SensorNet data repository. These are currently being improved and tested at sites such as Fort Bragg, the Port of Memphis, and the Watt Road weigh station in Knoxville, TN. Over the next two to three years the team will be demonstrating the integrated system. The basic standards requirements and research agenda are clear from the work that has been done, but it will take continued effort to fill in the details.

SensorNet will succeed when vendors adopt the standards initiatives outlined earlier and when those vendors' products are deployed in government and industry programs related to security and disaster management. Developing the standards is the first step, but then customers must create a market for these technologies. Program managers tend to recognize that a standards-based approach that fosters interoperability will best anticipate their future needs. Sensor manufacturers see the need for a plug-and-play approach and understand its benefits. However, both groups need a clear adoption path to follow and need to see market indicators signaling that the standards framework will meet future needs and result in an expanded market. Task forces, community efforts, and standards-requiring procurement language can play important roles.

Developing these technologies promises to enhance market opportunities and protection while also benefiting other applications, such as weather analysis and prediction, traffic control, aircraft surveillance, inventory tracking, earthquake monitoring, and environmental management worldwide. The organizations that are building SensorNet hope to see increased participation in OGC by the world's sensor users and providers.

ORNL will be a major sponsor of the OGC's Emerging Technology Summit on SWE (www.gita.org/events/ets/iii), to be held in the Washington, DC, area, April 14–15, 2005.

Bryan L. Gorman, Mallikarjun Shankar, and Cyrus M. Smith are members of the research staff in the Computational Sciences and Engineering Div., Oak Ridge National Laboratory, Oak Ridge, TN; [email protected], www.sensornet.gov.