• No results found

A Process Algebraic Description of a Temporal Wireless Network Protocol

N/A
N/A
Protected

Academic year: 2020

Share "A Process Algebraic Description of a Temporal Wireless Network Protocol"

Copied!
18
0
0

Loading.... (view fulltext now)

Full text

(1)

Proceedings of the

Fourth International Workshop on Formal Methods

for Interactive Systems

(FMIS 2011)

A Process Algebraic Description of a Temporal Wireless Network

Protocol

Colm Bhandal, Melanie Bouroche and Arthur Hughes

17 pages

Guest Editors: Judy Bowen, Steve Reeves

Managing Editors: Tiziana Margaria, Julia Padberg, Gabriele Taentzer

(2)

A Process Algebraic Description of a Temporal Wireless Network

Protocol

Colm Bhandal1∗, Melanie Bouroche1and Arthur Hughes1

1School of Computer Science & Statistics Trinity College, Dublin, Ireland

bhandalc@tcd.ie http://www.scss.tcd.ie/

Abstract: The problem of coordination is central to research in robotics, automat-ically guided vehicles, autonomous cars, unmanned aerial vehicles, and any other areas in which autonomous agents of any kind operate concurrently. This paper fo-cuses on one particular model of coordination, namely Comhord´u. The contribution of this work is a formalisation of the existing model in precise mathematical terms. This formalisation extends our understanding of the model and provides a basis for future work such as the formal verification of model properties, e.g. system safety.

Keywords: Process calculus, Temporal, Protocol, Model, Wireless, Mobile agent, System, Ad-hoc network.

1

Introduction

The problem of coordination is central to research in robotics [16, 26], automatically guided vehicles [8], autonomous cars [4], unmanned aerial vehicles [2], and any other areas in which autonomous agents of any kind operate concurrently. Of interest here are systems of mobile autonomous agents, mobility here referring to physical movement in space. Coordination in this setting is defined in [6] as “the management of interactions both amongst entities, and between entities and their environment, towards the production of a result.”

The Comhord´u model is a coordination model for the class of systems comprised of mobile entities communicating over an unreliable wireless network. The model was developed in [6] and [7] as an approach to coordination in a system of mobile agents that differed from the traditional consensus-based approaches [21,14,11,9] and other approaches [12,27]. Within the model is the notion of a safety constraint, which is specified for a particular system and denotes a property that should never be violated by that system. Also included in the model is a description of how entities should act to maintain this safety constraint, i.e. a protocol entities must follow.

This paper strives towards a formalisation of the Comhord´u model. It is the first such attempt: all work on Comhord´u e.g. [6, 7] prior to this has been informal. The contribution of such a formalisation if manifold. As stated in [28], a motivation for using formal specification is “to add precision, to aid understanding, and to reason about properties of a design.” Precision & understanding go hand in hand. An imprecise model or design of some system is difficult to comprehend and may have many interpretations due to its inherent ambiguities. This lack of

(3)

understanding will most likely lead to the design being incorrectly implemented, perhaps even to the point of system failure. Further to increasing our understanding of a problem, formalisation allows existing mathematical tools such as model checkers, e.g. [5], to be employed towards the assertion of certain system properties.

Our present understanding of Comhord´u is certainly enhanced as a direct result of this formal-isation. The process of building a formal model of Comhord´u has uncovered within the informal model ambiguous concepts, hidden assumptions and under specified behaviours, none of which were obvious prior to this work. These issues are resolved here via the introduction of modi-fications and extensions to the model. Furthermore, while pre-existing model descriptions are predominantly English-based, this description employs mathematical functions and a process calculus [23] with formally defined rules. This adds an air of precision to the model. Finally, a process algebraic description such as this one offers the future possibility of the specification of system properties in a formal property logic. It is also likely that this formal model can be trans-lated, somewhat approximately, into the language of a model checker which can machine verify to an extent its correctness with respect to some sensible properties, such as the satisfaction of the safety constraint.

The paper is organised as follows. Section2summarises the presentation of the protocol found in [6] and [7]. Section3presents a semi formal Comhord´u model. Extensions and modifications to the original model are proposed therein, and the groundwork is laid for the subsequent formal model. In Section 4, a process language is presented which is used in Section 5 to formally specify the Comhord´u protocol. A brief overview of related work is given in Section6. Finally in Section7, this work is discussed and compared to related work.

2

Informal Description of the Comhord ´u System

Comhord´u is a coordination model which was developed in [6] and [7]. The model is a means of reasoning about certain systems of autonomous mobile entities which communicate over a wire-less network. The model may also be used as an aid in the design of such systems. Summarised in this section are the main aspects of the model. The description here is deliberately informal; a formalised version of the same model will follow in Section3and Section5.

(4)

2.1 Properties of the Comhord ´u Model

A Comhord´u system1incorporates a collection of entities. An entity is some mobile vehicle e.g. a robot. Every entity has a type. The behaviour of an entity is governed partly by its type. At all times, every entity will be in some state or another. The state of an entity contains information about what it is doing, where it is, how fast it is travelling etc. A mode, or mode of operation, is an abstraction of a state. For example, a state might tell us that a car is currently at coordinates

(154,23)travelling east at 9.6km/h while the mode of that same car might only indicate that the car is travelling at an absolute speed in the range[0,10]km/h. A mode may be envisaged as an equivalence class on states. We will assume here that the nature of abstraction from state to mode yields a countable number of modes e.g. it may be that sates are points in some real space while modes are cells in that space.

Every Comhord´u system will have associated with it some notion of safe operation e.g. “No vehicles are on a collision course”. A constraint on the system, called the safety constraint (Cs)

is a condition on the states of all the entities that embodies the safety requirements of the system. This constraint may be evaluated at any time in the system. If it is true, then the system is safe at the time of evaluation. A desirable property of any system is that the safety constraintalways holds true as long as entities within the system obey the system protocol i.e. as long as their behaviours comply with certain rules of operation set out in the description of the system. A key concept of the Comhord´u system is that when entities are sufficiently far apart, they cannot cause an incompatibility. This issue will be addressed later and used to reformulate the safety constraint in simpler terms. Currently, a Comhord´u safety constraint is given in terms of an incompatibility that must never occur, where the following grammar describes incompatibilities.

incompatibilitydef= (incompatibility,“∧”,incompatibility)

(incompatibility,“∨”,incompatibility)

(elementType,“.”,stateVariable,relOperator,value)

(elementType,“.”,stateVariable,relOperator,elementType, “.”,stateVariable)

(“distance(”,position,“,”,position,“)”,relOperatorr,value)

(“|”,entityType“.”,stateVariable,“|”,relOperator,value) relOperatordef=“<”“≤”

“>”

“≥”

“=”

“6=”

The Comhord´u model applies to systems communicating over a wireless network. A sub-model of Comhord´u is the space elastic sub-model, a wireless communication sub-model upon which Comhord´u is built. While the space elastic model concerns itself with problems at low level communication layers, such as collisions at the physical layer, Comhord´u deals at a higher level of abstraction, relying on an interface provided by the space elastic model. This interface guaran-tees time bounded notification of coverage to all entities in the network. Assume an entity begins sending a message at timet. The actual coverage (Ca) of this message is the area to which it is

(5)

delivered by timet+msgLatency, wheremsgLatencyis a fixed constant of the system. Provided by the space elastic model is a notification ofCato the sender within a time boundadaptNoti f.

In other words, by timet+msgLatency+adaptNoti f, an entity that has sent a message at time twill be notified of the area to which that message was delivered by timet+msgLatency.

2.2 The Comhord ´u Protocol

A Comhord´u system must contain a number of distinguished modes called fail safe modes. In these modes, an entity must not be capable of contributing towards an incompatibility in the system. Hence, if all entities remain in fail safe modes all the time, the system remains trivially safe. However, if an entity wishes to progress towards one of its goals, it will most likely need to transition to or remain in some mode that may result in an incompatibility. For example, if a robot needs to get from pointAto pointB, is must move to do so, but moving introduces the possibility of a collision. Entering such a mode in an arbitrary way would pose a threat to the safety of the system. Hence, a protocol is imposed upon entities such that safety remains intact.

The protocol dictates that an entity wishing to act in some mode begins periodically sending messages, to entities in its environment, containing its position and the desired mode of opera-tion. The sender waits a pre-determined amount of time, while remaining to periodically broad-cast messages, before entering this desired mode and progressing towards its goal. If at any time the sender is notified of a degradation in coverage, or if it receives a message from another entity with which it may become incompatible, it will immediately begin to transition to a different mode that will ensure system safety. A conservative action for entities either receiving messages from other possibly incompatible entities or experiencing coverage difficulties is to immediately transition to a fail safe mode to maintain system safety. Henceforth, we shall refer to an entity in some fail safe mode as being inthemodeFS, i.e. we will cease to distinguish between different fail safe modes. This is possible as the primary concern of the protocol is ensuring a lack of incompatibilities, and all fail safe modes are equivalent in terms of the inability of any entity in such a mode to cause an incompatibility.

In Figure1, a sending entitysendersends a message to entities in its environment (receivers). However, a degradation in coverage occurs and the message is not sent to a sufficient set of receivers. The sender is notified of this degradation by the space elastic model at or before time t0=t+msgLatency+adaptNoti f, wheretis the time the message sending was initiated. Since an entity may not know the result of its message broadcast until timet0, it is necessary for every entity to wait for a time oft0−t=msgLatency+adaptNoti f before it can act. However, the question still remains as to whether this wait time is sufficient i.e. can an entity begin acting once this time has elapsed? A consideration of this question in Section3leads to the conclusion that this wait time alone is not always sufficient.

3

Towards a Formal Comhord ´u Model

(6)
[image:6.595.119.478.146.385.2]

Figure 1: Message sending with coverage degradation

that were absent in the original model. The need to define such features became apparent through the process of formalising the model. The need to modify existing definitions also emerged as a result of the formalisation process. This array of semi-formal definitions, be they restatements of existing definitions or entirely new ones, lays the groundwork for the process-algebraic model.

3.1 Space Elastic Model

Recall the space elastic model from Section2. A formal definition of the interface provided by this model is given here. The definition is broken into a definition of coverage and a definition of coverage-update. Let us say we observe a Comhord´u system evolving from timet, and that an entityewithin the system begins sending a message to its environment at this time. Then at time t0=t+msgLatency, the actual coverageCaofefor this observation is the maximum distanced

such that if there was an entitye0within this distance ofeat timet0,e0would have received the message sent byeatt. Now, let us assume the system further evolves and we observe it at time t00=t0+adaptNoti f. Then by this time,eis guaranteed by the space elastic model to knowCa

i.e.ewill be notified of the coverage at timet0within a time bound ofadaptNoti f.

3.2 Safety Constraint

(7)

separated by at leastminDistComp(i,j). The function is symmetric. Since entities in fail safe mode cannot cause incompatibilities, the function evaluates to 0 when modeFS is one of its arguments, as perEquation 1.

∀m:M•minDistComp(m,FS) =0 (1)

3.3 Reasoning about the Coverage

Ignore(e,i,s,e0,j,s0)def=i=FS∨j=FS∨(e=e0)∨(dist(s,s0)

rangeOK(i,r)def=i=FS∨r>dmax(i) +smax.(trans(i) +period(i)

+max(trans,adaptNoti f))

>minDistComp(i,j) +smax.(trans(j) +period(j) +max(trans,adaptNoti f) +0.5msgLatency))c

transdef=setMax({trans(i)|i:M})

dmax(i)

def

=setMax({minDistComp(i,j)|j:M})

We have reasoned about various aspects of the coverage and arrived at the above constant and function definitions that will be needed in the formal model. Ignore(e,i,s,e0,j,s0) asserts whether a listenere in mode iand position s can ignore a message sent bye0 in mode j and positions0. rangeOK(i,r)asserts whether the rangerof a message sent by an entity in modei is sufficient. We assume an upper bound on the time it takes an entity in modeito transition to modeFS. We call this timetrans(i). We then definetransas the maximum such time for any mode. The functiondmax(i)is the maximum of all the minimum distances of compatibility for

all mode pairs includingi.

3.4 Mode Transitions

A relation is defined over mode pairs such thati jdenotes the fact that an entity in modei can transition to be in mode j. We have as a feature of the system thati FSfor all non fail safe modes. This condition is needed to ensure safety via the protocol. While transitioning between modes, an entity will broadcast as if it were two entities in parallel, one broadcastingimessages, the other broadcasting jmessages. This idea is taken from the idea of “soft handovers” [15] in the field of mobile cellular networks. In networks employing this idea, cell coverage overlaps and users crossing the overlapping area between cells remain in the coverage of their original cell while they connect to the new cell. The physical time it takes to transition from modeito mode jis given byts(i,j), while the total wait time is given inEquation 2.

tw(i,j)

def

(8)

4

The Modelling Language for Comhord ´u

In this section, the language TCBS’ will be presented. The language is strongly based on the Timed Calculus of Broadcasting Systems (TCBS) [23] and has been influenced by the work in [13]. Expressions in this language which constitute a formal Comhord´u model will appear in Section5. The syntax of the language yields its set of terms, which are built inductively. A term belongs to the language iff it can be constructed using the language base terms & constructors. A processP is a closed term, i.e. one without any free variables. The structural operational semantics of the language is given via four relations over processes. The ignore relation asserts whether a process can ignore a value spoken by another process and essentially do nothing. The input relation captures the behaviour of a process that can consume and use some value, thus becoming a different process. The output relation applies to processes that can speak a value and then become some other process. Novel to the timed version of the calculus, the delay relation links processes such that one may delay and become the other. Given below is the inductively built syntax of the TCBS’ language.

T ::=0(ine)?T

(oute)!T

Takei∈ITi

ifbthenT A(~e)

T(f,g)

(T |T)

del(d).T The process 0 denotes the null process. It may delay indefinitely and ignores anything it hears. It cannot evolve to become another process and cannot output any value. An input-prefixed process(ine)?T is one which listens for a value matching the pattern ofe. Since this is a process, all free variables inT are bound bye. Once a valuevis heard that matchese, all free variables ine, and hence inT are bound to the matched values. The output prefixed process(oute)!Pmay broadcast a valuev, to which the expressioneevaluates. Notice thateandPare closed here. Here is a simple example to demonstrate the syntax so far. LetPdef= (in[x,y,z])?(out(x+y+z))!0. Assuming our language is defined over integers and lists of integers, we have thatPlistens for a list of three integers, outputs their sum, and finally terminates. Let’s sayPhears[1,2,3]. We represent this by the input actionP−−−−→[1,2,3]? P00whereP00= (out(1+2+3))!0. Since 1+2+3=6, P00then outputs 6 before terminating. This is represented by the output actionP00−6!→0.

Takei∈IPi denotes a choice over the set of processTi indexed by elements of a setI. Roughly

speaking, this process can choose to behave as any of its constituent processesTi. For finite sums,

this choice notation is often replaced by the infix operator+e.g. inP+Q. ifbthenPbehaves exactly asPdoes whenbevaluates to true, and behaves as 0 otherwise.A(~e)is the parametrised process on the vector of closed expressions~e= (e1,e2, ...,en). Each such process is given an

accompanying definitionA(~x)def= TA where the free variables ofTA are contained in~x. P(f,g) is the processPwith remap functions f andgapplied to it. WhenPcan speakv, this process can speak f(v)and when this process hearsu, the nestedPhearsg(u). del(d).P is a process that must delay byd before it may perform any of the actions available toP. (P|Q) denotes two process operating in parallel.

Table1defines the structural operational semantics (SOS) of the TCBS’ language. These are the laws which govern how processes, i.e. expressions in the language, evolve. In this table, compis the symmetric function such thatcomp(w!,w?) =comp(w!,w;) =w!,comp(w?,w?) =

(9)
[image:9.595.31.591.187.722.2]

Table 1: Structural operational semantics of TCBS’

Ignore(−w→; ) Input(−v→? ) Out put(−w→! ) Delay(−→d )

0−w→; 0 0−→d 0

∀~v•w6=e[~v/f v(e)] (ine)?T −w→; (ine)?T

v=e[~v/f v(e)] (ine)?T −→v? T[~v/f v(e)]

(ine)?T −→d (ine)?T

(oute)!P−w→; (oute)!P JeK=w

(oute)!P−w→! P

∀i∈I•Pi w; −→Pi

Takei∈IPi w;

−→Takei∈IPi

∃i∈I•Pi v? −→P0

Takei∈IPi v? −→P0

∃i∈I•Pi w! −→P0

Takei∈IPi w! −→P0

∀i∈I•Pi d

− →Pi0

Takei∈IPi d

→Takei∈IPi0

JbK=false

ifbthenP−w→; ifbthenP

JbK=false

ifbthenP−→d ifbthenP

P−w→; P

ifbthenP−w→; ifbthenP

P−v→? P0 JbK=true

ifbthenP−v→? P0

P−w→! P0 JbK=true

ifbthenP−w→! P0

P−→d P0 JbK=true

ifbthenP−→d P0

TA[~e/~x] α

−→P0

A(~e)−→α P0

P−−→gw; P P(f,g)

w; −→P(f,g)

P−gv−→? P0

P(f,g)−v→? P(0f,g)

P−w→! P0

P(f,g)−−→f w! P(0f,g)

P−→d P0

P(f,g)

d

− →P(0f,g)

P−→α P0 Q−→β Q0 comp(α,β)6=⊥

(P|Q)−−−−−−→comp(α,β) (P0|Q0)

P−→α P0 del(0).P−→α P0

d0≤d

del(d).P d

0

−→del(d−d0).P

d>0

del(d).P−w→; del(d).P

P d

0

−→P0

del(d).P d+d

0

(10)

two concurrent processPandQperform actionsα andβ concurrently,comp(α,β)denotes the

composition of these actions i.e. the overall action of the process (P|Q). This is the action seen by the external environment or equivalently an observer. There is a certain precedence present here. Whenever an output is performed by either process, the observed action is output. Otherwise, when there is at least one input, an input is observed to occur overall. Finally, when only ignore actions are performed, the resultant action is also an ignore.

We assume that all termsA(~x)are given associated definitionsTA where the free variables of

TA are a subset of the free variables of~x. Also, the bound variables ofTA are disjoint from the

free variables of~x- this can always be achieved by alpha renaming. It is further assumed that all such termsTAare guarded. A guarded term is one in which all parametrised process names of the

formA(~x)are part of some sub-expression whose structure is either an input prefix, and output prefix, or a non-zero delay prefix [1]. This assumption prevents the occurrence of nonsensical definitions such asAdef=A. Notice that in the SOS, we only deal with processes i.e. closed terms.

5

Formal Description of the Model

The arguments of Section3and the language of Section4, will now be amalgamated into one coherent formal model of Comhord´u. We begin with a description of the system at the highest level. The system is initialised with three parameters.n:Nrepresents the total number of entities;

S:R2[n]is a finite list ofnpoints in the plane, which are the positions of the entities;V :R2[n]

are the velocities of the entities as two dimensional vectors. This system easily generalises tok dimensions. Below is the expression for the system. It is given asnentities running in parallel.

Sys(n,S,V)def=

n

i=1

E(i,si,vi)

Here,∏ni=1Piis the fold of the binary parallel composition operator over the processesPiindexed

by the set{j∈N+|j≤n}. For the sake of formality, let us say that this fold is right associative. Also, we note thatsi,viare the elements of listsS,V respectively indexed byi.

The TCBS’ language is defined relative to a value type and a boolean type, each with its own associated expression language. Here, the value type will be briefly introduced. The language for boolean expressionsBexp will not be presented here, but is assumed to be well behaved. In

the following,u,vwill range over values in the typeVal,boverBexp,coverChan,soverBase

andewill be a process identifier of typeN.

Base def=R∪R2∪N∪ {A,W}

Val def=sch~si

Chan def=adaptNoti f bc

coverage(e)

f romRelay read

start(e)

switch

toServer

5.1 Top level Composition of an Entity

(11)

be-haviour of the entity. The environment buffers outgoing messages and filters incoming messages based on the facts that messages take time to propagate through space and that not all messages reach every entity. Finally, the mobile sub-process records in its parameters the position and velocity of the entity, updating these periodically based on the mode of the entity. All entities are initialised to be in modeFS.

E(e,s,v) def= (Protocol(e)|Environment(e)|Mobile(0,s,v))[/0](G)\{S} G def={start(e)7→start,coverage(e)7→coverage}

S def={read,toServer,switch,f romRelay,adaptNoti f start,coverage}

We have used some syntactic shortcuts in this specification. The relabelling shortcut generates a map from values to values given a finite map of channels in the form of a list. The idea is that if one channel is mapped to another in the finite map, then all values constructed with this channel are mapped to values constructed with the other channel. Formally, the syntactic sugar for the remap is defined as follows.

P[LF](LG)

def

=P(f,g) f(chxsi) def=F(c)hxsi g(chxsi) def=G(c)hxsi

Here,F andGare functions from channel names to channel names. They are specified by the finite lists of pairsLF andLGrespectively. Pairs in each list are of the formc7→c0 such that no

coccurs as the first element of more than one pair in a list. Channelscnot explicitly mapped by these lists are assumed to map to themselves. The definition forF is given below. Gfollows an analogous definition in terms ofLG.

F(c) =

c0 ifc7→c0∈LF;

c if∀c0•c7→c0∈/LF.

We have also defined a restriction shortcut for channels. Here, it is desired that a process P cannot send/receive messages to/from its environment over any channel in the set of channelsS. Since channels are modelled in this language by value constructors, this is the same as saying thatP cannot send to or receive from its environment any values constructed using the value constructors inS. More formally:

P\{C} def=P[C0](C0)

C0 def={c7→τ|c∈C}

5.2 Protocol Agents

(12)

executes the task of periodically sending messages to its environment containing mode and posi-tion informaposi-tion, as per the protocol descripposi-tion. LisAct(e,i)receives incoming messages from the environment. If any of these messages cannot be ignored, then this process will initiate a transition of the entity to fail safe mode via an internal broadcast to all protocol sub-components. ANCheckA(i) performs a similar duty to the message listener but it instead listens for degra-dations in coverage. The dormant set contains three processes also. The dormant process is so called because it idles for a time until the entity decides to change mode. This decision is mod-elled via input on the channelstart. The process then evolves to a waiting process, which like the active process periodically broadcasts both mode and position information.

The processes ANCheckD(i) and LisDorm(e,i) are analogous to Active(i) and LisAct(e,i)

respectively, only instead of initiating fail safe transitions on reception of a coverage degradation or incompatible message, they initiate an abort broadcast which causes a rollback action of the waiting process to its dormant state. The rollback is possible as opposed to a full fail safe transition because the entity has not yet entered the waiting mode yet. The Protocol process is parametrised on the id of the entity to which it belongs. All its components are initialised to fail safe mode.

Protocol(e)def= (Active(0)|Dormant(0)|LisAct(e,0)|LisDorm(e,0)

|ANCheckA(0)|ANCheckD(0))\{trans,abort}

Active(i)def= (outreadhi)!((inreadhsi)?((outtoServerhA,i,si)!(del(p(i)).Active(i) +A0) +A0) +A0) +A0

A0def= (inswitchhji)?Active(j)

Dormant(i)def=Takej∈{k|i k}(instarthji)?Waiting(i,j,tw(i,j)) +D0(i)

D0(i)def= (intrans)?Waiting(i,0,trans(i)) + (inabort)?Dormant(i)

Waiting(i,j,t)def= (outreadhi)!(inreadhsi)?((outtoServerhW,j,si)!W0(i,j,t) +D0(i)) +D0(i)

W0(i,j,t)def=del(p(j)).Waiting(i,j,t−p(j))

+del(t).(outswitchhji)!Dormant(j) +D0(i)

LisAct(e,i)def= (in f romRelayhe0,j,s0i)?(LisAct(e,i)

(13)

MessHand(e,i,e0,j,s0)def= (outreadhi)!(inreadhsi)?MH0(e,i,s,e0,j,s0)

LA0(e)def= (intrans)?LisAct(e,0) + (inswitchhji)?LisAct(e,j)

MH0(e,i,s,e0,j,s0)def=if¬Ignore(e,i,s,e0,j,s0)then(outtrans)!0

LisDorm(e,i)def=Takej∈{k|i k}(instarthji)?LW(e,i,j) +LW0(e,i)

LW(e,i,j)def= (inf romRelayhe0,j0,s0i)?(LW(e,i,j)

|MessHand(e,j0,e0,j,s0)({trans7→abort},/0))

+LW0(e,i)

LW0(e,i)def= (intrans)?LW(e,i,0)

+ (inswitchhji)?LisDorm(e,j) + (inabort)?LisDorm(e,i)

ANCheckA(i)def= (inadaptNoti fht,i,ri)?(ANCheckA(i)|ANC0(i,r)) + (inswitchhji)?ANCheckA(j)

ANC0(i,r)def=if¬rangeOK(i,r)then(outtrans)!0

ANCheckD(i)def=Takej∈{k|i k}(instarthji)?ANCheckW(i,j)

ANCheckW(i,j)def= (inadaptNoti fhW,j,ri)?(ANCheckW(i,j)

|ANC0(j,r)({trans7→abort},/0)) + (inswitchhji)?ANCheckD(j)

+ (intrans)?ANCheckW(i,0) + (inabort)?ANCheckD(i)

5.3 Environment & Space Elastic Model

Here the focus is on processes which model the environment i.e. the propagation of messages through space and the filtering of these messages based on their coverage. Also modelled in this logical sub-component is the interface provided by the space elastic model, which provides any sender with a coverage notificationadaptNoti f time units after message sending is initiated.

(14)

Environment(e)def=RelayServ|Server(e)

Server(e)def= (intoServerht,i,si)?(Server(e)|Buffer(e,t,i,s))

Buffer(e,t,i,s)def=del(msgLatency).(incoveragehri)?(inreadhs0i)?(outbchr,e,i,s,s0i)! del(adaptNoti f).(outadaptNoti fht,i,ri)!0

RelayServdef= (inbchr,e,i,s0,s00i)?(RelayServ|Relay(r,e,i,s0,s00))

Relay(r,e,i,s0,s00)def= (outreadhi)!(inreadhsi)?R0(r,s,s00,e,i,s0)

R0(r,s,s00,e,i,s0)def=ifinRange(r,s,s00)then(out f romRelayhe,i,s0i)!0

The predicate inRange used in these expressions asserts whether or not a message, whose radius of delivery is specified, should be delivered to a given entity based on the position of this entity and the sending entity. Equation3defines this predicate.

inRange(r,s,s0)def= (dist(s,s0)≤r) (3)

5.4 Mobile Agent

The mobile agent is a simple process modelling the physical state of an entity. Mobile(i,s,v)

records via its parameters the positions, velocityvand modeiof the entity to which is belongs. It periodically updates the position and velocity based on functionss0(i,s,v)andv0(i,s,v) respec-tively. It is assumed here that the modeialong with the current position and velocity is enough to determine the new position and velocity. However, this process, being independent of the rest of the system, can easily be altered to change the way position and velocity are updated e.g. by adding new parameters. The period of update is arbitrarily chosen and represents a discrete tick in time. Since this process calculus does not allow continuous actions, this discrete approxima-tion must suffice. We now take notice of the funcapproxima-tionss00andv00. These make an approximate correction to the velocity and position when this process is interrupted by a mode change, which is necessary since it is impossible to know how much time has elapsed since the last update. The nature of such a correction will not be examined here, though it should be such that error is minimised in some sense.

Mobile(i,s,v)def=MobTrack(i,s,v)|MobServ(s)

MobTrack(i,s,v)def=del(update).(outreadhsi)!MobTrack(i,s0(i,s,v),v0(i,s,v)) + (inswitchhji)?MobTrack(i,s00(i,s,v),v00(i,s,v))

MobServ(s)def= (inreadhi)?((outreadhsi)!MobServ(s) +MS) +MS

(15)

6

Related Work

In this section, we will briefly mention some related modelling languages to TCBS’ and highlight their weaknesses, compared to TCBS’, in terms of their applicability to the Comhord´u problem. As mentioned earlier, TCBS’ is a variation on the existing TCBS of [23], which itself is an extension of CBS [24]. The differences between TCBS’ and TCBS are mostly influenced by the changes made to CBS in [13]. The advantage of TCBS’ over TCBS is the clarity of notation achieved therein. Other formalisms were considered as alternatives to the timed broadcasting calculus. UPPAAL [5] is a model checker for finite timed automata [3]. The advantage of using UPPAAL to model a system is that certain system properties can be specified and machine-checked. However, the finiteness restriction of UPPAAL does not accommodate a fully general model and this has lead us towards the more powerful paradigm of process algebras. There are a myriad of process algebras currently in existence. We narrow our attention only to those most suitable.

Recently developed are a group of algebras for modelling wireless systems [18,20,17,22,25]. At first glance, these algebras seem ideal for the modelling task at hand. However, many of them focus on low level aspects of the wireless network such as collision detection. This would suit a formalised space elastic model but is too detailed for Comhord´u. The languages also lack any notion of time. A similar calculus that does include time is given in [19], but the time modelled is in ticks rather than delays of real amounts and again the focus is on collisions. Long stand-ing timed process algebras such as TCCS [29] and TCSP [10] were considered. However, the weakness of these languages is that they do not include broadcast as a communication primi-tive, whereas TCBS’ does, thus making it more suitable to the task of modelling an inherently broadcast-based system than any of these other languages considered.

7

Conclusions & Future Work

In this paper a formalisation of the Comhord´u model has been achieved. This formalisation provides us with a clearer understanding of the model, removing any ambiguity from pre-existing model descriptions. It paves the way for future verification work using model checkers. As a general framework, the model also serves as a guide to the construction of model instances i.e. formalisations of particular Comhord´u systems. Finally, it has emerged through the process of formalising the Comhord´u system that some new concepts were required at the heart of the model. In particular, there was the notion of “soft handover” from one mode to another, an idea taken from the telecoms community; the safety constraint language was reduced to the simpler notion of distance-based incompatibilities, which unlike expressions in the original language seem satisfiable in general by the protocol alone; coverage zones were re-evaluated and deduced from first principles, with some new constants and functions defined to yield expressions for sufficient coverage, wait time and ignorable messages.

(16)

sufficient spacing of the entities according to the distance function supplied. Other properties of the system also remain to be investigated such as those of liveness and deadlock. The intuition at the moment is that we will develop a property logic enabling us to express such conditions. After this, we can attempt proofs of certain properties by hand or we can develop some approximation of this system in a model checker like UPPAAL & machine check these properties. It is expected that both techniques will be employed. There have already been investigations performed on the behaviour of the system via the application of the TCBS’ SOS laws to the formal system expressions of Section5to yield traces through the system. Due to spatial limitations however, these traces could not be included here.

Acknowledgements: We extend a special thanks to Matthew Hennessy for his insights and his advice relating to this work. We also express our gratitude towards the anonymous reviewers of this paper for their feedback and their time.

Bibliography

[1] L. Aceto, A. Ing´olfsd´ottir, K. G. Larsen, and J. Srba. Reactive systems: modelling, specifi-cation and verifispecifi-cation. Cambridge Univ Pr, 2007.

[2] M. Alighanbari, Y. Kuwata, and J. How. Coordination and Control of Multiple UAVs with Timing Constraints and Loitering. InProceedings ofAmerican Control Conference, 2003.

[3] R. Alur and D.L. Dill. A theory of timed automata* 1. Theoretical computer science, 126(2):183–235, 1994.

[4] J. Baber, J. Kolodko, T. Noel, M. Parent, and L. Vlacic. Cooperative autonomous driving: intelligent vehicles sharing city roads. IEEE Robotics & Automation Magazine, 12(1):44– 49, 2005.

[5] Gerd Behrmann, Alexandre David, and Kim Larsen. A tutorial on uppaal. In Marco Bernardo and Flavio Corradini, editors,Formal Methods for the Design of Real-Time Sys-tems, volume 3185 ofLecture Notes in Computer Science, pages 33–35. Springer Berlin / Heidelberg, 2004.

[6] M. Bouroche. Real-Time Coordination of Mobile Autonomous Entities. PhD thesis, Uni-versity of Dublin, Trinity College, 2007.

[7] M. Bouroche and V. Cahill. We don’t need to agree to coordinate.Workshop on Dependable Network Computing and Mobile Systems (DNCMS’08), 1:47–51, October 2008.

[8] J. Cawkwell. A visually guided agv for use as passenger transport in urban areas. In Intelligent Transportation Systems, 2000. Proceedings. 2000 IEEE, pages 311–315. IEEE, 2000.

(17)

[10] J. Davies and S. Schneider. A brief history of timed csp. Theoretical Computer Science, 138(2):243–271, 1995.

[11] C.L. Fok, G.C. Roman, and G. Hackmann. A lightweight coordination middleware for mobile computing. In Coordination Models and Languages, pages 135–151. Springer, 2004.

[12] V. Gervasi and G. Prencipe. Coordination without communication: the case of the flocking problem. Discrete Applied Mathematics, 144(3):324–344, 2004.

[13] M. Hennessy and J. Rathke. Bisimulations for a calculus of broadcasting systems* 1. Theoretical Computer Science, 200(1-2):225–260, 1998.

[14] C. Julien and G.C. Roman. Active coordination in ad hoc networks. In Coordination Models and Languages, pages 199–215. Springer, 2004.

[15] R. Koodli and C.E. Perkins. Fast handovers and context transfers in mobile networks.ACM SIGCOMM Computer Communication Review, 31(5):37–47, 2001.

[16] N. Kubota, Y. Nojima, N. Baba, F. Kojima, and T. Fukuda. Evolving pet robot with emo-tional model. InProceedings of the 2000 Congress on Evolutionary Computation, 2000., volume 2, pages 1231–1237. IEEE, 2000.

[17] I. Lanese and D. Sangiorgi. An operational semantics for a calculus for wireless systems. Theoretical Computer Science, 411(19):1928–1948, 2010.

[18] M. Merro. An observational theory for mobile ad hoc networks. Electronic Notes in Theo-retical Computer Science, 173:275–293, 2007.

[19] Massimo Merro and Eleonora Sibilio. A timed calculus for wireless systems. In Farhad Arbab and Marjan Sirjani, editors,Fundamentals of Software Engineering, volume 5961 of Lecture Notes in Computer Science, pages 228–243. Springer Berlin / Heidelberg, 2010.

[20] N. Mezzetti and D. Sangiorgi. Towards a calculus for wireless systems. Electronic Notes in Theoretical Computer Science, 158:331–353, 2006.

[21] A.L. Murphy, G.P. Picco, and G.C. Roman. Lime: A middleware for physical and logi-cal mobility. InInternational Conference On Distributed Computing Systems, page 0524. Published by the IEEE Computer Society, 2001.

[22] S. Nanz and C. Hankin. A framework for security analysis of mobile wireless networks. Theoretical Computer Science, 367(1-2):203–227, 2006.

[23] K. Prasad. Broadcasting in time. In Paolo Ciancarini and Chris Hankin, editors, Coordi-nation Languages and Models, volume 1061 ofLecture Notes in Computer Science, pages 321–338. Springer Berlin / Heidelberg, 1996.

(18)

[25] KVS Prasad. A prospectus for mobile broadcasting systems. Electronic Notes in Theoreti-cal Computer Science, 162:295–300, 2006.

[26] R.D. Schraft. Mechatronics and robotics for service applications. Robotics Automation Magazine, IEEE, 1(4):31 –35, dec 1994.

[27] P. Verissimo and A. Casimiro. Event-driven support of real-time sentient objects. In Object-Oriented Real-Time Dependable Systems, 2003. (WORDS 2003). Proceedings of the Eighth International Workshop on, pages 2 – 9, jan. 2003.

[28] J. Woodcock and J. Davies. Using Z: specification, refinement, and proof, volume 39. Prentice Hall, 1996.

Figure

Figure 1: Message sending with coverage degradation
Table 1: Structural operational semantics of TCBS’

References

Related documents