For the PDF version of this article, click here.

Developing test vectors is generally a manual process driven by paper specifications and requirements. Verifying that the test vectors are correct and sufficient to test the device or system currently doesn’t happen until a prototype or the actual system is available. This is time better spent verifying and validating the system, not the tests.

Using model-based design reduces the development time and cost of defense electronics systems. One significant advantage of model-based design is that it allows test vector development and verification before hardware is available. Tests can be designed and verified faster on the computational model because there is no need to build prototypes and run physical tests. In addition, running tests in simulation can be much faster than running physical tests.

Scenarios that are difficult to reproduce in the physical world can be examined easily in simulation. For example, sensor and actuator failures can be introduced to verify the test vector design. By designing and verifying the tests on a computational model, the cost and time required for the design verification stage using actual hardware can be substantially reduced. This article presents a case study on developing and verifying test vectors for a Stewart platform used in a flight simulator.

Stewart platform

A Stewart platform consists of six legs attached to a common platform as shown in Figure 1. In Figure 2, the Stewart platform plant and the xPC TargetBox^[1] controller are shown as blocks in the center. The xPC TargetBox hardware is centered on a 400 MHz Intel Pentium III (floating-point) processor, with 128 MB RAM, and 32 MB flash RAM.

The control algorithm that is implemented on the xPC TargetBox computes the control signal for each of the actuators. The signal is first input to a Nanomotion amplifier that is connected to one of the six channels of the RTD DM6604 analog output of the xPC TargetBox to achieve a high-power equivalent that can drive the Nanomotion H1 piezoceramic motors on each of the legs. The motor input consists of a sinusoidal voltage, from a high-power driver, the amplitude of which is used to control the leg movement.

The sensor input to the xPC TargetBox comes from six MicroE Mercury 3110 incremental encoders, one on each leg. Each time the leg slides a given distance, a pulse is produced by a grated slide passing by an optical beam. The generated pulses are counted by an RTD DM6814 incremental encoder board and translated into a corresponding digital value, from which the actual distance is computed. The precision is determined by the total of 65,536 counts over about 4 cm of travel. This results in a precision of about 0.61 µm of travel per count.

Modeling the Stewart platform

• Physics modeling.

For modeling the Stewart platform, a SimMechanics^[2] model of the machine structure was exported from a CAD drawing in SolidWorks^[3]. The resulting SimMechanics model has a base plate as body at the bottom that is rigidly connected (by a weld joint) to ground. The six legs connect the base plate to the top plate. The legs are modeled by bodies that connect a prismatic joint to the spherical joints at the base and top plate. The prismatic joints can be actuated and are modeled to include stiction and viscous friction effects. The SimMechanics model for one of the six identical legs is shown in Figure 3.

• Estimating plant model parameters.

Once the structure of the model is designed based on modeling from first principles, the parameter values of the model have to be determined. This is typically done by measurements. Those measurements can be static (e.g., lengths, widths, gear ratios and diameters) or dynamic (e.g., inertias).

Once the data is obtained, parameter estimation tools such as Simulink Parameter Estimation^[4] can be applied to systematically find the values for the free parameters and initial states that result in behavior that best matches the measured data. To ensure correct and quick convergence to the optimal values, the minimum and maximum values of the parameters and initial states can be set, as well as their expected values.

Figure 4 shows the measured extension of one of the legs of the Stewart platform for a sequence of control commands as a dotted line, while the extension as computed from the model is shown by a solid line. In these results, the model parameters are chosen based on an educated guess.

Figure 5 shows the leg extension computed from the model in response to the same sequence of control commands after the model parameters have been estimated by Simulink parameter estimation to minimize the difference between the measured leg extension (shown by the dotted line) and the model leg extension (shown by the solid line).

Test vector generation and model coverage

Once a model is obtained that is an accurate representation of the system, it serves as a gold standard that can be used to design test vectors.

The input signals can now be varied across their signal ranges and the subsequent output ranges measured. These measurements provide a basis for the limits of the tests under normal operation. In addition to getting the output range for a given input, the use of a model allows access to coverage information of variables internal to a model that are not normally measurable. Simulink verification and validation^[5] shows coverage of the model for a given input vector and provides decision coverage reports, condition coverage reports, look-up table coverage reports, modified condition/decision coverage reports, signal range coverage reports, and cyclomatic complexity reports.

These coverage metrics give the test designer the necessary information to prove that their test set fully exercises the device under test (DUT). They can easily see if all possible paths in the model are covered and which test vector covers which section of the model. Traditionally, this information relied on the test strategy report to cover the full system but now the test programmer can see proof of the coverage for their given test vectors.

Testing the Stewart platform

For the Stewart platform discussed in Section 2, the test vectors in Figure 6 can be used to troubleshoot anomalous behavior. In Figure 6 (a), a ramp signal is shown that can be used to determine when the forward stiction of a motor is broken. In Figure 6 (b) a step is shown that has a large amplitude to simply make the corresponding leg extend itself. In Figure 6 (c), a pulse signal that can be used to test positive and negative leg extensions is shown. In Figure 6 (d), a triangular signal is shown that allows determining when the negative stiction is broken. If chosen at a sufficiently low amplitude, as determined from the model, it can also be used to determine when the forward stiction is broken. A frequency sweep that can be used to test overall parameter values is shown in Figure 6 (e).

A subset of coverage results for the tests in Figure 6 are shown in Table 1. The coverage results can be used to guide the testing process. For the Stewart platform, five components can be identified for each of the six legs: the motor, the amplifier, the bearing, the sensor and the counter. For the motor, three separate aspects are of importance: a change in viscous friction, a change in forward stiction and a change in backward stiction.

To troubleshoot a problem down to the component level, the first step is to run tests to determine whether the amplifiers for each of the legs work properly. The coverage results in Table 1 indicate that the best test for this capability is the step input with a large amplitude. The step input has a large range of accelerations and, therefore, large forces to overcome potential failures in the motor and legs. In response, the position of the platform is measured and in case there is no motion, the amplifier is a likely candidate for failure. Note that acceleration ranges are difficult to measure on hardware.

If the platform does move, the amplifier is likely to be functioning correctly, and so the motor could be dysfunctional or there could be a fault in the bearing. To test whether the motor is functioning correctly, first, the stiction coefficients can be validated. The coverage results in Table 1 show that because of the low acceleration range, the ramp and triangle tests are prime candidates because they will provide more accurate information about when the stiction is broken than tests with larger acceleration ranges.

To test both the forward and backward stiction, the triangle waveform is selected, because it gives coverage of both those situations, as can be seen by the coverage column in Table 1. The ramp test only tests the leg being stuck and the forward friction being broken, i.e., only 67% coverage is achieved.

If the stiction coefficients do not deviate, the next candidate for testing is the viscous friction of the motor and the bearing. These two are closely strongly coupled, and, therefore, if the test shows anomalous behavior, both the motor and bearing are implicated, and the mechanism has to be dismantled to perform further testing. This test is best performed by the frequency sweep, because of the large velocity range that it produces, as can be seen in the coverage results in Table 1.

This example demonstrates how model-based design can substantially reduce the time and costs required to design and verify test vectors for acceptance testing of defense electronics systems. The case study demonstrates the use of verification tools to compare tests run on the computational model and on hardware prototypes. It also shows how verification tools can be used to evaluate test coverage. Once tests have been designed and verified using computational models, the test design verification stage using physical hardware can proceed much more quickly.

REFERENCES
1. xPC TargetBox User’s Guide: The MathWorks, Natick, MA, 2004.
2. SimMechanics User’s Guide: The MathWorks, Natick, MA, 2004.
3. Introducing SolidWorks: SolidWorks Corporation, Concord, MA, 2002.
4. Simulink Parameter Estimation User’s Guide: The MathWorks, Natick, MA, 2004.
5. Simulink Verification and Validation User’s Guide: The
MathWorks, Natick, MA, 2004.

ABOUT THE AUTHORS

Tom Gaudette, test & measurement development manager, has been with The MathWorks since 2001 working in development with the test & measurement group. He participates in several standards for The MathWorks including the IVI Foundation, LXI, synthetic instrument working group and ATML working group. Gaudette holds a B.S. (1996) in Electrical Engineering, and a M.S. degree (1998) in Electrical Engineering specializing in waves, optics and plasma, both from Northeastern University.

Brett Murphy is manager, technical marketing, The MathWorks. He is responsible for the technical marketing of verification, validation and test products. Murphy has extensive controls analysis, real-time software development, and systems engineering experience in the aerospace industry. In 1995, Murphy joined Real-Time Innovations and guided the development and marketing of RTI’s embedded software test tools and network middleware. He holds a BS and MS in Aerospace Engineering from Stanford University.

RSS    Save to Del.icio.us  Digg This