Confidential Prerelease Documentation — Subject to Nondisclosure Agreement
R2015a provides many enhancements to Simulink® modeling of AUTOSAR elements and AUTOSAR code generation. Highlights include:
AUTOSAR multi-runnable modeling using Simulink rate-based multitasking
Improved traceability for AUTOSAR RTE implicit read
For more information about AUTOSAR-related enhancements in R2015a, see:
Under Model Architecture and Design:
Under Code Generation:
In previous releases, you modeled a multi-runnable AUTOSAR software component using Simulink function-call subsystems or Simulink Function blocks at the top level of a model. In R2015a, you can model a multi-runnable AUTOSAR software component using Simulink rate-based multitasking. Using this approach, you can:
Create an AUTOSAR software component with multiple periodic runnables in Simulink.
Import an AUTOSAR software component with multiple
periodic runnables from arxml
into Simulink.
Migrate an existing rate-based, multitasking Simulink model to the AUTOSAR target.
For more information, see Multi-Runnable Software Components and Configure Multiple Runnables Using Rate-Based Multitasking.
Before R2015a, you could not configure a multitasking model
for the AUTOSAR target. If you attempted to import an AUTOSAR software
component with multiple periodic runnables and create a rate-based
model (that is, if you invoked arxml.importer
method createComponentAsModel
with CreateInternalBehavior
set
to false
), the importer would:
Discard all but one runnable and create a rate-based, single-tasking model.
For each AUTOSAR port, create an inport or outport and related Simulink elements even if the port was not accessed by the AUTOSAR runnable.
Performing the same import in R2015b produces different results in two respects. The importer:
Creates a rate-based, multitasking model, rather than rate-based, single-tasking.
For each AUTOSAR port, creates an inport or outport and related Simulink elements only if the port is accessed by an AUTOSAR runnable.
In previous releases, you could define AUTOSAR system constants
(SwSystemConstant
s) in Simulink, but their
use was limited to condition formulas inside variant subsystems and
model references. In R2015a, you can directly reference AUTOSAR system
constants in Simulink algorithms. For example, you could reference
a system constant in a Gain block.
For more information, see System Constants and Model AUTOSAR Component Behavior.
R2015a significantly enhances AUTOSAR CompuMethod related workflows in Simulink. You can:
Configure the properties of imported AUTOSAR CompuMethods
Create and configure AUTOSAR CompuMethods in Simulink
Use externally-defined AUTOSAR CompuMethods
Use externally-defined AUTOSAR Units
For more information, see Configure AUTOSAR CompuMethods.
AUTOSAR code generation now generates more traceable and readable code for a root inport that models an AUTOSAR RTE implicit read, especially when the inport data type is a matrix.
For example, consider root inport In1
the
following model:
In R2014b, the generated code introduces a hidden Signal Conversion block:
void Runnable_Step(void) { const real_T *rtb_TmpSignalConversionAtIn1Out; real_T tmp[9]; int32_T /* SignalConversion: '<Root>/TmpSignal ConversionAtIn1Outport1' incorporate Inport: '<Root>/In1 */ rtb_TmpSignalConversionAtIn1Out = Rte_IRead_Runnable_Step_Input_Element0(); /* Sum: '<Root>/Add' incorporates: * Constant: '<Root>/Constant' */ for (i = 0; i < 9; i++) { tmp[i] = rtb_TmpSignalConversionAtIn1Out [i] + 1.0; } ... Rte_IWrite_Runnable_Step_Output_Output(tmp); }
In R2015a, the generated code is traceable and more readable.
A hyperlink is generated for <Root>/In1
.
void Runnable_Step(void) { const real_T *tmp_In1; real_T tmp[9]; int32_T i; /* Inport: '<Root>/In1' */ tmp_In1 = Rte_IRead_Runnable_Step_Input_Element0(); /* Sum: '<Root>/Add' incorporates: * Constant: '<Root>/Constant' */ for (i = 0; i < 9; i++) { tmp[i] = rtb_tmp_In1[i] + 1.0; } ... Rte_IWrite_Runnable_Step_Output_Output(tmp); }
In AUTOSAR applications, the aliveTimeout
value
for an AUTOSAR port specifies the amount of time in seconds after
which the AUTOSAR software component must be notified if the port
has not received data according to a specified timing description.
In previous releases, arxml
export generated a
fixed aliveTimeout
value of 60 for each AUTOSAR
port, without providing a way to modify the aliveTimeout
value
in Simulink.
The software now allows you to configure an aliveTimeout
value
that subsequent arxml
exports generate for each
AUTOSAR port. For more information, see Configure
AUTOSAR Port aliveTimeout Value.
For shared axis (COM_AXIS) lookup tables, AUTOSAR code generation
now exports arxml
that supports run-time calibration
of lookup table parameters. To configure a lookup table for run-time
calibration, add an n-D
Lookup Table block to your model and configure it
for COM_AXIS data. For table data and axis data that you want to tune
or manipulate at run-time, reference AUTOSAR calibration parameters.
For more information, see Calibration
Parameters for COM_AXIS Lookup Tables.
As of R2015a, to verify code generated from AUTOSAR software component, use the SIL block.
For more information, see Verify AUTOSAR C Code with SIL and PIL.
R2014a introduced the ability to switch between two SIL block behaviors—legacy (ERT S-function) and unified (SIL block). The software also indicated that ERT S-function support for code verification would be removed in a future release. Starting in R2015a, for AUTOSAR code generation, use the SIL block.