Contents

Introduction

Scope

This application note describes the functional background of the IpduM module, which will be used to add support for multiplexed CAN messages to an existing RTA-CAR project. In the context of this application note, the existing project will be the 9.2.1 Standard Starter Kit.

Definitions & Abbreviations

AR: AUTOSAR

BSW: AUTOSAR Basic Software / Hardware independent service layer

RTE: AUTOSAR Real Time Environment

OS: AUTOSAR Operating System

CAN: Control Area Network

SK: Starter Kit

PDU: Protocol Data Unit

I-PduM: Interface (layer) PDU Multiplexer

PCI: Protocol Control Information

SDU: Service Data Unit

PduR: PDU Router

Tool-chain

It is assumed to complete this AN, the RTA-CAR v9.2.1 tool-chain is in use:

Prerequisites

In order to complete this guide, it is assumed the user has a good knowledge of AR methodology and terminology. As well as having the specified tool-chain installed, and have access to the VRTE Standard 9.2.1 SK which is to be used.

Functional Overview

General Overview

PDU multiplexing means using the same PCI (Protocol Control Information) of a PDU with more than one unique layout of its SDU. A selector field is a piece of the SDU of a multiplexed PDU which is used to distinguish the contents multiplexed PDUs from one another. When multiplexing PDUs, it common to use the CAN infrastructure (as used in this AN), but is not restricted to this communication system.

To understand the use of the IpduM module, it is vital to know it's place and connections within the AR architecture:

On the sender-side, the IpduM module is responsible for combining appropriate I-PDUs from COM to new multiplexed I-PDUs and then send them back to the PduR. While on the receiver-side, the module is responsible for interpreting the content of a multiplexed I-PDU and provide COM with the appropriate separated I-PDUs taking into account the value of the selector field.

Within this module there are two different approaches of multiplexing several I-PDUs into one resulting PDU to be transferred on a communication bus:

• I-PDU Multiplexing means using the same I-PDU ID transferred from the PDU Router to the Communication Hardware Abstraction Layer with more than one unique layout of the corresponding I-PDU
• Multiple PDU to Container Mapping means collecting several I-PDUs into one Container PDU, which is transferred via the PDU Router as one (large) I-PDU. This has the advantage of the larger frame sizes of newer bus systems, allowing an efficient usage of bandwidth in combination with smaller I-PDU sizes (usually 8 bytes).

In this application note we will be focusing on the I-PDU Multiplexing approach. More information can be found within the official AR Specification for both approaches within IpduM.

I-PDU Multiplexing

A multiplexed I-PDU consists of a static and a dynamic part, where the static part consists of zero or more signals or signal groups. The dynamic part consists of the selector field and one or more signals or signal groups. Dependent on the value of the selector field inside the I-PDU, will produce the actual layout of the I-PDU in question. The positions of theses components are configurable per I-PDU, and each can be subdivided into different segments. However, only one selector field can be defined for each multiplexed I-PDU, as this defines how the content of the dynamic part is interpreted. The selector field has a configurable size between 1 and 16 contiguous bits. Below are some examples:

There is one COM I-PDU for the static part and one for each layout of the dynamic part of one multiplexed IpduM I-PDU, so the IpduM combines at most two I-PDUs of COM. The IpduM relies on the configuration of the COM module, as for each dynamic layout an I-PDU needs to be configured. Such I-PDUs already have to contain the correct selector field value; these can be initialised within COM, by configuring them as signals that are initialised with an init value but are never written after initialisation. Further information about transmission and reception within the AR compliant element can be found within the official AR Specification.

Workflow

Workflow Summary

1. Create the IpduM module
2. Configure the basic settings of the IpduM module
3. Interface Port Configuration
4. SWC Configuration
5. Modify & Import DBC file
6. System Data Mapping
7. Create ECUextract
8. Execute ConfGen
9. OsTask Configuration
10. COM Configuration
11. BswM Configuration
12. IpduM Configuration
13. CAN Configuration
14. RTA-BSW Generation
15. RTA-RTE Generation
16. RTA-OS Configuration & Generation
17. MasterSWC ASW Implementation
18. MCAL Re-Generation
19. Build Testing

IpduM Module

IpduM Module Creation

To implement the IpduM module into the SK project, navigate to the ECU Configurator and create the IpduM service within BSW Modules as shown (right-click):

IpduM Basic Configuration

Once created, open the IpduM module from the ECU Configurator within the BSW Editor. Then navigate the IpduMGeneral and set it as follows:

• IpduMDevErrorDetect should be set to false, as this will disable the "development error detection and notification" due to not requiring all IpduM APIs to check their input parameters within this project.
  
  
• The IpduMRxTimeBase value is the period between successive calls to the IpduM_MainFunctionRx function measured in seconds. The same is said for the IpduMTxTimeBase value, though towards the IpduM_MainFunctionTx function which handles the processing of transmission activities that are not directly handled within the calls from PduR while IpduM_MainFunctionRx handles the reception activities. Each value can range from 0 to infinity, though for the purpose of this project both should be set to 0.01.
  
  
• Within this project, static parts of a PDU is to be used and therefore IpduMStaticPartExists is required to be set to true. This parameter would otherwise allow for optimisations in the case that the IpduM will never be used with a static part. Finally, set the IpduMVersionInfoApi to false.

Following the IpduMGeneral configuration, set the IpduMRxDirectComInvocation to false which can be located within the IpduMPublishedInformation area of the IpduM module:

ASW Configuration

Interface Port Configuration

Now that the basic configurations of the IpduM module have been set, it its time to modify the SWCs and Interfaces of the SK to support Multiplexed CAN messages being passed through the module. Begin by creating 3 Sender Receiver Interfaces named Interface_Voltage and Interface_Data; all within the System package under the system_config/Interfaces.arxml.

Once all three interfaces have been created, open them within the Data Dictionary Editor:

Then assign 7 VariableData Prototype's to each interface and configure them as follows:

Ensure each interface is of similar structure, where the only difference is in the naming scheme of each VariableData Prototype (i.e. Voltage_SF100, Data_SF100 etc...)

SWC Configuration

After successfully creating and configuring the desired interfaces, navigate to the MasterSWC under Software/Components and open within the Component Editor:

Create 1 PPort and 1 RPort for MasterSWC with the corresponding interfaces just created with the following naming scheme: PPort_x and RPort_x (e.g. PPort_Voltage).

Once these ports have been created navigate to the Functions tab along the top of the window, created 2 new runnables named as follows:

Then navigate to the Events tab, and create two timing events named TE_Tx and TE_Rx with the time period of 0.5 as follows:

Now navigate back to the Functions tab, select the RE_Tx function and then along the right-side of the window navigate to the Data Access Points tab. Within this tab add new Access Points and select the following:

Then select the RE_Rx function, and again add new Access Points, this time selecting the following:

Repeat the same steps with port creation and configuration within the TesterSWC where there is 1 PPort and 1 RPorts (e.g. PPort_Data).

Composition Configuration

Once all ports have been configured, navigate to the projects compositions within Software. Open the TopLevelComposition within the Composition Editor:

Navigate to the Manual Connection Editor tab (located bottom-left of the window). Within this window, select the Source Component to be CPT_MasterSWC and the Target Component to be CPT_TesterSWC. This will bring up all the ports of each of these components. In this case, the following ports need connecting manually:

System Configuration

Modification of DBC file

Once all ASW elements have been configured, the pre-imported DBC file needs to be modified to accommodate these changes. The information below addresses the CAN frames and their signals. This information can be simply appended to the current DBC import file found under System_config within the project, above predefined CAN frames.

BO_ 4 Data_Msg: 8 TestECU
 SG_ DataStatic : 24|32@1+ (1,0) [0|0] ""  ApplicationECU
 SG_ DataD m200 : 16|8@1- (1,0) [0|0] ""  ApplicationECU
 SG_ DataC m200 : 8|8@1- (1,0) [0|0] ""  ApplicationECU
 SG_ DataB m100 : 16|8@1- (1,0) [0|0] ""  ApplicationECU
 SG_ DataA m100 : 8|8@1- (1,0) [0|0] ""  ApplicationECU
 SG_ DataSF M : 0|8@1+ (1,0) [0|0] ""  ApplicationECU

BO_ 5 Voltage_Msg: 8 ApplicationECU
 SG_ VoltageStatic : 24|32@1+ (1,0) [0|0] ""  TestECU
 SG_ VoltageSF M : 0|8@1+ (1,0) [0|0] ""  TestECU
 SG_ VoltageD m200 : 16|8@1+ (1,0) [0|0] ""  TestECU
 SG_ VoltageC m200 : 8|8@1+ (1,0) [0|0] ""  TestECU
 SG_ VoltageB m100 : 16|8@1+ (1,0) [0|0] ""  TestECU
 SG_ VoltageA m100 : 8|8@1+ (1,0) [0|0] ""  TestECU

Once the modifications are complete, ensure that all tabs within the ISOLAR-AB workspace are closed before selecting the project and DBC Importer tool:

Select only the ApplicationECU and its CAN frames before clicking Finish. As this will generate all the necessary signals within the System information for when it comes to generating the ECU framework. Upon completing this step, ISOLAR-AB will prompt the user to compare the changes, due to re-importing information alongside new information. Simply close this tab and decline the generation of a report.

System Data Mapping

Before creating an ECU extract, the signals from the DBC import should now be present. And these signals need assigning to the MasterSWC; to do this open the System component (located in System_Info) using the System Data Mapping Editor:

Within this window, map the signals to the VariableData Prototypes as made within the Interfaces (Voltage & Data) within the MasterSWC:

Ensure that only the MasterSWC Data Elements are mapped with signals, not TesterSWC.

ECU Configuration

ECU Extract

Once System Data Mapping has been completed, the project requires an ECU extract to form the structure of the ECU Configurator. Done by right-clicking the 'System' container within System Info and select Create ECU Extract:

Uncheck Ignore compspec conflicts and also Update existing ECUExtract. Then click Finish:

ConfGen Execution

Once the ECU Extract has been generated, execute the Configuration Generator for the ECU, selecting the latest RTA-BSW version available:

OsTask Configuration

Open the EcucValueCollection found within the BSW Modules of the ECU Configurator. Open this in RTE Mapping Editor:

Navigate the UnMapped Entities and select RE_Tx and RE_Rx. Drag and drop these under OsTask_ASW as shown:

Once the mapping of the MasterSWC runnables has been completed, map the IpduM functions to OsTask_BSW:

COM Configuration

Open the COM module within BSW Editor:

In the COM module, within ComConfig and ComSignals, set the ComTransferProperty of the sent signals, except the sent selector field signals, to PENDING and set the sent selector field signals to TRIGGERED. On the contrary set ComTransferProperty of all received signals to TRIGGERED. Check that all ComSignalType's match that which were set in Interface Configuration:

If not populated set the ComNotification attribute of each received signals “x” to “Rte_COMCBK_x”

BswM Configuration

Open the BswM module within the BSW Editor:

Navigate the file structure to BswMModeControl where the BswMActionLists and BswMActions are located. Within the BswMActions right-click and create a new BswMAction:

Name this newly created BswMAction: BswM_AI_IpduM_Init and add the available action BswMUserCallout to it with the value IpduM_init():

Upon configuring this new BswMAction, it is required to append it to the BswMActionList "BswM_AL_BswModules_InitListReadAll" as shown naming it BswM_ALI_IpduMInit:

Once created, configure the action list with the following parameters:

IpduM Configuration

Open the IpduM module within the BSW Editor:

Within the IpduM module under IpduMRxPathways select the IpduMRxIndication of the RxPw_Data_Msg_Multiplexed_IPDU_Can_Network_Channel_CAN. Ensure that within this element the IpduMByteOrder is set to LITTLE_ENDIAN. Following this, ensure that within the IpduMRxDynamicPart's Data_Msg_MUX100 and Data_Msg_MUX200 have their IpduMRxSelectoreValue set to 100 and 200 respectively.

Within IpduMTxRequest's under the IpduMTxPathways, configure the same parameters as in the figure below. Note that IpduMTxTriggerMode is set to DYNAMIC_PART_TRIGGER so writing the I-PDU representing the dynamic part does trigger the sending of the I-PDU.

CAN Configuration

Open the CAN module within BSW Editor:

Set the CanHwFilterMask of CAN Hardware Objects Can_Network_CANNODE_0_Rx_Std_MailBox_7 and Can_Network_CANNODE_0_Tx_Std_MailBox_6 to 2047, and CanHwFilterCode to 4 and 5 respectively.

RTA-BSW Generation

Now that all components and modules have been configured to accommodate the addition of the IpduM module, it is time to generate the BSW. Open the RTA Generator Dialog Window:

A window similar to the following should appear, within this window select the modules to match the screenshot and click Apply and then Run:

RTA-RTE Generation

Once the BSW has successfully been generated, the RTE is required to generate. Open the RTA Generator Dialog window and enter the following command prompt into the Rte Command section:

--strict-unconnected-rport-check=off --os-define-osenv=RTAOS40 --notimestamps --samples=memmap --os-output-param=changed

The window should look as follows, and then press Apply and the Run:

RTA-OS Generation

For the OS Generation to complete successfully, open the OS within ECU Configurator using the BSW Editor:

Navigate to the OsTasks section, and ensure the values within the OsTaskActivation fields match those presented here:

Once these are correct, open the RTA Generator dialog window and click Apply and then Run:

MasterSWC ASW Implementation

In the figures below two examples of RE_Tx_func() and RE_Rx_func() respectively in ASW to test the system:

FUNC (void, MasterSWC_CODE) RE_Tx_func(void)
{
    static boolean bool_SF = FALSE;
    uint8 Voltage_A = 3;
    uint8 Voltage_B = 4;
    uint8 Voltage_C = 5;
    uint8 Voltage_D = 6;
    uint32 Voltage_Static = 0;

    if (bool_SF == FALSE)
    {
        Voltage_Static = 33;
        bool_SF = TRUE;
        Rte_Write_PPort_Voltage_Voltage_SF100(100);
        Rte_Write_PPort_Voltage_Voltage_A(Voltage_A);
        Rte_Write_PPort_Voltage_Voltage_B(Voltage_B);
    }
    else
    {
        Voltage_Static = 44;
        bool_SF = FALSE;
        Rte_Write_PPort_Voltage_Voltage_SF200(200);
        Rte_Write_PPort_Voltage_Voltage_C(Voltage_C);
        Rte_Write_PPort_Voltage_Voltage_D(Voltage_D);
    }
    Rte_Write_PPort_Voltage_Voltage_Static(Voltage_Static);
} 

FUNC(void, MasterSWC_CODE) RE_Rx_func(void)
{
    uint8 Data_A = 0;
    uint8 Data_B = 0;
    uint8 Data_C = 0;
    uint8 Data_D = 0;
    uint8 Data_Static = 0;
    uint8 Data_SF = 0;
    Std_ReturnType retRteRead = RTE_E_OK;

    retRteRead = Rte_Read_RPort_Data_Data_SF100(&Data_SF);
    retRteRead = Rte_Read_RPort_Data_Data_A(&Data_A);
    retRteRead = Rte_Read_RPort_Data_Data_B(&Data_B);
    retRteRead = Rte_Read_RPort_Data_Data_C(&Data_C);
    retRteRead = Rte_Read_RPort_Data_Data_D(&Data_D);
    retRteRead = Rte_Read_RPort_Data_Data_Static(&Data_Static);

}

MCAL Re-generation

Now that the project is completed, the final step before testing this build with BusMaster is to re-generate the MCAL. To do this, run the 01_mcal.bat which can be found under the Build folder in the SK. This may differ from another project structure the user is using.

Build Generation

After re-generating the MCAL, it is imperative that the project build is re-generated. This is done using the 02_build.bat from the same folder as the MCAL bat. However, before executing the build script it is imperative to include the IpduM module into the CMakeLists.txt configuration file as shown below:

Finally, execute the build script by double-clicking it and a terminal should appear.

BusMaster Testing

Once having built the project, an executable is created into the sub-directory Build → output named RTA-SK-VRTA.exe. Double click on this file to execute it; the VRTA will open and begin the virtualisation of the project within the application. Ensure, that the runLoopback.bat is running also, as this will allow us to communicate with the virtualised ECU.

Now that both programs are running open BusMaster. Setting the Driver Selection to ETAS BOA:

A Hardware Selection prompt window should appear, here select any CAN hardware (except ETAS://ETH/ES523:VLoopBack/CAN:1) and move to Configured CAN Hardware and click Ok:

Then click connect, and the following should appear in the Message Window:

This shows the VRTA is working and sending the alternating multiplexed PDU messages. One time with the selector field equaling 100 and the next equaling 200 in sequence. To test the multiplexed messages in reception, use BUSMASTER and send the same message with different selector fields (different byte0) every time and different values of the contained signals. Then using visual studio code (or the users preferred IDE) put a break point into RE_Rx_func() and monitor the values of signals: Data_A, Data_B, Data_C and Data_D every time the message is sent from BUSMASTER.