All commercial vehicles meeting Chinese National III through National IV emission standards use the CAN bus to communicate between electronic control units (ECU), including the vehicle ECU (VECU), engine ECU (EECU), automatic transmission box ECU, instrument ECU, and antilock braking system ECU. The vehicle control network has implemented the commercial vehicle CAN bus based on the J1939 protocol, combined with the multipoint control unit (MCU), CAN controller, and MCU node CAN transceiver structure. Existing solutions for road tests, engine bench tests, and vehicle electrical environment HIL simulation tests that include a PC, CAN communication module, and software are extremely costly.
Communication Method Problems
Because industrial bus message identifiers and data frames in CAN 2.0 B specifications lack common definitions, the parameters are arbitrary. Commercial vehicle CAN bus communication specifications follow the SAE J1939 protocol, based on CAN 2.0 B. Currently, there is no CAN bus communication method based on LabVIEW and the J1939 protocol in a PXI control device application for the domestic automobile industry, so we set out to combine LabVIEW software with the complex J1939 protocol to filter, receive, synthesize, recombine, and send messages.
Considering commercial vehicle CAN bus network characteristics, we constructed a CAN bus platform based on LabVIEW and the J1939 protocol, and embedded it in an NI PXI modular interface device for engine bench and vehicle electrical environment HIL tests.
J1939 Protocol and CAN 2.0 B Specification Differences
The 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 a J1939 coding system, including priority (P); reserved bit (R); data page (DP); protocol data unit (PF); extended unit (PS); source address (SA); and data field; as shown in Figure 1. The open system interconnection (OSI) reference model application layer contains seven parts, which are encapsulated in one or more CAN data frames through a protocol data unit (PDU) and transmitted 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 according to specific manufacturer protocol can cause unrecognized or inconsistent IDs during system integration. Each message frame in the J1939 protocol has a unique identifier and PGN, assigning a unique source address for each node and mapping the source address to the CAN identifier to avoid multiple nodes using the same identifier. For example, ID: 0CF00400 represents an engine 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, J1939 is 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 a suspect parameter number (SPN). These parameters define the physical meaning of data bytes in the PDU data field; for example, SPN190 represents engine speed.
The CAN 2.0 B specification can only transmit single-frame messages, while the J1939 protocol can transmit single- and multiple-frame messages, including dialogue and broadcast. J1939 can pack, send, receive, synthesize, and reorganize messages according to the multiple-frame data transmission protocol.
The module interface consists of an NI PXI CAN dual–port transceiver, an SJA1000T CAN controller, a TJA1041T high-speed CAN transceiver, and a TJA1054AT low-speed CAN transceiver. The J1939 protocol data link layer packs messages according to 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 include
- Up to 30 ECUs
- A CAN bus communication rate of 250 kB/s
- Bus voltage that includes dominant and recessive levels
- A 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.
As shown in Figure 3, the CAN bus message based on the J1939 protocol multitask processing flow uses a producer and consumer loop structure. The producer loop uses the elements enqueue function to add data to the message cluster queue, and the consumer loop uses the element dequeue function to move data out of the message cluster queue. The queue communicates between loops to avoid conflicts between multiple tasks. When data production is faster than data consumption, the queue buffers avoid message data loss.
As shown in Figure 4, we implemented the CAN bus communication platform based on LabVIEW and the J1939 protocol in an HIL vehicle electrical environment simulation for a message receiving test. We simultaneously compared it against the Vector CANoe module. Figure 7 shows the EECU message received from a steadily running engine. In one second, the system can receive 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 CAN bus network according to commercial vehicle J1939 protocol to control the automatic gearbox vehicle shifting. The combined instrument ECU receives and displays this message in real time to remind the driver of good driving habits and manipulate the vehicle to achieve the best fuel efficiency. For optimal engine performance, efficiency, and emissions standards, we calibrate the EECU to obtain the best injection pulse-width calibration parameters. After calibration, we conduct a comparative test to verify EECU calibration effects.
An engine steady state test can reveal vehicle performance at a constant speed. An engine transient test in variable working conditions simulates engine state in actual road conditions. By comparing the real-time fuel consumption message and the actual instantaneous fuel consumption measurement, we determine the EECU control performance.
Figure 8 shows a comparison measuring the engine transient fuel consumption bench test curve in 10 working conditions. The EECU fuel consumption message data received and parsed by the CAN bus according to the J1939 protocol is markedly different when the engine is running under low load, compared with the test and bench fuel consumption meter. Thus, actual fuel injecting is low when the engine is running under low load. Target and actual fuel injection amount varies greatly due to common rail pressure fluctuation when the engine is running under low load, causing fuel quantity fluctuation. The two curves are generally consistent: Engine fuel injection target values received through the CAN bus are very similar to actual measured values, and the trend and timing are synchronized. This means that EECU calibration obtained the best injection pulse width target value.
Strong Foundation Shows Promise
The CAN bus communication platform based on the J1939 protocol and the NI PXI platform built a foundation for implementing an NI CAN module in a commercial vehicle CAN bus communication application. The platform shows promise for future applications 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 for a harsh vehicle test environment, this system provides CAN bus message information analysis functionalities required by multiple test conditions. It demonstrates message data sampling synchronization acquired by NI PXI devices. The comparative analysis proves real-time performance and authenticity of test data.
Dongfeng Motor Corporation