I have worked with SAE J1939 for many years, and one observation has remained remarkably consistent: understanding the technology is often easier than understanding the documents that define it.
This is not meant simply as criticism of SAE International. Technical standards have a difficult job. They must define behavior precisely, eliminate ambiguity, address unusual conditions, and provide enough detail that equipment developed independently by different manufacturers can communicate reliably.
But there is a difference between technical precision and technical explanation.
A standard is primarily a specification. It tells us what a compliant implementation must do. It does not necessarily teach us why the system works that way, which concepts are important first, or how all the individual requirements fit together.
With SAE J1939-22, that distinction becomes particularly noticeable.
Why J1939-22 Exists
Traditional SAE J1939 is based on Classical CAN, generally using the familiar 29-bit CAN identifier and an eight-byte data field.
That architecture has served the heavy-duty vehicle and off-highway industries extremely well. But eight bytes per CAN frame is an obvious limitation as applications demand larger amounts of data.
CAN FD addresses part of that problem by allowing a CAN frame to carry as many as 64 data bytes and, under appropriate conditions, transmit the data portion of the frame at a higher bit rate.
SAE J1939-22 defines how CAN FD is incorporated into the J1939 environment.
That sounds straightforward enough.
The difficulty begins when we try to preserve the established concepts of J1939 while introducing a substantially different CAN data-link technology.
J1939-22 Is More Than “J1939 with 64 Bytes”
It would be convenient to think of J1939-22 as traditional J1939 with a larger CAN payload.
Unfortunately, it isn’t quite that simple.
J1939 has accumulated decades of conventions governing message formats, Parameter Groups, network management, transport protocols, addressing, and interoperability. CAN FD changes some of the assumptions upon which those mechanisms were originally built.
Consequently, J1939-22 must define not only how CAN FD frames are used, but also how they coexist with concepts inherited from traditional J1939.
And that brings us to one of the reasons the standard can be difficult to approach.
When an Acronym Looks Like a Hex Value
One example that caught my attention immediately was the abbreviation CEFF.
This may be very much the programmer in me speaking, but when I see something like CEFF in a J1939 document, my first reaction is to interpret it as a hexadecimal value—0xCEFF. And in a protocol where we constantly deal with hexadecimal CAN identifiers, Parameter Group Numbers, source addresses, and data values, that seems like a perfectly reasonable assumption.
My next thought was therefore: What is PGN CEFF, and why haven’t I encountered it before?
Except CEFF isn’t a hexadecimal value at all.
It stands for CAN Extended Frame Format (meaning the “C” in “CEFF”represents the abbreviation of an abbreviation) and refers to the familiar extended CAN frame format used by traditional J1939.
Once you know that, there is nothing particularly complicated about the concept. But the terminology creates a small and unnecessary hurdle for someone approaching J1939-22 from a programming or embedded-development perspective.
To be fair, a standard needs concise terminology to distinguish between different frame types, particularly when Classical CAN and CAN FD must coexist. But this is also a good example of why reading a standard is different from learning a technology. The standard defines its vocabulary and expects the reader to use it. A programmer first has to translate that vocabulary back into familiar engineering concepts.
That last sentence also leads nicely into the following “Specification Versus Explanation” section.
And I would definitely retain the little “What is PGN CEFF?” moment. It gives the article some of your personal voice without being as confrontational as the original jcom1939.com post.
Specification Versus Explanation
This distinction is important enough to emphasize.
A technical standard might say, in effect:
Under these defined circumstances, this particular frame type shall or shall not be transmitted.
That is exactly what a standard is supposed to establish.
An engineer learning the technology usually needs a different explanation:
What problem are we trying to solve?
What was done in traditional J1939?
What changed because of CAN FD?
Why was that change necessary?
What does my ECU actually have to do differently?
Once those questions have been answered, the formal language of the standard becomes considerably easier to interpret.
Starting with the formal requirements and attempting to reconstruct the underlying architecture from them reverses the natural learning process.
The Classical J1939 Reference Point
I find it much easier to approach J1939-22 by beginning with what we already know.
Traditional J1939 gives us a familiar model:
Classical CAN → 29-bit identifier → PGN → up to 8 data bytes
If more information must be transferred than will fit into a single CAN frame, J1939 provides transport mechanisms for handling larger messages.
CAN FD changes one of the fundamental constraints:
CAN FD → 29-bit identifier → PGN → potentially much larger data payload
But changing the size of the underlying CAN frame has consequences farther up the protocol stack.
The interesting engineering question therefore isn’t simply:
How does J1939 use CAN FD?
A better question is:
Which mechanisms developed around the eight-byte limitation of Classical CAN still make sense when the underlying CAN frame can carry substantially more information?
That question provides a much more useful entry point into J1939-22.
Compatibility Makes Things More Complicated
There is another problem that standards designers cannot simply ignore: existing equipment.
J1939 is not a new protocol being introduced into an empty market. There is an enormous installed base of ECUs, vehicles, machinery, diagnostic equipment, gateways, and development tools based on traditional J1939.
A CAN FD-based extension therefore cannot be considered entirely in isolation.
The standard must address questions such as:
How does a device determine what kind of J1939 network it is connected to?
Which traditional J1939 frames remain relevant?
Which frame types are permitted under which circumstances?
How should network management operate?
How do devices avoid transmitting something inappropriate for the network they have joined?
These are legitimate engineering problems.
Unfortunately, once all the exceptions and operating conditions are expressed in formal standards language, the relatively simple idea underneath them can become difficult to recognize.
Read the Standard in Layers
For engineers approaching J1939-22, I would therefore resist the temptation to read the document sequentially and expect the architecture to emerge automatically.
Instead, build a conceptual model first.
Start with Classical CAN and traditional J1939. Make sure the relationship between the CAN identifier, PGN, source address, destination addressing, and the eight-byte data field is clear.
Then look at CAN FD independently. Understand what CAN FD actually changes at the CAN level: payload size, frame format, bit-rate switching, and the associated controller requirements.
Only then combine the two.
At that point, J1939-22 becomes less mysterious. You are no longer trying to learn CAN FD, J1939, and J1939-22 terminology simultaneously. You are looking specifically for the mechanisms SAE introduced to connect two technologies you already understand.
Don’t Let the Acronyms Define the Architecture
This is perhaps my largest objection to the way many technical standards are approached.
Engineers can easily find themselves learning terminology rather than learning the system.
CEFF is a good example. Once you understand that it identifies a particular CAN frame format, the acronym itself becomes secondary.
The same principle applies throughout protocol engineering.
Whenever I encounter a new abbreviation, my first questions are:
What does this represent physically?
Where does it sit in the protocol stack?
What information does it carry?
What problem does it solve?
If those questions can be answered, the terminology usually becomes manageable.
If they cannot, memorizing another acronym isn’t going to help.
Standards Still Matter
None of this means that engineers should ignore the SAE documents.
Quite the opposite.
If you are developing a product that must conform to SAE J1939-22, the official standard remains the authoritative technical reference. A tutorial, book, website, or application note can explain the concepts, but it cannot define compliance.
The two types of documentation simply serve different purposes.
A good technical explanation should provide the conceptual map.
The standard provides the precise coordinates.
You need both when developing an actual implementation.
A Broader Documentation Problem
J1939-22 also illustrates something I have encountered repeatedly during decades of working with CAN-based systems.
As technologies mature, their documentation tends to become more complicated.
There are more features to support, more legacy behavior to preserve, more exceptional conditions to define, and more terminology required to distinguish one mechanism from another.
The specification becomes more complete while simultaneously becoming less approachable to someone encountering the technology for the first time.
That is not necessarily evidence of a poorly designed protocol. Sometimes it is simply the consequence of a mature technology carrying its history forward.
But it does increase the importance of good educational material.
My Approach to J1939-22
As I continue working through J1939-22, my goal is therefore not to reproduce or paraphrase the standard paragraph by paragraph.
I am much more interested in extracting the engineering concepts behind it.
What changed from traditional J1939?
Why did it change?
Which parts are consequences of CAN FD itself, and which are decisions specific to the J1939 implementation?
And, perhaps most importantly:
What does an engineer actually need to know to implement it?
Those are the questions I intend to explore.
Because ultimately, a communication protocol is useful only when engineers can understand it well enough to build something with it.