R2018b

New Features, Compatibility Considerations

AUTOSAR Run-Time Calibration: Map internal signals, states, and model workspace parameters to AUTOSAR component memory and internal parameters for calibration

Map internal signals and states to AUTOSAR per-instance and static memory for calibration

In R2018b, in an AUTOSAR model, you can map internal signals and states to AUTOSAR ArTypedPerInstanceMemory and StaticMemory for run-time calibration. Code Mapping Editor adds Signals and States tabs for mapping individual internal signals and states and configuring their attributes. For more information, see Map Block Signals and States to AUTOSAR Variables (Embedded Coder).

For referenced models within an AUTOSAR component model, Embedded Coder® automatically maps internal signal and states for model reference code generation. Internal signals and states automatically map to AUTOSAR ArTypedPerInstanceMemory for multi-instance model reference, or AUTOSAR StaticMemory for single-instance model reference.

In the AUTOSAR Runtime Environment (RTE), calibration and measurement tools can access ArTypedPerInstanceMemory and StaticMemory generated from internal signals and states in the AUTOSAR top model and referenced models.

Map model workspace parameters to AUTOSAR component internal parameters for calibration

In R2018b, in an AUTOSAR model, you can map model workspace parameters to AUTOSAR component internal SharedParameters and ConstantMemory for run-time calibration. Code Mapping Editor adds a Parameters tab for mapping individual model workspace parameters, including lookup table and breakpoint parameters, and configuring their attributes. For more information, see Map Model Workspace Parameters to AUTOSAR Component Internal Parameters (Embedded Coder).

In the AUTOSAR Runtime Environment (RTE), calibration and measurement tools can access component internal SharedParameters and ConstantMemory generated from model workspace parameters in the AUTOSAR model.

Specify C type qualifiers for AUTOSAR static and constant memory

For an AUTOSAR component, you can configure C type qualifiers to customize generated AUTOSAR-compliant C code for AUTOSAR static memory and AUTOSAR constant memory. For example, you can apply C type qualifiers such as const or volatile to control compiler optimizations.

In R2018b, you can:

AUTOSAR Memory Sections: Use SwAddrMethods to control memory placement of AUTOSAR runnable functions and internal data

AUTOSAR software components use software address methods (SwAddrMethods) to group data and function definitions in memory, primarily for efficiency, performance, and data access by run-time calibration tools. R2018b extends SwAddrMethod support to allow you to control the memory placement of runnable (entry-point) functions and runnable internal data, including signals, states, and parameters. In R2018b, you can:

  • Add, delete, and modify SwAddrMethods in Simulink®.

  • Specify SwAddrMethods for runnable functions.

  • Specify SwAddrMethods for runnable internal data.

When you build the AUTOSAR model, exported arxml descriptions for runnables reflect their SwAddrMethod associations. Generated AUTOSAR-compatible C code groups runnable functions and internal data together into memory sections based on the SwAddrMethod associations you configured.

For more information, see Configure AUTOSAR SwAddrMethods (Embedded Coder), Map Entry-Point Functions to AUTOSAR Runnables (Embedded Coder), and Configure SwAddrMethod (Embedded Coder).

AUTOSAR XML Import and Export: Round trip imported arxml file structure and control packaging of new elements

R2018b improves the round trip of imported AUTOSAR XML file structure and content.

  • When you import arxml files for an AUTOSAR component into Simulink, Embedded Coder preserves the arxml file structure for export.

  • AUTOSAR elements that you create in Simulink export to one or more modelname*.arxml files, which are separate from the imported files. As before, you control the file packaging of new elements by using AUTOSAR Dictionary parameter Exported XML file packaging.

  • In the round-tripped arxml file content, import preserves AUTOSAR element UUIDs. If an imported element does not have a UUID, none is created.

With the improvements, you can more easily compare pre-import and post-export arxml files and track changes. Round-tripped arxml files are clearly differentiated from new arxml files. For example, if you import 20 arxml files into a model, and then use Simulink to define additional AUTOSAR interfaces and data, code generation exports the 20 imported files, along with modelname*.arxml files containing the new AUTOSAR interface and data elements.

For more information, see Round-Trip Preservation of AUTOSAR XML File Structure and Element Information (Embedded Coder).

AUTOSAR XML Import: Changes to ArTypedPerInstanceMemory and StaticMemory import behavior

In R2018b, to support AUTOSAR run-time measurement and calibration, you can map internal signals and states to AUTOSAR component memory and map model workspace parameters to AUTOSAR internal calibration parameters. R2018b enhances the arxml importer to support the new component data mapping, reduce clutter in the base workspace, and provide modeling flexibility.

  • In general, importing AUTOSAR ArTypedPerInstanceMemory, StaticMemory, SharedParameter, or ConstantMemory elements no longer creates data objects in the Simulink base workspace or data dictionary. Scoping data to the AUTOSAR component better encapsulates component data for participation in system-level modeling.

  • In general, importing AUTOSAR ArTypedPerInstanceMemory or StaticMemory elements no longer adds Data Store Memory blocks to the model. The software imports the elements more flexibly, without adding Data Store Memory blocks. You can decide whether to model the imported ArTypedPerInstanceMemory and StaticMemory elements by using signals, states, or data store memory.

  • In one case, an ArTypedPerInstanceMemory element with a Service Dependency, the importer adds a Data Store Memory block and a corresponding AUTOSAR.Signal object to the model.

To use an imported ArTypedPerInstanceMemory or StaticMemory element in your AUTOSAR model, reference the SHORT-NAME of the imported element in the name of a block signal or block state. Then update Simulink-to-AUTOSAR mapping by using the Update button or the AUTOSAR function autosar.api.syncModel. You can use Code Mapping Editor, Signals or States tab, to view and configure the mapping of Simulink internal signals and states to AUTOSAR component memory.

For imported ArTypedPerInstanceMemory and StaticMemory elements, the importer creates Simulink signal objects in the model workspace. The signal objects are not required to model AUTOSAR component memory. You can use the signal objects in your model or remove them. Optionally, you can inspect the signal objects for their design properties, such as data type or min and max values.

Compatibility Considerations

If existing AUTOSAR infrastructure expects the importer to add Data Store Memory blocks for all imported ArTypedPerInstanceMemory and StaticMemory elements, update the infrastructure to reflect the new importer behavior. Alternatively, after the import completes, manually add Data Store Memory blocks and corresponding AUTOSAR.Signal objects to the AUTOSAR model.

Obsolete AUTOSAR signal and state map functions removed

In R2018b, you can individually map Simulink block signals and states to AUTOSAR ArTypedPerInstanceMemory or StaticMemory for AUTOSAR run-time calibration. This replaces an older mechanism in which you set the storage class of named signals and states to Model default to generate ArTypedPerInstanceMemory.

In R2018b, you can no longer access the following autosar.api.getSimulinkMapping functions, which are associated with the older signal and state mapping mechanism. The functions have been removed from MATLAB® help.

getDataDefaultsGet AUTOSAR memory type for Simulink signals or discrete states
mapDataDefaultsMap Simulink signals or discrete states to AUTOSAR memory type

Compatibility Considerations

If an AUTOSAR script relies on the older signal and state map functions getDataDefaults and mapDataDefaults, update the script to use the new signal and state map functions, getSignal, getState, mapSignal, and mapState.

AUTOSAR Code Generation: Automatically generate AUTOSAR platform data types in C code

In R2018b, code generation for AUTOSAR models automatically generates AUTOSAR platform data types. For example, generated AUTOSAR-compliant C code uses AUTOSAR data types sint8, uint8, sint16, uint16, sint32, uint32, float32, and float64​ instead of Simulink code generation data types int8_T, uint8_T, int16_T, uint16_T, int32_T, uint32_T, real32_T, and real64_T.

Automatic AUTOSAR type generation allows you to generate AUTOSAR platform data types for top models, referenced models, and shared utilities without configuring Simulink data type replacement. For more information, see Automatic AUTOSAR Data Type Generation (Embedded Coder).