Apollo 11 at 50: Lessons from humanity’s greatest engineering

https://www.iise.org/iemagazine/2019-07/html/caldwell/caldwell.html

ISE Magazine July 2019 Volume: 51 Number: 7

By Barrett S. Caldwell

“What are you doing this summer?”

During late May on the Purdue campus and at many other research universities, this is a common greeting among faculty. Normally, it is a question addressing general hopes and promises of unstructured time, chances to re-turn to long-neglected projects and perhaps time for rest and recovery. However, my answer was very focused with a mission countdown clock updating on a nearly constant basis. T minus 51 days. “I’m working on the Apollo 11 anniversary.”

On July 20, 1969, there were “a bunch of guys about to turn blue,” realizing that one of the most complex and challenging systems engineering projects in human history had come down to a pilot from Ohio, trained at an Indiana engineering school, working with less than 30 seconds worth of fuel and a bunch of computer data overflow errors as he landed on the moon.

It is said that more than a billion people, perhaps a quarter of the world’s population, followed the progress of the Apollo 11 mission. Hundreds of thousands of children and adolescents were in the midst of a life-changing experience of inspiration and excitement to pursue careers in science and engineering.

I am one of those. Actually, my inspirational moment came a few months earlier, on Christmas Eve 1968. Listening to the crew of Apollo 8 send messages and pictures back from lunar orbit, I could think of no better direction for my life path to take: to pursue a career in astronautics and the grand dream of engineering the space program.

However, 50 years later, I am planning the celebration of those famous words displayed in front of the building named for Neil Armstrong, the man who spoke them: “Tranquility Base here. The Eagle has landed.” But many of the people who will visit the campus for this celebration were not born during the Apollo era. What lessons are there, in an event now described as history, that can still inspire creativity, curiosity and discovery?

I am eagerly searching out connections (I am always seeking to make connections for understanding) and unexpectedly, I find several of them from souvenirs, artifacts and memories in my own house.

The mission that inspired an engineer

Why are industrial and systems engineering tools and processes so important to me, and when did I learn them? I teach courses in systems engineering, and different considerations of what it means to be and think like an engineer. There was a photo in a box in my basement that brought back some of my fondest memories of childhood (Figure 1), and in it you can see the first genesis of an engineering approach to problem definition and understanding.

My father was not an engineer; he was a car salesman. We spent a lot of time talking about and experiencing cars – at the dealership, looking at them on the delivery trucks, even driving cars from one location to another on a “trade,” where a customer buying a car at one dealership learned that the car they wanted was at another maybe 50 to 150 miles away. The dealerships would exchange cars and sometimes special parts, so I began to learn about supply chain and inventory management

But most importantly, my father would teach me how to build plastic models of antique cars. He would show me how to read the instructions, separate the pieces, use structured techniques to build a piece of the model as a subsystem of the car and combine those subsystems into the finished model. He would say: “That’s a leaf suspension.” “That’s a steering mechanism.” “Read all the instructions first, so that you know what you’re trying to get done.”

Before Apollo, and even before I could read all of the instructions, my father was giving me a lesson I use to this day to manage the Apollo 11 celebration: Define the system, organize the system and work the system in a structured way. Thanks, Dad.

Systems: Models and flavors

Even now, I use examples of a plastic model of the Apollo lunar module (LM) seen in Figure 2 to demonstrate both the concept of models, and one of five distinct uses of the term, “systems engineering.” Clearly, the LM or the model car with my father aren’t meant to do exactly what their full size, reality based engineering systems do. They are meant to teach concepts and answer questions, and even to help with considerations of how to take component parts and structured procedures and use them to complete a finished product.

Those are different models than the Estes rockets I built out of balsa and cardboard. Those didn’t look as much like a real Saturn rocket as the Christmas 1969 present I received but are better at taking off from a launch pad and reaching an altitude of 500 feet or more. So these models are a form of systems engineering: Take components and rules and combine them to produce a product that allows you to ask and answer questions.

Interestingly, the effort to work with a team to organize the campus celebration is reminding me of other “flavors” of systems engineering. The planning for the Apollo 11 50th anniversary project has been filled with elements of managing a complex engineering project: defining scope, managing tasks, recognizing constraints and developing alternatives. In my collection of spaceflight artifacts, I found a document put together by prior generations of engineers worrying about sys-tem definition, planning and tracking: the “Apollo Management System” manual, produced by IBM in January 1968, as Volume 9 of the NASA/Apollo Program Management documentation.

The figures seem so straightforward until you recognize the complexity of managing not just all of the complex engineering components but the interdependencies and data inter-changes between them all (Figure 3), all in a document published less than 12 months after the fatal fire on Jan. 27, 1967, that killed the crew of Apollo 1 (including two other Purdue alumni, Gus Grissom and Roger Chaffee).

No, the campus celebration is not as complex, nor does it include the vast diversity of technical professionals as the original Apollo 11 mission it is intended to honor. But many of the elements of system integration are brought home to me with each planning meeting, email and telephone call that requires a response or resolution. Maybe I shouldn’t be surprised to learn that many of those elements can be described using the same section headings the Apollo Management System document used, so let me duplicate those headings as I describe additional experiences and lessons of systems management and mission execution.

“The Mission Operational System” (Section 1.5.1). As might be guessed from the name of the author (IBM) of the Apollo Management System report, the primary system definitions in this report address computer hard-ware and software as engineered artifacts. Each of the components has a particular responsibility to complete critical mission functions for the Apollo mission, ranging from pre-launch to re-entry, according to phases of flight and specific data flow requirements (see Figure 4).

In addition to the complexity of each of these components, there was a special emphasis on a supervisory control subsystem that “serves as the interface between the applications programs and equipment systems” of mission control and operational support teams. Note that the supervisory control function is not there to take over or replace these activities but to integrate the components and their functions. This is one of the most significant lessons of managing a team of people with a variety of skills and specialty domain knowledge.

Supervisory control is not a phrase that was in com-mon use in this sense in the mid-1960s. People were familiar with “command and control” in the sense of someone giving orders and others taking them. But empowering people to do excellent specialist work and assigning a different function to strategic coordination? From a systems engineering perspective, that is perhaps as radical an innovation as creating digital computers to calculate and transmit position and trajectory information in real time, or to configure engines to generate a million pounds of thrust using materials that didn’t exist a decade prior.

“Program Requirements Definition” (Section 4.2.2.1). Although the emphases on the computer configurations and data flows are of primary focus of this discussion of mission operations, one point is very obvious. The Apollo Management folks started with the mission goal of getting to the moon, not build the computer system. What is the mission goal for the “Apollo 11 + 50” celebration? This was a deceptively challenging question, and one for which the differences in possible answers became critical in addressing our sets of activities.

At its base: If the celebration was primarily a cam-pus-focused event, July is not a great time. Most of the campus is gone for the summer. Our university has been celebrating its 150th anniversary since fall 2018, and there have been many campus events, culminating in an astronaut reunion set for this October (see ac-companying article on Page 33). However, the Apollo missions are milestones, historic national and inter-national events that happen to have a unique Purdue twist. You don’t have to be a Purdue student or faculty or alumnus to be part of this grand arc, and the content we are creating and sharing with the public (including from NASA) is not just for our past but for inspiring current and future innovations (and innovators) in the STEM (science, technology, engineering and math) fields.

In this context, the “Apollo 11 + 50” mission goal becomes one of highlighting a variety of contributions to the national space-flight and STEM innovation experiences. Armstrong himself said, “400,000 people went to the moon,” as both a description of the magnitude of the effort and a concerted attempt to highlight how Apollo is not just one or two people.

We create a celebration that speaks to the history, and also importantly to the future, of human aerospace exploration. It’s glorious to have Armstrong as a Purdue alumnus, as well as Gene Cernan, who saw the surface of the moon in Apollo 10 before being the last astronaut to leave footprints with Apollo 17. These are only two of two dozen astronauts to note, not to mention our legacy of contractors, engineers, technicians, mission controllers and flight directors (several of whom will be part of the events we need to manage). The next time we go to the moon, and the first mission to Mars, will build on the critical science work done in our departments and schools.

Managing the team, to me, means enabling these requirements and goals – not for my benefit, but for the thousands who have contributed, the thousands who visit and the thou-sands who aren’t even here yet but will be inspired in the future.

“Change Control” (Section 4.2.1.4.1). As a systems engineer, I have a complex and bimodal response to uncertainty and change. On the one hand, I enjoy teaching elements of probability and statistics to help students and professionals understand distributions, local and deep uncertainty of estimates, and even the boundaries of “appropriate precision” based on appreciation of our limits of understanding.

However, I hate not knowing. Many of our challenges for managing projects force us to confront that we don’t know, and we don’t know when (or if) we will know. How about an aircraft flyover? Can we get engineering alumni who worked on Apollo 11? What happens if we change the schedule of the archives’ open house?

These are all issues of change control – not change for the sake of change, but because constraints prevent the original idea from being executed, or because a new opportunity presents itself unexpectedly. Innovation and systems robustness must embrace that conditions and environments and relation-ships change. As the time gets shorter, the difficulty of managing change increases. Things that can be managed at T minus 150 days get much harder to accommodate at 50 days, or 15 days. Knowing what can be changed, and how, is a skill of managing uncertainty.

Eventually, every practicing engineer must learn how to manage uncertainty and recognize how to proactively prepare for uncertain events in order to more effectively utilize re-sources in advance of and in reactive response to both reason-able and unexpected unknowns. At the center of this balance for me is a simple rule to explain to people (but not at all simple to live): Provide better information sooner. Don’t wait for perfect, don’t wait until it’s convenient and certainly don’t hide it, hoping the problem goes away.

“Measurement of Effectiveness” (Section 4.2.1.5). Not surprisingly, the primary measure of effectiveness is accomplishment. That is the focus right now. The date is fixed, and our performance is tied to that date. What are we planning, and how do we manage to enable those outcomes?

Since weather is a constraint, there are additional go/no-go decisions to be made that morning, in order to maximize health and safety of visitors during the day. There are additional effectiveness measures for the event as well, but these are more difficult to quantify: satisfaction, education and inspiration. Sometimes the most important measures of effectiveness aren’t immediately evident, but the lessons of the project itself will influence others in ways that we can only imagine – like the Apollo program itself.

“System Engineering Support” (Section 1.5.3). “A continuing effort is placed upon product improvement and configuration management to ensure that the reliability requirement of mission support are exceeded” (Pages 1-27).

A final word, and a note of thanks. While we talk about system engineering support in various configurations, there is a hidden debt we owe. In order to recognize and improve performance, we need to document our past work, including our failures and painful les-sons. In essence, the critical skill of mission support is to turn operational experience into available and usable reference material.

The success of Apollo did not start with Apollo. The critical subsystems and capabilities for Apollo 11, with the exception of actually landing on the surface of the moon, were developed and tested during the Mercury and Gemini programs. Long before I knew that I would get to lead the Apollo 11 50th anniversary celebration, I made the acquaintance of engineers who were deeply involved in the development of the Mercury and Gemini spacecraft (see Figure 5), and worked side by side with the astronauts (including Grissom, Armstrong and Cernan) during those critical development missions. They began before there was a NASA, and before we knew how to fulfill the promise realized on July 20, 1969.

I stand in continued awe of their work, and in appreciation that I have been able to learn just a bit more about their experience, difficulties and insights. They may not have recognized the historic impact of their operational experience until later, and they certainly have not met nor received the thanks from all those who have been impacted and inspired by their work.

But I am grateful that their work allows me to describe to others the capabilities and diversity and scope of systems engineering, and how it taught a young boy to make connections and dream of exploration.