In Boeing's Seattle engineering laboratories, a sheet of networked sensors covering a wing provides a profile of stress patterns as the structural integrity of the wing is tested. In Austin, a developer downloads a new Java applet that provides a fuzzy logic control algorithm for an actuator in a plant in Beijing. In Holland, a warning light blinks on the dashboard of a tractor-trailer as temperature and pressure sensors in the tire stem radio a problem with a trailer axle.

Far-fetched scenarios? On the contrary, these are examples of smart sensing and control technologies that are actually being deployed. All embody a convergence of key technologies that promise the sensor market will experience incredible change in the next five years. The development of sensor networking technology has been driven by advances in sensing and computation, and these technologies have been integrated by innovations in communications. The infusion and maturation of these technologies is moving sensor networks to the next generation.

The Next Generation
Over the past few generations, networking technology has edged out of the purely networking arena to support the needs of the application more closely. Just as the microcontroller packaged the microprocessor with common peripherals, today's networks are being enhanced with their equivalents of application-level functionality. Sensor networking technology development has climbed the layers of the ISO architecture, and the focus of the future is above the ISO model, in Layer 8—the application.

Today, you can find more than 60 different sensor network protocols geared for a broad spectrum of industries, providing varying degrees of functionality and success. With the maturation of networking technology, you can choose any one of a half dozen protocols to build a networked sensor application. The choice of which protocol to use is not dictated so much by the technical features of the protocol as by other considerations, such as the protocols' compatibility with a particular network technology or the availability of an application or software package with that technology. The problem you will face in the near future is not going to be which network to choose, but how to cost-effectively support multiple networks.

Many people are beginning to recognize that sensor networking choices are strategic decisions. Companies will change from traditional point-to-point wiring to less expensive multidrop cabling, realizing that distributed intelligence at end nodes provides greater flexibility and modularity. But most people will be unwilling to pay for network integration. The challenge for the sensor industry will be to find ways of dealing with competing, functionally overlapping network technologies.

Handling the Proliferation of Networking Technology
In the next few years, you can expect to see the deployment of four complementary technological approaches that will address the problem created by the proliferation of networking technology.

Catalog and Standardize. The first approach is based on cataloging and standardizing functionality. Almost without exception, each networking technology is supported by a group that attempts to define standard combinations of functionality to allow devices to interoperate with each other. Implementers must ensure that their products conform to one of the specified combinations of functionality. The specification is called a profile, and the verification that a device fits a profile is called conformance testing. Although this approach produces a measure of usability, it does not reduce the work involved in supporting multiple networks.

Over the next two years, you can expect to see several formal standardization efforts take this route. The best example of this is the work that is going on within NEMA to develop standard profiles for devices across a range of networks. To support this effort, NEMA has adopted a machine-readable syntax that can be used to specify profiles and extensions.

Describe and Use. The second approach asserts that what is needed is not so much a catalog of standard parts (which is often out of date and incomplete) but a way of describing a part so that it can be used, regardless of whether it has been cataloged or not.

The Fieldbus Foundation is implementing this approach using an enhanced version of the HART Device Description Language. This breakthrough development was a key factor in making HART the process industry's most prevalent smart field device protocol. The Device Description Language has a richer expressive capability than the NEMA syntax specification. It allows for the definition of relationships between variables and data, supports a subset of the C programming language as a way of describing standard actions and behavior, and supports menu structures for simple man-machine interfaces (MMIs). Applications can support off-the-shelf sensors and actuators through on-line processing of device descriptions written in the HART Device Description Language.

Standardize the Application. The third approach came out of the ongoing standardization effort for programmable controllers, IEC 1131 Part 3, which attempts to provide a standard set of programming languages for applications. The committee hopes that the use of such standard languages will make program code portable from one device to another.

Extension of this concept to deal with different network technologies is being discussed in Part 5 of the specification. By developing mappings to different networks for the communication primitives in the language, you could move the application from one network platform to another.

IEC 1131-3 and IEC 1131-5, however, carry a burden of perspective on the problem that will make achieving success at the sensor networking level difficult. The specifications attempt to define a level of internal detail that regulates deep into the architecture of the device, making it difficult to meet the specifications without implementing only the architecture implied by their model (see Kenneth C. Crater, "When Technology Standards Become Counterproductive). This technology will be superseded by the technology of the Internet.

The Object Model-Based Sensor Network
The fourth approach is based on object-oriented design principles that ensure interoperability while leaving open details of implementation. A number of network designs (e.g., DeviceNet and the Smart Distributed System) incorporate some of these concepts in their specifications.

Two years ago, participants in the IEEE TC-9/ NIST Workshops on Smart Transducer Interface Standards recognized that sensor vendors would have to deal with multiple device-level networks. Two approaches that promise to address this are being developed within IEEE P1451, which grew out of the IEEE/NIST workshops. The first (specified in IEEE P1451.2) makes the sensor independent of the microprocessor to which it is attached by specifying a digital interface and digital data sheet stored on the sensor. This would allow any sensor to be connected to any network-connected device.

The second approach, specified in IEEE P1451.1, makes a smart sensor (i.e., a sensor and microprocessor) independent of the protocol used on the network. This approach is significant because it builds on top of networking technology to provide a higher level of abstraction for application-to-application communication. Based on a distributed object model for sensor networks, the approach allows a common, extensible object model for smart sensor and actuator applications to be built across a range of networking technology. The idea is similar to that of writing a word processing program that must be able to print under an operating system such as Windows. The application deals with the printer at a high level of abstraction, and by loading the appropriate printer driver, the application can print on different kinds of printers with no changes to the application itself.

By using an object model, the IEEE also developed a class hierarchy structure for the components of the model. This provides a consistent organization and taxonomy for component types that are defined. The model enables an organization to develop profiles or catalogues but does not define them itself. Similar but more application area­p;specific ideas have also been developed in SEMI projects for the semiconductor manufacturing industry.

The Transition to Truly Integrated Smart Sensing and Actuation
The increased availability of communications and networking systems (both wired and wireless) and the demand for ubiquitous communications is likely to bring about a crossing over of price and functionality between sensor networking technology and communications technology. For example, Ethernet is a cost-effective communications medium for distributed I/O, and it is rapidly moving into sensing applications (e.g., the test and instrument area). In addition, low-power wireless communications technology will make it possible to overcome the need to wire in key applications.

The growing dissemination and use of World Wide Web browsers and Sun's Java programming language will also have a significant impact on sensor networking. The browsers provide a universal graphical user interface (GUI) and are becoming standard tools in many organizations. The reach of these browsers is complemented by their support of the Java programming language, which can help implement sharing and distribution of functionality across a network. Although usually perceived as a technology to animate web pages or to develop portable client applications, Java was designed to be a portable, clean, object-oriented language for small embedded systems. Java is network-aware (TCP/IP) and provides support for dynamically downloadable code, as well as for communication between applications.

Java has caught the eye of embedded system developers as a development language and execution environment, ideal for distributed applications. It is being pursued as an object-oriented, multiplatform language, and adoption of the technology is growing. Corresponding changes to base networking technology are also taking place, with support for TCP/IP, on-the-fly HTTP, and file-transfer protocols making their way onto the Ethernet chip.

The combination of browser- and Java-based systems has tremendous benefits for integration of networked sensor applications into the enterprise. The good match between Java and sensor networking applications means browser- and Java-based technology will migrate to sensor networking applications much as other communications technologies have. Using an architectural model such as IEEE P1451.1 for smart sensors, implemented in Java and supported on Ethernet, is exactly what is needed at the sensor networking level to enable the integration of smart sensing and actuation.

Conclusion
The shape of the next generation of sensor networks will be decided by a race between current sensor networking technologies pushing upward and Internet networking technology pushing downward. The question is, will the combination of a browser's universal GUI and Ethernet win out over traditional MMI packages and device networks, or will a blend of the best of both worlds move sensor networks forward and integrate smart sensing and actuation from the sensor to the boardroom? The next few years will tell.

Three Generations of Sensor Networks The evolution of sensor networks has been fueled by technological innovations from the sensing, computer, and communications industries. The growth of these networks has accelerated to meet demands for the use of sensors in a wider range of applications and for enterprisewide exchange of information. As these technologies have been incorporated into sensor networks, three clear generations have developed (see Figure 1). Figure 1. The first generation of sensor network technology was point-to-point. Interface standards such as current loops and the 1-5 V signal provided the means for sensing and control information to leave and reach the sensor and actuator. The sensor or actuator's analog signal provided a single dimension of measurement. From the Link to the Network The second generation of sensor networking technology was triggered by the development of the microprocessor, which allowed computing capability to be combined with the sensor. With increased intelligence in the node came the realization that communications were the limiting factor, and the development of such digital standards as RS-232, RS-422, and RS-485 spurred the creation of numerous sensor networking schemes. Some, such as Modbus, are still widely used today. Cost and complexity determined that complete instruments or controllers were more commonly networked than sensors. It took another silicon advancement, the popularization of the microcontroller, to advance communications capabilities and bring networking closer to the sensor. A key step forward for sensor networks was the introduction of BITBUS and the 8044 microcontroller by Intel in 1983. The BITBUS system offered communications and dealt with information and applications at a higher level of abstraction through its Remote Access Commands (today it would be called an application/user layer protocol). In addition, the BITBUS system packaged a small real-time kernel in the 8044. For the first time, it was possible to run a sensor bus inside a product, connecting sensors and actuators, instead of using direct wiring. From the Network to the Communications System Technological improvements behind the third and current generation of sensor networking technology came out of the development of the Manufacturing Automation Protocol (MAP), initiated by General Motors in the early 1980s. MAP was designed to reduce the cost of integrating various networking schemes into a plantwide system. The result was the development of the Manufacturing Messaging Specification (MMS). MMS represented a refinement of early messaging concepts, allowing the exchange of real-time data and supervisory control information between networked devices, independent of the function being performed and the method of implementing those functions in a device. For all MMS's capabilities, though, you paid a price, and variants and subsets of the protocol emerged as applications sought to address issues involving the size and complexity of implementations. These smaller networks (e.g., Profibus) were targeted at the growing intelligent systems and devices in manufacturing automation and process control. In the late 1980s and early 1990s, two other technical innovations were made that continue to have an impact today. Interoperability of Networked Devices Deployment of HART—a process industry protocol that is a de facto standard for simultaneous analog and digital communications for smart instruments—led to the recognition that interoperability and wide interconnection of sensor and actuator systems required standardization beyond that of the communications system. The first implementation of technology to do this, called the Device Description Language, was developed as a part of the HART protocol. The Device Description Language enabled applications to learn to interact with devices that they had not seen before. This was achieved through querying a written description of the functionality of the device. This technology has since been adapted in the Fieldbus Foundation specification, a digital process control protocol. A New Interaction Paradigm for Networked Devices Another key innovation to have an impact on the third generation of networks came out of work in France on the Flux Information Processus (FIP) communication protocol. Traditionally, sensor networks functioned in a client-server model, with applications interacting with sensors and actuators through coupled requests and responses. The FIP specification introduced the publisher-subscriber model for applications, where information is made available on the network to devices or applications. This model is useful for periodic data-driven systems and has been integrated into such protocols as the Fieldbus Foundation specification and the Controller Area Network (CAN) standard. The philosophical successor of the innovations of BITBUS in this generation is Echelon's LonTalk protocol. Supported by the Neuron chip, Echelon provided a sophisticated protocol coupled with an event-oriented application paradigm built on a publisher-subscriber model and supported with a programming environment called Neuron C. Echelon's idea was to use LonTalk as a protocol that would function over a broader range of applications and communications media than had been considered before. Volume at Last! As with previous generations, the third generation of networking technology saw its fullest development come with an innovation borrowed from another industry, but this time, the innovation was not so much in the technology as in the volumes and cost that could be expected from the source of the technology. To deal with the growing use of electronics in its products and the growing complexity and cost of wiring the electronics and electronic subsystems together, the automotive industry studied the use of a network in vehicles. In the mid 1980s, the Robert Bosch Company, a key supplier of components and subsystems to the automotive industry, specified the CAN. Driven by the size and cost sensitivity of the market, CAN silicon has proliferated, providing a cost-effective networking technology ideal for sensor network applications. As a consequence, the basic CAN technology spread widely to other applications.

Home | About Us | Site Index | Privacy Policy © 2006 Questex Media Group, Inc.. All rights reserved. Reproduction in whole or in part is prohibited. Please send any technical comments or questions to our webmaster.