01 June 2003
Network strategies make sense
By James Wiczer, Ph.D.
Linking smart sensors with web-centric equipment monitoring.
As network hardware in industrial and commercial facilities becomes more prevalent, companies get more involved with developing sensor interface solutions. These solutions use existing Ethernet infrastructure to enable monitoring of sensor-rich equipment. In one case, users wanted our company to develop a general-purpose interface to monitor several types of equipment in their facilities. The goal was to better manage the workload of capital-intensive assets.
The client wanted this information available to authorized users through the Internet. Their original laundry list of features and compatibility requirements yielded to cost-benefit analyses, resulting in an almost manageable set of features. They were mainly concerned with the diverse range of sensors representing equipment use. Depending on the specific type and model of equipment engineers monitored, they might encounter different sensors when connecting this general-purpose, equipment-use indicator. They subsequently narrowed the range of devices they wanted us to support to six common types of sensors.
By applying the Institute of Electrical and Electronics Engineers (IEEE) 1451.2-1997 standard for interfacing sensors and actuators to networks, we delivered a unit that was compatible with many types of sensors. Because the standard supported a variety of sensor types, we could apply the monitoring unit to a broad range of equipment types while providing essentially the same type of output—percent utilization. The client can use this unit for data gathering operations such as up-time monitoring, capital equipment resource allocation optimization, supervisory in-use monitoring, production output quantity monitoring, and preventive maintenance monitoring.
Technology behind the strategy
The IEEE working group developed a network-neutral solution that supports a wide range of networking hardware and avoids the problems associated with aligning an open standard with a proprietary network hardware solution. Although many proprietary network solutions exist, the 1451.2 committee reasoned users would value a generalized solution that would comply with different types of network hardware. The standard promoted the concept of a network-capable application processor (NCAP)—an intermediary between the external network and the smart-transducer interface module (STIM). They associated the core of the smart sensor feature set, including the transducer electronic data sheets (TEDS), with the STIM.
In this standard, the NCAP has two ports and all the hardware and software elements you need to make these ports function properly. One port contains the external network specific hardware and software elements of the interface, while the other port accommodates the hardware and software features you need to interface with the STIM. The only NCAP requirement in the standard is it needs to interface with the STIM in a software and hardware manner consistent with the standard, but the standard didn't define the network specifications. Now the group could promote the STIM features without associating with any specific network protocol.
Although we could come up with sound technical reasons for selecting from many different network standards for an application, we find this standard has abstracted details of the network into a separate functional block—the NCAP. The 1451.2 group promoted this as a network-neutral feature because they could make the core smart-transducer features compatible with any network that would make the development of an NCAP module comply with the target network hardware and software protocols.
The standard is flexible about details in implementing hardware for the NCAP and STIM. We needed to develop a solution for our client's general-purpose equipment-use monitor, so we provided the resulting use information through the Web. An authorized person would be able to access this data with a standard Web browser.
Although a PC could function as an NCAP and STIM, our client thought this approach would be cumbersome, expensive, and require on-going resources to manage the PC in their manufacturing environments. The client's goal was to use a small enclosure to house inexpensive, low-maintenance, smart-sensing technology. Another goal was to develop an easy-to-install, unobtrusive box with few user adjustments.
We chose a microweb server for the NCAP. This server includes a TCP/IP stack and support for hypertext transaction protocol requests to provide compatibility with hypertext markup language–type Web pages.
This device provided a direct Ethernet connection for an easy network interface with common Ethernet network hardware. Our chosen microweb server also gave us an asynchronous serial data connection so we could link to the STIM.
The STIM hardware and software interface requirements caused us to deviate slightly from strict compliance with all specifications in the IEEE-1451.2 standard. The standard 10-wire transducer independent interface (TII) specified in 1451.2 to connect the NCAP to the STIM was not easily implemented with the NCAP we selected. We substituted a 0 to 5 volt, asynchronous serial interface using hardware flow control to emulate the functions specified in the 1451.2 standard.
In fact, IEEE has recognized this issue as a hurdle to adopting the standard. It's investigating revising the TII to make the STIM-to-NCAP interface more compatible with widely available asynchronous serial-interface hardware solutions.
In and out
Applying NCAP, STIM, TEDS, and the rest of the alphabet to our client's equipment-use monitor required analysis about what to include and what to avoid. The IEEE-1451.2-1997 standard provided a set of powerful tools to satisfy our client's requirements, but the cost was prohibitive. For-tunately, many of the TEDS fields are optional, inapplicable, or default to zero. It was important to understand which fields were relevant to the application and which fields or entire TEDS we should exclude.
Another useful advantage of using the IEEE 1451.2-standard was a set of uniform electronic data sheets suitable for all six types of sensors specified by our client. The TEDS provide a mechanism to create a common data and sensor configuration structure for the six different types of sensors that our client might use in the equipment-use monitor project. The common structure helped us transform the sensor signal outputs from each sensor into the required equipment utilization parameter.
The TEDS also created a uniform approach to accommodate a list of differences between sensors—including delay time differences between data request and valid data, trigger mode types, calibration differences, and physical and unit differences. By closely following data structures outlined in the standard, we successfully configured the TEDS for each sensor.
The resulting product includes plug-and-play characteristics—allowing the end-user to easily customize the product with end-user specific names, in-use sensor selection, and output screen display. Because the client can store text attributes for each in a modifiable channel identification TEDS field, they can customize users for each equipment-use application.
We successfully accommodated signals for the following type of sensors: (1) a 0–5 volt analog signal, (2) a 0–5 volt digital logic signal, (3) a switch closure, (4) a 4–20 mA analog signal, (5) a series of 0–5 volt pulses for event or frequency counting, and (6) a type K thermocouple signal. ST
Behind the byline
James Wiczer is president of Sensor Synergy, Inc., in Buffalo Grove, Ill.
Transducer Electronic Data Sheets—TEDS
Transducer electronic data sheets (TEDS) electronically represent information about the sensors and actuators attached to a STIM. TEDS contain specific technical details useful for data acquisition, system deployment, and on-going system maintenance. The goal in developing TEDS was to provide a generalized data sheet representation of several key sensor and actuator features in a standard format that users could retrieve electronically and upgrade remotely in some cases. In a network environment with multiple active STIM-NCAP units, it's important to identify and characterize each STIM unit separately. Here, a client is a user system (typically a computer) connecting to the NCAP through the network and extracting information from the NCAP-STIM unit. When a client system connects through an NCAP to a STIM, the TEDS provide necessary information to acquire and use the transducer data. TEDS identify which unit is being interrogated and provide all necessary information to query specific sensors, correct the sensor data, and identify specific properties of the sensors providing the data.
The meta-TEDS provide global information to the client about the STIM unit attached to the NCAP and include the information users need to access data in channel TEDS. The meta-TEDS provide common information applicable to all transducers attached to the STIM and include unique identifiers for the STIM, the number of transducers attached to the STIM, the longest delay time between a request for transducer data and the delivery of the data for any of the transducers attached to the STIM, and the presence of a correction/compensation engine for sensors attached to the unit.
The channel TEDS contain information specific to one of the transducers connected to the STIM; each sensor and each actuator connected to the STIM must have its own channel TEDS. The type of information in the channel TEDS includes the physical units associated with the data, acquisition delays, the upper and lower limits on the data, and the type of data—such as single precision real, 4-byte integer.
The optional calibration TEDS allow data calibration using a standardized mathematical correction algorithm—a piecewise multinomial function. This approach can provide high-order correction for multiple segments in which many factors affect the results. The correction engine can accommodate a humidity sensor calibration coefficient, which needs to be corrected for nonlinearity as a function of temperature and humidity.
The identification TEDS provide human-readable information to the client about the connected STIM and transducers. The optional meta-ID TEDS provide information about the smart-transducer interface module unit—STIM manufacturer, model number, serial number, date of manufacturer, software version number, and product description.
You can implement the optional TEDS as needed. Most real-world sensors do not behave in a linear manner across the entire operating range of interest. The calibration TEDS are well suited for applications requiring calibration and compensation to correct for sensor nonlinearities. In certain applications, the self-documenting features enabled by the meta-ID TEDS can be extremely useful by providing a descriptive text document permanently associated with a sensor in an online manner.