CS 367: Model-Based Reasoning Lecture 6 (01/31/2002)

1. CS 367: Model-Based ReasoningLecture 6 (01/31/2002) Gautam Biswas

2. Today’s Lecture • Last Lecture: • Parallel Composition • Observer Automata • State Space Refinement • Automata with Input and Output • Analysis of Discrete Event Systems: Safety, Blocking, State Estimation, Diagnostics • Today’s Lecture: • Diagnoser Automata • Notion of Diagnosability (Sampath paper) • Supervisory Control • Feedback control with supervisors • Specifications on Controlled Systems

3. Analysis of Discrete Event Systems • Safety and Blocking Properties • Safety: avoiding undesirable states, or undesirable sequence of events for a composed automaton – “legal” or “admissible” language • Determine if state y is reached from state x : perform accessible operation on automaton with x as initial state, look for y in result • Determine if substring possible in automaton: “execute” substring for all accessible states Parallel composition complexity: Accessible, Coaccessible algorithms are linear in size of automaton • Blocking Properties:

4. State Estimation • Unobserved events: •  events can be attributed to: (i) absence of sensors, (ii) event occurred remotely, not communicated, (iii) fault events • Genuine unobservable events:

5. Daignostics • Determine whether certain events with certainty: fault events • Build new automata like observer, but attach “labels” to the states of Gdiag

6. Building Gdiag • To build • Step 1: Label the unobservable reach from x0 • Attach N label to states that can be reached from x0 by unobservable strings in • Attach Y label to states that can be reached from x0 by unobservable strings that contain at least one occurrence of ed • If state z can be reached both with and without executing edthen create two entries in theinitial state set of Gdiag: zN and zY. • Step 2: Build the subsequent states of Gdiag by following the rules for building Gobs (following Step 1 to maintain the unobservable reaches) and by propagating the label Y (i.e., any state reachable from zY should get the label Y)

7. Diagnoser Automata G Gobs Gdiag

8. Diagnosability

9. Diagnosability • Definition: (informal) Let s be any trace generated by the system that ends in a failure event from set Efiand t is a sufficiently long continuation of s Diagnosability implies that every trace that belongs to the language that produces the same record of observable events as st should contain in it a failure event from Efi Along every continuation t of s one can detect the failure of type Fi with finite delay, specifically in atmost ni transitions of the system after s Alternately, diagnosability requires that every failure event leads to observations distinct enough to enable unique identification of failure type with a finite delay Diagnosability must hold for all traces in L(G) that contain a failure event Relaxed definition: I-diagnosability – diagnosability condition holds only for those in which a failure is followed by certain indicator events associated with every failure type

10. Supervisory Control Feedback Control Automaton G with event set E – G models uncontrolled behavior of DES -- plant Not satisfactory – restrict behavior to subset of L(G) Done by supervisor denoted byS Issues: (1) How do we define restricted behaviors? -- specifications L(G) contains strings that violate conditions that we want to impose on plant, e.g., strings that lead us to blocking states, physically inadmissible substrings of strings that violate a norm ; Lr: minimal required behavior, La: maximal admissible behavior (2) How do we get S to modify the behavior of G ? S observes (some or all) events that G executes. S has the capability of disabling some but not all feasible events of G. It tells G to disable some of its feasible events. equivalent to dynamic feedback control.

11. Supervisory Control: Issues • S limited by which events it can observe in G –observable events in E • S limited by which events it can disable in G – controllable events in E • First answer Ques. 2: How to build feedback loop? • Then Ques. 1: How to define admissible behavior? • Supervisory Control Theory: attributed to W.M. Wonham and P.J. Ramadge (note Wonham is Sherif’s thesis advisor).

12. G S(s) s s S Assume all events are observable: s all events executed by G so far and S has seen them all How is control achieved? Controllable events of G can be dynamically enabled or disabled by S Formally, a supervisor is a function For each generated by G (supervised by S) is the set of enabled events that G can execute at it current state G cannot execute event unless it belons to S(s) Feedback Loop for Supervisory Control DES

13. Supervisory Controller: Terminology • Supervisory controller is admissible if • S(s) : control action at s • S is the control policy • For dynamic feedback domain of function S is L(G) and not X; so control action is not function of state, but function of event sequence s • Closed loop system is denoted by S/G

14. Language generated by S/G Language marked by S/G: Overall: Therefore, the controlled DES S/G is an automaton that generates L(S/G) and marks Lm(S/G) Marking implies completion of task or particular operation In this context, S is nonblocking if S/G is nonblocking

15. Control under Partial Observation G SP[P(s)] P S Because of P supervisor cannot distinguish between s1 and s2, i.e., Control action under partial supervision SP: P-supervisor Control Action can change only after occurrence of an observable event; but this action happens before an unobservable event occurs

16. Projections

17. Properties of P-supervisor • Supervisor is admissible if it does not disable a feasible uncontrollable event • Language generated by SP/G All feasible continuations in L(G) of all strings that SP(t) applies to

18. Specifications of Controlled System • Feedback supervisor S (SP) introduced to eliminate “illegal” traces in G. • Legal behavior of L(G) is La, where a – admissible Partially observable, replace S by SP

19. Specifications of Controlled System • La (or Lam) obtained after accounting for all specifications of system • These specifications are themselves described by one or more (possible marked) languages, Ks,i, i=1,…..,m • If specification language Ks,i is not given as subset of L(G) (or Lm(G)), then we take