Configure AUTOSAR Code Generation

To generate AUTOSAR-compliant C code and ARXML component descriptions from a model configured for the AUTOSAR Classic Platform:

In the Configuration Parameters dialog box, on the Code Generation > AUTOSAR Code Generation Options pane, configure AUTOSAR code generation parameters.
Configure AUTOSAR XML export options by using the AUTOSAR Dictionary or AUTOSAR property functions.
Build the model.

Select AUTOSAR Classic Schema

For import and export of ARXML files and generation of AUTOSAR-compliant C code, the software supports the following AUTOSAR Classic Platform schema versions.

Schema Version Value	Schema Revisions Supported for Import	Export Schema Revision
`R22-11` (default)	R22-11	R22-11
`R21-11`	R21-11	R21-11
`R20-11`	R20-11	R20-11
`R19-11`	R19-11	R19-11
`4.4`	4.4.0	4.4.0
`4.3`	4.3.0, 4.3.1	4.3.1
`4.2`	4.2.1, 4.2.2	4.2.2
`4.1`	4.1.1, 4.1.2, 4.1.3	4.1.3
`4.0`	4.0.1, 4.0.2, 4.0.3	4.0.3

Selecting the AUTOSAR system target file for your model for the first time sets the schema version parameter to the default value, R22-11.

If you import ARXML files into Simulink^®, the ARXML importer detects the schema version and sets the schema version parameter in the model. For example, if you import ARXML files based on schema 4.3 revision 4.3.0 or 4.3.1, the importer sets the schema version parameter to 4.3.

When you build an AUTOSAR model, the code generator exports ARXML descriptions and generates C code that comply with the current schema version. For example, if Generate XML file for schema version (Embedded Coder) equals 4.3, export uses the export schema revision listed above for schema 4.3, that is, revision 4.3.1.

Before exporting your AUTOSAR software component, check the selected schema version. If you need to change the selected schema version, use the model configuration parameter Generate XML file for schema version.

Note

Set the AUTOSAR model configuration parameters to the same values for top and referenced models. This guideline applies to Generate XML file for schema version (Embedded Coder), Maximum SHORT-NAME length (Embedded Coder), Use AUTOSAR compiler abstraction macros (Embedded Coder), and Support root-level matrix I/O using one-dimensional arrays (Embedded Coder).

Specify Maximum SHORT-NAME Length

The AUTOSAR standard specifies that the maximum length of SHORT-NAME XML elements is 128 characters.

To specify a maximum length for SHORT-NAME elements exported by the code generator, set the model configuration parameter Maximum SHORT-NAME length (Embedded Coder) to an integer value between 32 and 128, inclusive. The default is 128 characters.

Configure AUTOSAR Compiler Abstraction Macros

Compilers for 16-bit platforms (for example, Cosmic and Metrowerks for S12X or Tasking for ST10) use special keywords to deal with the limited 16-bit addressing range. The location of data and code beyond the 64k border is selected explicitly by special keywords. However, if such keywords are used directly within the source code, then software must be ported separately for each microcontroller family. That is, the software is not platform-independent.

AUTOSAR specifies C macros to abstract compiler directives (near/far memory calls) in a platform-independent manner. These compiler directives, derived from the 16-bit platforms, enable better code efficiencies for 16-bit micro-controllers without separate porting of source code for each compiler. This approach allows your system integrator, rather than your software component implementer, to choose the location of data and code for each software component.

For more information on AUTOSAR compiler abstraction, see www.autosar.org.

To enable AUTOSAR compiler macro generation, select the model configuration parameter Use AUTOSAR compiler abstraction macros (Embedded Coder).

When you build the model, the software applies compiler abstraction macros to global data and function definitions in the generated code.

For data, the macros are in the following form:

CONST(consttype, memclass) varname;
VAR(type, memclass) varname;

where

consttype and type are data types
memclass is a macro string SWC_VAR_INIT (SWC is the software component identifier)
varname is the variable identifier

For functions (model and subsystem), the macros are in the following form:

FUNC(type, memclass) funcname(void)

where

type is the data type of the return argument
memclass is a macro string. This string can be either SWC_CODE for runnables (external functions), or SWC_CODE_LOCAL for internal functions (SWC is the software component identifier).

If you do not select Use AUTOSAR compiler abstraction macros, the code generator produces the following code:

/* Block signals (auto storage) */
BlockIO rtB;

/* Block states (auto storage) */
D_Work rtDWork;

/* Model step function */
void Runnable_Step(void)

However, if you select Use AUTOSAR compiler abstraction macros, the code generator produces macros in the code:

/* Block signals (auto storage) */
VAR(BlockIO, SWC1_VAR_INIT) rtB;

/* Block states (auto storage) */
VAR(D_Work, SWC1_VAR_INIT) rtDWork;

/* Model step function */
FUNC(void, SWC1_CODE) Runnable_Step(void)

Root-Level Matrix I/O

For an AUTOSAR component model with multidimensional arrays, if you set the model configuration parameter Array layout (Simulink Coder) to Row-major, you can preserve dimensions of multidimensional arrays in the generated C code. Preserving array dimensions in the generated code can enhance code integration.

If your application design requires Column-major array layout, you can configure ARXML export to support root-level matrix I/O. The software can export ARXML descriptions that implement matrices as one-dimensional arrays.

By default, for Column-major array layout, the software does not allow matrix I/O at the root level. Building the model generates an error. To enable root-level matrix I/O, select the model configuration parameter Support root-level matrix I/O using one-dimensional arrays (Embedded Coder).

When Array layout is set to Row-major, Support root-level matrix I/O using one-dimensional arrays has no effect.

Inspect AUTOSAR XML Options

Examine the XML options that you configured by using the AUTOSAR Dictionary. If you have not yet configured them, see Configure AUTOSAR XML Options.

Generate AUTOSAR C and XML Files

After configuring AUTOSAR code generation and XML options, generate code. To generate C code and export XML descriptions, build the component model.

The build process generates AUTOSAR-compliant C code and AUTOSAR XML descriptions to the model build folder. The exported XML files include:

One or more modelname*.arxml files, based on whether you set Exported XML file packaging to Single file or Modular.
If you imported ARXML files into Simulink, updated versions of the same files.

This table lists modelname*.arxml files that are generated based on the value of the Exported XML file packaging option configured in the AUTOSAR Dictionary.

Exported XML File Packaging Value	Exported File Name	By Default Contains...
`Single file`	`modelname.arxml`	AUTOSAR elements for software components, data types, implementation, interfaces, and timing.
`Modular`	`modelname_component.arxml`	Software components, including: Ports Events Runnables Inter-runnable variables (IRVs) Included data type sets Component-scoped parameters and variables This is the main ARXML file exported for the Simulink model. In addition to software components, the component file contains packageable elements that the exporter does not move to data type, implementation, interface, or timing files based on AUTOSAR element category.
	`modelname_datatype.arxml`	Data types and related elements, including: Application data types Software base types Data type mapping sets Constant specifications Physical data constraints System constants Software address methods Mode declaration groups Computation methods Units and unit groups Software record layouts Internal data constraints
	`modelname_implementation.arxml`	Software component implementation, including code descriptors.
	`modelname_interface.arxml`	Interfaces, including S-R, C-S, M-S, NV, parameter, and trigger interfaces. The interfaces include type-specific elements, such as S-R data elements, C-S operations, port-based parameters, or triggers.
	`modelname_timing.arxml`	Timing model, including runnable execution order constraints.

You can merge the AUTOSAR XML component descriptions back into an AUTOSAR authoring tool. The AUTOSAR component information is partitioned into separate files to facilitate merging. The partitioning attempts to minimize the number of merges that you must do. You do not need to merge the data type file into the authoring tool because data types are usually defined early in the design process. You must, however, merge the internal behavior file because this information is part of the model implementation.

To help support the round trip of AUTOSAR elements between an AUTOSAR authoring tool (AAT) and the Simulink model-based design environment, the code generator preserves AUTOSAR elements and their universal unique identifiers (UUIDs) across ARXML import and export. For more information, see Round-Trip Preservation of AUTOSAR XML File Structure and Element Information.

For an example of how to generate AUTOSAR-compliant C code and export AUTOSAR XML component descriptions from a Simulink model, see Generate AUTOSAR C Code and XML Descriptions.

For information regarding all XML Options, see AUTOSAR XML Options Settings

Related Examples

More About

Round-Trip Preservation of AUTOSAR XML File Structure and Element Information