Can CH2 Trucks - Saej1939 PDF

NETWORKS IN TRUCKS AND BUSSES CAN SAE J 1939 1/39
KATHO department VHTI Industrial Sciences and Technology

study area Bachelor of Automotive KORTRIJ K - BELGIUM
frans.devolder @ katho.be
13-May-07

SEMINAR CONTROLLER AREA NETWORK IN TRUCKS 31 May 2007
Escola Superior de Tecnologia - Campus do Instituto Politcnico de Setbal - Estefanilha, 2910-761 Setbal PORTUGAL

1 INTRODUCTION...................................................................................................................................... 2
2 MAIN CHARACTERISTICS................................................................................................................. 3
3 OSI NETWORK LAYER MODEL....................................................................................................... 5
4 PHYSICAL LAYER................................................................................................................................... 6
5 DATA LINK LAYER SAEJ1939/21 : MESSAGE FORMAT.............................................. 12
5.1 EXTENDED CAN FRAME SAE J1939 ......................................................................................... 13
5.2 29 BITS IDENTIFIER IN DETAIL ........................................................................................................ 14
6 APPLICATION LAYER SAEJ1939/71......................................................................................... 20
6.1 DESCRIPTION OF PARAMETER GROUP NUMBERS (PGN)..................................................................... 20
6.2 DESCRIPTION OF SUSPECT PARAMETER NUMBER (SPN) .................................................................... 21
7 MESSAGE TYPES................................................................................................................................... 23
7.1 MESSAGE TYPE: INFORMATION SHARING BROADCAST OR RESPONSES.......................................... 24
7.2 MESSAGE TYPE: REQUEST ..................................................................................................................... 25
7.3 MESSAGE TYPE: COMMAND.................................................................................................................... 26
7.4 MESSAGE TYPE: ACKNOWLEDGMENT (ACK)......................................................................................... 27
7.5 MESSAGE TYPE: PROPRIETARY MESSAGES (GROUP FUNCTION) ............................................... 28
7.6 MESSAGE TYPE: MULTI-PACKET TRANSPORT FUNCTIONS - LONG MESSAGES (GROUP FUNCTION) . 29
7.6.1 Multipacket Broadcast (Broadcast Transmission Protocol) .................................... 30
7.6.2 Multipacket Destination Specific. ........................................................................................ 31
8 APPLICATION LAYER SAE J1939/73 : DIAGNOSTICS................................................... 33
8.1 DIAGNOSTIC MESSAGES (DM) .............................................................................................................. 33
8.2 DM 1(DIAGNOSTIC MESSAGE 1) ACTIVE DIAGNOSTIC TROUBLE CODES ........................................ 34
8.3 DATA FIELDS OF A DM1 MESSAGE ........................................................................................... 35
8.4 FMI FAILURE MODE INDICATION............................................................................................... 36
9 NETWORK MANAGEMENT ............................................................................................................... 37
9.1 NETWORK ADRESSES AND NAMES......................................................................................................... 37
9.2 SAE J1939 INDUSTRY GROUPS PREFERRED NETWORK ADDRESSES ......................................... 38
9.3 PROCEDURE ADDRESS CLAIMING..................................................................................................... 39


13-May-07


1 INTRODUCTION

CAN-SAEJ 1939 networks DAF Trucks

In the early 90ties, the SAE (Society of Automotive Engineers) Truck and Bus Control and Communications Sub-
committee started the development of a CAN-based application profile for in-vehicle communication in trucks. In
1998 the SAE published the J 1939 set of specifications supporting SAE class A, B, and C communication
functions. A J 1939 network connects electronic control units (ECU) within a truck and trailer system. The J 1939
specification - with its engine, transmission, and brake message definitions - is dedicated to diesel engine
applications. It is supposed to replace J1587/J1708 networks.

Other industries adopted the general J 1939 communication functions, in particular the J 1939/21 and J 1939/31
protocol definitions - they are required for any J 1939-compatible system. They added other physical layers and
they defined other application parameters. The ISO standardized the J 1939-based truck and trailer
communication (ISO 11992) and the J 1939-based communication for agriculture and forestry vehicles (ISO
11783). The NMEA specified the J 1939-based communication for navigation systems in marine applications
(NMEA 2000). One reason for the incorporation of J 1939 specifications into others is the fact that it makes sense
to re-invent the basic communication services. An industry-specific document defines the particular combination
of layers for that industry.


13-May-07


DATA LINK LAYER - APPLICATION LAYER
29-bit identifier:
Priority
Identification data (PGN), ( +some cases destination address)
Source address
8 data bytes (SPN)
Sharing information (vehicle data)
Commands
Configuration
Diagnostics
PHYSICAL LAYER
250 kbps
Twisted pair
End line resistors 2x120 ohm

2 MAIN CHARACTERISTICS

TRUCKS, BUSSES, OFF-ROAD- EN AGRICULTURE VEHICLES

ID 11 BITS ID18 BITS DATA 8 BYTES

13-May-07


Communication types
Peer-to-peer
Broadcast

Message types
Information sharing
Command
Request
Acknowledgment
Diagnostics (MIL, DTC, FMI)
Proprietary

Transport protocol.
Multi-packet transmission


13-May-07


3 OSI NETWORK LAYER MODEL

1. Physical - Concerns the transmission of structured bit stream over physical media; deals with the
mechanical, electrical, functional, and procedural characteristics 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 upper layers with independence from the data transmission and switching
technologies used to connect systems; responsible for establishing, maintaining, and terminating
connections;
4. Transport - Provides reliable, transparent transfer of data between end points; provides end-to-end
error recovery and flow control; provides segmentation and reassembly of very large messages;
5. Session - Provides the control structure for communication between applications; establishes,
manages, and terminates connections (sessions) between cooperating applications;
6. Presentation - Provide independence to the application process from differences in data representation.
7. Application - Provides access to the OSI environment for users and also provides distributed
information services.

J 1939/11 - 15
J 1939/21
J 1939/31
J 1939/21
not defined
not defined
J 1939/71
J 1939/73
DATA LINK
NETWORK
TRANSPORT
SESSION
PRESENTATION
APPLICATION

PHYSICAL
29 bits IDENTIFIER - Based on CAN ISO11898
ISO 11898 HSCAN - 250 kbps - 2x120 ohm
/71: vehicle data-commands-configuration
/73: diagnostics
BUS

13-May-07


4 PHYSICAL LAYER

SAE J 1939/11 - /15. describes the physical layer:
Bit rate 250 kbps
Shielded or unshielded twisted pair cable
End of line resistors
Bus levels (bit encoding/decoding)
Synchronisation
Bus characteristics (cables and connectors)
Number of module
Bus length

Physical layer
Data link layer

13-May-07


BUSLEVELS TERMINATION RESISTORS

120 ohm 120 ohm


13-May-07


CANL
2,5 - 1,5 V
CANH
2,5 - 3,5 V

13-May-07



13-May-07


Network wiring topology

R
L
: end line resistors
Bus length L: max 40 m
Cable stub S: max 1 m
Node distance d: min 0,1 , max 40 m
Cable stub for diagnostic connector: max 0,66 m on the vehicle +0,33 m for the off board tool

The wiring topology of this network should be as close as possible to a linear structure in order to
avoid cable reflections. In practice, it may be necessary to connect short cable stubs to a main
backbone cable. To minimize standing waves, nodes should not be equally spaced on the network
and cable stub lengths, dimension S, should not all be the same length.

ECU
1
ECU
2
ECU
3
ECU
4
R
L
R
L

d
S
L

13-May-07


Busfailure

Open and Short Failures-
In principle, failures are detectable if there is a significant message destruction rate, as interpreted by
the electronic control units. Some external events that may cause failures are shown
a. Case 1: CAN-H is Interrupted-Data communication between nodes on opposite sides of an
interruption is not possible. Data communication between nodes on the same side of an interruption
may be possible, but with reduced signal-to-noise ratio.
b. Case 2: CAN-L is Interrupted-Data communication between nodes on opposite sides of an
interruption is not possible. Data communication between nodes on the same side of an interruption
may be possible, but with reduced signal-to-noise ratio.
c. Case 3: CAN-H is Shorted to VBat-Data communication is not possible if VBat is greater than the
maximum allowed common mode bus voltage.
d. Case 4: CAN-L is Shorted to GND-Data communication is possible, because the bus voltages are
within the allowed common mode voltage range. Signal-to-noise ratio is reduced and radiation is
increased. The electromagnetic immunity is decreased.
e. Case 5: CAN-H is Shorted to GND-Data communication is not possible.
f. Case 6: CAN-L is Shorted to VBat-Data communication is not possible.
g. Case 7: CAN-H is Shorted to CAN-L--Data communication is not possible.
h. Case 8: Both Bus Lines are Interrupted at the Same Location-Data communication between nodes
on opposite sides of an interruption is not possible. Data communication between nodes on the same
side of an interruption may be possible, but with reduced signal-to-noise ratio.
i. Case 9: Loss of Termination Resistor- Data communication via the bus may be possible, but with
reduced signal-to-noise ratio.
J ; Case 10: Topology Parameter Violation (i.e. , Bus Length, Cable Stub Length, Node Distribution)
Data communication via the bus may be possible, but with reduced signal-to-noise ratio.


13-May-07


5 DATA LINK LAYER SAEJ1939/21 : MESSAGE FORMAT

The data link layer provides for the reliable transfer of data across the physical link. This consists of
sending the CAN Data Frame with the necessary synchronization, sequence control, error
control, and flow control. The flow control is accomplished by a consistent message/frame
format.

The data link layer services are implemented in the Logical Link Control (LLC) and Medium Access
Control (MAC) sub-layers of a CAN controller.

The LLC provides acceptance filtering, overload notification and recovery management.

The MAC is responsible for data encapsulation (de-capsulation), frame coding (stuffing/de-stuffing),
medium access management, error detection, error signalling, acknowledgement, and serialization
(de-serialization).

Physical layer
Data link layer

13-May-07


5.1 EXTENDED CAN FRAME SAE J1939

Message format conforms to the CAN requirements. The CAN specification referenced throughout
this document is CAN Specification 2.0 Part B, September 1991. It should be noted that when there
are differences between the CAN specification and SAE J 1939, then SAE J 1939 is the guiding
document.
The CAN document specifies, in an information routing related discussion, that node addresses are
not used. While this is true for some applications of CAN, it is not true for SAE J 1939. The definition
of the SAE J 1939 network requires that node addressing be used to prevent multiple nodes
from using the same CAN Identifier field (see SAE J1939). Many additional requirements exist in
SAE J 1939 that are not specified by CAN.

CAN 2.0B contains specification of two message formats, standard frame and extended frame. CAN
2.0B compatibility implies that messages of both formats can potentially be present on a single
network by using certain bit coding that allow for the recognition of the different formats. To this point,
SAE J 1939 also has accommodations for both CAN data frame formats. But SAE J 1939 only defines
a full strategy for standardized communications using the extended frame format. AII standard frame
format messages are for proprietary use following the rules defined in this document.
Therefore, SAE J 1939 devices MUST use the extended frame format. Standard frame format
messages can reside on the network, but only as described in this document.

NOTE
Standard frame devices do not respond to network management messages and are not able to
support the strategy for standardized communications.
The CAN data frame is parsed into different bit fields. The number and parsing of the bits in the
arbitration and control fields differ between the CAN standard and extended frame messages. CAN
standard frame messages, shown in "A," contains 11 identifier bits in the arbitration field and CAN
extended frame messages, shown in "B," contain 29 identifier bits in the arbitration field. SAE J 1939
has further defined the identifier bits in the arbitration field of the CAN Data Frame formats.

11 BITS ID 18 BITS ID DLC DATA CRC EOF
SOF SRR IDE RTR R1 R0 ACK
3 1 1 6 2 8 8
=SAE J 1939
PGN
SOURCE address
29 bits IDENTIFIER
destination

13-May-07


5.2 29 BITS IDENTIFIER IN DETAIL

J 1939 messages are sent using the CAN Extended Frame. A J 1939 message consists of the following
components:

Priority (P)
These three bits are used to optimize message latency for transmission onto the bus only.
They should be globally masked off by the receiver (ignored).
The priority of any message can be set from highest, 0 (000
2
), to lowest, 7 (111
2
).
The default for all control oriented messages is 3 (011
2
).
The default for all other informational, proprietary, request, and ACK messages is 6 (110
2
).
This permits the priority to be raised or lowered in the future as new PGNs are assigned and bus traffic changes.
A recommended priority is assigned to each PGN when it is added to the application layer document.
However, the priority field should be reprogrammable to allow for network tuning by the OEM should the need
arise.

Reserved Bit (R)
This bit is currently reserved for future use by the SAE. This reserved bit should not be confused with the CAN
reserved bits. AII messages should set the SAE reserved bit to ZERO on transmit. Future definitions might
possibly be expanding the PDU Format field, defining new PDU formats, expanding the priority field, or
increasing the address space.

Data Page
This 1-bit field defines on which data page (0 or 1) the message is defined in the J 1939 specification.
Page 0 contains the messages that are presently defined, while Page 1 is for future expansion.

1 11 2 18 1 1 1 4 0 64 16 2 7
11 BITS IDENTIFIER 18 BITS IDENTIFIER
S
O
F
D
P
R
I
D
E
S
R
R
R
T
R
PDU SPECIFIC (PS)
Destination address
(DA),
Group extension(GE)
SOURCE
ADDRESS
(PF)
cont
PDU FORMAT
(PF)
priority
3 2 1 1 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
8 bits 8 bits 8 bits
PARAMETER GROUP NUMBER

13-May-07


29 bits IDENTIFIER in detail

Protocol Data Unit (PDU) Format (PF)

The PDU Format is an 8-bit field that determines the PDU format and is one of the fields used to determine the
Parameter Group Number assigned to the data field.
Parameter Group Numbers are used to identify or label commands, data, some requests, acknowledgments, and
negative-acknowledgments.
Parameter Group Numbers identify or label information that may require one or more CAN Data Frames to
communicate the information. If there is more information than fits in 8 data bytes, then a multi-packet message
needs to be sent . If there are 8 or less data bytes, then a single CAN data Frame is used. A Parameter Group
Number can represent one or more parameters, where a parameter is a piece of data such as engine rpm. Even
though a Parameter Group Number label can be used for one parameter, it is recommended that multiple
parameters be grouped so that all 8 bytes of the data field are used.
The definition of two proprietary Parameter Group Numbers has been established allowing both PDU1
and PDU2 formats to be used. The interpretation of the proprietary information varies by manufacturer. For
example even though two different engines may use the same source address, manufacturer "A's" proprietary
communications is more likely to be different from manufacturer "B's."

This 8-bit PDU Format field determines the format of the message and is one of the fields that determine the
Parameter Group Number of the message (see the Parameter Group Number section).

If the value is between 0 and 239, the message is a PDU 1 Format message. These messages are sent to
specific addresses.

If the value is between 240 and 255, the message is a PDU 2 Format message. These messages are not sent to
a specific address (CA), but are instead broadcast to the entire network.

PDU Format (PF) PDU Specific
PDU1 0-239 Destination address DA
PDU2 240-255 Group extension GE

1 11 2 18 1 1 1 4 0 64 16 2 7
11 BITS IDENTIFIER 18 BITS
S
O
F
D
P
R
I
D
E
S
R
R
R
T
R
PDU SPECIFIC (PS)
Destination address
(DA),
Group extension GE)
SOURCE
ADDRESS
(PF)
cont
PDU FORMAT
(PF)
priority
3 2 1 1 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

13-May-07



Protocol Data Unit (PDU) Specific (PS)
This is an 8-bit field and its definition depends on the PDU format. Depending on the PDU format it can be a
Destination Address or a Group Extension.
If the value of the PDU Format field is below 240, then the PDU specific field is a destination address. If the value
of the PF field is 240 to 255, then the PDU specific field contains a Group Extension value.

Destination Address (DA)
This field defines the specific address to which the message is being sent. Note that any other device should
ignore this message.
The global destination address (255) requires all devices to listen and respond accordingly as message
recipients.

Group Extension (GE)
The Group Extension field, in conjunction with the four least significant bits of the PDU Format field (note that
when the four most significant bits of the PDU Format field are set, it indicates that the PS field is a Group
Extension), provides for 4096 Parameter Groups per data page. These 4096 Parameter Groups are only
available using the PDU2 format. In addition, 240 Parameter Groups are provided in each data page for use only
in the PDU1 format. In total, 8672 Parameter Groups are available to be defined using the two data pages
currently available.
The total number of Parameter Groups available can be calculated as follows:
(240 +(16 x 256)) x 2 =8672

Source Address (SA)
The Source Address field is 8 bits long. There shall only be one device on the network with a given source
address. Therefore, the source address field assures that the CAN identifier is unique, as required by CAN.
Address management and allocation is detailed in SAE J 1939-81. Procedures are defined in SAE J 1939-81 to
prevent duplication of source addresses. Reference SAE J 1939 Appendix B, Tables B2 through B9, for source
address assignments.

1 11 2 18 1 1 1 4 0 64 16 2 7
11 BITS IDENTIFIER 18 BITS
S
O
F
D
P
R
I
D
E

S
R
R
R
T
R
PDU SPECIFIC (PS)
Destination address
(DA),
Group extension GE)

SOURCE
ADDRESS
(PF)
cont
PDU FORMAT
(PF)
priority

3 2 1 1 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

13-May-07



Data Field (from 0 to 8 Bytes)

When 8 bytes or less of data are required for expressing a given Parameter Group, then all 8 data bytes of the
CAN data frame can be used. It is generally recommended that 8 data bytes be allocated or reserved for all
Parameter Group Number assignments which are likely to expand in the future. This provides a means to easily
add parameters and not be incompatible with previous revisions that only defined part of the data field. Once the
number of data bytes associated with a Parameter Group Number is specified, the number of data bytes cannot
be changed (cannot become multi-packet either unless originally defined as multi-packet). The CAN Data Length
Code (DLC) is set to the defined Parameter Group "Data Length" value when it is 8 bytes or less; otherwise
when the PG Data Length is 9 or greater, the CAN DLC is set to 8.
For example the REQUEST PGN, 59904, has the PG Data Length as 3 so the CAN DLC is set to 3. It is
important to note that an individual group function Parameter Group (see Section 5.4.5) must use the same
length data field because the CAN identifier will be identical while the CAN data field will be used to convey the
specific group sub functions, therefore requiring many different interpretations based on the CAN data field.

Data from 9 up to 1785 Bytes
When 9 up to 1785 data bytes are needed to express a given Parameter Group, the communication of this data
is done in multiple CAN Data Frames. Thus, the term multi-packet is used to describe this type of Parameter
Group Number. A Parameter Group defined as multi-packet capable, having fewer than 9 data bytes to transfer
in a specific instance, shall be sent in a single CAN Data Frame with the DLC set to 8. When a particular
Parameter Group has 9 or more data bytes to transfer, the "Transport Protocol Function" is used. The Transport
Protocol Function's Connection Management capability is used to set up and close out the communication of the
multi-packet Parameter Groups. The Transport Protocol Data Transfer capability is used to communicate the
data itself in a series of CAN Data Frames (packets) containing the packetized data. Additionally, the Transport
Protocol Function provides flow control and handshaking capabilities for destination specific transfers.

AII CAN Data Frames associated with a particular multi-packet response are required to have a DLC of 8. AII
unused data bytes are set to "not available" (see SAE J 1939-71). The number of bytes per packet is fixed;
however, SAE J 1939 defines multi-packet messages that have a variable and/or a fixed number of packets. The
Parameter Group Number for active diagnostic codes is an example of a multi-packet message that has a
"variable" number of packets. Parameter Groups that are defined as multi-packet only use the transport protocol
when the number of data bytes to send exceeds eight.


13-May-07


Example 1: PDU >240

IDENTIFIER 18 FE BF 0B
PGN FE BF

F E
1 1 1 1 1 1 1 0
bin
= 254
dec
>240

IDENTIFIER 1 8 F E B F 0 B

PGN 0 0 F E B F

0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 0 1 0 1 1 1 1 1 1
PRIOR R DP PDU F (PF) (PF) PDU SPECIFIC SOURCE ADDRESS

PGN

11 BIT 19 BIT
000 1 1 0 0 0 1 1 1 1 1 1 1 0 1 0 1 1 1 1 1 1 0 0 0 0 1 0 1 1
1 8 F E B F 0 B

13-May-07


Example 2: PDU <240

IDENTIFIER 18 D5 00 1B
PGN D5 00

D 5
1 1 0 1 0 1 0 1
bin
= 213
dec
< 240

INDENTIFIER 1 8 D 5 0 0 1 B

PGN : 0 0 D 5 0 0

0 0 0 0 0 0 0 0 1 1 0 1 0 1 0 1 0 0 0 0 0 0 0 0
PRIOR R DP PDU F (PF) (PF) PDU SPECIFIC SOURCE ADDRESS

PGN

11 BIT 19 BIT
000 1 1 0 0 0 1 1 0 1 0 1 0 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
1 8 D 5 0 0 F F

13-May-07


6 APPLICATION LAYER SAEJ1939/71

6.1 DESCRIPTION OF PARAMETER GROUP NUMBERS (PGN)

Example: data fields for PGN 61445 ETC2

1 2 3 4 5 6 7 8

Transmission selected gear SPN 524
Transmission actual gear ratio SPN 526
Transmission current gear SPN 523
Transmission requested range SPN 162
Transmission current range SPN 163

13-May-07


6.2 DESCRIPTION OF SUSPECT PARAMETER NUMBER (SPN)

SPN905 Relative Speed Front Axle Left Wheel

Data Length: 1 byte
Resolution: 1/16 km/h /bit
Offset: -7,8125
Data Range: -7,8125 to 7,8125 km/h
Type: Measured
SPN: 905
PGN: 65215

SPN525 - Requested Gear

Data Length: 1 byte
Resolution: 1 gear value/bit
Offset: -125
Data Range: -125 to 125
Type: Status
SPN: 525
PGN: 256


13-May-07


RESOLUTION OFFSET DATA RANGE

Physical value = offset + decimal bit value * resolution

0 to 250 decimal

0 to 15,625 km/h

data range: -7,8125 to 7,8125 km/h

x 1 km/h /bit (=resolution)
16

- 7,8125(=offset)
km/h physical value
Bit value
(decimaal)
0 250
7,8125
- 7,8125
offset

13-May-07


7 MESSAGE TYPES

The SAEJ 1939/21 data link layer defines special message types:

Commands,
Requests,
Broadcasts/Responses,
Acknowledgment, and

And, so called Group Functions
Proprietary messages
Multi-packet messages (transport protocol)


13-May-07


7.1 MESSAGE TYPE: INFORMATION SHARING BROADCAST OR RESPONSES

Example

Example: Message captured with Vector CANalyzer

Information Sharing
Most nodes will have associated with them a set of data which it broadcasts on the network. For
example, a generator may transmit data on it loading, fuel consumption, AC amperage and voltage,
coolant temperature, and so on. To accomplish this, messages will be defined and PGNs assigned to
these messages. All information sharing will be accomplished through these pre-formatted messages.
Information sharing messages are generally set at priority 6, unless the committee agrees that
the data is particularly time-sensitive (such as data used in mechanical controls). Since each
CAN packet can contain eight bytes of data, most messages will include multiple data items.
Even if the node does not support every item in the packet, the entire packet is sent. Certain values
are used to indicate that a particular datum is not supported or is not available at the moment.

Each node may have several messages associated with it. It is also possible that two nodes may
"share" a message each may transmit different data items from the same group.
Many data pages may be set to broadcast "on change" rather than on a schedule that is, whenever
certain data items change in value. Some may adjust their broadcast frequency according to whether
the product is "active". These behaviours must be approved and
Documented by the committee when the PGN is defined.


13-May-07


7.2 MESSAGE TYPE: REQUEST

PF =EA
hex
or 234
dec

DA = global (FF) or specific destination address
SA =source address
3 databytes =contain the PGN of the requested information

Example 18 EA FF 27 = Identifier for a request message, send to all, from module 27

18 EA 27 33 =Identifier for a request message, addressed to module 27, from module 33

Information Requests
Most messages are broadcast repeatedly at a set rate, but sometimes a node may need to request a
datum be transmitted immediately. To accomplish this, a node broadcasts a "Request for PGN"
message. All nodes that support that PGN are required to respond to such requests.

A request can be send to all (broadcast), or to a destination specific station.

The Request message for PGN looks like this:
PGN: 59904
PDU-F: 234
PDU-S: Destination Address or 255 (Global)
Data Length: 3
Priority: 6
Broadcast Rate: As needed
Data 1-3: Desired PGN. (LSB First)

If the Destination Address is specific, then the node must respond either with the desired PGN,
or if the node does not support the PGN with a Negative Acknowledgment (see further)

Overview:
Data page: 0
PDU Format: 234
dec
( EA
hex
)
PDU specific: Destination Address: global DA=FF
hex
or specific
Default priority: 6
PGN: 59904 (00EA00
16
)
Datafields: D0,D1,D2 requested PGN.

The response on a RQST can be:
A CAN frame with maximum 8 bytes
A Multi packet data transfer (in case more than 8 data bytes)
A NACK (negative acknowledgement), if the requested module is not able to send the requested
information.

29 BIT IDENTIFIER DLC DATA
Priority PGN SA 3 D0 D1 D2
R DP PF DA requested PGN

13-May-07


7.3 MESSAGE TYPE: COMMAND

Example

Message TSC1 is send form Transmission Controller (address 03) to Engine Controller (00)

See parameter: EngRqedTorque_TorqueLimit.
Parameter provided to the engine or retarder in the torque/speed control message for controlling or limiting the
output torque.

This message type categorizes those Parameter Groups that convey a command to a specific or global
destination from a source. The destination is then supposed to take specific actions based on the reception of this
command message type. Both PDU1 (PS =Destination Address) and PDU2 Format (PS =Group Extension)
messages can be used for commands. Example command type messages may include "Transmission Control,"
"Torque/Speed Control," etc.

Commands are send with a higher priority (3), than for example the message types sharing information ( priority
6).


13-May-07


7.4 MESSAGE TYPE: ACKNOWLEDGMENT (ACK)

GFV : group function value (*)

Example: 18 E8 FF EE

There are two forms of acknowledgment available. The first form is provided for by the CAN protocol. It consists
of an "in-frame" acknowledgment which confirms that a message has been received by at least one node. In
addition messages are further acknowledged by the absence of CAN error frames. Their absence acknowledges
that all other powered and connected devices received the message correctly.
The second form of acknowledgment is the response of a "normal broadcast" or "ACK" or "NACK" to a specific
command or request as provided for by an application layer.
For Group Function PGs the Group Function Value parameter allows a device to identify the specific group
function that is being acknowledged. The Group Function Values are unique to each Group Function PG. It is
desirable that the Group Function Values only use the range 0 to 250.

Overview
Data length: 8 bytes
Data Page: 0
PDU Format: 232
dec
(E8
hex
).
PDU Specific: Destination address =Global (255
dec
)
Default priority: 6
PGN: 59392
dec
(00E800
hex
)
DATA field
D0
Positive Acknowledgment: Control byte =0
Negative Acknowledgment: Control byte =1
Access Denied (PGN supported but security denied access) Control byte =2
Cannot Respond (PGN supported but ECU is busy and cannot respond now. Re-request the data at a
later time.) Control byte =3

D1 Definition is specific to the individual PGN, when applicable. Most often it is located as the first byte in the data
field of the applicable Group Function PG.

D5 to D7 contain requested PGN.

29 BIT IDENTIFIER DLC DATA FIELD
Priority PGN SA 8 D0 D1 D2 D3 D4 D5 D6 D7
R DP PF DA Ctrl GFV FFh FFh FFh PGN
29 BIT IDENTIFIER DLC DATA FIELD
Priority PGN SA 8 D0 D1 D2 D3 D4 D5 D6 D7
R DP PF DA Ctrl GFV FFh FFh FFh PGN
Ctrl byte =0 ACK
Ctrl byte =1 NACK
Ctrl byte =2 access refused for safety reasons
Ctrl byte =3 can not answer
Ctrl byte =0-255 gereserveerd door SAE
PDU Format=E8
hex

232
dec
Destination address:
Always Broadcast
FF
hex

Not used FF
hex
PGN of the requested message

13-May-07


7.5 MESSAGE TYPE: PROPRIETARY MESSAGES (GROUP FUNCTION)

Group functions
This Message Type is used for groups of special functions (e.g. proprietary functions, network management
functions, multi-packet transport functions, etc.). Each group function is recognized by its assigned PGN.

Proprietary Messages

The proprietary group function provides a means to transmit proprietary messages in a way that eliminates CAN
Identifier usage conflicts between different manufacturers. It also provides a means for receiving and
distinguishing proprietary messages for use when desired. Group Functions may need to provide their own
request, ACK, and/or NACK mechanisms if the messages defined in J 1939-21 are not sufficient.
A request using PGN 59904 can be used to find out if a specific Parameter Group of the message type, Group
Function, is supported. If it is supported, then the responding device sends the Acknowledgment PGN with the
control byte equal to zero, for Positive Acknowledgment, or equal to two, Access Denied or equal to three, Cannot
Respond. If it is not supported, the responding device sends the Acknowledgment PGN with the control byte set
to one, for Negative Acknowledgment. The remaining portions of the SAE J 1939 PDU format and Parameter
Group must be filled in appropriately.


13-May-07


7.6 MESSAGE TYPE: MULTI-PACKET TRANSPORT FUNCTIONS - LONG MESSAGES (GROUP
FUNCTION)

Long Messages
Messages requiring more than eight data bytes may be sent using the Multi-Packet message
protocol, which allows messages of up to 1785 bytes. Each message is still identified with a
particular PGN, and the technique is used usually for messages of variable lengths. The method
uses an initial packet to set up the transfer, followed by up to 255 data packets. Each data
packet must be separated by at least 50 ms.

Transport Protocol Functions
Transport protocol functions are described as a part of the data link layer with the recognition that Transport
protocol functionality is subdivided into two major functions:
Message Packetization and Reassembly; and
Connection Management.

They are described in the following sections.
In the following paragraphs the term originator corresponds to the ECU or device that transmits the request-to-
send message. The term responder corresponds to the ECU or device that transmits the clear-to-send message.

Packetization and Reassembly
Messages greater than 8 bytes in length are too large to fit into a single CAN Data Frame. They must therefore
be broken into several smaller packets, and those packets transmitted in separate message frames. At the
destination end, the individual message frames must be received and parsed and the original message
reassembled from the received packets.

Message Packets
The CAN Data Frame includes an 8-byte data field. Because the individual packets which comprise a large
message must be identified individually so that they may be reassembled correctly, the first byte of the data field
is defined as the sequence number of the packet.
Individual message packets are assigned a sequence number of 1 to 255. This yields a maximum message size
of (255 packets * 7 bytes/packet =) 1785 bytes.

Sequence Numbers
Sequence numbers are assigned to packets for transmission on the network during message packetization and
then used on reception of packets to reassemble them back into a message.
Sequence numbers shall be assigned to individual packets beginning with one and continuing sequentially until
the entire message has been packetized and transmitted. The packets shall be sent sequentially in ascending
order starting with packet 1.

Packetization
A large message is defined as one whose data does not fit into the data field of a single CAN message frame
(i.e. messages with a data field greater than 8 bytes).
For the purposes of this protocol, a large message is considered to be a Parameter Group that has associated
with it a string of 9 or more bytes. The first Data Transfer Packet contains the sequence number one and the first
7 bytes of the string. The second 7 bytes are placed into another SAE

J 1939/CAN data frame along with the sequence number 2, the third with sequence number 3, and so on until all
the bytes in the original message have been placed into SAE J 1939/CAN data frames and transmitted.
Each Data Transfer packet (other than the last packet in a transmission sequence) shall include 7 bytes of the
original large message. The final packet includes a data field of 8 bytes: those being the sequence number of the
packet and at least 1 byte of data related to the Parameter Group and then any remaining unused bytes set to
"FF16'"
The time between packets for Multipackets Broadcast messages shall be 50 to 200 ms (reference Section
5.12.3). For multi-packet messages directed to a specific destination, the originator maintains a maximum time
between packets (where CTS allows more than one) of not more than 200 ms. Responders must be aware that
the packets containing the data all have the same identifier.

Reassembly
Data packets are received sequentially. Each data packet of a multipacket message shall be assembied, in order
of sequence number, into a single string of bytes. This string of bytes is passed to the application entity
responsible for the large message.


13-May-07


7.6.1 Multipacket Broadcast (Broadcast Transmission Protocol)

Broadcast Announce Message (BAM)

The TP.CM BAM is used to inform all the nodes of the network that a large message is about to be broadcast. It
defjnes the parameter group and the number of bytes to be sent. After TP.CM_BAM is sent, the Data Transfer
Messages are sent and they contain the packetized broadcast data. TP.CM_BAM is only transmitted by the
originator (sender).

Transport Protocol-Data Transfer Message (TP.DT)
The TP.DT message is used to communicate the data associated with a Parameter Group. The TP.DT message
is an individual packet of a multipacket message transfer.
TP.DT is only transmitted by the originator (sender).

sender receivers
TP.CM_BAM 32, 17, 3, 255 , 65260
TP.DT 1, data 1-7
TP.DT 2, data 8-14
TP.DT 3, data 15-17, 255, 255, 255, 255
TP.CM_BAM :
Byte 0: Control byte: 32
dec
(20
hex
)
Byte 1-2: Total number of bytes to be transmitted: 17
Byte 3: Number of packets: 3
Byte 4: reserved for SAE
Byte 5-7: PGN : 65260
TP.DT :
Byte 0: sequence number: 1
Byte 1-7: data bytes: first 7
TP.DT :
Byte 1-7: data bytes: bytes 8 to 14
TP.DT :
Byte 0: sequence number : 3
Byte 1-7: data bytes: bytes 15 to 17
bytes not in use are filled with value 255.

13-May-07


7.6.2 Multipacket Destination Specific.

Sender 1 receiver
TP.CM_RTS 16, 23, 4, 255, 65259
TP.CM_CTS 17, 2, 1, 255, 255, 65259
TP.DT 2, data 8-14
TP.DT 1, data 1-7
TP.CM_RTS :
Byte 1: controle byte: 16 =RTS
Byte 2-3: Total amount of bytes to send: 23
Byte 4: number of messages: 4
Byte 6-8: PGN : 65259
TP.CM_CTS :
Byte 1: controle byte: 17 =CTS
Byte 2: number of bytes that can be received: 2
Byte 3: next databyte expected: 1
Byte 4-5:voorbehouden voor SAE
Byte 6-8:PGN : 65259
TP.DT :
Byte 2-8:data bytes: first 7 databytes 1-7
TP.CM_CTS 17, 0, 255, 255, 255, 65259
TP.CM_CTS 17, 2, 3, 255, 255, 65259
TP.DT 4, data 22-23
TP.DT 3, data 15-21
TP.EndofMsgACK 19, 23, 4, 255, 65259
TP.CM_CTS :
(0 =receiver wants a break.)
Byte 4-5:reserved for SAE
Byte 6-8:PGN : 65259
TP.CM_CTS :
Byte 3: number of the next databyte: 3
Byte 4-5:reserved voor SAE
Byte 6-8:PGN : 65259

TP.EndofMsgACK:
Byte 1: controle byte: 19
Byte 2-3: Total amount of received databytes: 23
Byte 4: total number of messages: 4
Byte 6-8: PGN : 65259

TP.DT :
Byte 1: sequence number : 2
Byte 2-8:data bytes: next 7 databytes 8-14
TP.DT :
TP.DT :

13-May-07


Connection Mode Request to Send (TP.CM_RTS)

The TP.CM_RTS message informs a node that another node on the network wishes to open a virtual connection
with it. The TP.CM_RTS is a message with the source address field set to that of the originating node, the
destination address field set to that of the intended recipient of a large message, and the remaining fields set
appropriately for the Parameter Group Number being gent.
Byte 5 of this message allows the originator to limit the responder's number of packets specified in the Clear To
Send message. When the responder complies with this limit, it ensures that the originator can always retransmit
packets that the responder may have not received for whatever reason.
It multiple RTSs are received from the same source address tor the same PGN, then the most recent RTS shall
be acted on and the previous RTSs will be abandoned. No abort message shall be sent for the abandoned RTSs
in this specific case.
TP. CM_RTS is only transmitted by the originator.

Connection Mode Clear to Send (TP.CM_CTS)
The TP.CM_CTS message is used to respond to the Request To Send message. It informs the peer node that it
is ready for a certain amount of large message data. The amount of large message data cleared to send shall not
be greater than byte 5 of the originator's TP.CM_RTS message. If multiple CTSs are received after a connection
is al ready established, then the connection shall be aborted. When the originator aborts the connection, it shall
send the Connection Abort message. The responder will not send the next CTS until it has received the last data
packet from the previous CTS or it has timed out. If a CTS is received while a connection is not established, it
shall be ignored.
CTSs not only control the flow but also confirm correct receipt of any data packet prior to that CTS packet's
number. Therefore if information for the previous CTS was corrupted, then a CTS for the corrupted information
shall be sent before continuing on to the next sequential packets to be sent.
Because of this requirement, the originator of a large message transmission may use byte 5 of the TP.CM_RTS
message as a way to ensure the possibility of retransmission of a packet within the last set of packets cleared to
send.
TP.CM_CTS is only transmitted by the responder.

End of Message Acknowledgment (TP.CM_EndOfMsgACK)
The TP.CM_EndOfMsgACK message is passed from the recipient of a large message to its originator indicating
that the entire message was received and reassembled correctly. The responder can keep the connection open
atter the last Data Transfer of the session by not immediately sending the TP.CM_EndOfMsgACK. This allows the
responder to get a packet resent if necessary. If an End of Message Acknowledgment is received by the
originator prior to the final Data Transfer, then the originator ignores it.
One End of Message Acknowledgment is sent to show the originator that the large message transfer has
been received and assem bied correctly.
TP.CM_EndOfMsgACK is only transmitted by the responder.

Connection Abort (TP.Conn_Abort)
The TP.Conn_Abort message is used by either node involved in a virtual connection to close the connection
without completing the transfer of the message or to prevent a connection from being initialized.
Upon receipt of a Connection Mode Request To Send message, a node must determine if there are sufficient
resources available to deal with the message for which this connection is sought. For example if the device must
acquire memory from the system heap, it may not be able to claim enough to accept the entire message; or a
device may simply be too occupied doing other things to expend processor cycles to handle a large message. In
these cases a Connection Abort message may be sent even though the connection has not been established.
This may be done in order to allow the originator to attempt another virtual connection without first having to wait
for a timeout to occur.
When either the originator or responder decides to close out a connection for any reason, prior to completing the
data transfer, including a timeout, it shall send a Connection Abort message with the appropriate Connection
Abort reason.

It is intended that the originator (i.e. the RTS node) should immediately stop transmitting after the reception of the
Connection Abort message by the CAN protocol device. If this is not possible, the process to stop transmitting
data packets shall take no more than 32 data packets and shall not exceed 50 ms. After sending or receiving a
Connection Abort message, all related data packets received should be ignored. TP.Conn_Abort is transmitted by
the originator or the responder.

13-May-07


8 APPLICATION LAYER SAE J1939/73 : DIAGNOSTICS

8.1 DIAGNOSTIC MESSAGES (DM)

13-May-07


8.2 DM 1(DIAGNOSTIC MESSAGE 1) ACTIVE DIAGNOSTIC TROUBLE CODES

Diagnostics
All compliant products will support the "DM1" message, which is a modified form of the SAE
J 1939 version of the same PGN. This message allows the communication of diagnostic information
and general operating status.

The form is as follows:
Active Diagnostic Message ("DM1")
PGN: 65226
PDU-F: 254
PDU-S: 202
Priority: 6. Node may increase priority if appropriate.
Broadcast Rate: 1000 ms, plus at change of status.
Data 1: Operating Status
bit 0-1: Product is "On"
bit 2-3: Product is "Active" (vs. "Standby")
bit 4-5: Yellow Lamp. See diagnostic info for details.
bit 6-7: Red Lamp. See diagnostic info for details.
Data 2: Product Identifier (i.e. Default Source Address for the product)
Data 3: Suspect Parameter Number (Most Sig. Bits)
Data 4: Suspect Parameter Number
Data 5:
bit 5-7: Suspect Parameter Number (Least Sig. Bits)
bit 0-4: Failure Mode Identifier
Data 6:
bit 7 Reserved (Always 1)
bit 0-6 - Occurrence count. (If unavailable, 1111111).

If multiple failures are occurring, the transmitter has a choice of sending this as a multi-packet
message (see next section) or simply sending multiple instances of this message. In the former
case, data bytes 3-6 are chained sequentially, so the message is in this order: Lamp Status,
SPN/FMI/Count, SPN/FMI/Count, . . . SPN/FMI/Count. When a problem is cleared up, the
message should be sent showing the lamps as unlit.
All conditions should be classified as "Yellow" or "Red". A "Yellow" condition would usually refer
to a problem that can be remedied by the user (e.g. Low Battery Level to an Inverter) or does not
require intervention. A "Red" condition would generally require a service technician. These
levels are subjective, of course.

ACTIVE FAILURE
MIL
DTC
BROADCAST DM 1

13-May-07


8.3 DATA FIELDS OF A DM1 MESSAGE

8 7 6 5 4 3 2 1
1
2
3
4
5
6
7
8

MIL STATUS
SPN
RESERVED
SPN
SPN FMI
CM OC

13-May-07


8.4 FMI FAILURE MODE INDICATION

The committee is charged with providing a list of SPNs. The Failure Modes are defined as
follows:
0 Item above normal operating range
1 Item below normal operating range
2 Item erratic, intermittent, or invalid
3 Short circuit high voltage (or complete sensor input failure)
4 Short circuit low voltage (or complete sensor input failure)
5 Current below normal, or Open circuit
6 Current above normal, or Grounded circuit
7 Mechanical system not responding
8 Abnormal frequency, pulse width, or period
9 Abnormal update rate
10 Abnormal rate of change
11 Failure not identifiable
12 Bad intelligent device or component
13 Out of calibration
14 "None of the above" (Use sparingly!)
15-30 Reserved
31 No failure information available (note: use when the SPN is unknown. If SPN is known,
use FMI 11).

13-May-07


9 NETWORK MANAGEMENT

9.1 NETWORK ADRESSES AND NAMES

On a J 1939 network, each device has a unique address. Each message that is sent by a device contains this
source address. There are 255 possible addresses:
0..253 Valid addresses of an ECU
254 Zero
255 Global

Each device type has a preferred address. Before a device may use an address, it must register itself on the bus.
This procedure is called "address claiming." Thereby the device sends an "AddressClaim" parameter group with
the desired source address. This PG contains a 64-bit device name. If an address is already used by another
device, then the device whose device name has the higher priority has received the address.
The device name contains some information about the device and describes its function.
Since the function of a device is contained in the name, the address can be changed at will and the correct device
is always addressed that provides the required functionality.

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.


13-May-07


9.2 SAE J1939 INDUSTRY GROUPS PREFERRED NETWORK ADDRESSES

SAE name for INDUSTRY GROUP 0
Network address
(hex)
Netwerk address
(dec)

Engine 00 00
Transmission 03 03
Shift console 05 05
Brake system controller 0B 11
Retarder engine 0F 15
Retarder driveline 10 16
Exhaust retarder 29 41
Suspension system controller 2F 47
Pneumatic system controller 30 48
Cab controller 31 49
Rear axle steering control 38 56
Exhaust emission controller (i.e. Adblue) 3D 61
Vehicle dynamic stability controller 3E 62

INDUSTRY GROUP 1/ on highway equipment
Tachograph EE 238

Industry Group
To permit multiple industries to use J 1939, an lndustry Group code is used to identify the industry to
which the ECU is associated. Code 0 is a special category of lndustry 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
preferable to add the definition to the applicable group rather than to use a global value.


13-May-07


9.3 PROCEDURE ADDRESS CLAIMING

ADDRESS REQUEST
PGN: 59904
PDU-F: 234
PDU-S: desired networkaddress
Priority: 6
Data Length: 3
Broadcast Rate: As Needed
Source Address: 254 is no address has been claimed.
Data 1: 0
Data 2: 238
Data 3: 0

ADDRESS CLAIMED
PGN: 60928
PDU-F: 238
PDU-S: 255
Priority: 6
Broadcast Rate: On Request Only
Source Address: Source Address.
Data 1-8: " DEVICE NAME". (8 byte identification for a module).

NAMEs identify the primary vehicle function or functions which an ECU performs and uniquely identify each
ECU, even when there is more than one of the same type on the network. But 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. For example, an engine may be assigned address 0, but if a second engine is present, it needs a
separate, unique address (e.g. 1) and instance. ECUs that accept destination specific commands may require
multiple addresses. This permits distinguishing which action is to occur. For example, if the transmission is
commanding a specific torque value from the engine (address 0), this must be differentiated from commanding a
specific torque value from the engine brake retarder)(address 15). As can be seen by this example, a single ECU
on the network may have multiple addresses and each address will have an associated NAME. To facilitate the
initialization process of determining the address (es) for each ECU on the network, commonly used devices have
Preferred Addresses assigned by the committee. Using the Preferred Addresses minimizes the frequency of
multiple devices attempting to claim the same address.

In general, most ECUs will use their Preferred Addresses immediately upon power up. A specific procedure
(defined in J 1939/81 and elaborated on in J 1939/01) for assigning addresses after powerup is used to resolve
any conflicts that may occur. Each ECU must be capable of announcing which address(es) it intends to use.
This is 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 value NAME uses this address and the other(s) must claim a different
address or stop transmitting on the

2) An ECU may send a request for Address Claimed message to determine addresses claimed by other ECUs.
When an ECU sends a request for Address Claimed, all requested ECUs then send their Address Claimed
messages. This permits transitional ECUs (tools, trailers, etc.) 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.

Can CH2 Trucks - Saej1939 PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Can CH2 Trucks - Saej1939 PDF

Uploaded by

Copyright:

Available Formats

NETWORKS IN TRUCKS AND BUSSES CAN SAE J 1939 1/39

KATHO department VHTI Industrial Sciences and Technology

You might also like