Blog
What Is J1939-22?
March 27, 2026
J1939-22 is an SAE International standard that defines a serial communications protocol for heavy-duty vehicles and industrial machinery. It is part of the broader J1939 family of standards — the dominant networking protocol used in commercial trucks, buses, off-highway equipment, and agricultural machinery worldwide.
While the original J1939 standard was built on the Classical CAN (Controller Area Network) bus running at 250 kbps or 500 kbps, J1939-22 is specifically designed to operate over CAN FD (CAN with Flexible Data-rate). CAN FD is a modernized extension of CAN that allows both higher bus speeds and larger data payloads per message frame. J1939-22 was published to give the heavy-vehicle industry a standardized, interoperable framework for harnessing these capabilities.
In short: J1939-22 is to CAN FD what the classic J1939 standard is to traditional CAN. It defines how electronic control units (ECUs) on a vehicle communicate — what the messages look like, how devices are addressed, how the bus is shared, and how faults are handled.
The original J1939 protocol, defined in layers over classical CAN, served the industry well for decades. However, as modern vehicles became more electronically complex, the limitations of classical CAN became increasingly apparent:
CAN FD was developed by Bosch to address these limitations. It retains the robust arbitration and error-handling mechanisms of classical CAN while permitting data-phase bit rates up to 8 Mbit/s and payloads up to 64 bytes per frame. J1939-22 was created to give the commercial vehicle industry a standardized, backward-compatible path to adopt CAN FD — without abandoning the decades of investment in J1939 tooling, diagnostics, and expertise.
J1939-22 leverages CAN FD's dual-phase bit rate. During the arbitration phase, all nodes on the bus compete at the standard rate (typically 500 kbps or 1 Mbit/s), preserving the classical CAN collision-avoidance mechanism. Once a node wins bus arbitration and begins transmitting its payload, the bit rate switches to a much higher data-phase rate — commonly 2 Mbit/s or 4 Mbit/s — dramatically increasing throughput.
Classical CAN is limited to 8 bytes of data per frame. CAN FD expands this to 64 bytes. J1939-22 defines how these larger frames are used, structured, and interpreted within the J1939 ecosystem, including updated parameter group number (PGN) assignments and suspect parameter number (SPN) mappings that can take advantage of the richer data space.
J1939-22 was designed with coexistence in mind. Networks can include both classical J1939 nodes and J1939-22 (CAN FD) nodes, with appropriate gateways or bridge devices enabling communication between the two segments. This allows fleet operators and OEMs to introduce CAN FD capable ECUs incrementally rather than requiring a wholesale network replacement.
The classic J1939 transport protocol (TP) was designed to segment messages larger than 8 bytes across multiple classical CAN frames. J1939-22 introduces updated transport protocol mechanisms optimized for CAN FD, taking advantage of larger frame sizes to reduce the overhead involved in sending multi-frame messages. This is particularly important for large diagnostic data transfers and software update payloads.
J1939-22 is compatible with the existing J1939 physical layer specifications (J1939-11, J1939-15), meaning that CAN FD signals can often be carried on the same twisted-pair cabling infrastructure already common in commercial vehicles. This minimizes the hardware redesign burden for vehicle manufacturers.
CAN FD introduces a stronger CRC (Cyclic Redundancy Check) algorithm than classical CAN. J1939-22 benefits from this improvement, offering better data integrity checking for the larger frame payloads. The enhanced CRC helps ensure that transmission errors in the additional payload bytes are reliably detected and flagged.
Like its predecessors, J1939-22 organizes data into Parameter Group Numbers (PGNs). Each PGN defines a specific set of data — engine speed, coolant temperature, brake pressure, and so on. Within a PGN, individual signals are identified by Suspect Parameter Numbers (SPNs). J1939-22 updates these definitions to support the larger CAN FD frame, allowing more SPNs to be transmitted in a single message than was possible with classical CAN.
J1939-22 retains the J1939 address claim procedure. When a device joins the network, it broadcasts its address and source address (SA) using the address claim mechanism. This ensures that every ECU on the bus has a unique address, preventing conflicts. The 8-bit source address field supports up to 253 addressable nodes (with a few addresses reserved for special purposes).
CAN FD uses the same Non-Destructive Bitwise Arbitration as classical CAN. When multiple nodes attempt to transmit simultaneously, the node with the higher-priority (numerically lower) CAN ID wins the bus without corrupting the data of any competing node. Losing nodes simply back off and retry. Because arbitration occurs at the slower arbitration-phase bit rate, all nodes — including classical CAN nodes on a mixed network — can participate in bus arbitration.
When a PGN's data exceeds 64 bytes (or needs to be sent to a specific destination address), J1939-22 employs its transport protocol. The sender and receiver negotiate the transfer with handshake messages, and data is broken into sequential CAN FD frames. At the receiver, the frames are reassembled in order. The larger CAN FD frame payloads mean fewer frames are needed compared to classical J1939 transport, reducing latency and bus load for large data transfers.
CAN FD inherits classical CAN's fault confinement architecture, in which each node tracks its own transmit and receive error counts. Nodes that exceed defined error thresholds transition from the active to passive error state, and eventually to a bus-off state, where they cease transmitting and cease affecting other nodes. J1939-22 leverages this mechanism to prevent a single malfunctioning ECU from disrupting the entire vehicle network.
The most immediate benefit is raw throughput. With data-phase bit rates up to 8 Mbit/s and 64-byte payloads, J1939-22 can move data several times faster than classical J1939. For applications like ECU reprogramming, high-frequency sensor polling, and live diagnostic data streaming, this is a transformative improvement.
Because each CAN FD frame can carry up to 64 bytes versus 8 bytes for classical CAN, a message that would require 8 classical frames can be sent in a single CAN FD frame. This dramatically reduces bus utilization, freeing bandwidth for other traffic and reducing latency across the entire network.
The automotive and commercial vehicle industry is moving toward more software-defined, electronically complex vehicles. J1939-22 provides a standards-based foundation to accommodate this trend without requiring OEMs and suppliers to abandon the familiar J1939 ecosystem. Adoption of J1939-22 today positions manufacturers for the next generation of vehicle networking requirements.
OTA software updates for ECUs have become increasingly important for emissions compliance, safety, and feature delivery. Updating firmware over classical CAN is slow, sometimes requiring hours per ECU. J1939-22's higher bandwidth can reduce update times dramatically, minimizing vehicle downtime and enabling more frequent software maintenance cycles.
Modern diagnostics — particularly Unified Diagnostic Services (UDS) and J1939 Diagnostic Message (DM) services — benefit enormously from higher bandwidth. Large data logs, fault memory snapshots, and live data streams that were impractical over classical CAN become routine with J1939-22, enabling deeper insight into vehicle health.
Because J1939-22 is built on CAN FD — itself a proven and widely deployed technology — manufacturers can adopt it using existing CAN FD silicon, transceivers, and development tools. There is no need to invest in entirely new physical layer technology or learn a new programming paradigm. The transition is evolutionary, not revolutionary.
The stronger CRC mechanisms in CAN FD, which J1939-22 inherits, provide more robust error detection than classical CAN. For safety-critical applications such as braking systems, steering controls, and emissions management, this improvement in data integrity is operationally significant.
J1939-22 is well-suited to a wide range of heavy-vehicle and industrial applications, including:
J1939-22 is one layer within the broader J1939 architecture, which is organized across multiple sub-standards
Understanding J1939-22's position within this hierarchy is important: it defines how data is moved on the bus, not what the data means. The application-layer standards (PGNs, SPNs) remain largely unchanged, which is a key reason why the transition to J1939-22 can be relatively smooth for software developers already familiar with J1939.
While the benefits of J1939-22 are clear, there are practical considerations for organizations undertaking adoption:
J1939-22 represents an important and well-conceived evolution of the J1939 protocol family. By standardizing the use of CAN FD within the familiar J1939 framework, it delivers substantially higher bandwidth, lower latency, and stronger data integrity — while preserving backward compatibility with the enormous installed base of J1939 equipment.
For OEMs designing next-generation commercial vehicles, Tier 1 suppliers developing advanced ECUs, and fleet operators planning future network infrastructure, J1939-22 provides the performance headroom needed to support increasingly sophisticated vehicle electronics — from real-time ADAS data processing to rapid OTA software updates.
As the commercial vehicle industry continues its transition toward electrification, autonomy, and connectivity, J1939-22 is well positioned to serve as the communications backbone for the next generation of heavy-duty transportation.