Understanding of FlexRay-TP (ISO 10681-2) Protocol

Welcome to my blog post about the FlexRay-TP (ISO 10681-2) protocol, a communication protocol for FlexRay-based vehicle network systems. In this post, I will give you an overview of what this protocol is, how it works, and why it is useful for automotive applications.

Introduction to FlexRay-TP (ISO 10681-2)

FlexRay is a high-speed serial communication bus that supports both deterministic and event-triggered data transmission. It is designed to meet the requirements of safety-critical and real-time applications in modern vehicles, such as engine control, brake control, steering control, and driver assistance systems. FlexRay can handle up to 10 Mbps of data rate per channel, and can operate with up to 64 nodes on a single network.

However, FlexRay does not define how to transmit messages with unknown or variable data length, such as diagnostic messages or software updates. This is where the FlexRay-TP (ISO 10681-2) protocol comes in. It is a communication layer protocol that provides services for transmitting messages with known or unknown data length over FlexRay. It also provides additional features such as acknowledgement, retry mechanism, routing, and dynamic frame length.

The FlexRay-TP (ISO 10681-2) protocol is specified by the ISO 10681-2 standard, which is based on the OSI model of communication systems. The OSI model divides communication systems into seven layers, from physical layer to application layer. The FlexRay-TP protocol incorporates the network layer and the transport layer services as communication layer services. The network layer is responsible for routing data between nodes on the network, while the transport layer is responsible for segmenting and reassembling data into messages.

Addressing Modes in FlexRay-TP (ISO 10681-2) Protocol

FlexRay-TP supports two addressing modes: physical addressing and functional addressing. Physical addressing uses a source address (SA) and a target address (TA) to identify the sender and the receiver of a message. Functional addressing uses a group address (GA) to identify a group of receivers that share a common function or service. The addresses are encoded in the header of each FlexRay frame as follows:

| Byte | Bit | Description |
|------|-----|-------------|
| 0    | 7-6 | Addressing mode (0x00 for physical addressing, 0x01 for functional addressing) |
|      | 5-4 | Address extension (AE) (additional bits for extended addressing) |
|      | 3-0 | Message identifier (MID) (identifies the type or content of the message) |
| 1    | 7-0 | Source address (SA) or group address (GA) |
| 2    | 7-0 | Target address (TA) |

The AE allows up to four different address spaces to be used within a FlexRay network. The MID allows up to 16 different messages to be distinguished within an address space. The SA or GA identifies the sender or the group of receivers of a message. The TA identifies the receiver or the sender of a message in physical addressing mode.

FlexRay-TP (ISO 10681-2) Message Frame Format

FlexRay-TP is a transport protocol that allows the transmission of data units larger than the payload of a single FlexRay frame. FlexRay-TP is based on the ISO 10681-2 standard and defines two types of messages: single-frame messages and multi-frame messages.

FlexRay-TP (ISO 10681-2) Single Frame Format

A single-frame message consists of a single FlexRay frame that contains the entire data unit. A single-frame message has the following format:

| Byte | Bit | Description |
|------|-----|-------------|
| 0        | 7      | PCI type (0x00 for single-frame message) |
|           | 6-0  | Data length (number of bytes in the data field) |
| 1-63  |          | Data field (up to 63 bytes) |

Multi-Frame

A multi-frame message consists of several FlexRay frames that contain a segmented data unit. The first frame of a multi-frame message is called the first frame, the last frame is called the last frame, and the intermediate frames are called consecutive frames. A multi-frame message has the following format:

| Byte | Bit | Description |
|------|-----|-------------|
| 0    | 7   | PCI type (0x10 for first frame, 0x20 for consecutive frame, 0x30 for last frame) |
|      | 6-4 | Frame sequence number (FSN) (incremented by one for each consecutive frame, modulo 8) |
|      | 3-0 | Data length high nibble (DLHN) (most significant nibble of the data length for first and last frames, reserved for consecutive frames) |
| 1    | 7-0 | Data length low byte (DLLB) (least significant byte of the data length for first and last frames, reserved for consecutive frames) |
| 2-63 |     | Data field (up to 62 bytes for first and last frames, up to 63 bytes for consecutive frames) |
 
The data length indicates the number of bytes in the entire data unit, not in each frame. The FSN allows the receiver to detect missing or duplicated frames and to reorder them if necessary. The DLHN and DLLB allow the receiver to allocate memory for the data unit and to detect its end.

FlexRay-TP Protocol Control Information Specification

The protocol control information (PCI) is a part of the payload data that contains information about the segmentation and reassembly of long messages. The PCI specification defines the format and meaning of the PCI fields for different types of segments, such as single frame (SF), first frame (FF), consecutive frame (CF), and flow control (FC). The PCI also specifies the rules for error handling, timeout management, and flow control mechanisms.

FlexRay-TP (ISO 10681-2) Protocol C_PCI bytes Information

Definition of C_PCI type values in FlexRay-TP (ISO 10681-2) Protocol

There are b6 types of frames in lexRay-TP (ISO 10681-2) Protocol for communication.

StartFrame / StartFrame_ACK (0x4) in FlexRay-TP (ISO 10681-2)

A StartFrame, also known as STFU or STFA, is necessary to facilitate the transmission of messages, whether they are in one piece or segmented into multiple parts.

In the case of an unsegmented transmission, the corresponding StartFrame includes the complete message and can be identified by the Message Length (ML) being equal to the length of the data content of the StartFrame.

If you decide to break up a message into smaller parts, the StartFrame will contain the first part of the message. You can identify this StartFrame because the Message Length (ML) will be greater than the length of the data in the StartFrame.

When a StartFrame is received, the receiving communication layer entity will begin to put together the segmented message.

If you are sending a message without expecting confirmation that it was received, the low nibble of the transmission will have a value of “0”. However, if you are expecting confirmation of the message being received, the low nibble will have a value of “1”.

ConsecutiveFrame_1 (0x5) in FlexRay-TP (ISO 10681-2)

When transmitting segmented data, any frames that come after the Start of Transmission Frame Used (STFU) or Start of Transmission Frame Acknowledgement (STFA) are encoded as ConsecutiveFrame (CF). Upon receiving a CF, the communication layer entity that receives it must gather the received data bytes and combine them until the complete message has been received. After the final frame of the message has been received without any errors during unacknowledged transmission, or after transmitting the acknowledgement of the message reception during acknowledged transmission, the receiving entity will pass the assembled message to the upper layer.

To enable a retry mechanism, the C_PCItype definition includes two distinct types of ConsecutiveFrames. When a retry mechanism is not supported, the ConsecutiveFrame_1 must be utilized for the entire message transmission.

A segmented message transmission shall always start with ConsecutiveFrame_1.

ConsecutiveFrame_2 (0x6) in FlexRay-TP (ISO 10681-2)

The format of ConsecutiveFrame_2 is identical to the definitions of ConsecutiveFrame_1.

ConsecutiveFrame_EOB (0x7) in FlexRay-TP (ISO 10681-2)

When there is a requirement to actively acknowledge a block of transmitted data, either due to buffer limitations in the sender or the receiver, the sender will utilize the ConsecutiveFrame_EOB (EOB=End Of Block) to explicitly request that the receiver acknowledge the reception of the transmitted data block. This mechanism is employed, for instance, when the sender has restricted buffer resources, and message transmission is possible only in specific blocks, and retry is necessary to ensure the buffer can be freed up for the subsequent block of data transmission for the message.

FlowControl (0x8) in FlexRay-TP (ISO 10681-2)

FlowControl (FC) serves several purposes, such as facilitating negotiation of the receiver’s buffer capabilities and enabling the request for retry of transmission within the current block of data. To support this function, the protocol specifies five distinct types of FC protocol control information, indicated by a field of the protocol control information known as FlowStatus (FS).

FlexRay-TP provides mechanisms for flow control, error detection and recovery. The receiver can send a flow control frame to indicate its buffer status and to request more frames or to stop the transmission. The flow control frame has the following format:

The BS and ST allow the receiver to regulate the transmission speed and to avoid buffer overflow.

LastFrame (0x9) in FlexRay-TP (ISO 10681-2)

The final frame is utilized by the sender to conclude any type of transmission, both for known and unknown message lengths. The message length (ML) parameter specifies the total length of the message, not considering any redundantly transmitted bytes during retries. For transmissions with a known message length, the indicated message length is equivalent to the message length given in the StartFrame.

StartFrame / StartFrame_ACK C_PCI parameter definition

overview of the STFU/STFA C_PCI byte

In the STF C_PDU, the FPL (Frame Payload Length) parameter indicates the quantity of payload data bytes present within the STF C_PDU. It’s worth noting that the FPL value doesn’t incorporate the length of the ML (Message Length) parameter, as shown below table:

How does FlexRay-TP (ISO 10681-2) protocol works?

1. The request from the sender is for the transmission of a message using C_Data.req with the MessageLength (ML) parameter set to the total length of the message. However, the sender is only able to provide a portion of the message data that fits into the sender buffer, as indicated by ActualLength not equal to zero. The StartFrame that is transmitted indicates the entire message using ML.
2. Upon receiving the StartFrame of the message, the receiver indicates it to the upper layer using C_Data_STF.indication.
3. The receiver sends a FlowControl frame to the sender, indicating its buffer capabilities through the BfS parameter. In this particular case, the receiver’s buffer is not large enough to accommodate the entire message, as indicated by BfS being less than ML.
4. After receiving the FlowControl frame from the receiver, the sender begins transmitting the next block of data with a Consecutive Frame.
5. The final frame of the block, which is the Consecutive Frame End of Block (CF_EOB), signals to the receiver that an acknowledgement for that block is necessary. The need for acknowledgement can be triggered either by the buffer constraints of the sender or by the buffer size of the receiver, as reported through BfS.
6. Upon receiving the block of data, the receiver acknowledges the reception.
7. After acknowledging the reception of the block, the receiver reports the data received up to that point to the upper layer through C_Data.ind, with C_Result set to C_MOREDATA. The receiver also adjusts its buffer to accommodate the next block of data.
8. After sending the block of data, the communication layer in the sender requests further data for the message from the upper layer using C_Data.con, with C_Result set to C_MOREDATA.
9. Upon receiving the request for more data from the communication layer in the sender, the upper layer now provides additional data to be transmitted.
10. Once the upper layer in the sender provides the additional data, the communication layer starts the next block of data with a Consecutive Frame, following the FlowControl frame.
11. Similar to the previous block, the last frame of the new block (CF_EOB) signals to the receiver that an acknowledgement is required for the segment. The need for acknowledgement can be triggered either by the buffer constraints of the sender or by the buffer size of the receiver, as reported through BfS.
12. Upon receiving the new block of data, the receiver acknowledges the reception.
13. After acknowledging the reception of the new block, the receiver reports the data received up to that point to the upper layer through C_Data.ind, with C_Result set to C_MOREDATA. The receiver also adjusts its buffer to accommodate the next block of data.
14. After transmitting the new block of data, the communication layer in the sender requests more data for the message from the upper layer using C_Data.con, with C_Result set to C_MOREDATA.
15. Upon receiving the request for more data from the communication layer in the sender, the upper layer now provides additional data to be transmitted.
16. After transmitting the complete message, assuming the Last Frame is unacknowledged and the message length is known, the sender indicates the completion of the transmission through C_Data.con, with C_Result set to C_OK.
17. Once the receiver successfully receives the complete message, it indicates the completion of the reception through C_Data.ind, with C_Result set to C_OK.

FlexRay Transport Protocol in AUTOSAR

The FrTp (FlexRay Transport Protocol) offers both confirmed and unconfirmed communication services for AUTOSAR applications that utilize a FlexRay bus. While it is partly based on the ISO 15765-2 standard, which provides unconfirmed communication for diagnostic applications in a CAN-based vehicle, the FrTp also includes additional reliability features, such as acknowledgements and retries, to ensure confirmed communication.

To improve performance, segmentation and flow control are implemented, using a go-back-N error/flow control scheme. In this section, only the features relevant to modeling and analysis tasks are described. The focus is on the confirmed service, as it is substantially different and more complex than the existing ISO 15765-2 protocol.

FrTp Service Specification:

AUTOSAR COM or DCM sends application and/or diagnostics data to the PDU Router. If necessary, the PDU Router forwards the data to FrTp, which then transfers it to the destination ECU, PDU Router, and ultimately the application. FrTp provides a service to the user (PDU Router). The protocol defines a set of service primitives, and each primitive is prefixed with a layer name, such as “FrTp Transmit.”

The key operations for data transfer are the following:

1. The Transmit primitive is called by PDU Router to initiatedata transmission at the sender.
2. The FlexRay Interface (FrIf) is used to transmit that data to the receiver FrTp.
3. When the receiver successfully receives the data, it transfers the data to the PDU Router via the ‘RxIndication‘ primitive. Furthermore, it sends a confirmation to the sender and passes it to the PDU Router as a TxConfirmation with the successful flag set.
4. If the data delivery is unsuccessful, no indication is given to the receiver PDU Router. Instead, a TxConfirmation with the unsuccessful flag set is delivered to the sender PDU Router.

FrTp Protocol Specification:

A Protocol Data Unit (PDU), which is data arriving from the higher layer, can be transmitted with FrTp using various methods.

1. unacknowledged segmented or unsegmented transfer.
2. acknowledged segmented or unsegmented transfer, but no retries.
3. acknowledged segmented or unsegmented transfer with retries.
4. unacknowledged segmented or unsegmented multi-cast transfer.

Advantages of FlexRay-TP (ISO 10681-2)

FlexRay-TP (ISO 10681-2) is a transport protocol built on top of the FlexRay communication system. It is designed for time-critical, safety-relevant, and high-performance applications in automotive systems. Here are some advantages of the FlexRay-TP protocol:

1. Deterministic and Time-Triggered Communication: FlexRay-TP supports both time-triggered and event-triggered communication, which makes it suitable for deterministic real-time systems. This ensures that critical data is exchanged within a fixed time period, enabling reliable and predictable communication.
2. High Data Rates: The FlexRay-TP protocol enables high data rates (up to 10 Mbps) compared to other automotive communication protocols, such as CAN (1 Mbps) or LIN (20 Kbps). This makes it ideal for advanced applications that require high-speed data transfer and real-time performance.
3. Fault-Tolerant: FlexRay-TP incorporates built-in fault-tolerant features, such as redundancy and error detection. These mechanisms ensure high reliability and data integrity, which is crucial for safety-critical systems like those found in modern vehicles.
4. Scalability: The FlexRay-TP protocol is highly scalable, allowing for the integration of a large number of nodes (up to 64) in the network. This is particularly beneficial in modern vehicles, which have an increasing number of electronic control units (ECUs) that need to communicate with each other.
5. Flexibility: FlexRay-TP supports multiple communication channels, which provides flexibility in designing the network architecture. This enables the integration of different communication requirements and simplifies system design.
6. Synchronization: The protocol allows for global time synchronization among all nodes in the network. This ensures that all nodes have a common time reference, which is important for time-critical applications and distributed control systems.
7. Lower Electromagnetic Interference: The FlexRay-TP protocol uses differential signaling to transmit data, which helps reduce electromagnetic interference (EMI). This is important in automotive environments, where numerous electronic systems coexist and are sensitive to EMI.
8. Modular and Reconfigurable: FlexRay-TP allows for modular and reconfigurable system designs, enabling changes or updates to the network without affecting the existing infrastructure. This makes it easier to adapt to future requirements and technologies.

Disadvantages of FlexRay-TP (ISO 10681-2)

Despite its many advantages, the FlexRay-TP (ISO 10681-2) protocol also has some disadvantages, which are important to consider when evaluating its suitability for a particular application:

1. Cost: FlexRay-TP systems tend to be more expensive than other automotive communication systems, such as CAN or LIN, due to the increased complexity and higher performance requirements. This includes both the cost of hardware components, like ECUs and communication modules, and the cost of development, integration, and testing.
2. Complexity: The FlexRay-TP protocol is more complex than other automotive communication protocols, which can make it more challenging to design, implement, and maintain. This can lead to longer development times and a steeper learning curve for engineers and developers who are new to the protocol.
3. Limited Backward Compatibility: FlexRay-TP is not directly compatible with legacy automotive communication systems, such as CAN or LIN. This means that integrating FlexRay-TP into existing systems may require additional hardware, software, or bridging solutions, which can add to the overall cost and complexity.
4. Limited Sdoption: Although FlexRay-TP offers many benefits, it has not been as widely adopted in the automotive industry as other communication protocols like CAN. This can make it more difficult to find off-the-shelf components, tools, and resources for working with the protocol.
5. Power Consumption: The high data rates and advanced features of FlexRay-TP can result in higher power consumption compared to other automotive communication protocols. This can be a concern in applications where power efficiency is a priority, such as battery-powered electric vehicles.
6. Availability of Skilled Resources: Since FlexRay-TP is a relatively niche protocol, it can be more challenging to find engineers and developers with expertise in the technology. This may limit the availability of skilled resources for system design, development, and maintenance.

Future Development & Enhancement of FlexRay-TP (ISO 10681-2)

While FlexRay-TP (ISO 10681-2) protocol offers a robust solution for high-performance, safety-critical, and real-time automotive applications, there is always room for future development and enhancements to address its current limitations and adapt to new technologies and requirements. Here are some potential areas of development and improvement for the FlexRay-TP protocol:

1. Increased Data Rates: As automotive systems continue to evolve and demand for high-speed communication grows, further increasing the data rates supported by FlexRay-TP can help it remain competitive and meet the needs of emerging applications.
2. Enhanced Backward Compatibility: Developing solutions or methods to improve the compatibility of FlexRay-TP with legacy automotive communication systems, such as CAN or LIN, can facilitate its integration into existing infrastructures and make it more appealing for a wider range of applications.
3. Improved Power Efficiency: With the growing emphasis on energy efficiency and the rising popularity of electric vehicles, enhancing the power efficiency of FlexRay-TP components and systems can be an important area of development.
4. Expanded Adoption and Standardization: Encouraging the adoption of FlexRay-TP in more automotive applications can help drive the development of off-the-shelf components, tools, and resources. This can lead to lower costs and a larger ecosystem of support, making it more accessible and attractive for a wider range of use cases.
5. Integration with Emerging Technologies: FlexRay-TP can be enhanced by integrating it with new technologies, such as wireless communication, advanced security features, or machine learning algorithms, to enable new functionalities and support emerging automotive applications.
6. Development of Dedicated Software Tools: Creating more user-friendly, dedicated software tools for designing, simulating, and analyzing FlexRay-TP networks can help reduce the complexity associated with working with the protocol and shorten development times.
7. Strengthening Security: As automotive systems become more interconnected and cyber threats grow, enhancing the security features of FlexRay-TP to protect against potential attacks and ensure data privacy will be crucial.
8. Capacity for more Nodes: Increasing the maximum number of nodes that can be supported by the FlexRay-TP protocol can help accommodate the growing number of electronic control units (ECUs) in modern vehicles and make the protocol more scalable.
9. Training and Skill Development: Encouraging education and training programs to develop skilled engineers and developers with expertise in FlexRay-TP can help address the current shortage of skilled resources and promote the wider adoption of the protocol.