Why does function 'createComponentAsModel' create an enum data type that leads to a data type mismatch when building a model using the autosar.tlc target?

It is sought to use function 'arxml.importer' to import some data type definitions from an ARXML-file and then function 'createComponentAsModel' to generate a Simulink model for this AUTOSAR software component. When doing so, then an m-file is generated, that contain all the definitions for the underlying enum-data types and then a Simulink model that models this software component.

When trying to generate code from the latter Simulink model using the autosar.tlc target, then the following error message occurs,

Potential conflicting usages of identifier 'myenumtype1': an enumeration string in
data type 'myenumdatatype1', and an enumeration string in data type
'myenumdatatype2'

Why does function 'createComponentAsModel()' create an enum data type that leads to a data type mismatch when building a model using the autosar.tlc target?

Answer 1

[MathWorks Support Team]

Please note, that the enum-definitions that are generated from the ARXML-file should have either unique names for their enum-types, or one should make sure, that different namespaces are created for the different enum-data types which have enum-types with the same name, so that no conflict is observed.

For the latter workaround, once needs to find the enum-data types in the generated m-file, such as,

 

Simulink.defineIntEnumType( 'myenumdatatype1', ...
   {'myenumtype1','myenumtype2','myenumtype2','myenumtype4'}, [0 1 2 3], ...
   'DefaultValue', 'myenumtype1', ...
   'StorageType', 'uint8', ...
   'HeaderFile', 'myheaderfile.h', ...
   'AddClassNameToEnumNames', false);

replace the property 'AddClassNameToEnumNames' to true for all the conflicting definitions, namely,

 

Simulink.defineIntEnumType( 'myenumdatatype1', ...
   {'myenumtype1','myenumtype2','myenumtype2','myenumtype4'}, [0 1 2 3], ...
   'DefaultValue', 'myenumtype1', ...
   'StorageType', 'uint8', ...
   'HeaderFile', 'myheaderfile.h', ...
   'AddClassNameToEnumNames', true);

and then rerun the m-file with the latter definitions, so that they take effect. Afterwards, it should be possible to generate code from the Simulink model that models the AUTOSAR component without such conflicting issues.

Please use the

Customized Enumerated Types in Generated Code Documentation

 

for more information about the parameter 'AddClassNameToEnumNames'.

Another option is to change the 'EnumMemberNameClash' setting from 'Error' to 'Warning' or 'None' in the model configuration parameters. Since the enumerations are of imported data scope and same storage type and values, this would allow to generate code while maintaining and preserving the imported definitions.

This solution also respects the AUTOSAR rules and constraints being operated under, allowing to integrate the interfaces without modifying the data type definitions. Learn more about the parameter 'EnumMemberNameClash' using the Duplicate Enumeration Member Names Documentation.