1 / 38

Motivation

Motivation. Supervisory control of systems composed of (synchronized) modules too large to fit in memory/be computed modules change with time: (dis)appear where continuous uptime is needed adaptive control is needed early warning of problems. DES Model.

aaron
Download Presentation

Motivation

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. Motivation • Supervisory control of systems • composed of (synchronized) modules • too large to fit in memory/be computed • modules change with time: (dis)appear • where continuous uptime is needed • adaptive control is needed • early warning of problems

  2. DES Model • The system G is modeled as a (synchronous) composition of modules Mj • Time is discrete and increments with one after each occurrence of an event • The composition can vary with time. Gt=M1t||M2t||…||Mnt t{0,1,…} • Modules can appear or disappear

  3. System control • Control is exercised using the limited lookahead online paradigm • “Supervisory control using variable looahead policies”, Chung, Lafortune, Lin, 1994 • (“Variable lookahead supervisory control with state information”, Hadj-Alouane, Lafortune, Lin, 1994)

  4. Problems • Computing the synchronous product of modules • Optimizing the control • Alternative to marking in the system (accepted language)

  5. Dynamic product • How to compute M=M1M2…Mn so that if Mi changes, M can be recomputed inexpensively? • The operation  is commutative and associative and there is an identity element e=*, Mie=Mi

  6. M5 Stack-like M4 M3 M2 • M=(…(M1M2)…)Mn • When Mi changes M1…Mi-1 remains intact • Older elements are “stacked” first • If there are stable components, they will “sink” • Not suitable for systems with non-persistent components M1

  7. Tree-like M1 M2 M3 M4 • M=(((M1M2)(M3M4))…)(…(Mn-1Mn )) • When Mi changes log n number of  is required to recompute M • Suitable for systems with any pattern of stability of modules • Increased requirements on memory

  8. Stack-tree • Using a tree, inner nodes are modules as well • M=(…(M1M2M3)M4(M5M6M7))…)Mi(…(Mn-2Mn-1Mn )…) • If top components change, less than log n number of  is required to recompute M • New modules go at the top, stable modules “sink” to the base of the tree • Not suitable for non-persistent modules • Increased complexity, need to use the identity element • (Reduced requirements on memory)

  9. Stack-tree * moves down added 15 disappers 7 14 10 3 6 13 1 2 4 5 8 9 11 12

  10. Recomputing M • When the composition of modules changes, the lookahead window has to be recomputed • Legality of states determined first on substructures to reduce the size of the complete product of the composition • Keep information about the Cartesian product of the basic-module states to facilitate the advancement of the horizon

  11. Optimization of control • Cost function v:*R v(s) =   sK (legal language) • v can be computed for example using the monetary value of events in a real system. Expenses will have positive values, revenue will be negative • Simplest v is 0 when not  • results in the original limited lookahead control policy

  12. Algorithm • Simple modification of algorithm in “Super. ctrl using var. lookahead policies” • generate the tree of the possible continuations of a string • var. ctrl with state information should be used

  13. Original algorithm • if from state come uncontrollable events, recursively compute the cost for each event and assign max value (or until ) • if only controllable event, recursively compute the cost for each one and assign min value (or until 0) • if state at border of window, return 0 or  depending on policy • optimistic • conservative

  14. Modified algorithm • Traversal stops when state is identified as illegal or when it hits the boundary • When traversing hits boundary, v(s) is returned • need to keep history (generated s) • Unlike original algorithm, traversal will not terminate when a state is identified as legal • for a better approximation of cost • costly when tree depth is very large

  15. goS Small truck (S) Examples fetch10 goB Big truck (B) • Trucks fetch material • Legal specs: • Only one truck can fetch material at a given time • Exactly 40 units of material are needed • c(goS)=5, c(goB)=6, c(fetch10)=10, c(fetch20)=12 • All events controllable (for simplicity) fetch10, fetch 20

  16. Cost function & compositions • v(s)= if slegal language • v(s)=c(i) - N*10 else • s=12…n; N=units of material fetched • G=S1||S2 t=0,1 • G=S1||B2 t=2,3 • G=B2 t > 3 • In the examples, the cost function isn’t always computed using the full history to keep the examples simple

  17. Example 1 (depth=1) • Time 0 v=5 goS1 Leave both goS2 v=5

  18. Example 1 • Time 1 (executed goS1) v=-90 fetch101 Leave fetch101 goS2 v=

  19. Example 1 • Time 2 (executed fetch101) v=5 goS1 Leave goS1 goB2 v=6

  20. Example 1 • Time 3 (executed goS1) v=-90 fetch101 Leave fetch101 goB2 v=

  21. Example 1 • Time 4 (executed fetch101) goB2 v=6 Leave goB2

  22. Example 1 • Time 5 (executed goB2) v=-90 fetch102 Leave fetch202 fetch202 v=-188 …Task completed

  23. Example 1 • Discussion • At time 2 there was a wrong choice in disabling goB2 instead of goS1, since big truck can bring more material • This was caused by the limited window size (no satisfactory prediction was possible)

  24. Example 2 (depth=2) • Time 0 v= goS2 goS1 fetch101 v=-85 Leave both v= goS1 goS2 fetch102 v=-85

  25. Example 2 • Time 1 (executed goS1) v= goS2 Leave fetch101 goS1 v=-85 fetch101 goS2 v=-85

  26. Example 2 • Time 2 (executed fetch101) v= goB2 goS1 fetch101 v=-85 Leave goB2 fetch102 v=-84 goB2 v= goS1 fetch202 v=-182

  27. Example 2 • Time 3 (executed goB2) goS1 v=-85 fetch102 goB2 v=-84 v= Leave fetch202 goS1 v=-183 goS1 fetch202 goB2 v=-182

  28. Example 2 • Time 4 (executed fetch202) fetch102 v=-84 goB2 Leave goB2 v= fetch202

  29. Example 2 • Time 5 (executed goB2) v=-84 goB2 fetch102 Leave fetch102 fetch202 goB2 v= …Task completed

  30. Example 2 • Discussion • The control is not optimal, since v(goS1fetch101goB2fetch202goB2fetch102) = v(goS1fetch101goS1fetch101goB2fetch202)+1 • Non-optimality arises because the system varies with time. Sometimes it can also happen that the controller will base the control decisions on a module which later will not be available

  31. goB Example 3 Big truck (B) fetch 20 • Consider the big truck can carry only 20 units. • Thus at time 4 we get a runtime error • Theoretically, the system can continue with goB2 to time 5 and then throw an RTE goB2 fetch202 v= RTE

  32. Example 3 • Discussion • Time varying made the system throw an RTE • Let’s relax the requirements and leave only legality rule #1 (only one truck can fetch at a time) • We’ll use the cost function to enforce the requirement for 40 units

  33. New cost function • v(s)= if slegal language • v(s)=c(i) - N*10 if N40 • v(s)=c(i) + N*10 - 400 else • s=12…n; N=units of material fetched

  34. Example 4 • At time 4, there is only a big truck available while only 10 units are required • There is no RTE, only the operation is very costly goB2 fetch202 v=118 << 

  35. Example 4 • If the big truck can fetch both 10 and 20 units (time 5): v=-84 goB2 fetch102 Leave fetch102 fetch202 goB2 v=118 …Task completed

  36. Example 4 • Discussion • Resulting behavior is “‘legal’ when possible, best effort otherwise” • Using the cost function to enforce requirements is much more flexible and leaves room when the system varies with time • Approach is language-oriented as opposed to state-machine-oriented

  37. General discussion • The optimality of the solution depends on how well the cost function can approximate the real cost of a string • limited future (lookahead window) • full-depth traversal of subtrees • history • Algorithm is flexible and makes best attempts to control system • Algorithm can be “tweaked” to consider • costs of disabling • allow threshold control of branching • notification of pending RTE’s • etc.

  38. “Goals” instead of marking • (preliminary idea) • Using marked languages in limited lookahead systems may lead to RTE’s due to wrong control • Using a cost function to guide execution can give a “second chance” to the system to recover (similar to rollback in databases) • Suitable for systems with continuous uptime (may have “checkpoints”) • System might not need to explore full tree depth if it recognizes the accomplishment of a goal

More Related