If you are new to SAE J1939, the first thing you will probably do is search for the official standards documents. That usually leads to an immediate moment of confusion.

You discover that SAE J1939 is not a single document.

It is an entire collection of standards. Hundreds of pages. Dozens of separate documents. Cryptic names like J1939/21, J1939/71, J1939/73, and J1939/81. References to ISO layers. Acronyms everywhere. Tables that seem to assume you already know the material.

And yet, despite all of that, SAE J1939 itself is one of the best heavy-duty vehicle communication systems ever created.

That contradiction is important to understand.

The standard is excellent.
The documentation often is not.

In my personal opinion, the SAE J1939 standards were written primarily as engineering reference material, not as educational material. The documents are highly technical, fragmented across multiple publications, and frequently written in a way that assumes the reader already understands both CAN bus technology and the ISO networking model.

In other words:
The standards tell you what the system does.
They do not do a particularly good job teaching you how the system works.

That is why so many developers struggle during their first exposure to J1939.

Ironically, once you finally understand the architecture, you realize the system itself is actually elegant, logical, and remarkably well designed.

SAE J1939 and the ISO 7-Layer Model

One of the first surprises for many engineers is that SAE J1939 is heavily based on the ISO Open Systems Interconnection (OSI) 7-layer model.

The OSI model divides communication into seven conceptual layers:

Physical Layer
Data Link Layer
Network Layer
Transport Layer
Session Layer
Presentation Layer
Application Layer

Most industrial communication systems borrow concepts from this structure, but J1939 follows it more closely than many engineers initially realize.

The challenge is that the SAE documents are distributed according to these layers. Instead of explaining the entire system from top to bottom in one coherent narrative, the information is split into multiple standards documents.

That structure makes sense from a standards organization perspective.

It does not make learning easy.

Why the Standards Feel Difficult to Read

The SAE documentation style is extremely formal and reference-heavy.

You frequently encounter situations like this:

One document references another document
That second document references ISO standards
The ISO standards reference lower-layer specifications
Terminology is reused without re-explanation
Definitions sometimes appear many pages after their first use

This creates a steep learning curve for newcomers.

The documents are not written like textbooks.
They are written like legal engineering contracts.

There is a major difference.

A textbook explains concepts progressively.
A standards document defines behavior precisely.

Those are not the same thing.

The Most Important SAE J1939 Standards

While the complete J1939 collection contains many documents, a small core group forms the foundation of nearly every implementation.

Let’s look at the most important ones.

SAE J1939/11 — Physical Layer (250 kbit/s)

SAE J1939/11 defines the original physical layer for J1939 communications.

This includes:

Bus wiring
Electrical signaling
Termination requirements
Cable impedance
Connector recommendations
Shielding practices

This document corresponds primarily to OSI Layer 1 — the Physical Layer.

The original J1939 physical layer uses:

Classical CAN
250 kbit/s
Twisted pair wiring
120-ohm termination resistors at both ends of the bus

Many engineers first encounter J1939 while troubleshooting physical layer issues:

Missing termination resistors
Improper grounding
Excessive stub lengths
Noise problems
Faulty transceivers

Interestingly, some of the most common field failures have nothing to do with software at all.

SAE J1939/21 — Data Link Layer

This is arguably one of the most important J1939 documents.

SAE J1939/21 defines how messages are formatted and transported across the CAN bus.

It covers:

29-bit CAN identifiers
Priority handling
PGNs (Parameter Group Numbers)
Source addresses
Destination addresses
Broadcast messaging
Transport Protocol (TP)

This document primarily spans:

OSI Layer 2 (Data Link)
Parts of Layer 3 and Layer 4

One of the most brilliant aspects of J1939 is the way the 29-bit identifier is structured.

Instead of simply identifying a message, the identifier itself contains meaningful network information:

Message priority
PGN
Source address
Destination addressing behavior

This allows nodes to make intelligent decisions immediately upon receiving a frame.

Once you understand the identifier structure, the entire J1939 architecture suddenly starts making sense.

Before that moment, it feels like deciphering ancient hieroglyphics.

SAE J1939/71 — Vehicle Application Layer

This document is the heart of practical J1939 communication.

SAE J1939/71 defines:

Standard PGNs
SPNs (Suspect Parameter Numbers)
Message meanings
Parameter scaling
Units
Data interpretation

This corresponds largely to OSI Layer 7 — the Application Layer.

If you have ever decoded:

Engine speed
Oil pressure
Coolant temperature
Fuel rate
Vehicle speed

you were probably using information from J1939/71.

This is the document that transforms raw CAN data into meaningful engineering values.

Without J1939/71, J1939 would merely be structured data transport.
With it, the network becomes interoperable.

That interoperability is one of the greatest achievements of SAE J1939.

An engine ECU from one manufacturer can communicate with a dashboard from another manufacturer because both sides follow the same PGN and SPN definitions.

SAE J1939/73 — Diagnostics

If J1939/71 defines operational data, J1939/73 defines diagnostic behavior.

This document includes:

DM messages
Diagnostic Trouble Codes (DTCs)
Lamp status indicators
Active and inactive fault reporting
Freeze frame data

This standard is essential for:

Service tools
Fleet diagnostics
Maintenance systems
Emissions compliance

Some of the best-known messages include:

DM1 — Active Diagnostic Trouble Codes
DM2 — Previously Active DTCs
DM3 — Clear diagnostic information

For many developers, DM1 becomes their first serious encounter with real-world J1939 decoding.

And usually their first encounter with why the documentation can be frustrating.

The logic is excellent.
The explanation often is not.

SAE J1939/81 — Network Management

J1939/81 handles address claiming and network management.

This document explains how ECUs:

Join the network
Claim addresses
Resolve address conflicts
Identify themselves

This corresponds primarily to OSI Layer 3 — Network Layer behavior.

One of the elegant features of J1939 is dynamic address claiming.

Every ECU has a unique NAME field containing identity information such as:

Manufacturer code
Function
ECU instance
Identity number

When two devices attempt to use the same address, arbitration occurs automatically.

The node with the higher-priority NAME wins.

This mechanism allows large multi-vendor networks to operate without centralized configuration.

That is impressive engineering.

SAE J1939/31 — Network Layer

This document defines the connector architecture and network installation guidelines.

It covers:

Connector pinouts
Diagnostic connectors
Network topology recommendations

While not as intellectually exciting as PGNs or transport protocols, this document becomes extremely important in real-world vehicle integration.

Because eventually every elegant software design encounters a technician with a wiring harness.

SAE J1939/13 — Off-Board Diagnostics Connector

SAE J1939/13 defines the diagnostic connector used for service tools.

This includes:

Connector shape
Pin assignments
Electrical interface

If you plug a diagnostic interface into a heavy-duty truck, you are likely using a connector defined by J1939/13.

This standard helped create consistency across manufacturers and diagnostic equipment vendors.

SAE J1939/82 — Compliance Testing

J1939/82 defines compliance and interoperability testing.

This includes:

Protocol conformance
Address claim behavior
Transport protocol verification
Timing requirements

Many engineers ignore this document initially.

Then eventually discover why it exists.

A device that “mostly follows J1939” can still create major network problems.

J1939/82 attempts to reduce those interoperability failures.

The Genius of SAE J1939

Despite my criticism of the documentation style, I remain convinced that SAE J1939 itself is one of the finest industrial communication architectures ever developed.

Why?

Because it solved real-world interoperability problems remarkably well.

The system provides:

Multi-vendor compatibility
Deterministic communication
Scalable architecture
Standardized diagnostics
Structured parameter definitions
Robust network management

And it accomplished all of that decades ago using relatively modest CAN hardware.

That is not trivial.

Why Beginners Struggle

Most newcomers make the same mistake:

They try to read the standards sequentially.

That rarely works.

The documents constantly reference each other, meaning you often need knowledge from later documents to understand earlier ones.

A better approach is usually:

Learn CAN bus fundamentals first
Understand the 29-bit identifier structure
Learn PGNs and SPNs
Study address claiming
Then explore diagnostics and transport protocols

Once those foundations are clear, the standards become far easier to navigate.

Final Thoughts

SAE J1939 is a fascinating contradiction.

The communication architecture is elegant, powerful, and highly successful.
The standards documentation can feel fragmented, dense, and unnecessarily difficult for newcomers.

But once you push through that initial barrier, the design philosophy becomes surprisingly coherent.

The ISO 7-layer influence suddenly becomes visible.
The PGN structure starts making sense.
The transport protocols feel logical.
The diagnostics architecture becomes predictable.

And eventually you realize something important:

The difficulty is not that J1939 is poorly designed.

The difficulty is that the standards were never written to teach.

They were written to define.

SAE J1939 Starter Kit and Network Simulator

Our JCOM.J1939 Starter Kit and Network Simulator is designed to allow the experienced engineer and the beginner to experiment with SAE J1939 data communication without the need to connect to a real-world J1939 network, i.e., a diesel engine. It may sound obvious, but you need at least two nodes to establish a network. That fact applies especially to CAN/J1939, where the CAN controller shuts down after transmitting data without receiving a response. Therefore, our jCOM.J1939 Starter Kit and Network Simulator consists of two J1939 nodes, namely our jCOM.J1939.USB, an SAE J1939 ECU Simulator Board with USB Port.

The jCOM.J1939.USB gateway board is a high-performance, low-latency vehicle network adapter for SAE J1939 applications. The board supports the full SAE J1939 protocol according to J1939/81 Network Management (Address Claiming) and J1939/21 Transport Protocol (TP). More Information…