The SAE J1939 communication protocol is a family of standards that defines how electronic control units, or ECUs, exchange data over a Controller Area Network in heavy-duty vehicles and mobile equipment. It adds standardized addressing, message definitions, diagnostics, network management, and multi-packet communication to the underlying CAN technology.

In practical terms, CAN provides the communication bus. J1939 provides much of the language and organization that connected ECUs use on that bus.

SAE J1939 at a Glance

Characteristic	J1939 approach
Underlying network	Controller Area Network
Classical identifier format	29-bit extended CAN identifier
Message identification	Parameter Group Number, or PGN
Individual data values	Suspect Parameter Numbers, or SPNs
ECU identification	Source addresses
Communication modes	Broadcast and destination-specific
Network management	Address claiming and address management
Large messages	Multi-packet transport protocol
Diagnostics	Standardized diagnostic messages and services
Common applications	Heavy trucks, buses, construction equipment, agricultural machinery, and other mobile equipment

SAE maintains J1939 as a collection of related documents rather than one isolated specification. The SAE J1939 top-level document provides the overall framework, while subordinate documents define individual layers and services.

What Is the Difference Between CAN and J1939?

J1939 and CAN are related, but they are not interchangeable terms.

The Controller Area Network establishes the underlying method for transmitting frames between devices. It covers functions such as bus arbitration, error detection, frame formatting, and message transmission.

J1939 builds a higher-layer communication system on top of CAN.

CAN	SAE J1939
Defines how frames travel across the network	Defines how participating ECUs organize and interpret vehicle data
Supports standard and extended identifiers	Uses the extended identifier format in Classical J1939
Does not assign universal meaning to every message	Standardizes many message groups and parameters
Provides arbitration and error-handling mechanisms	Adds message priority, addressing, network management, diagnostics, and transport services
Can be used in many industries	Primarily targets heavy-duty vehicles and mobile equipment

A CAN controller can transmit a 29-bit frame without automatically being J1939-compliant. The identifier structure, message timing, address behavior, PGN definitions, SPN encoding, and applicable network-management rules must also conform to the relevant J1939 requirements.

For a wider comparison of network architectures, see ANZER’s guide to electronic communication bus protocols.

How the 29-Bit J1939 Identifier Works

The SAE J1939-21 data-link specification defines Classical J1939 communication using CAN’s extended 29-bit identifier format.

The identifier carries more than a basic message number. Its fields communicate information including:

Message priority
Data-page and parameter-group information
PDU format
A group extension or destination address, depending on message type
The transmitting ECU’s source address

The extended identifier increases the available identifier space. It does not increase the normal Classical CAN payload beyond eight data bytes.

When a parameter group contains more than eight bytes, J1939 uses a transport mechanism to divide and reconstruct the information across multiple CAN frames.

What Is a Parameter Group Number?

A Parameter Group Number, or PGN, identifies the meaning and format of a J1939 message group.

A PGN tells a receiving ECU what type of information the message contains and how the associated payload should be interpreted. Depending on the parameter group, the data may describe engine status, vehicle speed, temperatures, pressures, operating states, diagnostic information, or another defined function.

The PGN is derived from fields inside the 29-bit CAN identifier. It is not simply equivalent to the complete CAN identifier because the complete identifier also contains fields such as priority and source address.

PDU1 and PDU2 Messages

J1939 supports both destination-specific and broadcast-style communication.

PDU1 messages use the PDU Specific field as a destination address. They can therefore target a particular ECU or use a global destination.

PDU2 messages use that field as a group extension and are normally broadcast for any interested ECU to receive.

This destination-specific J1939 behavior should not be confused with an electrical interface dedicated to only two devices. ANZER’s article on point-to-point communication protocols explains that separate communication model.

What Is an SPN in J1939?

A Suspect Parameter Number, or SPN, identifies an individual parameter contained within a parameter group.

For each standardized parameter, the applicable J1939 documentation may define attributes such as:

Start bit or byte position
Data length
Resolution or scaling
Offset
Engineering unit
Valid range
Error or unavailable-data representations

A single PGN can contain several SPNs. For example, one message group may carry multiple operating measurements, with each measurement assigned its own SPN and decoding rules.

The current SAE J1939 Digital Annex provides the controlled reference for standard PGNs, SPNs, and related J1939 data definitions. OEM-specific or proprietary parameters may require separate controlled documentation.

How J1939 Address Claiming Works

Every ECU communicating on a J1939 network requires a source address.

However, a preferred address may already be in use by another device. The network therefore needs a controlled method for determining which ECU may use a particular address.

SAE J1939-81 network management defines the processes and messages used to manage ECU addresses. During address claiming, an ECU announces identifying information associated with its application and preferred source address. When devices attempt to claim the same address, the applicable network-management rules determine the outcome.

An implementation plan should define:

Preferred source addresses
Whether the device can select an alternative address
How address conflicts are handled
The device identity information used during claiming
Expected startup timing
Behavior when an address cannot be claimed

Address management is one reason a generic CAN implementation should not automatically be described as J1939-compatible.

How J1939 Sends Messages Larger Than Eight Bytes

A Classical CAN data frame normally carries no more than eight payload bytes. Some J1939 parameter groups require more data than one frame can contain.

J1939 therefore defines multi-packet transport methods.

Broadcast Announce Message

A Broadcast Announce Message, commonly called BAM, announces that a multi-packet message will be broadcast. The sender then transmits the segmented data packets without flow-control responses from each recipient.

Connection-Managed Transfer

Connection-managed communication uses a request-to-send and clear-to-send process. The sender and intended receiver coordinate packet flow, and either party can terminate the transfer when required.

The receiving implementation must reassemble the packets in the correct sequence before interpreting the complete parameter group.

J1939 also has a separate CAN FD data-link specification. A product team should not assume that a Classical J1939 device and a J1939 CAN FD implementation are interchangeable. The applicable physical layer, data-link specification, transceiver, connector, network speed, and software stack must be defined explicitly.

How J1939 Diagnostics Work

SAE J1939-73 defines J1939 diagnostic messages and services, including communication between networked control modules and vehicle service tools.

A diagnostic implementation may need to handle:

Active and previously detected fault information
Diagnostic trouble-code reporting
ECU identification
Software or calibration identification
Requests for diagnostic information
Clearing or managing diagnostic records
Service-tool communication
Multi-packet diagnostic messages

The exact messages and behavior depend on the applicable SAE documents, product requirements, and OEM implementation.

A device that only transmits operational data should not be assumed to satisfy the diagnostic requirements expected by a vehicle, machine, gateway, or service tool.

Where Is SAE J1939 Used?

J1939 is associated most strongly with heavy-duty vehicles, but its application range is broader.

Common implementations include:

Commercial trucks
Buses
Construction and earthmoving equipment
Agricultural and forestry machinery
Material-handling equipment
Mining vehicles
Fire and emergency vehicles
Mobile hydraulic equipment
Industrial engines
Generator and power systems
Other off-highway or specialized mobile platforms

Related standards may use concepts or structures derived from J1939 while defining different application data or physical-layer requirements. Engineers should identify the exact standard required by the target equipment rather than assuming all CAN-based mobile networks use identical J1939 rules.

Benefits of the SAE J1939 Communication Protocol

Standardized Data Organization

Standard PGNs and SPNs give ECUs a shared framework for identifying and interpreting many types of information.

Manufacturer-Spanning Communication

Properly implemented standard messages can make integration across participating suppliers more manageable than an entirely proprietary message architecture.

Priority-Based Bus Access

The identifier includes message priority, allowing higher-priority frames to win CAN arbitration when devices attempt to transmit simultaneously.

Integrated Diagnostics

J1939 includes defined diagnostic communication rather than treating diagnostics as an unrelated interface.

Broadcast and Destination-Specific Messaging

The protocol supports information intended for the entire network as well as communication directed toward a particular ECU.

Multi-Packet Data Transfer

Transport services allow parameter groups larger than a single Classical CAN frame to be transmitted and reconstructed.

J1939 Limitations and Integration Risks

J1939 standardization does not remove the need for system engineering.

Standardized and Proprietary Data Can Coexist

An OEM may use standard PGNs alongside proprietary parameters. Integrators need controlled documentation for both.

Document Revisions Matter

The J1939 family changes over time. Requirements should identify the exact document revisions and Digital Annex release used by the program.

Bit Rate and Physical Layer Must Match

A device cannot communicate reliably when its physical-layer implementation, termination, connector, or network bit rate does not match the target system.

Timing Is Part of Compatibility

Correct data encoding is not sufficient if messages are transmitted at the wrong repetition rate, timeout behavior is incorrect, or startup sequencing conflicts with the rest of the network.

Diagnostics Need Separate Validation

Operational communication can appear functional while diagnostic requests, fault reporting, or service-tool interaction remain incomplete.

J1939 Is Not a Complete System-Security Strategy

Network access, gateway architecture, remote connectivity, firmware security, diagnostic authorization, and cybersecurity controls require system-level analysis beyond basic message compatibility.

Design Considerations for a J1939 Electronic Product

A development team should establish a controlled J1939 communication specification before finalizing the electronics.

Network Requirements

Document:

Applicable SAE documents and revisions
Classical CAN or CAN FD implementation
Required physical-layer specification
Network bit rate
Connector and pinout
Termination requirements
Expected network length and topology
Environmental and electrical conditions

Message Requirements

Identify:

Required transmit PGNs
Required receive PGNs
SPN encoding and decoding rules
Transmission rates
Event-driven messages
Request and response behavior
Destination-specific messages
Proprietary PGNs and parameters
Timeout and missing-data behavior

ECU and Address Requirements

Define:

ECU NAME information
Preferred source address
Address-claiming behavior
Address-conflict handling
Startup sequence
Reset and power-cycle behavior

Diagnostics

Specify:

Required diagnostic messages
Fault-detection logic
Trouble-code mapping
Service-tool requirements
Diagnostic connector access
Record-clearing behavior
Firmware and calibration identification

Verification

The test plan should include:

Power-up and address claiming
Message timing
PGN/SPN decoding
Broadcast reception
Destination-specific communication
Request responses
Transport-protocol reassembly
Diagnostic-message behavior
Error handling
Bus loading
Power interruption and restart
Boundary and unavailable-data values

PCB Design and Manufacturing Considerations

Protocol functionality depends on both software and correctly manufactured electronics.

A design review should consider:

CAN transceiver selection
Transceiver voltage compatibility
Connector definition
CAN_H and CAN_L routing
Termination strategy
ESD and transient protection
Grounding
Isolation requirements
Power-supply stability
Test-point accessibility
Programming access
Firmware and configuration control
Environmental protection
Mechanical support for connectors

ANZER’s electronic design for manufacturability process can help identify layout, component, sourcing, assembly, and testing risks before production.

For product programs that need board development and manufacturing support, ANZER also provides custom electronic design and assembly solutions and PCB manufacturing services.

What to Include in a J1939 Electronics RFQ

Provide the manufacturing or design partner with a controlled package containing:

Product description and application
Target equipment or vehicle platform
Applicable J1939 documents and revisions
Network bit rate and physical-layer requirements
Approved connector and pinout
Required PGN and SPN matrix
Proprietary message definitions
ECU address and NAME requirements
Diagnostic-message requirements
Schematics
PCB files and fabrication notes
Bill of materials
Firmware and programming instructions
Assembly drawings
Harness drawings
Test procedure
Acceptance criteria
Environmental requirements
Traceability and documentation requirements
Prototype and production quantities
Revision-control process

Do not rely on the statement “supports J1939” as the complete technical requirement. Different devices can support different portions, revisions, physical layers, diagnostics, and proprietary messages.

How ANZER Supports OEM Electronic Programs

ANZER supports OEM electronic products from design and manufacturability review through PCB fabrication, SMT and through-hole assembly, wire-harness production, box-build integration, programming, testing, coating, potting, labeling, and packaging.

For a J1939-based product, the controlled communication requirements, applicable SAE documents, proprietary definitions, and final system-validation responsibility must remain clearly defined by the product owner.

ANZER can support the electronic design and manufacturing work needed to turn those controlled requirements into prototypes and production assemblies. This includes DFM and DFA review, BOM evaluation, PCB layout, prototype builds, PCB assembly, functional testing, harness integration, and complete system assembly.

Frequently Asked Questions

What is SAE J1939 in simple terms?

SAE J1939 is a standardized communication framework that helps ECUs exchange operating and diagnostic information over a CAN network in heavy-duty vehicles and mobile equipment.

Is J1939 the same as CAN bus?

No. CAN defines the underlying frame transmission, arbitration, and error-handling system. J1939 adds standardized message organization, addressing, PGNs, SPNs, diagnostics, network management, and transport services.

What is the difference between a PGN and an SPN?

A PGN identifies a message group and its overall data layout. An SPN identifies an individual parameter within that group, including how the parameter is positioned, scaled, and interpreted.

Does J1939 always operate at 250 kbit/s?

No. Different J1939 physical-layer specifications support different network configurations, including 250 kbit/s and 500 kbit/s implementations. The equipment specification must identify the required physical layer and bit rate.

What happens when a J1939 message exceeds eight bytes?

In Classical J1939, the transport protocol divides the parameter group into multiple CAN frames. The receiving ECU reassembles the packets before decoding the complete message.

Conclusion

The SAE J1939 communication protocol provides a structured method for ECU communication, addressing, diagnostics, and data exchange in heavy-duty vehicles and mobile equipment. Reliable implementation requires more than connecting a CAN transceiver. The product team must control the applicable standards, physical layer, PGNs, SPNs, address behavior, timing, diagnostics, proprietary data, firmware, hardware, and verification plan.

For support with electronic design, PCB manufacturing, prototype assembly, testing, harness integration, or box-build production, request an electronic manufacturing quote from ANZER.

Blog Post

SAE J1939 Communication Protocol: CAN, PGNs and SPNs