Generating Code That Complies with AUTOSAR Standards :: Developing Models and Code That Comply with Industry Standards and Guidelines (Real-Time Workshop® Embedded Coder™)

Learn more about Real-Time Workshop Embedded Coder

Generating Code That Complies with AUTOSAR Standards

On this page…
Overview of AUTOSAR Support Importing an AUTOSAR Software Component Using the Configure AUTOSAR Interface Dialog Box Configuring Ports for Basic Software and Error Status Receivers Configuring Client-Server Communication Configuring Calibration Parameters Modifying and Validating an Existing AUTOSAR Interface Exporting a Single Runnable Entity AUTOSAR Software Component Configuring Multiple Runnable Entities Configuring AUTOSAR Options Programmatically Verifying the AUTOSAR Code Using Software-in-the-Loop Testing Limitations and Tips Migrating AUTOSAR Development Kit Models Demos and Further Reading

On this page…

Overview of AUTOSAR Support

Importing an AUTOSAR Software Component

Using the Configure AUTOSAR Interface Dialog Box

Configuring Ports for Basic Software and Error Status Receivers

Configuring Client-Server Communication

Configuring Calibration Parameters

Modifying and Validating an Existing AUTOSAR Interface

Exporting a Single Runnable Entity AUTOSAR Software Component

Configuring Multiple Runnable Entities

Configuring AUTOSAR Options Programmatically

Verifying the AUTOSAR Code Using Software-in-the-Loop Testing

Limitations and Tips

Migrating AUTOSAR Development Kit Models

Demos and Further Reading

Overview of AUTOSAR Support

Real-Time Workshop Embedded Coder software supports AUTomotive Open System ARchitecture, AUTOSAR, an open and standardized automotive software architecture. AUTOSAR is jointly developed by automobile manufacturers, suppliers, and tool developers.

You can use Real-Time Workshop Embedded Coder software to import AUTOSAR software components into Simulink models, generate AUTOSAR-compliant code, and export AUTOSAR-compliant XML files. You can configure your models by GUI, command-line functions, or AUTOSAR-compliant XML files.

The following table maps different aspects of working with AUTOSAR components to the relevant sections.

Workflow	Description and Links to Sections
Importing an AUTOSAR software component	Import AUTOSAR software component description XML files, including calibration parameters for use in your model. Importing an AUTOSAR Software Component Configuring Calibration Parameters
Configuring for AUTOSAR-compliant code generation	Configure AUTOSAR code generation options and XML export options through a GUI or programmatically. Using the Configure AUTOSAR Interface Dialog Box Configuring Ports for Basic Software and Error Status Receivers Configuring Client-Server Communication Configuring AUTOSAR Options Programmatically
Validating a modified AUTOSAR interface	Validate your interface from the Configure AUTOSAR Interface dialog box or programmatically. Using the Configure AUTOSAR Interface Dialog Box Modifying and Validating an Existing AUTOSAR Interface
Exporting an AUTOSAR Software Component	After configuring your AUTOSAR export options, generate code to export your AUTOSAR component. Building the subsystem or model generates the code and XML according to your customizations. Exporting a Single Runnable Entity AUTOSAR Software Component Configuring Multiple Runnable Entities
Verification	Verifying the AUTOSAR Code Using Software-in-the-Loop Testing

Importing an AUTOSAR Software Component

Use the arxml.importer class to parse an AUTOSAR software component description file (for example, exported from a tool such as DaVinci System Architect from Vector Informatik Gmbh) and import into a Simulink model for configuration, code generation, and export to XML. For a complete list of methods, see AUTOSAR in the Real-Time Workshop Embedded Coder Function Reference documentation. You use functions in the following order:

Call arxml.importer('mySoftwareComponentFile.arxml') to create an importer object that looks for atomic software components in the specified "main" XML file. You can see reports at the command line describing identified atomic software components. You can have multiple components.
For example:
```
The file "mySoftwareComponentFile.arxml" contains:
  1 Atomic-Software-Component-Type:
    '/ComponentType/complex_type_component'
  3 CalPrm-Component-Type:
    '/ComponentType/MyCalibComp1'
    '/ComponentType/MyCalibComp2'
    '/ComponentType/MyCalibComp3'
```
Use SetFile to change the main file and update the list of components.
Each software component requires an arxml.importer object. For each arxml.importer object, specify the file that contains the software component that you want.
Use the setDependencies method if you need to specify additional dependent XML files containing the information that completes the software component description (for example, data types, interfaces). You can specify a cell array of files or a single file.
Complete specifying dependencies only for components that you intend to import into Simulink.
To import a parsed atomic software component into a Simulink model, call one of the following methods. If you have not specified all dependencies for the components, you will see errors.
- arxml.importer.createComponentAsSubsystem — Creates and configures a Simulink subsystem skeleton corresponding to the specified atomic software component description.
- arxml.importer.createComponentAsModel — Creates and configures a Simulink model skeleton corresponding to the specified atomic software component description.
  For example:
```
importer_obj.createComponentAsModel('/ComponentType/complex_type_component')
```
- arxml.importer.createCalibrationComponentObjects — Creates Simulink calibration objects corresponding to the specified AUTOSAR calibration component description.
  For example:
```
[success] = createCalibrationComponentObjects(importerObj,
CreateSimulinkObject, 'true')
```
See also the limitation, Cannot Import Internal Behavior.

After you import your software component into Simulink, you can modify the skeleton model or subsystem. To configure AUTOSAR code generation options and XML export options, see Using the Configure AUTOSAR Interface Dialog Box or Configuring AUTOSAR Options Programmatically).

To see how to import, modify, and export AUTOSAR software components, see the Import and Export an AUTOSAR Software Component demo.

Using the Configure AUTOSAR Interface Dialog Box

Use the Configure AUTOSAR Interface dialog box to configure your AUTOSAR code generation and XML import and export options. Alternatively, you can use functions to control all AUTOSAR options programmatically.

In any model using the autosar.tlc system target file, you can open the Configure AUTOSAR Interface dialog box by right-clicking a subsystem and selecting Real-Time Workshop > AUTOSAR Single or Multi-Runnable Component > Configure.

Single-Runnable menu options are enabled only for atomic or function-call subsystems.

Multi-Runnable menu options are enabled only for virtual subsystems.

To configure your AUTOSAR options:

Clear the Configure I/O for server operation check box. Select this check box only when you want to configure your Simulink model as a server operation (see Configuring a Server Operation).
Click Get Default Configuration to populate the controls for your model.
The runnable entity names, XML properties, and I/O configuration are initialized. If you click Get Default Configuration again later, only the I/O configurations are reset to default values.
In the Configure AUTOSAR Interface pane, use the controls to change your AUTOSAR code generation options and XML export options, for example, send and receive communication options such as port and interface names, data access modes, runnable entity, initialization, and periodic function names.
- On the Configure I/O tab, designate inports and outports as data sender/receiver ports, error status receivers, or as access points to basic software.
  
  To designate inports and outports as sender or receiver ports, set each port's Data Access Mode to either Implicit, where data is buffered by the run-time environment (RTE), or Explicit where data is not buffered and therefore not deterministic.
  Use the port interface settings to reflect your AUTOSAR port best practices. For example, some AUTOSAR users like to group related data into the same AUTOSAR port. You can achieve this arrangement in the GUI by duplicating AUTOSAR port names. Alternatively, you can use the AUTOSAR port to group information individually; in this case, a common approach is to set all of the data element settings to something neutral, for example, 'data', and leave the AUTOSAR port names as they are. You can also use the AUTOSAR interface name for any best practices that you might have. For example, you can set up interfaces for individual AUTOSAR ports by ensuring that the interface names change when the AUTOSAR port name changes, for example, by prefixing the AUTOSAR interface of the corresponding AUTOSAR port name with an 'if_'.
  For more information on all these options, see AUTOSAR in the Real-Time Workshop Embedded Coder Function Reference documentation.
  You also use Data Access Mode to designate ports to access basic software or error status. See Configuring Ports for Basic Software and Error Status Receivers.
- On the Configure Runnables tab, specify the names of your runnable entity, initialization, and periodic functions.
- On the XML Options tab, specify the names and package paths of the XML files that you publish when you generate code. For more details about these files, see Exporting a Single Runnable Entity AUTOSAR Software Component.
After you configure your options, click Validate, which calls runValidation. If there are problems, you see messages describing why the configuration is invalid.
If validation succeeds, click OK to return to the Configuration Parameters dialog box.
Save your model and then generate code to export your AUTOSAR component.

Configuring Ports for Basic Software and Error Status Receivers

You can configure ports to access AUTOSAR services and device drivers (AUTOSAR basic software), and to access communication error status in your model. You can configure ports programmatically or by using the AUTOSAR Model Interface dialog box. To open the dialog box, right-click a subsystem and select Real-Time Workshop > AUTOSAR Single or Multirunnable Component > Configure.

In the dialog box, you can specify the Data Access Mode of every port.

Designate inports and outports as access points to basic software.
If you select Basic Software, specify the service name, operation, and interface. The service name and operation must be valid AUTOSAR identifiers, and the service interface must be a valid path of the form AUTOSAR/Service/servicename.

After you export your AUTOSAR components, you must include your service interface definition XML file to import correctly into an authoring tool.
Designate inports to receive error status.
If you select Error Status for an inport, you must select the other port (of mode Implicit or Explicit Receive) to listen to, for error status. Error status ports must use uint8 data type (or an alias).

Configuring Client-Server Communication

AUTOSAR allows client-server communication between:

Application software components
An application software component and Basic Software

An AUTOSAR Client-Server Interface defines the interaction between a software component that provides the interface and a software component that requires the interface. The component that provides the interface is the server. The component that requires the interface is the client.

In Simulink, you can:

Configure your model to implement a server operation. You generate AUTOSAR-compliant code and XML description files, including a client-server interface, when you build your model.
Configure a client port for your model using an Invoke AUTOSAR Server Operation block that references a client-server interface. You generate AUTOSAR-compliant code and XML description files for your client port when you build your model.

In addition, if you have a previously created client-server interface, you can generate a Simulink library of configurable, client-server subsystems that reference the:

Invoke AUTOSAR Server Operation block for code generation
Server operation model block for simulation

For information on how to generate this library, see Creating Configurable Subsystems from a Client-Server Interface

You can deploy the client-server subsystem in a Simulink model and, using the Mode Switch for Invoke AUTOSAR Server Operation, run the model in either a simulation or code-generation mode. See Simulating and Generating Code for Client-Server Communication.

For a demo on generating and using an AUTOSAR Client-Server Interface, see rtwdemo_autosar_clientserver_script.

Configuring a Server Operation

In the Configure AUTOSAR Interface dialog box, you can configure your Simulink model as a server operation and then generate AUTOSAR-compliant code and XML files, including the client-server interface.

Select the Configure I/O for server operation check box. The Configure I/O tab becomes the Configure I/O for server operation tab.
Click Get Default Configuration to populate the controls for your model.
The runnable entity names, XML properties, and I/O configuration are initialized. If you click Get Default Configuration again later, only the I/O configurations are reset to default values.
Use the controls in the Configure AUTOSAR Interface pane to change your AUTOSAR code generation options and XML export options.
On the Configure Server Operation tab, specify the following:
- Server port name. Use a valid AUTOSAR short-name identifier.
- Operation prototype . The names of the prototype and its arguments must be valid AUTOSAR short-name identifiers, for example rtwdemo_autosar_server_operation(IN double upper, IN double input, IN double lower, OUT double output).
- Interface name. The path reference of the client-server interface. Use a valid AUTOSAR short-name path, for example, csinterface
- Server type. From the drop-down list, select either Application software or Basic software.
On the Configure Runnables tab, specify the names of your runnable entity, initialization, and periodic functions.
On the XML Options tab, specify the names and package paths of the XML files that you publish when you generate code. For more details about these files, see Exporting a Single Runnable Entity AUTOSAR Software Component.
After you configure your options, click Validate, which calls runValidation. If there are problems, you see messages describing why the configuration is invalid.
If validation succeeds, click OK to return to the Configuration Parameters dialog box.
Save your model.
To generate AUTOSAR-compliant code and XML files, select Tools > Real-Time Workshop > Build Model.

Configuring the Invoke AUTOSAR Server Operation Block

You can use the Invoke AUTOSAR Server Operation block in your Simulink model to configure a client port (that accesses either application software or AUTOSAR Basic Software). You can then build the model to generate AUTOSAR-compliant code and XML files.

Drag an Invoke AUTOSAR Server Operation block into your model.
Double-click the block to open the Invoke AUTOSAR Server Operation dialog box. Specify the following:
- Client port name. A valid AUTOSAR short-name identifier
- Operation prototype. The names of the prototype and its arguments must be valid AUTOSAR short-name identifiers, for example, rtwdemo_autosar_server_operation(IN double upper, IN double input, IN double lower, OUT double output)
- Interface path. The path reference of the client-server interface. You must use a valid AUTOSAR short-name path, for example, /AUTOSAR/Interface.
- Server type. From the drop-down list, select either Application software or Basic software.
- Show error status. Select this check box if you want the client port to receive the error status of client-server communication.
- Sample time. Set this parameter to -1 to inherit the sample time.
Click OK. Your Invoke AUTOSAR Server Operation block is updated.
Replace your client block with the updated Invoke AUTOSAR Server Operation block.
Select Tools > Real-Time Workshop > Build Model. AUTOSAR-compliant code and XML files for the client port are generated.

Creating Configurable Subsystems from a Client-Server Interface

You can generate a Simulink library of configurable subsystems by applying the createOperationAsConfigurableSubsystems method to the arxml.importer object with the client-server interface. For example:

% Create an AUTOSAR importer object
obj = arxml.importer('rtwdemo_autosar_csinterface.arxml');

% Create the client-server operation configurable subsystem library
obj.createOperationAsConfigurableSubsystems('/PortInterface/csinterface', ...
                                            'CreateSimulinkObject', false);

yield the following PortInterface_csinterface library.

Simulating and Generating Code for Client-Server Communication

Use the Template block from the client-server subsystem library to construct a model that can be run in either code-generation or simulation mode.

Drag the Template block from the subsystem library into your model window and connect it to other blocks.
Place the Mode Switch for Invoke AUTOSAR Server Operation in your model window.

To simulate the model:

Double-click the Mode Switch for AUTOSAR Server Operation to change the current mode from code generation to simulation.
Select Simulation > Start.

To generate code for the model:

Double-click the Mode Switch for AUTOSAR Server Operation to change the current mode from simulation to code generation.
Select Tools > Real-Time Workshop > Build Model.

Configuring Calibration Parameters

To import calibration parameters, use the importer method arxml.importer.createCalibrationComponentObjects. This method imports all of your parameters into the MATLAB workspace, and you can then assign them to block parameters in your model.

So that the calibration parameters export correctly when you generate code, check the following configuration parameter settings:

Inline parameters must be selected
Custom Storage Class not ignored must not be selected

After you export your AUTOSAR components, you must include your calibration interface definition XML file to import correctly into an authoring tool.

Modifying and Validating an Existing AUTOSAR Interface

To validate your AUTOSAR interface:

Get the handle to an existing model-specific RTW.AutosarInterface object that is attached to your loaded Simulink model. Enter:
```
obj = RTW.getFunctionSpecification(modelName)
```
modelName is a string specifying the name of a loaded Simulink model, and obj returns a handle to an RTW.AutosarInterface object attached to the specified model.
Test the AUTOSAR interface object. Enter:
```
isa(obj,'RTW.AutosarInterface')
```
This test must return 1. If the model does not have an AUTOSAR interface object, the function returns [].
To view and change items, use the AUTOSAR get and set functions listed in AUTOSAR in the Real-Time Workshop Embedded Coder Function Reference documentation.
Validate the function prototype using RTW.AutosarInterface.runValidation.
If validation succeeds, save your model and then generate code.

Exporting a Single Runnable Entity AUTOSAR Software Component

After configuring your AUTOSAR export options, generate code to export your AUTOSAR component.

Building the subsystem or model generates the code and XML files according to your customizations.

The software component C code and the following XML files are exported to the build directory.

File Name	Description
`modelname_behavior.arxml`	Specifies the software component internal behavior.
`modelname_implementation.arxml`	Specifies the software component implementation.
`modelname_interface.arxml`	Specifies the software component interfaces, including extra interfaces.
`modelname_component.arxml`	Specifies the software component type, including additional ports added to the Simulink model.
`modelname_datatype.arxml`	Specifies the software component data types, including any modified or additional data types.

You can then merge the software component information back into an AUTOSAR authoring tool.

This software component information is partitioned into separate files to facilitate merging. The partitioning attempts to minimize the number of merges you need to do. In general, 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.

For an example of how to generate AUTOSAR-compliant code and export AUTOSAR software component description XML files from a Simulink model, see the AUTOSAR Code Generation demo.

Selecting an AUTOSAR Schema

The default AUTOSAR schema version is 3.0. If you need to change the schema version, you must do so before exporting.

To select a schema version, open the Configuration Parameters dialog box:

In any model using the autosar.tlc system target file, the AUTOSAR Code Generation Options component appears in the tree.
Click AUTOSAR Code Generation Options to open the AUTOSAR Code Generation Options pane.
Select a schema version (3.0, 2.1 or 2.0) for generating XML files.

Tip While you are working in this view, you can also click the Configure AUTOSAR Interface button to open the Configure AUTOSAR Interface dialog box.

Configuring Multiple Runnable Entities

You can use subsystems to model multiple runnable entities explicitly in a single AUTOSAR software component. You can map AUTOSAR runnable entities to function-call subsystems by using the Export Functions feature. If your model contains function-call subsystems, as in the following example, you can use the Export Functions command to specify that you want each subsystem to represent an AUTOSAR runnable entity.

Specify an AUTOSAR interface for each function call subsystem being exported as a runnable entity. Configure the AUTOSAR interfaces for your subsystems by right-clicking the top-level wrapper subsystem and selecting Real-Time Workshop > AUTOSAR Multi-Runnable Component > Configure.

To specify that you want multiple runnable entities generated from your subsystems, right-click the top-level subsystem and select Real-Time Workshop > AUTOSAR Multi-Runnable Component > Export Functions.

This command builds code for an AUTOSAR runnable entity for each subsystem. In the example shown, runnable1 and runnable2 are both runnable entities. The build also creates an additional runnable entity at code generation time to aggregate the initialization functions for each of the function-call subsystems.

Inter-runnable variables communicate data between runnable entities to ensure data integrity. Define these inter-runnable variables by the signal lines connecting subsystems (var1 and var2 in the example). Double-click to edit these signal names before generating code.

In a multi-runnable software component, you may need to use blocks that depend on time, such as the Discrete-Time Integrator block. You can use a timer for each AUTOSAR runnable entity if a block uses time. The timer increments at each execution of the runnable entity. You specify the timer resolution in the AUTOSAR Model Interface dialog box, in the Execution period field. In the Configuration Parameters dialog box, under Optimization, specify the Application life span (days) . The timer data type is based on your specified application life span and execution period.

To see how to configure and generate AUTOSAR-compliant code and export AUTOSAR software component description XML files for a Simulink model with multiple runnables entities, see the AUTOSAR Code Generation for Multiple Runnable Entities demo.

Configuring AUTOSAR Options Programmatically

To control AUTOSAR options programmatically, use the AUTOSAR functions listed in the following tables in the Real-Time Workshop Embedded Coder Function Reference documentation.

Verifying the AUTOSAR Code Using Software-in-the-Loop Testing

A common technique to verify the generated code is to wrap the generated code in an S-function. This technique allows you to verify the generated code in simulation. The AUTOSAR target automatically configures the generated S-function to route simulation data using AUTOSAR run-time environment (RTE) API calls.

Configure your model for software-in-the-loop (SIL) testing by setting these configuration parameters:
```
set_param( modelName, 'GenerateErtSFunction', 'on' );
set_param( modelName, 'GenCodeOnly', 'off' )
```
Generate code to build the SIL block.
Once the SIL block has been built, replace the existing component in your model with the new block.
Simulate the model and check the output to verify that the code produces the same data as the original subsystem.

Limitations and Tips

Cannot Import Internal Behavior

Internal behavior is not parsed. This means any I/O information stored at the runnable level (for example, implicit or explicit) is not imported, and all internal I/O settings default to implicit. You can subsequently configure these I/O ports with the setIODataAccessMode method or in the Configure AUTOSAR Interface dialog box.

Cannot Copy Subsystem Blocks Without Losing Interface Information

If you copy and paste a subsystem block to create a new block in either a new model or the same model, the AUTOSAR interface information stored with the original subsystem block does not copy to the new subsystem block.

Error If No Default Configuration

To avoid build errors, do not clear the Generate code only check box. Configure your model using the Get Default Configuration button or the RTW.AutosarInterface.getDefaultConf method. If you try to build an executable with the AUTOSAR target without supplying your own system target file or generating a software-in-the-loop (SIL) S-function, you see an error.

Server Operation Model with Reusable Function Subsystems

The software does not provide AUTOSAR support for a model that is configured as a server operation and contains subsystems that have the reusable function code generation option selected (see Reusable Function Option and Generating Reusable Code for Subsystems Containing S-Function Blocks).

Cannot Save Importer Objects in MAT-Files

If you try to save an arxml.importer object in a MAT-file, you lose all the information. If you reload the MAT-file, then the object is null (handle = –1), because of the Java™ objects that compose the arxml.importer object.

Using the Merge Block for Inter-Runnable Variables

You can use the Merge block to merge inter-runnable variables. However, you must do the following:

Ensure that the output signal of the Merge block is connected to either one root outport or one or more subsystems.
If the output signal of the Merge block is connected to the inputs of one or more subsystems, assign the same signal name to the Merge block's output and inputs.

Migrating AUTOSAR Development Kit Models

Use the autosar_adk_migrate function to migrate an AUTOSAR Development Kit (ADK) model (from releases before R2008a) to the AUTOSAR interface.

Enter:

autosar_adk_migrate(PATHNAME)

to migrate the ADK model/system specified by the full path name PATHNAME from the ADK settings to the new AUTOSAR interface. The model must be open before you invoke this function. The MathWorks recommends that you save the migrated model to a different file name.

Demos and Further Reading

AUTOSAR Demos

For detailed explanations of AUTOSAR workflows with Real-Time Workshop Embedded Coder software, see the demos in the following table.

Demo	Description
AUTOSAR Code Generation: rtwdemo_autosar_legacy_script	How to generate AUTOSAR-compliant code and export AUTOSAR software component description XML files from a Simulink model
Using an AUTOSAR Client-Server Interface rtwdemo_autosar_clientserver_script	How to configure and generate AUTOSAR-compliant code and export AUTOSAR-compliant XML files for a Simulink model with an AUTOSAR client-server interface
AUTOSAR Code Generation for Multiple Runnable Entities: rtwdemo_autosar_multirunnables_script	How to configure and generate AUTOSAR-compliant code and export AUTOSAR software component description XML files for a Simulink model with multiple runnables entities.
Import and Export an AUTOSAR Software Component: rtwdemo_autosar_roundtrip_script	How to use an AUTOSAR authoring tool with Simulink to develop AUTOSAR software components. Learn how to import software component interfaces into Simulink, modify and export them, and merge the completed software component back into an AUTOSAR authoring tool.

Related Products & Applications

Get Simulink trial software

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.

Get this Simulink Kit