Limitations and Tips

The following limitations apply to AUTOSAR code generation.

Building AUTOSAR Executables

If you do not select the Generate code only check box, the software produces an error message when you build the model. The message states that you can build an executable with the AUTOSAR system target file only if you:

  • Configure the model to create a software-in-the-loop (SIL) or processor-in-the-loop (PIL) block

  • Run the model in SIL or PIL simulation mode

  • Provide a custom template makefile

AUTOSAR Compiler Abstraction Macros (Classic Platform)

The software does not generate AUTOSAR compiler abstraction macros for data or functions arising from the following:

  • Model blocks

  • Stateflow®

  • MATLAB® Coder™

  • Shared utility functions

  • Custom storage classes

  • Local or temporary variables

Preservation of Bus Element Dimensions in Exported ARXML and Code

Bus element dimensions are preserved in the exported ARXML and generated code when a model is configured with the property Array layout set to Row-major. Previously, if a model contained a Simulink.Bus object that contained an element typed with a multidimensional array, the exported ARXML and generated code flattened the bus element to a one-dimensional array. Now, the generated code and exported ARXML preserves the dimensionality as expected, except when the Simulink.Bus object types an outport that is mapped with the ImplicitSendByRef data access mode.

Loop Unrolling Threshold Optimization

AUTOSAR code generation supports optimizations, such as Loop unrolling threshold (Simulink Coder), for improving the performance of the generated code. The circumstances under which these optimizations are implemented in the generated code can vary across releases and targets.

C++11 Style Scoped Enum Classes Generated for AUTOSAR Adaptive Applications

To facilitate easier integration, by default the generated C++ code for AUTOSAR adaptive models emit C++ 11 style scoped enum class data types in the generated code. You can view this data type definition in the header file for enumerations located in the aragen/stub folder of the build folder. This data type definition is standardized and validated prior to code generation.

The following table shows a comparison of a scoped enum class definition versus the previously generated code behavior for a dynamic enumeration:

Simulink.defineIntEnumType('BasicColors', ...
{'Red','Green','Blue'},...
[0;1;2],...
'DataScope','Auto',...
'StorageType','uint8')

Generated Enumeration Definition in Header File

Previous Behavior (C++03)Current Default Behavior (C++11)
#ifndef IMPL_TYPE_BASICCOLORS_H_
#define IMPL_TYPE_BASICCOLORS_H_
#include <cstdint>
  
using BasicColors = uint8_t;
 
const BasicColors Red = 0;
const BasicColors Green = 1;
const BasicColors Blue = 2;
  
#endif   //IMPL_TYPE_BASICCOLORS_H_

#ifndef IMPL_TYPE_BASICCOLORS_H_
#define IMPL_TYPE_BASICCOLORS_H_
#include <cstdint>
  
enum class BasicColors : uint8_t {
    Red = 0, 
    Green = 1,
    Blue = 2
};
  
#endif   //IMPL_TYPE_BASICCOLORS_H_

The default behavior is determined by the default Language standard for a model set to C++11(ISO). If you configure this setting so that a model to generates C++ 03, then the generated code emits the previous code definition behavior and may not compile if used with a third-party ara generator.

AUTOSAR Code Generation Complex Number Support

AUTOSAR code generation supports complex numbers inside software components, but it does not support complex signals at the model interface level. For more information regarding this code generation setting, see Support: complex numbers (Embedded Coder).

Optimization of Unused Root-Level Inport Blocks

Inport blocks that are grounded are considered unused by the software and optimized out during code generation. As a result, these inports are not considered during RTE stub generation which may lead to the data types of these blocks not being described in the generated Rte_Type.h header file.

Inconsistent Code Replacement Behavior

It is possible that code replacement behaves differently than you expect. For example, intermediate data types for a Simulink® block might not match the intermediate data types used by your implementation code even if the input and output data types do match the implementation code.

Additionally, discrepancies can occur due to implementation details of the replacement code, as the implementations might differ from the logic used by Simulink for simulation. This can lead to mismatches between simulation and generated code behavior. Verify code replacements by examining the generated code and check the implementations when potential mismatches occur between simulation and generated code behavior to justify the discrepancies.

For more information regarding the AUTOSAR 4.x code replacement library, see Code Generation with AUTOSAR Code Replacement Library.

Nested AUTOSAR Components

Generating code and ARXML files for AUTOSAR software component models that contain Model blocks that are also mapped as AUTOSAR software components is not supported. To create modeling hierarchies use AUTOSAR compositions or software architectures. For more information, see:

Building AUTOSAR Components and AUTOSAR Software Architectures with ModelReferenceCoderTarget

Building and generating code for AUTOSAR software component models and AUTOSAR software architecture models by using the slbuild function and setting input argument buildSpec to "ModelReferenceCoderTarget" is not recommended and will be removed in a future release.

Verifying AUTOSAR Adaptive Code with SIL and PIL Simulations

SIL and PIL simulations are not supported for models mapped to an AUTOSAR software component configured for the AUTOSAR Adaptive Platform.

For unit-level testing of a Model block that is referenced by an AUTOSAR Adaptive software component, run Model block SIL simulation with Code interface set to Model Reference. In this case, the Model block under test can not reference a model mapped to an AUTOSAR software component.

See Also

Topics