Site Information

 Loading... Please wait...

SAE J1939 vs. CAN Bus - Physical Layer And Higher Layer Protocol (HLP)

Posted by Wilfried Voss on

SAE J1939 vs. CAN Bus - Physical Layer And Higher Layer Protocol (HLP)

To answer the fundamental question upfront: SAE J1939 is a higher-layer protocol (i.e., an add-on software) that uses the CAN Bus technology as a physical layer. In addition to the standard CAN Bus capabilities, SAE J1939 supports node addresses, and it can deliver data frames longer than 8 bytes (in fact, up to 1785 bytes). 

However, while SAE J1939 is limited to a 29-bit message identifier at either 250 or 500 kbps (a self-inflicted restriction to assure maximum reliability), the standard CAN Bus supports 11- or 29-bit message IDs at virtually every baud rate up to 1 Mbps.

A Brief History of Controller Area Network And J1939

Beginning with its official introduction in 1983, the standard CAN Bus message frame used only an 11-bit message identifier (CAN 2.0A), which is sufficient for the use in regular automobiles and any industrial application, however, not necessarily for off-road vehicles.

The Society of Automotive Engineers (SAE) Truck and Bus Control and Communications Subcommittee had developed a family of standards concerning the design and use of devices that transmit electronic signals and control information among vehicle components. As a result, the higher layer protocol SAE J1939, based on CAN Bus, was born, which was required to provide some backward-compatible functionality to older RS485-based communication protocols (J1708/J1587).

To serve these demands, the CAN standard needed to be enhanced to support a 29-bit message identifier. The ISO 11898 amendment for an extended frame format (CAN 2.0B) was introduced in 1995.

The ISO 11898 Extension (CAN 2.0B)

The 29-bit message identifier consists of the regular 11-bit base identifier and an 18-bit identifier extension. The distinction between CAN base frame format and CAN extended frame format is accomplished by using the IDE bit inside the Control Field. A low (dominant) IDE bit indicates an 11-bit message identifier, a high (recessive) IDE bit indicates a 29-bit identifier.

An 11-bit identifier (standard format) allows a total of 211 (= 2048) different messages. A 29-bit identifier (extended format) allows a total of 229 (= 536+ million) messages.

The above picture shows a comparison between a standard CAN data frame with an 11-Bit identifier and a CAN data frame in extended format (29-Bit identifier). Both frames contain an Identifier Extension Bit (IDE), which is at a low level for the standard frame and high for the extended data frame. CAN controllers must be designed in a way that they check the IDE to distinguish between the two possible frame formats.

Both formats, Standard (11-bit message ID) and Extended (29-bit message ID), may co-exist on the same CAN bus. During bus arbitration, the standard 11-bit message ID frame will always have higher priority than the extended 29-bit message ID frame with same 11-bit base identifier and thus gain bus access.

The Extended Format has some trade-offs: The bus latency time is longer (minimum 20 bit-times), messages in extended format require more bandwidth (about 20 %), and the error detection performance is reduced (because the chosen polynomial for the 15-bit checksum is optimized for frame length up to 112 bits).

SAE J1939 Applications

The main advantages of using CAN as a field-bus technology are reduced wiring (the CAN Bus 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.

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
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
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, SAE 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.

For more information, see: