Macchine gerarchiche per il tempo reale: lapproccio V IOLIN Angelo - - PDF document

1

WIRTES Pisa 2/Luglio/2007 1

Macchine gerarchiche per il tempo reale: l’approccio VIOLIN

Angelo Furfaro & Libero Nigro

Laboratorio di Ingegneria del Software www.lis.deis.unical.it Dipartimento di Elettronica Informatica e Sistemistica Università della Calabria I-87036 Rende (CS) a.furfaro@deis.unical.it, l.nigro@unical.it

WIRTES Pisa 2/Luglio/2007 2

Related approaches

Existing methods for reactive systems based on

statecharts, e.g.

STATEMATE ROOM UML-RT

Despite the powerful modelling constructs available,

time management in these methods was felt not completely satisfactory for real time systems

2

WIRTES Pisa 2/Luglio/2007 3

Hierarchical Communicating Real-Time State Machines

An executable formalism which

Is an extension of CRSM – Communicating

Real-Time State Machines, originally proposed by Alan Shaw and centred on flat state machines

Embodies a form of distilled statecharts to

control state explosions during modelling

WIRTES Pisa 2/Luglio/2007 4

System Modelling

Architectural level

system = collection of interacting state machines

Behavioural level

The dynamic behaviour of each machine is

specified by a statechart

3

WIRTES Pisa 2/Luglio/2007 5

Architectural level: A console/device system model

info

Console Device

start

• CSP-like typed channels, linking compatible i/o ports
• Distributed model of concurrency

⇒ machines are units of modularity and concurrency and share no data

• Closed specification

WIRTES Pisa 2/Luglio/2007 6

Behavioural specification

Display Proc Step1 Step2 Step3 End Stop

start? {//reset}[2] {//op3}[2,4] {//op2}[4] {//op1}[4] info![t, ] {//show}[1] 8

c0

info? [0,20] timer ? [20] start!

c1

Device machine Console machine

4

WIRTES Pisa 2/Luglio/2007 7

Commands

State transitions are labeled by guarded commands with timing

constraints: where C can be: (i) an I/O command, ch!(expr), ch?(x) (ii) a timer command, timer(x)?[t] (iii) an internal command, action [d1,d2]

[t]≡[t,t] [0,∞] (default for io-command and internal command) [0] (default for internal command duration)

max min max min max min

), ( , ] , [ t t R t R t t t C G ≤ ∞ ∪ ∈ ∈ →

WIRTES Pisa 2/Luglio/2007 8

Behavioural specification

• I/O Commands:

ch(msg)![t1,t2], ch(var)?[t3,t4] at rendezvous: var=msg rendezvous is only possible in the intersection interval [ta+t1,ta+t2]∩[tb+t3,tb+t4], and at earliest time tb+t3

• An impossible rendezvous can deadlock a machine

ta tb ta+t1 tb+t3 ta+t2 tb+t4

5

WIRTES Pisa 2/Luglio/2007 9

Hierarchical features (1)

Only or-decomposition is admitted (as in ROOM &

UML-RT)

State ports can be used for abstracting the internal

• f a macro state

History (H), deep history (H*) connectors and group

transitions supported

Configuration = set of states in a path from root to a

leaf (or basic) state in which a machine finds itself

State transitions as a switch between two

configurations

Synchronous one-to-one instead of event

broadcasting

WIRTES Pisa 2/Luglio/2007 10

Hierarchical features (2)

State transitions as configuration switches: A1→A2 ⇒ Cs={Top,A,A1} → Cd={Top,A,A2,A21} [init actions]

6

WIRTES Pisa 2/Luglio/2007 11

Operational semantics (1)

Event-driven executor centred on interleaved interpretation of

concurrency

At each step the executor considers the proposed set, i.e. the set of enabled and

ready transitions in all the machines

selects a next event with minimum occurrence time

(Earliest Time First). In case of multiple candidates, next is chosen non deterministically

removes from the proposed set all the enabled and ready

transitions associated with states which will be abandoned after next execution (revoked set); finally

executes next which results in one or two simultaneous

state transitions (rendezvous) and clock advancement; new events, corresponding to reached states, are added to the proposed set, and the control loop repeated

WIRTES Pisa 2/Luglio/2007 12

Operational semantics (2)

The proposed/revoked sets depend upon flat vs modular

semantics, which define in a different way the scope for a state transition

Top A A2 A21 A22 A1 B2 B1 B B11 B12 Top A A2 A21 A22 A1 B2 B1 B B11 B12

flat modular A1→A2

7

WIRTES Pisa 2/Luglio/2007 13

Temporal testing by assertions

Properties of a system (safety, end-to-end timing, etc.)

can be checked during prototyping/simulation of a system specification, based on

recorded Time stamped Event Histories (TEHs) of

channel communications: e0(d0)@t0 e1(d1)@t1 e2(d2)@t2 …

RTL-like assertions:

when <event> [ + <delay> ] { assert( <RTL_expression> ) }

time(ch,index) value(ch,index) functions

WIRTES Pisa 2/Luglio/2007 14

The VIOLIN toolbox (1)

8

WIRTES Pisa 2/Luglio/2007 15

The VIOLIN toolbox (2)

Graphical editing capabilities rely on jDraw, a developed

reusable framework for building domain specific graphical editors

Customisable runtime support (control engine) enabling

both prototyping (with assertion checking) and real-time

• execution. Execution modes exploit a common data

representation of an HCRSM system

For timing predictability, memory for states, events,

channel data, etc. is statically pre-allocated and reused at runtime

Code generation is currently targeted to Java Assertions handled as special-case machines XML externalization of a project or a single machine

WIRTES Pisa 2/Luglio/2007 16

Current work

Supporting model checking of Violin systems, by

mapping a model in a product of Timed Automata of UPPAAL

Using Violin for automating the translation Enabling both discrete time or dense time Extending Violin with different runtime systems

and target languages

9

WIRTES Pisa 2/Luglio/2007 17

UPPAAL translation using dense time

“dream” “reality” timer, action, ch, reset, disable ⇒ urgent channels

g[0]&& a[0]==E g[2]

s0

s0

g0-> timer?[d1] g2-> cmd?[d2] g1-> ch?[l,u]

e_s0 reset! status=S0, update() timer? g[1] && a[1]==E ch? v=ch_v disable! clk>=l[2] cmd clk<=u[2] g0&& clk==d1 timer?

s0

s0

g0-> timer?[d1] g2-> cmd?[d2] g1-> ch?[l,u]

clk=0 g1 && clk>=l && clk<=u ch? v=ch_v g2 && clk==0 action? clk>=d2 cmd clk<=d2

WIRTES Pisa 2/Luglio/2007 18

Flat machine translation

Exploits priorities of latest UPPAAL versions For each flat machine M a couple of TA are introduced:

an automaton corresponding to M behavior a “clock handler” that keeps track of the time elapsed

in the current state of M and updates the enabling/disabling status of transitions leaving current state of M

The two “synergic” TA share one clock Clock handler is reset by M before entering a new

state (timing constraints data structures l, u & a updated)

Clock handler is disabled when M executes an

internal command

An additional global TA for priority handling is used

10

WIRTES Pisa 2/Luglio/2007 19

Console translation

c0

info? [0,20] timer ? [20] start!

c1 c1 e_c1 c0 e_c0 a[0]==E info? a[1]==E timer? a[0]==E start! reset! status=C1, updateB() reset! status=C0, updateB() s c<=ke && c<=kd disable? c==kd && !allDisabled() dis? kd=nextDisable() reset? resetAct() reset? resetAct() c==kd && allDisabled() c==ke && !allEnabled() en? ke=nextEnable()

WIRTES Pisa 2/Luglio/2007 20

Priority handler

Simple automaton always ready

to synchronize on

en or dis with a clock handler timer with a TA modeling the

behavior of a machine

timer! dis! en!

chan priority default<dis<info,timer,start,disable…<en

11

WIRTES Pisa 2/Luglio/2007 21

Timing constraints and clock handler

clk=0 ke=2 kd=5 a[0]=W a[1]=W clk=2 ke=4 kd=5 a[0]=W a[1]=E 2≤clk≤4 ch!

• > S2, reset clock handler

clk=4 ke=6 kd=5 a[0]=E a[1]=E 4≤clk≤5 ch!

• > S2, …

timer?

• > S1, …

clk=5 ke=6 kd=6 a[0]=E a[1]=D 5≤clk≤6 timer?

• > S1, …

s0

timer? [4,6] ch! [2,5]

s1 s2

a[0] a[1]

WIRTES Pisa 2/Luglio/2007 22

Transition mapping rules (1)

Internal command

g[t] clk>=l[t] disable!

g -> {cmd}[d1,d2]

s0 s1

cmd s0 e_s1 clk<=u[t] g[t] disable! cmd

g -> {cmd}[0]

s0 s1 s0 e_s1 general instantaneous

12

WIRTES Pisa 2/Luglio/2007 23

Transition mapping rules (2)

Input command Output command Timer command Timer command simple

g[t] && a[t]==E ch? v=ch_v

g -> ch(v)?[lb,ub]

s0 s1 s0 e_s1 g[t] && a[t]==E ch! ch_v=expr

g -> ch(expr)![lb,ub]

s0 s1 s0 e_s1 g[t] && a[t]==E timer? g[t] && a[t]=D

s0 s1

s0 e_s1

g -> timer?[lb,ub]

g[t] && a[t]==E timer?

s0 s1

s0 e_s1

g -> timer?[d] WIRTES Pisa 2/Luglio/2007 24

Hierarchical machine flattening

(state unfolding)

For each level l add clock clkM[l] For each state s introduce: a variable h[path(s)] a committed location e(s) and a location m(s)

(committed if s is not a leaf)

a transition from e(s) to m(s) updating the parent

history and resetting clkM[level(s)]

a transition from m(s) to e(d), where d is the default

substate of s

13

WIRTES Pisa 2/Luglio/2007 25

Flattening (shallow history)

For each state s entered with shallow history

introduce:

a committed location he(s) for each child state q of s add:

a transition from he(s) to e(q) with guard

h[path(s)]==path(q)

a transition from he(s) to m(s) with guard h[path(s)]==-1

both resetting clkM[level(s)]

WIRTES Pisa 2/Luglio/2007 26

Flattening (deep history)

For each state s entered with deep history

introduce:

a committed location dhe(s) for each child state q of s add: a transition from dhe(s) to e(q) with guard

h[path(s)]==path(q) if q is a leaf

a transition from dhe(s) to dhe(q) with guard

h[path(s)]==path(q) if q is not a leaf

a transition he(s) to m(s) with guard h[path(s)]==-1

all resetting clkM[level(s)]

14

WIRTES Pisa 2/Luglio/2007 27

Flattening (transition unfolding)

For each transition t from s to d:

1.

Introduce a boolean variable gt initialized to false modelling the guard of t Let r=e(d) or he(d) or dhe(d) [depends on the type of d] Let

2.

For each state q in src(t):

• add a transition originating from m(q)
• augment the action with the evaluation of gt

Let

1.

The destination of transition(s) introduced in step 2 is:

r if a new committed location e(t) otherwise

2.

If

add a transition from e(t) to r updating the histories of the states in and resetting their level clocks

{

φ = ) (t enter

{ }

) ( ) ( | ) ( u leaf s descendant u u t src ∧ ∈ =

{ }

) ( ) ( | ) ( s ancestor u d ancestor u u t enter ∉ ∧ ∈ = φ ≠ ) (t enter ) (t enter

WIRTES Pisa 2/Luglio/2007 28

Hierarchical Device machine

Display Proc Step1 Step2 Step3 End Stop

start? {//reset}[2] {//op3}[2,4] {//op2}[4] {//op1}[4] info![t, ] {//show}[1] 8

15

WIRTES Pisa 2/Luglio/2007 29

Device translation

e_display c[0]<=u[0][0] display h_proc c[1]<=u[1][0] c[1]<=u[1][0] proc_end c[1]<=u[1][0] e_proc_end proc_step2 e_proc_step3 proc_step3 e_proc_step2 c[1]<=u[1][0] proc_step1 e_proc_step1 e_proc stop e_stop a[0][0]==E info! a[0][0]==E info! a[0][0]==E info! a[0][0]==E info! c[0]>=l[0][0] disable[0]! reset[1]! status[1]=NONE, updateB(1) h[PROC]==PROC_END reset[0]! status[0]=PROC, updateB(0) h[PROC]==PROC_STEP3 reset[0]! status[0]=PROC, updateB(0) h[PROC]==PROC_STEP2 reset[0]! status[0]=PROC, updateB(0) h[PROC]==PROC_STEP1 reset[0]! status[0]=PROC, updateB(0) h[PROC]==-1 disable[1]! c[1]>=l[1][0] disable[1]! reset[1]! h[PROC]=status[1]=PROC_END, updateB(1) c[1]>=l[1][0] disable[1]! reset[1]! h[PROC]=status[1]=PROC_STEP3, updateB(1) c[1]>=l[1][0] reset[1]! h[PROC]=status[1]=PROC_STEP2, updateB(1) reset[0]! status[0]=DISPLAY, updateB(0) c[1]>=l[1][0] disable[1]! reset[1]! h[PROC]=status[1]=PROC_STEP1, updateB(1) reset[0]! status[0]=PROC, e=true,x=0, updateB(0) a[0][0]==E start? reset[1]! status[1]=NONE, updateB(1) reset[0]! status[0]=STOP, e=false,x=0, updateB(0)

WIRTES Pisa 2/Luglio/2007 30

Model checking the Console/Device system

Every time state Proc is entered, state Stop will

eventually be reached:

Device.Proc --> Device.Stop (***)

Satisfaction of this property depends on the value of

constant t

If t>0, the property holds If t==0, it is not verified because machine Device can

engages an unbounded number of synchronizations through channel status before executing the next processing step

16

WIRTES Pisa 2/Luglio/2007 31

Bounded-liveness (1)

The execution of the four processing steps takes at most k

time units

Model decoration: Introduce a boolean variable enable and an UPPAAL

clock x

Upon entering state Proc, enable is set to true and x is

reset

enable is set to false when entering state Stop Property specification: A[] Device.enable imply Device.x<=k Let u be lowest value of k for which the property is

satisfied, u is the upper bound on the completion of processing activities

WIRTES Pisa 2/Luglio/2007 32

• The value of t influences that of u:

t in [1, 4] u=17 t in [5,12] u=15 t>12 u=14

• For t>12 communications on channel status never happen.
• This was also checked by asking the UPPAAL verifier if state

Display is eventually reached:

E<> Device.Display The verifier found this property satisfied only for values of t

less than or equals 12

Bounded-liveness (2)

17

WIRTES Pisa 2/Luglio/2007 33

Future work

Enhancing Violin so as to hide the underlying

Uppaal model checker

Tuning modelling&verification to implementation, by

adding a concept of deadline to internal commands, e.g. with an EDF scheduler with pre-emption on a single cpu system. Some experience carried out using discrete-time

Porting in RTSJ a prototype implementation of a

custom real-time EDF scheduler, based on L4 microkernel and C++

Extending the approach to distributed context

WIRTES Pisa 2/Luglio/2007 34

Time Petri Nets M&V

Modelling and analysis of time-dependent systems

using Time Petri Nets augmented by inhibitor arcs

Structural translation of TPNs in Uppaal, which

enables an efficient yet scalable approach to schedulability analysis

Distributed simulation tool which makes it possible

to exploit temporal uncertainty in a TPN model so as to achieve high performance and “accurate” analysis

• f large models

18

WIRTES Pisa 2/Luglio/2007 35

Sigle UPPAAL TA for TPN transitions

Deposit Withdraw U_Firing Firing x<=I[ID][1] Disabled enabled(ID) && I[ID][1]<0 end_fire! x=0 enabled(ID) && I[ID][1]>=0 end_fire! x=0 !enabled(ID) end_fire! end_fire! deposit(ID) !enabled(ID) end_fire? x=0 !enabled(ID) end_fire? x=0 x>=I[ID][0] fire! x=0,withdraw(ID) x>=I[ID][0] fire! x=0,withdraw(ID) enabled(ID) && I[ID][1]<0 end_fire? x=0 enabled(ID) && I[ID][1]>=0 end_fire? x=0

end_fire! Starter

WIRTES Pisa 2/Luglio/2007 36

Schedulability analysis

[0,1] t8 [0,1] t7 [0,2] t6 [0,1] t5 [1,2] t4 [2,4] t3 [1,2] t2 [1,3] t1 [0,1] t0 p11 p10 p9 p8 p7 p6 p5 p4 p3 p2 p1 p0

Transition firings sequences (tasks): t0σt4t5t6 with: σ=t1t2t3 or t1t3t2 or t3t1t2 t3t1t2t0σt4t5σ1mσ2nt6 (with loops) σ1=t7t1t2t4t5, σ2=t8σt4t5 FMS

19

WIRTES Pisa 2/Luglio/2007 37

Decorator automaton

d12345 d13245 d1234 d1324 d123 d132 d12 d13 d31245 d3124 d312 d31 d1 d3 d0 d123456 d132456 d312456 d fire[7]? fire[7]? fire[8]? fire[8]? fire[8]? fire[7]? fire[6]? fire[5]? fire[4]? fire[3]? fire[6]? fire[5]? fire[4]? fire[2]? fire[6]? fire[5]? fire[4]? fire[2]? fire[3]? fire[2]? fire[1]? fire[1]? fire[3]? fire[0]?

WIRTES Pisa 2/Luglio/2007 38

Schedulabity analysis of transition firings

E<> Decorator.d312456 Decorator.d --> Decorator.d312456 || Decorator.d132456 || Decorator.d123456 A[] Decorator.d312456 imply z>=lower_bound A[] Decorator.d312456 imply z<=upper_bound … A[] Decorator.d123456 imply z<=55 A[] Decorator.d123456 && M[10]==0 && M[11]==0 imply z>=18

20

WIRTES Pisa 2/Luglio/2007 39

Extensions to sequence matching problems

First transition can occur multiple times in the

sequence pattern σ whose schedulability analysis must be investigated

The decorator may have already recognized a prefix

• f the sequence and now detects an unexpected

transition

Decorator as NDA which is translated into an

equivalent DA that for sequence-matching conserves the same number of states

Buffers of clocks can be introduced to help

schedulability analysis