AIAG & VDA Failure Mode and Effect Analysis

Failure Mode and Effects Analysis (FMEA) is a team-oriented, systematic. qualitative, analytical method intended to:

• evaluate the potential technical risks of failure of’a product or process
• analyze the causes and effects of those failures
• document preventive and detection actions
• recommend actions to reduce risk

Manufacturers consider different types of risk including technical risks. financial risks, time risks and strategy risks. The FMEA is used for analyzing the technical risks to reduce failures and improve safety in the products and processes.

The objective of FMEA is to identify the functions of a product or steps of a process and the associated potential failure modes, effects, and causes. Furthermore, it is used to evaluate whether prevention and detection controls already planned are enough, and to recommend additional actions. The FMEA documents and tracks actions that are taken to reduce risk. The FMEA methodology helps engineers prioritize and focus on preventing product and/or process problems from occurring. Business objectives exist that are supported by the FMEA and other activities. such as:

• Increasing the quality, reliability, manufacturability, serviceability. and safety of automotive products
• Ensuring the hierarchy. linkage, interface. and cascading and alignment of requirements between components, systems and vehicles are captured
• Reducing warranty and goodwill costs
• increasing customer satisfaction in a highly competitive market
• Proving product and process risk analysis in the case of product liability
• Reducing late changes in development
• Maintaining defect-free product launches
• Targeting communication in internal and external customer and supplier relationships
• Building up a knowledge base in the company. i.e document lessons—learned
• Complying with regulations in the registration approval of the components, systems, and vehicles

Limitations of the FMEA include the following:

• It is qualitative (subjective). not quantitative (measurable)
• It is a single-point failure analysis not a multi-point failure analysis
• It relies on the team’ 5 level of knowledge which may or may not predict future performance.
• It is a summary of the team’ s discussions and decisions, therefore, the quality of the FMEA report is subject to the recording skills of the team which may reflect the discussion points in whole, or in part (it is not a transcript of a meeting)

For quantitative analysis and multi-point failure analysis other methods such as FTA (Fault Tree Analysis) and FMEDA (Failure Modes Effects, and Diagnostic Analysis) are used. These are the methods which can calculate and analyze the relevant metrics (e.g. single-point failure analysis. multi—point faults latent faults) to reach a quantified analysis result.

Integration of FMEA in the Company

FMEA is a multi-disciplined activity affecting the entire product realization process. The implementation of FMEA needs to be well planned to be fully effective. The FMEA method is an integral element of Product Development and Process Development activities. The FMEA can reduce product redevelopment timing and cost. It supports the development of comprehensive specifications, test plans, and Control Plans.

1 Potential Considerations of the FMEA
The competent performance of the FMEA and the implementation of its results are among the responsibilities of companies that design,manufacture, and/or assemble products for the automotive industry. It is critical that the analysis take into consideration the product’s operating conditions during its useful life. particularly with regard to safety risks and foreseeable (but unintentional) misuse. When the FMEA is performed, the following norms are observed:

• Clear: potential failure modes are described in technically precise, specific terms. enabling a specialist to assess failure causes and possible effects. Descriptions are free from possible misunderstanding. Emotion-laden terms, (e.g. dangerous, intolerable, irresponsible, etc.) are not appropriate.
• True: the consequences of potential failures are described accurately (e.g.. potential for odor, smoke, fire, etc.).
• Realistic: failure causes are reasonable. Extreme events are not considered (e.g.. falling rock on road, no power to manufacturing plant. etc.). Failures resulting from misuse relative to perception, judgement, or action are considered foreseeable when documented by systematic methods (including brainstorming, expert judgement, field reports. use case analysis, etc.). Failures resulting from intentional misuse (e.g. deliberate manipulation and sabotage) are not considered.
• Complete: foreseeable potential failures are not concealed. Concern about revealing too much know-how by creating a correct and competent FMEA is not a valid reason for an incomplete FMEA. Completeness refers to the entirety of the product/process under analysis (e.g., system elements and functions). However. the depth of detail depends on the risks involved.

Technical risks of failure identified in the FMEA are either assessed as acceptable. or actions are assigned to further reduce risk. The closure status of actions to reduce the risk is documented.

2 Senior Management Commitment

The FMEA process can take considerable time to complete. A commitment of the required resources is vital. Active participation of the product and process owners and commitment from senior management are important to successful FMEA development. Senior management carries the responsibility for the application of FMEA. Ultimately. senior management is responsible for acceptance of the risks and risk minimization actions identified in the FMEA.

3 Know-How Protection of the Design FMEA/ Process FMEA

The sharing of intellectual property found in the Design FMEA and for Process FMEA between suppliers and customers is governed by contractual agreements between suppliers and customers .

4 Agreements between Customers and Suppliers
The Customer Specific Requirements regarding FMEA should be coordinated with the parties involved and for the suppliers. An agreement made about the execution of FMEAs may include but is not limited to items such as system boundaries, necessary work documents, analysis methods, and evaluation tables.

5 Foundation and Family FMEAs
Foundation and family FMEAs are recommended to be created and used as a basis for new analyses. These optional practices provide the greatest opportunity to leverage past experience and knowledge and ensure that knowledge is accumulated over product lifecycles and that prior performance issues are not repeated (lessons learned). Furthermore. such reuse also reduces effort and expenditures. Foundation FMEAs (also known as generic. baseline, template, core, master, or best practice FMEAs. etc.) are FMEAs that contain knowledge of the organization from prior developments which make them useful as a starting point for new FMEAs. The foundation FMEA is not program specific, therefore the generalization of requirements, functions, and measures is allowed. Family FMEAs are specialized foundation FMEAs. It is common to develop products that generally contain common or consistent product boundaries and related functions (a Product Family) or processes which contain a series of operations that produce multiple products or part numbers. In these cases, it is appropriate to develop Family FMEAs which cover the commonalities for these Families. When using the family or foundation FMEA approach for the new product or process under development, the team should identify and focus the analysis on the differences between the existing and the new product, process or application. The information and. ratings carried over from the family or foundation are to be criticality- examined. with regard to the respective use case, and experiences from the known application.

FMEA for Products and Processes

There are three basic cases fer which the FMEA is to be applied, each with a different scope or focus.
Case 1: New designs. new technology, or new process. The scope of the FMEA is the complete design. technology. or process.

Case 2: New application of existing design or process. The scope of the FMEA is an existing design or process in a new environment, location, application, or usage profile (including duty cycle, regulatory requirements, etc.). The scope of the FMEA should focus on the impact of the new environment, location, or application usage on the existing design or process.
Case 3: Engineering changes to an existing design or process. New technical developments, new requirements, product recalls, and reports of failures in the field may drive the need for design and/or process changes. In these cases, a review or revision of the FMEA may be necessary.
The FMEA contains a collection of knowledge about a design or process and may be revised after start of production if at least, one of the following points applies:

• Changes to designs or processes
• Changes to the operating conditions
• Changed requirements (e.g.. law. norms. customer. state of the art)
• Quality Issues, ( e.g.. Plant experience. zero mileage, or field issues. internal / external complaints)
• Changes to the Hazard Analysis and Risk Assessment (HARA)
• Changes to the Threat Analysis and Risk Assessment (TARA)
• Findings due to product monitoring
• Lessons learned
  There are two main approaches to FMEA: the analysis according to product functions (Design FMEA) or according to process steps (Process FMEA).

1 Design FMEA
A Design FMEA (DFMEA) is an analytical technique utilized primarily by a design responsible engineer/team as a means to assure that, to the extent possible. potential Failure Modes and their associated Causes or mechanisms of failure have been considered and addressed prior to releasing the part to production. The Design FMEA analyzes the functions of a system, subsystem, or component of interest as defined by the boundary shown on the Block/Boundary Diagram, the relationship between its underlying elements, and to external elements outside the system boundary. This enables the identification of possible design weaknesses to minimize potential risks of failure. A System DFMEA is comprised of various subsystems and components which are represented as system elements (items). System and subsystem analyses are dependent on the viewpoint or responsibility. Systems provide functions at the vehicle level. These functions cascade through subsystems and components. For purpose of analysis, a sub-system is considered the same way as a system. Interfaces and interactions among systems, subsystems, the environment and the customers (e.g. Tier N, OEM, and end user) may be analyzed in System FMEAs. Within a system there may be software, electronic, and mechanical elements. Examples of systems include: Vehicle, Transmission System, Steering System, Brake System or Electronic Stability Control System, etc. A component DFMEA is a subset of a system or subsystem DFMEA. For example. an Electrical Motor is a component of the Window Lifter, which is a subsystem of Window Lifter System. A Housing for the Electrical Motor may also be a component or part. For this reason, the terms “system element” or “item” are used regardless of the level of analysis. Design FMEA may also be used to assess the risks of failure of non-automotive products such as machines, and tooling. The actions resulting from the analysis may be used to recommend design changes, additional testing, and other actions which reduce the risk of failure or increase the ability of a test to detect failures prior to delivery of the design for production.

2 Process FMEA
In contrast to the Design FMEA (DFMEA). which analyzes the failure possibilities that may be created during the design phase of the product, the Process FMEA (PFMEA) analyzes the potential failures of manufacturing, assembly and logistical processes to produce products which conform to design intent. Process-related failures are different than the failures analyzed in the Design FMEA. The Process FMEA analyzes processes by considering the potential failure modes which may result from process variation, to establish priority of actions for prevention, and as needed, improve controls. The overall purpose is to analyze processes and take action prior to production start. to avoid unwanted defects related to manufacturing and assembly and the consequences of those defects.

3 Collaboration between FMEAs
There are opportunities for collaboration between both Design and Process FMEAs in the same company and outside of the company. To help communicate effects and severity, a joined and agreed to severity evaluation can be reviewed between organizations (different companies in the supply chain starting with Tier 1. Tier 2. Tier 3. etc.)

A good starting point for a manufacturer is to make sure the severity in the DFMEA and PFMEA are the same when the failure effects are the same. If the “product“ failure effects to the end user
(vehicle-level) are not included in the PFMEA then the correlation between the DFMEA and PFMEA is not possible. A correlation needs to be made so that a failure of a feature in design that leads to a certain failure effect is also captured in the PFMEA for the same feature (product characteristic).

Project Planning
The Five T’s are five topics that should be discussed at the beginning of a DFMEA or PFMEA. In order to achieve the best results on time and avoid FMEA rework. These topics can be used as part of a project kick- off.

• FMEA lnTent – Why are we doing FMEA?
• FMEA Timing- When is this due?
• FMEA Team – Who needs to be on the team?
• FMEA Task – What work needs to be done?
• FMEA Tools- How do we conduct the analysis?

1 FMEA lnTent

It is recommended that members of the FMEA team are competent in the method, based on their role on the team. When team members understand the purpose and intent of FMEA. they will be more prepared to contribute to the goals and objectives of the project.

2 FMEA Timing

FMEA is meant to be a “before-the-event” action. not an “after-the- fact” exercise. To achieve the greatest value, the FMEA is conducted before the implementation of a product or process in which the failure mode potential exists. One of the most important factors for the successful implementation of an FMEA program is timeliness. Up-front time spent properly completing an FMEA, when product/process changes can be most easily and inexpensively implemented, will minimize late change crises. The FMEA as a method for system analysis and failure prevention is best initiated at an early stage of the product development process. It is used to evaluate the risks, valid at that time, in order to initiate actions to minimize them. In addition. the FMEA can support the compilation of requirements. The. FMEA should be carried out according to the project plan and evaluated at the project milestones according to the state of the analysis, it is recommended that a company defines the desired maturity levels for their FMEAs according to overall company-specific development project milestones.

Advanced Product Quality Planning (APQP) Phases	Plan and Define program	Product Design and Development  Verification	Process Design and Development Verification	Product and Production Validation	Feedback Assessment and Corrective action
DFMEA	Start FMEA planning in concept phase before product development begins information flow from DFMEA and PFMEA The DFMEA and PFMEA should be executed during the same time period to allow optimization of both the product and process design	Start DFMEA when the design concept is well understood	Complete DFMEA analysis prior to release of design specification for Quotation	Complete DFMEA action prior to start of production Tooling	Start again with DFMEA and PFMEA planning if there are changes to an existing Design or process
PFMEA		Start PFMEA when the production concept is well understood	Complete PFMEA analysis prior to final Process decision	Complete PFMEA action prior to PPAP/PPA

VDA maturity level Assurance level for new parts	ML0	ML1	ML2	ML3	ML4	ML5	ML6	ML7
	Innovation Approval for serial Development	Requirement Management for procurement Extensive	Definition of the supply chain and placing of Extensive	Approval of Technical Specification	Production planning done	Serial tools, spare parts and Serial Machines available	Product and Process approval	Project End, Responsibilities transfer to serial production, start ,Requalification
DFMEA		Start FMEA planning in concept phase before product development begins information flow from DFMEA and PFMEA The DFMEA and PFMEA should be executed during the same time period to allow optimization of both the product and process design	Start DFMEA when the design concept is well understood	Complete DFMEA analysis prior to release of design specification for Quotation		Complete DFMEA action prior to start of production Tooling		Start again with DFMEA and PFMEA planning if there are changes to an existing Design or process
PFMEA			Start PFMEA when the production concept is well understood		Complete PFMEA analysis prior to final Process decision		Complete PFMEA action prior to PPAP/PPA

NOTE: Exceptions to this FMEA timing include non-traditional development flows such as where development of a “standard” process precedes the development of products that will be manufactured using the process.

3 FMEA Team

The FMEA team consists of multi-disciplinary (cross-functional) members who encompass the necessary subject matter knowledge. This should include facilitation expertise and knowledge of the FMEA process. The success of the FMEA depends on active participation of the cross-functional team as necessary to focus on the topics of discussion.

The Design FMEA Team
The Core Team may consist of the following people:-

• facilitator
• design engineer
• system engineer .
• component engineers
• test engineer
• quality/reliability engineer
• others responsible for the development of the product

The Core Team members prepare the FMEA System Analysis. (Steps 1-3) and participate in the FMEA meetings. The Extended Team may participate on demand (coordinated by the FMEA facilitator or meeting organizer). The Extended Team may consist of the following people:

• technical experts
• process/manufacturing engineer
• service engineer
• project manager
• functional safety engineer
• purchasing
• supplier
• customer representative
• others that may have specialized knowledge which will help the core team analyze specific aspects of the product

The Process FMEA Team
The Core Team may consist of the following people:

• facilitator
• prccess/manufacturing engineer
• ergonomic engineer
• process validation engineer
• quality/reliability engineer
• others responsible for the development of the process

The Core Team members prepare the FMEA System Analysis (Steps 1 – 3) and participate in the FMEA meetings. The Extended Team may participate on demand (coordinated by the FMEA facilitator or meeting organizer). The Extended Team may consist of the following people:

• design engineer
• technical experts
• service engineer
• project manager
• maintenance staff
• line worker
• purchasing
• supplier
• others (as necessary)

FMEA Team Roles and Responsibilities
Within the organization’s product development process. the following roles and responsibilities for FMEA participation should be assigned. Responsibilities of a given role can be shared amongst different persons and/or multiple roles may be assigned to the same person.
a) Management, (Project Manager)

• Authority to make decisions about the acceptability of identified risks and the execution of actions
• Defines the persons responsible for pre-work activities, FMEA facilitation, and the design/process engineer responsible for implementation of actions resulting from the analysis
• Responsible for selecting and applying resources and ensuring an effective risk management process is implemented within scheduled project timing
• Responsibility and ownership for development and maintenance of the FMEAs.
• Management responsibility also includes providing direct support to the team(s) through on-going reviews and eliminating roadblocks.
• Responsible for budget.

b) Lead Design/Process Engineer (Technical Lead)

• Technical responsibility for the FMEA contents
• Preparation of the Business Case for technical and/or financial decisions
• Definition of elements, functions, requirements, and interfaces
• Focusing on the topics
• Procurement of the necessary documents and information
• Incorporating lessons learned

c) FMEA Facilitator

• Coordination and organization of the workflows in the FMEA
• Mitigation of conflicts
• Participation in the team formation
• Participation in the Preparation of the rough schedule
• Participation in the invitation to the 1st team meeting for the analysis phase
• Participation in the Preparation of the decision guidelines/criteria
• Development of Corporate or Product Line Examples for Rating Tables (Optional) with support from Design/Process Engineer
• Method competence (FMEA) and familiarization of participants in the FMEA method
• FMEA Software documentation competence (as necessary)
• Social skills. able to work in a team
• Competent moderator, ability to convince, organization and, presentation skills
• Managing execution of the 7 steps of FMEA method
• If necessary, Preparation or wrap-up of FMEA meetings
• Moderation of the FMEA workgroup
• NOTE: Any team member with the relevant competence and training may fulfill the role of facilitator,

d Core Team Members.

• Contribute knowledge from relevant product and process experience
• Contribute necessary information about the product or process that is the focus of the FMEA
• Contribution of existing experiences from previous FMEAs already known
• Participation in the execution of the 7 steps of FMEA
• Involvement in the Preparation of the Business Case
• Incorporating lessons learned

e Extended Team Members/Experts

• Contribution of additional information about special topics
• Contribution of necessary information about the product or process that is the focus of the FMEA
• Involvement in the Preparation of the Business Case

4 FMEA Task
The 7-Step Overview provides the framework for the tasks and deliverables of the FMEA. In addition, the FMEA team should be prepared to review the results of their analysis with management and the customer. upon request.The FMEA may also be audited by an internal auditor, customer auditor, or third-party registrar to ensure each task has been fulfilled.

5 FMEA Tools

There are numerous FMEA Tools, i.e.. software packages that an be used to develop a DFMEA and PFMEA as well as follow up on actions. This software ranges from dedicated FMEA software to standard spreadsheets customized to develop the FlEA. Companies may develop their own in-house database solution or purchase commercial software. In any case. the FMEA team needs to have knowledge of how to use the FMEA tool selected for their project as required by the company. The Software View depicts what the user sees when developing a FMEA using specialized software that utilizes system element structure, function net, failure net, etc. The Form View depicts what the user sees when developing a FMEA in a spreadsheet.

FMEA METHODOLOGY

The FMEA process is carried cut in seven steps. These seven steps provide a systematic approach to perforrn a Failure Made and Effects Analysis and serve as a record of the The FMEA process is carried cut in seven steps. technical risk analysis.