CAN CH2 TRUCKS_ SAEJ1939.pdf

8/11/2019 CAN CH2 TRUCKS_ SAEJ1939.pdf

1/39

NETWORKS IN TRUCKS AND BUSSES CAN SAE J1939 1/39

KATHO department VHTI Industrial Sciences and Technologystudy area Bachelor of Automotive KORTRIJK - BELGIUM

frans.devolder @ katho.be13-May-07

SEMINAR CONTROLLER AREA NETWORK IN TRUCKS 31 May 2007Escola 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 EXTENDEDCANFRAMESAEJ1939 ......................................................................................... 135.2 29BITS IDENTIFIERIN 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:PROPRIETARYMESSAGES(GROUP FUNCTION) ............................................... 287.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 DM1(DIAGNOSTIC MESSAGE 1) ACTIVE DIAGNOSTIC TROUBLE CODES ........................................ 34

8.3 DATAFIELDSOFA DM1MESSAGE ........................................................ ................................... 35

8.4 FMIFAILUREMODEINDICATION ................................................... ............................................ 36

9 NETWORK MANAGEMENT ............................................................................................................... 37

9.1 NETWORK ADRESSES AND NAMES................................................... ...................................................... 379.2 SAEJ1939 INDUSTRY GROUPS PREFERRED NETWORK ADDRESSES ......................................... 38

9.3 PROCEDUREADDRESS CLAIMING........................................................ ............................................. 39


2/39





1 INTRODUCTION

CAN-SAEJ1939 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. In1998 the SAE published the J1939 set of specifications supporting SAE class A, B, and C communicationfunctions. A J1939 network connects electronic control units (ECU) within a truck and trailer system. The J1939specification - with its engine, transmission, and brake message definitions - is dedicated to diesel engineapplications. It is supposed to replace J1587/J1708 networks.

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


3/39





DATA LINK LAYER - APPLICATION LAYER29-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


4/39





Communication types Peer-to-peer Broadcast

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

Transport protocol.Multi-packet transmission


5/39





3 OSI NETWORK LAYER MODEL

1. Physical - Concerns the transmission of structured bit stream over physical media; deals with themechanical, 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 ofdata (frames) with the necessary synchronization, error control, sequence control, and flow control;

3. Network - Provides upper layers with independence from the data transmission and switchingtechnologies used to connect systems; responsible for establishing, maintaining, and terminatingconnections;

4. Transport - Provides reliable, transparent transfer of data between end points; provides end-to-enderror 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 distributedinformation services.

J1939/11 - 15

J1939/21

J1939/31

J1939/21

not defined

not defined

J1939/71J1939/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: dia nostics

BUS


6/39





4 PHYSICAL LAYER

SAE J1939/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


7/39





BUSLEVELS TERMINATION RESISTORS

120 ohm 120 ohm


8/39





CANL2,5 - 1,5 V

CANH2,5 - 3,5 V


9/39






10/39





Network wiring topology

RL: end line resistorsBus length L: max 40 mCable stub S: max 1 mNode distance d: min 0,1 , max 40 mCable 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 toavoid 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 networkand cable stub lengths, dimension S, should not all be the same length.

ECU1

ECU2

ECU3

ECU4

RL RL

d

S

L


11/39





Busfailure

Open and Short Failures-In principle, failures are detectable if there is a significant message destruction rate, as interpreted bythe electronic control units. Some external events that may cause failures are showna. Case 1: CAN-H is Interrupted-Data communication between nodes on opposite sides of aninterruption is not possible. Data communication between nodes on the same side of an interruptionmay be possible, but with reduced signal-to-noise ratio.b. Case 2: CAN-L is Interrupted-Data communication between nodes on opposite sides of aninterruption is not possible. Data communication between nodes on the same side of an interruptionmay 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 themaximum allowed common mode bus voltage.

d. Case 4: CAN-L is Shorted to GND-Data communication is possible, because the bus voltages arewithin the allowed common mode voltage range. Signal-to-noise ratio is reduced and radiation isincreased. 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 nodeson opposite sides of an interruption is not possible. Data communication between nodes on the sameside 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 withreduced 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.


12/39





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, errorcontrol, and flow control. The flow controlis accomplished by a consistent message/frameformat.

The data link layer services are implemented in the Logical Link Control (LLC) and Medium AccessControl (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/39





5.1 EXTENDED CAN FRAME SAE J1939

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

SAE J1939 that are not specified by CAN.

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

NOTEStandard 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 thearbitration and control fields differ between the CAN standard and extended frame messages. CANstandard frame messages, shown in "A," contains 11 identifier bits in the arbitration field and CANextended frame messages, shown in "B," contain 29 identifier bits in the arbitration field. SAE J1939has 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 J1939

PGN SOURCE address

29 bits IDENTIFIER

destination


14/39





5.2 29 BITS IDENTIFIER IN DETAIL

J1939 messages are sent using the CAN Extended Frame. A J1939 message consists of the followingcomponents:

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 (0002), to lowest, 7 (1112).The default for all control oriented messages is 3 (0112).The default for all other informational, proprietary, request, and ACK messages is 6 (1102).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 needarise.

Reserved B it (R)This bit is currently reserved for future use by the SAE. This reserved bit should not be confused with the CANreserved bits. AII messages should set the SAE reserved bit to ZERO on transmit. Future definitions mightpossibly be expanding the PDU Format field, defining new PDU formats, expanding the priority field, orincreasing the address space.

Data PageThis 1-bit field defines on which data page (0 or 1) the message is defined in the J1939 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

SOF

DP

R IDE

SRR

RTR

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

SOURCEADDRESS

(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


15/39





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 theParameter Group Number assigned to the data field.Parameter Group Numbers are used to identify or label commands, data, some requests, acknowledgments, andnegative-acknowledgments.Parameter Group Numbers identify or label information that may require one or more CAN Data Frames tocommunicate the information. If there is more information than fits in 8 data bytes, then a multi-packet messageneeds to be sent . If there are 8 or less data bytes, then a single CAN data Frame is used. A Parameter GroupNumber can represent one or more parameters, where a parameter is a piece of data such as engine rpm. Eventhough a Parameter Group Number label can be used for one parameter, it is recommended that multipleparameters 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 PDU1and PDU2 formats to be used. The interpretation of the proprietary information varies by manufacturer. Forexample even though two different engines may use the same source address, manufacturer "A's" proprietarycommunications 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 theParameter 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 tospecific addresses.

If the value is between 240 and 255, the message is a PDU 2 Format message. These messages are not sent toa 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

OF

D

P

R I

DE

S

RR

R

TR

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




16/39






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 valueof 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 shouldignore this message.The global destination address (255) requires all devices to listen and respond accordingly as messagerecipients.

Group Extension (GE)The Group Extension field, in conjunction with the four least significant bits of the PDU Format field (note thatwhen the four most significant bits of the PDU Format field are set, it indicates that the PS field is a GroupExtension), 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 onlyin the PDU1 format. In total, 8672 Parameter Groups are available to be defined using the two data pagescurrently 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 sourceaddress. Therefore, the source address field assures that the CAN identifier is unique, as required by CAN.Address management and allocation is detailed in SAE J1939-81. Procedures are defined in SAE J1939-81 toprevent duplication of source addresses. Reference SAE J1939 Appendix B, Tables B2 through B9, for sourceaddress assignments.

1 11 2 18 1 1 1 4 0 64 16 2 7



11 BITS IDENTIFIER 18 BITS

S

OF

D

P

R I

DE

S

RR

R

TR

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




17/39






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 theCAN data frame can be used. It is generally recommended that 8 data bytes be allocated or reserved for allParameter Group Number assignments which are likely to expand in the future. This provides a means to easilyadd parameters and not be incompatible with previous revisions that only defined part of the data field. Once thenumber 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 LengthCode (DLC) is set to the defined Parameter Group "Data Length" value when it is 8 bytes or less; otherwisewhen 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 isimportant to note that an individual group function Parameter Group (see Section 5.4.5) must use the samelength data field because the CAN identifier will be identical while the CAN data field will be used to convey thespecific group sub functions, therefore requiring many different interpretations based on the CAN data field.

Data from 9 up to 1785 BytesWhen 9 up to 1785 data bytes are needed to express a given Parameter Group, the communication of this datais done in multiple CAN Data Frames. Thus, the term multi-packet is used to describe this type of ParameterGroup Number. A Parameter Group defined as multi-packet capable, having fewer than 9 data bytes to transferin a specific instance, shall be sent in a single CAN Data Frame with the DLC set to 8. When a particularParameter Group has 9 or more data bytes to transfer, the "Transport Protocol Function" is used. The TransportProtocol Function's Connection Management capability is used to set up and close out the communication of themulti-packet Parameter Groups. The Transport Protocol Data Transfer capability is used to communicate thedata itself in a series of CAN Data Frames (packets) containing the packetized data. Additionally, the TransportProtocol 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. AIIunused data bytes are set to "not available" (see SAE J1939-71). The number of bytes per packet is fixed;however, SAE J1939 defines multi-packet messages that have a variable and/or a fixed number of packets. TheParameter 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 protocolwhen the number of data bytes to send exceeds eight.



18/39





Example 1: PDU > 240

IDENTIFIER 18 FE BF 0BPGN FE BF

F E1 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


19/39





Example 2: PDU < 240

IDENTIFIER 18 D5 00 1BPGN D5 00

D 51 1 0 1 0 1 0 1 bin = 213dec < 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


20/39





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


21/39





6.2 DESCRIPTION OF SUSPECT PARAMETER NUMBER (SPN)

SPN905 Relative Speed Front Axle Left Wheel

Data Length: 1 byteResolution: 1/16 km/h /bitOffset: -7,8125Data Range: -7,8125 to 7,8125 km/hType: MeasuredSPN: 905PGN: 65215

SPN525 - Requested Gear

Data Length: 1 byteResolution: 1 gear value/bit

Offset: -125Data Range: -125 to 125Type: StatusSPN: 525PGN: 256


22/39





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 valuedecimaal0 250

7,8125

- 7,8125

offset


23/39





7 MESSAGE TYPES

The SAEJ1939/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)


24/39





7.1 MESSAGE TYPE: INFORMATION SHARING BROADCAST OR RESPONSES

Example

Example: Message captured with Vector CANalyzer

Information SharingMost nodes will have associated with them a set of data which it broadcasts on the network. Forexample, 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 tothese 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 thatthe data is particularly time-sensitive (such as data used in mechanical controls). Since eachCAN 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 valuesare 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, whenevercertain data items change in value. Some may adjust their broadcast frequency according to whetherthe product is "active". These behaviours must be approved andDocumented by the committee when the PGN is defined.


25/39





7.2 MESSAGE TYPE: REQUEST

PF = EAhex or 234decDA = global (FF) or specific destination addressSA = source address3 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 requestmessage, addressed to module 27, from module 33

Information RequestsMost messages are broadcast repeatedly at a set rate, but sometimes a node may need to request adatum 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: 234PDU-S: Destination Address or 255 (Global)Data Length: 3Priority: 6Broadcast Rate: As neededData 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: 0PDU Format: 234dec( EAhex)

PDU specific: Destination Address: global DA= FFhexor specificDefault priority: 6PGN: 59904 (00EA0016)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


26/39





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 theoutput torque.

This message type categorizes those Parameter Groups that convey a command to a specific or globaldestination from a source. The destination is then supposed to take specific actions based on the reception of thiscommand 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 ( priority6).


27/39


28/39





7.5 MESSAGE TYPE: PROPRIETARY MESSAGES (GROUP FUNCTION)

Group functionsThis Message Type is used for groups of special functions (e.g. proprietary functions, network managementfunctions, 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 CANIdentifier usage conflicts between different manufacturers. It also provides a means for receiving anddistinguishing proprietary messages for use when desired. Group Functions may need to provide their ownrequest, ACK, and/or NACK mechanisms if the messages defined in J1939-21 are not sufficient.A request using PGN 59904 can be used to find out if a specific Parameter Group of the message type, GroupFunction, is supported. If it is supported, then the responding device sends the Acknowledgment PGN with thecontrol byte equal to zero, for Positive Acknowledgment, or equal to two, Access Denied or equal to three, CannotRespond. If it is not supported, the responding device sends the Acknowledgment PGN with the control byte setto one, for Negative Acknowledgment. The remaining portions of the SAE J1939 PDU format and Parameter

Group must be filled in appropriately.


29/39





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

Long Messages

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

Transport Protocol FunctionsTransport protocol functions are described as a part of the data link layer with the recognition that Transportprotocol 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 ReassemblyMessages greater than 8 bytes in length are too large to fit into a single CAN Data Frame. They must thereforebe broken into several smaller packets, and those packets transmitted in separate message frames. At thedestination end, the individual message frames must be received and parsed and the original messagereassembled from the received packets.

Message PacketsThe CAN Data Frame includes an 8-byte data field. Because the individual packets which comprise a largemessage must be identified individually so that they may be reassembled correctly, the first byte of the data fieldis 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 sizeof (255 packets * 7 bytes/packet =) 1785 bytes.

Sequence NumbersSequence numbers are assigned to packets for transmission on the network during message packetization andthen 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 untilthe entire message has been packetized and transmitted. The packets shall be sent sequentially in ascendingorder starting with packet 1.

PacketizationA 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 associatedwith it a string of 9 or more bytes. The first Data Transfer Packet contains the sequence number one and the first7 bytes of the string. The second 7 bytes are placed into another SAE

J1939/CAN data frame along with the sequence number 2, the third with sequence number 3, and so on until allthe bytes in the original message have been placed into SAE J1939/CAN data frames and transmitted.Each Data Transfer packet (other than the last packet in a transmission sequence) shall include 7 bytes of theoriginal large message. The final packet includes a data field of 8 bytes: those being the sequence number of thepacket 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 Section5.12.3). For multi-packet messages directed to a specific destination, the originator maintains a maximum timebetween packets (where CTS allows more than one) of not more than 200 ms. Responders must be aware thatthe packets containing the data all have the same identifier.

ReassemblyData packets are received sequentially. Each data packet of a multipacket message shall be assembied, in orderof sequence number, into a single string of bytes. This string of bytes is passed to the application entity

responsible for the large message.


30/39





7.6.1 Multipacket Broadcast (Broadcast Transmission Protoco l)

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. Itdefjnes the parameter group and the number of bytes to be sent. After TP.CM_BAM is sent, the Data TransferMessages are sent and they contain the packetized broadcast data. TP.CM_BAM is only transmitted by theoriginator (sender).

Transport Protoco l-Data Transfer Message (TP.DT)The TP.DT message is used to communicate the data associated with a Parameter Group. The TP.DT messageis 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: 32dec(20hex)Byte 1-2: Total number of bytes to be transmitted: 17Byte 3: Number of packets: 3Byte 4: reserved for SAEByte 5-7: PGN : 65260

TP.DT :Byte 0: sequence number: 1Byte 1-7: data bytes: first 7

TP.DT :Byte 0: sequence number: 2Byte 1-7: data bytes: bytes 8 to 14

TP.DT :Byte 0: sequence number : 3Byte 1-7: data bytes: bytes 15 to 17bytes not in use are filled with value 255.


31/39





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 = RTSByte 2-3: Total amount of bytes to send: 23Byte 4: number of messages: 4Byte 5: reserved for SAEByte 6-8: PGN : 65259

TP.CM_CTS :Byte 1: controle byte: 17 = CTSByte 2: number of bytes that can be received: 2Byte 3: next databyte expected: 1Byte 4-5:voorbehouden voor SAE

Byte 6-8:PGN : 65259

TP.DT :Byte 1: sequence number: 1Byte 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 :Byte 1: controle byte: 17 = CTS

Byte 2: number of bytes that can be received: 0(0 = receiver wants a break.)Byte 4-5:reserved for SAE

Byte 6-8:PGN : 65259

TP.CM_CTS :Byte 1: controle byte: 17 = CTSByte 2: number of bytes that can be received: 2Byte 3: number of the next databyte: 3Byte 4-5:reserved voor SAE

Byte 6-8:PGN : 65259

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

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

TP.DT :

Byte 1: sequence number: 3Byte 2-8:data bytes: next 7 databytes 15-21

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


32/39





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 connectionwith it. The TP.CM_RTS is a message with the source address field set to that of the originating node, thedestination 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 ToSend message. When the responder complies with this limit, it ensures that the originator can always retransmitpackets 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 shallbe acted on and the previous RTSs will be abandoned. No abort message shall be sent for the abandoned RTSsin 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 itis ready for a certain amount of large message data. The amount of large message data cleared to send shall notbe greater than byte 5 of the originator's TP.CM_RTS message. If multiple CTSs are received after a connectionis al ready established, then the connection shall be aborted. When the originator aborts the connection, it shallsend the Connection Abort message. The responder will not send the next CTS until it has received the last datapacket from the previous CTS or it has timed out. If a CTS is received while a connection is not established, itshall be ignored.CTSs not only control the flow but also confirm correct receipt of any data packet prior to that CTS packet'snumber. Therefore if information for the previous CTS was corrupted, then a CTS for the corrupted informationshall 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_RTSmessage as a way to ensure the possibility of retransmission of a packet within the last set of packets cleared tosend.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 indicatingthat the entire message was received and reassembled correctly. The responder can keep the connection openatter 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 theoriginator 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 hasbeen 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 connectionwithout 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 sufficientresources available to deal with the message for which this connection is sought. For example if the device mustacquire memory from the system heap, it may not be able to claim enough to accept the entire message; or adevice may simply be too occupied doing other things to expend processor cycles to handle a large message. Inthese 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 waitfor a timeout to occur.When either the originator or responder decides to close out a connection for any reason, prior to completing thedata transfer, including a timeout, it shall send a Connection Abort message with the appropriate ConnectionAbort reason.

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


33/39





8 APPLICATION LAYER SAE J1939/73 : DIAGNOSTICS

8.1 DIAGNOSTIC MESSAGES (DM)


34/39





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 SAEJ1939 version of the same PGN. This message allows the communication of diagnostic informationand general operating status.

The form is as follows:Active Diagnostic Message ("DM1")PGN: 65226PDU-F: 254PDU-S: 202Priority: 6. Node may increase priority if appropriate.Broadcast Rate: 1000 ms, plus at change of status.Data 1: Operating Statusbit 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 NumberData 5:bit 5-7: Suspect Parameter Number (Least Sig. Bits)bit 0-4: Failure Mode IdentifierData 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-packetmessage (see next section) or simply sending multiple instances of this message. In the formercase, 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, themessage should be sent showing the lamps as unlit.All conditions should be classified as "Yellow" or "Red". A "Yellow" condition would usually referto a problem that can be remedied by the user (e.g. Low Battery Level to an Inverter) or does notrequire intervention. A "Red" condition would generally require a service technician. Theselevels are subjective, of course.

ACTIVE FAILURE

MIL

DTC

BROADCAST DM 1


35/39





8.3 DATA FIELDS OF A DM1 MESSAGE

8 7 6 5 4 3 2 1

12345

678

MIL STATUS

SPN

RESERVED

SPN

SPN FMI

CM OC


36/39





8.4 FMI FAILURE MODE INDICATION

The committee is charged with providing a list of SPNs. The Failure Modes are defined asfollows:0 Item above normal operating range1 Item below normal operating range2 Item erratic, intermittent, or invalid3 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 circuit7 Mechanical system not responding8 Abnormal frequency, pulse width, or period9 Abnormal update rate10 Abnormal rate of change11 Failure not identifiable12 Bad intelligent device or component13 Out of calibration14 "None of the above" (Use sparingly!)15-30 Reserved31 No failure information available (note: use when the SPN is unknown. If SPN is known,use FMI 11).


37/39





9 NETWORK MANAGEMENT

9.1 NETWORK ADRESSES AND NAMES

On a J1939 network, each device has a unique address. Each message that is sent by a device contains thissource address. There are 255 possible addresses:0..253 Valid addresses of an ECU254 Zero255 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 anotherdevice, 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 deviceis always addressed that provides the required functionality.

There are examples, such as an engine and engine retarder residing in a common ECU, whereinmultiple names and multiple addresses may coexist within a single electronics unit. The address of anECU defines a specific communications source or destination for messages; the name includesidentification of the primary function performed at that address and adds an indication of the instanceof that functionality in the event that multiple ECUs with the same primary function coexist on the samenetwork. As many as 254 different ECUs of the same function can coexist on the network, eachidentified by their own address and name.


38/39





9.2 SAE J1939 INDUSTRY GROUPS PREFERRED NETWORK ADDRESSES

SAE name for INDUSTRY GROUP 0Network 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 41Suspension 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 GroupTo permit multiple industries to use J1939, an lndustry Group code is used to identify the industry towhich the ECU is associated. Code 0 is a special category of lndustry Group in that it identifiesPreferred Addresses and NAMEs that are common to all industries. Any ECU which may be used inmore than one industry application, such as diesel engines, should have NAMEs and PreferredAddresses within this global group. It is the responsibility of those requesting new definitions toconsider if this may be the case, and to request the new definition in the correct group. To avoidrunning out of NAME or address values, it is requested that global values be used only when trulyapplicable, if an ECU may exist in only one group, such as agricultural equipment, it would bepreferable to add the definition to the applicable group rather than to use a global value.


39/39


9.3 PROCEDURE ADDRESS CLAIMING

ADDRESS REQUEST PGN: 59904

PDU-F: 234PDU-S: desired networkaddressPriority: 6Data Length: 3Broadcast Rate: As NeededSource Address: 254 is no address has been claimed.Data 1: 0Data 2: 238Data 3: 0

ADDRESS CLAIMED PGN: 60928PDU-F: 238PDU-S: 255

Priority: 6Broadcast Rate: On Request OnlySource 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 eachECU, even when there is more than one of the same type on the network. But with a length of 64 bits, a NAME isinconvenient to use in normal communications. Therefore, once the network is fully initialized, each ECU utilizesan 8 bit address as its source identifier or "handle" to provide a way to uniquely access a given ECU on thenetwork. For example, an engine may be assigned address 0, but if a second engine is present, it needs aseparate, unique address (e.g. 1) and instance. ECUs that accept destination specific commands may requiremultiple addresses. This permits distinguishing which action is to occur. For example, if the transmission iscommanding 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 ECUon the network may have multiple addresses and each address will have an associated NAME. To facilitate theinitialization process of determining the address (es) for each ECU on the network, commonly used devices havePreferred Addresses assigned by the committee. Using the Preferred Addresses minimizes the frequency ofmultiple 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 J1939/81 and elaborated on in J1939/01) for assigning addresses after powerup is used to resolveany 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 anaddress. 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, butall must at least compare the newly claimed address with their own. Should multiple ECUs claim the sameaddress, the one having the lowest value NAME uses this address and the other(s) must claim a differentaddress 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 Claimedmessages. This permits transitional ECUs (tools, trailers, etc.) or ECUs powering up late to obtain the currentaddress table so that an available address can be found and claimed or to determine which ECUs are currentlyon the network.

Documents

CAN CH2 TRUCKS_ SAEJ1939.pdf