Analyze Requirements Table Blocks for Modeling Problems

Since R2022a

If you have Simulink^® Design Verifier™, you can validate requirements in the Requirements Table block by analyzing the block for modeling problems. The problems detected by analysis generate errors during simulation, but they can be difficult to detect manually. When you analyze the table, you can also choose to include the entire model in the analysis.

Table analysis detects these issues:

If the block can execute a scenario where at least one data is not assigned a value, the requirement set is incomplete. See Incompleteness Issues.
If at least one data defined in the requirement set can equal more than one value during simulation, the requirement set is inconsistent. See Inconsistency Issues.
If you define requirements that use data before the data is written, the requirement set can cause a read-before-write error. See Detect Read-Before-Write Issues.
If more than one or no exclusive exhaustive requirements are active, the requirements have exclusivity issues. See Detect Exclusivity Issues in the Requirements Table Block.

Analyze the Table

To analyze the requirements, open the Requirements Table block. In the Table tab, in the Analyze section, click Analyze Table. If there are issues in the block, the Analysis Results pane displays additional information.

Analysis results for a requirements table with one inconsistency and one incompleteness issue

Include the Entire Model in Analysis

By default, the Requirements Table block assumes that input data is independently generated. If the input data is not independent, you may need to over-specify your requirements to prevent issues. You can prevent this problem by:

Configuring the block to identify the source of the data in the context of the entire model. In the Table tab, in the Analyze section, expand the Analyze Table menu and enable Include entire model.
Specifying assumptions based on how physical or mathematical limitations prevent data from being certain values. See Add Assumptions to Requirements.

Analysis Limitations for Flexible Requirements

Depending on how you define the relationships between data, you can establish two kinds of requirements: rigid and flexible. In addition to individual requirements, sets of requirements in the block can also be rigid or flexible.

Rigid Requirements

If a requirement postcondition specifies an exact value, or if the requirement specifies only an action, the requirement is rigid. You express these requirement postconditions with the double equals sign ==. For example, a requirement with a postcondition y == 0 is rigid. If each requirement in the requirement set is rigid, then the requirement set is rigid.

Flexible Requirements

If a requirement postcondition can satisfy a range of values, then the requirement is flexible. For example, a requirement with a postcondition y >= 0 or y >= 0 && y < -2 is flexible. Additionally, postconditions that specify multiple values also create flexible requirements. For example, a requirement with a postcondition u == 3 || u == 4 is flexible. If at least one requirement in the requirement set is flexible, then the entire requirement set is flexible.

If the requirements are flexible, you cannot use table analysis if the requirements use:

Persistent variables.
Arrays as Requirements Table block outputs, or inputs with the Treat as design model output for analysis property enabled.
Incompatible functions cause an error when analyzing the table. The error message identifies the responsible function.