Your Reliability Engineering Professional Development Site
A listing in reverse chronological order of articles by:
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…]
In the early years of inkjet printer development, our standard industry reliability testing plans used at HP were not capable of finding potential problems as the product matured. The following issues were found as printer technology continued to develop. [Read more…]
As we make things to be more and more reliable, it gets harder and harder to make them fail in reliability tests. On the one hand – that’s great. On the other hand – that sucks if we want to use testing to help measure reliability. So if we are focused on measuring reliability through testing, we need to make our product or system fail in test conditions (without making it less reliable) but make sure these test conditions can somehow be translated back to how customers are going to use it. This is where accelerated testing comes in. [Read more…]
I was assigned to a new project at HP as a reliability engineer was to develop a rear projection, large screen TV. As the project was being defined, I was informed that an Asian Original Equipment Manufacturer (OEM) would be developing and manufacturing the HW while HP developed the SW. HP would own the service center support of field issues. My role was to represent the customer and evaluate the reliability of the final product. [Read more…]