Learn Ramly

Ramly is a browser-based tool for Reliability, Availability and Maintainability (RAM) analysis. You describe your system as a reliability block diagram (RBD), attach failure and repair behaviour to each piece of equipment, and Ramly runs a Monte Carlo simulation — thousands of simulated lifetimes — to predict availability, failure counts, production throughput and downtime cost.

No installation is needed; everything runs in the browser. Models are saved to your account, simulations execute on Ramly servers, and results stay attached to the model for comparison and reporting.

A RAM study quantifies three related properties of a system:

For repairable systems in steady state, availability relates to the two mean times: A = MTTF / (MTTF + MTTR). The mean time between failures is the full cycle: MTBF = MTTF + MTTR.

Why simulation instead of a formula?

Closed-form formulas only work for simple structures with constant failure rates. Real plants have redundancy, standby equipment, shared repair crews, limited spares, buffer tanks and ageing equipment — interactions no formula captures. Monte Carlo simulation handles all of this by simply replaying the system’s life many times with randomly drawn failure and repair times.

From one reliability block diagram, Ramly answers several distinct questions. You pick a solution method — Monte Carlo simulation or the exact analytical (Markov) solver — and the relevant outputs come back together.

Two solution methods

See Monte Carlo vs Analytical for the full decision guide.

The outputs

“Availability” is not a single number — which one you mean depends on what you count as downtime. Engineering practice distinguishes several, ranging from an idealised design figure to the throughput-weighted number a production-assurance contract is actually written against.

Inherent vs. operational — why they differ

Inherent availability uses only the two mean times, Ai = MTTF / (MTTF + MTTR), where MTTR is the active repair time alone. Operational availability replaces that repair time with the full mean down time (MDT) — repair plus every delay around it: Ao = MTTF / (MTTF + MDT). Because MDT is never smaller than MTTR, operational availability is always the lower, more honest number. The gap between the two is exactly the downtime your support organisation adds: spares that aren’t on the shelf, crews that are busy, parts on order.

Production availability — when “up” isn’t binary

Plain availability treats the system as either up or down. A plant with redundant trains is rarely so simple: losing one of three trains may drop output to two-thirds rather than to zero. Production availability weights downtime by the production actually lost, so a partial outage counts in proportion to the throughput it removes — the metric most production-assurance studies are contracted against.

Common reasons reliability engineers run RAM studies:

• Compare design options — does a third pump (2-of-3) buy enough availability to justify its cost? Is cold standby sufficient, or is hot redundancy required?
• Verify availability targets — demonstrate that a design meets a contractual or internal availability requirement before it is built.
• Size spares and buffers — how many spare pumps should be in the warehouse? How much storage capacity bridges a typical outage?
• Evaluate maintenance strategy — quantify the effect of preventive-maintenance intervals, crew sizes and logistics delays on production.
• Quantify production loss — translate downtime into lost throughput and money, so reliability investments can be ranked against each other.
• Find the critical equipment — importance rankings show which components dominate system unavailability, focusing engineering effort where it matters.

RAM analysis is supported by a body of international standards. The most relevant to the methods used in Ramly:

This list is informative, not exhaustive. Always consult the current edition of a standard and your company’s own engineering practices for contractual work.

1. 1

   Create your account

   Sign up free at ramly.io — no credit card. Every new account starts with a 14-day Professional trial.

2. 2

   Explore the example models

   Your account comes pre-loaded with six real-world example models (oil & gas pumping, gas compression, air separation, offshore wind, green hydrogen, and an analytical-solver compression train). They are for learning — open any of them to see a complete, runnable study.

3. 3

   Open a model

   Click a model card on the dashboard. The editor opens on the RBD tab showing the full diagram.

4. 4

   Run the analysis

   Pick a solver on the Analysis tab, then press Run Analysis (top right). The job appears on the dashboard with a live progress bar and typically finishes in seconds.

5. 5

   Read the results

   When the job completes, open it to see availability, MTBF/MTTR, throughput and cost charts — explained in the Results section below.

The model editor has three tabs — RBD (the diagram), Simulation (parameters and advanced features) and Results. On the RBD tab you build the diagram from four block types, dragged in from the palette on the left:

Series structure

Blocks in series all must operate — one failure brings the path down. Reading is left to right, from the green S terminal to the red E terminal:

Parallel (k-of-n) structure

Parallel branches fan out at a fork dot and rejoin at a join dot. The k value defines how many branches must work — a 2-of-3 pump set tolerates one pump being down with no production loss:

Standby

In a standby group the reserve unit doesn’t run until needed — shown with a dashed border, the standard convention for standby in RBDs. A standby unit can have its own (usually lower) failure behaviour while dormant, configured on its component type:

Hierarchy — systems inside systems

Containers nest. A typical plant model is a parallel set of trains, where each train is itself a series of equipment. The canvas shows the whole hierarchy at once, with each container drawn as a labelled box around its children:

Working on the canvas

• Drag from the palette to add a block to the container you are viewing.
• Click a block to select it and edit its properties in the Block Inspector (right panel).
• Double-click a container to zoom into that subtree; use the breadcrumb to navigate back up.
• Collapse / expand — the chevron in a container’s header collapses it to a single box; the round chevron button on a collapsed box expands it again. Containers with more than 6 children start collapsed so large models stay readable. Expand all / Collapse all are in the toolbar.
• Delete a selected block with the Delete or Backspace key.
• PNG export — the toolbar’s PNG button saves the current view as an image for slides and reports.
• Layout is automatic — blocks are always arranged in clean engineering style; there is nothing to line up by hand.

Equipment behaviour lives in component types — named templates such as CENTRIFUGAL_PUMP defined once and assigned to any number of component blocks. Manage them in the Types tab of the editor’s left panel. A type defines, at minimum:

• Failure distribution — how long the item runs before failing.
• Repair distribution — how long a repair takes once started.

and optionally:

• Logistics delay — waiting time before repair work can start (mobilisation, parts on order).
• Standby failure distribution — a separate (usually slower) failure behaviour while a unit is dormant in a standby group.
• Preventive maintenance — a PM interval plus a PM duration distribution.
• Costs — repair cost and PM cost per event, used by the cost model.
• Spare pool — link the type to a spare-parts pool and define the replacement time.
• Failure modes — split one item into independent sub-modes (e.g. bearing vs. seal failure), each with its own failure and repair behaviour.

Distributions

All times are in hours. Seven distributions are available; the shapes below are drawn from the actual probability density functions:

You can also import component types in bulk from CSV or Excel, and save reusable libraries — see Import & export.

All of these are configured on the Analysis tab of the editor (or, for component-level options, in the component type dialog).

On the Analysis tab you first choose a solver: Monte Carlo (discrete-event simulation — handles every feature) or Analytical(an exact closed-form + Markov solver — instant, but no crews, spares, buffers or PM). Settings the chosen method can’t use grey out automatically. See Monte Carlo vs Analytical for a full decision guide.

Key parameters:

Press Run Analysis. Jobs run on the server — you can leave the page; progress is visible on the dashboard, and finished results stay attached to the job. (The analytical solver returns almost immediately.)

The results page is organised top-down, headline first:

• System availability — the average across all runs, with P50 and P90 percentiles. Because high availability is good, P10 is the pessimistic case (9 out of 10 simulated lifetimes did better) and P90 the optimistic one. For "bad" quantities like failure counts it flips: P90 is pessimistic.
• Convergence — the confidence-interval width of the availability estimate and a suggested number of runs for a stable result.
• System KPIs — failures, MTBF, MTTR, throughput and lost hours over the mission.
• Availability trend — per time window, when the duration is split into multiple windows.
• Block KPI table — availability, failures, MTBF, MTTR per tracked block; with throughput capacities configured it adds actual throughput and production lost in real units.
• Cost breakdown — downtime vs. repair vs. PM cost, when a cost model is defined.
• Spare pool statistics — usage and stock-outs per pool.
• Importance ranking — which components contribute most to system unavailability. Three standard risk-importance measures are computed — Birnbaum, RAW (risk achievement worth) and RRW (risk reduction worth) — with the top 15 shown.
• Sensitivity — how system availability responds to ±20% changes in each type’s MTTF and MTTR, highlighting where better data or better equipment pays off.

Comparing runs

On the dashboard, select several completed jobs and open the comparison view to see their KPIs side by side — the quickest way to evaluate design alternatives that you modelled as separate scenarios.

Reports

Generate a formatted study report as PDF or Word (DOCX) from a completed simulation. The report includes the KPI tables, distribution histograms with P10/P50/P90 reference lines, and your own key findings and recommendations — fill those in under the Report section of the Simulation tab before exporting.

Import & export

Quotas are counted in runs — one run is one simulation job submission, regardless of size. Every new account starts with a 14-day Professional trial.

Every account starts with a free 14-day Professional trial — no credit card. After that, stay on the free Starter plan or subscribe; see the pricing page for details.