Problem with Simulink.NumericType after AUTOSAR-XML (ARXML) import

Hello everyone,

As mentioned in the summary, I have a problem with the Simulink.NumericType after importing my ARXML file into Simulink.

The class is designed so that the import inherits a slope of 0.1 and bias 0. These values are necessary for the data type that defines the output port. Unfortunately, the generated data type is "Fixed-point: slope and bias scaling" and I don't have a license for the Fixed-point Designer Toolbox. Also, I would like to avoid buying it.

So is there any way to bypass the toolbox and import the Simulink.NumericType with the same conditions as floating point.

Thanks for the help

Answer 1

[Andy Bartlett]

To simulate the model with the fixed-point data types and see bit-true behavior will require a Fixed-Point Designer license.

However, there is a feature called Data Type Override that will allow the fixed-point and integer types to be ignored and replaced with floating-point double or single. Data Type Override allows a quick and easy switch to the more luxurious math of doubles or singles. This is helpful for debugging or creating a "golden baseline."

If all the fixed-point types used in the model are overriden to double or to single, then the Fixed-Point Designer license will not be required.

Many blocks in Simulink, including the basic math blocks, are designed to support Data Type Override. But some parts of a model, such as user written s-functions, might not work with data type override or might not accept double or single. In those cases, the Data Type Override approach described here will not work.

To see an example, download the attached files in R2019a or later, and run the following code.

% Select whether to override types
% to floating-point double or single
%
wantDouble = 0;
if wantDouble
    fiOverride = 'TrueDoubles';
    slOverride = 'Double';
else
    fiOverride = 'TrueSingles';
    slOverride = 'Single';
end
% Override any 
% subsequently created fi object to be floating-point
%
fp = fipref;
fp.DataTypeOverride = fiOverride;
%
% Open model
%
mdl = 'fixpt_dt_override_example';
open_system(mdl);
%
% Limit data type override to just integer and fixed-point types
%
set_param(mdl, 'DataTypeOverrideAppliesTo','Fixed-point')
%
% Override all integer and fixed-point data types to 
% floating-point for compatible Simulink blocks
%
set_param(mdl, 'DataTypeOverride', slOverride)
%
% simulate
%
sim(mdl)

% license('inuse')

[Marc Reingruber]

Thank you for the answer.

However, the one solution with the Data type override is not possible because the outport data type has the Data Type Assistant 'Expression'. Here the override information is not given. To specify my problem even more.

Supplement to my question.

To specify it further, it is about mapping a physical quantity linearly to a unsigned integer datatype. Therefore the needed bias and slope values. Apparently the implementation with the NumericType is not solvable without the Fixed-point-Designer Toolbox.

So my next question would be if there is an alternative to the NumericType to achieve the same result for the RTE.

[Andy Bartlett]

Hmm, Data Type Override does work with expressions as shown in the image below.

Fixed-Point Designer allows user to work with real world values in the engineering units of their choice. It also manages all the scaling bookkeeping in modeling, simulation, and code generation.

The alternative to using Fixed-Point Designer is to model directly with Stored Integer values. If users looked at a signal directly modelled as a stored integer with a Display block or Scope they would see the raw stored integer value such 9. To understand the real world value in the engineering units of choice, a user would need to do the necessary multiplications and additons in their head. Any math on the signals, including data type conversion, would need to manually handle at the integer level all the necessary low level operations to account for the specified scaling of all the signals involved.

Working only with Simulink's built-in integers would not require a Fixed-Point Designer license, but would be less productive proportional to how many fixed-point signals and operations were being handled.