Students will be introduced to failure modes and effects analysis (FMEA) and failure modes, effects, and criticality analysis (FMECA), and taught how to use both to make their design reliable, cheap, and fast to produce. The course structure and schedule are also covered, along with the role of Artificial Intelligence (AI).

FMEAs are commonly misunderstood and seen as a bureaucratic formality. When done well, FMEAs greatly accelerate production, slash costs by eliminating problems and crises, and allow novel design features to be incorporated when it is fast and easy.

Students will be taught what a design FMEA/FMECA is, how it incorporates software FMEAs, where it occurs in the design and production process, and common mistakes made when attempting them.

Description of how Process FMEAs can be used to improve manufacturing processes to minimize defects, scrap, rework, and costs. Students are shown how Design FMEAs/FMECAs interact with and guide Process FMEAs.

Root causes of failure (by definition) are human behaviors. They are things we can do differently. If not, then they are simply environmental or operational characteristics we need to deal with (and not things we can blame). Root causes of failure aren’t corrosion, suppliers, customers, the weather, or the schooling system. They are (by definition) decisions we did (or didn’t) make.

Around 50 % of failures occur at interfaces between components, systems, users and the external environment. FMEA Block diagrams make these interfaces 'visible' to ensure our FMEA doesn't accidentally halve reliability by forgetting about them.

Good FMEAs involve creating (or recreating) a use case regardless of what has been completed beforehand. This allows specific characters (with names) to be used in the FMEA workshop to facilitate brainstorming and the identification of potential root causes of failure.

Students will see how the first step of a FMEA is completed, where the item is defined and requirements are brainstormed.

‘Requirements’ are the language of the customer or user. ‘Functions’ are the language of the designer. ‘Functions’ are things the item in question does. Students will learn how ‘functions’ support ‘requirements,’ which supports how FMEAs find potential root causes of failure, and how 'basic,' 'interface' and 'additional' functions help understand what your product is supposed to do.

Students will see how the second step of a FMEA is completed, where the functions that support requirements are identified in priority order.

‘Functional failure modes’ are what your item is (or is not) doing as a result of failure. Students will learn what these are at the system and component levels and how they can be used to prioritize which failures we focus on first.

If all failures are important, then no failures are important. Students will learn how to easily classify the ‘severity’ of different failures using criteria that are easy to understand and allow rapid classification during a FMEA workshop to help maintain momentum.

Students will see how the third step of a FMEA is completed, and potential effects of specific failure modes are identified to work out what parts of the item need to be focused on first.

'Functional failure modes' are the functional consequences of a failure mechanism - and they can apply at the component level. ‘Physical failure modes’ are the physical aftermath of a failure mechanism, which by definition occur at the component level. A physical failure mode could be a ‘fracture,’ ‘deformation,’ ‘delamination,’ or whatever else describes what the ‘broken bit’ looks like. Together, these help us understand 'component failure modes' which are essential to trying understand what might cause failure. Students will learn what ‘physical failure modes’ are and how they relate to other ‘failure modes.’

‘Failure mechanisms’ are the physical, chemical, electrical, thermal, or other natural processes that result in failure (think ‘fatigue,’ ‘corrosion,’ ‘wear,’ and so on). Students will learn about ‘failure mechanisms’ and how they are the only things we can model, drive maintenance strategies ... and more!

Each ‘failure mechanism’ is triggered by something called a ‘fault,’ which is the circumstance that gives rise to failure. ‘Faults’ can be physical (such as manufacturing defects or imperfections), a poor design choice (where the wrong material is used), or anything else. Students will learn about ‘faults’ to understand how we can identify potential root causes of failure.

Software runs (and ruins) everything. Many software related failures are caused by simply 'forgetting' how important software is until it's too late. Students (especially those with a hardware background) will be introduced to how software fails to help them understand what they need to look for when it comes to including software in a FMEA.

Incorporating software into a FMEA means sharing some language. Software functional failure modes are uniquely 'software,' but are analagous to hardware comonent functional failure modes. Students will learn how to use software functinal failure modes to enhance what would otherwise be hardware-centric FMEAs.

Software failures are more than simple coding errors. Students will be taught the different types of software defects, along with how they lead us to simple fixes up front that prevent software issues from causing problems later.

Software failures are always 'human errors.' Software always does what the code asks it to do. Students are taught how software failures 'enter' the code in the first place to help inform what needs to occur to help understand what steps a FMEA can identify to ensure they don't enter in the future.

The majority of software failures go beyond simple coding errors. Students will be taught the most common root causes of software failure to help them understand how a FMEA can help ensure that they never enter a product's or system's design.

Students will see how the fourth step of a FMEA is completed, the role that key components play in the key system failure modes, and their effects.

Students will see how the fifth step of a FMEA is completed, where the the root cause statements that drive useful ideas are brainstormed.

Students will be taught reliability basics in a largely visual (equation-lite) way to ensure a deep understanding of 'how often things fail,' and how that relates to reliability specifications.

This is another 'equation-free' lesson where we examine the CDF or failure function, and how it relates to other probabilistic concepts such as the reliability function and Probability Density Function (PDF). Students will learn how the CDF applies to these reliability functions, and informs the likelihood of failure in a FMEA or FMECA.

Most organizations are already doing 'something' to mitigate failures. Students are taught how to take into consideration existing 'prevention controls' or what is already being done when to make sure FMEAs and FMECAs don't force us to continually focus on things that are already dealt with.

Students will learn how ‘occurrence’ can be used to help characterize the likelihood of different failure scenarios to ensure that (in conjunction with the ‘severity’ of each failure) we only ever focus on the ‘vital few.’

The MTTF and MTBF are not reliability metrics, although they are frequently used in that context. Students will be taught what the 'mean' of a random variable is, and how the MTBF in particular relates to repairable systems.

While other probabilistic functions like the CDF and PDF can help characterize when or 'how often' something might fail, the 'hazard rate' helps us understand what we can do to improve reliability. Understanding the hazard rate helps inform servicing, overhaul, and condition-based maintenance, AND helps us identify when things like manufacturing defects are driving failure. Students will learn what the hazard rate is and how it can help FMEAs and FMECAs.

The 'hazard rate' is the rate at which a surviving or functional system or item fails. An item with a 'constant' hazard rate never ages. Think of a coffee mug. The ceramic is very stable, and never 'degrades' or 'wears out' throughout its life. But coffee mugs do 'fail' ... when we drop them. As a 'young' coffee mug is equally likely to be dropped as an 'old' coffee mug, it has a constant hazard rate. This is very rare in the world of reliability and manufacturing, as most machines and products wear out, wear in, or do both. However, many of these items are assumed to have a constant hazard rate. This lesson teaches students about the constant hazard rate, what it represents, and pitfalls associated with its use.

Many machines and products are used as part of a larger asset, and are routinely repaired. This means their reliability performance is not the same as (for example) a consumer product. Students will be taught how to develop MTBF based occurrence scales for repairable systems.

Students will see how the sixth step of a FMEA is completed, where the occurrence of each potential root cause of failure (and by extension the failures they cause) are assessed to focus on the 'vital few' that matter.

Students will see how the seventh step of a FMEA is completed, where the risk of each potential root cause of failure is assessed to ensure that we focus only on the ones that matter moving forward.

The ‘faults’ that trigger different failure scenarios can sometimes be detected during production. Something like a bend in metal that is too sharp (thereby amplifying local stresses beyond a critical level) might be detected during something like ‘finite element analysis (FEA).’ Students will learn about the ‘detectability’ of different failure scenarios, allowing us to pay less attention to or ignore failure scenarios we will likely pick up anyway.

Students will be taught how to develop ‘detectability scales’ with criteria for different timeframes for potential detectability during the normal production process. Developing scales like these greatly speeds up the FMEA or FMECA workshop, and produces more meaningful results.

Students will see how the seventh step of a FMEA is completed, where the detectability of each root cause of failure is assessed.

FMEAs and FMECAs are not about admiring problems. They are about preventing them. Students will learn how the prioritized failure scenarios can be analyzed for different ‘corrective actions (CAs)’ to be identified to prevent those scenarios from occurring. The earlier CAs are identified, the faster, simpler, and cheaper they are to implement.

Some systems are very complex. Completing a FMEA on the entire system can be unfeasible. System FMEAs can help break down the task by focusing on the system at a high level and then (amongst other things) identifying the components and subsystems that will be subjected to more specific FMEA efforts. Students will learn how system FMEAs can help you work out what part of your system you need to (and which you don’t need to) focus on.

A ‘criticality analysis’ is a poorly defined activity that often focuses on the ‘failure rates’ of different failure scenarios to help inform logistic and support activities (like sparing and repair). Students will learn how ‘criticality analyses’ can be used, effectively converting a FMEA to a FMECA (‘failure mode, effects, and criticality analysis).

Maintenance strategies are often identified after a design is finalized. This robs a lot of potential for truly optimized maintenance strategies, as slight design modifications allow extraordinary maintenance efficiency improvements. Students will learn how to embed maintenance considerations into a FMEA seamlessly.

A good FMEA workshop doesn’t just happen. A FMEA workshop is a brainstorming workshop of 4-8 cross-functional representatives with an amazing facilitator. Students will learn how to prepare for and execute an amazing FMEA workshop.

FMEAs and FMECAs aren't complete when the workshop has finished. They are complete once all the corrective actions have been implemented, or otherwise addressed. Students will learn how to create a system that ensures the FMEA or FMECA is not 'wasted effort.'

Virtually all FMEA, FMECA, and risk standards (including ISO/IEC 23894) require thoughtful tailoring. However, the approaches outlined in each standard often doesn't 'neatly' follow the best approach for a FMEA brainstorming workshop. Students will be taught how to ensure that they both create 'compliant' FMEAs and FMECAs, while not loosing the ability to facilitate effective brainstorming.

A summary of all the core concepts we covered in the course and brief review of key takeaways.