NASA Readings in SE

_¢q ..
SP-6102 -"
READINGS
IN SYSTEMS ENGINEERING
Edited by Francis T. Hoban
and William M. Lawbaugh
co
(NASA-SP-6102) REAOINGS IN SYSTEMS N93-24678

ENGINEERING (NASa) 215 p --THRU--
N93-24693
Unclas
H1/31 0158570
.J
,j
J
READINGS
IN SYSTEMS ENGINEERING
Edited by Francis T. Hoban

and William M. Lawbaugh
Scientific and Technical Information Program

N_A National Aeronautics and Space Administration
Washington, DC 1993
READINGS IN SYSTEMS ENGINEERING
Introduction by Francis T. Hoban and William M. Lawbaugh
Author Title Page
Robert A. Frosch A Classic Look at Systems Engineering 1 .*J,_._r

_
Defense Systems Management Systems Engineering Overview and Process 9

College
Paul E. Lewkowicz Systems Engineering for 17

Very Large Systems
Marshall Space Flight What is a System ? NASA 's Phased 23

Center SE Handbook Project Description
J
NASA SE Handbook (Draft) Management Issues in Systems Engineering 35
Tony Fragomeni and Spacecraft Systems Engineering: An 79 :_
Mike Ryschkewitsch Introduction to the Process of GSFC
Owen Morris SE&I and Management for Manned 87

Space Programs
Charles W. Mathews The Systems Engineering Role in

Top-Level Requirements 105
John D. Hodge Cost Considerations in the Systems

Engineering Process 115
John E. Naugle Systems Engineering and User Requirements 127 "
Eugene Kranz and SE&I in Manned Missions

Christopher Kraft
J
Robert O. Aller Systems Engineering for Operational 157 !

Support Systems
/
John F. Yardley and Political and Institutional Factors of 163 zl
David Wensley Systems Engineering i
]
Loren A. Lemmerman Optimization in the SE Process 173 _
j_
NASA Investigation Board Initial Flight Anomalies of Skyiab I 181 :
NASA Investigation Board The Seasat Failure 201
George Trimble Defining Systems Engineering

INTRODUCTION
INTRODUCTION
by Francis T. Hoban and William M. Lawbaugh
Systems engineering is not new--it's been This group, in its final report to the
around for quite some time. The ancient NASA administrator on December 30, 1986
engineers who designed and built the pyra- also recommended a renewed effort in the
mids practiced some form of what we today education and training of the NASA pro-
call "systems engineering." Modern systems gram and project management workforce.
engineering emerged during and immediate- Unwritten but well understood in this rec-
ly following World War II as weapons grew ommendation was renewed emphasis on sys-
into weapon systems, due to the degree of tems engineering training. It was no easy
complexity in design, development and de- task to build a knowledge base, create a li-
ployability. The advent of space exploration brary collection and develop courses and
further increased the need for and use of sys- workshops in systems engineering, but the
tems engineering processes and practices. efforts took shape, as one essential part of
The Apollo Program is perhaps NASA's NASA's Program and Project Management
best example of the application of systems Initiative. This became a continuing educa-
engineering. During Apollo, systems engi- tion process assisted on an Agency-wide
neering processes were in place in NASA basis by the Systems Engineering Working
Headquarters and at all field centers. At Group.
some locations the process was formalized; at Today most large engineering organiza-
others it was a back-of-the-envelope applications, including NASA, have a systems engi-
tion, but it was in place. It was widely prac- neering process containing elements both
ticed, and it sustained a young and vibrant common and unique to those practiced by
organization during the design, development other organizations. To document these
and operations of the world's greatest engi- processes NASA is now involved in the prep-
neering feat. NASA systems engineering aration of the first Agency-wide systems
capabilities grew out of its NACA heritage, engineering manual. The manual addresses
bolstered by people from the Department of common systems engineering practices and
Defense, industry and academia who joined tools, as well as those unique to NASA and
the team during the Apollo build-up. It the aerospace industry. This manual, togeth-
should be noted that during the Apollo era, er with those describing the individual Cen-
systems engineering was conducted without ters' practices, will fully document systems
Agency-wide guidance, standards or lexicon. engineering at NASA and add to the educa-
After Apollo, the various NASA centers con- tion process.
tinued to implement systems engineering on This present collection was inspired by
complex projects but perhaps with less vigor seven papers prepared by the NASA Alumni
and enthusiasm than that displayed during League, illustrating the members' systems
Apollo. engineering experience. These papers make
The discipline again became a priority in up the heart of this collection. We have sup-
NASA when the study team of the National plemented them with papers describing
Academy of Public Administration, led by industry processes and other governmental
Lt. General Sam C. Phillips, recommended practices to illustrate the diversity of sys-
the strengthening of systems engineering in tems engineering as it is formulated and
NASA. practiced. This is one discipline that clearly
benefits from cross-fertilization and infusion Systems Engineering Handbook stress the
of new ideas. engineering aspects of successful manage-
There is also a wide variety of tools and ment of aerospace systems.
techniques described herein, some standard In our second section, devoted to specific
and some unique. It is not unlike an elite applications of systems engineering, we be-
crew of talented carpenters showing up for a gin with two engineers from the Goddard
job, each with some different tools in their re- Space Flight Center whose presentations are
spective toolboxes, and each with different famous for explaining the process and pro-
tricks or techniques to save time or money-- ducts of systems engineering in unmanned
to do each one-of-a-kind job better, cheaper, spacecraft. Tony Fragomeni and Mike
faster. Ryschkewitsch are associate chief and chief
If all the authors of Readings in Systems respectively of Goddard's new Systems Engi-
Engineering were ever to assemble in one neering Office. Owen Morris, who was
place, there would be some unanimity on ba- NASA's Lunar module project manager and
sics and essentials but much debate and the Space Shuttle Systems and Engineerng
downright disagreement on the particulars. manager, then discusses the history of sys-
Nevertheless, the meeting would be lively tems engineering and integration (SE&I)
and interestingma decent description of the management in manned space programs.
dynamic process of systems engineering it- Chuck Mathews, past president of the NASA
self. Alumni League, and NASA's manager of the
Gemini Program, director of the the Skylab
APPROACH Program and associate administrator for Ap-
plications, then focuses upon the systems en-
We begin our collection with a now-famous gineering role in establishing, verifying and
speech delivered by Bob Frosch to a group of controlling top-level program requirements.
engineers in New York in 1969, shortly John D. Hodge, a 25-year veteran of the
before his appointment as NASA Adminis- Department of Transportation and NASA,
trator. The speech sets the tone best of all for including the Mercury, Gemini, Apollo and
this volume: Frosch urges a common sense Space Station programs, retiring as an asso-
approach to systems engineering. ciate administrator, explains cost consider-
When weapons evolved into weapons sys- ations in the systems engineering process,
tems, the Department of Defense took the urging clear definition of requirements, sta-
lead in systems, engineering. Today the DoD ble management and strong central control
approach is widely recognized, and so we to allocate funds properly.
present the newly revised (1990) description John E. Naugle, retired NASA associate
of the systems engineering process from the administrator and chief scientist, describes
Defense Systems Management College at the dual role of "master" and "servant" for
Fort Belvoir, Virginia. A senior project engi- the systems engineer, from the requirements
neer formerly with Hughes Aircraft, Paul E. phase to preliminary design. Eugene F.
Lewkowitcz, then discusses requirement Kranz, director of the Johnson Space Center
analysis, technology assessment, solution Mission Operations Directorate, and
synthesis and performance verification for Christopher C. Kraft Jr., former director of
very large systems. Marshall Space Flight the Johnson Space Center, stress manned
Center does it differently, but one of the best mission operations and SE&I. Robert O.
descriptions of Phase A through C can be Aller, recently retired associate administra-
found in Marshall's systems engineering tor for space operations, views operations
handbook. To close out this overview section, support as the infrastructure of people,
excerpts from the forthcoming NASA procedures, facilities and systems for flight
ii
INTRODUCTION
success. John Yardley, NASA's associate scribed the uncritical acceptance of "stan-
administrator for manned space flight dur- dard" or "flight proven" equipment that
ing the Space Shuttle development, asserts failed in 1978. But no one wants to end on a
that the systems engineer should consider 10 negative, so we reproduce a Johnson Space
different politicaland nontechnical groups. Center engineer's attempt to define and ex-
Associate David Wensley suggests ways of plain "systems engineering" a quarter of a
handling politicaland institutional factors century ago.
in the systems engineering process. Loren A. This book is primarily for the next gen-
Lemmerman, formerly of the Lockheed- eration of systems engineers, so we look
Georgia Company, shows how a large air- ahead. As Bob Aller concludes, "The need for
craft company fitsoptimization into systems systems engineering is criticalto NASA in
engineering and the totaldesign process. itspreparations for conducting operations in
Next, we present what today can be look- the late 1990s and into the next decade."
ed at as case studies in lost systems engi- The editors gratefully acknowledge the
neering opportunities. On May 14, 1973, a authors for sharing their information with
minute into flight,Skylab 1 lost its meteor- us. We also wish to thank the NASA Alumni
oid shield and one of two solar array systems. League for its most important contribution.
The NASA Investigation Board determined We thank the NASA Systems Engineering
that aerodynamic loads were probably not Working Group and the entire NASA sys-
accounted for in design. Likewise, the Seasat tems engineering family for their encourage-
Mission Failure Investigation Board de- ment and support.
iii
A CLASSIC LOOK AT SYSTEMS ENGINEERING
by Robert A. Frosch
Editors' Note defined by what is done, not what is said; and

Before his term as NASA Administrator, if what I am describing is bad systems engi-
Bob Frosch was an assistant secretary of neering, I can only say that I seldom see any
the U.S. Navy in charge of research, devel- other kind.
opment, test and evaluation of Navy What I want to do is discuss briefly a
programs. In that capacity, he delivered a series of antitheses (and perhaps an unbal-
controversial and well-remembered speech anced question or two) that pit the systems
to the IEEE Group on Aerospace and world against what I believe are some
Electronic Systems during IEEE's interna- aspects of the real world.
tional convention in New York on March If I plot a graph versus time of what
26, 1969. Edited portions of that famous appears to be a recent rising tide of costs,
speech follow in an effort to preserve what cost overruns, unsatisfactory performance
is now considered a classic formulation of and unhappiness among engineers, I have
systems engineering as an art rather than a reason to worry. (If this trend continues, we
science. may have to debate whether the question
"whither engineering?" is spelled with one
In this presentation, I really will be discus- "h" or two.) IfI plot on the same graph versus
sing the application of systems engineering time the rise in talk, directives, and use of
to development, and in particular to military "systems engineering," "systems analysis"
systems development (with which I am most and "Management," I see high correlation
familiar). However, from reading various between the two graphs--trouble versus
journals and newspapers, I suspect my re- time and the use of systems engineering
marks are of more general applicability. I versus time. This does not prove causation,
have said some of these things before, but but it suggests, at least, that the "new tech-
some bear repeating and some I hope will niques" are proving to be a poor substitute
spark new ideas. for real science and engineering; they are, at
I couple systems engineering, systems the least_, not doing what they are advertised
analysis and Management (with a capital as doing, if they are indeed actually not
"M"), because in practice they seem to be making things worse. It could be that things
closely related terms, referring to the same would be even worse without these new
constellation of systematic practices and techniques, but I would like to ask some
attitudes. questions and suggest some reasons for
believing that systems engineering, systems
• We badly lack: systems engineering of analysis and Management, as practiced, are
systems engineering; systems analysis of likely to be part of the problem, and indeed
systems analysis. causative agents.
• And, heaven knows, there is no: manage- I believe that the fundamental difficulty
ment of Management. is that we have all become so entranced with
• Therefore, I will now preach against technique that we think entirely in terms of
home, motherhood and apple pie. procedures, systems, milestone charts, PERT
diagrams, reliability systems, configuration
To the charge that I am writing about bad management, maintainability groups and
systems engineering, I can only say that I the other minor paper tools of the "systems
am taking a pragmatic view: the thing is engineer" and manager. We have forgotten
that someone must be in control and must and is well on the way to fixing it before any
exercise personal management, knowledge management systems ever indicate that it is
and understanding to create a system. As a about to happen. This happens if for no other
result, we have developments that follow all reason than because the competent manager
of the rules, but fail. is watching what is going on in great detail
I can best describe the spirit of what I and perceives it long before it flows through
have in mind by thinking of a music student the paper system. That is to say, personal
who writes a concerto by consulting a check- contact is faster than form-filling and the
list of the characteristics of the concerto U.S. mails. A project manager who spends
form, being careful to see that all of the can- much time in a Management Information
ons of the form are observed, but having no Center instead of roving through the places
flair for the subject, as opposed to someone where the work is being done is always
who just knows roughly what a concerto is headed for catastrophe. The MIC can assist
like, but has a real feeling for music. The the people who are not involved in the project
results become obvious upon hearing them. toward learning of after-the-fact problems,
The prescription of technique cannot be a but that is roughly all that it can do, and its
substitute for talent and capability, but that value even for this purpose is frequently
is precisely how we have tried to use questionable.
technique. Blaming deficiencies in management
systems for problems that exist in real
PAPER VS. PEOPLE unknowns, or in the deficiencies of people, is
mere foolishness. In a poem called "Bagpipe
My first antithesis pits the systems world of Music," by Louis MacNeice, the final couplet
paper and arrangements against the real is:
world of people and hardware. When paper "The glass is falling hour by hour,
appears in the real-world version of a the glass will fall forever
system, it is generally only as an abstracted But if you break the bloody glass,
commentary. For example, in a very basic you won't hold up the weather."
sense it really is of no consequence whether
the documentation on a weapons system is LINEARITY VS. THE REAL WORLD
good, bad or nonexistent; that is only a

commentary on whether or why the people One of the key misassumptions in modern
and the hardware actually work when called systems engineering and systems analysis is
upon, and a tool to help them work. If the that the total problem can be, and frequently
systems arrangements on paper and the doc- is, decomposed into subproblems; the
umentation can help to make the stuff work, subproblems can be solved more or less
then they are of some use. If they are merely independently, and the total solution can be
the formal satisfaction of a requirement, synthesized by combination of the subsolu-
they are only an interference with engineer- tions, treating the interactions of the parts
ing. Systems, even very large systems, are as "interfaces." The real world is, however,
not developed by the tools of systems engi- highlynon-linear, and unless real attention
neering, but only by the engineers using the is paid to this fact, the linear decomposition
tools. In looking back at my experiences in treatment will fail catastrophically, because
development, including watching a number the interaction terms may be as large as the
of Navy developments over the past few subproblems and not reducible to simple
years, it seems quite clear that in most cases interfaces. The result may well remain
where a system gets into trouble, a compe- decomposed.
tent manager knows all about the problem
This criticism is frequently answered by paper techniques and there are only two in-
the comment that problems are unmanage- stead of N dimensions available. What we
able unless sliced up and, therefore, the pro- end up displaying are linear sequential mea-
cedure is used even though we know it may sures of system progress.
be seriously in error. This is the case of the The PERT diagram and the milestone
man who played in a poker game that he chart are excellent examples. These both
knew to be crooked, because it was the only essentially assume that the progress of
game in town; or the drunk who looked for development and design consists of doing
his ring under the street lamp even though step A, then step B, then step C, etc. Anyone
he had lost it a block away in the dark--the who has ever carried out a development or a
light was better under the street light. I have design (as opposed to setting up a manage-
some difficulty seeing that a bad analysis is ment system for doing so) is well aware of
really better than an informed judgment, the fact that the real world proceeds by a
especially since faith in the analysis (and/or kind of feedback iterative process that looks
the decomposed solution to the problem) is more like a helix than like a line. That is to
frequently, nay, usually, used as a substitute say, you do A, then B, then C, then you look
for seeking or applying any judgment at all. I at C and go back and change part of A again,
am often faced with a result that seems and that causes you to fiddle with B and
absurd, and can even produce a quick analy- perhaps bring in a B-prime that you bounce
sis that at least makes it obvious that the against C, and then go back to A and then
solution is absurd, but am then given the jump to D, so that there has to be continual
answer, "Well, that's what the analysis adjustment, going back and forth so that the
showed." system is adjusted to itself and to its end
Such a situation usually indicates room objectives as it changes and as the design or
for deep criticism, either of the way in which development proceeds. Because it is difficult
the problem was divided up, or of peculiar- to predict this process or to diagram it, or to
ities of the assumptions that drive the predict its costs precisely without using
problem in curious and unsuspected ways, competent engineers, the systems engineer-
particularly through the unsuspected (by the ing procedures simply ignore the iterative,
systems person) nonlinearities of the feedback nature of the real world because the
problem. It sometimes appears that the only process has been degraded to clerical report-
rational subdivision of the problem is to ing. To a large extent, this tends to constrain
fractionize the blame to the point where project managers from doing work in the real
approval is sought by default. way toward doing it in a way that fits with
I would argue that careful attention to their management tools. This is clearly
the parts of the problem that do not seem to nonsense.
be easily decomposable into semi- As a specific example, doctrine says that
independent parts might be one very good one is to consider the "ilities," that is, main-
guide to areas involving high risk, since tainability, reliability, operability, etc., from
these are likely not to be amenable to our the very beginning of the process. This is a
usual rules, procedures and technologies, vast waste of time and effort. I do not mean
and hence probably will have to be that one should not think about these things
approached empirically. at the beginning, but it is certainly ridicu-
lous to have a complete plan for the logistics
SERIAL VS. ITERATIVE MODELS of the maintenance of an object that has not
yet been designed. I have seen overruns in
Systems engineering techniques themselves expenditure and unnecessary effort generat-
contribute to disaster because they are all ed by the fact that the linear sequencing of
READINGS IN SYSTEMS ENG[NEERING
milestones had forced development of a com- the possibility of having a good system
plete maintenance and reliability plan for because they were not allowed to adjust what
what was no longer the design, and had not they were doing to the real world; otherwise,
been the design for three months. The they would have been so far off prediction in
machinery forced everyone to grind on and one or another dimension that the project
on because, after all, the maintenance and would have been canceled. We fell between
reliability milestones could not be missed two stools. We had a system that was only
without disaster and fear of cancellation of approximately what we wanted and the sys-
the project, even though the plan being tem failed to meet the prediction. Similarly,
worked out had nothing whatever to do with we have not had the sense to cancel some-
the hardware being designed. thing that met the predictions, but was no
In fact, the point at which to start serious damn good.:
work on configuration control, maintainabil-
ity and reliability cannot be very well pre- A QUESTION OF PREDICTABILITY
planned; it can be roughly preplanned, but it
must be adjusted to be at the point at which It is curious that those of us, sophisticated as
the design means something and is likely to systems engineers, and having read history
stay still long enough so that the redesign for (in which no one ever seems to anticipate
the "ilities" will really make some sense. what really happens), knowing that the pre-
Judgment, not tools, is what is required. diction time for random noise seen through a
bandpass filter is only about one over the
PREDICTION VS. PRODUCTION bandwidth, should yet seek predictability for
the processes with a wide bandwidth of
This brings me to a related antithesis that I unknown information. No one can predict
describe as prediction versus production. We politics or economics; few of us predict what
have come to a time when meeting certain happens in our own lives. Why then do we
targets seems to have become more impor- assume the predictability of development of
tant than producing a satisfactory system. the unknown?
The question is not the development of a sys- Should we expect development miles-
tem that performs well and was produced at tones to be met? Presumably, the prior
a reasonable cost and in a reasonable time, probability of meeting the perfectly chosen
but rather replacement of this sensible milestone on time is distributed randomly
desire by the question, "Does the system per- and symmetrically about the predicted time.
form as predicted, did you produce it for the If the accomplishment is relatively simple,
cost you predicted, and on the schedule you the distribution is narrow and this is called
predicted, and did you do it in the way you "low risk;" if the accomplishment is difficult,
predicted?" Consequently, looking at what is the distribution is wide and this is called
actually happening in the development has "high risk." However, all development
been replaced by measuring it against a schedules assume success of each process. If
simplistic set of predicted milestones. Fulfill- we put trouble contingency time allowances
ment of prediction has been seriously pro- into every task, the total contingency allow-
posed as the criterion for judging system ance would be unacceptably large and the de-
managers. It is certainly a minor criterion. velopment unacceptably long. This tends to
Fulfillment of a need when fielded continues bias the true risk distribution in such a way
to be our real objective. as to move the peak to the late side. Thus,
I know of a number of cases where the there is a tendency for the "risk distribution"
pressure on prediction has been so great that to peak after the milestone. The contingency
the project managers were forced to destroy allowance should be provided in an unpopu-
__ w
lar program element, "allowance for stupid- is almost true that no military system is ever
ity and the unforeseen." Even so, it probably used for the precise purpose for which it is
would be eliminated by the efficient review designed Consequently, it makes sense to
process. think about the system as something that
All I am saying is that we only assess the will have a history in time and that is likely
risk of the predictable problems and that to require change, and to include some
there is always a family of unpredictable thought of this in the design. Change,
problems that make things take longer; strangely, is the only truly predictable attri-
there are few ("oh, happy few!") cases of luck bute of the system. Perhaps I am merely go-
" that make things take less time. We should ing to be enshrined in the next generation of
i not expect milestones to be reached, and they systems engineering doctrine with a special
"-- never (or hardly ever) are, although miles- group in every project organization called
tones are needed to assure adequate program "changeabiIity management." I hope not.
i pressure. The question is not whether there will be
_-, This question and my trial answer sug- changes or not, but whether the change
gest a signal-to-noise ratio approach to risk process will be under conscious control. Do
_= and error assessment in development the developers know "what" and "why" when
models. I have not tried to carry this further; they allow Or make a change? Pretending
it is left as an exercise for the developer. that no changes are allowable or desirable is
merely a way of losing control of the change
SYSTEMS IN SPACE VS. process.
SYSTEMS IN SPACE-TIME An example of the consequences of what I
mean follows. It is systems engineering
My next antithesis I would label "systems in doctrine that the system should be matched
space" versus "systems in space-time." We throughout; that is to say, it is regarded as
talk about system design and system choice poor practice to have, for example, high-
in terms of ten-year life-cycle costs, but the reliability components matched with low-
assumption we tend to make is that the sys- reliability components since system reliabil-
tem we are costing is a static object once it is ity will really be set by the low-reliability
designed and produced. In a way, this is components whereas system cost is likely to
forced upon us by the accountant's formalism be set by the high-reliability components.
of dividing costs into investment and recur- This ignores the fact that since the system
ring costs. Any system managers who say will have to change in time it may be very
that they are designing their system in sensible to build in high-reliability compo-
space-time, and that they propose to design nents in some parts of the system, even
it so as to facilitate their ability to change it though the technology does not provide them
during the course of the ten-year life cycle, for other parts of the system. During the
will promptly have their project removed course of the lifetime of the system, there
from under them because the doctrine says, may be a high probability of bringing the
"This is terribly uneconomicali" further- low-reliability parts up to an equivalent reli-
more, it says that it is bad system design. I ability with the higher-reliability parts for a
would simply like to note here that real- reasonable cost. Thus the system could be
world history tells us that all systems are designed for great improvement in reliabil-
changed frequently during their lifetime, if ity from the very beginning, whereas if
for no other reason than that the real everything is matched to the lower reliabil-
requirements and environments and tech- ity, the cost of improvement becomes gigan-
nologies for them change, often in ways that tic, because the changes are extensive. In
make it stupid to leave them alone. In fact, it fact, the rule of thumb may not be good
5
engineering at all if the system is designed that it is a game and cannot be taken
considering change with time. We should de- literally.
sign for growth and a process of technological There is a procedure called sensitivity
leapfrogging in the system. analysis, but I have rarely seen it applied to
the right parameters and variations. It is
OPTIMIZATION VS. UNCERTAINTY usually too difficult to do so. One rarely ever
considers an error analysis, even when some-
One of the fundamental tenets of systems thing is known about the error distributions
engineering is that the system should be of the input parameters.
optimized to its purpose. This is dandy if the A problem related to this is posed by the
purpose is very specifically definable and if it analysis of multipurpose objects. A tremen-
is very independent of scenario and enemy dous difficulty is generated by the fact that
behavior. If these requirements are not true, the costs and characteristics must be allocat-
and they almost never are for any military ed to the appearance of the system in several
system of any great sophistication, then opti- different scenarios. Consequently, these
mization may merely be the definition of systems must be single solutions to several
which catastrophe you want to undergo. My systems engineering requirements. Our usu-
analogy is the matching of a narrow-band al way of dealing with this problem is to bow
filter to a specific signal. This is an elegant three times in its direction and then ignore
engineering procedure, provided you can de- it, because it is just too hard to solve. Solving
pend on the signal to stay put. If the enemy, it requires solving the systems problems for
for example, has a slight adjustment in their all the situations in which the multipurpose
frequency, then optimization in the normal system appears, then doing all the (non-
sense rapidly becomes nonsense. There is no linear) interaction cases.
sense in optimizing the system beyond the In addition, the cost allocation to the var-
accuracy of the definition of requirements, ious uses must be attacked. There is simply
and I never, or almost never, see a definition no methodology available for really trying
of requirements with estimated error limits. this and hence the problem is generally
This particular kind of catastrophe is ignored. This makes many of the analyses
most often generated by the portion of sys- useless, but that is generally ignored too.
tems engineering that the economists like to There is no sense in pretending to solve
call systems analysis. That is to say, having problems by refusing to address them realis-
chosen some scenario or problem defined in a tically because they are too difficult, but we
very specific way, the system prescription go on playing that game.
follows optimization of this problem to the
bitter and ridiculous end. There is a vast OBJECTS VS. OBJECTIVES
reluctance to look at the difficulties and the
risks involved in assuming that the chosen Finally, we do not distinguish sufficiently
problem is the correct problem. I will feel between objects and objectives. The working
much better about the use of scenarios and tools and most of the life of systems
prediction of warfare ten years ahead for engineering are spent trying to reach an
system choice and optimization if ever I meet objective, the objective finally becoming an
a person who can really predict a chess game, object. It is important to keep this distinction
or what will happen in the stock market in mind. The trouble in procurement of a
tomorrow. This is not to say the game should development is that procurement procedures
be ruled out just because the results cannot are designed to buy objects, whereas in
be predicted, but rather to reinforce the fact development there is no object until the end,
only an objective, and the two are not the frequent conferences with those who have
same thing. the requirement.
For example, what is a specification? A In this way, the end object may become
specification is an abstract set intended to the best that both parts of the system can
describe what is to be produced, but of course produce and not merely the solution to a
it is only a portion of a total description. It is paper problem, said solution having the best
a subset of points selected from a continuous paper properties to match the previous set of
portion of an infinite multidimensional paper. (Some paper is water soluble.)
space. The object itself and its total future It might do well to bear in mind the
history is the only complete specification. following closing thoughts:
Consequently, the idea of a "complete" speci-
fication is an absurdity; we can only produce As we are now behaving, we are using up
a partial subset. In fact, it is possible (and we our best people in filling out documenta-
have all seen it happen) for an object that tion for their superiors to read, and most
meets the subset of specification points to of the time no one is running the store.
badly miss being a sensible solution to the We have lost sight of the fact that engi-
problem, because it departs from the neering is an art, not a technique; a tech-
required reality between the specification nique is a tool. From time to time I am
subset points. I hasten to add that sometimes briefed on the results of a systems analy-
even the object itself, without regard to its sis or systems engineering job in a way
future history, is not a sufficient specifica- that prompts me to ask the questions:
tion, because it does not contain the details "That's fine, but is it a good system? Do
of the techniques used to produce it. Let the you like it? Is it harmonious? Is it an
specifier beware! elegant solution to a real problem?" For
Having complained about all of this an answer I usually get a blank stare and
throughout this article, what do I propose? a facial expression that suggests I have
The only thing I know that works is to obtain just said something really obscene.
a competent person and assistants, and
make sure they understand the problemn We must bring the sense of art and
not the specifications of the problem, not the excitement back into engineering. Talent,
particular written scenario, but what is real- competence, and enthusiasm are qualities of
ly in the minds of those who have a people who can use tools; the lack of these
requirement to be solved. Then give them characteristics usually results in people who
funds, a good choice of managerial and cannot even be helped by techniques and
systems engineering tools, and let them tools. We can all do better.
work at the problem after reasonably
SYSTEMS ENGINEERING OVERVIEW AND PROCESS
N 9 3 .. 2 4
THE SYSTEMS ENGINEERING OVERVIEW AND PROCESS _)_-_7/
(FROM THE SYSTEMS ENGINEERING MANAGEMENT GUIDE [1990])
Defense Systems Management College
The past several decades have seen the rise In its simplest terms, systems engineer-
of large, highly interactive systems that are ing is both a technical process and a manage-
on the forward edge of technology. As a re- ment process. To successfully complete the
sult of this growth and the increased usage of development of a system, both aspects must
digital systems (computers and software), be applied throughout the system life cycle.
the concept of systems engineering has From a government's program management
gained increasing attention. Some of this at- point of view, the Defense Systems Manage-
tention is no doubt due to large program fail- ment College favors the management ap-
ures which possibly could have been avoided, proach and defines systems engineering as
or at least mitigated, through the use of sys- follows:
tems engineering principles. The complexity Systems engineering is the manage-
of modern day weapon systems requires con- ment function which controls the total
scious application of systems engineering system development effort for the pur-
concepts to ensure producible, operable and pose of achieving an optimum balance
supportable systems that satisfy mission of all system elements. It is a process
requirements. which transforms an operational need
Although many authors have traced the into a description of system parameters
roots of systems engineering to earlier dates, and integrates those parameters to op-
the initial formalization of the systems engi- timize the overall system effectiveness.
neering process for military development A system life cycle begins with the user's
began to surface in the mid-1950s on the bal- needs, expressed as constraints, and the
listic missile programs. These early ballistic capability requirements needed to satisfy
missile development programs marked the mission objectives. Systems engineering is
emergence of engineering discipline "special- essential in the earliest planning period, in
ists" which has since continued to grow. conceiving the system concept and defining
Each of these specialties not only has a need system requirements.
to take data from the overall development As the detailed design is being done, sys-
process, but also to supply data, in the form tems engineers: 1) assure balanced influence
of requirements and analysis results, to the of all required design specialties, 2) resolve
process. interface problems, 3) conduct design re-
A number of technical instructions, mili- views, 4) perform trade-off analyses, and
tary standards and specifications, and man- 5) assist in verifying system performance.
uals were developed as a result of these During the production phase, systems en-
development programs. In particular, MIL- gineering is concerned with: 1) verifying sys-
STD-499 was issued in 1969 to assist both tem capability, 2)maintaining the system
government and contractor personnel in baseline, and 3)forming an analytical
defining the systems engineering effort in framework for producibility analysis.
support of defense acquisition programs. During the operation and support (O/S)
This standard was updated to MIL-STD- phase, systems engineering: 1) evaluates
499A in 1974, and formed the foundation for proposed changes to the systems, 2) estab-
current application of systems engineering lishes their effectiveness, and 3) facilitates
principles to military development pro- the effective incorporation of changes, modi-
grams. fications and updates.
PRE(_EDiNG PAGE BLANK NOT FILMED

IterativeTrade-Offs
Functional
.i Input
t.
Lf
i Requirements
............ .i
i '_ Analysis
Synthesis
R_
and
Evaluation
Decision _]
System
Description
Elements of
• What • How • Solutions

• Why
Figure I The Systems Engineering Process
THE SYSTEMS ENGINEERING PROCESS use as performance, design, interface,

support, production and test criteria.
Although programs differ in underlying • Provide source data for development of
requirements, there is a consistent, logical technical plans and contract work state-
process for best accomplishing system design ments.
tasks. Figure 1 illustrates the activities of • Provide a systems framework for logistic
the basic systems engineering process. analysis, integrated logistic support
The systems engineering process is itera- (ILS), trade studies and logistic documen-
tively applied. It consists primarily of four tation.
activities: functional analysis, synthesis, • Provide a systems framework for produc-
evaluation and decision, and a description of tion engineering analysis, producibility
systems elements. The product element trade studies, and production and manu-
descriptions become more detailed with each facturing documentation.
application and support the subsequent • Ensure that life cycle cost considerations
systems engineering design cycle. The final and requirements are fully considered in
product is production-ready documentation all phases of the design process.
of all system elements.
Since the requirement to implement a Successful application of systems engi-
systems engineering process may cause neering requires mutual understanding and
major budgetary commitments and impact support between the milita_ and contractor
upfront development schedules, it is impor- program managersl Ti_ey must be willing to
tant to understand the inherent objectives: make the systems engineering process the
backbone of the overall development
• Ensure that system definition and design program. They must understand the need to
reflect requirements for all system ele- define and communicate among the
ments: equipment, software, personnel, engineering specialty programs. They must
facilities and data. recognize the role of formal technical reviews
• Integrate technical efforts of the design and audits, including the value, objectives
team specialists to produce an optimally and uniqueness of each formal review and
balanced design. audit. They must also know the objectives of
• Provide a comprehensive indentured the program and possess a thorough inter-
framework of system requirements for pretation of the user's requirements.
10
SYSTEMS ENGINEERING OVERVIEW AND PROC ESS
The output of the systems engineering , Producibility Plan

process is documentation. This is the means • Functional Flow Block Diagrams (FFBD)
by which it controls the evolutionary devel- • Requirements Allocation Sheets (RAS)
opment of the system. Systems engineering • Audit Reports
prepares a number of technical management • EMI/EMC Control Plan
and engineering specialty plans that define • Human Engineering Plan
how each phase of the acquisition cycle will • Trade Study Reports
be conducted. Draft plans are usually sub-
mitted with the proposal and final plans are The systems engineering process is an
delivered in accordance with the Contract iterative process applied throughout the ac-
Data Requirements List (CDRL). These quisition life cycle. The process itself leads to
plans are used by the government to ensure a well defined, completely documented and
compliance with the contract and used by the optimally balanced system. It does not pro-
contractor to develop detailed schedules and duce the actual system itself, but rather, it
allocation of resources. Specifications are produces the complete set of documentation,
submitted that form the basis for the design tailored to the needs of a specific program,
and development effort. Top-level specifica- which fully describes the system to be devel-
tions are incorporated into the statement of oped and produced. Each program's systems
work (SOW) and provided to the developer. engineering process, developed through
The developer will allocate these top-level tailoring and/or adding supplemental re-
requirements to lower level system compo- quirements, must meet certain general crite-
nents (hardware and software) and submit ria. Although not complete, the following
the associated specifications and design doc- guidelines should be considered in approach-
uments to the government for approval. The ing the basic process:
status of system development progress is
tracked and documented in the form of tech- • System and subsystem (configuration
nical review data packages, technical perfor- item) requirements shall be consistent,
mance measurement (TPM) reports, analysis correlatable, and traceable both within
and simulation reports and other technical data produced as basic documentation
documentation pertinent _o the program. In (e.g., Functional Flow Block Diagram,
summary, this documentation may include: Requirements Allocation Sheet, and
Time Line Sheet) and as related docu-
• Systems Engineering Management Plan mentation (e.g., work breakdown struc-
(SEMP) ture and Logistic Support Analysis
• Specifications (system, segment, develop- Record).
ment, product, process, material) • The concept of minimum documentation
• Design Documentation shall be evident.
• Interface Control Documents (ICDs) • Acquisition and ownership cost shall be
• Risk Analysis Management Plan an integral part of the evaluation and de-
• Survivability/Vulnerability (S/V) Hard- cision process.
ness Plan • Baselines shall be established progres-
• Mission Analysis Report sively as an integral part of the systems
• Reliability Plan engineering process.
• Maintainability Plan • The systems engineering process shall
• Integrated Logistics Support Plan (ILSP) result in a design that is complete, at a
• Software Development Plan(SDP) given level of detail, from a total system
• Test and Evaluation Master Plan element viewpoint.
(TEMP)
]l
• The process shall provide for the timely Significant engineering decisions shall be
and appropriate integration of main- traceable to the systems engineering ac-
stream engineering with engineering tivities and associated documentation
specialties such as reliability, maintain- upon which they were based.
ability, human factors engineering,
safety, integrated logistic support, envi- Figure 2 is an overview of the four basic
ronmental assessments and producibility steps of the systems engineering process.
to ensure their influence on system
design. FUNCTIONAL ANALYSIS
• The process shall provide for continuing
prediction and demonstration of the an- Every engineering effort must begin with a
ticipated or actual achievement of the statement of a perceived need. At the
primary technical objectives of the sys- beginning of a DOD acquisition effort, this
tem. Problems and risk areas shall be statement will be in the form of a system
identified in a timely manner. requirement document, usually developed
• Formal technical reviews and audits through a Mission Area Analysis of antici-
shall be an integral part of the systems pated threats.
engineering process. Once the purpose of the system is known,
• The systems engineering process shall be the functional analysis activity identifies
responsive to change. The impact of what essential functions the system must
changes to system and/or program re- perform. In order to accomplish this, func-
quirements must be traceable to the low- tional analysis is composed of two primary
est level of related documentation in a process segments: functional identification
timely manner. and requirements identification and
(_ G _ Evalua _)tiOn
Input Requirements
• Mission Objectives
• Mission Environments F_na_ysnal_[ Synth_esis __1 a_drD_:Is_n l
• Mission Constraints
• Measurements of
Effectiveness
S_'
Technology Selection Factors ____= 1 N° No_
• Hardware
• Software
[ Description of System Elements ]
• Reliability
• Maintainability
• Personnel/Human Factors
• Equipment
• Survivability • Personnel
• Security • Facilities
• Safety • Computer Software
• Standardization • Technical Data
• IntegratedLogisticSupport
• EMC
• System Mass Properties
• Producibility
• Transportability
• Electronic
Warfare
• Computer Resources
Figure 2 The Systems Engineering Process
12
allocation (functional performance require- allocation of the functional performance

ments analysis). It answers the "what" and requirements to individual system elements
"why" questions relative to system design. or a combination of elements; and 3) follow-
The basic analytical tool for functional ing evaluation and decision, the RAS
identification is the Functional Flow Block provides the functionally oriented data re-
Diagram (FFBD), showing logical sequences quired in the description of the system
and relationships of operational and support elements.
functions at the system level. Specific func- The Time Line Sheet (TLS) is used to
tions will vary from system to system and perform and record the analysis of time-
will be traceable to mission requirements critical functions and functional sequence_
and objectives. Maintenance flow diagrams In performing time requirements analysis
depicting general maintenance and support for complex functional sequences, additional
concepts will lead to analysis of require- tools, such as mathematical models or
ments on an end item/equipment basis. At computer simulations, may be needed. Time
this level, since functions are more standard- requirements analysis is performed in any or
ized, functional identification is often accom- all of the functional cycles of the process to
plished using the End Item Maintenance determine whether time is a critical factor.
Sheet (EIMS) or Logistic Support Analysis The TLS complements the FFBD in its
Record (LSAR). Similarly, detailed test ability to show a lower level of detail, as well
requirements are identified using the Test as to illustrate the impact of concurrent
Requirements Sheet (TRS), and productivity functions within a given sequence. TLSs are
requirements are identified using the used to support the development of design
Production Sheet (PS). requirements for the operation, test and
It should be kept in mind that the sys- maintenance functions. They identify time-
tems engineering process is always iterative. critical functions and depict the concurrency,
Each acquisition phase will involve function- overlap and sequential relationship of
al analysis to progressively more detail. For functions and related tasks. Time-critical
example, during the Concept Explora- functions are those that affect reaction time,
tion/Definition (C/E) phase, analysis of downtime or availability.
support functions will concentrate on Main-
tenance FFBDs, which will support the SYNTHESIS
establishment of gross maintenance con-

cepts. During Full Scale Development (FSD), Synthesis supplies the "how" answers to the
emphasis will shift to detailed analysis of the "what" outputs of functional analysis.
maintenance requirements of specific equip- Two documentation tools accomplish and
ment using the EIMS or LSAR. record the synthesis of design approaches or
The Requirements Allocation Sheet alternative approaches. The Concept
(RAS) is used as the primary analytical tool Description Sheet (CDS) is used to collect the
for requirements identification and alloca- performance requirements and constraints,
tion, or functional performance require- as delineated by functional analysis, that
ments analysis as it often is referred to, in apply to an individual subsystem or end
conjunction with FFBDs and special purpose item. The CDS also describes at the gross
documents such as EIMSs, TRSs, and PSs. level a design approach for meeting the
The RAS serves three purposes in document- requirements. The Schematic Block Dia-
ing the systems engineering process: 1) ini- gram (SBD) is used to develop and portray
tially, it is used to record the performance the conceptual schematic arrangement of
requirements established for each function; system elements to meet system and/or
2) during synthesis, it is used to show the subsystem requirements. The CDS and SBD
13
are both applicable to all acquisition phases and constraints that establish the selection
and provide the basis for development of the criteria for a specific trade study area. The
descriptions of system elements. report also documents the rationale used in
the decision process and should present risk
EVALUATION AND DECISION assessment and risk avoidance consider-
ations. Other tools, such as analytical or
Since program risk and cost are dependent mathematical models or computer simula-
on practical trade-offs between stated oper- tions, may be needed and used in accomplish-
ating requirements and engineering design, ing the evaluation and decision process.
continual evaluations and decisions must be
made not only at the beginning of the DESCRIPTION OF SYSTEM ELEMENTS
program but throughout the design and
development activity. All systems can be defined by a set of inter-
The Trade Study Report (TSR) is used to acting system elements which fall into five
summarize and correlate characteristics of categories: equipment (hardware), software,
alternative solutions to the requirements facilities, personnel, and procedural data.
Functional Analysis
ments _
I i
........................
Id
L- ..........................
n
r! $
_J
] i
Synthesis
_
& Decision
Evaluation _
System
Elements
Description of
Functional Flow Requirements Concept r ............Trade 7w............... Design

Block Diagrams Allocation Sheets Description Sheets Study Reports t Sheets
(FFBD) (RAS) (CDS) (TSR) ', (DS)
Identify and se- Define the require- Constrain the de- Select,evaluate and ljDefine, describe and
t_tn ce functions ments and constraints signer to stop at a optimize promising ispecify performance.
must be accom- for each of the func- point in the cycle and or attractive con- 'design and testcri-
Basic plished to achieve tions and relate each create at the gross cepts.Document the J_
teria for the system
Documen- ---_1 system or project ob- requirement to the sys- level a design or syn- trade-offand sup- lelements
tation I iectives Develop the tem elements of thesis meeting the porting rationale. 0a Equipment
i basis for establish- FFBD, RAS, TLS Consider all00ssible ljb. Facilities
ing intersystem .• Equipment
Facilities requirements and solutions within the ,c. Personnel
functionalinterfaces c. Personnel 'constraints. framework of re- ld. Procedural data
and identify system d. Procedural data quirements, e. Computer soft-
relationships. e. Computer software Schematic ware
Block Diagrams
Time Line Sheets _SBD)
(TLS)
Develop and portray
Present critical func- schematic arrange-
tions against a time ment ofsystem ele-
base in the required se- ments to satisfy sys-
quence of accomplish- tom requirements.
ment.
........................ m I .................
End Item
FacilityInterface
Maintenance Sheet
Sheets
(EIMS)frest Reqmt
(FIS)
Sheet {TRS)/
Special Production Sheets Identify environ-
Purpose _.._, (PS)/Logistic Sup- mental and physical
Documen- --, port Analysis interfaces between
tation Record (LSAR) equipment and fa-
Identify mainten- cilities
on an end
i ance, test and pro- item basis.
I duction functions on
a specific end item,
I subaszembly, and
component basis.
Indenture is carried to the level required for the selected level ofengmeering to identify, describe and specify.
Figure 3 Basic and Special Purpose Documentation for Systems Engineering
14
Two documentation forms are used to specifications are prepared as part of the-
describe these system elements: the Design systems engineering process to form the
Sheet (DS) and the Facility Interface Sheet basis for the design and development effort.
(FIS). The DS is used to establish and The top-level specification (system or seg-
describe the performance, design and test ment) is normally approved and draft lower
requirements for equipment end items, criti- level specifications (configuration items) are
cal components and computer software developed reflecting allocated system re-
programs. The FIS is used to identify the quirements to lower level components or sub-
environmental requirements and interface systems, which designers and subcontractors
design requirements imposed upon facilities translate into hardware and software pro-
by the functional and design characteristics duction plans.
of equipment end items. The DS and FIS In order to provide a continuing assess-
provide the basis for the formal identifica- ment of the system's capability to meet
tion required for configuration management. performance requirements, the systems
The systems engineering process pro- engineering organization prepares technical
duces the basic and special purpose docu- review data packages, technical performance
mentation that controls the evolutionary measurement (TPM) reports, analysis and
development of the system. Figure 3 simulation reports, and other documenta-
correlates the particular documentation tion.
associated with each step of the systems The systems engineering process is one
engineering process. approach to providing disciplined engineer-
The systems engineering process itself ing during all acquisition phases. Although
does not actually produce the system, but current application of the process has focused
produces the documentation necessary to de- on C/E, D/V, and FSD, systems engineering
fine, design, develop and test the system. As process techniques and principles are equal-
such, a variety of engineering and planning ly applicable to the analysis and definition of
documentation is required throughout the production requirements.
acquisition cycle, and systems engineering is The systems engineering process also pro-
the vehicle used to produce that documenta- vides the logic and timing for a disciplined
tion. approach, with certain internal assurances
Numerous plans are prepared to define of technical integrity such as traceability.
which technical activities will be conducted. Technical integrity ensures that the design
They address the integration of engineering requirements for the system elements reflect
specialties requirements, "design-for" re- the functional performance requirements,
quirements and organizational resource that all functional performance require-
requirements, and discuss how progress ments are satisfied by the combined system
toward system-level goals will be measured. elements, and that such requirements are
The Systems Engineering Management Plan optimized with respect to system perfor-
is the key planning document that reflects mance requirements and constraints.
these requirements. Contractor compliance
with these plans is monitored by government The DSMC Systems Engineering Man-
organizations to ensure that standard poli- agement Guide may be purchased from the
cies and procedures in the area of systems U.S. Government Printing Office (1991-306-
engineering are employed. Additionally, 417-QL 3).
15
SYSTEMS ENGINEERING FOR VERY LARGE SYSTEMS
N93- 24 J68 )
SYSTEMS ENGINEERING FOR VERY LARGE SYSTEMS /.5"_'7 2-_
by Paul E. Lewkowicz
Very large integrated systems have always Recent efforts at Hughes Aircraft
posed special problems for engineers. Wheth- Company's Space & Communications Group
er they are power generation systems, com- have focused on sharpening the definition of
puter networks or space vehicles, whenever systems engineering and defining standards
there are multiple interfaces, complex tech- for improving the implementation of the full
nologies or just demanding customers, the systems engineering methodology on large
challenges are unique. "Systems engineer- spacecraft programs. Since these programs
ing" has evolved as a discipline in order to typically cost in the $100 million range, the
meet these challenges by providing a struc- pressure to deliver specified performance on
tured, top-down design and development time and on budget is enormous. A casual re-
methodology for the engineer. This paper view of programs within the author's exper-
attempts to define the general class of ience has shown that the classical approach
problems requiring the complete systems to systems engineering has been followed
engineering treatment and to show how throughout, but with varying uniformity
systems engineering can be utilized to and overall success. The question to answer,
improve customer satisfaction and profit- in the context of even more advanced, more
ability. Specifically, this work will focus on a demanding projects, is: "How can it be done
design methodology for the largest of better?"
systems, not necessarily in terms of physical The "classical" method of systems
size, but in terms of complexity and intercon- engineering alluded to above consists of
nectivity. requirements definition, technology assess-
The literature has generally defined ment, solution synthesis and performance
"systems engineering" as in this quote from verification: four successive steps in the
W.P. Chase in Management of System design of the mission solution. Typically,
Engineering: this is an iterative process, since require-
ments and technology rarely remain static.
[Systems Engineering is] the process of
The customer's mission can be altered by
selecting and synthesizing the applica-
events or even by a better understanding of
tion of... knowledge in order to trans-
the technology, risks or costs involved.
late system requirements into a system
Synthesized solutions, too, depend on the
design and.., to demonstrate that [it]
technology available, as well as the question
can be effectively employed as a coher-
asked. Often, the proposed technology does
ent whole to achieve some stated goal
not live up to expectations, resulting in a
or purpose. "new" solution and reverification: an embar-
This definition points out, in the most rassing situation at best, an extremely costly
general terms, that systems engineering is a one at worst.
process for ensuring that the customer When the verification (or testing) phase
requirements are satisfied. What it also of the systems engineering process uncovers
implies is that this satisfaction must be a fault, the cause can often be traced to in-
achieved on time and for the agreed-upon complete or improperly stated requirements.
price. It is this implicit requirement that is An example of this fact is a problem uncov-
most often unfulfilled in complex engineer- ered on one particular series of satellites; an
ing projects. on-orbit failure resulted in the loss of some
16 channels of telemetry data. The failure
o 1988 IEEE. Reprinted with permission of the author, from [EEE
Aerospace Application Conference, Park City, Utah, Februa_ I988
analysis, performed by the program's
17
systems engineering staff, identified the ing must be distributed over the entire
cause as an open circuit in a particular unit. production run. Even if the run is large, as in
This fault produced an abnormally high the ballpoint pen case, when the product nor-
telemetry output signal on one channel, mally sells for 39 cents, if the engineering
which in turn resulted in the degradation of costs run into the millions, then the manu-
all 16 inputs to the telemetry multiplexer. facturer could be in serious trouble. For
Had systems engineering levied a require- smaller production runs, like a satellite or
ment to protect against failure-induced over- submarine contract, systems engineering
voltages (via a simple circuit redundancy costs can still drive the final sale price, but
technique at the unit), only the failed tele- systems engineering can also reduce the
metry channel would have been lost, instead price by preventing errors and rework.
of that of 15 other units as well.
The point here is that it is a knowledge of THE SYSTEMS ENGINEERING
the needs of the whole system that is re- METHODOLOGY
quired, instead of only the needs of the parts.
This knowledge exemplifies the principle of The procedure followed in systems engineer-
"engineering leverage" whereby a few engi- ing consists of four distinct phases, described
neers, representing a broad experience base, here in the simplest terms: requirements
performing the logical, methodical systems definition, technology assessment, solution
design work, can save money over trial and synthesis and performance verification.
error or crisis-oriented engineering. It is the These sobriquets are intended to be mne-
concentration of systems knowledge, the "big monic; the details of what they really signify
picture" view, that allows for efficient are presented below.
designs all through the system.
A common question is: "How much sys- Requirements Analysis. The initial step
tems engineering is required for a given pro- consists of defining the problem to be solved
ject?" This can usually be interpreted as and the constraints on the solution set. This
"How much will this cost?" Clearly a design is perhaps the single most critical phase of
team with unlimited funds can perform com- the systems engineering process in that a
plete requirements analysis, all manner of misunderstanding of the problem to be
failure analysis and simulations, and exten- solved, either in characterizing it or defining
sive part and unit environmental testing to the context of the solution, can result in an
fully optimize the design of some particular erroneous conclusion. As in the satellite
product. But if that product is, say, a ball- telemetry example, the customer can be
point pen, have they really made it better somewhat less than satisfied when a partial
from the manufacturer's standpoint? Or solution is delivered.
have they succeeded in making the most In large systems, the problem definition
expensive writing instrument the world has is usually described by the contractual docu-
ever known? The application of systems ments. The request for proposal (RFP) or the
engineering techniques to a project is a statement of work typically contains direc-
matter of appropriate degree; how much tives as to the overall mission of the system,
engineering is required to ensure the cus- but these are not always completely specific;
tomer's satisfaction becomes the first ques- some interpretation of what the customer
tion any organization must ask before they really meant is often required.
can set up a systems engineering program. Another aspect of requirements analysis
This example emphasizes the fact that often underappreciated is that of constrain-
systems engineering costs are a direct charge ing the solution. The RFP for a program may
to the effort, so the total cost of the engineer- state that only a certain rocket booster or
18
parts of a specific grade can be used, but the pecially such items pertaining to cost and
implications of such statements, and espe- producibility. If it can't be built or bought,
cially the implications of the "unstated" or then it's not the right answer.
"implied" requirements, can have serious
consequences in the final design. These Performance Verification. Last, but defi-
requirements, sometimes called derived or nitely not least, is the performance verifica-
secondary requirements, determine the lim- tion or testing phase. The task here is to
its of the parametric trades that can be made prove, with all the rigor possible, that the
in characterizing the problem's solution. suggested solution does in fact meet all of the
system requirements in a clearly docu-
Technology Assessment. Once the basic mented way. A standard approach is to
requirements, both primary and secondary, utilize specification trees and a verification
are in place and understood by the design matrix to show where each requirement from
team, the technology available to solve the the original customer's source documents is
problem can be examined for suitability. captured in lower level specifications. Addi-
This step is intuitively obvious for small tionally, the verification matrix shows how
systems, but when complexity is high, compliance with the requirement is proven,
making the appropriate choice is not always either by inspection, test, demonstration or
easy. Typical activities in this phase include analysis. In general, the specification system
comparative tradeoffs between different is designed to show a clear, unambiguous
processes and materials, architectures and flowdown of all system requirements into
performance. The technology assessment individual component designs. The verifica-
phase may also consider the design and docu- tion phase is the test of this flowdown as well
mentation methods and the management as a measure of system performance.
organization to be employed on a specific
project. Overall, this phase is concerned with REQUIREMENTS FOR SUCCESSFUL
selecting the best tools for performing the SYSTEMS ENGINEERING
system design.
The foregoing text has all been a precursor to
Solution Synthesis. This is usually the this: exactly what does an organization have
most time-consuming step in engineering a to do to apply a full-scale systems engineer-
system to perform complex tasks and meet ing approach to their work? And, perhaps
stringent requirements simply because of more importantly, what does it cost that
the number of choices available. If the re- organization? As expected, in systems engi-
quirements are well understood and the neering, as in life, there are no free lunches.
available hardware and software appro- This section details the inputs to the process,
priate to the task are known, then trade or what is required by a systems engineering
studies can be carried out (on paper) that re- organization in order to function properly.
sult in myriad viable combinations. During
this phase, compromises are often required Formality. First and foremost, a formal,
in order to satisfy conflicting requirements. planned approach to the systems engineer-
For example, in a communications system ing process must be in place. Not only must
design, a large antenna may be desired to the "generic" methodology for systems engi-
provide high gain, but this will reduce its neering be understood by all involved, the
coverage capability by reducing the beam- detailed program plans for the specific appli-
width. Out of this sea of alternatives must cation of systems engineering must reflect
come a single "best fit" solution, meeting all this commitment. The major components in
of the original and derived requirements, es- the formal system are review procedures,
19
specification generation and maintenance tem engineers, unit designers, etc.) must all
(or "configuration control") procedures, and talk to each other in order to completely
planning. understand the requirements. In every pro-
As can be deduced from the discussion of gram there are stated goals and hidden
the phases of the systems engineering pro- goals, real requirements and perceived
cess, some degree of review and checking is requirements; it all depends on where the
inherent to all operations. The establish- observer is looking from. Communications
ment of specification and design review and open channels between all participants,
teams to examine the documents (e.g., speci- regardless of title or rank, are absolutely
fications, trade study reports, etc.) and help essential to all phases of the job.
polish them into complete and correct inputs
to the final design cannot be avoided. With- Technology Base. "Technology" in this
out concrete review milestones, the design context means more than the hardware and
will often wander and become unfocused software that can be employed in a design
with respect to its objectives, which results solution; it encompasses the organizations
in inefficient time and money management. and information architectures as well. As a
Since the specifications define the prob- system becomes larger and more complex, so
lem to be solved and its constraints, it is too does the technology or "knowledge base"
clear that they must be reliable and well doc- required to fully define the implementation
umented. The configuration control function of system requirements. Such a base might
is to provide a routine for the introduction, include other contractors, national resources
validation and documentation of new re- (e.g., the Space Transportation System), spe-
quirements and the updating of old ones cialized electronic devices, etc. In short, prac-
within the system. This is an important step tically any conceivable problems, and even a
in the review process, as well as the design few inconceivable ones, can come up in sys-
process, in that all parties (customer and tems design. To deal effectively with them,
contractor alike) need a stable, well-defined the systems engineering team must have the
basis of judgment for the validation of the knowledge and experience to recognize solu-
system. tions from a wide selection of possibilities.
Planning is mentioned last in this case
only for emphasis: without complete plan- Dedication and Staffing. Finally, the one
ning for the entire system design effort, from factor that takes system engineering from an
requirements definition through systems en- abstract concept to a practical reality is the
gineering, production, and final deployment, dedication of the people involved. In order to
the project is doomed to failure. Every man- even begin a design for a complex system, a
agement textbook in the world expounds this design team is required. Not a single guru
fact in detail, yet weak planning is still a and a few part-time acolytes, but a team of
major cause of cost overruns and poor perfor- committed managers and engineers with ex-
mance in all types of industry. perience in real-world problem solving, tech-
nical breadth and clearly defined roles in the
Information Exchange. While formality systems engineering process. Without this
and procedure allow tight control of the core team, the continuity and rigor required
requirements, informality and open commu- by the process to ensure a coherent, effective
nications are the key to efficient design and solution cannot possibly exist.
problem resolution. Not only must the con- Just as planning is the key to a successful =
tractor communicate effectively with the project, leadership is the key to a successful
customer, but the various elements of the team. The complexity of the designs under
contractor's organization (management, sys- discussion are such that (typically) a wide
2O
range of talents are needed to arrive at a continuity and growth, the staff benefits
solution. This diversity can be dangerous personally as well.
without direction, because diversity is just a What about the individual roles of the
polite name for chaos waiting to happen. A staff members? The need for a broad know-
group with a broad technical background, ledge base, for generalists, is clear, but what
when presented a problem without leader- do they do? As in any team-building
ship, will always seek to maximize its situation, all members need clearly commu-
entropy. The project staff must be directed nicated job descriptions and management
and focused at all times in order to move expectations; this applies to all members of
through the systems engineering process. the project team from the most senior man-
After all, efficiency and minimal engineer- ager to the last clerk. Once the work has
ing costs concern the entire group. The depth started, they need tangible feedback on what
necessary to perform the detailed designs is going correctly, according to expectations,
need not come from the systems staff, and what is not. The immediate benefit to
however; this is often not possible given the the organization is clear. Job satisfaction in-
generalist nature required of them. Most creases, and with it, a concomitant rise in
companies employ a unit engineering staff to overall productivity. Again, the process,
design the components of the complete when properly managed, feeds upon itself to
solution, which simply reflects the top-down work more efficiently.
design approach of breaking each require-
ment down into smaller and smaller COST VS. BENEFITS OF FULL-SCALE
functional blocks. SYSTEMS ENGINEERING
An important factor to consider is time. It
may take several months or even years to The requirements levied upon systems de-
complete the design of a complex system, so sign for very large projects are simple: pro-
continuity becomes a factor in the staffing of vide full customer satisfaction on time and
the design team. The deleterious effects of on budget for a set of diverse and complex
change on an organization are well known, functional specifications and interconnec-
and so are those of miscommunication. The tions. Likewise, the technology appropriate
training of systems engineers, whether to this task is (hopefully) equally clear:
through formal schooling or on-the-job edu- employ a formal, full-scale systems engi-
cation, is the first step toward building a neering approach to meeting this challenge.
self-perpetuating, self-replicating design
methodology. Experienced staff members are Costs:
able to produce more and overcome obstacles - Management must be willing to allow
better than those less experienced; reinven- group synergy to make decisions; the
ting the wheel is avoided. Additionally, "group think" approach is mandatory.
experienced people add synergy to the team - Personnel must be dedicated and im-
by virtue of shared experiences. Synergism mersed in the systems engineering of a
in the design process is how the engineering single system. Teamwork and continuity
leverage of systems engineering is released, must be fostered and preserved.
by the magnification of individual efforts. A - The systems engineering organization
fringe benefit of this magnification is growth can exhibit all the negative aspects of a
in the individuals involved. The less bureaucracy if not managed precisely.
experienced become more experienced and - Careful, rigorous planning is required for
leadership skills are developed and honed. all aspects of the program up-front, before
Not only does the design process (and the work begins, which often means extra
product) continue to improve but, through bidding expense.
21
Benefits:
+ Customer satisfaction is enhanced The author wishes to thank Dr. Thomas A,
through demonstrated performance and Brackey, W. Richard Brown, and Gdvien
the opportunity for full customer involve- Miyata of the Hughes Aircraft Company for
ment in the design process. their support and mentorship in several com-
+ Manageability is improved by accurate, plex design projects.
more complete planning and a well-
defined staff structure. REFERENCES
+ Contingencies are worked out in advance,
resulting in fewer surprises during the Chase, W.P. Management of System Engi-
design, test and production phases. neering, as quoted in Hughes, Seminar.
+ Better cost performance is achieved due
to reduced redesigns, reworks and "patch- Defense Systems Management College. Sys-
es." tems Engineering Management Guide, U.S.
Air Force, 3 October 1983.
After an analysis of the costs and benefits
of implementing a systems engineering Hughes Aircraft Company. Systems Engi-
solution to a complex design problem, it neering Seminar for General Motors, internal
becomes apparent that the benefits outweigh memorandum, 1987.
the costs, especially in terms of the potential
for productivity and cost improvements. The ..... . "S&CG Practice 5-0-53," internal
chief drawback of this method is that it is memorandum, 21 July 1987.
difficult to implement in organizations that
do not already practice some form of systems ..... . "Systems Engineering Division Mis-
engineering, due to the cultural adjustments sion, Goals, and Objectives," internal memo-
that are uften necessary. Once the need for a randum, 8 October 1987.
rigorous design methodology is apparent, the
systems engineering process of requirements IEE_._tandard Dictionary of Electrical and
analysis, technology assessment, solution Electronics Terms, IEEE Press, Third Edi-
synthesis and performance verification can tion, 1984 (ANSI/IEEE Std 100-1984).
be utilized to provide an efficient, cost-
effective solution to the managerial and IEEE Spectrum special report, On Good De-
technical challenges. sign, Volume 24, Number 5, May 1987.
U.S. Government MIL-STD-499.
22
WHAT IS A SYSTEM?
WHAT IS A SYSTEM? NASA's PHASED PROJECT / 7J

DESCRIPTION
From the MSFC Systems Engineering Handbook (1991) _ _ /
Systems engineering is defined in MIL-STD- • Many hardware and software systems in

499A as concurrent development
• . . the process(es) required to trans- • Complex operational and logistic support
form an operational need into a requirements
description of system performance • Constrained development time
parameters and a system configuration • High level of advanced technology
through the use of an iterative process (Systems Engineering Management
of definition, synthesis, analysis, de- Guide, U.S. Government Printing Office,
sign, test and evaluation. It includes 1986).
the integration of related technical
parameters and ensures compatibility There are many definitions of a system. Two
of all physical, functional, and program of these are listed below:
interfaces in a manner that optimizes
the total system definition and design. A system is a set of interrelated compo-
In addition, systems engineering nents working together toward some com-
integrates reliability, maintainability, mon objective. (Blanchard, Benjamin S.
safety, survivability, and other such and Fabrycky, Wolter J., Systems Engi-
efforts into the total engineering effort neering and Analysis, Prentice Hall, Inc.,
to meet cost, schedule and technical 1990)
performance objectives. (Engineering A system is a grouping of parts that
Management, May 1, 1974) operate together for a common purpose.
Systems engineering is a continuous, For example, an automobile is a system of
iterative process that has a built-in feedback components that work together to provide
mechanism, It is used throughout a project transportation. An autopilot and an
or program's life cycle to arrive at the best airplane form a system for flying at a
system architecture and design possible. specified altitude. (Forrester, Jay W.,
Just when systems engineering began to be Principles of Systems, Wright-Allen Press
practiced as a separate discipline is open to Inc., 1968).
debate, but there seems to be general agree-
ment that formal recognition and definition Systems engineering is a cyclical process as
of the process started after World War II. depicted in Figure 1. The terms shown in
Large, complex post-war development this figure are explained in the following
projects such as the first U.S. ballistic paragraphs.
missiles and NASA's Apollo program exhib- 1. Project and Mission Requirements/
ited the characteristics which created the Need Definition can also be termed as "cus-
need for systems engineers. tomer engineering." It is the process by
Among these project characteristics are: which the needs of the customer (the princi-
pal investigator or other significant parties,
• Large design teams with many highly such as Congress or other budgetary author-
specialized designers ity) are determined. This allows the systems
• Many contractors involved, widely sepa- engineer to define requirements for a system
rated geographically, complicating com- that will meet the needs of the customer.
munications
23
1. Project and Mission Requirements/Need Definition
9. Verification and Validation
2. Risk Analysis/Management
8. Technical 3. Systems Analysis

Oversight
7. Configuration 4. Concept
Management Development
5. Derived Requirements Definition

6. Implementation Planning and
Systems Integration
Figure 1 Systems Engineering Cycle
2. Risk Analysis/Management is a 5. Derived Requirements Definition is

continuing process to identify and assess the the process of translating mission and func-
risks involved with the development and tional analysis results, system operational
operation of the system. These include tech- concepts, and the selected system architec-
nical, schedule, cost and organizational ture into a set of system performance and
risks. Following the identification of the interface requirements. At this level, the
risks involved, the system engineer then de- requirements must specify either functional
velops an implementation plan to control or interface criteria only, without presenting
and, if possible, reduce risks. design solutions. This gives the detail
3. Systems Analysis involves under- designers the flexibility needed to arrive at
standing how the key mission and system design solutions that meet the requirements.
functional elements interact. The mission 6. Implementation Planning and Sys-
analysis translates the users' needs into tems Integration is a complex activity
functional/performance requirements and resulting in a coherent, integrated set of
design constraints. A functional analysis implementation tasks and responsibilities
takes these requirements and breaks them for the design, development, fabrication, ver-
down into specific tasks. ification and operation of the required
4. Concept Development is the process of system. It requires negotiation between the
making informed trade-offs among the var- system requirements definition personnel
ious options to select the one that best meets and the system implementation (develop-
the requirements and design constraints. ment) personnel. The plan must also consid-
Preliminary design and performance re- er the project constraints of schedule and
quirements and implementation architec- budget while avoiding unnecessary risk.
ture are the results.
24
WHAT IS A SYSTEM?
7. Configuration Management activities systems engineer should view these changes

ensure that controlled definition of all as a normal part of the design process. Avoid
engieering documentation is maintained and the tendency to view the Systems Require-
correct information is distributed to all ments Specification as something, once base-
appropriate parties in a timely manner. This lined, that is final and unchangeable.
is one of the most important responsibilities 9. During the Verification and Valida-
of the systems engineering organization. On tion portion of the development activity, the
larger programs that have large numbers of characteristics and performance of the sys-
people involved, this process becomes even tem are compared to the requirements and
more critical. This activity is also the mecha- specifications. Tests, analyses and demon-
nism by which the system development strations are performed to verify that the
process is documented (i.e., design knowl- hardware and software satisfactorily meet
edge capture). the performance requirements of the system

Configuration Management establishes specifications.
the system to control the requirements and
configuration of hardware and software, NASA PHASED PROJECT DESCRIPTION
evaluate changes, and maintain the defini-
tion of the configuration via baselined docu- In the planning of major projects, critical
mentation and released drawings. requirements must be well defined and the
8. Technical Oversight serves two func- necessary technology must be available. If
tions. First, it ensures that all the subsys- these criteria are met, there will be an ac-
tems work together. Second, it implements ceptable level of risk in meeting technical
mechanisms to guarantee that the developed goals with reasonable cost and schedule.
and documented architectural concept is not To ensure that the program is at a proper
inadvertently changed during the develop- level of maturity when Congress approves
ment process. This allows the developer to major funding for design and development,
certify that the system, which is ultimately projects go through various phases of analy-
tested, will meet the customer's require- sis and definition. There are five phases in
ments. Technical oversight consists of the the life cycle of a typical successful project:
technical reviews and audits that gather pre-Phase A (concept study), Phase A
consensus from all parties involved to ascer- (preliminary analysis), Phase B (definition),
tain that the effort at any given time is Phase C (design) and Phase D (development/
correct and adequately planned for the operations). Depending on the complexity of
continuance of the work. the system, funding availability and launch
A specific task for the systems engineer schedules, a project may combine phases or
to perform is assuring that the systems re- add intermediate phases. Common
quirements are understood and correctly variations would include combining pre-
implemented by the design organizations. Phase A and Phase A, adding an advanced
This responsibility requires the systems development phase between Phase B and
engineer to work closely with the design Phase C, combining Phase C and Phase D
organizations throughout the program. At into Phase C/D, or moving operations out of
the same time, the systems engineer must Phase D into a separate phase. As a further
recognize that the initial set of systems example, the Space Shuttle program had
requirements will not be perfect. During both a Phase B' (B prime) and Phase B" (B
design evolution or because of the inability of Double-prime) in order to further refine the
a subsystem to meet its intended functional definition and requirements of the system
requirements, changes in the systems before proceeding into Phase C. Figure 2
requirements will be necessary, and the depicts a typical phased project flow in which
MAJOR MANAGEMENT DECISIONS
_I) _¢{2)
PRE-PHASE AJ PHASE D
PHASE A PHASE B PHASE C
PRELIMINARY DEVELOPMENT/
DESIGN DESIGN
ANALYSIS OPERATIONS
• Develop Project • Refine Selected • Develop Detail of • Developand Test

Objectives Alternative Concepts Selected Concept • Manufacture
• Assess Feasibility • Conduct Systems • Develop Specific • Checkout
• Identify Research and Analysis Requirements and
• Operate
Advanced Technology • Develop Preliminary Design Specifications
• Evaluate
Requirements Requirement and Design • Develop Plans for
• Distribute Results
• Identify Support Specifications Manufacturing, Testing,
Requirements Areas • Define Support Operations, Supporting

Requirements Systems, Facilities, etc.
• Develop Gross Plans for
Implementation • Assess Preliminary • Initiate Required
• Perform Trade-Off Manufacturing and Test Long Lead Advance

Development and Define
Analysis Requirements
Plan for Supporting
• Identify Favorable and • IdentifyAdvanced
Development
Unfavorable Factors Technology and
Advanced Development • Develop Schedules and
• Define Relationships to Estimates of Costs
Requirements
Programs
• Assess Costs and • Refine Management and
• Perform Cost Analysis
Schedules Procurement Plans
• Define Management
and Procurement
Approaches
• Perform Trade-off
Analysis
• Perform Operation
• Feasible Project Concepts for • Preliminary Design and • Project Design and • Completed Project
Detailed Study Specifications Specification including
Man ufacture Test and
• Preliminary Schedule,
Resource and Management Operation Plans
Plans • Schedule Resources
• WBS Management and
Procurement Plans
(1)Missionneed statementapproved
(2)Missionneed statementreaffirmed Source: MM7120.2, Project Management Handbook
Figure 2 NASA Program Phases
pre-Phase A has been combined with decision points. Note that this description
Phase A. pertains to the typical program, in which
Safety is a critical systems engineering NASA contracts with industry to do the
function that must be considered during all Phase C/D activity. Other types of programs
program phases and in all studies and analy- include small, contracted efforts, as well as
ses. In short, although safety is organization- both large and small in-house programs
ally the responsibility of S&MA, it is a where NASA may retain all or part of the
responsibility of all program participants design and development responsibility.
and should be a primary consideration The typical program review phasing
throughout the systems engineering process. includes many more activities and formal
Figure 2 shows the major activities in reviews than are shown in Figure 2. For
each phase, as well as the outputs and major completeness, these are introduced here and
26
WHAT ISA SYSTEM?
PRR PDR CDR AR
Analysis Phase B
T
Design Development/Operation
Preliminary
Phase A Definition T Phase C Phase D
xx
I Final Flight
Concept Requirements Preliminary
Definition Generation _ Design Fabrication VerificationIntegration Operation Analysis
Design
Launch/Vehicle/Payloads
IPL IPL IPL IPL IPL IPL

ATP RR PDR CDR GOR FOR mR
.V-7 x_7 X-7
Miasion
Interface Final Verification & Ground &
Definition Design Integration Flight
efinition Operations
Space System Carrier
Notes: PRR - Preliminary Requirements Review RR- RequirementsReview

PDR- Preliminary Design Review GOR- Ground OperationsReview
CDR- Critical Design Review FOR -FlightOperationsReview
AR- Acceptance Review IRR- Integrated
Readiness Review
ATP- Authority to Proceed FRR- FlightReadinessReview
IPL- Integrated Payload
Figure 3 Typical Program Review Phasing
shown in Figure 3. This figure also serves to year period is used to execute the definition
relate the major reviews to the project phase (Phase B) and prepare the request for
phases and to show the more detailed inte- proposal (RFP) for Phase C/D. The new start
gration activities associated with attached approval process includes a definition review
payloads and Spacelab-kinds of experiments. or non-advocate review (NAR) generally con-
At MSFC, the Program Development ducted during the Phase B activity at a time
(PD) Directorate is responsible for nurturing when the project manager, Center manage-
new projects from idea conception through ment, and Headquarters program office
concept definition supporting preliminary deem appropriate. Results of the NAR are
design. Systems engineering is emphasized factored into the Phase C/D RFP, as well as
and utilized throughout this process, both in- the budget approval process. Note that this
house and during contracted studies. Typi- timeline pertains principally to large pro-
cally, concepts that have matured through grams which include in-house and contract-
this process and gained Congressional new ed efforts. The timeframe could be much
start approval to become official projects are shorter for smaller projects such as experi-
then moved into project offices. The new ments. Figure 4 shows the overall systems
start review and approval process begins ap- engineering process flow in Program Devel-
proximately two years in advance of Phase opment (PD).
C/D authority to proceed (ATP) at which In the course of developing the pre-
point funds are applied to begin a major liminary systems requirements and the
design and development effort. That two- conceptual design, PD uses many of the same
READINGS IN" SYSTEMS ENGINEERING
Operations Planmng
Planning and
Mission Analysis
Planning and Analyms
Planning Systems Analysis Applications
I
"_[
r
Project Planmng I ,
la- _l_ Budget Planning
I Program
Planning and Implementations -_ Feasibility and Definition I _ II Concept Definition &
Studi es I _'_l Desi gn
Manpower Planning"
and Analysis
Pr_,ra m Control
Preliminary Systems Preliminary
-l_[ Requirements
Program/Science I Requirements Desig.
System_Subsystems
Analysis &Trades t
[ Advanced
Requirements
Development I
Cost Modeling &
Supporting/Advanced Research Estimating
and Technology
Headquarters Approval Lead to

Program Initiation Agreement
Figure 4 Systems Engineering Process Flow in Program Development
analysis tools and techniques that are em- further study can come from a variety of
ployed by Science & Engineering (S&E) in sources: industry, the scientific community,
later program phases. The principal differ- university and research centers, MSFC con-
ences in the outputs of the two organizations tractors and associates, or even from within
are the quantity, format and maturity of the MSFC itself. Typically, such ideas receive a
documentation and the level of detail in the top-level examination by cognizant
analyses. In summary, the analyses and MSFC/PD personnel. A quick assessment of
trade studies by S&E are to refine, not re- objectives, requirements and the total mis-
peat, the concepts developed by PD in sup- sion concept is performed. Often, new ideas
port of design implementation. PD develops are shared with colleagues through propos-
the conceptual approach and S&E develops als (either in response to an RFP or unsolicit-
the design implementation. ed), technical papers at professional society
meetings, or "white papers" propounding the
PRE-PHASE A (CONCEPT STUDY) new idea/concept. From an MSFC in-house
weeding out process, concepts are identified
A pre-Phase A study may be accomplished for further (Phase A) study.
within the engineering capability of Pro- System functional concept trades are per-
gram Development or contracted with formed during the pre-Phase A period,
funding from one of the major NASA Head- generally at a fairly cursory level of detail.
quarters offices. Successful results from this This process eliminates architectures that
study would provide justification to initiate a are too costly or time-consuming to develop.
Phase A study or additional pre-Phase A They are conducted at a level sufficient to
studies. The genesis of new ideas requiring support the definition of the top-level system
28
WHAT IS A SYSTEM?
requirements. Architectural options are the database discussed above. The has access to
result. Some of the primary sources for this several cost estimating systems, both
identification of concepts include brain- government and commercial. One example is
storming, past experience, examination of the GE/RCA Price Model. Each model is
other systems and intuition. unique with special capabilities and limita-
Cost estimates are developed in pre- tions. Complexity factors and Cost Estimat-
Phase A and are usually at a very prelimi- ing Relationships are applied to the
nary level due to the lack of detailed systems estimating software using system weight as
definition. These estimates are based pri- the independent variable. A factor is applied
marily on parametrics adjusted for the new to the hardware/software costs to account for
program, taking into account differences in wraparounds such as project management,
mission, size, complexity and other factors. test and verification, percent new design,
operational complexity, hardware complex-
PHASE A (PRELIMINARY ANALYSIS) ity, similarity to other projects or develop-
ment activities and others. As each system is
A Phase A study is the preliminary analysis defined in more detail and the system weight
of a space concept. These concepts could have is further refined, the cost estimates become
come from a pre-Phase A study or from other more realistic and provide a higher confi-
sources within or external to NASA. The ma- dence level in the results.
jority of concepts that are studied at MSFC A cost/risk analysis and assessment is
are assigned by NASA Headquarters and usually completed near the end of each
funded accordingly. Documentation in this Phase A study. The analysis is accomplished
Phase usually consists of study reports and with special software that uses statistical
briefing charts. techniques, including a Monte Carlo simula-
Schedules are developed during Phase A tion. The results predict the probability of
studies by Program Development in conjunc- completing the program within the estimat-
tion with the organization performing the ed cost. A risk assessment, which follows the
study (contractor, PD, S&E). The schedules analysis, should identify areas of high risk
include an overall program schedule pro- that require further cost analysis or possibly
vided by MSFC and a detailed technical further trade studies to look at alternate sys-
schedule developed by the contractor. tems that would lower the potential costs
The overall program schedule depicts im- without sacrificing technical capability.
portant milestones that establish the start As part of the study activity, the contrac-
and finish dates of each study phase, includ- tor provides a detailed risk analysis and
ing design, development, launch, and oper- assessment to establish a high level of confi-
ations. Programmatic milestones are also dence for the program cost. The cost estimate
shown. These are dependent on the federal established during this phase will provide
budget cycle plus proposal preparation and NASA Headquarters with the funding
evaluation time. The contractor schedule requirements to be approved by Congress
depicts the major activities and phasing before the development program can begin.
required to develop the hardware in time to The processes occurring during Phase A
meet the scheduled launch date. Since this is include:
a concept study, the detail schedule is still at
a relatively high level and would not show • Development of project objectives
activity below the system level. • Assessment of project feasibility
Cost estimates developed during Phase A • Identification of research and advanced
are generated using a parametric cost technology requirements
analysis system in conjunction with the cost
29
• Identification of support requirements are Level I (NASA Headquarters) require-

areas ments from preliminary activities.
• Performance of trade-off analyses Level I requirements are broad mission
• Identification of favorable and unfavor- needs and objectives. Occasionally, there
able factors may be some Level 1I (project office level) re-
• Definition of relationships to other quirements at this time.
programs The mission need determination is the
• Selection of systems concepts first step in a multifaceted preliminary con-
• Identification of maintenance, technology cept definition activity. This is the step that
insertion, and disposal concepts of is first performed at a NASA Headquarters
payload and orbital debris or Center level (or industry, university, etc.)
• Environmental Impact Analysis. and is the precursor to concept development.
The mission need determination is that part
The outputs from Phase A, which become the of early mission planning that identifies a
inputs to Phase B, are in the form of reports scientific knowledge need or gap that could
or annotated briefing charts and include in- be met with some kind of NASA sponsored
formation on: activity. A set of Level I requirements is gen-
erally developed during or just prior to the
• Concept definition activities described in the following para-
• Preliminary system requirements graphs.
• Preliminary configuration layouts A feasibility analysis is conducted to de-
• Point designs termine the viability of the project. The
• Preliminary implementation plans study report usually includes requirements,
• Preliminary schedules objectives, problems, opportunities and costs.
• Preliminary cost estimates A utility analysis is then conducted to de-
• Environmental impact. termine the value of a project. The following
criteria may be considered during this study:
PHASE B (DEFINITION AND the needs met, the scientific knowledge ac-
PRELIMINARY DESIGN) quired, the political benefits, or potential
spinoffs and applications.
This phase of the project consists of the re- Certain satellites and/or instruments are
finement of preliminary requirements, cost selected for a more detailed level of design.
estimates, schedules and risk assessments The Preliminary Design Office of Program
prior to starting final design and develop- Development performs these studies. This
ment. office is a miniature replication of the capa-
Once the feasibility of an idea is estab- bilities of the laboratories at MSFC: Propul-
lished, the concept definition phase is begun sion, Guidance, Navigation and Control,
to explore alternatives to meet the docu- Electrical Power, Avionics, Structures,
mented mission need. Competition and inno- Operations, etc. One difference is the empha-
vation should be employed to ensure that a sis by Program Development in developing
wide variety of alternatives are identified credible cost estimates. Cost is an important
and examined. Modeling and computer ana- differential, but often other factors, such as
lysis are required to assess the best concepts. mission risk or incompatibility with other
The goal of a concept definition activity is instruments that may be grouped on a com-
to determine the best and most feasible mon satellite, may predominate.
concept(s) that will satisfy the mission and Throughout the Phase B period the con-
science requirements. Generally, the re- cepts that were developed during Phase A
quirements available at this point in time are iteratively reviewed and analyzed. Using
3O
WHAT IS A SYSTEM?
trade study techniques, the concepts' capa- the Phase A overall program schedules. In
bilities are compared to the system require- addition, other schedules are developed that
ments. Those concepts that consistently include Phase C and D procurement strate-
satisfy the requirements are identified and gies, cost phasing and project manning
refined. Any concepts that do not meet requirements. The study contractor sched-
performance and other requirements are ules are expanded to lower levels of the work
scrutinized very closely for possible elimina- breakdown structure (WBS) to include
tion. Following the examination of those subsystem development, program manage-
that do not perform well, assessments are ment, manufacturing, verification, logistics
made regarding their augmentation to dis- planning, operations planning and other
cover the degree of change necessary to bring technical areas. The schedule detail would
their performance into scope. The concepts show the phasing of all major activities
that have to change too much or would through launch and the follow-on operations.
experience severe budgetary and/or schedule As in Phase A, the typical documentation
impacts are deleted from the concept defini- of this phase consists of reports and briefing
tion and analysis cycle. This allows the ana- charts.
lysts' energies to be focused on those concepts The processes occurring during Phase B
that are valid and workable. include:
These trade studies provide a more de-
tailed look at the architectural concepts and • Refinement of selected alternative
result in a narrowing of the field of candi- concepts
dates. Trades performed during this time • Performance of trade-off analyses
consider such things as cost, schedule, life- • Performance of system analyses and
time and safety. The evaluation criteria used simulations
to assess alternative concepts are developed • Definition ofpreliminary system and
to a finer level of detail than for earlier sys- support requirements
tem trades. • Definition and assessment of preliminary
Cost estimates from Phase A are refined manufacturing and test requirements
as further detailed requirements are identi- • Identification of advanced technology and
fied during Phase B. The cost estimating advanced development requirements for
process is still dependent on parametric ana- focused funding
lysis. The Program Development cost office • Refinement of preliminary schedules
works closely with the study contractor in • Refinement ofpreliminarycost estimate
evaluating costing methodology and continu- and trade study results which support
ously compares government cost estimates selection of baseline for cost estimate
with those of the study contractor. Should a • Assessment of technical, cost, and sched-
large discrepancy occur, the assumptions ule risks
and schedule inputs of the study contractor • Assessment and refinement of the Mis-
are examined. If this examination yields val- sion Need Statement.
id assumptions and schedules, the NASA
estimates are adjusted. The cost estimation The outputs from Phase B, which become the
process goes through continuous iterations inputs to Phase C, may include (in the form
during the study to reflect the evolution of of study reports and annotated briefing
detail resulting from trade studies. charts) information related to:
Schedules are developed during Phase B
by the task team program control personnel • Preliminary WBS
and by the study contractors. Schedules de- • System requirements
veloped by the task team are expanded from • Preliminary interface requirements
PHASE A PHASE B PHASE C PHASE D

Preliminary Development/
Analysis Definition Design Operations
PROGRAM PDO ......

DEVELOPMENT TASK TEAM _" "_"_""_'_-- -_. _ ..._
s_ -I
PROGRAM/PROJECT OFFICES
SCIENCE & ENGINEERING In-depth Technical Support
INSTITUTIONAL & PROGRAM SUPPORT Support& Services

i [ I
Source: PD Lead Engineer's Guide
Figure 5 MSFC Support Relationships in Project Phases
• Management and procurement ap- chief engineer is often the deputy to the task
proaches team manager and is usually the first Sci-
• Program Implementation Plans ence and Engineering representative sub-
• Request for Proposal (RFP) inputs, where stantially involved in the process. The chief
applicable. engineer's office has personnel resources
available to support the project as needed
Phase B is normally the final phase of during the study. Additional engineering
activity within Program Development. A support from S&E may be used at the discre-
separate core of people is selected to form a tion of the chief engineer. The chief engineer
task team to manage the Phase B contract. plays a key role in determining the state of
At the beginning of Phase B, a chief engineer technical maturity of the project for starting
is appointed to the task team (or project the design and development phase.
office) to provide consultation to the task At the conclusion of Phase B, the task
team manager on all related engineering team is converted to a project office, and it is
matters. The chief engineer also helps no longer under the direction of program
ensure that the study contractor uses accept- development. On large projects, such as
able engineering practices and sound Space Station, a project office might be
judgment during the course of the study. The created prior to Phase B; in that case,
32
WHAT IS A SYSTEM?
Program Development (PD) support becomes PHASE C (DESIGN)

minimal (such as cost estimating and limited
programmatics) and S&E plays a major role This phase requires Congressional budget
in the Phase B engineering activities. approval for projects large enough to be
At MSFC, it is not uncommon to have separate line items in the NASA budget
more than one directorate providing submission. Funding must be approved and
engineering or technical support to a project available at the start of Phase C. Detailed
throughout its life cycle. The transition of design is accomplished and plans are refined
engineering support is depicted in Figure 5. for final development, fabrication, test and
Figure 5 shows that Program Develop- operations.
ment typically performs most, if not all, of
the technical support during Phase A. As the The processes occurring during Phase C in-
project life cycle evolves, the S&E Director- clude:
ate takes on a larger and larger role as PD's
involvement tapers off. The exact point at • Refinement of work breakdown structure
which S&E gets involved varies depending • Development of Systems Requirements
on the size and priority of the project at Specification
MSFC, as well as the availability of S&E • Development of design and contract end
manpower resources. In every case, however, item specifications
Phase C and D activities are exclusively the • Development of interface requirements
domain of S&E. documents
The extent of information and the level of • Completion of preliminary and detail
detail available at the end of Phase B to design
begin the Phase C design are variable and • Development ofpreliminary interface
become a function of the time and money control documents (ICDs)
made available to the PD organization for • Performance of detailed system analyses
the conduct of Phase B studies. As a result, • Development of manufacturing, testing
significant efforts may be needed at the verification, integration, operations, sup-
beginning of Phase C to refine many of the porting systems and facilities plans
Phase B analyses. • Definition of a development plan
The hand-over of technical responsibility • Refinement of schedules and cost esti-
from PD to S&E is an interface which mates
requires a great deal of attention to mini- • Refinement of management and procure-
mize transition problems and project ment plans.
disruptions. A key issue to be addressed is
the type and content of documentation The outputs from Phase C, which become the
produced in Phases A and B. Since these inputs to Phase D, include:
early phases typically have limited funding
and PD's manpower resources are limited, • Updated system requirements documen-
requirements and specifications resulting tation
from Phase B may require substantial • Updated detail design and CEI specifica-
refinement and rework by S&E at the tions
beginning of Phase C. It is important that • Baseline.
Phase C planning and schedules account for
this activity.
33
It is typically at the beginning of Phase C, • Retrieval or disposal of payload and orbit-

when industry is heavily involved in design al debris.
and project funding is increased dramatical- The outputs from Phase D include:
ly, that many formal documentation require-
ments are contractually imposed. This can • A successful mission,
contribute to large cost increases over • Documentation and evaluation of the re-
previous estimates in Phases A and B, and sults and anomalies
dictates the need for early inputs from the • Documentation oflessonslearned.
S&E engineering organization to assure that
design and performance requirement specifi- In the early days of spaceflight, MSFC
cations and data requirements are incorpo- provided expendable propulsion systems, so
rated into initial cost estimates. most project activity terminated when
launch operations were complete. As the
PHASE D (DEVELOPMENT/OPERATIONS) mission of MSFC evolved into payloads and
experiments, its role in the area of mission
During this phase of a project, flight hard- operations and maintenance greatly expand-
ware and software are developed, manufac- ed and now provides an important function
tured/coded, tested and qualified for flight. in present projects such as Spacelab, the Na-
In addition, support is provided for the tional Space Transportation System, Hubble
follow-on flight operations. Space Telescope, the Advanced X-Ray Astro-
physics Facility, and Space Station Freedom.
The processes occurring during Phase D in- These programs involve 15 to 30 years of
clude: technology insertion, operations and main-
tenance activities that would justify a sepa-
• Development and test of prototype and rate independent phase in their life cycles.
protoflight hardware At MSFC, the design phase is normally
• Verification/Validation - qualification of combined with the development and oper-
hardware and sot_ware for flight ations phase to form a Phase C/D. The result-
• Manufacture and integration offlight ing contract takes the Phase B data, refines
hardware it into a final design, develops and fabricates
• Checkout offlight systems the hardware, tests and flight qualifies it,
• Launch operations and supports the flight and mission
• Flight operations operations.
34
MANAGEMENT ISSUES IN SYSTEMS ENGINEERING
N 9 3 #2:-Ztki 8 2
MANAGEMENT ISSUES IN SYSTEMS ENGINEERING /2-ff -
by Robert Shishko and Robert G. Chamberlain /9 ,/'_,
with contributions by (-.
Robert Aster, Vincent Bilardo, Kevin Forsberg, Hal Mooz, Lou Polaski and Ron Wade
When applied to a system, the doctrine of "voice of the buyer" is heard. Determining
successive refinement is a divide-and- the right requirements -- that is, only those
conquer strategy. Complex systems are suc- that the informed buyer is willing to pay for
cessively divided into pieces that are less -- is an important part of the systems engi-
complex, until they are simple enough to be neer's job. Second, system requirements also
conquered. This decomposition results in communicate to the design engineers what to
several structures for describing the product design and build (or code). As these require-
system and the producing system ("the ments are allocated, they become inexorably
system that produces the system"). These linked to the system architecture and prod-
structures play important roles in systems uct breakdown, which consists of the hierar-
engineering and project management. Many chy of project, systems, segments, elements,
of the remaining sections in this chapter are subsystems, etc.
devoted to describing some of these key The work breakdown structure (WBS) is
structures. also a hierarchical structure that contains
Structures that describe the product sys- the pieces of work necessary to complete the
tem include, but are not limited to, the re- project. Each task in the WBS should be
quirements tree, system architecture and traceable to one or more of the system re-
certain symbolic information such as system quirements. Schedules, which are structured
drawings, schematics, and data bases. The as networks, describe the time-phased activi-
structures that describe the producing sys- ties that result in the product system in the
tem include the project's work breakdown, WBS The cost account structure needs to be
schedules, cost accounts and organization. directly linked to the work in WBS and the
These structures provide different perspec- schedules by which that work is done.
tives on their common raison d'etre: the The project's organizational structure
desired product system. Creating a funda- describes clusters of personnel assigned to
mental harmony among these structures is perform the work. These organizational
essential for successful systems engineering structures are usually trees. Sometimes they
and project management; this harmony are represented as a matrix of two interlaced
needs to be established in some cases by one- trees; one for line responsibilities, the other
to-one correspondence between two struc- for project responsibilities. In any case, the
tures, and in other cases, by traceable links structure should allow identification of re-
across several structures. It is useful, at this sponsibility for each WBS task.
point, to give some illustrations of this key Project documentation is the product of
principle. particular WBS tasks. There are two funda°
System requirements serve two purposes mental categories of project documentation:
in the systems engineering process. First, baselines and archives. Each category con-
they represent a hierarchical description of tains information about both the product
the buyer's desired product system as under- system and the producing system. The base-
stood by the systems engineer. The interac- line, once established, contains information
tion between the buyer and systems engineer describing the current state of the product
to develop these requirements is one way the system and producing system resulting from
35
all decisions that have been made. It is usu- priate concurrent engineering. Each one of
ally organized as a collection of hierarchical these systems engineering functions re-
tree structures, and should exhibit a signifi- quires application of technical analysis skills
cant amount of cross-linking. The archives and tools to achieve the optimum system
should contain all of the rest of the project's solution.
information that is worth keeping, even if The techniques used in systems engineer-
only temporarily. The archives should con- ing management include baseline manage-
tain all assumptions, data and supporting ment, requirements traceability, change
analyses that are relevant to past, present control, design reviews, audits, document
and future decisions. Inevitably, the struc- control, failure review boards, control gates
ture (and control) of the archives is much and performance certification.
looser than that of the baseline, though cross The Project Plan defines how the overall
references should be maintained where feasi- project will be managed to achieve the pre-
ble. established requirements within defined pro-
The structure of reviews (and their asso- grammatic constraints. The Systems Engi-
ciated control gates) reflect the time-phased neering Management Plan (SEMP) is the
activities associated with the realization of subordinate document that defines to all
the product system from its product break- project participants how the project will be
down. The status reporting and assessment technically managed within the constraints
structure provides information on the established by the Project Plan. The SEMP
progress of those same activities. On the fi- communicates to all participants how they
nancial side, the status reporting and assess- must respond to pre-established manage-
ment structure should be directly linked to ment practices. For instance, the SEMP
the WBS, schedules and cost accounts. On should describe the means for both internal
the technical side, it should be linked to the and external (to the project) interface con-
product breakdown and/or the requirements trol.
tree.
Role of the SEMP
MANAGING THE SYSTEMS ENGINEERING
PROCESS: THE SYSTEMS The SEMP is the rule book that describes to
ENGINEERING MANAGEMENT PLAN all participants how the project will be tech-
nically managed. The responsible NASA
Systems engineering management is a tech- Center should have a SEMP to describe how
nical function and discipline that ensures it will conduct its technical management,
that systems engineering and all other tech- and each contractor should have a SEMP to
nical functions are properly applied. describe how it will manage in accordance
Each project should be managed in accor- with both its contract and NASA's technical
dance with a project cycle that is carefully management practices. Since the SEMP is
tailored to the project's risks. While the pro- project- and contract-unique, it must be up-
ject manager concentrates on managing the dated for each significant programmatic
overall project cycle, the project-level or lead change or it will become outmoded and un-
systems engineer concentrates on managing used, and the project could slide into an un-
its technical aspect. This requires that the controlled state. The NASA Center should
systems engineer perform (or cause to be per- have its SEMP developed before attempting
formed) the necessary multiple layers of to prepare a "should-cost" estimate, since ac-
decomposition, definition, integration, ver- tivities that incur cost, such as technical risk
ification and validation of the system, while reduction, need to be identified and described
orchestrating and incorporating the appro- first. The contractor should have its SEMP
36
developed during the proposal process (prior • The role ofsystemsengineering

to costing and pricing) because the SEMP de- • The role of design engineering
scribes the technical content of the project, • The role of specialty engineering
the potentially costly risk management ac- • Applicable standards
tivities, and the verification and validation • Applicable procedures and training
techniques to be used, all of which must be • Baseline control process
included in the preparation of project cost • Change control process
estimates. • Interface control process
The project SEMP is the senior technical • Controlofcontracted (or subcontracted)
management document for the project; all engineering
other technical control documents, such as • Data control process
the Interface Control Plan, Change Control • Make-or-buy control process
Plan, Make-or-Buy Control Plan, Design • Parts, materials and process control
Review Plan, Technical Audit Plan, etc., de- • Quality control
pend on the SEMP and must comply with it. • Safety control
The SEMP should be comprehensive and • Contamination control
describe how a fully integrated engineering • EMI/EMC
effort will be managed and conducted. • Technical performance measurement
• Control gates
Contents of the SEMP • Internal technical reviews
• Integration control
Since the SEMP describes the project's tech- • Verification control
nical management approach, which is driven • Validation control.
by the type of project, the phase in the project
cycle, and the technical development risks, it Part II m Systems Engineering Process.
must be specifically written for each project This section should contain a detailed de-
to address these situations and issues. While scription of the process to be used, including
the specific content of the SEMP is tailored the specifictailoring of the process to the re-
to the project, the recommended content is quirements of the system and project; the
listed below. procedures to be used in implementing the
process; in-house documentation; the trade
Part I -- Technical Program Planning study methodology; the types of mathemat-
and Control. This section should identify ical and/or simulation models to be used for
organizational responsibilities and authority system cost-effectiveness evaluations; and
for systems engineering management, in- the generation of specifications.
elude control of contracted engineering; lev- This section should describe the:
els of control established for performance
and design requirements, and the control • System decomposition process
method used; technical progress assurance • System decomposition format
methods; plans and schedules for design and • System definition process
technical program reviews; and control of • System analysis and design process
documentation. • Trade study process
This section should describe: • System integration process
• System verification process
• The role of the project office • System qualification process
• The role of the user • System acceptance process
• The role of the Contracting Office Techni- • System validation process
cal Representative (COTR) • Risk management process
37
• Life-cycle cost management process the project that ultimately determines the
• Use of mathematical models length and cost of the project. The develop-
• Use of simulations ment of the programmatic and technical
• Specification and drawing structure management approaches of the project re-
• Baseline management process quires that the key project personnel develop
• Baseline communication process an understanding of the work to be per-
• Change control process formed and the relationships among the var-
• Tools tobe used. ious parts of that work. (See sections on work
breakdown structures and network sched-
Part III -- Engineering Specialty Inte- ules.)
gration. This section of the SEMP should de-
scribe tbe integration and coordination of the
SEMP Lessons Learned from DoD Experience
efforts of the specialty engineering disci-
plines into the systems engineering process • A well-managed project requires a
during each iteration of that process. Where coordinated SEMP that is used through
there is potential for overlap of specialty ef- the project cycle.
forts, the SEMP should define the relative • A SEMP is a living document that must be
updated as the project changes and kept
responsibilities and authorities of each.
consistent with the Project Plan.
This section should contain the project's • A meaningful SEMP must be the product
approach to: of experts from all areas of the project.
• Projects with little or insufficient systems
• Concurrent engineering engineering discipline generally have
• The activity phasing of specialty disci- major problems.
• Weak systems engineering, or systems
plines
engineering placed too low in the
• The participation of specialty disciplines organization, cannot perform the functions
• The involvement of specialty disciplines as required.
• The role and responsibility of specialty • The systems engineering effort must be
disciplines skillfully managed and well
communicated to all the individuals
• The participation of specialty disciplines
• The systems engineering effort must be
in system decomposition and definition
responsive to both the customer and the
• The role of specialty disciplines in verifi- contractor interests.
cation and validation
• Reliability
• Producibility The SEMP's development requires contri-
• Human engineering butions from knowledgeable programmatic
• Maintainability and technical experts from all areas of the
• Safety project that can significantly influence the
• Survivability/vulnerability project's outcome. The involvement of recog-
• Integrated logistics nized experts is needed to establish a SEMP
• Quality assurance. that is credible to the project manager and to
secure the full commitment of the project
Development of the SEMP team.
The SEMP must be developed concurrently Managing the Systems Engineering

with the Project Plan. In developing the- Process: Summary
SEMP, the technical approach to the project,
and hence the technical aspect of the project Systems engineering organizations, and spe-
cycle, are developed. This becomes the keel of cifically project-level systems engineers, are
38
responsible for managing projects through WBS should be a product-based, hierarchical

the technical aspect of the project cycle. This division of deliverable items and associated
responsibility includes managing the decom- services. As such, it should contain the pro-
position and definition sequence, managing ject's product breakdown structure (PBS),
the integration, verification and validation with the specified prime product(s) at the
sequence and controlling the technical top, and the systems, segments, subsystems,
baselines of the project. Typically, these etc. at successive lower levels. At the lowest
baselines are the functional, "design-to," level are products such as hardware items,
"build-to" (or "code-to"), "as-built" (or "as- software items and information items (e.g.,
coded"), and "as-deployed." Systems engi- documents, databases, etc.) for which there
neering must ensure efficient and logical is a cognizant engineer or manager. Branch
progression through these baselines. points in the hierarchy should show how the
Systems engineering is responsible for PBS elements are to be integrated. The WBS
system decomposition and design until the is built from the PBS by adding, at each
design-to specifications of all lower level con- branch point of the PBS, any necessary ser-
figuration items have been produced. Design vice elements such as management, systems
engineering is then responsible for develop- engineering, integration and verification
ing the build-to and code-to documentation (I&V), and integrated logistics support (ILS).
that complies with the approved design-to If several WBS elements require similar
baseline. Systems engineering audits the equipment or software, then a higher level
design and coding process and the design en- WBS element might be defined to perform a
gineering solutions for compliance to all block buy or a development activity (e.g.,
higher level baselines. In performing this "System Support Equipment"). Figure 1
responsibility, systems engineering must shows the relationship between a system, a
ensure requirements traceability and docu- PBS and a WBS.
ment the results in a requirements traceabil- A project WBS should be carried down to
ity/verification matrix. the cost account level appropriate to the
Systems engineering is also responsible risks to be managed. The appropriate level of
for the overall management of the integra- detail for a cost account is determined by
tion, verification and validation process. In management's desire to have visibility into
this role, systems engineering conducts Test costs, balanced against the cost of planning
Readiness Reviews and ensures that only and reporting. Contractors may have a Con-
verified configuration items are integrated tract WBS (CWBS), which is appropriate to
into the next higher assembly for further the contractor's needs to control costs. A
verification. Verification is continued to the summary CWBS, consisting of the upper lev-
system level, after which system validation els of the full CWBS, is usually included in
is conducted to prove compliance with user the project WBS to report costs to the con-
requirements. tracting agency.
Systems engineering also ensures that WBS elements should be identified by ti-
concurrent engineering is properly applied tle and by a numbering system that performs
through the project cycle by involving the the following functions:
required specialty engineering. The SEMP is
the guiding document for these activities. • Identifies the level of the WBS element
• Identifies the higher level element into
THE WORK BREAKDOWN STRUCTURE which the WBS element will be integrat-
ed
A WBS is a hierarchical breakdown of the • Shows the cost account number of the
work necessary to complete a project. The element.
39
System Components !,subsystems) other interested parties. It fully describes

held together by "glue (integration) the products and/or services expected from
Subsystem
each WBS element.
A
The whole does

This section provides some techniques for
more than the developing a WBS, and points out some mis-
sum of its parts
Subsystem
takes to avoid.
Sub C
_y_|em
B Subsystem
D Role of the WBS
A product-based WBS is the organizing

_S_tr BPr°duct
structure for:
reakdown
ucture Shows "h
" the components I
from which the • Project and technical planning and sched-
I system was I
J Sy_
uling
• Cost estimation and budget formulation
_1_ (In particular, costs collected in a
tera.., [ formed
product-based WBS can be compared to
,ub- historical data. This is identified as a
Sub-
system primary objective by DoD standards for

A
WBSs.)
Work • Defining the scope of statements of work
Breakdown
The individual system Structure {WBS)
and specifications for contract efforts
components All work • Project status reporting, including sched-
components
necessary to ule, cost and work force, technical perfor-
produce a
complete system mance, integrated cost/schedule data
(such as earned value and estimated cost
_L_
at completion)
• Plans, such as the SEMP, and other docu-
mentation products, such as specifica-
Sub-
system Manage- Systems [&V II.B tions and drawings.

A meat Engin-
eering
Work to produce the It provides a logical outline and vocabulary

individual system
components that describes the entire project and inte-
Work to integrate the
components into a grates information in a consistent way. If
system
there is a schedule slip in one element of a
The whole takes WBS, an observer can determine which other
more work than the
sum of itsparts WBS elements are most likely to be affected.
Cost impacts are more accurately estimated.
Figure 1 The Relationship between a System,
If there is a design change in one element of
a Product Breakdown Structure, and
a Work Breakdown Structure the WBS, an observer can determine which
other WBS elements will most likely be af-
fected, and these elements can be consulted
A WBS should also have a companion WBS for potential adverse impacts.
dictionary that contains each element's title,
identification number, objective, description, Techniques for Developing the WBS
and any dependencies (e.g., receivables) on
other WBS elements. This dictionary pro- Developing a successful project WBS is likely
vides a structured project description that is to require several iterations through the
valuable for orienting project members and project cycle since it is not always obvious at
4O
the outset what the full extent of the work service products provided to external cus-
may be. Prior to developing a preliminary tomers. However, the general concept of a
WBS, there should be some development of hierarchical breakdown of products and/or
the system architecture to the point where a services would still apply.
preliminary PBS can be created. The rules that apply to a development
The PBS and associated WBS can then be WBS also apply to a WBS for an operational
developed level by level from the top down. facility. The techniques for developing a
In this approach, a project-level systems en- WBS for an operational facility are the same,
gineer finalizes the PBS at the project level, except that services such as maintenance
and provides a draft PBS for the next lower and user support are added to the PBS, and
level. The WBS is then derived by adding ap- services such as systems engineering, inte-
propriate services such as management and gration and verification may not be needed.
systems engineering to that lower level. This
recursive process is repeated until a WBS ex- Common Errors in Developing a WBS
ists down to the desired cost account level.
An alternative approach is to define all There are three common errors found in
levels of a complete PBS in one design activ- WBSs:
ity, and then develop the complete WBS.
When this approach is taken, it is necessary Error 1: The WBS describes functions,
to take great care to develop the PBS so that not products. This makes the project man-
all products are included, and all assembly/ ager the only one formally responsible for
integration and verification branches are products.
correct. The involvement of people who will Error 2: The WBS has branch points that
be responsible for the lower level WBS ele- are not consistent with how the WBS ele-
ments is recommended. ments will be integrated. For instance, in a
flight operations system with a distributed
A WBS for a Multiple Delivery Project. architecture, there is typically software asso-
Some of the terms for projects that provide ciated with hardware items that will be inte-
multiple deliveries, are "rapid develop- grated and verified at lower levels of a WBS.
ment," "rapid prototyping" and "incremental It would then be inappropriate to separate
delivery." Such projects should also have a hardware and software as if they were sepa-
product-based WBS, but there will be one ex- rate systems to be integrated at the system
tra level in the WBS hierarchy immediately level. This would make it difficult to assign
under the final prime product(s) that identi- accountability for integration and to identify
fies each delivery. At any point in time there the costs of integrating and testing compo-
will be both active and inactive elements in nents of a system.
the WBS. Error 3: The WBS is inconsistent with
the PBS. This makes it possible that the PBS
A WBS for an Operational Facility. A will not be fully implemented, and generally
WBS for managing an operational facility complicates the management process.
such as a flight operations center is analo- Some examples of these errors are shown
gous to a WBS for developing a system. The in Figure 2. Each one prevents the WBS from
difference is that the products in the PBS are successfully performing its roles in project
not necessarily completed once and then planning and organizing. These errors are
integrated, but are all produced on a routine avoided by using the WBS development tech-
basis. A PBS for an operational facility niques described above.
might consist of information products or
41
I Error 1 I Functions without Products _ Error 2 ] Inappropriate Branches

This WBS describes only This WBS has branch points that are
functions, not the products not consistent with the way the WBS
elements will be integrated
i!_ii!iiiiiiiiiiiiii!i
Error 3 Inconsistency with PBS

This WBS is inconsistent with the
Product Breakdown Structure
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: g:_:::x:::.:, ::_.:::::::::::.

x_::::.::::::::_:p,
>:::_:::;:.::
h:::_ :::::::::_:::::
:::::::::::::.:-:..'::
_.._::::::b_:_':
_::': _:'_:_.::::
:;.::::::_:'_:. :::::::.:'__::'_ :::::::::::::::::::::::::::::::::::::::::::::::::::::::
_ ":::::::: : ::::: _.:: :.:::::> _'_: :::: :::::::::_:::_.:::._._
' :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: <::_:?.._.
:_::.:.:_:
_..::.:: :-:f,:.::: _:_ :::_;::: f_::
::_.,'_:_:::::::::::
:,'.':_ :':-*,i ouosysCem
*:-_,"::-,.-_::•-:•_:'-.:-," P..:-..-.-.<._-_
.-_....... :,'-:-
_:<-:-:-:-:-
-:->:-
----:........ :-:-..:
....... >:-:.
->,':->:.>>>
.>•-_._.:.,:---.'.•-..••.xVi-_,.'l |ii-:-:-:-
-:.:.
•-:---.:z-:........... _-.•---:-•<-:i:.::-_
::::::::::::::::::::::::::::::::::::::::::::::
[ :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:...................... ×_'"
?.".............. :--."C" ? ?-? _"': :" .................... - ....... :::::::::::::::::::::
-: ..:.:._..:-:.,':.:.:,,:_.>_:.:.':_.:o:.:.:.:.:.>:.:._.>_:..'-..i_ .......... ×...:-........ .'.---:.'.'.'.._-_ .................................. _ _............... _................
:-_---'_........................................................ -:-:-:.-'2_
:::::::::::::::::::::::::::::::::::::::::
................ x ......... ::::/'-::":::7":: ........ :_=':: ========================================================================
,:_ ,_ _ iTansml_.er
:.;._ .:_._:_:.:.:._:.:_:+:7..:.:.:.:.:.::.:_._:._>>_:+>>_>_>_×_7.'_7.÷_'_:_/.._:._`:°_:._.:_'_._._._.:_:_ :.:+:+:.:.:..:.',.:....:.:..:.:.:.:.:.;:..,:.:,_:_ r_ i_ r_
;_;_'.::_ _:-_:_:_,<:_:!_:_:!_:_!_..'..:.'-::.,d_-_,.;_:_i_<_,
._._..:&'_:_.:;_;_:_:_;:_:_::
:_:_:_:;:_:;:!:_:::::
:_::_::
_::_:::
_: ::::_i:::_:::_ _:::;:_::::::;.................... ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::::::::::::::::::::: ............. _._,_'_._,_x:_::_$".<._._:_:_3 ..................................... :::::::::::::::::::::::::::::::::::::::::: .................... :.:....:,...:.:.:_/.:.:.:.:..:.:....:. ; ,...:.:.: :.,:.:.,....: :.;.: _:.;.:.:, ..:..:.: ..:.:.:.. ,= 5.,..= 5 =.:5_: i3_:_:_:::::_
,._._-:.:.:*:.:.:-:.>_ ._.:. "-_...,-.-...-...-.-.........- ..-...... ....... ...*_..,.-...-...-.....-..-...-.--.....................,.:....._ ......... >>..7_x<_7..>-_.._7-7.-.-..-.-...........-.-.-_...-.-.-.-.......-.-....-.-..-..-.-...-,..-.-.._:.--
:_2;_>.;_z I_x_._.>._, ,g'::_:_:::_

_:: f_7¢.::::>.
::>:./.:::::_ _::::::::::::::::::::::_::_.:::::_:_:::::::::::P.
::::-'::
::::::::::::
::::::::::::::::
:::::::
::.'::::::::::f.::_:.'._'./-:¥./.
:::::::::
_"./.:_¢.:::
>.y._; _ _22. :3:_x:_ ::::::::::::::::::::::::::::: ::./_:f_,::3:_:
.'._::::::.:
_:;:::):::):::;::,'::-":::::_::
The Work Breakdown Structure The Product Breakdown Structure
Figure 2 Examples of WBS Development Errors
NETWORK SCHEDULING it will take, and how each element of the pro-
ject WBS might affect other elements. A
Products described in the WBS are the result complete network schedule can be used to
of activities that take time to complete. An calculate how long it will take to complete a
orderly and efficient systems engineering project, which activities determine that du-
process requires that these activities take ration (i.e., critical path activities), and how
place in a Way that respects the underlying much spare time (i.e., float) exists for all the
time-precedence relationships among them. other activities of the project. An under-
This is accomplished by creating a network standing of the project's schedule is a
schedule, which explicitly takes into account prerequisite for accurate project budgeting.
the dependencies of each activity on other ac- Keeping track of schedule progress is an
tivities and receivables from outside sources. essential part of controlling the project, be-
This section discusses the role of scheduling cause cost and technical problems often show
and the techniques for building a complete up first as schedule problems. Because net-
network schedule. work schedules show how each activity af-
Scheduling is an essential component of fects other activities, they are essential for
planning and managing the activities of a predicting the consequences of schedule slips
project. The process of creating a network or accelerations of an activity on the entire
schedule can lead to a much better under- project. Network scheduling systems also -A
standing of what needs to be done, how long help managers accurately assess the impact
42
A work flow diagram (WFD) is a graphi-

Critical Path and Float Calculation
cal display of the first three data items
above. A network schedule contains all four
The critical path is the sequence of activities
that will take the longest to accomplish. Activi- data items. When creating a network sched-
ties that are not on the critical path have a cer- ule, graphical formats of these data are very
tain amount of time that they can be delayed un- useful. Two general types of graphical for-
til they, too are on a critical path. This time is mats, shown in Figure 3, are used. One has
called float. There are two types of float, path activities-on-arrows, with products and de-
float and free float. Path float is where a se-
pendencies at the beginning and end of the
quence of activities collectively have float. If
there is a delay in an activity in this sequence, arrow. This is the typical format of the Pro-
then the path float for all subsequent activities gram Evaluation and Review Technique
is reduced by that amount. Free float exists (PERT) chart. The second called precedence
when a delay in an activity will have no effect on diagrams, has boxes that represent activi-
any other activity. For example, if activity A can ties; dependencies are then shown by arrows.
be finished in 2 days, and activity B requires 5
Due to its simpler visual format and reduced
days, and activity C requires completion of both
A and B, then A would have 3 days of free float. requirements on computer resources, the
Float is valuable. Path float should be con- precedence diagram has become more com-
served where possible, so that a reserve exists mon in recent years.
for future activities. Conservation is much less
important for free float.
To determine the critical path, there is first Diagram
Activity-on-Arrow
a "forward pass" where the earliest start time of AI _J_-__A_ ._._____---__- ActivityA has
each activity is calculated. The time when the broken into two
last activity can be completed becomes the end i separate activities.
!
I
point for that schedule. Then there is a "back-
ward pass," where the latest possible start point
_.._._ BSO_
_ __ Activity Description
of each activity is calculated, assuming that the 5 Activity Duration
last activity ends at the end point previously cal- (e.g., days)
culated. Float is the time difference between the

earliest start time and the latest start time of an PrecedenceDiagram
Note:
activity. Whenever this is zero, that activity is Each activity's
on a critical path. A Activity Description description
shouldcontain
[ an action and
the object of
I_ ActivityDuration that action.
(e.g.,
days)
l i
of both technical and resource changes on the L SS5 _ B

cost and schedule of a project. This means that Activity B
can start5 days after
i
ActivityA starts.
Network Schedule Data and Graphical
Formats Figure 3 Activity-on-Arrow and Precedence
Diagrams for Network Schedules
Network schedule data consist of:
The precedence diagram format allows
• Activities for simple depiction of the following logical
• Dependencies between activities (e.g., relationships:
where an activity depends upon another
activity for a receivable) • Activity B begins when Activity A begins
• Products or milestones that occur as a re- (Start-Start, or SS)
sult of one or more activities • Activity B begins only after Activity A
• Duration of each activity. ends (Finish-Start, or FS)
43
• Activity B ends when Activity A ends • Ensuring that the cost account WBS is
(Finish-Finish, or FF). extended downward to describe all sig-
nificant products, including documents,
Each of these three activity relationships reports, hardware and software items.
may be modified by attaching a lag ( + or - ) • For each product, listing the steps re-
to the relationship, as shown in Figure 3. quired for its generation and drawing the
It is possible to summarize a number of process as a work flow diagram.
low-level activities in a precedence diagram • Indicating the dependencies among the
with a single activity. This is commonly products, and any integration and verifi-
referred to as hammocking. One takes the cation steps within the work package.
initial low-level activity and attaches a
summary activity to it using the first re- Step 2: Identify and negotiate external
lationship described above. The summary dependencies. External dependencies are
activity is then attached to the final low- any receivables from outside of the cost ac-
level activity using the third relationship count, and any deliverables that go outside
described above. Unless one is hammocking, of the cost account. Informal negotiations
the most common relationship used in prece- should occur to ensure that there is agree-
dence diagrams is the second one mentioned ment with respect to the content, format and
above. The activity-on-arrow format can labeling of products that move across cost
represent the identical time-precedence logic account boundaries. This step is designed to
as a precedence diagram by creating artifi- ensure that lower level schedules can be
cial events and activities as needed. integrated.
Step 3: Estimate durations of all activi-
Establishing a Network Schedule ties. Assumptions behind these estimates
(work force, availability of facilities, etc.)
Scheduling begins with project-level sched- should be written down for future reference.
ule objectives for delivering the products de- Step 4: Enter the schedule data for the
scribed in the upper levels of the WBS. To WBS element into a suitable computer pro-
develop network schedules that are consis- gram to obtain a network schedule and an
tent with the project's objectives, the follow- estimate of the critical path for that element.
ing six steps are applied to each cost account (There are many commercially available
at the lowest available level of the WBS. software packages for this function.) This
Step 1: Identify activities and dependen- step enables the cognizant engineer, team
cies needed to complete each WBS element. leader, and/or systems engineer to review
Enough activities should be identified to the schedule logic. It is not unusual at this
show exact schedule dependencies between point for some iteration of steps one to four to
activities and other WBS elements. It is not be required in order to obtain a satisfactory
uncommon to have about 100 activities iden- schedule. Reserve will also be added to criti-
tified for the first year of a WBS element cal path activities, often in the form of a
that will require 10 work-years per year. dummy activity, to ensure that schedule
Typically, there is more schedule detail for commitments can be met for this WBS ele-
the current year, and much less detail for ment.
subsequent years. Each year, schedules are Step 5: Integrate schedules of lower level Z
updated with additional detail for the cur- WBS elements, using suitable software, so
rent year. This first step is most easily ac- that all dependencies between WBS ele-
complished by: ments are correctly included in a project
44
network. It is important to include the im- Desirable Features in Gantt Charts

pacts of holidays, weekends, etc., at this
point. The critical path for the project is dis- The Gantt chart shown in Figure 4 illustrates
covered at this step in the process. the following desirable features:
Step 6: Review the work force level and
o A heading that describes the WBS element,
funding profile over time, and make final ad-
the responsible manager, the date of the
justments to logic and durations so that work baseline used, and the date that status was
force levels and funding levels are reason- reported.
able. Adjustments to the logic and the dura- • A milestone section in the main body (lines 1
tions of activities may be needed to conform and 2).
to the schedule targets established at the • An activity section in the main body.
Activity data:
project-level. This may include adding more
a. WBS elements (lines 3, 5, 8, 12, 16 and
activities to some WBS element, deleting re-
20)
dundant activities, increasing the work force b. Activities {indented from WBS elements)
for some activities that are on the critical c. Current plan (shown as thick bars)
path, or finding ways to do more activities in d. Baseline plan (same as current plan, or if
parallel, rather than in series. If necessary, different, represented by thin bars under
the thick bars)
the project-level targets may need to be ad-
e. Status line at the appropriate date
justed, or the scope of the project may need to f. Slack for each activity (dashed lines
be reviewed. Again, it is good practice to above the current plan bars)
have some schedule reserve, or float, as part g. Schedule slips from the baseline (dashed
of a risk mitigation strategy. lines below the milestone on line 12)
The product of these last steps is a feasi- • A note section, where the symbols in the
ble baseline schedule for each WBS element main body can be explained.
that is consistent with the activities of all

This Gantt chart shows only 23 lines, which is a
other WBS elements, and the sum of all summary of the activities currently being
these schedules is consistent with both the worked for this WBS element. It is appropriate
technical scope and the schedule goals for the to tailor the amount of detail to those items most
project. There should be enough float in this pertinent at the time of status reporting.
integrated master schedule so that schedule
and associated cost risk are acceptable to the
project and to the project's customer. Even know precisely how much schedule reserve
when this is done, time estimates for many has been consumed by critical path activi-
WBS elements will have been underestimat- ties, and whether reserves are being
ed, or work on some WBS elements will not consumed or are being preserved in the
start as early as had been originally as- latest reporting period. This table provides
sumed due to late arrival of receivables. Con- information on the rate of change of schedule
sequently, replanning is almost always reserve.
needed to meet the project's goals. Good scheduling systems provide
capabilities to show resource requirements
Reporting Techniques over time, and to make adjustments so that
the schedule is feasible with respect to
Summary data about a schedule is usually resource constraints over time. Resources
described in Gantt charts, a good example of may include work force level, funding
which is shown in Figure 4. Another type of profiles, important facilities, etc. Figure 5
output format is a table that shows the float shows an example of an unleveled resource
and recent changes in float of key activities. profile. The objective is to move the start
For example, a project manager may wish to dates of tasks that have float to points where
45
Space Science & Instruments

System (Level 2) STIKSCAT PROJECT
Approval
Level 3 Manager
Subsystem (Level 3)
Achievement Statusas of:Jan 20,1991
Assembly (Level 4) RevisionDate: Dec 23,1990
Level 4 Mana_r
1990 1991
ACTIVITY FY91
OCT NOV DEC JAN FEB MAR APR MAY JUN JUL AUG SEP
1 Milestones - Subsystem _ rSOR _PDR _CDR .... I
2 - Assembly • DR
,, V I °E,.
I
3 Management I
I
4 Quarterly Assessments V_ V V
]
5 System Engineering I t REC REQ IS
I
I
6 Assembly Design m m F I
7 Subassembly rqmt.. I F ,!
8 Subassembly #I
I
" I0....."
9 Design
TO I&T
10 Fabricate
,
I , L_
11 Test 'I P-'- -- l .....
Im
12
13
Subassembly
Design
#2
i
, I ..... • •
' TO I&T
14 Fabricate mm
I
15 Test !
16
17
Subassembly
Design
#3
, +
TO I&T
I
18 Fabricate
19 Test ,
I _ c___ln ........ 9
I
I
20 Integration & Test i REC _7
21 Plans I n • FI ALL SUBASSY
F
22 Procedttres mm--j
I
.... e v FIXTURE
23 Integrate & Test , l ..... •
' " I
NOTES:
FLOAT- Positive or Negative- is This assembly is for the PFM !WBS 49801)
shown above the activity bars and Assemblies for FM1 (WBS 49802) and
event symbols. FM2 (WBS 49803) are on Pg 2/2.
The BASELINE plan is shown below
the current plan, ifthey differ.
Figure 4 An Example of a Gantt Chart
the resource profile is feasible. If that is iyze changes to that baseline resulting from
not sufficient, then the assumed task dura- technical and/or schedule changes. The proj-
tions for resource-intensive activities should ect's WBS, baseline schedule and budget
be re-examined and, accordingly, the re- should be viewed by the Systems engineer as
source levels changed. mutually dependent, reflecting the technical
content, time, and cost of meeting the proj-
BUDGETING AND RESOURCE PLANNING ect's goals and objectives.
The budgeting process needs to take into
Budgeting and resource planning involves account whether a fixed cost cap or cost
the establishment of a reasonable project profile exists. When no such cap or profile
baseline budget and the capability to ana- exists, a baseline budget is developed from
46
descoping the project's goals and objectives,

requirements, design, and/or implementa-
Note: Activities
Unita I resulting in tion approach.
violations of
15 resourcelimit ,_ , Whether a cost cap or fixed cost profile
need to be _ _ ',
rescheduled. exists, it is important to control costs after
they have been baselined. An important
source,Limil
""
10 aspect of cost control is project cost and
.....HI' schedule status reporting and assessment.
::r{_::r:5_
{.:_:_::iil j Another is cost and schedule risk planning,
:[: {i [ii i such as developing risk avoidance and work-
:[:1: |i [: around strategies. At the project level,
{
ili::[ •_ _
0 :iii t;::I :::{i;i:.l l ]_i
iil budgeting and resource planning must also
Time 10 20 3O
ensure that an adequate level of contingency
funds are included to deal with unforeseen
Figure 5 An Example of an Unleveled Resource events.
Profile
Assessing the Effect of Schedule Slippage

the WBS and network schedule. This specifi-
cally involves combining the project's work
Certain elements of cost, called fixed costs, are
force and other resource needs with the
mainly time related, while others, called vari-
appropriate work force rates and other finan- able costs, are mainly product related. If a pro-
cial and programmatic factors to obtain cost ject's schedule is slipped, then the fixed costs of
element estimates. These elements of cost completing it increase. The variable costs re-
include: main the same in total (excluding inflation
adjustments), but are deferred downstream, as
in the figure below.
• Direct labor costs
• Overhead costs _DEFERRED_
• Other direct costs (travel, data process-

ing, etc.)
• Subcontract costs
• Material costs
• General and administrative costs
• Cost of money (i.e., interest payments,
if applicable) +
• Fee (if applicable) TNOW
• Contingency To quickly assess the effect of a simple schedule

slippage:
• Convert baseline budget plan from nominal
When there is a cost cap or a fixed cost
(real-year) dollars to constant dollars
profile, there are additional logic gates that • Divide baseline budget plan into fixed and
must be satisfied before the systems engi- variable costs
neer can complete the budgeting and plan- • Enter schedule slip implementation
ning process. A determination needs to be • Compute new variable costs including any
made whether the WBS and network sched- work force disruption costs
• Repeat last two steps until an acceptable
ule are feasible with respect to mandated
implementation is achieved
cost caps and/or cost profiles. If not, the sys- • Compute new fixed costs
tems engineer needs to recommend the best • Sum new fixed and variable costs
approaches for either stretching out a project • Convert from constant dollars to nominal
(usually at an increase in the total cost) or (real-years) dollars.
47
RISK MANAGEMENT There are a number of actions the systems

engineer can take to effect these objectives.
Risk management comprises purposeful Principal among them is planning and com-
thought to the sources, magnitude and pleting a well-conceived risk management
mitigation of risk, and actions directed to- program. Such a program encompasses
ward its balanced reduction. As such, risk several related activities during the systems
management is an integral part of project engineering process. The structure of these
management, and contributes directly to the activities is shown in Figure 6.
objectives of systems engineering. The first is the process of identifying and
characterizing the project's risks. The objec-
tive of this step is to understand what uncer-
Risk
tainties the project faces, and which among
them should be given greater attention. This
The term risk has different meanings depending
on the context. Sometimes it simply indicates the is accomplished by categorizing (in a consis-
degree of variability in the outcome or result of a tent manner) uncertainties by the likelihood
particular action. In the context of risk of occurrence (e.g., high, medium, or low),
management during the systems engineering and separately, according to severity of
process, the term denotes a combination of both
consequences. This categorization forms the
the likelihood of various outcomes and their
basis for ranking uncertainties by their rela-
distinct consequences. The focus, moreover, is
generally on undesired or unfavorable outcomes tive riskiness. Uncertainties with both high
such as the risk of a technical failure, or the risk likelihood and severely adverse conse-
of exceeding a cost target. quences are ranked higher than those
without these characteristics. The primary
methods used in this process are qualitative;
NASA policy objectives with regard to hence, in systems engineering literature,
project risks are expressed in NMI 8070.4A, this step is sometimes called qualitative risk
Risk Management Policy. These are to: assessment. The output of this step is a list of
significant risks (by phase) to be given
• Provide a disciplined and documented ap- specific management attention.
proach to risk management throughout In some projects, qualitative methods are
the project cycle adequate for making risk management
• Support management decision making by decisions; in others, these methods are not
providing integrated risk assessments precise enough to elucidate the magnitude of
(i.e., taking into account cost, schedule, the problem, or to allocate scarce risk reduc-
performance and safety concerns) tion resources. Risk analysis is the process of
• Communicate to NASA management the quantifying both the likelihood of occurrence
significance of assessed risk levels and and consequences of potential future events
the decisions made with respect to them. (or "states of nature" in some texts). The
[
RiskCharacterization
Identification / Risk Analysis
and
Figure 6 Risk Management Structure
48
systems engineer needs to decide whether

Risk
risk identification and characterization are
Identification Risk
adequate, or whether the increased precision and Risk Analysis Mitigation
of risk analysis is needed for some uncertain- Characteriza- and Tracking
tion
ties. In making that determination, the sys-
tems engineer needs to balance the (usually} Expert Decision Watchlists/
higher cost of risk analysis against the value interviews analysis milestones
of the additional information.
Independent Probabilistic Contingency
Risk mitigation is the formulation, selec- assessment Risk planning
(cost, schedule Assessment
tion and execution of strategies designed to and technical) (PRA)
economically reduce risk. Tracking the effec-
Risk templates Probabilistic Critical
tivity of these strategies is also considered
(e.g., DoD network items/issues
part of risk mitigation. Risk mitigation is 4245.7-M) schedules (e.g., lists
PERT)
often a challenge because efforts and expen-
ditures to reduce one type of risk may Lessons Probabilistic Cost/schedule
increase another type. (Some have called this learned files cost and control
from previous effectiveness YeStems and
the systems engineering equivalent of the projects models (e.g., chnical
Heisenberg Uncertainty Principle in quan- Monte Carlo Performance
FMECAs/ models) Measure
tum mechanics). The ability (or necessity) to FMEAs/ (TPM)
trade one type of risk for another means that Digraphs tracking
the project manager and the systems engi-
neer need to understand the system-wide Table 1 Techniques of Risk Management
effects of various strategies in order to make

a rational allocation of resources. on the SEMP and should be updated at each
Several techniques have been developed phase of the project cycle, contains:
for each of these risk management activities.
The principal ones are shown in Table 1. The • The project's overall risk policy and objec-
systems engineer needs to choose the tech- tives
niques that best fit the unique requirements • The programmatic aspects of the risk
of each project. management activities (i.e., responsibil-
A risk management program is needed ities, resources, schedules and miles-
throughout the project cycle. In keeping with tones, etc.)
the doctrine of successive refinement, its • A description of the tools and techniques
focus, however, moves from the "big picture" to be used for risk identification and
in the early phases of the project cycle characterization, risk analysis, and risk
(Phases A and B) to more specific issues dur- mitigation
ing product design and development (Phases • A description of the role of risk manage-
C and D). During pre-operations and oper- ment with respect to systems analysis,
ations (Phases E and F), the focus changes baseline change control, formal reviews,
again. A good risk management program is and status reporting and assessment
always forward-looking. In other words, a • Documentation requirements for each
risk management program should address risk management product and action.
the project's ongoing risk issues and future
uncertainties. As such, it is a natural part of The level of risk management activities
concurrent engineering. should be consistent with the project's
Risk management activities for a project overall risk policy established in conjunction
should be documented in a risk management with its NASA Headquarters program office.
program plan. That plan, which elaborates At present, formal guidelines for the
49
classification of projects with respect to over- An example of the first kind of uncertain-
all risk policy do not exist; such guidelines ty occurs in the unpredictability of the
exist only for NASA payloads. These are pro- spares upmass requirement for alternative
mulgated in NMI 8010.1A, Classification of Space Station Freedom designs. While the
NASA Payloads, Attachment A. requirement is stochastic in any particular
logistics cycle, the probability distribution
Types of Risks can be estimated for each design from reli-
ability theory and empirical data. Examples
There are several ways to describe the var- of the second kind of uncertainty occur in
ious types of risk a project manager/systems trying to predict whether a Shuttle accident
engineer faces. Traditionally, project manag- will make resupply of Freedom impossible
ers and systems engineers have attempted to for a period of time greater than x months, or
divide risks into three or four broad categor- whether life on Mars exists.
ies namely, cost, schedule, technical, and Modern subjectivist (also known as
sometimes, safety (and/or hazard) risks. Bayesian) probability theory holds that the
More recently, others have entered the lexi- probability of an event is the degree of belief
con, including the categories of organization- that a person has that it will occur, given
al, management, acquisition, supportability, his/her state of information. As that infor-
political and programmatic risks. These mation improves (e.g., through the acquisi-
newer categories reflect the expanded set of tion of data or experience), the subjectivist's
concerns of project managers and systems estimate of a probability should converge to
engineers who must operate in the current that estimated as if the probability distribu-
NASA environment. Some of these newer tion were known. In the examples of the
categories also represent supersets of other previous paragraph, the only difference,
categories. For example, the Defense Sys- then, is the probability estimator's perceived
tems Management College (DSMC) Systems state of information. Consequently, subjec-
Engineering Management Guide wraps tivists find the distinction between the two
"funding, schedule, contract relations, and kinds of uncertainty of little or no practical
political risks" into the broader category of significance. The implication of the subjec-
programmatic risks. While these terms are tivist's view for risk management is that,
useful in informal discussions, there appears even with little or no data, the systems
to be no formal taxonomy free of ambiguities. engineer's subjective probability estimates
One reason, mentioned above, is that often form a valid basis for risk decision making.
one type of risk can be exchanged for an-
other. A second reason is that some of these Risk Identification and
categories move together, as for example, Characterization Techniques
cost risk and political risk (e.g., the risk of
project cancellation). A variety of techniques is available for risk
Another way some have categorized risk identification and characterization. The
is by the degree of mathematical pre- thoroughness with which this step is accom-
dictability in its underlying uncertainty. plished is an important determinant of the
The distinction has been made between an risk management program's success.
uncertainty that has a known probability
distribution, with known or estimated Expert Interviews. When properly con-
parameters, and one in which the underlying ducted, expert interviews can be a major
probability distribution is either not known, source of insight and information on the pro-
or its parameters cannot be objectively ject's risks in the expert's area of knowledge.
quantified. One key to a successful interview is in
5O
identifying an expert who is close enough to general caution, risk templates cannot
a risk issue to understand it thoroughly, and provide an exhaustive list of risk issues for
at the same time, able (and willing) to step every project, but they are a useful input to
back and take an objective view of the prob- risk identification.
abilities and consequences. A second key to
success is advanced preparation on the part Lessons Learned. A review of the lessons
of the interviewer. This means having a list learned files, data and reports from previous
of risk issues to be covered in the interview, similar projects can produce insights and in-
developing a working knowledge of these formation for risk identification on a new
issues as they apply to the project, and devel- project. For technical risk identification, as
oping methods for capturing the information an example, it makes sense to examine pre-
acquired during the interview. vious projects of similar function, architec-
Initial interviews may yield only qualita- ture or technological approach. The lessons
tive information, which should be verified in learned from the Infrared Astronomical Sat-
follow-up rounds. Expert interviews are also ellite (IRAS) project might be useful to the
used to solicit quantitative data and infor- Space Infrared Telescope Facility (SIRTF)
mation for those risk issues that qualitative- project, even though the latter's degree of
ly rank high. These interviews are often the complexity is significantly greater. The key
major source of inputs to risk analysis to applying this technique is in recognizing
models built using the techniques described what aspects are analogous in two projects,
later. and what data are relevant to the new
project. Even if the the documented lessons
Independent Assessment. This technique learned from previous projects are not appli-
can take several forms. In one form, it can be cable at the system level, there may be
a review of project documentation, such as valuable data applicable at the subsystem or
statements of work, acquisition plans, verifi- component level.
cation plans, manufacturing plans and the
SEMP. In another form, it can be an evalua- FMECAs, FMEAs and Digraphs. Failure
tion of the WBS for completeness and consis- Modes, Effects, and Criticality Analysis
tency with the project's schedules. In a third (FMECA), Failure Modes and Effects Analy-
form, an independent assessment can be an sis (FMEA) and digraphs are specialized
independent cost (and/or schedule) estimate techniques for safety (and/or hazard) risk
from an outside agency and/or group. identification and characterization. These
techniques focus on the hardware compo-
Risk Templates. This technique consists of nents that make up the system. According to
examining and then applying a series of pre- MIL-STD-1629A, FMECA is "an ongoing
viously developed risk templates to a current procedure by which each potential failure in
project. Each template generally covers a a system is analyzed to determine the results
particular risk issue, and then describes or effects thereof on the system, and to classi-
methods for avoiding or reducing that risk. fy each potential failure mode according to
The most widely recognized series of tem- its severity." Failures are generally classi-
plates appears in DoD 4245.7M, Transition fied into four severity categories:
from Development to Production... Solving
the Risk Equation. Many of the risks and risk • Category I - Catastrophic Failure (possi-
responses described are based on lessons ble death or system loss)
learned from DoD programs, but are general • Category II - Critical Failure (possible
enough to be useful to NASA projects. As a major injury or system damage)
51
• Category III- Major Failure (possible common to much of systems engineering, a

minor injury or mission effectiveness deg- complex uncertainty is decomposed into sim-
radation) pler ones, which are then treated separately.
• Category IV - Minor Failure (requires The decomposition continues until it reaches
system maintenance, but does not pose a a level at which either hard information can
hazard to personnel or mission effective- be brought to bear, or intuition can function
ness). effectively. The decomposition can be graphi-
cally represented as a decision tree. The
A complete FMECA also includes an esti- branch points, called nodes, in a decision tree
mate of the probability of each potential fail- represent either decision points or chance
ure. These probabilities are usually based, at events. Endpoints of the tree are the poten-
first, on subjective judgment or experience tial outcomes.
factors from similar kinds of hardware com- In most applications of decision analysis,
ponents, but may be refined from reliability these outcomes are generally assigned dollar
data as the system development progresses. values. From the probabilities assigned at
An FMEA is similar to an FMECA, but typi- each chance node, and the dollar value of
cally excludes the severity classification each outcome, the distribution of dollar val-
category. ues (i.e., consequences) can be derived for
Digraph analysis is an aid in determining each set of decisions. Even large, complex de-
fault tolerance, propagation and reliability cision trees can be represented in currently
in large, interconnected systems. Digraphs available decision analysis software. This
exhibit a network structure and resemble a software can also calculate a variety of risk
schematic diagram. The digraph technique measures.
permits the integration of data from a num- In brief, decision analysis is a technique
ber of individual FMECAs/FMEAs, and can that allows:
be translated into fault trees, described be-
low, if quantitative probability estimates are • A systematic enumeration of uncertain-
needed. ties and encoding of their probabilities
and outcomes
Risk Analysis Techniques • An explicit characterization of the deci-
sion maker's attitude toward risk, ex-
The tools and techniques of risk analysis rely pressed in terms of his/her risk aversion
heavily on the concept and "laws" (actually, • A calculation of the value of "perfect
axioms and theorems) of probability. The information," thus setting a normative
systems engineer needs to be familiar with upper bound on information-gathering
these in order to appreciate the full power expenditures
and limitations of these techniques. The • Sensitivity testing on probability esti-
products of risk analyses are generally quan- mates and outcome dollar values.
titative probability and consequence esti-
mates for various outcomes, more detailed Probabilistic Risk Assessment (PRA). A
understanding of the dominant risks, and PRA seeks to measure the risk inherent in a
improved capability for allocating risk re- system's design and operation by quantify-
duction resources. ing both the likelihood of various possible
accident sequences and their consequences.
Decision Analysis. Decision analysis is one A typical PRA application is to determine
technique to help the individual decision the risk associated with a specific nuclear --
maker deal with a complex set of uncertain- power plant. Within NASA, PRAs are used z
ties. Using the divide-and-conquer approach to demonstrate, for example, the relative
52
An Example of a Decision Tree for Robotic Precursor Missions to Mars
In 1990, the Lunar/Mars Exploration Program Office (LMEPO) at JSC wanted to know how robotic precur-
sor missions might reduce the risk of a manned Mars mission. Structuring the problem as a decision tree a -
lows the effects of different missions and chance events to be systematically and quantitatively evaluated.
The portion of the decision tree shown here illustrates the calculation of the probabilities for three distinct
outcomes: (A) a successful Mars landing, (B) a safe return without a landing, or (C) a disaster resulting in
mission and crew loss, when no atmospheric or site reconnaissance robotic precursor missions were made
and aerocapture at Mars was selected. As new information becomes available, the decision tree's data can be
reviewed and updated.
Probability of Each Outcome _ /
/__A_X_ = 8635/ _ _ A Land 0.09_L_L.?_._

//_x.^ =:0600_"=I.000 Propulsive_'_" _,,_ Catastrophic . Crash 0.01// _ A
• "
/ Success0.8
con uccess09 - Crash001
h rxc Chan e and
I • DecisionNode @ Chance Node _ Outcome 0.00 Probability
Making the same calculations for every( branch in the decision tree allows a determination of the best mix of
roboticprecursor missions as an explicit function of: (a) the contribution of each robotic precursor mission to
mannedmission risk reduction; (b) the cost, schedule and riskiness of each robotic mission; (c) the value of
the manned mission; and (d) the science value of each robotic mission in the absence of a subsequent manned
mission. Another benefit of this quantitative approach is that robotic precursors can be traded against other
risk mitigation strategies in the manned mission architecture.
For more information on decision analysis, see de Neufville and Stafford, Systems Analysis for Engineers
and Managers, 1971, and Barclay, et al., Handbook for Decision Analysis, 1977.
safety of launching spacecraft containing consequences of each accident sequence are

RTGs (Radioisotope Thermoelectric Gener- generally measured both in terms of direct
ators). economic losses and in public health effects.
The search for accident sequences is Doing a PRA is itself a major effort,
facilitated by event trees, which depict requiring a number of specialized skills
initiating events and combinations of system other than those provided by reliability
successes and failures, and fault trees, which engineers and human factors engineers.
depict ways in which the system failures PRAs also require large amounts of system
represented in an event tree can occur. When design data at the component level and
integrated, an event tree and its associated operational procedures data. [For additional
fault tree(s) can be used to calculate the information on PRAs, refer to the PRA
probability of each accident sequence. The Procedures Guide (1983) by the American
structure and mathematics of these trees is Nuclear Society and Institute of Electrical
similar to that for decision trees. The and Electronic Engineers (IEEE).]
Probabilistic Cost and Effectiveness

Probabilistic Risk Assessment Pitfalls
Models. These models offer a probabilistic
Risk is generally defined in a probabilistic risk view of a project's cost and effectiveness out-
assessment (PRA) as the expected value of a con- comes. This approach explicitly recognizes
sequence function -- that is:
that single point values for these variables
R = EsPs Cs do not adequately represent the risk condi-
where Ps is the probability of outcome s, and Cs is
tions inherent in a project.
the consequence of outcomes. To attach probabil-
ities to outcomes, event trees and fault trees are
Risk Mitigation and Tracking
developed. These techniques have been used
since 1953, but by the late 1970s, they were Techniques
under attack by PRA practitioners. The reasons
include the following: Risk identification and characterization and
• Fa_'lt trees arelimiting because a complete
set of failures is not definable risk analysis provide a list of significant
• Common cause failures could not be captured project risks that require further manage-
properly. An example of a common cause fail-
ure is one where all the valves in a system ment attention and/or action. Because risk
have a defect so that their failures are not mitigation actions are generally not costless,
truly independent
• PRA results are sometimes sensitive to sim- the systems engineer, in making recommen-
ple changes in event tree assumptions dations to the project manager, must balance
• Stated criteria for accepting different kinds of the cost (in resources and time) of such
risks are often inconsistent, and therefore not
appropriate for allocating risk reduction re- actions against their value to the project.
sources Four responses to a specific risk are usually
• Many risk-related decisions are driven by
perceptions, not necessarily objective risk as available: (1) deliberately do nothing, and
defined by the above equation. Perceptions of accept the risk, (2) share the risk with a co-
consequences tend to grow faster than the participant, (3) take preventive action to
consequences themselves -- that is, several
small accidents are not perceived as strongly avoid or reduce the risk, and (4) plan for con-
as o_m large one, even if fatalities are identi- tingent action.
cal
• There are difficulties in dealing with incom- The first response is to accept a specific
mensurables, as for example, lives vs. dollars. risk consciously. Sometimes, a risk can be
shared with a co-participant, that is, with a
foreign partner or a contractor. In this
Probabilistic Network Schedules. Proba- situation, the goal is to reduce NASA's risk
bilistic network schedules, such as PERT independent of what happens to total risk,
(Program Evaluation and Review Tech- which may go up or down. There are many
nique), permit the duration of each activity ways to share risks, particularly cost risks,
to be treated as a random variable. By with contractors. These include various
supplying PERT with the minimum, incentive contracts and warranties. The
maximum and most likely duration for each third and fourth responses require that
activity, a probability distribution can be additional specific planning and actions be
computed for project completion time. This undertaken.
can then be used to determine, for example, Typical technical risk mitigation actions
the chances that a project (or any set of tasks include additional (and usually costly)
in the network) will be completed by a given testing of subsystems and systems, design-
date. In this probabilistic setting, however, a ing in redundancy, and building a full
unique critical path may not exist. Some engineering model. Typical cost risk mitiga-
practitioners have also cited difficulties in tion actions include using off-the-shelf
obtaining meaningful input data for hardware and providing sufficient funding
probabilistic network schedules. during Phases A and B. Major supportability
54 z
risk mitigation actions include providing event occurs. In this sense, contingency
sufficient initial spares to meet the system's planning and resources act as a form of
availability goal and a robust resupply project insurance. (The term contingency
capability (when transportation is a signifi- here should not be confused with use of the
cant factor). For those risks that cannot be same term for project reserves.)
mitigated by a design or management
approach, the systems engineer should re- Critical Items/Issues Lists. A critical
commend the establishment of reasonable items/issues list (CIL) is similar to a watch-
financial and schedule contingencies and list, and has been used extensively on the
technical margins. Shuttle program to track items with signifi-
The strategy and underlying rationale cant system safety consequences.
selected for a specific risk should be docu-
mented in a risk mitigation plan and its ef- C/SCS and TPM Tracking. Two very
fectivity should be tracked through the pro- important risk tracking techniques--cost
ject cycle, as required by NMI 8070.4A. The and schedule control systems (C/SCS) and
techniques for choosing a (preferred) risk Technical Performance Measure (TPM)
mitigation strategy deal with the larger role tracking--are discussed later.
of trade studies and system modeling in gen-
eral. Some techniques for planning and Risk Management: Summary
tracking are briefly mentioned here.
Uncertainty is a fact of life in systems engi-
Watchlists and Milestones. A watchlist is a neering. To deal with it effectively, the risk
compilation of specific risks, their projected manager needs a disciplined approach. In a
consequences and early indicators of the project setting, a good-practice approach
start of the problem. The risks on the watch- includes efforts to:
list are those that were selected for manage-
ment attention as a result of completed risk • Plan, document and complete a risk man-
management activities. A typical watchlist agement program.
also shows for each specific risk a triggering • Identify and characterize risks for each
event or missed milestone (for example, a phase of the project. High risks, those for
delay in the delivery of long lead items), the which the combined effects of likelihood
related area of impact (production schedule), and consequences are significant, should
and the risk mitigation strategy to be used in be given specific management attention.
response. The watchlist is periodically Reviews conducted throughout the
reevaluated and items are added, modified or project cycle should help to force out risk
deleted as appropriate. Should the triggering issues.
event occur, the projected consequences • Apply qualitative and quantitative
should be updated and the risk mitigation techniques to understand the dominant
strategy revised as needed. risks and to improve the allocation of risk
reduction resources. This may include the
Contingency Planning. This technique is development of project-specific risk ana-
generally used in conjunction with a watch- lysis models such as decision trees and
list. The focus in contingency planning is on PRAs.
developing credible hedges and work • Formulate and execute a strategy to
arounds, which are activated upon a trigger- handle each risk, including establish-
ing event. To be credible, hedges often re- ment, where appropriate, of reasonable
quire that additional resources be expended, financial and schedule contingencies and
which provide a return only if the triggering technical margins.
55
• Track the effectivity of each risk mitiga- • Definition (or specification) of the func-
tion strategy. tional and performance requirements for
hardware, software and operations
Good risk management requires a team • Interface definitions
effort--that is, managers and systems engi- • Specialty engineering requirements
neers at all levels of the project need to be • Verification plans
involved. However, risk management re- • Documentation trees.
sponsibilities must be assigned to specific
individuals. Successful risk management Baseline management includes the following
practices often evolve into institutional techniques:
policy.
• Baseline definition and approval
BASELINE MANAGEMENT • Configuration control (and version con-
trol, if needed)
The baseline for a project contains all of the • Change control
technical requirements and related cost and • Traceability
schedule requirements that are sufficiently • Data management
mature to be accepted and placed under • Baseline communication.
change control by the NASA project man-
ager. The project baseline consists of two Baseline Evolution
parts: the technical baseline and the
business baseline. The systems engineer is The project baseline evolves in discrete steps
responsible for managing the technical base' through the project life cycle. An initial
line and ensuring that the technical baseline baseline may be established when the top-
is consistent with the costs and schedules in level user requirements expressed in the
the business baseline. Typically, the project Mission Needs Statement are placed under
control office manages the business baseline. configuration control. At each interphase
Baseline management requires the for- control gate, increased technical detail is
mal agreement of both the buyer and the added to the maturing baseline. For a typical
seller to proceed according to the up-to-date, project, there are five sequential technical
documented project requirements (as they baselines:
exist at that phase in the project cycle), and
to change the baseline requirements only by • Functional baseline at Program/Project
a formal change control process. The buyer Requirements Review (PRR, sometimes
might be an external funding agency. For called development baseline)
example, the buyer for the GOES project is • Design-to baseline at Preliminary Design
NOAA and the seller is the NASA GOES Review (PDR)
project office. Baseline management must be • Build-to (or code-to) baseline at the Criti-
enforced at all levels. In the next level for cal Design Review (CDR)
this same example, the NASA GOES project • Production (or as-built or as-coded) base-
office is the buyer and the seller is the line at the System Acceptance Review
contractor, the Loral GOES project office. (SAR)
The project-level systems engineer is • Operational (or as-deployed) baseline at
responsible for ensuring the completeness Operational Acceptance Review (OAR).
and technical integrity of the technical base-
line. The content of the technical baseline Risk management activity must begin
includes: early and continue throughout the
56
decomposition process of the project cycle to the technical baseline until approved by
prove that the core-level decisions are sound. control gate action of the buyer.
These early detailed studies and tests must Configuration control is the process of
be documented and retained in the project controlling changes to any approved baseline
archives, but they are not part of the techni- by formal action of a change board that is
cal baseline. controlled by the same authority that pre-
viously approved the baseline. Typically, the
Configuration Management change control board meets to consider
change requests to the business or technical
Configuration management is the discipline baselines of the project. The project manager
of identifying and formalizing the physical is usually the board chair, and the configura-
and functional characteristics of a configuration manager the secretary, who skillfully
tion item at discrete points in the product guides the process and records the official
evolution for the purpose of maintaining the events of the process.
integrity of the product and controlling In a change control board forum, a num-
changes to the baseline. As a functional ber of issues should be addressed:
discipline, configuration management man-
ages the documentation of the approved What is the proposed change?
evolution of a product's configuration. Con- What is the reason for the change?
figuration management includes configura- What is the design impact?
tion or baseline identification, configuration What is the effectiveness or performance
control and configuration communication. impact?
(See Figure 7.) • What is the schedule impact?
Configuration management is essential to • What is the project life-cycle cost impact?
the execution of an orderly development • What is the impact of not making the
process, to enable the modification of an change?
existing design, and to provide for later rep- • What is the risk of making the change?
lication of an existing design. Configuration • What is the impact on operations?
management often provides the information • What is the impact to support equipment
needed to track the technical progress of the and services?
project. • What is the impact on spares require-
Configuration identification of a baseline ments?
is evidenced by documentation such as • What is the effectivity of the change?
requirements documents, specifications, • What documentation is affected by the
drawings, code listings, process specifica- change?
tions and material specifications. Configura- • Is the buyer supportive of the change?
tion documentation is not considered part of
Configuration
Management
Configuration
Control
Figure 7 Configuration Management Structure
57
READINGS INSYSTEMS ENGINEERING
A review of this information should lead to a Audit control gate verifies that the accep-
well-informed decision. When this informa- tance test results are consistent with the test
tion is not available to the change control requirements previously approved at the
board, unfounded decisions are made, often PDR and CDR. The Formal Qualification
with negative consequences to the project. Review control gate verifies that the as-built
product is consistent with the as-built or as-
coded documentation and describes the ulti-
Change Control Board Conduct
mate configuration of the product. This
Objective: To review evaluations and then ap- review follows all modifications needed to
prove or disapprove proposed changes to the pro- implement qualification-caused corrective
ject's technical, operations or business baseline. actions.
Participants: Project manager (chair), project- For disciplined software development, ad-
level systems engineer, managers of each affected
ditional configuration control methods are
organization, configuration manager (secretary),
recommended:
presenters.
Format: Presenter covers recommended change
and _' -cusses related system impact. The presen- • Computer Resources Working Group
tati_: Ls reviewed by the systems engineer for (CRWG)--ensures the development envi-
completeness prior to presentation. ronment is adequate for the job
Decision: The CCB members discuss the Change • Software Configuration Review Board--
Request (CR) and formulate a decision. Project
manager agrees or overrides. change board for software baseline
changes
• Software Development Library--man-
Configuration control always includes agement controlled repository for soft-
the management of approved baseline ware development documentation and
documentation, so configuration control is tools
required on a no-change project as well as a • Software Development Folder (SDF)--
frequently changing one. Configuration developer-controlled repository for devel-
management and configuration control em- opment documentation and tools.
brace the function of data management,
which ensures that only up-to-date baseline The configuration manager performs the
information is available to the project staff. following functions:
The data management function also encom-
passes managing and archiving supporting • Conceives, documents and manages the
analyses and trade study data, and keeping configuration management system
it convenient for project use. • Acts as secretary of the change control
Configuration verification is part of con- board (controls the change approval
figuration control. It ensures that the result- process)
ing products conform to the intentions of the • Controls changes to baseline documenta-
designers and to the standards established tion
by preceding approved baselines. Each con- • Controls release of baseline documenta-
trol gate serves to review and challenge the tion

data presented for conformance to the pre- • Initiates configuration verification au-
viously established baseline constraints. The dits.
Physical Configuration Audit control gate

verifies that the physical configuration of the Configuration communication is the process
product corresponds to the build-to (or code- of conveying to all involved parties the
to) documentation previously approved at approved baseline progression in a timely
manner. This is essential to ensure that
the CDR. The Functional Configuration
58
developers only pursue options that are com- forewarn of an impending change provides
patible with the approved baseline. the project manager with sufficient prelimi-
Communication also keeps developers nary information to determine whether the
knowledgeable of the approved baseline and contractor should spend NASA contract
the necessity of approaching the change con- funds on a formal ECP. This technique is
trol board for approval of any deviations designed to save significant contract dollars.
considered necessary to further develop the Class 1 changes affect the approved base-
system. line and hence the product version identifica-
The project's approach to configuration tion. Class 2 changes are editorial changes or
management should be documented in the internal changes not "visible" to the external
project's Configuration Management Plan. interfaces.
Overly formalized systems can become so
Change Control and Version Control burdensome that members of the project
team may try to circumvent the process. It is
Once a baseline is placed under change con- essential that the formality of the change
trol, any change requires the approval of the process be appropriately tailored to the
change control board. The project manager needs of each project. However, there must
chairs the change control board, while the always be an effective change control process
systems engineer or configuration manager on every project.
is responsible for reviewing all material for For software projects, it is routine to use
completeness before it is presented to the version control for both pre-release and post-
board, and for ensuring that all affected or- release deliverable systems. It is equally
ganizations are represented in the change important to maintain version control for
control board forum. hardware-only systems.
Change control is essential at both the Approved changes on a development
contractor and NASA Center levels. project that has only one deliverable ob-
Changes determined to be Class 1 to the viously are only applicable to that one deliv-
contractor must be referred to the NASA erable item. However, for projects that have
project manager for resolution. This process multiple deliverables of "identical" design,
is described in Figure 8. The use of a prelimi- changes may become effective on the second
nary Engineering Change Proposal (ECP) to or subsequent production articles. In such a
I
.......... ............................. F .......................... i-
| Disapprove Disa _prove Disapprove
I
Approve Request i
Request
Approve
Class I
[ Prelim
ECP _ F°rmal ECPI
r [ Prepare
ECP _._I Buyer
Decision prove
Class II , I No Approve
I Concurrence
II with
Buyer j
I Classification Yes
"III Record Implement
Change
[_ Indicates
Buyer Action Status Change
Figure 8 Contract Change Control Process
59
situation, the change control board must Since the systems engineer spends time
decide the effectivity of the change, and the working with information about the system
configuration control system must maintain rather than the system itself, there are
version control and identification of the several vital characteristics the symbolic in-
as-built configuration for each article. Incre- formation must have. First, the information
mental implementation of changes is must be shareable. Whether it is in electron-
common in projects that have a deliberate ic or paper form, the data must be readily
policy of introducing product or process available in the most recently approved
improvements. As an example, the original version to all members of the team.
1972 plan held that each of the Space Shuttle Second, symbolic information must be
orbiters would be identical. In reality, each durable. This means that it must be recalled
of the orbiters is different, driven primarily accurately every time and represent the
by the desire to achieve the original payload most current version of the baseline. The
requirement of 65,000 pounds. Proper baseline information cannot change or de-
version control documentation has been grade with repeated access of the database or
essential to the sparing, fielding and main- paper files, and cannot degrade with time.
tenance of the operational fleet. This is not a trivial requirement, poor data
management practices (e.g., allowing some-
Data Management and Requirements one to borrow the only copy of a document or
Traceability drawing) can allow controlled information to
become lost. Also, material must be retained
Data management is an essential and associ- for the life of the program (and possibly be-
ated function to configuration management. yond), and a complete set of documentation
Data management ensures that official for each baseline change must be retained.
baseline data is retained, available and Third, the symbolic information must be
controlled for all official project use. Data traceable upward and downward. A data
management is essentially the official base must be developed and maintained to
project library and reference desk. show the parentage of any requirement. The
The data manager performs the following data base must also be able to display all
functions: children derived from a given requirement.
Finally, traceability must be provided to
• Conceives, documents and manages the engineering reports that document trade
documentation management system study results and other decisions that played
• Manages changes to baseline documenta- a key role in the flowdown of requirements.
tion It is the responsibility of the systems
• Manages the release of baseline docu- engineer to ensure the active, approved base-
mentation line is communicated to all those relying on
• Manages the project library. it. This technique keeps all participants ap-
prised as to the distinction between what is
Before the project team can produce a frozen under formal change control and what
tangible product, engineering must produce can still be decided without change control
descriptions of the system using words, icons board approval.
(drawings) and numbers (i.e., symbolic in-
formation). The project team must have a REVIEWS, AUDITS AND CONTROL GATES
common understanding of the words and
icons in order to be able to go from an idea to The intent and policy for reviews, audits and
a properly functioning system. control gates should be developed during
6O
Phase A and defined in the Project Imple- project cycle that is of sufficient importance
mentation Plan. The specific implementa- to be identified, defined and included in the
tion of these activities should be consistent project schedule. It requires formal examina-
with, though not limited to, the types of tion to evaluate project status and to obtain
reviews and audits described in this section. approval to proceed to the next management
The same tailoring applies to the timing of event according to the Project Implementa-
reviews, audits and control gates. tion Plan.
The purpose of a review is to furnish the
forum and process to provide NASA manage- GENERAL PRINCIPLES FOR REVIEWS
ment and their contractors assurance that
the most satisfactory approach, plan or Review Boards. The convening authority,
design has been selected, that a configura- who supervises the manager of the activity
tion item has been produced to meet the being reviewed, normally appoints the
specified requirements, or that a configura- review board chair. Unless there are compel-
tion item is ready. Reviews (technical or ling technical reasons to the contrary, the
management) are scheduled to communicate chair should not be directly associated with
an approach, demonstrate an ability to meet the project or task under review. The conven-
requirements or establish status. Reviews ing authority also names the review board
help to develop a better understanding members. The majority of the members
among task or project participants, open should not be directly associated with the
communication channels, alert participants program or project under review.
and management of problems and open ave-
nues for solutions. Internal Reviews. During the course of a
project or task, it is necessary to conduct
internal reviews that present technical
Project Termination approaches, trade studies, analyses and
It should be noted that project termination, problem areas to a peer group for evaluation
while usually disappointing to project personnel, and comment. The timing, participants and
may be a proper reaction to changes in external
content of these reviews are normally de-
conditions or to an improved understanding of
the system's projected cost-effectiveness. fined by the project manager or the manager
of the performing organization. Internal
reviews are also held prior to participation in
The purpose of an audit is to provide a formal, control gate review.
NASA management and its contractors a The internal reviews provide an excellent
thorough examination of adherence to pro- means for controlling the technical progress
gram or project policies, plans, requirements of the project. They also should be used to en-
and specifications. Audits are the systematic sure that all interested parties are involved
examination of tangible evidence to deter- in the design/development process early on,
mine adequacy, validity and effectiveness of and throughout the process. Thus, represen-
the activity or documentation under review. tatives from areas such as manufacturing
An audit may examine documentation of and quality assurance should attend the
policies and procedures as well as verify internal reviews as active participants. They
adherence to them. can then, for example, ensure that the design
The purpose of a control gate is to provide is producible and that quality is managed
a scheduled event (either a review or an through the project cycle.
audit) that NASA management will use to In addition, some organizations utilize a
make program or project go/no-go decisions. Red Team. This is an internal, independent,
A control gate is a management event in the peer-level review conducted to identify any
61
deficiencies in requests for proposals, propos- the presented approach, plan or design.
al responses, documentation or presentation Following the review, these are screened by
material prior to its release. The project or the review board to consolidate them and to
task manager is responsible for establishing ensure that the chair and cognizant man-
the Red Team membership and for deciding ager(s) understand the intent of the re-
which of their recommendations are to be quests. It is the responsibility of the review
implemented. board to ensure that adequate closure
responses for each of the action requests are
Review Presentation Material. Presenta- obtained.
tions using existing documentation such as
specifications, drawings, analyses and re- Post Review Report. The review board
ports may be adequate. Copies of any pre- chair has the responsibility to develop,
pared materials (such as viewgraphs) should where necessary, a consensus of the findings
be provided to the review board and meeting of the board, including an assessment of th_e
attendees. Background information and re- risks associated with problem areas, and de-
view presentation material of use to board velop recommendations for action. The chair
members should be distributed to the mem- will submit, on a timely basis, a written
bers early enough to enable them to examine report, including recommendations for ac-
it prior to the review. For major reviews, this tion, to the convening authority with copies
time may be as long as 30 calendar days. to the cognizant managers.
Review Conduct. All reviews should con- Standing Review Boards. Standing review
sist of oral presentations of the applicable boards are selected for projects or tasks that
project requirements and the approaches, have a high level of activity, visibility and/or
plans or designs that satisfy those require- resource requirements. Selection of board
ments. These presentations normally are members by the convening authority is gen-
given by the cognizant design engineer or erally made from senior Center technical
his/her immediate supervisor. and management staff. Supporting members
It is highly recommended that in addition or advisors may be added to the board as
to the review board, the review audience in- required by circumstances. If the review
clude project personnel (NASA and contrac- board is to function over the lifetime of a pro-
tor) not directly associated with the design ject, it is advisable to select extra board
being reviewed. This is required to utilize members and rotate active assignments to
their cross-disciplinary expertise to identify cover needs.
any design shortfalls or recommend design
improvements. The review audience should SPECIFIC TYPES OF REVIEWS
also include non-project specialists in the
area under review, and specialists in manu- This section describes the types, purpose,
facturing and fabrication, testing, quality timing and content of most of the reviews
assurance, reliability and safety. Some that may occur during the conduct of projects
reviews may also require the presence of or tasks. Review material should be keyed to
both the contractor's and NASA's contract- project documentation when available to
ing officers. minimize separate efforts.
Prior to and during the review, board
members and review attendees may submit Program/Project Requirements Review.
requests for action or engineering change Purpose. The Program/Project Require-
requests (ECR) that document a concern, ments Review (PRR) establishes the project
deficiency or recommended improvement in
62
development (i.e., functional) baseline. It • Management structure

ensures that: • Budget constraints
• Schedule
• The project objectives (particularly the • Risk management activities.
research and/or science objectives) have
been properly translated into definite and Preliminary Design Review. The Prelimi-
unambiguous statements of require- nary Design Review (PDR) is not a single re-
ments. view but a number of reviews starting with
• The impact of these requirements on the the system PDR, followed by reviews con-
design of the major project elements and ducted on specific configuration items (CIs).
systems is sufficiently well understood Purpose. The PDR establishes the
that trades between requirements and design-to baseline and ensures that it meets
constraints can be properly made. the program, project, system, subsystem or
• The management techniques, procedures, specific CI baseline requirements. The PDR
agreements and resources to be utilized process should:
by all project participants are evaluated.
• Establish the ability of the selected de-
Timing. At the completion of the Concept sign approach to meet the technical
Definition Phase (Phase B) activities, just requirements.
prior to issuing the Source Selection Request • Establish the compatibility of the inter-
for Proposal. face relationships between the specific
Agenda. The appropriate items from the configuration item and other interfacing
following review items/data checklist should items.
be addressed: • Establish the integrity of the selected
design approach.
• Status of action items from the Conceptu- • Establish the operability of the selected
al Design Review (CoDR) design.
• Project Plan • Assess compliance with quality assur-
• Mission objectives ance, reliability and system safety re-
• Research objectives quirements.
• Science objectives • Address status, schedule and cost rela-
• Design criteria and approach tionships,
• System trade analyses • Establish the feasibility of the approach.
• Design analyses and trade studies
• Final system specification Timing. After design-to specifications
• Preliminary interface specifications are developed and after risk reduction analy-
• Software system requirements ses are available.
• Work breakdown structure Agenda. The appropriate items from the
• Preliminary manufacturing plan following review items/data checklist should
• Preliminary ground operations plan be addressed:
• Preliminary payload integration plan
• Preliminary flight operations plan • Status of action items from the applicable
• Preliminary data management plan Hardware or Software Specification
• Configuration management plan Review(s)
• Reliability requirements and plan • Final functional requirements and speci-
• Quality assurance requirements and plan fications
• System safety requirements and plan • Technical justification for the perfor-
• Project policy and requirements mance specified
63
• Experiment performance analysis, in- requirements and establishes its build-to

cluding an analysis of instrument accura- and/or code-to baseline. The CDR determines
cy requirements whether the design is compatible with the
• Design parameters and constraints specified requirements, and verifies that the
• Environmental design requirements design conforms to the requirements estab-
• Interface design requirements lished at the PDR and updated to the time of
• Requirements traceability results the CDR. During the CDR, the integrity of
• Software standards to be applied the design is verified through review of ana-
• Design and safety codes and standards to lytical and test data.
be applied Following the CDR, the CI specifications
• Results of technical feasibility modeling and drawings are updated and placed under
and testing configuration control, and may be then re-
• Design optimization analyses leased for fabrication and/or coding.
• Discussion ofblock diagrams Timing. When the design of a CI is com-
• Compliance with functional require- plete and after the completion of producibil-
ments and specifications ity demonstration. It should be held early
• Suitability of inherited designs and hard- enough to allow for corrective action and
ware before total design freeze, the purchase of
• Lists of preliminary parts, materials and significant equipment or fabrication of final
processes hardware.
• Spares requirements philosophy Agenda. The appropriate items from the
• Preliminary data management flow and following review items/data checklist should
reduction plans be addressed:
• Preliminary payload integration plan
• Preliminary ground operations plan • Status of PDR action items
• Preliminary flight operations plan • Design requirements and specifications
• Requirements and plans for support • Interface requirements and specifications
equipment, including ground support • Design approach
equipment (GSE) • Assessment of hardware and software
• Preliminary reliability analyses, includ- inheritance
ing single-point failure mode policy • Test procedures
• Preliminary system safety analyses • Producibilitydemonstration results
• Quality Assurance Plan • Scale model test results
• Hardware and/or software verification • Design trades and alternatives consid-
plans ered
• Hardware and software development • Reliability, maintainability and opera-
plans and schedules (including verifica- bility considerations
tion tests or analyses to be performed) • Spares list
• Present status of item under review, in- • Conformance of the design to functional
cluding cost and technical developments and user requirements
• Risk management activities. • Conformance to environmental design
requirements
Critical Design Review. The Critical De- • Differences between the configuration
sign Review (CDR) is not a single review but item, system and subsystem perfor-
a number of reviews starting with specific mances in relation to the performances
CIs and ending with the system CDR. estimated at the PDR
Purpose. The CDR verifies the suitabil- • Final hardware and software design ver-
ity of a CI design in meeting the specified ification plans
64
• Detailed mechanical (including electronic test planning and compatibility with the ver-
packaging, thermal, hydraulic and pneu- ification requirements and specifications.
matic) design Timing. After completion of preliminary
• Detailed electronic and electrical circuit testing and prior to the start of official verifi-
design cation testing.
• Detailed software design Agenda. The appropriate items from the
• Interface details and agreements following review items/data checklist should
• Mechanical and electronic parts stress be addressed:
analysis results
• Final reliability analyses, including • Description of test article
single-point failure analyses against the • Test objectives
reliability policy • Verification requirements and specifica-
• System safety analyses tions
• Electronic parts classifications and • Applicable test plans
screening specifications • Applicable test procedures
• Nonelectric parts, materials and process- • Test configuration and functional block
ing list diagrams
• Materials and processing specifications • Test equipment and circuitry
• Purchased devices list • Test equipment calibration
• Manufacturing and fabrication plans • Data to be collected, and collection and
• Quality assurance plans and procedures preservation methods
• Configuration control plans • Quality assurance plan
• Qualification and acceptance test plans • Safety plan
• Calibration plan • Test failure procedures
• Data management flow and data reduc- • Personnel responsibilities and qualifica-
tion plan tions
• Support equipment and GSE require- • Present status of item under review in-
ments and plans cluding cost and technical developments
• Spares provisioning plan • Risk management activities.
• Ground operations plan
• Payload integration plan System Formal Qualification Review.
• Flight operations plan Purpose. The System Formal Qualifica-
• Present status of item under review, in- tion Review (SFQR) establishes the system
cluding cost and technical developments production baseline by verifying that the
• Risk management activities. system performance meets the system
qualification specifications. The qualifica-
Test Readiness Review. The Test Readi- tion testing demonstrates that the system
ness Review (TRR) is not a single review but meets its performance and operational
a series of reviews conducted prior to the requirements within the specified margins.
start of verification testing of each test arti- The SFQR is the decision point for customer
cle, CI, subsystem and/or system. approval of the qualification certification of
Purpose. The TRR establishes the deci- the design.
sion point to proceed with planned verifica- Timing. After the completion of all
tion (qualification and/or acceptance) testing lower-level qualification testing.
of test articles, CIs, subsystems and/or sys- Agenda. The appropriate items from the
tems to acquire official sell-off verification following review items/data checklist should
data. The TRR assesses the adequacy of the be addressed:
65
• Status of action items from the applicable • Is correctly documented in as-built draw-
CDRs and TRRs ings, code listings, user manuals, etc.
• Description of system tested, including
all subsystems and functional block dia- Timing. Following the completion of the
grams SFQR. Usually held in conjunction with the
• Qualification test objectives System Acceptance Review (SAR). For single
• Qualification test requirements and unit projects, the FCA/PCA may be held pri-
specifications or to qualification testing.
• Description of test facilities Agenda. The appropriate items from the
• Description of test configurations following project documentation should be
• Subsystem qualification test results addressed:
• System qualification test results
• Qualification by similarity analysis • CI, subsystem and system specifications
• Nonconformance reports/status • Design drawings and engineering orders
• Waivers and deviations • Subsystem and system schematics and
• Open work list block diagrams
• Environmental retest following correc- • Design verification matrices for each con-
tive action of any failures figuration item, subsystem and system
• Strength and fracture mechanics for as- • Inspection results
built hardware • Material and electronic parts certifica-
• Software development documentation tions
• Summary of qualification status of all • Materials process certifications
end items subjected to separate qualifica- • Material Utilization List (MUL)
tion tests • Installed non-flight hardware list
• Operational manuals • Test results
• Maintenance manuals • Demonstration results
• Present status of system under review, • Nonconformance reports/status
including cost and technical develop- • Results of each Configuration Item Ac-
ments ceptance Review (CIAR)
• Risk management activities. • Results of the SFQR.
Functional and Physical Configuration System Acceptance Review.

Audit. Purpose. The System Acceptance Review
Purpose. A Functional Configuration (SAR) provides the decision point to confirm
Audit (FCA) verifies that each as-built con- that the design is ready for either integra-
figuration item, test article, subsystem tion, acceptance or replication.
and/or system satisfies the functional and Timing. Following the completion of
performance requirements specified in their the SFQR and prior to the Multi-Unit
respective design-to specifications. Procurement Phase and/or the Pre-
A Physical Configuration Audit (PCA) Operations Phase (Phase E).
verifies that each as-built test article, CI, Agenda. The appropriate items from the
subsystem and/or system: following project documentation should be
addressed:
Satisfies the physical requirements
(weight, center of gravity, moments of in- • Brief description of system under review
ertia, surface finish, cleanliness, etc.) • Verification requirements
specified in their respective design speci- • Results of the system FCA and PCA
fications • Results of the SFQR
66
MANAGEMENT ISSUES [N SYSTEMS ENGINEERING
• System verification report (qualification Timing. At the completion of the Mission

and operation) Needs and Conceptual Studies Phase (Phase
• System acceptance report A). It should be held concurrently with the
• Final systems operations and mainten- Conceptual Design Review (CoDR).
ance methods Agenda. The appropriate items from the
• System development lessons learned following list should be addressed:
document
• Safety analyses status • Purpose of the project, facility or equip-
• Present status of system under review, ment
including cost and technical develop- • Design requirements
ments • Safety requirements
• Risk management activities. • Preliminary project safety plan
• Preliminary hazard analysis
Safety Reviews. System safety is the appli- • Safety staffing and management struc-
cation of engineering and management prin- ture
ciples,criteria and techniques to optimize • Safety budget
safety within the constraints of operational • Schedule
effectiveness, time and cost through all • Risk management activities.
phases of the project cycle.A series of system
and occupational safety reviews are held Project Requirements Safety Review.
during the project cycle,many of which are Purpose. The Project Requirements
held concurrently with other project reviews. Safety Review (PRSR) establishes the project
Following are descriptions of these reviews safety requirements baseline and ensures
and their relationship to the other project that:
reviews.
• The project safety objectives have been
Occupational Safety Reviews. The re- properly translated into definite and un-
quirements for these reviews are not covered ambiguous statements of requirements.
here. However, the systems engineer should • The impact of these requirements on the
be aware that many occupational safety redesign of the major project elements and
quirements can impose requirements on systems is sufficiently well understood
flight and/or ground equipment, such as the that trades between requirements and
shipping and handling of pressure vessels or constraints can be properly made.
toxic or explosive materials. Early reviews • The management techniques, procedures,
with Center occupational safety personnel agreements and resources to implement
should be held to identify and understand the safety program by all project partici-
any problem areas and specify the require- pants are evaluated.
ments to control them.
Timing. At the completion of the Concept
Conceptual Design Safety Review. Definition Phase (Phase B) activities just
Purpose. The Conceptual Design Safety prior to issuing the Source Selection Request
Review (CoDSR) ensures that safety require- for Proposal. It should be held concurrently
ments have been included in the conceptual with the PRR.
design and that a preliminary assessment of Agenda. The appropriate subjects from
the potential hazards has been made. At the following list should be addressed:
several NASA Centers, the CoDSR is called • Purpose of the project, facility or equip-
the Phase 0 Safety Review. ment
67
• Status of action items from the CoDSR Critical Design Safety Review. The Criti-
• Design requirements cal Design Safety Review (CDSR) is not a
• Safety requirements single review but a series of reviews conduct-
• Updated preliminary project safety plan ed on specific configuration items, subsys-
• Updated preliminary hazard analysis tems and the system.
• Safety staffing and management struc- Purpose. The CDSR establishes the
ture baseline for safety requirements, safety haz-
• Safety budget ard controls and verification methods to be
• Schedule implemented in verifying those controls. At
• Risk management activities. several NASA Centers, the CDSR is called
the Phase II Safety Review.
Preliminary Design Safety Review. The Timing. When the design of a configura-
Preliminary Design Safety Review (PDSR) is tion item is essentially complete and prior to
not a single review but a series of reviews total design freeze, the purchase of signifi-
conducted on specific configuration items, cant equipment, or fabrication of final hard-
subsystems and the system. ware. It should be held concurrently with the
Purpose. The PDSR ensures that the CDRs.
proposed CI, subsystem and/or system de- Agenda. The appropriate subjects from
signs satisfy the project and Center safety re- the following list should be addressed:
quirements. At several NASA Centers, the
PDSR is called the Phase I Safety Review. • Description of design under review
Timing. At the completion of prelimi- • Status of safety-related action items from
nary design and prior to the start of major applicable hardware or software PDSRs
detail design activities. It should be held con- • Final project safety plan
currently with the PDRs. • Updated safety analysis reports
Agenda. The appropriate subjects from • Updated preliminary hazard analyses
the following list should be addressed: (sometimes called the Phase II Hazard
Analyses)
• Description of design under review • Final Failure Modes and Effects Analysis
• Status of safety-related action items from • FinalCritical Items List
applicable hardware or software specifi- • List oflimited-life items
cation reviews • Accident or mishap investigation reports
• Updated project safety plan • Waiver and deviation request disposi-
• Updated safety analysis reports tions
• Updated preliminary hazard analyses • Present status of safety activities includ-
(sometimes called the Phase I Hazard ing cost and technical developments
Analyses) • Risk management activities.
• Preliminary Failure Modes and Effects
Analysis (FMEA) System Acceptance Safety Review.
• Preliminary Critical Items List (CIL). Purpose. The System Acceptance Safety
• List of limited-life items Review (SASR) provides the decision point to
• Accident or mishap investigation reports confirm that all project safety requirements
• Waiver and deviation request disposi- have been satisfied and confirms the satis-
tions factory completion of all hazard control
• Present status of safety activities, includ- verification items and open safety items. At
ing cost and technical developments several NASA Centers, the SASR is called
• Risk management activities. the Phase III Safety Review.
68
Timing. Following the completion of the • Critical items list

SFQR and prior to the Multi-Unit Procure- • Limited-life item list
ment Phase and the Pre-Operation Phase • Accident or mishap investigation reports
(Phase E). It should be held concurrently • Nonconformance reports/status
with the SAR. • Personnel training requirements
Agenda. The appropriate subjects from • Personnel training status
the following list should be addressed: • Present status of safety activities, includ-
ing cost and technical developments
• Description ofdesignunder review • Risk management activities.
• Status of safety-related action items from
applicable hardware or software CDRs STATUS REPORTING AND ASSESSMENT
• Updated safety analysis reports
• Updated preliminary hazard analyses An important part of systems engineering
(sometimes called the Phase III Hazard planning is determining what is needed in
Analyses) time, resources and people to realize the
• Accident or mishap investigation reports system that meets the desired goals and
• Waiver and deviation request disposi- objectives. Planning functions such as WBS
tions preparation, scheduling and fiscal resource
• Present status of safety activities, includ- requirements planning, were discussed earli-
ing cost and technical developments er. Project management, however, does not
• Risk management activities. end with planning; project managers need
visibility into the progress of those plans in
Launch or Operational Safety Readiness order to exercise proper management con-
Reviews. trol. This is the purpose of the status report-
Purpose. These reviews ensure the flight ing and assessing processes. Status reporting
and/or ground operational safety of the item is the process of determining where the
under review by certifying that: project stands in dimensions of interest such
as cost, schedule and technical performance.
• A CI, subsystem or system complies with Assessing is the analytical process that con-
all program and/or project safety require- verts the output of the reporting process into
ments. a more useful form for the project manager;
• Approved controls for all identified safety namely, what are the future implications of
hazards have been implemented. current trends? Lastly, the manager must
• All personnel involved in the handling decide whether that future is acceptable, and
and/or operation of the item under review what changes, if any, in current plans are
have received the required training. needed. Planning, status reporting, and
assessing are systems engineering and/or
Timing. Following installation and inte- program control functions; decision making
gration and prior to flight and/or start of is a management one.
ground operations. These processes together form the feed-
Agenda. The appropriate subjects from back loop depicted in Figure 9. This loop
the following list should be addressed: takes place on a continual basis throughout
the project cycle.
• Brief description of item under review This loop is applicable at each level of the
• Safety requirements and specifications project hierarchy. Planning data, status re-
• Safety compliance data package porting data and assessments flow up the
• Hazard analyses/reports with supporting hierarchy with appropriate aggregation at
data each level; decisions cause actions to be
_9
This section provides additional infor-

Status ] Not OK
mation on status reporting and assessment
L,ReH s tus
Planning Reporting Assessing __._[ Making
Decision
techniques
performance,
for costs and schedules,
and systems engineering
technical
pro-
t Status[OK cess metrics.
Figure 9 Planning and Status Reporting Cost and Schedule Control Measures
Feedback Loop
Status reporting and assessment on costs
taken down the hierarchy. Managers at each and schedules provides the project manager
level determine (consistent with policies and systems engineer visibility into how
well the project is tracking against its
establi=.hed at the next higher level of the
planned cost and schedule targets. From a
project hierarchy) how often, and in what
form, reporting data and assessments should management point of view, achieving these
be made. In establishing these status report- targets is on a par with meeting the techni-
cal performance requirements of the system.
ing and assessment requirements, some
It is useful to think of cost and schedule
principles of good practice are:
status reporting and assessment as measur-
• Use an agreed-upon set of well-defined ing the performance of the "system that
status reporting variables produces the system."

NHB 9501.2B, Procedures for Contractor
• Report these core variables in a consis-
Reporting of Correlated Cost and Perfor-
tent format at all project levels
• Maintain historical data for both trend mance Data, provides specific requirements
for cost and schedule status reporting and
identification and cross-project analyses
assessment based on a project's dollar value
• Encourage a logical process of rolling up
and period of performance. Generally, the
status reporting variables, (e.g., use the
NASA Form 533 series of reports is applica-
WBS for obligations/costs status report-
ble to NASA cost-type (i.e., cost reimburse-
ing and PBS for mass status reporting)
ment and fixed-price incentive) contracts.
• Support assessments with quantitative
risk measures However, on larger contracts (>$25M)
• Summarize the condition of the project by which require Form 533P, NHB 9501.2B al-
lows contractors to use their own reporting
using color-coded (red, yellow, and green)
alert zones for all core reporting vari- systems in lieu of 533P reporting. The pro-
ables. ject manager/systems engineer may choose
to evaluate the completeness and quality of
these reporting systems against criteria
Regular, periodic (e.g., monthly) tracking of
the core status reporting variables is recom- established by the project manager/systems
mended, through some status reporting vari- engineer's own Center, or against the DoD's
ables should be tracked more often when CostSchedule Cost System Criteria
(C/SCSC). The latter are widely accepted by
there is rapid change or cause for concern.
industry and government, and a variety of
Key reviews, such as PDRs and CDRs, are
tools exist for their implementation.
points at which status reporting measures
and their trends should be carefully sCru-
Assessment Methods. The traditional
tinized for early warning signs of potential
method of cost and schedule control is by
problems. Should there be indications that
comparing baselined cost and schedule plans
existing trends, if allowed to continue, will
against their actual values. In program con-
yield an unfavorable outcome, replanning
trol terminology, a difference between actual
should begin as soon as practical.
7O
performance and planned costs or schedule BCWPt-ACWPt, is called the cost variance
status is called a variance. at time t. Such variances may indicate that
Figure 10 illustrates two kinds of vari- the cost Estimate at Completion (EACt) of the
ances and some related concepts. A properly project is different from the budgeted cost.
constructed work breakdown structure These types of variances enable a program
(WBS) divides the project work into discrete analyst to estimate the EAC at any point in
tasks and products. Associated with each the project cycle.
task and product (at any level in the WBS) is If the cost and schedule baselines and the
a schedule and a budgeted (i.e., planned) technical scope of the work are not fully inte-
cost. The Budgeted Cost of Work Scheduled grated, then cost and schedule variances can
(BCWSt) for any set of WBS elements is the still be calculated, but the incomplete link-
budgeted cost of all work on tasks and pro- age between cost data and schedule data
ducts in those elements scheduled to be com- makes it very difficult (or impossible) to esti-
pleted by time t. The Budgeted Cost of Work mate the current cost EAC of the project.
Performed (BCWPt) is a statistic represent-
ing actual performance. BCWPt, also called Control of Variances and the Role of the
Earned Value (EVt), is the budgeted cost for Systems Engineer. When negative vari-
tasks and products that have actually been ances are large enough to represent a signifi-
produced (completed or in progress) at time t cant erosion of reserves, then management
in the schedule for those WBS elements. The attention is needed to either correct the vari-
difference, BCWPt-BCWSt, is called the ance, or to replan the project. It is important
schedule variance at time t. to establish levels of variance at which
action is to be taken. These levels are gener-
ally lower when cost and schedule baselines
ECA
Foreosst of
do not support Earned Value calculations.
Cost Varience The first action taken to control an
at Completion
excessive negative variance is to have the

C _ Budget cognizant manager or systems engineer in-
U
M I
/
vestigate the problem, determine its cause
U
L .:! and recommend a solution. There are a
A
T st
17 I
gchedule
number of possible reasons why variance
I
V
l
L
[ Varianc_
[ to Date
problems occur:
E _Cost Ver/anc_ [ [BCWP -
[to Date _ BCWS)

• A receivable was late or was unsatisfac-
(BCWP - ACWP)
tory for some reason.
Work Scheduled
• A task is technically very difficult and
ACWP = A_tual Cost of
Work Performed
requires more resources than originally
BCWP = Budgeted Cost of
D0t_j Work Performed planned.

0 J EV Earned
Budgeted Value
TIME
BCWS
EAC
=
EstSmate
Cost of
at
• Unforeseeable (and unlikely to repeat)
Completion events occurred, such as illness, a labor
strike, a fire or some other calamity.
FigureI0 Costand ScheduleVariances
Although the identification of variances is
The Actual Cost of Work Performed largely a program control function, there is
(ACWPt) is a third statistic representing the an important systems engineering role in
funds that have been expended up to time t their control. That role arises because the
on those WBS elements. The difference be- correct assessment of why a negative vari-
tween the budgeted and actual costs, ance is occurring greatly increases the
71
chances of successful control actions. This • Systems analysis activities identify the
assessment often requires an understanding key performance or technical attributes
of the cost, schedule and technical situation that determine system effectiveness;
that can only be provided by the systems trade studies performed in systems ana-
engineer. lysis help quantify the system's perfor-
mance requirements.
• Functional and performance require-
Computing the Estimate at Completion
ments definition activities help identify
EAC can be estimated at any point in the project. verification and validation requirements.
The appropriate formula depends upon the the • Verification and validation activities re-
reasons associated for any variances that may sult in quantitative evaluation of TPMs.
exist. If a variance exists due to a one-time
• "Out-of-bounds" TPMs are signals to re-
event, such as an accident, then EAC = BUD-
GET + ACEP - BCWP where BUDGET is the plan fiscal, schedule and people re-
original planned cost at completion. If a variance sources; sometimes new systems analysis
exists for systemic reasons, such as a general un- activities need to be initiated.
derestimate of schedule durations, or a steady
redefinition of requirements, then the variance Tracking TPMs can begin as soon as a base-
is assumed to continue to grow over time, and
line design has been established, which can
the equation is: EAC = BUDGET × (ACWP/
BCWP). occur as early as Phase B. A TPM tracking
It is also possible that EAC will grow at a program should begin not later than the
greater rate than estimated by the above equa- start of Phase C. Data to support the full set
tion if there are a growing number of liens, ac- of selected TPMs may, however, not be avail-
tion items or significant problems that will able until later in the project cycle.
increase the difficulty of future work. Such fac-
tors could be addressed using risk management
methods. Selecting TPMs. In general, TPMs can be
In a large project, a good EAC is the result of generic (attributes that are meaningful to
a variance analysis that may use a combination each Product Breakdown Structure [PBS]
of these estimation methods on different parts of element, like mass or reliability) or unique
the WBS. A rote formula should not be used as a (attributes that are meaningful only to spe-
substitute for understanding the underlying
cific PBS elements). The systems engineer
causes of variances.
needs to decide which generic and unique
TPMs are worth tracking at each level of the
Technical Performance Measures PBS. The systems engineer should track the
measure of system effectiveness (when the
Status reporting and assessment of the project maintains such a measure) and the
system's technical performance measures principal performance or technical attri-
(TPMs) complements cost and schedule con- butes that determine it, as top-level TPMs.
trol. By tracking the system's TPMs, the At lower levels of the PBS, TPMs worth
project manager gains visibility into wheth- tracking can be identified through the func-
er the delivered system will actually meet its tional and performance requirements levied
performance specifications (requirements). on each individual system, segment, etc.
Beyond that, tracking TPMs ties together a In selecting TPMs, the systems engineer
number of basic systems engineering should focus on those that can be objectively
activities--that is, a TPM tracking program measured during the project cycle. This mea-
forges a relationship among systems analy- surement can be done directly by testing or
sis, functional and performance require- indirectly by a combination of testing and
ments definition and verification and valida- analysis. Analyses are often the only means
tion activities. available to determine some high-level
72
TPMs such as system reliability, but the Earned Value method for cost and schedule
data used in such analyses should be based control described earlier.
on demonstrated values to the maximum
practical extent. These analyses can be
Examples of High-Level TPMs for
performed using the same measurement Planetary Spacecraft and Launch Vehicles
methods or models used during trade stud-
High-level technical performance measures
ies. In TPM tracking, however, instead of
(TPMs) for planetary spacecraft include:
using estimated (or desired) performance or
technical attributes, the models are exer- • End-of-mission (EOM) dry mass
• Injected mass (includes EOM dry mass, base-
cised using demonstrated values. As the line mission plus reserve propellant, other
project cycle proceeds through Phases C and consumables and upper stage adaptor mass)
• Consumables at EOM
D, the measurement of TPMs should become
• Power demand (relative to supply)
increasingly more accurate because of the • Onboard data processing memory demand
availability of more "actual" data about the • Onboard data processing throughput time
• Onboard data bus capacity
system. • Total pointing error
Lastly, the systems engineer should se-
lect those TPMs that must fall within well- Mass and power demands by spacecraft subsys-
tems and science instruments may be tracked
defined (quantitative) limits for reasons of separately as well.
system effectiveness or mission feasibility.
For launch vehicles, high-level TPMs include:
Usually these limits represent either a firm
upper or lower bound constraint. A typical • Total vehicle mass at launch
• Payload mass (at nominal altitude or orbit)
example of such a TPM for a spacecraft is its
• Payload volume
injected mass, which must not exceed the ca- • Injection accuracy
pability of the selected launch vehicle. • Launch reliability
• In-flight reliability
Tracking injected mass as a high-level TPM • For reusable vehicles, percent of value recov-
is meant to ensure that this does not happen. ered
• For expendable vehicles, unit production cost
at the n th unit.
Assessment Methods. The traditional
method of assessing a TPM is by establishing
a time-phased planned profile for it, and A closely related method of assessing a
comparing the demonstrated value against TPM relies on establishing a time-phased
that profile. The planned profile represents a margin requirement for it and comparing
nominal "trajectory" for that TPM taking the actual margin against that requirement.
into account a number of factors. These The margin is generally defined as the differ-
factors include the technological maturity of ence between a TPM's demonstrated value
the system, the planned schedule of tests and and its allocated requirement. The margin
demonstrations, and any historical exper- requirement may be expressed as a percent
ience with similar or related systems. As an of the allocated requirement. The margin
example, spacecraft dry mass tends to grow requirement generally declines through
during Phases C and D by as much as 25 to Phases C and D, reaching or approaching
30 percent. A planned profile for spacecraft zero at their completion.
dry mass may try to compensate for this Depending on which method is chosen,
growth with a lower initial value. The final the systems engineer's role is to propose
value in the planned profile usually either reasonable planned profiles or margin re-
intersects or is asymptotic to an allocated quirements for approval by the cognizant
requirement (or contract specification). The manager. The value of either of these meth-
planned profile method is the technical per- ods is that they allow management by
formance measurement counterpart to the exception--that is, only deviations from
73
planned profiles or margins below require-

(a) Planned Profile Method
ments signal potential future problems re-
quiring replanning. If this occurs, then new I
cost, schedule and/or technical changes New
Allocation
should be proposed. Technical changes may T a _
P
imply some new planned profiles. This is il- M Original • _ It
lustrated for a hypothetical TPM in Figure V All_:ation --'=4
ll(a). In this example, a significant demon- tl t Planned I
strated variance (i.e., unanticipated growth) e Margin ¢ -c

V* u
in the TPM during design and development ml

/Original r
r
Demonat_ated Planned
e
of the system resulted in replanning at time Demonstrated • * T
Variance Profile in
Value q
t. The replanning took the form of an in-
iD
crease in the allowed final value of the TPM _eplannJng
Occurred Here
la
It
(the "allocation"). A new planned profile was

TIME
then established to track the TPM over the
remaining time of the TPM tracking
program. (b) Margin Management Method
+
The margin management method of as- Disconti nuity
sessing is illustrated for the same example in • _l_ /induced by shiR
-- , _¢f to new allocation
Figure l l(b). The replanning at time t oc-

curred when the TPM fell significantly below
Margin I
the margin requirement. The new higher m 0 Requirement ¢ New Marppn
M Requirement _ _.
allocation for the TPM resulted in a higher
margin requirement, but it also immediately
placed the margin in excess of that require-
ment.
Both of these methods recognize that the Replann_ng
Occurred Here
final value of the TPM being tracked is un-
certain throughout most of Phases C and D.
The margin management method attempts TIME
to deal with this implicitly by establishing a
margin requirement that reduces the P (c) Risk Management Method
chances of the final value exceeding its allo- ro 1.0 I
Green Alert ! g • • • 4_
cation to a low number, for example, five per- $
i
Zone
el • i¢ i
cent or less. A third method of reporting and T

j Yellow Alert
% I Zone :-:::f.,,
assessing deals with this risk explicitly. The ::i:!'!!
risk management method is illustrated for N_

rt
the same example in Figure l l(c). The e
,.._:::i_:-
replanning at time t occurred when the
::::ii_-_induced by sh_R
probability of the final TPM value being less
than the allocation fell precipitously into the .:::::_
t; .:¢.:<
red alert zone. The new higher allocation for _;:;

_l::_..:.._;!_:_;!-':_:':i:!:::!::::::::_::i::"
_ Note: Although red-
':i::¥
the TPM resulted in a substantial improve- E:_._,'-'_; _:_:'::':_':: _:::-_::_ are _bow_a only ia (cL
t:::.::_:::_:.<::: _.: :._.: _.::;:: £::: • _:_
|D
ment in that probability. :::::::_.::: ::._.: :: ,::::::.:_.:::::::::::::._
_,,:_Y._:._:::'::::_:_:i::_!:_:_!:.'¢-'_-_
correuponding zone_
apply to (a_ and (bk
t_:i_ _._i_:_:_:_._.:;:i::¢_¢._ :!e
The risk management method requires
TIME
an estimate of the probability distribution
for the final TPM value. Early in the TPM
Figure 11 Three TPM Assessment Methods
tracking program, when the demonstrated
74
value is based on indirect means of estima-

An Example of the Risk Management Method for
Tracking Spacecraft Mass tion, this distribution typically has a larger
statistical variance than later, when it is
During PhasesC and D, a spacecraft's
injectedmass based on measured data, e.g., a test result.
can be consideredan uncertainquantity.
Estimates
When a TPM stays along its planned profile
ofeach subsystem'sand eachinstrument'smass are,
however,made periodicallyby thedesignengineers. (or equivalently, when its margin remains
These estimateschange and become more accurate above the corresponding margin require-
as actual parts and components are built and ment), the narrowing of the statistical distri-
integratedintosubsystems and instruments and bution should allow the TPM to remain in
are integratedintospacecraft.Injectedmass can l the green alert zone (in Figure 11(c)) despite
alsochange duringPhasesC and D as the quantity
its growth. The three methods represent
of propellantis fine-tunedto meet the mission
design requirements. At each point during different ways to assess TPMs and communi-
developmentthen,the spacecraft'sinjectedmass is cate that information to management, but
betterrepresentedas a probabilitydistribution whichever is chosen, the pattern of success or
ratherthan as a singlepoint. failure should be the same for all three.
The mechanics of obtaining a probability
distributionfor injectedmass typicallyinvolve
Relationship of TPM Tracking Program
making estimatesof threepoints-- the lower and
to the SEMP. The SEMP is the usual docu-
upper bounds and the most likelyinjectedmass
value.These three values can be combined into ment for describing the project's TPM track-
parameters that completelydefine a probability ing program. This description should include
distribution
liketheone shown inthefigurebelow. a master list of those TPMs to be tracked and
the measurement and assessment methods
to be employed. If analytical methods and
models are used to measure certain high-
level TPMs, then these need to be identified.
The reporting frequency and timing of as-
sessments should be specified as well. [n de-
termining these, the systems engineer must
balance the project's needs for accurate,
Spacecraft
Injected
Mass, Kg
timely and effective TPM tracking against
The launch vehicle's "guaranteed" payload
the cost of the TPM tracking program. The
capability, designated the "LV Specification," is
shown as a bold vertical line.The area under the TPM tracking program plan, which elabo-
probability curve to theleft ofthe boldverticalline rates on the SEMP, should specify each
representsthe probabilitythat the spacecraft's TPM's allocation, time-phased planned pro-
injectedmass will be lessthan or equal to the i file or margin requirement, and alert zones,
launchvehicle's payloadcapability. Ifinjectedmass as appropriate to the selected assessment
isa TPM beingtrackedusingtheriskmanagement method.
method, thisprobabilitycould be plotted in a
display similar to Figure ll(c).
If this probability were nearly one, then the Systems Engineering Process Metrics
project manager might consider adding more
objectives to the mission in order to take advantage Status reporting and assessment of systems
of the "large margin" that appears to exist. In the engineering process metrics provides addi-
above figure, however, the probability is
tional visibilityinto the performance of the
significantly less than one. Here, the project
"system that produces the system." As such,
manager might consider descoping the project, for
example, by removing an instrument or otherwise[ these metrics supplement the cost and sched-
changing mission objectives. The project manager] ule control measures discussed earlier.
could also solve the problem by requesting a larger[ Systems engineering process metrics try
launchvehicle! J to quantify the effectivityand productivity of
75
the systems engineering process and organi- arises from the insights they provide into the
zation. Within a single project, tracking process that cannot be obtained from cost
these metrics allows the systems engineer to and schedule control measures alone. Over
better understand the health and progress of time, these metrics can also be a source of
that project. Across projects (and over time), hard productivity data, which are invaluable
the tracking of systems engineering process in demonstrating the potential returns from
metrics allows for better estimation of the investment in systems engineering tools and
cost and time of performing systems engi- training.
neering functions. It also allows the systems
engineering organization to demonstrate its Examples and Assessment Methods.
commitment to the TQM principle of con- Table 2 lists some systems engineering pro-
tinuous improvement. cess metrics to be considered. That list is not
Selecting Systems Engineering Process

Systems Engineering Cate-
Metrics Function Process Metric gory
Requirements Requirements identified vs. S

Generally, systems engineering process development and completed vs. approved
management
metrics fall into three categories: those that Requirements volatility Q
measure the progress of the systems engi- Trade studies planned vs. S
completed
neering effort, those that measure the qual-
Requirements approved per P
ity of that process, and those that measure systems engineering hour
its productivity. Different levels of systems
Design and Specificationsplanned vs. S
engineering management are generally development completed
interested in different metrics. For example, Processing of ECRs/ECOs Q

a project manager or lead systems engineer Engineering drawings planned S
vs. related
may focus on metrics dealing with systems
Verification and V&V plans identifiedvs. S
engineering staffing, project risk manage- Validation IV&V) approved
ment progress and major trade study V&V procedures planned vs. S
completed
progress. A subsystem systems engineer
S
may focus on subsystem requirements and Functional requirements
approved vs. verified
interface definition progress and verification P
V&V plans approved per
procedures progress. It is useful for each systems engineering hour
systems engineer to focus on just a few V&V procedures completed per P

systems engineering hour
process metrics. Which metrics should be
Processing of trouble reports Q
tracked depends on the systems engineer's
Reviews Processing of Review Item Q
role in the total systems engineering effort. Discrepancies (RIDs)
The systems engineering process metrics Processing of action items Q
worth tracking also change as the project
S = Progress, or schedule-related
moves through the project cycle. Q = Quality-related
P = Productivity
Collecting and maintaining data on the
systems engineering process is not without Table 2 Systems EngineeringProcessMetrics
cost. Status reporting and assessment of sys-

tems engineering process metrics divert time intended to be exhaustive. Because some of
and effort from the process itself. The system these metrics allow for different interpreta-
engineer must balance the value of each tions, each NASA Center needs to define
systems engineering process metric against them in a common-sense way that fits its
its collection cost. The value of these metrics own processes. For example, each Center
76
needs to determine what it meant by a apply personal judgment in picking the

completed versus an approved requirement, status reporting and assessment method.
or whether these terms are even relevant. As Productivity-related metrics provide an
part of this definition, it is important to indication of systems engineering output per
recognize that not all requirements, for unit of input. Although more sophisticated
example, need be lumped together. It may be measures of input exist, the most common is
more useful to track the same metric sepa- the number of systems engineering hours
rately for each of several different types of dedicated to a particular function or activity.
requirements, for example. Because not all systems engineering hours
Quality-related metrics should serve to cost the same, an appropriate weighing
indicate when a part of the systems engi- scheme should be developed to ensure
neering process is overloaded and/or break- comparability of hours across systems engi-
ing down. These metrics can be defined and neering personnel.
tracked in several different ways. For Displaying schedule-related metrics can
example, requirements volatility can be be accomplished in a table or graph of
quantified as the number of newly identified planned quantities vs. actuals. With quality-
requirements, or as the number of changes to and productivity-related metrics, trends are
already-approved requirements. As another generally more important than isolated
example, engineering change request (ECR) snapshots. The most useful kind of assess-
processing could be tracked by comparing ment method allows comparisons of the
cumulative ECRs opened versus cumulative trend on a current project with that for a
ECRs closed, or by plotting the age profile of successful completed project of the same
of open ECRs, or by examining the number of type. The latter provides a benchmark
ECRs opened last month versus the total against which the system engineer can judge
number open. The systems engineer should personal efforts.
77
SPACECRAFT SYSTEMS ENGINEERING
N 9 3 - 2,46/8 3
SPACECRAFT SYSTEMS ENGINEERING:
AN INTRODUCTION TO THE PROCESS AT GSFC

by Tony Fragomeni and Mike Ryschkewitsch #,¢
Systems engineering means different things systems engineer does and what are some of
to different people. Some say it applies only the products.
to one spacecraft or a total mission. Others But first we can state what systems engi-
say it applies only to hardware and not to neering is not. It is not one, single, isolated
software, but that assumption is flatly process. The whole process of systems engi-
wrong. Still others say it is electrically neering is better described as an attitude...
oriented while others say it is mechanically a plan of attack.., a way of thinking. Con-
oriented; that depends upon whether you sider, for example, the difference between a
talk to an electrical or a mechanical engi- chemist adding one ingredient to a fixed
neer. Systems engineering is often equated solution to achieve a predictable result, and a
with systems management and systems doctor who must consider a variety of uncer-
design. Some would reduce it to a purely ana- tain and ever changing physical and emo-
lytical process and others would reduce it to tional factors in the diagnosis and treatment
mere hands-on physical integration. of a patient.
Systems engineering is all of these and As shown in Figure 1, systems engineer-
much more. It encompasses such terms as the ing is not a process that is easily contained in
system approach, system analysis and sys- a single manual or cookbook. Rather, it is the
tems integration. It includes systems re- systematic use of many time-tested and
quirements analysis and functional analysis. experience-verified disciplines, tools and
The Goddard Space Flight Center's Code 400 human resources needed to identify, define
Project Manager's Handbook says it is "one of and solve problems. Which tools to use or
the most important technical efforts of a pro- expertise required depends not only on the
jeet and . . . assures the design adequacy of mission under consideration but also the
the complete system to meet the stated phase or stage of the project. The process
user/experimenter requirements for a mis- thus demands a great deal of versatility and
sion." These efforts include both the ground flexibility.
and flight segments, launch vehicle inter- Finally, systems engineering is not
face, and the end-to-end data system from always one individual or even one organiza-
collection of raw data on orbit to reduced tion. Instead, it is a flexible process which
data on the ground ready for analysis. The makes the development and design meet the
handbook says: "The Systems Manager of a requirements and constraints imposed by the
project serves as Chief Engineer and user and the system environment. It is a
provides a focal point for the systems engi- process characterized by multiple starts and
neering effort throughout all phases of the stops, frequent shifts and alternate ap-
project." proaches, as opposed to a clear-cut path or a
As a succinct definition, that is as good as simple recipe for success.
any but not really very helpful in under- Systems engineering is clearly a dynamic
standing the systems engineering process, process that cannot and will not be pinned
especially in the development of spacecraft. down into a simple procedural formula. This
The concept becomes much clearer and richer process, however, is generally the same for
when we ask why we need systems engineer- different kinds of projects. In these times of
ing, who a systems engineer is, what the increasingly constrained budgets, it is
PRE($EDING PAGE BLANK NOT FILMED
79
I
I
Phase A _._.._.__ Phase B Phase C;D/E
_ I
I
I
I
Ylission Oblectives I I Review & analyms Conduct analyses to II blRPaMRD and

(_erationui I I to establish top refine the * System Ground Data r- ..... 7
requirements I _ ] level system conceptual design Architectu re Processing ! SIRD I Ground I
• Parametric r ......
Data Products F'_"l _equirements which Allocation of Requirernent_ I I Data I
Requirements /I define ,_C, [IV, • Functional Resources ! I Processing I
Environments || Orbit • Trade.off Performance L. ......
Programmatics |[ Reqm rernenta, • System Requirernente 1
Marglns
l Data Product
Conslxaints ] ReqUirements
t +
[ Subsystem
and
Sot_war
.Fabrication,
e, Design,
and
Teat
Performance
Verification
Metric
Conduct I P?o_p .... t Assembly. Inspection
I
Parametric,
l
Flight Segment Performance lntegratmn Data
Functional, Syst_m_ Performance and Design and Test
Tirneline, Designs Specification: Specifications
and trade-off
• Miseiot_ Performance I Output ]
Analyses to Requirements
Evaluate Each and Drawings
• System Level
Approach
Performance,
Operations, and
Interface
• Key Subsystem
Performance
Requirements
T Lat tch l
Baseline system Requiremente Conduct

conceptu•ldesign • Verification
seO_tirnu rn approach defined: Analyses to
acted on basis of Requirements Refine the
• Functional &
performance, • GSE Requirernents
Operational System Desi gn:
schedule and coat, • Design Guidelines • Parametric
configuration and Descriptions
• Functional
eompatibilit_t of
-_ • Block Diagrams Changes "<--
• Hardware/ • Trade off
system phymcal.
SoRware
functional, and Ground Segment
Characteristics Specification: • Subsystem On-Orbit
technical Interfaces
• Physical • Tirneliue • Component E ngineering
and demonstrated I opMeira_i°onns
Characteristics • System Checkout
• System Acceptance
[--_.- Data I
Figure 1 SE Process in the Evolution of a Mission
incumbent upon the systems engineer to they interrelate, but more often than not,
optimize the systems design and to do things their trade studies were on isolated scratch
efficiently and not just effectively. Systems pads and the logic kept in their heads or in a
engineers are called upon to identify the desk drawer. You can almost hear them say:
risks in increasingly complex projects, and "This is the way we've always done it."
then attempt to minimize the impact of those Sometimes this informal system worked,
risks. In very complex spacecraft, which are especially on small, relatively simple pro-
expected to perform delicate and ultrasophis- jects. But as the spacecraft became more
ticated functions, a minor intrasystem per- complex and development time elongated, a
turbation can have a major performance more formal process of systems engineering
impact across multiple systems. Systems emerged. In simple terms, it starts with func-
engineering is a disciplined technical ap- tional analysis and leads to functional
proach that forces us to do our homework up requirements and then design requirements,
front and early on, to uncover problems be- It starts at the top and works down, fully
fore they become showstoppers. Although we documented at each step and traceable. The
cannot conclusively test for everything, we greater the complexity and duration of a pro-
are expected to identify and verify realities ject, the greater the penalty for not catching
and adequate margins. errors early on, and the greater the need for a
In a sense, we have always had systems well understood and well documented pro-
engineering in NASA, but it may aptly be cess. The SE process should ensure that all
termed "informal." Certainly, we recall engi- fixes be made before the start of hardware
neers and managers who had a big-picture fabrication when the cost of fixes is relatively
perspective, looking at all functions and how inexpensive. To wait until later is costly, and
8O
it can be prohibitive at the interval between are initially derived from user needs, i.e., the
acceptance testing and launch. customer. It is understood that for each re-
quirement there is an associated margin that
SE ROLES AND RESPONSIBILITIES must continually be challenged. As the pro-
ject nears completion, the amount of avail-
The main objective in systems engineering is able margin is expected to decrease since the
to devise a coherent total system design capa- margins are updated based on "actuals."
ble of achieving the stated requirements.
Requirements should be rigid. However, they Functional Requirements provide a
should be continuously challenged, rechal- description of the functions and subfunc-
lenged and/or validated. The systems engi- tions required to conduct the mission.
neer must specify every requirement in order These are generally derived from func-
to design, document, implement and conduct tional analysis and allocation.
the mission. Each and every requirement
must be logically considered, traceable and Performance Requirements or source
evaluated through various analysis and requirements define what the system
trade studies in a total systems design. Mar- must accomplish and how well the system
gins must be determined to be realistic as must perform. These requirements are
well as adequate. The systems engineer must initially derived from user needs and
also continuously close the loop and verify requirements statements and refined
system performance against the require- through requirements analyses and trade
ments. studies. They are defined during each
The fundamental role of the systems application of the systems engineering
engineer, however, is to engineer, not man- process based on outputs from previous it-
age. Yet, in large, complex missions, where erations of the process, program decisions
more than one systems engineer is required, and updates to user requirements. They
someone needs to manage the systems engi- provide the metrics that must be verified
neers, and we call them "systems managers." through appropriate analyses, demon-
Systems engineering management is an strations and tests.
overview function which plans, guides, moni-
tors and controls the technical execution of a • Derived Requirements are lower level
project as implemented by the systems engi- (subsystem and components) performance
neers. As the project moves on through requirements resulting from an analysis
Phases A and B into Phase C/D, the systems of the user stated performance require-
engineering tasks become a small portion of ments and the definition of functional re-
the total effort. The systems management quirements. These derived requirements
role increases since discipline subsystem are used by subsystem discipline engi-
engineers are conducting analyses and neers in characterizing the subsystem
reviewing test data for final review and performance requirements necessary to
acceptance by the systems managers. ensure the attainment of the user-stated
performance or source requirements.
REQUIREMENTS
Reflected Requirements are require-
The name of the game in systems en- ments placed on other subsystems or on
gineering is requirements, The statement, the higher level systems which must be
traceability and eventual verification of re- provided to each of the subsystems to en-
quirements is probably the most important sure proper performance of the subsystem
aspect of systems engineering. Requirements and the eventual attainment of the user
81
stated performance or source require- areas and offsets. Common system drivers
ments. include size, weight, power, data rate, com-
Design Requirements are described by munications, pointing, orbital altitude,
drawings, material lists, process descrip- mission operations coverage (geometry and
tions and other supporting documents for timing) and scheduling. Trade-off studies are
the fabrication, production or manufac- conducted to balance the requirements, but
turing of a system element. These are even the optimal technical approach may not
generally derived from the synthesis of a be the best way when the design is evaluated
solution for one or more higher level re- in terms of cost, schedule and risks. Since all
quirements. projects will undergo cost, schedule and tech-
nical perturbations during development, it is
The systems engineer must be able to imperative that a good system be developed.
demonstrate the traceability of each require- However, contractual, legal and fiscal re-
ment through each level, right up to the quirements dictate that the technical ap-
contractually binding source requirements. proach must be agreed to by the start of
User requirements are determined and Phase C/D. The overall system architecture
refined during Phase A studies. A host of must be established during Phase A; this
considerations are made in order to produce includes the apportionment of functions be-
the best set of "integrated performance tween the flight and ground segments. It is
requirements," considering technical perfor- imperative that proper studies and analyses
mance, first as mitigated by cost and sched- be done to result in the correct structure
ule. Systems engineers should not and do not since this affects the remainder of the project
make cost and schedule decisions, especially up through the operations phase.
in the later phases, but in Phases A and B, Phase A outputs or products include a
cost and schedule are trade-off parameters Phase A Report, a Science Requirements
that must be considered in determining the Document, preliminary Instrument Interface
best course of action. Requirements Documents, cost, schedule and
a Project Initiation Agreement (PIA). The
PHASE A - MISSION ANALYSIS Phase A Report includes functional and oper-
ational descriptions, hardware and software
In Phase A Mission Analysis, systems engi- distribution, design requirements, system/
neers will translate user needs or goals into a subsystem descriptions, mission description,
quantifiable set of functional requirements a preliminary work breakdown structure
that can be translated into design require- (WBS) and recommendations for Phase B.
ments. User requirements are defined as a The Phase A Report must have sufficient
"set of objectives" that are quantified in data to answer questions such as these:
broad terms and basic functions. The user
should also state performance measures in • Do the conceptual design and operational
terms of preferences as well as trade evalua- concept meet the overall mission objec-
tion criteria. The systems engineers will tives?
conduct functional, parametric and system • Is the design technically feasible?
analyses to define and refine mission • Is the level of risks acceptable?
requirements and to generate alternative • Are schedules and budget within the
candidate system designs. Baseline system specified limits?
conceptual designs should emerge as design • Do preliminary results show this option
drivers are identified, as well as high risk to be better than all others?
82
PHASE B - DEFINITION PHASE development, test and evaluation to ensure

that timely and appropriate intermeshing of
Assuming that each crucial question is an- all technical disciplines are reflected in the
swered affirmatively during Phase A, the overall design. Technical performance re-
systems engineer will continue development quirements and margins are continually
of the system requirements by conducting reaffirmed through analyses and tests dur-
more detailed analyses to refine the baseline ing this phase. Phase C/D outputs or pro-
system conceptual design. These Phase B ducts will also include a variety of analytical
tasks must result in technical requirements and test reports on hazards, faults, single-
and operational functions that are reflected point failures and failure modes for "what-if"
in Interface Control Documents, perfor- or worst-case scenarios. Trade-offs and other
mance and design specifications and state- analyses continue but in greater detail at the
ments of work that are _sed to produce the subsystem and component levels to ensure
hardware during Phase C. proper conversion of performance require-
Specifications are defined as "a descrip- ments into the design and into the hardware.
tion of the technical requirements for a mate-
rial or product that includes the criteria for PHASES E AND F - PRE-MISSION AND
determining whether the requirements are MISSION OPERATIONS
met." Basically, there are four types of speci-
fications: Phases E and F, Pre-mission and Mission
Operations, also involve systems engineer-
• Functional - describes only the ultimate ing, although to a lesser degree since the
end use; contractor is responsible. most important SE work is done early on.
• Performance - describes quantitatively However, the final verification of a space
what it must do; contractor is responsible. flight, system can only be done in flight, on-
• Design - what to make and how to make orbit. The systems engineering team is full
it; buyer is responsible. time with the flight operations team during
• Levels of Effort - used only for support initial on-orbit engineering checkout and on
services. call during mission operations. The final
product is the "On-Orbit Engineering Perfor-
The statement of work (SOW) describes mance Report" which measures mission
the work needed to carry out the entire mis- performance against requirements. This
sion as well as how and where the work is to document becomes useful in subsequent pro-
be done. The work breakdown structure jects, especially if it contains lessons learned.
(WBS) is used for reporting progress, perfor- Finally, the systems engineer's job is only
mance and engineering evaluations. The completed when the user has the final deliv-
WBS will structure the family of specifica- ered product, e.g., scientific data, in hand.
tions and drawings resulting from the pro-
gressive stages of systems engineering. The SYSTEMS ENGINEERING ANALYSES
final result of the Phase B process is a system
definition in sufficient depth of detail to Systems engineering is a highly analytical
allow beginning the detailed design process process. Throughout the entire project (not
for each of the individual subsystems. just at the beginning) the systems engineer
will conduct or review numerous analyses to
PHASE C/D - EXECUTION PHASE establish strong performance and design
parameters as well as to continually evalu-
During Phase C/D, systems engineering ate design approaches and options. A
provides technical oversight during design, systems engineer is expected to establish
83
performance parameters and margins, verify including those with moderate to high risk.
them with test and inspection data, and com- Trade-off studies also support make-or-buy
pare the actual to the predicted. Everything decisions and help manage technical risk. In
must be "what-ifed" to the lowest necessary Phases A and B, they establish system archi-
level, not just once but continually, so that tecture and configuration. In Phase C/D,
there are few if any surprises. they evaluate alternate solutions in sys-
One tool used by the systems engineer is tem/subsystem/component design. After
functional analysis. This is a top-to-bottom critical design review (CDR), however, trade-
effort done in all phases and at every hard- off studies are conducted only during the
ware level. The systems engineer takes a evaluation of design changes or responses to
performance requirement (function) at one failures. All factors that affect the function
hardware level of assembly and, after or requirement must be studied: perfor-
thorough analysis, determines the optimum mance, reliability, safety, cost, risk, sched-
distribution and implementation of the re- ule, maintainability, servicing, power,
quirement at the next lower hardware level. weight, thermal, complexity, etc.
Functional analysis is also used to determine System parametric and sensitivity model-
whether a particular function is best accom- ing and analyses are used to develop confi-
plished in flight or on the ground. Functional dence that a design satisfies higher level
analysis results in a hierarchical structure requirements, and to provide traceability of
(i.e., architecture) that progressively divides functional, performance and design require-
and allocates how a function is to be ments. This is accomplished by varying a
accomplished, down to the lowest common particular performance parameter between
denominator. This is extremely useful in its established worst-case limits and as per-
deciding where to cut the interface, especial- turbed by worst-case environmental stresses
ly in view of verification, accountability and to determine the resultant effect on succes-
jurisdictional (i.e., contractual) boundaries. sively higher assembly levels or performance
Another top-to-bottom systems engineer- parameters. These analyses can serve as a
ing analysis done in all phases is the require- primary vehicle for conducting trade studies
ments flowdown and allocation analysis. and to assess the whole system effectiveness
This can be described as an equitable, attain- of synthesized design options and alterna-
able and realistic distribution of system-level tives. Like all other studies and analyses,
performance requirements and resources, these analyses are done during all phases
including margins, to successively lower and are updated based on actual test data.
levels of hardware assemblies. To verify the
validity and distribution of tolerances and RISK ASSESSMENT
margins, continued analysis and review are
required throughout the project. This starts Risk assessment is approached from different
during Phase A and continues through every but related directions. During Phases A and
on-orbit checkout. Distribution should be B, the systems engineer will want to do suffi-
compared to actuals, and estimates should be cient analyses to ensure that the technical
quantified as a function of design maturity. approach is valid and that any new develop-
Trade-off studies and analyses also define ments or state-of-the-art items and their risk
margins and identify potential problem offsets have been identified. During Phase
areas. They are done on all systems and for C/D, sufficient analysis must assure that
all technical disciplines to select the configu- performance requirements and margins are
ration that best satisfies a user requirement. adequate and are in fact satisfied. Through-
Alternative technologies are examined to out the entire project life cycle, risk assess-
satisfy functional and design requirements, ment and particularly Failure Mode Effects
84
Analyses and fault tree analyses should be Systems safety hazards analyses are also
used as design tools to enhance the overall considered a systems engineering function.
system design and make it immune to fail- The intent of the systems safety hazards ana-
ures, both hardware and human. lysis is to identify design deficiencies that
Risk assessment is the identification and could directly -- or indirectly through opera-
evaluation of the impact upon the technical tor error -- result in personnel injury or
performance of those system elements that damage to the flight hardware. In this case,
appear to possess an inherent probability of any potential hazards that could result in
failing to meet some critical performance or death, severe injury or illness must be elimi-
design requirement essential for the success- nated. The impact of a major system loss or
ful accomplishment of the intended mission. damage must be evaluated in light of user
Systems engineering identifies the potential requirements.
failures, establishes margins and quantifies Operations hazards analyses look at
the risk. Risk taking gets down to knowing possible failures occurring during testing,
what your margins are and how they are dis- handling and transportation that could jeop-
tributed. How do you know what the margins ardize the hardware or personnel. All catas-
are? By doing lots of analyses and backing trophes and critical hazards resulting in
them up with tests. Two of the best tools are death, severe injury or illness, or major
Failure Mode Effects Analysis (FMEA) and system loss or damage must be eliminated.
hazards analyses. Marginal hazards may be tolerated if they
The FMEA assures that the failure modes can be rationally justified and accepted.
of a system are known and can be addressed
in an orderly fashion. Initially the analysis REVIEWS, PERFORMANCE ASSESSMENT
must identify all critical functions and the AND VERIFICATION
effects of the impairment of those functions
on mission success. Following this, a detailed The systems engineer is best advised to start
component and system interaction study is early and stay late in reviewing and assess-
conducted to determine all the ways a func- ing performance requirements and the asso-
tion could be impaired, the effect on mission ciated verification methods employed to
success and how such an impairment could prove the requirement has been satisfied.
be detected. The impact of these failures and Reviews must be done at all levels. Non-
the probability of occurrence must be evalu- advocate reviews (NARs) should be conduct-
ated in light of the user requirements and ed at the end of Phase B to evaluate the
the desired level of reliability. technical, cost and schedule approach for
The FMEA is also used in compiling the accomplishing the mission. System-level
system-level fault tree used by the flight op- reviews and lower-level hardware design and
erations team (FOT) during mission oper- test reviews should be conducted continually.
ations. The fault tree is a listing of every Peer reviews are vital at all levels and must
plausible anomaly or failure that may occur be conducted by "looking at the drawings and
on orbit. It starts out with the detection of not the viewgraphs." Trend analysis is need-
the anomaly or failure as observed by the ed on all critical performance parameters,
FOT via telemetry. It then provides a road from box level acceptance through on-orbit to
map used by the FOT in isolating the cause enable the early identification of potential
of the anomaly and taking the required cor- problem areas. Technical performance mea-
rective action or operational work-around so surement (TPM) is one proven method of as-
that the mission can proceed. The fault tree sessing compliance to requirements and the
analysis and the development of the FMEA level of technical risk. TPM is defined as the
should be done together. continuing analysis, test and demonstration
85
of the degree of anticipated and actual 2. Don't box yourself in with unnecessary
achievement of selected technical measures and undue constraints.
v
and performance parameters. TPM involves 3. Exercise extreme-care in system design,

analysis of the differences among the especially incorporating appropriate (to
achievement to date, current estimate and the risks) redundancy and provisions for
the required or target value for the par- late design changes and on-orbit oper-
ameter. ational work-arounds, and factor in test-
ing ability.
SUMMARY AND SOME ADVICE 4. Institute the discipline to ensure pains-
taking attention to details -- great and
Systems engineering is much more than a small.
one-person job. It is best described as "the 5. Maintain a total dedication to quality
technical conscience of a project." As such, quality is designed in, it does not acci-
systems engineering is a highly structured dentally happen.
and disciplined engineering process that cuts 6. Ensure rigorous pre-launch testing to es-
across all technical disciplines to ensure tablish that requirements are in fact
interface design compatibility, both inter- satisfied, and any workmanship or mar-
system and intrasystem. It organizes at the ginal designs are uncovered.
system level m not at the subsystem level, 7. Insist on inexhaustible diligence in test-
where compromises may be made. It estab- ing -- allow an unexplained or random
lishes performance requirements and failure only after all reasonable and
margins. Systems engineering evaluates the practical steps to isolate are taken.
validity of hardware through analysis and 8. Attempt to design backwards -- satisfy
review of test data. It identifies risk and mission requirements first.
offers approaches for the project manager to 9. Conduct extensive reviews -- look at the
eliminate or reduce the impact. One eye of drawings, not viewgraphs.
the system engineer is on how the end prod- 10. Have adequate documentation to know
uct is used during mission operations; the where you are going, how you are get-
other is focused on how analyses and tests ting there, where you have been and
can prove it can do the job within acceptable when you are there.
margins. Both eyes work in tandem, togeth- 11. Have an open door policy to foster strong
er, clearly andin focus. Remember: intra-project technical communications.
1. Perform sound systems analyses and de- 12. Ensure total openness regarding prob-
sign; consider all options. lem identification and resolution.
86
SE&I AND MANAGEMENT
N9 3 -
SYSTEMS ENGINEERING & INTEGRATION AND MANAGEMENT
FOR MANNED SPACE FLIGHT PROGRAMS
by Owen Morris /Z__j /_
The development of systems engineering and In these projects, essentially all of the tech-
program management in NASA manned nical responsibility was delegated to one of
space programs has grown in a largely un- the Centers, which were primarily expert in
coordinated manner over the last 30 years. the technical area being explored (i.e., aero-
However, the systems and practices that dynamics, stability, control and structures)
have been developed form a proven pattern but did not have experts in the development
for successfully integrating large, technical- of hardware. Accordingly, NACA entered
ly complex programs executed in several geo- into agreements with the Air Force or Navy
graphical locations. This development has to manage the actual development of the
not been recorded in a comprehensive man- aircraft. The NACA Centers focused their
ner, and much of the reasoning behind the direction on the technical requirements and
decisions made is not obvious. performance characteristics to be demon-
For the purposes of this discussion, sys- strated by the aircraft. The contractor's
tems engineering is defined as the inter- responsibility was similar to that for the
disciplinary engineering that is necessary to development of any aircraft, and the contrac-
achieve efficient definition and integration tor usually furnished test pilots for early
of program elements in a manner that meets demonstration flights.
the system-level requirements. Integration With the formation of NASA and the
is defined as the activity necessary to de- start of major manned space programs, it
velop and document the systems' technical was necessary for NASA to develop the capa-
characteristics, including interface control bility to manage complex development
requirements, resource reporting and analy- activities. Very little SE&I capability exist-
sis, system verification requirements and ed within the functional organizations of the
plans, and integration of the system NASA Centers. As a result, SE&I expertise
elements into the program operational was developed within each of the program
scenario. offices. In particular, the Gemini program
This paper discusses the history of SE&I office was set up with autonomous capability
management of the overall program archi- to manage SE&I and direct the development
tecture, organizational structure and the contractor.
relationship of SE&I to other program orga- With the advent of the Apollo program,
nizational elements. A brief discussion of the SE&I was again managed from the project
method of executing the SE&I process, a offices at the development centers. The
summary of some of the major lessons project offices used specialized technical
learned, and identification of things that capability from the Center functional orga-
have proven successful are included. nizations and prime contractors and initiat-
ed the practice of hiring support contractors
HISTORY to assist in implementing SE&I. After the
Apollo I fire, a review committee was estab-
NASA, then the National Advisory Commit- lished to determine the cause of the fire and
tee for Aeronautics (NACA), participation in recommend modifications to the program.
the management of major aerospace pro- One of the recommendations made was that
grams began shortly after World War II with NASA acquire a technical integration and
the advent of the X series research aircraft. engineering support contractor to assist in
87
accomplishing SE&I activity. The Washing- integration. JSC, then called the Manned
ton program office selected Boeing as the Space Center, managed both development
contractor and managed the contract for this and flight operational aspects of the Mercury
activity; however, a large portion of the work and Gemini programs with the checkout and
force was located at the Centers. The con- preflight testing being performed by support
tractor's responsibilities included moni- elements at Cape Canaveral.
toring the development and operational Apollo became organizationally more
activities at the Centers, forming integrated complex (Figure 1). The spacecraft develop-
assessments of the activity, and making ment was managed by JSC, the launch vehi-
recommendations to the program director for cle development by Marshall Space Flight
improvements. As the program matured, the Center (MSFC), the prelaunch activities by
contract, focus was changed, and the contrac- Kennedy Space Center (KSC)mby then an
tor provided a significant number of person- independent NASA CenterRand the flight
nel to directly support the Centers in SE&I operations by JSC. In all of these programs,
and systems development activities. the responsibility for the development of the
With the initiation of the Space Shuttle flight hardware was delegated to the
program and the adoption of the Lead Center Centers, and the interfaces between projects
concept, it was decided to manage the Level were intentionally kept as simple as possi-
II integration activity, including SE&I, by ble. The Washington office, under direction
providing a small management core within of the program director, was responsible for
the program office and using many of the overall direction of the program including
Centers' functional organizations to provide budgetary allocations, congressional rela-
technical support in a matrix fashion. At the tions, and management of development
Johnson Space Center (JSC), the lead person issues between the project offices at the
from the functional organization was gener- different Centers. The actual integration
ally a branch head or an assistant division activity (SE&I) was coordinated by a series
chief. JSC had a relatively large staff to of panels and working groups in which
draw from to provide the specific technical individuals from the Washington program
expertise and the level of effort needed to office served as either chairperson or
accomplish a given task. members, with the program director over-
The Space Station Freedom program was seeing the activity. In the early programs
started using the Space Shuttle program as a (Mercury and Gemini), this activity was the
model. As the Lead Center, JSC managed in- responsibility of a single Center, and the
tegration. Later, the Level II function was Washington office was coordinated in an
moved near Washington, D.C., under the informal manner, but by the end of the
deputy program director, and an indepen- Apollo program, the management of the pan-
dent contractor was brought in to assist the el and working group activity was relatively
integration process. The Space Station Free- formal. In all of these programs the Center
dom management organization will be dis- directors took an active part and personally
cussed in more detail in the next section. felt responsible for the technical excellence
of the work performed by their Centers. This
PROGRAM MANAGEMENT intercenter involvement was accomplished
ORGANIZATIONAL STRUCTURE primarily through the management council
and major program reviews where Center
A single NASA Center largely managed ear- directors personally participated in major
ly NASA manned space flight programs, decisions.
which allowed for a relatively simple organi- In part of the Apollo program, the
zational structure to accomplish program Washington office retained the responsibil-
88
SE&I AND MANAGEMENT
Level I
Apollo Program
Director
Gen. S. Philips
Level II
Al_rO11o Spacecraft Saturn V Launch Flight

ogram Office Office Operations Operations
G. Low H. Rudolph R. Petrone C. Kraft
.......
Yi..........
t.......
/ ..........
E
.............
i........
pCrSM t pLo_ec t SpIr oS;:cgte prSo]:ct Sol:ct 1 l In_rUoo_c: nt
Figure I Apollo Program Management Organization
performing the SE&I activity with the actu- interfaces of much greater complexity; and
al work being led by Bellcom, a division of the employment of one of the major hard-
Bell Laboratories. Ultimately, this approach ware development contractors as the inte-
was abandoned, at least partly because much gration support contractor. The complex
of the Center director's responsibility was interfaces made SE&I activity voluminous
lost, and an adversarial relationship be- and involved and required the commitment
tween the program director and the Center of a larger percentage of the program re-
organizations developed. The execution of sources to this activity.
the SE&I was returned to the Centers with The Space Station Freedom program was
management and coordination of intercenter structured so that the interface activity
activities achieved through the use of work- between the work packages was even more
ing groups, panels and management re- complex than that of the Shuttle program.
views. Initially, the Lead Center approach to SE&I
At the outset of the Space Shuttle pro- activity was adopted, but the implementa-
gram (Figure 2), the management of SE&I tion was not effective. As a result of recom-
was markedly changed. Some of the more im- mendations made by study groups and the
portant changes were adoption of the Lead committee reviewing the Challenger acci-
Center management concept in which one of dent, it was decided to transfer the responsi-
the participating Centers was delegated the bility for program integration activity,
management of program level integration including SE&I, to the deputy program
including SE&I activities; the adoption of a director in Reston, Virginia, and to bring on
configuration with functional and physical a contractor to provide program integration
89
Level I
Space Shuttle
Program Director
M. Malkin
Level II
Space Shuttle
Program Manager
R.F. Thompson
I I [
Resources and
Systems Management Operations Schedules
Integration Integration Integration
Integration
O. Morris R. Machell D. Cheatham R. Young
I
MSFC
Space Shuttle
Projects Office
Integration
R. Lindstrom
J. Lovingood
l
Level III
I I I
Orbiter External Tank SRB
Project Project Project Project
A. Cohen I J.R. SSME

Thompson J. Odom G. Hardy
Figure 2 Space Shuttle Program Management Organization
support (Figure 3). Contractors having sig- contractors negotiate the definition and
nificant hardware development contracts execution of much of the detailed integration
were excluded from the contract competition. process directly between themselves. This
The first approach was to provide detailed proved ineffective, however, because there
management of SE&I activity by the Reston was no clear lead responsibility and no clear
civil service personnel with the integration way to resolve differences. As a result, |
contractor providing support in executing because of the complexity of program in-

the activity. Additionally, it was thought tegration and the lack of in-depth backup ca-
that much of the technical integration could pability, this management approach has not
be accomplished by having the work package been completely effective.
9O
SE&I AND MANAGEMENT
Level I Space Station Freedom I

Program Director
I
Level II Space Station Freedom /
Deputy Program Director
J
I
Deputy Program Manager Deputy Program Manager
for for
Integration (JSC) Utilizations & Operations
I
I
Element System
Integration Integration
Manager Manager
(MSFC) (JSC)
I, __ I ! L
Systems International
Management Program Program
Engineering & Integration Control Assessments
Analysis Programs
Group Group Group Office
Group
Level III
I 1 1 I 1 L
Work Work Work Work
Package 1 Package 2 Package 3 Package 4 KSC Langley
(MSFC) (JSC) (GSFC) (LeRC)
Figure 3 Space Station Freedom Program Management Organization (1990)
Recently, it was decided to give the inte- had the advantage of drawing from the in-
gration support contractor direct responsibil- depth technical capability residing at the
ity for the integration of the program but Centers. Simultaneously, the integrating
without authority to directly manage the contractor's work force at the Centers was
work packages or their contractors. In an increased in both responsibilities and num-
attempt to obtain more in-depth capability, bers.
the program director and deputy program
director decided to execute the systems in- GROWING PROGRAM COMPLEXITY
tegration portion of the SE&I activity at two
of the Centers with the deputy director for One of the major factors determining the
integration physically located at one of the efficiency of the integration of a program is
Centers. Since these functions were still re- the methodology used to delegate the engi-
tained organizationally within the program neering and development responsibilities to
office, they were under the control of the dep- the project offices at the Centers. It has been
uty program director and, at the same time, found that less complex organizational
91
structures and simple interfaces are ex- originates in the spacecraft batteries. The
tremely important to allow efficient manage- main point is that a single person can fully
ment of SE&I activities. Each of NASA's understand this interface and can cope with
manned space programs has been organiza- all the effects of a change on either side of the
tionally more complex than its predecessor interface. If there had been 10 times as many
and has had more complex interfaces. In both wires, it probably would have taken a hun-
the Mercury and Gemini programs, the dred (or a thousand?) times as many people
flight elements were divided into two parts, to handle the interface." However, the oper-
spacecraft and launch vehicle, and the phys- ational complexity of the Apollo vehicle
ical and functional interfaces between the demanded a more extensive integration
two were quite simple. The induced environ- activity between the Centers and for the first
mental interfaces were somewhat more com- time posed the problem of accomplishing
plex but readily amenable to experimental detailed technical coordination between
and analytical determination. Centers.
The Apollo program involved a major in- One of the basic tenets of the Space
crease in program complexity. The space- Shuttle was to have an integrated vehicle
craft was divided into two project offices and that would recover the most expensive ele-
the launch vehicle was divided into four ments of the system for reuse. This led to a
project offices. By assigning the four launch design concept that placed a great majority
vehicle projects to the same Center (MSFC), of the electronics and major components of
the integration between launch vehicle the main propulsion systems in the orbiter.
stages could be accomplished at the Center This design concept led to very large
level. Similarly, both spacecraft projects increases in interface complexity between
were assigned to one center (JSC) for the the program elements and, more important-
same reason. The physical and functional in- ly, between the Centers. For instance, the
terfaces between the spacecraft and launch number of electrical wires running between
vehicle, and hence between Centers, was rel- the external tank and the orbiter was more
atively simple. In a 1971 paper titled "What than an order of magnitude greater than
Made Apollo a Success," George Low stated: between the spacecraft and launch vehicle of
"Another important design rule, which we Apollo, and for the first time, major fluid
have not discussed as often as we should, systems ran across the interfaces. This
reads: minimize functional interfaces be- represented a formidable increase in the ef-
tween complex pieces of hardware. Examples fort required to successfully accomplish the
in Apollo include the interfaces between the SE&I activity. As previously noted, a new
spacecraft and launch vehicle and between program management structure (Figure 1)
the command module and the lunar module. was adopted to accommodate the increase.
Only some 100 wires link the Saturn launch The accomplishment of program-level SE&I
vehicle and the Apollo spacecraft, and most was given to a "Lead Center." The program
of these have to do with the emergency detec- director at Headquarters was still respon-
tion system. The reason that this number sible for program budgetary control, Con-
could not be even smaller is twofold: redun- gressional relations and a technical staff
dant circuits are employed, and the electrical sufficient to assure that the program tech-
power always comes from the module or nical activity was being properly implement-
stage where a function is to be performed. ed. At JSC, which was the Lead Center for
For example, the closing of relays in the the Shuttle program, a Level II program
launch vehicle could, in an automatic abort office was established totally separate from
mode, fire the spacecraft escape motor. But the Level IH orbiter project office located at
the electrical power to do this, by design, the same Center.
92
SE&I AND MANAGEMENT
The development of the flight hardware projects and to serve as the primary interface
was delegated to four project offices with the to the Level II systems integration office.
orbiter office located at JSC, as mentioned The flight hardware developmental dele-
above, and the other three--the Space Shut- gation of the Space Station Freedom
tle main engine office, the external tank program was formulated in an even more
office, and the solid rocket booster officew complex manner (Figure 4). End-to-end
located at MSFC. In addition to the hard- developmental responsibility for each of the
ware development project offices, a pre- major functional systems was delegated to
launch processing office was formed at KSC. one of four project offices called work pack-
All of the project offices reported to the Level age offices in the Space Station Freedom
II program manager for all programmatic program. Responsibility for assembling and
direction except budget allocation, which delivering the flight hardware was broken
was retained by the program director at down by launch elements, again assigned to
Headquarters. one of the work package offices. Each of these
The SE&I activity was delegated to the launch elements incorporates components of
systems integration office located within the most of the distributed systems, neces-
JSC Level II office. The orbiter contractor, sitating the transfer of an extremely large
Rockwell International, was selected to be number of hardware and software items
the integration support contractor, but to between work packages prior to their deliv-
increase objectivity, the integration activity ery to the Government. This resulted in
was made a separate exhibit to the contract another major increase in the complexity of
and technical direction was delegated to the the program-level SE&I process and directly
Level II systems integration office. The contributed to the difficulty of implementing
MSFC Space Shuttle project office appointed a satisfactory SE&I process in the Space
an integration manager to manage the Station Freedom program.
integration of the Marshall Space Shuttle
f6
M8
Figure 4 Space Station Integration Job
93
SE&I SCENARIO and reviews is central to accomplishing hori-

zontal integration among the project offices
As a program develops from concept to oper- and is discussed in more detail later.
ational status, the characteristics of the In preparation for the preliminary design
SE&I activity vary greatly. Early in the pro- review (PDR), SE&I defines the minimum
gram, conceptual SE&I is intimately in- content required in the PDR data packages
volved in defining systems that will meet the and is responsible for preparing system-level
overall program objectives and in evaluating documents supporting the Integrated
the relative merits of each. This is usually System PDR. During the PDR process, SE&I
accomplished in NASA manned programs by representatives participate in the project-
the civil service organizations, often in con- level reviews with particular emphasis on
cert with Phase A/B contracts with industry. the compliance of the project to the system-
After the general systems specification has level requirements. During the Integrated
been developed and a detailed evaluation of System PDR, emphasis is placed on assuring
systems concepts has been completed, SE&I that the preliminary designs proposed by the
provides a lead in the preparation of the pro- projects are compatible across the interfaces
curement specifications for the Phase C and and that the integrated system is capable of
D activities and is usually directly involved meeting the operational requirements of the
in the source selection process. After award program. The SE&I organization is inti-
of the Phase C and D contracts and final mately involved with the evaluation and dis-
selection of the design approach chosen for position of review item discrepancies (RIDs)
implementation, SE&I is responsible for pre- that are submitted during the review.
paring system-level technical specifications, As a result of the PDR process, changes to
which define the performance requirements the requirements and modifications to the
to be satisfied by each of the major program preliminary design of the elements are incor-
elements. SE&I then develops the system porated. A new characterization cycle is then
characterization process to be used (dis- initiated to evaluate the compatibility be-
cussed in detail later) and starts an initial tween the modified requirements and pro-
analysis cycle. The results of this cycle are posed system capabilities. At this time, the
extremely important in verifying the valid- drafts of the interface control documents are
ity of the system technical specifications and expanded and quantitative detail is added to
providing a technical basis for conducting assure that the documents are mature
the Program Requirements Review (PRR). enough to become baseline requirements in
After completion of the PRR and updating of the program. This maturation process inevi-
the technical specifications, SE&I starts the tably results in the identification of physical
definition of the interface control document and functional disconnects among the ele-
tree and the initial document drafts. An- ments and in a significant number of
other system characterization cycle is start- changes to the baseline.
ed, based on the updated specifications and In a similar manner, the verification
the hardware and software concepts chosen plans of the elements and the integrated
to assess the adequacy of the proposed pre- system are refined and baselined. The
liminary design approach. responsibility for executing the test and ana-
By this time in the program, the ad hoc lysis required by the integrated system ver-
organizational structure should be well in ification plan are delegated to appropriate
place and functioning routinely. The commu- organizations that prepare detailed plans for
nication and management overview provided accomplishing the assigned portions of the
by this structure of working groups, panels verification.
94
SE&I AND MANAGEMENT
Detailed mission operational scenarios The SE&I organization's participation

and timelines are prepared by the operations throughout the program development cycle
organizations, and the operations and SE&I supports operational planning and real-time
organizations jointly conduct an analysis of operations. SE&I is the repository of corpo-
the system capabilities to support the sce- rate knowledge of the details of system
narios. Concurrently, the acceptance test capability, which is vital to the effective and
and prelaunch operations requirements and efficient operation of the system.
plans are prepared and delegated for execu-
tion. RELATIONSHIP OF SE&I TO OTHER
In preparation for the critical design PROGRAM FUNCTIONS
review (CDR), another system characteriza-
tion cycle is performed, based upon the To effectively accomplish the SE&I task, the
detailed design of the elements. This cycle SE&I management organization must main-
typically uses mature models to synthesize tain good communications and obtain the
the hardware and software systems and also support of other program office organiza-
incorporates the results of tests performed to tions. Some of the more important interac-
that time. SE&I participates in the conduct tions are discussed below.
of the CDR in a manner similar to that of the
PDR. After completion of the CDR, the Configuration Management. The in-
system requirements and design changes re- teraction between SE&I and configuration
sulting from the CDR are incorporated into management is particularly strong. As the
the documentation, and another complete or developers and keepers of the systems speci-
partial system characterization cycle vali- fications, SE&I has an interface with the
dates the decisions made during CDR. configuration management function that is
After CDR, the primary activity of the extremely active throughout the life of the
SE&I organization is to analyze test results program. The SE&I office recommends the
and conduct analysis to verify the capability baselining of the technical requirements as
of the system that is being manufactured. they become sufficiently mature and then
Particular emphasis is given to verifying the serves as the office of primary responsibility
interface characteristics of the elements as for defining and evaluating most of the pro-
defined by the interface control documents. posed changes to this baseline. The SE&I of-
This activity directly supports the prepara- rice, after proper coordination throughout
tion for the design certification review the integration function, also recommends
(DCR), and provides interface information the processing of noncontroversial changes
necessary to allow acceptance of the system outside of the formal control board meetings,
hardware and software by the Government. where appropriate. This significantly re-
The DCR is conducted similarly to the duces the board's workload and conserves the
PDR and CDR but addresses the as-built time of the key managers who are members
hardware and software. Successful comple- of the change control board. As significant is-
tion of the DCR certifies the acceptability of sues are referred to the board, SE&I presents
the as-built elements and the ability to be an analysis of the issues involved and makes
integrated into an overall system that will appropriate recommendations for action.
satisfy the initial program operational re-
quirements. Final operational certification Program Control. SE&I supports the
of the system is obtained by a combination of program control function in the development
the DCR process and analysis of information of program schedules and budgets. The key
obtained during early flight operation of the to making this support effective is the use of
system. the SE&I logic networks and estimates of the
manpower required to accomplish the activi- SR&QA office is responsible for setting the
ties. Because of SE&I's interdisciplinary requirements for SR&QA activities and for
nature, SE&I can assist in planning activi- evaluating the outcomesmwhile other orga-
ties in many areas of the program. nizations are delegated the responsibility for
Early in the program, SE&I helps define executing the workmthen SR&QA must de-
the content and schedule milestones of each fine and obtain baseline approval of task re-
project to permit coherent development of quirements, monitor execution of the task by
project-level schedules and cost estimates. SE&I, and evaluate the results to assure sat-
SE&I also provides program control with the isfactory achievement.
engineering master schedules (EMS) and The former mode of operation was exem-
associated budget estimates for incorpora- plified during the early Apollo program, in
tion in the overall schedule and budget which the SR&QA activities were largely ac-
system. SE&I also works with program complished within the SR&QA office using
control in planning major program reviews; basic engineering information obtained from
provides technical leadership in conducting SE&I and other program organizational
the reviews; and frequently chairs the offices. Later in the Apollo program, the
screening groups and pre-boards. second mode of execution was adopted; the
engineering offices, primarily SE&I, actual-
Operations. In all of the NASA manned ly performed the work and made a first-level
space programs to date, the SE&I function analysis before formally transmitting the
has been managed in an organization differ- results to SR&QA for authentication. This
ent from the operations definition and plan- latter method was considered more effective
ning function. Although this is undoubtedly primarily because problems and discrepan-
the best choice in the later phases of the pro- cies were often discovered by the originating
gram, it may result in a less thorough incor- engineering office and corrected even before
poration of operational requirements in the the task was completed.
systems specifications and other SE&I pro-
ducts early in the program. It may be desir- SE&I EXECUTION
able to combine the management of SE&I
and operations in the same office early in the Techniques developed in past NASA manned
program and then separating them later, programs have proven effective and have
perhaps at the completion of the preliminary become an integral part of implementing
design review. The stated reason for separat- SE&I activities. The following paragraphs
ing the functions in the past has been that describe, in no particular order, some of the
they serve as a check and balance on each most important techniques in planning and
other; however, the separation also discon- implementing new programs.
nects the detailed interfaces between the two
functions.
Importance of SE&I Early in a Pro-
gram. In the early stages of complex
SR&QA. The interactions between SE&I programs, comprehensive SE&I support
and the system reliability and quality assur- helps determine the architecture to be used
ance (SR&QA) functions depend on how to delegate project responsibility. This is
responsibility for executing the program is accomplished by dividing the program into ±
delegated. If a large part of the SR&QA the next lower level of management, the pro-
activity is accomplished within the SR&QA ject offices. The primary outputs are compre-
organization, SE&I is used as a reservoir of hensive and clear program requirement
information or to perform specific tasks as specifications, identification of major pro-
requested by SR&QA. However, if the grammatic interfaces, development of the ad
96
SE&IAND MANAGEMENT
hoc SE&I management structure, definition Development and Use of Ad hoc Inte-
of operating concepts, and preparation of gration Structure. To manage the defini-
initial specifications for the hardware to be tion and implementation of the SE&I
delegated to each project office. activities in manned space programs, NASA
The SE&I organization is responsible for has developed an effective ad hoc organiza-
managing technical integration both verti- tional structure. The structure consists of a
cally between different levels of the man- series of reviews, panels and working groups
agement organizations and horizontally that address the definition and management
across the organizations at each level. To of integration functions throughout the pro-
efficiently achieve both dimensions of inte- gram. Each organization has members who
gration, it is necessary to develop logic represent all of the organizations interested
diagrams of the major SE&I activities to be in the particular integration function being
accomplished by each of the organizational managed. In the Space Station Freedom pro-
elements and then to determine the interre- gram, the working group structure is formed
lations between them. By developing these by technical disciplines and distributed
diagrams and playing them against different systems, such as Guidance, Navigation and
organizational structures, it is possible to Control, Robotics, and Loads and Dynamics.
evaluate the proposed organizations in The panels are formed to address specific
simple terms and easily define the inter- programmatic management areas (i.e., as-
actions between the organizational ele- sembly requirements and sLage definition,
ments, thus helping to choose the most system design integration, and element de-
efficient management structure. The impor- sign integration) that span a number of orga-
tance of the logic diagrams will be discussed nizations. The reviews are formed to address
later. relatively broad program areas as shown in
Figure 5.
Program Management
Integration
Integration Mission
Engineering
Management Integration
Element System
Integration Integration
Figure 5 Space Station Freedom Technical Review Structure (1990)
.q7
Each organization is responsible for de- Internal vs. Matrix SE&I Staffing. As
veloping the integration plan in its area of already noted, SE&I has been staffed and
responsibility, monitoring the execution of accomplished in different ways in different
the tasks, identifying problem areas, and NASA manned programs. In the early
either resolving them or submitting them to manned space programs, the personnel
the overall program management structure required to accomplish the SE&I activity
for resolution. Although these organizations were assigned directly to the program and
by their nature do not perform work, the project offices. During the Apollo and Shut-
members, by working back through their tle programs, the program office had only the
functional organizations, greatly influence people necessary to manage the SE&I activ-
the work being accomplished in their par- ity, and most of the work was accomplished
ticular area of expertise. As rapport develops by technical experts assigned from the
between members, many potential problems Centers' functional organizations in a
and issues are identified and resolved with- matrix fashion. Although each method has
out being referred to formal management its advantages and disadvantages, the ma-
decision channels. In addition, the quality of trix approach generally has more advan-
the work materially improves. This ad hoc tages in that manpower can be increased or
organizational structure also provides obvi- decreased as needed by pulling support from
ous places for program elements to present the matrix organizations without reassign-
any issue for deliberation and resolution. All ing the people involved. The primary disad-
of the panels and working groups support vantage is that the leader of a particular
each review as needed, and submit their area does not report functionally to the pro-
open issues to the most appropriate review gram or project office, which means that the
for resolution. line of direction is not as strong. The
The reviews address broad issues and importance of this negative factor, however,
serve as a communication channel between is inversely proportional to the working
the panels and the working groups. Since the relationship between the organizations. In
reviews cover all of the panels and working the Space Shuttle program, this relationship
groups, they provide an excellent way of and the matrix approach worked well. In
assessing and recommending to manage- other programs, the relationship was not as
ment the interdisciplinary priorities of the good and direction through the matrix was
program. less effective. On occasion, program man-
Chairpeople of the panels and working agement appointed all panel and working
groups are the most qualified individuals group chairpeople from the program office
available in a particular discipline. Only sec- staff, giving less regard to the individual's
ondary consideration is given to selecting a personal qualifications. This led to a marked
person from a specific organizational ele- decrease in the stature of the ad hoc
ment. As a result of their recognized stature, structure, which then resulted in a lack of
the chairpeople provide leadership, which support from the functional organizations
makes their recommendations and decisions and a decrease in the quality of the integra-
more credible. The panels and working tion activity and products. As in many areas
groups also call in outside expertise when of SE&I, effective implementation relies
needed, but such outside inputs are filtered heavily on the quality of the leadership and
by the panels and working groups before the maintenance of free and open communi-
making a recommendation to the reviews or cations among the organizations involved.
other management organizations.
98
SE&I AND MANAGEMENT
21
Logic Networks. As the NASA manned means of determining status and managing
space programs have become increasingly activities in real time.
complex, it has become difficult to define the Associated with the EMS, a dictionary
specific content and tasks needed to accom- was prepared with an entry for each activity.
plish the SE&I function. Central to the de- Each entry identified all input information
velopment of a comprehensive SE&I plan is required to allow the accomplishment of the
the development of detailed logic networks, activity; described the contents of the pro-
which form the basis for planning, executing ducts; and identified the primary user of
and evaluating the SE&I activities. each product, the scheduled completion date,
As used in the Space Shuttle program, and the person responsible for preparing the
logic networks covered all of the SE&I activi- product. The EMS and the dictionary were
ties that had to be accomplished by all the primary tools for defining and communi-
elements of the program organization. Thus, cating SE&I activities throughout the entire
these networks were able to interrelate program structure.
SE&I activities both vertically and horizon- As would be expected, the content of the
tally throughout the program management EMS changes character over the life of the
structure. The basic summary logic net- program and accordingly, requires various
works were developed for the entire program technical capabilities over time. Early in the
duration, to identify all major activities program, the design activities involve a
required as a function of time, and were large number of trade studies and the devel-
instrumental in developing cost and man- opment of synthesis tools to be used in evalu-
power forecasts for the entire duration of the ating the capabilities of the proposed design.
program. Detailed logic networks were then As the program matures and the design so-
prepared for the near-term in the Shuttle lidifies, the activities become more involved
program for 12 months, identifying in with exercising the system models, conduct-
greater detail the specific activities to be ing tests and analyzing data. As the flight
accomplished by each organizational ele- phase approaches, the activities are pre-
ment during that period. The networks were dominated by operational considerations, in-
revised every six months to extend the detail cluding the development of operational data
planning horizon; in addition, the summary books, mission requirements, certification of
networks were reviewed and modified as system readiness, and support of mission
needed on an annual basis. The logic planning and real-time mission operations.
networks were a primary input to the devel-
opment of the engineering master schedules System Characterization Process. A
discussed in the next paragraph. major SE&I activity throughout the program
life span is the assessment of the capability
Engineering Master Schedules (EMS) of the system to meet specified requirements.
and Associated Dictionary. The activities In the NASA manned space program, this
identified in the SE&I integration logic net- has been accomplished in an analytic sense
works were then assigned to specific organi- by synthesizing the vehicle characteri-
zations for execution and presented as a zations in the form of either models or
schedule for each organization involved. By simulations, and then developing detailed
using a numbering system for the activities, performance characterizations by exercising
the logic network and the schedule could be the models against selected mission time-
easily correlated. The schedules allowed cost lines and significant mission events.
and manpower estimates to be prepared for The methodology used to perform the sys-
each organization and provided an excellent tem synthesis is central to the development
99
of the logic networks and schedules described pletion of one of the system characterization
earlier. An examination of the system usual- cycles is an excellent indicator of whether
ly reveals scenarios useful in conducting the the system design meets the specified
overall system evaluation; after selecting requirements. The engineering master
the most desirable scenario, it forms the nu- schedule gives a graphic representation of
cleus of the overall SE&I logic. In the Space whether the integration progress is being
Shuttle program, the scenario chosen was (1) achieved. Reports produced by the SE&I ac-
develop the necessary models and simula- tivity, such as resource allocation status and
tions; (2) determine the structural modal margins, interface control document status,
characteristics; (3) determine the loads on design reference mission maturity, and sys-
each of the system elements; and (4) perform tem operational data books indicate the
stress analysis of the system when subjected maturity of the element participation in the
to these loads. Using this scenario it was rel- system-level SE&I process.
atively easy to define and interrelate the
SE&I activities of other disciplines, such as Design Reference Missions. Most of the
GN&C, propulsion, and thermal, among manned space programs had to be capable of
others. After defining all of the required ac- performing a relatively large number of di-
tivities, a document was prepared to identify verse missions, and the specifications are
the models to be used, and the mission events written to allow hardware and software sys-
to be analyzed and to define the configura- tems and elements that are flexible enough
tion to be used. The sequence described to satisfy all of the missions. For analytical
above formed an analysis cycle of a specific purposes, however, it is convenient to define
configuration subjected to specific operation- and adopt one or more design reference mis-
al requirements. In the Shuttle program, it sions (DRMs) that stress all of the systems
was termed an integrated vehicle baseline capabilities to a significant extent. The
characterization cycle (IVBC). As previously DRMs are used as the primary mission re-
described in the SE&I scenario, several char- quirements in the system characterization
acterization cycles are needed during the cycles, and in evaluating the ability to meet
program: as the program matures, the cycles performance specifications. In addition to
have additional synthesis detail, more de- evaluating the baselined configuration
finitive configuration information, and bet- against the DRMs, other specification
ter operational information. requirements are evaluated by the accom-
At the completion of each of the charac- plishment of specific analyses or tests, as
terizations cycles, system deficiencies are necessary.
identified and modifications to either the The DRMs also allow the user community
system specifications or the requirements to evaluate whether the system is capable of
are made. For program management pur- meeting specific user needs and whether
poses, it is usually convenient to schedule these needs are specifically in the system
the completion of one of the characterization specifications. The DRM is used by mission
cycles to occur just before each of the major planners to determine the system's capabil-
program-level review milestones. ity of performing any specific mission under
consideration.
Program Reviews. SE&I has a large
input to each of the program-level reviews, Verification. Verification plays a major
such as system requirements review, pre- role in program planning and in the ultimate
liminary design review, critical designre- cost of the system. Although most of the
view, design certification review, and flight verification is delegated to projects, SE&I is
readiness reviews. As mentioned above, corn- responsible for identifying the overall
100
SE&I AND MANAGEMENT
verification requirements and specific all system requirements be evaluated

system-level verification tests and simula- against all of the as-built system capabil-
tions, which frequently require specialized ities, and where possible, the system mar-
facilities and significant amounts of system gins are quantified to assist the operations
hardware and software. Since these system- organization in planning and conducting
level verification tests are frequently com- flight operations.
plex and expensive, planning for them needs
to start very early in the program. The ICD Development. As the program
system-level verification network is devel- management organizational structure is
oped as an integral part of the program SE&I determined and responsibility for developing
logic networks and is baselined early in the hardware and software is delegated, it is nec-
program. essary to start the development of the
Final verification of some system require- interface control document (ICD) tree, which
ments can only be accomplished in the real identifies each required ICD and the content
flight environment, _nd these are demon- to be presented. As previously noted, the di-
strated in early operations before final certi- vision of program activities to minimize the
fication of system operational capability is number and complexity of interfaces has a
accomplished. It is also important to inte- strong influence on the overall program cost
grate the system-level verification planning and the ability of the program to meet sched-
and the operations planning to promote the ules. The early development of strawman
maximum synergism possible between sys- ICD trees can greatly assist in optimizing
tem verification and operational training. the overall program management structure.
In manned space programs, all of the As the program progresses and the system
major system level verification tests have configuration becomes better defined, the
been assigned to program or functional orga- content of each ICD is developed in more de-
nizational elements other than SE&I for tail and ICD working groups are formed to
implementation. This has helped to assure quantify the environmental, physical, func-
that the management of SE&I can remain tional and operational characteristics in
objective in the evaluation of overall certifi- detail. In most manned programs, the ICDs
cation adequacy. have been baselined at a relatively early
point in the program and have usually con-
DCR Process. One of the most signifi- tained a large number of TBDs (to be
cant activities of SE&I its role in the certifi- determined). After baselining the ICDs,
cation of the system design prior to the start working groups continue their work to arrive
of the flight operations and then later, prior at specific values for each of the TBDs and to
to committing the system to operating continually assess the adequacy of the ICDs
throughout the entire design envelope. SE&I as the design matures.
is instrumental in setting the overall re- The ICDs are primary documents at each
quirements for the DCR and is directly re- program review and provide a basis for eval-
sponsible for the system-level portion of the uating the adequacy of the items being
review. This process becomes the final major reviewed to satisfactorily function as part of
system characterization cycle, using a syn- the total system.
thesis of the as-built vehicle hardware and
software capabilities and results of tests and Program Management Organization-
analyses. DCR results also form the basis for al Structure. The efficiency of program
the system operational data books that are management is greatly influenced by the
used to plan and conduct the operational organizational structure selected. Organi-
phase of the program. The DCR requires that zational structures that are compact and
l_J)
simple promote effective program manage- maintenance of the complex bilateral sched-
ment. Compactness is measured vertically ules and support required. The complexity of
by the number of levels of the program man- providing support after the transfer of the
agement organization and horizontally by instrumentation was a significant manage-
the number of organizations at each level. ment problem throughout the entire time
Each additional organizational element that the development flight instrument was
significantly increases the manpower and used. In the Space Station Freedom program,
costs of achieving program integration, in- considering the many hardware and soft-
cluding SE&I. If each organizational ele- ware items that must be passed between
ment must interface with all others in the work packages, it will be difficult to develop,
program, the number of interfaces increases coordinate and maintain all of the interface
rapidly as organizations are added. Adding information required.
management levels increases the complexity
for delegating the execution of the program. Objectivity In Management. To pro-
This factor was evident to the Augustine mote objectivity in managing SE&I, one of
Commission in their recent summary report the basic ground rules in the Shuttle pro-
The Future of the U.S. Space Program, in gram was that the SE&I function would not
which they recommended that "multicenter be responsible for the development of any
projects be avoided wherever possible, but flight hardware or software products; thus,
when this is not practical, a strong and inde- they had no conflicting pressure to make
pendent project office reporting to Headquar- their development job easier at the expense
ters be established near the Center having of another organization. It was found that
the principal share of the work for that any bias, either perceived or real, immedi-
project; and that this project office have a ately brings the objectivity of management
systems engineering staff and full budget into question and rapidly destroys the confi-
authority." dence between organizational elements.
In addition to keeping the management
structure compact, it is also very important Need for Good Communication. The
to select an architecture that divides the nature of SE&I is such that most of the pro-
program into project offices, to enable simple gram elements and many other agency orga-
interfaces between projects and delegation nizations are involved in the execution of
that is all-encompassing. All of the deliver- SE&I tasks. To facilitate accomplishment of
able hardware assigned to a given project the work, the importance of free and open
should be the responsibility of that project to communication cannot be overstressed. One
design and manufacture. In all manned of the ways of accomplishing this is "to live
programs prior to the Space Station, there in a glass house." All decisions and, of equal
was little transfer of hardware and software importance, the logic behind those decisions
between projects--with one exception, that must be communicated to all parties
being the development flight instrumenta- involved if they are to understand their role
tion in the Apollo program. and how it fits into the overall picture. All
Early in Apollo, a decision was made to parties must feel that their inputs are in-
establish a civil service project office to cluded in the decision-making process. This
develop, procure and deliver the specialized openness, and the accompanying feeling of
development flight instrumentation to the vulnerability, is often not welcomed and
prime spacecrai_ contractors for installation requires faith and confidence between the
and integration in the early spacecraft. organizations involved. The fact that mis-
Coordination of the large volume of interface takes will be made must be accepted, and all
information required the development and organizations involved must constructively
102
SE&I AND MANAGEMENT
assist in correcting them. Frequent open elements take a common approach to the
meetings of the ad hoc organizational ele- implementation of SE&I. This is difficult to
ments described above have proven to be an accomplish using the normal program office
effective tool in developing rapport between organizations because they cannot directly
peers and communicating information and address inter-organizational communica-
decisions throughout the program structure. tions and have difficulty managing across or-
As noted earlier, however, such meetings ganizational lines. The ad hoc organizational
become increasingly time-consuming and structure, on the other hand, is made up of
expensive as the complexity of the organiza- specialists from each of the affected organi-
tional structure is increased. zations, and their activities directly promote
inter-organizational communications. Using
Importance of Margins. At the time this technique, technical peers can plan and
programs are initiated, they are frequently monitor the execution of specific SE&I ac-
sold on the basis of optimistic estimates of tivities. When a resolution cannot be reached
performance capability, cost and schedules. within the ad hoc organization, the issue can
This often results in reducing margins to low be referred to the proper program manage-
levels at program initiation and solving ment office for decision.
early program costs and schedule problems
by reducing weight, power and other re- Standard Organization Structure
source margins. As a consequence, margins within the Program and Project Offices.
are reduced to zero or negative values early During the Apollo program, the program di-
in the program, making it necessary to modi- rector decided to have all of the program
fy the program to either reduce requirements management offices at both Level II and
or introduce program changes that will Level III adopt a standard organization
reestablish positive margins. The recovery of structure: five offices reported to the
the margin inevitably leads to significantly program manager and the same five offices
higher ultimate program costs in both reported to each project manager. This tech-
dollars and days. Minimum life cycle costs nique assured that the work breakdown
are achieved by holding relatively large structure was similar for all offices, that
margins early in the program and then direct counterparts could be identified in
allowing them to be expended at a prudent each of the offices, and that budget alloca-
rate during the program life cycle. tions flowed down in a uniform and predict-
able manner. All of these features resulted in
THINGS THAT HAVE WORKED WELL less cross-linking between organizations and
made the required program management
In the management of the manned space pro- activity more rational and predictable.
grams' SE&I activities, several approaches Although the specific office structure chosen
have been particularly successful. Some of would be different for each program, having
the most important, have been discussed pre- uniformity between the Level II and Level
viously but are readdressed here because of III management offices should be considered
their assistance in the management of SE&I. for future programs.
Ad hoc Organizations. The use of ad System Characterization Cycles. Con-

hoc organizations to coordinate SE&I activi- structing the SE&I plan and identifying the
ties has proven to be a valuable tool. The required tasks is a very complex under-
effectiveness of SE&I depends heavily on taking in large programs. As previously
good communications between organizations described, it is best to have a well-defined
and the assurance that all organizational core of activity that, when completed, will
103
READINGS IN SYSTEMS ENGINEERINQ
characterize the capability of the system to Use of a Prime Development Contrac-

meet the specified requirements. Analysis of tor to Provide SE&I Support. In the
the results reveals deficiencies and allows Shuttle program, the SE&I support contrac-
modifications to either the requirements or tor was also the prime contractor for the de-
the system design to be identified, thus as- velopment of the Space Shuttle orbiter.
suring an adequate margin of performance. Although there was considerable concern
Building on this core analysis cycle, it is rel- about the ability of the contractor to main-
atively easy to plan the other SE&I tasks in tain objectivity in supporting SE&I, this con-
a consistent manner, and create a complete cern was reduced to an acceptable level by
characterization of the system capability. separating the direction channels of the
development and integration activity both
Matrix Management Organizational within NASA and within the contractor's
Approach. The concept of staffing the organization. The support contract was also
program management office with a small set up with an award fee structure in which
number of people who serve as managers SE&I was responsible for providing inputs
only and then augmenting their capability for the SE&I activities. There were many
with personnel drawn from other Center or- advantages in this arrangement:
ganizations in a matrix fashion has signifi-
cant advantages. Manpower can be brought a) The integration personnel were familiar
in from the organizations only when it is with one of the major program elements
actually needed, and the technical composi- and did not need to become familiar with
tion can be changed over time to satisfy pro- that element or the general program
grammatic needs. The quantity of personnel structure.
can be augmented to meet program needs,
i.e., during major program reviews; the per- b) Technical experts could be made avail-
sonnel involved can be assured of a career able for both activities as needed.
path in their parent organization; and the
individuals involved can continually replen- c) Many of the synthesis tools required by
ish their expertise by participating in the both activities were similar, and fre-
R&D activities of their parent organization. quently one model could be used for both
This mode of operation has been quite purposes with only minor modifications.
successful and has demonstrated several
additional advantages, such as reducing fric- d) Uniformity in approach assured ease of
tion and undesired competition between the comparison of results from both project-
program office and Center functional organi- level and program-level activities.
zations, improving technical communica-
tions across programs being implemented The management of SE&I in NASA man-
simultaneously, and providing an efficient ned space programs has developed over the
way of phasing the development program last 30 years to satisfactorily integrate
into an operational role. In particular, the relatively complex programs. Some of the
assignment of program-level SE&I to a Lead approaches and techniques described in this
Center, coupled with the execution of this paper may be helpful in integrating future
assignment using Center functional organi- programs. Careful consideration of the
zations in a matrix fashions, allows the pro- organizational structure and systems archi-
gram to take advantage of both the quality tecture at a start of a program has an
and quantity of technical expertise available overriding effect on the effort required to
throughout the Center. accomplish the SE&I activity.
104
THE SYSTEMS ENGINEERING ROLE IN TOP-LEVEL REQUIREMENTS
THE SE ROLE IN ESTABLISHING, VERYIFYING AND

CONTROLLINGTOP-LEVEL PROGRAM'REQUIREMENTS
by Charles W. Mathews p _ /0
People working in the field of systems engi- The need is to focus on program require-
neering have differing views as to the range ments during all phases and facets of a
and depth of this subject. Without venturing program, e.g. definition, development, man-
into the controversial arena of specific defini- ufacturing, testing, operations, growth and,
tions, I will assert that systems engineering most important, effective use or mission
has much to do with the definition, evalua- accomplishment. The effort just described in-
tion and control of the technical effort aimed volves the entire systems engineering task;
at achieving the objectives of a program. however, the main emphasis of this paper is
Efforts in the field of systems engineering the interaction of the systems engineering
may in fact go well beyond purely technical process with the top-level program require-
considerations, e.g., when cost or political ments. This aspect of systems engineering is
considerations impact the technical ap- often given inadequate attention during
proach to a program. In this context, the certain phases of a program. This paper will
systems engineering process must function endeavor to answer such questions as:
to maximize the probability that a program's What is meant by top-level program re-
technical requirements can be met while at quirements, and who generates them?
the same time recognizing and including How are these requirements validated,
other program factors and constraints. New altered, and controlled by the systems engi-
constraints as well as technical problems can neering process?
be encountered at all stages of a program, What capabilities are needed to accom-
often necessitating some adjustment to the plish such efforts effectively?
program objectives and requirements. Such
activities are part of the systems engineer- WHAT ARE TOP-LEVEL PROGRAM
ing process, which must begin immediately REQUIREMENTS?
at the start of a program and continue
throughout the life of the program. Top-level program requirements are directly
Sometimes a program manager will con- related to program objectives or systems uses
centrate on insuring that hardware elements determined and stated early during the
perform well and all play well together, program definition. Probably the most re-
assuming that this alone will enable the membered program objective of the past was
program requirements to be met. Then on to "land men on the moon and return them
entering the operational phase, while the safely to Earth." The program requirements
system may indeed perform, it may not do that emerged from early studies included,
what was intended. This situation frequent- among others, one to two-week mission dura-
ly occurs because many engineers, scientists, tions, lunar landing, extravehicular activi-
managers, and yes, even administrators tend ties, launch from a remote site, rendezvous,
to be intrigued by and want to concentrate and reentry from near escape velocity, all of
on configuration selection and design prob- which had never been accomplished at the
lems. It is the responsibility of the top-level time of President Kennedy's statement.
systems engineering professionals to be the These requirements in turn highlighted
conscience of all participants in making sure the need to define and validate specific
that program requirements are met or prop- technical approaches--redundancy concepts,
erly adjusted. simple system interfaces, new technology
105
NAL MONOGRAPH SERIES: SYSTEMS ENGINEERING PAPERS
requirements (e.g., fuel cells), operational performance in accomplishing these mission

demonstrations such as Gemini, entirely and configuration demonstrations.
new configurations such as the LM, and the It is important to firmly establish which
nature of the flight program buildup. Inci- of the above two categories reflect the real
dentally, many of the program requirements program objectives because a capability
for Apollo determined the mission objectives demonstration has a higher potential for suc-
for the earlier Gemini program. In any cess than a tightly specified use commit-
event, program requirements must be estab- ment. The systems engineering organization
lished early and stated distinctly so that all should be providing top-level program man-
necessary steps for meeting and validating agement with the information to make such
them can be determined. This effort is a fun- determinations. The program objectives may
damental systems engineering function. vary during program implementation be-
cause of early "selling" pressures or because
Types of Program Objectives and of unforeseen technical problems When this
Requirements happens, the systems engineering organiza-
tion should provide concrete evidence to
The program objectives and requirements management so that a strategy can be devel-
described in the preceding paragraphs em- oped to properly inform the outside world,
phasize mission demonstrations. Obtaining e.g., Office of Management and Budget
desired science or applications information is (OMB), Congressional committees and the
another type of program objective. The pro- media; if the outside elements are not made
gram requirements then state the need for to understand and accept such changes in a
specific data, usually specifying a particular timely way, support can be alienated,
instrument or instrument set; the operating placing extreme pressure on the program.
conditions under which the data is to be ob-
tained (e.g., orbit altitude, field of view, and Establishing Priorities
pointing accuracy); and the data handling
and use. Conversely, a new instrument may When a large number of objectives and asso-
be conceived or created with the program ob- ciated requirements are included in a given
jective to establish its use potential. The program, an additional complication occurs.
Multispectral Scanner employed in the Several past programs qualify including pro-
Landsat program is an example. grams as early as Gemini and space station
Another space program category includes programs such as Skylab. Even Apollo, with
service functions such as Earth-to-orbit its simply stated mission objective, had
transportation or a space laboratory. In the many secondary objectives associated with
first case, the program objective might be lunar exploration and lunar science. It is
economical and an easy access to the space very important to establish priorities with-
environment for the using community. Pro- out precluding the accomplishment of objec-
gram requirements then include such pa- tives of lower priority. For example, the two
rameters as dollars per pound to orbit, top priorities in the Gemini program were
launch frequency and payload integration demonstration of long duration flight and
lead times. Conversely, in this case, the rendezvous, but large quick-opening hatches
program objectives might also be stated in were incorporated to accommodate extrave-
terms of capability demonstrations such as hicular activities (EVA) and the spacecraft
the reentry of a winged spacecraft, ground structure was designed to permit the firing
landing and reusability. The program of a large propulsive stage once docked to it.
requirements then are related to system Most of these secondary objectives were
106
accomplished. In fact, because of the way the WHO GENERATES TOP-LEVEL PROGRAM
actual flight program developed, EVA was REQUIREMENTS?
one of the first accomplishments. The secon-
dary program objectives also afforded some A program objective can be conceived and
flexibility; the paraglider system planned for stated initially by almost anyone working at
use in ground landing, for example, was any level, from the President, as in Apollo, to
dropped from Gemini in order to meet cost others on down. If considered seriously, such
and schedule objectives. an objective is studied to determine its valid-
To summarize what has been stated thus ity, practicality and usefulness. Sometimes
far, a number of classes of top-level program it takes a short time to obtain a go-ahead;
requirements exist. They can be associated sometimes it takes many years, as on the
with mission objectives, scientific investiga- Space Station. One of the fallouts of these
tions or space services, among others. In efforts should be a clear statement of top-
addition, different ways of looking at top- level program requirements.
level program requirements include demon- The involvement of the right people in
strations as compared with tightly specified the generation of top-level program require-
commitments. Many programs have multi- ments is extremely important. Depending on
ple requirements. Nevertheless, it is impor- the nature of the program, this involvement
tant to 'zero in' on these requirements early can include customers, users, operators and,
in the systems engineering process, i.e., of course, designers and developers. Program
during Phase A. Most important, they must managers and directors, however, should
combine to realistically meet the stated guard against limiting involvement in this
objectives of the program; they must be activity to just the latter two. Systems engi-
prioritized when necessary; and they must neering, should be involved early to assure a
be clearly stated and documented in the reasoned and logical approach to the genera-
Program Requirements Document. tion and iteration of program requirements.
These requirements may have to be In the space science and applications
changed, adjusted or reprioritized as the arenas, program requirements are frequent-
program proceeds, and any changes must be ly generated by a process that begins with a
carefully controlled and formally approved program objective or a flight system capabil-
at the top level of the program throughout its ity being stated in an "Announcement of
life. If program objectives are affected, a Flight Opportunity." Investigators are then
decision by the administrator is required (at selected through evaluation of the responses
least for medium-to-large programs). The obtained. The experiments selected deter-
outside world needs to be kept abreast of mine the actual requirements of the flight
significant changes in objectives or top-level program. Other inputs are often required, as
requirements so that no sudden surprises adjustments may be needed in consideration
occur that affect support. of technical limitations or program costs, for
The systems engineering function should example. The analysis and resulting output
provide the initial evaluation and validation of the systems engineering group usually
of the top-level program requirements and gives rise to an iteration of the program
should continue to evaluate proposals or requirements, which again involves the sci-
events that would produce any change. The ence team. Frequently, a selected proposal
effort should occur at the top level of a dis- provides for excellent science but does not
tributed systems engineering function and deal adequately with other constraining
guide upper level program management and technical considerations and the cost impli-
the administrator. cations associated with the overall effort.
107
Hierarchical Consideration in development and systems integration is not

Requirements Generation an important facet of systems engineering.
There are instances where these consider-
In all classes of space flight programs, the ations are at the top of the requirements
systems engineering organization should hierarchy. An instrument demonstration
work closely with groups having expertise in such as the Multispectral Scanner is one case
and cognizance over program requirements. in point, and the Advanced Communications
In Apollo, because the primary program Technology Satellite (ACTS) is another tech-
objective was oriented to the accomplish- nology demonstration of this type. In most
ment of a specific mission demonstration, respects, the research airplanes such as the
operational personnel--particularly those X-1 and X-15 fit into this category. However,
involved in flight operations--tended to be this case does not fit the situations occurring
near the top of the program requirements in most NASA programs. It is therefore criti-
hierarchy. Even though science re- cal for top-level program management to
quirements existed and science teams and examine its program, determine who the
advisory committees were active, the science main contributors or generators of the pro-
requirements were of lower priority, at least gram requirements are, and assure that they
until after the first lunar landing was accom- are interfacing adequately with the systems
plished. In contrast, a program such as engineering function. This need exists at the
Skylab always included the solar scientists outset of the program but should continue
and Earth resources investigators, among through the design and development phases,
others, at the top of the requirements hierar- for as hardware and software systems prob-
chy, even though the engineering and lems are encountered, the tendency is to
operations personnel may have been focus on them, and top-level program re-
somewhat confused by this arrangement. quirements can be altered or even disappear
The Space Shuttle involves still another without due consideration.
situation. The operations groups can be per-
ceived to be the customers for the system, WHO VALIDATES TOP-LEVEL PROGRAM
but the real users at the top of the hierarchy REQUIREMENTS?
are the scientists, commercial firms, indus-
trial experimenters and NASA engineers Activities that validate top-level program
who provide the payloads that fly on the requirements are mostly of a systems en-
Space Shuttle or conduct related experi- gineering nature. This validation, is an
ments or other use functions. This is similar important, though small, part of the total
to the relationship between passengers and systems engineering job. In total, systems
shippers, the airlines, and the commercial engineering, particularly during design and
airplane developer in the air transport development, is a distributed activity. Space-
industry. In addition to general operating ef- craft hardware systems such as electrical
ficiency, consideration must be given to user power, attitude control and communications
accommodation from the start. Such needs all have to be systems engineered. Total
are now quite successfully accomplished in systems elements (e.g., a launch vehicle
commercial aviation. Naturally, expecta- stage, a checkout facility, a launch complex
tions are less in the case of the Space Shuttle and a flight control center) all have to be sys-
because of its experimental nature, but it is tems engineered to correctly perform their
fair to say that user accommodation has not functions. In the end, all elements involved
been accomplished to the degree desired. in a program--the total flight system, the
The foregoing discussion is not meant to operational support facilities, the mission
imply that successful hardware design, planning, and the user integration, among
108
others--need to be brought together in a Phase A efforts are aimed at selecting

timely fashion to meet the program objec- and analyzing a single programmatic and
tives and requirements. An effort of this na- technical approach, at least in theory, to best
ture, even for a very modest program, is too meet the requirements of the program.
complex to be handled in a purely top-down Again, the Phase A activity is chiefly a sys-
fashion. The cardinal rule is that all the in- tems engineering effort usually conducted by
terfaces at any particular level, both hori- a single team at a single location. If a work
zontally and vertically, should be as clean breakdown structure with clear interfaces
and simple as is practical. can be established at this time, then systems
engineering at multiple locations may be
Validation Efforts During Program possible. In any case, the group that worked
Definition during the pre-Phase A study needs to be
augmented considerably, and the support of
At the start of program evolution, practically one or more contractors is frequently
all of the mainstream effort is of a systems obtained.
engineering character and is more top-down In this phase, emphasis should be placed
than later in the program. The validation not only on hardware but on validating the
effort begins in pre-Phase A, where options mission design and other operational or use
are examined for meeting the program objec- aspects of the program. This emphasis is par-
tives as well as certain initially stated pro- ticularly important where the operational
gram requirements. These requirements life of the program is envisioned to be very
should endeavor to incorporate most of the long, e.g., Space Shuttle, Hubble Telescope,
major program factors but are usually gener- Space Station and the Earth Observing
al and often are quite optimistic. All aspects System (EOS). It is important to clearly
of the technical and programmatic approach establish what is required in the operational
should be studied. Although effort is limited phase and to establish with adequate confi-
in this phase, a determined attempt must be dence the feasibility of accomplishing the
made to establish and to ascertain the feasi- programs with realistic operational costs
bility of meeting the program requirements. and schedules.
This work should usually be accomplished by At the time the program enters Phase B,
a team working at a single location, a complete work breakdown structure should
although supporting effort and information be established, including all facets of the pro-
can be obtained from groups in other loca- gram with simple and clear interfaces and as
tions. There have been cases where alterna- little overlap as possible. Program work
tive approaches are studied by separate assignments will be made. For moderate to
teams, which has proved to be effective in large programs, these assignments may
some pre-Phase A efforts. In all likelihood, involve program groups at different geo-
the program requirements will be changed graphic locations, including parts of the total
and expanded to account for such factors as systems engineering effort. The top-level
technology readiness, knowledge of the program requirements should have been
operating environment, mission complexity established in adequate detail, and each
and similar factors. A need for additional program organizational element should
technology development or operational regard these requirements as program con-
verifications may be identified as well. Any straints.
pre-Phase A study that is completed with The program requirements or even the
everything looking rosy should be viewed objectives can be changed because of unfore-
with caution. seen events or other activities occurring
109
throughout the course of the program, but group is the guardian and conscience of the
they should be subject to formal change top-level program requirements but by no
control. Obviously this particular change means includes the total systems engineer-
control activity deals with top-level program ing effort. The group should be composed of
requirements and must occur at the highest engineering personnel, each of whom has
level in the program; in certain cases, the considerable technical experience in one or
administrator should be informed of an more of the applicable areas and possesses a
impending change and must be informed natural talent and desire to deal with all
when program objectives are significantly aspects of the program. The individuals
impacted. should be selected so the group encompasses
as many of the technical, scientific and
Validation Efforts During Design, programmatic disciplines involved in the
Development and Operations program as possible, but the group does not
have to be large. By selecting people with the
Although the top-level systems engineering right backgrounds and talents, the work can
effort in the definition phases of a program is be done in part by obtaining information
important, this function is critically impor- from other elements of the program--in
tant in Phases C/D, the design and develop- particular, other systems engineering
ment phases. It is during this time that most groups.
of the technical difficulties and other pro-
gram limitations surface. There is a strong HOW ARE TOP-LEVEL PROGRAM
tendency to focus on the flight hardware and REQUIREMENTS CONTROLLED?
to get it delivered and flying. These situa-
tions sometimes allow the top-level require- Control of top-level program requirements is
ments to "fall through the cracks," later extremely critical to program success. This is
producing surprises, embarrassments and not to say that such requirements cannot be
undue pressures, which can contribute to the changed. Almost without exception changes
potential for accidents and failures in the will occur, but they must be carefully
operational phase. controlled by a well-defined process that es-
Systems engineering must continue tablishes the change impact on the program,
throughout the operational phases of a pro- particularly its objectives. This process also
gram. Although the character of the top- must inform program participants inside
level activities change, there still is a need to and outside the program organizational
deal with program requirements and their structure, including those having responsi-
alteration. Some of the possible subjects are bilities or scrutiny from above.
the rate and nature of the flight program The program director is the individual
buildup, working around performance who is personally responsible for the integri-
deficiencies or failures, and adjustments to ty and control of the top-level program
mission objectives. On the positive side, the requirements. As such, the program director
top-level systems engineering in the oper- must assure that a Program Requirements
ational phase involves the incorporation of Document is produced during Phase A and
new system capabilities and mission exten- that it is properly updated immediately
sions, including the development and control following a change. This effort is supported
of the associated program requirements. mainly by the program director's systems
Support to the activities just described is engineering group described in previous sec-
accomplished by a systems engineering tions. This group is responsible for analyzing
group also operating at the highest level in any proposed change that could potentially
the program's organizational structure. This impact the top-level program requirements.
110
The analysis can be done by the group itself attend design reviews and other program
or by support groups, including contractors. reviews associated with all the program ele-
The analysis must specifically include in ments. They must be able to have free infor-
writing how the affected requirement(s) mation exchange with other program and
would be changed and the determination of project personnel and to accompany them on
other impacts such as cost or schedule, which visits to contractors when the occasion
could be either positive or negative. demands. These activities are best accom-
plished if the group and its members operate
Change Control of Program with a low profile. They should not give or
Requirements imply directions or conclusions in discus-
sions with program and project people. All
Change proposals are brought before a direction as a result of their work should
standing committee, usually called a change come from the program director. Naturally,
board, selected by the program director. these individuals must be able to request
There will be other change boards through- and analyze program documentation, but all
out the program, but this one should deal such activities should be done in a way to
only with top-level program requirements. maintain good rapport with other groups
Anyone who proposes a legitimate change in working in the program.
the program requirements should be able to
come before this board. In general, individu- TOP-LEVEL PROGRAM REQUIREMENTS IN
als who have a significant input should also PREVIOUS PROGRAMS
be invited. The proposed change is usually
presented by its sponsor and is followed by a In general, most of NASA's past major pro-
presentation of the analysis of the systems grams have successfully met their program
engineering group. Following discussion, the objectives and must have fulfilled their pro-
program director makes the disposition, gram requirements. Some brief observations
which can include acceptance, rejection, or a of the results obtained during some of the
requirement for further analyses or informa- previous manned programs may provide use-
tion. Following an acceptance, the Program ful insight into future programs. Although
Requirements Document should be changed the very early programs were not explicitly
immediately. Regardless of the nature of the divided into program phases, in retrospect, it
decision, the affected elements of the pro- is possible to discuss them within a phased
gram organization need to be informed im- context.
mediately. Affected elements outside the
program should also be informed in a timely The Mercury Program
manner but only after an appropriate strate-
gy is developed. The Mercury program objective was to place
One of the chief difficulties associated a manned spacecraft in orbit around Earth
with this change control activity is that and return safely. In pre-Phase A, several
events that impact the top-level program re- winged (lifting) configurations were studied
quirements can occur at any place, at any as well as the so-called "capsule." The cap-
time and at any level in the program, and sule was selected on the basis of greater
there is a natural tendency to try to fix a technical simplicity and limitations on
problem at its source without passing on launch vehicle payload capability. In Phase
information. Several things can be done to A, in addition to developing the spacecraft
alleviate this difficulty as it relates to the systems specifications, safety requirements
activities of the top-level systems engineer- were emphasized, including the proper posi-
ing group. Individuals in the group must tioning and support of the crew to handle
lll
launch and reentry accelerations, which duration flight, e.g., the Atlas-Agena target
were demonstrated on a centrifuge; the con- vehicle, orbit maneuvering system, rendez-
cept of a system to escape from the launch vous radar, fuel cells, and the cryogenic
vehicle if necessary; and the layout of a storage of hydrogen and oxygen in a super-
worldwide tracking and monitoring network. critical state. Again, considerable develop-
In Phase B, a full-scale demonstration of the ment problems emerged, largely associated
reentry heat protection system was conduct- with the newer systems, such as ablative
ed, and the results produced minor design thrusters and fuel cells. Problems were also
changes. The concepts of flight control and encountered in the flight program. The ini-
recovery were evolved, including a mission tial rendezvous exercise revealed inadequate
control center and flight controller deploy- attention to mission design, which was later
ment to remote sites, worldwide communica- corrected, and several classes of rendezvous
tion for near real-time surveillance of the were successfully demonstrated. The extra-
missions, and recovery procedures involving vehicular activities revealed deficiencies in
ship deployment. training, and neutral buoyancy simulation
The spacecraft configuration and specifi- was introduced late in the program.
cations proved to be satisfactory although One significant systems engineering
considerable development problems were achievement emphasized the checkout
encountered. The biggest systems engineer- systems and checkout procedures, and the
ing problem was associated with the lack of delivery of flight ready spacecraft. To gain
appreciation of the difficulties in conducting confidence, many of the checkout personnel
factory and preflight checkout. The checkout at the Cape were sent on temporary duty
required more or less continuous human (TDY) to the factory to participate in the
presence in the extremely confining interior factory checkout of the early spacecraft. This
of the spacecraft, producing wire breakage approach allowed the ten manned flights to
and other damage. These conditions were take place on about two-month cycles and
severe enough to curtail the flight program, contributed immensely to the on-time
although six manned flights were made, launches required for rendezvous.
building up to a duration of approximately
one day in orbit. The Apollo Program
The Gemini Program The Apollo Program was characterized by a

disjointed definition program. Because of the
The pre-Phase A activity concentrated large- obvious schedule pressures, certain contracts
ly on correcting some of the basic problems involving Phase B-type effort were let before
encountered in Mercury, i.e., a Gemini either the mission design or the lunar
spacecraft design that had most of the equip- landing mode had been selected. For exam-
ment outside the pressure vessel and was ple, the command and service module con-
also checkable from the outside, allowing a tract was awarded while questions about the
relatively clear cockpit area. The spacecraft use of Earth orbit rendezvous, lunar orbit
was enlarged to provide for a two-man crew, rendezvous, and the so-called direct ascent
but the basic external configuration and heat were still being debated. Sufficient pre-
protection system of the Mercury spacecraft Phase A effort was completed to enable a
was retained. decision to go with the lunar orbit rendez-
Most of the Phase A activity involved vous route in the spring of 1962, but the
defining the mission objectives, in support of Phase A work on the lunar module, even
Apollo, and the related program require- when accomplished in-house on a highly ac-
ments associated with rendezvous and long celerated schedule, did not allow the lunar
112
module contractor to be selected until nearly program. The program first known as Apollo
a year after the selection of the command Applications started out as a series of single-
and service module contractor. This situa- mission flights involving a larger number of
tion proved to be very distracting to the scientific and technical experiments. This
latter and resulted in major inefficiencies in program concept was the basis for approval
the contracted effort caused by premature in the President's budget for FY 1968. About
work force buildup. the same time, a command decision was
What saved the situation was the main- made to incorporate these experiments in a
tenance of simple interfaces between the two concept known as the "wet workshop," in
spacecraft. In fact, not much more than a which a spent upper stage of the Saturn V
docking interface existed; however, there would be left in orbit, purged, occupied and
was also an important structural interface outfitted to perform the experiments. Many
recalling that service module propulsion was believed the concept could not work, but the
used to place the docked configuration in program proceeded to preliminary design
lunar orbit. No support was required be- and, in many cases, detailed design. In the
tween the two spacecraft except status moni- spring of 1969, a decision was made to go to a
toring, and no commonality of systems was "dry workshop" wherein all the flight hard-
specified, although by some rationales, this ware elements would be assembled and
approach appears inefficient. The simple checked out on the ground and launched us-
system organizational and programmatic ing the first two stages of the Saturn V as the.
interfaces obtained greatly benefited the launch vehicle. It took another four years of
program. It was also the approach taken in design and development to bring the pro-
connection with other elements of Apollo. gram to flight readiness. The flight program
The operational phase of the Apollo pro- was quite successful in the accomplishment
gram provides good illustrations of systems of the many experiments. The data obtained
capability extension and mission extensions. from a large solar telescope, for example, the
The major extensions to the lunar surface Apollo Telescope Mount (ATM), was regard-
stay-time of the lunar module is an example. ed as outstanding by the scientists involved.
The decision to accomplish this was made This capability was included in the earliest
about the time of the first lunar landing, and program requirements.
a Headquarters systems engineering group
provided the impetus for the validation. An- CONCLUDING REMARKS
other capability extension was the addition

of the lunar rover contract, awarded about This paper has endeavored to highlight the
six years after the Apollo start but before the importance of generating top-level program
first lunar landing. Both these added capa- requirements at an early stage in the pro-
bilities greatly enhanced the lunar surface gram evolution or Phase A definition phase.
science and exploration aspects of the Apollo These requirements should include all the
program. factors involved in meeting the program-
objective(s) and should be stated with clarity
The Skylab Program so a determination can be made as to wheth-
er they can or are being met. Depending on
The definition activities of the program that the nature of the program, these require-
ultimately became Skylab proceeded in what ments can relate to uses of a capability, a
must be described as a highly confused state; mission objective or other factors, including
most of the program objectives and user- a simple hardware demonstration such as a
oriented program requirements, however, test of a new instrument. It is critical to
remained stable for the entire duration of the understand whether specific performance
113
requirements are to be met or only a demon- distributed activity that allows the top-level
stration of capability is entailed, for the systems engineering organization to be rela-
latter provides more flexibilityfor program tively small because it depends on others for
adjustments. most of the required analysis. It should oper-
The establishment of program require- ate with a low profile.
ments usually requires input and involve- Past programs serve to illustrate the
ment of people both inside and outside of the range of program requirements consider-
program organization. Determination of just ations and the associated systems engineer-
what disciplines are involved is important, ing effort. In the early manned programs,
particularly forthe users and operators. safety was a dominant consideration. Exper-
Validation of the top-level program ience in these programs showed that
requirements is a systems engineering func- preflight checkout is an important consider-
tion. At the outset, the systems engineering ation, as is mission design, training, and
organization works with entitiesresponsible simulation, all of which can impact the hard-
for generating the requirements in an ware design.
iterative process to assure their validity. The top-level program requirements and
This activitycontinues throughout the lifeof the associated systems engineering activi-
the program because of unforeseen events ties should obtain and maintain simple
that impact the program effort. At times, interfaces between program elements, even
this will necessitate changes to top-level though this produces some apparent pro-
program requirements. Changes should be gram inefficiency. At least one past program,
under formal change control, and the sys- Skylab, has shown that top-level program
tems engineering organization operating at requirements can be maintained even when
the top of the program organization struc- considerable fluxing occurs with regard to
ture should be responsible for the validation the hardware and mission design.
effort. Systems engineering is a program-
114
COST CONSIDERATIONS IN THE SE PROCESS
N93-
THE IMPORTANCE OF COST CONSIDERATIONS IN THE
SYSTEMS ENGINEERING PROCESS
by John D. Hodge ¢_ _-" / /
One of the most vexing aspects of managing high technology and, in the long run, our
large programs within NASA (or any other way of life.
high technology government programs) is
how to allocate program funds in a way that BASIC PRINCIPLES
is best for the program. One of the major
reasons is that the role of cost changes The principles are simple. First, define very
throughout the phases of the program. An- carefully what it is you are trying to do.
other reason is that total cost is not all that Check everything you do against that base-
easy to define; yet another is that funding, line, even if it has to be changed, and resist
which is based on annual appropriations, is change once the decisions have been made.
almost never consistent with fiscally effi- Second, break up the program into manage-
cient program spending rates. The net result ably sized chunks of deliverables that can be
is that program costs almost always escalate measured in terms of cost, schedule and per-
and inordinate amounts of time are spent formance, and define the interfaces between
controlling costs at the expense of maintain- the chunks. Third, continuously assess the
ing performance or schedule. risks to success as the program proceeds, and
Many studies have been performed to try modify only as necessary.
and understand this problem. They show
that program costs will escalate by at least a REQUIREMENTS TRACEABILITY
factor of three, from approval to completion.
The studies suggest a number of guidelines Most studies have shown that the primary
that should be followed if costs are to be kept reason for cost escalation is that not enough
down, including clear definition of require- time or resources are spent in defining the
ments, stable management and strong cen- program. It is clear that you cannot control
tral control. Unfortunately, these factors are what you have not or cannot define. It is dur-
not always under the control of the program ing this period that some of the most elegant
manager. systems engineering should be performed,
This paper examines the question of cost, especially in understanding the cost of every
from the birth of a program to its conclusion, requirement and its systems implication.
particularly from the point of view of large Even if the definition is adequate during the
multi-center programs, and suggests how to early phases of the program, it is imperative
avoid some of the traps and pitfalls. Empha- that great vigilance be exercised in main-
sis is given to cost in the systems engineer- taining the baseline definition of the pro-
ing process, but there is an inevitable gram and the fundamental reasons for doing
overlap with program management. (These the program. This process establishes a
terms, systems engineering and program small but influential part of the program
management, have never been clearly de- office, preferably within the systems engi-
fined.) In these days of vast Federal budget neering organization, dedicated to the trace-
deficits and increasing overseas competition, ability of requirements and to ensuring that
it is imperative that we get more for each a clear path exists from program rationale to
research and development dollar. This is the program requirements to systems require-
only way we will retain our leadership in ments to systems design. Too often, once a
115
design has been established, changes are PROGRAM RISK ANALYSIS
proposed and enacted that bear little rela-

tionship to the original premises of the In recent years, especially since the Chal-
program. As will be discussed later in this lenger accident, program risk analysis has
paper, there are many reasons for change, come to be used largely in the context of crew
but where possible, changes should be con- safety, but this is only a part of program risk.
sidered during the formulation of the pro- Basically, program risk analysis assesses the
gram and not later when the program struc- probability of meeting requirements as
ture is in place and the program is in changes occur. A number of analytical tools
progress. Change is almost always costly; now available can be used to understand the
requirements traceability provides a bul- relationships between cost, performance and
wark against which the program manager schedule. Again, a small group within the
and the systems engineer can stand and systems engineering organization should be
defend. dedicated to understanding the impact of
any change on all three parameters. Armed
BASELINE COST, SCHEDULE AND with this information, risk can be reduced in
PERFORMANCE many ways. Adding more money, reducing
the performance requirements, or extending
The three main parameters in the control the schedule are most often used. A compe-
process--cost, schedule and performance-- tent systems engineer will know the rela-
are the program manager's bread and butter. tionships between these three variables and
Again, program definition is vital and neces- the impact of any situation on the total pro-
sary from the very beginning. It may be gram.
argued that clear definition is not possible,
particularly early in the program; never- THE ROLE OF COST IN PHASED
theless, an approved, traceable baseline, al- PROCUREMENT
though it may alter, must be known at any

given time, and must include everything in The most common form of procuring high
the program. The "I forgots" can kill you. technology capability within the Federal
The key to success in handling these Government is known as phased procure-
three parameters is to manage the balancing ment. The theory behind this procurement
act between them. Cost, schedule and perfor- method is that commitment to the program
mance are usually dependent variables and gradually increases with time and in dis-
at various times, one or another may assume crete stages. Within NASA, there are four
greater or lesser importance. A single vari- standard phases; others are beginning to
able, however, should never be changed creep in as the ability to establish new pro-
without knowing the impact on the other grams becomes more difficult and the dura-
two. Within the NASA culture, performance tion and cost of operations becomes a more
is generally the predominant factor, and significant part of total program costs. The
schedule is a distant second. Cost tends to be role of cost is different in each of the phases.
considered mostly in the context of the annu- The phases are:
al appropriation, but from the point of view
of the program manager, all three param- Pre-phase A" This is a very unstruc-
eters must be defined and approved continu- tured period that examines new ideas,
ously, which is a function of the systems usually without central control and mostly
engineering process. oriented toward small studies. This period
116
can last for a decade or more and produces toward systems specification and systems in-
the list of ideas and alternatives from which terfaces. The secret to cost control is a sound
new programs are selected. definition of end items and their interfaces
with a tight hold on changes.
Phase A" Sometimes called the feasibil-
ity phase, this is a structured version of the Phase E" In most past programs, the op-
previous phase. Usually a task force or pro- erations costs were less than 20 percent of
gram office is established, and multiple con- the total cost. This was because there was a
tracts will be awarded. The goal of this definite end to a relatively short-term pro-
phase, which may last for several years but gram. In recent years, particularly in the
usually is limited to one or two years, is to manned programs, the length of the oper-
decide whether a new program will be start- ational phase has increased significantly. In
ed and what its purpose and content should the case of the Shuttle, it could be conceived
be. This phase represents less than one per- as indefinitely long. For this reason, life cy-
cent of the total program costs. Nevertheless, cle costs should be a major consideration
it is largely a systems engineering effort and from the beginning.
sets the stage for everything that follows.
SELLING THE PROGRAM
Phase B: Sometimes known as program
definition, this phase is the most important The definition of a new start within NASA
in establishing the basic parameters of the varies by program and organization but can
program. By the time this phase is finished generally be said to occur at the beginning of
(a period of two or three years), the program Phase B. Prior to that time, the program
rationale, cost, schedule, performance, man- manager is selling the program. The total
agement style and the most likely technical expenditure of funds during the selling peri-
solution will have been established. This od is usually far less than one percent of the
phase usually involves multiple contracts to final program costs; this is, however, when
establish a variety of ideas and a competitive the basic parameters of the program are es-
environment, should the program proceed. tablished. It is a time of building constitu-
Cost is continuously assessed as a function of ents both inside and outside the Agency.
design solutions relative to basic require- Assuming that a feasible technical solution
ments. Studies indicate that from five per- is available and an acceptable management
cent to ten percent of the total program costs scheme can be provided, much of the debate
will need to be expended if control is to be about whether a program should be approved
maintained over the program during Phases centers largely around the question of cost.
C and D. Of course, with only preliminary designs
available, only cost estimates can be made
Phase C/D" Originally separate phases, and these are obtained from standard cost
this period covers design, development, test models.
and evaluation. Contracts may be open to all
qualified bidders or only to those involved in COST ESTIMATING
the previous phase. Although competition is
not usually open between Phases C and D, During Phase A of the program, when the
commitment to Phase D depends on a suc- most rudimentary designs are available, it is
cessful and acceptable design. In past pro- essential that program cost estimates are
grams, two-thirds of the total program cost made before the program start can be autho-
was expended during this period. The sys- rized. Estimates are made using cost models
tems engineering role has begun to shift that have been developed on the basis of past
117
experience on similar programs. These a_ absolute basis, however, they are of little
models are among the most arcane devices
invented by engineers, so a few words on how So far we have been able to make a tenta-
they work are appropriate. tive estimate of the cost of the flight system.
Past experience is captured by document- To this must be added the cost of new facili-
ing the cost of each system on the basis of ties, including launch, test beds, flight oper-
weight. Regression analysis is performed to ations, networks and data reduction, among
determine a straight line log relationship. other factors, and finally the cost of oper-
Once the weight of the system has been esti- ations.
mated, the cost can be determined. This esti- It is at this point that the program man-
mate is multiplied by a complexity factor to ager faces the first dilemma: What should be
allow f_r the risk associated with the select- included in the program cost? That sounds
ed technology and may vary from as little as like a simple question, but it is complicated
0.50 to 2 or more. This is repeated for each by the fact that not all costs are under the
system, and the total becomes the baseline control of the program manager nor is he or
cost. This total is multiplied by a factor to she responsible for justifying all of the asso-
allow for systems engineering and testing by ciated appropriations. For example, launch
the prime contractor. This is known as the costs are provided by the Office of Space
"prime wrap" factor and is again determined Flight, network costs are provided by the Of-
based on all relevant past experience. All fice of Operations, and civil service costs are
prime contractor estimates are added and provided by the research and program man-
then multiplied by a second factor known as agement fund managed by the Office of the
the "nonprime wrap." This is the cost of gov- Comptroller. New buildings are provided un-
ernment work. Finally, a reserve factor is der the construction of facilities budget. In
used to allow for problems during the pro- addition, most new program managers are
gram. There are separate cost models for surprised to find that a tax based on the
manned and unmanned programs, which are number of civil servants working on the pro-
significantly different. In general, for the un- gram varies from Center to Center, and nei-
manned programs, about 40 cents of every ther the number of people nor the level of tax
dollar goes to hardware, and in the manned is under the control of the program manager.
programs, about 20 cents. Taxation without representation! Despite
These cost models pose a great many this dilemma, the systems engineer should
problems. First, they are normalized on the include all of these factors in the cost esti-
basis of weight. Clearly this is not valid in mate because the chosen design will affect
all cases, particularly structure. Second, all of them; overall program costs are as im-
they do not explain why the costs are what portant to the Agency as direct program
they are. Factors such as management style, costs.
procurement strategy and test philosophy Program costs tend to be presented as
are not differentiated. Third, they include all only those costs that are under the control of
past experience, including errors and over- the program manager. No matter how much
runs. In this respect, these cost models this limitation is stated in presentations, it
assume no learning curve. As it was in the is assumed that it is the total program cost
beginning, is now, and forever shall be! They (especially when it is a popular program)
must therefore be used with great caution. that has the support of the Executive branch,
From the systems engineer's point of view, the Congress and other constituencies. It is
these cost models can be used to assess the no wonder that the average program in-
relative costs of various design solutions; on creases in cost by a factor of about three from
118
the time of approval to completion and that on feasible design solutions. The systems
most program managers during this period engineer is responsible for comparing these
are accused of everything from naivet_ to two cost estimating techniques. It is unwise
self-deception to outright lies. There is the to proceed to the next phases unless some
added ethical question that if all costs were bottom-up cost estimating has been per-
presented, the program would not be ap- formed.
proved! Perhaps the most important product of
this phase is a complete work breakdown
DEFINING THE PROGRAM structure. Again, this is largely the responsi-
bility of the systems engineering organiza-
This phase of the program, usually known as tion. The axiom to be followed is, "You
Phase B, will take from one to two years. The cannot control what you have not defined."
purpose is to take the various concepts con-
sidered in Phase A and select a single valid WORK BREAKDOWN STRUCTURE
solution. By the time Phase B is over, a clear

set of requirements should be available with Too often a program will be approved with-
a complete set of functional specifications out a well-established work breakdown
and a cost estimate based on preliminary de- structure (WBS) describing the whole pro-
sign concepts rather than on cost models. gram, which inevitably results in large cost
These are primarily produced by the systems overruns. The WBS is the basis for the pro-
engineering organization and include at curement strategy and often for the manage-
least one preliminary design and selected ment structure. Without it, program changes
technologies with well-understood risks
as- will take place after the contractors are in
sociated with those technologies. Don place and have to be paid. Overlaps between
Hearth, who recently retired from NASA as contracts, as well as missing elements and
director of the Langley Research Center, per- contract changes, are always expensive.
formed a study on how much this phase has
cost for various past programs as compared The following simple rules have to be fol-
to the success of the program in later phases. lowed:
Success was measured as the ability to main-
tain performance, schedule and cost as deter- 1. Each element of the WBS should contain a
mined at the end of Phase B. He concluded deliverable that can be defined.
that the most successful programs spent
between five percent and ten percent of the 2. The sum of the WBS elements must be the
total program cost in Phase B. The scope was total program. (Note that a given program
limited to unmanned programs, but the ra- manager may not have the responsibility for
tionale can reasonably be extended to man- all elements, but they should each be defined
ned programs. and allocated.)
Apart from establishing a credible func-
tional system specification, it is essential to 3. Each deliverable should be accompanied
determine the management structure, the by a cost and a schedule. The cost should in-
procurement strategy and a baseline cost for clude a reserve based on the estimated risk
the life of the program, including the cost of associated with that element, and the cost
operations. Once again, the primary method should be allocated to that element.
for cost estimating is the cost model, but
there should be sufficient detail available to As simple as these rules sound and as much
check the model with bottom-up costs based as NASA requires contractors to adhere to
119
them, the internal track record is dismal. We Design to cost. There is much talk about
can go a long way toward containing costs if design to cost but very little action, and for
discipline is established early and main- this there are a number of reasons. Earlier, I
tained. mentioned that within NASA there is a ten-
One last word of caution. A WBS element dency to order the three variables by perfor-
should never be established on the basis of mance first, schedule second, and only then
function or organization. These elements are worry about cost. So by tradition, cost tends
not end items. Other mechanisms exist for to be put on the back burner. One of the rea-
identifying these elements, which in general sons for this is that during the Apollo pro-
could be defined as program overhead and gram, the cost function was transferred to
not entirely the responsibility of the program the budget and program control groups. In a
manag._.r. They should be recognized for program where the technical problems were
what they are and identified, but they should so difficult and the budgets were ample, this
not be included in the WBS. was understandable, but this is no longer the
case. This situation resulted in a shift away
MANAGING THE PROGRAM from making the design engineer account-
able for cost as well as performance and
We have now reached the time in the pro- schedule. The second problem occurs when
gram when promises have been made, deals the cost is not allocated at the WBS element
have been struck, and the program has been level, where it can readily be traded against
approved. All that remains is to deliver. A performance and schedule and easily traced.
custom within NASA stipulates that new I believe that cost must be allocated to the
managers are installed with the belief that lowest possible level (a little scary for the
the skills required to sell a program and to program manager), but unless this is done, it
define it are different than those required to will be impossible to hold the designer ac-
run it. Certainly some changes can be ex- countable and unlikely that overall costs
pected, but I believe that such changes are will be held in check. The third problem is
better if they occur sometime after a phase that in an organization that prides itself on
has been entered and the basic management technical excellence, it is very difficult not to
structures have been established. What the make things a little better; consequently,
program needs at this time is ownership of there are always plenty of ideas around. The
the concept, and changes in management credo of the systems engineer should there-
will usually result in program changes that fore be: "The better is the enemy of the good."
inevitably will lead to increased costs. This
is particularly true of the systems engineer- Design to life cycle cost. Over the past
ing group that has carefully balanced the decade, the operational costs of NASA pro-
requirements against the design and is fa- grams have steadily risen as a percentage of
miliar with the "why" of a decision as well as total program costs. This is largely due to the
the "what." So far the total expenditure has fact that programs have a longer life in the
been relatively low, but once the contractors operational phase. Whereas 20 years ago
are onboard and the manpower begins to operational costs amounted to no more than
build up, costs can escalate at an alarming 20 percent of costs, they are now approach-
rate. In a very short time, increases or de- ing half of the NASA budget. It is time to
creases in performance, extensions or reduc- place design to life cycle cost on an equal
tions in schedule, and decreases in annual footing with design to cost. The dilemma is
funding will all increase cost. that a design that allows low-cost operations
120
will usually demand higher development Managing cost reserves. A qualified cost
costs and in turn, this means larger front- estimator would not let a program get start-
end program costs. It is essential that the ed without making provision for cost over-
systems engineer make these assessments. runs or reserve. The many uncertainties in a
The simplest thing for a program manager to development program make it essential. An
do is walk away from this dilemma and let analysis of past programs allows a fairly
the operations people worry about it later. accurate estimate to be made of what is a
As this is becoming an overall problem for reasonable total amount as a percentage of
the Agency, the ability to make new starts total costs, assuming that the programs are
will depend on the ability to ensure that a similar. Determining how and when the al-
sufficient percentage of the budget is avail- lowance should be allocated is much more
able for operations. Unfortunately, it is difficult. One school of thought says that
difficult to get enough operations people to reserves should be held at the highest level
participate early in the program, but I be- in the program and applied only to correct
lieve it is essential. Some kind of veto power unforeseen occurrences. The problem is that
should be established when it comes to mak- this tends to bail out poor performers. I be-
ing design decisions; too many program lieve that the reserve should be determined
managers do not feel responsible for oper- based on the perceived risk of the element
ations costs and perhaps, what is worse, are when the WBS is formulated. The manager
not held accountable for it. Let there be no of the element should then be held responsi-
doubt that operational costs are unaccepta- ble for the stewardship of the reserve. In
bly high. An operational concept must there- order for this to work, some sort of reward
fore be developed early enough in the pro- system must be established for the manager
gram to have an effect on the design process. who does not spend the reserve. In any case,
it would be prudent to maintain some re-
Change control. Once a program is under- serve at the central level for those things
way, the program manager's responsibility that cannot be anticipated. Just to keep the
is controlling change, which is inevitable. system honest, a very simple tracking pro-
Earlier I said that you cannot control what gram can be established to follow the expen-
you have not defined. It is equally true that diture of the reserves at the WBS element
you cannot control changing something that level after the fact. I would like to see an in-
is not defined. First know what it is! A com- depth study done on this subject.
plete WBS with allocated schedule and cost
is, once again, the key. Change requests TRAPS AND PITFALLS
must not be limited to solving a technical
problem. They must be accompanied by cost So far we have talked about where cost fits
and schedule impacts and, just as important, into the program management and systems
life cycle cost impacts. In addition, there is engineering processes. There are a few areas
always a rippling cost impact caused by that may catch the program manager unpre-
change. Other WBS elements may be affect- pared and a few ideas that may be used to
ed, including items in different contracts or make life a little easier in the future. It may
in totally different NASA codes, or line not be possible to implement all of them, but
items. For these reasons, change must be as- it is worth a try.
sessed at the systems engineering level as
well as at the WBS level. Perhaps the over- Buying in. If you are involved in the selling
riding rule is that changes should be difficult of the program, the easiest trap to fall into is
to approve but easy to implement once the underpricing the program. Despite stories to
decision is made. the contrary, I do not believe that this is a
121
matter of deliberate low bidding. Although I doubt find yourselves in this position, and
once heard a distinguished gentleman say you will receive a great deal of advice from
that we do business the old fashioned way, the nonparticipants, but you should beware
we do underbid and make up on change re- of "descoping." A cursory examination of the
quests. The fact is that every program man- cost models will show that in the manned
ager I have ever met was convinced that he programs, only 20 cents of every dollar go to
or she could do it for less than the past record hardware. (In the unmanned programs, the
would suggest. Unfortunately, this usually number is closer to 40 cents.) Once the man-
involves changing the way we do business. I agement structure is in place and the con-
believe that there are less expensive ways, tracts have been awarded, virtually all of the
but you should tackle this one at your own other costs are fixed or very difficult to
risk and only if you have the support of the reduce. Take out all the content and the pro-
very top of the organization. The systems en- gram cost will still be 80 percent of the
gineer must be the conscience of the program estimate! The lesson is that if you are forced
manager during this period. to remove content, you should be sure to take
out every cent that is associated with that
Design to budget. Let us assume that we content: prime wraps, nonprime wraps, test
have completed a perfect Phase B and that beds, personnel, and, if necessary, the kitch-
everything is in place, including the rate of en sink. It will be difficult to find, but it will
expenditure by year. It is a virtually certain be worth the effort. If this were a mystery
that two things will happen. First, with elo- novel, it might well be called "The Case of
quent rationales and spreadsheets by the the Missing 80 Percent." Where does it all
ton, the various element managers will find go, and why is it only 60 percent for
a need to increase their funding allocation. unmanned programs? Much of this is valid
One favorite argument will be that the sell- and accounts for systems engineering and
ers of the program, who are no longer in integration at all levels of the program,
charge, will be blamed for not understanding including test and evaluation, operations,
the problem. In addition, Congress may add and many other things. But it also accounts
a requirement or two. Second, the budget for duplication of test facilities, overlaps
will be cut in the Agency, at the Office of between assignments, management style,
Management and Budget (OMB), and finally inefficiencies and a host of hidden costs asso-
in Congress. At this point, the intricate pat- ciated with maintaining the institutions
terns of dependency between performance, that are often invisible to the program man-
cost and schedule begin to unravel. In the ager. The systems engineer is responsible for
first year, this is not devastating because ferreting out the good from the bad. It is a
you can always delay bringing the prime simple fact that the first one percent reduc-
contractors on board. But by the time they tion in these wraps (80 percent to 79 percent)
arrive, the trap has been set for the most in- increases the amount of hardware by five
sidious form of management, design to bud- percent (20 percent to 21 percent)! A 20 per-
get. Unfortunately, a fact of life is that very cent improvement in the wraps (80 percent
few research and development (R&D) pro- to 60 percent) results in a doubling of the
grams have multi-year funding, and annual hardware (20 percent to 40 percent) or cut-
budgets will be less than planned. The net ting the program costs in half for the same
effect is that program costs will escalate, and amount of hardware! "Thar's gold in them
enormous pressures will attempt to bring thar hills."
down the annual funding. The first remedy is
to stretch the schedule, and the second is to The UPN System. The NASA budget is
reduce the scope of the program. You will no prepared and submitted using a system of
122
breakdowns known as the unique project THE INSTITUTION AND THE PROGRAM
number (UPN) system. All parts of the agen-
cy are required to report their annual needs Although not directly related to the systems
on the basis of this system, including the pro- engineering process, a number of things bear
gram offices. From a program point of view, directly on the program and have a major
a fatal flaw in this process is the numbering effect on the ability to perform the various
system, which generally describes functions program functions. These generally concern
rather than end items and is therefore not in the relationship between the program and
consonance with the principles of a WBS sys- the institution. NASA was originally
tem. It is essential that the program man- established using the resources of the Na-
ager be able to trace the equivalence of the tional Advisory Committee for Aeronautics
UPN number and its corresponding WBS (NACA), an aeronautical research organiza-
element. This will require a joint effort tion that was seldom involved in large
between systems engineering and the pro- development programs. The budget was rel-
gram control people. Without this traceabil- atively small, and there were few contrac-
ity matrix, the program manager will not tors. In fact, all contracts were signed at the
know what is being asked for or where the Washington office, the NACA equivalent of
money is going. Too often the UPN number Headquarters. It quickly became apparent
is perceived as directly equivalent to the that, in addition to the research centers, a
WBS element, but this is very seldom the development center was needed. The God-
case unless the WBS is not end-item orient- dard Space Flight Center (GSFC) was estab-
ed. (The latter happens more often than it lished to perform this function. This was
should.) One way to avoid this situation is to rapidly followed by the Lyndon B. Johnson
make the annual budget call for the program Space Center (JSC) in Houston, the George
using the WBS system and then translate it C. Marshall Space Flight Center (MSFC) in
to thv UPN system for the purpose of aggre- Huntsville, and the Jet Propulsion Laborato-
gating the total NASA budget. I have never ry (JPL) in Pasadena. Almost immediately,
seen this happen. GSFC and JPL became responsible for multi-
ple unmanned programs, which were largely
The cost of operations. I mentioned earlier contained within a single Center, and JSC
that the costs of operations are now about 50 and MSFC became responsible for multi-
percent of the NASA budget. This is partly center manned programs. In both cases,
due to the increase in the operational life of a program offices were established and the
program and to the fact that we have not Centers provided the resources, both person-
learned to design systems for operability. It nel and facilities, to support the program.
has not been necessary in the past. It is also With the exception of JPL, which was a fed-
true that the productivity of the operations erally funded research and development
infrastructure has not been high on the pro- center and operated outside the civil service
gram manager's list. If we are to reduce total system, all NASA personnel and basic facili-
program costs, which are vital to the Agency ties are funded separately from the programs
and to the program, it is time to strike a new in line items known as Research and Pro-
level of cooperation between these two nor- gram Management (RPM) and Construction
mally separate parts. The program and the of Facilities (CoF). Program-specific facili-
systems engineer must assume a large part ties are funded by the program and these
of the responsibility. facilities are most often operated by support
contractors, also funded by the program. centers were managed using an industrial
This system was established so that the pro- funding system similar to JPL and many
grams would be managed by government other government facilities, including the
personnel who would rotate from program to Navy labs. But until that happens, it will be
program and carry their experience with necessary to find some balance between the
them. This worked very well until the late institutional and program needs.
1960s when the budget began to fall rapidly,
and there was a significant reduction in MANAGEMENT STABILITY
NASA personnel. By the early seventies,
both the budget and the number of personnel Every program will change management
had been cut in half, but the number of during its life cycle. The common practice in
Centers remained essentially the same. The NASA has been to make these changes delib-
cost of maintaining the institution could not erately between phases. It is not uncommon
longer be sustained by the RPM and CoF line to see as many as four different managers
items. The solution was to tax the programs during a program, including a specialist in
based on the number of personnel that were closing off completed programs. The positive
applied to the program. Unfortunately, the side to this is that it is possible to match the
program manager does not decide how many needs of each phase of a program to the
people should work on the program, which, special capabilities within the agency. The
by tradition, is the responsibility of the negative side is that each manager has a
Center director. Neither does the program different style, each program has different
manager participate in determining the management needs, and often these do not
level of the tax. These decisions, again by match when the change-over occurs between
tradition, are made by the comptroller. phases. One way is not always right and an-
other always wrong, but each is different,
MAINTAINING THE INSTITUTION and changes even in management style can,
and usually do, increase the cost of the pro-
Unless the basic system of funding personnel gram. The secret then is to stick with a team
is changed, the programs will most certainly as long as possible, particularly the systems
be responsible for funding some of the insti- engineering team, something that is easy to
tutional costs that are not related to the pro- say and difficult to do in these times of
gram; the RPM budget will never be allowed declining internal expertise and increasing
to grow to compensate for this. The question retirements.
is rather how large the institution needs to
be to support the program and how that deci- THE TYRANNY OF EXPERIENCE
sion is made. I mentioned earlier that the
WBS should represent the totality of the Too often, you will find resistance to change
program and should always describe deliver- in the way things are done. "We have always
ables; this problem runs counter to that been successful (measured by performance)
principle. I believe that the solution lies in doing it this way, and its very dangerous to
accepting this cost for what it is, negotiating change winning ways." "If it ain't broke,
the level of tax with the program manager don't fix it." "You get no credit for an on-time
for the duration of the program, and taking failure." All true and at the same time, de-
it offthe top each year. It may not be control- structive to valid new ways of doing busi-
lable in the normal sense, but at least it is a ness, especially when it comes to introducing
known number. more efficient or less expensive ways. When
Personally, I believe that the Agency the space program started, we had no
would be better served if the development experience and what followed was the most
124
innovative and exciting period in the history we were basking in this glory, the rest of the
of high technology programs. But now we world has been catching up. They have been
have all that experience, and it has become a reading the book, and the competition, sup-
burden. By all means, you should keep the ported by their governments, is getting good
wise heads around (they may still save you), and fierce.
but take advantage of the explosion in new But there is a difference; the competition
technologies and capabilities, which allows believes that the space business is here to
for things that we could only dream of 30 stay. I said space business, but I meant com-
years ago. You should be careful before you merce, and in commerce cost efficiency is
introduce a change, but you should not dis- paramount. Do we still want to stay at the
miss it out of hand. top, or are we ready to leave it to the rest of
the world? Are we prepared to do what is
DOES IT MATTER? necessary to stay in the game? After all, it's
only a space program. Does it matter? You
We have been in the civilian space business bet!
for almost 40 years, and time after time we
have shown that we can rise to any challenge CAN ANYTHING BE DONE?
and lead the competition, provided we have
the resources. Time and time again the Fed- In this paper, I have attempted to show
eral Government has provided the resources. where cost fits into the space program's engi-
We have been the envy of the world. We have neering and management business. A combi-
written the book on the subject, both from a nation of things have placed cost at the
technical and a management sense. bottom of the priority ladder except in mat-
Until now, it was enough to know that we ters of the inexorable annual budget. There
were the best. There was no established are many ways to improve cost efficiency,
competition, most of the money was spent some of which are available to the program
internally, and cost efficiency was second to manager. In the long run, it will take a con-
performance. Some have characterized it as certed effort by all of us to make a difference.
a Works Projects Administration (WPA) for The Executive branch and Congress, togeth-
the technologists! The problem is that in this er with industry and academia, must work
era of budget deficits and trade deficits, as before, when we perceived that we were
there is not enough discretionary money to second. In the meantime, I hope that I have
go around. Even without international com- been able to give the budding systems engi-
petition, it would be imperative to get more neer and program manager a few tips to do
out of our research dollars. The trouble is something about the problem of cost consid-
that we have learned profligate ways, as erations. We can only do something about it
neither the government nor the contractors if we want to!
give rewards for cost efficiency. And while
125
USER
REQUIREMENTS
N93-24687
SYSTEMS ENGINEERING AND THE USER: INCORPORATION OF
USER REQUIREMENTS INTO THE SE PROCESS 5_-_ /

by John E. Naugle
A scientific mission goes through two assure everyone--the scientists, the project5
distinct stages, each with its own special management, the Center management andS,-
requirements for systems engineering. A NASA Headquarters--the scientific objec-
division director at NASA Headquarters, as- tives and requirements have been incorpo-
sisted by a program chief and a program rated into the systems engineering process.
manager, conducts the first stage. These This paper is organized into four parts. In
three people, assisted by committees and the Gestation Phase, I describe the process of
working groups, define the mission, formu- starting a new mission and establishing its
late its objectives, establish its rough rough boundaries. Next I show how the sci-
boundaries and manage the selection of the entific experiments are selected. Then we en-
experiments. The division director practices ter the Preliminary Design Phase, where we
a rough and ready kind of systems engineer- incorporate the scientist's instruments into
ing, balancing the desire of the scientist for the systems engineering process. Finally, I
the most complex sophisticated instrument show how the Preliminary Design Review
possible against the desire of the Office of (PDR) assures NASA management and the
Management and Budget and Congress to re- scientists that the scientific requirements
duce the NASA budget. If the division direc- have been incorporated into the systems en-
tor's systems engineering is done well, the gineering process to everyone's satisfaction.
mission will be supported and scientific re- Throughout I emphasize the dual role of
sults obtained. If, on the other hand, the sys- servant and master that the systems engi-
tems engineering is poor, the mission may be neer plays with respect to the scientist and
canceled either because the scientific com- the project manager. As servant, the systems
munity concludes the scientific objectives do engineer works to assure the scientists that
not merit the cost or because the Office of the project will meet the requirements of
Management and Budget or Congress thinks their experiment and their instrument; as
the cost is too high. master, the systems engineer works to as-
After the experiments have been selected, sure the project manager that the scientists
the action shifts from Headquarters to one of and their instrument will meet the require-
the NASA Centers, and the second stage be- ments of the project. A glossary of terms
gins. A project manager, assisted by a project appears at the end of this paper.
scientist and supported by an engineering I emphasize the need for the systems en-
and a financial staff, is in charge of the sec- gineering process to consider all of the pieces
ond stage. The second stage begins with the of hardware that the mission will require
preliminary design phase and ends when the and all the activities that must be conducted
last scientific paper has been published. All during the entire mission. It is easy, in the
the hardware for the mission is constructed, early phases of a mission, to focus on the
tested and operated in the second stage. spacecraft and the instruments and to ignore
Systems engineers incorporate the scien- or push into the background those activities
tists and their instruments into the systems and facilities that will be needed later or are
engineering process during the preliminary the responsibility of other offices. The associ-
design phase. At the conclusion of the ate administrator for the Office of Space Sci-
preliminary design phase, the project man- ence and Applications needs to know, before
ager conducts a preliminary design review to committing to undertake a mission, that the
PRE(]_DI/_iG PAGE BLAt_K NOT FILMED

127
entire mission has been thought through, Sun begun by HELIOS. Some missions are
that the facilities will be available, and that precursors to later more complex missions.
the funding is adequate to procure all the Surveyor and the Lunar Orbiter were pre-
flight and ground-based hardware and to pay cursors to Apollo. The Lunar Observer and
for all the work that will be required. the Mars Observer, in addition to increasing
I arbitrarily end this paper with the PDR. our knowledge of the Moon and Mars, will be
Clearly there will be continuous interaction designed to provide data needed to design
between the scientists and the systems engi- manned lunar bases and manned missions to
neers throughout the remainder of the mis- Mars.
sion. However, the main purpose of the PDR Applications missions result from a need
is to see that the user requirements have for additional coverage, better resolution,
been properly incorporated into the system. more complete coverage of the electromag-
Other papers discuss the role of systems en- netic spectrum or a new operational space-
gineers in later phases of the mission. craft.
Although there is no set process by which
THE GESTATION PHASE a new mission gets started, once it begins,
there is a fairly predictable process by which
If we are to successfully incorporate user it moves from concept to design to flight.
requirements into the systems engineering Usually a new mission gets underway when
process, we need to know how NASA creates a dedicated advocate devotes the time and
a new mission and establishes its principal energy required to get the idea accepted
boundaries; we need to know who selects the within NASA. This advocate may be located
scientific instruments and when. at a Center, a university, another federal
New missions get started in a variety of agency, an aerospace company or in NASA
ways. A person with a new idea may initiate Headquarters. The advocate prepares a
a new space mission. A scientist at a NASA rough design of the spacecraft and a list of
Center or a university may make a discov- potential instruments. With these in hand,
ery, ask a new question or invent a new the advocate buttonholes scientists, engi-
instrument. An engineer at a NASA Center neers, Center and Headquarters personnel to
or in industry may invent a new control sys- persuade them to become supporters of the
tem enabling more precise measurements to mission. At a Center, the advocate may boot-
be made. A technology may mature. leg some feasibility studies at the Center be-
New missions have been started this way fore taking the concept to Headquarters. At
in the past, but now, more and more, new some point, the advocate must describe the
missions either come from a group of people mission to the director of the appropriate di-
convened by NASA specifically to think vision in NASA Headquarters and persuade
about new missions or are logical follow-ons the director that NASA should undertake
to existing or completed missions. The the mission. If it is an astronomy mission,
Hubble Space Telescope was started as a the advocate must convince the director of
logical step after the Orbiting Astronomical the Astrophysics Division; if a planetary
Observatories. Its scientific objectives were mission, the director of the Solar System
laid down in 1964 during a summer study Exploration Division; if an Earth science or
conducted for NASA by the National Acade- applications mission, the director of the
my of Sciences Space Science Board. The Earth Science and Applications Division.
Advanced X-Ray Astronomical Facility con- The director may ask the advocate and
tinues the x-ray observations begun with supporters to describe the concept to the ap-
Uhuru and High Energy Astronomy Obser- propriate NASA advisory committee or to a
vatory. Ulysses continues the study of the summer study sponsored by the Space
128
USER REQUIREMENTS
Science Board. The director may ask a objectives themselves. The initial diameter
Center or a contractor to make a feasibility of the Hubble Telescope, four meters, was
study of the mission before committing to the chosen in the mid-sixties because that was
5- or 10-year effort that is required to get a the diameter of the largest spacecraft that
new mission underway. The advocate may could be put inside the shroud of the Saturn
appeal to the associate administrator for the V launch vehicle. Later, the diameter was
Office of Science and Applications to tell a reduced to 3.2 meters to take advantage of
reluctant division director to undertake the existing manufacturing, test and calibration
mission, but until the director is convinced equipment. The broad boundaries of the
that the mission is worth doing, it is almost Viking mission were set by the capability of
impossible to get a new mission started. the Titan launch vehicle. As a matter of fact,
Once the division director becomes enthu- in its formative stage, Viking was called the
siastic about the mission, it will be incorpo- Titan Orbiter-Lander Mission. An earlier
rated into the director's long-range plan, and Mars orbiter-lander mission, Voyager, had
the groundwork will be prepared for approv- been planned for a Saturn V; this big
al by NASA senior management, Office of Voyager was canceled by Congress because it
Management and Budget and Congress. was too large and too expensive and because
Once the division director includes a descrip- the scientists involved would not support
tion of the mission in the division's advanced such an expensive mission at that stage in
program, the advocate's work is over; the the exploration of Mars. The competition
mission takes on a life of its own. The divi- with the Soviets also helped set the bound-
sion director provides funds for studies and aries for Viking. The scientific returns from
for research and development and may pro- Viking had to be sufficient to justify the cost
vide funds to several scientists to begin work of the mission, even though the Soviets
on potential instruments for the mission. might land a spacecraft on Mars before
Applications missions are started by an Viking got there. National needs--foreign
agreement between the division director at policy, security, development of new technol-
NASA Headquarters and the division direc- ogy and the maintenance of an institution or
tor's counterpart at the National Oceanic a capability--may influence the size, scale
and Atmospheric Administration, or which- and timing of a mission. For a decade scien-
ever agency needs the mission. They agree tists unsuccessfully tried to persuade NASA
that the mission has merit and that they to start a mission to study the interplanetary
should begin to jointly plan for the mission. medium near the Sun. After President
Agreements are made as to what research Johnson offered to undertake a joint space
and development will be conducted, who will mission with Germany, it took NASA just 24
conduct it, and which agency will pay for it. hours to establish the HELIOS Mission to
They will produce a mutually acceptable make a close flyby of the sun. The need to
plan of action by which they will seek ap- test the Titan HIC launch before the launch
proval and funds. of the Viking mission dictated that HELIOS
would use the unproven Titan IIIC rather
SE'FrING THE BOUNDARIES than the existing Atlas-Centaur.
The actions of the members of Congress
The scientific or applications objectives as they review, authorize and appropriate
establish some but not all of the boundaries funds for a mission may help establish the
of a space mission. Other factors, such as the boundaries of a mission. A key chairperson
kind of transportation or the funds available or a powerful committee member may decide
help set the boundaries. Nonscientific that a particular mission is worth $500
criteria may have influenced the scientific million but not $750 million; the chairperson
129
may decide to support a mission if it will in- THE ROLE OF THE PAYLOAD AND THE
crease employment or prevent the closure of TECHNICAL WORKING GROUPS
a facility in the chairperson's district.
Purists may argue that systems engi- As soon as the broad boundaries of a mission
neering should focus on technical constraints are established and the division director is
and need not take into account nebulous confident about obtaining approval, the
political and managerial constraints. Unfor- groundwork begins for selecting principal
tunately, such constraints have been with us investigators--the scientists who will per-
since the first time two people joined togeth- form the mission experiments. To make the
er to accomplish a task neither could do selection, the division director first needs to
alone. Incorporation of such constraints into know how many and what kind of instru-
the systems engineering process is just as ments can be placed on the spacecraft, an
important as incorporating the purely tech- analysis accomplished by two working
nical constraints. The division director, groups: a Payload Working Group and a
however, must keep the political and techni- Technical Working Group. The Payload
cal constraints separate and should never Working Group consists of NASA and aca-
attempt to justify a political constraint with demic scientists from the scientific disci-
some flimsy technical justification. If this plines involved in the mission, and the Tech-
happens, the rest of the participants in the nical Working Group of system engineers
mission will become confused and the and discipline engineers representing all the
division director will lose credibility. If the engineering disciplines and subsystems re-
participants are kept straight, then later, if quired to design, build and operate the
relief is needed from some such constraint, spacecraft. Working together, these two
the division director will know who must be groups will design a trial payload that will
persuaded to get relief and the kind of justifi- accomplish the scientific objectives of the
cation that must be prepared. mission and a spacecraft capable of support-
In the early days of NASA, with a power- ing that payload. In this joint activity, we
ful administrator and with space exploration begin to incorporate the user requirements
a major national goal, a project manager into the systems engineering process.
could ignore factors other than the scientific The trial payload and the spacecraft
and technical requirements. Today, the as- emerge through an iterative process. The
sembly and maintenance of the necessary members of the Payload Working Group se-
support for the mission are so difficult that lect a trial payload--a group of instruments
these other factors may become as impor- that accomplish the objectives of the mission.
tant, if not more important, than the re- In assembling this trial payload, the Payload
quirements derived from the objectives of the Working Group may invite scientists to come
mission. to a meeting to describe instruments they
Out of this combination of political and hope to fly on the mission. They may invent
technical considerations, the major bound- new instruments that are needed to accom-
aries are set for a mission. The launch vehi- plish the objectives. The Payload Working
cle is selected, the project management Group will estimate the weight, volume,
center is picked, the trajectory and a power and communication needs, and specify
tentative launch date identified, and a rough the orientation and stabilization require-
idea formed of the kind and number of ments for each instrument. One or more
instruments that will make up the payload. members of the Technical Working Group
The availability of transportation and the will attend the meetings of the Payload
support of the Office of Operations is estab- Working Group to help them develop the re-
lished. A rough cost estimate is made. quirements and to design the spacecraft and
130
USER REQUIREMENTS
bring back to the Technical Working Group a tivities associated with the selection process.
better understanding of the payload that is People sometimes ask why the experiments
emerging. are selected by an official at NASA Head-
Meanwhile, the Technical Working quarters rather than by one at the NASA
Group will use the scientific objectives and Center that will manage the project. Others
broad constraints of the mission and design a ask, why not use the instruments selected by
hypothetical spacecraft for the mission. The the Payload Working Group for the trial pay-
Technical Working Group then takes the load and avoid all the time and energy that
first trial payload prepared by the Payload goes into the NASA selection process? Why
Working Group and integrates it into the NASA Headquarters, why not the National
spacecraft. The two groups then hold a joint Academy of Sciences Space Science Board?
session where the Technical Working Group These are good questions, and in some cases,
reviews the fit between the payload and the the answer is easy: the particular method
spacecraft, and the descriptions of changes has been tried and found not to work; in oth-
that must be made either in the spacecraft or ers, the answer is not obvious and some ex-
in the payload to make them compatible. planation is necessary.
Additional power may be required, the struc- History shows that the nation needs a
ture of the spacecraft modified, or one or vigorous broad-based space science program
more instruments may have to be redesigned that involves many academic scientists.
or eliminated. At the conclusion of the joint Academic scientists are a fertile source of
meeting, the two groups agree on the actions new ideas, and their involvement rapidly
each will take during the next iteration with disseminates the knowledge and experience
the mutual objective of making the payload gained in the space program to the next gen-
and the spacecraft compatible. The Payload eration of scientists and engineers. In addi-
Working Group refines the payload and the tion, the participation of academic scientists
Technical Working Group refines the design and their graduate students helps assure a
of the spacecraft. They meet again, review continuing supply of space scientists and
their progress, and decide on the next course aerospace engineers. Academic scientists
of action. also form a strong, vociferous lobby for the
After a year or so of joint effort and two or NASA space science program.
three such iterations, a spacecraft and a History also shows that NASA needs
payload will emerge that are satisfactory to competent, creative scientists at its Centers
both groups, the scientific community, the to help conceive and design new missions
division director, the program manager, the and to work with the academic scientists
program scientist and to senior NASA man- who participate in NASA's missions.
agement. The division director and the pro- The academic scientists and the NASA
gram scientists are now ready to select the scientists at the Centers fiercely compete for
actual scientists, and their instruments, for the right to conduct investigations on NASA
the mission. missions. If an official at the Center respon-
sible for the mission selected the principal
SELECTION OF THE SCIENTIFIC investigators, then the academic scientists
EXPERIMENTS would feel that the Center scientists had an
unfair advantage. The NASA scientists
The associate administrator for the Office of would be more familiar with the mission and
Space Science and Applications selects the therefore able to prepare better proposals. In
scientists who do research in space. The divi- addition, they would be colleagues of the
sion director, using an ancient procedure Center people handling the selection. If the
established in 1960, is in charge of all the ac- Space Science Board, made up entirely of
131
non-NASA scientists, handled the selection, scientists, engineers and financial analysts
then the NASA scientists would feel that who use the information in the AFO to pre-
academic scientists had an unfair advan- pare the scientific, technical and financial
tage. By mutual agreement between NASA parts of their proposals. Their written pro-
and the Academy, NASA scientists cannot posal is the final and generally the only
serve on the Board because they would be opportunity they have to persuade NASA to
providing advice to themselves. select their experiment. (Sometimes com-
NASA procedures were formulated to re- peting scientists are invited to brief the re-
duce the fears of these two groups of scien- viewers.) NASA bases its selection on the
tists and to encourage them to participate in written proposal. Once the procedure is
NASA's space science program. NASA pro- completed and the experiments are selected,
vides a competitive process that assures it is almost impossible for a dissatisfied
equal access to NASA's space science mis- scientist to overturn the decision. Once the
sions for all scientists, whether they are at selections are made and contracts awarded,
universities, NASA Centers or in industry, the principal investigator's team is legally
and whether they are domestic or foreign obligated to produce the instrument, conduct
scientists. Administrative scientists at the experiment and publish the results.
NASA Headquarters, who are no longer con- NASA is legally obligated to provide funds
ducting research and hence have no conflict and space on the spacecraft and to conduct
of interest, conduct the selection process. flight operations and provide data to the in-
The selection process proceeds through vestigator.
three stages. The first stage, the creation of a Careful preparation of the AFO is essen-
trial payload and the design of the space- tial. Large amounts of time and energy are
craft, was discussed above. Next NASA required to prepare and evaluate the propos-
issues an Announcement of Flight Opportu- als. If the information in the AFO is
nity (AFO) to scientists to inform them that inadequate or wrong, experimenters may be
NASA intends to proceed with the mission discouraged from competing, or experiment-
and invites them to submit a proposal to ers with instruments not suitable for the
conduct experiments during the mission. spacecraft may be selected, which can lead to
After the proposals are submitted, they are costly overruns or schedule slips.
evaluated, and a final selection is made by The preliminary systems engineering
NASA Headquarters. done by the Technical Working Group and
the Payload Working Group plays a crucial
THE ANNOUNCEMENT OF FLIGHT role in the preparation of the AFO. The AFO
OPPORTUNITY contains a description of the trial payload
and the spacecraft generated by the two
As soon as the division director is reasonably working groups. The AFO specifies the sub-
sure that the mission will be approved by systems planned for the spacecraft in suffi-
NASA senior management and by Congress, cient detail so that the proposers can design
he or she will issue an AFO. The AFO speci- their instruments to function in harmony
fies the objectives of the mission and invites with subsystems. The AFO must specify any
scientists to propose investigations. It gives special requirements for the instruments
the ground rules for the proposals and the such as the need to keep electromagnetic
deadline for their submission. interference, nuclear radiation levels or
The AFO is a very important document. outgassing below specified levels. The ther-
Several (sometimes 100 or more) teams of mal characteristics of the spacecraft are de-
scientists will spend several months prepar- scribed, and the thermal specifications that
ing their proposals. Each team consists of the instruments must meet are included.
132
USER REQUIREMENTS
The AFO specifies the date the proposals scientists prepare a list of the principal
must be returned and in some cases limits investigators who they think are the best
the number of pages of a proposal to avoid qualified to accomplish the objectives of the
getting lengthy proposals loaded with ex- mission. Their selection is based on, and
traneous information. must be consistent with, the evaluations of
the scientists and the project team. The divi-
EVALUATING THE PROPOSALS sion director is free to choose between two
competing proposals that have been given
The scientists send their proposals to the di- the same priority by the scientists but is not
vision director at NASA Headquarters who free to pick a proposal that was given a lower
is responsible for the mission. After receipt priority. In other words, the division director
of all proposals, the division director forms must select a principal investigator whose
two groups to assist in the evaluation. The proposal was placed in Category I by the
first group, chaired by the program scientist, scientific working group rather than pick an
consists of scientists who are peers of those investigator whose proposal was placed in
proposing experiments and who will evalu- Category II, even though the Category II
ate the scientific and technical merits of the experiment might be cheaper or easier to
proposals and assign them a priority for integrate with the spacecraft. The instru-
inclusion in the mission. This group of scien- ments of the principal investigators selected
tists must be free of any legal conflict of must be certified compatible with the space-
interest with respect to any of the proposals, craft or the division director must have the
which is the reason why they cannot be cho- results of a study that shows that the instru-
sen until all the proposals are in. The second ment or the mission can be modified to make
group consists of engineers at the project the instrument compatible. Since each of the
management Center similar in membership investigators selected has proposed a specific
to the Technical Working Group (in many instrument, in the process of selecting the
cases it will be the Technical Working investigators the division director has also
Group). This group will examine all the pro- selected the suite of instruments that will
posals to see if the instruments proposed are make up the payload for the mission.
compatible with the spacecraft and judge After completing the list of principal
whether the proposer has the team and the investigators and the justification for their
facilities required to carry out the investiga- selection, the division director takes the
tion. recommendations to the members of the
As soon as the division director has the Space Science Steering Committee for their
proposals, copies are sent to both groups. review and recommendation.
After the two groups complete their work,
they send the results of their evaluation to THE ROLE OF THE SPACE SCIENCE
the division director. If an otherwise high STEERING COMMITTEE
priority investigation is incompatible with
the spacecraft, the division director may ask The Space Science Steering Committee is
the project team to conduct a short study to composed of the directors and the deputies of
determine whether the instrument or the each of the program divisions in the Office of
spacecraft can be modified to make the two Space and Applications. Traditionally, if the
compatible and, if so, to prepare an estimate director is an engineer, the deputy is a scien-
of the costs involved. tist and vice versa. Thus the Space Science
After receiving the evaluation made by Steering Committee consists of roughly
the scientific working group and the project equal numbers of scientists and engineers
team, the division director and the chief and is capable of reviewing the merits of
133
investigators, the selection procedure, and THE ASSOCIATE ADMINISTRATOR'S

all other technical and managerial aspects of APPROVAL
the mission. !t is chaired by the chief scien-
tists in Office of Space Science and Applica- After the associate administrator approves
tions and reports directly to the associate ad- the principal investigators, each of them is
ministrator for that Office. sent a letter to inform them of their selection
The Space Science Steering Committee and to give them any guidelines or qualifica-
reviews the investigations that have been tions that come from the selection process.
selected and the process by which they were For instance, only a part of the investigator's
selected. It reviews the investigations for proposal may have been approved or the
their scientific and technical merit and for investigator may have agreed to provide en-
their c_mpatibility with the spacecraft. If vironmental data to other investigators on
there are any objections or reservations the mission to aid them in the interpretation
raised by anyone about the payload, the of their data. Funding for the mission may be
Space Science Steering Committee reviews limited; the associate administrator may
those objections. Normally the investigators direct each investigator to control costs very
chosen by the division director are accepted; carefully and request that some aspect of the
however, if a member of the Steering Com- investigation be modified or excluded if it
mittee objects to a selection or questions the becomes apparent that the costs will exceed
selection process, then the Committee may the funds allocated for the investigation. If
send the division director back to prepare a the interest in the mission is high and the
different version of the payload. funds are limited or the resources of the
The Space Science Steering Committee spacecraft, such as the weight, power and
serves as the court of final review for a pay- telemetry, are very constrained, the associ-
load. By its acceptance of the principal inves- ate administrator may give provisional ap-
tigators and their instruments, it certifies proval to one or more investigators pending
that, up to this stage, the user requirements an analysis by the project to determine if the
have been properly incorporated into the sys- res.ources are available.
tems engineering process for the mission. The associate administrator's letter to a
After the members of the Committee com- principal investigator is an informal con-
plete their review, the chairperson sends tract between the associate administrator
their recommendations to the associate ad- and the principal investigator that obligates
ministrator of the Office of Space Science and the investigator to devote the time and ener-
Applications who approves the investigators. gy required to accomplish the objectives of
After approval of the investigators by the the investigation. It obligates the associate
associate administrator, the only way to administrator to proceed with the mission
change an investigator or an instrument is to and provide the resources and assistance
appeal over the head of the associate admin- that the principal investigator will need.
istrator, to the deputy administrator or the At the same time the letters are sent to
administrator of NASA. Only once in the the principal investigators, the associate ad-
past 30 years has the decision of an associate ministrator also sends a letter to the director
administrator been reversed. In that case, of the Center responsible for managing the
NASA modified its selection procedure to project. This letter notifies the director of the
facilitate the selection of investigators for investigators selected and the qualifications
the Apollo-Soyuz Mission. The chairperson of or guidelines that have been given. The
the Space Science Board objected to the letter is accompanied by the authorization
change; NASA redid its selection and fol- and transfer of funds that enable the project
lowed the normal procedure. team to negotiate contracts with and fund
134
USER REQUIREMENTS
the work of the principal investigators. This of the letter triggers an intensive assessment
contract should provide for the support of the by the project manager of each investigator
principal investigator and specify the work and of the status of each instrument. This
to be done during design, manufacture, pre- assessment should be completed prior to the
flight testing, operations, analysis of the beginning of preliminary design activity.
data and publication of the results. The fun- The assessment is conducted by a team
ding for data analysis is normally carried in appointed by the project manager. The team
a separate line item in the Space Science consists of several engineers from the Cen-
budget and is transferred to the Center ter. A key member of the project manager's
through a separate channel at a later date. review team is the project scientist, who,
Regardless of how the funding for the oper- among other tasks, serves as the communi-
ational phase is handled, the associate ad- cation link between the investigators and
ministrator should require that the project the project team.
team provide for data analysis and publica-
tion of the results in these contracts with the THE ROLE OF THE PROJECT SCIENTIST
principal investigators. The incorporation of
the user requirements into the systems engi- The Center director, with concurrence of the
neering process will not be complete unless Office of Space Science and Applications as-
all phases of the mission are considered, sociate administrator, appoints the mission's
including data analysis, interpretation and project scientist. This project scientist has a
publication of the results. powerful role during a scientific mission,
The Space Science Steering Committee's quite different from that of the project man-
review and the associate administrator's ap- ager and, at this stage, equally important. If
proval of the principal investigators com- the project scientist and the project manager
plete those phases of the mission that are led have a conflict they cannot resolve and that
by the division director at NASA Headquar- may affect the mission's scientific outcome,
ters. Once the investigators have been the project scientist is expected to carry the
selected, the focus of the work shifts from case to Center management and, if it is a
Headquarters to the Center, where the pro- good case, to prevail.
ject manager and the project scientist take The project scientist should have as vest-
over the technical and scientific leadership of ed an interest in the scientific success of the
the mission. They are responsible for the mission as the one who conceived the mission
final steps in the incorporation of the users or as an investigator on the mission. As an
requirements into the systems engineering experienced space scientist and person who
process. has conducted investigations in space, the
project scientist should understand what
ASSESSMENT OF THE PRINCIPAL information the project needs from the prin-
INVESTIGATORS cipal investigator in order to conduct the
mission and should be able to accurately
When the associate administrator for the communicate those requirements, and the
Office of Space Science and Applications reasons for them, to the scientists. The pro-
selects the principal investigators and au- ject scientist should understand the techni-
thorizes the Center to negotiate contracts cal requirements submitted by the principal
with them, the responsibility for working investigators and be able to communicate
with the scientists is transferred from the them to the project. In addition, the project
division director and the program scientists scientist should be able to judge which of the
at Headquarters to the project manager and requirements of the principal investigator
the project scientists at the Center. Receipt are mandatory and which are only highly
135
desirable so that the resources of the project spacecraft and the operational equipment. In
are not squandered. Conversely, the project addition, it provides the project manager
scientist should be able to sort out the highly with the first opportunity to determine the
desirable from the mandatory requirements experience and capability of each principal
of the project manager so that unnecessary investigator and of the team, and to assess
constraints, reporting requirements or re- whether the investigator's institution can
views are not placed on the principal investi- and will provide the support that will be
gators. Clearly, the project scientist must needed.
have the confidence of the project manager The assessment begins with "fact find-
and the investigators on the mission in order ing," a systematic effort by the review team
to succeed. The assessment of the principal to collect information about the investiga-
investijators provides an excellent opportu- tors. The team conducts its review at the in-
nity for the project scientist to become a reli- vestigator's institution, rather than bringing
able representative of the scientists to the the investigator and the team to the Center.
project team and of the project team to the A visit to the institution enables the review
scientists. team to not only examine the laboratory
People ask, why all this concern about the model of the instrument, but also to review
communication channel between the project the calculations and test results that support
and the investigators? Why can't the project the design. The team can review the facili-
manager deal with the investigators just as ties that will be available to investigators to
one would with the person responsible for develop, test and calibrate the flight instru-
any other subsystem on the spacecraft? ments. If the investigator plans to have most
Early experience in space science showed of the work done by a contractor, then the
that a project manager who was not a scien- review team conducts a similar review at the
tist, or who did not have a strong competent contractor's plant.
project scientist working with him or her, The review should cover all the elements
usually got into one of two kinds of trouble. that are required by the investigator to com-
Either the project manager regarded the plete the objectives of the experiment. By
scientists as all powerful and gave in to all "all the elements," I mean all the pieces of
their whims, thereby driving the costs of the hardware, all the facilities, all the testing
mission out of sight, or the project manager gear that will be required, and all the work
regarded the scientists as overly bright and the people that will be required to enable
children and overrode their legitimate re- the investigator to design, build, test and fly
quests, thus causing their instruments to fail the instrument. In addition, the review
or forcing the scientists to complain to Cen- should identify all the computers, all the pro-
ter management or NASA Headquarters and grams and all the software that the investi-
try to get the project manager replaced. gator will require to analyze the data and
publish the results. The review should cover
FACT FINDING the entire mission, from design and develop-
ment, to testing and calibration, to place-
The initial assessment of each principal in- ment of the published results and of the data
vestigator by the project team is the most im- in the archives. The plans, scheduled actions
portant part of the incorporation of the user and funding requirements as a function of
requirements into the systems engineering time are key elements to be reviewed. The
process of a mission. The primary purpose of impact of project requirements on the inves-
the assessment is to determine the technical tigator or the instrument should be covered
requirements of the instruments and their in the review. Throughout the review, its
compatibility with each other and with the two-way nature must be emphasized. The
136
USER REQUIREMENTS
purpose of the review is to determine what tigator at the host institution and by the
the investigator requires of the project and to project team to monitor the work of the
inform the investigator of the requirements investigator.
of the project. Obviously, not all of this data will be
The review begins with information and available at this first review. However,
data collection by the team. The team must where information is not available, the need
collect information on the technical re- should be established and the project man-
sources on the spacecraft that the instru- ager and the principal investigator must
ment requires such as weight, telemetry, formulate a mutually acceptable plan as to
band width, volume, power, commands and who will generate the information and on
thermal control. what schedule.
This initial data gathering phase pro-
The team must collect data on the engineer- vides an excellent opportunity for the project
ing constraints imposed by the instrument manager and the systems engineers to assess
on the spacecraft, including but not limited the capability of the principal investigator
to: and the team. NASA policy makes the prin-
cipal investigator, responsible for all phases
Location of the instrument of the investigation, beginning with the de-
Look angle and field of view sign of the instrument, continuing through
Pointing and stabilization required to the delivery of a calibrated, tested and
Operational requirements flight worthy instrument, and culminating
Special treatment during testing, launch, in the publication of the results. During the
and operations review, the principal investigator should
Limitations on vibration and shock demonstrate understanding and the ability
Limitations on stray electromagnetic to discharge this responsibility and should
fields be able to describe how to conduct the day-
Limitations on material surrounding the by-day work of the team. The principal
instrument investigator should state whether the day-
Limitations on outgassing. by-day work of the team will be under the
investigator's direction or whether a man-
The team needs to know the facilities ager will be appointed to direct the work. If a
that will be required by the instrument and manager is appointed, do the principal inves-
their availability, either at the investigator's tigator, the manager and the project
institution, the contractor, or at the field manager all understand the limits of the
center or its contractors, including but not authority of the manager? What decisions
limited to: can be made by the manager and which ones
must go to the investigator? Has the investi-
Vacuum chambers gator delegated sufficient authority to the
Shock and vibration tables manager so that decisions can be made and
Solar simulators the work can be kept on schedule? How does
Computers the principal investigator plan to oversee the
Special test and calibration facilities work of the manager? Does the investigator
Special data handling and analysis plan to attend certain key reviews to see how
facilities. things are going? Will the manager give
weekly reports?
The team must collect information and plans The project manager and the principal
for the funding, manpower and management investigator should agree on which reviews
capability that will be required by the inves- the investigator will attend and which can
137
be delegated to the manager. They also need the other hand, if the investigator has a
to agree on how they will resolve disputes weak team or inadequate facilities, then the
that will arise between the principal investi- project manager has to lay out a project plan
gator's manager and the project manager. and a schedule that takes this weakness into
If the principal investigator plans to han- account. Additional money must be set aside
dle the day-to-day operations, another set of to cover overruns. Provisions for additional
questions needs to be asked. Is the investiga- monitoring must be made and additional
tor prepared and able to spend the time and time for testing and integration must be
energy to handle the daily work? Is the in- allowed. An engineer from the project may
vestigator prepared to travel to the Center or be assigned to aid the investigator. The in-
to a contractor when reviews must be held vestigator is placed on the list of the project's
and decisions need to be made? Is the investi- "Top Ten Problems," thereby alerting the
gator prepared to give up other research dur- Center management and Headquarters of
ing the development of the instrument? the problem. Any management or technical
Appointing a good project manager is problems unearthed in this initial assess-
generally better for the investigator and the ment should be treated just as thoroughly
team. The project manager can concentrate and just as promptly as the failure of any
on the daily activity of managing the team subsystem would be treated later in the
and the investigator can focus on meeting schedule. Prompt action at this stage will
the requirements that will be levied by the prevent many hardware problem_ from aris-
project manager and the team. ing later when there is less time and less
The review team needs to ask other ques- money to resolve them.
tions. Is the investigator's team adequate for The review of each principal investigator
the task? Have they planned their work and culminates in the negotiation of a contract
laid out a sensible schedule? Are they cooper- between the Center and principal investiga-
ative and forthright about the status of their tor, whereby the investigator is to produce a
instrument? Are the kinds of engineers and flight instrument using funds provided by
technicians that will be needed either on the the Center. At the conclusion of the assess-
investigator's team or at the contractor? Has ment process, a principal investigator will
the investigator done a good job estimating have two contracts: one with the associate
the costs as a function of time? Has a reserve administrator of the Office for Space Science
been allowed for unforeseen problems, and if and Applications to accomplish the objec-
so, have criteria and a schedule been laid out tives of the experiment proposed, and the
for its use? Any weakness in planning or other with the project management center to
management at this stage, if not corrected, produce an instrument that is ready for
will inevitably result in more serious prob- flight. A principal investigator who thinks
lems later in the project. that a Center decision will jeopardize the
The analysis of the strengths and weak- investigation has the right to appeal the
nesses of a principal investigator's team decision directly to the associate administra-
serves an important function in the incor- tor of the Office for Space Science and Appli-
poration of the user requirements into the cations. This appeal channel is rarely, if
systems engineering process. If an investiga- ever, used.
tor has a competent team and adequate
facilities and equipment, the project man- THE SYSTEMS ENGINEERING PROCESS
ager can reduce the monitoring require-
ments for that investigator. The investigator Once the review team has completed its fact
can reduce the time allocated for testing and finding and its assessment of the investiga-
integration and may waive certain tests. On tor's capability, the systems engineers are
138
USER REQUIREMENTS
ready to complete the conventional systems In this highly constrained case, the systems
analysis of the system. The information the engineer takes the requirements of the core
review team has collected enables them to payload and the existing constraints
incorporate the user requirements into that and,working closely with the project scien-
process. tist and the principal investigators, makes a
By this time, all the broad boundaries of number of tradeoff studies to determine the
the mission are established; the investiga- maximum number of investigations that can
tors have been selected, a preliminary design be accommodated and the maximum amount
of the spacecraft is available, the transporta- of scientific information that can be collect-
tion system is specified, the total cost of the ed.
mission has been set (or a ceiling placed on The objective of the systems engineering
the total cost) and a preliminary launch date effort at this stage is to plan the entire mis-
scheduled. sion, establish the specifications for the in-
If there is no hard fast launch date, then struments and the spacecraft, lay out a
the launch schedule may become a variable schedule for all the activities of the mission,
in the systems analysis and shifted forward establish milestones for completion of major
or back to reduce costs or improve the scien- activities, schedule the testing and integra-
tific return of the mission. If it is a planetary tion work, set a launch date, estimate the
mission, however, the launch date is not a cost and lay out a funding plan for the entire
variable but is rigorously set by planetary mission. The systems engineers identify any
dynamics; the role of the systems engineer is technical conflicts that exist between instru-
to identify the decisions that must be made ments or between an instrument and the
and the actions that must be taken to assure spacecraft. Where they find conflicts, they
the sanctity of that launch date. identify the options available to the project
In the case of a high priority scientific to solve them, conduct tradeoffs between the
mission, such as Viking or the Hubble Space options and recommend the option that they
Telescope, the scientific objectives may be think will produce the greatest scientific
the primary constraint. The systems engi- return for the lowest cost.
neer can adjust the launch vehicle, the As the systems engineers conduct their
launch date and the total cost to meet the analyses, there is a continuous iteration pro-
scientific objectives. cess that takes place throughout the project
For most missions, however, the primary and among the investigators. Different loca-
constraints will be technical and financial. tions of the instruments on the spacecraft
The launch vehicle may be specified; there are studied and discussed with the investiga-
may be a cap on the funding, certain subsys- tors to determine which are best. Tradeoffs
tems may be specified and in many cases the may have to be made between the value of
spacecraft itself will be specified. In such adding an investigation and adding more
highly constrained missions, the only vari- power or more telemetry bandwidth for the
ables the systems engineer has to work with core payload. In rare instances, the systems
are the number and complexity of the scien- analysis may show that additional resources
tific instruments that can be accommodated. are available on the spacecraft; then trade-
For such highly constrained missions, the offs are made to determine how to allocate
associate administrator of the Office of Space the resources among the investigators to bet-
Science and Applications will usually select ter accomplish the scientific objectives.
a core payload that is certain to be accom- Many complicated tradeoffs are made at
modated and then add one or more in- this stage in a project. As an example, sys-
vestigations to be included if the systems tems engineers working closely with the
analysis shows they can be accommodated. project scientist and the investigators may
139
conduct tradeoffs to determine how much care they would examine an instrument that
data processing should be done on board by is not meeting its design specifications or its
each instrument, thereby increasing the milestones. Such a deviation in the rate of
weight and power required by the instru- use of reserves may identify a weakness in
ments but reducing the complexity of, and the investigator's team or in the design of
the weight and power required by, the com- the instrument early in the development
munications system of the spacecraft. cycle. If the project manager takes prompt
Mutually acceptable schedules for the use action when an unexpected use of the re-
of common ground facilities such as shake serves is first seen, technical or schedule
tables, vacuum chambers and calibration problems that may occur later in the devel-
equipment are worked out between the pro- opment phase can be eliminated or reduced.
ject, the investigators and the persons re- At this time, the project manager estab-
sponsible for those facilities. A detailed lishes another important policywhow the
schedule of all the tests, calibration runs and information about the reserves will be treat-
flight operations is established with each ined. The project manager can choose to oper-
vestigator. These schedules, as emphasized ate somewhere between two extremes:
repeatedly in this paper, should carry "everything on the table" or "hold all the
through flight operations and data analysis. cards close to the chest." In the first extreme,
Only by doing this can a systems engineer be everybody in the project is informed, includ-
sure that all the requirements of the scien- ing all the subsystem managers, all the
tists have been incorporated into the mission principal investigators and the contractors,
plan. By forcing the occasionally unwilling exactly what the reserves are, who is holding
investigator to sit down and think through them and the schedule for their use. At the
the entire experiment, the systems engineer other extreme, the project manager treats
may bring to the surface a major technical the reserves as highly classified information
problem or an inadequate cost estimate. known only to the project manager and possi-
Once the entire mission is laid out, the in- bly some of the senior management. Both
vestigators accommodated, their expenses extremes have worked. The choice largely
estimated and a launch date established, the depends on the experience and personality of
systems engineer must estimate how much the project manager and NASA's current
and what kind of resources need to be re- management philosophy. A new, insecure or
served for unanticipated problems. Extra weak project manager may want to keep this
slack time must be placed in the schedule to information confidential to help control the
accomplish unanticipated work. The systems project. A more confident project manager
engineer must reserve some weight, power may choose to operate an open system. If a
and communications capability for shortages project manager chooses to operate an open
that will inevitably arise. Funds to cover system, there must be a willingness to accept
overruns must be reserved and a schedule by a high level of acrimony in the project. A
which the funds are to be released must be principal investigator fighting a weight
prepared. If there is no schedule for the re- problem or overrunning the l_udget will eye a
lease of reserve funds, then they may all be compatriot's reserve and scheme to get it. On
used up in the early months of the project, the other hand, by operating in an open
leaving nothing for the major problems that manner the project manager may create a
will occur later. more healthy climate of trust between the
The project manager and the overseers at investigators and the project team and
the Center and Headquarters should exam- thereby discover problems earlier than if all
ine any deviation by an investigator from the the reserves are kept secret. Sharing knowl-
planned use of the reserves with the same edge of the problems and the reserve being
140
USER REQUIREMENTS
maintained can help a project manager pro- The good chairperson goes around the
mote teamwork on the project, raise the mo- room after the discussion of a controversial
rale, and encourage the investigators to item and questions the key people involved
carefully manage their reserves. On the oth- to see if they all understand and agree on the
er hand, if NASA's current policy is to pull project's plan. The chairperson of the PDR
all identifiable reserves into a Headquarters cannot be a "shrinking violet" or an introvert
reserve to be held by the comptroller, then (at least not during a PDR).
project managers will instinctively bury any The project manager conducts the review.
financial reserves somewhere in the project. Attendance from Headquarters includes, but
Ultimately, the user requirements will be is not be limited to: the associate administra-
assimilated into the systems engineering tor for the Office of Space Science and Appli-
process, the preliminary designs will be com- cations or a designee, the division director,
pleted, the schedules established, and the the program manager, the program scientist,
rate of expenditure established. When this is the financial analyst, the NASA comptroller
done, the project is ready for its first major or the designee, and the associate adminis-
design review, the preliminary design re- trators for the Offices of Space Flight and
view. Operations or their designees. Someone from
the Office of International Affairs attends if
PRELIMINARY DESIGN REVIEW there are foreign investigators or if it is a
joint mission with another country. Atten-
The Preliminary Design Review (PDR) ends dance from the Center will include the direc-
the preliminary design work, and completes tor, the financial analysts, representatives of
the incorporation of user requirements into the engineering disciplines and the systems
the systems engineering process. All aspects engineers. All the principal investigators
of the mission and all future activities re- attend. Senior people from the major con-
quired to accomplish the mission should be tractors also attend. If the PDR is for an
planned by this time. applications mission, then senior people from
The choice of a chairperson for the PDR the agency who will use the system will
depends upon the complexity, cost and attend.
national interest in the project. The division The chairperson expects the project man-
director may chair the PDR of a routine, ager to present a clear, concise statement of
small scientific project. The associate admin- the overall objectives of the mission. If there
istrator for the Office of Space Science and are other nonscientific objectives for the
Applications will chair the PDR of a larger, mission--if, for instance, one of the objec-
more complex mission. The administrator or tives is to test a new subsystem, a new space-
deputy administrator of NASA may chair craft or a new tracking system--then the
the PDR of a large, complex, costly, highly project manager is expected to clearly specify
visible mission such as the Hubble Tele- the relationship and priorities between those
scope, or Earth Observing System. The other objectives and the scientific objectives.
chairperson should be someone who thrives The chairperson should make sure that all
on crowds and controversy and has a vast objectives are clear, understood and agreed
curiosity about the mission and a penchant to by the attendees.
for uncovering unforeseen or concealed prob- The project manager should present a
lems. The chairperson should use the PDR to complete schedule, extending from the PDR
identfy and resolve any issues that the pro- through the Critical Design Review, on
ject team or the investigators may have over- through development, testing and calibra-
looked or may be trying to avoid. tion of the instruments and continue on to
141
launch operations, data analysis and publi- resolve the problems. If the investigator has
cation or use of the results. Slack time should only a tentative approval to fly on the mis-
be clearly shown. Even though detailed sion, then the actions and milestones should
plans for operation and data analysis may be specified that will lead to final acceptance
not be complete at this time, the systems or rejection.
engineering process should have produced a The project manager or the manager's
list of the facilities required and a schedule designee should review the status of the
for their use. Very often, the examination of other elements of the mission, their sched-
the mission's schedule at the PDR will un- ules and problems. If the cost or configura-
cover potential conflicts for the use of facili- tion of a subsystem is being determined by a
ties or an underestimate of the cost of some requirement of a particular investigation,
phase of the mission. that fact should be presented so that senior
The chairperson reviews the status of management and the principal investigator
each instrument. Ideally, the review of an in- can decide whether the particular aspect of
strument will consist of two parts, a presen- the investigation merits the additional cost
tation by the principal investigator followed or complexity.
by the project scientist's assessment of the The project team should present an over-
status of the instrument. The principal in- all assessment of the instruments and their
vestigator should describe the experiment, interaction with each other and with the
its objectives and how they relate to the subsystems on the spacecraft. The project
objectives of the mission. The principal in- manager may elect to divide the experiments
vestigator should describe the instrument, into two groups: one group consisting of
show the schedule and slack times, and those investigations in which the design of
present a cost breakdown and a funding the instrument is on schedule, within bud-
schedule. The investigator should identify get, and the investigator is not in need of
any issues with the project manager, includ- careful monitoring; the second group consist-
ing any foreseeable technical and procure- ing of those instruments that have major
ment problems, and list the top four or five problems, that will require careful monitor-
problems. The project scientist should then ing and perhaps even a backup instrument.
give the project's view of the status of the The project manager should review the
instrument and should state whether the status of the resources available to the pro-
project agrees with the status as presented ject, the reserves that are being held and the
by the investigator. The project scientist schedule for their release. At the conclusion
should present any concerns the project has of the PDR, the project manager should
about the principal investigator, the team, identify the top 10 problems for the overall
the institution or the contractor. project and describe plans to resolve them.
This review by the project scientist at the At the conclusion of the PDR, all the
PDR should not lead to a confrontation be- participantsmHeadquarters, Center man-
tween the principal investigator and the pro- agement, the project team, the principal
ject scientist or the project manager; through investigators and the subsystem managersm
earlier discussions, each should be aware of should all understand and accept the status
what the other intends to say; each should be and requirements of the investigations
aware of the concerns of the other and at the scheduled for the mission. The principal
review they should present a jointly devel- investigators should agree with the status of
oped plan to solve the problems that exist. their experiment as presented, and they
The project manager and the principal inves- should understand and be prepared to accept
tigator should understand and accept the the requirements and meet the schedules
actions that the other intends to take to that have been placed on them by the project.
142
USER REQUIREMENTS
Once the actions that were assigned to the GLOSSARY

project and the investigators by the PDR
have been completed, the requirements of Mission. An effort to increase human knowl-
the investigators should be incorporated into edge that requires the launch of one or more
the systems engineering process. The project spacecraft. A mission begins with the initial
team and the investigators are then ready to concept and concludes with the publication of
proceed with the detailed design and manu- the results.
facture of the instruments and the space-
craft. System. All the tasks and all the equipment,
The majority of the systems engineering both ground and space based, required to ac-
effort required to incorporate the user re- complish a mission.
quirements should be complete at this time.
Normal project management and engineer- Systems engineering. The systematic
ing techniques should be adequate to com- planning activity that begins with the mis-
plete the integration of the investigators into sion objectives and the requirements of the
the mission. There will, however, be a scientists and turns them into specifications
continuing need for systems engineers to for hardware and facilities, conducts tradeoff
support the project team. No matter how studies between competing subsystems, ana-
good and how complete the systems engi- lyzes the interaction between the subsys-
neering effort has been, and how carefully tems to eliminate unwanted interference,
the PDR is conducted, problems will still be and prepares schedules, cost estimates and
encountered in the instruments or in the funding plans.
subsystems and changes will have to be
made. The systems engineer will have to Program. The formulation and documenta-
trace the impact of those changes through tion of a mission prepared by NASA Head-
the system, identify the problems that are quarters and used to obtain authorization
created and provide the options for their and funding from Congress to conduct the
solution. Inevitably, there will be a shortage mission.
of resources available--additional power or
weight required--and the systems engineer Project. All the equipment produced or pur-
will have to assess the system to see how the chased by, and all the activity conducted and
resources can be found and analyze the im- directed by, a NASA Center to accomplish a
pact of using those resources. Occasionally, mission.
excess resources will become available; the
systems engineer will have to examine these Division director. An individual at NASA
extra reserves and determine how they can Headquarters responsible for a group of re-
best be applied to enhance the quality of the lated scientific programs.
mission.
As the work progresses, the engineers Program manager. A person, usually an
will eventually understand the instruments engineer, at NASA Headquarters in charge
and their spacecraft, their designs will be of a program. A program manager reports to
frozen, all the options will be eliminated and a division director.
the systems engineer will no longer be need-
ed. Sometime before this stage is reached, Program scientist. A scientist at NASA
the good systems engineers will become Headquarters responsible for formulating
bored and will move on to a new system with the scientific objectives of a program. A pro-
new challenges. gram scientist reports to a division director.
143
Project manager. The person, usually an scientific objectives of a project. The project
engineer, at a NASA Center who is responsi- scientist reports to the senior management
ble for the success of a project. The project of the Center.
manager reports to the senior management
of the Center. Principal investigator. A scientist, select-
ed by NASA Headquarters, to conduct an
Project scientist. The scientist at a NASA experiment during a mission.
Center responsible for accomplishing the
144
SE&I PROCESSES
N93"2468
SYSTEMS ENGINEERING AND INTEGRATION PROCESSES
INVOLVED WITH MANNED MISSION OPERATIONS /
by Eugene F. Kranz and Christopher C. Kraft /f_'_ _-_'I I
The quality of the systems engineering and the early Mercury program to the mature
integration (SE&I) process determines the and structured process used for Apollo. The
viability, effectiveness and the survivability flight experience of the Mercury program re-
of major NASA flight programs. In mission vealed the need for a deeper knowledge of
operations, SE&I is the process by which the spacecraft systems by flight operations
technical, operational, economic and politi- teams. It further indicated a need for
cal aspects of programs are integrated to systems documentation tailored to the opera-
support the program objectives and require- tor's real-time task. By the completion of
ments consistent with sound engineering, Mercury, a systems handbook had been
design and operations management princi- developed as an "on-console," real-time docu-
ples. ment for flight systems data. Direct commu-
Major flight programs involve operation- nication was established between the operat-
al, cost, and political elements and priorities, ing team and the manufacturer so that any
international prerogatives, and often poorly additional systems data needed during the
focused utilization requirements, in addition course of the mission could be obtained. This
to traditional technical trades, technology communication also provided a means for
utilization, and interface definition and con- getting engineering judgment on operational
trol. This combination demands an effective trades, whenever time permitted. The flight
SE&I process that spans and involves all rules became the focus of operational poli-
these elements, cies.
SE&I, therefore, is a distributed process The Gemini program required the devel-
that involves the structuring and integrated opment of the trajectory capabilities needed
management of a program within and be- for rendezvous and docking, as well as a
tween the program, project and technical guided reentry capability. These require-
levels, with a life cycle consistent with the ments established the linkage between tra-
program phase. SE&I must anticipate pro- jectory; guidance, navigation and control
gram needs by providing clear technical (GNC) systems; and propulsive consumables.
assessments, trades and alternatives aimed The Gemini extravehicular activity (EVA)
at satisfying the program objectives and increased awareness of the relationship be-
requirements, tween crew, the task and the working envi-
This paper will describe the key princi- ronment.
ples and processes used within mission oper- During Apollo, science became the final
ations, emphasizing the pre-mission prep- mission component supported by the oper-
aration activities most useful for describing ations teams. The Apollo operations team
the principles of an effective SE&I process, worked in an integrated fashion on all issues
involving flight systems, flight design,
EARLY DEVELOPMENT OF MISSION science and manned operations.
OPERATIONS It was during the Skylab program that
the first formal and broad-scale application
The development of mission operations capa- of the mission operations (SE&I) process
bilities for manned space flight involved a emerged to support the early flight system
rapid evolution from the traditional method hardware and software design. During the
of aircraft flight test operations used during Skylab design reviews, many of the review
145
R EADINGS 1N SYSTEMS ENGINEERING
item discrepancies (RIDs) revealed the need management, avoiding conflicting priorities
for much closer relations between systems and providing leadership focus. The only
design and operational utilization. exception is a Flight Design and Dynamics
The multiple Skylab systems elements, Division (FDDD), which provides integrated
combined with the broad spectrum of scienti- flight design for the Shuttle and all pro-
fic objectives and the complexity of manned grams using Shuttle services.
and unmanned flight, required an early and Each division is responsible for integra-
effective relationship between flight systems tion within its work area and provides
designer, scientist-user and mission oper- mission operations representation to the
ations. A Johnson Space Center (JSC) oper- project-level boards. Program-level boards
ations team and a Marshall Space Flight are generally supported through the Flight
Center (MSFC) engineering team joined to Director Office, by the Operations Division
conduct a series of systems operations com- and by the FDDD. Integration between pro-
patibility assessment reviews (SOCARs). grams is accomplished by the MOD assistant
During these and all subsequent reviews, the directors for the Shuttle and for the Space
Skylab systems and software handbooks pro- Station.
duced by mission operations were used as the In addition to the internal integration
baseline reference documentation for the process, each division generally has a hori-
SOCAR. These documents were also used by zontal integration responsibility that identi-
the JSC and MSFC teams for the flight phase fies, collects and documents the capabilities
of the program. Skylab real-time operations and constraints imposed by other elements.
demonstrated the effectiveness of this rela- This integration process frequently incorpo-
tionship between the JSC and MSFC teams. rates participants external to mission oper-
The mission operations team supported ations (for example, participants from the
the design and development phase of the program and the project), as well as the
Space Shuttle program at the program and flight system contractor and the payload
project levels and helped develop operational user. In most cases, this is accomplished by
workarounds for flight systems and software mission operations directed panels that are
deficiencies that could not be corrected be- chartered by the program.
fore the flight test phase of the program.
INTRODUCTION TO MISSION OPERATIONS
MISSION OPERATIONS STRUCTURE SE&I
The Mission Operations Directorate (MOD) This paper will discuss three mission oper-
at the Johnson Space Center is highly inte- ations functions that are illustrative of the
grated and structured around the principal key principles of operations SE&I and of the
skills needed for mission preparation, plan- processes and products involved.
ning, training, reconfiguration, facility de-
velopment, facility operations and real-time • The flight systems process was selected to
flight operations. illustrate the role of the systems product
Each mission operations element consists line in developing the depth and cross-
of a single functional discipline, e.g., mission disciplinary skills needed for SE&I and
design, flight systems, reconfiguration, providing the foundation for dialogue
training, etc. Usually each organizational between participating elements.
element is structured to provide dedicated • FDDD was selected to illustrate the need
support to either the Shuttle or Space Sta- for a structured process to assure that
tion. This is believed to be the best way for SE&I provides complete and accurate
assuring accountability in individuals and
146
SE&I PROCESSES
results that consistently support program mission operations schematics were complet-
needs. ed prior to the flight system critical design
@ The flight director's role in mission oper- review (CDR) and were used as the founda-
ations was selected to illustrate the com- tion for the mission operations assessments.
plexity of the risk/gain tradeoffs involved
in the development of the flight tech- The Systems Handbook Today
niques and flight rules process as well as
the absolute importance of the leadership Mission operations schematics are developed
role in developing the technical, oper- by the controllers to a common set of internal
ational, and political trades. drafting standards and conventions and use
the design engineering drawings, vendor
Flight Systems Division SE&I schematics and software source code. For the
Shuttle, operations personnel were required
The early Mercury program employed a mix- to develop Houston Aerospace Language/
ture of operations and engineering personnel Shuttle software language skills as a job
to support the real-time operations. Later, requirement. Permanent, prime contractor,
flight experience established the need for a in-house and in-plant support assures the
full-time systems operations team. The need flow of the raw design data and provides the
for an integrated compilation of flight sys- communications conduit between the sys-
tem data usable by the crew and ground tems operations personnel and the prime
team for real-time operations led to early contractor design engineers so they can ad-
versions of the systems handbooks that are dress questions as they arise. After the STS-
the foundation for today's handbooks. Rudi- 51L accident, all handbook schematics were
mentary integrated schematics were used for expanded to provide direct traceability to
Gemini, but with the Apollo program came design drawings by title, drawing number,
more complex inflight computing capability. revision and date.
Consequently, the schematics were expand- The systems controllers who develop the
ed to define the computer interfaces and used schematics derive significant training from
significantly more of the vehicle design and using design data and translating this data
performance data base within the schematic into an operationally useful format. The
notes. schematic development and the integration
As mentioned earlier, the schematics of data from supporting systems and subsys-
were used for the first time to support the tems provides independent validation of the
Skylab critical design reviews and the system design intent. In particular, it identi-
SOCAR. During these reviews, program and fies issues where the integrated design may
project management recognized that the sys- have compromised the program intent. The
tems operations teams and the systems drawing configuration control process re-
handbooks were an SE&I asset. The modu- quires verification by section and branch
larity of the Skylab elements, along with the chiefs and final approval by the division
integrated nature of the systems, established chief. Formal reviews are conducted before
the pre-mission role for the systems hand- major handbook releases. As a result, the op-
books to support the flight system design erator and the supervisory chain derive a
review process as an integrated activity. The training benefit from the systems handbook
usefulness of the handbooks in addressing process.
integrated systems issues was thus formally The systems handbooks are used by
established. For the Apollo Soyuz Test Pro- crews, flight directors, training instructors
gram (ASTP), and the Shuttle and Spacelab and mission operations payload support per-
programs, the preliminary version of the sonnel. They are a formal portion of training
147
documentation and are carried in the Shuttle mance limits, crew capabilities, failure
flight data file. The schematics support modes, and crew and ground response times.
airborne system troubleshooting and provide The emergency procedures therefore provide
a common base for the crew and the ground a bridge from operations checklist proce-
to discuss suspected problems and follow-on dures into options that allow the crew to con-
actions. They provide the basis for MOD dis- tinue the current flight phase with modifica-
cussion with the contractor engineering tion, to reconfigure to recover capabilities, or
team and with the mission support team. to utilize an alternate capability. Figure i is
a typical procedure used during powered
Flight Procedures. The development of the flight for a main B undervolt condition.
systems handbook provided the foundation The final type of flight procedures devel-
for the development of flight procedures. oped by the controllers are the malfunction
Three basic categories of flight procedures procedures (MALS), which are used when
are developed: the operations checklists, the time is available to troubleshoot, locate and
pocket checklists and the malfunction proce- define the boundaries of problems that occur
dures. inflight. To solve the problem, the crew and
The operations checklist procedures allow ground use the full range of instrumentation
the crew and ground systems operations to available and any visual or external cues
accomplish a planned activity and are nor- available. The procedures are developed in a
mally developed as blocks of integrated sys- logical format using a series of "if," "and,"
tems activities; for example, aligning the and "or" statements. Warning notes are pro-
inertial measurement unit. Procedures de- vided, as well as permissive steps when
velopment requires intimate familiarity ground and crew consultation is required pri-
with the system; its interfaces, controls, and or to continuing the procedural sequence.
displays; and with the intended task to be These procedures have allowed the correct
accomplished. Operations checklist proce- isolation of the majority of inflight problems
dures cross all systems and technical disci- for the Shuttle program.
plines, and as a result of their development, A final category of flight procedures con-
provide another level of systems integration cern payload operations and involve multiple
and design validation. Procedures associated flight elements.
with an Orbital Maneuvering Subsystem
burn, for example, involve loading the ma- Flight Systems Organizations. Since
neuver targets into the computer, selecting Gemini, the MOD flight systems organiza-
and configuring engines for the burn, acti- tions have been structured to address a
vating the correct digital autopilot, selecting complete space system. Examples include
displays, and specifying of data to be record- command service module, lunar module and
ed. Shuttle. Each section within an organization
Pocket checklists are emergency proce- has responsibility for an assigned system,
dures based on the operations checklist. The with its subsystems, software, instrumen-
term "pocket" is used because the checklists tation, display, crew controls, command
must be readily available for critical mission controls, procedures, mechanical, power,
phases and are sized to be carried by the crew cooling, and thermal and consumable inter-
in the pockets of their flight suits. faces. During the Skylab program, each or-
The pocket checklist procedures define ganization also had to know about inflight
the steps to be taken when an unplanned maintenance and support logistics.
event occurs. These procedures address The systems organizations of the MOD
critical failures and are flight-phase unique. participate in flight systems design via for-
They require knowledge of system perfor- mal membership on the working groups,
148
SE&I PROCESSES
Crew
Activitv Plan CAP
and FDF FDF
(L- 12 to L-S)
Fli{
Rq
Flight Flight Trajectory Data
MCC
Design Build
Desic_n (L ! 3 to L-6)
"light Definition (L-4½ to 2½)
Constratnts
Data (I-Loads)
Flight-unique
Orbiter/Payload / MCC Release
Flight
Software
Mass Properties
Generation
(L-7 to L-4)
Orbiter and
Orbiter and
Payload
_-- Flight-unique
TLMICMD Rqmts
(L- 16 to L-7} Onboard Software
Payload
_ique
Onboard Display
Rqmts
Build
Payload Training Model Rqmts (L-7 to L2½)
Payload
Model Rqmts
SMS
Figure 1 MOD Production Process Overview (L-Time in Months)
panels and boards established by the pro- capability for space flight. The perspective of
gram office. During the early design phase, the systems operator provides the cross-
they establish the data base for the develop- disciplinary assessment needed to assure ef-
ment of schematics and procedures for the fective overall systems engineering and
flight controllers. Because of this, direct con- integration. This perspective is the corner-
tractor liaison is maintained within the stone of the real-time capability of the man-
MOD systems organization and in-plant. ned spaceflight operations team.
Development of the mission product line
by the systems flight controllers increases Flight Design Division SE&I
their skills and knowledge. In addition, the
product line focuses the operations assess- The flight design process involves the inte-
ments of overall flight system architecture gration of payload and engineering require-
and provides the foundation for subsequent ments with mission objectives to form an
steps. Finally, as a recognized product, it is integrated mission design. The flight design
used by several groups in support of their must satisfy both Shuttle system design and
individual responsibilities. Program SE&I payload design constraints while considering
products typically must exhibit the same the additional constraints imposed in consid-
characteristics--they must pass the value- eration of safe mission conduct and mission
added test. success.
The systems operations contribution to The flight design process is a critical node
the early design and eventual operation of in the Shuttle mission preparation process.
the flight system has been essential in assur- In addition to flight design, the process
ing safe, effective and functional system provides initialization data for the ground
149
ENGINEERING I ENG
RFIT
CYCLE I SUPER I-L MMU ENG ENG
Ist TAPE CR SDTF Rl CYC

CYC I
STAGE I-L SMS
STAND FLT
TDDP CIR TDDP FOP LO
RDY ALONE RFIT
[ I I-L SMS
77
I
42
351 323 309 288 228 _14 186 161
/ 193 7O
260 221 175
FLT
FLT CYC
I-L ALT SMS
ASC Ist FPSR CR FOR MMU DATA
FREEZE STAGE SUPER I-L I-L I-L ORBIT FLT

PT TDDP TDDP FOP TAPE RDY APPR APPR RFIT RFIT LO
FLIGHT
CYCLE
228
I I--I II 207 179 140 109
1
I
88
I
I
70 42 o
284 270
242 136 91 77 57
f I
12 11 10 9 8 7 6 5 4 3 2 1 0
Time prior to launch, months
Figure 2 Flight Design Template
facilities, Shuttle primary and backup soft- The flight design process acquires a vast
ware, flight and payload planning, and real- amount of input data from a wide variety of
time decision support products. sources. The input data for the early phase of
Within the flight design and dynamics the program is typical specification data, but
discipline there are three mission phase ana- during the operational phase of the program
lysis and design work areas--ascent, orbit it becomes highly flight specific and fre-
and descent--and one functional area--real- quently component specific. A good example
time operations. The FDD, working in would be constraints for engine throttling
coordination with other mission operations related to a specific Space Shuttle Main
elements, establishes and integrates the Engine turbo pump.
propulsive and non-propulsive consumables,
abort propellant dump analysis, and manip- Flight Design Cycles. The flight design
ulator requirements and analysis into the process has three principal cycles designed to
overall flight design. The overall integration satisfy the requirements and lead times of
of activities supporting a mission is provided the many users. The conceptual flight profile
by a flight design manager. cycle provides the program office with data
150
SE&I PROCESSES
for making commitments to the payload The flight design handbooks developed
customers and assessing the overall suitabil- during recent years have documented the
ity of the operations flight design approach. flight design SE&I process and, to a great
The engineering cycle supports the ini- extent, represent the structure and relation-
tialization of the engineering and test facili- ships that must exist to incorporate integrat-
ties as well as the initial shuttle mission ed trajectory design into any space program.
simulator (SMS) training load. The flight These documents are invaluable examples of
cycle supports MCC and SMS initialization the structure and approach needed for fur-
for final training and operations, Kennedy ther space exploration activity. They also
Space Center (KSC) Launch Processing provide a good textbook for personnel in-
System checkout and launch support, God- volved in SE&I management to describe the
dard Space Flight Center network support, relation between trajectory, systems, soft-
and range safety. The flight design cycles are ware and objective data. In addition, they
under review to determine if a single cycle define input/output requirements, integra-
could be used to satisfy all user require- tion nodes, audit points and interfaces to
ments. This latter objective requires signifi- external elements for data acquisition and
cant standardization within the program, transfer.
improved and timely provision of payload
specific data and significant training stan- An Illustration of the Flight Design Pro-
dardization. cess. The integration of the constraints im-
posed by the flight system, environment,
Flight Design Documentation. The flight payload and operations in the determination
design process is the last of the mission oper- of the launch window will be used to illus-
ations processes to be documented as a trate one aspect of the flight design process.
structured flow from the conceptual phase The launch window is the time period
through the delivery of the launch-loads that the Shuttle should launch to achieve
used for flight. The full documentation of precise program requirements. This activity
these processes is now contained in 22 vol- is described in the flight design handbook via
umes of flight design handbooks. Documen- three processes that satisfy Shuttle and
tation was undertaken to serve four distinct payload requirements. These processes are
objectives: (1) document the corporate mem- further combined and iterated to develop the
ory of this process before it is lost; (2) estab- integrated launch window. This initial step
lish an error- and omission-free process, of the process provides input data for subse-
necessary because of the critical nature and quent planning involving deorbit opportuni-
use of the flight design products; (3) support ties, sequence of events, pointing, thermal
the design of an integrated computing sys- assessments and so forth.
tem as an aid to support the flight design The constraints imposed in launch win-
process; and (4) assure consistent design and dow determination represent the broad
rationale between similar missions. range of considerations faced by the flight
The two years after the STS-51L accident designer in this task. Where practicable,
were used to safe the flight design system, priorities are established to assist the flight
document the process and initiate a multi- designer. The actual development of the
year plan for code conversion, consolidation, launch window analyses is governed by a 27-
documentation and configuration control of page procedure within the flight design
all applications software. Process flow charts handbook.
were developed for every activity involved in Flight design is an essential element for
the flight design analysis and production space flight. The documentation of this pro-
activity. cess captured what was in the minds of the
151
talented and imaginative individuals work- between the preliminary design reviews
ing in this field, and provided the definitive (PDRs) and CDRs. This phase is character-
text for future flight design work for space ized by major tradeoffs between program
exploration. requirements, flight system design, crew and
For the Space Station Freedom program, ground and customer roles, schedule and
MOD has developed process flow charts for cost. During this period the flight director,
all functions that describe the input/output supported by all mission operations ele-
activities within mission operations and be- ments, refines the operating _concepts and
tween mission operations and the Level II leads the operational trades involving auton-
program elements, MSFC, KSC, GSFC and omy, fault tolerance, crew and ground func-
international partners. These flow charts de- tions, and flight design and payload suppor-
scribed interfaces, product exchanges and tability. As flight system design becomes
work templates. They were used to define the more focused during this period, the program
roles and mission boundaries needed for sus- costs and the real world design trades con-
tained and effective relationships between verge and program tradeoffs must be imple-
participants. Documentation of the SE&I mented. As a result, the mission operations
process is absolutely essential to clear and integration process is initiated to provide the
effective role and responsibility definition, program and project managers with a clear
and is a primary step in minimizing jurisdic- understanding of available options. The op-
tional battles between SE&I elements. tions are generally provided by in the form of
operations compatibility studies, similar to
Flight Directors SE&I the SOCARs described previously, or in the
form of an integrated mission design assess-
The mission operations SE&I process uses ment.
the Flight Director Office to provide the top
level, multidisciplinary integration, risk/ CDR Support. The CDR support to the
gain assessment and validation of the inte- program from the mission operations team is
grated mission preparation. significantly different because of the avail-
Flight directors are selected from the ability of the mission operations flight
ranks of MOD personnel. Selection is based systems handbooks and the increased knowl-
on leadership, technical abilities, stability edge of the team. The operations team has
and judgment as established by their perfor- acquired significant experience in working
mance during flight operations. They are with the program and project as a member of
already intimately familiar with the operat- the change control board (CCB) and through
ing disciplines, interfaces, flight and ground the CCB processes. The CDR represents a
systems capabilities, crew capabilities and milestone for reassessing the design and is
the mission risk/gain process. The challenge frequently the first time that the maturity of
for the flight directors is acquiring and the software begins to approach the maturity
maintaining the clear perspective needed for of the hardware.
multidisciplinary technical, operational and The principal contribution from mission
political trades and leading the many di- operations during this time is in the detailed
verse elements to operationally correct risk/ operational suitability assessments. These
gain decisions. assessments concern the mission suitability
The lead flight director is central to the of the flight system design and involve pro-
process for the assigned missions. gram requirements, hardware and software
design, mission design, and crew and ground
Pre-CDR Support. Support to a program capabilities. Through these assessments the
from the Flight Director Office is initiated preliminary risk/gain trades and fault down
152
SE&I PROCESSES
options are established, operating philos- Flight Rules. Flight rules are the funda-
ophies are defined and mission options ascer- mental risk/gain policy document for mis-
tained. Within mission operations, the CDR sion conduct. The "flight rules outline
is not a discrete process. It is considered one preplanned decisions to minimize the
of the many milestones of a process charac- amount of real-time rationalization required
terized by an increasing involvement by when non-nominal situations occur from the
operations personnel in the change boards start of the terminal countdown through
and control mechanisms established by the crew egress."
program. The involvement extends to the The most complex, difficult and critical of
flight preparation period, which has two dis- the integration processes provided by the
tinct processes and products representative Flight Director Office is flight rules develop-
of the flight director's role in the mission ment. Flight rules used today trace their
operations SE&I. These processes involve beginnings to aircraft flight tests. Rudimen-
flight techniques and flight rules. tary guidelines were provided for the flight
test pilots relative to test conditions, and go-
Flight Techniques. The initial flight tech- no-go criteria were provided for test continu-
niques process was developed, and since ation or termination. Similarly, during
Apollo, has been chartered by the Level II Mercury the rules for selected systems fail-
program. The process was established to ures were also a simple set of go-no-go crite-
address the growing complexity of the inter- ria involving powered flight abort and
action between flight software, flight system mission continuation or termination. Rules
and flight objectives. This process provided also addressed the control center, network
the technical focus for the operations, engi- and flight instrumentation requirements.
neering and contractor teams to address the Today's flight rules involve sophisticated
use of the as-built flight system, the soft- risk/gain trades across redundant systems,
ware, and the crew and ground capabilities multiple mission phases, engineering and
in accomplishing flight objectives. During payload objectives, and crew and controller
Apollo, the ground system, flight procedures capabilities. They also reflect and tradeoff
and flight software were the only elements the payload objectives, crew adaptation and
that could be readily changed within cost flight system survivability in defining mis-
and schedule considerations. The flight tech- sion duration for off-normal conditions.
niques process, assisted by Draper Laborato- Additionally, they clearly define the respon-
ries and the operational vehicle and software sibilities of key personnel implementing
developers, established virtually all of the flight operations.
navigation capabilities for Apollo. They While the rules are infinitely more com-
developed the technique for the Apollo 12 plex, the principle of the rules remains the
pinpoint landing and were a principal contri- same; that is, "to establish the risk versus
butor to the Apollo 13 return. gain trades" before the mission, utilizing the
The product line of the techniques process full range of operational, program and engi-
is initially the series of detailed meeting neering judgment available in the pre-
minutes, which provide the basis for flight mission environment.
procedures and the rationale for the majority To assure complete visibility to all trade-
of the flight rules and mission design con- offs involved in the flight rules, rule ratio-
straints. The flight techniques process pro- nale, techniques data and Systems Oper-
vides the integration of the knowledge base ations Data Book (SODB), references are
available on the flight system to drive flight contained in the published rules. The SODB
designs, procedures and flight rules. and its variants were developed during
153
NSTS/SSF PROGRAM OFFICE

• LEVEL II HARDWARE AND SOFTWARE DECISIONS AND SCHEDULES
MISSION OPERATIONS TEAM
• FUNCTIONICONCEPTSOPSINTEGRATION I
/ I
• CONTROL CENTER & TRAINING INTEGRATION AND OPERATIONS FLIGHT SYSTEMS PROJECTS OFFICE
• RECONFIGURATION & TRAINING
• INTEGRATED FLT DESIGN REQUIREMENTS • OVERALL PROGRAM INTEGRATION • HARDWARE AND SOFTWARE
• OPERATIONS PLANS SCHEDULES SCHEDULES
• ODF • FLIGHT PREPARATION SCHEDULES - ORBITER & CARGO
• FLIGHT & GROUND OPS DOCUMENTATION - MANIFEST DEFINITION CONFIGURATION DEFINITION
• CREW, FLIGHT CONTROLLER. & SUPPORT TEAM - PAYLOADS SUPPORT
TRAINING - PIP/ANNEX REQUIREMENTS
SIMULATORS - LANDINGABORT SITES
- INTEGRATED SIMS
VEHICLE AN ULES
• FLIGHT DESIGN/PERFORMANCE
• MMDB
• I-LOADS
• FACILITY DESIGN/M&O/ANDSUSTAINING ENGINEERING
• INTEGRATED SAFETY/HAZARD ASSESS
• OVERALL SCHEDULING /o .,_ ,\ / Ksc

_ " _1_ ,,./ • LAUNCH & FLIGHT OPS COORDINATION
• MCCJPOCC,'$SCC RECONFIGURATION
jr E _ _'_ 1_ - FLIGHT SYSTEM AND CARGO
• SMS/SSTF RECONFIGURATION I t, _ L I, _ PROCESSING
| _ _ I A | -VEHICLETESTANDCHECKOUT
• FLIGHT.SOFTWARE RECONFIGURATION
| _ _ | | -CARGOTESTANDCHECKOUT
• FLIGHT AND OPERATIONS O_RECTORS _ J _ _ o _ -END-TO-ENDTESTING
r - PAD SU PPOF
• FLIGHTCOflTROLLERS- U.5 & INTERNATIONALS
ROOOTICS AND EVA OPS SUPPORT
• NASA INTEGRATED CONTROL OPERA-
• CONSUMABLES TIONS & LAUNCH COMMIT ASSESSMENT
• REAL-TIME SUPPORT
y_ • TURNAROUND
- PAD SUPPORTSUPPORT
SCHEDULING
• MISSION RISK/GAIN POLICY
U_ERJCU!OMERdP01(r
SCF/POCC/ESC/P01( _
• COMMUNICATION AND DATA
/SI _:_ii_:::: L, V E Ri E S REQUIREMENTS
- JOINTS OPS PROCEDURES
• iNTERNAL CHECKOUTSCHEDULE
FLIGHT CREW OPERATIONS DIRECTORATE
• TEST AND CHECKOUT SCHEDU LE
• CREW ASSIGNMENT COORDINATION - INCLUDING END-TO- • NETWORK INTERFACE TEST SCHEDULES
CREW AVAILABILITY END TESTING - SIM SUPPORT
- OPERATIONS SUPPORTAND - SUPPORT TO OTHER PROGRAMS
• CREW CAPABILITIES & CONSTRAINTS PROCEDURES INPUTS
• CREW OPERATIONS REQUIREMENTS - CUSTOMER PROVIDED TRAINING • END-END TESTING

- SIM SUPPORT
• DATA REQUIREMENTS
• "iNTERNAL SCHEDULES
Figure 3 Mission Operations Integration
Gemini by mission operators with support by address the flight-unique objective and
the prime contractor for the purpose of docu- payload risk/gain trades for each specific
menting the performance capabilities and mission, flight objective and payload ele-
limitations of the flight system. Since ment.
Apollo, the SODB has been maintained by Flight directors, like program and project
the prime contractor, with mission oper- managers, depend on a matrix structure of
ations as the primary user. organizations to accomplish their responsi-
The leadership function provided by the bilities. The flight directors are consistently
flight director, using the flight techniques successful because their roles are well
and flight rules process, provides the focus defined, and because the integration tech-
for the integration of flight-specific work niques are facilitated by the MOD organiza-
within mission operations. tion structure as well as by clearly defined
The rules and rationale section in the all- product line and support processes. These
flights document is almost 900 pages. The characteristics must exist to successfully
flight-specific annex published for each cope with the complex issues imposed by all
mission is about 70 pages. It is provided to mission elements.
154
SE&I PROCESSES
PRINCIPAL REQUIREMENTS OF AN 2. SE&I must utilize the existing capabil-

EFFECTIVE SE&I PROCESS ities of organizations.
SE&I is the "integration" of the techni-
The mission operations elements, processes, cal, operational, economic and political as-
and products are oriented to the singular ob- pects needed to support a major program.
jective of safe and successful manned flight The broad range of work, skills required and
operations. The spacecraft on the drawing complexity of issues virtually precludes the
board, like the ship in a harbor, is a safe development of a single SE&I organization
ship, but that is not what spacecraft and for a major program. SE&I responsibility
ships are for. The mission operations job is to must be distributed to be successful.
take the spacecraft from the harbor of the 3. SE&I elements must recognize and ac-
drawing board into space, accomplish a mis- cept that major and complex programs will
sion and then safely return the spacecraft to involve technical, operational, political and
Earth. economic needs.
In recognition of this responsibility, the Major programs must address and sup-
mission operations processes are structured port the needs of the various constituencies
to assure effective policy, objective, system involved in establishing the program and
and operations integration. Within this must consider all of the economic issues
framework, complex risk/gain trades are involved in program development and
conducted and validated at all levels, culmi- operations. This recognition is essential if
nating in a completely independent and NASA and its contractors are to develop a
dynamic assessment and stress test during more flexible and responsive approach to
the integrated training process. program management.
The mission operations process can illus- 4. SE&I must have a process-based struc-
trate the principles necessary to a successful ture and a defined product line and life cycle.
SE&I. It is believed that these principles are The complexity of SE&I requires a struc-
useful to other SE&I elements that have the tured process to assure all interfaces are ad-
responsibility for NASA flight programs at dressed, proper responsibilities assigned,
the project and program level. and SE&I is effectively mechanized. SE&I
1. SE&I must have necessary roles and requires a solid grasp of all the elements to
missions that are clearly defined by the probe brought together, where the elements
gram and implemented by the project and logically come from, where they fit in the
technical organizations. sequence, what the end product is and what
SE&I is necessary because the integra- the alternatives are.
tion processes needed to address the techni- SE&I can be accomplished by a few gifted
cal, operational, political and economic people for a limited time, but without
aspects of major programs are complex. structured processes, SE&I will become
The value-added principle is the basic inefficient, outputs will not meet schedule
test that should be used in determining role commitments, "more integration resources
and mission assignments. will be needed, and the downward spiral will
SE&I by its nature will be controversial begin." SE&I is not provided by massive ap-
and participating elements may stonewall plication of resources. It comes about by
the process. When this occurs, the program, structured processes that clearly establish
project or technical manager must quickly the roles and responsibilities of the support-
and personally address the issue, establish a ing elements and use them effectively.
program position and demand the support The SE&I process definition is also used
required. to establish the product line of participating
155
elements and define input/output require- SE&I within NASA's flight programs is a
ments. This product line must be phased to constantly evolving and complex process
the life cycle of the program. involving many conflicting requirements
5. SE&I leadership must exist within all that must be brought together to support
elements of the SE&I process structure and program needs throughout the program's life
must be clearly recognized and accepted by cycle. An SE&I process that is effectively
the assigned individuals and their organiza- structured with distributed responsibilities
tions. will support program needs and recognize
Accepting an SE&I leadership role is to many of the prerogatives of the existing
recognize and accept conflict, particularly in NASA elements. Each complex program,
the project and technical organizations. however, will have some elements that do
Organizations assigned an SE&I role must not fit neatly into the existing NASA
recognize and accept the technical, oper- infrastructure because of economic, political
ational, political and economic implications or other considerations. SE&I will always be
of the SE&I role. SE&I must address the controversial, in structure and in implemen-
needs of the program, which must supersede tation.
the needs of individuals and organizations.
156
SYSTEMS ENGINEERING FOR OPERATIONAL SUPPORT SYSTEMS
SYSTEMS ENGINEERING CONSIDERATIONS FOR __,/-

OPERATIONAL SUPPORT SYSTEMS / 5
by Robert O. Aller (0 /
Operations support as considered here is the Implementation, integration and transition

infrastructure of people, procedures, facili- of these major changes to the Agency's oper-
ties and systems that provide NASA with ational capacity require significant manage-
the capability to conduct space missions. ment attention. To assure NASA's future in
This infrastructure involves most of the research, development and operations, this
Centers but is concentrated principally at system must be implemented successfully
the Johnson Space Center, the Kennedy and designed to minimize NASA's operation-
Space Center, the Goddard Space Flight al costs.
Center, and the Jet Propulsion Laboratory.
It includes mission training and planning, TOTAL SYSTEMS ENGINEERING
launch and recovery, mission control, track-
ing, communications, data retrieval and The need for incorporation of systems engi-
data processing. neering concepts and discipline is much
Operations support of NASA's space broader for operations support systems than
flight systems during the 1960s and the the hardware and software systems for
1970s was associated with operations char- which it is normally considered. As noted,
acterized as Research and Development. operations support is an infrastructure of
Flight programs were a single flight of people, procedures, facilities and systems.
limited duration or a series of flights to ob- Although systems engineering is routinely
tain specific data or to demonstrate an oper- applied to each new system, the major prob-
ational capability. This required operational lems often occur between systems and
support systems to be reactive and respon- frequently among people, procedures and fa-
sive to relatively short duration programs. cilities. A disciplined systems engineering
In the past ten years, this has continued approach formulating each of these elements
with some notable exceptions. With ad- in the establishment of the "system" cannot
vances in space and data technologies, the be overemphasized. NASA has learned many
demonstrated capabilities and advantages of times that good system contractors do not
space operations and the increased cost and necessarily nurture good operational person-
complexity of space systems has led to longer nel and technicians nor do they necessarily
duration and repetitive flight programs. Sys- develop usable maintenance procedures. Ex-
tems engineering of operational support sys- perience has also shown that facilities not
tems must accommodate this evolution and adequately analyzed in conjunction with the
the increasing operational nature of NASA. planned utilization of the facilities require
The need for systems engineering is criti- constant modification to meet operational
cal to NASA in its preparations for conduct- needs. In considering support capability,
ing operations in the late 1990s and into the each of the infrastructure elements requires
next decade. The planning and implementa- analysis and carefully managed selection
tion of the operational support systems for and attention.
this era are under way. Proper systems An organizational tier of system analysis
engineering is vital to the development of from the whole to each element can be ap-
each new system, as well as to a "total sys- plied in a macro sense to assure consider-
tems engineering" of the functionality and ation of both technical and nontechnical
interfaces of the entire operational system. systems. A macro analysis of the system
157
involves many considerations; two nontech- rare that a contractor has an established
nical areas that have often caused problems technique to trade and iterate design cost
are inadequately skilled personnel and un- against operations costs. LCC needs to be a
derdesigned facilities. driving discipline to assure that the costs of
The nature of operations support requires operating the increasingly more sophisticat-
a spectrum of talents and skill levels. Most ed flight systems can be controlled. The
newly developed systems have not properly flight systems of today are projected for 15-
analyzed the experience and skill mix need- 20 years of operation. This demands that the
ed nor the number of personnel required, operational support systems be analyzed and
which varies from skilled flight controllers to designed to minimize LCC, or the cost of op-
maintenance and repair technicians. Too of- erations will increasingly erode NASA's re-
ten a process to analyze the system operation sources for new development capacity.
and system maintenance and repair require- NASA and its contractors should establish
ments is not properly developed in advance, more sophisticated models of development,
resulting in an operations team that is un- operations and maintenance costs that will
dersized and underskilled. provide more reliable data for conducting
A second issue is simply undersizing operations cost trades against alternative
facilities. While managers operate on the system designs.
"nature abhors a vacuum" principle and
insist that each square foot of a new facility SYSTEMS ENGINEERING AND
needs clear functional definition, too often OPERATIONAL SUPPORT SYSTEMS
new facilities are found to be inadequately
sized even before they are put into operation. Systems engineering for operational support
This is particularly true with new operation- systems follows the traditional disciplines
al systems. Facilities should be designed to applied to the development of major flight
accommodate the unforeseen. Quite often the systems. Operational support requirements
unforeseen is a result of an incomplete need to be translated into performance pa-
analysis of the operational and system rameters and configurations through multi-
requirements prior to facility design, but ple iterations to optimize system design. The
also new requirements will emerge. A contri- purview of systems engineering includes
buting difficulty is NASA's facility approval requirements definitions and verification,
process, which is instituted before a reliable system analysis and design, integration
utilization analysis is available. It is prudent planning, requirements control, configura-
to provide capacity for some growth to action control and testing.
commodate new requirements. While similar to the design and develop-
Another nontechnical factor that is of ment of major flight systems, the emphasis
increasing importance to NASA is life cycle of the systems engineer for operational sup-
costing (LCC). NASA has not traditionally port systems is generally to provide generic
incorporated LCC as a critical selection, de- support to an aggregate of flight programs
sign or engineering process. The elements and the increasing necessity to provide sys-
critical to LCC have all been managed and tems with extended operational usefulness.
considered, but an LCC process has not been This operational longevity can be attained
established within NASA or by NASA's con- by systems capable of accommodating
tractors as a routine process. LCC was used change while continuing to provide service.
as a contract selection factor by NASA for The Deep Space Network operated by Jet
the first time in 1988 with the selection of Propulsion Laboratory and the Goddard
the second Tracking and Data Relay Satel- Space Flight Network are excellent exam-
lite System (TDRSS) Ground Terminal. It is ples of major systems that have provided
158
space flight program support with tracking tion age, the computer (including software),
and data retrieval service for 30 years, all of communications, and electronics industries
the while undergoing changes to provide have developed new technologies and capa-
support for increasingly complex missions. bilities often before a flight program's sup-
In addition to providing generic support port requirements are established. The
to many users, a vital characteristic of sup- incorporation of these new services needs
port systems is operability. The focus in the careful examination and scrutiny; when
vehicle development community is principal- these new services clearly enable future or
ly directed toward designing a system that expanded programs, however, the operation-
optimizes performance; the operations com- al community should provide them to
munity's focus is directed more toward an ef- enhance future operations. An example of
fective and efficient operation of the system. capability beyond defined need was clearly
Operability emphasizes ease of operation, incorporated in the TDRSS program in 1975.
resistance to system problems and failures, The TDRSS provides capacity and data rates
maintainability, reparability, simplicity, ef- that will meet the requirements of the 1990s
ficiency, capacity for growth and modifica- and well into the next century. It has also
tion, and accommodation of users. enhanced flight control concepts by greatly
These two features, multiple program increasing the capability to access and con-
support and system operability, are key to trol spacecraft. If phasing in of added capa-
assuring the proper systems engineering of bilities can be accommodated, it will permit
operations support systems. They are smoothing of resources and help the budget-
historically the most difficult to sustain as ing process.
cost and schedule pressures frequently tend Another important consideration of the
to compromise the system's range of utility systems engineer in the evaluation of sup-
and operability. port requirements is the impact these
services will impose on the user. The goal is
REQUIREMENTS, EVALUATION, always to limit the interface restrictions
VERIFICATION AND CONTROL imposed on the user program. Two of NASA's
major operating systems have caused major
Operations systems development is general- constraints in their use. The Shuttle Pro-
ly driven by new, expanded or improved gram has imposed major safety and integra-
support service required by new flight pro- tion complications on deployed payloads and
grams or expanded program objectives. The the TDRSS program has imposed scheduling
systems engineer needs to challenge user and radio frequency interface constraints
requirements to assure the "real" needs are that have been restrictive to some users.
not sacrificed at the expense of low priority, Some of these constraints with both the
highly demanding requirements. Occasion- Shuttle and the TDRSS were intrinsic to
ally, requirements are driven by the fact their operational concepts, but some were
that new technology is available and not avoidable, had operability and utilization
that it is essential (or even desirable) for been more completely evaluated.
effective operation. The systems engineer When developing systems such as the
must consider the broad base of program Shuttle and the TDRSS that represent a
users and not provide a narrow focus of major departure in operating concepts and
support that overly complicates or ignores expansion of the operational envelope, the
operations of the aggregate of users. systems engineer needs to broaden analysis
While sharply defining real needs, it is to the entire mission or spectrum of missions
equally critical to consider the potential to to better define and limit the major compli-
provide for future capacity. In the informa- cations to system operations and utilization.
159
NASA's experience with both of these pro- and expensive to develop. Similarly, less
grams has clearly indicated much more ef- expensive hardware solutions may be possi-
fort is required to operationally understand ble when the full range of software abilities
the implications of their use. This experience is considered. (The designer must always
should be understood and applied in the de- bear in mind, however, the probable need for
velopment of the Space Station, the Earth system expansion, which may make the
Observation System, and their associated selection of a more complex hardware ele-
support systems in consideration of their ment the prudent choice since software modi-
broad utilization objectives. fications are generally less costly than
Requirements verification and control is computer replacement.) This analysis of
generally practiced with all new develop- system architecture may involve the estima-
ments, but control can be difficult to sustain tion of size, complexity and structure of the
throughout an extended development of an software needed for a series of mainframe
operational support system and its oper- computers.
ational life. Unfortunately, the nature of Management and the systems engineer
flight programs is to evolve operational sup- must realize the definition, design and
port requirements and occasionally to trans- implementation of major software packages
fer capabilities planned for the flight system require the same systems management
as requirements to the ground support sys- disciplines and controls as do hardware
tems. Careful monitoring and control of components. Because software code can be
these requirements is essential, particularly easily erased or changed, it does not follow
in the development of software support sys- that changes should be considered any more
tems. Requirement changes will constantly lightly than they are for hardware. The
occur, however, and an efficient process to flexibility associated with software is its
identify, approve and control requirements is greatest asset, but if not well managed and
vital. Clear and precise interface definition controlled, it becomes its greatest problem.
is necessary to enable this control. A detailed Although software design has made aston-
knowledge of the flight programs that intend ishing progress over the years, software
to use the support system, as well as an un- development remains a significant problem
derstanding of other related support systems to most major systems. The inability of
(operational support systems rarely provide management to accurately predict software
the total functional support services), is re- costs, delivery schedules and performance
quired for effective requirements control by has consistently been a severe problem in the
the systems engineer. Interface definition development of major operational systems.
and control are essential to maintaining
requirements control. LONG-RANGE REQUIREMENTS
SYSTEM ARCHITECTURE AND SOFTWARE An area often inadequately considered in

DESIGN the design of a support system is its capacity
for future modification and upgrade as new
For those operational systems that contain technology becomes available and as re-
standard computers and specialized soft- quirements change over time. Many systems
ware, which are a majority of the ground must continue to provide services while
systems, a special subset of systems engi- undergoing these modifications. Proper con-
neering must be performed to obtain the op- sideration for redundancy and capacity can
timum hardware and software combination. greatly alleviate future expense and compli-
The selection of the wrong hardware may cations. Making assumptions regarding
result in software needs that are difficult future support requirements can lead to a
160
system design that reasonably accommo- major rebuilding of the 240-ft. DSN antenna
dates alternative future growth require- reflectors prior to the Uranus Encounter was
ments. Designs that fail to gracefully accom- feasible because each antenna was sequen-
modate change are limited and will lead to a tially modified, and alternate antenna
dead end. systems were available at each DSN location
While the Deep Space Network and the to provide continuous tracking support.
Goddard Space Flight Network have effec- Redundancy within the system--provided
tively accommodated change, the initial because of the critical nature of tracking and
design of the TDRSS ground station failed to communications support--and ground sta-
properly consider the long-term need to mod- tion accessibility have been critical to
ernize and upgrade. This required extensive NASA's ability to continuously operate these
redesign and change at significant cost. A networks while modernizing their capabil-
focus on the current needs may result in ities.
limited system utility, and pressures to When considering system changes, space-
implement the least cost system may con- based operational support systems present a
strain future expansion and ultimately, be different challenge. Two major factors influ-
the least cost effective. ence the consideration to changemaccessi-
The development of new features or major bility and cost. Cost is directly related to the
changes to operating systems is frequently lack of direct access. Accessibility is difficult
implemented with new contractors. General- at best and impractical for most. The Hubble
ly, if NASA and the systems engineer did not Space Telescope is accessible at great
specifically assure that the original contrac- expense by using the Shuttle but the TDRSS
tor provided adequate hooks, the new con- satellites are presently inaccessible. The
tractor's implementation will be difficult and systems engineering of space-born support
costly. The term "transition phase" is ap- systems must consider the criticality of the
plied by NASA to the period when an online service to be provided, the longevity of the
system is undergoing change while continu- service (providing adequate redundancy and
ing to provide support services. This is a deli- projected service requirements), and the lack
cate and challenging problem to the systems of ready access to the system. Satellites can
engineer and critical in the selection of an of course be replaced by an upgraded satel-
appropriate design. It is important that tran- lite; systems that use multiple satellites at
sition be planned in conjunction with the multiple locations, however, such as TDRSS,
design process and not after the design is require identical satellite configurations to
established. provide orbital coverage as an effective oper-
In considering long-range requirements ational system. Spacecraft replacements are
for operational systems, the type of system, normally planned to sustain the system
the importance of support, and accessibility through its projected life with no ground in-
are major factors. These factors were central terface and no service changes to the system.
to NASA's decision and ability to sustain the When new services become necessary,
Deep Space Network (DSN) and the Goddard they are expensive and require an extended
Space Tracking Network over their extended period to implement. A space-based system
lifetimes while undergoing numerous modi- that consists of several satellites, such as
fications and changes. The continuous avail- TDRSS, requires a change to the services of
ability of these sites has been possible each satellite in orbit to provide an effective
because of the redundancy within each orbital service to the user. This is consistent
ground station, a configuration of multiple with the practice of upgrading all ground
sites (redundancy among the ground sta- station locations to the same service configu-
tions), and their accessibility. The recent ration; the accessibility makes the upgrade
161
of space systems more costly and requires a operability. Developments that continuously
much longer time. focus on the ultimate operation are consis-
NASA is now planning to modify the tently superior in performance and in total
TDRSS with a higher data rate KA band costs.
service. The system and budget planning for
this upgrade was begun in earnest in about The need for NASA to be alert to systems
1985, and it is anticipated the satellite fleet engineering is more prevalent now than ever
will not be in orbit until early in the next before in NASA's history. The implementa-
century, a 15- to 20-year period. The TDRSS tion of new operating systems is planned
will have been operating for 20 years or more throughout the 1990s to prepare the agency
by that time. A similar projection will mean for managing the operations of complex, long
the replacement system, Advanced TDRSS, duration and extremely high data rate pro-
will likely be operating to the year 2020 and grams. The quantity of data the agency will
perhaps beyond. It is clear this system will be processing and managing in the later part
be as challenging as the original, with new of the decade was unimaginable in the 1960s
problems replacing those resolved with and the 1970s. This data will be generated
TDRSS. The transition of replacing the by programs that will be launched in a
TDRSS systems presents a significant new period when NASA will already be operating
challenge not faced with initiating the origi- and supporting a complex array of flight
nal service. Providing systems engineering vehicles. New ground systems, with evolving
for the Advanced TDRSS to remain viable 20 capabilities and changing interfaces, will
to 30 years in the future will tax any man- come into operation almost continuously
ager. Systems can no longer be replaced throughout this period. The complex nature
frequently or modified to meet individual of interaction among these systems demands
program desires. Careful and complete sys- a visibility and overarching control that can
tem analysis and forward-thinking engineer- only be accomplished through a systems
ing are essential to the establishment of engineering network. Management and co-
durable, effective support systems. ordination of the individual systems is re-
quired to assure total system functionality,
ASSURING OPERABILITY interface definition, requirements control
and the optimization of each system.
To succeed in developing a support system NASA has done an excellent job for the
that meets the goals of operability--ease of past 30 years in providing an operations
operation, failure resistance, maintainabil- infrastructure that has met the demands of
ity, efficiency, expandability and accommo- exploring space. The next 30 years of space
dation to usersmrequires continuous effort operations are equally exciting but represent
and emphasis by the systems engineer. An a far greater challenge. The quality of the
oversight and regular review from the opera- systems engineering of the operations
tor's viewpoint will contribute to success. support team is critical to both the success of
Both the government and the contractors the nation's civil space flight programs and
should provide an operational position with- to sustaining a viable operational role with-
in their program management structure that in NASA.
is responsible for maximizing the system's
- 162
POLITICAL AND INSTITUTIONAL FACTORS OF SE
N 9 3- 690
POLITICAL AND INSTITUTIONAL FACTORS AFFECTING
SYSTEMS ENGINEERING
by John F. Yardley
Most systems engineering courses and text- regarding the space program. All of these
books discuss only the engineering aspects of methods influence both the executive and
the subject and are silent about the non- legislative branches of our government.
technical world's influence on the planned The President and his staff are very im-
project. This approach, although entirely portant to NASA's programs. They must
satisfactory for many engineering programs, make a positive decision to include money for
including smaller NASA programs, leaves specific NASA programs in the budget re-
out a significant element affecting large quest before it is even considered by Con-
NASA programs. Some traditionalists be- gress. In these times of large government
lieve these nontechnical aspects should not deficits, which makes starting new programs
even be considered in the systems engineer- very difficult, NASA is pressured to cut back
ing process. However, if we take the broad requirements and save money. This pressure
view that systems engineering should take even results in the stretch-out and cancella-
into account all significant requirements in tion of some ongoing projects. Sometimes in
order to produce the proper end-product, negotiations with the Office of Management
then it should include consideration of those and Budget, NASA is asked to choose be-
outside non-technical parties who can levy tween programs.
requirements on NASA programs. This pa- The Congress is one of the most signifi-
per identifies these elements, discusses their cant groups that has a major impact on
viewpoints and probable influence, and re- NASA's requirements. In addition to repre-
views some past case histories as illustra- senting their constituents' opinions, mem-
tions of these problems. It also presents some bers feel it is their duty to closely watch the
suggestions for working with these non- details of NASA's large programs. In the last
technical groups, which ma) better achieve several decades, they have acquired the tech-
overall optimum systems engineering and nical staff needed to exercise this detailed
integration (SE&I) solutions. oversight. As a result, they are in a position
to demand program requirement changes,.
THE NON-TECHNICAL GROUPS and they have the appropriation muscle to
back up their demands. _
There are many outside parties that provide The Department of Defense (DoD) and
inputs to NASA program requirements. other national security agencies often get
The public at large can have a profound involved in NASA's programs because they
influence on whether large sums are appro- have agreed to participate in a joint develop-
priated for NASA's major programs. They ment or because they plan to use the end-
respond to NASA triumphs and disasters product. They are involved in monitoring
and are sensitive to NASA's role in projec- NASA's projects from a national security
ting the American image around the world. viewpoint, and they sometimes require
Their influence is exercised by letters to changes in NASA programs if they see
Congress and the White House, by public potential security problems. DoD is always
appearances (interviews and speeches, for included as a major player in any high-level
example), and through public opinion polls White House space study or committee.
163
READrNGS IN SYSTEMS ENGINEERING
Some NASA partisans feel that certain DoD EXAMPLES FROM THE PAST
offices take a biased view and try to reduce
the NASA program so DoD can play a larger History provides examples of political and
role in space study. institutional influences that illustrate how
Other executive departments substan- these factors affect NASA's programs. After
tially involved in NASA program matters the first Sputnik launch, the basic thrust to
include the State Department, the Com- start the space agency, as well as to initiate
merce Department, the Transportation the Mercury Program, came mostly from
Department, and the Office of Management Congress, with lukewarm support from the
and Budget. Eisenhower administration. NASA's foun-
Government agencies and national com- ding organizations, the National Advisory
missions that fact-find, study and advise the Committee for Aeronautics (NACA), was
executive and legislative branches upon re- used as a technical staff; decisive actions
quest include the General Accounting Office, were primarily political in nature.
the Office of Technology Assessment, the During the sixties, the Kennedy Admin-
National Academy of Sciences, the National istration's decision to land astronauts on the
Academy of Engineering, the National Moon and return them safely was political;
Research Council, the National Commission namely, to catch up with the Russians and
on the Challenger Accident, the Advisory get back U.S. world technological leadership.
Committee on the Future of the U.S. Space NASA provided a large part of the technical
Program, and a number of other ad hoc com- staff work, which consisted of preliminary
mittees. analyses and estimated success probabil-
International cooperation agreements ities.
often involve political considerations, and In the case of the Space Shuttle start deci-
the foreign parties usually desire a part of sion, interaction increased between systems
the job that interfaces with many of the engineering and the non-technical world.
mainstream elements. If these agreements Richard Nixon had become President in ear-
are not structured with the interface prob- ly 1969, just a few months before the lunar
lems in mind, they can have major effects on landing. He requested the National Space
systems engineering. Council to study and report on the options for
Scientific specialist groups feel they could the next phase of space flight and the long-
more wisely spend the money appropriated term future. NASA was heavily involved in
for the large NASA manned space programs this year-long study. The report recommend-
on their own research or on unmanned scien- ed that development of a Space Station and a
tific space programs. This group sometimes fully reusable Space Shuttle be undertaken
works through "associations" seeking to in parallel as the next step in manned space
plead their case in the media. flight and as the precursor of later lunar
Local communities near NASA centers colonies and manned Mars expeditions. At
often inject themselves into the process of this point, a political decision was made to
dividing the program work between Centers. continue study of the Space Shuttle but to
The actual division of work can have a sub- defer the Space Station. Work then proceed-
stantial effect on the efficiency of the collec- ed on the Shuttle with Phase A contracts and
tive NASA effort and can make the systems then Phase B contracts. It soon became
engineering effort much more difficult than apparent that the Shuttle development cost
a distribution based on technical merits. The was more than double the original prelimi-
political realities usually result in a "techni- nary estimates used in earlier decision
cally non-optimum" work split. making. Much interaction ensued between
164
NASA, the Office of Management and Bud- tem is probably workable, it certainly is not
get, and Congress, with NASA trying to get considered optimum from a technical or effi-
the added funding commitment. When this ciency viewpoint.
was not forthcoming, the program manage-
ment exhorted the projects to reduce cost MINIMIZING DISRUPTION FROM
without changing the basic concept. POLITICAL AND INSTITUTIONAL SOURCES
After more work confirmed that the cost
ceiling could not be achieved with the two- We have identified many of the outside
stage fully reusable Shuttle, it was finally sources of SE&I requirements and have
decided by NASA management that the given some examples to illustrate how im-
concept had to be changed in order to stay portant these inputs can be. Although most
within funding limitations imposed by the of these examples involve major program
Administration. Phase B contracts were changes, many smaller requirements are
extended, a major realignment of contractor questioned and changed. Now we will discuss
teams was required, and the current Space methods of dealing with these inputs effi-
Shuttle configuration (solid first stage, ciently, minimizing disruption and avoiding
parallel burn) emerged. After the Apollo adversarial relationships with these outside
program and its blank check atmosphere, organizations.
NASA was not used to this limited funding Good two-way communication between
approach. NASA and these outside groups is one of the
This process left much to be desired from major keys to negotiating proper agreements
many points of view. It delayed the program, on these external requirements. In order to
caused a lot of wasted effort, and contractors properly deal with these outside inputs, we
formed teams and wasted a lot of their dis- need to know what new requirements they
cretionary funds (estimated at $100 million). are considering before these requirements
No one is to blame for this, since everyone are placed on NASA as irreversible de-
was feeling their way in a new environment. mands. If we wait until then, it is very
A better process, however, would have been probable that we will develop adversarial re-
very worthwhile. lationships with the requester who has "gone
In contrast to the Shuttle, the Space Sta- public" and will be embarrassed to lose the
tion did have strong support from President argument. This will make the requestor very
Reagan. This support was not for short-term difficult to deal with during subsequent
political gain but rather because President negotiations.
Reagan believed it was in the best long-term This means NASA must be organized and
interest of the country, despite the fact that managed in a manner that facilitates com-
most of the President's cabinet members and munication of both internal and external
his close advisors were against starting the pertinent information.
space station (Hans Mark's book). Most of these outside inputs are discussed
The fragmented nature of the final Space at lower levels during interface or coordina-
Station hardware split between Centers tion meetings as "what ifs." They rarely first
resulted from an intense tug of war for surface at the NASA decision level in the
appropriate shares of the program between program office or the SE&I management.
the NASA Centers and their supporting This means that the lower-level NASA peo-
political communities. Some NASA Centers ple interfacing with outside organizations
felt that much of this struggle was for their must be trained to recognize these potential
very survival. Others in NASA felt this type inputs at the beginning, and the overall
of work distribution was necessary for broad NASA organization must have good commu-
Congressional support. While the final sys- nications at all levels so these issues can get
165
to the appropriate level early, a strategy can or additions, and to develop rapport. While
be developed, special analyses can be per- doing these things, it is very important for
formed, and contacts to discuss the issues NASA individuals to come across as open,
can be planned. forthright, and on top of their jobs. If the out-
When preparing the material for discus- side participants sense ulterior motives that
sion with the requester, NASA must be very are not discussed, or evasiveness and bluff-
careful to consider the requestor's point of ing, trust cannot develop. In fact, many of
view objectively and not just from the NASA these groups currently have a "corporate
parochial viewpoint of pure engineering memory," which includes perceptions of
ease, i.e., the "invented here" syndrome or many NASA Center biases. These must be
the "bad for the Center" rationale. NASA overcome by careful and fair negotiations,
must remember it is not the user or the own- bending over backward to diffuse any biased
er but rather the implementor of someone reputation.
else's requirements. When presenting the NASA Centers have tended to think of
material, NASA must be careful to avoid many of these non-technical meetings as
patronizing the requester. If the requestor NASA Headquarters' responsibility (and a
senses a patronizing attitude, the relation- big, time-wasting nuisance), believing the
ship rapidly becomes adversarial. Center's only role should be the engineering
It is also important for NASA to advise and management of the program. For NASA
and sell the appropriate outside groups on to do the most efficient and effective job, this
any requirement changes they feel are neces- concept must be changed. Whereas NASA
sary before the action has been taken beyond Headquarters should participate in many of
the point of reasonable return. This is par- these contacts, the Center people who best
ticularly true when NASA wants to relax know the subject and have prepared the
requirements that were important to outside material should present it. This is also an
groups once the program was begun. Many excellent training mechanism. The younger
examples exist where Congress finds out Center people will rapidly develop a much
after the fact that the program can no longer broader view of the outside world from inter-
meet the planned launch rate or some other acting with NASA. Working with the
fundamental requirement, and the original centers in this manner, Headquarters also
"NASA promise" must be broken. This has a facilitates better internal communications.
very negative effect on rapport with Con- Interfacing with Congress presents some
gress, the scientific community or any other special problems, particularly when NASA
major stakeholder. It is therefore important is trying to sell them a new program. There
to level with these outside groups as quickly are laws prohibiting government employees
as possible after deciding to revise a basic from lobbying, and the line between lobbying
requirement. and briefing on the merits of a new program
NASA must also develop harmonious re- is somewhat blurred. NASA must use its leg-
lationships with the pertinent outside groups islative and legal offices to help the program
and individuals. This can be done, among people properly interpret the law. In all
other ways, using a network of committees or probability, NASA will not be able to com-
scheduled small meetings among selected municate with Congress on critical subjects
individuals. The important thing is to plan in the manner and with the frequency they
for relationships and have the meetings reg- desire.
ularly. These meetings should be used to An alternative to direct NASA communi-
bring the groups up to date, to permit them cation with Congress is for NASA to work
to ask questions and critique the activity, to with its contractors and keep them informed.
smoke out impending requirements, changes The contractors are not bound by any laws
166
against lobbying and can communicate more Middle East, and the bail-out of the savings
freely with Congress. The contractors will and loan industry, such an ambitious plan
contact the appropriate Representatives and will be difficult to accomplish.
their staffs with their own messages, in any
case. It is not necessary for NASA to direct SUMMARY AND CONCLUSIONS
them to lobby (this being illegal), but NASA
should inform them of its position so that if External groups have a significant impact on
the contractors do contact Congress, they NASA's programs. Ten groups affecting
have the correct information. NASA are identified, and examples are
On some past programs, all of the prime given for some of the them. Methods of deal-
contractors informally worked together to ing with these external inputs are discussed,
keep Congress informed. One technique that the most important being good and open two-
has been popular with Congress is an "Infor- way communications and an objective atti-
mation Notebook" on a given NASA pro- tude on the part of the NASA participants.
gram. This notebook is kept in the Congres- The importance of planning ahead, of devel-
sional member's officefor easy reference and oping rapport with these groups, and of effec-
is updated monthly, providing a useful tive use of NASA contractors is covered. The
monthly resource for informal discussions. need for an overall strategic plan for the U.S.
space program is stressed.
NATIONAL STRATEGIC PLANNING FOR In order to obtain the broadest range of
SPACE opinions on the political and institutional
factors that affect systems engineering, the
After the Apollo program and President writer requested thoughts from a number of
Kennedy's clear mandate to land astronauts senior individuals who have been involved in
on the Moon and return in the sixties, the the interfaces between NASA and the out-
U.S. space program suffered from a lack of side world.
clear national goals and a strategic plan to In any subject as complex as this one,
achieve them. In the Apollo era, all of the there are always some differences of opinion.
diverse forces involved coalesced behind The viewpoints expressed above are those of
President Kennedy because they wanted to the writer and sometimes agree with the
beat our superpower adversary, the U.S.S.R., majority, and at other times do not. To pro-
in the technological war. Since that time, we vide the reader with another viewpoint, an
have been unable to generate such a unify- additional paper by David Wensley is repro-
ing environment. If this could be done, and a duced in its entirety in the appendix to this
framework for future space activity could be chapter. Mr. Wensley examines the subject
agreed on in the form of a strategic plan, the through the eyes of a prime Space Station
problems of interfacing with the outside contractor executive.
groups would be much easier. The author concludes that NASA does not
As of this writing, the Bush administra- pay sufficient attention to the impact of
tion has outlined a long-range plan for explo- political and institutional factors in con-
ration that includes colonizing the Moon a ducting its business and is being hurt by this
and a manned exploration of Mars, which attitude. NASA should therefore focus on
could form the framework for a good strate- working with these outside groups, adjust
gic plan. However, it must be accepted by NASA policies and organizations to
these outside parties and backed with appro- facilitate interfacing with them, and train
priations by Congress before any plan can NASA personnel to conduct themselves ap-
realisticallybe made. During this period of a propriately in this environment.
growing national deficit, tensions in the
167
POLITICAL AND INSTITUTIONAL FACTORS AFFECTING SE
POLITICAL AND INSTITUTIONAL FACTORS AFFECTING

SYSTEMS ENGINEERING: AN INDUSTRY PERSPECTIVE
by David Wensley
The "nominal" or "idealized" systems engi- • Funding constraints used as a mechanism

neering process must take into consideration of technical and political control.
the political and institutional factors that
have become prevalent in the government An effective project management and
funded and, to a certain extent, the privately systems engineering process must deal con-
funded civil space activity. Attempts to ig- structively with these influences. They may
nore these influences may result in delay and affect program content, allocation of respon-
frustration of the systems engineering pro- sibilities, schedules, interface definitions,
cess. optimization and trade-off criteria, and tech-
NASA programs are currently growing nical decisions. They may even affect mission
larger in scope, longer in duration and fewer definition, and they most certainly will affect
in number. The increasing number of partici- funding availability versus time. Effective
pants includes NASA Centers, other U.S. management must provide for flexibility to
agencies, international agencies and contrac- react to these influences without undue pen-
tors. NASA programs are also characterized alties on performance, cost or schedule. A
by higher public visibility, and are more cost- constructive and cooperative relationship
ly and more politically sensitive. between the legislators and program man-
In this environment, the Congressional agement can minimize the impact of these
committees that appropriate and authorize interactions on planned efforts.
budgets will demand more justification for Many examples of the influences noted
expenditures, more political return from the above can be cited in the Space Station Free-
investments and more oversight of ongoing dom program, including:
activities.
• Legislated use of a Flight Telerobotic
POLITICAL FACTORS Servicer to advance U.S. robotic technol-
ogy.
Space projects have always been an instru- • Allocation of responsibilities to interna-
ment of domestic politics and a tool of politi- tional partners.
cal influence in international relations. As • Political influence on the work distribu-
the scope and importance of these projects tion between NASA Centers.
increases, we can expect more political influ- • Increased complexity of interfaces and
ence on the systems engineering process. management processes resulting from
The political influence may take any of distributed responsibilities.
several forms: • Funding constraints (fencing) in budget
authorization bills.
• Geographical distribution of funds to gain • Oversight committees and hearings to
political support. critique technical progress and to influ-
• Creation ofinternationalpartnerships. ence resolution of technical issues.
• Insertion of technical requirements to
satisfy strategic national goals. The systems engineering process must
• Increased Congressional and Administra- stand the tests of external review and cri-
tion involvement in the technical tique. The assumption that technical man-
decision-making processes. agement and decision making is part of an
PREGEDING PAGE BLANK NOT FILMED

immune internal process is, unfortunately, planned strategy for deferral of less critical
unrealistic. Techniques for effectively elements, retaining the systems engineering
managing the external factors include: effort to establish interface requirements
and essential design definitions, can mini-
• Open communication between project mize such effects.
management and stakeholders to under-
stand needs and develop trust. INSTITUTIONAL FACTORS
• Realistic planning to support schedule
and cost commitments. Numerous institutional factors will affect
• Disciplined control of requirements to the systems engineering process, principally
avoid unwarranted cost and schedule those inherent in NASA and the participat-
growth. ing Centers. Examples include:
• Effective use of risk management tech-
niques to minimize iterations on design • Accepted standards, design criteria, and
and testing. specifications.
• Cost-effectiveness and life-cycle cost ana- • Design, management and operational
lysis to substantiate trade decisions. preferences of the Center functional divi-
• Early emphasis on operations, mainten- sions.
ance and logistical support to avoid un- • Availability and preference for use of
predicted support costs. Center test facilities.
• Early constructive resolution of responsi- • The organization and management struc-
bility conflicts between NASA Centers ture adopted for the program.
and between NASA and international • Traditional practices such as use of com-
partners. mittees, panels, boards, documentation
formats and integration processes.
These features are characteristic of tradi- • Use of support contractors to supplement
tional management and represent the expec- NASA staff.
tations of legislators and budget authorities. • NASA and Center policies and priorities
Deviations from these norms, especially if that may influence, for example, technol-
uncovered through Congressional or media ogy selections, responsibility issues and
probing, can be disruptive and potentially requirements decisions.
dangerous to the stability and continuity of a
program. The systems engineering process The above considerations can have a
can significantly reduce these risks by stay- major impact on systems engineering
ing on track and by making summary data requirements derivations, trade studies, ar-
available to project managers to use in open chitecture and design selections, test plans
dialogue with legislators. and operational concepts. They will also af-
Program changes are unavoidable, and fect the schedule and effort required to
systems engineering and project manage- evolve the design baseline, to resolve inte-
ment must be equipped with the analytical gration issues and to establish interface
tools to respond effectively to these changes. agreements. The potential magnitude of
The ability to re-prioritize and reschedule ac- these effects dictates early planning for their
tivities rapidly and with reasonable accuracy accommodation in the systems engineering
is essential, especially in response to funding process. It is virtually pointless to embark on
adjustments emanating from the annual a systems engineering process that ignores
budgetary process. More often than not, these considerations. The institutional char-
these events are unanticipated and result in acteristics have evolved over time and are
traumatic and costly adjustments. A pre- the product of many successes and failures. It
170
POLITICAL AND INSTITUTIONAL FACTORS AFFECTING SE
is unlikely that personnel assigned to new and contractors must be measured as ele-
projects will adopt practices that violate ments of a closed-loop process that affects the
tradition. Contractor personnel should be efficiency and quality of our space activities.
prepared to adapt to customer preferences, The identification of improvement candi-
but customer (NASA) personnel should be dates should focus on the inanimate process,
prepared to consider new alternatives as part not on the organizations or people. This
of a continuous improvement process. allows the people to conduct constructive
problem identification and resolution with-
THE SEARCH FOR IMPROVEMENT out personal implications.
Increased budget pressures and heightened CONCLUSION

concern for foreign competition create a
demand for NASA to seek new methods of NASA stands at a crossroads. The opportuni-
achieving quality and reducing costs. Indus- ties for space exploration and the exploita-
try is similarly under pressure in these areas tion of space attributes and resources have
and is rapidly adopting techniques such as never been better. Public acceptance of space
Total Quality Management (TQM) princi- projects and reliance on space technology as
ples. NASA is beginning to apply TQM crite- a means to resolve worldwide environmental
ria in new procurements and has started to and resource issues have never been higher.
look for TQM opportunities within its organi- Yet NASA lacks credibility with the legisla-
zational structure. Conversion to these prin- tors of this country who are eager to voice
ciples represents a major cultural change criticism of NASA's planning and implemen-
and, in many respects, is contrary to recent tation of space projects. Their depth of pene-
trends within NASA. TQM teachings empha- tration into NASA's technical activities is
size reduction in top-down management di- increasing. Not only is the continuity of
rection, preferring increased delegation and NASA funding at risk, the scope of NASA's
empowerment of the lower tier personnel. responsibilities is also threatened. Transfer
Since the Challenger accident, the tendency of responsibilities to other agencies and even
within NASA has been to increase manage- the creation of new agencies is topical con-
ment and technical oversight. In the Space versation. Resolution of this dilemma
Station Freedom program, for example, requires more than a willingness to commu-
many layers of management and technical nicate and to negotiate differences; it re-
oversight exist within the Level II and Level quires a change in the NASA management
III organizations above the prime contractors culture that recognizes the degree of matur-
and their subcontractor teams. Although ity of the space industry. The mystery of
contractors are generally committed to cost discovery and the complexity of space tech-
and schedule objectives, their progress is of- nology is no longer an adequate defense for
ten controlled by the efficiency and speed of cost or schedule overruns. Critics demand
the NASA management and systems engi- performance that meets expectations. NASA
neering processes and integration. If the in- has the opportunity to lead the family of
volved participants agree that improvement federal agencies in demonstrating fiscal
is essential to create an environment of responsibility combined with technical
credibility and trust at the political level, achievements. Systems engineering will be a
recognition of these relationships can lead to major contributor to this success by provid-
constructive changes. ing the guidance for timely decisions leading
Measurement of performance is essential to effective project management.
in the search for improvement. Both NASA
171
OPTIMIZATION IN THE SYSTEMS ENGINEERING PROCESS
Loren A. Lemmerman
The essential elements of the design process Preliminary design is far more complicat-
consist of the mission definition phase that ed, both because the analysis techniques are
provides the system requirements, the con- more complex, and also because these tech-
ceptual design, the preliminary design and niques require specialized knowledge. The
finally the detailed design (Figure 1). Mis- objective of this step is to refine the design
sion definition is performed largely by oper- estimates made during conceptual design
ations analysts in conjunction with the cus- and to add additional detail to the descrip-
tomer. The result of their study is handed off tion of the configuration. At the conclusion
to the systems engineers for documentation of this phase, the aircraft is defined well
as the systems requirements. The document enough so that a company can comfortably
that provides these requirements is the basis bid the cost of producing it.
for the further design work of the design en- Detail design is largely mechanical in na-
gineers at the Lockheed-Georgia Company. ture, and normally occurs after receipt of an
The design phase actually begins with order for production. This is not an area of
conceptual design, which is generally con- concentration in this presentation, however.
ducted by a small group of engineers using To provide a basis for amplification of the
multidisciplinary design programs. Because conceptual design process, look at Figure 2.
of the complexity of the design problem, the The function of the conceptual design process
analyses are relatively simple and generally is to conduct a multidisciplinary analysis of
dependent on parametric analyses of the con- an aircraft to produce values of parameters
figuration. The result of this phase is a base- that describe an aircraft. These parameters
line configuration from which preliminary are top level descriptions that leave most of
design may be initiated. the actual configuration details undefined.
Contracted Proposal Contract

Studies Requested Award
1-3 Years 1-2 Years 1 Year
Detail
Definition
Mission Requirements
System _ Design
Conceptual _ Preliminary
Design Design --_ Manufacture
Market Research Advanced Design Aerodynamics Project Engineering

Operations Analysis Systems Engineering Structures Detail Design
Propulsion Stress
AircraftSystems Subsystems
Supportability Weights
Value Engineering
Test
Figure 1 Essential Elements of the Design Process
PREGEDING PhGE BLANK NOT FILMED

However, implicit in this process is the investigated to ensure that a true optimum
trading of factors that relate to the perfor- had been found. This old procedure was also
mance of the configuration. The trades I tedious. All data had to be manipulated man-
mean are typified by the thinness of a wing ually. Although this did provide useful in-
desired by an aerodynamicist versus the sight to the designer, the cost was a further
thickness of a wing as desired by a structural delay. Dozens of computer runs had to be
analyst. scanned, the results judged for correctness,
and the results plotted on carpet plots. Many
hours of talented labor were consumed per-
forming menial tasks.
_ Multidisciplinary
Analysis [F//__is cu
t opti
H
Initial
Configura-
tion
f
Subject
Constraints
to
Evaluate
Configura-
tion
Figure 3 Preliminary Design
Figure 2 Conceptual Design

The former process was basically elimi-
nated at Lockheed-Georgia several years
Typical parameters defined at this stage ago, in favor of the approach shown here,
are fuselage length and width, wing area, based entirely on numerical optimization.
sweep, aspect ratio and, to a limited extent, The new process is described schematically
control surface. here (Figure 3). The former process was usu-
In former times, conceptual design was ally completed in one day. Many of the man-
manually directed and highly iterative. The ual actions have been eliminated. Now, a
process consisted of guessing an initial con- given study may consume as much time as
figuration, analyzing that configuration, and formerly, but a much larger range of design
then systematically varying each of several variables has been included.
design parameters to examine a design space
within which manual optimization could PRELIMINARY DESIGN PROCESS
take place. Normally the number of param- (PARTIAL)
eters examined did not exceed four, because
of the human limitations in absorbing more The next step in the design process is pre-
variations than that. There were several liminary design. This is the process, partially
disadvantages to the former approach. This illustrated in Figure 4, by which the concep-
process was time consuming, fallible and tual design baseline is analyzed in greater
tedious. It was time consuming because the depth to confirm the design or provide foun-
answer depended on many executions of a dation for changing the design. This process
computer code. It was fallible because the is typified by the more or less simultaneous
choice of the parameter variation to be exam- execution of many detailed design codes in
ined was entirely at the discretion of the several disciplines. Obviously, the communi-
designer. Thus, the quality of the answers cation during the process is difficult, and the
was directly dependent on the skill of that designs proposed by each discipline are fre-
designer. In addition, no one could be sure quently inconsistent. Iterative loops, while
that a large enough design space had been very common, cannot be represented because
174
OPTIMIZATION INTHE SYSTEMS ENGINEERING PROCESS
I Conceptual
Desig_ I
Control Surface Engine Control

Loads Needs
I Surface 11 Pressures '1
Structures
I S/C I I Aer° ] Propulsion l Electronics
Wing I Prop. Load l

l Weight I
Constraints Constraints
Figure 4 Preliminary Design Process
of the indeterminate sequence of such iter- methods provide a wing shape, starting with
ation. a specification of a desirable pressure distri-
As an example of the type of analysis con- bution. Using such methods, the wing con-
ducted in this phase, consider aerodynamics tour and twist distribution may be calculated
for a moment. The codes frequently applied directly.
in this phase consist of full potential subsonic Subsonic optimization techniques have
or transonic codes for configuration analysis, generally been limited to the design of high
full potential codes for direct design, and lift systems. In this case, the optimal location
Navier-Stokes codes for highly complex vis- of a slotted trailing edge flap can be found by
cous flow analyses. As a result of the aerody- optimizing on the axial force for the system
namic analysis done during this phase of and by using paneling methods for calculat-
design, the wing external contours are fully ing the flap system pressure distribution.
defined and more reliable estimates of the Structural optimization has been done for
vehicle performance are available. Similar minimizing structural weight, given loading
refinements and definition are added by each conditions. In this case, the structure is mod-
of the participating disciplines. eled using finite element techniques, with
The deficiencies of the current approach element geometries such as thicknesses or
are immediately obvious. First and foremost, cross sectional areas taken as design vari-
the result is a suboptimal configuration. ables. Another example of structural opti-
Even though optimization may be used mization is in the design of composite panels.
within isolated analyses, the difficulty of The objective is to determine the ply orienta-
communication in real-time and the lack of tion to respond to specific loading conditions.
available tradeoff criteria mean that no glo- If I were to summarize the preliminary
bal, rigorous optimization occurs. design optimization work currently being
I have already alluded to the use of opti- done at Lockheed-Georgia, I would have to
mization on individual analyses in this say that its use is relatively new, that it has
phase. Here are some examples of such opti- been very well accepted, and that its use is
mizations. The aerodynamics discipline has certainly increasing. But this may eventual-
been very active in developing optimization ly become a severe problem for us, since the
techniques for the design of wings in tran- optimization is being applied to subprocesses
sonic flow, largely based on FLO codes. These within design. Worse yet, it is being applied
175
" Optimizer w/ Evaluate
Constraints _ Configuration
Aero S/C I I Structures I Propulsion
Figure 5 Proposed Preliminary Design Process
to old design philosophies. The result has to sensitivities. In the preliminary design pro-
be suboptimal designs. cess illustrated here, the former approach
The preliminary design process is clearly clearly will not work. The new process must
another candidate for improvement by opti- include a method for disciplinary engineers
mization. The technical challenge of this to examine the analysis code results as they
problem is much greater that that of the con- are being generated to ensure that the opti-
ceptual design process, but the potential pay- mized results are valid. When such an opti-
off is also much larger. The challenge comes, mization method is available, however, I
in part, from the large number of individuals submit that the problem is far from finished.
and computer programs normally invoked at This is so because people inevitably are the
this design state, and the current dearth of designers, and the design techniques, wheth-
technology available to solve the very differ- er through optimization or not, must take the
ent problems thus posed. human element into consideration.
One possible way to apply optimization in
the preliminary design process is shown SYSTEMS ENGINEERING - A DEFINITION
here. The fundamental idea is that candidate
design parameters flow downward to the in- To expand on this theme, let me begin be giv-
dividual analysis modules and the result of ing you my orientation. I am in the Systems
the analysis flows back up to the optimizer. Engineering Department at Lockheed-
Obviously, such a system is far from reali- Georgia. This gives a reasonable definition of
ty. The technical challenges outweigh those what Systems Engineering means to us: a
of optimization itself. The analysis methods discipline that coordinates the engineering
normally used in preliminary design are activities within large organizations to help
state-of-the-art methods that are time con- produce a superior, cost-effective, timely
suming, user-sensitive and modeling sensi- product. By its very definition, it is a process
tive. Because of this, not only will new of dealing with people in a large design op-
optimization techniques be needed, but so eration. As such, our interest is not in the
will entirely new operational procedures. For internal working of design codes, but rather
example, optimization now is executed most- in how individuals use given design codes to
ly as a black box program. The analysis produce designs, and then how those indi-
points provided by support codes are consid- viduals transmit their information to other
ered to be correct and not subject to code designers in the organization.
176
OPTIM[ZATION INTHE SYSTEMS ENGINEERING PROCESS
Let me present the four main tasks of the involved, coordinating the studies needed,
Systems Engineering operation. They and documenting the result.
involve the management of trade studies, re- Some of the decisions illustrated in this
quirements, interfaces and technical risk. trade tree are supported by optimized meth-
Another way to express these four tasks is ods. For example, the vehicle may be initial-
Communication, Communication, Communi- ly sized with optimization, and components
cation, Communication. may also be designed with optimized meth-
Decisions are the design process. By its ods. Nonetheless, when design decisions are
very nature, design requires definition of to be made, there is a high likelihood that not
some configuration from an infinity of possi- all the decisions will have been supported
bilities. The best design is some compromise through optimization. The point is, optimiz-
of many and widely varying constraints. ation methods are embedded in the total
Many times the choices to be made are design process, and this must be taken into
aesthetic, or subjective, or not amenable to account in the development of these optimiz-
computer analysis. In these situations, and ation methods.
sometimes even in well-defined engineering This last feature is what I am trying to
choices, trade studies must be performed that illustrate in Figure 7. Some decisions of the
are outside the domain of the optimization design process will be made within the opti-
process. mization process. Some will not. But those
that do not must have information available
Vehicle from the optimization to assist the manual

decision-making process.This is true wheth-
er the outside decision is being made concur-
rently with the optimization or whether it
lags the optimization by days, weeks or
months.
Figure 6 Hierarchy of Decisions to Select a

LJIN vI U
Navigation System for an Airplane
Figure 7 Trade Studies with Optimization
The illustration above (Figure 6) is a sim-

ple representation of the decisions that The implication is that information more
might be made to select a navigation system comprehensive than just the final optimized
for an airplane. These choices are displayed configuration must be provided and stored.
as a hierarchy, beginning with the top level Possible information needs include sensitivi-
vehicle considerations, and then working ties around the optimal point and the
downward to finer levels of detail. Systems optimization history. In addition, it will be
Engineering is responsible for generating necessary to provide a way to interrupt the
such a trade tree to illustrate the decisions to optimization process as it is occurring to
be made, defining the design groups to be input new information to the optimization
177
process and to influence, on the fly, the out- minimum range requirements. Whatever the
come. requirement, this process allocates it to the
lowest level of the configuration, maintains
REQUIREMENTS FLOWDOWN the traceability to the top level requirement
and assures that the total system require-
Let me provide one more example, that of ment will be met.
requirements flowdown. This is another ex- The question is, "What is a proper alloca-
ample of the communication involved in the tion?" If a top level requirement is rippled to
design process. In this case, the objective is to the lowest level, which functional area
communicate to each individual designer the should contribute what proportion to the
importance of design in meeting the top level final performance? If we rely on a optimiz-
performance requirements. This is done by ation process that merely gives a final an-
analyzing the top level system requirements swer, we are blind. This is another case of not
and assigning or allocating these top level re- all functions being included in the optimiz-
quirements to the next lower level to deter- ation process. For these "outside" functions,
mine the drivers in the system. This process we have no sensitivity information upon
is repeated to successively lower levels until which to base realistic allocations. The actu-
the final objective is accomplished. That is, al situation might be as illustrated here,
the question "What is each individual's con- where the cost of attaining a given level of
tribution to the total system performance?" performance varies greatly from one disci-
is answered at the lowest logical level. pline to another. I have used cost as the mea-
A specific performance might be mainten- sure, but I could have used any measure of
ance manhours per flight hour, or it might be merit. For the illustration I have given, the
System Level
Performance
Requirements
Unique to
AllocatableElementsbetween I Element
1
[ 1
Allocatable Unique to
between Subsys Subsystem
Allocatable Unique to
between Comp Component
Figure 8 Requirements Flowdown
178
Allocation Allocation Allocation Allocation

1 2 3 4
PERF PERF PERF i PERF
Figure 9 Optimize Allocations
optimal allocation of the requirement is that ally occur during design. The visibility of tile
which simultaneously attains the top level design process must be maintained as fur-
system performance and minimizes the cost. ther developments are proposed. Careful at-
In the future, our optimization processes tention must be given to the management of
must provide visibility for such data. data in the optimization process, both for
I have attempted to illustrate that opti- technical reasons and for administrative
mization has a role in our design process, purposes. Finally, to satisfy program needs,
both today and in the future. The benefits are provisions must be included to give data to
well known already, but I believe that we are support program decisions, and to communi-
only seeing the proverbial tip of the iceberg. cate with design processes outside of the opti-
Optimization must, however, continue to mization process.
be sold and this selling is best done by consis- If we fail to adequately consider all of
tent good performance. For this good perfor- these needs, the future acceptance of optimiz-
mance to occur, the future approaches must ation will be impeded. We simply cannot
be clearly thought out so that the optimiz- allow that to happen. Optimization is too
ation methods solve the problems that actu- important.
179
SKYLAB 1
THE INITIAL FLIGHT ANOMALIES OF SKYLA P 3 9
By the NASA Investigation Board
At approximately 63 seconds into the flight sulted from a failure of communications

ofSkylab 1 on May 14, 1973, an anomaly oc- among aerodynamics, structural design, and
curred which resulted in the complete loss of manufacturing personnel. The failure to
the meteoroid shield around the orbital recognize the design deficiencies of the mete-
workshop. This was followed by the loss of oroid shield through six years of analysis,
one of the two solar array systems on the design and test was due, in part, to a pre-
workshop and a failure of the interstage sumption that the shield would be "tight to
adapter to separate from the S-II stage of the the tank" and "structurally integral with the
Saturn V launch vehicle. The investigation S-IVB tank" as set forth in the design crite-
reported herein identified the most probable ria. In practice, the meteoroid shield was a
cause of this flight anomaly to be the large, flexible, limp system that proved diffi-
breakup and loss of the meteoroid shield due cult to rig to the tank and to obtain the close
to aerodynamic loads that were not account- fit that was presumed by the design. These
ed for in its design. The breakup of the mete- design deficiencies of the meteoroid shield,
oroid shield, in turn, broke the tie downs as well as the failure to communicate within
that secured one of the solar array systems to the project the critical nature of its proper
the workshop. Complete loss of this solar ar- venting, must therefore be attributed to an
ray system occurred at 593 seconds when the absence of sound engineering judgment and
exhaust plume of the S-II stage retro-rockets alert engineering leadership concerning this
impacted the partially deployed solar array particular system over a considerable period
system. Falling debris from the meteoroid of time.
shield also damaged the S-II interstage The overall management system used for
adapter ordnance system in such a manner Skylab was essentially the the same as that
as to preclude separation. developed in the Apollo program. This sys-
Of several possible failure modes of the tem was fully operational for Skylab; no con-
meteoroid shield that were identified, the flicts or inconsistencies were found in the
most probable in this particular flight was records of the management reviews. None-
internal pressurization of its auxiliary tun- theless, the significance of the aerodynamic
nel which acted to force the forward end of loads on the meteoroid shield during launch
the meteoroid shield away from the shell of were not revealed by the extensive review
the workshop and into the supersonic air process. Possibly contributing to this over-
stream. The pressurization of the auxiliary sight was the basic view of the meteoroid
tunnel was due to the existence of several shield as a piece of structure, rather than as
openings in the aft region of the tunnel. An- a complex system involving several different
other possible failure mode was the separa- technical disciplines. Complex, multidisci-
tion of the leading edge of the meteoroid plinary systems such as the meteoroid shield
shield from the shell of the workshop (par- should have a designated project engineer
ticularly in the region of the folded ordnance who is responsible for all aspects of analysis,
panel) of sufficient extent to admit ram air design, fabrication, test and assembly.
pressures under the shield. The Board found no evidence that the de-
The venting analysis for the auxiliary sign deficiencies of the meteoroid shield were
tunnel was predicated on a completely sealed the result of, or were masked by, the content
aft end; the openings in the tunnel thus re- and processes of the management systems
181
PRECEDING P._IGE BLANK NOT FILMED
that were used for Skylab. On the contrary, Figure 1 shows the Skylab in orbit. Its
the rigor, detail, and thoroughness of the sys- largest element is the orbital workshop, a
tems are doubtless necessary for a program cylindrical container 48 feet long and 22 feet
of this =magnitude. At the same time, as a in diameter weighing some 78,000 pounds.
cautionary note for the future, it is empha- The basic structure of the orbital workshop
sized that management must always be alert is the upper stage, or S-IVB stage, of the S-IB
to the potential hazards of its systems and and S-V rockets which served as the Apollo
take care that an attention to rigor, detail program launch vehicle. The orbital work-
and thoroughness does not inject an undue shop has no engines, except attitude control
emphasis on formalism, documentation, and thrusters, and has been modified internally
visibility in detail. Such an emphasis can to provide a large orbiting space laboratory
submerTe the concerned individual and de- and living quarters for the crew. The Sky-
press the role of the intuitive engineer or lab 1 (SL-1) space vehicle included a payload
analyst. It will always be of importance to consisting of four major units---orbital work-
achieve a cross-fertilization and broadened shop, airlock module, multiple docking
experience of engineers in analysis, design, adapter, Apollo telescope mount--and a
test or operations. Positive steps must al- two-stage Saturn-V (S-IC and S-II) launch
ways be taken to assure that engineers be- vehicle as depicted in Figure 2. To provide
come familiar with actual hardware, develop meteoroid protection and thermal control, an
an intuitive understanding of computer- external meteoroid shield was added to cover
developed results, and make productive use the orbital workshop habitable volume. A
of flight data in this learning process. The solar array system (SAS) was attached to the
experienced chief engineer, who can spend orbital workshop to provide electrical power.
most of the time in a subtle integration of all The original concept called for a "wet
elements of the system under purview, free workshop." In this concept, a specially con-
of administrative and managerial duties, structed S-IVB stage was to be launched
can also be a major asset to an engineering "wet" as a propulsive stage on the S-IB
organization. , _: launch system filled with propellants. The
empty hydrogen tank would then be purged
THE SKYLAB PROGRAM and filled with a life-supporting atmosphere.
A major redirection of Skylab was made on
Skylab missions have several distinct goals: July 22, 1969, six days after the Apollo 11
to conduct Earth resources observations, lunar landing. As a result of the successful
advance scientific knowledge of the sun and lunar landing, S-V launch vehicles became
stars, study the effects of weightlessness on available to the Skylab program. Conse-
living organisms, particularly human, and quently, it became feasible to completely
study and understand methods for the equip the S-IVB on the ground for immediate
processing of materials in the absence of occupancy and use by a crew after it was in
gravity. The Skylab mission utilizes the as- orbit. Thus it would not carry fuel and
tronaut as an engineer and as a research earned the name of"dry workshop."
scientist, and provides an opportunity for The nominal Skylab mission called for
assessing potential human capabilities for the launch of the unmanned S-V vehicle and
future space missions. workshop payload SL-1 into a near-circular
Skylab uses the knowledge, experience (235 nautical miles) orbit inclined 50 degrees
and technical systems developed during the to the equator. About 24 hours after the first
Apollo program along with specialized equip- launch, the manned Skylab 2 (SL-2) launch
ment necessary to meet the program objec- would take place using a command service
tives. module payload atop the S-1B vehicle. After
182
SKYLAB 1
the command service module rendezvous and THE FLIGHT OF SKYLAB 1
docking with the orbiting cluster, the crew

enters and activates the workshop; Skylab is Skylab 1 was launched at 1730:00 (range
then ready for its first operational period of time, R =0) on May 14, 1973, from Complex
28 days. At the end of this period, the crew 39 A, Kennedy Space Center. At this time,
returns to Earth with the command service the Cape Kennedy launch area was exper-
module, and the Skylab continues in an iencing cloudy conditions with warm tem-
unmanned quiescent mode for some 60 days. peratures and gentle surface winds. Total
The second three-person crew is launched sky cover consisted of scattered cumulus at
with a second S-IB, this time for a second 2,400 feet, scattered stratocumulus at 5,000
56-day period in orbit after which they will feet, broken altocumulus at 12,000 feet, and
return to Earth. The total Skylab mission cirrus at 23,000 feet. During ascent, the
activities cover a period of roughly eight vehicle passed through the cloud layers but
months, with about 140 days of manned no lightning was observed in the area. Upper
operation. area wind conditions were being compared to
General Characteristics
Condition work volume 12,700 cu ft (354 cubic meters)
...... Solar Panels
Overall length 117 ft (35.1 meters)
Weight including CSM 199,750 (90,606 Kilograms)
Width OWS including solar array 90 ft (27 meters)
Experiments
• Micrometeoroid
• ' Shield
Apollo Telescope..
Mount ......
Multiple Ward Room

Docking
Adapter
Waste Compartment
Command &" •
Service
° o
Module
Sleep Compartment
Saturn Workshop
Airlock Modu
Figure 1 SkylabCluster
183
PS Payload Shroud
Diameter 6.6 meters (21.7 feet)
Length 16.8 meters
Weight 11,794 kilograms (26,000 lbs.)
ATM Apollo Telescope Mount

Wi Width 3.3 meters
Length 4.4 meters
Weight 11.181 kilograms (24,650 lbs.)
MDA Multiple Docking Adapter

Diameter 3 meters (lo feet)
Length 5.2 meters (17.3 feet)
AM Airlock Module
Diameter STS 3 meters (10 feet)
Diameter FAS 6.6 meters (21.7feet)
IU Instrument Unit
Length 0.9 meter (3 feet)
Weight 2,064 kilograms (4,550 Ibs.)
OWS Orbital Workshop

S-II Second Stage

Diameter 10 meters (33 feet)
Weight 488,074 kilograms (1,076,000 lbs.)
fueled
35,403 kilograms (78,050 Ibs.) dry
Engines J-2 (5)
Propellants: Liquid Oxygen 333,837 liters
(88,200 gallons)
Liquid Hydrogen 1,030,655
liters (272,300 gallons)
Thrust 5,150,000 Newtons (1,150,000 lbs.)
Interstage Approx. 5,171 kilograms (11,400)
Ibs.)
S-IC First Stage

Diameter 10 meters (33 feet)
Length 42 meters (138 feet)
Weight 2,245,320 kilograms (4,950,0001bs.)
fueled
130,410 kilograms (287,500 lbs.) dry
Engines F-1 (5)
Propellants: Liquid Oxygen 1,318,315 liters
(348,300 gallons)
RP-1 (Kerosene) 814,910 liters
(215,300 gallons)
Thrust 31,356,856 Newtons (7,723,726 lbs.)
Figure 2 SL-1 vehicle
184
SKYLAB 1
most other Saturn-V flights. The flight envi- apparent early deployment and loss of the
ronment was quite favorable. meteoroid shield. At this time, the vehicle
The automatic countdown proceeded nor- was at about 28,600 feet altitude and at a
mally with Guidance Reference Release oc- velocity of about Mach 1.
curring at R-17.0 seconds and orbit insertion At this time, vehicle dynamic measure-
occurring at R+599.0 seconds. The orbital ments such as vibration, acceleration, atti-
workshop solar array deployment was com- tude error, and acoustics indicated strong
manded on time; however, real-time data in- disturbances. Measurements which are nor-
dicated that the system did not deploy fully. mally relatively static at this time, such as
The solar array system (SAS) on the or- torsion rod strain gauges, tension strap
bital workshop consists of two large beams breakwires, temperatures, and solar array
enclosing three major sections of solar cell system position indicators, indicated a loss of
assemblies within each. During ascent, the the meteoroid shield and unlatch of the
sections are folded like an accordion inside SAS-2 wing. Further preliminary evaluation
the beams which in turn are stowed against revealed abnormal vehicle accelerations, vi-
the workshop. The meteoroid shield is a brations, and solar array system tempera-
lightweight structure wrapped around the ture and voltage anomalies at about R + 593
converted S-IVB stage orbital workshop and seconds. Temperature data loss and sudden
is exposed to the flight environment. The two voltage drops indicated that the SAS-2 wing
hinged solar array system wings are secured was separated from the orbital workshop at
to the orbital workshop by tie downs above this time. Other data later in the flight indi-
and below the meteoroid shield. Seals at- cated the SAS-1 wing did not fully deploy
tached to the solar array system perimeter when commanded to do so. Although not ap-
actually press against the shield to form an parently associated with the 63-second and
airtight cavity prior to launch. Once in orbit, 593-second anomalies, the S-II stage range
the solar array system beams are first de- safety receiver signal strengths showed sev-
ployed out 90 degrees. The meteoroid shield eral drops throughout the flight beginning at
is deployed later to a distance of about five about R + 260 seconds.
inches from the orbital workshop wall. After
the ordnance release is fired, meteoroid 63-SECOND ANOMALY: LOSS OF
shield deployment is effected by torsion rods METEROID SHIELD
and swing links spaced around the structure
fore and aft. The rods are torqued prior to The Investigation Board evaluated the te-
launch and simply unwind in orbit to move lemetry data in order to explain the various
the meteoroid shield away from the tank, anomalies that occurred on Skylab 1. The
Detection of pertinent conditions associated first anomalous indication was an increase
with the meteoroid shield and solar array in S-II telemetry reflected power from a
system is afforded by measuring various pa- steady 1.5 W beginning at R + 59.80 seconds.
rameters by telemetered instrumentation. At this time the telemetry forward power
When the orbital workshop solar array remained steady at 58.13W. By 61.04 sec-
system was commanded to deploy, telemeter- onds, the reflected power had reached
ed data indicated that events did not occur as 1.75 W, and by 80.38 seconds, the reflected
planned. The flight data was analyzed by power had stabilized at about 2.0 W. This
flight operations personnel to reveal the pos- abnormal increase in power might be in-
sible source of the problem. At about R + 60 dicative of a vehicle physical configuration
seconds, the S-II telemetry reflected power change which altered the antenna ground
increased slightly. At about 63 seconds, plane characteristic.
numerous measurements indicated the
185
Shortly after the telemetry reflected 593-SECOND ANOMALY

power increase, the meteoroid shield torsion
rod 7 forward (measurement G7036) indicat- As a consequence of the meteoroid shield
ed a slight change toward the deployed failure at approximately 63 seconds, the
condition. This occurred at R+60.12 sec- SAS-2 wing was unlatched and partially de-
onds, and at 61.78 seconds the vehicle roll ployed as evidenced by minor variations in
rate decreased slightly from a normal value the main solar array system electrical volt-
of 1.1 degrees per second clockwise looking ages and SAS-2 temperatures. Full deploy-
forward. The next torsion rod 7 forward ment was prevented due to the aerodynamic
sample at about 62.52 seconds revealed a forces and accelerations during the remain-
further relaxation. The increase in telemetry der of powered flight.
reflected power and the movement of torsion At the completion of the S-II phase of
rod 7 forward tend to indicate meteoroid flight, the four 35,000-pound thrust retro-
shield lifting between positions I and II. rockets fired for approximately two seconds
Between R+62.75 and 63.31 seconds, commencing at R+591.10 seconds followed
several vehicle dynamic measurements by spacecraft separation at 591.2 seconds.
indicated a significant disturbance. A sensor The effect of retro-rocket plume impinge-
on the orbital workshop film vault showed an ment was observed almost immediately on
abnormal vibration at 62.75 seconds fol- the SAS-2 temperature and on vehicle body
lowed by disturbances sensed by X and Y rates.
accelerometer pickups in the instrument At 593.4 seconds the wing imparted mo-
unit, the pitch, yaw, and longitudinal mentum to the vehicle, probably by hitting
accelerometers, and the pitch, yaw, and roll and breaking the 90 degree fully deployed
rate gyros. At 62.78 seconds, the roll rate stops, and at 593.9 imparted a final kick as it
gyro sensed a sudden clockwise roll rate re- tore completely free at the hinge link. In-
sulting in a peak amplitude of 3.0 degrees orbit photographs show clearly the hinge
per second clockwise 62.94 seconds. A sensor separation plane and the various wires
at the instrument unit upper mounting which were torn loose at the interface.
showed a maximum peak-to-peak shock of
17.2 g's at 63.17 seconds. In addition, the S-II INTERSTAGE SECOND PLANE
engine actuators experienced pressure fluc- SEPARATION ANOMALY
tuations caused by vehicle movement
against the inertia of the non-thrusting Post-flight analysis revealed unexpectedly
engine nozzles. high temperatures and pressures in the S-II
The data indicate that the most probable engine compartment following ignition and
sequence of meteoroid shield failure was continued high after interstage separation
initialstructural failure of the meteoroid command. The unusually high temperatures
shield between the SAS-2 wing and the main from S-II ignition and until the S-II inter-
tunnel (between positions I and II). The stage separation signal are considered by
initialfailure propagation from this area Marshall Space Flight Center (MSFC) to be
appears likely since the wardroom window caused by a change in the engine heat shield
thermocouple indication (C7013) remained skirts introduced on this flight, and there-
normal at 62.94 seconds after SAS-2 indicat- fore do not indicate a problem. However, the
ed unlatched at 62.90 seconds and after the increasing temperatures after the time of
K7010 and K7011 tension strap measure- normal S-II interstage separation are indica-
ments failed. tive of an abnormal condition. More detailed
186
SKYLAB I
investigation based on performance evalua- A review of the history of manufacturing,

tion and axial acceleration time history re- acceptance, checkout, qualification and
vealed that the interstage had not been flight environment revealed no basic cause
jettisoned; however, due to the vehicle perfor failure. The most probable cause is secon-
formance characteristics and performance dary damage as a result of the meteoroid
margin, the desired orbit was achieved. shield failure, attributed to falling debris as
Data analysis confirms that the primary evidenced by the various shock and acoustic
ordnance command was properly issued at disturbances occurring in the 63-second time
R + 189.9 seconds. The backup command was period.
issued 100 milliseconds later but the explod- The redundant mode of ordnance opera-
ing bridge wire circuit discharge was charac- tion of all prior Saturn flights in which both
teristic of an open circuit consistent with ends of the linear shaped charge are fired at
separation of the interstage disconnect by a once from a single command would probably
minimum of 0.25 inch. have prevented the failure, depending on the
The linear shaped charge is mounted cir- extent of damage experienced by the linear
cumferentially around the S-II interstage. shaped charge.
When fired by the primary command, the
charge cuts the tension straps (in the direc- FORWARD INTERSTAGE INTERNAL
tion of position II to position I) allowing the PRESSURE ANOMALY
skirt to drop away. Normal propagation time
of the linear shaped charge is approximately Flight data indicated a deviation of the S-II
four milliseconds. Assuming a failure to forward interstage pressure from analytical
propagate completely around the structure, values commencing at approximately 63 sec-
analyses were made by appropriate contrac- onds. Inasmuch as the deviation from the
tor and government personnel to determine analytical curve of the internal pressure ver-
what area must remain intact in order to re- sus time appeared to be coincident with the
tain the skirt and what area must have been meteoroid shield failure, it was postulated
cut to allow rotation of the skirt sufficient to that a portion of the shield had punctured
disconnect the connector panel. The various the forward interstage. On this basis, it was
analyses isolate the region of failure to an possible to correlate the flight data with ei-
arc extending from approximately _ = 100 ther an assumed 2.0 square foot hole in the
degrees to as much as O = 200 degrees. conical section or an assumed 0.75 square
This ordnance installation was different foot hole in the cylindrical section.
from prior Saturn flights. Previously, a sin-
gle fire command from the instrumentation RANGE SAFETY RECEIVER ANOMALY
unit was issued which simultaneously deto-
nated the linear shaped charge from both During the S-II portion of the flight, the sig-
ends allowing the charge to propagate from nal strength indications from both range
both directions. On this flight, in an attempt safety receivers showed drops in level. From
to provide redundant firing commands, the liftoff through R+259 seconds, both receiv-
detonators at each end of the linear shaped ers maintained relatively stable values
charge were separately connected to two above range requirements. At R+259.57
command channels spaced 100 milliseconds seconds, receiver 2 signal strength began to
apart due to the characteristics of the air- drop and between this time and 522.1 sec-
borne equipment. As a result of the partial onds, both receivers indicated various de-
cutting of the interstage, it rotated suffi- grees of signal strength shift. These signal
ciently to separate the electrical connector strength shifts dropped below the 12 db safe-
prior to issuing the backup command. ty margins required by Air Force Eastern
I87
Test Range Manual 127-1. At R÷327.81 sec- deploy it in orbit, and provide access to the
onds the receiver 2 signal strength dropped orbital workshop interior during prelaunch
briefly below its threshold sensitivity. At activities. The principal means of holding
this instant this receiver probably would not the shield in place in orbit (and to a lesser
have responded to any range safety com- extent during powered flight) was a set of
mands. Receiver 1 was, however, capable of tension straps under the main tunnel. These
receiving commands. At R + 521.16, receiv- straps were bonded to the orbital workshop
er 2 strength again dropped briefly to its wall and fitted with a hinge on each end to
threshold sensitivity. None of these drops take the butterfly hinge that attaches to the
could be correlated to ground system perfor- adjacent meteoroid shield panel. These
mance. butterfly hinges were designed to rotate so
Analysis indicates that the most probable as to lie against the sides of the main tunnel
cause of the S-II receiver signal strength which enclosed the tension straps and var-
dropout was a variable phase shift within ious cable runs on the orbital workshop.
the vehicle's hybrid coupler due to the chang- Clockwise from the tension straps and
ing aspect angle produced by the moving butterfly hinge, the next special feature is
vehicle and the fixed transmitting site. Be- the auxiliary tunnel. This tunnel extends in
cause the decrease in receiver signal an arch between panels of the thin meteoroid
strength occurred with only one receiver at a shield. The 28 titanium frames of this tunnel
time, range safety commands could have provide a very springy section in the rela-
been received continuously throughout pow- tively rigid hoop provided by the rest of the
er flight. During two of these drops, however, shield. The auxiliary tunnel also encloses a
the planned redundancy of range safety re- smaller tunnel covering the wiring for the
ceivers was not available. thruster attitude control system. Farther
During this investigation, it was revealed around, in position I, there are two curved
that the Wallops Island and Bermuda rectangular smaller panels, included to pro-
ground stations did not continuously record vide access to the orbital workshop.
ground transmitter power levels. The Board Between positions I and IV, the two
considers that such continuous recordings halves of the meteoroid shield overlap and
would be of value. are joined by a series of 14 trunnion bolts and
straps. These trunnion bolts were used to ad-
THE METEOROID SHIELD DESIGN just the tension with which the shield was
held against the orbital workshop. Adjusting
Although fairly simple in concept, the mete- the bolts in the trunnion assemblies was a
oroid shield had to provide such a variety of major aspect in positioning and tightening
functions that it was, in fact, a quite compli- the meteoroid shield against the orbital
cated device. It was, foremost, a very lightly workshop (rigging).
built cylindrical structure 270 inches in di- In order to provide the extra 30 inches of
ameter (in the deployed condition) by 265 perimeter required when the meteoroid
inches long. shield was deployed, a foldout panel assem-
In brief, the meteoroid shield is formed of bly is included in the panel adjacent to the
a set of sixteen curved sheets of 2014 T6 alu- trunnions. The only remaining distinctive
minum panels, 0.025 inches thick, assem- features of the meteoroid shield are the
bled at flanges and other fittings to form the panels located over the scientific airlock and
cylinder shown. The forward and aft ends wardroom window at position HI. The mete-
were reinforced with curved 7075 T6 angles. oroid shield is completed at the butterfly
Various special details were included in hinges and tension straps at position I.
the assembly in order to hold it in place,
188
SKYLAB 1
Deployment Provisions inches circumferentially upon deployment of

the shield.
The deployment of the 265-inch-long meteor- The main structural members of the aux-
oid shield was accomplished by providing iliary tunnel are titanium, arch-shaped,
two folding panel sections on each side of a frame springs. These frames provide the
contained explosive pyrotechnic chain which structural tie between two meteoroid shield
extended axially for the full length of the panels and provide both regulation of the
shield except for short end reinforcements. pre-loading of the meteoroid shield to the
When the ordnance strip is fired and sepa- orbital workshop and act as a flexible relief
rates the fold-over panel, the segments are for diametrical changes resulting from ther-
released and the shield is deployed. After re- mal and pressure changes of the orbital
lease of this folded panel, a number of swing workshop.
arms are used to displace the shield away The tunnel also serves to protect the
from the orbital workshop wall and hold it thrust attitude control system cables located
there. A rotational force is applied to these in a small channel-shaped cover permanent-
swing arms by a total of sixteen torsion rods ly attached to the orbital workshop. A seg-
suitably spaced around the ends of the mete- mented and corrugated outer skin form an
oroid shield. When the meteoroid shield is aerodynamic fairing for the complete system
stowed for launch, there is a larger twist in and seals between forward and aft fairings.
the torsion rods than after deployment. The
links on one side of the ordnance chain swing Thermal Control
in a direction opposite to those on the other
side. The butterfly hinges on each side of the Although the primary purpose of the meteor-
main tunnel permit the radial displacement oid shield is that of providing protection of
of the shield at the location of the tension the orbital workshop from meteoroids, it also
straps. plays a significant role in the thermal con-
The meteoroid shield should therefore be trol system. Much of the overall thermal de-
regarded as a very limp system, which design was accomplished passively by painting
pends on being stretched tight around the the outer surfaces of the meteoroid shield
orbital workshop to withstand the aerody- black except for a large white cross-shaped
namic, vibratory, flutter and thrust loads at pattern on the Earth side during flight. The
launch. After deployment, it needs very little entire surface of the orbital workshop wall
strength to serve its primary objective as a was covered with gold foil. The overall choice
meteoroid shield. of finishes biased the thermal design toward
the cold side, it being easier to vernier con-
The Auxiliary Tunnel trol by heating rather than cooling.
The auxiliary tunnel extends from the for- Friction between the Meteoroid Shield
ward skirt, down the full length of the mete- and Orbital Workshop Wall
oroid shield shield, and below the meteoroid
shield by about 57 inches. Venting of this To provide a uniform tension throughout the
tunnel was provided through an outlet of 10 meteoroid shield upon assembly and rigging
square inches under the corrugations of the for flight, and to permit transfer of the trun-
tunnel cover at the aft end of the forward nion bolt tension into the frames of the auxil-
fairing. The tunnel was intended to be sealed iary tunnel, it was necessary to minimize
at the aft end by a rubber boot assembly in friction between the shield and the external
both the stowed and deployed position. Note surface of the orbital workshop. This was
that the tunnel is displaced some 5 or 6 accomplished by applying a Teflon coating to
189
READINGS 1N SYSTEMS ENGINEERING
the entire inner surface of the meteoroid num stock fitted with doublers and angles to
shield assembly. Special care was also taken permit their assembly. In each of these panel
to assure that all fastening rivets be either joints, 96 holes of 1/8-inch diameter were
flush with or below the Teflon surface of the drilled to vent any air trapped under the me-
shield. In addition to considerations of teoroid shield skin. The special panel joint is
friction, the elimination of rivet head required next to the SAS-1 wing because of
protrusions was important in not damaging the unavailability of sufficiently wide panel
the rather delicate gold surface used to pro- stock for the panel under SAS-1. It was a
vide the proper emissivity of the outer orbit- strap of metal of this special joint that be-
al workshop wall surfaces as mentioned came embedded in the SAS-1 cover and pre-
above. This was a vapor-deposited gold sur- vented automatic deployment of SAS-1 in or-
face applied to a Kapton backing and bonded bit. It is, perhaps, of passing interest to note
to the outer workshop wall with an adhesive. the longer length of exposed bolts in this par-
ticular joint.
Panel Details Around the top of the panels is located an
angle and a neoprene rubber rain or weather
The sixteen panels comprising the meteoroid seal. This seal was not intended to be an
shield were formed of 0.025 inch thick alumi- aerodynamic seal and could not be expected
Forward
Fairing
_ Shocks
Forward from
Fairing
Meteoroid
Auxiliary Shield
Tunnel
Figure 3 Compressibility waves from the forward auxiliary tunnel fairing
190
SKYLAB 1
to accommodate significant relative deflec- One solution is, of course, to simply omit the
tions between the orbital workshop and me- meteoroid shield, suitably coat the orbital
teoroid shield surfaces. To provide meteoroid workshop for thermal control and accept the
protection at the two ends of the meteoroid meteoroid protection afforded by the orbital
shield, small strips of thin stainless steel workshop tank walls. Although the Board
"fingers" were squeezed down between the has not conducted an analysis, meteoroid
orbital workshop and the meteoroid shield flux levels are now known to be considerably
when stowed. The thrust load of the shield, lower than those used in the original calcula-
which weighs some 1200 pounds, is trans- tions. A new analysis, based on these flux
ferred to the forward flange of the aft skirt levels, may show acceptable protection.
through a group of twelve thrust blocks. Should some additional meteoroid protec-
tion be required, the Board is attracted to the
SUMMARY AND RECOMMENDATIONS concept of a fixed, nondeployable shield.
Although the inherent weight advantages of
The preceding analysis and discussion of pos- a separable bumper are not available in this
sible failure modes of the meteoroid shield approach, the mission of Skylab could prob-
have identified at least two ways that it ably be satisfied in this manner. One concept
could fail in flight. Although the most prob- would be to bond an additional layer of metal
able cause of the present failure was the lift- skin to the surface of the tank with a layer of
ing of the shield from the orbital workshop nonventing foam between the orbital work-
tank by excessive pressures in the auxiliary shop tank and the external skin. The prob-
tunnel, other failure modes could have oc- lem being statistical in nature, the entire
curred in other regions of flight or under shell of the orbital workshop would not have
more severe flight environments that were to be covered.
encountered by Skylab 1.
Among these other modes of potential POSTULATED SEQUENCE OF THE MOST
failure, which could combine in various ways PROBABLE FAILURE MODE
under varying conditions of flight, are exces-
sive pressures under the forward edge of the The availability of flight data from the in-
shield, or inadequate venting of the folded strumentation on the meteoroid shield and
ordnance panel. The inherently light spring the vehicle disturbances, the design features
force of the auxiliary tunnel frames, the of the meteoroid shield, the solar array sys-
crushing loads on these frames in flight, the tem photographs taken in orbit, descriptions
inherent longitudinal flexibility of the shield by the astronauts, and other information
assembly, the forces applied by the swing permit the following postulation of the prob-
links to deploy the shield, the possible able sequence of events associated with the
breathing of the shield panels as cavities are meteoroid shield failure.
vented, the noncylindrical nature of the un- In Figure 4, sketches and details of sa-
derlying pressurized tank, and the uncertain lient events are correlated to the roll rate
tension loads applied to the shield in rigging data around the 63 second anomaly period.
for flight all contribute to a lack of rigidity of The events are designated on the figures by
the shield and a weakness of its structural times which are consistent with the avail-
integrity with the underlying tank struc- able data.
ture.
A simple and straightforward solution to 60.12 Seconds - Meteoroid shield liftoff
these inherent problems of the present shield and local inflation in the vicinity of the aux-
design is therefore not likely. A fundamen- iliary tunnel was indicated by a small shift
tally different design concept seems in order.
191
in position of the torsion rod on the forward upon the conical adapter between the orbital
edge just to the left of the tunnel. workshop and the SAS-1 stage.
61.78 Seconds - Air entered the forward 63. 7 Seconds - The meteoroid shield con-
fairing opening, raised the pressure under tinued to unwind and whip until 63.7 sec-
the shield and high mass flows escaped onds when it reached SAS-1 wing. As the me-
through the adjacent holes in the butterfly teoroid shield began to wrap around the
hinge. This flow produced reactive force SAS-1 wing, a negative roll torque resulted.
causing a gradual decrease in roll rate be- The meteoroid shield then ripped apart from
tween 61.78 seconds and 62.74 seconds. top to bottom at the longitudinal joint adja-
62. 74 to 62. 79 Seconds - Burst pressure cent to SAS-1, pulling a portion of the joint
under the auxiliary tunnel and adjacent me- assembly over the SAS-1 wing as the meteor-
teoroid shield caused a large tangential load oid shield section departed. From this point
on the forward section of the butterfly hinge, on the vehicle showed normal response to its
causing the whole hinge to unzip. Fly around roll control system.
inspection indicated that the failure of the
butterfly hinge occurred at the hinge line ad- POSSIBLE IMPACT OF COSTS AND
jacent to the main tunnel. SCHEDULES ON THE METEOROID SHIELD
The butterfly hinge was now completely
broken. Aerodynamic drag on the meteoroid The origin of Skylab in late 1966--as an ex-
shield including the bulky auxiliary tunnel tension of the use of Apollo hardware for ex-
produced tension in the shield and pulled on periments in Earth orbit---imposed an initial
the vehicle so as to roll it in the direction environment of limited funding and strong
shown, that is, opposite to that noted earlier. schedule pressures on the program. Skylab,
The large area and mass of this metal flag then designated the Apollo Applications Pro-
induced a more rapid change in roll rate than gram (AAP), was to fit in among the Apollo
the earlier jetting through the butterfly flights under schedules imposed by the main-
hinge. This process terminated as the mete- line Apollo program. Funding was provided
oroid shield started to wrap around and lift out of the Apollo program and thus the needs
the SAS-2 wing. of Skylab competed with those of the higher
62.79 to 62.90 Seconds - During this in- priority Apollo program.
terval the shield was wrapping around the The situation changed in mid-1969 when
SAS-2 wing producing a negative roll torque Skylab became a major line item in its own
in the vehicle. At about 62.85 seconds the right and was to use a Saturn-V launch vehi-
SAS-2 tie-downs were broken. cle with a dedicated, dry, orbital workshop.
62.90 Seconds - Upon release of the From that point on, increased funding and
SAS-2, the tension in the shield was trans- new flight schedules were established for
ferred to the trunnions, causing failure of the Skylab. Nonetheless, the original concept of
trunnion straps. Upon separation of this sec- the meteoroid shield was retained when the
tion of the shield, the negative roll torque orbital workshop changed from Saturn-IB
ended. propulsion stage to a dry workshop launched
62.90 to 62.95 Seconds - In this interval, by a Saturn-V. The Board was therefore
the remaining section of the meteoroid shield interested in determining the extent, if any,
began unwinding, introducing a large posi- that either the initial limitation of funds and
tive roll torque. time, or any subsequent limitations, deter-
63.17 Seconds - A large shock was detect- mined the design or thoroughness of develop-
ed by the instrument unit upper mounting ment of the meteoroid shield. This inquiry
ring vibration sensor due to the impact of the was limited to the possible effect of funding
separated section of the meteoroid shield and schedule of the meteoroid shield as
192
SKYLAB 1
designed and flown on Skylab 1 and did not na] assembly for flight,particular attention
consider whether meteoroid protection could was devoted to any impacts arising from
have or should have been provided in some limitation of funds or time. Extensive discus-
other way had the program not evolved as it sions were also held with management per-
did. sonnel of MDAC-W, MSFC, JSC, and NASA
In the Board's review of the evolution of Headquarters on this matter. In no instance
the meteoroid shield from initial design con- could the Board find any evidence that the
cept, through testing and development, to fi- design or testing of the meteoroid shield was
POS HI
I"sAsl \1
SAS-2 SAS-2--_]
D J
/
] Situationat62.79 _ i Situationat62.85 at62.90
SAS-2
SAS-2
SAS- 1
I
I Situation at 63.4 Situationat63.70
i
Figure 4 -- Postulated Sequence Failure Mode
193
compromised by lack of funds or time. Pro- Item as being offered for delivery is in confor-
gram personnel, both government and mance with the baseline established at the
contractor, had full confidence in the basic CDR."
concept of the meteoroid shield and thus saw Certification of Flight Worthiness
no need to alter the design when the change (COFW). "To certify that each flight stage
to a dry, Saturn-V launched orbital work- module and experiment is a complete and
shop occurred. Given the concept that the qualified item of hardware prior to ship-
shield was to be maintained tight to the or- ment."
bital workshop tank, and thus structurally Design Certification Review (DCR). "To
integrated with the well-established S-IVB examine the design of the total mission com-
structure, the emphasis of testing given to plex for proof of design and development ma-
ordnance reliability and shield deployment turity."
was considered proper. Neither the records of Flight Readiness Review (FRR). "A con-
Skylab nor the memories of key personnel solidated review of the hardware, operation-
revealed any tests or analyses of the meteor- al and support elements to assess their
oid shield that were considered desirable at readiness to begin the mission."
the time and which were precluded by lack of
funds or time. The primary thrust of these key program
milestones is thus a formal review and certi-
THE SKYLAB MANAGEMENT SYSTEM fication of equipment design or program sta-
tus; the primary purpose being served is to
The management system utilized for the provide visibility into these matters to senior
Skylab program was derived directly from NASA and contractor program manage-
that which had been developed and used in ment. As noted in the Skylab Program Direc-
the Apollo program. As such, it included a tive, the organization and conduct of the
series of formal reviews and certifications at review is a major responsibility of a senior
progressive points in the program life cycle program or management official. For each
that are intended to provide visibility to con- review, specific objectives are to be satisfied,
tractor and NASA management on program in conformance with preestablished criteria
status, problems and their resolution. The and supported by specified documentation.
selected review points and their primary The reviews are thus highly structured and
purpose are set forth in Skylab Program formal in nature, with a major emphasis on
Directive No. l lA, which is summarized as design details, status of various items and
follows: thoroughness of documentation. Several
Preliminary Requirements Review (PRR). hundred specialists, subsystem engineers
"To verify by formal review the suitability of and schedule managers are generally in at-
the conceptual configuration and to establish tendance.
the requirements and action necessary to The material presented in these reviews
achieve a design baseline." is, of course, developed over a period of time
Preliminary Design Review (PDR). "To in many lower-level reviews and in monthly
verify by formal review the suitability of the progress reports dealing with various sys-
baseline design of the Contract End Item." tems and subsystems. In addition, several
Critical Design Review (CDR). "To verify other major reviews peculiar to Skylab were
by formal review the suitability of the design conducted, including the following:
of a Contract End Item when the design is es-
sentially complete." Cluster System Review of December 1967
Configuration Inspection (CI). "To certify Mathew's Subsystem Review Team of
that the configuration for the Contract End August 1970-July 1971
194
SKYLAB 1
• Critical Mechanisms Review of March tention and understanding during the design
1971 and review process which in retrospect it de-
• Systems Operations Compatibility served.
AssessmentReview of October 1971-June This omission, serious as it was, is not
1972 surprising. From the beginning, a basic de-
• Structural/Mechanical Subsystem sign concept and requirement was that the
Reviews of July 1971-May 1972 shield be tight to the tank. As clearly stated
• Hardware Integrity Review of March in much of the early documentation, the me-
1973 teoroid shield was to be structurally integral
• MSFC Center Director's Program with the S-IVB tank--a piece of structure
Reviews that was well proven in many previous
flights. The auxiliary tunnel frames, the con-
There was thus no shortage of reviews. In trolled torque on the trunnion bolts and the
order to determine the consideration given to rigging procedure itself were all specifically
the meteoroid shield throughout the pro- intended to keep the shield tight against the
gram, the Board examined the minutes, pre- tank. The question of whether the shield
sentation material, action items, and would stay there under the dynamics of
closeout of data of each of these reviews and flight through the atmosphere was simply
progress reports. In every case, complete not considered in any coordinated manner--
records and documentation were available at least insofar as the Board could determine
for inspection. In no case did the Board un- by this concentrated investigation.
cover any conflict or inconsistency in the Possibly contributing to this oversight
record. All reviews appeared to be in com- was the basic view of the meteoroid shield as
plete conformance to Program Directive llA a piece of structure. Organizationally, re-
and were attended by personnel appropriate sponsibility for the meteoroid shield at
to th_ subject matter under consideration. MDAC-W was established to develop it as
The system was fully operational. one of the several structural subsystems,
And yet, a major omission occurred along with such items as spacecraft struc-
throughout this process--consideration of ture and penetrations, pressure vessels, sci-
aerodynamic loads on the meteoroid shield entific airlocks, protective covers and fin-
during the launch phase of the mission. ishes. Neither the government, (MSFC), or
Throughout this six year period of progres- the contractor, (MDAC-W), had a full-time
sive reviews and certifications the principal subsystem engineer assigned to the meteor-
attention devoted to the meteoroid shield oid shield. While it is recognized that one
was that of achieving a satisfactory deploy- cannot have a full-time engineer on every
ment in orbit and containment of the ord- piece of equipment, it is nonetheless possible
nance used to initiate the deployment. As that the complex interactions and integra-
noted in the preceding section on possible tion of aerodynamics, structure, rigging
failure modes,design attention was also giv- procedures, ordnance, deployment mecha-
en to the strength of the hinges, trunnion nisms, and thermal requirements of the me-
straps and bolts, to the crushing pressures on teoroid shield would have been enhanced by
the frames of the auxiliary tunnel, to flutter such an arrangement. Clearly, a serious fail-
and to the venting of both the auxiliary ure of communications among aerodynamics,
tunnel and the several panels of the shield. structures, manufacturing and assembly
But never did the matter of aerodynamic personnel, and a breakdown of a systems
loads on the shield or aeroelastic interactions engineering approach to the shield, existed
between the shield and its external pressure over a considerable period of time. Further,
environment during launch receive the at- the extensive management review and
195
certification process itself, in its primary ment system, can, in itself, serve to separate
purpose of providing visibility of program the people engaged in the program from the
status to management, did not identify these real world of hardware. To counteract these
faults. potential hazards and flaws, we offer the fol-
Further insight into this treatment of the lowing suggestions.
meteoroid shield as one of several structural
subsystems is obtained by a comparison of a Deployable systems or structures that
listing of the design reviews conducted on have to move, or that involve other
both the meteoroid shield and the solar array mechanisms, devices, or components in
system. At MDAC-W, the solar array system their operation, should not be considered
was considered a major subsystem and was as a piece of structure or be the basic re-
placed under the direction of a full-time pro- sponsibility of a structures organization.
ject engineer. A complex, multi-disciplinary system
The Board is impressed with the thor- such as the meteoroid shield should possi-
oughness, rigor and formalism of the man- bly have a designated project engineer
agement review system developed by Apollo who is responsible for overseeing all as-
and used by Skylab. Great discipline is im- pects of analysis, design, fabrication, test
posed upon everyone by this system and it and assembly.
has served very well. In a large program as Management must always strive to coun-
geographically dispersed and intrinsically teract the natural tendency of engineers
complex as Skylab, such visibility of pro- to believe that a drawing is the real
gram status and problems is a management world. First-hand experience with how
necessity. We therefore have no wish to alter hardware behaves and can fail is of the
this management system in any basic man- essence to design engineers. Possibly,
ner. But all systems created by humans have some design engineers should be required
their potential flaws and inherent hazards. to spend time in testing, operations, or
Such inherent flaws and weaknesses must be failure analysis. Such experience may not
understood by those who operate the system contribute to cleverness or sophistication
if it is not to become their master. We thereof analysis, but something equally
fore wish to identify some of those potential valuable--actual experiencemmay be ad-
flaws as they have occurred to us in this in- ded to the design group. An unfamiliarity
vestigation, not to find fault or to identify a with hardware, first hand, makes it diffi-
specific cause of this particular flight failure cult to conceptualize a living, breathing,
but to use this experience to further piece of hardware from an analysis or a
strengthen the management processes of drawing.
large and complex endeavors. The. extensive use of the computer for
As previously noted, the management complex analyses can serve to remove the
system developed by NASA for manned analyst from the real world. One should,
space flight places large emphasis on rigor, therefore, require a simplified or support-
detail and thoroughness. In hand with this ing analysis that provides an understand-
emphasis comes formalism, extensive docu- able rationale for the phenomena under
mentation, and visibility in detail to senior consideration before accepting the results
management. While nearly perfect, such a of a computer analysis.
system can submerge the concerned individ- The emphasis on "visibility to manage-
ual and depress the role of the intuitive engi- ment" in the review process should not be
neer or analyst. It may not allow full play for extended to the point that one can be led
the intuitive judgment or past experience of to believe the job is completed, or the de-
the individual. An emphasis on a manage- sign is satisfactory, when such visibility
196
SKYLAB 1
is provided. A major emphasis on status, boot seal between the tunnel and tank
on design details, or on documentation surface; and (3) open stringers on the aft
can detract from a productive examina- skirt under the tunnel.
tion of "how does it work" or "what do you 6) The venting analysis for the tunnel was
think." predicated on a completely sealed aft
Today's organizations seldom include the end. The openings in the aft end of the
old-fashioned chief engineer who, rela- tunnel thus resulted from a failure to
tively devoid of administrative or man- communicate this critical design feature
agerial duties, brings total experience among aerodynamics, structural design,
and spends most of the time in the subtle and manufacturing personnel.
integration of all elements of the system 7) Other marginal aspects of the design of
under purview. Perhaps we should more the meteoroid shield which, when taken
actively seek and utilize these talented together, could also result in failure dur-
individuals in an engineering organiza- ing launch are:
tion. a) The proximity of the meteoroid
shield forward reinforcing angle to
SIGNIFICANT FINDINGS the air stream
b) The existence of gaps between the or-
1) The launch anomaly that occurred at ap- bital workshop and the forward ends
proximately 63 seconds after lift-off was of the meteoroid shield
a failure of the meteoroid shield of the c) The light spring force of the auxil-
orbital workshop. iary tunnel frames
2) The SAS-2 wing tie downs were broken d) The aerodynamic crushing loads on
by the action of the meteoroid shield at the auxiliary tunnel frames in flight
63 seconds. Subsequent loss of the SAS-2 e) The action of the torsion-bar actu-
wing was caused by retro-rocket plume ated swing links applying an out-
impingement on the partially deployed ward radial force to the meteoroid
wing at 593 seconds. shield
3) The failure of the S-IIinterstage adapter f) The inherent longitudinal flexibility
to separate in flight was probably due to of the shield assembly
damage to the ordnance separation de- g) The nonuniform expansion of the
vice by falling debris from the meteoroid orbital workshop tank when pressur-
shield. ized
4) The most probable cause of the failure of h) The inherent difficulty in rigging for
the meteoroid shield was internal pres- flight and associated uncertain ten-
surization of its auxiliary tunnel. This sion loads in the shield.
internal pressurization acted to force the 8) The failure to recognize many of these
forward end of the tunnel and meteoroid marginal design features through six
shield away from the orbital workshop years of analysis, design and test was
and into the supersonic air stream. The due, in part, to a presumption that the
resulting forces tore the meteoroid meteoroid shield would be "tight to the
shield from the orbital workshop. tank" and "structurally integral with
5) The pressurization of the auxiliary tun- the S-IVB tank" as set forth in the
nel resulted from the admission of high design criteria.
pressure air into the tunnel through 9) Organizationally, the meteoroid shield
several openings in the aft end. These was treated as a structural subsystem.
openings were: (1) an imperfect fit of the The absence of a designated project engi-
tunnel with the aft fairing; (2) an open neer for the shield contributed to the
197
lack of effective integration of the future, a possible course of action is to

various structural, aerodynamic, aeroe- omit the meteoroid shield, suitably coat
lastic, test fabrication, and assembly the orbital workshop for thermal con-
aspects of the meteoroid shield system. trol, and accept the meteoroid protection
10) The overall management system used afforded by the orbital workshop tank
for Skylab was essentially the same as walls. If, on the other hand, additional
that developed in the Apollo program. protection should be necessary, the
This system was fully operational for Board is attracted to the concept of a
Skylab; no conflicts or inconsistencies fixed, nondeployable shield.
were found in the records of the manage- 2) To reduce the probability of separation
ment reviews. Nonetheless, the signifi- failures such as occurred at the S-II in-
carce of the aerodynamic loads on the terstage Second Separation Plane, both
meteoroid shield during launch was not linear shaped charges should be detonat-
revealed by the extensive review pro- ed simultaneously from both ends. In
cess. addition, all other similar ordnance
11) No evidence was found to indicate that applications should be reviewed for a
the design, development and testing of similar failure mode.
the meteoroid shield were compromised 3) "Structural" systems that have to move
by limitations of funds or time. The or deploy, or that involve other mecha-
quality of workmanship applied to the nisms, equipment or components for
meteoroid shield was adequate for its their operation, should not be the exclu-
intended purpose. sive responsibility of a structures orga-
12) Given the basic view that the meteoroid nization.
shield was to be completely in contact 4) Complex, multi-disciplinary systems
with and perform as structurally inte- such as the meteoroid shield should have
gral with the S-IVB tank, the testing a designated project engineer who is
emphasis on ordnance performance and responsible for all aspects of analysis,
shield deployment was appropriate. design, fabrication, test and assembly.
13) Engineering and management person-
nel on Skylab, on the part of both con- OBSERVATIONS ON THE
tractor and government, were available MANAGEMENT SYSTEM
from the prior Saturn development and

were highly experienced and adequate The Board found no evidence that the design
in number. deficiencies of the meteoroid shield were the
14) The failure to recognize these design result of, or were masked by, the content and
deficiencies of the meteoroid shield, as processes of the management system that
well as to communicate within the pro- were used for Skylab. On the contrary, the
ject the critical nature of its proper vent- rigor, detail, and thoroughness of the system
ing, must therefore be attributed to an are doubtless necessary for a program of this
absence of sound engineering judgment magnitude. At the same time, as a caution-
and alert engineering leadership con- ary note for the future, it is emphasized that
cerning this particular system over a management must always be alert to the po-
considerable period of time. tential hazards of its systems and take care
that an attention to rigor, detail and thor-
CORRECTIVE ACTIONS oughness does not inject an undue emphasis
on formalism, documentation, and visibility
1) If the backup orbital workshop or a simi- in detail. Such an emphasis can submerge
lar spacecraft is to be flown in the the concerned individual and depress the
198
SKYLAB I
role of the intuitive engineer or analyst. It sults, and make productive use of flight data
will always be of importance to achieve a in this learning process. The experienced
cross-fertilization and broadened experience chief engineer, whose time can be spent in
of engineers in analysis, design, test or oper- the subtle integration of all elements of the
ations. Positive steps must always be taken system under review, free of administrative
to assure that engineers become familiar and managerial duties, can also be a major
with actual hardware, develop an intuitive asset to an engineering organization.
understanding of computer-developed re-
199
THE SEASAT FAILURE
N9 3-
REPORT OF THE SEASAT FAILURE REVIEW BOARD
by the NASA Investigation Board _.

The Seasat spacecraft failed on October 9, lying program policy and a pervasive view
1978, after satisfactory operation in orbit for that Seasat's Agena bus was a standard,
105 days, as a result of a loss of electrical well-proven piece of equipment that had
power in the Agena bus that was used as a been used on other programs. In actuality,
part of the spacecraft. The loss of power was however, three major subsystems--the elec-
caused by a massive and progressive short in trical power subsystem, the attitude control
one of the slip ring assemblies that was used subsystem, and the data subsystem--were
to connect the rotating solar arrays into the substantially modified for use on Seasat's
power subsystem. The most likely cause of Agena bus. So firmly rooted was this princi-
this short was the initiation of an arc be- ple of using a "standard Agena bus" that,
tween adjacent slip ring brush assemblies. even after the engineering staffs of both the
The triggering mechanism of this arc could government and the contractor were well
have been either a wire-to-brush assembly aware of the final uniqueness of their bus,
contact, a brush-to-brush contact, or a mo- the words, and the associated way of doing
mentary short caused by a contaminant that business, persisted to the end.
bridged internal components of opposite elec- The point of view that the Seasat bus was
trical polarity. flight proven, standard equipment proved to
The slip ring assembly, as used in the have far-reaching consequences. It became
Seasat spacecraft, was connected into the program policy to minimize testing and docu-
power subsystem in such a way that most of mentation, to qualify components by similar-
the adjacent brush assemblies were of oppo- ity wherever possible, and to minimize the
site electrical polarity. This wiring arrange- penetration into the Agena bus by the gov-
ment, together with the congested nature of ernment. It led to a concentration by project
the design itself, made the Seasat slip ring management of the sensors, sensor integra-
assembly a unique, first-of-a-kind component tion, and the data management system to the
that was particularly prone to shorting. near exclusion of the bus subsystems. Impor-
The possibility of slip ring failures result- tant component failures were not reported to
ing from placing opposite electrical polarities project management, a test was waived with-
on adjacent brush assemblies was known at out proper approval, and compliance with
least as early as the summer of 1977 to other specifications was weak. The component that
projects within the contractor's organization. failed--the slip ring assembly--was never
Furthermore, failures of slip ring assemblies mentioned in the briefing charts for either
due to shorting between brushes had been the Consent to Ship meeting or the Critical
experienced by the prime contractor on the Design Review.
slip ring assemblies used by other programsl The Failure Modes, Effects and Critical-
That the Seasat organization was not fully ity Analysis that was conducted for the elec-
aware of these potential failure modes was trical power subsystem did not consider
due to a breakdown in communication within shorts as a failure mode and thus did not re-
the contractor's organization. veal the presence of single point failure
In addition to this small, though fatal, modes in the system or provide a basis for the
breakdown in communications, the failure to development of a full complement of sating
give the slip ring assembly the attention it command sequences that could be used by
deserved was due, in large part, to an under- the flight controllers in responding to
201
PRESEDIHG PAGE BLANK NOT FILMED
anomalies in the power subsystem. A lack of Seasat-A scatterometer system (SASS), a

clarity and rigor in the operating require- scanning multichannel microwave radiome-
ments and constraints documents for the ter (SMMR), and a visual and infrared radi-
power subsystem of the bus, together with ometer (VIRR). All of these sensors except
this lack of sating command sequences, pre- the SAR operated continuously; telemetry
vented the flight controllers from having all from them, as well as from all engineering
the tools they needed to do their job. The subsystems, was sent in real-time when over
flight controller for the power subsystem was a ground station and recorded on a tape re-
also new to his job at the time of the failure corder for later transmission to provide data
and thus was not sufficiently knowledgeable for a full orbit. SAR data had to be transmit-
of the system he was controlling. While no ted in real-time, without the use of the on-
action of the flight controllers contributed to board recorder, to specially equipped stations
the failure, they did fail to follow the pre- because of its high data rate. The normal
scribed procedures in response to the infor- duty cycle for the SAR was four percent.
mation available to them at the time of the The five sensors were integrated into a
failure. sensor module that provided mounting, ther-
The advantages of using standard, well mal control, power conditioning, telemetry,
proven equipment in terms of both cost and and command support to the instruments.
mission success are well recognized. But the The second major element of the spacecraft
experience of Seasat illustrates the risks that was an Agena bus which provided attitude
are associated with the use of equipment that control, electrical power, telemetry and com-
is classified as "standard" or "flight proven." mand functions to the sensor module. In ad-
The uncritical acceptance of such classifica- dition to these on-orbit functions, the Agena
tions by the Seasat engineering staff sub- bus also provided injection stage propulsion
merged important differences in both design and guidance to orbit. The spacecraft was
and application from previously used equip- three-axis stabilized with all sensors Earth
ment. It is therefore important that thorough pointing and is shown in its on-orbit configu-
planning be conducted at the start of a ration in Figure 1. To provide near global
project to fully evaluate the heritage of pre- coverage, the spacecraft was injected into a
viously used equipment and to establish 790 kilometer, near circular orbit with an
project plans and procedures that enable the inclination of 108 degrees and a period of ap-
system to be selectively penetrated. proximately 101 minutes. Design lifetime
was one year on orbit, with expendables pro-
THE SEASAT MISSION AND ITS vided for a three-year life.
SPACECRAFT The sensors were provided by various
NASA Centers. The sensor module, the Age-
The Seasat Project was a proof-of-concept na bus and the integration of the sensors,
mission whose objectives included demon- sensor module and Agena bus into a space-
stration of techniques for global monitoring craft was provided by the Lockheed Missles
of oceanographic and surface meteorological and Space Company under contract to the Jet
phenomena and features, provision of Propulsion Laboratory (JPL).
oceanographic data for both application and Responsibility for Seasat project manage-
scientific areas, and the determination of key ment, mission planning and direction, mis-
features of an operational ocean dynamics sion operations and experiment data process-
monitoring system. ing resided at JPL. The Goddard Space
To fulfill these objectives, the Seasat sen- Flight Center (GSFC) provided network
sor complement comprised a radar altimeter support and spacecraft orbit and attitude de-
(ALT), a synthetic aperture radar (SAR), a terminations; use was therefore made of the
2O2
THE SEASAT FAILURE
f
existing Spaceflight Tracking and Data systems, and comprehensive and frequent
Network, the NASA Communications (NAS- technical and management reviews. A large
COM) network, and the Project Operations in-house staffwas required in order to imple-
Control Center that are operated by GSFC. ment this approach. The high cost of conduct-
To place this failure review in a proper ing space programs in this mode severely
perspective, it is noted that the Seasat space- constrained the future uses of space. During
craft operated in orbit in a generally satisfac- the final phases of the Apollo program,
tory maneuver for over three months and NASA management accordingly instituted a
provided a large amount of scientific data. policy aimed at reducing the cost space mis-
The sensors represented a significant ad- sions. This policy was aggressively pursued
vance in technology and their integration by the highest levels of management.
into the sensor module, a large engineering A Low Cost Systems Office was estab-
challenge. In addition, Seasat also required lished in Headquarters to oversee a stan-
the creation of significantly enlarged capa- dardization program and to encourage the
bilities in the acquisition and processing of use of existing hardware. This program in-
flight data. That the important and signifi- cluded the development of standard compo-
cant technical and engineering advance- nents as well as a multimission spacecraft.
ments were achieved is a tribute to the skill A major emphasis was placed on shifting
and dedication of all who were associated work from in-house to out-of-house in consid-
with this program. eration of reducing the NASA manpower

The Seasat spacecraft was successfully base. Design-to-cost techniques and cost
launched on June 26, 1978, and thus operat- benefits of heritage through the use of hard-
ed for 105 days until the failure occurred on ware and software developed for other pro-
October 9, 1978. During this time in orbit, grams were subjects to be addressed at each
the spacecraft operation was generally satis- step in the approval cycle.
factory with considerable data being ob- The basic philosophy of the Seasat pro-
tained from all of the sensors. Three signifi- gram was thus established in an environ-
cant anomalies were experienced during the ment in which management emphasis was
life of Seasat in orbit, one involving sun in- shifting from one of demonstrating a nation-
terference in the attitude control system scan al capability to operate reliably in space to
wheels, one caused by a sticking thermostat one of reducing the cost of utilizing space.
in a sensor heater circuit, and one in which Design-to-cost was a fundamental tenet of
the spacecraft suffered an abnormally low the Seasat project definition. A cost estimate
bus voltage for several orbits. Because of a of $58.2 million was established as a target
possible relationship of these latter two cost at the end of the feasibility study phase
anomalies with the failure of October 9, in mid-1973 and was imposed as a design-to-
1978, they were specifically investigated by cost ceiling in December 1973 by NASA
the Board. management. Any overruns were to be offset
by descoping the mission content.
PROGRAM HISTORY AND MANAGEMENT In attempting to define a program which
would both satisfy the user community and
The Seasat program was conceived and live within the ceiling cost, the concept of
initiated in a period of transition in the making maximum use of proven existing
philosophy of management of NASA pro- hardware and software was adopted early in
grams following the Apollo program. Apollo, the program planning phase. This in turn
and to varying degrees other NASA flight provided for a reduction in design and devel-
programs, were characterized by extensive opment effort and in the size of the in-house
test programs, large formal documentation staff needed to monitor the activity.
203
_,'_,'_i _,/ _ Solar Arrays (2)

Agena Bus
;_ °/["
II-_L .r
__,_. L/__Flight Path
Sensor Module
. :-_ -_--'_; SAR Antenna

Y
Earth Pointing Sensors
Figure i On-Orbit Configuration of the Seasat Spacecraft
These were key elements of the manage- With the user requirements as a basis, the
ment philosophy which influenced the struc- feasibility studies examined the Seasat mis-
ture and conduct of the program. sion from an overall systems viewpoint, in-
cluding a review of instrumentation and pos-
PROGRAM PLANNING sible spacecraft (bus) approaches to accom-
modate the instrumentation.
Feasibility Studies (Phase A) - Feasi- Subsequent to the submission of the
bility for the Seasat mission was established Phase A studies in July 1973, a joint
in '73 through three studies conducted by the NASA/User Study Task Team was formed to
JPL, GSFC, and the Applied Physics Labora- review the Phase A studies, integrate the
tory of the Johns Hopkins University. These results, and provide technical and program-
studies were aimed at meeting the set of user matic guidance for more in-depth Definition
requirements generated at a series of meet- Phase studies.
ings held in the first half of 1973 among As a result of this review, the Task Team
NASA and representatives of the govern- recommended a Baseline Mission which in-
mental, commercial, and institutional com- cluded a complement of the five sensor types
munities of users of ocean dynamics data. that actually ended up flying on Seasat.
204
THE SEASAT FAILURE
Based upon cost estimates prepared by Baseline Mission within the design-to-cost
the Phase A study participants, the Task ceiling.
Team recommended a target cost of $58.2 With the stimulus of the design-to-cost
million for the Baseline Mission. This includ- ceiling, and management emphasis on the
ed the cost of the spacecraft bus and instru- maximum use of existing subsystem hard-
ments, the launch vehicles, and tracking and ware, the JPL Definition Phase Group pro-
data acquisition. An Alternate Payload Mis- posed the of idea building a spacecraft sys-
sion of reduced capability, excluding the syn- tem comprising two major elements: a sensor
thetic aperture radar, was also recommended module designed specifically for Seasat, and
for further study with a target cost of $43.2 a spacecraft bus based on an existing, flight
million. proven bus devloped for other Air Force or
There was some discussion in the Seasat NASA programs. The JPL viewed the results
Study Study Task Team Report (October of the Phase A studies as indicating that the
1973) of the use of an existing bus to mini- requirements of the sensors could be satisfied
mize cost. The idea, however, was addressed by standard support subsystems for attitude
with some skepticism. While it was believed control, power, structures, thermal control,
that the use of subsystems with a high de- etc. On the other hand, the area of greatest
gree of inheritance from existing programs uncertainty was seen to be the definition of
was desirable and possible, it was not clear at the sensor's operating capabilities, data re-
that time that an existing bus could be quirements and sensor system integration. It
adapted economically. was therefore proposed that if a suitable
spacecraft bus were available, the design and
Definition Studies and Preliminary development effort could be concentrated on
Design (Phase B) - Definition Phase Studies the sensors and their integration with a sen-
of the Baseline and Alternate Payload Mis- sor module that could then be mated to the
sions recommended by the Seasat Study bus via a mechanical/electrical interface.
Task Team were conducted from November The JPL entered into four $I5,000 study
1973 to the summer of 1974. The Wallops contracts with aerospace companies (Boeing,
Flight Center managed the Definition Phase General Electric, Lockheed, and TRW) that
Study of the Baseline Mission which was con- had existing spacecraft designs with capabil-
ducted by the Applied Physics Laboratory. ities in the range of Seasat requirements to
The JPL, assisted by various aerospace com- evaluate the concepts that: (1) there are ex-
panies familiar with Earth satellite design, isting buses that could be used, without
conducted the Definition Phase Study of the modification, to supply the necessary support
Alternate Mission. functions for the sensor payload, and (2) new
In December 1973, NASA management design functions could be incorporated in a
adopted the $58.2 million figure recommend- separate module along with the sensors and
ed by the Task Team as a not to exceed ceiling thereby reduce the systems development
for the Seasat Baseline Mission. The efforts task to a sensor system development task.
of the Definition Phase Study participants The studies were conducted from November
were accordingly intensified to develop the 15, 1973 to March 30, 1974. The sensors were
most economical satellite system possible described to the study contractors as they
that would best suit the user requirements were developed on December 15, 1973, with
within the cost ceiling. updates as appropriate until the end of these
GSFC declined to participate in the Defi- studies.
nition Phase activity as they had serious It was concluded as a result of these stud-
doubts as to their ability to structure a full ies that basic sensor support requirements
2O5
could be satisfied by the existing spacecraft Laboratory's Definition Phase studies to

bus designs studied with "no major changes," NASA Headquarters management in August
although "minor modifications" were ac- 1974 resulted in a reduced baseline payload
knowledged to be required. It was contem- at the $58.2 million ceiling which eliminated
plated, for example, that minor modifications the microwave radiometer and combined the
would be required of the attitude control, altimeter and scatterometer into a single in-
power, and temperature control subsystems. strument, but which retained the synthetic
Telemetry, tracking and command subsys- aperture radar, as well as the visual and in-
tems were reported to be off-the-shelf de- frared radiometer.
signs, but required significant modification.
It should be noted that the contractor bus SPACECRAFT REQUIREMENTS AND
studies were concerned almost solely with DOCUMENTATION
mission performance requirements. The re-
ports did not sufficiently define the sub- The two primary contractual documents on
system design or component selections to Seasat were the Satellite Vehicle Specifica-
provide a basis for an adequate penetration tion (Part I and Part H) and the Satellite Ve-
of heritage. The JPL Definition Phase Final hicle System Test Plan. There were 13 other
Report nevertheless concluded that the exist- documents which required JPL approval, but
ing bus approach had significant cost, sched- these were primarily implementation and
ule and risk advantages, and permitted a operations type plans; i.e., Data Manage-
concentration of development efforts on the ment Plan, Quality Assurance Plan, etc. One
sensor system. of these plans, the Reliability Assurance
Midterm reports in May 1974 of the JPL Plan, is relevant to this chapter and will be
and the Wallops Flight Center and Applied discussed herein.
Physics Laboratory Definition Phase study Part I of the Satellite Vehicle Specifica-
groups demonstrated that neither the Base- tion established the performance, design, de-
line nor Alternate Payload Mission was velopment, and qualification requirements
achievable within the $58.2 million ceiling. for the Seasat mission. Part II of the specifi-
The Wallops Flight Center and Applied cation established the product configuration
Physics Laboratory's estimate for the Base- and system test acceptance requirements.
line Mission, which included an in-house de- This specification is similar to a typical Part
signed spacecraft, was $85.2 million. At this I, Part II Contract End Item specification
point in time the Wallops Flight Center and used for most NASA programs.
the Applied Physics Laboratory adopted the The Satellite Vehicle Systems Test Plan
sensor module/existing bus concept that JPL established the test program for assembling,
was pursuing. JPL's midterm estimate for testing, monitoring and operating the Seasat
the Alternate Payload Mission using the ex- spacecraft from manufacturing through
isting bus concept was $65.9 million. launch. The Satellite Vehicle Systems in-
The JPL and the Wallops Flight Center cluded all Lockheed and government fur-
and Applied Physics Laboratory searched for nished hardware installed in the Agena bus
ways to descope the project in order to stay assembly and the sensor module. The test
within the cost ceiling. Each group per- plan was the controlling test document and
formed a number of iterations wherein sen- subordinate only to the Satellite Vehicle
sor performance and sensor combinations Specification. An evaluation was made re-
were varied in order to decrease the cost and garding this flow of requirements and the in-
yet meet the basic user requirements. terrelationships of Lockheed and JPL rela-
A final presentation of the JPL and tive to control and the visibility of require-
Wallops Flight Center and Applied Physics ments.
206
THE SEASAT FAILURE
Compliance with Requirements - Dur- uncovered during detailed evaluation into

ing the Board's review, it was determined the qualification status of the electrical pow-
that a significant test required by the JPL er subsystem components that point out the
approved test plan was not conducted. The weakness of the EM system.
Satellite Vehicle Test Plan required elec- In one case, the Seasat environmental
tronic assemblies to be subjected to eight requirements specified a five minute per axis
cycles in thermal environment of which, as a random vibration level but several compo-
minimum, two cycles should be in a vacuum nents were qualified by similarity to a pro-
chamber (acceptance test). The Slip Ring gram that required only a three minute per
Assembly Component Specification, howev- axis vibration. This five minute per axis
er, did not require a thermal vacuum test. requirement was also specified in Part I of
This noncompliance was not recognized by the Satellite Vehicle Specification. There
JPL or Lockheed systems engineering until was no documented evidence that this non-
the present failure investigation was begun. compliance was acceptable. In the second in-
Discussions with Lockheed and JPL person- cident, pyro shock levels for Seasat were not
nel revealed that there was not a closed loop enveloped by the program to which the Sea-
system to assure compliance with contractu- sat slip ring assemblies were "qualified by
al requirements identified in the test plan. similarity." While an EM stated that the slip
The fact that a component specification ring assemblies are "not highly sensitive to
that violated a contractual requirement pyro shock," there was no documentation or
could be issued is indicative of a lack of analysis to support the stated conclusion.
checks and balances in the system. Another Because Seasat was a one-of-a-kind vehi-
indication of this lack surfaced in reviewing cle, Lockheed did not summarize the require-
the qualification requirements. In at least ments contained in the various EMs into a
two cases, to be discussed below, qualifica- single baseline document. A baseline docu-
tion requirements noncompliance was not ment, with change control, would have been
documented. In fact, in the areas where the a systematic approach to assuring require-
Board performed an in-depth evaluation, in- ments were satisfied and would have pro-
consistencies in requirements were noted in vided a feedback mechanism to all parties.
many cases. Most inconsistencies were mi- The large number of EMs produced in the
nor; however, the impression left was that Seasat program made it very difficult for
both compliance with requirements by Lock- Lockheed to use the EMs to manage the
heed and the check and balance system at program and to assure continuity in require-
Lockheed and JPL were deficient. ments, as exemplified above, and equally
difficult for JPL to effectively penetrate the
Engineering Memoranda - Environ- system.
mental derivations, test criteria and detailed
test requirements were documented in engi- The Failure Modes, Effects and
neering memoranda (EMs). Lockheed stated Criticality Analysis (FMECA) - The
that EMs were used to allow early genera- FMECA prepared for Seasat utilized the
tion of requirements while the spacecraft de- Fault Tree Analysis Technique. In effect,
sign was being finalized. A considerable this was a method for studying the factors
number of EMs were developed during the that could cause an undesired event to occur
course of the Seasat program, and it accord- and inputting these factors into a computer
ingly became very difficult to establish a model to which probability data could be
documentation trail as to how test require- applied to determine the most critical and
ments were established, modified, and satis- probable sequence of events that could pro-
fied. In fact, two particular incidents were duce the undesirable event.
207
The Reliability Assurance Program Plan equipment engineer and the program engi-
required that a FMECA be performed at the neer. Two specifications were released prior
system level. Further evaluation revealed to April 1976 and never received the full
that "critical/new equipment" would also be complement of signature approvals. These
subjected to an FMECA. Out of the 74 criti- two specifications were for the Slip Ring As-
cal items identified on Seasat, only three semblies and the Solar Array Drive Motors.
were judged to require component level Had the other three engineering organiza-
FMECAs. These were the command timing tions reviewed the specifications, quite possi-
unit (CTU), the telemetry sensor unit (TSU) bly the Slip Ring Assembly thermal vacuum
and the synthetic aperture radar (SAR) an- test deletion may have been prevented and
tenna (supplier performed). inconsistencies in the qualification require-
The FMECA for the electrical power sub- ments may have been avoided. The compo-
system stated that there were "no single nent specifications were not reviewed and
point failures" and listed a number of redun- approved by JPL.
dancies, including main bus power supply
channels, batteries, charge controllers, and Qualification for Flight - The Seasat
others. Electrical shorts were, however, not program used the classical methods of quali-
included as possible failure modes; almost all fying hardware for flight. These were:
of the effort was directed toward consider-
ation of failure modes that would result in a) Qualification by test to demonstrate the
loss of solar array power, and the only slip capability of an item to meet specification
ring assembly failure mode considered was requirements.
"slip ring contact failure." The lack of consid- b) Qualification by design similarity where-
eration of electrical shorts in effect prevented by an unqualified item is compared with
the FMECA from serving as a tool for direct- an item qualified by test to determine
ing attention to those portions of the system whether the requirements for both items
where electrical shorts could occur and led to and their configurations are sufficiently
the erroneous conclusions that there were no similar to justify not testing the unquali-
single point failure modes in the electrical fied item.
power subsystem. c) Qualification by engineering analysis, in-
dependently or in conjunction with test
Component Specifications - Compo- and/or similarity, to meet a specific quali-
nent specifications were used on Seasat to de- fication in the specifications. The use of
fine the design, performance, acceptance, engineering analysis alone could not be
and qualification requirements of the major used to satisfy all qualification require-
hardware items and subassemblies. Because ments.
the program intent was to utilize as much
off-the-shelf hardware as possible, many ex- In September 1976, the Lockheed Seasat pro-
isting specifications were redlined and up- ject issued a directive creating an Equipment
dated for the Seasat Agena bus. These red- Qualification Review Board for the purpose
lined specifications were then converted into of reviewing and approving all qualification
component specifications by the responsible and design similarity certificates. The pri-
equipment engineers. After April 1976, a mary membership of the board included the
program directive established that all com- program engineering managers, the chief
ponent specifications on Seasat required the systems engineer, the program reliability en-
signature approval of reliability engineer- gineer, the quality assurance manager, and
ing, of space technology, and of the chief sys- the applicable space technology manager.
tems engineer in addition to the responsible This Board met every two weeks to review
208
THE SEASAT FAILURE
the status of the qualification program and to reports and made a conscious decision as to
determine what additional tasks were re- the possible effect of the anomaly in contri-
quired to qualify a given item. Status reports buting to the Seasat failure. None of the non-
were issued by program reliability engineer- conformances were judged to be contributory
ing which tracked the qualification progress to the failure.
and documented open items. Evaluation of the spacecraft build paper
The qualification cycle concluded with a of the electrical power subsystem indicated
meeting to review all test data, design simi- that the Air Force Plant Representative Of-
larity statements, engineering analyses, and fice involvement, operating under delegation
individual component pedigree packages. In- from JPL, was shallow. Inspection coverage
dividual Certificates of Qualification were is- was concentrated at the system level with
sued stating that the specific component had few in-process mandatory inspection points.
been qualified to the intended environment Early negotiations surfaced the fact that
and was acceptable for flight. A JPL engi- the Air Force Plant Representative Office
neering representative attended these quali- could provide neither the number of person-
fication review meetings but was not re- nel nor the required skill levels to perform
quired to approve the qualification certif- electronic inspections. As a result of these
icate. A JPL reliability representative at- negotiations, JPL elected to send three JPL
tended approximately 25 percent of the re- inspectors on extended temporary duty to
view meetings. perform 100 percent of the solder joint in-
spections and electronic component accep-
Review of Build Paper - An evaluation tance testing. While it cannot be stated that
of the Seasat "build" paper was made with a more in-depth involvement by the govern-
primary attention focused on the electrical ment would have prevented the failure, it is
power subsystem. The review encompassed the opinion of the Board that the depth of
the electrical harness fabrication and instal- penetration was inappropriate and a more
lation, the "pedigree packages" on electrical selective penetration would have been in or-
components and assemblies, nonconformance der rather than a nearly total reliance on
reports on anomalies encountered in assem- system level audits and shakedown inspec-
bly and test, vehicle log books, and the vehi- tions for the bus assembly operations.
cle acceptance summary.
Because the Board's failure analysis SLIP RING HERITAGE
eventually identified the slip ring assembly
as the component responsible for the Seasat Consistent with the basic philosophy of the
failure, the detailed build paper associated Seasat program to use, to the maximum ex-
with only this component will be discussed in tent possible, standard flight-proven equip-
the next section. However, some brief obser- ment, the solar array drive motors and slip
vations are presented below that deal with ring assemblies for Seasat were adapted from
other findings made during the course of the another Lockheed program. At the time of
investigation. initial contract negotiations, this other Lock-
The nonconformance reports are used by heed program had just developed a slip ring
Lockheed to document nonconforming condi- assembly and was in the process of perform-
tions and resultant dispositions and correc- ing qualification testing. This slip ring was
tion actions. In general, the nonconformance also being considered for still other Lockheed
report system at Lockheed was found to be programs and it was anticipated that the as-
acceptable. At the Board's request, Lockheed sembly would be a qualified and flight-
reviewed, cataloged, and summarized all proven design by the time Seasat was flown.
electrical power subsystem nonconformance As it turns out, however, the program for
209
which the design was originally developed on one of the Seasat assemblies was caused
was canceled after completion of slip ring by shorting of a wire to ground due to cold
qualification but prior to flight; however, one flow of the Teflon insulation in the region
other Lockheed program did fly a slip ring where high stresses were imposed on the
assembly of this design shortly before Seasat wire. This incident will be described later.
was launched. While the designs of the slip Considerable evidence exists in published
ring assembly for Seasat and this "previously reports that the sliding friction between
flown" program were identical, the wiring se- brushes and rings will generate debris parti-
quence of the individual rings and brushes cles that can accumulate and produce electri-
was different in the two programs. As noted cal noise or, in some cases, short circuits be-
earlier, the Seasat slip rings were wired such tween adjacent rings and brushes. Lockheed
that most of the adjacent power brushes were experienced a shorting failure in a slip as-
of opposite DC polarity while the other Lock- sembly used in ground tests of a control mo-
heed program was wired such that the adja- ment gyro prior to June 1977, which was at-
cent power brushes had the same polarity. tributed to accumulation of brush-generated
This difference in how the slip ring assem- debris and subsequent arcing between adja-
blies were connected into the electrical power cent power brushes. Discussion with engi-
subsystem thus became crucial to the heri- neering personnel from TRW, Ball Corpora-
tage of the Seasat slip ring assembly; when tion, and Sperry Flight Systems have indi-
the Seasat slip ring assembly became, in its cated that other aerospace contractors have
application, connected in a manner that was experienced similar slip ring shorts in
different from its sole predecessor it became ground tests. As a result of their experience
a unique, first of a kind component. with slip rings, Sperry initiated an experi-
Two significant problems were noted as a mental study of the possible effects of debris.
result of random vibration testing of the slip While the Board recognizes that there are
ring assemblies used for the other Lockheed significant differences between the design
flight program. An isolation failure was and application of the Seasat slip ring assem-
found after vibration testing in two adjacent bly and these other units, experience illus-
brush/ring circuits. The corrective action was trates a third possible failure mode due to
to separate the brushes. Also, when the as- shorting caused by contaminants or debris
sembly was opened for this operation, a crack within the assembly.
was noted in the brush mounting block at a
mounting hole. This block was replaced on Seasat Slip Ring History - A portion of
the failed unit and a "T" strengthener was the build history of components is assembled
added to all identical slip ring assemblies, in- by Lockheed into pedigree packages. These
cluding the Seasat units, to distribute the packages contain component drawings, a
mounting loads away from the mounting component specification including accep-
point. tance and qualification test requirements,
nonconformance reports, and some vendor
Failure History - Slip ring assemblies of documentation including specified testing
the design flown by Seasat experienced two and plans test records. Component selection
nonconformances that provide evidence of for pedigree packages was determined by the
two separate failure mode possibilities. One Seasat Program Office and the quality assur-
of these was the isolation failure noted above ance organization at Lockheed. The Seasat
on the other Lockheed flight program that slip ring assemblies are documented by such
was indicative of a possible failure mode due pedigree packages. Relevant component his-
to contact between adjacent brushes of oppo- tory not contained in the slip ring pedigree
site polarity. Another failure mode identified packages include vendor assembly and test
210
THE SEASAT FAILURE
nonconformance reports (including failure lined version of the Program A specification.

reports), assembly test procedures and It was in this March 5, 1976, specification
records (including brush alignments and that the Program A requirement for 10 cy-
pressure checks and brush "run-in" proce- cles of thermal vacuum acceptance testing
dures), and relevant vendor and customer was deleted. This deletion occurred even
correspondence. though: (1) the majority of the Seasat elec-
The timing of the Seasat contract was tronic assemblies and electromechanical as-
such that Lockheed was able to acquire two semblies were subjected to a thermal vacuum
partially assembled slip ring assemblies acceptance test; (2) Seasat reliability and
when another Lockheed program referred to systems engineering personnel, and JPL per-
herein as Program A, was canceled. Program sonnel were unaware of this deletion until
A had initially contracted for 10 assemblies the present failure investigation; and (3) the
and, at the time of termination, had accepted thermal vacuum test was contractually re-
delivery of one qualification unit, one devel- quired and a waiver of the requirement was
opment unit, and two production units leav- never issued.
ing six partially assembled units at the ven- Upon pursuing the thermal vacuum dele-
dor. The Seasat program picked up two of tion further, it was determined from inter-
these units and Lockheed Program B picked views with involved personnel that the test
up the additional units. Reference will be was deleted during verbal negotiations be-
made to Program B in other portions of this tween both the responsible equipment engi-
report relative to test experience and use of neer and the buyer at Lockheed, and the ven-
Program B qualification testing as a basis for dor in order to reduce unit cost of the slip
qualifying the Seasat slip rings by similar- ring assemblies. The responsible Lockheed
ity. program engineer approved the deletion but,
Program A personnel were informed by at that time, there was no requirement to co-
Poly-Scientific in late 1973 that the con- ordinate specifications with the Seasat pro-
straints placed upon the length of the assem- gram reliability engineer or the chief sys-
bly were found to be restrictive and that re- tems engineer. The fact that a waiver was
lief of the specifications would enhance reli- not issued on this and other contract noncom-
ability. Program A, however, could not relax pliances is indicative of a weak compliance
the specification. Although the Seasat appli- system between Lockheed and JPL.
cation was not constrained by length, the On March 25, 1976, Lockheed issued a
program desire to use available off-the-shelf formal Request for Quote to Poly-Scientific
hardware precluded the development of a for two Seasat slip ring assemblies built to
new unit having increased dimensional tol- the March 5, 1976 specification with a re-
erances between the rings and brush assem- quested delivery date of one year. On May
blies with possibly enhanced inherent reli- 26, 1976, Lockheed authorized contract go
ability. ahead for two slip ring assemblies at a unit
Seasat personnel initiated discussions price of $8,953.50.
with Poly-Scientific in late 1975 using the Researching the manufacturing history
Lockheed Program A specification as a base- and fabrication and test anomalies at Poly-
line. On February 3, 1976, Poly-Scientific Scientific resulted in the following:
submitted its first written quote for two as-
semblies to be fabricated and tested per the a) There were four anomalies noted on slip
Program A specification. This initial quote ring unit 1001. Three were minor and ap-
was not acceptable to Lockheed, and the re- pear to have had no real impact on assem-
sponsible equipment engineer and buyer re- bly reliability. The fourth anomaly was a
sponded on March 5, 1976, with a Seasat red- Teflon wire short to an adjacent ground
211
lug. The repair action, approved by Lock- 2) Poly-Scientific stated that the toler-
heed engineering, was to insulate the ances within the slip ring assembly
ground terminal and repot with ES 222-2 could allow adjacent brushes to touch.
cement. The damaged insulation on the It is noted here that an identical slip
wire was not repaired. This discrepancy ring assembly experienced an isola-
report was not included in the vendor's tion failure during acceptance testing
data package and consequently this fail- which was probably caused by adja-
ure was not contained in the Lockheed cent brushes touching. (Program B
pedigree package. hardware).
b) Slip Ring Unit 1002 (-Y solar array) had Both Seasat slip ring assemblies were
the more significant anomalies noted dur- shipped from Poly-Scientific on February 22,
ing fabrication and test. These anomalies 1977. These units were received and accepted
are summarized as follows: at Lockheed on March 11, 1977, where they
1) 9/20/76 - 80 minute run-in of brushes remained in storage until required for instal-
to rings at 100_ 10 rpm. Run-in time lation on their respective solar array mod-
should have been for 100 to 115 min- ules.
utes. This discrepancy was missed and In approximately July 1977, Lockheed
not documented. Program B, which utilized identical slip ring
2) 9/23/76 - discrepancy No. 146522 - dis- assemblies, made a wiring change external
colored rings noted after above run-in to the slip rings that separated the polarity
test. Unit had to be completely disas- arrangement of adjacent slip rings. By
sembled, brushes and rings recleaned, changing connector pin functions, the power
unit reassembled and another run-in applied to individual rings was changed from
performed. The exact run-in time was a configuration in which adjacent rings were
not recorded nor entered into the log of opposite polarity to one having positive
book. contacts on one end of the slip ring assembly
3) 11/12/76 - discrepancy No. 151887 - ex- and negative contacts on the opposite end.
cessive noise noted caused by moisture This wiring change significantly reduced the
pick-up in the brush material. Correc- possibility of internal shorts within the slip
tive action was to run the unit in vacu- ring assembly.
um at 14.4 rpm for 1½ hours. No vacu- The Seasat chief system engineer was
um cleanup was performed after this contacted by a system engineer from Pro-
14.4 rpm run-in test. This run time gram B about this change in wiring in Au-
was not entered into the log book. gust 1977. The explanation given for the wir-
ing change was a concern that the ascent vi-
c) Review of vendor documentation and sub- bration environment could cause adjacent
sequent teleconferences with Poly- brushes to make contact and thus produce an
Scientific personnel revealed the follow- electrical short because Program B slip rings
ing assembly technique and procedures: had power applied during launch. The chief
1) The assembly planning documenta- system engineer discussed this change with
tion specified that the brushes were to the Seasat program engineer and they decid-
be aligned "in center of the rings." ed not to make a similar wiring change be-
This requirement was verified visual- cause Seasat did not see the same launch vi-
ly by the inspector, but no dimensional bration levels and because Seasat slip rings
checks were made. Proper alignment were not planned to be powered during
of the brushes is dependent, therefore, launch. It is noted that in April 1978, a
on the inspector's judgment. change in launch relay configuration was
212
THE SEASAT FAILURE
made which did apply power to the slip ring slip ring assembly which could have detected
assemblies. In retrospect, the decision not to missing washers in the slip rings, and (2) it
change the wiring sequence for Seasat was a was never conclusively determined if all lost
crucial one. When the other program washers were found.
changed its wiring and Seasat did not, Seasat The solar array modules, including the
became the first program to fly a 52-brush slip ring assemblies, were shipped to the
slip ring assembly with adjacent brushes of launch site in April 1978. The last reported
opposite polarity. Had there been better visi- anomaly on the slip rings was high contact
bility to the problems experienced with slip resistance on unit 1002 during interface tests
rings by both the vendor and by other organi- performed when the solar array modules
zations within Lockheed, the Seasat engi- were mated to the vehicle. The resistance
neering managers may have been more sen- reading recorded was 2.38 ohms; the specifi-
sitive to the failure prone nature of this com- cation value was 2.00 ohms maximum. The
plicated device and to the importance of the engineering disposition in the nonconfor-
electrical polarity of adjacent brushes. Un- mance report was "use-as-is" because in-
fortunately, such visibility, which may only flight operation would decrease the contact
have needed to have been slight to have been resistance.
effective, was lacking.
Slip Ring Assembly serial number 1002 SIGNIFICANT FINDINGS
was installed on the -Y solar array module on
August 17, 1977. On August 30, 1977, a non- 1) The spacecraft failure that occurred on
conformance report was written because the October 9, 1978, was due to a loss of elec-
mechanic "lost" an undetermined number of trical power in the Agena bus as a result
shim washers. of a massive and progressive electrical
Review of the installation drawing re- short within the slip ring assembly of the
vealed that four number 10 washers were re- -Y solar array.
quired between the solar array mounting 2) The electrical short was most probably
structure and the slip ring assembly. The initiated by an arc between adjacent com-
cover of the assembly is made of thin sheet ponents in the slip ring assembly. Possi-
metal and is prone to bow up during installa- ble triggering mechanisms for this arc are
tion operations. Because the mounting bolts momentary shorts caused by wire-to-
go through the cover plate into the threaded brush assembly contact, brush-to-brush
holes in the slip ring body, the mechanic had contact, or by a contaminant.
to place the round washers over the bolts be- 3) The congested nature of the slip ring de-
tween the structure and the cover plate. It sign, coupled with a wiring arrangement
was during this operation that the mechanic for connecting the slip rings into the pow-
lost the washers. The S/N 1002 slip ring as- er subsystem that resulted in most of the
sembly was removed from the solar array adjacent brush assemblies being of oppo-
module, the cover plate removed and three site polarity, made the Seasat slip ring as-
washers were found. Because some areas sembly particularly prone to shorting.
were still obscured, an x-ray of the slip ring 4) The combination of design and wiring se-
was taken. No additional washers were locat- quence used for the Seasat slip ring as-
ed. A nonconformance report was then writ- semblies made these unique, first-of-a-
ten against Slip Ring Assembly 1001 and no kind components.
washers were found by either visual or x-ray 5) The possibility of slip ring failures result-
inspection. It is interesting to note two ing from placing opposite electrical po-
things: (1) there were no downstream electri- larities on adjacent brush assemblies was
cal functional checks after installation of the known at least as early as the summer
213
1977 to other projects within the prime Phase B project plans before becoming en-
contractor's organization. That the Seasat gaged in the actual spacecraft develop-
organization was not fully aware of these ment.
potential failure modes was due to a
breakdown in communications within the Although unrelated to the failure of the Sea-
contractor's organization. sat, certain deficiencies in flight control pro-
6) The failure to recognize the potential fail- cedures were present that are worthy of note
ure modes of the slip ring assembly and to as a lesson for the future. The flight control-
give this critical component the attention lers were not provided with an adequate set
it deserved was due, in part, to the under- of safing command sequences to use in re-
lying program policy and pervasive view sponse to anomalies, were not sufficiently fa-
that it was an existing component of a miliar with the system they were controlling,
well-proven and extensively used stan- received insufficient anomaly training and,
dard Agena bus. This program policy fur- during the failure event itself, failed to fol-
ther led to a concentration by project low the prescribed procedures in response to
management on the sensors and sensor the flight data available to them. Compound-
module of the spacecraft to the near ex- ing these difficulties were the frequent
clusion of the bus subsystems. In actual- breakdowns of the ground data acquisition
ity, many of these subsystems, including and processing system throughout the mis-
the power subsystem, contained compo- sion.
nents that were neither flight proven nor It is ironic, and yet typical, of spacecraft
truly qualified by similarity. failures that the termination of the Seasat
7) Lack of proper attention by both Lock- flight was caused not by a malfunction of a
heed and JPL Seasat program engineer- new or sophisticated device, but by a failure
ing to the new and unproven components in a very common component of a type that
on the Agena bus resulted in several in- has flown in many spacecraft for many years.
stances of both noncompliance with con- It is also ironic, and instructive, that the
tractual, qualification and acceptance re- smallest of events or the slightest of commu-
quirements and failure to document such nications could have prevented the failure.
noncompliances. Better clarity in an oral communication, a
8) The Failure Modes, Effects, and Critical- brief memorandum of the right kind at the
ity Analysis that was conducted for the right time, a failure report coming to the
electrical power subsystem did not consid- right person, or an alert engineer could have
er shorts as a failure mode and thus did made all the difference.
not reveal the presence of single point Basic to the Seasat mission was the con-
failure modes in the subsystem nor pro- cept of using an existing, flight-proven space-
vide a basis for the development of a full craft bus for the services and housekeeping
complement of safing command se- functions required by the sensors in order to
quences that could be used by the flight minimize program costs and to permit a con-
controllers in responding to anomalies. centration of effort on the sensors and their
9) The strong desire on the part of all con- integration into the spacecraft. Thus the use
cerned to initiate the project as soon as of a "standard Agena bus" as part of the Sea-
possible resulted in inadequate time for sat spacecraft became an enduring tenet of
an effective Phase B study. As a result, the program. So firmly rooted was this prin-
the project office did not have the opportu- ciple in program philosophy that, even after
nity to plan the activity thoughtfully and the engineering staffs of both the govern-
establish the preliminary designs, compo- ment and the contractor were well aware of
nent evaluations, test plans, and other the final uniqueness of their Agena bus, the
214
THE SEASAT FAILURE
words, and the associated way of doing busi- components that are different should be
ness, persisted. They became deceived by treated as new. The policy of limited pene-
their own words. tration into Seasat's Agena bus by the gov-
Consistent with the concept of the "stan- ernment was appropriate, but a limited pene-
dard Agena bus" was the policy decision to tration must be a selective penetration and
minimize testing and documentation, to not a reduced effort everywhere.
qualify components by similarity wherever This identification of the heritage of pre-
possible and to minimize the penetration into viously used equipment, in both design and
the Agena bus by the government. As a re- application, need not require a large staff or
sult, a test was waived without proper ap- a lot of money. But it does take time, both at
proval, important component failures were the start of the project and at the time of the
not reported to project management, compli- Critical Design Review. And here, respond-
ance with specifications was weak, and flight ing to strong desires by all concerned to get
controllers were inadequately prepared for the project on contract and underway, the
their task. Significantly, the Seasat slip ring Seasat project was denied the advantage of
assembly had no applicable flight history at an effective Phase B study. Had there been
the time of its launch and, in its application an effective Phase B study period, prelimi-
to the spacecraft, was a new device. nary designs would have been completed,
There can, of course, be no quarrel with component selections better understood, test
the policy of using existing and well proven plans and qualification requirements better
equipment. The use of such equipment has established, and possibly, the critical role
certainly reduced the costs and contributed and inherent complexities of the slip ring as-
to the success of many space missions. But sembly might have been more apparent to
the world of space flight is an unforgiving the Seasat engineering staffs. Whether such
one and words like "standard," "existing," a Phase B study period would have precluded
and "similar to" can be traps for the unwary. the Seasat failure is, of course, uncertain for
The technical risks of using standard equip- history does not reveal its alternatives. But
ment can be as high as those present in a new such a carefully conducted planning and
or untried piece of equipment, but the ap- study period would have minimized the
proach, both technical and managerial, must chances for the type of failure that did occur.
be different. For new equipment, one designs The policy of using existing, flight-proven
carefully, reviews thoroughly, and tests com- equipment can be both valid and cost effec-
pletely -- and that we know how to do. For tive. But it is the main lesson of Seasat that
standard equipment, one should diligently an uncritical acceptance of such classifica-
and thoroughly probe the heritage that justi- tions as "standard" can submerge important
fies the classification and identify, compo- differences from previously used equipment
nent by component and piece by piece, those in both design and in application. It is impor-
that are truly standard and those that are tant, therefore, that thorough planning be
not. One should assume that each space vehi- conducted at the start of a project to fully
cle is unique until proven otherwise. Then, evaluate the heritage of such equipment, to
for those parts that are standard or well identify those that are standard and those
proven, and that are applied in the same that are not, and to establish project plans
way, one can forego design, reviews, testing and procedures that enable the system to be
and extensive documentation. Conversely, penetrated in a selective manner.
215
DEFINING SYSTEMS ENGINEERING
DEFINING SYSTEMS ENGINEERING
by George S. Trimble
Editors' Note complicated to run than a simple old 'engi-

Back on September 27, 1968, a NASA engineering' blueprint file, which was, of course,
neer by the name of George S. Trimble wrote familiar. The guy from industrial relations
to the Chief of the Management Analysis and never did understand it because the guy who
University Programs Office after the Chief explained it, didn't. It takes a lot of words to
issued a letter to find a universally suitable explain something you don't understand or
definition for "systems engineer." The engi- that isn't there. Try explaining 'zero' some-
neer told the manager that the term had no time.
particular meaning at all. "In fact," Trimble A parallel effort with the objective of em-
claimed, "I may know the guy who thought it phasizing *!!ENGINEERING!!* was carried
up or resurrected it, as the case may be, for out with great dispatch by the 'scientists,' all
modern usage." His seemingly authoritative of whom became famous at the close of WWII
account follows: because a couple of them invented and built
During the war, new management prac- the A-bomb, all by themselves, with great se-
tices were introduced at a great rate, and one crecy. What they were really doing all that
of the functions that came to the fore was the time, of course, wasn't science--it was engi-
business of writing job descriptions and eval- neering. When this was discovered, a mixed
uating them. Certain industrial relations wave of nausea and terror ran through the
experts fell heir to this function, and there brotherhood. It was worse than being caught
was a tendency for them to write very clear reading a dirty book in church. Most learned
job descriptions for all jobs except their own. scientists knew that engineers were people
It soon became obvious that the value of a who ran around with special hats and oil
job, or, more importantly, the money it paid cans and made steam locomotives go, and
(or even more importantly, its draft-dodging who, incidentally, made too much money. Be-
power), was inversely proportional to the ing identified as part of the same crowd was
ease with which one could describe it. Indus- too much for the intellectuals to bear. Scien-
trial relations people were able to describe tists had to be working on something more
any engineering job in 25 words or less, important than 'engineering,' which is super-
whereas an industrial relations function vised by a Ph.D and is therefore high-class
might take two or three pages. Miserable to and also obvious to those schooled properly,
begin with, engineering salaries were futher but difficult if not impossible for anybody
threatened and so was draft status. else to understand.
Of course, everyone knows that engineers Since, as we all know, very few, if any,
are very creative. They could see that the Ph.Ds understand the meaning of plain, ordi-
industrial relations boys had a good thing nary 'engineering,' it follows that 'systems
going, so they borrowed the approach and engineering' has given engineering a bad
improved on it (typical engineering method). name, and should be avoided for that reason
Soon it took five pages to describe the alone.
most menial engineering task, and the engi- A third group who helped the cause for
neers were saved. It was a simple matter to systems engineering were the pre-war 'hand-
spend three hours explaining to a job analyst book' engineers who discovered creative
from industrial relations why a 'systems engineering when they joined up with a war-
engineering' blueprint file was much more time industrial engineering group to avoid
217
PRE@EDING P.alGE BI.ANK NOT FIL_,_O
being drafted. They had always thought that Moreover, one could dream of performing
engineering was the choosing from a catalog systems engineering at increased hierar-
of the proper washer for a quarter-inch bolt. chical levels by considering at one and the
It was difficult for them to use the same same time not only the quarter-inch bolt, but
name for their new discovery, creative also the half-inch bolt. Advanced systems
engineering (designing a washer for a engineering.
quarter-inch bolt). The term 'systems engi- So much for the history and meaning of
neering' suited well, and groups of people systems engineering. You can demonstrate
were noising it around by then. It sounded the validity of my story to yourself in several
nice and, after all, a quarter-inch bolt is a ways. Your letter, for instance, can be clari-
fastening system of high complexity. It fied by eliminating the word 'systems.' I
consists of a bolt with threads (helical in- believe it appears 10 times. Check the uni-
clined plane), a nut of the proper size, hand versities for courses in systems engineering
and thread configuration (bolt interface and find out what they are really teaching.
problem), external shape (wrench interface Note also that the term 'systems engineer-
problem), one or more washers (structures ing' does not yet appear in an accredited
interface problem), and sometimes even a dictionary. This is because Webster cannot
cotter pin (reliability). figure it out either. Good luck!
218

NASA Readings in SE

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

NASA Readings in SE

Hochgeladen von

Copyright:

Verfügbare Formate

_¢q ..

Edited by Francis T. Hoban

and William M. Lawbaugh

(NASA-SP-6102) REAOINGS IN SYSTEMS N93-24678

Edited by Francis T. Hoban

Scientific and Technical Information Program

Introduction by Francis T. Hoban and William M. Lawbaugh

Author Title Page

Robert A. Frosch A Classic Look at Systems Engineering 1 .*J,_._r

Defense Systems Management Systems Engineering Overview and Process 9

Paul E. Lewkowicz Systems Engineering for 17

Marshall Space Flight What is a System ? NASA 's Phased 23

Tony Fragomeni and Spacecraft Systems Engineering: An 79 :_

Mike Ryschkewitsch Introduction to the Process of GSFC

Owen Morris SE&I and Management for Manned 87

Charles W. Mathews The Systems Engineering Role in

John D. Hodge Cost Considerations in the Systems

John E. Naugle Systems Engineering and User Requirements 127 "

Eugene Kranz and SE&I in Manned Missions

Robert O. Aller Systems Engineering for Operational 157 !

NASA Investigation Board Initial Flight Anomalies of Skyiab I 181 :

NASA Investigation Board The Seasat Failure 201

George Trimble Defining Systems Engineering

by Francis T. Hoban and William M. Lawbaugh

A CLASSIC LOOK AT SYSTEMS ENGINEERING

Editors' Note defined by what is done, not what is said; and

good, bad or nonexistent; that is only a

Defense Systems Management College

PRE(_EDiNG PAGE BLANK NOT FILMED

• What • How • Solutions

Figure I The Systems Engineering Process

THE SYSTEMS ENGINEERING PROCESS use as performance, design, interface,

The output of the systems engineering , Producibility Plan

Technology Selection Factors ____= 1 N° No_

Figure 2 The Systems Engineering Process

allocation (functional performance require- allocation of the functional performance

establishment of gross maintenance con-

Functional Flow Requirements Concept r ............Trade 7w............... Design

Figure 3 Basic and Special Purpose Documentation for Systems Engineering

U.S. Government MIL-STD-499.

WHAT IS A SYSTEM? NASA's PHASED PROJECT / 7J

Systems engineering is defined in MIL-STD- • Many hardware and software systems in

1. Project and Mission Requirements/Need Definition

9. Verification and Validation

8. Technical 3. Systems Analysis

5. Derived Requirements Definition

Figure 1 Systems Engineering Cycle

2. Risk Analysis/Management is a 5. Derived Requirements Definition is

7. Configuration Management activities systems engineer should view these changes

edge capture). the performance requirements of the system

MAJOR MANAGEMENT DECISIONS

• Develop Project • Refine Selected • Develop Detail of • Developand Test

Requirements Areas • Define Support Operations, Supporting

• Perform Trade-Off Manufacturing and Test Long Lead Advance

Figure 2 NASA Program Phases

PRR PDR CDR AR

IPL IPL IPL IPL IPL IPL

Space System Carrier

Notes: PRR - Preliminary Requirements Review RR- RequirementsReview

Figure 3 Typical Program Review Phasing

Planning Systems Analysis Applications

Preliminary Systems Preliminary

Cost Modeling &

Supporting/Advanced Research Estimating