Demystifying Autosar PDU Router. A Comprehensive Guide to Routing, Handling, and Buffering
The PDU Router provides a mechanism for routing PDUs between upper and lower layers, abstracting them from each other, including both communication interfaces and TP modules. The routes taken by the PDUs are defined statically and can be found on the routing tables of the PDU router, which is one part of the PDU Router. The other part, the PDU router engine, is the entity responsible for routing from the source to the destination, including the translation of the source PDU ID to the destination PDU ID, hereby connecting both layers.
When a PDU is routed by the PDU Router, its payload stays intact, and the PDU ID gets converted into the expected PDU ID of the destination. These identifiers are available statically, both in the source and the destination modules. The source and destination can be found because they reference the same PDU inside the EcuC module configuration. The direction is also possible to find because the modules are configured as upper or lower layers (not both, except the I-PDU Multiplexer).
A routing path is the route traversed between the source and destination. There are two limitations regarding the routing path: The PDUs need to share the same MetaDataType and in case the DDS module is part of the routing path, the other module is required to be either the SoAd or the LdCom. If any of these conditions is not valid for any of the routing paths, then the configuration is invalid.
The PDU Router interacts with multiple modules, mainly those that communicate through it. These are defined as upper or lower layer modules, depending on their location relative to the PduR. The bus interfaces / TP modules are usually lower layers, while interaction layer modules are commonly the upper layers (usually COM and DCM). One module can be both at the same time, if it requires communication with both upper and lower layers, such as the IpduM. Lastly, the list of upper and lower layer modules is not fixed, as even CDDs can use the PDU Router functionality.
Depending on the required functionality of your system for communication (transmission, reception, cancellation, and triggered transmission for both IF and TP), the layers that use the PDU Router need to implement and provide certain APIs. These are the mandatory APIs:
- Lower Layers –
<Lo>_Transmit,<Lo>_CancelTransmit,<Lo>_CancelTransmit, and<Lo>_CancelReceive(only for TP). - Upper Layers Using IF –
<Up>_RxIndication,<Up>_TxConfirmation, and<Up>_TriggerTransmit. - Upper Layers Using TP –
<Up>_StartOfReception,<Up>_CopyRxData,<Up>_CopyTxData,<Up>_TpRxIndication,<Up>_TpTxConfirmation.
The PDU Router expects each of its modules to provide the API declarations in a header file with a name as PduR_<moduleName>.h.
PDU Handling Capabilities
Since the PDU Router acts as a forwarder or a gateway (or both), it does not modify the I-PDUs between the source and the destination. This forwarding can also be multicast in both directions and with TP. All the possibilities provided by the PDU Router for PDU forwarding are defined in the table below:
| Direction | Method | Mode |
|---|---|---|
| Tx | 1:1 | Capable |
| 1:N | Capable | |
| Rx | 1:1 | Capable |
| 1:N | Not capable | |
| N:1 | Capable, with buffering |
When acting as a gateway, the PDU Router is capable of handling unicast and multicast methods for IF and TP communication interfaces, with three different buffering methods. The possible combinations are described in the table below:
| Method | Buffering | Mode |
|---|---|---|
| 1:1 | Last is Best | Capable |
| FIFO | Capable | |
| No Buffer | Not Capable | |
| 1:N | Last is Best | Capable |
| FIFO | Capable | |
| No Buffer | Not Capable | |
| N:1 | Last is Best | Only 1 source enabled at a time (1:1) |
| FIFO | Only 1 source enabled at a time (1:1) | |
| No Buffer | Not capable |
It is also possible to configure the PDU Router as both forwarder and gateway at the same time. In this case, the communication via TP protocol can only be performed with Single Frames (SF) with buffering. Moreover, combining PDU reception with fan-in (1:N) gateway functionality is not possible.
There are some considerations we should keep in mind about the PDU Router:
- It does not modify the I-PDUs.
- It does not perform routing based on the payload.
- It cannot route PDUs between an IF and a TP layer, and vice-versa, only between layers of the same type.
- It does not work with MOST protocol.
Now, to some specific behaviors of the 1:N (I-PDU fan-out) transmission that might not look so obvious from the outside:
- The PDU Router will indicate a successful transmission request if at least one of the transmissions of the lower layers is successful.
- The PDU Router will report a successful transmission confirmation to the upper layer only when the last lower layer where the transmission was requested successfully confirms the transmission (E_OK). Hence, in case the deadline monitoring functionality from the COM is used, it will be applied only to the last lower layer.
- A transmission cancellation request sent by the upper layer will only return E_OK in case all the lower layers return E_OK.
- The update-bit functionality from the COM does not work with I-PDU fan-out.
- All the destinations are affected by a change in the I-PDU group states.
The update-bits and sequence counter from the COM will not work with I-PDU fan-in (N:1) reception.
PDU Buffering
As you saw before, buffers are necessary for the gateway functionality, in case the gateway destinations obtain their data through triggered transmission or if they are a TP gateway. They are used inside an I-PDU by setting the PduRQueueDepth parameter to a value larger than zero and created inside the PduRBuffer container. This value defines the number of buffers a routing path can occupy at once, the number of instances that can be buffered. For multicast routing, the buffers are defined individually and are independent from each other.
There are two buffer types: global, if they are not referenced within any PduRRoutingPath, or dedicated, in case they are. The main difference between them is the latter can only be occupied by the routing paths that reference them through the PduRDestBufferRef container, while the former can be used by any I-PDU that requires buffering.
Be aware that when a dedicated buffer is full (or if the dedicated buffer length is smaller than the I-PDU length), the routing paths that define them can also use the global buffers. Lastly, the dedicated buffers are useful for high priority messages that have low tolerance for delays, such as OBD requests. The buffer length is defined by the PduRPduMaxLength parameter and each of them only holds one I-PDU.
If the PduRQueueLength value is larger than one, the buffer will behave as a FIFO.
A routing path can also trigger the PDUR_E_ROUTING_PATH_BUFFER_OVERFLOW to the DEM when all the buffers are occupied.
Today, we will stop here. In a future article, we will go in further depth, exploring the specific behaviours of the sending, reception, and cancellation, for the different modalities. There is more that meets the eye, such as gateway functionality, routing path groups and zero-cost operations, among other sub-topics this intricate module hides. Stay tuned, and do not forget to join the waiting list for the eBooks we are creating!
Author: Micael Coutinho (opens in a new tab)
References:
© AutosarToday —@LinkedIn