Confidential Prerelease Documentation — Subject to Nondisclosure Agreement

R2014b

New Features, Compatibility Considerations

Support package for AUTOSAR Standard

Beginning in R2014b, the Embedded Coder® Support Package for AUTOSAR Standard provides add-on support for the AUTOSAR standard. The support package allows you to perform a wide range of AUTOSAR-related workflows in Simulink®, including:

  • Create and modify a Simulink model representation of an AUTOSAR software component

  • Model AUTOSAR elements

  • Generate arxml descriptions and AUTOSAR-compatible C code from a model

To download and install the support package, perform the steps described in Install Support Package for AUTOSAR Standard.

For more information, see Embedded Coder Support Package for AUTOSAR Standard.

Compatibility Considerations

AUTOSAR models and scripts that worked without a support package before R2014b now require Embedded Coder Support Package for AUTOSAR Standard. Install the support package before working with AUTOSAR models and scripts.

AUTOSAR targeting updates including 4.1 ARXML, client/server with Simulink Functions, multi-instance components, and IFL/IFX libraries

R2014b provides many enhancements to AUTOSAR code generation and Simulink modeling of AUTOSAR elements. Highlights include:

  • Support for AUTOSAR Release 4.1, including:

    • AUTOSAR 4.1 (schema version 4.1.1) arxml and C code generation

    • AUTOSAR 4.1 initialization events

    • AUTOSAR 4.1 provide-require ports

  • Ability to model AUTOSAR clients and servers in Simulink, using Simulink Function and Function Caller blocks.

  • Ability to model multi-instance AUTOSAR software components (SWCs) in Simulink, using the Reusable function setting of the model parameter Code interface packaging.

  • AUTOSAR code replacement library support for:

    • Floating-point interpolation (IFL) and fixed-point interpolation (IFX) library routines.

    • Functions that perform a multiplication, and then a division operation in sequence.

    • Addition and subtraction operator replacements for cast-after-operation algorithms.

For more information about AUTOSAR-related enhancements in R2014b, see:

AUTOSAR client and server modeling

Beginning in R2014b, you can model AUTOSAR clients and servers in Simulink for simulation and code generation.

  • Use Simulink Function blocks at the root level of a model to model AUTOSAR servers.

  • Use Function Caller blocks to model AUTOSAR client invocations.

  • Use the top-model export-functions modeling style to create interconnected Simulink functions, function-calls, and root model inports and outports.

For more information, see Client-Server Interface and Configure AUTOSAR Client-Server Communication.

Global From and Goto blocks for AUTOSAR modeling

Beginning in R2014b, you can use global From and Goto blocks in a model configured for AUTOSAR. With From and Goto blocks, you can pass a signal from one block to another without actually connecting them. You can model AUTOSAR runnables with more flexibility and cleaner separation of components and interfaces.

AUTOSAR IRV branch from outport signal allowed outside runnable

In previous releases, if you wanted to branch an AUTOSAR runnable output signal to an AUTOSAR inter-runnable variable (IRV) and a Simulink model root outport, AUTOSAR code generation supported only branching inside the runnable.

Beginning in R2014b, AUTOSAR code generation supports branching outside the runnable. This modeling pattern can potentially generate more efficient C code, for example, with fewer global variables and fewer block I/O buffers.

The following guidelines and constraints apply to the new modeling pattern:

  • You can branch a runnable output signal to only one root outport outside a runnable boundary.

  • When a runnable output signal branches to an IRV and a root outport outside the runnable subsystem:

    • Only Goto and From blocks are allowed between the source and the destination of the signal.

    • You cannot conditionally write to the IRV or root outport.

  • When a runnable output signal does not branch, only Goto/From and Merge blocks are allowed between the source and the destination of the signal.

Constant sample time limitation for AUTOSAR models

Previously, for models using the AUTOSAR target, the compiler reported a warning if you configured a root-level Outport block to inherit a constant sample time from its sources. The compiler then set the sample time of the root-level Outport block to the fundamental rate of the model. In R2014b, this warning becomes an error.

AUTOSAR help navigation enhancements

To make it easier to find AUTOSAR topics within MATLAB® documentation, R2014b introduces the following AUTOSAR documentation enhancements:

  • New AUTOSAR landing page in MATLAB Help — Encapsulates the entire Embedded Coder® AUTOSAR workflow.

  • New Embedded Coder AUTOSAR book in PDF format — Collects AUTOSAR concepts, examples, how-to topics, and reference material in a PDF file to help Simulink users learn how to model AUTOSAR components.

Support for AUTOSAR Release 4.1

AUTOSAR 4.1 ARXML and C code generation

The software now supports AUTOSAR Release 4.1 (schema version 4.1.1) for import and export of arxml files and generation of AUTOSAR-compatible C code.

If you import schema version 4.1.1 arxml code into Simulink, the arxml importer detects and uses the schema version, and sets the schema version parameter in the model to 4.1.

For information on specifying an AUTOSAR schema version for code generation, see Select an AUTOSAR Schema.

AUTOSAR 4.1 InitEvent support

Beginning in R2014b, you can model AUTOSAR initialization events (InitEvents), as defined in AUTOSAR schema version 4.1. You can use an InitEvent to designate an AUTOSAR runnable as an initialization runnable, and then map an initialization function to the runnable.

In previous releases, you could use AUTOSAR mode management to set up software component initialization. For example, you could define a ModeDeclarationGroup with a mode for setting up and initializing a software component. InitEvent provides a potentially lighter-weight alternative to the mode-based approach.

If you import arxml code that describes a runnable with an InitEvent, the arxml importer configures the runnable in Simulink as an initialization runnable.

Alternatively, you can configure a runnable to be the initialization runnable in Simulink. For more information, see Configure AUTOSAR Initialization Runnable.

AUTOSAR 4.1 provide-require port support

Beginning in R2014b, you can model AUTOSAR provide-require ports (PRPorts), as defined in AUTOSAR schema version 4.1. PRPorts are a third type of port, in addition to provide ports (PPorts) and require ports (RPorts), that can be associated with an AUTOSAR sender-receiver interface. For example, you can:

  • Map a Simulink inport/outport pair to a data element of an AUTOSAR provide require port. Generated code complies with Simulink and AUTOSAR semantics.

  • Import AUTOSAR provide-require ports for sender-receiver interfaces from ARXML files.

  • Export AUTOSAR provide-require ports to ARXML files.

For more information, see Configure AUTOSAR Provide-Require Port.

Multi-instance AUTOSAR atomic software components

In previous releases, AUTOSAR software components (SWCs) modeled in Simulink were single-instance. Beginning in R2014b, you can model multi-instance AUTOSAR SWCs in Simulink. For example, you can:

  • Map and configure a Simulink model as a multi-instance AUTOSAR SWC, and validate the configuration.

  • Generate C code with reentrant runnable functions and multi-instance RTE API calls.

  • Verify AUTOSAR multi-instance C code with SIL and PIL simulations.

  • Import and export multi-instance AUTOSAR SWC description XML files.

For more information and limitations, see Multi-Instance Atomic Software Components.

AUTOSAR arxml import and export

AUTOSAR R4.x compliant data type support

AUTOSAR data types workflow improvements

R2014b provides enhanced AUTOSAR Release 4.x compliant data type support.

  • For round-trip workflows involving AUTOSAR components originated outside MATLAB, the arxml importer and exporter preserve data type information and mapping for each imported AUTOSAR data type.

  • For AUTOSAR components originated in Simulink, the software generates AUTOSAR application, implementation, and base types to preserve the information contained within Simulink data types.

For more information, see Release 4.x Data Types.

Application data type export control

For AUTOSAR data types created in Simulink, by default, the software generates application base types only for fixed-point data types and enumerated date types with storage types.

Beginning in R2014b, if you want to override the default behavior for generating application types, you can configure the arxml exporter to generate an application type, along with the implementation type and base type, for each exported AUTOSAR data type. For more information, see Control Application Data Type Generation.

DataTypeMappingSet package and name control

In previous releases, for AUTOSAR software components created in Simulink, users did not have control over the AUTOSAR package and short name exported for AUTOSAR data type mapping sets. The arxml exporter generated the short name DataTypeMappingSet for every data type mapping set. The exporter used a rule-based package path that was not configurable in Simulink.

Beginning in R2014b, you can control the package and short-name for data type mapping sets. To configure the data type mapping set package for export, set the XMLOptions property DataTypeMappingPackage using the Configure AUTOSAR Interface dialog box or the AUTOSAR property set function. For example:

The exported arxml uses the specified package. The default mapping set short-name is the component name ASWC prefixed to DataTypeMappingsSet. You can specify a short name for a data type mapping set using the AUTOSAR property function addPackageableElement.

For more information, see Configure DataTypeMappingSet Package and Name.

Data initialization with ApplicationValueSpecification

AUTOSAR Release 4.0 introduced application data types and implementation data types, which represent the application-level physical attributes and implementation-level attributes of AUTOSAR data types. To initialize AUTOSAR data objects typed by application data type, R4.1 requires AUTOSAR application value specifications (ApplicationValueSpecifications).

Beginning in R2014b, for AUTOSAR data initialization with ApplicationValueSpecification, Embedded Coder provides the following support:

  • The arxml importer uses ApplicationValueSpecifications found in imported arxml files to initialize the corresponding data objects in the Simulink model.

  • If you select AUTOSAR schema 4.0 or later for a model that contains AUTOSAR data typed by application data type, code generation exports arxml code that uses ApplicationValueSpecifications to specify initial values for AUTOSAR data.

AUTOSAR CompuMethod control

CompuMethod direction for linear functions

In previous releases, Embedded Coder software imported AUTOSAR computational methods (CompuMethods) described in arxml code and preserved them across round-trips between an AUTOSAR authoring tool (AAT) and Simulink. For designs originated in Simulink, the arxml exporter created schema-compliant CompuMethods, but did not allow users control over CompuMethod attributes, including the direction of CompuMethod conversion between internal and physical representations of a value. For CompuMethods originated in Simulink, the exporter generated only the forward, internal-to-physical direction.

Beginning in R2014b, you can control how conversion direction is described in exported CompuMethods. Using either the Configure AUTOSAR Interface dialog box or the AUTOSAR property set function, you can specify one of the following CompuMethod direction values:

  • InternalToPhys (default) — Generate CompuMethod sections for conversion of internal values into their physical representations.

  • PhysToInternal — Generate CompuMethod sections for conversion of physical values into their internal representations.

  • Bidirectional — Generate CompuMethod sections for both internal-to-physical and physical-to-internal conversion directions.

For more information, see CompuMethod Direction for Linear Functions.

CompuMethod generated for each ApplicationDataType

In previous releases, the arxml exporter preserved AUTOSAR computational methods (CompuMethods) that you imported into Simulink, but for designs originated in Simulink, generated CompuMethods only for fixed point application types.

Beginning in R2014b, the exporter generates CompuMethods for every primitive application type. Measurement and calibration tools can monitor and interact with more application data. For more information, see CompuMethod Categories for Data Types.

Unit reference generated for each CompuMethod

In previous releases, exported CompuMethods did not contain unit references. Beginning in R2014b:

  • The arxml importer preserves unit and physical dimension information found in imported CompuMethods. The software preserves CompuMethod unit and physical dimension information across round-trips between an AUTOSAR authoring tool (AAT) and Simulink.

  • For designs originated in Simulink, the exporter generates a unit reference for each CompuMethod.

Providing a unit for each exported CompuMethod helps support measurement and calibration tool use of exported AUTOSAR data. For more information, see CompuMethod Unit References.

Rational function CompuMethod for dual-scaled parameter

R2014b provides greater control over the AUTOSAR CompuMethods generated for AUTOSAR dual-scaled parameters. For an AUTOSAR dual-scaled parameter, which stores two scaled values of the same physical value, the software generates the CompuMethod category RAT_FUNC. The computation method can be a first-order rational function. For more information, see Rational Function CompuMethod for Dual-Scaled Parameter.

Improved AUTOSAR package configuration

In previous releases, the arxml exporter generated a fixed file and package structure for packaging AUTOSAR elements. Beginning in R2014b, Embedded Coder software provides more flexible configuration and management of AUTOSAR packages. For example:

  • AUTOSAR packages and their elements now are fully preserved across round-trips between an AUTOSAR authoring tool (AAT) and Simulink.

  • AUTOSAR XML options in Simulink include ten new packaging parameters (XmlOptions properties). You can now easily group AUTOSAR elements of the following categories into packages:

    • Application data types (schema 4.x)

    • Software base types (schema 4.x)

    • Data type mapping sets (schema 4.x)

    • Constants and values

    • Physical data constraints (referenced by application data types or data prototypes)

    • System constants (schema 4.x)

    • Software address methods

    • Mode declaration groups

    • Computational methods

    • Units and unit groups (schema 4.x)

For more information, see Configure AUTOSAR Package Structure.

AUTOSAR calibration component export

In previous releases, the software exported an AUTOSAR calibration component (ParameterSwComponent) only if it had been created in an AUTOSAR authoring tool (AAT) and imported into Simulink from an arxml file.

Beginning in R2014b, the software can export an AUTOSAR calibration component originated in Simulink. To configure AUTOSAR parameters for export in a calibration component, use the custom storage class (CSC) CalPrm with AUTOSAR.Parameter data objects. For more information, see Model AUTOSAR Calibration Parameters and Configure AUTOSAR Calibration Component.

Simulink Min and Max mapping to AUTOSAR physical data constraints

Beginning in R2014b, in models configured for AUTOSAR, the software maps minimum and maximum values for Simulink data to the corresponding physical constraint values for AUTOSAR application data types. Specifically:

  • If you import ARXML files, PhysConstr values on ApplicationDataTypes in the ARXML files are imported to Min and Max values on the corresponding Simulink data objects and root-level I/O signals.

  • When you export ARXML from a model, the Min and Max values specified on Simulink data objects and root-level I/O signals are exported to the corresponding ApplicationDataType PhysConstrs in the ARXML files.

AUTOSAR addPackageableElement replaces add*Interface functions

R2014b introduces a new AUTOSAR property function, addPackageableElement, for adding packaged elements to the AUTOSAR configuration of a model. The function syntax is:

addPackageableElement(arProps,category,package,name)
addPackageableElement(arProps,category,package,name,property,value)

See the addPackageableElement reference page. For an example of using addPackageableElement as part of configuring a DataTypeMappingSet element for an AUTOSAR model, see DataTypeMappingSet package and name control.

Compatibility Considerations

Using the function addPackageableElement with element categories ModeSwitchInterface or SenderReceiverInterface replaces the following equivalent AUTOSAR property functions:

  • addMSInterface(arProps,qName,property,value)

  • addSRInterface(arProps,qName,property,value)

If an existing script calls addMSInterface or addSRInterface, replace the call with an equivalent call to addPackageableElement. For example, consider the addSRInterface call in the following code:

open_system('rtwdemo_autosar_multirunnables');
arProps=autosar.api.getAUTOSARProperties('rtwdemo_autosar_multirunnables');
addSRInterface(arProps,'/pkg/if/Interface3','IsService',true);
ifPaths=find(arProps,[],'SenderReceiverInterface',...
  'IsService',true,'PathType','FullyQualified')

Replace the addSRInterface call with an equivalent addPackageableElement call. For example:

open_system('rtwdemo_autosar_multirunnables');
arProps=autosar.api.getAUTOSARProperties('rtwdemo_autosar_multirunnables');
addPackageableElement(arProps,'SenderReceiverInterface','/pkg/if','Interface3',...
  'IsService',true);
ifPaths=find(arProps,[],'SenderReceiverInterface',...
  'IsService',true,'PathType','FullyQualified')