Diverging from reliability statistics for a post or two, let’s consider one way which R(t), reliability at time, t, is useful during the design phase of a product. Apportionment is the breakdown or allocation of reliability goals or objectives to elements within the product.
Overall, the product’s reliability is just one number, and it represents what the customer will experience with the product. During design, we often work on subsystems and components. Having a meaningful way to describe the reliability requirements that also assists the team to meet the overall product goal, is, well, useful.
With one client, I was requested to assist in the improvement of their current 50% field failure rate. During the day’s discussions with a variety of design engineers, I found that each of the major subsystems had been designed to meet the system goal. For example, the product reliability goal was 95% at one year.
Each major subsystem and component (10 altogether) were designed, specified or procured with the idea that they each had to only meet the 95% reliability at 1-year goal. And, the team was rather successful at meeting the assumed goals for the major subsystems and components.
A quick calculation to determine the product reliability given each of the ten elements has 95% reliability shows they should expect a 60% reliability at 1 year. They were doing a bit worse than their designed reliability.
The main circuit board designer literally said, that since the board met the goal of 95%, it was good enough. If the underlying assumption that all the other elements of the product would be perfect, this team’s approach would work. Unfortunately, as in many products, if any one element fails, the product fails. And, every element of a product has a finite possibility of failing.
Therefore, let’s create a model that permits us to allocate reliability to each element using the series reliability model of the system. Graphically a series system is portrayed, for example, as
where each block represents an element of the system. And, if anyone block fails the ‘flow’ is interrupted with no alternative path to provide the intended function.
“Weakest link” comes to mind, as a series system is only as strong as the weakest element, much like a chain.
Mathematically, a series system model of reliability is
where the product of the individual elements is the system reliability. One feature of this formula is all of the elements have to have a higher reliability than the system. Keep in mind that reliability is a probability between zero and one and considering that everything has a finite possibility of failure. And, considering when multiplying two numbers between zero and one, say 0.9 and 0.8. The result is less than the lowest number, never higher. In this case, the product of 0.9, 0.85 and 0.8 is 0.612.
This means that each element of a product should have a higher reliability than the product reliability goal. Apportionment of the reliability to the elements is one way to determine (or set) goals, objectives, or a budget for the individual elements.
According to Ireson, Coombs, and Moss in the Handbook of Reliability Engineering and Management, 2nd edition, there are six basic ways to reasonably and non-controversially perform the task of apportionment. In this post, let’s explore two: simple apportionment and equal apportionment.
where, R(t) is the reliability of the system (or product) at time, t.
and, i = individual subsystems, i = 1, 2, 3, …, n.
Determine reliability estimates for the n subsystems via past product field return analysis, in-house testing, vendor information, databases, or engineering judgment. A common practice is to buffer the apportionment for the unknown or new risks in the design. Thus, by adding more element, we reserve 10 percent of the overall goal for the uncertain or unknown element’s apportionment. Of course, this number can be higher or lower depending on local practice and degree of reliability risk.
Let’s explore a simple example. Let’s say for the holidays our rich uncle installed a new home entertainment system at our house (cool!). It has three basic elements: big screen TV, Blu-ray player, and a sound system.
Graphically this would be illustrated:
If any one part of the system doesn’t work, we’re not going to be able to watch the new Blu-ray movie (also provide by that wonderful uncle).
Having worked in the industry, we have some estimates of the reliability values for the various subsystems. We do not need to include every cable, yet making sure they are properly connected would be a good idea. So, let’s assume we know the following for the expected reliability at one year:
1. Big screen TV’s — 98%
2. Blu-ray player — 97%
3. Sound System — 98.5%
No elements are in parallel, and our highly alert ear can tell if the surround sound is working or not. We have a series system reliability speaking. The product of the three reliability provides the system reliability.
I should mention that our goal, personally speaking, is that system should never fail, or a goal of 100%. Professionally speaking, and knowing the everything has a chance of failing, a realistic goal might be 95% at one year.
Back to our estimates. The product of the three subsystem reliabilities provides a calculated system reliability.
And comparing to our goal, find that we should expect more failures (or a failure is more likely) than expected for acceptable performance. Something needs improvement and the most likely area to focus is the “weakest link” or the Blu-ray player. Switch to a DVD player with reliability at one year of 99% or find a more reliable model, etc. Immediately we see the benefit of doing reliability apportionment – it provides a comparison to what is known and provides a focus for improvements.
This is simple and generates the needed conversation and behavior. Every element is assigned the same apportionment. Mathematically this is represented for a system of N elements by
where R1 = R2 = … Rn, basically all elements have the same value.
Given a system goal, say 95% at one year, we can determine the individual element equal apportioned reliability goal by determining the value raised the number of elements power that equals the reliability goal.
One could also find this iteratively using Excel or a calculator knowing that the element reliability is higher than the system reliability. Following the example from above, where the system reliability goal is 95% at one year, we would solve for Re when raised to the third power equals 95%.
Thus, when every element is at least 98.32% reliable at one year, the system would be at least 95% reliable at one year.
At this point, the power supply team raised an objection knowing that they are a much more difficult element of the product than the keyboard (using a computer example). Which is true and not accounted for in this method. Yet, consider the objective and justification — and more importantly the ensuing discussion.
Back to the discussion and behavior that I mentioned earlier; in a real situation, without any reasonable prior history, working with a team to perform apportionment, we used this method.
Reliability Allocations (article)
Reliability Block Diagrams Overview and Value (article)
System Engineering and Reliability (article)
Sri Ganesh Buddhavarapu says
Fred, it was mentioned that the client had 10 major subsystems and components altogether. For a complex system like an automobile which has lot of components depending on how it is sliced and diced, how far down do you suggest allocating the reliability? Assuming that a design meets the allocated goal – the test times & sample sizes to demonstrate it will be impractical. My thoughts are to allocate to down a level which can be practically tested and eventually prove that allocated goal could be met. Please share your thoughts. Thank you.
Fred Schenkelberg says
Hi Sri Ganesh,
Good question – I tend to build the model to the level of major decisions – for example, is a team or engineering is responsible for the power supply, down to the power supply and not to the power supply components. For a car, I would break down the model to the major subsystems, like powertrain, dashboard, braking system, etc. Within those major subsystems, we may break down the model to a finer level, yet not based on testing.
Don’t limit the model to the level you are good to run testing. Instead, build the model to help you and your team make decisions. Pull data in from engineering judgment, vendors, field data analysis, and if necessary from testing. Not everything requires a demonstration test… instead use the information you have available to help you make decisions. Get better data, sometimes test data, if the data available is not good enough to make a clear decision.
hope that helps