1/4 www.ni.com

Bookmark and Share

Explore the NI DeveloperCommunity

Discover and collaborate on the latestexample code and tutorials with aworldwide community of engineers andscientists.

Check out the NI Community

Who is National Instruments?National Instruments provides agraphical system design platform fortest, control, and embedded designapplications that is transforming theway engineers and scientists design,prototype, and deploy systems.

Learn more about NI

Creating a CAN Bus Communication Platform Based on the SAE J1939Protocol and NI PXI

"With powerful LabVIEW mathematical analysis and queue processing, NIPXI devices, and a CAN interface module suitable for a harsh vehicle testenvironment, this system provides CAN bus message information analysisfunctionalities required by multiple test conditions."- , Dongfeng Motor Corporation

ReadtheFullCaseStudy

Author(s): - Dongfeng Motor Corporation

All commercial vehicles meeting Chinese National III through National IV emission standards use the bus to communicateCAN between electronic control units (ECU), including the vehicle ECU (VECU), engine ECU (EECU), automatic transmission boxECU, instrument ECU, and antilock braking system ECU. The vehicle control network has implemented the commercial vehicleCAN bus based on the J1939 protocol, combined with the multipoint control unit (MCU), CAN controller, and MCU node CANtransceiver structure. Existing solutions for road tests, engine bench tests, and vehicle electrical environment HIL simulationtests that include a PC, CAN communication module, and software are extremely costly.

Communication Method ProblemsBecause industrial bus message identifiers and data frames in CAN 2.0 B specifications lack common definitions, theparameters are arbitrary. Commercial vehicle CAN bus communication specifications follow the SAE J1939 protocol, based onCAN 2.0 B. Currently, there is no CAN bus communication method based on and the J1939 protocol in a controlLabVIEW PXIdevice application for the domestic automobile industry, so we set out to combine LabVIEW software with the complex J1939protocol to filter, receive, synthesize, recombine, and send messages.

Considering commercial vehicle CAN bus network characteristics, we constructed a CAN bus platform based on LabVIEW andthe J1939 protocol, and embedded it in an NI PXI modular interface device for engine bench and vehicle electrical environmentHIL tests.

Figure 1. J1939 Data Frame Format

J1939 Protocol and CAN 2.0 B Specification DifferencesThe J1939 protocol is based on the CAN 2.0 B specification. The 29-bit ID in the CAN 2.0 B extended frame is defined to form aJ1939 coding system, including priority (P); reserved bit (R); data page (DP); protocol data unit (PF); extended unit (PS); sourceaddress (SA); and data field; as shown in Figure 1. The open system interconnection (OSI) reference model application layercontains seven parts, which are encapsulated in one or more CAN data frames through a protocol data unit (PDU) andtransmitted to other device nodes in the bus network through the physical layer.

Various CAN 2.0 B device functions send different message information using the same ID, so CAN devices selected accordingto specific manufacturer protocol can cause unrecognized or inconsistent IDs during system integration. Each message frame inthe J1939 protocol has a unique identifier and PGN, assigning a unique source address for each node and mapping the sourceaddress to the CAN identifier to avoid multiple nodes using the same identifier. For example, ID: 0CF00400 represents anengine speed and torque message.

The CAN 2.0 B specification defines the data link layer in seven OSI reference model layers, meaning it is a low-level standard,as shown in Figure 2. CAN bus products typically have bad compatibility, interchangeability, and integration. Conversely, J1939is a high-level protocol according to the OSI reference model application layer, which defines vehicle application signals(parameters) and messages (parameters group). The signal is described by parameters, and each parameter is assigned asuspect parameter number (SPN). These parameters define the physical meaning of data bytes in the PDU data field; forexample, SPN190 represents engine speed.

The CAN 2.0 B specification can only transmit single-frame messages, while the J1939 protocol can transmit single- andmultiple-frame messages, including dialogue and broadcast. J1939 can pack, send, receive, synthesize, and reorganizemessages according to the multiple-frame data transmission protocol.

The Challenge:Merging the J1939 protocol into the CAN bus communication platform design.

The Solution:Using NI LabVIEW system design software and an NI PXI CAN communication module to design a method to filter J1939 protocolIDs to receive and send multiple frames according to protocol format and construct a CAN communication platform. We alsoimplemented a complete vehicle hardware-in-the-loop (HIL) electrical environment simulation, and constructed an engine benchtest platform that includes CAN bus message sending and receiving, storage, and real-time display.

2/4 www.ni.com

Figure 2. OSI Reference Model

Module InterfaceThe module interface consists of an NI dualport transceiver, an SJA1000T CAN controller, a TJA1041T high-speed PXI-CANCAN transceiver, and a TJA1054AT low-speed CAN transceiver. The J1939 protocol data link layer packs messages accordingto PDU format, and performs CAN data frame synchronization, sequential control, error control, and flow control.

According to the J1939 physical layer protocol, each network segment can includeUp to 30 ECUsA CAN bus communication rate of 250 kB/sBus voltage that includes dominant and recessive levelsA differential voltage of 3.5 V or 1.5 V

Additionally, the CAN bus transceiver converts the voltage level between the CAN bus and the MCU.

Software DesignAs shown in Figure 3, the CAN bus message based on the J1939 protocol multitask processing flow uses a producer andconsumer loop structure. The producer loop uses the elements enqueue function to add data to the message cluster queue, andthe consumer loop uses the element dequeue function to move data out of the message cluster queue. The queuecommunicates between loops to avoid conflicts between multiple tasks. When data production is faster than data consumption,the queue buffers avoid message data loss.

Figure 3. CAN Bus Multitask Message Transceiver Based on LabVIEW and the J1939 Protocol

ImplementationAs shown in Figure 4, we implemented the CAN bus communication platform based on LabVIEW and the J1939 protocol in anHIL vehicle electrical environment simulation for a message receiving test. We simultaneously compared it against the VectorCANoe module. Figure 7 shows the EECU message received from a steadily running engine. In one second, the system canreceive a 526-frame message from the EECU without losing a message.

The engine fuel consumption message reveals engine fuel efficiency in real time. The VECU receives the message in the CANbus network according to commercial vehicle J1939 protocol to control the automatic gearbox vehicle shifting. The combinedinstrument ECU receives and displays this message in real time to remind the driver of good driving habits and manipulate thevehicle to achieve the best fuel efficiency. For optimal engine performance, efficiency, and emissions standards, we calibratethe EECU to obtain the best injection pulse-width calibration parameters. After calibration, we conduct a comparative test toverify EECU calibration effects.

An engine steady state test can reveal vehicle performance at a constant speed. An engine transient test in variable workingconditions simulates engine state in actual road conditions. By comparing the real-time fuel consumption message and theactual instantaneous fuel consumption measurement, we determine the EECU control performance.

3/4 www.ni.com

Figure 4. Vehicle Electric Environment HIL Simulation Test Engine

Figure 5. Test Bench

Figure 6. CAN Bus Communication Platform Based on LabVIEW and the J1939 Protocol Implementation

Figure 7. Engine Steady State EECU Message

Figure 8. Fuel Consumption Comparative Test in Variable Engine Working Conditions

Figure 8 shows a comparison measuring the engine transient fuel consumption bench test curve in 10 working conditions. The

4/4 www.ni.com

Figure 8 shows a comparison measuring the engine transient fuel consumption bench test curve in 10 working conditions. TheEECU fuel consumption message data received and parsed by the CAN bus according to the J1939 protocol is markedlydifferent when the engine is running under low load, compared with the test and bench fuel consumption meter. Thus, actualfuel injecting is low when the engine is running under low load. Target and actual fuel injection amount varies greatly due tocommon rail pressure fluctuation when the engine is running under low load, causing fuel quantity fluctuation. The two curvesare generally consistent: Engine fuel injection target values received through the CAN bus are very similar to actual measuredvalues, and the trend and timing are synchronized. This means that EECU calibration obtained the best injection pulse widthtarget value.

Strong Foundation Shows PromiseThe CAN bus communication platform based on the J1939 protocol and the NI PXI platform built a foundation for implementingan NI CAN module in a commercial vehicle CAN bus communication application. The platform shows promise for futureapplications such as engine bench tests; vehicle electrical environment simulation HIL tests; realizing filtering; recognition;synthesis; receiving; packing; transmission; storage; parsing; calculation; and real-time CAN bus message display.

With powerful LabVIEW mathematical analysis and queue processing, NI PXI devices, and a CAN interface module suitable fora harsh vehicle test environment, this system provides CAN bus message information analysis functionalities required bymultiple test conditions. It demonstrates message data sampling synchronization acquired by NI PXI devices. The comparativeanalysis proves real-time performance and authenticity of test data.

Author Information: Dongfeng Motor Corporation Chinazhouyg@dfl.com.cn

CAN Bus Communication Platform Based on LabVIEW and the J1939 Protocol Implementation

LegalThis case study (this "case study") was developed by a National Instruments ("NI") customer. THIS CASE STUDY IS PROVIDED "AS IS"WITHOUT WARRANTY OF ANY KIND AND SUBJECT TO CERTAIN RESTRICTIONS AS MORE SPECIFICALLY SET FORTH INNI.COM'S TERMS OF USE ( ).http://ni.com/legal/termsofuse/unitedstates/us/