R2016a

New Features, Compatibility Considerations

Installing Version 16.1.2 or later requires uninstalling earlier versions

If you previously installed an earlier Version 16.1.n Embedded Coder® Support Package for AUTOSAR Standard, you must uninstall that version before installing Version 16.1.2 or later.

AUTOSAR Round Trip: Automate model additions for update and merge of ARXML files

Simulink® provides the ability to merge AUTOSAR authoring tool changes into a model as part of round-trip iterations. R2016a adds more automation and better reporting to the merge process. The software:

  • Automates Simulink block additions. In the updated model, green highlighting identifies the added blocks.

  • Lists required Simulink block deletions. In the updated model, red highlighting identifies the blocks to delete.

For more information, see Import AUTOSAR Software Component Updates.

Note

This capability is available to R2015b Embedded Coder customers by installing the R2015b Embedded Coder Support Package for AUTOSAR Standard, Version 15.2.2 or later.

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

Variants in AUTOSAR component modeling

R2016a enhances AUTOSAR component modeling with modeling support for:

  • AUTOSAR variants in ports and runnables

  • AUTOSAR variants in array sizes

AUTOSAR variants in ports and runnables

AUTOSAR software components can use variants to enable or disable AUTOSAR elements, such as ports and runnables, based on defined conditions. Embedded Coder now supports modeling AUTOSAR variants in ports and runnables.

In Simulink, you can:

  • Import AUTOSAR ports and runnables with variation points.

    The arxml importer creates the required model elements, including workspace variables for modeling with variants, Variant Sink blocks, and Variant Source blocks to propagate variant conditions.

  • Model AUTOSAR ports and runnables with variation points.

    • To define variant condition logic, use Simulink.Variant data objects.

    • To represent AUTOSAR system constants, use AUTOSAR.Parameter data objects with storage class SystemConstant.

    • To propagate variant conditions for the AUTOSAR elements, use Variant Sink and Variant Source blocks.

  • Run validation on the AUTOSAR configuration. The validation software checks that variant conditions on Simulink blocks match the designed behavior from the imported arxml code.

  • Export previously imported AUTOSAR ports and runnables with variation points.

For more information, see Model AUTOSAR Variants and Configure AUTOSAR Variants in Ports and Runnables.

AUTOSAR variants in array sizes

AUTOSAR software components can flexibly specify the dimensions of an AUTOSAR element, such as a port, by using a symbolic reference to a system constant. The system constant defines the array size of the port data type.

Embedded Coder now supports modeling AUTOSAR variants in array sizes.

In Simulink, you can:

  • Import AUTOSAR elements with variant array sizes.

    • The arxml importer creates the required model elements, including AUTOSAR.Parameter data objects with storage class SystemConstant, to represent the array size values.

    • Each block created by the importer to represent an AUTOSAR element with variant array sizes references AUTOSAR.Parameter data objects to define its dimensions.

  • Model AUTOSAR elements with variant array sizes.

    • Create blocks that represent AUTOSAR elements.

    • To represent array size values, add AUTOSAR.Parameter data objects with storage class SystemConstant.

    • To specify array size for an AUTOSAR element, reference an AUTOSAR.Parameter data object.

  • Modify array size values in system constants and simulate the model, without regenerating code for simulation.

  • Generate C and arxml code with symbols corresponding to variant array sizes.

For more information, see Variants in Array Sizes and Configure AUTOSAR Variants in Array Sizes.

AUTOSAR DataReceivedEvents for receiver ports in ImplicitReceive data access mode

R2016a enhances AUTOSAR sender-receiver modeling with support for DataReceivedEvents for receiver ports in ImplicitReceive data access mode. Previously, the software supported DataReceivedEvents for receiver ports only in ExplicitReceive, QueuedExplicitReceive, and EndToEndRead data access modes.

Note

This capability is available to R2015b Embedded Coder customers by installing the R2015b Embedded Coder Support Package for AUTOSAR Standard, Version 15.2.0 or later.

AUTOSAR LiteralPrefix for enumerations in IncludedDataTypeSets

The arxml importer can now import AUTOSAR LiteralPrefixs defined in IncludedDataTypeSets. The software adds LiteralPrefixs to Simulink enumerated data types generated by the importer.

Note

This capability is available to R2015b Embedded Coder customers by installing the R2015b Embedded Coder Support Package for AUTOSAR Standard, Version 15.2.2 or later.

Programmatic validation and synchronization of AUTOSAR model configurations

R2016a adds 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.

Note

This capability is available to R2015b Embedded Coder customers by installing the R2015b Embedded Coder Support Package for AUTOSAR Standard, Version 15.2.1 or later.

AUTOSAR arxml round trip

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

  • CompuMethods with LINEAR and TEXTTABLE COMPU-SCALEs

  • PredefinedVariants import and export

  • Enhanced control of AUTOSAR package path specification

CompuMethods with LINEAR and TEXTTABLE COMPU-SCALEs

In R2016a, you can import and export a CompuMethod that uses LINEAR and TEXTTABLE scaling. Importing application data types that reference CompuMethods of category SCALE_LINEAR_AND_TEXTTABLE creates Simulink.NumericType or Simulink.AliasType data objects in the Simulink workspace. In Simulink, you can modify the LINEAR scaling for the CompuMethods. The TEXTTABLE scaling is read-only.

For more information, see CompuMethod Categories for Data Types and Modify Linear Scaling for SCALE_LINEAR_AND_TEXTTABLE CompuMethod.

Note

This capability is available to R2015b Embedded Coder customers by installing the R2015b Embedded Coder Support Package for AUTOSAR Standard, Version 15.2.1 or later.

PredefinedVariants import and export

For an AUTOSAR software component that contains variation points, to define the values that control variation points, you can use the following AUTOSAR elements:

  • SwSystemconst — Defines a system constant that serves as an input to control a variation point.

  • SwSystemconstantValueSet — Specifies a set of system constant values.

  • PredefinedVariant — Describes a combination of system constant values, among potentially multiple valid combinations, to apply to an AUTOSAR software component.

Previously, when creating a model from arxml code, the arxml importer did not provide a way to specify a PredefinedVariant or SwSystemconstantValueSets as a basis for resolving variation points in the model.

In R2016a, you can resolve variation points in an AUTOSAR software component at model creation time. Specify a PredefinedVariant or SwSystemconstantValueSets with which the importer can initialize SwSystemconst data.

After model creation, you can run simulations and generate code based on the combination of variation point input values that you specified.

For more information, see Model AUTOSAR Variants and Control AUTOSAR Variants with Predefined Value Combinations.

Enhanced control of AUTOSAR package path specification

In R2016a, if you modify an AUTOSAR package path, and if packageable elements of that category are affected, you can:

  • Move the elements from the existing package to the new package.

  • Set the new package path without moving the elements.

If you modify a package path in the Configure AUTOSAR Interface dialog box, and if packageable elements of that category are affected, a dialog box opens with control options. If you programmatically modify a package path, you can use the MoveElements property to specify handling of affected elements.

For more information, see Control AUTOSAR Elements Affected by Package Path Modifications.

Note

This capability is available to R2015b Embedded Coder customers by installing the R2015b Embedded Coder Support Package for AUTOSAR Standard, Version 15.2.0 or later.

Improved AUTOSAR library support for Mfx functions

As of R2016a, the AUTOSAR 4.0 code replacement library (CRL) replaces abs, saturate, min, and max function calls that involve operands with equal slope and bias with calls to corresponding Mfx functions.

Calls ToReplace
Mfx_Absabs with operands that have equal slope
Mfx_Limitsaturate with operands that have equal slope and bias
Mfx_Maxmax with operands that have equal slope and bias
Mfx_Minmin with operands that have equal slope and bias

For more information about using the AUTOSAR 4.0 CRL, see Code Generation with AUTOSAR Library.

AUTOSAR target no longer supports building wrapper subsystem as AUTOSAR SW-Component

In R2016a, the AUTOSAR target removes support for using right-click builds to build a wrapper subsystem that models an AUTOSAR SW-Component. In R2013b, a top model approach to modeling multirunnable AUTOSAR SW-Components replaced the wrapper subsystem approach. For more information, see Multi-Runnable Software Components and Configure AUTOSAR Multiple Runnables.

Compatibility Considerations

In R2016a, if you try to configure and build an AUTOSAR SW-Component by using a wrapper subsystem, the software issues an error message. The message states that configuring a subsystem as an AUTOSAR SW-Component is not supported.

To convert subsystem multirunnables to top model multirunnables, use the subsystem-to-model conversion techniques described in Convert a Subsystem to a Referenced Model. After the basic conversion, you must manually reestablish some AUTOSAR configuration information from the subsystem configuration in the new configuration.

AUTOSAR schemas 4.2.2 and 3.2.2

Version 16.1.1 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 16.1.5 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.1.7, 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.1.8, 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.1.8, 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 arxml importer enhancements

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

Version 16.1.2 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 16.1.3 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 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.

  • The importer now correctly handles system constant expressions for variants that span multiple lines. Previously, the importer threw an error if a variant expression was not on a single line.

Version 16.1.4 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.1.6 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 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
  • 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.1.7 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.1.8 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.1.1 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 16.1.2 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 16.1.3 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 16.1.4 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.1.6 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.1.7 provides the following arxml export enhancements:

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

Version 16.1.3 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 16.1.6 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.1.6 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.

Version 16.1.8 provides the following AUTOSAR modeling enhancement:

AUTOSAR validation no longer errors out when a model contains ModeReceive ports and NvData ports. Previously, validation generated the following error:

Did not recognize DataAccessMode ModeReceive