TechnicalReference_PduRs

MICROSAR PDU Router
Technical Reference

DaVinci Configurator
Version 3.00.00

Authors
Erich Schondelmaier, Gunnar Meiss, Sebastian
Waldvogel, Florian Röhm
Status
Released

Technical Reference MICROSAR PDU Router
Document Information
History
Author
Date
Version
Remarks
Erich Schondelmaier  2012-12-20
1.00.00
Initial version based on PduR Technical
Reference
Erich Schondelmaier  2012-07-12
2.00.00
Adapted to AUTOSAR 4.0.3
Erich Schondelmaier  2012-10-15
2.01.00
TP Gateway
IF Gateway
Gunnar Meiss
2012-11-21
2.02.00
AR4-285: Support PduRRoutingPathGroups
Erich Schondelmaier  2013-02-07
2.02.01
Adapted Tp- API description
Erich Schondelmaier  2013-02-15
2.02.02
Added some ASR deviations
ESCAN00064126
Erich Schondelmaier  2013-03-19
2.03.00
ESCAN00064364 AR4-325: Post-Build
Loadable
Added Cancel- Receive/ Transmit Support
Erich Schondelmaier  2014-04-15
2.04.00
Added TP routing with variable addresses
(MetaData Handling)
Added Threshold “0” support
Erich Schondelmaier  2014-04-15
2.04.01
Support  the  StartOfReception  API  (with  the
PduInfoType),
TxConfirmation  and  RxIndication  according
ASR4.1.2
Erich Schondelmaier  2014-09-01
2.05.00
Added SecOC to the Interface Overview
Extended  Tp  Gateway  Routing  behavior
description
Updated Configuration Variant
Sebastian Waldvogel  2015-02-23
2.06.00
FEAT-1057:  Added  documentation  about
configuration  of  range  routing  paths  and
functional requests gateway
Sebastian Waldvogel  2015-05-11
2.06.01
FEAT-1057: Improvements of documentation
Florian Röhm
2015-07-30
2.07.00
FEAT-109:  Added  documentation  for  PduR
switching feature and N:1 routing paths
Florian Röhm
2016-01-16
2.08.00
FEAT-1485:  Added  documentation  for  1:N
and N:1 transport protocol routing paths
Gunnar Meiss
2016-02-25
2.08.00
FEAT-1631:  Trigger  Transmit  API  with
SduLength In/Out according to ASR4.2.2
Erich Schondelmaier  2016-03-17
2.08.00
added limitation:
-  The  Polling  Mode  cannot  be  used  for  N:1
routings.
-  Cancel  Transmit  for  N:1  routing  paths  is
only  supported  if  a  Tx  Confirmation  is
enabled.
-  Removed  limitation:  N:1  interface  routing
paths suppport only for lower layer CanIf.
© 2017 Vector Informatik GmbH
Version 3.00.00
2
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
Florian Röhm
2016-04-01
2.08.01
Removed empty chapters
Erich Schondelmaier, 2016-08-10
3.00.00
Shared/Dedicated Buffer support
Florian Röhm
Memory mapping extension
Sebastian Waldvogel 2016-11-24
3.00.00
Smart Learning (Switching)
© 2017 Vector Informatik GmbH
Version 3.00.00
3
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
Reference Documents
No.
Source
Title
Version
[1]   AUTOSAR
AUTOSAR_SWS_PDURouter.pdf
4.0.3
[2]   AUTOSAR
AUTOSAR_SWS_PDURouter.pdf.
4.1.1
[3]   AUTOSAR
AUTOSAR_SWS_PDURouter.pdf
4.1.2
[4]   AUTOSAR
AUTOSAR_SWS_DevelopmentErrorTracer.pdf
3.2.0
[5]   AUTOSAR
AUTOSAR_TR_BSWModuleList.pdf
1.6.0
[6]   AUTOSAR
AUTOSAR_SWS_SAEJ1939TransportLayer.pdf
1.5.0
[7]   Vector
TechnicalReference_CanIf.pdf
6.02.00
[8]   Vector
TechnicalReference_<CAN Driver>.pdf
-
[9]   AUTOSAR
TechnicalReference_CanTp.pdf
2.00.00

This technical reference describes the general use of the PduR basis software module.

Caution
We have configured the programs in accordance with your specifications in the
  questionnaire. Whereas the programs do support other configurations than the one
specified in your questionnaire, Vector´s release of the programs delivered to your
company is expressly restricted to the configuration you have specified in the
questionnaire.

© 2017 Vector Informatik GmbH
Version 3.00.00
4
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
1  Component History
The  component  history  gives  an  overview  over  the  important  milestones  that  are
supported in the different versions of the component.
Component Version  New Features
1.00
  MICROSAR 4 Base
2.00
  AUTOSAR 4.0.3
2.01
  TP Gateway
  IF Gateway
2.02
  Routing Path Groups
2.03
  Post-Build Loadable
5.00
  Changed  StartOfReception, TpRxIndication and
TpTxConfirmation APIs according to AUTOSAR 4.1.2
  Added TP routing with variable addresses
  Meta-Data support
6.00
  Post-Build Selectable
7.00
  CAN-FD
8.00
  PduR Switching
  N:1 Interface routing path support
9.00
  1:N/N:1 transport protocol routing path support
Table 1-1   Component history

© 2017 Vector Informatik GmbH
Version 3.00.00
10
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
2  Introduction
This  document  describes  the  functionality, API  and  configuration  of  the AUTOSAR  BSW
module PDUR as specified in [1].

Supported AUTOSAR Release*:
4
Supported Configuration Variants:
PRE-COMPILE [SELECTABLE]
POST-BUILD-LOADABLE [SELECTABLE]
Vendor ID:
PDUR_VENDOR_ID
30 decimal
(= Vector-Informatik,
according to HIS)
Module ID:
PDUR_MODULE_ID
51 decimal
(according to ref. [5])
* For the precise AUTOSAR Release 4.x please see the release specific documentation.

The  main  task  of  the  PDU  Router  module  is  to  abstract  from  the  type  of  bus
access (Interface layer and TP layer) and from the bus type itself.
Since the PDU Router module has to route Rx and Tx PDUs to and from the  upper- and
lower-    layers  and  any  software   component  uses  its  own  handle  space,  multiple
routing tables  are  required.  The  PDU  Router  uses  the  input  handle  as  an  index  to
the  related routing table.
© 2017 Vector Informatik GmbH
Version 3.00.00
11
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
2.1
Architecture Overview
Figure 2-1 shows where the PDUR is located in the AUTOSAR architecture.

Figure 2-1 AUTOSAR 4.1 Architecture Overview

© 2017 Vector Informatik GmbH
Version 3.00.00
12
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
Figure  2-2  shows the interfaces to adjacent modules of the  PDUR.  These interfaces are
described in chapter 5.
class Architecture
CanTp
FrArTp
DoIp
J1939Tp
FrTp
CanNm
J1939Dcm
Det
<UpTp>
IpduM
Bsw M
J1939Rm
<LoTp>
PduR
LdCom
FrNm
<LoIf>
Dcm
CanIf
SoAd
J1939Nm
<UpIf>
Com
LinIf
FrIf
SecOC
CddPduRUpperLayerContribution
CddPduRLow erLayerContribution

Figure 2-2  Interfaces to adjacent modules of the PDUR

Applications do not access the services of the BSW modules directly. They use the service
ports provided by the BSW modules via the RTE. The service ports provided by the PDUR
are listed in chapter 0 and are defined in [1].
© 2017 Vector Informatik GmbH
Version 3.00.00
13
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
3  Functional Description
3.1
Features
The features listed in the following tables cover the complete functionality specified for the
PDUR.
The AUTOSAR  standard  functionality  is  specified  in  [1],  the  corresponding  features  are
listed in the tables
  Table 3-1   Supported AUTOSAR standard conform features
  Table 3-2   Not supported AUTOSAR standard conform features
For further information of not supported features see also chapter 0.
Vector Informatik provides further PDUR functionality beyond the AUTOSAR standard. The
corresponding features are listed in the table
  Table 3-3   Features provided beyond the AUTOSAR standard

The following features specified in [1] are supported:
Supported AUTOSAR Standard Conform Features
Pre compile and Post build time configuration variant
I-PDU transmission and reception
Cancel-Receive/Transmit support
Change Parameter support
1:1 routing between upper- and lower-layer communication interface modules
1:1 routing between upper- and lower-layer transport protocol modules
1:1 Interface Gateway Routing
1:N Interface Gateway Routing
1:1 Transport protocol Gateway Routing
1:N Transport protocol Gateway Routing (single and multiframe Tp messages)
Complex device driver ( CDD ) support
Routing Path Groups
Debugging support (optional feature)
Table 3-1   Supported AUTOSAR standard conform features
The following features specified in [1] are not supported:
Not Supported AUTOSAR Standard Conform Features
Link time configuration
1:N fan-out from the same upper layer PDU (IF/ Tp)
Zero cost operation
Minimum Routing (Reduced state)
© 2017 Vector Informatik GmbH
Version 3.00.00
14
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
Table 3-2   Not supported AUTOSAR standard conform features
The following features are provided beyond the AUTOSAR standard:
Features Provided Beyond The AUTOSAR Standard
N:1 Interface routing path capability
PduR Switching: Smart learning of routing path destinations depending on received Pdus
1:N and N:1 transport protocol single- and multiframe routing path capability
Table 3-3   Features provided beyond the AUTOSAR standard
3.2
Interfaces to adjacent modules of the PDUR
The  PDU  Router  provides  generic  communication  interfaces  and transport protocol APIs
for any lower and upper layer module.
3.3
Initialization
Before  the  PduR  can  be  used  it  has  to  be  initialized  by  PduR_Init()  which  performs  the
basic initialization. Initialization is normally driven by the Communication Manager.  If this
software  component  is  not  available  a  similar  component  has  to  be  provided  by  the
integrator.
3.4
States
The  PduR  is  initially  not  activated.  Basic  RAM  arrays  are  initialized  with  the  call  of
PduR_InitMemory or with the startup code of your ECU. If PduR_Init() is called with valid
parameters, the PduR is in the state “PduR_IsInitialized” and the communication can start.
3.5
Error Handling
3.5.1
Development Error Reporting
By  default,  development  errors  are  reported  to  the  DET  using  the  service
Det_ReportError()  as  specified  in  [4],  if  development  error  reporting  is  enabled  (i.e.
pre-compile parameter PDUR_DEV_ERROR_DETECT==STD_ON).
If  another  module  is  used  for  development  error  reporting,  the  function  prototype  for
reporting the error can be configured by the integrator, but must have the same signature
as the service Det_ReportError().
The reported PDUR ID is 51.
3.6
Interface Layer Gateway
3.6.1
Data Provision
3.6.1.1
Direct data provision
For  Direct  Data  Provision  routing  paths  the  data  will  be  copied  by  the  PduR  to  the
destination module in the transmit API call. If a FIFO queue is configured, the data might
be queued and will then be transmitted in the Tx Confirmation context.
© 2017 Vector Informatik GmbH
Version 3.00.00
15
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
3.6.1.2
Trigger transmit data provision
For  Trigger  Transmit  Data  Provision  routing  paths  the  data  will  be  copied  by  the
destination module in the trigger transmit API call. This is useful if the destination module
always wants to fetch the latest data available (single buffer configuration) or it has specific
timing requirements when it needs to provide the data.
3.6.2
FIFO Queue
A FIFO is used if loss of I-PDU instances is critical. In case of several parallel transmitting
FIFO queues, the order of transmission depends upon the bus access of the lower layer
and not on the relative order of I-PDU reception. One FIFO queue therefore only cares for
a FIFO based sorting of the instances of its own queued I-PDUs.
The queue depth can be configured for each routing path independently.
If the transmission of an I-PDU failed (negative return value of the interface layer transmit
request),  the  PDU  Router  removes  the  I-PDUs  instance  from  the  queue  and  retries  the
transmission with the next instance – until the queue is empty or the transmission request
is accepted.
In case of a buffer overrun, all queued I-PDU instances of the affected queue are removed
and the newly received I-PDU is transmitted.

EcuC structural changes with PduR version 9.00.00
The PduRTxBufferDepth has been removed and was replaced by the
  PduRDestPduQueueDepth parameter.

3.6.3
Buffer Configurations
3.6.3.1
No Buffer
No buffering will be used if the PduRDestPduQueueDepth is not configured.
3.6.3.2
Direct Data Provision FIFO
A  FIFO  queue  will  be  used  if  the  data  provision  is  set  to  direct  transmission  and  the
PduRDestPduQueueDepth is larger than zero.
3.6.3.3
Trigger Transmit Data Provision FIFO
A  FIFO  will  be  used  if  the  data  provision  is  set  to  trigger  transmit  and  the
PduRDestPduQueueDepth is larger than one.
3.6.3.4
Trigger Transmit Data Provision Single Buffer
A  single  buffer  will  be  used  if  the  data  provision  is  set  to  trigger  transmit  and  the
PduRDestPduQueueDepth is one.
Last  is  best  semantics  apply.  Values  in  the  buffer  will  be  overwritten  so  that  a  Trigger
Transmit call always gets the latest data from the buffer. It is necessary to specify default
values for the buffer, as the Trigger Transmit API can be called before any new data was
written to the buffer.
© 2017 Vector Informatik GmbH
Version 3.00.00
16
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
3.6.4
Shared Tx Buffer Pool support
The  Interface  Layer  Gateway  supports  shared  Tx  Buffer.  Tx  Buffer  can  be  assigned  to
multiple routing paths at once. This is useful for routing paths which are not active at the
same time. Thus, RAM consumption can be reduced.
3.6.5
Timing aspects
The  PDU  Router  triggers  the  transmission  of  I-PDU  instances  to  be  routed  as  soon  as
possible. If the queue is empty, a reception will directly cause a transmission request to the
interface layer.  If the queue is occupied, the I-PDU instance will  be added to the queue.
Queued  I-PDU  instances  are  transmitted  within  the  Tx  confirmation  of  the  preceding
instance.  This  queuing behavior can cause bursts on the destination channel (especially
CAN)  if  several  queue  instances  are  queued  and  if  the  driver  layer  does  not  free  the
hardware queue.
The  PDU  Router  does  not  provide  a  mechanism  to  implement  a  rate  conversion  (e.g.
change the cycle time from the source to the destination channel). A rate conversion can
be  implemented  (at  extra  runtime  costs)  by  signal  routing  paths  using  the  COM  signal
gateway.
3.6.6
Dynamic DLC Routing
With PduR version 9.00.00 and later there is no restriction for the dynamic length routing
for gateway routing paths.  All lengths between 0 and the configured PDU length can be
routed. The length can be adapted dynamically during runtime.

Caution
A Pdu with a DLC larger than the configured Pdu length will be truncated to the length
  of the smallest available buffer of this routing path.

3.6.7
Transport protocol low level routing
If the TP segments (N-PDUs) on the source and the destination network are identical, it is
possible to route TP I-PDUs using the interface layer gateway (“low-level” routing). If low-
level  routing  is  used,  the  (former)  N-PDU  is  no  longer  accessible  to  the  TP  layer  and
therefore seen as an I-PDU by the PDU Router module.
The advantage of low-level routing is that it is executed in the context of the interface layer
RxIndication and therefore introduces a minimal routing latency.
Low-level routing has, however, several drawbacks which might cause that a high-level TP
routing is more adequate:
  TP protocol conversion is not possible as the frame-layout and the flow-control
handling must be the same on the source and the destination network.
  No forwarding of routed TP I-PDUs to the local DCM is possible as it may be required
for functional requests.
  Eventual loss of TP parameters, such as the STmin timing and the block size, due to
bursts on the destination bus. Bursts are a result of queued I-PDUs which were
transmitted in the TxConfirmation of the previous I-PDU.
© 2017 Vector Informatik GmbH
Version 3.00.00
17
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
 A buffer overrun in the FiFo queue causes the queue to be flushed and therefore
corrupts the TP communication. The TP layer gateway can avoid buffer overflows if the
receiving TP connection supports a dynamic block size adaptation.
© 2017 Vector Informatik GmbH
Version 3.00.00
18
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
3.6.8
Smart Learning (Switching)
The  PduR  routing  path  relations  are  statically  configured  and  cannot  be  modified  during
runtime.  In  case  ECUs  will  be  attached  to  different  networks  during  assembly  or  a  huge
amount  of  possible  routing  relations  will  be  required,  the  dynamic  learning  of  routing
relations can be used.
The switching functionality is based on a dynamic RAM table, the forwarding information
base (FIB) inside the PduR. This RAM table stores the location (network) of the different
ECUs and will be used to direct the routings to the correct destination. The identification of
the communication partners is done by a source- and target address which is determined
based  on  the  PDU  meta  data.  The  FIB  is  updated  with  the  related  location  (called
connection) on reception of every participating PDU.
Source address  Learned destination location/connection
0x00
Connection 2
0x01
<not yet learned>
0x02
Connection 0
…
…
Table 3-4   Example FIB content after reception of Pdus from source 0x00 and 0x02
On  reception  of  every  PDU  a  lookup  in  the  FIB  is  done  to  check  whether  the
location/connection  of  the  target  address  is  already  known.  If  the  target  address
destination  (FIB  source  address)  is  not  yet  known,  the  PDU  will  be  broadcasted  to  all
destinations  of  the  respective  routing  path.  In  case  the  target  address  destination  was
already learned by the gateway, the PDU will be routed to the learned destination instead
of the broadcasting.
From the technical point of view the switching functionality is an add-on for the static PduR
routing path relations. The standard PduR routing paths are used to describe all required
routing relations which are necessary if no dynamic learning is available. This means that
the routing paths must be configured in a way that the PDUs are broadcasted to all desired
networks which have possible destination ECUs connected. This is typically a 1:N routing
path  which  performs  a  broadcasting  of  the  PDU.  The  switching  add-on  suppresses  the
routing to the individual destinations based on the FIB information. In case the destination
of a single PDU / target address is not yet known, the PDU will be routed to all destinations
of  the  1:N  routing  path.  In  case  the  destination  is  already  learned,  the  routing  to  all
destinations except the learned one is suppressed.
Gateway ECU
Gateway ECU
ECU0
ECU1
ECU2
ECU0
ECU1
ECU2
CAN0
CAN1
CAN2

CAN0
CAN1
CAN2

Figure 3-1  Example routing path configurations: Every ECU transmits to every other ECU (via N:M routing paths)
or ECU0 can exclusively broadcast to all other ECUs. Other ECUs can only reach ECU0
© 2017 Vector Informatik GmbH
Version 3.00.00
19
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
An  important  concept  for  the  smart  learning  functionality  is  the  usage  of  communication
interface  range  routing  paths  where  multiple  PDUs  can  be  routed  with  a  single  routing
path. For the examples this means that only three N:M or 1:N/N:1 routing paths have to be
configured  between  the  networks.  The  range  filters  of  the  Rx  CAN  range  Pdus  can  be
used to define the concrete CAN ID range to be routed via the routing paths. For further
information see chapter 6.1.
The memorization of the source / target address locations/networks is done on the basis of
the actual extracted source / and target addresses which are based on the CAN ID of the
routed range PDUs.

Caution
The PduR switching feature is only supported for MetaData Pdus. Therefore the
  referenced routing paths in a PduR Connection must be MetaData routing paths.
Currently only the CanIf supports the MetaData feature.

The  switching  functionality  is  automatically  enabled  for  all  PDUs  associated  to  a
PduRDataPlane (see chapter 3.6.8.1).
All entries of the FIB will be set to ‘not yet learned’ during initialization of the PduR. This is
the  only  way  to  completely  ‘unlearn’  the  FIB  table. A  relearning  is  possible  by  receiving
messages with the corresponding source address on some other channel. The PduR will
then update the connection/location of this address.

3.6.8.1
Configuration
The  configuration  and  activation  of  the  switching  functionality  is  done  within  the  EcuC
container  /MICROSAR/PduR/PduRRoutingTables/PduRDataPlaneTable.  By  adding  a  new
PduRDataPlane an independent FIB RAM table will be instantiated. Therefore it is possible
to configure multiple different independent smart learning / switching behaviors in a single
gateway.
Within a PduRDataPlane the PduRDataPlane/PduRConnection containers are used to assign
the  static  PduR  routing  path  sources  and  destinations  to  a  network  (location).  A
PduRConnection represents a single network.
Gateway ECU
Connection_CAN0
Connection_CAN1
Connection_CAN1
ECU0
ECU1
ECU2
CAN0
CAN1
CAN2

Figure 3-2  Network specific assignment of PduRRouting path sources and destinations to a PduRConnection
© 2017 Vector Informatik GmbH
Version 3.00.00
20
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
Reference all related PduRRoutingPath/PduRSrcPdu and PduRRoutingPath/PduRDestPdu of
a single network to the PduRConnection by the references PduRConnection/PduRSrcPduRef
and PduRConnection/PduRDestPduRef.

The
behavior
of
the
switching
logic
itself
is
configured
in
the
PduRDataPlane/PduRSwitchingStrategy/PduRSaTaSwitchingStrategy
container.
The
currently available strategy is based on source- and target addresses as described above.
Within the PduRSaTaSwitchingStrategy different strategies are supported to determine the
source- and target address of the PDUs:
  PduRLinearTaToSaCalculationStrategy
The target address is the CAN ID (contained in the Pdu meta data). The source
address is calculated by masking the target address and adding a linear offset.
For PDUs referenced by PduRAddOffsetSrcPduRef:
  source address = (target address + offset) & mask
For PDUs referenced by PduRSubtractOffsetSrcPduRef:
  source address = (target address - offset) & mask
  PduRSaTaFromMetaDataCalculationStrategy
The source and target address is directly read from the CAN ID contained in the meta
data. The bit access will occur on the logical CAN ID extracted from the meta data.
The source address bit position is defined by the PduRSaStartBitPosition and
PduRSaEndBitPosition parameters. The target address bit position is defined by the
PduRTaStartBitPosition and PduRTaEndBitPosition parameters.
Example bit position configuration of the CAN ID layout shown in Figure 3-3:
PduRSaStartBitPosition: 0
PduRSaEndBitPosition:   9
PduRTaStartBitPosition: 10
PduRTaEndBitPosition: 19
Message ID (29 bit)
<Reserved>
Target Address
Source Address
9bit
10bit
10bit

Figure 3-3  Example Extended CAN ID layout

© 2017 Vector Informatik GmbH
Version 3.00.00
21
based on template version 4.9.2

Technical Reference MICROSAR PDU Router

EcuC structural changes with PduR version 9.00.00

PduRConnection
In the previous versions the PduRConnection/PduRSrcPduRef and
PduRConnection/PduRDestPduRef parameters were used to separate between
request and response routing paths. A separation between request and response
routing paths does not exist anymore. Instead the references are now just used for
network to PduRSrcPdu / PduRDestPdu mapping.
An automated migration of the PduRConnection references is not possible. Please
add missing references manually.

PduRLinearMappingStrategy
In the previous versions the mapping between request and response PDUs was
configured in the
PduRDataPlane/PduRDataPlaneMappingStrategy/PduRLinearMappingStrategy
container. This container will be automatically migrated to the new location
PduRDataPlane/PduRSwitchingStrategy/PduRSaTaSwitchingStrategy/PduRSaTa
CalculationStrategy/PduRLinearTaToSaCalculationStrategy. As described
above the separation between request and response routing paths by the
PduRConnection/PduRSrcPduRef and PduRConnection/PduRDestPduRef does not
exist anymore. Rather the new references
PduRLinearTaToSaCalculationStrategy/PduRAddOffsetSrcPduRef and
PduRLinearTaToSaCalculationStrategy/PduRSubtractOffsetSrcPduRef were
introduced. PduRAddOffsetSrcPduRef must reference all PduRSrcPdus where the
offset shall be added to the target address to determine the related source address.
PDUs where the offset shall be subtracted must be referenced with the
PduRSubtractOffsetSrcPduRef references.
The AddOffset- and SubtractOffsetSrcPduRef references are automatically
migrated. Former PduRSrcPdu referenced by PduRConnection/PduRDestPduRef are
migrated to PduRAddOffsetSrcPduRef. Former PduRSrcPdu referenced by
PduRConnection/PduRSrcPduRef are migrated to PduRSubtractOffsetSrcPduRef.

© 2017 Vector Informatik GmbH
Version 3.00.00
22
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
3.6.8.2
Example
Network topology is as shown in Figure 3-4. The CAN ID layout is as shown in Figure 3-5.
Strategy  PduRSaTaFromMetaDataCalculationStrategy  used  (see  chapter  3.6.8.1).  Routing
path configuration as shown in Figure 3-1 (every ECU can broadcast to the other ECUs).
Gateway ECU
FIB
ECU0
Routing  logic
ECU1
address = 0x4
address = 0x2
ECU2
address = 0x3
CAN 0
CAN 1
CAN 2

Figure 3-4  Example switching network topology
Message ID (11 bit)
<Reserved>
Target Address
Source Address
3bit
4bit
4bit

Figure 3-5  Example Standard CAN ID layout

Figure 3-6  Example switching EcuC configuration - PduRConnection

© 2017 Vector Informatik GmbH
Version 3.00.00
23
based on template version 4.9.2

Technical Reference MICROSAR PDU Router

Figure 3-7  Example switching EcuC configuration - PduRSaTaFromMetaDataCalculationStrategy
Example communication sequence and FIB contents:

1. ECU0 transmits the range Pdu with CAN ID 0x034.
Source Address  Learned location
This  means  ECU0  uses  its  address  as  source
…
…
address (0x4), and addresses ECU2 with the target
0x02
address  0x3.  The  PDU  will  be  broadcasted  to

<not yet learned>
CAN1 and CAN2 and the location of ECO0 address  0x03
<not yet learned>
is updated in the FIB.
0x04
Connection_CAN0

…
…

2. ECU2  responds  to  the  initial  PDU  of  ECU0  with  a
Source Address  Learned location
PDU  with  CAN  ID  0x043.  The  PDU  will  only  be
…
…
routed  to  CAN0  because  the  location  of  the  target
0x02
<not yet learned>
address (0x4) was already learned by the first PDU
0x03
of  ECU0.  Additionally  the  location  of  ECU2  is

Connection_CAN2
updated in the FIB.
0x04
Connection_CAN0

…
…

3. Finally ECU1 transmits a PDU with CAN ID 0x032.
Source Address  Learned location
The PDU will only be routed to CAN2 because the
…
…
location  of  the  target  address  (0x3)  was  already
0x02
Connection_CAN1
learned. The FIB gets updated with the location of
ECU1.
0x03
Connection_CAN2

0x04
Connection_CAN0
…
…

3.6.9
Queue overflow notification callback
The  PDU  Router  supports  a  Queue  overflow  notification  callback.  In  case  of  a
communication interface routing with unfavorable  FIFO  configuration or if the destination
bus  is  not  available  (e.g.  bus  off)  a  buffer  overflow  can  occur.  In  this  case  the  FIFO  is
flushed.
Additionally  a  callback  could  be  configured  to  capture  this  event  and  perform  error
handling. See Figure 3-8 Overflow notification callback configuration.
© 2017 Vector Informatik GmbH
Version 3.00.00
24
based on template version 4.9.2

Technical Reference MICROSAR PDU Router

Enable Feature overflow notification callback
  >
PduR_QueueOverflowNotification activates / deactivates a PduR
communication interface TxBuffer overflow notification.
>  Set an individual error notification module name by using
PduR_ErrorNotificationModuleName parameter. This parameter is optional
and can be left empty. ‘ErrorNotification’ is used as default value.

If the feature is enabled two additional source files are generated to the Gendata folder.
A <ErrorNotification>_Cbk.h file and a _<ErrorNotification>_Cbk.c template file. The
template contains the error notification function which must be implemented.
>  Implement the error notification function and remove the template
underscore.
Figure 3-8 Overflow notification callback configuration
During runtime the error notification is called by the PDU Router in case of a FIFO
overflow. The lower layer interface handle is passed to the notification callback.

How to get the associated gateway routing path


>  Open the Find view and enter the destination PDU name with the
associated handle. Syntax: value == destination PDU name
>  Right click on the PDU Router destination container in the result view and
open the reference using the “Show referenced item in” dialog.

Table 3-5 How to get the associated gateway routing path

Caution
The error notification function is called in the interrupt context! Please keep the error
  handling short.

© 2017 Vector Informatik GmbH
Version 3.00.00
25
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
3.7
Transport Protocol Gateway
The TP layer gateway allows high-level routing of TP I-PDUs.
In order to reduce runtime and memory consumption, the gateway supports the so called
routing on-the-fly (for 1:1, 1:N and N:1 single and multiframe routing paths). Depending on
the  “Threshold”  configuration  of  each  routing  path,  the  gateway  starts  with  the
transmission on the destination network before the reception has completed on the source
network.
Since AUTOSAR 4 the PduR copies the data within the PduR_<LoTp>_CopyRxData() call.
So  the  PduR  module  always  knows  how  much  buffer  is  still  available  and  provides  the
complete size to the Tp module. The PduR is not limited to linear buffer boundaries like in
AUTOSAR 3, so the PduR data rate is very efficient.
The  Tp  module  will  never  get  more  buffer  within  one  PduR_<LoTp>_CopyRxData()  call
than the PduR provides to the Tp module. Therefore the Tp modules should not try to copy
more data than the provided buffer length.
3.7.1
Multi-Routing
The  PduR  supports  N:1  and  1:N  routing paths  for  both  single-  and multiframes.  Each  of
these routing paths will only occupy a single Tx Buffer at runtime (if no FIFO behavior is
required). For details on the queuing behavior refer to chapter 3.7.4.

Note
1:N gateway routing paths which involve an upper layer destination must be configured
  as a store and forward routing path.

3.7.2
TP Threshold
The Threshold value is used to…
  … define the fill level of the buffer where the transmission is triggered on the
destination bus.
  … exclude buffers from the selection during runtime. This could be helpful to ensure
that small buffers which are configured for single frames are not taken into account for
long multi messages. If the Threshold is larger than the buffer size it is ensured that
the PduR will not use this buffer to perform the routing.

Note
Small buffers can also be excluded from the selection at runtime using the
  dedicated/shared Tx Buffer pool support. All suitable buffers can be assigned to the
respective routing paths. Only these assigned buffers will be used at runtime. The
assigned buffers can also be shared between multiple other routing paths.
See chapter 3.7.3 for details.

© 2017 Vector Informatik GmbH
Version 3.00.00
26
based on template version 4.9.2

Section 1
Section 2
MetaData FF
CFs
CF size- 1


Technical Reference MICROSAR PDU Router
3.7.2.1
Restrictions
The setting of the TP Threshold is restricted for CanTp, LinTp and FrArTp routing paths.
Threshold values in the shaded sections of Figure 3-9 are not allowed to be configured for
these kind of gateway routings.
Each PduR_<LoTp>_CopyRxData() call requires that a complete consecutive frame (CF)
will be copied to the buffer. If not enough buffer is available the Tp tries again to get more
buffer.  But  the  PduR still  cannot  dequeue  data  because  the  threshold  is  not  reached.  In
this situation there will never be enough buffer space and the routing will be aborted with a
timeout.
The DaVinci Configurator validates this and provides appropriate Solving-Actions to set a
suitable Threshold. The recommended values are adapted to the boundaries.
If just the largest buffer of Figure 3-9 should be used for a routing the Threshold must be
set to Section 2. If the routing should have both buffer options the Threshold level must be
set somewhere in Section 1.

Figure 3-9  Configured Tp Buffer with possible Threshold ranges

3.7.2.2
Threshold “0”
Since  ASR  4.1.2  the  PduR  module  supports  a  Threshold  of  “0”.  This  means  that  the
transmission  will  be  triggered  immediately.  The  first  frame  of  some  Transport  Protocol
modules (J1939Tp and FrTp) does not contain data but it is required that the transmission
will  be  triggered  nevertheless.  For  further  details  refer  for  example  the  J1939Tp
specification [6].
3.7.3
Tx Buffer Handling
Diagnostic communication usually does not take place within all ECUs at the same time.
Therefore a TP routing path typically has no dedicated assigned buffer. In order to reduce
the amount of RAM required for queues, the Tx buffers are assigned dynamically to active
TP routing paths and can be reused in different routing paths automatically.
© 2017 Vector Informatik GmbH
Version 3.00.00
27
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
If a buffer is assigned to a routing path during runtime, this buffer is exclusively reserved
for this routing. If all available buffers are occupied, no further routing is possible and the
PduR  signalizes  the  state  “BUFREQ_E_NOT_OK”  towards  the  TP  module.  It  will  then
create an appropriate flow-control frame depending on its capabilities.
The PduR supports a ring buffer mechanism. Due to the AUTOSAR 4 architecture long TP
messages  can  now  be  routed  through  a  small  PduRTxBuffer,  especially  if  the  source
and destination bus have the same data rate.
The PduRTxBuffer will be released during initialization of the PduR module and after a
routing has terminated either successfully or with an error. They can then be allocated by
other PduRDestPdus again.
The PduR supports multiple Tx Buffer assignment strategies to support different usecases.
3.7.3.1
Tx Buffer Usage Types
A PduRTxBuffer can either be referenced by zero, one or multiple PduRDestPdus.

Note
If a PduRDestPdu references at least one PduRTxBuffer, it has only access to this pool
  of buffers and cannot use the global Tx Buffer pool of unassigned PduRTxBuffers.

3.7.3.1.1
Dedicated Tx Buffer
If a PduRTxBuffer is referenced by only one PduRDestPdu, it is called a dedicated Tx
Buffer. The buffer can only be used by this PduRDestPdu.
Dedicated  Tx  Buffers  accelerate  the  buffer  search  algorithm  as  the  amount  of  available
PduRTxBuffer is more limited compared to a global Tx Buffer Pool use case.
Dedicated  Tx  Buffer  can  be  used  to  ensure  the  availability  of  suitable  Tx  Buffers  and
optimize the buffer for certain bus architectures.

Expert Knowledge
Routing of a functional request is a typical use case for a dedicated buffer. For a short
  diagnostic request it is required to avoid searching for a buffer in the global Tx buffer
pool. If a dedicated buffer is assigned to the PduRDestPdu, this buffer will be used
during runtime.

Note
Dedicated Tx Buffers raise the RAM consumption. Every Tx Buffer allocates its needed
  memory in RAM. This memory will not be shared with any other routing path.
3.7.3.1.2
Shared Tx Buffer
If  a  PduRTxBuffer  is  referenced  by  multiple  PduRDestPdus,  it  is  a  shared  Tx  buffer
which can be used by all corresponding PduRDestPdus.
If  the  Tx  buffer  is  currently  used  by  a  PduRDestPdu,  it  can’t  be  used  by  any  other
PduRDestPdu until the processing of the active routing path is finished.
© 2017 Vector Informatik GmbH
Version 3.00.00
28
based on template version 4.9.2

Technical Reference MICROSAR PDU Router

Expert Knowledge
A buffer pool configuration avoids that a non-suitable buffer is used for a routing during
  runtime.

It is also possible to share Tx Buffers between communication interface and transport
protocol routings. Keep in mind that an allocated buffer is locked until the routing is
finished.
3.7.3.1.3
Local Tx Buffer Pool
If  one  PduRDestPdu  references  more  than  one  PduRTxBuffer,  it  is  called  a  local  Tx
Buffer  Pool.  These  can  either  be  dedicated  PduRTxBuffer  or  they  can  be  shared  with
other PduRDestPdus. A mix of dedicated and shared PduRTxBuffers is supported.
The corresponding routing path can only request the referenced PduRTxBuffers.
3.7.3.1.4
Global Tx Buffer Pool
A PduRTxBuffer which is not referenced by any PduRDestPdu is part of the global Tx
Buffer  pool.  It  can  be  used  by  any  PduRDestPdu  which  has  not  referenced  any
PduRTxBuffer.
3.7.3.2
Example Configuration
In the example shown in Figure 10 the buffer 3 belongs to the global Tx Buffer Pool and
Buffer 1 and 2 are dedicated Tx Buffers of Routing 1 (local Tx Buffer Pool). Routing 2 does
not have a buffer reference. This routing will use buffer 3 from the global Tx Buffer Pool.

Figure 10 Buffer pool configuration

Figure  11  shows  a  shared  buffer  pool  configuration.  Buffer  1  and  2  are  shared  between
Routing 1 and 2.

Figure 11 Shared buffer pool
© 2017 Vector Informatik GmbH
Version 3.00.00
29
based on template version 4.9.2

Technical Reference MICROSAR PDU Router

Caution
If Routing 1 uses Buffer 1 and Buffer 2, Routing 2 will not get a buffer until Buffers are
  released. Use shared buffer pool configurations carefully.

3.7.3.3
Tx Buffer Length Configuration
The  length  of  each  buffer  element  is  configured  individually  and  therefore  allows  fine
adaptations  according  to  the  use  case.  First  of  all,  the  length  of  the  configured  buffer
depends on the Threshold of the configured routing paths. If the gateway assigns a buffer
element to a routing path it is required that the buffer has at least the size of the Threshold.
Increase the PduRTxBuffer length to adapt a high bus load on the reception side to a lower
bandwidth on the transmit side.
Due to the ring-buffer mechanism it is not required that a buffer element with the size of
the largest expected TP I-PDU is configured. A buffer smaller than the routed I-PDU can
result  in  wait-frames  or  a  buffer-overflow  if  the  destination  connection  is  slower  than  the
source connection. A buffer overflow can be avoided if the receiving TP connection allows
dynamic adaptation of the block size (BS) (e.g. CanTp connection with BS greater 0). If a
BS of 0 is used by some of the source TP connections, the configured buffer length should
be dimensioned in a way that buffer overflows are avoided.

Note
It might make sense to configure a small Tp buffer (e.g. 7 bytes) to allow single
  frame routings without occupying a larger and therefore more “expensive” buffer
for  this  task.  This  is  applicable  for  both  local  and  global  Tx  Buffer  Pool
configuration. Dedicated assigned TxBuffer can be used to avoid this problem.

Note
If Meta Data Support is enabled please consider that the MetaDataLength must be
  copied to the Tp Buffer additionally. The MetaDataLength should be taken into account
during the Tp buffer configuration.

3.7.3.4
Amount of Tx Buffer
The Tp gateway requires at least one buffer element to allow the routing of Tp I-PDUs.
The number of buffer elements that have to be configured depends on the number of TP I-
PDUs that shall be routed at the same time.
For each 1:N and N:1 routing path only one buffer element is  occupied at runtime. More
than one buffer element will be occupied if a FIFO behavior is desired.
As  the  buffer  elements  are  not  assigned  to  a  routing  path  statically,  the  number  of
configured buffer elements can be smaller than the number of routing paths.
© 2017 Vector Informatik GmbH
Version 3.00.00
30
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
3.7.3.5
Tx Buffer Selection Algorithm
The PduR uses the following rules to choose one of the configured Tx buffers:
  If the size of the incoming I-PDU is smaller than the configured TP Threshold the
smallest available buffer is used that can hold the entire I-PDU.
  If the size of the incoming I-PDU is larger than the configured TP Threshold it uses the
smallest Tx buffer which can hold the entire I-PDU. If such a buffer is not availabe it
will use the largest available buffer which has a size larger than the TpThreshold.
  If all buffer are occupied, the buffer request is rejected and the TP I-PDU is not routed.
3.7.4
TP Queue
Every  destination  PDU  can  be  configured  to  use  a  queue  to  buffer  the TP  I-PDUs.  The
amount  of  I-PDUs  which  will  be  buffered  can  be  configured  with  the  Dest  PDU  Queue
Depth parameter.
The  Queue  supports  FIFO  behavior.  This  means  that  the  first  started  source  TP
connection is transmitted to the destination first.
TP Queues are supported for the following routing paths:
  1:1 routing path
  1:N routing path (Queue Depth must be equal for all destinations)
  N:1 routing path (Queue Depth must be equal for all DestPdus which reference the
one common destination global PDU)
Multiple I-PDUs from different source connections can be received at once on N:1 routing
paths, as long as the TP Queue is not full. For routing paths with only one possible source
Tp connection (1:1, 1:N), only one I-PDU can be received at once. If the transmission on
the  destination  side  is  delayed,  multiple  I-PDU  instances  which  were  received  on  the
source Tp connection are stored in the queue.
The  default  value  for  the  Dest  Pdu  Queue  Depth  is  2.  This  corresponds  to  the  back-to-
back routing behavior. After one TP I-PDU was received successfully it is transmitted to the
destination  and  another  instance  of  the  I-PDU  can  be  received  on  the  same  TP
connection. Basically every queue with a depth greater than one can store multiple TP I-
PDUs.
A  TP  queue  does  not  reserve  the  actual  memory  location  for  the  Pdu.  This  is  done
dynamically  at  runtime.  TP  buffer  will  be  assigned  to  the  queue,  if  it  requests  to  store  a
new I-PDU. In case there are no suitable TP buffer available, the StartOfReception call will
be rejected.
3.7.5
Error Handling
If one of the source or destination TP components that are involved in a TP data transfer
stops  its  transmission  or  reception  due  to  an  error  (e.g.  a  timeout  has  occurred),  the
corresponding  TP-routing  relation  and  buffer-element  will  be  released.  The  next  buffer
request on the not yet aborted Tp connection will return "BUFREQ_E_NOT_OK" and will
release the Tp connection.

© 2017 Vector Informatik GmbH
Version 3.00.00
31
based on template version 4.9.2

Technical Reference MICROSAR PDU Router

Info
There is no AUTOSAR mechanism which notifies the other TP component side of an
  error during the reception or transmission.

3.7.6
Meta Data Handling
Since  ASR  4.1.2  the  StartOfReception()  API  was  extended  by  the  “PduInfoPtr”.  This
parameter can be used to transmit Meta Data.
In case of a gateway routing the payload provided in the “PduInfoPtr” will be ignored by the
PduR.  Just  Meta  Data  are  buffered  and  transmitted  via  the  <LL>_Transmit  function.  In
case of forwarding to an upper layer module (e.g.  DCM  or CDD ) the payload and Meta
Data  will  be  forwarded  and  the  upper  layer  must  extract  the  Meta  Data  according  the
configured Meta Data length.

Caution
The length of the “PduInfoPtr” does not contain the “MetaDataLength” information. The
  length parameter represents the I-PDU total length. Each module must copy the
MetaData from the ”PduInfoPtr” according the configured “MetaDataLength”. Do not
use the length of the “PduInfoPtr” to copy “MetaData” from the “PduInfoPtr”.

Caution
The lower layer module must provide the complete payload in the CopyRxData()
  function

© 2017 Vector Informatik GmbH
Version 3.00.00
32
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
4  Integration
This chapter gives necessary information for the integration of the MICROSAR PDUR into
an application environment of an ECU.
4.1
Scope of Delivery
The delivery of the PDUR contains the files which are described in the chapters 4.1.1 and
4.1.2:
4.1.1
Static Files
File
Source Code  Description
Name  Delivery
PduR.c

This is the source file of the PDUR
PduR.h

This is the header file of PDUR
Table 4-1   Static files
4.1.2
Dynamic Files
The dynamic files are generated by the configuration tool DaVinci Configurator.
File Name
Description
PduR_Cfg.h
This file contains:
 global constant macros
 global function macros
 global data types and structures
 global data prototypes
 global function prototypes
of CONFIG-CLASS PRE-COMPILE data.
PduR_Lcfg.h
This file contains:
 global constant macros
 global function macros
 global data types and structures
 global data prototypes
 global function prototypes
of CONFIG-CLASS LINK data.
PduR_Lcfg.c
This file contains:
 local constant macros
 local function macros
 local data types and structures
 local data prototypes
 local data
 global data
of CONFIG-CLASS LINK and PRE-COMPILE data.
PduR_PBcfg.h
This file contains:
© 2017 Vector Informatik GmbH
Version 3.00.00
33
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
File Name
Description
 global constant macros
 global function macros
 global data types and structures
 global data prototypes
 global function prototypes
of CONFIG-CLASS POST-BUILD data.
PduR_PBcfg.c
This file contains:
 local constant macros
 local function macros
 local data types and structures
 local data prototypes
 local data
 global data
of CONFIG-CLASS POST-BUILD data.
PduR_Types.h  This file contains types and defines for the PduR.
PduR_<Up>.h    This is the interface header of the PduR to an Upper Layer Module.
PduR_<Lo>.h
This is the interface header of the PduR to a Lower Layer Module
Table 4-2   Generated files
4.2
Critical Sections
The critical section PDUR_EXCLUSIVE_AREA_0 has to lock global interrupts to protect
common critical sections.
4.3
Memory Section
With PDUR_START_SEC_BUFFER_VAR_NOINIT_8BIT and
PDUR_STOP_SEC_BUFFER_VAR_NOINIT_8BIT large Tx buffer can be mapped into an
own memory section.
4.4
Type Definitions
The types defined by the PDUR are described in this chapter.
Type Name
C-Type  Description
Value Range
PduR_RoutingPathGroupIdType  uint16
Identification of the routing path
unsigned int
group. Routing path groups are
defined in the
PDU router configuration.
Table 4-3   Type definitions
© 2017 Vector Informatik GmbH
Version 3.00.00
34
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
5  API Description
5.1
Services provided by PDUR
5.1.1
PduR_Init
Prototype
void PduR_Init (const PduR_PBConfigType* ConfigPtr)
Parameter
ConfigPtr
>  NULL_PTR in the PDUR_CONFIGURATION_VARIANT_PRECOMPILE
>  Pointer to the PduR configuration data in the
PDUR_CONFIGURATION_VARIANT_POSTBUILD_LOADABLE and
PDUR_CONFIGURATION_VARIANT_POSTBUILD_SELECTABLE
Return code
void
none
Functional Description
This function initializes the PDU Router and performs configuration consistency checks. If the initialization
is performed successfully the PDU Router is in the state PduR_IsInitialized else not PduR_IsInitialized.
Particularities and Limitations
The function is used by the Ecu State Manager
Caution
PduR_Init shall not pre-empt any PDU Router function.

Call Context
The function must be called on task level. To avoid problems calling the PDU Router module uninitialized it
is important that the PDU Router module is initialized before interfaced modules.
Table 5-1   PduR_Init
5.1.2
PduR_InitMemory
Prototype
void PduR_InitMemory (void)
Parameter
void
none
Return code
void
none
Functional Description
The function initializes variables, which cannot be initialized with the startup code.
Particularities and Limitations
The function is called by the application.
Call Context
© 2017 Vector Informatik GmbH
Version 3.00.00
35
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
The function must be called on task level.
Table 5-2   PduR_InitMemory
5.2
Services
5.2.1
PduR_GetVersionInfo
Prototype
void PduR_GetVersionInfo (Std_VersionInfoType* versioninfo)
Parameter
versioninfo
Pointer to where to store the version information of the PDU Router.
Return code
void
none
Functional Description
Returns the version information of the PDU Router.
Particularities and Limitations
The function is called by the application.
Call Context
The function can be called on interrupt and task level.
Table 5-3   PduR_GetVersionInfo
5.2.2
PduR_GetConfigurationId
Prototype
uint32 PduR_GetConfigurationId (void)
Parameter
void
none
Return code
uint32
uint32
Functional Description
Provides the unique identifier of the PDU Router configuration.
Particularities and Limitations
The function is called by the application.
Call Context
The function can be called on interrupt and task level.
Table 5-4   PduR_GetConfigurationId
5.2.3
PduR_EnableRouting
Prototype
void PduR_EnableRouting (PduR_RoutingPathGroupIdType id)
© 2017 Vector Informatik GmbH
Version 3.00.00
36
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
Parameter
id
Identification of the routing path group. Routing path groups are defined in the
PDU router configuration.
Return code
void
none
Functional Description
This function enables a routing path group. If the routing path group does not exist or is already enabled,
the function returns with no action.
Particularities and Limitations
The function is called by the BSW Mode Manager.
Call Context
The function can be called on interrupt and task level and has not to be interrupted by other
PduR_EnableRouting or PduR_DisableRouting calls for the same id.
Table 5-5 PduR_EnableRouting
5.2.4
PduR_DisableRouting
Prototype
void PduR_DisableRouting (PduR_RoutingPathGroupIdType id)
Parameter
id
Identification of the routing path group. Routing path groups are defined in the
PDU router configuration.
Return code
void
none
Functional Description
This function disables a routing path group. If the routing path group does not exist or is already disabled,
the function returns with no action.
Particularities and Limitations
The function is called by the BSW Mode Manager.
Call Context
The function can be called on interrupt and task level and has not to be interrupted by other
PduR_EnableRouting or PduR_DisableRouting calls for the same id.
Table 5-6 PduR_DisableRouting

© 2017 Vector Informatik GmbH
Version 3.00.00
37
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
5.3
Communication Interface
5.3.1
PduR_<GenericUp>Transmit
Prototype
Std_ReturnType PduR_<GenericUp>Transmit (PduIdType id, PduInfoType*
info)
Parameter
id
ID of the <GenericUp> I-PDU to be transmitted
info
Payload information of the I-PDU (pointer to data and data length)
Return code
Std_ReturnType
Std_ReturnType
E_OK The request was accepted by the PDU Router and by the destination
layer.
E_NOT_OK PduR_Init() has not been called
or the id is not valid
or the id is not forwarded in this identity
or the info is not valid
or the request was not accepted by the destination layer.
Functional Description
The function serves to request the transmission of a Communication Interface I-PDU. The PDU Router
evaluates the upper layer I-PDU handle and performs appropriate handle and port conversion. The call is
routed to a lower communication interface module using the appropriate I-PDU handle of the destination
layer.
Particularities and Limitations
The function is called by an upper layer.
Call Context
The function can be called on interrupt and task level and has not to be interrupted by other
PduR_<GenericUp>Transmit calls for the same upper layer id.
Table 5-7 PduR_<GenericUp>Transmit
5.3.2
PduR_<GenericLo>RxIndication
Prototype
void PduR_<GenericLo>RxIndication (PduIdType id, const PduInfoType*
info)
Parameter
id
Handle ID of the received <GenericLo> I-PDU.
info
Payload information of the received I-PDU (pointer to data and data length).
Return code
void
none
© 2017 Vector Informatik GmbH
Version 3.00.00
38
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
Functional Description
The function is called by a lower communication interface to indicate the complete reception of a lower
communication interface I-PDU. The PDU Router evaluates the lower communication interface I-PDU
handle and performs appropriate handle and port conversion. The call is routed to an upper communication
interface module using the appropriate I-PDU handle of the destination layer.
Particularities and Limitations
The function is called by a lower communication interface module.
Call Context
The function can be called on interrupt and task level and has not to be interrupted by other
PduR_<GenericLo>RxIndication calls for the same a lower communication interface id.
Table 5-8 PduR_<GenericLo>RxIndication
5.3.3
PduR_<GenericLo>TriggerTransmit
Prototype
void PduR_<GenericLo>TriggerTransmit (PduIdType id, PduInfoType* info)
Parameter
id
Handle ID of the <GenericLo> I-PDU that will be transmitted.
info
Contains a pointer to a buffer (SduDataPtr) to where the SDU data shall be
copied, and the available buffer size in SduLengh. On return, the service will
indicate the length of the copied SDU data in SduLength.
Return code
Std_ReturnType
E_OK: The SDU has been copied and the SduLength indicates the number of
copied bytes.
E_NOT_OK: No data has been copied, because PduR is not initialized or
TxPduId is not valid or PduInfoPtr is NULL_PTR or SduDataPtr is NULL_PTR
or SduLength is too small.
Functional Description
The function is called by a lower layer communication interface to request the TX I-PDU data before
transmission. The PDU Router evaluates the lower layer communication interface I-PDU handle and
performs appropriate handle and port conversion. The call is routed to an upper IF module using the
appropriate I-PDU handles of the destination layer.
Particularities and Limitations
The function is called by a lower layer communication interface
Call Context
The function can be called on interrupt and task level and has not to be interrupted by other
PduR_<GenericLo>TriggerTransmit calls for the same id.
Table 5-9 PduR_<GenericLo>TriggerTransmit

© 2017 Vector Informatik GmbH
Version 3.00.00
39
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
5.3.4
PduR_<GenericLo>TxConfirmation
Prototype
void PduR_<GenericLo>TxConfirmation (PduIdType id)
Parameter
id
Handle ID of the transmitted lower layer communication interface I-PDU.
Return code
void
none
Functional Description
The function is called by a lower communication interface to confirm the complete transmission of a lower
communication interface I-PDU. The PDU Router evaluates the lower communication interface I-PDU
handle and performs appropriate handle and port conversion. The call is routed to an upper layer
communication interface module using the appropriate I-PDU handle of the destination layer.
Particularities and Limitations
The function is called by a lower communication interface module.
Call Context
The function can be called on interrupt and task level and has not to be interrupted by other
PduR_<GenericLo>TxConfirmation calls for the same lower layer communication interface id.
Table 5-10 PduR_<GenericLo>TxConfirmation

© 2017 Vector Informatik GmbH
Version 3.00.00
40
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
5.4
Transport Protocol
This  chapter  describes  the  interfaces  provided  to  Upper  Layers  (e.g.  Dcm,  ApplTp  and
Cdds). Replace the tag <UpTp> by the MSN of the Upper Layer.

5.4.1
PduR_<GenericUpTp>ChangeParameter
Prototype
Std_ReturnType PduR_<GenericUpTp>ChangeParameter (PduIdType id,
TPParameterType parameter, uint16 value)
Parameter
id
ID of the <UpTp> I-PDU where the parameter has to be changed
parameter
The TP parameter that shall be changed.
value
The new value for the TP parameter.
Return code
Std_ReturnType
Std_ReturnType
E_OK: The parameter was changed successfully.
E_NOT_OK: The parameter change was rejected.
Functional Description
The function serves to change a specific transport protocol parameter (e.g. block-size).
The PDU Router evaluates the <UpTp> I-PDU handle and performs appropriate handle and port
conversion. The call is routed to a lower TP module using the appropriate I-PDU handle of the destination
layer.
Particularities and Limitations
The function is called by <UpTp>.
Call Context
This function can be called on interrupt and task level and has not to be interrupted by other
PduR_<UpTp>ChangeParameter calls for the same id.
Table 5-11   PduR_<GenericUpTp>ChangeParameter
5.4.2
PduR_<GenericUpTp>CancelReceive
Prototype
Std_ReturnType PduR_<GenericUpTp>CancelReceive (PduIdType id)
Parameter
id
ID of the RX <GenericUp> I-PDU to be cancelled
Return code
Std_ReturnType
Std_ReturnType
E_OK:       Cancellation was executed successfully by the destination module.
E_NOT_OK: Cancellation was rejected by the destination module.
© 2017 Vector Informatik GmbH
Version 3.00.00
41
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
Functional Description
The function serves to cancel the reception of a TP layer I-PDU.
The PDU Router evaluates the upper layer transport protocol I-PDU handle and performs appropriate
handle and port conversion. The call is routed to a lower TP module using the appropriate I-PDU handle of
the destination layer.
Particularities and Limitations
The function is called by an upper layer transport protocol module.
Call Context
The function can be called on interrupt and task level and has not to be interrupted by other
PduR_<GenericUpTp>CancelReceive calls for the same upper layer id.
Table 5-12   PduR_<GenericUpTp>CancelReceive
5.4.3
PduR_<GenericUpTp>CancelTransmit
Prototype
Std_ReturnType PduR_<GenericUpTp>CancelTransmit (PduIdType id)
Parameter
id
ID of the TX upper layer I-PDU of the routing that must be cancelled in the
lower layer
Return code
Std_ReturnType
Std_ReturnType
E_OK The cancellation request was accepted by the PDU Router and by the
TP layer.
E_NOT_OK PduR_Init() has not been called
or the id is not valid
or the id is not forwarded in this identity
or the request was not accepted by the TP layer.
Functional Description
The function serves to cancel the transmission of a TP layer I-PDU.
The PDU Router evaluates the upper layer transport protocol I-PDU handle and performs appropriate
handle and port conversion. The call is routed to a lower TP module using the appropriate I-PDU handle of
the destination layer.
Particularities and Limitations
The function is called by an upper layer transport protocol module
Call Context
The function can be called on interrupt and task level and has not to be interrupted by other
PduR_<GenericUpTp>CancelTransmit calls for the same upper layer id.
Table 5-13   PduR_<GenericUpTp>CancelTransmit
© 2017 Vector Informatik GmbH
Version 3.00.00
42
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
5.4.4
PduR_<GenericLoTp>StartOfReception
Prototype
BufReq_ReturnType PduR_<GenericLoTp>StartOfReception (PduIdType id,
PduInfoType info, PduLengthType TpSduLength, PduLengthType*
bufferSizePtr)
Parameter
id
ID of the <GenericLo> I-PDU that will be received.
info
Pointer to the buffer (SduDataPtr) contains MetaData if this feature is enabled.
TpSduLength
Length of the entire <GenericLo> TP SDU which will be received
bufferSizePtr
Pointer to the receive buffer in the receiving module.
This parameter will be used to compute Block Size (BS) in the transport
protocol module.
Return code
BufReq_ReturnType
BufReq_ReturnType BUFREQ_OK Connection has been accepted.
bufferSizePtr indicates the available receive buffer.
BUFREQ_E_NOT_OK PduR_Init() has not been called
or the id is not valid
or the id is not forwarded in this identity
or the info is not valid
or the request was not accepted by the upper layer.
or no buffer is available
Functional Description
This function will be called by the lower layer at the start of receiving an I-PDU. The I-PDU might be
fragmented into multiple N-PDUs (FF with one or more following CFs) or might consist of a single N-PDU
(SF).
Particularities and Limitations
The function is called by lower layer transport protocol module.
Call Context
The function can be called on interrupt and task level and has not to be interrupted by other
PduR_<GenericLoTp>StartOfReception calls for the same lower layer transport protocol id.
Table 5-14 PduR_<GenericLoTp>StartOfReception
5.4.5
PduR_<GenericLoTp>CopyRxData
Prototype
BufReq_ReturnType PduR_<GenericLoTp>CopyRxData (PduIdType id,
PduInfoType* info, PduLengthType* bufferSizePtr)
Parameter
id
ID of the lower layer transport protocol I-PDU that will be received.
info
Pointer to the buffer (SduDataPtr) and its length (SduLength) containing the
data to be copied by PDU Router module in case of gateway or upper layer
module in case of reception.
bufferSizePtr
Available receive buffer after data has been copied.
© 2017 Vector Informatik GmbH
Version 3.00.00
43
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
Return code
BufReq_ReturnType
BufReq_ReturnType
BUFREQ_OK Buffer request accomplished successful.
BUFREQ_E_NOT_OK PduR_Init() has not been called
or the id is not valid
or the id is not forwarded in this identity
or the info is not valid
or the request was not accepted by the upper layer.
or the request length to copy is greater than the remaining buffer size
BUFREQ_E_OVFL The upper TP module is not able to receive the number of
bytes. The request was not accepted by the upper layer.
Functional Description
This function is called by the lower layer transport protocol if data has to be copied to the receiving module.
Parallel routing of several I-PDU is possible.
Particularities and Limitations
The function is called by lower layer transport protocol
Call Context
The function can be called on interrupt and task level and has not to be interrupted by other
PduR_<GenericLoTp>CopyRxData calls for the same lower layer transport protocol id.
Table 5-15 PduR_<GenericLoTp>CopyRxData
5.4.6
PduR_<GenericLoTp>CopyTxData
Prototype
BufReq_ReturnType PduR_<GenericLoTp>CopyTxData (PduIdType id,
PduInfoType* info, RetryInfoType* retry, PduLengthType*
availableDataPtr)
Parameter

id
ID of the lower layer I-PDU that will be transmitted.
info
Pointer to the destination buffer and the number of bytes to copy.
In case of gateway the PDU Router module will copy otherwise the source
upper layer module will copy the data. If not enough transmit data is available,
no data is copied. The transport protocol module will retry.
A size of copy size of “0” can be used to indicate state changes in the retry
parameter.
retry
retry not supported yet, is always a NULL_PTR.
availableDataPtr
Indicates the remaining number of bytes that are available in the PDU Router
Tx buffer.
© 2017 Vector Informatik GmbH
Version 3.00.00
44
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
Return code
BufReq_ReturnType
BufReq_ReturnType
BUFREQ_OK The data has been copied to the transmit buffer successful.
BUFREQ_E_NOT_OK PduR_Init() has not been called
or the id is not valid
or the id is not forwarded in this identity
or the info is not valid
or the request was not accepted by the upper layer and no data has been
copied.
BUFREQ_E_BUSY The request cannot be processed because the TX data is
not available and no data has been copied. The TP layer might retry later the
copy process.
Functional Description
This function is called by a lower layer transport protocol module to query the transmit data of an I-PDU
segment.
Particularities and Limitations
The function is called by a lower layer transport protocol module.
Call Context
The function can be called on interrupt and task level and has not to be interrupted by other
PduR_<GenericLoTp>CopyTxData calls for the same a lower layer transport protocol module id.
Table 5-16   PduR_<GenericLoTp>CopyTxData
5.4.7
PduR_<GenericLo>TpTxConfirmation
Prototype
void PduR_<GenericLo>TpTxConfirmation (PduIdType id, Std_ReturnType
result)
Parameter
id
ID of the <GenericLo> I-PDU that will be transmitted.
result
Result of the TP transmission
E_OK           The TP transmission has been completed successfully.
E_NOT_OK PduR_Init() has not been called
         or the transmission was aborted
         or the id is not valid
         or the id is not forwarded
         or the request was not accepted by the destination upper layer.
Return code
void
none
© 2017 Vector Informatik GmbH
Version 3.00.00
45
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
Functional Description
The function is called by a lower layer transport protocol module to confirm a successful transmission of a
lower layer transport protocol module TX SDU or to report an error that occurred during transmission. The
PDU Router evaluates the lower layer transport protocol module I-PDU handle and performs appropriate
handle and port conversion. The call is routed to an upper TP module using the appropriate I-PDU handle
of the destination layer.
Particularities and Limitations
The function is called by a lower layer transport protocol module.
Call Context
The function can be called on interrupt and task level and has not to be interrupted by other
PduR_<GenericLo>TpTxConfirmation calls for the same the lower layer transport protocol module id.
Table 5-17   PduR_<GenericLo>TpTxConfirmation
5.4.8
PduR_<GenericLo>TpRxIndication
Prototype
void PduR_<GenericLo>TpRxIndication (PduIdType id, Std_ReturnType
result)
Parameter
id
ID of the <GenericLo> I-PDU that will be received.
result
Result of the TP reception
E_OK        The TP reception has been completed successfully.
E_NOT_OK PduR_Init() has not been called
        or the reception was aborted
        or the id is not valid
        or the id is not forwarded
        or the request was not accepted by the destination upper layer.
Return code
void
none
Functional Description
The function is called by the lower layer transport protocol module to indicate the complete reception of a
lower layer transport protocol module SDU or to report an error that occurred during reception. The PDU
Router evaluates the lower layer transport protocol module I-PDU handle and performs appropriate handle
and port conversion. The call is routed to an upper TP module using the appropriate I-PDU handle of the
destination layer.
Particularities and Limitations
The function is called by a lower layer transport protocol module.
Call Context
The function can be called on interrupt and task level and has not to be interrupted by other
PduR_<GenericLo>TpRxIndication calls for the same lower layer transport protocol module.
Table 5-18   PduR_<GenericLo>TpRxIndication

© 2017 Vector Informatik GmbH
Version 3.00.00
46
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
5.4.9
PduR_<GenericUpTp>Transmit
Prototype
Std_ReturnType PduR_<GenericUpTp>Transmit (PduIdType id, PduInfoType*
info)
Parameter
id
ID of the upper layer I-PDU that have to be transmitted
info
Payload information of the I-PDU (pointer to data and data length)
Return code
Std_ReturnType
Std_ReturnType
E_OK The request was accepted by the PDU Router and by the destination
layer.
E_NOT_OK PduR_Init() has not been called
or the id is not valid
or the id is not forwarded in this identity
or the info is not valid
or the request was not accepted by the TP layer.
Functional Description
The function serves to request the transmission of a TP layer I-PDU.
The PDU Router evaluates the incoming I-PDU ID and performs appropriate ID and port conversion. The
call is routed to the TP layer using the appropriate I-PDU handle of the destination layer.
Particularities and Limitations
The function is called by an upper layer transport protocol module.
Call Context
The function can be called on interrupt and task level and has not to be interrupted by other
PduR_<GenericUpTp>Transmit calls for the same an upper layer transport protocol module id.
Table 5-19 PduR_<GenericUpTp>Transmit

© 2017 Vector Informatik GmbH
Version 3.00.00
47
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
5.5
Service Ports
5.5.1
Complex Device Driver Interaction
Besides  the  AUTOSAR  modules,  Complex  Device  Drivers  (CDD)  are  also  possible  as
upper  layer  and  lower  transport  protocol  or  communication  interface  modules  for  the
PduR. When a callout function of the PduR is invoked from a lower or upper layer module
for a PDU that is transmitted or received by a CDD, the PduR invokes the corresponding
target function of the CDD. If all PDUs transmitted or received by a CDD are referenced by
communication interface modules, the CDD requires a communication interface API.  If all
PDUs transmitted or received by a CDD are referenced by transport protocol modules, the
CDD requires a transport protocol API.
A  CDD  can  either  require  a  communication  interface  API  or  it  can  require  a  transport
protocol API but not both. The API functions provided by the PduR for the CDD interaction
contain the CDD’s name.
© 2017 Vector Informatik GmbH
Version 3.00.00
48
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
6  Configuration
6.1
Use Case Configuration: Communication interface range gateway
The PduR routing paths configuration is typically focused on the routing of dedicated Pdus
and  their  bus-specific  representation  (e.g.  the  concrete  CAN  ID,  DLC,  …).  For  some
network  and  communication  architectures  it  might  be  helpful  to  avoid  the  dedicated
configuration of all possible and required PduR routing paths. Especially if a huge amount
of  Pdus  shall  be  routed  between  networks,  the  PduR  routing  paths  configuration  gets
extensive, error-prone and requires a lot of hardware resources (ROM / RAM).
To overcome this situation, so called range-routings could be used. For the routing of a full
Pdu range between two networks just single PduR routing path needs to be configured.
Technically, the range-routing is based on the usage of MetaData information appended to
the  Pdu  data  field.  During  Pdu  reception  the  related  bus  interface  module  stores  all
required  Pdu  meta  information  (the  CAN  ID)  in  the  MetaData  part  of  the  Pdu  data  field.
The  PduR  itself  performs  the  routing  of  the  full  Pdu  data  field,  including  the  MetaData.
During  transmission  the  related  bus  interface  module  uses  the  MetaData  information  for
dynamic  adaptation  (the  CAN  ID)  of  the  transmitted  bus  Pdu.  The  range  of  the  routed
Pdus is defined by the bus interface specific Rx Pdu range. In case of CanIf,  the CAN ID
Rx filter is used to define the range. Figure 6-1 visualizes the range-routing technique.

PduR
CanIf
Store Rx
Use stored CAN ID
CAN ID in
from meta data for
Payload
CAN ID
MetaData
meta data
transmission
Pdu
CAN ID
Pdu
CAN ID
Rx ID mask
filter
Routed CAN ID is identical

Figure 6-1  Meta data routing with CanIf

Limitations
There are some limitations when using the described range-routing technique:
   Available for CAN only
 No CAN ID conversion possible
 No length conversion possible
 No dynamic PDU lengths possible

© 2017 Vector Informatik GmbH
Version 3.00.00
49
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
6.1.1
Step-by-step configuration

Configuration Example
  All following step-by-step instructions are based on this range-routing example:
CAN ID  CAN ID  DLC  Source network /  Destination network(s) / channel(s)
code
mask
channel
0x700
0x708
8
CAN0
CAN1, CAN2
0x708
0x708
8
CAN1
CAN0
0x708
0x708
8
CAN2
CAN0
Table 6-1   Example range routings
The CAN ID range is defined by the condition
<received CAN-ID> & <mask> == <code> & <mask>

The following step-by-step configurations steps will result in the following CanIf / PduR
range routing architecture shown in Figure 6-2.
1:N routing path
PduR
Tx FIFO
Tx FIFO
Tx FIFO
Tx FIFO
CAN1
CAN2
CAN2_to_C
CAN1_to_C
AN0
AN0
CanIf
Rx range
Rx range
ID
0x700
ID
0x708
mask 0x708
mask 0x708
CAN0 Rx
CAN1 Tx
CAN2 Tx
CAN1 Rx
CAN2 Rx
CAN0 Tx

Figure 6-2  CanIf / PduR range routing example overview

Derived model elements / Validation and solving actions
  During project setup the EcuC configuration will be automatically derived from the
provided input files. Therefore some of the following manual configuration steps are
redundant. In this case, please extend or adapt the existing configuration containers
and parameters to the described step-by-step configuration.
Parameters and containers which will be created and configured by background-
validations are not described explicitly. Please finalize all manual configuration steps
before solving the open validations results. Use the provided solving actions.

© 2017 Vector Informatik GmbH
Version 3.00.00
50
based on template version 4.9.2

Technical Reference MICROSAR PDU Router

Create global Pdus
 Create global Pdus for every required range routing source and destination channel.
Global Pdu container: /MICROSAR/EcuC/EcucPduCollection/Pdu
 Create and configure a MetaData length. 2 bytes are required for standard CAN IDs,
4 bytes are required for extended CAN identifiers.
MetaData length: /MICROSAR/EcuC/EcucPduCollection/Pdu/MetaDataLength
 Configure the Pdu length to the Pdu payload length.
Pdu length: /MICROSAR/EcuC/EcucPduCollection/Pdu/PduLength
For the example configuration this results in the following global Pdu configuration:

© 2017 Vector Informatik GmbH
Version 3.00.00
51
based on template version 4.9.2

Technical Reference MICROSAR PDU Router

Create CanIf Rx Pdus
    Create a CanIf Rx Pdu for every required range routing source channel.
CanIf Rx Pdu container: /MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg
 Configure the Rx CAN ID range by the CAN ID code and the CAN ID mask
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduCanId
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduCanIdMask
The CAN ID range is defined by the filter condition
<received CAN-ID> & <mask> == <code> & <mask>
 Configure the CAN ID type (standard or extended) and the DLC with the parameters
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduCanIdType
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduDlc
 Reference the related channel specific Rx global Pdu created in the previous steps
with the parameter
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduRef
  Reference the related CAN channel hardware receive object (HRH) used for
reception of the range Pdus with the parameter
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduHrhIdRef
 Assign the PduR as upper layer user with the parameter /MICROSAR/CanIf/
CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduUserRxIndicationUL

For the example configuration this results in the following CanIf Rx Pdu configuration:

Create CanIf Tx Pdus
    Create a CanIf Tx Pdu for every required range routing destination channel.
CanIf Tx Pdu container: /MICROSAR/CanIf/CanIfInitCfg/CanIfTxPduCfg
 Configure the Tx CAN ID used for prioritization of this dynamic Tx Pdu against other
static Pdus with the parameter
/MICROSAR/CanIf/CanIfInitCfg/CanIfTxPduCfg/CanIfTxPduCanId
Use the highest priority CAN ID of the routing range for this prioritization ID.
  Configure the CAN DLC with the parameter
/MICROSAR/CanIf/CanIfInitCfg/CanIfTxPduCfg/CanIfTxPduDlc
 Reference the related global Pdu created in the previous steps with the parameter
/MICROSAR/CanIf/CanIfInitCfg/CanIfTxPduCfg/CanIfTxPduRef
 Reference the related channel specific CanIf Tx buffer object used for transmission
of the range Pdus with the parameter
/MICROSAR/CanIf/CanIfInitCfg/CanIfTxPduCfg/CanIfTxPduBufferRef

For the example configuration this results in the following CanIf Tx Pdu configuration:

© 2017 Vector Informatik GmbH
Version 3.00.00
52
based on template version 4.9.2

Technical Reference MICROSAR PDU Router

Create PduR routing paths
Finally create the PduR routing paths connecting the CanIf Rx and Tx range Pdus. A
single PduR routing path for every channel specific range routing is required.
 Create a PduR routing path:
/MICROSAR/PduR/PduRRoutingTables/PduRRoutingTable/PduRRoutingPath
 Reference the related channel specific Rx global Pdu at the routing path source:
/MICROSAR/PduR/PduRRoutingTables/PduRRoutingTable/PduRRoutingPath/Pd
uRSrcPdu/PduRSrcPduRef
 Reference the related channel specific Tx global Pdu at the routing path destination:
/MICROSAR/PduR/PduRRoutingTables/PduRRoutingTable/PduRRoutingPath/Pd
uRDestPdu/PduRDestPduRef

For the example configuration this results in the following PduR routing path
configuration:
RoutingPath
RoutingPath Source
RoutingPath Destination(s)
Global Pdu
Global Pdu(s)
RP_RangeRouting_ RxRangePdu_CAN0
TxRangePdu_CAN0_to_CAN1,
CAN0_to_CAN1_2
TxRangePdu_CAN0_to_CAN2
RP_RangeRouting_ RxRangePdu_CAN1
TxRangePdu_CAN1_to_CAN0
CAN1_to_CAN0
RP_RangeRouting_ RxRangePdu_CAN2
TxRangePdu_CAN2_to_CAN0
CAN2_to_CAN0

For further details regarding the PduR communication interface gateway, please refer
to chapter 3.6.

© 2017 Vector Informatik GmbH
Version 3.00.00
53
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
6.1.2
Optional configuration variants / options

[Optional] Configure PduR FIFO routing
  In case the sequence of successive routed range Pdus shall be retained, a
FIFO queue must be configured within the PduR.
  Create PduR Tx buffer (FIFO) for every range routing destination channel:
/MICROSAR/PduR/PduRRoutingTables/PduRTxBufferTable/PduRTxBuffer
  Configure the Tx buffer length to the length of the routed global Pdu
(including the MetaData length):
/MICROSAR/PduR/PduRRoutingTables/PduRTxBufferTable/PduRTxBuffer/Pdu
RPduMaxLength
  Configure the Tx buffer depth to the maximum expected amount of queued
Pdus (see also chapter 3.6.2):
/MICROSAR/PduR/PduRRoutingTables/PduRTxBufferTable/PduRTxBuffer/Pdu
RTxBufferDepth

  Reference the created Tx buffers at the related PduR range routing paths:
/MICROSAR/PduR/PduRRoutingTables/PduRRoutingTable/PduRRoutingPath/P
duRDestPdu/PduRDestTxBufferRef



© 2017 Vector Informatik GmbH
Version 3.00.00
54
based on template version 4.9.2

Technical Reference MICROSAR PDU Router

[Optional] CAN priority inversion
    Enable the CanIf feature „Cancellation of PDUs and requeueing” in order to
avoid inner priority inversion:
/MICROSAR/CanIf/CanIfCtrlDrvCfg/CanIfCtrlDrvTxCancellation

  Enable the CAN driver feature „Multiplexed Transmission“ in order to avoid
external priority inversion:
/MICROSAR/<CAN_Platform>/Can/CanGeneral/CanMultiplexedTransmission

If this feature is enabed, multiple hardware objects are used for
transmission of a single logical Tx object.
Hint: These features are not supported by all CAN controllers. Please refer to
[7] and [8].

[Optional] Alternative CanIf Rx range configuration method
  Depending on the required CAN ID range, the range can also be configured using an
upper- and lower layer ID using the following container / parameters:
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduCanIdRange
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduCanIdRange/CanIfR
xPduCanIdRangeLowerCanId
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduCanIdRange/CanIfR
xPduCanIdRangeUpperCanId

In case of this alternative range configuration method, the previously used range
configuration parameters must not be used:
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduCanId
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduCanIdMask

For further details about the CanIf and CAN driver modules, please refer to [7] and [8].
© 2017 Vector Informatik GmbH
Version 3.00.00
55
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
6.2
Use Case Configuration: Functional requests gateway routing
Gateway  ECUs  typically  include  diagnostic  services,  handling  physical  and  functional
addressed  requests  used  by  external  diagnostic  tools  during  the  development,
manufacturing and service.
Functionally addressed request messages are a kind of broadcast requests which shall be
processed  by  all  (or  a  dedicated  set  of)  ECUs. Typically  this  includes  the  gateway  ECU
itself  as  well.  In  case  the  ECUs  are  distributed  on  multiple  CAN  networks,  the  gateway
ECU  needs  to  handle  the  broadcasting  of  the  request  messages  to  the  connected  sub-
network as well as the handling of the functional requests by the gateway-own diagnostic
handler.
Gateway ECU
Diagnostic  handler
ECU A
Diagnostic
Diagnostic
ECU B
handler
Tool
Diagnostic
handler
functional  requests
CAN 0
CAN 1
CAN 2

Figure 6-3  Example functional requests gateway network architecture
To realize the gateway behavior as visualized in Figure 6-3, a PduR 1:N transport protocol
gateway could be configured, as shown in Figure 6-4.
Dcm
Service  handler
PduR
1:N routing path
CanTp
Physical request
Functional request  handler
handler
CanIf
Physical request /
Functional request
response message
message

Figure 6-4  Functional request gateway architecture

Handling of physically addressed diagnostic messages
Routing of physically addressed diagnostic messages is not focus of this chapter.
  Please refer to chapter 6.1 introducing range-routing paths which could be used for
efficient and simple routing of physically addressed diagnostic messages.

© 2017 Vector Informatik GmbH
Version 3.00.00
56
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
6.2.1
Step-by-step configuration

Configuration Example
  All following step-by-step instructions are based on the following functional diagnostic
routing example:
Functional diagnostic
DLC  Source network /
Destination network(s) /
request ID
channel
channel(s)
0x7DF
8
CAN0
CAN1, CAN2
Table 6-2
Example functional diagnostic request routing

Derived model elements / Validation and solving actions
  During project setup the EcuC configuration will be automatically derived from the
provided input files. Therefore some of the following manual configuration steps are
redundant. In this case, please extend or adapt the existing configuration containers
and parameters to the described step-by-step configuration.
Parameters and containers which will be created and configured by background-
validations are not described explicitly. Please finalize all manual configuration steps
before solving the open validations results. Use the provided solving actions.

Create global Pdus / Sdus
    Create two global Pdus for the received functional request. The first global Pdu
interconnects the CanIf and CanTp receive paths. The second global Pdu (Sdu)
interconnects the CanTp, PduR and the related diagnostic handler (e.g. Dcm).
Global Pdu container: /MICROSAR/EcuC/EcucPduCollection/Pdu
This step is optional if the own functional request routing path was automatically
derived based on input files during project setup.
 Create a pair of global Pdus (Pdu and Sdu) for every destination channel where the
functional requests shall be routed to.
  Configure the Pdu length to the CAN frame length of the functional request
message. The length of the Sdu (interconnection between CanTp, PduR and the
related diagnostic handler) shall be the length of transport protocol payload.
Pdu length: /MICROSAR/EcuC/EcucPduCollection/Pdu/PduLength

For the example configuration this results in the following global Pdu configuration:

© 2017 Vector Informatik GmbH
Version 3.00.00
57
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
Create CanIf Rx Pdus
  The following steps are optional if the own functional request routing path was
automatically derived based on input files during project setup.

 Create a CanIf Rx Pdu for the functional diagnostic request message.
CanIf Rx Pdu container: /MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg
 Configure the static Rx CAN ID of the functional request message
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduCanId
 Configure the CAN ID type (standard or extended) and the DLC with the parameters
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduCanIdType
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduDlc
 Reference the related functional request Rx global Pdu created in the previous
steps with the parameter
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduRef
  Reference the related CAN channel hardware receive object (HRH) used for
reception of the functional request message with the parameter
/MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduHrhIdRef
 Assign the CanTp as upper layer user with the parameter /MICROSAR/CanIf/
CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduUserRxIndicationUL

For the example configuration this results in the following CanIf Rx Pdu configuration:

Create CanIf Tx Pdus
    Create a CanIf Tx Pdu for every destination channel where the functional requests
shall be routed to:
CanIf Tx Pdu container: /MICROSAR/CanIf/CanIfInitCfg/CanIfTxPduCfg
 Configure the static Tx CAN ID of the functional request message with the
parameter
/MICROSAR/CanIf/CanIfInitCfg/CanIfTxPduCfg/CanIfTxPduCanId
  Configure the CAN DLC with the parameter
/MICROSAR/CanIf/CanIfInitCfg/CanIfTxPduCfg/CanIfTxPduDlc
 Reference the related functional request Tx global Pdu created in the previous steps
with the parameter
/MICROSAR/CanIf/CanIfInitCfg/CanIfTxPduCfg/CanIfTxPduRef
 Reference the related channel specific CanIf Tx buffer object used for transmission
of the functional request message with the parameter
/MICROSAR/CanIf/CanIfInitCfg/CanIfTxPduCfg/CanIfTxPduBufferRef
 Assign the CanTp as upper layer user with the parameter /MICROSAR/CanIf/
CanIfInitCfg/CanIfTxPduCfg/CanIfTxPduUserTxConfirmationUL

For the example configuration this results in the following CanIf Tx Pdu configuration:

© 2017 Vector Informatik GmbH
Version 3.00.00
58
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
Create CanTp Rx channel
The following steps are optional if the own functional request routing path was
  automatically derived based on input files during project setup.
 Create a CanTp Rx channel for the functional request
CanTp Rx channel container: /MICROSAR/CanTp/CanTpConfig/CanTpChannel
 Create a CanTp Rx N-Sdu container below the previously created Rx channel:
/MICROSAR/CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu
 Reference the related global Pdu (Sdu, interconnecting the CanTp, PduR and
diagnostic handler) created in the previous steps with the parameter
/MICROSAR/CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu/CanTpRxNSduRef
 Configure the Rx Sdu as functional communication type with the parameter
/MICROSAR/CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu/CanTpRxTaType

 Reference the related global Pdu (interconnecting the CanIf and CanTp) created in
the previous steps with the parameter /MICROSAR/CanTp/CanTpConfig/
CanTpChannel/CanTpRxNSdu/CanTpRxNPdu/CanTpRxNPduRef

For further information regarding the CanTp timing configuration parameters please
refer to [9].

© 2017 Vector Informatik GmbH
Version 3.00.00
59
based on template version 4.9.2

Technical Reference MICROSAR PDU Router

Create CanTp Tx channels
    Create a CanTp Tx channel for every destination channel where the functional
requests shall be routed to.
CanTp Tx channel container: /MICROSAR/CanTp/CanTpConfig/CanTpChannel
  Set the channel mode of the created Tx channel to half-duplex mode:
/MICROSAR/CanTp/CanTpConfig/CanTpChannel/CanTpChannelMode

 Create a CanTp Tx N-Sdu container below the previously created Tx channel:
/MICROSAR/CanTp/CanTpConfig/CanTpChannel/CanTpTxNSdu
 Reference the related global Pdu (Sdu, interconnecting the CanTp, PduR and
diagnostic handler) created in the previous steps with the parameter
/MICROSAR/CanTp/CanTpConfig/CanTpChannel/CanTpTxNSdu/CanTpTxNSduRef
 Configure the Tx Sdu as functional communication type with the parameter
/MICROSAR/CanTp/CanTpConfig/CanTpChannel/CanTpTxNSdu/CanTpTxTaType

 Reference the related global Pdu (interconnecting the CanIf and CanTp) created in
the previous steps with the parameter /MICROSAR/CanTp/CanTpConfig
/CanTpChannel/CanTpTxNSdu/CanTpTxNPdu/CanTpTxNPduRef

For further information regarding the CanTp timing configuration parameters please
refer to [9].

© 2017 Vector Informatik GmbH
Version 3.00.00
60
based on template version 4.9.2

Technical Reference MICROSAR PDU Router

Create a PduR TP buffer
  The following steps are optional if sufficient TP buffers are already configured.
 Create a new PduR TP buffer which will be used for the TP gateway routing of the
functional request messages.
/MICROSAR/PduR/PduRRoutingTables/PduRTpBufferTable/PduRTpBuffer
 Configure the size of TP buffer to the TP payload length of the functional requests.
In case of CanTp the buffer size must be at least 7 bytes.

Please refer to chapter 3.7.3 for further details regarding the TP buffer configuration.

Create / Extend PduR routing path
  Finally create a PduR 1:N routing path. This 1:N routing path shall route the received
functional diagnostic requests to the gateway-own diagnostic application and all
connected destination channels.
In case the functional request routing path for the gateway-own diagnostic application
was derived automatically the first steps describing the creation of a routing path can
be skipped. Proceed with the configuration of the additional routing destinations.
 Create the PduR routing path:
/MICROSAR/PduR/PduRRoutingTables/PduRRoutingTable/PduRRoutingPath
 Reference the related functional request Rx global Pdu (Sdu, interconnecting the
CanTp, PduR and diagnostic handler) at the routing path source:
/MICROSAR/PduR/PduRRoutingTables/PduRRoutingTable/PduRRoutingPath/Pd
uRSrcPdu/PduRSrcPduRef
and the routing path destination:
/MICROSAR/PduR/PduRRoutingTables/PduRRoutingTable/PduRRoutingPath/Pd
uRDestPdu/PduRDestPduRef
This step is optional if the own functional request routing path was automatically
derived based on input files during project setup.
 Add a new routing destination to the previously created routing path for every
destination channel the functional requests shall be routed to
PduR routing path destination: /MICROSAR/PduR/
PduRRoutingTables/PduRRoutingTable/PduRRoutingPath/PduRDestPdu
and reference the related functional request Tx global Pdu (Sdu) at the new routing
path destination:
/MICROSAR/PduR/PduRRoutingTables/PduRRoutingTable/PduRRoutingPath/Pd
uRDestPdu/PduRDestPduRef
 Configure the TP threshold value of the created gateway routing path to the value 1.
Please refer to chapter 3.7.2 for further details of the TP threshold configuration.
/MICROSAR/PduR/PduRRoutingTables/PduRRoutingTable/PduRRoutingPath/Pd
uRDestPdu/PduRTpThreshold

© 2017 Vector Informatik GmbH
Version 3.00.00
61
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
For the example configuration this results in the following PduR routing path
configuration:
RoutingPath
RoutingPath Source
RoutingPath Destination(s) Global
Global Pdu
Pdu(s)
RP_FuncReq_CAN
RxSdu_FuncReq_CAN0 RxSdu_FuncReq_CAN0
0_to_CAN1_2
(gateway-own diagnostic application),
TxSdu_FuncReq_CAN1,
TxSdu_FuncReq_CAN2

For further details about the CanIf and CanTp modules, please refer to [7] and [9].

© 2017 Vector Informatik GmbH
Version 3.00.00
62
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
6.3
Use Case Configuration: N:1 routing path
N:1  routing  paths  are  not  specified  by  AUTOSAR.  The  multiplicity  of  a  PduRSrcPdu
container is defined to one. Therefore N single 1:1/1:M routing paths (mixture of 1:M/N:1
routing paths is supported) referencing the same global Pdu in one of their PduRDestPdu
container  must  be  configured.  Every  PduRSrcPdu  container  must  reference  their  own
global PDU, duplicates are not allowed. Whereas more than one PduRDestPdu container
may  reference  the  same  global  PDU  to  support  the  N:1  routing  feature.  An  example
configuration is shown in Figure 6-5. Both configured routing paths are 1:2 routing paths,
but  both  routing  paths  refer  to  the  same  global  PDU  in  one  of  their  two  PduRDestPdu
container. That makes them also a 2:1 routing path. The data flow is shown in Figure 6-6.
The names refer to the example configuration in Figure 6-5.

Cancel Transmit for N:1 routing paths is only supported if a Tx Confirmation is enabled.

Figure 6-5: example N:1 routing path configuration
© 2017 Vector Informatik GmbH
Version 3.00.00
63
based on template version 4.9.2

Technical Reference MICROSAR PDU Router

Figure 6-6 EcuC configuration of (mixed) N:1 / 1:N routing paths
© 2017 Vector Informatik GmbH
Version 3.00.00
64
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
7  AUTOSAR Standard Compliance
7.1
Deviations
 The API PduR_<User:LoTp>StartOfReception is implemented according to
SWS_PduR_00507 ASR 4.1.2 [3]
 The PduR does not provide the return value  “BUFREQ_E_BUSY” for the function
PduR_<User:LoTp>StartOfReception like specified in Requirement PDUR507 in  [1].
 The parameter list contains a PduInfoType

 The API PduR_<User:LoTp>RxIndication is implemented according to
SWS_PduR_00375 ASR 4.1.2 [3]
 Result type changed to Std_ReturnType

 The API PduR_<User:LoTp>TxConfirmation is implemented according to
SWS_PduR_00381 ASR 4.1.2 [3]
 Result type changed to Std_ReturnType

 The PduR does not provide the return value “BUFREQ_E_BUSY” for the function
PduR_<User:LoTp>CopyRxData like specified in Requirement PDUR512 in [1]. The API
is implemented according to SWS_PduR_00512 ASR 4.1.1 [2]

 If the PduR_<Lo>StartOfReception is called with an I-PDU ID that is already in process,
the PDU Router does not forward the call to the upper module

 In case a transport protocol module reports PduR_<LoTp>TxConfirmation with result
other than NTFRSLT_OK the PDUR does not forward the result in the
<Up>_TpTxConfirmation to the source upper layer module due to optimization reason.

 The PduR does not support the retry parameter in the PduR_<LoTp>CopyTxData like
specified in Requirement PDUR518 in [1]

 State Management: PDUR_REDUCED is not used

 PduR does not return any value if a routing path group is disabled

 PduR does not clear the buffers if a routing path group is disabled

 The header files does not contain software and specification version number

 If the routing path group id does not exist, then the PDUR call the DET instate of return
with no action. [PDUR0716]

© 2017 Vector Informatik GmbH
Version 3.00.00
65
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
7.2
Limitations
Since 8-bit micro controllers are out of scope in AUTOSAR, PDUR has been optimized for
the  usage  on  16-  and  32-bit  controllers.  Therefore  the  target  system  must  be  able  to
provide atomic read and write accesses to 16-bit variables.

7.2.1
General
  Link-time configuration support
  Multiple Configuration support
  1:N fan-out from the same upper layer PDU
  N:1 fan-in to the same upper layer PDU

© 2017 Vector Informatik GmbH
Version 3.00.00
66
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
8 Glossary and Abbreviations
8.1
Glossary
Term
Description
BSWMD
The BSWMD is a formal notation of all information belonging to a certain
BSW artifact (BSW module or BSW cluster) in addition to the
implementation of that artifact.
Buffer
A buffer in a memory area located in the RAM. It is an memory area
reserved by the application for data storage.
Callback function
This is a function provided by an application. E.g. the CAN Driver calls a
callback function to allow the application to control some action, to make
decisions at runtime and to influence the work of the driver.
Cfg5
DaVinci Configurator
Channel
A channel defines the assignment (1:1) between a physical
communication interface and a physical layer on which different modules
are connected to (either CAN or LIN). 1 channel consists of 1..X
network(s).
Component
CAN Driver, Network Management ... are software COMPONENTS in
contrast to the expression module, which describes an ECU.
Confirmation
A service primitive defined in the ISO/OSI Reference Model (ISO 7498).
With the service primitive 'confirmation' a service provider informs a
service user about the result of a preceding service request of the service
user. Notification by the CAN Driver on asynchronous successful
transmission of a CAN message.
Critical section
A critical section is a sequence of instructions where mutual exclusion
must be ensured. Such a section is called 'critical' because shared data is
modified within it.
Electronic Control
Also known as ECU. Small embedded computer system consisting of at
Unit
least one CPU and corresponding periphery which is placed in one
housing.
Event
An exclusive signal which is assigned to a certain extended task. An
event can be used to send binary information to an extended task. The
meaning of events is defined by the application. Any task can set an
event for an extended task. The event can only be cleared by the task
which is assigned to the event.
Gateway
A gateway is designed to enable communication between different bus
systems, e.g. from CAN to LIN.
Indication
A service primitive defined in the ISO/OSI Reference Model (ISO 7498).
With the service primitive 'indication' a service provider informs a service
user about the occurrence of either an internal event or a service request
issued by another service user. Notification of application in case of
events in the Vector software components, e.g. an asynchronous
reception of a CAN message.
Interrupt
Processor-specific event which can interrupt the execution of a current
program section.
Interrupt service
The function used for direct processing of an interrupt.
© 2017 Vector Informatik GmbH
Version 3.00.00
67
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
routine
Network
A network defines the assignment (1:N) between a logical communication
grouping and a physical layer on which different modules are connected
to (either CAN or LIN). One network consists of one channel, Y networks
consists of 1..Z channel(s). We say network if we talk about more than
one bus.
Overrun
Overwriting data in a memory with limited capacity, e.g. queued message
object.
Post-build
This type of configuration is possible after building the software module or
the ECU software. The software may either receive parameters of its
configuration during the download of the complete ECU software resulting
from the linkage of the code, or it may receive its configuration file that
can be downloaded to the ECU separately, avoiding a re-compilation and
re-build of the ECU software modules. In order to make the post-build
time re-configuration possible, the re-configurable parameters shall be
stored at a known memory location of ECU storage area.
Schedule table
Table containing the sequence of LIN message identifiers to be
transmitted together with the message delay.
Signal
A signal is responsible for the logical transmission and reception of
information depending on the restrictions of the physical layer. The
definition of the signal contents is part of the database given by the
vehicle manufacturer. Signals describe the significance of the individual
data segments within a message.  Typically bits, bytes or words are used
for data segments but individual bit combinations are also possible. In the
CAN data base, each data segment is assigned a symbolic name, a
value range, a conversion formula and a physical unit, as well as a list of
receiving nodes.
Transport Protocol
Some information that must be transferred over the CAN/LIN bus does
not fit into individual message frames because the data length exceeds
the maximum of 8 bytes. In this case, the sender must divide up the data
into a number of messages. Additional information is necessary for the
receiver to put the data together again.
Use case
A model of the usage by the user of a system in order to realize a single
functional feature of the system.
Table 8-1   Glossary
8.2
Abbreviations
Abbreviation
Description
API
Application Programming Interface
AUTOSAR
Automotive Open System Architecture
BSW
Basis Software
BSWMD
Basic Software Module Description
CAN
Controller Area Network protocol originally defined for use as a
communication network for control applications in vehicles.
CDD
Complex Device Driver
COM
Communication
© 2017 Vector Informatik GmbH
Version 3.00.00
68
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
DCM
Diagnostic Communication Manager
DEM
Diagnostic Event Manager
DET
Development Error Tracer
DLC
Data Length Code, Number of data bytes of a CAN message
EAD
Embedded Architecture Designer
ECU
Electronic Control Unit
ECUC
ECU Configuration
FIFO
First In First Out
HIS
Hersteller Initiative Software
ID
Identifier (e.g. Identifier of a CAN message)
ISR
Interrupt Service Routine
LIN
Local Interconnect Network
MICROSAR
Microcontroller Open System Architecture (the Vector AUTOSAR
solution)
MSN
Module shortname
PDU
Protocol Data Unit
PDUR
PDU Router
RAM
Random Access Memory
ROM
Read-Only Memory
RTE
Runtime Environment
SDU
Segmented Data Unit
SRS
Software Requirement Specification
SWC
Software Component
SWS
Software Specification
TP
Transport Protocol
Table 8-2 Abbreviations

© 2017 Vector Informatik GmbH
Version 3.00.00
69
based on template version 4.9.2

Technical Reference MICROSAR PDU Router
9  Contact
Visit our website for more information on

  News
  Products
  Demo software
  Support
  Training data
  Addresses

www.vector.com

© 2017 Vector Informatik GmbH
Version 3.00.00
70
based on template version 4.9.2

Document Outline

Last modified July 6, 2025: Initial commit (97b4320)