This article is part of CAN Bus Embedded Development, my growing online book about practical CAN Bus hardware, software, and embedded system development.
View the complete Table of Contents →
When engineers hear SAE J1939, the first association is usually heavy-duty trucks—and for good reason. J1939 has become one of the dominant communication protocols for electronic systems in commercial vehicles.
But describing J1939 simply as a “truck protocol” does not do it justice.
At its core, SAE J1939 is a CAN-based higher-layer protocol designed for electronic control systems operating in demanding environments. Its most familiar application is the diesel engine, and wherever electronically controlled diesel engines are used, there is a good chance that J1939 is nearby.
That includes far more than trucks.
Much More Than Trucks
J1939 can be found in applications such as:
Heavy-duty trucks and trailers
Buses and coaches
Construction equipment
Agricultural machinery
Generator sets
Mining equipment
Military vehicles, including tanks and other heavy equipment
Marine engines and vessels
Railway equipment and diesel-powered trains
Industrial diesel engines and stationary equipment
SAE itself explicitly identifies on-road and off-road vehicles as well as stationary applications using vehicle-derived components, including generator sets, as J1939 applications.
The common denominator is not necessarily the vehicle. It is the need for multiple electronic control units to communicate reliably in a demanding environment.
An engine ECU may need to exchange information with a transmission controller, instrument cluster, braking system, emissions controller, generator controller, hydraulic system, or numerous other electronic devices.
CAN provides the communication medium. J1939 provides the rules that allow those devices to understand and manage each other.
J1939 Builds on CAN
SAE J1939 uses CAN with the 29-bit extended identifier.
This extended identifier is important because J1939 does not treat the CAN identifier as simply an arbitrary message number. The identifier contains several fields that J1939 uses to describe the message, its priority, and its source—and, for certain messages, its destination.
One of the most important concepts derived from this structure is the Parameter Group Number, or PGN.
A PGN identifies the type and purpose of a J1939 message. Rather than saying that CAN identifier 0x123 contains engine data, as we might with a proprietary CAN protocol, J1939 defines standardized parameter groups for exchanging information between ECUs.
Within these parameter groups are individual parameters, traditionally known as Suspect Parameter Numbers (SPNs).
The result is a standardized communication framework. An engine from one manufacturer and an instrument display from another can communicate because both understand the applicable J1939 definitions. SAE J1939/71 and the J1939 Digital Annex define these application-layer parameters and messages.
A Multi-Master Network
Another important characteristic of J1939 is that it preserves the decentralized nature of CAN.
There is no central master that must authorize every communication.
Every ECU connected to the network can transmit when necessary. CAN arbitration determines which message gains access to the bus when two or more nodes attempt to transmit simultaneously.
In that sense, J1939 can be described as a multi-master network.
This is quite different from a traditional master/slave architecture in which one controller manages the network and the other devices primarily respond to it.
A J1939 engine controller does not have to wait for a master to ask for engine speed before transmitting it. Many J1939 messages are transmitted periodically and are available to every interested ECU on the network.
Other messages may be requested, and destination-specific communication is also possible. But there is no requirement for a central master controlling the overall J1939 network.
That makes the network highly distributed and fits particularly well with vehicle and machinery applications, where numerous ECUs need to operate independently while continuously exchanging information.
Network Management Without a Master
A decentralized network still needs management.
This is one of the areas where J1939 adds functionality that CAN itself does not provide.
Every J1939 ECU communicating on the network uses a source address. But simply assigning addresses permanently would create problems, particularly when equipment from different manufacturers is combined.
J1939 therefore provides an Address Claiming process.
An ECU can announce its identity and claim an address when it joins the network. That identity is represented by a 64-bit value called the NAME, which contains information describing the device and its function.
If two devices attempt to use the same address, the J1939 network-management rules determine which device has priority and how the conflict is resolved.
No central network master is required to make that decision.
SAE J1939/81 defines these network-management mechanisms, including address selection, address claiming, association of addresses with functions, and handling network-related errors.
This is a good example of why a higher-layer protocol is useful. CAN itself provides an excellent method of transporting messages, but it does not know who the nodes are or how their addresses should be managed.
J1939 adds that intelligence.
More Than Eight Bytes
Classical CAN limits the payload of an individual CAN frame to eight data bytes. Many J1939 parameter groups fit comfortably within that limit, but some applications require considerably more data.
J1939 therefore includes transport mechanisms that allow larger messages to be divided among multiple CAN frames and reconstructed by the receiving device.
This allows J1939 applications to exchange larger blocks of information while continuing to use Classical CAN underneath.
Again, this demonstrates the role of the higher-layer protocol: CAN transports the individual frames, while J1939 defines how those frames work together to carry the complete message.
What About CAN FD?
Traditional SAE J1939 is based on Classical CAN, with a maximum payload of eight data bytes per CAN frame. However, the J1939 family has evolved to take advantage of CAN FD (CAN with Flexible Data Rate). CAN FD supports payloads of up to 64 bytes per frame and allows the data portion of the frame to be transmitted at a higher bit rate than the arbitration phase.
For J1939 applications, this provides significantly greater bandwidth and reduces the need to divide larger messages into numerous Classical CAN frames. SAE has defined J1939-22, the CAN FD Data Link Layer, specifically to support J1939 communication over CAN FD while retaining familiar J1939 concepts such as PGNs, source addresses, and the 29-bit identifier structure. CAN FD therefore does not replace J1939; it provides a faster and more capable underlying CAN technology on which J1939 networks can operate.
Diagnostics Are Part of the System
Diagnostics are another major strength of J1939.
The protocol family defines standardized mechanisms for reporting faults and diagnostic information. This includes the familiar Diagnostic Messages such as DM1 for currently active diagnostic trouble codes.
This standardization is particularly valuable in heavy equipment. An engine, transmission, braking controller, or other ECU can report diagnostic information using a common structure rather than every manufacturer inventing an entirely proprietary system.
For technicians, diagnostic-tool manufacturers, fleet operators, and equipment developers, this is one of J1939’s most important practical benefits.
A Complete Communication Framework
It is tempting to think of J1939 primarily as a database of engine parameters.
It is much more than that.
J1939 combines CAN with a standardized message structure, network addressing, address claiming, device identification, diagnostics, requests, destination-specific communication, and transport mechanisms for larger messages.
Most importantly, it does all of this without requiring a central master.
Each ECU remains an independent participant on the CAN network while following a common set of rules that allows the entire system to operate together.
That combination—CAN’s robust multi-master communication together with standardized network management and application-level definitions—is one of the reasons SAE J1939 has become so successful far beyond the heavy-duty truck for which it is best known.
In future posts, I will look more closely at individual J1939 concepts, including the 29-bit message identifier, PGNs and SPNs, Address Claiming, the 64-bit NAME, diagnostics, and the J1939 Transport Protocol.
SAE J1939
CAN identifier: 29-bit extended CAN ID
Typical bit rate: 250 kbit/s or 500 kbit/s, depending on the J1939 network/application
Network structure: Decentralized; no master required
Node addressing: 8-bit source address with address-claiming mechanisms
Network management: Primarily address management, device identification through the 64-bit NAME, initialization, and handling address conflicts
Message organization: Parameter Group Numbers (PGNs)
Data parameters: Suspect Parameter Numbers (SPNs)
Communication: Broadcast and destination-specific messages
Large messages: Transport Protocol for data exceeding a single CAN frame
Diagnostics: Extensive standardized diagnostic messaging, including Diagnostic Trouble Codes (DTCs)
Typical applications: Heavy-duty vehicles, engines, construction equipment, agricultural machinery, and other mobile equipment
Follow CAN Bus Embedded Development
New chapters and technical material are added regularly. Subscribe to receive new additions as the online book continues to grow.