This article is part of our comprehensive SAE J1939 online documentation.
The primary document describing the J1939 message format is SAE J1939/21 – Data Link Layer. This specification defines the use of the CAN data frame (29-bit identifier, Parameter Group Numbers – PGN, etc.) as well as the transport protocol functions, i.e., the rules for transmitting messages that exceed the standard CAN data length of 8 bytes across a J1939 bus network.
Unfortunately, the J1939/21 document assumes that the reader has already mastered all related publications and fully understands the concept of Parameter Groups. Without any introduction or context, it jumps directly into the intricate architecture of Parameter Group Numbers. It feels like trying to explain how a car works by starting with the technical details of its fuel injection system. The result is a text that is poorly structured and unnecessarily difficult to follow.
For example, the fact that some J1939 messages may exceed the standard 8-byte CAN frame is mentioned multiple times across the document, yet without providing clear, consolidated guidance on how such messages are packetized. Similarly, key topics such as the PDU Format are explained in a fragmented manner, scattered across several chapters with unnecessary repetition instead of being presented in a cohesive, systematic way.
Extended Message Identifier
The SAE J1939 Standard exclusively uses the CAN 29-bit message identifier. In fact, the CAN standard itself was extended from 11 to 29 bits at the request of SAE to enable J1939 functionality. This extended identifier is used not only to describe the data but also, in many cases, to indicate the source and, when required, the destination of a message on the bus.
By design, the original CAN standard does not support node (ECU) addressing—it relies solely on message identifiers. The sender of a CAN frame is not concerned with who receives the data, and the receiver has no knowledge of which node sent it. The only way the receiver understands the meaning of the data is through the message ID. The SAE J1939 Standard ingeniously extends this principle by embedding a source address and, depending on the operating mode, a destination address within the 29-bit identifier.
The 29-bit identifier itself is composed of the standard 11-bit base identifier plus an 18-bit identifier extension. The distinction between the two CAN formats is made using the IDE bit in the Control Field:
-
A dominant (low) IDE bit indicates the 11-bit standard format.
-
A recessive (high) IDE bit indicates the 29-bit extended format.
In terms of addressing capacity:
-
The 11-bit standard format supports up to 2,048 (2¹¹) unique message identifiers.
-
The 29-bit extended format supports over 536 million (2²⁹) identifiers, providing the flexibility required by J1939.
The image above compares a standard CAN data frame with an 11-bit identifier to an extended CAN data frame with a 29-bit identifier. In both cases, the frame includes an Identifier Extension (IDE) bit, which indicates the format in use:
-
Low (dominant) = Standard frame (11-bit identifier)
-
High (recessive) = Extended frame (29-bit identifier)
CAN controllers are required to evaluate the IDE bit to distinguish between these two formats.
Although the J1939 protocol is based entirely on the 29-bit identifier, it does not exclude devices that use the 11-bit identifier from operating on the same network. This compatibility is not unique to J1939 but is an inherent feature of the CAN protocol itself. However, the SAE J1939 specification provides no additional definitions or guidelines for the use of the 11-bit identifier within a J1939 network.
Both formats—Standard (11-bit identifier) and Extended (29-bit identifier)—can coexist on the same CAN bus. During bus arbitration, however, a standard 11-bit frame will always have higher priority than an extended 29-bit frame if both share the same 11-bit base identifier. In such cases, the standard frame wins arbitration and gains access to the bus.
In cases where an application must use both formats, it is recommended to assign a unique priority to all 11-bit ID messages that is not shared with any 29-bit ID messages. This ensures that no 11-bit message overrides a 29-bit message and, in line with SAE’s typically cautious requirements, eliminates any potential for transmission failures.
The Extended Format involves certain trade-offs: bus latency increases (by at least 20 bit-times), messages in extended format consume more bandwidth (approximately 20% more), and error detection performance is slightly reduced because the 15-bit CRC polynomial is optimized for frame lengths up to 112 bits.
Protocol Data Unit
SAE J1939/21 defines the Protocol Data Unit (PDU) as a CAN 29-bit identifier message with the CAN control fields removed. These control fields include SOF (Start of Frame), RTR (Remote Transmission Request), the Control field containing the Data Length Code (DLC), the checksum field, the acknowledgement field (ACK), and the End of Frame (EOF) field. What remains is the core information needed to address and carry the data: the 29-bit message identifier and the actual data field (0 to 8 bytes).
While the definition of the PDU itself is not of major significance within the J1939 protocol, it provides a basis for naming the most important sections of the 29-bit identifier. Its abbreviation (PDU) and derived terms such as PDU Format (PF) and PDU Specific (PS) are used extensively throughout the SAE J1939 standards collection.
The following figure illustrates the structure and use of the 29-bit message identifier.
The parameters embedded within the 29-bit message identifier are divided into three sections: the priority field, the Parameter Group Number (PGN), and the 8-bit source address.
Priority
The first three bits of the identifier define the priority used during the arbitration process, providing eight priority levels. In accordance with the CAN standard, a value of 0 (000) represents the highest priority, while a value of 7 (111) represents the lowest.
High-priority messages are typically assigned to time-critical data, such as torque control signals exchanged between the transmission and the engine. Lower priorities are suitable for non-time-critical data, such as engine configuration information.
By default, control-oriented messages use a priority of 3, while all other messages (e.g., informational, proprietary, request, and acknowledgement) default to 6. Each PGN is assigned a recommended priority, but for network optimization, the priority may be configured for each message type.
Parameter Group Number (PGN)
Parameter Group Numbers (PGNs) reference vehicle signals and parameters that are organized into Parameter Groups. Each Parameter Group specifies how parameters are assigned within the 8-byte CAN data field of a message, along with details such as repetition rate and priority.
For example, an engine temperature Parameter Group may include coolant temperature, fuel temperature, oil temperature, and other related values. PGNs and their associated Parameter Groups are cataloged in the SAE J1939 standards (roughly 300 pages) and further defined in SAE J1939/71, an extensive document of nearly 800 pages containing Parameter Group definitions along with Suspect Parameter Numbers (SPNs).
Internally, the PGN is represented as a 24-bit value (see also the chapter on Parameter Group Numbers). Its structure is divided into four fields:
-
R (Reserved)
-
DP (Data Page)
-
PF (PDU Format)
-
PS (PDU Specific)
This structure allows for a total of 8,672 different Parameter Groups per page.
Source Address
The last 8 bits of the 29-bit message identifier represent the source address, i.e., the address of the transmitting ECU (node). A total of 253 unique addresses are available on the network, and each ECU must be assigned a unique address—no two ECUs can share the same one.
Importantly, PGNs are independent of the source address. This means that any ECU is permitted to transmit any message, regardless of its assigned address.
Communication Methods
SAE J1939 defines three communication methods, each serving a distinct purpose:
1. Destination-Specific Communication
-
Uses PDU1 (PF values 0–239) and may also use the global destination address (255).
-
Certain cases require destination-specific Parameter Group Numbers (PGNs)—for example, when more than one engine is present. A torque message, for instance, must be directed only to the intended engine rather than broadcast to all.
2. Broadcast Communication
-
Uses PDU2 (PF values 240–255).
-
As the name implies, broadcast messages can be sent:
-
From a single or multiple sources to a single destination.
-
From a single or multiple sources to multiple destinations.
-
3. Proprietary Communication
-
Uses either PDU1 or PDU2.
-
Applied in cases where standard communications are not practical.
-
Can be either:
-
Broadcast Proprietary Communication
-
Destination-Specific Proprietary Communication
-
-
Dedicated PGNs exist for both proprietary types.
Message Reception and Processing
Message handling depends on the communication method:
-
Destination-Specific Request or Command:
Each ECU checks whether the destination address matches its own. If so, it processes the message and responds accordingly. -
Global Request:
Every ECU on the network—including the sender—must process the message and respond if the requested data is available. -
Broadcast:
Each ECU individually determines whether the broadcast message is relevant to its operation.
SAE J1939 Starter Kit and Network Simulator
Our JCOM.J1939 Starter Kit and Network Simulator is designed to allow the experienced engineer and the beginner to experiment with SAE J1939 data communication without the need to connect to a real-world J1939 network, i.e., a diesel engine. It may sound obvious, but you need at least two nodes to establish a network. That fact applies especially to CAN/J1939, where the CAN controller shuts down after transmitting data without receiving a response. Therefore, our jCOM.J1939 Starter Kit and Network Simulator consists of two J1939 nodes, namely our jCOM.J1939.USB, an 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. The board supports the full SAE J1939 protocol according to J1939/81 Network Management (Address Claiming) and J1939/21 Transport Protocol (TP).
Comments are closed.