In a Supplemental FMEA for Monitoring and System Response, potential Failure Causes which might occur under customer operating conditions are analyzed with respect to their technical effects on the system, vehicle, people, and regulatory compliance. The method considers whether or not Failure Causes or Failure Modes are detected by the system, or Failure Effects are detected by the driver. Customer operation is to be understood as end-user operation or in-service operation and maintenance operations.
FMEA-MSR includes the following elements of risk:

1. Severity of harm regulatory noncompliance. loss or degraded functionality. and unacceptable quality; represented by (S)
2. Estimated frequency of a Failure Cause in the context of an operational situation; represented by (F)
3. Technical possibilities to avoid or limit the Failure Effect via diagnostic detection and automated response, combined with human possibilities to avoid or limit the Failure Effect via sensory perception and physical reaction; represented by (M)

The combination of F and M is an estimate of the probability of occurrence of the Failure Effect due to the Fault (Failure Cause), and resulting malfunctioning behavior (Failure Mode).
NOTE: The overall probability of a Failure Effect to occur may be higher, because different Failure Causes may lead to the same Failure Effect.
FMEA-MSR adds value by assessing risk reduction as a result of monitoring and response. FMEA-MSR evaluates the current state of risk of failure and derives the necessity for additional monitoring by comparison with the conditions for acceptable residual risk.
The analysis can be part of a Design FMEA in which the aspects of Development are supplemented by aspects of Customer Operation. However. it is usually only applied when diagnostic detection is necessary to maintain safety or compliance. Detection in DFMEA Is not the same as Monitoring in Supplemental FMEA- MSR. In DFMEA Detection controls document the ability of testing to demonstrate the fulfillment of requirements in development and validation. For monitoring that is already part of the system design, validation is intended to demonstrate that diagnostic monitoring and system response works as intended. Conversely, Monitoring in FMEA-MSR assesses the effectiveness of fault detection performance in customer operation, assuming that specifications are fulfilled. The Monitoring rating also comprehends the safe performance and reliability of system reactions to monitored faults. It contributes to the assessment of the fulfillment of Safety Goals and may be used for deriving the Safety Concept. Supplemental FMEA-MSR addresses risks that in DFMEA would otherwise be assessed as High, by considering more factors which accurately reflect lower assessed risk according to the diagnostic functions of the vehicle operating system. These additional factors contribute to an improved depiction of risk of failure (including risk of harm, risk of noncompliance, and risk of not fulfilling specifications). FMEA-MSR contributes to the provision of evidence of the ability of the diagnostic, logical, and actuation mechanisms to achieve and maintain a safe or compliant state (in particular, appropriate failure mitigation ability within the maximum fault handling time interval and within the fault tolerant time interval). FMEA—MSR evaluates the current state of risk of failure under and user conditions (not just risk of harm to persons). The detection of faults/failures during customer operation can be used to avoid the original failure effect by switching to a degraded operational state (including disabling the vehicle), informing the driver and/or writing a diagnostic trouble code (DTC) into the control unit for service purposes. In terms of FMEA, the result of RELIABLE diagnostic detection and response is to eliminate (prevent) the original effect and replace it with a new, less severe effect. FMEA—MSR is useful in deciding whether the system design fulfills the performance requirements with respect to safety and compliance. The results may include items such as:

• additional sensor(s) may be needed for monitoring purposes
• redundancy in processing may be needed
• plausibility checks may reveal sensor malfunctions

Step 1: Planning and Preparation

1.1 Purpose

The main objectives of Planning and- Preparation in FMEA-MSR 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
• Basis for the Structure Analysis step

1.2 FMEA-MSR Project Identification and Boundaries

FMEA—MSR project identification includes a clear understanding of what needs to be evaluated. This involves a decision-making process to define the FMEA—MSRs that are needed for a customer program. What to exclude can be just as important as what to include in the analysis. The following may assist the team. in defining FMEA-MSR projects, as applicable:

• Hazard Analysis and Risk Assessment.
• 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

Answers to these questions and others defined by the company help create the list of FMEA-MSR projects needed. The FMEA- MSR project list assures consistent direction, commitment and
focus. Below are some basic questions that help identify FMEA-MSR boundaries:

1. After completing a DFMEA on an Electrical/Electronic/Prograrnmable Electronic System, are there effects that may be harmful to persons or involve regulatory noncompliance?
2. Did the DFMEA indicate that all of the causes which lead to harm or noncompliance can be detected by direct sensing. and/or plausibility algorithms?
3. Did the DFMEA indicate that the intended system response to any and all of the detected causes is to switch to a degraded operational state (including disabling the vehicle]. inform the driver and/or write a Diagnostic Trouble Code (DTC) into the control unit for service purposes?

FMEA for Monitoring and System Response may be used to examine systems which have integrated fault monitoring and response mechanisms during operation. Typically, these are more complex systems composed of sensors. actuators and logical processing units. The diagnosis and monitoring in such systems, may be achieved through hardware and, or software. Systems that may be considered in a Supplemental FMEA for Monitoring and System Response consist in general of at least a sensor, a control unit, and an actuator or a subset of them and are called mechatronic systems. Systems in-scope may also consist of mechanical hardware components (e.g., pneumatic and hydraulics).

The scope of a Supplemental FMEA for Monitoring and System Response may be established in consultation between customer and supplier. Applicable scoping criteria may include, but are not limited to:

• System Safety relevance
• ISO Standards, i.e., Safety Goals according to ISO 26262
• Documentation requirements from legislative bodies e.g., UN/ECE Regulations, FMVSS/CMVSS, NHTSA, and On Board Diagnostic Requirements (OBD) Compliance.

1.3 FMEA-MSR Project Plan

A plan for the execution of the FMEA-MSR should be developed once the FMEA-MSR project is known. It is recommended that the 5T method (Intent, Timing, Team, Tasks. Tool) be used. The plan for the FMEA-MSR helps the company be proactive in starting the FMEA-MSR early. The FMEA-MSR activities (5-step process) should be incorporated into the overall design project plan.

Step 2 : Structure Analysis

2.1 Purpose

The main objectives of Structure Analysis in FMEA—MSR are:

• Visualization of the analysis scope
• Structure tree or equivalent: block diagram, boundary diagram, digital model, physical parts
• Identification of design interfaces, interactions
• Collaboration between customer and supplier engineering teams (interface responsibilities)
• Basis for the Function Analysis step

Depending on the scope of analysis, the structure may consist of hardware elements and software elements. Complex structures may be split into several structures (work packages) or different layers of block diagrams and analyzed separately for organizational reasons or to ensure sufficient clarity. The scope of the FMEA—MSR is limited to the elements of the system for which the baseline DFMEA showed that there are causes of failure which can result in hazardous or non-compliant effects. The scope may be expanded to include signals received by the control unit. In order to visualize a system structure, two methods are commonly used:

• Block (Boundary) Diagrams
• Structure Trees

2.2 Structure Trees

In a Supplemental FMEA for Monitoring and System Response, the root element of a structure tree can be at vehicle level, i.e. for OEMs which analyze the overall system or at the system level, i.e. for suppliers which analyze a subsystem or component .

The sensor element and the control unit may also be part of one component (smart sensor). Diagnostics and monitoring in such systems may be realized by hardware and/or software elements.

In case there is no sensor within the scope of analysis, an Interface Element is used to describe the data/current/voltage received by the ECU. One function of any ECU is to receive signals via a connector. These signals can be missing or erroneous. With no monitoring, you get erroneous output. In case there is no actuator within the scope of analysis, an Interface Element is used to describe the data/current/voltage sent by the ECU. Another function of any ECU is to send signals. i.e. via a connector. These signals can also be missing or erroneous. It can also be “no output” or “failure information.” The causes of erroneous signals may be within a component which is outside the scope of responsibility of the engineer or organization. These erroneous signals may have an effect on the performance of a component which is within the scope of responsibility of the engineer or organization. It is therefore necessary to include such causes in the FMEA-MSR analysis.
NOTE: Ensure that the structure is consistent with the Safety Concept (as applicable).

STRUCTURE ANALYSIS (STEP 2)
1. Next Higher Level	2 Focus Element	3. Next lower level or characteristic Type
Window Lift System	ECU Window Lifter	Connector ECU Window Lifter

Step 3 : Function Analysis

The main objectives of Function Analysis in FMEA-MSR are:

• Visualization of functions and relationships between functions in Function tree/ function net, or equivalent parameter diagram (P—diagram)
• Cascade of customer (external and internal) functions with associated requirements
• Association of requirements or characteristics to functions
• Collaboration between engineering teams (systems, safety, and components)
• Basis for the Failure Analysis step

In a Supplemental FMEA for Monitoring and System Response, monitoring for failure detection and failure responses are considered as functions. Hardware and software functions may include monitoring of system states. Functions for monitoring and detection of faults/failures may consist of, for example: out of range detection, cyclic redundancy checks, plausibility checks and sequence counter checks. Functions for failure reactions may consist of, for example, provision of default values, switching to a limp home mode, switching off the corresponding function and/or display of a warning. Such functions are modeled for these structural elements that are carriers of these functions, i.e., control units or components with computational abilities like smart sensors. Additionally, sensor signals can be considered which are received by control units. Therefore, functions of signals may be described as well. Finally, functions of actuators can be added, which describe the way the actuator or vehicle reacts on demand. Performance requirements are assumed to be the maintenance of a safe or compliant state. Fulfillment of requirements is assessed through the risk assessment. in case sensors and/or actuators are not within the scope of analysis, functions are assigned to the corresponding interface- elernents (consistent with the Safety Concept-as applicable).

FUNCTION ANALYSIS (STEP 3)
1. Next Higher Level Function and Requirement	2 Focus Element Function and Requirement	3. Next lower level Function and Requirement  or characteristic Type
Provide anti-pinch protection for comfort closing mode	Provide signal to stop and reverse window lifter motor in case of pinch situation	Transmit signal from Hall effect sensor to ECU

Step 4: Failure Analysis

4.1 Purpose

The purpose of Failure Analysis in FMEA-MSR is to-describe the chain of events which lead up to the end effect, in the context of a relevant scenario. The main objectives of Failure Analysis in FMEA-MSR are:

• Establishment of the failure chain
• Potential Failure Cause, Monitoring, System Response,Reduced Failure Effect.
• Identification of product Failure Causes using a parameter diagram 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

4.2 Failure Scenario

A Failure Scenario is comprised of a description of relevant operating conditions in which a fault results in malfunctioning behavior and possible sequences of events (system states) that lead to an and system state (Failure Effect). It starts from defined Failure Causes and leads to the Failure Effects.

The focus of the analysis is a component with diagnostic capabilities, e.g., an ECU. If the component is not capable of detecting the fault/failure, the Failure Mode will occur which leads to the end effect with a corresponding degree of Severity. However, if the component can detect the failure, this leads to a system response with a Failure Effect with a lower Severity compared to the original Failure Effect. Details are described in the following scenarios (1) to (3).

Failure Scenario (1) describes the malfunctioning behavior from the occurrence of the fault to the Failure Effect, which in this example is not hazardous but may reach a non-compliant end system state.

Failure Scenario (2) describes the malfunctioning behavior from the occurrence of the fault to the Failure Effect, which in this example leads to a hazardous event. As an aspect of the Failure Scenario, it is necessary to estimate the magnitude of the Fault Handling Time Interval (time between the occurrence of the fault, and the occurrence of the hazard/non-compliant Failure Effect). The Fault Handling Time Interval is the maximum time span of malfunctioning behavior before a hazardous event occurs, if the safety mechanisms are not activated.

Failure Scenario (3) describes the malfunctioning behavior from the occurrence of the fault to the mitigated Failure Effect, which in this example leads to a loss or degradation of a function instead of the hazardous event.

4.3 Failure Cause

The description of the Failure Cause is the starting point of the Failure Analysis in a Supplemental FMEA for Monitoring and System Response. The Failure Cause is assumed to have occurred and is not the true Failure Cause (root cause). Typical Failure Causes are electrical/electronic faults (E/E faults). Root causes may be insufficient robustness when exposed to various factors such as the external environment, vehicle dynamics, wear, service, stress cycling, data bus overloading, and erroneous signal states etc. Failure Causes can be derived from the DFMEA, catalogues for failures of E/E components, and network communication data descriptions.

NOTE: In FMEA-MSR, diagnostic monitoring is assumed to function as intended. (However, it may not be effective.) Therefore, Failure Causes of diagnostics are not part of FMEA—MSR but can be added to the DFMEA section of the form sheet. These include Failed to detect fault; Falsely detected fault (nuisance); Unreliable fault response (variation in response capability).

Teams may decide not to include failures of diagnostic monitoring in DFMEA because Occurrence ratings are most often very low (including “latent faults” Ref. ISO 26262). Therefore. this analysis may be of limited value. However, the correct implementation of diagnostic monitoring should be part of the test protocol. Prevention Controls of diagnostics in a DFMEA describe how reliable a mechanism is estimated to detect the Failure Cause and reacts on time with respect to the performance requirements. Detection Controls of diagnostics in a DFMEA would relate back to development tests which verify the correct implementation and the effectiveness of the monitoring mechanism.

4.4 Failure Mode

A Failure Mode is the consequence of the fault (Failure Cause). In FMEA-MSR two possibilities are considered:

1. In case of failure scenarios (1) and (2) the fault is not detected or the system reaction is too late. Therefore, the Failure Mode in FMEA-MSR is the same as in DFMEA.
2. Different is failure scenario (3), where the fault is detected and the system response leads to a mitigated Failure Effect. In this case a description for the diagnostic monitoring and system response is added to the analysis. Because the failure chain in this specific possibility consists of a fault/failure and a description of an intended behavior, this is called a hybrid failure chain or hybrid failure network

4.5 Failure Effect

A Failure Effect is defined as the consequence of a Failure Mode. Failure Effects in FMEA-MSR are either a malfunctioning behavior of the system or an intended behavior after detection of a Failure Cause. The end effect may be a “hazard” or “non-compliant state” or, in case of detection and timely system response, a “safe state” or”compliant state” with loss or degradation of a function. The severity of Failure Effects is evaluated on a ten-point scale

FAILURE ANALYSIS (STEP 4)
Failure Effect (FE) to the  Next Higher Level Element and/ or End User	2 Failure Mode (FM) of the Focus Element	3. Failure Cause (FC) of theNext lower level Element  or characteristic
No anti-pinch protection in comfort closing mode. {Hand or neck may be pinched between window glass and frame]	No signal to stop and reverse window lifter motor in case of pinch situation	Signal of Hall effect sensor is not transmitted to ECU due to  poor connection of Hail effect Sensor

Step 5: Risk Analysis

5.1 Purpose

The purpose of Risk Analysis in FMEA-MSR is to estimate risk of failure by evaluating Severity, Frequency, and Monitoring. and prioritize the need for actions to reduce risk. The main objectives of the FMEA-MSR 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, Frequency and Monitoring for each failure chain.
• Evaluation of Action Priority
• Collaboration between customer and supplier (Severity).
• Basis for the Optimization step.

5.2 Evaluations

Each Failure Mode, Cause and Effect relationship (failure chain or hybrid network) is assessed by the following three criteria:

• Severity (S): represents the Severity of the Failure Effect
• Frequency (F): represents the Frequency of Occurrence of the Cause in a given operational situation, during the intended service life of the vehicle
• Monitoring (M): represents the Detection potential of the Diagnostic Monitoring functions (detection of Failure Cause, Failure Mode and/or Failure Effect)

Evaluation numbers from 1 to 10 are used for S, F, and M respectively. where 10 stands for the highest risk contribution. By examining these ratings individually and in combinations of the three factors the need for risk-reducing actions may be prioritized.

5.3 Severity (S)

The Severity rating (S) is a measure associated with the most serious Failure Effect for a given Failure Mode of the function being evaluated and is identical for DFMEA and FMEA-MSR. Severity should be estimated using the criteria in the Severity Table . The table may be augmented to include product- specific examples. The FMEA project team should agree on an evaluation criteria and rating system, which is consistent even if modified for individual design analysis. The Severity evaluations of the Failure Effects should be transferred by the customer to the supplier, as needed.

Product General Evaluation Criteria Severity (S)
Potential Failure Effects rated according to the criteria below.			Blank until filled in by user
S	Effect	Severity criteria	Corporate or Product Line  Examples
10	Very High	Affects safe operation of the vehicle and/or other vehicles, the health of driver or passengers or road users or pedestrians.
9		Noncompliance with regulations.
8	High	Loss of primary vehicle function necessary for normal driving during expected service life.
7		Degradation of primary vehicle function necessary for normal driving during expected service life.
6	Moderate	Loss of secondary vehicle function.
5		Degradation of secondary vehicle function.
4		Very objectionable appearance, sound, vibration, harshness, or haptics.
3	Low	Moderately objectionable appearance, sound, vibration, harshness, or haptics.
2		Slightly objectionable appearance, sound, vibration, harshness, or haptics.
1	Very low	No discernible effect

5.4 Rationale for Frequency Rating

In a Supplemental FMEA for Monitoring and System Response, the likelihood of a failure to occur in the field under customer operating conditions during service life is relevant. Analysis of end user operation requires assumptions that the manufacturing process is adequately controlled in order to assess the sufficiency of the design. Examples on which a rationale may be. based on:

• Evaluation based on the results of Design FMEAs
• Evaluation based on the results of Process FMEAs
• Field data of returns and rejected parts
• Customer complaints
• Customer complaints
• Warranty databases
• Data handbooks

The rationale is documented in the column “Rationale for Frequency Rating“ of the FMEA-MSR form sheet.

5.5 Frequency (F)

The Frequency rating (F) is a- measure of the likelihood of occurrence of the cause in relevant operating situations during the intended service life of the vehicle or the system using the criteria in Table below. If the Failure Cause does not always lead to the associated Failure Effect, the rating may be adapted. taking into account the probability of exposure to the relevant operating condition. In such cases the operational situation and the rationale are to be stated in the column “Rationale for Frequency Rating.”
Example: From field data it is known how often a control unit is defective in ppm/year. This may lead to F=3. The system under investigation is a parking system which is used only a very limited
time in comparison to the overall operating time. So harm to persons is only possible when the defect occurs during the parking maneuver. Therefore, Frequency may be lowered to F=2.

Frequency Potential (F) for the Product
Frequency criteria (F) for the estimated occurrence of the Failure Cause in relevant operating situations during the intended service life of the vehicle				Blank until filled in by user
F	Estimated Frequency	Frequency criteria — FMEA-MSR		Corporate or Product Line  Examples
10	Extremely High or cannot be determined	Frequency of occurrence of the Failure Cause is unknown or known to be unacceptably high during the intended  service life of the vehicle
9	High	Failure Cause is likely to occur during the intended service  life of the vehicle
8		Failure Cause may occur often in the field during the  intended service life of the vehicle
7	Medium	Failure Cause may occur frequently in the field during the intended service life of the vehicle
6		Failure Cause may occur somewhat frequently in the field during the intended service life of the vehicle
5		Failure Cause may occur Occasionally  in the field during the intended service life of the vehicle
4	low	Failure Cause is predicted to occur rarely in the field during the intended service life of the vehicle. At least ten occurrences in the field are predicted.
3	Very Low	Failure Cause is predicted to occur in isolated cases in the field during the intended service life of the vehicle. At least one occurrence in the field is predicted.
2	Extreme Low	Failure Cause is predicted not to occur in the field during the intended service life of the vehicle based on prevention and detection controls and field experience with similar parts. Isolated cases cannot be ruled out. No proof it will not happen.
1	Cannot occur	Failure Cause cannot occur during the intended service life of the vehicle or is virtually eliminated. Evidence that Failure Cause cannot occur. Rationale is documented.
Percentage of relevant operating condition in comparison to overall operating time			Value by which F may be lowered
< 10%			1
< 1%			2

Note:

1. Probability increases as number of vehicles are increased
2. Reference value for estimation is one. million vehicles in a the field

5.6 Current Monitoring Controls

All controls that are planned or already implemented and lead to a detection of the Failure Cause, the Failure Mode or the Failure Effect by the system or by the driver are entered into the “Current Monitoring Controls” column. In addition, the fault reaction after-detection should be described. i.e. provision of default values, (if not already sufficiently described by the Failure Effect). Monitoring evaluates the potential that the Failure Cause, the Failure Mode or the Failure Effect can be detected early enough, so that the initial Failure Effect can be mitigated before a hazard occurs or a non-compliant state is reached. The result is an end state effect with a lower severity.

5.7 Monitoring (M)

The Monitoring rating (M) is a measure of the ability of detecting a fault/failure during customer operation and applying the fault reaction in order to maintain a safe or compliant state. The Monitoring Rating relates to the combined ability of all sensors, logic, and human sensory perception to detect the fault/failure; and react by modifying the vehicle behavior by means of mechanical actuation and physical reaction (controllability). In order to maintain a safe or compliant state of operation, the sequence of fault detection and reaction need to take place before the hazardous or non-compliant effect occurs. The resulting rating describes the ability to maintain a safe or compliant state of operation. Monitoring is a relative rating within the scope of the individual FMEA and is determined without regard. for severity or frequency. Monitoring should be estimated using the criteria in Table below. This table may be augmented with examples of common monitoring. The FMEA project team should agree on an evaluation criteria and rating system which is consistent, even if modified for individual product analysis. The assumption is that Monitoring is implemented and tested as designed. The effectiveness of Monitoring depends on the design of the sensor hardware. sensor redundancy, and diagnostic algorithms that are implemented. Plausibility metrics alone are not considered to be effective. Implementation of monitoring and the verification of effectiveness should be part of the development process and therefore may be analyzed in the corresponding DFMEA of the product. The effectiveness of diagnostic monitoring and response, the fault monitoring response time. and the Fault Tolerant Time Interval need to be determined prior to rating. Determination of the effectiveness of diagnostic monitoring is addressed in detail in ISO 26262-5:2018 Annex D.
In practice. three different monitoring/response cases may be distinguished:

If there is no monitoring control. or if monitoring and response do not occur within the Fault Handling Time Interval, then Monitoring should be rated as Not Effective (M=10).

The original Failure Effect is virtually eliminated. Only the mitigated Failure Effect remains relevant for the risk estimation of the product or system in this instance only. the mitigated FE is
relevant for the Action Priority rating, not the original FE. The assignment of Monitoring Ratings to Failure Causes and their corresponding Monitoring Controls can vary depending on:

• Variations in the Failure Cause or Failure Mode
• Variations in the hardware implemented for diagnostic monitoring
• The execution timing of the safety mechanism. i.e., failure is detected during “power up” only
• Variations in system response
• Variations in human perception and reaction
• Knowledge of implementation and effectiveness from other projects (newness)

Depending on these Variations or execution timing, Monitoring Controls may not be considered to be RELIABLE in the sense of M=1.

The original Failure Effect occurs less often. Most of the failures are detected and the system response leads to a mitigated Failure Effect. The reduced risk is represented by the Monitoring rating. The most serious Failure Effect remains S=10.

Supplemental FMEA for Monitoring and System Response (M)
Monitoring Criteria (M) for Failure Causes, Failure Modes and Failure Effects by Monitoring during Customer Operation. Use the rating number that corresponds with the least effective of either criteria for Monitoring or System Response				Blank until filled in by user
M	Effectiveness of Monitoring Control and system response	Diagnostic Monitoring/ Sensory Perception criteria	System Response /Human Reaction Criteria		Corporate or Product Line  Examples
10	Not effective	The fault/failure cannot be detected at all or not during the Fault Handling Time Interval; by the system, the driver, passenger, or service technician.	No response during the Fault Handling Time Interval
9	Very low	The fault/failure can almost never be detected in relevant operating conditions. Monitoring control with low effectiveness, high variance, or high uncertainty. Minimal diagnostic coverage.	The reaction to the fault/failure by the system or the driver may not reliably occur during the Fault Handling Time Interval
8	Low	The fault/failure can be detected in very few relevant operating conditions. Monitoring control with low effectiveness, high variance, or high uncertainty. Diagnostic coverage estimated <60%.	The reaction to the fault/failure by the system or the driver may not always occur during the Fault Handling Time Interval
7	Moderately Low	Low probability of detecting the fault/failure during the Fault Handling Time Interval by the system or the driver. Monitoring control with low effectiveness, high variance, or high uncertainty. Diagnostic coverage estimated >60%.	Low probability of reacting to the detected fault/failure during the Fault Handling Time Interval by the system or the driver
6	Moderate	The fault/failure will be automatically detected by the system or the driver only during power-up, with medium variance in detection time. Diagnostic coverage estimated >90%.	The automated system or the driver will be able to react to the detected fault/failure in many operating conditions.
5		The fault/failure will be automatically detected by the system during the Fault Handling Time Interval, with medium variance in detection time or detected by the driver in very many operating conditions. Diagnostic coverage estimated between 90% – 97%.	The automated system or the driver will be able to react to the detected fault/failure during the Fault Handling Time Interval in a very many operating conditions
4	Moderately High	The fault/failure will be automatically detected by the system during the Fault Handling Time Interval, with medium variance in detection time or detected by the driver in most operating conditions. Diagnostic coverage estimated > 97%.	The automated system or the driver will be able to react to the detected fault/failure during the Fault Handling Time Interval in a most operating conditions
3	High	The fault/failure will be automatically detected by the system during the Fault Handling Time Interval, with very low variance in detection time and with high Probability. Diagnostic coverage estimated > 99%.	The system will automatically react to the detected fault/failure during the Fault Handling Time Interval in a most operating conditions with very low variance in system response time, and with a high probability.
2	Very High	The fault/failure will be automatically detected by the system during the Fault Handling Time Interval, with very low variance in detection time and with very high Probability. Diagnostic coverage estimated > 99.9%.	The system will automatically react to the detected fault/failure during the Fault Handling Time Interval in a most operating conditions with very low variance in system response time, and with a very high probability.
1	Reliable and acceptable for elimination of original failure effect	The fault/failure will always be automatically detected by the system. Diagnostic coverage estimated to be significantly greater then 99.9%.	The system will always automatically react to the detected fault/failure during the Fault Handling Time Interval

5.8 Action Priority (AP) for FMEA-MSR

The Action Priority is a methodology which allows for the prioritization of the need for action, considering Severity, Frequency, and Monitoring (SFM). This is done by the assignment of SFM ratings which provide a basis for the estimation of risk.

• Priority High (H): Highest priority for review and action. The team needs to either identify an appropriate action to lower frequency and/or to improve monitoring 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 lower frequency and/or to improve monitoring 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 lower
• frequency and/or to improve monitoring 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.

Auction Priority is based on combinations of Severity, Frequency, and monitoring ratings- in order to prioritize actions for risk reduction.
Effect	S	Prediction of Failure Cause occurring during service life of vehicle	F	Effectiveness of Monitoring	M	Action Priority (AP)
Product or Plant Effect Very high	10	Medium-Extremely High	5-10	Reliable – Not effective	1-10	H
		Low	4	Moderately high – Not effective	4-10	H
				Very high – High	2-3	H
				Reliable	1	M
		Very low	3	Moderately high – Not effective	4-10	H
				Very high – High	2-3	M
				Reliable	1	L
		Extremely low	2	Moderately high – Not effective	4-10	M
				Reliable- high	1-3	L
		Cannot occur	1	Reliable – Not effective	1-10	L
Product Effect high	9	Low – Extremely high	4-10	Reliable – Not effective	1-10	H
		Extremely low –Very low	2-3	Very High – Not effective	2-10	H
				Reliable- high	1-3	L
		Cannot occur	1	Reliable – Not effective	1-10	L
Product Effect Moderately high	7-8	Medium-Extremely High	6-10	Reliable – Not effective	1-10	H
		Medium	5	Moderately high – Not effective	5-10	H
				Reliable- Moderately high	1-4	M
		low	4	Moderately low – Not effective	7-10	H
				Moderately High- Moderate	4-6	M
				Reliable -High	1-3	L
		Very low	3	Very low – Not effective	9-10	H
				Moderately low-Low	7-8	M
				Reliable -Moderate	1-6	L
		Extreme Low	2	Moderately low – Not effective	7-10	M
				Reliable -Moderate	1-6	L
		Cannot occur	1	Reliable – Not effective	1-10	L
Product or  Effect Moderately low	4-6	High-Extremely High	7-10	Reliable – Not effective	1-10	H
		Medium	5-6	Moderate – Not effective	6-10	H
				Reliable –Moderately High	1-5	M
		Extremely low- Low	2-4	Very low – Not effective	9-10	M
				Moderately High- Moderate	7-8	M
				Reliable -Moderate	1-6	L
		Cannot occur	1	Reliable – Not effective	1-10	L
Product  Effect low	2-3	High-Extremely High	7-10	Reliable – Not effective	1-10	H
		Medium	5-6	Moderately low – Not effective	7-10	M
				Reliable -Moderate	1-6	L
		Extremely low- Low	2-4	Reliable -Moderate	1-6	L
		Cannot occur	1	Reliable – Not effective	1-10	L
Product effect very low	1	Very low- Very high	1-10	Reliable – Not effective	1-10	L

• NOTE 1: If M=1, the Severity rating of the Failure Effect after Monitoring and System Response is to be used for determining MSR Action Priority. If M is not equal to 1, then the Severity Rating of the original Failure Effect is to be used for determining MSR Action Priority.
• NOTE 2: When FMEA—MSR is used. and M=1, then DFMEA Action Prioritization replaces the severity rating of the original Failure Effect with the Severity rating of the mitigated Failure Effect.

Step 6: Optimization

6.1 Purpose

The primary objective of Optimization in FMEA-MSR is to develop actions that reduce risk and improve safety. In this step, the team reviews the results of the risk analysis and evaluates action priorities. The main objectives of FMEA-MSR Optimization are:

• Identification of the actions necessary to reduce risks
• Assignment of responsibilities and target completion dates for action 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 requirements and prevention/detection controls

High and medium action priorities may indicate a need for technical improvement. Improvements may be achieved by introducing more reliable components which reduce the occurrence potential of the Failure Cause in the field or introduce additional monitoring which improve the detection capabilities of the system. Introduction of monitoring is similar to design change. Frequency of the Failure Cause is not changed. It may also be possible to eliminate the Failure Effect by introducing redundancy. 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 optimization is most effective in the following order:

• Component design modifications in order to reduce the Frequency (F) of the Failure Cause (FC)
• Increase the Monitoring (M) ability for the Failure Cause (FC) or Failure Mode (FM).

In the case of design modifications. all impacted design elements 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 design concept.

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 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. Closure of all actions should be documented before the FMEA is released at Start of Production (SOP). If “No Action Taken”, then Action Priority is not reduced and the risk of failure is carried forward into the product design.

6.4 Assessment of Action Effectiveness

When an action has been completed, Frequency, and Monitoring 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 MSR Preventive and Diagnostic Monitoring Actions taken and the new values are based on the definitions in the FMEA-MSR Frequency and Monitoring rating tables.

6.5 Continuous Improvement

FMEA—MSR serves as an historical record for the design. Therefore. the original Severity. Frequency, and Monitoring (S, F, M) numbers are not modified once actions have been taken. The completed analysis becomes a repository to capture the progression of design decisions and design refinements. However, original S, F, M ratings may be modified for basis, family or generic DFMEAs because the information is used as a starting point for an application-specific analysis.

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 FMEA – MSR 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 reduction to acceptable levels

7.2 FMEA Report

The scope and results of an FMEA should be summarized in a report. The report can be used for communication purposes within a company, or between companies. The report is not meant to replace reviews of the FMEA-MSR details when requested by management, customers, or suppliers. It is meant to be a summary for the FMEA-MSR 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 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/F/M rating tables and method of action prioritization (e.g. 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 FMEA-MSR during mass production to ensure the accuracy and completeness of the analysis as compared with the original production design (e.g. revisions triggered from design changes, corrective actions, etc., based on company procedures).
   • Commitment to capture “things gone wrong” in foundation FMEA-MSRs for the benefit of future analysis reuse, when applicable.

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.

Step 1 : Planning and Preparation

1.1 Purpose

The purpose of the Design FMEA Planning and Preparation Step is to define which FMEAs will be done for a project, and to define what is included and excluded in each FMEA based on the type of analysis being developed. i.e.. system, subsystem or component. The main objectives of Design FMEA Planning and Preparation 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 DFMEA Project Identification and Boundaries

DFMEA Project identification includes a clear understanding of what needs to be evaluated. This involves a decision-making process to define the DFMEAs 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 DFMEA projects.

• What is the customer buying from us?
• Are there new requirements?
• Does the customer or company require a DFMEA?
• 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 DFMEA project list assures consistent direction, commitment and focus. The following may assist the team in defining DFMEA boundaries as applicable:

• Legal requirements
• Technical requirements
• Customer wants/needs/expectation (external and internal customers)
• Requirements specification
• Diagrams (Block/Boundary) from similar project
• 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 (DFMEA)
• QFD Quality Function Deployment

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

• Novelty of technology/ degree of innovation
• Quality/reliability history (in-house. zero mileage, field failures, warranty and policy claims for similar product)
• Complexity of design
• Safety of people and systems
• Cyber-physical system (including Cyber security)
• Legal compliance
• Catalog & standard parts

1.3 DFMEA Project Plan
A plan for the execution of the DFMEA should be developed once the DFMEA project is known. It is recommended that the 5T method (lnTent, Timing, Team,Tasks, Tool) be used. The plan for the DFMEA helps the company be proactive in starting the DFMEA early. The DFMEA activities (5-Step process) should be incorporated into the overall project plan.

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

1.5 DFMEA Header
During the Planning and Preparation Step, the header of the DFMEA document should be filled out. The header may be modified to meet the needs of the organization. The header includes some of the basic DFMEA scope information as follows:

• Company Name: Name of Company Responsible for DFMEA
• Engineering Location: Geographical Location
• Customer Name: Name of Customer(s) or Product
• Model Year / Program(s): Customer Application or Company Model /Style
• Subject: Name of DFMEA Project (System, Subsystem and/or Component)
• DFMEA Start Date: Start Date
• DFMEA Revision Date: Latest Revision Date.
• Cross-Functional Team: Team Roster needed
• DFMEA ID Number: Determined by Company.
• Design Responsibility: Name of DFMEA owner
• Confidentiality Level: Business Use, Proprietary, Confidential

1.6 Basis for Structure Analysis
The information gathered during Step 1 Planning and. Preparation will be used to develop Step 2 Structure Analysis.

Step 2 : Structure Analysis

2.1 Purpose
The purpose of Design Structure Analysis is to identify and breakdown the FMEA scope into system, subsystem, and component parts for technical risk analysis. The main objectives of a Design Structure Analysis are:

• Visualization of the analysis scope
• Structure tree or equivalent: block diagram, boundary diagram, digital model, physical parts
• Identification of design interfaces, interactions, close clearances
• Collaboration between customer and supplier engineering teams (interface responsibilities)
• Basis for the Function Analysis step

2.2 System Structure
A system structure is comprised of system elements. Depending on the scope of analysis, the system elements of a design structure can consist of a system, subsystems, assemblies. and components. Complex structures may be split into several structures (work packages) or different layers of block diagrams and analyzed separately for organizational reasons or to ensure sufficient clarity. A system has a boundary separating it from other systems and the environment. Its relationship with the environment is defined by inputs and outputs. A system element is a distinct component of a functional item. not a function, a requirement or a feature.

2.3 Define the Customer
There are two-major customers to be considered in the FMEA analysis:

• END USER: The individual who uses a product after it has been fully developed and marketed.
• ASSEMBLY and MANUFACTURING: the locations where manufacturing operations (e.g., powertrain, stamping and fabricating) and vehicle! product assembly and production material processing takes place. Addressing the interfaces between the product and its assembly process is critical to an effective FMEA analysis. This may be any subsequent or downstream operation or a next Tier manufacturing process.

Knowledge of these customers can help to define the functions, requirements and specifications more robustly as well as aid in determining the effects of related failure modes.

2..4 Visualize System Structure
A visualization of the system structure helps the DFMEA team develop the structural analysis. There are various tools which may be used by the team to accomplish this. Two methods commonly used

• Block/Boundary Diagrams
• Structure Tree

2.4.1 Block/Boundary Diagram
Block/Boundary Diagrams are useful tools that depict the system under consideration and its interfaces with adjacent systems, the environment and the customer. The diagram is a graphic
representation that provides guidelines for structured brainstorming and facilitates the analysis of system interfaces as a foundation for a Design FMEA. The diagram below shows the physical and logical relationships between the components of the product. It indicates the interaction of components and subsystems within the scope of the design as well as those interfaces to the product Customer, Manufacturing, Service,Shipping. etc. The diagram identifies persons and things that the design interacts with during its useful life. The Boundary Diagram can be used to identify the Focus Elements to be assessed in the Structure Analysis and Function Analysis. The diagram may be in the form of boxes connected by lines, with each box corresponding to a major component of the product. The lines correspond with how the product components are related to, or interface with each other, with arrows at the end point(s) to indicate the direction of flow. Interfaces between elements in the Boundary Diagram can be included as Focus Elements in the Structure and Function Analysis Structure Tree. There are different approaches and formats to the construction of a Block/Boundary Diagram, which are determined by the organization. The terms “Block Diagram” and “Boundary Diagram” are used interchangeably. However. the Boundary Diagram tends to be more comprehensive due to the inclusion of external influences and system interactions. In the context of the DFMEA, Block/boundary Diagrams define the analysis scope and responsibility and provides guidelines for structured brainstorming. The scope of analysis is defined by the boundaries of the system; however. interfaces with external factors/systems are to be addressed.

• Defines scope of analysis (helps to identify potential team members)
• Identifies internal and external interfaces
• Enables application of system, sub-system. and component hierarchy

When correctly constructed, Block/Boundary Diagrams provide detailed information to the P-Diagram and the FMEA. Although Block/Boundary diagrams can be constructed to any level of
detail, it is important to identify the major elements, understand how they interact with each other, and how they may interact with outside systems. Block/boundary Diagrams are steadily refined as the design matures. The steps involved in completing a Block/boundary Diagram may be described as follows:

1. Describe components and features
   • Naming the parts and features helps alignment within the team, particularly when features have ‘“nicknames’
   • All system components and interfacing components shown
2. Reorganize blocks to show linkages :
   • Solid line for direct contact
   • Dashed line for indirect interfaces. e.g. clearances or relative motion
   • Arrows indicate direction
   • All energy flows /signal or force transfers identified.
3. Describe connections
   • Consider all types of interfaces, both desired and undesired:
     • P – Physically touching (welded. bolted. clamped, etc.)
     • E – Energy transfer (Torque (Nm), heat. etc.)
     • I-information transfer (ECU, sensors, signals, etc.)
     • M-Material exchange (Cooling fluid, exhaust gases,etc.)
4. Add interfacing systems and inputs (persons and things). The following should be included:
   • Adjacent systems— including systems that are not physically touching your system but may interact with it. require clearance, involve motion. or thermal exposure.
   • The customer/or end user
   • Arrows indicate direction
5. Define the boundary (What parts are within “the span of control of the team? What is new or modified?). Only parts designed or controlled by the team are inside the boundary. The blocks within the boundary diagram are one level lower than the level being analyzed. Blocks within the boundary may be marked to indicate items that are not part of the analysis.
6. Add relevant details to identify the diagram.
   • System, program and team identification
   • Key to any colors or line styles used to identify different types of interactions
   • Date and revision level

2.4.2 Interface Analysis
An interface analysis describes the. interactions between elements of a system. There are five primary types of interfaces:

• Physical connection (e.g., brackets, belts, clamps and various, types of connectors)
• Material exchange (e.g., compressed air, hydraulic fluids or any other fluid or material exchange)
• Energy transfer (e.g., heat transfer, friction or motion transfer such as chain links or gears)
• Data exchange (e.g., computer inputs or outputs, wiring- harnesses, electrical signals or any other types of information exchange, cyber security items)
• Human-Machine (e.g., controls, switches, mirrors, displays, warnings, seating, entry/exit)

Another type of interface may be described as a physical clearance between parts, where there is no physical connection. Clearances may be static and/or dynamic. Consider the interfaces between subsystems and components in addition to the content of the sub-systems and components themselves. An interface analysis documents the nature (strong/weak/none/beneficial/harmful) and type of relationships (Physical, Energy, Information or Material Exchange) that occur at all internal and external interfaces graphically displayed in the Block/Boundary Diagram. Information from an interface analysis provides valuable input to a Design FMEA, such as the primary functions or interface functions to be analyzed with potential causes/mechanisms of failure due to effects from neighboring systems and environments. Interface analysis also provides input to the P-Diagram on ideal functions. and noise factors.

2.4.3 Structure Trees
The structure tree arranges system elements hierarchically and illustrates the dependency via the structural connections. The clearly structured illustration of the complete system is thereby guaranteed by the fact that each system element exists only once to prevent redundancy. The structures arranged under each System Element are independent sub-structures. The interactions between System elements may be described as functions and represented by function nets. There is always a system element present even if it is only derived from the function and cannot yet be specified more clearly.

Structural Analysis (Step 2)
1. Next Higher Level	2. Focus Elements	3. Next Lower Level or Characteristic Type
Window Lifter Motor	Commutation System	Brush Card Base Body

1. Next Higher Level: The highest level of integration. within the scope of analysis.
2. Focus Element: The element in focus. This is the item that is topic of Consideration of the failure chain.
3. Next Lower Level or Characteristic Type:The element that is the next level down the structure from the focus element.

2.5 Collaboration between Customer and Supplier
The output of the Structure Analysis (visualization of the design and its interfaces) provides a tool for collaboration between customers and suppliers during technical reviews of the design and/or DFMEA project.

2.6 Basis for Function Analysis.
The information defined during Step 2 Structure Analysis will be used to develop Step 3 Function Analysis. If design elements (items) 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 Design Function Analysis is to ensure that the functions specified by requirements/specifications are appropriately allocated to the system elements. Regardless of the
tool used to generate the DFMEA, it is critical that the analysis is written in functional terms. The main objectives of a Design Function Analysis are:

• Visualization of product or process functions
• Function tree/net or function analysis form sheet and parameter diagram (P-diagram)
• Cascade of customer (external and internal) functions with associated requirements
• Association of requirements or characteristics to functions
• Collaboration between engineering teams (systems, safety, and components)
• Basis for the Failure Analysis step

The structure provides the basis so that each System Element may be individually analyzed with regard to its functions and requirements. For this, comprehensive knowledge of the system and the operating conditions and environmental conditions of the system are necessary, for example, heat, cold, dust, splash water, salt, icing, vibrations. electrical failures. etc.

3.2 Function
A function describes what the item/system element is intended to do. A function is to be assigned to a system element. Also, a system element can contain multiple functions. The description of a function needs to be clear. The recommended phrase format is to use an “action verb“ followed by a “noun” to describe a measurable function. A Function should be in the “PRESENT TENSE”; it uses the verb’s base form (e.g., deliver, contain, control, assemble, transfer).
Examples: deliver power, contain fluid, control speed, transfer heat, color black. Functions describe the relationship between the input and output of an item system element with the aim of fulfilling a task.
Note: A component (i.e., a part or item in a part list) may have a purpose/ function where there is no input/output. Examples such as a seal, grease, clip, bracket, housing, connector, flux etc. have functions and requirements including material, shape, thickness, etc. In addition to the primary functions of an item, other functions that may be evaluated include secondary functions such as interface functions, diagnostic functions, and serviceability functions

3.3 Requirements
Requirements are divided into two groups: functional requirements and non-functional requirements. A functional requirement is a criterion by which the intended performance of the function is judged or measured (e.g., material stiffness). A non-functional requirement is a limitation on the freedom for design decision (e.g., temperature range). Requirements may be derived from various sources, external and internal, these could be:
Legal requirements: for eg Environmentally friendly product design, suitable for recycling, safe in the event of potential misuse by the operator. non-flammable, etc.
Industry Norms and Standards: for eg ISO 9001, VDA Volume 6 Part 3, Process audit, SAE J1739, ISO 26262 Functional Safety.
Customer Requirements:Explicit (i.e., in customer specification) and implicit (i.e., freedom from prohibited materials) – under all specified conditions

Internal Requirements:Product Specific (i.e., Requirements Specifications, manufacturability, suitability for testing, compatibility with other existing products, reusability, cleanliness, generation, entry and spreading of particles)
Product Characteristics: A distinguishing feature (or quantifiable attribute) of a product such as a journal diameter or surface finish.

3.4 Parameter Diagram (P-Diagram)
Parameters are considered to be attributes of the behavior of a function. A Parameter (P) Diagram is a graphical representation of the environment in which an item exists. A P-Diagram includes factors which influence the transfer function between inputs and outputs, focusing on design decisions necessary to optimize output. A P-Diagram is used to characterize the behavior of a system or component in the context of a single function. P-Diagram-s are not required for all functions. Teams should focus on a few key functions affected by new conditions and those with history of robustness issues in previous applications. More than one P- Diagram may be needed in order to illustrate the function(s) of the system or component that are of concern to the FMEA Team.

The complete functional description forms the basis for subsequent failure analysis and risk mitigation. A P-Diagram focuses on achievement of function. It clearly identifies all influences on that function including what can be controlled (Control Factors), and what cannot reasonably be controlled (Noise Factors). The P-Diagram. completed for specific Ideal Functions. assists in the identification of:

• Factors, levels. responses and signals necessary for system optimization
• Functions which are inputs to the DFMEA
• Control and Noise factors which could affect functional performance
• Unintended system outputs (Diverted Outputs)
• Information gained through developing a P-Diagram provides input to the test plan.

Referring to Figure below, the output (grey area) of the item/ System Element often deviates/varies from the desired behavior (straight line). The control factors act on the design to achieve as close as practical to the desired behavior.

A Parameter Diagram consists of dynamic inputs (including signals), factors that could affect system performance (control and noise), sources of variation, and outputs (intended outputs and
unintended/diverted outputs). The following is an example of a Parameter Diagram which is used to assess the influences on a function of a product including:

• Input (What you want to put in to get the desired result) is a description of the sou fees required for fulfilling the system functionality.
• Function (What you want to happen) is described in a Parameter Diagram with an active verb followed by a measurable noun in the present tense and associated with requirements.
• Functional Requirements (What you need to make the function happen) are related to the performance of a function
• Control Factors (What you can do to make it happen) which can be adjusted to make the design more insensitive to noise (more robust) are identified. One type of Control Factor is a Signal Factor. Signal Factors are adjustment factors, set directly or indirectly by a user of a system, that proportionally change the system response (e.g., brake pedal movement changes stopping distance). Only dynamic systems utilize signal factors. Systems without signal factors are called static systems.
• Non-Functional Requirements (What you need beside the functional requirements) which limit the design option.
• Intended Output (What you want from the system) are ideal, intended functional outputs whose magnitude may (dynamic system) or may not (static system) be linearly proportional to a signal factor (e.g., low beam activation for a headlamp. stopping distance as a function of brake pedal movement).
• Unintended Output (What you don’t want from the system) are malfunctioning behaviors or unintended system outputs that divert system performance from the ideal intended function. For example, energy associated with a brake system is ideally transformed into friction. Heat, noise and vibration are examples of brake energy diverted outputs. Diverted Outputs may be losses to thermal radiation, vibration, electrical resistance, flow restriction. etc.
• Noise Factors (What interferes with achieving the desired output) are parameters which represent potentially significant sources of variation for the system response and cannot be controlled or are not practical to control from the perspective of the engineer. Noises are described in physical units. Noise factors are categorized as follows:
  • Piece to Piece Variation (in a component and interference between components)
  • Change Over Time (aging over life time. e.g.. mileage, aging, wear)
  • Customer Usage (use out of desired specifications)
  • External Environment (conditions during customer usage.e.g. road type. weather)
  • System Interactions(interference from other systems)

3.5 Function Analysis

The interactions of the functions of several System elements are to be demonstrated. for example as a function tree/network or using the DFMEA form sheet. The focus of the analysis cascades from OEM to Tier 1 supplier to Tier N supplier. The purpose of creating a function tree/network or function analysis on the DFMEA form sheet is to incorporate the technical dependency between the functions. Therefore. it subsequently supports the visualization of the failure dependencies. When there is a functional relationship between hierarchically linked functions. Then there is a potential relationship between the associated failures. Otherwise. if there is no functional relationship between hierarchically linked functions, there will also be no potential relationship between the associated failures. For the preparation of the function tree/network. the functions that are involved need to be examined. Sub-functions enable the performance of an overall function. All sub-functions are linked logically with each other in the function structure (Boolean & relationships). A function structure becomes more detailed from top down. The lower level function describes how the higher level function is to be fulfilled. For the logical linking of a function structure, it is helpful to ask:

• “How is the higher level function enabled by lower level functions?” (Top-Down) and
• “Why is the lower level function needed?” (Bottom-Up).

The function structure can be created in the Function Analysis section:

FUNCTION Analysis (Step 3)
1.Next Higher Level Function and Requirement	2. Focus Elements Function and Requirement	3. Next Lower Level Function and Requirement or Characteristic
Convert electrical energy into mechanical energy according to parameterization	Commutation System transport the electrical current between coil pairs of the electromagnetic convertors	Brush card body transports forces between spring and motor body to hold the brush spring system in x. y, z position (support commutating contact points)

How is the higher level function enabled by lower level functions?

1. Next Higher Level Function and Requirement: The function in scope of the Analysis.
2. Focus Element Function and Requirement: The function of the associated System Element (item in focus) identified in the Structure Analysis.
3. Next Lower Level Function and Requirement of Characteristic:The function of the associated Component Element identified in the Structure Analysis.

3.6 Collaboration between Engineering Teams (Systems, Safety, and Components)
Engineering teams within the company need to collaborate to make sure information is consistent for a project or customer program especially when multiple DFMEA teams are simultaneously conducting the technical risk analysis. For example, a systems group might be developing the design architecture (structure) and this information would be helpful to the DFMEA to avoid duplication of work. A safety team may be working with the customer to understand the safety goals and hazards. This information would be helpful to the DFMEA to ensure consistent severity ratings for failure effects.

3.7 Basis for Failure Analysis
Complete definition of 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 Design Failure Analysis is to identify failure causes, modes, and effects, and show their relationships to enable risk assessment. The main objectives of a Design Failure Analysis are:

• Establishment of the Failure Chain
• Potential Failure Effects, Failure Modes. Failure Causes for each product function.
• Collaboration between customer and supplier (Failure Effects)
• Basis for the documentation of-failures in the FMEA form sheet and the Risk Analysis step

4.2 Failures

Failures of a function are derived from the function descriptions. There are several types of- potential failure modes including, but not limited to:

• Loss of function (e.g. inoperable, fails suddenly)
• Degradation of function (e.g. performance loss overtime)
• Intermittent function (e.g. operation randomly starts/stops/starts)
• Partial function (e.g. performance loss)
• Unintended function (e.g. operation at the wrong time, unintended direction, unequal performance)
• Exceeding function (e.g. operation above acceptable threshold)
• Delayed function (e.g. operation after unintended time interval)

The description of a system and subsystem failure mode is described in terms of functional loss or degradation e.g., steering turns right when the hand wheel is moved left. as an example of an unintended function. When necessary, the operating condition of the vehicle should be included e.g. loss of steering assist during start up or shut down. A component/part failure mode is comprised of a noun and a failure description e.g., seal twisted. It is critical that the description of the failure is clear and understandable for the person who is intended to read it. A statement “not fulfilled,” “not OK,” “defective.” “broken“ and so on is not sufficient. More than one failure may be associated with a function. Therefore. the team should not stop as soon as one failure is
identified. They should ask “how else can this fail?“

4.3 The Failure Chain

There are three different aspects of a Failure analyzed in an FMEA:

• Failure Effect (FE)
• Failure Mode (FM)
• Failure Cause (FC)

4.4 Failure Effects

A Failure Effect is defined as the consequence of a failure mode. Describe effects on the next level of product integration (internal or external), the end user who is the vehicle operator (external), and government regulations (regulatory) as applicable. Customer effects should state what the user might notice or experience including those effects that could impact safety. The intent is to forecast the failure effects consistent with the team’s level of knowledge. A failure mode can have multiple effects relating to internal and external customers. Effects may be shared by OEMs with suppliers and suppliers with sub-suppliers as part of design collaboration. The severity of failure effects is evaluated on a ten-point scale. Examples of failure effects on the end user:

• No discernible effect
• Poor appearance e.g.. unsightly close-out. color fade, cosmetic corrosion.
• Noise e.g.. misalignment/rub. fluid-borne noise. squeak/rattle, chirp, and squawk
• Unpleasant odor, rough feel, increased efforts
• Operation impaired. intermittent. unable to operate. electromagnetic incompatibility (EMC)
• External leak resulting in performance loss. erratic operation,unstable
• Unable to drive vehicle (walk home)
• Noncompliance with government regulations
• Loss of steering or braking

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 specification. In these cases. the system integrator is responsible for ensuring the correct part for the application is selected. e.g.. auto,truck, marine, agriculture.

4.5 Failure Mode
A Failure Mode is defined as the manner in which an item could fail to meet or deliver the intended function. The Failure Modes are derived from the Functions. Failure Modes should be described in technical terms and not necessarily as symptoms noticeable by the customer. In preparing the DFMEA, assume that the design will be manufactured and assembled to the design intent. Exceptions can be made at the team‘s discretion where historical data indicates deficiencies exist in the manufacturing process. Examples of component-level failure modes include, but are not limited to:

Examples of system-level failure modes include, but are not limited to:

• Complete fluid loss
• Disengages too fast
• Does not disengage
• Does not transmit torque
• Does not hold full torque
• Inadequate structural support
• Loss of structural support
• No signal
• Intermittent signal
• Provides too much pressure/signal/voltage
• Provides insufficient pressurefsignal/voltage
• Unable to withstand load/temperature/vibration

4.6 Failure Cause
A Failure Cause is an indication of why the failure mode could occur. The consequence of a cause is the failure mode. Identify, to the extent possible, every potential cause for each failure mode. The consequences of not being robust to noise factors (found on a P-Diagram) may also be Failure Causes. The cause should be listed as concise and complete as possible so that remedial
efforts (controls and actions) can be aimed at appropriate causes. The Failure Causes can be derived from the Failure modes, of the next lower level function and requirement and the potential noise factors (e. g, from a Parameter Diagram). Types of potential failure causes could be, but are not limited to:

• Inadequate design for functional performance (e.g., incorrect material specified, incorrect geometry, incorrect part selected for application, incorrect surface finish specified, inadequate travel specification, improper friction material specified, insufficient lubrication capability, inadequate design life assumption, incorrect algorithm, improper maintenance instructions, etc.)
• System interactions (e.g., mechanical interfaces, fluid flow, heat sources. controller feedback, etc.)
• Changes overtime (e.g., yield, fatigue, material instability, creep, wear, corrosion, chemical oxidation, electromigration, over-stressing, etc.)
• Design inadequate for external environment (e.g., heat, cold, moisture, vibration, road debris, road salt, etc.)
• End user error or behavior (e.g., wrong gear used, wrong pedal used, excessive speeds, towing, wrong fuel type, service damage, etc.)
• Lack of robust design for manufacturing (e.g., part geometry allows part installation backwards or upside down, part lacks distinguishing design features, shipping container design
• causes parts to scratch or stick together, part handling causes damage, etc.)
• Software Issues (e.g., Undefined state, corrupted ccde/data)

4.7 Failure Analysis
Depending on whether the analysis is being done at the system, sub-system or component level, a failure can be viewed as a failure effect, failure mode, or failure cause. Failure Modes, Failure
Causes, and Failure Effects should correspond with the respective column in the FMEA form sheet. Figure below shows a cascade of design-related failure modes, causes, and effects from the vehicle level to the characteristic level. The focus element (Failure Mode), Causes, and Effects are different depending on the level of design integration. Consequently, a Failure Cause at the OEM becomes a Failure Mode at a next (Tier 1) level. However, Failure Effects at the vehicle level (as perceived by the end user) should be documented when known, but not assumed. Failure Networks may be created by the organization that owns multiple levels of the design. When multiple organizations are responsible for different levels of the design they are responsible to communicate failure effects to the next higher or next lower level as appropriate.

To link Failure Cause(s) to a Failure Mode. the question. should be “Why is the Failure Mode happening?“. To link Failure Effects to a Failure Mode, the question should be “What happens in the event of a Failure Mode?”

The failure structure can be created in the Failure Analysis section.

FAILURE ANALYSIS (STEP 4)
1.Failure Effect(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 next lower element or characteristics
Torque and rotating velocity of the window lifter motor too low	Angle deviation by commutation system intermittently connects the wrong coils (L1, L3 and L2 instead of L1, L2 and L3)	Brush card body bends in contact area of the carbon brush

Following once again the header numbering (1, 2, 3) and color coding, by inspecting the items in the Function Analysis begin building the Failure Chain.

1. Failure Effects (FE): The effect of failure associated with the “Next Higher Level Element and/or End User” in the Function Analysis.
2. Failure Mode (FM): The mode (or type) of failure associated with the “Focus Element” in the Function Analysis.
3. Failure Cause (FC): The cause of failure associated with the “Next Lower Element or Characteristic” in the Function Analysis..

4.8 Failure Analysis Documentation
The DFMEA Form Sheet can have multiple views once the Structure Analysis. Function Analysis and Failure Analysis are complete.

4.9 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.10 Basis fer 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 Design Risk Analysis is to estimate risk by evaluating Severity, Occurrence and Detection, and prioritize the need for actions. The main objectives of the Design 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

5.2 Design Controls
Current design controls are proven considerations that have been established for similar. previous designs. Design control documents are a basis for the robustness of the design. Prevention-type controls and detection-type controls are part of the current library of verification and validation methods. Prevention controls provide information or guidance that is used as an input to the design. Detection controls describe established verification and validation procedures that have been previously demonstrated to detect the failure, should it occur. Specific
references to design features that act to prevent a failure or line items in published test procedures will establish a credible link between the failure and the design control. These prevention and/or detection methods that are necessary, but not part of a current library of defined procedures should be written as actions in the DFMEA.

5.3 Current Prevention Controls (PC)
Current Prevention Controls describe how a potential cause which results in the Failure Mode is mitigated using existing and planned activities. They describe the basis for determining the occurrence rating. Prevention Controls relate back to the performance requirement. For items which have been designed out-of-context and are purchased as stock or catalog items from a supplier, the prevention control should document a specific reference to how the item fulfills the requirement. This may be a reference to a specification sheet in a catalog. Current Prevention controls need to be clearly and comprehensively described, with references cited. if necessary, this can be done by reference to an additional document. Listing a control such as “proven material” or “lessons learned” is not a clear enough indication. The DFMEA team should also consider margin of safety in design as a prevention control. Examples of Current Prevention Controls:

• EMC Directives adhered to, Directive 89/336/EEC
• System design according to simulation, tolerance calculation, and Procedure – analysis of concepts to establish design requirements
• Published design standard for a thread class
• Heat treat specification on drawing
• Sensor performance specifications.
• Mechanical redundancy (fail-safe)
• Design for test-ability
• In Design and Material standards (internal and external)
• Documentation (e.g., records of best practices. lessons learned, etc.) from similar designs
• Error-proofing (Poke-Yoke design i.e., part geometry prevents wrong orientation)
• Substantially identical to a design which was validated for a previous application, with documented performance history. (However, if there is a change to the duty cycle or operating conditions, then the carry-ever item requires re-validation in order for the detection control to be relevant.)
• Shielding or guards which mitigate potential mechanical wear, thermal exposure, or EMC.
• Conformance to best practices

After completion of the preventive actions the occurrence is verified by the Detection Control(s).

5.4 Current Detection Controls (DC)
Current Detection Controls detect the existence of a failure cause or the failure mode before the item is released for production. Current Detection Controls that are listed in the FMEA represent planned activities (or activities already completed), not potential activities which may never actually be conducted. Current Detection controls need to be clearly and comprehensively described. Listing a control such as “Test” or “Lab Test” is not a clear enough indication of a detection control. References to specific tests, test plans or procedures should be cited as applicable, to indicate that the FMEA team has determined that the test will actually detect the failure mode or cause, if it occurs (e.g.. Test No. 1234 Burst Pressure Test, Paragraph 6.1). Examples of Current Detection controls:

• Function check
• Burst test
• Environmental test
• Driving test a Endurance test
• Range of motion studies
• Hardware in-the-loop
• Software in-the-Ioop
• Design of experiments
• Voltage output lab measurements
  All controls that lead to a detection of the failure cause. or the failure mode are entered into the “Current Detection Controls” column.

5.5 Confirmation of Currant Prevention and Detection Controls

The effectiveness of the current prevention and detection controls should be confirmed. This can be done during validation tear down reviews. Such confirmation can be documented within the DFMEA, or within other project documents, as appropriate, according to the team’s normal product development procedure. Additional action may be needed if the controls are proven not to be effective. The occurrence and detection evaluations should be reviewed when using FMEA entries from previous products, due to the possibility of different conditions for the new product.

5.6 Evaluations
Each failure mode, cause and effect relationship is assessed to estimate risk. There are 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, where 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.7 Severity (S)
The Severity rating (S) is a measure associated with the most serious failure effect for a given failure mode of the function being evaluated. The rating is used to identify priorities relative to the scope of an individual FMEA and is determined without regard for occurrence or detection. Severity should be estimated using the criteria in the Severity Table. The table may be augmented to include product-specific examples. The FMEA project team should agree on an evaluation criteria and rating system. which is consistent even if modified for individual design analysis. The Severity evaluations of the failure effects should be transferred by the customer to. the supplier. as needed.

Product General Evaluation Criteria Severity (S)
Potential Failure Effects rated according to the criteria below.			Blank until filled in by user
S	Effect	Severity criteria	Corporate or Product Line  Examples
10	Very High	Affects safe operation of the vehicle and/or other vehicles, the health of driver or passengers or road users or pedestrians.
9		Noncompliance with regulations.
8	High	Loss of primary vehicle function necessary for normal driving during expected service life.
7		Degradation of primary vehicle function necessary for normal driving during expected service life.
6	Moderate	Loss of secondary vehicle function.
5		Degradation of secondary vehicle function.
4		Very objectionable appearance, sound, vibration, harshness, or haptics.
3	Low	Moderately objectionable appearance, sound, vibration, harshness, or haptics.
2		Slightly objectionable appearance, sound, vibration, harshness, or haptics.
1	Very low	No discernible effect

5.3 Occurrence (O)
The Occurrence rating (O) is a measure of the effectiveness of the prevention control, taking into account the rating criteria. Occurrence ratings should be estimated using the criteria in the Occurrence Table . The table may be augmented to include product-specific examples. The FMEA project team should agree on an evaluation criteria and rating system. which is consistent, even if modified for individual design analysis (e.g., passenger car, truck, motorcycle, etc). 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 in customer operation, according to the rating table, considering results of already completed detection controls. Expertise, data handbooks, warranty databases or other experiences in the field of comparable products, for example, can be consulted for the analysis of the evaluation numbers. When failure causes are rated for occurrence, it is done taking into account an estimation of the effectiveness of the current prevention control. The accuracy of this rating depends on how well the prevention control has been described. Questions such as the following may be helpful for a team when trying to determine the appropriate Occurrence rating:

• What is the service history and field experience with similar components, subsystems, or systems?
• Is the item a carryover product or similar to a previous level item?
• How significant are changes from a previous level item?
• Is the item completely new?
• What is the application or what are the environmental changes?
• Has an engineering analysis (e.g. reliability) been used to estimate the expected comparable occurrence rate for the application?
• Have prevention controls been put in place?
• Has the robustness of the product been proven during the product development process?

Occurrence Potential (O) for the Product
Potential Failure Causes rated according to the criteria below. Consider Product Experience and Prevention Controls when determining the best Occurrence estimate (Qualitative rating).			Blank until filled in by user
O	Prediction of Failure Cause Occurring	Occurrence criteria – DFMEA	Corporate or Product Line  Examples
10	Extremely High	First application of new technology anywhere without operating experience and/or under uncontrolled operating conditions. No product verification and/or validation experience. Standards do not exist and best practices have not yet been determined. Prevention controls not able to predict field performance or do not exist.
9	Very High	First use of design with technical innovations or materials within the company. New application or change in duty cycle / operating conditions. No product verification and/or validation experience. Prevention controls not targeted to identify performance to specific requirements.
8		First use of design with technical innovations or materials on a new application. New application or change in duty cycle/operating conditions. No product verification and/or validation experience.   Few existing standards and best practices, not directly applicable for this design. Prevention controls not a reliable indicator of field performance.
7	High	New design based on similar technology and materials. New application or change in duty cycle /operating conditions. No product verification and/or validation experience. Standards, best practices, and design rules apply to the baseline design, but not the innovations. Prevention controls provide  limited indication of performance
6		Similar to previous designs, using existing technology and materials. Similar application, with changes in duty cycle or operating conditions, Previous testing or field experience. Standards and design rules exist but are insufficient to ensure that the failure cause will not occur. Prevention controls provide some ability to prevent a failure cause.
5	Moderate	Detail changes to previous design, using proven technology and materials. Similar application, duty cycle or operating conditions. Previous testing or field experience, or new design with some test experience related to the failure. Design addresses lessons learned from previous designs. Best Practices re-evaluated for this design but have not yet been proven. Prevention controls capable of finding deficiencies in the product related to the failure cause and provide some indication of performance.
4		Almost identical design with short-term field exposure. Similar application with minor change in duty cycle or operating conditions. Previous testing or field experience.   Predecessor design and changes for new design conform to best- practices, standards, and specifications. Prevention controls capable of finding deficiencies in the product related to the failure cause and indicate likely design conformance.
3	Low	Detail changes to known design (same application, with minor change in duty cycle or operating conditions) and testing or field experience under comparable operating conditions or new design with successfully completed test procedure. Design expected to conform to Standards and Best Practices, considering Lessons Learned from previous designs. Prevention controls capable of finding deficiencies in the product related to the failure cause and predict conformance of production design.
2	Very low	Almost identical mature design with long term field exposure. Same application, with comparable duty cycle and operating conditions. Testing or field experience under comparable operating conditions. Design expected to conform to standards and best practices, considering Lessons Learned from previous designs, with  significant margin of confidence. Prevention controls capable of finding deficiencies in the product related to the failure cause and indicate confidence in design conformance.
1	Extremely low	Failure eliminated through prevention control and failure cause is not possible by design
Product Experience: History of product usage within the company [Novelty of design, application or use case). Results of already completed detection controls provide experience with the design.
Prevention Controls: Use of Best Practices for product design, Design Rules, Company Standards. Lessons Learned, industry Standards, Material Specifications, Government Regulations and effectiveness of prevention oriented analytical tools including Computer Aided Engineering, Math Modelling, Simulation Studies. Tolerance Stacks and Design/Safety Margins
Note: 10,9,8,7 can drop based on product validation activities

5.9 Detection (D)
The Detection rating (D) is an estimated measure of the effectiveness of the detection control to reliably demonstrate the failure cause or failure made before the item is released for production. The detection rating is the rating associated with the most effective detection control. 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 Detection Table.The FMEA project team should agree on an evaluation criteria and rating system, which is consistent. even if modified for individual product analysis. The detection rating is initially a prediction of the effectiveness of any yet unproven control. The effectiveness can be verified and re-evaluated after the detection control is completed. However, the completion or cancellation of a detection control (such as a test) may also affect the estimation of occurrence. 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 Product 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	Test procedure yet to be developed.	Test method not defined
9		Test method not designed specifically to detect failure mode or cause.	Pass-Fail, Test-to-Fail, Degradation Testing
8	Low	New test method; not proven.	Pass-Fail, Test-to-Fail, Degradation Testing
7	Moderate	Proven test method for verification of functionality or validation of performance, quality, reliability and durability; planned timing is later in the product development cycle such that test failures may result in production delays for re-design andi/r re-tooling.	Pass-Fail
6			Test-to-Fail
5			Degradation Testing
4	High	Proven test method for verification of functionality or validation of performance, quality, reliability and durability; planned timing is sufficient to modify production tools before release for production.	Pass-Fail
3			Test-to-Fail
2			Degradation Testing
1	Very High	Prior testing confirmed that failure mode or cause cannot occur. or detection methods proven to always detect the failure mode or failure cause.

5.10 Action Priority (AP)
Once the learn has completed the initial identification of Failure Modes, Failure Effects, Failure Causes and controls, including ratings for 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. The Action Priority (AP) method 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 0. 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 0, S and D, and 0 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 .Since the AP Table was designed to work with the Severity, Occurrence, and Detection tables , if the organization chooses to modify the S,0, 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 / or 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 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.11 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.

• The OEM may compare design functions, failure effects, and severity from a vehicle-level DFMEA with the Tier 1 supplier DFMEA.
• The Tier 1 supplier may compare design functions, failure effects, and severity from a subsystem DFMEA with the Tier 2 supplier who has design responsibility.
• 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.12 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 design 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 Design Optimization is to determine actions to mitigate risk and assess the effectiveness of those actions. The main objectives of a Design Optimization are:

• I Identification of the actions necessary to reduce risks
• Assignment of responsibilities and deadlines for action 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 requirements and prevention and detection controls

The primary objective of Design Optimization is to develop actions that reduce risk and increase customer satisfaction by improving the design. In this step, the team reviews the results of the risk analysis and assigns actions to lower the likelihood of occurrence of the Failure Cause or increase the robustness of the Detection Control to detect the Failure Cause or Failure Mode. Actions may also be assigned which improve the design 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. 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 DFMEA should be used to assess technical risks related to continuous improvement of the design. The optimization is most effective in the following order.

• Design modifications to eliminate or mitigate a Failure Effect (FE).
• Design modifications to reduce the Occurrence (O) of the Failure Cause (FC)
• Increase the Detection (D) ability for the Failure Cause (FC) or Failure Mode (FM).
• In the case of design modifications, all impacted design elements 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 design concept.

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 been 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 design. 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 Design FMEA Occurrence and Detection rating tables.

6.5 Continual Improvement
The DFMEA serves as an historical record for the design. 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 design decisions and design refinements. However, originalS, O, D ratings may be modified for foundation. family or generic DFMEA’s because the information is used as a starting point for an application-specific analysis.

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

Communication between the FllA team, management, customers and suppliers during the development of the technical risk analysis and/or when the DFMEA is initially complete brings people together to improve their understanding of product 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 FMEA activity. The main objectives of Design 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 report may be used for communication purposes within a company. or between companies. The report is not meant to replace reviews of the DFMEA details when requested by management, customers, or suppliers. It is meant to be a summary for the DFMEA 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 Project Plan
   • FMEA lntent— 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 (e.g. 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 DFMEA 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 DFMEAs for the benefit of future analysis reuse, when applicable.

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.

Product Quality Planning is a structured method of defining and establishing the steps necessary to assure that a product satisfies the customer. The goal of product quality planning is to facilitate communication with everyone involved to assure that all required steps are completed on time. Effective product quality planning depends on a company’s top management commitment to the effort required in achieving customer satisfaction. Some of the benefits of product quality planning are:

• To direct resources to satisfy the customer.
• To promote early identification of required changes.
• To avoid late changes.
• To provide a quality product on time at the lowest cost.

The work practices, tools, and analytical techniques described in this manual are listed in a logical sequence to make it easy to follow. Each Product Quality Plan is unique. The actual timing and sequence of execution is dependent on customer needs and expectations and/or other practical matters. The earlier a work practice, tool, and/or analytical technique can be implemented in the Product Quality Planning Cycle, the better.

Organize the Team:The organization’s first step in product quality planning is to assign a process owner for the APQP project. In addition, a cross functional team should be established to assure effective product quality planning. The team should include representatives from multiple functions such as engineering, manufacturing, material control, purchasing, quality, human resources, sales, field service, suppliers, and customers, as appropriate.

Define the Scope: It is important for the organization’s product quality planning team in the earliest stage of the product program to identify customer needs, expectations, and requirements. At a minimum, the team must meet to:

• Select a project team leader responsible for overseeing the planning process. (In some cases it may be advantageous to rotate the team leader during the planning cycle.)
• Define the roles and responsibilities of each area represented.
• Identify the customers – internal and external.
• Define customer requirements. (Use QFD if applicable.)
• Select the disciplines, individuals, and/or suppliers that must be added to the team, and those not required
• Understand customer expectations, i.e., design, number of tests.
• Assess   the    feasibility   of   the    proposed   design,   performance requirements and manufacturing process.
• Identify costs, timing, and constraints that must be considered.Determine assistance required from the customer.
• Identify documentation process or method.

Team-to-Team: The organization’s product quality planning team must establish lines of communication with other customer and organization teams. This may include regular meetings with other teams. The extent of team-to-team contact is dependent upon the number of issues requiring resolution.

Training: The success of a Product Quality Plan is dependent upon an effective training program that communicates all the requirements and development skills to fulfill customer needs and expectations.

Customer and Organization Involvement: The primary customer may initiate the quality planning process with an organization. However, the organization has an obligation to establish a cross functional team to manage the product quality planning process. Organizations must expect the same performance from their suppliers.

Simultaneous Engineering: Simultaneous Engineering is a process where cross functional teams strive for a common goal. It replaces the sequential series of phases where results are transmitted to the next area for execution. The purpose is to expedite the introduction of quality products sooner. The organization’s product quality planning team assures that other areas/teams plan and execute activities that support the common goal or goals

Control Plans: Control plans are written descriptions of the systems for controlling parts and processes. Separate control plans cover three distinct phases:

• Prototype – A description of the dimensional measurements and material and performance tests that will occur during Prototype build
• Pre-launch – A description of the dimensional measurements and material and performance tests that will occur after Prototype and before full Production.
• Production – A comprehensive documentation of product/process characteristics, process controls, tests, and measurement systems that will occur during mass production.

Concern Resolution:  During the planning process, the team will encounter product design and/or processing concerns. These concerns should be documented on a matrix with assigned responsibility and timing. Disciplined problem- solving methods are recommended in difficult situations. Analytical techniques described in Appendix B should be used as appropriate.

Product Quality Timing Plan: The organization’s product quality planning team’s first order of business following organizational activities should be the development of a Timing Plan. The type of product, complexity and customer expectations should be considered in selecting the timing elements that must be planned and charted. All team members should agree with each event, action, and timing.   A well-organized timing chart should list tasks, assignments, and/or other events. (The Critical Path Method may be appropriate;) Also, the chart provides the planning team with a consistent format for tracking progress and setting meeting agendas. To facilitate status reporting, each event must have a “start” and a “completion” date with the actual point of progress recorded. Effective status reporting supports program monitoring with a focus on identifying items that require special attention.  

Plans Relative to the Timing Chart: The success of any program depends on meeting customer needs and expectations in a timely manner at a cost that represents value. The Product Quality Planning Timing Chart below and the Product Quality Planning Cycle described previously require a planning team to concentrate its efforts on problem prevention. Problem prevention is driven by Simultaneous Engineering performed by product and manufacturing engineering activities working concurrently. Planning teams must be prepared to modify product quality plans to meet customer expectations. The organization’s product quality planning team is responsible for assuring that timing meets or exceeds the customer timing plan.

1.0 Plan and Define Program

IT describes how customer needs and expectations are linked to planning and defining a quality program. The goal of any product program is meeting customer needs while providing competitive value. The initial step of the product quality planning process is to ensure that customer needs and expectations are clearly understood.The inputs and outputs applicable to the planning process may vary according to the product development process, and customer needs and expectations.

INPUTS

• Voice of the Customer
  • Market Research (including OEM Vehicle Build Timing and OEM Volume Expectations)
  • Historical Warranty and Quality Information
  • Team Experience
• Business Plan/Marketing Strategy
• Product/Process Benchmark Data
• Product/Process Assumptions
• Product Reliability Studies
• Customer Inputs

OUTPUTS

• Design Goals
• Reliability and Quality Goals
• Preliminary Bill of Material
• Preliminary Process Flow Chart
• Preliminary Listing of Special Product and Process Characteristics
• Product Assurance Plan
• Management Support (including program timing and planning for resources and staffing to support required capacity)

1.1 Voice of the Customer
The “Voice of the Customer” encompasses complaints, recommendations, data and information obtained from internal and/or external customers. Some methods for gathering this information are as follows.

1.1.1 Market Research

The organization’s product quality planning team may need to obtain market research data and information reflecting the Voice of the Customer. The following sources can assist in identifying customer concerns and wants and translating those concerns into product and process characteristics:

• Customer interviews
• Customer questionnaires and surveys
• Market test and positioning reports
• New product quality and reliability studies
• Competitive product quality studies
• Best Practices
• Lessons Learned

1.1.2 Historical Warranty and Quality Information

A list of historical customer concerns and wants should be prepared to assess the potential for recurrence during the design, manufacture, installation and use of the product. These should be considered as an extension of the other design requirements and included in the analysis of customer needs. Many of the following items can assist the team in identifying customer concerns and wants and prioritizing appropriate resolutions.

• Best Practices
• Lessons Learned
• Warranty reports
• Capability indicators
• Supplier plant internal quality reports
• Problem resolution reports
• Customer plant returns and rejections
• Field return product analysis

1.1.3 Team Experience

The team may use any source of any information as appropriate, including the following:

• Input from higher system level or past Quality Function Deployment (QFD) projects
• Media commentary and analysis: magazine and newspaper reports, etc
• Customer letters and suggestions
• Best Practices
• Lessons Learned
• Dealer comments
• Fleet Operator’s comments
• Field service reports
• Internal evaluations using surrogate customers
• Road trips
• Management comments or direction
• Problems and issues reported from internal customers
• Government requirements and regulations
• Contract review

1.2 Business Plan and Marketing Strategy

The customer business plan and marketing strategy will set the framework for the product quality plan. The business plan may place constraints (e.g., timing, cost, investment, product positioning, research and development (R&D) resources) on the team that affect the direction taken. The marketing strategy will define the target customer, the key sales points, and key competitors.

1.3 Product/Process Benchmark Data

The use of bench-marking will provide input to establishing product/process performance targets. Research and development may also provide benchmarks and concept ideas. One method to successful bench-marking is:

• Identify the appropriate benchmarks.
• Understand the reason for the gap between your current status and the benchmark.
• Develop a plan to close the gap, match the benchmark, or exceed the benchmark.

1.4 Product/Process Assumptions

  There will be assumptions that the product has certain features, design, or process concepts. These include technical innovations, advanced materials, reliability assessments, and new technology. All should be utilized as inputs.

1.5 Product Reliability Studies

This type of data considers frequency of repair or replacement of components within designated periods of time and the results of long-term reliability/durability tests. 

1.6 Customer Inputs

 The next users of the product can provide valuable information relating to their needs and expectations. In addition, the next product users may have already conducted some or all of the aforementioned reviews and studies. These inputs should be used by the customer and/or organization to develop agreed upon measures of customer satisfaction.

1.7 Design Goals

 Design goals are a translation of the Voice of the Customer into measurable design objectives. The proper selection of design goals assures that the Voice of the Customer is not lost in subsequent design activity. The Voice of the Customer also includes regulatory requirements such as materials composition reporting and polymeric part marking.

1.8 Reliability and Quality Goals

Reliability goals are established based on customer wants and expectations, program objectives, and reliability benchmarks. An example of customer wants and expectations could include no safety failures. Some reliability benchmarks could be competitor product reliability, warranty data, or frequency of repair over a set time period. Quality goals should be based on metrics such as parts per million, problem levels, or scrap reduction.  

1.9 Preliminary Bill of Material

The team should establish a preliminary bill of material based on product/process assumptions and include a potential supplier list.   In order to identify the preliminary special product/process characteristics it is necessary to have selected the appropriate design and manufacturing process.

1.10 Preliminary Process Flow Chart
The anticipated manufacturing process should be described using a process flow chart developed from the preliminary bill of material and product/process assumptions.

1.11 Preliminary Identification of Special Product and Process Characteristics
Special product and process characteristics are identified by the customer in addition to those selected by the organization through knowledge of the product and process. Examples of input to identification of special characteristics include:

• Product assumptions based on the analysis of customer needs and expectations.
• Identification of reliability goals and requirements.
• Identification of special process characteristics from the anticipated manufacturing process.
• Similar part FMEAs.

1.12 Product Assurance Plan
The Product Assurance Plan translates design goals into design requirements and is based on customer needs and expectations. This manual does not require a specific method for preparing a Product Assurance Plan. The Product Assurance Plan can be developed in any format understood by the organization and should include:

• Outlining of program requirements.
• Identification of reliability, durability, and apportionment/allocation goals and/or requirements.
• Assessment of new technology, complexity, materials, application, environment, packaging, service, and manufacturing requirements, or any other factor that may place the program at risk.
• Use of Failure Mode and Effects Analysis (FMEA).
• Development of preliminary engineering requirements.

1.13 Management Support

One of the keys to the success of Advanced Product Quality Planning is the interest, commitment and support of upper management. Participation by management in product quality planning meetings is vital to ensuring the success of the program. Management should be updated at the conclusion of every product quality planning phase to reinforce their commitment and support. Updates and/or requests for assistance can occur more frequently as required. A primary goal of Advanced Product Quality Planning is to maintain management support by demonstrating that all planning requirements have been met and/or concerns documented and scheduled for resolution, including program timing and planning for resources and staffing to support required capacity

2.0 Product Design and Development

It discusses the elements of the planning process during which design features and characteristics are developed into a near final form. All design factors should be considered by the organization in the Advanced Product Quality Planning process even if the design is owned by the customer or shared. The steps include prototype build to verify that the product or service meets the objectives of the Voice of the Customer. A feasible design must permit meeting production volumes and schedules, and be consistent with the ability to meet engineering requirements, along with quality, reliability, investment cost, weight, unit cost and timing objectives. Although feasibility studies and control plans are primarily based on engineering drawings and specification requirements, valuable information can be derived from the analytical tools described in this chapter to further define and prioritize the characteristics that may need special product and process controls.In this chapter, the Product Quality Planning Process is designed to assure a comprehensive and critical review of engineering requirements and other related technical information. At this stage of the process, a preliminary feasibility analysis will be made to assess the potential problems that could occur during manufacturing.

DESIGN INPUTS

• Design Goals
• Reliability and Quality Goals
• Preliminary Bill of Material
• Preliminary Process Flow Chart
• Preliminary Listing of Special Product and Process Characteristics
• Product Assurance Plan
• Management Support

DESIGN OUTPUTS

• Design Failure Mode and Effects Analysis (DFMEA)
• Design for Manufacturability and Assembly
• Design Verification
• Design Reviews
• Prototype Build – Control Plan
• Engineering Drawings (Including Math Data)
• Engineering Specifications
• Material Specifications
• Drawing and Specification Changes

APQP OUTPUTS

• New Equipment, Tooling and Facilities Requirements
• Special Product and Process Characteristics
• Gages/Testing Equipment Requirements
• Team Feasibility Commitment and Management Support

2.1 Design Failure Mode and Effects Analysis (DFMEA)

The DFMEA is a disciplined analytical technique that assesses the probability of failure as well as the effect of such failure. A DFMEA is a living document continually updated as customer needs and expectations require. The DFMEA is an important input to the APQP process that may include previously selected product and process characteristics. The Design FMEA Checklist should also be reviewed to assure that the appropriate design characteristics have been considered.

2.2   Design for Manufacturability and Assembly

   Design for Manufacturability and Assembly is a Simultaneous Engineering process designed to optimize the relationship between design function, manufacturability, and ease of assembly. The scope of customer needs and expectations defined will determine the extent of the organization’s product quality planning team involvement in this activity. This manual does not include or refer to a formal method of preparing a Design for Manufacturability and Assembly Plan. At a minimum, the items listed here should be considered by the organization’s product quality planning team:

• Design, concept, function, and sensitivity to manufacturing variation
• Manufacturing and/or assembly process
• Dimensional tolerances
• Performance requirements
• Number of components
• Process adjustments
• Material handling

The above list may be augmented based on the organization’s product quality planning team’s knowledge, experience, the product/process, government regulations, and service requirements. 

2.3 Design Verification

 Design verification verifies that the product design meets the customer requirements derived from the activities.

2.4 Design Reviews

 Design reviews are regularly scheduled meetings led by the organization’s design engineering activity and must include other affected areas. The design review is an effective method to prevent problems and misunderstandings; it also provides a mechanism to monitor progress, report to management, and obtain customer approval as required.Design reviews are a series of verification activities that are more than an engineering inspection. At a minimum, design reviews should include evaluation of:

• Design/Functional requirement(s) considerations
• Formal reliability and confidence goals
• Component/subsystem/system duty cycles
• Computer simulation and bench test results
• DFMEA(s)
• Review of the Design for Manufacturability and Assembly effort
• Design of Experiments (DOE) and assembly build variation results
• Test failures
• Design verification progress

A major function of design reviews is the tracking of design verification progress. The organization should track design verification progress through the use of a plan and report format, referred to as Design Verification Plan and Report (DVP&R) by some customers. The plan and report is a formal method to assure:

• Design verification
• Product and process validation of components and assemblies through the application of a comprehensive test plan and report.

The organization’s product quality planning team is not limited to the items listed. The team should consider and use as appropriate, the analytical techniques.

2.5 Prototype Build – Control Plan

Prototype control plans are a description of the dimensional measurements and material and functional tests that will occur during prototype build. The organization’s product quality planning team should ensure that a prototype control plan is prepared. A Control Plan Checklist is provided to assist in the preparation of the prototype control plan.The manufacture of prototype parts provides an excellent opportunity for the team and the customer to evaluate how well the product or service meets the Voice of the Customer objectives. It is the organization’s product quality planning team’s responsibility to review prototypes for the following:

• Assure that the product or service meets specification and report data as required.
• Ensure that particular attention has been given to special product and process characteristics.
• Use data and experience to establish preliminary process parameters and packaging requirements.
• Communicate any concerns, deviations, and/or cost impact to the customer.

2.6 Engineering Drawings (Including Math Data)

Customer designs do not preclude the organization’s product quality planning team’s responsibility to review engineering drawings in the following manner. Engineering drawings may include special (governmental regulatory and safety) characteristics that must be shown on the control plan. When customer engineering drawings are nonexistent, the controlling drawings should be reviewed by the team to determine which characteristics affect fit, function, durability and/or governmental regulatory safety requirements.Drawings should be reviewed to determine if there is sufficient information for a dimensional layout of the individual parts. Control or datum surfaces/locators should be clearly identified so that appropriate functional gages and equipment can be designed for ongoing controls. Dimensions should be evaluated to assure feasibility and compatibility with industry manufacturing and measuring standards. If appropriate, the team should assure that math data is compatible with the customer’s system for effective two-way communications.

2.7 Engineering Specifications

A detailed review and understanding of the controlling specifications will help the organization’s product quality planning team to identify the functional, durability and appearance requirements of the subject component or assembly. Sample size, frequency, and acceptance criteria of these parameters are generally defined in the in-process test section of the Engineering Specification. Otherwise, the sample size and frequency are to be determined by the organization and listed in the control plan. In either case, the organization should determine which characteristics affect meeting functional, durability, and appearance requirements.  

2.8 Material Specifications

In addition to drawings and performance specifications, material specifications should be reviewed for special characteristics relating to physical properties, performance, environmental, handling, and storage requirements. These characteristics should also be included in the control plan.  

2.9 Drawing and Specification Changes

Where drawing and specification changes are required, the team must ensure that the changes are promptly communicated and properly documented to all affected areas.  

2.10  New Equipment, Tooling and Facilities Requirements

The DFMEA, Product Assurance Plan and/or design reviews may identify new equipment and facilities including meeting capacity requirements. The organization’s product quality planning team should address these requirements by adding the items to the Timing Chart. The team should assure that there is a process to determine that new equipment and tooling is capable and delivered on time. Facilities progress should be monitored to assure completion prior to planned production tryout.

2.11 Special Product and Process Characteristics

In the Plan and Define Program stage, the team identified preliminary special product and process characteristics. The organization’s product quality planning team should build on this listing and reach consensus through the evaluation of the technical information. The organization should refer to the appropriate customer-specific requirements

2.12  Gages/Testing Equipment Requirements

Gages/testing equipment requirements may also be identified at this time. The organization’s product quality planning team should add these requirements to the Timing Chart. Progress should be monitored to assure that required timing is met. 

2.13 Team Feasibility Commitment and Management Support

The organization’s product quality planning team must assess the feasibility of the proposed design at this time. Customer design ownership does not preclude the organization’s obligation to assess design feasibility. The team must be satisfied that the proposed design can be manufactured, assembled, tested, packaged, and delivered in sufficient quantity on schedule at an acceptable cost to the customer. The Design Information Checklist allows the team to review its efforts in this section and make an evaluation of effectiveness. This checklist will also serve as a basis for the open issues discussed in the Team Feasibility Commitment. The team consensus that the proposed design is feasible should be documented along with all open issues that require resolution and presented to management for their support.

3.0 Process Design and Development

It discusses the major features of developing a manufacturing system and its related control plans to achieve quality products.   The tasks to be accomplished at this step of the product quality planning process depend upon the successful completion of the prior stages contained in the first two sections. This next step is designed to ensure the comprehensive development of an effective manufacturing system. The manufacturing system must assure that customer requirements, needs and expectations are met. The inputs and outputs applicable to the process step in this chapter are as follows:

INPUTS

• Design Failure Mode and Effects Analysis (DFMEA)
• Design for Manufacturability and Assembly
• Design Verification
• Design Reviews
• Prototype Build – Control Plan
• Engineering Drawings (Including Math Data)
• Engineering Specifications
• Material Specifications
• Drawing and Specification Changes
• New Equipment, Tooling and Facilities Requirements
• Special Product and Process Characteristics
• Gages/Testing Equipment Requirements
• Team Feasibility Commitment and Management Support

OUTPUTS

• Packaging Standards & Specifications
• Product/Process Quality System Review
• Process Flow Chart
• Floor Plan Layout
• Characteristics Matrix
• Process Failure Mode and Effects Analysis (PFMEA)
• Pre-Launch Control Plan (including Error-Proofing Devices)
• Process Instructions
• Measurement Systems Analysis Plan
• Preliminary Process Capability Study Plan
• Management Support (including operator staffing and training plan)

3.1  Packaging Standards and Specifications

The customer will usually have packaging requirements that should be incorporated into any packaging specifications for the product. If none are provided, the packaging design should ensure product integrity at point of use. The organization’s product quality planning team should ensure that individual product packaging (including interior partitions) is designed and developed. Customer packaging standards or generic packaging requirements should be used when appropriate. In all cases the packaging design should assure that the product performance and characteristics will remain unchanged during packing, transit, and unpacking. The packaging should have compatibility with all identified material handling equipment including robots. 

3.2 Product/Process Quality System Review

The organization’s product quality planning team should review the manufacturing site(s) Quality Management System. Any additional controls and/or procedural changes required to produce the product should be updated, documented and included in the manufacturing control plan. This is an opportunity for the organization’s product quality planning team to improve the existing quality system based on customer input, team expertise, and previous experience. The Product/Process Quality Checklist can be used by the organization’s product quality planning team to verify completeness. 

3.3  Process Flow Chart

The process flow chart is a schematic representation of the current or proposed process flow. It can be used to analyze sources of variations of machines, materials, methods, and manpower from the beginning to end of a manufacturing or assembly process. It is used to emphasize the impact of sources of variation on the process. The flow chart helps to analyze the total process rather than individual steps in the process.   The flow chart assists the organization’s product quality planning team to focus on the process when conducting the PFMEA and designing the Control Plan. The Process Flow Chart Checklist can be used by the organization’s product quality planning team to verify completeness. 

3.4   Floor Plan Layout

 The floor plan should be developed and reviewed to determine the acceptability of important control items, such as inspection points, control chart location, applicability of visual aids, interim repair stations, and storage areas to contain non-conforming material. All material flow should be keyed to the process flow chart and control plan. The Floor Plan Checklist can be used by the organization’s product quality planning team to verify completeness. The floor plan layout should be developed in such a manner to optimize the material travel, handling and value-added use of floor space and should facilitate the synchronous flow of materials through the process.  

3.5 Characteristics Matrix

A characteristics matrix is a recommended analytical technique for displaying the relationship between process parameters and manufacturing stations.

3.6 Process Failure Mode and Effects Analysis (PFMEA)

A PFMEA should be conducted during product quality planning and before beginning production. It is a disciplined review and analysis of a new or revised process and is conducted to anticipate, resolve, or monitor potential process problems for a new or revised product program. The Process FMEA Checklist i can be used by the organization’s product quality planning team to verify completeness. 

3.7  Pre-Launch Control Plan

Pre-launch control plans are a description of the dimensional measurements and material and functional tests that will occur after prototype and before full production. The pre-launch control plan should include additional product/process controls to be implemented until the production process is validated. The purpose of the pre-launch control plan is to contain potential non-conformities during or prior to initial production runs. Examples of enhancements in the pre-launch control plan are:

• More frequent inspection
• More in-process and final check points
• Robust statistical evaluations
• Enhanced audits
• Identification of error-proofing devices

 The Control Plan can be used by the organization’s product quality planning team to verify completeness.

3.8 Process Instructions

The organization’s product quality planning team should ensure that process instructions provide sufficient understanding and detail for all personnel who have direct responsibility for the operation of the processes. These instructions should be developed from the following sources:

• FMEAs
• Control plan(s)
• Engineering      drawings,      performance     specifications,     material specifications, visual standards and industry standards
• Process flow chart
• Floor plan layout
• Characteristics matrix
• Packaging Standards and Specifications
• Process parameters
• Organization expertise and knowledge of the processes and products
• Handling requirements
• Operators of the process

 The process instructions for standard operating procedures should be posted and should include set-up parameters such as: machine speeds, feeds, cycle times, and tooling, and should be accessible to the operators and supervisors. Additional information for process instruction preparation may be found in appropriate customer-specific requirements. 

3.9 Measurement Systems Analysis Plan

The organization’s product quality planning team should ensure that a plan to accomplish the required measurement systems analysis is developed, including checking aids. This plan should include, at a minimum, a laboratory scope appropriate for the required measurements and tests, the responsibility to ensure gage linearity, accuracy, repeatability, reproducibility, and correlation for duplicate gages.

3.10 Preliminary Process Capability Study Plan

The organization’s product quality planning team should ensure the development of a preliminary process capability plan. The characteristics identified in the control plan will serve as the basis for the preliminary process capability study plan. . 

3.11 Management Support

The organization’s product quality planning team should schedule a formal review designed to reinforce management commitment at the conclusion of the process design and development phase. This review is critical to keeping upper management informed as well as gaining assistance to assist in resolution of any open issues. Management support includes the confirmation of the planning and providing the resources and staffing to meet the required capacity.

4.0 Product and Process Validation

IT discusses the major features of validating the manufacturing process through an evaluation of a significant production run. During a significant production run, the organization’s product quality planning team should validate that the control plan and process flow chart are being followed and the products meet customer requirements. Additional concerns should be identified for investigation and resolution prior to regular production runs.The inputs and outputs applicable to the process steps in this chapter are as follows:

INPUTS

• Packaging Standards & Specifications
• Product/Process Quality System Review
• Process Flow Chart
• Floor Plan Layout
• Characteristics Matrix
• Process Failure Mode and Effects Analysis (PFMEA)
• Pre-Launch Control Plan
• Process Instructions
• Measurement Systems Analysis Plan
• Preliminary Process Capability Study Plan
• Management Support

OUTPUTS

• Significant Production Run
• Measurement Systems Evaluation
• Preliminary Process Capability Study
• Production Part Approval
• Production Validation Testing
• Packaging Evaluation
• Production Control Plan
• Quality Planning Sign-Off and Management Support

4.1 Significant Production Run

The significant production run must be conducted using production tooling, production equipment, production environment (including production operators), facility, production gages and production rate. The validation of the effectiveness of the manufacturing process begins with the significant production run . The minimum quantity for a significant production run is usually set by the customer, but can be exceeded by the organization’s product quality planning team. Output of the significant production run (product) is used for:

• Preliminary process capability study
• Measurement systems analysis
• Production rate demonstration
• Process review
• Production validation testing
• Production part approval
• Packaging evaluation
• First time capability (FTC)
• Quality planning sign-off
• Sample production parts
• Master sample (as required)

4.2 Measurement Systems Analysis

The specified monitoring and measuring devices and methods should be used to check the control plan identified characteristics to engineering specification and be subjected to measurement system evaluation during or prior to the significant production run. Refer to the Chrysler, Ford, and General Motors Measurement Systems Analysis (MSA) reference manual. 

4.3 Preliminary Process Capability Study

The preliminary process capability study should be performed on characteristics identified in the control plan. The study provides an assessment of the readiness of the process for production. Refer to customer-specific requirements for unique requirements.

4.4  Production Part Approval

PPAP’s purpose is to provide the evidence that all customer engineering design record and specification requirements are properly understood by the organization and that the manufacturing process has the potential to produce product consistently meeting these requirements during an actual production run at the quoted production rate.

4.5 Production Validation Testing

Production validation testing refers to engineering tests that validate that products made from production tools and processes meet customer engineering standards including appearance requirements.  

4.6 Packaging Evaluation

All test shipments (when required) and test methods must assess the protection of the product from normal transportation damage and adverse environmental factors. Customer-specified packaging does not preclude the organization’s product quality planning team involvement in evaluating the effectiveness of the packaging.  

4.7 Production Control Plan

The production control plan is a written description of the systems for controlling production parts and processes. The production control plan is a living document and should be updated to reflect the addition or deletion of controls based on experience gained by producing parts. (Approval of the authorized customer representative may be required.) The production control plan is a logical extension of the pre-launch control plan. Mass production provides the organization the opportunity to evaluate output, review the control plan and make appropriate changes.

4.8 Quality Planning Sign-Off and Management Support

The organization’s product quality planning team should perform a review at the manufacturing location(s) and coordinate a formal sign-off. The product quality sign-off indicates to management that the appropriate APQP activities have been completed. The sign-off occurs prior to first product shipment and includes a review of the following:

• Process Flow Charts. Verify that process flow charts exist and are being followed.
• Control Plans. Verify that control plans exist, are available and are followed at all times for all affected operations.
• Process Instructions. Verify that these documents contain all the special characteristics specified in the control plan and that all PFMEA recommendations have been addressed. Compare the process instructions, PFMEA and process flow chart to the control plan.
• Monitoring and Measuring Devices. Where special gages, fixtures, test equipment or devices are required per the control plan, verify gage repeatability and reproducibility (GR&R) and proper usage.
• Demonstration of Required Capacity. Using production processes, equipment, and personnel.

Upon completion of the sign-off, a review with management should be scheduled to inform management of the program status and gain their support with any open issues.

5.0 Feedback, Assessment and Corrective Action

Quality planning does not end with process validation and installation. It is the component manufacturing stage where output can be evaluated when all special and common causes of variation are present. This is also the time to evaluate the effectiveness of the product quality planning effort. The production control plan is the basis for evaluating product or service at this stage. Variable and attribute data must be evaluated. Organizations that fully implement an effective APQP process will be in a better position to meet customer requirements including any special characteristics specified by the customer.

INPUTS

• Significant Production Run
• Measurement Systems Evaluation
• Preliminary Process Capability Study
• Production Part Approval
• Production Validation Testing
• Packaging Evaluation
• Production Control Plan
• Quality Planning Sign-Off and Management Support

OUTPUTS

• Reduced Variation
• Improved Customer Satisfaction
• Improved Delivery and Service
• Effective use of Lessons Learned/Best Practices

5.1 Reduced Variation

  Control charts and other statistical techniques should be used as tools to identify process variation. Analysis and corrective actions should be used to reduce variation. Continual improvement requires attention not only to the special causes of variation but understanding common causes and seeking ways to reduce these sources of variation. Proposals should be developed including costs, timing, and anticipated improvement for customer review. The reduction or elimination of a common cause may provide the additional benefit of lower costs. Organizations should be using tools such as value analysis and reduction of variation to improve quality and reduce cost.

5.2  Improved Customer Satisfaction

Detailed planning activities and demonstrated process capability of a product or service are important components to customer satisfaction. However, the product or service still has to perform in the customer environment. This product usage stage requires organization participation. In this stage much can be learned by the organization and customer. The effectiveness of the product quality planning efforts can also be evaluated at this stage.The organization and customer become partners in making the changes necessary to correct any deficiencies and to improve customer satisfaction. 

5.3  Improved Delivery and Service

The delivery and service stage of quality planning continues the organization and customer partnership in solving problems and continual improvement. The customer’s replacement parts and service operations must also meet requirements for quality, cost, and delivery.   The goal is first time quality. However, where problems or deficiencies occur in the field it is essential that the organization and customer form an effective partnership to correct the problem and satisfy the end-user customer.The experience gained in this stage provides the customer and organization with the necessary knowledge to reduce process, inventory, and quality costs and to provide the right component or system for the next product. 

5.4 Effective Use of Lessons Learned/Best Practices

  A Lessons Learned or Best Practices portfolio is beneficial for capturing, retaining and applying knowledge. Input to Lessons Learned and Best Practices can be obtained through a variety of methods including:

• Review of Things Gone Right/Things Gone Wrong (TGR/TGW)
• Data from warranty and other performance metrics
• Corrective action plans”Read-across” with similar products and processes
• DFMEA and PFMEA studies

PRODUCT QUALITY PLANNING CHECKLISTS

The following checklists are provided to assist the organization’s product quality planning team in order to verify that the APQP process is both complete and accurate. These checklists are not intended to fully define or represent all elements of the APQP process. The use of the checklists is one of the last steps of the process and not intended as a “check the box” activity or exercise to circumvent full application of the APQP process. In reviewing the questions in the checklist, where “No” is identified as the appropriate response, the column “Comment/Action Required” is used to identify the action required to close the gap, including the impact on the APQP process. The follow up action should include identification of an individual responsible and schedule. Use the “Person Responsible” and “Due Date” columns.

ANALYTICAL TECHNIQUES

Assembly Build Variation Analysis: An assembly build variation analysis is an analysis that simulates the buildup of an assembly and examines tolerance accumulation, statistical parameters, sensitivity, and “what if” investigation. 

Benchmarking:  Benchmarking is a systematic approach to identifying standards for comparison. It provides input to the establishment of measurable performance targets, as well as ideas for product design and process design. It can also provide ideas for improving business processes and work procedures.Product and process benchmarking should include the identification of world class or best-in-class based on customer and internal objective performance measures and research into how this performance was achieved. Benchmarking should provide a stepping stone for developing new designs and processes that exceed the capabilities of the benchmark companies.

Cause and Effect Diagram: The “cause and effect” diagram is an analytical tool to indicate the relationship between an “effect” and all possible “causes” influencing it. This is sometimes referred to as fishbone diagram, Ishikawa diagram, or feather diagram.

Characteristics Matrix

   A characteristics matrix is a display of the relationship between process parameters and manufacturing stations. A method of developing the characteristics matrix is to number the dimensions and/or features on the part print and each manufacturing operation. All manufacturing operations and stations appear across the top, and the process parameters are listed down the left-hand column. The more manufacturing relationships there are, the more important the control of a characteristic becomes. Regardless of matrix size, the upstream relationships of characteristics are evident. A typical matrix is shown below

CHARACTERISTICS MATRIX

 

(EXAMPLE)

 

		TOLERANCE	OPERATION NOS.
DIM.	DESCRIPTION		05	10	20	30
NO.
1	ID		X	C		X
2	FACE			X	C	C
3				X	L	L
4					X
5					X
6	OD				X

• C = Characteristic at an operation used for clamping
• L = Characteristic at an operation used for locating
• x = Characteristic created or changed by this operation should match the process flow diagram form

Critical Path Method

  The critical path method can be a Pert or Gantt Chart that shows the chronological sequence of tasks that require the greatest expected time to accomplish. It can provide valuable information as to:

• Interrelationships
• Early Forecast of Problems
• Identification of Responsibility
• Resource Identification, Allocation and Leveling

Design of Experiments (DOE)

A design experiment is a test or sequence of tests where potential influential process variables are systematically changed according to a prescribed design matrix. The response of interest is evaluated under the various conditions to: (1) identify the influential variables among the ones tested, (2) quantify the effects across the range represented by the levels of the variables, (3) gain a better understanding of the nature of the causal system at work in the process, and (4) compare the effects and interactions. Application early in the product/process development cycle can result in: (1) improved process yields, (2) reduced variability around a nominal or target value, (3) reduced development time, and (4) reduced overall costs.

Design for Manufacturability and Assembly

Design for Manufacturability and Assembly is a Simultaneous Engineering process designed to optimize the relationship between design function, manufacturability, and ease of assembly. The enhancement of designs for assembly and manufacturing is an important step. Plant representatives should be consulted early in the design process to review components or systems and provide input on specific assembly and manufacturing requirements. Specific dimensional tolerances should be determined based on the like process. This will assist in identifying the equipment required and any process changes necessary.

Design Verification Plan and Report (DVP&R)

The Design Verification Plan and Report (DVP&R) is a method to plan and document testing activity through each phase of product/process development from inception to ongoing refinement. An effective DVP&R provides a concise working document that aids engineering personnel in the following areas:

• Facilitates the development of a logical testing sequence by requiring the responsible areas to thoroughly plan the tests needed to assure that the component or system meets all engineering requirements.
• Assures product reliability meets customer-driven objectives.
• Highlights situations where customer timing requires an accelerated test plan.
• Serves as a working tool for responsible area(s) by:
  • Summarizing functional, durability, and reliability testing requirements and results in one document for ease of reference.
  • Providing the ability to easily prepare test status and progress reports for design reviews.

Mistake Proofing/Error- Proofing

Mistake proofing is a technique to identify errors after they occur. Mistake proofing should be used as a technique to control repetitive tasks or actions and prevent non-conformances from being passed on to the subsequent operation and ultimately the customer. Error-proofing is a technique used to identify potential process errors and either design them out of the product or process, or eliminate the possibility that the error could produce a non- conformance.

Process Flow Charting

  Process flow charting is a visual approach to describing and developing sequential or related work activities. It provides both a means of communication and analysis for planning, development activities, and manufacturing processes.Since one goal of quality assurance is to eliminate non-conformities and improve the efficiency of manufacturing and assembly processes, advanced product quality plans should include illustrations of the controls and resources involved. These process flow charts should be used to identify improvements and to locate significant or critical product and process characteristics that will be addressed in control plans to be developed later.

Quality Function Deployment (QFD)

QFD is a systematic procedure for translating customer requirements into technical and operational terms, displaying and documenting the translated information in matrix form. QFD focuses on the most important items and provides the mechanism to target selected areas to enhance competitive advantages.Depending upon the specific product, the technique of QFD may be used as a structure for the quality planning process. In particular, QFD Phase I – Product Planning translates customer requirements into counterpart control characteristics or design requirements. QFD provides a means of converting general customer requirements into specified final product and process control characteristics.  

A.  ASPECTS OF QFD

The two dimensions of QFD are:

• Quality Deployment: Translation of Customer Requirements into Product Design Requirements.
• Function   Deployment:  Translation   of   Design   Requirements   into appropriate Part, Process and Production Requirements.

B.  BENEFITS OF QFD

• Increases the assurance of meeting the customer requirements.
• Reduces number of changes due to increased engineering understanding of customer requirements.
• Identifies potentially conflicting design requirements.
• Focuses various company activities on customer-oriented objectives.
• Reduces product development cycle time.
• Reduces costs of engineering, manufacturing, and service.
• Improves quality of product and services.

TEAM FEASIBILITY COMMITMENT

Customer:                                                                                          Date:                                                                                               

Part Number:                                                                 

Part Name:                                                                                                                  

Revision Level                                                      

Feasibility Considerations

Our product quality planning team has considered the following questions.

The drawings and/or specifications provided have been used as a basis for analyzing the organizations ability to meet all specified requirements. All “no” answers are supported with attached comments identifying our concerns and/or proposed changes to enable the organization to meet the specified requirements.  

YES	NO	CONSIDERATION
		Is product adequately defined (application requirements, etc. to enable feasibility evaluation?
		Can Engineering Performance Specifications be met as written?
		Can product be manufactured to tolerances specified on drawing?
		Can product be manufactured with process capability that meet requirements?
		Is there adequate capacity to produce product?
		Does the design allow the use of efficient material handling techniques?
		Can the product be manufactured within normal cost parameters? Abnormal cost considerations may include:
		– Costs for capital equipment?
		– Costs for tooling?
		– Alternative manufacturing methods?
		Is statistical process control required on the product?
		Is statistical process control presently used on similar products?
		Where statistical process control is used on similar products:
		– Are the processes in control and stable?
		– Does process capability meet customer requirements?

Conclusion 

Feasible            Product can be produced as specified with no revisions.

Feasible            Changes recommended (see attached).

Not Feasible     Design revision required to produce product within the specified requirements.   Approval 

Team Member/Title/Date	Team Member/Title/Date	Team Member/Title/Date

Team Member/Title/Date	Team Member/Title/Date	Team Member/Title/Date

1. Under “required,” for each item indicate the number of characteristics required. Under “acceptable,” for each item, indicate the quantity that was accepted per customer requirements. Under “pending,” for each item, indicate the quantity not accepted. Attach action plan for each item.
2. Indicate if control plan has been approved by the customer (if required) by circling yes or no. If yes, indicate date approved. If no, attach action plan.
3. Under “samples,” indicate the quantity of samples inspected for each item. Under “characteristics per sample,” for each item indicate the number of characteristics inspected on each sample for each category.Under “acceptable,” for each item indicate the quantity of characteristics acceptable on all samples.Under “pending,” for each item indicate the quantity of characteristics not accepted. Attach action plan for each item.
4. Under “required,” for each item indicate the number of characteristics required. Under “acceptable,” for each item indicate the quantity acceptable per Chrysler, Ford and General Motors Measurement Systems Analysis Reference Manual.Under “pending,” for each item, indicate quantity not accepted. Attach action plan for each item.
5. Under “required,” for each item indicate the quantity required. Under “acceptable,” for each item, indicate the quantity accepted. Under “pending,” for each time, indicate quantity not accepted. Attach action plan for each item.
6. Under “required,” for each item indicate yes or no to indicate if item is required. Under “acceptable,” for each item indicate yes or no to indicate acceptance. Under “pending,” if answer under “acceptable” is no – attach action plan.
7. Each team member should sign form and indicate title and date of signature.

For Control plan click here