What is IPDUM in Autosar? How multiplexing is performed for multiple IPDUs?

3.2k Views Asked by At

While reading about ComStack in autosar I came to know about IPDUM module. I read technical reference but its still not clear about functionality of IPDUM and how the multiplexing takes place with different IPDUs. I know about Multiplexing/Demultiplexing or Selector fields but how is this linked here?

1

There are 1 best solutions below

0
kesselhaus On

The AUTOSAR_SWS_IpduM (Chapter 7) and the AUTOSAR_TPS_SystemTemplate (Ch. 6.5) explain this I think pretty well.

IpduM lower layer connects to PduR. So reception/transmission of the MultiplexedIPdu.

IpduM higher layer connects to Com either:

  • directly (optimization option in IpduM)
  • over PduR

There will be a ISignalIPdu for the static part, and one ISignalIPdu for each dynamic part of the MultiplexedIPdu in Com. The selector is even added to each ISignalIpdu-ID. For transmission, a trigger of one of the dynamic ISignalIpdu in Com will forward to IpduM which will also add the ISignalIPdu of the static part to the MultiplexedIpdu.

For reception, there will be an RxIndication of the dynamic ISignalIpdu and the static ISignalIpdu in Com.

So, in Com you just handle the ISignalIPdus as each other ISignalIPdu, without worrying about if they are multiplexed or not. You can even monitor the timeout of each dynamic part separately there in Com.

So, you just have to update the ISignals/ISignalGroups by application, which will update the Com-Buffers, and Com/IpduM will decide when and what to send according to the configuration.

Though, my experience in this field is, that a lot of developers can not really abstract the application and its ports/interfaces and the mapping to Signals and SignalGroups in RTE, signals/signalgroups and the reception/transmission model in Com, from lower layer frames/PDUs (or formerly messages). Seen this in former projects using (or rather not using IL) in e.g. Vector CANbedded, or now with AUTOSAR Com.

This is then the reason, the application components have to be touched and rewritten all the time, because they depend so much on the signals of the vehicle communication description. And I have even seen "application components" too often actually work around the transmission/reception model in Com (or IL) by reimplementing the transmission requests or doing timeout monitoring themselve.