Elkhart Brass Industrial Systems Elkhart Brass Industrial Systems
Elkhart Brass - Industrial Systems




Home


Definitions


Abbreviations


OSI Model


Tutorial

Message Format

Addresses & Name

Communication Methods

Transmitting Messages

Receiving Messages

ECU Design

Network Topology

Preassigned Values

Parameter Group Numbers

Data Field Grouping

NAME Functions

Manufacturer Code

Preferred Address

Suspect Parameter Nubmer

Application Examples


Network Layer

Definitions

Layer Description

Multisegment Justification

Network Topology

Network Addressing

Off-Tractor Segment

Proprietary Messages

11-Bit Identifier


Diagnostics Layer

SAE J1939-73

Definitions

Abbreviations

Technical Requirements

Diagnostic Capabilities

Diagnostic Procedures

PGN Definitions

Active DTC

DM1 Transmission Rate

Suspect Parameter Numbers

Failure Mode Identifier

Previously Active DTCs

Seed Requirements

Seed Completed

Use Long Seed

Valid Seed Values

No Key Required

Long Key Values

Expected Completion Time

Binary Data Occurrences

Boot Load Data

Data Security

Failure Mode (FMI)

Memory Access Design

Data Security

General Rules

ISO-15765

Abbreviations

Network Services

Service Primitives

Data Specification

7 Layer Protocol

Single Frame

Multiple Frame

Network PDU

Single Frame PDU

Consecutive Frame PDU

PDU Description

Can Analyzer Tool (CAT)

Application Structure

Basic Steps

Can Setup

Upload Buffer




Recommended Practice for a Serial Control and Communications Vehicle Network

SAE J1939 is intended as a guide toward standard practice and are subject to change so as to keep pace with experience and technical advances.

SCOPE

SAE J1939 is intended for light, medium, and heavy duty vehicles used on or off road and also including appropriate stationary applications which use vehicle derived components. Vehicles of interest include, but are not limited to: on and off highway trucks and their trailers; construction equipment; and agricultural equipment and implements.

J1939 is intended to provide an open interconnect system for electronic systems. Adherence to this standard will allow Electronic Control Units to communicate with each other by providing a standardized architecture.

Open Network

An SAE J1939 network is open to the degree that any two ECUs which conform to the same J1939/0X document can be connected via the network and communicate with each other without functional interference. The SAE J1939/0x documents describe a specific type of application, typically representing a specific industry to which it pertains such as agricultural or heavy duty trucks. ECUs which conform to a different SAE J1939/0X document may not be capable of communicating directly with one another and in some cases may cause degradation or complete disruption of the entire network.

Definitions and Abbreviations

Definitions provided herein will supersede those contained in SAE J1213. SAE J1213 will otherwise apply throughout.

Definitions

  • Acknowledgement (ACK): - Confirms that the requested action has been understood and performed.

  • Address: The 8 bit field (or fields) used to define the source (and destination when applicable) of a message (e.g. engine, transmission, etc.)

  • Arbitration: The process by which one or more ECUs resolve conflicts in obtaining access to a shared network bus.

  • Bit Stuffing: A procedure used to assure the transmitted and received messages maintain a minimum number of dominant to recessive edges, and vise versa, to maintain the proper resynchronization within the string of bits in a CAN Data Frame. See CAN specification for a more detailed discussion.

  • Bridge: A device which stores and forwards messages between two SAE J1939 network segments. This permits changes in the media, the electrical interface, and data rate between segments. The protocol and address space remain the same on both sides of the bridge. Note that a bridge may selectively filter messages going across it so that the bus load is minimized on each segment.

  • Bus: The physical media and attached nodes of a network not interconnected by network interconnection ECUs. A single segment of a network is characterized by all of the ECUs "seeing" the signal at the same time (i.e. there is no intermediate ECU between electrical sections of the network). Multiple segments can be connected together by network interconnection ECUs including repeaters, bridges, and routers.

  • CAN Data Frame: the ordered bit fields necessary to create a CAN frame used to convey data, beginning with an SOF and ending with an EOF.

  • Cyclic Redundancy Check (CRC): An error control mechanism. A 15 bit cyclic redundancy check is performed for detecting transmission errors. Given a k-bit frame or message, the transmitter generates an n-bit sequence, known as a Frame Check Sequence so that the resulting frame, consisting of k+n bits is exactly divisible by some predefined number. The receiver then divides the incoming frame by the same number and, if there is no remainder, assumes that there was no error.

  • Data Field: A 0 to 64 bit field normally placed in a CAN Data Frame which contains the data as defined in the Application Layer (document SAE J1939/7X).

  • Data Page: One bit in the identifier portion of the CAN Arbitration Field is used to select on of two pages of Parameter Group Numbers (PGN). This provides for the future growth of Parameter Group definitions. It also is one of the fields used to determine the Parameter Group Number which labels the Data Field of the CAN Data Frame.

  • Destination Address (DA): This a Protocol Data Unit (PDU) specific field in the 29 bit CAN identifier used to indicate the address of the ECU intended to receive the SAE J1939 message.

  • Device: A physical component with one or more ECUs and network connections.

  • Electronic Control Unit: A computer based electronic assembly from which SAE J1939 messages may be sent or received.

  • End of Frame (EOF): A 7 bit field marking the end of a CAN data frame.

  • Extended Frame: A CAN Data Frame using a 29 bit identifier as defined in the CAN 2.0 specification.

  • Frame: A series of data bits making up a complete message. the frame is subdivided into a number of fields, each field containing a predefined data type. See CAN Data Frame.

  • Function: A capability of a vehicle system having one or more ECUs that are connected to an SAE J1939 bus segment of a Vehicle System. The function value is used in the 8 bit Function Field in the 64 bit NAME entity. (See SAE J1939/81, Section 4.1).

  • Gateway: this device permits data to be transmitted between two networks with different protocols or message sets. The gateway provides a means to repackage parameters into new message groups when transferring messages from one segment to another.

  • Group Extension (GE): This is a Protocol Data Unit (PDU) specific field of an SAE J1939 CAN Data Frame that is used as part of the information necessary to determine the Parameter Group Number (PGN).

  • Identifier: The identifier portion of the CAN arbitration field.

  • Idle: A state on the CAN bus where no node is transmitting or attempting to transmit data.

  • Implement: A machine consisting of one or more ECUs which may be attached to or detached from the vehicle as a unit.

  • Media: The physical entity which conveys the electrical transmission (or equivalent means of communication) between ECUs on the network. For SAE J1939/11, the media consists of shielded twisted pair copper wires.

  • Message: A Message is equivalent ot one or more CAN Data Frames that have the same Parameter Group Number. For instance, the information related to a single Parameter Group Number to be transferred on the bus may take several CAN Data Frames.

  • Multipacket Message: A type of SAE J1939 message which is used when more than one CAN data frame is required to transmit all data specific to a given Parameter Group Number. Each CAN data frame will have the same identifier, but will contain different data in each packet.

  • NAME: An 8 byte value which uniquely identifies the primary function of an ECU and its instance on the network. A device's NAME must be unique, no two devices may share the same NAME value on a given vehicle network.

  • Node: A specific hardware connection of an ECU to the physical media. A specific node may have more than one address claimed on the network.

  • Non-Volatile: Retention of changeable memory values even though power is turned off for any reason. This term is used with respect to data values, such as ECU addresses or NAMEs, that are changed during use. Read Only Memory (ROM) is technically non-volatile, but is not changeable during use and thus is not what is referred to in these documents.

  • Negative-Acknowledgement (NACK): A response which indicates that a message has not been understood or a requested action could not be performed.

  • Packet: A single CAN Data Frame. This can also be a message if the Parameter Group to be transferred can be expressed in one CAN data frame.

  • Parameter Group: A collection of parameters that are conveyed in an SAE J1939 message. Parameter groups include commands, data, requests, acknowledgements, and negative acknowledgements. The Parameter Group identifies the data in a message, regardless of whether it is a single packet or multipacket message. Parameter Groups are nto dependent on the source address field thus allowing any source to send any Parameter Group.

  • Parameter Group Number: A three byte (24 bit) sequence composed of the Reserved Bit, Data Page, Protocol Data Unit Format, and Group Extension fields. The Parameter Group Number uniquely identifies a particular Parameter Group.

  • PDU Format (PF): An 8 bit field in the 29 bit identifier that identifies the Protocol Data Unit (PDU) format and is used in whole or in part to provide a label for a Parameter Group. It also is one of the fields used to determine the Parameter Group Number which labels the data field of the CAN Data Frame.

  • PDU Specific (PS): An 8-bit field in the 29 bit identifier whose definition depends upon the value of the Protocol Data Unit (PDU) Format field. It can be either a Destination Address (DA) or Group Extension (GE). It also is one of the fields used to determine the Parameter Group Number which labels the data field of the CAN Data Frame.

  • PDU1 Format: A Protocol Data Unit format used for messages that are to be sent to a Destination Address (DA). The Protocol Data Unit Specific field contains the Destination Address (specific or global).

  • PDU2 Format: A Protocol Data Unit format used to send information that has been labeled using the Group Extension Technique. This Protocol Data Unit does not contain a Destination Address. The Protocol Data Unit Specific Field contains the Group Extension in the case of PDU2 formats.

  • Preferred Address: The address that an ECU will attempt to use first when claiming an address. Preferred Addresses are assigned by the committee.

  • Priority: A 3-bit field in an identifier that establishes the arbitration priority of the information communicated. The higheset priroity is 0 and the lowest priorty is seven.

  • Protocol Data Unit(PDU): A Protocol Data Unit is an SAE1939 specific CAN Data Frame format.

  • Remote Transmission Request (RTR): A feature of the CAN protocol allowing an ECU to request that another ECU or ECUs send a message. This feature is not used is SAE J1939. An alternate request mechanism is specified for SAE J1939.

  • Repeater: An ECU which regenerates the bus signal onto another segment of media. The permits the network to connect more electrical loads (ECUs) onto the bus, or to connect to another type of media (Phsical Layer Expansion). The speed (data rate), protocol (data link layer), and address space are the same on both sides of the repeater. For SAE J1939, and delays in regenerating the data signal must be kept to a very small fraction of one bit interval.

  • Reserved Bit: A bit in an SAE J1939 29 bit identifier reserved for future definition by SAE. It also is one of the fields used to determine the Parameter Group Number which lablels the data field of the CAN Data Frame.

  • Router: An ECU which allows segments with indepedendent address space, data rates, and media to exchange messages. A router may permit each segment to operate with minimum bus loading, yet still obtains critical messages from remote segments. The protocol remains the same across all segments. Note that the router must have look up tables to permit the translation and routing of a message with ID X on segment 1 to ID Y on segment 2.

  • Segment: The physical media and attached nodes of a network not interconnected by network interconnection ECUs. A single segment of a network is characterized by all of the ECUs seeing the signal at the same time. Mutliple segments can be connected together by network interconnection ECUs including repeaters, bridges and routers.

  • Source Address (SA): A 8-bit field in the 29 bit identifier which allows for the unique identification of the source of a message. The Source Address field contains the address of the ECU that is sending the messsage.

  • Standard Frame: A CAN Data Frame using an 11 bit identifier as defined in the CAN 2.0b specification.

  • Start of Frame (SOF): The initial bit in a CAN frame serving only to indicate the beginning of frame.

  • Subnetwork: The refers to the network activity (message traffic) on a specific SAE J1939 segment when multiple segments are used. Subnetworks may include: Tractor, Trailer, Implement and Braking System.

  • Vehicle: A machine which, in most applications, includes the ability to propel itself and includes one or more SAE J1939 segments. A vehicle may be assembled of one or more Vehicle Systems which are connected together to form the whole vehicle.

  • Vehicle System: A subcomponent of a vehicle, or a component that is analogous to a subcomponent of a vehicle, that includes one or more SAE J1939 segments and may be connected or disconnected from the vehicle. A Vehicle System may be made up of one or more Functions, which have ECUs that are connected to an SAE J1939 segment of the Vehcile System.

Abbreviations
ABS Antilock Braking System
ACK Acknowledgment
AP Accelerator Pedal
ASR Acceleration Slip Regulation (Traction Control)
ASCII American Standard Code for Information Exchange
CAN Controller Area Network
Con-Ag Construction-Agriculture Industry
CRC Cyclical Redundancy Check
DA Destination Address
DLC Data Length Code
DP Data Page
ECU Electronic Control Unit
EOF End of Frame
GE Group Extension
ID Identifier
IDE Identifier Extension Bit
LLC Logical Link Control
LSB Least Significant Bit or Least Significant Byte (Context)
MAC Medium Access Control
MID Message Identifier
MSB Most Significant Bit or Most Significant Byte (Depends on Context)
NA Not Allowed / Not Available / Not Applicable (Depends on Context)
NACK Negative Acknowledgement
OSI Open System Interconnect
P Priority
PDU Protocol Data Unit
PF Protocol Data Unit Format
PG Parameter Group
PGN Parameter Group Number
PID Parameter Identifier
PS Protocol Data Unit Specific
PS_GE Protocol Data Unit Specific - Group Extension
PS_DA Protocol Data Unit Specific - Destination Address
PTO Power Take Off
R Reserved
RTR Remote Transmission Request
SA Source Address
SID Subsystem Identifier
SLOT Scaling, Limits, Offset and Transfer Function
SOF Start of Frame
SPN Suspect Parameter Number
SRR Substitute Remote Request
un Undefined

References to the OSI Model

The Open System Interconnect (OSI) model was developed by the International Organization for Standardization (ISO) in 1984 as a model of a computer communications architecture. There are 7 layers to the Open System Interconnect Model as depicted below:

OSI Model

Figure CAN-1: OSI 7 Layer Network Model


SAE J1939 is structured into several parts based on this model. The functionality of each layer is:

  1. Physical: Concerns the transmission of a structured bit stream over physical media. This layer deals with the mechanical, electrical, functional, and procedural characteritics to access the physical media.

  2. Data Link: Provides the reliable transfer of information across the physical layer; sends blocks of data (frames) with the necessary synchronization, error control, sequence control and flow control.

  3. Network: Provides the layers above the network layer with independence from the details of the data transmission and switching technologies used to connect systems. The network layer is responsible for establishing, maintaining and terminating connections.

  4. Transport: Provides reliable, transparent tranfer of data between end points. The transport layer provides end-to-end error recovery and flow control. The Transport layer also provides segmentation and reassembly of very large messages.

  5. Session: provides the control structure for communication between applications. The session layer establishes, manages and terminates connections between cooperating applications.

  6. Presentation: provides independence to the application from differences in data representation.

  7. Application: provides access to the OSI environment for users and also provides distributed information services.

The purpose of the OSI model is to provide a standard communication and protocol for networked systems. Any networks developed from this standard need not be explicitly partitioned into each of the 7 layers, as long as the fundamental functionality is supported. Only the OSI layers which are required for anticipated SAE J1939 uses are implemented.

SAE J1939 Tutorial

J1939 is a high speed communications network designed to support real-time closed loop control functions between ECUs which may be physically distributed throughout the vehicle. J1939 uses the CAN protocol which permits any ECU to transmit a message on the network when the bus is idle. Every message includes an identifier which defines the message priority, who sent it, and what data is contained within it. Data Collisions are avoided due to the arbitration process that occurs while the identifier is being transmitted. This permits high priority messages to get through the CAN Bus with low delay times because there is equal access on the network for any ECU, but when multiple ECUs are simultaneously attempting to transmit, the highest priority message prevails.

Message Format and Usage

J1939 provides a complete network definition using the 29 bit identifier of the CAN Extended Frame protocol. The 11 bit identifier can coexist with the 29 bit identifier without interference. The following diagram illustrates the division of the 29 bit CAN identifier:

CAN S
O
F
Identifier - 11 bits S
R
R
I
D
E
Identifier Extension - 18 bits R
T
R
J1939 S
O
F
Priority R D
P
PDU MSB-6
(PF)
S
R
R
I
D
E
PDU
LSB-2
(PF)
Destination
Address
(PS)
Source
Address
R
T
R
BIT 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

Figure CAN-2: CAN Message Identifier


    Field Descriptions:

  • SOF [1]: Start of Frame bit

  • Priority [2-4]: Priority '000' is highest priority. '001' has higher priority than '100'. '111' is lowest priority.

  • Reserved [5]: Reserved bit should be set to 0.

  • DP [6]: Data Page

    • 0: Contains All Messages Currently Defined (Use this)

    • 1: Future Expansion

  • PDU [7-12]: Contains 6 Most Significant Bits of Protocol Data Unit.

  • SRR [13]: Substitute Remote Request (normally 0).

  • IDE [14]: Identifier Extension Bit (Set to 1 for 29 Bits)

  • PDU [15-16]: Contains 2 Least Significant Bits of Protocol Data Unit.

  • Destination Address [17-24]: 8 bit Address designated for recipient of message.

    • 0 → 239: Destination Address of recipient:

    • 240 → 255: Group Extension - Allows messages which can be broadcast to all ECUs on the network.

    Bits 17-24 of the identifier are PDU Specific (PS), meaning that they are dependent on the value of PF (Bits 7-12, 15, & 16). If the PF value is between 0 and 239 which is PDU1, these 8 bits contain a specific destination address.

    If the PF field (Bits 7-12, 15 & 16) is between 240 and 255, the value in the PS Field (Bits 17-24) now contains a Group Extension. The Group Extension (GE) provides a larger set of values to identify messages which can be broadcast to all ECUs on the network.

    Most messages on SAE J1939 are intended to be broadcast using the PDU2 format. Data transmitted on the network using PDU2 format cannot be directed to a specific destination. When a message must be directed to a particular ECU, it must have been assigned a Program Group Number using the PDU1 protocol format range of numbers so a specific destination address can be included within the identifier of the message.

    Collectively, the Reserved Bit, Data Page, PF, and PS values define the Parameter Group being transmitted. These parameter groups have definitions which inlcude the parameter assignments within the 8 byte data field of each message as well as the tranmission repetition rate and priority. The term "Parameter Group" is used because they are groups of specific paramters. Parameter Groups are identified by a Parameter Group Number (PGN), which uniquely identifies each Parameter Group. The Parameter Group Number structure allows for a total of 8672 different Parameter Groups.

  • Source Address [25-32]: Address of the entity transmitting the message.

  • The last 8 bits of the identifier contain the address of the ECU transmitting the message. For a given network, every address must be unique, and 254 different addresses are available, allowing for a maximum of 254 different devices on any single bus. Two different ECUs cannot use the same address at the same time. The Program Group Numbers are independent of the Source Address, thus any ECU can transmit any message.

Addresses and NAME

Each ECU on the network will have at least one name and one address associated with it. There are examples, such as an engine and engine retarder residing in a common ECU, wherein multiple names and multiple addresses may coexist within a single electronics unit. The address of an ECU defines a specific communications source or destination for messages, the name includes identification of the primary function performed at that address and adds an indication of the instance of that functionality in the event that multiple ECUs with the same primary function coexist on the same network. As many as 254 different ECUs of the same function can coexist on the network, each identified by their own address and name.

To uniquely name each ECU, SAE J1939 defines a 64 bit NAME consisting of the fields designated in the diagram below:

Arbitrary
Address
Capable
Industry
Group
Vehicle
System
Instance
Vehicle
System
Reserved Function Function
Instance
ECU
Instance
Manufacturer
Code
Identity
Number
1 Bit 3 Bits 4 Bits 7 Bits 1 Bit 8 Bits 5 Bits 3 Bits 11 Bits 21 Bits

Figure CAN-3: NAME Fields


The Function Instance, ECU Instance, and Identity Number permit multiple ECUs of the same make and model to coexist on the same network but still have unique NAMES for each. NAMEs identify the primary vehicle functions which an ECU performs and uniquely identifies each ECU, even when there are more than one of the same type on the network.

However, with a length of 64 bits, a NAME is inconvenient to use in normal communications. Therefore, once the network is fully initialized, each ECU utilizes an 8 bit address as its source identifier or Handle to provide a way to uniquely access a given ECU on the network.

In general, most ECUs will use their Preferred Addresses on power up. A specific procedure for assigning addresses after powerup is used to resolve any conflicts that may occur. Each ECU must be capable of annonuncing which addresses it intends to use. This the address claim feature. Two options are available:

  1. Upon power up and whenever requested, an ECU must send an Address Claimed message to claim an address. When an ECU sends the Address Claimed message, all ECUs record or compare this newly claimed address to their own table of addresses on the network. Not all ECUs are required to maintain such a table, but all must at least compare the newly claimed address with their own. Should multiple ECUs claim the same address, the one having the lowest NAME value uses this address and the other ECUs must claim a different address or stop transmitting on the network.

  2. An ECU may send a request for an Address Claimed message to determine which addresses are claimed by other ECUs. When an ECU sends a request for an Address Claimed, all requested ECUs then send their Address Claimed messages. This permits transitional ECUs (tools, trailers, diagnostics) or ECUs powering up late to obtain the current address table so that an available address can be found and claimed or to determine which ECUs are currently on the network. This approach permits the option of self-configurable addresses for those ECUs which may need it, but does not make this a requirement for all ECUs. Self-configurable addressing is optional, however, those ECUs which might be expected to encounter address conflicts are recommended to support this capability.

When an address conflict has been detected, the following four options are available, depending upon the capabilities of the ECU involved:

  1. Self-Configurable ECUs: are capable of dynamically computing and claiming an unused address. Most service tools and bridges will have this capability.

  2. Command-Configurable ECUs: A network interconnection ECU, such as a bridge, or a service tool may command another ECU to use a given address. The ECU having the unclaimable address would then issue an Address Claimed message to acknowledge acceptance of this new commanded address. The ECU may be commanded to accept a new address even though it has already claimed a valid address.

  3. Service Configurable ECUs: are ECUs which are modifiable by service personnel, usually by means of dip switches or a service tool. When Commanded Address messsages are used, this option differs from the Command Configurable option in that a service tool is required and will often use proprietary techniques.

  4. Non-Configurable ECUs: are ECUs that are neither self-configurable nor reprogrammable. They would have to cease transmitting if they failed to claim a valid address.

Communication Methods

Three primary communication methods exist with SAE J1939 and appropriate use of each type allows effective use of the available Paramter Group Numbers. The 3 communication methods are:

  1. Destination Specific Communications: Using PDU1 (PF Values 0-239).
    • Includes the use of the global destination address: 255

  2. Broadcast Communications: are achieved using PDU2 (PF Values 240-255).

  3. Proprietary Communications: can be performed with using either the PDU1 or PDU2 format.

Each of the communication methods has an appropriate use. Destination specific Parameter Group Numbers are needed where the message must be directed to one or another specific destination and not to both. SAE J1939 currently defines a torque control message which may be sent to an engine or retarder. In the case of more than one engine, this message must be sent only to the desired engine and a destination specific Parameter Group Number is needed and has been assigned.

Broadcast communications apply in several situations, including:

  • Messages sent from a single source or multiple sources to a single destination.

  • Messages sent from a single source or multiple sources to multiple destinations.

  • Broadcast communications cannot be used where a message must be sent to one or another destination and not both.

The third communications method in SAE J1939, proprietary communications, is provided by the use of two proprietary Parameter Group Numbers. A Parameter Group Number has been assigned for broadcast proprietary communications and a Parameter Group Number has been assigned for destination specific proprietary communications. This allows for 2 functions:

  1. A specific source can send its proprietary message in a PDU2 type format (broadcast).

  2. It allows for situations where a service tool must direct its communication to a specific destination out of a possible group of ECUs. For instance this case arises when an engine uses more than one controller but the service tool must be able to perform calibration/reprogramming while all ECUs are connected to the same network. In this case the proprietary tool needs to be destination specific.

Proprietary communications are useful in two situations:

  1. Where it is unnecessary to have standardized communications.

  2. Where it is important to communicate proprietary information.

Transmitting Messages

In addition to the 29 bit identifier shown in Figure 2, a CAN Data Frame includes a 6 bit control field, an 8 byte data field, and terminates with CRC, ACK, and EOF fields. To send a particular data item, a message must be constructed by properly filling each of these fields. The process first needs to define the Parameter Group Number (PGN) to use. The proper SAE J1939 documents will need to be referenced to properly define the PGN. Next the message update rate will need to be determined followed by the priority setting for that message. Since multiple data items are typically packed together within a message, it will also defien the data field format. Note that, when the ECU does not have data available for a given parameter, it sets those bits to "N/A" so that a receiver knows that the data is not provided.

Parameter Groups which have more than 8 bytes of data must be sent as multipacket messages using the Transport Protocol functions.

Receiving Messages

There are various techniques and electronic ICs available for capturing selected messages off the network. Several general observations can be made however regarding received messages:

  1. If the received message is a destination specific request or command, the ECU must determine if there is an address match between itself and the incoming messages' destination address. If there is an address match, the ECU must process the message and provide some type of acknowledgement.

  2. If a message is broadcast, each ECU must determine if the message is relevant or not.

  3. If a message is a global request, every ECU, even the requestor, must process the global message request and respond if the data is available.

ECU Design

Although every manufacturer will have different performance requirements for the ECU contained within their product, several observations should be made regarding the resources required to support SAE J1939. The current data rate of SAE J1939 is 250 Kbps (400μS/bit). A typical message containing 8 data bytes is 128 bits long (excluding bits used for stuffing) will transmit in approximately 500 μSec. The shortest message is 64 bits long. This means that a new message could conceivably be available every 250 μSec. Even though not every message is relevant, nor is the bus loading likely to be over 50%, the receiving processor must still be able to process multiple back to back messages. This will require some ram space as well as processor time for the memory transfers. The requirement of SAE J1939 is that no messages be lost due to hardware or software limitations.

Network Topology

SAE J1939/01 network defines a system containing one or more segments connected by network interconnecting ECUs. Each SAE J1939 segment consists of a single, linear, shielded twisted pair of wires installed in the vehcile and connected to each ECU. A short stub is permitted to connect the ECU to the bus. This simplifies the routing of the main bus wiring by not requiring the main bus to be in directy proximity to each ECU. The linear bus is necessary with a data rate of 250 Kbps in order to minimize reflections of the electrical signals. The termination resistor at each end of the bus also reduces reflections. To support a tractor pulling one or more trailers, and the frequent removal and reconnection of trailers, a separate SAE J1939 segment, or subnetwork, is used within the tractor and each trailer.

The SAE J1939 network may thus be composed of multiple segments, with a network interconnection ECU, also known as a bridge, between the ECUs. The network segments do not need to be directly compatible with each other, as they may operate at different data rates or even use different physical media. For example, a bridge provides electrical isolation between segments, provides initialization support for the subnetwork connected to it, and can provide message filtering to prevent unnecessary message traffic on the subnetworks. In the event of a bus failure on the wires exposed between the tractor and trailer, the main SAE J1939 subnetwork on the tractor will continue to function.

Preassigned Values

Application specific parameters and Parameter Groups are defined in the SAE J1939/7X documents. Parameter Groups that are used for control and management of the network are defined in SAE J1939/21, SAE J1939/31 and SAE J1939/81. If new values are required that are not already assigned, developers may request new values to be assigned by the SAE Control and Communications Network Subcommittee.

Parameter Group Numbers

Parameter Group Numbers are assigned specifically to use either PDU1 or PDU2 format. Once assigned to a format the other PDU type is no longer available for that Parameter Group. The assignment of a Parameter Group Number should be done keeping in mind the following characteristics:

  • Priority

  • Update Rate

  • Importance

  • Length of Data

Much of the communications between ECUs constructed by a single manufacturer do not require standardization. The information that is communicated between these ECUs is generally not useful to other ECUs on the network. In this situation the proprietary Parameter Groups can be used. The use of standardization communications is preferred and should be used whenever practical, however, the proprietary option is offered as a means of solving unique problems and situatons.

If proprietary information is being communicated, or the information communicated is not of general interest, the proprietary method should be used. If the information is of general interest and does not require direction of the message to a particular ECU, a Parameter Group Number utilizing the PDU2 broadcast format should be sought. Finally, if the information is of general interest but requires direction to one or another ECUs then destination specific addressing is needed and a PDU1 format Parameter Group Number should be sought. Proprietary and PDU1 communication methods should be considered carefully and used sparingly.

Data Field Grouping

Minimizing message overhead with CAN based systems requires full use of the data fields of messages. Except in the case of very time critical messages, parameters should be grouped to fill the 8 byte data field. Following this principle conserves Parameter Group Numbers for future assignments and allows for minimum network loading when all data bytes are known by and sent from the same address. Strong justification is needed to allow definition of Parameter Group Numbers that result in sparsely used data fields.

Parameters should be grouped as follows:

  1. By common subsystem (the ECU likely to measure and send the data).

  2. With similar update rates (to minimize unnecessary overhead).

  3. By function (Oil pressure, coolant levels, Fuel consumption).

It should be recognized that, while these are guidelines, in most cases when parameters are grouped together they will end up violating one or more of the above rules. Since all parameters defined in SAE J1939 have a technique for identifying when they are not available, it is not crucial that all of the parameters in one Parameter Group come from the same ECU. If a new parameter is defined and there are spare bytes or bits in an existing Parameter Group, then it can easily be added there. When the update rate is fast, it is desirable to make sure that a Parameter Group is as fully utilized as possible (i.e. uses all 8 data bytes) before defining another Parameter Group and preferably that all parameters are normally coming from one specific ECU.

For the slower update rate it is not as critical that all of the parameters in a Parameter Group come from the same ECU. Even though it is desirable to have parameters come from one ECU, the intention of SAE J1939 is to provide a means of communicating the data and not dictating which ECU is to send what data.

NAME Systems and Functions

A function is a capability of a component or group of components served by one or more ECUs. The Function of each ECU is identified within an 8 bit field of that ECU's NAME. As there may be multiple ECUs which identify themselves with the same Function, the Function Instance Field of NAME is used to distinguish between them. The same Function value (upper 128) may have a different meaning to different Industry Groups or Vehicle Systems, therefore, the Function Identification (upper 128) identification is dependent upon the Industry Group, and the Vehicle System.

A Vehicle System is a subcomponent of a vehicle or an analogous component that includes one or more SAE J1939 network segments and may be connected or disconnected from the total vehicle. A Vehicle System may be made up of one or more Functions, which have ECUs that are connected to an SAE J1939 network segment of that Vehicle System. A typical on-highway Vehicle System is a tractor and trailer. Because of the definition of Vehicle Systems will vary from one industry to another, the System definition is dependent upon the Industry Group.

The above definitions are illustrated in the diagram below:

Arbitrary
Address
Capable
Industry
Group
Vehicle
System
Instance
Vehicle
System
Reserved Function Function
Instance
ECU
Instance
Manufacturer
Code
Identity
Number
1 Bit 3 Bits 4 Bits 7 Bits 1 Bit 8 Bits 5 Bits 3 Bits 11 Bits 21 Bits

Reserved Field:       Available Field:      

Figure CAN-4: User Available NAME Fields


A single ECU on the network may combine multiple Functions, and would then have the option to claim a separate address for each supported function. To permit multiple industries to use SAE J1939, an Industry Group code is used to identify the industry to which the ECU is associated. Code 0 is a special category of Industry Group in that it identifies Preferred Addresses and NAMEs that are common to all industries. Any ECU which may be used in more than one industry application, such as diesel engines, should have NAMEs and Preferred Addresses within this global group. It is the responsibility of those requesting new definitions to consider if this may be the case, and to request the new definition in the correct group. To avoid running out of NAME or address values, it is requested that global values be used only when truly applicable. If an ECU may exist in only one group, such as agricultural equipment, it would be preferrable to add the definition to the applicable group rather than use a global value.

Manufacturer Code

As defined in SAE J1939/81, the NAME convention includes a Manufacturer Code, permitting a unique Identity Number to be part of a full name. This Identity Number is assigned by the manufacturer and can be an individual ECU's serial number if desired. To enable the Identity Numbers to be unique to a given manufacturer, all manufacturers using SAE J1939 are assigned a code. A manufacturer is permitted to have multiple codes, such as when there are multiple divisions or product lines. Having a unique Manufacturer Code for each individual product would be discouraged, as this would quickly exhaust the range of available codes. There are 21 bits available in the Identity Number field of NAME, permitting the manufacturer to include a reference to each particular product if desired.

PreferredAddress

The number of addresses within a given system cannot exceed 254 (null and global cannot be claimed by devices). Most ECUs that operate on an SAE J1939 network will have an assigned Preferred Address that the ECU may use. If the ECU's Preferred Address has been claimed or is in use by another ECU on the network, the conflict will be resolved by using the procedure Addresses and Names outlined above. There may be additional constraints or procedures defined in applicable SAE J1939 documents. For instance, on-highway trailer bridges and devices have address claiming constraints that differ from Con-Ag systems. A supplier of a Self-Configurable ECU may provide ANY strategy for selecting an address to claim. However, if an alternative approach is not defined, the device should attempt to claim an address in the range of 128-247, starting at 128. Individual reserved Preferred Address assignments begin at zero and are assigned in a linear fashion as follows:

  • 000 → 127: Reserved for most conventional ECUs in Industry Group 0 - Global

  • 128 → 247: Reserved for Industry Specific assignments.

  • 248 → 253: Reserved for Special ECUs.

  • 254:              Null Address

  • 255:              Global Address

Suspect Parameter Number (SPN)

A Suspect Parameter Number is a 19-bit number used to identify a particular element, component, or parameter associated with an ECU. This capability is especially useful for diagnostics, permitting an ECU which has detected a fault associated with a particular component, such as a sensor, to transmit a fault message identifying the faulty component.

Due to the very large number of Suspect Parameter Numbers which may be assigned, and their assignment being in order of request, it will be very difficult for one interested in finding the Suspect Parameter Number value of a particular component of interest simply by looking through the table. To facilitate the verification that new Suspect Parameter Numbers are not duplications of existing assignments, the SAE committee retains the table as an MS Excel spreadsheet. This permits sorting based upon Suspect Parameter Numbers, name, description, attribute, source name and source paragraph. It is recommended that those developint SAE J1939 applications or wishing to request the assignment of a new Suspect Parameter Number have access to an up-to-date version of the spreadsheet so that they can perform various sorts and searches of the data.

Application Examples

A typical shift sequence consists of a series of commands from the transmission to the engine for controlling engine RPM and torque. Messages from the engine provide status and information which is used to determine when a particular condition has occurred. Other messages may also be sent regularly to disable the engine retarder at the proper time interval, or to coordinate the Acceleration Slip Regulation functions which could affect engine demand during portions of the shift sequence.

Step Parameter Group Message Type Sender Receiver Action/Function
1 ETC1 Information Transmission Engine, ASR Transmission Decision to Shift
2 TSC1 Command Transmission Engine Override Priority Bits for Transmission
3 TSC1 Command Transmission Engine Retarder Disable Mode, Torque=0
4 EEC1 Information Engine Transmission Disengage Clutch
5 TSC1 Command Transmission Engine Requested Speed = X
6 EEC1 Information Engine Transmission Speed = X
7 TSC1 Command Transmission Engine Speed/Torque Limit Mode
8 ETC1 Information Transmission ASR Allow ASR
9 TSC1 Command Transmission Engine Retarder Mode = Enable
10 TSC1 Command Transmission Engine Override Disable
11 ETC1 Information Transmission Engine, ASR Shift Complete
Figure CAN-5: Transmission Shift Message Example

A typical ABS sequence will cause a message to be transmitted which indicates that the engine should reduce torque and the transmission should remain in its existing state. If the ABS condition is 'significant', it may request that the transmisiion also be disengaged. Note, this message must be sent at regular intervals to maintain the condition. Once the event is over, the ABS inactive condition indicates that the transmission and engine may return to 'normal' operation.

Step Parameter Group Message Type Sender Receiver Action/Function
1 EBC1 Command ABS Engine - Transmission ABS Active → Modulate Brakes
2 TSC1 Command ABS Engine Retarder Mode = Disable
3 TC1 Command ABS Transmission Disengage DriveTrain
4 EBC1 Command ABS Engine & Transmission ABS - Complete & Inactive
Figure CAN-6: ABS Brake Modulation Event