Establish Hierarchy in Requirements Table Blocks

Since R2022a

When defining requirements and assumptions in a Requirements Table block, you may decide that some requirements or assumptions must relate to one another in a hierarchy. For example, you may have a requirement precondition that you want to check only if another precondition is valid. Alternatively, you may have a requirement where your model must satisfy several preconditions before you check a postcondition. You can establish hierarchies by using child and semantic rows.

For more information on how to define requirements and assumptions, see Use a Requirements Table Block to Create Formal Requirements and Add Assumptions to Requirements.

Add Child Rows

Requirements and assumptions are organized in rows. You can organize the rows into a hierarchy by creating parent and child rows. Use child rows to determine evaluation hierarchy. For example, if a parent requirement precondition is valid, the block checks the preconditions of the child requirements. Otherwise, the block ignores the child preconditions.

To create child rows, right-click the index of a row and select Add Child Requirement or Add Child Assumption. If you want to move a row to a higher or lower hierarchy level, click the row index and select Make Parent or Make Child. You can delete and modify child rows by right-clicking the index of a child row and clicking Delete Requirement or Delete Assumption.

The index number of a child row is the index of the parent followed by the index of the child. You can have multiple child rows at each hierarchy level and multiple hierarchy levels. Rows in the same hierarchy level that have the same parent, or rows that do not have parent rows, are called siblings.

Use Child Rows in an Example Model

This example uses a Requirements Table block that has child requirements. The model tests a signal and outputs two values if the model behavior meets the parent and child requirements.

Open the Requirements Table block to see the parent and child requirements. If the input signal satisfies the precondition of the first requirement, the block executes the action and then tests the child requirements. In this example, the child requirements control the output data z. The second requirement executes if the input signal does not satisfy the precondition of the first requirement.

Run the simulation and open the Scope block to observe the block output.

Create Exclusive Exhaustive Requirements

You can use exclusive exhaustive requirements to create non-overlapping and complete child requirements. When you run the simulation, the Requirements Table block checks that exactly one child requirement is active at each time step. The block returns an error if more than one or no child requirement is active at any time step.

To make the children of a parent requirement exclusive exhaustive, right-click the index of the parent requirement and select Child Evaluation > Exclusive Exhaustive. The exclusivity icon indicates exclusive exhaustive requirements. When you specify child requirements as exclusive exhaustive, only the direct children of the selected parent requirement become exclusive exhaustive. Lower-level requirements are not exclusive exhaustive.

Add Semantic Rows

While designing your model, you may need to define rows that have several applicable preconditions. For example, you may have a requirement where only one precondition must be satisfied, or each of the preconditions must be simultaneously satisfied. The Requirements Table block allows you to construct these rows using semantic rows. Semantic rows evaluate two or more preconditions before checking the postconditions or executing the actions of a parent row.

To add a semantic requirement where only one child precondition must be satisfied before the parent requirement executes, right-click the requirement index and click Add Semantic Requirement > Any Child Active Active. You can perform the same task in the Assumptions Table by clicking Add Semantic Assumption > Any Child Active.

To add a semantic requirement that executes only if each of the child requirement preconditions are satisfied, right-click the requirement index and click Add Semantic Requirement > All Children Active. You can perform the same task in the Assumptions Table by clicking Add Semantic Assumption > All Children Active. For each kind of semantic row, the table dims cells that cannot be filled and indicates the logic used by the children in each parent. This table illustrates what each semantic requirement looks like.

You can specify the duration in the parent or in individual children. For more information on the duration, see Using the Duration Column. If you specify the duration in a child, the duration applies only to the child. If you specify the duration for the parent, the block checks the duration only if the semantic is satisfied.

If you want to switch the semantic row type, point to the precondition cell of the parent row. The option to switch between Any Child Active and All Children Active appears at the bottom of the cell.

Create Default Requirements

If you want to define behavior that occurs if none of the sibling requirements are met, include a default requirement. Right-click the index of the sibling requirement and click Add Semantic Requirement > Default.

You can specify multiple default requirements for each group of siblings. For example, this table has two requirements that each contain two child requirements and a default requirement. The default requirement executes only if the parent precondition is true and if the siblings are false.

Use Semantic Rows in an Example Model

This example uses a Requirements Table block with semantic requirements. The model tests two signals and adjusts the output if the model behavior meets the semantic requirement preconditions.

Open the block. The block contains two semantic requirements and a default requirement:

• If the input u1 satisfies the precondition of the first child and the input u2 satisfies the precondition of the second child, the block sets the output y to 2.

• Otherwise, if either the first or second preconditions for the children of the second requirement are true, then the block sets y to 1.

• If the semantic requirement preconditions are not satisfied, the block executes the action of the default requirement and sets y to 0.

Run the model and open the Scope block to observe the block output.