Confidential Prerelease Documentation — Subject to Nondisclosure Agreement
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.
Diagnostic Event Manager (Dem) blocks — Calls to Dem service interfaces, including CallbackEventStatusChangeCaller, DiagnosticInfoCaller, and DiagnosticMonitorCaller.
NVRAM Manager (NvM) blocks — Calls to NvM service interfaces, including NvMAdminCaller and NvMServiceCaller.
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.
R2016b enhances AUTOSAR calibration parameter and data modeling with additional support for:
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.
To support mapping a Simulink lookup table to an AUTOSAR
parameter, you can now create AUTOSAR calibration parameters (ParameterDataPrototype
s)
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 software components use software record layouts (SwRecordLayout
s)
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 SwRecordLayout
s
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 SwRecordLayout
s are
preserved and subsequently exported in arxml
code.
If you create your AUTOSAR model in Simulink,
you can import reference definitions of SwRecordLayout
s
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 software components use software address methods (SwAddrMethod
s)
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 SwAddrMethod
s 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 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 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.
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.
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 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.
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.
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.
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
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.
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.
arxml
filesThe 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.
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.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.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.
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.