What Is Block Replacement?
Using Simulink® Design Verifier™, you can define rules to replace blocks automatically in your model. For example, you can work around a block that is incompatible with the software by creating a rule that replaces an unsupported Simulink block in your model with a supported block that is functionally equivalent. Or, you can customize blocks for analysis by creating a rule that adds constraints or objectives to particular blocks in your model.
When performing block replacements, the software makes a copy of your model and replaces blocks in the copy, without altering your original model. In this way, you can easily customize a model for analysis.
The Simulink Design Verifier software replaces blocks automatically in a model using:
Libraries of replacement blocks
Rules that define which blocks to replace and under what conditions
You replace any block with any built-in block, library block, or subsystem.
Block replacements are extensible, allowing you to define your own libraries of replacement blocks and custom block replacement rules. Using block replacements, you can
Work around an incompatibility, such as the presence of unsupported blocks in your model.
Customize a block for analysis, such as:
Adding constraints to its input signals
Adding objectives to its output signals
Eliminating the contents of a subsystem or Model block to simplify your analysis
Note
You can use automatic stubbing as an alternative to block replacements to resolve incompatibilities. Automatic stubbing replaces unsupported blocks with elements that have the same interface. For more information, see Handle Incompatibilities with Automatic Stubbing.
Block Replacement Effects on Test Generation
Replacing blocks can affect test case generation if the replaced blocks share functionality with other parts of your model. Before you replace blocks, understand functional dependencies on those blocks or on shared signals. See Highlight Functional Dependencies. Replacement blocks can also affect other analysis workflows such as property proving.
For example, you can customize a block for analysis using a replacement block that adds objectives to an input signal. If another subsystem depends on that signal, the replacement block effectively adds an objective for the subsystem.
In this example, the breakpoint range of u1 in
the 2-D Lookup Table is 5–7. The switch
threshold 8 falls outside the u1 lookup
table range.
Tests generated without replacing the 2D Lookup Table satisfy
two objectives: that the trigger is not greater than the Switch block
threshold 8, and that the trigger is greater than
the Switch block threshold 8.
Objective Satisfied
Test generation with block replacement returns a different analysis.
The blkrep_rule_lookup2D_normal.m block replacement
rule replaces the 2D Lookup Table with a masked subsystem containing
the 2D Lookup Table and a verification subsystem.
The verification subsystem constrains the analysis within the
breakpoint bounds of the table. The additional constraints prevent
generating tests that exercise the second objective for the Switch block.
The condition that the input signal In1 > 8 is
unsatisfiable.
Objectives Satisfied
Objectives Proven Unsatisfiable
