190 likes | 196 Views
This meeting discusses the importance of system models in describing system behavior and how to use them effectively. Topics covered include state diagrams, flowcharts, mathematical modeling, system control, simulation, and early prototyping.
E N D
ECE/BENG-492 SENIOR ADVANCED DESIGN PROJECT Meeting #5 10 Aug 2010
ECE-492 Meeting#5 Q1: Teams – show draft diagrams of your system architecture Q2: Any questions about proposal format and preparation?
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
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 !!!
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
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
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
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
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
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
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
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
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
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’
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
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
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