| |
Using IEEE's Smart Sensor Interface Standard for Web-Centric Equipment Monitoring
James Wiczer, PhD
Sensor Synergy, Inc
Buffalo Grove, IL 60089
(A version of this paper was printed in the June 2003, ISA SensorTech Journal - A Supplement to InTech.)
Background
As the prevalence of network hardware in industrial and commercial facilities continues to grow, our company has become involved in developing sensor interface solutions that utilize existing Ethernet infrastructure to enable monitoring of sensor-rich equipment. One of our clients requested that we develop a "general purpose" interface to monitor several types of equipment located in their facilities. The goal of this work was to better manage the workload of capital-intensive assets. The client wanted this information available to authorized individuals through the Internet. Originally there was a long "laundry list" of requested features and compatibility requirements but expansive feature desires yielded to cost-benefit analyses resulted in an almost manageable set of features. The main engineering concern centered on the diverse range of sensors that may be selected to represent equipment usage. Depending on the specific type and model of equipment being monitored, different sensors might be encountered when connecting this general-purpose equipment "use" indicator; subsequent discussions narrowed the range of devices we had to support to six common types of sensors.
The issues became focused with a review of the IEEE 1451.2 - 1997 specification for connecting smart transducers to computer networks . Although reading the standard can be compared with ingesting a potent sedative, valuable solutions to difficult problems can be found throughout this document. The standard was developed during a 4-year period by a broad spectrum of industry authorities experienced in interfacing sensors to stand-alone equipment and data networks. The goal of their effort was to develop a flexible interface technology that could satisfy a wide range of sensor and actuators while supporting the growing set of "smart" sensor technology features.
This IEEE (Institute of Electrical and Electronic Engineers) working group decided to develop a network neutral solution that would support a wide range of different networking hardware and avoid the problems associated with aligning an open standard with a proprietary network hardware solution. Although there are many proprietary network solutions, the 1451.2 committee reasoned that a generalized solution that could be made to comply with several different types of network hardware would be of greater value to industry users. The IEEE 1451.2 standard promoted the concept of a "Network Capable Application Processor" (NCAP) that served as an intermediary between the external network and the Smart Transducer Interface Module (STIM). The core of the smart sensor feature set, including the Transducer Electronic Data Sheets (TEDS), was associated with the STIM.
In this standard, the NCAP consists of two ports and all of the hardware and software elements needed to make these ports function properly; one port contained the external network specific hardware and software elements of the interface while the other port accommodated the necessary hardware and software features required to interface with the STIM. The only requirements in the standard about the NCAP were that it needed to interface with the STIM in a software and hardware manner consistent with the standard, but the network specifications were undefined. In this way, the network-to-NCAP features were left unspecified and the standards group could promote the STIM features without associating with any specific network protocol. Although there are many sound technical reasons for selecting any one of tens of different network standards for an application, this standard abstracted the details of the network into a separate functional block - the NCAP. The 1451.2 group promoted this as a network neutral feature since the core smart transducer features could be made compatible with any network that would allow the development of an NCAP module compliant with the target network hardware and software protocols.
The standard provides for great flexibility with regard to the details of the hardware implementation for the NCAP and considerable flexibility regarding the implementation of the STIM. In developing a solution for our client's general-purpose equipment-use monitor, we were required to provide the resulting use-information through the Web in which an authorized individual would be able to access this data with a standard Web browser program.
Although a personal computer (PC) could be made to function as an NCAP and STIM, it seemed to our client that 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 utilize a relatively small size enclosure to house relatively inexpensive, low-maintenance smart sensing technology. Included with the list of goals for this project was a desire to develop an easy-to-install, unobtrusive box with minimal user adjustments.
Considering our client's constraints, we selected a microweb server device to serve as the NCAP. The selected microweb server includes a TCP/IP (Transmission Control Protocol/ Internet Protocol) stack and support for HTTP (HyperText Transaction Protocol) requests to provide compatibility with HTML (HyperText Markup Language) type "web" pages. This allows us to display data from this unit on universally available "Web Browser" software. By providing an Ethernet type of NCAP, the number of possible applications for this monitor were greatly enhanced compared with most other proprietary industrial network hardware/software solutions.
This device provided a direct Ethernet connection for an easy network interface with common Ethernet network hardware. The microweb server that we selected also provided an asynchronous serial data connection to allow interfacing to the STIM. In evaluating commercially available off-the-shelf technology to serve as a microweb server for our IEEE 1451.2 interface implementation, we found several devices suitable for the NCAP role. Although the mechanical interfaces were different, there were enough similarities in the feature sets to allow for alternate suppliers if devices became unavailable for any reason.
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, recognition of this issue as a hurdle to adopting the standard, IEEE has recently launched a working group to investigate revisions to the TII to make the STIM-to-NCAP interface more compatible with widely available asynchronous serial interface hardware solutions. Work on this revision and other improvements to the standard are on-going.
Transducer Electronic Data Sheets - TEDS
The transducer electronic data sheets (TEDS) electronically represent information about the sensors and actuators attached to a STIM. These electronic data sheets contain specific technical details useful for data acquisition, system deployment and on-going system maintenance. The motivation for developing the TEDS was to provide a generalized data sheet representation of several key sensor and actuator features in a standard format that would be electronically retrievable, always available, and in some instances remotely upgradeable. In a network environment in which multiple STIM-NCAP units were connected and active, it is important to address, identify and characterize each STIM unit separately. In this description, the term "client" is used to describe 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 all of the necessary information to acquire and utilize the transducer data. In essence, the TEDS identifies which unit is being interrogated and provides all necessary information to query specific sensors, correct the sensor data, and identify specific properties of the sensors providing the data.
The IEEE standards group decided on implementing eight types of TEDS in the 1451.2-1997 standard including the Meta TEDS, Channel TEDS, Channel ID TEDS, Meta ID TEDS, Calibration TEDS, Calibration ID TEDS, an application specific user TEDS, and industry expansion for future TEDS. The Meta TEDS and at least one Channel TEDS are required to be implemented in a minimum memory usage form; these two TEDS can be implemented in less than 300, 8-bit bytes.
The Meta TEDS provide global information to the client about the STIM unit attached to the NCAP and includes the information necessary to access data in any of the channel TEDS. The Meta TEDS provides common information applicable to all transducers attached to the STIM and include such essentials as the unique identifier 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 contains 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 to be associated with the data, acquisition delays, the upper and lower limits on the data, type of data provided (e.g. single precision real, 4-byte integer), and other related information.
The Calibration TEDS, an optional TEDS, provides a data calibration capability using a standardized mathematical correction algorithm - a piecewise multinomial function. This approach can provide high-order correction for multiple segments in which multiple factors effect the results. For example, this correction engine can accommodate a humidity sensor calibration coefficient, which needs to be corrected for non-linearity as a function of temperature and humidity.
The Identification TEDS provide human readable information to the client about the connected STIM and transducers. The Meta-ID TEDS, an optional TEDS with at most one of these TEDS per STIM unit, provides information about the Smart Transducer Interface Module unit, such as STIM manufacturer, model number, serial number, date of manufacturer, software version number, and product description. The Channel-ID TEDS, another optional TEDS with at most one of these TEDS for each Channel TEDS, provides information about the transducers associated with the specified channel. This Channel-ID information includes transducer manufacturer, model number, serial number, version number, and transducer description.
The optional TEDS may be implemented as needed and provide for some useful features. For examples, 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 which require calibration and compensation to correct for sensor non-linearities. 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 on-line manner.
Applying Smart Interface Standards to Equipment Use Monitor
Applying NCAP, STIM, TEDS, and the rest of the alphabet to our client's equipment use monitor required some analysis about what to include and what to avoid. The IEEE-1451.2-1997 standard clearly provides a set of powerful tools that can be used to satisfy all of our client's requirements but the cost of including all possible TEDS fields would be prohibitive. Since the authors 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 not be applicable for a given implementation. Fortunately, many of the TEDS fields are optional, are inapplicable, or default to "0". An important aspect of applying the IEEE standard to an application is understanding which fields are relevant to the application and which fields or entire TEDS should be excluded.
Another useful advantage of using the IEEE 1451.2 standard for this application is that the standard provides a set of uniform Electronic Data Sheet suitable for all six types of sensors specified by our client for this application. The TEDS provides a mechanism to create a common data and sensor configuration structure for the six different types of sensors that might be utilized by our client 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 the various sensors including the delay time differences between data request and valid data, the type of trigger modes, calibration differences, physical unit differences and other fundamental disparities between our sensors. By adhering to the data structures outlined in the IEEE 1451.2 -1997 standard, we were able to configure the TEDS for each sensor appropriately. The completeness of the TEDS definitions and TEDS data structures greatly assisted our efforts.
The IEEE 1451.2 also provides a set of "functional addresses" for software interfaces to the TEDS. These functional addresses provided a common, well-defined command interface to the STIM for acquiring data and setting parameters. The standard also includes accommodations for various trigger modes and status bytes for reporting operational errors. The IEEE 1451.2 standard contains several status registers that indicate various error conditions and are used to indicate a need to service the smart transducer.
A Network Enabled Equipment Use Monitor
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. Since text attributes for each sensor can be stored in a modifiable Channel ID TEDS field, information can be customized as indicated by the user for each equipment - use application. In addition, a unique threshold value to indicate the "in-use" condition can be associated with each sensor selected.
Due to the flexibility provided by the IEEE 1451.2 TEDS data structures and STIM command structures, as the initial product specifications requested, multiple types of sensors can be used to indicate the equipment "in-use" condition. To illustrate the wide range of sensor inputs that can be considered, for this application, the sensor types include 1) a 0-5 volt analog signal, 2) a 0 -5 volt digital logic signal, 3) a switch closure, 4) a 4-20 milliamp analog signal, 5) a series of 0-5 volt pulses for event or frequency counting, and 6) a type K thermocouple signal.
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 sensor specific electronic datasheet (TEDS), smart transducer interface module (STIM) commands, and NCAP compliant 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
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 - IEEE, New York, N.Y., Sept. 1998.
|
|
|
|
|
