ideal-traffic: a framework for ... - repositorio.ufop.br‡Ão... · catalogação:...

Saul Emanuel Delabrida Silva

Supervisor – Alvaro Rodrigues Pereira Junior

Co-supervisor – Ricardo Augusto Rabelo Oliveira

IDEAL-TRAFFIC: A FRAMEWORK FOR

BUILDING MONITORING SYSTEMS FOR

INTELLIGENT TRANSPORTATION SYSTEMS

Ouro Preto

August 3rd, 2012

Saul Emanuel Delabrida Silva

Orientador – Alvaro Rodrigues Pereira Junior

Co-orientador – Ricardo Augusto Rabelo Oliveira

IDEAL-TRAFFIC: UM FRAMEWORK PARA

CONSTRUCAO DE SISTEMAS DE

MONITORAMENTO PARA SISTEMAS

INTELIGENTES DE TRANSPORTES

Dissertacao de mestrado apresentada ao

Programa de Pos-Graduacao em Ciencia

da Computacao da Universidade Federal de

Ouro Preto, como requisito parcial para a

obtencao do grau de Mestre em Ciencia da

Computacao.

Ouro Preto

03 de Agosto de 2012

Catalogação: [email protected]

S586d Silva, Saul Emanuel Delabrida.

Ideal traffic [manuscrito] : a framework for building monitoring systems for intelligent transportation systems / Saul Emanuel Delabrida Silva. – 2012.

viii, 91 f.: il. color.; tabs. Orientador: Prof. Dr. Álvaro Rodrigues Pereira Júnior. Coorientador: Prof. Dr. Ricardo Augusto Rabelo Oliveira.

Dissertação (Mestrado) - Universidade Federal de Ouro Preto. Instituto de Ciências Exatas e Biológicas. Departamento de Computação. Programa de Pós-graduação em Ciência da Computação.

Área de concentração: Sistemas de Computação

1. Sistemas operacionais (Computadores) - Teses. 2. Sistemas operacionais distribuídos (Computadores) - Teses. 3. Sistemas embarcados (Computadores) - Teses. 4. Android (Programa de computador) - Teses. I. Universidade Federal de Ouro Preto. II. Título.

CDU: 004.451.9

Glossary

ITS Intelligent Transportation Systems, 1–7, 11–13, 16,

19–23, 25, 26, 51, 54, 71, 72

ITS Intelligent Transportation Systems use cases. One of

these cases uses was implemented on the embedded

architecture using the Android OS., 6

OBU On Board Devices Unit, 12, 33, 54, 55

RSU Roadside Unit, 12, 33, 54, 55

SC Service Composition, 3, 29–33, 36–40, 42, 43, 51, 53,

54

SM Service Mediator, 29, 31–35, 39, 40, 42, 46, 47, 53, 54,

68, 73

SOA Service Oriented Architecture, 1, 3, 5, 7, 13, 19–21, 26,

29, 31, 33, 35, 39, 62, 71

SP Service Provider, 21, 29–42, 47, 48, 52–54, 61, 62, 65,

66, 68, 72, 73

SU Service User, 29–33, 35, 37, 39, 47–49, 54, 68

V2I Vehicle To Infrastructure, 12, 54

V2V Vehicle To Vehicle, 12, 54

VANET Vehicular Networks, 6, 12, 26, 51, 55, 72

i

Contents

1 Introduction 1

1.1 Motivation and Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objective of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Contributions of this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Organization of this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Background 9

2.1 Olhos da Cidade Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 ITS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 ANDROID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Advanced RISC Machine - ARM . . . . . . . . . . . . . . . . . . . . . . . 16

2.6 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Related Work 19

4 The IDEAL-TRAFFIC Framework 29

4.1 The IDEAL-TRAFFIC SOA Architecture . . . . . . . . . . . . . . . . . . 29

4.1.1 Service Composition Conceptions . . . . . . . . . . . . . . . . . . . 29

4.1.2 IDEAL-TRAFFIC Overview . . . . . . . . . . . . . . . . . . . . . . 30

4.1.3 IDEAL-TRAFFIC Service Mediator (SM) . . . . . . . . . . . . . . 33

4.1.4 IDEAL-TRAFFIC Service User (SU) . . . . . . . . . . . . . . . . . 35

4.1.5 IDEAL-TRAFFIC Service Provider (SP) . . . . . . . . . . . . . . . 36

4.2 IDEAL-TRAFFIC Network Management and Service Management . . . . 38

4.2.1 Requirements Classify . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.2 Service Creation Process . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.3 Adaptation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 40


iii

5 Building Applications over IDEAL-TRAFFIC 45

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2 SM Hardware and Software . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.3 SP Hardware and Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.4 SU Hardware and Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 48


6 Use Cases 51

6.1 Use Case with Radars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.2 IDEAL-TRAFFIC Integration with V2V . . . . . . . . . . . . . . . . . . . 54


7 Experiments and Results 61

7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.2 Experiment 1: Simple Radars Use Case Application . . . . . . . . . . . . . 62

7.3 Experiment 2: Radars Use Case Application with a Legacy System as Input 65

7.4 Experiment 3: The IDEAL-TRAFFIC Running with 5 Nodes with Legacy

Systems as Input and Output . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.5 Conclusion Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

8 Conclusions and Future Work 71

8.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

8.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Bibliography 74

A XML Example to Compose a Service in a SP 79

B XML Configuration to Create the Radars Application 83

B.1 P1 XML Configuration for Experiments 1, 2 and 3 . . . . . . . . . . . . . . 83

B.2 P2 XML Configuration for the Experiments 1 . . . . . . . . . . . . . . . . 84

B.3 P3 XML Instance for the Experiments 1 . . . . . . . . . . . . . . . . . . . 85

B.4 P2 XML Configuration for the Experiments 2 and 3 . . . . . . . . . . . . . 86

B.5 P3 XML Instance for the Experiment 2 . . . . . . . . . . . . . . . . . . . . 87

B.6 P3 XML Instance for the Experiment 3 . . . . . . . . . . . . . . . . . . . . 88



iv

List of Figures

1.1 Tipical Model of ITS Infrastructure. Figure reused from [20]. . . . . . . . . 2

2.1 Traditional Centralized Monitoring System. . . . . . . . . . . . . . . . . . 10

2.2 Impact of Productivity by Country.(a)Number of Publications. (b) Number

of Citations. Figure reused from [12]. . . . . . . . . . . . . . . . . . . . . . 12

2.3 Android Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4 AM3517 Evaluation Module. . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5 Tablet Motorola Xoom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.6 Mobile Sony Xperia X10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 System Architecture of CrowdITS. Figure reused from [2]. . . . . . . . . . 20

3.2 System Architecture of LOCA. Figure reused from [1]. . . . . . . . . . . . 21

3.3 Architecture of Parking Management System. Figure reused from [10]. . . 22

3.4 The National ITS Architecture. Figure reused from

http://itsarch.iteris.com/itsarch/index.htm. . . . . . . . . . . . . . . . . . 23

3.5 The FRAME ITS General Architecture. Figure reused from

http://www.frame-online.net/. . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.6 iTransIT Framework Architecture. Figure reused from 3.6. . . . . . . . . . 25

4.1 IDEAL-TRAFFIC Class Services new SCs. The SM component manages

all procedures, receives requests from SU, treats it, and collects necessary

data from the SP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 IDEAL-TRAFFIC SOA Architecture. . . . . . . . . . . . . . . . . . . . . . 31

4.3 Three Example of the IDEAL-TRAFFIC Configuration. (a) Child and Par-

ent nodes. (b) A Parent and multiple Children. (c) A Parent and multiple

SC Children. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 IDEAL-TRAFFIC Service Mediator (SM). . . . . . . . . . . . . . . . . . . 33

4.5 IDEAL-TRAFFIC Service User (SU). . . . . . . . . . . . . . . . . . . . . . 35

4.6 IDEAL-TRAFFIC Service Provider (SP). . . . . . . . . . . . . . . . . . . . 36

4.7 IDEAL-TRAFFIC Requirement Classification. . . . . . . . . . . . . . . . . 39

4.8 Step 1 - Topology and Services. . . . . . . . . . . . . . . . . . . . . . . . . 40

v

4.9 Step 2 - SP Selected to SC. . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.10 Step 3 - Subgraph of SC Topology. . . . . . . . . . . . . . . . . . . . . . . 41

4.11 SP 10 Failure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1 IDEAL-TRAFFIC Software Architecture. . . . . . . . . . . . . . . . . . . . 46

5.2 XML File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3 IDEAL-TRAFFIC SP Diagram Classes. . . . . . . . . . . . . . . . . . . . 50

6.1 Traffic speed radar problem scenario. . . . . . . . . . . . . . . . . . . . . . 52

6.2 Using average time and calculated the speed. . . . . . . . . . . . . . . . . . 52

6.3 P1 instantiation using IDEAL-TRAFFIC . . . . . . . . . . . . . . . . . . . 57



6.6 Region sample. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.1 Scenario 1 Designed on the Experiments . . . . . . . . . . . . . . . . . . . 63

7.2 Sequence Diagram For Experiment 1 . . . . . . . . . . . . . . . . . . . . . 64

7.3 Scenario 2 designed on the experiments . . . . . . . . . . . . . . . . . . . . 65

7.4 Sequence diagram for experiment 2 . . . . . . . . . . . . . . . . . . . . . . 66

7.5 Scenario 3 Used on the Experiments . . . . . . . . . . . . . . . . . . . . . 67

7.6 Sequence Diagram For Experiment 3 . . . . . . . . . . . . . . . . . . . . . 69

vi

List of Tables

3.1 National ITS Architecture User Services . . . . . . . . . . . . . . . . . . . 23

3.2 FRAME Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 National ITS Architecture and Frame Requirements . . . . . . . . . . . . . 25

3.4 Comparison of requirements among related work . . . . . . . . . . . . . . . 27

5.1 Layers of the SM Component . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2 Layers of the SP Component . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.3 Layers of the SU Component . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.1 Modules Definition on the XML Files . . . . . . . . . . . . . . . . . . . . . 61

7.2 Classes Definition on the XML Files . . . . . . . . . . . . . . . . . . . . . . 62

7.3 Devices Configuration for Experiment 1 . . . . . . . . . . . . . . . . . . . . 63

7.4 Summary of XML Configuration for Experiment 1 . . . . . . . . . . . . . . 64


7.6 Devices Configuration for Experiment 3 . . . . . . . . . . . . . . . . . . . . 67


vii

1

Abstract

The evolution and dissemination of network communication technology and the advanced

status of embedded devices encourage the creation of solutions for monitoring cities in var-

ious environments. Intelligent Transportation Systems (ITS) is an area that makes use of

these technologies, so that end-users can benefit from applications that deliver information

in real time. On the other hand, administrating these applications is not a trivial task.

Components may fail and invalidate an application. Usually, traffic application’s architec-

ture is centralized, fact that increases the cost of maintenance and reduces the flexibility

of resources reuse.

There are features required on ITS such as adaptability, scalability, heterogeneity, in-

teroperability, openness, accessibility, and flexibility. It was not found on the literature any

related work that aims to cover all these features, although some of them are requisites for

ITS developed for use in North America and Europe.

In this work we present IDEAL-TRAFFIC: a framework based on SOA architecture for

building monitoring applications, with the ability to manage the state of the applications.

IDEAL-TRAFFIC provides a simple interface that enables system administrators create

applications and make them available to end-users.

A self-adaptation process is included in the IDEAL-TRAFFIC framework in order to

ensure fault tolerance. For the implementation of these features, rules of the application

need to be considered and might depend upon the minimum of human intervention, since

the framework can use third part systems or legacy systems to retrieve relevant data to

continue running an application.

In this thesis we have applied the IDEAL-TRAFFIC to two use cases to illustrate its

use for ITS. In the first use case, we demonstrate the use of the framework in static nodes.

In the second use case, we show how the framework may be integrated with vehicular

networks.

Three experiments have been launched. In all executions we reproduced the first use

case over embedded devices. In order to demonstrate the framework accordance with the

main ITS requirements, we illustrate the creation of services using XML SOA files, the

communication among devices, the integration of the framework with a legacy system, and

the scalability of the system. In all experiments we have obtained the expected results. This

fact shows that the IDEAL-TRAFFIC is in accordance with the main ITS requirements.

In the experiments launched, it was proved that the use of XML is a effective and

efficient alternative, to create applications using services available by several nodes on the

network. The proposed process reduces the time of creation of applications.

Chapter 1

Introduction

The demand for monitoring applications has strongly increased in recent years. ‘Smart

cities’ is a term used for an emergent area composed by several sub-areas which generate

research, and novel solutions for users convenience. Catastrophes alerts, counting people

on the streets, image processing for road traffic conditions, among others, are examples

of services that can be provided by monitoring infrastructures. The combination of wire-

less technologies, embedded systems, and robust servers make it possible to build several

monitoring applications whose users can easily retrieve information at their convenience.

One of the sub-areas of ‘Smart Cities’ is the Intelligent Transportation Systems (ITS),

which refers to the extraction of relevant information for users and traffic systems adminis-

trators. This is a special research area which has a multidisciplinary range of subareas such

as digital image processing, digital signal processing, networks, wireless sensor networks,

distributed systems, optimization, data mining, among others.

1.1 Motivation and Problem

The common infrastructure for processing and storage of data in ITS applications is com-

posed by systems based on centralized data processing and storage. This fact imposes a

high demand of network bandwidth to transfer data to servers. Usually these data are

only the raw data extracted from sensors, such as video streams from cameras and audio

streams from microphones. The process of extracting information from the raw data is

performed by the server, which corresponds to a large infrastructure assembled to support

a high data processing. For instance, a server can extract the license plate code from a

video stream (raw data). The extracted data can be used by diverse applications to identify

events on the traffic.

Opposite to our proposal, typical ITS infrastructure are centralized, as shown in Fig-

ure 1.1. The data collection phase occurs through static or mobile sensors on the road.

1

2 CHAPTER 1. INTRODUCTION

Figure 1.1: Tipical Model of ITS Infrastructure. Figure reused from [20].

The mobile sensors usually correspond to vehicles. All the data collected by sensors are

sent to the ITS Center, a large-scale data center for processing the data and extraction of

events from the traffic.

This usual architectural model can imply in a bottleneck in the network and in an inef-

fective data processing, precluding the real time applications implementation. An identified

drawback in this kind of infrastructure is related to the traffic flow. Although there are

several efficient algorithms for data compression, the transference of images is more ex-

pensive than the transference of alpha-numeric and binary data. The infrastructure can

demand high performance equipments for network communications among sensors and the

data center.

ITS usually demands a large number of sensors on the traffic, elevating the demand

for network bandwidth. For instance, transfering images is not a trivial task in large scale

applications. Moreover, managing the infrastructure is not a simple task. The challenge is

to provide technology that supports the increasing demand of applications, ensuring that

the services continue available. Furthermore, ITS projects need to be in accordance with

requirements such as adaptability, scalability, heterogeneity, interoperability, openness,

1.1. MOTIVATION AND PROBLEM 3

accessibility, and flexibility. The ITS also need to have features of cooperative systems,

according to the European standard1.

To give solution for the aforementioned problems, some questions are raised:

� How to reduce the traffic flow on the network?

� Is there any strong requirement for processing data in a centralized way?

� Is it possible to use the sensors as processing nodes?

� Is it possible to create a flexible infrastructure that easily allows creating and deploy-

ing of applications at a feasible cost?

Some hypotheses have encouraged the development of this project.

� With the advance of embedded technologies, for instance the increase of power pro-

cessing, memory size, the utilization of these components to run digital image pro-

cessing algorithms [3].

� Once the data from sensors are processed locally, the volume of data to be transferred

trough network is reduced to the volume of the aggregated data.

� The bandwidth for transferring stream data is largely reduced without harming the

applications. When this is need, the architecture allows the transference of streams

on demand.

Considering that there are strong evidences that the above hypothesis are true, we

have designed and developed the IDEAL-TRAFFIC framework [7] based on SOA archi-

tecture. IDEAL-TRAFFIC is a framework that allows users to access available services

and provides to system administrators an interface to build Services Composition (SC).

IDEAL-TRAFFIC enables building applications in real time without installing hardware

or software, and without turning it off, except at the discretion of the system administrator.

Another challenge of this thesis is to develop the project in accordance with the main

requirements of the ITS shown below.

Adaptability: ITS components may fail and invalidate an application that results on

unavailable service for users. An application with faulty components can ensure the follow-

ing features: Fault Tolerance of system (whenever there is element failure); the increase of

quality of service delivery, and consequently the increase the requirements of service level

agreement (SLA). On this project is shown an adaptation protocol in case of indenting

1The KAREN European ITS Framework Architecture. http://www.frame-online.net/. Accessed on

March 2012


failure in a participant node of an application. Our approach considers that a pair of

nodes can identify a failure on the system without a central element. In order to maximize

the use of resources, we present a re-adaptation process in case of the faulty node resume.

This is a requirement defined by distributed systems.

Heterogeneity Support: ITS projects are complex usually and may involve different

kinds by devices of a large number of manufacturers. To provide the interaction among

these different devices is a hard task if protocols communication are not used. A system is

heterogeneous when it runs in different hardwares (embedded, PC, Server, Workstation),

with different softwares (Android, Windows, Linux) and is available in several communi-

cation networks (Ethernet, WiFi, UTMS). This is a requirement defined by distributed

systems.

Interoperability: Some solutions on ITS can be found running on the cities and roads.

The companies that administrate these systems desire that the newer systems could be

linked with their solutions. On this case, the old systems may provide the data for newer

systems, acting as data input interface of newer system, or receive the data from it, acting

as output interface of newer systems. In our purpose the framework is able to establish

connection with other components. This software project has interface to receive data from

legacy systems, as well as send data to it. This requirement is shown in [14], FRAME1

and National ITS Architecture2.

Scalability: ITS tend to increase the number of sensors monitoring cities and roads,

hence is important to consider the geographic growth of the system. This means that

the power of processing on the computers of the data center increases according with the

number of sensors. To administrate the scalable systems is not a trivial task, in particular

when this system is distributed. Our solution consider the communication among sensors to

provide the scalability. We believe that each sensor can process your information collected,

perform the data processing, and then combines them with data from other sensors, will

be given the scale of processing. In our vision, small devices can perform small tasks, that

combined, corresponds a bigger task. The framework provides an user interface for systems

administrators to create and manage their applications. This interface is able to show the

current state of a node and it capabilities. This requirement is presented in FRAME1.

Openness: This requirement is related with a characteristic of distributed systems of

our solution. The applications need to be easy to implement, install and deploy, and the

1The FRAME European ITS Framework Architecture. http://www.frame-online.net/. Accessed on

March 20122The National ITS Architecture. http://itsarch.iteris.com/itsarch/index.htm. Accessed on March 2012

1.1. MOTIVATION AND PROBLEM 5

developers can write their own applications. With the use of an user interface the system

administrators can build its applications. This user interface uses XML files to establish

communication with the sensors, this latter instantiate the classes with this file. All process

may be performed remotely. To complete the second feature the software deployed on the

sensors has interface for developers set new classes with their rules. Hence, if the developers

respect the framework hierarchy, they will make the systems administrators able to use

updates of the system. This is a requirement defined by distributed systems.

Accessibility for End-Users: ITS systems does not make sense if they are not avail-

able for end-users, that may be drivers, pedestrians or the stakeholders that need of the

information to make decisions about the traffic. Drivers and pedestrians can be alerted

about abnormally events on the traffic and due to this change their plans. The framework

proposes an user interface for end user confer the information provided by available appli-

cations, which in turn are created by systems administrators. There are the possibility of

to integrate the data with third part systems, for instance board computers on vehicles.

This requirement is presented in FRAME1 and National ITS Architecture.

Flexibility to Implement Regulatory Policies: Each country has its particularities

in their laws in traffic. In some places these laws can be different among state or province.

An ITS need to be flexible to receive these different approaches and easy to make changes

when necessary. The software framework has support to apply this requirement. By

its distributed system characteristic the application rules are implemented on the nodes,

and such as in the Openness requirement, developers can use the framework interface to

list their implementations for systems administrators. This requirement is presented in

FRAME1.

Real Time Software: some ITS applications do not make sense if their results are not

delivered in real time. For instance, applications that aim to avoid traffic accidents need

to notify drivers of an abnormal event in a short time. This means that the solutions

need act as soon as possible according to the real time requirement given by features

of each application. IDEAL-TRAFFIC has support to implement parallel tasks allowing

developers to create their real time applications. This requirement is present in [9].

An important feature of the IDEAL-TRAFFIC is its self-adaptation process which

does not depend on human interaction. Although the system administrator is able to

define rules to carry out the adaption process, the IDEAL-TRAFFIC has autonomy to

perform changes based on the application rules. The network topology status is used in

the adaptation process.

IDEAL-TRAFFIC has the following main benefits: 1) it deploys monitoring applica-

tions using SOA architecture; 2) it provides the system administrator with an interface


for building and managing applications; 3) it provides users with an interface to access

services and applications running over the IDEAL-TRAFFIC. To the best of our knowl-

edge there is no other work that allow users to create their monitoring applications using

remote access or nodes working together performing cooperative system, where each node

performs a partial task, thus composing a larger real task.

1.2 Objective of the Thesis

The main objective of this thesis is to design and develop a framework to support the

creation of monitoring applications for ITS. The secondaries objective are: 1) to present

with details the framework, illustrating its operation; 2) to demonstrate that the framework

is in accordance with general ITS requirements: is a cooperative system, scalability, and

interoperability; 3) to show that the framework can be used on the embedded devices

to perform small tasks; 4) to illustrate the use of the framework to ITS, including its

integration with VANETS.

The IDEAL-TRAFFIC Framework has been experimented on three scenarios in or-

der to demonstrate its accordance with ITS requirements. The framework has shown

to be a feasible alternative to create monitoring applications using XML files. We have

been demonstrate two ITS The scalability of the systems can be easily performed without

changes in the software source code.

1.3 Contributions of this Thesis

The main contributions of this work are:

1. To design and develop the first distributed solution that covers the main ITS require-

ments.

2. To show the possibility of reducing the network data flow using the conception of

cooperative systems and distributed systems.

3. To provide a technological advancement demonstrated by the publication of a pa-

per [7] in the Applications Session of the NOMS conference, and by two applications

of patent, being one in the United States (Application Number USPTO 61641330)

and another in Brazil (Application Number INPI BR1020120087014).

4. To give the evidence of effectiveness of the framework to create monitoring applica-

tions for ITS.

5. To show that even this solution is robust, it can be built on embedded devices.

1.4. ORGANIZATION OF THIS THESIS 7

6. To present the state of the art of technologies and related work on ITS infrastructure.

1.4 Organization of this Thesis

This work is organized as follow: Chapter 3 is a brief background on the technology used

for our purpose. Chapter 3 presents the related work. Chapter 4 presents the IDEAL-

TRAFFIC framework, describes how the framework places the SOA components, and

presents the adaptation and readaptation process for treat fault tolerance. Chapter 5 shows

the hardware and software requirements and details for the use of the IDEAL-TRAFFIC.

Chapter 6 presents two examples of use cases applied to ITS. Chapter 7 describes three sce-

narios where the framework was experimented. Finally, Chapter 8 presents the conclusions

and future work.

Chapter 2

Background

This chapter describes projects and technologies used on this work. Section 2.1 presents

a brief description about the project that encouraged the development of this work. Sec-

tion 2.2 presents an overview about Intelligent Transportation Systems, its infrastructure

and the components as well as the most advanced regions that make research on this area is

shown. Section 2.3 presents the SOA technology used in proposed framework. Section 2.4

presents the Android operating system which was used to develop the solution. Section 2.5

presents the ARM architecture which was chosen as hardware platform to run the first

version of the framework.

2.1 Olhos da Cidade Project

In January 2010 the “Olhos da Cidade” project1 was proposed to CNPq2, a Brazilian

agency for promoting research and innovation. The Olhos da Cidade project is a multi-

disciplinary project that involves several research areas. The problem identified on the

project is the lack of data to make an efficient traffic management. This concern has been

increased in recent years due to the growing number of vehicles in cities and roads.

The project presents several points to motivate the development of solutions. Super-

vising the traffic is not a simple task, since the monitoring is highly dependent of human

analysis or expensive equipments. This fact makes difficult to scale the solutions. The lack

of supervision is the main reason for the disruption of traffic. Another point highlighted

in the project corresponds to the difficulty of traffic managers to collect data, to make de-

cisions and then to improve traffic conditions. The impact is a reduction in productivity,

quality of citizens’ life and increasing the possibility of accidents.

1A. R. Pereira Jr. Edital MCT/CNPq no 018/2009 – Pesquisa, Desenvolvimento e Inovacao em Trans-

portes. January 2010.2CNPq. Conselho Nacional de Desenvolvimento Cientıfico e Tecnologico. http://www.cnpq.br/. Ac-

cessed on March 2012

9

10 CHAPTER 2. BACKGROUND

Nowadays transport management companies in cities do not have effective mechanisms

to collect data, make decisions and plan strategies for improving the traffic conditions. The

Brazilian government spends about R$28 billion a year on traffic accidents, accounting since

the rescue of victims until the treatment. In 2006 there were 35,000 traffic deaths registered

in Brazil and 407,000 non-fatal casualties. Another point shown is the low productivity

due to bad traffic conditions. The traffic is the main complaint by citizens in Sao Paulo.

The complaints of pedestrians are over holes and the lack of street lighting, while drivers

complain about the time spent in traffic.

Figure 2.1 shows 4 layers of a typical ITS infrastructure. The layers are described

below.

Figure 2.1: Traditional Centralized Monitoring System.

� Data collect: wireless sensor network, sensor network.

� Data Transference: network infrastructure (wired and wireless).

� Processing and extracting information: high performance computation, data mining.

� Release for users: computer optimization and simulation, systems information, geo-

graphical information systems, Internet of things.

The first layer provides an interface to collect data from sensors such as cameras,

microphones, and others. Information collected is relayed through the second layer to the

Processing and extracting information. Several network interfaces can be used to make

the transference. In order to reduce the network bandwidth, some heuristics and protocols

may be implemented to improve the network performance. The third layer, Processing

2.2. ITS OVERVIEW 11

and Extracting Information, has basically two roles: 1) to implement the algorithms to

extract data from sensors; 2)to use the extracted data for identifying events according to

policies for local transit. This layer can encapsulate data fusion algorithms that discover

relevant information out of the traffic. The last layer receives data from the previous layer

and releases it for end-users through a software interface.

An drawback in the architecture shown in Figure 2.1 is the need of a large network

bandwidth. This fact increases the cost to implement ITS solutions. In the next section

this problem is exposed in details.

2.2 ITS Overview

Intelligent Transportation Systems (ITS) is a research area that seeks through technological

and autonomous mechanisms the efficient management of traffic. There are records of

researches of at least two decades [13].

Indeed ITS plays an important role in society, for instance the increasing the flow of

vehicles in large cities demands new plans and acts for transit. Some examples of problems

treated in ITS are, to optimize vehicles flow reducing the traffic congestion, improve traffic

security and pedestrian security, to build infrastructures self-sustaining that reduce the

environmental degradation.

Government leaders of some countries tend to publish local challenges and target to

guide research on ITS [11].

Linjing [12] shows that the United States and Asia are leader researches related with

ITS. China, Japan and Taiwan, respectively, act with the major researches, followed of

European countries as shows the 2.2. These countries typically rely with on incentives of

the public sector and private companies which contribute to the success of the projects.

Figure 2.2(a) shows the number of publications among years 2000-2010. Figure 2.2(b)

shows the number of citations of the same countries at the same period.

Researches related to ITS in Brazil are not traditional, although the federal government

through its public services, such as CNPq, invests in projects for cities working for solutions

to the traffic. This is also the case of BHTRANS, the transportation and Traffic Company

of Belo Horizonte city, whose is linked with the Belo Horizonte City Council and maintains

projects to improve the traffic conditions [5]. In the section 2.1 was described the Olhos

da Cidade project which has partnership with BHTRANS and CNPq.

The researches in ITS involve several multidisciplinary areas in order to collect, treat

and extract information. In particular we can cite digital image processing with its diverse

sub-areas, optimization, embedded systems, distributed systems, network, wireless sensor

network and data mining. Data fusion is another important area of success of ITS. This

technique is used by military department to monitoring and events detection of environ-


Figure 2.2: Impact of Productivity by Country.(a)Number of Publications. (b) Number of

Citations. Figure reused from [12].

ments [8].

The ITS infrastructure is composed by static and mobile nodes. These components

work as sensors sending data for the applications that provides services for end-users.

Follow both nodes are explained.

On-Board Units (OBU) are devices installed in vehicles in order to process local data

and enable the communication with static devices. Its use increased significantly in the

last years [4]. In its turn, Roadside Unit (RSU) is a static element of a structured net-

work that works like a wireless access point, usually providing an interface with the ded-

icated infrastructure to process data and generate information, in order to allow traffic

controllers to make decisions over traffic conditions. OBU devices can be used to provide

Vehicles to Vehicles (V2V) and Vehicles to Infrastructure communications (V2I) (when the

OBU communicates with the RSU). V2V is usually composed by an unstructured network

characterizing an ad-hoc network, in this case referred to as Vehicular Ad-Hoc Network

(VANET).

ITS researches usually start of the application domain, and in the most recent publi-

cations the applications are related to the traffic management in urban streets and roads.

New proposals appear to reduce the time spent by vehicles in urban areas, to reduce the

lock on the traffic [13] and to reduce the accidents in roads.

The data collection is performed by electronic sensors where mostly corresponds to

digital or analogical cameras. Devices as microphones, presence sensors, radars, among

others can be used, but they are not enough to collect and treating of several kind of

2.3. SOA 13

information. The combination of among these devices with appropriated algorithms to

process signal or the image is the best way to extract relevant information about traffic

conditions. In the literature, the cameras are the sensors most used, as well as the digital

image processing, is the technique most used to extract data for ITS solutions [13], [20].

2.3 SOA

Service-Oriented Architecture (SOA) is a software paradigm based on services available

to users3. The paradigm is represented by a process called “find-bind-execute”. Three

components are defined to perform this process: the Service Requester, the Service Provider

and the Service Broker. The Service Requester represents the module that searches for

available services. It requests to the Service Broker, which knows all services available.

Service Provider corresponds to an interface that provides and deliver the services to the

users. Each Service Provider publishes its services on the Services Broker. In case of a

Service Requester queries a service(find), the Service Broker redirects it to an available

Service Provider (bind). At this point, the Service Requester communicates directly with

the Service Provider (execute).

Web Service is a SOA implementation that integrates the three components4. There

are four different open specifications. 1) The XML pattern to structure the messages; 2)

Simple Object Access Protocol (SOAP) based on remote method invocation5. SOAP does

not dependent on semantic programming model, hence the existence of a consolidated stan-

dard that can be used in Web Services; 3) Web Services Description Language (WSDL)6,

designed by W3C, which is the pattern that allows development of the Web Services and

releases it; 4) Universal Description, Discovery, and Integration (UDDI)7, that perform the

three functions Find-Bind-Execute. The XML is the structure of message, SOAP transfers

it, WSDL releases the services, and the UDDI lists them.

The framework proposed on this thesis is based on SOA architecture. The Service

Provider represents sensors connected embedded devices, able to process the data from

these sensors. In our architecture, the Service Broker is called the Service Mediator. It

is a passive server in which knows the services that each Service Provider releases. The

third component is the Service User that performs the Service Requester role. Chapter 4

describes all components in detail.

3Web Services Architecture. http://www.w3.org/TR/ws-arch/. Accessed March 20124Service Oriented Architecture Standards. http://www.w3.org/2007/01/wos-papers/boeing. Accessed

March 20125Simple Object Access Protocol (SOAP) 1.1. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.

Accessed March 20126Web Services Description Language (WSDL) 1.1. http://www.w3.org/TR/wsdl. Accessed March 20127UDDI Version 3.0.2. http://uddi.org/pubs/uddi-v3.0.2-20041019.htm. Accessed March 2012


2.4 ANDROID

Android is an operating system (OS) based on Linux, and was developed to run in embed-

ded devices as smartphones and tablets. The Android OS project was started by Andy

Rubin, founder of Android Inc., a small company from California USA. The objective of

Rubin was to develop an open, flexible and of the easy migration platform for mobiles of

the several manufacturers.

In 2005 the Google company purchased the Android Inc. in order to enter in the

mobile market. The Google announced in 2007 the Open Handset Alliance8, a group of

86 companies of the hardware, software and telecommunications, focused to develop a

standard OS for mobile devices. To implement the project, the Google company released

the Android OS as open-source under the Apache License. Nowadays the Open Handset

Alliance is composed by 84 companies as Samsung, LG, ARM, Texas Instruments, eBay

and others.

The Google company release in 2008 the first mobile embedded with Android OS in

the USA and Canada. In 2009 the HTC Dream was released (with the Android version 1.0

until 1.6, although the 2.0 cracked version was used to provide the touch screen function)

in Europe, Australia and some countries of Asia. On April 2009 was announced one billion

devices sold around the world, this fact shows the relevance of the alliance for the mobile

market. In 2011 the first Android version was released to tablets. The Motorola Xoom

was the first commercial tablet released with the Android 3.0 Honeycomb version.

The Android was built under Linux kernel, its libraries, and middleware were written

in C. The Android OS implements the Dalvik virtual machine, a just-in-time compiler

that translates the Dalvik dex-code (Dalvik Executable) in java bytecode. The Dalvik

virtual machine, optimizes the use of hardware resources (memory, processor). This fact

brings several benefits, for instance the increasing of the time life of the battery. This is

an important point considering that the battery is crucial of mobile devices.

An API was developed by Google to design Android applications. This API is part

of Android’s core, and developers can use the Android SDK to create their applications

using the Java syntax language. This API provides several advantages, in particular by

run together the Dalvik virtual machine. For instance, the Android OS avoids the context

swap with the use of Resource Manager provided by the API. So, optimizes the use of

processor and memory, consequently the battery consumption.

The Android’s libraries contemplate a set of resources that raise productivity of devel-

opers. For instance, the developers can use the SQLite, a native data base, the OpenGL

to draw complex interfaces and libc. These are some examples of libraries available to use.

Figure 2.3 shows the Android OS layers.

The Application Layer encapsulates the natives and user mobile softwares. The An-

8Open Handset Alliance. http://www.openhandsetalliance.com/. Acessed March 2012

2.4. ANDROID 15

Figure 2.3: Android Architecture.

droid’s developer can use a set of resources available on the Application Framework layer.

This layer provides access in resources available by devices that can be used by the same

SDK. The Linux Kernel layer corresponds the modified Linux kernel that encapsulates the

several algorithms to manage the hardware and software according with requirements of

mobile devices. On the Android API there is an interface called Services, which is used

on applications that need to perform actions on Background, or applications that do not

require long interaction with the user 9. Threads are alternatives of Services. The An-

droid OS creates a new process when the developer uses the Service implementation while

that, Thread is a part of a process. Because of this, Services can encapsulate the Threads.

On Android conception to manage Services is better than Treads, since the O.S. provides

mechanisms to reduce de battery consumption.

We consider this fact an important feature to develop our solution, since the optimizes

the use of resources. In the Android OS, a Service can share its data with another instances

of Services. For this platform, it does not matter if the Services were created on the same

application, the main idea is share all possible data according with the authorizations

9Service—Android Developers. http://developer.android.com/reference/android/app/Service.html.

Accessed March 2012


specified by application’s developers. Another relevant fact to choose the Android as

OS as platform of our solution, is the support gave to integrate the applications with

services available by Google. In the ITS scenario we can use Google services to delivery of

information for end users.

2.5 Advanced RISC Machine - ARM

The Advanced RISC Machine, ARM architecture 10, is the most common 32-bits RISC set

instruction used in embedded devices such as smartphones, tablets and several electronics

equipments. Built by ARM Holdings, a British multinational semiconductor company,

the ARM architecture was licensed by several companies such as Apple Inc., Microsoft,

Nitendo, Sony, Texas Instruments and others.

The ARM technology has diverse families of processors with a large core of products

with advanced resources, that reduce the cost of processing and increases its performance.

Nowadays in the list of the licensed products can be found processors with the technologies

single-cores, dual-core and quad-core. Some processors even are integrated with Digital

Signal Processor (DSP). This is a relevant feature for this project, considering that it

requires processing data from sensor such as camera, microphones and others.

The ARM processors has a large support to embedded OS such as Windows CE, An-

droid, Symbiam, Linux, and real-time OS such as QNX. A range of development boards

were designed to create and evaluate the prototypes. In our case, we use three equipments

to develop, run and evaluate our solution described below.

Figure 2.4 shows a image of the Texas Instruments AM3517 board evaluation module

(EVM). This device is composed by an ARM Cortex-A8 processor with 600MHZ, single

core, 256MB DDR2 and 512MB NAND. This EVM contains diverse interface of connection

such as USB, Bluetooth, WLAN, and offers support to connect camera as well as video

input.

The EVM has support for the operating systems Android, Linux and Windows CE .

We define the Android as the official platform to develop the first version to the proposed

framework.

Other model of device used was the tablet Motorola Xoom as shows Figure 2.5. The

device corresponds to the first tablet with Android OS Honeycomb v3.0 released. The

Xoom tablet was built with an ARM Dual-core 1GHZ Cortex-A9 processor, 1GB RAM and

GPU GeForce. The Motorola Xoom has sensors as accelerometer, gyroscope, barometer,

compass and network interfaces such as wireless 802.11 b/g/n, 3G and bluetooth 2.1.

Figure 2.6 shows the third model of device used. Treat of a mobile Sony Xperia X10

with Scorpion 1GHz processor, single-core, 384 RAM, a GPU Adreno 200, and OS Android

10ARM The Architecture for the Digital World. http://www.arm.com/. Accessed March 2012

2.6. CONCLUDING REMARKS 17

Figure 2.4: AM3517 Evaluation Module.

Figure 2.5: Tablet Motorola Xoom.

v2.3. This equipment contains the sensors as accelerometer, proximity, compass sensors,

wireless interfaces 802.11 b/g/n, 3G and bluetooth 2.1 connections.

2.6 Concluding Remarks

This chapter has presented the concepts and technologies related to this work. First, we

have presented the “Olhos da Cidade” project which motivated this work. An overview

about ITS has been presented. The solutions used to develop this work have been described.

The Android OS was chosen together with the ARM architecture as platform to create the

SPs components, and they have been presented. We were motivated to use Android due to


Figure 2.6: Mobile Sony Xperia X10.

the large number of embedded devices available with this technology. We were motivated

to use ARM because it has support to several embedded OS. This is an important feature

to provide interoperability. The Android OS includes a development API that facilitates

the integration with many services available for end-user such as Google Maps. Another

relevant fact for our choice was the way which the OS manages its resources. For instance,

the operating system is able to reduce the battery consumption.

Next, the related work is described along with the relationship with IDEAL-TRAFFIC.

Chapter 3

Related Work

In this chapter the related work is presented. The studies are presented from the most

relevant to the lest relevant in comparison to our approach.

Study [2] proposes a novel crowdsourcing system for ITS. The system, called CrowdITS,

enables drivers to notify traffic events from a smartphone or a PDA device. The authors

describe their motivations based on the possibility of creating applications that do not

need infrastructure with sensors on the roads. Figure 3.1 shows the architecture of the

CrowdITS. The system has three major components: 1) Sensing and Interface; 2) Informa-

tion Processing; and 3) Localized Device Messaging. The Sensing and Interface component

corresponds of the Smart Mobile Phones that is an interface for users to make their noti-

fications. Component Information Processing is formed by the CrowdITS Server(s), and

component Localized Device Messaging is formed by the Google’s C2DM (Cloud to Device

Messaging), a service provided by Google that gives support to authenticate the users in

the CrowdITS.

In our vision, this is a kind of solution that solves only part of the ITS problems. A

crowdsourcing system can increase the risk of accidents, since the driver needs to interact

with his/her smartphone or PDA while driving. The system considers that most drivers

on the road have access to the Internet to notify the events. This is not a true fact in every

countries.

In our conception this is a kind of system that should give support on ITS. In our work

we exemplify a use case that show the integration of a crowdsourcing system with the

IDEAL-TRAFFIC. In Chapter 6 we show that IDEAL-TRAFFIC is able to receive data

from legacy systems as CrowdITS is.

A context-aware problem solution using the SOA components is introduced in [1]. The

authors create the framework called LOCA that uses the SOA architecture to redirect

users to available services, based on user location. Figure 3.2 shows the architecture of

the LOCA framework. LOCA is the most similar service-oriented architecture framework

found in the literature when compared with our solution. The figures used to describe our

19

20 CHAPTER 3. RELATED WORK

Figure 3.1: System Architecture of CrowdITS. Figure reused from [2].

solution in this thesis were inspired on [1].

The services provided by LOCA are classified in to four categories, and each one has

other sub categories. This fact improves the search process by reducing the time to bind

users in a service provider. Considering that LOCA is a context-aware application, this is

a relevant feature. Although LOCA has many benefits, the authors did not mention any

case of adding categories into the service classification. This is a weakness of the framework

considering the scalability of the system and its openness, in order to be used in a large

range of scenarios. Another point to be considered is the fact that the framework does not

provide a solution to manage failures of any component. The LOCA was experimented for

searching services available for tourism and the authors did not mention its use for ITS,

although we consider this is possible. Furthermore, there is no management support.

Study [10] shows a service-oriented architecture running together with wireless sensor

networks. The proposed system was divided on three modules: Monitoring, Management

and User. The system corresponds to an ITS with a wireless sensor network on a parking

to obtain the parking spot.

The authors launched their experiments using sensors in a parking. The collected data

were sent to the Management module. This module is a complex system that shows at real

time the state of the parking. Two applications were developed in the User module, one

for users to query the state of the parking using their PDAs or smartphones, and another

application to show the information on a Google Web interface which was developed with

the Google Maps’ API. Although the proposed system uses the SOA architecture, its

21

Figure 3.2: System Architecture of LOCA. Figure reused from [1].

architecture is centralized.

The User module makes queries to the Management module as Figure 3.3 shows. This

fact violates the SOA architecture conception, since the role of the Management module

is to manage the state of the providers, in this case the sensors in the parking. Another

characteristic of the Management module is to bind the User module in the WSN nodes.

Moreover, on the proposed system there is no concern with any requirement of ITS.

TRAVIS is introduced by [17]. It corresponds to a client-server infrastructure built to

collect data from an Autonomous Tracking Unit (ATU). The ATUs are small computers

linked to cameras, and have many modules to extract information from the video stream.

The final outputs of an ATU are parameters with information of the monitoring area.

These information are sent for the central Sensor Data Fusion (SDF), which applies the

application rules using data fusion techniques. A channel was built as backup to transfer

compressed video stream in order to assist operators in case of an incident to be reported.

Although TRAVIS uses simple computers to process data locally, the application rules

are defined in the SDF component. In the IDEAL-TRAFFIC, the SP acts as ATU, can

fuse data through its cooperative characteristic, if a set of SPs were configured to work

together. This configuration also allows an SP to assume the role of another SP that turns

off.


Figure 3.3: Architecture of Parking Management System. Figure reused from [10].

Moreover, the TRAVIS paper [17] does not mention about the fault tolerance of the

system. In case of failure of some ATU, the application may be invalided. In our solution,

a process of adaptation is designed to cover this requirement, which is very important in

ITS.

The U.S. Department of Transportation developed the National ITS Architecture

framework 1, a solid model that considers physical and logical architectures besides stan-

dards to implement ITS projects in the country. The architecture view is presented with

three layers: Institutional, Transportation and Communications, as shown in Figure 3.4.

According with to documentation, the Institutional layer is shown in the bottom due to

the solid institutional support and the possibility of taking effective decisions by companies

and stakeholders. They show that is is a prerequisite for an effective ITS. The second layer,

Transportation, is the kernel of the National ITS Architecture, since in this layer the sub-

systems and interfaces for each transportation service are defined. In the third layer, the

requisites for integration of the systems are defined, the technologies and communication

services that National ITS Architecture supports are described.

The National ITS Architecture also provides a set of services for users, which is that

were summarized in Table 3.1. Every service corresponds to a subsystem released for

end-users or traffic administrators.

FRAME 2 is a similar framework used in Europe to create ITS projects. FRAME

was originally published in October 2000 by the name of KAREN. The current version of

FRAME is 4.1 and it supports a similar set of services of the North American framework.

Figure 3.5 shows the FRAME general architecture. One point of interest of this thesis is

the support for cooperative systems, which exists in the current version of FRAME as well.

Such as the National ITS Architecture, FRAME has a set of documents with standards

to create ITS solutions. Table 3.2 shows the benefits of FRAME described in its website.

1The National ITS Architecture. http://itsarch.iteris.com/itsarch/index.htm. Accessed on March 20122The FRAME European ITS Framework Architecture. http://www.frame-online.net/. Accessed on

March 2012

23

Figure 3.4: The National ITS Architecture. Figure reused from

http://itsarch.iteris.com/itsarch/index.htm.

Table 3.1: National ITS Architecture User Services

User Services

Travel And Traffic Management

Public Transportation Management

Electronic Payment

Commercial Vehicle Operations

Emergency Management

Advanced Vehicle Safety Systems

Information Management

Maintenance And Construction Management

A subproject of FRAME is called E-FRAME. It provides support for the creation of

inter-operable and scalable cooperative systems. According to their website, E-FRAME

provides a center of knowledge that is commercially and politically neutral, and that ser-

vices everyone’s long term interests.

The E-FRAME objectives are:

� To extend the European ITS Framework (FRAME) Architecture to include cooper-

ative systems.

� To show how the Extended FRAME Architecture can be used to develop and imple-

ment cooperative systems in members states, regions and projects.

� To provide advice on the capture of deployment and operational issues for a given

ITS architecture.

� To study the standardization issues for cooperative systems highlighted by given ITS


Figure 3.5: The FRAME ITS General Architecture. Figure reused from http://www.frame-

online.net/.

Table 3.2: FRAME Benefits

Description

Can be planned in a logical manne

Integrates successfully with other systems

Meets the desired performance levels

Has the desired behaviour

Is easy to manage

Is easy to maintain

Is easy to extend

Satisfies the expectations of the users

architectures, and to create a set of recommendations for the appropriate organiza-

tions.

� To organize working groups, seminars and workshops for all stakeholders to study

the business cases for.

� To provide advice and guidance on using the Extended FRAME Architecture.

The North American and European frameworks have natural maturity after years of

development. Our proposed solution was based on their documentations. We have not

found any explicit information about the requirements of applications. Table 3.3 presents

some noticeable requirements read on the documents.

Reference [14] presents the iTransIT, a framework based on FRAME, experimented in

Ireland. The basic objective of iTransIT is to provide a layer that connect current legacy

25

Table 3.3: National ITS Architecture and Frame Requirements

Description National FRAME

Integration with legacy systems and subsystems x x

Scalable x

Cooperative Systems x

To Provide an end-user interface x x

Security x

Easy Management x

systems to the new proposes systems. The integration with legacy systems is a basic

requirement for ITS solution architectures. Figure 3.6 shows the proposed architecture

which is explained next.

Figure 3.6: iTransIT Framework Architecture. Figure reused from 3.6.

The Legacy Tier provides the integration of legacy systems that are not in accordance

with the iTransIT system architecture. The iTransIT Tier provides an interface to inte-

grate the traffic systems developed according to the iTransit requirements and patterns.

The Application Tier provides information about the traffic for end-users.

The IDEAL-TRAFFIC also allows the integration with legacy systems. Our framework

ensures that a given legacy system can provide information for the framework (input), as

occur in the iTransIT, as well as send information for legacy systems (output). The iTransit


uses the Corba3 and WebServices4 to provide communications, while the IDEAL-TRAFFIC

is open for developers to implement their protocols. In the version used in this thesis it

was experimented http connection and the SOA standard communication.

An autonomous group-management applied for Intelligent Transportation System is

presented in [18]. The authors proposed a system where each sensor unit is autonomous

by forming groups without an external centralized manager. This approach was applied on

the Vehicular Network (VANET) where the vehicles send their data for an station base. In

this thesis we describe a use case in Chapter 6 where the integration of the framework with

VANET is shown. In this case the user requests a service, and the VANET self adapts to

find the solution.

Fujimura [9] shows an infrastructure that prevents accidents in case the traffic is down.

Through the extraction of data from images provided by cameras on the road, the system

sends alerts to drivers in case of identifying some obstacle. In this proposal, the authors

do not mention about requirements of ITS projects. For instance, the fault tolerance is an

important requirement for this application. The failure of some camera may uncover some

critical area.

An adaptation solution of semantic web services is shown in [19]. The authors state

that adaptation is an essential feature for the long-life of enterprise systems, which need

a higher level of autonomy to make changes on the applications, and keep it running.

They justify its solution since web services are frequently changed due to environments

requirements. IDEAL-TRAFFIC presents an autonomous adaptation process in case of

failure of components that provide services. Our approach differs from them, first because

we use the network topology to analyze the nodes that are available to participate of the

adaptation process. Second, we defined a protocol of readaptation in case the node resumes

its activities.

An ITS as multiple layers of integrated technologies is shown in [16]. The authors

presented a centralized infrastructure to extract the license plate of vehicles using cameras.

In the work it was presented the network, hardware, software, and database architectures.

This kind of architecture, although functional, is an example of critics that motivate this

thesis, since this architecture is hard to scale, maintain, and expensive to make redundance.

The authors do not mention about these characteristics on their system. So, some ITS

requirements are not covered by this infrastructure.

This chapter has presented the related work. Table 3.4 presents a comparison between

the IDEAL-TRAFFIC requirements and the related work. Note that IDEAL-TRAFFIC

accomplishes most of the requirements described in the related work. This fact shows that

the IDEAL-TRAFFIC is suitable for ITS applications. Some requirements are not cov-

ered by the related work, since these requirements are associated with distributed system,

3The OMG’s CORBA Website. Corba http://www.corba.org/. Accessed on July 20124Web Services Architecture. http://www.w3.org/TR/ws-arch/. Accessed March 2012

27

whereas all works are characterized as centralized system.

Table 3.4: Comparison of requirements among related work

Description National FRAME CrowdITS LOCA [18] IT

[15] [6] [2] [1]

Heterogeneity x x x x

Scalable x x x

Cooperative x

Systems x x

Accessibility x x x x

Security x

Easy x

Management x x

Adaptability x x x

Interoperability x

Openness x

Flexibility x

Next we describe the IDEAL-TRAFFIC framework.

Chapter 4

The IDEAL-TRAFFIC Framework

IDEAL-TRAFFIC is a context-aware monitoring, topology based framework created on

a SOA architecture. It enables end-users to access services and system administrators to

create applications. End-users search for available services, and then are forwarded to an

instance that is able to establish communication with them and provide the service. We

consider service as a set of available resources for users convenience. The composition of

different services can provide more specialized information to the users. This process is

called Services Composition (SC). This chapter discusses system requirements followed by

a demonstration of what constitutes the level of services in our architecture. Next, each

IDEAL-TRAFFIC component in the SOA architecture is presented.

4.1 The IDEAL-TRAFFIC SOA Architecture

Three elements constitute IDEAL-TRAFFIC: Service Mediator (SM), Service User (SU)

and Service Provider (SP). The SP element is the main component to perform an SC hier-

archy. This section describes the service composition conceptions, the IDEAL-TRAFFIC

overview, and details the three elements that composes the IDEAL-TRAFFIC.

4.1.1 Service Composition Conceptions

The higher the level, the more aggregated the rules will be. Figure 4.1 shows the SC

hierarchy. The two first levels are atomic services because is not dependent of another

service, for instance assume that the sensor is a camera, then the output of this service

could be a stream. Following the second level, the output could be a meta data such as

vehicle plate number provided by programs such as digital image processing. The result of

atomic services can be combined with other services, which may be provided by the same

SP, or by others. This combination defines the Service Composition (SC) conception. In

29

30 CHAPTER 4. THE IDEAL-TRAFFIC FRAMEWORK

our architecture, it was defined that the two first hierarch levels are integrated on the same

SP.

A concrete example of atomic services and SC can be seen below. Imagine a SP built

with a camera that is hanging on a light post on an avenue in a city. A person driving

his car will then use his mobile to consult the stream video available. This service is

considered atomic, once is not composed by another service. A second atomic level shown

in Figure 4.1 is called Meta Data. A program that counts the number of vehicles at certain

moment is an example of Meta Data. This counting could be done using a program with

digital image processing technique. The estimate number of vehicles in the next moment

could be available as first level of the service compositions. This service is a composition

of other instances of SP that take count of vehicles in other streets of the city, and that

are available to perform the formation of services in order to shape what we call ”the first

level of SC.” The results of this formation, put together with other services, perform what

we call ”the second level of SC”, or (SC-Level 2), and so on.

Figure 4.1: IDEAL-TRAFFIC Class Services new SCs. The SM component manages all

procedures, receives requests from SU, treats it, and collects necessary data from the SP.

4.1.2 IDEAL-TRAFFIC Overview

Topology is an important feature in the creation of SC applications. It was defined on the

IDEAL-TRAFFIC to maximize its functionalities. It is crucial information which enables

collaboration among several SP components.

The process of creating SC is made on a software interface which is provided by the

SU component. The system administrator starts the process by requesting the topology

network and available services. This information is used in an unique software interface,

for system administrator to analyze and compose.

4.1. THE IDEAL-TRAFFIC SOA ARCHITECTURE 31

The IDEAL-TRAFFIC framework architecture is presented in Figure 4.2. We prefer

to use an explanation on optics following a vertical order, from top to bottom. In this

explanation, we begin with the presentation of the SOA components, followed by the

detailed description of each component. All the graphics we used in this work, were re-

drawn, expanded and derived from [1].

Figure 4.2: IDEAL-TRAFFIC SOA Architecture.

The flow of communication between services usually starts when the SU submits a

request for an SC application. The request is directed to SM order to perform the mediator

role. There are two basic kinds of requests to be done by the SU, namely:

1. When the user is a system manager of the context. In that case, he builds SC

applications, either by consulting SC applications status that were already built, or

by modifying them. As a result, this user will contact the SM using a SU client

administrator software.

2. When the user is the end-user who wants to benefit from the results of SC applica-

tions. Then, he uses a SU client software which allows him to access the available

applications for end-users. The SM recognizes available applications, retrieves it to

SU client requests, and forwards the SU to a SP.


Communication among the three services may be performed by several network inter-

faces. In general, SUs are mobile devices that can found in the market today, such as

tablets and smartphones. These devices are created to work with a diverse set of wireless

technologies such as WIFI, Bluetooth, 2G, 3G and more recently 4G. It is also important

to take under consideration stationary devices, such as PCs, which may need cable, or

LAn, connections. Following the same pattern, SPs can be built in embedded platform to

work with the same interfaces, cabled or not. Communication between the SU and the

SP is evident since both share the same technology. Usually the SM is allocated on data

center, and has a more restrict wireless technology. These devices work over LAN, WAN

and MAN networks.

The services can establish communication using the HTTP (Hypertext Transfer Proto-

col), SOAP (Simple Object Access Protocol), WSDL (Web Service Description Language),

and UDDI (Universal Description, Discovery and Integration). Figure 4.1 shows the com-

munication among services.

In the Service Composition, the SP which receives data from a peer is called parent

of this peer. Figure 4.3 shows three examples of compositions. The arrows from children

to parents are used to illustrate the child/parent compositions. Figure 4.3a is the simple

instance of child/parent design. Figure 4.3b shows a parent SP with multiple children.

In this case, the parent performs the fusion of data from all children composing the SC

application. The output of this service may be used in other SC formations as shown in the

Figure 4.3c. A parent SP itself can generate events to combine with their children’s events.

Another role of the parent is to combine events from all children and send it for some web

server or legacy system. The higher the Services Composite level the more specific it is.

(a) (b) (c)

Figure 4.3: Three Example of the IDEAL-TRAFFIC Configuration. (a) Child and Parent

nodes. (b) A Parent and multiple Children. (c) A Parent and multiple SC Children.

A Provider is any element able to receive events from any IDEAL-TRAFFIC SP. By

convention, all parent SPs in the IDEAL-TRAFFIC are Providers. Other examples of

Providers are private and public data centers, cloud computing infrastructure and legacy

systems. Each SP needs to instantiate at least one provider to send its data. Actually, in

an SP there is no limit for instantiating Providers. This limit depends on the context and


the application level requirements.

For our purpose, RSU and OBU devices are built as SOA SPs components. Thus, from

this point on, every reference to RSU and OBU is equivalent to the IDEAL-TRAFFIC SP

component.

Next describes each component of IDEAL-TRAFFIC and their roles.

4.1.3 IDEAL-TRAFFIC Service Mediator (SM)

The IDEAL-TRAFFIC SM is a central element that mediates the communication between

SP and SU, and it manages the status of network and the state of the SC applications.

These components are responsible for analyzing the request and delivery of the correct SU

data according to the type of request being made. Requests that are related to adminis-

trative tasks are queried in the SM database and forwarded to the SU. The SM manages

the network topology and discovers services on the SPs. This information is delivered to

the SU administrator interface.

For a end-user request, the SM queries the properties of available SC and sends this

information to the SU interface. After the end-user has chosen the service, the SM binds

its SU in the correspondent SP. The Figure 4.4 shows the interaction among internal SM

components. Each one is described in detail below.

Figure 4.4: IDEAL-TRAFFIC Service Mediator (SM).


Topology Manager

This component is responsible for updating information about its peers connections. A peer

connection corresponds to two or more SPs that are in the same range of communication.

A database is defined to store data in secondary memory. The topology scanner occurs

through the topology MatchMaker element. This update occurs after a SU requests the

topology of SPs. The Topology Manager establishes connection with the SPs and then

requests their peers. The Topology Manager merges the data received from SPs and sends

the result to the SU requester. The MatchMaker uses the SOA protocol to perform the

communication among SPs and SUs. Hence, the data is exchanged through an XML file.

Service Finder

This component retrieves from SP the services available. There are two strategies for the

SM to update the list of services. First, each SP manages its services autonomously, then

these services do not need to be registered on the SM database. This strategy is interesting

when there is a large number of SPs in communication with SM, since the services can be

updated on demand. Another evident advantage is the fact that the information can be

saved only in the SPs, hence there is an economy of secondary memory in the SM. The

second strategy considers the fact that the list of services to be modified in case a SP has

been updated. In this case, the SP sends its new services for the SM to register them

in the persistent module. This strategy is interesting when the SM has large resource of

secondary memory. The advantage of its use is to save time to retrieve the data, since it

is kept locally into a database.

Application Manager

This component is responsible for keeping application properties updated. When system

administrator compiles an application it is registered on SM component and saved on the

database. An application is composed by one or more SP, and each one has its business

rules implemented on each SP. These rules are based on context-aware and a sample of it

is defined and detailed on SP section explanation.

Communication Manager

This component encapsulates the interface to communicate with other components such

as SPs. Each module corresponds to an interface with a specific task.


4.1.4 IDEAL-TRAFFIC Service User (SU)

IDEAL-TRAFFIC SU corresponds to an interface to user request in the SOA architecture.

This component is composed by a friendly human interface which establishes connection

with the services and provides data to the users. Users typically stipulate mobile devices

like smartphones and tablets, as favorite hardware to carry out the communication. The

communication process happens through the SU request made for the SM. The latter treats

the request and retrieves the related information by user. Two interfaces are proposed in

the IDEAL-TRAFFIC, 1) An user interface to manage context-aware applications. 2) An

user interface to request the services available for users. The former is dedicated to system

administrators, while the latter is for final users who benefit from the several services

available on SPs. Figure 4.5 SU components.

Figure 4.5: IDEAL-TRAFFIC Service User (SU).

User Application

This is an application that will be downloaded by end-users, who will interact with the

services created with the IDEAL-TRAFFIC framework. This module can be used in mobile

devices, desktop applications, or running on WEB browsers.

Administrator Application

It is an application to manage the services. This application enable systems administrator

to create, manage and modify the services.


4.1.5 IDEAL-TRAFFIC Service Provider (SP)

The IDEAL-TRAFFIC SP is the main element to compose the SC application. The com-

ponent usually is linked to sensors and knows programs to extract information, or composes

the data received by other SP component. After SP receives the message of registry in a

SC, SP often scan its parents, and in the case of discovering some failure, the SP starts

the adaptation process. The modules that perform SP this role are described below.

Figure 4.6: IDEAL-TRAFFIC Service Provider (SP).

Data Extractor

This component encapsulates all algorithms that can extract data from sensors. This

component is usually linked to one or more sensors. Processing digital image and signal

processing are examples of techniques to be implemented on the Data Extractor component.

In addition, this component can implement an interface to carry out communication with

other modules not implemented over IDEAL-TRAFFIC framework, such as legacy systems.

Repository

After Data Extractor extracts the data from a sensor, the data are sent to Repository.

Note that the triple component (Data Extractor, Analyzers and Repository) comprises the

knowledge producer/consumer problem. Data Extractor works as producer and Analyzer

works as consumers.


Analyzer

The Analyzer receives extracted data from the Data Extractor and processes it according

to the rules of previously established SC applications. This component is responsible for

generating SC applications. It can be used in two ways. The first way is working as a filter

to validate data. For instance, when counting the number of cars, it filters the information

to determine if the data form a number or an alphanumeric element. The combining of

this information with the amount of vehicles from other SPs generates an SC application

with more precise data. Analyzers implements kernel of application, and defines what data

will be notified by some SP. This process depends on the application rules established by

the analyzer.

SC Properties

The module encapsulates properties of a registered SC in which SP is a participant. This

module is fundamental for the process of re-establishing a SP on an application.

Notifier Strategy

The component receives events from Analyzers and decides how these events will notify an

SP. Different events can be submitted to SPs. For example, the system administrator can

decide if the information will be delivered to a private data center, while at the same time,

delivering it to the SU client application. In this case, the Notifier Strategy recognizes

two Notifier objects that will forward that information. Each Notifier corresponds to one

target SP.

Notifier

The Notifier recognizes the protocol communication between local SP and the destination

component. It encapsulates the properties necessary to establish communication. This

component is instantiated by the Notifier Strategy, which makes the decision to forward

data to a particular event. For instance, if the system needs to send an event to a Google

service, the Notifier encapsulates the protocol that establishes this communication. An-

other example is the communication between the SP components. The Notifier develops

the client role of a client-server protocol, which is defined in order to exchange data be-

tween IDEAL-TRAFFIC SPs components. On the other side, the Data Extractor also acts

as a server.


Scanner Policy

This component plays the role of verifying if the SPs peers that are registered in SC are

also linked. The Scanner Policy implementation may be a simple ICMP protocol, or a

more advanced technique that helps manage devices such as Simple Network Management

Protocol (SNMP). The Scanner Policy component works together with the Adaptation

Strategy component.

Adaptation Strategy

This is the strategy designed to adapt the SC in case of a failure of an SP element partic-

ipant. Each developer can implement it adaptation strategy.

4.2 IDEAL-TRAFFIC Network Management and

Service Management

This section describes the management process proposed in the IDEAL-TRAFFIC. First,

we will define the requirements used for system administrator to create services. The same

requirements are used by the framework that makes the adaptation process. Second, we

will present the process of service creation, and then the adaptation and readaptation

processes will be explained.

4.2.1 Requirements Classify

IDEAL-TRAFFIC offers an interface that can be used by the system administrator so

that he may generate services and SC based on SP network topology. IDEAL-TRAFFIC

framework is composed by an autonomous module that manages the adaption of the service

whenever a SP participant becomes unavailable. To provide this autonomous management,

the SP needs to know the requirements of the registered service. For instance, if a service

requires network connection that is able to transfer stream video, this requirement will

need to be analyzed by the SP before it carries out the adaptation process. Network

properties are requirements that must be analyzed by SP. Hardware performance is another

requisite for the SC. In the case of a service that was built for road monitoring, the

location of the SP can be used as an example of the requirement for the can be used as

an example of the requirement for the domain level application. The SC application rules

are the most difficult information to manage, for the reason that they can be changed by

means of topology modification. The different categories resulted in a classification of SC

applications requirements. Figure 4.7 shows the definition.

4.2. IDEAL-TRAFFIC NETWORK MANAGEMENT AND SERVICE MANAGEMENT 39

Figure 4.7: IDEAL-TRAFFIC Requirement Classification.

Each SP needs to save a list of its own available services that have been classified with

the same hierarchy requirement. This organization is necessary, since in the SC creation

processes and adaptable process, requirements services will be compared with the same

classification. The communication between SPs is performed by SOAP protocol which

uses the XML structure to transfer messages.

4.2.2 Service Creation Process

The process of SC creation involves the three SOA IDEAL-TRAFFIC components. The

SU is the interface which user interacts to design and registry the SC. The SM discovers

the topology and delivers it to the SU in order to show the information. In addition, the

SM communicates with the SP to retrieve the list of services available in each one, as well

as their connections, in order to form the network topology. The steps to create the SC

using the IDEAL-TRAFFIC components are described below.

Step 1

A logged system administrator calls the function to create an application in the SU. At

this point, the SU has retrieved the topology of network formed by SPs. The system ad-

ministrator then selects possible candidates with services in order to form a SC. Remember

that each SC has autonomy to change its list according to its state. The Figure 4.8 shows

this process. The elements having a List of Services attached to them correspond to the

possible candidates List of Services attached to them correspond to the possible candi-

dates selected by the system administrator. The other SPs are SCs available to use at that

moment.


Figure 4.8: Step 1 - Topology and Services.

Step 2

In this step, system administrators have already chosen the SPs that will participate to

the SC. In the case of Figure 4.8, SP 13 has not yet been chosen, since the service need to

perform SC is not available on it. The 9 until 11 SCs will participate of the SC. Note that

each SC selected has connection with more than one peer, Figure 4.9. System administrator

chooses how each node will establish connection to form a new sub graph, Figure 4.10.

Step 3

The system administrator configure final rules and properties in the SC, then validates

it and sends it to SM to be registered. The registry is done in the SM, which saves the

general information of the SC application. SM generates a SC identifier (id) and sends it

to each SP participant. The SPs register the SC identifier (id) and sends it to each SP

participant. The SPs register the id together with the SC properties.

4.2.3 Adaptation Process

The adaptation process does not dependent on human intervention. This is a very beneficial

feature, since the SC is able to continue to run in the case of SP failure. The adaptation

process can promote changes in the application rules. One solution for this problem is

the creation of different adaptations strategies. Each one of these priorities has a priority,

determined by the system administrator. If the higher priority established cannot be built,

then the SP will try to build the next, until the defined strategies are completed. If the

4.2. IDEAL-TRAFFIC NETWORK MANAGEMENT AND SERVICE MANAGEMENT 41

Figure 4.9: Step 2 - SP Selected to SC.

Figure 4.10: Step 3 - Subgraph of SC Topology.

system administrator does not define any strategy, the SP will only analyze hardware and

network interface requirements, as explained on Figure 4.7.

Failure Adaptation Process

The sub graph on Figure 4.10 illustrates this adaptation process. For instance, it assumes

that the SP 9 sends its results to SP 10; that the SP 10 sends them to the SP 11 and that

the SP 11 sends the results to the SP 12. Then, by definition the SP 10 is named ”parent”

of the SP 9. In the IDEAL-TRAFFIC framework, all SPs ”children” are responsible for

verifying the connection with their ”parents”. We use this definition because if a parent

stops working, the ”child” tries to find another ”parent”.

In our scenario the SP 9 realized that the SP 10 had turned off by means of the

Scanner Policy component. Consequently, the SP 9 sent a broadcast message to identify


candidates that could assume SP 10’s place. Note that in the Figure 4.8, SPs 8, 11 and

12 are candidates. In our explanation, due to a requirement, SP 8 cannot perform SP 10’s

role. SP 11 was chosen because it was available and it was also the first in the priority

queue. The new connection is shown in Figure 4.11. After establishing new connections,

a new SC topology is registered on the SM.

Figure 4.11: SP 10 Failure.

SP Readaptation Process

In the case that SP10 may resume its activities, a process will be initiated as an attempt

to readapt the component. The faulty component, namely SP10 in this case, is responsible

for the management of all the procedures involved in the readaptation. SP10 will then

need to establish a connection with the SM, seen that it is aware of the current status of

the application which the SP10 held before it had gone off-line. If the application remains

active, the readaptation procedure will then take place.

After booting, the SP 10 collects in its database the information of its last state.

Information on the SC(s), in which SP 10 was a participant, is retrieved. As a first step,

SP 10 sends to SM a message to confirm if the retrieved SC is still registered in SM and if it

is authorized to start the Readaption process. If positive, the process continues, otherwise

it stops. Upon receipt of the authorization, SP 10 starts a procedure of communication

with its peers. In this case, SP 9 and SP 11. Both peers were retrieved from SP 10

database. SP 10 then, multicast a message to its peers inviting them to re-establish SC

participation. If SP 9 and SP 11 responds by demonstrating that they are able to receive

SP 10 in the application, SP 10 will build the necessary services and synchronize them

with SP 9 and SP 10. SP 9 and SP 11 receive the message, and communicate the changes

in SC topology with their current peers. The SC topology is registered on the SM and

each SP carries out the necessary registries in its database.

Note that this process can be used as a proactive strategy to save energy in SPs that

are built with batteries. System administrators could determine and activate this behavior


during SC process creation. This alternative shows that IDEAL-TRAFFIC framework is

flexible and ready for changes depending on different situations.


This chapter has described the IDEAL-TRAFFIC framework and its components: Service

Mediator (SM), Service User (SU) and Service Provider (SP). The Service Composition

(SC) conception has been described. We have also discussed the adaptation and readap-

tation processes, which treat failures and resumes of an SP. The adaptation process is

dependent of the SPs network topology and of the application rules defined by the system

administrator. Next we describe the IDEAL-TRAFFIC software and hardware conception.

Chapter 5

Building Applications over

IDEAL-TRAFFIC

This chapter describes the hardware and software architecture required for using IDEAL-

TRAFFIC including details about the system implementation. First an overview about

all the components and their interaction is described. Next, the details of each IDEAL-

TRAFFIC SOA component are exposed. The model of XML

le received by an SP from an SM is explained in Appendix A.

5.1 Overview

For the system to provide every functionality proposed, some software and hardware re-

quirements are imposed for each component. Figure 5.1 shows the macro view of the

three components. Each component has three layers: Hardware, Operating System, and

Applications.

Figure 5.1 shows the components with some of the operational systems available by the

date of creation of this document, however the framework implementation is not limited by

these O.S.. The same occurs for the hardware used. Several technologies of communications

can be applied on the modules, such as 3G, 4G, WIFI, and Bluetooth. We consider that

new technologies can be incorporated easily into the framework.

The interaction among the devices is shown in the Figure 5.1. The communication can

be performed by several network protocols. In the implementation of the first version of

IDEAL-TRAFFIC it was used Webservices, http connection and sockets to establish the

communication, and the data are sent through XML files.

The next explained in details, each layer and others concepts of each component.

45

46 CHAPTER 5. BUILDING APPLICATIONS OVER IDEAL-TRAFFIC

Figure 5.1: IDEAL-TRAFFIC Software Architecture.

5.2 SM Hardware and Software

The Service Mediator is able to receive requests from other components and processing it in

a timely manner. This component can be protected by security softwares such as firewall,

and can be built in clusters, using several available software in the literature. Scalability, is

an important requirement of this component. Moreover, this component tends to have a lot

of simultaneous accesses of end-users or other components. There are several technologies

available for performing this construction, for example softwares as Eucalyptus, Hadoop,

and frameworks of Java API. Usually this component is assembled on robust servers.

Table 5.1 shows each layer and their description.

Table 5.1: Layers of the SM Component

Layer Description

Hardware must be composed by microprocessor, RAM, HD and interfaces of

wired network or wireless network.

Operating System must have systems allowed to perform server tasks, and to provide

several services for other components.

Application must have a container with permission to launch web applications,

server, database, and information sharing. The broker application

works in this layer.

The development of this component consists in a web service that receives requests from

5.3. SP HARDWARE AND SOFTWARE 47

Service Users and treats it according to the kind of requirement. This component does not

demand user interface, since the processing of the requests are done in background.

The communication of this component with the other components is performed using

an XML file. Figure 5.2 shows the structure of the XML file that an SM sends to SPs. The

details of the structure of the XML file are found in the Appendix A. There are several

kinds of communications between SM and SU, and several different applications, so that

the XML file of any communication can be personalized according to each case.

1 <?xml version=‘‘1.0” encoding=”UTF−8”?>2 <root Name=”C2”>34 <DataModel Name=”R1” ClassName=‘‘ class”> </DataModel>5 <ServiceComposition id=‘‘ id” Name=‘‘Name SC”>6 <Source Name=‘‘nameSource” ClassName=‘‘ class”>7 <DataModel From=‘‘ localhost” Name=‘‘R1”> </DataModel>8 </Source>9

10 <Analyzer NotifierStrategy= ”1” Name=‘‘A1” ClassName=‘‘ class”>11 <NotifierStrategy Notifier=‘‘1” Name=‘‘

DefaultNotifierStrategy” ClassName=‘‘ class”>12 <Notifier address=‘‘ ip” ClassName=‘‘ class”></

Notifier>13 </NotifierStrategy>14 <DataModel From=‘‘ localhost” Name=‘‘R1”> </DataModel>15 </Analyzer>1617 </ServiceComposition>1819 </root>

Figure 5.2: XML File Structure

5.3 SP Hardware and Software

Service Provider can be built in several computational platforms being that embedded

(tablets, smartphones or third-party hardware) or traditional platforms (PCs, Notebooks,

or specific devices assembled to perform this role). This component can demand the use of

Real Time Operating Systems (RTOS) since they work as sensors. Another relevant factor

is the use of resources that reduces the consumptions of energy, in particular for the case

in which sensors are devices with battery restrictions. The Android OS has mechanisms

that provide this benefit.

Table 5.2 shows the layers of the SP component. The SP component was implemented

in Android due to the existence of resources that enable the operating system to reduce


Table 5.2: Layers of the SP Component

Layer Description

Hardware Must contains processor, RAM, data interface communication

wired or wireless. On this layer can be have integrated sensors in

which will provide the data to analysis using specifics algorithms.

Operating System Must be composed by systems allowed to act in mobile devices,

embedded or systems of PC platform.

Application Must contains an SP application able to process data received

from sensors or data received from other SP components. An

interface to communicate with other components of the

architecture is necessary. WEB interfaces are need to provide

data to other components or receive data from other SP components.

power consumption and other factors already explained in Chapter 3. Figure 5.3 shows the

classes that are defined in the Android application as service. These classes are designed

to launch in background software, since no user interface is needed.

Some Design Patterns are employed in the SP component to allow reuse of software.

One of the requirements of the system is that developers must have mechanisms to im-

plement their own applications and embed them in the components. In the Figure 5.3

there are several interfaces that act as hotspots of the application. The AbstractSource

and AbstractAnalyzer are examples of hotspot classes that allow developers to implement

their solutions. The AbstractSource corresponds to an interface to implement algorithms

to extract data from sensors attached to the SP. It also can be used to implement the

class that receives data from other SPs. The AbstractAnalyzer provides an interface to

implement the algorithms based on the user application rules.

5.4 SU Hardware and Software

Service User is a software with a human software interface that can be built on several

computational platforms such as embedded devices, WEB platforms, and others. For in-

stance, the hardware to access this component may be tablets, PCs, TVs, Notebooks,

Smartphones, or any other device that contains a screen for user manipulation and inter-

face for data communication. For the transportation scenario, some special requirements

are described for this platform. For instance, considering that the users of the system are

usually drivers, the software interface need to have resources to facilitate the their interac-

tions. Speech recognition, synthetic voice and audible alerts are examples of resources for

drivers interaction.

Table 5.3 shows the SU layers.


Table 5.3: Layers of the SU Component

Layer Description

Hardware must contain a processor, RAM, data communication interface, wired

or wireless. Devices that facilitate user interaction with the SU software

can be coupled in this layer, such as microphones and cameras.

Operating System this component must contain systems prepared to act in embedded,

devices or PC platform.

Application must contain an SU application to communicate with other

components of the architecture to build, request, make maintenance, and

configure released systems.


This chapter has presented the hardware and software conception of IDEAL-TRAFFIC.

We have discussed each component: Service Mediator (SM), Service User (SU) and Service

Provider (SP). In particular we have shown details of SP, which was designed upon the

Android platform in order to be able to make the experiments presented in this thesis. The

chapter has shown evidences that IDEAL-TRAFFIC is in accordance with the heterogene-

ity requirement described in Chapter 4. Next we present two use cases of IDEAL-TRAFFIC

in order to demonstrate how the framework can be applied to ITS scenarios.


Figure 5.3: IDEAL-TRAFFIC SP Diagram Classes.

Chapter 6

Use Cases

This chapter describes two use cases that demonstrate the use of IDEAL-TRAFFIC. For

the first use case IDEAL-TRAFFIC is demonstrated with static nodes using three devices.

The second case demonstrates the use of IDEAL-TRAFFIC integrated with a vehicular

network (VANETS). The objective of the use cases is to show how the IDEAL-TRAFFIC

can be used in ITS applications. The first one use case shows the use of SPs in static

nodes. The second one shows the integration of IDEAL-TRAFFIC with mobile nodes.

6.1 Use Case with Radars

This section introduces a use case application which received implementations under the

IDEAL-TRAFFIC framework. The objective is to demonstrate an example of a real case

of creation of the SC in the IDEAL-TRAFFIC. We use as a scenario the monitoring of

vehicles speed on the road.

Usually, the images are collected, sent to the data center, and processed using digital

image processing techniques. The fast growth of demand in ITS solutions increases the

costs of network infrastructure, especially when the main data to be transferred is video

and audio streams. This fact may increase network traffic that can become the bottleneck

of the system. The IDEAL-TRAFFIC is able to immensely contribute to the solution of

this problem. The video stream can be processed locally and the result transferred as meta

data. We take into consideration the fact that the stream video may be transferred on

demand.

The next step is to describe the use case problem, followed by providing a solution

using the IDEAL-TRAFFIC framework.

Figure 6.1 illustrates the problem. The road layout was divided into five parts (P1, P2,

P3, P4, and P5). The vertical lines between the parts delimit the areas. Three areas have

radars: P1, P3 and P5 having respectively radars R1, R2 and R3. The average speed in

51

52 CHAPTER 6. USE CASES

this scenario is 80 Km/h. The radars cannot measure or ensure the average speed imposed

by the traffic administrator. This is due to the fact that this device is able to measure only

an exact speed at that point. The driver’s behavior is usually similar to what is shown in

Figure 6.1. The radar points have the defined speed S (80Km/h in this example), and in

the areas without radar, the speed S increases.

We are encouraged to solve this problem because the frontier lines among the points

have high collision risk. In these areas, drivers tend to dramatically reduce the speed, after

noticing radar signs on the road. An inattentive driver coming up from behind may have

difficulty in avoiding collision.

Figure 6.1: Traffic speed radar problem scenario.

Figure 6.2 illustrates how the Traffic Radars Monitoring problem can be solved. The

road was divided in to three points: P1, P2 and P3. The three points are built on embedded

architecture and each point is an SP. It is assumed that the distance between P1 and P2,

and the distance between P2 and P3, are known. It is possible to define the average speed

between these points using the average speed formula.

Figure 6.2: Using average time and calculated the speed.

Each radar point has been changed by collectors that identify vehicles, where P1 and

P2 were chosen to use cameras and P3 was chosen to use a RFID antenna. These collector

instances were used to show how IDEAL-TRAFFIC can work with any combination of

sensors, which is one of the benefits of our proposal. The first function of P1 and P2 is

6.1. USE CASE WITH RADARS 53

to obtain the tag number of a vehicle on road. P3 extracts a RFID tag identifier of the

vehicle (assuming that RFID tag identifier is a license plate, or the id enables to retrieve

the car license plate). In a real scenario, the P3 collector may be a legacy system which

had been linked with the IDEAL-TRAFFIC instance, thus evidencing another benefit of

IDEAL-TRAFFIC. It is assumed that when a vehicle exceeds the average speed, the SC

registers an event. This event is sent to a WebService provided by the traffic administrator

through the Notifier module.

In order to successfully provide interaction among these three systems, it is important

to make use of the date time synchronization. Messages may occur between SPs and SM.

The role of SP P1 is to extract the tag number from the image collected by the camera

device, along with the current time. Both information would be packed and sent to SP P2,

where they are combined with the same information obtained from the P2 camera. The

algorithm combines both information, from P1 and P2, using the average speed formula. If

the average speed analyzed by P2 is greater than 80km/h, then P2 generates an event. The

speed limit can be set by systems administrators or traffic administrator. Note that this is

the SC application rule. If by chance, P1 loses connection with P2, P1 would then adapt

the topology connection with P3. If this fact happens, the properties used in the average

formula will change, according to the distance between P1 and P3. The distance between

P1 and P2 might be defined by the system administrator, or it is possible to collect this

information from other sources, for instance from Google Maps1.

The P1 module contains an algorithm that obtains the car tag information from images.

The obtained tag numbers are validated according to the local country pattern. After

validation, the tag information is paired with the current time, and both information

are sent to SP P2. Figure 6.3 shows the class diagram that represents the algorithms

instantiated by P1.

The same components instantiated on SP P1 have been instantiated in SP P2 in order

to obtain the tag number from vehicles. For SP P2, other components were deployed to

perform average speed analysis. This component implements the average speed formula

and verifies if the result is higher than 80km/h. P2 has two strategies. The first strategy

assumes that when the data is a tag number, it was taken from a sensor, and as a result, it

sends to P3. The second strategy is used when the data corresponds to an average speed

greater then the stipulated speed, hence instantiating a private data center connection.

Figure 6.4 shows the class diagram for P2 instance.

There are only two differences between SPs P2 and P3. First, in P3 the camera was

replaced by a RFID receiver as sensor. The second difference is that P3 does not need to

send the obtained tag numbers to another SP. Figure 6.5 shows the class diagram for P3.

Appendix B showns the XML configurations to build each component of this applica-

1Google Maps. https://maps.google.com.br/. Accessed on July 2012


tion. The experiments presented in the Chapter 7 simulates this application.

6.2 IDEAL-TRAFFIC Integration with V2V

This section shows a second use case on ITS whose problem can be effectively solved using

the IDEAL-TRAFFIC framework. The scenario involves the V2V and V2I communica-

tions. Modules SM, SU and SP are used according with their specifications to generate

services and provide communication. The user requests a service using SU to establish con-

nection with an SM. The SM receives the data, establishes connection with a set of SPs,

and requests them to adapt to start working for the new application. Below we present

the scenario, the features, the problem, and the applied solution.

This is an alternative application to try finding stolen cars quickly in a city. The goal

is to identify the location of the stolen car as soon as possible after the record of the

occurrence, using V2V and V2I communications.

The following situations must be considered:

� The system administrator uses the IDEAL-TRAFFIC SU to release a service that

allows users to record the theft.

� The user uses an IDEAL-TRAFFIC SU to get access to the released service. The

service requires the GPS position or the address of the event, and the licence plate

of the vehicle.

� The vehicles on the city have the OBU device with a digital image processing module,

camera and GPS.

� The thief has some expertise in technology so that he/she could shut down systems

of identifying and monitoring the vehicle, like GPS.

� A preliminary study of the theft was carried out allowing setting the parameters of

the application.

The user requests the list of services and chooses the application theft. He or she fills

the required data and submits to the SM. The SM receives the event location and the

stolen vehicle license plate, then notifies all RSU within a K distance of the event in order

to compose a new application. The RSUs disseminate the data for all OBUs in its range.

Each OBU disseminates the received messages for other neighbor OBUs. The message

created has at minimum an id of the SC application and the license plate of the stolen car.

Other important information can be inserted in the message at the system administrator’s

convenience. The goal of the SC is to use the OBUs module to collect the license plate of


vehicles within the distance K, analyze it, and compare it with the license plate sent by

the end user.

In case a OBU finds the stolen car, its target is to delivery the information as soon as

possible for a RSU. In this case, if the OBU is within the range of some RSU, then the

data is sent to it. Otherwise, the OBU disseminates the information for its neighbors in

order to delivery the data to a RSU.

Figure 6.6 is illustrates this scenario. All information is enlightening. The shaded area

corresponds to a neighborhood where the stolen vehicle can still be located, and the center

of the Figure 6.6 is the point of theft. Note that the RSUs are not covering all the streets of

the region, then the idea is that each vehicle with OBU receives the message and transmit

it to other OBUs until it comes to reach an RSU. In case of an OBU finds the license plate

of the stolen car, the information is packaged with its GPS position and then the process

of delivering to the RSU starts. Note that the combination of events generated for each

OBU, combined with the current date and time, can define the path of the stolen car. This

approach is configurable by the system administrator.

In the literature we found several algorithms to route messages in VANETS. Applying

this approach is not the focus of this work, so that we have not specified any VANET

protocol, although we consider it as future work.

This scenario was not experimented in a real environment by several reasons. First,

although the static nodes could be connected using a wireless access point or a wireless

router, the same approach cannot be used in the vehicles. The WIFI direct technology is

needed to implement the communication among vehicles. Another important fact is the

protocol to be used by vehicles. There are several protocols proposed in the literature,

but we have not found any protocol that would be able to run this application, then

some adaptations are need and are not the focus of this work. The final reason is that

the VANETs is an emergent area which has many results in simulations. The patterns

and protocols have been validated by IEEE and the devices built with these patterns are

not available on market. We have not found any work that shows experiments running a

vehicular protocol on a real case. This is a suggestion for our future work.


Two use cases have been presented in this chapter in order to show how the IDEAL-

TRAFFIC can be used to building ITS applications. The first use case presented a radars

scenario. The objective was to calculate the average speed of vehicles between two points.

The use case shows the interaction among components. The second use case presented

the integration of IDEAL-TRAFFIC with VANETs. For the IDEAL-TRAFFIC does not

matter the VANET protocol applied to perform the application, since it can be integrated


with legacy systems. Next we present the experiments on the IDEAL-TRAFFIC.


Figure 6.3: P1 instantiation using IDEAL-TRAFFIC


Figure 6.6: Region sample.

Chapter 7

Experiments and Results

This chapter shows three scenarios used to run the experiments. The general objective of

these executions was to show the effectiveness of the IDEAL-TRAFFIC. The experiments

described on corresponds the reproduction of the use case traffic radars scenario shown

on the Chapter 6. The objective of the first experiment described in the Section 7.2 is

to demonstrate that the use of SP to perform rules applications is a feasible alternative.

The objective of the second experiment described on Section7.3, is to demonstrate the

integration of the IDEAL-TRAFFIC with legacy systems. Finally, the objective of the

third experiment described on Section7.4, is to show how the system may be scaled. The

XML files used on all experiments are found in the Appendix B.

7.1 Overview

This section describes relevant information for the three scenarios experimented. Moreover,

a set of limitations for the three scenarios are exposed on this section.

For each scenario a sequence diagram is shown. Four functions are used in these dia-

grams. Table 7.1 shows the functions, their types and descriptions. The type values are:

Call, used when a local method of the device is called, and Send, which means that a

message was sent from a device to another.

Table 7.1: Modules Definition on the XML Files

Message Type Description

dataCollected() Call Called when a data is collected by component

sendCollectedData() Send Called when a component will send message for other

analizeData() Call Function that call the declared Analyzer for apply rules

application over the data

sendDataAnalyzed() Send Called in case of the result of analyzer to demand notification

61

62 CHAPTER 7. EXPERIMENTS AND RESULTS

Table 7.2 shows the classes used to launch the experiments. A brief description of each

one is presented, as well as the their acronyms. Since the IDEAL-TRAFFIC is based on

the SOA architecture, the standard of communication among devices is performed by XML

files.

Table 7.2: Classes Definition on the XML Files

Class Inheritance Acronym Description

PlateNumberReader AbstractSource PNR Module that simulates the data collected

WebServerSource AbstractSource WSS Module that are listening the data from

a child SP or a legacy system

PlateNumberStrategy AbstractAnalyzer PNS Module that validates a license plate. In

true case, forward the data for the

declared Notifier

AVGStrategy AbstractAnalyzer AVG Module that applies the average formula.

This module notifies a declared legacy

system in case of event

Before presenting the experiments, some limitations of the radars application scenario

are exposed. These limitations are applied to the three scenarios.

� The application was launched without an algorithm that retrieves the plate number

from a video stream or a RFID sensor, since developing this source code is not the

focus of this work;

� In the experiments a WIFI router was used as a hotspot to connect the SPs. In real

scenario we expect to use peer-to-peer connections, for instance Wi-Fi Direct;

� The experiments were performed only with SP components. Given the objectives de-

scribed and the current stage of the framework we do not need any other component.

Each scenario was launched with 5, 10, 50, 100, and 1,000 different messages generated

by the SPs and by legacy systems. The difference of time among the generation of each

license plate was set to the of is at minimum 1 second. We consider that this time is enough

to validate the experiment, since the security time between vehicles defined in Brazilian

traffic law is 2 second.

7.2 Experiment 1: Simple Radars Use Case Applica-

tion

The objective of this experiment is to analyze the swap of messages among the devices and

the behavior of the framework in the cooperative tasks performed by each SP. Table 7.3

7.2. EXPERIMENT 1: SIMPLE RADARS USE CASE APPLICATION 63

Figure 7.1: Scenario 1 Designed on the Experiments

shows the devices used and their respective connections, and the Operating System. Fig-

ure 7.1 shows the first scenario experimented.

The devices used to launch the experiments were the same described on Chapter 3.

Table 7.3 shows the devices used and their respective connections. Figure 7.1 shows the

first scenario experimented.

Table 7.3: Devices Configuration for Experiment 1

Component Device Connection OS IP

P1 Xperia X10 Wi-Fi 802.11 Android 2.2 192.168.1.2

P2 TI AM3517 Ethernet 100Mbps Android 2.1 192.168.1.110

P3 Motorola Xoom Wi-Fi 802.11 Android 3.2 192.168.1.9

Web Server Core i3, 4GB Ethernet 100Mbps Windows 7 192.168.1.3

A Web Server was implemented using the Java language. It uses a Servlet to receive

requests and store the data. This Web Server performs the role of a legacy system or a sub-

system. In ITS scenario we can compare it with a server of traffic management company.

Each time that nodes P2 and P3 receive the license plate code from their children, they

collect the same data from its correspondent module source, analyze the data using the

AVGStrategy module and send notification to the Web Server. Table 7.4 summarizes the

XML file configuration of P1, P2.

Following this idea, P1 collect its data and send it to P2. P2 collects the same data

(the same car that passed through P1 and through P2), analyzes it and sends it to the


Table 7.4: Summary of XML Configuration for Experiment 1

Component Sources From source, Analyzers Send to

module to data model module notifier

P1 PlateNumberReader localhost, R1 PlateNumberStrategy P2


localhost, R3

WebServerSource P1, R3 AVGStrategy WS

P3 PlateNumberReader localhost, R3 AVGStrategy WS

WebServerSource P2, R3

Figure 7.2: Sequence Diagram For Experiment 1

Web Server.

Figure 7.2 shows the sequence diagram of the described process. Table 7.1 describes

the functions of each event on the sequence diagram.

The result of experiments 1 is the following: the Web Server received all data generated

for every 5 execution. This means that P1 sent all its data to P2, since P2 established

communication with the Web server after receiving data from P1. The same behavior is

observed for the relationship between P2 and P3.

7.3. EXPERIMENT 2: RADARS USE CASE APPLICATION WITH A LEGACY SYSTEM ASINPUT 65

Figure 7.3: Scenario 2 designed on the experiments

7.3 Experiment 2: Radars Use Case Application with

a Legacy System as Input

In this scenario, instead P2 generates its license plate code, a Web Service was created.

This Web Service generates data and sends it to P2. So, this Web Service replaced the

PlateNumberReader module in P2 SP. The objective of this experiment is to show the

integration of IDEAL-TRAFFIC with legacy systems linked as input and output sources.

The same configurations shown on the Table 7.3 were used to this experiment, added by

the legacy system that was developed on the same computer of the Web Server. Figure 7.3

shows the experimented scenario. Figure 7.4 shows the sequence diagram for this scenario.

Table 7.5 shows the summary of XML files for this experiment.

The same source module that receives data from a child node is used to receive the

data from the legacy system, in this case WebServerSource.

In this scenario it was observed that all data generate by legacy systems were delivered

to P2, since that P2 sends its data to the Web Server. We remind that this occurs only

after P2 analyzes its data according with the data received from P1. The same behavior

was observed for SPs P2 and P3.

With this scenario we observed that, if a legacy system has interface to implement a

connection with the IDEAL-TRAFFIC, the two systems can be integrated.



Component Sources From source, Analyzers Send to

module to data model module notifier


P2 WebServerSource P1, R2 PlateNumberStrategy P3

Legacy System 1, R3

Legacy System 1, R3 AVGStrategy WS

P3 PlateNumberReader localhost, R1 AVGStrategy WS

localhost, R3

WebServerSource P2, R2

Figure 7.4: Sequence diagram for experiment 2

7.4 Experiment 3: The IDEAL-TRAFFIC Running

with 5 Nodes with Legacy Systems as Input and

Output

In this scenario we elevate the number of nodes of the application. The objective is to

show the overall scalability of the system increasing the number of SPs. Two other SPs

were added, as well as two other instances of legacy systems. Table 7.6 shows how the

components are configurated. Figure 7.5 shows the new configuration of this scenario.

The changes made on this scenario after adding the two new SPs were: to redirect the

data collected from P3 to P4, which in turn sends its data to P5. P4 combines its data

with the data from P3 and P5 combines its data with the data from P4. SPs P2, P3, P4,

7.4. EXPERIMENT 3: THE IDEAL-TRAFFIC RUNNING WITH 5 NODES WITH LEGACYSYSTEMS AS INPUT AND OUTPUT 67

Table 7.6: Devices Configuration for Experiment 3

Component Device Connection OS

P1 Xperia X10 Wi-Fi 802.11 Android 2.2 192.168.1.2





Web Server Core i3 4GB Ethernet 100Mbps Windows 7 192.168.1.3

Legacy System 1 Core i3 4GB Ethernet 100Mbps Windows 7 192.168.1.3

Legacy System 2 Core i3 4GB Ethernet 100Mbps Windows 7 192.168.1.3

Figure 7.5: Scenario 3 Used on the Experiments

and P5 send the analyzed data to the Web Service, in case of an event to be identified.

Nodes P3 and P4 receive the data from two different legacy systems. Figure 7.6 shows the

sequence diagram for this scenario. Table 7.7 shows the summary of the XML files for P1,

P2, P3, P4, and P5.

Note that P1 has the same XML file as other experiments. P2 and P3 does not have

the PlateNumberReader source module, since they receive the data from legacy systems.

The P4 XML file has the same structure of P2 XML file configured on the experiment 1.

The P5 component does not send messages to any parent, but sends its analyzed data

to the Web Service. Its XML configurations are similar with the P3 XML for experiment

1.



Component Sources From Source, Analyzers Send to

Module To Data Model Module Notifier



Legacy System 1, R1

Legacy System 1, R3 AVGStrategy WS

P3 WebServerSource Legacy System 2, R1 PlateNumberStrategy P4

Legacy System 2, R3

P2, R2 AVGStrategy WS


PlateNumberReader localhost, R1

localhost, R3 AVGStrategy WS


PlateNumberReader localhost, R3 AVGStrategy WS

The behavior of the components in this scenario was similar to the behavior observed

on the other experiments. All the devices sent their analyzed data to the Web Service. We

reming that the SPs send the data to the Web Service after receiving the data from its SP

child.

A explicit advantage in our architecture is the facility to scale the system quickly, since

the only need is to create the XML files and publish them into each new component of an

application. This approach is faster than building a new software version with the class

defined in the source code. For the launched experiments these configurations files were

created by a developer, but in the future these files will be created by the components SU

and SM of IDEAL-TRAFFIC.

7.5 Conclusion Remarks

This chapter has presented three experiments upon IDEAL-TRAFFIC. The objective of

the experiments was to show that the framework is in accordance with the main ITS

requirements described in Chapter 4. In the three experiments performed we have shown

that the framework does not need a centralized element to perform an application. Results

showed that all data have been delivered to their destination. The integration of the

framework with legacy systems has occurred with success.

7.5. CONCLUSION REMARKS 69

Figure 7.6: Sequence Diagram For Experiment 3

Chapter 8

Conclusions and Future Work

In this chapter the conclusions and future work are shown for IDEAL-TRAFFIC.

8.1 Conclusions

Intelligent Transportation Systems (ITS) become more complex in last years due to grow-

ing of the number of vehicles in the cities. It is an emerging field with important research

challenges related to infrastructure and vehicle communications. In the literature we have

found several works whose architecture is centralized. Data collected by sensors distributed

in the cities or roads are sent in their raw format (stream video, stream audio) for data cen-

ters to be processed. This architecture imposes a robust network infrastructure, increasing

the cost to design and development of the solution. The ITS infrastructure has been the

focus of this work. Our objective have been to design and develop an infrastructure that

composes the main ITS requirements.

In this thesis we have presented a framework called IDEAL-TRAFFIC. The IDEAL-

TRAFFIC has distributed architecture and is in accordance with the main requirements for

ITS. The framework facilitates the creation and maintenance of applications, mainly due

to the remote access provided by the user interface through the Service User module. The

IDEAL-TRAFFIC is composed by nodes built in embedded platform to perform partial

tasks. Each one shares its results with others in order to combine them. This approach

classifies the IDEAL-TRAFFIC as a cooperative system. The IDEAL-TRAFFIC respects

the main ITS requirements and can be applied to diverse monitoring applications.

Other distributed solutions have been found in the literature but does not satisfies the

main ITS requirements of ITS.

The proposed solution was based on the SOA architecture which, in its original format,

connects users to available the services distributed on the web. In our solution the services

are launched in embedded devices linked to sensors then able to extract information from

71

72 CHAPTER 8. CONCLUSIONS AND FUTURE WORK

the traffic. These devices are called Service Providers (SP). System administrators can

update SP with algorithms that apply traffic applications rules. With this resource, the

SP can provide more specifics data in comparison to the raw data from sensors. Part of

the applications that would run on robust data centers are deployed in SPs.

Two use cases have been shown as a proof of concept to IDEAL-TRAFFIC in Chapter 6.

The first one is called Traffic Radars and shows the use of static nodes in an ITS scenario.

The second one shows the integration of framework with VANET.

Moreover, three experiments have been launched to evaluate the accordance of IDEAL-

TRAFFIC with some ITS requirements. The objectives of the first scenario is to analyze

the swap of messages among devices and to analyze the behavior of the framework on

collaborative tasks performed by each SP. The simulated data by SPs were combined

with other SPs data in order to extract the average speed of a vehicle. Although in the

experiments we did not use a real sensor to collect the license plate code of a vehicle. We

have shown that the use of a web service on the Android Platform is a feasible alternative

for communication among devices.

In order to show that the IDEAL-TRAFFIC is able to communicate with legacy sys-

tems, a second experiment has been launched. We have created a web server that generated

the data and sent them to an SP. We have been encouraged to add this web server to show

that IDEAL-TRAFFIC is able to receive input data from other systems. After each SP

processes the data received, a notification is sent to another external service. The lat-

ter simulates a scenario where the IDEAL-TRAFFIC provides data for a legacy system

(output). In all executions it has been observed that the data arrived on the destination.

This fact validates the use of the framework interacting with legacy systems, proving its

interoperability.

In the third experiment the number of SPs was increased in order to show the scale

of the system. To make this change, the system administrator configures the XML files

to modify the SP status. Instantiating classes in real time is a feasible characteristic of

the framework that facilitates the modifications on the state of an SP. This characteristic

shows that adding SPs in applications is easily performed through the configuration of

XML files.

The most of main ITS requirements are covered by our solution. The the integration

with legacy systems has occurred, ensuring the interoperability of the system. The scala-

bility of the system have shown through the increasing of new nodes that have configured

on XML files. The system administrator can change the applications easily through an

user software interface. This fact shows the flexibility of the solution. The accessibility

is provided by end user interface on the Services User component to access applications

configured by systems administrators. The project is openness to new programs due to

the software interface described in the Chapter 5. Also in the Chapter 5 is presented the

hardware and software requirements of IDEAL-TRAFFIC showing the heterogeneity of the

8.2. FUTURE WORK 73

solution. An adaptation process is presented in order to cover the adaptability requirement.

We have demonstrated that the ITS does not need to be built on centralized architec-

ture.

8.2 Future Work

Next the future work for this project are described. Each item was identified during the

development of project.

To modify the process of adaptation for SP mobiles. The current process might not

work well if used on mobile nodes. The SM will be called every time that a vehicle lose

connection with it pair. An evaluation of the VANETs protocols in the literature need be

done in order to validate their accordance with IDEAL-TRAFFIC.

To develop the component SM in a scalable architecture. This component may be a

drawback of the project due to the number of simultaneous of access that will receive when

applied in big cities. Eucalyptus, Hadoop, Java Web APIs are suggests to be evaluated to

provide this scale.

To apply the framework for others monitoring areas, such as the environment catastro-

phes, smart cities and others. We have strong evidences that the framework is not limited

on the ITS applications. It use in other areas such as ‘smart citiesA´, industry, home

automation among others need to be explored.

To implement security mechanisms on the framework. This is a requirement no raised

on this thesis, but we understand that is an important area to be explored. Integrity,

authenticity and privacy are the requirements to avoid the vulnerability of the system.

To evaluate the latency of the adaptation and readaptation processes. Call these pro-

cesses to be launched means that an application are unavailable. Hence, this process need

to run at shortest possible time.

To do the experiments with the WI-FI Direct technology. This is a recent technology

that our project demands. Experiments with it benefits the integration with VANETs as

well, become possible to implement the second use case proposed on the Chapter 6 in a

real scenario.

To implement resources to monitoring the hardware consumption of the SP. For in-

stance, using the SNMP protocol. This feature can give support for system administrators

crete their applications.

74 CHAPTER 8. CONCLUSIONS AND FUTURE WORK

Bibliography

[1] Chulbum Ahn and Yunmook Nah. Design of location-based web service framework

for context-aware applications in ubiquitous environments. In IEEE International

Conference Sensor Networks, Ubiquitous, and Trustworthy Computing (SUTC), pages

426–433, June 2010.

[2] Kashif Ali, Dina Al-Yaseen, Ali Ejaz, Tayyab Javed, and Hossam S. Hassanein.

Crowdits: Crowdsourcing in intelligent transportation systems. In Wireless Commu-

nications and Networking Conference (WCNC), 2012 IEEE, pages 3307–3311, April

2012.

[3] Clemens Arth, Florian Limberger, and Horst Bischof. Real-time license plate recogni-

tion on an embedded dsp-platform. Computer Vision and Pattern Recognition, IEEE

Computer Society Conference, pages 1–8, 2007.

[4] A. Bazzi and B.M. Masini. Taking advantage of v2v communications for traffic man-

agement. In Intelligent Vehicles Symposium, 2011 IEEE, pages 504–509, June 2011.

[5] Karla Albuquerque de V. Borges and Sundeep Sahay. GIS for the public sector:

Experiences from the city of belo horizonte, brazil. Information and Infrastructure

and Policy, Vol 6:139–155, August 2000.

[6] European Commission. The karen european its framework architecture, 2011.

[7] Saul Delabrida, Ricardo R.Oliveira, and Alvaro R. Pereira Jr. Ideal-traffic: A self-

adaptive management framework for building monitoring applications with support

to network topology changes. In Network Operations and Management Symposium -

NOMS 2012 - Application Sessions, pages 764–779, April 2012.

[8] Nour-Eddin El Faouzi, Henry Leung, and Ajeesh Kurian. Data fusion in intelligent

transportation systems: Progress and challenges - a survey. Information Fusion, Vol.

12:4–10, January 2011.

75

76 BIBLIOGRAPHY

[9] K. Fujimura, K. Toshihiro, and K. Shunsuke. Vehicle infrastructure integration system

using vision sensors to prevent accidents in traffic flow. Intelligent Transport Systems

(IET), 5(1):11–20, March 2011.

[10] Luis Felipe Herrera-Quintero, Francisco Macia-Perez, Diego Marcos-Jorquera, and

Virgilio Gilart-Iglesias. Wireless sensor networks and service-oriented architecture, as

suitable approaches to be applied into its. In 6th Euro American Conference Telem-

atics and Information Systems (EATIS), pages 1–8, May 2012.

[11] H. Kanoshima and H. Hatakenaka. Development of next-generation road services by

public and private joint research. In 8th International Conference on ITS Telecom-

munications, ITST, pages 404–407, Octuber 2008.

[12] Linjing Li, Xin Li, Zhenjiang Li, D.D. Zeng, and W.T. Scherer. A bibliographic

analysis of the ieee transactions on intelligent transportation systems literature. IEEE

Transactions on Intelligent Transportation Systems, 11(2):251–255, June 2010.

[13] Liang-Tay Lin, Hung-Jen Huang, Jim-Min Lin, and F.F. Young. A new intelligent traf-

fic control system for taiwan. In 9th International Conference on Intelligent Transport

Systems Telecommunications (ITST), pages 138–142, Octuber 2009.

[14] R. Meier, A. Harrington, and V. Cahill. A framework for integrating existing and

novel intelligent transportation systems. In IEEE Intelligent Transportation Systems,

pages 154–159, September 2005.

[15] U.S. Department of Transportation. The national its architecture, 2011.

[16] M. Padmadas, K. Nallaperumal, V. Mualidharan, and P. Ravikumar. A deployable

architecture of intelligent transportation system - 2014; a developing country perspec-

tive. In IEEE International Conference on Computational Intelligence and Computing

Research, ICCIC, pages 1–6, December 2010.

[17] T. Semertzidis, K. Dimitropoulos, A. Koutsia, and N. Grammalidis. Video sensor

network for real-time traffic monitoring and surveillance. Intelligent Transport Systems

(IET), 4(2):103–112, June 2010.

[18] A. Shimura, T. Sakaibara, M. Hiraiwa, and T. Aizono. Proposal of an autonomous

group-management model and its application to intelligent transport system. In Au-

tonomous Decentralized Systems (ISADS). The Sixth International Symposium on,

pages 71–79, April 2003.

[19] A. Staikopoulos, O. Cliffe, R. Popescu, J. Padget, and S. Clarke. Template-based

adaptation of semantic web services with model-driven engineering. IEEE Transac-

tions on Services Computing, 3(2):116–130, April-June 2010.

BIBLIOGRAPHY 77

[20] Lee Tsu-Tian. Research on intelligent transportation systems in taiwan. In 27th

Chinese Control Conference (CCC) 2008, pages 18–23, 2008.

78 BIBLIOGRAPHY

Appendix A

XML Example to Compose a Service

in a SP

This Appendix shows an example of XML configuration used in the SPs to create local

instance of service composition. Each SP receives a copy of a XML file structured like this

from the SM, reads it and instantiates the classes defined. The tags and its attributes are

explained below.

1 <?xml version=”1.0” encoding=”UTF−8”?>2 <root Name=”C2”>34 <DataModel Name=”R1” ClassName=”class”> </DataModel>5 <ServiceComposition id=”id” Name=”Name SC”>6 <Source Name=”nameSource” ClassName=”class”>7 <DataModel From=”localhost” Name=”R1”> </DataModel>8 </Source>9

10 <Analyzer NotifierStrategy= ”1” Name=”A1” ClassName=”class”>11 <NotifierStrategy Notifier=”1” Name=”

DefaultNotifierStrategy” ClassName=”class”>12 <Notifier address=”ip” ClassName=”class”></Notifier

>13 </NotifierStrategy>14 <DataModel From=”localhost” Name=”R1”> </DataModel>15 </Analyzer>1617 </ServiceComposition>1819 </root>

The root tag marks the begin of document. This tag has a unique attribute called

Name. This attribute corresponds the name identifier of SP.

The DataModel tag corresponds of a data model of the repository used to provide com-

munication among components of the same Service Composition. In this implementation,

79

80 APPENDIX A. XML EXAMPLE TO COMPOSE A SERVICE IN A SP

two or more Services Compositions could share its data with each other, since the An-

droid API implements the content provider, as described on Chapter 3. Due to this fact

the DataModel is defined outside of Service Composition. The attribute From means the

source where the data emerged. This feature is important since the a web server can receive

data from legacy systems simultaneously with a child node. When this parameter is set

with localhost value, means that the source is the same device. When another parameter

is used (usually the name of source component) the framework will interpret it put the

data on indicated Data Source indicated by parameter name . The and the Name is a

DataModel attribute which is a name identifier of repository. This attribute is used by

the components Source and Analyzer to put and retrieve data in a local Service Compo-

sition. The second attribute ClassName corresponds a class that implements repository

behavior. Currently there are two class that represents this repository’s behavior in the

IDEAL-TRAFFIC. FIFODataModel and HashDataModel.

The SeviceComposition tag delimits the configuration of a local Service Composition.

The attributes, id and Name, are defined in the SM and by user respectively. These

attributes are important in the case of a single SP to launch two or more Service Com-

positions. In particular, when a child node sends the data to its parents, and its father is

running more than one service composition.

The Source is the component responsible by receive the data and put it in the DataModel

repository. The Source component corresponds a system class which encapsulates the

algorithm with source code to extract sensor data. By definition, in the IDEAL-TRAFFIC

has a class to receive data from a child called WebServerSource, then each SP that performs

the parent role, needs of a WEBServerSource instance launched. The attribute Name

identifies the Source name. The ClassName attribute corresponds of the class path to

perform the Source algorithm. A single ServiceComposition may have more than one

Source.

The DataModel tag corresponds of the repository that stores the data collected by

Source. Note that this component has the attribute Name, that is equivalent of the data

model declared before to declare the ServiceComposition. The same tag is used in the

Analyzer component explained below.

The Analyzer tag declares a component that retrieves the data from a repository and

applies some application rule over these data. The attribute Name corresponds of the

id of analyzer, while ClassName corresponds a class that perform the algorithm with

a application rule. The same occur for attributes of the next tags. The NotifierStrategy

attribute counts the number of child tags called NotifierStrategy that the analyzer contains.

The NotifierStrategy corresponds a class that implements some strategy to notify some

provider. The default implementation provides by the IDEAL-TRAFFIC is the Default-

NotifierStrategy class that sends the data for all declared Notifier. This class is important

in case of the developer to need define some strategy to notify the data. The Analyzer

81

may have more than one NotifierStrategy.

The Notifier corresponds to a class that knows the properties of components that will

receive the data. Usually, the Notifier implements the protocol to establish communica-

tion among the components. Currently, the IDEAL-TRAFFIC implements two notifiers,

one to communicate with a SP parent (ParentNotifier class) and other to communicate

with a WEBServer (WEBServerNotifier class). This implementation uses the http GET

communication method to send data. On the next releases of IDEAL-TRAFFIC others

protocols will be implemented, such http POST communication, bluetooth communication

and others. Note that, if some developer need perform communication with some legacy

system, the protocol of communication will be implemented under Notifier interface. In a

NotifierStrategy one or more Notifier may be declared.

82 APPENDIX A. XML EXAMPLE TO COMPOSE A SERVICE IN A SP

Appendix B

XML Configuration to Create the

Radars Application

Below is shown the XML file of the three components that perform the Radars application

of Chapter 6. The XML files were created according the model shown in Appendix A. The

XML files of P1, P2 and P3 are explained respectively.

B.1 P1 XML Configuration for Experiments 1, 2 and

3

1 <?xml version=”1.0” encoding=”UTF−8”?>2 <root Name=”P1”>34 <DataModel Name=”R1” ClassName=”com. sdelabrida .mestrado . analyzer .

datamodel .FIFODataModel”> </DataModel>5 <ServiceComposition id=”plate” Name=”Name Plate”>6 <Source Name=”S1” ClassName=”com. sdelabrida .mestrado . source . II .

PlateNumberReader”>7 <DataModel From= ”localhost” Name=”R1”> </DataModel>8 </Source>9

10 <Analyzer Notifiers= ”1” DataModel=”1” Name=”A1” ClassName=”com.sdelabrida .mestrado . analyzer . II .PlateNumberStrategy”>

11 <NotifierStrategy Notifier=”1” Name=”DefaultNotifierStrategy” ClassName=”com. sdelabrida .mestrado . not i f ier . strategy . DefaultNotifierStrategy”>

12 <Notifier address=”192.168.1.110” ClassName=”com.sdelabrida .mestrado . not i f ier . ParentNotifier”></Notifier>

13 </NotifierStrategy>14 <DataModel From= ”localhost” Name=”R1”> </DataModel>15 </Analyzer>

83

84 APPENDIX B. XML CONFIGURATION TO CREATE THE RADARS APPLICATION

16 </ServiceComposition>1718 </root>

The DataModel used is FIFODataModel with the FiFo approach to storage the data.

This Data Model is the single repository to share data between defined Source class and

Analyzer class. In the P1 instance, the ServiceComposition contains only one Source and

one Analyzer. The Source corresponds of the algorithm that simulates the license plate

reader, and the Analyzer validates the extracted data. Actually, in the IDEAL-TRAFFIC

there is not an algorithm to recognize the license plate from a video stream. To effect of

the proof of concept was used a class that generate license plate called PlateNumberReader.

This source puts the data in R1 DataModel.

The P1 Analyzer retrieves the data from R1 and sends it for DefaultNotifierStrategy.

The Analyzer class called PlateNumberStrategy validates a plate number and sends the

data for a ParentNotifier with the IP number ”192.168.1.110 ”.

B.2 P2 XML Configuration for the Experiments 1


datamodel .FIFODataModel”> </DataModel>5 <DataModel Name=”R2” ClassName=”com. sdelabrida .mestrado . analyzer .

datamodel .HashDataModel”> </DataModel>6 <DataModel Name=”R3” ClassName=”com. sdelabrida .mestrado . analyzer .

datamodel .FIFODataModel”> </DataModel>78 <ServiceComposition id=”plate” Name=”Name Plate”>9 <Source Name=”S1” ClassName=”com. sdelabrida .mestrado . source . II .

PlateNumberReader”>10 <DataModel From= ”localhost” Name=”R1”> </DataModel>11 <DataModel From= ”localhost” Name=”R3”> </DataModel>12 </Source>1314 <Analyzer Notifiers= ”1” DataModel=”1” Name=”A1” ClassName=”com.

sdelabrida .mestrado . analyzer . II .PlateNumberStrategy”>15 <NotifierStrategy Notifier=”1” Name=”

DefaultNotifierStrategy” ClassName=”com. sdelabrida .mestrado . not i f ier . strategy . DefaultNotifierStrategy”>


17 </NotifierStrategy>18 <DataModel From= ”localhost” Name=”R1”> </DataModel>19 </Analyzer>

B.3. P3 XML INSTANCE FOR THE EXPERIMENTS 1 85

2021 <Source Name=”S2” ClassName=”com. sdelabrida .mestrado . source . II .

WebServerSource”>22 <DataModel From= ”P1” Name=”R2”> </DataModel>23 </Source>2425 <Analyzer Notifiers= ”1” DataModel=”2” Name=”A2” ClassName=”com

. sdelabrida .mestrado . analyzer . II .AVGStrategy”>26 <NotifierStrategy Notifier=”1” Name=”


27 <Notifier address=”192.168.1.3” ClassName=”com.sdelabrida .mestrado . not i f ier .WEBServerNotifier”></Notifier>

28 </NotifierStrategy>29 <DataModel From= ”localhost” Name=”R3”> </DataModel>30 <DataModel From= ”P1” Name=”R2”> </DataModel>31 </Analyzer>3233 </ServiceComposition>34 </root>

On the P2 instance, three DataModel were declared, where R1 and R3 are FIFOData-

Model, and the R2 is a HashDataModel. Two pairs of Source and Analyzer were defined.

The first performs the same role described on the P1 node. The PlateNumberReader col-

lects the license plate with the current time, and put it in the R1 and R3 Data Models.

The PlateNumberStrategy analyzer class retrieves the information from R1, validates the

data, and sends it to defined SP parent with IP ”192.168.1.9”, shown in lines 14 to 19.

The second pair of Source and Analyzer of the P2 instance is built with the WebServer-

Source that receives the data from the P1 SP and puts it in a hash data model R2, lines 21

to 22. The AVGStrategy class calculates the average speed with the AVG formula. Each

data generated by PlateNumberReader is stored in R3. The AVGStrategy, according of

FiFo policy, uses the current retrieved data to query in the R2 the time of the car passed

in the P1 SP. In case of a hit, P2 combines the time of its own source extracted with the

received time P1. This Analyzer uses the DefaultNotifierStrategy and sends the data for

a Webservice whose the IP is ”192.168.1.3”. In our implementation, this web server only

write the received data in a text file.

B.3 P3 XML Instance for the Experiments 1

1 <?xml version=”1.0” encoding=”UTF−8”?>2 <root Name=”P3 1”>3


4 <DataModel Name=”R2” ClassName=”com. sdelabrida .mestrado . analyzer .datamodel .HashDataModel”> </DataModel>

5 <DataModel Name=”R3” ClassName=”com. sdelabrida .mestrado . analyzer .datamodel .FIFODataModel”> </DataModel>

67 <ServiceComposition id=”plate” Name=”Name Plate”>8 <Source Name=”S1” ClassName=”com. sdelabrida .mestrado . source . II .

PlateNumberReader”>9 <DataModel From=”localhost” Name=”R3”> </DataModel>

10 </Source>1112 <Source Name=”S2” ClassName=”com. sdelabrida .mestrado . source . II .

WebServerSource”>13 <DataModel From= ”P2” Name=”R2”> </DataModel>14 </Source>1516 <Analyser Notifiers= ”1” DataModel=”2” Name=”A2” ClassName=”com




19 </NotifierStrategy>20 <DataModel From=”localhost” Name=”R3”> </DataModel>21 <DataModel From=”P2” Name=”R2”> </DataModel>22 </Analyser>2324 </ServiceComposition>2526 </root>

The difference between P3 and P2 is that the P3 does not send the license plate for a

parent. P3 retrieves the data provided by P2 in the WebServerSource, puts it in the R2

repository and compares with data read from PlateNumberReader using the R3 repository.

The data analyzed by AVGStrategy are sent to the same web server used in P2.

B.4 P2 XML Configuration for the Experiments 2

and 3


datamodel .FIFODataModel”> </DataModel>

B.5. P3 XML INSTANCE FOR THE EXPERIMENT 2 87



78 <ServiceComposition id=”plate” Name=”Name Plate”>9

10 <Source Name=”S2” ClassName=”com. sdelabrida .mestrado . source . II .WebServerSource”>

11 <DataModel From= ”P1” Name=”R2”> </DataModel>12 <DataModel From= ”Legacy System 1” Name=”R1”> </DataModel>13 <DataModel From= ”Legacy System 1” Name=”R3”> </

DataModel>14 </Source>1516 <Analyzer Notifiers= ”1” DataModel=”1” Name=”A1” ClassName=”com.




19 </NotifierStrategy>20 <DataModel ”Legacy System 1” Name=”R1”> </DataModel>21 </Analyzer>2223 <Analyzer Notifiers= ”1” DataModel=”2” Name=”A2” ClassName=”com




26 </NotifierStrategy>27 <DataModel From=”Legacy System 1” Name=”R3”> </

DataModel>28 <DataModel From=”P1” Name=”R2”> </DataModel>29 </Analyzer>30 </ServiceComposition>31 </root>

B.5 P3 XML Instance for the Experiment 2

1 <?xml version=”1.0” encoding=”UTF−8”?>2 <root Name=”P3 2”>3






PlateNumberReader”>10 <DataModel From= ”localhost” Name=”R1”> </DataModel>11 <DataModel From= ”localhost” Name=”R3”> </DataModel>12 </Source>1314 <Source Name=”S2” ClassName=”com. sdelabrida .mestrado . source . II .

WebServerSource”>15 <DataModel From= ”P2” Name=”R2”> </DataModel>16 </Source>1718 <Analyzer Notifiers= ”1” DataModel=”2” Name=”A2” ClassName=”com




21 </NotifierStrategy>22 <DataModel From= ”localhost” Name=”R3”> </DataModel>23 <DataModel From= ”P2” Name=”R2”> </DataModel>24 </Analyzer>2526 </ServiceComposition>27 </root>

B.6 P3 XML Instance for the Experiment 3

1 <?xml version=”1.0” encoding=”UTF−8”?>2 <root Name=”P3 3”>34 <DataModel Name=”R1” ClassName=”com. sdelabrida .mestrado . analyzer .


datamodel .HashDataModel”> </DataModel>6 <DataModel Name=”R3” ClassName=”com. sdelabrida .mestrado . analyzer .

datamodel .FIFODataModel”> </DataModel>78 <ServiceComposition id=”plate” Name=”Name Plate”>


9 <Source Name=”S2” ClassName=”com. sdelabrida .mestrado . source . II .WebServerSource”>

10 <DataModel From=”P2” Name=”R2”> </DataModel>11 <DataModel From=”Legacy System 2” Name=”R1”> </DataModel>12 <DataModel From=”Legacy System 2” Name=”R3”> </

DataModel>13 </Source>1415 <Analyzer Notifiers= ”1” DataModel=”1” Name=”A1” ClassName=”com.





DataModel>20 </Analyzer>2122 <Analyzer Notifiers= ”1” DataModel=”2” Name=”A2” ClassName=”com





DataModel>27 <DataModel From=”P2” Name=”R2”> </DataModel>28 </Analyzer>2930 </ServiceComposition>31 </root>




datamodel .HashDataModel”> </DataModel>




PlateNumberReader”>10 <DataModel From=”localhost” Name=”R1”> </DataModel>11 <DataModel From=”localhost” Name=”R3”> </DataModel>12 </Source>1314 <Analyzer Notifiers= ”1” DataModel=”1” Name=”A1” ClassName=”com.




17 </NotifierStrategy>18 <DataModel From=”localhost” Name=”R1”> </DataModel>19 </Analyzer>2021 <Source Name=”S2” ClassName=”com. sdelabrida .mestrado . source . II .

WebServerSource”>22 <DataModel From=”P3” Name=”R2”> </DataModel>23 </Source>2425 <Analyzer Notifiers= ”1” DataModel=”2” Name=”A2” ClassName=”com




28 </NotifierStrategy>29 <DataModel From=”localhost” Name=”R3”> </DataModel>30 <DataModel From=”P3” Name=”R2”> </DataModel>31 </Analyzer>3233 </ServiceComposition>34 </root>


1 <?xml version=”1.0” encoding=”UTF−8”?>2 <root Name=”P5”>3





PlateNumberReader”>9 <DataModel From=”localhost” Name=”R3”> </DataModel>

10 </Source>1112 <Source Name=”S2” ClassName=”com. sdelabrida .mestrado . source . II .

WebServerSource”>13 <DataModel From=”P4” Name=”R2”> </DataModel>14 </Source>1516 <Analyser Notifiers= ”1” DataModel=”2” Name=”A2” ClassName=”com




19 </NotifierStrategy>20 <DataModel From=”localhost” Name=”R3”> </DataModel>21 <DataModel From=”P4” Name=”R2”> </DataModel>22 </Analyser>23 </ServiceComposition>2425 </root>

ideal-traffic: a framework for ... - repositorio.ufop.br‡Ão... · catalogação:...

Documents