A Reliability Block Diagram (RBD) is a graphical representation of a system that shows how individual components contribute to overall reliability. Each block represents a functional unit—a mechanical part, an electronic circuit, a software module, or an entire subsystem. The connections between these blocks show how the units must interact for the system to perform its intended function.
The underlying principle is straightforward. A system functions if, and only if, there is at least one operational path from the beginning of the diagram to the end. If every path is broken, the system fails. This visual logic forces engineers to confront exactly how their design behaves under failure conditions.
I have audited plants where complex FMEA documentation masked a fundamental architectural weakness. Drawing the RBD exposed the vulnerability in minutes. It translates abstract risk into a functional map, making it immediately clear where a system survives and where it collapses.
Series Versus Parallel Architectures
Systems generally follow three basic configurations. The first is a series arrangement, where all blocks must function. The failure of any single component means total system failure. An assembly line where each station depends on the previous one is a classic series arrangement. If one station stops, the entire line stops.
The second is a parallel arrangement, or redundancy. Here, the system functions as long as at least one block operates. Think of dual independent braking systems in an automotive application. If one fails, the other sustains the function. The third is a combined arrangement. Most real-world systems mix series and parallel connections, requiring rigorous engineering analysis to decode.
An RBD is not just an illustration. It is the foundation for mathematical analysis. For a series system, the formula is R_system = R1 x R2 x R3. A series system is always less reliable than its weakest component. Five components in series, each with 99% reliability, yield a total reliability of 0.99 to the fifth power, or 95.1%.
The Mathematics of Series vs Parallel Reliability
In a parallel arrangement, the formula is R_system = 1 – (1 – R1) x (1 – R2). Reliability increases with every additional parallel block. Two components with 90% reliability in parallel yield 99% reliability. These formulas dictate whether your product survives its warranty period and whether your line runs without interruption.
Exposing Hidden Risk in Electronic Control Units
I once reviewed an automotive electronic control unit line where warranty costs were rising. Final inspection quality was high. PFMEA documentation was complete. Control plans were implemented. Despite this, field failures persisted. We built an RBD to find the disconnect.
We identified system functions: controlling fuel injection, communicating with modules, and processing sensor signals. We broke the architecture into functional blocks: power supply, processor, communication interface, input circuits, output drivers, and protective circuits. Then we mapped the dependencies between them.
The mapping revealed a critical flaw. A single power circuit—a block no one had scrutinised because it was considered 'simple'—was in series with all other functions. Without it, nothing worked. We pulled field reliability data for each block. The power circuit had a reliability of 0.97. Every other block operated above 0.998.
The entire system reliability was bottlenecked at 0.97 by this single component. We modelled a scenario adding a redundant power circuit. The reliability jumped to 0.9991. The cost of adding the backup circuit was roughly 1.20 euros per unit. The annual warranty savings exceeded 2.3 million euros.
Building the Diagram: Function Over Physical Parts
To build an accurate RBD, you must first define the system and its boundaries explicitly. Without clear limits, you will model too much or too little. If you are modelling a vehicle braking system, state whether the ABS module, wheel sensors, and power supply are included or excluded.
Next, identify all functional blocks. Every block must represent a function, not a physical component. One physical part might perform multiple functions. Conversely, a single function might require multiple parts. Mapping physical parts instead of functions is a guaranteed way to miss critical dependencies and produce a useless model.
The RBD Construction Sequence
- 01Define BoundariesExplicitly state what is included in the system model and what is external.
- 02Identify FunctionsMap blocks based on functional requirements, bypassing physical part numbers.
- 03Map DependenciesEstablish series, parallel, or complex logical relationships between functions.
- 04Assign Reliability DataInput MTBF, failure rates, or field data to quantify the model accurately.
- 05Calculate and OptimiseIdentify single points of failure and evaluate the impact of added redundancy.
Determine the logical relationships: series, parallel, k-out-of-n voting, or standby redundancy. Finally, assign reliability data. Use MTBF from field returns or testing. If you lack hard data, use engineering estimates but flag them as assumptions. An RBD is a living document that improves as data quality improves.
Core Analyses: Identifying Single Points of Failure
A Single Point of Failure (SPOF) is any block in a series arrangement whose failure causes total system collapse. In automotive and aerospace manufacturing, identifying SPOFs is a safety-critical exercise. An RBD exposes every SPOF instantly. Any block in series without a parallel backup is a liability.
Redundancy without common-cause failure analysis is a false sense of security.
Sensitivity analysis reveals which blocks dictate overall system reliability. By adjusting a single block's reliability by 1%, you see the systemic impact. Importance analysis, using metrics like Birnbaum's measure, quantifies how much each block contributes to overall system failure. It answers the question: if you have 100 euros for reliability improvement, where do you spend it?
These analyses enable what-if scenario modelling. You can test the impact of adding redundancy here, or swapping a component for a more reliable variant there, before committing capital. You evaluate architectural changes on paper, preventing expensive engineering mistakes during physical prototyping.
Common Errors That Invalidate the Model
The most frequent error is ignoring common-cause failures. Two parallel blocks look highly reliable on paper, but they are useless if they fail simultaneously from the same cause. A power surge, thermal shock, or shared software defect will defeat your redundancy. Common-cause analysis is mandatory for the redundancy to hold mathematical weight.
Using unrealistic data is a guaranteed path to failure. A supplier's MTBF from a sterile datasheet rarely matches the MTBF of a component operating in a harsh environment. If you model your system using optimistic catalogue data, your results will be optimistic, and your customers will shoulder the consequences through field failures.
Treating the RBD as a one-time deliverable is another critical mistake. The diagram must be updated when the design changes, when field data becomes available, or when operating conditions shift. An outdated RBD hidden in a project folder provides false assurance and actively misleads engineering decisions.
Finally, engineers often forget the human factor. Not every block in an RBD is a hardware component. Human operations—maintenance, calibration, setup—must be modelled when relevant. Omitting these manual interventions leaves a blind spot in the system's true reliability profile, skewing the calculation.
Integration with ISO 26262 and Quality Tools
In the automotive sector, RBD is integral to functional safety analysis under ISO 26262. When evaluating an Automotive Safety Integrity Level (ASIL), an RBD demonstrates that the architecture meets target metrics like Probability of Failure per Hour (PFH) or Single Point Fault Metric (SPFM). Without this modelling, compliance at higher ASIL levels is practically impossible.
RBD does not operate in isolation. It feeds directly into and draws from other quality mechanisms. FMEA provides the failure modes and effects data that inform the blocks. Fault Tree Analysis (FTA) acts as the logical counterpart—while RBD models how a system functions, FTA models how it fails.
Weibull analysis provides real-world failure distribution data for individual blocks. Monte Carlo simulation handles complex systems with dynamic dependencies. Reliability Growth Testing closes the loop, providing feedback on how actual performance tracks against the theoretical model you constructed.
If you are building your first RBD, start on paper. Map a system you know well. Identify the functional blocks and their relationships before opening specialised software like Reliability Workbench or BlockSim. The sketching process forces systemic thinking that software often obscures. Build it with a cross-functional team to capture every angle of the system's reality.