Join or Manage Your Profile
Posting Boards
Maintenance and Reliability
Posts About Improving Reliability
Virtual Reliability Centered Maintenance (RCM) Analysis|
Go
![]() |
New
![]() |
Find
![]() |
Notify
![]() |
Tools
![]() |
Reply
![]() |
|
I think we should move forward with the functions as soon as you can incorporate comments to the functions. Without trying to slow this down, I think we have expanded the functions into too many. This list of functions could support the full breakdown of all the LRUs individual replaceable components. Many of these functions could be combined and then broken out at the Functional Failure and then EFM/ Failure Mode level. I say this simply as an observation because the "manageability" of this layout is less than optimal. It appears there are functions for each component (from the parts list) of the end item, which is not typical of a "system" level analysis. Steve, I expected even more consolidated functions than I would have recommended, so, I'm surprised. I am NOT suggesting starting over as it is important we make progress to keep interest, I just wanted to point out that typically (from my experience) most "Items" have 4-15 system level functions, which improves the "flow" of the analysis. Either way, I say, lets keep moving. |
||||
|
Hello all,
Thanks for all the input. I have updated the template with a overview of all comments and made a overview of the functions to continue with adding functional failures. Trevors also made a start with FF and FM so I added those as well. Let's first concentrate on the FF and continue with discussions. Updated template This message has been edited. Last edited by: Rogier, rcm2_template_V2.xls (90 KB, 81 downloads) |
||||
|
I provided some FF for consideration on the google doc's.
One question, can the fan "overspeed"/ is too much air flow a problem? |
||||
|
Guys - this question appeared on the spreadsheet''''
To direct the airflow (and prevent flow losses at the blade tip?) coloured text => Steve what do you mean here The cowl makes the fan efficient. If the cowl is not in place the airflow will reduce |
||||
|
Johnny
The whole purpose of this thread is for discussion. Can you elaborate on your point please. I would be happy to discuss my thoughts. Steve |
||||
|
Typically when performing "system" or "end item" analysis the functions are relevant at the level of analysis. Functions like "provide safety provisions for operators/ maintainers/ equipment" or "provide monitoring/ warning capability prior to catastrophic failure (with time to react)" instead of producing a separate function for each sub-assembly which may contribute to that function. The sub-assy's would be broken out at the FF or EFM/FM level. This produces more of a "tier-ed" analysis instead of one which is "flat" with each component having a function, FF, EFM/FM.
Sorry this is not better though out, but it's Monday. Currently we have several functions which add up to "generate ?X? airflow", "provide ?remote? monitoring/ alarm to ?standard?", "Cool ?X?", "Operate safely". The result of putting component functions at the function level makes the functions less relevant to the system/ end item but is good for identification of the components, but searching at the FF level or the EFM/FM level does the same thing. This would be much easier in person or by phone (feel free to give me a call). Again, my apologies for not presenting this any clearer. |
||||
|
Hi Johnny,
Thanks for your explanation. I agree with you not to name equipment items in the functions and stay on system level. When I look at the functions that's I think what we did. The only time it's done is on function 5. This function has to be deleted because it's already covered in function 4 (my mistake). When in the function the fan is named reference is made to the fan system, see the scope in the attached updated project plan. projectplan-v3 Because I am still a facilitator novice can you describe which functions are not correct and make a list of functions you would see defined. This is not for reopening the discussion but learn from different approaches. Regards, Rogier This message has been edited. Last edited by: Rogier, Projectplan_RCM_Case_Study_Cooling_Fan_System.ppt (497 KB, 66 downloads) |
||||
|
OK, again, I really don't want to de-rail where we are. Naming of a component is ilrelivent. Most of the current functiona ARE component functions whether you name the component or not.
On similar items, I am used to seeing 5 functions 10-15 FF and about 30 failure modes. Typical functions are: Provide airflow (covers motor/drives/ducting) Provide fluid containment (covers anything that can leak, soemtimes covers air leaks) System monitoring (all monitoring, detecting, allarm, display) Maintenace/ access/ adjustment Allow engagment/ disengagment (covers drive and elect, clutches ect) Distribute and carry loads/ attachments (covers structure, fittings and attachemnts) We are starting with about 30 functions which will result in a flat analysis. Everyone has invested into the current list and I say keep it for this exercise. It will work, it's fine, I just wanted to point out, in some places it is done diffrently. V/R: |
||||
|
Johnny,
Thanks for your explanation and getting a view of a different approaches of RCM. On page 1 of this topic there was actually a suggestion to compare the different RCM methods like RCM 2, RCM Cost, RCM Turbo, RCM Blitz and PMO2000. Reading the chapter of functions in the RCMII Moubray book I think we defined the functions according to the RCMII method, please correct me if I am wrong. Can you tell us which method you have use describing the functions? Question to all team members and observers: Ttell us which method you use and in what way you will handle defining functions in relation to the to different approaches. Maybe there are more? We do not want to slow down the study but get a wider understanding of the different methods and approaches. So please also respond in filling in or commenting the Functional Failures. Regards, Rogier |
||||
|
I think we are doing RCM2.
If someone wants to introduce another approach then that is fine but we cant integrate the two. The have to be separate analyses. Rgds Steve |
||||
|
Questions / suggestions:
17 To protect equipment from corrosion. I cant see any corrosion protection on this system hence I think the function should be dropped. I think another function is to prevent foreign objects such as paper and rubbish entering the fan... which should be added to function 8. FF - Intermittent loss of cooling air. I think this is covered by total loss of cooling air. We dont consider the time frame. Loss is loss I suggest. Wrting Failure modes.. 1. Usually I write them as something (component) fails due to mechanism. Just a formating thing for consistency. Instead of broken belts, I prefer to write belts fail due to normal wear. 2. Seized motor is very general - would it be better to write motor bearing seizes due to wear? Comments? Is it worth adopting these consistent rules of analysis? Rgs Steve |
||||
|
2 parts,
First Rogier: My methods are consistent with JA1011, NAVAIR 403, RCM II, and "not inconsistent" with MSG-3. I do/ have done analysis at the facility, platform, system, removable component level. Whatever the level of analysis is where I target the Functions. Second, Steve: I absolutely agree the "form" of failure modes should be "groundrule-d" up front. Typically, I write Functional failures as an "anti" function which is most easily noticed or described. "It failed to blow enough (or any) air" (that might be 2 FFs). The Failure Mode (FM), or by my definition Engineering Failure Mode (EFM) we combine the 1629a defined "Mode" and "Cause" with a "due to" between them. So, it would be "Fan motor sized due to internal failure". Typically the FM/EFM is written to the detectability level of the maintainer dealing with it. This is why I didn't write "fan motor #2 bearing failed due to galling", because the maintainer who is dealing with this failure has no way to know. If a disassembly of the motor is done, AND a line replaceable unit (LRU) analysis was done, it would have the lower level failures fully detailed. So, I would recommend we "groundrule" that Functional failure be an anti-function as described on a potential work order and the Failure Mode be: Item/failure/due to/cause. |
||||
|
I have inserted comments to Trevors Functional failure cells along those lines.
Mike. |
||||
|
http://spreadsheets.google.com/pub?key=pdpGecGencbmwJcmyWvR4WQ
IS this the latest update to the spreadsheet. I added some FF to this list several days ago, and someone put in some FM that look pretty good. I like the description of damage "by any other means (than corrosion)". This may be very relevant though I have never grouped so many things together. For a FM/EFM they should only be grouped if the effects, detection method and preventative/preventive and corrective actions will be the same. I would think the effects would be different for minor mechanical and major cracking damage. I have seen "damage" grouped by "within repairable limits" and "beyond repairable limits" and "outside of safe operation". Typically, I don't like this as there could be different preventative measures for accidental damage vs. wear/ rubbing vs. fatigue and you miss that root cause in the grouping. |
||||
|
Johnny, I dont think it matters about the detectability of the maintainer to the spefic mechanism of failure. At the FM stage of the analysis we should not be making assumptions about detectability. My view is that analysts should be writing what fails and how. The right team would know what the resuling failure types might be should the component be stripped and a detailed examination done. You have made me think because I have never had to explain what level of mechanisms I write FM's at... it would make for a long analsis to describe all the precise mechanisms by which a bearing could fail (and I would not do this) so I tend to write a general mechanism such as "normal wear". Motor seized due to internal failure is too vague for me. But in some cases, when I am dealing with electrical components that could fail in many ways (mother board on my computer for example) I will write "mother board fails for various electrical / electronic reasons). I just think the analysist should look at it from a practical point and write a level of detail that allows sufficient detail for the reader to understand and be confident the analysis has not been too superficial, yet makes sense without being overly detailed. I dont think the detectable criteria is the right one, but I dont have a good alternative. Comments from others please? Rgds Steve |
||||
|
I would regard a failed bearing as failed no matter what the reason. Obviously a task to detect failure being the remedy. Perhaps the only exception being if it were due to faulty installation practices in which case we would be looking to modify (procedures).
Mike. |
||||
|
So what would you write Mike... bearing fails due to ________?
|
||||
|
Steve - if there was no dominant failure mode for the bearing in question I would write:
1.Bearing fails due to wear and tear. 2. Bearing fails due to improper installation. Of course the question would be asked of the particpants: Guys have you had bearing failures and if so what have they tended to be caused by - and if for example someone piped up and said - "We realised one of the bearing failures we had was due to lack of grease" - then this would be included as a third FM. So Steve over to you - have there been any bearing failures on the fan system not attributed to wear and tear to your knowledge? Mike. |
||||
|
Terry & guys, perhaps RCM deserves a separate posting board like RCA etc. for easy reference.
|
||||
|
Mike - (mechanics hat) we do experiece premature bearing failure and I suspect they are caused by poor installation in some cases. (facilitators hat)I would not list incorect installation - since we would never end the analysis of the plant. I would write lack of lubrication - because that ends up as a lube task. Rgds steve |
||||
|
| Powered by Social Strata | Page 1 2 3 4 5 6 7 8 9 10 |
| Please Wait. Your request is being processed... |
|
Join or Manage Your Profile
Posting Boards
Maintenance and Reliability
Posts About Improving Reliability
Virtual Reliability Centered Maintenance (RCM) Analysis
