Chapter 29: Mission Design — From Requirements to Architecture

"The last ten percent of performance generates one-third of the cost and two-thirds of the problems." — Norman R. Augustine, Augustine's Laws

Overview

For twenty-eight chapters you have been sharpening tools. You can compute the delta-v to reach orbit and the delta-v to transfer between orbits. You can size an engine, choose a propellant, and read the mass ratio the rocket equation demands. You can budget power, radiate away heat, close a link across the solar system, and point a spacecraft to a fraction of a degree. Each of those is a piece. This chapter is where the pieces stop being separate and become a mission.

Mission design is the discipline of turning a goal — "provide broadband to a whole continent," "land two tonnes of cargo on the Moon," "map Mars from orbit for a decade" — into an architecture: a specific orbit, a specific delta-v budget, a specific spacecraft with sized subsystems, a specific launch vehicle, and a plan to fly it, each choice tightening the others until the whole thing closes on a single design you could actually build and launch. It is the most intellectually demanding activity in spaceflight, not because any one calculation is hard, but because none of the calculations can be done alone. A heavier camera needs more power; more power needs a bigger solar array; a bigger array is more mass; more mass needs more propellant to move; more propellant needs bigger tanks, which are more mass again — and every loop of that reasoning runs through the rocket equation, which punishes mass exponentially. Mission design is the art of chasing those loops until they settle.

This is the synthesis chapter of the book. Everything before it converges here, and everything after it is either a specialized tool for the process (launch vehicles in Chapter 30, reliability in Chapter 32) or a full worked application of it (the Mars mission of Chapter 34; your own capstone in Chapter 40). We will meet all six of the book's themes at once, because mission design is exactly the place where they collide.

In this chapter, you will learn to:

• Walk the mission-design funnel — objective → requirements → orbit → trajectory → spacecraft → launch vehicle → operations → cost — and see why it iterates rather than flows straight down.
• Write a good requirement, flow requirements down through the system, and run a trade study to decide between competing architectures.
• Formalize the delta-v budget as the master constraint, and roll it up — with margins — into the number that sizes your vehicle.
• Apply mass, power, and delta-v margins the way real programs do: generous early, disciplined late.
• Use systems engineering to trace the mass–power–cost coupling and pick out the one driving requirement that sizes your mission.
• Place your design on the review timeline — MDR, PDR, CDR — that every real mission must pass.

Learning Paths

🚀 Space Enthusiast: Read 29.1 for the big picture of how a mission gets designed, then 29.3 (the delta-v budget as the master constraint) and 29.5 (why everything is connected to everything). These are the two ideas that will change how you read every mission announcement from now on.

📐 Engineering Student: Read all of it; this chapter is the connective tissue for Parts I–IV. Do the trade study in 29.2 and the sizing calculation in the Checkpoint by hand — they are the core skill of the whole discipline, and the capstone (Chapter 40) assumes you can do them cold.

🎮 KSP Player: You already run this loop every time you build a craft and discover it is too heavy for your launcher. Sections 29.3 and 29.4 name what you have been feeling: the delta-v budget and the margins. The mass–power–cost spiral of 29.5 is the "why does adding one more part ruin everything" problem, formalized.

🛰️ Industry Prep: This is the chapter that sounds most like the job. Requirements, trade studies, margins, and the MDR/PDR/CDR gates of 29.6 are the daily language of a spacecraft program. Learn the vocabulary here; you will use it in every review room you ever sit in.

29.1 The mission-design process

Every mission begins as a sentence. "Image the entire Earth's landmass in visible light every day." "Keep a hundred people connected from a single point over the equator for fifteen years." "Return a sample of an asteroid." That sentence is the objective, and it is the only thing on the page that comes from outside engineering — it comes from a scientist, a business, a government, a need. Everything else in a mission is derived from it. The job of mission design is to run a disciplined chain of derivations from that one sentence down to hardware.

Definition (mission design). Mission design is the process of converting a mission objective into a complete, self-consistent architecture — orbit, trajectory, spacecraft, launch vehicle, and operations plan — in which every subsystem is sized to meet the requirements and every choice is consistent with every other. Its output is a design that closes: one that can be built, launched, and flown within its mass, power, delta-v, cost, and schedule constraints.

The chain has a characteristic shape — a funnel. At the top it is wide and abstract; at the bottom it is narrow and concrete. Here is the funnel for a communications satellite, with the chapters that supply each step:

  OBJECTIVE          "Broadband to one continent, fixed users, 15-year service."
      |   (what must be true for that to happen?)
      v
  REQUIREMENTS       coverage area, data rate, availability, lifetime, cost cap ...
      |   (where must it fly to satisfy them?)
      v
  ORBIT              geostationary, at a fixed longitude              (Ch. 9)
      |   (how does it get there and stay there?)
      v
  TRAJECTORY & Dv    GTO -> GEO, then 15 yr of station-keeping        (Ch. 3, 10)   <== delta-v BUDGET
      |   (what hardware provides all this?)
      v
  SPACECRAFT         power, thermal, comms, GN&C, propulsion, structure   (Part IV)
      |   (what puts that spacecraft into orbit?)
      v
  LAUNCH VEHICLE     chosen by the wet mass it must lift to GTO       (Ch. 30)
      |   (how is the whole thing operated?)
      v
  OPERATIONS         control, station-keeping, end-of-life disposal   (Ch. 31, 35)
      |
      v
  COST               the single number that decides whether it flies at all

Read top-to-bottom, the funnel looks like a tidy waterfall: each stage hands its output to the next. And for a first pass, that is exactly how you work it — objective sets requirements, requirements pick an orbit, the orbit sets the delta-v, the delta-v and the payload size the spacecraft, the spacecraft's mass picks the launch vehicle, and the sum sets the cost. You could do it on a napkin, and mission designers often do, precisely to get a rough feel for whether an idea is even plausible before spending real money on it.

⚠️ Common Misconception: "Design flows straight down the funnel." It never does. The arrows also go up. Suppose the spacecraft you sized in the middle turns out to be too heavy for any affordable launch vehicle at the bottom. Now you must go back up and change something: accept a smaller payload (loosen a requirement), choose a different orbit (a lower one is cheaper to reach), or pick a higher-efficiency engine (change the trajectory hardware). Each trip down the funnel teaches you something that sends you back up to revise an earlier choice. Real mission design is not a waterfall; it is a spiral — the same funnel traversed again and again, each loop closer to a design that closes.

That spiral is the reason mission design is a discipline and not a checklist. The order of the funnel tells you the dependencies — you cannot size the spacecraft before you know the delta-v, and you cannot know the delta-v before you pick the orbit — but the iteration is where the engineering lives. A good mission designer is someone who has run enough loops to guess, early, which choices will matter and which will not, so that the spiral converges in three iterations instead of thirty.

🔗 Connection: The four tracks of the Design Your Mission project are four different objectives feeding the same funnel. Track A (a GEO communications satellite) is the worked example of this chapter. Track B (a lunar cargo lander), Track C (a Mars science orbiter), and Track D (an asteroid rendezvous) run the identical process with different numbers — a different orbit, a different delta-v budget, a different driving requirement. The process is universal; only the sentence at the top changes.

We will spend the rest of the chapter putting rigor into the three most important boxes of the funnel: the requirements and trade studies that fill the top (29.2), the delta-v budget that anchors the middle (29.3–29.4), and the systems engineering that closes the whole thing (29.5) — before placing the design on the review timeline every real program follows (29.6).

29.2 Requirements and trade studies

The gap between "provide broadband to a continent" and a piece of hardware is bridged by requirements. A requirement is not a wish or a goal; it is a precise, testable statement of something the system must do or must be, written so that at the end of the program you can point to a test and say yes, it meets this or no, it does not.

Definition (requirement). A requirement is a single, testable, verifiable statement of a capability or constraint the system must satisfy. Good requirements are written with "shall" ("the spacecraft shall provide 8 kW to the payload at end of life"), are unambiguous, and are verifiable — by test, analysis, inspection, or demonstration. A requirement you cannot verify is a wish in disguise.

Requirements come in families. Functional requirements say what the system must do ("shall relay data between ground terminals"). Performance requirements attach numbers to the functions ("shall provide a downlink of at least 50 Gbps"). Constraint requirements fence in the solution ("shall fit within a 5 m payload fairing"; "shall cost no more than \$300 million"; "shall comply with the 25-year disposal rule of Chapter 35"). And crucially, requirements form a hierarchy: a small number of top-level mission requirements flow down into many system requirements, which flow down again into hundreds of subsystem requirements.

Watch a single requirement flow down. "Provide broadband to one continent" is a mission requirement. Flow it down one level: to cover a continent from a single fixed point, the spacecraft shall operate in geostationary orbit (a system requirement about the orbit — see Chapter 9). Flow that down: to reach and hold GEO for fifteen years, the propulsion subsystem shall provide about 2.6 km/s of delta-v (a subsystem requirement — we will compute it in 29.3). Flow again: to provide that delta-v to a 1.5-tonne spacecraft, the tanks shall hold roughly 2 tonnes of propellant (a component requirement). Each level is derived from the one above by an engineering calculation, and each is verifiable. This is requirements flow-down, and it is the skeleton on which a whole design hangs.

🧩 Productive Struggle. Before reading on: "the spacecraft shall be reliable" — is that a good requirement? What about "the spacecraft shall achieve a probability of mission success of at least 0.90 over 15 years"? What is the difference, and why does it matter to the engineer who has to build the thing?

The first is useless and the second is a requirement, because the second can be verified (by the reliability analysis of Chapter 32) and the first cannot. "Reliable" is an adjective; "0.90 over 15 years" is a target you can design toward and test against. The single most common failure in real programs is a requirement that sounds meaningful but cannot be verified — it survives all the way to the review where someone finally asks "how would we ever check that?" and the schedule pays for the answer.

Trade studies: choosing between architectures

Requirements tell you what the mission must achieve. They almost never tell you how — there are usually several architectures that would satisfy the same requirements, and choosing among them is the job of a trade study.

Definition (trade study). A trade study is a structured comparison of competing design options against a common set of weighted evaluation criteria, used to make and document a design decision. It lists the options, scores each against each criterion (mass, cost, risk, schedule, performance, heritage), and makes the winning choice — and the reasoning — explicit and reviewable.

The value of a trade study is not that it produces a number; it is that it forces the reasoning into the open, where it can be checked and, later, remembered. Let us run a real one. Our comsat must climb from its drop-off in geostationary transfer orbit (GTO) to its operational geostationary orbit (GEO), and then hold station for fifteen years. That is roughly 2.6 km/s of delta-v (29.3 justifies the number). How should the spacecraft provide it? Two architectures compete.

Option 1 — chemical propulsion. A bipropellant apogee engine, specific impulse around 320 s. High thrust: the orbit-raising is done in a few burns over days. But its exhaust is slow, so by the rocket equation it needs a lot of propellant.

Option 2 — electric propulsion. A xenon Hall thruster, specific impulse around 1,800 s (see Chapter 20). Its exhaust is roughly six times faster, so it needs far less propellant — but its thrust is tiny, so orbit-raising is a slow spiral lasting months.

We size each with the rocket equation (the calculation of the Checkpoint), delivering 2.6 km/s to a 1,500 kg dry spacecraft:

The electric option is dramatically lighter — about 250 kg of xenon against more than two tonnes of bipropellant — which through the funnel means a smaller, cheaper launch. That mass saving is why most new GEO communications satellites are now all-electric or hybrid. But the trade is not free: those extra months of slow spiraling to station are months the satellite earns no revenue and sits longer in the radiation of the Van Allen belts. There is no universally "right" answer; there is the answer that best fits this operator's weighting of mass against time against risk. The trade study is where that weighting is made honest.

Definition (driving requirement). The driving requirement is the single requirement that most constrains the design — the one whose small change ripples into the largest change in mass, cost, or feasibility. Finding it early is the highest-leverage move in mission design, because it tells you where to spend your engineering effort and your margin.

For our comsat, the fifteen-year lifetime is a strong candidate for the driving requirement: it sets the station-keeping propellant, which is a large fraction of the wet mass, which sets the launch vehicle, which dominates the cost. Halve the required lifetime and the whole vehicle shrinks; double it and the design may not close at all. A designer who identifies that early will interrogate the fifteen-year number hard — is it really fifteen, or would twelve satisfy the business case at far lower cost? — before optimizing anything else.

🔄 Check Your Understanding 1. Rewrite this bad requirement as a good one: "The satellite shall have plenty of power." 2. In the trade study above, which architecture wins if the operator weights time-to-revenue far above launch mass? Why is there no single correct answer?

Answers

1. Something verifiable with a number and a condition, e.g. "The electrical power subsystem shall deliver at least 8 kW to the payload bus at end of life (15 years), in worst-case eclipse." It has a quantity, a condition, and a way to test it. 2. Chemical wins on time-to-revenue — it reaches station in days, not months, so the satellite starts earning almost immediately. There is no single correct answer because the "best" option depends on how the operator weights the criteria; the trade study's job is to expose that weighting, not to hide it inside one number.

29.3 The delta-v budget as the master constraint

Of all the budgets a mission tracks — mass, power, data, pointing, cost — one sits above the rest, because it is the one that, through the rocket equation, sizes the vehicle itself. It is the delta-v budget, and you have been building yours since Chapter 3. Here we promote it from a running tally to the formal master constraint of the whole design.

Definition (delta-v budget, formalized). A delta-v budget is the itemized, margined sum of every velocity change a mission requires — launch, transfers, plane changes, orbit insertion, station-keeping, disposal — collected into a single total 🔗 (the concept was introduced in Chapter 3, §3.6). It is the master constraint because it is the one budget that converts, through $\Delta v = v_e \ln(m_0/m_f)$, into a required propellant mass, and propellant mass dominates the wet mass of almost every space vehicle. Get the delta-v budget wrong and no amount of subsystem cleverness can save the mission; get it right and everything downstream has a number to size against.

Why does this one budget rule the others? Follow the chain. The delta-v budget is a velocity; the rocket equation turns a required velocity into a required mass ratio, $m_0/m_f = e^{\Delta v/v_e}$; the mass ratio times the dry mass gives the wet mass; the wet mass picks the launch vehicle; the launch vehicle is a large share of the cost. Every link is exponential in the first one. That is what "master constraint" means: a small error at the top of that chain is amplified, through an exponential, into a large error in mass and cost at the bottom. No other budget has that leverage.

Building the budget: a mission is a route across the delta-v map

To build a budget, trace your mission's path across the delta-v map of Chapter 3 (collected for reference in Appendix G) and sum the legs. It helps to split the budget by who pays for each leg — the launch vehicle or the spacecraft's own propulsion — because those are two different pieces of hardware sized separately.

Here is the full budget for our GEO comsat, launched from Cape Canaveral (latitude 28.5°, so the launch plane is inclined 28.5° to the equator and a plane change is needed to reach equatorial GEO):

The launch vehicle's job (top row) is a separate sizing problem we take up in Chapter 30; what the spacecraft must carry in its own tanks is the 2.56 km/s of the lower rows. That number — not the launch — is what sizes the comsat's propulsion.

Strategy first. To turn a delta-v budget into a vehicle, we (1) roll up the legs into an ideal total, (2) add margin to get a design total (29.4), (3) choose an engine, giving $v_e = I_{sp}\,g_0$, and (4) invert the rocket equation to get the propellant mass for the spacecraft's dry mass. Steps 1–2 are this section and the next; step 4 is the Checkpoint's size_vehicle. The whole of mission sizing is those four moves.

We can do step 1 in code. The roll_up_dv function we add to astrotools this chapter takes a budget of (label, delta_v, margin) legs and returns both the ideal total and the margined total:

import math

def roll_up_dv(budget):
    """Roll up a delta-v budget. `budget` is a list of (label, dv, margin)
    tuples; dv in m/s, margin a fraction (0.05 = 5%). Returns (ideal, margined)."""
    ideal    = sum(dv               for _, dv, _      in budget)
    margined = sum(dv * (1.0 + m)   for _, dv, m      in budget)
    return ideal, margined

comsat = [
    ("GTO->GEO (with plane change)", 1800, 0.05),   # m/s, 5% margin (well understood)
    ("station-keeping, 15 yr",        750, 0.10),   # 10% margin (lifetime uncertain)
    ("disposal to graveyard",          11, 0.00),   # tiny, fixed
]
print(roll_up_dv(comsat))
# Expected output:
# (2561, 2726.0)

The ideal budget is 2,561 m/s; with margin it is 2,726 m/s. That margined number is the delta-v the comsat's propulsion must actually be designed to deliver. (Notice the different margins per leg — the well-understood transfer burn carries less reserve than the uncertain fifteen-year station-keeping. That is deliberate, and it is the subject of the next section.)

🚪 Threshold Concept. The delta-v budget is the spine of a mission. Once you internalize that a mission is a route across the delta-v map, and that its total delta-v — through one exponential — determines the mass and therefore the cost of the entire vehicle, you stop seeing spacecraft as collections of parts and start seeing them as answers to a delta-v number. Ask "what is the delta-v budget?" about any mission and you have asked the question that sizes everything else. This is why a mission designer's first serious calculation, before any subsystem exists on paper, is almost always the delta-v budget. It is the constraint from which the rest of the design is deduced.

🔧 Engineering Reality: Real delta-v budgets carry legs the map does not draw. Finite-burn losses (a real engine is not the instantaneous impulse of Chapter 10); trajectory- correction maneuvers to fix navigation error; attitude-control propellant if the same thrusters do both jobs; and reserves for the maneuvers you have not thought of yet. Each is small, but near a tight mass budget the small ones decide whether the design closes. A professional budget has a line for every velocity change, however minor, and a margin line on top of the sum.

🔄 Check Your Understanding 1. Why is the delta-v budget called the master constraint, rather than, say, the power budget? 2. The comsat's launch vehicle pays ~11.9 km/s and its own propulsion pays ~2.6 km/s. Why do we size those two numbers against two different pieces of hardware instead of adding them into one total?

Answers

1. Because it is the one budget that converts — through the exponential rocket equation — into propellant mass, and propellant mass dominates a vehicle's wet mass and therefore its launch cost. An error in delta-v is amplified exponentially into mass; an error in the power budget is not. 2. Because they are provided by different vehicles that are staged apart: the launch vehicle burns its ~11.9 km/s and is discarded (or flies home) before the spacecraft ever fires its own engine. The spacecraft only ever has to provide its own 2.6 km/s, so that — not the sum — is what sizes its tanks. (Staging, again: you never carry the launch vehicle's job into your own mass ratio.)

29.4 Margins and contingency

Every number in a mission design is wrong when you first write it. The mass estimate is too low (they always are), the power draw is underestimated, the delta-v budget is missing a leg you have not thought of. This is not incompetence; it is the nature of designing something before it exists. The engineering response is not to pretend the numbers are exact — it is to carry margin.

Definition (margin). A margin is a deliberate reserve held between the current best estimate of a quantity and the limit the design can tolerate — extra delta-v beyond the computed budget, extra mass capability beyond the current mass estimate, extra power beyond the predicted load. Margin absorbs the growth, uncertainty, and surprises that every real program experiences. It is distinct from contingency, which is reserve set aside specifically for identified risks; margin covers the unknown, contingency covers the known-but-uncertain.

Margin is not padding, and this is worth being emphatic about, because "cut the margin to save mass" is one of the most dangerous sentences in engineering. Recall theme 2: space is an unforgiving environment — you cannot pull over and fix a spacecraft that came up 3% short on propellant. Margin is what converts an estimate you are not sure of into a design you can stake a mission on. A rocket that reaches orbit with 5% propellant to spare is not wasteful; it is a rocket that still reaches orbit when the winds are bad, the engine underperforms by a percent, and the spacecraft came out 40 kg heavy.

🐛 Find the Error. A program manager, under pressure to fit a smaller launch vehicle, reasons: "Our analysis says we need 2,561 m/s of delta-v, and we have propellant for exactly 2,561 m/s. The analysis is our best engineering; carrying extra propellant 'just in case' is unscientific padding that costs mass and money. Fly it at the computed number." What is wrong with this reasoning?

Answer

The "best engineering" number is a point estimate of a quantity that is genuinely uncertain — masses grow, engines underperform, and the budget is likely missing small legs (finite-burn losses, extra trajectory corrections). Designing to the exact estimate guarantees that any adverse deviation — and there is always at least one — makes the mission fall short. Margin is not padding on top of the right answer; it is the honest acknowledgment that the estimate is a distribution, not a number, and that the cost of falling short (a lost mission) vastly exceeds the cost of carrying reserve. The correct move is to reduce the uncertainty (better mass tracking, more analysis) so the margin can shrink with justification — never to delete the margin and hope.

How much margin, and when

The right amount of margin depends on how mature the design is. Early, when everything is a guess, you carry a lot. Late, when hardware is built and weighed, you carry little — because by then you know the numbers. A rough schedule, standard across the industry (the specific percentages are illustrative and vary by organization; see, e.g., AIAA mass-properties practice):

The pattern is the point: margin starts large and is bought down as knowledge is bought. You do not add margin as you learn; you earn the right to remove it by replacing estimates with measurements. This is why a healthy program watches its margin trend the way a pilot watches fuel — a margin that is shrinking faster than the design is maturing is the earliest warning that a mission is in trouble.

The same philosophy applies to every budget. Delta-v margin (we used 5–10% per leg above; NASA missions often carry a defined delta-v reserve for exactly the unmodeled effects of the previous section). Power margin (size the array for more than the predicted load — the load always grows, and the array degrades: Chapter 25). Mass margin on the dry mass. Each is a hedge against the same reality: your estimate is optimistic, and the environment is unforgiving.

🔧 Engineering Reality: Spacecraft gain weight the way books gain pages — steadily, and never in reverse. Across a typical development, dry mass grows on the order of 20–30% from the first concept estimate to the flight article, as "we'll figure it out later" becomes brackets, cables, shims, and heavier-than-hoped components. This mass growth is so reliable that it is a budgeted allowance, not a surprise: the whole point of a 25–30% margin at concept is to have somewhere for that growth to go. The mission that budgeted zero margin does not avoid the growth; it just discovers, at the launch site, that it cannot fly. Echoing Augustine's law in the epigraph, it is the last ten percent of mass performance that generates the disproportionate share of a program's pain — which is exactly why you hold reserve against it from the first day.

🔄 Check Your Understanding 1. Why does the margin you carry decrease as a program matures, when you might naively expect uncertainty to be handled by keeping margin constant? 2. Distinguish margin from contingency in one sentence each.

Answers

1. Because margin exists to cover uncertainty, and uncertainty falls as you replace estimates with built-and-measured hardware. You buy down margin by buying knowledge; at launch you know the mass, so almost no mass margin is needed. 2. Margin is reserve held against the unknown (growth, surprises, optimistic estimates). Contingency is reserve set aside for specific identified risks (e.g., extra propellant in case a particular thruster underperforms).

29.5 Systems engineering: why everything is connected

We have been circling the central truth of the whole chapter, and now we name it. In spaceflight you cannot optimize the subsystems one at a time, because they are coupled: improving one makes another worse, and the improvements chase each other in loops. The discipline of managing those loops — of designing the whole rather than the sum of the parts — is systems engineering.

Definition (systems engineering). Systems engineering is the discipline of designing a system so that its subsystems work together to meet the mission requirements — managing the interfaces between subsystems, the budgets (mass, power, delta-v, data, pointing, cost) that they share, and the emergent behavior that no single subsystem exhibits alone. Its governing insight is that the whole is constrained differently from any of its parts, so the parts cannot be optimized in isolation.

The clearest way to feel systems engineering is to trace the mass–power–cost coupling, the loop that runs through every spacecraft ever built. Follow it around once for our comsat:

        more PAYLOAD capability
                 |
                 v
        more POWER needed  ------> bigger SOLAR ARRAY (Ch. 25)
                 |                          |
                 |                          v
                 |                   more ARRAY MASS
                 |                          |
                 v                          v
        more THERMAL to reject  ----> more DRY MASS (Ch. 23, 24)
                 (Ch. 24)                    |
                                             v
                              more PROPELLANT for the same delta-v  (Ch. 3, 29.3)
                                             |
                                             v
                                    more WET MASS
                                             |
                                             v
                              bigger / costlier LAUNCH VEHICLE  (Ch. 30)
                                             |
                                             v
                                        more COST

Every arrow is a real engineering dependency you met in Part IV, and the loop closes on cost. The reason this is hard — the reason it is a discipline — is the arrow from dry mass to propellant, which runs through the rocket equation and is therefore an amplifier. Let us make the amplification concrete.

Worked Example: the amplifier that is the rocket equation. Our comsat sizes to a wet mass of about 3,576 kg for a 1,500 kg dry mass and its 2,726 m/s margined budget (the Checkpoint computes this). Now suppose the customer asks for a heavier antenna — 100 kg more payload, so the dry mass rises to 1,600 kg. Re-size with the same delta-v and engine ($v_e = 320 \times 9.80665 = 3{,}138\ \text{m/s}$, mass ratio $e^{2726/3138} = 2.384$): the wet mass becomes $2.384 \times 1{,}600 = 3{,}814\ \text{kg}$. Adding 100 kg of payload added $3{,}814 - 3{,}576 = 238\ \text{kg}$ of wet mass — more than twice the payload increase. The mass ratio, 2.38, is the amplification factor: every kilogram of dry mass drags 2.38 kg of wet mass behind it. On a mission with a larger delta-v (a Mars orbiter, a lunar lander) the amplifier is larger still, and a small subsystem change can blow the whole vehicle past its launch vehicle's capacity.

That amplification is theme 1 (the tyranny of the rocket equation) and theme 4 (mass is the enemy) meeting in a single number. It is why a spacecraft systems engineer fights for every kilogram of dry mass as if it were ten — because, through the rocket equation, it nearly is. And it is why "just add a little more capability" is never a local decision: it propagates around the whole loop and comes back as cost.

The systems engineer's tools: budgets and interfaces

How does one person keep this whole coupled machine in their head? They do not — they keep budgets. Every shared, conserved resource gets a budget with an owner, a running total, and a margin:

A design closes when every budget balances at once — with margin. The systems engineer's other main job is the interfaces between subsystems: the bolt patterns, the voltages, the data formats, the units. It sounds like bookkeeping, and it is, but the bookkeeping is where missions are lost — as we will see in the next section, an entire Mars orbiter was destroyed by a single unmanaged interface.

💡 Intuition: Think of the subsystem budgets as accounts and the systems engineer as the auditor who makes sure the whole company is solvent, not just each department. A department (subsystem) can be "under budget" on its own while quietly pushing another over — the heavier camera is a win for the science team and a disaster for propulsion. Only someone looking at all the budgets at once, and at the interfaces between them, can see whether the mission as a whole can afford a local decision. That whole-system view, not any single calculation, is what systems engineering is.

Finding the driving requirement (29.2) is the systems engineer's highest-leverage act precisely because of this coupling: the driving requirement is the one input to which the whole loop is most sensitive. For our comsat it is the fifteen-year lifetime (which sets station-keeping propellant → wet mass → launch → cost); for a Mars orbiter it might be the science instrument's mass; for a lunar lander, the surface payload. Identify it, and you know where in the loop to spend your margin and your ingenuity.

🔄 Check Your Understanding 1. In the mass–power–cost loop, which single arrow makes the coupling an amplifier rather than a simple sum, and why? 2. Why is finding the driving requirement worth more than optimizing any individual subsystem?

Answers

1. The arrow from dry mass to propellant, because it runs through the rocket equation: propellant mass grows as $e^{\Delta v/v_e}$ times dry mass, so a change in dry mass is multiplied (here by ~2.4) into wet mass, not merely added. 2. Because the subsystems are coupled: optimizing one in isolation can push another over budget through the loop. The driving requirement is the input the whole coupled system is most sensitive to, so effort spent there (or relaxation negotiated there) moves mass and cost far more than the same effort spent optimizing a subsystem that is not driving the design.

29.6 Mission phases and the design lifecycle

A mission is not designed all at once and then built. It matures through a sequence of phases, and between the phases stand design reviews — formal gates where the design is examined by people who did not create it, and either allowed to proceed or sent back. The reviews are how a program converts optimism into evidence, one gate at a time.

Definition (design review). A design review is a formal, gated evaluation of a design's maturity and soundness by an independent board, held at a defined point in the lifecycle. Passing a review authorizes the program to spend the money and take the risk of the next phase; failing it sends the design back for rework. Reviews exist because the people who build a thing are the worst-placed to see its flaws — they are why the design must survive contact with outside eyes before it survives contact with space.

The lifecycle and its gates, in the form NASA and most of the industry use (names vary between organizations; the sequence and intent do not):

Three of these gates are the ones every space engineer knows by their initials.

Definition (MDR / PDR / CDR). The MDR (Mission Definition Review; in this book, your Mission Design Review) closes the concept phase: it confirms that the requirements, orbit, delta-v budget, and overall architecture are sound and consistent — that the mission can close — before detailed design money is spent. The PDR (Preliminary Design Review) confirms that the preliminary design of every subsystem meets its requirements with adequate margin; passing it freezes the architecture and the interfaces. The CDR (Critical Design Review) confirms that the detailed, build-to design is complete and verified by analysis; passing it authorizes cutting metal and building flight hardware. In one line: MDR proves the mission closes, PDR proves the design will work, CDR proves it is ready to build.

Notice how the margins of 29.4 line up with these gates: 25–30% mass margin at MDR, 15–20% at PDR, 5–10% at CDR, near zero when the built hardware is weighed. The review timeline is the margin-buy-down schedule. Each gate is the moment a program checks that it has bought enough knowledge to justify removing some reserve — and a review board's sharpest question is almost always "show me your margins, and show me they are shrinking for the right reasons."

The document you have been assembling since Chapter 1 — requirements, orbit selection, delta-v budget, subsystem budgets, and now a coherent architecture — is exactly a Mission Design Review package. This chapter is the one where it becomes a review, because for the first time you have all the pieces on one table and can ask the MDR's defining question: does this mission close?

📜 From History: Systems engineering as a formal discipline was forged on the great programs of the mid-twentieth century — the ICBM programs and Apollo — where thousands of engineers across dozens of organizations had to build interfaces that met in the middle and worked the first time. Its hardest lesson is written in the loss of the Mars Climate Orbiter in 1999. The spacecraft was destroyed at Mars not by a physics error but by an interface error: one team's ground software produced a thruster impulse in pound-force-seconds (imperial units) while the navigation software expected newton-seconds (metric), and the mismatch accumulated over months of cruise until the orbiter entered the atmosphere too low and broke apart. No single subsystem failed. The system failed, at an unmanaged interface between two correct pieces — the precise failure mode systems engineering exists to prevent, and the reason "units on every number" (a rule of this whole book) is not pedantry but survival.

🔧 Engineering Reality: Reviews are adversarial on purpose. A good review board is not there to admire the design; it is there to find the flaw that the design team has grown too close to see. The healthiest thing that can happen at a PDR is that a reviewer finds a real problem — because the alternative is that space finds it instead, and space does not let you reschedule. The cost of fixing a flaw rises by roughly an order of magnitude at each gate you pass without catching it: cheap at MDR, painful at CDR, catastrophic in flight. This is the entire economic argument for the review timeline.

🔄 Check Your Understanding 1. Put MDR, PDR, and CDR in order and give the one-line question each answers. 2. Why does the cost of fixing a design flaw rise so steeply the later it is caught?

Answers

1. MDR (does the mission close?) → PDR (will the design work, with margin?) → CDR (is it ready to build?). 2. Because later work is built on top of earlier decisions: a flaw caught at MDR changes a line in a document, but the same flaw caught at CDR means re-doing detailed design, re-analyzing every affected interface, and possibly scrapping hardware already ordered — and caught in flight it means losing the mission. Each gate you pass without finding it multiplies the amount of work built on top of it.

Mission Design Checkpoint: assemble your MDR and build mission.py

This is the synthesis checkpoint of the whole project. Everything you have added to your Mission Design Review since Chapter 1 now comes together into one coherent architecture — and you build the astrotools module that ties it together.

The design — assemble your MDR. Lay your pieces on one table and check that they form a consistent whole:

1. Requirements — the top-level mission requirements and the driving requirement you identified in 29.2 (for Track A, the 15-year lifetime).
2. Orbit — chosen back in Chapter 9 (Track A: GEO at a fixed longitude).
3. Delta-v budget — rolled up here, with margin (Track A: ~2.56 km/s ideal → ~2.73 km/s margined for the spacecraft's own propulsion).
4. Mass and power — your dry mass from the mass budget of Chapter 23 and your loads from the power budget of Chapter 25.

Now close the loop: feed the margined delta-v, an engine's $I_{sp}$, and your dry mass through the rocket equation to get the propellant mass and the wet mass — the number that will pick your launch vehicle in Chapter 30. Then write down, in one sentence, your driving requirement and how it flows through this loop. That sentence is the heart of your MDR.

The code. Create astrotools/mission.py with the two canonical functions this chapter owns — roll_up_dv (from 29.3) and size_vehicle, which inverts the rocket equation to size the vehicle from the budget:

import math
G0 = 9.80665  # standard gravity, m/s^2

def roll_up_dv(budget):
    """budget: list of (label, dv, margin) tuples (dv in m/s, margin a fraction).
    Returns (ideal_total, margined_total) in m/s."""
    ideal    = sum(dv             for _, dv, _ in budget)
    margined = sum(dv * (1.0 + m) for _, dv, m in budget)
    return ideal, margined

def size_vehicle(dv, isp, payload):
    """Invert the rocket equation. dv (m/s), isp (s), payload = dry mass m_f (kg).
    Returns (m_prop, m_wet) in kg."""
    ve = isp * G0
    m_wet = math.exp(dv / ve) * payload      # m0 = (m0/mf) * mf
    return m_wet - payload, m_wet

comsat = [("GTO->GEO", 1800, 0.05), ("SK 15yr", 750, 0.10), ("disposal", 11, 0.00)]
ideal, margined = roll_up_dv(comsat)
m_prop, m_wet = size_vehicle(margined, isp=320, payload=1500)
print(f"budget: {ideal} ideal, {margined:.0f} margined m/s")
print(f"propellant {m_prop:.0f} kg, wet mass {m_wet:.0f} kg")
# Expected output:
# budget: 2561 ideal, 2726 margined m/s
# propellant 2076 kg, wet mass 3576 kg

The wet mass, ~3,576 kg, is your comsat's number for Chapter 30: it is what the launch vehicle must lift to GTO. Change the engine to electric (isp=1800) and the propellant drops to ~250 kg and the wet mass to ~1,750 kg — the trade study of 29.2, now in one line of code. How it feeds the capstone: in Chapter 40 you will present a complete MDR, and roll_up_dv and size_vehicle are the functions that turn your budget into the sized vehicle at its heart. The full astrotools package is reproduced in Appendix I.

Summary

Mission design is the synthesis of the whole book: the disciplined, iterative conversion of an objective into a closed architecture. Carry these forward:

Key relationships: $v_e = I_{sp}\,g_0$; mass ratio $m_0/m_f = e^{\Delta v/v_e}$; wet mass $m_0 = (m_0/m_f)\,m_f$; every kilogram of dry mass drags $m_0/m_f$ kilograms of wet mass. astrotools additions: mission.py with roll_up_dv(budget) and size_vehicle(dv, isp, payload).

Spaced Review

Retrieval strengthens memory. Answer from memory before checking, then look back at the cited chapter.

1. (Ch. 3) A spacecraft must provide $\Delta v = 2{,}726\ \text{m/s}$ with an engine of $I_{sp} = 320\ \text{s}$. What is its exhaust velocity, and what mass ratio does it need? (This is the sizing step of the Checkpoint.)
2. (Ch. 3) Why does a 100 kg increase in dry mass cause a larger increase in wet mass? Name the amplifier.
3. (Ch. 10) Our comsat's GTO→GEO leg is expensive partly because of a 28.5° plane change. Roughly why are plane changes costly, and why is it cheaper to do them at GEO altitude than at LEO?
4. (Ch. 23) In the mass–power–cost loop, the mass budget is where subsystem masses are rolled up. Why is "mass is the enemy" the defining slogan of spacecraft structures, in one sentence?
5. (Ch. 10 & Ch. 3) A mission is "a route across the delta-v map." What operation turns that route into the single number that sizes the vehicle?

Answers

1. $v_e = 320 \times 9.81 \approx 3{,}140\ \text{m/s}$; mass ratio $= e^{2726/3138} = e^{0.869} \approx 2.38$. 2. Because dry mass and wet mass are linked by the rocket equation: $m_0 = (m_0/m_f)\,m_f$, so a change in dry mass ($m_f$) is multiplied by the mass ratio (~2.38 here) — the rocket equation is the amplifier. 3. A plane change turns the velocity vector through the inclination angle at roughly constant speed, costing $\Delta v = 2v\sin(\Delta i/2)$, which is proportional to the orbital speed $v$; since spacecraft move slower at high altitude (GEO, ~3.1 km/s) than in LEO (~7.8 km/s), the same angle is cheaper up high — which is why the plane change is folded into the GEO apogee burn. 4. Because every kilogram of structure is a kilogram that is not payload and must be accelerated by propellant that grows exponentially with delta-v — so structural mass is penalized twice, once directly and once through the rocket equation. 5. Summing the legs into a total delta-v budget, then inverting the rocket equation ($m_0/m_f = e^{\Delta v/v_e}$) to turn that total into a required mass — the roll-up-then-size operation of this chapter's mission.py.

What's Next

You now hold your mission's defining number: the wet mass your spacecraft must be, which came from the delta-v budget through the rocket equation. But a spacecraft on paper is not a mission until something lifts it off the Earth — and which something is its own design decision, with its own constraints of payload capacity, orbit, launch site, cost, and schedule. In Chapter 30 we survey the world's launch vehicles — Falcon, Starship, Vulcan, Ariane, Soyuz, Long March, and the small-launch newcomers — learn how launch-site latitude and launch windows constrain what they can do, and choose the rocket that carries your mission to orbit. The wet mass you just computed is the first number you will bring to that choice.