Reaching Up and Out: Interface Standards Smarten Up Sensors, Transducers

KEY WORDS

Networks and communications

Sensors

PC-based control

System integration

Embedded control

Sensor/actuator-level networks

Sidebars: Parts of IEEE P1451 Standard for a Smart Transducer Interface for Sensors and Actuators

Can you hear it? It’s the sound of several thousand fed up sensor and transducer manufacturers doing an end-run around the endless fieldbus squabbles. Many are beginning to use increasingly intelligent devices and common communications, which can access networks and function on the Internet to get jobs done.

Big talk, to be sure. However, IEEE P1451, the proposed Smart Transducer Interface Standard, is solidly grounded in the trenches. Its developers designed it to solve specific problems; held ongoing demonstrations and based adjustments on real-world applications; and assigned newer, more esoteric problems and solutions to subsequent working groups.

History and evolution

P1451 was launched in 1993-94 by members of the IEEE Instrumentation and Measurement Society’s (I&M, Los Angeles, Calif.) TC9 Committee on Sensor Technology and the National Institute of Standards and Technology (NIST, Gaithersburg, Md.) to alleviate traditional sensor integration problems by using standard communication interfaces.

Though different networks and fieldbuses had and continue to have different protocols and requirements, many of the 1,500-2,000 small and medium sensor and transducer manufacturers and their users wanted a common interface. This was something fieldbus standards organizations have long promised, but so far haven’t delivered to many users’ satisfaction.

‘Users and sensor manufacturers would ask which network was best to use, and we couldn’t recommend one,’ says Kang Lee, group leader of NIST’s Sensor Integration Group and chair of I&M’s Sensor Technology Committee. ‘However, we could help solve their problem by devising this common interface for smart sensors.’

Janusz Bryzek, former TC9 co-chair and general manager of intelligent MEMs products at Maxim (Sunnyvale, Calif.), says the initial concept was to design a transducer shell with room for a driver. This meant the transducer could plug into a generic P1451 driver, which would replace the need for a specific driver.

‘By implementing P1451 connectivity, we estimated that-once the drivers were available-users could save 90-95% of the time necessary to develop software they would have needed previously,’ says Dr. Bryzek.

Nuts, bolts, and TEDS

Following initial organizing efforts, P1451’s developers divided themselves into two and eventually four working groups based on objectives. The 1451.2 group developed Smart Transducer Interface Modules (STIMs) that included Transducer Electronic Data Sheets (TEDS) donated by Hewlett-Packard (HP, Palo Alto, Calif.). Dr. Bryzek says HP also contributed the concept of standardizing by using digital coding for physical units, which will also help sensors connect to the Internet. Meanwhile, the 1451.1 group began to define standards for the Network-Capable Application Processor (NCAP) information module.

‘We found we could define network-independent hardware interfaces with little electronic data sheets,’ says Jay Warrior, chairman of the 1451.2 group and HP’s program manager for distributed measurement and control operations. ‘Once these are in place, it frees up taking any sensor or actuator and plugging it into a DeviceNet, LonWorks, or SDS-based network.’

TEDS enable the common interface by defining device characteristics in 70 software-based fields. This gives transducers, sensors, and other devices a sort of passport for presenting themselves to networks. TEDS also set the format that helps devices read through the common interface, which allows automatic identification of use characteristics. Network devices can read TEDS on sensors, rather than requiring manual code keying, configuration, or calibration data whenever a device is installed or replaced. TEDS not only improve communication, but also help networks track devices and secure data from them.

Dr. Warrior adds that 1451.2 is aided by 1451.1’s mapping, which can say that a message needs to be sent, for example, but allows the implementation to be handled by the small piece of driver software peculiar to each network. This means devices using 1451.1’s common object model are responsible for taking messages to a network, but they are delivered in accordance with whatever method the network uses.

Mr. Lee emphasizes that P1451 is not another fieldbus. Instead, it’s a way for sensor manufacturers to develop their sensor interfaces according to a single, common interface.

Using intelligence

To create 1451.2, the developers defined two parts, a sensor piece that includes the STIM and TEDS and a network piece that could accommodate an embedded controller. Rick Van Ness, business development specialist for HP’s distributed measurement and control division, says TEDS allowed the resulting smart devices to be independent of traditional networks, so users could plug into the electronic support network of their choice, such as Profibus, DeviceNet, LonWorks, SDS, or others.

Mr. Lee estimates that 1451.2 can help meet 80% of the needs of sensor manufacturers. ‘We start with sensors and networks, but this can propagate up to the enterprise level,’ says Mr. Lee. ‘We’d like anyone to be able to see what their sensors are doing.’

Inclusive input

In tandem with P1451’s overall evolution, TC9 developers continuously demonstrated and updated it with new input. Mr. Lee says this openness and a TEDS extension feature built into P1451 make it a useful, living standard, rather than just a paper specification. Manufacturers can apply for TEDS extensions directly to IEEE with proposals that future sensor features be added to the overall TEDS specification. For instance, Mr. Lee says someone can even put an entire operator manual on a TEDS device.

‘P1451 was driven by people that want to use networks, but didn’t have an ax to grind about what network to use,’ says Dr. Warrior. ‘Users and developers don’t want to do so much rework on each project. ‘

TC9’s inclusiveness also helped the developers keep 1451.2’s focus relatively narrow, which smoothed its eventual approval in 1997. This inclusiveness also helped TC9 form in 1995 the P1451.3 working group for applications with a cluster of sensors, for getting high-speed, synchronized data. TC9 also formed the P1451.4 working group for applications with mixed-mode (digital TEDS and analog signaling ) communications for analog transducers. For example, engineers at Boeing Corp. (Seattle, Wa.) are helping with 1451.3 because it can help use TEDS in a multidrop network. This will allow Boeing to minimize wiring needed when measuring pressure across airplane wings.

From chips to applications

Though there aren’t dozens of P1451-based products available yet, TC9 included representatives of 30-40 firms when 1451.2 was approved in 1997. This group of sensor and device manufacturers was also expected to grow after two major companies recently released 1451.2-based chips that can be used to build compliant products.

For example, HP began shipping its two 1451.2 embedded Ethernet controllers in March 1999. They include BFoot 66501, a 4 x 6-in. card with extra connections and ports, and BFoot 10501, a 1.6 x 1.8-in. version that can link devices to the Internet. HP used software development tools, such as Tornado, from Wind River Systems (Alameda, Calif.) to develop BFoot.

HP’s Mr. Van Ness says several OEMs are using BFoot in their designs, while some customers have made pilot installations and are planning to introduce products in 2000. He adds BFoot is being used in a military deployment to turn on a remote chemical detector; in single-loop controllers that monitor chillers and heaters in buildings; and in several flowmeters and pressure transducers.

Sensor and device manufacturers are also using 1451.2-compliant chips from Analog Devices (Norwood, Mass.). The company released its ADuC812 chip in 1998 and launched its ADuC824 chip earlier this year. Analog Devices’ ADuC812 features dual 12-bit DACs and a 12-bit ADC coupled with flash memory and 8051/8052 microcontroller cores.

In the wake of the chipmakers’ support, adoption of P1451 is expected to grow steadily. ‘P1451 allows sensors and device manufacturers to cross that last six inches between their world and the physical world,’ says Dr. Warrior. ‘However, one of the biggest hurdles for P1451 developers is to learn to think more broadly about the mechanics of how they’re making measurements. They have to step back and up a level; think at a higher level of abstraction; and think more about how a particular measurement is important to their application.’

One pioneering developer, Electronics Development Corp. (EDC, Columbia, Md.), is using P1451 to improve its testing systems. EDC recently launched its CogniSense IEEE 1451.1-compatible RS-485 Smart Transducer Network System. It includes EDC 1451.2-NA Network Node, which provides NCAP functions, and EDC 1451.2-SA Smart Transducer Module, which has interface electronics to make transducers smart and can connect to Network Node. EDC’s products also use HP’s BFoot. EDC also recently launched Telemonitor Inc., a new company that will concentrate on Internet-based remote monitoring and control. ‘When we began building a smart sensor module in 1997, the 1451.2 working group instantly solved our problem. We no longer had to worry about what network to use. We just had to support the 1451.2 standard,’ says Robert Johnson, EDC’s president.

EDC is using 1451.2 in an Ethernet-to-Modbus bridge hooked up to a loop controller that has been managing a remote chilled water plant at the University of North Carolina for more than a year. The interface standard gives engineers remote access to the plant’s legacy system. ‘Modbus is a registration-based control system with addresses, so we map its addresses to 1451.2 data channels within a TEDS,’ says Mr. Johnson.

Similarly, The Modal Shop-A PCB Group Co. (Cincinnati, O.) is using two parts of P1451 to help it provide vibration and acoustic sensing solutions. Its LanSharc product is a STIM that comes in a 1451.1 and .2-compliant version and a 1451.4-compliant version. These are installed in a package that can accept Ethernet on one side and Modal sensors on the other to help make acoustical measurements.

‘P1451 means we don’t have to worry about the network, and can concentrate on measurements and reducing vibration,’ says Mark Schiefer, Modal’s senior scientist. ‘The common interface gives me a building block approach to measuring and control solutions. It saves an order of magnitude in time, space, and dollars.’

Dr. Bryzek adds that Maxim is developing a new line of silicon pressure sensors that will provide some basic TEDS in devices. They will likely be introduced in early 2000.

Other companies making P1451-related products include Endevco (San Juan Caspistrano, Calif.) that produces Smart Modal measurement system for model analysis. Smart Modal includes Smart Isotron accelerometers, with a built-in P1451.4-based TEDS, and Smart Isotron signal conditioner.

In the future, Mr. Lee adds TC9 will likely focus on other Ethernet-related applications and may work on standardizing some wireless sensor communications. He adds that interested parties should call him at NIST.

Dr. Warrior adds that 1451.2’s rich data set means it can be used, not just for analog data, but also for vectors, coordinate sets, time series, and Spectra-based applications.

‘I believe these P1451 efforts will result in a new generation of products that will jump the existing generation of buses for sensors, and go directly to Internet connectivity for the creation of global sensor and actuator networks,’ says Dr. Bryzek. ‘Fieldbus will be restricted to local plant control, but P1451 will be what you see wherever you go on a global scale. I don’t know of any other system that allows standardized transmission of information about the physical units these devices use for operation.’

Parts of IEEE P1451 Standard for a Smart Transducer Interface for Sensors and Actuators

1451.1

What: Network-Capable Application Processor (NCAP) information model.

Function: Defines the common object model for smart transducers and tries to find the interface specifications to the components of that model. Proactively defining their behavior helps make devices network neutral and easier to configure.

Status: Approved as a standard, June 1999. Publication expected in early 2000

1451.2

What: Transducer-to-microprocessor communications protocols and Transducer Electronic Data Sheet (TEDS) formats. Includes connection schemes listed as 1451.2.

Function: Defines interface standard for analog to digital communications

Status: Approved as a standard, Sept. 1997; published in 1998

P1451.3

What: Digital Communication and TEDS formats for distributed multidrop systems

Function: Seeking to use 1451.2 as baseline for developing TEDS for distributed multidrop network systems that use higher bandwidth data.

Status: May be approved by summer 2000.

P1451.4

What: Mixed-mode communication protocols and TEDS formats for piezoelectric devices

Function: Trying to define mixed-mode communications that will use reversed polarity to allow first the digital transmisssion of TEDS data, and then the sending of an analog transducer signal over the same two wires.

Status: May be approved by summer 2000

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.