Additional Information

Site Information

 Loading... Please wait...

Guide To SAE J1939 - Introduction to J1939

Posted by Wilfried Voss on

The following is an excerpt from A Comprehensible Guide To J1939 by Wilfried Voss.

A Comprehensible Guide to SAE J1939

The Society of Automotive Engineers (SAE) Truck and Bus Control and Communications Subcommittee has developed a family of standards concerning the design and use of devices that transmit electronic signals and control information among vehicle components. SAE J1939 and its companion documents have quickly become the accepted industry standard and the Controller Area Network (CAN) of choice for off-highway machines in applications such as construction, material handling, and forestry machines.

J1939 is a higher-layer protocol based on Controller Area Network (CAN). It provides serial data communications between microprocessor systems (also called Electronic Control Units - ECU) in any kind of heavy-duty vehicles. The messages exchanged between these units can be data such as vehicle road speed, torque control message from the transmission to the engine, oil temperature, and many more.

The main advantages of using CAN as a field-bus technology are reduced wiring (CAN requires only two wires between nodes), extremely reliable communication, easy implementation and improved maintenance and service capabilities, which consequently not only produce better vehicle performance, but also help to reduce production costs.

J1939-based protocols are used in:

  • Diesel power-train applications
  • In-Vehicle networks for trucks and buses
  • Agriculture and forestry machinery (ISO 11783)
  • Truck-Trailer connections
  • Military vehicles (MiLCAN)
  • Fleet management systems
  • Recreational vehicles
  • Marine navigation systems (NMEA2000)

The protocol features of J1939 are based on two older SAE (Society of Automotive Engineers) specifications:

1. SAE J1708

SAE J1708 specifies on the physical layer of the communication link. It uses RS485 as an electrical layer operating at 9600 baud. (Note: Unlike RS232/485 there are no message collisions under CAN). Messages under J1708 start with a Message Identification Character, followed by the data information and a checksum. The message length is 21 characters (or less) and each data character is 10 bits long. Each character starts with a start bit of low polarity.

2. SAE J1587

SAE J1587 is a joint SAE/TMS "Recommended Practices for Electronic Data Exchange Between Microcomputer Systems in Heavy-Duty Vehicle Applications". It regulates the communication and standardized data exchange between ECUs based on J1708 networks.

Note: The situation regarding documents/literature on J1708 and J1587 is as dire as with J1939.

J1939 is designed to replicate the functionality of J1708 and J1587 including control system support. Vehicle applications may utilize either one of both specifications.

The J1939 specification is described by a number of SAE documents, the SAE J1939 Standards Collection:

Document Description
J1939 Recommended Practice for a Serial Control and Communications Vehicle Network[1]
J1939/01 Recommended Practice for Control And Communications Network for On-Highway Equipment
J1939/02 Agricultural and Forestry Off-Road Machinery Control and Communication Network[2]
J1939/11 Physical Layer - 250k bits/s, Twisted Shielded Pair
J1939/13 Off-Board Diagnostics Connector
J1939/15 Reduced Physical Layer, 250k bits/sec, Un-Shielded Twisted Pair (UTP)
J1939/21 Data Link Layer
J1939/31 Network Layer
J1939/71 Vehicle Application Layer
J1939/73 Application Layer - Diagnostics
J1939/74 Application - Configurable Messaging
J1939/75 Application Layer - Generator Sets and Industrial
J1939/81 Network Management

SAE J1939 is a very ingeniously designed protocol that takes a resourceful advantage of the CAN 29-Bit message identifier. Rather than relying on a myriad of protocol functions, SAE J1939 uses predefined parameter tables, which keeps the actual protocol on a comprehensible level. SAE J1939 is a prime example of good American engineering according to the KISS principle (KISS = Keep It Simple, Stupid!), but it is nevertheless at least as effective as any other higher layer protocol based on CAN.

Unlike other CAN based protocols J1939 does not implement the established Master/Slave or Client/Server architecture, yet another contribution to the efforts of keeping it simple. The conventional Multi-Master principle (the node that wins the bus arbitration is the master, while all other nodes are the slaves) works just as well.


[1]This document does exist, however, the hyperlink on the SAE web site produces an error message.

[2] This document is not listed in the "Core J1939 Standards" list on the SAE web site, but it can be found through their search feature. Reference: http://www.sae.org/technical/standards/J1939/2_200608


SAE J1939 ECU Simulator Board With USB Port

SAE J1939 ECU Simulator Board With USB Port

The jCOM.J1939.USB gateway board is a high-performance, low-latency vehicle network adapter for SAE J1939 applications. It allows any host device with a USB COM port to monitor SAE J1939 data traffic and communicate with the SAE J1939 vehicle network.

The board supports the full SAE J1939 protocol according to J1939/81 Network Management (Address Claiming) and J1939/21 Transport Protocol (TP). It is also supported by an extensive programming interface for Windows and Linux/Ubuntu applications, including full C/C++/C# source code for short time-to-market developments.

The strength of the board lies in the fact that the entire SAE J1939 protocol, including all timing requirements, is stored on-chip, thus taking the burden off the main system. The board uses a USB COM port to communicate with the main system, i.e. all data transfer is handled through a standard COM port access. 

The communication protocol between the board and the main system is well documented and thus allows a porting to any computer system with a USB connection. Working source code libraries exist for Windows (C# under Visual Studio 2012/2013), Linux and its derivatives (C++ using Code::Blocks), and Raspberry Pi (C using the standard gcc compiler).

More Information...