Course 1: Design for Problems and Risk

Hello and welcome to another lesson. This lesson is called building FMEAs for design decisions and we are on lesson six.

Lesson Objectives

Here's what we're going to be covering in this lesson.

• We're going to identify different types of FMEA s to use for a design and will also consider when FMEA s may not be necessary for us.
• We're also going to learn how to construct FMEA so that we can get the design input that we need from the activity.

So far, we've built a perspective of design as solving problems and controlling risk.

• We can prioritize design efforts,
• know what specific questions to ask our cross functional team and
• can work with them and have discussions to be able to come to a consensus on what's important for the design.
• We've done all of this within a concept phase without a prototype.

What we’ve done so far

If you recall in previous lessons in this course,

• We talked about tree diagrams, how they can map out a problem and its subsequent causes and different levels of causes.
• We also talked about the symptom problem and cause model and that we can break out the symptoms into its outcomes and impacts and we can evaluate the drivers for the outcome and the impact and our symptom problem cause model and put them into FMEAs for further analysis.
• We also wanted to expand our thinking of our product design into the greater system level and we introduced the Swiss Cheese Model of Accident Causation, looking at our layers of cheese as controls from bad things happening.

We don't want to lose that information as the project progresses through development. It's solid fact-based design work that was done in the early phases of development. It counts for a lot! We also don't want to just evaluate risk all the time, spending hours on documents and in meetings.

We want to do design engineering work. We want to continue to learn as much about our product as early as we can in development, take all we've learned about it so far and continue to iterate on it - use what we learn to continue to set priorities, compare features of our design and make decisions.

We're going to do that with the help of our risk analysis tools.

So, let's talk about the types of FMEAs and when to do each.

Different types of FMEAs

Just a reminder, when we introduced FMEA, we introduced four different FMEAs: a system, a use, a design, and process FMEA.

System FMEAs are used to analyze a product in a larger system, considering the environment and the human interfaces and other products. It considers the high-level product architecture.

The use FMEA focuses on the steps that a user takes to use the product.

Both the system and the use FMEA can be done at the concept phases, when our design is just an idea and we may have some large level ideas about functions of our new product.

Design and Process FMEA are a little different. We do need to consider more concrete ideas about what our components are going to be or how we're going to be manufacturing our product,.

Something I haven't introduced yet is the hazard analysis and we're going to get into what that is and why it's different from FMEA and what kind of benefits we can get from using a hazard analysis.

When to do FMEA

FMEAs don't have to be done in a one- or two-day huge meeting with a big cross functional team.

• It can be done iteratively throughout the design development project with our team.
• We do FMEAs when we want to make choices and evaluate different options, and
• we can also look at FMEAs as a framework that we can use to have discussions with our cross functional team.
• FMEA s should be useful, not a burden. If they're a burden, then we may be doing them wrong.

Choosing and using FMEA

Let's talk a little more about how we can effectively choose FMEAs and iterate on them throughout the design development process to make them useful analyses.

Let's continue our FMEA example scenario.

If you remember, we're working with bike stands. We have an existing bike stand and we're going to iterate to the next generation design. We started a system FMEA, and let's reintroduce the tree diagram with our scenario in it. Our customers can't assemble the bike stand because the customer cannot assemble the angle and the support and the customer can assemble those two parts because of several reasons parts are wrong, parts are damaged, there's missing parts or customer difficulty and we have further causes mapped out beyond that.

In the previous lessons we started building out a system FMEA and it followed the tree diagram like this:

• we have our customers can't assemble the bike stand and our problem is that they can't assemble the angle and the support
• we have different causes listed: the design failure, manufacturing process failure parts are damaged, missing parts and customer difficulty.

System FMEA

When we're doing the system FMEA, we can think about where we want to put our slice of cheese. What are the things that we want to control at the system level? We don't want damaged parts or missing parts to create a situation where the customer can't assemble the angle and the support. We also don't want design and manufacturing process failures or we don't want the customer having a difficult time assembling it for other reasons. These are the things that we want to control at the system level. Our symptom problem and cause model can line up pretty nicely under our system FMEA and, again, our system FMEA is considering the large picture: our product design, its interfaces, and then the environment that our product is going to be used in.

Use FMEA

Now we may want to do a UFMEA. If we want to get into more details about that customer difficulty bucket, we may want to expand the customer difficulty description by adding: they have difficulty fitting and bolting the angle and the support. Our causes are still confusing instructions to many parts and a lack of tools. Where would we want to put our slice of cheese in this scenario? That's right. We want to prevent confusing instructions to many parts and a lack of tools from creating the customer difficulty. With a UFMEA, we want to focus on the user's process or the use steps. Our product gives an output, our user perceives that, makes a decision about what to do about it, and takes action. And that, again, is input into our product. Their perception, decisions and actions are what we want to analyze in the use FMEA.

Breaking out our system level cause into, now, the problem of our use FMEA lets us get more specific with the use problem. We're still evaluating our product in the greater system.

Design FMEA

Now, when we get into DFMEA, this is when our focus is on individual parts components or subsystems. We can have different levels of design FMEA depending on what we want to learn. We're focused-in on design failures. What could cause the design to fail in our tree diagram that we've been looking at? Our slice of cheese would be to prevent the design failure by fixing the design specification, whatever's causing the design failure in the first place.

The potential effect that we're looking at in the design FMEA could be the overall system from just the customer viewpoint. It could also be for the next higher design. If we have a hierarchical system of components, subsystems and systems, what would be the effect of failure at this level on the next level of design?

The design FMEA is focused on the design of the product itself. We may not always be working from a tree diagram when we're creating a design FMEA. We may look at a particular component (at its features, its materials and how it's built) and thinking about how it would fail and then working backwards from that.

For example, we may look at our part and, considering the geometry and the materials that it's made of, it may stress crack. So stress crack would be our failure. The cause could be material spec and part geometry. The effect of failure could be whatever effect it has on the next level design of the system or product.

Process FMEA

Like the design FMEA, a process FMEA is focused on individual processes or process steps. We would want to place our slice of cheese here. We want to prevent the manufacturing process failure that leads to parts wrong, and the cause that we want to fix has to do something with our process step.

The potential symptom, or effect of failure, is a consequence on the next process, the next operation. It can also be on the product, the customer or other things. And again, we're focused in on the product design itself. This isn't really a system level FMEA.

Hazard Analysis

A hazard analysis table may look similar to an FMEA, but it's a little different and here's what's different: hazard analysis evaluates and tracks safety issues, identifies hazards and parts of a system that can create hazards including human error. FMEA, on the other hand, evaluates and tracks potential failure issues. A hazard analysis has a larger scope. It considers hazards due to failure and hazards not introduced by failure. Hazards analysis supplements FMEA.

In our FMEA scenario example, a delayed use of a bike stand is not really a hazard. If this were a medical device that was performing an intervention, then delayed use could be a hazard.

Because this isn't really a hazardous situation, let's take a look at maybe something that could be.

Tree diagrams for hazards

Let's create a tree diagram about a hazardous situation where a bike stand falls with the bicycle in it and that could lead to property damage or injury. We start drawing out our map of what could cause this. It could be that the bike stand is not sturdy or that it doesn't fit into the stand. We can keep going with our causal chain and fill out our tree diagram.

Fault Tree Analysis (FTA)

Then we can also flip it 90° so that our hazard is at the top. Now we can start adding logic and/or gates, and this logic can show the inner relationships of an event happening depending on two or more faults happening together. That's considered a multi-point failure and what we're looking at now is a fault tree analysis.

Fault tree analyses are helpful if any one failure wouldn't cause a hazard but if a combination of failures could cause it. It helps us to understand and capture that information. You can see from this example that hazard analysis, and a fault tree analysis used to help us, is capturing hazards and some combinations of faults that can lead to a hazardous event that we may not have caught in a failure mode effects analysis. This is why hazard analysis is a supplement to FMEA.

We cannot eliminate all risk.

We're going to have to live with some risk but we can determine which risks we're willing to live with. We don't have to do an FMEA on everything, but we do want to do FMEA on the things that are causing us the most concern. Maybe the riskiest component that we have in our new design: we may want to do a design FMEA on that to explore that further and make sure that we have our design inputs correct and that whatever we've learned from this new component can be properly reviewed by the cross functional team.

Let's consider how we can construct FMEA so we get the design inputs that we need.

Knowing what we want to get out of a particular FMEA also helps us to assess whether or not we want to do that level of an FMEA. The output of our analysis is supposed to be input into the design. The things that we might get out of these types of analyses are:

• the design features
• limits and performance
• testing parameters
• the confidence levels for tests
• what quality assurance or test methods we would want
• the design measures we put in place to prevent failures or prevent causes that create failures
• a list of information that we need to include in the labeling: things that we need to communicate to our users
• an idea of design trade-offs
• characteristics that we may want to monitor for the product after it's in the field.

These are all real inputs into the design from these types of analyses. One of the keys of success to risk analyses during design is to have these design inputs as a goal.

We want to structure risk analyses for people to develop actions or to decide there doesn't need to be in action. We want those design inputs, we want to eliminate reduce or control risks, and we want to be able to define the need for data and how it will be implemented through the design or the process.

If we aren't getting this type of output from our FMEA, then our team needs to reassess what we're doing and understand why it's not working. We may have to adjust our timing, the way we're creating it or the way we use it, or team dynamics.

We can also scale the scope of these analyses for what it is that we need.

We may want to look more closely at the system function, the interfaces, the subsystems, the components and even the requirements. We can do failure mode effects analysis on requirements. The scope of these analyses should be determined by the team for the particular project.

On the other hand, there may be several layers of FMEA to any particular product design and this seems to be especially the case in manufacturing. Manufacturing FMEA, as our process FMEAs, may have different levels or tiers of FMEAs depending on what it is they want to explore. If they find a symptom-problem-cause chain that they want to explore further for the root cause they may decide to do another FMEA. That's another reason we do layered FMEAs: because we're further exploring our tree diagram and the causes in getting to the root cause.

Another reason we may want to do different FMEAs in different layers of FMEAs is the topic of the FMEA has a different owner. We may want to break out our FMEAs into different systems or subsystems for a design. FMEA group A has subsystem A and group B is working on subsystem B. They may decide to do different FMEAs. Those different groups can still merge those FMEAs together in a higher-level FMEA, like a system FMEA, and that's how we bring the whole picture together.

Going back to our fault tree analysis example, what could we do? People could develop actions to eliminate, reduce or control risks. In this case, for this example, we could keep the fault tree analysis and then evaluate these single point failures in an appropriate FMEA and link it back to the fault tree analysis. For our example, it looks like a use FMEA would be appropriate.

With our FMEAs, we can also add information that we want or need.

There are other versions of FMEAs that people have used or shared. They added a couple columns to the table. We can add diagnostic information if we want, or criticality information. We can also add columns to explain the source of our data; if we estimated an occurrence rate based on complaint data of another product, we can make that as a note in a column in our FMEA.

FMEAs provide that conduit for us to be able to review these tricky situations, details about the design and evaluate our users and how they're using our product more thoroughly, more effectively. It allows the team to come together across a common tool with a common purpose of reducing risk. FMEA is a way that we can analyze our design concepts and our designs themselves to make sure that they're the best they can be. It's a great way to communicate with our team, incorporate their feedback and make decisions with data.

Here's what we covered in today's lesson.

• We identified types of FMEAs to use for product design, and we looked at when they may not be necessary.
• We can use hazard analysis, system FMEA and use FMEA at the concept phases in early product development, and our design and process FMEA can look at individual failure points as we get further along in development.
• We talked about how to layer FMEAs for design input and that we want to have those inputs as a goal in mind when we're doing risk analyses.

I'm glad we could talk about this today. I'll see you in the next lesson.

[progressally_media media_id="2"]