Main Content

Requirements Table

Model formal requirements with input conditions

expand all in page
  • Library:

  • Requirements Toolbox

  • Requirements Table block icon.

Description

The Requirements Table block models formal requirements. The block starts with evaluating conditions listed in the Precondition column. If the conditions are satisfied, you can check if other simulation data meet specified conditions in the Postcondition column, or execute desired actions, such as block outputs or functions, in the Action column. For more information, see Use a Requirements Table Block to Create Formal Requirements.

You can also constrain requirements based on physical limitations of your model by defining assumptions in the Assumptions tab. See Add Assumptions to Requirements.

You can configure this block only if you have Requirements Toolbox™.

Ports

Input

expand all

Input port, specified as a scalar, vector, or matrix. Each input data that you define has a corresponding input port.

Dependencies

To create input ports, open the block and create input data in the Symbols pane. See Define Data in Requirements Table Blocks.

Data Types: single | double | int8 | int16 | int32 | int64 | uint8 | uint16 | uint32 | uint64 | Boolean | string | fixed point | enumerated | bus

Output

expand all

Output port, specified as a scalar, vector, or matrix. Each output data that you define has a corresponding output port.

Dependencies

To create output ports, open the block and create output data in the Symbols pane. See Define Data in Requirements Table Blocks.

Data Types: single | double | int8 | int16 | int32 | int64 | uint8 | uint16 | uint32 | uint64 | Boolean | string | fixed point | enumerated | bus

Parameters

expand all

Main

Select how to display port labels on the Requirements Table block icon.

  • none – Do not display port labels.

  • FromPortIcon – Display the name of the input and output data.

  • FromPortBlockName – Display the name of the input and output data.

  • SignalName – If the signal connected to the port is named, display the signal name. Otherwise, display the name of the data.

Programmatic Use

Parameter: ShowPortLabels
Type: string scalar or character vector
Value: "none" | "FromPortIcon" | "FromPortBlockName" | "SignalName"
Default: "FromPortIcon"

Control user access to the contents of the Requirements Table block.

  • ReadWrite – Enable opening and modifying of Requirements Table block contents.

  • ReadOnly – Enable opening of the Requirements Table block.

  • NoReadOrWrite – Disable opening or modifying of the Requirements Table block.

Note

When you attempt to view the contents of a Requirements Table block whose Read/Write permissions parameter is NoReadOrWrite, the block does not respond. For example, when you double-click the Requirements Table block, Simulink® does not open the table contents and does not display messages.

Programmatic Use

Parameter: Permissions
Type: string scalar or character vector
Value: "ReadWrite" | "ReadOnly" | "NoReadOrWrite"
Default: "ReadWrite"

Try to eliminate artificial algebraic loops that include the atomic unit during simulation.

  • off – Do not try to eliminate artificial algebraic loops that include the atomic unit.

  • on – Try to eliminate artificial algebraic loops that include the atomic unit.

Programmatic Use

Parameter: MinAlgLoopOccurrences
Type: string scalar or character vector
Value: "off" | "on"
Default: "off"

Specify whether entries in this block must run at the same rate or can run at different rates.

  • If entries in the Requirements Table block can run at different rates, specify the sample time as inherited (-1).

  • If entries must run at the same rate, specify the sample time, Ts, corresponding to this rate.

Programmatic Use

Parameter: SystemSampleTime
Type: string scalar or character vector
Value: "-1" | "[Ts 0]"
Default: "-1"

Code Generation

To enable these parameters, you must have Simulink Coder™ or Embedded Coder®.

Select the code format the block uses to generate code for an atomic (nonvirtual) unit.

  • Auto – Simulink Coder and Embedded Coder choose the optimal code format based on the type and number of instances of the Requirements Table block in the model.

  • Inline – Simulink Coder and Embedded Coder inline the Requirements Table block unconditionally.

  • Nonreusable function – Simulink Coder explicitly generates a separate function in a separate file.

  • Reusable function – Simulink Coder and Embedded Coder generate a function with arguments that allows reuse of block code when a model includes multiple instances of the block.

    This option also generates a function with arguments that allows the Requirements Table block to be reused in the generated code of a model reference hierarchy that includes multiple instances of a Requirements Table block across referenced models. In this case, the block must be in a library.

Tips

  • When you want to represent multiple instances of a Requirements Table block as one reusable function, you can designate each of the instances as Auto or as Reusable function. It is best to use one or the other, as using both creates two reusable functions, one for each designation. The outcomes of these choices differ only when reuse is not possible. Selecting Auto does not allow control of the function or file name for the Requirements Table block code.

  • The Reusable function and Auto options both try to determine if multiple instances of a Requirements Table block exist and if the code can be reused. The options differ only when reuse is not possible:

    • Auto yields inlined code, or if circumstances prohibit inlining, the setting separates functions for each Requirements Table block instance.

    • Reusable function yields a separate function with arguments for each Requirements Table block instance in the model.

  • If you select Reusable function while your generated code is under source control, set File name options to Use subsystem name, Use function name, or User specified. Otherwise, the names of your code files change when you modify your model, which prevents source control on your files.

Programmatic Use

Parameter: RTWSystemCode
Type: string scalar or character vector
Value: "Auto" | "Inline" | "Nonreusable function" | "Reusable function"
Default: "Auto"

Select how Simulink Coder names the function it generates for the block.

If you have Embedded Coder, you can control function names with options on the Configuration Parameter Code Generation > Identifiers pane.

  • Auto – Assign a unique function name using the default naming convention, model_block(), where model is the name of the model and block is the name of the block (or that of an identical one when code is being reused).

  • Use subsystem name – Use the Requirements Table block name as the function name. By default, the function name uses the naming convention model_block.

    Note

    When a Requirements Table block is in a library block and the Function packaging parameter is set to Reusable function, if you set the Use subsystem name option, the code generator uses the name of the library block for the function name and file name.

  • User specified – Enable the Function name field. Enter a legal C or C++ function name, which must be unique.

For more information, see Generate Subsystem Code as Separate Function and Files (Simulink Coder).

Dependencies

To enable this parameter, set Function packaging to Nonreusable function or Reusable function.

Programmatic Use

Parameter: RTWFcnNameOpts
Type: string scalar or character vector
Value: "Auto" | "Use subsystem name" | "User specified"
Default: "Auto"

Name of the function for the block code.

Use this parameter if you want to give the function a specific name instead of using an autogenerated name or the block name. For more information, see Generate Subsystem Code as Separate Function and Files (Simulink Coder).

Dependencies

To enable this parameter, set the Function name options parameter to User specified.

Programmatic Use

Parameter: RTWFcnName
Type: string scalar or character vector
Value: "" | "<function name>"
Default: ""

How Simulink Coder names the separate file for the function it generates for the block.

  • Auto – Depending on the configuration of the block and how many instances are in the model, Auto yields different results:

    • If the code generator does not generate a separate file for the block, the block code is generated within the code module generated from the block parent system. If the block parent is the model itself, the block code is generated within model.c or model.cpp.

    • If you select Reusable function for the Function packaging parameter and your generated code is under source control, consider specifying a File name options value other than Auto. This prevents the generated file name from changing due to unrelated model modifications, which is problematic for using source control to manage configurations.

    • If you select Reusable function for the Function packaging parameter and there are multiple instances of the block in a model reference hierarchy, in order to generate reusable code for the block, File name options must be set to Auto.

  • Use subsystem name – The code generator generates a separate file, using the block name as the file name.

    Note

    When File name options is set to Use subsystem name, the block file changes if the model contains Model blocks, or if a model reference target is being generated for the model. In these situations, the file name for the Requirements Table block consists of the block name prefixed by the model name.

  • Use function name – The code generator uses the function name specified by Function name options as the file name.

  • User specified – This option enables the File name (no extension) text entry field. The code generator uses the name you enter as the file name. Enter a file name, but do not include the .c or .cpp (or another) extension. This file name need not be unique.

    Note

    While a Requirements Table block source file name need not be unique, you must avoid giving nonunique names that result in cyclic dependencies (for example, sys_a.h includes sys_b.h, sys_b.h includes sys_c.h, and sys_c.h includes sys_a.h).

Dependencies

To enable this parameter, set Function packaging to Nonreusable function or Reusable function.

Programmatic Use

Parameter: RTWFileNameOpts
Type: string scalar or character vector
Value: "Auto" | "Use subsystem name" | "Use function name" | "User specified"
Default: "Auto"

Name of the generated file. The file name that you specify does not have to be unique. However, avoid giving non-unique names that result in cyclic dependencies (for example, sys_a.h includes sys_b.h, sys_b.h includes sys_c.h, and sys_c.h includes sys_a.h).

For more information, see Generate Subsystem Code as Separate Function and Files (Simulink Coder).

Dependencies

To enable this parameter, set File name options to User specified.

Programmatic Use

Parameter: RTWFileName
Type: string scalar or character vector
Value: "" | "<file name>"
Default: ""

Model Examples

Analyze Formal Requirements of an Electric Vehicle Charger Locking Mechanism

Analyze Formal Requirements of an Electric Vehicle Charger Locking Mechanism

Use a Requirements Table block and Simulink Design Verifier™ to construct, analyze, and update formal requirements of an electric vehicle charging station locking mechanism.

Open Live Script
Define Formal Requirements with a Duration

Define Formal Requirements with a Duration

Define formal requirements that use a duration.

Open Live Script
Use Specification Models for Requirements-Based Testing

Use Specification Models for Requirements-Based Testing

Follow a systematic approach to verify your design model against requirements.

Open Live Script

Extended Capabilities

Version History

Introduced in R2022a

See Also

Topics