Flight Research Experiments Driver (FRED)

Very few engineers have the knowledge or the desire to generate a simulation of an aircraft's motion, but many need the results of such a simulation to drive their code. For example, someone working on a model of a navigation system needs a tracjectory generator to provide truth data as an input to the emulated sensors. The results of any test of this hypothetical engineer's code depends directly on the fidelity of the truth data. A trajectory generator that does not accurately model the kinematic equations of motion to at least the second derivative of both the linear and rotational components of vehicle motion provides insufficient fidelity to any but the most basic applications.

American Computational's Flight Research Experiments Drivers (FRED) provides all of the fidelity that any trajectory consumer could need.

History of FRED

FRED began its existence as a driver for a TF/TA algorithm.

American Computational was participating in the integration of this system into a real-time facility at the Air Force's Wright Laboratory. This facility included a model's host that produced navigation data and included an OFP that was to use the TF/TA algortihm's output to steer the aircraft. We had no way of unit-testing the algorithm beyond the overly-simplistic means of running single passes of the algorithm to determine if it produced reasonable results. Any guidance algorithm runs as part of a closed loop system, with the output from one pass affecting the inputs to the next. No single-pass unit test could allow us to determine if the algorithm would drive the system in an unstable way.

We decided to emulate the overall system and use this emulation to drive the TF/TA algorithm. We included all of the system elements that affected the algorithm or that the algorithm affected, feeding its output through OFP-like steering code and sending the OFP's results to the flight control system. With this tool, we quickly isolated and fixed many problems that would have been far more complex to analyze in a full-up, real-time system.

Since then, we have applied FRED to many problems, always adding to its (his?) capability, until today it exists as a complex tool that is quite simple to use. It can be run real-time or flat-out, which with a 400 MHz system means something on the order of 30 times faster than real-time. It can generate reams of output data or none at all. It has no knowledge of its test article, yet can drive any test article with ease. We confidently assert that it is one of the most useful and versatile tools on the market for analyzing software that requires trajectory information.

By the way, in case you're curious about where it got its name, look at your keyboard. The letters F-R-E-D form a circle on the left side, making it easy to enter. Only when it became a formal tool did we generate a name from which we could extract an acronym.

Isn't that typical of the way these things always get named?

FRED Today

FRED has been designed to include any trajectory parameter that any user might need to drive a test article, including: With the exception of jerk which it calculates as the time-derivative of linear acceleration, FRED does not use any limiting assumptions or take any shortcuts in computing any of these values. It simulates the actual kinematic equations of motion to generate its output, and therefore accurately models the transitions between all states. Any user that applies FRED as driver for a test article ensures that the test article gets an extrordinarily-high-fidelity set of inputs.

Depending on the host platform, FRED may run in real-time, slower than real-time, or even faster than real-time. However, any test article seems to run in real-time because of FRED's control over the value of time. It does not rely on the system clock but maintains an internal clock that controls what time test articles believe it to be. Therefore, even tho it may run much slower than real time on a platform with insufficient computing resources (such as an older generation PC), the results that it produces (and hence that test articles produce) have the same validity that they would in a real-time system.

FRED's trajectory results get placed into an emulated shared memory which any test article can access by including the proper interface packages into its address space. For a test article that will be able to access truth data, this method suffices. However, most test articles will receive trajectory data from a navigation system such as an Inertial Navigation Unit (INU) or a Global Positioning System (GPS). To support such needs, we have combined FRED with GHOST to increase the use of FRED as a driver.

In addition to placing trajectory data into simulated shared memory, FRED can use GHOST's messaging capability to produce emulations of the results of an INU or a GPS. It formats the truth data from the equations of motion into a variety of data messages in standard formats (SNU-84). A test article can connect to any (or all) of these messages and be driven as they would be in their intended environment.

FRED provides pre-defined interfaces for initialization, execution, and termination of test articles in an interface specification. The user supplies the body to this interface, with the body invoking the test article. It also provides a variety of guidance modes to allow the user to generate the desired tracjectory including:

Using FRED, an engineer gets all of the fidelity required for even the most delicate applications, without having to invest the time (and money) in generating a trajectory generator. FRED exists in both C++ and Ada versions.

FRED is a fine product from the Software Specialists of
American Computational Technical Services, Inc.

For information or questions on support for additional features please contact Mike Miedlar

Back to Main Page