Handle Incompatibilities with Automatic Stubbing

What Is Automatic Stubbing?

Stubbing in Simulink^® Design Verifier™ is the process of replacing certain parts of a model with simpler representations or "stubs" to facilitate analysis.

Automatic stubbing lets you analyze a model that contains objects that Simulink Design Verifier does not support. This technique allows the software to complete the analysis.

How Automatic Stubbing Works

When the Simulink Design Verifier analysis comes to an unsupported block, the software “stubs” that block. The analysis ignores the behavior of the block, and as a result, the block output can take any value.

Stub Trigonometric Function Block

Simulink Design Verifier does not support Trigonometric Function blocks when the Function parameter is set to acos, such as the one in the following graphic.

When stubbing this block during analysis, out_signal can take any value, with the following results.

Analysis Model	Result of Stubbing out_signal
Design error detection	If a design-error objective that depends on out_signal is proven valid, that objective is valid for all simulations. In this case, the stubbing did not affect the results of the analysis. If a design-error objective that depends on out_signal is falsified, the analysis cannot create a test case. The analysis cannot determine which input to the stubbed block produces the output that falsifies the objective.
Test case generation	If a test objective that depends on the value of out_signal is satisfied, the analysis cannot create a test case. The analysis cannot determine which input to the stubbed block produces the output that satisfies the objective. If a test objective that depends on the value of out_signal is unsatisfiable, there is no simulation that can satisfy that objective. In this case, the stubbing did not affect the results of the analysis.
Property proving	If a proof objective that depends on out_signal is proven valid, that objective is valid for all simulations. In this case, the stubbing did not affect the results of the analysis. If a proof objective that depends on out_signal is falsified, the analysis cannot create a counterexample. The analysis cannot determine which input to the stubbed block produces the output that falsifies the objective.

Stub S-Function Block Containing Function-Call Triggers

The Simulink example model sfcndemo_sfun_fcncall has an S-Function block. The S-function sfun_fcncall triggers the execution of the function-call subsystems f1 subsys1 and f2 subsys2 on the first and second elements of the first output port.

If you do not enable support for an S-function in Simulink Design Verifier, the analysis ignores the behavior of the S-function. As a result, the code that triggers the two function-call subsystems is ignored, resulting in two unsatisfiable objectives. Since the function calls are ignored, the contents of those subsystems are effectively eliminated from the analysis.

To enable support for an S-function in Simulink Design Verifier, see Support Limitations and Considerations for S-Functions and C/C++ Code

Impact of Automatic Stubbing on the analysis

The following model contains a Discrete State-Space block, which is not compatible with Simulink Design Verifier.

Review Results

If you run an analysis, make sure to review the results. In the Simulink Design Verifier analysis report you can see a table of unsupported blocks that Simulink Design Verifier encounters.

Unsupported Blocks

The generated analysis report for the example model shows that the objectives are undecided because of stubbing. The Simulink Design Verifier analysis cannot generate test cases because it does not understand the operation of the Discrete State-Space block.

Objective Undecided Due to Stubbing

Achieve Complete Results

You can define custom block replacements to give a more precise definition of the unsupported blocks. For more information, follow the steps in Block Replacements for Unsupported Blocks.