begin with a good plan · requirement-driven design amplifier preamplifier gain stage output driver...
TRANSCRIPT
1
1
ECE496 Design Project Preparing Your Project Proposal
Thursday, Sept. 12, 2019
Ross Gillett, Khoman Phang
All things are created twice. There’s a mental or first creation, and a physical or second creation.�
�Stephen Covey�
Begin with a good plan …
n Maps n Equipment n Study
terrain n Plan path
… to guide the rest of your journey
n Design n Implementation n Testing n Presentations n Teamwork
4
Outline
Tonight n Systems Engineering, Requirements, Proposals, Project
Planning, and Risks (Gillett) n Your Project Proposal – an evolving plan n Project Proposal Guidelines n Draft A meetings n Draft A Submission & Meeting Sign-Up n Q&A n Update from students without supervisors
Next week: n Thu., Sept. 19th submit Proposal Draft A
2
R. Gillett, P.Eng. FEC (2019) ECE496 The Design Process
September 2003
ECE496:
Systems Engineering, Requirements, Proposals,
Project Planning, and Risks
Ross Gillett, M.Eng, P.Eng, FEC 12 September 2019
R. Gillett, P.Eng. FEC (2019)
ECE496 The Design Process September 2003
Agenda
• Project Planning • System Engineering • Use of Requirements for Teamwork (an Example) • Engineering a Success: Requirement Verification • The Project Proposal • Requirement verification • Project Planning/Tracking • Risk Management • Why Projects run into trouble / Why marks are lost • Summary
R. Gillett, P.Eng. FEC (2019)
Project Planning: The Beginning
• Define what you want to achieve (Goal) • [Establish team size, time/budget constraints] • Break down the project into
– Tasks (per sub-element, per team member, …) – Milestones (grouped tasks, system elements completed)
• Assign tasks to team members (parallel tasks) • Generate a Gantt chart (schedule) showing
– Sequencing of tasks – Dependencies between tasks – Continuous activities for all team members, no ‘vacations’
R. Gillett, P.Eng. FEC (2019) ECE496 The Design Process
September 2003
System Engineering - recap
Goal(or Mission)
- Top level requirements(function andperformance)
- Major modules of system architecture defined- "2nd Tier" requirements generated
- Major modules of subsystem's system, defined within each module- "3rd Tier" requirements generated
The larger and more complex the system, the more 'levels' to define itTake-Away Message: All requirements, at any level, can be ‘traced’ to the Goal
Note: Each “jump” down is a design effort, a creative action to define the next-level building blocks that satisfy the requirements of the previous level (one of many solutions), plus analysis to generate requirements from the requirements of the previous level to assign to these new blocks
3
R. Gillett, P.Eng. FEC (2019) ECE496 The Design Process
September 2003
Project Example using Requirement-Driven Design
Goal: Use “wall-plug” electrical power to amplify the specified input signal to drive 50 Watts rms into a 8-ohm speaker
Input Signal Specification: Approx 80-150 mVrms signal, 40-10,000 Hz, 10kOhm output impedance
“Black Box” [i.e. We must ignore implementation when defining requirements]
R. Gillett, P.Eng. FEC (2019) ECE496 The Design Process September 2003
Project Example using Requirement-Driven Design
Amplifier
Preamplifier Gain StageOutput Driver
Stage andPower Supply
8-Ohm
8-Ohm
"Design" (Creativeactivity)
Initial Top Level (Goal)
Architecture After InitialDesign Effort
(next 'level' design)
< 50 Wrms
< 50 Wrms
120Vac,60Hz
80mV,80-20kHz
120Vac,60Hz
80mV,80-20kHz
R. Gillett, P.Eng. FEC (2019) ECE496 The Design Process
September 2003
Requirements coming from analysis of new architecture [Permits a team to design "in parallel“]
Pre-Amplifier Stage Requirements: - Input Z: >10kohm - Output Z: < 100 ohm - Gain: 0 to +20 V/V log control - Output DC Offset: < 1 mV - Frequency Response: -3db at 18kHz, single pole - User Tone Controls: Treble: ±10db notch at 8kHz Mid: ±10db notch at 1kHz Bass: ±10db notch at 150Hz - Power: ± 12 Vdc, < 200 mA
Gain Stage: Requirements: - Input Z: >1kohm - Output Z: < 20 ohm - Output DC voltage: < 1 mV - Gain: 15 V/V - Clipping at ± 8 Volts - Frequency Response: -3db at 20kHz - Power: ± 12 Vdc, < 500 mA
Output Driver Stage: Requirements: - Input impedance: >1kohm - Gain: 2 V/V - Output type: Class A-B with bias trim ** - Output power: 50 Watts into 8 ohm load - Power Supply: 110 Vac, 60 Hz input, ± 12 Vdc, 700 mA to other circuitry ** Not really a pure requirement, because
it dictates implementation, but oh well …
Input signal from Electric Guitar: 80 mV rms James Susan David
Project Example using Requirement-Driven Design
R. Gillett, P.Eng. FEC (2019) ECE496 The Design Process September 2003
Project Example using Requirement-Driven Design
Amplifier
Preamplifier Gain StageOutput Driver
Stage andPower Supply
8-Ohm
8-Ohm
"Design" (Creativeactivity)
Initial Top Level (Goal)
Architecture After InitialDesign Effort
(next 'level' design)
< 50 Wrms
< 50 Wrms
120Vac,60Hz
80mV,80-20kHz
120Vac,60Hz
80mV,80-20kHz
8-ohmspeaker
SignalInput
Power Input(120VAC,
60Hz)
"Design" (Creativeactivity)
4
R. Gillett, P.Eng. FEC (2019)
Engineering a Success: Requirement Verification
• So, again …. how do we ensure success/safety?
– Requirements and their Verification:
• Showing a project will be successful before it is completed – Incremental successes through subsystem verification
• Proving it is successful after completion
• All requirements must be verifiable … so you can prove that the
design works, or that it will work – Each subsystem or element can be verified separately – In advance, or (for some) at the end after integration
R. Gillett, P.Eng. FEC (2019)
The Project Proposal
• Introduces the project (Background/Motivation, Goal) • Background/Motivation (General topic, current state of the art, problem or area for
further work) • Goal (single statement if possible, best if it draws directly from the motivation)
• Defines your project technically in terms of: • Scope of work (what you are doing, and not doing) • Function and Performance • Deliverables
**Protects you from ‘scope creep’ or misinterpretations**
• Defines your project plan: • Shows how you prove that your work is ‘done’ (verification) • Defines the work Breakdown (teamwork) • Defines the schedule (sequence of events, dependencies) • Identifies risks
R. Gillett, P.Eng. FEC (2019)
The Project Proposal
• Requirements: – Define Functions and Performance
• Before anything has been designed yet
– No implementation should be stated or implied
– MUST BE VERIFIABLE • Can you prove it is done, to someone skeptical? • Verifiable is best if measurable/testable, but other methods
are acceptable (see next slide) • Never say “as much as possible”, “to the maximum extent”,
“as low as possible”, since these can never be verified
R. Gillett, P.Eng. FEC (2019) ECE496 The Design Process
September 2003
Requirement Verification
• Engineering – Not complete (or fully paid for) until verification is completed
for each requirement • Verification
– Method must be agreed with the customer up front • Common verification methods (all in a single project):
– Similarity (e.g. the identical circuit is already working well in another amplifier)
– Review of Design (e.g. no ceramic capacitors used in tone control circuitry) – Analysis (e.g. “worst case” performance, performance prediction at end-of-life)
– Test (e.g. gain can be tested in the lab using a signal generator and oscilloscope)
5
R. Gillett, P.Eng. FEC (2019) ECE496 The Design Process
September 2003
Requirement Verification
• Many contracts use a “Verification Matrix” within a formal document.
• For ECE496 use a table as shown below.
Requirement ID Requirement
1 The item shall be light blue
2The item shall have maximum dimensions of 20cm x 30cm by 100cm
2 The item shall have a mass of 15kg + 1kg3.1 The gain of the amplifier in the unit shall be greater than 50db
3.2 The item shall operate for a minimum of 1 year in daily use3.3 The item shall have the following maximum power demand:
3.3a 12 Watts average in standby mode
3.3b 23 Watts average in operational mode
3.3c 31 Watts peak in operational modeAnalysis: Calculate peak power demand for worst case component tolerances and operational use
-
Test: Measure gain in a laboratory set upSimilarity: Designs with similar parts, complexity and power have all been observed to operate for this long without failure
Test: Measure average power demand for this mode in a laboratory set upTest: Measure average power demand for this mode in a laboratory set up
Review of Design: Compare to a colour chartReview of Design: Review the bounding envelope on the mechanical drawingsTest: Weigh the final product on a calibrated scale
Requirement Verification Method
Verification Table(How you will answer the question: "Prove it!" for each requirement)
R. Gillett, P.Eng. FEC (2019)
Project Planning/Tracking
• Teamwork benefits can be seen on the schedule – Splitting the work up (Work Breakdown) for parallel
design activities – Dependencies (“what needs to happen before other
things can happen”) – Critical Path (the activities that form a sequence of
events that drive the completion date)
R. Gillett, P.Eng. FEC (2019) ECE496 The Design Process September 2003
Project Planning/Tracking
Perform Weekly Lawn MaintenanceCut Grass
Cut front lawnCut back lawnCut sides
Trim EdgesTrim property boundariesTrim around gardenTrim around trees
Trim BushesPrune side hedgesPrune back hedge
Case 1: One person does Lawn MaintenancePerform Weekly Lawn Maintenance
Cut GrassCut front lawnCut back lawnCut sides
Trim EdgesTrim property boundariesTrim around gardenTrim around trees
Trim BushesPrune side hedgesPrune back hedge
Case 2: Two people do the same, each with their own equipment
A team of two:
[By adding team members, the project progresses faster ...
No Teamwork - one person
R. Gillett, P.Eng. FEC (2019) ECE496 The Design Process September 2003
Perform Weekly Lawn MaintenanceCut Grass
Cut front lawnCut back lawnCut sides
Trim EdgesTrim property boundariesTrim around gardenTrim around trees
Trim BushesPrune side hedgesPrune back hedge
Case 3: Three people do the same but can’t ‘Trim’ until the grass is cut (alogical dependency)
The "critical path" is the job, or sequence of tasks, that takes the longest time and drives the completion date. - This limits how fast the team can complete the job, regardless how many people are added
... but not always ]
Project Planning/Tracking
6
R. Gillett, P.Eng. FEC (2019) ECE496 The Design Process
September 2003
Risk Management
• How many of you:
– Bring more than one pen/pencil to an exam? – Backup important computer files to CD/DVD? – Leave earlier for 9AM exams than for a 9AM
lectures? – Drive a car with one spare tire? Two spares? – ………………. Would sit at desk #2 →
• Then you have considered risk
• Risk can impact technical, schedule, or both
Desk #1Desk #2
R. Gillett, P.Eng. FEC (2019)
Why projects run into trouble
• Scope of Work – Too large for the available time – Too complex for the team – Insufficient understanding/management of risks
• Requirements – Not complete, or vague and leading to misinterpretation – Too many assumptions – Not verifiable
• Falling behind schedule – Not starting any work until too late in the year – Not seeing problems until too late – Not reducing scope of work when needed
i.e. All of the stuff in the project Proposal. This is why we get you to spend so much effort on it
R. Gillett, P.Eng. FEC (2019)
Why ECE496 Marks Are Lost Typically
• Not following the guideline for deliverables – Missing sections – Late submission of deliverable documents – Lack of clear writing/figures – Being “creative” with the document structure and headings
• Trying to argue why a verification failure is still successful – Be honest about your results – Remember: ‘Pass/Fail’ on a requirement does not mean ‘Pass/
Fail’ for your mark for this course.
R. Gillett, P.Eng. FEC (2019) ECE496 The Design Process
September 2003
• The proposal is not just a deliverable for now - it contains the plan for the full project.
• Requirements and their verification are key to successful projects. Maintain and update them throughout the year.
• Keep requirements and scope of work up to date – Changes to these are fine, but must be agreed with Supervisors
and discussed in the subsequent deliverable document
• Follow the guidelines for deliverables
Summary
7
Your Project Proposal – an evolving plan
25
ECP & Administrator
Administrator &
Supervisor
Project Proposal Guidelines (2 files)
Document Guidelines – general guidelines that apply to all written deliverables Project Proposal -- Guidelines specific to the project proposal (all versions)
26
Contains examples & suggestions – read through carefully
Draft A Meetings (Sept 23 – Oct 1)
27
n Writing Instructors will provide feedback to help you with the revision and editing process.
n Writing Instructors will ask questions to help you clarify your ideas.
Draft A Submission & Meeting Sign-Up
28
• Submit Thursday, September 19, 9am-3pm in SFB670 • Sign up for a Writing Instructor meeting on the signup sheet posted in SF B670. (Be sure whole group can attend.) • Staple a Draft A Feedback Form (from Proposal Guidelines) to the front of your Proposal
• Write down Session Code, e.g., A28100, and Meeting Date, Time, and Place on the Draft A Feedback Form. • Note meeting details in your calendar. • Submit hard copy in the drop box in SFB670 (electronic copy: upload onto ECE496 website)
8
Submitting Draft A
29
Fill in these boxes
Staple this form to the
front of your Draft A
Submission
Sign-up Sheet
30
Time
Session
Location
Project Name
Contact Person Name (PRINT)
Contact Person Email
12:00
A191200
GB204A
12:00
K191200
SFB670B
12:30
A191230
GB204A
12:30
K191230
SFB670B
1:00
A19100
GB204A
3:00
M19300
SFB670E
3:30
M19330
SFB670E
4:00
M19400
SFB670E
Time Session Location Project Name
Contact Person Name (PRINT)
Contact Person Email
12:00 A191200 GB204A
12:00 K191200 SFB670B
12:30 A191230 GB204A
12:30 K191230 SFB670B
1:00 A19100 GB204A
3:00 M19300 SFB670E
3:30 M19330 SFB670E
4:00 M19400 SFB670E
Project Proposal Schedule
n Draft A – Thu. Sept 19 by 3pm – Paper copy: submit to ECP office (SFB670) Register for an
appointment with ECP – Electronic copy: Log into ECE496 website and under
assignments, Proposal Draft A, click ‘Submit assignment’
n Draft B – Thu. Oct 10 at 3pm – Paper copy: Submit into drop boxes outside SFB560 in the box
for your section # (you will know by then) – Electronic copy: upload onto ECE496 website
31 32
No supervisor yet ??
Please stay after the lecture for the team forming session
Projects-> Finding Team/Project (on ECE496 website)