Begin with a good plan · Requirement-Driven Design Amplifier Preamplifier Gain Stage Output Driver Stage and Power Supply 8-Ohm 8-Ohm "Design" (Creative activity) Initial Top Level

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


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’


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


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


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


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




Amplifier

Preamplifier Gain StageOutput Driver

Stage andPower Supply

8-Ohm

8-Ohm


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)


4


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


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


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


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


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)


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)



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



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


Perform Weekly Lawn MaintenanceCut Grass

Cut front lawnCut back lawnCut sides



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 ]


6


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


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


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.


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)

Documents

Begin with a good plan · Requirement-Driven Design Amplifier Preamplifier Gain Stage Output Driver Stage and Power Supply 8-Ohm 8-Ohm "Design" (Creative activity) Initial Top Level