Model AUTOSAR Data Types

The AUTOSAR standard defines platform data types for use by AUTOSAR software components. In Simulink^®, you can model AUTOSAR data types used in elements such as data elements, operation arguments, calibration parameters, measurement variables, and inter-runnable variables. If you import an AUTOSAR component from ARXML files, Embedded Coder^® imports AUTOSAR data types and creates the required corresponding Simulink data types. During code generation, Embedded Coder exports ARXML descriptions for data types used in the component model and generates AUTOSAR data types in C code.

About AUTOSAR 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
Measurement variables
Inter-runnable variables

The data types fall into two categories:

Platform (primitive) data types, which allow a direct mapping to C intrinsic types.
Composite data types, which map to C arrays and structures.

To model AUTOSAR platform data types, use corresponding Simulink data types. You can configure the platform type names in the XML Options of the AUTOSAR Dictionary. For more information, see AUTOSAR Platform Types.

Simulink Data Type	AUTOSAR 3.x Platform Type	AUTOSAR 4.x Platform Type
`boolean`	`Boolean`	`boolean`
`single`	`Float`	`float32`
`double`	`Double`	`float64`
`int8`	`SInt8`	`sint8`
`int16`	`SInt16`	`sint16`
`int32`	`SInt32`	`sint32`
`int64`	`SInt64`	`sint64`
`uint8`	`UInt8`	`uint8`
`uint16`	`UInt16`	`uint16`
`uint32`	`UInt32`	`uint32`
`uint64`	`UInt64`	`uint64`

AUTOSAR 3.x platform names will be removed in a future release.

AUTOSAR composite data types are arrays and records, which are represented in Simulink by wide signals and bus objects, respectively. To configure a wide signal or bus object through Inport or Outport blocks, use the Model Data Editor. On the Modeling tab, click Model Data Editor and select the Inports/Outports tab. Select the Design view. From the list of inports and outports, select the source block to configure.

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.

To specify the data types of data elements and arguments of an operation prototype, use the drop-down list in the Data Type column. You can specify a Simulink built-in data type, such as boolean, single, or int8, or enter an (alias) expression for data type. For example, the following figure shows an alias sint8, corresponding to an AUTOSAR data type, in the Data Type column.

For more guidance in specifying the data type, you can use the Data Type Assistant on the Signal Attributes pane of the Inport or Outport Block Parameters dialog box or in the Property Inspector.

Enumerated Data Types

AUTOSAR supports enumerated data types. For the import process, if there is a corresponding Simulink enumerated data type, the software uses the data type. The software checks that the two data types are consistent. However, if a corresponding Simulink data type is not found, 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 quantity 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 Control Field Data Types and Characteristics by Creating Parameter Object. Otherwise, the software displays the following behavior:

When you validate the AUTOSAR configuration, 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 Types

The AUTOSAR standard defines an approach to AUTOSAR data types in which base data types are mapped to implementation data types and application data types. Application and implementation data types separate application-level physical attributes, such as real-world range of values, data structure, and physical semantics, from implementation-level attributes, such as stored-integer minimum and maximum and specification of a primitive type (for example, integer, Boolean, or real).

The software supports AUTOSAR data types in Simulink originated and round-trip workflows:

For AUTOSAR components originated in Simulink, the software generates AUTOSAR application, implementation, and base types to preserve the information contained within Simulink data types.
In the AUTOSAR package structure created for Simulink originated components:
- You can specify separate packages to aggregate elements that relate to data types, including application data types, software base types, data type mapping sets, system constants, and units.
- Implementation data types are aggregated in the main data types package.
For more information, see Configure AUTOSAR Packages.
For round-trip workflows involving AUTOSAR components originated outside MATLAB^®, the ARXML importer and exporter preserve data type information and mapping for each imported AUTOSAR data type.

For information about mapping value constraints between AUTOSAR application data types and Simulink data types, see Application Data Type Physical Constraint Mapping.

For AUTOSAR data types originated in Simulink, you can control some aspects of data type export. For example, you can control when application data types are generated, or specify the AUTOSAR package and short name exported for AUTOSAR data type mapping sets. For more information, see Configure AUTOSAR Data Types Export.

AUTOSAR Data Types in Simulink Originated Workflow
AUTOSAR Data Types in Round-Trip Workflow
Application Data Type Physical Constraint Mapping

AUTOSAR Data Types in Simulink Originated Workflow

In the Simulink originated (bottom-up) 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.
For each Simulink.ValueType object, the software generates an application data type reflecting the properties specified on the Simulink.ValueType object, including dimension, and minimum and maximum values. This application data type is mapped to an implementation data type.

Note

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

Simulink Data Type	AUTOSAR XML
Simulink Data Type	Implementation Type	Application Type
Primitive (excluding fixed point), for example, `myInt16` Covers Boolean, integer, real myInt16 = Simulink.AliasType; myInt16.BaseType = 'int16';	<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</SHORT-NAME> <COMPU-METHOD-REF>…
Enumeration, for example, `myEnum` Simulink.defineIntEnumType('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
Value types, for example, `EngSpeed` EngSpeed = Simulink.ValueType; EngSpeed.Min = 0; EngSpeed.Max = 65535; EngSpeed.DataType = 'uint32';	<IMPLEMENTATION-DATA-TYPE> <SHORT-NAME>EngSpeed</SHORT-NAME> <CATEGORY>VALUE</CATEGORY> …	<APPLICATION-PRIMITIVE-DATA-TYPE> <SHORT-NAME>EngSpeed</SHORT-NAME> <COMPU-METHOD-REF>… <DATA-CONSTR-REF>… …

AUTOSAR Data Types in Round-Trip Workflow

In the round-trip workflow, you first use the XML description generated by an AUTOSAR authoring tool to import an AUTOSAR software component into a model. Later, you generate AUTOSAR C and XML code from the model.

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 that the authoring tool specifies an application data type:

ApplDT1

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

ImplDT1

AUTOSAR XML	Simulink Data Type
<APPLICATION-PRIMITIVE-DATA-TYPE> <SHORT-NAME>myFixPt</SHORT-NAME> <COMPU-METHOD-REF>…	<IMPLEMENTATION-DATA-TYPE> <SHORT-NAME>myInt</SHORT-NAME> …	myFixPt = Simulink.NumericType; myFixPt.DataTypeMode = …; myFixPt.IsAlias = true;

AUTOSAR XML

Simulink Data Type

Application Type

Implementation Type

<APPLICATION-PRIMITIVE-DATA-TYPE>
<SHORT-NAME>myFixPt</SHORT-NAME>
<COMPU-METHOD-REF>…

<IMPLEMENTATION-DATA-TYPE>
<SHORT-NAME>myInt</SHORT-NAME>
…

myFixPt = Simulink.NumericType;
myFixPt.DataTypeMode = …;
myFixPt.IsAlias = true;

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.

Application Data Type Physical Constraint Mapping

In models configured for AUTOSAR, the software maps minimum and maximum values for Simulink data to the corresponding physical constraint values for AUTOSAR application data types.

If you import ARXML files, the software imports PhysConstr values on ApplicationDataTypes in the ARXML files to Min and Max values on the corresponding Simulink data objects and root-level I/O signals.
When you export ARXML files from a model, the software exports the Min and Max values specified on Simulink data objects and root-level I/O signals to the corresponding ApplicationDataType PhysConstrs in the ARXML files.
Simulink data types with unspecified Min and Max correspond to AUTOSAR ApplicationDataTypes with full-range constraints. For example:
- On import, if the PhysConstr values on an ApplicationDataType match the full lower and upper limits in the InternalConstr for the associated ImplementationDataType, the importer sets the Simulink Min and Max values to [ ]. In those cases, Simulink implicitly enforces the default lower and upper limits based on the type.
- On export, if the Simulink Min and Max values for a type are [ ], the software exports default lower and upper limit values for that type (for example, 0 and 1 for a boolean based type) to the ARXML PhysConstr description.

CompuMethod Categories for Data Types

AUTOSAR software components use computation methods (CompuMethods) to convert between the internal values and physical representation of AUTOSAR data. Common uses for CompuMethods are linear data scaling and calibration and measurement.

The category attribute of a CompuMethod represents a specialization of the CompuMethod, which can impose semantic constraints. The CompuMethod categories produced by the code generator include:

BITFIELD_TEXTTABLE — Transform internal value into bitfield textual elements.
IDENTICAL — Floating-point or integer function for which internal and physical values are identical and do not require conversion.
LINEAR — Linear conversion of an internal value; for example, multiply the internal value with a factor, then add an offset.
RAT_FUNC — Rational function; similar to linear conversion, but with conversion restrictions specific to rational functions.
SCALE_LINEAR_AND_TEXTTABLE — Combination of LINEAR and TEXTTABLE scaling specifications.
TEXTTABLE — Transform internal value into textual elements.

The ARXML exporter generates CompuMethods for every primitive application type, allowing calibration and measurement tools to monitor and interact with the application data. The following table shows the CompuMethod categories that the code generator produces for data types in a model that is configured for AUTOSAR.

Data Type	CompuMethod Category	CompuMethod on Application Type	CompuMethod on Implementation Type
Bitfield	`BITFIELD_TEXTTABLE`	Yes	Yes
Boolean	`TEXTTABLE`	Yes	Yes
Enumerated without storage type	`TEXTTABLE`	Yes	Yes
Enumerated with storage type	`TEXTTABLE`	Yes	No
Fixed-point	`LINEAR` `RAT_FUNC` (limited to reciprocal scaling) `SCALE_LINEAR_AND_TEXTABLE`	Yes	No
Floating-point	`IDENTICAL` `SCALE_LINEAR_AND_TEXTABLE`	Yes	No
Integer	`IDENTICAL` `SCALE_LINEAR_AND_TEXTABLE`	Yes	No

For enumerated data types, the ARXML importer tool adheres to the AUTOSAR standard and sets the CompuMethod category TEXTTABLE to the following:

The value of the symbol attribute if it exists.
The value VT if it is a valid C identifier.
The value of the shortLabel.

For floating-point and integer data types that do not require conversion between internal and physical values, the exporter generates a generic CompuMethod with category IDENTICAL and short-name Identcl.

For information about configuring CompuMethods for code generation, see Configure AUTOSAR CompuMethods.