using-modeling-and-simulation-to-test-designs-and-reqs.pdf

8/12/2019 using-modeling-and-simulation-to-test-designs-and-reqs.pdf

1/5

Using Modeling and Simulation to Test Designs andRequirementsBy Michael Carone, MathWorks

Modeling is an efcient and cost-effective way to represent a real-world system. A model can represent key aspects of the system,

including the underlying requirements, the components, and how those components communicate with one another. The model can be

simulated, enabling designers to test designs before hardware is available, or to test conditions that are either difcult or expensive to

replicate in the real world. Iterating between modeling and simulation can improve the quality of the system design early, reducing the

number of errors found later in the design process.

Despite these advantages, designers who heavily rely on hand coding do not always take full advantage of modeling and simulation.

Setting up tests can be difcult and time-consuming, and when separate tools are used for each domain, it can be challenging to obtain a

system-level view of the design. As a result, defects that could have been found in the modeling and simulation phase are often found

during the implementation phase, when defects are more expensive to x.

These issues are addressed in Simulink, a platform for modeling and simulation. Simulink supports not only multidomain modeling but

also simulation, with its own set of ordinary differential equation (ODE) solvers. A fundamental advantage of using Simulink is that you

can represent different domains, including control systems, state machines, and environmental models, in one model, and then run

simulations within Simulink to verify that the model is built correctly. As the simulation runs, you have access to simulation analysis

capabilities, such as data displays, state animation, and conditional breakpoints. After the simulation is completed, you can analyze any

logged data with MATLAB scripts and visualization tools.

In this article, we describe a workow for building a component model from requirements, simulating and testing that component

model, and then connecting it to a system-level model for further simulation and testing. To illustrate this workow we will build and

test the fault detection, isolation, and recovery (FDIR) component of the HL-20, a re-entry vehicle designed by NASA to complement the

Space Shuttle orbiter. We will connect our component to a system-level model that includes environmental models, ight controls, and

guidance, navigation, and controls (GN&C) systems, and then simulate the system-level model to validate its behavior.

The model used in this example is available in Aerospace Blockset.

Building the Component Model from Requirements

The rst step is to model the fault management logic of the actuator system. The requirements document species ve possible modes for

the actuator: passive, standby, active, isolated, and off. For simplicity, we will consider the rst four modes only. We represent these

modes by adding four states to a Stateow state diagram (Figure 1).

Figure 1. Stateflow diagram showing actuator modes represented by states.

Next, we need to determine how the system will transition from one state (or mode) to another. Using the information provided in the

requirements document, we add transitions connecting the states, and specify which conditions need to be satised for the system to

See more articles and subscribe at mathworks.com/newsletters

1
http://www.mathworks.com/products/aeroblks/http://www.mathworks.com/newslettershttp://www.mathworks.com/newslettershttp://www.mathworks.com/products/aeroblks/


2/5

switch states. We also group the Passive, Active, and Standby states together in a superstate, since they all transition to the Isolated state

under the same condition. This hierarchical modeling technique helps us to model complex logic in a simple visual form (Figure 2).

Figure 2. State diagram modeled using requirements document as the source.

We continue to build the model, connecting each element to a specic system requirement (Figure 3). Later we will be able to trace our

model back to the requirements document to explain why a design choice was made.

Figure 3. Requirements linked to specific parts of the state diagram.

Once we have built up the logic for the left inner actuator, we can reuse this design for the right inner actuator, since the structure is

exactly the same. The only elements that need to be changed are the conditions that guard each transition, as described in the

requirements document (Figure 4).

Figure 4. Control logic for the right inner actuator.

Testing the Component Through Simulation

Now that the component is partially built, we are ready to run simulations to verify that it is behaving correctly. To do this, we set up a

simple test harness that feeds input signals into the component using a combination of switch and constant blocks (Figure 5).

2


3/5

Figure 5. Test harness used to test the control logic.

With Simulink and Stateow we can start the simulation without having to manually dene variables. When we press thePlaybutton, a

dialog box appears showing which variables need to be dened before the simulation can run. When we pressOK, those variables are

automatically created (Figure 6).

Figure 6. Stateflow Symbol Wizard for automatically defining variables used in the logic.

As the simulation runs, the state diagram animates, letting us know which state is active at any given time and how the system is

transitioning from state to state. Ad-hoc testing by switching input signals on or off reveals a aw in the design (Figure 7). When the left

inner actuator is activated, the right inner actuator should be activated, as well. The fact that we were able to set the input conditions so

that this did not happen indicates that there is a aw in our design.

3


4/5

Figure 7. State animation showing a defect in the design.

It turns out that the condition on the transition from Active to Standby contains a defect. Since we have linked each condition to a

requirement, we can trace that condition to the underlying requirement and verify that the defect originated from the requirements

document and not from the design (Figure 8).

Figure 8. Design defect traced back to requirements document.

The last line should read "or the left inner actuator is in the Active mode."

We x the language in the requirements document, revise the condition, simulate the model again, and verify that the system now

behaves correctly in response to the input signals.

Testing the System with the New Component

Now that the FDIR component has been tested on its own, we are ready to test it in the system-level model. We bring the component

into the model as a Model block named FDIR_application. Once the block is integrated into the system model, we can continue to work

on it independently from the rest of the system using the model referencing capability in Simulink (Figure 9).

Figure 9. System-level model showing three referenced component models: flight control system, FDIR logic, and guidance system.

We simulate the system-level model and visualize the behavior of the component in the state diagram, as well as the behavior of the

overall system, using FlightGear, an open-source visualization tool. To test the system, we set up a harness that injects faults into the

actuator system so that we can verify that both the component and overall system respond correctly (Figure 10).

4


5/5

Figure 10. Simulation of the multidomain system-level model.

Next Steps

So far, we have built up a component from requirements, simulated and tested that component, and then connected it to a system-level

model for additional simulation and testing. There are a number of additional steps that we can take to enhance the modeling and

simulation workow. For example, we can:

Speed up simulation performance (57:19) using the Performance Advisor in Simulink

Implement a formal testing and verication process with design proofs, coverage analysis, and test-case generation

Replace blocks with connections to hardware as hardware becomes available

Whichever step you choose next, the key is to model, simulate, and test the system as frequently and as early as possible to nd and x

defects early to reduce overall system development cost.

Products Used

MATLAB

Simulink Aerospace Blockset

Stateflow

Learn More

Webinar: Simulink and Stateflow for Simulation Engineers

(48:04) Modeling and Simulation

See more articles and subscribe at mathworks.com/newsletters.

Published 201492158v0

mathworks.com

2014 The MathWorks, Inc. MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See mathworks.com/trademarks for alist of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respective holders.

5
http://www.mathworks.com/videos/speeding-up-simulink-applications-81795.htmlhttp://www.mathworks.com/verification-validation/http://www.mathworks.com/hardware-support/home.htmlhttp://www.mathworks.com/products/matlab/http://www.mathworks.com/products/simulink/http://www.mathworks.com/products/aeroblks/http://www.mathworks.com/products/stateflow/http://www.mathworks.com/videos/simulink-and-stateflow-for-simulation-engineers-81993.htmlhttp://www.mathworks.com/videos/simulink-and-stateflow-for-simulation-engineers-81993.htmlhttp://www.mathworks.com/discovery/modeling-and-simulation.htmlhttp://www.mathworks.com/newslettershttp://www.mathworks.com/http://www.mathworks.com/trademarkshttp://www.mathworks.com/trademarkshttp://www.mathworks.com/http://www.mathworks.com/newslettershttp://www.mathworks.com/discovery/modeling-and-simulation.htmlhttp://www.mathworks.com/videos/simulink-and-stateflow-for-simulation-engineers-81993.htmlhttp://www.mathworks.com/videos/simulink-and-stateflow-for-simulation-engineers-81993.htmlhttp://www.mathworks.com/products/stateflow/http://www.mathworks.com/products/aeroblks/http://www.mathworks.com/products/simulink/http://www.mathworks.com/products/matlab/http://www.mathworks.com/hardware-support/home.htmlhttp://www.mathworks.com/verification-validation/http://www.mathworks.com/videos/speeding-up-simulink-applications-81795.html

using-modeling-and-simulation-to-test-designs-and-reqs.pdf

Documents

Transcript of using-modeling-and-simulation-to-test-designs-and-reqs.pdf