If you previously installed an earlier Version 16.1.n Embedded Coder® Support Package for AUTOSAR Standard, you must uninstall that version before installing Version 16.1.2 or later.
Simulink® provides the ability to merge AUTOSAR authoring tool changes into a model as part of round-trip iterations. R2016a adds more automation and better reporting to the merge process. The software:
Automates Simulink block additions. In the updated model, green highlighting identifies the added blocks.
Lists required Simulink block deletions. In the updated model, red highlighting identifies the blocks to delete.
For more information, see Import AUTOSAR Software Component Updates.
Note: This capability is available to R2015b Embedded Coder customers by installing the R2015b Embedded Coder Support Package for AUTOSAR Standard, Version 15.2.2 or later. |
R2016a provides many other enhancements to Simulink modeling of AUTOSAR elements and AUTOSAR code generation. For more information, see:
Under Model Architecture and Design:
Under Code Generation:
R2016a enhances AUTOSAR component modeling with modeling support for:
AUTOSAR variants in ports and runnables
AUTOSAR variants in array sizes
AUTOSAR software components can use variants to enable or disable AUTOSAR elements, such as ports and runnables, based on defined conditions. Embedded Coder now supports modeling AUTOSAR variants in ports and runnables.
In Simulink, you can:
Import AUTOSAR ports and runnables with variation points.
The arxml
importer creates the required model
elements, including workspace variables for modeling with variants, Variant
Sink blocks, and Variant
Source blocks to propagate variant conditions.
Model AUTOSAR ports and runnables with variation points.
To define variant condition logic, use Simulink.Variant
data
objects.
To represent AUTOSAR system constants, use AUTOSAR.Parameter
data
objects with storage class SystemConstant
.
To propagate variant conditions for the AUTOSAR elements, use Variant Sink and Variant Source blocks.
Run validation on the AUTOSAR configuration. The validation
software checks that variant conditions on Simulink blocks match
the designed behavior from the imported arxml
code.
Export previously imported AUTOSAR ports and runnables with variation points.
For more information, see Model AUTOSAR Variants and Configure AUTOSAR Variants in Ports and Runnables.
AUTOSAR software components can flexibly specify the dimensions of an AUTOSAR element, such as a port, by using a symbolic reference to a system constant. The system constant defines the array size of the port data type.
Embedded Coder now supports modeling AUTOSAR variants in array sizes.
In Simulink, you can:
Import AUTOSAR elements with variant array sizes.
The arxml
importer creates the
required model elements, including AUTOSAR.Parameter
data
objects with storage class SystemConstant
,
to represent the array size values.
Each block created by the importer to represent an
AUTOSAR element with variant array sizes references AUTOSAR.Parameter
data
objects to define its dimensions.
Model AUTOSAR elements with variant array sizes.
Create blocks that represent AUTOSAR elements.
To represent array size values, add AUTOSAR.Parameter
data
objects with storage class SystemConstant
.
To specify array size for an AUTOSAR element, reference
an AUTOSAR.Parameter
data object.
Modify array size values in system constants and simulate the model, without regenerating code for simulation.
Generate C and arxml
code with
symbols corresponding to variant array sizes.
For more information, see Variants in Array Sizes and Configure AUTOSAR Variants in Array Sizes.
R2016a enhances AUTOSAR sender-receiver modeling with support
for DataReceivedEvent
s for receiver ports
in ImplicitReceive
data access mode. Previously,
the software supported DataReceivedEvent
s
for receiver ports only in ExplicitReceive
, QueuedExplicitReceive
,
and EndToEndRead
data access modes.
Note: This capability is available to R2015b Embedded Coder customers by installing the R2015b Embedded Coder Support Package for AUTOSAR Standard, Version 15.2.0 or later. |
The arxml
importer can now import AUTOSAR LiteralPrefix
s
defined in IncludedDataTypeSet
s. The software adds LiteralPrefix
s
to Simulink enumerated data types generated by the importer.
Note: This capability is available to R2015b Embedded Coder customers by installing the R2015b Embedded Coder Support Package for AUTOSAR Standard, Version 15.2.2 or later. |
R2016a adds MATLAB® functions for validating and synchronizing AUTOSAR model configurations:
autosar.api.validateModel
—
Validate AUTOSAR properties and Simulink to AUTOSAR mapping of
specified model.
autosar.api.syncModel
—
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.
Note: This capability is available to R2015b Embedded Coder customers by installing the R2015b Embedded Coder Support Package for AUTOSAR Standard, Version 15.2.1 or later. |
R2016a enhances the AUTOSAR arxml
round-trip
workflow with support for:
CompuMethods with LINEAR and TEXTTABLE COMPU-SCALEs
PredefinedVariants import and export
Enhanced control of AUTOSAR package path specification
In R2016a, you can import and export a CompuMethod that uses
LINEAR and TEXTTABLE scaling. Importing application data types that
reference CompuMethods of category SCALE_LINEAR_AND_TEXTTABLE creates Simulink.NumericType
or Simulink.AliasType
data
objects in the Simulink workspace. In Simulink, you can
modify the LINEAR scaling for the CompuMethods. The TEXTTABLE scaling
is read-only.
For more information, see CompuMethod Categories for Data Types and Modify Linear Scaling for SCALE_LINEAR_AND_TEXTTABLE CompuMethod.
Note: This capability is available to R2015b Embedded Coder customers by installing the R2015b Embedded Coder Support Package for AUTOSAR Standard, Version 15.2.1 or later. |
For an AUTOSAR software component that contains variation points, to define the values that control variation points, you can use the following AUTOSAR elements:
SwSystemconst
— Defines
a system constant that serves as an input to control a variation point.
SwSystemconstantValueSet
—
Specifies a set of system constant values.
PredefinedVariant
— Describes
a combination of system constant values, among potentially multiple
valid combinations, to apply to an AUTOSAR software component.
Previously, when creating a model from arxml
code,
the arxml
importer did not provide a way to specify
a PredefinedVariant
or SwSystemconstantValueSet
s
as a basis for resolving variation points in the model.
In R2016a, you can resolve variation points in an AUTOSAR software
component at model creation time. Specify a PredefinedVariant
or SwSystemconstantValueSet
s
with which the importer can initialize SwSystemconst
data.
After model creation, you can run simulations and generate code based on the combination of variation point input values that you specified.
For more information, see Model AUTOSAR Variants and Control AUTOSAR Variants with Predefined Value Combinations.
In R2016a, if you modify an AUTOSAR package path, and if packageable elements of that category are affected, you can:
Move the elements from the existing package to the new package.
Set the new package path without moving the elements.
If you modify a package path in the Configure AUTOSAR Interface
dialog box, and if packageable elements of that category are affected,
a dialog box opens with control options. If you programmatically modify
a package path, you can use the MoveElements
property
to specify handling of affected elements.
For more information, see Control AUTOSAR Elements Affected by Package Path Modifications.
Note: This capability is available to R2015b Embedded Coder customers by installing the R2015b Embedded Coder Support Package for AUTOSAR Standard, Version 15.2.0 or later. |
As of R2016a, the AUTOSAR 4.0 code replacement library (CRL)
replaces abs
, saturate
, min
,
and max
function calls that involve operands
with equal slope and bias with calls to corresponding Mfx
functions.
Calls To | Replace |
---|---|
Mfx_Abs | abs with operands that have equal slope |
Mfx_Limit | saturate with operands that have equal
slope and bias |
Mfx_Max | max with operands that have equal slope
and bias |
Mfx_Min | min with operands that have equal slope
and bias |
For more information about using the AUTOSAR 4.0 CRL, see Code Generation with AUTOSAR Library.
In R2016a, the AUTOSAR target removes support for using right-click builds to build a wrapper subsystem that models an AUTOSAR SW-Component. In R2013b, a top model approach to modeling multirunnable AUTOSAR SW-Components replaced the wrapper subsystem approach. For more information, see Multi-Runnable Software Components and Configure AUTOSAR Multiple Runnables.
In R2016a, if you try to configure and build an AUTOSAR SW-Component by using a wrapper subsystem, the software issues an error message. The message states that configuring a subsystem as an AUTOSAR SW-Component is not supported.
To convert subsystem multirunnables to top model multirunnables, use the subsystem-to-model conversion techniques described in Convert a Subsystem to a Referenced Model. After the basic conversion, you must manually reestablish some AUTOSAR configuration information from the subsystem configuration in the new configuration.
Version 16.1.1 extends support of AUTOSAR schema versions 4.2
and 3.2 to include schema revisions 4.2.2 and 3.2.2. Embedded Coder supports
the new schema revisions for import and export of arxml
files
and generation of AUTOSAR-compatible C code.
If you import schema 4.2.2 or 3.2.2 arxml
descriptions
into Simulink, the arxml
importer detects
and uses the schema version and revision, and sets the schema version
parameter in the model. For more information on schema import and
export, see Select
an AUTOSAR Schema.
If you are developing an AUTOSAR software component based on
AUTOSAR schema version 3.2, schema revision 3.2.2 allows you to include
sender-receiver port end-to-end (E2E) protection, receiver port IsUpdated
service,
and port-based nonvolatile (NV) data communication in your component
design.
Version 16.1.5 enhances support for AUTOSAR DESC elements. Importing
AUTOSAR DESC information associated with an AUTOSAR identifiable element
now populates the Description property in the
corresponding Simulink element or data object. Correspondingly,
exporting a Simulink element or data object Description property
now populates the DESC information in the corresponding AUTOSAR element.
Previously, Embedded Coder preserved AUTOSAR DESC information
across arxml
round-trips but did not leverage the
information to add a readable text description to the Simulink model.
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.
In Version 16.1.7, the updateModel
function
now automates insertion and mapping of the following elements:
Inter-runnable variable (IRV) lines for AUTOSAR IRVs
Constant blocks for AUTOSAR parameters
Data store memory (DSM) blocks for AUTOSAR per-instance memory (PIM) blocks
Previously, these elements required manual additions to the model.
Model updates also now resize added Function Caller, Constant, and DSM blocks so that block text is readable.
Version 16.1.1 provides the following arxml
importer
enhancements:
The importer now successfully imports parameter values with a pointer-to-void implementation data type. Previously, importing these data types caused an import error.
The importer now successfully imports application data types with a CompuMethod of category SCALE_LINEAR_AND_TEXTTABLE, when the mapped implementation data type category is TYPE_REFERENCE. Previously, importing these data types caused an import error.
Improved importer performance when using Simulink data dictionary.
The importer now successfully imports multiple data
store memories from arxml
files. Previously, importing
multiple data store memories could cause a Simulink canvas limit
error.
The importer now successfully imports an application value specification of category BOOLEAN with VT labels. Previously, importing these application value specifications caused an import error.
Version 16.1.2 provides the following arxml
importer
enhancements:
The importer now correctly imports the Min and Max
values for ApplicationDataTypes by using the correct precision for
fixed-point and float types. Previously, the importer threw an error
message similar to "Value (3276.7000000000003) is greater
than maximum (3276.7)
" when the imported constant value
is equal (within tolerance) to the Min or Max value.
Importer method updateModel
now
correctly handles Goto/From blocks with
local scope. Previously, updateModel
could get
into a loop and potentially run out of memory when locally scoped Goto/From blocks
had the same tag.
The importer now correctly imports ReceiverPorts with
multiple ReceiverComSpecs with InitValue specified using ARRAY-VALUE-SPECIFICATION.
Previously, the importer threw error message "Imported AUTOSAR
MetaModel contains orphaned elements
".
The importer now correctly imports STATIC-MEMORY or
CONSTANT-MEMORY and overwrites existing Simulink.Signal
or Simulink.Parameter
data
objects, respectively. Previously, the importer threw an error while
overwriting existing Simulink data objects.
Version 16.1.3 provides the following arxml
importer
enhancements:
The importer no longer errors out when an arxml
file
contains PORT-API-OPTIONS. Previously, the importer threw the following
error:
Element {} of type Simulink.metamodel.arplatform.behavior.PortAPIOption has no property named {}InitValue
The importer now throws a warning when an arxml
file
specifies a ModeSwitchEvent TARGET-MODE-DECLARATION-REF reference
that does not exist. Previously, the importer threw an error for this
case.
The importer now correctly ignores DataConstr for Structure members of category TYPE_REFERENCE, which Simulink does not support. Previously, the importer tried to read DataConstr for Structure members of category TYPE_REFERENCE, which could generate an unhelpful importer error message.
The importer now correctly creates internal data type names, without double underscores, for ApplicationDataTypes of category VAL_BLK, CURVE, MAPS, etc. Previously, if a data type already had underscore as the last character in its ShortName, the importer added a second underscore, which caused a validation error.
The importer now correctly creates an AUTOSAR.Parameter
with
data type boolean
for ApplicationDataTypes of category
VAL_BLK. Previously, the importer created an AUTOSAR.Parameter
with
data type logical
, which caused a compilation error.
The importer now throws an informative error message when an ApplicationDataType of category CURVE, COM_AXIS, etc., for a lookup table uses an initial value that is scalar rather than nonscalar. Previously, the importer threw an unhelpful error message.
The importer no longer creates unnecessary and unused Simulink data types in the workspace when importing ApplicationDataTypes of category VAL_BLK.
The importer now correctly handles system constant expressions for variants that span multiple lines. Previously, the importer threw an error if a variant expression was not on a single line.
Version 16.1.4 provides the following arxml
importer
enhancement:
The importer now correctly handles an implementation data type that is directly referenced from a data prototype and maps to a fixed-point application data type. Previously, the importer created an extra fixed-point Simulink type corresponding to the implementation data type.
Version 16.1.6 provides the following arxml
importer
enhancements:
The importer now supports Goto/From tag names up to 64 characters. Previously, tag names were limited to 32 characters, after which the name was truncated and appended with a unique suffix.
The importer now correctly imports an ImplementationDataType of category STRUCTURE or ARRAY that references another ImplementationDataType. Previously, importing ImplementationDataTypes for curves and maps could generate an assertion.
The importer now makes better use of the Simulink model
canvas for arxml
files that contain a large number
of runnables or ports. Previously, import threw the following error:
Error using autosar.mm.mm2sl.SLModelBuilder/setIdealBlockPosition At least one value is out of range for defining rectangle or position. All values must be less than or equal to 32767.
Importer method updateModel
now
works correctly with reference configuration sets. Previously, updateModel
threw
the following error:
A configuration set reference does not allow writing to parameters in the source configuration set
Importer method updateModel
now
supports importing arxml
files containing matrices
with differing dimensions. Previously, updateModel
threw
an error similar to the following:
Error using Simulink.metamodel.arplatform.Comparator/compare Assertion failed: first and second values sizes are different at b:\matlab\src\arxml_util\matcher\comparator.cpp:209:
Version 16.1.7 provides the following arxml
importer
enhancements:
The importer now correctly updates models with Goto and From blocks. Previously, updating some models that had Goto and From blocks generated the following error:
Out of memory. The likely cause is an infinite recursion within the program. Error in num2str (line 72) s = int2str(x); % Enhance the performance
The importer now correctly configures the base type
(StorageType
) of an enumeration data type when
an implementation data type references a TEXTTABLE CompuMethod. Previously,
the StorageType
was not set and defaulted to sint32
.
The importer now can create models that have branched IsUpdated
ports.
Previously, the importer displayed the following error:
Error using autosar.mm.mm2sl.SLModelBuilder/createIsUpdatedPortElement (line 663) Could not create IsUpdated inport for RPort_DE1_IsUpdated Error in autosar.mm.mm2sl.SLModelBuilder/addPortElement (line 124) this.createIsUpdatedPortElement(blkPath, m3iPort, m3iDataElement, slPortType);
The importer now correctly imports ComSpecs with matching InitValue names. Previously, the importer discarded ComSpecs in which InitValues had the same name.
The importer now imports PerInstanceMemory that has ArrayValueSpecification initial data. Previously, the importer displayed the following error:
Error : While setting the 'Type' property of 'MatrixValueSpecification': Value must be 'Simulink.metamodel.foundation.ImmutableType'.
The importer now correctly creates function-call subsystems with large subsystems (for example, greater than 800 ports). Previously, the importer generated the following error:
Error using autosar.mm.mm2sl.SLModelBuilder/setIdealBlockPosition (line 110) At least one value is out of range for defining rectangle or position. All values must be less than or equal to 32767.
The importer now correctly imports a configuration in which multiple InitValues have ValueSpecifications with the same short label name. Previously, when ValueSpecification short labels had the same name, the importer could import incorrect initial values.
The importer now correctly imports InvalidValues with a UnitReference. Previously, the importer displayed an error similar to the following:
Error using Simulink.metamodel.arplatform.ArxmlImporter/read Assertion failed: MetaClass Simulink.metamodel.types.LiteralReal does not have property Unit at b:\matlab\src\arxml_util\arxml\arxmlreadtransformer4p0.cpp:10444
The importer now supports import of NumericalValueSpecifications with Value NaN. Previously, the importer generated an error message.
The importer now supports import of ImplementationDataTypes of category TYPE_REFERENCE that do not specify a CompuMethod. Previously, the importer required that both the parent and the referenced ImplementationDataType specify a CompuMethod.
Version 16.1.1 provides the following arxml
export
enhancement:
Unused pointer-to-integer data types no longer cause export errors. Simulink supports pointer-to-void data types, but does not support pointer-to-integer data types. Previously, unused pointer-to-integer data types caused export to fail.
Version 16.1.2 provides the following arxml
export
enhancement:
Exporting arxml
descriptions previously could
change the CompuMethod category of an ApplicationDataType of type
BOOLEAN from IDENTICAL to TEXTTABLE in top-down workflows. Export
now preserves the CompuMethod category.
Version 16.1.3 provides the following arxml
export
enhancements:
Export now round-trips the initial values that were imported on port ComSpecs. Previously, export created default initial values on the port ComSpecs, replacing the imported initial values.
Export now correctly handles rounding errors when writing out CompuMethod coefficients. Previously, export could write coefficient values that looked like 0.99999999999999989.
Export now correctly generates only Internal DataConstr for enumeration data types, for both ApplicationDataType and ImplementationDataType. Previously, export generated duplicate DataConstrs for enumeration data types because it tried to export Physical DataConstr for the enumeration ApplicationDataType.
With modular XML file packaging selected, export no
longer generates empty packages for DataConstrs and SystemConstants
in the _datatype.arxml
file. Previously, export
generated empty packages, resulting in a round-trip arxml
mismatch.
Export no longer generates INVALID-VALUEs with invalid or empty CONSTANT-REFERENCEs. Previously, exporting an imported INVALID-VALUE with an empty CONSTANT-REFERENCE could crash Simulink.
Export now throws a warning if two common axis lookup tables use the same parameter for table data and different parameters for axis data. The warning informs the user that the COM_AXIS parameter is not shared. Previously, export threw an error.
Version 16.1.4 provides the following arxml
export
enhancement:
Export now correctly generates arxml
files
when an application data type does not reference a CompuMethod. Previously,
export threw an error while setting the unit property for the physical
data constraint.
Version 16.1.6 provides the following arxml
export
enhancement:
Export now supports exporting a previously imported inlined structure type. Previously, export threw the following error:
Error using autosar.mm.mm2rte.TypeBuilder/addReferencedType (line 68) Unsupported m3iType class M3I.Object for addReferencedType.
Version 16.1.7 provides the following arxml
export
enhancements:
Export now correctly generates arxml
descriptions
for imported ApplicationRecordTypes that have missing type references.
Previously, export generated the following error:
Error using autosar.mm.arxml.Exporter/write Cannot create reference to element [unnamed].
Export now supports round-tripping an AutosarVariableRef that does not specify a DataPrototype. Previously, export generated an error message.
Version 16.1.3 provides the following AUTOSAR code generation enhancements:
Code generation now generates correct typedefs for
void types in Rte_Type.h
. Previously, the code
generator generated the wrong typedef, which could cause compilation
errors during software-in-the-loop (SIL) simulations.
Code generation now generates the return type of RTE
function Rte_Mode_<p>_<o>
as ShortName
of ImplementationDataType of ModeDeclarationGroup. Previously, the
code generator generated the return type as ShortName of ModeDeclarationGroup,
which could cause compilation errors in the contract phase.
Version 16.1.6 provides the following AUTOSAR code generation enhancement:
Code generation now correctly generates an implementation enumeration data type when an application enumeration data type is mapped to an implementation data type. Previously, code generation incorrectly generated an application enumeration data type.
Version 16.1.6 provides the following AUTOSAR modeling enhancement:
The Configure AUTOSAR Interface dialog box now correctly displays mode declaration values for a mode-switch event when you specify an enumeration type on a Simulink inport without a space. You also can now specify an enumeration type name with a ? (question-mark) symbol.