You can now import AUTOSAR compositions from arxml
files into
Simulink®. AUTOSAR compositions aggregate AUTOSAR software components and
potentially other compositions. Use the arxml.importer
function
createCompositionAsModel
to import a composition. Use the function
updateModel
to update an imported composition with changes from
arxml
files.
For more information, see the createCompositionAsModel
reference page and live-script example Import AUTOSAR Composition to Simulink.
R2016b introduced the AUTOSAR Basic Software (BSW) block library. The library provides preconfigured Function Caller blocks for modeling component calls to AUTOSAR BSW services. The BSW caller blocks support AUTOSAR code generation.
Before R2017b, you could not easily simulate a component that used the BSW blocks, because no model-level implementations existed for the BSW service functions called by the blocks.
In R2017b, the software provides reference implementations of the AUTOSAR Dem and NvM services supported by the BSW caller blocks. When coupled with the caller blocks, the reference implementations allow you to run system- or composition-level simulations of AUTOSAR BSW service calls. The ability to simulate calls into BSW services can help identify modeling problems before the AUTOSAR generated code reaches the AUTOSAR Runtime Environment (RTE).
For more information, see Model AUTOSAR Basic Software Service Calls (Embedded Coder®), Configure AUTOSAR Basic Software Service Implementations for Simulation (Embedded Coder), and live-script example Simulate AUTOSAR Basic Software Services and Runtime Environment.
In R2017b, you can use Simulink messages to model AUTOSAR queued sender-receiver communication between automotive components. Previously, you could model only nonqueued sender-receiver communication.
In Simulink, you can now model sending and receiving AUTOSAR data using a queue, and handling errors that occur when the queue is empty or full.
For more information, see Configure AUTOSAR Queued Sender-Receiver Communication (Embedded Coder).
arTypedPerInstanceMemory
AUTOSAR typed per-instance memory (arTypedPerInstanceMemory
),
introduced in AUTOSAR schema version 4.0, defines an AUTOSAR typed memory block that is
available for each instance of an AUTOSAR software component. In the AUTOSAR Runtime
Environment (RTE), calibration tools can access arTypedPerInstanceMemory
blocks for measurement and calibration.
Previously, you could model arTypedPerInstanceMemory
in Simulink by creating an AUTOSAR.Signal
data object and referencing
it in a Data Store Memory block.
In R2017b, you can also generate arTypedPerInstanceMemory
blocks for
block signal and discrete state data in your AUTOSAR model. Configure the signals and states
to use SimulinkGlobal
storage class. For more information, see Per-Instance Memory (Embedded
Coder) and Configure AUTOSAR Per-Instance
Memory (Embedded
Coder).
The Embedded Coder Support Package for AUTOSAR Standard now installs AUTOSAR featured examples, including new live-script examples.
See Embedded Coder Support Package for AUTOSAR Standard Examples.
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 R2017b, 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.
You can now generate AUTOSAR code without including inactive variant parts of a model. If your model contains a variant block with the Generate preprocessor conditions (GPC) option turned off, the generated C code contains only active condition paths and omits inactive condition paths.
In AUTOSAR software components, a sender or receiver port optionally can specify a communication specification (ComSpec). ComSpecs describe additional communication requirements for port data.
In Version 17.2.1, to model AUTOSAR sender and receiver ComSpecs in Simulink, you can:
Import sender and receiver ComSpecs from arxml
files
Create sender and receiver ComSpecs in Simulink
For nonqueued receiver ports, modify ComSpec attributes
AliveTimeout
and
HandleNeverReceived
Export ComSpecs to arxml
files
In Version 17.2.3, you additionally can modify ComSpec attribute
InitValue
for nonqueued sender and receiver ports.
For example, if you import a receiver port ComSpec from arxml
files, you can use the AUTOSAR Properties Explorer to view and edit the ComSpec
attributes of the mapped S-R data elements in the AUTOSAR port.
If you create an AUTOSAR receiver port in Simulink, you use the Simulink-AUTOSAR Mapping Explorer to map a Simulink inport to the AUTOSAR receiver port and an S-R data element. You can then select the port and specify its ComSpec attributes.
When you generate code for an AUTOSAR model that specifies ComSpec attributes, the
exported arxml
port descriptions include the ComSpec attribute
values.
<PORTS> <R-PORT-PROTOTYPE UUID="..."> <SHORT-NAME>ReceivePort</SHORT-NAME> <REQUIRED-COM-SPECS> <NONQUEUED-RECEIVER-COM-SPEC> <DATA-ELEMENT-REF DEST="VARIABLE-DATA-PROTOTYPE"> /Company/Powertrain/Interfaces/Input_If/In1 </DATA-ELEMENT-REF> ... <ALIVE-TIMEOUT>30</ALIVE-TIMEOUT> <HANDLE-NEVER-RECEIVED>true</HANDLE-NEVER-RECEIVED> ... <INIT-VALUE> <CONSTANT-REFERENCE> <SHORT-LABEL>DefaultInitValue_Double_1</SHORT-LABEL> <CONSTANT-REF DEST="CONSTANT-SPECIFICATION"> /Company/Powertrain/Constants/DefaultInitValue_Double_1 </CONSTANT-REF> </CONSTANT-REFERENCE> </INIT-VALUE> </NONQUEUED-RECEIVER-COM-SPEC> </REQUIRED-COM-SPECS> </R-PORT-PROTOTYPE> </PORTS> ... <CONSTANT-SPECIFICATION UUID="..."> <SHORT-NAME>DefaultInitValue_Double_1</SHORT-NAME> <VALUE-SPEC> <NUMERICAL-VALUE-SPECIFICATION> <SHORT-LABEL>DefaultInitValue_Double_1</SHORT-LABEL> <VALUE>1</VALUE> </NUMERICAL-VALUE-SPECIFICATION> </VALUE-SPEC> </CONSTANT-SPECIFICATION>
arxml
File Import: Add Signal Invalidation blocks and ErrorStatus ports when required by imported componentsIn Version 17.2.1, the AUTOSAR arxml
importer now automatically
adds Signal Invalidation blocks and ErrorStatus ports when required by an imported
component that uses sender-receiver (S-R) communication. Importer function
createComponentAsModel
:
Adds a Signal Invalidation block connected to an outport if the outport is mapped to an AUTOSAR sender port and the associated S-R data element uses invalidation policy KEEP or REPLACE.
Adds an ErrorStatus port to a receiver component if the associated S-R data element meets one of these conditions:
Uses invalidation policy KEEP or REPLACE.
Uses an AliveTimeout
value greater than
0.
Has HandleNeverReceived
set to true.
In Version 17.2.3, the update report generated by importer function
updateModel
now provides a search bar. You can quickly
navigate to specific elements or other strings of interest.
AUTOSAR CompuMethods of category BITFIELD_TEXTTABLE allow you to access bit values within an application data type of category VALUE. You can group bit values, assign labels to them, and define masks for accessing values within bytes of data.
In Version 17.2.3, you can import BITFIELD_TEXTTABLE CompuMethods from
arxml
files. After you import the CompuMethods, you can
create Simulink enumerated types to represent bit groups and masks for accessing the
bitfields, and reference them in Simulink bitwise and relational operator and constant blocks.
You can use the AUTOSAR properties function createEnumeration
to create Simulink enumerated types for a bitfield CompuMethod. For example:
arProps = autosar.api.getAUTOSARProperties(modelName); createEnumeration(arProps,'/Company/Module/CompuMethods/MyBitfieldCompuMethod');
In Version 17.2.3, when using the Basic Software block
NvMServiceCaller to call ReadBlock
,
RestoreBlockDefaults
, or
WriteBlock
operations, you now can specify array and
bus data types. Use the block parameter Argument
specification.
arxml
importer enhancementsVersion 17.2.1 provides the following arxml
importer
enhancements:
Importer function updateModel
no longer errors out
when both a port and its referenced interface have been deleted. Previously,
updateModel
generated the following error:
Error using autosar.api.getAUTOSARProperties/findObjByPartialOrFullPathForNamedElement (line 1371) The AUTOSAR element does not exist at '/pkg/swc/Port1'.
When an arxml
file contains
INSTANTIATION-DATA-DEF-PROPS, the importer now creates a
Simulink.LookupTable
object that references
appropriate axis data. Previously, the importer generated a
Simulink.LookupTable
object with the breakpoint
Field name set to BP1.
Version 17.2.3 provides the following arxml
importer
enhancement:
The importer now correctly sets the implementation data type name for types of category TYPE_REFERENCE.
arxml
export enhancementsVersion 17.2.1 provides the following arxml
export
enhancement.
Export no longer errors out when an inter-runnable variable name in the AUTOSAR model matches a workspace object name. Previously, export generated the following error:
No appropriate method, property, or field 'DataType' for class 'Simulink.Bus'
Version 17.2.3 provides the following arxml
export
enhancements.
Export now correctly places an AUTOSAR data type package inside the
file, even if the package does not match XML option specifications.
Previously, interface and datatype packages could be incorrectly placed in
the modelname
_datatype.arxml
file.modelname
_component.arxml
Export now correctly exports any AUTOSAR interface with the
isService
attribute set to true to
stub/
,
rather than to a top-level ARXML file such as
modelname
_external_interface.arxml
or
modelname
.arxml
.
Previously, setting the modelname
_interface.arxmlisService
attribute caused only
C-S interfaces to be exported to the external interfaces ARXML stub file.
Other interfaces with isService
set, such as S-R or M-S,
were incorrectly exported to a top-level ARXML file.
Export performance is improved when the Configure AUTOSAR Interface dialog box is open. Previously, export took much longer when the dialog box was open.
Export now generates a Category subelement when describing AUTOSAR VariationPointProxy elements. Previously, VariationPointProxy elements did not include a Category subelement.