1 / 65

Control and Data Agenda

Control and Data Agenda. 1. Definitions 2. Decision tables 3. Data flow 4. Instrumentation 5. Homework. 1. Definitions. Open-loop Vs closed-loop control Discrete Vs continuous control Logical Vs state-variable control States and status Mode Reconfiguration.

vlora
Download Presentation

Control and Data Agenda

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Control and Data Agenda 1. Definitions 2. Decision tables 3. Data flow 4. Instrumentation 5. Homework

  2. 1. Definitions • Open-loop Vs closed-loop control • Discrete Vs continuous control • Logical Vs state-variable control • States and status • Mode • Reconfiguration There are several types of control. 1. Definitions

  3. 2. Decision Tables • Two goals in logical control • Examples 1-4 2. Decision tables

  4. Two Goals in Logical Control • Enumerating all control options • Determining when the control applies 2. Decision tables

  5. Example 1 -- Control of Remote Terminal Remote terminal (RT) 1 Master bus communications self test loading operation RT 1 power switch closed open power • Goal -- turn on power, establish communications, load, and operate. 2. Decision tables

  6. Logical Control Requirements in Words • Two power control states • 1. Off • 2. On • Off when power switch is open. • On when power switch is closed 2. Decision tables

  7. Complete State Diagram Power-state state diagram RT 1 power switch open 1 off transition paths RT 1 power switch closed RT 1 power switch open same- state transition paths RT 1 power switch closed 2 on Power-state state diagram showing state transition paths and same-state transition paths 2. Decision tables

  8. Simplified State Diagram Power-state state diagram 1 off Power switch closed Power switch open 2 on Power-state state diagram showing only state transition paths and not showing the same-state transition paths. This form is used often. 2. Decision tables

  9. Number of Paths in a State Diagram • Maximum number of state transition paths is n2 • Maximum number of same-state transition paths is n • Maximum number of state transition paths excluding the same-state transition paths is n2 - n. • Maximum number doesn’t need to be present 2. Decision tables

  10. Truth Table criterion RT 1 power switch RT 1 power state open off closed on decisions A truth table the same information as state diagram, but it is less graphic 2. Decision tables

  11. Decision Table RT 1 power-state decision table A decision table is a truth table with the information rearranged to be more compact when typed 2. Decision tables

  12. Value of Decision Tables • Identifies all possibilities • Uncovers hidden paths • Promotes consistency • Provides concise documentation • Allows numerical checks for quality 2. Decision tables

  13. Limits of Decision Tables • Decision tables don’t guarantee that the decisions are right 2. Decision tables

  14. Number of Decisions • Number of decisions equals the product of the number of choices for each criterion. • Must account for all the decisions • A “-” in a decision table means that the decision table doesn’t care what the value of a criterion is. 2. Decision tables

  15. Showing the Number of Decisions RT 1 power-state Number of decisions per criterion Number of decisions It’s not necessary to show the number of decisions, but showing the number of decisions helps check the quality of the table 2. Decision tables

  16. Showing the Number of Paths RT 1 power-state Add current state even though not needed in example Show the matrix of paths It’s not necessary to show the number of paths, but showing the number of paths helps check the quality of the state diagram. 2. Decision tables

  17. Matrix of Paths • Show the number of paths between each state 16 1 2 14 14 2 3 3 2 2 1 2. Decision tables

  18. Example 2 (1 of 3) • Two communications states • 1. Not established (not est) • 2. Established (est) • Not established if power state is off or ability to communicate is false • Established if power state is on and ability to communicate is true 2. Decision tables

  19. Example 2 (2 of 3) communications not established power state = on and ability to communicate = true power state = off or ability to communicate = false communications established

  20. Example 2 (3 of 3) Communications state 2. Decision tables

  21. Guidelines for Control • Use one state diagram for each decision or concept • Use one decision table for each diagram • Use adjectives to avoid ambiguity • Confirm quality of decisions 2. Decision tables

  22. Canonical Format Example canonical format 2. Decision tables

  23. Rules for Ordering Criteria • Listed vertically • Based on the author’s guess at the impact of each criterion on state • Strongest criterion at the top • Weakest at the bottom 2. Decision tables

  24. Rules for Ordering Decisions • 1. Listed from left to right • 2. Weakest criterion change fastest • 3. Strongest change slowest 2. Decision tables

  25. Simplifying the Canonical Format Example canonical format 2. Decision tables

  26. Rules for Simplifying • 1. Find columns in which criteria have no effect • 2. Merge such columns into a single column • 3. Replace the values of the criteria that have no effect with a “-”. 2. Decision tables

  27. Guidelines for Creating a DT (1 of 2) • 1. Identify all states • 2. Identify all criteria • 3. Identify all values of each criterion • 4. Enter the criteria values into the table in canonical format 2. Decision tables

  28. Guidelines for Creating a DT (2 of 2) • 5. Determine state corresponding to each column • 6. Simplify the decision table • 7. Confirm the number of decisions 2. Decision tables

  29. Order of the Criteria Rows • Order of the rows can be changed • Number of columns may change 2. Decision tables

  30. Simplifying • Not necessary to simplify • Minimizing makes printing the decision table easier and helps definition and implementation 2. Decision tables

  31. Optimization • Row order resulting in fewest number columns is not always obvious • Obtained by trial and error 2. Decision tables

  32. Invariance • Number of decisions and the path matrix remain the same • Confirms accuracy of rearranging rows 2. Decision tables

  33. Changing Rows • Changing rows doesn’t leave table in canonical format 2. Decision tables

  34. Making Columns Mutually Exclusive • The columns must be mutually exclusive 2. Decision tables

  35. Violation of Mutual Exclusive Left hand Right hand Columns 1 and 2 in the left hand table are not mutually exclusive. Columns 1 and 3 in right hand table are not mutually exclusive. Results are conflicting. 2. Decision tables

  36. Additional Results Information Results in addition to state can be shown. However additional information may prevent merging some columns. 2. Decision tables

  37. Mechanical Guidelines for DTs • 1. Use Excel • 2. Use ‘- to enter a minus into a cell • 3. Use calculating capabilities to check numbers • 4. Use non-proportional fonts • 5. Use single character criteria 2. Decision tables

  38. Example 3 (1 of 5) • Three load states • 1. Not loaded or loading • 2. Loading • 3. Loaded • Determined by • Communications state (not est, est -- [F,T]) • Load state (1, 2, 3 -- [1, 2,3]) • Load command (none, stop, load -- [N, S, L]) • Load status (none, failure, complete -- [N, F, C]) 2. Decision tables

  39. Example 3 (2 of 5) • If (1) the comm state is not established or (2) the load status is failure, then the load state is not-loaded-or-loading • If (1) the comm state is established and (2) the load status is not failure and (3) the load command is stop, then the load state is loading • If (1) the comm state is established and (2) the load status is complete and (3) the load command is none and (4) the current load state is loading, then the load state is loaded 2. Decision tables

  40. Example 3 (3 of 5) not loaded or loading (1) comm state = not est or load status = failure comm state = not est or load status = failure comm state = est & load cmnd= load & load status = not failure comm state = est & load status =complete loading (2) loaded (3) comm state = est & load cmnd= load & load status = not failure 2. Decision tables

  41. Example 3 (4 of 5) 2. Decision tables

  42. Example 3 (5 of 5) Problems with developing decision table ad hoc 67>54 2. Decision tables

  43. Example 4 (1 of 3) • Two operate states • 1. Not operating • 2. Operating • Determined by • Operate command (stop, operate -- [S,O]) • Operate state (1, 2-- [1,2]) • Load state (not loaded, loading, loaded [1,2,3] • If (a) the operate command is stop, or (b) the operate command is operate and the loading state is 1 or 2, then the operate state is not operating • If the operate command is operate, then the operate state is operating 2. Decision tables

  44. Example 4 (2 of 3) not operating (1) operate command = operate operate command = stop operating (2)

  45. Example 4 (3 of 3) 2. Decision tables

  46. 3. Data flow • Flow diagrams • Automated techniques • Terminology • Tracing data flow 3. Data flow

  47. Flow Diagrams (1 of 2) • Flow diagrams show the flow of physical quantities, data, and control into, out of, and through a product. Examples are • Power • Cooling air • Signals • Control 3. Data flow

  48. Flow Diagrams (1 of 2) • Diagrams can be functional or physical • Controlling the flow is one of the strongest influences a product engineer has on the development of a product 3. Data flow

  49. Automated Techniques • Excel spreadsheet • Data bases; e.g. TeamWork 3. Data flow

  50. Flowing Down Interfaces Product requirements concept; e.g.,power control Product design requirements requirements requirements Lower product A requirements Lower product B requirements Interface requirements requirements Product requirements suggest a concept; e.g., power control. Design develops this concept and creates requirements for lower products and interfaces. The interface requirements also become requirements for the lower products 3. Data flow

More Related