A Reliability Block Diagram, or RBD, is a graphical model that represents how component success or failure affects the ability of a system to perform its required function.

The blocks describe functional relationships.

They do not need to match the physical layout of the equipment.

Define the required system function

Before drawing the diagram, state what success means.

Examples include:

  • deliver cooling;
  • maintain compressed air;
  • pump required flow;
  • complete a production cycle.

The same physical system can have different reliability models depending on the required function.

Use series logic for required components

When every component must work for the system to succeed, the blocks are arranged in series.

For independent components in series:

System reliability = R1 × R2 × … × Rn

Adding more required components generally lowers overall system reliability.

This is why complex systems can have lower reliability even when individual components are fairly reliable.

Use parallel logic for redundancy

When either of two independent paths can provide the required function, the model can use parallel blocks.

Redundancy may improve system reliability.

Examples include:

  • duty/standby pumps;
  • redundant power supplies;
  • multiple cooling fans.

The actual benefit depends on whether the redundant path is available when needed.

Model common-cause risks carefully

Two redundant components may not be truly independent.

Both may fail because of:

  • common power source;
  • common cooling;
  • shared control system;
  • same contamination source;
  • common maintenance error.

A simple parallel calculation can overstate reliability if common-cause failure is ignored.

Failure Mode and Effects Analysis can help identify shared failure mechanisms that the diagram alone may not reveal.

Include switching and standby logic

Standby redundancy may require:

  • failure detection;
  • switching device;
  • successful startup;
  • operator response.

If the backup cannot be activated reliably, the theoretical redundancy is weaker than it appears.

Failure-Finding is especially relevant for protective or standby functions whose failure may remain hidden until demand occurs.

Use the diagram to compare design alternatives

An RBD can help evaluate questions such as:

  • Where will redundancy create the most value?
  • Which component dominates system reliability?
  • What happens if one path is removed?
  • Which component improvement matters most?

The diagram helps teams reason about the system rather than optimizing components independently.

Connect reliability modeling to maintenance strategy

Reliability-Centered Maintenance focuses on preserving required system functions.

An RBD can help show which components or paths are essential to those functions.

This can support:

  • maintenance prioritization;
  • spare strategy;
  • design improvement;
  • redundancy review.

Use realistic data

Reliability estimates may come from:

  • field history;
  • supplier data;
  • test data;
  • engineering estimates.

The model is only as good as its assumptions.

Document:

  • time basis;
  • independence assumptions;
  • operating conditions;
  • data source.

Common mistakes

Drawing the physical layout instead of the functional logic, treating redundant components as independent when they share common causes, ignoring switching reliability, using inconsistent time bases, treating uncertain component estimates as exact values, and optimizing individual components without understanding system function are common mistakes.

Practical sequence

  1. define the required function.
  2. define system success and failure.
  3. identify required components and paths.
  4. model series relationships.
  5. model parallel or standby redundancy.
  6. identify common-cause dependencies.
  7. assign reliability estimates.
  8. calculate or simulate system reliability.
  9. test alternative designs or maintenance strategies.
  10. update the model with field evidence.

The practical lesson

A Reliability Block Diagram shows how component reliability combines into system reliability.

It helps teams focus on the architecture of success, not just the reliability of individual parts.