Contents
PGNs and SPNs — standardized meaning
A PGN (Parameter Group Number) identifies a message that groups related parameters. Engine speed, vehicle speed, and coolant temperature travel in the same PGN on any manufacturer's vehicle.
An SPN (Suspect Parameter Number) identifies an individual parameter inside a PGN. Resolution, offset, and units are defined in the standard, so receivers can convert to physical values without their own conversion tables.
This is J1939's greatest strength. Coming from passenger-car development, you will likely be surprised to find that you can understand the values without a DBC file.
29-bit identifiers and addresses
J1939 uses 29-bit extended identifiers that embed the priority, PGN, and source address. Addresses are 8 bits (0–253), with recommended values per function (engine = 0, transmission = 3, and so on).
Because nodes claiming the same address would collide, an arbitration procedure called address claiming is specified. Each node has a 64-bit NAME, claims an address at startup, and if there is a conflict, the node with the lower NAME wins.
When you add your own ECU to a vehicle, a missing or incomplete address-claim implementation causes hard-to-reproduce faults such as “sometimes it stops communicating.”
Data longer than 8 bytes (transport)
A CAN frame carries at most 8 bytes. Longer data is split and sent with the TP (Transport Protocol). There is a point-to-point RTS/CTS method (TP.CM_RTS / TP.CM_CTS) and a broadcast BAM (Broadcast Announce Message) method.
BAM sends one way without waiting for the receiver to be ready, so data can be missed. Handle it with care.
Extension to CAN FD (J1939-22)
J1939-22 (J1939-FD) is a new data-link layer for CAN FD. It handles up to 64 bytes per frame and introduces a container format that packs several PGNs into one frame.
The key point is that its implementation is separate from classic-CAN J1939. An existing stack cannot simply be reused, so if you plan to move to CAN FD, check this when choosing a stack.
Diagnostics and firmware updates
J1939-73 specifies diagnostics. Messages such as DM1 (active faults) and DM2 (previously active faults) express a fault as a pair of SPN and FMI (Failure Mode Identifier).
Emissions regulations add OBD-related requirements (such as the J1939-84 tests). For North America there are further compliance checks such as CARB's Clean Truck Check.
Firmware is usually updated through a bootloader over J1939. Design recovery from power loss during an update, identification of the update target, and an estimate of transfer time first. If there are security requirements, the bootloader must verify image signatures.
Related standards
ISO 11783 (ISOBUS) extends J1939 for agricultural machinery, adding implement–tractor interconnection, the virtual terminal (VT) and the task controller.
J1587 / J1708 are commercial-vehicle networks that predate J1939 and are still needed when servicing existing vehicles.
NMEA 2000 is a marine network based on J1939.
Frequently asked questions
- Can we write our own J1939 stack?
- Including address claiming, transport, and diagnostics, it is a sizable job. Address claiming and multi-packet transport in particular need testing against the conflicts and lost frames that happen on real vehicles, which is where in-house development tends to overrun. Commercial stacks are often supplied as source code, so you can choose one with porting to your MCU in mind.
- We plan to move to CAN FD. What should we check now?
- Three things: whether the stack you choose supports J1939-22; if so, whether it can coexist with classic CAN; and whether drivers exist for your MCU's CAN FD controller.
- Can we ask you to do the porting?
- Yes. Tell us the target MCU, CAN controller, functions you need (diagnostics and/or bootloader), and expected quantity, and we will reply with a configuration and a rough estimate.
Related product categories and solutions
- Middleware / protocol stacks (product category)
- Automotive ECU diagnostics, measurement, and calibration (product category)
- Automotive and industrial network devices / gateways (product category)
- Commercial, construction, and agricultural vehicles (SAE J1939) (solution)
- Automotive ECU diagnostics, measurement, and calibration (UDS / XCP / OBD) (solution)
Other technical guides
- How to choose an embedded RTOS
- CANopen basics — CiA 301 / 302 / 402 and how to develop CANopen devices
- UDS / DoIP vehicle diagnostics basics
- Embedded debugging and trace basics
- Designing production programming — cycle time, gang programming, and IP protection
- Automotive Ethernet basics — 100/1000BASE-T1, time sync, and measurement
- LIN basics — ISO 17987, LDF, and conformance testing
- What is functional safety? — an introduction to ISO 26262 / IEC 61508
Look up the terms
Discuss your setup
If you organize your requirements along the lines of this guide, we can reply early with a proposed configuration and a rough estimate. Partial questions are welcome too.
