Choose your reading route
eduKateSG · Why Mathematics? · Reliability Block Diagrams: Series, Parallel, k-out-of-n Redundancy and Common-Cause Failures
Start with the question, audit the worked example, or jump to the assumptions and practice. Every chapter stays open for uninterrupted reading.
Understand the question
Define the quantity and follow the mechanism.Route 2 · Chapters 9–16
Reproduce the example
Audit the numbers one step at a time.Route 3 · Chapters 17–24
Check assumptions
See where design and calibration matter.Route 4 · Chapters 25–32
Explore applications
Connect the method to a concrete investigation.Route 5 · Chapters 33–43
Study and verify
Practise, inspect failure cases and read further.
Full chapter index · Practice and checking · Mathematics Learning Hub
Why is mathematics important when a system succeeds only through a particular combination of components? Reliability block diagrams turn functional architecture into probability. Series products show the cost of many necessary links; parallel complements and k-out-of-n sums show when genuine redundancy improves survival.
Did You Know? Three independent components that are each 99 percent reliable form a series system reliability of 0.99³=0.970299. Strong components do not make the whole system 99 percent reliable when every one is required.
The central skill is translating an actual function into the right success paths. A student should be able to say what users receive, which components must work, which alternatives are truly independent, how long the mission lasts and what happens after one path fails. Only then do products, complements and binomial sums answer the intended question. This discipline prevents a physical drawing, marketing claim or idealised backup from becoming an unsupported probability model. It also reveals where adding another component creates a new switch, voter, interface or maintenance burden that must be included. Good RBD work therefore combines calculation with architecture review, failure evidence and a test plan for the assumptions that provide the apparent redundancy benefit. A worked probability is most valuable when another reader can redraw the same function, reproduce the arithmetic and identify exactly which dependency would change the answer. That transparency turns a diagram into an engineering argument that can be checked, improved and confirmed with evidence.
Full chapter index
Chapters 1–8 · Understand the question
Chapters 9–16 · Reproduce the example
Chapters 17–24 · Check assumptions
Chapters 25–32 · Explore applications
Chapters 33–43 · Study and verify
A reliability block diagram, or RBD, connects blocks according to the functions that must succeed for a system to operate. Blocks in series all need to work; parallel paths provide alternatives. The diagram is logical rather than a physical wiring or flow drawing. A valve located beside a pump may belong in a different success path. Define the system function, mission and boundary before drawing. The same equipment can have different RBDs for cooling, power and control functions.
A block reliability R_i(t) is the probability that component i performs its required function through time t under stated conditions. Values must refer to the same mission time and environment before they are combined. One-hour and one-year reliabilities cannot be multiplied directly. Component models may come from tests, field data or lifetime distributions. Keep uncertainty and censoring visible; an RBD does not improve weak inputs.
In a series success path, every block must succeed. Under independence, system reliability is the product of component reliabilities. For R1=0.98 and R2=0.95, Rs=0.98×0.95=0.931. The system is no more reliable than its weakest component and is usually lower than each. Adding necessary functions can reduce mission reliability even when each component is strong. This is a mathematical reason to simplify architectures and improve critical links.
Three independent series components each with reliability 0.99 give 0.99³=0.970299. A reader might expect “about 99 percent” because every component is 99 percent reliable, but the system requires all three. As the number of necessary blocks grows, the product falls. This does not mean complexity is always bad; it means each added required function must be justified and modelled.
For two active independent parallel components, the system fails only if both fail. If each reliability is 0.90, each failure probability is 0.10, so system reliability is 1−0.10²=0.99. This benefit assumes both paths can perform the required function, failures are independent and any combining or switching equipment succeeds. Parallel lines on paper do not create those conditions.
| Architecture | Calculation | Reliability |
|---|---|---|
| 0.98 and 0.95 series | 0.98×0.95 | 0.931 |
| two 0.90 parallel | 1−0.10² | 0.99 |
| three 0.99 series | 0.99³ | 0.970299 |
| 2-out-of-3 at p=0.90 | 3p²(1−p)+p³ | 0.972 |
For independent parallel reliabilities R1 and R2, system reliability is 1−(1−R1)(1−R2). If values are 0.95 and 0.80, result is 1−0.05×0.20=0.99. The weaker backup can still add value, but load sharing, detection and activation may change its effective reliability. State whether both run continuously, share load or one waits in standby.
A k-out-of-n system works when at least k of n components succeed. Voting logic, multiple engines and sensor arrays can have this structure. For identical independent components with reliability p, add binomial probabilities from k successes through n. Series is the special case k=n; parallel is k=1. NIST uses r-out-of-n terminology for the same idea. Independence and identical reliability are simplifying assumptions, not inherent features.
For three identical independent components with p=0.9, a 2-out-of-3 system reliability is C(3,2)p²(1−p)+p³. This is 3×0.81×0.1+0.729=0.243+0.729=0.972. At p=0.8, it becomes 3×0.64×0.2+0.512=0.896. Redundancy benefit changes nonlinearly with component reliability. If the voter can fail, its reliability must also be included.
Many coherent RBDs can be reduced step by step. Replace a simple parallel group by one equivalent reliability, then multiply it with neighbouring series blocks. Record each reduction so the model remains auditable. Some bridge networks cannot be reduced by simple series-parallel rules; use state enumeration, decomposition, cut sets or simulation. Software can calculate large networks, but the functional logic still requires human review.
A minimal path set is a smallest collection of components whose success guarantees system success. A minimal cut set is a smallest collection whose failure causes system failure. RBDs emphasise paths; fault trees emphasise cuts. Deriving both provides a cross-check. Overlapping paths are not independent simply because each contains reliable blocks. Exact system probability must account for shared components.
Parallel units may share power, cooling, location, software, maintenance or environment. A common-cause event can disable all paths and cap the achievable reliability. A simple model places a shared block in series with the parallel group or conditions component behaviour on a shared state. Specialised beta-factor and dependency models may be appropriate. Never quote a redundancy gain without stating how common causes were treated.
Active parallel units operate together. A standby unit may be dormant until detection and switching. Standby reliability depends on dormant failure, detection, switch success, startup and load transfer. A two-line parallel RBD can overstate standby benefit if it omits these events. Dynamic sequence matters: the spare must be available after the active unit fails. Markov or dynamic fault-tree models often represent this better.
| Model | Success requirement |
|---|---|
| Series | every block succeeds |
| Parallel | at least one path succeeds |
| k-out-of-n | at least k of n blocks succeed |
| Standby | active path or successful detection, switch and spare |
When parallel components share load, failure of one increases stress on survivors. Their subsequent failure rates change, violating a fixed independent model. Represent states by the number working and use conditional component models. Mechanical, electrical and computing systems can all exhibit load sharing. A static RBD may still provide a bound or screening model, but label the approximation and test sensitivity.
Reliability usually means uninterrupted success over a mission, while availability allows repair and asks whether the system is operational at a time or over a long period. An RBD built from steady-state component availabilities calculates an availability-like metric, not non-repairable mission reliability. State which measure each block carries. Repair crews, queues and dependencies may require Markov or simulation models rather than static multiplication.
Redundancy needs mechanisms to detect failure, isolate it and select a healthy path. Coverage is the probability that the system successfully handles a component fault. Voters, switches and control logic can be single points of failure. Include them as blocks or in a state model. Idealised k-out-of-n mathematics assumes perfect recognition and combination unless otherwise stated. Real resilience depends on these supporting functions.
When component reliability follows exponential, Weibull or other lifetime models, substitute R_i(t) into the architecture formula to obtain system reliability over time. A series of independent exponential components has a summed hazard. Parallel hazards are time-dependent even when components are exponential. Plot system reliability across the mission, not only at one convenient time. Different component ageing shapes can change which path dominates.
Component reliability estimates have uncertainty and may share data sources. Propagate parameter distributions or confidence bounds through the RBD. Sensitivity derivatives or simulation can identify influential inputs. A system estimate shown to six decimals is misleading when component evidence is sparse. Model-form uncertainty—independence, architecture and common causes—may be larger than numerical intervals. Report both.
A cooling function may require power and at least one of two pumps and an outlet valve. The RBD places power in series, then a parallel pump group, then the valve. A common pipe blockage belongs in series with both pumps. Improving pump reliability has limited value if the valve or power block dominates. The diagram directs design attention toward functional bottlenecks.
A web service may need identity, application and database functions in series, with several instances inside each function. Multiple servers sharing a deployment or control plane are not fully independent. Regional diversity may reduce some causes while leaving global identity or DNS as common blocks. Use incident evidence to update architecture assumptions. Service availability also depends on repair and traffic routing, not only component uptime.
Three sensors with 2-out-of-3 voting can tolerate one failed sensor under perfect voter and independent failures. Calibration drift or common environment can cause correlated errors, and a voter may combine wrong but plausible readings. Reliability of “produces any output” differs from safety of “produces a correct output.” Define the success criterion and include common-mode measurement errors. MSA and fault analysis complement the RBD.
Students can model a presentation function requiring power, a display and at least one of two file-access paths. They calculate series and parallel reliability from illustrative values, then add a shared network dependency. The purpose is understanding system structure, not claiming real school risk. Ask learners to explain why a physical diagram and a functional success diagram differ. This builds probability and systems reasoning with a familiar, low-stakes context.
Sensitivity can show which block offers the largest system gain per improvement. Adding redundancy to a highly reliable non-dominant block may add little, while removing one shared dependency can transform the system. Compare cost, complexity, testability and new failure modes. Every design change can introduce switches, software or maintenance burden. Confirm the revised architecture through testing and operational evidence rather than trusting the new diagram alone.
NIST explains that series-system reliability is the product of component reliability functions under the stated model and that the first component failure causes system failure. Read the NIST series model. This supports the 0.931 and 0.970299 calculations. Independence, common mission time and functional boundaries remain application-specific responsibilities.
NIST describes parallel systems as surviving while at least one independent component works and r-out-of-n systems as surviving when at least r of n identical independent components work. Read the NIST parallel model and r-out-of-n model. These formulas support the worked examples but do not justify independence by themselves.
Reproduce 0.98×0.95=0.931, 1−0.1²=0.99, 0.99³=0.970299 and the 2-out-of-3 value 0.972. Evaluate boundary cases p=0 and p=1. Confirm that k=1 matches parallel and k=n matches series. Add one common-cause block and show the ceiling it creates. Compare the result with a fault-tree calculation under identical assumptions.
RBDs can hide dependencies, repair, sequence, imperfect coverage, degraded performance and changing load. Component inputs may not represent installation conditions. Complex networks can be mis-reduced. A high calculated reliability does not prove safety or availability. Success paths may omit software, human and environmental functions. Use RBDs with fault trees, testing, FMEA, Markov models and field monitoring where appropriate.
State the function, mission time, boundary and success criterion. Show the RBD with a component dictionary. Report each reliability function, data source, uncertainty and common-cause treatment. Distinguish active, standby and k-out-of-n logic. List switches, voters and coverage. Provide reduction steps or software method, sensitivity, validation and limitations. A reader should be able to trace every series product and parallel complement.
Begin with two blocks in series and parallel. Add a third series component and calculate the product. Build a 2-out-of-3 voter, then insert an imperfect voter and common power block. Derive minimal paths and compare with fault-tree cut sets. Finally, replace fixed reliabilities with Weibull functions and plot the system over time. This sequence connects basic probability, combinatorics, functions and engineering design.
Reliability block diagrams make system success visible. Products show why many necessary parts reduce reliability; complements show how genuine independent alternatives help; k-out-of-n models reveal graceful tolerance. The diagrams also teach humility: redundancy works only when shared causes, switching and repair are understood. Mathematics helps students design systems whose strength comes from real architecture rather than optimistic labels.
Rehearse the analysis from function to field evidence. Write a one-sentence success criterion and mission time, then ask an engineer, operator and maintainer to draw the functional paths independently. Reconcile differences before entering probabilities. Build the smallest RBD, list minimal paths and create the equivalent failure logic. Calculate series, parallel and k-out-of-n groups by hand, then enumerate all component states to verify the result. Add switching, voter and coverage blocks. Next add a shared power or environment event and observe how it limits the redundancy gain. Replace fixed component values with time-dependent reliability functions and plot the system over the whole mission. Propagate uncertainty and rank sensitivity, but also inspect inputs whose evidence comes from a different environment. Finish with a design alternative that removes a common dependency and a test that could confirm the claimed separation. This rehearsal prevents a polished schematic from hiding functional disagreement, incompatible time bases or idealised independence.
Architecture can preserve full function, provide reduced function or merely enable safe shutdown. These outcomes should not share one success label. A 2-out-of-3 sensor array may still report with two sensors, yet diagnostic coverage and accuracy can change. A one-pump cooling state may satisfy normal demand but not peak demand. Use separate mission modes or rewards when necessary. Calculate reliability for the exact service promised, and report degraded-state probability beside total failure. This keeps redundancy mathematics connected to what users actually receive rather than to an overly broad “system up” statement.
Create a component table with ID, function, reliability at the common mission time, failure probability, source and uncertainty. Use named formulas for series products, parallel complements and binomial k-out-of-n sums. Build a reduction log rather than one hidden formula. Add sensitivity columns and a common-cause scenario. Validate with p=0 and p=1 boundary cases. Keep reliability and availability in separate sheets and label active versus standby assumptions.
Represent the RBD as a graph with typed series, parallel and k-out-of-n nodes. Write unit-tested functions for each architecture and exact enumeration for small networks. Detect shared component IDs and warn against treating overlapping paths as independent. Sample uncertain component parameters to propagate uncertainty. Compare an equivalent fault-tree calculation. Version the component dictionary, mission time and architecture, and export minimal paths, sensitivity and common-cause scenarios with the result.
RBDs support reliability engineering, systems architecture, aerospace, transport, energy, telecommunications, manufacturing, medical devices and cloud computing. Careers combine probability, design, testing, maintenance, safety and communication. A diagram does not certify a system or grant automatic career access. Students can practise with small networks, then build foundations in algebra, combinatorics, coding and engineering before exploring specialist roles.
Design a low-stakes system such as a battery-powered lamp with two possible power paths and a required switch and bulb. Assign illustrative component reliabilities, draw the functional RBD and calculate system reliability. Then add a shared connector or imperfect switch and recalculate. Compare with a physical sketch and explain why they differ. Use simulation with random numbers to verify the analytic result over many trials.
Series means every block in the path succeeds, not physical connection. Parallel benefit requires functional alternatives and appropriate independence. Two 90-percent components in parallel are not automatically 99 percent reliable if they share a cause. Reliability is not availability. Standby is not ideal active parallel. A 2-out-of-3 voter needs voter reliability. Minimal paths can overlap. Adding components can introduce new necessary functions and reduce rather than improve system performance.
The fault tree analysis article checks failure logic and common causes. The Weibull reliability article supplies time-dependent component functions. The Markov reliability article handles repair and state changes. RBDs provide the architecture layer connecting component evidence to functional success.
Students should calculate one series and parallel system by hand before using graph software. Parents can ask whether blocks describe function, whether reliabilities use the same time and whether a common cause exists. Encourage learners to add a realistic switch or shared resource; discovering why ideal redundancy weakens is valuable. Use illustrative technical systems, not labels about people or student “reliability.” Keep safety conclusions within verified evidence.
1. Reproduce all four worked reliabilities. 2. Derive the unequal parallel formula. 3. Calculate 2-out-of-3 at p=0.8. 4. Show k=1 and k=n special cases. 5. Add common power to a parallel pair. 6. Compare active and standby redundancy. 7. Derive minimal paths for a small network. 8. Explain why an RBD built from availabilities answers a different question.
### Does an RBD copy the physical layout? No. It represents functional success logic.
### Why multiply series blocks? All must succeed, under the joint assumptions including independence.
### Does parallel always improve reliability? Only when paths are true alternatives and shared failures are handled.
### Can repair be included? Static availability RBDs exist, but repair dependencies often need Markov or simulation models.
Report function and success criterion; boundary and mission; architecture diagram; block definitions; time-dependent or mission reliabilities; sources and uncertainty; independence and common causes; series, parallel, k-out-of-n and standby assumptions; switches, voters and coverage; repair treatment; reduction or enumeration method; minimal paths; sensitivity; comparison with fault logic; validation; software and version; and limitations.
Trace every block to a real function and verify the mission time and units of each input. Recalculate simple reductions independently. Enumerate small-system states and compare. Search interfaces for common power, cooling, location, software, maintenance and environment. Confirm that overlapping paths were not multiplied as independent. Add imperfect switching and coverage where required. Compare RBD success logic with an FTA failure model. Challenge the result under parameter uncertainty and one plausible dependency before reporting it.
Continue through the Mathematics Learning Hub. NIST’s bottom-up reliability overview and complex-systems discussion place series, parallel and r-out-of-n models in context. Next build an equivalent fault tree, then use a Markov model if repair, standby or degraded states make the static diagram too simple.
Extended practice laboratory
Practice case 1: Series reliability
Setup: Use two independent components with reliabilities 0.98 and 0.95.
Task: Multiply them.
Checking target: Obtain 0.931 for a system that needs both components.
Practice case 2: Parallel reliability
Setup: Use two independent components with reliabilities 0.90 each.
Task: Calculate 1−(0.10)(0.10).
Checking target: Obtain 0.99 only under active parallel operation and independence.
Practice case 3: Three-component series
Setup: Use three components each at 0.99.
Task: Calculate 0.99 cubed.
Checking target: Obtain 0.970299 and explain why many strong links can reduce system reliability.
Practice case 4: Two-out-of-three
Setup: Use identical independent reliability p=0.9.
Task: Calculate 3p²(1−p)+p³.
Checking target: Obtain 0.972.
Practice case 5: Change component reliability
Setup: Repeat the two-out-of-three calculation at p=0.8.
Task: Compare the system result.
Checking target: Obtain 0.896 and identify the nonlinear change.
Practice case 6: Add common cause
Setup: Give two parallel units a shared failure event probability 0.02.
Task: Construct a conditional or explicit model.
Checking target: Do not multiply unconditional unit failures as if independent.
Practice case 7: Model standby
Setup: Use one active unit, one standby and imperfect switching.
Task: Write the success paths.
Checking target: Include switch reliability and dormant failure.
Practice case 8: Map function not layout
Setup: Draw an RBD for a cooling function.
Task: Connect blocks according to success logic.
Checking target: Do not copy the physical pipe drawing when functional paths differ.
Practice case 9: Compare with a fault tree
Setup: Convert a small RBD success model to top-event failure logic.
Task: Verify equivalent probabilities under the same assumptions.
Checking target: Name any dependency that either simple model omits.
Practice case 10: Report the model
Setup: State mission, component reliabilities and architecture.
Task: List independence, repair and common-cause assumptions.
Checking target: Avoid promising field performance from a schematic alone.