DFBW F-8: Phase II

On November 16, 1973, the DFBW team received a NASA group achieve­ment award for its highly impressive accomplishments during the Phase I effort. By that time, planning was well underway for the Phase II effort, with the first version of the software specification having already been issued in April 1973. Whereas Phase I had verified the feasibility of flight control using a digital computer, Phase II was intended to develop a more practical approach to the implementation of digital flight control, one that could be used to justify the incorporation of digital technology into production designs for both military and commercial use. In the Phase

II design, the single channel Apollo computer-based flight control sys­tem was replaced with a triply redundant flight control system approach using three International Business Machines (IBM) AP-101 digital com­puters. The challenge was how to program this multicomputer system to act as a single computer in processing flight control laws and directing aircraft maneuvers while functioning independently for purposes of fault tolerance.[1160] The 32-bit IBM AP-101 computer had been selected for use in the Space Shuttle. It consumed 370 watts of power, weighed about 50 pounds, and had 32,000 words of memory.[1161] The DFBW program decided to also use the AP-101 computer in its Phase II effort, and a purchase contact with IBM was signed in August 1973. However, the reliability of the AP-101 computer, as measured by mean time between failures, left much to be desired. The computer would turn out to require major rede­sign, and it never came close to meeting its reliability projections. As Ken Szalai recently commented: "the IBM AP-101 computer was one of the last of the ‘beasts.’ It was big and ran hot. The circuit boards tended to fail as temperatures increased. This was found to be due to thermal expan­sion causing the layers within the circuit boards to separate breaking their electrical connections.” Szalai recounted that he notified the Space Shuttle team as soon as the issue was discovered. They were surprised, as they had never seen a similar problem with the AP-101. The reason soon became apparent. The AP-101s installed in the F-8 Iron Bird were being tested in a non-air-conditioned hangar; Space Shuttle flight control sys­tem testing had been in a 50 degree Fahrenheit (50 °F) cooled laboratory environment. When the Space Shuttle was tested on the flight line in typ­ical outside temperatures encountered at Dryden, similar reliability prob­lems were encountered. IBM subsequently changed the thermal coating process used in the manufacture of the AP-101 circuit boards, a measure that partly resolved the AP-101’s reliability problems.[1162]

Software for Phase II was also larger and more complex than that used in Phase I because of the need for new pilot interface devices. Flight control modes still included the direct (DIR) mode, the stability aug­mentation (SAS) mode, and the control-augmentation (CAS) mode. A pitch maneuver-load-control feature was added to the CAS mode, and a digital autopilot was fitted that incorporated Mach hold, altitude-hold,

and heading-hold selections. The software gradually matured to the point where pilots could begin verification evaluations in the Iron Bird sim­ulator in early 1976. By July, no anomalies were reported in the latest software release, with the direct and stability-augmentation modes con­sidered flight-ready. The autopilot and control-augmentation mode still required more development, but they were not necessary for first flight.

The backup analog flight control system was also redesigned for Phase II, and the secondary actuators were upgraded. Sperry supplied an updated version of the Phase I Backup Control System using the same technology that had been used in the Air Force’s YF-4E project. Signals from the analog computers were now force-summed when they reached the actuators, resulting in a quicker response. The redesigned secondary actuators provided 20 percent more force, and they were also more reli­able. The hydraulic actuators used in Phase I had two sources of hydraulic pressure for the actuators; in those chosen for Phase II, there were three hydraulic sources that corresponded with the three channels in each of the primary and secondary flight control systems. The secondary elec­tronic actuators had three channels, with one dedicated to each computer in the primary system. The actuators were shared by the analog com­puter bypass system in the event of failure of the primary digital system.

The final Phase II design review occurred in late May 1975, with both the Iron Bird and aircraft 802 undergoing modification well into 1976. By early April, Gary Krier was able to fly the Iron Bird simulator with flight hardware and software. Handling qualities were generally rated as very good, but actuator anomalies and transients were noted, as were some problems with the latest software releases. After these issues were resolved, a flight qualification review was completed on August 20. High-speed taxi tests beginning 3 days later, then, on August 27, 1976, Gary Krier took off on the first flight of the Phase II program. On the second Phase II flight, one of the AP-101 computers failed with the aircraft at supersonic speed. An uneventful landing was accomplished with the flight control system remaining in the primary flight control mode. This was in accordance with the established flight-test procedure in the event of a failure of one of the primary computers. Flight-testing was halted, and all AP-101s were sent back to IBM for refurbishment. After 4 months, the AP-101s were back at Dryden, but another AP-101 computer failure occurred on the very next flight. Again, the primary digital flight control system handled the failure well, and flights were soon being accomplished without inci­dent, providing ever increasing confidence in the system.

In the spring of 1977, the DFBW F-8 was modified to support the Space Shuttle program. It flew eight times with the Shuttle Backup Flight System’s software test package running in parallel with the F-8 flight control software. Data from this package were downlinked as the F-8 pilots flew a series of simulated Shuttle landing profiles. Later in 1977, the unpowered Space Shuttle Enterprise was being used to evaluate the flight characteristics of the Space Shuttle during approach and landing in preparation for full-up shuttle missions. During the Shuttle Approach and Landing Test (ALT) program, the Enterprise was carried aloft atop the NASA 747 Shuttle carrier aircraft. After release, the Shuttle’s han­dling qualities and the responsiveness of its digital fly-by-wire system were evaluated. On the fifth and last of the shuttle ALT flights in October 1977, a pilot-induced oscillation developed just as the Enterprise was landing. The DFBW F-8C was then used in a project oriented to dupli­cating the PIO problem encountered on the Shuttle during a series of flights in 1978 that were initially flown by Krier and McMurtry. They were joined by Einar K. Enevoldson and John A. Manke, who had exten­sive experience flying NASA lifting body vehicles. The lifting body vehi­cles used side stick controllers and had approach characteristics that were similar to those of the Space Shuttle.

Flying simulated Shuttle landing profiles with the DFBW F-8, the pilots gathered extremely valuable data that supported the Shuttle pro­gram in establishing sampling rates and control law execution limits. The DFBW F-8 flight control software had been modified to enable the pilot to vary transport delay times to evaluate their effect on control response. Transport delay is the elapsed time between pilot movement of his cockpit control and the actual movement of the flight control sur­faces. It is a function of several factors, including the time needed to do analog-to-digital conversion, the time required to execute the appropri­ate flight control law, length of the electrical wires to the actuators, and the lag in response of the hydraulic system. If transport delay is too long, the pilot may direct additional control surface movement while his ini­tial commands are in the process of being executed by the flight control system. This can result in overcontrol. Subsequent attempts to correct the overshoot can lead to a series of alternating overshoots or oscilla­tions that are commonly referred to as a PIO. The range of transport delay times within which the Shuttle would be unlikely to encounter a PIO was determined using the DFBW F-8, enabling Dryden to develop a PIO suppression filter for the Shuttle. The PIO suppression filter was

successfully evaluated in the F-8, installed in the Shuttle prior to its first mission into space, and proved to effectively eliminate the PIO issue.[1163]

During Phase II, 169 flights were accomplished with several other test pilots joining the program, including Stephen D. Ishmael, Rogers Smith, and Edward Schneider. In addition to its previously noted accom­plishments, the DFBW F-8 successfully evaluated adaptive control law approaches that would later become standard in many FBW aircraft. It was used in the Optimum Trajectory Research Experiment (OPTRE). This involved testing data uplink and downlink between the F-8 and a computer in the then-new Remotely Piloted Vehicle Facility. This exper­iment demonstrated that an aircraft equipped with a digital flight con­trol system could be flown using control laws that were operating in ground-based digital computers. The F-8 conducted the first in-flight eval­uations of an automatic angle-of-attack limiter and maneuvering flaps. These features are now commonly used on nearly all military and com­mercial aircraft with fly-by-wire flight controls. The DFBW F-8 also suc­cessfully tested an approach that used a backup software system known as the Resident Backup System (REBUS) to survive potential software faults that could cause all three primary flight control system comput­ers to fail. The REBUS concept was later used in other experimental aircraft, as well as in production fly-by-wire flight control systems. The final flight-test effort of the DFBW program involved the development of a methodology called analytical redundancy management. In this concept, dynamic and kinematic relationships between dissimilar sen­sors and measurements were used to detect and isolate sensor failures.[1164]