Just how easy is it to develop a working prototype of an IEEE 1451.2–compliant transducer? To integrate a data acquisition (DA) system into a smart sensor, we had to dig deep into the protocol to relate its requirements to the IC’s specs, memory allocation, timing characteristics, and logic capabilities. For a standard whose aim is less to divide and conquer and more to integrate and simplify, this sounded like an onerous task.

So What Is 1451.2? [1]

We started by trying to understand what seemed like a simple concept. But the details of the protocol are very sophisticated, and its scope is all encompassing (see the sidebar “An IEEE 1451.2 Glossary,”).

IEEE 1451.2 is part of a planned family of adopted and proposed standards whose objective is to simplify the complexities designers have traditionally faced in establishing communications between networks and transducers. The goal is to standardize the interfaces between the transducer and the microcontroller and the microcontroller node and the network (see the sidebar “The Evolution of IEEE 1451,”).

Figure 1. This figure shows the networked smart transducer interface module developed by Analog Devices. The plug-and-play aspect of the standard not only allows the smart transducer interface module to be used here, but it also facilitates its seamless use in any other 1451.2-compatible network node.

In its simplest terms, 1451.2 specifies a plug-and-play capability in a transducer (sensor/ actuator) module. This isolates the choice of the transducer from that of the control network by specifying an electronic data sheet (memory) in a smart transducer module. The protocol also defines a serial digital interface that allows the control network to interrogate the sensor, access the data sheet, and monitor/configure sensor and actuator channels.

Getting Your Hands Dirty

We decided to implement a two-channel, 1451.2-compliant smart transducer interface module (STIM). One of the channels would handle input from an external temperature sensor, and the second channel would carry a digital output signal that controlled an external minifan—in effect, we decided to build a simple temperature control system.

We also provided an Ethernet connection. This allowed us to configure and control the system over the Internet.

TABLE 1
IEEE 1451.2 Transducer Independent Interface Signals
Group:	Line:	Abbreviation:	Description:
Data	DATA_OUT	DOUT	Data transport from STIM to NCAP
	DATA_IN	DIN	Address and data transport from NCAP to STIM
	DATA_CLOCK	DCLK	Positive-going edge latches data on both DIN and DOUT
	N_IO_ENABLE	NIOE	Signals that the data transport is active and delimits data transport framing
Triggering	N_TRIGGER	NTRIG	Performs triggering function
Support	POWER	POWER	Normal 5 V power supply
	COMMON	COMMON	Signal common or ground
	N_ACKNOWLEDGE	NACK	Serves two functions: 1. trigger acknowledge 2. data transport acknowledge
	N_STIM_DETECT	NSDET	Used by the NCAP to detect the presence of the STIM
Interrupt	N_IO_INTERRUPT	NIMT	Used by the STIM to request service of the NCAP

Choosing a Hardware Platform

As recent as the introduction of these standards has been, we were easily able to find an Ethernet network capable application processor (NCAP) development board that met our needs. The Bfoot-66501 [2] embedded Ethernet controller board from Agilent is a thin Web server for integrators and manufacturers of smart sensors and actuators. The Bfoot supports a 10Base-T Ethernet connection and a 10-wire, 1451.2 transducer independent interface (TII). The module uses a custom ASIC to provide the Ethernet/ Internet connection, and you can customize it with HTML pages and Java applets. [3]

The STIM platform chosen for this implementation is Analog Devices’ ADuC812 MicroConverter. [4] This 12 bit DA system incorporates a self-calibrating, multichannel A/D converter (ADC), two 12 bit DACs, and a programmable 8 bit (8051-compatible) microcontroller unit (MCU) on a single chip. The MCU core is supported by 8 KB of flash/EE program memory, 640 bytes of flash/EE data memory, and 256 bytes of on-chip SRAM data. Additional MCU support functions include a watchdog timer, power supply monitor, and ADC direct memory access functions. The MicroConverter has 32 programmable I/O lines. I²C-compatible, SPI (serial peripheral interface), and UART serial port interfaces are also provided for multiprocessor communications and I/O expansion.

We decided that the most elegant configuration was to interface the Ethernet NCAP with the ADuC812 evaluation board. We used the board prototype area to hardwire the temperature sensor to one of the 8 ADC input channels and to drive the minifan from a digital output line on the ADuC812 (see Figure 1)

Hardware Configuration

The configuration and connection of the TII interface between the NCAP and STIM is an area that causes some confusion. The standard defines the TII as a 10-wire interface as described in Table 1—remember that the naming conventions for the TII logical signals are designated from the STIM point of view.

You can hardwire the data set of four signals to the onchip SPI interface pins on the ADuC812, and the other signals can be connected to power, ground, and other digital I/O signals on the ADuC812. Under standing the function of these 1451.2 signals, we interfaced them to the ADuC812 platforms shown in Figure 2 .

A Software Model of 1451.2 [3]

Now that the hardware platform has been defined, we can turn our attention to the software development process. The software model we developed describes the essential components of the standard and how they relate to each other and the 1451.2 NCAP/ TII/STIM physical implementation.

Figure 2. An area that can cause confusion is the mapping of the 10-wire transducer independent interface (TII) defined by 1451.2 to the ADuC812. Shown here are the details of the TII wiring in our implementation. Note that all the logic signals’ naming conventions are defined from the smart transducer interface module’s point of view.

From the model, four software blocks emerge. These were coded in four software modules controlled by a kernel routine. The individual modules are described here.

STIM Kernel Control, Channel Data, and Transducer Interface Module. This module contains the definitions for the transducer channels associated with the STIM, the data associated with each channel, and the main kernel control flow of the program. Our implementation defines two channels—a temperature sensor and an actuator (a digital-output controlled minifan). As with the TII module (outlined below), this module contains certain definitions that are necessarily hardware coupled (i.e., the physical lines on which the sensor and actuator are realized).

TII Interface Module. The TII module defines the physical interface to the NCAP. This module integrates the logical TII lines with their hardware interface and provides an abstract layer for software interaction. Looking at the TII functions from a user’s perspective, the hardware coupling is transparent. The TII API calls allow for the transport of read and write protocol frames and for detecting and manipulating the states of the TII lines.

An IEEE 1451.2 Glossary [1]

As you begin to probe the IEEE 1451.2 standard, you’re introduced to new concepts that are crucial to your understanding of the implementation concept. [2] Network capable application processor (NCAP). The STIM is controlled by an NCAP, which mediates between the STIM and the control network and may provide local intelligence. IEEE 1451.1 defines an NCAP network-independent information model, or a meta language, that describes how NCAPs can adapt to various network standards and fieldbuses. Smart transducer interface module (STIM). The standard defines a STIM, which is your remote, networked, and intelligent transducer node. A STIM can support a single channel or many channels, linking both sensors and actuators. In fact, the standard specifies a maximum of 255 transducer channels per STIM. A transducer channel is “smart” in this context because it is described by a machine-readable transducer electronic data sheet. The control and data associated with the channel are digital. Triggering, status, and control are provided to support the proper functioning of the channel. Transducer electronic datasheet (TEDS). Every STIM must contain an area of memory written in a defined electronic format that describes the STIM itself and any transducer channels associated with it. This memory area is called the TEDS and is divided into eight fields, each of which is used to describe different aspects of the STIM and transducer channels. Only two of the eight TEDS fields are required and must remain with the STIM for the duration of its lifetime. The remaining fields are optional. Transducer independent interface (TII). The STIM communicates with the network transparently via the TII, which links the STIM to the NCAP. In physical terms, the TII is simply a 10-wire serial I/O bus. In implementation terms, this serial bus is a synchronous serial communications interface based on the serial peripheral interface (SPI). We’ve learned to look at it as an SPI with additional power, ground, and special-purpose digital strobe signals. The TII definition also includes triggering functions, byte transfer methodology, a byte read/write protocol, and data transport frames.

Transducer Electronic Datasheet (TEDS) Module. This module defines the TEDS for the STIM. The definition spells out where the TEDS are physically mapped (in our case, we decided to use the 640 byte flash/EE data space on the ADuC812), how they are written/stored, how they are re trieved, and what they contain. Only the mandatory TEDS are supported in this implementation (i.e., one meta and two channel TEDS). Reference [5] describes an expansion of this implementation to include the optional meta-ID TEDS.

Figure 3. An interesting view of 1451.2 is how easily the proposed software model maps to the chosen hardware platform. This lets you determine the compatibility of the hardware and the software before any significant software development has begun.

Address and Function Module. This module implements all the main functionality defined by the IEEE 1451.2 standards. It takes care of the data transport, control, interrupt, status, and trigger functions.

Mapping Software to Hardware

It was interesting to see how easily our software model mapped to the hardware platform (see Figure 3). This allowed us to assess mismatches and shortcomings in our software-hardware implementation before the coding exercise began. We wrote the code using Keil C51 development tools and then downloaded it to the ADuC812’s flash memory using the in-circuit serial downloader, an evaluation copy bundled with the MicroCon verter QuickStart Development Tools. [4]

Overview of the Software Operation

As sophisticated as the software model is, the operation of the resulting code is relatively easy to understand. The operational flow of the STIM kernel (which sits in an endless loop) controls the system. Having initialized the ADuC812 and configured the ADC and digital output channels, the kernel writes the TEDS data into flash/EE memory and then configures the SPI port for TII-compatible communications.

The TII data transport channel is continuously monitored for read or write requests from the network. These requests are immediately serviced. The hardwire trigger line (NTRIG), defined as part of the 10-wire TII interface, is polled, and if required, the trigger request is serviced. Finally, the STIM kernel generates a STIM interrupt on the TII (NINT) line if the STIM requires service from the NCAP (see Figure 4).

Figure 4. The STIM kernel runs on the onchip program flash/EE memory of the ADuC812 and is key to configuring, controlling, and managing the 1451.2 software implementation.

Again, the code is modular, and it’s easy to navigate in each of the code modules. The code handles the initial configuration of the TII-compatible interface on the ADuC812 STIM, which includes a standard SPI interface and digital I/O strobe pins, which are implemented using Port 3 digital I/O lines.

Implementing the TEDS

The global TEDS definition is subdivided into eight fields, two of which are mandatory. In our implementation, we included the minimum pair of TEDS fields—the mandatory meta and channel TEDS.

The TEDS are implemented as structures and copied from RAM into flash/EE data memory during the STIM kernel initialization. The checksum for each TEDS field is calculated during run time before the TEDS are written into memory.

The Evolution of IEEE 1451

In the early 1990s, traditional networks or fieldbuses enjoyed acceptance and ongoing adoption, but each solution resulted in an integration task that could take much time and effort, and even then, success wasn’t guaranteed. Providing transducers that interfaced with a broad range of existing and emerging control networks represented a significant cost to transducer manufacturers. Then in 1993 and 1994, the concept of the IEEE 1451 standard was brought before the members of the IEEE Instrumentation and Measurement Society’s TC9 Committee on Sensor Technology and before the National Institute of Standards and Technology. Through a series of five transducer workshops held in 1994 and 1995, the proposal for a transducer communications interface standard emerged, with the intent that it would alleviate traditional sensor integration problems. As a result of the initial work by the TC9 committee, the standard emerged as a set of four substandards—1451.1, 1451.2, 1451.3, and 1451.4. Each focused on one area of the smart networked sensor’s signal path, and each can be used individually or as part of an overall network solution. To date, only the 1451.1 and 1451.2 have been formally adopted by the IEEE. P1451.3 and P1451.4 are still under development, hence the prefix P, denoting a proposed document. The four substandards spell out how each substandard relates to the others: • 1451.1 defines a network capable application processor (NCAP) model, which is network independent, allowing NCAPs to be adapted to various networks. The model provides a hardware-independent abstraction layer for the sensor interface and defines how the model is mapped through a network abstraction layer to the control net work. • 1451.2 defines a transducer electronic data sheet (TEDS) for the smart transducer interface module (STIM) and specifies the digital interface and communications protocols between the STIM and the NCAP. • P1451.3 proposes a standard digital interface, called a transducer bus interface module (TBIM), which can connect multiple physically separated transducers in a multidrop configuration. The standard can be used in harsh environments, where it may not be possible to site the TEDS with the transducer, or in applications where transducers are distributed across an area in which it is not feasible to install an NCAP for each transducer channel. • P1451.4 proposes a standard interface that will allow analog transducers to operate in a mixed-signal mode. First, operating in a digital mode, it transfers TEDS data on power-up or on command. After transmitting the TEDS data, the transducer switches to the analog mode and sends its primary analog sensor signals. The IEEE 1451 standards take distributed sensing, data acquisition, and control to a higher level and make open systems more of a reality. The overall impact is to introduce an isolation between the transducer node design and the network implementation by facilitating self-identification of transducers, self-configuration, maintenance of long-term self-documentation, ease of transducer upgrades and maintenance, increases of system and data reliability, and remote self-calibration.

Conclusion

Our STIM solution verifies the IEEE 1451 concept and demonstrates its functionality and usefulness over an industrial Ethernet network. Isolating the choice of the transducer from the choice of network has shown how a networked smart transducer module can be implemented, even on a simple 8051-based machine. Our development can be measured in terms of a six worker-week task, starting from a position of little knowledge of 1451.2.

Our STIM prototype implements all the main functionality defined in the 1451.2 specification (see Table 2). It should also be noted that our aim was to develop a basic working prototype of a networked 1451.2 transducer. To this end, the software architecture met only the mandatory TEDS definitions and allows easy expansion at a later date to support a more comprehensive implementation. As a result, the code is structured, modular, and scalable.

The software architecture also maps closely to the single-chip ADuC812 MicroConverter chosen as the target platform. Expansion of the number of channels implemented on the STIM will obviously use up more memory on the ADuC812. As memory is filled, the developer can locate TEDS (which are intended to be read-only) in the program code area and locate run-time editable TEDS in the 640 byte data space.

All in all, a good development experience. The concept of the 1451 smart networked sensor is here and now—and it works.

TABLE 2
1451.2 Code: 2 Channel TEDS, 1 Meta TEDS
ADuC812 Memory Resource 256 byte RAM 640 byte data flash/EE 8 KB program flash/EE	Used 178 bytes 268 bytes 5,534 bytes	Available 78 bytes 372 bytes 2,657 bytes

References

1. “IEEE Standard for a Smart Transducer Interface for Sensors and Actuators—Transducer to Microprocessor Communi-cations Protocols and Transducer Electronic Data Sheet (TEDS) Formats,” IEEE Std 1451.2-1997. September 26, 1997.

2. Bfoot datasheet.

3. P. Conway et al. 2000. “IEEE 1451.2—An Interpretation and Example Implementation,” Proc 17th IEEE IMTC.

4. ADuC812 datasheet.

5. uC003 Technical Note and accompanying code.

Editor’s Note

See the STIM implementation on the Internet.

Paul Conway is Senior Research Engineer, PEI Technologies, Electronic Product Devel-opment Ctr., Foundation Bldg., University of Limerick, Limerick, Ireland; 353 61 202607, fax 353 61 334925, paul.conway@ul.ie, www.ul.ie/~pei.

Home | Contact Us | Advertise © 2009 Questex Media Group, Inc.. All rights reserved. Reproduction in whole or in part is prohibited. Please send any technical comments or questions to our webmaster.