Debug Requirements Table Blocks

Since R2023a

You can debug formal requirements in a Requirements Table block. The Requirements Table block includes some of the same debugging tools available in the MATLAB^® editor. To use the debugger, set a breakpoint on at least one the requirements and run the simulation. The Requirements Table block also checks for erroneous table cells as you create and edit requirements.

Add a Breakpoint to a Requirement Set

This example uses the model in Model Dice Game Rules Using a Requirements Table Block. To debug the Requirements Table block requirements:

Open the Requirements Table block, Dice Game Rules, in the example model, ReqTableDiceGame:
```
openExample('slrequirements/DiceGameReqTableBlockExample')
open_system("ReqTableDiceGame/Dice Game Rules");
```
Right-click the requirement with the index 1 and click Set Breakpoint. The requirement displays the breakpoint icon next to the index.
Select when the simulation pauses during the requirement evaluation. Click the breakpoint to expand the options:
- Before Checking Precondition — The simulation stops before the block checks the precondition.
- After Precondition is Valid — The simulation stops only if the precondition is true.
If you clear both of these options, the table removes the breakpoint. If you select both options, the block creates two breakpoints.
In this example, select Before Checking Precondition and clear After Precondition is Valid.
Simulate the model. The simulation pauses when execution reaches the breakpoint. The block highlights the precondition that the simulation stops at in green.

When the simulation pauses at a breakpoint, you can use buttons in the Debug tab to continue execution in other ways:

Button	Description
Continue	Continue execution to the next breakpoint.
Step Over	Advance to the next step in the requirement set execution. Possible steps include: Evaluate a precondition or postcondition Execute an action. Each action cell executes from left to right as you step over. If an action cell contains multiple lines, execute each line of the action as you step over.
Step In	From a precondition, postcondition, or action that calls a function, advance to the first executable statement in the function. Otherwise, advance to the next step in the requirement set execution. Each action cell executes from left to right as you step in. If an action cell contains multiple lines, execute each line of the action as you step in.
Step Out	From a function call, return to the requirement precondition, postcondition, or action calling the function. Otherwise, continue execution to the next breakpoint.
Stop	Exit debug mode and interrupt the execution.

In this example model, clicking Continue advances to the next time step or ends the simulation.

Using Multiple Breakpoints

You can add multiple breakpoints to a Requirements Table block. The block evaluates the listed requirement first and works downward. See Establish Hierarchy in Requirements Table Blocks.

In the Dice Game Rules block, add a breakpoint to the requirement with index 2, clear Before Checking Precondition, select After Precondition is Valid, and simulate the model. Click Continue to advance to the next breakpoint or the next time step. At the first time step, the requirement with index 2 does not pause the simulation. However, if the player sets the point value, the simulation pauses at both breakpoints at the following time step.

This image shows the table when the simulation pauses at the requirement with index 2. In the first time step, this requirement breakpoint is ignored. In the following time step, this requirement pauses at the action because the precondition is true. The actions highlight green.

Run the simulation again, but click Step Over or Step In instead. The debugger pauses at each step of the block execution. Depending on the roll, the debugger stops at only one of the actions, but evaluates several preconditions.

View the Simulation Status at the Breakpoints

You can view additional information about the breakpoints in the Breakpoints List pane. To open the pane, click a breakpoint and click Breakpoints List. The Breakpoints List pane displays five columns:

Column Header	Description
Enabled	Specifies whether the breakpoint is enabled. When you disable Before Checking Precondition and After Precondition is Valid on a requirement, the breakpoint icon is grey .
Source	Specifies the location of the breakpoint.
Source Type	Specifies whether the block checks the requirement before checking the precondition or after the precondition is valid.
Condition	Specifies a logical expression that must be true before the simulation pauses. Specify an expression by using Requirements Table block data and literal values. The expression must evaluate to a logical `true` (`1`) or `false` (`0`).
Hits	Specifies the number of times that the simulation pauses at the breakpoint.

In the Dice Game Rules block, the Breakpoints List pane lists two breakpoints. Run the model to see how many times each breakpoint pauses the simulation as you run the debugger. The pane highlights the breakpoint that the simulation pauses at.

This image shows the Breakpoints List pane at the second time step when the simulation pauses at the second breakpoint. The breakpoint that the simulation pauses at is highlighted green.

Watch Data Values During Simulation

You can track the data values in the block while you simulate by using the Symbols pane or the Command Window.

Watch Data Values in the Symbols Pane

To view the value of the data in the Symbols pane in a Requirements Table block during simulation:

Open the Symbols pane. In the Modeling tab, in the Design Data section, click Symbols Pane.
Add a breakpoint to the a requirement.
Run the model.
When the simulation pauses, the Symbols pane displays the values at the breakpoint. If the data is an array, the data column displays the dimension and data type of the data. In this example, the data are scalar.

This image shows an example of the data values in the Symbols pane when the debugger pauses at a breakpoint.

Watch Block Data with the Command Line Debugger

You can view the values for block data in the MATLAB Command Window. When you reach a breakpoint, enter the name of a data at the debug>> prompt to see its value and data type.

debug>> dice1

	int8        
	
	5

debug>>

You can also enter these commands in the Command Window while debugging:

Command	Description
`dbcont`	Continue execution to next breakpoint.
`dbstep [in\|out]`	Advance to next step of execution after encountering a breakpoint.
`dbquit`	Quit debugging and terminate the simulation.
`help`	Display help for command line debugging.
`print <data>`	Display the value of the data `data` at the current time step and breakpoint. If `data` is a vector or matrix, you can also index into `data`. For example, `data(1,2)`.
`save`	Save data at the current time step and breakpoint to the specified file. The command uses the syntax of the MATLAB `save` command. To retrieve data from the MATLAB base workspace, use `load` function after simulation completes.
`<data>`	Equivalent to `print <data>` if the data is defined in the block.
`who`	Display the data defined in the block.
`whos`	Display the size and type of the data defined in the block.

To issue a command in the MATLAB base workspace at the debug>> prompt, use the evalin command with the first argument "base" followed by the second argument command, for example, evalin("base","whos"). You cannot define or change data at the debug>> prompt.

Resolve Cell Errors

Table cell errors appear when the block identifies syntax errors or data that has not been defined in the Symbols pane. Point to or click the alert icon next to the cell to read the error message. If you run the simulation without addressing these problems, the Diagnostic Viewer displays details about the error.

The block does not detect all issues while editing the table cells. For instance, if the duration for a requirement evaluates to a vector or matrix, a compilation error occurs. These warnings and errors appear in the Diagnostic Viewer.