Main Content

Configure AUTOSAR Adaptive Code Generation

To generate AUTOSAR-compliant C++ code and ARXML component descriptions from a model configured for the AUTOSAR Adaptive platform:

  1. In the Configuration Parameters dialog box, on the Code Generation > AUTOSAR Code Generation Options pane, configure AUTOSAR code generation parameters.

  2. Configure AUTOSAR XML export options by using the AUTOSAR Dictionary or AUTOSAR property functions.

  3. Optionally, configure run-time logging behavior for the adaptive application.

  4. Build the model.

Note

CMake version of 3.12 or above is required for AUTOSAR adaptive code generation.

Select AUTOSAR Schema

For import and export of ARXML files and generation of AUTOSAR-compliant C++ code, AUTOSAR Blockset supports the following AUTOSAR Adaptive Platform schema versions:

  • 00048 (R19-11)

  • 00047 (R19-03)

  • 00046 (R18-10)

Selecting the AUTOSAR adaptive system target file for your model for the first time sets the schema version parameter to the default value 00048 (R19-11).

If you import ARXML files into Simulink®, the ARXML importer detects and uses the schema version. It sets the schema version parameter in the model. For example, if you import ARXML files based on schema 00048 (R19-11), the importer sets the matching schema version in the model.

When you build an AUTOSAR adaptive model, the code generator exports ARXML descriptions and generates C++ code that are compliant with the current AUTOSAR schema version value.

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 (Embedded Coder).

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), Transport layer (Embedded Coder), IP address (Embedded Coder), Port (Embedded Coder), Verbose (Embedded Coder), and Use custom XCP Slave (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.

Specify XCP Slave Transport Layer

XCP is a network protocol originating from ASAM for connecting calibration systems to electronic control units. It enables read and write access to variables and memory contents of micro controller systems at runtime. As a two-layer protocol, XCP separates the protocol and transport layers and adheres to a Single-Master/Multi-Slave concept. Transport layer selection does not affect the XCP protocol layer.

Currently, the following transport layers are defined as standard by ASAM:

  • XCP on CAN

  • XCP on Sxl

  • XCP on Ethernet (TCP/IP or UDP/IP)

  • XCP on USB

  • XCP on Flex Ray

To select the transport layer used by the AUTOSAR adaptive application (XCP Slave), use the model configuration parameter Transport layer (Embedded Coder). Selecting an XCP transport layer enables other XCP parameters.

For more information, see Configure AUTOSAR Adaptive Data for Run-Time Measurement and Calibration.

Specify XCP Slave IP Address

Internet Protocol (IP) is the principal communications protocol for relaying datagrams across network boundaries. The Internet Protocol is responsible for addressing host interfaces, encapsulating data into datagrams, and routing datagrams from a source host interface to a destination host interfaces across one or more IP networks.

Each datagram has two components: a header and a payload. The IP header includes source IP address, destination IP address, and other metadata needed to route and deliver the datagram. The payload is the data that it transported.

To specify the IP address of the machine on which the AUTOSAR adaptive application (XCP Slave) executes, use the model configuration parameter IP address (Embedded Coder). The IP address parameter is enabled by selecting a value for Transport layer (Embedded Coder).

For more information, see Configure AUTOSAR Adaptive Data for Run-Time Measurement and Calibration.

Specify XCP Slave Port

A port number is the logical address of each application or process that uses a network or the Internet to communicate. Port number primarily aids in the transmission of data between a network and an application. Port numbers work in collaboration with networking protocols to achieve this.

A port number uniquely identifies a network-based application on a computer. Each application is allocated a 16-bit integer port number. This number is assigned by the operating system, set manually by the user, or set as a default.

To specify the network port on which the AUTOSAR adaptive application (XCP Slave) serves XCP Master commands, use the model configuration parameter Port (Embedded Coder). The Port parameter is enabled by selecting a value for Transport layer (Embedded Coder).

For more information, see Configure AUTOSAR Adaptive Data for Run-Time Measurement and Calibration.

Enable XCP Slave Message Verbosity

Verbosity is the level of technical detail included in software messages. Verbose messages can help in debugging and understanding XCP communication.

To enable verbose messages for the AUTOSAR adaptive application (XCP Slave), select the model configuration parameter Verbose (Embedded Coder). The Verbose parameter is enabled by selecting a value for Transport layer (Embedded Coder).

For more information, see Configure AUTOSAR Adaptive Data for Run-Time Measurement and Calibration.

Use Custom XCP Slave

By default, the MathWorks® XCP Slave is used for communication. You can use a custom XCP Slave for the Ethernet (TCP/IP) transport layer. A custom XCP Slave implementation is required to establish the interface. Define the implementation in header file xcp_slave.h in folder matlabroot/toolbox/coder/autosar/adaptive.

To enable use of a custom XCP Slave, select the model configuration parameter Use custom XCP Slave (Embedded Coder). The Use custom XCP Slave parameter is enabled by selecting a value for Transport layer (Embedded Coder).

For more information, see Configure AUTOSAR Adaptive Data for Run-Time Measurement and Calibration.

Inspect AUTOSAR Adaptive XML Options

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

Configure Run-Time Logging Behavior

Optionally, configure the ara::log based run-time logging behavior for the AUTOSAR adaptive application.

As defined in the AUTOSAR Specification of Diagnostic Log and Trace, adaptive applications can forward event logging information to a console, file, or network. This allows you to collate and analyze log data from multiple applications. By default, the application logs event messages to the local console.

To modify the default run-time logging behavior for an adaptive model, you use AUTOSAR property functions, including set. Code generation exports the specified logging properties to an ARXML execution manifest file. If you build a Linux® executable from the adaptive model, you can generate a JSON execution manifest file that modifies the default logging behavior for the executable. For more information, see Configure Run-Time Logging for AUTOSAR Adaptive Executables.

Generate AUTOSAR Adaptive C++ and XML Files

After configuring AUTOSAR code generation and XML options, generate code. To generate C++ code and export XML descriptions, build the adaptive 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.

  • Manifests for AUTOSAR executables and service instances.

  • If you imported ARXML files into Simulink, updated versions of those 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 ValueExported File NameDefault Contents
Single filemodelname.arxmlAUTOSAR elements for adaptive software components, data types, and interfaces.
modelname_ExecutionManifest.arxmlDeployment-related information for adaptive applications, including executables, process-to-machine mapping sets, and processes.
modelname_ServiceInstanceManifest.arxmlConfiguration of service-oriented communication, including service interface deployments, service instances, and service instance to port mappings.
Modularmodelname_component.arxml

Adaptive software components, including required and provided ports.

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 or interface files based on AUTOSAR element category.

modelname_datatype.arxml

Data types and related elements, including:

  • Application data types

  • Standard Cpp implementation data types

  • Constant specifications

  • Physical data constraints

  • Units and unit groups

  • Software record layouts

modelname_interface.arxmlAdaptive interfaces, including required and provided service interfaces with namespaces and events.
modelname_ExecutionManifest.arxmlDeployment-related information for adaptive applications, including executables, process-to-machine mapping sets, and processes.
modelname_ServiceInstanceManifest.arxmlConfiguration of service-oriented communication, including service interface deployments, service instances, and service instance to port mappings.

You can merge the AUTOSAR adaptive XML component descriptions 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 defined early in the design process. You must 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 Adaptive C++ Code and XML Descriptions.

Customize Class Name and Namespace in Generated Code

If you would like to customize the generated code, you can control the generated C++ class names and namespaces for your AUTOSAR applications either interactively or programmatically.

To interactively configure these aspects of the generated code, from an open model, on the AUTOSAR tab, click Code Interface, select Class Name & Namespace, and customize the names in the opened configuration dialog box. For more information, see Interactively configure class name and namespace (Embedded Coder).

To programmatically configure these aspects of the generated code, use the functions getClassName and setClassName to customize the generated class names and use the functions getClassNamespace and setClassNamespace to control the generated namespaces.

See Also

| | | | | (Embedded Coder) | (Embedded Coder) | (Embedded Coder) | (Embedded Coder) | (Embedded Coder) | (Embedded Coder) | (Embedded Coder)

Related Examples

More About