PRACTICAL FMEA/FMECA WITH AI 

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.

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.

‘Physical failure modes’ are the physical aftermath of a failure mechanism. This could be a ‘fracture,’ ‘deformation,’ ‘delamination,’ or whatever else describes what the ‘broken bit’ looks like. 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 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.

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.

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.’

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.