How to do a RAM study

A RAM study answers a deceptively simple question: how much of the time will this system do its job, and what is stopping it? Getting a defensible answer takes more than drawing a block diagram — it is a sequence of decisions about scope, data and analysis, each of which shapes the result.

Two contexts use the same eight steps, with different data sources:

• Design phase — before the asset is built: compare options, verify an availability target, size spares and buffers. Data comes from generic handbooks and vendor estimates.
• Operational phase — an asset already running: find the bad actors, justify upgrades, tune maintenance. Data comes from your own failure history.

Start with the question, not the model. A study built to compare two pump configurations looks different from one sizing a warehouse of spares. Pin down three things before drawing anything:

• The boundary — what equipment is in scope, and what “the system is up” means functionally. A clear success criterion (e.g. “delivers ≥ 50 t/h to the export line”) is worth more than a long equipment list.
• The objective — a single availability figure? a design comparison? a spares-holding decision? This decides what you must model in detail and what you can lump together.
• The metric and mission time — which availability you are reporting (operational vs. production — see types of availability), and over what period (design life, a maintenance cycle, a contract term).

Translate the system into a success path — a reliability block diagram. Each piece of equipment becomes a block; the structure encodes how they combine:

The craft is picking the right level of detail: model what drives downtime, lump what doesn’t. A motor whose failures never reach the system boundary may not need its own block; a single-point-of-failure valve always does.

This is the step that makes or breaks a study. Every component needs a failure behaviour (a distribution and its parameters) and a repair behaviour. Garbage in, garbage out — and the data is rarely handed to you cleanly.

Where the numbers come from

• Industry databases — OREDA (offshore & onshore reliability data) and the ISO 14224 equipment taxonomy are the common references for oil & gas.
• Vendor data — manufacturer reliability figures for specific equipment.
• Plant history — your own CMMS / maintenance records, the best source for an operating asset.

Document the provenance of every figure — a reviewer will ask.

Choosing a distribution

The difference between the idealised inherent availability and the realistic operational one is your support organisation. A study that ignores it is optimistic by exactly the downtime your logistics add. Model the real constraints:

• Preventive maintenance — planned outages at intervals.
• Spares — finite warehouse stock; when the shelf is empty, the repair waits for replenishment.
• Repair crews — a limited team shared across equipment; simultaneous failures queue.
• Logistics delay — mobilisation, permits and parts-on-order before work even starts.
• Common-cause failures and buffers — shared-cause events, and storage that rides through short outages.

With the model and data in place, set the run parameters: mission time, number of Monte Carlo runs, an optional fixed random seed (for reproducibility), reporting windows and which blocks to track. Then run it.

Start small — around 1,000 runs — while you iterate on the model, then raise the count for the final numbers. The key check is convergence: the confidence interval on availability must be tight enough that it wouldn’t change your decision. A wide interval means run more.

A headline availability number is the start, not the finish. Report it with its uncertainty — average plus P10/P50/P90 percentiles, not a single optimistic point — and then do the part that drives action: find out where the downtime comes from.

• Importance measures — Birnbaum, RAW and RRW rank which components contribute most to system unavailability.
• Sensitivity — how the answer moves if a component’s MTTF or MTTR is 20% better or worse, showing where better data or better equipment pays off.
• Loss contributors — in production terms, which subsystems account for the most lost throughput.

A RAM study earns its keep by comparing alternatives: two pumps vs. three, hot vs. cold standby, a bigger buffer vs. more spares. Model each as a variant, run them, and put the KPIs side by side. With a cost model attached, you can weigh availability gained against money spent — the comparison that actually settles a design argument.

Finally, write it up: assumptions, data sources and their provenance, the model, the results, and clear recommendations. A study no one can reproduce is not defensible — record the random seed and the exact inputs so the numbers can be regenerated on demand. Then iterate, as the design firms up or operational data accumulates.