1. Table of Contents

2. Introduction

2.1 - Scope

This Application Note describes how to add a PIM to an existing RTA-CAR project, and consequently how to configure the Memory Stack.

2.2 - Definitions and Abbreviations

• BSW: AUTOSAR Basic Software, Hardware independent service layer
• RTE: AUTOSAR Real Time Environment
• OS: AUTOSAR Operating System
• SWC: Software Component
• NvM: Non Volatile Memory
• MCAL: Micro-Controller Abstraction Layer
• FLS: Flash Driver
• PIM: Per-Instance memory
• ECU: Electronic Control Unit
• AR: AUTOSAR
• AN: Application Note
• ECU: Electronic Control Unit
• ASW: Application SoftWare

2.3 - Toolchain

It is assumed you are using the RTA-CAR 9.2.0 toolchain:

3. Prerequisites

In order to successfully follow this guide, you must have the RTA-CAR toolchain installed and you must be familiar with the AUTOSAR specifications, terminology and methodology.

It is recommended that Memory Stack configuration is added to an existing project, with Application Software, Basic Software and System Configuration.

This workflow continues on from workflow 03 - ECU Configuration.

4. Workflow

Workflow Summary

Here is a summary of the steps that you will be working through in this example.

Step 1. We will add a Per Instance Memory to the Receiving Software Component.

Step 2. We will create an NvM Service Need for each PIM created. With this we can define attributes of the PIM like if it is read on start-up or if it can only be written to once.

Step 3. If we are using the VRTA, we will import 2 files that are required for the MCAL generation.

Step 4. As we have made changes to the System, we will need to re-generate the ECU configuration. This will create the modules required for the Memory Stack.

Step 5. We will re-generate the BSW. This will create the BSW code for the modules we have configured, as well as the Service Component for the NvM.

Step 6. We will add the newly created NvM Service Component to the composition.

Step 7. We will map the necessary ports on the NvM Service Component, to the relevant ports on the Receiving Software Component.

Step 8. We will update the ECU extract, so it contains the new Modules we’ve created.

Step 9. We will map the newly created SWCs runnables to the BSW OsTask.

Step 10. We will re-generate the RTE code.

Step 11. We will update the Micro Controller Abstraction Layer.

Step 12. We will add code that interacts with one of our newly creates PIMs.

Step 1. ASW Configuration and PIM creation

The first thing we'll need to do is create a PIM (Per Instance Memory) in our receiving Software component. With this we can store data in our ECU.
You are able to choose what type is stored in the PIM, for our example we will be creating 2 PIMs. One will be boolean and one will be an 8 bit unsigned integer.

Double click MyReceivingSWC in either the AR Explorer or ECU Navigator to open the Software Component configuration.

Switch to the tab "Others".

Next, switch to the sub-tab PerInstanceMemory and press the Create PerInstanceMemory button twice.

A new element will be added to the table. Set the ShortName for the first to 'PIM_01' and the second to 'PIM_02'. PIM_01 will be of type boolean, and PIM_02 will be of type uint8 (8 bit unsigned integer).
Then set the initial value of PIM_01 to 0, and PIM_02 to 1.

The final result of the two PIMs created is shown below:

For each PIM, a new software data definition proposal must be created. To do that right click on the PIM and select the following to configure the Data Definition Properties, New Child --> Sw Data Def Props | Sw Data Def Props Conditional.

Create one for each PIM, setting the base type to boolean for PIM_01, and uint8 for PIM_02.

Step 2. Create NvM Service Needs

Now that we have 2 PIMs configured, we will need to configure a NvM Service Need for each one. This will define how our PIM can be interacted with.

Open the SWC containing the PIMs with the service needs Editor; to do that right click on the SWC in the AR Explorer and select Open with --> Service Needs Editor. 

Switch to Tab NvM Service Needs and select Add NvM Service Needs twice; the table below will be filled with 2 new elements. Select Srv_NvM_0 and on the left, in NvM Service Needs Attributes, check StoreAtShutdown and RestoreAtStart. Do the same for Srv_NvM_1.

You should also set the attributes NDataSets, NRomBlocks, and WritingFrequency to 0.

Finally connect the PIM to the Service needs created by adding a data Assignment. Press on Add Data Assignment and in the pop-up window, switch to the tab, Used PIM. For Srv_NvM_0 select PIM_01 and for Srv_NvM_1 select PIM_02.

The final result of this step is shown below.:

Step 3. Integration with the MCAL

If you are using the virtual target MCAL provided by ISOLAR-EVE, you will need to import the following files for the MCAL generation (RTA-SK_VRTA_9.2.0\RTA-SK\ecu_config\bsw\integrationCfg):

• Fls_BSWMD.arxml 

• Fls_BSWMD_EcucValues.arxml

These files are provided along with the VRTA (Virtual) RTA Starter Kit. For other hardware, the MCAL configuration will vary - a range of RTA Starter Kits are available. For more information on the available Starter Kits, contact ETAS.

Step 4. Configuration Generation

We now have an updated the System, specifically we have implemented 2 Per Instance Memories into MyReceivingSWC, and defined their service needs. So we will need to re-generate the ECU configuration so it reflects these changes.  When running ISOLAR-ABs ECU configuration generator, ISOLAR-AB will now create or update the ECU extract before generating the configuration, so there is no need to do this manually.

Ensure that the path is pointing to the existing Project_EcucValues.arxml, or if the Generate separate file for each Module option is selected, then make sure its pointing towards the existing ConfGen folder, so that values are not duplicated and click Finish. This step will update the "Config" directory inside the Project folder with the automatically generated arxml files related to the BSW modules. 

As a result expanding the Bsw Modules within the "ECU Navigator" menu you can see how a Memory stack has been created with the modules: NvM, MemIf and Fee.

A brief explanation of these modules is as follows -

• NvM - NVRAM Manager - This module organizes the ECU's persistent data storage facility in separately manageable units called "NvM blocks".
• MemIf - Memory Abstraction Interface - This module provides a common interface for the NvM blocks to access the underlying memory hardware.
• Fee - Flash EEPROM Emulation - This module emulates the functionality of a serial EEPROM inside a flash memory by organizing and saving different types of data to non-volatile memory media.

Note: Updating the Mode Management

In order to have PIMs correctly saved and restored during startup/shutdown, you need to update the Mode Management configuration. To do so, you need to update the BswM and the EcuM in order to:

• Initialize the Memory Stack (NvM, MemIf, Fee, Fls)
• Configure the actions to complete the NvM ReadAll during startup and the NvM WriteAll during Shutdown.

The Mode Management configuration is outside of the scope of this Application Note and is covered by the Mode Management Application Note, which can be found here: *INSERT LINK TO WORKFLOW 05 WHEN IT IS PUBLISHED*

Step 5. Code generation

Now you need to generate the BSW code; in this way the BSWMD files will be generated and the NvM module will be recognized and available to be added to the composition.

After this step, the BSW code for the RTA-MEM stack will be generated as well as the NVM Service component.

If BSW fails, you may need to remove the element FlsAcLoadJobOnStart under Fls. You will also need to update the NvMBlockLength attributes so they are greater than 0. This can be done like so:

Open RTA Code Generator dialog...

Ensure that the RTA-MEM stack is selected for the generation:

Then select Generate RTA-BSW to generate the BSW code.

Step 6. Add the NvM Service component to your composition

Running the BSW Codegen with NvM selected will create a NvM Service Component,

Now that the Service Software Component for NvM has been created, you'll need to add it to your composition. To do so, right click on your composition from the AR Explorer and open it with the Composition Editor.

Then select at the top of the window the Component Prototype.

Then a pop-up will appear and it will allow the selection of the NVM Service component (CPT_NvM) in order to add it to the composition. Click OK.

Once you have created the Component Prototype you should find that the components connections and open ports will be displayed:

Note: You might need to check some fields in the Filter if the connections have not been displayed.

Step 7. Create connections between the Receiver software component and NvM Service component

The NvM services will be accessible to your MyReceiverSWC by connecting it with the NVM Service component which has been generated by RTA-BSW. But first we will need to add an NvM Service Port to the MyReceiverSWC. We will then need to add a Server Call Point that references the NvMService port we will create.

To do so, in AR Explorer right click on the MyReceivingSWC > Open With > Service Needs.

Under the NvM Service Needs tab click on Add Service Ports in the Service Needs Editor of the SWC. In the pop-up window select Already available interfaces and then check Client Server Interfaces > NvMService > OK.

Now open the SWC in the Component Editor:

To add the Server Call Point, switch to Functions Tab, then on the right switch to sub-tab Server Call Points and press the + Server Call Points... button. In the pop-up window select SynchronousServerCallPoint and then select R_NvMService_0:

Now that the the NvM has been added to the ECU configuration, you must connect its ports to MyRecieverSWC. Open the TopLevelComposition in the Composition Editor and switch to tab "Manual Connection Editor".

On the left under Source Component, select CPT_NvM and select the port NvMNativeBlock_2, then on the right under Target Component, select the MyRecieverSWC and select R_NvMService_0. Repeat this for NvM_NativeBlock_3.

Step 8. Update ECU Extract

At this point we should update the ECU Extract to reflect the changes we've made. Right click on the System and select Create ECU Extract as done before. Make sure Update existing ECUExtract is checked.

Step 9. Map the SWC runnables to an Os Tasks

We will now need to map the runnables which belong to the components we have created in this guide, to an Os task. As these are all Basic Software Modules, we will want to map them to the OsTask_BSW.
As the Fee_MainFunction and Fls_MainFunction are called by MemIf_Rb_MainFunction, we do not need to map these functions. We need to map SE_MainFunction from the NvM module, and MemIf_Rb_MainFunction from the MemIf module. MemIf_Rb_MainFunction should be scheduled before NvMs SE_MainFunction.

Open the existing EcuC Value Collection and switch to the Entity to Task Mapping Tab and drag the Runnables from the unmapped entities table on the right, to OsTask_BSW which is situated in the mapped entities table on the left.

4.10. RTE generation

You can now generate the RTE code. To do this, use the RTA-RTE plug-in, press the RTA Code Generator button in the menu bar and select Generate RTA-RTE from the drop down menu.

4.11. MCAL update

Remember to update the MCAL. This step is target dependent; when using the ETAS Virtual Target (VRTA), the MCAL is regenerated using the mcalgen.exe tool.

4.12 ASW Update

Now you can update the code in your ASW in order to use the PIM. In the ASW, you can use the services provided by the BSW (for example mark the block to be written during shutdown).

You can find an example of ASW implementation in the VRTA RTA Starter Kit: