Table of Content

Introduction

Scope

This application note describes different Variant Management Mechanisms that can be used with ISOLAR A/B 9.2.0, in particular:

• PreBuild artifact selection: is a Variant Management mechanism which enables the selection of product specific artifacts (files or folders) from a product line. The user can select in the project which is the Variant that he wants to configure and work separately with more Variants but in the same project.
• PostBuild loadable (PBL): is a mechanism which enables the flashing of different Hex code parts in specific areas of the memory, changing the current configuration of the ECU. With the PBL the BSW configuration of an ECU can be updated at PostBuild time, without rebuilding the complete application software and BSW.
• PostBuild selectable: is a mechanism which enables the selection of different Hex code parts at ECU load time. Each variant will load different parameters during the initialization. The customer can switch between alternative BSW configurations of an ECU at PostBuild time.

Definitions and Abbreviations

BSW: AUTOSAR Basic Software, Hardware independent service layer

RTE: AUTOSAR Run-Time Environment

OS: AUTOSAR Operating System

SWC: Software Component

Toolchain

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

PreBuild Artifact Selection with MIC

This section describes the steps to create a MIC configuration with multiple variants and import DBC file into respective Variants.

The name MIC stands for "Metadata Information Container" and it represents a Workspace Management System to extend information of conventional resources.

MIC supports artefact based variant management. Therewith it gives the opportunity to activate and deactivate workspace management information base on specific variants of a software project.

• It offers a file-based approach to variant configuration.
• Individual configuration files and their associated generated artefacts are assigned to specific variants.
• MIC enables or disables the configuration files according to the selected variant and manages the generated source code and other artefacts.

A project can have multiple variants configured but at a time, only one variant can be active.

All MIC files have to be stored under the folder "_metadata/mic/" that is called MIC persistence area.

The MIC data which are placed in the MIC persistence area are all stored in files with the common extension '*.mic'. 

• type.mic: contains information that describes additional properties for resources. Such properties are key/value attributes for files and folders, e.g. domain and class attributes;
• variants.mic: stores the specification of variants for a certain folder. The variants.mic file itself is the upper most configuration element called VariantConfigurationUnit (VCU). 

A VCU is a self-contained, logical container for the specification of variants for the associated folder and all child resources. Basically each folder in a resource hierarchy can be turned into a VCU just by adding a related variants.mic file. The resources which can be referenced within a VCU are limited. The sum of all elements which can be referenced is called the scope (or in-scope) and defined as follows:

• VCU-Scope: all artifacts selected in a VCU (simple files, folders and VCU's itself) must be reachable from the current VCU or any of its parent VCU's without bypassing any of the VCU's in between. Elements which are on the parent chain cannot be included.

Per convention there has to be at least one VCU on project level if the project need to make use of the variants concept. It contains the variants selectable by the clients, called RootConfigurations. E.g. a VCU of a software component might act as RootConfiguration if the components folder is the root of the project (i.e. the context of work) while in the context of an outer project the same configuration will be a simple VCU.

The content of a VCU is separated into a settings section, containing general processing instructions and a variant configuration part containing the actual definition of variants.

Create a MIC project 

With the new tool version it is not needed anymore to convert the RTA-CAR project to MIC project and got it imported to ISOLAR-A/B as in the old versions.

Now, it is sufficient to set the variant handling configuration variant strategy to MIC.

To do so, create a new RTA-CAR project clicking on FIle → New → RTA-CAR Project

chose the RTA-CAR generic project and click next,

In the next window click on Advanced option and set the configuration variant handling to MIC as shown in the below image

Then click Finish.

When viewed through the Filesystem Navigator, the newly-created project will look like this, following the MIC folder structure:

As shown in the image above, the project root contains an area with MIC information.

In the new project the type file is present, it contains information such properties are key/value attributes for files and folders, e.g. domain and class attributes.

Create MIC variants

This section describes how a variant could be created in a MIC project with ISOLAR-A/B 9.2.

First, from the Filesystem Navigator, Open VCU Editor (Using the menu MIC Utils → Open New VCU. This menu will be active only for the first time we create VCU. From next time, you must use Open Related VCU)

Then, add a Common Configuration by clicking the icon highlighted below:

A Common Configuration is a special Variant Configuration which will be applied to the related VCU always. It’s a convenience feature to avoid redundant definition of resources common to all variants.

If there are no variants, i.e. the CommonConfiguration is the only VC in the VCU, the CommonConfiguration acts as a default configuration and thus the parent components do not need to select a certain variant explicitly.

There can be only one CommonConfiguration per VCU.

After, go to Variant Configuration tab and select the Common Variant, selecting all the files:

 Then, create specific variants clicking on Add a new pre configuration, say “Variant_A” and “Variant_B”, and two folders will be created on to the project called “Variant_A” and “Variant_B”.

There can be any number of variants defined for a single VCU. If there're variants defined, clients including the related VCU are forced to select exactly one variant.

The variant located at the VCU on project level are called RootConfigurations. A RootConfiguration is a top level variant which can be activated by the user. E.g. a software build will generate files for a specific variant.

Finally, associate the files and folders for respective variant like shown below. This step can be done each time a new file is added to the project.

• common configuration: set the common variant on the Pick a configuration option and choose the files and folders that are in common for all variants by clicking on the box next to their name under Artifact Selection:

• variant A configuration: set the variant A on the Pick a configuration option and choose the files and folders that are Variant A only by clicking on the box next to their name in the Artifact Selection:

• variant B configuration: set the variant B on the Pick a configuration option and choose the files and folders that are Variant B only by clicking on the box next to their name in the Artifact Selection:

Active Variant selection

Select the Active Variant during the project development enables or disables the configuration files according to the selected variant and manages the generated source code and other artefacts.

MIC offers a file-based approach to variant configuration, variants have assigned individual configuration files and their associated generated artefacts. 

By defaults, the first created variant would be active. User can change the active variant using the below option available in Project Properties → Project Configuration → Project Variant

When you switch the variant, tool will automatically register all the files belong to selected current variant and also unregister all the files belong to other variants. This can be verified by the decorator next to each file.
Here in below image, the current variant is “Variant_B”. The folder “Variant_A” does not have the tag [Container] whereas the folder “Variant_B” has it.

DBC import

This section describes how to get multiple DBC imported to the same project but for different variants.

For demonstration purpose, we take two DBC files, “Variant_A.dbc” and Variant_B.dbc.

Import the “Variant_A.dbc” DBC file in a usual way. Enter the “<ACTIVE_VARIANT>” in the File Name text box as shown below to get the files generated inside the Variant_A folder

Repeat the steps also for Variant_B after switch Variant using the following option to switch the Variant to “Variant_B”.

Make sure you type “Variant_B” in the DBC window to get the file generated inside the location.

Classifying DBC imported files to the Variant

When a new file is generated it will not be automatically classified following the rules present inside the "rta_rules.mrf" file that determined the class. So, it will not be present inside the "types.mic" file and in the Filesystem view no class will appear related to these files.

Resources will be classified regardless to which variant they belong and the classification of a resource will not automatically add it to a variant. 

• Classify Subtree (preserve) / (Overwrite): when choosing one of the “Classify subtree” menu entries, the selected resources and, in case of folders, all resources below the folders will be classified. If no classification rules can be applied for a specific resource, no classification will be generated for the resource. Sub-tree classification can be either run in “overwrite” or in “preserve” mode. In “overwrite” mode, previously existing classifications will be overwritten, in “preserve” mode, classification will only be generated for resources with no existing classification.
• Classify resource (Overwrite): when choosing the menu entry “Classify resource”, only the actually selected resources will be classified. If no classification rules can be applied for a selected resource, no classification will be generated. Previously existing Classifications for the selected resources will be overwritten.

To classify the files that are added to the project click on MIC Utils → Classify subtree (overwrite)

N.B. This step is required any time files are added to a project.

ECU Extract Generation

This section describes how the ECU Extract generation can be done in a MIC project.

1. Select Create ECU Extract
2. In the Create ECU Extract dialog, select Customize Preferences
3. Navigate to Flat Map And Package Path Settings and enter <ACTIVE_VARIANT>/ for each of the file locations:

This only needs to be done once per user/workspace and will automatically place the generated ECU Extract into the select MIC Variant folder you created above.

Creating Splitable Elements

MIC variant handling is file based and thus creating elements which are splitable is required.
The example below shows how to split System Data Mappings. In most circumstances this type of configuration (creating the splitable elements) only needs to be done once. Afterwards the created split files can be modified directly for that particular variant.

First, create your initial Data Mappings, with a single System (possibly already available) and open the System with the Generic Editor then expand out to find the SenderRecieverToSignalMapping top level view and ctrl+Click each of the mappings you want to split into their own file then Right Click and select Move/Split:

Select Create New File and for the AR Filename enter in the path to the variant folder and the new filename

In order for Data Mappings to be split across multiple files, the System Mapping container short name needs to be unique across files. Expand out in the AR Explorer the newly created System Mapping file, Right-Click on the new System Mapping and select Rename

Give it a new name and when prompted, uncheck the original (common) System file that SHOULD NOT be renamed and click OK

Additional configurations and mappings can be done within their respective files.

RTA-BSW Conf Gen

This section describes how the conf gen can be executed on the project.

After switching to the current variant, Click on RTA-BSW Conf Gen button.

Classify project variant. Refer the section Variant Handling - Configure Post Build Selectable project

Repeat above steps after switching to “Variant_B”.

RTA-BSW / RTE Code Gen

This section describes the steps needed code generation.

Open the RTA Code Generator GUI and verify that /{ACTIVE_VARIANT} is written on the Root output path to route the generated artifacts to the respective folders.

This will automatically fetch the active variant and place all generated files into that specific folder.

Classify project variant. Refer the section  Variant Handling - Configure Post Build Selectable project

Additionally, for RTE generation, make sure that in the Included AR Files tab that you only select the files related to the particular variant you are generating.

PostBuild 

The following modules have an alternate workflow for Post Build support:

Module	Post Build Loadable	Post Build Selectable
CanTp
FrTp
CanNm
FrNm
BswM

PostBuild Selectable

PostBuild Selectable (PBS) of ECU configuration means that the OEM can switch between alternative BSW configurations of an ECU at PostBuild time.

Alternative BSW configurations are provided in the Hexcode by the Tier-1 and the OEM can select one configuration. Instead of several ECU’s the OEM has only one ECU which supports multiple ECU variants.

Decision about the valid set will be done at EcuM_startup.

To enable Post-build Selectable, more than one variant shall be configured in the RTA-CAR project.

To configure the Variant Info right click on Variant Info → create Predefine Variant and create two variants, in this example called Master and Slave

Add the variant references to the EcuC configuration clicking on the green plus button present on EcucPostBuildVariants and selecting the two variants

Configure the post build by right clicking on the FrTpLa and selecting Configure Post Build Variants 

Configure EcuM to init with Post-Build pointer:

Write EcuM integration code to determine which Post-Build Configuration select:

PostBuild Loadable

Post Build Loadable (PBL) of ECU configuration means that BSW configuration of an ECU can be updated by OEM ( without interacting with Tier-1 supplier ) at PostBuild time, without rebuilding the complete application software and BSW.  A dedicated memory section shall be used for flashing the new configuration by OEM.

All the details on how to calibrate a parameter using PostBuild Loadable can be found Diagnostic Calibration.

To check if a BSW parameter can be calibrated using PostBuild Loadable:

• Step 1. understand in which structure/variable the parameter is contained: one possible technique is to change the value of that parameter in a test project, regenerate the code and check which structure/variable has been updated.
• Step 2. understand if the parameter can be assigned to a memory section: this is needed in order to control that the parameter can be placed in the area of memory that will be later on calibrated.
• Step 3. in order to be assigned to a specific memory section, the parameter must be surrounded by the macros “xxx_START_SEC_ROM_CONST” and “xxx_STOP_SEC_ROM_CONST”.

N.B. After you calibrate a parameter in PostBuild Loadable, the reset of the ECU is needed (or at least high recommended)! 

This is because most of these parameters are used in the initialization phase of the ECU. If you don’t re-initialize, there might be inconsistencies.