COM I-PDU Groups - Overview and Configuration

In this post, you will learn about I-PDU groups in all of their glory! We will start by characterizing an I-PDU group and the rules behind them. After that, we will see what happens when an I-PDU group is started and stopped and how that can be done.

During this article, we will connect with a wide array of topics already taught in previous articles. So we recommend you take a look into COM Signal Transmission and Reception Overview (opens in a new tab), COM - Demystifying I-PDU Transmission Modes (opens in a new tab) and COM Signal Retransmission and Retry (opens in a new tab) as a good starting point.

What are I-PDU Groups

I-PDUs can be associated together in the COM, as so called I-PDU groups. This allows them to be managed (started and stopped) as a group. I-PDUs can belong to zero or many I-PDU groups and are started if any I-PDU group which they belong to is started (by default, all I-PDU groups are stopped upon COM initialization) or if they belong to no I-PDU group and the COM is initialized (they can never be stopped too).

Starting and Stopping I-PDU Groups

An I-PDU group can be started or stopped via the APIs Com_IpduGroupStart and Com_IpduGroupStop, respectively. Signals / signal groups can only be sent or received if the I-PDU group they belong to is started. Also, the maximum number of I-PDU groups is statically defined by the parameter ComSupportedIpduGroups. Lastly, I-PDU groups can only contain I-PDUs of the same direction (sending / reception).

This is what happens when an I-PDU is started through the start of its I-PDU group:

• ComMinimumDelayTime is initialized for the I-PDUs in the DIRECT or MIXED transmission modes.
• Reception deadline monitoring is restarted for signals with a ComFirstTimeout value larger than zero. An important note, reception deadline monitoring is enabled per I-PDU group, so it will only be enabled if the I-PDU group enables it.
• Transmission deadline monitoring is cancelled, and the first transmission timeout will be given by ComFirstTimeout.
• All update bits will be cleared.
• The OCCURRENCE parameter will be reset of the signals using the ComFilterAlgorithm ONE_EVERY_N.
• Its transmission mode is determined immediately by its initialization data or its current values.

Moreover, the Com_IPduGroupStart API can perform more actions, if its Initialize parameter is set to true:

• The data of the I-PDUs will be initialized with the respective ComSignalInitValue or each signal. If the parameter is set to false, the last value is used for initialization, which can be different from the ComSignalInitValue in case the APIs Com_SendSignal, Com_SendSignalGroup or Com_InvalidateSignal are called beforehand.
• The shadow buffers of signal groups are initialized.
• The OLD_VALUE of filtering mechanisms is initialized with ComSignalInitValue.
• The parameters ComTxModeTimePeriod and ComTxModeTimeOffset of PERIODIC or MIXED transmission modes are initialized.

When an I-PDU group is stopped, the following actions occur for the group:

• An API call to Com_SendSignal, Com_SendSignalGroup or Com_InvalidateSignal will result only in an internal buffer value update but will return COM_SERVICE_NOT_AVAILABLE.
• Calls to Com_ReceiveSignal and Com_ReceiveSignalGroup will return COM_SERVICE_NOT_AVAILABLE and give back the last known value.
• Transmissions in progress and further requests are stopped, and the ComErrorNotification is invoked right away.
• Reception of the group I-PDUs will not be processed.
• Deadline monitoring stops and transmission confirmations are ignored.
• Com_TriggerTransmit will result in E_NOT_OK.

Configuration of I-PDU Groups

I-PDU groups are referenced by each ComIPdu individually inside the COM configuration parameters, as you can see in the picture below (do not worry, we will come back to this picture in a future post):

COM configuration parameters for a ComIPdu container

The ComIpduGroup container itself is quite simpler, containing the following elements:

• ComIPduGroupHandleId – Unique ID for the I-PDU group.
• ComIPduGroupGroupRef – Optional reference to other I-PDU groups this group belongs to, enabling the hierarchical representation of them.

COM configuration parameters for a ComIPduGroup container

Ending Notes

Now that we are reaching the end of this post, I want to mention we will also explore the different COM Filters, COM I-PDUs and other intricate elements in the future, so make sure to stay tuned for that, by following our LinkedIn (opens in a new tab).

If you want to learn more about Classic Autosar in general, we are working on a set of eBooks, which intend to revolutionize the Autosar learning experience and make it way more approachable. So far, I am very excited about how it is turning out, but unfortunately it is still a long way out. You can stay updated and receive a sweet discount when the first eBook is ready by joining the waiting list on top of the page! And no, you will not receive any other promotional emails. See you then!

Author: Micael Coutinho (opens in a new tab)

References:

• Specification of Communication - Autosar (opens in a new tab)