1Spring 2013/V0.1

Senior Design: A Hands-on Experience with The Engineering Process

This is an iterative process

Problem

Design Constraints

Test Specification

Design

SimulationTest Verification

Prototyping

Test Verification

Hardware Implementation,

Design Refinement, packaging

Test Verification

Design IIDesign I

2Spring 2013/V0.1

• Problem: recognize that a problem exists, and develop a concise statement of the problem.

• Objectives: study the parameters of the problem, and convert them into engineering language you are familiar with.

• Literature Survey: assimilate existing knowledge about the problem, and search for similar data (related experiments, evaluations, etc.)

The Engineering Process

a design methodology . . .

3Spring 2013/V0.1

• Analysis: analyze the problem based on the knowledge gained from the literature survey, produce a set of design constraints, and generate test specifications to verify these design constraints.

• Synthesis: manipulate the analysis to yield a family of solutions (typically through simulation and prototyping).

• Evaluation: choose the best solution and verify it meets the design constraints.

• Presentation: communicate the solution to your peers/management.

The Engineering Processa design methodology continued . . .

4Spring 2013/V0.1

Design I Structure• Lectures: Meets once a week

– Thursdays for Design I lectures, some weeks Tuesdays for Entrepeneurship lectures

– Lectures on team building, planning, software design, design document

• Assignments:

– Writing assignments for design document in conjunction with GE 3513 tech writing

– Website (see syllabus)

• Presentations: mid-term, end-of-semester

Must demonstrate working prototype of project at end of semester!!

5Spring 2013/V0.1

Design I Structure (cont.)

• Grading: Design Document, presentations, weekly deliverables, peer reviews, web site, advisor input, etc (see syllabus)

– Team members do not necessarily all get the same grade!

– Custom grading forms for each team/presentation

• Funding: Donations and other funding

– Ryan Green will handle this, $200 per team

• Lab Space: Room 311, shared by Senior Design I & II

• Conference Room: Simrall 206

6Spring 2013/V0.1

Success in Design 1 is Up to You!• Progress on technical goals is entirely up to the

team– Faculty advisor is not a task master – only “advises”– The team sets the weekly goals, measures weekly

progress

• Many projects require you to explore new technologies on your own initiative– Welcome to life-long learning! – Take advantage of all possible resources

7Spring 2013/V0.1

Design I Pitfalls• Design I is the critical semester

– Design II difficulty depends on Design I success• Pitfalls

– Poorly specified goals, constraints for project• Much time spent in semester beginning on this!!!

– Poor implementation choices for key technical aspects• Spend time on tradeoff analysis, survey of

alternatives!– Lack of weekly progress

• Schedule a weekly meeting with your faculty advisor NOW.

• Make REAL progress – connect wires, write code!– Malfunctioning teams (more on this later)

8Spring 2013/V0.1

Design I Complaints• Believe it or not, we do listen to you!

– Increased from 1 hour to 4 hours spread over two semesters

– Integrated Design I writing with Tech Writing

– Added lab/meeting space reserved for Senior Design

• Common complaints

– “Too much work for too little credit”

• Design takes time – get used to it

• Work smarter to reduce effort by using faculty, expert resources

– “Why do we have to do assignment X? Just let us do our design!”

• Planning, documentation, oral communication – all are a real part of design!!!

9Spring 2013/V0.1

Planning Your Project

• Phase 1 – System definition

– Specifications and Features

– Physical Interface

– Subsystem definition and investigation of alternatives for each subsystem

• Phase 2 – Design/test of individual subsystems

– Requires prototyping of different subsystems, perhaps even prototyping of different alternatives. Do not be surprised when something that you assumed turns out not to be true, requiring you to backtrack!

– agreement between team members on how subsystems will interact

• Phase 3 – Subsystem integration

– Connecting subsystems together and getting them to work correctly takes time!

10Spring 2013/V0.1

Writing Assignments vs. Project Development

• The writing assignments LAG the project development

– Your project development should be well ahead of the writing assignments, as the due dates for the writing assignments are spread out without regard to project development.

• Having the project development ahead of the writing assignments make the writing assignments easier, since you have something to write about!

– Writing up the different alternatives for a subsystem will be easy since you have already had actual experience with the subsystems.

11Spring 2013/V0.1

Pitfalls in Project Development• Do not assume that a circuit you find via Google will work the way that it is

documented.

– Until you build it yourself, you know nothing.

– Understand the circuit! Simulate in Pspice if that is an option!

– If it is an analog circuit, when you integrate it with other components (like a microprocessor), it may quit operating.

• Read the datasheet!!!!!!

– If the datasheet specs are unsuitable, then don’t waste your time.

• Consider packaging – if the part is only available a surface mount package, it will be harder to prototype with.

• If a design has a lot of components, consider using a PCB from the start since breadboard wiring will drive you crazy.

• Order spare parts so that if something breaks, you will have a backup.

12Spring 2013/V0.1

Pitfalls in Project Development (cont)

• Be careful how you divide the labor

– The best way is to divide it by subsystem, with lots of communications between the team members on how the subsystems interact

• In a hardware subsystem that has a microcontroller, you cannot divide the software development and the external hardware development between multiple people

– Software is needed to drive the hardware, and the software creator needs an intimate understanding of the hardware.

– You can divide it by functionality which combines hardware+software (Joe will handle the LCD code and LCD interfacing, Sally will handle the DAC code and DAC interfacing).

• Everybody must contribute technically. You cannot have somebody whose only job is the web page or documentation!

13Spring 2013/V0.1

Assign. #1: Product Specification• One page• Contains Applications, Features, Specifications

– Applications: how can this be used?– Features: what can it do?– Specifications: quantitative measures of what it can

and cannot do, requirements for use

• Visually appealing, tells all in one page– Contains one or more graphics of product itself and

usage of product in typical scenarios

• Post this on your web site (use .pdf files)

14Spring 2013/V0.1

Example Specifications• Signal tolerances (> 30% duty cycle clock at 1MHz +/-1%)

• Supply current range (.5 mA min to 100 mA max)

• Power efficiency (83% supply efficiency at rated load)

• Speed, Response time (interrupt service latency < 10 S)

• Conversion rate (12-bit conversion at 500Ksamples/sec)

• Transmission distance (100 M with unobstructed view)

• Quantization error (+,- 5mV)

• Frequency response (20 Hz to 20 KHz, +/- 3 dB)

• Signal-to-noise ratio (50 dB min)

• Power requirements (7 to 12 V DC)

• Environmental (functions in range of -25 C to +125 C)

• Limitations (requires Windows XP or later)

• Battery life (battery lasts for 20 hours of constant use)