Understanding FlexRay Transport Protocol Timing Parameters and Timeout Strategies
In today’s automotive environment, where real-time communication is essential, understanding the nuances of
FlexRay Transport Protocol (FrTp) Timing Parameters and Timeout Behaviour
The FrTp module necessitates varied temporal parameters for the management of communication. The FlexRay communication protocol is designed for distributed bus-based communication between a set of controllers. It defines both the physical and data link layers, allowing controllers to connect via one or two channels at data rates of 10 Mb/s. The data link layer employs Time-Division Multiple Access (TDMA), enabling each controller to transmit 255 bytes of data in a frame per time slot.
Introduction to FrTp Timing Parameters and Timeout Behaviour
FlexRay, famend for its deterministic behavior, is based on specific timing parameters to facilitate seamless verbal exchange among car components. These parameters govern diverse elements of records transmission, making sure synchronization and performance inside the community.
An essential aspect of the FrTp (FlexRay Transport Protocol) is its timing parameters, which govern the precise timing and synchronization of data transmission within FlexRay networks. These parameters play a crucial role in ensuring efficient and reliable communication between network nodes.
Need of FrTp Timing Parameter in Flexray Protocol
The FrTp protocol timing parameters include various factors such as frame timing, message scheduling, and response times. Frame timing refers to the intervals at which data frames are transmitted over the FlexRay bus, while message scheduling dictates the order in which different types of messages are sent and received.
Additionally, response times determine the maximum duration within which a node must respond to a message or request from another node. These timing parameters are carefully configured to meet the specific requirements of the automotive system, considering factors such as latency, bandwidth utilization, and network congestion.
By optimizing and fine-tuning these timing parameters, engineers can enhance the performance and reliability of FrTp communication, ensuring timely and accurate data exchange within the FlexRay network. This enables the seamless operation of advanced automotive systems, including driver assistance features, vehicle diagnostics, and entertainment systems.
FrTp Module Timing Parameters in AUTOSAR
| Timing Parameter | Description | Timer Start Condition | Timer Stop Condition |
|---|---|---|---|
| FRTP_TIME_AS | The duration for transmitting any FrTp N-PDU from the sender’s end is a performance criterion. This duration varies depending on the implementation and the overall FlexRay schedule. The upper limit of this duration is regulated by the FRTP_TIMEOUT_AS parameter. | FrIf_Transmit() | FrTp_TxConfirmation() |
| FRTP_TIME_AR | The time required to transmit a FlowControl FrTp N-PDU on the receiver side is a performance standard. This duration is contingent upon the implementation and the overarching FlexRay schedule. The maximum duration is governed by the FRTP_TIMEOUT_AR parameter. | FrIf_Transmit() | FrTp_TxConfirmation |
| FRTP_TIME_BS | The duration until the reception of the subsequent FlowControl N-PDU is a regulated aspect. The maximum duration is governed by the FRTP_TIMEOUT_BS parameter. | FrTp_TxConfirmation (STF), FrTp_RxIndication (FC), FrTp_TxConfirmation (CF), FrTp_TxConfirmation (LF) | FrTp_RxIndication (FC) |
| FRTP_TIME_BR | The duration until the transmission of the next FlowControl N-PDU. | FrTp_RxIndication (STF), FrTp_TxConfirmation (FC), FrTp_RxIndication (CF), FrTp_RxIndication (LF) | FrIf_Transmit (FC) |
| FRTP_TIME_CR | The duration until the receipt of the next ConsecutiveFrame N-PDU. The maximum duration is regulated by the FRTP_TIMEOUT_CR parameter. | FrTp_TxConfirmation (FC), FrTp_RxIndication (CF) | FrTp_RxIndication (CF) FrTp_RxIndication (LF) |
| FRTP_TIME_CS | The duration, measured in seconds, until the transmission of the subsequent ConsecutiveFrame N-PDU or LastFrame N-PDU. | FrTp_TxConfirmation (CF), FrTp_RxIndication (FC) | FrIf_Transmit (CF) |
FrTp Module Timeout Behaviour
| Timeout Parameter | Cause | Action |
|---|---|---|
| FRTP_TIMEOUT_AS | Any FrTp N-PDU that isn’t transmitted within the designated timeframe on the sender side. | Abort message transmission: 1) Call FrIf_CancelTransmit() and free the FrTpTxPdu. 2) Issue PduR_FrTpTxConfirmation with the associated FrTpTxSdu ID and E_NOT_OK status. |
| FRTP_TIMEOUT_AR | Any FrTp FlowControl N-PDU that isn’t transmitted on time on the receiver side. | Abort the reception of the message and issue PduR_FrTpRxIndication with the relevant FrTpRxSdu ID. |
| FRTP_TIMEOUT_BS | The FlowControl N-PDU is not received (lost or overwritten) on the sender’s end. | Terminate the transmission of the message and issue PduR_FrTpTxConfirmation with the corresponding FrTpTxSdu ID and status E_NOT_OK. |
| FRTP_TIMEOUT_CR | The ConsecutiveFrame or Last Frame NPDU is not received (lost or overwritten) on the receiver’s side. | Cease message reception and trigger PduR_FrTpRxIndication with the respective FrTpRxSdu ID and status E_NOT_OK. |
| FRTP_TIMEOUT_BR | The initiation of transmission for any FrTp FlowControl N-PDU is not carried out on the receiver’s end following the receipt of the subsequent consecutive frame (STF or last CF of a block or LF), or after the transmit confirmation for the flow control (WT) frame. | Terminate message reception and initiate PduR_FrTpRxIndication with the corresponding FrTpRxSdu ID. |
| FRTP_TIMEOUT_CS | Transmission of any FrTp CF N-PDU is not initiated on the sender’s end in a timely manner after receiving the flow control frame (CTS). | Halt the transmission of the message and send PduR_FrTpTxConfirmation with the corresponding FrTpTxSdu ID and status E_NOT_OK. |
In FlexRay, the transmission confirmation doesn’t offer an End-To-End confirmation as in other bus protocols (such as CAN). This implies that a transmission confirmation is only provided once the L-PDU has been handed over to the network. Consequently, if no confirmation is received, the L-PDU remains trapped within the message buffer of the FlexRay controller, rendering it occupied and unavailable for use in the interim.
This scenario could arise if an N-PDU is repeatedly suspended within the dynamic segment. Such a situation may occur if the preceding FlowControl N-PDU is not received (lost or overwritten) on the sender’s side overall.
FrTp Timing Parameter Definition for one PDU Transmission per MainFunction call in AUTOSAR
The FrTp timing parameter definition for one PDU transmission per MainFunction call in AUTOSAR refers to the specific parameters governing the timing of single PDU transmissions within each MainFunction call in an AUTOSAR-compliant system.
As mentioned earlier, it is feasible to transmit multiple N-PDUs per connection within a single FlexRay Communication Cycle. Therefore, the communication handler should have the capability to invoke the FrIf_Transmit API multiple times, depending on the availability of N-PDUs within the Tx-PDU-Pool, regardless of whether FrTp_TxConfirmation for previously transmitted N-PDUs has been received. Consequently, the timing behavior, such as Start FRTP_Time_AS, varies accordingly.
FrTp Timing Parameter Definition for Multiple PDU Transmission per MainFunction call in AUTOSAR
The FrTp timing parameter definition for multiple PDU transmission per MainFunction call in AUTOSAR refers to the specific parameters and configurations governing the timing and execution of multiple Protocol Data Unit (PDU) transmissions within each MainFunction call in an AUTOSAR-compliant software architecture.
Bandwidth control limits the number of N-PDUs that can be transmitted per FlexRay cycle. This limitation affects FrTp_Time_CS, which is dependent on the implementation, including the task schedule of FrTp_Main() and the associated FlowControl parameters.
FrTp Timers Management using the different Counters handled in AUTOSAR
The utilization of multiple counters within the FlexRay protocol to manage various retry attempts. It outlines the specific counters employed and their respective behaviors, including how they increment and decrement. Each counter is constrained by a predetermined threshold value. Additionally, the paragraph mentions a figure illustrating the interactions between timers, counters, and function calls to provide a visual representation of these dynamics.
Different Timing Parameters used in AUTOSAR Flexray-TP Stack for Configuration with Description.
| Parameter Name | Time Range (ms) | Description | Exmple Time Taken |
|---|---|---|---|
| FrTpAckType | FrTp_ACK/NACK | This parameter defines the type of acknowledgement which is used for the specific channel. | FrTp_NO |
| FrTpMaxAr | 0 – 255 | This parameter defines the maximum number of trying to send a frame when a TIMEOUT AR occurs. This parameter is currently not used. | 0 |
| FrTpMaxAs | 0 – 255 | This parameter defines the maximum number of trying to send a frame when a TIMEOUT AS occurs. | 0 |
| FrTpMaxBufferSize | 1 – 65535 | This constrains the maximum buffer size that FrTp can select to restrict the quantity of Tx buffers requested at the sender’s end during a segmented transfer. | 16384 |
| FrTpMaxFCWait | 0 – 255 | This parameter establishes the upper limit for the number of FlowControl N-PDUs with FlowState “WAIT”. | 1 |
| FrTpMaxFrIf | 0 – 255 | This parameter defines the maximum number of trying to send a frame when the FrIf returns an error | 0 |
| FrTpMaxNbrOfNPduPerCycle | 0 – 31 | This parameter is part of the ISO 10681-2 protocol’s FlowControl parameter “Bandwidth Control (BC)”. It limits the number of N-Pdus the sender is allowed to transmit within a FlexRay cycle. | 7 |
| FrTpMaxRn | 0 – 255 | This parameter sets the maximum number of retries (if retry is configured). | 0 |
| FrTpSCexp | 0 – 7 | This parameter is a component of the ISO 10681-2 protocol’s FlowControl parameter “Bandwidth Control (BC).” It denotes the exponent used to determine the minimum number of “Separation Cycles” the sender must wait for the next transmission of an FrTp N-PDU. | 3 |
| FrTpTimeBr | 0 – 0.255 | This parameter specifies the time, measured in seconds, that FrTp needs to transmit a corresponding FlowControl Frame. As per ISO 10681-2 standards, this parameter represents a performance requirement. | 0.25 |
| FrTpTimeBuffer | 0 – 65.535 | This parameter sets the duration, measured in seconds, for waiting to attempt acquiring a Tx or Rx buffer again. | 0.0 |
| FrTpTimeFrIf | 0 – 0.255 | This parameter determines the duration, measured in seconds, of waiting for the next attempt (if retry is enabled) to transmit via FrIf_Transmit. | 0.0 |
| FrTpTimeoutAr | 0 – 65.535 | This parameter specifies the timeout duration in seconds between the PDU transmit request from the Transport Layer to the FlexRay Interface and the corresponding confirmation from the FlexRay Interface on the receiver side (for FC or AF). | 0.1 |
| FrTpTimeoutAs | 0 – 65.535 | This parameter determines the timeout duration, measured in seconds, within which FrIf must confirm a transmitted PDU to FrTp. | 0.1 |
| FrTpTimeoutBs | 0 – 65.535 | This parameter sets the timeout duration, measured in seconds, for waiting for an FC or AF on the sender’s side in a 1:1 connection. | 0.04 |
| FrTpTimeoutCr | 0 – 65.535 | This parameter specifies the timeout duration, measured in seconds, that a receiver waits for a CF or a LF. | 0.8 |
| FrTpMaxBufReq | 0 – 255 | This parameter is employed to restrict the number of retries for PduR_FrTpCopyTxData when no timer is active. | 255 |
Future development and enhancement of the FlexRay-TP protocol timing parameters entails refining and optimizing various aspects to improve communication efficiency and reliability. This process involves careful analysis and adjustment of parameters such as frame timing, message scheduling, and response times to accommodate evolving system requirements and technological advancements. By continuously fine-tuning these parameters, engineers can ensure better performance, reduced latency, and enhanced scalability for FlexRay-based communication systems in automotive and other industries.
Discover more from PiEmbSysTech
Subscribe to get the latest posts sent to your email.
I really appreciate this Flexray tp protocol article how it explained in a way that fresher to professional engineers can understand and work and implement in their company. Either it is AUTOSAR or Non-AUTOSAR Based project, everyone can understand and implement this in their project.This FlexRay ISO Transport Layer protocol was very complex for me to understand, but i understood well after going through PiEmbSysTech Tutorial. Thank you so much for giving that much deep level of knowledge.