Each module's failure risk follows a Weibull "bathtub" wear-out hazard, the standard reliability-engineering model for hardware whose failure rate rises with age since it was last serviced (seals dry out, filters foul, sorbent saturates):
hazard h(t) = (k/λ) · (t/λ)^(k-1)
reliability R(t) = exp( -(t/λ)^k )
per-step failure chance ≈ h(t) · dt
t = simulated days since the module's last service, λ = its characteristic life, k > 1 = wear-out shape (bigger k = the hazard rises faster as the part ages). System reliability is the product of every module's R(t).
- Preventive — a module is auto-serviced (age reset to 0) once its reliability drops below the threshold, but only if this week's crew-hour budget still has room. Planned service costs 2 crew-hours.
- Reactive (run-to-fail) — nothing is serviced early; a module runs until it actually fails (a live draw against h(t)·dt), forcing an unplanned repair that costs 6 crew-hours and counts against the failure tally.
- Crew-hour budget — resets every 7 simulated days. Spending more hours than the budget in a week shows as overtime (the readout turns amber/red) — the real trade-off every ECLSS maintenance plan has to make.
- Click any rack in the 3D view (or its row in the Modules list) to select it, then Service Selected Module to repair it manually regardless of strategy.
Real-world relevance: this is the same logic that sizes ISS ECLSS spares manifests and crew-timeline budgets — deferring maintenance saves crew-hours short-term but raises the odds of an unplanned failure that costs far more time to fix.