- 85 Views
- Uploaded on
- Presentation posted in: General

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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

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

Sherif S. Abdelwahed

February 4, 2002

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

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

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 Ii sync. events s

async. events a

composition

Language

vectors

Languages

decomposition

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

- Decomposed structure is not in general behaviourally

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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