Interacting Discrete Event Systems:Modelling, Verification, and

Supervisory Control

Sherif S. Abdelwahed

February 4, 2002

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

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 component

component component

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 spaceMain 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 elementslanguage vector L = {Li | i I}Events all events: = i I i sync. events s

async. events a

Basic sets and operations

Language vectors Languages

composition

decomposition

Behavioral Analysis of Multiprocess Systems

ProblemCompare a multiprocess system to a (flat) specificationIssues• Different structures• Conversion has to be made

Behaviour comparison

multiprocess system

specification?

(flat) systemComposition 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

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 = {L1,L2}

a b

c d

x

xy

y

L2L1

• 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

P1(L)

P2(L)

P3(L)

P

L compensator

+

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 modelInteraction

specification, K

L1 Ln

…

L

IDESI()

LanguagesL()

composition

decomposition

• Decomposition

: L() I(): L (P(L ),C(L))

• Composition B : I() L(): (L,K) || Li K

Extended operations

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

L1 Ln

x

1- 2 1 2

u vx

u v

x

x

u

v

u vu vv

u,v,x

Sync product Refinement Catenation Interleaving

2- 1

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

K11

L1 L2 L3

K21

K12

L1 L2 L3

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

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

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}+

b/{a,b}+

x/{x}ab c

d

a,b c

d

a,b

xa/{a,b}+

a,b

b2

a1

b2

a1

y

zxb1,z

a1

y

x0 1,2

z

x0,1 2

b2

a2 y

||

y

x

a1 b20

1

2

z

z

a2

b20

1

2 y

h1 h2

x||

b1a1

a2

y

za1

a1

b1

b1

a2 a2

b2 b2 b2

x

h1 x h2

A1 A2

B1 B2

B1 || B2

A1 || A2

Automaton-based Abstractions - Example

Deadlock Detection in Multiprocess SystemsDeadlocks• 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

06 05

03

0201xo,yo ao

bo

boco

co

x1

x1

y2

y2

10

14

16 15

13

1211x1,y1 a1

b1

b1c1

c1

x2

x2

yo

yo

20

24

26 25

23

2221x2,y2 a2

b2

b2c2

c2

xo

xo

y1

y1

Potential blocking states(q00, q10, q20)(q03, q13, q23)

Both unreachableSystem is deadlock free

Reachability cost: 23

System size: 73

Milner scheduler (3 cyclers)c0 c1 c2

Livelock Detection in Multiprocess SystemsLivelock• 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

00 01

02

03

04

x

yz

a1

a1b1

b1

10 11

12

13

14

x

yz

a2

a2b2

b2

L1L2

Potential blocking states(q00, q14), (q04, q10)Both unreachable - System is deadlock-freeReachability cost: 2 global states

Potential livelock clique setsC1 = {(q00, q01), (q10, q11)} - terminalC2 = {(q00, q01), Q2} - terminalC3 = {Q1,(q10,q11)} – terminalC4 = {Q1,Q2} - terminalSystem is livelock-freeTesting complexity: depends on testing order

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

Iterative Verification – Example

00

04

06 05

03

0201xo ao

bo

boco

co

x1

x1

c0

00

04

06 05

03

0201x1 a1

b1

b1c1

c1

x2

x2

c1

00

04

06 05

03

0201x2 a2

b2

b2c2

c2

xo

xo

c2

K = *IDESSpecification

ao a1

a2

Initial abstractionKo = K = *

Local verification: failFailure report:(,a1), (,a2)

First refinementK1

Local verification: failFailure report:(,a1), (,a2)

Fourth refinementK4

Local verification: OK

…

x1

x2

a1

a2 a1

a2

x1

x2

ao

xo

Supervisory Control of Multiprocess DESMultiprocess 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

00 01

02

03

04

x

yz

a1

a1b1

b101

02

00

b1

b2

b3

’

0,0,0 1,1,1 1,2,1 2,1,2 2,2,2 4,2,2

3,1,1 2,1,1 2,2,1

1,1,2 1,2,2

4,1,1 4,2,1

3,2,1 4,1,2

3,1,2 3,2,2

4,4,4 4,4,2

a1

a2

a3

a1

a2

a3

a2 a2 b1

b2

b3

z

x

y

a3

a1

a3

a1

b1b1

b1b1

b1b1

L1

Supervisory Control of MDES - ExampleSystem Specification

00 01

02

03

04

x

yz

a2

a2b2

b2

L1

00 01

02

03

04

x

yz

a2

a2b2

b2

L1

b1

SupervisorRed states are bad

Forward sync.explores only 19 out of 65 global states

Optimal supervisor is obtained in oneiteration

Supervisory Control of Interacting DESIDES 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

L1 L2 L3

V1V1 V2 V3

K

T

IDES supervision structure

x

fa1

x

fa2

mar1a r2a

op1a op2a

op3a op4a

r3a r4a

Process A

fb1

x

fb2

mbr1b r2b

op1b op2b

op3b op4b

r3b r4b

Process B

r2a

op1a

Spec A

op2a

Spec B

op1a

C(S)

r2a

op1a

op1a

op2a

System

Supervisory Control of IDES - ExampleSpecification

Sub A

r2a

r1a

op1a

op2a

fa1 fa2

mar3a

r4aop3a

op4a x

x

r2b r1b

op2b

op1b

x

x

Sub B

Co(S)IDES Supervisor

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