Developing a Real-Time Full-Flight Simulator Using LabVIEW and Compact FieldPoint

 Read in  |   Print
  |   PDF  |  

"Although we previously thought of graphical dataflow programming as an aid to engineering design and manufacturing, it has proven to also be an effective tool for developing a real-time, full-flight simulator."

- Terry Keenan, Keenan Simulation Corporation

The Challenge:
Designing and building a DC-9 full-flight simulator that meets Federal Aviation Administration (FAA) Level D standards for the US Navy.

The Solution:
Using NI Compact FieldPoint hardware and LabVIEW software to replace the entire linkage system of an existing simulator, which consisted of 1,800 channels of cockpit instrumentation.

Terry Keenan - Keenan Simulation Corporation


This project called for a new, updated DC-9 Level D full-flight simulator to match the new glass cockpits of the naval fleet. This project was an ideal platform for the proof of concept phase in developing a graphical dataflow simulator. With limited choices for a new host with a real-time scheduler, we decided to conduct the first phase of this study, the Dataflow Architecture Flight Simulation Study (DAFSS). We started by recovering and rehosting a traditional DC-9 simulation system that originally ran on a 1984 Gould SEL Model 8760 computer and was coded in FORTRAN. We considered the differences between starting from scratch and purchasing one of the older DC-9 simulators and upgrading it. Since the DC-9 was an older airplane, we found a few existing simulators that were very good candidates to be purchased and upgraded. We ultimately purchased a Singer Link DC-9 simulator from Aeromexico because it was also originally programmed in FORTRAN and remained in service for 20 years without any major upgrades.

We began the project by reviewing the requirements for the Level D simulator contract. The Singer Link still had the original DC-9 cockpit instruments and associated hardware links along with its motion base, flight controls, visual system, and instructor station. After carefully considering each system based on the level of effort and associated cost to recover it, we decided to only recover the FORTRAN program itself. The hardware was simply too far out of date to be reusable or maintainable. We replaced the cockpit instruments’ hardware interface with a combination of National Instruments products including Compact FieldPoint. Figure 1 shows our system’s interface cabinet.

Figure 1: NI Compact FieldPoint Cockpit Instrument Interface Cabinet

Though we had the DC-9 code base, we needed to design or purchase several new systems. First, we needed a suitable real-time PC platform to run the recovered FORTRAN program. With limited options available, we chose a Concurrent RedHawk system. To recover the DC-9 program, we faced two main issues. First, we needed to recover the scheduler and file revisions that were currently running in the Singer Link executable. All of these files must be organized and rebuilt onto the Concurrent system along with the data pool of program variables. Second, the lookup table functions for all of the aircraft data packages were separate intrinsic functions of the Gould mainframe OS, so we needed a replacement for these functions that fit within both the project’s budget and schedule.

Dataflow Programming

Initially, we chose MathWorks, Inc. Simulink® software for the project because it is a well-known simulation modeling tool that contains aerodynamic examples. Integrating the aerodynamic data into the Simulink environment and the lookup table functions worked perfectly, but getting these functions to run as replacements in the original FORTRAN code proved very difficult. Exporting the model functions out of Simulink to run on real-time hardware requires a separate package called the Simulink Real-Time Workshop™. This export generated over 20,000 lines of text-based code and still left us unable to integrate the code in the FORTRAN program and replace the incompatible lookup table functions. The scheduling time crunch began to take its toll on our engineering group, which is made up of both text-based and dataflow programmers. The text-based programmers wanted to search through the code generated by Simulink for functions they could remove and rebuild into their own code structures. The dataflow programmers argued that this would invalidate the original dataflow diagram.

Programming in LabVIEW

The dataflow programmers decided to try a different approach with a commercial dataflow programming environment called LabVIEW. Although this environment is commonly used for test and automation, it had all the necessary lookup table functions.  Again, the aerodynamic table data imported properly and the functions ran perfectly. With LabVIEW, however, we could build the dataflow diagram functions directly into shared libraries without generating any text-based code. This successfully eliminated the disagreements between the text-based and dataflow programmers and saved the project schedule. The engineers put a simple ANSI C code wrapper around the shared library function calls with the same name as the original Gould function, which allowed them to call the libraries directly with the original FORTRAN program. Based on the success achieved with the dataflow lookup functions, we programmed many more systems with LabVIEW, including an instructor station, drivers for the new glass cockpit instruments, a Fokker control loading interface, an RSI Visual Systems interface, and a data-logging system for the FAA 120-40B test. We built all of these systems directly into either a shared library or an executable. We discovered that the key to using a visual dataflow environment is requiring that it build directly into a shared library or executable. If it generates code, as our Simulink trial did, the text-based programmer’s first instinct is to edit the code, not the dataflow diagram that generated it. This creates the risk of losing the changes if the code is regenerated from the block diagram. Figure 2 shows the LabVIEW block diagram for the DC-9 simulation.



Figure 2:  Top-Level LabVIEW Graphical Dataflow Diagram for the DC-9 Simulation

With the successes mounting, our engineers decided to try expanding the data lookup functions into the full coefficients section of the DC-9. Rather than build the LabVIEW dataflow diagram of the complete coefficients into a library, they decided to build them directly into an executable and began benchmarking the timing. We first measured the Concurrent PC running the original FORTRAN program, then called the dataflow shared libraries against the executable built in LabVIEW. We found that both ran at approximately 1 millisecond. At this point, we became convinced that we could use LabVIEW to design the entire flight model. We continued the experiment and converted the equations of motion, ground effects, and parts of the navigation into the LabVIEW environment. When completed, the core of the DC-9 flight model was built directly into a LabVIEW executable and ran in 7 milliseconds, leaving over 50 percent spare time.

During the DC-9 rehost process, we recognized many other benefits of graphical dataflow programming, including natural parallelism for use on multicore computers, simplified project management, and significant reduction in the cost and complexity of flight simulation development, documentation, and maintenance. Although we previously thought of graphical dataflow programming as an aid to engineering design and manufacturing, it has proven to also be an effective tool for developing a real-time, full-flight simulator.

Since this was a completely new approach to flight simulation, we were unsure if it would work. Various flight simulation engineers initially responded that they thought a simulation based on graphical dataflow programming would run much slower and therefore not be a feasible real-time training device. Therefore, we needed to prove that a dataflow-based, full-flight simulation model can run within the real-time frame rate of 60 Hz, with at least 20 percent spare time between frames. Other important requirements for both the lookup table libraries and the flight model executable included developing a program that can build and run directly on a real-time kernel and support the drivers for 1,800 linkage I/O channels. We found that National Instruments software and hardware products met all of our requirements, resulting in a low-cost, high-fidelity flight training device. See Figure 3 for a view of the completed cockpit.

Figure 3: Completed DC-9 Flight Simulator Cockpit

Simulink® is a registered trademark of MathWorks, Inc.

Author Information:
Terry Keenan
Keenan Simulation Corporation
P.O. Box 2227
Castle Rock, CO 80104
United States
Tel: 303-990-9649

Bookmark and Share

Explore the NI Developer Community

Discover and collaborate on the latest example code and tutorials with a worldwide community of engineers and scientists.

‌Check‌ out‌ the‌ NI‌ Community

Who is National Instruments?

National Instruments provides a graphical system design platform for test, control, and embedded design applications that is transforming the way engineers and scientists design, prototype, and deploy systems.

‌Learn‌ more‌ about‌ NI