Flight Simulators

The software simulation configuration discussed in this
article was a Bombardier/Canadair Regional Jet RJ-200 aircraft
(Figure 9), a successful 50-seat twin jet regional aircraft
manufactured and built by Bombardier Aerospace in Montréal and
popular with airlines such as Comair, Skywest and Air Canada, just
to name a few. The first task at hand for CAE engineers was to port
the entire CAELIB and SIMEX software environment to Linux. This
proved to be a relatively uncomplicated task for our operating
system support group (OSU), since most of our code is in ANSI C.
All modules were compiled with relatively minor modifications. Once
this was done, the task of transferring and porting the entire
software simulation code from SIMEX to Linux proved to be more
challenging. Now, I am referring to years of software development
on AIX with at least 500 software modules, each ranging from 1,000
to over 100,000 lines of code—the porting of which would be no
trivial matter. The third task was to port the required
CAE-specific compilers from our own OpenGL-based graphics compiler
and editor to our basic support utilities. CAE has developed its
own graphical environment called TIGERS (an OpenGL-based
system).

At the time TIGERS was developed at CAE, sophisticated
graphic systems for simulation use were not yet commonplace.
Figures 10, 11, 12, 13 and 14 show the level of graphical detail
required for CATS simulation. The main difference between a CATS
and a full-flight simulator is simple: CATS requires that all
aircraft panels be a graphical representation, as opposed to the
hardware-driven interface on a full-flight simulator. Simply put, a
graphical representation of a switch is used instead of a real
switch in a cockpit environment. In all respects, the amount of
simulation software required is much more complex on a CATS as
opposed to a real full-flight simulator. All aircraft systems are
simulated in the CATS environment, instead of only the simulated
black boxes of the full-flight simulator. In flight simulators, we
simulate the same black boxes as used on the aircraft. In trying to
address the needs of a Bombardier's training department as they
sought a portable version of their existing AIX CATS on the PC
platform, CAE engineering decided Linux would be the ideal and
practical choice for this project.

We made the decision to use the standard GNU ANSI C compiler
and F77 translator for the task. Our FORTRAN77 legacy software
modules proved to be the greatest challenge. AIX FORTRAN77
compilers are very forgiving in equating logical to integer data
types. For example, if you equate an integer label to a logical
label, the AIX FORTRAN compiler would assume you require the value
in the logical label to be stored into the integer label. This
style of programming is not allowed under F77 Linux. You must
declare and equate labels of the same data type, or the compilation
will fail. Now, this would be a simple task if the labels were
defined in the local module. The problem arises when the software
module in question uses a logical label declared in what we call
our CDB (common data block) as an integer label. This common data
block is used to declare all global labels used by every simulation
module to pass variables among each other. If the declaration is
wrong in the CDB, a correction must be made in all modules. Then
each module must be reprocessed with the new CDB and
recompiled.

The next problem lies with the memory storage format of
logical labels between AIX and Linux. For example, a data type of
Logical*4 (four bytes) in F77 Linux is stored from left to right
(MSB, most significant bit, to LSB, least significant bit) while
AIX stores the logical in reverse order (LSB to MSB). This can
create a major problem when using the logical in a bit manipulation
operation. If you use each bit for a different function in your
code and apply a bit manipulation operation (e.g., FECDE
.XOR. Logical Label), then the
problems are compounded. You must reverse all masks used in the bit
manipulation operation—a considerable amount of work.

Another area of concern is the data files used to store
navigation and engine data interpolation information. The byte
order in these data files must also be reversed to read data
correctly into their assigned CDB labels. Our ANSI C code does not
have this problem. Most of the C code compiled with relatively
little change.

Aural warning system conversation required a minor amount of
work. Under AIX, all audio warnings were designed to work with a
DSP card with one large digital audio file. We were required to
convert the large digital aural warnings data files into separate
PCM wave files. A newly coded audio software module was then needed
to cross-index the requested aural warnings to their corresponding
wave file and pipe them to a standard SoundBlaster audio card.
Throw in all the graphics files and IOS pages (Instructor Operator
System Pages, Figure 15), and we have an enormous porting
task.