NASA Observations

NASA observations on some of the more serious issues encountered in early testing of the AFTI/F-16 asynchronous digital flight control sys­tem are worthy of note. For example, an unknown failure in the Stores Management System on flight No. 15 caused it to request DFCS mode changes at a rate of 50 times per second. The DFCS could not keep up and responded at a rate of 5 mode changes per second. The pilot reported that the aircraft felt like it was in severe turbulence. The flight was aborted, and the aircraft landed safely. Subsequent analysis showed that if the aircraft had been maneuvering at the time, the DFCS would have failed. A subsequent software modification improved the DFCS’s immunity to this failure mode.[1202]

A highly significant flight control law anomaly was encountered on AFTI/F-16 flight No. 36. Following a planned maximum rudder "step and hold” input by the pilot, a 3-second departure from controlled flight occurred. Sideslip angle exceeded 20 degrees, normal acceleration fluc­tuated from -4 g to +7 g, angle of attack varied between -10 and +20 degrees, and the aircraft rolled 360 degrees. Severe structural loads were encountered with the vertical tailfin exceeding its design load. During the out-of-control situation, all control surfaces were operating at rate limits, and failure indications were received from the hydraulics and canard actuators. The failures were transient and reset after the pilot regained control. The problem was traced to a fault in the programmed flight control laws. It was determined that the aerodynamic model used to develop the control laws did not accurately model the nonlinear nature of yaw stability variations as a function of higher sideslip angles. The same inaccurate control laws were also used in the real-time AFTI/F-16 ground flight simulator. An additional complication was caused when the side fuselage-mounted air-data probes were blanked by the canard
at the high angles of attack and sideslip encountered. This resulted in incorrect air data values being passed to the DFCS. Operating asynchro­nously, the different flight control system channels took different paths through the flight control laws. Analysis showed these faults could have caused complete failure of the DFCS and reversion to analog backup.[1203] Subsequently, the canards were removed from the command path to prevent the AFTI/F-16 from obtaining higher yaw angles.

AFTI/F-16 flight-testing revealed numerous other flight control prob­lems of a similar nature. These prompted NASA engineer Dale Mackall to report: "The asynchronous design of the [AFTI/F-16] DFCS introduced a random, unpredictable characteristic into the system. The system became untestable in that testing for each of the possible time relation­ships between the computers was impossible. This random time rela­tionship was a major contributor to the flight test anomalies. Adversely affecting testability and having only postulated benefits, asynchronous operation of the DFCS demonstrated the need to avoid random, unpre­dictable, and uncompensated design characteristics.” Mackall also pro­vided additional observations that would prove to be highly valuable in developing, validating, and certifying future software-intensive digital fly-by-wire flight control system designs. Urging more formal approaches and rigorous control over the flight control system software design and development process, Mackall reported:

The criticality and number of anomalies discovered in flight and ground tests owing to design oversights are more significant than those anomalies caused by actual hardware failures or software errors. . . . As the operational requirements of avionics systems increase, complexity increases. . . . If the complexity is required, a method to make system designs more understandable, more visible, is needed. . . qualification of such a complex system as this, to some given level of reliability, is difficult. . . the number of test conditions becomes so large that conventional testing methods would require a decade for completion. The fault – tolerant design can also affect overall system reliability by being made too complex and by adding characteristics which are ran­dom in nature, creating an untestable design.[1204]