PDU Router#1, AUTOSAR BSW

13 min readSep 22, 2020

PDUR module provides routing services of I-PDUs for COM and DCM modules using communication interface modules (like CanIf, LinIf and FlexRayIf) and transport protocol modules (like CanTp and FlexRayTp). Role of PDUR is limited to only routing, it cannot modify I-PDU or perform any checks of the data. It also provides gateway service for I-PDUs. It can route I-PDUs from one source bus (CAN, FlexRay, Lin) to one or more destination bus.

Here we will be looking at PduR w.r.t only CAN module I-PDU reception, transmission and gateway, i.e it will involve only CanIf, CanTp. Gateway and routing for other lower layer modules like Flex Ray, LIN and Ethernet will be excluded from the discussion. This is to keep the discussion concise.

The APIs for the Transport Protocol modules was redesigned in AUTOSAR release 4.0. Therefore the APIs are not directly backwards compatible with AUTOSAR release 3.1 and older releases. Here we will be looking at PduR in AUTOSAR version 4.2.2

Position in BSW

The most common combination of upper and lower layer modules that use PduR are:

DCM and Transport Protocol modules as upper layer modules
COM and Communication Interface modules/ Transport Protocol Modules / I-PDU multiplexer module as lower layer modules.

List of possible interactions for PduR

Limitations of PduR module

For Network Management data exchange the PDU Router module is bypassed.
PduR cannot extract or apply conversions to the signals of the I-PDU.
It cannot perform integrity checks on the I-PDU.
PDUR cannot make routing decisions based on the contents of the I-PDU.
It cannot modify the contents of the I-PDU in any way.
It cannot route I-PDUs between transport protocol modules and the interface modules.

Functional Specifications

From the ECU point of view, the PDU Router module can perform three different classes of operations:

PDU Reception to local module(s): receive I-PDUs from lower layer modules and forward them to one or more upper layer modules,
PDU Transmission from local module(s): transmit I-PDUs to one or more lower layer modules on request of upper layer module,
PDU Gateway:
receive I-PDUs from an interface module and transmit the I-PDUs immediately via the same or other communication interface module(s)
receive I-PDUs from a transport protocol module and transmit the IPDUs via the same or other transport protocol module(s).

Let us look into each of this operations one by one.

I-PDU reception to upper modules

Reception can take place from either a Communication Interface module like CanIf or the Transport Protocol module like CanTp. The behaviour is same in both the cases. PduR copies incoming I-PDU from the lower layer to one or more upper layers that are registered with I-PDU.

I-PDU reception from Communication Interface module

PduR provides 1:n routing for communication interface modules and shall forward the I-PDU to every destination module.
PduR calls < Up >_ RxIndication() of each receiving module when the communication interface module calls PduR_< Lo >RxIndication().

I-PDU reception from Transport Protocol module

Reception of I-PDU through Transport Protocol module may have only one upper layer module for the routing path.
Start of reception: when PduR is notified of an incoming reception by the transport protocol module calling PduR_< LoTp >StartOfReception(), it notifies the upper layer by calling < Up >_StartOfReception()
Copying data: when data is being copied from transport protocol module to PDUR, PduR< LoTp >CopyRxData() the data gets copied to upper layer by calling < Up >_CopyRxData()
Receive Indication: any receive indication received by PduR_< LoTp >RxIndication() is forwarded to upper layer by calling < Up > _ RxIndication().
Any error or return value generated by the lower Transport Protocol module layer or the upper layer is propagated by PduR.

I-PDU transmission from upper modules

I-PDU transmission using Communication Interface module

There are three ways for I-PDU transmission using communication interface

Direct data provision : In this case the upper module triggers the transmission by calling PduR_< Up >Transmit() . PduR then forwards the I-PDU to lower layer by calling < Lo > _ Transmit().
Trigger transmit data provision : In this case transmit is triggered by the lower layer. PduR_ < Lo >TriggerTransmit() is called by the lower layer and the request is forwarded by PduR to the upper layer by calling PduR_< Up >TriggerTransmit(). On receiving the request upper layer then lets PduR copy the data. Any return value from upper layer is copied to the lower layer.
Mixed (not the official terminology, but still makes sense): In this case the upper module triggers the transmission as in the case of direct data provision but the lower layer module does NOT copy the data, instead it requests the data later by calling PduR_< Lo >TriggerTransmit().
The transmission confirmation is same for all the transmission types. The interface module calls PduR_< Lo >TxConfirmation() and then PduR calls < Up >_TxConfirmation().
PduR has no specific error handling mechanism. It only forwards the return value from the lower layer to the upper layer.

I-PDU transmission using Transport module

Transmission of I-PDU using transport module can be of two types, singlecast (from one source module to one transport module) or multicast ( from one source module to multiple transport modules ).

Upper module will initiate the transmission by calling PduR_< Up >Transmit().
PduR calls the relevant transport modules by calling PduR_< LoTp >Transmit().
Transport module then copies the data from PduR by calling PduR_< LoTp >CopyTxData() and then PduR in turn copies the data from upper layer by calling < Up >_CopyTxData().
The return value from the < Up >_CopyTxData() is forwarded to the lower layer destination module.
The transmit confirmation is copied from lower layer PduR_ < LoTp >TxConfirmation() to upper layer by < Up >_TpTxConfirmation().
In case of multicast transmission, the data needs to be copied to multiple transport modules. PduR_< LoTp >CopyTxData() is called for each transport module and the transmit confirmation is sent to the upper layer only when PduR has received the transmit confirmation from all transport modules.
The result of multicast transmit is E_OK if at least one transport module reports E_OK.
RetryInfoPtr contains a state called TpDataState. This used to copy data to multiple transport modules. When copying the data for the first time, TpDataState = TP_CONFPENDING and when the data is being copied to other modules the state is changed to TpDataState = TP_DATARETRY.
Similar to communication interface there is no error handling done in PduR. Only the return values are passed along.

Multicast I-PDU transmission

There are two cases of multicast transmissions

When an I-PDU ID represents a group of I-PDUs

The transmission can be direct or by trigger transmit.
If at least one of the transmit request returns E_OK, PduR will send PduR_< Up >Transmit() with E_OK.
The transport modules that return E_NOT_OK will not copy the data with PduR_< LoTp >CopyTxData().

2. When there are multiple lower layer destination modules

All the destination modules should be either communication interface modules or transport protocol modules, it cannot be a mix of both.
When multiple communication interfaces are involved, PduR will call the transmit confirmation of the upper layer module as soon as the first transmit confirmation is received.

Gateway

PduR supports gatewaying of I-PDUs from one bus to another. For example an I-PDU received on CAN can be forwarded to LIN or FlexRay. Gatewaying is allowed in between communication interfaces and in between transport modules, but not in between a communication interface and a transport module. An I-PDU received on CAN IF can be gatewayed to LIN IF or FR IF not to LIN TP or FR TP.

Lets look at these in some more detail.

Communication interface gateway

When an I-PDU is being gatewayed to a communication interface, it can also be simultaneously received by an upper layer module.

PduR supports immediate routing for IPDU between communication interfaces having the same period or rate. Routing between communication interfaces with different periods is done in COM module using signal gateway and is not handled by PduR.

Data Provision for communication interface gateway

There are two flavours of gatewaying depending on the interface module.

Direct Data Provision: The communication interface module copies the data directly when < DstLo >_Transmit() is called. The configuration parameter, PduRDestPduDataProvision = PDUR_DIRECT.

2. Trigger Transmit Data Provision: The communication interface module does not copy the data when < DstLo >Transmit() is called. PduR module buffers the I-PDU and waits for the lower layer module to call PduR_< DstLo >TriggerTransmit(). PduR buffers the I-PDU for the lower layer. The buffer strategy is set by the configuration parameter PduRTxBufferDepth. The configuration parameter PduRDestPduDataProvision = PDUR_TRIGGERTRANSMIT.

Buffer allocation for communication interface gateway

The I-PDU of each destination bus can be buffered. But this buffer is only for the communication interface module not for the local module. There are two buffering strategies

Last is best buffering : Only the last received I-PDU is buffered. Configuration parameter PduRTXBufferDepth = 1
FIFO buffering : A FIFO buffer is maintained by PduR. Configuration parameter PduRTXBufferDepth > 1.
For Direct Data Provision an I-PDU is buffered in FIFO only when PduR _< SrcLo >RxIndication() is received before the last transmission of the I-PDU has not been confirmed by PduR _< DstLo >TxConfirmation() for the I-PDU. If the confirmation has been removed before indication of a new reception the I-PDU is transmitted without buffering.
For Trigger Transmit Data Provision: When receive indication is received, the I-PDU is copied to the FIFO and PduR_ < DstLo >Transmit() is called. When the lower module then calls the PduR_ < DstLo >TriggerTransmit() it copies the data from FIFO.

Error handling for communication interface gatewaying

If one of the destination interface modules fails (returns E_NOT_OK) after calling < DstLo >Transmit(), PduR will not retry transmission for the interface and simply move on to the next communication interface.
If transmitting an IPDU from the FIFO buffer fails, the next buffer entry will be used.
If the FIFO is full and a new I-PDU is received, the FIFO gets flushed, and the FIFO is now treated as empty. The newly received FIFO is served and not discarded.

Transport Protocol module gateway

There are two types of gatewaying, direct (complete set of N-PDUs building up the I-PDU) and on-the-fly (fragmented I-PDU).
Both single frame message and multi frame message can be gatewayed to multiple transport modules or local modules.
If a I-PDU is transported in multiple N-PDUs, gatewaying is done “on-the-fly”. The complete I-PDU does not need to be received for gatewaying. Also, in this case the gatewaying can be done to either transport protocol module or the local module, but not both.
When I-PDU is being transmitted as a single N-PDU, can it be received by both the local and Transport Protocol module module.

Buffer allocation for transport protocol gateway

PduR uses two different buffers for gatewaying of transport protocol modules. A large pool of buffers configured via PduRTpBufferTable and a small dedicated buffer configured via PduRDestTxBufferRef.
The dedicated buffer is used for routing SF and must be large enough for the largest possible SF of the involved bus systems.
The buffer table is used for direct and on-the-fly gatewaying. This buffer should be large enough to contain one block of TP data in case of on-the-fly gatewaying and for the complete PDU in case of direct gatewaying.
The total size of the SDU is reported in the TpSduLength of the PduR_ < Src LoTp > StartOfReception call. If the size is more than the configured PduRPduMaxLength, then PduR shall dynamically allocate buffer from the buffer table configured via PduRTpBufferTable. If the size is less than PduRPduMaxLength then the dedicated buffer is used.
If no buffer has been allocated during the call of PduR_ < SrcLoTp >StartOfReception() then PduR shall terminate the further processing and return the value BUFREQ_E_OVFL.

Direct Gatewaying for transport protocol modules

For every call to PduR_ < SrcLoTp >StartOfReception(), < DstLoTp >_ Transmit( ) is called for each of the target transport modules.

For a SF transmission, if PduR_< DstLoTp >CopyTxData() is called with TpDataState TP_CONFPENDEING or TP_DATACONF or TP_DATARETRY.

TP_CONFPENDEING or TP_DATACONF or RetryInfoType pointer is NULL : PduR shall copy SduLength bytes of data.
If enough data is not available, PduR shall return BUFREQ_E_BUSY and not copy any data.
TP_DATARETRY : PduR shall set back the current position by TxTpDataCnt bytes and copy SduLength bytes of data.
If PduR cannot set the position back, it will change the current position and not copy any data, also return BUFREQ_E_NOT_OK.
If after resetting the current position, enough data is not available to copy, it will not copy any data and return the BUFREQ_E_BUSY.

2. For MF transmission, if PduR_< DstLoTp >CopyTxData() is called with TpDataState TP_CONFPENDEING or TP_DATACONF or RetryInfoType pointer is NULL :

PduR shall copy SduLength bytes of data.
If not enough data is available or all other destination transport protocol modules have called PduR_< DstLoTp >CopyTxData() for the previous frame, the Pdu Router shall return BUFREQ_E_BUSY without copying any data.
Only the call from last destination module shall increase the buffer position.
TP_DATARETRY : PduR shall return BUFREQ_E_NOT_OK without copying any data.

On-the-fly gatewaying for transport protocol module

There can be only one destination module when gatewaying is on the fly.
Also, PduR does not support retransmission in case of on the fly gatewaying.
Configuration parameter PduRTpThreshold is used to control the number of bytes that of incoming message that must be received for transmission to start.
PduR will initiate transmission to destination transport module by calling, < DstLoTp >_ Transmit() as soon as the Tx threshold size has been reached.

Forwarding to upper layers

When a PDU is being gatewayed to transport protocol modules, this I-PDU can also be forwarded to the upper layer module at the same time. While doing so, if the local upper layer module fails to receive the I-PDU it does not affect the gatewaying process.

When the gatewaying being done is direct gatewaying, on receiving an RxIndication for an I-PDU, PduR executes the reception sequence. < UpTp >_ StartOfReception(), < UpTp >_ CopyRxData(), < UpTp >_ RxIndication(). Any error generated will result in terminating the reception for the local module.

When gatewaying on the fly is being used, there can be only one destination transport protocol module. In this case there cannot be a simultaneous forwarding to local upper layer module.

Error handling

All the error handling is done by transport protocol module, PduR does not perform any error handling.
If any one of the destination transport protocol modules fails, gatewaying continues unhindered for other transport protocol modules. Only if all the transport protocol modules fail reception side will be stopped by returning BUFREQ_E_NOT_OK for the current call to StartOfReception or CopyTxData.

Lets look at some examples of gateway. Flow diagrams are very much self explanatory, so I will not explain them again here.

Routing Path groups of I-PDUs

A routing path group is a group of I-PDUs that can be disabled and enabled during runtime. The group contains the destination I-PDUs and not the routing path itself. The reason is that it is desirable to enable or disable I-PDUs for a specific bus. And a routing path can multicast an I-PDU to several busses. Enabling and disabling of routing path groups is typically used by the BswM module.

Enabling and disabling of routing path groups is typically used by the BswM module. When a routing path associated with a FIFO (PduRTxBufferDepth > 1) is stopped, the according FIFO shall be flushed.

Cancel Reception of an I-PDU

An upper layer module may request cancellation of an I-PDU transported on transport protocol module(s).
The PDU router module will get a request through the PduR_ < Up >CancelReceive().
The confirmation of the cancellation request is made through the return value of < LoTp >_ CancelReceive() that is forwarded to the upper layer module as return value of PduR_ < Up >CancelReceive().

Cancel Transmission of an I-PDU

An upper layer module may request cancellation of an I-PDU (transported by communication interface module or transport protocol module).
The PDU Router module will forward the request to either one destination module (singlecast) or multiple destination modules (multicast).
The PduR_< Up >CancelTransmit() is used to cancel communication interface I-PDU and to cancel transport protocol I-PDUs in the case of forwarding.
For communication interface, < Lo > _CancelTransmit() and for transport protocol, < LoTp > _CancelTransmit() is called.
Only if all the involved < Lo > and < LoTp > _ CancelTransmit() calls return E_OK the return value to PduR_< Up >CancelTransmit() is E_OK else it is E_NOT_OK.

Change transport protocol parameter

It is possible for the upper layer modules to change a transport protocol parameter for a specific I-PDU.
The upper layer will start with calling the PduR_< Up >ChangeParameter(), the PDU Router module will forward to the correct transport protocol module using < LoTp >_ChangeParameter().

Zero Cost Operation of PduR module

This is an optimization that is done to completely bypass the PduR module during operation. This optimization is possible only when the following conditions are met.

There is only one source and destination module.
For example an ECU with a COM module and a single CAN bus, the PduR_ComTransmit may directly call the CanIf_Transmit without any logic inside the PduR Module. The PDU Router becomes a macro layer.
All routing paths are of configuration class Pre-Compile.
Configuration parameter PduRZeroCostOperation is set to TRUE.