design of reactive systems -...

tele

Design of Reactive SystemsSummer 2001

Prof. Dr. Stefan LeueInstitute for Computer Science

Albert-Ludwigs-Universität Freiburg

[email protected]

Copyright © Stefan Leue 2001

© Stefan Leue 2001 teleDesign of Reactive Systems / Summer 2001 II - 2 © Stefan Leue 2001

State Machine based RequirementsSpecification

Part 2


States of Reactive Systems♦ State

8state is a function assigning to each variable a value over its domain– data variables

ivisible to outside world, or invisible– control

i"program counter"♦ Characterization of Reactive Systems

8states8environment events (stimuli), causing state transitions8 reaction events caused by transitions

♦ Reactive System Behaviour Specification8 infinite sequences of states and transitions8 transitions are instantaneous and discrete8while the system is in a state, the values of all variables remain

unchanged


Finite State Machines♦ Finite State Machines (FSMs) for the Specification of

Reactive Systems8states

– current control state– current state of all data variables

8state transition rules– before transition occurs

i1. controlc state before executing transitioni2. conditions for the executability of the transition

– after transition occurredi3. optional change of the environment statei4. new control state


Finite State Machines♦ Example: Beverage Vending Machine

state input output successor stateidle m - recrec s - selsel (true) d idle

sel (true) r idle

idle selrec?m ?s

!d

!r


Finite State Machines♦ Finite State Machine

8 letQ: finite set of statesq0 ∈∈∈∈ Q (initial state)I: an alphabet (input symbols)O with I ∩∩∩∩ O = ∅∅∅∅ : an alphabet (output symbols)A = I ∪∪∪∪ O (event alphabet)α: Q → Q a relationδ: Q x A → Q a relationρ: Q x I → O x Q a relation

8we call (Q, q0, α) a transition system

idle selrec




8we call (Q, q0, A, δ) a finite Moore machine

idle selrec?m ?s

!d

!r




8we call (Q, q0, I, O, ρ) a finite Mealey machine

idle rec?m/-

?s/!d

?s/!r


Finite State Machines♦ Finite State Machine Models

8Moore and Mealy machines are expressively equivalent (cf. [Hopcroftand Ullman])

8 the state machines considered here are non-deterministic, i.e., morethan one transition can be executable in any given state


Finite State Machines♦ Specification of Requirements

8what or how?

implementationFSMspecification

1

0

m s r m s d m s

idle selrec?m ?s

!d

!r



8what or how?


1

0

m s r m s d m s d m s r m s d m s r m

idle selrec?m ?s

!d

!r



8what or how?


1

0

m s r m s d m s d m s r m s d m s r m s d r

idle selrec?m ?s

!d

!r



8what or how?


1

0

d m s r m s d r m s d m s r m s d m s d m s r m s d

idle selrec?m ?s

!d

!r



8A = {m, s, d, r} describes an alphabet of externally observable events8 the FSM describes a mathematical model for the set of all admissible

event sequences– enumeration?

8acceptance criteria– is <m, s, d, m> an admissible event sequence?– s <m, s> an admissible event sequence?need to extend FSM model by acceptance criteria

idle selrec?m ?s

!d

!r


Nondeterministic Finite Automata♦ Nondeterministic Finite Automaton (NFA)

let8M = (Q, q0, A, δ) an FSM, and8F ⊆⊆⊆⊆ Q (we call F the set of all accepting states).We call N = (M, F) a nondeterministic finite automaton.

♦ Pathlet8N an NFAWe call the state sequence (q0, q1, .. , qk) a path of N iff

)))q),a,q)(((Aa((q 1iii

1k

0i

δ∈∈∃

+

−

=∀


Nondeterministic Finite Automata♦ Accepting Path

let8N a NFA8q = (q0, q1, .. , qk) a path over NWe call q accepting if qk ∈∈∈∈ F.

♦ Language acceptance8 from the set of accepting paths of N and the corresponding set of

transition labels one can infer the language LN that N accepts8example: vending machine VM accepts Lvm = (m s (r | d))*8Lvm represents all valid observable behaviours

idle selrec?m ?s

!d

!r


Why Automata Models♦ Why not use a general programming language

main (){ ...idle: c = nextevent();switch(c) { case ‘m’: goto rec; default : goto blocking }rec: c = nextevent();switch(c) { case ‘s’: goto sel; default : goto blocking; }sel: c = nextevent();switch(c) { case ‘d’: goto idle; case ‘r’: goto idle; default : goto blocking; }blocking: ...}

idle selrec?m ?s

!d

!r


Why Automata Models♦ Why not use a general programming language

8choice of language (C, C++, Java, XML, ...)?8overspecification / implementation bias

– what, not how– no valid implementation should be precluded

8most programming languages do not posses a (generally accepted)formal semantics


Limitations of FSMs♦ Limitations

8while FSMs form an important concept in behavior-oriented propertyspecification, their expressivness is too limited to be used in thespecification of more complex systems

8semantically extended variants are usually used in practicalspecification methods


Limitations of FSMs♦ L1: Missing Data Abstraction

8FSMs do not possess data variables8consequences

– variables over infinite data domains cannot be used– data values and changes to data values need to be coded into the

state space of the FSMiassume

* each of the i = 1, .., n variables in the system ranges overdomains of size si

* size of the state space

icombinatorial, exponential state space explosion due to datavariables

∏=

n

1iis



8example: multi-coin accepting, change-giving beverage vendingmachine



8example: dialing of 4-digit extension numbers


Limitations of FSMs♦ L2: Concurrent Composition

8example: 2-buffer producer-consumer system

Copyright © Prentice-Hall, 1993


Limitations of FSMs♦ L2: Concurrent Composition

8concurrent composition by constructing the cartesion product of thecomposed FSMs

8assumption– n system components (FSMs)– each of the i = 1, .., n system components has ki system states

8size of the statespace of composed system

8consequence:– state space size grows exponentially in the number of component

FSMs– combinatorial exponential state space explosion due to concurrent

composition

∏=

n

1iik


Limitations of FSMs♦ L3: Bounded Memory

8FSMs only possess a finite number of memory locations– consequence: counting only possible modulo constant, known

numbers– problem when modeling communication channels

ichannel size may be unknown at requirement specificationtime,

idetermining buffer size at requiremet specification time maybe undesirable (overspecification)

iconsequence* usage of finite abstractions of real system* question of soundness of abstraction


Limitations of FSMs♦ L4: Abstraction/Refinement

8missing abstraction and refinement of states and transitions8example: call model for plain old telephony system (POTS)

idle

on_hook

on_hook

on_hookon_hook

busy

dialtone

number

waiting

tone

calling

off_hook

audible_ring busy

ringing

conver-sation

ringing

on_hookoff_hook


Limitations of FSMs♦ L4: Abstraction/Refinement

8abstraction– group states that have common features– introduce group and multi-level transitions

idle

on_hook

on_hook

on_hookon_hook

busy

dialtone

number

waiting

tone

calling

off_hook

audible_ring busy

ringing

conver-sation

ringing

on_hookoff_hook


Limitations of FSMs♦ L5: Missing Composition and Synchronization

Mechanisms for Modelling of Concurrent Systems8 instantiation and termination of concurrent components8communication primitives

– point-to-point– multicast– broadcast– channels (queues, bags, …)

8synchronization– synchronous/asynchronous


Limitations of FSMs♦ L6: Finite Acceptance

8NFAs accept only finite execution sequences– Lvm = (m s (r | d))*

8properties of reactive systems need to be described in terms ofinfinite sequences

– examplesithe vending machine will infinitely often return to a state in

which it accepts moneyiif infinitely often money is inserted into the machine, the

machine will infinitely often either give a drink, or return themoney

8needed: acceptance of languages of infinite words– Lvm = (m s (r | d))ω


Limitations of FSMs♦ L7: Deficit in Real-Time Expressiveness

8 "if a drink will will not be selected within 15 secs after insertingmoney, the money will be returned"

8 requires a timed execution model, and the introduction of timevariables, clocks and timers


Limitations of FSMs♦ L8: Graphic Representation

8while the graphical representation of FSMs is suitable for thespecification of small systems, for complex systems FSMs are notuseful

8consequence of some of the previously mentioned limitations


Extended State Machine Models♦ Communicating Finite State Machines (CFSMs)

8groups of independent, concurrently executing state machines8communication and synchronization by message passing over

unbounded buffers8 inserts:

– concurrency– Promela

♦ ωωωω-Automata8automata accepting languages of words of infinite length

♦ Extended Finite State Machines (EFSMs)8data variables8predicates8operations

♦ Hirarchical Finite State Machines (HFSMs)8abstraction and refinement on states and transitions8concurrent states


CFSMs♦ Following [Brand and Zafiropulo]

8concurrent FSMs (≥2) + communication channels (=“protocol“)8every FSM represents a concurrent, communicating process with a

finite number of control states8every communication channel is

1. full-duplex,2. error-free,3. has a first-in-first-out service strategy4. has unbounded capacity(1. - 3. characterizes a perfect full-duplex channel)(question: how does one model an imperfect channel)

8one pair of channels (cij and cji) for each pair (i,j) of machines

M1

M2 M3


CFSMs♦ Formalization

8N: a positive integer8 i, j = 1, .. N: index over processes8 : N disjoint, finite sets, Qi denotes the state set of process I8 : N² disjoint sets, with (∀ i)(Aii = ∅ ), Aij denotes the message

alphabet for the channel i → j8δ: relation, determining, for each pair i, j the following functions:

Qi x Aij → QiQi x Aji → Qi

8 : tupel of initial states,

♦ Definition8we call a protocol

N

1iiQ=N

1j,iijA=

0iq ( )( )i0

i Qqi ∈∀

( )δ,A,q,Q ij0ii


CFSMs♦ Notation

8si ∈ Qi: state of process i8xij ∈ Aij: a message

– ?xij reception of a message– !yji sending of a message

8 f((si, .., sn)) = (f(si), .., f(sn))8x, y: message8X, Y: sequence of messages8x, xy, xY, xXY: concatenated sequences of messages


CFSMs♦ Example: A Sever Protocol (cf. [Brand and Zafiropulo])

8 Initially, both processes user and server are in states ready and idle,respectively. The user can send a request by a message REQ to theserver, which enters state service after receiving REQ. When finishedprocessing the request, the server sends a message DONE to theuser and goes back to state idle. Afer sending REQ, the user entersthe wait state and returns to ready when receiving DONE. In stateidle, the server indicates a fault to the user by sending an ALARMmessage. The user registers the fault and sends the server an ACKmessage. Upon receipt of ACK, the server returns to state ready.

ready

wait reg

idle

service fault

!REQ

?DONE!ACK

?ALARM ?REQ

!DONE?ACK

!ALARM

user server


CFSMs♦ Alternating Bit Protocol (cf., [Holzmann 91])

8simple protocol securing unreliable message channels8sender sends message msgn with n ∈ {0, 1} a sequence number8 receiver acknowledges with ackn8sender sets new sequence number at 1 + n mod 28 retransmission of current message when wrong sequence number

received8symmetric variant exists

!msg1

?ack0?ack1

?ack1 !msg0

?ack0

sender

?msg1!ack1

?msg0!ack0

receiver

s1

s2

r0

r1 r2


CFSMs♦ Semantics of a protocol?

8set of admissible state sequences♦ State of a protocol?

8sum of– local state of each of the 1 .. N processes, plus– state of all channels cij ∈ Aij*

ieach cij corresponds to a sequence of messages that havebeen sent, but not yet received

8we call this the global system state


CFSMs♦ How do we obtain the set of all computations of a

protocol, i.e., sets of sequences of global system states8 initially: all processes in qi

0 and all cij = ∅8system is in a current global system state s8state transition triggered by send and receive events

– send eventiadd a message to the tail of the corresponding message

queue (= channel)ichange the local system state of the sending process

– receive eventitake the message to be received from the head of the

message queueichange the local system state of the receiving process

8 leads into a new global system state s'


CFSMs♦ Global System State

8 let– P = a protocol– S = (S1, .. ,SN) an N-tuple of local process states– C an N² tuple

so that for all i, j: cij ∈ Aij*8we call (S, C) a global system state

( )δ,A,q,Q ij0ii

ε

ε=

N

1

N1

c

c

cc

COM

L


CFSMs♦ State Transition Relation

8 let P a protocol and G = {(S, C) | (S, C) is a global system state}8 |— : G → G is defined as follows

(S, C) |— (S’, C’) iff ∃∃∃∃ i, k, xik such that eithera) (S, C) and (S’, C’) are identical except for the following

exceptionssi’ = δ(si, !xik) (sending by i)cik’ = cikxik

orb) (S, C) and (S’, C’) are identical except for the following

exceptionssk’ = δ(sk, ?xik) (receiving by k)cik = xikcik’


CFSMs♦ Reachable Global System State

8 let– G⁰ the initial global system state of a protocol,– G a global system state of the same protocol,– |— the state transition relation of this same protocol, and– |—* denote the transitive closure of |—.

8We say that G is reachable ifG⁰ |—* G

♦ Paths and the language accepted by a protocol can bedefined through |— as it was done for NFAs


Insert: Event Ordering

♦ Lamport’s happened-before relation8Basic observations

– if two events happen in the same process pi, then they occurred inthe order in which pi observed them (c.f., the local happenedbefore relation →i)

– for any message passing, the send event occurs before thereceive event

8The HB (happened before) relation →– HB1: for any pair of events e and e’, if there is a process pi such

that e →i e’, then e → e’– HB2: for any pair of events e and e’ and for any message m, if e =

send(m) and e’ = receive(m), then e → e’– HB3: if e, e’ and e’’ are events and if e → e’ and e’ → e’’, then e→ e’’ (HB is identical to its transitive closure)

8HB defines a partial order

© Pearson Education 2001


Insert: Event Ordering♦ Lamport’s happened-before relation

8Consequence– for any tuple e → e’

ieither e and e’ are direct or indirect successors in the sameprocess, or

ithere are events e’’ and e’’’ and a message m such that e →e’’ and e’’’ → e’ and e’’ = send(m) and e’’’ = receive(m)

– e → e’ does not necessarily express causality between e and e’’8Concurrency

– for all e, e’, e not → e’ and e’ not → e, then we say that e and e’’are concurrent (also written as e || e’)

© Pearson Education 2001


CFSMs♦ Modeling of Concurrency

8CFSM model models linear sequences of global system states (seeeither .. or in the definition of |—)

8How do we model that two states or events are concurrent?– assuption: if two events E1 are E2 concurrent, then one assumes

that each ordering of these events must be possible.– Hence, the system must allow both of the following execution

sequences:{<…, E1, …, E2, …>, <…, E2, …, E1, …>, …}

8 Interleaving Semantics


CFSMs♦ Expressiveness

8Theorem: CFSMs are Turing-complete– proof idea (other approaches are possible…):

ithree processes: P1, P2, P3,isimulate the control of the TM in the state machine of P2iuse P1 and the channels c21 und c12 to simulate the left half

tape, and use P3 and c23 and c32 to simulate the right half tapeinote: alle cik have unbounded length

8Consequences– global state space has unbounded size– undecidable problems:

iterminationiwill some communication event ever be executed?iis some system state reachable?iis the protocol deadlock free?


CFSMs♦ Expressiveness

8a channel cik ist bounded if there is a constant h such that for everyreachable global system state (S, C) the length of cik is bounded by aconstant h

– for arbitrary protocols the boundedness of a channel isundecidable

– for many practical protocols, however, single or all channels arebounded

8 the previously mentioned reachability and deadlock problems aredecidable for protocols for which all channels are bounded.

8Consequence– finite approximation / abstraction– introduction of CFSM-Models with bounded channel capacities to

enable complete formal analysis8however: danger of introducing deadlocks when using bounded

channels


Insert: Promela♦ Protocol (oder Process) Meta Language

8concurrent programming/modeling language8guarded command - type8application domain

– reactive systems modelingiin particular message based, concurrent systems

* amongst others, protocols♦ SPIN Model Checker

8simulation and validation of Promela models8XSPIN: graphical interface to SPIN8developed by Gerard Holzmann, Bell Laboratories, Lucent

Technologies, USA


Insert: Promela♦ Web Site

8 for Promela/SPIN– http://netlib.bell-labs.com/netlib/spin/whatisspin.html

iaccess to software* open source C code* uses gcc, Tcl/Tk, dotty, ...* compiles under Solaris, Linux and Windows* Windows binaries available

8Documentation and literature references– [Holzmann 91]– [Holzmann 95]– [Holzmann 97]


Insert: Promela♦ Goal

8originally: modeling language for communication protocols– “A model represents and abstraction that contains only those

aspects of a design that are relevant to the properties one isinterested in proving.”

– “A model contains things that are typically not part of animplementation” (cf. [Holzmann 95])

8 recently application in a much more diverse spectrum of areas– various communication protocols (RLP, GIOP, …)– Rotterdam storm surge barreer control software– Philips HiFi control system– Bosch/Blaupunkt CAM protocol– NASA PathFinder– JAVA code und bytecode model checking– avionics control logic– telecommunications services (Lucent PathStar, AT&T Distributed

Feature Composition)– business workflow modeling


Promela Language Definition♦ Objects

8concurrent processes (proctype)8variables over finited domains8message channels of fixed bounded length8all objects must be declared before using them

♦ Scope8processes

– always global8variables and channels

– global or local for some process


Promela Language Definition♦ Processes

init{

printf(“it works\n”)

}

8init: instatiates a process8printf: built-in function


Promela Language Definition♦ Process abstraction: proctype

proctype my_x (byte x)

{

printf("my x is: %d\n", x)

}

init

{

run my_x (0);

run my_x (1)

}


Promela Language Definition♦ Instatiation of a process instance at system start-up

time

proctype my_x (byte x){printf("my x is: %d\n", x)

}active proctype main(){run my_x (0);run my_x (1)

}


Promela Language Definition♦ Replicated instances of one proctype

active [2] proctype my_x()

{

printf("my _pid is: %d\n", _pid)

}


Promela Language Definition♦ Execution Semantics

8Guarded-command language (à la Dijkstra)

begin loop

g1 -> s1g2 -> s2…gn -> sn

end loop

8semantics if more than one guard is true?8how to implement sequential execution?


Promela Language Definition♦ Execution Semantics

8 in Promela:– a statement is always either executable, or blocked

iin sequential programming language

while a not = bdood;

corresponds in Promela to

(a == b);

or

(a == b)->


Promela Language Definition♦ Conditions of Executability

8condition: when condition evaluates to true8assignment, printf: always8run: when a new process instance can be generated (number of

concurrent proctype instances depends on implementation, usually256)

8 read from an asynchronous channel: when a message of theexpected type is at the head of the denoted input queue

8write into an asynchronous channel– always, if the channel is not full– for a full channel blocking/non-blocking, depending on run-time

parameter8 read/write from/to a synchronous channel

– whenever communication partner is ready for the handshake


Promela Language Definition♦ More than one concurrently executable statement

8when simulating, run-time scheduler decides randomly aboutselection

8only one statement will be executed at a time– exceptions: atomic, d_step, synchronous communication


Promela Language Definition♦ Control Flow

8case decisionif

:: (a != b) -> option1

:: (a = b) -> option2

fi;

– blocks, until at least one of the statements following a :: isexecutable

– random decision if more than one statement is executable– special guard else can be used once per if .. fi

iexecutable, if no other guard is true



8 infinite loopdo

:: (count != 0) ->

if

:: count = count + 1

:: count = count - 1

fi

:: else -> break

od

– similar to if .. fi– infinite repetition until break is reached, or goto is executed



8 jumps

proctype Euclid (int x, y) {do :: (x > y) -> x = x-y :: (x < y) -> y = y-x :: else -> goto doneoddone:

skip }


Promela Language Definition♦ Data Types

Type Domainbit or bool {0, 1}byte 0 .. 255short -2¹⁵ .. 2¹⁵-1int -2³¹ .. 2³¹-1

♦ Type Declarationstype name = expression

type name [constant] = expression

8expression: default8[constant]: declaration of an array


Promela Language Definition♦ Petersen's Mutual Exclusion

bool turn, flag[2];

byte ncrit;

active [2] proctype user()

{

assert(_pid == 0 || _pid == 1);

again:

flag[_pid] = 1;

turn = _pid;

(flag[1 - _pid] == 0 || turn == 1 - _pid);

ncrit++;

assert(ncrit == 1); /* critical section */

ncrit--;

flag[_pid] = 0;

goto again

}


Promela Language Definition♦ Data Structures

typedef Field {short f = 3;byte g }

typedef Msg {byte a[3];int fld1;Field fld2;bit b };

Msg message;…message.a[2] = message.fld2.f + 12…proctype me (Msg z) {…}…run me(message)


Promela Language Definition♦ Multi-Dimensional Arrays

typedef Array {byte el[4] };

Array a[4];…a[i].el[j]


Promela Language Definition♦ Expressions

8all expressions must be free of side-effects8conditional expression

(expr1 -> expr2 : expr3)

– can be used in assignments


Promela Language Definition♦ Message Channels

8arbitrary, finite number of uni-directional channels8message types

mtype{ack, req, done, alert}will be translated in byte values 1, 2, 3, 4

8 finite capacity, known at run-timechan qname = [16] of {mtype, byte, bool}orchan qname = [16] of {byte, byte, bool}or#define QUSIZE…chan qname = [QUSIZE] of {mtype, byte, bool}

8send/receiveqname!expr1,expr2,expr3qname?var1,var2,var3– executability


Promela Language Definition♦ Insert: Communication Primitives

8 types of communication primitives– non-blocking: execution never delays invoker– blocking: otherwise

8when are send/receive primitives blocking or non-blocking?– asynchronous message passing: buffers with unbounded storage

capacity (sender may overtake receiver an unbounded number ofsteps)isender never blocks

– synchronous message passing: no bufferingisend primitive blocks until receiver ready to receive message

– buffered message passing: buffer with bounded, finite capacity,known at compile-timeisender blocks on full bufferisender does not block on full buffer (entails message loss)

8 in Promela?8Cf. [Andrews and Schneider, Ch. 4.2]


Promela Language Definition♦ Communication Primitives

8selective receive: match of the first component of the message to bereceived– qname?cons1, var2, cons3

ireceived value must match the value of the locally definedconstant

– qname?mtype1, var2, cons3ireceived message type must match the locally defined

message type8querying the current length of a channel

len(qname)empty(qname)full(qname)

8determining the head element of a channel– only possible for asynchronous channels– not syntactically valid:

((a -> b) && qname?msg0) -> …– valid variant

((a -> b) && qname?[msg0]) -> qname?msg0; …


Promela Language Definition♦ Communication Primitives

8protection against a full channel!full(qname) -> qname!msg0

8synchronous communication (rendez-vous)mtype = {req}chan port = [0] of {mtype}active proctype sender(){port!req; port!req}

active proctype receiver(){port?req}

8behaviour of...chan port = [1] of {mtype}chan port = [10] of {mtype}?


Promela Language Definition♦ Atomicity of Composed Expressions

8semantic problems– qname?[msg0] -> qname?msg0– !full(qname) -> qname!msg0

8solution: atomic– atomic {qname?[msg0] -> qname?msg0}– atomic {!full(qname) -> qname!msg0}– atomic { /*swap a and b */

tmp = b;b = a;a = tmp }

– semantic conditionsistatements within atomic can be non-deterministiciatomicity broken if a statement blocksiwhen control returns to the interrupted process, atomicity of

interrupted statement is restored at point of interruptioniduring synchronous rendez-vous, control transferred to

receiver if it receives within atomic , return is possible8more efficient variant: d_step

– deterministic code required within d_step


Promela Language Definition♦ Concurrent Process Initialization

init {atomic {run user(s_to_u, u_to_s);

run server(u_to_s, s_to_u)}

}


Promela Language Definition♦ Procedural Abstraction: inline

inline recv(cur_msg, cur_ack, lst_msg, lst_ack)

{

do

:: receiver?cur_msg -> sender!cur_ack; break /* accept */

:: receiver?lst_msg -> sender!lst_ack

od;

}

active proctype Receiver()

{

do

:: recv(msg1, ack1, msg0, ack0);

recv(msg0, ack0, msg1, ack1)

od

}


Promela Language Definition♦ Example: AB-Protocol ([Holzmann 00])

mtype = { msg0, msg1, ack0, ack1 };chan sender = [1] of { mtype };chan receiver = [1] of { mtype };

inline phase(msg, good_ack, bad_ack){ do :: sender?good_ack -> break :: sender?bad_ack :: timeout -> if :: receiver!msg; :: skip /* lose message */ fi; od }

inline recv(cur_msg, cur_ack, lst_msg, lst_ack){ do :: receiver?cur_msg -> sender!cur_ack; break /* accept */ :: receiver?lst_msg -> sender!lst_ack od;}

active proctype Sender(){ do :: phase(msg1, ack1, ack0); phase(msg0, ack0, ack1) od}

active proctype Receiver(){ do :: recv(msg1, ack1, msg0, ack0); recv(msg0, ack0, msg1, ack1) od}


Promela Language Definition♦ Timeout

8no concept of real-time im Promelatimeout -> …

timeout becomes executable, when no other statement in the wholePromela model is executable

– possible use: pre-emption of deadlock situations

proctype watchdog (){ do

:: timeout -> guard!reset od }


Promela Language Definition♦ Escape Sequence

{ P } unless { E }

(where P and E are arbitrary Promela fragments)8semantics

– the first guard of E will be evaluated after every execution of astatement in P

– P is terminated as soon as E becomes executable, in which caseE will be executed immediately

– E will be omitted in case it does not become executable before Pterminates


Promela Language Definition♦ Final Remarks

8only process recursion– danger of stack overflow

8very limited procedural abstraction (inline)8Promela doesn't know an environment

– all models must be closed


ωωωω-Automata♦ Acceptance condition for NFAs

8an NFA accepts a word a ∈ A* iff by reading the word the automatonhalts after a finite number of steps in an accepting state

8 reactive systems are characterized by event- or state sequences ofinfinite length, i.e., words a ∈ Aω


ωωωω-Automata♦ Acceptance conditions for words in Aωωωω

8Options– 1. finite acceptance

ithe automaton accepts a prefix of a ∈ Aω

– 2. looping acceptanceithe automaton has an infinite execution when reading the

word– 3. repeating acceptance

i2. + the set of states that the automaton reaches infinitelyoften satisfies an additional accepance condition

8 Note– (ab*)ω can be expressed by 3., but neither by 1. nor by just 2.kann

-> usage of 3. (Büchi acceptance condition)


ωωωω-Automata♦ Büchi Automaton

8definition as for NFA8acceptance condition

– an infinite word a ∈ Aω will be accepted by a Büchi Automaton iffthe automaton reaches at least one of the states in theacceptance set F infinitely often when reading a

idle selrec?m ?s

!d

!r


ωωωω-Automata♦ Büchi-Automaton

8 letQ: finite set of statesq0 ∈∈∈∈ Q (called initial state)A a finite set of event symbols (called event alphabet)δ: Q x A → Q a relationF ⊆⊆⊆⊆ Q (called acceptance set)

8we call M = (Q, q0, A, δ, F) a Büchi-Automaton


ωωωω-Automata♦ Acceptance Condition

8 let σ = s0, s1, … a sequence,– σ[i] = si– |σ| denotes the length of σ (ω, if σ infinite)

8 let– a sequence of events– a sequence of states of M

8we call ρ a run on σ iff– ρ[0] = q0, and– (∀ i: 0 ≤ i ≤ |σ|)(ρ[i] ∈ δ(ρ[i-1], σ[i-1]))

8 let– ΓM(σ) = {ρ ∈ | ρ is a run on σ}– INFM(σ) = {q ∈ Q | q appears infinitely often in any element ofΓM(σ)}

8σ is accepted by M iffINFM(σ) ∩ F ≠ ∅

AMω∈σ

QM

ω∈ρ

AMω


ωωωω-Automata

♦ Example8 requirement

whenever an a will be observed, eventually a b will also beobserved

8 translation into event sequencesin every execution sequence of m, i.e., in every word of , any

occurrence of a must be followed by an occurrence of b

communicationmedium

Msender receiver

a b

(=DATreq) (=DATind)

AMω

S1 S2

a

b

b, c a, c

Q = {S1, S2}, q0 = S1, F = {S1}


ωωωω-Automata♦ Acceptance of finite execution sequences by Büchi

automata8assumption

– the final state will be repeated infinitely often


ωωωω-Automata♦ Example

8 if the self-test routine of the beverage vending machine detects afailure, then the money that has been inserted will be returned andthe automaton will permanently remain in a state in which it displaysthe message “sorry, out of order”.

8F = {frei, sorry}

idle selrec?m ?s

!d

!r

error

sorry

!r

*

?f

?f?f


ωωωω-Automata♦ Literature

8 [Thomas]8 [Alpern and Schneider]


Extended Finite State Machines (EFSMs)♦ An EFSM is an FSM extended by

8data abstraction (variables)8operations on variables8symbolic (explicit) states8boolean transition conditions


Extended Finite State Machines (EFSMs)♦ A (symbolic) state of an EFSM represemts an

equivalence class of system states


Extended Finite State Machines (EFSMs)♦ Formalisation

– S: set of symbolic states– D: n-dimensional linear space, each Di is a data domain– V = {Π, v1, .., vn}: finite set of programme variables

iΠ: control variable over domain Si{v1, .., vn} ∈ D: data variables

– O: finite set of output signal types– I: finite set of input signal types– T: S x 2D x I → S x 2D x O– C: an initial condition over S x 2D

8We call E = (S, D, V, O, I, T, C) an extended finite state machine(EFSM)

♦ Remarks8state is a function s: V → 2D x 2D8Since Di are potentially unbounded, EFSMs have an infinite state set8EFSMs are Turing-complete


CEFSMs♦ Communicating Extended Finite State Machines

8Foundation for many practical specification and modelling languages– Specification and Description Language (SDL)

iStandardised by ITU-T in Recommendation Z.100– Estelle

iISO standardised– ROOM / UML-RT


Hierarchical Finite State Machines


Hierarchical Finite State Machines♦ Basic Concepts

8state abstraction and refinement– geometric area inclusion

8Higraphs (cf. [Harel 88])– combine the concepts of

iVenn diagrams (geometric inclusion)ihyper graphs (edges connecting more than two nodes)

8multi-level transitions– e.g.: S1- scan_digits - S2

8Group transitions– e.g.:S4 - S1

8Statecharts notation (cf. [Harel 87])– state diagrams– depth– orthogonality (concurrent composition of states)– broadcast communication


idle

Hierarchical Finite State Machines♦ Abstraction

8group states that have common features8 introduce group transitions and multi-level transitions

on_hook

on_hook

on_hookon_hook

busy

dialtone

number

waiting

tone

calling

off_hook

audible_ring busy

ringing

conver-sation

ringing

on_hookoff_hook




idleringing

conver-sation

ringing

on_hook on_hook

on_hook

busy

dialtone

number

waiting

tone

calling

off_hook

audible_ring busy

originator

off_hook

off_hook


idleringing

conver-sation

ringing

on_hook



on_hook

audible_ring

originator

off_hook

off_hook


Hierarchical Finite State Machines♦ HCEFSM-based CASE-tools and notations

8Rhapsody (iLogix), UML8Rose-RT (Rational), UML-RT (formerly: ROOM)

♦ URLs8 iLogix: www.ilogix.com8Rational: www.rational.com


Zusammenfassung: Erweiterungen von FSMs♦ L1: Missing Data Abstraction

8extended finite state machines (EFSMs)

♦ L2: Concurrent Composition8decompositions into sets of communicating finite state machines8EFSMs

♦ L3: Bounded Memory8EFSMs

♦ L4: Abstraction/Refinement8Hierarchical state machines (HFSMs, Statecharts)


Zusammenfassung: Erweiterungen von FSMs♦ L5: Missing Composition and Synchronization

Mechanisms for Modelling of Concurrent Systems8composition of CFSMs

♦ L6: Finite Acceptance8automata on infinite words (ω-Automata)

♦ L7: Deficit in Real-Time Expressiveness8 timed automata8 timer

♦ L8: Graphic Representation8anything that reduces visual complexity

– HFSMs– EFSMs– CFSMs

© Stefan Leue 2001 teleDesign of Reactive Systems / Summer 2001 II -100

© Stefan Leue 2001

References♦ [Alpern and Schneider] B. Alpern and F. Schneider,

Recognizing Safety and Liveness, DistributedComputing, 2:117-126, 1987

♦ [Brand] D. Brand and P. Zafiropoulo, On CommunicatingFinite State Machines, Journal of the ACM (20) 2, April1983, S. 323-342

♦ [Chang et al.] E. Chang, Z. Manna and A. Pnueli, TheSafety-Progress Classification

♦ [Ghezzi] C. Ghezzi et al., Fundamentals of SoftwareEngineering, Prentice-Hall, 1993

♦ [Harel 87] D. Harel, Statecharts: A Visual Formalism forComplex Systems, Science of Computer Programming 8(1987), S. 231-274

♦ [Harel 88] D. Harel, On Visual Formalisms, CACM,Volume 31, Number 5, S. 514-530


© Stefan Leue 2001

References♦ [Holzmann 91] G. Holzmann, Design and Validation of

Computer Protocols, Prentice-Hall, 1991♦ [Hopcroft and Ullman] J. Hopcroft and J. Ullman,

Introduction to Automata Theory, Languages, andComputation, Addison-Wesley, 1979

♦ [Lamport 77] L. Lamport, Proving the Correctness ofMultiprocess Programs, IEEE Transactions on SoftwareEngineering, Vol. 3, 1977, pp. 125 - 143

♦ [Manna and Pnueli 90] Z. Manna and A. Pnueli, AHierarchy of Temporal Properties, Proc. of the 9th ACMSymposium on Principles of Distributed Computing,1990

♦ [Thomas] W. Thomas, Automata on Infinite Objects, in:J. van Leeuwen (ed.), Handbook on TheoreticalComputer Science, Vol. B, Elsevier, 1990


© Stefan Leue 2001

Bibliographic References for Promela/SPIN♦ [Andrews and Schneider] G. Andrews and F. Schneider, Concepts and Notations for

Concurrent Programming, Computing Surveys, Vol. 15, No. 1, March 1983♦ [Clarke, Grumberg and Peled] E. Clarke, O. Grumberg and D. Peled, Model Checking,

MIT Press, Cambridge, 1999♦ [Holzmann 91] G. Holzmann, Design and Validation of Computer Protocols, Prentice-

Hall, 1991♦ [Holzmann 93] Tutorial: Design and Validation of Protocols, Computer Networks and

ISDN Systems, Vol. 25, No. 9, pp. 981-1017, 1993♦ [Holzmann 95] G. Holzmann, The Verification of Concurrent Systems, unpublished

manuscript, AT&T Inc., 1995♦ [Holzmann 97] G. Holzmann, The Model Checker SPIN, IEEE Transactions on

Software Engineering, Vol. 23, No. 5, May 1997♦ [Holzmann 00] G. Holzmann, personal communication, 2000.♦ [Natarajan and Holzmann] V. Natarajan and G. Holzmann, Outline for an Operational-

Semantics Definition for PROMELA, in: J.-C. Grégoire, G. Holzmann and D. Peled(eds.), The SPIN Verification System - Proceedings of the Second Workshop on theSPIN Verification System, DIMACS Series in Discrete Mathematics and TheoreticalComputer Science, Vol. 32, AMS, 1996. (Postscript available)

design of reactive systems -...

Documents