Confidential Prerelease Documentation — Subject to Nondisclosure Agreement
R2015b extends AUTOSAR schema support to schema 4.2 (revision
4.2.1) and schema 4.1 (revision 4.1.3). For a detailed list of AUTOSAR
schemas supported for import and export of arxml
files
and generation of AUTOSAR-compatible C code, see Select
an AUTOSAR Schema.
R2015b provides many other enhancements to Simulink® modeling of AUTOSAR elements and AUTOSAR code generation. For more information, see:
Under Model Architecture and Design:
Under Code Generation:
R2015b enhances AUTOSAR sender-receiver modeling with support for:
IsUpdated
API for receiver ports
Data element invalidation policies on sender ports
End-to-end protection for sender and receiver ports
DataReceiveErrorEvent
for receiver
ports
Rte_IWriteRef
for sender ports
AUTOSAR defines quality of service attributes, such as ErrorStatus
and IsUpdated
,
for sender-receiver interfaces. R2015b adds support for the AUTOSAR IsUpdated
attribute
and API. The IsUpdated
attribute allows an AUTOSAR
receiver to detect when a receiver port data element has received
data since the last read occurred. When data is idle, the receiver
can save computational resources. You can:
Import an AUTOSAR receiver port for which IsUpdated
service
is configured.
Use Simulink to configure an AUTOSAR receiver
port for IsUpdated
service.
Generate C and arxml
code for an
AUTOSAR receiver port for which IsUpdated
service
is configured.
For more information, see Configure AUTOSAR Receiver Port for IsUpdated Service.
AUTOSAR defines an invalidation mechanism for data elements on AUTOSAR sender ports. To protect downstream data consumers from receiving invalid data, you can define an invalidation policy for a sender port data element. R2015b adds support for data element invalidation policies on sender ports. You can:
Import AUTOSAR sender port data elements for which an invalidation policy is configured.
Use Simulink to configure an invalidation policy for AUTOSAR sender port data elements.
Generate C and arxml
code for AUTOSAR
sender port data elements for which an invalidation policy is configured.
For more information, see Configure AUTOSAR Sender Port for Data Element Invalidation.
AUTOSAR end-to-end (E2E) protection for sender and receiver ports is based on the E2E library. E2E is a C library that you can use to transmit data securely between AUTOSAR components. End-to-end protection adds additional information to an outbound data packet. The component receiving the packet can then verify independently that the received data packet matches the sent packet. Potentially, the receiving component can detect errors and take action.
For easier integration of AUTOSAR generated code with AUTOSAR E2E solutions, R2015b adds support for AUTOSAR E2E protection. You can:
Import AUTOSAR sender port and receiver ports for which E2E protection is configured.
Use Simulink to configure an AUTOSAR sender or receiver port for E2E protection.
Generate C and arxml
code for AUTOSAR
sender and receiver ports for which E2E protection is configured.
For more information, see Configure AUTOSAR S-R Interface Port for End-To-End Protection.
In AUTOSAR sender-receiver communication between software components,
the run-time environment (RTE) raises a DataReceiveErrorEvent
when
the communication layer reports an error in data reception by the
receiver component. For example. the event can indicate that the sender
component failed to reply within an aliveTimeout
limit,
or that the sender component sent invalid data.
R2015b adds support for creating DataReceiveErrorEvent
s
in AUTOSAR receiver components. You can:
Import an AUTOSAR DataReceiveErrorEvent
definition.
Use Simulink to define a DataReceiveErrorEvent
.
Generate arxml
code for AUTOSAR
receiver ports for which a DataReceiveErrorEvent
is
configured.
For more information, see Configure AUTOSAR Receiver Port for DataReceiveErrorEvent.
In R2015b, you can leverage the Rte_IWriteRef
API
(AUTOSAR Release 4.x) when writing to AUTOSAR sender ports. Rte_IWriteRef
returns
a reference to the write data, which the runnable code can use to
directly update the corresponding data elements. The API provides
constant execution time for writes of any data element type, including
structure and matrix data.
If you want AUTOSAR sender port data to be written using Rte_IWriteRef
rather
than Rte_IWrite
, configure the corresponding Simulink root
outport for ImplicitSendByRef
access. For
example, suppose that you open the example model rtwdemo_autosar_counter
,
and change the data access mode of its root outport, Output
,
from ImplicitSend
to ImplicitSendByRef
.
When you generate code, in rtwdemo_autosar_counter.c
,
the model step function uses Rte_IWriteRef
to
write the sender port data.
void Runnable_Step(void) { ... int32_T *tmp; tmp = Rte_IWriteRef_Runnable_Step_Output_Output(); ... /* Outport: '<Root>/Output' incorporates: * Gain: '<S1>/Gain' * Inport: '<Root>/Input' ... */ *tmp = Rte_Prm_rCounter_K() * Rte_IRead_Runnable_Step_Input_Input(); ... }
R2015b enhances AUTOSAR client-server modeling with support for:
AUTOSAR error status
AUTOSAR NVRAM memory services
In R2015b, you can model AUTOSAR application error status for client-server error handling. In Simulink, you can:
Import arxml
code that implements
client-server error handling.
Configure error handling for a client-server interface.
Generate C and arxml
code for client-server
error handling.
For more information, see Configure AUTOSAR Client-Server Error Handling.
R2015b provides improved support for AUTOSAR nonvolatile RAM
memory (NvM) services, including the NvM APIs ReadBlock
, WriteBlock
,
and RestoreBlockDefaults
. On ECU hardware startup
or shutdown, or in response to an explicit read or write request,
NvM services store data needed by the AUTOSAR software component.
To better support NvM services, Embedded
Coder®:
Imports and exports the void
pointer
data type that the NvM APIs use.
Imports and exports asynchronous-server call points
for calling the NvM APIs. The arxml
importer creates Function
Caller blocks to model the call points.
Enforces constraints for modeling the RAM block required for NvM API calls. A data store memory block models the RAM block, and must directly connect to the Function Caller block.
Generates C code that provides the RAM block to the NvM API calls without creating a local buffer.
Here is an example of Data Store Read and Function
Caller blocks that model an asynchronous call to the NvM WriteBlock
service.
The generated C code calls the NvM WriteBlock
service
with the global RAM block as an argument.
appErrType = Rte_Call_WriteBlock_client_WriteBlock(Rte_Pim_myDSM());
Enforcing the new modeling constraints can generate errors for models that previously did not get errors. For example, if a Function Caller block configured to call an AUTOSAR NvM API does not directly connect to a data store block, Embedded Coder generates an error.
In R2015b, you can model AUTOSAR nonvolatile (NV) data communication, as defined in AUTOSAR Release 4.0 or later. To implement NV data communication, AUTOSAR software components define provide and require ports that send and receive NV data. In Simulink, you can:
Import AUTOSAR NV data communication definitions from arxml
code.
Create AUTOSAR NV data communication elements, including an NV interface and ports, and map Simulink inports and outports to AUTOSAR NV ports.
Generate C and arxml
code for AUTOSAR
NV data communication elements.
To create NV data communication elements in Simulink:
Open the Configure AUTOSAR Interface dialog box and select AUTOSAR Properties.
Select NV Interfaces. Click the Add icon to create a new NV data
interface. Specify its name and the number of associated NV data elements.
Select and expand the new NV interface. Select Data Elements, and modify the data element attributes.
In the left-hand pane of the Configure AUTOSAR Interface dialog box, under AUTOSAR, select AtomicComponents. Expand AtomicComponents and select an AUTOSAR component. Expand the component.
Select and use the NvReceiverPorts, NvSenderPorts, and NvSenderReceiverPorts views to add the NV ports you require. For each NV port, select the NV interface you created.
Switch to the Simulink mapping view. Select Simulink-AUTOSAR Mapping.
Select and use the Inports and Outports views to map Simulink inports and outports to AUTOSAR NV ports. For each inport or outport, select an AUTOSAR port, data element, and data access mode.
To programmatically configure AUTOSAR NV data communication elements, use the AUTOSAR property and mapping functions. For example, the following MATLAB® code adds an AUTOSAR NV data interface and an NV receiver port to an open model. It then maps a Simulink inport to the AUTOSAR NV receiver port.
% Add AUTOSAR NV data interface myNvInterface with NV data element DE3 arProps = autosar.api.getAUTOSARProperties('rtwdemo_autosar_multirunnables_nv'); addPackageableElement(arProps,'NvDataInterface','/pkg/if','myNvInterface'); add(arProps,'myNvInterface','DataElements','DE3'); % Add AUTOSAR NV receiver port NvRPort, associated with myNvInterface add(arProps,'ASWC','NvReceiverPorts','NvRPort','Interface','myNvInterface'); % Map Simulink inport NvRPort_DE3 to AUTOSAR port/element pair NvRPort and DE3 slMap = autosar.api.getSimulinkMapping('rtwdemo_autosar_multirunnables_nv'); mapInport(slMap,'NvRPort_DE3','NvRPort','DE3','ImplicitReceive');
R2015b enhances AUTOSAR component behavior modeling with support for:
IRVs in feedback loops
Constant memory with const
or volatile
type
qualifiers
Simulink modeling now supports an AUTOSAR inter-runnable
feedback loop, that is, AUTOSAR runnables accessing an AUTOSAR inter-runnable
variable (IRV) with both read and write access. For example, in the
figure, Runnable2_subsystem
can read and write irv1
.
(Signal irv1
is shown in Highlight
Signal to Source view.) In previous releases, the software
flagged an error for this modeling pattern.
When modeling an AUTOSAR constant or static memory variable
(AUTOSAR schema 4.x), you can now generate const
, volatile
,
or const volatile
qualifiers in C code to control
data access.
You model AUTOSAR constant memory and static memory using AUTOSAR4.Parameter
and AUTOSAR4.Signal
data
objects with a global storage class. Optionally, you can create custom
storage classes and memory sections to customize the code generated
for the global memory data, as described in Design
Custom Storage Classes and Memory Sections. The AUTOSAR4 data
class package now provides CONST, VOLATILE, and CONST_VOLATILE memory
section definitions for configuring the const
, volatile
,
and const volatile
qualifiers. You can reference
the new memory-section values in cscdesigner
to
set up memory sections, and then reference the values from within AUTOSAR4.Parameter
and AUTOSAR4.Signal
data
objects.
R2015b provides the ability to model common axis (COM_AXIS) lookup tables for AUTOSAR applications. You can:
Import AUTOSAR calibration parameters of category
CURVE, MAP, CUBOID, and COM_AXIS from arxml
files
into Simulink. The importer creates corresponding model content,
including n-D Lookup Table blocks and parameter objects.
Use Simulink to create a COM_AXIS table and configure it for AUTOSAR run-time calibration.
Export COM_AXIS lookup table information in arxml
code,
including calibration parameters of category CURVE, MAP, CUBOID, and
COM_AXIS.
For more information, see Calibration Parameters for COM_AXIS Lookup Tables and Configure COM_AXIS Lookup Table for Measurement and Calibration.
R2015b enhances the AUTOSAR arxml
round-trip
workflow with support for:
Editable AUTOSAR display format for calibration
Configurable export of AUTOSAR internal data constraints
AUTOSAR reference bases
AUTOSAR-typed per-instance memory import
AUTOSAR display format specifications control the width and precision display for calibration and measurement data. In R2015b, you can import and export AUTOSAR display format specifications, and edit the specifications in Simulink. You can specify display format for the following AUTOSAR data objects and elements:
Signal and parameter data objects (AUTOSAR and AUTOSAR4 classes)
Inter-runnable variables
Sender-receiver interface data elements
Client-server interface operation arguments
CompuMethods
For more information, see Configure AUTOSAR Display Format for Measurement and Calibration.
In releases before R2015b, you could not control the export
or packaging of AUTOSAR internal data constraints from Simulink.
Code generation exported internal data constraints to AUTOSAR package DataConstrs
at
a fixed location under the AUTOSAR datatype package.
In R2015b, you can enable or disable export of AUTOSAR internal data constraints. Export now is disabled by default. Optionally, you can specify the name and path of an AUTOSAR package into which internal data constraints are exported. For more information, see Configure AUTOSAR Internal Data Constraints Export.
Embedded
Coder now can import AUTOSAR reference bases from arxml
code
into a model. Reference bases, which are defined in AUTOSAR Release
4.0, allow the use of relative paths in AUTOSAR specifications of
packageable elements. In this arxml
code example,
reference base CMs
resolves to /pkg/Components/MyComponent/CompuMethods
.
R2014a introduced modeling and code generation support for AUTOSAR-typed
per-instance memory (arTypedPerInstanceMemory
)
in Simulink models. With R2015b, you can import arTypedPerInstanceMemory
definitions
from arxml
code into a model. When you import an arTypedPerInstanceMemory
definition,
the arxml
importer:
Creates an AUTOSAR.Signal
data
object, sets its Storage class to PerInstanceMemory
,
and configures per-instance memory attributes.
Creates a Data Store Memory block that
references the AUTOSAR.Signal
object.
For more information, see Per-Instance Memory and Configure AUTOSAR Per-Instance Memory.
The AUTOSAR target (autosar.tlc
) now supports
toolchain controls for C code generation. When you select the AUTOSAR
target, the Configuration Parameter dialog box displays toolchain
parameters rather than the template makefile (TMF) parameters previously
displayed. You can more flexibly configure AUTOSAR code generation,
for example, for processor-in-the-loop (PIL) verification, or to leverage
a toolchain-based hardware support package.
Other targets that support toolchain controls include the ERT
targets ert.tlc
and ert_shrlib.tlc
.
Building an AUTOSAR model generates RTE (run-time environment)
files into the stub
subfolder of the model build
folder. The RTE files have .c
and .h
extensions,
and contain stub implementations of the AUTOSAR Rte
functions.
The stub implementations can be used to test the generated C code
in Simulink, for example, in software-in-the-loop (SIL) or processor-in-the-loop
(PIL) simulations of the component under test. When the generated
code ultimately is deployed in the AUTOSAR RTE, you replace the RTE
stub files with externally-generated RTE files.
R2015b enhances the generated RTE stub files in many respects. The build generates most of the same RTE stub files as before, but with improved content:
More closely reflects the AUTOSAR element content of the model.
More closely resembles what an external RTE Generator creates.
Better descriptions of content and possible uses.
R2015b also generates new stub files, Std_Types.h
:
and Platform_Types.h
:
Std_Types.h
is a standard AUTOSAR
file that defines basic data types.
Platform_Types.h
maps AUTOSAR base
types to platform types.
Std_Types.h
includes Platform_Types.h
,
and is included by Rte_Type.h
.
As of R2015b, lookup table blocks generate AUTOSAR compatible IFX library routines. Lookup table blocks were enhanced to support a new specification for even-spacing breakpoints, which supports and generates AUTOSAR IFX routines.
For more information, see Code Replacement for AUTOSAR.
Version 15.2.1 provides MATLAB functions for validating and synchronizing AUTOSAR model configurations:
autosar.api.validateModel(model)
—
Validate AUTOSAR properties and Simulink to AUTOSAR mapping of
specified model.
autosar.api.syncModel(model)
—
Synchronize Simulink to AUTOSAR mapping of specified model with Simulink block
modifications.
The functions are equivalent to using the Validate and Synchronize
icons in the graphical
views of an AUTOSAR configuration.
Version 15.2.1 allows you to round-trip CompuMethods that use
both LINEAR and TEXTTABLE scaling. Importing application data types
that reference CompuMethods of category SCALE_LINEAR_AND_TEXTTABLE
creates Simulink.NumericType
s and Simulink.AliasType
s
in the Simulink workspace. In Simulink, you can modify the
LINEAR scaling for the CompuMethods, but the TEXTTABLE scaling is
read-only.
Simulink provides the ability to merge AUTOSAR authoring
tool changes in arxml
files into a model and generate
an update report. Version 15.2.2 adds more automation and better reporting
to the merge process. The software automates Simulink block additions
required to represent arxml
updates and identifies Simulink block
deletions required to represent arxml
updates.
In Version 15.2.2, the arxml
importer can
import LiteralPrefixes defined in IncludedDataTypeSets. The LiteralPrefix
is then automatically added to Simulink enumerated data types
generated by the importer.
Version 15.2.4 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.
Version 15.2.8 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.
Version 15.2.1 provides the following arxml
importer
enhancements:
During arxml
import, for ArTypedPerInstanceMemory
referencing ApplicationArrayDataTypes, the software now creates data
store memory initialized with dimensions and initial values.
The software now supports import of ImplementationDataTypes with category TYPE_REFERENCE (with a reference to another ImplementationDataType with category DATA_REFERENCE, that is, VoidPtr). Previously, the software generated an error message that began with the following text.
Error using Simulink.metamodel.arplatform.ArxmlImporter/read Assertion failed: Could not find context sequence for type /
When the name of a NvDataInterface or DataElement
is updated using import with update (updateModel
),
the mapping now is correctly updated.
Version 15.2.2 provides the following arxml
importer
enhancements:
Import no longer throws an error when a CompuMethod is specified on an ImplementationDataType element.
Import of AUTOSAR physical data constraints is now correct when the physical and internal data constraints are bundled together.
If you import an AUTOSAR software component that uses an NV data interface, the importer now correctly initializes the XML option ImplementationDataType Reference.
ALIVE-TIMEOUT values for AUTOSAR ports are now imported
correctly from arxml
files and preserved in generated arxml
descriptions.
Previously, ALIVE-TIMEOUT values imported from arxml
files
were not preserved.
Version 15.2.3 provides the following arxml
importer
enhancements:
The importer now correctly configures a Simulink
Function block when the imported arxml
description
contains runnable arguments. In arxml
files, runnable
arguments are described using RUNNABLE-ENTITY-ARGUMENT nodes. Previously,
if a runnable description in the arxml
file included
runnable arguments, the importer incorrectly configured the Simulink
Function block.
Importing inlined array types from an arxml
file
no longer results in a model that fails to generate code. In arxml
files,
an inlined array type is an array type for which the element category
is not a TYPE_REFERENCE. Previously, importing inlined array types
resulted in invalid models.
Importing incomplete lookup table or axis descriptions
in an arxml
file no longer results in an incorrect
model. For example, if a COM-AXIS node is missing a description of
the SW-BASE-TYPE node, the axis is incomplete. The importer and the
code generator now recognize when the information is incomplete and
behave correctly.
Importing an NvM_ReadBlock
operation
from an arxml
file now correctly configures the
corresponding Function Caller block. Previously, in
the created model, the block arguments were incorrectly configured.
Importing LITERAL-PREFIX nodes now correctly creates Simulink enumeration type and literals. Previously, the enumeration literals were incorrect in the enumeration type.
Importing an incomplete DATA-TYPE-MAPPING-SET node if neither the data type set nor the constituent data types are used in the model no longer throws an error. Previously, importing incomplete nodes resulted in an importer error.
Importing a COMPU-METHOD node that represents a linear scaling slope less than or equal to zero now results in an error. Previously, the importer created an incorrect model. Linear scaling with slope less than or equal to zero is not supported for AUTOSAR models.
Importing a SW-BASE-TYPE node that represents an integer type of size 64, when the type is not used in the created model, no longer throws an error. Previously, the importer threw an error, incorrectly assuming that the integer type is used in the created model. Integer types of size greater than 32 are not supported for AUTOSAR models.
Version 15.2.4 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.
The updateModel
method now successfully
updates models that previously gave an out of memory error.
Version 15.2.5 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 15.2.6 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 imports runnables with self-feedback inter-runnable variables (IRVs), that is, IRVs that are only read and written by the same runnable. Previously, the importer threw the following error:
Cannot map data transfer signal signalName because it does not exist.
The importer now correctly handles arxml
descriptions
that produce merged array signals in Simulink. Previously, the
importer created an uncompilable Simulink model.
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.
Version 15.2.7 provides the following arxml
importer
enhancements:
The importer now makes better use of the Simulink model
canvas for arxml
files that contain a large number
of runnables or ports. Previously, the importer 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
The importer now creates correct Goto/From tags
from arxml
files that contain long identifiers.
Previously, the importer threw the following error:
Error using autosar.mm.mm2sl.MRLayoutManager/addGotoFrom (line 265) The value 'RPortWithAVeryLongIdentifier_RPortWithAVeryLongIdentifier_VariationLongIdentifier_2_Tag' of parameter 'GotoTag' is not a valid MATLAB identifier. Valid identifiers start with an alphabetic character, followed by at most 63 alphanumeric or '_'
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 15.2.8 provides the following arxml
importer
enhancement:
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.
Version 15.2.9 provides the following arxml
importer
enhancement:
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
Version 15.2.10 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 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 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 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 15.2.1 provides the following arxml
export
enhancements:
Multiple ApplicationDataTypes created from same Simulink data type, but with different Min and Max values, now reference the same CompuMethod. Previously, each ApplicationDataType referenced a separate CompuMethod.
Export no longer incorrectly generates an error when building a model with a mixture of Receiver/Sender and NvReceiver/NvSender ports. Previously, export threw the following error:
ERROR: The call to autosar_make_rtw_hook, during the exit hook generated the following error: Cannot create reference to element [unnamed].
The software now prevents inclusion of old arguments in the exported interface for the Invoke AUTOSAR Server Operation block.
Version 15.2.2 provides the following arxml
export
enhancement:
Export no longer throws an error when Simulink enumeration is redefined with option AddClassNameToEnumNames set to true.
Version 15.2.4 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 15.2.5 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 15.2.6 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 15.2.7 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 15.2.9 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 15.2.1 provides the following AUTOSAR code generation enhancement:
Code generation no longer incorrectly throws an error when data
access mode QueuedExplicitReceive
is used
with a nonvolatile (NV) data interface.
Version 15.2.6 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 15.2.7 provides the following AUTOSAR code generation enhancement:
Code generation now generates an implementation enumeration data type when an application enumeration data type is mapped to an implementation data type. Previously, the code generator incorrectly generated an application enumeration data type.
Version 15.2.1 provides the following AUTOSAR modeling enhancements:
In the AUTOSAR configuration dialog box, when mapping of a Simulink inport to a PortInterface DataElement changes, the software now updates the trigger port for the associated event.
The following AUTOSAR configuration dialog box icons for nonvolatile (NV) data interfaces are updated: NvReceiverPorts, NvSenderPorts, and NvSenderReceiverPorts.
In the NV Add Interfaces dialog box, the label Nv Data Interfaces is changed to Non-Volatile Data Interfaces.
In the NV Add Ports dialog box, the label Nv Sender Receiver Ports is changed to Non-Volatile Data Ports.
Adding an NV SenderReceiverPort through the API now correctly errors out for AUTOSAR schema version 4.0 models.
Default names of DataElements in an NV data interface are changed to NVData1, NVData2, and so on.
When using the AUTOSAR configuration dialog box, a change in a data element name for an NV data interface now updates the drop-down menu for Simulink port mapping.
The software no longer generates a segmentation violation when VARIABLE-ACCESS for an unmapped component has a missing VARIABLE-PROTOTYPE reference.
Changed the default ApplicationError for a model that has an error argument but no predefined error codes from 0 to 1.
Version 15.2.6 provides the following AUTOSAR modeling enhancements:
AUTOSAR validation no longer errors out when a model includes both NV data ports and a mode-receiver port.
AUTOSAR function autosar.api.syncModel
now
automatically maps unmapped Function Caller blocks
for existing client-server operations to the same mapping as existing
mapped function callers. Previously, the function did not complete
the mapping and validation and subsequently errored out. The issue
affected only the function and not the Synchronize icon
in the Configure AUTOSAR Interface dialog box.
Version 15.2.9 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.