#468 – WHEN PAST RELIABILITY IS GOOD! – FRED SCHENKELBERG

Featured

Let’s say that you and your team have done well. Your products or systems are reliable. They work, customers are happy, and the cost of unreliability is low. That’s the goal, right? Congratulations are in order.

However, enjoying great reliability performance was the goal. It is what we expected. It’s what we worked to achieve. Now what? Continue reading

#467 – 2 DESIGN APPROACHES TO RELIABILITY – FRED SCHENKELBERG

Featured

There are two basic philosophies when creating a reliability plan for a new product or system.

One is to experiment with prototypes as quickly and often as possible, the build, test, fix, approach. Or, you can research and model detailed aspects of the materials and structures to characterize the strength of a product or system, the analytical approach. Continue reading

#466 – RELIABILITY AND CUSTOMER SERVICE – FRED SCHENKELBERG

Featured

As reliability professionals know, products fail. They fail for a wide range of reasons and over a broad span of time. We know it happens.

This doesn’t help when it impacts us directly though. When we purchase a product or service, it should just work. We know the odds, we know better, yet the sting of failure remains. Continue reading

#465 – 3 SUPPLY CHAIN CAUSED FAILURES – FRED SCHENKELBERG

Featured

Some days are better than others. We sometimes run into failure when working to create a new product. With a little investigation we suspect the components are not working as expected.
We’ll call the vendor and ask for an explanation. If this is normal production and variability of performance, our product will suffer an higher than expected failure rate. The vendor will assure us with: Continue reading

#464 – THE MEANING OF (PRODUCT) FAILURE – FRED SCHENKELBERG

Featured

Every failure provides information. It provides time to failure, stress strength relationship, process stability and design margin types of information. In every case. Even failures directly related to human error.

A hardware intermittent failure observed by a firmware engineer should not be dismissed. Rather recorded, explored and examined. Continue reading