Flight Simulators

Have you ever wondered how full-flight simulators and CATS (computer-aided training systems, Figure 1) are made? The answer, as one might expect, is that they are made with a lot of high-tech hardware and a million lines of code. It is a true marvel of technology where hardware and software meet to produce some of the most incredibly realistic simulations in the world today. Full-flight simulators are based on three principles: visuals, sound and motion. Using these three basic concepts, we are able to produce the most sophisticated flight simulators in the world. A full-flight simulator is an invaluable training tool for helping a pilot acquire the necessary skills and abilities to react to unpredictable situations.

Full-flight simulators (Figure 2) are built with a complex and effective six-degrees-of-freedom motion system. This motion system is responsible for producing the realistic feeling of takeoff, landing and in-flight turbulence. The visual projectors generate the real-world images as visual references. The heart of the entire system is the host computer, which is responsible for interacting with all the avionics hardware, motion and visual systems as well as simulating the aircraft's aerodynamics. CATS are a different breed of aircraft simulation. Instead of defining a hardware interface to interact with all the aircraft panels, CATS produce a graphical representation of all the aircraft panels (Figure 3), schematics (Figure 4), Line Replaceable Units (LRUs, Figure 5), and black boxes as they are sometimes called (Figure 6). By contrast, CATS provide a quite useful tool for training aircraft maintenance personnel involved, as well as pilots. They are also invaluable as a diagnostic tool for maintenance personnel in troubleshooting and diagnosing aircraft system failures. CATS are available in three configurations: single-screen (mini-CATS, Figure 7), three-screen (CATS, Figure 1), and seven-screen (CATS System Trainer, Figure 8). This last one is a full graphical representation of the aircraft cockpit with touch-sensitive screens. This system provides the entry-level pilot and/or aircraft maintenance personnel an opportunity to master his cockpit procedural skills.

Figure 1. Computer-Aided Training Systems

What kinds of software and computing power are required to produce the realism required for flight simulation? Until not too long ago, this field has been the playground for big players in the industry such as IBM, Digital VAX/VMS and Gould. Today, with powerful CPUs being commonplace and mainframes almost obsolete, Intel has just about dominated the marketplace.

The company I work for (CAE Electronics Inc., Montréal, Quebec, Canada) employs 4000 people, half of whom are software engineers in the simulation hardware and software domain. Speaking objectively, I am proud to say that CAE Electronics builds the most technologically advanced full-flight simulators in the world today. It is up to CAE engineers to come up with new technologies in software simulation, both with respect to the CPU hardware and the OS required to produce quality products for our customers. Linux can be used as a dependable and reliable platform for commercial flight simulation software in the airline industry.

Figure 2. Full-Flight Simulator

CAE has always been a company that believed in building its own software tools and basic software development environment. For the last nine years, CAE has been an IBM AIX RS/6000 house. IBM has been our foundation for building a stable platform under AIX to run thousands of software modules in a real-time environment, a tough task for Linux to undertake. In the last four years, however, Linux has been used as a basic development platform for CAE engineers requiring a complete simulation environment.

Figure 3. Aircraft Panels Representation

Can Linux be used to develop CAE commercial software simulation systems? Yes. Linux has matured a great deal in the last couple of years. With that in mind, CAE engineering has been instrumental in supporting Linux. Will our customers react favorably to Linux? Will the Linux community support the product in the years to come? Both are serious questions. Full-flight simulators are a long-term investment for our customers. These and many other questions must be answered before we can fully commit and support future Linux development. Current industry trends show Linux being supported more and more by companies such as IBM, H-P, Compaq and Dell. The future for Linux looks bright.

Our basic principles in software simulation are simple. We produce C code in straight-line execution within a CAE software environment called SIMEX (simulator executable). This environment provides the basic software dispatcher required in controlling software module execution in a real-time environment. SIMEX also provides software configuration control under RCS to maintain multiple configurations for testing and integration. SIMEX is capable of building different executables for runtime execution from a collection of different source modules. This provides an invaluable environment for the engineers to test new software code without destroying the previous working configuration.

Figure 4. Schematics

Since AIX is a non-real-time OS, the question arises as to how one would create a real-time environment on a non-real-time OS. The answer is simple: produce your own library of asynchronous I/O control functions that the software engineer will require for all I/O system calls. Setting the system priority of the software dispatcher code to the highest level is not enough to create a real-time environment. All simulation I/O requests must be handled in an asynchronous manner in order to maintain a real-time simulation environment. We call this environment CAELIB (CAE Library).

The software dispatcher is also required to control the sequence and duration of software module execution so as not to allow any overruns to occur. This technique is called banding. Software banding enables the software dispatcher to control the time required to execute a collection of software modules as well as the sequence of code executions. Certain modules need to run before others in order to maintain aircraft system simulation integrity. This allows all modules ample opportunity to execute in the allotted time. For real-time simulation, this is 60 Hertz or 16.66 milliseconds for one full pass for all software modules. The software dispatcher then further breaks the banding down into legs, which are executed in a controlled state.

Figure 5. Line Replaceable Units

Not all modules need to be executed at a rate of 60 Hertz. Most aircraft systems need to be executed at only a third or even a quarter of a second. For this reason, the software dispatcher calls certain modules at an iteration rate of 16.66, 33, 66, 133 or 266 milliseconds. The CAE engineer enters his/her module into a dispatch table. This, in turn, instructs the software dispatcher code to execute and sequence as per the engineer's request. If there are too many modules in one particular leg and the code is unable to complete execution within the allotted time, the software dispatcher will terminate the execution of the code and continue onto the next leg for execution.

This situation is called a software overrun. In order to control software overruns, the integration specialist and software engineer redistribute the software modules into less heavily weighted bands that have excess execution time. This allows critical modules ample time to execute, while non-critical modules are executed at a slower iteration rate. Since all our code is based on legacy FORTRAN 77 and ANSI C, porting our code to a Linux PC platform proved to be a relatively straightforward task, except, of course, accounting for the obvious differences between Linux and AIX compilers. (More to follow on that subject.)

Figure 6. Black Boxes