Your Reliability Engineering Professional Development Site
All articles listed in reverse chronological order.
We know that there are no “quick fixes” or “silver bullet solutions” when it comes to improvements in maintenance management.
In my last article, I pointed out that many separate conditions and events must come together properly to achieve “schedule success” – i.e.: the high level of compliance to a schedule of planned work as produced by your planners.
That list of includes: [Read more…]
What you will learn from this article.
Fixing plant and equipment about which you know little is daunting.
Here are a few ideas to help you successfully fault find failed equipment. [Read more…]
Guest Post by James Kline (first posted on CERM ® RISK INSIGHTS – reposted here with permission)
On March 28, 1979, there was a cascading failure in reactor number 2 at Three Mile Island.
This failure allowed large amounts of nuclear reactor coolant to escape. The accident coalesced the anti-nuclear movement and ultimately caused the decline in nuclear plant construction in the United States. [Read more…]
As seen in the previous articles, you can easily use the data you already have to conduct a meaningful analysis. This includes Weibull, Crow-AMSAA or a Mean Cumulative Function analysis.
Digging into a well manage dataset promises to reveal insights, trends, and patterns that will help improve the line, process, or plant.
Creating a plot or calculating summaries is pretty easy with today’s tools. Yet, are you doing the right analysis or are the various assumptions valid?
One critical step in the data analysis process is making sure you are doing a valid and appropriate analysis. [Read more…]
I see many organizations that feel a great sense of victory when they solve a current issue that has been plaguing their product.
It may be a field issue that took a product that was performing flawlessly to a steeply increasing failure rate “out of nowhere”.
Customers are angry, management is angry, everyone is angry and afraid. It seems to go on forever and the end is unknown. Then just as suddenly as the issue arose, a solution is found that puts the universe back in order.
The team celebrates, goes back to the day to day tasks that keep the machine running and there is a sense of calm. But the unspoken nervousness of waiting for the next issue to pop up is there.
There is nothing to do but just wait. A new one will arise, maybe tomorrow, maybe in six months, maybe next year.
“But that is the way it is and there isn’t much that can be done about it”.
That is the mindset of a Mid-maturity reliability culture. A High-maturity reliability culture doesn’t have to just sit and wait for the next “gremlin strike”.
The reason is that not only do they know what caused the last issue, they also know why they currently aren’t having any issues. It is a subtle but big difference.
The High-maturity reliability culture has in place an ongoing program that studies the variabilities that can occur in their product manufacturing and usage. This program uses methods such as specialized testing and analysis that supports mitigations in design, manufacturing, and product usage.
Now the organization isn’t just not having issues, they know why they aren’t having issues!
But in reality, it’s just pitfalls we fall into because we simply aren’t willing to study the road up ahead.
5 Steps to Building a Reliability Culture (article)
Purpose of a Reliability Program (article)
How to Assess Your Reliability Program (article)
The definition of reliability includes four elements.
One of them is the intended environment where the device or system will experience a range of stresses.
The knowledge of where and how an item will operate enables:
A Petri net graph is a depiction of a system using a symbolic language.
The modeling permits the analysis of complex systems or networks of systems.
It is possible to include elements of the system that are neither function or failed. In other words, it permits modeling a system when one or more of the elements are in a degraded state or under repair.
Petri net modeling is useful when the repair/restore times are long compared to operating times, as reliability block diagrams and fault tree analysis approach assume short or insignificant repair times, in most cases. [Read more…]
Today’s world contains a myriad of choices for instant gratification.
Regardless of our age, we have grown used to getting what we want, when we want it, and how we want it limited only by our ability and willingness to pay for it. [Read more…]
Failure Happens – It Is What Happens Next That MattersOne of the benefits of reliability engineering is failure happens.
Nothing made, manufactured, or assembled will not fail at some point. It is our desire to have items last long enough that keeps us working. Since failures happen, our work includes dealing with the failure.
Years ago while preparing samples for life testing at my bench, I heard an ‘eep’ or a startled sound from a fellow engineer. It was quickly followed by an electrical pop noise and a plum of smoke.
Something on the circuit board she was exploring had failed. With a pop and smoke. She didn’t move.
At this point, my initial amused response turned to concern for her safety. She was fine, just startled as the failure was unexpected. She quickly claimed it wasn’t her fault.
It was her design, she selected and assembled the parts, and she was testing the circuit. Yet, it wasn’t her fault. She did not expect a failure to occur (a blown capacitor – which we later discovered was exposed to far too much voltage), thus it was not her fault.
We hear similar responses from suppliers of components. It must have been something in your design or environment that caused the failure, as the failure described shouldn’t happen. It’s not expected.
Well, guess what, it did happen. Now let’s sort out what happened and not immediate assign blame for who’s fault it is.
The ‘not my fault’ response so a failure is not helpful. Failures are sometimes the result of a simple error and quickly remedied. Other are complex and difficult to unravel. The quicker we focus on solving the mystery of the cause of the failure, the quicker we can move on to making improvements.
With possibly too many ‘not my fault’ responses, laws now enjoin the manufacture of products to stand behind their product. If a failure occurs, sometimes within specific conditions, the customer may ask for a remedy from the supplier.
If failures did not happen there would be no such thing as a warranty.
A warranty is actually a legal obligation, yet has turned into a marketing tool. A long warranty implies the product is reliable and by offering a long warranty the manufacturer is stating they are shifting the risk of failure to themselves.
A repair or replacement is generally not adequate recompense for a failure, yet it provides some restitution. In most cases, it only provides peace of mind, if the item doesn’t fail.
The warranty business has become an industry in of itself. Selling, servicing, and honoring warranties is something that others can deal with outside your organization. The downside is the lack of feedback about failure details so you can affect improvements. A manufacturer shouldn’t hide behind their warranty policy, nor ignore the warranty claim details. It is one-way a customer can voice their expectations concerning product reliability. You should listen.
My favorite outsourced repair service story involved a misguided payment structure.
If you pay a repairman based on the value of the components replaced, they will likely always replace the most expensive components. If the repair is accomplished by resetting a loose connector, nothing is replaced, and the repairman is not compensated for the diagnostic work and effective repair. If he instead immediately replaced the main circuit board, and in the process reseating most of the connectors, the repair is fast, effective, and he is handsomely rewarded.
See the problem?
When a failure occurs, it may be natural to offer a repair service as the remedy. It should be quick (not a two-week wait as with my local cable company to restoring a fallen line), and efficient for all parties involved. For the owner of the equipment, we want the functionality restored as quickly as possible and cost effectively as possible. For the manufacture of the equipment, we want cost effectiveness, plus the knowledge concerning the failure.
Does your repair service provide for the needs of both parties as well as the repair technician?
Sometimes when a failure occurs nothing happens. We might not even notice the failure occurs. Other times the product simply goes ‘cold’ or a function is lost. Nothing adverse, no pop or smoke, occurs.
We call this failing safe. It’s more complicated than my simple explanation, yet it is the desired repose to a failure. The product itself should not create more damage, cause harm, place someone in peril. It should fail safely and preferably quietly.
If the ignition falls from the ignition switch, which may be considered a failure to retain the key within the switch, the driver should not lose control of the vehicle. This is in part a safety feature, yet is also a common expectation that the failure of a system should not create other problems.
Failure containment is related.
How does your product fail? Safely?
For some failures, such as the degradation of lubricants, we perform maintenance. When the brake pads or tire tread wears to marginally safe level we replace the brake pad or tire. If we can anticipate the failure pattern we perform preventive maintenance.
Creating a maintainable piece of equipment is one response to failures. It allows creating complex equipment with failure prone elements. Through maintenance, we are able to restore the system to operation or avoid unexpected downtime. If failures didn’t occur, we wouldn’t need maintenance.
We have some control over the nature of the maintenance activities. For some types of failures, we can only execute corrective maintenance. For others, we can use preventative methods. The idea is to anticipate and avoid the widest range of failures through effective maintenance practices, that remains cost effective.
Adding maintenance practices in response to system failures is not the duty of the owner of the equipment. It is a design function to anticipate the system failures that may occur and devise the appropriate maintenance plan to thwart unwanted failures from occurring. The two parties actually have to work together to make this work well.
When I buy a product, I know that some proportion of products like the one I just purchased will failure prematurely. I just do not want or desire mine to fail. My expectation is the one I select at the store is a good one. It won’t let me down, stranded, or injured. That is my expectation.
When a failure does occur and I value the functionality the product provides I will want to restore the unit via repair or replacement, sometimes via a service contract or warranty or repair center. To a large degree, my expectation is after a failure all will go well.
As the manufacture of products, when a failure occurs, your expectations may include learning from the failure to make improvements. Or it should.
We know we cannot anticipant nor avoid every failure that may occur. The expectation on both sides is to make robust and dependable products that provide value for all involved. When that approach fails, we fail.
In response to a failure, it’s how the product, customer, and manufacture responds that matters. A simple failure can turn into a disaster for all involved. Or the failure can provide insights leading to breakthrough innovations and new opportunities.
It’s how we respond that matters.
How do you respond to failures?
In a recent post, I wrote about suppliers who claim to be committed to quality but may not actually behave that way.
Before getting too carried away with improving quality in the supply chain, it’s probably a good idea to understand your own company’s commitment to quality, although I see nothing wrong with holding your suppliers to a higher standard.
It may seem impressive when businesses highlight quality as a core value, something that’s published on their website and displayed on their walls, but is that just for show?
Some quality paradigms are expensive.
Quality is a mindset! When a wise man is given the chance to buy quality items he does so because quality pays for itself.
A quality item lasts longer, runs better and looks good when others fade. To change the way you think about quality takes a lot of experience with using poorer options. When you are sitting down with your head in your hands wondering what can be done to get costs down, to get production up and how you are going to hit the key performance indicators, remember the importance of quality equipment, quality systems, quality training and your quality mindset!
Keywords: quality control [Read more…]
Guest Post by John Ayers (first posted on CERM ® RISK INSIGHTS – reposted here with permission)
Reliability is designed into a product. Quality is built into a product. Poor reliability is long term, difficult and expensive to rectify because it is woven into the fabric of the product.
Quality is a relative short term problem because once the badly written procedure, non-compliant material or poor workmanship is identified, it usually can be fixed relatively quickly with minimal impact to the program. [Read more…]
A few years into your reliability journey, you start to struggle to make the improvements you were able to when you first started.
Why is this? You were able to systematically eliminate all of the low hanging fruit using the existing data in your CMMS. But now you have to dig deeper to realize the improvements and that requires better data. [Read more…]
Beyond the part reliability specification, you may also add conditions or requests to your reliability specification for your supplier.
The communication with your supplier should include sufficient information that they fully understand your reliability performance expectations. When buying or contracting with a supplier, you are the customer.
Be clear about your reliability requirements including constraints and conditions. [Read more…]
The best time is at the product conception. The second best time as early as possible in the product development process.
It may change. Be refined. Altered later.
That is fine, yet the initial concept needs the boundary condition of a reliability goal. [Read more…]