Design for Excellence in Electronics Manufacturing. Cheryl Tulkoff

Чтение книги онлайн.

Читать онлайн книгу Design for Excellence in Electronics Manufacturing - Cheryl Tulkoff страница 10

Design for Excellence in Electronics Manufacturing - Cheryl Tulkoff

Скачать книгу

resources risks failure.

      3 Clearly define reliability goals and the use environment: these drive the rest of the reliability program.

      4 Identify critical components, especially those at risk of wearout. Initiate test‐to‐failure and design‐ruggedization activities.

      5 Implement step‐stress testing at both sub‐assembly and assembly levels.

      6 Perform RCA. Focus on the top three field issues, and repeat; drive to quality assurance as appropriate.

      

      Elements of a comprehensive reliability program include:

       Organization: Develop a system that rewards teams for effective reliability engineering focus. Reliability must be the goal of the entire organization and must be implemented early in the process apart from verification and validation (V and V).

       Reliability goals: Consider an availability goal as well.

       Reliability resources: Resources need to be assigned to reliability characterization and committed in program staffing. Characterization infrastructure needs building.

       Software reliability: Frequently overlooked but critical to today's products and systems

       Defined use environments: Engage field service to obtain knowledge of relevant stresses (loads, contaminants, electrostatic discharge [ESD], etc.) in use environment, and then exercise these during reliability characterization.

       Thermal analyses.

       Circuit and component stress analyses.

       Derating: Employ systematic derating by computational and/or experimental analysis.

       Critical components identification: Identify and prioritize components and subassemblies for extended reliability analysis and test activity during early development. Use supplier life data where possible; create the expectation of minimum supplier reliability competency.

       Failure mode and effects analysis (FMEA).

       Critical to quality (CTQs) and tolerance identification.

       Comprehensive control plans with suppliers.

       Design for excellence practices.– Design for Manufacturability (DfM), Design for Testing (DfT), Design for Reliability (DfR), Design for Excellence (DfE), and Design for Sustainability (DfS).– Manufacturing involvement in DfM and DfT.

       Step‐stress tests to define design margins (HALT).

       Simulation for end‐of‐life prediction

       Relevant product qualification tests

       Accelerated life test (ALT) to validate the life‐prediction model

       RCA on failures and field returns with a feedback loop (design, measure, analyze, improve, control [DMAIC])

      These elements will be explored in more detail in the upcoming sections and chapters.

      2.3.1 Reliability Goals

      Desired lifetime and product performance metrics must be identified and documented. The desired lifetime may be defined as the warranty period or by the expectations of the customer. Some companies set reliability goals based on survivability, which is often bounded by confidence levels such as 95% reliability with 90% confidence over 15 years. The advantages of using survivability are that it helps set bounds on test time and sample size, and it does not assume a failure rate behavior (decreasing, increasing, steady‐state).

      Reliability goals and requirements address the product or system itself and include test and assessment requirements and associated tasks and documentation. These are included in appropriate system/subsystem requirements and specifications, test plans, and contract statements.

      Examples of reliability goals and metrics:

       Minimum required field service life under defined conditions: 10 years of environmental exposure and 150,000 miles (or 1 million operating hours)

       Maximum allowable quality defect rates– Field infant mortality quality defect rates at 3‐6‐9‐12 months– Dead on arrival (DOA) defect rate– Required minimum field reliability at one year or the end of the warranty period– Six Sigma first‐pass quality yield– Non‐repairable or failure to replicate (no trouble found, NTF) rates

      2.3.2 Defined Use Environments

      Meaningful reliability prediction must consider the environment in which the product is used. There are several commonly used approaches to identifying the environment. One approach involves the use of industry/military specifications such as MIL‐STD‐810, MIL‐HDBK‐310, SAE J1211, IPC‐SM‐785, Telcordia GR3108, and IEC 60721‐3. The advantages of this approach include the low/no cost of the standards, their comprehensive nature, and acceptance throughout the industry. If key information is missing from a given industry standard, simply consider standards from other industries. Disadvantages include the advanced age of the standards (some are more than 20 years old) and the lack of validation against current design usage. Depending upon the product and environment, the standards both overestimate and underestimate reliability by an unknown margin.

      A second approach to identifying the field environment uses actual measurements of similar products in similar environments. This provides the ability to determine both average and realistic worst‐case scenarios. All failure‐inducing loads can be identified; and all environments, including manufacturing, transportation, storage, and field, can be included.

Illustration of key reliability tools and tests across the product design and development phases: Concept phase, design phase, production phase, and filed phase.

      2.3.3 Software Reliability

      The major difference between software and other engineering endeavors is that software is purely design. Hardware unreliability issues are typically related to physical failures of components, which can be traced back to a variety of root causes, such as material, fabrication, or assembly defects; environment or usage overstress; or wearout and design errors. In contrast, when software problems arise, they are traced back to design faults, which come from human errors such as inadequate or incomplete requirements, coding errors, logic errors, improper resource allocation, or the

Скачать книгу