Practical matters Case studies

1
Practical mattersCase studies

• CS 5270 Lecture 10

2
AU ?1 ? ?2 until ?2
3
DBMs matrix view
4
DBMs halfspace view
5
DBMs halfspace view
6
DBMs halfspace view
7
DBMs graph view
8
DBMs graph view
9
RTS, time passing and TA
10
RTS, time passing and TA
11
RTS, time passing and TA
12
RTS, time passing and TA
13
RTS, time passing and TA
14
RTS, time passing and TA
15
RTS, time passing and TA
16
RTS, Time abstracted
17
ZTS, time passing and TA
18
ZTS, time passing and TA
19
ZTS, time passing and TA
20
Today

• RTOS in the field
• PCP in TRON, RMS in RTEMS
• Giotto
• LTL MC using spin
• CTL MC using smv
• Model examples
• BRP
• Scheduling

21
TRON/ITRON

• ITRON is the most common OS in the world (!).
• Japanese, 1984, embedded systems, detailed docs
  mostly in Japanese.
• Documentation and standards are open, although
  implementations may not be.
• http//www.sakamura-lab.org/TRON/ITRON/home-e.html
  

22
Mutexes in ITRON

• When you create a Mutex in an ITRON system, you
  specify attributes in the mtxattr field
• TA_INHERIT (2) priority inheritance
• TA_CEILING (3) priority ceiling
• The ceiling protocol in ITRON is a variant of
  that in class

23
RTEMS

• Open source project, hopes to be of similar
  quality to commercial RTOS.
• Uses standard interfaces such as POSIX/ITRON
• http//www.rtems.com/
• Multitasking, event-driven, priority-based
  pre-emptive scheduling.
• Optional rate-monotonic scheduling
• Priority inheritance
• Portable, micros, embedded

24
RTEMS RMS scheduling

• General structure turns a task into RMS task
• rate_monotonic_create(taskname,period)
• while (true)
• if ( rate_monotonic_period(period,30)TIMEOUT
  )
• break
• performTask()
• Scheduler uses RMS scheduling

25
Giotto

• Environment, standards, and language for
  implementing embedded hard real-time systems.
• Use language to specify periodic tasks (a
  time-triggered architecture)
• http//embedded.eecs.berkeley.edu/giotto/
• API centers on reactive tasks, communicating with
  ports
• Each task is scheduled, the compiler finding
  suitable schedules

26
Giotto

• Compiler generates E-code and S-code for an
  abstract time-triggered architecture
• Various systems that interpret/run the code
  (distribution uses a Java interpreter)
• Example of a helicopter control system, running
  on a strong-arm system, code developed in Giotto,
  using HelyOS on the web site

27
Giotto Helicopter control
28
Today

• RTOS in the field
• PCP in TRON, RMS in RTEMS
• Giotto
• LTL MC using spin
• CTL MC using smv
• Model examples
• BRP
• Scheduling

29
Spin, Xspin, PROMELA

• spin is the name of an LTL model checker
• xspin is a graphical interface for it
• PROMELA is the model checking language it uses.
• Developed by Gerard Holzmann at Bell Labs
• http//www.spinroot.com/

30
Modelling protocols
31
Modelling protocol with Spin
32
Modelling protocol with Spin
33
Modelling protocol with Spin

• (Promela do..od is do forever)
• proctype protocol( chan in, out, chin, chout )
• byte o,i
• in?next(o)
• do
• chin?ack(i) -gt out!accept(i) in?next(o)
  chout!ack(o)
• chin?nak(i) -gt out!accept(i) chout!ack(o)
• chin?err(i) -gt chout!nak(o)
• od

34
Modelling protocol with Spin

• Add assertions in the PROMELA code for
  reachability claims
• assert(maxbuffered3)
• Convert LTL formula into Buchi automata for
  (negative) temporal claims

35
Modelling protocol with Spin

• To assert an LTL temporal formula/claim on a
  model, we have to show that the language of the
  model (all executions) is included in the
  language of the claim.
• It is easier to claim the negative It is easier
  to prove that the intersection of the language of
  the model and the claim is empty.
• Hence NEVER claims in PROMELA.

36
A(FG p) spin f ltgtp

• never / ltgtp /
• T0_init
• if
• ((p)) -gt goto accept_S4
• (1) -gt goto T0_init
• fi
• accept_S4
• if
• ((p)) -gt goto accept_S4
• fi
• If the product of the model and the negation of
  this automaton is empty (i.e. no acceptance),
  then A(FG p).

37
Model without (and with) media
38
Modelling media
proctype medium( chan in, out ) byte typ
int data do in?typ,data -gt
if out!typ,data
out!err,0 fi od
39
Modelling media
chan Ain 2 of byte chan MedtoA 2
of byte, int atomic run protocol(
Ain, Aout, MedtoA, AtoMed ) run protocol(
Bin, Bout, MedtoB, BtoMed ) run medium(
AtoMed, MedtoB ) run medium( BtoMed, MedtoA
) run application( Aout, Ain ) run
application( Bout, Bin )
40
Today

• RTOS in the field
• PCP in TRON, RMS in RTEMS
• Giotto
• LTL MC using spin
• CTL MC using smv
• Model examples
• BRP
• Scheduling

41
NuSMV and smv

• McMillan (1992) wrote smv a CTL model checker,
  making sources public
• More recently, NuSMV is being developed furhter,
  and now includes LTL, and other extensions
  including SAT solvers, BMC
• Now has an extensive history

42
Hardware and software together

• The tool smv has been particularly useful for
  hardware design checking, although it is similar
  to all the other style systems we have seen
  specifying a model in an automata style useful
  for any responsive software system (protocols)
• For a change give a hardware verification example
  electronic circuit to detect the START condition
  for I2C signalling.

43
I2C detect START condition

• If SDA goes low while SCL is high

44
I2C modelling in smv.

• MODULE mainVAR
• inv1 boolean
• inv2 boolean
• inv3 boolean
• or2gate1 boolean
• and2gate1 boolean
• and3gate1 boolean
• SCLIN boolean
• SDAIN boolean
• ASSIGN
• inv1 !SCLIN
• inv2 !SDAIN
• inv3 !or2gate1
• next( or2gate1 ) inv1 and2gate1
• and2gate1 inv2 or2gate1
• and3gate1 inv3 SCLIN inv2
• SPEC
• ( AG ( (SDAIN1)(SCLIN1)(AX SDAIN0) ) -gt AF
  and3gate1 )

45
I2C modelling in smv.

• When we try it out
• hugh_at_pnp176-44 FormalVerification NuSMV
  SMV-ofI2C-start-detector-parallel
• This is NuSMV 2.3.1 (compiled on Mon Apr 3
  101122 UTC 2006)
• For more information on NuSMV see
  lthttp//nusmv.irst.itc.itgt
• or email to ltnusmv-users_at_irst.itc.itgt.
• Please report bugs to ltnusmv_at_irst.itc.itgt.
• -- specification (AG ((SDAIN 1 SCLIN 1)
  AX SDAIN 0) -gt AF and3gate1) is true
• hugh_at_pnp176-44 FormalVerification
• Verifies that it is always true that if SDA and
  SCL were both HIGH, and that if the next state
  had SDA LOW, then eventually and3gateSTART will
  be HIGH

46
I2C ROBDD

• ROBDD representation of model
• (Generated automatically from within smv dont
  know what corresponds with what)

47
Today

• RTOS in the field
• PCP in TRON, RMS in RTEMS
• Giotto
• LTL MC using spin
• CTL MC using smv
• Model examples
• BRP
• Scheduling

48
Outline

• The Bounded Retransmission Protocol.
• The TTA model
• The verification issues
• Task arrival patterns and their schedulability.
• Periodic, aperiodic, sporadic tasks.
• More sophisticated patterns captured by timed
  automata.
• Timed automata can also be used for schedulabilty
  analysis !

49
Case Studies

• Available from the UPPAAL home page (Examples).
• Bang Olufsen Audio/Video Protocol.
• Bang Olufsen Power Down Protocol.
• Commercial Field Bus Protocol.
• Gear Box Controller.
• Multimedia Stream.

50
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.

51
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.

52
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.

53
Sin
Rout
Sout
Sender
Receiver
G
F
K
L
B
A
54
(d1, d2, ,,,,dn) a file consisting of n chunks
of data.
Sin
Rout
Sout
Sender
Receiver
G
F
K
L
B
A
55
IOK, INOK, IDK
Sin
Rout
Sout
Sender
Receiver
G
F
K
L
B
A
56
The values of Sout

• IOK
• All the acknowledgments were received.
• All the chunks were transmitted successfully and
  were received by the receiver.
• INOK
• Some acks failed to arrive in time the MAX count
  of retransmissions for that chunk was exhausted
  without receiving an ack.
• IDK
• The acks 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!

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

• (e1, i1) (e2, i2). (ek, ik)
• 0 k n
• ij 2 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).

60
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

61
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.

62
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.

63
IOK
a
a
b
b
c
c
(a, FST) (b, INC) (C, OK)
64
?
a
a
b
b
c
c
(a, FST) (b, INC) (C, OK)
65
IDK
a
a
b
b
c
c
(a, FST) (b, INC) (C, OK)
66
?
a
a
b
b
?
67
INOK
a
a
b
b
(a, FST) (b, INC) (NOK, )
68
INOK
a
a
b
(a, FST) (NOK, )
69
INOK
a
70
The Sender Module

• S reads the file (with n chunks d1, d2,, dn) and
  sets the retry counter to 0.
• It then starts sending over the chunks one by
  one
• Its sets a timer T1 and the first frame into the
  channel K. A frame is of the form (b1, b2, ab,
  d).
• b1 (b2) indicates whether or not this chunk is
  the first (last) one. ab is the alternating bit.
  d is the chunk.
• ab is used to distinguish between a retry and a
  fresh chunk.

71
The Sender Module

• After sending the frame (b1, b2, ab, d), the
  sender module waits for an acknowledgment or a
  time-out.
• If an ack. is received in time then T1 is reset.
• The next frame (b1, b2, 1-ab, d) is sent or
  (if b2 1 in the previous round), it signals
  Rout IOK.
• If it times out, the frame (b1, b2, ab, d) is
  resent after resetting the timer and incrementing
  the retry counter.
• If MAX is exceeded in the process of incrementing
  the counter, the transmission is broken off it
  signals Rout INOK or Rout IDK depending on n
  and how many ack messages were received.

72
Verification

• Premature time-outs do not occur.
• In case of an abort, Sender waits sufficiently
  long so that the Receiver has reacted to the
  abort before starting a new file.

73
Verification

• Using UPPAAL it was determined
• T1 gt 2 TD
• TD the transmission delay of the channel.
• SYNCH ? TR ? (2 MAX T1) 3 TD
• Both the verifier and the simulator had to be
  used!

74
Task Scheduling

• Basic Idea
• Classical scheduling
• Periodic
• Aperiodic
• Sporadic
• Use timed automata to describe task arrivals.
• Some of the control states have tasks associated
  with them.
• Whenever a state is entered, its task is added
  to the ready queue.

75
Periodic Task
TSK
x0
x T
76
Periodic Task Set
TSK1
TSK2
TSK3
x0
x T1
y0
y T2
z0
z T3
77
The Task Arrival Model
TSK (c, d)
TSK (c, d)
G X
c computation time d relative deadline Whenever a
task is released, it is added to the ready
queue. Scheduling is done according to some
policy (EDF) uniprocessor model.
78
The Scheduling problem.

• TSKA (S, S0, CL, INV, Tasks, label, !)
• Label S ----gt TASKS
• TSTSKA (S, S0, R)
• R ? S S
• conf (s, V, Q)
• Q The current state of the ready queue.
• Q ERROR if the ready queue contains a task that
  has missed (will miss) its deadline according to
  the scheduling policy.

79
A non-schedulable automaton
A
C (3, 3.5)
B (2, 2)
x
x 1
A, 0, ?
A, x gt 0, ?
80
A non-schedulable automaton
A
C (3, 3.5)
B (2, 2)
x
x 1 x
A, 0, ?
A, x gt 0, ?
C, 1, (3, 2.5) (0, 0)
B, 0, (2, 2)
B, 1, (1, 1)
C, 0, (3, 3.5) (1, 1)
81
A non-schedulable automaton
A
C (3, 3.5)
B (2, 2)
x
x 1 x
A, 0, ?
A, x gt 0, ?
C, 0, (3, 2.5)
B, 0, (2, 2)
B, 1, (1, 1)
C, 0, (3, 3.5) (1, 1)
82
A non-schedulable automaton
A
C (3, 3.5)
B (2, 2)
x
x 1 x
A, 0, ?
A, x gt 0, ?
C, 0, ERROR
B, 0, (2, 2)
B, 1, (1, 1)
C, 0, (3, 3.5) (1, 1)
83
The Scheduling Problem

• Given TSKA, determine if ERROR state is
  reachable.
• This problem can be solved (using UPPAAL) for
  both preemptive and non-preemptive schedules.
• TIMES is a specialized tool for schedulability
  analysis.