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.

Modular crewed interplanetary spacecraft architecture with propulsion, pressurised modules, power and docking interfaces. — Conceptual visualisation of a modular interplanetary architecture. A credible Earth–Mars spacecraft depends less on one silhouette than on integrating propulsion, power, thermal control, habitat, avionics, storage, redundancy and maintainable interfaces.

ESTABLISHED FACTACTIVE ENGINEERINGPROSPECTIVE CHOICE

Why system architecture matters

Architecture closure is a sequence of coupled budgets

Mass, power, thermal rejection, data, propellant and crew time are not separate spreadsheets that can be closed independently. A change in one subsystem often moves several budgets at once. Increasing battery capacity adds mass, may change structure and thermal dissipation, and can alter fault-recovery duration. A larger antenna can improve link margin while adding pointing inertia and deployment risk. System architecture therefore needs an explicit set of coupled trades and a record of which mission phase is dimensioning each resource. The most robust design is not necessarily the one with the largest percentage margin in every row; it is the one whose margins correspond to known uncertainties and whose failure cases do not consume the same reserve twice.

Crew time is a system resource too

For a crewed spacecraft, maintenance, monitoring and anomaly response consume hours that cannot be assigned twice. An architecture that saves hardware mass by demanding frequent manual intervention may move the cost into crew workload and training. Reviews should therefore identify operations that become routine, operations that require specialist knowledge and tasks that must remain possible when one crewmember is unavailable.

Spacecraft architecture: mission, interfaces and margins

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.

Critical interfaces and system consequences that are easy to miss

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?

Integration: interfaces, budgets, verification and validation

Integration means managing boundaries

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

Test as you fly, fly as you test

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.

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.

The spacecraft is a system of systems

A crewed Mars spacecraft is not merely a tank with engines and a cabin. For months it must simultaneously hold trajectory, generate and distribute power, reject heat, maintain breathable air, recycle water, store food, protect the crew, detect fire and leaks, communicate, navigate, withstand micrometeoroids, manage waste and remain maintainable. Simultaneity is the difficulty. An excellent subsystem can become hazardous if it rejects too much heat, demands peak power or requires maintenance incompatible with the rest of the vehicle. Architecture therefore begins with interfaces: who supplies what, within which limits, and what happens when a function disappears?

Systems engineering starts from mission requirements: maximum duration, crew size, return probability, acceptable radiation exposure, habitable volume, repair capability, cargo, and autonomy. These requirements become budgets in kilograms, watts, kilowatt-hours, cubic meters, data rate, liters of water, cooling capacity and crew time. Each budget receives margin because a mission lasting hundreds of days cannot be designed to an exact nominal number. Margin is not waste; it is quantified acknowledgement of uncertainty.

NASA currently describes twelve Moon to Mars sub-architectures. Several overlap directly inside a Mars spacecraft: habitation, human systems, communications and positioning, data, autonomous systems, logistics, power and transportation. This classification is useful because it prevents the transit habitat from being treated as furniture placed inside a propulsion stage. Habitation is vital infrastructure whose loss can leave a propulsion system healthy while making the vehicle unusable by humans.

Integrated vehicle or separated modules

An integrated architecture keeps the same occupied volume, primary propulsion and much of the hardware from departure to arrival. It reduces rendezvous and interfaces, but can force the mission to carry structures through phases in which they are unnecessary. A modular architecture may separate departure stage, transit habitat, arrival vehicle, lander and ascent vehicle. Dead mass may decrease, but rendezvous, docking, power transfer, leak checks and separations become additional critical events. The choice is not ‘simple versus complex’; it moves complexity from hardware into operations.

For settlement, reuse favors durable modules: an expensive transit habitat might perform multiple rotations if its structure, life-support systems and shielding are truly inspectable and replaceable. Interplanetary reuse is more demanding than first-stage reuse, however. Components accumulate thermal cycles, operating hours, radiation dose and impacts over years. The key question is not merely nominal lifetime but the ability to diagnose actual component health far from an Earth workshop.

A credible architecture therefore draws failure paths. If a cooling loop leaks, is there an independent loop? If a CO₂ removal pump fails, can it be replaced without depressurizing the cabin? If the high-gain antenna fails to deploy, what backup link remains? If a flight computer resets, do critical valves return to a safe state? Redundancy is not identical everywhere: two identical units can share the same design flaw. Diversity, physical separation and manual or degraded modes may be more effective than simple duplication.

Power, heat and atmosphere: the invisible networks

Electricity is the spacecraft’s circulatory system. Even with chemical main propulsion, continuous electrical generation is required for avionics, pumps, life support, communications, lighting, experiments and often thermal control. Design must consider average power and peaks: an antenna, compressor or medical device can demand kilowatts at an inconvenient moment. Batteries do not replace the primary source; they absorb transients and bridge special configurations. A distribution failure can therefore be more dangerous than a moderate loss of solar-array performance.

Nearly all power consumed inside a habitat ultimately becomes heat. In vacuum, that heat cannot leave by external convection: fluid loops must carry it to radiators and radiate it to space. As solar distance changes, the external thermal environment changes; as internal systems operate, rejection demand changes. Radiators are vulnerable surfaces, and their orientation can interact with propulsion and maneuvers. Power cannot therefore be designed independently from thermal control.

The third network is atmosphere. ECLSS must maintain total pressure, oxygen partial pressure, CO₂ removal, humidity and trace contaminants. A leak changes gas inventory, pressure and reserve availability simultaneously; a fire can make a cabin chemically hazardous while its structure remains intact. Mars duration prevents life support from being treated as disposable consumables. Water-recovery loops, sorbent beds, filters, fans and sensors become maintained equipment with spares and diagnostic procedures.

Radiation, micrometeoroids and the refuge concept

A pressure shell protects against vacuum but not adequately against every radiation hazard. Galactic cosmic radiation is difficult to stop completely with reasonable shielding mass; solar particle events can justify a more heavily shielded storm shelter where the crew gathers during an alert. Smart design places masses already required for the mission—water, food, waste and consumables—around that refuge instead of adding uniform shielding everywhere. This does not eliminate the risk; it redistributes protection according to physics and exposure time.

Micrometeoroids create another low-probability, high-consequence hazard. Multi-layer structures can break up and disperse an impact before it reaches the pressure shell. The crew must also be able to locate a small leak, isolate a section and patch it. The architectural variable is time: a slow leak detected through pressure trend is not the same event as a rapid puncture. Sensors, compartments and repair kits must be designed together.

The refuge can serve more than a solar storm. A central volume may be designed as a survival zone during partial contamination, thermal failure or depressurization elsewhere. But the more functions it carries, the more carefully single-point failure must be avoided: a fire inside the refuge must not make the whole mission uninhabitable. Resilience comes from spatial architecture as much as from equipment count.

Design for repair

On Earth, reliability is often achieved by replacing an entire device. En route to Mars, spare-mass limits prevent carrying a complete replacement for everything. Maintenance must therefore be layered: redundant critical units, stocked wear parts, standardized common components, shared tools, module-level replaceable electronics and local fabrication of noncritical parts. Standardizing a fan, connector or pump family can be more valuable than a few percent of efficiency if it shrinks the spare inventory.

The crew becomes part of the maintenance system. Every hour spent repairing is unavailable for science, exercise, rest or operations. Human time must therefore appear in budgets alongside watts. A solution that saves five kilograms but requires two maintenance hours every week for nine months may be a poor trade. Future vehicles will need health monitoring, diagnostic support and procedures usable without real-time Earth assistance.

This requirement makes a Mars spacecraft resemble a submarine or polar station more than an airliner: the crew lives for a long time inside the system it must maintain. The difference is that no rescue vessel can arrive the same day. Maintainability is therefore not a chapter added after design; it must shape equipment access, routing, isolation valves and even technology selection.

Verification is part of the spacecraft architecture

A Mars spacecraft is not complete when its block diagram closes. It must be verifiable. Every critical function needs a credible way to be tested at component, subsystem and integrated level before a crew relies on it for months. Some functions can be exercised repeatedly in low Earth orbit: life support, fault management, maintenance procedures, rendezvous, docking and portions of thermal control. Others cannot be reproduced exactly because the radiation environment, communication delay, mission duration or Martian arrival sequence differs. The verification program must therefore combine test, analysis, inspection, simulation and operational rehearsal. The architecture should favor designs whose most dangerous uncertainties can be exposed early rather than hidden until the first interplanetary flight.

This principle affects software as much as hardware. A long-duration vehicle contains thousands of states, commands, limits and automatic responses. Fault management has to distinguish a sensor failure from a genuine environmental change, prevent cascading protective actions, and leave the crew with understandable control authority. Software updates may be possible during cruise, but updating a safety-critical system hundreds of millions of kilometers from Earth is itself a risk. Configuration control, independent validation, recorded telemetry and the ability to return to a known software state are therefore part of crew survival, not administrative details.

Human factors close the loop. Controls must remain usable after months of isolation and altered gravity; maintenance tasks must be possible in the available volume; alarms must prioritize rather than overwhelm; sleeping, exercise and private spaces must coexist with machinery. A technically functional vehicle can still fail as a human system if noise, workload, lighting, confinement or repeated maintenance erodes crew performance. In a Mars architecture, habitability is not decoration around the engineering. It is one of the engineering requirements.

Margins, common cause and graceful degradation

Margins need to be allocated deliberately rather than added everywhere as an arbitrary percentage. Mass margin protects against design growth, power margin protects against degraded generation and peak demand, thermal margin protects against uncertain loads, and consumables margin protects against leaks or mission extension. These margins interact: a larger battery adds mass and heat; more stored oxygen adds pressure-vessel requirements; a larger radiator creates deployment and micrometeoroid exposure. System engineering tracks those couplings so that one team does not quietly spend margin owned by another.

Graceful degradation is the desired behavior after failure. A spacecraft should be able to shed experiments, reduce comfort loads, isolate a damaged volume, lower communication rate or suspend nonessential operations while preserving atmosphere, water, navigation and thermal safety. This is a more realistic resilience objective than pretending every function remains fully available after every failure. The mission architecture should define the minimum survival configuration and how long it can be maintained.

Architecture starts with functions, modes and interfaces

A Mars spacecraft is not a stack of separately optimized subsystems. Architecture translates a mission into functions: keep the crew alive, provide energy and data, control attitude and trajectory, survive the environment, communicate, detect failures and enable repair. Functions are then allocated among hardware, software, procedures and crew. One function can cross many components, while one component can support many functions. This is why catalog-driven architecture often fails: local optimization hides system interactions.

NASA's Systems Engineering Handbook links stakeholder expectations, requirements, logical and physical design, verification and validation. A Mars mission must also carry uncertainty through that chain. Mass, flow rate, electrical load or radiator capability have maturity and margin. Budgets are therefore not just spreadsheets; they are negotiated boundaries between engineering domains.

Operating modes reveal what averages hide

Architecture should be exercised in cruise, sleep, maintenance, maneuver, high-rate communications, power-chain loss, refuge and arrival modes. Each mode asks which equipment is active, what resources it consumes, what sensors verify it, and which functions are mandatory. A backup pump is only useful if the fault that removed the primary pump did not also remove the power bus or coolant path it needs.

This makes common causes visible. Two computers do not provide true independence if they share power, software, sensors or cooling. Two water loops that share a single exchanger are not independent survival chains. Redundancy must be accompanied by a dependency map.

Interfaces are where otherwise-correct subsystems can fail together

Interfaces may be mechanical, electrical, thermal, software, human or documentary. Critical values must be explicit: voltage, current, connector, pinout, thermal conductance, mechanical load, protocol, timing accuracy, command authority and maintenance procedure. Ambiguous interfaces allow two teams to deliver “correct” units that fail when integrated.

NASA's 2025 Systems Modeling Handbook describes how SysML models can support systems-engineering processes. The value for a Mars vehicle is traceability rather than diagram quantity. When a requirement changes — mission duration, crew size, power demand — the engineering team needs to know which budgets, interfaces and verification evidence are affected.

A 20% load increase is rarely a local 20% change

If a new payload adds 2 kW to a 10-kW bus, the peak load rises by 20%. But cable sizing, I²R loss, heat rejection, converter rating, battery reserve and array margin can all change by different fractions. If the payload runs only twenty minutes per day, daily energy rises by about 2 kW × 1/3 h ≈ 0.67 kWh while peak-distribution hardware still sees the full 2 kW. Power and energy are coupled but not interchangeable.

A Mars architecture must change without losing its technical truth

Long missions include software updates, repairs, configuration changes and replaced hardware. The spacecraft must always know what is installed, which software controls it, what verification has been completed and which limitations remain open. An undocumented repair can become the starting point of a later failure. Configuration management therefore becomes an operational capability.

The vehicle is partly an architecture of knowledge. Models, procedures, schematics, anomaly history and qualification limits travel with the crew. Success depends not only on a strong initial design but on the ability to understand the actual vehicle months after departure.

Architecture is proven by what remains possible after the nominal plan disappears

A functional block diagram matters only if it answers operational questions. What survives loss of one bus? Can a cabin be isolated? Can the vehicle navigate without a star tracker? How many functions change when a fluid loop is closed? Such questions turn architecture from a subsystem list into a dependency network.

Interfaces deserve explicit inventory. An interface can carry geometry, energy, matter, data and responsibility. A mechanical connector may also carry grounding and signals; a fluid line may be a contamination path; a software message can trigger a physical actuator. System accidents often emerge at boundaries each team thought belonged to another.

Margin is not redundancy. Twenty percent spare power does not replace a failed converter, and two identical computers do not provide resilience if they share power, clock and flawed software. Capacity margin, alternate paths and common causes must be mapped separately.

A revealing exercise removes one major function at a time. Without Earth communications, the vehicle must navigate and decide locally. Without one cabin, crew must consolidate elsewhere. Without primary cooling, loads must fall to what the remaining loop can carry. Each scenario exposes critical interfaces and degraded modes that must exist before flight.

Modularity is not the multiplication of boxes. A replaceable module needs stable interfaces, physical access, test means and stock or substitution. Otherwise “modular” describes only a drawing. Interface standardization can be more valuable than component standardization because it enables future replacements.

The human architecture finally includes crew as a control element. Some failures need immediate automation; others need human judgment. Too much autonomy creates opaque dependence, while too little overloads crew during emergencies. Authority allocation needs understandable state, reversible automation when possible and evidence about what the vehicle actually believes.

Coupled budgets make architectural trade-offs visible. Mass, power, thermal rejection, data and crew time are often tracked separately, yet one design change moves several budgets at once. Adding a pump increases mass and electrical load, generates heat, consumes control channels and creates maintenance tasks. Systems engineering needs a trade table that records these coupled effects rather than approving each subsystem inside its own local margin.

Mass margin should also be located. Ten tonnes of generic “vehicle margin” is less useful than knowing which structures, propulsion tanks or launch interfaces can physically accept growth. Center of mass, inertia and packaging may become limiting before total mass.

Requirements need verification paths. A statement such as “the vehicle shall be maintainable” is too vague unless translated into access time, required tools, safe isolation and demonstration. Every critical requirement should eventually point to analysis, inspection, test or demonstration evidence.

Architecture reviews should include failure-driven configurations, not only nominal block diagrams. Which interfaces change during cabin isolation? Which antennas still work after loss of one power zone? Which thermal paths exist during safe mode? Drawing these states exposes dependencies that a nominal schematic hides.

Crew time is a systems budget. An architecture that saves 100 kg by creating two maintenance hours every day may be a poor human-mission trade. Repeated manual operations, inspections and resets should be quantified across the mission.

The final architecture should therefore be understood as a set of viable configurations over time. The vehicle is not one diagram; it is a controlled family of states whose transitions and degraded forms are part of the design.

Case study: isolating one compartment changes the entire vehicle. A slow leak appears in a nonessential compartment. Closing a hatch looks local, but it changes pressurized volume, airflow, accessible cable routes, power distribution, crew circulation and storage. Architecture should define each isolation state in advance rather than improvise it during an emergency.

If the compartment represents 15% of habitable volume, isolation reduces volume to maintain but crowds the remaining space with people and heat. CO₂ can rise faster and noise can increase. A pressure-saving action creates a new life-support and human-factors load.

Electrical and data paths may cross the isolated region. Mechanical closure does not automatically isolate power, signals or contamination paths. The design needs decisions about penetrations, shutdown capability and fire or fluid propagation. Physical and logical segmentation should follow safety boundaries.

Future maintenance changes too. Hardware inside the lost compartment may be healthy but inaccessible. Critical inventory and essential functions should therefore be geographically distributed; two identical units side by side do not protect against loss of the room itself.

The final decision—repair, keep the compartment closed or reconfigure permanently—changes mass distribution, consumables and crew living conditions. A good architecture model recalculates these consequences and verifies the new margins. Robustness is the ability to change form without losing budget coherence.

Verification architecture matters as much as functional architecture. A system can be beautifully partitioned yet impossible to verify convincingly. Every critical function should have an evidence path from requirement to analysis, component test, integrated test and operational monitoring. If a requirement cannot be observed or tested, designers should ask whether it is written in a useful form.

Interfaces are especially difficult to verify because responsibility is divided. An electrical interface may pass voltage tests while failing under combined thermal or electromagnetic conditions. End-to-end tests should therefore cross subsystem ownership and include realistic timing, loads and failure states.

Model-based systems engineering can help maintain traceability among requirements, functions, components and verification evidence, but the model is only useful if it matches the real configuration. Late hardware changes and software updates must flow back into it. Otherwise digital sophistication merely creates a more elegant obsolete drawing.

Margins should also be verified as a system. A subsystem using its full power margin may consume thermal and battery margin elsewhere. Reviews need coupled scenarios where several uncertainties take unfavorable values at once. The goal is not to prove every subsystem individually comfortable while the vehicle collectively has no margin.

Human-in-the-loop tests reveal another class of interface. An alarm can be technically correct but operationally unusable if crew cannot understand the action it requires. Procedures, displays and automation should be tested with degraded communications and realistic workload.

The strongest architecture is therefore one whose claims can be demonstrated repeatedly. Verification is not a phase after design; it shapes modularity, instrumentation, interfaces and safe modes from the beginning.

Safety cases should track assumptions explicitly. A redundancy argument may depend on failures being independent, a thermal margin may assume one operating mode, and a crew-time estimate may assume routine communications with Earth. If those assumptions change, the evidence should be revisited rather than carried forward automatically.

Architecture also needs ownership of cross-cutting resources such as time, configuration, cybersecurity and fault management. When every subsystem assumes someone else provides them, gaps appear. Assigning system-level responsibility prevents these invisible infrastructures from being discovered only during integrated test.

A Mars spacecraft should finally be evaluated across mission phases as one product. Hardware that is excellent for launch but impossible to repair in cruise, or easy to maintain but incompatible with arrival loads, is not a good architecture. Phase transitions are where local optimizations are forced to coexist.

Design the spacecraft as an architecture of life-critical services

Life-critical service architecture: interfaces connect multiple subsystems.

A service crosses several subsystems at once

The safest way to read a Mars spacecraft is to set equipment names aside for a moment and follow the services being delivered. Breathing requires a suitable atmosphere, but also electrical power for fans and sensors, thermal capacity to reject heat, water for some processes, data to understand loop status, and command authority able to act when measurements disagree. Communicating with Earth requires an antenna, but also pointing, timing, electrical power, file management, visibility planning, and a strategy for interrupted links. Every useful service is therefore an interdisciplinary chain.

This service view prevents a common mistake: assuming that local redundancy automatically creates system redundancy. Two pumps are of little value if a single faulty sensor shuts both down. Two computers do not guarantee a decision if the same software misinterprets corrupted data. Two electrical strings remain vulnerable if they cross the same fire zone. Architecture should identify the service, its minimum dependencies, its common causes, and its recovery path before drawing the boxes.

NASA’s Moon to Mars material separates subarchitectures such as transportation, power, communications and navigation, habitation, autonomous systems, logistics, and data. That framework does not prescribe one crewed Mars vehicle, but it makes an important point: real elements usually support more than one architectural function. For Delta-Sierra, the implication is that an important interface should be described by what it carries, the quality it must preserve, and what happens when it degrades.

Write the modes before writing the automation

A long-duration vehicle needs an explicit understanding of its operating state. Nominal cruise, trajectory correction, loss of Earth contact, radiation shelter, electrical maintenance, Mars arrival, and restart after a failure are not merely software labels; they change priorities. A secondary pump can become critical during fluid transfer. A high-rate antenna can be irrelevant during the first minutes of an emergency and become essential once the crew needs to transmit a diagnosis. Robust architecture therefore begins with a mode table, allowed transitions, and the functions that must survive each state.

Transitions are often more dangerous than steady states. Entering a refuge mode may start several loads together, reposition valves, change software authority, and alter crew activity. The protection maneuver itself can create a new failure. Designers therefore need to verify inrush currents, fluid movements, heat generation, timing, and interlocks. A transition should be a verifiable sequence rather than an abstract button labeled SAFE.

Leaving the degraded state deserves equal rigor. Repair should not be assumed to restore the vehicle instantly. Measurements need confirmation, protections must be reinstated, computers resynchronized, loads reintroduced progressively, and secondary consequences of the original fault checked. Recovery is part of architecture, not an afterthought.

Carry margin all the way to mission level

A margin is meaningful only when its level is explicit. Adding 20% to an equipment load and then adding another 20% to a subsystem total that already includes it can count the same caution twice. The opposite can also happen: local margin can disappear when a converter, radiator, or battery is sized without carrying downstream reserve upstream. A credible budget therefore identifies the base value, design margin, conversion efficiency, and any separate system-level reserve.

Consider two vital loads of 3.0 kW each, a 1.5 kW diagnostic load, and 15% operational reserve. Useful demand is 7.5 kW; with reserve it becomes 8.625 kW. If the conversion path is only 91% efficient, the source must provide about 8.625 / 0.91 = 9.48 kW. Roughly 0.86 kW lost in conversion becomes mainly heat. The small example shows why power, thermal control, and margin cannot be traded independently.

Mass behaves similarly. A kilogram added to protection may eliminate several kilograms of redundant hardware elsewhere; a kilogram removed from an access panel may cost tens of crew-hours in maintenance. Architecture is therefore not a search for the minimum of every budget. It is a search for a coherent combination that leaves margin where Earth-based repair is impossible.

Integrated verification should reproduce bad days

A nominal test rarely proves what worries a Mars crew most. The vehicle should face realistic combinations: loss of a sensor during electrical reconfiguration, reduced cooling during a maneuver, unavailable communications while a software update has to be rolled back, or a maintenance task during which a second anomaly appears. Integrated testing should expose hidden dependencies and test whether the crew can understand the situation from the information actually available.

The NASA Systems Engineering Handbook emphasizes the chain from requirements and architecture to verification and validation. Applied to Mars, a requirement such as “maintain a safe environment after a single failure” should eventually produce concrete evidence: analysis, simulation, test, procedure, and pass criteria. A reassuring sentence is not evidence. The record should show which faults were injected, which assumptions were used, and which functions remained available.

Validation asks a different question: does the built system actually let the crew accomplish the mission? A procedure can be perfect on paper and fail because the hardware is inaccessible in protective clothing, diagnosis requires a tool that is not onboard, or alarms arrive too late. Human-in-the-loop tests, mockups, and duration-representative campaigns are therefore architecture evidence rather than ergonomic decoration.

Keep the architecture understandable after years of change

Time changes the spacecraft. Batteries age, sensors drift, boards are replaced, software is patched, and procedures evolve. The actual configuration must remain connected to drawings, performance models, and spare inventories. An unrecorded modification can leave the team believing a circuit still has a capacity or protection it has already lost. Configuration discipline is therefore a safety function.

Good architecture also prepares for modification. Stable interfaces, replaceable units, measurement points, and clearly documented limits let one element evolve without invalidating the entire vehicle. A system with implicit dependencies becomes more fragile with every repair. For Mars transit and especially for reused vehicles, the ability to change without losing safety evidence is itself a design property.

The objective is neither a frozen spacecraft nor endless documentation. It is a system whose functions, modes, interfaces, and evidence remain readable long enough for the crew to answer the essential question: “if I change this today, which other services might I affect tomorrow?”

Integrated case study: forty-eight hours without Earth assistance

A useful architecture test deliberately removes the comfort of a continuously available ground team. Imagine that communications are unusable for forty-eight hours while a secondary thermal loop begins to drift. Cabin pressure remains stable and the primary system still functions, yet the crew must decide whether to continue planned work, shed loads, prepare a repair, or wait for better evidence. The hard part is not one spectacular component failure. It is the interaction among incomplete data, power, thermal margin, schedule, and human authority.

The first need is a readable system picture. Operators should know available power, residual heat-rejection capability, temperature trends, battery reserve, pump state, and which functions would become critical if the remaining loop degraded. The interface should not merely present a hundred measurements; it should expose dependencies. If shutting down a science computer releases 1.8 kW and removes roughly the same heat from the cabin, the benefit and operational cost should both be visible.

Suppose the remaining loop can reject 11 kW under current conditions while the vehicle dissipates 10.2 kW. Margin is only 0.8 kW, about 7.3% of available capacity. Removing a 1.8 kW load reduces dissipation to 8.4 kW and raises margin to 2.6 kW, about 23.6%. The percent sign denotes a fraction of one hundred. The arithmetic alone does not prove the configuration safe; heat location, exchanger capability, and transients still matter. It does turn an intuition into a quantified decision.

The selected configuration then has to last for forty-eight hours without consuming another reserve. Crew may alternate some loads instead of removing them entirely, postpone one demanding operation, monitor drift, and prepare access to the suspect module. Every action should update configuration records so that the vehicle model matches reality. When communications return, Earth receives a structured chronology rather than a story reconstructed from memory.

The most revealing moment comes if a second anomaly appears. If one battery begins to heat abnormally, architecture must allow the strategy to change without losing the functional refuge. Robust design therefore does not optimize the first failure until every remaining margin is consumed. It preserves decision reserve for the next failure. Residual options are a particularly useful measure for crewed systems far from Earth.

This case links several disciplines without duplicating them. Thermal control, power, avionics, communications, and operations retain their own technical detail; system architecture shows how their constraints meet inside one decision. That is the purpose of an architecture monograph: not to repeat every specialty, but to expose dependencies that exist only between them.

Turn architecture into a verifiable contract between functions, modes, and interfaces

An interplanetary spacecraft is not safe simply because each subsystem has an impressive specification sheet. It becomes operable when the functions crossing those subsystems are described consistently and can be verified. “Keep the crew alive,” for example, simultaneously involves electrical power, thermal control, cabin atmosphere, water, avionics, sensing, alarms, procedures, and sometimes propulsion if a maneuver must be deferred. Systems architecture exists to expose those dependencies before a failure reveals them at the worst possible time.

A robust method starts from mission states rather than equipment. The same power converter does not carry the same significance during quiet cruise, a trajectory correction, loss of Earth contact, a radiation shelter period, or Mars-arrival preparation. Architecture should associate each state with functions that are indispensable, functions that may be shed, and functions that can be stopped for a limited time. A mode matrix is often more revealing than a diagram in which every box appears equally important.

This is consistent with NASA systems-engineering practice: begin with stakeholder expectations, functions and requirements, then preserve the chain through design, verification and validation. NASA’s 2026 Moon to Mars architecture makes the coupling especially visible by organizing work into subarchitectures such as transportation, power, communications and PNT, habitation, autonomous systems, logistics and data. On an actual Mars vehicle, an interface is therefore not a decorative line on a block diagram. It represents a transfer of matter, energy, information, authority, timing, or responsibility.

A useful interface specification answers operational questions. What voltage and power quality are guaranteed? What maximum flow and fluid temperature are available? Which clock is authoritative? Which estimate wins when two computers disagree? Who commands a pump shutdown? What state survives a reboot? A spacecraft may be complete at component level and still remain dangerously ambiguous if those interface contracts are not explicit.

Coupled budgets: mass, power, heat, data, and crew time

The word “budget” is not limited to mass margin. It is physical accounting. A local decision almost always moves several budgets at once. A more capable computer adds avionics mass, but it may also increase power demand, heat rejection, data flow, radiation-hardening needs and the amount of software verification. Conversely, a heavier passive device may reduce power and maintenance. System design has to compare those coupled consequences instead of optimizing each discipline independently.

A small calculation shows how margins propagate. Consider a device with a 4.0 kW nominal electrical load. Adding a 20% design margin reserves 4.8 kW at the load. If the upstream converter operates at 92% efficiency, input power is about 4.8 / 0.92 = 5.22 kW. The 0.42 kW difference is not lost; it largely becomes heat that the thermal system must reject. What looked like “add 0.8 kW of margin” therefore produces more than one additional kilowatt of generation and heat-rejection demand relative to the original useful load.

The slash symbol “/” denotes division. The 92% efficiency is an illustrative assumption, not a prescribed value for a future vehicle. The architectural lesson is that margin travels through conversion chains. Margin placed at the wrong level can be counted twice or disappear at an interface. The same reasoning applies to water, gases, data storage and communications capacity.

Crew time deserves equal status as a budget. Suppose twelve planned maintenance tasks each require two hours per month and two crew members for safe execution. The cost is not 24 hours but 48 person-hours. Preparation, isolation, depressurization when relevant, reconfiguration and documentation may add substantially more. An architecture that saves kilograms by increasing interventions can become extremely expensive in human workload.

Shape dependencies so that a failure remains local

Redundancy is often drawn as two parallel boxes. That picture is incomplete. Two devices may be physically separate while sharing the same power feed, software, reference sensor, cooling loop or connector. A common-cause failure can then remove both channels. The architecture should identify those hidden dependencies and decide where independence is worth its mass and complexity.

Total independence is rarely affordable. Priority should go to functions whose loss rapidly drives the vehicle toward an irreversible state. A protected electrical survival core might retain command computers, emergency communications, minimum atmosphere circulation, essential sensors, minimal lighting and restart capability while other loads are shed. This turns a broad power emergency into several controlled operating states rather than a single “nominal/dead” transition.

The safe-haven idea extends beyond a single room. A functional refuge can be a temporary combination of volumes, power feeds, reserves and digital services that preserves the crew while the main system is repaired. Architecture then has to demonstrate that one common cause — a fire in an equipment bay, loss of a thermal loop, contamination of a fluid circuit — cannot simultaneously deprive the refuge and the primary system of the same essential service.

Consider loss of one of two cooling loops while the crew is preparing a trajectory correction. The first decision is not automatically “repair now.” Operators need to know whether the remaining loop can carry the flight computer, actuators and avionics loads during the maneuver. If it can, but with little margin, the mission may preserve the maneuver window and repair later in a quieter configuration. If it cannot, the architecture needs another option: reduce loads, delay the maneuver, or use a backup chain. The scenario exposes a connection between thermal control, navigation, propulsion and orbital timing.

Configuration is the technical memory of the spacecraft you actually have today

A multi-year vehicle will not remain identical to its launch configuration. Parts will be replaced, boards exchanged, software revised, parameters recalibrated, and temporary repairs may become long-lived. Configuration management is the organized memory of those changes. Without it, procedures, performance models and diagnostics gradually describe a spacecraft that no longer exists.

Configuration has to connect hardware, software, wiring, consumables and documents. Replacing a converter with a later revision raises questions about thermal limits, firmware compatibility, interchangeability of spares and the accuracy of power models. On Earth, an organization may compensate for imperfect records by calling the manufacturer. At interplanetary distance that dependence is much less comfortable and can be too slow for an operational decision.

NASA-HDBK-1009A, published in 2025, formalizes the value of linking expectations, requirements, measures of performance, verification and validation through systems modeling. For a Mars mission the operational implication is broader: the vehicle model should remain capable of representing what is actually installed. The objective is not to mandate a particular SysML tool; it is to preserve evidence connecting what the team believes is onboard with the configuration that truly exists.

Verify architecture with cross-system evidence, not a pile of isolated tests

Component verification proves that a unit satisfies a requirement under defined conditions. It does not automatically prove that the integrated vehicle behaves correctly. Architecture-level testing should seek interactions: restart after long dormancy, bus transfer under high load, loss of a sensor during a maneuver, safe-haven operation with a reduced crew, recovery after a software update, or preservation of an essential service when several users demand a scarce resource at once.

The evidence hierarchy can be viewed as a ladder. Analytical calculation and simulation come first, followed by component tests, subsystem tests, interface tests, integrated tests, duration-representative campaigns and operational experience. No rung makes the others unnecessary. Simulation explores thousands of cases that cannot all be tested physically; testing exposes physical behavior the model omitted. Confidence grows when those forms of evidence converge and the remaining uncertainties are named rather than hidden.

A Mars spacecraft needs one further kind of evidence: proof that an intervention can return the system to a controlled state. Repair is not complete when a replacement is bolted in place. The function must be restored, protections re-established, configuration recorded, and neighboring systems shown not to have been degraded. In that sense, maintainability is an extension of systems engineering rather than a separate downstream activity.

Calculation marker. If an architecture requires ten critical functions simultaneously, each available 99.9% of the time, and their outages were truly independent, simultaneous availability would be approximately 0.999¹⁰ ≈ 0.990, or about 99.0%. This deliberately simple calculation shows why excellent local availability does not guarantee excellent system availability when many functions are connected in series. Real architectures are harder because dependencies and common causes violate independence; that assumption must be demonstrated before multiplying probabilities.

Primary references used for this extension include the NASA Systems Engineering Handbook, NASA-HDBK-1009A — Systems Modeling Handbook, Moon to Mars Architecture — Components, and the Architecture Definition Documents. NASA sources provide methods and current architectural framing; the numerical Delta-Sierra scenarios above remain explicitly illustrative engineering cases rather than a declared NASA vehicle design.

Case study — one local change consumes several budgets

A spacecraft with 28 t dry mass, 8 t consumables and 22 t propellant totals 58 t before margin. A 10% reserve applied to dry mass adds 2.8 t: m_plan = 60.8 t. Here t means metric tonnes. Margin must stay visible so it cannot be spent twice.

A more capable computer simultaneously increases electrical load, rejected heat, wiring or battery mass and sometimes cooling demand. Safe mode tests whether the chains that actually survive remain coherent after loss of a bus.

System acceptance chains cold start, power transfer, clock loss, post-eclipse recharge and software restart to verify interfaces rather than isolated boxes.

Change an interface without silently breaking the rest of the vehicle

Real complex systems live through change: a sensor becomes unavailable, a supplier replaces a board, a spare pump has a different performance curve, software changes a protocol, or a thermal limitation forces a new operating mode. The danger is not only that the new item may be bad. It can be excellent in isolation and still invalidate an assumption somewhere else. Interface engineering is what follows that propagation.

A flow-rate change shows the mechanism. If a replacement pump can provide 15% more flow, can the line accept the higher velocity? Does the filter tolerate the pressure drop? Is peak electrical power still available? Is pump cooling sufficient? Does the sensor remain inside its range? The phrase “better pump” therefore has no architectural meaning until those consequences are checked.

Each modification should be linked to affected assumptions, analyses that need to be rerun, and tests needed for return to service. A system model can help find dependencies, but responsibility remains human: the team must decide which relationships are important enough to maintain explicitly. An enormous graph of every possible dependency would be unusable; a smaller map of critical interfaces can be valuable during an emergency.

Software change has the same property. Increasing message frequency can raise bus occupancy, processor load, telemetry storage, and sometimes power demand. One new variable can alter a packet format consumed by several tools. Configuration management should therefore connect the change to its users and preserve rollback to a known state.

On Mars, this discipline mainly protects against slow erosion of knowledge. After years of repairs, the organization should not depend on a few people remembering why a limit exists. A documented interface, design rationale, and return-to-service test create knowledge that can be transferred to the next crew.

Architecture maturity can therefore be tested with one practical question: when an element changes, can the team quickly identify which evidence has become suspect? If answering requires rereading the entire project from zero, the architecture is not structured enough for long operation. If interfaces, budgets, and affected modes can be identified, the vehicle has a real capacity for controlled evolution.

The final criterion: preserve options when the model stops being perfect

Interplanetary architecture is not proven merely because everything works as expected. Its value appears when reality leaves the model: a sensor disagrees, a spare is a later revision, a resource is scarcer than expected, the crew is fatigued, or communications are unavailable. The vehicle should still offer understandable states and recovery paths. A design with excellent nominal performance but only one valid way to operate remains fragile.

This idea can be turned into three review questions. Which life-critical service is actually threatened? Which dependencies can propagate the fault? Which options remain if the first recovery attempt fails? Those questions prevent confusion between component health and mission health. They also force power, thermal, crew-time, and configuration margins to remain available for non-nominal situations.

Option count should not become another artificial metric. Some options are only theoretical if they require an absent spare, unavailable skill, or a maneuver that cannot be executed at the current date. Evidence for an option therefore includes resources, access, procedure, physical limits, and the time needed to carry it out.

Under those conditions, architecture becomes the memory of what makes the mission recoverable. It does not attempt to predict every failure. It organizes functions and interfaces well enough that the crew can still reason when a failure arrives that was never written exactly into the scenario.

Interfaces and margins: where subsystem optimizations become vehicle failures

A subsystem can meet its own requirement while damaging the spacecraft. A more efficient power converter may reject heat into a location the radiator cannot serve; a thicker radiation shield may move the centre of mass; a new antenna field of view may conflict with thermal pointing constraints. Interface budgets therefore have to carry physical quantities — watts, kilograms, data rate, pointing angle, heat load and crew time — rather than only connector names.

Margins need ownership as well. Ten percent mass margin in one table and ten percent structural reserve in another are not interchangeable, and the same reserve must not be spent twice. A useful design review asks where each margin lives, what uncertainty it covers and which later decision is allowed to consume it. That practice turns “system of systems” from a slogan into a traceable engineering method.

Crew time is an interface budget too

A design can close mass, power and thermal budgets while quietly requiring more inspection, manual switching or maintenance than the crew can perform. Crew time should therefore be allocated to critical functions with the same discipline as electrical power. An interface change that saves hardware but adds hours of routine work can move risk from engineering mass into human workload rather than removing it.

Sources and references

Primary NASA sources

These references provide documentary guardrails;

Primary references

NASA Systems Engineering Handbook; NASA-HDBK-1009A Systems Modeling Handbook; and NASA Spacecraft Components.

Primary sources and research landmarks

Sources used for this expansion, checked 2026-08-14.