Your Reliability Engineering Professional Development Site
A listing in reverse chronological order of articles by:
Well, it’s time for another exploration in Use Case 7. Unfamiliar with UC7? It’s simply when customers do unexpected things to our products. We often ignore it, but in fact, it is one of our best ways to learn about our product’s reliability. [Read more…]
This is a direct followup to my post last week.
I usually don’t do two part posts but….
I got some great responses to my post last week. I then got this image from my buddies at NASA (on the ground, not on the space station). One is actually my roommate from college. His hair is much shorter now.
Sometimes I see images that speak strongly to how reliability engineering affects us everyday. Think of how many items you own or use systems that you wouldn’t touch/interact with if you couldn’t be absolutely sure they would work as expected. I wouldn’t use my microwave if I thought there was a 1/1000 chance it would catch fire. The amount of faith I have in traffic lights working correctly is astounding. If they malfunction it could be fatal.
I found, while working at HP as a reliability engineer, that most managers of new products had little to no understanding of reliability concepts. They usually had the basic concept that reliability engineers should be brought into the project as the design was being finalized but had no clue what they would work on. [Read more…]
The clock in my ’79 Porsche 911 works perfectly. I don’t remember the last time I set it. Maybe I made a small adjustment six months ago, a year ago, don’t know? A modern day quartz clock does this no problem, a mechanical spring clock might struggle in such a rough environment. So was it quartz or mechanical? the ’70s was when quartz came on the scene, so either was a possibility. First I wanted to find out if it was ever replaced or serviced. So what did I do? I contacted the previous two owners. One purchased it new in ’79 and the other owned it for a five year period before I bought it. Neither recalls it ever being serviced or having a problem.
This is our fifth article about the 3 ways to do reliability allocation. We have been taken on a journey through the reliability design cycle, key steps for reliability allocation, allocation factors used to get these goals and key pitfalls. Now we finish off our conversation by looking at a few variations and applications. Allocating MTBF (… though we recommend against it), allocating availability, allocating maintainability (… another thing we recommend against) and allocating for different system reliability goals.
If you want to finish off your understanding of reliability allocation – read this!
This is our fourth article about the 3 ways to do reliability allocation. The first three articles describe the reliability design cycle and how reliability allocation is a part of this cycle. Our last article focused on what options you, as a design team leader, have at your disposal when you realize that your components aren’t on track to meet their allocated goals (or doing something!) Now we talk about working out what these allocated goals are. And how to get them. And don’t worry – it is much easier than you probably think!
If you want to learn more about a straightforward approach to reliability allocation – read this!
This is our third article about the 3 ways to do reliability allocation. In the first article, we set the scene. We talked about the reliability design cycle that needs to be implemented to make sure what we do will actually work. Will actually matter. In the second article, we cover the six steps of reliability allocation. In this article, we go through the six steps of reliability allocation.
You should have already read these articles – and if you haven’t please do! Once we have our reliability design cycle up and running, there are six key steps to making reliability allocation happen. And this article is about the sixth step – doing something!
If you want to learn more about a straightforward approach to reliability allocation – read this!
This is our second article about the 3 ways to do reliability allocation. In the first article, we set the scene. We talked about the reliability design cycle that needs to be implemented to make sure what we do will actually work. Will actually matter. In this article, we go through the six steps of reliability allocation. You need to do the preparation work first. But … we are all about keeping it simple. Making it exhaustive and complicated means you are wasting your time.
If you want to learn more about a straightforward approach to reliability allocation – read this!
If we have even a moderately complex product, we often need to break up our design team into smaller groups. Perhaps electronic, mechanical and hydraulic teams. Perhaps teams for specific functional components. And these teams need to work at least partially independently. So what do we do if we have a system reliability goal? What goals do we pass on to our smaller teams? This is where reliability allocation comes into play. Reliability allocation is often portrayed as a very complex, very involved and extremely exhaustive process. It should never be! In fact – the more exhaustive you make, the less likely it is to work.
If you want to learn more about a straightforward approach to reliability allocation – read this!
I have a customer that has developed an impressive wrist worn biometric sensor for athletes. The system is worn on the athletes wrist, like many other personal devices. But this product is for serious athletes that aren’t just looking for non-descript data like step count and heart rate. What are you even supposed to do with that information?
“What’s the MTBF of a Human?” That’s a bit of a strange question?
I ask this question in my Reliability 101 course. Why ask such a weird question? I’ll tell you why. Because MTBF is the worst, most confusing, crappy metric used in the reliability discipline. Ok maybe that is a smidge harsh, it does have good intentions. But the amount of damage that has been done by the misunderstanding it has caused is horrendous.
MTBF stands for “Mean Time Between Failure.” It is the inverse of failure rate. An MTBF of 100,000 hrs/failure is a failure rate of 1/100,000 fails/hr = .00001 fails/hr. Those are numbers, what does that look like in operation? [Read more…]
Yesterday had the chance to review the long list of Design for X topics. Assembly, environment, maintainability, and of course reliability, plus about a dozen other areas of focus. How is a design team to navigate all these different sets of constraints and objectives along with crafting a solution that works?
With a little creativity, you could relate every Design for X topic to reliability. Easier to assembly, fewer assembly errors leading to field failures, for example.
Another way to think about the Design for X space is to consider a superset instead. What are all these design considerations really about? What is common, including the design for reliability topic? With a little thought, it seems clear to me that we all are really considering how to identify and manage risk. [Read more…]
My first system project was a new TV design by HP. My first actions were to interview all project engineers and discuss their function in the program. I wanted to know what they were thinking and the approach they would use. From this interview process, I could start defining the Functional Architecture (Ref. REI book p 22-25) and start forming the reliability strategy. [Read more…]
“Speak with Data!” commanded my former general manager. “Let the Data Sing” is an article I wrote long ago. We all have data, often too much data. We like to present based on what the data says. Yet, sometimes the speaking with data is not clear.
If you’ve done the data gathering, the analysis, the summary, all based on the data, how can you best reveal what the data says to enhance your results and recommendations?
Just because you can add a 3D pie chart doesn’t mean you should. Crafting meaningful charts is only one part of the puzzle. You also have to present the data in a clear and meaningful manner. Here is a set of suggestions to consider the next time you are preparing and presenting when data is involved. [Read more…]