Simulink Modeling Patterns for AUTOSAR

About Simulink Modeling Patterns for AUTOSAR

This section describes how you model AUTOSAR Software Components and related concepts in Simulink.

Back to Top

AUTOSAR Software Components

In AUTOSAR, application software consists of separate units, AUTOSAR Software Components.

Note   An AUTOSAR Software Component is sometimes referred to as atomic because it is never split across more than one Electronic Control Unit (ECU). Do not confuse atomic in this context with the concept of Simulink atomic subsystems.

The behavior of an AUTOSAR Software Component is implemented by a single or multiple runnable entities (runnables), which expose well-defined connection points, ports.

In Simulink, you can represent an AUTOSAR Software Component using a model or a subsystem. For example, the following figure shows modeling patterns for AUTOSAR Software Components (ASWC) labeled ASWC1, ASWC2, ASWC3, and ASWC4.

Runnables

AUTOSAR Software Components contain runnables that are directly or indirectly scheduled by the underlying AUTOSAR operating system.

The following figure shows an AUTOSAR Software Component with two runnables, Runnable 1 and Runnable 2. Each runnable is triggered by RTEEvents, events generated by the AUTOSAR Runtime Environment (RTE). For example, TimingEvent is an RTEEvent that is generated periodically.

The components ASWC1, ASWC2 and ASWC4 contain single runnables. These components are represented by a subsystem or a model, and can be single- or multirate. However, the software implements each component as a single-tasking operation.

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

ASWC2 is modeled as a single-rate, single-tasking atomic subsystem.

You can generate the ASWC2 runnable, which corresponds to the step function of the subsystem. Use the Configure AUTOSAR Interface dialog box to specify the names of the initial and periodic runnables, as shown by the following figure.

The software generates TimingEvents for the runnables. The TimingEvent period for the periodic runnable is the fundamental sample time of the model or atomic subsystem. Specify this sample time in the Subsystem Parameters dialog box, in the Sample time (-1 for inherited) field.

The component ASWC3 contains multiple runnables.

Use the Export Functions feature to map the runnables to Simulink function-call subsystems. See Configure Multiple Runnables and Export AUTOSAR Software Component. The software also generates an initialization runnable for the initialization function.

Use the Configure AUTOSAR Interface dialog box to specify the names of the multiple runnables and the periods of TimingEvents.

Multiple Instantiation

AUTOSAR supports multiple instantiations of software components. However, Simulink supports multiple instantiations (reentrant code) only if a model is configured as a server operation. See Configuring a Server Operation.

To generate reentrant code for a model configured as a server operation, on the Code Generation > Interface pane, select the Generate reusable code check box.

Back to Top

AUTOSAR Communication

AUTOSAR Software Components provide well-defined connection points, ports. There are two types of AUTOSAR ports:

• Require

• Provide

In addition, these AUTOSAR ports can reference two kinds of interfaces:

• Sender-Receiver

• Client-Server

The following figure shows an AUTOSAR Software Component with four ports representing all port and interface combinations.

Sender-Receiver Interface

A Sender-Receiver Interface consists of one or more data elements. Although a Require or Provide port may reference a Sender-Receiver Interface, the AUTOSAR Software Component does not necessarily access all the data elements. For example, consider the following figure.

The AUTOSAR Software Component has a Require and Provide port that references the same Sender-Receiver Interface, interface1. Although this interface contains data elements DE1, DE2, DE3, DE4, and DE5, the component does not utilize all the data elements.

The following figure is an example of how you model, in Simulink, an AUTOSAR Software Component that accesses data elements.

ASWC accesses data elements DE1 and DE2. You model data element access as follows:

• For Require ports, use Simulink inports. For example, RPort1_DE1 and RPort1_DE2.

• For Provide ports, use Simulink outports. For example, PPort1_DE1 and PPort1_DE2.

ErrorStatus is a value that the AUTOSAR Runtime Environment (RTE) returns to indicate errors that the communication system detects for each data element. You can use a Simulink inport to model error status, for example, RPort1_DE1 (ErrorStatus).

Use the Configure AUTOSAR Interface dialog box to specify the AUTOSAR settings for each inport and outport. The following figure shows settings for ASWC.

For example, the Data Access Mode for RPort1_DE1 is set to ImplicitReceive. For information on how you specify settings, see Use the Configure AUTOSAR Interface Dialog Box.

Client-Server Interface

A Client-Server Interface consists of one or more operation prototypes. An operation prototype contains one or more arguments of specific data types. A Client-Server Interface can be referenced by either a Require or Provide port.

The following figure shows an AUTOSAR Software Component with Require ports (RPort2 and NvM ) that reference Client-Server Interfaces (Interface2 and NvM).

Simulink provides the following modeling patterns for Client-Server Interfaces:

• If you want to invoke a Basic Software interface with operations that have only one argument, for example, Client-Server Interface: NvM, use an inport or outport.

• If you want to invoke Basic Software or application software interfaces that contain operations with any number of arguments, for example, Client-Server Interface: Interface2, use the Invoke AUTOSAR Server Operation block. See Configuring the Invoke AUTOSAR Server Operation Block

The following figure shows the use of the Invoke AUTOSAR Server Operation block in modeling an AUTOSAR Software Component in Simulink.

Use the Configure AUTOSAR Interface dialog box to specify the AUTOSAR settings for each inport and outport. See Use the Configure AUTOSAR Interface Dialog Box.

The following figure shows an AUTOSAR Software Component with a Provide port that references a Client-Server Interface.

In Simulink, you can model a single operation of an AUTOSAR Software Component that is referenced by a Client-Server Interface. Consider the following model.

Use the Configure AUTOSAR Interface dialog box to map the inports and outports to the arguments of the operation prototype. For example, the inports map to arguments upper, input, and lower.

For more information, see Configuring a Server Operation .

Back to Top

Calibration Parameters

About Calibration Parameters

A calibration parameter is a value in an Electronic Control Unit (ECU). You tune or modify these parameters using a calibration data management tool or an offline calibration tool.

The AUTOSAR standard specifies the following types of calibration parameters:

• Calibration parameters that belong to a calibration component, which can be accessed by all AUTOSAR Software Components.

  You define calibration components using an AUTOSAR authoring tool.

• Internal calibration parameters, which are defined and accessed by only one AUTOSAR Software Component.

The software supports import, export, and code generation for both types of calibration parameters.

Importing and Exporting Calibration Parameters

You can import calibration parameters into the MATLAB base workspace.

For example, to import parameters from an AUTOSAR calibration component description, use arxml.importer.createCalibrationComponentObjects.

To provide your Simulink model with access to these parameters, assign the imported parameters to block parameters.

For more information, see Import an AUTOSAR Software Component.

You can specify the type of calibration parameter exported by configuring properties of the corresponding block parameter in the base workspace. See Configure Calibration Parameters and rtwdemo_autosar_legacy_script.

Back to Top

Inter-Runnable Variables

In AUTOSAR, inter-runnable variables are used to communicate primitive type 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. See Configuring Inter-Runnable Variables.

Back to Top

Data Types

AUTOSAR specifies data types that apply to:

• Data elements of a Sender-Receiver Interface

• Operation arguments of a Client-Server Interface

• Calibration parameters

• Inter-runnable variables

The data types fall into two categories:

• Primitive data types, which allow a direct mapping to C intrinsic types.

• Composite data types, which map to C arrays and structures.

You can use Simulink data types to define AUTOSAR primitive types.

AUTOSAR composite data types are arrays and records, which are represented in Simulink by wide signals and bus objects, respectively. In the Inport or Outport Block Parameters dialog box, use the Signal Attributes pane to configure wide signals and bus objects.

The following figure shows how to specify a wide signal, which corresponds to an AUTOSAR composite array.

The following figure shows how to specify a bus object, which corresponds to an AUTOSAR composite record.

You can use the Data Type Assistant on the Signal Attributes pane of the Inport or Outport Block Parameters dialog box to specify the data types of data elements and arguments of an operation prototype. If you select Mode to be Built in, then you can specify the data type to be, for example, single or boolean. Alternatively, if you select Mode to be Expression, you can specify an (alias) expression for data type. As an example, the following figure shows an alias UInt4 in the Data type field.

Enumerated Data Types

AUTOSAR supports enumerated data types. For the import process, if there is a corresponding Simulink enumerated data type, then the software uses this data type. The software checks that the two data types are consistent. However, if there is no corresponding Simulink data type, then the software automatically creates the enumerated data type using the Simulink.defineIntEnumType class. This automatic creation of data types is useful when you want to import a large number of enumerated data types.

Consider the following example:

<SHORT-NAME>BasicColors</SHORT-NAME>
  <COMPU-INTERNAL-TO-PHYS>
  <COMPU-SCALES>
     <COMPU-SCALE>
        <LOWER-LIMIT>0</LOWER-LIMIT>
        <UPPER-LIMIT>0</UPPER-LIMIT>
        <COMPU-CONST>
           <VT>Red</VT>
....

The software creates an enumerated data type using:

Simulink.defineIntEnumType( 'BasicColors', ...
     {'Red', 'Green', 'Blue'}, ...
     [0;1;2], ...
     'Description', 'Type definition of BasicColors.', ...
     'HeaderFile', 'Rte_Type.h', ...
     'AddClassNameToEnumNames', false);

Structure Parameters

Before exporting an AUTOSAR Software Component, specify the data types of structure parameters to be Simulink.Bus objects. See Structure Parameters and Generated Code in Simulink Coder documentation. Otherwise, the software displays the following behavior:

• When you validate the AUTOSAR interface, the software issues a warning.

• When you build the model, the software defines each data type to be an anonymous struct and generates a random, nondescriptive name for the data type.

When importing an AUTOSAR Software Component, if a parameter structure has a data type name that corresponds to an anonymous struct, the software sets the data type to struct. However, if the component has data elements that reference this anonymous struct data type, the software generates an error.

Data Type Support for Release 4.0

AUTOSAR R4.0 introduces the notion of application data types, implementation data types and base types. The duality of application and implementation data types allows the separation of the following attributes:

• Physical attributes (application level) — For example, real-world range of values, the data structure, and physical semantics.

• Implementation attributes (implementation level) — For example, stored-integer minimum and maximum values and specification of primitive type such as integer, Boolean, real, and opaque.

For information about how Simulink supports AUTOSAR R4.0 data types, see R4.0 Data Types — Generating Code Without Importing XML and R4.0 Data Types — Importing XML and Generating Code.

For comparison, the following table shows how the software translates AUTOSAR R2.X and R3.X data types to Simulink data types.

R4.0 Data Types — Generating Code Without Importing XML.  In this workflow, you create a Simulink model and export the model as an AUTOSAR Software Component.

The software generates the application and implementation data types and base types to preserve the information contained within the Simulink data types:

• For Simulink data types, the software generates implementation data types.

• For each fixed-point type, in addition to the implementation data type, the software generates an application data type with the COMPU-METHOD-REF element to preserve scale and bias information. This application data type is mapped to the implementation data type.

Note   The software does not support application data types for code generated from referenced models.

Simulink Data Type	AUTOSAR XML
	Implementation Type	Application Type
Primitive (excluding fixed point), for example, myInt16 >> myInt16 = Simulink.AliasType; >> myInt16.BaseType = 'int16'; >> myInt16.IsAlias = 'true' Covers Boolean, integer, real	<IMPLEMENTATION-DATA- TYPE> <SHORT-NAME> myInt16</SHORT-NAME> <CATEGORY>VALUE </CATEGORY> …	Not generated
Primitive (fixed point), for example, myFixPt >> myFixPt = Simulink.NumericType; >> myFixPt.DataTypeMode = … >> myFixPt.IsAlias = 'true';	<IMPLEMENTATION- DATA-TYPE> <SHORT-NAME> myFixPt></SHORT-NAME> <CATEGORY>VALUE </CATEGORY> …	<APPLICATION- PRIMITIVE-DATA-TYPE> <SHORT-NAME> myFixPt … <COMPU-METHOD-REF …
Enumeration, for example, myEnum Simulink.defineIntEnum Type( 'myEnum', ... {'Red', 'Green', 'Blue'}, ... [1;2;3], … );	<IMPLEMENTATION- DATA-TYPE> <SHORT-NAME>myEnum> </SHORT-NAME> <CATEGORY>VALUE <\CATEGORY> <COMPU-METHOD> ...	Not generated
Record, for example, myRecord myRecord = Simulink.Bus;	<IMPLEMENTATION-DATA- TYPE> <SHORT-NAME>myRecord> </SHORT-NAME> <CATEGORY>STRUCT </CATEGORY>	Not generated

R4.0 Data Types — Importing XML and Generating Code.  With this workflow, you first import an AUTOSAR Software Component using the XML description generated by an AUTOSAR authoring tool. Later, you generate AUTOSAR code.

If the data prototype references an application data type, the software stores application to implementation data type mapping within the model and uses the application data type name to define the Simulink data type.

For example, suppose the authoring tool specifies an application data type:

ApplDT1

In this case, the software defines the following Simulink data type:

ImplDT1

If the data prototype references an implementation data type, the software does not store mapping information and uses the implementation data type name to define the Simulink data type.

The software uses the application data types in simulations and the implementation data types for code generation. When you re-export the AUTOSAR Software Component, the software uses the stored information to provide the same mapping between the exported application and implementation data types.

Back to Top

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.

In Simulink, you can model per-instance memory through the use of Data Store Memory and Data Store Read/Write blocks together with an AUTOSAR.Signal data object that specifies, for example, the PerInstanceMemory custom storage class.

AUTOSAR also allows you to use per-instance memory as a RAM mirror for data in non-volatile RAM (NVRAM), which enables you to access and use NVRAM in your AUTOSAR application.

Once an AUTOSAR.Signal data object specifies the PerInstanceMemory custom storage class, you can configure this per-instance memory to be a mirror block for a specific NVRAM block by setting the attribute needsNVRAMAccess to true.

For detailed information about how you model per-instance memory, see the demo rtwdemo_autosar_PIM_script. For an outline, see Use Data Store Memory Blocks to Specify Per-Instance Memory.

Back to Top

AUTOSAR Terminology

Back to Top

Overview of AUTOSAR Support

Workflow for AUTOSAR

Related Products & Applications

• Simulink
• Control Design
• Signal Processing & Communications
• Model-Based Design
• Physical Modeling
• Verification & Validation

Get Simulink trial software

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.

Get this Simulink Kit