The Transition to Automation
With the RCA 110A computers on line for the first Saturn IB mission, Hans Gruene's Launch Vehicle Operations team found itself totally dependent on computers and computer programs. They were not dependent, however, on automation. Having approached the idea of automated testing with reservations, they insisted that the Saturn design provide for manual testing as well as automation. Hence, LC-34's complex provided a dual capability. Test engineers could proceed in the traditional manner - initiating commands from switchboards and checking the results on meters, strip recorders, and cathode ray tube displays. In this mode, testing would remain essentially manual, with the computer complex serving as an expensive data link. Or the launch team could convert the manual test procedures into computer programs for interpretation and execution by the 110As. During the early IB missions, manual procedures predominated. Besides the inevitable resistance to change, systems engineers had trouble converting their test procedures into machine language. Development of a special computer test language alleviated the latter problem, while Gruene's leadership prevailed over personal inertia. By the end of Apollo, most launch vehicle tests were fully automated programs.17
Saturn ground computers employed two types of programs: operating system and test. As the name implied, the operating system program was the computer's basic software. It operated continuously, seeking alternate paths when a failure was detected. Manual testing of the Saturn vehicle was accomplished through this program. Test and monitor programs provided the means to automate the checkout process; they were the system engineer's primary software tool. Test programs could be prepared in machine language, using the full capability of the computer's logic, or in Atoll (Acceptance Test Or Launch Language), a form of engineer's shorthand. Once prepared, the test programs performed a number of important tasks: sequencing required events during a test, evaluating system responses, monitoring, displaying anomalies, and tying together a series of programs. A test program could preselect the operation sequence, change the limits of tested values, and intervene during the operation. On the later Apollo missions, test programs accomplished much of the routine checkout. Engineers would initiate programs through console keyboards and react when problems arose. Many of the tests would start on their own - the launch team having programmed the computer to call up test programs at a certain time in the countdown or when another test was successfully completed. While test programs were the key to automated checkout, maintenance and post-test processing programs played an important role. Maintenance programs tested the interfaces between RCA 110As and related equipment. With the post-test processing programs, engineers converted raw data into usable printouts.18
Changing test procedures into computer programs may well have been the highest hurdle in Saturn automation. Early Saturn I automation rested largely with IBM, Huntsville's contractor for computer software. From KSC requirements, IBM programmers and system analysts prepared machine-language programs. The Automation Office provided the coordination between Saturn test engineers and IBM computer experts. Unfortunately, it was not simply a matter of converting a few lines from English into a computer program. KSC's manual procedures did not spell out every detail; many contingency actions depended upon an engineer's intimate knowledge of a system. Inevitably, misunderstandings arose. Some KSC systems engineers viewed the process as a one-way street: IBM programmers were gaining a knowledge of Saturn hardware while KSC engineers learned little about automation. Furthermore, as Saturn automation grew, requirements for IBM support increased. Clearly, KSC needed some way to simplify the conversion from test procedure to computer program - a route that would bypass machine language.19
The solution was Atoll, a computer language under development at Huntsville's Quality Laboratory. By 1965 the Astrionics Laboratory and IBM were incorporating Atoll into IB plans. KSC's automation team helped define launch site requirements for the new software system. The AS-201 mission in February 1966 used only a half-dozen Atoll procedures, but subsequent launches showed increasing numbers as KSC engineers converted from manual procedures to computer programs. There were 21 Atoll programs on AS- 501, 43 on AS-506 (Apollo 11), and 105 by the Apollo 14 launch in early 1971. Atoll proved particularly valuable for Saturn systems that changed from one mission to the next. While modifications to machine language procedures required approval from Marshall, KSC's Automation Office controlled Atoll. Changes could therefore be approved quickly at the launch center. More importantly, Atoll involved the test engineers directly and its use was instrumental in their acceptance of computerized checkout.20
| Next |