Model AUTOSAR Component Behavior

In Simulink^®, you can model AUTOSAR component behavior, including behavior of runnables, events, and inter-runnable variables.

AUTOSAR Elements for Modeling Component Behavior
Runnables
Inter-Runnable Variables
System Constants
Per-Instance Memory
Static and Constant Memory
Shared and Per-Instance Parameters

AUTOSAR Elements for Modeling Component Behavior

To model AUTOSAR component behavior, you model AUTOSAR elements that describe scheduling and resource sharing aspects of a component. The AUTOSAR elements that bear on component behavior include:

Runnables and the events to which they respond
Inter-runnable variables, used to communicate data between runnables in the same component
System constants, used to specify system-level constant values that are available for reference in component algorithms
Per-instance memory, used to specify instance-specific global memory within a component
Static and constant memory, for access to global data and parameter values within a component
Shared and per-instance memory, for access to component internal parameters.

This topic describes how to model the AUTOSAR elements that help you define component behavior.

Runnables

AUTOSAR software components contain runnables that are directly or indirectly scheduled by the underlying AUTOSAR operating system.

This figure shows an AUTOSAR software component with two runnables, Runnable 1 and Runnable 2. RTEEvents, events generated by the AUTOSAR Runtime Environment (RTE), trigger each runnable. For example, TimingEvent is an RTEEvent that is generated periodically.

A component also can contain a single runnable, represented by a model, and can be single-rate or multirate.

Note

The software generates an additional runnable for the initialization function regardless of the modeling pattern.

For more information, see Configure AUTOSAR Runnables and Events.

Inter-Runnable Variables

In AUTOSAR, inter-runnable variables are used to communicate data between runnables in the same component. You define these variables in a Simulink model by the signal lines that connect subsystems (runnables). For example, in the following figure, irv1, irv2, irv3, and irv4 are inter-runnable variables.

You can specify the names and data access modes of the inter-runnable variables that you export.

System Constants

AUTOSAR system constants (SwSystemConstants) specify system-level constant values that are available for reference in component algorithms. To add AUTOSAR system constants to your model, you can:

Import them from ARXML files.
Create them in Simulink, using AUTOSAR.Parameter objects with Storage class set to SystemConstant.

You can then reference the AUTOSAR system constants in Simulink algorithms. For example, you could reference a system constant in a Gain block, or in a condition formula inside a variant subsystem or model reference.

When you reference an AUTOSAR system constant in your model:

Exported ARXML code contains a corresponding SwSystemConstant and a corresponding AUTOSAR variation point proxy (VariationPointProxy) that references the SwSystemConstant. If you generate modular ARXML files, the SwSystemConstant is located in modelname_datatype.arxml and the VariationPointProxy is located in modelname_component.arxml.
Generated C code uses the generated VariationPointProxy in places where the model uses the SwSystemConstant.

For an example of an AUTOSAR system constant used to represent a conditional value associated with variant condition logic, see Configure Variants for AUTOSAR Runnable Implementations.

Per-Instance Memory

AUTOSAR supports per-instance memory, which allows you to specify instance-specific global memory within a software component. An AUTOSAR run-time environment generator allocates this memory and provides an API through which you access this memory.

Per-instance memory can be AUTOSAR-typed or C-typed. AUTOSAR-typed per-instance memory (arTypedPerInstanceMemory), introduced in AUTOSAR schema version 4.0, is described using AUTOSAR data types rather than C types. When exported in ARXML code, arTypedPerInstanceMemory allows the use of measurement and calibration tools to monitor the global variable corresponding to per-instance memory.

AUTOSAR also allows you to use per-instance memory as a RAM mirror for data in nonvolatile RAM (NVRAM). You can access and use NVRAM in your AUTOSAR application.

To add AUTOSAR per-instance memory to your model, you can:

Import per-instance memory definitions from ARXML files.
Create model content that represents per-instance memory.

To model arTypedPerInstanceMemory, you can use block signals, discrete states, or data stores in your AUTOSAR model:

To use block signals and discrete states, use the Code Mappings editor, Signals/States tab, to select a signal or state and map it to arTypedPerInstanceMemory. The Property Inspector displays code and calibration attributes for the static memory, which you can modify.
To use data stores, use the Code Mappings editor, Data Stores tab, to select a data store and map it to arTypedPerInstanceMemory. The Property Inspector displays code and calibration attributes for the static memory, which you can modify.

For more information, see Configure AUTOSAR Per-Instance Memory.

Static and Constant Memory

AUTOSAR supports static memory (StaticMemory) and constant memory (ConstantMemory) data, introduced in AUTOSAR schema version 4.0. Static memory corresponds to Simulink internal global signals. Constant memory corresponds to Simulink internal global parameters. In Simulink, you can import and export ARXML descriptions of AUTOSAR static and constant memory. When exported in ARXML code, static memory and constant memory allow the use of measurement and calibration tools to monitor the internal memory data.

To model AUTOSAR static memory in Simulink, use the Code Mappings editor, Signals/States or Data Stores tab. Select a signal, state, or data store and map it to StaticMemory. The Property Inspector displays code and calibration attributes for the static memory, which you can modify.

To model AUTOSAR constant memory in Simulink, use the Code Mappings editor, Parameters tab, to select a parameter and map it to ConstantMemory. The Property Inspector displays code and calibration attributes for the constant memory, which you can modify.

For more information, see Configure AUTOSAR Static Memory and Configure AUTOSAR Constant Memory.

Shared and Per-Instance Parameters

AUTOSAR supports shared parameters (SharedParameters) and per-instance parameters (PerInstanceParameters) for use in software components that potentially are instantiated multiple times. Shared parameter values are shared among all instances of a component. Per-instance parameter values are unique and private to each component instance.

In Simulink, you can import and export ARXML descriptions of AUTOSAR shared and per-instance parameters. When exported in ARXML code, shared and per-instance parameters allow the use of measurement and calibration tools to monitor component parameters.

To model an AUTOSAR shared parameter in Simulink, configure a model workspace parameter that is not a model argument (that is, not unique to each instance of a multi-instance model). For example, in the Model Explorer view of the parameter, clear the Argument property. In the Code Mappings editor, Parameters tab, select the parameter and map it to parameter type SharedParameter. The Property Inspector displays code and calibration attributes for the shared parameter, which you can modify.

To model an AUTOSAR per-instance parameter in Simulink, configure a model workspace parameter that is a model argument (that is, unique to each instance of a multi-instance model). For example, in the Model Explorer view of the parameter, select the Argument property. In the Code Mappings editor, Parameters tab, select the parameter and map it to parameter PerInstanceParameter. The Property Inspector displays code and calibration attributes for the per-instance parameter, which you can modify.

Documentation