Senior SeminarECE 4890 Lecture Notes

Spring 2013

© 2006–13Mark A. Wickert

Engineer

Customer Manufacturer

.

!"!#$%&'#()*+,-#().+*/- +++

!"#$%#$&

!"#$%&'(#)%"*+"&*,%'$-.*/0.$0).1!"#$%&'(#)%"*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*,-,

./0%$*1%'$23*453632*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*,-7893(#$)(/9*/"&*1%6:'#3$*8";)"33$)";*%$*818*@ABB*,-7

1%'$23*CD99/E'2*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*,-F

CD99/E'2*G(%"#H +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*,-@

!"2#$'(#%$*=%9)()32 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*,-I

453*8";)"33$)";*=$%>322)%" +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*,-J

453*K%93*%>*#53**N9#3$"/#)?3*C%9'#)%"2+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*7-I

%$*C#'&3"#*8";)"33$2VC#'&3"#**K3X')$363"#2+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*F-7

)(/#)%"*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*F-F4Y%*C(3"/$)%2*F-F

N*4Y%ZC#/;3*N::$%/(5*#%*)(/#)%"*F-I

K3/9Z[%$9&*1%"2)&3$/#)%"2*F-J

\33&2*N2232263"#-C#/#)";*#53*=$%E936*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*F-JW'32#)%"*#53*1'2#%63$O*8S/6:932*F-L

+0 !"!#$%&'#()*+,-#().+*/-

>3$3"#)/#3*\33&2*/"&*[/"#2*F-A

8S:9%$3*=$%03(#*P%'"&/$)32*F-B

!":'#V]'#:'#*N"/9D2)2*F-B

=$3?)3Y*#53*^23$*!"#3$>/(3*F-,_

C'$?3D*D*1%">9)(#)";*\33&2*F-,,

=$3:/$3*/*#*]:3$/#)%"2*./"'/9*F-,F

=$3:/$3*#53*K3X')$363"#2*C:3()>)(/#)%" *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*F-,F4$/"29/#)";*\33&2*#%*C:3()>)(/#)%"2*F-,F

C:3()>)(/#)%"*%>*!"#3$>/(3*=%)"#2*F-,@

8S(322)?3*K3X')$363"#2*F-,I

`3$)>)(/#)%"*F-,J

*=$%03(#*./"/;363"#*I-F

453*=$%03(#*=9/" +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*I-F

)")";*#53*[%$Q +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*I-I

C(53&'9)";*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*I-J\3#Y%$Q*

!"!#$%&'#()*+,-#().+*/- 0

82#)6/#)";*=3$2%""39*K3X')$363"#2*I-,,

P'&;3#*=$3:/$/#)%"*I-,,

='##)";*#53*=9/"*4%;3#53$*I-,,

./"/;)";*#53*=$%03(# +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*I-,7=3$>%$6/"(3*.%")#%$)";*I-,7

4/2Q*=$%;$322*I-,7

C(53&'93*C#/#'2*I-,7

P'&;3#*C#/#'2*I-,7

K3:%$#)";*I-,F

=$%E936*K32%9'#)%"*I-,F

4.#+);.&*4.-)5"?*2.-#)"5?*+"&*4.-)5"*>+"+5.9."#P9%(Q**432#)";*J-,

432#*=$/(#)(32*J-7

453*CD2#36*432#*J-7

0+ !"!#$%&'#()*+,-#().+*/-

!"!#$%&'#()*+,-#().+*/- 010

!"#$%&'(#)%"*+"&*,%'$-.*/0.$0).1Introduction• Major themes:

– Electrical and computer engineering design

– Professional development

– Preparing for ECE 4899

• Team presentations

• Instructor policies

• Course syllabus

• Engineering design introduction

,2+3#.$

4

!"#$%&'()(*(+,%'-./0%1-,(#,.(!-/'2&(34&'41&5

)67 8!8(9:;

Course Syllabus

ECE 4890 Senior Seminar 1–3

Course SyllabusECE 4890

Senior SeminarSpring Semester 2013

Dr. Mark Wickert !"#$%& EB-292 '()*%& 255-3500 mwickert@uccs.edu +,-& 255-3589 http://www.eas.uccs.edu/wickert/ece4890/

Friday 9:15–10:00 AM, others by appointment.

J. Eric Salt and Robert Rothery, !"#$%&'()*'+,"-.*$-/,'/&0'1)234."*'+&%$&""*#, John Wiley, New York, 2002. ISBN 0-471-39146-8.

1.) Topic A, B, or C, learning presentation 20%.2.) Topics A, B, and C learning notes 20%.3.) In-class attendance/performance/attitude 10%.4.) Team design requirements document 25%.5.) Pre-proposal oral presentation 25%.

.*/012$0)1&

!"#$%341/&

5%6271%839%-0:1,87*;&

9)/!"# $%&'()#*+)'+,)-#./0#1/2'%0&32,%/ 1.1–1.3 1.04"# 5'%6)32#7)8&)(2#9%'#5'%:%(.;(# Web Doc 1.0?"# @A)#B)(,C/#5'%3)(( 2.1–2.5 1.0D"# 7)8&,')E)/2(#F/.;G(,( 3.1–3.5 2.0H"# IG(2)E#B)(,C/ 4.1–4.7 1.5J"# K./.C,/C#2A)#B)(,C/#5'%3)(( 5.1–5.7 2.5L"# B)2.,;)0#B)(,C/M#@)(2,/CM#./0#B)(,C/#K./.C)E)/2 6.1–6.4 1.0N"# $.()#I2&0GO#5*"#"&./.$)&'(*)2'/'6"/#)&"0'+,"-.*$-/,'+&%$7&""*P#E./0.2%'G#.22)/0./3)

Handout A.1–A.6

1.0

Q"# IA%'2#*'.;#5')()/2.2,%/#@%:,3#R'%&:#FO#S%-#2%#0)(,C/#.#(G(2)EM#3%E:%/)/2M#%'#:'%3)((#2%#E))2#0)(,')0#/))0(#-,2A,/#').;,(2,3#3%/(2'.,/2(#(&3A#.(#)3%/%E,3M#)/+,'%/E)/2.;M#(%3,.;M#:%;,2,3.;M#)2A,3.;M#A).;2A#./0#(.9)2GM#E./&9.32&'.T,;,2GM#./0#(&(2.,/.T,;,2G"

Library and internet re-

search

Student presen-tations spread throughout the

semester

!U"#IA%'2#*'.;#5')()/2.2,%/#@%:,3#R'%&:#VO#B,(3&((#-A.2#,2#E)./(#2%#A.+)#:'%9)((,%/.;#./0#)2A,3.;#')(:%/(,T,;,2G"

Library and internet re-

search

Student presen-tation spread

throughout the semester

!!"#IA%'2#*'.;#5')()/2.2,%/#@%:,3#R'%&:#$O#B,(3&((#2A)#,E:.32#%9#)/C,/))',/C#(%;&2,%/(#,/#.#C;%T.;M#)3%/%E,3M#)/+,'%/E)/W2.;M#./0#(%3,)2.;#3%/2)X2"

Library and internet re-

search

Student presen-tations spread throughout the

semester!4"#5')W:'%:%(.;#@).E#5')()/2.2,%/( 1.0

Chapter 1 • Introduction and Course Overview

1–4 ECE 4890 Senior Seminar

Syllabus (cont)• ECE 4899 proposal presentations Friday February 1, 8:00 – 11:00 AM, EN

101. ECE 4890 students must attend.• ECE 4890 case study presentation by an industry engineer, Friday TBD (as

early as February 15), 8:00 – 9:15 AM, EN 101. ECE 4890 students must attend. This date will be announced well in advance during a Friday class meeting, and it will also be posted on the course Web site.

• ECE 4890 ABET Topic A, B, & C presentations. ECE 4890 students must attend to either make their presentation and also to take notes on the other team presentations. There will likely be 3 total presentations spread over at most two weeks. Approximate dates are February 22 and/or March 1.

• ECE 4899 design review presentations Friday March 15, 8:00 – 11:00 AM, EN 101. ECE 4890 students must attend.

• Research librarian visit, TBD, to learn about search engines and other re-search related topics. Friday March 22.

• ECE 4890 design requirements documents due Friday April 12, for review by ECE faculty and project sponsors.

• ECE 4890 Pre-proposal presentations Friday May 3, 8:00 – 10:30 AM, EN 101. ECE 4890 students must participate.

• ECE 4899 final project presentations and demonstrations Friday May 10, 8:00 AM – 12:30 PM, EN 101. ECE 4890 students must attend. Note that this is the Friday before finals. Lunch is included.

• ECE 4890 Design Requirements Document Final Draft (paper copy and PDF via E-mail) due Wednesday May 15, 12:00 PM.

Ralph M. Ford and Chris Coulston, !"#$%&'()*'+,"-.*$-/,'/&0'1)234."*'+&%$5&""*#, McGraw Hill, New York, 2008. ISBN 978-0-07-338035-3.

!"!#!$%&'!$%%#()*+,-./-#0.-12

34-5#!"!#01267/#819-

!"#$%'()*#(#+,-(.,/,0$# "%1#2',3'#$%(1*#1*4&*-0,56#(5#(33%77%+(0,%58#$%(1*#9:;?@9ABCFCBL99OB=;CB:BCM?:BCM9BN>FCBL99OB

!"#$%&'$(%)*(+,',-#

./.)0123)4-",(%)4-5,"6% 789

Instructor Policies• In-class participation is a very important part of this course,

and is in fact required most of the time

• If business travel or similar activities prevent you fromattending class and participating in team presentations, class-room discussions, please inform me beforehand

• Grading is done on a straight 90, 80, 70,... scale with curvingbelow these thresholds if needed

!"#$%&'()(*(+,%'-./0%1-,(#,.(!-/'2&(34&'41&5

)67 8!8(9:;

!"#$%&'#$&($)"#$*#+,-.$/.-,.##0

/1/$2345$6#.,&0$6#7,.80 9:;

The Role of the Design Engineer• In general terms, there are three stakeholders in any engineer-

ing design problem

• The customer is also referred to as the client or end-user

• In a larger company the customer is represented by the mar-keting department

• The engineer is a member of research and development(R&D)

• The manufacturing department may in fact be a separatecompany, that in this time of outsourcing and globalization,is in a different country

Engineer

Customer Manufacturer

!"#$%&'()(*(+,%'-./0%1-,(#,.(!-/'2&(34&'41&5

)67 8!8(97:;(

!"!#$%&'#()*+,-#().+*/- 123

'(%)*%&+,#)-."/%&&

Introduction• Engineering and problem solving go together

• Scientific and mathematical knowledge are combined to formthe solution

General Engineering Process

!(01$%.

2

"4/56)-#1#7#84)#9):+;*#

>55?@+*;#64)#A)*)-/?#!*;+*))-+*;#

"4/56)-#1#7#84)#9):+;*#

!0/?I/6+,*#,J#>?6)-*/6+0)#(,?I6+,*:

!"!#$%&'#()*+,-#().+*/- 12K

– The lower cost solution is not hands-free, so the engineermust consult with marketing (customer) to see if this isacceptable

– What do you think?

Evaluation of Alternative Solutions• In practice, truly optimal solutions are not possible, so we

must choose from the best among the available alternatives

• Cost and performance are the main factors in an engineeringsolution

• Reliability and maintainability are also very important

– Maintainability has hidden costs as highly skilled individu-als my be needed to fix problems

– Increasing reliability would reduce maintenance costs, butmay drive up manufacturing cost too much

• The various criteria overlap, so sorting all of this out becomescomplicated

• A design exceeding requirements is not always better, as costobjectives may then be exceeded

– As a student the temptation is exceed the performancerequirements

– A lower performance design may be more reliable and eas-ier to maintain

• When deadlocked over two near equal choices, just pick!

"4/56)-#1#7#84)#9):+;*#

9):+;*#M)64,G,?,;+):

!"!#$%&'#()*+,-#().+*/- 12N

• Some solutions will be discarded early on, without the timeand expense of detailed design and implementation

• Just a small number of solutions goes through detaileddesign, implementation, and evaluation

Methodology Pros and Cons

• Methodology B should result in better performance, reliabil-ity, and maintainability since more effort was put into obtain-ing the go-forward solutions (say two)

• Methodology A should be cheaper to manufacture since thelack of a block-level design likely means that circuit func-tions are shared and the parts count is minimal

• Methodology A is better for the design of high-volume con-sumer products

• Methodology B on the other hand, is better for low-volumeindustrial products, where high engineering costs are accept-able because reliability, maintainability, and performance arevery important

Methodology for Student Engineers/Student Design Projects

• The text has an additional design methodology it recom-mends for a ECE 4890/4899 type course sequence

• The goal is to produce a high quality design with limitedresources (sound familiar? I frequently hear this around thecampus)

"4/56)-#1#7#84)#9):+;*#

>#M)64,G,?,;@#J,-#E+;4#OI/?+6@

!"!#$%&'#()*+,-#().+*/- 12&

• The drawback of the above is that it does not allow mistakesto be corrected as they propagate from one stage to the next

• To fix this consider the more realistic approach shown below

– When errors are uncovered you can jump back one stage torework and solve the issue(s)

– Jumping back two stages is also possible, but it will bemore costly

• The next two steps, requirements analysis and system design,Chapters 3 and 4 respectively, are the most important

Customer Needing Solution to a Problem

Requirements Analysis

System Design

Detail Block Level Design and Test

System Integration and Test

Properly Functioning System

C'9D)"5*E+(F*/".%$*>%$.*=#+5.-*)-6%--)G;.*13."*+"H$$%$*)-*4)-(%0.$.&

"4/56)-#1#7#84)#9):+;*#

!"!#$%&'#()*+,-#().+*/- H23

3%45+.%6%#$&)7#089&+&• The design methodology of Chapter 2 lists requirements

analysis as the first step

• We will find in this chapter that producing a requirementsdocument, along with performing a requirements analysis,forms a contract between you and the customer

– “What exactly is the design to accomplish”

– How will everyone with a stake in the design know whenits done?”

RequirementsAnalysis

System Design

Detailed Design

Implementationand

Verification

RequirementsSpecification

!(01$%.

:

"4/56)-#H####P)QI+-).)*6:#>*/?@:+:

H21 !"!#$%&'#()*+,-#().+*/-

The Importance of Requirements• Describes tests that will be performed to verify the design

• Serves as a check point for “go, no–go” decisions

• Acts as a filter to weed out designs that are

– Overly ambitious

– Have conflicting objectives

– Address intractable problems

• Not all projects are successful

– The text authors claim that only 1 in 10 commercial designprojects result in a viable product

• Costs mount exponentially as a design proceeds, so go/no–goon a project is an important decision

345.)67)512*

7).819):7)512*

;6

9)0)?,5+*;#64)#P)QI+-).)*6:#(5)=+J+=/6+,*

!"!#$%&'#()*+,-#().+*/- H2H

• Good engineering judgment is required at this phase of adesign project, so experienced engineers are vital here

– time, money, & expertise

Developing the Requirements Specification• Focus on the customer/marketing department who needs a

solution to a problem

Two Scenarios

• The informed customer

– Problem area is well understood

• The frontier customer

– Problem lies in unexplored territory

Informed Customer Frontier Customer

Customer’s knowledge of the problem

High— Customer knows and understand what the design should accomplish

Low—No appropri-ate experience or examples to draw upon

Availability of information

Readily available from:• customer• equip. vendors• competitors• similar designs• books, journals

Limited availability—No existing equip-ment on the market or no similar designs have been done to offer experience

"4/56)-#H####P)QI+-).)*6:#>*/?@:+:

H2$ !"!#$%&'#()*+,-#().+*/-

Example: Noise judgement curves used by AT&T

Ease of doing requirements specification

Relatively easy— The task is to organize the available information

Relatively difficult—Also can be expen-sive. May require basic research and specialized skills

Probability of proceeding to next stage in design process

Relatively high—More up-front knowl-edge minimizes the risk that the design is overly ambitious

Relatively low—Unforeseen issues are likely to arise that may reveal the prob-lem is intractable or too costly to solve

Informed Customer Frontier Customer

1009080706050403020100

ExcellentGood

orbetter

Fairor

better

Pooror

better

(29.5;6.2)

(39.0;6.0)

(48.0;6.0)

(55.5;4.2)

15 20 25 30 35 40 45 50 55 60 65Noise Level at Line Terminals of Station Set in dBrnc

Notes:2. Received volume constant, -28 vu.1. Values in parentheses indicate average and standard deviation.

Perc

enta

ge o

f Obs

erve

rs A

ssig

ning

Indi

cate

d R

espo

nse

9)0)?,5+*;#64)#P)QI+-).)*6:#(5)=+J+=/6+,*

!"!#$%&'#()*+,-#().+*/- H2K

A Two-Stage Approach to Developing the Requirements Specification

• Developing the requirements specification requires differentthinking than used in engineering courses

• The following figure explains the approach:

• Assess needs and organize into a problem statement

– The language of the customer should be used, likely non-technical and nonquantifiable

• Second, turn the problem statement into a technical specifica-tion

– At the same time establish criteria for judging the accept-ability of the design

– Note that there is a need for iteration (the feedback path)

– The customers true needs may be called into question, andsubsequently changes may be made, etc.

– The engineer must be free to make decisions and formagreements with the customer

• The final output is the requirements specification document

• This document is a concise statement of what the design willaccomplish, and the criteria used to judge the final outcome

CustomerNeeding a Solution

to a ProblemAssessNeeds

Statementof Problem

RequirementsSpecification

SpecifyDesign

Requirements

"4/56)-#H####P)QI+-).)*6:#>*/?@:+:

H2L !"!#$%&'#()*+,-#().+*/-

• The document also answers the two earlier questions:

– What exactly is the design team to do?

– How will everyone know when the design is done?

• The document ultimately must receive approval of both thecustomer and the designer

Real-World Considerations

• A real-world design rarely starts with a clean slate

• There will be both constraining factors and enabling factors:

Needs Assessment–Stating the ProblemNontechnical: Use the language of the customer and avoid theengineer’s jargon and other technical terminology

Nonquantifiable: Avoid the use of numerical terms at this point

CB5.+6)/F5G)):5

&55)55G)):5

HB.51:)I;*J(+B5)KL8?.B/1*2S/+?)55)5 3.8.)6)*."+>

.()"S/+T9)6

,%"-#$+)")"5*I+(#%$- H"+G;)"5*I+(#%$-

R))G:#>::)::.)*62(6/6+*;#64)#

"4/56)-#H####P)QI+-).)*6:#>*/?@:+:

H2% !"!#$%&'#()*+,-#().+*/-

Differentiate Needs and Wants

• Determining needs is not always easy

• Wants may be confused for real needs

– Wants generally exceeds the true needs

• If only wants were addressed, some of the true needs wouldbe missed (area A), and unneeded features would be imple-mented (area C)

• The customer’s wants must be translated into a problem state-ment reflecting the true needs

– Note, the problem statement does not exactly match thetrue needs, but is close

TrueNeeds WantsA B C

TrueNeeds Wants

Needs as Reflectedin Problem Statement

R))G:#>::)::.)*62(6/6+*;#64)#

"4/56)-#H####P)QI+-).)*6:#>*/?@:+:

H23' !"!#$%&'#()*+,-#().+*/-

• The designer and customer need to jointly develop this dia-gram

– This will insure that unforeseen needs will surface

• The input/output diagram does not however indicate anythingabout reliability, size, and weight

• The diagram may be overkill for simple functionality designs

Preview the User Interface

• The requirements specification should include a definition ofthe user interface

– This applies to both hardware and software designs

– There may be more than one interface in some design, e.g.,a remote interface via ethernet, etc.

Survey Design Attributes

• Functional

• Nonfunctional

Example: Cell Phone

• Functional

– Standard functions

– Advanced functions

• Nonfunctional

– User interface

R))G:#>::)::.)*62(6/6+*;#64)#

"4/56)-#H####P)QI+-).)*6:#>*/?@:+:

H231 !"!#$%&'#()*+,-#().+*/-

Example: Cell Phone Revisited (conflicting design needs)

• Construct a correlation matrix to rate the overlapping designneeds

SmallSize

HighQualityLook

PowerRequirements

High-TechDisplay and

Advanced UserFeatures ,%"J;)(#)"5*4.-)5"

K..&-

++ ++ -

+++

--

++ Highly correlated positive+ Moderatley correlated positive- Moderately correlated negative-- Highly correlated negative

Display/Appearance

Display/Appearance

BatteryCapacity

BatteryCapacity

Range/Performance

Range/Performance

Size

Size

"4/56)-#H####P)QI+-).)*6:#>*/?@:+:

H23$ !"!#$%&'#()*+,-#().+*/-

• A poor problem statement will become obvious, and mayneed to be reworked with the customer to remove inconsis-tencies

• The translation from problem statement to specificationsrequires the experience of the design engineer

• Outside help will likely be needed to assist with the transla-tion:

(1) Search out expert sources — ?

(2) Analyze similar design — ?

(3) Conduct tests or experiments — ?

Specification of Interface Points

• The user interface must be completely specified

– Conceptual drawing of the front panel; switches, key pads,displays, etc.

– Computer screens; GUI conceptual layout

– Electrical and mechanical interfaces such as connectors,communications standards, etc.

"4/56)-#H####P)QI+-).)*6:#>*/?@:+:

H23L !"!#$%&'#()*+,-#().+*/-

• Stringent or conservative specifications can drive cost upquickly when the cost reliability threshold is reached

– The customer needs to be made aware of this type of trade-off

Verification

• The system or acceptance test verifies whether the design ful-fills the customer needs

• At the final stage of the design process, the system is subjectto a final acceptance test (FAT)

• A preliminary test plan should be delivered along with therequirements specification

• Verification Rule #1 — “If a design requirement cannot beverified, it should not be specified”

– If need be restate the specification into a form that can beverified

Reliability

Cost

"4/56)-#H####P)QI+-).)*6:#>*/?@:+:

H23% !"!#$%&'#()*+,-#().+*/-

Closing Remarks• The requirements specification will be useful to the end of

the project

– It is the agreement between the engineer and the customeras to what is to be done

– It is a guide to remind the engineer as to what is to beaccomplished as they work on the project

– It is used to judge the final outcome

– It is an historical record; what was the thought process asthis particular design unfolded

– A document to help the manufacturers, operators, main-tainers, and future designers (re-designers) in their work

!"!#$%&'#()*+,-#().+*/- $23

;9&$%6)*%&+,#)

• “How will the problem be solved?”

• Also known as systems engineering, this stage involves:

– conceptualizing, analyzing, refining, and

– selecting the ideas giving the best solution

• The output is a document that:

– Describes the design at a functional level

– Describes component parts that form the design

– Shows through analysis how the design meets the intendedobjective

RequirementsAnalysis

System Design

Detailed Design

Implementationand

Verification

RequirementsSpecification

!(01$%.

"4/56)-#$###(@:6).#9):+;*

$21 !"!#$%&'#()*+,-#().+*/-

The Importance of System Design• Innovation and novelty occurs here (patentable?)

• Create the potential for outstanding performance

• Proficiency at systems-level design is the mark of a seniorengineer

• Junior level engineers typically step in after the system engi-neering is complete

– Junior engineers need to look for opportunities to gainexperience with this aspect

– Start now in senior design!

• Reasons for having a solid system-level design

– Decide if the problem is tractable

– What are the performance limits of a design and are theselimits acceptable

– Get good estimates on cost before spending too much timeon the actual design (i) cost of finishing the design, (ii)cost of manufacturing the design

– Reduce the risk of the design not functioning properly

– Increase the product reliability

– Reduce the overall cost of product development

– Provide a framework to organize and coordinate the engi-neers to work on the design

(@:6).#C?,=D#9+/;-/.:

!"!#$%&'#()*+,-#().+*/- $2H

System Block Diagrams• Dissect a complex problem into manageable smaller prob-

lems

– Subdivide until the problem size is small enough to con-ceive a hardware/software solution

• In a design context, system means a group of interconnectedelements that work together to form a function

• Each element may also be viewed as a subsystem

– At some point the subdividing stops and we are left with acollection interconnected parts, e.g., resistors, capacitors,and diodes

• A system block diagram displays how the group of subsys-tems is interconnected to form a system

– Each block performs a well defined function

– The functions are usually drawn as rectangular blocks

"4/56)-#$###(@:6).#9):+;*

$2$ !"!#$%&'#()*+,-#().+*/-

Example: A 12v Battery Charger

• Block names should be meaningful

• The functional elements here may be helpful in costing thedesign

• The design is composed of five blocks that can be viewed asfive smaller problems

– A sketch of the front panel may also be created at thispoint to better visualize how the ammeter and power-onlight will be oriented to the user

• The above block diagram is likely not the first version

– The first white-board sketch may be rather crude

– As the design concept is refined, the block diagram isfleshed out with more detail and possibly block subdivid-ing

• The design process and refinements to the block diagram gohand-in-hand

Transformer AmmeterFull-waveRectifier

CurrentLimiter

Power-OnLight

18v peak

ground

groundneutralhot

+16v+14

+14a

(red)

ground

(black)

84)#(@:6).#9):+;*#

"4/56)-#$###(@:6).#9):+;*

$2L !"!#$%&'#()*+,-#().+*/-

• It will also describe how the blocks work together, and satisfythe requirements specification

• Big questions are is the design required?

– A commercial-of-the-shelf solution (COTS) may alreadyexist

– Is the COTS product good enough to meet all require-ments, even in the future when the product may need tosatisfy additional requirements?

– Perform a Web search and/or talk with those knowledge-able of the product area

• Leading up to the system specification requires the engineerto first conceptualize a solution, synthesis it, analyze it to seeif requirements can be met, and as needed iterate the synthe-sis/analysis phase multiple times

Conceptualization: A Hazy Perception of the Solution

• A primitive solution lacking a detailed definite form

• Requires thinking and reasoning together with past experi-ence and scientific knowledge

• Creative thinking skills needed, which comes from experi-ence and practice

– Nonlinear thinking skills generally not encountered in pastengineering course work

84)#(@:6).#9):+;*#

"4/56)-#$###(@:6).#9):+;*

$2% !"!#$%&'#()*+,-#().+*/-

• Failure to identify via analysis and simulation that a design islacking, must be avoided

• Preliminary design reviews (PDRs) and technical interchangemeetings (TIMs) will give others the opportunity to see prob-lems you may not see, and force a synthesis/analysis iteration

Refinement: Modify the Concept Based on Analysis Results

• Refinement is inevitable

• Minor modifications may be all that is needed

• A totally new structure may be needed if the original designis found to be at its performance limits

• Economics will also factor into the refinement

– The easiest refinement approach may be too expensive ortoo risky

Documentation: Describes Block Function and Interconnection

• Provide details on how each function is to be implemented

• Describe interfaces to other blocks

The Synthesis/Analysis Cycle

• Not all concepts can be synthesized

• It might be that after trying a few cycles of synthesis/analysisa concept is discarded

• The engineer must start over, and again work to overcomedeficiencies of earlier concepts

C?,=DT9+/;-/.#C/:+=:

!"!#$%&'#()*+,-#().+*/- $2&

• For critical designs, more than one engineer may be assignedto conceptualize, synthesize, and analyze

Block-Diagram Basics

• The fruit of the systems-engineering design phase

• Specify blocks so that the detailed design of the block can beaccomplished by a single engineer

• Suggestions for senior design

– Each block should be implemented in a single technology,e.g., analog RF, analog baseband, digital

– Common functions grouped into a single block

– Create blocks to simplify the interfaces between them

– Avoid feedback loops; try to keep feedback inside a givenblock

structures

perfo

rman

ce performancethresholdx

+++ **

x

revisions

x*

of revisionssecond set of revisionsfirst set

concept 2concept 1

reference 1 reference 2

"4/56)-#$###(@:6).#9):+;*

$23' !"!#$%&'#()*+,-#().+*/-

– Specify interfaces using standards when possible (RF, ana-log, logic levels, etc.)

– Timing diagrams for complex interfaces

Documentation• The documentation will be used by everyone who has a stake

in the project

– Used to complete the detailed design and implementationof the blocks in the block diagram

– Contains the details used in the system-level design so thatfuture modifications resulting from bugs/errors can bedealt with efficiently

– Used as a reference design for future/next generation prod-ucts

– Used by test engineers to design test fixtures and test pro-cedures

– Used by marketing to develop data sheets, manuals, andother literature for advertising and technical support

System Specification Organization

• The concept

• The block diagram

• Functional description of the blocks

• Description of the system

9,=I.)*6/6+,*

!"!#$%&'#()*+,-#().+*/- $233

• System analysis

Example: 12v Battery Charger Revisited

Sec. Table of Contents Entry

1. The concept

2. Inputs/outputs and system block diagram

3. Specification of the blocks

3.1 Transformer

3.2 Full wave rectifier

3.3 Current limiter

3.4 Power-on light

3.5 Ammeter

4. System description

5. System analysis

"4/56)-#$###(@:6).#9):+;*

$231 !"!#$%&'#()*+,-#().+*/-

Detailed Example: Power Line Flicker Meter

Concept

Preliminary Block Diagram

computer

v(t)

sampler

converter

A/D

personal

between pm

voltagedividerby 75

aliasingfilteranti

common

chassis

hot

ground

neutral

no parity19.2 kbpsRS 232

of the PCserial portto the

8 bitA/D

converter

oscillator

2.5

sum

A/D input range is 0 to 5 volts

200 Hzfor samplingsquare clock

v(t)

9)6/+?)G#!F/.5?)B#

"4/56)-#$###(@:6).#9):+;*

$23$ !"!#$%&'#()*+,-#().+*/-

!"!#$%&'#()*+,-#().+*/- 012

!"#"$%#$&'()&*)+%$#&,-./)++&• Relevant high level management questions include:

– “How much is the design going to cost?”

– “When can you deliver?”

• Secondary concerns include:

– “How many people do you need?”

– “What skills must they possess?”

– “What load will you place on the lab and the machineshop?”

– “Will you be using any special (scarce) test equipment?”

• The goal of project management is to complete on time andon budget

Text Project Definition: A quantifiable piece of work withdefined start, end, and with specific deliverables.

Other project attributes:

• The output is low volume, a unique product/service

• There are measurable objectives

• It uses a limited set of resources (people, materials, equip-ment)

• The work is often complex, uncertain, and/or urgent

0("1')-

2

!"#$%&'()(*(+#,#-.,-(%"&(/&0.-,(1'23&00

)45 6!6(789:(;&,.2'(;&

!"#$%&'(#)*$%+,-

./.$0123$4#-5'&$4#65-,& 789

Elements of Project Management

• Meeting budget and meeting schedule

• Three main elements are

– Planning: A project plan defines the work to be donealong with a schedule, and a budget

– Monitoring: Compare actual progress with the plan andmake adjustments as needed

– Control: Make choices about how to optimize project per-formance; reallocate resources to make sure tasks com-plete on time and integrate smoothly

• There are many management theories

• Management theory is beyond the scope of this course, but itis safe to say that over an engineer’s career, they will experi-ence a variety approaches, some of which they may find moredifficult to cope with than others

The Project Plan• A concise statement as to how a project is to be conducted

• The project plan can take many forms, largely dependentupon the complexity and size/scope of the work

• All plans contain

– Definition of the Work: A breakdown of the various tasksneeded to complete the project

!"#$%&'()(*(+#,#-.,-(%"&(/&0.-,(1'23&00

)45 6!6(5789(:&,.2'(:&;.,#'

– Schedule: Dates/times for completing tasks and subtasks,demarcated by milestones

– Resource Requirements: Estimate each engineer’s time,materials, equipment, and other support services

– Cost Estimate (project budget): An estimate of all costsassociated with the project

• The planning process parallels the system design stage

DesignManagement

DevelopSchedule

EstimateResources

ProjectPlan

DesignProcess

PlanningProcess

Costs

DetailedDesign

Estimate

SystemDesign

PreliminaryPlan

DefineWork

!"#$%$%&'()"'*+,-

./.'0123'4"%$+,'4"5$%6, 787

Defining the Work•

• The text considers the project planning associated with aRPM measurement device (RMD)

!"#$%&'(%#)*+ ,-./0'()1*21& 31#0#

PERIOD OF

COUNTER

PULSESHAPER

BY TENDIVIDE

LOOK UP TABLE

DISPLAY

RPS10

RPS10

CLOCK5 kHz

Spark Plug Wire

5 V DC (to all circuits above)120 V AC POWERSUPPLY

10

RPM14

IDLE RANGEINDICATORFULL THROTTLERANGE INDICATOR

CYCLESSWITCH

Clamp

SPARK EVERYCYCLE/notEVERY TWO

spark plug signal

SPARK PULSES

!"#$%&'$()$*)#+$(,$-"#$./0,1230#4$4#5/(4$(,+*)-46

!"#$%&'()(*(+#,#-.,-(%"&(/&0.-,(1'23&00

)45 6!6(789:(;&,.2'(;&

!"#$%&'()*

+,+-./01-!$)(23-!$4()53 678

• Two categories are network diagrams and simple bar charts

• For the capstone design the bar chart is adequate

Network Diagrams

• For future reference you may encounter network diagramsknows as precedence diagrams

– Critical path method (CPM)

– Program evaluation and review technique (PERT)

• Graphically illustrate interdependence and precedenceamong tasks

• Consider the activity on arrow (AOA) method

– The completion time is in the lower half of each node

Start

Test (1)7

Finalize(1.5)Design (3)

System

Packaging (3)

Project Management (11)

3

Main Board (4)

Power Supply (1)9.5

(1.5)Prototype

0 8 11

EndInt. &

!"#$%&'()(*(+#,#-.,-(%"&(/&0.-,(1'23&00

)45 6!6(7589(:&,.2'(:&;.,#'

• A more detailed variation is the activity-on-node (AON)method

• Key aspects of all network diagrams is the ability to illustrate

– Precedence

– Critical paths

– Slack time

Reviewing the Work Description

• Once a schedule is developed a means to improve the sched-ule might be revealed

– Add another engineer

– Requirements changes

3.0

3.0 4

1.0PWR SUPPLY

3

MAIN BOARD2.0 4.0

0 73

INT & TEST5.0 1.0

7 0 8FINALIZE6.0 1.5

8 0 9.5

PACKAGING3 1.0 6

3.04.0

SlackTime

StartWeek

1.0

0SYS DESIGN

30

3.0

1100

11.08.0

7.0 1.5

9.5 0 11

PROJ MGMT

PROTOTYPE

START END

Task No.Elapse Time

End Week

Critical Path

!"#$%&'()*

+,+-./01-!$)(23-!$4()53 670

Bar (Gantt) Charts

• The schedule tool of choice in the 4890/4899 sequence is theGantt chart or time-line diagram

• Color or line type coding and a legend can be used to indicateindividual team member responsibility

• The text contends that Gantt charts are usually developedfrom network diagrams

• Gantt charts are particularly useful when making customerpresentations

– Consider the network chart as the manager’s personal tool,used to develop the Gantt chart

START

TASKS APRIL MAY JUNE01 08 15 22 29 06 13 20 27 03 10 17

1.0

6.07.0

8.0

FINALIZE DESIGNCONSTRUCTPROTOTYPESPROJECTMANAGEMENT

MAIN BOARD

POWER SUPPLY3.0

2.0DESIGN

DESIGNPACKAGING DESIGN4.0INTEGRATE & TEST5.0

FINALIZE

MAY 20APRIL 15MAR 25 JUNE 10

ENDSYST DESIGN

SYSTEM DESIGN

JUNE 1

SIGNOFFDESIGNCOMPLETE

ACCEPTANCETEST

MILESTONES

!"#$%&'()(*(+#,#-.,-(%"&(/&0.-,(1'23&00

)456 7!7(89:6(;&,.2'(;&

!"#$$%$&'()*+,-.)*'#$/'0*1%2#1%$&'3+*1*

030'4567'8)$%+-'8)2%$#- 9:;;

Planning Resources and Estimating Costs• Resources and estimating costs are closely linked, so they

often occur together

Costing Practices

• Personnel

• Lab, shop, and other internal facilities

• Outside services and facilities

• Supplies and materials

Estimating Personnel Requirements

• The largest category

• Availability of personnel with the right skills will have a bigimpact on the schedule

Budget Preparation

• Organize into a table broken down into categories thatinclude personnel, services, and expenses

Putting the Plan Together

• The project plan document

!"#$%&'()(*(+#,#-.,-(%"&(/&0.-,(1'23&00

)456 7!7(89:;(

!"#"$%#$&'()&*+,-).'

/0/&1234&5)#%,+&5)6%#"+ 789:

Reporting

• Project manager submits a (monthly) status report

– Summary of work completed

– Problem areas

– Plans for the next period

– Schedule and budget (updates)

Problem Resolution

• Projects can/will encounter:

– Taking longer than expected to meet objectives

– Taking more resources (costing more) than expected

– It is technically infeasible to meet some objectives

• Solution approaches

– Accept a delay but stay within budget

– Add resources and increase the project cost

– Change the deliverables. Perhaps adjust specifications oreliminate deliverables; (descoping) to maintain schedule

– Reorganize the project to utilize resources more effectively

• The last two approaches require an amendment to the state-ment of work and will require the customer to sign-off

!"#$%&'()(*(+#,#-.,-(%"&(/&0.-,(1'23&00

)456 7!7(689:(;&,.2'(;&

!"!#$%&'#()*+,-#().+*/- L23

*%$0+8%=)*%&+,#>)'%&$+#,>)0#=)*%&+,#)?0#0,%6%#$)

Block Design

Design Management

Communication

Documentation Control

Design Reviews

Principles of Testing

Stages of Testing

!(01$%.

@

"4/56)-#L#7#9)6/+?)G#9):+;*X#8):6+*;X#/*G#9):+;*#M/*/;).)*6

L21 !"!#$%&'#()*+,-#().+*/-

Test Practices

The System Test

CoverTable of ContentsIntroduction and Course OverviewIntroductionMajor Course ThemesElectrical and Computer Engineering DesignProfessional DevelopmentPreparing for ECE 4899

Course SyllabusSyllabus (cont)Instructor PoliciesThe Engineering ProfessionThe Role of the Design Engineer

The Design ProcessIntroductionGeneral Engineering ProcessApplying the General Engineering Process: Engine Block Heater Extension CordEvaluation of Alternative SolutionsDesign MethodologiesFactorsBottom LineMethodology AMethodology BMethodology Pros and ConsMethodology for Student Engineers/Student Design Projects

A Methodology for High Quality

Requirements AnalysisThe Importance of RequirementsDeveloping the Requirements SpecificationTwo ScenariosA Two-Stage Approach to Developing the Requirements SpecificationReal-World Considerations

Needs Assessment–Stating the ProblemQuestion the Customer: ExamplesDifferentiate Needs and WantsExplore Project BoundariesInput/Output AnalysisPreview the User InterfaceSurvey Design AttributesIdentify Conflicting NeedsPrepare a Draft Operations Manual

Prepare the Requirements SpecificationTranslating Needs to SpecificationsSpecification of Interface PointsExcessive RequirementsVerificationDocumenting the Requirements Specification

Closing Remarks

System DesignThe Importance of System DesignSystem Block DiagramsThe System Design ProcessThe Synthesis/Analysis Cycle

Block-Diagram BasicsDocumentationSystem Specification Organization

Detailed Example: Power Line Flicker MeterConceptPreliminary Block DiagramFinal Block Diagram

Managing the Design ProcessThe Project Management ApproachProject OrganizationElements of Project Management

The Project PlanDefining the WorkSchedulingNetwork DiagramsReviewing the Work DescriptionBar (Gantt) ChartsComments

Planning Resources and Estimating CostsCosting PracticesEstimating Personnel RequirementsBudget PreparationPutting the Plan Together

Managing the ProjectPerformance MonitoringTask ProgressSchedule StatusBudget StatusReportingProblem Resolution

Detailed Design, Testing, and Design ManagementBlock DesignDesign ManagementCommunicationDocumentation ControlDesign Reviews

Principles of TestingStages of TestingTest PracticesThe System Test