Table of content

Introduction

Scope

This application note describes the workflow to set up your Multicore AUTOSAR project. 

The complete configuration of an AUTOSAR project is out of the scope of this Application Note. The presented workflow will start from an already complete AUTOSAR project and the presented steps will guide the user in making the correct configurations to have the same project working in a Multicore environment. The example presented in this document it is based on the RTA-SK TC275 v7.0.

Definitions and Abbreviations

BSW: AUTOSAR Basic Software, Hardware independent service layer

RTE: AUTOSAR Real Time Environment

OS: AUTOSAR Operating System

SWC: Software Component

Toolchain

It is assumed you are using RTA-CAR 6.0.1 or newer.

Prerequisites

This application note assumes that the reader is familiar with the AUTOSAR terminology and concepts, and he has got a good knowledge of the RTA-CAR Toolchain.

General overview

In this section we will explain the general concepts for reaching the multicore configuration.

The two main elements needed for achieving a multicore configuration are ECU Partitions and OS Applciations. The following diagram explains the relationship among Partitions, Cores, and OS Applications and it is more or less representative of the sample configuration provided with the RTA-SK multicore.

ECU Partitions

It is needed to create multiple ECU Partitions, at least one for each core of your system. In the simplest case (which is the one explained in this document) you will have 2 cores and 2 EcuPartitions. Each Partition will be assigned to a Core, and we will see that during the configuration steps.

OS Application

The OS Applications is used to define the privilege level and the protection boundary of the tasks and ISRs it owns. Since we are in a multicore context, we will need to have an OS Application for each Partition so that we can keep separation between the Tasks and elements assigned to each core.

Step 1 - Update of the ASW

The main scope of having a multicore system is to improve the performance with respect to the single core configuration.

This can be achieved splitting the ASW among the different cores, so that the computation load is equally distribuited. The first step is then to create (if not already available in the configuration) the ASW Components that you intend to map in the two cores.

The creation of the ASW components and their elements is out of the scope of this AN, please consult the relative RTA Guide for further information.

In our example, we used the RTA-SK as a starting point for the multicore configuration. To the standard set of SWCs available in the RTA-SK, we added a new one that will be mapped in the new OS partition.

The new SWC has some interfaces to communicate with the MasterSWC and with the NvM Service Component. In fact, we added a PIM configuration and NvM Service Needs to the SWC so that we can include in the example the IOC and the usage of BSW services from a second core.

Before to start with the Multicore configuration, we shall update the SW Composition and the ECU Extract in the usual way.

First, open the composition editor and add the SWC instance to the composition:

And make the expected connection with the other SWCs when needed.

Then open the SWC to ECU Mapping, and drag and drop the component instance to the ECU instance:

Finally, update your ECU Extract.

Step 2 - Update of the BSW Configuration and EcuM

You will need to update your BSW configuration for two reasons:

1. The BSW needs to be aware it is working in a multicore system. For this reason, the EcuM shall be mapped to both cores to handle startup, shutdown, init phases etc.
2. If you introduced any additional SWC needs (for example we added NvM needs) you need to regenerate your BSW configuration and code in order to get the NvM up to date.

To get the EcuM up to date, first of all, open the Os Module in ISOLAR-B and change the OsNumberOfCores parameter to 2.

This parameter will be checked by the BSW code generator and it will generate a second instance of the EcuM Mainfunction that will be mapped in the second Core.

For further information on why this is needed, please consult the AUTOSAR documentation.

Now you can run again the Configuration Generation (Confgen) and the Code Generator for RTA-BSW.

Now you need to update your EcuExtract because also your EcuM SWCD has been updated after the code generation.

We will have a look to the changes later in the document, where we will proceed mapping the EcuM Mainfunctions correctly.

Step 3 - Create the ECU Partitions, OS Applications and Core Definitions

Now we are ready to update the System configuration with the needed elements.

You can open your ECU Extract with the ECU Partititon Editor

Switching to the Multicore view, you can start creating two EcuC Partitions, one for each Core.

And create two new partitions, one for each core:

Now it is possible to create the needed OsApplications. To do so, we switch to the OS configuration doubleclicking on the Os module in ISOLAR-B

Now you can create the OsApplications that you need. In our case, we can create 3 OsApplications. Two main OsApplication (one for each core) where I will map the OsTasks, and an OsApplication called RTE_Application that will contain the InitTask.

Please ensure you are not modifying the OsNeeds.arxml file, which is automatically generated. You must use the same file you used for the OS configuration (in our case Os.arxml). To choose the file where you will apply the modification, press the split configuration button and check if you are working in the expected file:

Then create your OsApplications:

Once we have the three OsApplication, we can complete the configuration assigning to them a reference to an EcuC Partition. OsApplication_1 will be assigned to EcucPartition_1 (for Core1) and the reference to EcucPartition_0 will be assigned to the OsApplication_0.

Repeat the previous step for the OsApplication_1 and OsApplication_0. The RTE_Application shall not have a reference to a partition instead.

Moving back to the ECU Partition Editor, the view should be now updated as follow, with the reference to the created OsApplication (you will need to close and reopen the ECU Partition Editor to refresh the view :

Now, right clicking on every EcucPartition line, you can Create a Core Definition. This is needed to assign each Partition to a specific core.

Now that we created the two Core Definitions, we can configure all the other options for the partitions and selecting one partition as the one to host the Bsw Modules.

The configuration should look like the following:

As shown in the next screenshot, now you can drag and drop SWC instances between the two partitions.

Step 4 - Configuration of additional OS Tasks

The next step is to add the new OS Tasks. Please open the Os module with the BSW editor and add the new task there.

You need at least a new OS Task to assign to the OSApplication mapped in the second Core.

We are creating two tasks in this example, one for the Core1, and the other one is for handling NvM events in Core0. This choice might change according to your project.

Select the OS application for every task:

As you can see in the previous screenshot, all the tasks related to Core0 will be assigned to OsApplication_0 and all the tasks related to Core1 will be assigned to OsApplication_1. The InitTask will be assigned to the RTE_Application.

Step 5 - Mapping SWCs to Tasks

 You can proceed mapping the runnable of the SWC to the task running in the application in Core1.

If you executed all the previous steps correctly, you should get to this view, where you have two EcuM mainfunction (one fore each Core) and the runnable of the SWC running ini the second Core:

Map the runnable to the Task assigned to the Core1

And, as mentioned before, please also map the EcuM mainfunction to both cores in the following way:

As you can see from the above screenshots, you can distinguish between the two EcuM mainfunction looking to the name of the "Swc Event Properties", which contains the name of the Core.

There are also some hidden events that must be mapped. Press the icon to show the hidden events, and filter them by the event name in order to get the set of events that concerns the NativeBlock_3 (which is the one used by NvM in this example)

If you are not using NvM services in your second core, you can ignore this part and all the other advices that regards NvM. If you are working in your own project, please bear in mind that the name of the events, blocks, interfaces is project dependent, so you might have different names/events to map in your project.

You can select all the above events and map them to the relative task:

Step 6 - RTE Generation

We are now ready for the RTE Generation.

Open the RTE Code Generator options and update the Rte Command line with the following string:

--strict-unconnected-rport-check=off --os-define-osenv=RTAOS40 --notimestamps --samples=memmap --use-partition-sections=1 --deviate-split-swci-support=on --deviate-bsw-any-partition=1 --client-server-global-optimization=on

Switch to the Included AR Files tab and ensure you selected all the new added files (for example, the Partitions.arxml file and the arxml files of the new SWC)

Finally you can generate the RTE:

If you open up the iocNeeds.arxml file, you should now find new elements that describe the IOC interfaces needed. Check out if you got a similar result.

RTE Artifacts and needed changes

A new file, the iocNeeds.arxml has been created with the IOC information needed for the OS. Also the osNeeds has been updated with the needed resources.

Some manual changes are needed to fix the RTE generated files.

Patch the osNeeds.arxml

The generated OsNeeds contains a not needed element - the RTE_RESOURCE. You will need to remove this not need element. You can use a script (like the one provided with the RTA-SK)

Please ensure that you remove also all the references to the RTE_RESOURCE (for example in the OsTask there are other references to the RTE_RESOURCES).

Step 6 - OS configuration and OS partitions

Before to proceed with the OS configuration, there is a minor fix you need to manually apply.

You need now to update the Os configuration. In the screenshot below, you can check the configuration used for the RTA-SK, but this may vary according to the project and requirements.

Add three OS Resources (ensure you are not modifying the osneeds.arxml)

The RTE generated the osNeeds in the previous step. The OS needs contains the Rte_TimeoutAlarm1 and the Rte_TOutCounter needed for handling the IOC communication.

You need to map those element in the OS configuration, in the following way:

Check out the RTA-SK multicore example for the complete OS configuration.

Before generate the OS, change the OS generator configuration.

Select the missing files:

And use the following command line

--build:clean --include:src/integration --include:src/rte --include:src/bsw/integration

Known Issue: Generating RTE, OS and BSW

There are some known incompatibilites between RTA-RTE and RTA-OS that will be fixed in next RTA-CAR release.

As of now, in order to switch between RTE, OS and BSW generation there are some changes needed.

RTE Generation

To generate the RTE, you must:

1. remove the references below from the OS Application configuration in Os.arxml

2. Change the Package name in the Partition.arxml file

3. Fix all the invalid references to EcuPartitions and EcucCoreDefinition (in all the OsApplications you have created)

Os generation

In order to generate the OS, you need to undo the steps explained in the previous section for the RTE generation

BSW Generation

If you already generated the RTE, the OsNeeds.arxml generated by the RTE might cause some issues and could be misinterpreted in the pre-build stage of the RTA-BSW generation.

To avoid this, remove temporarly the OsNeeds.arml and ripristinate it after the BSW generation.