R2015b

New Features

AUTOSAR 4.1.3 and 4.2: Import and export ARXML and generate code for latest AUTOSAR standard

R2015b extends AUTOSAR schema support to schema 4.2 (revision 4.2.1) and schema 4.1 (revision 4.1.3). For a detailed list of AUTOSAR schemas supported for import and export of arxml files and generation of AUTOSAR-compatible C code, see Select an AUTOSAR Schema.

R2015b provides many other enhancements to Simulink® modeling of AUTOSAR elements and AUTOSAR code generation. For more information, see:

AUTOSAR sender-receiver modeling

R2015b enhances AUTOSAR sender-receiver modeling with support for:

  • IsUpdated API for receiver ports

  • Data element invalidation policies on sender ports

  • End-to-end protection for sender and receiver ports

  • DataReceiveErrorEvent for receiver ports

  • Rte_IWriteRef for sender ports

IsUpdated API for receiver ports

AUTOSAR defines quality of service attributes, such as ErrorStatus and IsUpdated, for sender-receiver interfaces. R2015b adds support for the AUTOSAR IsUpdated attribute and API. The IsUpdated attribute allows an AUTOSAR receiver to detect when a receiver port data element has received data since the last read occurred. When data is idle, the receiver can save computational resources. You can:

  • Import an AUTOSAR receiver port for which IsUpdated service is configured.

  • Use Simulink to configure an AUTOSAR receiver port for IsUpdated service.

  • Generate C and arxml code for an AUTOSAR receiver port for which IsUpdated service is configured.

For more information, see Configure AUTOSAR Receiver Port for IsUpdated Service.

Data element invalidation policies on sender ports

AUTOSAR defines an invalidation mechanism for data elements on AUTOSAR sender ports. To protect downstream data consumers from receiving invalid data, you can define an invalidation policy for a sender port data element. R2015b adds support for data element invalidation policies on sender ports. You can:

  • Import AUTOSAR sender port data elements for which an invalidation policy is configured.

  • Use Simulink to configure an invalidation policy for AUTOSAR sender port data elements.

  • Generate C and arxml code for AUTOSAR sender port data elements for which an invalidation policy is configured.

For more information, see Configure AUTOSAR Sender Port for Data Element Invalidation.

End-to-end protection for sender and receiver ports

AUTOSAR end-to-end (E2E) protection for sender and receiver ports is based on the E2E library. E2E is a C library that you can use to transmit data securely between AUTOSAR components. End-to-end protection adds additional information to an outbound data packet. The component receiving the packet can then verify independently that the received data packet matches the sent packet. Potentially, the receiving component can detect errors and take action.

For easier integration of AUTOSAR generated code with AUTOSAR E2E solutions, R2015b adds support for AUTOSAR E2E protection. You can:

  • Import AUTOSAR sender port and receiver ports for which E2E protection is configured.

  • Use Simulink to configure an AUTOSAR sender or receiver port for E2E protection.

  • Generate C and arxml code for AUTOSAR sender and receiver ports for which E2E protection is configured.

For more information, see Configure AUTOSAR S-R Interface Port for End-To-End Protection.

DataReceiveErrorEvent for receiver ports

In AUTOSAR sender-receiver communication between software components, the run-time environment (RTE) raises a DataReceiveErrorEvent when the communication layer reports an error in data reception by the receiver component. For example. the event can indicate that the sender component failed to reply within an aliveTimeout limit, or that the sender component sent invalid data.

R2015b adds support for creating DataReceiveErrorEvents in AUTOSAR receiver components. You can:

  • Import an AUTOSAR DataReceiveErrorEvent definition.

  • Use Simulink to define a DataReceiveErrorEvent.

  • Generate arxml code for AUTOSAR receiver ports for which a DataReceiveErrorEvent is configured.

For more information, see Configure AUTOSAR Receiver Port for DataReceiveErrorEvent.

Rte_IWriteRef for sender ports

In R2015b, you can leverage the Rte_IWriteRef API (AUTOSAR Release 4.x) when writing to AUTOSAR sender ports. Rte_IWriteRef returns a reference to the write data, which the runnable code can use to directly update the corresponding data elements. The API provides constant execution time for writes of any data element type, including structure and matrix data.

If you want AUTOSAR sender port data to be written using Rte_IWriteRef rather than Rte_IWrite, configure the corresponding Simulink root outport for ImplicitSendByRef access. For example, suppose that you open the example model rtwdemo_autosar_counter, and change the data access mode of its root outport, Output, from ImplicitSend to ImplicitSendByRef.

When you generate code, in rtwdemo_autosar_counter.c, the model step function uses Rte_IWriteRef to write the sender port data.

void Runnable_Step(void)
{
  ...
  int32_T *tmp;
  tmp = Rte_IWriteRef_Runnable_Step_Output_Output();
  ...
    /* Outport: '<Root>/Output' incorporates:
     *  Gain: '<S1>/Gain'
     *  Inport: '<Root>/Input'
     ...
     */
    *tmp = Rte_Prm_rCounter_K() * Rte_IRead_Runnable_Step_Input_Input();
    ...
}

AUTOSAR client-server modeling

R2015b enhances AUTOSAR client-server modeling with support for:

  • AUTOSAR error status

  • AUTOSAR NVRAM memory services

AUTOSAR error status

In R2015b, you can model AUTOSAR application error status for client-server error handling. In Simulink, you can:

  • Import arxml code that implements client-server error handling.

  • Configure error handling for a client-server interface.

  • Generate C and arxml code for client-server error handling.

For more information, see Configure AUTOSAR Client-Server Error Handling.

AUTOSAR NVRAM memory services

R2015b provides improved support for AUTOSAR nonvolatile RAM memory (NvM) services, including the NvM APIs ReadBlock, WriteBlock, and RestoreBlockDefaults. On ECU hardware startup or shutdown, or in response to an explicit read or write request, NvM services store data needed by the AUTOSAR software component. To better support NvM services, Embedded Coder®:

  • Imports and exports the void pointer data type that the NvM APIs use.

  • Imports and exports asynchronous-server call points for calling the NvM APIs. The arxml importer creates Function Caller blocks to model the call points.

  • Enforces constraints for modeling the RAM block required for NvM API calls. A data store memory block models the RAM block, and must directly connect to the Function Caller block.

  • Generates C code that provides the RAM block to the NvM API calls without creating a local buffer.

Here is an example of Data Store Read and Function Caller blocks that model an asynchronous call to the NvM WriteBlock service.

The generated C code calls the NvM WriteBlock service with the global RAM block as an argument.

appErrType = Rte_Call_WriteBlock_client_WriteBlock(Rte_Pim_myDSM());

Compatibility Considerations

Enforcing the new modeling constraints can generate errors for models that previously did not get errors. For example, if a Function Caller block configured to call an AUTOSAR NvM API does not directly connect to a data store block, Embedded Coder generates an error.

AUTOSAR nonvolatile data communication modeling

In R2015b, you can model AUTOSAR nonvolatile (NV) data communication, as defined in AUTOSAR Release 4.0 or later. To implement NV data communication, AUTOSAR software components define provide and require ports that send and receive NV data. In Simulink, you can:

  • Import AUTOSAR NV data communication definitions from arxml code.

  • Create AUTOSAR NV data communication elements, including an NV interface and ports, and map Simulink inports and outports to AUTOSAR NV ports.

  • Generate C and arxml code for AUTOSAR NV data communication elements.

To create NV data communication elements in Simulink:

  1. Open the Configure AUTOSAR Interface dialog box and select AUTOSAR Properties.

  2. Select NV Interfaces. Click the Add icon to create a new NV data interface. Specify its name and the number of associated NV data elements.

  3. Select and expand the new NV interface. Select Data Elements, and modify the data element attributes.

  4. In the left-hand pane of the Configure AUTOSAR Interface dialog box, under AUTOSAR, select AtomicComponents. Expand AtomicComponents and select an AUTOSAR component. Expand the component.

  5. Select and use the NvReceiverPorts, NvSenderPorts, and NvSenderReceiverPorts views to add the NV ports you require. For each NV port, select the NV interface you created.

  6. Switch to the Simulink mapping view. Select Simulink-AUTOSAR Mapping.

  7. Select and use the Inports and Outports views to map Simulink inports and outports to AUTOSAR NV ports. For each inport or outport, select an AUTOSAR port, data element, and data access mode.

To programmatically configure AUTOSAR NV data communication elements, use the AUTOSAR property and mapping functions. For example, the following MATLAB® code adds an AUTOSAR NV data interface and an NV receiver port to an open model. It then maps a Simulink inport to the AUTOSAR NV receiver port.

% Add AUTOSAR NV data interface myNvInterface with NV data element DE3
arProps = autosar.api.getAUTOSARProperties('rtwdemo_autosar_multirunnables_nv');
addPackageableElement(arProps,'NvDataInterface','/pkg/if','myNvInterface');
add(arProps,'myNvInterface','DataElements','DE3');

% Add AUTOSAR NV receiver port NvRPort, associated with myNvInterface
add(arProps,'ASWC','NvReceiverPorts','NvRPort','Interface','myNvInterface');

% Map Simulink inport NvRPort_DE3 to AUTOSAR port/element pair NvRPort and DE3
slMap = autosar.api.getSimulinkMapping('rtwdemo_autosar_multirunnables_nv');
mapInport(slMap,'NvRPort_DE3','NvRPort','DE3','ImplicitReceive');

AUTOSAR component behavior modeling

R2015b enhances AUTOSAR component behavior modeling with support for:

  • IRVs in feedback loops

  • Constant memory with const or volatile type qualifiers

IRVs in feedback loops

Simulink modeling now supports an AUTOSAR inter-runnable feedback loop, that is, AUTOSAR runnables accessing an AUTOSAR inter-runnable variable (IRV) with both read and write access. For example, in the figure, Runnable2_subsystem can read and write irv1. (Signal irv1 is shown in Highlight Signal to Source view.) In previous releases, the software flagged an error for this modeling pattern.

Constant memory with const or volatile type qualifiers

When modeling an AUTOSAR constant or static memory variable (AUTOSAR schema 4.x), you can now generate const, volatile, or const volatile qualifiers in C code to control data access.

You model AUTOSAR constant memory and static memory using AUTOSAR4.Parameter and AUTOSAR4.Signal data objects with a global storage class. Optionally, you can create custom storage classes and memory sections to customize the code generated for the global memory data, as described in Design Custom Storage Classes and Memory Sections. The AUTOSAR4 data class package now provides CONST, VOLATILE, and CONST_VOLATILE memory section definitions for configuring the const, volatile, and const volatile qualifiers. You can reference the new memory-section values in cscdesigner to set up memory sections, and then reference the values from within AUTOSAR4.Parameter and AUTOSAR4.Signal data objects.

AUTOSAR COM_AXIS lookup table modeling

R2015b provides the ability to model common axis (COM_AXIS) lookup tables for AUTOSAR applications. You can:

  • Import AUTOSAR calibration parameters of category CURVE, MAP, CUBOID, and COM_AXIS from arxml files into Simulink. The importer creates corresponding model content, including n-D Lookup Table blocks and parameter objects.

  • Use Simulink to create a COM_AXIS table and configure it for AUTOSAR run-time calibration.

  • Export COM_AXIS lookup table information in arxml code, including calibration parameters of category CURVE, MAP, CUBOID, and COM_AXIS.

For more information, see Calibration Parameters for COM_AXIS Lookup Tables and Configure COM_AXIS Lookup Table for Measurement and Calibration.

AUTOSAR arxml round-trip

R2015b enhances the AUTOSAR arxml round-trip workflow with support for:

  • Editable AUTOSAR display format for calibration

  • Configurable export of AUTOSAR internal data constraints

  • AUTOSAR reference bases

  • AUTOSAR-typed per-instance memory import

Editable AUTOSAR display format for calibration

AUTOSAR display format specifications control the width and precision display for calibration and measurement data. In R2015b, you can import and export AUTOSAR display format specifications, and edit the specifications in Simulink. You can specify display format for the following AUTOSAR data objects and elements:

  • Signal and parameter data objects (AUTOSAR and AUTOSAR4 classes)

  • Inter-runnable variables

  • Sender-receiver interface data elements

  • Client-server interface operation arguments

  • CompuMethods

For more information, see Configure AUTOSAR Display Format for Measurement and Calibration.

Configurable export of AUTOSAR internal data constraints

In releases before R2015b, you could not control the export or packaging of AUTOSAR internal data constraints from Simulink. Code generation exported internal data constraints to AUTOSAR package DataConstrs at a fixed location under the AUTOSAR datatype package.

In R2015b, you can enable or disable export of AUTOSAR internal data constraints. Export now is disabled by default. Optionally, you can specify the name and path of an AUTOSAR package into which internal data constraints are exported. For more information, see Configure AUTOSAR Internal Data Constraints Export.

AUTOSAR reference bases

Embedded Coder now can import AUTOSAR reference bases from arxml code into a model. Reference bases, which are defined in AUTOSAR Release 4.0, allow the use of relative paths in AUTOSAR specifications of packageable elements. In this arxml code example, reference base CMs resolves to /pkg/Components/MyComponent/CompuMethods.

AUTOSAR-typed per-instance memory import

R2014a introduced modeling and code generation support for AUTOSAR-typed per-instance memory (arTypedPerInstanceMemory) in Simulink models. With R2015b, you can import arTypedPerInstanceMemory definitions from arxml code into a model. When you import an arTypedPerInstanceMemory definition, the arxml importer:

  • Creates an AUTOSAR.Signal data object, sets its Storage class to PerInstanceMemory, and configures per-instance memory attributes.

  • Creates a Data Store Memory block that references the AUTOSAR.Signal object.

For more information, see Per-Instance Memory and Configure AUTOSAR Per-Instance Memory.

Toolchain controls for AUTOSAR code generation

The AUTOSAR target (autosar.tlc) now supports toolchain controls for C code generation. When you select the AUTOSAR target, the Configuration Parameter dialog box displays toolchain parameters rather than the template makefile (TMF) parameters previously displayed. You can more flexibly configure AUTOSAR code generation, for example, for processor-in-the-loop (PIL) verification, or to leverage a toolchain-based hardware support package.

Other targets that support toolchain controls include the ERT targets ert.tlc and ert_shrlib.tlc.

AUTOSAR RTE file generation enhanced for SIL and PIL

Building an AUTOSAR model generates RTE (run-time environment) files into the stub subfolder of the model build folder. The RTE files have .c and .h extensions, and contain stub implementations of the AUTOSAR Rte functions. The stub implementations can be used to test the generated C code in Simulink, for example, in software-in-the-loop (SIL) or processor-in-the-loop (PIL) simulations of the component under test. When the generated code ultimately is deployed in the AUTOSAR RTE, you replace the RTE stub files with externally-generated RTE files.

R2015b enhances the generated RTE stub files in many respects. The build generates most of the same RTE stub files as before, but with improved content:

  • More closely reflects the AUTOSAR element content of the model.

  • More closely resembles what an external RTE Generator creates.

  • Better descriptions of content and possible uses.

R2015b also generates new stub files, Std_Types.h: and Platform_Types.h:

  • Std_Types.h is a standard AUTOSAR file that defines basic data types.

  • Platform_Types.h maps AUTOSAR base types to platform types.

  • Std_Types.h includes Platform_Types.h, and is included by Rte_Type.h.

Lookup table blocks with new even spacing specification generate AUTOSAR compatible IFX library routines

As of R2015b, lookup table blocks generate AUTOSAR compatible IFX library routines. Lookup table blocks were enhanced to support a new specification for even-spacing breakpoints, which supports and generates AUTOSAR IFX routines.

For more information, see Code Replacement for AUTOSAR.

Programmatic validation and synchronization of AUTOSAR model configurations

Version 15.2.1 provides MATLAB functions for validating and synchronizing AUTOSAR model configurations:

The functions are equivalent to using the Validate and Synchronize icons in the graphical views of an AUTOSAR configuration.

Round-trip CompuMethods of category SCALE_LINEAR_AND_TEXTTABLE

Version 15.2.1 allows you to round-trip CompuMethods that use both LINEAR and TEXTTABLE scaling. Importing application data types that reference CompuMethods of category SCALE_LINEAR_AND_TEXTTABLE creates Simulink.NumericTypes and Simulink.AliasTypes in the Simulink workspace. In Simulink, you can modify the LINEAR scaling for the CompuMethods, but the TEXTTABLE scaling is read-only.

Improved merging of AUTOSAR authoring tool changes into Simulink model as part of round-trip iterations

Simulink provides the ability to merge AUTOSAR authoring tool changes in arxml files into a model and generate an update report. Version 15.2.2 adds more automation and better reporting to the merge process. The software automates Simulink block additions required to represent arxml updates and identifies Simulink block deletions required to represent arxml updates.

Support of LiteralPrefix for enumerations in IncludedDataTypeSets

In Version 15.2.2, the arxml importer can import LiteralPrefixes defined in IncludedDataTypeSets. The LiteralPrefix is then automatically added to Simulink enumerated data types generated by the importer.

AUTOSAR schemas 4.2.2 and 3.2.2

Version 15.2.4 extends support of AUTOSAR schema versions 4.2 and 3.2 to include schema revisions 4.2.2 and 3.2.2. Embedded Coder supports the new schema revisions for import and export of arxml files and generation of AUTOSAR-compatible C code.

If you import schema 4.2.2 or 3.2.2 arxml descriptions into Simulink, the arxml importer detects and uses the schema version and revision, and sets the schema version parameter in the model. For more information on schema import and export, see Select an AUTOSAR Schema.

If you are developing an AUTOSAR software component based on AUTOSAR schema version 3.2, schema revision 3.2.2 allows you to include sender-receiver port end-to-end (E2E) protection, receiver port IsUpdated service, and port-based nonvolatile (NV) data communication in your component design.

AUTOSAR DESC elements populate Simulink Description fields

Version 15.2.8 enhances support for AUTOSAR DESC elements. Importing AUTOSAR DESC information associated with an AUTOSAR identifiable element now populates the Description property in the corresponding Simulink element or data object. Correspondingly, exporting a Simulink element or data object Description property now populates the DESC information in the corresponding AUTOSAR element. Previously, Embedded Coder preserved AUTOSAR DESC information across arxml round-trips but did not leverage the information to add a readable text description to the Simulink model.

AUTOSAR arxml importer enhancements

Version 15.2.1 provides the following arxml importer enhancements:

  • During arxml import, for ArTypedPerInstanceMemory referencing ApplicationArrayDataTypes, the software now creates data store memory initialized with dimensions and initial values.

  • The software now supports import of ImplementationDataTypes with category TYPE_REFERENCE (with a reference to another ImplementationDataType with category DATA_REFERENCE, that is, VoidPtr). Previously, the software generated an error message that began with the following text.

    Error using Simulink.metamodel.arplatform.ArxmlImporter/read
    Assertion failed: Could not find context sequence for type /
  • When the name of a NvDataInterface or DataElement is updated using import with update (updateModel), the mapping now is correctly updated.

Version 15.2.2 provides the following arxml importer enhancements:

  • Import no longer throws an error when a CompuMethod is specified on an ImplementationDataType element.

  • Import of AUTOSAR physical data constraints is now correct when the physical and internal data constraints are bundled together.

  • If you import an AUTOSAR software component that uses an NV data interface, the importer now correctly initializes the XML option ImplementationDataType Reference.

  • ALIVE-TIMEOUT values for AUTOSAR ports are now imported correctly from arxml files and preserved in generated arxml descriptions. Previously, ALIVE-TIMEOUT values imported from arxml files were not preserved.

Version 15.2.3 provides the following arxml importer enhancements:

  • The importer now correctly configures a Simulink Function block when the imported arxml description contains runnable arguments. In arxml files, runnable arguments are described using RUNNABLE-ENTITY-ARGUMENT nodes. Previously, if a runnable description in the arxml file included runnable arguments, the importer incorrectly configured the Simulink Function block.

  • Importing inlined array types from an arxml file no longer results in a model that fails to generate code. In arxml files, an inlined array type is an array type for which the element category is not a TYPE_REFERENCE. Previously, importing inlined array types resulted in invalid models.

  • Importing incomplete lookup table or axis descriptions in an arxml file no longer results in an incorrect model. For example, if a COM-AXIS node is missing a description of the SW-BASE-TYPE node, the axis is incomplete. The importer and the code generator now recognize when the information is incomplete and behave correctly.

  • Importing an NvM_ReadBlock operation from an arxml file now correctly configures the corresponding Function Caller block. Previously, in the created model, the block arguments were incorrectly configured.

  • Importing LITERAL-PREFIX nodes now correctly creates Simulink enumeration type and literals. Previously, the enumeration literals were incorrect in the enumeration type.

  • Importing an incomplete DATA-TYPE-MAPPING-SET node if neither the data type set nor the constituent data types are used in the model no longer throws an error. Previously, importing incomplete nodes resulted in an importer error.

  • Importing a COMPU-METHOD node that represents a linear scaling slope less than or equal to zero now results in an error. Previously, the importer created an incorrect model. Linear scaling with slope less than or equal to zero is not supported for AUTOSAR models.

  • Importing a SW-BASE-TYPE node that represents an integer type of size 64, when the type is not used in the created model, no longer throws an error. Previously, the importer threw an error, incorrectly assuming that the integer type is used in the created model. Integer types of size greater than 32 are not supported for AUTOSAR models.

Version 15.2.4 provides the following arxml importer enhancements:

  • The importer now successfully imports parameter values with a pointer-to-void implementation data type. Previously, importing these data types caused an import error.

  • The importer now successfully imports application data types with a CompuMethod of category SCALE_LINEAR_AND_TEXTTABLE, when the mapped implementation data type category is TYPE_REFERENCE. Previously, importing these data types caused an import error.

  • Improved importer performance when using Simulink data dictionary.

  • The importer now successfully imports multiple data store memories from arxml files. Previously, importing multiple data store memories could cause a Simulink canvas limit error.

  • The importer now successfully imports an application value specification of category BOOLEAN with VT labels. Previously, importing these application value specifications caused an import error.

  • The updateModel method now successfully updates models that previously gave an out of memory error.

Version 15.2.5 provides the following arxml importer enhancements:

  • The importer now correctly imports the Min and Max values for ApplicationDataTypes by using the correct precision for fixed-point and float types. Previously, the importer threw an error message similar to "Value (3276.7000000000003) is greater than maximum (3276.7)" when the imported constant value is equal (within tolerance) to the Min or Max value.

  • Importer method updateModel now correctly handles Goto/From blocks with local scope. Previously, updateModel could get into a loop and potentially run out of memory when locally scoped Goto/From blocks had the same tag.

  • The importer now correctly imports ReceiverPorts with multiple ReceiverComSpecs with InitValue specified using ARRAY-VALUE-SPECIFICATION. Previously, the importer threw error message "Imported AUTOSAR MetaModel contains orphaned elements".

  • The importer now correctly imports STATIC-MEMORY or CONSTANT-MEMORY and overwrites existing Simulink.Signal or Simulink.Parameter data objects, respectively. Previously, the importer threw an error while overwriting existing Simulink data objects.

Version 15.2.6 provides the following arxml importer enhancements:

  • The importer no longer errors out when an arxml file contains PORT-API-OPTIONS. Previously, the importer threw the following error:

    Element {} of type Simulink.metamodel.arplatform.behavior.PortAPIOption
    has no property named {}InitValue
  • The importer now throws a warning when an arxml file specifies a ModeSwitchEvent TARGET-MODE-DECLARATION-REF reference that does not exist. Previously, the importer threw an error for this case.

  • The importer now correctly imports runnables with self-feedback inter-runnable variables (IRVs), that is, IRVs that are only read and written by the same runnable. Previously, the importer threw the following error:

    Cannot map data transfer signal signalName because it does not exist.
  • The importer now correctly handles arxml descriptions that produce merged array signals in Simulink. Previously, the importer created an uncompilable Simulink model.

  • The importer now correctly ignores DataConstr for Structure members of category TYPE_REFERENCE, which Simulink does not support. Previously, the importer tried to read DataConstr for Structure members of category TYPE_REFERENCE, which could generate an unhelpful importer error message.

  • The importer now correctly creates internal data type names, without double underscores, for ApplicationDataTypes of category VAL_BLK, CURVE, MAPS, etc. Previously, if a data type already had underscore as the last character in its ShortName, the importer added a second underscore, which caused a validation error.

  • The importer now correctly creates an AUTOSAR.Parameter with data type boolean for ApplicationDataTypes of category VAL_BLK. Previously, the importer created an AUTOSAR.Parameter with data type logical, which caused a compilation error.

  • The importer now throws an informative error message when an ApplicationDataType of category CURVE, COM_AXIS, etc., for a lookup table uses an initial value that is scalar rather than nonscalar. Previously, the importer threw an unhelpful error message.

  • The importer no longer creates unnecessary and unused Simulink data types in the workspace when importing ApplicationDataTypes of category VAL_BLK.

Version 15.2.7 provides the following arxml importer enhancements:

  • The importer now makes better use of the Simulink model canvas for arxml files that contain a large number of runnables or ports. Previously, the importer threw the following error:

    Error using autosar.mm.mm2sl.SLModelBuilder/setIdealBlockPosition
    At least one value is out of range for defining rectangle or position.
    All values must be less than or equal to 32767
  • The importer now creates correct Goto/From tags from arxml files that contain long identifiers. Previously, the importer threw the following error:

    Error using autosar.mm.mm2sl.MRLayoutManager/addGotoFrom (line 265)
    The value 'RPortWithAVeryLongIdentifier_RPortWithAVeryLongIdentifier_VariationLongIdentifier_2_Tag'
    of parameter 'GotoTag' is not a valid MATLAB identifier.
    Valid identifiers start with an alphabetic character, followed by at most 63 alphanumeric or '_'
  • The importer now correctly handles an implementation data type that is directly referenced from a data prototype and maps to a fixed-point application data type. Previously, the importer created an extra fixed-point Simulink type corresponding to the implementation data type.

Version 15.2.8 provides the following arxml importer enhancement:

The importer now correctly imports an ImplementationDataType of category STRUCTURE or ARRAY that references another ImplementationDataType. Previously, importing ImplementationDataTypes for curves and maps could generate an assertion.

Version 15.2.9 provides the following arxml importer enhancement:

Importer method updateModel now works correctly with reference configuration sets. Previously, updateModel threw the following error:

A configuration set reference does not allow writing to parameters in the source configuration set

Version 15.2.10 provides the following arxml importer enhancements:

  • The importer now correctly updates models with Goto and From blocks. Previously, updating some models that had Goto and From blocks generated the following error:

    Out of memory. The likely cause is an infinite recursion within the program.
    Error in num2str (line 72)
                    s = int2str(x); % Enhance the performance
  • The importer now correctly configures the base type (StorageType) of an enumeration data type when an implementation data type references a TEXTTABLE CompuMethod. Previously, the StorageType was not set and defaulted to sint32.

  • The importer now can create models that have branched IsUpdated ports. Previously, the importer displayed the following error:

    Error using autosar.mm.mm2sl.SLModelBuilder/createIsUpdatedPortElement (line 663)
    Could not create IsUpdated inport for RPort_DE1_IsUpdated
    Error in autosar.mm.mm2sl.SLModelBuilder/addPortElement (line 124)
         this.createIsUpdatedPortElement(blkPath, m3iPort, m3iDataElement, slPortType);
  • The importer now imports PerInstanceMemory that has ArrayValueSpecification initial data. Previously, the importer displayed the following error:

    Error : While setting the 'Type' property of 'MatrixValueSpecification':
    Value must be 'Simulink.metamodel.foundation.ImmutableType'.
  • The importer now correctly creates function-call subsystems with large subsystems (for example, greater than 800 ports). Previously, the importer generated the following error:

    Error using autosar.mm.mm2sl.SLModelBuilder/setIdealBlockPosition (line 110)
    At least one value is out of range for defining rectangle or position. All values must
    be less than or equal to 32767.
  • The importer now correctly imports InvalidValues with a UnitReference. Previously, the importer displayed an error similar to the following:

    Error using Simulink.metamodel.arplatform.ArxmlImporter/read
    Assertion failed: MetaClass Simulink.metamodel.types.LiteralReal does not have
    property Unit at
    b:\matlab\src\arxml_util\arxml\arxmlreadtransformer4p0.cpp:10444
  • The importer now supports import of ImplementationDataTypes of category TYPE_REFERENCE that do not specify a CompuMethod. Previously, the importer required that both the parent and the referenced ImplementationDataType specify a CompuMethod.

AUTOSAR arxml export enhancements

Version 15.2.1 provides the following arxml export enhancements:

  • Multiple ApplicationDataTypes created from same Simulink data type, but with different Min and Max values, now reference the same CompuMethod. Previously, each ApplicationDataType referenced a separate CompuMethod.

  • Export no longer incorrectly generates an error when building a model with a mixture of Receiver/Sender and NvReceiver/NvSender ports. Previously, export threw the following error:

    ERROR: The call to autosar_make_rtw_hook, during the exit hook generated the following error:
    Cannot create reference to element [unnamed].
  • The software now prevents inclusion of old arguments in the exported interface for the Invoke AUTOSAR Server Operation block.

Version 15.2.2 provides the following arxml export enhancement:

Export no longer throws an error when Simulink enumeration is redefined with option AddClassNameToEnumNames set to true.

Version 15.2.4 provides the following arxml export enhancement:

Unused pointer-to-integer data types no longer cause export errors. Simulink supports pointer-to-void data types, but does not support pointer-to-integer data types. Previously, unused pointer-to-integer data types caused export to fail.

Version 15.2.5 provides the following arxml export enhancement:

Exporting arxml descriptions previously could change the CompuMethod category of an ApplicationDataType of type BOOLEAN from IDENTICAL to TEXTTABLE in top-down workflows. Export now preserves the CompuMethod category.

Version 15.2.6 provides the following arxml export enhancements:

  • Export now round-trips the initial values that were imported on port ComSpecs. Previously, export created default initial values on the port ComSpecs, replacing the imported initial values.

  • Export now correctly handles rounding errors when writing out CompuMethod coefficients. Previously, export could write coefficient values that looked like 0.99999999999999989.

  • Export now correctly generates only Internal DataConstr for enumeration data types, for both ApplicationDataType and ImplementationDataType. Previously, export generated duplicate DataConstrs for enumeration data types because it tried to export Physical DataConstr for the enumeration ApplicationDataType.

  • With modular XML file packaging selected, export no longer generates empty packages for DataConstrs and SystemConstants in the _datatype.arxml file. Previously, export generated empty packages, resulting in a round-trip arxml mismatch.

  • Export no longer generates INVALID-VALUEs with invalid or empty CONSTANT-REFERENCEs. Previously, exporting an imported INVALID-VALUE with an empty CONSTANT-REFERENCE could crash Simulink.

  • Export now throws a warning if two common axis lookup tables use the same parameter for table data and different parameters for axis data. The warning informs the user that the COM_AXIS parameter is not shared. Previously, export threw an error.

Version 15.2.7 provides the following arxml export enhancement:

Export now correctly generates arxml files when an application data type does not reference a CompuMethod. Previously, export threw an error while setting the unit property for the physical data constraint.

Version 15.2.9 provides the following arxml export enhancement:

Export now supports exporting a previously imported inlined structure type. Previously, export threw the following error:

Error using autosar.mm.mm2rte.TypeBuilder/addReferencedType (line 68)
Unsupported m3iType class M3I.Object for addReferencedType.

AUTOSAR code generation enhancements

Version 15.2.1 provides the following AUTOSAR code generation enhancement:

Code generation no longer incorrectly throws an error when data access mode QueuedExplicitReceive is used with a nonvolatile (NV) data interface.

Version 15.2.6 provides the following AUTOSAR code generation enhancements:

  • Code generation now generates correct typedefs for void types in Rte_Type.h. Previously, the code generator generated the wrong typedef, which could cause compilation errors during software-in-the-loop (SIL) simulations.

  • Code generation now generates the return type of RTE function Rte_Mode_<p>_<o> as ShortName of ImplementationDataType of ModeDeclarationGroup. Previously, the code generator generated the return type as ShortName of ModeDeclarationGroup, which could cause compilation errors in the contract phase.

Version 15.2.7 provides the following AUTOSAR code generation enhancement:

Code generation now generates an implementation enumeration data type when an application enumeration data type is mapped to an implementation data type. Previously, the code generator incorrectly generated an application enumeration data type.

AUTOSAR modeling enhancements

Version 15.2.1 provides the following AUTOSAR modeling enhancements:

  • In the AUTOSAR configuration dialog box, when mapping of a Simulink inport to a PortInterface DataElement changes, the software now updates the trigger port for the associated event.

  • The following AUTOSAR configuration dialog box icons for nonvolatile (NV) data interfaces are updated: NvReceiverPorts, NvSenderPorts, and NvSenderReceiverPorts.

  • In the NV Add Interfaces dialog box, the label Nv Data Interfaces is changed to Non-Volatile Data Interfaces.

  • In the NV Add Ports dialog box, the label Nv Sender Receiver Ports is changed to Non-Volatile Data Ports.

  • Adding an NV SenderReceiverPort through the API now correctly errors out for AUTOSAR schema version 4.0 models.

  • Default names of DataElements in an NV data interface are changed to NVData1, NVData2, and so on.

  • When using the AUTOSAR configuration dialog box, a change in a data element name for an NV data interface now updates the drop-down menu for Simulink port mapping.

  • The software no longer generates a segmentation violation when VARIABLE-ACCESS for an unmapped component has a missing VARIABLE-PROTOTYPE reference.

  • Changed the default ApplicationError for a model that has an error argument but no predefined error codes from 0 to 1.

Version 15.2.6 provides the following AUTOSAR modeling enhancements:

  • AUTOSAR validation no longer errors out when a model includes both NV data ports and a mode-receiver port.

  • AUTOSAR function autosar.api.syncModel now automatically maps unmapped Function Caller blocks for existing client-server operations to the same mapping as existing mapped function callers. Previously, the function did not complete the mapping and validation and subsequently errored out. The issue affected only the function and not the Synchronize icon in the Configure AUTOSAR Interface dialog box.

Version 15.2.9 provides the following AUTOSAR modeling enhancement:

The Configure AUTOSAR Interface dialog box now correctly displays mode declaration values for a mode-switch event when you specify an enumeration type on a Simulink inport without a space. You also can now specify an enumeration type name with a ? (question-mark) symbol.