Doesn't the Weibull book contain some realistic/actual example4s for illustration of its application?

Josh,
Which Weibull book are you thinking of?

By Abinateh something... His surname is difficut to be remembered by me.

Gary,
have you deserted the discussion? We are all still waiting for your Weibull solution to the roulette wheel. We need to know the replacement interval to achieve a 1:10,000 years chance of failure using your Eta and Beta with life expressed in years.
Maybe Vee or someone else can do the calculation.

Regards
Steve

Hello Steve,

Vee previously said “Steve, I think you should take some time to understand the Weibull analysis process properly”

Well, I’ve already provided my answer using weibull parameters from the three numbers generated on the roulette wheel.

Weibull Analysis is one tool in the Reliability Engineers toolbox, there are plenty of others. If you don’t find the tool useful, then simply don’t use it.

Reliability Engineering Definition:

“A professional discipline which combines knowledge of statistics and engineering for the purpose of quantatively evaluating, prediction, measuring and improving the reliability of human products”

Source: RAC, USA

Cheers - Gary

Hi Vee,
Do you have any comments on Gary's Eta and Beta numbers?
David seems to think they prove my point?
Rgds
Steve

Thanks guys for ressurecting the discussion. I agree with Steve. Basically, if a machine fails in a so-called random pattern, ( which I don't believe exists) it would be a very poor fitter (or millwright) who couldn't work out the failures. I don't see the the point of using statistics for small numbers of occurences. It doesn't make sense to me. If the numbers are so small and the hands-on people can't work out the failure mechanism, there's your major area for improvement. Not an easy one considering union agreements, industrial etiquette etc. And! in any case, the Reliability Group are relying on that information from the shop floor to perform the analysis. How can the situation of 'Garbage in Garbage out' be avoided. I have seen so much time being wasted in Reliability Groups investigating failures with bad information and then producing pointless recommendations.
I am sure that statistics are very useful, but there is more basic work required, in my opinion.
Best regards
Joe McCormack

I am with you on that one Joe.
I will provide some feedback on the roulette wheel analysis soon. I am just a bit busy for the moment.
Rgds
Steve

Hi Joe, your argument here is based on the "garbage in and garbage out" principle which you may have experienced? I have seen this many times and typically the reason for it is that the information that is gathered is not used! I had an experience in implementing SAP on a site and we set up all the damage, cause and object codes and we said to the teams "OK go out and capture them for us".

What the reliability group pretty well much did was to sit back and wait for a few months (reactive maintenance was high so was priority) on the premise that they may have some data to do something with at some stages, "What & How", was never really well defined.

Anyway 3 months later someone decided to investigate the data and what they found was that it was quite good to start with and over the months it got worse to the point that the fitters were even putting in comments such as "does anyone read this shit"! So what then happened was more training on how to use codes and they are needed, blah blah blah. So you can guess then that after another 3 months the situation returned again.

So my point is you will always get "Garbage in and Garbage" out if you do not use the data for any purposes or involve the trades/teams in their analysis. The codes should be linked back to an RCM strategy and should also be used to initiate RCA in which the teams get involved with. Setting up robust reliability processes that promote contunuous improvement will overcome this "garbage in garbage out" because "people " will be involved in using them frequently and also seeing the value they add to the organisation.

Paulius, You're correct. I've been guilty of ignoring data sheets when completing repairs. It's especially bad in reactive maintenance situations. There are so many things which get ignored in the rush to get to the next job that the bad situation feeds on itself.
The solution, as I see it, is that there is no room for passengers. Everyone in the chain has to be, at least, compotent, and be willing to learn. It's possible to get to a good situation by making sure the basics are in good order. Statistics can be brought in afterwards to do fine tuning and I'm sure it can be useful, but it seems to me to be a waste of resources to expect it to do more than it's capable of.
Best regards,
Joe McCormack

We’ve had good luck with Problem Code Analysis of our work orders. The problem code set is pretty simple, that is, not too many to choose from: PC01 thru PC09. The tech enters the problem code on a work order. We run a monthly query to show all work orders with problem codes other than “No Failure-Acceptable”. We’ve been able to show failure trends much sooner than without the analysis and have been able to support improvement recommendations with this data. We don’t need extreme accuracy in the PC number; I mostly rely on problem codes to get work orders into the report and analyze the comments and failure remarks from there.

I don’t know enough about Weibull, but I don’t see how you can gain much value from 3 failure points without knowing whether the failures fall inside or outside the expected life of the equipment in question.

quote:

Originally posted by Paulius:
Hi Joe, your argument here is based on the "garbage in and garbage out" principle which you may have experienced? I have seen this many times and typically the reason for it is that the information that is gathered is not used! I had an experience in implementing SAP on a site and we set up all the damage, cause and object codes and we said to the teams "OK go out and capture them for us".

What the reliability group pretty well much did was to sit back and wait for a few months (reactive maintenance was high so was priority) on the premise that they may have some data to do something with at some stages, "What & How", was never really well defined.

Anyway 3 months later someone decided to investigate the data and what they found was that it was quite good to start with and over the months it got worse to the point that the fitters were even putting in comments such as "does anyone read this shit"! So what then happened was more training on how to use codes and they are needed, blah blah blah. So you can guess then that after another 3 months the situation returned again.

So my point is you will always get "Garbage in and Garbage" out if you do not use the data for any purposes or involve the trades/teams in their analysis. The codes should be linked back to an RCM strategy and should also be used to initiate RCA in which the teams get involved with. Setting up robust reliability processes that promote contunuous improvement will overcome this "garbage in garbage out" because "people " will be involved in using them frequently and also seeing the value they add to the organisation.

Paulius

You make reference to the need to link the Damage Cause & Object codes back to the RCM Strategy and also use them to initiate RCA

Our SAP Catalogue codes which were set up some time ago are not really aligned to RCM FMEA and as such are in need of some work to standardise them in line with a standard such as ISO 14224 for example.
To start we first need to agree on use of standard terminology across SAP & FMEA .
Our SAP Catalogue codes are Object part, Damage, Cause which we think cross reference to Maintainable item, Functional Failure , Failure mode in FMEA, however in ISO 14224, the examples of Failure Modes appear to be a mix of Functional failures & Failure modes !
Can you advise how the SAP Damage , Cause & Object codes should be linked back to RCM Maintenance strategies and also how to use the SAP codes to trigger RCA Investigations

Cheers
Trevors

quote:

Can you advise how the SAP Damage , Cause & Object codes should be linked back to RCM Maintenance strategies and also how to use the SAP codes to trigger RCA Investigations

Hi Trevors,

In my opinion there are 2 ways here which I have implemented both through my experience.

The first was for an offshore gas production facility where the company wanted to implment ISO14224 coding and also have the ability to feed data to OREDA. SAP has many more codes that can be switched on and can be customised to do this if this is the requirement of the business strategy. All the object, damage and cause codes are part of the configuration through transaction SPRO where catalogs can be created. In this situation you would have switched on under Notifications Content>>Maintain catalogs:

B: Object part
C: Overview of Damage
5: Causes

There are many more that can be switched on here to meet requirements for ISO14224 reporting.

So to the second part I guess which is my preference as I am not against ISO14224 but more like to see that the minimum amount of data in the field be captured as when more is asked of the teams, the quality always seems to reduce as most prefer to get the job done and move on to the next and not want to continually fill in "paperwork" as Joe above has nicely confirmed for me above. So when we design such systems this is an important consideration and try to design the ISO14224 into your reliability tool instead of SAP.

Anyway we design the RCM strategy in an external reliability tool and from the RCM model we create a library. So if you have 10 "single statge centifugal pumps of size x" this then becomes a catalog profile with all of its failure causes rolled up to it. This catalog profile is then assigned to each piece of equipment. The failure causes themselves are assigned to one of the SAP catalogs mentioned above and we have been using 5:Causes for this. (Note: I have found if people are able to select a damage (seized, worn, burnt) and Object (Bearing, shaft, seal) the amount of combinations and permutations possible becomes limitless and data analysis and linking to RCM becomes difficult)

When the work order is printed we have configured the tickets so that the causes for that equipment are listed so the teams can just tick the most appropriate code. If the code is not listed it is then reviewed by the relaibility engineer to determine whether it needs to be added to the RCM strategy etc and a new maintenance task or even redesign etc considered. The Causes in SAP can then be analysed using Weibull in 2 ways. If there is not much data for a piece of equipment, (as seems to be the main argument of this thread) weibull can be performed against the Catalog profile (Equipment Class) as in this case we had said we have 10 of these pumps on our site so we can get some good data to review the failure characteristics. The second is for the individual piece of equipment. Other techniques used here require configuring of the SAP work order type but analysis into failures in between inspections and also over-maintenance as well so the RCM strategy can be adjusted. Essentially, all of the notifcations sit within the reliability tool under each of the specific failure causes so that we have real time history for our choice and decision making of why we have chosen that strategy.

Our reliability tool initiates decision making as it has a graphical analytics portal which views all the SAP failure data (live) so that the engineer can see for his area current plant performance. Through the analytics he can see on a daily basis a Top 10 pareto of equipment v downtime, failure cause v costs etc and depending on the case he may choose to perform RCA on frequent failures for an equipment class or even equipment.

So I guess my points here are when designing a reliability system keep it simple, dont try to capture to many codes for a single work order and have a clear purpose that delivers value to the organisation in capturing this data. In my opinion it is pointless capturing codes if you do not have work processes and systems in place that will use them for benefit as what you need to do is turn this data to information that can then be used for decision making.

quote:

Originally posted by Joe Mc Cormack:
Paulius, You're correct. I've been guilty of ignoring data sheets when completing repairs. It's especially bad in reactive maintenance situations. There are so many things which get ignored in the rush to get to the next job that the bad situation feeds on itself.
The solution, as I see it, is that there is no room for passengers. Everyone in the chain has to be, at least, compotent, and be willing to learn. It's possible to get to a good situation by making sure the basics are in good order. Statistics can be brought in afterwards to do fine tuning and I'm sure it can be useful, but it seems to me to be a waste of resources to expect it to do more than it's capable of.
Best regards,
Joe McCormack

Hi Joe,

I guess its "horses for courses" in many cases as capturing data to certain levels can also depend on the industry. The amount of effort of setting up such a system needs to obviously weighed up against the business impact it will deliver. I have in some situations implemented some common failure codes (brainstormed with my maintenance team) and their purposes was solely to capture a top 10 system downtime contibutors that are then used for RCA within the teams. In this case statistics was never used and also RCM was never implemented because more value was delivered through this process as yes, I agree it would have been a waste of resources and my budget.

On the other hand I have also worked in facilities where we would have up to 50 relaibility engineers where their sole purposes was reliability engineering and managing such statistics to ensure the safe and relaible operation. Here we do not rely on "failed" data but use statistical techniques to understand the size of the ice-berg (whats under the water) so as to prevent the ship hitting the top. The investment into such systems and work processes is easily justfied and seen as a necessity such that the reliability engineers purposes are focussed on prediction and not reacting to failures. Reliability has close links to probability and to determine the probability of an event you need some sort of data. The more data the better your chances on determining the probability of an event and hence reliability. and again please note it does not mean failed data as well!! Therefore data becomes a vital means of allowing a relaibility engineer to predict plant performance over a given period.

The myth is busted

quote:

One of the advantages of Weibull analysis is the ability to be able to analyse small amounts of failure data and get some reasonably accurate failure forecasts without having to wait for more failures

BUSTED

quote:

However, there are times when urgency is required and a sense of direction is needed, particularly in the case of safety, environmental and high cost issues. We cannot afford to wait for more failures to occur in order to support our conclusions.

True but to imply that Weibull analysis with three data points provides a solution – BUSTED

Forum Members– the problem was to try and predict the pattern on the roulette wheel using three data points and Weibull analysis.
The answer came back saying that the roulette wheel had a mean of 27.66 and had a heavy bias towards the higher numbers.
If this were a real example and the numbers that were used to represent the roulette wheel were the life of a component in years, and I wanted to use Weibull analysis to reduce the risk of failure to less than 1/10,000 years, the answer would be to change out the component at around 3.21 years as shown in the table below. I used excel to generate these numbers and used Beta ,4.096 and Eta 30.4
Life___Prob of Failure
0_____0.0000%
1_____0.0001%
2_____0.0014%
3_____0.0076%
3.21___0.0100%
4 ____0.0247%

The 1:10,000 years equates to a probability of failure of 0.01 %
Now we all know that the roulette table is a random number generator – the one in question has 37 numbers ranging from 0 to 36. The average is 18. If we changed the component out at 3.21 years then it would be the same probability of getting a number less than 3.21 on our roulette wheel. There are four numbers less than 3.21. They are 0,1,2 and 3. So actual probability of failure at age 3.21 is around 4/37 which is near enough to 1 in 10.
This is scary – I do my Weibull and I am looking for a 1:10,000 change and I end up with 1:10.
By the way – a friend of mine used a simulation model and came up with a change out life of 4.75 years which is even more scary. See attached document.
Forum members – If the failure of this component led to some serious injury then if I use the numbers presented and Weibull analysis to assess the change out, over a large period of time I will injure someone once every ten years with each component I have installed.
Nothing more can be said – Weibull is not only useless in this application – it is dangerous. It can not be used on its own on small data sets. Now some will argue that where there are three data points and their range or band is small compared to the age, the statistical significance is higher and this is true – but even with such a data cluster – enormous care needs to be taken – I would never risk my reputation on such an analysis.
So there ends the myth I hope

AvsimRouletteAnalysis.xls (88 Kb, 6 downloads) Avsim Analysis

Hi Steve,

I am a little late in this debate as you can see I have not responded to it as of yet. To me something does not add up to what has been presented so far. Typically a beta value of > 4 depicts a good wearing component so we can see with a good degree that 63.2% of the failures will have occured by the time we reach our eta of 30.4 years. Over the 10,000 year lifetime we would expect to get something like 365 failures if we let this component run to failure. If we replace at the stated interval of every 4.7 years we would expect that we would get something very close to 1:10,000 chance of failure, based on these values.

I think the flaw in this argument is that somewhere a beta of 4 has been calculated I think by GLT based on some random numbers. In a roulette wheel we all know that it is a random number generator so therefore the beta value should be = 1 no matter what. Try having your friend recalculate with a beta =1 and see what the results is. Weibull is a flexible distribution that can model any life scenario from infant mortality through to old age, which for us reliability engineers provides us a great tool to model our plant behaviour.

I guess you have highlighted one thing which is to understand when weibull is used and how its parameters are correctly applied. This is not something that can be just given to an engineer and to say "go and use" as it does take education and practice in applying it to the sites machines and equipment. Applying it blindly will lead to results as highlighted in this thread. There are many companies that train people in such methods and I recommend that they partake in such training if they are going down this path.

If anyone knows a roulette wheel that can generate numbers to produce a beta >4 please let me know as I need some cash!

WEIBULL as a Usefull tool :CONFIRMED

This message has been edited. Last edited by: Paulius,

Paulius,
The essence of the roulette wheel / table example was to illustrate the grave shortcomings of using statistical methods with small data sets to develop conclusions about failure distributions. It does not matter what distribution is used [Exponential (either 2 or three parameters), Normal, Lognormal, Gamma; G-Gamma, Chi-Squared, Logistic, Loglogistic and Gumbel - Thanks Rui for some of these I have never heard of], three points can never be accepted as sufficient to provide the confidence engineers need to make proper decisions. It is not ok to say where safety is involved and data is scarce, Weibull can fill in for the deficiencies.
If you have a large data set - and I am talking in the order of 20 points, then fine - but even with this set of data, one needs to be careful. Often there are more than two drivers of the failure pattern hence the curve does not fit Weibull either. I have seen this many times.

quote:

I think the flaw in this argument is that somewhere a beta of 4 has been calculated I think by GLT based on some random numbers. In a roulette wheel we all know that it is a random number generator so therefore the beta value should be = 1 no matter what.

Precisely.
This is my case. How can someone suggest that a roulette wheel has a beta value of 4?

quote:

This is not something that can be just given to an engineer and to say "go and use" as it does take education and practice in applying it to the sites machines and equipment. Applying it blindly will lead to results as highlighted in this thread. There are many companies that train people in such methods and I recommend that they partake in such training if they are going down this path.

Paulius... the serious part is that there are training courses in the market that say it is ok to use Weibull with three data points. What do you think of that? There are RCM software packages out there that require Eta and Beta numbers to allow the users to create the interval. Where do these numbers come from?
The reason I have persisted with this thread is to get some awareness of the problem. I will talk more in later threads.
Rgds
Steve

Steve

This message has been edited. Last edited by: Steve Turner,

Hi Steve,

In regards to 3 data points, these are seen as a minimum to be able to generate Weibull parameters in fact you can generate a plot with 2 failed data points. Also you can use 2 failed data points and a suspended point if needed. A suspended failure is the time since last failure to current day ie you know it has lasted this long at least but has not yet failed.

Anyway, Weibull is simply used to calculate the failure characteristic of a piece of equipment or its component so that we can then determine the most appropriate maintenance strategy. (ie it will tell us whether we have early failure, random, degradation or wear behavior).

I agree with you that 2-3 points may not be enough in some cases, but for others it maybe enough data. This all depends on the situation and circumstances it is being applied to and I guess is the real difference between a "Mathematical Statistician” and a "Reliability Engineer".

The Mathematical Statistician will apply such numbers without a good working knowledge of the machine and its environment and could lead to an impractical solution, where the Reliability Engineer will understand the machine, risks, production etc and make a decision whether more data is needed or the current amount is enough.

Using Weibull is just a tool for decision making but it requires more than just throwing the numbers into a calculator and coming up with an eta and beta. It requires engineering judgment to each individual situation which at the end of the day is the skill and the practice of an experienced Reliability Engineer.

Interesting arguments here.

I understand that Weibull analysis has been and continues to be used extensively in the aerospace and defense industries. AND used successfully.

They cannot afford failures and furthermore they cannot test a plane to failure due to the expense.

So, how do your arguments here square with the success seen in Aerospace? I think they're likely more reliable than the general manufacturing plant.

quote:

In regards to 3 data points

Fitting the 2 parameters with just 3 points would provide 0 statistical confidence in the fit. I've seen this done but doubt the value when using so few points.