Sensors have become embedded physical information servers. Starting from this observation, we may draw insights from the IT community's long-standing efforts to cope with integrating diverse sources of distributed information. Today, every large enterprise, major supply chain, and significant Web portal integrates many different kinds of data sources from physically distributed dynamic processes. They do this by using a software-based service oriented architecture (SOA) built upon a relatively straightforward foundation of Web services. The same lesson can be applied to embedded Web services as a framework for integrating diverse sensor networks.
Three Levels of Embedded Information Integration
The quest to integrate networks of sensors dates back to the 1950s and the development of the 4–20 mA current loop signaling standard for analog sensors. While this standard allows a controller to obtain the current output value from any sensor (by digitizing the voltage across a precision resistor), interpreting that value as a meaningful process variable still requires out-of-band information about the specific transducer, its calibration, and how to correctly operate and control the device.
In general, integrating diverse sources of information takes place at three levels (Figure 1). At the lowest level is the communication medium that allows the exchange of information and control actions. Given such an interconnection, the communicating participants must agree on how information is represented; this middle level is variously called the format, data model, or object model. Finally, for such information exchanges to be useful the participants must have a way to discover what behaviors other devices can perform, and how to cause them to take particular actions; this third level is called service discovery.
 Figure 1. Integrating diverse information sources |
The quest entered its digital chapter in the mid-1980s with the highway addressable remote transducer (HART) standard. HART borrowed a page from the telephony book to provide a 1200 baud serial communication bus over analog 4–20 mA wiring. It fused all three levels by defining a fixed set of transactions (access process variables, set configuration parameters, and perform calibration) with fixed data representation over a particular link.
BACnet began in the early 1990s with a much broader integration goal. It was defined over several standard serial-line and LAN communication links (RS-232, RS-485, ARCNet, Ethernet, and LONTalk), specified 23 standard object types, and represented a device as a collection of objects supporting application-level services (for data sharing, alarm and event management, trending, scheduling, and remote device and network management). BACnet/IP allowed adoption of newer IP-based links, such as Ethernet, but also allowed a BACnet network to be constructed as an application-specific "virtual network" within an IP infrastructure. The representation of all of the data objects that can be sent over BACnet is defined in abstract syntax notation (ASN.1), which is also used for management of IP networking devices with SNMP. To represent intended behaviors, specific device and object definitions are collected into "application profiles."
Common industrial protocol (CIP) emerged in the late 1990s with a more complete object model and a recognition that communication between objects can be defined independently from the physical links that provide transport, starting with DeviceNet and moving to UDP/IP. Devices are physical instances of a class and contain a collection of objects. However, all CIP classes, object types, and data types have fixed 8-bit encodings prespecified in human-readable documents.
The development of IEEE 802.15.4—the IEEE standard for very low power wireless personal area networks (WPAN)—presents a dramatically enhanced opportunity for easier physical integration of diverse devices. Multihop mesh routing is used for robustness and increased range even in harsh, cluttered environments. ZigBee seeks to provide integration at the application level over 802.15.4 by creating application profiles. For example, a ZigBee application profile might describe a thermostat, which has an object representing the current temperature. ZigBee then defines the encoding rules to give this object a concrete representation as a specific set of bytes that can be sent over a ZigBee network. Meanwhile several groups, including Wireless HART and SP100.11a, have begun to incorporate this new wireless link.
Today, most sensors are small chips or circuit elements connected directly to powerful but inexpensive microcontrollers with sophisticated communication links (CMOS radios or wired interfaces). With intelligence and communication connected to every device, it should be easy to integrate them into rich networks.
Web Services
The complexity of defining and using distributed information sources in binary form is not unique to sensors. During this same time period we have seen the automation of order entry, inventory management, process flow, and logistics. While IP-based networks connected all the parts together, information representation and behaviors in the customer's system were always different from those in the vendor's system, and all the databases organized the information differently. The IT community introduced its own collection of complex distributed object systems (e.g., Sun RPC, CORBA, Microsoft's DCOM), each with its own abstract object representation model, interface inquiry protocols, and service-discovery mechanisms.
Integration Breakthrough
All this changed with the Web. Today we routinely experience the sophisticated integration of many different kinds of information sources and processes. Even a single shopping site integrates inventory and availability from many different vendors, order processing, shipping, real-time feeds, shipping, news, alerts, and customized analytics.
Two primary factors sparked the integration breakthrough. The first is a radical simplification at each of our levels. Communication is simplified to transferring sequences of characters between named endpoints on hosts. Information representation is simplified to recognizing nested XML-tagged sections, delimited by <tag> ... </tag> pairs in the sequence, coupled to a machine-readable schema that is also in XML. The set of behaviors is simplified to two: GET and POST a sequence from, or to, a named endpoint. The second factor is consistent application of an SOA, in which applications are built as a protocol- and implementation-independent composition of services.
In Web services, each information source or computational element describes itself in a Web Services Description Language (WSDL) file. As illustrated in Figure 2, a requestor of the service first obtains its WSDL, either directly from the service, as in device discovery, or indirectly from a repository. The WSDL is a complete machine-readable description of the service, revealing how information is represented and what behaviors are provided. It allows the requestor to bind to the provider of the service and establish any necessary translations in a fully automated fashion. Data sharing and behavior invocation are then conducted efficiently through the established service interface. XML and WSDL provide an automated framework for defining objects and operations. The application domain determines the specific objects and operations included in the services.
 Figure 2. Web service discovery, bind, and utilize |
Embedded Web Services
In the realm of wireless sensor networks, can we have the best of both worlds? Can we retain the compact binary representations and finely crafted application profiles that we demand for embedded devices and still have automated service discovery, composition, and the ability to deal with diverse information sources that we expect in enterprise applications?
At the communications level, the binding step between the consumer and the provider of a service provides the mechanism to deal with a diversity of links and protocols. The higher-powered devices are likely to be on IP-based links, such as Ethernet or WiFi, and the binding is simpler if the embedded sensor links also support IP. However, for non-IP embedded links, gateways can participate in the binding step. The only requirement is the ability to name the service endpoint in a consistent manner. In IP this is the IP address and port number. At the HTTP level it is a URL.
At the information representation level, the set of binary objects (e.g., bits, bytes, and integers) used in the exchange is mapped to a set of XML tags, as is the set of composition rules (e.g., struct and array). With this mapping, any binary object that can be represented at the embedded device level can also be represented as an XML document. Embedded devices need not support general XML; they only deal with a compact representation thereof. The WSDL provides sufficient information for gateways, proxies, or applications to perform the translation automatically. For example, the temperature reading 75°F may be represented natively at the embedded device level as an unsigned 16-bit number, and may also be represented as the following XML document: <Value>75</Value>. An XML schema used in the WSDL file specifies a type of unsignedShort for the value in this tag, which matches the 16-bit integer used in the embedded representation.
The application profile is reflected in the objects and methods described in the WSDL for the device. In fact, WSDLs can be defined for existing industrial
 Figure 3. Embedded Web services (Click image for larger version) |
These concepts are illustrated in Figure 3 for Arch Rock's Primer Pack/IP. Primer Pack/IP is an all-in-one platform for developing and deploying wireless sensor network applications that integrate with enterprise infrastructures.
- The communication layer uses IPv6 naming and routing (with 6LoWPAN standard compression) over IEEE 802.15.4. This connects to surrounding corporate networks through routers or gateways.
- Data and objects in the embedded devices and network are represented as a compressed binary form of restricted XML. The role of HART process variables, BACnet properties, and CIP attributes is provided by typed attributes. The particular attributes such as sample rate, threshold, and current value are specific to the application and form the core of the application profile.
- GET and SET methods are defined on attributes, providing basic data acquisition, device and service configuration, and management. Events, alarms or scheduled reporting are POSTed from the embedded service provider to the consumer.
- More complex aspects of the application profile, such as calibration, local data processing, management, and diagnosis, are provided by commands POSTed to the device with an associated set of typed argument and result parameters.
All of the data and objects used in Primer Pack/IP are communicated in compact binary form across the mesh-routed low-power wireless network, but when they cross a gateway or proxy to a more capable network they are translated to their full, self-describing XML form.
Primer Pack/IP goes one step further and provides application development support for embedded Web services. The variable that holds the attribute in the embedded code is annotated so compilation tools can generate the corresponding sections of the WSDL, the XML representation, and all the translations. Similar support is provided for annotating commands and events.
Going Forward
The increasing intelligence, ubiquity, and diversity of sensors have made paramount the need for an interoperable, robust means of communicating with sensors and interpreting their output. Although many industrial standards efforts have approached this problem with complex binary object models working up from the devices, it is likely that the path to ease of integration may follow that of Web services, which employ a fairly simple model from the top down. As both these worlds seek to easily integrate diverse information sources in application-specific ways, it is likely that they will grow more similar.