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

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.

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

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:

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.

Published 2014 - 92158v00