Availability has no analysis method that is purely its own: it is computed by combining what the reliability toolkit predicts with what the maintainability toolkit budgets, inside models that know the system's structure and its support. That makes this chapter's map a map of confluences: which methods produce the inputs, which models combine them, and where the measured truth comes back in. As before: what each method answers, how they chain, where the platform stands, and how the emphasis shifts by industry.
The availability toolkit
| Method | The question it answers | Typical phase | Read more |
|---|---|---|---|
| RBD availability modelling | What availability does this structure deliver, given failure and restoration rates? | Design onward | Topic planned |
| Markov state modelling | What happens when repair, detection, and switching couple the states? | Design, on redundant clusters | Within the RBD family of structure models |
| Reliability Prediction | The λ inputs: how often each item will fail | Design | Full topic published |
| Maintainability Prediction | The MTTR inputs: how long each repair takes | Design | Topic planned |
| Maintenance Task Analysis and LORA | The support inputs: task times, echelons, turnaround pipelines behind MLDT | Design and support planning | Topics planned |
| Fault Tree Analysis | The on-demand form: unavailability of a protective function, cut sets of the ways it hides | Design | Topic planned |
| Testability Analysis | The detection inputs: which failures announce themselves, which wait for a test | Design | Topic planned |
| FRACAS | The measured truth: observed Ao, downtime by cause, the Ai-to-Ao gap's anatomy | Field | Topic planned |
Two rows deserve a note. Markov modelling appears without a tile of its own because in practice it is a zoom lens inside the structure-modelling family: the RBD covers the breadth of the system with product-rule arithmetic, and the state model takes over on the few clusters where shared crews, latent failures, or switchover risk break the product rules (the systems chapter drew that boundary). And fault tree analysis enters the availability toolkit wearing its unavailability hat: for safety and protective functions, the tree's top event probability is an availability statement, the on-demand kind, computed from the same λT/2 latent arithmetic the foundations chapter built.
How the methods chain together
- The inputs converge. Prediction supplies the failure rates; the maintainability chain supplies repair times and, through task analysis and LORA, the logistics behaviour behind MLDT; testability supplies the detection split that decides which failures are announced and which are latent.
- The models combine. RBD availability arithmetic across the system; Markov on the coupled clusters; fault trees on the protective functions; sparing and simulation models where the support network's stocks and queues need explicit treatment.
- The budget flows down, the number flows back. The Ao target becomes a downtime budget allocated in minutes per year; the fielded system reports observed availability through FRACAS with every downtime hour categorised by cause; and the predicted-versus-observed gap is decomposed into its reliability, maintainability, and logistics parts, each finding routed to the analysis that owns it.
The chain's characteristic failure is stale convergence: an availability model quietly running on last year's failure rates and the proposal-phase repair times. Because availability sits downstream of everything, it inherits every upstream revision, and a model that is not rebuilt when the prediction or the maintenance concept changes is not conservative; it is fiction with confident decimals.
Where RAMSynapse stands
The built modules cover the confluence's core today: Reliability Prediction computes the failure rates on the shared system model, and the RBD module combines them through series, parallel, and k-out-of-n structures into system reliability and availability, with the rates flowing as live links rather than exports; the Fault Tree module quantifies top-event probabilities on the same shared rates, and the live module ring shows the flow as it runs. The restoration side of the confluence (Maintainability Prediction's MTTR roll-up, task analysis, LORA) is on the roadmap, with the designed topology routing MTTR into the RBD's availability arithmetic exactly as this chapter's chain describes; until those modules ship, the disciplines they implement are covered here in RAMS Core.
Industry lenses
| Industry | What availability work typically looks like |
|---|---|
| Defence and aerospace | Ao as a contractual sustainment KPP; performance-based logistics; the radar-station arithmetic at fleet scale |
| Nuclear | Production availability through outage critical-path management; on-demand availability of protective functions through proof-test programmes |
| Energy and resources | Energy-weighted availability factors; turnaround planning; condition monitoring converting unscheduled to scheduled |
| Railway | Service availability inside the EN 50126 RAMS case: punctuality and cancellation targets flowing down to fleet and infrastructure downtime budgets |
| Electronics and high tech | The nines culture: redundancy, failover rehearsal, and service-level agreements as civilian PBL |
| Medical devices | Uptime of clinical and laboratory systems under service contracts; loaner and swap pools as the logistics lever |
| Automotive | Vehicle-off-road time and dealer-network parts logistics; availability as a warranty and brand economics problem |
| Space systems | Availability without repair: redundancy management, graceful degradation, and ground-segment continuity carrying the whole burden |
The emergency call centre from the overview would sit in every row at once: telecoms, power, buildings, staffing, and procedure composing one availability chain. That is the general lesson of the lenses: the mathematics of this book is identical everywhere, and what changes is which slice of downtime the sector prices highest, and therefore which lever (design, repair, logistics, or architecture) its money flows to first.