Design Feature: June 22, 1995
For anyone attempting to choose a sensor-interface or -networking standard, the range of choices is overwhelming. Some standards are open, and some are proprietary to a company's control products. To remedy the situation, the IEEE and the National Institute of Standards and Technology (NIST) are developing the IEEE TC-9 Smart-Sensor Communication Standard. The standard, which is due at year's end, will unite the fragmented sensor market.
The sensor market comprises widely disparate sensor types (see Question 4 in the questionnaire on pg 54). Designers consume relatively large amounts of all types of sensors. However, the lack of a universal interface standard impedes the incorporation of "smart" features, such as an on-board electronic data sheet, onboard A/D conversion, signal conditioning, device-type identification, and communications handshaking circuitry, into the sensors.
A universally accepted sensor-interface standard will not only allow for the development of smarter sensors but also lead to lower expenses because it costs less to design to a single standard. To develop the new standard, the IEEE and NIST considered the pros and cons of the following standards at a smart-sensor workshop in March 1994:
The IEEE and NIST decided against adopting one of these network protocols as the single standard. According to the study, users will have different preferences for hardware implementations because of the emerging status of the low-cost smart-transducer industry. For some designers the sensor's compatibility with the devices' instrumentation is important. Other designers will take company alliances into account. And, still others will make choices based on personal preferences. The study concludes that standard setters can't force users to implement a specific smart-transducer protocol, especially when other system components are using different approaches (Ref 1).
The IEEE and NIST decided instead to develop a hardware-independent communication standard for low-cost smart sensors that includes device models and interfacing to selected low-cost networks, such as ISP, CAN, LonWorks, and J1850. The key phrase here is "hardware-independent." Designers will not have to develop smart sensors for any particular network protocol. Instead, the standard will lead to the development of a generation of smart sensors and associated network-adapter circuits that are not committed to a particular network.
A smart-sensor/actuator model
To ensure that the standard incorporates all the necessary parts, the IEEE and NIST interviewed designers and suppliers for input. The group found that many control-network applications are available, each with strengths for a given application and weaknesses for others. Each network requires a large development effort, especially by the traditional sensor or actuator manufacturers still using analog communication technology, such as 0.5 to 4.5V or 4 to 20 mA. Manufacturers can't transport the development effort to other networks. This scenario creates a major stumbling block for the manufacturers, which are typically small companies with limited R&D budgets. These companies are usually unfamiliar with sophisticated networking technology.
The IEEE and NIST aim to lower the networking entry barrier for sensors and actuators by creating the hardware-independent standard. Standardization will encompass the formation of two software models: The smart sensor/actuator model describes a standardized behavior of sensors or actuators in terms of interfacing signals, such as read/write, open/close. This model requires the presence of a standardized transducer electronic data sheet (TEDS) in a memory. The TEDS will include such information as the device model, the name of the manufacturer, the range, and the accuracy. The networked smart-sensor/actuator model maps, or translates, the network-capable application processor (NCAP) onto a specific network. The NCAP will interface with a smart-sensor/actuator model and will include application-specific software that supports the interfacing signals, such as the FFT algorithm.
The numbers in Fig 1 represent locations for possible standardization of the proposed interface. The network interface in Fig 1-1 takes data packets from the network processor in a form appropriate for the network. The sensor-signal processor is a type of ADC that covers the analog signal (Fig 1-4) from the sensor/actuator to a digital form (Fig 1-2), suitable for network adaptation by the network processor.
As Fig 1 shows, three levels of sensor smartness, or completeness, are possible. The transducer has no smartness at all and simply translates the sensed quantity into an analog signal. The smart sensor/actuator has onboard A/D conversion and an electronic data sheet. The networked smart sensor/ actuator has the features of the other two and also contains the adapter, and possibly application-specific software, for the network.
Benefits to the user
A smart-sensor standard will offer compatibility with the majority of control networks suitable for analog output sensors, such as pressure sensors, and actuators, such as proportional valve. The standard will eliminate the need to develop new network hardware, allowing you to develop standardized software. You can easily transport this software to different networks. The development effort to produce the first network interface for the analog-output sensors/actuators will drop by about 50%. This drop will result in a 90% reduction in the development effort for subsequent network interfaces for the same sensors/actuators. The standard will also establish plug-and-play compatibility between sensors and networks, allowing interfaces of given sensors/actuators to different networks.
| Looking ahead |
|---|
|
The proposed smart-sensor interface standard will provide many benefits to the industry. Sensor developers can incorporate smarts into their devices without worrying about network-protocol compatibility. Designers who integrate sensors into their factory-automation or process-control systems can count on an easier integration process. Assume, for example, a DeviceNet application needs a particular temperature sensor. Previously, a system integrator had to convert the sensor's analog output to digital form, then format the digital signals to satisfy the network protocol. With the new standard, sensor manufacturers will produce devices that have onboard A/D converters with outputs that are compatible with a variety of network processors.
The sensor-to-network-processor industry is another market that the standard will spawn. For example, a DeviceNet integrator must simply connect the sensor to the network processor, and the system is ready to go. Depending on industry usage, the temperature sensors might contain all the smarts necessary to connect them directly to DeviceNet. You can expect self-test of sensors that use the new standard and direct delivery of diagnostics information to the network. |
References
| For free information... | |
|---|---|
| For free information on the proposed smart-sensor interface standard discussed in this article, contact the following organizations directly. When you contact them, please let them know you read about their standardization project in EDN. | |
| National Institute of Standards and Technology Gaithersburg, MD (301) 975-6602 |
Roger Grace Associates San Francisco, CA (415) 821-6881 |