Part 1 here.
Hardware and Software Development:
Early computers, being the size of rooms and lacking reliability, were considered out of the question for use in a range of applications, not just aviation. The amount of work (calculations) these early computers could do in a relatively short period of time, in the mind of scientists in the late 1940s outweighed the abysmal reliability.
That reliability can be traced to the number of parts in a system. Analog computers had a large number of moving parts therefore not a not very reliable. Digital computers on the other hand and fewer moving parts and better reliability. That meant a digital computer was an easy early choice in the NASA’s F-8 Program.
By the late 1950s digital computers were small enough (not by today’s standards) to be considered to be installed in aircraft. Most of the output errors in these early digital computers was due to manufacturing defects in vacuum tubes in the logic circuits. In 1952, John Van Nuemann, suggested that all systems fail at some point and the solution was to use triplicate logic circuits to “vote” on what was valid output. This solution really wasn’t practicable for aviation until a few years later when transistors started to replace vacuum tubes in digital computers.
The Voyager 1 Spacecraft
In the 1960s a group of General Electric engineers stumbled across Van Nuemann lectures on redundancy, as it was to be called, and did some projections that showed that identical software feeding outputs from individual computers to majority logic voters made failures 300 times less likely in 100 hours of operations. As a matter of fact the longest lived spacecraft, Voyager 1, features a 3 digital computer redundant system…and it’s STILL working! The Saturn V booster also used a similar “triple-redundant” computer . At the that time continued shrinkage of the computer hardware meant that processor units could be made redundant.
The Saturn V booster rocket.
All this paid dividends in the Apollo and F-8 programs. Draper Laboratory won the contract to develop the guidance and navigation computers. During hardware development, Draper Lab implemented very strict quality controls (QA, quality assurance) of manufacture. In fact so much so, that “every piece of metal could be traced to the mine it came from.” The strict QA paid off as there were 16 computer and 36 display and keyboard system failures in the 42 computers and 64 DSKYs (Display and Keyboard Unit) built – all on the ground. Along with zero in-flight failures in 1,400 hours of operation, Draper Lab was able to achieve a 99.9% reliability (over the target reliability rate for Apollo of 99.8%).
Software QA and validation became a major cost driver in the Apollo program and by 1967 NASA approached Bellcomm, Inc to study successful software development and management techniques. These processes formed a baseline for QA and development standards for the software industry, years in to the future.
In the F-8 program, Nasa’s Dryden Flight Research Center would be responsible for overall vehicle integration. Draper Labs remained responsible for requirements analysis, software and interface design, simulator support and flight-test support.
No one had built an all digital flight control system before and Draper Labs ran into 2 issues initially. 1) the use of a digital system in an “all-analog” world and 2) how to ingrate the computer system in to an analog airplane. At the input end of the computer there was an analog-to-digital converter; at the output end a digital to analog to converter. When the pilot moved the stick, displacement translated to voltage. In the pitch axis for instance, the physical limit movement of the stick was 5.9 inches nose up and 4.35 inches nose down. The transformers were designed to generate a signal of plus or minus 3 volts. Therefore input to the analog-to-digital converter was scaled to the longer aft movement, so the forward movement had a maximum value of about 2.4 volts, while the aft movement topped out at –3.0 volts. The voltage from the transformers would be converted into bits and ten be used as input to the software control laws.
Control devices in each axis have a deadband region in which small movements of the stick have no result. In a mechanical, systems the deadband is caused by stretching of the control cables from age and use. This deadband can vary over the lifetime of the cables and the aircraft and each axis has a unique deadband region. In a FBW system, small discrepancies are magnified. If the FBW designers ignored the deadband, the control surfaces would move with every tiny motion of the stick and rudder pedals. The airplane would become too sensitive to fly without the occurrence of pilot induced oscillations (PIOs) that result from constant attempts to dampen motion. Deadband had to dealt with via good old fashioned trial and error.
On the output end, signals causing gearing gains had to be calibrated. Gearing was non-linear because movement of a control device was translated by control laws into movement of the appropriate control surface. This was done by adjusting a linear variable differential transformer to provide a corresponding response.
The digital flight control system for Phase 1 tests of NASA’s F-8 Crusader
Both deadband and gearing equations were at the center of control law development. The output to the actuators was a sum of the trim command from the electric trim button on the stick and the product of the stick gearing gain and stick deflection.
Through sampling techniques done every 30 milliseconds by the computer, control calculations would occur every 8 to 15 milliseconds.
Control law equations were written into specifications arranged by axis and functional groupings with no attention being paid to how they where used by the flight-control computer. This made the equations more difficult to manipulate and use. Here’s an example from Tomayko:
“DE meant “delta” or “change,” C is “command,” K is “constant,” GE is “gearing,” P is “pilot” and T is “trim.” The equation can be loosely translated as: “The command change equals the gearing gain times the pilot stick position plus the change in trim.”
Names for each variable were different for each axis of flight.
Changes to the software specification took place up to March 1973 when the final version of the flight-control software was published. In that time there were many which were managed by a 4-layer system. The lowest impact were “Assembly Control Board” requests. There were straight forward code changes that could be approved by the software manager at Draper. The next highest was an Anomaly – an error that needed to be repaired. Both DFRC and Draper signed off on it. Next was a Draper designed Program Change Notice – during development something that could not be implemented in the desired way, so the implementation had to be changed. Both managers signed off on this. The highest level was a “Program Change Request” – a chance to the specification. Both software and project managers had to sign off on this, as there was schedule and budget impacts.
Rope memory from the Apollo Guidance Computer
The name for the flight control software was “DIGFLY” which was pronounced “digifly” and was written in FORTRAN. There were 2 copies of DIGFLY in the computer memory core rope (here’s a video on how it’s actually done). DIGFLY itself was divided into system and application components. The system software provided task management, a restart segment, service routines to monitor the IMU and provide self test modes. The application software contained flight control and some miscellaneous components. 60% of the F-8 software was taken from the Apollo program.
Core rope memory test sample from the Apollo Program.
Converting the F-8 to DFW:
The F-8 Crusader was selected because there were quite a few airframes being retired and the F-8 itself had the internal space available for the necessary equipment. NASA received 4 airframes. F-8A Crusader Bureau Number (BuNo) 145385 was going to the be non-flying FBW test bed, the so-called “Iron Bird” and was given NASA tail number 816. F-8C BuNo 145546 (interestingly, the first C model to be built) was to the actual flying test bed aircraft. 546 was allocated NASA tail number 802.
F-8A Crusader NASA tail number 816 after the program.
F-8C 145546 (NASA tail number 802) photographed at the Naval Air Test Center in 1959.
Converting the F-8 to accommodate the DFBW hardware and software turned out to the rather straightforward, albeit with a lot work. Problems ranged from canopy that would fit to a sweatshirt found in 802’s fuel tank. It took a year to convert 802 but the interesting thing was that the aircraft retained its fighter-looks and for the most part, it’s performance.
A port side view of the Apollo hardware as installed in 802.
Cooling problems were the first hurdles and persisted until almost first flight. After all the testing to resolve the cool issue, which even included a redesign of the heat exchangers, it was found that someone forgot to turn on the external cart to cool the computer during engine run-up. DOH!
The Apollo guidance computer and inertial system (left) on a pallet with the cooling tank and associated piping on the right.
The core ropes containing the flight control software arrived from Raytheon in January 1972 and the second version of the software, DIGFLY 2 was undergoing test and development work by Draper Labs. DIGIFLY 2 would use what remained of Skylab’s core rope which turned out to be the last ropes made for an Apollo computer.
Control sticks were initially tested that were originally tested for the Lunar Module were used in the iron-bird and a DSKY (installed the F-8s left gun bay) from the Apollo 15 Command Module was used to replace one that had been previously blown out due to errors in power requirements.
The F-8 initially retained an analog backup flight control system as well as it’s stock APC (approach power compensator, an autopilot for the throttle).
In flight once the pilot positioned the stick and rudder pedals a completely electric system took over. The inertial measurement unit was an arrangement of accelerometers and gyros that could track altitude, velocity and position changes without depending on external devices to get data. This reference was compared to the pilot’s control inputs were expressed as voltage from transformers to the control stick and rudder pedals, these were called Linear Variable Differential Transformers (LVDTs). There were 2 installed installed at the base of the stick for each control axis, pitch, roll and yaw. Each one served the primary flight control system and the other the analog backup system.
Actuators in had 2 systems, a primary and analog backup. In primary mode the digital computer sent analog position signals for a single actuation cylinder. This cylinder was controlled by dual self monitoring servovalves. One valve controlled the servo and the other was there for comparison. If position values differed from each servovalve then the backup mode, 3 servocylinders in a 3 channel arrangement, would engage and control the flight surface.
There was an attempt to upgrade the power plant of 802 from the J57-P20A to a more powerful –p420 but there wasn’t time and the installed –P20 was sent to the Navy for refurbishment by the October 1971. By February 1972, the software and hardware had been thoroughly tested and installed in 802. The engine, pilot’s seat and tail were reinstalled in April.
It was time to fly :)