1 2 3 4 5 6 7 8 9 10 11 12
3.1 SAE J1939
SAE J1939 - Recommended Practice for a Serial Control and Communications Vehicle Network
This document (SAE J1939) represents the top level of a number of documents known as the J1939 Standards Collection. It references to the OSI 7-Layer Model and the corresponding documents and provides a “J1939 Tutorial”. The bulk of the document, though, is comprised of 300+ pages containing data such as Parameter Group Assignments (Appendix A), Address and Identity Assignments (Appendix B) and Fault Reporting Parameters (Appendix C). Without these appendixes the document is a mere 19 pages long.
The SAE J1939 StandardThe J1939 Standards Collection was designed to follow the ISO/OSI 7-Layer Reference Model as far as necessary. Each layer is addressed by a corresponding document.
Note: In a CAN (Controller Area Network) network both layers, Data Link and Physical Layer, are represented by the actual CAN controller. As a matter of fact, the actual CAN protocol, i.e. the entire data communication management including bus arbitration, error detection and fault confinement, etc., etc., is implemented into silicon. CAN controllers know per default what to do and how to do it.
The SAE has named documents addressing the transport (4), session (5), and presentation (6) layer in the ISO/OSI 7-Layer Reference Model. These layers are not documented (in all consequence they are not necessary for J1939) and thus the corresponding documents have not been created.
Additional documents such as J1939/01, J1939/02 and J1939/81 do not refer directly to any of the seven layers and are regarded as additional functions that may affect several layers.As the name, J1939 Standards Collection, implies the J1939 standard comprises of a number of documents:
Document
Description
J1939
Recommended Practice for a Serial Control and Communications Vehicle Network[1]
J1939-01
Recommended Practice for Control And Communications Network for On-Highway Equipment
J1939-02
Agricultural and Forestry Off-Road Machinery Control and Communication Network[2]
J1939-11
Physical Layer - 250k bits/s, Twisted Shielded Pair
J1939-13
Off-Board Diagnostics Connector
J1939-15
Reduced Physical Layer, 250k bits/sec, Un-Shielded Twisted Pair (UTP)
J1939-21
Data Link Layer
J1939-31
Network Layer
J1939-71
Vehicle Application Layer
J1939-73
Application Layer - Diagnostics
J1939-74
Application - Configurable Messaging
J1939-75
Application Layer - Generator Sets and Industrial
J1939-81
Network Management
[1] This document does exist, however, the hyperlink on the SAE web site produces an error message.
[2] This document is not listed in the "Core J1939 Standards" list on the SAE web site, but it can be found through their search feature. Reference: http://www.sae.org/technical/standards/J1939/2_200608
Introduction to J1939
Note: It may seem that information on this section of our web site is somewhat repetitive. The reason lies in the fact that a great amount on information in the J1939 Standards Collection is redundant.
The Society of Automotive Engineers (SAE) Truck and Bus Control and Communications Subcommittee has developed a family of standards concerning the design and use of devices that transmit electronic signals and control information among vehicle components. SAE J1939 and its companion documents have quickly become the accepted industry standard and the Controller Area Network (CAN) of choice for off-highway machines in applications such as construction, material handling, and forestry machines.
J1939 is a higher-layer protocol based on Controller Area Network (CAN). It provides serial data communications between microprocessor systems (also called Electronic Control Units - ECU) in any kind of heavy duty vehicles. The messages exchanged between these units can be data such as vehicle road speed, torque control message from the transmission to the engine, oil temperature, and many more.
The protocol features of J1939 are based on two older SAE (Society of Automotive Engineers) specifications:
1. SAE J1708
SAE J1708 specifies on the physical layer of the communication link. It uses RS485 as an electrical layer operating at 9600 baud. (Note: Unlike RS232/485 there are no message collisions under CAN). Messages under J1708 start with a Message Identification Character, followed by the data information and a checksum. The message length is 21 characters (or less) and each data character is 10 bits long. Each character starts with a start bit of low polarity.
2. SAE J1587
SAE J1587 is a joint SAE/TMS "Recommended Practices for Electronic Data Exchange Between Microcomputer Systems in Heavy-Duty Vehicle Applications". It regulates the communication and standardized data exchange between ECUs based on J1708 networks.
J1939 is designed to replicate the functionality of J1708 and J1587 including control system support. Vehicle applications may utilize either one of both specifications.
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 211 (= 2048) different messages. A 29 bit identifier (extended format) allows a total of 229 (= 536+ million) messages.
The following picture demonstrates the use of the 29-Bit message ID:
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:
PriorityThe 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.
The picture below shows the mapping of a J1939 message into the extended CAN 29-Bit message frame:
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.
Data Field: 0 bytes
Data Field: 8 bytes
No bit stuffing
64
128
Max. bit stuffing
75
156
Average bit stuffing
67
132
The next table (below) lists the number of messages per second based on data field length and bit stuffing applying a 250k bit/sec baud rate (= 4 µsec) as required by the SAE J1939/11 Standard.
Data Bytes
Frame Length
Bit Stuffing
Total Frame Time [µsec]
Max. Messages/sec
0
64
None
256
3906
0
67
Average
268
3731
0
75
Max.
300
3333
8
128
None
512
1953
8
132
Average
528
1894
8
156
Max.
624
1603
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.
In addition, bridges can provide message filtering to prevent unnecessary message traffic in the sub-network. Bridges allow the continued operation of the main J1939 sub-network even in cases of bus failures in other sub-networks or when the sub-networks are disconnected from the main sub-network, for instance, when a trailer is physically removed from the tractor.
