The Engineering Design Process

Presented by Bryan Rosenstiel

Developed largely by

M. Conner, V. P. Nelson & R. M. Nelms

Outline

“Discovery” vs. “Design”? The Design Process

Design Specifications Design Alternatives Modeling and Simulation Implementation Testing

Example

Discovery vs. Design

The Scientific Method is an algorithm for discovery.

The Engineering Design Process is an algorithm for design.

Scientific Method

1. Observe the environment.2. Invent a tentative description or

hypothesis – describe.3. Use the hypothesis to predict.4. Test the predictions via experiments and

modify the hypothesis.5. Repeat Steps 3 and 4 until hypothesis

agrees with the experiments.

Definition of “Design”

International Technology Education Association:“The systematic and creative application of scientific and

mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.”

Accreditation Board for Engineering & Technology:

“Students must be prepared for engineering practice through the curriculum culminating in a major design experience based on the knowledge and skills acquired in earlier course work and incorporating engineering standards and multiple realistic constraints”

The Engineering Design Process

IdentifyProblem

GenerateDesign

Alternatives

DevelopSpecifications

Model &Simulate

ImplementPrototype

Test

Document

Practical Engineering Design Bystrom & Eisenstein – Figure 1.1

FormTeam

Design Objective

Big picture idea of what the design should be able to do

Nothing specific in terms of requirements or constraints

No indication as to a particular design solution

ObjectiveSpecsSolutionsModelPrototypeTest

Specifications

A more precise description of the system: should not imply a particular architecture; provides input to the architecture design process.

May be developed in several ways: talking directly to customers; talking to marketing representatives; providing prototypes to users for comment.

May include functional and non-functional requirements.

May include constraints placed on the design.

ObjectiveSpecsSolutionsModelPrototypeTest

Typical Project Specifications

Some specifications are absolute – others may be negotiable Functionality (inputs, outputs, operating modes) Performance (speed, resolution, latency) Cost Ease of use Reliability, durability, security, fault tolerance Physical (size, weight, temperature, radiation) Power (voltage levels, battery life) Conformance to applicable standards Compatibility with existing product(s)

ObjectiveSpecsSolutionsModelPrototypeTest

Functional vs. Non-Functional Requirements

Functional requirements: output as a function of input.

Non-functional requirements: time required to compute output; size, weight, etc.; power consumption; reliability; etc.

ObjectiveSpecsSolutionsModelPrototypeTest

Design Constraints

Physical Economic Environmental Social Time to market Political

Ethical Health and safety Reliability Manufacturability Sustainability Adherence to standards

• Multiple constraints usually apply• Constraints are often conflicting•Trade-offs are often needed to satisfy constraints Examples:

ObjectiveSpecsSolutionsModelPrototypeTest

Architecture Design

What major components go to satisfying the specification?

Hardware components: CPUs, peripherals, etc.

Software components: major programs and their operations.

Must take into account functional and non-functional specifications.

ObjectiveSpecsSolutionsModelPrototypeTest

Design Alternatives

Consider different design approaches that meet the specifications Most involve trade-offs – some specifications can be

modified, others cannot Define performance metrics that must be met

Follow top-down design process Partition design into well-defined modules Design and test modules independently Integrate the modules into a system and test the system

Selection of components, programming languages, etc. Develop vs. purchase (use of “Intellectual Property”)

ObjectiveSpecsSolutionsModelPrototypeTest

Model & Simulate

Where prototyping is impractical or expensive

Verify design prior to implementation Avoid expensive mistakes Ensure that design will meet specifications Some design details easier to verify in

simulation than on prototype Develop test for manufactured product

ObjectiveSpecsSolutionsModelPrototypeTest

Implement Prototype

Implementation should follow naturally from previous design and modeling

Determine order in which modules should be implemented, testing at each stage

Plan ahead for tools needed for implementation Compilers/software tools Chip sockets, connectors, cables PC boards (through-hole vs. surface-mount, etc.) Test equipment

ObjectiveSpecsSolutionsModelPrototypeTest

Test & Verification

Develop a test plan early in the design stage – incorporate testability features as necessary

Test throughout design and implementation Test components independently, and then

the integrated system functions Final test to verify meeting of

specifications, as well as safety Ensure the product is “user proof” (test all

external conditions/events) perhaps have non-designer test the product

ObjectiveSpecsSolutionsModelPrototypeTest

General Troubleshooting

Define the problem: symptoms, extent

What module could becausing the problem?

Evaluation: Is this cause reasonable? Would fixing it fix the problem?

Select the most likelycause of the problem

Repair

Evaluation: Problem solved? If not, check another possible cause

Analysis

Synthesis

Decision

Action

Evaluation

Engineering Design, Alan Wilcox – Pg. 39

ObjectiveSpecsSolutionsModelPrototypeTest

The Design Process:A Teaching Tool

Within BEST, the Design Process can be applied to The robot as a whole Individual components of the robot –

propulsion, “arm”, “grabber”, base, etc. The Project Notebook The group presentation The Six Weeks of BEST

Encouragements

Have your students formally apply the design process to the various aspects of BEST.

Have your students document each stage of the design process.

Encourage “design”, but recognize the value of trial and error!

Remind students of the gulf between a proposed design and an implemented (i.e. functioning) design!!!

Documentation

Objective? Specifications? (Requirements, Goals,

Constraints) Design Alternatives? Modeling and Simulation results? Prototype: Successes? Failures? Testing?

Guiding Principles

Don’t reinvent the wheel: read data sheets and application notes Reduce your problem to something you’ve solved before If you can’t meet the spec’s, negotiate; don’t hide the problem Always have an answer; you have to start somewhere Change one variable at a time when you adjust your design Build a quick simple circuit for experimentation; understand it Keep designs simple Use multifunction integrated devices when possible Talking aloud to yourself and team members helps spot errors If you find you made a mistake, figure out why Solve the right problem Act rather than react; think ahead to prevent problems from cropping up Read the fine print at the bottom of data sheets When in doubt, don’t guess; look it up and be sure Manage your time

Engineering Design, Alan Wilcox – Pg. 36

References

Practical Engineering Design, Maja Bystrom & Bruce Eisenstein, CRC Press, 2005

Engineering Design for Electrical Engineers, Alan D. Wilcox, Prentice-Hall, 1990

Computers as Components – Principles of Embedded Computing Systems Design, Wayne Wolf, Morgan Kaufmann, 2001