Content uploaded by Hadi Ali
Author content
All content in this area was uploaded by Hadi Ali on Aug 03, 2020
Content may be subject to copyright.
AC 2011-1064: TOWARDS MORE EFFECTIVE TEACHING STRATEGIES
OF ITERATION AND SYSTEMS MANAGEMENT IN SPACECRAFT DE-
SIGN
Hadi Ali, Purdue University
Hadi Ali is a Ph.D. student in the School of Engineering Education at Purdue University. He holds a B.S.
in Aeronautics and Astronautics from Purdue University and a B.Sc. in Mechanical Engineering from
the University of Jordan. He earned his Masters degree in Aeronautics and Astronautics from Purdue
University majoring in aerospace systems design. He is also pursuing a Masters degree in Electrical and
Computer Engineering at Purdue. Hadi is a student member of AIAA, IEEE, ASME, and SAE.
Robin Adams, Purdue University, West Lafayette
Robin S. Adams is an Assistant Professor in the School of Engineering Education at Purdue University.
She led the Institute for Scholarship on Engineering Education (ISEE) as part of the Center for the Ad-
vancement of Engineering Education (CAEE). Dr. Adams received her PhD in Education, Leadership
and Policy Studies from the University of Washington, an MS in Materials Science and Engineering from
the University of Washington, and a BS in Mechanical Engineering from California Polytechnic State
University, San Luis Obispo. Dr. Adams’ research is concentrated in four interconnecting areas: cross-
disciplinary thinking, acting, and being; design cognition and learning; views on the nature of engineering
knowledge; and theories of change in linking engineering education research and practice.
c
American Society for Engineering Education, 2011
Page 22.1537.1
Towards More Effective Teaching Strategies of Iteration and
Systems Management in Spacecraft Design
ABSTRACT
We propose effective teaching strategies to help teams of students in spacecraft
design projects in the first or second semester in the sophomore year in the
aerospace engineering curriculum move from being “beginning designers” to
being “informed designers.” The focus here is on one dimension in the Matrix of
Informed Design that is suggested by Crismond and Adams (in review), namely,
Haphazard or Linear versus Managed and Iterative Designing. The objective is to
instill in students systems management skills and greater appreciation for iteration
in design by providing a unique context. This will be provided through the use of
the development story of the Apollo Lunar Module as a historical case study in
which students can observe design iterations in the larger system in which the
spacecraft existed, with particular emphasis on cost and schedule. In this paper
we describe the teaching strategy and the elements of the historical case as a
unique way to contextualize design learning by understanding the kinds of
iteration that occur and why they occur; implementing and assessing the strategy
will be a focus of future work.
1. Introduction and Motivation
Spacecraft design is highly iterative. Like many complex systems, problems faced during the
design of a spacecraft often have more than one solution. The fact that an operable space system
capable of meeting mission requirements within imposed constraints including (but not restricted
to) mass, cost, and schedule makes spacecraft design a highly iterative process of exploring
optimal solutions that have conflicting requirements. Therefore, systems thinking and iterative
design practice are important aspects in the development of space vehicles and space systems
that involve a variety of technologies and subsystems.
Opportunities to understand the iterative aspects of spacecraft design are limited. Methods to
develop students’ awareness of iteration beyond introducing iteration in different design models
are lacking in engineering education in general, and in aerospace engineering education in
particular. One of the challenges being faced by faculty in the field of aeronautics and
astronautics is teaching space systems design and engineering in an effective way. Unlike
traditional engineering fields, including the closely related field of aeronautics, teaching space
systems design and engineering is difficult because of the lack of opportunities to go through an
entire cycle from system conception to system operation in one or two design courses. Iterative
design tasks that are introduced in sophomore design courses in the aerospace engineering
curriculum cannot be iterative in the grand scale in which students must consider the real impact
Page 22.1537.2
of technical design iterations on cost and schedule iterations. This is further complicated by the
fact that students have limited, if any, exposure to systems thinking and systems design at the
sophomore year level because of the lack of interaction with different disciplines outside
aerospace engineering. Efforts have been made to restructure an entire engineering curriculum
to foster systems building skills, like the Conceive-Design-Implement-Operate (CDIO)
initiative2. Much of the research in space systems design conducted in academia emphasizes
computational modeling with a focus on predicting system capability and behavior3,4. Recent
initiatives like CubeSat5, suggest cost-effective, standard satellite modules to deliver educational
experience of building spacecraft to university students. Yet another example that fosters
systems thinking is the utilization of design competitions similar to those administered by the
American Institute of Aeronautics and Astronautics (AIAA).
Learning about iteration is a key part of becoming an informed designer. The pedagogical
objective of the teaching strategy presented in this paper is to move students from being
“beginning designers” to being “informed designers.” We suggest a teaching strategy that can be
used in a team setting. This paper draws on the framework of Crismond and Adams (in review)
to create a scaffolded design learning experience that helps student move from “Haphazard or
Linear Designing” to “Managed and Iterative Designing.” In particular, we present a case on the
iterative aspects of spacecraft design as an effective teaching strategy for learning about iteration.
This case is based on the Apollo Lunar Module (LM) as an interesting example of building a
manned space vehicle that had no similar precedent. The case illustrates the highly iterative
process of designing spacecraft by looking at possible relationships between the profile of
vehicle configuration changes, and consequently, impacts on cost and schedule predictions.
2. Background
In Crismond and Adams (in review), a great effort has been made to integrate the vast
literature on design, and create a Matrix of Informed Design tool that a design ‘educator’ can use
to monitor progress in design learning during design experiences. The “starting point” and the
“end point” of the journey of design learning are defined in such a way that neither
underestimates nor overestimates the expectations about the students. The starting and end points
of the Matrix “focus on the rank beginner and the advanced novice or “informed” designer, the
latter who demonstrate capabilities articulated in research on design cognition and learning and
described in engineering education and STEM education standards.”1
The Matrix contains a “set of nine observable engineering design strategies and habits” (Fig.
1) that may be assessed and compared between a “beginning designer” and an “informed
designer.”1 While the paper talks about “expert” designers requiring at least ten years to reach
the level of mastery of their fields by consistent effort in organizing knowledge, “informed
designers” are different from expert designers. Bransford, et. al., describe expert designers as
showing salient patterns, and have much situation-specific knowledge and easily remembered
cases6. In contrast, a focus on informed designers is a focus on a realistic target for
undergraduate education. Crismond and Adams (in review) characterize informed designers as
being able to “retrieve their knowledge less flexibly, and encounter more instances of
disconnected knowledge and isolated facts, in part because they hold in mind few experiential
cases and have yet to achieve what could be considered extensive practice.”1 Beginning
Page 22.1537.3
designers show less effective design approaches when contrasted with the more effective
strategies of informed designers. Informed designers have formal training or experience, but they
cannot teach what they know to beginning designers.
For the purpose of this paper, we focus on one dimension, Pattern H, Haphazard or Linear
versus Managed and Iterative Designing. As shown in Fig. 1, Pattern H emphasizes the iterative
aspects of design and design learning. In particular, the Informed Design Matrix characterizes
informed designers in Pattern H as being able to do design as an iterative process, improving
ideas and prototypes based on feedback, and use strategies in any order, as needed, in a
managed and systematic way1.
Fig. 1. The Matrix of Informed Design links nine Patterns of Design Behaviors (Column 1) to
descriptions of how Beginning Designers (Column 2) versus Informed Designers (Column 3) do those
strategies1.
Page 22.1537.4
Different suggested teaching strategies for each pattern in the Matrix of Informed Design are
also discussed as examples of ways to move design students from being beginning designers to
being informed designers1. For Pattern H, these include:
1. Design storyboards: Students are asked to document how challenges have been overcome
over time through sketches or digital snapshots accompanied by short verbal descriptions.
2. Project and time management: Students develop a timeline with special milestones where
feedback and peer evaluations on prototypes or presentations are provided.
3. Instruction and scaffolding for systematic design: Students can be asked to simply read a
book on design process as well as the instructor making them aware of the iterations that
took place during their design process. Reviewing case studies of strategic design
thinking “can help students realize the power and utility of iterative design.”1 Reflection
in various contexts can be very helpful as well32.
4. Risk-taking and iteration: Offering students with lessons about learning from failures,
approaching and accepting them, can be very effective in allowing students to appreciate
iteration and take more risks while designing.
“Instruction and scaffolding for systematic design” was selected as an appropriate teaching
strategy to illustrate the role of iteration in spacecraft design with respect to cost and scheduling
issues. In particular, we claim that the case of the Apollo Lunar Module has the capacity to
provide rich opportunities to effectively teach students the role of iteration in design, the ways
spacecraft design is iterative, and to develop an awareness of iteration as a characteristic of
informed design. The rationale for this decision is based on the idea of contextualization as a
proven concept in teaching and learning50 because it provides situated examples for students to
connect with their own frames of reference. Contextualization allows the introduction of
environments beyond the students’ reach and helps them make relationships with such
environments in a more sensible and appealing way. In a recent paper to the American Society
for Engineering Education on the CDIO initiative in aerospace engineering, contextualization is
found to be a compelling learning approach that goes beyond the regular educational
environments:
“The evidence for adopting a contextual learning approach is compelling. This
approach encourages students to choose specific careers and remain in their
respective career preparation programs. Learning environments and experiences
set in professional contexts open students’ minds, enabling them to become more
thoughtful, participative members of society and the workforce. Moreover, a
contextual learning approach assists students in learning how to monitor their own
learning so that they can become self-regulated learners.”52
As a point of clarification, our proposed strategy is not project based, because of the belief
that real impact of design iterations on cost and schedule iteration are very hard to capture in any
educational setting, given the realization of the real complexity of space projects in the scale of
the Apollo or the Space Shuttle programs.
3. Creating the Teaching Tool
Page 22.1537.5
In this section we describe the process of creating a teaching tool to introduce and emphasize
the concepts of design iteration and systems management to students involved in spacecraft
design projects. The teaching strategy draws on the case of the Apollo Lunar Module and the
method of narrative research design51 to provide students with a scaffolded and contextualized
learning experience. The uniqueness of the Apollo LM makes the decision to study its
development very attractive for the purpose of exploring themes in designing spacecraft that
have no precedence. Reading a book, like Tom Kelly’s book, Moon Lander: How We Developed
the Apollo Lunar Module33, provides an opportunity for students to act as narrative researchers51.
The narrative in Kelly’s book illustrates how iteration in design occurred while designing the LM
and how it affected and was affected by the budget available from Congress at that time of the
Apollo program, and the pressure of national schedule commitments (i.e., landing a man on the
Moon and returning him safely back to Earth before the end of the decade). A unique value of
this book is that it tells a story that cannot be inferred from technical reports because such reports
usually do not give details of the changes of configuration of the vehicle that took
place34,35,36,37,38.
The goal of this teaching tool is to facilitate students’ development as informed designers by
helping them understand (1) how spacecraft design is highly iterative, (2) the kinds of technical
iterations that have an impact on the larger design project through cost and schedule iterations,
and (3) reasons why a systems perspective is necessary for spacecraft design.
The narrative research design procedure is summarized as follows:
1. Identify the phenomenon to explore.
2. Purposefully select an individual from whom the phenomena can be learned more
about.
3. Collect the story from that individual.
4. Organize the story elements into the problem solution narrative structure.
In the following sections we provide details for each step.
Step 1. Identify the phenomenon to explore.
In this study the phenomenon is design iterations during the development of the Apollo LM.
Iteration plays a central role in design
Design iteration is an essential phenomenon in designing complex systems like spacecraft
and space systems. Modeling the design process has been extensively studied, particularly in
terms of modeling relationships among design activities7,8. Iteration is present in many design
process models, and has also been studied9,10. For example, Safoutin discussed how
manipulating iteration could improve design11. Iteration has been described as a “fundamental
feature of design activity that signifies a goal-directed process of revisiting aspects of a design
task in which the goal is a solution that is internally consistent with an understanding of the
problem. Iterations mark awareness that neither the problem nor the goals are well-defined, and
are the result of attempts to reconcile ambiguities and contradictions. In cognitive models of
design, aspects of this process are described as problem and solution co-evolution.”12
Page 22.1537.6
Browning defines an iterative design process as “one where multiple passes are required for
the design to converge to suit an array of sometimes conflicting specifications.”13 Another
definition of iteration is provided by Eppinger as “the repetition of activities to improve an
evolving design.”14 The repetition or rework generates a new, modified design (output) as a
result of some new information, activities, and/or failure to meet design objectives (more
generally, new input)9. The new “input” can be in the form of13:
(1) Upstream (previously worked) activities changing their outputs
(2) Concurrent, coupled activities changing shared assumptions
(3) Downstream activities feeding back changes as errors and
incompatibilities are discovered.
Iterations can be intentional (planned) to create useful information required in the design
process, or they can be unintentional (unplanned) “resulting from new information arriving at the
wrong time in the process.”13
Spacecraft design is highly iterative
Improving the spacecraft design process requires understanding that process. This leads to
the question of what do we know about the spacecraft design process? The design process, in
general, can be viewed “as a set of complex activities with discernable interrelationships.”13 In
the case of the spacecraft, the designer has to deal with different scientific requirements and
engineering disciplines that must be considered concurrently and as a part of the integrated
design process and optimization. The complexity of activities and interrelationships amongst
them required the emergence of the field of space systems engineering. This is necessary to
integrate the design process and its accompanying tradeoffs between subsystems such as
propulsion, power sources, guidance and control, and communications.
One of the definitions of space systems engineering is given as15:
“The art and science of developing an operable system capable of meeting mission
requirements within imposed constraints including (but not restricted to) mass, cost, and
schedule.”
As subsystems become more sophisticated, as it is the case in spacecraft design that has
multiple sets of conflicting requirements, requirements and capabilities become difficult to align.
As a result, tradeoffs and compromises along the path of project completion will be required15,16.
Familiarity and literacy in a broad set of disciplines become necessary in such design processes
as multiple iterations of design decisions will be required to achieve an optimal solution.
Spacecraft design involves particularly broad challenges because iterations occur in two
major levels. First, iterations occur in the mission analysis level when the top-level parameters
are being examined. This includes parameters of launch options, transfer trajectories and overall
mass budget (propellant, platform, and payload), without regard to details of the subsystems16.
The details of the payload itself and the accompanying subsystems represent another, second,
level of iterations which is often being simply assumed at the early stages or drawn upon
Page 22.1537.7
similarities with previous missions. The decisions being made during tradeoffs and complexities
at this level require a wide range of analysis in disciplines such as communications, power,
thermal control, propulsion and so on. Mass growth is a typical feature in spacecraft
development projects (mass growth refers to the situation that happens to the spacecraft as its
mass increases during the development process due to additions or reconfigurations). It is the
task of the systems engineer to resolve technical tradeoffs as the project progresses.
What makes spacecraft design complex and highly iterative is the interaction between these
two levels of iterations in addition to the fact that iterations are not purely technical; there are
social factors that take place in all these iterations. The products of the aerospace industry
represent a pinnacle of research and development enterprise17 but they are paradoxical: in one
sense they are innovative, but in the other sense, with thousands of engineers working on the
solution of several problems, bureaucracy plays an important role. How can innovation and
bureaucracy coexist? This is related to the social aspect of designing space vehicles, where the
ultimate success does not only depend on technical solutions, but also on managerial and social
solutions. Max Weber was one of the pioneers to indicate in his theory of social and economic
organization that in modern organizations the structure promotes and sustains bureaucracy18.
In the early developments of spacecraft in the U.S., systems management was a result of
conflicting interests and objectives between the major groups involved in the development
process. The four major groups of people who were involved were the scientists, the engineers,
the managers, and the military officers representing the customer. These groups were,
unconsciously, the promoters of systems management. Systems management can be defined as:
“A set of organizational structures and processes to rapidly produce a novel but dependable
technological artifact within a predictable budget.”17 One can see that all the groups are present
in this definition; the customer seeking rapidability, scientists seekingnovelty, engineers seeking
dependability, and managers seeking predictability of budget (cost and schedule) 17. Systems
management seems to be surviving in today’s aerospace industry because of two major reasons;
first because it emerged unconsciously by the various groups, and second because everyone is
present in its processes17.
Design iterations impact cost and schedule iterations
Iteration has been found to impact the time required to complete a development cycle21,28.
Thus, to accelerate the design development process (1) faster iterations, and (2) fewer iterations
are required9. Faster iterations can be achieved by improved coordination, while fewer iterations
may mean a design with less quality13. In complex systems developments, it is the nature of such
project that they are coupled and iterative11,20,21. Thus, the design of complex systems is not
achievable without multiple passes. Many recent design models have identified the need for
iteration in design, and therefore iteration in design is well documented in literature22,23,24,25,26.
von Hoppel discussed the importance of partitioning tasks in large projects and talked about
different strategies to achieve that19. Recently, the NASA Systems Engineering Handbook
documents iteration as part of the design process27.
AitSahlia, et. al., discussed the extent to which planning concurrent activities in engineering
projects is valuable29. Susman’s book is one of many that discuss the role that different
Page 22.1537.8
management tools play in improving the integration of design and manufacturing20. Blanchard
and Fabrycky is another example of the discussion on management tools as particularly applied
in the context of systems engineering22. Several types of design tools have been developed to
assess design24,25,26,27,30.
Yet, the relationship between iteration in spacecraft design and its impact on a project cost
and schedule is not fully understood in the spacecraft development process. Understanding the
relationship between technical design iterations and cost and schedule iterations may enhance the
ability of project managers to accurately predict budgets, which is crucial for high risk, high cost
projects like space projects.
Why is iteration not thoroughly addressed early in the design process as a factor affecting
cost and schedule? Browning tried to answer this question in his work on aircraft design. While
there are similarities between the aircraft and spacecraft projects, mainly because both are high-
risk, high-cost projects, spacecraft are unique because they are not produced in volume, which
makes their developmental cycles inherently different. Here is a list that summarizes answers to
the question of why iteration in the aircraft industry is not thoroughly addressed13:
Table 1. Summary of answers to why iteration in the aircraft industry is not thoroughly addressed13.
Why iteration in the aircraft industry is not thoroughly addressed?
Reason Interpretation
Unperceived iteration In the design process, awareness of
iteration is not achieved by
everybody in a company.
Atypical circumstances
Most iterations are unintentional, so
most participants in the project
including the mangers consider such
iterations as unique cases, and
therefore they are not thoroughly
addressed.
Process iteration is schedule driven
This means that only a prior judgment
is used to accommodate iteration with
no further understanding of the
phenomenon.
Iterations are made unlikely to happen through “conservative” but not “robust” design.
Iteration is considered a more detailed issue to consider in the early planning phases.
Iteration is well appreciated and acknowledged in the early design cycles, but iteration is
actually more frequent and has more serious impacts in the later stages of the design process,
especially when testing occurs.
Iterative aspects of spacecraft design are not often emphasized or used to help students learn
Page 22.1537.9
Teaching spacecraft design as a linear process, moving from one step to the other in one
direction, can limit students’ understanding of important iterations in design and encourage
design misconceptions. This is complicated by the fact that students do not typically have a
chance to build and test spacecraft designs. Testing is known to be an important step in moving
from one stage to the other in the progress of the project. In fact, iteration has been defined as
“cycles of proposal, testing, and modification of an evolving design.”31
Step 2. Purposefully select an individual from whom the phenomena can be learned more
about.
The individual selected is Thomas Kelly, the father of the Lunar Module. The case of the Apollo
LM provides opportunities to effectively teach students the role of iteration in design, the ways
spacecraft design is iterative, and to develop an awareness of iteration as a characteristic of
informed designer. Fig. 2 below illustrates the development of the LM configuration from
beginning to end.
Fig. 2. Composed image showing the overall configuration development of the Apollo LM49. The image
on the top right corner shows the schematic that the LM engineers used to use to describe their concept
simplistically: a descent stage and an ascent stage.
Step 3. Collect the story from that individual.
We propose the book Moon Lander: How We Developed the Apollo Lunar Module by Tom
Kelly, the father of the LM33, as a useful resource for cataloguing and understanding design
iterations for the Apollo LM. In this book, Kelly records and presents a personal, professional
experience during the period of his involvement in the development of the LM with Grumman.
The story has the following unique characteristics:
Page 22.1537.10
It is an individual experience
It provide the chronology of experiences as experienced by the individual
It has some side descriptions of experiences by other individuals
It has the form of restoring of the LM development in specific, and the Apollo
program in general
It includes detailed descriptions of contexts and settings
There was no collaboration with others in writing
The Apollo engineers where not necessarily designing experts in developing
spacecraft as this was something new to everyone. Their attributes match somehow
the attributes of informed designers as discussed before.
All these characteristics make Kelly’s story suitable for developing a case study since it
provides sufficient detail to illustrate design iterations. Kelly has also published papers on the
features of the LM34,35,36,37,38 for the American Institute of Aeronautics and Astronautics (AIAA)
that are more technical in nature. Kelly also wrote a masters thesis on a closely related topic
after his involvement with the Apollo program entitled The Dynamics of R&D Project
Management39. Personal stories from people involved in space explorations at different
positions also exist. A summary of some of the existing literature in this area is provided in Table
2.
Table 2. Summary of similar narration stories from individuals who were involved in the space program.
Reference and Title Occupation of
Main Character Narrated by
Hansen (2006) First Man: The Life of Neil A.
Armstrong40 Astronaut Narrator
Collins (2009) Carrying the Fire: An Astronaut's
Journeys41 Astronaut Himself
Cernan and Davis (2000) The Last Man on the Moon:
Astronaut Eugene Cernan and America's Race in
Space42
Astronaut Himself with a
narrator
Kluger and Lovell (2006) Apollo 1343 Astronaut Himself with a
narrator
Kranz (2009) Failure Is Not an Option: Mission Control
From Mercury to Apollo 13 and Beyond44 Mission Control Himself
Kraft (2002) Flight My Life in Mission Control45 Mission Control Himself
Slayton (1995) Deke!: An Autobiography46 Mission Control Himself
Shirley (1999) Managing Martians47 Manager Herself
Bizony (2006) The Man Who Ran the Moon: James E.
Webb, NASA, and the Secret History of Project
Apollo48
Manager Narrator
Step 4. Organize the story elements into the problem solution narrative structure.
For this step, the framework by Adams for coding iterative activity is used12. The framework
is based “on a cognitive model describing underlying mechanisms of iteration as well as schemes
Page 22.1537.11
for classifying iterative cycles and processes.”12 To operationalize iteration in this framework,
iteration is understood as a goal-directed cognitive process. To identify and document iterations
in Kelly’s story, two features for each iteration in the story were coded as follows, see Fig. 3.:
- First feature: That which triggered the iteration (by an information processing or
activity)
- Second feature: A change to a design state (process, problem, or solution
element).
Fig. 3. The cognitive model of iteration in design that will be used in coding Kelly’s story12 .
We have selected Chapter 9, Problems, Problems! from Kelly’s book to illustrate the coding
process in Step 4. This chapter is very useful because it outlines a set of iterations that had
implications across cost and scheduling, including the sequencing of manned missions that
eventually led to the manned LM landing before the end of the decade. Several of the
interactions between iterations in the LM design and the larger system of the entire Apollo
program are also discussed in this chapter.
Step 4 is illustrated below, Table 3, for problems regarding one subsystem of the LM as
narrated by Kelly, namely, Propulsion and Reaction Control System Leaks.
An example of the coding in Step 4 is described for the first row in Table 3: “Leaks occurred
on both the pressurant (helium gas) and the propellant fuel and oxidizer sides of the system,”33
(first column). This prompted a series of activities to address this technical issue: “we proposed
using welded or brazed joints to eliminate mechanical connections in fluid systems,” 33 (second
column). As such, this sequence of activities was coded as a Solution kind of iteration, as the
change in the design state resulted in change to a solution.
Another example is the second row in Table 3: “None of our mechanical joint designs were
leak-tight and even the brazed joints leaked,” 33 which resulted in the change in the design state:
“We stopped the leaks on the heavyweight rigs at Bethpage by replacing gaskets and O-rings and
tightening bolts and threaded fasteners to their allowable torque limits.” 33 We coded this as a
Solution kind of iteration. One may notice that the kind of change (process, problem, or
solution), can be more than one kind at the same time, as there is a co-evolution of problems and
solutions being observed.
Table 3. Coding of iteration as narrated in Chapter 9 in Kelly’s book33 for Propulsion and Reaction
Control System Leaks.
Page 22.1537.12
What triggered an iteration? Changes to a Design State Kind of Change
(Process, Problem,
Solution)
“Leaks occurred on both the pressurant
(helium gas) and the propellant fuel and
oxidizer sides of the system. Although no
leaks were tolerable anywhere in the systems,
propellant leaks were extremely serious
because the propellants were highly toxic
volatile liquids, and being hypergolic, their
fumes would ignite if combined.” (p. 127)
“Without working out the details at that time,
we proposed using welded or brazed joints to
eliminate mechanical connections in fluid
systems and mechanical energy absorbers in
the landing gear to eliminate the potential
leakage of hydraulic shock absorbers. We
chose stainless steel tubing joined by high
temperature nickel-silver brazing for the
propulsion and RCS systems to minimize the
number of mechanical joints.” (p. 127)
Solution
“None of our mechanical joint designs were
leak-tight and even the brazed joints leaked,
unless they were perfect, with full, even flow
of the brazing material over the contact area of
the joint.” (p. 127)
“For a while we blamed the sniffers (too
sensitive!), but we found that many of the
suspect joints would also show leaks in the
common, low-tech bubble test with detergent
solution. We stopped the leaks on the
heavyweight rigs at Bethpage by replacing
gaskets and O-rings and tightening bolts and
threaded fasteners to their allowable torque
limits.” (p. `128)
Solution
“[Lynn] made a special trip to Bethpage to
demand that Propulsion and RCS be made
leak-tight, no matter what it took.” (p. 128)
“Two additional sets of rigs, heavyweight HA-
3 and HD-3 and lightweight PA-1 and PD-1,
had been delivered from Bethpage to White
Sands, and although they had improved
mechanical joint designs, they still leaked.” (p.
128)
Problem/Solution,
“Radcliffe started with Joe Gavin and Bob
Mullaney and worked his way down through
the LM management hierarchy, preaching
against the evil of leaks and the need to reform
our designs without delay. When he reached
me I was shocked by what I heard. I had not
realized that the rigs were still leaking badly
despite the improved seal designs we had
provided.” (p. 129)
“Carbee and his fluid systems design group
leaders joined the meeting at my request, and
after Radcliffe repeated his message of
warning we discussed what to do next.
Radcliffe's opinion was unequivocal:
"Eliminate all mechanical joints, and learn
how to make brazed joints that don't leak." We
agreed to work toward this goal.” (p. 129)
Process
Page 22.1537.13
“In the ensuing week we eliminated the AN
(army-navy standard), Gamah, and other
fittings … we brazed these components
directly into the system with high-temperature
nickel silver brazing alloy … For replacement,
the Manufacturing Engineering group worked
out a technique of cutting out the component
...” (p. 129)
“This made maintenance of these fluid systems
more difficult and time-consuming, but if we
made the brazes properly, they did not leak. It
was necessary to X-ray every brazed joint ...
Portable X-ray equipment was used to inspect
the joints in place on the shop floor, but no one
could work in the immediate area while X-ray
was in progress. There were still some areas
where we retained mechanical connections ...
Large opening in the tanks were necessary for
cleaning, inspection, and installation of
quantity gauging sensors ... Even Radcliffe
found the improved system design acceptable,
except that he occasionally had to reheat
brazed joints or tighten bolted flanges that had
developed leaks.” (p. 129-130)
Process/Solution
“Leaks continued as an occasional nuisance
item in cold flow and at White Sands until the
LM-1 fiasco in June 1967. LM-1 was
delivered in the midst of shakedown problems
with the spacecraft assembly and test operation
in Pant 5, Bethpage. When we delivered LM-
1, Grumman and the local NASA inspectors
thought we had a leak-tight spacecraft ... Soon
after it was received at KSC, LM-1 was found
to have wide-spread leakage in the propulsion
and RCS systems. The people at Cape
Kennedy quickly characterized Grumman's
first-worthy spacecraft that we had proudly, if
tardily, shipped as a "piece of junk that leaked
like a sieve." ... We initially thought the cape's
findings were due to differences in leak
detection procedures and equipment.” (p. 130)
“To test this hypothesis a QC crew from Cape
Kennedy came to Bethpage and performed
leak tests on systems in LM-2 and LM-3 that
had been found leak-tight at Bethpage.” (p.
130-131)
Process/Problem
“Discouragingly, they found some leaks that
had escaped detection by the home team.
Moreover, the leaks were real-on both LM-1 at
the cape and LM-2 and LM-3 some of the
leaks detected by the sniffers could also be
seen in the bubble test.” (p. 131)
“Although I was unsure why this happened, I
declared that we would adopt the cape leak test
regimen and have experienced cape inspectors
train our people in its use …” (p. 131)
Process/Problem
“Embarrassed and responding to pressure from
NASA, Joe Gavin became directly involved in
the leak problem.” (p. 131)
“At my recommendation he put Will Bischoff,
deputy Structural Design Section head, in
charge of an intensive leak fix effort.” (p. 131)
Process/Problem
Page 22.1537.14
“The bolted flanges on the tanks were the
worst problem, followed by the few other
smaller mechanical component connections
that had survived my earlier purge.” (p. 131)
“Bishop consulted with the tank manufacturer
… and with the O-ring and sealing experts
around the country, and developed a new
design for the tank flanges. It had dual O-
rings, revised groove dimensions and
tolerances, and a test port between the two O-
rings to detect leakages. Test samples
performed very well ... we replaced the tank
flanges in LM-1 with an interim improved
design ... Bishop's team also developed an
improved dual O-ring flange design for pipe-
mounted components ... the bishop team went
over our brazing process thoroughly ... With
time, the percentage of first-time acceptable
and leak-tight brazes increased and the number
of reheats went down.” (p. 131)
Solution
“LM-1 was finally made leak-tight at the cape
after three months of intensive effort, aided by
six of Radcliffe's best "leak fixers" on loan
from White Sands. The damage to Grumman's
reputation was severe. The next spacecraft we
delivered, LM-3, was pounced upon savagely
when it arrived in June 1968 and immediately
checked for leaks.” (p. 131)
“This time we had invited the Cape Kennedy
receiving inspection team up to Bethpage to
join our people in the predelivery inspection
and tests, so the cape people agreed that LM-3
was leak-tight when shipped.” (p. 131-132)
Process
“Propulsion and RCS leakage remained a
concern throughout the duration of the LM
program.” (p. 132)
“Constant vigilance and retraining were
required to attain leak-tight systems-any minor
slip would soon be shown by a squealing
sniffer in S/CAT or at Cape Kennedy. The
frequency of leaks was greatly reduced from
the mortifying debacle of LM-1 or the constant
problems that had bedeviled Radcliffe at
White Sands, but the occasional leakage that
did occur reminded us constantly of the
difficult and unforgiving nature of pressurized
fluid systems in space. If it leaked in space or
on the Moon there would be no way to stop it
or replenish the precious lost propellant.” (p.
132)
Process
The following three examples from the coding above illustrate how the technical design
iterations had impact on cost and schedule iterations during the Apollo LM design process:
“Two additional sets of rigs, heavyweight HA-3 and HD-3 and lightweight
PA-1 and PD-1, had been delivered from Bethpage to White Sands.”33
Page 22.1537.15
“This made maintenance of these fluid systems more difficult and time-
consuming.” 33
“With time, the percentage of first-time acceptable and leak-tight brazes
increased and the number of reheats went down.” 33
The first sentence shows implicitly how adding new test rigs required additional costs, and
the second and third sentences are examples of how modifications had a scheduling impact.
While they are not as rich as they may seem, Chapter 9 provides other examples from other
subsystems of the LM, the accumulation of iterations in which caused delays in the manned
space program.
Step 5. Reflect on the findings to identify and understand patterns of iteration.
This step should be conducted in a team setting in which team members discuss among
themselves the key issues. They might focus on how the different teams of people interacted, and
how that in itself is an interesting take away from the complex systems perspective. Crawley, et.
al, describe one of the reasons why setting aerospace engineering education in the context of
aerospace product development is important as “it aids in teaching the skills that [students] will
need in the workplace.” 52 Providing a narrative in the form of a case study gives the teams some
guidance on how to “communicate and work in teams, and especially to act ethically and
creatively.” 52 While this statement was focused on engineering activities, the case study provides
scenarios of “what would you do if you were in that situation?,” and gives opportunities to
explore more realistic, complicated, real-life situations.
Extending the application of the procedure
The teaching strategy presented above has illustrated three major activities: (1) Reading the
narrative, (2) Analyzing the reading, and (3) Discussing the analysis within a design team. The
teaching strategy can be extended by adding the step of (4) Anticipating similar problems that
may occur in other subsystems. As a matter of fact, Chapter 9 of Kelly’s book provides a
discussion on problems encountered and solutions achieved to overcome problems with other
subsystems such as ascent engine instability, stress corrosion, battery problems, and tank
failures. It is expected that students would be faced with one or more of the following themes in
the process51: ordinary themes (e.g., the number of battery rechargers allowed during ground
tests compared to the actual flight of fully charged battery that would be used until depleted),
unexpected themes, hard-to-classify schemes, and major and minor themes.
4. Conclusion and Future Work
Design iteration is an essential phenomenon in designing complex systems like spacecraft
and space systems. In this paper we proposed a teaching strategy based on the case study of the
Apollo Lunar Module to help students appreciate the role of iteration in spacecraft design
projects and develop systems management skills. This is intended to move students in spacecraft
design projects from being beginning designers to informed designers. We did not do the
intervention; therefore, impact on learning is considered to be as a next step in future work.
Page 22.1537.16
Instead, the historical case is proposed as a unique way to contextualize design learning by
understanding the kinds of iteration that occur and why they occur.
This proposal is unique in its approach to teaching about iteration in the spacecraft design
process in two main ways: (1) it focuses on revealing aspects of iteration in the spacecraft design
by exploring case studies from previous spacecraft projects; and (2) it uses a qualitative approach
of narrative research to make evident themes of iteration and important variables. Both of these
aspects are useful for students in spacecraft design courses and informed designers who are
assigned the task of building real space systems with no prior history of similar developments.
A future goal is to develop more examples of applying the teaching strategy procedure,
especially in an effort to provide a framework that relates technical design iterations to cost and
schedule iterations, and to test the impact of this strategy on sophomore student’s design
learning. The teaching tool may also be used to help students predict other technical design
iteration scenarios and the associated impacts on the larger system of the design project.
Predictions may focus on the early stages of the design process or at times when critical
decisions are made during detailed design and the consequences of these decisions. Predicting is
an effort to anticipate “breakpoints” while controlling is an effort to avoid these “breakpoints.”
As such, the proposed teaching strategy may help students to develop skills in predicting
breakpoints in design. This is similar to the role of configuration management and configuration
control as practiced in spacecraft systems management. Configuration management is a process
that makes people involved in changing a design of a spacecraft aware of what this change is
going to affect and what its consequences are. The Jet Propulsion Laboratory over time learned
by experience the typical profile of engineering changes and, consequently, how better to predict
cost and schedule17.
References
1Crismond, D. and Adams, R.S. (in review). “A Scholarship of Integration: The Matrix of Informed Design.”
Submitted to the Journal of Engineering Education.
2Crawley, E.F., “Creating the CDIO Syllabus, A Universal Template for Engineering Education,” Proceedings, 23rd
Frontiers in Education Conference, Institute of Electrical and Electronics Engineers, Vol. 2, pp. f3f/8-f3f/12, 2002.
3Georgia Tech, Space Systems Design Laboratory website:http://www.ssdl.gatech.edu/about.htm [Accessed 9
January 2011]
4Old Dominion University, Advanced Engineering Environments website: http://www.aee.odu.edu/index2.php
[Accessed 9 January 2011]
5Chin, A., Coelho, R., Nugent, R., Munakata, R., Puig-Suari, J. (2008) “The CubeSat: The Picosatellite Standard for
Research and Education” American Institue of Aeronautics and Astronautics, AIAA-2008-7734.
6Bransford, J.D., A.L. Brown, and R.R. Cocking. 1999. How people learn: Brain, mind, experience and school.
Washington, DC: National Academies Press.
Page 22.1537.17
7Andersson, Johan, Jochen Pohl, and Steven D. Eppinger (1998) “A Design Process Modeling Approach
Incorporating Nonlinear Elements” Proceedings of the ASME Tenth International Conference on Design Theory and
Methodology, Atlanta, GA, Step. 13-16.
8Belhe, Upendra and Andrew Kusial (1996) “Modeling Relationships Among Design Activities” Journal of
Mechanical Design 118: 454-460.
9Smith, Robert P. and Steven D. Eppinger (1997) “A Predictive Model of Sequential Iteration in Engineering
Design” Management Science 43(8): 1104-1120.
10Smith, Robert P. and Steven D. Eppinger (1998) “Deciding Between Sequential and Parallel Tasks in Engineering
Design” Concurrent Engineering: Research and Applications, 6(1): 15-25.
11Safoutin, Michael J. and Robert P. Smith (1996) “The Iterative Component of Design” Proceedings of the IEEE
International Engineering Management Conference, Vancouver, Aug. 18-20.
12Adams, R. S. (2002). "Understanding design iteration: Representations from an empirical study," Proceedings of
the International Conference of the Design Research Society, September, London.
13Browning, Tyson Rodgers (1998) Modeling and Analyzing Cost, Schedule, and Performance in Complex System
Product Development, Ph.D. Thesis (Technology, Management, and Policy), Massachusetts Institute of Technology,
Cambridge, MA.
14Eppinger, Steven D., Murthy V. Nukala, and Daniel E. Whitney (1997) “Generalised Models of Design Iteration
Using Signal Flow Graphs” Research in Engineering Design 9: 112-123.
15Griffin, Michael D., French, James R. (2004) Space Vehicle Design. 2nd Edition, Reston, VA: AIAA Education
Series.
16Ball, Andrew J., Garry, James R. C., Lorenz, Ralph D., Kerzhanovich, Viktor K. (2007) Planetary Landers and
Entry Probes, Cambridge University Press.
17Johnson, Stephen B. (2002) The Secret of Apollo: Systems Management in American and European Space
Programs, Baltimore and London: The John Hopkins University Press.
18Weber, Max (1947) The Theory of Social and Economic Organization. New York: Oxford University Press.
19von Happel, Eric (1990) “Task Partitioning: An Innovation Process Variable” Research Policy 19: 407-418.
20Susman, Gerald, I., Ed. (1992) Integrating Design and Manufacturing for Competitive Advantage. New York:
Oxford University Press.
21Whitney, Daniel E. (1990) “Designing the Design Process” Research in Engineering Design: 2: 3-13.
22Blanchard, Benjamin S. and Wolter J. Fabrycky (1990) Systems Engineering and Analysis, Second Edition,
Englewood Cliffs, NJ: Prentice Hall.
23Clausing, Donald (1994) Total Quality Development: A Step-by-Step Guide to World-Class Concurrent
Engineering, New York: ASME Press.
24DoD (1992) Systems Engineering/Configuration Management Life Cycle Application, DoD, Military Handbook,
MIL-HDBK-499-3.
25DoD (1994) MIL-STD-499B Systems Engineering (Draft), DoD, Military Standard Specifications, MIL-STD-
499B.
Page 22.1537.18
26Pugh, Stuart (1991) Total Design: Integrated Methods for Successful Product Engineering, Reading, MA:
Addison-Wesley.
27Shishko, Robert, et al. (1995) NASA Systems Engineering Handbook, NASA.
28Cesiel, Douglas S. (1993) A Structured Approach to Calibration Development for Automotive Diagnostic Systems,
Master’s Thesis (Mgmt./E.E.), Massachusetts Institute of Technology, Cambridge, MA.
29AitSahlia, Farid, Eric Johnson, and Peter Will (1995) “Is Concurrent Engineering Always a Sensible Proposition?”
IEEE Transactions on Engineering Management 42(2): 166-170.
30Chan, Lai-Kow and Wu, Ming-Lu (2002) “Quality function deployment: A literature review,” European Journal
of Operational Research, Volume 143, Issue 3, 16 December 2002, pp 463-497.
31Smith, R.P., and P. Tjandra. (1998) Experimental observation of iteration in engineering design. Research in
Engineering Design 10(2): 107-117.
32Barlex, D., and R. Wright. 1998. Using the internet as an information gathering tool for the design and technology
curriculum. IDATER ’98: 160-8.
33Kelly, Thomas J. (2001) Moon Lander: How We Developed the Apollo Lunar Module, Washington, D. C.:
Smithsonian Institution Press.
34Kelly, Thomas J. (1967) “Apollo Lunar Module mission and development status.” American Institute of
Aeronautics and Astronautics, AIAA-1967-863.
35Kelly, Thomas J. (1968) “Flight Experience with the Apollo Lunar Module” American Institute of Aeronautics and
Astronautics, AIAA-1968-1005.
36Kelly, Thomas J. (1981) “Design features of the project Apollo lunar module LM” American Institute of
Aeronautics and Astronautics, AIAA-1981-910.
37Kelly, Thomas J. (1990) “A review of the Apollo Lunar Module program and its lessons for future space missions”
American Institute of Aeronautics and Astronautics, AIAA-1990-3617.
38Kelly, Thomas J. (1992) “Manned lunar lander design - The Project Apollo Lunar Module (LM)” American
Institute of Aeronautics and Astronautics, AIAA-1992-1480.
39Kelly, Thomas J. (1970) The Dynamics of R&D Project Management, Master of Science Thesis, Massachusetts
Institute of Technology, Cambridge, MA.
40Hansen, James R. (2006) First Man: The Life of Neil A. Armstrong. Simon & Schuster.
41Collins, Michael (2009) Carrying the Fire: An Astronaut's Journeys, Farrar, Straus and Giroux.
42Cernan, Eugene and Davis, Donald A. (2000) The Last Man on the Moon: Astronaut Eugene Cernan and
America's Race in Space, St. Martin's Griffin; First Edition.
43Kluger, Jeffrey and Lovell, James (2006) Apollo 13, Mariner Books.
44Kranz, Gene (2009) Failure Is Not an Option: Mission Control From Mercury to Apollo 13 and Beyond, Simon &
Schuster.
45Kraft, Christopher (2002) Flight My Life in Mission Control, Plume, 1st edition.
46Slayton, Donald K. (1995) Deke!: An Autobiography, Forge Books.
Page 22.1537.19
47Shirley, Donna (1999) Managing Martians, Broadway.
48Bizony, Piers (2006) The Man Who Ran the Moon: James E. Webb, NASA, and the Secret History of Project
Apollo, Basic Books; First Edition.
49Life.com Oddly Beautiful Spacecraft Models website: http://www.life.com/image/88883764/in‐
gallery/30242#index/0 [Accessed 16 January 2011]
50Dym, C.L., Agogino, A.M., Eris, O., Frey, D.D. and Leifer, L.J. (2005). “Engineering design thinking, teaching,
and learning.” Journal of Engineering Education, Jan, pp. 103-120.
51Creswell, J. W. (2008). Educational Research: Planning, Conducting, and Evaluating Quantitative and
Qualitative Research. 3rd. Edition. Prentice Hall: Upper Saddle River, N.J.
52Crawley, E., Niewoehner, R., Koster, J. (2010) “CDIO in Aerospace Engineering: The North America Aerospace
Project Progress Report.” ASEE Conference Proceedings, 2010, AC 2010-987.
Page 22.1537.20
