10 Aug 2010

1. ECE/BENG-492 SENIOR ADVANCED DESIGN PROJECT Meeting #5 10 Aug 2010

2. ECE-492 Meeting#5 Q1: Teams – show draft diagrams of your system architecture Q2: Any questions about proposal format and preparation?

3. System Design II:Behavioral Models • A system model is needed for describing system behavior, with an emphasis on computing resources and other resources influencing system functionality • Models are needed to describe: • Interactivity of a system with the environment • Man-machine interactions – how to operate a system • Interactivity between modules – signal/data exchange, actions, etc. • Models can be used to describe system behavior at any level

4. You need to work with these models to avoid disasters ! • They are also planning tools for your team • ‘Model’ – we mean a hard copy so you and your team can see it on paper • Models in your mind. . . leave for your hobbies. . . • A hard copy is a must: • To have a blueprint of system behavior, • To transfer your mathematical model into its implementation • To coordinate your implementation activities around these behaviors, and • To be able to trace it if problems occur --- and they will !!!

5. Models • State Diagrams (State Machine) • State diagrams describe the behavior of systems with memory • Intuitively, a state corresponds to an operating mode of a system and inputs are associated with transitions between states • Almost all systems are systems with memory – consider startup phase, work phase, turn-off phase, sleep phase, etc. • Show transitions between states/phases using state diagrams • A must for systems with microcontrollers • Excellent tool to visualize control influences for systems controlled by a microprocessor • Mostly used at the upper abstraction level • Again, you have to use them when programming microcontrollers – will help you to define tasks and task switching mechanisms

6. No-Operation Start Engine Engine Running Power Off Power On ON(Engage Off) or ON(Rpm=0) Emergency Stop Stop (INT) Idle Engage On Engage Charge On Pause (INT) Base Charge Mode 11 Mode 01 Mode 10 Balance Power Charge Battery Max

7. Flowcharts • The intention is to visually describe a process or algorithm; for example data/signal processing • Used to connect activities of a process or algorithm together • You can use flowcharts to describe processes at different levels of detail within each state • Data Flow Diagrams • Used to model the processing and flow of data inside a system • A function oriented modeling approach • Differs from Flowcharts – it does not encapsulate control and sequencing information, but allows multiple processes running concurrently • See Chapter 6

9. CASE STUDY#1< State Diagram >

10. Modeling and Design Design + Mathematical model  System implementation • Many ECE 492/3 projects include a control component • If you have a control element in your system, then review control engineering principles • Proper design, modeling and implementation is still a challenging issue for EE and CpE students • RIGH vs. WRONG

11. Structure + Parameter Modifications System Design Structure System Implementation Completely WRONG Parameter Modifications Better but still WRONG System Design Structure System Implementation Design evaluation Simulation Performance prediction + Parameters RIGHT System Model (math+physics) System Design System Implementation Structure + Parameters Structure Performance data

12. Mathematical Modeling and System Control • Use functional/physical decomposition to determine system structure • Assign mathematical equation(s) to each physical/functional element (this will help you to handle complexity and allow for easier implementation and debugging) θ B K Vr Va Vm Power Amp. KTa DC Motor Kv, KT J - Tl Gears r Potentiometer Kp

13. Use simulation • System debugging will be simpler and conclusions for system modification will be more clear • You will estimate system parameters much faster  meaning: no endless experimentation and debugging • Recommendations: • Use simple equation(s) to represent each system component • Check simulation results: • Are your results LOGICAL ? • Are they VALID ? • Can you EXPLAIN what happens in your system ? • Keep it simple, complicate later when you succeed

14. Early Prototyping • Early prototyping is absolutely needed to • Understand chips/components you will work with (these days many chips are multifunctional with inherited complications) • Check them against spec • Play to educate yourself and gain experience • Right after proposal presentation, you need to define key chips/elements you will use in your design/system – you need to buy them early and work with them immediately • Early prototyping report is needed at your Design Review Presentation (Week#11) • You will eventually need to extend early prototyping over the first 1-2 weeks of ECE-493, if needed, but no longer than that

15. Proposal Presentation • Limit your presentation to 20-30 minutes • You must have two faculty members at the presentation • All team members must speak at the proposal presentation – distribute the load evenly, but do not switch speakers too frequently • Your presentation must be professional • It matters what you wear • Use audio-visual equipment • Distribute a copy of your proposal and slides before the presentation day (coordinate with FS) • Use right size font and nice figures • Book the room and find another faculty in advance

16. Preparing for the Presentation • Before you start developing the presentation, plan your strategy. Design it! You are telling the story!!! • Analyze your audience - it’s the audience stupid! • What are they interested in? • What do they want from your talk? • What does the audience know? What don’t they know? • Determine main points • Emphasize 2-3 main points in your talk • Structure your presentation to support these points • Remember, ‘tell your story’

17. Sample Presentation Content • Follow your proposal content • Introduction/motivation and identification of a need • Main technical body including • Requirements • System architecture • Alternative designs (any other you considered?) • Identify main components and their role. How about interfaces? • What are major challenges? • Experimentation and testing approach • Main administrative body • List of tasks and allocation of responsibilities • Skills of team members. What is an extra knowledge/skills to be acquired? • Conclusions

18. Extra Advice • Use professionally prepared graphics • Do not use PowerPoint “CPU Wasters” (extra visual effects, fancy combinations of them) • Avoid the use of cue cards – read directly from slides • Meet the time constraints through the entire talk – have control points • Motivate your audience to listen. Stay excited. • Practice your talk in front of your teammates, girlfriend/ boyfriend, family members • Do not overprepare to the point of sounded scripted • Practice the talk a night before, and do only a brief review of the material right before the talk • You can tell a joke but watch out the ethics, etc. • Prepare for the question and answer session

19. For the Next Meeting • Read textbook – Chapters 6 and 12 • Teams – bring a state diagram showing state transition of your system at Level-1 (or Flowchart, Data flow diagram) • Next meeting: • Design document; Design Review presentation