Main Content

Model AUTOSAR Data Types

AUTOSAR data types provide consistent and reliable data exchange in automotive software models. In Simulink®, you can model AUTOSAR data types used in various elements of a component, composition, and architecture. When you import AUTOSAR components from ARXML files into Simulink, the AUTOSAR data type descriptions are used to create 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.

Simulink supports AUTOSAR platform types defined by the AUTOSAR standard for Release 4.0 through Release R23-11.

About AUTOSAR Data Types

AUTOSAR data types apply to these AUTOSAR elements of a component or composition:

  • Data elements of a sender-receiver interface

  • Operation arguments of a client-server interface

  • Calibration parameters

  • Measurement variables

  • Inter-runnable variables

AUTOSAR data types include:

  • Application data types — Application-level physical attributes of an AUTOSAR software component or composition, such as real-world ranges of values, units, and physical semantics.

  • Implementation data types — Implementation-level attributes of an AUTOSAR software component or composition, such as stored-integer minimum and maximum values, and specifications of underlying AUTOSAR platform types.

  • Software base types — Fundamental data types that are referenced by implementation data types.

  • Platform data types — Implementation data types defined by the AUTOSAR standard that allow a direct mapping to C intrinsic types.

  • Composite data types — Arrays and records, which are represented in Simulink by wide signals and bus objects, respectively.

In most ARXML descriptions, application data types have software data definition properties that include physical data constraints and computation methods that include units. Implementation data types also have software data definition properties, but they include internal data constraints and references to software base types.

In general, there are two categories of implementation data types: TYPE-REFERENCE and VALUE. Implementation data types that are tagged by category VALUE are self-contained and fully defined by their software base type and data constraint definitions. Implementation data types that are tagged by category TYPE-REFERENCE reference another implementation data type tagged by category VALUE and depend on the definition of the referenced implementation data type.

Application data types are mapped to implementation data types, and implementation data types can directly relate to their software base type. In the image below, application data type EngSpd is mapped to implementation data type uint8_max_200 which is based on software base type uint8 and has a maximum value of 200, which is an internal constraint of the system that uses this data type.

Application data type EngSpd references implementation data type uint8_max_200 which is based on software base data type uint8.

In Simulink, data type mappings can be implicit or explicit. Explicit data type mappings are mappings you define and have an explicit representation in ARXML. Within the scope of a single AUTOSAR software component, each application data type must be explicitly mapped to only one implementation data type. In ARXML, data type mappings are stored as data type mapping sets. When you import ARXML files, the ARXML importer preserves data type and mapping information for each imported AUTOSAR data type within its data type mapping set.

Implicit data type mappings are the implied relationship, assumed by Simulink, between elements of complex data types such as structures and arrays. For example, if a Simulink.ValueType object is typed by a Simulink.AliasType object of type uint8, then in the exported ARXML, the exporter assumes a data type mapping between the application data type representing the Simulink.ValueType object and the implementation data type that defines uint8.

To model AUTOSAR platform data types, use the corresponding Simulink data types. For more information, see AUTOSAR Platform Types. This table lists the Simulink data type with its corresponding AUTOSAR 4.x platform data type.

Note

Simulink supports only the import and export of AUTOSAR platform types for AUTOSAR schema versions released in or after AUTOSAR 4.0, referred to as AUTOSAR 4.x platform data types in Simulink.

Simulink Data TypeAUTOSAR 4.x Platform Data Types
booleanboolean
singlefloat32
doublefloat64
int8sint8
int16sint16
int32sint32
int64sint64
uint8uint8
uint16uint16
uint32uint32
uint64uint64

When you import ARXML files, Simulink creates Simulink data types that have the same name as application data types in the ARXML. If the imported ARXML files contain an implementation data type that references only another implementation data type and is not referenced by an application data type, then the ARXML importer uses the implementation data type name to define the Simulink data type. For more information about importing AUTOSAR data types to Simulink, see Import AUTOSAR Data Types and Shared Elements to Simulink.

Modeling Data Types in Simulink for ARXML Export

You can configure a Simulink model to be an AUTOSAR software component without importing ARXML files by using the AUTOSAR Component Designer app. When you generate code and export ARXML for your model, the exporter identifies data types and exports them as application data types or implementation data types in the exported ARXML files. If the exporter determines application data types are not needed to define a data type, the exporter generates only implementation data types. For most Simulink data types the exporter generates only implementation data types, except:

  • For fixed-point data types, in addition to the implementation data type, the exporter 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 exporter 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.

If you need AUTOSAR elements to refer only to application data types in the exported ARXML, set XML option ImplementationDataType Reference to NotAllowed to enable Simulink to automatically generate application data types and the relevant mappings to implementation data types. If you allow implementation data type references (ImplementationDataType Reference set to Allowed), you allow data prototypes of interfaces to directly reference implementation data types in your exported ARXML, where possible. Changing XML option ImplementationDataType Reference to NotAllowed might create application data types and data type mappings that are not automatically removed by changing the XML option back to Allowed.

For more information about configuring Simulink data types for export, see Configure AUTOSAR Data Types Export.

To clarify how specific Simulink data type definitions are represented in AUTOSAR ARXML, these examples present common data types used in Simulink models configured for the AUTOSAR Classic Platform and their corresponding exported ARXML. Each example focuses on a different data type and highlights the generated application data types and implementation data types in the exported ARXML.

  • For built-in Simulink data types (excluding fixed-point data types) the software only generates implementation data types and no application data types. For example, consider Simulink data type, myInt16.

    myInt16 = Simulink.AliasType;
    myInt16.BaseType = "int16";
    If you export ARXML from a Simulink model configured for the AUTOSAR Classic Platform that uses this data type, then the exported ARXML contains the following implementation data type and no application data type.
    ...
    <IMPLEMENTATION-DATA-TYPE UUID="...">
        <SHORT-NAME>myInt16</SHORT-NAME>
        <CATEGORY>VALUE</CATEGORY>
        <SW-DATA-DEF-PROPS>
            ...
            <BASE-TYPE-REF DEST="SW-BASE-TYPE">/DataTypes/SwBaseTypes/sint16</BASE-TYPE-REF>
            ...
        </SW-DATA-DEF-PROPS>
    </IMPLEMENTATION-DATA-TYPE>
    ...

  • For fixed-point data types both an implementation and application data type are generated by the software. For example, consider fixed-point data type FixPt.

    FixPt = fixdt(0,16,-17);
    FixPt.IsAlias = true;
    If you export ARXML from a Simulink model configured for the AUTOSAR Classic Platform that uses data type FixPt, then the exported ARXML contains the following implementation data type and application data type. The implementation data type has the same name as the Simulink data type, FixPt, and references software base type uint16.
    ...
    <IMPLEMENTATION-DATA-TYPE UUID="...">
        <SHORT-NAME>FixPt</SHORT-NAME>
        <CATEGORY>VALUE</CATEGORY>
        <SW-DATA-DEF-PROPS>
            ...
            <BASE-TYPE-REF DEST="SW-BASE-TYPE">/DataTypes/SwBaseTypes/uint16</BASE-TYPE-REF>
            ...
        </SW-DATA-DEF-PROPS>
    </IMPLEMENTATION-DATA-TYPE>
    ...
    The application data type also has the same name as the Simulink data type, FixPt. The application data type contains the data constraints that define the upper and lower limits of the fixed-point data type, and references a defined computation method that has the same units of the fixed-point data type.
    ...
    <APPLICATION-PRIMITIVE-DATA-TYPE UUID="...">
        <SHORT-NAME>FixPt</SHORT-NAME>
        <CATEGORY>VALUE</CATEGORY>
        <SW-DATA-DEF-PROPS>
            ...
            <SW-CALIBRATION-ACCESS>READ-WRITE</SW-CALIBRATION-ACCESS>
            <COMPU-METHOD-REF DEST="COMPU-METHOD">/DataTypes/CompuMethods/COMPU_FixPt</COMPU-METHOD-REF>
            <DATA-CONSTR-REF DEST="DATA-CONSTR">/DataTypes/ApplDataTypes/DataConstrs/DC_FixPt</DATA-CONSTR-REF>
            ...
        </SW-DATA-DEF-PROPS>
    </APPLICATION-PRIMITIVE-DATA-TYPE>
    ...
    </COMPU-METHOD>
    <COMPU-METHOD UUID="...">
        <SHORT-NAME>COMPU_FixPt</SHORT-NAME>
        <CATEGORY>LINEAR</CATEGORY>
        <UNIT-REF DEST="UNIT">/DataTypes/Units/NoUnit</UNIT-REF>
        <COMPU-INTERNAL-TO-PHYS>
            <COMPU-SCALES>
                <COMPU-SCALE>
                    <COMPU-RATIONAL-COEFFS>
                        <COMPU-NUMERATOR>
                            <V>0</V>
                            <V>131072</V>
                        </COMPU-NUMERATOR>
                        <COMPU-DENOMINATOR>
                            <V>1</V>
                        </COMPU-DENOMINATOR>
                    </COMPU-RATIONAL-COEFFS>
                </COMPU-SCALE>
            </COMPU-SCALES>
        </COMPU-INTERNAL-TO-PHYS>
    </COMPU-METHOD>
    ...
    </DATA-CONSTR>
    <DATA-CONSTR UUID="...">
        <SHORT-NAME>DC_FixPt</SHORT-NAME>
        <DATA-CONSTR-RULES>
            <DATA-CONSTR-RULE>
                <PHYS-CONSTRS>
                    <LOWER-LIMIT INTERVAL-TYPE="CLOSED">0</LOWER-LIMIT>
                    <UPPER-LIMIT INTERVAL-TYPE="CLOSED">8589803520</UPPER-LIMIT>
                    <UNIT-REF DEST="UNIT">/DataTypes/Units/NoUnit</UNIT-REF>
                </PHYS-CONSTRS>
            </DATA-CONSTR-RULE>
        </DATA-CONSTR-RULES>
    </DATA-CONSTR>
    ...

  • For Simulink.Bus objects, only an implementation data type is generated by the software. For example, consider Simulink.Bus object myRecord:

    myRecord = Simulink.Bus;
    If you export ARXML from a model configured for the AUTOSAR Classic Platform that uses this data type, the exported ARXML contains an implementation data type with the same name as the Simulink data type. The implementation data type is tagged by category STRUCTURE with SUB-ELEMENTS that are the same as the elements of the exported bus, in this case Simulink.Bus object myRecord has only one element typed by data type float64.
    ...
    <IMPLEMENTATION-DATA-TYPE UUID="...">
        <SHORT-NAME>myRecord</SHORT-NAME>
        <CATEGORY>STRUCTURE</CATEGORY>
        <SUB-ELEMENTS>
            <IMPLEMENTATION-DATA-TYPE-ELEMENT UUID="...">
                <SHORT-NAME>Element</SHORT-NAME>
                <CATEGORY>TYPE_REFERENCE</CATEGORY>
                <SW-DATA-DEF-PROPS>
                   ...
                   <IMPLEMENTATION-DATA-TYPE-REF DEST="IMPLEMENTATION-DATA-TYPE">/DataTypes/float64</IMPLEMENTATION-DATA-TYPE-REF>
                   ...
                </SW-DATA-DEF-PROPS>
            </IMPLEMENTATION-DATA-TYPE-ELEMENT>
        </SUB-ELEMENTS>
    </IMPLEMENTATION-DATA-TYPE>
    ...

    Note

    Application data types may be generated for Simulink.Bus objects in the exported ARXML when elements of that Simulink.Bus object are typed by data types that require application data types to be fully defined in the exported ARXML, like fixed-point data types.

  • For Simulink.ValueType objects both an implementation data type and application data type are generated by the software. Where the application data type references the physical constraints of the data type, represented in Simulink as the minimum and maximum values of the Simulink data type. For example consider Simulink.ValueType object EngSpeed.

    EngSpeed = Simulink.ValueType;
    EngSpeed.Min = 0;
    EngSpeed.Max = 200;
    EngSpeed.DataType = "uint32";
    
    If you export ARXML from a model configured for the AUTOSAR Classic Platform that uses this data type, the exported ARXML contains an implementation data type whose name is that of the data type EngSpeed: uint32.
    ...
    <IMPLEMENTATION-DATA-TYPE UUID="...">
        <SHORT-NAME>uint32</SHORT-NAME>
        <CATEGORY>VALUE</CATEGORY>
        <SW-DATA-DEF-PROPS>
            ...
            <BASE-TYPE-REF DEST="SW-BASE-TYPE">/DataTypes/SwBaseTypes/uint32</BASE-TYPE-REF>
            ...
        </SW-DATA-DEF-PROPS>
    </IMPLEMENTATION-DATA-TYPE>
    ...
    The application data type has the same name as that of the Simulink.ValueType data type, and contains data constraints that define the minimum and maximum values of the type.
    ...
    </APPLICATION-PRIMITIVE-DATA-TYPE>
    <APPLICATION-PRIMITIVE-DATA-TYPE UUID="...">
        <SHORT-NAME>EngSpeed</SHORT-NAME>
        <CATEGORY>VALUE</CATEGORY>
        <SW-DATA-DEF-PROPS>
            ...
            <SW-CALIBRATION-ACCESS>READ-WRITE</SW-CALIBRATION-ACCESS>
            <COMPU-METHOD-REF DEST="COMPU-METHOD">/DataTypes/CompuMethods/Identcl</COMPU-METHOD-REF>
            <DATA-CONSTR-REF DEST="DATA-CONSTR">/DataTypes/ApplDataTypes/DataConstrs/DC_EngSpeed</DATA-CONSTR-REF>
            ...
        </SW-DATA-DEF-PROPS>
    </APPLICATION-PRIMITIVE-DATA-TYPE>
    ...
    <DATA-CONSTR UUID="...">
        <SHORT-NAME>DC_EngSpeed</SHORT-NAME>
        <DATA-CONSTR-RULES>
            <DATA-CONSTR-RULE>
                <PHYS-CONSTRS>
                    <LOWER-LIMIT INTERVAL-TYPE="CLOSED">0</LOWER-LIMIT>
                    <UPPER-LIMIT INTERVAL-TYPE="CLOSED">200</UPPER-LIMIT>
                    <UNIT-REF DEST="UNIT">/DataTypes/Units/NoUnit</UNIT-REF>
                </PHYS-CONSTRS>
            </DATA-CONSTR-RULE>
        </DATA-CONSTR-RULES>
    </DATA-CONSTR>
    ...

Computation Method (COMPU-METHOD) Categories for Data Types

AUTOSAR software components use computation methods to convert their AUTOSAR-specific data between internal values and their physical representations. For example, when sending data to an ECU from an AUTOSAR software component the internal data values need to be converted to relevant physical values that the ECU understands. Other common uses for computation methods are linear data scaling and enumeration. AUTOSAR components use data constraint mappings to specify any physical constraints and internal constraints of application and implementation data types, respectively. For more information about constraints and ARXML export, see Configure AUTOSAR Internal Data Constraints for Export.

Computation methods have a defined CATEGORY attribute in ARXML. The category of a computation method defines the specialization of that computation method, which can impose semantic constraints on data it computes. The computation method categories supported by Embedded Coder include:

  • BITFIELD_TEXTTABLE — Transformation of internal values into bitfield textual elements as a concatenated value set

  • 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, such as multiplying the internal value with a factor, then adding 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 — Transformation of an internal value to a singular textual element

The ARXML exporter generates computation method categories 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 computation method.

This table shows the computation method categories that Embedded Coder produces for AUTOSAR platform data types, and if those categories are supported for application and implementation data types.

COMPU-METHOD CategoryData TypeCOMPU-METHOD on Application Data TypeCOMPU-METHOD on Implementation Data Type
BITFIELD_TEXTTABLEBitfieldYesYes
TEXTTABLEBooleanYesYes
TEXTTABLEEnumerated without storage or with NativeInteger typesYesYes
TEXTTABLEEnumerated with storage typeYesNo
LINEAR
RAT_FUNC (limited to reciprocal scaling)
SCALE_LINEAR_AND_TEXTTABLE
Fixed-pointYesNo
IDENTICAL
SCALE_LINEAR_AND_TEXTTABLE
Floating-pointYesNo
IDENTICAL
SCALE_LINEAR_AND_TEXTTABLE
IntegerYesNo

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

  • The value of the symbol attribute, if it exists

  • The value VT if it is a valid C identifier

  • The value of the shortLabel attribute

For floating-point and integer data types that do not require conversion between internal and physical values and thus do not require a specialized computation method, the exporter automatically generates a generic computation method with category IDENTICAL and short-name Identcl in the generated code.

For more information about creating and configuring computation methods for code generation, see Create, Import, and Configure AUTOSAR Computation Methods.

See Also

Objects

Functions

Topics