Autosar Classic compliant modules

The analysis of Autosar Classic compliant software, relies on the ARXML files describing the Software Component of the runnable. The ARXML files need to be provided to the utility to get information such as:

  • Runnables name

  • Runnables periodicity

  • Port interfaces

  • Input/Output types

  • etc …

These details are used to generate the SIL (Software In the Loop) wrapper (including a mock RTE) for the compilation, including example CSV files that can be generated to provide specific measures (datasets) to stimulate the execution of the runnable.

HPROF generation command for Autosar compliant software

By default, Autosar compliant software provided is analyzed at the SWC (Software Component) level. The utility simulates a schedule of the runnables in the SWC, hence the measures provided as input need to refer to the input ports of the SWC itself. As a result, you can expect multiple HPROF files, one for each runnable in the SWC.

Here’s an example command to generate the HPROF performing the analysis at the SWC level on AWS:

python hux-autosar-sil.py generate_hprof \
  -i <arxml_files_folder> \
  -m <map_file> \
  -I <library_folder_to_include> \
  -I <library_folder_2_to_include> \
  -c <library_folder_to_include> \
  -c <library_folder_2_to_include> \
  -v <csv_files> \
  --aws \
  -z <sil_archive_name> \
  -b <aws_bucket_name> \
  -ho <hprof_output_file>

The -i flag is used to provide the ARXML files to process. In this case the utility will process all the ARXMLs in <arxml_files_folder> folder, to identify the components, runnables and variables, and process the map file <map_file> to identify variable mapping.

The -I and -c flags are necessary for the creation of the Makefile, to know which are the include paths to use and the source files to compile respectively.

The -v flag is used to specify a CSV file containing the input dataset. If not specified, a random dataset will be generated to test the runnable.

This command produces the following outputs:

  • a zip file containing all the generated files (mock RTE) for the SIL

  • the HPROF files of the runnables analyzed

To organize the outputs produced by the command, it is possible to use the -z flag to specify the name of the zip file, and the -ho flag to specify the base name of the HPROF files.

Analysis at runnable level vs SWC level

The default behavior of the utility for Autosar compliant software is an analysis at SWC component level. It is however possible to:

  1. perform an analysis at SWC level but generate the HPROF file for a single runnable

  2. perform an analysis at runnable level

The main difference between the two analyses is in the input measure provided to the tool. In case 1., as the analysis is at the software component level, the utility expects the input signals of the SWC. Here’s an example command:

python hux-autosar-sil.py generate_hprof \
  -r <runnable_name> \
  -i <arxml_files_folder> \
  -m <map_file> \
  -I <library_folder_to_include> \
  -I <library_folder_2_to_include> \
  -c <library_folder_to_include> \
  -c <library_folder_2_to_include> \
  -v <csv_file_of_swc> \
  --aws \
  -z <sil_archive_name> \
  -b <aws_bucket_name> \
  -ho <hprof_output_file>

Notice the -r flag used to specify the name of the runnable to analyze.

In case 2. the utility expects to have the input signals of the runnable. As in this example:

python hux-autosar-sil.py generate_hprof \
  -rs \
  -r <runnable_name> \
  -i <arxml_files_folder> \
  -m <map_file> \
  -I <library_folder_to_include> \
  -I <library_folder_2_to_include> \
  -c <library_folder_to_include> \
  -c <library_folder_2_to_include> \
  -v <csv_file_of_runnable> \
  --aws \
  -z <sil_archive_name> \
  -b <aws_bucket_name> \
  -ho <hprof_output_file>

The utility generates a single HPROF file for the <runnable_name> to be stimulated with the input CSV file containing input measures of the runnable.

Use a mapfile to provide symbol location

To get a more accurate performance analysis, the analysis can include information regarding the memory mapping of the I/Os of the runnables and the location of the code in the flash memories. These information can be parsed by the utility during the analysis, by providing a mapfile with the -m flag.

By providing the mapfile, the performance report takes into consideration the location of the symbols, and, based on their exact location, is able to provide a more accurate estimate for a specific architecture When the software is then analyzed on a different target, the symbol location will not be taken into consideration.

Generate a CSV template file for the input stimuli

Depending on the level of analysis performed (runnable vs SWC level), it is possible to generate a template CSV file, containing the name of the input stimuli that are necessary to perform the analysis with a real-case dataset. In case the input CSV file is not provided, the input stimuli are randomly generated.

If you want to provide stimuli for the function to be simulated, you must also submit a CSV file organized as in the example below. The -v flag is used to specify the input CSV file. Each column of the CSV file needs to have the variable name as first entry (header) and all the values for each timeframe as entry below. If the variable name is composite, then its name must be described as <parent variable name>.<child variable name> as reported in the example.

Example file for analysis at runnable level:

Rte_Var_1_P,Rte_Var_2_P.var_2_C
0.0,228.0
0.001,228.0
0.002,228.0

When the analysis is performed at SWC level, the variables provided must be the ones in input to the SWC. Furthermore, there is an additional field represented by the time keyword, expressed in seconds.

Example file for analysis at runnable level:

time, Rte_Var_1_Inport,Rte_Var_2_Inport.var_2_C
0.1,0.0,228.0
0.2,0.001,228.0
0.3,0.002,228.0

The following command allows you to generate a CSV template file containing all the variables useful for simulating a SWC.

python hux-autosar-sil.py generate_template -i <arxml_files_folder> -o <output_csv_file_name>

When the analysis focuses on a single runnable, it is necessary to use the -rs and -r (omittable in case of a single runnable in the SWC), to specify the analysis at runnable level, and the specific runnable for which the utility needs to generate the template:

python hux-autosar-sil.py generate_template -rs -r <runnable_name> -i <arxml_files_folder> -o <output_csv_file_name>

The -i flag specifies the folder and/or the filename of the ARXML files to process. The generated <custom_name>.csv is the output. .. note:

Generating the template using this command is strongly recommended to avoid possible errors.

Avoid RTE stub creation

When providing the ARXML file, the utility will automatically create an RTE stub for dynamic code analysis. It is possible to avoid the RTE stub creation as follows:

  1. use the –skip-rte-stub-generation so that the utility does not automatically generate the stub and

  2. specify the new sources that can be used for the RTE stub with the -I and -c flags.