1 — The concrete scene
One concept is lighter but less redundant; another is more robust but needs more power and radiator. The decision cannot be made with one number.
The key point is never to isolate this subject from the rest of the spacecraft. A local change often moves mass, power, heat, data, software, testing or risk elsewhere in the system.
2 — Essential words, explained before using them
Before calculating, we define every word that will be used next. The goal is for the symbol to come after the idea, never before it.
- Tradeoff
- Balance among competing criteria.
- Mode
- Functional configuration for a phase.
- Allocation
- Assigned share of a resource.
- Risk
- Possibility and consequence according to method.
- Margin
- Reserve for uncertainty or growth.
- Traceability
- Requirement-decision-evidence link.
3 — See the architecture before calculating
Scenarios
List launch, cruise, emergency and arrival.
Concepts
Keep multiple solutions alive long enough.
Criteria
Compare mass, power, risk, maturity and maintainability.
Iteration
A local choice moves other budgets.
4 — Formulas, only when they answer a question
A formula is useful only if we know which question it answers, what every symbol means, and which units must be used.
How to read it : score equals sum of weight times rating
Structures a comparison but weights remain a choice to justify.
How to read it : reserve equals capability minus need
Positive mass reserve does not compensate negative power reserve.
5 — What units and margins mean
Criteria can have incompatible units; they only become addable after explicit normalisation in a decision method.
6 — Three concrete demonstrations, calculated step by step
Matrix
A: mass 8/10, robustness 4/10. B: 6/10 and 8/10. Weights 40/60.
A=0.4×8+0.6×4=5.6
B=0.4×6+0.6×8=7.2
B wins with these weights.
Mass growth
8,000 kg with 15% reserve, +600 kg growth.
Initial reserve=1,200 kg
Growth=600 kg
Remaining=600 kg
Emergency mode
Two 400 W heaters, one nominally, both in emergency.
Nominal=400 W
Emergency=800 W
Check emergency budget.
7 — Deepening: what the simplified diagram hides
Requirement hierarchy
Local optimisation must not violate system objective.
Maturity
Promising technology can increase development risk.
Maintainability
On long missions, diagnosis and repair can be worth mass.
Growth
Margins are consumed as design matures.
Irreversibility
Identify early decisions that close options.
8 — Application to an Earth-Mars spacecraft
On an Earth-Mars transit, long duration turns a small weakness into cumulative risk: ageing, drift, consumption, cycles and maintenance become as important as nominal performance.
Communication delay forces the vehicle and possibly the crew to diagnose and reconfigure locally. Design must therefore remain observable, understandable and testable in degraded modes.
9 — Reference dossier: what a real project must still consider
This section deliberately goes beyond the introductory calculation. It connects the concept to interfaces, failures, testing, duration and maintenance so the lesson can serve as a reference chapter rather than a revision card.
Complete spacecraft design means tradeoffs
No subsystem can be maximised independently. More shielding adds mass; more power can require more radiator and battery; more redundancy adds mass and software; higher propulsion performance can add storage or thermal complexity. Systems engineering therefore compares architectures rather than isolated components.
Requirements need traceable hierarchy
A high-level need such as safe crew return decomposes into functions and subsystem requirements. Each lower-level requirement should retain its reason for existence so the impact of mission changes can be traced across thermal, power, storage, maintenance and life support.
Technology maturity changes development risk
A high-performance technology can still be immature, difficult to manufacture or poorly tested in the relevant environment. Demonstrators and qualification campaigns reduce uncertainty before a technology becomes mission-critical. Useful innovation includes a credible path to qualification.
Margins are resources that get consumed
Early design contains high uncertainty, so projects keep reserve. As detail grows, some uncertainty falls while new needs appear. Tracking trend and remaining margin is more informative than one final number. Margin first protects against the unknown; it is not automatically free capacity for new features.
Maintainability changes with mission duration
Short missions can tolerate some non-repairable equipment. Multi-year Mars infrastructure cannot apply that philosophy everywhere. Diagnostics, access, modularity, spares, documentation, training and local manufacturing may justify additional launch mass.
Recognise irreversible decisions
Some choices are easy to change; others lock many future interfaces. Habitat diameter, bus voltage, data standards or tank architecture may shape decades of hardware. Irreversible choices deserve early analysis, while replaceable details can stay open longer.
The real mission is a set of scenarios
A spacecraft must survive launch, cruise, corrections, communications, anomalies, approach, safe mode and possibly return. Each scenario activates different functions and risks. Mode analysis, failure analysis and operational testing build a coherent system view, especially when several faults combine.
10 — Common traps and bad intuitions
- Treating a score as objective truth.
- Maximising every subsystem alone.
- Using average instead of peak modes.
11 — Guided exercises
Question : What question comes before choosing hardware?
Question : Why is a nominal result insufficient?
12 — What to remember
- Explain the topic in simple words before symbols.
- Connect at least four interfaces with other subsystems.
- Redo the three numerical examples without reasoning gaps.
- Identify at least three limits or failure modes absent from the ideal calculation.
13 — NASA sources for further study
Primary institutional sources used to check the lesson structure. Teaching-number examples are identified as such.