Limitations and Tips

R2026b

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 AUTOSAR system target file autosar.tlc only if you:

  • Run the model in SIL or PIL simulation mode

  • Provide a custom template makefile

For models with AUTOSAR system target file autosar_adaptive.tlc, building an AUTOSAR Adaptive executable requires a Linux® environment. On Windows®, you can still generate C++ code, ARXML files, and service implementation code.

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 parameter Array layout set to Row-major. The generated code and exported ARXML preserve the dimensionality as expected, except when the Simulink.Bus object types an outport that is mapped with the ImplicitSendByRef data access mode. (since R2026a)

Before R2026a: 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.

Loop Unrolling Threshold Optimization

AUTOSAR code generation supports optimizations, such as selecting 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 Enumeration Classes Generated for AUTOSAR Adaptive Applications

To facilitate easier integration, the generated C++ code for AUTOSAR adaptive models emits C++11 style scoped enumeration class data types in the generated code, by default. 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 enumeration 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 code generator generates code for a model compliant with the C++03 standard, then the software generates the previous code definition behavior and might not compile if used with a third-party AUTOSAR Runtime for Adaptive Applications (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

The software considers grounded blocks to be unused and optimizes them out during code generation. As a result, these inports are not considered during RTE stub generation, which can lead to the data types of these blocks not being described in the generated Rte_Type.h header file.

Initialize Function Blocks Connected to Root-Level Outputs

In AUTOSAR Adaptive models, connecting outputs of Initialize Function blocks that connect to root-level outputs of the model is not supported.

Inconsistent Code Replacement Behavior

When you generate code using the AUTOSAR 4.x code replacement library it is possible that the behavior implemented in generated code differs from the simulated behavior of the Simulink® model the code was generated for. This discrepancy can happen because certain implementation details of the code replacement library can implement algorithm logic differently than what Simulink used for simulation.

Use software-in-the-loop simulations to identify discrepancies between simulation and generated code, including discrepancies due to code replacements. For more information about verifying generated code, see Verify AUTOSAR Adaptive Software Component Code With SIL. For more information regarding the AUTOSAR 4.x code replacement library, see Code Generation with AUTOSAR Code Replacement Library.

Nested AUTOSAR Components

The software does not support generating code and ARXML files for AUTOSAR software component models that contain Model blocks mapped as AUTOSAR software components. 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 supported.

Testing Protected AUTOSAR Models

You can create protected models from AUTOSAR models with Code interface set to Top Model. For models configured for the AUTOSAR Classic Platform, you can test code generated from your protected model by running software-in-the-loop (SIL) simulations. For more information, see Test Generated Code with SIL and PIL Simulations (Embedded Coder).

Protected models have these limitations in AUTOSAR workflows:

  • Linking a protected model to Classic Component or Adaptive Component blocks in an AUTOSAR software architecture is not supported

  • For protected models created from AUTOSAR Adaptive software component models, the following are not supported:

    • Creating test harnesses

    • Referencing protected models from Model blocks

    • Building standalone AUTOSAR Adaptive executable applications

    • Running SIL or PIL simulations

See Also

Blocks

Model Settings

Topics