Your Reliability Engineering Professional Development Site
A listing in reverse chronological order of articles by:
What happens when you power up an electronics device with clocked circuits?
Well you have a clock running and you have clocked circuit elements, also known as sequential circuits. Latches, registers, basically any “memory” element. What could interfere with testing?
Do you know the state of that “memory element” when you start?
Heck No!
That’s a problem. [Read more…]
Working with product engineers to develop a reliability test early in a program can be a satisfying experience. My interactions with the product engineers are the most fruitful when there is mutual respect. I ask the product engineer questions about his goals, the product features, the supplier, and rely on his product expertise. I like to examine prototype parts and review an engineering drawing or the circuit diagrams.
A good example was when a product engineer, let’s call him Jim, approached me to develop a safety switch reliability test.
Do you consider yourself an FMEA beginner or are you more experienced? Challenge yourself with these problems, and see how you do. One of the best ways to learn is by pondering actual application problems and seeing if you can solve them.
The concept of robust design is commonly discussed, but what exactly is it? What options are available for achieving robust design? How do you know if it could be appropriate for your new product or process application?
This overview helps answer those questions – contact Perrys Solutions for more specific assistance. [Read more…]
Have you ever wondered what are the key ingredients for successful FMEA application in a company? Why are some FMEAs successsful, and others are not? What are the most important factors for uniformly achieving great results? Based on supervising or performing over two thousand FMEAs, six FMEA success factors have been identified, and they are covered in this article.
Nothing succeeds like success.
Alexandre Dumas
When I introduced you to the Stuck at Fault Model I stated that the size of VLSI devices necessitated the usage of Electronic Design Automation (EDA) tools to support testing.
My first full-time job at IBM exposed me to the world of test and to their EDA tools.
In the mid-1980’s, testing of logic devices relied upon the S@ fault model. Three common software tools included fault simulation, automatic test pattern generation, and fault diagnosis.
This article will provide an introduction to fault simulation as one can view the other two tools as applications built upon a fault simulator. [Read more…]
Automobile companies pay dealers to perform vehicle prep and make warranty repairs on customer vehicles. A lot of data is collected thus warranty is considered big data.
Generally, vehicle warranty covers 3 years or 36,000 miles. When a vehicle is serviced, the customer, vehicle, repair, and text data are collected. Claims are entered into a transaction database, may be rejected for a number of reasons, and then resubmitted until resolved. The transaction database covers many model years, millions of vehicles, and a number of warranty claims for each vehicle. As a rough estimate, assuming 10 years, 2 million vehicles/year, and 2 claims for each vehicle, yields 40 million records. The actual number is higher due to the submission, rejections, and resubmission cycle.
There is much talk about data based decision making, but I think that misses the point. We make decisions based on knowledge. Data needs to be translated into that knowledge, and yet not all knowledge can be measured. This has been my training philosophy for a number of years now and has been quite effective. [Read more…]
What did American inventor and businessman Charles Kettering mean when he said, “A problem well stated is a problem half-solved”? Framing the problem and pondering solutions can be enlightening, and a great way to learn. This article will pose three problems and offer solutions, as a way to learn by doing.
“I hear and I forget. I see and I remember. I do and I understand.”
Confucius
Nothing can undermine FMEA results more than approaching the subject from the wrong philosophy. In this article readers will learn how use key focus areas to achieve effective FMEAs in all applications.
“In matters of style, swim with the current; in matters of principle, stand like a rock.”
Thomas Jefferson
Should an FMEA result in design or manufacturing improvements? Should it ensure that tests discover the right problems? What are the objectives of FMEAs? Whether you are new to FMEA or an experienced practitioner, there is always something to learn. This is the first in a series of articles on FMEA that should expand the knowledge of every reader.
“Successful engineering is all about understanding how things break or fail.” ~ Henry Petroski
Do you consider yourself new to FMEA, or are you an FMEA expert?
Or somewhere in between?
I’m a great believer that knowledge of any tool such as FMEA, is a lifelong journey. In the new series of articles called Inside FMEA, my intention is to bring to life the subject of FMEA, and provide value to readers from all levels of experience.
Each week I will publish a new article on Accendo. The topics will span the full range of FMEA applications, and offer guidance to real-world challenges that FMEA teams face each and every day. [Read more…]
In the previous article you learned to apply the Stuck at Fault Model (S@) to a small combinational circuit.
You can take the learning on the Full 1-bit adder and apply it to larger combinational circuit.
In testing lingo, you often hear people refer to this as the testing of random logic. Technically, there’s nothing random about the logic.
I think “random” gets used to contrast with the highly structured design of memory circuits into array of 1-bit cells. Memory test lends itself to algorithmic testing, for example the Marching 1. In random logic testing you may use algorithms to propagate your faults, that is automatically develop a test pattern.
You need to keep in mind that the logic being tested has a functional purpose and this can be implemented in a multitude of ways. Let’s take a second look at the adder function. [Read more…]
To work our ways towards understanding Design For Test (DFT)applications I am taking you back to the Stuck at Fault model (S@).
In the article which introduced you to the S@ model you learned the S@ model at the logic gate level.
Let’s build on this by applying it to combinational logic circuits.
Combinational logic has no clocked circuitry; sequential logic has clocked circuitry. In a few articles you’ll learn about test and sequential logic circuitry. [Read more…]
After the sponsorship and training are in place and resourcing is defined, there is still no guarantee that any investigations will get done. (See the end of the article for links to the blogs about these needs) This is where the definition of insanity applies – “doing the same thing over and over – and expecting different results” – so something must change. If there is no reason to perform an investigation, then things will continue to happen as they always have. [Read more…]