SAE J1939-22 Explained: A Guide to CAN FD for Next-Generation Heavy-Duty Vehicle Networks

SAE J1939-22 is the CAN FD evolution of the J1939 family. In SAE’s own high-level description, it brings CAN’s flexible data rate capability into J1939 to support higher efficiency, parallel transactions, functional safety, and cybersecurity-oriented extensions, while preserving the J1939 application model built around PGNs, SPNs, source addresses, requests, diagnostics, and network management. In practical terms, the biggest shift is this: classic J1939/21 assumed one 29-bit extended CAN frame per parameter group and only 8 data bytes per frame, while J1939-22 adds CAN FD frame formats, up to 64-byte frames, a container mechanism called Multi-PG, and a new FD transport protocol that moves much more data with fewer frames.

For an implementer, the mental model that works best is to treat J1939-22 as “J1939 semantics over a CAN FD-capable network”, not as a brand-new application protocol. Most of the things a J1939 engineer already knows still matter: PGN-centric decoding, PDU1 versus PDU2, source address claiming, request/response patterns, and J1939-73 diagnostic messages. What changes are the wire-level carriage rules: J1939-22 expects CAN FD on the network, typically paired with the J1939-17 physical layer at 500 kbit/s arbitration and 2 Mbit/s data rate; it adds FEFF and FBFF frame usage, allows multiple contained parameter groups inside one CAN FD frame, and replaces classical TP.CM / TP.DT usage with FD.TP.CM / FD.TP.DT plus end-of-message status signaling.

The easiest way to avoid confusion is to separate the stack into three questions. First, what does the data mean? That still comes mostly from the Digital Annex and application-layer documents. Second, how is a node identified and managed? That is still largely J1939/81. Third, how is the data packed onto CAN now that the network is CAN FD? That is the main job of J1939-22, working on top of ISO 11898 CAN FD and, in a typical J1939-22 deployment, the J1939-17 physical layer.

This report is therefore organized to make the standard teachable: first the surrounding document map, then the physical assumptions, then the J1939-22 frame and transport mechanics, then worked examples, and finally implementation guidance, glossary, and a checklist. Helpful public explanations from Vector Informatik, CAN in Automation, Kvaser AB, and National Instruments complement the published scopes from SAE International and the CAN base standards from International Organization for Standardization.

Where J1939-22 fits

The current J1939 top-level document says its purpose is to provide the overall network overview and explain the subordinate document structure. That is exactly the right starting point for J1939-22: the standard is not a replacement for the rest of J1939, but one subordinate piece in a document family. The Digital Annex remains the searchable catalog of many PGNs and SPNs. J1939/81 still governs address management. J1939/73 still defines the diagnostic messages. J1939/82 still defines self-compliance-style network testing. J1939-17 defines the CAN FD-capable physical layer normally paired with J1939-22.

The table above is a paraphrase of published document scopes and abstracts, not a substitute for the documents themselves.

A second comparison helps show what changed between classical J1939 and J1939-22:

Physical layer assumptions

J1939-22 is not a physical-layer standard by itself. The public J1939-22 scope material focuses on CAN FD capability and transport/network efficiency, while the physical companion is J1939-17, whose published scope says it defines a physical layer with high bandwidth using the ISO 11898-1:2015 CAN FD frame format. Public summaries of J1939-17 and independent industry explainers consistently describe the intended operating point as 500 kbit/s arbitration and 2 Mbit/s data phase, which is a strong clue that a real J1939-22 system should be designed and validated as a CAN FD system from the transceiver upward, not merely as a faster classic J1939 bus.

That has several practical consequences. The CAN controller must support CAN FD. The transceiver and topology must also support the data-phase bit rate; the ISO 11898-2:2024 abstract explicitly describes high-speed PMA variants for CAN, including selective wake-up and other high-speed features, while CiA’s CAN dictionary notes that CAN FD transceivers are specified in ISO 11898-2 for bit rates above 1 Mbit/s depending on topology. In other words, controller support without physical-layer validation is not enough.

It is also important not to confuse J1939-22 with older J1939 physical options. J1939/11 is the robust 250 kbit/s shielded-twisted-pair option for harsh environments; J1939/14 is a 500 kbit/s classical-CAN option and explicitly says CAN FD-capable controllers on that network must be restricted to the classical frame format; J1939/15 is an unshielded-twisted-pair 250 kbit/s option; and J1939/13 covers off-board diagnostic connectors for those networks. J1939-22 is therefore not simply “use CAN FD on any existing J1939 wire and hope it works.” It belongs with a CAN FD-capable physical design, usually J1939-17.

At the CAN-physics level, the usual high-speed differential assumptions still apply: CAN_H and CAN_L in ISO 11898-2 networks sit around 2.5 V recessive and move in opposite directions in dominant state, and a common ground is still important to avoid common-mode problems. Those are ISO/CAN facts rather than J1939-specific rules, but they matter more in J1939-22 because the faster data phase tightens topology, EMC, and sampling-margin discipline.

Frames, identifiers, and transport

The most useful way to read J1939-22 is to separate it into direct CAN FD PG carriage, Multi-PG carriage, and FD transport protocol carriage. All three use J1939-style addressing concepts, but they solve different size and efficiency problems. The public Vector descriptions, public J1939-22 implementations, and CAN FD references line up on the major picture: J1939-22 normally uses CAN FD frames, uses FEFF and FBFF formats, introduces Multi-PG and Contained PGs, and adds FD.TP.CM / FD.TP.DT plus EOMS.

Direct FEFF and FBFF use

CAN FD itself supports FEFF and FBFF. CiA’s dictionary explicitly names these as the CAN FD frame formats, and public J1939-22 summaries say J1939-22 can use both 29-bit and 11-bit CAN identifiers. In classical J1939, the practical norm is the 29-bit identifier, but J1939-22 adds a defined 11-bit global Multi-PG case. Public implementation material also shows that direct PDU1 and PDU2 notification remains meaningful at the receiver side, which is consistent with the idea that a receiving stack should still understand standard J1939 PGNs and addresses even on a CAN FD network.

For the familiar 29-bit J1939 identifier, the same conceptual fields still matter:

• Priority: 3 bits, lower number means higher priority during CAN arbitration.
• PGN: 18-bit message identity used for decoding rules.
• SA: 8-bit source address of the sender.
• PDU1 vs PDU2: PF below 240 means addressed semantics; PF 240 and above means broadcast/group-extension semantics.

Multi-PG and Contained PGs

The signature J1939-22 feature is the Multi-PG: instead of sending exactly one parameter group in one frame, a CAN FD frame can carry one or more Contained PGs. Vector’s public description says the C-PG header is 4 bytes long, the first three bits are TOS, the remaining header fields include trailer-format information and the PGN, and the last 8 bits are the length of the subsequent payload. Public implementation code confirms a concrete byte layout for the “no assurance data” case: byte 0 packs TOS, TF, and the top two PGN bits; bytes 1–2 carry the remaining PGN bits; byte 3 carries payload length.

Contained PG header (4 bytes)

Byte 0: [ TOS(3) | TF(3) | PGN[17:16](2) ]
Byte 1: [ PGN[15:8] ]
Byte 2: [ PGN[7:0]  ]
Byte 3: [ payload length in bytes ]
Byte 4..: payload bytes (and, if TF says so, assurance data trailer bytes)

For the common “no assurance data” case, a public reference implementation uses TOS = 2and TF = 0. That same implementation also enforces a 60-byte application-data limit for a contained PG or a single FD transport data slice, which matches Vector’s public explanation that a single FD transport data-transfer frame can carry up to 60 bytes. The conceptual reason is simple: once J1939-22 reserves control/header bytes inside the CAN FD payload, the entire 64-byte CAN FD field is no longer available to user data.

Two important address rules matter here:

• A 29-bit FEFF Multi-PG uses outer ID semantics compatible with J1939-style destination/global addressing and uses Multi-PG PGN 0x2500 in the outer identifier.
• An 11-bit FBFF global Multi-PG is broadcast-only. Public summaries say the first three identifier bits are AppPI and must be 000 for this form, leaving the remaining 8 bits as SA.

A subtle but very important point is that an addressed J1939-22 frame must not bundle C-PGs for different destinations. A Kvaser technical note states this explicitly: if a J1939-22 frame is addressed to a specific device, all contained PGs must be for that device. This is one of the easiest implementation mistakes to make if you think of a Multi-PG as just a generic “UDP-like container.” It is not.

FD transport protocol

For payloads that do not fit into a contained PG, J1939-22 adds an FD transport protocol. Vector’s public summary names FD.TP.CM (PGN 0x4D00) and FD.TP.DT (PGN 0x4E00), says parallel sessions are possible, says the segment-count field grows from two bytes to three, and says there is a new End-of-Message Status frame, EOMS. Public implementation material aligned to J1939-22 shows the wire-facing formats clearly enough to explain them teachably:

• FD.TP.CM carries a 12-byte control block. Byte 0 packs control type and session number. Bytes 1–3 carry message size. Bytes 4–6 carry segment count or next-segment information. Bytes 7–8 vary by control type. Bytes 9–11 carry the PGN of the reassembled message.
• FD.TP.DT uses 4 bytes of internal header before payload: byte 0 packs DTFI and session number, bytes 1–3 carry the segment number, and the remaining bytes carry up to 60 payload bytes.

Public reference code for J1939-22 labels the transport control types and timeout constants as follows: RTS=0, CTS=1, EOM_STATUS=2, EOM_ACK=3, BAM=4, ABORT=15; and timeouts such as Tr 200 ms, T1 750 ms, T2/T3 1.25 s, T5 3 s are annotated as J1939-22 timeouts. Because this is public implementation material rather than the licensed standard itself, treat these timer values as a useful cross-check, not as a substitute for the official text you already own.

A practical frame-format picture

Direct FEFF frame (29-bit CAN FD)
CAN ID: [Priority | EDP | DP | PF | PS | SA]
Data  : application bytes directly associated with that PGN

FEFF Multi-PG frame (29-bit CAN FD)
CAN ID: [Priority | EDP | DP | PF=0x25 | DA | SA]
Data  : [C-PG header][C-PG payload][C-PG header][C-PG payload]...[padding]

FBFF Global Multi-PG frame (11-bit CAN FD)
CAN ID: [AppPI=000 | SA]
Data  : [C-PG header][C-PG payload]...[padding]

FD.TP.DT frame
CAN ID: PGN 0x4E00 + destination semantics
Data  : [session/DTFI][segment no. 3 bytes][up to 60 bytes payload]

This picture combines the public Vector explanations with the public reference implementation layout.

Example message flows

The examples below are didactic captures, not normative test vectors. The payload values are illustrative; the frame formats, address rules, and field placement are based on the cited public material. Timing is shown as plausible application timestamps on a quiet 500 kbit/s / 2 Mbit/s J1939-22 bus, not as guaranteed minimum wire times. For orientation, Vector’s CAN FD performance example shows about 103.5 µs for an 8-byte CAN FD frame and about 329.5 µs for a 64-byte CAN FD frame at 500 kbit/s arbitration and 2 Mbit/s data rate, with actual timing varying by stuffing and identifier length.

Address claim conflict on a J1939-22 network

Even on a J1939-22 network, the Address Claimed PG is the public exception that may still be sent as a classical 29-bit CAN frame. J1939/81 still governs the semantics: nodes claim source addresses using NAME, address 255 is global, address 254 is the null address, and the lower NAME wins an address conflict.

The teaching point is that J1939-22 does not abolish J1939 address claiming. It modernizes payload carriage, but your ECU still needs the J1939/81 state machine.

FEFF Multi-PG broadcast carrying two contained PGs

This example shows a single FEFF Multi-PG broadcast from SA 0x31. The outer Multi-PG uses PGN 0x2500 with global destination 0xFF, while the inner payload contains two C-PGs. Each C-PG uses a 4-byte header: TOS/TF/PGN-high bits, PGN middle byte, PGN low byte, then payload length. Here both C-PGs are simple broadcast PDU2 examples with illustrative payload bytes.

How to read the first C-PG header:

• 0x40 → TOS=010b (common no-assurance-data case), TF=000b, PGN[17:16]=00b
• 0xF1 0x00 → remaining PGN bits, so PGN=0x00F100
• 0x04 → four payload bytes follow

The outer CAN ID tells you the sending node and the fact that this is a Multi-PG; the inner headers tell you which individual PGs are inside the container. That is the conceptual leap many classic-J1939 readers need to make.

Destination-specific FD transport with RTS/CTS and EOMS

This example sends an illustrative 96-byte manufacturer-defined PGN 0x00D200 from source 0x31 to destination 0x90. Because 96 bytes do not fit in a single contained PG, the sender uses FD.TP. The transport protocol uses FD.TP.CM (0x4D00) and FD.TP.DT (0x4E00), can run multiple sessions in parallel, and adds EOMS/EOMA to terminate the session cleanly. The byte layouts shown here follow public J1939-22 implementation material aligned to the standard.

This is the sequence to remember: RTS/CTS governs the stream, DT carries the slices, EOMS closes the sender side, EOMA closes the receiver side. If you stop implementing after the last DT, you have not finished J1939-22 transport.

Design and implementation guidance

The first implementation rule is architectural: pair J1939-22 with the correct physical assumptions. If the network is really J1939-17-style CAN FD, validate controller capability, transceiver capability, bus topology, and timing margins together. J1939/14’s published scope explicitly says CAN FD-capable controllers on that network must be restricted to classical frames, which is a useful reminder that “my microcontroller supports CAN FD” does not by itself mean “this network is ready for J1939-22.”

The second rule is semantic separation: keep your application database and your wire-format engine separate. The Digital Annex and diagnostic/application docs tell you what a PG means; J1939-22 tells you how it is carried. This seems obvious, but it is a common source of design debt when teams embed SPN scaling, PGN routing, Multi-PG packing, and transport segmentation into one monolithic “J1939 handler.” That makes migration, diagnostics, and conformance testing much harder.

The third rule is to design around the three different carriage modes. For small periodic data, a contained PG inside a Multi-PG is often the efficient J1939-22-native choice. For addressed or broadcast transfers that exceed the single-frame carried-data limit, use FD.TP. For startup identity and address management, keep the J1939/81 logic intact and remember the Address Claimed exception. Public tooling from Vector also exposes a practical split between direct single CAN-FD transmission, Multi-PG transmission, and FD.TP transmission for a given PG, which is a good way to think about implementation strategy.

The most common pitfalls are concrete and unusually repeatable:

Mixing destinations inside one addressed Multi-PG. Public guidance from Kvaser warns against this explicitly. If the outer frame is addressed to one node, every contained PG has to belong to that same destination context.

Mishandling PDU1 PGNs in contained headers. In public J1939-22 implementations, a PDU1 C-PG stores the PGN with the PS low byte zeroed, while the actual destination lives in the outer FEFF frame. If you reconstruct the PGN naively, you will decode or route the wrong thing.

Treating the 64-byte CAN FD payload as 64 bytes of free application data. In J1939-22, headers and transport metadata consume bytes. Public J1939-22 material points to 60-byte application chunks for Multi-PG payload carriage and per FD.TP.DT transfer slice.

Forgetting EOMS/EOMA. J1939-22 added an end-of-message status step. This is a real protocol obligation, not just a decode nicety.

Under-sizing buffers and CPU service paths. CAN FD reduces the number of frames for large transfers, but each frame is denser. Vector’s performance example shows that a full 64-byte CAN FD frame at 500 kbit/s / 2 Mbit/s is only a few hundred microseconds long on the wire. If your ISR, DMA, queueing, or copy strategy assumes classic J1939 pacing, bursts will expose it quickly.

Ignoring CAN-level failure confinement. J1939-22 inherits CAN’s error handling: error active, error passive, and bus-off all still exist. Kvaser’s CAN material and CiA’s dictionary are good reminders that CAN controllers detect message errors, emit error indications, and can transition into passive or bus-off states. J1939-22 diagnostics should therefore always observe both the application layer and the CAN controller health.

Skipping compliance testing. J1939/82 exists specifically to verify that an ECU operates correctly on a J1939 network, and SAE explicitly frames it as manufacturer self-compliance rather than a certification stamp. That is exactly the mindset you want when bringing up a J1939-22 ECU: treat conformance as an engineering discipline, not a marketing checkbox.

One final implementation point is software architecture. Public discussion around AUTOSARemphasizes that Multi-PG behaves a lot like a container PDU problem rather than like a traditional single-frame signal mapping problem. Even if you are not using AUTOSAR, the lesson is worth copying: implement a packing layer, a carrier layer, and a decoder/reassembly layer as separate software elements.

Glossary, checklist, and references

Glossary

The glossary above consolidates terminology from the published scopes and explainers for J1939, CAN FD, and J1939-22.

Concise implementer checklist

Use this as a pre-integration gate:

• Confirm the network is truly designed for J1939-22, meaning CAN FD-capable controllers, CAN FD-capable transceivers, and a physical layer aligned with J1939-17 expectations.
• Keep J1939/81 address claiming as a first-class state machine; do not treat it as legacy code.
• Implement FEFF, FBFF, Multi-PG, and FD.TP as separate decode/encode paths.
• Enforce the addressed-frame rule: one destination context per addressed Multi-PG.
• For PDU1 C-PGs, reconstruct the effective destination from the outer frame, not from the zeroed low byte of the inner PGN.
• Use FD.TP for payloads that do not fit the per-frame carried-data budget; do not invent a proprietary “almost transport” shortcut.
• Implement EOMS/EOMA and transport timeouts, then test abort and recovery paths.
• Monitor CAN controller error states separately from J1939 application diagnostics.
• Validate behavior with J1939/82-style compliance thinking before field deployment.
• Keep your PG/SPN metadata synchronized with the current Digital Annex.

Primary references

The most important primary and near-primary references for this topic are:

• J1939 top-level document — structure of the family, common terms, and document map.
• J1939-22 — official scope language on CAN FD use for safety, cybersecurity, parallel transactions, and network efficiency.
• J1939-17 — the CAN FD physical layer companion, publicly described as 500 kbit/s arbitration and 2 Mbit/s data phase in public summaries.
• J1939DA — current searchable PGN/SPN data supplement.
• J1939/81 — address management and source-address claiming.
• J1939/73 — diagnostic message services and service-tool interface.
• J1939/82 — compliance tests and procedures for J1939 ECUs.
• ISO 11898-1:2024 — CAN data-link and physical-coding sublayer, including CAN FD and CAN XL in the current edition.
• ISO 11898-2:2024 — high-speed physical medium attachment for CAN, including high-speed PMA variants relevant to CAN FD installations.

Open questions and limitations

A few J1939-22 topics are still hard to explain fully from public material alone. The biggest gaps are the exact normative details of all trailer formats and assurance-data profiles, the full intended use of security/safety add-ons such as J1939-91C in real deployments, and some edge-case conformance rules that are only summarized—not reproduced—in public descriptions. Public implementations are very helpful for understanding byte layouts and timer names, but when they differ from your licensed copy, your licensed copy should win.