Category Archives: Engineering

Teaching Reliability is Part of Your Role

Teaching Reliability is Part of Your Role

Nearly everyone I’ve ever met doesn’t like their toaster to fail.

It will, and that is a bummer, as the quick and easy way to warm up the morning toast will be thwarted.

Failures happen. As reliability engineers, we know that failures happen. Helping others to identify potential failures, to avoid failures or to minimize failures is what we do best.

It is out ability to teach others about reliability engineering that allows us to be successful. Continue reading Teaching Reliability is Part of Your Role

Math, Statistics, and Engineering

14586673050_b71972cc74_m_dMath, Statistics, and Engineering

In college, Mechanics was a required class from the civil engineering department. This included differential equation.

Luckily for me, I also enjoyed a required course called analytical mechanics for my physics degree. This included using Lagrange and Hamiltonian equations to derived a wide range of formulas to solve mechanisms problems.

In the civil engineering course, the professor did the derivation as the course lectures, then expected us to use the right formula to solve a problem. He even gave us a ‘cheat sheet’ with an assortment of derived equations. We just had to identify which equation to use for a particular problem and ‘plug-and-chug’ or just work out the math. It was boring. Continue reading Math, Statistics, and Engineering

When Do Failures Count?

14586657179_3359d879f8_m_dWhen Do Failures Count?

One technique to calculate a product’s MTBF is to count the number of failures and divide into the tally of operating time.

You already know, kind reader, that using MTBF has its own perils, yet it is done. We do not have to look very far to see someone estimating or calculating MTBF, as if it was a useful representation of reliability… alas, I digress.

Counting failures would appear to be an easy task. It apparently is not. Continue reading When Do Failures Count?

The Relationship Between Reliability Goals and Confidence

14803836443_5a40e52835_oReliability Goal and Confidence

We establish reliability goals and measure reliability performance.

They are not the same thing. Goals and measures, while related, are not the same nor serve the same purpose. Continue reading The Relationship Between Reliability Goals and Confidence

Bought a House Due to Pokemon Go

Reliability and Pokemon GoWalking, Playing and Bought a House

Seriously, while out walking, listening to a podcast, and playing Pokemon Go, found an open house to view. A week later our offer was accepted and next week we close.

I  would not have been out walking that Sunday afternoon if not out playing Pokemon Go.

Glad there are no dangerous cliffs nearby. Continue reading Bought a House Due to Pokemon Go

3 Ways to Improve your Reliability Program

The reliability performance of equipment is a reflection of your reliability programA Few Simple Ideas to Improve Your Reliability Program

Spending too much on reliability and not getting the results you expect? Just getting started and not sure where to focus your reliability  program? Or, just looking for ways to improve your program?

There is not one way to build an effective reliability program. The variations in industries, expectations, technology, and the many constraints, shape each program. Here are three suggestions you can apply to any program at any time. These are not quick fix solutions, nor will you see immediate results, yet each will significantly improve your reliability program and help you achieve the results you and your customers expect. Continue reading 3 Ways to Improve your Reliability Program

What is Reliability?

14784844872_7b7908dd94_zGuest Post by Martin Shaw

In today’s complex product environment becoming more and more electronic, do the designers and manufacturers really understand what IS Reliability ??

It is NOT simply following standards to test in RD to focus only on Design Robustness as there is too much risk in prediction confidence, it only deals with the ‘intrinsic’ failure period and rarely has sufficient Test Strength to stimulate failures. Continue reading What is Reliability?

Failure Happens – It Is What Happens Next That Matters

When a failure happens with our equipment our measured response mattersFailure Happens – It Is What Happens Next That Matters

One of the benefits of reliability engineering is failure happens.

Nothing made, manufactured, or assembled will not fail at some point. It is our desire to have items last long enough that keeps us working. Since failures happen, our work includes dealing with the failure.

Not My Fault

Years ago while preparing samples for life testing at my bench, I heard an ‘eep’ or a startled sound from a fellow engineer. It was quickly followed by an electrical pop noise and a plum of smoke.

Something on the circuit board she was exploring had failed. With a pop and smoke. She didn’t move.

At this point, my initial amused response turned to concern for her safety. She was fine, just startled as the failure was unexpected. She quickly claimed it wasn’t her fault.

It was her design, she selected and assembled the parts, and she was testing the circuit. Yet, it wasn’t her fault. She did not expect a failure to occur (a blown capacitor – which we later discovered was exposed to far too much voltage), thus it was not her fault.

We hear similar responses from suppliers of components. It must have been something in your design or environment that caused the failure, as the failure described shouldn’t happen. It’s not expected.

Well, guess what, it did happen. Now let’s sort out what happened and not immediate assign blame for who’s fault it is.

The ‘not my fault’ response so a failure is not helpful. Failures are sometimes the result of a simple error and quickly remedied. Other are complex and difficult to unravel. The quicker we focus on solving the mystery of the cause of the failure, the quicker we can move on to making improvements.

Warranty

With possibly too many ‘not my fault’ responses, laws now enjoin the manufacture of products to stand behind their product. If a failure occurs, sometimes within specific conditions, the customer may ask for a remedy from the supplier.

If failures did not happen there would be no such thing as a warranty.

A warranty is actually a legal obligation, yet has turned into a marketing tool. A long warranty implies the product is reliable and by offering a long warranty the manufacturer is stating they are shifting the risk of failure to themselves.

A repair or replacement is generally not adequate recompense for a failure, yet it provides some restitution. In most cases, it only provides peace of mind, if the item doesn’t fail.

The warranty business has become an industry in of itself. Selling, servicing, and honoring warranties is something that others can deal with outside your organization. The downside is the lack of feedback about failure details so you can affect improvements. A manufacturer shouldn’t hide behind their warranty policy, nor ignore the warranty claim details. It is one-way a customer can voice their expectations concerning product reliability. You should listen.

Repair services

My favorite outsourced repair service story involved a misguided payment structure.

If you pay a repairman based on the value of the components replaced, they will likely always replace the most expensive components. If the repair is accomplished by resetting a loose connector, nothing is replaced, and the repairman is not compensated for the diagnostic work and effective repair. If he instead immediately replaced the main circuit board, and in the process reseating most of the connectors, the repair is fast, effective, and he is handsomely rewarded.

See the problem?

When a failure occurs, it may be natural to offer a repair service as the remedy. It should be quick (not a two-week wait as with my local cable company to restoring a fallen line), and efficient for all parties involved. For the owner of the equipment, we want the functionality restored as quickly as possible and cost effectively as possible. For the manufacture of the equipment, we want cost effectiveness, plus the knowledge concerning the failure.

Does your repair service provide for the needs of both parties as well as the repair technician?

Fail safe

Sometimes when a failure occurs nothing happens. We might not even notice the failure occurs. Other times the product simply goes ‘cold’ or a function is lost. Nothing adverse, no pop or smoke, occurs.

We call this failing safe. It’s more complicated than my simple explanation, yet it is the desired repose to a failure. The product itself should not create more damage, cause harm, place someone in peril. It should fail safely and preferably quietly.

If the ignition falls from the ignition switch, which may be considered a failure to retain the key within the switch, the driver should not lose control of the vehicle. This is in part a safety feature, yet is also a common expectation that the failure of a system should not create other problems.

Failure containment is related.

How does your product fail? Safely?

Maintenance

For some failures, such as the degradation of lubricants, we perform maintenance. When the brake pads or tire tread wears to marginally safe level we replace the brake pad or tire. If we can anticipate the failure pattern we perform preventive maintenance.

Creating a maintainable piece of equipment is one response to failures. It allows creating complex equipment with failure prone elements. Through maintenance, we are able to restore the system to operation or avoid unexpected downtime. If failures didn’t occur, we wouldn’t need maintenance.

We have some control over the nature of the maintenance activities. For some types of failures, we can only execute corrective maintenance. For others, we can use preventative methods. The idea is to anticipate and avoid the widest range of failures through effective maintenance practices, that remains cost effective.

Adding maintenance practices in response to system failures is not the duty of the owner of the equipment. It is a design function to anticipate the system failures that may occur and devise the appropriate maintenance plan to thwart unwanted failures from occurring. The two parties actually have to work together to make this work well.

Expectations

When I buy a product, I know that some proportion of products like the one I just purchased will failure prematurely. I just do not want or desire mine to fail. My expectation is the one I select at the store is a good one. It won’t let me down, stranded, or injured. That is my expectation.

When a failure does occur and I value the functionality the product provides I will want to restore the unit via repair or replacement, sometimes via a service contract or warranty or repair center. To a large degree, my expectation is after a failure all will go well.

As the manufacture of products, when a failure occurs, your expectations may include learning from the failure to make improvements. Or it should.

We know we cannot anticipant nor avoid every failure that may occur. The expectation on both sides is to make robust and dependable products that provide value for all involved. When that approach fails, we fail.

Failure Happens

In response to a failure, it’s how the product, customer, and manufacture responds that matters. A simple failure can turn into a disaster for all involved. Or the failure can provide insights leading to breakthrough innovations and new opportunities.

It’s how we respond that matters.

How do you respond to failures?

Are the Measures Failure Rate and Probability of Failure Different?

Old machinery enjoyed a failure rate, which one though?Are the Measures Failure Rate and Probability of Failure Different?

Failure rate and probability are similar. They are slightly different, too.

One of the problems with reliability engineering is so many terms and concepts are not commonly understood.

Reliability, for example, is commonly defined as dependable, trustworthy, as in you can count on him to bring the bagels. Whereas, reliability engineers define reliability as the probability of successful operation/function within in a specific environment over a defined duration.

The same for failure rate and probability of failure. We often have specific data-driven or business-related goals behind the terms. Others do not.
If we do not state over which time period either term applies, that is left to the imagination of the listener. Which is rarely good.

Failure Rate Definition

There at least two failure rates that we may encounter: the instantaneous failure rate and the average failure rate. The trouble starts when you ask for and are asked about an item’s failure rate. Which failure rate are you both talking about?

The instantaneous failure rate is also known as the hazard rate h(t)

\displaystyle h\left( t \right)=\frac{f\left( t \right)}{R\left( t \right)}

Where f(t) is the probability density function and R(t) is the relaibilit function with is one minus the cumulative distribution function. The hazard rate, failure rate, or instantaneous failure rate is the failures per unit time when the time interval is very small at some point in time, t. Thus, if a unit is operating for a year, this calculation would provide the chance of failure in the next instant of time.

This is not useful for the calculation of the number of failures over that year, only the chance of a failure in the next moment.

The probability density function provides the fraction failure over an interval of time. As with a count of failures per month, a histogram of the count of failure per month would roughly describe a PDF, or f(t). The curve described for each point in time traces the value of the individual points in time instantaneous failure rate.

Sometimes, we are interested in the average failure rate, AFR. Where the AFR over a time interval, t1 to t2, is found by integrating the instantaneous failure rate over the interval and divide by t2 – t1. When we set t1 to 0, we have

\displaystyle AFR\left( T \right)=\frac{H\left( T \right)}{T}=\frac{-\ln R\left( T \right)}{T}

Where H(T) is the integral of the hazard rate, h(t) from time zero to time T,
T is the time of interest which define a time period from zero to T,
And, R(T) is the reliability function or probability of successful operation from time zero to T.

A very common understanding of the rate of failure is the calculation of the count of failures over some time period divided by the number of hours of operation. This results in the fraction expected to fail on average per hour. I’m not sure which definition of failure rate above this fits, and yet find this is how most think of failure rate.

If we have 1,000 resistors that each operate for 1,000 hours, and then a failure occurs, we have 1 / (1,000 x 1,000 ) = 0.000001 failures per hour.

Let’s save the discussion about the many ways to report failure rates, AFR (two methods, at least), FIT, PPM/K, etc.

Probability of Failure Definition

I thought the definition of failure rate would be straightforward until I went looking for a definition. It is with trepidation that I start this section on the probability of failure definition.

To my surprise it is actually rather simple, the common definition both in common use and mathematically are the same. There are two equivalent ways to phrase the definition:

  1. The probability or chance that a unit drawn at random from the population will fail by time t.
  2. The proportion or fraction of all units in the population that fail by time t.

We can talk about individual items or all of them concerning the probability of failure. If we have a 1 in 100 chance of failure over a year, then that means we have about a 1% chance that the unit we’re using will fail before the end of the year. Or it means if we have 100 units placed into operation, we would expect one of them to fail by the end of the year.

The probability of failure for a segment of time is defined by the cumulative distribution function or CDF.

When to Use Failure Rate or Probability of Failure

This depends on the situation. Are you talking about the chance to failure in the next instant or the chance of failing over a time interval? Use failure rate for the former, and probability of failure for the latter.

In either case, be clear with your audience which definition (and assumptions) you are using. If you know of other failure rate or probability of failure definition, or if you know of a great way to keep all these definitions clearly sorted, please leave a comment below.

Basic Outline to Craft Your Professional Development Plan

14783620362_60646695a1_zGetting Enough of the Right Professional Development

Learning the basics of reliability engineering is where we all start. Mastering the range of skills and techniques is a never ending quest.

Improving, maintaining, expanding your reliability engineering professional skills takes many forms. There are plenty of options and sources to support your education, yet are do getting enough of the right material?  Continue reading Basic Outline to Craft Your Professional Development Plan

Are Your Reliability Engineering Technical Skills Good Enough?

14782026181_49d0000e8d_oAre Your Reliability Engineering Technical Skills Good Enough?

How do you know? How would you know?

There is a lot to know concerning the technical aspects of reliability engineering. From calculating summary statistics to discovering the root cause of a failure, the body of knowledge you should master as a reliability personal is expansive. Continue reading Are Your Reliability Engineering Technical Skills Good Enough?

Lifetime Evaluation vs Measurement Part 3

14782008631_1af1c79419_oLifetime Evaluation vs. Measurement. Part 3.

Sometimes shifting your perspective
is more powerful than being smart.

—Astro Teller

Guest post by Oleg Ivanov

A common approach for “no failure” testing is the use of the well-known expression

\displaystyle (1) \quad 1-CL={{R}^{n}}

where CL is a confidence level, R is a required reliability, n is a sample size. Its parent is a Binomial distribution with zero failures. This expression is like a poor girl: Continue reading Lifetime Evaluation vs Measurement Part 3

How to Avoid Delivering Bad Data

14781654934_58be162f3b_zHow to Avoid Delivering Bad Data

We gather and report loads of data nearly every day.

Is your data “good data”? Or does it fall into the “bad data” category?

Let’s define the difference between good and bad data. Good data is accurate, timely, and useful. Bad data is not. It may be time to look at each set of data you are collecting or reviewing and judge if it’s good or not. Then set plans in motion to minimize the presence of bad data in your organization.

Good data is accurate

By this I mean it truly reprints the items or process being measured.

If the mass is 2.3 kilograms, then the measurement should be pretty close to 2.3 kg. This is a basic assumption we make when reviewing measurements, yet when was the last time you checked? Use a different measurement method, possible a known accurate method to check.

Measurement system analysis includes a few steps to determine if the gage making a measurement is true or not. Calibration may come to mind, as it is a step to verify the gage readings are reflecting standard measures. A meter is a meter is a meter across the many ways we can measure distance.

It also includes checking the common sources of measurement error:

  • Repeatability
  • Reproducibility
  • Bias
  • Linearity
  • Stability

You may also want to understand the resolution or discrimination of the measurement process.

If these terms and how one goes about checking for accuracy, it may be time to learn a little about MSA.

Good data is timely

If the experiment results are available a week after the decision to launch the product, it will not be considered in the decision. It is not useful for the decision concerning product launch. If the data was available it may alter the decision. Late, we will not know.

Timely means it is in time for someone or some team to make a decision. Ideally, the data is available immediately. When a product fails in the field, we would like to know right away, not two or three month later. If a production line becomes unstable, knowing before another unit of scrap is produced would be timely.

Not all data gathering and reporting is immediate. Some data takes months or an entire year to gather. There are physical constraints in some situation that day the gathering of data. For example is takes on average 13 minutes, 48 seconds, for radio signals to travel from a space probe orbiting Mars to reach Earth [1]. If you are making important measurements on Earth it should be a shorter delay.

The key point here, is the data should be available when it is needed to make decisions.

Good data is useful

Even if the data is accurate and timely is may not be useful. The data could be from a perfect measurement process, yet is measuring something we do not need to know or consider. The data gathered does not help inform us concerning the decision at hand.

For example, if I’m perfectly measuring production throughput, it does not help me understand the causes of the product line downtime. While related to some degrees, instead of the tally of units produced per hour, what we really would find useful is data concerning the number of interruptions to production, plus details on the root cause of each.

Setting up and maintaining the important measurements is difficult as we often shift focus based on the current data. We spot a trend and want to learn more than the current data can provide. The idea is we should not setup and only use a fixed set of data collection processes. Ideally your work to gather data is driven by the need to answer questions.

  • Is the maintenance process improving the equipment operation?
  • Is our manufacturing process stable and capable of creating our product?
  • Will the current product design meet life expectations/requirements?
  • Have we confirmed the new design ‘fixed’ the faults seen in the last prototype?

We have questions and we gather data to allow us to answer questions.

How would you describe the data you will look at today? Good or Bad? And more importantly, do you know if your data is good or bad?

Time delay between Mars and Earth, Thomas Ormhston, posted 5/8/2012,  European Space Agency, Mars Express Blog, http://blogs.esa.int/mex/2012/08/05/time-delay-between-mars-and-earth/ accessed 4/29/2016

Lifetime Evaluation vs. Measurement. Part 2.

Lifetime Evaluation vs. Measurement. Part 2.

Guest post by Oleg Ivanov

A result of life testing can be measurement or evaluation of the lifetime.

Measurement of the lifetime requires a lot of testing to failure. The results provide us with the life (time-to-failure) distribution of the product itself. It is long and expensive.

Evaluation of the lifetime does not require as many test samples and these tests can be without failures. It is faster and cheaper [1]. A drawback of the evaluation is that it does not give us the lifetime distribution. The evaluation checks the lower bound of reliability only, and interpretation of the results depends on the method of evaluation (the number of samples, test conditions, and the test time). Continue reading Lifetime Evaluation vs. Measurement. Part 2.

Does Your FMEA Study Go Far Enough?

14781622934_acabe9f466_zExtend Your FMEA Process with Mechanisms

One of the issues I’ve had with failure modes and effects analysis is the focus on failure modes.

The symptoms that the customer or end user will experience are important. If a customer detects that product has failed, that is a failure. The FMEA process does help us to identify and focus on the important elements of a design that improve the product reliability. That is all good.

The issue is the FMEA process doesn’t go far enough to really aide the team focus on what action to take when addressing a failure mode. The process does include the discussion of causes of the failure mode. The causes are often the team members educated opinions on what is likely to cause the failure mode. Often the description of the a cause is a failed part, faulty code, or faulty assembly.

Generally the discussion of causes is vague.

Failure Mechanisms versus Failure Modes

Failures modes are best described as what the customer experiences (no power, loss of function, etc.). Failure mechanisms are the root physical or chemical anomaly that leads to the existence of the failure mode. While we want to remove failure modes, we have to solve, remove, or mitigate failure mechanisms along the way.

The traditional FMEA process in my experience often provides vague classes of causes, hints at potential failure mechanisms, or avoids specifying mechanisms entirely. The actions items from the FMEA study then include investigations to find and understand the actual failure mechanisms (at best) or attempt to address vague classes of mechanisms with broad sweeps of monitoring, testing, or design changes.

Instead focusing the discussion on causes of failures at the level of failure mechanisms, enhances the discussion. Instead of talking about the causes as a component failure, it changes to what happens such that the component fails. Instead a vague average failure rate, it becomes a discussion about design or process errors or variation that leads to the components demise.

The hard part of this approach is the sheer number of ways (root causes) that an item may fail. Consider a simple component solder joint. The potential root causes includes:

  • Contamination
  • Corrosion
  • Dendrite growth
  • Cracking
  • Shear fracture
  • Flex cracking
  • Pad lifting
  • Gold embrittlement

And many others potential issues. Even these brief descriptions may have underlying causes which are the elements requiring attention in order to solve.

Fault Tree Analysis (FTA) and FMEA

Detailing all possible root causes of each failure mode would be tedious and I would suggest unnecessary. One approach I’ve seen is the common approach to FMEA, where we explore the class or basic expected types of root causes that lead to the listed failure mode. Then for the lines in the FMEA study that percolate to the items requiring attention, we then conduct a detailed FTA that flushes out the range and relative frequency of occurrence of the many different underlying failure mechanisms that lead to a specific failure mode.

If the primary cause of a failure mode is a faulty component, then what are the specific mechanisms that lead to a component being faulty. FTA is the right tool here. Used on conjunction with the highest risks identified in the FMEA permit the team to understand and solve or mitigate the right elements in the design or process to make a difference. Being specific with actions that make a difference is the key.

With your work to identify and resolve risks to reliability performance, how do you insure the solutions are actually solving the right problem? What works for you in your organization? How do you extend your FMEA work into effective action?