As a professional in the automotive industry, understanding the intricacies of J1939 communication is crucial for ensuring efficient data transmission and system interoperability. The SAE J1939 standard is a key specification for heavy-duty vehicles, providing a robust framework for communicating and controlling a vehicle's electronic systems. In our earlier article on introduction to SAE J1939 standard, we covered various sub-standards associated with this and how the overall scheme of things works. In this comprehensive guide, we will delve deep into the various aspects of J1939 communication — from message frame formats and parameter group number to transport protocols — and explore the nuances of the SAE J1939 standard.
As described earlier, the message frame format in the SAE J1939 standard is based on the high-speed CAN specification ISO11898 and leverages the 29-bit extended frame format of CAN to encode information about the data being transferred.
The 29-bit ID field is split into 3 components:
Priority:3 bits — Specifies the priority of the message. Leveraging CAN's arbitration procedure, 0 has the highest priority and 7 the lowest. Critical control messages like torque data from transmission are transmitted with higher priority and non-critical information with lower priority.
Parameter Group Number:18 bits — Indicates the information associated with this message. Source address — 8 bits — contains the address of the originator of this message with a value between 1 and 254.
The parameter group number (PGN) is further split into 4 fields:
Group Extension is essentially used to increase the number of available messages to be broadcast.
The parameter group number (PGN) in the SAE J1939 standard serves as a key identifier for different categories of data transmitted across the network. Each parameter group number corresponds to a specific type of information, such as engine speed, vehicle position, or diagnostic trouble codes (DTCs). Defined by the J1939/71 standard, all standard parameters used in any vehicle network are given a unique parameter group number that identifies the contents of the data section of the frame.
The parameter group number is a fundamental concept in the SAE J1939 standard: it maps directly to the CAN frame ID and tells any receiving node what kind of data to expect. Engineers working with the SAE J1939 standard typically reference the parameter group number to filter, log, or decode in-vehicle signals without needing to negotiate content at runtime.
In the context of the SAE J1939 standard, the suspect parameter number (SPN) is a critical element that facilitates precise identification of specific parameters within transmitted data. Each SPN corresponds to a distinct parameter, such as vehicle speed, engine oil temperature, or brake system status.
By standardizing the SPNs, the SAE J1939 standard ensures consistency and interoperability across different vehicle models and manufacturers.
The PGNs and SPNs in the SAE J1939 standard are typically equivalent to messages and signals in typical in-vehicle networking and are available as DBC files that can be quickly used with standard tools like CANAnalyser, CANKing, etc.
As the volume and complexity of data within vehicle systems continues to grow, the need for efficient transport protocols becomes increasingly critical. The SAE J1939 standard addresses this demand through the implementation of robust transport protocols, enabling the reliable transfer of extensive data payloads across the network. These transport protocols support the fragmentation, transmission, and reassembly of large data sets, ensuring that comprehensive diagnostic information and system updates can be effectively exchanged between ECUs.
The J1939-21 specification within the SAE J1939 standard defines two mechanisms to transfer data larger than 8 bytes — one for broadcast messages and another for peer-to-peer communication — called Broadcast Announcement Message (BAM) and Connection Mode (CM) respectively. Both protocols work similarly but differ in reliability and control on delivery. To begin the transfer, they utilize a special message called Transport Protocol Connection Management message (TP.CM). This message carries the connection command, the parameter group number of the large message about to be transmitted, and the method of reconstructing the received message. Then the actual data is transmitted using Transport Protocol Data Transfer messages (TP.DT). The first byte of the data field holds the sequence number of the chunk along with 7 bytes of data.
A multiplexed message in the SAE J1939 standard uses a mode-selector byte embedded in the data field to indicate which set of parameters is contained in a given transmission. This multiplexed message mechanism allows a single parameter group number to carry data from multiple logical sub-groups without allocating separate PGNs for each, conserving the limited 29-bit CAN ID space. Understanding the multiplexed message structure is important when parsing J1939 DBC files and implementing J1939 decoders that need to correctly extract SPN values from multiplexed frames.
The Broadcast Announcement Message (BAM) mechanism is used to broadcast data to multiple nodes. It is not possible to implement a handshake mechanism, so the transmitter manages the flow to ensure the receiver can handle messages without overloading. Even if the receiver loses part of the message, there is no way to request it again — the transmitter is responsible for managing the entire flow of data across the network.
As depicted, the source sends the TP.CM message with value of 32 in the control byte indicating BAM. Then it starts sending data over TP.DT messages until all are sent. The last packet, if it does not have 7 bytes of data, the remaining area is padded with 0xFF.
The Connection Mode is a peer-to-peer transfer with a mechanism for handshaking and acknowledgments that can ensure successful data transfer. The receiver has fine control over the data flow and can request the sender to pause and continue transmission when needed. Both parties can choose to abort the transmission at any point.
The sender starts transmission with a TP.CM message with control byte Request to Send (value 16). The receiver responds with TP.CM control byte Clear to Send (17) and the current sequence number and number of TP.DT packets allowed. The sender then sends TP.DT messages starting at the sequence requested until the allowed count is reached. Once all data is received, the receiver sends a TP.CM with control byte End of Message Acknowledgment (19).
The address claim procedure is a vital aspect of the SAE J1939 standard, governing the allocation of unique addresses to ECUs within the network. As vehicles incorporate an increasing number of electronic control units, the address claim procedure plays a crucial role in ensuring that each ECU can communicate effectively without causing conflicts. By following a standardized process for address allocation, the SAE J1939 standard facilitates seamless integration of new ECUs into the network, promoting scalability and interoperability.
During the address claim procedure, each ECU broadcasts its preferred address and listens for potential conflicts. If a conflict arises, the ECUs involved engage in a prioritized arbitration process to resolve it and secure unique addresses. This systematic approach minimizes communication errors and fosters a stable network environment for the exchange of critical vehicle data.
The CAN in vehicle network layer defined by the SAE J1939 standard governs how ECUs discover each other, claim addresses, and share parameter group numbers across the bus. A well-implemented CAN in vehicle network using the SAE J1939 standard also handles NAME conflicts during address claiming and supports dynamic address assignment for plug-and-play ECUs in off-highway and marine applications.
A J1939 protocol stack implements all the layers of the SAE J1939 standard in software — from the transport layer BAM and Connection Mode handlers up through the application layer parameter group number dispatcher and diagnostic message processor. A production-grade J1939 protocol stack must handle address claiming, parameter group number filtering, transport protocol fragmentation, and SPN encoding/decoding in real time. Teams porting a J1939 protocol stack to cloud-connected gateways can leverage Embien's cloud migration services to bridge J1939 protocol stack telemetry into cloud-native data pipelines for fleet analytics. For embedded J1939 protocol stack integration into ECU firmware, Embien's product engineering services provide rapid deployment across CAN-capable MCU platforms.
A J1939 protocol stack typically exposes APIs at three levels: a raw CAN frame receive/transmit interface, a parameter group number registration interface, and an SPN read/write interface. The J1939 protocol stack handles address claim negotiation automatically, allowing application code to focus on parameter group number data without dealing with the underlying CAN arbitration details. Validating a J1939 protocol stack against the SAE J1939 standard conformance requirements is essential before deploying it in safety-critical vehicle programs.
In conclusion, a thorough understanding of the SAE J1939 standard is indispensable for automotive professionals seeking to harness its full potential for data transmission and system control. From the intricate message frame formats and the parameter group number identification system to the transport protocols and the J1939 protocol stack, the SAE J1939 standard offers a comprehensive framework for robust communication within heavy-duty vehicles. By mastering the nuances of the SAE J1939 standard — including parameter group numbers, transport protocol mechanisms, and J1939 protocol stack architecture — professionals can elevate their diagnostic capabilities, optimize system performance, and ensure seamless interoperability across diverse vehicle components.
Embien's cross-domain embedded services include SAE J1939 standard integration, parameter group number decoding, and J1939 protocol stack deployment across commercial vehicle domains.
Embien's electronics product development services cover SAE J1939 standard hardware design, J1939 protocol stack integration, and parameter group number validation for heavy-duty vehicle ECUs.
A connected instrument cluster integrating SAE J1939 standard communication with mobile application support, demonstrating Embien's J1939 protocol stack and parameter group number expertise.