firstname.lastname@example.org +46 35 17 29 56
HMS products and services enable you to...
With the cross-platform SAE J1939 Protocol Software 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.
SAE J1939 Protocol Software Packages
IXXAT PC CAN interfaces enable the easy connection
of PC-based applications to SAE J1939 based systems.
PC CAN Interfaces for SAE J1939
SAE J1939 API for Windows
We offer a wide range of tools for your SAE J1939 development, system commissioning and for trouble-shooting.
canAnalyser with CANopen extension
SAE J1939 Designer
SAE J1939 Diagnosis and Trouble-Shooting
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:
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 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 is divided in 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
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/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.
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.
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).
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.
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:
Most CA's like engine, transmission, etc. have a preferred address.
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
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 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”.
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 lenght: 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
In SAE J1939 messages with more than 8 bytes of data are transfered 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:
Figure: Peer-to-Peer messages
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:
Figure: Broadcast messages
Customized OEM solutions
and development services