|Plant Maintenance Resource Center
M-News Edition 36
Edition 36, July 2003
In this edition...
If you wish to receive notification of future copies of this newsletter by email, please register at www.plant-maintenance.com/registration.shtml. If you have any feedback on the newsletter, or have something to contribute, please send me an e-mail.
As mentioned in the last newsletter, we are making up for lost time! This is the second edition of this newsletter to be issued this month, and in it we bring you four more high quality articles, and more. Enjoy!
Alexander (Sandy) Dunn
You may know exactly the good engineering reasons why your company should be investing in Condition Monitoring equipment, but to make your case, you must learn to think in financial terms. This article, by Stan Jackson of SPM Condition Monitoring Solutions, explains how.
You will find the article at http://www.plant-maintenance.com/articles/numbercruncher.pdf. Note that you will require the free Adobe Acrobat reader to be able to view this file.
This article, from Bryan Weir of PEMMS, is an introduction to Equipment Failure Codes. It outlines what they are, where and why they are used, and how they are formed. It also includes a list of typical failure codes. You can read the article at
Is a vibration reading of 4 mm/sec a proper limit for accepting balancing quality of a new forced draft fan? Is this limit also applicable on a new cooling water pump? A key element of Machinery Health Management is the expertise to determine proper acceptance limits for different machine types and speeds. This simplified article outlines a process for determining balancing quality acceptance limits for newly purchased or serviced machines. It is based on an interpretative reading of ISO 1940/1. Illustrative figures are given to emphasize the major concepts of that standard.
You can read it at http://www.plant-maintenance.com/articles/balancingqualitylimits.pdf. Note that you will require the free Adobe Acrobat reader to be able to view this file.
There are many improvement methodologies and techniques available to improve plant reliability and availability, including such techniques as Reliability Centred Maintenance, PM Optimisation, Weibull analysis and others. However all of these techniques have significant limitations when it comes to dealing with high consequence, low probability events - those events that have potentially catastrophic impacts on plant integrity. This paper, written by Sandy Dunn of Assetivity discusses these limitations, and outlines an alternative approach to effectively identify, and manage, asset integrity risks.
You can read the article at http://www.plant-maintenance.com/articles/assetintegrity.pdf. Yet again, you will require the free Adobe Acrobat reader installed to be able to view this file. This paper was originally published at the ICOMS 2003 conference. Additional papers from ICOMS 2003 are available for purchase - you can access the list of papers and videos from www.icoms.org.au/icoms_proc.htm
This book is more of a Management book than a technical book aimed at Engineers, but there is a lot in this book that is relevant to the jobs of Maintenance and Reliability Engineers and Maintenance Managers. This book discusses how "High Reliability Organisations" (HROs) organise for high performance in environments where the consequences of error and disaster is overwhelming. When read in conjunction with some of the other books on Risk and Reliability covered in previous reviews (such as Reason's "Managing the Risks of Organizational Accidents", or Evan and Manion's "Minding the Machines - Preventing Technological Disasters", this expands, yet again, our understanding of what organisations must do in order to become true "High Reliability Organisations".
Read our review of this book at www.plant-maintenance.com/books/0787956279.shtml.
Here are ten Maintenance-related books that we have reviewed recently, and strongly recommend:
Get more information on these and other books at http://www.plant-maintenance.com/maintenance_books.shtml.
Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob, and a lever. "What do you think this is?"
One advisor, an engineer, answered first. "It is a toaster," he said. The king asked, "How would you design an embedded computer for it?" The engineer replied, "Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantizes its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I'll show you a working prototype."
The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don't look to the future, we will have to completely redesign the toaster in just a few years."
"With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork, and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes, and waffles; pork divided into sausage, links, and bacon; and poultry divided into scrambled eggs, hard- boiled eggs, poached eggs, fried eggs, and various omelet classes."
"The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy, and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself.' The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs."
"Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don't want the eggs to get cold while the bacon is frying, so concurrent processing is required, too."
"We must not forget the user interface. The lever that lowers the food lacks versatility, and the darkness knob is confusing. Users won't buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it, and the message 'Booting UNIX v.8.3' appears on the screen. (UNIX 8.3 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook."
"Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel 80386 with 8MB of memory, a 30MB hard disk, and a VGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap. (Imagine the difficulty we would have had if we had foolishly allowed a hardware-first design strategy to lock us into a four-bit microcontroller!)."
The king wisely had the computer scientist beheaded, and they all lived happily ever after.
I hope you have enjoyed this newsletter. All feedback, comments and contributions to future editions are very welcome (as are enquiries about contributions to, and sponsorship of, this newsletter).
Copyright 1996-2009, The Plant Maintenance Resource Center . All Rights Reserved.