COM Signal Retransmission and Retry
In this post, we will delve into retransmission and retry of COM Signals. Let us start with a question in which cases does a retransmission or a retry (or even both) take place? There are three variables to take into consideration: the ComTxModeMode selected, the return value of PduR_ComTransmit and the configuration of the parameters ComTxModeNumberOfRepetitions and ComRetryFailedTransmitRequests. Below, we will go through each of them, how they overlap and how they influence the overall COM behavior.
COM Retransmission via ComTxModeNumberOfRepetitions
If our selected ComTxModeMode is DIRECT or MIXED (if you need some help with transmission modes and the COM, please refer to our article COM - Demystifying I-PDU Transmission Modes (opens in a new tab) for more information), we configure the parameter ComTxModeNumberOfRepetitions, resulting in a transmission of 1 + its value of the I-PDU, as mentioned before.
PduR_ComTransmit will be called the selected number of times periodically (the period is defined by the parameter ComTxModeRepetitionPeriod), until we receive the same number of confirmations from the PduR (to learn more about the PDU Router, you can read our article Demystifying Autosar PDU Router: A Comprehensive Guide to Routing, Handling, and Buffering (opens in a new tab)).
If we receive a new transmission request from the application, the retransmissions are cancelled for the given I-PDU and the process is restarted with the new values. Although PduR_ComTransmit can return E_NOT_OK, COM will ignore this value and continue the process until it receives the desired number of confirmations or deadline monitoring is triggered (which in this case no more transmissions will occur), issuing more than the number of transmissions necessary in order to achieve this goal. If in the MIXED mode a periodic transmission occurs in the middle of this process, it will count for the number of transmissions. Lastly, a start-up time offset can be configured to avoid the buffering of too many transmission requests after startup. This process is illustrated in the figure below:
Impact of ComTxModeNumberOfRepetitions in the COM Retransmission Behavior
COM Retry Through ComRetryFailedTransmitRequests
In case the parameter ComRetryFailedTransmitRequests is set to true (as illustrated in the picture below), the COM will check if the return value of PduR_ComTransmit is E_NOT_OK (keep in mind, not all lower layers support the confirmation of transmission requests, so this can only be configured for those that do) and issue a new transmission request on the next call of the cyclic Com_MainFunctionTx function, for a multiple number of retries until a timeout occurs. If the data is updated in the meantime, it will be sent on the retry. This operation does not affect the repetition mechanism we stated before and is not blocked by the repetition period selected via ComTxModeRepetitionPeriod.
Impact of ComRetryFailedTransmitRequests in the COM Retry Behavior
COM MDT (Minimum Delay Timer) to Control Excessive Requests
If you have worked with OSEK, this will sound familiar to you. On its interaction layer (which serves as the base for the Autosar COM) there was an MDT (Minimum Delay Timer) on the OSEK COM, blocking us from sending multiple transmission requests without obeying to it. This option still exists in the Autosar COM. It can be enabled through ComEnableMDTForCyclicTransmission and its value can be configured individually for each I-PDU via the parameter ComMinimumDelayTime.
The MDT does not apply for failed transmission requests and is restored when either a successful confirmation occurs, or a monitoring timer expires. Moreover, since the MDT is initialized when an I-PDU is started, it is possible to exploit it, by stopping and starting the I-PDU successively.
COM Transmission Deadline Monitoring
Regarding transmission deadline monitoring, it is used to oversee the lower layers the COM interacts with, at least those that support transmission confirmation. It starts when a signal or signal group is requested to be sent from the upper layers and not usually restarted or reset when running. Its value is configured per signal / signal group, through the parameter ComTimeout or ComFirstTimeout (for the first timeout when deadline monitoring is started).
The underlying I-PDU then uses the smallest timeout value configured between all of its associated signals / signal groups (if you configure deadline monitoring for the signal group, no signal belonging to the group can configure its own deadline monitoring). When a transmission confirmation is received, all the signals associated with the I-PDU get their transmission deadline monitoring timers cancelled.
When a timeout occurs, you can optionally cancel the transmission of further I-PDUs via the parameter ComIPduCancellationSupport, which will call PduR_ComCancelTransmit. Furthermore, if a ComTimeoutNotification is configured, it will be called at this point too. Keep in mind that if you cancel the transmission within an I-PDU callout, the notification will take place regardless. The only condition for notification is a deadline monitoring timeout.
In case I-PDU retransmission should take place, the monitoring timer will be cancelled after the successful confirmation of N + 1 transmissions and reset when the transmission is requested while retransmission is already taking place.
Ending Points
Now that you know how the Autosar COM handles the retransmission and retries of transmission requests based on the different transmission modes, why stop now? If you are looking for a good read on the same topic, I recommmend two of our recent pieces, namely COM Signal Transmission and Reception Overview (opens in a new tab), where we trace the path of a Signal and a PDU throughout the Communication Stack, and Exploring ISignal and ISignalGroup Definitions in Autosar ARXML (opens in a new tab), which will guide you through the necessary parameters for defining I-Signals and I-Signal-Groups in ARXML. Make sure to add yourself to the waiting list for our upcoming ebooks, if Autosar interests you!
Author: Micael Coutinho (opens in a new tab)
References:
© AutosarToday —@LinkedIn