Spares for a one-way trip

No second shipment

In 2123 the SS Mariposa left Earth for the Ficus sector with nine crates of Model 4077 cores, 25 to a crate, and no return leg. Everything the crew would need to keep those cores running had to be in the hold on the day it left. A data centre on Earth can order a part and have it the next day, and the International Space Station is resupplied every few months.² A ship on a one-way crossing has no second shipment.

NASA has studied this problem for crewed Mars missions, where a transit habitat may spend about 1,100 days out of reach. "Because spare parts cannot be flown as needed for Mars missions," Stromgren and colleagues write, "all required spares must be flown with the mission or pre-positioned."¹ We use their framework here. Our trip is about 13 times longer, and the hardware is one repeated design rather than thousands of different components. Both differences matter.

The 4077 is built for this. Its four modules come out from the front, and its datasheet promises a 40-year MTBF (mean time between failures). We split that rate across the modules and the chassis as in the table below. The split and the masses are this note's inputs, not measurements; the calculator and the code let you change them.

One point before the arithmetic. An MTBF of 40 years does not mean a core lasts 40 years. It describes a rate: "the types of random failures defined by MTBF have nothing to do with accumulated lifetime; rather they are failures that can occur randomly at any time."¹ 225 cores at one failure per 40 core-years produce, on average, 225 failures in 40 years, about one every two months.

Counting failures

If failures arrive at a constant rate and each failed part is replaced by a fresh spare, the number of failures of part i across the fleet over the mission is Poisson-distributed. Its mean is the number installed, times the rate, times the time. The chance that s spares are enough is NASA's probability of sufficiency (POS):²

With independent parts, the fleet's POS is the product over parts. This is why NASA sets one target for the whole system and lets each item's level float: five parts each at 0.999 give only 0.995 together.²

For M1, μ = 225 × 40 / 133 = 67.5. The standard deviation of a Poisson count is the square root of its mean, about 8.2. So 98 spares, the mean plus 3.7 standard deviations, leave a 0.02% chance of running short. That is the share of a 0.999 fleet target that falls on M1. Chance alone needs a margin of about 45% over the mean, and the margin shrinks as the fleet grows, because the square root grows more slowly than the mean. For an item expected to fail once or twice, as many items in a habitat are, the margin can be several times the mean. A fleet of identical parts is the easy case, as long as the rate is right.

What to carry

There are three ways to pack for the same fleet target.

• Spare whole cores, swapped whole. Every failure, whatever its cause, uses up a core: demand is Poisson with mean 225. For 0.999 that is 273 spare cores, more than doubling the cargo.
• Spare whole cores, stripped for parts. A broken core's good modules go back into stock, so a spare core is a kit of one of each part. You need enough kits to cover the worst-hit part. That is 94 cores.
• Separate modules and chassis. Buy each part in the quantity its own demand needs, and add the spare that buys the most POS per kilogram each time. This is the greedy "marginal analysis" used by NASA Langley's EMAT tool, which "examines each possible spare that could be added, selecting the spare that most effectively reduces risk from a mass perspective".^1,4 The result is 98, 84, 71 and 71 modules and 24 chassis: 348 parts with the mass of about 51 cores.

Most of the saving comes from repairing inside the core at all (273 → 94). The rest comes from no longer paying for a 0.52-core chassis every time an M1 fails. The chassis is the heaviest part and the least likely to fail, so a kit of whole cores is mostly chassis that will never be needed. This is what "every module comes out from the front" buys on a ship: the 4077 was designed so that the part you carry is the part that fails.

Stripping broken cores for parts also makes the arithmetic simple. If part i has s_i spares and suffers D_i failures, then n + s_i − D_i good copies of it exist at the end, and the number of cores you can assemble is

We checked Equation 2 against a simulation that plays out each failure, repair and strip-down in order over 40 years. For the module kit the two agree within the simulation's noise: 0.99905 ± 0.0002 simulated, against 0.99906 from Equation 2. The tougher test is the kit sized for 10 tolerated losses (next section), where cores really do sit dead and get stripped: 0.99898 ± 0.0002 simulated against 0.99906.

Letting a few cores go

Equation 2 has a useful consequence. Suppose the mission still succeeds with up to m dead cores, because the ship only needs 225 − m to run. Then

Each core you can afford to lose is worth one free spare of every part. With m = 10 the module kit drops from about 51 cores of mass to about 41, and with m = 20 to about 31. This is the spares-versus-redundancy trade in its simplest form. Owens and de Weck note that, ignoring repair time, a cold spare and a redundant unit are "functionally nearly equivalent".² Section 7 covers the case where they are not.

Luck versus ignorance

Everything so far assumes the rates are exactly right. They won't be. NASA separates two kinds of uncertainty. Aleatoric uncertainty is chance: how many failures a known rate happens to produce. Epistemic uncertainty is ignorance: not knowing the rate itself.¹ The Space Station's record shows how much the second kind matters. Predicted MTBFs of its components run "from a low of about 2,000 hours to a high of 100 Million+ hours". By 2016 over half had been revised: about 85% upward and 15% downward, and about 3% to a quarter or less of the original estimate.¹

ISS practice describes the uncertainty in each failure rate with a lognormal error factor, the ratio of the 95th percentile to the median.⁷ We take the datasheet rate as the median, so the mean rate is a little higher (by 9% at an error factor of 2). Give M1 an error factor of 2. The spread of M1's demand then grows from 8.2 to 33.6. Of that variance, 93% comes from not knowing the rate and only 7% from chance:

This is the reverse of the small-count case. With one or two spares per item, chance dominates. With 67 expected failures, chance is cheap to cover and ignorance is not.

The fleet suffers more than any single part does, and in one direction. Fly the nominal kit, then draw each part's true rate independently, each with a factor-2 error. Some parts come out better than planned, but their POS was already near 1 and has little room to rise. Parts that come out worse lose a great deal. The median fleet POS falls from 0.999 to 0.44, and about 95% of draws end below target. Stromgren and colleagues found the same asymmetry in their Mars habitat model. Even there, with 85% of components likely to come out better, "it is this very small number of critical components that drive the behavior and reliability of the entire system."¹ A kit designed for a 1-in-1,000 risk delivered a median of about 1 in 37 under ISS-like uncertainty.³

If instead the error is shared, with the whole design better or worse than the test campaign said, the median stays at 0.999. But it becomes a coin toss whether the true POS is above or below target, and the bad half can be very bad. For a single design flown in quantity, a shared error is the more realistic case: the 225 cores came from the same line and the same qualification tests.

There are two ways to pay for this:

• Plan at the pessimistic rate. Size every part for its 95th-percentile rate. For an error factor of 2 this is about 91 cores of mass instead of 51, 1.8×. If the error is shared across the design, that kit meets 0.999 with 95% confidence. If each part errs separately it does so only about 82% of the time, because with five parts, one of them often comes out worse than its 95th percentile. For comparison, NASA's Mars habitat needed about 2.0× (low uncertainty) and 2.8× (high) the mass to restore its target at 95% confidence: over 12,000 and 17,000 kg against 5,984 kg.¹
• Average over what you don't know. Size against the mixed distribution. At a 0.999 target this is the more expensive option: about 140 cores of mass at ×2, about 340 at ×3, and over 1,000 at ×5. The kit then has to cover rates in the far tail of the lognormal, so the result depends mostly on how far you trust that tail. These figures are approximate.

Testing narrows the error factor more slowly than you might hope. Stromgren and colleagues put the operating time needed for confidence in an MTBF at about three times the MTBF.¹ A simple Bayesian count shows why. After 10 observed failures the rate is known to about ×1.6, and after 30 to about ×1.3. For M1 at its nominal rate, 10 failures take the whole 225-core fleet 6 years of running, and 30 failures take 18 years. For the chassis, 10 failures take 36 years. You cannot burn the uncertainty off on the ground before departure. The ship learns its rates on the way, when it can no longer order more.

Same MTBF, different ageing

A constant rate is an assumption. A Weibull lifetime with shape β below 1 fails early and then settles, β = 1 is the constant-rate case, and β above 1 wears out. We simulated M1 as a renewal process with each shape, keeping the same 133-year mean life. Every replacement starts as a new part. We also simulated two cases where a wear-out mechanism (β = 4) that never appeared in qualification is added on top of the random failures.

The constant-rate simulation reproduces the Poisson answer (98). Genuine wear-out against a 133-year mean helps: few parts reach old age in a 40-year trip, so only 13 spares are needed. Early failures hurt, because every fresh spare repeats its own early-life risk. That is an argument for burn-in before the spares are packed. The cases that should worry a planner are the last two. A wear-out mechanism with a characteristic life of 45 years (mean about 41) doubles M1's spares. One at 30 years (mean about 27) means nearly every M1 module in the fleet is replaced once, for 310 spares instead of 98. None of this is visible in a constant-rate MTBF measured over the first few years of service.

The NASA sources treat wear-out as scheduled replacement of life-limited items. This renewal treatment is our own.^2,3 Spares also age in storage, and a part that sits in the hold for 30 years is not new when it is fitted. We do not model dormant ageing.

When spares help least

Jones separates two kinds of common cause failure. A common event, such as a fire or a power surge, hits everything at once. A common mode, such as a design or manufacturing defect, makes identical parts fail in the same way, though usually not at the same moment. "Common event failures reduce the reliability of on-line redundant systems but not of systems using off-line spare parts. Common mode failures reduce the dependability of systems using off-line spare parts and on-line redundancy."⁶ In the Shuttle anomalies he reviews, 11% were common cause. The largest coupling factor was the same part design, at 27% of dependent failures.⁶

Spares sitting in the hold are protected from common events, which is one reason to carry spares rather than run everything in parallel. Against a common mode they help less, because spares from the same lot share the defect. Suppose a latent defect fails 30% of all M1 modules at some point in the mission, including 30% of the spares. The nominal kit does not survive it. A 1% chance of such a defect over the mission takes the fleet's 0.999 down to 0.989, about eleven times the risk the kit was sized for, before any rate uncertainty. Even a 10% defect leaves the nominal kit only a 45% chance.

Spares can cover a known defect: 260 M1 spares instead of 98 ride out the 30% case, about 19 cores of extra mass, and 141 cover the 10% case. The trouble is that nobody knows the fraction in advance, and the cost grows with every fraction you choose to cover. Design diversity costs a fixed amount and covers every fraction, so the main defence has to come from design and from the sources of supply: two production lots or two revisions of each module type, packed separately, and repair below the module level, so that a recurring fault becomes a known fix rather than a dwindling stock. Stromgren and colleagues make a related point. ISS failures traced to design or manufacturing deficiencies were "diagnosed and rectified" on the ground, and so dropped out of the rate updates.¹ A one-way ship cannot send the part back to be fixed.

What we do with this

Four rules come out of this, and they are the rules the YS·CORE team uses for long-haul spares:

1. Carry the part that fails. Repair inside the core and pack modules by type. Spare cores belong in the kit only for the chassis, which nothing else replaces.
2. Size for the rate you might have, not the rate you hope for. State an error factor for every part and size to its 95th-percentile rate. That buys 95% confidence only against an error shared by the whole design, so add margin where parts could err separately. Don't trust a 0.999 that assumes the datasheet is exact.
3. Treat dead cores as stock. Plan how many cores the mission can lose, and strip the dead ones for parts. Every tolerated loss is a free spare of every part.
4. Split the lots. No module type flies with all its spares from one production lot. Keep enough tools and parts aboard to repair modules, not just swap them.

See the Compute Cores datasheet for the 4077's module layout.

Calculator

Change any input and the kit is re-sized. It uses the same model as the code: Poisson demand, stripping dead cores for parts, least-mass allocation, and an error factor applied as "every rate at its 95th percentile". Masses are relative; only their ratios matter.

The calculator needs JavaScript. Figure 1 and its table view give the results for the default inputs, and sparing.py runs the full model.

Limits of this note

• The 4077's failure split and part masses are inputs we chose for illustration. The 40-year MTBF is the datasheet figure. None of these are field measurements.
• Equation 2 assumes repairs always succeed and take no time. Our Poisson demand also counts failures as if all 225 cores always run, when a dead core's parts in fact stop running. The event-by-event simulation models this and agrees within its noise. We ignore induced failures, damage during repair, and crew time. On the ISS, life-support maintenance planned at about 1 hour a week took 13–15.⁷
• Rate errors are lognormal with median 1, either independent per part or shared. The real ISS revision distribution is skewed toward improvement and is only published as a summary;¹ its raw data are in a limited-access database.
• The wear-out cases are scenarios, not fits, and we do not model spares ageing in storage. The common-mode case is a single defect in one part type.

References

1. C. Stromgren, K. Goodliff, W. Cirillo and A. Owens. "The Threat of Uncertainty – Why Using Traditional Approaches for Evaluating Spacecraft Reliability Are Insufficient for Future Human Mars Missions." AIAA SPACE 2016, Long Beach, CA. NTRS 20160011578.
2. A. C. Owens and O. L. de Weck. "Limitations of Reliability for Long-Endurance Human Spaceflight." AIAA SPACE 2016, Long Beach, CA. NTRS 20160012010.
3. A. C. Owens and O. L. de Weck. "Systems Analysis of In-Space Manufacturing Applications for the International Space Station and the Evolvable Mars Campaign." AIAA SPACE 2016, Long Beach, CA. NTRS 20160011570.
4. A. Owens, O. de Weck, B. Mattfeld, C. Stromgren and W. Cirillo. "Comparison of Spares Logistics Analysis Techniques for Long Duration Human Spaceflight." ICES-2015-288, Bellevue, WA, 2015. NTRS 20160006509.
5. W. Cirillo, K. Goodliff, G. Aaseng, C. Stromgren and A. Maxwell. "Supportability for Beyond Low Earth Orbit Missions." AIAA SPACE 2011, AIAA-2011-7231, Long Beach, CA. NTRS 20110015914.
6. H. W. Jones. "Common Cause Failures and Ultra Reliability." ICES 2012, AIAA-2012-3602, San Diego, CA. NTRS 20160005837.
7. A. C. Owens, O. L. de Weck, C. Stromgren, W. Cirillo and K. Goodliff. "Supportability Challenges, Metrics, and Key Decisions for Future Human Spaceflight." AIAA SPACE 2017, Orlando, FL. NTRS 20170009115.

Reproduce

Every computed number in this note comes from sparing.py, which states all its inputs at the top. You need Python 3.10+, NumPy and SciPy; it runs in about two minutes, most of it in the rate-uncertainty and wear-out simulations.

python code/ys-en-0004/sparing.py          # strategies, k-of-n, uncertainty, wear-out, common mode → results.json
python code/ys-en-0004/build_figures.py    # rebuild the figures in this page

• sparing.py: the model, with its inputs
• results.json: every computed value
• check_cannibalisation.py: event-by-event simulation that checks Equation 2
• build_figures.py and svgchart.py: figure generation
• sparing-calc.js: the calculator
• LICENSE: the scripts are MIT-licensed. Use them freely, keep the notice; they come with no warranty

Changelog

• 2026-10-05Rev 1. First publication.