Design Features February 17, 1997

Data acquisition
QUIETLY JOINS THE COMMUNICATIONS REVOLUTION

Dan Strassberg, SENIOR TECHNICAL EDITOR

Sometimes, you just can't be too careful. Experience has taught this lesson to many EEs who work with data acquisition. So, it should come as no surprise that these engineers are circumspect in their embrace of data communication and distributed intelligence.

Users of I/O and data-acquisition hardware and software are a cautious lot--and with good reason. In many cases, their applications are "mission-critical." System failures can bring entire industrial plants to a grinding halt, tying up production equipment worth millions of dollars while harried maintenance people scramble to find causes and cures. Despite strong motivation for sticking with tried-and-true approaches, engineers who design and install data-acquisition systems are finding good reasons to join the communications revolution. But in data acquisition, unlike some other areas of electronics, this revolution is working changes that are more evolutionary than dramatic.

Putting microcontroller ICs near data sources is clearly within the state of the art. Such distributed intelligence can reduce network traffic and improve system reliability in the event of disrupted communication or partial network failures. Indeed, many suppliers of industrial-control systems offer distributed-control products. Despite data acquisition's close relationship to industrial control, data-acquisition users seem reluctant to become too reliant on it, although they accept distributed intelligence in limited roles. Hardware vendors, mindful of the market's inherent conservatism, are cautious about announcing new capabilities faster than users seem ready to accept them.

Still, several vendors are demonstrating the use of distributed intelligence in real-time data-acquisition applications that many people would call visionary. The demonstrations, by Laboratory Technologies and National Instruments, use the Internet as part of systems that collect and display weather data in real time. You can see the results at the companies' Web sites: www.labtech.com and www.natinst.com.

In these initial demonstrations of Internet-based data acquisition, the remote nodes use general-purpose computers, albeit in limited, well-defined roles. In most other remote-data-acquisition systems, the remote intelligence is more deeply embedded and relatively inflexible; modifying it to perform new or expanded functions is more difficult than is reconfiguring the software that runs in general-purpose computers. Still, whether the distributed intelligence is specialized or general-purpose, the host computer--not the remote nodes--almost always provides the user interface.

Although Internet-based data acquisition brings attention to the companies that are demonstrating it, these companies don't expect a big rush to use the Internet for gathering real-time data. Instead, the companies see a move to in-house networks, or intranets, as a major data-transmission medium. Data-acquisition companies see networks, such as the ubiquitous office Ethernet LANs, as displacing special-purpose data-communication networks in many industrial data-acquisition applications.

According to Rob Winkler, an application engineer at Intelligent Instrumentation, a company that offers Ethernet-based products, one reason for Ethernet's popularity is users' recognition that Ethernet's well-known nondeterministic latency, though often a fatal Achilles' heel in closed-loop control, isn't necessarily a problem in data acquisition. Once a company realizes that Ethernet can do the job, nothing else stands much of a chance. Ethernet LANs are almost everywhere in industrial plants. Instead of installing costly new wiring, companies can simply tap into the wiring of an existing LAN to connect a remote-data-acquisition node.

There will, however, be some real uses of Internet-based data acquisition within the next few years. It's intriguing to think of an engineer's monitoring an automated manufacturing process from his or her living room late on a weekend night or via a cellular-modem-equipped laptop from the beach on a hot summer afternoon. Anyone with an Internet account and the correct security password could perform such a task without special connectivity hardware.

Of course, monitoring signals from sensors far from the central monitoring station or host computer is anything but new. Remote monitoring has been a feature of factory-automation, building-automation, and process-control systems for decades. What are relatively new are digitizing analog signals close to the sensor and sending digital data instead of analog signals over long distances. Thus, digital communication is replacing the analog-signal transmission (usually, 4- to 20-mA current loops) that has been a mainstay of remote data acquisition for more than 25 years. Multiplexing discrete (on/off) I/O data onto a few wires is also relatively new.

A Tower of Babel

Communicating by means of standard protocols is newer still. In the last few years, multivendor protocols have certainly gained favor over vendor-specific data-communication approaches. But, despite several protocols' multivendor support, a real Tower of Babel exists (Reference 1). The number of protocols is staggering, with big winners just about impossible to discern. And, even when specific protocols gain fairly broad acceptance, they generally do so only in narrow market segments and limited geographic areas.

In some cases, a standard that many people think defines a communication protocol does not really do so. RS-485 is an example (Reference 2); it standardizes many hardware aspects of digital communication over twisted pairs of wires. But it does not define important network characteristics, such as node addressing, data formats, message headers, and the handshaking necessary to establish communications among network nodes. In the absence of a true protocol standard, many vendors have devised proprietary protocols that use RS-485. Therefore, most RS-485-based hardware works only with hardware from the same vendor.

Many remote-data-acquisition and remote-I/O products incorporate intelligence. But, in most cases, the intelligence performs a rather specialized function--managing the interface with the communication network. Data-acquisition products in which remote units assume decision-making authority (limit checking and data reporting by exception are examples) remain in the minority. (See box, "An overdose of high tech could make you lose your bearings.")

One of the earliest embodiments of remote data-acquisition was Analog Devices' 6B module series, which is now available from several sources. Despite the diversity of remote-data-acquisition products, careful observers should note the 6B series' influence on newer products. The 6B family currently numbers nine members for different transducer types. The modules, which perform signal isolation and conditioning as well as 16-bit A/D conversion, plug into manifolds that accept the transducer wiring. Manifold outputs connect to the host computer via RS-232C- or RS-485-compliant wiring. Prices of 6B modules begin at $180. Manifold prices start at $45 for a single-channel unit.

The box, "A remote-data-acquisition gallery," which runs through this article, contains photos and descriptions of representative remote-data-acquisition-hardware products. The diversity of these products indicates how many choices system designers have for building data-acquisition systems that meet their needs.

References

1. Travis, Bill, "Smart-sensor standard will ease networking woes," EDN, June 22, 1995, pg 49.
2. Goldie, John, "Ten ways to bullet-proof RS-485 interfaces," EDN, Aug 1, 1996, pg 141.
3. Travis, Bill, "Smart sensors," EDN, May 9, 1996, pg 56.

You can reach Senior Technical Editor Dan Strassberg at (617) 558-4205, fax (617) 928-4205, ednstrassberg@cahners.com.

| EDN Access | Feedback | Subscribe to EDN | Table of Contents |