Four reaction wheels of which three are needed, two star trackers, three magnetorquers and an onboard computer with a cold spare, flying a seven-year mission with no possibility of repair. Every other system in this column has an MTTR to put into a formula. This one has none, and the formula every engineer reaches for first, A = MTBF/(MTBF + MTTR), quietly collapses when there is nothing to substitute.
The availability question for a spacecraft is therefore not whether the vehicle is alive. It is whether the payload was pointing correctly when a customer's imaging order came due, and answering it means choosing a denominator before choosing a model. That choice moves the reported number by a factor of two on this system, which makes it the most consequential piece of engineering on the page.
The technique, and why this one
Service-clock outage accounting: an explicit outage ledger measured against the imaging service's own opportunity window, with no repair term at all and each safe-mode entry treated as a whole-service outage. There is no steady state to solve for, because the system is not repairable and never returns to as-good-as-new; there is no repair rate to feed a Markov model, and setting μ = 0 in A = μ/(λ + μ) gives A = 0, which is arithmetically true over infinite time and useless over seven years. What remains is bookkeeping done carefully: count the outages, decide what an outage costs, and decide what it is a fraction of.
| Quantity | Model | Value |
|---|---|---|
| Reaction wheel (4 fitted, 3 needed) | Weibull, β = 2.2, η = 15 years | drives the reliability multiplier, not the outage rate |
| Star tracker (2 fitted) | exponential | λ = 150 per 10⁶ h each |
| Magnetorquer (3 fitted) | exponential | λ = 60 per 10⁶ h each |
| Onboard computer plus cold spare | exponential, spare dormant at 10% of λ | λ = 200 per 10⁶ h |
| Safe-mode entries | empirical outage stream | 2.5 per year, 18 h each |
| Ground restoration | task-time build-up, no second attempt | 7.2 h (40 min detect, 4 h diagnose and decide, 2.5 h uplink and confirm) |
| Imaging service clock | denominator | daylit portion of the orbit, 4,380 h a year |
| Tasked imaging | utilisation of the clock | 22% of orbit time, 1,927 h a year |
Choosing the denominator, and what it costs
An Earth-observation payload can only be scheduled on the daylit side of the orbit, so the service clock is roughly half the calendar:
imaging opportunity = 8,760 / 2 = 4,380 hours a year
of which the mission actually books 22% of orbit time,
tasked imaging = 0.22 × 8,760 = 1,927 hours a year
so the payload uses 1,927/4,380 = 44% of the opportunity available to it. Safe mode costs
safe-mode time = 2.5 entries × 18 h = 45 hours a year
and charged in full against the service clock that is
45 / 4,380 = 1.03% of imaging availability
Now the choice. An eighteen-hour safe mode spans about eleven orbits, so only half of it falls in daylight; charging only the daylit fraction gives 22.5 hours and halves the answer to 0.51%. Both ledgers are defensible and they differ by a factor of two on the headline number. The mission carries the full-outage convention, on the grounds that a passing daylit opportunity inside a safe mode is not merely unused but unrecoverable, since the ground track has moved on and the target will not be under the spacecraft again for days. Write the convention down before the first report, or the number becomes an argument rather than a measurement. The general form of that warning lives in the foundations chapter; this is the sharpest instance of it in the column.
The rest of the ledger
Operational availability of the imaging service is 0.983, an unavailability of 1.7%, which on the 4,380-hour service clock is
total service outage = 0.017 × 4,380 = 74.5 hours a year
Safe mode owns 45 of those hours. The remaining
74.5 − 45 = 29.5 hours a year
belongs to everything else standing between an ordered image and a delivered one: contact opportunities missed, tasking uploads that arrive too late for the pass, calibration slots, and the ground segment's own outages. That residual is 0.67 percentage points, and it is a legitimate part of an availability figure that carries the word "service" in its name. A spacecraft-only ledger would report a better number and would not describe anything a customer buys.
The eighteen hours, dissected
Mean restoration builds up as a task sequence rather than as a repair time:
restoration = 0.67 h detect + 4 h diagnose and decide + 2.5 h uplink and confirm = 7.2 h
The safe-mode event is charged at 18 hours, so
18 − 7.2 = 10.8 hours per event
is time during which nobody is doing anything to the spacecraft. It is waiting: for a contact opportunity, for a decision, for the imaging schedule to be rebuilt and re-uploaded. That is the space-segment version of the aircraft's 26 hours at an outstation in this same column, and it responds to the same class of remedy: more contact opportunities, pre-authorised recovery procedures that do not need a committee, and a rehearsed duty roster. The maintainability page treats the 7.2 hours as a restoration task and optimises it; the availability ledger cares about the 18, and 60% of the 18 is not maintainability's to fix.
There is also no second attempt. A repairable system's availability model assumes that a failed repair simply lengthens the queue. Here an incorrect wheel reassignment can end the imaging mission outright, which is why the four-hour diagnose-and-decide block is the longest single element and why nobody tries to compress it.
The multiplier nobody puts in the availability number
The 0.983 is a conditional figure: it describes the service given that the spacecraft is still capable. It has to be multiplied by the probability that it is, and the reliability page supplies that from a Monte Carlo of the ageing wheel set. Per-wheel reliability at seven years, with β = 2.2 and η = 15 years (131,400 h), is
R = exp(−(61,320 / 131,400)^2.2) = exp(−(0.4667)^2.2) = exp(−0.1837) = 0.832
R_3oo4 = R⁴ + 4R³(1 − R) = 0.479 + 4(0.5758)(0.168) = 0.866
and the whole AOCS reaches 0.81 at end of life. The service the customer receives over the mission is therefore closer to 0.81 × 0.983 than to 0.983, and the difference is not an availability failure at all: it is a wear-out curve. On a non-repairable system, availability and reliability stop being separable properties, because there is no repair loop to reset the clock, and quoting one without the other overstates the service by nearly twenty points.
What the analysis tells the engineer to do
Three findings, in the order the budget should read them. Attack the 10.8 hours of waiting first, because it is the largest single block, it is entirely ground-segment cost, and it needs no hardware: additional ground station passes, standing authority for a defined set of recovery actions, and a rehearsed reconfiguration procedure. Attack the safe-mode entry rate second, since each avoided entry is 18 hours and the entries are triggered by attitude anomalies that better fault management can often ride through without dropping the payload. Accept the reliability multiplier third and design for it before launch, because after launch there is no lever at all: everything available to the operations centre is already in orbit.
The support-system lever that dominates every other page in this column is absent here. There are no spares to position, no crew to add, no repair queue to shorten. Availability on this system is bought entirely before launch, or in the operations centre, and nowhere else.
What a different technique would have given
The plausible alternative is calendar-clock availability, the measure every other repairable system in this chapter reports. Forty-five hours of outage in 8,760 gives
A_clock = 1 − 45 / 8,760 = 0.99486
which reads better than 0.983, is arithmetically correct, and describes nothing anybody buys. It counts eclipse passes as available service, so it improves every time the payload is idle, and it would let an operator raise the reported availability by reducing the tasking load. A measure that rewards not working is not a measure.
The second alternative is the one an availability engineer reaches for by reflex: a Markov model with failure and repair transitions. It was rejected because there is no repair transition to write down. Ground reconfiguration is not repair; it re-assigns a function to surviving hardware, once, with no guarantee and no rollback, and it leaves the system permanently poorer. A Markov model would need an absorbing state for every degradation step and would spend its entire structure describing a system that only ever moves downhill, which is a reliability question already answered by the Monte Carlo next door.