I-PDU Multiplexer (IPduM) Overview and Transmission

I-PDU multiplexing is the ability to use the same PDU to communicate with a different layout of I-Signals / I-PDUs, according to a selector field, setting the contents of the I-PDU, hence, shaping the SDU. This is performed by the IPduM, which in the sending process combines I-PDUs coming from the COM and passed to it by the PDU Router, returning a container / multiplexed PDU to the PduR, and in the reception separates a container / de-multiplexed I-PDU into multiple I-PDUs, forwarding each of them to the PduR.

This module sits between the COM and the PDU Router. Therefore, if your skills on both these modules are lacking, we recommend having a read into out posts about the COM and the PDU Router COM Signal Transmission and Reception Overview (opens in a new tab) and Demystifying Autosar PDU Router: A Comprehensive Guide to Routing, Handling, and Buffering (opens in a new tab), respectively. There are more. You can click on the tags to find them all.

IPduM (I-PDU Multiplexer) Interaction With Other BSW Modules

As you can see in the picture below, the PduR is the connection point for the I-PDU Multiplexer with the remainder of the Autosar communication stack, although the COM is also involved:

The interaction between the I-PDU Multiplexer and other BSW modules

The PduR provides the contained / multiplexed I-PDUs for sending, along with the necessary transmission, transmission confirmation and trigger transmission interfaces, getting in return from the I-PDU Multiplexer container / de-multiplexed I-PDUs that can be transmitted over the underlying bus interface. For reception, the PduR forwards container I-PDUs through the reception indication interface, which the IPduM multiplexes / separates its respective I-PDU or a contained I-PDUs and issues a reception indication for each of them individually to the PDU Router. For all this, the PduR contains a record of all the contained and container I-PDUs.

As for the COM, it uses the multiplexed / contained I-PDUs individually. Although it usually does not interact directly with the IPduM, it is possible to make the reception indication and transmission confirmation flow directly from the IPduM to the COM (without the PDU Router in the loop), by enabling the IpduMRxDirectComInvocation Boolean parameter. This results in a more resource-efficient implementation.

Lastly, it also interacts with the DET for error reporting and contains cyclic functions which are mapped to the BSW scheduler inside the RTE. For the latter, the IPduM can be distributed among multiple partitions, facilitating communication with the underlying bus technologies while avoiding inter-partition communication. This means there will be multiple main functions for the IPduM (with independent time bases from each other), distributed throughout the partitions where the module is relevant.

I-PDU Multiplexing and Multiple PDU to Container Mapping

An I-PDU dealt by the IPduM can essentially be a container or a de-multiplexed I-PDU. They correspond to the following:

• Multiplexed I-PDU – Using a single I-PDU to transmit one of multiple possible I-PDUs.

• Container I-PDU – Grouping multiple, smaller I-PDUs into one larger I-PDU, to take advantage of large frame sizes found on newer bus technologies.

Multiplexed I-PDU

A multiplexed I-PDU is comprised of a static and a dynamic part, each of them containing one or multiple signals. Along with them, the dynamic part includes a selector field, which sets the layout of the I-PDU. There can only be one selector field (hence, only one dynamic part) per I-PDU, and its size can range from 1 to 16 bits. The selector field is present in the I-PDU from the COM as a signal, which is initialized with the respective selection number and not altered afterwards. The IPduM also needs to consider the IPduMByteOrder when parsing the selector field.

Moreover, the static and dynamic parts can appear fragmented into segments, and their position is configurable, but they must appear in the same position and have the same length for all the possible I-PDU layouts. The selector field is placed in the first dynamic segment.

Lastly, the multiplexed I-PDU combines at most two I-PDUs (as seen in the figure below): one for the static part and another for the dynamic part selected.

A multiplexed I-PDU handled by the I-PDU multiplexer, with a static and a dynamic part

Container I-PDU

The container I-PDU englobes multiple contained I-PDUS, which can be statically or dynamically set, where the latter places an extra header before each contained I-PDU. In the former, the position of each contained I-PDU is defined statically, where the latter relies on the DLC of the container I-PDU and the lengths specified in the header of each contained I-PDU. No extra padding is added between each of the contained I-PDUs for a dynamic container I-PDU. A container I-PDU can be observed in the following picture:

A container I-PDU handled by the I-PDU multiplexer, in its two possible forms, for static and dynamically set I-PDUs

The header can be short (24 bits ID and 8 bits length) or long (32 bits ID and 32 bits length), and is set per container I-PDU, through the parameter IpduMContainerHeaderSize. A static container I-PDU is defined by setting this value to IPDUM_HEADERTYPE_NONE. These values are parsed according to the IpduMHeaderByteOrder parameter. Lastly, if a header ID of zero is present, it indicates the end remainder of the container I-PDU has been filled with padding bytes and everything from that point on can be discarded.

I-PDU Multiplexer (IPduM) Normal Operation

IPduM Initialization

The IPduM initialization is carried out by the IpduM_Init function, which sets its internal variables and I-PDU buffers. Any other IPduM function call prior to initialization (except the main functions IpduM_MainFunctionTx, IpduM_MainFunctionRx and IpduM_GetVersionInfo) will result in the error IPDUM_E_UNINIT, which can be reported to the DET.

Regarding buffer initialization, this is important because it is possible that the container or multiplexed I-PDU gets sent before the COM fills the entire buffer. The buffer gets initialized with a pattern at first, via the IpduMIPduUnusedAreasDefault parameter, then with the initial signal values from the COM are taken, if available, via the references to its I-PDUs located in the static part (IpduMTxStaticPart) and the initial dynamic part (IpduMInitialDynamicPart) containers.

IPduM Transmission of a Multiplexed I-PDU

The transmission of a multiplexed I-PDU (as seen in the picture below) involves the assembly of the static and the selected dynamic parts, within the IpduM_Transmit API, coming in from the PDU Router as two different I-PDUs, into a single I-PDU with its own I-PDU ID, which can be given back to the PduR in the form of a transmission request, depending on the configuration of the IpduMTxTriggerMode parameter.

The trigger can be the reception of a static part, the reception of a dynamic part (it can occur that the non-triggering part gets overwritten multiple times before sending the multiplexed I-PDU), either of them (this is why the initialization values are important, as one of them will not have been sent by the COM) or no trigger, in case the IpduM_TriggerTransmit functionality is used by the lower layer to issue a transmission request. The latter requires the IpduMTxConfirmationPduId to be configured, to receive the transmission confirmation.

Transmission of a multiplexed I-PDU throught the IPduM, via upper layer transmission

IPduM Transmission of a Container I-PDU

The transmission trigger condition for a container I-PDU is spanned over multiple parameters, as this can be based on a time (for both container and contained I-PDUs) or length threshold (for the container I-PDU) or triggered over each of the contained I-PDU that arrives on the IPduM. Moreover, the first I-PDU container trigger is also handled separately. The available parameters and their behaviour are described in the table below:

For the transmission of container I-PDUs, there are two IpduMContainedTxPduCollectionOptions for each of the contained I-PDUs (which have to be exact the same value for all the contained I-PDUs of a given container I-PDU):

• IPDUM_COLLECT_LAST_IS_BEST – Transmission requests are stored. Right before the container I-PDU is sent, the data of each contained I-PDU will be requested to the PDU Router. Static container I-PDUs can only use this option.

• IPDUM_COLLECT_QUEUED – The contained I-PDU will be stored by the I-PDU Multiplexer. In case the contained I-PDU would make the container I-PDU larger than its maximum length, the current instance of the container I-PDU is triggered for transmission and the contained I-PDU is placed in a new instance of the container I-PDU. The same contained I-PDU can also be present multiple times inside the same container I-PDU instance.

Before a transmission to the lower layer occurs (which always comes through the PduR_IpduMTransmit API), the I-PDU Multiplexer needs to assemble the container I-PDU, according to the selected configuration of the IpduMContainerTxTriggerMode, which can be IPDUM_DIRECT or IPDUM_TRIGGERTRANSMIT.

Transmission of a container I-PDU throught the IPduM, via upper layer transmission (considering IPDUM_COLLECT_QUEUED and IpduMContainerTxSizeThreshold)

Closing Thoughts

This is the essential information you need to get started on understanding the I-PDU Multiplexer and leveraging it in your projects. Keep in mind, there is a bit more to it, especially when it comes to the container I-PDUs (and we have not touched in the reception, although it is basically the opposite process rolling out), but we will cover these in a future post or even on the upcoming books about Classic Autosar. Are you on the waiting list yet? Then what are you waiting for?

If you are unsure what to learn next, have a read on our extensive coverage of the COM module. It is always a good read! See you next time.

Author: Micael Coutinho (opens in a new tab)

References:

• Specification of I-PDU Multiplexer (opens in a new tab)