Print this article

Comment

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.

End result

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.