document
document
Introduction
In this paper, an application of the IEEE 1451.2 standard is described and key features from this
standard are explained in terms of the application requirements and the standard’s guidelines.
Other papers in these proceedings summarize the IEEE 1451 family of interface standards and
discuss the motivations behind developing smart transducer interface standards; this paper will
focus on the IEEE 1451.2 standard [1].
For the application described here, a request was made to provide a networked monitor that
could indicate the status of certain high-valued assets. Unfortunately, there were multiple
categories of assets that provided different indicators of equipment status. The customer
requested a single unit that could be used with six different types of sensors but all types of
sensors should be processed to provide the same type of output – a utilization percentage. This
percent utilization would indicate to the customer approximately what percentage of the workday
this relatively high value asset (equipment) was in use. The requested output was to be provided
as a unitless percentage indicating the asset utilization during the workday. Once the equipment
monitor was attached to a specific target piece of equipment, the type of sensor used to indicate
the “in-use” condition would be selected. A threshold setting for the selected “in-use” sensor
would then be set-up for this target piece of equipment. The “Asset Utilization” value was then
defined as the condition that occurs when the selected “in-use” indicating sensor exceeds the
defined threshold value.
Preprinted from the Proceedings of the 2002 Sensors Expo, May 20 – 23, 2002, San Jose, CA -1-
type of sensor. The meta-TEDS and meta-ID TEDS provides the ability to include global
information about the entire unit including text descriptions, serial numbers, date of manufacture,
timing issues and a substantial amount of other information.
The standard includes accommodations for various trigger modes and status bytes for reporting
operational errors. In addition, if sensor data correction is needed, general-purpose, sensor-data,
correction algorithms are specified in detail in this standard. The Calibration TEDS describes
the details of the correction engine and how this can be applied.
The IEEE 1451.2 standard also includes a Smart Transducer Interface Module (STIM)
description that, among other things, provides a set of “functional addresses” for software
interfaces to the TEDS. These functional addresses provided a common, well-defined command
interface for acquiring data and setting parameters.
Since the writers of this standard, tried to make a widely useful standard to cover many types of
sensors, actuators, applications, networks, and processors, many of the TEDS fields will be zero
for any given implementation. The “trick” for using these TEDS is to understand which fields are
relevant for your application and which fields can be “zeroed”. Of course, for different
applications, different transducers fields will be utilized and therefore different fields will be
zeroed. In fact, of the eight TEDS data structures defined in the IEEE 1451.2 standard, only two
of these structures - the channel TEDS and the Meta TEDS - are required. The other six TEDS
are essentially optional. The application of the smart transducer will determine the need to add
any of the other TEDS or to leave them zeroed.
The next most valuable aspect of this standard, is the description of how these commands,
signals and digital communications all work together. IEEE 1451.2 contains several examples
illustrating the interactions between the commands from the Network Capable Application
Process (a generalized network interface unit) and the STIM. In developing a “real world”
application, it is important to understand these timing requirements, but even more important to
understand how different elements in the smart transducer respond when something go wrong.
The IEEE 1451.2 standard contains several status registers that indicate various error conditions
and are used to indicate a need to service (software or hardware) the smart transducer.
One of the goals of the IEEE 1451.2 was to make the standard independent of the specific
network to be used in the application. Although there are many great technical arguments for
selecting any one of tens of different network standards, the goal of this standard is to abstract
the details of the network into a separate functional block. This block, referred to as the Network
Capable Application Processor – NCAP, is described only with respect to the hardware and
software interactions with the STIM. No network interaction details are specified so that any
device, compliant with any network, is allowed to function as a 1451.2 NCAP as long as the
device behaves according to the standard regarding the STIM-NCAP interactions. Figure 1
shows a block diagram structure of the IEEE 1451.2 interface. Note that the objects to the left of
Preprinted from the Proceedings of the 2002 Sensors Expo, May 20 – 23, 2002, San Jose, CA -2-
the left side vertical dashed line and the objects to the right of the right side vertical dashed lines
are not included in the standard.
Using the IEEE 1451.2 technology in a data acquisition and transducer characterization
“engine”, a network enabled equipment monitor was developed. This unit is schematically
shown in Figure 2 followed by a photograph of the actual 6.75” x 2.5” x 8”(W x H x D) unit in
Figure 3. This Network Enabled Equipment Monitor has some interesting features and can
support several classes of applications. When analyzing this unit’s features, it is apparent that the
use of the IEEE-1451.2 is an underlying enabling technology.
For example, since text attributes for each sensor are stored in a modifiable Channel ID TEDS
field, information can be customized as indicated by the user for each application. In addition, a
unique threshold value to indicate the “in-use” condition can be associated with each sensor
selected.
For this implementation, the Network Capable Application Processor was selected to be a micro-
web server that includes a TCP/IP (Transmission Control Protocol/ Internet Protocol) stack and
support for HTTP (HyperText Transaction Protocol) requests. This results in compatibility with
HTML (HyperText Markup Language) type “web” pages to display data from this unit on the
(essentially) universally available “Web Browser” software.
By providing an Ethernet type NCAP, the number of possible applications for this monitor is
greatly enhanced compared with most other industrial network hardware/software solutions. To
support this, the January 2001 issue of the IEEE Spectrum magazine had a section dedicated to
industrial network connectivity [2]. One editorial predicted that by the year 2005, the
“manufacturing and process control markets would be nearly 100 percent Ethernet …” Since the
IEEE 1451.2 smart transducer technology does not care which outside world network is selected,
Ethernet was initially selected for the NCAP for compatibility with the Internet. However, this
selection did not exclude the possibility of later applying this same technology to other
proprietary industrial control buses, should this prediction be in error.
By adhering to the standard representation for the IEEE 1451.2 TEDS, the resulting product
includes “plug and play” like characteristics allowing the end-user to easily customize the
product with end-user specific names, “in-use” sensor selection, and output screen display.
Due to the flexibility provided by the IEEE 1451.2 TEDS data structures and STIM command
structures, the goals of this project were achieved. The initial product specifications requested
that one of several different types of sensors should be able to be used to indicate the equipment
“in-use” condition; the final product design fulfilled this requirement. This implementation of the
IEEE 1451.2 technology accommodates a broad range of sensor inputs. The compatible types of
sensors include the following: 1) 0-5 volt analog signal, 2) 0 –5 volt digital logic signal, 3)
switch closure, 4) 4-20 milliamp analog signal, 5) a series of 0-5 volt pulses for event counting
or frequency measurement, and 6) a type K thermocouple signal.
Preprinted from the Proceedings of the 2002 Sensors Expo, May 20 – 23, 2002, San Jose, CA -3-
This allows the same monitoring unit to be applied to a broad range of equipment types and
application categories and still provide essentially the same type of output – percent utilization.
The applications for this type of unit can include the following: 1) up-time monitoring, 2) capital
equipment resource allocation optimization, 3) supervisory “in-use” monitoring, 4) production
output quantity monitoring, 5) preventive maintenance monitoring and more.
Conclusions
We have described an example of smart sensor device technologies applied to a real world
problem – keeping track of the utilization of high-valued, capital assets. The design and
development of the Network Enabled Equipment Monitor example described here utilized the
key features of the IEEE 1451.2 smart sensor standard. These features include a set of sensor-
specific electronic datasheet (TEDS), a set of smart transducer interface module (STIM)
commands, and a NCAP compliant with several STIM-network interface functions. For the
example described here, the selected NCAP served as a micro-web server and provided Ethernet-
based, hypertext transaction protocol for Internet compatibility.
References
[1] IEEE Std 1451.2-1997, “IEEE Standard for a Smart Transducer Interface for Sensors and
Actuators – Transducer to Microprocessor Communication Protocols and Transducer Electronic
Data Sheet (TEDS) Formats”, IEEE Instrumentation and Measurement Society, TC-9 Committee
on Sensor Technology, Institute of Electrical and Electronics Engineers, New York, N.Y., Sept.
1998.
[2] Kaplan, G., “Ethernet’s Winning Ways”, IEEE Spectrum, January 2001 vol. 38, #1, page
113 – 115
James Wiczer is the President of Sensor Synergy, Inc in Buffalo Grove, IL. Sensor Synergy develops custom and
semi-custom software and hardware interfaces for sensors and actuators used in industrial automation and control
applications. Prior to Sensor Synergy, Wiczer was the manager of the Microsensors R&D Dept. and before that he
was manager of the Robotics and Automation Dept. - both at Sandia National Laboratories in Albuquerque, New
Mexico. James received his PhD in Electrical Engineering from the University of Illinois in 1977 and has worked at
Sandia National Labs between 1977 - 1994. Wiczer's activities at Sandia have included: sensor program
development; research and development of sensors for automation and process control applications using ultrasonic,
optical and capacitance phenomena; and the design and development of specialized optical detectors for adverse
environments. Wiczer has published over 40 articles on his research and development work and has been awarded
five patents on microimpedance imaging sensors and fluid quality sensors. Additional patents on networking
sensors are pending. He is a member of the IEEE, Tau Beta Pi, and HKN.
Preprinted from the Proceedings of the 2002 Sensors Expo, May 20 – 23, 2002, San Jose, CA -4-
Figure 1. Block Diagram of IEEE 1451.2 Smart Sensor Interface
Transducer
Electronic
Data Sheet
Sensors for (TEDS)
Monitoring Network
Transducer Capable
Manufacturing Independent Application
Process Status & Interface Processor Network
Other Related (TII) (NCAP) Connection
Condition/ Analog to Remote
Smart
Environments Digital Transducer Client
Transducer
- Interface
Computer
Signal Module (STIM)
Actuators for
Controlling Non-
Conversion (Incl. Address &
Command Logic)
Viewing
Time Critical Sensors
Processes & Data &
Environs
Activating
Preprinted from the Proceedings of the 2002 Sensors Expo, May 20 – 23, 2002, San Jose, CA -5-
Figure 2. A Network Enabled Equipment Monitor Using IEEE 1451.2 technology to
accommodate multiple types of “equipment-status indicating” transducers
Equipment Monitor
Module
Equipment or Process to Scheduler, Data Processing,
be Monitored Configuration Tools,
Preprinted from the Proceedings of the 2002 Sensors Expo, May 20 – 23, 2002, San Jose, CA -6-