DOCSLIB.ORG

Reliability Performance and Specifications in New Product Development

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Reliability Performance and Specifications in New Product Development Reliability Performance and Specifications in New Product Development T. Østeras1, D.N.P. Murthy2 and M. Rausand3 1 Associate Professor of Design Engineering, the Norwegian University of Science and Technology, Trondheim, Norway. 2 Professor of Engineering and Operations Management, The University of Queensland, Australia and Senior scientific Advisor, Norwegian University of Science and Technology, Trondheim, Norway. 3 Professor of Safety and Reliability Engineering, the Norwegian University of Science and Technology, Trondheim, Norway Preface The establishment of a framework for Reliability Performance and Specifications in New Product Development is the objective of a joint research project between University of Queensland and the Norwegian University of Science and Technology. The project is divided into three parts: • Part I: Establish a conceptual framework for determining reliability specifications and assessing reliability performance in new product development. • Part II: Discuss briefly the tools and techniques needed in the above framework. • Part III: Conduct case studies. This report documents the results from Parts I and II of the research project. The conceptual framework presented in Part I provides the basis for Part II of the research project which deals with the tools and techniques needed. Reliability Performance and Specifications in New Product Development T. Østeras1, D.N.P. Murthy2 and M. Rausand3 Part I: A Conceptual Framework 1 Associate Professor of Design Engineering, the Norwegian University of Science and Technology, Trondheim, Norway. 2 Professor of Engineering and Operations Management, The University of Queensland, Australia and Senior Scientific Advisor, Norwegian University of Science and Technology, Trondheim, Norway. 3 Professor of Safety and Reliability Engineering, the Norwegian University of Science and Technology, Trondheim, Norway. Table of Contents 1 INTRODUCTION................................................................................................1 2 PRODUCTS..........................................................................................................3 2.1 PRODUCT CLASSIFICATION .............................................................................3 2.2 PRODUCT DECOMPOSITION .............................................................................7 2.3 PRODUCT LIFE CYCLE.....................................................................................9 2.3.1 Manufacturer’s Point of View................................................................9 2.3.2 Buyers’ Point of View ..........................................................................10 3 PRODUCT PROPERTIES AND PERFORMANCE.....................................11 3.1 DEFINITIONS .................................................................................................11 3.1.1 Product Properties...............................................................................11 3.1.2 Product Performance...........................................................................13 3.2 PRODUCT PERFORMANCE: DIFFERENT PERSPECTIVES ..................................15 3.2.1 Buyer's Perspective..............................................................................15 3.2.2 Manufacturer's Perspective .................................................................16 3.2.3 Product Life Cycle (PLC) Perspective.................................................17 3.3 PRODUCT QUALITY AND CUSTOMER SATISFACTION.....................................19 3.3.1 Product Quality....................................................................................19 3.3.2 Customer Satisfaction ..........................................................................19 3.4 PRODUCT COST.............................................................................................23 3.4.1 Manufacturers’ versus Buyers’ Perspective ........................................23 3.4.2 Operating Cost versus Product Performance......................................24 4 NEW PRODUCT DEVELOPMENT (NPD) PROCESSES...........................26 4.1 DRIVERS FOR NPD........................................................................................26 4.2 NPD PHASES.................................................................................................27 4.2.1 Front-End [Phase 1]............................................................................27 4.2.2 Design [Phases 2 and 3]......................................................................28 4.2.3 Development [Phases 4 and 5] ............................................................29 4.2.4 Production [Phase 6]...........................................................................29 4.2.5 Testing..................................................................................................30 4.3 AN ALTERNATIVE MULTILEVEL CHARACTERISATION ..................................30 4.4 EVALUATIONS AND ITERATIONS ...................................................................31 4.5 DECISION-MAKING .......................................................................................34 4.6 DATA AND INFORMATION FLOW ...................................................................35 5 PRODUCT SPECIFICATION.........................................................................37 5.1 CONCEPT AND DEFINITION............................................................................37 5.2 RELATIONSHIP BETWEEN OBJECTIVE AND PERFORMANCE............................39 5.3 RELATIONSHIP BETWEEN PERFORMANCE AND SPECIFICATION .....................40 5.4 PERFORMANCE AND SPECIFICATION LINKS IN THE NPD PROCESS................41 5.4.1 Stage I ..................................................................................................41 5.4.2 Stage II.................................................................................................42 6 CONCEPTUAL MODEL FOR PRODUCT SPECIFICATION ..................44 6.1 FRONT-END PHASE (STAGE I, LEVEL I) ........................................................44 6.2 DESIGN PHASES (STAGE I, LEVELS II AND III) ..............................................45 - i - 6.3 DEVELOPMENT PHASES (STAGE II, LEVELS II AND III).................................47 6.4 PRODUCTION (STAGE II, LEVEL I).................................................................47 6.5 FACTORS INFLUENCING OBJECTIVE AND PERFORMANCE..............................48 6.5.1 Objective ..............................................................................................48 6.5.2 Desired Performance [DP-I]...............................................................49 6.5.3 Predicted Performance ........................................................................50 6.5.4 Actual Field Performance....................................................................50 6.5.5 Overview of Factors Influencing Product Performance......................51 7 PRODUCT RELIABILITY ..............................................................................53 7.1 DEFINITION OF RELIABILITY .........................................................................53 7.2 PRODUCT DEGRADATION AND FAILURES......................................................53 7.2.1 Failures Related to Functions..............................................................54 7.2.2 Failure Modes......................................................................................56 7.2.3 Failure Causes and Severity ................................................................58 7.2.4 Deterioration........................................................................................60 7.3 MAINTENANCE AND MAINTAINABILITY........................................................61 7.3.1 Maintenance Actions............................................................................61 7.3.2 Maintenance Costs...............................................................................62 7.3.3 Maintainability.....................................................................................63 7.4 CONSEQUENCES OF FAILURES.......................................................................64 7.4.1 Customers Point of View......................................................................64 7.4.2 Manufacturers Point of View...............................................................66 7.5 PRODUCT RELIABILITY .................................................................................66 7.5.1 Life Cycle Perspective..........................................................................66 7.5.2 Product Profitability Perspective ........................................................68 7.6 CHARACTERISATION OF PRODUCT RELIABILITY ...........................................69 7.6.1 First Failure.........................................................................................69 7.6.2 Subsequent Failures.............................................................................71 7.6.3 Failures over Time...............................................................................72 7.6.4 Availability...........................................................................................73 8 RELIABILITY SPECIFICATIONS................................................................75 8.1 INTRODUCTION .............................................................................................75 8.2 LITERATURE REVIEW....................................................................................75 8.2.1 Selecting the Desired Reliability
Load more

Recommended publications
  • An Architect's Guide to Site Reliability Engineering Nathaniel T
    An Architect's Guide to Site Reliability Engineering Nathaniel T. Schutta @ntschutta ntschutta.io https://content.pivotal.io/ ebooks/thinking-architecturally Sofware development practices evolve. Feature not a bug. It is the agile thing to do! We’ve gone from devs and ops separated by a large wall… To DevOps all the things. We’ve gone from monoliths to service oriented to microserivces. And it isn’t all puppies and rainbows. Shoot. A new role is emerging - the site reliability engineer. Why? What does that mean to our teams? What principles and practices should we adopt? How do we work together? What is SRE? Important to understand the history. Not a new concept but a catchy name! Arguably goes back to the Apollo program. Margaret Hamilton. Crashed a simulator by inadvertently running a prelaunch program. That wipes out the navigation data. Recalculating… Hamilton wanted to add error-checking code to the Apollo system that would prevent this from messing up the systems. But that seemed excessive to her higher- ups. “Everyone said, ‘That would never happen,’” Hamilton remembers. But it did. Right around Christmas 1968. — ROBERT MCMILLAN https://www.wired.com/2015/10/margaret-hamilton-nasa-apollo/ Luckily she did manage to update the documentation. Allowed them to recover the data. Doubt that would have turned into a Hollywood blockbuster… Hope is not a strategy. But it is what rebellions are built on. Failures, uh find a way. Traditionally, systems were run by sys admins. AKA Prod Ops. Or something similar. And that worked OK. For a while. But look around your world today.
    [Show full text]
  • Chapter 6 Structural Reliability
    MIL-HDBK-17-3E, Working Draft CHAPTER 6 STRUCTURAL RELIABILITY Page 6.1 INTRODUCTION ....................................................................................................................... 2 6.2 FACTORS AFFECTING STRUCTURAL RELIABILITY............................................................. 2 6.2.1 Static strength.................................................................................................................... 2 6.2.2 Environmental effects ........................................................................................................ 3 6.2.3 Fatigue............................................................................................................................... 3 6.2.4 Damage tolerance ............................................................................................................. 4 6.3 RELIABILITY ENGINEERING ................................................................................................... 4 6.4 RELIABILITY DESIGN CONSIDERATIONS ............................................................................. 5 6.5 RELIABILITY ASSESSMENT AND DESIGN............................................................................. 6 6.5.1 Background........................................................................................................................ 6 6.5.2 Deterministic vs. Probabilistic Design Approach ............................................................... 7 6.5.3 Probabilistic Design Methodology.....................................................................................
    [Show full text]
  • Training-Sre.Pdf
    C om p lim e nt s of Training Site Reliability Engineers What Your Organization Needs to Create a Learning Program Jennifer Petoff, JC van Winkel & Preston Yoshioka with Jessie Yang, Jesus Climent Collado & Myk Taylor REPORT Want to know more about SRE? To learn more, visit google.com/sre Training Site Reliability Engineers What Your Organization Needs to Create a Learning Program Jennifer Petoff, JC van Winkel, and Preston Yoshioka, with Jessie Yang, Jesus Climent Collado, and Myk Taylor Beijing Boston Farnham Sebastopol Tokyo Training Site Reliability Engineers by Jennifer Petoff, JC van Winkel, and Preston Yoshioka, with Jessie Yang, Jesus Climent Collado, and Myk Taylor Copyright © 2020 O’Reilly Media. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more infor‐ mation, contact our corporate/institutional sales department: 800-998-9938 or [email protected]. Acquistions Editor: John Devins Proofreader: Charles Roumeliotis Development Editor: Virginia Wilson Interior Designer: David Futato Production Editor: Beth Kelly Cover Designer: Karen Montgomery Copyeditor: Octal Publishing, Inc. Illustrator: Rebecca Demarest November 2019: First Edition Revision History for the First Edition 2019-11-15: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781492076001 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Training Site Reli‐ ability Engineers, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc.
    [Show full text]
  • Reliability: Software Software Vs
    Reliability Theory SENG 521 Re lia bility th eory d evel oped apart f rom th e mainstream of probability and statistics, and Software Reliability & was usedid primar ily as a tool to h hlelp Software Quality nineteenth century maritime and life iifiblinsurance companies compute profitable rates Chapter 5: Overview of Software to charge their customers. Even today, the Reliability Engineering terms “failure rate” and “hazard rate” are often used interchangeably. Department of Electrical & Computer Engineering, University of Calgary Probability of survival of merchandize after B.H. Far （[email protected]） 1 http://www. enel.ucalgary . ca/People/far/Lectures/SENG521/ ooene MTTF is R e 0.37 From Engineering Statistics Handbook [email protected] 1 [email protected] 2 Reliability: Natural System Reliability: Hardware Natural system Hardware life life cycle. cycle. Aging effect: Useful life span Life span of a of a hardware natural system is system is limited limited by the by the age (wear maximum out) of the system. reproduction rate of the cells. Figure from Pressman’s book Figure from Pressman’s book [email protected] 3 [email protected] 4 Reliability: Software Software vs. Hardware So ftware life cyc le. Software reliability doesn’t decrease with Software systems time, i.e., software doesn’t wear out. are changed (updated) many Hardware faults are mostly physical faults, times during their e. g., fatigue. life cycle. Each update adds to Software faults are mostly design faults the structural which are harder to measure, model, detect deterioration of the and correct. software system. Figure from Pressman’s book [email protected] 5 [email protected] 6 Software vs.
    [Show full text]
  • Technology Planning for Emerging Business Model and Regulatory Integration: the Case of Electric Vehicle Smart Charging
    Portland State University PDXScholar Engineering and Technology Management Faculty Publications and Presentations Engineering and Technology Management 9-1-2016 Technology Planning for Emerging Business Model and Regulatory Integration: The Case of Electric Vehicle Smart Charging Kelly Cowan Portland State University Tugrul U. Daim Portland State University, [email protected] Follow this and additional works at: https://pdxscholar.library.pdx.edu/etm_fac Part of the Operations Research, Systems Engineering and Industrial Engineering Commons Let us know how access to this document benefits ou.y Citation Details Cowan, Kelly and Daim, Tugrul U., "Technology Planning for Emerging Business Model and Regulatory Integration: The Case of Electric Vehicle Smart Charging" (2016). Engineering and Technology Management Faculty Publications and Presentations. 104. https://pdxscholar.library.pdx.edu/etm_fac/104 This Article is brought to you for free and open access. It has been accepted for inclusion in Engineering and Technology Management Faculty Publications and Presentations by an authorized administrator of PDXScholar. Please contact us if we can make this document more accessible: [email protected]. 2016 Proceedings of PICMET '16: Technology Management for Social Innovation Technology Planning for Emerging Business Model and Regulatory Integration: The Case of Electric Vehicle Smart Charging Kelly Cowan, Tugrul U Daim Dept. of Engineering and Technology Management, Portland State University, Portland OR - USA Abstract--Smart grid has been described as the Energy I. LITERATURE REVIEW Internet: Where Energy Technology meets Information Technology. The incorporation of such technology into vast Literature from several key literature streams has been existing utility infrastructures offers many advantages, reviewed and research gaps were identified.
    [Show full text]
  • Software Reliability and Dependability: a Roadmap Bev Littlewood & Lorenzo Strigini
    Software Reliability and Dependability: a Roadmap Bev Littlewood & Lorenzo Strigini Key Research Pointers Shifting the focus from software reliability to user-centred measures of dependability in complete software-based systems. Influencing design practice to facilitate dependability assessment. Propagating awareness of dependability issues and the use of existing, useful methods. Injecting some rigour in the use of process-related evidence for dependability assessment. Better understanding issues of diversity and variation as drivers of dependability. The Authors Bev Littlewood is founder-Director of the Centre for Software Reliability, and Professor of Software Engineering at City University, London. Prof Littlewood has worked for many years on problems associated with the modelling and evaluation of the dependability of software-based systems; he has published many papers in international journals and conference proceedings and has edited several books. Much of this work has been carried out in collaborative projects, including the successful EC-funded projects SHIP, PDCS, PDCS2, DeVa. He has been employed as a consultant to industrial companies in France, Germany, Italy, the USA and the UK. He is a member of the UK Nuclear Safety Advisory Committee, of IFIPWorking Group 10.4 on Dependable Computing and Fault Tolerance, and of the BCS Safety-Critical Systems Task Force. He is on the editorial boards of several international scientific journals. 175 Lorenzo Strigini is Professor of Systems Engineering in the Centre for Software Reliability at City University, London, which he joined in 1995. In 1985-1995 he was a researcher with the Institute for Information Processing of the National Research Council of Italy (IEI-CNR), Pisa, Italy, and spent several periods as a research visitor with the Computer Science Department at the University of California, Los Angeles, and the Bell Communication Research laboratories in Morristown, New Jersey.
    [Show full text]
  • Product Development Value Stream Mapping (PDVSM) Manual
    Product Development Value Stream Mapping (PDVSM) Manual Release 1.0 September 2005 Hugh L. McManus, PhD The Lean Aerospace Initiative Sept. 2005 Product Development Value Stream Mapping (PDVSM) Manual 1.0 Prepared by: Dr. Hugh L. McManus Metis Design 222 Third St., Cambridge MA 02142 [email protected] for the Lean Aerospace Initiative Center for Technology, Policy, and Industrial Development Massachusetts Institute of Technology 77 Massachusetts Avenue • Room 41-205 Cambridge, MA 02139 The author acknowledges the financial support for this research made available by the Lean Aerospace Initiative (LAI) at MIT, sponsored jointly by the US Air Force and a consortium of aerospace companies. All facts, statements, opinions, and conclusions expressed herein are solely those of the author and do not in any way reflect those of the LAI, the US Air Force, the sponsoring companies and organizations (individually or as a group), or MIT. The latter are absolved from any remaining errors or shortcomings for which the author takes full responsibility. This document is copyrighted 2005 by MIT. Its use falls under the LAI consortium agreement. LAI member companies may use, reproduce, and distribute this document for internal, non-commercial purposes. This notice should accompany any copies made of the document, or any parts thereof. This document is formatted for double-sided printing and edge binding. Blank pages are inserted for this purpose. Color printing is preferred, but black-and-white printing should still result in a usable document. TABLE
    [Show full text]
  • Effective New Product Ideation: IDEATRIZ Methodology
    Effective New Product Ideation: IDEATRIZ Methodology Marco A. de Carvalho Universidade Tecnológica Federal do Paraná, Mechanical Engineering Department, Av. Sete de Setembro 3165, 80230-901 Curitiba PR, Brazil [email protected] Abstract. It is widely recognized that innovation is an activity of strategic im- portance. However, organizations seeking to be innovative face many dilem- mas. Perhaps the main one is that, though it is necessary to innovate, innovation is a highly risky activity. In this paper, we explore the origin of product innova- tion, which is new product ideation. We discuss new product ideation ap- proaches and their effectiveness and provide a description of an effective new product ideation methodology. Keywords: Product Development Management, New Product Ideation, TRIZ. 1 Introduction Introducing new products is one of the most important activities of companies. There is a significant correlation between innovative firms and leadership status [1]. On the other hand, evidence shows that most of the new products introduced fail [2]. There are many reasons for market failures of new products. This paper deals with one of the main potential sources for success or failure in new products: the quality of new product ideation. Ideation is at the start of product innovation, as recognized by eminent authors in the field such as Cooper [1], Otto & Wood [3], Crawford & Di Benedetto [4], and Pahl, Beitz et al. [5]. According to the 2005 Arthur D. Little innovation study [6], idea management has a strong impact on the increase in sales associated to new products. This impact is measured as an extra 7.2 percent of sales from new products and makes the case for giving more attention to new product ideation.
    [Show full text]
  • Big Data for Reliability Engineering: Threat and Opportunity
    Reliability, February 2016 Big Data for Reliability Engineering: Threat and Opportunity Vitali Volovoi Independent Consultant [email protected] more recently, analytics). It shares with the rest of the fields Abstract - The confluence of several technologies promises under this umbrella the need to abstract away most stormy waters ahead for reliability engineering. News reports domain-specific information, and to use tools that are mainly are full of buzzwords relevant to the future of the field—Big domain-independent1. As a result, it increasingly shares the Data, the Internet of Things, predictive and prescriptive lingua franca of modern systems engineering—probability and analytics—the sexier sisters of reliability engineering, both statistics that are required to balance the otherwise orderly and exciting and threatening. Can we reliability engineers join the deterministic engineering world. party and suddenly become popular (and better paid), or are And yet, reliability engineering does not wear the fancy we at risk of being superseded and driven into obsolescence? clothes of its sisters. There is nothing privileged about it. It is This article argues that“big-picture” thinking, which is at the rarely studied in engineering schools, and it is definitely not core of the concept of the System of Systems, is key for a studied in business schools! Instead, it is perceived as a bright future for reliability engineering. necessary evil (especially if the reliability issues in question are safety-related). The community of reliability engineers Keywords - System of Systems, complex systems, Big Data, consists of engineers from other fields who were mainly Internet of Things, industrial internet, predictive analytics, trained on the job (instead of receiving formal degrees in the prescriptive analytics field).
    [Show full text]
  • New Product Development Methods: a Study of Open Design
    New Product Development Methods: a study of open design by Ariadne G. Smith S.B. Mechanical Engineering Massachusetts Institute of Technology, 2010 SUBMITTED TO THE DEPARTMENT OF ENGINEERING SYSTEMS DEVISION AND THE DEPARTMENT OF MECHANICAL ENGINEERING IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREES OF MASTER OF SCIENCE IN TECHNOLOGY AND POLICY AND MASTER OF SCIENCE IN MECHANICAL ENGINEERING A; SW AT THE <iA.Hu§TTmrrE4 MASSACHUSETTS INSTITUTE OF TECHNOLOGY H 2 INSTI' SEPTEMBER 2012 @ 2012 Massachusetts Institute of Technology. All rights reserved. Signature of Author: Department of Engineering Systems Division Department of Mechanical Engineering Certified by: LI David R. Wallace Professor of Mechanical Engineering and Engineering Systems Thesis Supervisor Certified by: Joel P. Clark P sor of Materials Systems and Engineering Systems Acting Director, Te iology and Policy Program Certified by: David E. Hardt Ralph E. and Eloise F. Cross Professor of Mechanical Engineering Chairman, Committee on Graduate Students New Product Development Methods: a study of open design by Ariadne G. Smith Submitted to the Departments of Engineering Systems Division and Mechanical Engineering on August 10, 2012 in Partial Fulfillment of the Requirements for the Degree of Master of Science in Technology and Policy and Master of Science in Mechanical Engineering ABSTRACT This thesis explores the application of open design to the process of developing physical products. Open design is a type of decentralized innovation that is derived from applying principles of open source software and crowdsourcing to product development. Crowdsourcing has gained popularity in the last decade, ranging from translation services, to marketing concepts, and new product funding.
    [Show full text]
  • Novice Designers' Use of Prototypes in Engineering Design
    Novice designers’ use of prototypes in engineering design Michael Deininger, Shanna R. Daly, Kathleen H. Sienko and Jennifer C. Lee, University of Michigan, George G. Brown Laboratory, Hayward Street, Ann Arbor, MI 48109, USA Prototypes are essential tools in product design processes, but are often underutilized by novice designers. To help novice designers use prototypes more effectively, we must first determine how they currently use prototypes. In this paper, we describe how novice designers conceptualized prototypes and reported using them throughout a design project, and we compare reported prototyping use to prototyping best practices. We found that some of the reported prototyping practices by novice designers, such as using inexpensive prototypes early and using prototypes to define user requirements, occurred infrequently and lacked intentionality. Participants’ initial descriptions of prototypes were less sophisticated than how they later described using them, and only upon prompted reflection did participants recognize more specific benefits of using prototypes. Ó 2017 Elsevier Ltd. All rights reserved. Keywords: design education, novice designers, product design, prototypes, user centered design rototyping is a combination of methods that allows physical or visual form to be given to an idea (Kelley & Littman, 2006; Schrage, 2013) Pand plays an essential role in the product development process, enabling designers to specify design problems, meet user needs and engineer- ing requirements, and verify design solutions (De Beer, Campbell, Truscott, Barnard, & Booysen, 2009; Moe, Jensen, & Wood, 2004; Viswanathan & Linsey, 2009; Yang & Epstein, 2005). Designers tend to think of prototypes as three-dimensional models, but nonphysical models, including 2D sketches and 3D CAD models, as well as existing products or artifacts, can also serve as prototypes (Hamon & Green, 2014; Ullman, Wood, & Craig, 1990; Wang, 2003).
    [Show full text]
  • Reducing Product Development Risk with Reliability Engineering Methods
    Reducing Product Development Risk with Reliability Engineering Methods Mike McCarthy Reliability Specialist Who am I? • Mike McCarthy, Principal Reliability Engineer – BSc Physics, MSc Industrial Engineering – MSaRS (council member), MCMI, – 18+ years as a reliability practitioner – Extensive experience in root cause analysis of product and process issues and their corrective action. • Identifying failure modes, predicting failure rates and cost of ‘unreliability’ – I use reliability tools to gain insight into business issues - ‘Risk’ based decision making 2 Agenda ‘Probable’ Duration 1. Risk 2 min 2. Reliability Tools to Manage Risk 4 min 3. FMECA 6 min 4. Design of Experiments (DoE) 5 min 5. Accelerated Testing 5 min 6. Summary 3 min 7. Questions 5 min Total: 30 min 3 Managing Risk? Design Installation Terry Harris © GreenHunter Bio Fuels Inc. Maintenance Operation Chernobyl 4 Likelihood-Consequence Curve Consequence Catastrophic Prohibited ‘Acceptable’ Negligible Likelihood Impossible Certain (frequency) to occur 5 Reliability Tools to Manage Risk 6 Tools to Manage Risk • Design Reviews • FRACAS/DRACAS Review & • Subcontractor Review Control • Part Selection & Control (including de-rating) • Computer Aided Engineering Tools (FEA/CFD) • FME(C)A / FTA Design & • System Prediction & Allocation (RBDs) • Quality Function Deployment (QFD) Analysis • Critical Item Analysis • Thermal/Vibration Analysis & Management • Predicting Effects of Storage, Handling etc • Life Data Analysis (eg Weibull) • Reliability Qualification Testing Test & • Maintainability
    [Show full text]