A Smart Sensor Bus for Data Acquisition

Lee H. Eccles, Boeing Commercial Airplane Co.

As we were developing a data acquisition (DA) system for the Boeing 777, we determined that we needed several new sensors. Some of those we selected had digital outputs and internal compensation to correct for the effects of temperature and nonlinearity. Each type of sensor had a different output characteristic, so what we needed was a standard interface between the detectors and the DA system. Lacking the time to develop one, we had to tailor an interface for each sensor.

Once we had completed the DA system and testing was under way, we decided to address the issue of defining a standard interface. The bus would thus be ready when we had to meet the next airplane development deadline. We contacted several other testing organizations within Boeing and discovered that others had the same problem. The team we subsequently created gathered the pertinent user requirements and is using them to define a standard interface that could be the basis for a distributed DA system.

(This idea is not new—the lighting in new commercial buildings is often controlled by signals transmitted over the power wires, simplifying the wiring scheme and reducing its costs, assuming that the electronics cost less than the wiring.)

The size and cost of signal conditioning components have until recently prohibited their installation near the sensor or inside its housing. Modern ICs, however, and especially ASICs, have reduced the size and cost of these components to the point where we now believe it will be less expensive to install the signal conditioning and the ADC inside the housing or very near the sensor itself. This arrangement will allow the signal conditioning to be optimized for the specific sensor. The elimination of long cables will permit us to measure not only the physical variable of interest but also other factors such as temperature or pressure that may cause measurement errors. The complex ICs and microprocessors will allow the detector output to be compensated for such variables. Digital filtering can be applied to the output of the ADC to remove any noise outside the band of interest. This all leads to a more accurate measurement for the same or less cost. Digital techniques and microprocessors will also allow the sensor to perform self-diagnostics in ways not possible with conventional methods.

The greatest benefits, however, will be realized only if we work together to define the interfaces to these devices so that the cost advantages can be realized.

We paid particular attention to work carried out by the IEEE and the National Institute of Standards and Technology (NIST) toward a standard definition of the elements that make up a smart sensor and the various device-level interfaces. "Smart sensor," as used in this article, refers to any sensor that produces a digital output. We decided to adopt a variation on the IEEE/NIST model for the sensors in our system. This model was later revised, and our version reflected those changes (see Figure 1). The primary difference between the IEEE/NIST models and the Boeing models is the presence of an analog output that some users wanted for troubleshooting problems with the system. In addition, some of the laboratory groups are considering attaching actuators to this DA tool.

Figure 1. In this smart sensor, as defined in IEEE 1451.2, the NCAP is the interface between the sensor and the user's network. A smart transducer interface module (STIM) may contain several different sensors and must incorporate a transducer electronic data sheet (TEDS). The TEDS is a nonvolatile memory containing a detailed, machine-readable description of the STIM.

System Concept
In the general concept we developed (see Figure 2), each of a number of buses in the lab or on the airplane would connect a number of sensors or actuators to a central DA and/or control system. The number of buses required and the number of sensors on each would be determined either by the physical addressing limits on the bus or by the total number of samples required from all the transducers. The bit rate of the bus would thus in many cases determine the number of sensors that could be connected to it. A number of these transducer buses could then be interconnected to form a complete system. For systems located in a small area, the buses could be connected directly to the DA system. For systems spread out over a large area, the buses would be attached to a hub or hubs connected to the DA system or control room via a high-speed data link. The connection between the hub and the host controller requires more investigation. Some of the labs might require a link up to 1 km long, but <100 m would be sufficient for onboard purposes if a hub is needed there at all.

Figure 2. In a smart sensor system, as envisioned by the Boeing Commercial Airplane Co. interface team, multiple buses would be installed on a test object or airplane and connected to a concentrator or hub at the test site. A single high-speed cable or fiber-optic link would provide the interface to the host computer, which could be in a control room remote from the test site.

Data Sampling Requirements
If a large number of sensors are going to share a common data transfer medium, there must be some way to sample the sensor data and transmit them to the host either upon request or at the proper time in a sampling schedule. To keep the number of wires to a minimum, data transfer should be done serially over a single pair of wires and power for the sensors should be transmitted over this same pair. The interval between samples of a given sensor's output must be fixed and repeatable to within ±2 µs for proper reconstruction of the data during processing. This is a requirement also for the user, who needs to know the order in which events occurred. In some cases the characteristics of the sensor will determine how well these two requirements can be met. For example, a sensor measuring a frequency will need to acquire its samples at the zero crossings of the input waveform that will not be synchronized by the data system. If these types of sensors are going to be required to meet the ±2 µs time constraint, they must be given time-tagging capability.

The same principle holds true for groups of sensors on a given bus. To satisfy the ±2 µs requirement, the data are held in the sensor until time to transmit the information to the host. The system requires some sort of common clock, which could take the form of the host's commanding each sensor to sample and transmit its data. Alternatively, the host can provide periodic time commands and allow each sensor to maintain the time interval between the host's commands. The command-response mode drives up the amount of traffic on the bus, but a higher degree of complexity is required of sensors that must maintain their own clocks that are synchronized by the host's time commands.

Adding in overhead, error correcting codes, and dead time between transfers increases the minimum bit rate to somewhere on the order of 1 3 106 bps. A command-response type of system would probably need twice this rate. The number of sensors that a given bus can support is either increased or decreased, depending on whether the sensors connected to it are designed to transmit more or less than 16 bits. This number must still be taken into acount in figuring the total number of bits per second, and the rates for all the networked sensors on a bus will not necessarily be uniform. The rates may differ, for instance, as a result of a single pair of wires' being run into a particular area, such as an engine, and connected to temperature, pressure, and vibration sensors. If all the sensors had to respond at the same rate, the vibration sensor would drive the data rate and only two sensors would be able to share a pair of wires.

Operational Requirements
Users placed several operational requirements on the bus and sensors. One universal demand was that each sensor be able to identify itself to the host. Each should also be able to run an internal diagnostic. Also desirable was the ability to read and write the sensor's stored memory over the bus to facilitate system setup. These requirements conflict with the controlled sample intervals and known time of the data samples described earlier. A satisfactory solution entails two operating modes for the bus. In the DA mode, all the timing constraints are met and no unnecessary communications are allowed. In setup, all communications are supported and data are acquired, but the sample timing requirement is not adhered to.

This is a natural way for the system to be used. During a test, the system runs in the DA mode and no one is permitted to request memory dumps or set up a sensor. When no test is in progress, the system will be used to set up for the next test and troubleshoot problems on the network. The assumption is that when the system is in the setup mode, the DA schedule will be running in the background without the timing guarantees.

One common problem that could take the system down is a continuously transmitting sensor. Each sensor should therefore have a built-in capability of detecting this condition and shutting itself off. The most promising approach for finding shorts and opens on the bus may be related to the physical bus topology. A topology or implementation is needed that will allow parts of the bus to be quickly isolated for troubleshooting, but even this may be difficult if the bus is buried in an airplane wing. Error-correcting codes and other techniques that make a bus more robust will help, but the best solution cannot be devised until the technology is selected.

The addition or removal of a sensor from an active bus should not cause more than a momentary interruption of bus operation. For example, a transmission in progress when a sensor is connected can be corrupted. That is acceptable, but after the transient on the bus is gone, the bus must continue in normal operation without any operator action. It is not acceptable to have to reset the bus or system to recover from this type of event.

There are other criteria as well, but we would prefer to use a generally available standard that outside vendors can readily understand and follow in qualifying parts without working directly with us, at least at this stage. In some cases, the environmental requirements will be so specific for a given sensor that a general specification will not be useful, but we hope that this is the exception and not the rule.

In the U.S., Fieldbus Foundation has joined forces with World FIP to complete the work begun by ISA. This effort has thus far resulted in a definition of the physical layers of a fieldbus, as laid out in ISA Standard S-50 Part 2. The total capabilities of this bus cannot be determined since the higher protocol layers have a significant effect on the data sampling rate.

The only other fieldbuses under consideration are ProfiBus and World FIP. ProfiBus has several different speed ranges; ProfiBus-DP, with rates up to 12.5 Mbps, would appear fast enough but we are finding some features we do not like. For example, all devices on the bus must be sampled at the same rate. World FIP comes the closest to meeting all our requirements but cannot handle our requisite 12,800 sps per bus.

We are also investigating Firewire and the Universal Serial Bus (USB). Because both are designed for use with PCs, they have the necessary bandwidth and the chip sets to support them will be widely available. The USB has a too-short physical limit of 5.5 m between active nodes on the network. Firewire has a similar limit, but we do not know what it would take to extend it.

The final option under consideration is to take one of the existing field buses and modify it to add a different physical layer and any required protocol changes. This might be the only way to meet most of our requirements. We still have quite a bit of work to do toward determining which bus to use and how to implement it, but we expect to accomplish most of our goals.

Adapted from a paper presented at the 1996 Summer Test and Measurements Conference, sponsored by the Western Regional Strain Gage Committee, Society for Experimental Mechanics, 6­7 August 1996, Bethel, Connecticut.

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.