<< Click to Display Table of Contents >> Navigation:  Protocols > J1939

Introduction

J1939 is a protocol which runs on CAN channels with extended message IDs. It is not specified for CAN-FD. You can use normal CAN messages with standard messages IDs on this channel simultaneously.

The idea behind J1939 is, that there can be one CAN channel with plug in applications like trailers. If  two trailers are connected to a truck which might both be the same type, there will be the same control units in both. In this case there must be a way to address specific functions in specific trailers. For example to activate the back light of the last trailer only.

To archieve this, they defined that the message ID is dynamic, part of the message ID is the source and destination address.

The addresses are handled by so called controller applications (CA). A CA specifies a defined functionality in a control unit. A control unit can have several CA.

Each controller application has a unique NAME which is a 64 bit value. Part of the NAME is predefined like the number for the manufacturer or the industry group. But part will be changed dynamic like the vehicle instance, which indicates in which trailer the CA is.

Because a 64 bit value is a bit hard to use and there should not be that many CA on a CAN channel they defined that each CA has a 8 bit address. Some of the addresses are predefined, like the first instance of the engine CA has the address 0 and the second instance has the address 1. But there is an area of addresses which any CA can use.

On startup every CA sends an address claim message with their wanted address and their NAME. If there is another CA which uses the address already it will check if their NAME is smaller, if yes they will keep their address and send a claim with it, else they will need to take a new one. If no address can be claimed, the CA will stop sending any messages.

In the J1939 spec, signals are called specific parameter (SP) and messages are called parameter group (PG). Each SP has a number (SPN) and each PG has a number (PGN).

The 29 bit message ID is split in 3 parts. 3 bit priority, 18 bit PGN and 8 bit source address.
The PGN has 4 parts: 1 bit extended data page, 1 bit data page, 8 bit PDU format and 8 bit PDU specific.

The content of the PDU specific part depends on the PDU format part. If PDU format is below 240 it is the destination address, otherwise it is part of the PGN and the destination address is all CA.

 

Configuration

Below a CAN node a CA (Controller Application) can be created via the context menu.

Each CA has the following properties:

The NAME property consists of other properties:

For a new created CA the values for Function and NAME_VehicleSystem are set to unknown (all bits one). NAME_IdentityNumber will automatically be set to a unique value on this channel.
Changes to the NAME will change the parts and changes to the parts will change the NAME property.
If the function or the industry group are changed additionally the name of the CA and the default address gets updated according to the spec.

 

Address claiming

On simulation start a simulated CA will do address claim for the default address.
If the default address is set o 255 no address claim will be done.
If the address can’t be claimed and it is arbitrary address claim capable (NAME_ArbitraryAddressCapable is set), it will then try to claim another address.
If no address can be claimed, it will switch to “no address claimable” mode (address is set to 254) and stop sending automatically. Sending manually is still possible in this case.

For a real CA the address will be set to the default address. If an address claim message with the NAME of the CA is received it will change the address to the new one.

Supported J1939 Features:

 

Parameter Group (PG)

Below a CA a PG can be created via the context menu.

A PG is derived from a CAN message so it has the same properties.

Each PG has the following additional properties:

A newly created PG will have the PGN and priority. After setting a valid PGN the length of the PG is  automatically set.
Via the context menu "Create specific parameters (SP) according to PGN" the SP of this PG can be created.

Changes to the message ID or any other property which describes a part of it, will automatically change all the involved properties to the correct values.

The PG can be used like any other CAN message. The only differences are the massage ID parts and the length can be more than 8 bytes.
If the length is more than 8 bytes the J1939 transport protocol (TP) will be automatically used.

 

MuxMessage

Below a PG a multiplex message can be created via the context menu.
Because they were introduced for J1939 there is no difference to the ones in CAN messages.

 

Specific Parameter (SP)

Below a PG (parameter group) a parameter can be created via the context menu.
The only difference to CAN signals is the property SPN. The SPN is only used for the automatic creation of the SP below the PG.

 

Transport protocol (TP)

CanEasy supports the J1939 transport protocols. If a PG is larger than 8 byte it will automatically be transmitted by the transport protocol. If the PG is targeting all CA the BAM protocol is used, otherwise the CMDT protocol is used.

If the auto flag for a CA is deactivated, TP messages can still be sent. However, received TP messages are no longer answered.

 

Record

In the details window of the trace all parts of the J1939 message ID are interpreted. Via the context menu of the column header, additional columns for the J1939 message id parts can be activated.

If the TP is used, the combined messages are inserted into the record. Loading a record without the combined TP messages, they can be added via the record context menu "Analyze protocols".

Because the priority part of the message ID can change, it is ignored as filter in Trace and Plot. Additionally the filtering of the source and destination address can be deactivated via the context menu of the PG.