This is our fifth article about the 3 ways to do reliability allocation. We have been taken on a journey through the reliability design cycle, key steps for reliability allocation, allocation factors used to get these goals and key pitfalls. Now we finish off our conversation by looking at a few variations and applications. Allocating MTBF (… though we recommend against it), allocating availability, allocating maintainability (… another thing we recommend against) and allocating for different system reliability goals.
If you want to finish off your understanding of reliability allocation – read this!
Allocating the MTBF?
The MTBF is not reliability. So MTBF allocation is not reliability allocation. Two systems with the same MTBF can have very different reliabilities at different points of time.
If you have to use the MTBF, then the equations you need to use are:
$$ \lambda _{i(DG)} = \frac{a_i \lambda _{Sys(DG)}}{\sum {a_{i’}}}… MTBF_{i(DG)} = \frac{MTBF_{Sys(DG)} \sum{a_{i’}}}{a_i}$$
where $$ \lambda _{Sys(DG)} \text{ and } MTBF_{Sys(DG)} $$ are the system hazard rate and MTBF goals respectively, $$ \lambda _{i(DG)} \text{ and } MTBF_{i(DG)} $$ are the allocated hazard rate and MTBF goals for the ith component.
Your allocation factors have the same meaning as those we talked about in our previous article.
But you need to understand that the MTBF is rarely a good goal to be allocating. There are plenty of other articles that can help you with this!
Allocating Availability?
Absolutely! The approach is very similar to that for reliability. The equation you need to use is:
$$A_{i(DG)}=\sqrt[\frac{\sum{a_{i’}}}{a_i}]{A_{Sys(DG)}}$$
where $$A_{i(DG)}$$ is the allocated design availability goal for the ith component and $$A_{Sys(DG)} is the system availability design goal.
Now when determining these allocation factors, you typically consider more factors than you do for reliability allocation. Things like the cost and duration of repair. The cost of downtime. Whatever relates to the availability performance of your product. Maintainability considerations.
Allocating Maintainability?
Don’t do it!
Why? Many reasons.
The first and the biggest reason is that most maintainability allocation techniques are premised on knowing the final reliabilities of your components. Which means you must have already finished your design process! So how can you use maintainability allocations to influence design? It is too late!
The second is that most approaches to maintainability allocation are triggered at the prototype stage at the earliest. Initial or observed maintenance duration for all maintenance actions are then fed into an optimization process with the aim of meeting maintainability requirements. Again – how do you make your system easier to maintain without getting back into the design cycle? Which must be largely finished if you are at an advanced prototype stage.
And the third reason to avoid maintainability allocation is that published approaches have rudimentary theoretical underpinnings at best (see below).
Instead – consider allocating availability. This means your design teams can internally trade off reliability and maintainability performance levels to meet the system goals. Unleash their potential!
If you have to allocate maintainability because you lost a bet or signed a contract without reading it, then the equation you need to use is:
$$MMT_{Sys(DG)}=\frac{\sum{\lambda_i a_i MMT_{i(observed)}}}{\sum{\lambda_i}}$$
You will note that this equation doesn’t provide any allocated maintainability goals for all components. Instead, the design team leader must manually adjust each allocation factor until the system maintainability goal is achieved. And once you do this, we get:
$$MMT_{i(DG)}=a_i MMT_{i(observed)}$$
Again – don’t do it!
What about incremental goals?
And by incremental goals, we mean reliability goals that start of low at the beginning of the product development process and gradually increase until we meet our system reliability goals at the end of the development process. This approach is fairly common and is often very useful. It helps provide the glidepath from where we start to where we want to go.
There are a couple of approaches for the allocation of incremental reliability goals.
The first approach is to start with incremental goals at the system level and then allocate these incremental goals to all components. If the initial system reliability goal is 50 per cent of our final goal (with several incremental goals in between) we allocate each of these incremental goals to our components against specific phases of design.
The benefit of this approach is simplicity. But different modules and components may have different developmental growth curves. So one component or module might appear to be doing very well because it has a rapid growth curve. It may be technologically simple. Or it may be based on an element of a fielded model. So this component or module may quickly have its reliability ‘allocated away’ even if it might eventually struggle to meet its final allocated reliability goal.
Another approach is allocating the final reliability goals to all components and modules, and then having the respective design teams create their own incremental reliability goals. This allows design teams to take into consideration reliability growth curves for their component.
The problem with this approach is that design teams may have different levels of experience or understanding of reliability growth. Meaning there are philosophical differences between each curve.
You need to work out which makes the most sense for your product or design – and perhaps incorporate a hybrid approach. Perhaps allocate the final goals for each component or product and then sit down with each team to determine individual reliability growth profiles. Once you have done this, you can then use these individual component incremental goals to create incremental system reliability goals.
What if I have multiple customer requirements for different types of failure and reliability?
This can happen a lot.
Remember the example requirements we discussed previously? Where we had reliability goals for the service life, warranty period and initial six-month period? They are all important, and all need to be allocated.
Your customer might also define what a ‘critical’ failure is and have a separate requirement for it. And let’s say that after you go through the steps we talked about above, the system critical reliability goal with design margin is 99.5 per cent. You may recall based on our example that the reliability goal with reliability design margin was 97.8 percent.
The first thing you need to do is work out if any of your components will exclusively fail in one way or another. Are the components whose failures will always cause a critical failure? If the answer is no, then you allocate both critical and non-critical reliability requirements.
But if there are any components whose failures will cause a critical failure, then you need to approach allocation in a different way. Let’s say we identify two of our nine components whose failure may result in a higher level critical failure. One component in particular is identified as being very critical. Every failure of this component results in a system level critical failure. The other component can fail in a number of ways – some of which will result in a system level critical failure.
We use the allocation factors to identify critical reliability goals for these components.
$$R_{i(DG)}^{critical}=\sqrt[\frac{\sum {a_{i’}}}{a_i}]{R_{Sys(DG)}{critical}}$$
Recall that the allocation factors (based on complexity) in the example above were 8 and 4 respectively (you can come up with any allocation factor you want based on your approach). So the critical reliability goals for these components become:
$$R_{1(DG)}^{critical}=\sqrt[\frac{12}{8}]{99.5\%}=99.67\%$$
$$R_{2(DG)}^{critical}=\sqrt[\frac{12}{4}]{99.5\%}=99.83\%$$
For our first component, the critical reliability goal is also the overall reliability goal for this component – every failure is a system or product reliability product. And for our second component, it needs to be allocated both critical and non-critical reliability goals because it can fail in multiple ways.
But – the fixed reliability goal now needs to take into consideration the critical reliability goal for our first component.
$$R_{i(DG)}=\sqrt[\frac{\sum{a_{i’}}}{a_i}]{\frac{R_{Sys(DG)}}{\prod^m_{i=1}{R^{fixed}_{k(DG)}}}}$$
where $$R_{i(DG)}$$ is the allocated design reliability goal for the ith component whose goals aren’t already fixed, $$R_{Sys(DG)}$$ is the system reliability design goal, and $$R^{fixed}_{k(DG)}$$ is the fixed reliability goal for the kth component.
For our medical device example, we now exclude this component from consideration. So the sum of our allocation factors is now 41.
So if we focus on the most complex component, our reliability goal becomes:
$$R_{5(DG)}=\sqrt[\frac{\sum{a_{i’}}}{a_5}]{\frac{R_{Sys(DG)}}{\prod^m_{i=1}{R^{fixed}_{k(DG)}}}}=\sqrt[\frac{41}{10}]{\frac{97.8\%}{99.67\%}}=99.54\%$$
This is slightly less than the allocated reliability goal without any criticality consideration (which was 99.55 percent). This is great! Your most complex component has a slightly easier reliability goal to achieve. You were going to have to focus on critical failures regardless – so by taking them into consideration (which you were always going to have to do) you made life easier for yourself.
And – this is another approach to reliability allocation that takes into consideration the severity of your failures.
And the ‘so what’ (summary)
Reliability allocation is the least important part of reliability allocation. I know this a literal contradiction. But if you focus exclusively on the allocation bit and not the reliability design cycle then you will inevitably fail to meet your requirements.
Your initial allocated reliability goals are guides. They provide a starting point. It is not important to have the ‘right’ starting point. In fact, there is often no ‘right’ starting point. You just need a starting point. A starting point that makes as much sense as possible. But most importantly, a starting point that allows the reliability design cycle to commence.
Reliability allocation is part of a larger reliability design approach that focuses on design guidance and motivating behaviors. You want each and every design team to design aspirationally. To strive for reliability goals that may initially exceed what you or your customer thinks you require. This has the added benefit of potentially creating a market-leading system or product without having to explicitly ask for it.
You need aspirational behavior from your designers. Your design is very uncertain at the start of a production process. So for every component that goes better than you anticipate, you will have some that really struggle. So you can ‘reallocate’ reliability from some components to others. And this means that you don’t have to find out about problems at the end of your development lifecycle. Which is very expensive and introduces substantial delays.
Understanding the reliability design cycle and the important role that reliability allocation plays means you avert crises. You limit delays. You become aware of potential problems early – which means that you can do more about them as the fixes are less expensive and easier to implement.
In short, knowing how to reliability allocation well, and understanding the reliability design cycle even better makes and saves you money.
Ask a question or send along a comment.
Please login to view and use the contact form.
Leave a Reply