1

Networks of TA; Specification Logic; Case Studies

CS5270, P.S. Thiagarajan

2

Parallel Composition

• TTS = TTS1 || TTS2 || …… || TTSn

• Same principle as before:– Do common actions together– Take union of clock variables.– Take conjunction of the guards (state

invariants) !

3

An Example.

4

The Product Construction

• TTS1 = (S1, s01, Act1, X1, I1, →1)• TTS2 = (S2, s02, Act2, X2, I2, →2)• Assume X1 and X2 are disjoint (rename if

necessary).• TTS = TTS1 || TTS2 = (S, S0, Act, X, I, →)

– S = S1 S2

– (s01 , s02 )

– Act = Act1 Act2

– X = X1 X2

– I(s1, s2) = I1(s1) I2(s2)

5

The Product Construction

• TTSi = (Si, S0i, Acti, Xi, II, →i) i = 1, 2• TTS = TTS1 || TTS2 = (S, S0, Act, X, I, →)• → is the least subset of S Act (X) 2X S

satisfying:– Suppose (s1, a, 1, Y1, s1’) →1 and (s2, b, 2, Y2, s2’) →2. – Case1: a = b Act1 Act2

• Then ((s1, s2), a, 1 2, Y1 Y2, (s1’, s2’)) →.– Case2: a Act1 - Act2

• Then ((s1, s2), a, 1, Y1, (s1’, s2)) → .– Case3: b Act2 - Act1

• Then ((s1, s2), b, 2, Y2, (s1, s2’)) →.

6

The Gate-Train Example

7

Reachability of Control States

• TS = (S, S0, Act, →) s S• s is reachable iff there is run which ends at s.• TTS = (S, S0, Act, X, I, →) s S• s is reachable in TTS iff for some valuation (s,

V), the state (s, V) is reachable in TSTTS.• In the Train-Gate example a good question to

ask is: – Is the state (in, up, s) reachable for some control state

s of the controller?– Safety property!

8

Reachability of Control States

• TTS = (S, s0, Act, X, I, →) s S• s is reachable in TTS iff for some valuation

(s, V), the state (s, V) is reachable in TSTTS.

• TSTTS = ((S V), (s0, Vzero) Act R, )• R, non-negative reals• (S V) Act R (S V)

• Both (S V) and Act R are infinite sets.

9

Reachability of Control States

• For a finite TS it is trivial to decide whether s 2 S is reachable in TS.

• For finite TTS, whether s is reachable in TTS is not easy to decide because TSTTS is an infinite object!

• But this can be done and this verification process can be automated.

• More involved (liveness) properties can also be verified effectively but not always efficiently.

10

The Reductions.

TSTTS

TA

QTA

Both the set of states and actions are infinite.

Time abstraction

Finite set of actions but infinite set of states.

Quotient via stable equivalence relation of finite index.

Both states and actions are finite sets.

TTSSemantics

11

The Reductions.

TSTTS

TA

QTA

Both the set of states and actions are infinite.

Finite set of actions but infinite set of states.

Both states and actions are finite sets.

QTA is computed directly from TTS (a finite object)

s is reachable in TTS iff the corresponding state is reachable in QTA.

TTSSemantics

12

Specification Logics

13

Temporal properties: Qualitative.

• We would like to pose more sophisticated questions (other than reachability questions)– Every “request” is “eventually” served.– The sensor signal x11 is sensed infinitely

often.– From any stage of the computation it is

possible to reach the “all clear” state within 3 steps.

14

Temporal Properties: Quantitative

• Every “request” is served within 3 micro seconds.

• The sensor signal x11 is sensed every 10 milliseconds for ever.

• From any stage of the computation it is possible to reach the “all clear” state within 1 second .

15

Temporal Logics

• Temporal Logics– A good mechanism for expressing qualitative

temporal properties of reactive systems.– Linear Time : LTL, …..– Branching Time: CTL, …..– SPIN, SMV,…

• UPPAAL Logic:– A part of CTL + a bit of real time.– A restricted version of TCTL.

16

The Verification Framework

• Start with a finite state (untimed) transition system TS = (S, s0, R)

• R S S is the (unlabeled) transition relation.

– Identify a finite of atomic propositions AP.• AP = {p, q, r, …}• p = “The alarm light is on”• q = “User15 is waiting”• r = “The buffer is full”

17

The Verification Framework

• TS = (S, S0, R)

• AP = {p, q, r,..}

• L : S → 2AP

• Valuation function• Specifies the (subset of ) atomic propositions that

are “True” at a state.

• Identifying AP and L is a part of the modeling process.

18

Atomic Propositions

Arbiter

Req-1

Grt-1

Req-2

Grt-2

Resource

PR1

PR2

i1 – Process 1 is idlew1– Process 1 is waiting

u1 – Process 1 is using the resource.AP = { i1, w1, u1, i2, w2, u2}

19

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2

Ret2

Ret1

20

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2

Ret2

Ret1

L(so) = {i1, i2}

L(s2) ={i1, u2}L(s5) = {w1,w2}

21

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2

Ret2

Ret1

L(so) = {i1, i2}

L(s3) = ?

22

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2

Ret2

Ret1

L(so) = {i1, i2}

L(s3) = {w1, i2 }

23

CTL

• TS = (S, S0, R)• AP = {p, q, r,..}• L : S → 2AP

• K = (S, S0, R, AP, L) is called a Kripke structure.– Often, AP is suppressed.

• Using AP, build a CTL formula .• Ask K, s ╞ ?• Is true in K at s?• This is the CTL model checking problem !• But we will look at only a fragment of CTL (CTL-) .

24

CTL-

• Syntax– AP – a finite set of atomic propositions.– p AP is a formula.– If and ’ are formulas then so are

’.

– If is a formula then so is EX()– If is a formula then so are

• EF() • AF().

25

Formulas• EX(p EF(AF( p r)))

EX

p EF

AF

r

p

26

Semantics

• K = (S, S0, R, AP, L)– L : S → 2AP

• a CTL- formula s S

• K, s ╞ • (holds) is satisfied at s.

27

Semantics

• CTL- ::= p | | 1 2 | | EX() |

EF() | AF()

• K = (S, S0, R, AP, L); L: → 2AP s S

• K, s ╞ p iff p L(s).

• K, s ╞ iff it is NOT the case K, s ╞ • K, s ╞ 1 2 iff

K, s ╞ 1 OR K, s ╞ 2.

28

Ret2

L(s2) ={i1, u2}

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2Ret1

L(s5) = {w1,w2}K, s5 ╞ w1 ?

K, s0 ╞ w2?

29

Ret2

L(s2) ={i1, u2}

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2Ret1

L(s5) = {w1,w2}

K, s5 ╞ i1 ?

K, s0 ╞ w2 i1?

30

Ret2

L(s2) ={i1, u2}

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2Ret1

L(s5) = {w1,w2}

K, s5 ╞ i1 ?

K, s1 ╞ i1 u2?

31

Semantics

• K = (S, S0, R, AP, L); L: → 2AP s S

• K, s ╞ EX() there exists s’ such that:– s → s’ (R(s, s’)) and – K, s’ ╞ – s has a successor state s’ at which holds.

32

on

off

onoffAP = {B, G, R}S0

S1 S2

K, S0 ╞ EX(R) ? K, S0 ╞ EX(R) ?

K, S1 ╞ EX(R) ?

K, S2 ╞ EX(G) ?

33

Semantics

• K = (S, S0, R, AP, L); L: → 2AP s S

• A path from s is a(n infinite) sequence of states = s0, s1, s2, …,si, si+1, … s.t:

– s = s0

– si → si+1 (R(si, si+1)) for every i.

• (i) = si the i th element of .

• Assume for convenience that for every s there is s’ such that R(s, s’).

34

Semantics

• CTL ::= p | | 1 2 | EX() |

EF() | AF() • K = (S, S0, R, AP, L); L: → 2AP s S• K, s ╞ EF() iff there exists a path = s0, s1, … from s and k 0 such

that: K, (k) ╞

35

EF()

36

s

s1

sj

sk╞

╞ EF(

37

Semantics

• CTL ::= p | | 1 2 | EX() |

EF() | AF()

• K = (S, S0, R, AP, L); L: → 2AP s S

• K, s ╞ AF() iff for every path = s0, s1, … from s there exists k 0

such that: K, (k) ╞

38

AF()

39

0

3

4

Req2

Grt2

M, 0 ╞ AF(u1) ?

0

Ret1

5

7

Req1

Grt1

40

0

3

4

Req2

Grt2

M, 0 ╞ AF(EF(u1)) ?

0

Ret1

5

7

Req1

Grt1

41

Derived Operator

• AX() = EX()– It is not the case there exists a next state

at which does not hold.– For every next state holds.

AX()

42

Derived Operators

• K, s ╞ AG()

• AG() = EF()– It is not the case there exists a path (from s)

and k 0 such that:• K, (k) ╞

– For every path (from s) and every k ╞ 0:• K, (k) ╞

43

AG()

44

Derived Operators

• K, s ╞ EG()

• EG() = AF()– It is not the case that for every path from s

there is a k 0 such that K, (k) ╞ .– There exists a path from s such that, for

every k 0:• K, (k) ╞ .

45

EG()

46

CTL- Model Checking

• The actual model checking problem:– Given K = (S, S0, R, AP, L)– Given s 2 S– Given , a CTL- formula.– Determine:

• K, s ╞

47

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2

Ret2

Ret1

L(so) = {i1, i2}

L(s2) ={i1, u2}L(s5) = {w1,w2}

K, s0 ╞ AX(w1) ?

48

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2

Ret2

Ret1

K, s0 ╞ AX(w1 w2) ?

49

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2

Ret2

Ret1

K, s0 ╞ EF(u2) ?

50

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2

Ret2

Ret1

K, s0 ╞ EF(u1 u2) ? u1 u2 = ( u1 u2)

51

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2

Ret2

Ret1

K, s0 ╞ AG(u2 u2) ?

52

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2

Ret2

Ret1

K, s0 ╞ AG( (u2 u2)) ?

53

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2

Ret2

Ret1

K, s0 ╞ EG( u2) ?

54

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2

Ret2

Ret1

K, s0 ╞ AF( u2) ?

55

s0

s3 s1

s5s4 s2

Req1 Req2

Grt1 Grt2

Grt1 Grt2

Req2 Req1

Req2 Req1

Ret1

Ret2

Ret2

Ret1

K, s0 ╞ AF(u1 u2 ) ?

56

CTL Model Checking

• The actual model checking problem:– Given K = (S, S0, R, AP, L)– Given s S– Given , a CTL formula.– Determine:

• K, s ╞

• This can be done “efficiently”• Can be automated:

– SMV

57

UPPAAL Properties

• The derived modalities EF, AF, EG and AG are defined as in the case of CTL.

• UPPAAL Syntax:– AG (bf) | EF (bf)– bf ::= p | x R c | bf | bf1 bf2 – x ≤ c x ≥ c x < c x > c– x can be a clock or data variable .

58

Case Studies

59

Case Studies

• Available from the UPPAAL home page (“Examples”).

• Bang & Olufsen Audio/Video Protocol:– Aim:

Messages are to be transmitted

between audio/video components over a

single bus.

– Critical real time constraints.– Error discovered using UPPAAL.

60

Case Studies

• Bang & Olufsen Power Down Protocol:– Aim:

Control the switching between power on/off states in AV components.

– 15 properties proved in UPPAAL to verify the design.

– Tightening of the design suggested by the verification process...

61

Case Studies

• Commercial Field Bus Protocol:– Aim:

Verify the process logic of this large industrial-strength bus communication protocol used in various industrial environments; developed by ABB.

– A number of errors found.

62

Case Studies

• Gear Box Controller:– Aim:

Design and verify a prototype gear box controller for a vehicle (Mecel AB).

• A component in a real time distributed system.• Gear-change requests from the driver delivered over

a network to the controller; • Controller actuates physical parts such as clutch,

engine, gear box.• 46 properties extracted from the requirements and

verified.

63

Case Studies

• Multimedia Stream:– Aim:

Model AV streams Verify quality-of-service properties

throughput, end-to-end latency..

64

BRP

• Bounded Retransmission Protocol (BRP).– Developed by Phillips Electronics Corporation.

• A real-time bounded variant of the alternating-bit protocol.

• Used to transfer in burst-mode a list of data (a file) – via an infra-red communication medium between AV

equipment and a remote control unit.

65

BRP

• The medium is lossy!

• The file is transmitted in chunks.– If an acknowledgment for a sent-chunk is not

received “in time” the chunk is retransmitted.– If the number of retransmissions for the same

chunk exceed a bound then the transmission is aborted.

66

BRP

• Timing aspects:– The sender has a timer to decide when to

retransmit a chunk.– The receiver has a timer to detect when a

transmission has been aborted by the sender.

67

Sender Receiver

Sin SoutRout

K

L

F

B A

G

68

Sender Receiver

Sin SoutRout

K

L

F

B A

G

(d1, d2, ,,,,dn) ; a file consisting of n chunks of data.

69

Sender Receiver

Sin SoutRout

K

L

F

B A

G

{IOK, INOK, IDK }

70

The values of Sout

• IOK – All the acknowledgments were received.– All the chunks were transmitted successfully and were received

by the receiver.

• INOK – Some ack. failed to arrive in time ; the MAX count of

retransmissions for that chunk was exhausted without receiving an ack.

• IDK

– The ack. were received for all the chunks except the last one.– Don’t know whether the transmission was successful or not.– This is due to asynchronous communication via a lossy channel.– Byzantine agreement is impossible!

71

Sender Receiver

Sin SoutRout

K

L

F

B A

G

(e1, i1) (e2, i2) ….(ek, ik)

72

Sender Receiver

Sin SoutRout

K

L

F

B A

G

(e1, i1) (e2, i2) ….(ek, ik)(d1, d2, ,,,,dn)

73

Rout

• (e1, i1) (e2, i2)……. (ek, ik)– 0 ≤ k ≤ n– ij {IFST, IINC, IOK, INOK }, 0 < j ≤ k

• IFST --- The first chunk of the file but not the last one.

• IOK --- The last chunk of the file.• IINC --- For all other chunks.• INOK ---- Something has gone wrong.

– In this case j = k and ek = * (no datum).

74

The Specification

• (ej, ij)

• For every 0 < j ≤ k, if ij INOK then ej = dj

– The datum delivered is the chunk that was sent.

• If n > 1 then i1 = IFST

– INOK is put out only if something at all was received.

• If 1 < j < k then ij = IINC

75

The Specification

• ik = IOK OR ik = INOK

– The last output must signal positive or negative termination.

• ik = IOK implies k = n.

– Successful transmission.

• ik = INOK implies k > 1.

– Unsuccessful only if something was received to start with.

76

The Specification

• If Sout = IOK then ik = IOK.

– Should we demand the converse too?

• If Sout = INOK then ik = INOK

• If Sout = IDK then k = n.

– ik = ?

• If k = 0 then– Sout = IDK iff n = 1.

– Sout = INOK iff n > 1.