What is a Specification Model?

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.

Using Specification Models for Requirements-based Testing

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:

  1. Author requirements in the Requirement Editor. Write your requirements in a natural language text that describes the behavior of the system under design.

  2. 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.

  3. Link requirements. Link the individual requirements or subrequirements to the parts of the specification model.

  4. Generate tests for the specification model. Generate at least one test per requirement that demonstrates its conformance to that requirement.

  5. 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.

  6. Develop the design model. Develop the design model independently by using the requirements document. Link the requirements to the design model.

  7. 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

Creating a Specification Model

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:

Identify the Specification Model Interface

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:

  1. Autopilot Engage Switch: Enable/Disable the autopilot controller

  2. Heading Engage Switch: When engaged, enables the HDG_HOLD_MODE. Otherwise, ROLL_HOLD_MODE is active

  3. Roll Reference Target Turn Knob: A dial that feeds desired roll angle value to the autopilot controller

  4. Heading Reference Turn Knob: Gives the set-point value for heading mode

  5. Aircraft Roll Angle: The current instantaneous roll angle of aircraft

These are the output signals:

  1. Aileron Command: The output to the aileron actuator

  2. Roll Ref Command: The output on the display window indicating the set-point value for the aileron actuator

Use High-Level Representation for Signal Values

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 Range.

These five zones are shown in the following figure.

Identify High-Level Operating Modes

The requirements specify the high-level AP Controller modes and their active conditions as follows:

Autopilot ModeAutopilot Engage SwitchHeading Engage Switch
OFFOFFDon't care
ROLL_HOLD_MODEONOFF
HDG_HOLD_MODEONON

Identify Preconditions, Effects, and Expected Output for Each Requirement

Consider the following requirement:

"Whenever cockpit turn knob Roll Reference Target Turn Knob (Roll_Ref_TK) is commanding in normal range (between [-30, -3] or [+3, +30] degrees), Roll Reference (Roll_Ref_Cmd) shall be set to Roll_Ref_TK."

Identify the precondition and effects.  The above requirement consists of two clauses:

  1. Precondition: 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.

  2. Effect: Set Roll_Ref_Cmd to 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 Command Ail_Cmd output, so it is considered as Range.All which denotes the set of all possible values.

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 the statement sldv.test (REQ_ID==2.1). Simulink Design Verifier finds a test when REQ_ID 2.1 is satisfied.

Final Specification Model

The final specification model obtained by using above workflow looks like this:

See Also

Simulink Design Verifier Documentation

Support