Import AUTOSAR Data Types and Shared Elements to Simulink

When developing an AUTOSAR software component in Simulink®, you can import AUTOSAR element definitions that are shared by multiple components. Multiple product lines and teams might share elements such as interfaces, data types, constants, and software address methods. Sharing AUTOSAR element definitions across teams lowers risk of definition conflicts and eases code integration.

This topic describes how Simulink treats AUTOSAR data types imported from ARXML files at various points in the import and component creation process. For more information about AUTOSAR data types and how Simulink models them, see Model AUTOSAR Data Types.

Import AUTOSAR Data Types to Simulink

You import ARXML descriptions of software components or compositions generated by an AUTOSAR authoring tool into Simulink by creating an arxml.importer object. Once you have created the arxml.importer object, you can create new models based on the component or composition descriptions by using either createComponentAsModel or importFromARXML. You can also update existing Simulink models with the imported component or composition descriptions by using updateAUTOSARProperties. For information on these creation workflows review these functions and workflow examples.

Functions:

Workflow examples:

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, the ARXML importer uses the implementation data type name to define the Simulink data type.

For example, consider application data type FixPt and its implementation data type:

...
<IMPLEMENTATION-DATA-TYPE UUID="...">
    <SHORT-NAME>FixPt</SHORT-NAME>
    <CATEGORY>VALUE</CATEGORY>
    <SW-DATA-DEF-PROPS>
        <SW-DATA-DEF-PROPS-VARIANTS>
            <SW-DATA-DEF-PROPS-CONDITIONAL>
                <BASE-TYPE-REF DEST="SW-BASE-TYPE">/DataTypes/SwBaseTypes/uint16</BASE-TYPE-REF>
            </SW-DATA-DEF-PROPS-CONDITIONAL>
        </SW-DATA-DEF-PROPS-VARIANTS>
    </SW-DATA-DEF-PROPS>
</IMPLEMENTATION-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>
...
When you create component models based on the imported arxml.importer object, Simulink creates a Simulink.NumericType object FixPt using the short name of the application data type. The Simulink.NumericType object inherits word length and signedness from the mapped implementation data type constraints and software base types.
FixPt = 

  NumericType with properties:

    DataTypeMode: 'Fixed-point: slope and bias scaling'
      Signedness: 'Unsigned'
      WordLength: 16
           Slope: 131072
            Bias: 0
         IsAlias: 1
       DataScope: 'Auto'
      HeaderFile: 'Rte_Type.h'
     Description: ''

Consider application data type EngSpeed and its implementation data type.

...
<IMPLEMENTATION-DATA-TYPE UUID="...">
  <SHORT-NAME>float64</SHORT-NAME>
  <CATEGORY>VALUE</CATEGORY>
  <SW-DATA-DEF-PROPS>
    <SW-DATA-DEF-PROPS-VARIANTS>
      <SW-DATA-DEF-PROPS-CONDITIONAL>
        <BASE-TYPE-REF DEST="SW-BASE-TYPE">/Company/Powertrain/SwBaseTypes/float64</BASE-TYPE-REF>
        <DATA-CONSTR-REF DEST="DATA-CONSTR">/Company/Powertrain/DataTypes/DataConstrs/DC_Double</DATA-CONSTR-REF>
      </SW-DATA-DEF-PROPS-CONDITIONAL>
    </SW-DATA-DEF-PROPS-VARIANTS>
  </SW-DATA-DEF-PROPS>
</IMPLEMENTATION-DATA-TYPE>
...
<APPLICATION-PRIMITIVE-DATA-TYPE UUID="...">
    <SHORT-NAME>EngSpeed</SHORT-NAME>
    <CATEGORY>VALUE</CATEGORY>
    <SW-DATA-DEF-PROPS>
        <SW-DATA-DEF-PROPS-VARIANTS>
            <SW-DATA-DEF-PROPS-CONDITIONAL>
                <SW-CALIBRATION-ACCESS>READ-WRITE</SW-CALIBRATION-ACCESS>
                <COMPU-METHOD-REF DEST="COMPU-METHOD">/Company/Powertrain/CompuMethods/Identcl</COMPU-METHOD-REF>
                <DATA-CONSTR-REF DEST="DATA-CONSTR">/Company/Powertrain/DataConstrs/DC_EngSpeed</DATA-CONSTR-REF>
            </SW-DATA-DEF-PROPS-CONDITIONAL>
        </SW-DATA-DEF-PROPS-VARIANTS>
    </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">/Company/Powertrain/Units/NoUnit</UNIT-REF>
            </PHYS-CONSTRS>
        </DATA-CONSTR-RULE>
    </DATA-CONSTR-RULES>
</DATA-CONSTR>
...
<DATA-TYPE-MAP>
    <APPLICATION-DATA-TYPE-REF DEST="APPLICATION-PRIMITIVE-DATA-TYPE">/Company/Powertrain/ApplDataTypes/EngSpeed</APPLICATION-DATA-TYPE-REF>
    <IMPLEMENTATION-DATA-TYPE-REF DEST="IMPLEMENTATION-DATA-TYPE">/Company/Powertrain/DataTypes/float64</IMPLEMENTATION-DATA-TYPE-REF>
</DATA-TYPE-MAP>
...

When you create a component model based on the imported arxml.importer object, Simulink creates a Simulink.ValueType object EngSpeed using the short name of the application data type. The data constraints for EngSpeed in the ARXML are defined as a maximum value of 200 and minimum value of 0. These minimum and maximum values are preserved as the minimum and maximum values of the created Simulink.ValueType object EngSpeed.

>> EngSpeed

EngSpeed = 

  ValueType with properties:

          DataType: 'double'
               Min: 0
               Max: 200
              Unit: ''
        Complexity: 'real'
        Dimensions: 1
    DimensionsMode: 'Fixed'
       Description: ''

AUTOSAR Data Storage with Data Dictionaries

Simulink data dictionaries are used to store and manage your data. Simulink data dictionaries have an Architectural Data section where you create, manage, and store interfaces, data types, and other element definitions that are used across multiple components and modeling hierarchies.

When you create components or compositions by using createComponentAsModel or importFromARXML, and you specify the DataDictionary name-value argument, data types used by the created model are created in the Architectural Data section of the data dictionary. If you also specify the name-value argument UseBusElementPorts (or UseFunctionPorts when modeling client-server communication) as true, sender-receiver and client-server interfaces used in the model are created in the Architectural Data section of the specified data dictionary.

For more information regarding architectural data, see What Is Architectural Data? and Manage AUTOSAR Architectural Data With Data Dictionaries.

Import AUTOSAR Data Types as Simulink.ValueType Objects in Simulink

You can import AUTOSAR Data Types as Simulink.ValueType objects when you create AUTOSAR software components and compositions based on imported ARXML descriptions by using either createComponentAsModel or importFromARXML and setting UseValueTypes to true. When you enable UseValueTypes, the software creates Simulink.ValueType objects whenever possible for each application data type in the ARXML files. Specifically, Simulink.ValueType objects are created explicitly for imported enumerations, structures, and application data types with linear scaling. Excluding array data types, if the imported application data types and implementation data types have the same name, then Simulink.ValueType objects are not created regardless of the value of UseValueTypes, because Simulink.ValueType objects must have a different name than their assigned data type. When application and implementation data types that represent arrays are imported into Simulink only one Simulink.ValueType object is created that has the same name as the application data type. The data type of the created Simulink.ValueType object is created from the underlying implementation data type.

For example, when you import ARXML descriptions of application data types, by default Simulink creates:

  • Simulink.AliasType objects for application data types, except lookup tables and types that correspond to Simulink built-in data types.

  • Simulink.NumericType objects for application data types representing a fixed-point type or an integer type with a nonstandard word length. The Simulink.NumericType object inherits word length and signedness from the mapped implementation data type constraints and software base types.

  • Simulink.Bus objects for application data types that are interfaces, structures, and other composite data types. In some cases, the software creates enumeration data types.

When you import implementation data types that are AUTOSAR structure types that do not map to an application data type, Simulink creates a Simulink.Bus object. When you import implementation data types with standard word lengths that do not map to an application data type, Simulink creates Simulink.AliasType objects. When you import implementation data types with nonstandard word lengths that do not map to an application data type, Simulink creates Simulink.NumericType objects.

When you export ARXML and generate code for your model, for each Simulink.ValueType object, the software generates an application data type in the exported ARXML file 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. Only implementation data type names are present in the generated code.

Import AUTOSAR Enumeration Data Types to Simulink

When you import AUTOSAR enumeration data types to Simulink, if there is a corresponding enumeration data type built-in to Simulink, then the software creates an instance of that enumeration data type when you create component or composition models. If a corresponding Simulink data type is not found, the software automatically creates an enumeration data type by using the Simulink.defineIntEnumType function. If the enumerated data type name is part of element names in the imported ARXML, then the importer assumes that name-value argument AddClassNamesToEnumNames of Simulink.defineIntEnumType is set to true.

Alternatively, when you use createComponentAsModel or importFromARXML and specify the DataDictionary name-value argument, the enumeration data types are created in the Architectural Data section of the specified dictionary.

Consider the following implementation data type myColors and its computation method.

...
<IMPLEMENTATION-DATA-TYPE UUID="...">
    <SHORT-NAME>myColors</SHORT-NAME>
    <CATEGORY>VALUE</CATEGORY>
    <SW-DATA-DEF-PROPS>
        <SW-DATA-DEF-PROPS-VARIANTS>
            <SW-DATA-DEF-PROPS-CONDITIONAL>
                <BASE-TYPE-REF DEST="SW-BASE-TYPE">/DataTypes/SwBaseTypes/sint32</BASE-TYPE-REF>
                <COMPU-METHOD-REF DEST="COMPU-METHOD">/DataTypes/CompuMethods/COMPU_myColors</COMPU-METHOD-REF>
            </SW-DATA-DEF-PROPS-CONDITIONAL>
        </SW-DATA-DEF-PROPS-VARIANTS>
    </SW-DATA-DEF-PROPS>
</IMPLEMENTATION-DATA-TYPE>
...
<SHORT-NAME>CompuMethods</SHORT-NAME>
<ELEMENTS>
    <COMPU-METHOD UUID="...">
        <SHORT-NAME>COMPU_myColors</SHORT-NAME>
        <CATEGORY>TEXTTABLE</CATEGORY>
        <UNIT-REF DEST="UNIT">/DataTypes/Units/NoUnit</UNIT-REF>
        <COMPU-INTERNAL-TO-PHYS>
            <COMPU-SCALES>
                <COMPU-SCALE>
                    <LOWER-LIMIT INTERVAL-TYPE="CLOSED">1</LOWER-LIMIT>
                    <UPPER-LIMIT INTERVAL-TYPE="CLOSED">1</UPPER-LIMIT>
                    <COMPU-CONST>
                        <VT>Red</VT>
                    </COMPU-CONST>
                </COMPU-SCALE>
                <COMPU-SCALE>
                    <LOWER-LIMIT INTERVAL-TYPE="CLOSED">2</LOWER-LIMIT>
                    <UPPER-LIMIT INTERVAL-TYPE="CLOSED">2</UPPER-LIMIT>
                    <COMPU-CONST>
                        <VT>Green</VT>
                    </COMPU-CONST>
                </COMPU-SCALE>
                <COMPU-SCALE>
                    <LOWER-LIMIT INTERVAL-TYPE="CLOSED">3</LOWER-LIMIT>
                    <UPPER-LIMIT INTERVAL-TYPE="CLOSED">3</UPPER-LIMIT>
                    <COMPU-CONST>
                        <VT>Blue</VT>
                    </COMPU-CONST>
                </COMPU-SCALE>
            </COMPU-SCALES>
        </COMPU-INTERNAL-TO-PHYS>
    </COMPU-METHOD>
</ELEMENTS>
...

When you import an AUTOSAR component that uses data type myColors and then create a Simulink model from the component description, the software creates a corresponding Simulink enumeration data type by using Simulink.defineIntEnumType.

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

Structured Data Types in Simulink

In Simulink, structured data types consist of elements that can have different data types. Use the Architectural Data section of data dictionaries to manage structure data types and their AUTOSAR Classic platform properties as Simulink.dictionary.archdata.StructType objects.

If you are using Simulink.Parameter to manage structured data types, before exporting an AUTOSAR software component, check that each Simulink.Parameter object is typed with a Simulink.Bus data type. For more information on configuring Simulink.Parameter objects, see Control Field Data Types and Characteristics by Creating Parameter Object.

If you are using Simulink.Parameter objects to model structured data types that are not typed with Simulink.Bus objects, then:

  • 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 structure 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 structure, the software sets the data type to struct. However, if the component has data elements that reference this anonymous structured data type, the software generates an error.

Import and Reference Shared AUTOSAR Element Definitions

You can reference these kinds of AUTOSAR element definitions in Simulink:

  • Computation methods, their unit, and dimension

  • Implementation data types and their software base types

  • Application data types

  • System constants, system constant value sets, and predefined variants

  • Software record layouts

  • Software address methods

  • Interfaces, including:

    • Client-server interfaces

    • Sender-receiver interfaces

    • Mode-switch interfaces

    • Non-volatile data interfaces (NvDataInterface)

    • Parameter interfaces

    • Trigger interfaces

For information about importing computation methods in Simulink, see Create, Import, and Configure AUTOSAR Computation Methods.

For each component model that shares a set of definitions, use the arxml.importer function updateAUTOSARProperties to add element definitions to the model. This example shows how to import definitions from ARXML file SwAddrMethods.arxml into example model autosar_swc.

openExample("autosarblockset/ReuseAUTOSARElementsInComponentModelExample");
modelName = "autosar_swc";
open_system(modelName);
ar = arxml.importer("SwAddrMethods.arxml");
updateAUTOSARProperties(ar,modelName);

Optionally, by using name-value arguments, you can specify subsets of elements to import. For more information, see updateAUTOSARProperties. Your model can reference the imported elements in multiple different ways. For example, you can select imported software address method values to group the data for calibration and measurement. For more information, see Import AUTOSAR Package into Component Model.

Generate model code and export ARXML. The exported ARXML files contain references to the imported elements. When iterating on a model where you generate code and re-export ARXML files, the names, file structures, and contents of the ARXML files are preserved, with only the items you edit in the model or model interface added or removed. To view changes present in your ARXML files, inspect the code generation report created by the software. The code generation report highlights changes in the generated code as a result of changes you made to your model. For more information about code generation reports, see Reports for Code Generation (Embedded Coder).

See Also

Objects

Functions

Topics