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