Cee Nace cute mm) Process Landscape\VDA-Volume 4: Product- and Process-FMEAPreface ‘The Failure Modes and Effects Analysis (FMEA) is a development and planning accompanying system and risk analysis. It is integrated in the spe- Cialist departments and includes the system optimization as well as the risk reduction. ‘As an important methodical instrument, the FMEA allows possible failures to be identified at an early stage, in order to prevent their occurrence be- forehand. This is important in new concepts and developments, as well as for the further development of products and processes. Their maturity is al~ ready methodically scrutinized and evaluated during the development and planning phases. In all critical places, the FMEA points out suitable actions with whose conduction risks have already been reduced or are still to be minimized. By means of a consequent structuring of the systems and processes with their respective multilevel cause and effect relationships, the FMEA aids the flow of communication in the team and project work, as well as the neces- sary knowledge transfer in the company. The project workflow depicts how the FMEA, as a method of prevention, is integrated into the product devel- ‘opment and production process development. Through the documentation of the FMEA, the company gains a recorded knowledge basis with which current and future development projects are and will be efficiently supported. Preface to the update 2012 ‘The present description of FMEA was formally revised, In particular, the graphics have been unified and regardless of specific software programs to editing an FMEA shown. Specifically, the colour has been explained in the graphs and a suggestion of labelling of unreacted measures has been described. Itis pointed out that no special software program was preferred by these representations. \VDA-Volume 4: Product- and Process-FMEA 3We would like to thank all the companies and collaborators who have contributed in this workgroup: Audi AG Robert Bosch GmbH BMW AG. BP AG.ILS Division Context Management Consulting GmbH DaimierChrysler AG Siemens VDO Automotive Thyssen Krupp Stahl AG Volkswagen AG 2F Friedrichshafen ZF Sachs AG Thanks are also due to all who have provided suggestions for improvement as well as those organizations represented in the editorial circle, Frankfurt/Main, December 2006 Oberursel, March 2009 (update) Berlin, June 2012 (update) 4 \VDA-Volume 4: Product- and Process-FMEAContents Page Preface 3 0 Introduction 10 0.1 Development History of the FMEA 10 0.2 FMEA Objectives 12 0.3 Integration of the FMEA in the Company 14 0.4 FMEA for Products and Processes 18 0.4.1 Product FMEA 5 0.42 Process FMEA 6 0.8 Chronological Process of the FMEA Execution 16 0.6 DAMIC®, Flow Chart For the Workflow of the FMEA 16 0.7 Handling of the Guideline 7 1 Definition > D 19 1.4 Objective of the definition phase 19 41.4 Define the Need for Action for the Execution of an FMEA 19 11.2 Objective of the FMEA 20 12 Time Frame 20 13 Input 20 13.4 Agreements 20 13.2 Procurement of Work Documents 24 14 Work Scope 22 4.41 Task Assignment in the Definition Phase 2 1.42 FMEA Team Building 23 1.4.2.1 Criteria for the FMEA Moderator 23 14.2.2 Criteria for the Other Team Members 23 1.4.2.3 The Formation of the FMEA Team 23 15 Tools and Supplies 23 1.6 Methods 23 1.7 Measurement Variables 26 1.8 Substeps 26 19 Result a 440 Risks 28 4.41 Communication 2 \VDA-Volume 4: Product- and Process-FMEA 52 Analysis +A 29 2.1 Objective of the Analysis Phase 29 22 Time Frame 29 23 Input 29 2.4 — Work Scope 30 25 Tools and Supplies 31 26 Methods 32 27 Measurement Variables 32 28 — Substeps 32 2.8.1 Preparation of the Product FMEA 34 2.8.1.1 Product FMEA (Step 1) Structure Analysis 34 2.8.1.2 Product FMEA (Step 2) Function Analysis, 37 2.8.1.3 Product FMEA (Step 3) Failure Analysis 39 2.8.1.4 Product FMEA (Step 3) Actions Analysis, 41 2.8.1.5 Product FMEA (Step 5) Optimization 46 2.82 Preparation of the Process FMEA 49 2.8.2.1. Process FMEA (Step 1) Structure Analysis 49 2.8.2.2 Process FMEA (Step 2) Function Analysis 52 2.8.2.3 Process FMEA (Step 3) Failure Analysis 54 2.82.4 Process FMEA (Step 4) Actions Analysis 56 2.8.2.5 Process FMEA (Step 5) Optimization 6 2.83 Risk Evaluation 64 29 Result 67 2.10 Risks 68 2.41 Communication 68 a Measures Decision + M 69 3.1 Objective of the Actions Decision Phase 69 32 Time Frame 69 3.3 Input 69 3.4 Work Scope 69 3.5 Tools and Supplies 70 36 Methods 70 2.7 Measurement Variables 70 28 — Substeps 70 39 Result 70 3.10 Risks nm 3.11 Communication a 6 \VDA-Volume 4: Product- and Process-FMEA54 52 53 54 55 56 57 58 58.1 58.2 58.3 5.8.4 59 5.10 Implementation + | Objective of the Implementation Phase Time Frame Input Work Scope Tools and Supplies Methods Measurement Variables Substeps Action Tracing Re-Evaluation of the Remaining Risk ‘Summary of the FMEA Results Result Risks Communication Communication + C Objective of the Communication Phase Time Frame Input Work Scope Tools and Supplies Methods Measurement Variables ‘Substeps ‘Communicate Knowledge Using Knowledge Information and Communication Information Systems Result Risks VDA-Volume 4: Product- and Process-FMEAPage Annex 83 Al Additions 83 11 Execution of the FMEA 83 1.1.1 Implementation of the FMEA in the company 83 1.1.2. Distribution of Tasks When Preparing The FMEA 83 A113. Know-How Protection of the Product FMEA/Process FMEA 84 A114 Reuse of the FMEA 84 A115 IT Application When Preparing an FMEA 84 ‘A1.2 Relationships Between Different FMEAs 85 A124 Levels Within A System 85 ‘1.2.2 Methodical interrelationships Between Different MEAS 86 A13 Special Characteristics 87 ‘14 Relation to Other Methods 88 1.5 Documentation 90 1.5.1. Final Documentation After Completion of all Phases 90 A152 FMEA Form 90 2 Further Application Fields 94 2.1 FMEA for Mechatronical Systems 94 2.1.1. Structure and Function Analysis 94 A212 Failure Analysis 98 A2.1.2.1 "Dormant Failure 100 A241.3_ Actions Analysis and Optimization 100 A214 Evaluation of the Risk 107 22 FMEA for Software Scopes 107 A221 General 108 2.2.1.1 Objective of the Software Scopes Inspection 108 2.2.1.2 FMEA in the Software Development Process 108 A2.2.1.3. Connections to other Methods/Measures of Software Engineering 109 A23 Depiction of Error Propagation 110 ‘A24 FMEA for Machine and Facility Manufacturers 110 8 \VDA-Volume 4: Product- and Process-FMEAAad 42 M43 AA M5 A468 AAT M8 As Page Evaluation of an FMEA 4 Examples of Evaluation Tables 17 Product FMEA Example Table: Product General Severity Criteria S 7 Product FMEA Example Table: ‘Occurrence Potential O for the Product Design 18 Produkt FMEA Example Table: Detection Potential D for the Validation of the Product Design 119 Process FMEA Example Table’ General Process Severity Criteria S 120 Process FMEA Sample Table: Occurrence Potential O for the Process Design 121 Process FMEA Sample Table: Detection Potential D for the Validation of the Process Design 122 Product FMEA Example Table: Product Occurrence Potential © with Assignment of Failure Rates: 123 Product FMEA Example Table: Detection Potential D in Customer Operation 124 Process FMEA Example Table: Occurrence Potential © with Assignment of Failure Rates 125 \VDA-Volume 4: Product- and Process-FMEA 9o Introduction 0.1 Development History of the FMEA. ‘The FMEA was developed by the US military as the MIL-P-1629 military di- rective and dates from 9th November 1949. It was used as an evaluation technique for reliability, in order to depict the effects of system and equip- ment failures. The failures were classified according to the influence on the success, the people, and the equipment safety. awe In 1963, NASA developed the “Failure i BB fh Mode and Effects Analysis” (FMEA) for * innate ns the Apollo project. In 1965, the aero- _ acne (space engineering adopted this meth- maemo any SEBS ‘od. Around 1975 this method was de- area ployed, among other things, in nuclear EE power engineering The FMEA was first deployed in the automotive industry by the Ford Motor Co. (USA) in 1977 for preventive quality assurance. In Germany, in DIN 25448 the Failure Effect Analysis with the subtitle FMEA was standardized in 1980. In the Verband der Automobilindustrie (VDA) this method was de- veloped further specifically for automobiles. The first method description was published in 1986 in VDA volume 4, Quality Assurance Prior to Serial Application. This method has been increasingly used in the automotive in- dustry. The application of the FMEA In the different areas of medicine and tele- ‘communications engineering took place in the 90s. ‘The FMEA is also used in non-technological areas, such as in Facility Man- agement for example, due to the broadening of the term “quality” to include the service industry. In the beginning of 1990, the method for the System FMEA Product and System FMEA Process for the Automotive Industry was developed further based on the FMEA published in VDA volume4 in 1986. In 1996, VDA volume 4, part 2, Quality Assurance Prior to Serial Application with the subtitle System FMEA, was published. The knowledge of the automotive manufacturers and their suppliers was written down there, and the execu- tion of the FMEA was defined. This results in a uniform procedure for the 10 VDA-Volume 4: Product and Process-FMEAFMEA that is universally accepted. The automotive manufacturers, their suppliers and their subcontractors equally approve this procedure. At the end of the 90s, the Deutsche Gesellschaft fur Qualitat e.V. (German Registered Association for Quality - DGQ) founded a workgroup in order to describe the application of the FMEA for additional fields, for example, Ser- vice Industry and Project Management. The DGQ volume 13-11 was pub- lished in November 2001 A further representation of the FMEA in the United States took place in the SAE paper J1739 from June 2000. This SAE paper served for the revision of the FMEA 3" Edition as reference handbook for QS-9000. \VDA-Volume 4: Product- and Process-FMEA "0.2 FMEA Objectives The objectives of the FMEA are derived from the changed influence factors on the company. They are influenced by increased quality demands of the cus- tomer and the necessary cost opti zation of the products and processes, as well as the product liability of the manufacturer required by the legislation ‘The achievement of the business objectives listed below is supported by, among other things, the FMEA: * Increase of the functional safety and reliability of products and pro- cesses, ‘+ Reduction of guarantee and goodwill costs due to the extension of the legal warranty period, Proof of exoneration in the case of product liability, Shorter development times, Low-fault starts of production, ‘Adherence to schedules, Profitable production and assembly, Customer-oriented services, Targeted communication in internal and external customer and supplier relationships, Build-up of a knowledge base in the company, Proof of safety in the registration approval of the vehicles. ‘The FMEA as a method for system analysis and preventive failure avoid- ance is already employed at a very early stage of the product development process, see VDA volume 4, part 3, Project Planning. It examines the de- ‘velopment or planning stages valid at that time for possible falures, in order to initiate actions to avoid these failures. “Avoidance and detection action costs are not FIMEA costs.” 12 \VDA-Volume 4: Product- and Process-FMEAThe FMEA is to be carried out according to the project plan and to be eval- uated at the project milestones according to the state of the analysis. ‘An FMEA already makes sense in an early concept phase, since the FMEA supports the compilation of requirements. The further the development ad- vances, the more detailed the FMEA can become The FMEA is a team-oriented method for risk minimization of the develop- ment and planning processes and facilitates the interdisciplinary coopera tion of the departments involved. Furthermore, it provides @ documentation of expertise in the company. ea eee EE ‘\VDA-Volume 4: Product- and Process-FMEA 130.3 Integration of the FMEA in the Company Today, the FMEA is anchored as a requirement in the individual manage- ment systems of the automotive industry (see VDA 6.1, VDA 6.4, ISO/TS 16949), In further VDA volumes and standards, the FMEA is referred to and/or an FMEA is requited in, for example: VDA 1 Documentation and Archiving VDA 2 Quality Assurance of Supplies \VDA 4 Quality Assurance in the Process Landscape VDA 4.3 Project Planning VDA 6.1 QM System Audit VDA 6.3 Process Audit 10 9001:2000 ISO/TS 16949:2002 In addition to these general requirements in the management systems, the customer orientation plays an important role. Management carries the responsibility for the application and the implementa- tion of the FMEA and has to fully sup- Port the implementation of FMEAs, in order to guarantee the company ob- jectives. Due to these factors, the integration of the FMEA in the company processes is a necessary prerequisite and therefore an integral part of the communication in the management process. 4 \VDA-Volume 4: Product- and Process-FMEA0.4 FMEA for Products and Processes There are two approaches to FMEA: the inspection according to functions or according to processes. The FMEA is also universally applicable for non- technical systems and processes. With the product and process FMEA, all concepts of the FMEA are covered. These could have scopes of inspections such as e.g. system, software functions, interfaces, design, components, production sequences, assembly sequences, logistics, transport and machines. 0.4.1 Product FMEA The Product FMEA inspects the required functions of products and systems, except for the layout of the attributes and characteristics. In the process, the possible non- conformities are inspected and the actions to guarantee the require- ments are defined, 04.2 Process FMEA The Process FMEA inspects all processes for the manufacture of products and systems up to the re- quirements for the process influ- ence coefficients. In the process, the possible non- conformities are inspected and the actions to guarantee the processes and the product characteristics are defined. \VDA-Volume Product- and Process-FMEA 150.5 Chronological Process of the FMEA Execution ‘The preparation of an FMEA should take place as early as possible. ‘The chronological process must be co- ordinated with the project schedule, see VDA 4.3 Project Planning, Annex. At this point, the customers and sup- pliers are to be involved. 0.6 DAMIC®, Flow Chart For the Workflow of the FMEA, Objective and inspection scope: an approach for the execution of the FMEA, consists in achieving a prioritization of the items to be covered. This inspec- tion with a model leads to an efficient processing of the FMEA. The following process model serves as a guideline for the Implementation of the method in the company. Irrespective of this, each company can use its own process model. DAMIC® Model with the following structure: Definitior Preparation and system definition Analysis: Establish requirements and risks systemati- cally Measures decision: Identify actions and procedure Implementation: Implementation and evaluation through veri- fication, validation and monitoring Communication: Present and communicate 16 \VDA-Volume 4: Product- and Process-FMEAPhase Model: DAMIC” CS _emmnton 0.7 Handling of the Guideline The depiction of the method tracks the process-oriented approach as it is also tracked in DIN EN ISO 9000 ff. and ISO/TS 16949. The flow chart shows that one can switch back to the definition phase after the communication phase. An element of every phase is the necessary communication. Each phase includes the process-oriented approach. The efficiency of the phases can be verified by means of the appropriate meas- urement variables. The characteristics that structure each phase result from the process- oriented approach. 1 Objective: ‘The objective of every phase is to be established. 2 Time frame: The start and time requirement of each phase is to be coordinated with the project plan. \VDA-Volume 4: Product- and Process-FMEA 73 Input: 4 Work scope: 5 Tools and supplies: 6 Methods: 7 Measurement variables: 8 Substeps: 9 Result 10 Risks: 11 Communication: Please note: Agreements and necessary work documents at the start of the process and, in the further course, the re- sults from the previous phase. ‘Tasks and activities of the persons responsible and the contributors named in the individual phases. The tools to be employed according to the phase. ‘Supporting methods and procedures that aid the effi- cient execution of the FMEA in the respective phase. Indicators and characteristics that refer to a basis that allow an evaluation of the phase with regard to effectiveness, i.e. the effectiveness for the customer including customer satisfaction and the efficiency, i.e the performance of the phase. ‘The division of the phase into individual substeps. ‘The conversion of the input into results through the ‘sub steps of the individual phases. Identification of the risks that can result from the ap- plication of the process-oriented approach during the execution and implementation in the phases. Communicate the results of the individual phases to those responsible, and process and document for further use. ‘The analyses for the product FMEA and process FMEA are each described completely in a chapter. As a consequence, redundancies are unavoidable. For the user this has the advantage that he/she can turn directly to the Product and/or Process FMEA without knowing the content of the other chapters and tuning back in the text to previous chapters is not necessary. 18 \VDA-Volume 4: Product- and Process-FMEA1 Definition + D s i 41 Objective of the definition phase Defining of boundary conditions and prerequisites for the efficient execution of the FMEA. 11.4 Define the Need for A‘ ion for the Execution of an FMEA The clarification of the necessary scopes for the preparation and/or the up- dating of the FMEA takes place by means of criteria, Examples of this are: ‘+ New development of products. + Producibility. + Safety relevance. © Complexity. © Uso of new facilities, machines or tools, «_ Newsite or relocation of the production. * New operating conditions for existing products, ‘* High share of rejects with similar products, © Mountability. * Environmental and operational hazards, * Produst change. © Process change. ‘* Changed operational conditions. «Insufficient process capability. ‘© Limited verifability. «Warranty and goodwill costs. + Operating expenses. © Comfort. * Field experience. = 8D report Hazard Analysis or Quality Function Deployment (QF), for example, are suitable as further possible decision processes for the need of an FMEA. For this see 1.6 Methods. \VDA-Volume 4: Product- and Process-FMEA 19‘The threshold values for the need for action can be regulated by the re- spective company (see 1.6 Methods). Normally, from the findings of the FMEA, more in-depth methods for subdi- visions are applied, such as Fault Tree Analysis (FTA), Event Tree Analysis, (ETA) and simulations, 1.4.2 Objective of the FMEA ‘The scope of components, functions, processes and/or changes that are to be examined in the FMEA is to be defined by means of the criteria listed above, taking into account the interfaces with other systems. 12 Time Frame © The start of the definition phase must take place at the beginning of the development phase according to the project schedule of the product development process. * The conclusion of the definition phase and therefore the start of the analysis phase have to take place at a time when the releases defined in the project schedule, including the implementation of necessary ac- tions, can be met. ‘+ The time frame for the individual scopes of the definition phase is to be established and documented in a detailed schedule before the first team mesting of the analysis phase. © The time frame for the individual phases of the total FMEA up to the product and/or process release is to be defined; a rough schedule is to be created and integrated into the project schedule, + The detailed schedules of the subsequent phases are to be created at the beginning of the respective phases. 13° Input The following scopes are necessary as the basis forthe defintion phase: 1.31 Agreements The specified person in charge of functions andlor the project manager! customer is responsible for the initiation of the definition phase andor the FMEA, 20 \VDA-Volume 4: Product- and Process-FMEAThe customer's specifications with regard to FMEA must be coordinated with the parties involved andior the suppliers on the basis of the tender or the offer documents, and an agreement must be made about the execution, such as for example definition of system boundaries, necessary work doc- uments, analysis methods, and evaluation tables. The product and process conditions must be clarified with the parties involved. 1.3.2 Procurement of Work Documents Examples of work documents: Project schedule, specifications with adequate details, which are for example customer requirements, system description drawings, function, descriptions, components, networking, interfaces, interactions with oth er systems and peripherals, legal and official regulations, customer regulations, customer/supplier agreements, guidelines for prod- uctiprocess quality objectives, safely concept, diagnosis, usage condi- tions, installation situation, quality regulations, internal regulations and requirements, processes, documented procedures, inspection instruc- tions and/or changes to these scopes. ‘+ Partlists, production, assembly and inspection schedules. ‘© Results from the previous analyses (for example hazard analysis, FTA, QF), use of existent FMEA scopes. + Proof of experience from similaripredecessor products (for example test reports, error lists and field experience). + Legal regulations, procedural requirements, quality regulations, quality- objective definitions, ordinances, safety regulations, standards, classi cation documents. + Specific FMEA evaluation tables. ‘The work documents have to correspond to the current status. \VDA-Volume 4: Product- and Process-FMEA 21.4 Work Scope 1.4.1 Task Assignment in the Definition Phase Ifnecessary, the team members should perform the following: C: Customer, e.g, project manager * Decision about the execution (need for action of an FMEA and/or other methods) Define the responsible person for the execution of the definition phase (can also be identical to the person in charge of function and/or cus- tomeriproject manager) ‘+ Support during information gathering, ‘+ Provision of resources. Responsible Person for the execution of the definition phase Procurement of the necessary documents and information, Coordination and organization of the workflows in the definition phase. Classification of topics, definition of interfaces, team building Responsibility for the result of the definition phase. FMEA Moderator Participation in the team formation Participation in the preparation of the rough schedule. Participation in the invitation to the 1" team meeting for the analysis phase. + Participation in the preparation of the decision guidelines/criteria. T: Team Members Participation in the preparation of the FMEA (classification of topics, definition of interfaces, team building). Contribute experience from similar FMEAs. 22 \VDA-Volume 4: Product- and Process-FMEA142 FMEA Team Building 1.4.2.1 Crit for the FMEA Moderator + Method competence (FMEA). © Social skills, able to work in a team. Competent moderator, ability to convince, organization and presenta- tion skils. 1.42.2 Criteria for the Other Team Members © Expertise for the FMEA scopes that are to be considered. * Basics of the FMEA methodology. 1.4.2.3. The Formation of the FMEA Team + Along with the FMEA moderator, the FMEA basis team must contain the additional competent employees necessary for the respective FMEA scope, These employees must come from the specialist de- partments involved (internal and external) from project, development and/or design engineering, production process planning andlor produc- tion planning, testing, prototyping, production execution, production, in- spection planning and quality assurance. + If necessary, additional experts, for example from the laboratory, cus- tomer service, and legal department, or from customers andlor suppli- ers, are to be involved, 1.5 Tools and Supplies ‘The method of FMEA documentation that includes for example the FMEA tool, flip chart, update, archiving and distribution of information during the FMEA execution and beyond. 16 — Methods Examples of supporting methods: Checklists. Risk matrixes. Mind mapping. Brainstorming, \VDA-Volume 4: Product- and Process-FMEA 23Please see figure 1.6-1 (Example: Prioritization of the scopes) for an exam- ple of prioritization of the scopes, This manner of prioritization evaluates the inspection scopes in terms of applicable criteria. The criteria describe known or assumed risk fields within the product development process. For the execution of the prioritization, the inspection scopes and the evaluation criteria are contrasted in matrix and evaluated according to relevance, ‘The evaluations are tiered for a clear classification of the risks: © Risk does not apply. 1 Risk applies to a minor degree 3 Risk applies 9 Risk applies to a high degree. The total of all individual evaluations defines the priority. From this a corre- sponding need for action can be derived, 24 \VDA-Volume 4: Product- and Process-FMEAara | Tas | PA 2 e]1 az] ° a eee ToT RGA = Sey requremects ° ° 1 tomes ° @PEEER | WEL be TT. |. tl 4 3 Smionty | fear ara zpenty a Taree | OSS] Te | Praia Temes [eae [The Tey ! tll | Fig. 16-1 Example of prioritization of the scope VDA-Volume 4: Product- and Process-FMEA1.7 Measurement Variables Examples of measurement variables: Starting time of the analysis phase according to schedule, Expenditure of workdays for the complete FMEA. The finish time of the complete FMEA in the project until start of pro- duction (SOP). + Number of queries about the definition phase in the subsequent phas- es. 1.8 Substeps Clarify and establish scope of the FMEA andlor other methods. Establish type of FMEA (productiprocess FMEA). ‘Appoint the person responsible for the execution of the definition phase. Appoint the team members and the responsibilities for the definition phase, Organize invitation to the events of the definition phase. Coordinate and organize the workflows of the definition phase. Establish the communication (content and communication channels) for the entire FMEA. Establish the escalation threshold and channels. Clarify and establish the objectives of the FMEA, analysis scope (inter- faves and interactions, among other things) of product/process. * Clarify the product and process conditions with the involved parties. ‘+ Identify the time frame for the complete FMEA, create the rough ‘schedule and integrate it into the project plan. ‘+ Identify the resources/budget demands for the complete FMEA, taking into account the following scopes: The type of FMEA (product or process FMEA), ‘The scope of the examination (range of inspection). The thoroughness of the examination (depth of inspection), The execution procedure. ‘The objectives for the FMEA. The degree of integration achieved. The quality of the preparation. The expenditures for the team members. The quality of the supporting tools and aids. ‘The complexity of the product or process 26 VDA-Volume 4: Product- and Process-FMEA‘+ Coordinate the results of the resources/budget requirements with the management. ‘+ Establish the scopes of the FMEA to be documented, for example, FMEA contents, FMEA accompanying document/cover sheet, FMEA protocol Establish the documentation system for the complete FMEA. Regulate the archiving of the FMEA documentation. Procure the necessary work documents for the analysis phase. Classification of topics, definition of interfaces, team building, ‘Assume responsibility for the result of the definition phase. Establish the team members and the responsibilities for the 1% team. meeting of the analysis phase. ‘Organize the invitation to the 1" team meeting for the analysis phase. Determine the presentation appointments with content/committee. 1.9 Result ‘The following scopes are determined, documented and coordinated with the customer: ‘+ FMEA rough schedule up to the product and/or production process re- lease. Detailed schedule for step 1 of the FMEA, structure analysis (system structure analysis) Invitation to the 1" team meeting of the analysis phase. Service agreement with the people responsible. Personnel and material resources. FMEA scopes (FMEA type, content, responsibilities). ‘System limits with interfaces. The objective of the FMEA for the concrete project, for example ‘+ Quality goals for the product and process (measurement variables). Also cost-optimized repair, among other things (operational costs, cost of ownership). \VDA-Volume 4: Product and Process-FMEA ar1.10 4 28 Risks Responsibilities not clearly established. Incomplete or incorrect specications. Communication problems (customerisupplier relationship. development/production). Deadline difficulties Insufficient planning, for example capacity requirements for FMEA scopes. Inadequate clarification with the customer. Unavailabilty of expert. Qualification deficits of the team members. ‘Communication Regular coordination talks between the parties involved. Reviews, Coordination with the project management. ‘Memos to management. Dialog with suppliers and customers, \VDA-Volume 4: Product- and Process-FMEA2 Analysis +A [el 24 Objective of the Analysis Phase In the analysis phase, all requirements for plausibilty, ability to be verified and validated, and their risks are to be systematically identified. The estab- lished and mature actions and improvement potentials are to be demon- strated for the selected scope. ‘The analysis phase is followed by the Measures Decision. 22 Time Frame The milestones and phases in the project plan provide the time frame for the analysis phase. For the detailed schedule defined in step 1 - the defini- tion phase - for the system structure, the further schedules for the steps two to five of the FMEA are to be created 23° Input ‘The results from the definition phase are necessary as input for the analysis phase, ‘The following scopes are determined, documented and coordinated with the customer: Objective ‘System limits with interfaces, FMEA scopes. FMEA rough schedule up to production process release. Detailed schedule for step 1 of the FMEA, structure analysis. Invitation to the 1* team meeting of the analysis phase. Service agreement with responsible parties, Personnel and material resources. \VDA-Volume 4: Product- and Process-FMEA 29Clarification and provision of documents, such as + Specifications ‘+ In the form of customer requirements, function descriptions, draw- ings, quaiity regulations, test instructions et. + For components, functions, processes and/or changes of these scopes etc. Legal and official regulations Customer regulations, Customerisupplier agreement. Internal regulations and requirements, such as procedural requirements, test instructions. Requirements for product/process quality objectives Project schedule. Results from previous analyses, such as risk analysis, FTA, QFD. Information about comparable products, such as for exemple experience from predecessor products/processes Determination of the necessary documents for the execution of the FMEA. 24 Work Scope FMEA team (core team, FMEA moderator, extended team with experts). R: Responsible Person + Responsible for the adequate execution of the FMEA against schedule and resources. Technical responsibility for the FMEA contents. Preparation of the Measures Decision. Mitigation of conflicts. 30 \VDA-Volume 4: Product- and Process-FMEAM: FMEA Moderator © Managing execution of structure description, function analysis, failure ‘analysis, risk evaluation and the determination of optimization actions. If necessary, preparation or wrap-up of FMEA meetings Moderation of the FMEA workgroup. Analysis of FMEA, suggest actions. Safeguarding of the FMEA documentation. Processing of decision papers. Development and maintenance of the evaluation catalog, T: Team Members Procurement of necessary information about the object of inspection. Demonstration of the developmentiplanning state in the FMEA team * Contribution of existing experiences from previous FMEAS already known. + Parficipation in the execution of the structure description, function ana~ lysis, failure analysis, risk evaluation and the determination of optimi- zation actions. Involvement in the preparation for the Measures Decision. m Experts «Procurement of additionally necessary information about special topics. # Procurement of necessary information about the object of inspection. * Involvement in the preparation for the Measures Decision. 25 Tools and Supplies Flip chart, wall chart, teamwork room, software for the preparation of the FMEA documentation with a computer, video projector, viewing objects, access to internallextemal data for FMEA etc. oo \VDA-Volume 4: Product- and Process-FMEA 3426 Methods Hierarchical structure, structured brainstorming, logical links, weak-point analysis, risk evaluation etc, 2.7 — Measurement Variables Inspected scope against determined scope. Actual time frame against target time frame. All necessary personnel and material resources, such as team mem- bers (external and internal) and FMEA tool, are available and adequate at the planned date. + Allestablished and necessary documents from the definition phase are available and sufficient. ‘+ The evaluation of the results is carried out in the team and on schedule. 2.8 Substeps ‘The FMEA is carried out in five steps. These five steps communicate the systematic approach in the FMEA and safeguard the coherent documentation. 32 \VDA-Volume 4: Product- and Process-FMEAaimonas tepshe 9019 « ‘squou 219 ponjonuy eq) eamonas ‘smes ‘snqeys poBueyo queuino ayenyeng « ‘enpeag « ‘seunye)yur1= — suonauny Ur + ssuopoe ‘suon _uonasiep pue suopouny squ0woye -oejeuomppe —souRplone uss «ap oysosn—_ suman out oy ines sonpey + “uno quewnseg- —-He4 uByssy » suojouny ubjssy « ‘pue piooey « i uulese< EISEeeS| | ant) ‘Sisheuy suonoy sishjeuy eunyes SIBAIEUY UoRDUNS das vs das dos 4 8 yi ‘suonoy pur sisheuy S14 sishjeuy wersks VAIN 24} Jo UoMEIeGaId 84} 10} SaE}S orl oul The five steps for the preparation of the FMEA. Fig. 28-1 the steps 3 to 5 are carried ‘The steps 1 (Structure Analysis) and 2 (Function Analysis) can be carried out sequentially or simultaneously. Afterwards, ‘out sequentially. 33 VDA-Volume 4: Product- and Process-FMEA281 Preparation of the Product FMEA 2.8.1.1. Product FMEA (Step 1) Structure Analysis Structure Analysis TH objectives of a structure analysis are: “<< ‘The system consists of individual system elements (SE) that are arranged hierarchically for the description of the structural connections, for example hardware concept. ‘Overview of the inspected product. Reuse of modules. Classification and interface description. Establish responsibilities, During the preparation of the system structure, the degree of detailing of an FMEA is dependent and can therefore not be globally established. To what extent a structure must be analyzed in more detail depends on many factors, The following criteria supports the identification of the inspection depth: © fan unacceptable and/or incalculable risk is found during the analysis (steps 1-5) of an inspection scope, additional detailing is necessary + The detailing is ended if failures in this degree of detailing are suffi- ciently secured by actions. ‘+ With known and operationally proven inspection scopes, a lesser de- gree of detailing is necessary than with new scopes. © The lowest level of inspection is the characteristics of the components (the characteristic level). ‘The clearly structured illustration of the complete system is thereby guaran- teed by the fact that each system element only exists once. The structures arranged under each SE are independent substructures (see figures 2.8.4.1-1 and 2.8.1.1-2). 34 \VDA-Volume 4: Product- and Process-FMEADue to the structuring, interfaces are also generated on physical connec- tions (that exist in the system) from an SE of a substructure to an SE in other substructures. All functional connections between the SEs are to be described, including the interfaces of the inspected system structure and beyond, There is always a structure element present, even if it is only derived from the function and cannot yet be specified more clearly. Pere] Saar) 9 HK SSS NN Lv] Fig. 2.8.1.1-1 Example of system structure up to the component level ee \VDA-Volume 4: Product- and Process-FMEA 36screen Fig. 2.8.1.1-2 Example of system structure up to the characteristics level of the components 36 \VDA-Volume 4: Product- and Process-FMEA2842 Product FMEA (Step 2) Function Analysis Function Analysts TR objectives ofa function analysis are: | * Overview of the functionality of the product. enol Overview of the cause-effect relationships. Verification against the customer require- ments, © Basis for the failure analysis. ‘The system structure described by SEs provides the basis so that each SE can be analyzed as differentiated as necessary with regard to its functions and failures in the system, For this, comprehensive knowledge of the system and the ambient condi- tions of the system are necessary, for example heat, cold, dust, splash wa- ter, salt, icing, vibrations, electrical failures etc. Functions Each SE has different functions and/or tasks in the system (see figure 2.8.1.2-1), Generally, the functions of other SEs are also necessary for the fulfilment of the individual functions of an SE. ‘The description of the function must be clear, and it must be possible to ver- ify ang validate it. For better overview functions are shown in green in the graphics. Function Structures ‘The interaction of the functions of several SEs must be demonstrated, for example as @ function network, function structure, function tree, and flow charts, For the preparation of the function structures of an SE, the functions that are involved must be examined. Subfunctions that in sum describe a function are linked logically with each other in the allotted function structure, This serves the completion of the functional demonstration. The detailing of a function structure increases from left to right. The right function describes how the previous function is to be fulfilled. For the logical linking of a function structure, the questions "How?" (from left to right) and "Why?" (from right to left) are therefore helpful a \VDA-Volume 4: Product- and Process-FMEA 7EE) ions way Sey 200 haut oa epnenio _A00 mi ema Taw or = we not hm op eohsaroo} {nob mundo e004 InN Ge = widvans euawn| nsb hmong easiroes5} us o1evs nae} ‘9 wos bien asus ‘sob ian ‘agus 1 93] q Fig. 2.8.1.2-1 Example of a function structure \VDA-Volume 4: Product- and Process-FMEA2.8.1.3 Product FMEA (Step 3) Failure Analysis Failure Analysis The objectives of a failure analysis are: «Identification of the possible failures, assigned to system structure and to functions. ‘© Links ofthe fallures to the failure structures. © Basis for the illustration of failures in @ form anandior the preparation of the form. ‘A failure analysis must be carried out for each SE inspected in the system description. Possible failures are deduced from the functions, for example nonconformi- ties from specified function target states, limited function, unintentional func- tion or exceeding a function. ‘The description of the failure must be clear. Non-fulfilment, not OK, defec~ tive, broken and so on do not suffice to comprehensively assign the failure cause, failure mode and to determine actions. For this, the operating cond- tions of the product are to be considered. Generally, many fallures are associated with a function. For better overview functions are shown in red in the graphics Failures Structures Built up on the known functions, the failures are derived and failure struc tures (failure treesifailure networkifault treelfault network) are created for the failure analysis (see figure 2.8.1.3-1). For this, failures are linked ac- cording to cause and effect. Depending on the focus, a failure can be viewed as a failure cause, failure ora failure mode. The created failure structures are transferred to the cor- responding columns ,Potential Failure Modes’, ,Potential Failure", and “Po- tential Fallure Causes" of the FMEA form. Depending on the depth of the failure structure, itis possible to create the analysis on different levels and to illustrate the contents of the failure struc~ tures in the three form columns, a \VDA-Volume 4: Product- and Process-FMEA 39‘ie) see eg pou amy ue oes Roave og Sones ose eRe Taos siemonnoy sou ones| [SSSR ERT SORT OS sai; uorstasuen enbios | —{ seu Sujado Jo ounsnpy| ‘poneod onan TENET oTESTH] we yobsqus ou buted. eet Seuctiod enon VDA-Volume 4: Product and Process-FMEA Failure structure based on the throttle positioner Fig. 2.8.1.3 402.8.1.4 Product FMEA (Step 4) Actions Analysis Actions Analysis The objectives of the actions analysis are: ‘= Assigning the existing and/or already estab- lished actions to the failures. © Risk evaluation. There are two different actions groups: the Preventive actions and the de- tection actions Preventive Actions (PA) Preventive actions in the development facilitate the optimal system layout and/or the characteristics layout so that the occurrence potential of the fail- ure possibility is very low. Preventive actions must be clearly and comprehensively described. If nec- essary, this can be done by reference to an additional document. The indi- cation “proven material” is not enough. Preventive actions could be: ‘* EMC directives adhered to, directive 89/336/EEC «System design according to simulation, tolerance calculation and VAT. © Tolerances taken over from drawing number ZN 1.239.876 Preventive actions in customer operation and in the service are described in Chapter 7, "Additional Fields of Application” Detection Actions (DA) By using detection actions in the development, the possible failures are found andor the effectiveness of the Preventive actions is confirmed. Detection actions must be clearly and comprehensively described. If neces- sary, this can be done by reference to an additional document. The indica- tion “Test or lab test” is not enough. VDA-Volume 4: Product- and Process-FMEA aDetection actions for the validation of the layout can be: SV 1646a simulation process Function check according to test plan PP 136-07 Burst test according to PR 196-00 Climate change test according to test plan 1723 Driving test according to DE44 Endurance test according to PST 1000 Drawing check according to ZN 9.214.543 Lab tests according to PV 5768 Detection actions in customer operation and in the service are described in Chapter 7, “Additional Fields of Application’, Responsible Person and Deadline ‘A responsible person (R) and a deadline (DL) are assigned to each action. The responsible person sees to the decision of the action and, if confirmed, to the implementation. Deadlines are to be set early enough so that the implementation before the production release is guaranteed. The deadline is to be specified with the date. If the responsible persons and the deadlines are not entered into the form, these are to be defined in assigned documents, Status of the Actions: a) Unprocessed Idea gathering, implementation of the action has not begun yet b) Decision pending ‘The action has been defined but not yet decided A decision paper is being created, ©) Implementation pending The action has been decided and not implemented yet 42 \VDA-Volume 4: Product- and Process-FMEAd) Completed Completed actions have been implemented and their effectiveness has been demonstrated and documented; a final evaluation has been carried out. e) Discarded Discarded actions are documented and generally require an optimi- zation, phases A and | (see Step 4, Actions Analysis). Evaluations ‘The risk connected to each cause of failure is evaluated. For the evaluation of the risk, avoidance and detection actions recorded in the development and planning stage are consulted For this S stands for the severity of the failure mode, © __ stands for the occurrence potential of the failure cause, and 1D _ stands for the detection potential of the occurred failure cause, fail- Ure andior failure mode. Evaluation numbers from 10 to 1 are used for S, O, and D respectively, in ‘which 10 stands for the highest risk contribution. By means of single examinations and combinations of these three factors, prioritizations can be conducted (see section “Evaluation of the Risk’). Examples for the preparation of evaluation tables are found in Chapter 9, ‘Samples of Evaluation Tables. Severity (S) ‘The evaluation number $ is determined by the severity of a failure mode at the highest level of the inspection scope andlor at the interface defined for the superordinated system. Therefore, “10” or *9" is given, for example, if a failure affects the safety andjor If it violates the compliance to legal regulations, or if it constitutes an existence-endangering risk to the company. At" is given, for example, if the failure mode constitutes a very small im- pairment to the function that is only identifiable by experts. oo \VDA-Volume 4: Product and Process-FMEA 43For a comprehensible evaluation, product group-specific evaluations check- lists are created that, if stated in the contract, are to be coordinated with the customer. The evaluations of the failure modes have to be mutually agreed upon by the manufacturer and the customer (subpurchaser). If the failure modes are not known, the severity is to be evaluated at S=10. Avoidance and Detection A‘ ns Evaluations for the occurrence and detection potential (D and ©) are given according to the effectiveness of the avoidance and detection actions car- ried out forthe inspected failure causes The more detailed the failure analysis of the FMEA is carried out for the ‘causes, the more differentiated the evaluations O and D can be undertaken. ‘The © and D evaluation of causes in the FMEA can fall back on empirical values (such as reliability rates of comparable systems). If already evaluat- ed subsystems are integrated into a new system, the evaluations are to be checked, due to the possibly modified boundary conditions of the new sys- tem. Occurrence Potential (0) O describes the occurrence potential of the failure cause during the lifecycle Of the vehicle, taking into account the associated preventive actions. The evaluation number is always to be understood as @ relative estimation instead of as an absolute measured value according to the current state of knowledge 'n the preventive preparation of the FMEA, the O-value expected according to the current state of knowledge is assessed before the execution of the detection actions. 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, 44 \VDA-Volume 4: Product- and Process-FMEA‘After the application of the detection action during the development and ver- ification of the effectiveness of the preventive actions, the O-evaluation is tither confirmed or corrected according to the result of the detection action. A“40°, for example, is given in the O-evalvation if the inspected failure cause occurs with high potential, no avoidance action exists andior its ef- fectiveness is not known. 'A“", for example, is given when It is improbable that the inspected failure cause occurs. Detection Potential (D) ‘The evaluation of the detection potential is carried out taking info account all the detection actions specified for it. Here the DA can be consulted for the failure cause of different levels, The evaluation number "10", for example, is given when it is impossible or improbable that the failure will be detected in time or at all, or f no detection actions exist. The evaluation number * ed easily and in time. " for example, is given when the failure is detect- ‘The evaluation number “1”, for example, is given when an inspected failure cause is discovered easily during the development by the sum of all testing measures. ‘After decision and implementation of the action and of phases A and |, the effectiveness is to be verified and re-evaluated. a VDA-Volume 4: Product and Process-FMEA 45Evaluation at the Time of inspection The time of inspection is taken into consideration for the evaluation of © and D actions. In order to depict the current state, the potential of occur- rence and the detection of the failure cause are first evaluated, taking into account the already completed actions, The actions not yet implemented are additionally included for the evaluation of the expected state. This evaluation is to be labeled. The type of labeling is optional. ‘The analysis of the evaluation is described in Chapter 2.8.3, Risk Evaluation, 2.8.1.5 Product FMEA (Step 5) Optimization The objectives of an optimization are: * Identification of the actions necessary for im- provement. © Assessment of the risk. * Checking the effectiveness of the implement- ed actions, * Documenting the implemented actions. If the result of the evaluation of the status is not satisfactory, new actions are suggested. These actions are processed analogous to step 4. A new actions status is produced. These new actions are evaluated in advance, are provided with responsible persons and deadlines, and are decided on After the implementation of the actions, an effectiveness check is to be car- Tied out and the evaluation is to be examined. If it becomes apparent that the action has not produced the desired result, the optimization is to be per- formed as often as needed until an acceptable result is reached. The optimization takes place in the following order: * Concept modification in order to eliminate the failure cause and/or to obiain a failure mode with a low severity — ee 46 \VDA-Volume 4: Product- and Process-FMEA«Increase of the reliability of the components in order to minimize the ‘occurrence potential of the failure cause + Effective detection of the failures In the case of concept modifications, all five steps of the FMEA are run through again for the affected sections. ‘The following figure shows a possible depiction of the information on the form. The evaluation of the expected state Is denoted here with round brackets. a VDA-Volume 4: Product- and Process-FMEA a7Example of an FMEA form for the Product FMEA (Development) Fig. 28.1.5-4 \VDA-Volume 4: Product- and Process-FMEA 482.8.2 Preparation of the Process FMEA 2.8.2.1 Process FMEA (Step 1) Structure Analysis Structure Analysis The objectives of a structure analysis are: ‘The process system consists of individual system elements (SE) that are arranged hierarchically in a system structure (for example workflows, tech- nology concepts) for the description of the structural connections in the complete system Overview of the inspected product. Reuse of modules. Classification and interface description. Determine responsibilities. During the preparation of the system structure, the level of detailing of an FMEA is process-dependent and can therefore not be generally deter- mined. To what extent a structure must be analyzed in more detail depends on several factors. The following criteria support the identification of the examination depth: © If. an unacceptable and/or incalculable risk occurs during the analysis (steps 1-5) of an examination scope, additional detalling is necessary ‘* The detailing is ended if failures in this degree of detalling are suffi ciently secured by actions. With known and operationally approved examination scopes, a lesser degree of detailing is often necessary than with new scopes, © In the process, the lowest levels of examination are the classic “4M” (Man Machine Method Material) ‘The clearly structured illustration of the complete system is quaranteed by the fact that each SE exists only once. The structures assigned under each SE are independent substructures (see figure 2.8.2.1-1, Example of System Structure). SS VDA-Volume 4: Product and Process-FMEA 49In the process FMEA, the so-called 4M are examined in the lowest levels. These serve as reminders in order to illustrate all relevant influencing fac- tors in the process. These can be: Man stands for fitter, machine operator, production associate, manager ete. Machine stands for robot, primer, hopper reservoir tank, color mixing unit heating of the plastifying unit, injection molding form, spiral conveyor etc. Material stands for intake tread, bearing surface, synthetic granules, col- or batch, plasticized synthetic material etc. Method stands for ambient conditions such as heat, dust, contamination etc. Due to the structuring, interfaces occur on connections (that physically exist in the system) of one SE of a substructure to an SE in other substructures. All functional connections between the SEs are to be described, also be- yond the interfaces of the inspected system structure. There is always a structure element present, even if it is only derived from the process and cannot be specified more precisely yet. 50 \VDA-Volume 4: Product- and Process-FMEA[iansnans epee ecm ery es Fig. 2.8.2.1-1 Example of System Structure ee VDA-Volume 4: Product- and Process-FMEA 512.8.2.2 Process FMEA (Step 2) Function Analysis Function Analysis ‘The objectives of a function analysis are: * Overview of the workflows in the process * Overview of the cause-effect relationships « Verification against the process planning + Basis for the failure analysis The system structure (structure tree) described by the SEs provides the ba- sis so that each SE can be analyzed as differentiated as necessary with re- {gard to its function and failures conceming the procedure in the system. For this, comprehensive knowledge of the system and the ambient condi- tions of the system are necessary, for example the product requirements or characteristics, functions and process requirements andior costs, time, oc- cupational safety, environmental impact. Functions/Workflows Each SE has different workflows, tasks and/or functions in the system, in- dependent of its position in the structure (see figure 2.8.2.2-1). Generally, the functions of other SEs are also necessary for the fulfillment of the indi- vidual functions of an SE. The description of the function must be clear, verifiable, and it must be pos- sible to validate it For better overview functions are shown in green in the graphics. Function Structures/Workflow Structures The interaction of the workflows of several SEs must be demonstrated, e.g as function network, function structure, function tree, or flow charts. For the preparation of the function structures of an SE, the involved functions must be inspected. Subfunctions that in sum describe a function are logically linked with each other in the assigned function structure. The detailing of a workflow structure increases from left to right. The right workflow describes how the previous workflow is to be detailed. For the log- ical linking of a function structure, the questions "How?’ (from left to right) and "Why?" (from right to left) are therefore helpful SS 52 \VDA-Volume 4: Product and Process-FMEATonitop arohdnsonouls won] te Gaze 90 Cae “Gumtap oy Gupuodseno9 eave 9200 Example of a Function Structure Fig. 2.8.2.2-1 \VDA-Volume 4: Product- and Process-FMEA2.8.2.3 Process FMEA (Step 3) Failure Analysis Failure Analysis The objectives ofa failure analysis are ‘© Identification of the possible failures, assigned to system structure and to functions. Linking the failures to the failure structures. Basis for the illustration of the failures on the form and/or preparation of the form. AA failure analysis must be carried out for each SE inspected in the system description. Possible failures are deduced from the functions/tasks, e.g. nonconformities from specified target state of the facilities, not completely executed tasks, unintentional activity or unnecessary activity. ‘The description of the failure must be clear. Non-fuffllment, not OK, defec- tive, broken and so one are not sufficient to comprehensively assign the failure cause and mode and to determine actions. Generally, several failures are associated with a function. For better overview functions are shown in red in the graphics Fallure Structures Based on the known functions, the failures are derived and failure struc- tures (ailure trees/failure network/faulttreeffailure network) are created for the failure analysis (see figure 2.8.2.3-1). Depending on the focus, a failure can be inspected as a failure cause, fail Ure, or a failure mode. The failure structures that were created are tra ferred to the corresponding columns “Potential Failure Modes’, “Potential Failure’, and “Potential Failure Cause” of the FMEA form. Depending on the depth of the failure structure, it is possible to prepare the analysis on different levels and to represent the contents of the failure struc- tures in the three columns of the examples. 54 \VDA-Volume 4: Product and Process-FMEATames 49 S0BnNED joNUOIO ‘Spout oinyey eH ‘anges yo sane jenusiog ph Pepron] a woauneu ana aie Sue ‘saves axa syarg 1098 ot ee ee evan Supra creat aseon puna bape eaeahs| | en eb kmuad eno oMDOIUE ‘apart asea Buneae ou pawUTUTTAD| uy096 pu syeg se98 Aveu eavon ura vane) Tanar oat sessed =] aS Te] owes wou uotssusuen onbiey 0 2un Gazensard oy owes Our Baus paso you SaaS en renew 0 Bate Example of Failure Structure Based on the Manu- facture of the Primary Gear VDA-Volume 4: Product- and Process-FMEA Fig. 2.8.2.3-1‘Actions Analysis Th® objectives of the actions analysis are: Assigning the failures to the existing and/or al- ready determined actions. © Risk evaluation ‘There are two different action groups: the preventive actions and the detec- tion actions, Preventive Actions (PA) Preventive actions in the development facilitate the optimal process plan- ning so that the occurrence potential of the failure possibilty is very low. Preventive actions must be clearly and comprehensively described. If nec- essary, this can be done by reference to an additional document. The indi- cation “proven process” is not enough. Preventive actions can be © Process planning ‘* Detection of possible layout deficiencies of the production facility, .g. test runs according to start-up regulation AV 17/3 Production process: Detection of defectively produced parts in the production facility, test station 25 Use of A003.7 device ‘Two-handed operation of machines ‘Subsequent part can not be attached Form-dependent position 56 \VDA-Volume 4: Product- and Process-FMEADetection Actions (DA) By using detection actions in the process planning, the possible failures are found andior the effectiveness of the action is confirmed. Detection actions must be clearly and comprehensively described. If neces- sary, this can be done by reference to an additional document. The indica- tion “Intermediate test, dimensional check, etc” is not enough, Detection actions for the validation of the layout can be: Visual inspection according to AA 15.08 ‘Visual inspection with sample checklist MKO05.3 Optical test with limit sample GM368 Attributive test with mandrel! 46565, Dimensional check with a caliper gauge 159/3, Random inspection 50-0 Responsible Persons and Deadline ‘Aresponsible person (R) and a deadline (DL) are assigned to each action. ‘The responsible person sees to the decision of the action and, if confirmed, to the implementation. Deadlines are to be set early enough so that the implementation before the production release is guaranteed. The deadline is to be specified with the date. If the responsible persons and the deadlines are not entered into the form, these are to be established in related documents. Status of the Actions: a) Unprocessed Idea gathering, implementation of the action has not yet begun. b) Decision pending The action has been defined but has not yet decided on. A decision paper is being created. a \VDA-Volume 4: Product- and Process-FMEA 87©) Implementation pending ‘The action has been decided but not yet implemented. 4) Completed ‘Completed actions have been implemented and their effectiveness has been demonstrated and documented, a final evaluation has been done, e) Discarded Discarded actions are documented and generally require an optimiza- tion, phases A and I (step 4, Actions Analysis). Evaluations The risk connected to each failure cause is evaluated. For the evaluation of the risk, avoidance and detection actions recorded in the development and planning stage are consulted, For this s stands for the severity ofthe failure mode, ° stands for the occurrence potential ofthe failure cause, and D stands for the detection potential of the occurring fallure cause failure and/or faiture mode. For S, O, and D, evaluation numbers from 10 to 1 are used respectively, in which 10 stands for the highest risk contribution. By means of individual inspections and combinations of these three factors, prioritizations can be conducted (see the section “Evaluation of the Risk’). Examples for the preparation of evaluation tables are found in chapter 9. Examples of Evaluation Tables. Severity (S) The evaluation number $ is determined by the severity of a failure mode at the highest level of the inspection scope andior at the interface defined for the superordinated system. ‘Therefore, the “10” or “9” is given, for example, if a failure affects the safety and/or if it violates the compliance to legal regulations, or if it constitutes an existence-endangering risk to the company. 58 VDA-Volume 4: Product- and Process-FMEA‘The “1" is given, for example, if the failure mode constitutes a very small impairment to the function thet is only identifiable by experts. For a comprehensible evaluation, product group-specific evaluation check- lists are created that, if stated in the contract, are to be coordinated with the customer. ‘The evaluations of the failure modes have to be mutually agreed upon by the manufacturer and the customer (subpurchaser). If the failure modes are not known, the severity is to be evaluated with 0. Avoidance and Detection Actions Evaluations for the occurrence and detection potential (D and ©) are given ‘according to the effectiveness of the avoidance and detection actions car- ried out for the inspected failure causes The more detailed the failure analysis of the FMEA is carried out for the causes, the more differentiated the evaluations O and D can be carried out. The O and D evaluation of causes in the FMEA can fall back on empirical values (e.g. reliability rates of similar systems). If already evaluated subsys- tems are integrated into a new system, the evaluations are to be checked due to the possibly modified boundary conditions of the new system, Occurrence Potential (0) © describes the occurrence potential of the failure cause in the process, taking into account the associated preventive actions. The evaluation number is always to be understood as a relative assess- ment instead of as an absolute measured value according to the current state of knowledge. In the preventive preparation of the FMEA, the O-value expected according to the current state of knowledge is assessed before the execution of the detection actions, Expertise or other experiences from comparable processes, for example, can be consulted for the assessment of the evaluation numbers. os \VDA-Volume 4: Product- and Process-FMEA 59After the application of the detection actions in the process and verification of the preventive actions effectiveness, the O-evaluation is either confirmed or corrected according to the result of the detection action. ‘A "10", for example, is given in the O-evaluation if the inspected failure cause occurs with high potential, no avoidance action exists andior its of- fectiveness is not known. A“1", for example, is given when it is improbable that the inspected failure cause will occur. Detection Potential (D) The evaluation of the detection potential is carried out taking into account all the detection actions specified for it within the complete production pro- cess. In this connection, the DA can be consulted for the failure cause of different levels, The evaluation number “10", for example, is given if it is impossible or im- probable that the failure will be detected in time or at all, or if no detection actions exist. The evaluation number “1”, for example, is given if the failure Is detected easily and in time. The evaluation number “1", for example, is given when a production failure in the process is easily detected at the location of the failure cause. After decision and implementation of the action - phases A and |, the effec- tiveness is to be verified and re-evaluated, Evaluation at the Time of Inspection The time of inspection is taken into consideration for the evaluation of O and D actions. In order to demonstrate the current state, the potential of oc- currence and the detection of the failure cause are first evaluated, taking in- to account the already completed actions. The actions not yet implemented are additionally included for the evaluation of the expected status. This evaluation is to be labeled. The type of labeling 's optional The analysis of the evaluations is described in chapter 2.8.3, Risk Evalua- tion, 60 \VDA-Volume 4: Product- and Process-FMEA2.8.2.5 Process FMEA (Step 5) Optimization The objectives of an optimization are: Optimization ‘2 Identification of the actions necessary for im- provement. © Assessment of risk © Checking the effectiveness of the imple- mented actions, © Documenting the implemented actions. If the result of the evaluation of the status is not satisfactory, new actions are suggested. These actions are processed analogous to step 4. A new actions status is generated. These new actions are evaluated in advance, are provided with responsible persons and deadlines, and are decided on. After the implementation of the actions, an effectiveness check is to be car- ried out and the evaluation is to be validated. If it becomes apparent that the action has not produced the desired result, the optimization is to be per- formed as often as necessary until an acceptable result is reached, ‘The optimization takes place in the following order: «Process modification in order to eliminate the failure cause and/or to obtain a failure mode with a low severity. + Increase of the stability of the processes, in order to minimize the oc- currence potential ofthe failure cause. «More effective detection of the failures. In the case of process modifications, all five steps of the FMEA are run through again for the affected subsections. The following illustration shows a possible depiction of the information in the form. The evaluation of the expected status is denoted here with round- brackets. \VDA-Volume 4: Product- and Process-FMEA 61ma man | neon ad om vnemeou fl] yanioas [] ‘edmuy seu pue oped anes \VDA-Volume 4: Product- and Process-FMEA 62Fig. 2.8.2.5-1 Example of FMEA Form for Process FMEA, 63 \VDA-Volume 4: Product- and Process-FMEA2.8.3 — Risk Evaluation ‘The evaluations S, O, and D are consulted for the risk evaluation, Derivatives from the SOD Evaluations Anhiigh S value shows a high potential extent of damage. Conclusion: low occurrence potential and/or reduction of the damage extent is necessary. Aniigh © value demonstrates a (potential frequent occurrence of the failure cause, The frequency of the failure mode occurrence can often not be concluded from the occurrence of the failure cause. The occurrence of the associated failure mode can be significantly more seldom. If D describes detection actions in the development, a high value for D indi- cates that the detection action is unsuitable to efficiently detect the failure and cannot effectively confirm O. If D describes detection actions in customer operation, a high value for D indicates that an occurring failure was not detected, or not detected in time to prevent or to minimize the failure mode. Combinations of Individual Evaluations Combinations of evaluations from the FMEA can be used in order to demonstrate different risks and to deduce a possible need for action. ‘The decision whether an action is necessary (actions decision phase) can in certain cases not be made only by inspecting the values 8, O and D. For example, the potential that a failure cause also actually lead to a failure mode is not considered by any parameters; however it plays an essential role in the actions decisions. In cases in which several causes have to come together in order to produce a failure mode, the application of other methods, such as e.g. the fault tree analysis, can make sense for the deci- sion about actions, 64 \VDA-Volume 4: Product and Process-F MEAStatement about O and D Evaluation While the © evaluation describes the estimated quantity of faulty products, the D evaluation states how easily the occurring failure can be detected. Risk Matrix ‘A further possibilty for the classification into risk classes can be carried out by an. individually determined tabular classification, with which non- linearities and different weightings of damages can also be considered. ‘The risk matrix makes the classification of the risk for the determination of the need for action and/or as release requirement possible, among other things. The risk matrix shown here and the limit values included in it are intended solely for the explanation of the method. The limit values are to be deter- ined as company and/or project-specific. 123456789 00 § Fig.2.8.3-1 Example of Risk Matrix \VDA-Volume 4: Product- and Process-FMEA 650 Severity of the failure mode at higher level (vehicle, driver, environ- ment) taking into consideration the system reactions due to the detec- tion actions (D) in the system and/or the severity of the failure mode for the manufacturer. © Occurrence potential (0) of the failure cause in the field and/or the oc- currence potential of the failure cause at the manufacturer minus the failures of the process FMEA detected by the detection actions (= slip). Green zone: there is no need for action. + Yellow zone: there is no imperative need for action, the risk should be reduced by appropriate actions. © Red zone: ‘There is a need for action, the risk must be reduced by appropriate actions. Prioritization with Individual Limit Values for S, © and D The following method provides an easy possibilty to prioritize: 1. Select all failure causes that lead to an S$ > limit value for S, @.g. all S > 9, or all $> 8, or all S > etc. 2. Select all failure causes from this group with O > limit value for O, e.g. all 0 > 1, or 0 > 2, or O > ete, 3. From this, select all failure causes in which D > limit value for D, e.g. all D>8,orD>6, orD > etc. ‘The groups obtained in this way contain the failure causes with the highest priority. The method can now be run through repeatedly with different limit values, so that several groups with different priorities are formed. 66 \VDA-Volume 4: Product- and Process-FMEARisk Priority Number (RPN) The result of the multiplication of the three evaluations numbers S x O x D is referred to as the Risk Priority Number. In many cases, the inspection of the absolute value of a risk priority number is misleading and not appropriate as the basis for further actions. A relative comparison of the individual risk priority numbers can also be misleading, It does not make sense to define a “rigid RPN” as the intervention limit (e.g, from RPN > limit), since the evaluation criteria can possibly be different for each FMEA, The results in the problem that the same RPN values do not necessarily mean the same risk. Based on the RPN = 100, this value can arise through (Sx 0 xD) = (10 x 1 x 10) or also through (S x O x D) = (10x 10x 1). ‘Therefore the RPN has a low significance regarding the quality of products and processes. Note ‘The FMEA delivers @ predominantly qualitative evaluation. Due to the sub- jective assessment and its uncertainty, it is only conditionally suitable as a method for quantitative evaluation. For this, other appropriate methods are to be applied. 2.9 Result ‘The documentation for the FMEA is available by the end of the analysis phase: + Detailed schedule for the step 2 to step § of the FMEA, function analy- sis until optimization. + The established FMEA scopes are processed according to the objec- tives. + System structure. * Function structure. + Failure structure. ‘VDA-Volume 4: Product- and Process-FMEA er‘© Related and coordinated evaluation checklists, © Evaluations, © Optimization, * Actions checklist with persons responsible/deadiines/status © The actions decision is prepared. 2.10 Risks * Deficient coordination between product and process or customer and supplier. No customer requirements for the severity. FMEA schedule is not in ine with project plan. Processing scopes not completed at the required milestone. Responsibilities not clearly established, Incomplete or faulty specifications. Unexpected test and inspection results Deficient decision or escalation preparation. Incorrect actions decision, Availability problems of the FMEA team members. Inadequate planning (such as increased capacity requirement for FMEA execution). 241 Communication ‘After the risk evaluation of the individual potential failure causes has taken place, a memo to management about the results of the analysis phase should be prepared ‘The contents of the communication are, for example: Information about the work carried out Information about necessary actions Information about further need for optimization Information whether risks are sufficiently avoided. This data is recorded into the project progress evaluation by the complete project management within the project review (see VDA 4.3), 68 \VDA-Volume 4: Product- and Process-FMEA,3a Measures Decision + M Radi 3.1 Objective of the Measures Decision Phase To bring possible actions that have been developed in the team to a deci- sion and fo make available the resources necessary for them (implementa- tion planning). 3.2 Time Frame ‘Actions that have been decided in the team and that do not require man- agement or project management approval are to be incorporated so that they can be implemented and their effectiveness can be evaluated before the corresponding milestone. Actions that require approval are to be processed and to be decided so that these actions can be implemented and the effectiveness can be evaluated before the corresponding milestone. 33° Input Decide actions that have not been decided yet, taking into account the costs, time, quantities, resources and considering the effect on other sys- tems and components, or send back the actions for analysis. Ideas for the actions from the team. 3.4 Work Scope R: Responsible Person * Preparation of the Measures Decision. Development of the decision paper with costs, deadlines. Decision on the action, Release of the resources Team Members Information about the action to be decided. ‘Support for the planning of the Measures Decision. een \VDA-Volume 4: Product- and Process-FMEA 693.5 Tools and Supplies Calculation program for cost calculation, simulation programs, network planning, project planning tool, implementation risks, legal basis such as laws, standards and regulations, presentation methods. 3.6 Methods Decision matrixes, discussion etc. 3.7 Measurement variables * Efficiency of the decision. + Time frame from the input to the decision. 38 — Substeps ‘* Cost evaluation and implementation evaluation ‘+ Demonstrate decision premises. ‘© Identify and present alternatives. * Planning of the implementation. Impact inspection of the actions implementation * Risk inspection for the actions decision + Develop decision papers including, * Objectives, costs, + Feasibility, ‘+ Implementation time. ‘* Give recommendation. ‘* Make decision, ‘+ Documentation of the decision with basic principles 39 Result * Implementation resolution of the actions and documentation of the de- cision and provision of the resources. Rejection with reasons. Request for renewed processing. Detailed schedule for the implementation of the actions decided. Risk with regard to function safety and producibilty, delivery date. 70 VDA-Volume 4: Product- and Process-FMEA3.10 Risks Risks that can occur in the Measures Decision process: Objective not clearly defined. Inadequate or wrong inputs. Too late or insufficient result. Too few resources allocated. Not all involved parties integrated Wrong premises. Insufficient communication, 3.41 Communication ‘After the actions decision takes place, a complete overview with person(s) in charge, deadlines and resources for the implementation, and a memo to management should be prepared Objective of the communication + Information about actions already decided. * Decision about further need for optimization. * Decision as to whether risks are adequately safeguarded against. \VDA-Volume 4: Product- and Process-FMEA ”4 Implementation ~ 1 441 Objective of the implementation Phase In the implementation phase, the implementation of the individual actions is traced against the schedule and a re-evaluation is carried out. If the actions have brought the expected success, this action Is completed. In the other case, further actions have to be initiated, the schedule has to be traced, and they must be re-evaluated. 42 1e Frame The implementation phase begins after the definition of actions and their responsible persons, and it ends when all actions have been implemented and the results have been accepted. ‘The determined deadlines must fit the framework of the project plan. 43° Input The actions described and defined in Chapter 3 that have been adopted within the framework of the FMEA, with the corresponding responsible per- sons. 44 Work Scope FMEA team (core team, FMEA moderator and experts). R: Responsible Person * Monitors the on-schedule implementation of the defined actions. * Summons the FMEA team for the evaluation of the implemented ac- tions. Produces and distributes the final report. Gives the appropriate recommendation for releases. FMEA Moderator Chairs the team meetings. Accounts for the methodical execution. Documents the meeting. 72 VDA-Volume 4: Product- and Process-FMEA,T: Team Members «Report their experiences for the evaluation of the remaining residual risk. ‘Along with the experts, are responsible for the correct assessment of the residual risk E: Experts Support the team members in the evaluation of the remaining risk. ‘+ Demonstration of the actions conducted, 45 Tools and Supplies Tools for the action tracing and re-evaluation of the remaining risks + Implementation plans. + Schedules. = Work plans. 46 Methods + Project management. + Review. 4.7 Measurement Variables ‘The state of the actions and the processing of the actions are to be demon- strated in a target/actual comparison at established times that are based on customer or project regulations, milestones, releases, or agreed FMEA re- view deadlines, for example. 48 Substeps 484 Action Tracing When preparing the FMEA, various actions were defined and decided cor- responding to the identified risks. These actions have a deadline for when they must be completed, The deadline is compatible with the project scope deadlines and is monitored in the implementation phase, The person responsible for the action sees to the on-schedule implementa- tion of the action. \VDA-Volume 4: Product- and Process-FMEA 7348.2 Re-Evaluation of the Remaining Risk The actions carried out must be re-evaluated with regard to their effective- ness. If the remaining risk is too large, further actions must be defined, if required. If the newly defined actions are not compatible with the project Scope (costs/deadiines/quality objectives), the escalation path described in the Actions Decision chapter must be followed. Depending on the result, this iteration loop can be run through repeatedly. 48.3 Summary of the FMEA Results Preparation of a final report with possibly necessary release recommenda- tions 49 Result All defined actions are completed. The subsequent evaluation of the re- maining risk has been carried out and has been evaluated as acceptable. ‘The work carried out is summarized in a closing documentation. Among other things, the report includes: Objective of the FMEA. Prerequisites, resources, participants, schedule, ‘Summary of the most important findings. Remaining risks. 410 Risks Missed deadlines. Known schedule problems not escalated. Lack of resources for the FMEA, Lack of information management and methods. 74 \VDA-Volume 4: Product- and Process-FMEA441 Communication ‘After the completion of the implementation phase, or when the schedule andior the budget have been exceeded, an appropriate memo to manage- ment (final or progress report on the FMEA) must be prepared by the per- son responsible for the FMEA, Objective of the communication: Information about the work already carried out. Decision about necessary actions. Decision about further need for optimization Decision as to whether risks are adequately safeguarded against. In the framework of the project review (see VDA Volume Project Plan- ning/Management), this data will be recorded in the project progress evalu- ation by the general project management. \VDA-Volume 4: Product- and Process-FMEA es5 Communication + C ra f| 5.1 Objective of the Communication Phase With the help of an effective knowledge management, the existing knowledge of individual employees from the FMEA is consolidated, com- municated and distributed, and made usable for the entire organization and for suppliers and customers, if necessary. In detail, the following objectives are achieved: Find, record, process, reflect and evaluate information. Pass on, communicate and distribute knowledge content to others. Cooperatively exchange and mutually supplement knowledge content with others. ‘Apply knowledge, implement in action and evaluate. Present FMEA results. Knowledge “maintenance” (such as updating, eliminating, structuring). Create knowiedge than can be made further use of and used again. Final inspection by customer. 52 Time Frame Parallel to the individual phases and after end of project 5.3 Input Results of all previous phases and their documentation, as well as the re- ‘sults of inquiry calls and database hits. New findings and/or input (internal or external) with regard to standards, customer requirements etc, 76 \VDA-Volume 4: Product- and Process-FMEA5.4 Work Scope jesponsible Person + Establish the communication channels and cycles with the customer (internal and external) andior suppliers. Prepare and document information. Coordination and release of the information contents. Process, document and present results. Knowledge maintenance (such as updating, eliminating, structuring) Determine feedback systematic. MW: FMEA Moderator + Support of information gathering ‘* Participation in the generating of information ‘+ Processing of information with regard to misinterpretation ‘+ Transfer of the information to other FMEA specialists ‘+ Incorporation of information from comparable FMEAS. “4 : Team Members ‘+ Impart, establish and distribute knowledge content to one's own em- ployees. Report on positive experiences. Discuss and present implementation results concerning the own pro- ‘cesses to the person in charge of the process ‘+ Sensitization of the employees, suppliers and customers regarding the risks related to one’s processes. * Safeguarding of the information of the FMEA as well as the knowledge ‘maintenance and processing in one’s own area. E: Experts, © Support of information gathering = Procurement of additionally or supplementarily necessary information about special topics of the information exchange. + Procurement of necessary information about existing communication and information channels. + Patticipation in the execution of information workflows and distribution \VDA-Volume 4: Product- and Process-FMEA 775.5 Tools and Supplies Use of media, knowledge management systems, documentation systems, FMEA accompanying documents, intranet, infomation boards, and meetings. 56 Methods ‘Systematic visualization, presentation techniques, communication techniques. Determining distribution of the information 5.7 Measurement Variables + Further inquiries regarding results, Up-to-dateness of the information, Integration in procedure documents (design guidelines, quality guide- lines, test instructions, process specifications etc). ‘+ Amount of Continual Improvement Process projects due to the new FMEA findings, 58 — Substeps Processing and storage of the supplied data Generation of the presentation documents and presentation (inler- nalfexternal). * Completion of database with current, possibly version-controlled, find- ings. + Answering further inquiries. + Record and evaluate measurement variables. Establish the information distribution Tracing and projecting the resulting activities. 5.8.1 Communicate Knowledge The targeted communication of knowledge is a imperative prerequisite to make the isolated existing knowledge of individual employees useable for the entire organization. Without the communication of the findings from the FMEAs and their implementation in the organizational environment of the company, an optimal usage from the FMEA cannot be drawn. The commu- nication of knowledge can take place both as an obligation to provide or to collect. 78 VDA-Volume 4: Product- and Process-FMEA5.8.2 Using Knowledge ‘A central factor of the FMEA is the consolidation of expert knowledge for the optimization of the current and also future development expenditure. It is important here to guarantee that others actively use the existing knowledge as an information source, in order to remedy information deficits, Knowledge is deemed an im- portant element in a tem- porarily and situationally de- pendent process. Therefore, When saving a knowledge ob- ject, the content and chrono- logical contexts are always to be archived with it as project- related metadata. The con- texts in which the knowledge is valid and conclusive are also to be considered when retrieving later. In this way, changed meanings through deviating interpretations and contexts can be avoided. In order for this knowledge to be used, it must always be kept available, as well as the organized and structured archiving and distribution. Knowledge that is not communicated according to need and which is difficult for em- ployees to access does not, for all intents and purposes, exist. ‘The communication can be carried out in meetings and project groups, and with the help databases. It is crucial that the information is made available in such a way that it can serve as a source for further knowledge generation for employees that were not involved in the preparation of the FMEA. The knowledge does not only enter into risk inspections but can also be used for: ‘* Product and process information. ‘© Test data andlor test procedures. © Project schedules etc. A structured set-up knowledge communication, especially in large intera- tional projects like those in the automotive industry, has become an indis- ensable resource for the optimization of systems, products and processes. VDA-Volume 4: Product and Process-FMEA 795.8.3 Information and Communication Within the scope of an FMEA, information must be constantly exchanged. ‘An electronic data storage is employed as an important basis for the opti- mal execution of information exchange in an FMEA. Information and communication are dependent on each other, but are clear- ly conceptionally separated, Information is the object of the communication, The communication concept is kept so general that not only the communi- cation between people but also the communication between people and processes as well as only between processes can be Included, For the FMEA, communication is understood to be all organizational regula- tions that determine the information exchange of findings via sending, re- ceiving, storing and processing. The following sub-aspects are necessary for the transmission of information: A transmitter for the sending of information A receiver for the reception of information. A storage for when the information cannot be immediately made use of A conversion, i. a processing of the information. In an FMEA, risk evaluations are carried out which span purchasing, devel- ‘opment, production and suppliers. Analogous to this, formally related tasks of decision, planning, inspection and administration of these risks emerge. Since the information is only then valuable for an FMEA when it arrives at the place where the contribution for the task fulfilment must flow in, the ‘communication is a basic prerequisite for the cooperation of all the parties involved in the performance process. The prerequisite for this is created by the sending, receiving, storing and processing of information, Thus, for an optimal task fulfillment it is on no account enough to only set the locations, departments and instances, but also the rules for the commu- nication must be similarly made in an FMEA. As a result, it must be record- ed that information and communication are of great significance for an FMEA, since without them the highest goal, risk minimizing, cannot be achieved, 80 \VDA-Volume 4: Product- and Process-FMEA5.8.4 Information Systems The general objective of information systems is to provide the right infor- mation atthe right time to the right place in adequate form. For this the data must first be collected, stored, processed to information, and then made available. These steps are carried out with the help of IT supported sys tems. The relevant elements of an FMEA information system are: ‘© Databases: collection of organized data for certain purposes, e.g. a database for damage management. + Databases of methods: collection of programmed methods that can be ‘employed in the FMEA process, e.g. algorithms and statistical proce- dures, + Databases of models: analysis and decision models, ¢.g. model for the simulation of a damage scenario. ‘An appropriate FMEA information system must therefore guarantee a smooth fiow of information and communication between all involved func- tions, It collects and processes data, e.g. FMEA actions. ‘The requirements on the FMEA information system vary corresponding to the individual needs of the project. The identification of the requirements is a central problem when selecting and/or developing an FMEA information system. A few basic requirements can be defined ‘+ Flexible setup with upgrading possibilities. Availability of an integrated data set via suitable interfaces. + Availability of current data at any time. ‘+ Support of different views of the data set. ‘+ Provision and compression of data to any compression level ‘+ Fast and flexible simulation possibilities. ‘+ Individual layout of reports ‘+ Matured presentation possibilities, Ideally, an FMEA information system should be integrated into the existing IT environment of a company and have adequate interfaces to other com- ponents of the operational information system, e.g. to production planning, The system must also have appropriate communication interfaces, 0.9 email, in order to be able to guarantee the flow of information and commu- nication between the functions, departments or companies participating in the FMEA. The FMEA information system should be set up flexibly so that it can be adjusted according to the continuous development and process changes. \VDA-Volume 4: Product and Process-FMEA a159 Result * Documentation and processed information, * Sensitization of the employees, suppliers and customers with regard to risks. + Broad understanding of the problems and approaches of other inter- faces. Knowledge maintenance and distribution Presentation of FMEA scopes. Provided information for the use of syneray effects. 5.10 Risks ‘The communication of company-internal knovi-how that is consolidated in an FMEA exhibits varying sets of problems for which the entire FMEA team must be sensitized: + Loss of know-how. * Data security within the framework of product lability + Responsibilities not clearly established ‘+ Communication problems (customerisupplier relationship, development production) ‘+ Lack of presentation and distribution media, ‘© Deadline problems. + Availabilty of data + Incomplete or incorrect information + Insufficient processing + Information overload. + Not up-to-date. * “expiration date" for the information is not defined 82 \VDA-Volume 4: Product- and Process-FMEAAt Additions A141 Execution of the FMEA A141 Implementation FMEA in the company ‘The FMEA’s integration in the product development process is necessary for its successful im- plementation, Trained modera- tors are essential for this, These drive the FMEA process. The participants in the FMEA meetings must be informed about the basios of the FMEA methods and the process of the FMEA preparation. In the first FMEA meeting, the method expert gives an overview of the FMEA method. According to past experience, this takes one to two hours during the first FMEA team meeting. The FMEA moderator ensures the methodically correct procedure during the execution of the FMEA. ‘An exchange of experiences about the FMEA should take place inside and outside of a company, in order to inform the users and FMEA moderator about the latest state of knowledge of the methods and the application in the company. 1.1.2. Distribution of Tasks When Preparing The FMEA, Starting with higher system levels, the interfaces to lower system levels are defined. A clear distribution of tasks among several partners is determined for the FMEA. The interface-relevant SEs are jointly developed and/or co- ordinated, ‘When inspecting interfaces in the FMEA, the customer is completely re- sponsible for this scope. The suppliers account for their shares, VDA-Volume 4: Product- and Process-FMEA 83During the FMEA the evaluation numbers for the severity of the failure modes that are established in higher system levels are to be taken into ac- count in lower levels, The scope and the evaluation tables are to be coordinated between cus- tomers and suppliers, Results worked out together are available to the parties involved, 1.1.3 Know-How Protection of the Product FMEA/Process FMEA, For reasons of know-how protection, the product and process FIMEAs pre- pared by the suppliers are categorically not given to the customers as long ‘as no other contractual agreement has been reached. ‘The results are presented when requested. During inspections the custom- er can see that the relevant FMEAs were prepared, Here the procedure is similar to the archived documentations of the quality assurance. A114 Reuse of the FMEA Existing FMEAs for known products and processes are used in new anal- yses. In this way expenditures are reduced. The scopes carried over are to be critically examined with regard to the respective use case, especially the evaluations with the experiences from the application. A1.1.5 IT Application When Preparing an FMEA, With the application of IT, the FMEA can be carried out more efficiently: Systematical processing is supported. User guidance and support are possible. Execution of necessary preparatory work and analyses is simplified. Processing is supported, ¢.g. with pasting, deleting and copying. ‘Access to already prepared FMEAs by networking single PCs with sys- tematic access protection is possible. + Administer databases of already prepared FMEAs. 84 \VDA-Volume 4: Product- and Process-FMEAA1.2 Relationships Between Different FMEAS 1.2.1 Levels Within A System ‘The determination of the interfaces between FMEAs on different system levels is a prerequisite for the continuous processing of complex systems, such as a e-gas-system. With the help of these determinations, a clearly ar- fanged and sensible division of work is achieved for comprehensive FMEAs. This means for the manufacturer of a throttle positioner compo- nent, for example, that its FMEA starts at a defined system scope. Selected system elements of the system description, in this case throttle positioner, servomotor, transmission etc, serve the establishment of system limits. The mutual limits and also the links from FMEAs at different inspection levels fare possible with the establishment of system limits (see figure A1.2.1-1 and figure A1.2.1-2). lected Fig. A1.2.1-1 Example of levels of different FMEAs (hierarchical, compo- rent and function-oriented) oe \VDA-Volume 4: Product- and Process-FMEA 85A1.2.2 Methodical Inter-relationships between different FMEAS The existing inter-relationships exist between a product and a process FMEA should be used in order to support the co-operation of development and production. Figure A1.2.2.-1 shows this using the example of the failure structure of a product FMEA (the upper section of the illustration) and the ‘corresponding process FMEA (the lower section). The failure mode "primary gear jams on the primary shaft" is examined for development errors in the product FMEA @ and for manufacturing errors in the process FMEA @. The further consequences of the failure mode are described in the product FMEA and are pursued in the causal links from the process FMEA. In this case the significance is set out in the product FMEA, fc semaccs Foe alw [ree ners jromtcaren {ees iin nf een lsersn mercy | 7 frstmestamy” |\(i ne Seryiote cere [Sati Eee Fig. A1.2.2-1 Example of the inter-relationships between FMEAs \VDA-Volume 4: Product- and Process-FMEA1.3. Special Characteristics The requirement of ISO/TS with regard to labeling special characteristics is covered by the introduction of the C-column in the form. ‘Special characteristics are product characteristics or production process pa- rameters that can have an impact on the safety or compliance to official regulations, on the fit, the function, the performance, or on the further pro- cessing of the product. For special characteristics established by the customer, the organization has to demonstrate the fulfllment of the customer requirements with regard to the determination, documentation and control of special characteristics. Moreover, special characteristics are to be established by the organization, and further special characteristics can be identified also within the frame- work of the FMEA. The established special characteristics are ‘+ tobe incorporated into the production control plan, * and are to be labeled in the documents for the control of the production process - including drawings, FMEA, production control plans and op- erating instructions - with the customer's symbols for special character- istics or with @ corresponding symbol or reference note of the organiza- tion In the FMEA the labeling takes place on the form in the classification col- umn, it can be assigned to the cause of failure, the failure modes, the se- verity ate. a \VDA-Volume 4: Product- and Process-FMEA 87If there are no customer-specific symbols or determinations available, the following overview is recommended by the IATF: Product characteristics or process parameters that influence § the safety of a product or the compliance to legal regulations. Product characteristics or process parameters which influence the fitfunction of a product, or which have to be controlled and Sr documented for other reasons, such 2s customer requite- ments. No No Key characteristics, product characteristics or process pa- (No rameter that do not, even with diigently assessed distribution, Symbol) affect the product safety, legal regulations, fit or function. For a continuation see ISO/TS 16949:2002 A1.4 Relation to Other Methods The various scopes of the FMEA are, among other things, related to the fol- lowing methods: Quality Function Deployment (QFD). Function Analysis (German: Funktionsanalyse — FktA ©2005), Fault Tree Analysis (FTA). Effect Tree Analysis (ETA). Statistical Process Control (SPC). Value Analysis (German: Wertanalyse - WA). Design of Experiments (DoE). The system structure, functions and function structures can already emerge in the course of a QFD and be carried over for the FMEA. Methods of func- tion analysis, such as function trees, support the preparation of the FMEA function structure. Ideally these can be directly carried over to the FMEA. FTA, ETA, SPC, WA and DoE can be built up on this by means of the struc- tured procedure of the failure analysis in the FMEA. 88 \VDA-Volume 4: Product- and Process-FMEAPaget aro DOE SPC Ishikawa ‘Wale analysis Weibas FTA ETA FM Siuciura Functions, Function Tressfletworks Failures, Failure TresslNetwerks. ‘Avoidance Measures Detection Measures Severity ‘Geourence Brobabiity | lt Detection Probability Responsible Parson Deadline i [Processing Status |[ Selection of Focal Points, A Priorities for Optimisation jonni ParetoiAsc| ity bh bib bib) be (ty ty, bt tb Ledled al (yt) ‘he ‘te \ty, t janamont) sis (GeK) ipa eesTeal ‘Alta pas Srietire FunciionelGharacteristies Funstion TressINetworks ‘Falures, Fallure TeseNetwons: Fvoidanes Measures Detection Measures Severily ‘acurencs PrOpaAIy Detection Brobabiiy Responeibie Person Beading Brocossiig Stats Selection of Focal Palate Priorities for Optimisation [Bee} erenning ft) | ty tal ty, aan Loi ebb & b) {tt be ‘bit ttt a a a a) Fig. A141 Depiction of methods with their interrelationships a \VDA-Volume 4: Product- and Process-FMEA 89A1.5 Documentation For the storage and archive duration see VDA 1, p. 28 1.5.1. Final Documentation After Completion of all Phases. ‘The final documentation contains the results of the FMEA. Examples for the contents of the documentation are Inspection scope and depth. Objective of the FMEA. Prerequisites, resources, participants, schedule. ‘Summary of the most important findings. Results of the risk evaluation, Lessons learned, A15.2 FMEA Form Contents of the FMEA form 1) 2) 3) 4) 5) Master Data The data according to the requirements of the respective products and processes is depicted in the header of the form or on the cover sheet of the FMEA. The inspected system must be identifiable from this data ‘System Element (SE)/Function/Task Description of the SE with respective inspected function/task. Potential Failure Modes Depiction of the potential failure modes. Evaluation Number for the Severity (S) The evaluation number S is established for the severity of the failure modes for the complete system (see tables in Annex), Potential Failure Depiction of the potential failures (failures) of the inspected system elements from item 2 90 \VDA-Volume 4: Product- and Process-FMEA6) 7 8) 9) 10) 11) 12) 13) 14) Classification Here the “special characteristics” are labeled. The C-column can be Jaid out on the right side of the S-column or on the left side of the "po- tential failure causes" column, Potential Failure Causes Depiction of the potential failure causes. Preventive Actions ‘The preventive actions are shown for each potential failure cause. Evaluation Number for the Occurrence Potential (O) The evaluation number (0) is established for each fallure cause tak- ing into account all preventive actions (see tables in Annex) Detection Actions The detection actions are depicted for each potential failure cause. Evaluation Number for the Detection Potential (O) The evaluation number D is established for each failure cause taking into account all detection actions (see tables in Annex). Risk Priority Number The risk priority number is shown here. Action Status for Product and Process a) Development b) Customer operation ©) Service Optimization Optimization actions are shown here. a VDA-Volume 4: Product- and Process-FMEA ot15) RIDLIStatus Responsible person (R) for the execution and deadline (DL) for the ‘completion of actions. Status of the actions: a) unprocessed, b) decision pending, ©) implementation pending, d) completed, e) discarded 16) _ Risk evaluation of the optimization according to items 9, 11 and 12 92 \VDA-Volume 4: Product- and Process-FMEA® SAT we was PE ae a “on vaua| stsfteuy sis0ya pue epoyl oumes Fig. A1.5.2-1 Content of the FMEA form \VDA-Volume 4: Product- and Process-FMEAA2 Further Application Fields With the product and process FMEA described, all application fields can be covered. The procedure is also transferable to suppliers of the automotive industry of other industrial branches. The special features and specific procedures are to be taken into account, A21_ FMEA for Mechatronical Systems In systems that consist of hardware and software, and normally contain ‘sensors, control units and actuators (mechatronical systems), diagnostic and monitoring functions with which the system can diagnose failures are usually implemented. The information about such failures detected during customer operation can be used: ‘+ To lessen failure modes (limp home mode), ‘© Toinform the driver, ‘+ To simplify the search for and elimination of the failure in service. The inspection scope of the “Diagnostics and Monitoring Functions” in an FMEA is established in consultation between customer and supplier. A211 Structure and Function Analysis Hardware and software elements are shown together in a structure in figure AQAA Functions that serve the detection and treatment of failures during customer operation are analyzed as independent functions. Functions for the failure detection contain, among other things, monitoring or diagnostic functions such as watchdogs, validations, check sums (CRC), comparison functions and alive counter. Functions for failure treatment can contain the provision of default values, the switching to a limp home mode, the switching off of the corresponding function and/or the display of a warn- ing to the driver, for example. The functions are modeled for those structure elements that are carriers of these functions. The distinctive feature is that these functions are only nec- essary if a failure has already occurred. In figure A2.1.1-2 the function is shown in normal operation and in figure A2.1.1-3 the function is shown in the case of a failure. 4 VDA-Volume 4: Product- and Process-FMEATost oma] Example of a structure tree Fig. A21.1-4 95 MEA 2 é 4 é 3 5 z é 8—_> ones uopssqusuen| pauyep yun omen uonemse ou 01 Buypro22e Duyuod 1 snip seuoysod so3 enow ener jeze os se Buybueue fa and oaup uo] Buypuedap saMod suj6uo jonoo| waifG-0053| zea pue + 84 wow sonjea ut poo ‘enpow enien Sa -senjen yu a4 oy Buyps0220 “Buopsod among onjuoo} "un ones eur) uaysfs Bupeed| aueunsnfpe ou os roefans z pu 1 svosues reped evenay| 50 2469 0} usuea| ue andy eau ounuieeg (5a) sosies ped Fig. A2.1.1-2 Example of function in normal operation (extract) \VDA-Volume 4: Product- and Process-FMEA._swawouinbos uonein6ou Burpy Fig. A2.1.1-3 Example of function during a failure (extract) 97 \VDA-Volume 4: Product- and Process-FMEAA2AZ Failure Analysis ‘With functions for failure detection and treatment, one can normally distin- guish between two types of failures: * *Pseudo-failure’: a failure was detected by the failure detection and fallure responses were initiated although there was actually no failure, * ‘Failure on demand": when an initial failure exists, it is not detected or the failure response does not take place as intended. In order to be able to depict the “failure on demand” in the FMEA, multiple er- rors have to be inspected as an exception to the rule (see Chapter 2.1.2.1 “Dormant Failure"). The following example clarifies the modeling in the failure structure of the FMEA. rrr eS ie ese ecm [Eom ie essa SSF ae (ea) pees aaa ne atte rocionete of pal ence (Pee in Lee ~_ [t00 high Fig. A2.1.2-1 Example of failure structure in customer operation without failure detection and response Case 1: The failure mode “pedal sensors 1 and 2 actuated too far in propor- tion to adjustment” depicts a failure that cannot be detected by the intended monitoring mechanism in this example, even when the monitoring mecha- nism functions according to specifications Case 2: In contrast, the failure cause “value of the pedal sensor 1 (PS1) read-in too high” can be detected by the action depicted in figure A2.1.2-2 0 that the appropriate failure response leads to a reduction of the original failure mode. If the functions for the failure detection and treatment are de- fined, a link to the original failure mode can be left out. The original failure mode must then be documented, e.g. in the form, figure A2.8.2.5-1 98 \VDA-Volume 4: Product- and Process-FMEArt ato ne fevanmase cen ese letson w [stepcieeewnisensicersin | [Psuiratines an Fig. A21.2-2 Example of a failure structure in customer operation with failure detection and response (largel/actual comparison with cutoff) Figure A2.1.2-2 depicts the response according to specifications of the fail- ure detection and treatment actions as (moderated) failure mode. [erase unt [urea Se cheng ey a jac seston stg as en] [susioaeunerae Feat Fig. A21.2-3. Example of ‘pseudo-failure” Figure A2.1.2-3 shows that, due to a failure cause in the monitoring mecha: nism, a failure response is initiated although no failure exists in the function unit (no demand). lecae Sein Evin power oe ct [stenend test opt Fig. A21.2-4 Example of “failure on demand” Figure A2.1.2-4 shows that the failure response intended according to spec- ifications fails due to a failure cause in the monitoring mechanism. At the same time it is assumed that the underlying failure cause has occurred. This failure must be documented in the failure cause. VDA-Volume 4; Product- and Process-FMEA 99A2.1.2.1 “Dormant Failure” AAs a rule, simultaneously occurring fallures are not taken into account in the FMEA. The Product and Process FMEA is confined to the analysis of sepa- rately occurring failures. The failure tree analysis also examines the possi- ble simultaneous occurrence of failures and can supplement the FMEA, for example for safety analyses. AAs an exception “dormant” failures, Le. a failure that has no effect on the function in normal operation, can be examined in the FMEA if it occurs alone. This could be functions that are only executed on demand and then are not available when there is a failure. These are especially monitoring functions and warning signals that are necessary only with a failure. In the- se cases, additional failures can be examined. However, it often makes sense to carry out a combined method approach, such as for example the detection of single failures with the help of the FMEA, or the depiction of combinatorial analysis with the failure tree analysis. 2.1.3. Actions Analysis and Optimization When analyzing monitored mechatronical systems in the FMEA, it proves to be advantageous to differentiate between the action groups “Development”, "Customer Operation” and “Service’. The actions and evaluations described in these three groups are explained as a possibility, ‘The numeration here corresponds to the labeled fields in the form (see fig- ure A2.1.3-1). The sequence of the numeration represents the logical order of the actions analyses. Field 1 “Avoidance During Development”, field 2 “Detection During Development’, field 3 “Detection in Customer Operation’, field 4 "Avoidance in Customer Operation’, field 5 “Detection in Service and field 6 “Avoidance in Service". After actions for customer operation and service are labeled, the actions for development should be re-examined and if necessary optimized. 1. In the development actions group, all actions that reduce the occur- rence of the stated failure cause are entered in the “Preventive Actions” column, Here precise information is given which substantiates the relia bility of the functions and makes the occurrence of the failure cause improbable. These are, for example, specified requirements for compo- nent reliability, use of components with traceable operational maturity, 100 VDA-Volume 4: Product- and Process-FMEAand actions in the development process. O evaluates here the assess- menticonfirmation of the occurrence potential of the failure cause (FC) during the vehicle lifecycle, taking into account all associated preven- tive actions. If the associated preventive actions are not yet imple mented, the expected value of O is put into brackets. In chapter 4.2 "Example Table Product FMEA: Occurrence Potential © for Product Design” and 4,7 “Example Table Product FMEA: Occur- rence Potential O with Assignment of Failure Rates", examples for cor- responding evaluation tables are shown. 2. In the development action group, all actions that are carried out during product development are entered in the “Detection Actions’ column. ‘These include actions with prototypes and experimental vehicles such as tests and trials, as well as virtual actions such as simulations, ana- lyses and reviews. In this, actions for the confirmation or correction of the occurrence po- tential initially assessed in Field 1 are stated, and actions are described which ensure the effectiveness of the failure detection in customer ope~ ration (see Field 3) and the effectiveness of the fallure treatment (see Field 4). Additionally, actions can be named that ensure the failure de- tection in the garage (see Field 5) and the repair (Field 6). D evaluates the overall effectiveness of all actions named for a failure cause during the development (see Chapter “4.3, Example Table, Product FMEA: Detection Potential D for the Validation of the Product Design’). A high value means that further actions are necessary. This part of the FMEA serves the purpose of checking and, if neces- sary, Supplementing existing test and trial plans. 3. In the customer operation action group, all actions that lead to a detec- tion of the failure cause by the system or by the driver are entered into the “Detection Actions” column. Furthermore, actions can also be listed that detect the failure or failure modes that result from the failure cause. \VDA-Volume 4: Product- and Process-FMEA 101Examples of detection actions in customer operation include monitoring or diagnostic functions such as watchdogs, validations, check sums (CRC), comparison functions etc. A collection of failure detection ac- tions for electrical/electronical systems can be found, e.g., in the DIN 61508-2 standard, tables A2 to A15, The functions that are consulted as detection actions should also be analyzed within the FMEA as independent functions (see Chapter 2.1.4, “Structure And Function Analysis"). In order to guarantee the clarity and traceability, a cross-reference (hyperlink) to the correspond- ing location within the FMEA should be given. D evaluates here the potential that the failure cause or a failure result- ing from this, or a failure mode, can be detected early enough so that the failure treatment actions described in field 4 can take effect. In the chapters 4.8 “Example Table, Product FMEA: Detection Potential D in Customer Operation” and 4.9 “Example Table, Process FMEA: Occur- rence Potential O with Assignment of Failure Rates” as examples for corresponding evaluation tables are shown, 4, In the customer operation action group no actions for the avoidance of failure causes are entered in the “Preventive Actions” column. Instead, actions for failure treatment are described which, as a system re- sponse, reduce the failure modes. Such actions can include, for exam- ple, the provision of substitute values, the switching to a limp home mode, the switching off of the corresponding function and/or the re- lease of @ warning signal to the driver. ‘The functions that are consulted as failure treatment actions should al- so be analyzed within the FMEA as independent functions (see Chap- ter 2.1.1 “Structure and Function Analysis"). In order to guarantee the clarity and traceability, a cross-reference (hyperlink) to the correspond- ing location within the FMEA should be given. In the customer operation action group, O evaluates the potential that, the listed actions for the failure treatment are not effective on demand, It is assumed during classification that the original failure described in the failure cause has already occurred. Therefore the question espe- cially arises whether the failure treatment actions are always available completely independent of the original failure, If necessary, an evalua- tion can take place according to an individually determined table in which high evaluations correspond to ineffective failure treatment ac- tions and low evaluations denote effective failure treatment actions, 102 VDA-Volume 4: Product- and Process-FMEA,5. Inthe service action group, all actions that enable the detection of the failure cause in service garages and that facilitate the diagnostics are ‘entered in the “Detection Actions” column. Here, diagnostic functions in the vehicle that lead to an entry in the failure recorder, as well as func- tions for the test equipment used in the garage are inspected. Actions can also be listad which detect the failure or failure mode resulting from the failure cause, as long as these detections serve an efficient repair. ‘The functions that are consulted as detection actions in the service can also be analyzed within the scope of the FMEA as independent func- tions. In order to guarantee the clarity and traceability, a cross- reference (hyperlink) to the corresponding location within the FMEA shall be given. Here, D evaluates the potential that a failure cause, or a failure or & failure mode resulting from it, is detected in sufficient time so that the repair action described in field 5 can take effect. In the Chapters 4.8 "Product FMEA Example Table: Detection Potential D in Customer Op- eration’ and 4.9 “Process FMEA Example Table: Occurrence Potential O with Assignment of Failure Rates” examples of corresponding evalua- tion tables are listed. 6. In the service action group, actions for failure repair in the garage are described in the "Preventive Actions” column. An evaluation can be ‘carried out according to an individually established table in which high evaluations correspond to high repair expenditures and low values de- note low repair expenditures. a \VDA-Volume 4: Product and Process-FMEA 103‘wove oo] «| sensaenoe “ vous []— vaneowou safe anu Pun -sIOHBAE ON \VDA-Volume 4: Product- and Process-FMEA. 104esnunaa] seer] oa nag cami \VDA-Volume 4: Product- and Process-FMEAergata | & ren \VDA-Volume 4: Product- and Process-FMEA Example of actions analysis and optimization for mechatronical systems Fig, A24.3-4 106A2.1.4 Evaluation of the Risk Here procedures for different inspections of the risk are presented in order to generate conclusions from the following evaluation parameters. The references to the fields all refer to figure A2.1.3-1, Example of Actions Analysis and Optimization for Mechatronical Systems, Severity S of the failure mode described, Occurrence potential of the failure cause, see field 1, Effectiveness of the actions, see field 2, Detection potential in customer operation, see field 3, Failure potential of the failure response, see field 4 Detection potential in the service, see field 5, Repair expenditures, see field 6. 2.2. FMEA for Software Scopes The functions of a system are realized more and more often by software. A Product FMEA1 examines the functional capability of a system, and there- fore the inspection of software scopes is a part of this. The system and its effect relationships should be inspected as a whole in the analysis of the software scope, When inspecting software scopes, special problems can occur that are considered in the following chapter. ‘The term "Software FMEA" is misieading, since not the software but the functions that ere realized by the software are to be examined inthe system conten \VDA-Volume 4: Product- and Process-FMEA 107A224 General A2.2.1.1 Objective of the Software Scopes Inspection + Analysis of the software requirements: + Demand from the complete system + Checking the basis information/boundary conditions/specifications *_ Systematical establishment of actions for risk reduction, e.g. con- cept change, avoidance, detection. ‘+ Analysis of possible faults in software scopes: + Effect on the complete system + Depiction of the interaction of software modules in the complete system) ‘+ Assessment of the risk of software modules, 2.2.1.2 FMEA in the Software Development Process The FMEA is especially suited for the analysis of requirements and for the validation of the implementation. Therefore its field of application is primarily in the upper part of the model shown, see VDA volume 13 "Requirements on Processes and Products" spe ~RSREDE ET Seni Boon mes SE Fig. A2.2.1.2-1 Application of the FMEA in software development process 108 VDA-Volume 4: Product- and Process-FMEAA2.2.1.3 Connections to other Methods/Measures of Software Engineo- ring ‘The inspection of software scopes in the FMEA can draw on the findings of other methods/measures of software engineering. The findings from the FMEA can vice-versa be incorporated in other methods/measures. Fig. A2.2.1.3-1 Methods/measures of software engineering \VDA-Volume 4: Product- and Process-FMEA 109A23 Depiction of Error Propagation A depiction of the signal flow and its effect connections within different de- tailing levels depends on the objective. If the signal flow is not depicted within the FMEA, the technical documentation from which the signal flows and effect relationships result must be referenced in the FMEA. If @ depiction of the signal flow and its effect connections is necessary with- in the FMEA, there are the following possibilities: + Acomment for simple connections. * Depiction as failure mode chain, A2.4. FMEA for Machine and Facility Manufacturers ‘The Product FMEA of a machine is sometimes referred to as a "Machine FMEA’ in the literature. Starting from a Process FMEA in which a machine was identified as a risk, 2 Product FMEA can be prepared for the machine. In the Process FMEA, the requirements on the functions/abilities of the ma- chine are identified in the analysis of the machine. ‘Separate evaluation tables are to be developed for this FMEA. 110 \VDA-Volume 4: Product- and Process-FMEAEvaluation of an FMEA a3 paqenjens oq ‘pouTew VINA 841 10 Aujenb ‘Buyuueld sseaoid ‘uaurdojenap wos, syedxe pus Jewojsno ey} sessaippe i “SN J0 uoHvenjene uosfun eu) 20} Uoddns s} suousent ‘adoog Aronyoqnoelansren “sroydeyo renpy u) OU UI paquasep st u Se VaRL4 eu Jo einpeso1d oddns sv ania 0 o0u9 SIL. ‘oydsoutd ay) uo powouo sty "sya 10 U Wag ue Jo uopenjena 0 1 VDA-Volume 4: Product- and Process-FMEA‘SeVERE SI SIEEND ‘para 64 uoyequebi0 oui jo sonsuotoeseyo jade, au so) Sioquus ouh ane Ty RTS BPA ep2sn 26 018] euuo} eeDrect you (e20j01d uonewO) wea} 6-3 Lies nee Sem meee oes ‘oqeTeaar jun wood siaidne gs ay ane] © wow ob Fann 20H LIEU 2s usoq voewounoep au ssa i pus uoyoupone soem 8 eo ‘Suaunsop 24 jo ss9ua}ep-oF-n SRST APT “pausisseuseg one pur 6unsodn‘vonewaunsep ube von “Uapeiopau ee ane ye 242 ant pve “stuonoun a le fa pojode veg Sogou weet a re ‘uo smyeie wou 24 oy puodsauco Vand 941)0 STII at = sauopayuso Budoay 83 "Lpeuyodde ueeq seomnoss, anay pur ueppalontworonponauau oven fay wea vars ao uoyeredos [yam 2u1s01 Aaqavedsoy epsnuedde use sedons paradsu ay 10} sanmasuodsa: VaNia eid along ‘un “sae 5 ANDAGD BUR BOS ~ van ro 11 pouuuarep u2aq adoas uerpadsu ou pur Sanjzego atta ‘poniounoop hgs202N si ueNDejas canara seus 5 2 Aa paynuop! usa yaw ue fonpuco 0 Yon Jo, p3eU aul t ‘suaUNIOD uoneredaig odas. VDA-Volume 4: Product- and Process-FMEA, 112“s380010 / woddns soiniesl 0} Z smworsno aun wt vondu9sep ¥22u>):suonouny aur nage suodseno| _sucqouny jo sua} paujop Kesoeid u9eq adoas uonoedsu our se} ¥Z paepienpue posuen oq ueo ie fem ©. poquosap eg suoRDUN ay arEH ZZ ce sul Gunicoepeyoede haus vou omnes eo 3 0 a ‘sisAjeuy uonouny — Z : “her orau04 80g uomsadeu udp o sup adeas uepredau ai ei] SF pep pp nog seam on P [ainonus ow un pouatep Aves Uaeq uoyoedsut au Jo sevepuned 8 eH eb 2 VAN StD01g © 10 vanes BopOld # 9H eT NaS eH WE _Lssouypepieoas Hardee sow 1ygoyens uonsuacap sesoid jputuogeiuap Wats agearen & siskeuyeimonns — +dagy | 4113 VDA-Volume 4: Product- and Process-FMEA‘peye4—| weEA SLEEVED DEK HU OME] ‘sip8K9 Gam UUETIOD 0 voquyen uo Bupue ‘ed #9} 10 sanpais sououoiUEA aE eae aeedemaeee| ‘Susooyseranon “apsoubp 6» ‘suoneoyde evempDe Io ase og an mp Sud Ue] PE “uiuo} au; payeseides Ayoave0 uaa Sxuyaunie) aus ener] Se “iaiyoue 240 0} pawUy hyeD!o| w9aq Sainye) ay aNEH YE _-poquosap kejsuayeiducs pue AmveDyBs UDeq seins a aceHd ce ‘ontop 91 Bupioase anala0 canola oun sousploane i euonouny ai oH penvep AeRrdueo ud0g some) a ne ~ swvaun0D elo|o “sisheuyemiey _ e-dex wss0ad yoda sone ai 2 7 Uoyouny ayeureyerauroy dwn] Sr Z| eH WORN FIZ ‘euaju> BuuoRuond €1 Z| rE — ‘sejenboiaid 21 2| ‘opduasap resavag] Sele ‘SS8003d Bu) UI SoHSTAIDEIEID aiN Mode SUOTISANO | \VDA-Volume 4: Product- and Process-FMEA 114Sauipuinog pany aT Ww op "ea1 24 uoneUpI0~0, {euoyoe oj vonevouayay ee ptepdnuonerene ve SER 217] “paqvouIRo 2 pure poquoueidus ueog sugae exp one ue peyssue ueeq sseuenoeye 1 uojequawieyduy oge SuoHsenO | oy ax yupeBe 98ND) ‘avonpe Bupuadsonce ow "yuauno fox 2¥e pu porenens useq G pue © Dupree: Sesne9 ex wo} aip sUBBE YooED) ‘zhranonaquce paydde spiopuwis wouenene Buysne BA] 6 susie ybal fats pue soue|sN> UeaM}eG perEUP:000 UE 009 uoReRTena 24 one} Pere areal ‘atrldns pue seo og payepi009 ued SIspoe4p UOHENENS OWN NCH BY eraeyene esennodd are seppou opeNEAS uaemeso ox poxanGuisp sparpuES uoREENe=yoeHs-ss0 AN pp I ‘SGU NE aE BIE lvouoodsus ata win payeupi009 \ve0q ene Te SHIN2UD 20 pu 05 ny stsppak9 edbas pated a 10} OEHENE SPIES UORENTENS Ne 9'Y ued elon exp ysurebe eUD) ‘Baro es Bu yn un ponsouccieg uo few ‘Sapo wouojrep pond pa u panes woe SUE ene vP wo} 2ip IsUBEE ¥!0uD _2uoqoe ye 30) paypeds uda9 souypesn pue sou Bap = ~~ - pojerduioo | Gupued uonewwowsdiuy queue pure paypeds suonse ye jo smers ou 3h Bupued vasnop - 1 jonazu se ‘as sunoop 01 s0u070104 ‘Aim po ferme pevensuneg ogee oa en 2 io) ox isueBe ¥o240) ‘ums ou yo nanos eacosisoo ai jo Vohtunjuontuoureeese et sequoeep nq enon one panowen 123 VDA-Volume 4: Product- and Process-FMEADetection Potential D in Customer Operation Product FMEA Example Table: AaB nut bone ol pecpas ce semen | capeouy a TARE RT OSES ‘10.95 om atime es seeoneatubee es oon VDA-Volume 4: Product- and Process-FMEA 124Occurrence Potential O with Assignment of Failure Rates, A49 Process FMEA Example Table: angumonr gin Seoar pene 4 uoneipius ow Bune stne2 9 "Goustnaoo aio voneunuoonueuroe sumncs| oqo sous ep seg 125 \VDA-Volume 4: Product- and Process-FMEA