Why does the "arxml.importer" function produce different Simulink data types for ARXML elements with similar ARXML descriptions in MATLAB R2023a?

I'm attempting to create a model from my ARXML file using the "arxml.importer" function. Here's the code I'm using -

importerHandle = arxml.importer('<insert_file_name>.arxml');

componentNames = getComponentNames(importerHandle);

createComponentAsModel(swcImporter, char(componentNames), 'ModelPeriodicRunnablesAs','AtomicSubsystem')

I noticed that some of the imported variables in the workspace have different Simulink data types even though they have very similar descriptions in the ARXML file itself.

Here's an example -

In the ARXML screenshot below, "V1" and "V2" have almost the same descriptions. They only differ in name, UUID and data range values.

This makes it reasonable to assume that they will have the same Simulink Data Type upon being imported.

However, observing the MATLAB screenshot below indicates that "V1" and "V2" have different Simulink data types (former has the Simulink.NumericType while the latter has the Simulink.AliasType).

What is the reason for this behaviour?

Answer 1

[MathWorks Support Team]

The "arxml.importer" function has an inherent optimization feature that's causing this behavior. The function is automatically deciding how many bits will be needed to represent the data range of the ARXML variable. This bit-size ultimately determines what Simulink data type that variable is assigned after importing.

If the bit-size ends up fitting into a standard data type, e.g. uint16, then the "Simulink.AliasType" is assigned. If the bit-size ends up being a non-standard word length, then the "Simulink.NumericType" is assigned.

The ARXML screenshot of "V1" indicates a data range constraint (mentioned under in the "INTERNAL-CONSTRS" attribute) of '0-5000', which only needs 13 bits for complete representation. Since this is a non-standard word length, the "arxml.importer" function assigns it a "fixed-point" data type. This leads to "V1" being interpreted as "Simulink.NumericType" after getting imported.

The ARXML screenshot of "V2" indicates a data range of '0-60000'. Since it takes 16 bits to faithfully represent this range, the "arxml.importer" function defaults to "uint16", which is a standard data type. This leads to "V2" getting assigned "Simulink.AliasType".

Please refer to the following link for additional information of type assignment for ARXML file import:

• AUTOSAR Data Types in Round-Trip Workflow

------------------------------------------------------------

While this optimization step is unavoidable, there are a couple of workarounds for the fixed-point conversion. These are useful in case your application has an issue working with fixed-point types. 

1. Preprocessing of the ARXML file -  Since the "arxml.importer" function performs these optimizations based on the data range of the ARXML variable, you could change the data range to fit into that of a standard data type.
   For example, in the case above, simply changing the data range of V1 from '0-5000' to say '0-60000' would make the "arxml.importer" function assign it a "Simulink.AliasType", as now the data range can be expressed by a standard word length of 16 bits (here, uint16).
2. Modifying the ARXML variable after importing -The "Simulink.NumericType" data type has a field – "DataTypeMode" which indicates the fixed-point nature of the variable. By changing the value of this field to something like "Single" or "Double", Simulink should be able to interpret the variable as standard integer or float without changing the actual value. 

Please refer to the following link for more information:

• Simulink.NumericType

Note: Simulink defines the RPorts and PPorts and establishes connections from inports, outports to corresponding runnables upon importing the ARXML, provided the ARXML properly defines "variable-accesses" for the ports to runnables. To understand how the roundtrip preservation works, they can check this documentation page: https://www.mathworks.com/help/autosar/ug/round-trip-preservation-of-autosar-elements-and-uuids.html