COM Signal Transmission and Reception Overview
In this article, we will look at the actions that take place within the COM upon transmission and reception of signals / signal groups. Remember that internal communication (communication between Software Components within the same ECU) is handled by the RTE in Autosar, so we do not have to worry about it here. We will view the entire process for the transmission and reception of signals between different ECUs.
COM Transmission
In the figure below, the transmission of messages / signals is described. There are three entities responsible to trigger transmission-related actions within the COM: the APIs Com_SendSignal and Com_SendSignalGroup and the signal-based gateway (the latter can have a say on both transmission and reception).
Upon any of these actions, the signal update bits are set, the endianness conversion and sign extension are taken care of and the I-PDU gets filled with the signal data after that processing. Intermediately, a shadow buffer can be filled for signals that are part of a signal group.
Then, depending on the signal transfer properties and I-PDU transmission mode selection or the API call Com_TriggerTransmit via the PduR, the I-PDU will be sent out of the COM via the PduR, through the API PduR_ComTransmit (after the I-PDU callout is triggered), obeying to the I-PDU MDT (Minimum Delay Time) monitoring.
Feedback from the PduR by the means of the API Com_TxConfirmation is then awaited, in close oversight by transmission deadline monitoring. In the end, either transmission deadline monitoring or ComTxConfirmation will deliver a notification, Com_CbkTxTOut or Com_CbkTxAck, respectively.
Overview of the COM Transmission Process
COM Reception
Reception is started by the Com_RxIndication API call. At the same time, reception deadline monitoring is running and can be restarted via this call or trigger the callback Com_CbkRxTOut, if the message does not arrive within the expected time.
When an I-PDU is received, the optional I-PDU callout is called. Then, the endianness conversion and sign processing take place for each signal, the value is checked both for the update-bits (if it uses them and the signal has not been updated, it is discarded) and to verify it is not an already-defined invalid signal value (in that case further actions will take place, including the possible callout Com_CbkInv to be triggered) and these are filtered according to the filter configuration. Only after going through filtering deadline monitoring for the signal can be reset.
The callout Com_CbkRxAck can also take place and the data can also follow to the signal-based transmission gateway, to be transmitted again through the PDU Router. Lastly, the signal values are updated, and the shadow buffers for the signal groups too. When the signals are being consumed by the application, via the APIs Com_ReceiveSignal or Com_ReceiveSignalGroup, the signal values are consumed.
Overview of the COM Reception Process
So, that's it. This is the process of sending and receiving messages from the COM module. If this article sparked your interest on how signals and signal groups can be defined, a good place to go next is our post about Exploring ISignal and ISignalGroup Definitions in Autosar ARXML (opens in a new tab). There, you will learn how to define I-Signals and I-SignalGroups, essential for your Classic Autosar journey.
Lastly, do not forget to join the waiting list for our upcoming e-books!
Author: Micael Coutinho (opens in a new tab)
References:
© AutosarToday —@LinkedIn