1. The Engineering Design Process
Presented by Bryan Rosenstiel
Developed largely by
M. Conner, V. P. Nelson & R. M. Nelms

2. Outline “Discovery” vs. “Design”? The Design Process Example
Design Specifications
Design Alternatives
Modeling and Simulation
Implementation
Testing
Example

3. Discovery vs. Design
The Scientific Method is an algorithm for discovery.
The Engineering Design Process is an algorithm for design.

4. Scientific Method Observe the environment.
Invent a tentative description or hypothesis – describe.
Use the hypothesis to predict.
Test the predictions via experiments and modify the hypothesis.
Repeat Steps 3 and 4 until hypothesis agrees with the experiments.

5. 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”

6. The Engineering Design Process
Practical Engineering Design Bystrom & Eisenstein – Figure 1.1
Identify
Problem
Form
Team
Develop
Specifications
Generate
Design
Alternatives
Model &
Simulate
Document
Implement
Prototype
Test

7. Objective
Specs
Solutions
Model
Prototype
Test
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

8. Specifications A more precise description of the system:
Objective
Specs
Solutions
Model
Prototype
Test
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.

9. Typical Project Specifications
Objective
Specs
Solutions
Model
Prototype
Test
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)

10. Functional vs. Non-Functional Requirements
Objective
Specs
Solutions
Model
Prototype
Test
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.

11. Design Constraints Multiple constraints usually apply
Objective
Specs
Solutions
Model
Prototype
Test
Design Constraints
Multiple constraints usually apply
Constraints are often conflicting
Trade-offs are often needed to satisfy constraints
Examples:
Physical
Economic
Environmental
Social
Time to market
Political
Ethical
Health and safety
Reliability
Manufacturability
Sustainability
Adherence to standards

12. Objective
Specs
Solutions
Model
Prototype
Test
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.

13. Objective
Specs
Solutions
Model
Prototype
Test
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”)

14. Model & Simulate Where prototyping is impractical or expensive
Objective
Specs
Solutions
Model
Prototype
Test
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

15. Objective
Specs
Solutions
Model
Prototype
Test
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

16. Objective
Specs
Solutions
Model
Prototype
Test
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

17. General Troubleshooting
Objective
Specs
Solutions
Model
Prototype
Test
General Troubleshooting
Define the problem:
symptoms, extent
Analysis
What module could be
causing the problem?
Synthesis
Evaluation:
Is this cause reasonable?
Would fixing it fix the problem?
Evaluation
Select the most likely
cause of the problem
Decision
Repair
Action
Evaluation:
Problem solved?
If not, check another possible cause
Engineering Design,
Alan Wilcox – Pg. 39

18. 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

19. 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!!!

20. Documentation Objective?
Specifications? (Requirements, Goals, Constraints)
Design Alternatives?
Modeling and Simulation results?
Prototype: Successes? Failures?
Testing?

21. Guiding Principles
Engineering Design, Alan Wilcox – Pg. 36
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

22. 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