A reliability block diagram (RBD) for a product that has no redundancy or complex use profile is often very simple. A series system (reliability wise) implies that any one part or element of the product that fails the entire product fails. One might ask if an RBD is even necessary.
Let’s use a computer with five major elements as a simple example to illustrate one way the RBD (even a very simple one) becomes very important during the design process. Let’s say this computer has a mother board, power supply, hard drive, monitor and keyboard/mouse; five parts. To further the example, let’s assume the overall goal for the product is 95% reliable at two years.
The RBD’s first step is to layout the five elements of the product and apportion them a reliability goal. The easiest means to do this is simple math. What number raised the fifth power equals or is higher than the goal, 0.95. With rounding, let’s use 0.99.
0.99 ^ 5 = 0.95
Great. The keyboard/mouse and monitor team leads are smiling. “no problem” he says.
The power supply team lead is frowning, “might be difficult’ she says.
The mother board and hard drive team leads are puzzled, “we don’t know if we’re above or below that target.”
Already the RBD has created a brief conversation on product reliability. Two teams will need to use one or more reliability tools to estimate or measure the reliability of their sub-system. Once all teams have at least an estimate – then the full value of the RBD comes to play. Comparing the apportioned goals to the estimates the team has a few options.
1. Get better and more accurate estimates. Field data, vendor test data, in-house ALT’s, etc.
2. Adjust the goal down in one or more areas and likewise, adjust the goals up in other areas. This may need to be done to accommodate the relative complexity and expected failure rates for different elements of the product. As long as the overall goal is met, adjusting the apportioned goals is fine.
3. Reduce or raise the overall all goal. A goal or target is just that – the technology, use demands, etc. may all conspire to incur a higher than desired failure rate. Keep the goals balanced between business needs and technology capabilities will keep the RBD useful.
The design team’s awareness of the RBD and gaps permits prioritization, alternative designs, and experimentation to improve the product’s reliability. These are all good things.
How do you use RBD? What value do you and your team derive from these simple models?
Related:
Reliability Block Diagrams Overview and Value (article)
Weakest Link (article)
Exponential Reliability (article)
Great article and great website, thanks for the resource. Just a quick suggestion for your computer RBD example. I would consider changing either the number of years you are trying to meet the goal (5 years), or the number of components in the example (5). For a casual reader, your example of 0.99^5 might be confusing since it does not state if the power of 5 is for the number of years or for multiplying the reliability goal of 5 pieces of equipment in series that make up the entire system.
Hi Zach, great suggestion, I’ll implement the suggested edits to help clarify the article and calculations. Cheers, Fred