Towards Modeling Monitoring of Smart Trafﬁc Services

in a Large-scale Distributed System

Andreea Buga and Sorana Tania Nemes

Christian Doppler Laboratory for Client-Centric Cloud Computing, Johannes Kepler University,

Softwarepark 35, Hagenberg im M

uhlkreis, Austria

Keywords:

Formal Modeling, Monitoring Service, Trafﬁc Surveillance, Abstract State Machines.

Abstract:

Smart trafﬁc solutions have become an important component of today’s cities, due to their aim of improving

the quality of the life of inhabitants and reducing the time spent in transportation. They are deployed across

large distributed systems and require a robust infrastructure. Their complex structure has been addressed

numerous times in practice, but rarely in a formal manner. We propose in this paper a formal modeling

approach for monitoring trafﬁc systems and identifying possible failures of trafﬁc sensors. Ensuring a safe

and robust deployment and execution of services implies having a clear view on the system status, which is

analysed by the monitoring framework. Our work focuses on availability aspects and makes use of the Abstract

State Machines modeling technique for specifying the solution. The framework is deﬁned as an Abstract State

Machine agent and simulated in the ASMETA tool.

1 INTRODUCTION

Design and development of large-scale distributed

systems (LDSs) have been widely researched in the

last years due to the continuously growing storage and

processing demands in information systems’ area. We

address in our research project the aspects related to

monitoring nodes composing an LDS, with a practical

example of trafﬁc monitoring services. We consider

monitoring to represent acquiring data about the sta-

tus of the nodes and other information offered by their

internal sensors.

The main goal of our work is to construct a formal

speciﬁcation for the monitoring services, through us-

ing algorithms speciﬁc to distributed systems. Build-

ing a formal model evolves from natural-language

use cases and user stories and focuses on capturing

correctly functional and non-functional requirements.

We started from examining trafﬁc systems and elabo-

rating the requirements, from which we built the for-

mal model.

In order to ensure that such systems deliver reli-

able and correct data to the users within an admissi-

ble period of time, we need to observe possible fail-

ures that might occur either at node level or during

communication. Interpreting information and assess-

ing the state of the system and also of the trafﬁc is,

therefore, essential. The solution we propose is a

formal model for a monitoring framework deployed

along the LDS, with components replicated at node-

level. We use Abstract State Machine(ASM) method

for elaborating the speciﬁcations.

In comparison with previous proposals in the area

of monitoring smart trafﬁc systems, we are now fo-

cusing on identifying failures of sensor nodes and as-

signing a robust diagnosis through collaboration of

several monitors.

The remainder of the paper is structured as fol-

lows. In section II we deﬁne the problem state-

ment and the motivation. Section III familiarizes the

reader with the necessary concepts and introduces the

ground model for the monitors, that we reﬁne to a

pseudo-code-like/AsmetaL characterization, and sim-

ulate. Section IV explores previous meaningful work

carried out in the area, after which the paper is con-

cluded in Section V.

2 PROBLEM STATEMENT

LDSs have become a necessary paradigm for ensuring

the needed capabilities of nowadays services. Exist-

ing trafﬁc surveillance solutions for smart cities ben-

eﬁt of the evolution of distributed systems methods

capture a huge amount of data. Cloud computing is

a successful example of an LDS, which can offer a

Buga, A. and Nemes, S.

Towards Modeling Monitoring of Smart Trafﬁc Services in a Large-scale Distributed System.

DOI: 10.5220/0006303704830490

In Proceedings of the 7th International Conference on Cloud Computing and Services Science (CLOSER 2017), pages 455-462

ISBN: 978-989-758-243-1

455

robust infrastructure for trafﬁc monitoring.

We aim to deﬁne a model for the smart surveil-

lance of trafﬁc and identify possible issues that might

occur inside the system. We propose a framework

for monitoring the availability of the sensors, named

throughout the paper as nodes. We are interested also

in collecting the data offered by the nodes and inter-

pret it to understand the current situation of the trafﬁc.

The monitoring framework ensures the availability of

the smart trafﬁc services.

Monitoring is essential for understanding the per-

formance and evolution of the system. Tradition-

ally, it implies collecting data from running services

and assessing system performance in terms of service

availability, failures and anomalies. The heterogene-

ity and distribution of the sensors of a trafﬁc system

over a wide geographical area has introduced a high

complexity for the monitoring solutions. The use of

a formal model covers the system analysis and design

phases of software development and leads to a pro-

posal which can be veriﬁed for its intended properties.

Model-driven engineering allows the stake-

holders to contribute at deﬁning speciﬁc concepts

and entities. Natural language requirements, Uniﬁed

Modeling Language (UML) use cases, agile user sto-

ries are captured in models who are part of the soft-

ware development process. In the design phase func-

tional and non-functional properties are proposed and

validated. Spotting errors later in the development

process leads to higher costs for software projects.

The speciﬁcation needs to encompass the behavior

of the monitors and abstract away from complex de-

tails. We favored the use of the ASM method in front

of other modeling techniques as, UML or Business

Process Model and Notation (BPMN), due to its abil-

ity to model multi-agent systems and to easily reﬁne

speciﬁcations by replacing an action through multi-

ple parallel actions. In comparison with UML, ASMs

provide a more rigorous abstraction, that allows veri-

ﬁcation through model checking.

3 SYSTEM OVERVIEW

Trafﬁc surveillance solutions consist of a large num-

ber of sensors deployed and communicating across

an LDS. The proposed monitoring framework is part

of an architecture model concerned with coordinating

numerous heterogeneous components. The architec-

ture of the whole system is expressed as an abstract

machine model as depicted in Fig. 1. The moni-

toring component is closely related to the execution

layer from where it extracts information and the adap-

tation layer, which uses information from it to bring

the system to a proper state. The diagnosis established

by the monitor focuses on three main aspects: failure

detection, assessment of availability and diagnosis of

network problems (failure of the communication pro-

cesses).

The ASM relies also on local storage for saving

important events and data. Monitoring information

is saved in terms of low- and high-level metrics in

the data storage, while meaningful operations (adap-

tation events, identiﬁcation of problems) are stored in

the event database. A meta storage is used for sav-

ing additional information as for instance functions to

aggregate low-level metrics.

Robustness of the proposal is achieved by employ-

ing redundant monitors that can take over the tasks in

case of the misbehavior of running elements. There-

fore, each trafﬁc sensor is assigned a set of monitors

to assess its status. The evaluation is carried out in a

collaborative way. When one of the monitors exhibits

a random behavior, it is stopped by the middleware

and replaced.

Moreover, the interaction of the monitoring and

adaptation layers enables the system to perform re-

conﬁguration plans whenever any of the sensors faces

a problem. The monitoring framework submits the

collected data to the adapter whenever a problem oc-

curs. Afterwards, a plan to restore the system to a

normal working state is proposed and the monitors

perform a new evaluation that can indicate if the adap-

tation processes have been efﬁcient.

3.1 Background on ASM

Our research focused on elaborating formal models

for monitoring the smart trafﬁc solutions in terms of

ASMs, which allow capturing the requirements in ab-

stract speciﬁcations that can further be implemented.

The method offers system descriptions that can

be easily understood by the clients, as well as de-

velopers. ASMs have already been used in indus-

trial projects, in proofs of correctness of programming

languages (B

orger and Stark, 2003) and in modeling

client-cloud interaction (Arcaini et al., 2016).

One of the main artefacts of ASMs is the ground

model, which reﬂects system’s requirements. It is ad-

vanced, through incremental reﬁnements, to a written

speciﬁcation, that can be simulated and validated be-

fore deployment.

Basic ASMs contain transition rules expressed as

if Condition then Updates, where the Condition is an

arbitrary predicate logic formula and the Updates are

deﬁned as a set of assignments f(t

, ..., t

) := t. For

an update to be carried out successfully, consistency

must be ensured, meaning that for each location only

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

456

Middleware Component

Service

Interface

Dynamic

Deployment

Service

Monitor

Request

Handler

Abstract

Machine

Communication

Handler

Rollback

Engine

Restart

Engine

Optimizer

Abstract Machine

Adaptation

Layer

Monitoring &

Assessment Layer

Execution

Layer

Failure

Detection

Availability

Assessment

Network

Diagnosis

Event

Storage

Alternative

Meta Storage

Data Storage

Figure 1: Structure of the Middleware and its internal Abstract Machine.

one value has to be assigned (B

orger and Stark, 2003).

LDSs usually rely on multiagents ASMs, which

better reﬂect their modular organization. Each agent

executes its own rules in parallel on its local states.

Each monitor component is represented in our pro-

gram as an ASM agent. The system we describe is

asynchronous, and hence it cannot ensure a global

state, but rather a stable local view of each monitor.

Constants in ASMs are expressed as static func-

tions, while variables are expressed as dynamic func-

tions. A classiﬁcation of the dynamic functions de-

pends on the agent who is allowed to operate on them.

For instance, controlled functions can be modiﬁed

only by the agent and read by the environment, while

monitored ones can be written only by the environ-

ment and read internally by the agent. It is worth men-

tioning, that from the perspective of an agent, the en-

vironment is represented by the other agents. Shared

functions can be modiﬁed by both the agent and the

environment. A more exhaustive description of the

ASM method and functions is given by (B

orger and

Stark, 2003).

We make use of ASMETA framework, a toolset

tailored for deﬁning and simulating ASM models. We

are interested at this step in deﬁning, simulating and

observing their behavior at runtime. (Gargantini et al.,

2008).

3.2 System Requirements

As mentioned in the previous subsection, ASMs me-

diate the translation of requirements to speciﬁcations.

At design phase, we had into consideration the fol-

lowing list of requirements:

• [R. 1. ]Each node of the system is assigned a set

of monitors;

• [R. 2. ]Monitoring is carried out at different levels

of the system and follows and hierarchical struc-

ture;

• [R. 3. ]After monitoring is started, availability of

a node is checked through heartbeat requests;

• [R. 4. ]The framework must detect problems of a

node based on the data collected;

• [R. 5. ]The monitor must disseminate the infor-

mation locally and gossip about detected prob-

lems;

• [R. 6. ]Data collected are processed and temporar-

ily stored;

• [R. 7. ]The monitoring processes run continu-

ously in the background of execution of normal

services;

• [R. 8. ]The trust in the assessment of a monitor

decreases with the number of incorrect diagnoses

it made;

• [R. 9. ]When a monitor is considered untrustwor-

thy, the middleware will stop the activity of the

monitor;

3.3 ASM Ground Model

As illustrated in Fig. 2, we encompassed all the re-

quirements previously listed in the control state di-

agram of the local monitor assigned to a node. We

complete the diagram with sequences of the ASM

rules elaborated in AsmetaL language, which is part

of the ASMETA framework for modeling various

services and prototyping (Riccobene and Scandurra,

2014).

In equivalence with the control state diagram,

the monitoring agent can be in one of the following

states:

en um dom ai n St ate = { I NA C TI V E | ID LE | A CT I VE |

WA I T _RE S PON S E | C O LL E C T_ D A TA | R ET R I EV E _ INF O |

AS S I G N_ D I AGN O S IS | LO G _DA TA | R EP O R T_P R O BL E M };

Towards Modeling Monitoring of Smart Trafﬁc Services in a Large-scale Distributed System

457

Inactive

Monitor deployed

Yes

Assign to node

Idle

Start monitor Active

Send request

Wait for

response

Reply arrived

Yes

No Timeout Yes

Stop request

Process

response

Collect dataGather metrics

Retrieve

information

Repository

available

Yes

Query database Assign diagnosis Interpret data

Problem discovered

Yes

Report

problem

Gossip issue

Log data

Log

Monitor

trustworthy

Yes

Figure 2: ASM ground model for the monitor.

In the initial phase of the execution, the monitor is

in INACTIVE state. It awaits for its deployment in the

system, which is carried out by the middleware and

modeled as a monitored boolean function:

mo n ito r ed m o n ito r D ep l o y ed : Mo n it o r - > Bo o le a n

After its deployment in the system, the monitor

has to be assigned to a node. This process is currently

randomly binding a monitor to a sensor. In order to

ensure fairness, we aim to reﬁne this process so that a

new monitor is distributed to the node with the small-

est number of monitors. The monitors designated to a

node are stored in the nodeMonitors list.

ru le r _ as s i gn T o Nod e ( $mon in M o ni t or ) =

if ( a s si g ne d ( $m on )) t he n

sk ip

el se

ch oos e $n in No de wi th true do

par

as s ig n ed ( $ mo n ) := t ru e

no d e Mo n i to r s ($n ) := a ppe nd ( nod e Mon i tor s ( $n ) ,

$m on )

en dpa r

en di f

Once the monitor is appointed to a node, it reaches

the IDLE state, from where the monitoring process

starts and it moves to the ACTIVE state. Sending a re-

quest implies creating a Heartbeat instance and send-

ing it to the node to discover latency and availability.

ru le r _se n d Re q u es t ( $mon in M on i to r ) =

ex ten d He a rtb e at w it h $h do

seq

he a r tbe a t Sta t u s ( $h ) := S UBM I TT E D

he a rtb e at s ( $mon ) := a ppe nd ( h e art b ea t s ( $m on ) ,

$h )

en dse q

Subsequently to submitting the request, the mon-

itor advances to the WAIT RESPONSE state. The

guard Reply arrived veriﬁes if a response to the

heartbeat is acknowledged. If the monitor records

a response, it inspects it and moves to the COL-

LECT DATA state. The measurements are stored in a

set of < key, value > pairs, where the key is the unique

string identiﬁer of the metric and the value is ﬁlled by

the monitor. The pairs are stored in the local repos-

itory at every monitoring cycle. The monitor gath-

ers all the available data from the node and moves to

the RETRIEVE INFORMATION state. At this point it

checks if it can access the local repository and if so, it

queries the database. In case it is not possible to ob-

tain information from the local storage, the monitor

moves to the ASSIGN DIAGNOSIS state directly.

The rule for interpreting the data is in charge with

processing the collected metrics and evaluating the

current state of the sensor node. When a problem

is identiﬁed, as well as in the case the heartbeat re-

ply takes longer than an accepted maximum delay,

the monitor moves to the REPORT PROBLEM state.

From there gossip communication is triggered and the

other monitors assigned to the current node submit

their own assessment. The diagnosis set by the ma-

jority of the nodes is the one taken into consideration.

We left the gossip rule abstract for the moment, as

there are various gossip protocols that can be used by

different systems. After establishing a diagnosis by

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

458

consulting with the other counterparts, the decision is

locally logged and the conﬁdence degree of the mon-

itor is calculated after the following formula:

con f Degree(mon) = con f Degree(mon)−

c(mon) · penalty ·

|diagnoses| − |similar diagnoses|

numberO f Diagnoses

(1)

where the initial conﬁdence degree of a monitor is:

function confDegree($m in Monitor) = 100

and

c(mon) =

(

0, if the diagnosis was correct

1, otherwise.

As it can be noticed, the conﬁdence degree is a strictly

monotonically decreasing function in order to prevent

the case the conﬁdence degree is increased by false

positive diagnosis. A diagnosis is considered cor-

rect if it matches the decision adopted by the major-

ity of the monitors. In case of a false diagnosis, the

conﬁdence degree of a monitor is inﬂuenced by the

marginality of its assessment. For instance, if the di-

agnosis is shared by more counterparts, then the con-

ﬁdence degree decreases with a smaller value. The

value of the penalty constant depends on how critical

a mistaken diagnosis is for the system and is deﬁned

at the initialization of the system. If the conﬁdence

degree value of a monitor is above a set threshold, it

starts a new monitoring cycle. Otherwise, it will move

to the INACTIVE state and wait for the middleware to

take an action.

fu n ct i on is M oni t o rTr u s t wo r t h y ( $m on i n M on i to r ) =

if ( gt ( con f ( $mon ), m in C on f )) t he n

tr ue

el se

fa ls e

en di f

Monitors are also components of the LDS and they

can be affected by failures and unavailability prob-

lems just like any other node of the system. Using the

conﬁdence measure for evaluating the correctness of

a monitor we aim to mitigate the failures of the mon-

itoring solution itself.

Monitoring processes produce a high volume of

data, which needs to be processed for assessing the

evaluation. In order to avoid data cluttering and load-

ing the local storage, we proposed a data degradation

approach. Hence, the information which is older than

a speciﬁc date are considered irrelevant and are re-

moved from the repository.

3.4 Relevant Monitoring Metrics

Basic monitoring data does not offer a complete view

over the system. Having a delayed response does not

give extra information about probable network con-

gestion or overloaded sensors. Unsuccessful data log-

ging does not reveal problems related to the storage,

and so on. Combining basic data into higher-level

metrics provides a better understanding of the state

of the node, helps in establishing a better diagnosis

and ﬁnding proper adaptation measures.

The monitoring framework detects abnormal run-

time situations of sensors of the smart trafﬁc system.

The tasks executed by such nodes have to be taken

over by another suitable components. We describe a

composed metric characterizing the process transfer

effort (PTE), which is of interest in case the adaptation

component decides that a node needs to be replaced

with another candidate. The metric comprises infor-

mation about the candidate node (availability, perfor-

mance and reliability), which need to be deﬁned in

their turn from other basic data as available storage,

memory consumption and network bandwidth. Due

to privacy issues and different security policies, it

needs to be established if a new node can take over

the data of the faulty component. If a task cannot be

moved due to legislation issues, the value of the PTE

for the new node is set to ∞.

if !canBeLegallyTransferred(i, t) then

pte(i, t) = ∞

end if

For a node i, among k eligible candidates for a task

t we propose the following metric:

pte(i,t) =

bdwidth(t)

per f (i)

max(per f (k))

reliab(i)

100

, (2)

where bdwith(t) refers to the bandwidth available

for submitting task t, perf(i) represents the perfor-

mance of the node i, max(perf(k)) is the maximum

value of performance from all the available k candi-

dates. Reliab(i) refers to the reliability of the node

candidate i. The PTE gives information about the best

node candidate to move a trafﬁc surveillance task to.

It evaluates a node according to the performance perf

relatively to other nodes, its absolute reliability and

the absolute bandwidth of the communication estab-

lished for submitting the task. The lower the PTE, the

most suitable the competitor node.

Node work capacity describes an overview of the

percentage of available resources. This metric is im-

portant for understanding the behavior of the node

when sending new requests. High consumption of re-

sources leads to undesired delays which sometimes

might be interpreted as being caused by network com-

munication issues. Resources refer to storage, CPU

and memory of a sensor. A high usage value of any of

the resources leads to a signiﬁcantly smaller capacity

Towards Modeling Monitoring of Smart Trafﬁc Services in a Large-scale Distributed System

459

for taking new tasks. For a node i, the work capacity

is equal to the percentage of resources left available

after withdrawing the current efforts:

workCapacity(i) =

100

· (3 −

cpuUsage(i)

100

−

memoryUsage(i)

100

−

storageUsage(i)

100

) (3)

As mentioned before, the latency of a node i to

respond to a request r is introduced either by its

overloading or by network infrastructure problems.

Knowing that the bandwidth is small, reduces the sus-

picions that there might be problems with the node

and the other way around. For sensor networks, the

connection between nodes is susceptible to different

issues, reason for which it is important to include it in

the assessment of the status of the node.

delay(r, i) = (100−workCapacity(i))·

bdwidth(r)

(4)

We deﬁned the metrics also inside the rule desig-

nated to interpret the data. It works on the assumption

that the structure of the measurement list is known.

We temporarily made use of simple comparisons for

evaluating the state of the system but we aim to ad-

vance this function so that it can make use of more

complex statistic analysis methods.

ru le r _ in t e rpr e t Da t a ( $mo n in Mo n it o r ) =

seq

wo r k Ca p a ci t y ( $m on ) := 10 0 .0 * ( it or (3) - se con d

( at ( dat a Col l e ct e d ( $m on ) , 1 n ) ) /1 00. 0 -

se con d ( at ( da ta C o ll e c ted ( $ mo n ) , 3n ) ) / 10 0 .0

- seco nd ( at ( dat a C ol l e ct e d ( $m on ) , 4 n ) )

/1 0 0. 0 ) / 3.0

de la y ( $m on ) := (1 0 0. 0 - w o rk C a pa c i ty ( $ mo n ) ) /

se con d ( at ( da ta C o ll e c ted ( $ mo n ) , 2n ) )

if (( de la y ( $m on ) > 2. 0) o r ( w ork C apa c ity ( $ mo n )

< 30. 0) or ( s e co nd ( at ( dat a C ol l e ct e d ( $m on ) ,

6n)) < 40 .0 ) ) t he n

par

di a gno s is ( $mon ) := " Crit i ca l "

pr o b l em D i s co v e r ed ( $ mo n ) := true

en dpa r

el se

di a gno s is ( $mon ) := " Nor m al f u nc t i on i n g "

en di f

as s e s se d D i ag n o s is ( $ mo n ) := ap pe n d (

as s e s se d D i ag n o s is ( $ mo n ) , d i ag n osi s ( $m on ))

en dse q

The initial set of data to be collected by the monitor

contains the following metrics: latency expressed in

milliseconds needed by a node to reply to a request,

CPU, memory and storage usage represented in the

percentage of used resource, bandwidth expressed in

Mb/s, the cost of a node to perform a task and its per-

formance expressed as a percentage of the actual efﬁ-

ciency in report to the capabilities of a node. The list

of metrics is yet to be completed with other relevant

functions which provide insights on the status of the

trafﬁc sensors and their execution.

3.5 Simulation of the Model

We veriﬁed through simulation if the monitor model

passes through the states as expressed in the control

state diagram and if monitors are able to identify pos-

sible problems of a sensor node. We used AsmetaS

tool to simulate the execution of the model. The sim-

ulation consisted in following a speciﬁc scenario for

execution. Different conﬁgurations trigger a differ-

ent workﬂow. For compactness, we took into con-

sideration a monitor and a smaller set of metrics for

comparison and analysis, and left aside the collabo-

rative diagnosis. The set of metrics and the values of

the measurement are initialized in the function data-

Collected. We present in Listing 1 an excerpt of the

simulation of our model and we can notice that af-

ter passing through the state of ASSIGN DIAGNOSIS

the monitor correctly evaluates the node as being in a

Critical execution mode. The evaluation is carried out

by analysing the rule for interpreting the data, which

speciﬁes that in the case of a performance value be-

low 40.0, the monitor assesses that the node is in a

Critical state.

fu n ct i on da ta C o lle c t ed ( $ mo n in Mo n it o r ) =

sw itc h ( $ mo n )

ca se mo n1 : [( " La ten cy " , 5.0) , (" CPU Us ag e " ,

84 .0 ) , (" B an d wi d th " , 1 50 . 0) , ( " Memo ry U sa ge

", 50 .0 ) , (" St o ra g e U sag e " , 4 4. 0) , (" C os t " ,

4. 0) , (" P erf o rma n ce " , 2 0. 0) ]

en d swi t ch

4 RELATED WORK

LDSs, especially grids and clouds, are in the focus

of researchers due to their high computing capacities

and resources. Modeling properties of such systems

imposes, nonetheless, some restrictions as researchers

need to abstract away from several details that might

impede proper veriﬁcation.

Modeling cloud systems has been proposed by the

MODA-Cloud project in order to obtain self-adaptive

multi-cloud applications. It relies on CloudML lan-

guage, an extension of UML, for modeling the run-

time processes and specifying the data, QoS mod-

els and monitoring operation rules (Bergmayr et al.,

http://asmeta.sourceforge.net/download/asmetas.html

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

460

Listing 1: Excerpt of simulating the monitor agent.

IN I TI A L S TA T E : Mo ni t or ={ mo n1 }

No de ={ n1 , n2 }

In ser t a bo o le a n co n st a nt for mo n i t or D e plo y e d ( mon1

): tru e

< Sta te 0 ( m o ni t or e d )>

mo n i tor D e plo y e d ( mon1 )= tru e

</ S ta te 0 ( m o nit o re d ) >

< Sta te 1 ( c o nt r oll e d ) >

Mo n it o r ={ m on 1 }

No de ={ n1 , n2 }

as s ig n ed ( m on 1 ) = tru e

no d e Mo n i to r s (n2 ) =[ m on 1 ]

st at e ( mo n1 )= IDL E

</ S ta te 1 ( c o n tr o lle d )>

< Sta te 2 ( c o nt r oll e d ) >

Mo n it o r ={ m on 1 }

No de ={ n1 , n2 }

as s ig n ed ( m on 1 ) = tru e

no d e Mo n i to r s (n2 ) =[ m on 1 ]

st at e ( mo n1 )= AC TI VE

</ S ta te 2 ( c o n tr o lle d )>

< Sta te 3 ( c o nt r oll e d ) >

He a rtb e at ={ Hea r tb e at !1}

Mo n it o r ={ m on 1 }

No de ={ n1 , n2 }

as s ig n ed ( m on 1 ) = tru e

he a r tbe a t Sta t u s ( He a rtb e at ! 1) = SUB M IT T ED

he a rtb e at s ( mon1 ) =[ He ar t be a t !1]

no d e Mo n i to r s (n2 ) =[ m on 1 ]

st at e ( mo n1 )= WA I T _R E S PO N S E

</ S ta te 3 ( c o n tr o lle d )>

In ser t a bo o le a n co n st a nt for re p l yA r r iv e d : tru e

< Sta te 3 ( m o ni t or e d )>

re p l yA r r iv e d = tr ue

</ S ta te 3 ( m o nit o re d ) >

< Sta te 4 ( c o nt r oll e d ) >

He a rtb e at ={ Hea r tb e at !1}

Mo n it o r ={ m on 1 }

No de ={ n1 , n2 }

as s ig n ed ( m on 1 ) = tru e

he a r tbe a t Sta t u s ( He a rtb e at ! 1) = SUC C ES S F UL

he a rtb e at s ( mon1 ) =[ He ar t be a t !1]

no d e Mo n i to r s (n2 ) =[ m on 1 ]

st at e ( mo n1 )= CO L LEC T _DA T A

</ S ta te 4 ( c o n tr o lle d )>

< Sta te 5 ( c o nt r oll e d ) >

He a rtb e at ={ Hea r tb e at !1}

Mo n it o r ={ m on 1 }

No de ={ n1 , n2 }

as s ig n ed ( m on 1 ) = tru e

he a r tbe a t Sta t u s ( He a rtb e at ! 1) = SUC C ES S F UL

he a rtb e at s ( mon1 ) =[ He ar t be a t !1]

no d e Mo n i to r s (n2 ) =[ m on 1 ]

st at e ( mo n1 )= RE T R IE V E _I N F O

</ S ta te 5 ( c o n tr o lle d )>

In ser t a bo o le a n co n st a nt for rep o s ito r y A va i l a bl e (

mo n1 ):

fa ls e

< Sta te 5 ( m o ni t or e d )>

rep o s ito r y Ava i l a bl e ( m on 1 ) = fal se

</ S ta te 5 ( m o nit o re d ) >

< Sta te 6 ( c o nt r oll e d ) >

He a rtb e at ={ Hea r tb e at !1}

Mo n it o r ={ m on 1 }

No de ={ n1 , n2 }

as s ig n ed ( m on 1 ) = tru e

he a r tbe a t Sta t u s ( He a rtb e at ! 1) = SUC C ES S F UL

he a rtb e at s ( mon1 ) =[ He ar t be a t !1]

no d e Mo n i to r s (n2 ) =[ m on 1 ]

st at e ( mo n1 )= AS S I GN_ D I AGN O S IS

</ S ta te 6 ( c o n tr o lle d )>

< Sta te 7 ( c o nt r oll e d ) >

He a rtb e at ={ Hea r tb e at !1}

Mo n it o r ={ m on 1 }

No de ={ n1 , n2 }

as s e s se d D i ag n o s is ( m on 1 ) =[" C ri t ic a l "]

as s ig n ed ( m on 1 ) = tru e

de la y ( mo n1 ) = 0 .39 5 5 5 55 5 5 5 555 5 5 55

di a gno s is ( m on 1 ) = " Cr it i ca l "

he a r tbe a t Sta t u s ( He a rtb e at ! 1) = SUC C ES S F UL

he a rtb e at s ( mon1 ) =[ He ar t be a t !1]

no d e Mo n i to r s (n2 ) =[ m on 1 ]

ou t Me s s =" P r ob l em d i sco v er e d "

pr o b l em D i s co v e r ed ( m on 1 ) = tru e

st at e ( mo n1 )= RE P O RT _ P ROB L E M

wo r k Ca p a ci t y ( mo n1 ) = 4 0 .66 6 6 666 6 6 666 6 7

</ S ta te 7 ( c o n tr o lle d )>

... . . . . . ... . . . . ... . . . . . ... . . . . . ... . . . . . ... . . . . . ..

2015). The ASM method we used allows a more rig-

urous elaboration of speciﬁcation in comparison with

UML.

Trafﬁc control systems have been formally mod-

eled in terms of Petri Nets from the point of view of

safety (List and Cetin, 2004). We shift the attention

towards formally modeling failure detection inside a

trafﬁc system and focus on availability of the trafﬁc

sensors.

A solution for modeling monitoring smart trafﬁc

solutions using smart agent and emphasizing on self-

* properties has been proposed by (Haesevoets et al.,

2009). The authors present the organization of the

system and formally express the roles of the agents

and their capabilities.

The necessity of modeling and validating criti-

cal systems has been reported also by (Gl

asser et al.,

2008), which focuses on capturing the security of

aviation processes with the aid of ASMs and proba-

bilistic modeling techniques reported also by (Arcaini

et al., 2015), where authors describe a medical system

in a formal approach through the aid of AsmetaL.

Previous approaches of using ASMs in express-

ing grid services propose the description of job man-

agement and service execution in (A. Bianchi, 2011),

work that was further extended by (Bianchi et al.,

Towards Modeling Monitoring of Smart Trafﬁc Services in a Large-scale Distributed System

461

2013). Speciﬁcation of grids in terms of ASMs has

been proposed also by (Nemeth and Sunderam, 2002),

with a focus in underlining differences between grids

and normal distributed systems. Our work can be con-

sidered an extension of these projects with a focus on

monitoring components which are responsible of ser-

vice execution and detecting possible failures that can

occur at node level.

5 CONCLUSIONS

The use of formal models before starting the develop-

ment of a software system leads to more robust solu-

tions. Being able to design a model according to the

natural language speciﬁcations is very well supported

by the ASM technique through its ground models and

transition rules. We presented in the current paper

a formal approach for deﬁning a monitoring frame-

work for a smart trafﬁc system deployed in an LDS.

We started from the requirements and elaborated the

ground model and speciﬁc transition rules. One can

easily infer from the structure the complete workﬂow

of the system.

The work stays at the ground of future valida-

tion and veriﬁcation of the speciﬁcations, which will

help the practitioners to construct robust and reliable

smart trafﬁc solutions and their intrinsic monitoring

services. As a future work, we intend to further reﬁne

the proposed model and investigate it through valida-

tion and model-checking until we obtain a prototype.

By these means, issues faced by such real-time sys-

tems, like complexity and failures, can be overcome.

REFERENCES

A. Bianchi, L. Manelli, S. P. (2011). A Distributed Ab-

stract State Machine for Grid Systems: A Prelimi-

nary Study. In P. Ivnyi, B. T., editor, Proceedings of

the Second International Conference on Parallel, Dis-

tributed, Grid and Cloud Computing for Engineering.

Civil-Comp Press.

Arcaini, P., Bonfanti, S., Gargantini, A., Mashkoor, A., and

Riccobene, E. (2015). Formal validation and veriﬁ-

cation of a medical software critical component. In

2015 ACM/IEEE International Conference on Formal

Methods and Models for Codesign (MEMOCODE),

pages 80–89.

Arcaini, P., Holom, R.-M., and Riccobene, E. (2016). Asm-

based formal design of an adaptivity component for a

cloud system. Form. Asp. Comput., 28(4):567–595.

Bergmayr, A., Rossini, A., Ferry, N., Horn, G., Orue-

Echevarria, L., Solberg, A., and Wimmer, M. (2015).

The Evolution of CloudML and its Manifestations.

In Proceedings of the 3rd International Workshop

on Model-Driven Engineering on and for the Cloud

(CloudMDE), pages 1–6, Ottawa, Canada.

Bianchi, A., Manelli, L., and Pizzutilo, S. (2013). An ASM-

based Model for Grid Job Management. Informatica

(Slovenia), 37(3):295–306.

orger, E. and Stark, R. F. (2003). Abstract State Machines:

A Method for High-Level System Design and Analysis.

Springer-Verlag New York, Inc., Secaucus, NJ, USA.

Gargantini, A., Riccobene, E., and Scandurra, P. (2008). A

metamodel-based language and a simulation engine

for Abstract State Machines. j-jucs, 14(12):1949–

1983.

asser, U., Rastkar, S., and Vajihollahi, M. (2008). Mod-

eling and Validation of Aviation Security, pages 337–

355. Springer Berlin Heidelberg, Berlin, Heidelberg.

Haesevoets, R., Weyns, D., Holvoet, T., and Joosen,

W. (2009). A formal model for self-adaptive and

self-healing organizations. In 2009 ICSE Work-

shop on Software Engineering for Adaptive and Self-

Managing Systems, pages 116–125.

List, G. F. and Cetin, M. (2004). Modeling trafﬁc signal

control using Petri nets. IEEE Transactions on Intel-

ligent Transportation Systems, 5(3):177–187.

Nemeth, Z. N. and Sunderam, V. (2002). A formal frame-

work for deﬁning grid systems. In Cluster Comput-

ing and the Grid, 2002. 2nd IEEE/ACM International

Symposium on, pages 202–202.

Riccobene, E. and Scandurra, P. (2014). A formal frame-

work for service modeling and prototyping. Formal

Aspects of Computing, 26(6):1077–1113.

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

462