MATLAB: Do I get an error about evaluating an expression with the MATLAB built-in data type functions like ‘uint8’ when importing ARXML for an AUTOSAR 4.0 software component

Embedded Coder

Why do I get an error about evaluating an expression with the MATLAB built-in data type functions like 'uint8' when importing ARXML for an AUTOSAR 4.0 software component? For example:

Error using autosar.mm.mm2sl.SLModelBuilder.set_param

Expression 'uint8(1)' for block 'myModel/block' returns a

Simulink.AliasType object that has property values that need to be evaluated. This object should be instantiated in a workspace and

referenced by name in Simulink

Best Answer

Simulink imports AUTOSAR data types from the ARXML according to the rules mentioned here:

https://www.mathworks.com/help/ecoder/autosar/data-types.html#btdawtt

If you use an application data type name that matches a Simulink built-in data type (double, single, int8, uint8, int16, uint16, int32, uint32, boolean) the imported Simulink.AliasType now shadows the built-in MATLAB functions that might be used to configure the Simulink model created for the imported AUTOSAR software component. In general, application data type names should abstract away from implementation details such as signedness or size, and typically have physically relevant names like EngSpeed. If you know you want to use a data type that directly maps to a Simulink type (or really any other standard platform type), reference an implementation type/platform type rather than an application type.

Related Solutions

MATLAB: Is the definition for internal data types not generated in “Rte_Type.h” when using AUTOSAR

Root-cause of the issue:

The error in compilation is referring to an internal data type whose definition is not being generated in “Rte_type.h” (we define data types as internal when they are not used on any interfaces with the RTE).
It is not recommended for internal types to have “Rte_type.h” set as header file, because in the generated code, none of the RTE calls need to use the internal types (by definition).
Instead, having them in a header file corresponding locally to the specific SWC would provide a cleaner partition of the code.

The recommended workaround:

I see that you are defining the enumerated data types with Simulink.defineIntEnumType:
Currently, I see that the “HeaderFile” is set to “Rte_type.h”, but no setting for “DataScope” is provided when defining your enum types.
By default, according to the documentation, when having a HeaderFile but not a DataScope property, Simulink is expecting the type to be imported from “Rte_type.h”, and hence the error message.

Depending on your use case, there are two recommended approaches:

1. Top-down workflow:

In this case, you can either:
add a “HeaderFile” property with a header file that you choose, and “DataScope” set to “Exported” (this way this internal type’s definition will be generated in that specific header file), or
simply do no set any values for “HeaderFile” and “DataScope” properties. In this case, the type will be exported to “modelname_types.h”.

As an example of the two options using the enumerated data type that you showed above:

1. Selecting a HeaderFile and DataScope set to “Exported” (data type definition will be generated in “myheaderfile.h”):

Simulink.defineIntEnumType( 'myEnumType', ...
   {'a','b','c'}, ...
   [0 1 2], ...
   'DefaultValue', 'a', ...
   'StorageType', 'uint8', ...
   'HeaderFile', 'myheaderfile.h', ...
   'DataScope', 'Exported', ...
   'AddClassNameToEnumNames', true);

2. Not adding any HeaderFile or DataScope (data type definition by default generated in “modelname_types.h”):

Simulink.defineIntEnumType( 'myEnumType', ...
   {'a','b','c'}, ...
   [0 1 2], ...
   'DefaultValue', 'a', ...
   'StorageType', 'uint8', ...
   'AddClassNameToEnumNames', true);

2. Bottom-up workflow: (from MATLAB R2020b release)

If you are using Simulink as an AUTOSAR authoring tool and would require all data types to be defined in the generated code, you can use this capability from MATLAB R2020b release on.
With this new feature, you can export definitions of internal types, and for your particular use case, you can select the internal types to be exported to "Rte_type.h".
For this, you can choose "Rte_type.h" as HeaderFile, and set the DataScope property to "Exported", as follows:

Simulink.defineIntEnumType( 'myEnumType', ...
   {'a','b','c'}, ...
   [0 1 2], ...
   'DefaultValue', 'a', ...
   'StorageType', 'uint8', ...
   'HeaderFile', 'Rte_type.h', ...
   'DataScope', 'Exported', ...
   'AddClassNameToEnumNames', true);

This would make the definition for "myEnumType" to be generated in "Rte_type.h".

MATLAB: When are Simulink.AliasTypes created in Simulink for Application data types and Implementation data types, and how are they exported upon code generation with AUTOSAR

I understand that you are concerned that having a type represent and ADT or an IDT may influence whether a definition is generated in “Rte_type.h”. Let me clarify that the generation of the definitions in “Rte_type.h” is independent of whether a given type represents an ADT or an IDT.

The type definition will be generated in “Rte_type.h” as long as the type is used in the model, “Rte_type.h” is set as HeaderFile, and the DataScope property is set to “Exported”.

For a top-down workflow in Simulink:

For Application data types imported from ARXML, Simulink.AliasTypes are created in Simulink.
For the case of Implementation types:
If they are referencing a base type, Simulink.AliasTypes will be created in Simulink.
For the specific case of the base type being an Integer type with non-standard word length, they will be represented as Simulink.NumericTypes.
For all other cases, Implementation data types are imported as Simulink.NumericTypes.

Regarding how Simulink.AliasTypes are exported when generating code from Simulink, let me clarify the current behaviour:

Simulink.AliasTypes that have been created upon import from ARXML will preserve their “DataTypeMappingSet”, which can be accessed through the API “<https://www.mathworks.com/help/autosar/ref/autosar.api.getautosarproperties.html autosar.api.getAUTOSARProperties> ”, as follows:

>> arProps = autosar.api.getAUTOSARProperties(modelName);
>> mappingSet = arProps.find('', "DataTypeMappingSet")
>> listADT = find(arProps,[],'ApplicationDataType') % List the ADTs in the model.
>> listIDT = find(arProps,[],'ImplementationDataType') % List the IDTs in the model.

Please be aware that this API will allow you to view the IDTs and ADTs, but it does not allow to modify any of the mappings.
Therefore, for a Simulink.AliasType that has been created on import, and that represents an ADT, Simulink will generate that type as an ADT in the ARXML when following a round-trip workflow. If the imported type represents an IDT, an IDT will be generated.
Simulink.AliasTypes created directly in Simulink (bottom-up workflow) will always be interpreted as IDTs in the generated code. It is currently not possible to select whether a given Simulink.AliasTypes represents an IDT or an ADT.

Best Answer

Related Solutions

MATLAB: Is the definition for internal data types not generated in “Rte_Type.h” when using AUTOSAR

MATLAB: When are Simulink.AliasTypes created in Simulink for Application data types and Implementation data types, and how are they exported upon code generation with AUTOSAR

Related Question