Networks of TA Specification Logic Case Studies

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.
Both the set of states and actions are infinite.
TSTTS
TTS
Semantics
Time abstraction
Finite set of actions but infinite set of states.
TA
Quotient via stable equivalence relation of
finite index.
QTA
Both states and actions are finite sets.
11
The Reductions.
Both the set of states and actions are infinite.
TSTTS
TTS
Semantics
QTA is computed directly from TTS (a finite
object) s is reachable in TTS iff the
corresponding state is reachable in QTA.
Finite set of actions but infinite set of states.
TA
QTA
Both states and actions are finite sets.
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
Req-1
Arbiter
PR1
Grt-1
Resource
Req-2
PR2
Grt-2
i1 Process 1 is idle w1 Process 1 is
waiting u1 Process 1 is using the resource. AP
i1, w1, u1, i2, w2, u2
19
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
20
L(so) i1, i2
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
L(s2) i1, u2
L(s5) w1,w2
21
L(so) i1, i2
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
L(s3) ?
22
L(so) i1, i2
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
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 y and y are formulas then so are
• ? y
• y ? y.
• If y is a formula then so is EX(y)
• If y is a formula then so are
• EF(y)
• AF(y).

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
• y a CTL- formula s ? S
• K, s y
• y (holds) is satisfied at s.

27
Semantics

• CTL- p ?y y1 ? y2 EX(y)
• EF(y) AF(y)
• K (S, S0, R, AP, L) L ? 2AP s ? S
• K, s p iff p ? L(s).
• K, s ? y iff it is NOT the case K, s y
• K, s y1 ? y2 iff
• K, s y1 OR K, s y2.

28
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
L(s2) i1, u2
L(s5) w1,w2
K, s5 w1 ? K, s0 w2?
29
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
L(s2) i1, u2
L(s5) w1,w2
K, s5 ? i1 ? K, s0 w2 ? i1?
30
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
L(s2) i1, u2
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(y) there exists s such that
• s ? s (R(s, s)) and
• K, s y
• s has a successor state s at which y holds.

32
off
AP B, G, R
S0
off
on
on
S2
S1
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
  p s0, s1, s2, ,si, si1, s.t
• s s0
• si ? si1 (R(si, si1)) for every i.
• p(i) si the i th element of p.
• Assume for convenience that for every s there is
  s such that R(s, s).

34
Semantics

• CTL p ?y y1 ? y2 EX(y)
• EF(y) AF(y)
• K (S, S0, R, AP, L) L ? 2AP s ? S
• K, s EF(y) iff there exists a path
• p s0, s1, from s and k ? 0 such
• that K, p(k) y

35
EF(y)
y
36
EF(y)
s
s1
sj
y
sk
37
Semantics

• CTL p ?y y1 ? y2 EX(y)
• EF(y) AF(y)
• K (S, S0, R, AP, L) L ? 2AP s ? S
• K, s AF(y) iff for every path
• p s0, s1, from s there exists k ? 0 such
  that K, p(k) y

38
AF(y)
? y
y
y
y
y
39
0
Req2
3
Req1
Grt2
5
4
Grt1
Ret1
7
0
M, 0 AF(u1) ?
40
0
Req2
3
Req1
Grt2
5
4
Grt1
Ret1
7
0
M, 0 AF(EF(u1)) ?
41
Derived Operator

• AX(y) ?EX(?y)
• It is not the case there exists a next state at
  which y does not hold.
• For every next state y holds.

AX(y)
y
y
y
42
Derived Operators

• K, s AG(y)
• AG(y) ?EF(?y)
• It is not the case there exists a path p (from s)
  and k ? 0 such that
• K, p(k) y
• For every path p (from s) and every k 0
• K, p(k) y

43
AG(y)
y
y
y
y
y
?y
44
Derived Operators

• K, s EG(y)
• EG(y) ?AF(?y)
• It is not the case that for every path p from s
  there is a k ? 0 such that K, p(k) ?y.
• There exists a path p from s such that, for every
  k ? 0
• K, p(k) y.

45
EG(y)
y
y
y
y
y
46
CTL- Model Checking

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

47
L(so) i1, i2
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
L(s2) i1, u2
L(s5) w1,w2
K, s0 AX(w1) ?
48
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
K, s0 AX(w1 ? w2) ?
49
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
K, s0 EF(u2) ?
50
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
K, s0 EF(u1 ? u2) ? u1 ? u2 ? (? u1 ? ?
u2)
51
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
K, s0 AG(u2 ? u2) ?
52
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
K, s0 AG( ?(u2 ? u2)) ?
53
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
K, s0 EG(? u2) ?
54
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
K, s0 AF(? u2) ?
55
s0
Req1
Req2
Ret2
s3
s1
Ret1
Grt1
Grt2
Req2
Req1
s5
s4
s2
Ret1
Ret2
Grt2
Grt1
Req2
Req1
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 y, a CTL formula.
• Determine
• K, s y
• 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 lt c x gt 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
Sin
Rout
Sout
Sender
Receiver
G
F
K
L
B
A
68
(d1, d2, ,,,,dn) a file consisting of n chunks
of data.
Sin
Rout
Sout
Sender
Receiver
G
F
K
L
B
A
69
IOK, INOK, IDK
Sin
Rout
Sout
Sender
Receiver
G
F
K
L
B
A
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.
• Dont know whether the transmission was
  successful or not.
• This is due to asynchronous communication via a
  lossy channel.
• Byzantine agreement is impossible!

71
(e1, i1) (e2, i2) .(ek, ik)
Sin
Rout
Sout
Sender
Receiver
G
F
K
L
B
A
72
(e1, i1) (e2, i2) .(ek, ik)
(d1, d2, ,,,,dn)
Sin
Rout
Sout
Sender
Receiver
G
F
K
L
B
A
73
Rout

• (e1, i1) (e2, i2). (ek, ik)
• 0 k n
• ij ? IFST, IINC, IOK, INOK , 0 lt 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 lt j k, if ij ? INOK then ej dj
• The datum delivered is the chunk that was sent.
• If n gt 1 then i1 IFST
• INOK is put out only if something at all was
  received.
• If 1 lt j lt 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 gt 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 gt 1.