Product Development

17
Product Development Chapter 6

description

Product Development. Chapter 6. Hardware & Software Techniques. Block diagram the system (Visio) Redundancy Active: failure of one parallel component - the second still works Standby: failure of component – replacement MTBF=mean time between failures = 1/ λ Active MTBF=3/(2 λ ) - PowerPoint PPT Presentation

Transcript of Product Development

Page 1: Product Development

Product Development

Chapter 6

Page 2: Product Development
Page 3: Product Development

Hardware & Software Techniques Block diagram the system (Visio) Redundancy

Active: failure of one parallel component - the second still works

Standby: failure of component – replacement MTBF=mean time between failures = 1/λ

Active MTBF=3/(2λ) Standby MTBF=2/λ

Page 4: Product Development

MIL-HDBK-217

Where to get λ? Google MIL-HDBK-217…

For example, see www.sqconline.com/reliability/index.html

Try wire wound resistor in a missile…

Page 5: Product Development

Component Selection Considerations Component reliability

Vendor assessment (Hx, failure, etc.) Vendor audit (check facility) Vendor evaluation (inspect incoming) Vendor qualification (on-list?)

Component history military & reliability groups government info bases

Safety (FMEA, etc.)

Page 6: Product Development

Hardware & Software Techniques ctd. Component Derating

Practice of limiting the stresses Use 2 watt R in 1 watt situation, decrease failure

rate >30% (T, humidity, P, V, I, friction, vibration) Usage ratio = max stress/stress rating (.5-.9) Goal is reliability! Pacemaker example

Page 7: Product Development

Hardware & Software Techniques ctd. Safety Margin

=(mean safety factor) - 1

=(mean strength/mean stress) - 1 Elevator – safety margin~2 Medical devices – Fries - .5 and up.

Load Protection Environment (see 112) Product misuse Design for variation (6 sigma)

Page 8: Product Development

Experimental Design

Statistical Approach Effective approach for

multivariable situations Taguachi method

Design Process System design Parameter design Tolerance design

Two types of variables Control factors Noise factors

Apply this to design

Page 9: Product Development

Software Development and Engineering Management Planning for safety

(FDA!) Planning for risk

assessment Planning for method

Waterfall Incremental delivery Spiral Cleanroom Code and fix, …

Page 10: Product Development

Software Development and Engineering Management Choose design method

Top-down Data driven OOP

Language (Assembler/C++/Qbasic etc.) Testing Requirements Hazard Analysis!!! (FDA)

Page 11: Product Development

Software Development and Engineering Management

Requirements traceability (FDA)

Software architecture design Well defined modules (logical) Other vendor – standalone Single purpose modules Cohesion & coupling

Implementation (coding) Integration

Page 12: Product Development

Structured/Unstructured Design Techniques Computer/database assisted:

Ideation - ‘Innovation Workbench’

TRIZ Techoptimizer Others…

Example done in class, another in text

Page 13: Product Development

Axiomatic Design

Nam Suh, MIT Requirements, design parameters, process

variables, customer needs = vectors Try to solve, disassociate functional

requirements and design parameters Highly mathematical Acclaro Software

Page 14: Product Development

Reverse Engineering and Redesign Opportunities increase with age of technology Disassembly of product and inventory and

analysis of parts Allows for the potential update or modification

of the parts with technological advances Can drastically increase productivity or

effectiveness in a dated product

Page 15: Product Development

Design Techniques

Very structured approach Pahl and Beitz, Engineering Design Design method contains 8 distinct steps

Semistructured Wilcox, Engineering Design for Electrical

Engineers Ulrich and Eppinger Product Design and

Development

Page 16: Product Development

The Clean-Room Approach To Reverse-Engineering: “One person or group takes a device apart and

describes what it does in as much detail as possible at a higher level of abstraction than the specific code. That description is then given to another group or person who has absolutely no knowledge of the specific device in question. This second party then builds a new device based on the description. The end result is a new device that works identically to the original but was created without any possibility of specifically copying the original. “

-Mathew Schwartz

Page 17: Product Development