SAE J1939 Programming with Arduino - Multi-Packet Peer-to-Peer (RTS/CTS Session)

This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino.

The communication of destination specific (peer-to-peer) multi-packet messages is subject to flow-control.

1. Connection Initialization – The sender of a message transmits a Request to Send message. The receiving node responds with either a Clear to Send message or a Connection Abort message in case it decides not to establish the connection. A Connection Abort as a response to a Request to Send message is preferred over a timeout by the connection initiator. The Clear to Send message contains the number of packets the receiver is expecting plus the expected sequence number.
2. Data Transfer – The sender transmits the Data Transfer PGN after receiving the Clear to Send message. Data transfer can be interrupted/stopped by a Connection Abort message.
3. Connection Closure – The receiver of the message, upon reception of the last message packet, sends an End of Message ACK (acknowledgement) message, provided there were no errors during the transmission. Any node, sender or receiver, can send a Connection Abort message. The reason of aborting a connection can be a timeout.

A reliable flow-control will must also include timeouts in order to assure proper network function, and SAE J1939/21 defines a number of timeouts.

T_r = 200 ms - Response Time
T_h = 500 ms - Holding Time
T1 = 750 ms
T2 = 1250 ms
T3 = 1250 ms
T4 = 1050 ms

Scenarios for timeout control are:

• A node (regardless whether the node is the receiver or sender of the data message) does not respond within 200 ms (T_r) to a data or flow control message.
• If a receiving node needs (for any reason) to delay the transmission of data it can send a Clear to Send message where the number of packages is set to zero. In cases where the flow must be delayed for a certain time the receiver of a message must repeat the transmission of the Clear to Send message every 0.5 seconds (Th) to maintain an open connection with the sender of the message. As soon as the receiver is ready to receive the message it must send a regular Clear to Send message.
• A time of greater than T1 elapsed between two message packets when more packets were expected.
• A time greater than T2 elapsed after a Clear to Send message without receiving data from the sender of the data.
• A time greater than T3 elapsed after the last transmitted data packet without receiving a Clear to Send or End of Message Acknowledgment (ACK) message.
• A time greater than T4 elapsed after sending a Clear to Send message to delay data transmission without sending another Clear to Send message

Any timeout condition will consequently cause a connection closure.

Note: What SAE J1939/21 fails to mention is that the “Clear to Send” message can be send by the receiver of the data message at any time, either immediately after the reception of a “Request to Send” message or after reception of a data packet, meaning any time during the data transfer.

Other reasons for connection closure are:

• The sender of a data message sends the last Data Transfer package.
• The receiver of a data message receives the last Data Transfer package and a T1 timeout occurs.
• The sender of a data message receives an End of Message ACK message.
• Reception of Connection Abort message.

The flow control messages, such as Request to Send, Clear to Send, etc. are embedded in the Transport Protocol – Connection Management (TP.CM) PGN 60416 and the actual data transfer is handled by using the Data Transfer PGN 60160.

Control Byte = 32 is reserved for Broadcast Announce Message. Control Bytes 0-15, 18, 20-31, 33-254 are reserved by the SAE.

The Connection Abort Reasons can be:

1 – Node is already engaged in another session and cannot maintain another connection.
2 – Node is lacking the necessary resources.
3 – A timeout occurred.
4…250 - Reserved by SAE.

251…255 – Per J1939/71 definitions (Unfortunately, the SAE J1939 Standards Collection offers no further explanations.)

The actual data transfer is handled by using the Data Transfer PGN 60160.

The last packet of a multi-packet PGN may require less than eight data bytes. All unused data bytes in the last package are being set to 0xFF.

The following image demonstrates the basic data flow between the transmitting and receiving mode during an RTS/CTS session (i.e. peer-to-peer communication).

Note: I refrained from inserting the various timeouts that can occur during an RTS/CTS session. Each individual timeout scenario would require its own flow chart, while the functionality was already sufficiently described.

SAE J1939 has become the accepted industry standard and the vehicle network technology of choice for off-highway machines in applications such as construction, material handling, and forestry machines. J1939 is a higher-layer protocol based on Controller Area Network (CAN). It provides serial data communications between microprocessor systems (also called Electronic Control Units - ECU) in any kind of heavy duty vehicles. The messages exchanged between these units can be data such as vehicle road speed, torque control message from the transmission to the engine, oil temperature, and many more.

A Comprehensible Guide to J1939 is the first work on J1939 besides the SAE J1939 standards collection. It provides profound information on the J1939 message format and network management combined with a high level of readability.

Read more...