R2016b

New Features

AUTOSAR Basic Software (BSW) Services: Simulate BSW including Diagnostic Event Manager (DEM) and NVRAM Manager (NvM)

The AUTOSAR standard defines important services as part of Basic Software (BSW) that runs in the AUTOSAR runtime environment (RTE). Examples include the NVRAM Manager (NvM) and the Diagnostic Event Manager (Dem). In the AUTOSAR RTE, AUTOSAR software components typically access BSW services using client-server or sender-receiver communication.

To support system-level modeling of AUTOSAR components and services, R2016b adds an AUTOSAR Basic Software block library. The library contains preconfigured Function Caller blocks for modeling component calls to AUTOSAR BSW services.

To implement client calls to AUTOSAR BSW service interfaces in your AUTOSAR software component, you drag and drop Basic Software blocks into an AUTOSAR model and click a Synchronize icon. The software automatically configures the client calls in the AUTOSAR configuration. For more information, see Model AUTOSAR Basic Software (BSW) Service Calls, Configure Calls to AUTOSAR Diagnostic Event Manager (Dem) Service, and Configure Calls to AUTOSAR NVRAM Manager (NvM) Service.

AUTOSAR Parameters: Model STD_AXIS and COM_AXIS lookup table parameters, export SwRecordLayouts, and apply SwAddrMethods

R2016b enhances AUTOSAR calibration parameter and data modeling with additional support for:

AUTOSAR STD_AXIS and COM_AXIS lookup tables

AUTOSAR applications can use lookup tables in either or both of two ways:

  • Implement high-performance search operations.

  • Support tuning of the application with measurement and calibration tools.

To model lookup tables for automotive application tuning, use the new classes Simulink.LookupTable and Simulink.Breakpoint to store tunable table and breakpoint data. Simulink® lookup table blocks have additional parameters to support the use of Simulink.LookupTable and Simulink.Breakpoint objects. AUTOSAR models can leverage the new classes to model STD_AXIS and COM_AXIS lookup tables. In Simulink, you can:

  • Import arxml files that contain AUTOSAR lookup tables in STD_AXIS and COM_AXIS configurations.

  • Create STD_AXIS and COM_AXIS lookup tables and map them to AUTOSAR parameters. In R2016b, you can create AUTOSAR parameters for lookup tables graphically, using the AUTOSAR Properties Explorer, or programmatically, using AUTOSAR property functions. For more information, see AUTOSAR port-based and internal calibration parameters.

  • Generate arxml and C code with STD_AXIS and COM_AXIS lookup table content.

For more information, see Configure STD_AXIS and COM_AXIS Lookup Tables for AUTOSAR Measurement and Calibration.

AUTOSAR port-based and internal calibration parameters

To support mapping a Simulink lookup table to an AUTOSAR parameter, you can now create AUTOSAR calibration parameters (ParameterDataPrototypes) using the AUTOSAR Properties Explorer or AUTOSAR property functions. You can create either internal AUTOSAR parameters, defined and accessed only within your software component, or port-based AUTOSAR parameters, associated with a port-based parameter interface.

The AUTOSAR parameters that you create subsequently are available for Simulink lookup table mapping, using the Simulink-AUTOSAR Mapping Explorer or AUTOSAR map functions.

For more information, see Configure AUTOSAR Port-Based Calibration Parameters.

AUTOSAR SwRecordLayouts for lookup tables

AUTOSAR software components use software record layouts (SwRecordLayouts) to specify how to serialize data in the memory of an AUTOSAR ECU. The arxml importer imports and preserves the SwRecordLayout property for AUTOSAR data.

R2016b allows you to import SwRecordLayouts from arxml files in either of two ways:

  • If you create your AUTOSAR model from arxml files using importer method createComponentAsModel, include an arxml file that contains SwRecordLayout definitions in the import. The imported SwRecordLayouts are preserved and subsequently exported in arxml code.

  • If you create your AUTOSAR model in Simulink, you can import reference definitions of SwRecordLayouts from arxml files. When you generate model code, the exported arxml code contains references to the imported read-only SwRecordLayout elements, but not their definitions.

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

AUTOSAR SwAddrMethods for measurement and calibration tools

AUTOSAR software components use software address methods (SwAddrMethods) to group data in memory for access by measurement and calibration tools. In an AUTOSAR software component configuration, you assign common memory sections to data. When the runtime environment instantiates calibration parameters, calibration parameters that reference the same SwAddrMethod are placed within the same calibration parameter group.

The arxml importer imports and preserves the SwAddrMethod property for AUTOSAR data. In previous releases, in Simulink, you could assign memory sections to global constant and static memory, using AUTOSAR data objects. But you could not assign SwAddrMethods or memory sections to data accessed by RTE function calls, such as sender-receiver (S-R) interface data elements or inter-runnable variables (IRVs).

R2016b allows you to graphically or programmatically select imported SwAddrMethod values for AUTOSAR data accessed by RTE function calls.

When you build the model, the exported arxml code reflects the SwAddrMethod values you selected.

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

AUTOSAR startup, reset, and shutdown modeling

AUTOSAR applications sometimes require complex logic to execute during system initialization, reset, and termination sequences. R2016b introduces the Simulink blocks Initialize Function and Terminate Function. You can use these blocks to control execution of a component in response to initialize, reset, or terminate events at any level of a model hierarchy. Each nonvirtual subsystem can have its own set of initialize, reset, and terminate functions. In a lower-level model, Simulink aggregates the content of the functions with corresponding instances in the parent model.

AUTOSAR models can leverage the new blocks to model potentially complex AUTOSAR startup, reset, and shutdown sequences. The subsystems work with any AUTOSAR component modeling style.

For more information, see Startup, Reset, and Shutdown and Configure AUTOSAR Initialize, Reset, or Terminate Runnables.

AUTOSAR external trigger event communication

AUTOSAR Release 4.0 introduced external trigger event communication, in which an AUTOSAR component or service signals an external trigger occurred event (ExternalTriggerOccurredEvent) to another component. The receiving component activates a runnable in response to the event.

Embedded Coder® now supports modeling the receiver portion of AUTOSAR external trigger event communication. In a component that you want to react to an external trigger, you create a trigger interface, a trigger receiver port to receive an ExternalTriggerOccurredEvent, and a runnable that is activated by the event.

For more information, see Configure Receiver for AUTOSAR External Trigger Event Communication.

AUTOSAR support for JMAAB model architecture

Embedded Coder supports AUTOSAR code generation for the model architectures described in the Japan MBD Automotive Advisory Board (JMAAB) document Control Algorithm Modeling Guidelines Using MATLAB, Simulink, and Stateflow - Version 4.01. The document is available from the MAAB Web page at https://www.mathworks.com/solutions/automotive/standards/maab.html.

The document describes three layouts for the top layer of a controller model:

  • Simple control model — Represents a functions layer and a scheduling layer in one layer.

  • Complex control model type alpha (α) — Places a scheduling layer above function layers.

  • Complex control model type beta (β) — Places function layers above scheduling layers.

R2016b adds support for JMAAB type beta modeling in AUTOSAR models. For example, here is an AUTOSAR example model, rtwdemo_autosar_swc_fcncalls, in which an asynchronous function-call runnable at the top level of the model interacts with a periodic rate-based runnable. This type of component leverages periodic and asynchronous rates (sample times).

For more information about this component modeling style, see .Add Top-Level Asynchronous Trigger to Periodic Rate-Based System.

AUTOSAR ExplicitReceiveByVal data access mode for receiver ports

R2016b adds support for modeling scalar explicit read by value access for AUTOSAR receiver ports, and generating the corresponding AUTOSAR API Rte_DRead in C code. Reading data by value can produce more efficient and readable C code and reduce RAM requirements.

In Simulink, you can model the data access in the following ways:

  • Import an arxml file that uses DATA-RECEIVE-POINT-BY-VALUES variable access for a port. The importer creates a root inport with ExplicitReceiveByVal data access and maps it to an AUTOSAR receiver port.

  • Create a root inport, select ExplicitReceiveByVal data access, and map it to an AUTOSAR receiver port.

When you build the model, the exported arxml code defines DATA-RECEIVE-POINT-BY-VALUES variable access for the AUTOSAR receiver port.

<RUNNABLE-ENTITY UUID="...">
...
  <SHORT-NAME>Runnable_Step</SHORT-NAME>
...
  <DATA-RECEIVE-POINT-BY-VALUES>
    <VARIABLE-ACCESS UUID="...">
      <SHORT-NAME>IN_Input_Input</SHORT-NAME>
      <ACCESSED-VARIABLE>
        <AUTOSAR-VARIABLE-IREF>
          <PORT-PROTOTYPE-REF DEST="R-PORT-PROTOTYPE">
            /pkg/swc/rtwdemo_autosar_counter/Input</PORT-PROTOTYPE-REF>
          <TARGET-DATA-PROTOTYPE-REF DEST="VARIABLE-DATA-PROTOTYPE">
            /pkg/if/Input/Input</TARGET-DATA-PROTOTYPE-REF>
        </AUTOSAR-VARIABLE-IREF>
      </ACCESSED-VARIABLE>
    </VARIABLE-ACCESS>
  </DATA-RECEIVE-POINT-BY-VALUES>
...
</RUNNABLE-ENTITY>

The generated C code uses appropriate Rte_DRead API calls to receive the port data by value.

void Runnable_Step(void)
{
 ...
    /* Gain: '<S1>/Gain' incorporates:
     *  Inport: '<Root>/Input'
     *
     * Block description for '<S1>/Gain':
     *  This block references an AUTOSAR calibration parameter, which is
     *  accessed using the AUTOSAR Rte_Calprm function signature.
     */
    rtwdemo_autosar_counter_B.Gain = Rte_Prm_rCounter_K() *
      Rte_DRead_Input_Input();
 ...
}

AUTOSAR ModeSenderPorts and ModeSwitchPoints for application mode management

AUTOSAR mode-switch (M-S) communication relies on a mode manager and connected mode users. The mode manager is an authoritative source for software components to query the current mode and to receive notification when the mode changes. A mode manager can be provided by AUTOSAR Basic Software (BSW) or implemented as an AUTOSAR software component. A mode manager implemented as a software component is called an application mode manager. A software component that queries the mode manager and receives notifications of mode changes is a mode user.

R2016b enhances Simulink modeling of AUTOSAR M-S communication by adding the ability to model application mode manager components, including AUTOSAR mode sender ports (as defined in AUTOSAR Release 4). Mode sender ports output a mode switch to connected mode user components. For example, here is an application mode manager, modeled in Simulink, that uses a mode sender port to output the current value of EngineMode.

For more information, see Mode-Switch Interface and Configure AUTOSAR Mode-Switch Communication.

AUTOSAR reference element definitions for sharing among components and services

R2016b supports a new workflow for importing external AUTOSAR element definitions, defined in arxml files, for sharing among multiple AUTOSAR components and services. Benefits of sharing and reusing AUTOSAR element definitions include lower risk of definition conflicts and easier code integration. You can manage shared definitions in a centralized way.

Suppose that you have a large number of AUTOSAR software components that use similar packageable AUTOSAR elements in similar ways. You can define sets of reference elements in arxml files, and your software components can share them on a read-only basis. Each software component can import the element definitions it requires and reference them. When you build the model, exported arxml code contains references to the shared elements, but not their definitions. Their definitions remain in the reference element arxml source files.

If definitions of reference elements change, you modify them in the arxml files, and then import the updated definitions into the affected software components.

AUTOSAR elements that are supported for reference use in Simulink include:

  • CompuMethod, Unit, and PhysicalDimension

  • ImplementationDataType and SwBaseType

  • SwSystemConst, SwSystemConstValueSet, and PredefinedVariant

  • SwRecordLayout

  • SwAddrMethod

For more information, see Import or Update Shared AUTOSAR Reference Element Definitions.

ARXML import/export and C code generation for latest AUTOSAR 4.2 and 3.2 standard revisions

R2016b 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 code 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.

Note

This support is available to R2015b and R2016a Embedded Coder customers by installing the latest AUTOSAR support package for your release:

  • R2015b Embedded Coder Support Package for AUTOSAR Standard, Version 15.2.4 or later

  • R2016a Embedded Coder Support Package for AUTOSAR Standard, Version 16.1.1 or later

AUTOSAR code replacement library enhancements

R2016b improves the AUTOSAR code replacement library (CRL) by adding support for:

  • Functions that perform multiplication followed by a shift right arithmetic operation.

  • Arguments of type struct for the lookup table functions that perform prelookup and interpolation operations.

For more information, see AUTOSAR Code Replacement Library.

AUTOSAR DESC elements populate Simulink Description fields

Version 16.2.2 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.

Increased automation for AUTOSAR model updates from arxml files

The arxml importer function updateModel updates an AUTOSAR model with changes specified in arxml files. The updateModel function automatically adds Simulink blocks and signal lines to represent AUTOSAR elements, modifies AUTOSAR properties, and updates Simulink-to-AUTOSAR mapping. For more information, see Import AUTOSAR Software Component Updates (Embedded Coder).

In Version 16.2.4, the updateModel function now automates insertion and mapping of the following elements:

  • Inter-runnable variable (IRV) lines for AUTOSAR IRVs

  • Constant blocks for AUTOSAR parameters

  • Data store memory (DSM) blocks for AUTOSAR per-instance memory (PIM) blocks

Previously, these elements required manual additions to the model.

Model updates also now resize added Function Caller, Constant, and DSM blocks so that block text is readable.

Navigate AUTOSAR Update Report using search bar

In Version 16.2.5, the update report generated by importer function updateModel now provides a search bar. You can quickly navigate to specific elements or other strings of interest.

Import BITFIELD_TEXTTABLE CompuMethods

AUTOSAR CompuMethods of category BITFIELD_TEXTTABLE allow you to access bit values within an application data type of category VALUE. You can group bit values, assign labels to them, and define masks for accessing values within bytes of data.

In Version 16.2.5, you can import BITFIELD_TEXTTABLE CompuMethods from arxml files. After you import the CompuMethods, you can create Simulink enumerated types to represent bit groups and masks for accessing the bitfields, and reference them in Simulink bitwise and relational operator and constant blocks.

You can use the AUTOSAR properties function createEnumeration to create Simulink enumerated types for a bitfield CompuMethod. For example:

arProps = autosar.api.getAUTOSARProperties(modelName);
createEnumeration(arProps,'/Company/Module/CompuMethods/MyBitfieldCompuMethod');

AUTOSAR Basic Software: Use array and bus data types with NvMServiceCaller operations

In Version 16.2.5, when using the Basic Software block NvMServiceCaller to call ReadBlock, RestoreBlockDefaults, or WriteBlock operations, you now can specify array and bus data types. Use the block parameter Argument specification.

AUTOSAR arxml importer enhancements

Version 16.2.1 provides the following arxml importer enhancement:

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 16.2.3 provides the following arxml importer enhancements:

  • The importer now supports Goto/From tag names up to 64 characters. Previously, tag names were limited to 32 characters, after which the name was truncated and appended with a unique suffix.

  • 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.

  • The importer now makes better use of the Simulink model canvas for arxml files that contain a large number of runnables or ports. Previously, import 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.
  • Importer method updateModel now supports importing arxml files containing matrices with differing dimensions. Previously, updateModel threw an error similar to the following:

    Error using Simulink.metamodel.arplatform.Comparator/compare
    Assertion failed: first and second values sizes are different at
    b:\matlab\src\arxml_util\matcher\comparator.cpp:209:

Version 16.2.4 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 correctly imports ComSpecs with matching InitValue names. Previously, the importer discarded ComSpecs in which InitValues had the same name.

  • 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 a configuration in which multiple InitValues have ValueSpecifications with the same short label name. Previously, when ValueSpecification short labels had the same name, the importer could import incorrect initial values.

  • 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 NumericalValueSpecifications with Value NaN. Previously, the importer generated an error message.

  • 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.

Version 16.2.5 provides the following arxml importer enhancements:

  • The importer now correctly imports arxml descriptions in which runnables contain self-feedback inter-runnable variables (IRVs). Previously, the importer generated the following error:

    Message Key RunnableWithSelfFeedbackIRV was not found in the catalog
    autosarstandard:importer
  • The importer now correctly sets the implementation data type name for types of category TYPE_REFERENCE.

AUTOSAR arxml export enhancements

Version 16.2.1 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 16.2.3 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.

Version 16.2.4 provides the following arxml export enhancements:

  • Export now uses the correct exponent case (uppercase) when writing out ValueSpecifications for LookupTables. Previously, the exporter used lowercase.

  • Export now correctly generates arxml descriptions for imported ApplicationRecordTypes that have missing type references. Previously, export generated the following error:

    Error using autosar.mm.arxml.Exporter/write
        Cannot create reference to element [unnamed].
  • Export now supports round-tripping an AutosarVariableRef that does not specify a DataPrototype. Previously, export generated an error message.

Version 16.2.5 provides the following arxml export enhancements.

  • Export now correctly places an AUTOSAR data type package inside the modelname_datatype.arxml file, even if the package does not match XML option specifications. Previously, interface and datatype packages could be incorrectly placed in the modelname_component.arxml file.

  • Export now correctly exports any AUTOSAR interface with the isService attribute set to true to stub/modelname_external_interface.arxml, rather than to a top-level ARXML file such as modelname.arxml or modelname_interface.arxml. Previously, setting the isService attribute caused only C-S interfaces to be exported to the external interfaces ARXML stub file. Other interfaces with isService set, such as S-R or M-S, were incorrectly exported to a top-level ARXML file.

  • Export performance is improved when the Configure AUTOSAR Interface dialog box is open. Previously, export took much longer when the dialog box was open.

  • Export now generates a Category subelement when describing AUTOSAR VariationPointProxy elements. Previously, VariationPointProxy elements did not include a Category subelement.

AUTOSAR code generation enhancement

Version 16.2.3 provides the following AUTOSAR code generation enhancement:

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

AUTOSAR modeling enhancement

Version 16.2.3 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.