Troubleshoot Requirements Table Blocks
When using a Requirements Table block, you can resolve syntax errors, identify inconsistent and incomplete requirement sets, and find read-before-write errors. These problems can depend on semantic errors in individual requirements or can be caused by issues in the requirement set.
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 alert message. If you run the simulation without addressing these problems, the Diagnostic Viewer populates with details.
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 errorf occurs. These warnings and errors appear in the Diagnostic Viewer.
Analyze the Block for Requirement Set Issues
Formal requirements must uniquely define the data used in the preconditions, postconditions, and actions at each simulation time step. Three scenarios can violate this principle:
If the block can execute a scenario where at least one data is not assigned a value, the requirement set is incomplete.
If at least one data defined in the requirement set can equal more than one value during simulation, the requirement set is inconsistent.
If you define requirements that use data before the data is written, the requirement set can cause a read-before-write error.
Typically, these scenarios generate an error during simulation, but they can be difficult to detect manually. If you have Simulink® Design Verifier™, you can detect the causes of the scenarios. To analyze the requirements, open the Requirements Table block. In the Table tab, in the Analyze section, click Analyze Table. For more information, see Troubleshoot Requirements Table Blocks.
Inconsistency issues occur when the block can perform different behaviors for a single combination of input values. For example, the table below illustrates inconsistent requirements. When analyzed, it finds two inconsistency issues, which are highlighted red and include an alert icon .
The Analysis Results pane displays additional details on the inconsistency issues.
Requirements have incompleteness issues when the block does not comprehensively specify outputs for possible input values. For example, in the model used in the Generate Model Behavior example, the table includes two incompleteness issues.
You can fix these issues by introducing requirements that define when
u2 are less than or equal to
0, or by creating an assumption that constrains
u2 to be greater than or equal to
0. For more
information about how to write assumptions, see Add Assumptions to Requirements.
Read-before-write issues occur when a requirement attempts to read data that has not
yet been defined. In most cases, you can minimize the potential for read-before-write
issues by not calling output data in preconditions and postconditions, or by specifying
the requirements in order. For more information, see Establish Hierarchy in Requirements Table Blocks. For example,
in this table, the first requirement reads the output data
y2 has an assigned value.
When you analyze the requirements, the block detects a read-before-write issue.
You can create requirement preconditions that rely on output data if you list the requirements in order and enable the Enable outputs in preconditions property in the block. See Enable outputs in preconditions. For example, the model used in Example Using Requirement Order does not produce requirement issues because the requirement order specifies the local data before the other requirements need it. If you change the order of the requirements so that Requirements 3 and 4 are listed first, then analyze the requirements, the analysis finds two read-before-write issues.
If you write more than two requirements that read the same data before the data is written, the analysis detects the issue in only the first listed requirement with the issue. After resolving the issue, rerun the analysis to detect the next read-before-write 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 find that you must over specify your requirements to prevent issues. You can prevent this problem by doing the following:
Configure 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.
Specify assumptions based on how physical or mathematical limitations prevent data from being certain values. See Add Assumptions to Requirements.
Analyze Rigid and 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.
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
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.
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.
You can analyze the Requirements Table block with some features only if the requirement set is rigid. These features include:
Using arrays as Requirements Table block outputs, or inputs with the Treat as design model output for analysis property enabled.
Some functions. Incompatible functions will cause an error when analyzing the table. The error message identifies the responsible function.