Using Modeling and Simulation to Test Designs and Requirements .

Using Modeling and Simulation to Test Designs and Requirements .
See more articles and subscribe at mathworks.com/newsletters.
Using Modeling and Simulation to Test Designs and
Requirements
By Michael Carone, MathWorks
Modeling is an efficient 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 difficult 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 difficult 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 fix.
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 workflow 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 workflow 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, flight 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 first step is to model the fault management logic of the actuator system. The requirements document specifies five possible modes for
the actuator: passive, standby, active, isolated, and off. For simplicity, we will consider the first four modes only. We represent these
modes by adding four states to a Stateflow® 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 satisfied for the system to
1
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 specific 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
Figure 5. Test harness used to test the control logic.
With Simulink and Stateflow we can start the simulation without having to manually define variables. When we press the Play button, a
dialog box appears showing which variables need to be defined before the simulation can run. When we press OK, 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 flaw 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 flaw in our design.
3
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 fix 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
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 workflow. For example, we can:
▪ Speed up simulation performance (57:19) using the Performance Advisor in Simulink
▪ Implement a formal testing and verification 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 find and fix
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 2014
92158v00
mathworks.com
© 2014 The MathWorks, Inc. MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See mathworks.com/trademarks for a
list of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respective holders.
5
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement