AIAG & VDA Process Failure Mode and Effect Analysis

Step 1 : Planning and Preparation

1.1 Purpose

The purpose of the Process Planning and Preparation Step is to describe what product/ processes are to be included or excluded for review in the PFMEA project. The process takes into account that all processes within the facility can be analyzed or reanalyzed using PFMEA. This process allows an organization to review all processes at a high level and to make a final determination for which processes will be analyzed. The overall advantage of Preparation is to focus resources on processes with the highest priority. The main objectives of the Process Planning and Preparation
Step are:

• Project identification
• Project plan: lnTent, Timing, Team, Tasks. Tools (5T)
• Analysis boundaries: What is included and excluded from the analysis
• Identification of baseline FMEA with lessons learned
• Basis for the Structure Analysis step

1.2 PFMEA Project Identification and Boundaries

PFMEA Project identification includes a clear understanding of what needs to be evaluated. This involves a decision-making process to define the PFMEAs that are needed for a customer program. What to exclude can be just as important as what to include in the analysis. Below are some basic questions that help identify PFMEA projects.

• What is the customer buying from us?
• Are there new requirements?
• What specific process/elements cause a risk in imparting the requirement/characteristic?
• Does the customer or company require a PFMEA?
• Do we make the product and have design control?
• Do we buy the product and still have design control?
• Do we buy the product and do not have design control?
• Who is responsible for the interface design?
• Do we need a system, subsystem, component, or other level of analysis?

Answers to these questions and others defined by the company help create the list of DFMEA projects needed. The PFMEA project list assures consistent direction, commitment and focus. The following may assist the team in defining PFMEA boundaries, as available:

Legal requirements

• Technical requirements
• Customer wants/needs/expectation (external and internal customers)
• Requirements specification
• Diagrams (Block/boundary/System)
• Schematics, drawings, and/or 3D models
• Bill of Materials (BOM), Risk Assessment
• Previous FMEA for similar products
• Error proofing requirements, Design for Manufacturability and Assembly (DFM/DFA)
• QFD Quality Function Deployment

Preparation needs to be established at the start of the process to assure consistent direction and focus, e.g., an entire process line, process item / process element. Processes within the plant that can impact the product quality and can be considered for PFMEA analysis include: receiving processes, part and material storage, product and material delivery, manufacturing, assembly, packaging, labeling, completed product transportation, storage, maintenance processes, detection processes and rework and repair processes, etc.

The following may be considered in defining the scope of the PFMEA as appropriate:

• Novelty of technology /degree of innovation
• Quality/Reliability History (In-house. zero mileage, field failures, warranty and policy claims for similar products)
• Complexity of Design
• Safety of people and systems
• Cyber-Physical System (including cybersecurity)
• Legal Compliance
• Catalog and standard parts

Items that may assist in determining whether an existing PFMEA should be included in the final scope:

• New development of products and processes.
• Changes to products or processes
• Changes to the operating conditions
• Changed requirements (laws/regulations, standards/norms, customers, state of the art)
• Manufacturing experience, 0 km issues, or field issues/Warranty
• Process failures that may result in hazards
• Findings due to internal product monitoring
• Ergonomic issues
• Continuous Improvement

1.3 PFMEA Project Plan

A plan for the execution of the PFMEA should be developed once the DFMEA project is known. It is recommended that the 5T method (InTent. Timing, Team, Tasks. Tool) be used. The organization also needs to factor in development of the applicable Customer Specific Requirements) (CSRs) methods and/or deliverables into the project plan. The plan for the PFMEA
helps the company be proactive in starting the PFMEA early. The DFMEA activities (5-Step process) should be incorporated into the overall project plan.

1.4 Identification of the Baseline PFMEA

Part of the preparation for conducting the PFMEA is knowing what information is already available that can help the cross-functional team. This includes use of a foundation PFMEA, similar product PFMEA, or product foundation PFMEA. The foundation PFMEA is a specialized foundation process FMEA for products that generally contain common or consistent product boundaries and related functions. For a new product in the foundation, added to this foundation PFMEA would be the new project specific components and functions to complete the new product’s PFMEA. The additions for the new product may be in the foundation PFMEA itself, or in a new document with reference to the original family or foundation PFMEA. If no baseline is available. then the team will develop a new PFMEA.

1.5 Process FMEA Header

During Preparation, the header of the PFMEA document should be filled out. The header may be modified to meet the needs of the organization and includes some of the basic PFMEA Preparation information as follows:

• Company Name: Name of Company Responsible of PFMEA
• Manufacturing Location: Geographical Location
• Customer Name: Name of Customer(s) or Product Family
• Model Year / Program[s): Customer Application or Company Model /Style .
• Subject: Name of PFMEA project
• PFMEA Start Date: Start Date
• PFMEA Revision Date: Latest Revision Date
• Cross-Functional Team: Team: Team Roster needed
• PFMEA ID Number: Determined by Company
• Process Responsibility: Name of PFMEA owner
• Confidentiality Level: Business Use, Proprietary, Confidential

Step 2 : Structure Analysis

2.1 Purpose

The purpose of Process Structure Analysis is to identify and breakdown the manufacturing system into Process items, Process steps, and Process Work Elements. The main objectives of a Process Structure Analysis are:

• Visualization of the analysis scope
• Structure tree or equivalent: process flow diagram
• Identification of process steps and sub-steps
• Collaboration between customer and supplier engineering teams (interface responsibilities)
• Basis for the Function Analysis step

A Process Flow Diagram or a Structure Tree helps define the process and provide the basis for Structure Analysis. Formats may vary by company including the use of symbols, symbol type and their meaning. A Process FMEA is intended to represent the process flow as it physically exists when “walking the process” describing the flow of the product through the process. Function Analysis (Step 3) should not begin until Structure Analysis {Step 2) is complete.

2.2 Process Flow Diagram

A Process Flow Diagram is a tool that can be used as an input to the Structure Analysis.

2.3 Structure Tree

The structure tree arranges system elements hierarchically and illustrates the dependency via the structural connections. This pictorial structure, allows for an understanding of the relationships between Process Items, Process Steps and Process Work Elements. Each of these is a building block that will later have functions .and failures added.

The Process Item of the PFMEA is the highest level of the structure tree or process flow diagram and PFMEA. This can also be considered the end result of all of the successfully completed Process Steps.

The Process Step is the focus of the analysis. Process Step. is a manufacturing operation or station.

The Process Work Element is the lowest level of the process flow or structure tree. Each work element is the name of a main category of potential causes that could impact the process step. The number of categories may vary by company. ( e.g., 4M, 5M, 6M. etc. and is commonly called the lshikawa Approach.) A process step may have one or more categories with each analyzed separately.
4M Categories: Machine, Man, Material (Indirect) EnvironMent (Milieu)

Additional Categories could be Method, Measurement

STRUCTURE ANALYSIS (STEP 2)
1. Process Item, System, Subsystem, Part Element or Name of Process	2.Process Step Station No. and Name of Focus Elements	3.Process Work Element 4M Type
Electrical Motor Assy Line	[OP 30] Sintered Bearing Press-In Process	Operator
Electrical Motor Assy Line	[OP 30] Sintered Bearing Press-In Process	Press Machine

1. Process Item: The highest level of integration within the scope of analysis.
2. Process Step: The element in focus. This is the item that is topic of consideration of the failure chain.
3. Process Work Element: The element that is the next level down the structure from the focus element.

2.4 Collaboration between Customer and Supplier engineering teams (interface responsibilities):

The output of the Structure Analysis (visualization of the process flow) provides a tool for collaboration between customers and suppliers (including machine suppliers) during technical reviews-of- the process design and/or PFMEA project.

2.5 Basis for Function Analysis

The information defined during Step 2 Structure Analysis will be used to develop Step 3 Function Analysis. If process elements (operations) are missing from the Structure Analysis they will also
be missing from the Function Analysis.

Step 3 Function Analysis

3.1 Purpose

The purpose of the Process Function Analysis is to ensure that the intended functions/requirements of the product/process are appropriately allocated. The main objectives of a Process Function Analysis are:

• Visualization of product or process functions
• Function tree/net or equivalent process flow diagram
• Association of requirements or characteristics to functions
• Collaboration between engineering teams (systems, safety, and components)
• Basis for the Failure Analysis step

3.2 Function

A function describes what the process item or process step is intended to do. There may be more than one function for each process item or process step. Prior to beginning the Function Analysis, information to be gathered could include but is not limited to; product and process functions, product/process requirements. manufacturing environment conditions, cycle time, occupational or operator safety requirements, environmental impact. etc. This information is important in defining the “positive” functions and requirements needed for the Functional Analysis. The description of a Function needs to be clear. The recommended phrase format is to use an action verb followed by a l to describe the measurable process function (“DO THIS“ “TO THIS”). A Function should be in the PRESENT TENSE; it uses the verb‘s base form (e.g., deliver, contain, control, assemble, transfer).

Examples: Drill hole, apply glue, insert pin, weld bracket

The Function of the Process Item begins at a high level and references the Process Item in the Structure Analysis. As a high-level description, it can take into account functions such as: internal function. external function, customer related function and/or end user function.

Example: Assemble components
The Function of the Process Step describes the resulting product features produced at the station.

Example: Press in sintered bearing to pole housing

The Function of the Process Work Element reflects the contribution to the Process Step to create the process / product features.

Note: The negative of these examples will be the Failure Effects.

Example: Get sintered bearing from chute manually

Example: Press force to press sintered bearing into pole housing

For the logical linking of a function and structure, questions are asked as:
“What does it do?”
How to achieve the product 1/ process requirements – from right to left
(Process Item → Process Step → Process Work Element)

“How?”

Why implement the product /process requirements from left to right
(Process Work Element →Process Step →Process Item)

3.3 Requirements (Characteristics)

A Characteristic is a distinguishing feature (or quantifiable attribute) of a product. For example, a diameter or surface finishes. For PFMEA. Requirements are described in terms of Product Characteristics and Process Characteristics.
Note: The negative of these will be the Failure Mode and the Failure Cause.
A Product Characteristic (Requirement) is related to the performance of a process function and can be judged or measured. A product characteristic is shown on a product drawing or specification document e.g., Geometry, Material, Surface Finish, Coatings. etc. Process functions create product characteristics. The design documents comprehend legal requirements (e.g. lead-free material), industry requirements (e.g., thread class), customer requirements (e.g., quantity), and internal requirements (e.g. part cleanliness). Product characteristics can be measured after the product has been made (e.g., gap), Product Characteristics can come from performance requirements, e.g., legal (performance of windshield wipers). In these cases, the measurable Product Characteristic should be listed, followed by the Performance Requirement, e.g., Spline Over-pin Diameter (Government Windshield Wiper Regulation XYZ). The specific quantitative value is optional for the PFMEA form sheet.

• Product Characteristics: May be derived from various sources, external and internal.
• Legal requirements: Compliance with designated health & safety-and environmental protection regulations
• Industry Norms and Standards: ISO 9001, VDA Volume 6 Part 3, Process Audit, SAE J1739
• Customer Requirements: According to customer specifications, e.g. adherence to
  required quality, manufacture and provision of products in time x and quantity y (output z/hour)
• Internal Requirements: Manufacture of the product, in process cycle, compliance with expected production costs (e.g.,. facilities availability. limited rejects. no corrective work), production system principles, process quality and cleanliness instructions
• Process Characteristics: A Process Characteristic is the process control that ensures the Product Characteristic is achieved by the process. It may be shown on manufacturing drawings or specifications (including operator work instructions, set-up instructions, error-proofing verification procedures, etc.). Process characteristics can be measured while the product is being made (e.g., press force). The specific quantitative value is optional for the PFMEA form sheet.

3.4 Visualization of functional relationships

The interaction of process item functions, process step functions and process work element functions may be visualized as function network, function structure, function tree, and/or function analysis depending on the software tool used to perform the PFMEA. For example, Function Analysis is contained in the Form Sheet to perform the PFMEA.

1. Function of the Process Item Function of System, Subsystem, Part Element or Process	2. Function at the Process Step, and Product Characteristic (Quantitative value is optional)	3.  Function at the Process Work Element and Process Characteristic
Your Plant: Assembly of shaft into pole housing assembly Ship to Plant: Assembly of motor to vehicle door End User: Window raises and lowers	Press in sintered bearing to achieve axial position in pole housing to max gap per print	Machine presses sintered bearing into the pole housing seat until the defined axial position

The column header numbering (1, 2, 3) coding are included to help show alignment between the Structure Analysis and associated content of the Function Analysis. You work from left to right answering the question: “How is the higher level function enabled by lower level functions?”

3.5 Collaboration between Engineering Teams (Systems, Safety, and Components)

Engineering teams within the company need to collaborate to make sure information is consistent fer a project or customer program especially when multiple PFMEA teams are simultaneously conducting the technical risk analysis. For example, design information from systems, safety. and/or component groups helps the PFMEA team understand the functions of the product they manufacture. This collaboration, may be verbal (program meetings) or written as a summary.

3.6 Basis for Failure Analysis

Complete definition of process functions (in positive words) will lead to a comprehensive Step 4 Failure Analysis because the potential failures are ways the functions could fail (in negative words).

Step 4 Failure Analysis

4.1 Purpose

The purpose of the Process Failure Analysis is to identify failure causes, modes, and effects, and show their relationships to enable risk assessment. The main objectives of a Process Failure Analysis are:

• Establishment of the Failure Chain
• Potential Failure Effects. Failure Modes. Failure Causes for each process function.
• Identification of process failure causes using a fishbone diagram (4M) or failure network
• Collaboration between customer and supplier (Failure Effects)
• Basis for the documentation of failures in the FMEA form sheet and the Risk Analysis step.

A failure analysis is performed for each element/step in the process description (Structure Analysis/Step 2 and Function Analysis/Step 3}.

4.2 Failures

Failures of a process step are. deduced from product. and process characteristics. Examples include:

• Non-conformities
• Inconsistently or partially executed tasks
• Unintentional activity
• Unnecessary activity

4.3 The Failure Chain

For a specific failure, there are three-aspects to be considered:
Failure Effect (FE), Failure Mode (FM), Failure Cause (FC)

4.4 Failure Effects

Failure Effects are related to functions of the process item (System, Subsystem. Part Element or Name of Process). Failure Effects are described in terms of what the customer might notice or experience. Failures that could impact safety or cause noncompliance to regulations should be clearly identified in the PFMEA. Customers could be:

• Internal customer (next operation/subsequent operation/operation targets)
• External customer (Next Tier Level/OEM/dealer)
• Legislative bodies
• Product or Product and user/operator .

Failure Effects are given a Severity rating according to:

1. Your Plant: the effect of the failure mode assuming the| defect is detected in the plant (what action will the plant take, e.g. scrap)
2. Ship-to plant: the effect of the failure mode assuming the defect is not detected before shipping to the next plant (what action will the next plant take. e.g.. sort)
3. End user: the effect of the process item effect (what will the end user notice, feel, hear, smell etc., e.g. window raises too slow)

The following questions should be asked to help determine the potential impact of failure effects:

1. Does the failure mode physically impact downstream processing or cause potential harm to equipment or operators? This includes an inability to assemble or join to a mating component at any subsequent customer‘s facility. Iif so, then identify the manufacturing impact “Your Plant“ and/or “ship-to plant“ in the PFMEA. If not, then go to question 2. Examples could include:

• Unable to assemble at operation at operation x
• Unable to attach at customer facility
• Unable to connect at customer facility
• Cannot bore at operation X
• Causes excessive tool wear at operation X
• Damages equipment at operation X
• Endangers operator at customer facility

Note; When parts cannot be assembled there is no impact to the End User and question 2 does not apply.

2.What is the potential impact on the End User? Independent of any controls planned or implemented including error or mistake-proofing, consider what happens to the process item that leads to what the End User would notice or experience. This information may be available within the DFMEA. If an effect is carried from the DFMEA, the description of the product effects in the PFMEA should be consistent with those in the corresponding DFMEA.
NOTE: In some cases, the team conducting the analysis may not know the end user effect (e.g.. catalogue parts. off- the-shelf products. Tier 3 components). When this information is not known. the effects should be defined in terms of the part function and/or process specification.

Examples could include:

• Noise
• High effort
• Unpleasant odor
• Intermittent operation
• Water leak
• Rough idle
• Unable to adjust
• Difficult to control
• Poor appearance
• Regulatory System Function reduced or failed
• End user lack of vehicle control
• Safety effect on end user

3. What would happen if a failure effect was detected prior to reaching the end user? The failure effect at the current or receiving locations also needs to be considered. Identify the manufacturing impact “Your Plant” and/or “ship-to plant” in the PFMEA.
Examples could include:

• Line shutdown
• Stop shipment
• Yard hold
• 100% of product scrapped
• Decreased line speed
• Added manpower to maintain required line rate
• Rework and repair

4.5 Failure Mode

A (Process) Failure Mode is defined as the manner in which the process could cause the product not to deliver or provide the intended function. The team should assume that the basic design of the product is correct; however, if there are design issues which result in process concerns. those issues should be communicated to the design team for resolution. Assume that the failure mode could occur but may not necessary occur. Failure modes should be described in technical terms, not as a symptom noticeable by the customer. Verification of completeness of the failure modes can be made through a review of past thing‘s gone wrong, reject or scrap reports, and group brainstorming. Sources for this should also include a comparison of similar processes and a review of customer (end user and subsequent operation) claims relating to similar components. There are several categories of potential failure modes including:

• Loss of process function/operation not performed
• Partial function – incomplete operation
• Degradation of process function
• Overachieving process function – Too much too high.
• Intermittent process function – operation not consistent
• Unstable operation .
• Unintended process function – wrong operation
• Wrong part installed
• Delayed process function – operation too late

Typical failure modes could be, but are not limited to:

• Hole too shallow, too deep. missing or off location.
• Dirty surface
• Surface finish too smooth
• Misaligned connector pins
• Connector not fully seated
• Pass a bad part, or reject a good part, bypass inspection operation
• Label missing
• Barcode not readable
• ECU flashed with wrong software.

4.6 Failure Cause:

A failure cause is an indication of why a failure mode could occur.The consequence of a cause is the failure mode. Identify, to the extent possible, every potential manufacturing or assembly cause for each failure mode. The cause should be listed as concise and complete as possible so that efforts (controls and actions) can be aimed at appropriate causes. Typical failure causes may include the classic lshikawa‘s 4M, but are not limited to:

• Man: set-up worker, machine operator/ associate, material associate, maintenance technician etc.
• Machine/Equipment: Robot, hopper reservoir tank. injection molding machine, spiral conveyor, inspection devices, fixtures, etc.
• Material (Indirect): machining oil, installation grease. washer concentration, (aid for operation), etc.
• EnvironMent (Milieu): ambient conditions such as heat, dust, contamination, lighting, noise, etc.

Note: In preparing the FMEA. assume that the incoming parts/materials are correct. Exceptions can be made by the FMEA team where historical data indicate deficiencies in incoming part quality.

One method to help reveal/uncover failure causes is to have a facilitator that leads the team through “Thought Provoking Stimulation /Questions.“ These questions can be broad category
questions, enough to stimulate the process experts thought process, while keeping the number of questions to a manageable level. Questions can be process specific and broken down into the
4M categories. Initial list of questions can be formed by reviewing the Failure Causes in previous PFMEA’s.
Example – Assembly Process:

4.6.1 Man

• From parts available within the process, can wrong part be applied?
• Can no part be applied?
• Can the parts be loaded incorrectly?
• Can parts be damaged – From pickup to application?
• Can wrong material be used?

4.6.2 Machine

• Can automated process be interrupted?
• Can inputted data be entered incorrectly?
• Can machine be run in manual mode, bypassing automated controls?
• Is there a schedule to confirm prevention and detection controls?

4.6.3 Material (indirect)

• Can too much/ too little / no material be used?
• Can material be applied to a wrong location?

4.6.4- EnvironMent (Milieu)

• Is lighting adequate for task?
• Can parts used within the process, be considered foreign material?

The description of the failure. cause needs to be clear. Terms such as “defective, broken.” “operator failure,” “non-fulfillment or “not OK” and so on are insufficient to comprehensively assign the failure cause and mode and to determine actions.

4.7 Failure Analysis

Based on the process steps, the failures are derived and failure chains (i.e., Failure structure/failure trees/failure network) are created from the function analysis. The focus element of the failure structure is the Failure Mode, with its associated Failure Effects and potential Failure Causes. Depending on the focus, a failure can be viewed as a Failure Effect, a Failure Mode, or a Failure Cause. To link failure cause to a Failure Mode, the question should be “Why is the Failure Mode occurring?”
To link failure effects to a Failure Mode, the question should be “What happens in the event of a Failure Mode?“

FAILURE ANALYSIS (STEP 4)
1. Failure Effects (FE) to the Next Higher Level Element and/or End User	2. Failure Mode (FM) of the Focus Element	3. Failure Cause (FC) of the Work Element
Your Plant: Clearance too small to assemble shaft without potential damage Ship to Plant: Assembly of motor to vehicle door requires additional insertion force with potential damage End user: Comfort closing time too long.	Axial position of sintered bearing is not reached	Machine stops before reaching final position

Begin building the failure chain by using the information in the Function Analysis. When using a customer specific form sheet or software. follow the methodology as defined by your customer.
1.Failure Effects (FE): The effect of failure associated with “Next Higher Level Element and/or End User” in the Function Analysis.
Note for spreadsheet users: A potential failure mode may have more than one failure effect. Failure effects are grouped in the spreadsheet in order to avoid excessive duplication of the same failure modes and causes.

2.Failure Mode (FM): The mode (or type) of failure associated with the “Focus Element” in the Function Analysis.
Note for spreadsheet users: It is recommended that users start with the failure mode and then identify related failure effects using the information in the #1 Function of the Process Item column of the Function Analysis section because some or all categories may apply.

3. Failure Cause (FC): The cause of failure associated with the “Work Element and Process Characteristics in the Function Analysis.

4.8 Relationship between PFMEA and DFMEA

A design failure of a feature (product characteristic) can cause a failure fer one or more product functions. The corresponding process failure is the inability of the process to manufacture the same feature as designed. The failure to conform to a product characteristic alone leads to the Failure Effect. Only in this case is the Failure Effect in the Design FMEA the same as in the Process
FMEA. All Failure Effects which are caused by a failure of the processes and which are not identified in Design FMEA have to be newly defined and assessed in the Process FMEA. The Failure Effects related to the product, system, and/or end user and their associated seventies should be documented when known, but not assumed. The key to the identification of Failure Effects and associated severity is the communication of the involved parties and the understanding of differences and similarities of the analyzed failures in DFMEA and PFMEA. Figure below shows a potential interrelation of product-related Failure Effects, Failure Modes and Failure Causes from the “End User” level to the level of production (PFMEA level).
Note: The expectation of the relative time of and the flow of information from the DFMEA to the PFMEA is different in non-standard development flows, such as where development of a “standard” process precedes development of the products that will be manufactured using it. In such cases, the appropriate timing and flow of information between these FMEAs should be defined by the organization.

4.9 Failure Analysis Documentation

After the Structure Analysis, Function Analysis and Failure Analysis are complete a structure tree or spreadsheet can have multiple views.

4.10 Collaboration between Customer and Supplier (Failure Effects)

The output of the Failure Analysis may be reviewed by customers and suppliers prior to the Risk Analysis step or after to the Risk Analysis step based on agreements with the customer and need
for sharing with the supplier.

4.11 Basis for Risk Analysis

Complete definition of potential failures will lead to a complete Step 5 Risk Analysis because the rating of Severity, Occurrence, and Detection are based on the failure descriptions. The Risk Analysis may be incomplete if potential failures are too vague or missing.

Step 5 Risk Analysis

5.1 Purpose:

The purpose of Process Risk Analysis is to estimate risk by evaluating Severity, Occurrence and Detection, in order to prioritize the need for actions. The main objectives of the Process Risk Analysis are:

• Assignment of existing and/or planned controls and rating of failures
• Assignment of Prevention Controls to the Failure Causes
• Assignment of Detection Controls to the Failure Causes and/or Failure Modes
• Rating of Severity, Occurrence and Detection for each failure chain
• Evaluation of Action Priority
• Collaboration between customer and supplier (Severity)
• Basis for the Optimization step

There are two different Control Groups: Current Prevention Controls, and Current Detection Controls.

5.2 Current Prevention Controls (PC)

5.2.1 Process planning

Definition: Current Prevention Controls facilitate optimal process planning to minimize the possibility of failure occurrence.
Prevention of possible layout deficiencies of the production facility:

• Test runs according to start-up regulation AV 17/3b

5.2.2 Production process

Definition: Eliminate (prevent) the failure cause or reduce its rate of occurrence.
Prevention of defectively produced parts in the production facility:

• Two-handed operation of machines
• Subsequent part cannot be attached (Poke-Yoke)
• Form-dependent position
• Equipment maintenance
• Operator maintenance
• Work instructions /Visual aids
• Machine controls
• First part release

Failure Causes are rated for occurrence, taking into account the effectiveness of the current prevention control. Current Prevention Controls describe measures which should be implemented in the design process and verified during prototype, machine qualifications (run-off), and process verification prior to start of regular production. Prevention Controls may also include standard work instructions, set-up procedures, preventive maintenance, calibration procedures, error-proofing verification procedures, etc.

5.3 Current Detection Controls- (DC)

Definition: Current Detection controls detect the existence of a failure cause or the failure mode, either by automated or manual methods, before the item leaves the process or is shipped to the
customer.

Examples of Current Detection controls:

• Visual inspection
• Visual inspection with sample checklist
• Optical inspection with camera system
• Optical test with limit sample
• Attributive test with mandrel
• Dimensional check with a caliper gauge
• Random inspection
• Torque monitoring
• Press load monitoring
• End of line function check

5.4 Current Prevention and Detection Controls

Current Prevention and Detection Controls should be confirmed to be implemented and effective. This can be done during an in-station review (e.g. Line Side Review, Line walks and Regular audits). If the control is not effective, additional action may be needed. The Occurrence and Detection ratings should be reviewed when using data from previous processes, due to the possibility of different conditions for the new process.

5.5 Evaluations

Each Failure Mode, Cause and Effect relationship (failure-chain or net) is assessed for its independent risk. There are three rating criteria for the evaluation of risk:

• Severity (S): stands for the Severity of the Failure Effect
• Occurrence (O): stands for the Occurrence of the Failure Cause
• Detection (D): stands for the Detection of the occurred Failure Cause and/or Failure Mode.

Evaluation numbers from 1 to 10 are used for S, O, and D respectively, in which 10 stands for the highest risk contribution.
NOTE: It is not appropriate to compare the ratings of one team’s FMEA with the ratings of another team’s FMEA, even if the product/process appear to be identical, since each team’s environment is unique and thus their respective individual ratings will be unique (i.e., the ratings are subjective)

5.6 Severity (S)

Severity is a rating number associated with the most serious effect for a given failure mode for the process step being evaluated. it is a relative rating within the scope of the individual FMEA and is determined without regard for Occurrence or Detection. Fer process-specific effects, the Severity rating should be determined using the criteria in evaluation Table given. The table may be augmented to include corporate or product line specific examples. The evaluations of the Failure Effects should be mutually agreed to by the customer and the organization.
NOTE: If the customer impacted by a Failure Mode is the next manufacturing or assembly plant or the product user, assessing the severity may lie outside the immediate process engineer’s team’s field of experience or knowledge. In these cases, the Design FMEA, design engineer, and/or subsequent manufacturing or assembly plant process engineer, should be consulted in order to comprehend the propagation of effects.

Process General Evaluation Criteria Severity (S)
Potential Failure Effects rated according to the criteria below.					Blank until filled in by user
S	Effect	Impact to Your Plant	Impact to Ship-to Plant  (when known)	Impact to End User (when known)	Corporate or Product Line  Examples
10	Very High	Failure may result In an acute health and/or safety risk for the  manufacturing or assembly worker	Failure may result in an acute health and/or  safety risk for the manufacturing or assembly worker	Affects safe operation of the vehicles and / or other vehicles, the health of the drivers or passengers or road users or pedestrians.
9		Failure may result in in- plant regulatory noncompliance	Failure may result in in- plant regulatory noncompliance	Noncompliance with regulations
8	High	100% of production run affected may have to be scrapped. Failure may result in in-plant regulatory noncompliance or may have a chronic health and/or safety risk for the manufacturing or assembly worker	Line shutdown greater than full production shift; stop shipment possible; field repair or replacement required (Assembly to end users) other than regulatory noncompliance or may have a chronic health and/or safety risk for the manufacturing or assembly worker	Loss of primary vehicle function necessary for normal driving during expected service life.
7		Product may have to be sorted and a portion (Less than 100%) scrapped; deviation form primary process ; decreased line speed or added manpower	Line shutdown from 1 hour up to full production shift; stop shipment possible; field repair or replacement required (Assembly to End User) other than for regulatory noncompliance	Degradation of primary vehicle function necessary for normal driving during expected service life.
6	Moderate	100% of production run may have to be reworked off line and accepted	Line shutdown up to one hour	Loss of secondary vehicle function.
5		A portion of the production run may have to be reworked off line and accepted	Less than 100% of product affected; strong possibility for additional defective product: sort required: no line  shutdown	Degradation of secondary vehicle function
4		100% of production run may have to be reworked in station before it is processed	Defective product triggers significant reaction plan; additional defective products not likely; sort not required	Very objectionable, appearance, sound, vibration, harshness. Or haptics.
3	Low	A portion of production run may have to be reworked in station before it is processed	Defective product triggers minor reaction plan; additional defective products not likely; sort not required	Moderately objectionable, appearance, sound, vibration, harshness, or haptics.
2		Slight inconvenience to process operation or operator	Defective product triggers no reaction plan; additional defective products not likely; sort not required; requires feedback to supplier	Slightly objectionable, appearance, sound, vibration, harshness, or haptics.
1	Very low	No discernible effect	No discernible effect	No discernible effect

5.7 Occurrence (O)

The Occurrence rating (O) describes the occurrence of Failure Cause in the process, taking into account the associated current prevention controls. The occurrence rating number is a relative rating within the scope of the FMEA and may not reflect the actual occurrence. The Occurrence rating describes the potential of the failure cause to occur. according to the rating table. without regard to the detection controls. Expertise or other experiences with comparable processes. for example, can be. considered in the assessment of the rating numbers. In determining this rating, questions such as the following should be considered:

• What is the equipment history with similar processes and process steps?
• What is the field experience with similar processes?
• Is the process a carryover or similar to a previous process?
• How significant are changes from a current production process?
• Is the process completely new?
• What are the environmental changes?
• Are best practices already implemented?
• Do standard instructions exist? (e.g.. work instructions. set-up and calibration procedures, preventive maintenance, error-proofing verification procedures, and process monitoring
  verification checklists)
• Are technical error-proofing solutions implemented? (e.g.,product or process design, fixture and tool design,established process sequence. production control tracking/traceability, machine capability, and SPC charting)

Occurrence Potential (O) for process
Potential Failure Causes rated according to the-criteria below. Consider Prevention Controls when determining the best Occurrence estimate. Occurrence is a predictive qualitative rating made at the time of evaluation and may not reflect the actual occurrence. The occurrence rating number is a relative rating within the scope of the in by FMEA (process being evaluated). For Prevention Controls with multiple Occurrence Ratings, use the rating that best reflects the robustness of the control.				Blank until filled in by user
O	Prediction of Failure Cause Occurring	Type of controls	Occurrence criteria – DFMEA	Corporate or Product Line  Examples
10	Extremely High	None	No prevention controls
9	Very High	Behavioural	Prevention controls will have little effect in preventing failure cause.
8
7	High	Behavioural or Technical	Prevention controls somewhat effective in preventing failure cause.
6
5	Moderate		Prevention controls are effective in preventing failure cause.
4
3	Low	Best practices: Behavioural or Technical	Prevention controls are highly effective in preventing failure cause.
2	Very low
1	Extremely low	Technical	Prevention controls are extremely effective in preventing failure cause from occurring due to design (e.g., part geometry) or process (e.g.  fixture or tooling design}. Intent of prevention controls – Failure Mode cannot be physically produced due to the Failure Cause.
Prevention Control Effectiveness: Consider if prevention controls are technical (rely on machines, tool life, tool material, etc), or use bast practices (fixtures, tool design, calibration procedures, error- proofing verification, preventive maintenance. work instructions, statistical process control charting,  process monitoring, product design, etc.) or behavioural (rely on certified or non-certified operators,  skilled trades, team leaders, etc.) when determining how effective the prevention controls will be.

5.8 Detection (D)

Detection is the rating associated with a prediction of the most effective process control from the listed detection-type process controls. Detection is a relative rating, within the scope of the individual FMEA and is determined without regard for Severity or Occurrence. Detection should be estimated using the criteria in Table given. This table may be augmented with examples of
common detection methods used by the company. The intent of the term “control discrepant product” Ranks 3 and 4 is to have controls/systems/procedures in place that controls the discrepant-product in such a manner, that the probability of the product escaping the facility is very low. The controls start from when the product is identified as discrepant to the point of final disposition. These controls usually exceed controls that are used for discrepant products with higher Detection Ranks. After implementation of any unproven control. the effectiveness can be verified and re-evaluated, in determining this estimate, questions such as the following should be considered:

• Which test is most effective in detecting the Failure Cause or the Failure Mode?
• What is the usage Profile! Duty Cycle required detecting the failure?
• What sample size is required to detect the failure?
• Is the test procedure proven for detecting this Cause-Failure Mode?

Detection Potential (D) for tile Validation of the Process Design
Detection Controls rated according to Detection Method Maturity and Opportunity for Detection.				Blank until filled in by user
D	Ability to Detect	Detection Method Maturity	Opportunity for Detection	Corporate or Product Line  Examples
10	Very Low	No testing or inspection method has been established or is known	The failure mode will not or cannot be detected
9		It is unlikely that the testing or inspection method will detect the failure mode.	The failure mode is not easily detected through random or sporadic audits.
8	Low	Test or inspection method has not been proven to be effective and reliable ( e.g., plant has little or no experience with method, gauge R & R results marginal on comparable process or this application etc.	Human inspection (visual, tactile, audible) or use of manual gauging (attribute or variable) that should detect the failure mode or failure cause
7			Machine-based detection (automated or semi-automated with notification by light, buzzer, etc}. or use of inspection equipment such as a coordinate measuring machine that should detect failure mode or failure Cause
6	Moderate	Test or inspection Method has been proven to be effective and reliable (e.g. plant has experienced with method; gauge R & R results are acceptable on comparable process or this application, etc.)	Human inspection (visual, tactile, audible), or use of manual gauging (attribute or variable) that will detect the failure mode or failure cause (including product sample checks).
5			Machine-based detection (semi-automated with notification by light, buzzer, etc), or use of Inspection equipment such as a coordinate measuring machine that will detect failure mode or failure cause {including product sample checks).
4	High	System has been proven to be effective and reliable (e.g. plant has experience with method on identical process or this application), gauge R&R results are acceptable.	Machine-based automated detection method that will detect the failure mode downstream, prevent further processing or system will identify the product as discrepant and allow it to automatically move forward in the process until the designated reject unload area. Discrepant product will be controlled by a robust system that will prevent outflow of the product from the facility.
3			Machine-based automated detection method that will detect the failure mode in-station, prevent further processing or system will identify the product as discrepant and allow it to automatically move forward in the process until the designated reject unload area. Discrepant product will be controlled by a robust system that will prevent outflow of the product from the facility.
2		Detection method has been proven to be effective and reliable (e.g. plant has experience with method, error-proofing verifications, etc}.	Machine-based detection method that will detect the cause and prevent the failure mode (discrepant part} from being produced.
1	Very High	Failure mode cannot be physically produced as-designed or processed, or detection methods proven to always detect the failure mode or failure cause.

5.9 Action Priority (AP)

Once the team has completed the initial identification of failure modes and effects, causes and controls, including ratings fer severity, occurrence. and detection, they must decide if further efforts are needed to reduce the risk. Due to the inherent limitations on resources, time, technology. and other factors, they must choose how to best prioritize these efforts. It accounts for all 1000 possible combinations of S,O, and D. it was created to give more emphasis on severity first, then occurrence,then detection. This logic follows the failure-prevention intent of FMEA. The AP table offers a suggested high-medium-low priority for action. Companies can use a single system to evaluate action priorities instead of multiple systems required from multiple customers. Risk Priority Numbers are the product of S x O x D and range from 1 to 1000. The RPN distribution can provide some information about the range of ratings, but RPN alone is not an adequate method to determine the need for more actions since RPN gives equal weight to S, O, and D. For this reason, RPN could result in similar risk numbers for very different combinations of S, O, and D leaving the team uncertain about how to prioritize. When using RPN it is recommended to use an additional method to prioritize like RPN results such as S x O. The use of a Risk Priority Number (RPN) threshold is not a recommended practice for determining the need for actions. Risk matrices can represent combinations of S and O, S and D, and O and D. These matrices provide a visual representation of the results of the analysis and can be used as an input to prioritization of actions based on company-established criteria, not included in this publication. Since the AP Table was designed to work with the Severity, Occurrence, and Detection tables provided in this handbook. if the organization chooses to modify the S,O,D. tables for specific products, processes, or projects, the AP table should also be carefully reviewed. Note: Action Priority rating tables are the same for DFMEA and PFMEA, but different for FMEA—MSR.

Priority High (H): Highest priority for review and action. The team needs to either identify an appropriate action to improve prevention and/or detection controls or justify and document why current controls are adequate.

Priority Medium (M): Medium priority for review and action. The team should identify appropriate actions to improve prevention and for detection controls, or, at the discretion of the company, justify and document why controls are adequate.
Priority Low (L): Low priority for review and action. The team could identify actions to improve prevention or detection controls, it is recommended that potential Severity 9-10 failure effects with Action Priority High and Medium, at a minimum, be reviewed by management including any recommended actions that were taken.
This is not the prioritization of High, Medium, or Low risk, it is the prioritization of the need for actions to reduce risk.
Note: It may be helpful to include a statement such as “No further action is needed” in the Remarks field as appropriate.

Action Priority (AP) for DFMEA and PFMEA
Action Priority is based on combinations of Severity, Occurrence, and Detection ratings in order to prioritize actions for risk reduction.							Blank until filled in by user
Effect	S	Prediction of Failure Cause occurring	O	Ability to detect	D	Action Priority (AP)	Comments
Product or Plant Effect Very high	9-10	Very high	8-10	Low – Very low	7-10	H
				Moderate	5-6	H
				High	2-4	H
				Very high	1	H
		High	6-7	Low – Very low	7-10	H
				Moderate	5-6	H
				High	2-4	H
				Very high	1	H
		Moderate	4-5	Low – Very low	7-10	H
				Moderate	5-6	H
				High	2-4	H
				Very high	1	M
		Low	2-3	Low – Very low	7-10	H
				Moderate	5-6	M
				High	2-4	L
				Very high	1	L
		Very low	1	Very high – Very low	1-10	L
Product or Plant Effect high	7-8	Very high	8-10	Low – Very low	7-10	H
				Moderate	5-6	H
				High	2-4	H
				Very high	1	H
		High	6-7	Low – Very low	7-10	H
				Moderate	5-6	H
				High	2-4	H
				Very high	1	M
		Moderate	4-5	Low – Very low	7-10	H
				Moderate	5-6	M
				High	2-4	M
				Very high	1	M
		Low	2-3	Low – Very low	7-10	M
				Moderate	5-6	M
				High	2-4	L
				Very high	1	L
		Very low	1	Very high – Very low	1-10	L
Product or Plant Effect Moderate	4-6	Very high	8-10	Low – Very low	7-10	H
				Moderate	5-6	H
				High	2-4	M
				Very high	1	M
		High	6-7	Low – Very low	7-10	M
				Moderate	5-6	M
				High	2-4	M
				Very high	1	L
		Moderate	4-5	Low – Very low	7-10	M
				Moderate	5-6	L
				High	2-4	L
				Very high	1	L
		Low	2-3	Low – Very low	7-10	L
				Moderate	5-6	L
				High	2-4	L
				Very high	1	L
		Very low	1	Very high – Very low	1-10	L
Product or Plant Effect low	2-3	Very high	8-10	Low – Very low	7-10	M
				Moderate	5-6	M
				High	2-4	L
				Very high	1	L
		High	6-7	Low – Very low	7-10	L
				Moderate	5-6	L
				High	2-4	L
				Very high	1	L
		Moderate	4-5	Low – Very low	7-10	L
				Moderate	5-6	L
				High	2-4	L
				Very high	1	L
		Low	2-3	Low – Very low	7-10	L
				Moderate	5-6	L
				High	2-4	L
				Very high	1	L
		Very low	1	Very high – Very low	1-10	L
No discemible effect	1	Very low- Very high	1-10	Very high – Very low	1-10	L

5.10 Collaboration between Customer and Supplier (Severity)

The output of the Risk Analysis creates the mutual understanding of technical risk between customers and suppliers. Methods of collaboration range from verbal to formal reports. The amount of information shared is based on the needs of a project, company policy, contractual agreements. and so on. The information shared depends on the placement of the company in the supply chain. Some examples are listed below.

1. The OEM may compare design functions, failure effects, and severity from a vehicle-level DFMEA with the Tier 1 supplier PFMEA.
2. The Tier 1 supplier communicates necessary information about product characteristics on product drawings and/or specifications, or other means, including designation of standard or special characteristics and severity. This information is used as an input to the Tier 2 supplier PFMEA as well as the Tier 1‘s internal PFMEA. When the design team communicates the associated risk of making product characteristics out of specification the process team can build in the appropriate level of prevention and detection controls in manufacturing.

5.11 Basis for Optimization

The output of Steps 1, 2, 3, 4, and 5 of the 7-Step FMEA process is used to determine if additional design or testing action is needed. The process reviews, customer reviews, management reviews, and cross-functional team meetings lead to Step 6 Optimization.

Step 6: Optimization.

6.1 Purpose

The purpose of the Process Optimization Step is to determine actions to mitigate risk and assess the effectiveness of these actions. The end result is a process which minimizes the risk of producing and delivering products that do not meet the customer and stakeholder expectations. The main objectives of a Process Optimization are:

• Identification of the actions necessary to reduce risks
• Assignment of responsibilities and deadlines for action I implementation
• Implementation and documentation of actions taken including confirmation of the effectiveness of the implemented actions and assessment of risk after actions taken.
• Collaboration between the FMEA team, management, customers, and suppliers regarding potential failures.
• Basis for refinement of the product and/or process requirements and prevention and detection controls

The primary objective of optimization is to develop actions that reduce risk by improving the process. In this step, the team reviews the results of the risk analysis and assigns actions to lower the occurrence of the failure cause or increase the ability to detect the failure cause or failure mode. Actions may also be assigned which improve the process but do not necessarily lower the risk assessment rating. Actions represent a commitment to take a specific, measurable, and achievable action, not potential actions which may never be implemented. Actions are not intended to be used for activities that are already planned as these are documented in the Prevention or Detection Controls, and are already considered in the initial risk analysis. All actions
should have a responsible individual and a target completion time associated with the action. If the team decides that no further actions are necessary, “No further action is needed“ is written in the Remarks field to show the risk analysis was completed. The PFMEA can be used as the basis for continuous improvement of the process. The optimization is most effective in the following order:

• Process modifications to eliminate or mitigate a Failure Effect (FE)
• Process modifications to reduce the Occurrence (O) of the Failure Cause (FC).
• Increase the Detection (D) ability fer the Failure Cause (FC) or Failure Mode (FM).
• In the case of process modifications, all impacted process steps are evaluated again.

In the case of concept modifications. all steps of the FMEA are reviewed for the affected sections. This is necessary because the original analysis is no longer valid since it was based upon a different manufacturing concept. The PFMEA can be used as the basis for continuous improvement of the process.

6.2 Assignment of Responsibilities

Each action should have a responsible individual and a Target Completion Date (TCD) associated with it. The responsible person ensures the action status is updated. If the action is confirmed this person is also responsible for the action implementation. The Actual Completion Date for Preventive and Detection Actions is documented including the date the actions are implemented.
Target Completion Dates should be realistic (i.e., in accordance with the product development plan. prior to process validation prior to start of production).

6.3 Status of the Actions

Suggested levels for Status of Actions:

• Open: No action defined.
• Decision pending (optional): The action has been defined but has not yet decided on. A
  decision paper is being created.
• Implementation pending (optional): The action has been decided on but not yet implemented.
• Completed: Completed actions have been implemented and their effectiveness has been demonstrated and documented. A final evaluation has been done.
• Not Implemented: Not Implemented status is assigned when a decision is made not to implement an action. This may occur when risks related to practical and technical limitations are beyond current capabilities.

The FMEA is not considered “complete” until the team assesses. each item’s Action Priority and either accepts the level of risk or documents closure of all actions. If “No Action Taken,” then Action Priority is not reduced, and the risk of failure is carried forward into the product. Actions are open loops that need to be closed in writing.

6.4 Assessment of Action Effectiveness

When an action has been completed, Occurrence. and Detection values are reassessed. and a new Action Priority may be determined. The new action receives a preliminary Action Priority rating as a prediction of effectiveness. However. the status of the action remains “implementation pending” until the effectiveness has been tested. After the tests are finalized the preliminary rating has to be confirmed or adapted, when indicated. The status of the action is then changed from “implementation pending” to “completed.” The reassessment should be based on the effectiveness of the Preventive and Detection Actions taken and the new values are based on the definitions in the Process FMEA Occurrence and Detection rating tables.

6.5 Continual Improvement

The PFMEA serves as a historical record for the process. Therefore, the original Severity, Occurrence, and Detection (S, O, D) numbers need to be visible or at a minimum available and accessible as part of version history. The completed analysis becomes a repository to capture the progression of process decisions and design refinements. However, original S, O, D ratings may be. modified for foundation, family or generic PFMEA’s because the information is used as a starting point for an process specific analysis.

6.6 Collaboration between the FMEA team, Management, Customers, and Suppliers regarding Potential Failures:

Communication between the FMEA team, management, customers and suppliers during the development of the technical risk analysis and/or when the PFMEA is initially complete brings people together to improve their understanding of product and process functions and failures. In this way, there is a transfer of knowledge that promotes risk reduction.

Step 7: Results Documentation

7.1 Purpose

The purpose of the results documentation step is to summarize and communicate the results of the Failure Mode and Effects analysis activity. The main objectives of Process Results Documentation are:

• Communication of results and conclusions of the analysis
• Establishment of the content of the documentation
• Documentation of actions taken including confirmation of the effectiveness of the implemented actions and assessment of risk after actions taken
• Communication of actions taken to reduce risks, including within the organization. and with customers and/or suppliers as appropriate
• Record of risk analysis and risk reduction to acceptable levels.

7.2 FMEA Report

The-scope and results of an FMEA should be summarized in a report. The report can he used for communication purposes within a company, or between companies. The report is not meant to replace reviews of the PFMEA details when requested by management, customers, or suppliers. It is meant to be a summary for the PFMEA team and others to confirm completion of each of the tasks and review the results of the analysis. It is important that the content of the documentation fulfills the requirements of the organization, the intended reader, and relevant stakeholders. Details may be agreed upon between the parties. In this way. it is also ensured that all details of the analysis and the intellectual property remain at the developing company. The layout of the document may be company specific. However, the report should indicate the technical risk of failure as a part of the development plan and project milestones. The content may include the following:

1. A-statement of final status compared to original goals established in the Project Plan
   • FMEA Intent-Purpose of this FMEA?‘
   • FMEA Timing- FMEA due date?
   • FMEA Team- List of participants?
   • FMEA Task- Scope of this FMEA?
   • FMEA Tool- How do we conduct the analysis Method used?
2. A summary of_the scope of the analysis and identify what is new.
3. A summary of how the functions were developed.
4. A summary of at least the high-risk failures as determined by the team and provide a copy of the specific S/O/D rating tables and method of action prioritization (i.e., Action Priority table).
5. A summary of the actions taken and/or planned to address the high-risk failures including status of those actions.
6. A plan and commitment of timing for ongoing FMEA improvement actions.
   • Commitment and timing to close open actions.
   • Commitment to review and revise the PFMEA during mass production to ensure the accuracy and completeness of the analysis as compared with the production design (e.g. revisions triggered from design changes, corrective actions. etc., based on company procedures).
   • Commitment to capture “things gone wrong” in foundation PFMEA’s for the benefit of future analysis reuse, when applicable.

PFMEA Form Sheet Hints: Step 7

PFMEA Step 7 is independently handled by each organization and is not recorded on the PFMEA form sheet.