Variant Condition Propagation with Variant Sources and Sinks

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.

View Variant Condition Annotations

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.

How Variant Condition Propagation Works

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.

Cross-Coupling of Inputs and Outputs

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.

Cascading Blocks and Compounding Conditions

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.

Hierarchical Nesting of Sources or Sinks

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.

Condition Propagation with Subsystems

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.

Condition Propagation with Other Simulink Blocks

Variant Condition Propagation with Model Block

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.

Variant Condition Propagation with Simulink Function block

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.

Variant Condition Propagation with Initialize, Reset, and Terminate Blocks

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.

Variant Condition Propagation with Subsystem Block

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.

Variant Condition Propagation with Bus

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.

Known Limitations

  • 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.

Related Examples

More About