IDEAL-TRAFFIC: A FRAMEWORK FOR BUILDING MONITORING SYSTEMS FOR INTELLIGENT TRANSPORTATION SYSTEMS

(1)

Saul Emanuel Delabrida Silva

Supervisor – ´

Alvaro Rodrigues Pereira J´

unior

Co-supervisor – Ricardo Augusto Rabelo Oliveira

IDEAL-TRAFFIC: A FRAMEWORK FOR

BUILDING MONITORING SYSTEMS FOR

INTELLIGENT TRANSPORTATION SYSTEMS

Ouro Preto

August 3

rd

(2)

(3)

Saul Emanuel Delabrida Silva

Orientador – ´

Alvaro Rodrigues Pereira J´

unior

Co-orientador – Ricardo Augusto Rabelo Oliveira

IDEAL-TRAFFIC: UM FRAMEWORK PARA

CONSTRUC

¸ ˜

AO DE SISTEMAS DE

MONITORAMENTO PARA SISTEMAS

INTELIGENTES DE TRANSPORTES

Disserta¸cão de mestrado apresentada ao Programa de Pós-Gradua¸cão em Ciência da Computa¸cão da Universidade Federal de Ouro Preto, como requisito parcial para a obten¸cão do grau de Mestre em Ciência da Computa¸cão.

(4)

Catalogação: sisbin@sisbin.ufop.br 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.

(5)

(6)

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

(7)

(8)

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

(9)

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

(10)

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 ParPar-ent and multiple Children. (c) A ParPar-ent 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

(11)

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

(12)

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

(13)

(14)

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.

(15)

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.

(16)

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.

(17)

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 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

1

(18)

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

1

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

2

(19)

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.

(20)

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.

(21)

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

(22)

(23)

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 TransportaSec-tion 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.

1

A. R. Pereira Jr. Edital MCT/CNPq no 018/2009 – Pesquisa, Desenvolvimento e Inova¸c˜ao em Trans-portes. January 2010.

2

CNPq. Conselho Nacional de Desenvolvimento Cient´ıfico e Tecnol´ogico. http://www.cnpq.br/. Ac-cessed on March 2012

(24)

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 S˜ao 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.

(25)

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.

(26)

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 net-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 applipubli-cations 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.

(27)

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.

3

Web Services Architecture. http://www.w3.org/TR/ws-arch/. Accessed March 2012 4

Service Oriented Architecture Standards. http://www.w3.org/2007/01/wos-papers/boeing. Accessed March 2012

5

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

6

Web Services Description Language (WSDL) 1.1. http://www.w3.org/TR/wsdl. Accessed March 2012 7

(28)

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-8

(29)

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. TheLinux 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

9

(30)

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 architecture10

, 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

10

(31)

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

(32)

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.

(33)

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 theGoogle’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

(34)

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.

(35)

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.

(36)

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.

1

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

(37)

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.

(38)

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.

(39)

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.

(40)

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,

3

The OMG’s CORBA Website. Corba http://www.corba.org/. Accessed on July 2012 4

(41)

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

(42)

(43)

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

(44)

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.

(45)

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.

(46)

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 ProtoProto-col), 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.

(47)

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.

(48)

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

(49)

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

(50)

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 theData 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

(51)

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 fromAnalyzers 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

(52)

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

(53)

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

(54)

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.