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 | Full topic published |
| 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 | Full topic published |
| Maintenance Task Analysis | The support inputs: task times and crew demand behind MLDT | Design and support planning | Full topic published |
| Level of Repair Analysis | The support inputs: echelons and turnaround pipelines behind MLDT | Design and support planning | Full topic published |
| Fault Tree Analysis | The on-demand form: unavailability of a protective function, cut sets of the ways it hides | Design | Full topic published |
| Testability Analysis | The detection inputs: which failures announce themselves, which wait for a test | Design | Full topic published |
| FRACAS | The measured truth: observed Ao, downtime by cause, the Ai-to-Ao gap's anatomy | Field | Full topic published |
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.
Industry lenses
| Industry | What availability work typically looks like |
|---|---|
| Defence and aerospace | Ao in support contracts, under a fleet-level materiel availability 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.