Main Content

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 various elements including 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

These data types fall into two categories:

  • Platform 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.

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

Simulink Data TypeAUTOSAR 3.x Platform TypeAUTOSAR 4.x Platform Type
booleanBooleanboolean
singleFloatfloat32
doubleDoublefloat64
int8SInt8sint8
int16SInt16sint16
int32SInt32sint32
int64SInt64sint64
uint8UInt8uint8
uint16UInt16uint16
uint32UInt32uint32
uint64UInt64uint64

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 for the 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 from implementation-level attributes. Examples of application-level physical attributes are real-world ranges of values, data structures, and physical semantics. Examples of implementation-level attributes are stored-integer minimum and maximum values and specifications of AUTOSAR platform types (such as, integer, Boolean, or real).

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

  • For AUTOSAR components originating in Simulink, the software generates AUTOSAR application data types, implementation data types, 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 top-down and round-trip workflows involving AUTOSAR components originating from outside MATLAB®, the ARXML importer and exporter preserves data type and mapping information for each imported AUTOSAR data type within its data type mapping sets.

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 originating 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

In a 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 from referenced models.

Simulink Data TypeAUTOSAR XML
Implementation TypeApplication 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>uint32</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. For more information see, Import AUTOSAR XML Descriptions Into Simulink. Later, you can 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 mappings within the model and uses the application data type name to define the created Simulink data type.

For example, consider the primitive application data type with short name myFixPt in the table below. This is a fixed point data type so a Simulink.NumericType object named myFixPt, matching the short name of the primitive application data type, is generated in Simulink.

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

Upon import, the software derives implicit data type mappings from explicit data type mappings for the AUTOSAR data types present in composite data types. Within the scope of a single software component, any application data type can only be mapped to one implementation data type.

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. Implicit data type mappings that were created by the software will not be present in generated code.

Upon import of AUTOSAR data types, the importer creates the corresponding Simulink data types.

  • Simulink.AliasType objects are created for primitive AUTOSAR data types - except for lookup tables and AUTOSAR data types that do not correspond to a built-in data type (integer, float).

  • Simulink.ValueType objects are created for primitive AUTOSAR data types that correspond to built-in data types. Simulink.ValueType objects are created for AUTOSAR application data types when the UseValueType name-value argument is set to true when AUTOSAR application data types are imported using the createComponentAsModel function.

  • Simulink.NumericType objects are created for AUTOSAR data types representing a fixed point type or an integer type with a non-standard word length. Word length and signedness are inherited from data type constraints and base types.

  • Simulink.Bus objects (structs) are created for composite 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 application data types 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 application data type PhysConstrs in the ARXML files.

  • Simulink data types with unspecified Min and Max correspond to AUTOSAR application data types with full-range constraints. For example:

    • On import, if the PhysConstr values on an application data type match the full lower and upper limits in the InternalConstr for the associated implementation data type, 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 base 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, 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 data type, allowing calibration and measurement tools to monitor and interact with the application data.

Note

Multiple Simulink enumerations cannot refer to the same CompuMethod.

The following table shows the CompuMethod categories that the code generator produces for data types in a model that is configured for AUTOSAR.

Data TypeCompuMethod CategoryCompuMethod on Application Data TypeCompuMethod on Implementation Data Type
BitfieldBITFIELD_TEXTTABLEYesYes
BooleanTEXTTABLEYesYes
Enumerated without storage or with NativeInteger typesTEXTTABLEYesYes
Enumerated with storage typeTEXTTABLEYesNo
Fixed-pointLINEAR
RAT_FUNC (limited to reciprocal scaling)
SCALE_LINEAR_AND_TEXTTABLE		YesNo
Floating-pointIDENTICAL
SCALE_LINEAR_AND_TEXTTABLE		YesNo
IntegerIDENTICAL
SCALE_LINEAR_AND_TEXTTABLE		YesNo

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

  1. The value of the symbol attribute if it exists.

  2. The value VT if it is a valid C identifier.

  3. 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 creating and configuring CompuMethods for code generation, see Create, Import, and Configure AUTOSAR Computation Methods.

Related Examples

More About