Steve,
I guess that is another attempt at humor, so I will let that remark pass.

A heat exchanger is the main tag item - that is what I expect to find in the Asset Register. The fan, motor etc. are subsidiary tags, supporting this main item. The vendor will supply all the subsidiary items as part of his package. He will have designed the fan and its drive as part of the exchanger.

While it is correct to draw system boundaries, I have not seen a system boundary through part of a package before. To carry your logic further, you could draw the boundary at the motor, motor+coupling, motor+coupling+gearbox, and so on. In a like manner, if you are analyzing a motor car, you could stop at the tires, power transmission etc., but I think it makes sense to look at the whole car.

The fan assembly and structure will almost certainly be part of the fin-fan cooler structure.

For all these reasons, I am struggling to understand your approach.

People,
I am glad to see that many members are actively following this thread. It would help me, and I think Steve as well, if you posted your own observations, comments or questions and make the subject more of a discussion than merely a dialogue. I think many of you are very interested in this subject. A few, who are less experienced may feel diffident and wary of criticism. If that applies to you, remember your views and experiences are just as important as that of others who may be more experienced.
Please pitch in; I will certainly welcome that, and try to be supportive. We will all learn and benefit when you join in.

Steve,
I note that you have not responded to my post of 15th. This thread was created by you, so please let us know if you intend to see it through ... or not.
On the 2nd Dec. 09, I wrote
"I have hesitated to put these (my questions) up so far because I am not sure these will be acceptable (to you)."
From what I see so far, my concerns were probably justified.

quote:

I note that you have not responded to my post of 15th. This thread was created by you, so please let us know if you intend to see it through ... or not.

Vee,
I didn't see any questions in your post so I did not respond.
I am happy to see this through. I think that a lot of the questions are irrelevant but as I have done before i will answer them if I know the answer. If I don't know the answer, and you think the information is important, then make some assumptions. Show me that the information is important and I will learn something no doubt.

Vee,
When we do analysis in PMO2000, we do have system boundaries. I don't think there are hard and fast rules about where to set the boundaries because there is no definate logic where to draw them. You say the whole heat exchanger seems logical to you. It does not seem logical to me. I would put the cooling circuit, all its valves and instruments as a system and leave the fan out. Thus my comment about where all this ends.
The other reasons we would set the project up this way is because:
1. There are lots of fin fans on site and each heat exchanger may be different. We like to use library analysis so the fin fan fits nicely into this.
2. The fin fans are causing the problems, not the heat exchanger.

If you want to analyse the whole system including the heat exchanger and valves and instruments - go for it and deliver a time consuming project with no return. By the time you finish all of that with RCM we will have done another analysis and turned in another massive improvement.

And yes, in PMO2000 we can draw boundaries at any level. This is where RCM falls down because it starts with functions and from that looks at a systems approach rather than a needs approach. PMO2000 is flexible - it can even be done on operator rounds which have say 50 assets to inspect. At one site we reduced a 47 item check list for operators that was supposed to be completed every 6 hours into a 7 point check every shift, 3 more checks daily and another 5 weekly. This project took about two days
Try doing that with RCM .

quote:

A heat exchanger is the main tag item - that is what I expect to find in the Asset Register. The fan, motor etc. are subsidiary tags, supporting this main item. The vendor will supply all the subsidiary items as part of his package. He will have designed the fan and its drive as part of the exchanger.

While it is correct to draw system boundaries, I have not seen a system boundary through part of a package before. To carry your logic further, you could draw the boundary at the motor, motor+coupling, motor+coupling+gearbox, and so on. In a like manner, if you are analyzing a motor car, you could stop at the tires, power transmission etc., but I think it makes sense to look at the whole car.

The fan assembly and structure will almost certainly be part of the fin-fan cooler structure.

For all these reasons, I am struggling to understand your approach.

Getting back to the system and functions, would you require someone to go and find precisely what the product rate and temperature drop parameters are?

Pls give the whole datasheets of the fin fan cooler c/w motor if available, from Ollie I guess.

Josh,
If I were to provide all this detail it would be made up. When we do these analyses, we dont spend a lot of time getting all the "intimate" details of all the equipment. Perhaps you do.
I have provided all the failure history over two years and extracted the longer term failure modes from the CMMS.
If you think it is important to get all the machinery and process specifics, I would be happy for you to make them up. We can then see how dependent on the assumptions, the resulting maintenance program is.
The motors are standard with thermistors fitted. The coupling is a cone ring coupling. The gearbox is a wheel and worm wheel gearbox. The blades are FRP. The fan shaft bearings have never failed.
If the fan rotates at 160 rpm, then the system works fine.
That is pretty much all I know. If you have other specific questions, I can make them up or you can. I am of the opinion the purpose of this thread is to understand PMO2000. PMO200O does not go into enormous detail unless there is a need that arises during the workshop. I dont see any need this far except for the fact the system is what we would call "unmaintainable" from a fan belt perspective.

Steve,

quote:

The fin fans are causing the problems, not the heat exchanger.

If you want to analyse the whole system including the heat exchanger and valves and instruments - go for it

You mean the fans are causing the problem, not the 'fin-fans'. I am sure you are aware that the fin-fan cooler refers to the finned tubes and the fan as a unit, not just the fan.

No I would not necessarily ask that we include all of the product circuit, but that we include all of the air flow circuit, i.e. the external part of the finned tubes and the part of the product flow stream within the cooler.
Here is where we differ; to you the job is for the fan to spin at >160 rpm. You don't care whether the fin-tubes are clogged with dirt, loose paper or other small debris, or the cowling is torn or even if it exists. All that matters to you is that the fan spins at >160 rpm. To me the purpose is to cool the product, so the air flow AND the heat transfer efficiency matter. Perhaps your lower mesh is so fine that not even dust can go through, let alone loose paper etc. Is it?
You have stated clearly repeatedly that you do not have expertise in e.g. design. electrical/mechanical work details. Your forte and of your expert facilitators is the PMO 2000 process and your qualifications/experience in using RCM. So you and your 'expert PMO 2000 facilitators' are totally dependent on what the client's fitters, operators and electricians tell you and what the vendor's manual says. By your own admission, you will not (or cannot) challenge their views. In contrast, I bank on my practical experience of many years maintaining equipment - including fin-fan coolers. that tells me that keeping the fins clean is almost as important as keeping the fan running. If I hear to the contrary, I will try to understand why by challenging them. This is what I am doing here, and since you offered to be their spokesman, I ask you for an explanation. The answer seems to be that it is expedient for your PMO 2000 process.
Before you get on your soap-box on BTUs and air flow rates yet again, let me assure you that I (and most other analysts) would define the BTU bit by specifying the inlet-outlet temperature difference at rated product flow. Similarly, the air flow would be defined by fan speed, since the pitch is NOT adjustable.
So I would have defined the system boundary at the exchanger's product isolation valves. This would still allow me to apply/adopt the analysis to the other fans, meeting your expediency requirements while adding very little analysis work, but one that in my view, is essential.

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

Vee,
We have a personal difference about setting the boudaries on this one. If I were using RCM I would have set the same boundaries. It is not a difference between processes.
At some later time we would have analysed the cooler using either RCM or PMO.

quote:

You mean the fans are causing the problem, not the 'fin-fans'. I am sure you are aware that the fin-fan cooler refers to the finned tubes and the fan as a unit, not just the fan.

Vee,
Here are my answers in bold

Here is where we differ; to you the job is for the fan to spin at >160 rpm. You don't care whether the fin-tubes are clogged with dirt,
I did not say I "don't care if the fin-tubes are clogged with dirt". The tubes are not within the boundaries of my system. We have spoken before about twisting what I write

loose paper or other small debris, or the cowling is torn or even if it exists.
If you look at the schematic, the cowling is included. If you look at the failure history you will find some failures. If you look at the analysis, it has analysed what needs to be checked from the cowling. There is no history of the cowling being torn. Small debris does not seem to be a problem either.
All that matters to you is that the fan spins at >160 rpm.
Yes and no - what matters to me in this system is the fan runs at >160 RPM which cools the coolant which cools the system which ends up making product which is sold.
By discussing functions on this forum in this way, I am hoping to shake out some traditional thinking. And I think this is one of the key differences between RCM and PMO2000. RCM is intense on functions. PMO2000 is far less intense.
At the end of the analysis, we can determine if using a function statement of >160 RPM or using your suggestion of temperature differential and flow, changes the PM Program that is generated.

quote:

, let me assure you that I (and most other analysts) would define the BTU bit by specifying the inlet-outlet temperature difference at rated product flow.

I know, and just because lots of people do it, does not make it the correct way.
Heat exchangers provide cooling which has a metric defined in Thermal Units or other energy standard terminology.
Saying x degrees drop with y degrees flow rate is no different to me saying this fan running at >160 rpm.
But if I were to define the function of the cooler as per what the manufacturer says, I expect it would not be in your terminology.
When I bought a heater for my spa bath. I worked out the energy I needed and what different BTU heaters would achieve. I did not try to calculate flow rate through my system.
Anyway Vee,
I dont think my terminology of >160 rpm is different in concept to your function of flow rate and temperature drop. All that is different is your system boundary is different. And I think that RCM puts too much emphasis on defining the functions precisely. The BTU discussion is meant to illustrate that point. If we were to be true to the specification, we would find out the energy in some standard parameters such as BTU. Instead we find that too hard, and deal with indicators of that performance like RPM or temperature and flow rate.
Out of interest, if you were doing RCM on an oven in a bakery, how would you define the performance standard?

quote:

You have stated clearly repeatedly that you do not have expertise in e.g. design. electrical/mechanical work details. Your forte and of your expert facilitators is the PMO 2000 process and your qualifications/experience in using RCM. So you and your 'expert PMO 2000 facilitators' are totally dependent on what the client's fitters, operators and electricians tell you and what the vendor's manual says. By your own admission, you will not (or cannot) challenge their views. In contrast, I bank on my practical experience of many years maintaining equipment - including fin-fan coolers. that tells me that keeping the fins clean is almost as important as keeping the fan running. If I hear to the contrary, I will try to understand why by challenging them.

Vee,
we seem to have a difference here and you have pointed that out. What we are supposed to be discussing is not who has the most experience but what is the difference between processes. If you were using PMO2000 on this fin fan would you have included the fins? If your answer is yes, then you have not identified any difference between processes. PMO2000 does not prescribe system boundaries and I dont recall RCM having much to say on that subject. Typically we set the system boundaries to run a workshop over four days. We work out what we can do and we set those boundaries. We also vary the way we do this - as we explained, we do a lot of library analysis which means we set system boundaries on pumps, compressors, and in this case, belt driven fans.

Vee,
this is not right.

quote:

you will not (or cannot) challenge their views

We teach the team the principles and we test their logic. If we dont agree with the logic then we let this pass during the workshop and raise the issues with site management.
In so much as I would not argue with you on technical matters to do with fin fans, I would not argue with the people on site who are expert.

I thought consultants should have some levels of technical expertise when offering services. ANd insiders sometimes look to outsiders for technical assistance.

I remember one case where the consultant failing to convince the folks about issues and then talk to the MD so the decision seems dictated on them so it appears high-handed.

Josh,
We certainly employ technical people but we work in vastly different industries and in all sorts of disciplines in most continents of the world. Many of these are hazardous facilities.
It is not practical to employ people that we are prepared to put up as experts in customer businesses where ever they may find themselves working. We are general consultants.
How would you feel offering advice for example, to underground mining companies here in Australia - NSW to be specific which have a completely independent set of regulations to any other state in Australia, leave alone the rest of the world? I dont know your background, but lets assume you are doing some analysis of flameproof enclosures and other electrical systems on a continuous miner and you are a mechanical engineer?
How would you cope if there was an explosion and the advice you provided to the customer, became evidence in the prosecutions hands and the legal people found you had a big insurance policy and your advice was somewhat vague and misleading.
Our rule is we do what we do well and we don't advise clients when we don't know.
We are happy to say that things dont seem right but we dont provide expert opinion on engineering matters. If the customer does not have the experts, we can offer some of our network.

Steve,

quote:

PMO2000 does not prescribe system boundaries and I dont recall RCM having much to say on that subject. Typically we set the system boundaries to run a workshop over four days.

Using RCM does not mean we abandon common sense. Having worked on fin-fan coolers in West Borneo in situations not unlike those in Jurong, I know that there is a significant salt content in the air. Depending on the materials of construction of the fins, they can degrade due to corrosion, and more commonly, salt encrustation and fin blockage. Unless one actively looks for it, e.g. by monitoring the differential temperature of the product stream or physical inspection of the fins, this can go unnoticed till it results is major investment in new tubes. If the client's interest is not in long term profitability, one can of course bury the proverbial head in the sand. If I were the Consultant, I would certainly monitor this degradation mechanism, though no failures may have been recorder so far.

I will include the cooler air flow path and the cooler product flow between isolation valves in the system boundary, i.e., by defining the FUNCTION as to cool product from X˚C to Y˚C at Z tons/hour. Hence the fouling of the fins, and (depending on fin material) corrosion of fins will appear as failure modes. Your Function-Free method will remain blissfully unaware of these failure modes, since they may not appear in the history.

On this subject at least we have stated our respective positions clearly and I will not argue this any further. Readers can judge for themselves which method is technically sound and more likely to bring business benefits for the client.

Let us get another point clear. Whether this is your training exercise or not is not of great interest to me, so whether it is meant for a 1-day or 4-day training course does not impress me one bit. You have told me that the case data is based on a real life situation. Your example is meant to demonstrate your process. If readers including me are to examine it, you have to tell us the data truthfully, not hide behind its being a training exercise, or by your lack of observation of ball-park dimensions, or inability to read a manual to find out the as-new rpm of the fan. To me, all this is obfuscation and an attempt to conceal relevant data. Perhaps you are hoping I will give up, by stonewalling and you may well be right. Please respect the fact that I am spending a lot of my time. If readers decide your process smells of roses, that may be to your advantage. Those of us who don't know your process will never know, if you do not cooperate.

Steve,

quote:

Saying x degrees drop with y degrees flow rate is no different to me saying this fan running at >160 rpm.

If the fins are sufficiently fouled with salt encrustation or dirt or paper, or if the fins are corroded and broken off, the speed becomes almost irrelevant.

quote:

In so much as I would not argue with you on technical matters to do with fin fans, I would not argue with the people on site who are expert.

Here is the problem as I see it; if the analyst does not understand the physical process and understand the degradation mechanisms, he is in no position to challenge anything that the client 'expert' says. The logic alone is unlikely to reveal technical defects or fallacies; one has to know where to look.

Steve,

quote:

It is not practical to employ people that we are prepared to put up as experts in customer businesses where ever they may find themselves working. We are general consultants.

That is a fair observation, and one I can agree with. No single person knows everything about any industry.
But I do not think that is the point at all. Do your people have basic mechanical, electrical, instrument skills, and have they done maintenance work before? Have they done basic maintenance tasks on commonly found equipment in the industries to whom they offer consultancy? Do they know equipment such as reciprocating and rotating machinery e.g., compressors, pumps, conveyors, engines, fans, exchangers, fear-boxes, clutches etc.? Do they know how to do maintenance tasks on e.g., couplings, bearings, seal replacements, drives, do alignment, balancing, electrical testing, instrument calibration, taking vibration or other readings etc.? If they dont know these in relation to the equipment in the facility, the client will be short-changed.
If you employ MBAs or fresh Engineering graduates who can manipulate excel sheets or databases, read logic trees and challenge the logic, I would argue that it is NOT quite good enough.

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

Steve,

quote:

Vee,
1. this is not right.
quote:
2. you will not (or cannot) challenge their views
3. We teach the team the principles and we test their logic.

You are confusing technical understanding with an understanding of the logic. The latter is important and necessary. However, without the technical understanding, I do not believe you are in a position to question issues on the technical front. Without that, it is not feasible to understand the degradation mechanisms or performance metrics.
If logic was the only path to success, we should merely employ lawyers, not people with any technical background. I am sure you have anecdotes to show some of the ridiculous outcomes of legal processes.