Your Reliability Engineering Professional Development Site
A listing in reverse chronological order of articles by:
I often talk to engineers who have just been told that they are now a ‘reliability guy or girl’ for their organization. The CEO or perhaps a director decides that reliability is now important, so a group of poor unfortunates are hastily and collectively anointed as ‘the’ reliability program. Is this familiar?
Sometimes this works. Sometimes these rebranded ‘reliability guys and girls’ create amazing programs that [Read more…]
I recently held a lunch and learn about infographics. The recorded session is below. In our work as engineers, we often spend a great deal of time extracting amazing information from complex data sets only to find no clear way to get our message to those who need it which can include leadership, peers, or even the customer.
Changing how we present information can be the difference between driving change and simply being a slide in a weekly status meeting that solicits the response “next.”
Reliability engineering has an image problem. It is seen as an imbugerance that destroys budget, schedule and fun. People sometimes think reliability engineering is simply statistics, data analysis and other mind-numbing stuff. Reliability purgatory. Which brings us to the first reason you need to do reliability engineering.
#1 – Reliability engineering is not reliability purgatory. Reliability purgatory is all effort and no outcomes. Reliability happens at the point of decision. Design decisions. Manufacturing decisions. Maintenance decisions. True reliability engineering helps you make better decisions – which often comes down to organized judgment and not statistics.
Over the past week, I received a couple of interesting questions. One concerned assuming a Weibull beta value for an accelerated life test plan. The second involved assuming expected life models for elements within a reliability block diagram.
In both cases, we faced incomplete data and uncertainties, yet felt the need to assume some values in order for the math to work out. We do make assumptions in order to solve problems. We also can make mistakes that lead to unwanted consequences. [Read more…]
There are many scenarios that can arise throughout product development programs. There is one in particular that I have seen unfold more than once: I call it the “Plus one program.” Don’t let the name fool you; it’s horrible to watch unfold.
A startup or established player introduces an impressive jump in industry-standard technology, or sometimes an established player introduces an innovation to their industry. Since the technology is so innovative, there is great value in getting it to market quickly even if it isn’t a mature design. In this case, it is actually a smart move to go to market with a device that doesn’t have “ideal reliability.” In other words, the value of getting it out there quickly is worth the field issues. Those issues will be tolerated by the customer as well, if the technology is that good.
A recent student of mine was an engineer for a rail corporation. Let’s call her Liz. Liz kept asking me ‘what do I need to put in a contract’ to make sure my suppliers take reliability seriously? She kept asking this over, and over, until I got the penny to drop. Liz eventually realized that she was the one who had to take it seriously. [Read more…]
One of the enjoyable parts of reliability engineering work is the consistent need to learn. We learn how new materials, designs, applications, and systems work, and fail. Sometimes we learn through proactive characterization studies, sometimes via unwanted field failures.
Failures will occur, it is what we learn from them that matters. The ability to gather and remember the lessons learned is a common and ongoing need for every organization. We are not very good at it, in general. [Read more…]
Uncertainty is another word for risk. Reliability uncertainty or risk is neither good nor bad, it just a bit unknown. Until we know the outcome, the eventual reliability performance, we will not know the impact.
So, how do we deal with reliability uncertainty? Will our product or system work as expected over time, or will it fail? Let’s examine a few of the common approaches in use and when and why the approach is effective. [Read more…]
Remember how we were told as kids in school that we had to study hard to get into college or university? There was that ongoing, implied threat that not getting into university or college would ruin our career. Or at least, be very bad.
It turns out it may not be that bad after all. For example, over half of Apple’s employees don’t have 4-year degrees. Why? [Read more…]
The fist part of this post you likely already know. It’s the second part that may be helpful.
I love HALT testing and almost always include it in a new program. With a team new to the concept there is always the hurdle of getting them to understand it’s value. It’s not intuitive to see value in destroying a product with stepped stresses. Often these stresses aren’t even apart of the product’s use case. Why vibrate a lab electronic device that spends its entire life on a bench? Seeing the failure mode is a capacitor flying off the PCB at 50 G’s doesn’t reinforce the value of the activity without some explanation.
Every organization needs to be able to explain ‘why’ it is here. In fact, an organization’s ‘why’ is . Check out Simon Sinek. One of his favourite phrases is that ‘people don’t buy what you do – they buy why you do it.’
People buy Apple products because of they enjoy how they interface with devices that are part of a bigger and seamless ecosystem. All their competitors try to emulate this. Amazon is all about customer experience. [Read more…]
How is it that some people continue to get better at managing meetings, designing complex test plans, making presentations, or solving problems? How in general do people improve their performance over time at something? [Read more…]
A helpful analogy in communicating the concept of statistical reliability confidence is the “new airplane” example. Let’s say I am developing an entirely new technology for airplanes. The airplane has an engine that has never been used before for air travel; a fusion engine. I tell the world that this new airplane with a fusion engine will have a reliability of 99.99999999%, the highest any airplane has ever had. It’s not possible to fully demonstrate this reliability until every single unit of this airplane has been produced, used to full life, and the full fleet is retired. As long as one is still flying it can add or subtract from the reported reliability number. So, how do we make decisions at product launch regarding the design’s reliability? No products have yet to be produced or used by customers, so how can we trust the design?
Some time ago when talking with someone I just met, the conversation turned to what we did for a living. I mentioned being a reliability engineer, and his response: “Oh, yes, we do reliability”. Curious, as I’m not sure that I ‘do reliability’, we then talked about what he meant.
The conversation revealed that they had a list of tasks that they accomplished for each product under development. They did tests and reviews of the results. A lot of testing. They did FMEA and HALT. He believed the engineers did derating or stress/strength calculation. He didn’t know about process stability with vendors or internal manufacturing lines.
They did stuff, which meant they did reliability.
Anyone who knows me knows that I tend to only think in terms of cars. I can remember the car someone pulled up in at a party four years ago, but will have no recollection of what their name was. Moreso, I view culture, politics and economics through a sort of automotive anthropologist lens. For example, darker colors are more popular in luxury car sales when an economic downturn has occurred and major shifts in industrial focus will be reflected in increased offerings of economy cars that can hold 4 to 5 people. I think you can see what the problem is here.
In any case, I came up with a cooking analogy (in no way automotive related) for a principal of data organization and I have to say, it’s actually pretty good! So, I am documenting it here.
[Read more…]