Your Reliability Engineering Professional Development Site
A listing in reverse chronological order of articles by:
I can’t believe it! They took it to the next level, They hired a sniper, and he was good, he got a kill shot with one round.
I’m in the hull of my boat doing what should be the easiest “Spring prep before launch” I have ever done. I got everything set up a week earlier to make this ritual of “man vs machine” as easy as possible. I even took care of the squirrel problem from the previous year. [Read more…]
When it comes to product development, most technology companies understand the importance of reliability. In particular, the engineering teams usually have everything they need to design a reliable product, including the right testing tools and analysis methods.
At times, though, there can be problems. A product doesn’t ship on time. Or if it ships on time, it fails in the field.
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? [Read more…]
“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…]
The “Optimize Your Launch” series is a set of interviews with industry experts to help companies bring their products to market quickly, maintain quality, and create loyal satisfied customers. [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…]
