When you specify variant conditions in models containing Variant Source and Variant Sink blocks, Simulink® propagates these conditions to determine which components of the model are active during simulation.
When you create a model that contains Variant Source or Variant Sink blocks, you can visualize the conditions that activate each variant choice. Simulink annotates these blocks in the model with their corresponding variant conditions.
Consider this model containing multiple variant choices feeding into Variant Source blocks. A specific variant condition activates each variant choice.
To visualize the variant conditions, on the Debug tab of toolstrip, select Information Overlays > Variant Conditions.
The Variant Condition Legend dialog box appears. Variant
conditions on blocks are annotated as v:C
, where
v
is the variant semantic indicator and C
represents the variant condition index. The dialog box also shows the expression
associated with each condition.
In the Variant Condition Legend dialog box, you can click
through the hyperlinked variant annotations to observe which parts of the model each
condition activates. For example, if you click v:3
, Simulink highlights the parts of the model that are activated when the
condition V==3
evaluates to true
.
Variant condition annotations have these properties:
There are no annotations on unconditional blocks. Therefore, the
Out
block is not annotated.
To reduce clutter, the legend only displays the final computed conditions. For example, if you enter a variant condition in a Variant Source block, that condition appears in the annotations only when you apply your changes.
The conditions in the legend are sorted during display.
In the legend, a condition is set to false
if
Simulink assesses that the
blocks associated with that condition are never active.
For example, the Inport4
block is connected to the
Variant Source1
block, whose condition is
V==1
. Variant Source1
is connected
to the Variant Source2
block, which activates
Variant Source1
only when V==4
.
Therefore, Inport4
can only be active when V==1
&& V==4
, a condition that is always
false
.
In the legend, the (default)
keyword is displayed as
negated condition.
When you compile a model containing Variant Source or
Variant Sink blocks, Simulink determines which variant control evaluates to true
.
The active variant determination happens in the early stage of compilation.
Simulink then deactivates blocks that are not tied to the variant control being
true
and visualizes the active connections.
In this model, two inputs feed the Variant Source block. The
first input is active when Var == 1
, and it branches into the
second input before connecting to the Variant Source block. The
second input is the default variant choice.
During simulation, this model exhibits three modes of operation:
When Var == 1
, the first input is active and
its branch into the second input is inactive.
When Var == 1 || Var == 2
, the second input is
active and the branch of the first input is active.
When Var == 2
, the second input is active and
the output is active.
In this model, two Variant Source blocks, each fed by two input
ports, are connected in a cascading manner. The inputs to Variant
Source
are active when Var1 == 1
or
Var1 == 2
. The output of Variant
Source
branches into one of the inputs of Variant
Source1
. The inputs toVariant Source1
are
active when Var2 == 1
or Var2 == 2
.
During simulation, this model exhibits eight modes of operation:
When Var1 == 1 && Var2 == 1
, the first
inputs of Variant Source
and Variant
Source
are active.
When Var1 == 1 && Var2 == 2
, the first
input of Variant Source
and the second input of
Variant Source1
are active.
When Var1 == 2 && Var2 == 1
, the second
input of Variant Source
and the first input of
Variant Source1
are active.
When Var1 == 2 && Var2 == 2
, the second
inputs of Variant Source
and Variant
Source1
are active.
When Var1 == 1 && Var2 != (1,2)
, only
the first input of Variant Source
is
active.
When Var1 == 2 && Var2 != (1,2)
, only
the second input of Variant Source
is
active.
When Var1 != (1,2) && Var2 == 1
, none
of the inputs or outputs is active.
When Var1 != (1,2) && Var2 == 2
, only
the second input of Variant Source1
is
active.
When Var1 != (1,2) && Var2 != (1,2)
,
none of the inputs or outputs is active.
In this model, multiple Variant Source blocks are used to
create hierarchical nesting of variant choices. Choices are first grouped by
series: A Series
, B Series
, and C
Series
. A combination of one or more series is provided as input
for a device model. The resulting device model is provided as input to the
vendor by including or excluding a sensor selection.
Simulink propagates complex variant control conditions to determine which model components are active during compilation.
For more information, see Variant Sensors.
A subsystem can either be a virtual (grouped or ungrouped) or an atomic subsystem depending on the selections made in its Block Parameters dialog box. For,
Grouped Virtual: Select the Treat as grouped when propagating variant conditions check box. A grouped virtual subsystem has a continuous line.
Ungrouped Virtual: Clear the Treat as grouped when propagating variant conditions check box. An ungrouped virtual subsystem has a dotted line.
Atomic: Select the Treat as atomic unit check box. An atomic virtual subsystem has a solid line.
Simulink propagates variant conditions differently to these Subsystem types.
In this model, three types of subsystems are provided as input to the block
Variant Source2
.
The grouped virtual subsystem is activated when V == 1
.
Simulink propagates the
variant activation condition to all the blocks in the subsystem.
The ungrouped virtual subsystem is activated when V ==
2
. Simulink
propagates the variant activation condition to the blocks that were
available in the subsystem while marking the subsystem virtual.
The atomic subsystem is activated when V == 3
.
Simulink does not propagate
the variant activation condition into this subsystem.
For more information, see Propagating Variant Conditions to Subsystems.
Simulink compiles referenced models before propagating variant conditions. A variant condition can activate or deactivate a Model block, but variant conditions cannot propagate into the referenced model. A Model block can propagate variant conditions from its interface (input, output, or control port), if that variant condition originates at a port inside the model.
In this example, variant condition V==1
activates the
Model block iv_20_model_reference_sub
.
However, the condition does not propagate into the model referenced by the
block. Model block iv_20_model_reference_sub2
propagates the same variant condition from its output port.
Argument Inport and Argument Outport blocks interfacing with Simulink Function blocks cannot be connected to Variant Source or Variant Sink blocks. One variant condition must control the entire Simulink Function.
Consider the model slexVariantSimulinkFunctionInherit.
In this example, the function-call port block within the Simulink
Function block has the Enable variant condition
option selected. The (inherit)
keyword is used to specify the
value for the Variant control parameter. As a result, the
Simulink Function block inherits the variant condition from
the corresponding Function Caller blocks in the model. The
Generate preprocessor conditionals parameter value is
also inherited.
Note
Use the Configure C Step Function Interface dialog box to customize the generated C entry-point step function interface for a model. If input and output ports share an argument name and have propagated variant conditions, this level of interface control is not supported.
The Initialize, Reset, and Terminate function blocks are pre-configured subsystem blocks that execute during model initialize, reset, and terminate events. Similar to a Simulink Function block these blocks support variant condition propagation. You can propagate Variant conditions in Model blocks that have Reset Event ports. This results in optimized existence of blocks connected to the Reset Event ports. Models with inactive Variant Reset Event functions (in referenced models) also supports Variant condition propagation.
Note
Initialize and Terminate event ports are always unconditional because they control both the model default and block-specific initialize and terminate events of the referenced model. If you define an Initialize / Terminate function block in the referenced model, it corresponds to an explicit initialize / terminate event.
If you enable variants and define a variant condition on the Initialize / Terminate function block in the referenced model, the variant condition will not contribute to the model reference block instance’s variant condition.
In this example, the Event Listener
block within the
Init
, Reset
, and
Term
blocks have the Enable variant
condition option selected. The Variant
control parameter of the Event Listener
block
is specified as V==0
. If you change the value of
V
to any value other than 0
, the
Init
, Reset
, and
Term
blocks become inactive.
A variant condition can activate or deactivate a Subsystem block, but variant conditions cannot propagate into the subsystem. A Subsystem block can propagate variant conditions from its output port if that variant condition originates at a port inside the subsystem.
For more information, see Propagating Variant Conditions to Subsystems.
A Variant Source block can accept either virtual or nonvirtual bus inputs. When generating code with preprocessor conditionals, the bus types and hierarchies of all bus inputs must be the same.
However, all elements of a Mux, Demux, or a Vector Concatenate block signal must have the same variant condition.
For more information, see Variant Condition Propagation with Bus.
Variant condition propagation from Simulink Function inside Stateflow block is not supported.
When you simulate an Inline variants model with Simscape™ blocks, the Simscape blocks become unconditional.
C++ code generation is not supported for models that contain propagated variant conditions.
Variant condition propagation is not supported with root bus element ports.