Use Specification Models for Requirements-Based Testing

View the High-Level Requirements

Open the requirements set, AP_Controller_Reqs, in the Requirements Editor.

slreq.open("AP_Controller_Reqs");

The high-level requirements specify the outputs of the model and the autopilot controller mode. Each requirement description uses high-level language that you can use to explicitly define the logic needed in the formal requirements.

View the First Iteration of the Specification Model

Open the specification model, spec_model_partial.

spec_model = "spec_model_partial";
open_system(spec_model); 

The model contains two Requirements Table blocks that define the formal requirements that translate the high-level requirements into testable logical expressions. The block AP_Mode_Determination specifies the formal requirements for the autopilot controller mode, and the block Cmd_Determination specifies the outputs of the controller.

To view the formal requirements, inspect each Requirements Table block.

Requirements Table Block for Controller Mode

Open AP_Mode_Determination. The block specifies the formal requirements for the autopilot controller mode. To determine the output data Mode, AP_Mode_Determination specifies three requirements by using two input data:

Each requirement uses a combination of the inputs to specify a unique output value for Mode.

Requirements Table Block for Controller Commands

Open Cmd_Determination. Cmd_Determination specifies the requirements for the aileron command and roll reference command. Cmd_Determination uses four input data:

The block uses these input data to determine the controller output data:

In this example, the expressions use constant data to define the ranges of values for Roll_Ref_TK and Roll_Angle_Phi. You can also parameterize the values or use literal values. See Define Data in Requirements Table Blocks. To view these values, open the Symbols pane. In the Modeling tab, in the Design Data section, click Symbols Pane.

In addition to requirements, Cmd_Determination also defines the assumptions for the design. See Add Assumptions to Requirements. In this example, the assumptions constrain the values for the roll angle and the roll reference target knob based on their physical limitations. The roll angle cannot exceed 180 or fall below -180 degrees, and the roll reference target knob cannot exceed 30 or fall below -30. In the table, click the Assumptions tab.

You can also specify data range limitations in the Minimum and Maximum properties of the data or explicitly specify the range from the signal with blocks.

Analyze the Requirements Table

Next, analyze the Requirements Table block. As a best practice, analyze the block to confirm that the formal requirements are complete and consistent. This best practice helps you avoid generating tests from specification models before you confirm that the formal requirements are complete, consistent, and correspond to the high-level requirements.

In the Analyze section, click Analyze Table. See Analyze Requirements Table Blocks for Modeling Problems.

The analysis detects an incompleteness issue.

The requirement set in Cmd_Determination is missing the formal requirement that corresponds to the third bullet of requirement 3.

Open Cmd_Determination in the model spec_model_final to view the updated requirement set. The additional requirement has the index 2.2.4.

spec_model = "spec_model_final";
load_system(spec_model);
open_system(spec_model + "/Cmd_Determination");

Link High-Level and Formal Requirements

Loading the specification model loads the formal requirements in the Requirements Editor. Closing the specification model also closes the associated requirement set. When developing your formal requirements, link formal requirements to the corresponding high-level requirement to track the requirements in the specification model. In this example, linking the requirements does not affect test generation or test results.

To link the first formal requirement to the corresponding high-level requirement:

The link type defaults to Related to. For more information on link types, see Link Types.

Generate Tests from the Updated Model

Simulink® Design Verifier™ automatically creates test objectives from the requirements defined in Requirements Table blocks. To generate tests, use the Configuration Parameter window or specify the tests programmatically. See Model Coverage Objectives for Test Generation (Simulink Design Verifier). Select different coverage objectives to determine if you want to minimize the number of tests generated, or if you want to improve test granularity and traceability.

In this example, generate tests with decision coverage and save the output to a MAT-file.

opts = sldvoptions; 
opts.Mode = "TestGeneration"; 
opts.ModelCoverageObjectives = "Decision"; 
[~,files] = sldvrun(spec_model,opts,true);

Simulink Design Verifier generates the test objectives and the tests from the requirements. In this version of the specification model, the test objectives are satisfied.

Run the Tests on the Design Model

After you create tests that satisfy the test objectives, you can run the tests on the design model. In this example, the design model is the model for the aircraft autopilot controller, sldvexRollApController.

Before you run tests on the design model, you must interface the specification model with the design model. Typically, the specification model does not produce or use the same signals as the design model. These differences can be simple or abstract. For example, the design model might use different input and output signal types than the specification model, or you may want to compare a scalar output from the design model against a range in the specification model. As a result, you need to construct an interface between the design model and the specification model.

Interface the Design Model with the Specification Model

In this example, the specification model spec_model_final and design model sldvexRollApController inputs can interface directly, but one of the outputs is different. spec_model_final represents the aileron command as a range of values, but the aileron command value produced by sldvexRollApController is a scalar double. The interface uses a MATLAB Function block to compare the aileron command values. The interface then verifies both outputs with Assertion blocks. Open the model, spec_model_test_interface, to view the interface.

test_interface = "spec_model_test_interface";
open_system(test_interface);

The MATLAB Function block compares the two signals by using this code:

function y = fcn(design_val, spec_val)
switch spec_val 
    case Ail_Cmd.All
        y = true;
    case Ail_Cmd.Zero
        y = (design_val == 0);
    otherwise
        y = false;
end    

Run the Updated Tests on the Design Model

To test and verify the design model, create a harness model that contains the:

In the harness model, attach the models together. Then run the tests on the design model and verify the outputs correspond to the requirements in the harness model.

To view the harness model, open the model, sldvexDesignHarnessFinal.

harness_model = "sldvexDesignHarnessFinal";
open_system(harness_model);

Like with the interface model, not all design model inputs may directly correspond to specification model inputs. In this example, the harness model prepares the design model for testing with the five inputs specified by the specification model.

Run the updated tests on the design model from within the harness model. Use the sldvruntest (Simulink Design Verifier) function to run the tests and save the results. If you have Simulink Coverage™, you can view the results of the tests from the output of sldvruntest in a coverage report. View the coverage report by using the cvhtml (Simulink Coverage) function.

cvopts = sldvruntestopts;
cvopts.coverageEnabled = true;
[finalData, finalCov] = sldvruntest(...
    harness_model,files.DataFile,cvopts);
cvhtml("finalCov",finalCov);

In the coverage report, click the sldvexRollApController link. The summary shows that full coverage is achieved in the design model, sldvexRollApController.

bdclose("all");
slreq.clear;