Data Acquisition from HD Vehicles Using J1939 CAN Bus

By Richard Walter and Eric Walter

Modern vehicles have electronic control units (ECUs) to control various subsystems such as the engine, brakes, steering, air conditioning, and infotainment. These ECUs (or simply ‘controllers’) are networked together to share information, and output directly measured and calculated data to each other.

This in-vehicle network is

• Language: English
• Publisher: SAE International
• Release date: Oct 17, 2019
• ISBN: 9780768083101

Book preview

Data Acquisition from HD Vehicles Using J1939 CAN Bus

Chapter 1: Benefits and Applications of the In-Vehicle Network for Data Acquisition

Print ISBN: 978-0-7680-8172-5

eISBN: 978-0-7680-8310-1

https://www.sae.org/publications/books/content/R-446

Chapter 1

Benefits and Applications of the In-Vehicle Network for Data Acquisition

1.1 Overview—Data Gold Mine

Modern vehicles have electronic control units (ECUs) to control various subsystems such as the engine, brakes, steering, air conditioning, and infotainment. These ECUs (or simply controllers) are networked together to share information. This information is a potential data gold mine for the data acquisition user. Figure 1.1 shows an example of ECUs on a typical truck in-vehicle network.

Figure 1.1

Figure 1.1 Typical ECUs located on a vehicle. (Ref. [1-1])

Each controller has its own data acquisition system which consists of sensors, signal conditioning, an analog-to-digital converter, and processor. Each controller outputs directly measured and calculated data to the network to communicate with other controllers. The number of controllers varies across vehicle models. Ten controllers are common on an HD truck, while some luxury cars are approaching 100 controllers.

Here are the major functions a typical engine ECU performs:

Digitization of sensor data in real time

Interpretation of the sensor data

Adjustment of its actuators in real time for optimal air-fuel mixture, ignition timing, idle speed, etc.

An ECU consists of both hardware and software (firmware). The acronym ECU is used by some to designate the engine control unit. We will use ECU for electronic control unit only, meaning that it can refer to any controller on the vehicle.

1.2 Focus and Assumptions of This Book

The focus of this book is acquiring data from the in-vehicle network of HD vehicles using the SAE J1939 standard. This standard is used by medium-duty and HD vehicles including on-road trucks and buses and off-road vehicles for agriculture, construction, and mining.

There will be comparisons with light-duty (LD) vehicles (cars and LD trucks) to point out major differences. It is assumed that the vehicle's network is working properly, and debugging the in-vehicle network is not a focus of this book.

1.3 Access to the Data

Accessing the in-vehicle network data requires electronic hardware (a test tool) such as scan tool or a data logger. The test tool can interface with a PC or mobile device or work as a stand-alone data logger. The test tool appears as another controller on the in-vehicle network. Theoretically, the test tool can access all the data that the other controllers can access. The challenge for the test tool is to locate the messages of interest and convert them into useful data.

1.4 Normal and Requested Messages

There are two categories of in-vehicle network messages: Normal and Requested. Messages that are regularly sent without a request are Normal messages. Messages requiring a request are Requested messages. Normal messages are sometimes called Standard, Periodic, or Raw CAN (controller area network) messages. The term Normal will be used throughout this book. Requested messages are also referred to as Polled, Event-Driven, or Diagnostic messages in LD On-Board Diagnostics (OBD).

1.4.1 Normal Messages

Normal messages share information across controllers and are critical to the vehicle's operation. Either the Original Equipment Manufacturer (OEM) or the J1939 specification determines the necessary sample rate and resolution for the HD parameters that are sent within the Normal messages. The OEM has the challenge of not overloading the network bus by limiting the amount of Normal messages. Normal messages are on LD and HD vehicles, but only HD industries have standardized the information contained in the Normal messages.

1.4.2 Requested (Diagnostic/Polled/Event) Messages

Requested messages are not required for normal vehicle operation, and they typically change very slowly. Examples are distance traveled (odometer) or total engine run time.

1.4.3 Requested Versus Normal Messages

The Diagnostic/Polling/Request model used for LD OBD-II has the following traits [1-2]:

Increases tool communication demands for parametric data

Permits fully optimized point-to-point communication

Is implemented in SAE J1978/SAE J1979

The Normal model used by J1939 for HD vehicles has the following traits:

Transmits messages at specific time intervals to all controllers and the test tool

Less demand on the test tool since requests are not being made

Transmits only data that other controllers need; a key point is that the test tool will often not have access to the data if not transmitted as a Normal message

Has a standard database defining messages (J1939/71 and J1939/DA)

North American HD vehicles have used normal messages since 1988 (starting with SAE J1708 discussed in chapter 5)

1.5 Comparing Light- and Heavy-Duty Vehicle Designs

The HD vehicle test engineer will generally use Normal messages for data acquisition. In contrast, the LD vehicle tester primarily uses diagnostic messages. The reasons for this difference become clearer when we compare the two industries:

Table 1.1 compares various attributes of (LD) and (HD) vehicles. The first and last bullets are key factors that affect the number of parameters available to the test engineer. The HD industry controllers are much more likely to share information with other controllers than LD industry controllers. An HD vehicle customer often specifies the manufacturers for various subsystems such as the engine, transmission, HVAC (heating, ventilation, and air conditioning), and brakes as shown in Table 1.2. This means that each HD subsystem needs to share data with controllers from other manufacturers.

Table 1.1 Characteristics of LD and HD Vehicles that Affect the Data Present on the In-Vehicle Network

Table 1.1

Table 1.2 Variations in Suppliers to Vehicle Manufacturers (Ref. [1-2])

Table 1.2

The J1939 specification published in 2005 specified nearly 2000 parameters, and the 2012 version specifies over 5000 parameters. Typically, the number of parameters broadcast on an HD vehicle ranges from 150 to 600. This number is highly variable between models, model years, and types of HD vehicles.

In contrast, the LD OEMs (not their customers) specify all the controllers on the vehicle. Therefore, they do not need to make the Normal message specifications readily available. The Normal messages are kept so confidential that very few people within the OEM organization have access to the information. In general, the HD industry readily shares Normal messages, while the LD industry guards Normal messages and strives to keep them confidential.

The simplest way to acquire LD parameters is to request diagnostic messages defined in the OBD-II (J1979) specification. The OBD-II specification has only around 100 parameters defined, and less than 40 are typically supported on any particular vehicle. These numbers do not include proprietary Enhanced OBD (EOBD) parameters that are used by a service scan tool. For EOBD parameters it is difficult to obtain the information to relate the parameters to messages.

Figure 1.2 shows an example HD network configuration with multiple network segments. Multiple network segments organize the messages and increase the total number of messages that the network can handle. Most controllers do not need to utilize most messages on the vehicle, so multiple networks are a valuable way to reduce traffic. A Gateway Controller is required to bridge one network to another: a Gateway Controller routes traffic between multiple buses of the same protocol and translates the messages before routing to different types of buses. Networks are discussed further in chapter 6.

Figure 1.2

Figure 1.2 Example network configuration. (Ref. [1-1])

1.6 Medium-Duty Vehicles

LD and HD standards intersect for the medium-duty class of vehicles, and it may be difficult to predict