Main Content

Model AUTOSAR Adaptive Component and Elements in Simulink

AUTOSAR Blockset allows you to create an AUTOSAR adaptive application from a Simulink® model and generate AUTOSAR-compliant C++ code for integration into the AUTOSAR run-time environment. For an AUTOSAR adaptive model you can generate an executable from the code which can be deployed to a POSIX based target machine by using the Embedded Coder® Support Package for Linux® Applications.

You can create an AUTOSAR adaptive software component from a Simulink model in these ways:

Simulink to AUTOSAR Mapping

When you create an AUTOSAR software component from a Simulink model, Simulink converts its model elements to AUTOSAR elements. This table shows the mapping between Simulink modeling elements and their corresponding AUTOSAR elements.

Simulink ElementAUTOSAR Element
Input portServiceRequiredPort and Event
Output portServiceProvidedPort and Event
Port scoped Simulink functionServiceProvidedPort and Method
Port scoped function callerServiceRequiredPort and Method
Data storePersistencyProvidedRequiredPort and DataElement

Create AUTOSAR Adaptive Software Component

Create an AUTOSAR adaptive software component from a Simulink model by performing these tasks.

Configure AUTOSAR Adaptive Platform

You can configure Simulink model to an AUTOSAR Adaptive Platform in two ways.

  • Open the Simulink model and set the System target file to autosar_adaptive.tlc in Code Generation section of the model configuration parameters. Save the model and run the command:

    autosar.api.create(<modelName>,'default');

  • Open the Simulink model and click the AUTOSAR Component Designer app from the Apps tab for the model.

Define Ports and Interfaces

An AUTOSAR component communicates through its ports with other AUTOSAR software components. A port either consumes a service from or provides a service to its communication partners. Each port owned by the component maps to a communication interface, based on functional requirements of the component.

Ports enable software components to communicate with each other. AUTOSAR uses these types of ports.

  • Required port — Used when a software component consumes a service from other entities.

  • Provided port — Used when a software component provides a service to other entities.

  • Persistency provided required port — Used when a software component accesses persistent memory.

To enable event-based communication, AUTOSAR Blockset provides Event Send and Event Receive blocks to convert the event semantics of the AUTOSAR Adaptive runtime to Simulink signal semantics.

  • After each root inport, you can add an Event Receive block, which converts an input event to a signal while preserving the signal values and data type.

  • Before each root outport, you can add an Event Send block, which converts an input signal to an event while preserving the signal values and data type.

To enable persistency storage, Simulink data stores must be mapped to persistency ports.

To configure AUTOSAR communication for an adaptive component, specify the service interfaces that the component will provide or consume. Assign each required and provided port of the component to a specific service interface. Assign each persistency provided required ports of the component to a specific persistency key value interface.

Interface TypeDescription
Service interface

AUTOSAR Adaptive Platform defines service-oriented communication between adaptive software components. The service interface allows you to define interface events, methods, and C++ namespaces.

Persistency key value interfacePersistency offers mechanisms to access persistent memory through Key-Value Storages. The persistency usage of an adaptive application is described in the Execution manifest file.

Adaptive AUTOSAR supports client-server communication between application software components. Methods on an AUTOSAR service interface define the interaction between a software component modeled as a server that provides an interface implementation and a software component modeled as a client that requires an interface. With method-based communication a client application calls a method that is executed on the remote server. For more information, see Model Client-Server Communication.

For more information, see Configure AUTOSAR Adaptive Service Interfaces and Ports and Configure AUTOSAR Adaptive Persistent Memory Interfaces and Ports.

Configure AUTOSAR Elements and Properties

In Simulink, you can use the AUTOSAR Dictionary and the Code Mappings Editor separately or together to graphically configure an AUTOSAR software component and map Simulink model elements to AUTOSAR component elements. For more information, see AUTOSAR Component Configuration.

Using a tree format, the AUTOSAR Dictionary displays a mapped AUTOSAR component and its elements, service interfaces, persistency key value interfaces, and XML options. Use the tree to select AUTOSAR elements and configure their properties. The exported ARXML descriptions and generated AUTOSAR-compliant C++ code reflect the properties that you modify. For more information, see Configure AUTOSAR Adaptive Elements and Properties.

Configure and Generate AUTOSAR Code

You can generate AUTOSAR-compliant C++ code, export ARXML descriptions, manifest files, and a standalone executable from the AUTOSAR adaptive model.

A manifest file is a piece of an AUTOSAR model description that is created to support the configuration of an AUTOSAR adaptive platform, and which is uploaded to the AUTOSAR Adaptive Platform, in combination with other artifacts (such as binary files) that contain executable code to which the manifest file applies.

Manifest files can be categorized into the following ways.

Service Instance manifest fileThe service Instance manifest file is used to specify how service-oriented communication is configured in terms of the requirements of the underlying transport protocols. A service Instance manifest file is created at design time and deployed onto a machine together with the executable.
Execution manifest fileThe execution manifest file is used to provide information that is needed for the actual deployment of an application. An Execution manifest file is created together at design time and deployed onto a machine together with the executable​.
Machine manifest fileMachine manifest file is used to describe deployment related content that applies to the configuration of just the underlying machines (i.e. without any applications running on the machine) that runs an AUTOSAR adaptive application.

AUTOSAR adaptive model also generates an executable which can be deployed to a POSIX based target machine, define the logging behavior, and perform calibration and measurement. You can use Embedded Coder Support Package for Linux Applications to deploy an AUTOSAR adaptive application. For more information, see Build Simulink Model and Deploy Application (Embedded Coder).

You can also configure AUTOSAR code generation to generate the C++ code and ARXML descriptions according to a specific AUTOSAR schema version, specify XML options, AUTOSAR package paths, and modify default AUTOSAR code generation options. For more information about schema version, see Generate XML file for schema version (Embedded Coder).

  • To configure AUTOSAR code generation parameters, in the Simulink model Configuration Parameters dialog, select Code Generation > AUTOSAR Code Generation Options.

  • To configure AUTOSAR XML export options, use the AUTOSAR Dictionary or the autosar.api.getAUTOSARProperties function.

For more information about configuring AUTOSAR Code Generation, see AUTOSAR XML Options Settings, Configure AUTOSAR Adaptive Code Generation, and autosar.api.getAUTOSARProperties.

See Create and Configure AUTOSAR Adaptive Software Component for an example of creating an AUTOSAR adaptive software component and generating C++ code and ARXML descriptions.

See Also

|

Related Examples

More About