practical matters + case studies

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


Lecture 10 6


Lecture 10 7

DBMs – graph view

Lecture 10 8

DBMs – graph view

Lecture 10 9

RTS, time passing and TA

Lecture 10 10


Lecture 10 11


Lecture 10 12


Lecture 10 13


Lecture 10 14


Lecture 10 15


Lecture 10 16

RTS, Time abstracted

Lecture 10 17

ZTS, time passing and TA

Lecture 10 18


Lecture 10 19


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

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…

http://www.rtems.com/

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

http://embedded.eecs.berkeley.edu/giotto/

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…





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…





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…





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.

http://www.uppaal.com/

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

?


Lecture 10 65

a

b

c

a

b

c

IDK


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

practical matters + case studies

Documents