Programming the Moon Flights

With the exception of integrated circuits and extremely high reliability, the hardware for the Apollo guidance computer represented the state of the art when Apollo began. The same could not be said of the software and user interface. An aspect of the system barely envisioned when the program started, software turned out to be among the most difficult, and the most critical, components in the Apollo system. The software would carry all the burden of Richard Battin's complex guidance schemes. It would embody the goals and constraints of specific missions, and hence would require special finesse (sometimes completely new programs) for each one. It would control the flight at critical moments and stand between the astronauts, their machines, and the ground controllers and their tasks. Most important, it would interact with the astronauts, who might do unpredictable things at strange times in seemingly random order. As the Latin aphorism quoted above warned, the code contained secrets and hidden truths not apparent to the user.

Apollo began in a world when hardware and electronics were suspect and might fail anytime. It ended with the realization that as electronics became integrated, computers could become reliable, but that software held promise and peril. It could automate the flying, eliminate black boxes from the cramped cabin, and make the subtlest maneuvers seem simple. Yet it was also hideously complex and difficult to manage. If it went wrong at a bad time, it could abort a mission or kill its users.

When NASA first let the contract to the IL for Apollo guidance, programming was barely mentioned. In fact, the word software does not appear in the original statement of work. The word had only come into use in the late 1950s (The Oxford English

Dictionary lists the first usage of the term as I960).1 The original work statement referred to programming only twice, the most extensive reference being: ''The onboard guidance computer must be programmed to control the other guidance subsystems and to implement the various guidance schemes.''2 Software was not included in the schedule, and it was not included in the budget. The absence of software in the initial plans reflected not only an underestimation of the effort, but also the belief that writing code was part of engineering the system, not a discrete activity. Dick Battin likes to recount that when he told his wife he was in charge of Apollo's ''software,'' she found it unmanly and joked ''please don't tell our friends.''3

At the start, there were fewer specially trained programmers than engineers who could turn their ideas into executable code. As the IL's official history put it, ''It was believed that competent engineers with a credible, solid mathematical background could learn computer programming much more easily than programmers could learn the engineering aspects of the effort.''4 And it was difficult to find people who were skilled at both. Programming was new enough that it was not broadly recognized as a technical, much less engineering skill. Jack Garman managed the software project for NASA for a few years, and he recalled an attitude that ''the real problems [in spaceflight] are in propulsion or in... plumbing. I mean pressure vessels and stuff like that. That's where the real macho kind of space biz is.''5 Just writing instructions for the digital circuits still seemed a soft afterthought. The IL was fundamentally a guidance and control organization—mathematics, electronics, and the high-precision gyros were the dominant technologies. Obscure lines of machine code didn't have their own place of prestige in the organization.

Nevertheless, in the summer of 1961 a few engineers at the IL got started programming. Battin was in charge, with a laid-back management style typical of dedicated academics. ''He didn't really run it,'' one of his engineers recalled, ''he just nodded.'' Another thought of him as ''a real hands off manager, just a guru in his corner.''6 In the early days NASA's attention was on Mercury and Gemini, and the IL engineers had a great deal of autonomy. Dan Lickly, who worked on reentry guidance, remembered a loose environment.7

Fred Martin, a calm, intense engineer, started at the IL in 1956, working on autopilots and fire-control systems before winding up in the Polaris program. He then went back to school at MIT, though he stayed at the IL and joined Battin's guidance and navigation group. Martin soon became the project manager for the CSM software, which, before the LOR decision, comprised all of the Apollo flight code. Martin remembered the ''small group, seat of the pants effort that was unfettered and unhindered by NASA and devoid, pretty much, of real bureaucracy.'' He divided up the program, assigned tasks to different people, and kept track of their progress.

Some who worked for Martin remembered his subtle, hands-off style, ''like a psychi-atrist.''8 During this early period, the group focused on the fundamental engineering issues associated with getting to the moon, particularly the subtle mathematical models and numerical filters required to robustly solve the guidance equations in realtime.9 Some referred to it as the ''systems engineering phase,'' when budgets and schedules were loose and the group could afford to look at the big picture.10 Guidance to the moon seemed an interesting mathematical problem, and a calculating machine should be able to handle it without much trouble.

People at the lab worked long hours focused on a clear goal with compelling technical challenges. As in the rest of Apollo, sixty- or seventy-hour work weeks became the norm. ''There was a feeling of national urgency, you might say, of national responsibility,'' Martin recalled. ''You had the astronauts coming to the lab regularly____You had the pressure of what was going on.'' The IL group felt that NASA and the astronauts held them on a pedestal: ''Everybody was a guru and everybody was a genius.'' Lickly remembered ''a very privileged position,'' as the programmers regularly received visits not only from astronauts, but also from von Braun and the top NASA management, ''all those people we got to talk to as a small sort of elite organization.''11 Some IL engineers never found such creative excitement again in their careers.

Apollo software would be the product of many people's work, integrated into a coherent whole. Martin's group had physicists and mathematicians and engineers, ''probably had a literature major here and there too,'' he said, but no computer scientists. As few people were coming out of school with computer science degrees (MIT did not even create its department as part of electrical engineering until 1968), the IL group included people like Alex Kosmala and Margaret Hamilton. Hamilton, one of the few women engineers in all of the Apollo program, had a mathematics degree and had already worked as a programmer on the SAGE air defense system at MIT's Lincoln Labs. Lickly worked on the reentry programs for the command module. Others focused on navigation, or the inertial platform.

The LOR decision was not made until a year after the IL began working, so software design and programming began in a vacuum of detailed mission goals and specifications. Engineer Ed Copps remembered an exciting time as they contemplated the possibilities of a small computer onboard a spacecraft flying to the moon: ''We had automata doing things that we had not planned for them to do____We were the new guys coming to grips with new capabilities, which were now placing conceptual issues within the reach of actual implementation____We designed it in a very abstract way.''12 One day Kosmala, a programmer, went to the MIT library and looked up a series of star coordinates to align the inertial platform, which he then embedded into the code. That star catalog survived into the final version and became the basis for the astronauts' navigation to the moon.

The official IL report on the software effort credited its success to ''an intricately-tuned interaction among men and machines.''13 Interestingly, this statement refers not to the interactions aboard the spacecraft, but rather to the coordinating and scheduling of engineers and programmers on the ground, and their mainframes and simulation machines. Early on, of course, no actual Apollo computer existed to test the programs. The IL had a number of mainframes, including a Honeywell 1800 and the new IBM 360, which ran simulations of the Apollo computers. Indeed, throughout the program the software ran in simulation for validation on these machines, as well as on actual Apollo hardware. A digital simulator could analyze program operation in great detail, step by step, with a host of tracing and reporting tools, but at a comparatively slow speed. The simulator included routines like UNIVERSE, LUNAR, and TERRAIN to model various environments, and even one called ASTRONAUT that simulated the human operator. To complement these digital models, analog computers simulated the spacecraft's dynamics, from center of mass and rocket thrust to parameters for structural bending and fuel slosh, connected to models of the AGC that would run in real-time. Hybrid simulators mixed the two, and even included a sextant, an inertial unit, and a full user interface, allowing engineers and astronauts to exercise the system from the front panel.14 Together, they amounted to building the Apollo spacecraft and traveling to the moon in a completely numerical, virtual environment, an electronic equivalent of the wind tunnels of an earlier era.

During the 1960s, just across the same campus, project MAC at MIT was incubating much of the technology and culture that underlay computing today, from graphical user interfaces to the nocturnal hacker culture. Students and young engineers were becoming enthralled with the creative potential and practical difficulty of interactive computing. Apollo programmers at the IL, while a separate group in distant buildings, shared some of this ethos. They tended to believe that any program could be written by a few smart people. As the project grew, they began to realize the need for more help, but were reluctant to jeopardize their small-group culture. ''We've got to do this with either five people, maybe, or we've got to do it with 150,'' Jim Miller remembered thinking.15 The group, he said, developed a closed, proprietary attitude toward their system: ''We couldn't figure out why anyone else needed to know what was in the guidance computer besides us. What does NASA need to know for?''16

Of course, NASA needed to know because that was how its managers practiced systems engineering, where every subsystem had to be a white box open to scrutiny. And they were the customer. Martin later realized that MIT's hard-headed, creative exuberance appeared to NASA as exclusionary. ''I think that that arrogance started to irritate people,'' Martin said, ''who were tired of hearing that MIT knew best and knew better.'' NASA began to feel the need to ''rein in'' the IL, ''to get them on this program not on their own program.''17

Only in 1964 did NASA begin a series of meetings of a ''G&N system Panel'' to coordinate requirements among the contractors. Another series of meetings began to specify the interfaces—how the computers would read data and command actions of the spacecrafts' various sensors and actuators.18 The computer, it turned out, especially

Block II, would tie together numerous different systems in the vehicle—from clocks and needles to hand controllers and rocket engines.

Telescopes Mastery

Telescopes Mastery

Through this ebook, you are going to learn what you will need to know all about the telescopes that can provide a fun and rewarding hobby for you and your family!

Get My Free Ebook


Post a comment