Technical Explainer
J1939-22: The CAN FD Evolution of Heavy-Duty Vehicle Networking
SAE J1939-22 is the specification that defines how the J1939 heavy-duty vehicle protocol runs on CAN FD. Released by SAE International in 2020-2021, it extends the established J1939 family - used in commercial trucks, buses, off-highway equipment, and stationary industrial engines - onto the larger payloads and higher bit rates of the CAN FD physical layer.
If you operate, build, or connect to heavy-duty vehicles, J1939-22 is the standard you will increasingly meet over the next decade.
A short recap: what J1939 is, and where it came from
SAE J1939 is the application-layer protocol that sits on top of CAN for heavy-duty vehicle communication. It defines:
- A standard set of Parameter Group Numbers (PGNs) - categories of vehicle data such as engine temperature, fuel rate, or vehicle speed
- A standard set of Suspect Parameter Numbers (SPNs) - individual signals inside each PGN
- A transport protocol for messages that exceed a single CAN frame
- Network management for address claiming and ECU identification
J1939 has served the heavy-duty industry since the mid-1990s and is the reason a scan tool, a fleet tracker, and an aftermarket engine controller can all make sense of data coming off a commercial truck's CAN bus.
Classic J1939 runs on Classic CAN, typically at 250 kbps
(J1939-11) or 500 kbps (J1939-17). It carries up to
8 bytes of payload per frame.
What changed with CAN FD
CAN FD (Controller Area Network with Flexible Data-Rate), standardized in ISO 11898-1 from 2015, extends Classic CAN in two important ways:
- Payload length increases from 8 bytes to up to 64 bytes per frame
- Data-phase bit rate increases from 1 Mbps to as high as 5-8 Mbps
Arbitration - the priority-based bus access mechanism CAN is known for - still runs at Classic CAN rates, so CAN FD preserves the determinism and reliability the protocol is trusted for.
For heavy-duty vehicles, that combination is significant. Modern powertrain, battery, thermal, and ADAS subsystems produce more data, faster, than J1939 on Classic CAN can carry comfortably.
Enter J1939-22
J1939-22 is the SAE specification that runs the J1939 application layer on CAN FD. The semantic layer - PGNs, SPNs, parameter definitions - is preserved. What changes is the transport.
The three differences that matter most:
1. Larger payloads per frame
A single J1939-22 CAN FD frame can carry up to 64 bytes, compared to 8 bytes in Classic J1939. For signals that previously required the J1939 transport protocol's multi-frame segmentation (BAM, CMDT), J1939-22 often fits the same data in a single frame.
2. Multi-PG packing
J1939-22 introduces multi-PG packing - the ability to carry multiple Parameter Groups within a single CAN FD frame. In Classic J1939, one frame carries one PG. In J1939-22, a single 64-byte frame can carry several smaller PGs efficiently.
This is the defining structural change of J1939-22 and the one that requires receiver logic to be updated. A decoder that understands only Classic J1939 will see a J1939-22 multi-PG frame as malformed.
3. Higher effective bandwidth
With CAN FD's data-phase bit rates (typically 2 Mbps
in J1939-22 deployments, arbitration still at 500 kbps),
the bus can carry significantly more data per unit time.
Practically, this supports the signal density of modern
electrified and highly instrumented heavy-duty platforms.
J1939-22 vs Classic J1939 at a glance
| Classic J1939 | J1939-22 | |
|---|---|---|
| Underlying layer | Classic CAN (ISO 11898-1) | CAN FD (ISO 11898-1, 2015+) |
| Typical arbitration rate | 250 kbps (J1939-11) or 500 kbps (J1939-17) | 500 kbps |
| Typical data-phase rate | Same as arbitration | 2 Mbps (up to 5-8 Mbps possible) |
| Max payload per frame | 8 bytes | 64 bytes |
| Multi-PG per frame | No | Yes |
| PGN/SPN semantics | Defined in J1939-71 / J1939 DA | Largely preserved |
| Decoder compatibility | Classic J1939 decoders only | Requires J1939-22-aware decoder |
Who is adopting J1939-22?
J1939-22 adoption is still in its early phase. SAE published the specification in 2020-2021. Commercial-vehicle OEMs are selectively adopting it for subsystems where bandwidth pressure is highest - electrified powertrain, battery management, and sensor-dense ADAS domains - often alongside Classic J1939 on parallel or gated buses.
Full-platform adoption will likely track the generational refresh cycle of heavy-duty vehicle architectures through the second half of this decade. In the meantime, mixed fleets - combining legacy Classic J1939 trucks, newer J1939-22-capable platforms, and proprietary CAN FD schemas on EV-specific buses - are the realistic operating environment.
We're now seeing active light-vehicle logistics fleet tenders in both Australia and Europe specifying CAN FD-only vehicle platforms. For TSPs bidding into these tenders, the choice is binary: redesign the telematics device for CAN FD (a multi-year engineering investment, plus years of carrying both old and new devices in the field), or pair the existing device with a CAN FD bridge alongside it. The bridge path lets the TSP keep their proven hardware, decoding stack, and customer relationship, while futureproofing their product onto every new vehicle generation entering customer fleets.
What J1939-22 means for fleet telematics
For telematics service providers (TSPs) serving heavy-duty fleets, J1939-22 changes one specific part of the picture: the new vehicles entering customer fleets.
The challenge: a Classic CAN controller cannot decode CAN FD frames at the data-link layer, no matter how well it understands J1939 semantics. As customers add J1939-22-capable vehicles to their fleets, the TSP's existing telematics device can't read those vehicles, even though it continues to handle the rest of the fleet on Classic J1939 exactly as it always has.
The opportunity: the semantic layer is preserved. A bridge that reads J1939-22 traffic on the CAN FD bus and re-emits the relevant PGs as J1939 Classic CAN frames to the existing telematics device lets the device's decoding stack and backend operate exactly as they do today, on every new vehicle the customer adds.
That is the job Nexum Fleet is built for.
How the Nexum Fleet bridge handles J1939-22
The Nexum Fleet bridge installs alongside your existing telematics device on each new J1939-22 vehicle. It reads the vehicle's CAN FD bus directly, parses J1939-22 frames including multi-PG structures, and delivers the extracted PGs as J1939 Classic CAN frames your telematics device already understands.
The result:
- No redesign of your telematics device
- No rebuild of your decoding stack
- No change to your backend or customer-facing platform
- One bridge SKU covers J1939-22 heavy-duty vehicles, EV/hybrid CAN FD platforms, and OEM-specific CAN FD schemas
- New vehicle platforms added through over-the-air signal library updates, not firmware flashes or site visits
J1939-22 - frequently asked questions
When was J1939-22 released?
Is J1939-22 backward compatible with Classic J1939?
What is multi-PG packing?
Do I need a new CAN controller to read J1939-22?
Does J1939-22 replace Classic J1939?
How do I provide J1939-22 support into existing J1939 telematics hardware?
For a broader set of CAN FD, J1939, and fleet telematics questions, see our full FAQ. To discuss a specific deployment, talk to the founders.
Ready for J1939-22 in your customer fleets?
We're onboarding a small number of TSPs as launch integration partners now. If your customer fleets are adding J1939-22-capable heavy vehicles, the conversation is worth having.