Your Reliability Engineering Professional Development Site
Bryan Bieschke and Howard Penrose – These two U.S. Navy vets join for an annual tradition to honor and celebrate Veteran’s day (11.11) – Maintenance Sea Stories III with plenty of stories, anecdotes, unknown U.S. Navy slang, and swearing!
Tune in to hear about skaters and shit bags, pencil whipping and FUBAR, and a ton of other shenanigans! Get out there and thank a veteran today, and on Veteran’s day, with a simple gesture like a coffee or s simple, “Thank you for your service!”
We talk about reliability because it matters. The ability to estimate reliability allows us to make design and development decisions. The ability to monitor reliability allows us to adjust the design, suppliers or expectations about a product. [Read more…]
Before you build anything, before you open CAD, before you request a quote, before you sketch on a whiteboard: can you name the specific question you’re trying to answer?
Dianna talks with Chad Schneider who runs a successful engineering shop where a cardboard box became a prototype and where killing their own project was considered a win.
His team doesn’t think of prototyping as a phase. They think of it as a discipline, one that starts with knowing what you don’t know.
This interview is part of our series, “A Chat with Cross Functional Experts”. Our focus is speaking with people that are typically part of a cross-functional team within engineering projects.
Chad Schneider is the CEO and founder of Root3 Labs, an engineering and device development company in Maryland. He’s a professional engineer with a background in mechanical engineering, haptics and medical robots. With over twenty-five years of experience across medical device and aerospace and defense, Chad and his team specialize in applied research, rapid prototyping, and design for manufacture. They help clients turn ideas into prototypes and prototypes into finished products. He’s named on sixteen patents and is a Goldman Sachs ten thousand Small Businesses alumnus.
They talk about why prototyping isn’t about building miniature versions of your final product. It’s about answering questions before they get expensive. We cover how Root3 Labs uses low-fidelity prototypes like cardboard mockups to test assumptions early, why Chad starts every project by separating needs from wants, how his team navigates the tension between what stakeholders ask for and what users actually need, and why killing a project can be the best outcome prototyping delivers.
[Read more…]
The math would be easier.
The exponential distribution would be the only time to failure distribution. We wouldn’t need Weibull or other complex multi-parameter models. Knowing the failure rate for an hour would be all we would need to know, over any time frame.
Sample size and test planning would be simpler. Just run the samples at hand long enough to accumulate enough hours to provide a reasonable estimate for the failure rate. [Read more…]
In this episode of Reliability 4.0, we speak with Kim Stalder, Asset Reliability Team Leader at Schreiber Foods, the largest privately-owned dairy company in the world!
It is deceptively easy to calculate MTBF given a count of failures and an estimate of operating hours. Just tally up the total hours the various systems operate and divide by the number of failures. Easy.
This simple calculation is the unbiased estimator for the inverse of the parameter lambda for the exponential distribution, or directly to estimate theta (MTBF). We use theta to represent 1 / lambda.
What could go wrong with such a simple calculation? [Read more…]
There is an old saying that includes something about two ears and one mouth. It suggests listening twice as much as speaking. Or, to listen more. We listen in one way or another, yet it’s not a skill taught specifically to engineers. Yet, it is a vital skill to have as a reliability engineer.
Let’s examine the different ways one can listen, when it’s useful, and how to become a much better listener. To do our job as reliability engineers, we need not only to hear what is expected of us, but also to fully understand requests, outcome criteria, priorities, and much more. Improving your ability to listen will accelerate your ability to add value with what you focus on and accomplish.
The acronym MTBF is commonly known in our field as “Mean Time Between Failures”.
It is also associated with repairable systems in most textbooks.
It is also denoted as the theta parameter for an exponential distribution.
It is also referenced as a metric for reliability. Oh, and it is the inverse of the failure rate.
And, it is misunderstood and misused by many. I digress, as there is plenty already written on the Perils of MTBF.
What is MTBF? And where and how should it be used, if at all? [Read more…]
Did you know I was interviewed for the Dare to Know podcast? The interview was fun, check it out here.
Note: this interview was some time ago (about 10 years back), near the start of the article series called NoMTBF. My thoughts haven’t changed very much. Plus, it seems this campaign is slowly working across our profession.
Learning the basics of reliability engineering is where we all start. Mastering the range of skills and techniques is a never-ending quest.
Improving, maintaining, and expanding your reliability engineering professional skills takes many forms. There are plenty of options and sources to support your education, yet are you getting enough of the right material? [Read more…]
How do you know? How would you know?
There is a lot to know concerning the technical aspects of reliability engineering. From calculating summary statistics to discovering the root cause of a failure, the body of knowledge you should master as a reliability professional is expansive. [Read more…]
Capacitors are likely the most common electronic component. They have many uses, many shapes, sizes, and constructions. Yet, just because they are common and rather inexpensive, they can fail. Sometimes a capacitor failure is completely unnoticed; other times it can be catastrophic.
Let’s explore common types of capacitors, MLCC and Electrolytic, their basic construction, and how they may fail. Understanding these components will assist you in designing for reliability and failure analysis activities.
We gather and report loads of data nearly every day.
Is your data “good data”? Or does it fall into the “bad data” category?
Let’s define the difference between good and bad data. Good data is accurate, timely, and useful. Bad data is not. It may be time to look at each set of data you are collecting or reviewing and judge if it’s good or not. Then set plans in motion to minimize the presence of bad data in your organization. [Read more…]
This one made me scratch my head and wonder. Did I read this right?
A reader sent me an excerpt of a document found on Vicor’s site.
“Reliability is quantified as MTBF (Mean Time Between Failures) for repairable product and MTTF (Mean Time To Failure) for non-repairable product. A correct understanding of MTBF is important. A power supply with an MTBF of 40,000 hours does not mean that the power supply should last for an average of 40,000 hours. According to the theory behind the statistics of confidence intervals, the statistical average becomes the true average as the number of samples increase. An MTBF of 40,000 hours, or 1 year for 1 module, becomes 40,000/2 for two modules and 40,000/4 for four modules…”
One of the issues I’ve had with failure modes and effects analysis is the focus on failure modes.
The symptoms that the customer or end user will experience are important. If a customer detects that the product has failed, that is a failure. The FMEA process does help us to identify and focus on the important elements of a design that improve the product reliability. That is all good.
The issue is that the FMEA process doesn’t go far enough to really aid the team in focusing on what action to take when addressing a failure mode. The process does include the discussion of the causes of the failure mode. The causes are often the team members’ educated opinions on what is likely to cause the failure mode. Often the description of a cause is a failed part, faulty code, or faulty assembly.
Generally, the discussion of causes is vague.
