Electronic control units (ECUs) play a major role in making sure today’s automobiles operate at optimum performance. As you know, ECUs control a variety of vehicular functions, including fuel injection, transmission shifting, and anti-lock braking.
What may not be so well known is how engineers gather the data to characterize the performance of these units during automotive product development. There are two basic sources of information: analog data from sensors and digital data that is available on the vehicle data communications network. Much of the developmental data required is the same as that supplied by sensors permanently installed on the vehicle as inputs to the ECUs.
A standardized connector under the dashboard provides access to the data used by the ECUs. However, the data is structured more for diagnostics than for general-purpose data acquisition.
Engineers would like to access this data in a format that allows its use for product development. With this access, they could avoid the installation and removal of separate sensors and associated signal-conditioning equipment for data collection.
Data-Capture Problems
Data and control signals associated with the ECUs are transmitted over a standard data-communications network based on the Society of Automotive Engineers (SAE) J1850 Bus Protocol. Today’s SAE Class B serial communications protocol typically has a data rate of 41 kb/s.1 This rate is sufficient for many PC-based data acquisition projects; but in some cases, it may not be fast enough. Caution must be exercised when contemplating network-based data collection.
For example, if transient events over 50 Hz are important, then a Class B network might not be a good test solution. The good news is that the next generation Class C network will have throughput rates an order of magnitude higher so you can direct automotive system events as short as 1 ms.
Until recently, the capability to collect general-purpose data from the in-vehicle network was hampered by a lack of easy-to-use hardware and software. The data acquisition characteristics of the network were designed primarily for automotive system diagnostics on the assembly line, self-monitoring, and service-shop diagnostics. These diagnostic features adhere to the SAE Onboard Diagnostics standard, which does not lend itself to general-purpose test and measurement.
Ideally, an engineer would like to simply plug into a network connector and start gathering data. The engineer also would like to communicate in terms of the engineering units associated with sensor variables and system performance parameters, which is possible with general-purpose data acquisition software. When dealing with the in-vehicle network, many problems prevent such a straightforward approach.
Unlike direct data acquisition from analog sensors, network data is buried inside a digital message. To acquire a network parameter such as engine speed in rpm or manifold air pressure in psi, you need to know which message unit carries the data and where it is located within the message.
Figure 1 illustrates a typical message format defined by the SAE J1850 protocol.2 However, each ECU manufacturer has its own way of structuring data within a message unit. Some have one parameter per message; others have numerous parameters per message.
The data you want may not occur on the network unless a message is sent requesting it. This is due to Carrier Sense Multiple Access Contention Detection, a data traffic-control scheme that prevents the network from being overwhelmed by simultaneous transmissions of multiple messages. So the second requirement for acquiring network data is the capability to send a prompt to a specific ECU to request transmission of the desired message.
A third problem is to determine the type of message that carries the data you want, and whether prompting is actually required. Functional messages often do not require prompting, but physical messages usually do.
Functional messages are vehicle-function dependent, but independent of the physical location of the function. Messages legislated by J1850 generally are functional messages.
By contrast, physical messages are device dependent, and the physical location must be known to obtain information from the device. Generally, these are nonlegislated messages and the ones of most interest to development engineers.
Capturing Network Data
In the past, automotive-system manufacturers developed their own hardware and software for general-purpose network data acquisition. That is no longer necessary. The availability of network communications interfaces with scanning software now makes it possible to combine analog and network data acquisition in the same test and measurement system. Firms supplying these commercial products include the Dearborn Group, Cubic Systems, and Advance Electronic Diagnostics (AED).
Dearborn Group supplies a serial network communications box. Cubic Systems has a serial and parallel communications box that incorporates analog and network communications functions. The AED hardware is a PCMCIA card. This commercial hardware and associated driver software handle functional data for a variety of ECUs, but special driver software is still required to acquire physical data for a given vehicle manufacturer.
A complete data-collection system also requires the usual data acquisition hardware and associated signal conditioning. The hardware can take the form of a board residing in a PC’s ISA slot, a PCMCIA card, or an external data acquisition module with an RS-232 connection, a universal serial bus, a parallel port, or an IEEE 488 bus.
Compatible Software
With compatible data acquisition software in place, a request for network data is sent to the network communications interface. The scanning software translates the request to capture a given network parameter, such as engine temperature or wheel speed, and then uses a filter mask to locate the information. In the translation process, the scanning software also determines whether or not the data has to be prompted.
In a manner similar to analog data acquisition, digital network data then is routed to the PC where general-purpose data acquisition software provides data display, high-speed storage, and analysis that can be either real time or postprocessing. Data display options include Y-T and Y-X plots similar to an oscilloscope or strip-chart recorder, a digital meter, or a dial meter. Analysis encompasses digital filtering, integration, arithmetic, FFT, and statistics that can be used for pass/fail analysis.
The general-purpose data acquisition software should work seamlessly with the in-vehicle network interface to allow simultaneous data collection from analog sensors and the network itself. This should be true whether the network data is functional or physical and wherever it resides in legislated or nonlegislated messages.
One application requiring simultaneous collection of analog and network data is the measurement of network latency due to its limited bandwidth. One measurement of network latency is the delay between the time when analog data-sensor data is first available for transmission over the network and the time it actually arrives at the ECU. Latency also is a function of the data update rate, which varies according to vehicle operating conditions. To understand this phenomenon, external analog-sensor data must be acquired in parallel with, and time correlated to, network data. The sensors could be permanently installed on the vehicle.
In other cases, additional sensors may be required to supplement those already on a standard vehicle. For example, suppose you want to determine if a noise is related to engine speed or vehicle speed. The network provides data on both speeds, so you only need to add a microphone or accelerometer to measure ambient or structural noise.
The measure of compatibility between general-purpose data acquisition software and the network interface with its software is determined by:
Smooth communications between the user, who usually thinks in terms of engineering parameters, and the network that operates in terms of messages.
The availability of a data base that relates messages and data acquisition parameters.
Software drivers for the hardware being used, along with a simple communications method between the ECUs and data acquisition software.
The ease in configuring data acquisition channels for both analog and network data.
The capability to display both messages and engineering parameters.
Typical data-base information should include and define parameters such as engineering units, label (name), zero offset, scaling factor, minimum and maximum analog values, and data acquisition rate. This is true for both analog and network data.
In the case of network data however, additional parameters must be defined. These include the ECU address, device ID, filter mask, data length, device header, and data type such as hex or decimal.
General-purpose data acquisition software should efficiently handle this configuration process. Programs that take a data-base approach to storing and using channel parameters make it easy to modify or create new configurations for each data acquisition session.
For example, once they are set up in the data acquisition data base, many ECU parameters can be read directly from the in-vehicle network and be used to build a file defining message prompts and filter masks for a session. Ideally, the software then uses data-base contents across all elements of the software package. This includes virtual instrument definitions, data analyses, displays, and data export to spreadsheets.
Applications
An early use of commercial software for in-vehicle network data acquisition was GM’s anti-lock braking system (ABS) development for light trucks. This combined network data from the ABS control unit with analog sensor data, such as brake-pedal force, hydraulic pressure, wheel rpm, and temperature.
A proprietary network interface was used because commercial hardware was not yet available. The commercial software created overlays of analog and ECU data, such as the ABS wheel-speed analog signal, calculated analog acceleration, and the acceleration signal taken from the in-vehicle network.
Because commercial data-communications interfaces now are available, automakers are accelerating their application of in-vehicle network data acquisition. For example, engine rpm is used in a variety of product development projects and can be obtained from the in-vehicle network (Figure 2).
Besides engine rpm, the in-vehicle network provides information on transmission speed, gear state, shifter position, throttle position, external temperatures, and the transmission solenoid state. On the other hand, it does not provide transmission-fluid pressures which require separate analog sensors.
To completely characterize the performance of an electronic shift transmission, engine rpm and transmission data on the network combines with analog sensor data from transmission solenoid valves, fluid flows, and pressures. The data acquisition software then calculates critical performance parameters, such as clutch energy.
Shortening Development Time
Hundreds of variables available on a vehicle’s data-communications network could be beneficial for product development. Fortunately, you no longer must develop your own hardware and software to collect this data. Some benefits of using commercially available products include:
Acquiring in-vehicle network data as easily as acquiring analog data.
Flexibility in reading a variety of in-vehicle network data bases created by different automotive manufacturers.
Dynamically altering acquired parameters on the fly. Other systems require predefined parameters and messaging prior to the test and data acquisition.
The end result is better test information and improved productivity.
References
1. Swanson, G. and Grzymkowski, A., “SAE J1850 Bus Offers New Dimension To In-Vehicle Data Acquisition”, EE-Evaluation Engineering, October 1996, pp. 32-39.
NOTE: This article can be accessed on EE’s TestSite at www.nelsonpub.com/ee/. Select EE Archives and use the key word search.
2. Walter, R., “PC-Based Data Acquisition Plus On-Board Diagnostics: Tools for Faster Development of Passenger Car Systems,” SAE Paper #960090.
About the Authors
Richard P. Walter, P.E., is the founder and president of HEM Data. Prior to starting HEM Data, Mr. Walter worked with Bendix for 10 years, mainly in the company’s research labs, and was awarded five patents in electronic fuel injection. He has advanced degrees in mechanical engineering from Wayne State University and in management from the University of Detroit.
Thomas McAnnally joined HEM Data in 1994, where he is a software engineer. His previous experience includes the application of microprocessor and data acquisition technology in the development of hybrid electric vehicles. Mr. McAnnally holds a computer engineering degree from Michigan State University.
HEM Data, 17336 12 Mile Rd., Southfield, MI 48076, (810) 559-5607.
July 1997