When systematically verifying a design model against requirements, the development process involves generating test cases for each requirement. These tests validate the design model which is used for the production code generation and helps to gain the confidence that the design model satisfies requirements. Specification model is an executable entity that allows you to perform requirements-based testing by leveraging Simulink® Design Verifier™ capabilities.
If you have a set of requirements that are written in natural language text, you can convert them into formal (executable) specifications using Simulink. These then become a specification model. Unlike the design model, a specification model only specifies What is to be done and not How it is to be done. It captures the requirements at a higher level and hides the details at lower level.
The advantages of using a specification model are:
It validates the set of requirements in a systematic manner.
It automates requirements-based testing.
It helps to identify the missing requirements, design errors, or inconsistencies in your requirements and design model early in the development phase.
For requirements-based testing, test cases generated from the specification model are used to verify the design model against requirements. Follow these steps for the requirements-based testing using a specification model:
Author requirements in the Requirement Editor. Write your requirements in a natural language text that describes the behavior of the system under design.
Construct a specification model. Design the specification model as an executable representation of the requirements. This activity may reveal issues that lead to the refinement of the requirements.
Link requirements. Link the individual requirements or subrequirements to the parts of the specification model.
Generate tests for the specification model. Generate at least one test per requirement that demonstrates its conformance to that requirement.
Create a test conversion subsystem. The specification and design models may not use the same input-output interface. Convert the test cases that were generated in step 4 by using a test conversion system.
Develop the design model. Develop the design model independently by using the requirements document. Link the requirements to the design model.
Verify the design and analyze the coverage. Run the tests generated in step 5 on the design model that was developed in step 6 and verify whether the results agree with the specification model and requirements. Generate a design model coverage report to identify the missing coverage and refine the requirements, if required.
Specification Model Workflow
Consider the autopilot controller model described in Use a Specification Model for Requirements-Based Testing. For this demonstration, requirements consist of logical and temporal open-loop conditions.
Follow these steps to create a specification model for the requirements:
List the input and output signals for the specification model that are related to the requirements. You may ignore the signals that are not related to the requirements at hand.
These are the input signals for the autopilot controller that are based on the requirements:
Autopilot Engage Switch: Enable/Disable the autopilot controller
Heading Engage Switch: When engaged,
ROLL_HOLD_MODE is active
Roll Reference Target Turn Knob: A dial that feeds desired roll angle value to the autopilot controller
Heading Reference Turn Knob: Gives the set-point value for heading mode
Aircraft Roll Angle: The current instantaneous roll angle of aircraft
These are the output signals:
Aileron Command: The output to the aileron actuator
Roll Ref Command: The output on the display window indicating the set-point value for the aileron actuator
Some signals are represented at the higher-level in specifications. It is recommended to represent signals using high-level representation like ranges in the specification model.
Consider the input signal Aircraft Roll Angle, which represents the current roll angle of an aircraft and takes any value in the interval -180 to +180 degrees.
The requirements describe the behavior of the autopilot controller in terms of
zones. These zones are modelled using the enumeration
These five zones are shown in the following figure.
The requirements specify the high-level AP Controller modes and their active conditions as follows:
|Autopilot Mode||Autopilot Engage Switch||Heading Engage Switch|
Consider the following requirement:
"Whenever cockpit turn knob Roll Reference Target Turn
Roll_Ref_TK) is commanding in normal
range (between [-30, -3] or [+3, +30] degrees), Roll
Roll_Ref_Cmd) shall be set to
Identify the precondition and effects. The above requirement consists of two clauses:
Roll_Ref_TK is either in the negative normal range,
[-30, -3], or in the positive normal range, [+3, +30].
This precondition is a simple logical-OR expression, so truth tables are used to express the logical pre-conditions.
Roll_Ref_TK.The effect clause specifies the
output signal values in expected range.
The precondition clause of a requirement determines when it becomes active, while the effect clause determines what a requirement will do after it becomes active.
The above requirement has no effect on the Aileron
Ail_Cmd output, so it is
Range.All which denotes the set of all
Create Truth Table for Requirements
Encode the precondition clause of the requirement into the Condition Table section of the truth table and the effect clause into the Action Table section.
To track each requirement individually, set the local variable REQ_ID to the corresponding requirement ID 2.1.
Add a Simulink Design Verifier objective in Action Table by using
Design Verifier finds a test when REQ_ID 2.1 is satisfied.
The final specification model obtained by using above workflow looks like this: