Senior Seminar ECE 4890 Lecture Notes Spring 2013 © 2006–13 Mark A. Wickert Engineer Customer Manufacturer
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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$)";*<32);"*,-7
=$%>322)%"/9*<3?39%:63"#*,-7
=$3:/$)";*>%$*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*<32);"*8";)"33$+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*,-L
23.*4.-)5"*6$%(.--!"#$%&'(#)%"*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*7-,
M3"3$/9*8";)"33$)";*=$%(322 +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*7-,
N::9D)";*#53*M3"3$/9*8";)"33$)";*=$%(322O
8";)"3*P9%(Q*R3/#3$*8S#3"2)%"*1%$& *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*7-F
8?/9'/#)%"*%>*N9#3$"/#)?3*C%9'#)%"2+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*7-I
<32);"*.3#5%&%9%;)32 +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*7-JT/(#%$2*7-J
P%##%6*U)"3*7-J
.3#5%&%9%;D*N*7-J
.3#5%&%9%;D*P*7-J
.3#5%&%9%;D*=$%2*/"&*1%"2*7-L
.3#5%&%9%;D*>%$*C#'&3"#*8";)"33$2VC#'&3"#*<32);"*=$%03(#2*7-L
N*.3#5%&%9%;D*>%$*R);5*W'/9)#D+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*7-A
7.8')$.9."#-*:"+;<-)-453*!6:%$#/"(3*%>*K3X')$363"#2+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*F-7
<3?39%:)";*#53*K3X')$363"#2*C:3()>)(/#)%"*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*F-F4Y%*C(3"/$)%2*F-F
N*4Y%ZC#/;3*N::$%/(5*#%*<3?39%:)";*#53*K3X')$363"#2*C:3()>)(/#)%"*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*<32);"*N##$)E'#32*F-,_
!&3"#)>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
<%('63"#)";*#53*K3X')$363"#2*C:3()>)(/#)%"*F-,L
19%2)";*K36/$Q2 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*F-,A
=<-#.9*4.-)5"453*!6:%$#/"(3*%>*CD2#36*<32);"+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*@-7
CD2#36*P9%(Q*<)/;$/62+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*@-F
453*CD2#36*<32);"*=$%(322 +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*@-I453*CD"#532)2VN"/9D2)2*1D(93*@-A
P9%(QZ<)/;$/6*P/2)(2 +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*@-B
<%('63"#/#)%" +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*@-,_CD2#36*C:3()>)(/#)%"*]$;/")a/#)%"*@-,_
<3#/)93&*8S/6:93O*=%Y3$*U)"3*T9)(Q3$*.3#3$ +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*@-,71%"(3:#*@-,7
=$39)6)"/$D*P9%(Q*<)/;$/6*@-,7
T)"/9*P9%(Q*<)/;$/6*@-,F
>+"+5)"5*#3.*4.-)5"*6$%(.--453*=$%03(#*./"/;363"#*N::$%/(5 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*I-7
=$%03(#*]$;/")a/#)%"*I-7
89363"#2*%>*=$%03(#*./"/;363"#*I-F
453*=$%03(#*=9/" +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*I-F
<3>)")";*#53*[%$Q +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*I-I
C(53&'9)";*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*I-J\3#Y%$Q*<)/;$/62*I-L
K3?)3Y)";*#53*[%$Q*<32($):#)%"*I-A
P/$*GM/"##H*15/$#2*I-B
1%663"#2*I-,_
=9/"")";*K32%'$(32*/"&*82#)6/#)";*1%2#2 +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*I-,,1%2#)";*=$/(#)(32*I-,,
!"!#$%&'#()*+,-#().+*/- 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*<32);"*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*J-,
<32);"*./"/;363"# *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*J-,1%66'")(/#)%"*J-,
<%('63"#/#)%"*1%"#$%9*J-,
<32);"*K3?)3Y2*J-,
=$)"():932*%>*432#)"; *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*J-,C#/;32*%>*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:;<(=&,1-'(=&>1,#'
Major Course Themes
Electrical and Computer Engineering Design
• The design process
• Requirements analysis
• System design
• Managing the design process
• Detail design, testing, and design management
• An integrated case study
Professional Development
• Beyond engineering design
• Team presentations on key ABET professional developmentcurriculum issues
– economic, environmental, social, political, ethical, healthand safety, manufacturability, and sustainability
– professional and ethical responsibility
– impact of engineering solutions in a global, economic,environmental, and societal context
Preparing for ECE 4899
• Choosing a project and project advisor(s)
• Prepare and deliver a pre-proposal presentation with yourdesign team
Course Syllabus
ECE 4890 Senior Seminar 1–3
Course SyllabusECE 4890
Senior SeminarSpring Semester 2013
Dr. Mark Wickert !"#$%& EB-292 '()*%& 255-3500 [email protected] +,-& 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)<7$/3 9%-03 =%%>/!"# $%&'()#*+)'+,)-#./0#1/2'%0&32,%/ 1.1–1.3 1.0
4"# 5'%6)32#7)8&)(2#9%'#5'%:%(.;(#<7=5(> Web Doc 1.0
?"# @A)#B)(,C/#5'%3)(( 2.1–2.5 1.0
D"# 7)8&,')E)/2(#F/.;G(,( 3.1–3.5 2.0
H"# IG(2)E#B)(,C/ 4.1–4.7 1.5
J"# K./.C,/C#2A)#B)(,C/#5'%3)(( 5.1–5.7 2.5
L"# B)2.,;)0#B)(,C/M#@)(2,/CM#./0#B)(,C/#K./.C)E)/2 6.1–6.4 1.0
N"# $.()#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:;<=>?@9ABC<B;<:C?;CBDEF?GEHECIBJ9>KE;9FBLECME:BCM9BN>FCBL99OB<PB;H?FF9F!!"#$%&#(1*#(#7,/,0(1$#-0&+*50#2,0'#0'*#Q%0*50,(/#%"#.*,56#3(//*+#0%#7,/,0(1$#-*1),3*#(5+#R%1#01(,5,56#+&1,56#0'*#3%&1-*#%"#0'*#-*7*-0*18#$%&#(1*#*53%&1(6*+#0%#3%50(30#$%&1#STTJB;<=>F9BE:FC>=;C<>B:<BH?C9>BCM?:BCM9BN>FCBL99OB<PB;H?FFBC<BAEF;=FFBCM9B;H?FFB?C"C9:A?:;9BU<HE;I!
!"#$%&'$(%)*(+,',-#
./.)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:;<(=&,1-'(=&>1,#'
The Engineering Profession• Consider first the definition of engineering as found in two
sources
• From Webster’s New World Dictionary –1.a) the science concerned with putting scientific knowledgeto practical uses, divided into different branches, as civil,electrical, mechanical, or chemical engineering.
• From the Accreditation Board for Engineers and Technolo-gists (ABET) –Engineering is the profession in which a knowledge of themathematical and natural sciences gained by study, experi-ence, and practice is applied with judgement to develop waysto utilize, economically, the materials and forces of nature forthe benefit of mankind.
• Mathematical and scientific knowledge is at the core of engi-neering
• Engineer’s solve problems, for the benefit of society, usingsynthesis of what is currently known about a problem’s solu-tion, and new ways of solving it
• Engineer’s design
!"#$%&'#$&($)"#$*#+,-.$/.-,.##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:;(<&,1-'(<&=1,#'
!"!#$%&'#()*+,-#().+*/- 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):+;*#<-,=)::
121 !"!#$%&'#()*+,-#().+*/-
• Analysis and synthesis (Oxford American dictionary):
– Analysis—!"#$%&"!' "($)%*$#%+*' +,' #-"' "&")"*#.' +/' .#/012#0/"' +,' .+)"#-%*34' #56%1$&&5' $.' $' 7$.%.' ,+/' !%.10..%+*' +/
%*#"/6/"#$#%+*8' .#$#%.#%1$&' $*$&5.%.' 9' $*' $*$&5.%.' +,' 6+60&$/
10�/"
:-"' 6/+1"..' +,' ."6$/$#%*3' .+)"#-%*3' %*#+' %#.' 1+*.#%#0"*#"&")"*#.;'<,#"*'1+*#/$.#"!'=%#-'.5*#-".%.;
– Synthesis—1+)7%*$#%+*' +/' 1+)6+.%#%+*4' %*' 6$/#%10&$/' #-"1+)7%*$#%+*'+,'%!"$.'#+',+/)'$'#-"+/5'+/'.5.#")8'#-"'.5*2
#-".%.' +,' %*#"&&"1#' $*!' ")+#%+*' %*' -%.' =+/>' 9' #-"' %!"+&+35
/"6/"."*#"!'$'.5*#-".%.'+,' 1"/#$%*' %!"$.;'<,#"*'1+*#/$.#"!
=%#-'$*$&5.%.;
• Analysis is typically performed on an existing system, whilesynthesis is usually associated with a new system
• The process of analysis/synthesis may be repeated to findmultiple solutions
– Many implementations can perhaps meet the requirements,which is the best one?
– How many solutions should be obtained?
– The cost of generating possible solutions is expensive anddrives up the non-recurring engineering (NRE) budget
– Will the next solution attempted really be significantly bet-ter?
>55?@+*;#64)#A)*)-/?#!*;+*))-+*;#<-,=)::B#!*;+*)#C?,=D#E)/6)-#!F6)*:+,*#",-G
!"!#$%&'#()*+,-#().+*/- 12H
Applying the General Engineering Process:Engine Block Heater Extension Cord• In colder climates, northern US and Canada, engine block
heaters are used to insure easy starting in the morning andwhen leaving work in the late afternoon
• Problem:
– A breaker may blow and there is no indication to theemployee that their heater is actually working
– The heater may also burn out and become an open circuit
• The solution is a smart extension cord that gives an indica-tion of the above two conditions at the cord end
• A marketing study says that this cord enhancement is worth aprice increase of about $7
• The new extension cord must sell for less than $6 above thedumb model
• A first iteration design (synthesis):
Light
Neutral WireHot wire
Threshold
emittingdiodes
settingresistor
!"#$%"&"'()*"+*"",-%"&"'()*"*+."'+/01*2
"4/56)-#1#7#84)#9):+;*#<-,=)::
12$ !"!#$%&'#()*+,-#().+*/-
– LEDs must carry too much forward current (4A) makingthe cost prohibitive
• A second iteration design (synthesis):
– Include a current transformer
• An alternative design (synthesis):
– Need to press a switch to see if heater is functioning prop-erly
• Analyze the designs and choose the best:
– LED solution $4.50, switch/build solution $4.00
Thresholdsettingresistor
Light emittingdiodes
NeutralwireHotwire
transformerCurrent
Hot wire
Normally closedmomentary
switch
Neutral wire
Light bulb
glow pointwith one ampere
!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):+;*#<-,=)::
12L !"!#$%&'#()*+,-#().+*/-
Design Methodologies
Factors
• Complexity of the design
• Size of the design team
• Experience
• Personal style and preferences
Bottom Line
• Best possible solution, within a set of constraints
• Obtained in the shortest possible time
Methodology A
• Consider one possible solution and complete a detaileddesign
• Implement it and evaluate its performance, manufacturingcost, reliability, and maintainability
• Repeat until a satisfactory solution is obtained
Methodology B
• Consider multiple solutions only to the block-level design(system design)
• The team evaluates the block-level designs using the samecriteria as A
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):+;*#<-,=)::
12% !"!#$%&'#()*+,-#().+*/-
A Methodology for High Quality• When high quality is the goal, one question might be, ... can
the problem be solved?
– The methodology must be able to ascertain this as quicklyas possible to prevent time waste; why?
– The text claims that 9 out of 10 design efforts are unsuc-cessful, meaning the one good design must cover the costsof the failures
Customer Needing Solution to a Problem
Requirements Analysis
System Design
Detail Block Level Design and Test
System Integration and Test
Properly Functioning System
Requirements Specification
System Specification
Functioning Modules
@)53*A'+;)#<*1)#3*B)9)#.&*7.-%'$(.->.#3%&%;%5<
>#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):+;*#<-,=)::
123' !"!#$%&'#()*+,-#().+*/-
!"!#$%&'#()*+,-#().+*/- 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)6)*.8.1+*8*:"=)/1>1?8.1+*
@)AB1/)6)*.5&*894515
CB6B98.1D)"7)512*"C+5.
E16)
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)KL<)/.15)
H.()/"M516198/N7)512*5
O851?@)5)8/?(
P1*8*?189Q161.8.1+*5
Q)289I@)2B98.+/4@)5./1?.1+*5
&:()/)*?)".+KL15.1*2"7)512*
8*:"R8*B>8?.B/1*2S/+?)55)5 3.8.)6)*."+>
.()"S/+T9)6
,%"-#$+)")"5*I+(#%$- H"+G;)"5*I+(#%$-
R))G:#>::)::.)*62(6/6+*;#64)#<-,S?).
!"!#$%&'#()*+,-#().+*/- H2N
Complete: Cover all aspects of the design
Specifiable: It should be possible to convert a stated need into aquantitative requirement
Question the Customer: Examples
Define the Design Problem —• What is the problem to be solved?• Why is there a problem?• What is my role in solving the problem• How will I know when I am done
Determine Budget and Schedule Constraints —• When is the solution needed?• What is the upper limit of cost to do the design?• What are your expectations of production cost in high
volumes?
Reliability and Maintenance —• What are the consequences of the system failing once
in operation?• What resources (personnel, replacement parts, budget)
are available for maintenance?
Contract —• How will it be determined when the design is complete• How will it be determined that the design is acceptable• How will I (firm) be paid• Is the work that I am to do legal (ethics)
"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)#<-,S?).
!"!#$%&'#()*+,-#().+*/- H2&
Explore Project Boundaries
• Some solutions will be out of bounds
• There may be a need to fit within existing:
– operations
– standards
– methods
– procedures
– legal boundaries
Input/Output Analysis
• View the complete design as a system having a functionalblock diagram with inputs and outputs
Example: An Agricultural Pressure SprayerInputs Outputs
SprayerController
Metric/ImperialMeasureBoom WidthCalibrationConstants
SpayerVelocity
SprayFlow Rate
AlarmPoints
SensorInputs
UserInputs
SprayerVelocity
ApplicationRate
Flow Rate
CumulativeTotals
Alarms
SystemCutoff
UserOutputs
ControlPoints
"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)#<-,S?).
!"!#$%&'#()*+,-#().+*/- H233
– Packaging
– Battery
– Production
– Reliability
– Service
Identify Conflicting Needs
• Conflicting design needs are not uncommon
– Design trade-offs will resolve these conflicts later
– For now we just want to anticipate them so the customer isaware of them
• Classic conflicts: cost, performance, and time
– The customer wants high performance, but finds the asso-ciated cost and time to deliver unacceptable
– Alert the customer if these three are out of line ASAP
• A correlation matrix can be constructed as a means to ratehow overlapping design needs correlate in a positive or nega-tive sense
• Conflicts should be discussed as the problem statement isdeveloped, but resolution should not be attempted at this time
• The customer needs to know these are issues and hopefullyrecognize that some ‘needs’ may not be necessary
"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
<-)5/-)#64)#P)QI+-).)*6:#(5)=+J+=/6+,*
!"!#$%&'#()*+,-#().+*/- H23H
Prepare a Draft Operations Manual
• When a product or system is delivered, a users manual is alsodelivered to provide usage instruction
• At this early stage, the draft manual will help focus both theengineer and customer on true design needs
• The draft manual can be as simple as an outline of the sec-tions and subsections that the manual will contain
Prepare the Requirements Specification• Now that the problem statement is complete, the require-
ments specification document should follow naturally
– Recall that the problem statement is in nonquantifiable andnontechnical terms
• The requirements specification is very technical
– It might be that some experimentation, subjective tests,and research is required
Translating Needs to Specifications
• Each design need is translated into a specification
– All design needs are covered
– They are independent of each other
– Their are no contradictions
"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.
<-)5/-)#64)#P)QI+-).)*6:#(5)=+J+=/6+,*
!"!#$%&'#()*+,-#().+*/- H23K
Excessive Requirements
• You want to meet the customer expectations, but you have towalk a fine line between being too ambitious or too lax
– An inexperienced engineer is prone to having excessivespecifications that provide needless features/functionalityor make the specifications too difficult
• Added functionality to say software, may be viewed free,when in actuality time and money are needed to implementthese features
– There is also a trickle-down effect, in that documentationincreases along with test time
Des
ign
Cos
ts
Features & Functions
"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
<-)5/-)#64)#P)QI+-).)*6:#(5)=+J+=/6+,*
!"!#$%&'#()*+,-#().+*/- H23N
Documenting the Requirements Specification
• Document the above in to a deliverable form
Example: Typical Outline for a Requirements Specification
1. Overview2. Statement of the problem3. Operational description (derived from the draft user’s manual)4. Requirements specification (see the case study in text Appen-
dix A)5. Design deliverables (all that is to be delivered to the customer)6. Preliminary system (acceptance) test plan7. Implementation considerations
– Customer training, service, and maintenance
– Manufacture8. Attachments
– Studies (e.g., lab reports or marketing studies)
– Relevant codes and standards
• In the overview state why the design is being done, and whatare the expectations
– The executive summary
• The operational description will preview the user interface(front panel, computer GUI, etc.)
"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):+;*#<-,=)::
!"!#$%&'#()*+,-#().+*/- $2K
The System Design Process• Synthesis, analysis, and iteration
• The system specification will contain a description of eachblock in the block diagram
RequirementsSpecification
SystemSpecification
Developmentof Concepts
DetailedDesign
Analysis
Synthesis
Select and Document
Iteration
Rej
ect U
nwor
kabl
e D
esig
ns
"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):+;*#<-,=)::
!"!#$%&'#()*+,-#().+*/- $2N
Synthesis: Create a Well Defined Structure or Concept
• Enough detail is needed so that analysis can be performedrelative to performance, risk, and cost
• A block diagram is required here to break the problem down(divide and conquer)
• Conflicting forces:
– Complete the design quickly
– Desire for a novel solution that offers a cost or perfor-mance advantage over the competition
• Try to adapt an existing design (reference design)
• Linear thinking offers the most predictable results, but a diffi-cult problem may not yield to this process
• When a reference design does not exist, an original concept isrequired
– Brainstorm with other team members to find a concept thatcan get you off the ground
– If you are uncertain even after a small start, perform somepreliminary analysis to gain confidence you are moving inthe right direction
Analysis: Model/Analyze/Simulate/Breadboard/
• The objective is to determine if the synthesized system meetsperformance and cost objectives
• Risk must also be assessed
"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#<,U)-#V+*)#W?+=D)-#M)6)-
!"!#$%&'#()*+,-#().+*/- $23H
Final Block Diagram
1pm0.5%16 bitA/D circuit
framing
common
chassis
hot
ground
neutraloscillator
2.5pm0.18
sum
200 Hzfor samplingsquare clock
16 bit busvoltagedivider
75pm0.5%
RS232per sample3 bytes
v(t) aliasingfilteranti
"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'(;&<.,#'
The Project Management Approach
Project Organization
• Projects are always configured with some form of top-downmanagement
• Individuals are typically assigned to more than one project
(CAD)
Electrical Mechanical Support
PrototypeShop
Main Board
Power SupplyDesign
Design
(D. Houseman)
TechnicianSupport
(F. Bond)
Purchasing
ManagerProject
Senior
PackagingDesign
(J. Duzek)
(R. Borden)
Management
& Admin.FinanceMarketing
(M. King)
Drawing Office
Manufacturing
!"#$%&'(#)*$%+,-
./.$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'(;&<.,#'
• What makes up a task?
• Several rules apply:
– (1) Consider a top-down approach starting with just a fewtasks, then break them down adding detail and complexity;bottom-up lists all small tasks to define the project, thencombine to simplify the work definition
– (2) Each block in the block diagram should initially be asingle task; if several blocks form a single module (e.g. cir-cuit board), combine the tasks into one
– (3) Tasks should be assignable to individual team members
– (4) Work that leads up to a milestone should be a task, witha new task starting after the milestone (not always)
– (5) Tasks will rely on inputs from other tasks, while a taskis in process it should be independent of additional inputs
– (6) Too many tasks increases administrative load; engi-neers like to design, not shuffle paper. Too few tasks over-simplifies, and increases the chance for errors in budget,schedule, and resources (newbie advice—a few too manyis better than too few)
Scheduling• The logical sequencing of tasks
• Project schedules can be kept in tools such as Microsoft Proj-ect, or for this course a simple bar (Gantt) chart
!"#$%&'()*
+,+-./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'(;&<.,#'
– The Gantt chart is used by the manager when making pre-sentations
Comments
• Work hard on making the schedule
– It maybe used to sell customers and company managementalike on the viability of the project
• Project team members use it to see how their work relates toothers, and better understand why they need to meet a dead-line (no vacation or leisure time until . . .)
• Common schedule problems
– Too many tasks make for a confusing schedule
– Too few tasks make the project flow difficult to understand(can you really do this!?)
– Inconsistent with some areas having a lot of detail and oth-ers too little
– Individual team member roles are not clearly identified;don’t let this happen!
!"#$$%$&'()*+,-.)*'#$/'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:;(<&,.2'(<&=.,#'
Managing the Project• The three functions of project management include
– Monitoring
– Reporting
– Problem resolution
Performance Monitoring
• Is the design going to meet the performance as stated in thesystem specification?
Task Progress
• The project manager discusses progress with each teammember, e.g., weekly status report delivered to manager anda visit to the manager’s office
• Percent of task complete; an estimate
Schedule Status
• Pull task progress info together and provide an update of theoverall schedule status
Budget Status
• Three key questions:
– Are expenditures occurring as planned
– Are expenditures occurring when planned
– Is the project cost tracking the estimate
!"#"$%#$&'()&*+,-).'
/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
Related Documents
