J1939-11 Physical Layer

The physical layer of J1939 is based on Controller Area Network (CAN) as described in ISO11898. J1939-11 specifies a shielded twisted pair wire with a maximum length of 40 m (roughly 120 ft.). The CAN baud rate is 250 Kbit/sec per standard. The maximum number of ECUs is limited to 30 for one segment. Several units may be connected using special interconnection ECUs.

J1939-13 Off-Board Diagnostic Connector

J1939-13 defines a standard connector for diagnostic purpose. The connector is a Deutsch HD10 - 9 – 1939 (9 pins, round connector).
 

J1939/15 Reduced Physical Layer

J1939/15 describes a physical layer that utilizes an Unshielded Twisted Pair (UTP) cable.

J1939-21 Data Link Layer

J1939-21 defines the use of the CAN data frame (29-bit identifier, Permanent Group Numbers - PGN etc.) and the transport protocol functions, i.e. a definition of how messages longer than the standard CAN data length (8 bytes) are transmitted in a J1939 bus network. 

J1939-31 Network Layer

J1939-31 describes the services and functions needed for intercommunication between different segments of a J1939 network.

J1939-71 Vehicle Application Layer

J1939-71 describes and defines the Permanent Group Numbers. This document is updated very frequently to incorporate new standard parameters and messages.   

J1939-73 Application Layer – Diagnostics

J1939-71 defines functions and messages for accessing diagnostic and calibration data. There are several predefined Diagnostic Messages (DM) used for:

• Reading and writing to ECU memory

• Reporting diagnostic information when running

• Identification of lamp status

• Reading and clearing Diagnostic Trouble Codes (DTCs)

• Start/stop broadcast DMs

J1939/74 Application - Configurable Messaging

J1939/74 describes the message structure for a set of messages that enable the user to determine and announce the parameter placement within a particular message.

J1939/75 Application Layer - Generator Sets and Industrial

J1939/75 describes the parameters and parameter groups predominantly associated with monitoring and control generators and other driven equipment for electric power generation as well as industrial applications.

J1939-81 Network Management

J1939-81 provides information about the architecture of an ECU Name and how the ECU claims an addressing using that Name. The Name is a 64 bit (8 bytes) long number giving every ECU a unique identity.
 

Message Format

J1939 uses only the 29-Bit identifier (In fact, the CAN standard was extended from 11 to 29 bit per request by the SAE in order to support J1939). J1939 uses the identifier, among other features, to identify the source and, in some cases, the destination of data on the bus.

The 29 bit message identifier consists of the regular 11 bit base identifier and an 18 bit identifier extension. The distinction between CAN base frame format and CAN extended frame format is accomplished by using the IDE bit inside the Control Field. A low (dominant) IDE bit indicates an 11 bit message identifier, a high (recessive) IDE bit indicates a 29 bit identifier.

An 11 bit identifier (standard format) allows a total of 2¹¹ (= 2048) different messages. A 29 bit identifier (extended format) allows a total of 2²⁹ (= 536+ million) messages.

The parameters embedded in the 29-Bit message identifier are divided into two sections, PGN (Parameter Group Number) and the 8 bit source address.

The parameters embedded in the PGN are:

Priority

The first three bits in the identifier represent the priority during the arbitration process, thus providing eight priority levels.  In compliance with the CAN standard a value of 0 (000) has the highest priority; a value of 8 (111) has the lowest priority. High priority messages would be assigned to time critical data such as, for instance, torque control data from the transmission to the engine. Lower level priorities are suitable for non-time-critical data such as, for instance, engine configuration data.

The priority field, for the purposes of network tuning, may be programmable for each message type.

R

The R bit is reserved for future purposes and should always be set to 0 when transmitting messages.

DP – Data Page

The DP bit works as a page selector for the following PDU (Protocol Data Unit) Format (PF) field. Currently this bit is at 0, pointing to page 0, which in turn points to all currently defined messages. Page 1 will be used to provide extended capacity for the future, i.e. as soon as page 0 has reached its capacity.

PDU Format (PF)

PDU (Protocol Data Unit) Formats are described in SAE J1939/21.
 

PDU Specific (PS)

PDU Specific means that its content is interpreted according to the information in the PDU Format (PF). A PF value between 0 and 239 (PDU1) indicates a destination address in PS. A PF value between 240 and 255 (PDU2) indicates a Group Extension (GU) to the PDU Format (PF). The GU is used to increase the number of available messages to be broadcasted throughout the network.

Note the high-lighted portion in the J1939 Frame Architecture that points to PDU Format Field (PF). The PF is divided into two sections, separated by the CAN SRR and IDE bit.  The SRR and IDE bits are entirely defined by the CAN standard 2.0B and thus are not described or modified by the SAE J1939 standard. For the same reason, some documentation may refer to a PF length of 10 bits.

The last 8 bits of the 29-Bit message identifier contain the source address, i.e. the address of the transmitting ECU (node). There is a total of 254 addresses available and every address must be unique within the network, i.e.  ECUs cannot share addresses. PGNs, however, are independent of the source address, meaning every ECU is allowed to transmit any message.

As noted previously, the parameters embedded in the 29-Bit message identifier are divided into two sections, PGN (Parameter Group Number) and the 8 bit source address (See picture 3.1.2.2). The PGN identifies the Parameter Group (PG), which covers the Reserved bit, Data Page, PDU Format and PDU Specific field. PGs also point to information of parameter assignments within the 8 byte CAN data field of each message as well as repetition rate and priority.

The structure of the PGN allows a total of 8672 different Parameter Groups per page. Parameter Groups and Parameter Group Numbers are described in the SAE J1939/21 document. Current assignments are listed in the SAE J1939 standard – Appendix A.

Addresses and NAME

Each ECU in a J1939 vehicle network must hold at least one name and one address for identification purposes. Single electronic units are allowed, however, to control multiple names and addresses.

The ECU address defines the source or destination for messages.

The ECU name includes an indication of the ECU’s main function performed at the ECU’s address. A function instance indicator is added in cases where multiple ECUs with the same main function share the same network.

The J1939 standard allows up to 254 ECUs with the same function to share the same network, where each ECU is identified by their individual address and name.

SAE J1939 defines a 64 bit NAME, as shown in the picture below, to uniquely identify each ECU in a network.

While the 64 bit NAME is certainly appropriate to uniquely identify nodes (ECUs) and their function in a J1939 network, it will nevertheless necessitate unreasonable resources to maintain standard communications.

In order to provide a more efficient solution, the SAE J1939 Standard defines an address claim procedure, where each ECU utilizes an 8 bit address to identify the source of a message or to access (destination address) another ECU in the network. The address claim procedure is designed to assign addresses to ECUs right after the network has been initialized and thus assuring that the assigned address is unique to the ECU. For instance, an engine may be assigned the address 0 while another engine is present, which will be assigned another address (e.g. 1) and instance.

In addition, the SAE J1939 Standard defines Preferred Addresses to commonly used devices in order to minimize the rate of multiple devices demanding the same address and thus optimizing the process claim process.  ECUs will generally use their assigned Preferred Address immediately after the power up process, but in order to prevent any address claim conflicts,  each ECU must first announce which addresses it intends to claim.

The address claim feature considers two possible scenarios:

1. Sending an Address Claimed message

This first scenario addresses a standard J1939 network startup. Upon powering up (or when requested), an ECU will send an Address Claimed message into the CAN bus in order to claim an address. All ECUs receiving the address claim will record and verify the newly claimed address with their internal address table. In case of an address conflict, i.e. should two or more ECUs claim the same address, the ECU with the lowest NAME value will succeed and use the address as claimed. The remaining ECUs must claim a different address or stop transmitting to the network.

2. Request for Address Claimed message

Requesting an Address Claimed message from all nodes in the network and, as a result, determining addresses claimed by other ECUs, is the necessary procedure for ECUs powering up late for various reasons, but especially transitional ECUs. Such transitional ECUs may be diagnostics tools, service tools, and trailers, etc. This approach allows the ECU to determine and claim an available address or to find out which ECUs are currently on the network.

There are several options to resolve the situation where an address claim conflict is being detected and they depend on the ECUs’ capabilities:

Ø       Self-Configurable ECUs

A self-configurable ECU provides the ability of dynamically processing and claiming unused addresses. Such ECUs are largely diagnostics tools, service tools, and bridges, etc.

Ø       Command Configurable ECUs

Service tools or bridges may request (command) certain ECUs to assume an address that specifically serves the function of the service tool or bridge.

Ø       Service Configurable ECUs

These are ECUs whose address may be changed manually by service personnel (e.g. DIP switches) or through a service tool. Service tools usually use proprietary techniques and, as a result, the process of commanding a new address may differ from the process as described for Command Configurable ECUs.

Ø       Non-Configurable ECUs

As the name implies, Non-Configurable ECUs are neither self-configurable nor re-programmable, i.e. their address cannot be changed after they claimed it initially.

Communication Methods

SAE J1939 provides three communication methods, each serving a specific purpose.

1. Destination Specific Communications:

Destination specific communications use PDU1 (PF values 0 to 239), but also including the global destination address 255. There are cases where this method will require the utilization of destination specific Program Group Numbers, for instance, in the case of more than one engine. A torque message, for example, must be sent only to the desired engine and not to both.

2. Broadcast Communications

Broadcast communications use PDU2 (PF values 240 to 255) and, as the name implies, they can include:

Ø       Sending a message from a single or multiple sources to a single destination.

Ø       Sending a message from a single or multiple sources to multiple destinations.

3. Proprietary Communications

Proprietary communications use either PDU1 or PDU2 and, as the name implies, they are useful in case where standard communications are not practical.

The use of PDU1 or PDU2 indicates that there may be:

Ø       Broadcast Proprietary Communications

and

Ø       Destination Specific Proprietary Communications

A Parameter Group Number (PGN) has been assigned for both proprietary communication types.

Receiving Messages

The reception and processing of received messages are explained in detail in SAE J1939/21 (Data Link Layer) and J1939/7x (Application Layer).

In general a received message is handled according to the communication method:

Ø       Destination Specific Request or Command

Each receiving ECU must determine whether the incoming destination address matches its own address and if yes, it must process the message and respond accordingly.

Ø       Global Request

Each ECU in the network, even the sender of the request, must process the message and respond if the requested data is available.

Ø       Broadcast

Each ECU must determine individually whether or not the message is relevant.

Transmitting Messages

In addition to the 29 bit message identifier a J1939 message also contains further fields according to the CAN 2.0B standard, where the data field is, naturally, of special importance.

Before transmitting a message the data field needs to be filled with the appropriate information by first referencing to the applicable SAE J1939 documents. This procedure will identify the Parameter Group Number (PGN), the message frequency (transmission rate) and default priority. Also included is a data field format, since, typically, there are multiple data items packaged within one message.

Some Parameter Group Numbers (PGN) may be longer than eight bytes and they must be transmitted in a multi-packet message according to SAE J1939/21 - Data Link Layer.

ECU Design Requirements

Further details referring to ECU Design requirements can be found in SAE J1939/11, SAE J1939/21 and SAE J1939/7x.

The requirements for an ECU in a J1939 network are predominantly based on the assumption that there should be sufficient processing power (Processor speed, amount of RAM, etc.) to guarantee that no message will be lost due to hardware or software design limitations. In other words, the ECU must be able to handle the message frequency sufficiently. The message frequency in turn is a function of message length and bit time (or baud rate).

The data field may contain between 0 to 8 bytes of data. The table below displays the CAN frame length based on number of data bytes and bit stuffing.

In the worst case scenario, i.e. based on the highest possible message frequency, a message can enter the network roughly every 256 microseconds. Even though such a scenario is very unlikely to occur in a J1939 network the ECU must be able to receive (and/or buffer) all messages based on the worst case scenario as described here.

Network Topology

A J1939 network may consist of several network segments that are connected by network interconnecting ECUs (bridges). The ECUs in each J1939 network segment are connected by a single, linear, shielded twisted pair of wires.

The wiring topology of the network should be as straight as possible, i.e. using short stub lengths and avoiding complex network structures (even though almost any network structure is possible under CAN).

A simple network structure, as emphasized through the linear bus requirement, is necessary to minimize reflections of the electrical signals.

In order to suppress reflections even further each bus segment should be terminated by resistors, which are typically 120 Ω. The termination resistors should always be connected on both ends of the bus. They should never be physically attached to a CAN node, because the bus would loose proper termination in case this specific node is being removed.

The segmentation of a J1939 network, i.e. dividing the network into a number of sub-networks, is necessary, for instance, to allow a tractor to pull one or more trailers. The segments are connected through the use of network interconnecting ECUs (bridges). Bridges not only provide electrical isolation, but they can also connect sub-networks that are not compatible with the other sub-networks.