SAE J1939 - Protocol

SAE J1939 Overview

The SAE J1939 protocol is a set of standards that define standardized methods for ECU communication. It is a higher-layer protocol built on CAN as the physical layer. Supports both node addressing and message addressing. Can transmit up to 1785 bytes. Has its own diagnostic interface with a set of PGNs to handle diagnostic services.

Embien’s SAE J1939 stack supports all messages defined by application and diagnostic layers. Handles the reception and transmission of standard single-frame and multi-frame (i.e., transport protocol) J1939 messages.

The OSI layer of J1939

J1939 Block Diagram

Some of the salient features of RAPIDSEA SAE-J1939 protocol stack are

  • Enables in-vehicle network communications (ECU communications)

  • Supports vehicle diagnostics services and fault-code memory

  • Supports to transmit and receive the data in More than 8 bytes.

  • Peer-to-peer Transport Protocol (TP.CM_RTS(Ready to send)/TP.CM_CTS(Clear to send))and Broadcast Announce Message(BAM)

  • The embedded software code of the Stack is MISRA-C complaint.

  • Can be used with or without RTOS

  • Can support 8, 16, 32, 64-bit CPUs

The below diagram captures the block level diagram of the J1939 and how it interfaces with other modules.

J1939 Block Diagram

SAE J1939 Communication Mechanisms

1. BAM (Broadcast Announce Message)

BAM is used in the J1939 protocol for broadcasting large data. It’s a way for one ECU (or a node) to send a large message to multiple ECUs over the CAN network. BAM is often used for data that needs to be sent to multiple receivers at once, without waiting for individual acknowledgments. It allows for the broadcast of large data to multiple receivers. BAM messages can carry large data over multiple frames. A message is broken into multiple frames, each with an 8-byte data field. Each frame will include a sequence number to reassemble the full message at the receiving end.

  • Key Features: - Once the message is broadcast, receivers do not acknowledge each frame individually. - One ECU can send the data to many without needing a direct request.

2. RTS/CTS (Request to Send / Clear to Send)

RTS/CTS is a two-step process used for large data transfers in J1939. It is mainly used for point-to-point communication between two ECUs. The RTS/CTS method is used when an ECU needs to send a large amount of data (over 8 bytes) and wants to ensure that the receiving ECU is ready to receive this data without causing data overload or collisions.

  • RTS (Request to Send): - The sender ECU uses the RTS message to request permission to send a large message. - It includes the PGN (Parameter Group Number) of the message and indicates how many data frames the sender intends to send. - The sender waits for the receiving ECU to respond with a CTS message.

  • CTS (Clear to Send): - The receiving ECU sends a CTS message in response to an RTS message, indicating it is ready to receive the data. - The CTS message will contain the necessary details for the sender to continue transmitting the data (e.g., the number of frames the receiver is ready to accept).

  • Key Features: - Ensures that large messages are not sent too quickly or in a way that could overwhelm the receiving ECU. - First, the sender requests permission (RTS), and then the receiver approves (CTS).

3. Request/Response

The Request/Response method is a simple one-to-one communication method used in J1939 for querying data from a specific ECU. It is commonly used for diagnostic services, where one ECU requests a piece of information, and another ECU responds with the requested data.

  • Request: - An ECU sends a request message to another ECU asking for a specific piece of information, such as sensor data or diagnostic information. - It contains the PGN of the requested data, along with any necessary parameters to specify the data or service needed.

  • Response: - The ECU that has the requested data sends a response message containing the requested data or an acknowledgment if no data is available. - Contains the requested data or a response code (if the request could not be fulfilled).

  • Key Features: - Unlike BAM, where data is broadcasted, the Request/Response method is a direct communication between two ECUs. - Suitable for requests where the amount of data is small and the exchange is not as frequent.

Application Interface

This section covers the details of how to use the SAE J1939 stack. It provides the ability to transmit large messages over the Controller Area Network (CAN) bus using a series of smaller frames. It employs mechanisms like BAM (Broadcast Announce Mode) and RTS (Ready to Send)/CTS (Clear to Send) to transmit more than 8 bytes. Broadcast Announce Mode is used to send data to all ECUs with the standard global address (0xFF), while RTS/CTS is used for point-to-point communication.

As it is message-oriented, the RAPIDSEA SAE J1939 stack requires the application to provide buffers during initialization. The size of the buffers can be determined by the user based on their application requirements. For example, if a 4096-byte message size has to be supported, each buffer must be at least this size plus a few more bytes.

When the higher-level application layer wants to transmit and receive a message, it fills the buffer with data and queues it for transmission and reception. J1939 consolidates it over multiple frames into a single message and provides it to the application layer as a complete message.

The below table captures the function that are to be called from the application logic.

API Functions

Function

Description

rs_j1939_open

Initializes the j1939 stack

rs_j1939_set_tx_msg_buf

Set up the transmit buffers to be used for the j1939 stack

rs_j1939_set_rx_msg_buf

Set up the receive buffers to be used for the j1939 stack

rs_j1939_set_req_tx_msg_buf

Set up the transmit buffers to be used for the request response mode in j1939 stack

rs_j1939_set_req_rx_msg_buf

Set up the receive buffers to be used for the request response mode in j1939 stack

rs_j1939_get_transmit_msg_buf

Requests a transmit buffer for sending message.

rs_j1939_queue_transmit_msg

Transmits the given message over one or more frames

rs_j1939_release_transmit_msg

Function release the transmit messages

rs_j1939_rx_buffer_handled

Indicates the receive buffer is handled

rs_j1939_get_tx_request_msg_buf

Retrieve a transmit request message buffer in the J1939 protocol

rs_j1939_queue_request_tx_msg

Transmits the given message to push a response message data

rs_j1939_release_request_tx_msg

Function release the request transmit messages

rs_j1939_handled_request_rx_buff

Indicates the request receive buffer is handled

rs_j1939_tx_request

Sends a request message over the J1939 protocol for the specified Parameter Group Number

rs_j1939_ivn_transmit_handler

Handle a sequence of data packets to other ECU in BAM or RTS CTS mode.

rs_j1939_handle_rx_packet

Function used to handle the received message from CAN.

rs_j1939_process

Function to be called periodically to process underlying state machines

rs_j1939_can_id_is_valid

validates if the provided CAN ID corresponds to a valid J1939 frame.

rs_j1939_close

close j1939 handle

The details of these functions are covered in the below sections.

There are many functions through which the J1939 stack retrieves information from the application logic or indicate actions to be performed. These functions are captured in the below table.

API Functions

Function

Description

rcb_j1939_is_pgn_support

Check the PGN is supported or not

rcb_j1939_update_resp_failure_info

Update the response failure information

rcb_j1939_ack_resp_received

Handles the acknowledgment response for a J1939 message

rcb_j1939_rx_multiple_packet

Handles to reveive the multiple packets to update the DID

rs_ret_val_t rcb_j1939_get_ivn_msg_frame

Prepares and retrieves the IVN (In-Vehicle Network) message frame for J1939.

rs_ret_val_t rcb_j1939_pgn_is_available

Checks if a specific Parameter Group Number (PGN) is available.

rs_ret_val_t rcb_j1939_get_cts_tx_info

J1939 interface for control information related to the transmission of a CTS message

rs_ret_val_t rcb_j1939_get_max_frames

J1939 to set a max number of frames

The below diagram captures the high level sequence of operations associated with the J1939 stack.

J1939 Sequence Diagram

Dependency

This stack depends on the below RAPIDSEA interfaces that can be obtained or custom implemented.

J1939 Header Details

Documentation from the relevant header as follows:

Warning

doxygenfile: Cannot find file “rs_j1939.h