Readings in Systems Engineering

_¢q .. SP-6102 -"

READINGS IN SYSTEMS ENGINEERING

Edited by Francis T. Hoban and William M. Lawbaugh

(NASA-SP-6102) REAOINGS IN SYSTEMS N93-24678 ENGINEERING (NASa) 215 p --THRU-- N93-24693 Unclas

H1/31 0158570 .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

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 READINGS IN SYSTEMS ENGINEERING

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 craftcompany 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 READINGS IN SYSTEMS ENGINEERING

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 A CLASSIC LOOK AT SYSTEMS ENGINEERING

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 ridiculous 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, maintainability 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- A CLASSIC LOOK AT SYSTEMS ENGINEERING

__ 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 READINGS IN SYSTEMS ENGINEERING

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 (nonsense 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, A CLASSIC LOOK AT SYSTEMS ENGINEERING

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" specification 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 READINGS IN SYSTEMS ENGINEERING

IterativeTrade-Offs

Functional Synthesis and Analysis System .ii RequirementsInputLfi '_ R_ EvaluationDecision _] DescriptionElements of t...... i • 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 submitted 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 READINGS IN SYSTEMS ENGINEERING

• 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 • ElectronicWarfare • Computer Resources

Figure 2 The Systems Engineering Process

12 SYSTEMS ENGINEERING OVERVIEW AND PROCESS

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 concepts. 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 READINGS IN SYSTEMS ENGINEERING

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 considerations. 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 _ Id n Synthesis & Decision System ...... Elements I i r! $ ] i _ Evaluation _ Description of L- ...... _J

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 . Equipment ing intersystem • 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 Maintenance Sheet FacilityInterface 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- cilitieson 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 SYSTEMS ENGINEERING OVERVIEW AND PROCESS

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).

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 requirements 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 analysis, performed by the program's Aerospace Application Conference, Park City, Utah, Februa_ I988

17 READINGS IN SYSTEMS ENGINEERING

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 SYSTEMS ENGINEERING FOR VERY LARGE SYSTEMS

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 READINGS IN SYSTEMS ENGINEERING

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, technical 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 SYSTEMS ENGINEERING FOR VERY LARGE SYSTEMS

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 requirement 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 READINGS IN SYSTEMS ENGINEERING

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 agreement 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 principal 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 READINGS IN SYSTEMS ENGINEERING

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 definition 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 READINGS IN SYSTEMS ENGINEERING

MAJOR MANAGEMENT DECISIONS

_I) _¢{2) PRE-PHASE AJ PHASE D PHASE A PHASE B PHASE C DEVELOPMENT/ PRELIMINARY 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 Analysis Requirements and • Identify Research 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 Systems, Facilities, etc. • Develop Gross Plans for Requirements 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 Requirements Estimates of Costs 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 • Preliminary Schedule, Man ufacture Test and 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 T Analysis Phase B Design Development/Operation PreliminaryPhase A Definition T Phase C Phase D

x x I Final Concept Requirements Preliminary Flight 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- IntegratedReadiness 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 Missionand AnalysisPlanning and Analyms

Planning Systems Analysis Applications

"_[ Project Planmng I ,

I r la- _l_ Budget Planning I PlanningProgram 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_[ Program/ScienceRequirements I Requirements Desig.

System_SubsystemsAnalysis &Trades t [ AdvancedRequirementsDevelopment 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 development 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 READINGS IN SYSTEMS ENGINEERING

• 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 generally 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 conscience 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 detailed 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 READINGS IN SYSTEMS ENGINEERING

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 READINGS IN SYSTEMS ENGINEERING

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 requirements 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 maintenance 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 READINGS IN SYSTEMS ENGINEERING

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 management 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 technically 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 units 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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 READINGS IN SYSTEMS ENGINEERING

• 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 describe tbe integration and coordination of the efforts of the specialty engineering disci- SEMP Lessons Learned from DoD Experience 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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 integrated A WBS is a hierarchical breakdown of the • Shows the cost account number of the work necessary to complete a project. The element.

39 READINGS IN SYSTEMS ENGINEERING

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 This section provides some techniques for The whole does more than the developing a WBS, and points out some mis- Subsystem sum of its parts 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 uling J Sy_ • 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 documentation 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 affected, 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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 elements 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 READINGS IN SYSTEMS ENGINEERING

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:.::-_

-: ::::::::::::::::::::::::::::::::::::::::::::::..:.:._..:-:.,':.:.:,,:_.>_:.:.':_.:o:.:.:.:.:.>:.:._.>_:..'-..i_ [ :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::...... ×...:-...... '.---:.'.'.'.._-_...... :...... ×_'"?."...... _ _...... :--."C" ? _...... ?-? :-_---'__"':...... :" ...... - ...... :::::::::::::::::::::-:-:-:.-'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 project 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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 Activity-on-ArrowDiagram 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 i separate activities. last activity can be completed becomes the end ! point for that schedule. Then there is a "back- I 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 PrecedenceDiagram earliest start time and the latest start time of an 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 (e.g.,days) that action. 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 start5days after ActivityA starts. i 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 READINGS IN SYSTEMS ENGINEERING

• Activity B ends when Activity A ends • Ensuring that the cost account WBS is (Finish-Finish, or FF). extended downward to describe all significant 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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 READINGS IN SYSTEMS ENGINEERING

Space Science & Instruments System (Level 2) STIKSCAT PROJECT Approval Subsystem (Level 3) Level 3 Manager Achievement Statusas of:Jan 20,1991 Assembly (Level 4) Level 4 Mana_r RevisionDate:Dec 23,1990 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 " I0....." 9 Design I TO I&T 10 Fabricate ,I , L_ 11 Test .....Im I' P-'- -- l 12 Subassembly #2 , 13 Design i I ..... • • ' TO I&T 14 Fabricate mm I 15 Test ! 16 Subassembly #3 , + 17 Design TO I&T 18 Fabricate I 19 Test ,I _ c___ln ...... 9 I I 20 Integration & Test i REC _ 7 21 Plans I n • F I ALL SUBASSY F 22 Procedttres mm--jI .... 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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 ]_iiil 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

the WBS and network schedule. This specifi- Assessing the Effect of Schedule Slippage 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 processing, 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 READINGS IN SYSTEMS ENGINEERING

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 objective 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

[ Risk Analysis andRiskCharacterizationIdentification /

Figure 6 Risk Management Structure

48 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

systems engineer needs to decide whether risk identification and characterization are Risk 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 systems 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 often a challenge because efforts and expen- PERT) 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 engineer 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 READINGS IN SYSTEMS ENGINEERING

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 reliability 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 another. 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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 READINGS IN SYSTEMS ENGINEERING

• 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 default 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 below, 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 decision 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 estimates 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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 precursor 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).] READINGS IN SYSTEMS ENGINEERING

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 conditions inherent in a project. where Ps is the probability of outcome s, and Cs is the consequence of outcomes. To attach probabilities 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 failure 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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 documented 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 general. 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 management 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 establishing 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 READINGS IN SYSTEMS ENGINEERING

• Track the effectivity of each risk mitiga- • Definition (or specification) of the function 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 control, 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 manager. 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 baseline. The content of the technical baseline Risk management activity must begin includes: early and continue throughout the

56 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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 previously 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 manages 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 encompasses 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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

...... F ...... i- I | Disapprove I Disa _prove Disapprove

Approve Request i Class I Prelim Request [ECP _ F°rmal ECPIr [ PrepareECP _._I DecisionBuyer prove Approve Class II , I No Approve

I Concurrence I with I Buyer j I Classification Yes "III Record Implement Change [_ IndicatesBuyer Action Status Change

Figure 8 Contract Change Control Process

59 READINGS IN SYSTEMS ENGINEERING

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 information). 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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 READINGS IN SYSTEMS ENGINEERING

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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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 READINGS IN SYSTEMS ENGINEERING

• 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

• 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 qualification 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 READINGS IN SYSTEMS ENGINEERING

• 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 READINGS IN SYSTEMS ENGINEERING

• 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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, including 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 READINGS IN SYSTEMS ENGINEERING

This section provides additional infor- Status ] Not OK mation on status reporting and assessment techniques for costs and schedules, technical Planning Reporting Assessing __._[ DecisionMaking L,ReH s tus performance, and systems engineering 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 technical 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 allows 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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 representing 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 generally lower when cost and schedule baselines

ECA do not support Earned Value calculations. Foreosst of 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 17 I number of possible reasons why variance T st gchedule I l [ Varianc_ problems occur: V L [ to Date E _Cost Ver/anc_ [ [BCWP - • A receivable was late or was unsatisfac- [to Date _ BCWS) (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 planned. 0 D0t_j Work Performed J BCWSEV = BudgetedEarned ValueCost of • Unforeseeable (and unlikely to repeat) TIME EAC EstSmate at 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 READINGS IN SYSTEMS ENGINEERING

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 performance 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 factors 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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 studies. In TPM tracking, however, instead of High-level technical performance measures (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 select those TPMs that must fall within well- Mass and power demands by spacecraft subsystems 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 example of such a TPM for a spacecraft is its • Payload mass (at nominal altitude or orbit) • 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 READINGS IN SYSTEMS ENGINEERING

planned profiles or margins below require- (a) Planned Profile Method ments signal potential future problems requiring replanning. If this occurs, then new I cost, schedule and/or technical changes New Allocation should be proposed. Technical changes may T a _ P M Original imply some new planned profiles. This is il- • _ It lustrated for a hypothetical TPM in Figure V All_:ation --'=4

Planned I ll(a). In this example, a significant demon- tl t strated variance (i.e., unanticipated growth) e Margin ¢ -c u V* /Original ml r in the TPM during design and development r Demonat_ated Planned Demonstrated • * T e of the system resulted in replanning at time Variance Profile in t. The replanning took the form of an in- Value q iD _eplannJng la crease in the allowed final value of the TPM Occurred Here It (the "allocation"). A new planned profile was then established to track the TPM over the TIME remaining time of the TPM tracking (b) Margin Management Method program. + 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 occurred when the TPM fell significantly below Margin I the margin requirement. The new higher m 0 Requirement ¢ New Marppn allocation for the TPM resulted in a higher M Requirement _ _. margin requirement, but it also immediately placed the margin in excess of that requirement.

Both of these methods recognize that the Replann_ng Occurred Here final value of the TPM being tracked is uncertain 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 r 1.0 chances of the final value exceeding its allo- o I Green Alert ! g • • • 4_

i $ Zone cation to a low number, for example, five per- el • i¢ i T cent or less. A third method of reporting and 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 replanning at time t occurred when the ,.._:::i_:- probability of the final TPM value being less ::::ii_-_induced by sh_R

than the allocation fell precipitously into the .:::::_ t; .:¢.:< red alert zone. The new higher allocation for ':i::¥ _;:;_l::_..:.._;!_:_;!-':_:':i:!:::!::::::::_::i::"_ Note: Although red- the TPM resulted in a substantial improve- E:_._,'-'_; _:_:'::':_':: _:::-_::_ are _bow_a only ia (cL | D t:::.::_:::_:.<::: _.: :._.: _.::;:: £::: • _:_ :::::::_.::: ::._.: :: ,::::::.:_.:::::::::::::._ correuponding zone_ ment in that probability. _,,:_Y._:._:::'::::_:_:i::_!:_:_!:.'¢-'_-_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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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'sinjectedmass 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 partsand components are builtand 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 lowerand upper bounds and the most likelyinjectedmass to the SEMP. The SEMP is the usual docu- 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 distributionliketheone 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 assessments should be specified as well. [n determining these, the systems engineer must balance the project's needs for accurate, SpacecraftInjectedMass,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 verticalline.The area under the TPM tracking program plan, which elabo- probabilitycurveto theleftofthe 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'spayloadcapability.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 these metrics supplement the cost and sched- example, by removing an instrument or otherwise[ ule control measures discussed earlier. changing mission objectives. The project manager] could also solve the problem by requesting a larger[ Systems engineering process metrics try launchvehicle! J to quantify the effectivityand productivity of

75 READINGS IN SYSTEMS ENGINEERING

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 neering effort, those that measure the qual- completed 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 progress. A subsystem systems engineer completed may focus on subsystem requirements and Functional requirements S approved vs. verified interface definition progress and verification V&V plans approved per P 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 Table2 Systems EngineeringProcessMetrics systems engineering process is not without cost. Status reporting and assessment of systems 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 MANAGEMENT ISSUES IN SYSTEMS ENGINEERING

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.

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 READINGS IN SYSTEMS ENGINEERING

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 r ...... Data Products F'_"l _equirements which • Parametric 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 l Data Product Marglns Conslxaints ] ReqUirements + t Performance [ Subsystem Sot_war e, Design, Teat Verification and .Fabrication, and Metric Conduct I P?o_p.... t Parametric, Assembly. Inspection Flight Segment lntegratmn Functional, Performance Data Syst_m_ Performance and Design and Test Tirneline, Designs and trade-off Specification: I OutputSpecifications ] I • Miseiot_ Performance Analyses to l Requirements Evaluate Each • System Level and Drawings Approach Performance, Operations, and Interface Requirements Lat tch l • Key Subsystem T Performance Baseline system Requiremente Conduct conceptu•ldesign • Verification seO_tirnu rn approach defined: acted on basis of Analyses to • Functional & Requirements Refine the performance, • GSE Requirernents System Desi gn: schedule and coat, Operational Guidelines • Design • Parametric configuration and Descriptions -_ • Block Diagrams • Functional Changes "<-- eompatibilit_t of • Hardware/ • Trade off system phymcal. SoRware functional, and Ground Segment technical Interfaces Characteristics Specification: • Subsystem On-Orbit • Physical • Tirneliue • Component E ngineering and demonstrated I opMeira_i°onns Characteristics • System Acceptance • System Checkout

[--_.- 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 SPACECRAFT SYSTEMS ENGINEERING

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 requirement there is an associated margin that SE ROLES AND RESPONSIBILITIES must continually be challenged. As the project 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 READINGS IN SYSTEMS ENGINEERING

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 technical 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 operational 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 SPACECRAFT SYSTEMS ENGINEERING

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 material 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 specifications: 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 probe 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 progressive 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 READINGS IN SYSTEMS ENGINEERING

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 SPACECRAFT SYSTEMS ENGINEERING

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 READINGS IN SYSTEMS ENGINEERING

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 testing 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 initiated 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 READINGS IN SYSTEMS ENGINEERING

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 READINGS IN SYSTEMS ENGINEERING

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 LevelIII I I I

Orbiter External Tank SRB Project Project Project Project

I SSME A. Cohen J.R. 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 Management International Program Program Engineering & Integration Control Assessments Analysis Programs Group Office Group Group 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 READINGS IN SYSTEMS ENGINEERING

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

Figure 4 Space Station Integration Job

93 READINGS IN SYSTEMS ENGINEERING

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 execution. RELATIONSHIP OF SE&I TO OTHER In preparation for the critical design PROGRAM FUNCTIONS review (CDR), another system characterization 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 requirements. 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 READINGS IN SYSTEMS ENGINEERING

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 products 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

Engineering Integration Mission Management Integration

Element System Integration Integration

Figure 5 Space Station Freedom Technical Review Structure (1990)

.q7 READINGS IN SYSTEMS ENGINEERING

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 development 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 characterizations 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 READINGS IN SYSTEMS ENGINEERING

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) READINGS IN SYSTEMS ENGINEERING

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 predictable 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 significant 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 communications 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 because of early "selling" pressures or because Types of Program Objectives and of unforeseen technical problems When this Requirements happens, the systems engineering organization 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 obtained (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 THE SYSTEMS ENGINEERING ROLE IN TOP-LEVEL REQUIREMENTS

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 secondary 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 NAL MONOGRAPH SERIES: SYSTEMS ENGINEERING PAPERS

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 perceived 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, industrial 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 THE SYSTEMS ENGINEERING ROLE IN TOP-LEVEL REQUIREMENTS

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 NAL MONOGRAPH SERIES: SYSTEMS ENGINEERING PAPERS

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 program 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 situations 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 SYSTEMS ENGINEERING ROLE IN TOP-LEVEL REQUIREMENTS

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 accomplished 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 discussions 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 strategy 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 NAL MONOGRAPH SERIES: SYSTEMS ENGINEERING PAPERS

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 THE SYSTEMS ENGINEERING ROLE IN TOP-LEVEL REQUIREMENTS

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 whether 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 NAL MONOGRAPH SERIES: SYSTEMS ENGINEERING PAPERS

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 READINGS IN SYSTEMS ENGINEERING

design has been established, changes are PROGRAM RISK ANALYSIS proposed and enacted that bear little relationship 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 COST CONSIDERATIONS IN THE SE PROCESS

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 feasibility 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 READINGS IN SYSTEMS ENGINEERING

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 COST CONSIDERATIONS IN THE SE PROCESS

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 responsibility 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 considered 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 maintain 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 functional 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 READINGS IN SYSTEMS ENGINEERING

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 accountable 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 COST CONSIDERATIONS IN THE SE PROCESS

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 being 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 READINGS IN SYSTEMS ENGINEERING

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 COST CONSIDERATIONS IN THE SE PROCESS

breakdowns known as the unique project THE INSTITUTION AND THE PROGRAM number (UPN) system. All parts of the agency 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 multiple 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 READINGS IN SYSTEMS ENGINEERING

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 another 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 COST CONSIDERATIONS IN THE SE PROCESS

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

USERREQUIREMENTS 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 READINGS IN SYSTEMS ENGINEERING

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 preflight 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 READINGS IN SYSTEMS ENGINEERING

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 responsible 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 READINGS IN SYSTEMS ENGINEERING

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 reduce 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 READINGS IN SYSTEMS ENGINEERING

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 scientists 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 publication 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 READINGS IN SYSTEMS ENGINEERING

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 development, 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 principal 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 READINGS IN SYSTEMS ENGINEERING

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 requirements 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 READINGS IN SYSTEMS ENGINEERING

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 READINGS IN SYSTEMS ENGINEERING

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 consisting 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 spacecraft. 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 needed. 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 READINGS IN SYSTEMS ENGINEERING

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, selected 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 operat 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 development, 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 system 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 READINGS IN SYSTEMS ENGINEERING

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 Trajectory Data Flight MCC Design Build (L ! 3 to L-6) Desic_n (L-4½ to 2½) Constratnts "light Definition Data (I-Loads)

Flight-unique MCC Release Orbiter/Payload / Flight Mass Properties Software Generation (L-7 to L-4)

Orbiter and Orbiter and Payload TLMICMD Rqmts _-- Flight-unique (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 READINGS IN SYSTEMS ENGINEERING

ENGINEERING I ENG RFIT CYCLE I SUPER I-L MMU ENG ENG Ist TAPE CR SDTF Rl CYC CYC I STAGE SMS I-L STAND FLT TDDP FOP LO TDDP CIR RDY ALONE RFIT I [I I-L SMS 351 323 309 288 228 _14 186 161 77 42 / 193 7O 260 221 175 FLT

FLT CYC I-L ALT SMS

ASC Ist FPSR C R 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 I 1 I CYCLE I I--I I I I 284 270 228 207 179 140 109 88 70 42 o

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 imposed 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 READINGS IN SYSTEMS ENGINEERING

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 contained 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 READINGS IN SYSTEMS ENGINEERING

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 SUPPORTSUPPORTSCHEDULING • MISSION RISK/GAIN POLICY

U_ERJCU!OMERdP01(r SCF/POCC/ESC/P01( _ • COMMUNICATION AND DATA /SI _:_ii_:::: L, V E RiE 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 READINGS IN SYSTEMS ENGINEERING

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, tracking, 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 NAL MONOGRAPH SERIES: SYSTEMS ENGINEERING PAPERS

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 SYSTEMS ENGINEERING FOR OPERATIONAL SUPPORT SYSTEMS

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 NAL MONOGRAPH SERIES: SYSTEMS ENGINEERING PAPERS

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 SYSTEMS ENGINEERING FOR OPERATIONAL SUPPORT SYSTEMS

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 NAL MONOGRAPH SERIES: SYSTEMS ENGINEERING PAPERS

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 required 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 within 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 POLITICAL AND INSTITUTIONAL FACTORS OF SE

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 management 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 READINGS IN SYSTEMS ENGINEERING

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 POLITICAL AND INSTITUTIONAL FACTORS OF SE

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 technology. 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 READINGS IN SYSTEMS ENGINEERING

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 understand 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 techniques 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 DefinitionMission RequirementsSystem _ ConceptualDesign _ PreliminaryDesign 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 READINGS IN SYSTEMS ENGINEERING

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 performing menial tasks. _ Multidisciplinary

Evaluate

Initial Subject to Configura- Analysis [F//__is Configura- tion cution t ConstraintsoptiH f

Figure 3 Preliminary Design

Figure 2 Conceptual Design The former process was basically eliminated 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 ConceptualDesig_ 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 conducted 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 READINGS IN SYSTEMS ENGINEERING

" 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 probe 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 whether the outside decision is being made concurrently with the optimization or whether it lags the optimization by days, weeks or months.

LJIN vI U Figure 6 Hierarchy of Decisions to Select a Navigation System for an Airplane

Figure 7 Trade Studies with Optimization The illustration above (Figure 6) is a simple 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 READINGS IN SYSTEMS ENGINEERING

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 I

Unique to AllocatableElementsbetween I Element 1 [ 1

Allocatable Unique to between Subsys Subsystem

Allocatable Unique to between Comp Component

Figure 8 Requirements Flowdown

178 OPTIMIZATION IN THE SYSTEMS ENGINEERING PROCESS

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 READINGS IN SYSTEMS ENGINEERING

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 Module ° o Sleep Compartment

Saturn Workshop Airlock Modu

Figure 1 SkylabCluster

183 READINGS IN SYSTEMS ENGINEERING

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) Weight 6,260 kilograms (13,800 lbs.)

AM Airlock Module Diameter STS 3 meters (10 feet) Diameter FAS 6.6 meters (21.7feet) Length 5.3 meters (17.5 feet) Weight 22,226 kilograms (49,000 lbs.)

IU Instrument Unit Diameter 6.6 meters (21.7 feet) Length 0.9 meter (3 feet) Weight 2,064 kilograms (4,550 Ibs.)

OWS Orbital Workshop Diameter 6.6 meters (21.7 feet) Length 14.6 meters (48.5 feet) Weight 35,380 kilograms (78,000 lbs.)

S-II Second Stage Diameter 10 meters (33 feet) Length 24.8 meters (81.5 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 READINGS IN SYSTEMS ENGINEERING

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 single 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 READINGS IN SYSTEMS ENGINEERING

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 particular 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

_ ForwardShocks 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 protection 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 excessive 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 READINGS IN SYSTEMS ENGINEERING

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 developed 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 _ iSituationat62.85 at62.90

SAS-2

SAS- 1

I I Situation at 63.4 Situationat63.70 i

Figure 4 -- Postulated Sequence Failure Mode

193 READINGS IN SYSTEMS ENGINEERING

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 status; 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 essentially 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 pressureson 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 loadson 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 READINGS IN SYSTEMS ENGINEERING

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 replaced 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 READINGS IN SYSTEMS ENGINEERING

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 personnel 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 READINGS IN SYSTEMS ENGINEERING

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 inflight 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 READINGS IN SYSTEMS ENGINEERING

_,'_,'_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, including a review of instrumentation and pos- PROGRAM PLANNING sible spacecraft (bus) approaches to accommodate 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 READINGS IN SYSTEMS ENGINEERING

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 reports 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 READINGS IN SYSTEMS ENGINEERING

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 consideration 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, independently 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 inspections 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 READINGS IN SYSTEMS ENGINEERING

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 assemblies 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 READINGS IN SYSTEMS ENGINEERING

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 wiring 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 READINGS IN SYSTEMS ENGINEERING

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 relying 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

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 READINGS IN SYSTEMS ENGINEERING

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