SAE J1939

Open Standard for Networking and Communication in the Commercial Vehicle Sector

SAE J1939

SAE J1939 is the open standard for networking and communication in the commercial vehicle sector. The focal point of the application is the networking of the power train.

Characteristic for SAE J1939 is the use of CAN technology for networking and communication as well as manufacturer-spanning interoperability. The J1939 protocol comes from the Society of Automotive Engineers (SAE) and works on the physical layer with CAN-highspeed according to ISO11898.


  • Uses the 29-bit extended CAN identifier
  • Standardized CAN baud rates of 250 kbits/s and 500 kbits/s.
  • Has point-to-point addressing (node addressing) and global addressing (message addressing)
  • Up to 1785 bytes can be transmitted with multi-packet messages
  • Bus access control via own network management
  • Standardized messages for the overall vehicle communication
  • Allows manufacturer-specific message definition
  • Defines own diagnostic interface

SAE J1939 and CAN

The SAE J1939 protocol uses CAN (Controller Area Network, ISO 11898-1 and ISO 11898-2) as the physical layer. The CAN protocol plays a major role in motor vehicle networking and represents a commonly used method for bit serial communication between electronic control units (ECUs). Typical ECUs include: Engine, transmission, and brake ECUs as well as the instrument panel and door ECUs.

SAE J1939: Typical Vehicle Network with Engine, Transmission, and Brake ECUs
Typical J1939 vehicle network

Consortium and other Specifications

There are a number of standards which are derived from SAE J1939. These standards use the basic description of J1939 and often differ only in their data definition and adaptations of the physical layer, where necessary.

ISO 11783 – Tractors and machinery for agriculture and forestry – Serial control and communication

Defines the communication in vehicles used for agriculture. Specifically, the communication between the tractor and add-on equipment, the so-called implement. The ISO 11783 standard specifies services at the application layer, for example, the control of add-on equipment via a Virtual Terminal. The add-on equipment itself brings along all graphic elements needed for its control, which the Virtual Terminal can display. Other application components are: Tractor ECU, Task Controller, File Server, and Sequence Control. The ISO 11783 standard has an extension of the multi-packet protocol defined for SAE J1939. The Working Set mechanism is also applied.

Show more

NMEA 2000® – Serial-data networking of marine electronic devices

Defines the ECU communication between vehicles in the maritime environment. An extension of the multi-packet protocol – the so-called Fast Packet protocol – is also used here.

Show more

ISO 11992 – Interchange of digital information between towing and towed vehicle

Specifies the message exchange of road vehicles between the towing vehicle and the towed vehicle. ISO 11992 is based on the message format of J1939 but uses a different configuration of the physical layer, namely only 125 kbits/s.

Show more

FMS – Fleet Management System

The FMS standard defines a gateway between a J1939 network and the FMS.

Show more

Document Structure J1939

Document Structure J1939

The complete J1939 specification is subdivided into various documents and chapters. All documents can be downloaded individually or in preassembled packages from the SAE website:

There is a charge for the individual chapters of the J1939 specification, i.e., they cannot be accessed for free. The individual chapters are structured systematically and are loosely based on the ISO/OSI reference model. Loosely based only, because the document structure of J1939 contains a chapter 8, which is not defined in the OSI model.

The table on the right lists the currently existing chapters and documents.

Physical Layer

Comparison of Specifications J1939-11/14/15

The SAE J1939 protocol uses CAN (Controller Area Network, ISO 11898-1 and ISO 11898-2) as the physical layer.

SAE J1939 Physical Layer Comparison of Specifications J1939-11 / J1939-14 / J1939-15
SAE J1939: Bus topology
Parameter J1939-11 J1939-15 J1939-14
Twisted Pair Wire Shielded Unshielded Shielded or Unshielded
Bit Rate 250 kbit/s 250 kbit/s 500 kbit/s
Number of ECUs 30 10 30
Bus Length Max: 40 m Max: 40 m Max: 40.0 m – 56.4 m
ECU Distance Min: 0.1 m | Max: 40 m Min: 0.1 m | Max: 40 m Min: 0.3 m | Max: 40.0 m – 56.4 m
Stub Length Max: 1 m Max: 3 m Max: 1,67 m
Diagnostic Stub Length
Max: 0.66 m + 5 m Max: 2.66 m + 5 m Max: 1.67 m + 5 m


Parameter Group

The J1939-21 document defines the scheme according to which the 29-bit CAN identifier must be interpreted. Similarly as for the 8-byte data field of a CAN message in which different signals are defined by a start bit and length, the CAN identifier is subdivided into different segments for a parameter group. By this only a part of the identifier represents the PGN itself, the rest is interpreted as source address, destination address, priority, and data page (DP).

SAE J1939 - From the 29-bit CAN Identifier to the Parameter Group
From the 29-bit CAN Identifier to the Parameter Group

PGN Sections

The two bits “Data Page” (DP) and “Extended Data Page” (EDP) are also part of the PGN and are included for counting as the two most significant bits. As a result, the numeric range is arranged in four PGN pages, but only 3 are used for J1939.

The following data page definitions are available:

Extended Data Page (EDP) Data Page (DP) Description
0 0 SAE J1939 and ISO 11783
0 1 SAE J1939 NMEA 2000®
1 0 SAE J1939 – reserved –
1 1 ISO 11992 Diagnostics (Important: no J1939 layout!)

Transport Protocol

Messages greater than 8 bytes in length are too large to fit into a single CAN Data Frame. Therefor they must be divided by the sender into individual packets, which can then be sent with a CAN message each. The receiver has to recombine the individual fragments in their original order. A set of rules is defined for this in the J1939 standard: a so-called transport protocol.

Two transport protocols are defined corresponding to the communication types.

Specific Communication – Connection Mode Data Transfer (RTS/CTS)

SAE J1939 Transport Protocol – Connection Mode Data Transfer (RTS/CTS)
Connection Mode Data Transfer (RTS/CTS)

With this protocol the sender establishes a connection to the receiver. The receiver has the option of controlling and influencing the flow control of the individual data packets. Both the receiver and sender can abort the connection (e.g. in case of errors).

The Connection Mode Data Transfer protocol is not subject to any time limitation. All nodes potentially exchange their data with one another at their maximum possible speed.

Show more

Global Communication – Broadcast Announce Message (BAM)

SAE J1939 Transport Protocol – Broadcast Announce Message (BAM)
Broadcast Announce Message (BAM)

The sender alone manages the flow control. The message is always sent to all nodes. A receiver cannot intervene in the communication. If the receiver misses a message, it cannot signal this. The receiver must wait for a new message, if necessary.

Because the receiver is not able to influence the flow control in the BAM protocol, the sender must maintain a minimum interval between the individual packets. This is 10-200 ms. This allows possible slow network nodes to follow the communication.

Show more


The J1939 diagnostic interface defines a standard diagnostic connector as well as a set of PGNs for handling different diagnostic services. The PGNs designated as a Diagnostic Message (DM) largely fulfill the scope of functions of the UDS diagnostics (Unified Diagnostic Service). They also comply with the EU Directives and with the “California Code of Regulation” for Onboard Diagnostics (OBD II), as well as HD OBD (Heavy Duty OBD) and WWH (World Wide Harmonized) OBD (ISO 27145).

In contrast to the UDS diagnostics in which services have to be actively initiated via a software tool, J1939 ECUs also send diagnostic messages independently during standard operation. Errors that occur are evaluated directly in the network and visually displayed, if necessary. In parallel with that, errors can be read out with a tool via the diagnostic connector. Uniform error codes – so-called Diagnostic Trouble Codes (DTC) – contain the faulty SPN, the error pattern, and the frequency of occurrence of an error.

Diagnostic Trouble Code (DTC)

A DTC (Diagnostic Trouble Code) represents a faulty property in the system. It primarily represents an SPN whose current status is abnormal. This can have different causes. An indicator that gives the reason for the status is used to try to narrow down the actual cause of the error. A DTC has a uniform structure and consists of the following elements:

SAE J1939 Diagnostic Trouble Code (DTC)
  • Suspect Parameter Number (SPN)
    Represents the SPN with error. Every defined SPN can be used in a DTC.
  • Failure Mode Identifier (FMI)
    Represents the nature and type of error that occurred, e.g., value range violation (high or low), sensor short-circuits, incorrect update rate, calibration error.
  • Occurrence Counter (OC)
    A counter that counts the occurrence of the error condition for each SPN and stores this even when the error is no longer active.
  • SPN Conversion Method (CM)
    Defines the byte alignment within the DTC. The value “0” represents the method shown in graphic “Structure of a DTC”. If CM has the value “1”, a distinction must be made between three previously valid methods; this must be known for the system.

Functional Safety

SAE J1939 includes two different approaches for transferring safety-critical data. One is the SAE J1939-76 standard, which describes a general process for protecting a desired parameter group. The other involves standardized parameter groups specified by SAE J1939 featuring a built-in checksum and counter.

SAE J1939-76 – Dedicated Safety Header Message With Checksum and Sequence Counter

The SAE J1939-76 standard (SAE J1939 Functional Safety Communications Protocol) describes a J1939 enhancement for the transfer of safety-critical data. This is achieved by an additional message (Safety Header Message, or SHM) being sent ahead of the message with the critical data (Safety Data Message, or SDM), where the SHM and SDM together comprise a Safety Data Group (SDG).

The SHM contains the following information:

  • a sequence counter (for each SDG, 5 bits)
  • the inverted CAN ID of the SDM (no priority, 26 bits)
  • the CRC for the data of the SDM (32 bits)
Components of the Safety Data Group (SDG): Safety Header Message (SHM) and Safety Data Message (SDM)

- Timing

The sender (producer) generates the SHM & SDM and sends them in the proper order and in compliance with the time limits. The receiver (consumer) is responsible for checking the sequence and time limits, as well as the integrity, of the transferred data.


The following times must be complied with for transfer of the SDG:

  • SRVT: Safety-Relevant Validation Time (time between an SHM and an SDM)
  • SCT: Safety Cycle Time (time between successive SDM instances)

The time basis for determining the maximum permissible SRVT and SCT values is derived from the cycle time (transmission rate) of the respective SAE J1939 PG, which is to be transferred as the SDM.

Determination of the maximum SCT and the maximum SRVT is defined as follows:

SDG Timing Basis SCTMaximum SRVTMaximum
≤ 200 ms 150% of the time basis 50% of the time basis
> 200 ms Time basis plus 100 ms 100 ms

- Limitations

An SDM may not be longer than 8 bytes. This avoids the need for a transport protocol for transferring the message. In addition, the SDM must be sent with either a fixed or variable cycle time. An example of a variable cycle time would be every 100 ms and whenever a change is made, but not faster than 20 ms.

SAE J1939 Digital Annex – Messages With Integrated Checksum and Counter

The J1939 Digital Annex specifies checksums for over 200 messages and message counters for the detection of fault conditions of the ECUs involved. The message counter and checksum are part of the payload data of a PG. The message counter is increased by one each time a message is transferred. As the checksum is calculated from the payload data, the checksum also changes as a result of each correct transfer, regardless of whether or not other signals have changed. If, however, the message counter is not incremented for a subsequent transfer or the checksum does not match the payload data, the receiver can assume that the sender is in an error state.

  • Checksums
    The Digital Annex describes five different calculation rules for the checksums, two of which are based on a typical CRC (Cyclic Redundancy Counter) calculation with a length of 8 bits. The other three calculations use simple additions, bit shifts and bit masks.
  • Message counter
    Six possible positions within the message are specified for the message counter in the Digital Annex.

The following graphic shows common combinations and positions of checksums and message counters, as well as the names of the messages which use this combination, for example. For better understanding, the five calculation rules are each provided with a capital letter (A through E).

Arrangements of the checksum and message counter

– Defined Calculation Rules

Not only does the position in the message vary greatly in some cases, but the calculation formula for checksums does as well. Essentially, five rules are used.

1) The first two rules use a CRC with a length of 8 bits.

Calculation rules: Checksum as CRC

2) The other three are based on bit shift operations and bit masks. These rules have been in use for some time now and are used for parameter groups TSC1 (PGN 0) and XBR (PGN 1024), for example.

Calculation rules: Checksum as addition, bit shift and bit mask

J1939 Poster

J1939 Protocol at a Glance

With this quick overview in DIN format A1 (841 mm x 594 mm) you always have the most important basics of the J1939 protocol in mind. Order your own cheat sheet now with detailed information on the following topics:

Specification Documents | Physical Layer | Frame Structure | Transport Protocols | Request Handling | Diagnostic | Network Management

SAE J1939 Protocol Overview - Topics: Specification Documents | Physical Layer | Frame Structure | Transport Protocols | Request Handling | Diagnostic | Network Management
J1939 Protocol Reference Chart in DIN A1 format, folded to DIN A4

Vector - The J1939 Specialist

Vector is a member of SAE J1939 committees and participates regularly in the workshops. Thanks to Vector's expertise and many years' experience in the J1939 environment, you profit from high-performance products and services with which you can solve your challenging problems more efficiently, faster, and more cost-effectively.

With a continuous tool chain for all J1939 projects, Vector has the right solution for you:

  • perfectly-attuned software tools

  • custom-tailored embedded software components

  • individual service and trainings designed specially for your needs

Vector Tools

The following products from Vector assist you in your J1939 projects:

Model-based E/E system design according to SAE J1939 and ISOBUS 11783:
  • Import and Export of J1939 designs via DBC and AUTOSAR
  • Extended multiplexing for CAN
  • Modeling of controller applications
  • AUTOSAR compliant software and hardware network design
Simulation, testing, and development of J1939 systems:
  • Creation of simulation environments (simulation of the remaining bus) for J1939 systems
  • Run-time environment for the simulation
  • Band end tests
Analysis of J1939 systems:
  • Analysis and logging of data traffic on J1939 networks
  • Stimulation of message sequences
  • Replay of recorded message sequences (replay)
Embedded software components for J1939 applications
Running applications on CAN, SAE J1939 and SAE J1708/J1587 networks
Driver Software for DIAdem: supports the J1939 protocol as well as NMEA2000 and ISOBUS (ISO11783)
Quick and especially easy to use diagnostic tester for single ECUs or the complete vehicle
Workshops: SAE J1939 Fundamentals & Introduction to CANalyzer/CANoe .J1939