Post on 24-Aug-2019
ELEC-843: Control of
Discrete-Event Systems
Karen RudieDepartment of Electrical and Computer
Engineering
Queen’s University, Canada
karen.rudie@queensu.ca
WHAT ARE DISCRETE-EVENT SYSTEMS
(DESs)?
• Processes that are characterized by sequences
of events or actions
– queues
– traffic systems
– communication protocols
– database systems
– flexible manufacturing systems
– autonomous vehicles, robots
1
• Processes where change in state (or status)
of system is precipitated by occurrence of
event, not merely by passage of time
– e.g., if you’re waiting in lineup at bank and
for ten minutes no one leaves line or
enters line, then your situation (i.e., when
you will get served by teller) doesn’t
change just because time goes by.
However, if the person in front of queue
suddenly gets served by teller, then your
situation changes.
– behaviour of system best described by
describing sequences of events that occur
• Since such systems are not continuous
functions of time, and since typically such
systems are products of technology and not
natural phenomena, they are not
appropriately described by sets of differential
equations
2
• So we need to adopt some other
mathematical formalism to represent systems
and then develop a control theory that uses
these models
– take techniques and tools from computer
science and mathematics to do modeling
– develop a new branch of control theory for
these models
APPROACH
• Model some discrete-event system that is not
behaving in a desirable way
• Apply control to inhibit behaviour of
uncontrolled process
– prevent some events from occurring or
force some events to occur
– for real-time constraints would need to
make sure that events occur before
specified deadlines
3
• Useful in problems where specifications
require prescribed relative ordering of actions
– e.g., “retransmit data” after
“communication channel loses message”
– “logical time” as opposed to “real time”
• Abstracts chunks of information for high-level
control
NOTE: Processes are asynchronous (not
clock-driven)
4
SMALL FACTORY
Buffer
Output BinInput Bin
Machine 1 Machine 2
µβ
λ
α 2
2
2
2
Machine 1 Machine 2
µβ
λ
α 1
1
1
1
α1 Machine 1 takes workpiece from input bin and
starts processing it
β1 Machine 1 passes completed workpiece to buffer
λ1 Machine 1 breaks down
µ1 Machine 1 is repaired
α2 Machine 2 takes workpiece from buffer and
starts processing it
β1 Machine 2 completes working on part and
puts it in output bin
λ1 Machine 2 breaks down
µ1 Machine 2 is repaired
5
Why do we need control?
• Without preventing any of the events from
occurring, Machine 1 could keep dumping
workpieces into the buffer even if buffer is full
• If Machine 2 is more critical in overall factory
operation, then we might want to attend to
repairing Machine 2 before repairing
Machine 1 in the situation where both
machines need repair
Specifications
1. buffer must not overflow or underflow
2. if both machines are broken, Machine 2 must
be repaired before Machine 1
6
MUTUAL EXCLUSION PROBLEM
Critical Section: part of a program that accesses
shared resources
Mutual exclusion: make sure that no two
processes enter their critical sections at same
time
resource 1
resource 2
resource 2
resource 1
acquire
acquire
acquire
acquire
User
releaseresources
• With many users, if don’t prevent certainevents from occurring at certain times, then
– may have deadlock (if one user takes resource 1and one user takes resource 2)
– both users may try to acquire resources at sametime
7
TRAFFIC CONTROL
Station A Station B
traffic light
sensor/detector
• One-way track from Station A to Station B
• Four sections on track
• Two vehicles use track simultaneously
8
• Goal: to avoid collision, control of stoplights
must ensure that Vehicle 1 and Vehicle 2
never travel on the same section of track at
same time
(Mutual Exclusion)
• Have partial observation due to limited
sensors
9
DATA TRANSMISSION PROBLEM
Problem Statement
• Sender gets arbitrarily long sequence of data
from a computer & passes data over
unreliable communication channel to receiver
• Receiver must pass data to another computer
in correct order & without duplicates
Physical Constraints
• Channel may lose or (detectably) corrupt
msgs—no re-ordering
• Sender may tag on extra information in
header of data msgs
• Receiver may send acks
10
Requirements of protocol solution:
• Since channel can lose frames, must have
mechanism for retransmission
– sender has timer at its end: timeout promptsretransmission
• To avoid duplicates and to maintain correct
order, receiver must be able to distinguish
frame it is seeing for first time from
retransmission
– sender is permitted to attach sequence number (inheader) to each frame that it sends
– only ambiguity for a receiver is between a frameand its immediate predecessor or successor
– 1-bit sequence number (0 or 1) is sufficient
11
timeout, cksumerrack
timeout, cksumerrack
SNDR
send0
timer
rcvack
getframe
getframe
rcvack
send1
timer
RCV R
passtohost
passtohost
rcv0
rcv1
sendack
rcv0
rcv1 sendack
cksumerr
cksumerr
12
lose, cksumerrack
CHNL
lose, cksumerrlose, cksumerr
rcvacksendack
send0send1
rcv0rcv1
13
• Think of DES as describing all possibleexecutions of protocol
– Each agent observes those events that occur at itsphysical location; other events are unobservable toagent
– Message receptions, channel losses and timeoutsare uncontrollable
• Question: Can we ensure (via control) that
only correct runs are allowed to occur?
• Control would amount to further inhibiting
DES by constraining behaviours of
communicating agents, i.e., sender and
receiver
• Need decentralized control
• Given solution, does it correctly meetspecification?
– verification
• Alternatively, if hadn’t started with protocolat outset, can we derive protocol
– synthesis
14
EMERGENCY RESPONSE
• Behaviour of patients, care workers, hospital
administrators can be described by
discrete-event systems
• Emergency response protocol prescribes
actions that agents should take
• Control could amount to preventing certain
actions at certain states
15
0
16
24
25
27 21
1
3
5
11
12
14 10
4
6
2
1817
20
19
9
15
28
8
26
13
23
7
22
Model created with IDES 2.1Queen’s University, Kingston
resisted
seffects
ctrace
noseffects
surv
quarantine
disa
die
infected
isolate
ctrace
surv
quarantine
treat
not iso
die
sympto
notctrace
treat
treat
sympto
notctrace
treat
not iso
disa
isolate
treat
notreat
notreat
sympto
treat
sympto
recover
isolatesympto
isolatesympto
no sympto
no sympto
no sympto
recoverno sympto
no sympto
no sympto
CONCURRENCY CONTROL
• Multi-threaded computer code describes
event executions (i.e., each step of program
is an action)
• Specifications describe ways in which
instrumented code should guarantee certain
concurrency requirements—e.g., a process
may not write to a space that is currently
being read by another process
• DES theory can be used to determine where
in code concurrency control should be added
16
Example
T2 T4
T5
T3
T1
• All threads start together
• thread-2, thread-3, and thread-4 (T2, T3,
and T4, respectively) must wait for thread-1
(T1) to finish before executing their code
• thread-4 must wait for thread-5 (T5) to
finish.
17
CHAPTER 3. PROCESS DESCRIPTION 40
Figure 3.13: The monolithic supervisor for the precedence example.
OTHER EXAMPLES
• Database Management
– (Lafortune 1988)
– Scheduling database transactions
– Events are, for example, “read”, “write”
• Flexible Manufacturing Cell
– (Holloway and Krogh, 1990)
– Automated guided vehicles transport
material to various manufacturing
workstations
– Want to ensure that no two AGVs occupy
same zone simultaneously
– Uses Petri net to model system
– Events are, for example, “enter zone 1”,
“depart from workstation”
18
• Semiconductor Manufacturing
– (Balemi, Hoffmann et al, 1993)
– Controlling temperature of wafer on IC
chip
– Events are, for example, “open door of
heating chamber”, “close valve”
• Failure Diagnosis
– (Sampath, et al, 1996)
– Problem of determining if certain failures
or faults in system components occurred
– In heating system: events are, for example,
“valve is stuck open”, “start pump”
– Failure events (such as “valve is stuck
open”) are unobservable
– Section 2.5.2 of book
19
HOW CAN WE MATHEMATICALLY
MODEL DESs
Logical models
• Ensure that sequences of events follow
prescribed ordering in logical time
• Models well-suited for algorithms that
produce controllers that meet event-ordering
criteria
• Chapters 1–4 of book (course will cover
chapters 1–3)
Performance models
• Models suited for performance analysis,
simulation, statistical analysis
• Chapters 5–11 of book (course will not cover)
20
I. Logical Models
Automata/Language-based
(Ramadge & Wonham, early 1980s)
µλ
G1
αβ
L(G1) = {ǫ, α, αβ, αβα, αβαβλµ, λµ, . . .}
Lm(G1) = {αβλµ, αβαβλµ, λµ, . . .}
Lm(G1) = (αβ)∗λµ
where ∗ means “arbitrarily many finite number of
times”
21
δ
β α
α λ
G2
Lm(G2) = (αλ + βα)δ
where + means “or”
Lm(G1) and Lm(G2) are regular languages
Can represent regular languages by finite-state
machines (graphs with finite number of vertices)
Example of nonregular language:
L = {αnβn | n = 1,2,3,4, . . .}
22
Petri Nets
• Petri, 1962
• Textbooks: Peterson, Reisig
• in DES Control: Krogh
Can represent nonregular languages
Example: L = {anbn | n ≥ 1}
23
Temporal Logic
• Manna & Pnueli
• In DES Control: Thistle, Ostroff
• In computer science: Hailpern, Owicki
• Predicate Logic with modal operators
α → ♦β
“The occurrence of α implies that eventually
β will occur”
– specification and verification
– hard to do synthesis
– good way of translating verbal description
of problem into mathematical formalism
– unwieldy to manipulate or compute since
have to use formal derivation proofs
24
Process Algebra
• Milner, Calculus of Communicating Systems
• Hoare, Communicating Sequential Processes
• In DES Control: Heymann; Inan & Varaiya
Algebraic equations that describe process
behaviour
25
II. Performance Models
• simulation
• perturbation analysis, pioneered by Ho
• used for analysing performance measures
such as “throughput” or “mean waiting
time” in a queue
26