SAE J1850 Bus Offers New Dimension to In-Vehicle Data Acquisition

As automotive-related safety and comfort standards continue to increase, so does the electronic complexity of the vehicles. This has led to the use of a serial communications protocol to link the various controllers and electronic devices on a single- or dual-wire bus. For these communications, domestic manufacturers have adopted the Society of Automotive Engineers (SAE) J1850 Bus Protocol, a Class B Data Communication Network Interface.

Besides establishing communications among electronic subsystems, the J1850 bus offers a new dimension for in-vehicle data acquisition by combining it with traditional analog/digital measurements for a variety of testing procedures. The benefits of this network include:

Reduced weight of the electrical wiring.

Improved reliability of connections.

Standard messaging format.

Increased vehicle performance.

SAE J1850 Communication

The SAE J1850 bus protocol is a multimaster serial communications format (see sidebar). Some microcontrollers directly support this format. With firmware revisions, it is possible to make other microcontrollers compatible with J1850.

A similar, yet nonconforming, protocol is the Common Area Network (CAN) interface, which has a strong acceptance in the European and Asian automotive communities and in the global industrial automation market. Other protocols in the automotive community include ISO 9141 and other older, slower formats.

Each domestic automotive manufacturer has implemented its messaging format on top of the standard networking protocol defined by the lowest two layers of J1850. In other words, even though some of the communications protocol is implemented in the same fashion, the way messages are sent and received is unique to each company.

In-Vehicle Data Acquisition

In-vehicle data acquisition is a fundamental procedure for evaluating a system in real-world conditions. For instance, engineers developing brake systems may equip a vehicle with various load, strain and temperature transducers and take the vehicle through a series of maneuvers. This analog data is recorded for each run and analyzed once off the test track. In most cases, a visual display monitors signals during a test run.

There are many systems on the market for traditional in-vehicle data acquisition applications. The proprietary systems contain the sensors, signal conditioning, acquisition and storage in one unit. The modular PC-based systems combine standard data acquisition hardware with common programming languages. In any case, the in-vehicle data acquisition system must be reliable, accurate, rugged and small enough to fit easily in a vehicle with passengers.

Traditional transducer-based in-vehicle data acquisition can be limiting for some facets of engineering development. The analog/digital measurements give information about the environmental surroundings and the performance of the mechanical systems on the vehicle, such as wheel speed, brake temperature and suspension loading.

On the other hand, information about the condition and performance of the system controllers, such as the airbag, anit-lock brake system (ABS) and power train, is not as easily gathered with this architecture. Here is where the J1850 bus is valuable. It offers an easy, single-point connection for controlling and monitoring the subassemblies connected to the network.

By using the J1850 bus to acquire data, you can now gather both analog/digital transducer and vehicle bus data simultaneously for complete system evaluation. The synchronization of these two forms of data is a powerful method for analyzing the linkage between a mechanical system (brakes) and the system controller (ABS controller).

This dimension benefits several engineering areas. An engineering effort responsible for performing traditional analog/digital acquisition could develop a complete picture of the system if it is possible to capture parameters that are on the vehicle bus. Parameters like vehicle speed, engine speed, temperature, O2 readings and pressure offer valuable information and are all accessible by way of the J1850 bus without an extensive knowledge of the protocol.

This type of data acquisition system can also benefit vehicle electronics. Besides gathering extensive information from the controller via the J1850 bus, the information can be enhanced by combining it with traditional analog/digital transducer data. This might include temperature and vibration of the controller or additional data anywhere on the vehicle.

System Considerations

As with the traditional in-vehicle data acquisition system, the equipment gathering bus information must be reliable and portable. Some of the common J1850 interface form factors are:

Stand-alone box linked to RS-232 serial port.

Plug-in card for ISA slot on a desktop PC.

Plug-in card for PCMCIA slot on a laptop PC.

The flexibility offered by having both bus and analog measurement capabilities in the vehicle lends itself well to a modular system architecture. In a virtual instrumentation format, the ruggedized portable PC is the central component for data display, analysis and storage. You can then add a J1850 bus interface, multiple channels of analog/digital, or both to configure the best system for each test run.

Proper buffering of both analog/digital and bus data is essential to achieve direct correlation between the two. Synchronization of these two data sources is difficult since the J1850 messages cannot be controlled with an external clock.

The primary task of the electronics connected on this network is to perform a

vital function such as engine control or airbag deployment. Consequently, sending data to the bus obviously is a lower-priority task. Combined with the fact that J1850 allows bus arbitration, it is easy to understand why it is difficult to achieve precise synchronization.

A bus diagnostic tool on the network can request data at a certain rate, but there is no way to guarantee that those rates will be attained. Data capture from an automotive bus is unlike traditional analog/digital acquisition where captured data is

supplied synchronously with a precise, external clock.


Much of the functionality of a modular PC-based data acquisition system is found in the software. In that sense, the software should provide the same interface for test configuration, data analysis, data storage and data display, even if it is a combination of bus and analog/digital transducer data.

A graphical user interface offers the capability to quickly determine the characteristic of a particular variable. It is important to have both analog and bus data displayed on the same interface in a graphical format to easily determine the linkage between different data points. This prevents reading cryptic bus traffic and toggling between an analog measurement system and a bus monitoring system.



Another important aspect to viewing bus traffic simultaneously is the capability to offer displays conducive to the data type received. Data transmitted on the J1850 bus can take a variety of forms, such as:

Numeric Parameters: engine speed, vehicle speed, braking pressure.

Bit-Mapped Parameters: switch open/closed, solenoids enabled, doors ajar.

State Encoded Parameters: which gear state.

It is more intuitive to view engine speed on a graphical chart and switch closures as on/off lights, than just a display of text information. The software must handle these various formats and offer display capabilities reflective of the data types.

Since the J1850 is a multimaster bus, traffic exists from many sources on the network. User-definable filters may be employed to limit the traffic to be processed.

Each domestic manufacturer has a messaging format. There is also the variability within a given platform, since data location and parameter address locations vary from model to model. Given this degree of variability between messaging formats and parameter addresses, it is vital to keep this information modular.

Other Communication Protocols

Plans for the future in automotive networks include adopting Class C Data Communication Network strategies (>125 kb/s) which may use some other medium (fiber optics). The architecture of a PC-based modular data acquisition system allows flexibility for these different interfaces. Just as it is important for the system to adapt to various messaging and parameter address schemes, it is equally important to adapt to other interface protocols.

This dimension for in-vehicle data acquisition offers a convenient and low-cost method for gathering a complete image of the system under evaluation. By adding a serial interface that supports J1850, both transducer and bus information can be acquired simultaneously.

About the Authors

Gregory Swanson is a District Manager at VI Engineering. Previously, he was a Sales Manager at National Instruments and a Test Engineer at Delco Electronics. Mr. Swanson holds B.S.E.E. and M.S.E.E. degrees from the University of Minnesota. VI Engineering, 931 E. 86th St., Suite 104, Indianapolis, IN 46240, (317) 466-0706.

Aaron Grzymkowski is the Product Development Manager at VI Engineering. He received a B.S.E.E. degree from the University of Michigan. VI Engineering, 37800 Hills Tech Dr., Farmington Hills, MI 48324, (810) 489-1200.

 

Sidebar

SAE Standard J1850 Class B Data Communication Network Interface

The J1850 protocol encompasses the lowest two layers of the International Standards Organization (ISO) open-system interconnect model—the data link layer and the physical layer. This multimaster system uses the concept of carrier-sense multiple access with collision resolution, whereby any node can transmit if it has determined the bus to be free.

Nondestructive arbitration is performed on a bit-by-bit basis whenever multiple nodes begin to transmit simultaneously. J1850 allows for the use of a single- or dual- wire bus, two data rates (10.4 kb/s or 41.7 kb/s), and two bit-encoding techniques: pulse width modulation (PWM) or variable pulse width modulation (VPW).

A J1850 message, or frame, consists of a start of frame delimiter, a 1- or 3-byte header, 0 to 8 data bytes, a cyclical redundancy check (CRC) byte, an end-of-data delimiter, and an optional in-frame response followed by an end-of-frame delimiter. Two header formats, 1-byte (nonconsolidated) and consolidated (1- or 3-byte), exist under SAE J1850.

Frames using a 1-byte nonconsolidated header are transmitted at 10.4 kb/s using VPW modulation and contain a CRC byte for error detection. Frames using a 1-byte or 3-byte consolidated header can be transmitted at either 41.7 kb/ or 10.4 kb/ using either PWM or VPW modulation techniques and contain a CRC byte for error detection.

Each frame can contain up to 12 bytes (VPW) or 101 bit times (PWM), with each byte transmitted MSB first. The optional in-frame response can contain either a single byte or multiple bytes, with or without a CRC byte. The requirements of each network determine which features are used.


Copyright 1996 Nelson Publishing Inc.

October 1996


Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!