Space Mission Design Process

1. Space Mission Design Process with your host… Dr. Hyland

2. 426, Lecture 2 - Questions Addressed • What are the life-cycle phases of a space mission and which phase and point of view will we consider? • What are some systematic approaches to space system design and analysis? • What approach will we take and what are the steps involved? • How will the class be organized to carry out these steps and what is the schedule of events? Suggested reading: L&W, Chapter 1 (and Chaps. 2 and 3 for more detail)

3. The Space Mission Life Cycle - Four Phases Concept exploration: The initial study phase that results in a broad definition of the mission and its components Detailed development: The formal design phase which results in a detailed definition of the system components and, in larger programs, development of test hardware or software. Production and deployment: The construction of the ground and flight hardware and launch of the first full constellation of satellites. Operations and support: The day-to-day operation of the space system, its maintenance and support, and finally its de-orbit or recovery at the end of the mission life.

4. Various parties & constituencies: Sponsor: The group that provides and controls the program budget Operators: The group (typically an applied engineering organization) that controls and maintains the space and ground assets End users: Groups who receive and use the products and capability of the space mission Developer: The procuring agent, e.g. DOD, NASA or a commercial enterprise In this class, we concentrate on the Concept Exploration Phase from the point of view of the Contractor - Developer

5. Space Mission Analysis and Design Process - The Eightfold Path -

6. Step A: Define Broad Objectives and Constraints • Define what the mission needs to achieve. What are our qualitative goals and why? • The qualitative goals are summarized in the Mission Statement - a 3 to 4 sentence, crisp and cogent statement of overall goals. • This is the all-important starting point. We need to repeatedly refer back to the Mission Statement to ensure we remain "on track". • Usually, missions have several objectives. Besides the primary objectives, there may be secondary objectives that can be met by the defined set of equipment, or additional objectives that may demand more equipment.

7. Almost always, missions have a hidden agenda - which consists of secondary non-technical, objective, frequently of a political, social or cultural nature. • Example: • To forestall existential threats to humanity, our mission is to develop self-sustaining, self-propelled space habitats based on realistic technology. (Some hidden agendas: Boost space activity, encourage public interest and support for space exploration, imply economic benefits, etc.)

8. Step B: Estimate Quantitative Mission Needs and Requirements • In contrast to Step A, this quantifies how well we wish to achieve the broad objectives, given our needs, applicable technology and cost constraints. • These quantitative requirements should be subject to trade as we go along. In the early stages of design, it is very important not to set these requirements "in concrete". • To transform mission objectives into requirements, look at three broad areas:

9. Functional requirements, which define how well the system must perform to meet its objectives. • Operational requirements, which determine how the system operates and how users interact with it to achieve its broad objectives. • Constraints, which limit cost, schedule and implementation techniques available to the system designer. • Establishing top-level mission requirements is extremely difficult. Therefore, we should be prepared to iterate the numerical requirements many times in the design process. • The first estimate of requirements should come from the goals and objectives combined with some view of what is feasible. Then be prepared to iterate. • Also, look at the "hidden agenda", which contains the implicit goals and constraints.

10. Quantitative requirements – Interplanetary Vehicle / Space habitat design Example: Habitat population capacity = ? Amount of artificial gravity provided =? Radiation shielding capability = ? Resource extraction capability = ? Total V capability without refueling = ?

11. Step C: Define Alternative Mission Concepts As used here (as distinct from the usage in Larson and Wertz) a mission concept or architecture is a broad sketch of how the mission will work plus a definition of each of the principal components of a space mission: Subject: The thing that interacts with or is sensed by the space payload. Spacecraft or Space Segment: The self-contained portion that resides in space to carry out the mission long-term, comprising: Payload: The hardware and software that sense or interact with the subject. Spacecraft Bus: Subsystems that support the payload by providing orbit and attitude maintenance, power, command, telemetry and data handling, structure and rigidity and temperature control.

12. Launch System: Includes the launch facility, launch vehicle and any upper stage required to put the spacecraft in orbit as well as interfaces payload fairing and ground support. Orbit: The spacecraft's trajectory or path. Usually, there is an initial parking orbit, a transfer orbit and final mission orbit. Communications Architecture: The arrangement of components that satisfy the mission's command, control and communication (C3) requirements. Ground System: Fixed or mobile ground stations used to command and track the s/c, receive and process data and distribute the information to operators and users. Mission Operations and Timeline: The overall strategy and schedule for planning, building, deployment, operations, replacement and end-of-life.

13. Process for Identifying Alternative Mission Concepts • Five Steps: • Identify the mission elements subject to trade • 2. Identify the main options for each tradeable element • 3. Construct a trade tree of available options. • 4. Prune the trade tree by eliminating unrealistic combinations. • 5. Look for other alternatives that could substantially influence how • we do the mission

14. Trade Tree – Basic Concept (illustrated by the manned asteroid mission ) Mission Phase Alternatives for each mission phase Launch single vehicle Separate vehicle and crew Assemble mission on-orbit Launch-to-orbit Earth orbit to Asteroid vicinity Chemical propulsion Low thrust Chemical propulsion Low thrust Chemical propulsion Low thrust Proximity Operations Standoff mode Landing mode Combo Etc. … Each line connecting one “node” at each level marks out a distinct design

15. Propulsion system mass Trip Time Solar sail Electric propulsion Chemical Tradeoffs – Choosing one branch of the tree (Earth orbit to Asteroid vicinity)

16. Launch single vehicle Standoff mode Separate vehicle and crew Landing mode Assemble mission on-orbit Combo The above diagrams showed fully branched trade trees – i.e., where each option at a given level branches to all the possible options at the next level. In practice, only the distinct alternatives at each level are shown. Using this convention, previous diagrams look like: Alternatives for each mission phase Mission Phase Launch to orbit Earth orbit to Apophis vicinity Chemical Propulsion Low thrust Proximity operations A line connecting one option at each level marks out a distinct design

17. TRADES LIST These suggested possibilities are not claimed to be comprehensive. They are offered to help start the thought process

18. TRADES LIST These suggested possibilities are not claimed to be comprehensive. They are offered to help start the thought process

19. TRADES LIST These suggested possibilities are not claimed to be comprehensive. They are offered to help start the thought process

20. Step D. Identify System Drivers for Each Mission Concept 1. In any real system, overall cost and performance or the design of detailed components are mainly influenced by a relatively small number of key parameters or components (which the user or designer can control) - called drivers 2. In this step, we identify the cost and performance drivers for each alternative system concept. 3. For most missions, system drivers include the number of satellites, altitude, power, instrument size and weight 4. In identifying the drivers, we must clearly determine whether we are looking for drivers of performance, cost, scheduleor risk. 5. The results of this step tell us where to put most of our effort when we do detailed performance estimation for each mission concept in the next step.

21. More on “Drivers” There are two qualitatively distinct Characterizations of a system design: Quality or Performance: Measures of how well the system performs its mission. “How good it is going to be”. Burden or Penalty: Usually summarized in the cost. Also: Schedule, risk. This is what we have to pay in order to get the performance offered by the design. In addition, both of these types of measurements have uncertainty attached to them. The decision-maker needs to know: How good is it going to be; what’s the price, and how sure are you of both? Distinct from Quality and Burden (or Performance and cost) are design parameters – e.g. size and power of communications antenna, size/weight of transponder unit, propulsion system thrust, etc. Performance and cost describe the utility of the design and are functions of the design parameters. Design Drivers are those design parameters that most sensitively affect Performance or Cost (or other selected measures of quality and burden). One says: “This parameter is a cost driver” or “This is a performance driver”. Not: “Cost is a design driver”, etc.

22. Step E: CharacterizeMissionConcepts 1. This step defines in detail what the system is and does. We determine the power, weight and pointing budgets and decide what to process on the ground or in space. 2. The objective here is to define the mission concepts in enough detail to allow meaningful evaluations of effectiveness and the relative merits of the various concepts and architectures. Process for characterization: There are a variety of processes used - see Larson and Wertz, Section 2.4 -- but, in the case of Mission to Apophis, we suggest you follow the outline provided by the TECHNICAL APPROACH STUDY PRODUCTS LIST given in this lecture

23. TECHNICAL APPROACH STUDY PRODUCTS LIST • 1. Mission System Description (including at least the following) • 1.1 Launch components to LEO, integrate and travel to operating station - Sequence of Events • 1.2 Overview of all system elements • 1.3 Mass lists and power requirements, including at least current best estimate and identification of mass and power growth rationale for margin levels, power budgets should identify power utilization and margins during critical mission phases • 1.4 Functionality • 1.5 Block diagrams for system and critical subsystems • (where appropriate) • 1.6 Computing needs and margins • 1.7 Degree of autonomy

24. 1.8 Identification of all relevant margins, including mass margin above expected mass including growth contingency • 1.9 Heritage assumptions • 1.10 Critical interface properties • 1.11 Robustness to off-nominal conditions • 1.12 Redundancy, treatment of single point failures • 2. Required Infrastructure • 2.1 Deep Space Network tracking requirements • 2.2 Requirements at Apophis(telecom network is one example) • 3. Operations • 3.1 Operations concept • 3.2 Operations development • 3.3 Command & control team composition and responsibilities

25. 3.4 Operations margins (for example, up and downlink system buffers and required data download intervals) • 3.5 Operations phase flow diagram showing data and command flow to and from system • 4. Technology • 4.1 Assumed performance for advanced technology elements and basis of assumptions • 4.2 Fallback options if technology performance is not achieved and impact • 4.3 Required technology demonstrations

26. 5. Cost and Schedule • 5.1 Overall mission schedule including development, integration and test, and operations • 5.2 Overall development cost, and cost profile per development phase and per NASA fiscal year • 5.3 Assumptions regarding benefits from duplicating systems flown in technology demonstrations • 5.4 Cost and schedule risk, cost uncertainty • 5.5 Basis of cost (nominal and uncertainty) and cost estimating methodology (analogy, parametric, • grass-roots are some examples) • 5.6 Identify schedule and cost reserves • 5.7 Cost elements (estimates not required) for technology development and demonstration and for mission operations

27. Step F: Identify Driving Requirements • Having defined and characterized the alternative mission concepts, we return in this step to our initial quantitative requirements and identify the driving requirements. • These are the key requirements principally responsible for determining the cost and complexity of the system. • This step forces us to get a deep understanding of the relationships between the system design drivers and the driving requirements. These are the all-important "pressure points" in the design.

28. We can use this understanding to see how to improve chances of success by: • Striking a compromise in the initial requirements. • Finding potential technology advances in subsystems areas that relieve the system drivers. • Identify new approaches that circumvent the drivers. • The end result of this step is to revisit the requirements in the light of the drivers and revise as necessary.

29. The Mission Analysis Hierarchy

30. Step H: Define Mission Concept (Baseline) • Having evaluated alternative designs and done a preliminary assessment of mission utility for each, we select one or more system designs. • A baselinedesign is a consistent definition of the system that meets most or all of the mission objectives. • A consistent system definition is a single set of values for all of the system parameters that fit with each other

31. In designing a space system, many parameters are being defined and changed simultaneously. The baseline provides a temporary milestone against which to measure progress. • It also allows us to limit the number of options that must be evaluated. Rather than looking at all possible combinations and variations of parameters, it is much more feasible to look at the impact of varying several of the more important parameters relative to one or two baseline designs. • As the system design matures, the baseline becomes firmer and eventually becomes the system design.

32. Uncertainty and PredictionSee: N. N. Taleb, The Black Swan, Random House, 2010 • History is dominated by Black Swan events. A Black Swan three attributes: • It lies outside the realm of regular expectations, because nothing in the past can convincingly point to its possibility • It carries an extreme impact • Despite its outlier status, human nature makes us concoct explanations for it after the fact

33. Uncertainty and PredictionSee: N. N. Taleb, The Black Swan, Random House, 2010 • We tend to both tunnel and think “narrowly” (epistemic arrogance). We ignore “unknown unknowns” • There is an ingrained tendency in humans to underestimate outliers – or Black Swans • Our prediction record is highly overestimated – many people who think they can predict actually can’t • Not only have forecasters generally failed dismally to foresee the drastic changes brought about by unpredictable discoveries, but incremental change has turned out to be generally slower than forecasters expected.

34. Uncertainty and PredictionSee: N. N.Taleb, The Black Swan, Random House, 2010 • Mediocristan model of the process of discovery: Someone sits in a cubical and concocts the discovery according to a timetable • Classical model of real discovery: You search for what you know (say, a new way to reach India) and find something you didn’t know was there (America). • Almost everything of consequence is the product of serendipity • Serendipity was coined in a letter by Hugh Walpole, who derived it from a fairy tale, “The Three Princes of Serendip”. These princes “were always making discoveries by accident or sagacity, of things which they were not in quest of.” • Example: In 1965 two radio astronomers at Bell Labs, New Jersey, discovered the cosmic background microwave radiation (which revived the big bang theory)

35. Uncertainty and PredictionSee: N. N.Taleb, The Black Swan, Random House, 2010 • Forecasting fallacies: • First Fallacy: Neglecting variability. Taking a projection too seriously, without heeding its accuracy. • For planning purposes, the accuracy in your forecast matters far more than the forecast itself. • Don’t cross a river if it is four feet deep on average • Second fallacy:Failing to take into account forecast degradation as the projected period lengthens • We tend to underestimate the difference between the near and far futures • Look at forecasts made in 1975 about the prospects for the new millennium • Third fallacy: Misunderstanding the random character of the variables being forecast • Owing to the Black Swan, these variables can accommodate far more optimistic – or far more pessimistic – scenarios than are currently expected • Statistics of Mediocristan = Gaussian. Statistics of Extremistan = Mandelbrotian

36. Uncertainty and PredictionSee: N. N. Taleb, The Black Swan, Random House, 2010 • Some tips for dealing with uncertainty: • At the start, try to imagine all possible design options. Don’t commit prematurely to one option (based on linear prediction). • Build in redundancy (duplicative and functional redundancy) • Tally up all “grey swans” (known unknowns), as well as Mediocristan uncertainties. • For each set of design options, try to identify the worst cases (in Extremistan) • Now identify the worst cases that produce the least damage. This mini-max, robust design, is your design. It is armed against uncertainty • Be prepared for Black Swans (negative or positive)

37. Design Process and Class Teaming Arrangements

38. THE END