Accendo Reliability

Your Reliability Engineering Professional Development Site

  • Home
  • About
    • Contributors
  • Reliability.fm
    • Speaking Of Reliability
    • Rooted in Reliability: The Plant Performance Podcast
    • Quality during Design
    • Critical Talks
    • Dare to Know
    • Maintenance Disrupted
    • Metal Conversations
    • The Leadership Connection
    • Practical Reliability Podcast
    • Reliability Matters
    • Reliability it Matters
    • Maintenance Mavericks Podcast
    • Women in Maintenance
    • Accendo Reliability Webinar Series
    • Asset Reliability @ Work
  • Articles
    • CRE Preparation Notes
    • on Leadership & Career
      • Advanced Engineering Culture
      • Engineering Leadership
      • Managing in the 2000s
      • Product Development and Process Improvement
    • on Maintenance Reliability
      • Aasan Asset Management
      • CMMS and Reliability
      • Conscious Asset
      • EAM & CMMS
      • Everyday RCM
      • History of Maintenance Management
      • Life Cycle Asset Management
      • Maintenance and Reliability
      • Maintenance Management
      • Plant Maintenance
      • Process Plant Reliability Engineering
      • ReliabilityXperience
      • RCM Blitz®
      • Rob’s Reliability Project
      • The Intelligent Transformer Blog
    • on Product Reliability
      • Accelerated Reliability
      • Achieving the Benefits of Reliability
      • Apex Ridge
      • Metals Engineering and Product Reliability
      • Musings on Reliability and Maintenance Topics
      • Product Validation
      • Reliability Engineering Insights
      • Reliability in Emerging Technology
    • on Risk & Safety
      • CERM® Risk Insights
      • Equipment Risk and Reliability in Downhole Applications
      • Operational Risk Process Safety
    • on Systems Thinking
      • Communicating with FINESSE
      • The RCA
    • on Tools & Techniques
      • Big Data & Analytics
      • Experimental Design for NPD
      • Innovative Thinking in Reliability and Durability
      • Inside and Beyond HALT
      • Inside FMEA
      • Integral Concepts
      • Learning from Failures
      • Progress in Field Reliability?
      • Reliability Engineering Using Python
      • Reliability Reflections
      • Testing 1 2 3
      • The Manufacturing Academy
  • eBooks
  • Resources
    • Accendo Authors
    • FMEA Resources
    • Feed Forward Publications
    • Openings
    • Books
    • Webinars
    • Journals
    • Higher Education
    • Podcasts
  • Courses
    • 14 Ways to Acquire Reliability Engineering Knowledge
    • Reliability Analysis Methods online course
    • Measurement System Assessment
    • SPC-Process Capability Course
    • Design of Experiments
    • Foundations of RCM online course
    • Quality during Design Journey
    • Reliability Engineering Statistics
    • Quality Engineering Statistics
    • An Introduction to Reliability Engineering
    • An Introduction to Quality Engineering
    • Process Capability Analysis course
    • Root Cause Analysis and the 8D Corrective Action Process course
    • Return on Investment online course
    • CRE Preparation Online Course
    • Quondam Courses
  • Webinars
    • Upcoming Live Events
  • Calendar
    • Call for Papers Listing
    • Upcoming Webinars
    • Webinar Calendar
  • Login
    • Member Home

by Christopher Jackson Leave a Comment

3 Ways to do Reliability Allocation #5

3 Ways to do Reliability Allocation #5

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.

 

Filed Under: Articles, on Product Reliability, Reliability in Emerging Technology

« 3 Maintenance & Reliability Leadership Gaps
The Importance of Accurate Data for Improving Asset Reliability »

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Article by Chris Jackson
in the Reliability in Emerging Technology series

Join Accendo

Receive information and updates about articles and many other resources offered by Accendo Reliability by becoming a member.

It’s free and only takes a minute.

Join Today

Recent Posts

  • Risk And Safety
  • Risk Prioritization in FMEA – a Summary
  • What Are Best Practices for Facilitating Qualitative Assessments?
  • So, What’s Still Wrong with Maintenance
  • Foundation of Great Project Outcomes – Structures

© 2023 FMS Reliability · Privacy Policy · Terms of Service · Cookies Policy

This site uses cookies to give you a better experience, analyze site traffic, and gain insight to products or offers that may interest you. By continuing, you consent to the use of cookies. Learn how we use cookies, how they work, and how to set your browser preferences by reading our Cookies Policy.