Confidential Prerelease Documentation — Subject to Nondisclosure Agreement
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.
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.
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:
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.
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.
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.
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.
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.
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.
Beginning in R2014b, you can model AUTOSAR initialization events
(InitEvent
s), 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.
Beginning in R2014b, you can model AUTOSAR provide-require ports
(PRPort
s), as defined in AUTOSAR schema version
4.1. PRPort
s are a third type of port, in addition
to provide ports (PPort
s) and require ports (RPort
s),
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.
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.
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.
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.
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.
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 (ApplicationValueSpecification
s).
Beginning in R2014b, for AUTOSAR data initialization with ApplicationValueSpecification
, Embedded
Coder provides
the following support:
The arxml
importer uses ApplicationValueSpecification
s
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 ApplicationValueSpecification
s
to specify initial values for AUTOSAR data.
In previous releases, Embedded
Coder software imported AUTOSAR
computational methods (CompuMethod
s) 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 CompuMethod
s, but did
not allow users control over CompuMethod
attributes,
including the direction of CompuMethod
conversion
between internal and physical representations of a value. For CompuMethod
s
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 CompuMethod
s. 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.
In previous releases, the arxml
exporter
preserved AUTOSAR computational methods (CompuMethod
s)
that you imported into Simulink, but for designs originated in Simulink,
generated CompuMethod
s only for fixed point application
types.
Beginning in R2014b, the exporter generates CompuMethod
s
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.
In previous releases, exported CompuMethod
s
did not contain unit references. Beginning in R2014b:
The arxml
importer preserves unit
and physical dimension information found in imported CompuMethod
s.
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.
R2014b provides greater control over the AUTOSAR CompuMethod
s
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.
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.
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.
Min
and Max
mapping to AUTOSAR physical data constraintsBeginning 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 ApplicationDataType
s 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
PhysConstr
s
in the ARXML files.
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.
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')