Open Standard for Networking and Communication in the Commercial Vehicle Sector
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.
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.
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: www.sae.org.
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.
|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|
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).
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!)|
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)
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.
Global Communication – 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.
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:
- 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.
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)
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 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|
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.
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).
– 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.
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.
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
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
The following products from Vector assist you in your J1939 projects:
Model-based E/E system design according to SAE J1939 and ISOBUS 11783:
Simulation, testing, and development of J1939 systems:
Analysis of J1939 systems:
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