Configure AUTOSAR Adaptive Code Generation

R2026b

To generate C++ algorithm code, service implementation code, and AUTOSAR XML (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 customize the generated C++ namespaces for the software component port interfaces in your model.

4. Optionally modify the run-time logging behavior for the adaptive application.

5. Build the model.

Select AUTOSAR Adaptive Schema

For importing and exporting ARXML files and generating C++ code compliant with the AUTOSAR Adaptive Platform, AUTOSAR Blockset supports these AUTOSAR Adaptive Platform schema versions:

• R22-11 (00051)

• R21-11 (00050)

• R20-11 (00049)

When you select the AUTOSAR Adaptive system target file (autosar_adaptive.tlc) for your model for the first time, configuration parameter Generate XML file for schema version (Embedded Coder) defaults to R22-11 (00051).

If you import ARXML files into Simulink^®, the ARXML importer detects and uses the schema version. The importer sets the schema version parameter in the model. For example, if you import ARXML files based on schema version R22-11 (00051), 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 compliant with the configured AUTOSAR schema version. Before exporting your AUTOSAR Adaptive software component, verify the selected schema version by viewing configuration parameter Generate XML file for schema version. If you need to change the selected schema version, set configuration parameter Generate XML file for schema version to the desired schema.

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).

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.

Note

Set the AUTOSAR model configuration parameters to the same values for top and referenced models. This guideline applies to Maximum SHORT-NAME length (Embedded Coder).

Configure XCP Service

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 microprocessor-based systems at run time.

To enable and configure the XCP service for an AUTOSAR adaptive model, use the linux.setXCPServiceConfiguration (Embedded Coder) function. You can configure the TCP port and target computer for the XCP service.

Before using the linux.setXCPServiceConfiguration function, you must:

• Install the Embedded Coder Support Package for Service-Oriented Applications on Linux, see Install Embedded Coder Support Package for Service-Oriented Applications on Linux (Embedded Coder).

• In the Configuration Parameters dialog box, on the Hardware Implementation pane, set Hardware board to Embedded Coder Linux Docker Container.

For example:

linux.setXCPServiceConfiguration("myModel",Enabled=true,TCPPort=12345,Target="LinuxTarget3");

To retrieve the current XCP service configuration for a model, use the linux.getXCPServiceConfiguration (Embedded Coder) function.

[enabled,tcpPort,target] = linux.getXCPServiceConfiguration("myModel");

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

Inspect AUTOSAR Adaptive XML Options

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

Configure Run-Time Logging Behavior

Optionally, modify 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. You can then collate and analyze log data from multiple applications. By default, the application logs event messages to the local console. For more information, see Configure Run-Time Logging for AUTOSAR Adaptive Executables.

Configure run-time logging through the deployment specification in the Property Inspector of the AUTOSAR architecture model. When you build the component model, code generation exports the specified logging properties to the ExecutionManifest.json file.

Generate AUTOSAR Adaptive C++ and ARXML Files

After configuring AUTOSAR code generation and XML options, generate code. To generate C++ code compliant with the AUTOSAR Adaptive Platform and export ARXML descriptions, build the AUTOSAR Adaptive software component model. The build process exports ARXML descriptions to the model build folder. The exported ARXML 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

Note

The ARXML exporter does not create new ARXML files when the Simulink model and AUTOSAR Dictionary have not changed since the last build. AUTOSAR software architecture models regenerate composition ARXML files even if the Simulink model and AUTOSAR Dictionary have not changed since the last build.

These tables list the C++ algorithm and service implementation code and folder structure that the build process generates for each AUTOSAR Adaptive software component model. The software saves the generated files to your current MATLAB^® folder. For more information about the structure of generated files, see Build Process Folder and File Structure and Naming (Embedded Coder).

The modelname folder contains algorithmic and service implementation code and header files that it requires.

Files	Description
modelname.cpp	Contains entry points for the algorithm code.
modelname.h	Declares model data structures and provides a public interface to the algorithm entry points and data structures.
modelname_services.h	Declares access APIs that the algorithm calls and that are defined in the service implementation.

The exe folder contains build and deployment files.

Files	Description
CMakeLists.txt ExecutionManifest.json ServiceInstanceManifest.json	Build configuration and deployment manifests for an executable. The JSON manifests specify execution scheduling and service instance configuration for deployment onto the AUTOSAR adaptive software platform.

The services folder contains the service implementation and main.cpp.

Files	Description
main.cpp	Aggregates entry point scheduling data and calls the scheduler with this information.
modelname_comm.cpp modelname_comm_private.h	Service implementation code that calls into ara::com entities and APIs representing the model's communication elements.
aragen/	Contains generated ara::com proxy and skeleton headers for each port interface. Proxy header files handle receiver-side communication. Skeleton header files handle sender-side communication. The namespace folders reflect the C++ namespaces configured for each port interface.

The shared folder contains a shared data type definition of enumerated data type SlSignalStatus.

Files	Description
SlSignalStatus.h	Defines the SlSignalStatus enumeration data type used by status elements for communication error handling.

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	Default Contents
Single file	modelname.arxml	AUTOSAR elements for adaptive software components, data types, and interfaces.
	modelname_ExecutionManifest.arxml	Deployment-related information for adaptive applications, including executables, process-to-machine mapping sets, and processes.
	modelname_ServiceInstanceManifest.arxml	Configuration of service-oriented communication, including service interface deployments (with event and method deployment details), service instances, service instance to port mappings, and Data Distribution Service (DDS) Quality of Service (QoS) configuration (USER_DATA, Partition QoS, and service versioning).
Modular	modelname_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 C++ implementation data types Constant specifications Physical data constraints Units and unit groups Software record layouts
	modelname_interface.arxml	Adaptive interfaces, including required and provided service interfaces with namespaces and events.
	modelname_ExecutionManifest.arxml	Deployment-related information for adaptive applications, including executables, process-to-machine mapping sets, and processes.
	modelname_ServiceInstanceManifest.arxml	Configuration of service-oriented communication, including service interface deployments (with event and method deployment details), service instances, service instance to port mappings, and DDS QoS configuration.

You can merge the AUTOSAR Adaptive XML component descriptions into an AUTOSAR authoring tool. The AUTOSAR component information is partitioned into separate files to ease merging. The partitioning attempts to minimize the required merges. You do not need to merge the data type file into the authoring tool because the design process defines data types early. You must merge the internal behavior file because this information is part of the model implementation.

To support the round trip of AUTOSAR elements between an AUTOSAR authoring tool (AAT) and the Simulink environment, the code generator preserves AUTOSAR elements and their universally unique identifiers (UUIDs) across ARXML import and export.