Transcript Interacting Discrete Event Systems: Modelling

Interacting Discrete Event Systems:
Modelling, Verification, and
Supervisory Control
Sherif S. Abdelwahed
February 4, 2002
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
Modeling Multiprocess Systems
Main dimensions
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
System Environment
Elements of Process Space
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
Basic sets and operations
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
Language
vectors
composition
Languages
decomposition
Behavioral Analysis of Multiprocess Systems
Behaviour comparison
(flat) system
Composition approach
• Works directly without
further adjustment
• Computationally inefficient;
state explosion problem
Problem
Compare a multiprocess
system to a (flat) specification
Issues
• Different structures
?

• Conversion has to be made
specification
multiprocess system
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
Struc. specification
Model Adjustments
Compact language vectors
L1
• Do not contain any redundant
information in their components so that
x
L2
a
y
b
x
d
P B (L) = L
• Redundant information in the
components can be removed by
tracing shared behaviour
y
c
A non-compact language vector L = {L1,L2}
Language compensation
L
compensator
+
P3(L)
L
P
P2(L)
P1(L)
• 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
Interacting Discrete Event Systems
The model
• 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)
Interaction
specification, K
L1
Ln
…
where L is a language vector and K is
an interacting specification language
L
Extended operations
composition
IDES
Languages
I()
L()
decomposition
• Decomposition
 : L()  I(): L  (P(L ),C(L))
• Composition
B : I()  L(): (L,K)  || Li  K
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
1  2
2- 1
x
v
u
K
L1
Ln
u
v
x
u,v,x
u
x
v
u
u
v
x
Sync product
Refinement
v
v
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
• 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
• 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
initial system
composition
abstraction
•To be useful, it is necessary to
compute abstraction efficiently
Direct and Indirect abstractions
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
• given as language morphisms that
satisfy
• 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
• can be represented by transducers
(extension of mealy machines)
a,b
a
c
(  ) {}  G()  ([])*
• prefix preserving by definition
• The abstract mapping G is
preserved under indirect
computation if every shared event is
mapped to itself
c
b
a,b
a,b
x/{x}
d
d
b/{a,b}+
a/{a,b}+
b/{a,b}+
a/{a,b}+
x
Automaton-based Abstractions - Example
B1 || B2
B1
a1
B2
b1,z
y
a2
y
z
a1
b2
0
1,2
0,1
x
b2
||
x
h1
z
a1
2
x
b2
y
h2
h1 x h2
A1 || A2
A1
a1
A2
y
1
a1
0
b2
2
x
||
0
b2
a2
a2
a1
x
b1
z
x
z
2
z
a2
1
a2
b1
y
b2
b2
b2
a1
b1
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)
c1
c0
x1
co
xo,yo
00
bo
x2
04 y2
06
03
c1
bo
01
y2
x1
ao
05
02
co
14
x1,y1
10
b1
Potential blocking
states
(q00, q10, q20)
(q03, q13, q23)
c2
16
yo
11
yo
x2
xo
13
c2
b1
a1
15
12
c1
24
x2,y2
20
b2
26
y1
21
y1
xo
23
b2
a2
25
22
c2
Both unreachable
System is deadlock
free
Reachability cost: 23
System size: 73
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
x
00
a1
01
y
02
b1
04
z
b1
03
a1
x
10
a2
11
y
12
b2
14
z
b2
13
a2
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
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
Modular solution
• In general,
interaction
refinement
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
over approximation
Local Testing
success
fail
terminate
failure Analysis
genuine
failure
Iterative Verification – Example
IDES
K = *
Specification
c0
co
00
c2
c1
04
x1
03
c1
bo
xo
bo 06
01
ao
x1
05
02
00
co
Initial abstraction
Ko = K = *
04
x2
03
b1
x1
b1 06
01
x2
a1
02
05
00
c1
xo
03
ao
b2
x2
b2 06
01
xo
a2
05
c2
a2
Fourth refinement
K4
1
ao
a1
x2
a2
Local verification: fail
Failure report:
(,a1), (,a2)
a1
02
First refinement
K1
x

Local verification: fail
Failure report:
(,a1), (,a2)
c2
04
…
x1
a1
xo
a2
x2
Local verification: OK
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
Supervisory Control of MDES - Example
System
Specification
L1
L1
x
00
a1
01
y
02
b1
04
z
b1
03
L1
00
01
y
a1
02
a2
x
b2
04
z
b2
03
a2
x
00
01
y
a2
02
04
z
b2
’
b2
00
a2
03
01
b1
b2
b3
02
Supervisor
b1
Red states are bad
3,1,1
Forward sync.
explores only 19 out
of 65 global states
Optimal supervisor
is obtained in one
iteration
4,1,1
a2
2,1,1
a1
x
0,0,0
4,2,1
b1
2,2,1
a3
a3
b1
1,1,1
a2
a1
1,2,1
b1
y
a3
a3
b1
3,2,1
1,1,2
b1
4,4,4
2,2,2
b1
4,2,2
4,1,2
a1
a1
z
a2
2,1,2
a2
b2
1,2,2
b1
3,1,2
b3
3,2,2
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
T
|| (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
K
V1
V2
V3
L1
L2
L3
IDES supervision structure
Supervisory Control of IDES - Example
System
Process A
x
op3a
Specification

r2a
op1a
op1a
op2a
Process B
op1a
op2a
r1a
r2a
op1b
x
op4a
op3b
r2b
op4b
mb
r3b
r4a
fa1
op2b
r1b
ma
r3a
x
r4b
fb1
fa2
fb2
C(S)
IDES Supervisor
Co(S)
Spec A
Spec B
r2a
Sub A
x
r2a
x
op4a
op1a
op3a
x
op1a
Sub B
fa1
fa
2
r4a
ma
r3a
r1a
op1a
op2b
r2b
r1b
op2a
op1b
x
op2a
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