SAE J1939

All you need for development
and production.

HMS products and services enable you to...

  • flexible and easily implement the SAE J1939 protocol into your devices, either using ready-to-use modules or protocol stacks
  • connect SAE J1939 devices to any other industrial network
  • connect your PC to SAE J1939 systems, enabling PC based control, configuration and analysis
  • analyze and maintain your systems

SAE J1939 Technology Introduction
SAE J1939 Products and Services
Protocol Software

Implement SAE J1939 on your own device

With the cross-platform SAE J1939 Stack J1939 devices can quickly and easily be developed. All communication mechanisms defined in the SAE J1939 specification are available, which means that developers can fully concentrate on their application.

  • Available for various microcontroller systems and compilers

emotas SAE J1939 Stack

PC Interfaces

Connect your PC to SAE J1939 Systems

Ixxat PC CAN interfaces enable the easy connection
of PC-based applications to SAE J1939 based systems.

  • Available in various form factors and for many PC interface standards 

PC CAN Interfaces for SAE J1939

CAN Tools

Analyze and Configure

We offer a wide range of tools for your SAE J1939 development, system commissioning and for troubleshooting.

  • canAnalyser – easily analyze, transmit and log your SAE J1939 messages and signals
  • emotas J1939 DeviceDesigner – editor and code generator for J1939 projects, supporting the emotas J1939 stack
  • CANopen trouble-shooting – powerful mobile hand-held or PC based tools

canAnalyser with CANopen extension
emotas J1939 DeviceDesigner 
SAE J1939 Diagnosis and Trouble-Shooting 

Comprehensive SAE J1939 Tool Chain

HMS offers a comprehensive, cost-effective tool chain for SAE J1939 applications. This ranges from protocol software, analysis and configuration tools to Windows API-based testing devices.
  • Central definition of all relevant parameters for the complete tool chain by the SAE J1939 desinger
  • Significantly increase the development speed by avoiding errors caused by inconsistent data sets
  • Reduced development risks, lowered development costs and shorter time to market

SAE J1939 – a short introduction

In the commercial vehicle sector standardized, serial protocols for communication between the individual electronic control units (ECUs) and components of the drive train are common since a while. With the use of a standardized serial protocol the following advantages are connected:

  • Manufacturers of components only need to implement one protocol; this mainly matters for commercial vehicles because of the low numbers of production.
  • Manufacturers of commercial vehicles can rely on components from different suppliers.
  • Interoperability between components is assured, that is the components from different manufacturers work together without adjustments.


The protocol SAE 1939 defined by the International Society of Automotive Engineers (SAE) replaces the SAE standards J1587 / J1708 and works on the physical layer with CAN-high-speed according to ISO 11898.

SAE J1939 is used in the range of heavy commercial vehicles both "On-Road" (Truck & Trailer) and "Off-Road" (Construction, cranes, etc.). In the field of agricultural and forestry machinery ISOBUS after ISO11784 is applied, in maritime environments, the protocol NMEA2000 is used and in the military field MilCAN is suitable - all of these protocols are based on J1939.

Due to the required compatibility with the existing J1708 / J1587 protocol the extension of the CAN message identifier from 11 to 29 bit, the development of CAN modules and respectively protocol implementations to support this message format was required for J1939.

Via J1939, it is possible to transfer both measurement values and control data as well as configure components. Moreover, there is the ability to read or delete diagnostic data of individual components and perform a calibration of individual controls.

In J1939 protocol not only the mode of transmission, the structure of messages and their segmenting, the flow control, and so on is specified, but also the content of the messages themselves is precisely defined. 


SAE J1939 in the ISO/OSI reference model

SAE J1939 is divided into multiple documents according to the OSI reference model, in which the document number refers to the associated layer in the reference model. The layers 5 and 6 are not needed in SAE J1939 analogous to virtually any field bus protocols and are therefore not specified.



Figure: SAE J1939 in the ISO/OSI reference model


Physical Layer

The SAE J1939 protocol is based on the CAN bus and uses it as the physical layer (Controller Area Network, ISO 11998-1 and ISO 11998-2). There are the following specifications:

  • SAE J1939/11 defines a CAN high-speed bus connection in accordance with ISO / DIS 11898 with shielded twisted-pair cable and ground. The data transfer rate is 250 kbit/s, the maximum number of nodes is 30, the maximum cable length is 40 meters.
  • SAE J1939/12 describes a variant with four-wire line and active bus termination. This eliminates the need for shielding and thus allows the use of an inexpensive cable.
  • The specification SAE J1939/14 doubles the data transfer rate from 250 kbit/s to 500 kbit/s.
  • SAE J1939/15 allows the use of unshielded twisted pair cable, in which case no more than 10 ECUs are allowed per network. 


Data Link Layer

SAE J1939/21 describes the data communication via CAN based on the specification CAN 2.0B. Exclusively, the “Extended Format" is used for this communication; the "standard format" is just for vendor-specific applications.
The specification thus determines how the 11-bit identifier must be used in order to exclude identifier collisions between the various vendor-specific messages. Besides the allocation and use of the 29-bit identifier the specification essentially describes the various network services for message request mode, acknowledged transmission, and fragmented transmission of large data blocks.


Network Layer

SAE J1939/31 essentially describes the functionality of a bridge for the transmission of messages between two network segments. Due to filter functions existing in the bridge this serves primarily to reduce the message traffic in the individual segments, e.g. between a tractor and its trailer.


Application Layer

The application layer with the related document SAE J1939/71 describes the actual data (parameters or network variables with value range, resolution, physical unit and the type of transmission). Each message is uniquely referenced on a number (parameter group number: PGN).


Network Management

J1939 network management is decentralized, that is, each control unit must implement a minimum functionality. The network management functions are described in the document SAE J1939/81. Since the network management can be considered as a separate unit which reaches through to the hardware (layer 1), it appears as an independent function block on the right side of the image.



Device name, message structure, address claiming (J1939/81)

Device address

The software of an electronic control unit (ECU) is the controller application (CA). An ECU may include one or more CA's. Each CA has a unique address and an associated device name. Each message that is sent by a CA contains this source address.



In the address space of J1939 there are 256 possible device addresses:

  • 0..127 – used for CA's with a preferred address and defined functions 
  • 128..247 – available for all CA’s
  • 248..253 – used for CA's with a preferred address and defined functions 
  • 254 – Null
  • 255 – global

Most CA's like the engine, transmission, etc. have a preferred address. 


Device names

J1939 defines device names, which each are represented by a 64-bit (8 bytes) long label and are used to identify the device and its function. The device name is divided into different elements, some of which are interdependent. The independent fields include the "industry group" and the "manufacturer's code".



Figure: Structure of device name

  • By the industry group the functions required in the network are determined, as the J1939 protocol not only is used in conventional commercial vehicles but also in the agricultural engineering, or in the maritime sector.
  • The manufacturer code must be applied for at the SAE and will be assigned by this. This manufacturer's code and the additional Identity Number (e.g. Serial Number) makes the entire name of a device unique worldwide.
  • The function instance is required if several CAs have the same function


CAN Identifier

J1939 messages are based on the CAN 2.0B specification and make specific use of "Extended Frames". These use a 29-bit identifier instead of the usual 11-bit identifier. J1939-21 defines the fields within this 29-bit identifier, as shown below.


Figure: Structure Parameter Group


  • The first three bits (priority field: P) define the priority of the message on the network and make sure that messages with a higher importance are sent before those with lower priority; a message with P=0 has the highest priority.
  • Using the Extended Data Page bit (EDP) and the Data Page bit (DP), four different "Data pages" for J1939 messages (Parameter Group) can be selected:

    EDP        DP            Description
    0              0              SAE J1939 Parameter Groups
    0              1              NMEA2000 defined
    1              0              SAE J1939 reserved
    1              1              ISO 15765-3 defined

  • The PDU Format field (Protocol Data Unit Format, PDU F) defines whether the message is intended for a specific device on the network or the entire network. If PDU F <240, a particular device shall be addressed, if PDU F > = 240, the message is intended for all devices.
  • The definition of PDU Specific (PDU S) field bases on the value of the PDU F field.

    a.) If the message is intended for a particular device (PDU F <239), PDU S is interpreted as the address of that device; in this case, the PDU S field is called the “Destination address field” (PDU 1).

    b.) If the message is intended for all devices (PDU F> = 240), PDU S is interpreted as “Group Extension Field”. This group expansion (PDU 2) is used to increase the number of possible broadcast messages.

  • The last eight bits of the CAN identifiers identify the address of the device that sends the current message = “Source Address Field”.


Address Claiming

Before a CA uses an address, it must claim it in the network; this procedure is called "address claiming" (ACL). 
Here, the unique device name is used to resolve conflicts in the address assignment: the smaller the numerical value, the higher the priority. On its startup the CA sends an “Address Claim PGN” (ACL, PGN 00EE00h) and waits a predetermined time for response. If no other CA claims the same address within this period, the CA can start with the normal communication.


Figure: Address Claiming Procedure


If another CA on the network already uses the same address, an address conflict occurs. The CA with the higher priority in its device name then obtains the address. It depends on the "address capability” of the CA how to proceed:

If the CA has the address capability "non self-configurable" it must send a "Cannot Claim Address" PGN with the “Source Address” zero (254). Otherwise, it may take a new address from the address pool of free addresses (128-247) for itself.


Figure: Address Claiming Procedure with address conflict




Name: Engine temperature
- PG number: 65262 (FEEE Hex)
- PDU format: 254 (FE Hex)
- PDU specific: 238 (EE Hex)
- Default priority: 6
- Transmission rate: 1 s
- Data length: 8 Byte

Description of data
Byte 1: Engine coolant temperature
Byte 2: Fuel temperature
Byte 3,4: Engine oil temperature
Byte 5,6: Turbo oil temperature
Byte 7: Engine intercooler temperature
Byte 8: Not defined



Fragmented transmission of large data blocks

In SAE J1939 messages with more than 8 bytes of data are transferred via “Fragmented transmission”. A distinction is made between subscriber-oriented communication (“Peer-to-peer”) and global communication (“Broadcast”).



In Peer-to-Peer communication the destination address (Destination Address) is specified. The data is addressed to a particular subscriber and the transmission is confirmed:

  • A peer-to-peer communication is controlled by the receiver by means of a "Clear to send" (CTS) message
  • The transmitter may only transfer the number of data segments that are defined in the receiver’s CTS (0-255)
  • The receiver can defer the information flow via a "Hold" function (CTS with zero data segments)
  • The transmission has been successfully completed, if the sender has received the "End of Message" (EOM)
  • Peer-to-Peer messages
    - Request To Send (RTS)
    - Clear To Send (CTS)
    - Connection Abort (CA)
    - End of Message Acknowledgement (EOM)
    - Data Transfer Message (DTM)


Figure: Peer-to-Peer messages



A broadcast is a communication without confirmation (No flow control). The transmitter/sender don’t know the recipient(s) of its message. The following procedure is applied:

  • The start of transmission is announced by the "Broadcast Announce Message" (BAM). This message contains the number of bytes, the number of segments and the number of the parameter group of data to be transmitted.
  • To give all potential recipients enough time to prepare the reception of the announced data block, the transmitter may only start 50 ms after his BAM-message with the transmission of his first data segment. Also between the individual data segments a period of 50 ms must be observed.
  • If a receiver has problems with the message reception he is not allowed to abort the transmission by "Connection Abort" because in general he is not the only receiver.
  • Broadcast Messages
    - Broadcast Announce Message (BAM)
    - Data Transfer Message (DTM)


Figure: Broadcast messages