Macchine gerarchiche per il tempo reale: l’approccio V IOLIN 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 1 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 WIRTES Pisa 2/Luglio/2007 2 1
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 3 System Modelling � Architectural level � system = collection of interacting state machines � Behavioural level � The dynamic behaviour of each machine is specified by a statechart WIRTES Pisa 2/Luglio/2007 4 2
Architectural level: A console/device system model start Console Device info • 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 5 Behavioural specification Proc c0 {//show}[1] start? Stop {//op1}[4] Step1 Step2 timer ? [20] Display start! {//op2}[4] c1 {//op3}[2,4] Step3 info![t, ] 8 End {//reset}[2] info? [0,20] Device machine Console machine WIRTES Pisa 2/Luglio/2007 6 3
Commands � State transitions are labeled by guarded commands with timing constraints : → ∈ ∈ ∪ ∞ ≤ G C [ t , t ] t R , t ( R ), t t min max min max min max 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) WIRTES Pisa 2/Luglio/2007 7 Behavioural specification I/O Commands : � ch ( msg ) ! [t1,t2], ch ( var ) ? [t3,t4] at rendezvous: var=msg ta tb ta+t1 tb+t3 ta+t2 tb+t4 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 � WIRTES Pisa 2/Luglio/2007 8 4
Hierarchical features (1) � Only or -decomposition is admitted (as in ROOM & UML-RT) � State ports can be used for abstracting the internal of 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 9 Hierarchical features (2) [init actions] State transitions as configuration switches: A1 → A2 ⇒ Cs ={Top,A,A1} → Cd ={Top,A,A2,A21} WIRTES Pisa 2/Luglio/2007 10 5
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 11 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 A1 → A2 Top Top A B A B A2 A1 B2 B1 A2 A1 B2 B1 A21 A22 B11 B12 A21 A22 B11 B12 modular flat WIRTES Pisa 2/Luglio/2007 12 6
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: e 0 (d 0 )@t 0 e 1 (d 1 )@t 1 e 2 (d 2 )@t 2 … � RTL-like assertions : when <event> [ + <delay> ] { time (ch,index) assert( <RTL_expression> ) value (ch,index) } functions WIRTES Pisa 2/Luglio/2007 13 The V IOLIN toolbox (1) WIRTES Pisa 2/Luglio/2007 14 7
The V IOLIN 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 15 Current work � Supporting model checking of Violin systems, by mapping a model in a product of Timed Automata of U PPAAL � Using Violin for automating the translation � Enabling both discrete time or dense time � Extending Violin with different runtime systems and target languages WIRTES Pisa 2/Luglio/2007 16 8
U PPAAL translation using dense time timer, action, ch, reset, disable ⇒ urgent channels g 0 -> timer?[d1] g 0 && clk==d1 timer? s0 g 1 -> ch?[l,u] g 1 && clk>=l && clk<=u ch? “dream” s0 v=ch_v clk=0 g2 && clk==0 clk<=d2 g 2 -> cmd?[d2] clk>=d2 action? cmd g[0] && a[0]==E g 0 -> timer?[d1] timer? e_s0 s0 g 1 -> ch?[l,u] g[1] && a[1]==E ch? “reality” s0 v=ch_v reset! status=S0, disable! g[2] g 2 -> cmd?[d2] clk>=l[2] update() cmd clk<=u[2] WIRTES Pisa 2/Luglio/2007 17 Flat machine translation � Exploits priorities of latest U PPAAL 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 WIRTES Pisa 2/Luglio/2007 18 9
Console translation reset? reset? resetAct() resetAct() c==kd && allDisabled() disable? s c==kd && !allDisabled() c==ke && !allEnabled() dis? en? kd=nextDisable() ke=nextEnable() c<=ke && c<=kd c0 e_c0 c0 reset! status=C0, timer ? [20] updateB() start! a[1]==E a[0]==E timer? start! reset! c1 c1 e_c1 status=C1, updateB() info? [0,20] a[0]==E info? WIRTES Pisa 2/Luglio/2007 19 Priority handler � Simple automaton always ready en! to synchronize on timer! � en or dis with a clock handler � timer with a TA modeling the dis! behavior of a machine chan priority default< dis <info,timer,start,disable…< en WIRTES Pisa 2/Luglio/2007 20 10
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 timer? [4,6] s1 2 ≤ clk ≤ 4 a[0] ch! -> S2, reset clock handler clk=4 ke=6 kd=5 a[0]=E a[1]=E s0 4 ≤ clk ≤ 5 a[1] ch! -> S2, … ch! [2,5] timer? -> S1, … s2 clk=5 ke=6 kd=6 a[0]=E a[1]=D 5 ≤ clk ≤ 6 timer? -> S1, … WIRTES Pisa 2/Luglio/2007 21 Transition mapping rules (1) Internal command g -> { cmd }[d1,d2] s0 e_s1 g[t] clk>=l[t] general cmd disable! s0 s1 clk<=u[t] g -> { cmd }[0] s0 e_s1 g[t] instantaneous disable! cmd s0 s1 WIRTES Pisa 2/Luglio/2007 22 11
Transition mapping rules (2) g[t] && a[t]==E g[t] && a[t]==E g -> ch( expr )![lb,ub] g -> ch(v)?[lb,ub] e_s1 ch! e_s1 s0 s0 ch? ch_v= expr s0 s1 s0 s1 v=ch_v Input command Output command g -> timer?[d] g -> timer?[lb,ub] g[t] && a[t]==E e_s1 s0 s0 e_s1 g[t] && a[t]==E timer? s0 s1 s0 s1 timer? g[t] && a[t]=D Timer command simple Timer command WIRTES Pisa 2/Luglio/2007 23 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 WIRTES Pisa 2/Luglio/2007 24 12
Recommend
More recommend
