Real-Time Workshop® Embedded Coder™

Generating Code That Complies with AUTOSAR Standards

Overview of AUTOSAR Support

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 sections describe these aspects of working with AUTOSAR components:

1. Importing an AUTOSAR Software Component.

2. Configuring for AUTOSAR-compliant code generation. To configure AUTOSAR code generation options and XML export options, you can use the Model Interface dialog box, or configure programmatically.

3. Validating a modified AUTOSAR interface.

4. Exporting an AUTOSAR Software Component. After configuring your AUTOSAR export options, generate code as usual to export your AUTOSAR component. Building the subsystem or model generates the code and XML according to your customizations.

See the following demos for detailed explanations of AUTOSAR workflows with Real-Time Workshop Embedded Coder software:

• rtwdemo_autosar_roundtrip_script demonstrates how to generate and verify AUTOSAR-compliant code and export AUTOSAR software component description XML files.

• rtwdemo_autosar_legacy_script demonstrates how to import, modify, and export AUTOSAR software components.

Back to Top

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 from Vector) and import into a Simulink model for configuration, code generation, and export to XML. See AUTOSAR — Methods of arxml.importer for a full list of methods. Typical uses of functions follow these steps:

1. Call arxml.importer('mySoftwareComponentFile.arxml') to create an importer object and parse the specified "main" XML file looking for atomic software components. Identified atomic software components are reported at the command line. For example:

   importer_obj = arxml.importer('swc.arxml')
   
   importer_obj =
   
   The file "swc.arxml" contains 1 Atomic-Software-Component-Type:
       '/ComponentType/complex_type_component'
   

   You can use SetFile to change the main file and reparse.

   Each software component requires an arxml.importer object. For each arxml.importer object, you need to specify the file that contains the software component of interest.

2. Use the method setDependencies if you need to specify additional dependent XML files containing the information that completes the software component description (e.g., data types, interfaces). You can specify a cell array of files or a single file.

3. Call one of these methods to import a parsed atomic software component into a Simulink model:

   • createComponentAsSubsystem — Creates and configures a Simulink subsystem skeleton corresponding to the specified atomic software component description.

   • 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')

   See also the limitation Cannot Import Internal Runnable 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, you can use the AUTOSAR Model Interface Dialog Box, or configure programmatically (see Configuring AUTOSAR Options Programmatically).

See rtwdemo_autosar_legacy_script, which demonstrates how to import, modify, and export AUTOSAR software components.

Back to Top

Modify and Validate an Existing AUTOSAR Interface

1. Get the handle to an existing model-specific RTW.AutosarInterface object that is attached to your loaded Simulink model with obj = RTW.getFunctionSpecification(modelName), where 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 as follows: isa(obj,'RTW.AutosarInterface'). This test must return 1. If the model does not have an AUTOSAR interface object, the function returns [].

2. Use the AUTOSAR get and set functions listed in the Function Reference to view and change items.

3. Validate the function prototype using runValidation (AUTOSAR).

   Note   See runValidation (AUTOSAR) for information on all validation checks.

4. If validation succeeds, save your model and then generate code.

Back to Top

Exporting an AUTOSAR Software Component

After configuring your AUTOSAR export options programmatically or in the GUI, generate code as usual to export your AUTOSAR component.

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

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

• 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 this 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.

To use the DaVinci AUTOSAR authoring tool, call this function before generating code:

autosar_davinci_configure.m

This function configures your model to use the autosar.tlc system target file and AUTOSAR schema 2.1, and when you generate code, four XML files are exported. The component type and internal behavior XML files are combined into one file for use in DaVinci, called modelname_component.arxml.

Back to Top

AUTOSAR Model Interface Dialog Box

You can use the Model Interface dialog box to configure your AUTOSAR code generation and XML export options.

1. In the Configuration Parameters dialog box, on the Real-Time Workshop — General pane, select the autosar.tlc system target file.

   The AUTOSAR Code Generation Options component appears in the tree.

2. Click AUTOSAR Code Generation Options to open the AUTOSAR Code Generation Options pane. Here you can select a schema version (2.1 or 2.0) for generating XML files.

3. Click the Configure AUTOSAR Interface button to open the Model Interface dialog box. Here you can configure code generation and options for importing to and exporting from XML.

   Alternatively, you can use functions to programmatically control all AUTOSAR options.

   After you specify your changes, you can generate code based on your modifications.

4. Click Get Default Configuration to populate the controls for your model.

   The runnable 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.

5. Use the controls in the Configure AUTOSAR Interface pane to make changes to your AUTOSAR code generation options and XML export options, e.g., send/receive communication options such as port and interface names, data access modes (implicit or explicit), runnable, initialization, and periodic function names. For more information on all these options, see the AUTOSAR functions listed in Function Reference.

   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 alone. 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_'.

   Data Access Mode can be Implicit, where data is buffered by the run-time environment (RTE), or Explicit where data is not buffered and hence not deterministic.

6. After you have configured your options, click Validate. This calls runValidation (AUTOSAR). If there are problems, you see messages explaining why the configuration is invalid.

   Note   See runValidation (AUTOSAR) for information on all validation checks.

7. If validation succeeds, click OK to return to the Configuration Parameters dialog box.

8. Save your model and then generate code as usual to export your AUTOSAR component.

Back to Top

Configuring AUTOSAR Options Programmatically

To programmatically control AUTOSAR options, you can use the AUTOSAR functions listed in the following tables in the Real-Time Workshop Embedded Coder Reference:

• AUTOSAR — Methods of RTW.AutosarInterface

• AUTOSAR — Methods of arxml.importer

Back to Top

Limitations and Tips

Cannot Import Internal Runnable Behavior

Input/Output configuration (e.g., implicit or explicit) is imported at component level only. Internal runnable behavior is not parsed. This means any I/O information stored at the runnable level (e.g., 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 method setIODataAccessMode) or the AUTOSAR Model Interface dialog box.

Cannot Copy Subsystem Blocks Without Losing Interface Information

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

Error If No Default Configuration

To avoid build errors, do not clear the Generate code only check box, and you must configure your model with the Get Default Configuration button or the method getDefaultConf (AUTOSAR). 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. You cannot do this as you will get compiler warnings.

Cannot Save Importer Objects in MAT-Files

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

Back to Top

Migrating AUTOSAR Development Kit Models

Use the function autosar_adk_migrate 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 and it is advisable to save the migrated model to a different file name.

Back to Top

Developing Models and Code That Comply with MISRA C® Guidelines

Developing Models and Code That Comply with the IEC 61508 Standard