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

2. Introduction 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 Problem 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 Proposed approach

3. System Environment Modeling Multiprocess Systems 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. Main dimensions Interaction Specification component

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

5. Behavioral Analysis of Multiprocess Systems Problem Compare a multiprocess system to a (flat) specification Issues Different structures Conversion has to be made Behaviour comparison multiprocess system specification  ? (flat) system Composition approach Works directly without further adjustment Computationally inefficient; state explosion problem Struc. 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. Model Adjustments 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 Compact language vectors A non-compact language vector L = {L 1,L 2 } ab c d x xy y L2L2 L1L1 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 Language compensation L P 1 (L) P 2 (L) P 3 (L) PP L compensator +

7. Interacting Discrete Event Systems 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) where L is a language vector and K is an interacting specification language The model Interaction specification, K L1L1 LnLn … L IDES I(  ) Languages L(  ) composition decomposition Decomposition   : L(  )  I(  ): L  (P  (L ),C  (L)) Composition B  : I(  )  L(  ): (L,K)  || L i  K Extended operations

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 K L1L1 LnLn x  1 -  2 1  21  2 uv x uv x x u v uv uv v u,v,x Sync productRefinementCatenationInterleaving  2 -  1

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 K 11 L1L1 L2L2 L3L3 K 21 K 12 L1L1 L2L2 L3L3 K 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 Two way conversion

10. Abstractions in Process Space 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 Direct and Indirect abstractions abstraction composition initial system final abstraction indirect direct

11. Automaton and Language 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 Language-based abstractionsAutomaton-based abstractions a/{a,b} + b/{a,b} + x/{x} a b c d a,b c d xa/{a,b} + a,b

12. b2b2 a1a1 b2b2 a1a1 y z x b 1,z a1a1 y x 01,2 z x 0,12 b2b2 a2a2 y || y x a1a1 b2b2 0 1 2 z z a2a2 b2b2 0 1 2y h1h1 h2h2 x b1b1 a1a1 a2a2 y z a1a1 a1a1 b1b1 b1b1 a2a2 a2a2 b2b2 b2b2 b2b2 x h 1 x h 2 A1A1 A2A2 B1B1 B2B2 B 1 || B 2 A 1 || A 2 Automaton-based Abstractions - Example

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 00 04 0605 03 02 01 x o,y o aoao bobo bobo coco coco x1x1 x1x1 y2y2 y2y2 10 14 1615 13 12 11 x 1,y 1 a1a1 b1b1 b1b1 c1c1 c1c1 x2x2 x2x2 yoyo yoyo 20 24 2625 23 22 21 x 2,y 2 a2a2 b2b2 b2b2 c2c2 c2c2 xoxo xoxo y1y1 y1y1 Potential blocking states (q 00, q 10, q 20 ) (q 03, q 13, q 23 ) Both unreachable System is deadlock free Reachability cost: 2 3 System size: 7 3 Milner scheduler (3 cyclers) c0c0 c1c1 c2c2

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 0001 02 03 04 x y z a1a1 a1a1 b1b1 b1b1 1011 12 13 14 x y z a2a2 a2a2 b2b2 b2b2 L1L1 L2L2 Potential blocking states (q 00, q 14 ), (q 04, q 10 ) Both unreachable - System is deadlock-free Reachability cost: 2 global states Potential livelock clique sets C 1 = {(q 00, q 01 ), (q 10, q 11 )} - terminal C 2 = {(q 00, q 01 ), Q 2 } - terminal C 3 = {Q 1,(q 10,q 11 )} – 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 Local Testing interaction refinement terminate failure Analysis success fail genuine failure over approximation

16. Iterative Verification – Example 00 04 0605 03 02 01 xoxo aoao bobo bobo coco coco x1x1 x1x1 c0c0 00 04 0605 03 02 01 x1x1 a1a1 b1b1 b1b1 c1c1 c1c1 x2x2 x2x2 c1c1 00 04 0605 03 02 01 x2x2 a2a2 b2b2 b2b2 c2c2 c2c2 xoxo xoxo c2c2 K =  * IDES Specification aoao a1a1 a2a2 Initial abstraction K o = K =  * Local verification: fail Failure report: ( ,a1), ( ,a2) First refinement K 1 Local verification: fail Failure report: (,a1), (,a2)  Fourth refinement K 4 Local verification: OK … x1x1 x2x2 a1a1 a2a2 a1a1 a2a2 x1x1 x2x2 aoao xoxo

17. Supervisory Control of Multiprocess DES Multiprocess DES supervision given a multiprocess DES L and 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. 0001 02 03 04 x y z a1a1 a1a1 b1b1 b1b1 01 02 00 b1b1 b2b2 b3b3 ’’ 0,0,01,1,11,2,12,1,22,2,24,2,2 3,1,12,1,12,2,1 1,1,21,2,2 4,1,14,2,1 3,2,1 4,1,2 3,1,23,2,2 4,4,44,4,2 a1a1 a2a2 a3a3 a1a1 a2a2 a3a3 a2a2 a2a2 b1b1 b2b2 b3b3 z x y a3a3 a1a1 a3a3 a1a1 b1b1 b1b1 b1b1 b1b1 b1b1 b1b1 L1L1 Supervisory Control of MDES - Example System Specification 0001 02 03 04 x y z a2a2 a2a2 b2b2 b2b2 L1L1 0001 02 03 04 x y z a2a2 a2a2 b2b2 b2b2 L1L1 b1b1 Supervisor Red states are bad Forward sync. explores only 19 out of 65 global states Optimal supervisor is obtained in one iteration

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 L1L1 L2L2 L3L3 V1V1 V1V1 V2V2 V3V3 K T IDES supervision structure

20. x fa1 x fa2 ma r1ar2a op1aop2a op3a op4a r3a r4a Process A fb1 x fb2 mb r1br2b op1bop2b op3b op4b r3br4b Process B  r2a op1a Spec A op2a Spec B op1a C  (S) r2a op1a op2a System Supervisory Control of IDES - Example Specification Sub A r2a r1a op1a op2a fa1 fa 2 ma r3a r4a op3a op4a x x r2br1b op2b op1b x x Sub B C o  (S) IDES Supervisor

21. Conclusion 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 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 Contributions Future Research