Propagate Variant Conditions to Define Variant Regions Outside Variant Subsystems

Simulink^® propagates variant conditions from Variant Subsystem blocks to their connecting blocks. The propagation of variant conditions enables Simulink to determine which components of the model remain active during simulation. Simulink then deactivates the model components associated with the inactive choices and highlights the active connections. By default, variant conditions do not propagate outside the Variant Subsystem block. To allow variant conditions to propagate to the connecting blocks, select the Propagate conditions outside of variant subsystem parameter on the Variant Subsystem block. For more information about the Variant Subsystem block, see Variant Subsystem, Variant Model, Variant Assembly Subsystem.

Tip

Variant condition annotations on model components help you visualize the propagated conditions. To view the annotations, on the Debug tab, select Information Overlays > Variant Legend. If Variant Legend is not available, on the Debug tab, select Information Overlays > Variant Conditions. For more information, see Visualize Propagated Variant Conditions in Variant Conditions Legend.

Factors That Affect Propagation of Variant Conditions Outside of Variant Subsystem Blocks

The propagation of variant conditions outside of a Variant Subsystem block depends on the variant activation time of the block and the interface of the underlying variant choices. The Variant activation time parameter determines if Simulink must analyze only the active choice or both active and inactive choices of the block when simulating the model. If the interface of the analyzed variant choices matches the interface of the Variant Subsystem block, the variant conditions do not propagate outside the Variant Subsystem block. In other words, if the analyzed variant choices use all the input and the output signals of the Variant Subsystem block, the variant conditions do not propagate outside of the block. The variant conditions propagate outside of the Variant Subsystem block only if the interfaces do not match.

Adaptive Interface for Variant Subsystems

This example shows how propagating variant conditions outside a Variant Subsystem block enables the block to adapt its interface according to the states of the underlying blocks for different activation times. The example also explains the code that is generated for different activation times. For information on factors that affect the propagation, see Factors That Affect Propagation of Variant Conditions Outside of Variant Subsystem Blocks.

Consider the slexVariantSubsystemsAdaptiveInterface model containing a Variant Subsystem block named Controller with two variant choices, Linear and Nonlinear. The Linear controller is active when V == 1, and the Nonlinear controller is active when V == 2. V is a variant control variable and is defined in the PreLoadFcn callback of the model.

To change the value of the variant control variable, in the MATLAB™ Command Window, type V = 1 or V = 2.

Double-click the Controller block to view its contents. The Linear and Nonlinear controller blocks do not have the same interface. The inports sensor1 and sensor3 are used in Linear controller and Nonlinear controller blocks, but sensor2 is used only in Linear controller block. Hence, the sensor2 block is active only when the Linear controller is active and is not executed when the Nonlinear controller is active. To make the model components outside the Controller block aware of the active or inactive state of blocks within the Controller block, the block variant conditions must propagate outside the boundaries of the block. To propagate the variant conditions outside of the Controller block, select Propagate conditions outside of variant subsystem in the Block Parameters dialog box of the block. By default, this parameter is set to off.

To simulate the model and generate code for Linear and Nonlinear controllers, perform these steps:

1. In the Block Parameters dialog box of the Controller block, set an activation time in the Variant activation time parameter.

2. To activate the Linear controller and its connected blocks, change the value of V to 1.

3. Simulate the model and observe the propagated conditions as described in Propagation with Different Activation Times.

4. Generate code from the model by using Embedded Coder®. For information on how to generate the code, see Generate Code Using Embedded Coder (Embedded Coder). Observe the results as described in Propagation with Different Activation Times.

Note

In the model, the saturate port is an unconnected output port and so it is not included in the generated code for any variant activation times.

5. Similarly, to activate the Nonlinear controller and its connected blocks, change the value of V to 2 and simulate the model. Generate code from the model and observe the results.

Propagation with Different Activation Times

This section explains the simulation results and the code generated for Linear and Nonlinear controllers with different activation times.

Propagate Variant Conditions for update diagram Activation Time

This table compares the propagation of variant conditions and the generated code for the Linear and Nonlinear controller choices for update diagram activation time.

When V == 1 and Linear controller is active

When V == 2 and Nonlinear controller is active

Only the Linear controller is analyzed. The Linear controller uses only the sensor1, sensor3 and u ports, so these ports and their connected blocks are active. The Linear controller does not use the sensor2 and saturate ports, so these ports and their connected blocks are inactive. Since the interface of the Linear controller is different from the interface of the Controller subsystem, the variant conditions are propagated outside of the subsystem. The variant conditions are propagated only to the ports that are not used by at least one of the variant choices. In this example, the variant annotation v:2 with condition set to false propagates to sensor2, saturate, and all their connected blocks. In the Variant Conditions Legend, a variant condition is set to false if the blocks associated with that variant condition are never active. The code that you generate contains only the active ports. In this example, the input port In2 is inactive, so it is not part of the generated code. //slexVariantSubsystemsAdaptiveInterface.h /* External inputs (root inport signals with default storage) */ typedef struct { real_T In1; /* '<Root>/In1' */ real_T In3; /* '<Root>/In3' */ } ExternalInputs; /* External outputs (root outports with default storage) */ typedef struct { real_T u; /* '<Root>/u' */ } ExternalOutputs; The active choice is unconditional. The unconditional statements are not enclosed in any conditional statements and are compiled or executed irrespective of the state of the variant choices. //slexVariantSubsystemsAdaptiveInterface.c /* Model step function */ void step(void) { // Logic for Linear choice } /* Model initialize function */ void initialize(void) { /* (no initialization code required) */ }

Only the Nonlinear controller is analyzed. The Nonlinear controller uses all the input and output ports of the Controller subsystem block, so all the input ports, sensor1, sensor2, and sensor3, and all their connected blocks are active. Also, both output ports, u and saturate, and all their connected blocks are active. Because the interface of the Nonlinear controller matches the interface of the Controller subsystem, the variant conditions do not propagate outside of the Controller subsystem block. The code that you generate contains only the active ports. In this example, all the input and the output ports are active and so they are part of the generated code. //slexVariantSubsystemsAdaptiveInterface.h /* External inputs (root inport signals with default storage) */ typedef struct { real_T In1; /* '<Root>/In1' */ real_T In2; /* '<Root>/In2' */ real_T In3; /* '<Root>/In3' */ } ExternalInputs; /* External outputs (root outports with default storage) */ typedef struct { real_T u; /* '<Root>/u' */ } ExternalOutputs; The active choice is unconditional. The unconditional statements are not enclosed in any conditional statements and are compiled or executed irrespective of the state of the variant choices. /* Model step function */ void step(void) { // Logic for Nonlinear choice } /* Model initialize function */ void initialize(void) { /* (no initialization code required) */ }

Note

When propagating the variant conditions outside of a Variant Subsystem with update diagram activation time:

• If you set Allow zero active variant controls to on, Simulink propagates the variant conditions to all the blocks (including the unconditional or always true blocks) of the variant region. Propagating conditions to all the blocks of the variant region enables Simulink to completely remove the variant region from the model when none of the variant choices are active.

• The code that you generate is the same regardless of the setting of Allow zero active variant controls.

Propagate Variant Conditions for update diagram analyze all choices Activation Time

This table compares the propagation of variant conditions for the Linear and Nonlinear controller choices with update diagram analyze all choices activation time. The generated code is the same as update diagram.

When V == 1 and Linear controller is active

When V == 2 and Nonlinear controller is active

The Linear controller and Nonlinear controller choices are analyzed. The Linear controller uses only the sensor1, sensor3 and u ports, so these ports and their connected blocks are active. The Linear controller does not use sensor2 and saturate ports, so these ports and their connected blocks are inactive. Since the interface of the Linear controller does not match the interface of the Controller subsystem, the variant conditions propagate outside of the Controller subsystem block. The variant conditions propagate only to the ports that are not used by at least one of the variant choices. In this example, the variant with annotation v:1 and with variant condition set to V == 2 propagates to the sensor2, saturate, and their connected blocks.

The Linear controller and Nonlinear controller choices are analyzed. The Nonlinear controller uses all the input and output ports of the Controller subsystem, so all the input ports, sensor1, sensor2, and sensor3, and all their connected blocks are active. Also, both output ports, u and saturate, and all their connected blocks are active. Since the interface of the Linear controller does not match the interface of the Controller subsystem, the variant conditions propagate outside of the Controller subsystem block. The variant conditions propagate only to the ports that are not used by at least one of the variant choices. In this example, the variant with annotation v:1 and with variant condition set to V == 2 propagates to sensor2, saturate, and their connected blocks.

Note

When propagating variant conditions outside of a Variant Subsystem with update diagram analyze all choices activation time:

• If you set Allow zero active variant controls to on, Simulink propagates the variant conditions to the all the blocks (including the always trueor unconditional blocks) of the variant region. Propagating conditions to all the blocks of the variant region enables Simulink to completely remove the variant region from the model when none of the variant choices are active.

• The code that you generate is the same regardless of the setting of Allow zero active variant controls.

Propagate Variant Conditions for code compile Activation Time

The propagation of variant conditions for Linear and Nonlinear controller choices with code compile activation time is the same as propagation with update diagram analyze all choices. The code that is generated for the Linear and Nonlinear controllers is as shown.

The code contains Linear and Nonlinear choices enclosed in necessary preprocessor conditionals #if and #elif.

//slexVariantSubsystemsAdaptiveInterface.c
/* Model step function */
void step(void)
{
#if V == 1 
  // Logic for Linear choice
#elif V == 2  
 // Logic for Nonlinear choice
}
/* Model initialize function */
void initialize(void)
{
  /* (no initialization code required) */
}

The port sensor2, which is not used by all the variant choices, is also enclosed in preprocessor conditional #if.

//slexVariantSubsystemsAdaptiveInterface.h
External inputs (root inport signals with default storage)*/
typedef struct {
  real_T In1;                /* '<Root>/In1' */
	
#if V == 2
  real_T In2;                /* '<Root>/In2' */

#define EXTERNALINPUTS_VARIANT_EXISTS
#endif

  real_T In3;                /* '<Root>/In3' */
} ExternalInputs;
// External outputs (root outports fed by 
// signals with default storage)
typedef struct {
  real_T u;
} ExternalOutputs;

Note

When propagating variant conditions outside of a Variant Subsystem block with the code compile activation time, if you set Allow zero active variant controls to on, Simulink propagates the variant conditions to all the blocks (including the always true or unconditional blocks) of the variant region. In the generated code, the blocks of the variant region are enclosed in an additional variant condition that is the logical OR of conditions from the variant choices. This enables Simulink to remove the variant regions completely from the model when none of the variant choices are active. In this example, the always true blocks In1 and In3, and the variant choices Linear and Nonlinear are enclosed in the logical OR of variant conditions, V == 1 || V == 2. When V == 1 and V == 2 each evaluate to false, Simulink skips the compilation of these blocks thus removing the variant regions completely.

Propagate Variant Conditions for startup Activation Time

The propagation of variant conditions for the Linear and Nonlinear controller choices with startup activation time is the same as propagation with update diagram analyze all choices activation time.

The code that is generated for the Linear and Nonlinear controllers is as shown.

The code contains Linear and Nonlinear choices enclosed in regular if and else if conditions.

//slexVariantSubsystemsAdaptiveInterface.c
/* Model step function */
void step(void)
{
if (V == 1) 
  // Logic for Linear choice
else if (V == 2)  
 // Logic for Nonlinear choice
}
/* Model initialize function */
void initialize(void)
{
  startupVariantChecker();
}
static void startupVariantChecker(void)
{
  /* startup variant condition checks */
  utAssert((rtP.V == 1.0) + (rtP.V == 2.0) == 1);
}

The ports are unconditional.

//slexVariantSubsystemsAdaptiveInterface.h
/* External inputs (root inport signals with default storage) */
typedef struct {
  real_T In1;                          /* '<Root>/In1' */
  real_T In2;                          /* '<Root>/In2' */
  real_T In3;                          /* '<Root>/In3' */
} ExternalInputs;

// External outputs (root outports fed by signals
// with default storage) */
typedef struct {
  real_T u;                            /* '<Root>/u' */
} ExternalOutputs;

Note

When propagating variant conditions outside of a Variant Subsystem block with the startup activation time, if you set Allow zero active variant controls to on, Simulink propagates the variant conditions to all the blocks (including the always true or unconditional blocks) of the variant region. In the generated code, the blocks of the variant region are enclosed in an additional variant condition that is the logical OR of conditions from the variant choices. This enables Simulink to remove the variant regions completely from the model when none of the variant choices are active. In this example, the always true blocks In1 and In3, and the variant choices Linear and Nonlinear are enclosed in the logical OR of variant conditions, V == 1 || V == 2. When V == 1 and V == 2 each evaluate to false, Simulink skips the compilation of these blocks thus removing the variant regions completely.

Propagation Without Inport and Outport Blocks

Consider this model with a Variant Subsystem block that has two variant choices. There are no inports or outports on the block. The two variant choices have the variant conditions Var == 1 and Var == 2, respectively. When you set the Propagate conditions outside of variant subsystem parameter of the Variant Subsystem block to off, a logical OR of the variant conditions, Var == 1 || Var == 2, is set on the Variant Subsystem block. When the parameter is set to on, no variant conditions are applied on the Variant Subsystem block.

Limitations

Propagated variant conditions from variant subsystems can be set on Simscape™ or Stateflow^® blocks only for the update diagram variant activation time.

Related Topics

• Implement Variations in Separate Hierarchy Using Variant Subsystems
• Propagate Variant Conditions to Define Variant Regions with Variant Blocks
• Propagate Variant Conditions to Define Variant Regions Using Variant Source and Variant Sink Blocks

×

Apri esempio

Si dispone di una versione modificata di questo esempio. Desideri aprire questo esempio con le tue modifiche?

No, sovrascrivi la versione modificata Sì