Interacting Discrete Event Systems: Modelling, Verification, and Supervisory Control

1. Interacting Discrete Event Systems:Modelling, Verification, and Supervisory Control Sherif S. Abdelwahed February 4, 2002

2. Introduction Problem • Practical systems are usually composed of a set of interacting • components • Components interaction define the system architecture • The state space of the composite system grows exponentially with • the number of components • Direct approaches to DES analysis requires exhaustive search of the • system state space Proposed approach • Study the relation between the systems architecture and its • behaviour • Utilize architectural information to new analysis procedures where • the composition complexity can be avoided or reduced • Focus on the verification and supervisory control problems

3. Modeling Multiprocess Systems Main dimensions System Environment System components: The set of elementary processes of the system. Usually given or obtained by decomposition. The environment: The composition rule for the components. Usually assumed to be the synchronous product. The architecture: The way the components interact and communicate; An abstract specification of the system components. component component Interaction Specification component component

4. Elements of Process Space Process space Basic sets and operations • A multiprocess environment defined formally by: • Index set • a set Idefining a collection • of processes • Alphabet vector • A set of alphabets • = { i | i  I } • Composition rule • synchronous product • Main sets: • set of all language vectors L()(Models) • set of languages L() (behaviours) • Main operations: • Decomposition operation (projection) • P : L()  L(): L  {Pi(L ) | i I} • Composition rule (sync. product) • B : L()  L() : L  || Li Basic elements language vector L= {Li | i I} Events all events:  =  i  Ii sync. events s async. events a composition Language vectors Languages decomposition

5. multiprocess system Struc. specification Behavioral Analysis of Multiprocess Systems • Composition approach • Works directly without • further adjustment • Computationally inefficient; • state explosion problem Behaviour comparison (flat) system • Problem • Compare a multiprocess system to a (flat) specification • Issues • Different structures • Conversion has to be made ? specification  • Decomposition approach • Decomposition may be more efficient for relatively small size • specifications (typical) • Does not work directly due to: • Decomposed structure is not in general behaviourally equivalent to the specification • Existence of redundant information in the system components that does not contribute to its behaviour

6. a b x y c y x d Model Adjustments Compact language vectors L1 L2 • Do not contain any redundant • information in their components so that • P B (L) = L • Redundant information in the • components can be removed by • tracing shared behaviour A non-compact language vector L = {L1,L2} Language compensation L compensator • In general, due to information lost in • projections L B P(L) • Lost information can recovered by • using a compensator K such that • L =B P(L)  K • The set of compensators for L is not • empty and has a supremal element • C(L) = L  [B P(L) ]c + P3(L) P L P2(L) P1(L)

7. Interacting Discrete Event Systems The model Interaction specification, K • A language vector can only represent • a set of parallel processes • A more structured model is needed to • represent different forms of interactions • A general interacting discrete event • system (IDES) can be represented as • L= (L, K) • whereL is a language vector and Kis • an interacting specification language L1 Ln … L Extended operations • Decomposition •  : L()  I(): L  (P(L ),C(L)) • Composition • B : I()  L(): (L,K)  || Li K composition IDES I() Languages L() decomposition

8. Abstract Architectural Specifications • Architectural specifications usually • address each component as a whole • rather than its internal details • Layouts are special languages that • can be used to describe architectural • specifications. • An event in a layout represent a set • of events shared exactly by the same • set of components • Many standard operations can be • represented by layouts 1- 2 2- 1 1  2 u v x K L1 Ln u v x x u u,v,x u v u v v x v Sync product Refinement Catenation Interleaving

9. Multilevel Interaction Specifications • Practical systems usually • organized in a hierarchical scheme • A multilevel process space can be • formally represented by a set of • alphabet impeded into a tree • A multilevel IDES can then be • defined where the interaction • specification is distributed over a • multilevel process space Two way conversion • A multilevel interaction specification • can be converted to flat interaction • specification. • A flat interaction specification can be • converted to a multilevel matching a • given multilevel process space K21 K K12 K11 L1 L2 L3 L1 L2 L3

10. Abstractions in Process Space Direct and Indirect abstractions • Abstraction provides a simpler • representation of the system that • preserves its behaviour • In IDES, the interaction spec. • is an abstraction of the system • An abstraction L` of a system L • should retain enough information • such that for a given property P • L` P  L  P • If L` does not satisfy P it is then • refined until a proper abstraction is • found to confirm the test • To be useful, it is necessary to • compute abstraction efficiently • An association between the • abstraction and the system • behaviour is required to compute • the refinements • Direct • the system components are • composed then abstracted • Inefficient • Association is direct • Indirect • abstraction of the system components • are computed first and then composed • usually more efficient • association are difficult to preserve final abstraction indirect direct abstraction initial system composition

11. Automaton and Language Abstractions Automaton-based abstractions Language-based abstractions • given as a state partition for each • component • can be represented as a • homomorphism mapping between • finite state structures • mappings between the components • and their abstractions directly • translate to a map between the • system and its abstraction • components partitions translate to a • system partition • given as language morphisms that • satisfy • (  ) {}  G()  ([])* • prefix preserving by definition • can be represented by transducers • (extension of mealy machines) • The abstract mapping G is • preserved under indirect • computation if every shared event is • mapped to itself b/{a,b}+ a,b c a/{a,b}+ a,b a,b a c x/{x} b d b/{a,b}+ a/{a,b}+ x d

12. Automaton-based Abstractions - Example B1 || B2 B1 B2 a1 b1,z a2 y y z x b2 b2 z || a1 b2 a1 0 1,2 0,1 2 x x y h1 h2 h1 x h2 A1 || A2 A1 A2 a1 b1 y a2 a2 a2 1 1 a2 a1 b2 || a1 b1 0 0 z b2 x x 2 z b2 b2 b2 x 2 y a1 b1 z y

13. Deadlock Detection in Multiprocess Systems • Deadlocks • a deadlock state is a state in the composite system where no events are enabled • deadlock originates from the nature of the synchronization mechanism • Detect-first approach • a deadlock state in the composite system corresponds to a set of local states with • all eligible events are shared • the sets of eligible events at local states are disjoint • potential deadlock states can be identified locally • once identified potential deadlock states are checked for reachability Milner scheduler (3 cyclers) Potential blocking states (q00, q10, q20) (q03, q13, q23) Both unreachable System is deadlock free Reachability cost: 23 System size: 73 c1 c2 c0 x1 x2 xo 04 y2 03 14 yo 13 24 y1 23 co c1 c2 bo b1 b2 xo,yo ao x1,y1 a1 x2,y2 a2 02 12 22 00 01 10 11 20 21 co c1 c2 bo y2 b1 yo b2 y1 06 05 16 15 26 25 x1 x2 xo

14. Livelock Detection in Multiprocess Systems • Livelock • a deadlock state is a state that is • not deadlocked but cannot reach a • terminal states • livelock states must exist in a clique • that does not contain a terminal state • Detect-first approach • a livelock clique in the composite • system corresponds to a set of local • clique that when composed • - remains a clique • - is reachable • - has no terminal state • a potential livelock clique set is a one • satisfying any of these conditions • potential livelock cliques can be • identified locally • only maximal local cliques need to • be considered L2 L1 a1 02 b1 a2 12 b2 x x 00 01 04 10 11 14 z z y y b1 a1 b2 a2 03 13 Potential blocking states (q00, q14), (q04, q10) Both unreachable - System is deadlock-free Reachability cost: 2 global states Potential livelock clique sets C1 = {(q00, q01), (q10, q11)} - terminal C2 = {(q00, q01), Q2} - terminal C3 = {Q1,(q10,q11)} – terminal C4 = {Q1,Q2} - terminal System is livelock-free Testing complexity: depends on testing order

15. Verification of Interacting Discrete Event Systems • IDES verification problem • given an IDES L= (L, K) and a • specification S, test if • B(L)  S • The specification S can be converted • to an IDES S= (S, R) and the • problem will be to test if • B(L)  B(S) • without computing the composition • Modular solution • In general, • L  S B(L)  B(S) • However, the other direction does • not hold in general • Therefore, if local testing fails the • verification check cannot be • confirmed • Iterative verification • if the local test fails, refine K and • check again • A solution is guaranteed when K • reaches its minimal limit namely B(L) • if the number of possible refinements • is finite, the iterative procedure is • guaranteed to terminate Initial abstraction interaction refinement over approximation Local Testing failure Analysis fail genuine failure success terminate

16. Iterative Verification – Example IDES K = * Specification c2 c0 c1 xo x1 x2 04 03 ao a1 04 03 04 03 c2 co c1 b2 bo b1 x2 a2 xo ao x1 a1 02 02 02 00 01 00 01 00 01 xo c2 a2 x1 co x2 c1 b2 bo b1 06 05 06 05 06 05 Initial abstraction Ko = K = * Local verification: fail Failure report: (,a1), (,a2) First refinement K1 Local verification: fail Failure report: (,a1), (,a2) Fourth refinement K4 Local verification: OK x1 ao x1  a1 … a2 a1 xo x2 a2 x2

17. Supervisory Control of Multiprocess DES • Multiprocess DES supervision • given a multiprocess DES Land a specification S, design a supervision P • such that • B(L)  P  S • Synthesis the supervisor without computing the composition B(L) • Forward synchronization • a supremal non-blocking supervisor can • be obtained by exploring only the • behaviour common with S • while synchronizing L and S a state • (q, x ) in Q(L)  Q(s) is marked bad if • 1. an uncontrollable event is eligible • for q but not for x • 2.(q, x ) cannot reach a terminal state • 3. (q, x )leads uncontrollably to bad state • bad state identification is repeated until • there no more bad states • usually efficient for restrictive spec. • Detect first approach • the idea to isolate and then • remove bad states • a potential bad states is defined • by conditions 1,3 • control information can be • suplied for a bad state without • testing its reachability • a bad state is tested for • reachability only if it influences • the status of another state • can be efficient for permissive • specifications

18. Supervisory Control of MDES - Example System Specification L1 L1 L1 ’ a1 02 b1 a2 02 b2 a2 02 b2 b1 01 x x x 00 01 04 00 01 04 00 01 04 00 b2 z z z y y y b1 a1 b2 a2 b2 a2 b3 03 03 03 02 Supervisor Red states are bad Forward sync. explores only 19 out of 65 global states Optimal supervisor is obtained in one iteration 4,1,1 4,2,1 b1 b1 a2 3,1,1 2,1,1 2,2,1 a1 a3 a3 b1 x a1 a2 a2 b1 0,0,0 1,1,1 1,2,1 2,1,2 2,2,2 4,2,2 a3 b1 b1 3,2,1 4,1,2 y a3 a1 a1 z b2 1,1,2 1,2,2 a2 3,1,2 3,2,2 b1 b1 b3 4,4,4 4,4,2

19. Supervisory Control of Interacting DES • IDES supervision problem • given an IDES L= (L, K) and an • IDES specification S= (S, R), • design and IDES supervisor • V= (V, T) such that • || (Vi/Li)  (K/T)  B(S) • synthesis the supervisor without • computing the composition • Modular solution • we assume every language is prefix • closed (no blocking) • IDES supervision is always valid • (will restrict the system to the spec) • IDES supervision is optimal if: • - every shared event is controllable • - K is controllable w.r.t. B(L) • (can be guaranteed in some cases • without computing B(L)) • - R  K is controllable w.r.t K T K V1 V1 V2 V3 L1 L2 L3 IDES supervision structure

20. Supervisory Control of IDES - Example System Specification  r2a op1a Process A Process B x op1a op2a op1b op2b op1a op2a x x op4a op4b op3b op3a r1a r2a r1b r2b ma mb r3a r3b r4b r4a fb1 fb2 fa1 fa2 C(S) IDES Supervisor Co(S) Spec A Spec B r2a op1a Sub A Sub B x r2a op1a op2a x op2b op4a op1a fa1 op3a fa2 r4a r2b r1b op2a ma x r3a op1b r1a x

21. Conclusion Contributions • Investigated the relation between the behaviour and structure of interacting • discrete event systems: exploring the laws of architecture • Proposed a general paradigm for interacting DES, that integrates the • interaction specification in the modeling and analysis process • Proposed several approaches for verification of multiprocess DES based on • the IDES setting • Proposed several approaches for verification of multiprocess DES based on • the IDES setting • All proposed procedures avoid the computation of the synch product of • the system components; a major bottleneck in the analysis of IDES Future Research • Extensions for real-time systems • Extending the analysis procedures for multi-level systems • Further investigation of the blocking problem, particularly for the IDES • supervision problem