Lecture 10 1
Practical matters+
Case studies
CS 5270 Lecture 10
Lecture 10 2
AU: 1 2 until 2
Lecture 10 3
DBMs – matrix view
Lecture 10 4
DBMs – halfspace view
Lecture 10 5
DBMs – halfspace view
Lecture 10 6
DBMs – halfspace view
Lecture 10 7
DBMs – graph view
Lecture 10 8
DBMs – graph view
Lecture 10 9
RTS, time passing and TA
Lecture 10 10
RTS, time passing and TA
Lecture 10 11
RTS, time passing and TA
Lecture 10 12
RTS, time passing and TA
Lecture 10 13
RTS, time passing and TA
Lecture 10 14
RTS, time passing and TA
Lecture 10 15
RTS, time passing and TA
Lecture 10 16
RTS, Time abstracted
Lecture 10 17
ZTS, time passing and TA
Lecture 10 18
ZTS, time passing and TA
Lecture 10 19
ZTS, time passing and TA
Lecture 10 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
Lecture 10 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
Lecture 10 22
Mutexes in ITRON
• When you create a Mutex in an ITRON system, you specify attributes in the mtxattr field:
TA_INHERIT (=2) priority inheritanceTA_CEILING (=3) priority ceiling
• The ceiling protocol in ITRON is a variant of that in class
Lecture 10 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…
Lecture 10 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…
Lecture 10 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
Lecture 10 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
Lecture 10 27
Giotto – Helicopter control
Lecture 10 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
Lecture 10 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/
Lecture 10 30
Modelling protocols…
Lecture 10 31
Modelling protocol with Spin…
Lecture 10 32
Modelling protocol with Spin…
Lecture 10 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) -> out!accept(i); in?next(o); chout!ack(o)
:: chin?nak(i) -> out!accept(i); chout!ack(o)
:: chin?err(i) -> chout!nak(o)
od
}
Lecture 10 34
Modelling protocol with Spin…• Add assertions in the PROMELA code for
reachability claims:
assert(maxbuffered=3);
• Convert LTL formula into Buchi automata for (negative) temporal claims…
Lecture 10 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.
Lecture 10 36
A(FG p) … spin –f “<>[]p”never { /* <>[]p */
T0_init:
if
:: ((p)) -> goto accept_S4
:: (1) -> goto T0_init
fi;
accept_S4:
if
:: ((p)) -> 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).
Lecture 10 37
Model without (and with) media
Lecture 10 38
Modelling mediaproctype medium( chan in, out )
{
byte typ;
int data;
do
:: in?typ,data ->
if
:: out!typ,data
:: out!err,0
fi
od
};
Lecture 10 39
Modelling mediachan 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 )
};
Lecture 10 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
Lecture 10 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
Lecture 10 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.
Lecture 10 43
I2C – detect START condition…
If SDA goes low while SCL is high…
Lecture 10 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 ( (SDAIN=1)&(SCLIN=1)&(AX SDAIN=0) ) -> AF and3gate1 )
Lecture 10 45
I2C – modelling in smv.
• When we try it out…
[hugh@pnp176-44 FormalVerification]$ NuSMV SMV-ofI2C-start-detector-parallel*** This is NuSMV 2.3.1 (compiled on Mon Apr 3 10:11:22 UTC 2006)*** For more information on NuSMV see <http://nusmv.irst.itc.it>*** or email to <[email protected]>.*** Please report bugs to <[email protected]>.-- specification (AG ((SDAIN = 1 & SCLIN = 1) & AX SDAIN = 0) -> AF and3gate1) is true[hugh@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 and3gate=START will be HIGH
Lecture 10 46
I2C – ROBDD: • ROBDD representation of
model• (Generated automatically from
within smv – don’t know what corresponds with what…)
Lecture 10 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
Lecture 10 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 !
Lecture 10 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.
Lecture 10 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.
Lecture 10 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.
Lecture 10 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.
Lecture 10 53
Sender Receiver
Sin SoutRout
K
L
F
B A
G
Lecture 10 54
Sender Receiver
Sin SoutRout
K
L
F
B A
G
(d1, d2, ,,,,dn) ; a file consisting of n chunks of data.
Lecture 10 55
Sender Receiver
Sin SoutRout
K
L
F
B A
G
{IOK, INOK, IDK }
Lecture 10 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.– Don’t know whether the transmission was successful or not.– This is due to asynchronous communication via a lossy channel.– Byzantine - agreement is impossible!
Lecture 10 57
Sender Receiver
Sin SoutRout
K
L
F
B A
G
(e1, i1) (e2, i2) ….(ek, ik)
Lecture 10 58
Sender Receiver
Sin SoutRout
K
L
F
B A
G
(e1, i1) (e2, i2) ….(ek, ik)(d1, d2, ,,,,dn)
Lecture 10 59
Rout
• (e1, i1) (e2, i2)……. (ek, ik)– 0 ≤ k ≤ n– ij 2 {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).
Lecture 10 60
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
Lecture 10 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 > 1.
– Unsuccessful only if something was received to start with.
Lecture 10 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 > 1.
Lecture 10 63
a
b
c
a
b
c
IOK
(a, FST) (b, INC) (C, OK)
Lecture 10 64
a
b
c
a
b
c
?
(a, FST) (b, INC) (C, OK)
Lecture 10 65
a
b
c
a
b
c
IDK
(a, FST) (b, INC) (C, OK)
Lecture 10 66
a
b
a
b
?
?
Lecture 10 67
a
b
a
b
INOK
(a, FST) (b, INC) (NOK, *)
Lecture 10 68
a
b
aINOK
(a, FST) (NOK, *)
Lecture 10 69
a
INOK
Lecture 10 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.
Lecture 10 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.
Lecture 10 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.
Lecture 10 73
Verification
• Using UPPAAL it was determined:– T1 > 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!
Lecture 10 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.
Lecture 10 75
Periodic Task
TSK
x = T x:=0
Lecture 10 76
Periodic Task Set
TSK1
x = T1 x:=0
TSK2
y = T2 y:=0
TSK3
z = T3 z:=0
Lecture 10 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.
Lecture 10 78
The Scheduling problem.
• TSKA = (S, S0, CL, INV, Tasks, label, !)– Label: S ----> 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.
Lecture 10 79
A non-schedulable automaton
A B(2, 2)
{x} C(3, 3.5)
x = 1
A, 0,
A, x > 0,
Lecture 10 80
A non-schedulable automaton
A B(2, 2)
{x} C(3, 3.5)
x = 1; {x}
A, 0,
A, x > 0,
B, 0, (2, 2)
B, 1, (1, 1)C, 0, (3, 3.5) (1, 1)
C, 1, (3, 2.5) (0, 0)
Lecture 10 81
A non-schedulable automaton
A B(2, 2)
{x} C(3, 3.5)
x = 1; {x}
A, 0,
A, x > 0,
B, 0, (2, 2)
B, 1, (1, 1)C, 0, (3, 3.5) (1, 1)
C, 0, (3, 2.5)
Lecture 10 82
A non-schedulable automaton
A B(2, 2)
{x} C(3, 3.5)
x = 1; {x}
A, 0,
A, x > 0,
B, 0, (2, 2)
B, 1, (1, 1)C, 0, (3, 3.5) (1, 1)
C, 0, ERROR
Lecture 10 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.