1. Begin with a declared reference architecture
Technical discussions become incoherent when one paragraph assumes a four-person expedition, another assumes a hundred settlers and a third assumes a mature city. A useful study therefore defines a notional reference architecture. “Notional” means a scenario used for analysis, not an approved mission plan.
| Parameter | Why it matters | How it should be labelled |
|---|---|---|
| Crew size and surface duration | Sets food, water, habitat, medical and rescue demand. | Scenario assumption |
| Pre-deployed cargo | Determines how much infrastructure exists before the crew leaves Earth. | Architecture choice |
| Power level | Limits life support, resource processing and industrial activity. | Calculated requirement plus margin |
| Local water availability | Controls site choice and the feasibility of propellant production. | Measured regional evidence, then site-specific verification |
| Resupply interval | Sets reserves, spare parts and failure tolerance. | Trajectory and programme assumption |
The page uses five evidence labels: measured fact, demonstrated technology, active engineering, derived estimate and author’s scenario. Keeping these labels separate prevents a small demonstration from being mistaken for an operational colony system.
2. Transport architecture and mission mass
The first calculation is not passenger capacity but total delivered mass. Mission mass includes habitats, consumables, power systems, surface vehicles, communications, spares, scientific equipment, resource-processing plants and the propellant required for manoeuvres or ascent. Every kilogram added to radiation shielding or reserves affects launch and propulsion requirements.
A useful high-level relationship is:
Delivered settlement capability = launched mass × transfer efficiency × landing efficiency × operational availability.
This is not a precise engineering equation; it is a reminder that a large launch vehicle does not automatically deliver the same useful mass to the Martian surface. Transfer stages, thermal protection, landing propellant and structural systems consume part of the initial mass.
3. Propulsion and travel-time options
| Approach | Strength | Principal limitation | Likely role |
|---|---|---|---|
| Chemical propulsion | High thrust and extensive operational heritage. | High propellant mass for faster or heavier missions. | Crew transport, departure, capture or landing depending on architecture. |
| Solar electric propulsion | Very efficient use of propellant. | Low thrust and decreasing solar power farther from the Sun. | Slow cargo transport and pre-positioning. |
| Nuclear electric propulsion | High electrical power with efficient propulsion. | Large reactor, radiator and power-conversion systems; low thrust. | Potential cargo or specialised transport architecture. |
| Nuclear thermal propulsion | Potentially higher performance than conventional chemical engines while retaining substantial thrust. | Reactor development, testing, safety, materials and political acceptance. | Potential faster crewed transfer. |
| Mars cycler concepts | Large habitat repeatedly follows an Earth–Mars trajectory. | Complex rendezvous, timing and transport to and from the cycler. | Long-term transport network rather than first missions. |
Travel time cannot be reduced in isolation. A faster trajectory changes departure energy, arrival velocity, thermal loads, capture requirements, crew radiation exposure and payload mass. Architecture selection must compare the complete chain that delivers the required crew and cargo, including risk, margins, cadence and repeatability; peak engine performance alone cannot decide the system.
4. Entry, descent and landing for heavy payloads
EDL means Entry, Descent and Landing. Mars presents an awkward combination: atmospheric entry creates severe heating, but the thin atmosphere provides limited aerodynamic braking. Human settlement requires repeated delivery of heavy payloads with high precision.
Candidate elements include rigid or deployable heat shields, inflatable aerodynamic decelerators, parachutes for selected mass classes, terrain-relative navigation and supersonic retropropulsion. Supersonic retropropulsion means firing engines while the vehicle is still moving faster than the speed of sound through the atmosphere.
Settlement-scale EDL must also address plume–surface interaction, ejecta, dust contamination, landing-pad construction, safe separation from habitats and transport of cargo from the landing zone. A vehicle that lands safely but immobilises its cargo tens of kilometres away has not completed the logistical mission.
5. Mars ascent and return capability
The MAV, or Mars Ascent Vehicle, carries crew or samples from the surface toward orbit. Its mass depends on whether it reaches Mars orbit only or begins a direct Earth return. Producing some propellant locally can reduce landed mass, but this moves risk into the resource-processing and storage systems.
A credible architecture requires evidence that the propellant plant, tanks, valves and power supply have operated successfully before the crew becomes dependent on them. Long-duration storage of cryogenic propellants introduces boil-off and thermal-control problems. Methane–oxygen architectures may use the Sabatier reaction, which combines carbon dioxide and hydrogen to form methane and water, but hydrogen supply and water extraction remain important system choices.
6. Surface power and microgrid design
Power demand is normally divided into survival loads, habitat services, resource utilisation and industry. A conceptual balance is:
Ptotal = Plife support + Phabitat + PISRU + Pindustry + Preserve.
The symbol P represents power. ISRU means In-Situ Resource Utilization: using local Martian resources instead of importing everything from Earth.
Fission power can offer continuous output through night and dust events. Solar power is modular and can provide distributed or backup generation, but requires area, cleaning, storage and seasonal analysis. The microgrid must support black-start capability, fault isolation, load shedding and physically separated emergency circuits. Black start means restarting a power system without relying on an already operating external grid.
7. Water extraction and processing
Orbital data can identify promising regions, but the final site needs ground truth. Engineers require the mass fraction of water, excavation energy, processing temperature, contaminants and extraction rate. A complete chain may include excavation, crushing or heating, vapour capture, condensation, purification and storage.
The critical quantities are kilograms of water produced per day, kilowatt-hours consumed per kilogram, maintenance hours, filter life and reserve capacity. A process with excellent laboratory efficiency but frequent downtime can be inferior to a less efficient system with higher availability.
8. Oxygen and methane production
MOXIE demonstrated solid-oxide electrolysis of Martian carbon dioxide at small scale. Scaling the concept requires compression, filtration, thermal cycling, oxygen purification, storage and years of operation. If oxygen becomes an ascent propellant, the plant’s reliability becomes mission critical.
Methane production through the Sabatier reaction may use Martian carbon dioxide and hydrogen derived from water. The process also produces water that can be recycled. The overall system includes electrolysis, gas separation, reactors, compressors, heat exchangers and cryogenic storage. The largest risk is not a single chemical equation; it is the operational chain.
9. Environmental Control and Life Support
ECLSS means Environmental Control and Life Support System. It manages atmosphere, water, temperature, humidity, contaminants and waste. A Mars settlement may combine physicochemical systems with biological processes such as plant growth.
Design questions include oxygen generation, carbon-dioxide removal, trace-contaminant control, urine and humidity recovery, microbial monitoring, fire detection and emergency reserves. A higher “closure rate” means more material is recycled, but maximum theoretical closure is not always the safest first architecture. Stored reserves and simple bypass modes can protect the crew when complex recycling equipment is offline.
10. Habitat pressure, radiation, thermal control and fire
The pressure shell retains the internal atmosphere. Radiation shielding is a separate function and may use regolith, water or dedicated materials around the shell. Separating these roles can simplify inspection and repair.
Repeated pressurisation cycles create fatigue. Penetrations for cables, pipes, windows and airlocks require leak control. Thermal design must reject internal and industrial heat while protecting systems from severe external temperature cycles. Fire is particularly dangerous because the settlement cannot evacuate outdoors; modules need isolation, smoke control and protected refuge zones.
11. Dust control and surface operations
Martian dust is fine, abrasive and potentially hazardous. Dust mitigation begins outside the habitat: suitports, vehicle cleaning, landing-pad surfaces, controlled traffic and separation of dirty and clean maintenance zones. Filters and seals require inspection intervals based on measured loading rather than optimistic assumptions.
Surface mobility includes unpressurised utility vehicles, pressurised rovers, cargo haulers, excavators, cranes and rescue capability. Routes should consider slopes, rocks, communication coverage and the ability to recover a disabled vehicle.
12. Reliability, maintenance and spare parts
MTBF means Mean Time Between Failures. MTTR means Mean Time To Repair. Both are useful but insufficient because different components may fail together through a common cause, such as dust contamination, software error or power loss.
FMEA means Failure Modes and Effects Analysis. It asks how each component can fail, what the consequence would be, how the failure is detected and how the system recovers.
| System | Example failure | Effect | Detection | Recovery |
|---|---|---|---|---|
| Water loop | Pump seizure | Loss of circulation | Flow and current sensors | Parallel pump, manual isolation, reserve tank |
| Atmosphere control | CO₂ sensor drift | Incorrect control response | Validate with an independent sensor | Calibration or replacement |
| Power converter | Thermal failure | Loss of electrical sector | Temperature and insulation monitoring | Reconfigurable bus and spare converter |
| Airlock | Seal leakage | Pressure loss and contamination risk | Pressure decay test | Second seal, alternate airlock, replaceable gasket |
Spare-parts planning must include low-cost consumables such as seals, filters, lubricants and connectors, not only large replacement machines. Additive manufacturing may produce some mechanical parts, but electronics, sensors and high-performance materials remain a demanding supply problem.
13. Communications, navigation and digital autonomy
Earth–Mars delay varies and prevents real-time remote control. The settlement needs local decision authority, autonomous software and procedures that remain safe when communications are interrupted. Orbital relays, surface networks, time synchronisation and local positioning are part of the infrastructure.
Cybersecurity is a safety discipline because malicious or accidental changes to software can affect power, air, vehicles or medical systems. Critical control networks should be segmented, updateable through verified packages and capable of manual fallback.
14. Human health and partial gravity
Radiation exposure, reduced gravity, isolation, sleep, dust and limited medical resources interact. Countermeasures may include shielding, exercise, pharmacology, monitoring and mission design. The biological effects of lifelong exposure to 0.38 g remain unknown.
A technical page must identify uncertainty rather than hide it. Reproduction, pregnancy and childhood on Mars cannot be treated as solved simply because adult crews might survive shorter missions.
15. Technology Readiness Levels and verification
TRL means Technology Readiness Level. It describes maturity from basic principles through laboratory prototypes to operation in the real environment. A system can contain components at high TRL while the integrated Mars-scale system remains much less mature.
Verification should proceed through component tests, integrated ground analogues, orbital or lunar demonstrations where relevant, robotic Mars precursors and long-duration operation before crew dependence. The most convincing milestone is not a promotional animation; it is measured performance over the required time with realistic maintenance and fault conditions.
Engineering ledger · interfaces, margins and degraded modes
At the public-question level, the Mars colonization overview explains why a settlement could work, while the practical roadmap for how humans could colonize Mars turns that goal into stages; this engineering dossier tests whether the coupled systems can actually survive together.
Engineering a Mars settlement means controlling interfaces between systems
A settlement is not made safe by having a good power system, a good habitat and a good water system separately. It becomes safe when their interfaces are known, tested and resilient. How much electrical power does the water plant draw during startup? What happens to carbon-dioxide removal when the thermal loop is degraded? Can a habitat accept emergency power from a neighboring module? Which software has authority to shed a greenhouse load before it sheds a medical load? Can one maintenance team isolate a failed pump without depressurizing the technical gallery?
NASA’s 2026 Moon to Mars architecture explicitly frames exploration as a system of systems and maps capabilities into interacting sub-architectures. Delta-Sierra uses the same discipline for the more demanding settlement problem: every critical function needs an input/output ledger, operating range, reserve, fault response, maintenance burden and evidence status. The ledger is not a bureaucratic appendix. It is what prevents two individually correct subsystems from becoming incompatible when connected.
The minimum interface ledger
| Interface | Parameters to name | Failure question |
|---|---|---|
| Electrical | Voltage, current, frequency if AC, peak power, startup transient, grounding, connector and protection logic. | Can a fault propagate into the common bus, and can the load restart after isolation? |
| Fluid | Pressure, temperature, composition, cleanliness, maximum flow, fittings, valve state and leak detection. | Can contamination or pressure loss move from one loop into another? |
| Thermal | Heat rejected, coolant temperature, flow range, radiator capacity and survival temperature. | What function is lost first when heat rejection is restricted? |
| Data/control | Protocol, time reference, command authority, authentication, update path and safe state. | Can one software error or cyber event disable nominally redundant equipment? |
| Mechanical | Loads, alignment, tolerances, lifting points, seals, fasteners and dust protection. | Can a damaged interface be repaired with local tools and measurement capability? |
| Human | Access, visibility, reach, protective equipment, workload, procedure and training. | Can a crew member perform the repair under emergency constraints without creating a second hazard? |
Power must be sized by energy, peak power and restart behavior
Power and energy are often confused. Power is the rate at which energy is used or produced and is measured in watts (W). Energy is power accumulated over time and is commonly measured in watt-hours (Wh) or joules (J). A 10-kilowatt load running for 5 hours consumes 50 kilowatt-hours of energy. A settlement design needs both values because batteries may have enough stored energy but still be unable to deliver a short high-power startup surge, or a reactor may have adequate continuous power while the distribution system cannot restart several loads at once.
Consider a simplified essential-load list after a major grid fault: 18 kW for life support, 8 kW for thermal control, 4 kW for communications and computing, 5 kW for water, and 3 kW for medical/lighting reserve. The continuous essential demand is:
18 + 8 + 4 + 5 + 3 = 38 kW
Here kW means kilowatts, or one thousand watts. If emergency batteries must support that load for 6 hours before another generation source is restored, the ideal energy is:
38 kW × 6 h = 228 kWh
The symbol h means hours and kWh means kilowatt-hours. A real battery would need more than 228 kWh because depth-of-discharge limits, conversion losses, temperature and ageing reduce usable energy. The calculation nevertheless exposes the architectural question: what exact loads are “essential,” for how long, and what restarts them?
Fission as an initial Mars power choice changes the failure analysis, not the need for redundancy
NASA’s current Mars architecture material identifies nuclear fission as the primary surface-power generation technology selected for initial human Mars missions. The reason is not that solar power becomes useless. Fission offers continuous output independent of the day/night cycle and less direct sensitivity to atmospheric dust opacity. A settlement can still use solar arrays, storage and other sources as a diversified portfolio.
The key phrase is common-cause failure. Two identical reactors placed beside each other and connected to one switchgear room are not fully independent if a fire, software defect, construction error or impact can disable both. Two solar fields are not independent if one dust-cleaning strategy, one inverter design or one distribution trench is shared. Redundancy becomes resilience only when designers examine what the “redundant” items still have in common.
Life support is a mass-flow network
Air and water systems are easier to reason about when every percentage is translated into a flow of matter. For a pedagogical oxygen calculation, use a reference metabolic oxygen demand of 0.82 kg of O₂ per person per day. This value is an engineering reference drawn from NASA life-support literature, not a fixed physiological constant for every person and activity. For 20 residents:
0.82 kg/person/day × 20 people = 16.4 kg O₂/day
Over a 30-day bookkeeping month:
16.4 kg/day × 30 days = 492 kg O₂
The unit kg/person/day reads “kilograms per person per day.” Multiplying by people cancels “per person”; multiplying by days then cancels “per day.” The result, 492 kg, is the amount corresponding to that simplified metabolic demand over 30 days. A real design must also account for leakage, EVA use, medical oxygen, fire response, storage losses, plant downtime and reserve policy.
MOXIE is a demonstration of a process, not a scale model of a city
MOXIE on Perseverance demonstrated that oxygen can be produced electrochemically from Martian atmospheric carbon dioxide. Across its mission it generated 122 grams of oxygen in total and reached 12 grams per hour in its best operating condition, with purity of at least 98%. Compare the best hourly rate with the simplified 20-person metabolic demand above. Sixteen point four kilograms per day equals:
16.4 kg/day ÷ 24 h/day ≈ 0.683 kg/h = 683 g/h
The unit g/h means grams per hour. Dividing 683 g/h by 12 g/h gives roughly 57. That does not mean “57 MOXIE units would support 20 people.” Scaling is not linear because compressors, thermal management, durability, storage, maintenance, operating duty cycle and reserve capacity matter. The comparison simply shows why a successful demonstration can still be far from an operational settlement plant.
Maintenance hours should be treated like a consumable
Mission mass is visible because every kilogram must be launched and landed. Human maintenance time is less visible but can become just as limiting. A settlement with 20 people has at most 480 person-hours in a 24-hour Earth day before sleep, meals, exercise, hygiene, science, administration and emergencies are considered. If routine maintenance consumes 100 person-hours per day, more than one fifth of the entire theoretical human-time budget disappears before other work begins.
This is why maintainability must be measured: mean time to access a component, mean time to replace it, tools required, protective equipment, diagnostic ambiguity, post-repair test and probability that maintenance itself introduces another fault. NASA’s current human-factors work on Mars crew complement similarly emphasizes that communication delay shifts tasks from Earth-based experts to the crew and can increase staffing requirements. A settlement must therefore budget expertise and workload, not only hardware.
Degraded modes are part of the nominal architecture
A degraded mode is a planned condition in which the system provides reduced capability after a fault. It is not the same as improvising during a crisis. A power-degraded mode might preserve life support, medical systems and communications while suspending manufacturing. A water-degraded mode might stop high-consumption hygiene and greenhouse expansion while protected potable reserves are used. A communications-degraded mode might switch from high-bandwidth Earth links to local cached procedures and a lower-rate relay.
For each degraded mode, the engineering page should state four quantities: remaining capacity, time limit, trigger for escalation and recovery criterion. “The backup works” is not enough. “The backup supports 38 kW for at least six hours at end-of-life battery capacity, after which nonessential habitat volume is isolated” is an auditable statement.
Verification needs a ladder from component to integrated failure
A component can pass its qualification test and still fail in the settlement because the environment created by neighboring systems is different. Verification should therefore progress through a ladder: component bench test; subsystem test; integrated habitat or surface-system test; fault-injection test; long-duration endurance; dusty/thermal environment exposure; robotic precursor operation; crewed analog; and, where practical, lunar or space demonstration before Mars dependency.
The most revealing tests are often not nominal. Remove a sensor. Feed a plausible but wrong reading. Delay a command. Block a filter. Simulate a failed pump. Force a software rollback. Disconnect the largest power source and watch whether the network actually enters the planned degraded state. Reliability claims become credible when the architecture has been asked to fail in controlled ways.
Primary references used in this module
Engineering workbook · turn requirements into numbers
From requirement to design: every sentence should become a measurable test
“The habitat shall be safe” is not an engineering requirement because nobody can test the word safe without further definition. “The emergency volume shall maintain breathable pressure for six occupants for 12 hours after isolation from the main habitat” is closer to a testable requirement because it names a function, population and duration. The next step would name the pressure range, oxygen and carbon-dioxide limits, temperature, leakage assumptions, battery state and measurement accuracy. This conversion from narrative to measurable requirement is one of the main differences between a concept image and an architecture.
Margins must say what they are margins on
A “30% margin” is meaningless without a baseline. Thirty percent of dry mass? peak electrical power? average energy? oxygen stock? propellant? schedule? A margin also changes as a design matures. Early studies often carry larger uncertainty reserves; later hardware can replace some uncertainty with measured performance. Delta-Sierra pages should therefore attach every margin to a quantity, phase and reason.
Example: if a water processor is expected to need 4 kW during nominal operation and the design carries a 25% power-design margin, the allocated electrical power is:
4 kW × (1 + 0.25) = 5 kW
The number 0.25 is the decimal form of 25%. Adding 1 means keeping the original 100% plus 25% reserve. This does not mean the processor will continuously consume 5 kW. It means the upstream power architecture reserves that capacity under the stated design rule.
Reliability and availability answer different questions
Reliability asks whether a system performs without failure for a specified time and environment. Availability asks whether the function is ready when needed; it therefore depends both on failures and on how quickly they can be repaired. A machine that fails relatively often but is repaired in ten minutes may have high availability. A machine that almost never fails but requires a replacement part from Earth can have terrible operational availability after its first failure.
For Mars, repair time includes diagnosis, safe access, depressurization if necessary, dust decontamination, tooling, part replacement, alignment, software/configuration work and post-repair qualification. “Mean time to repair” is useful only when those steps resemble the real environment.
Thermal control is an energy-disposal problem
Almost every watt of electrical power used inside a habitat eventually becomes heat. If electronics, lights, pumps and people consume or release 100 kW of thermal power, that heat must leave the protected volume or temperatures will rise. Mars is cold, but that does not make cooling automatically easy: the atmosphere is thin, convection is limited compared with Earth, equipment must survive large external temperature changes and radiators can be affected by dust, orientation and geometry.
This is why adding a high-power industrial process can force changes far outside its own machine. A 50 kW increase in electrical load may require larger generation, cables, converters and storage, but it can also require more heat rejection. Engineering budgets must propagate both effects.
Dust belongs in mechanical, electrical, optical and health requirements
Martian dust is not one subsystem’s problem. It can reduce optical transmission, contaminate seals and mechanisms, coat radiators and solar surfaces, enter airlocks and challenge health protection. NASA in 2026 published work toward exposure limits for Martian dust because its human-health implications remain partly uncertain and authentic airborne Martian dust has not yet been returned to Earth. That uncertainty should be visible in design requirements rather than hidden behind one generic “dust filter.”
Useful requirements therefore specify zones: dirty exterior equipment, transitional airlock volumes, cleaned maintenance spaces, medical areas and food-production zones may require different contamination controls. The architecture also needs a waste path: captured dust does not disappear when it leaves a filter.
Cybersecurity becomes physical safety
In a terrestrial office, a software fault may interrupt productivity. In a Mars habitat, software can command valves, heaters, pumps, batteries, rovers and atmospheric controls. The boundary between “IT” and “physical plant” becomes thin. A settlement therefore needs authenticated commands, role separation, offline recovery, signed software, configuration history, network segmentation and the ability to operate critical equipment locally if the supervisory network fails.
Redundancy must include software diversity where common-code failure is credible. Two pumps driven by two controllers are not independent if the same faulty update disables both controllers. Recovery procedures should be rehearsed with communications to Earth unavailable, because delay or blackout is precisely when local cyber/automation resilience matters most.
Engineering closure: name the unanswered questions
A reference architecture becomes more trustworthy when it has an uncertainty register. How does partial gravity affect pregnancy over an entire gestation? How quickly do specific seals degrade in real Martian dust? What crew size is sufficient once Earth-based mission-control work shifts to the local crew? What heavy-payload EDL architecture will achieve acceptable reliability? Which ascent-propellant strategy closes best when plant mass, energy and storage are included? Which foods remain acceptable and nutritionally stable over long storage?
Those are not embarrassing gaps; they are the map of the work still required. The engineering task is to distinguish a known unknown from an assumption accidentally presented as a fact.
Quantitative budgets · mass, power, time and uncertainty
Four budgets close the architecture: mass, power, crew time and uncertainty
Mars concepts often publish a mass budget because launch vehicles force mass to be counted. A settlement needs at least three other budgets with the same discipline. The power budget tracks continuous, peak and emergency electrical demand. The crew-time budget tracks how many human hours are consumed by maintenance, science, food production, EVA, administration and training. The uncertainty budget records what is measured, estimated or still unknown and therefore where reserve is justified.
These budgets interact. A lighter component may need more maintenance. A low-power process may be slower and consume more crew time. Automation can save crew time but add sensors, computing, software verification and cyber risk. A larger spare inventory increases landed mass but can reduce downtime. There is no single optimum component; there is an optimum trade only within a declared mission objective and set of constraints.
Example: power growth from outpost to workshop
Assume a hypothetical outpost has 40 kW of essential continuous load and 30 kW of discretionary science/manufacturing load, for 70 kW total when everything operates. If a new machine shop adds 25 kW average electrical demand and its cooling/air handling adds another 8 kW, the new average becomes:
70 kW + 25 kW + 8 kW = 103 kW
If designers then reserve 20% growth margin on that average planning figure:
103 kW × 1.20 = 123.6 kW
The factor 1.20 means the original 100% plus a 20% planning reserve. This is not a statement that a real Mars workshop needs exactly 25 kW; all values are pedagogical assumptions. The important point is that industrial growth propagates through generation, distribution, thermal rejection, spares and emergency strategy.
Example: crew-time closure
Suppose 20 residents each have, after sleep and personal time, an average of 10 hours per sol available for work, training, exercise-support duties and community tasks. The gross available time is:
20 people × 10 h/person/sol = 200 person-hours/sol
If mandatory exercise and health operations use 30 person-hours, life-support and power maintenance 45, food production 35, EVA/surface logistics 25, medical/administration 15 and training 20, committed time is:
30 + 45 + 35 + 25 + 15 + 20 = 170 person-hours/sol
Only 30 person-hours remain for science, construction, unexpected maintenance and growth. Again, the figures are hypothetical. The calculation shows why a settlement can become labor-limited before it becomes mass-limited. Automation is valuable when it reduces total human workload after its own maintenance burden is included.
Example: reserve duration is a ratio
If an emergency potable-water reserve contains 6,000 kg and the protected emergency consumption is limited to 120 kg per day for the whole settlement, ideal duration is:
6,000 kg ÷ 120 kg/day = 50 days
The kilograms cancel, leaving days. In reality, unusable tank volume, contamination, leakage and higher medical needs may reduce the usable duration. A good specification would therefore state both nominal stored mass and guaranteed usable reserve under the defined emergency scenario.
Uncertainty deserves its own register
| Item | Status | Why it matters | How uncertainty can be reduced |
|---|---|---|---|
| Local water extraction rate | Site-dependent, not yet measured for a future crew site. | Controls plant size, energy, reserve and excavation logistics. | Robotic drilling, thermal extraction tests and seasonal operation. |
| Heavy-payload EDL reliability | Architecture still under development. | Controls how much infrastructure can be pre-positioned and how much redundancy cargo needs. | Scaled tests, full-system demonstrations and repeated operational flights. |
| Long-term partial-gravity health | Major human uncertainty. | Affects exercise, medicine, reproduction and settlement permanence. | Long-duration partial-gravity research and carefully monitored missions. |
| Dust health threshold | Being refined from simulants and planetary data. | Controls airlock, filtration, cleaning and exposure rules. | Exposure studies and eventually returned/authentic material data. |
| Maintenance workload | Architecture-specific. | Determines crew complement and time available for growth. | Long-duration integrated tests with realistic fault injection. |
Requirements must survive the “so what?” test
Every number should end with a physical consequence. “The battery is 300 kWh” is incomplete; what critical load and duration does that protect? “Water recovery is 98%” is incomplete; what flow lies behind the percentage and where does the remaining 2% go? “The rover range is 50 km” is incomplete; can it return after a tire, motor or battery fault, and what rescue asset exists? “The habitat has two airlocks” is incomplete; can a common dust or fire event disable both?
This is the operating philosophy for the entire engineering branch of Delta-Sierra: a number becomes useful when its unit, boundary, source, uncertainty and consequence are all visible.
Current NASA architecture context, 2026
NASA’s current Mars trade space remains open in several high-level areas, including transportation and ascent options, while explicitly recognizing strong coupling between those choices and surface systems. The agency’s current architecture products also identify fission as the primary surface-power technology for initial human Mars missions and publish separate work on crew complement, communications delay, EDL, ascent propellant, surface power and round-trip mass challenges. The existence of those trade studies is itself instructive: a credible architecture keeps alternatives visible until evidence is sufficient to narrow them.
Design review · questions that reveal hidden coupling
A Mars design review should try to break the architecture on paper first
Design reviews are valuable when they do more than confirm that documents exist. Reviewers should deliberately search for coupling that the project team has normalized. The following questions are examples of the adversarial-but-constructive review needed before a settlement function is considered mature.
Power and thermal
If the largest generator trips, what is the exact automatic load-shedding order? Can the remaining grid black-start without the failed source? Which batteries require heating from the very grid they are expected to restart? If manufacturing is stopped, does waste heat disappear so quickly that another habitat subsystem becomes too cold? Which thermal loops cross pressure boundaries, and can a leak in one contaminate another?
Air and pressure
How is a false oxygen-sensor reading detected? Are sensors diverse in technology or merely duplicated? Can an operator close a valve locally if the supervisory network is unavailable? What is the largest credible leak that still allows time to reach a safe haven? How much breathing gas is stored outside the compartment most likely to be damaged?
Water and food
What happens when water recovery falls from its nominal percentage to a lower degraded value for a month? Which consumables limit the processor: filters, catalysts, membranes, biocide or pump parts? How many crop cycles can fail before stored food reaches the minimum reserve? Is agricultural water physically separable from potable-water contamination?
Mobility and rescue
A rover’s maximum range is not its safe operational radius. If a vehicle can travel 50 km on a nominal charge, a prudent rescue radius may be much smaller once terrain, heating, battery ageing, detours and return reserve are included. Is there a second vehicle able to tow or recover the first? Can two vehicles fail together because they received the same software update or charge from the same damaged power point?
Maintenance and inventory
Which ten components create the largest expected downtime? Which ten have the longest Earth replacement lead time? Are those the same list? Can local manufacturing reproduce the geometry but not the material treatment or electronics? What calibration tools are needed to prove that a locally made replacement is correct? Which spare parts degrade while sitting on the shelf?
Humans and operations
Who is awake when the emergency occurs? Which critical skills exist on every shift? What tasks become unsafe after a crew member is injured? Which procedures require two independent people? What decisions currently assumed to be made by Earth mission control must move to the local crew because one-way delay can approach 22 minutes?
Software and data
Can critical systems run on a known-good local version if Earth connectivity disappears? Can a software update be rolled back without internet access? Which controllers share code, libraries or cryptographic credentials? Is the offline technical library synchronized with the actual as-built hardware? How is a configuration change reviewed before it propagates to redundant equipment?
The design-review output should be a risk register with owners
Every unanswered question should produce an owner, evidence plan and due condition. “Investigate later” is not a control. A risk register should say what can happen, why it matters, how likely/severe it is under the chosen model, what currently prevents it, what evidence is still missing and what decision depends on closing it. On Mars, the value of this discipline is magnified by distance: a risk discovered after landing cannot always be bought away with rapid logistics.
A reference website cannot perform a mission program’s full review, but it can teach the reader to ask the same questions. That is the standard this engineering section is intended to reach.
Traceability · every requirement needs an origin and a verification
The architecture should be traceable from mission goal to sensor reading
Traceability means being able to follow a requirement backward to the reason it exists and forward to the evidence that proves it has been met. Suppose the goal is “crew survives loss of the primary water processor.” That goal can generate a requirement for stored potable reserve, a requirement for an independent treatment path, sensor requirements for contamination detection, inventory requirements for filters and a procedure requirement for switching modes. Each lower-level requirement should point back to the survival goal, and each should point forward to a test or inspection.
Without traceability, projects accumulate orphan requirements: numbers copied from an old study, margins whose reason is forgotten, tests that verify a component without proving the mission need. On Mars, that can become dangerous because mass pressure encourages deletion. If nobody knows why a valve, sensor or reserve exists, it is easier to remove it as “excess.” A traceable architecture can show which higher-level hazard reappears when the item is removed.
A simple requirement chain
- Goal: keep six crew alive after isolation from the main habitat.
- Hazard: main habitat pressure or atmosphere becomes unsafe.
- Function: provide an independent safe haven.
- Requirement: maintain defined pressure, oxygen, CO₂, temperature and water for a stated duration.
- Design: protected volume, tanks, scrubbers, batteries, sensors and communications.
- Verification: isolate the volume, simulate loss of external services and measure every limit for the full duration.
The exact numbers depend on mission design. The chain is universal: purpose, hazard, function, measurable requirement, implementation and proof. It is also an excellent structure for a public technical page because a reader can see why each number exists instead of encountering a table of unexplained specifications.
Configuration control keeps traceability alive after landing
The as-built settlement will drift from the original design. A valve is replaced by another model, a cable route changes, a software patch alters control logic, a temporary bypass remains in service. Traceability must follow those changes. Otherwise the verification evidence applies to a system that no longer exists. Every safety-relevant modification should therefore update drawings, part records, software versions, hazard analysis and the tests needed before return to service.
This is one of the quiet thresholds between an expedition and a civilization: the ability to preserve a trustworthy technical memory of infrastructure across years, personnel changes and repairs.
Engineering closure · when a subsystem is mature enough to depend on
“Works” is not the same as “ready for crew dependency”
A subsystem should cross several levels before a crew’s life depends on it. First, the underlying physical process must work. Second, a component must operate over the required range. Third, the subsystem must work with its real interfaces. Fourth, it must survive representative duration and environment. Fifth, operators must demonstrate diagnosis and repair. Sixth, the architecture must show a degraded mode when the subsystem is unavailable. Finally, the integrated settlement must prove that loss of the subsystem does not trigger an uncontrolled cascade.
This sequence explains why technology readiness cannot be reduced to a single number. A high-TRL component can still be immature in a new architecture if its interfaces, duty cycle or environment are different. A pump with excellent terrestrial heritage may face unfamiliar dust, fluid chemistry, gravity, maintenance access or thermal conditions. A software controller may use proven code but become a common-cause hazard when copied into every redundant channel.
The evidence package should travel with the hardware
For each critical system, the settlement should retain local access to drawings, operating limits, calibration data, software hashes, test history, known anomalies, repair instructions and the rationale for safety limits. The crew cannot depend on a cloud service or an expert who may be unreachable during a blackout. Documentation itself needs redundancy, version control and periodic exercises proving that a technician can find the correct procedure under time pressure.
The engineering goal is not perfection. No complex system can eliminate failure. The goal is controlled failure: faults are detected early, consequences are contained, people know what state the system is in, reserves create time, repairs are possible and the evidence needed to return to service is explicit. That is the difference between a machine that once worked and infrastructure that can support a settlement.
Audit rule
Every engineering budget must identify its boundary
A mass figure is meaningless if it excludes packaging, spares or landing structure without saying so. A power figure is misleading if it quotes average generation but hides peak demand and conversion losses. A recycling percentage is incomplete if the reader cannot tell which input and output streams are inside the calculation. A reliability number is weak if the duration, environment and definition of “success” are absent.
The same rule applies to Delta-Sierra calculations. Each worked example must identify what the number represents, what units are used, which assumptions are pedagogical, which values come from a source and which physical effects are intentionally omitted. The calculation can then be simple without being simplistic. A beginner sees every step; an engineer can see where a higher-fidelity model would replace the approximation; a journalist or decision-maker can trace the conclusion back to the underlying assumptions.
Engineering principle: optimise the mission, not the component
The best engine, greenhouse, reactor or habitat in isolation may not produce the safest settlement. Interfaces, logistics, repairability and common-cause failures determine whether the architecture survives. Every major choice should therefore be tested against mass, power, volume, crew time, failure recovery and long-term expansion.
Scope and limits of this overview
This overview introduces public evidence and the principal system choices. It does not reproduce the full sequences, tables, operational reasoning or integrated city model developed in Arcadia — Manual of the First Martian City.
Live engineering developments
Official news, mission channels, NASA and ESA reports, and current broadcasts.
Open live missionsDelta-Sierra calculators and data
Each engineering tool keeps its assumptions and arithmetic visible so a reader can test sensitivity, reproduce the order of magnitude and identify where a conclusion depends on a chosen scenario.
