MARS BIBLE — REFERENCE DOSSIER
Interplanetary Mars spacecraft system architecture: designing a machine that must survive for months
Mission, bus, payload, budgets, modes, interfaces, redundancy, maintenance and validation: understand the spacecraft as a system of systems rather than a rocket surrounded by boxes.
Why this dossier matters
Mission, bus, payload, budgets, modes, interfaces, redundancy, maintenance and validation: understand the spacecraft as a system of systems rather than a rocket surrounded by boxes.
The goal is deliberately encyclopaedic: start from the simple principle, show useful interfaces and calculations, then continue through failures, testing, maintenance and Mars autonomy.
1. Why system architecture deserves a full chapter
An Earth-Mars vehicle is not one technical object. It is a federation of functions that must remain compatible through launch, interplanetary cruise, trajectory corrections, communications, anomalies and arrival. Structure, power, thermal control, computing, navigation, propulsion, communications and payload continuously exchange mass, power, heat, data, loads and operational constraints. A local decision therefore moves problems elsewhere. A stronger antenna may improve data rate while increasing power, mass, heat rejection and pointing needs. Systems engineering tries to see those consequences before integration.
2. Start from the mission, never the catalogue
A serious architecture starts from objectives, duration, environments, performance, autonomy and failure consequences. Those needs become verifiable requirements, and only then are functions allocated to hardware. This avoids selecting an attractive technology first and inventing a justification later. Crewed missions bring survival, abort, maintenance and return requirements from the beginning, while cargo vehicles can accept different trades. Two vehicles both going to Mars can therefore have very different architectures without either being inherently wrong.
3. Functional and physical architecture
Functional architecture asks what the system must be able to do: generate and distribute power, control temperature, know position and attitude, execute commands, manoeuvre, communicate, store data and protect payload or crew. Physical architecture then asks which components implement those functions, where they are located and how they connect. Keeping the two levels distinct makes alternative implementations possible and helps reveal forgotten critical functions.
4. Budgets are the spacecraft’s physical accounting
Mass, power, energy, volume, radiator area, data rate, propellant and computing capacity are limited resources. Budgets are therefore built by subsystem and operating mode. Mass addition is simple; power is harder because not every load runs simultaneously. Budgets also need defined margins. Margin is not decoration; it is reserve against design growth and uncertainty. As the project matures, the origin of every kilogram and watt must become traceable.
5. Operating modes reveal the real sizing cases
A spacecraft does not have one power draw or one temperature. It has modes: launch, cruise, charging, communications, manoeuvre, sleep, maintenance, emergency and safe mode. Each activates a different set of functions. A burn may create power and thermal peaks; a long dormant phase may be limited by cold; safe mode must preserve minimum attitude, power and communications. Mode-function matrices expose complete-system consistency and dangerous transitions.
6. Interfaces: where systems meet and failures emerge
Interfaces carry power, data, heat, loads, fluids and responsibility. Many integration failures come not from broken hardware but from two compliant units built around different assumptions: voltage, message format, mechanical tolerance, time reference, sign convention or startup sequence. Interface-control documents formalise these boundaries, but must evolve with the design and be tested. An untested interface remains an assumption.
7. Redundancy, independence and common-cause failures
Duplicating hardware does not automatically double safety. Two channels sharing one power feed, software image, reference sensor or thermal zone can fail together. Analysis therefore looks for common causes and single-point failures. Designers may separate channels physically, diversify technologies or use a deliberately simpler backup mode. Mars adds repairability: can the failure be isolated, bypassed or repaired with onboard resources?
8. Maintenance becomes an architecture requirement
On long missions, equipment access, connector standardisation, spares, tools, documentation and diagnostic capability must be designed rather than added later. A unit trapped behind other hardware can turn a minor fault into a long-term loss of function. Maintenance therefore affects layout, access panels, modularity, cable reserves, lifting provisions and diagnostic software. A future Mars economy will need spacecraft architecture and maintenance workshops to evolve together.
9. Verify, validate, and know what remains unknown
Verification shows compliance with requirements; validation shows that the system meets the real need. Analysis, inspection, tests, demonstrations, simulations and hardware-in-the-loop complement one another. No Earth test exactly reproduces months of interplanetary transit, radiation and operations. A mature architecture distinguishes measured evidence, model-correlated evidence and remaining extrapolation. Being explicit about limits is a condition for trust.
10. A Mars architecture must be evolvable
The first Mars spacecraft will not be the last. If every generation changes voltages, connectors, protocols, mechanical interfaces and procedures, the settlement accumulates incompatibility. Stable standards allow computers to be replaced, modules added and payloads reused. Standardisation should not freeze innovation; it should stabilise the boundaries that are most expensive to change, letting mission architecture evolve into fleet and industrial infrastructure.
11. Centre of mass and architecture evolve during the mission
Consuming propellant, moving cargo, emptying water tanks or changing module configuration shifts the centre of mass and can change spacecraft inertia. This affects propulsion, GNC, structure and sometimes thermal behaviour. Architecture is therefore not a frozen launch-day picture; multiple mass configurations must be analysed so actuators, pointing margins and loads remain acceptable.
12. Human-rated systems change the meaning of risk
Crew adds life support, habitable volume, protection, human interfaces, procedures, consumables and intervention capability. More importantly, hazards are judged differently than on cargo vehicles. Failures tolerable on a probe may be unacceptable when they threaten a pressurised atmosphere or return capability. Crewed architecture therefore needs barriers, detection and recovery proportional to consequence.
13. Configuration control and technical truth
Long missions cannot depend on drawings that no longer match the real spacecraft. Cable, software, valve, sensor and fastener changes must be traced. Teams need to know which version is installed, which tests qualified it and which spares are compatible. Mars workshops will need the same discipline: manufacturing the right part to the wrong revision can be as dangerous as having no spare.
14. Architecture and human factors
Crewed spacecraft must account for possible human error: confusing commands, poor access, alarm floods, ambiguous procedures or maintenance that cannot be performed with available gloves and tools. Human-machine interaction is therefore a system interface. Good architecture helps crews understand state, prioritise alarms and recover without creating a second failure.
15. From one mission to a Mars fleet
When multiple cargo vehicles, habitats and spacecraft share standards, spares, software tools and procedures can serve several systems. This reduces inventory and training burden. An incompatible fleet creates logistics debt. Long-term architecture should therefore distinguish freely evolving technology from interfaces that benefit from civilisation-level standards: voltage, connectors, formats, mechanical interfaces, diagnostics and safety rules.
Cross-cutting deepening: what the simplified lesson must not hide
The following points complete the system view and connect this dossier to Space Academy lessons.
AM-09.01 — Spacecraft anatomy: bus, payload and subsystems
From mission need to architecture
A spacecraft should not be designed by first choosing a battery, computer or engine. Start with the mission: payload, destination, duration, navigation accuracy, communications, environment, autonomy, safety and possibly crew. These needs become measurable requirements. Functional architecture describes what the vehicle must do; physical architecture later assigns those functions to real hardware. Keeping those two levels separate prevents the mission from being forced into a collection of preselected boxes.
Bus and payload are useful but imperfect boundaries
The bus is not necessarily one physical object. It groups common support functions that make the mission possible. Payload is what directly accomplishes the primary objective. On an Earth-Mars vehicle the boundary can become ambiguous, so the important issue is not the label but clear interfaces, ownership, budgets and modes. A poor boundary can hide a critical dependency.
Budgets are contracts between subsystems
Mass, power, energy, volume, heat rejection, data rate, propellant and computing time are shared resources. A budget is therefore not an end-of-project spreadsheet. It prevents one team from optimising locally at the expense of the vehicle. A heavier instrument affects structure and propulsion; a stronger transmitter affects power and thermal control. Margins must be defined rather than assumed.
Operating modes change everything
Launch, cruise, high-rate communications, manoeuvres, charging, science, emergency and safe mode do not activate the same equipment. Adding every load can over-size a system, while using only an average can hide an impossible peak. A mode-function matrix makes required loads, allowed shutdowns, redundancy and transitions explicit. For Mars, surviving a long degraded mode may matter more than a short peak capability.
Redundancy needs real independence
Two computers sharing one converter are both lost if that converter fails. Identical software can share the same design defect, and co-located sensors can share the same environmental hazard. Robust design therefore considers common-cause failures and may separate power feeds, data paths, sensors, locations or technologies.
Design for maintenance before departure
Mars missions change the value of accessibility, spares, tools, connectors, procedures and fault isolation. A compact design may save mass yet make repair impossible. A modular design may cost mass but improve maintainability. The correct trade depends on mission duration, crew, autonomy and consequence of failure.
Evidence matters as much as architecture
A neat diagram is not proof. Important requirements need verification by analysis, inspection, demonstration or test, interfaces must be exercised, degraded modes must be tested and margins must be recalculated after changes. Validation asks a different question: even if the design meets its requirements, does it actually satisfy the mission need?
Open the corresponding Space Academy lesson
AM-09.09 — Integration: interfaces, budgets, verification and validation
Integration means managing boundaries
Two units can work separately and fail when connected. Integration verifies mechanical, electrical, thermal, software, RF, fluid and operational interfaces. Interface Control Documents formalise parameters and ownership, but their value depends on remaining current as the design changes.
Budgets evolve until late in the project
Mass, peak power, data rate and thermal predictions change as detail grows. Systems engineering tracks budgets and margins over time and defines when changes require approval and re-analysis by affected subsystems.
Verification and validation are different
Verification asks whether the system meets its requirements. Validation asks whether those requirements and the resulting system actually satisfy the mission need. Both are necessary; a perfectly compliant system can still solve the wrong problem.
Test as you fly, fly as you test
Testing should represent flight configuration and sequences as closely as practical, while flight should avoid untested modes. A complete Mars mission cannot be reproduced on Earth, so environmental tests, simulations, hardware benches and operational rehearsals are combined with explicit knowledge of what remains extrapolated.
Electromagnetic compatibility is invisible but real
Power converters, motors, radios and digital clocks can disturb other equipment through conducted or radiated noise. Cable routing, shielding, grounding and filters are integration issues, and some problems appear only in the complete configuration.
Anomaly management requires cause, not just replacement
Test anomalies must be recorded, reproduced where possible, analysed and closed with rationale. Replacing a failed part without understanding the cause can hide a systemic problem. Traceability lets similar hardware and interfaces be checked.
Mars integration becomes logistics infrastructure
Adding a module to a settlement requires compatibility with existing power, data, fluids, dimensions, software, safety and maintenance. Local interface standards, test benches, calibration references and configuration management become part of industrial autonomy.
Open the corresponding Space Academy lesson
AM-09.10 — Design a complete spacecraft: modes, tradeoffs, margins and system decisions
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.
Primary NASA sources
These references provide documentary guardrails; they do not make the prospective choices on this page an official NASA architecture.