MPD 5750 DESIGN FOR QUALITY

1. MPD 5750DESIGN FOR QUALITY Developed by: Dave Minock, J.D. Salinas, Dan Slater

2. INTRODUCTION • Definition of Quality • What is DFQ • How DFQ fits into the Engineering V process • DFQ Process Flow • Example of DFQ

3. Design for Ergonomics (DFE) Design for Reuse and Recycle-ability (DFRR) Design for Craftsmanship (DFC) Design for NVH (DFN) Design for Assembly (DFA) The World of Quality Design for Environmental Friendliness (DFEF) Design for Manufacturing (DFM) Design for Cast and Molded Parts (DFCMP) Design for Serviceability (DFS) Design for Health and Safety (DFHS)

4. Exciting & Innovative Products Customer Satisfaction and Owner Loyalty Superior Purchase & Service Experience High Product Quality TGRTGW Elements of Quality

5. DEFINITION OF QUALITY • The Customer defines Quality - products and services that meet their needs and expectations throughout the product life at a cost that represents value - Ford Quality Policy • The totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs - ISO 8402 • The loss a product imposes on society after it is shipped - Taguchi • A subjective term for which each person has his or her own definition - American Society for Quality

6. DESIGN FOR QUALITY (DFQ) • Quality is intrinsic to a design and is dependent on: • Choice of system architecture • Robustness of execution during the PD process • Quality is primarily associated with two aspects: functional performance and customer perception • DFQ is the disciplined application of engineering tools and concepts with the goal of achieving robust design development and definition in the PD process • The DFQ process allows the engineer to: identify, plan for and manage factors that impact system robustness , reliability and failures early in the design process

7. Key dfq terms Design: Creative process in the Arts, Sciences and Technologies. There are many design heuristics that are derived from rules, relationships and experiences. Failure: A condition in which a system no longer performs its intended function, or is unable to do so at a level that meets customer satisfaction. Failure can also result from the emergence of an undesirable function. Reliability: Elimination/avoidance of failure modes/mistakes. The probability that a product will perform its intended function: • 1) Under customer operating conditions • 2) For a specified life • 3) In a manner that meets or exceeds customer expectations Robustness: The capability of a product or process to perform its intended function consistently in the presence of noise during its expected life. The performance of the product or process is insensitive to sources of variability Testability: Ability to generate, evaluate and apply tests that improve quality and minimizes time-to-profit.

8. Key dfq terms System Architecture: The art and science of creating and building complex systems. That part of systems development most concerned with scoping, structuring, and certification. [M&R, 1997]. Failure Mode And Effect Analysis (FMEA): Systematic activities intended to: • 1) recognize and evaluate potential failure of products/processes and its effects • 2) identify actions to eliminate or reduce the chance of the potential failure occurring • 3) document the process Classification of failures: • - Hard failures cause complete loss of function, (ex: Driveline does not transmit torque to wheels) • - Soft failures cause degraded function, (ex: driveline whines at 45 mph steady vehicle speed. Approach: Design for quality must be approached from a functional perspective as opposed to a hardware perspective. It is recommended to use a “function tree” to decompose functions from the system to the subsystems and components.

9. Quality product design tools • Common product design tools associated with DFQ, and discussed in this presentation, are: • Boundary Diagrams • Interface Matrix • Parameter Diagram (P-Diagram) • Design Failure Mode and Effects Analysis (DFMEA) • Reliability Checklist (RCL) • Reliability Demonstration Matrix (RDM) • Design Verification Plan (DVP) • The engineering concepts associated with the tools identified above are based on proven methods that can be applied across a variety of industries

10. Terminology & Concepts • Control Factors: features of the design that can be changed by the engineer (dimensions, shapes, materials, positions, locations etc). • Noise Factors: sources of disturbing influences that can disrupt ideal function, causing error states which lead to quality problems. Noise factors can be categorized into five categories: • Piece to Piece Variation • Customer Usage • Degradation Time/Mileage • Environmental Usage • System Interaction • Error state: is an undesirable output of the engineering system (we can also call these failure modes), characterized by 1) variation in ideal function (soft failure), 2) degradation in ideal function (soft failure), 3) or loss of ideal function (hard failure).

11. Why design for quality? • Reliability can make or break the long-term success of a product: • Too high reliability will cause the product to be too expensive • Too low reliability will cause warranty and repair costs to be high and therefore market share will be lost • A reliable product is robust and mistake-free • A robust design is a product which performs its function "on target“ which will generate the smallest loss to the customer and producer • Cost of customer dissatisfaction • Cost to repair or replace • Customers tend to be more satisfied with their purchases if the product is robust and reliable

12. Why design for quality? • Failures must be approached from a functional perspective as opposed to a hardware perspective. It is recommended to use a “function tree” to decompose functions from the system to the subsystems and components. • Optimize the Design • Eliminate unacceptable failure modes, including but not limited to high severity modes. • Substitute high severity failure modes by lower severity failure mode • Iterate the designs through CAE and physical testing using component and system level testing until reliability is established.

13. Why design for quality? • Testability must be engineered into the product at the design stage itself, such that optimal compromise is archived between system maintainability and performance • Ability to generate, evaluate and apply tests that improve quality and minimizes time-to-profit • Extent to which a design can be tested for the presence of manufacturing, base component, system, and/or field defects • Measure of how easy it is to generate test sets that have a high fault coverage

14. DESIGN FOR QUALITY TIMING

15. design for quality Phases System design has three phases: • Design the Product or Component • Optimize the Design • Validate the Design

16. design for quality Phases Design the Product or Component • Complete System Architecture analysis. The focus should be placed on identifying the architecturally significant requirements, tracing the requirements to their owners, analyzing reusable components at their interfaces, selecting, assessing and accepting the system architecture. • For each tasks, a list of risks and opportunities must be updated as the architecture is refined. • Complete technical concept generation. • Complete concept DFMEA.

17. design for quality phases Design the Product or Component • Complete system and component level Design. • Complete P-diagrams, identify ideal functions, error states, control factors, noise factors. • Conduct system and component DFMEA’s • Address failure modes in order of severity and then in order of the product of severity by occurrence. • Implement actions to reduce severity of failures identified as critical and unavoidable by altering primary failure modes.

18. design for quality phases Optimize the Design • Eliminate unacceptable failure modes, including but not limited to high severity modes. • Substitute high severity failure modes by lower severity failure mode. • Document trade-offs. • Iterate the designs through CAE and physical testing using component and system level testing until reliability is established.

19. design for quality phases Validate the Design (Testing) • Critical noise factors (internal and external) must be included in the tests. • Duty cycle must be correlated to real life usage. • Tests must be run to failure to verify that the system failed as intended and that the system is able to perform the protected functions under the test simulated conditions. • Failure modes (primary, secondary,…) must be analyzed. • Teardown analysis are too often neglected. All parts must be inspected to properly assess the failure mechanisms. • Product validation starts at the component level and ends at the full system level.

20. design for quality timing Design for Quality should be considered throughout the PD cycle: • Early - to develop "product concepts" which are well suited for production (i.e., conceptual product design) • Gain the maximum benefit from the entire process • Define intended functions, requirements, and noises to support the cascade process • Continually - to ensure that the chosen product concept is implemented through optimal component design • DFR should be conducted throughout the entire PD cycle.

21. design for quality – the system v Phase I Phase III Phase I Phase III Define Define Total System Customer/System Requirements Confirmation Integrate and Integrate and Verify Designs Verify Designs Cascade and Cascade and Balance Targets Balance Targets QUALITY DESIGNS DESIGNS Phase II Phase II

22. design for quality process flow PRODUCTDESIGN BOUNDARY DIAGRAM INTERFACE MATRIX P-DIAGRAM DFMEA RELIABILITY CHECKLIST ROBUSTNESS DEMONSTRATION MATRIX DVP PROCESS DESIGN PFMEA CONTROL PLAN QUALITY HISTORY

23. What is Quality History and why do we need it? • Research into the history of the system or component under development • Identify opportunities (Close the gap on competition) • Establish priorities (Establish weaknesses from data) • Help set targets (What is it supposed to do) • Financial reasons (Warranty costs, impact on sales) • Improved efficiency (Not repeating the same errors) QUALITY HISTORY

24. Quality History – Links to other FMA tools QUALITY HISTORY

25. Why we need Quality History Quality History “It gets hot when it’s running” “it doesn’t do what I expect” “it doesn’t do it when I want” “I got soaked” “It doesn’t work “It came off in my hand” Problems with Target Failures Consequences Hardware Failure Modes Target misses customer want Transformation characteristics badly defined Functional Failure Effects of Failure Diverted Output Potential Failure Modes Cause of Failure QUALITY HISTORY Classifying Customer Failures

26. Commodity Core Engineer Date reviewed/ Issue Updated VEHICLE / ENGINE / INDICATORS INDICATORS INDICATORS INDICATORS INDICATORS INDICATORS INDICATORS INDICATORS INDICATORS INDICATORS INDICATORS INDICATORS INDICATORS INDICATORS INDICATORS INDICATORS INDICATORS MY CAUSAL PART CONCERN / FAILURE / SYMPTOM TRANSMISSION Quality History Matrix Example Part / Attribute Identification Magnitude /Severity Symptom / Failure Effects QUALITY HISTORY

27. Pre-requisites to Perform Analysis To develop Quality History you will need the following… • Warranty data • Market Research • Campaign Prevention Review • Manufacturing data • Service contact • Test data • External Media QUALITY HISTORY

28. GATHERING DATA Data gathering exercise: How many Product Quality Indicators can you name…? - Consumer Research - Warranty - Product Development - Manufacturing - Service - Public Domain/Media QUALITY HISTORY

29. GATHERING DATA – USING SOURCES • Look at all sources - All data sources have blind-spots • Understand the limitations of sources - Customer verbatim will only report squeaks from the front of the vehicle, no detail! • Use all metrics in data source - Can you see total costs and/or repair counts? • Update matrix in real time for best results - Keep up to date so issues are not forgotten or lost and are documented when top of mind Throw a wide net for data QUALITY HISTORY

30. ANALYSING DATA • Data source summaries only indicate the presence of an issue - They do not give any indication of Root Cause • Summaries don’t tell you the importance of a problem - Read customer verbatim for more detail - Understand indicator & breakdown of issue QUALITY HISTORY

31. ANALYSING DATA Identify & Categorise unique issues: Source data may include many problems: - Are the problems distinct or unique in the description? • Do unique problems exist in a subset of the sample • Is it seasonal? Find, Filter, Select QUALITY HISTORY

32. ANALYSING DATA Prioritise if many failures are identified: • Identify every safety critical problem - Review all Campaign Issues • Pick top X for each data source - Which issues cover 80% of metric? • Set a threshold for each data source & metric: - Warranty Data - R/1000 or CPU - AIMS - severity category QUALITY HISTORY

33. Analysing Data Describe the problems you see: • What does the customer experience? - Is that what we expect it to do? (Check Function versus target setting) • Describe the condition when the problem occurs - What, Where, When, How big? • Confirm the profile of the problem: - Was this a spike? - Is this a High TIS wear-out or an issue caused in the factory? QUALITY HISTORY

34. Drilling Down Identify the Root Cause(s) of the Failure - know where to look! - Plant based PVTs are a good source of root cause data….will be tracked on VQR single agenda - Parts Recall Centre (PRC) - Dealerships will be more useful for Warranty issues QUALITY HISTORY

35. Drilling Down Test if the Root Cause is fully defined - Try the ‘5 whys’ technique as example Problem statement WHY? Cause WHY? Cause WHY? Cause WHY? Cause WHY? Root Cause QUALITY HISTORY

36. Drilling Down What exactly is going on? • Check what investigations are on-going? - What 8D’s are available? Is 6-Sigma involved? - Don’t duplicate effort! • What mechanism causes the part to fail? - What is the weakness in the design? • What led to targets not being achieved? - Were they ever achieved? even on test? QUALITY HISTORY

37. Feed Forward • What actions will prevent re-occurrence? - Quality History should be constantly updated • Take actions that will last: - Revise Design Rules - Update D-FMEA’s - Revise Test Methods - Challenge Specifications - Develop Robustness Strategies QUALITY HISTORY

38. BOUNDARY DIAGRAM What does a boundary diagram do? • Defines the scope of the system being studied • Identifies components that are internal to the system • Identifies system-system, system-human and system-environment interfaces (External Components) • Defines the scope of the DFMEA i.e. elements within the boundary • Indicates the nature of all interface relationships • Represents all of the above in a clear graphical manner BOUNDARY DIAGRAM

39. Engineering with Robustness Linkages Quality History Interface Analysis Function Analysis Boundary Diagrams FMEA P-Diagram Robustness Checklist RCL Robustness Demonstration Matrix RDM DVP BOUNDARY DIAGRAM

40. BOUNDARY DIAGRAM Why create a boundary diagram? • Provide a disciplined approach to ensuring all system interfaces are considered at design initiation • Understand the nature of interface relationships i.e. • Physically touching (P) • Energy transfer (E) • Information transfer (I) • Material exchange (M) • Communication tool which facilitates team understanding and collaboration BOUNDARY DIAGRAM

41. BOUNDARY DIAGRAM How to create a boundary diagram? • Identify components within the system as blocks • Establish relationships between the various blocks • Establish intra-system and system/component relationships, including customer inputs • Construct a boundary line around what should be included in the analysis of the system • Boundary diagram analysis should follow system hierarchy down to the desired sub-system, component level BOUNDARY DIAGRAM

42. Example a Boundary Diagram • Use a hierarchical approach for the complete seat assembly Rear Seat Assembly (B4) Electrical Harness (B2) Door Casing (B7) Console (B11) Carpet (B9) B Post Finisher (B6) Squab Assembly (A2.0) Cushion Assembly (A1.0) HVAC ducts (B5) Seatbelt (B3) Headliner (B8) Head Restraint Assembly (A3.0) In System Direct Interface BIW floor (B1) In System Indirect Interface Direct Interface Indirect Interface Curtain Airbag (B12) Throw in mats (B10)

43. Boundary Diagram: Key Learning Points • Defines scope for analysis - identifies potential team members • Foundation for: Interface Matrix, P-diagram and key tools DFMEA or Robustness study - mandatory component of a D-FMEA • Identifies Interfaces with other Systems - aid to developing DFMEA and Robustness studies • System, Sub-system and Component levels can be applied - System hierarchy should be clear BOUNDARY DIAGRAM

44. INTERFACE MATRIX What? • Provides a supplemental analysis of the boundary diagram • Quantifies the strength of system interactions • Provides input to the Potential Effects of Failure and Severity column of the DFMEA • Robustness linkage to the P-Diagram • Positive interactions may be captured on the P-Diagram as input signals or output functions • Negative interactions may be captured on the P-Diagram as input noise or error states Why? • Cross-check boundary diagram interfaces • Verify positive interactions • Manage negative interactions for robustness • Interfaces of modern electrical systems are not easily done in this format, the use of SE/SA tools of PREEvision and Rhapsody, others are emerging to address this. INTERFACE MATRIX

45. Interface Analysis – Links to other FMA tools INTERFACE MATRIX

46. INTERFACE MATRIX How? • List all elements within the boundary diagram and all elements that interface across the boundary in the leftmost column of the Interface Matrix sheet • Fill the 4 quadrants (Q1-Q4) representing the interface relationship (P, E, M, I) between the elements of the Boundary Diagram with a rating from -2 to +2 2 = Necessary for function 1 = Beneficial but not absolutely necessary for function 0 = Does not affect functionality -1 = Causes negative effects but does not affect functionality -2 = Must be prevented to achieve functionality INTERFACE MATRIX

47. Types of Relationships • P – physically touching. • welded, bolted, clamped, etc • E – energy transfer. • Torque (Nm), heat, etc • I – information transfer. • ECU, sensors, signal, etc • M – material exchange. • cooling fluid, exhaust gases, etc INTERFACE MATRIX

48. Relationship Strengths +2 = Interaction is necessary for Function. (Part A is bolted to part B) +1 = Interaction is beneficial, but not absolutely necessary for Functionality. (Quick release switch on electrical lead) 0 = No interaction / interaction does not affect functionality -1 = Interaction causes negative effects, but does not prevent Functionality (Upper link touches lower link causing squeak) -2 = Interaction must be prevented to achieve functionality (Suspension strut fouls Wheel arch lining) INTERFACE MATRIX

49. Interface Matrix - How to complete • Enter Components (blocks) into the matrix • Look at where components should, or could, physically touch • Enter the relationship strength • These interactions are useful for P-Diagram noises • Positive interaction ratings should be reviewed against the system functions • Negative interaction ratings should be considered as potential causes in the DFMEA INTERFACE MATRIX

50. Interface Matrix Example INTERFACE MATRIX