arquitetura baseada em redes de sensores sem fio e ... · as a service) pelo apache stratos, que...

Pós-Graduação em Ciência da Computação

ARQUITETURA BASEADA EM REDES DE SENSORES SEM FIO E COMPUTAÇÃO EM NUVEM PARA CIDADES INTELIGENTES

Por

Ronald Jared Romero Reyes

Dissertação de Mestrado

Universidade Federal de Pernambuco

[email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE

2015

Universidade Federal de Pernambuco

Centro de InformáticaPós-graduação em Ciência da Computação

Ronald Jared Romero Reyes

ARQUITETURA BASEADA EM REDES DE SENSORES SEM FIO ECOMPUTAÇÃO EM NUVEM PARA CIDADES INTELIGENTES

Trabalho apresentado ao Programa de Pós-graduação em

Ciência da Computação do Centro de Informática da Univer-

sidade Federal de Pernambuco como requisito parcial para

obtenção do grau de Mestre em Ciência da Computação.

Orientador: Kelvin Lopes Dias

RECIFE

2015

Catalogação na fonte

Bibliotecária Jane Souto Maior, CRB4-571

R457a Reyes, Ronald Jared Romero Arquitetura baseada em redes de sensores sem fio e

computação em nuvem para cidades inteligentes / Ronald Jared Romero Reyes. – Recife: O Autor, 2015.

87 f.: il., fig., tab. Orientador: Kelvin Lopes Dias. Dissertação (Mestrado) – Universidade Federal de

Pernambuco. CIn, Ciência da Computação, 2015. Inclui referências.

1. Sistemas distribuídos. 2. Computação em nuvem. 3. Redes de sensores sem fio. I. Dias, Kelvin Lopes (orientador). II. Título. 004.36 CDD (23. ed.) UFPE- MEI 2015-176

Dissertação de Mestrado apresentada por RONALD JARED ROMERO REYES à Pós-

Graduação em Ciência da Computação do Centro de Informática da Universidade Federal

de Pernambuco, sob o título “ARQUITETURA BASEADA EM REDES DE

SENSORES SEM FIO E COMPUTAÇÃO EM NUVEM PARA CIDADES

INTELIGENTES” orientada pelo Prof. KELVIN LOPES DIAS e aprovada pela Banca

Examinadora formada pelos professores:

______________________________________________

Prof. Paulo Roberto Freire Cunha

Centro de Informática/UFPE

______________________________________________

Prof. Obionor de Oliveira Nóbrega

Departamento de Estatística e Informática / UFRPE

_______________________________________________

Prof. Kelvin Lopes Dias

Centro de Informática / UFPE

Visto e permitida a impressão.

Recife, 31 de agosto de 2015.

___________________________________________________

Profa. Edna Natividade da Silva Barros Coordenadora da Pós-Graduação em Ciência da Computação do

Centro de Informática da Universidade Federal de Pernambuco.

Eu dedico esta dissertação à minha esposa, quem me deu

todo o apoio possível para levar a bom término meus

estudos.

Agradecimentos

À Fundação de Amparo à Ciência e Tecnologia de Pernambuco (FACEPE), patrocinou

minha bolsa de estudo, apoiando minha estada no Brasil possibilitando a realização do Mes-

trado, de forma a incrementar meu conhecimento e experiências acadêmicas, e permitindo o

desenvolvimento do presente projeto de dissertação.

Ao Programa de Pós-Graduação em Ciências da Computação que aceitou minha candi-

datura ao mestrado e proporcionou-me grandes conhecimentos e experiências necessários para

desenvolver o presente trabalho.

Ao professor Kelvin Lopes Dias que sempre esteve apoiando-me e incentivando meu

progresso acadêmico, mesmo desde o começo, quando eu era só um estudante estrangeiro

procurando informação do programa de pós-graduação.

Aos meus colegas Warley, Daladier, Lucas e Filipe, que com seu apoio e conhecimento

me ajudaram a concluir a implementação da minha proposta.

À minha esposa Dayana Rico, por caminhar sempre ao meu lado disposta a brindar-me

força e amor em cada uma das nossas etapas de vida e a percorrer o mundo inteiro trabalhando

juntos para conseguir nossos sonhos.

Obrigado mãe porque a pesar de estar a mais de 4500Km de distância, eu posso sentir

seu amor e sua fortaleza incentivando-me a continuar sempre na busca dos meus objetivos, você

tem sido o melhor exemplo de superação e fortaleza.

Obrigado pai por cuidar na nossa família desde o céu, sempre apresentando-nos o melhor

caminho.

Dime y lo olvido, enséñame y lo recuerdo, involúcrame y lo aprendo.

—BENJAMIN FRANKLIN (1706-1790)

Resumo

Devido às limitações das redes de sensores sem fio (RSSFs) em termos de recursos de

memória, poder computacional, comunicação e escalabilidade, dois de seus grandes desafios

são: o gerenciamento eficiente da vasta quantidade de dados coletados e o compartilhamento

dos sensores entre diversas aplicações. Atualmente, existem várias propostas, com suporte

da computação em nuvem, para a aplicação de sensores em cidades inteligentes. Contudo,

tais soluções não oferecem ferramentas ou plataformas para o desenvolvimento de aplicações

baseadas em RSSFs que façam a gestão dos dados, bem como forneçam interfaces padronizadas,

para que usuários finais desenvolvam e gerenciem as aplicações e os serviços fornecidos pela

mesma infraestrutura. Desta forma, esta dissertação propõe uma nova arquitetura baseada no

paradigma de Computação Orientada a Serviços (SOC – Service-Oriented Computing), para

o gerenciamento eficiente de dados de RSSFs heterogêneas. Propõe-se um mecanismo de

virtualização que fornece representações lógicas: tanto para sensores individuais, quanto para

agrupamentos, objetivando padronizar os dados gerados pelas RSSFs, além de prover o suporte

à qualidade de serviço (QoS – Quality of Service) nos processos de coleta, armazenamento,

processamento e distribuição destes dados. Além disso, a proposta fornece serviços para

o desenvolvimento de aplicações consumidoras dos dados. A arquitetura proposta utiliza o

framework WSO2©, o qual proporciona toda uma plataforma de middleware para desenvolver

soluções baseadas em SOA (Service Oriented Architecture) no ambiente de computação em

nuvem. Os serviços oferecidos pela proposta são fornecidos segundo o modelo PaaS (Plataform

as a Service) pelo Apache Stratos, que executa sobre uma infraestrutura de nuvem gerenciada

com OpenStack. A virtualização dos dados dos sensores é feita através do conceito de filas de um

Middleware Orientado a Mensagens (MOM – Message Oriented Middleware) utilizando a API

JMS (Java Message Service). O serviço de armazenamento dos dados das RSSFs é composto e

executado pelo servidor de orquestração BPS (Business Process Server), que inclui o fluxo de

dados entre os serviços de acesso às filas e os serviços de armazenamento no banco de dados.

Este serviço é executado automaticamente como uma tarefa programada no ESB (Enterprise

Service Bus), sendo invocado com uma periodicidade que dependerá da carga de dados no

sistema. A implementação da arquitetura foi avaliada com diversas cargas e periodicidades na

coleta de dados das RSSFs. As análises permitiram concluir que os componentes da arquitetura

impactam minimamente no desempenho do sistema, ao mesmo tempo em que a proposta permite

atingir os objetivos de gerenciamento eficiente dos dados e tratamento da heterogeneidade de

sensores e aplicações.

Palavras-chave: Cidades Inteligentes, RSSF, Computação em Nuvem, Virtualização, MOM,

SOA, ESB

Abstract

Due to limitations of wireless sensor networks (WSNs) in terms of memory resources,

computational power, communication and scalability, two of its biggest challenges are: the

efficient management of the vast amount of data collected and sharing the sensors between

various applications. Currently, there are several proposals with cloud computing support for

the application of sensors in smart cities. However, such solutions do not provide tools or

platforms for the development of applications based on WSNs, which make the management

of data and provide standardized interfaces for end users to develop and manage applications

and services provided by the same infrastructure. Thus, this work proposes a new architecture

based on the paradigm of Service Oriented Computing (SOC), for efficient management of

heterogeneous WSNs data. It proposes a virtualization engine that provides logical represen-

tations: for individual sensors, and for groups, aiming to standardize the data generated by

WSNs, and provide support for quality of service (QoS) in the collection processes, storage,

processing and distribution of data. Moreover, the proposal provides services for the development

of data-intensive applications. The proposed architecture uses the WSO2 © framework, which

provides a whole middleware platform to develop solutions based on SOA (Service Oriented

Architecture) in the cloud computing environment. The services offered by the proposal are

provided according to the PaaS model (Platform as a Service) by Apache Stratos, running on

a cloud infrastructure managed with OpenStack. Virtualization of the data from the sensors is

made through the concept of queues of a Message Oriented Middleware (MOM) using the JMS

API (Java Message Service). The storage service data of WSN is composed and executed by

BPS orchestration server (Business Process Server), which includes the flow of data between the

access services to queues and storage services in the database. This service runs automatically as

a scheduled task on the ESB (Enterprise Service Bus), being invoked at intervals that depend on

the system’s workload. The implementation of the architecture was evaluated with various loads

and data collection periodicity of WSNs. The analysis showed that the architectural components

incur in a minimal impact on system performance at the same time as the proposal achieves the

efficient management goals of data and management of heterogeneous sensors and applications.

Keywords: Smart Cities, WSN, Cloud Computing, Virtualization, MOM, SOA, ESB

Lista de Figuras

2.1 Rede de sensores sem fio (Rede de Sensores Sem Fio (RSSF)) . . . . . . . . . 21

2.2 Modelo Point-to-Point (PTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3 Modelo publish/subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4 Arquitetura Orientada a Serviço (SOA) . . . . . . . . . . . . . . . . . . . . . . 25

2.5 Arquitetura de Computação na Nuvem . . . . . . . . . . . . . . . . . . . . . . 29

2.6 Nuvem Pública . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.7 Nuvem Privada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.8 Nuvem de Comunidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.9 Nuvem Híbrida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.10 Hypervisor Tipo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.11 Hypervisor Tipo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.12 Arquitetura do Openstack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.13 Internet das Coisas (IoT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.14 Aplicação Smart City - Monitoramento da intensidade de ruído . . . . . . . . . 36

2.15 Aplicação Smart City – Gerenciamento eficiente do serviço de coleta de lixo . . 36

3.1 Virtualização no nível de nó. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2 Várias redes virtuais sobre uma única infraestrutura de rede. . . . . . . . . . . 40

3.3 Uma rede virtual sobre várias infraestruturas de rede. . . . . . . . . . . . . . . 40

4.1 Arquitetura proposta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2 Cenário – Monitoramento ambiental . . . . . . . . . . . . . . . . . . . . . . . 60

4.3 IaaS – Openstack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.4 Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.5 Infraestrutura da implementação da proposta . . . . . . . . . . . . . . . . . . . 64

4.6 Diagrama de fluxo recepção/coleta . . . . . . . . . . . . . . . . . . . . . . . . 67

4.7 Diagrama de fluxo registro/consulta . . . . . . . . . . . . . . . . . . . . . . . 69

5.1 Diagrama de caixa (2,5,*). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74









5.10 Comparação valores médios de aFF. . . . . . . . . . . . . . . . . . . . . . . . 79

Lista de Tabelas

2.1 Caraterísticas da computação em nuvem . . . . . . . . . . . . . . . . . . . . . 27

2.2 Benefícios e Riscos da computação em nuvem . . . . . . . . . . . . . . . . . . 28

2.3 Modelos de entrega de nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4 Descrição dos Serviços do Openstack . . . . . . . . . . . . . . . . . . . . . . 33

3.1 Comparação dos tipos de virtualização de RSSFs . . . . . . . . . . . . . . . . 41

3.2 Caraterísticas das propostas Sensor-Cloud . . . . . . . . . . . . . . . . . . . . 42

3.3 Comparação de caraterísticas dos trabalhos relacionados - Parte 1 . . . . . . . 48

3.4 Comparação de caraterísticas dos trabalhos relacionados - Parte 2 . . . . . . . 54

4.1 Servidores Infrastructure as a Service (IaaS) . . . . . . . . . . . . . . . . . . . 62

5.1 Cenários. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2 Trecho de medições das métricas . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.3 Taxa de descarte de dados, S = 2 . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.4 Tempo médio do aFF, S = 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 74





Lista de Acrônimos

API Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

BPEL Business Process Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

BPS Business Process Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

COS Computação Orientada a Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

DaaS Database as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

ESB Enterprise Service Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

HTML HyperText Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

HTTP Hypertext Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

IaaS Infrastructure as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

IoT Internet das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

JMS Java Message Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

LAN Local Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

LTE Long Term Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

MOM Middleware Orientado a Mensagens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

NaaS Network as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

NIST National Institute of Standards and Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

PaaS Plataform as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

PTP Point-to-Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

QoS Qualidade de Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

REST Representational State Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

RFID Radio Frequency Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

RSSF Rede de Sensores Sem Fio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

SaaS Software as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

SIMTUR Sistema Inteligente para Monitoramento de Tráfego Urbano . . . . . . . . . . . . . . . . 16

SO Sistema Operacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

SOC Service-Oriented Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

SOA Computação Orientada a Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

SoS Sistema de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

SGBD Sistema de Gerenciamento de Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

SLA Service Level Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

SOAP Simple Object Access Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

TIC Tecnologias da Informação e Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

UDDI Universal Description, Discovery and Integration . . . . . . . . . . . . . . . . . . . . . . . . . 31

URL Uniform Resource Locator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

WAN Wide Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

WS Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

WS-BPEL Web Services Business Process Execution Language . . . . . . . . . . . . . . . . . . . . . . . 24

WS-CDL Web Services Choreography Description Language . . . . . . . . . . . . . . . . . . . . . . . . 25

WSDL Web Services Description Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

XML eXtensible Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Sumário

1 Introdução 16

1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.3 Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 Conceitos Básicos 20

2.1 Rede de Sensores Sem Fio (RSSF) . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.1 Middleware Orientado a Mensagens (MOM) . . . . . . . . . . . . . . 22

2.2.2 Java Message Service (JMS) . . . . . . . . . . . . . . . . . . . . . . . 23

2.3 Computação Orientada a Serviços (COS) . . . . . . . . . . . . . . . . . . . . 24

2.4 Computação em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.4.1 Caraterísticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.4.2 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.4.3 Benefícios e Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4.4 Modelos de entrega de Nuvem . . . . . . . . . . . . . . . . . . . . . . 28

2.4.5 Modelos de implantação . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.4.6 Tecnologias envolvidas . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.4.7 Gerenciadores de Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.5 Internet das Coisas (IoT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.6 Cidades Inteligentes (Smart Cities) . . . . . . . . . . . . . . . . . . . . . . . . 34

2.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3 Trabalhos Relacionados 38

3.1 Virtualização de Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2 Integração RSSF e Nuvem (Sensor-Cloud) . . . . . . . . . . . . . . . . . . . . 40

3.3 Análise dos trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . 41


4 Arquitetura Proposta 56

4.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1.1 Camada de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1.2 Camada de Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.1.3 Camada de Virtualização . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.1.4 Camada Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2 Implementação da proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3 Fluxos de informação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.3.1 Fluxo-Recepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.3.2 Fluxo-Coleta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.3.3 Fluxo-Registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.3.4 Fluxo-Consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68


5 Avaliação Experimental 70

5.1 Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.2 Variáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.3 Procedimento de medição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.4.1 Cenário A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.4.2 Cenário B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.4.3 Cenário C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.4.4 Comparação entre cenários . . . . . . . . . . . . . . . . . . . . . . . . 78

5.5 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79


6 Conclusões 81

6.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Referências 84

161616

1Introdução

Atualmente, a indústria, a academia e os governos, dentro do desenvolvimento dos

sistemas inteligentes de informação, estão aproveitando as tecnologias sem fio existentes e

gerando novas aplicações com o objetivo de melhorar a oferta em segurança, eficiência e

comodidade no uso de diversos serviços como: sistemas de transportes (e.g., Sistema Inteligente

para Monitoramento de Tráfego Urbano (SIMTUR) Sistema Inteligente para Monitoramento

de Tráfego Urbano – SIMTUR) (ANSARI et al., 2013), portais de informação ambiental, entre

outros.

Assim, através da utilização de sensores como dispositivos móveis e fixos (por exemplo:

câmeras, sensores de movimento e GPS - Global Positioning System) uma nova capacidade

coletiva emerge, aquela em que as pessoas participam da detecção e da análise de aspectos do

seu entorno. Por isso, compartilhar a informação pode ser estratégico, não apenas por oferecer

serviços avançados em cidades inteligentes, mas também, porque tal compartilhamento de dados

em grande escala está levando para o conceito de Sistema de Sistemas (SoS)(JAMSHIDI, 2011),

que visa a integração orientada a tarefas de diferentes sistemas prestados por organizações

públicas e privadas, oferecendo novos níveis de eficácia e eficiência na tomada de decisões.

Uma Rede de Sensores Sem Fio (RSSF) consiste em sensores autônomos espacialmente

distribuídos, para monitorar cooperativamente condições físicas ou ambientais, tais como: a

temperatura, o som, a vibração, a pressão, o movimento, etc. (AL-JAROODI; MOHAMED,

2012). Cada nó de uma rede de sensores é composto de a) um transceptor de rádio ou outro

dispositivo de comunicação sem fio; b) um pequeno micro controlador, e; c) uma fonte de energia

(ANSARI et al., 2013). Normalmente, esses tipos de redes estão estreitamente ligadas a um

serviço ou a uma aplicação com um propósito específico (RAO et al., 2012) e hoje em dia são

vistas como elementos intrínsecos a conceitos como a Internet das Coisas (IoT) e SoS, onde as

ofertas de serviços inovadores baseados na integração digital de infraestruturas físicas, através

de sistemas de computação, permitirão a prestação de serviços sob demanda (REA; ASLAM;

PESCH, 2013).

Devido às limitações das RSSFs, em termos de uso de memória, consumo de energia,

poder computacional, comunicação, mobilidade e escalabilidade, os dois grandes desafios

17

são o gerenciamento eficiente dos dados coletados e o compartilhamento dos sensores entre

diversas aplicações. Pesquisas na área de RSSFs (AHMED; GREGORY, 2011)(REA; ASLAM;

PESCH, 2013)(HASSAN; SONG; HUH, 2009) apontam que há uma necessidade de um uso mais

inteligente e cooperativo destas redes, bem como um arcabouço mais eficiente de armazenamento

e de poder computacional, tanto para o processamento das informações em tempo real, quanto

para o armazenamento (online e offline) dos dados processados.

Ao se falar em armazenamento e poder computacional, a computação em nuvem (Cloud

Computing) (MIRASHE; KALYANKAR, 2010) é uma das tecnologias dominantes. Nesta

tecnologia são oferecidos aos usuários recursos computacionais virtualizados, através da Internet,

por meio de computadores e servidores compartilhados (HASSAN; SONG; HUH, 2009). A

integração entre as redes de sensores e a computação na nuvem é uma das soluções para os

problemas apresentados, denominada por ANSARI et al. (2013) como Sensor-Cloud. Esta

integração visa resolver o problema de armazenamento e distribuição dos dados coletados

nas redes de sensores sem fio (DELICATO et al., 2003) e, adicionalmente, permite processar

informações de diversas RSSFs, viabilizando o compartilhamento de informações em larga

escala, bem como o trabalho colaborativo entre aplicações e usuários.

Por sua vez, uma Sensor-Cloud impulsiona a necessidade de infraestruturas de RSSF

reutilizáveis, flexíveis e gerenciáveis. Para simplificar a operação e manutenção do sistema, bem

como para reduzir custos, a virtualização das redes e/ou dos sensores permite fluxos de comuni-

cação direta entre dispositivos heterogêneos, escondendo a complexidade da heterogeneidade

fim-a-fim dos serviços de comunicação. No entanto, a complexidade das tecnologias e da infini-

dade de redes heterogêneas interconectadas limita as estratégias de integração (GLOMBITZA;

PFISTERER; FISCHER, 2009)(ISLAM; HUH, 2012)(REA; ASLAM; PESCH, 2013).

Portanto, este trabalho propõe uma arquitetura para o gerenciamento eficiente de dados

em RSSF, utilizando virtualização para a padronização dos dados provenientes das redes hete-

rogêneas de sensores e computação na nuvem como meio de armazenamento, processamento,

distribuição e compartilhamento desses dados. Esta integração provê uma série de benefícios,

tais como:

� Combinar os serviços oferecidos pelas diferentes organizações (privadas e públicas)

graças à integração de altas quantidades de dados acumulados de vários sensores, de

várias RSSFs ou de vários sistemas;

� Suportar um grande número de usuários, de forma confiável e descentralizada;

� Viabilizar a transparência no sensoriamento, processamento e distribuição da infor-

mação ao usuário;

� Lidar com parâmetros de Qualidade de Serviço (QoS) dependendo das necessidades

do usuário;

� Tolerar falhas com base na replicação inteligente;

1.1. OBJETIVO GERAL 18

� Fornecer plataformas de visualização para representar com diagramas os dados

armazenados e recuperados de vários dispositivos, redes e sistemas ativos;

� Mudar regras de processamento de eventos sem afetar todo o sistema;

� Disseminar a informação de forma eficiente (os serviços de acesso e armazenamento

de dados estarão distribuídos geograficamente) assegurando a disponibilidade e a

integridade dos dados;

� Oferecer e compartilhar infraestruturas tecnológicas caras, com menos custos.

� Fornecer redundância e manutenção regular de processos, que garantam um fluxo

contínuo dos serviços;

� Disponibilizar ferramentas para o desenvolvimento de serviços e aplicações, que

utilizem os dados dos sensores.

Todos os benefícios listados acima serão disponibilizados por meio um conjunto de

serviços Web, que fornecerão as funções, as quais permitirão registrar e consultar dados de

sensoriamento, assim como funções de gerenciamento das redes ou dos sensores registrados.

Como as interfaces estão bem definidas sob padrões Web Services (WS)1 , com tipos de dados

ou tipos de estruturas baseadas em tipos de dados primitivos, o sistema responderá ao principal

desafio desse tipo de ferramentas, a interoperabilidade.

1.1 Objetivo Geral

Propor uma arquitetura de integração de RSSFs com a computação em nuvem, no

contexto de cidades inteligentes, que lide com o gerenciamento eficiente dos dados coletados

pelas RSSFs, aproveitando a ampla capacidade de recursos de armazenamento e processamento

da nuvem. A proposta implementada na dissertação visa o compartilhamento de informações em

larga escala, viabilizando o trabalho colaborativo entre aplicações e usuários, além de fornecer

suporte para o desenvolvimento de aplicações de RSSFs.

1.2 Objetivos Específicos

Os objetivos específicos desta dissertação são:

� Definir os componentes, as responsabilidades, os papéis e os fluxos de informação

que farão parte de arquitetura;

1Alguns exemplos deste tipo de padrões são: WSDL, WSBPEL, WS-Security, WS-Transaction, os quaissão desenvolvidos e publicados pela Advancing Open Standards for the Information Society – OASIS (videhttps://www.oasis-open.org/standards)

https://www.oasis-open.org/standards

1.3. ORGANIZAÇÃO DA DISSERTAÇÃO 19

� Usar Computação Orientada a Serviço (COS) como base para definir o modelo de

serviço para RSSF, que ofereça interfaces funcionais, as quais sejam reutilizáveis,

componíveis, flexíveis e gerenciáveis;

� Investigar técnicas para a implementação de virtualização de sensores através de

middleware;

� Elaborar uma camada de virtualização, que lide com os problemas relacionados à

conectividade entre os sensores heterogêneos;

� Definir os modelos padronizados de representação, configuração e gerenciamento

dos dados dos sensores e das redes virtuais;

� Determinar as interfaces que ligam a camada encarregada da virtualização dos senso-

res com a nuvem, especificando que modelo básico de serviço (Ex: Infrastructure

as a Service (IaaS), Plataform as a Service (PaaS), Software as a Service (SaaS))

responde melhor as necessidades da arquitetura;

� Deliberar como devem ser feitas as interfaces de serviço dos sensores e das redes

(físicas e virtualizadas), para que afinal possam ser orquestradas dinamicamente,

automatizando e agilizando o provisionamento de recursos tanto de sensoriamento,

quanto computacionais;

� Implementar um testbed baseado na arquitetura proposta, visando avaliar a carga, em

relação ao tempo adicionado pelos componentes do sistema na disponibilização dos

dados.

1.3 Organização da Dissertação

Este trabalho está organizado da seguinte forma. O capítulo 2 apresenta os fundamentos

para o desenvolvimento desta dissertação. O capítulo 3 apresenta e discute propostas e trabalhos

relacionados com a integração entre RSSFs e nuvem. O capítulo 4 apresenta a arquitetura

proposta e os seus componentes, assim como a implementação dessa arquitetura (Testbed). O

capítulo 5 apresenta a avaliação e os testes da implementação da proposta. Finalmente, o capítulo

6 apresenta as conclusões da dissertação, assim como os trabalhos futuros.

202020

2Conceitos Básicos

Neste capítulo serão abordados conceitos que são os elementos básicos para a realização

desse trabalho. Serão apresentados conceitos referentes às RSSFs, suas limitações e alguns

desafios existentes, para o gerenciamento de dados mais abrangentes. Em seguida, será tratado o

conceito de middleware, mostrando como este tipo de software pode ser classificado a partir da

abstração fornecida para a comunicação, e será detalhado o middleware orientado a mensagem.

O terceiro conceito abordado é a COS e terminologias relacionadas, como Computação Orien-

tada a Serviço (SOA), orquestração de serviços, Enterprise Service Bus (ESB), dentre outros;

também são ressaltados os benefícios do uso deste paradigma quando um sistema implementa os

princípios do modelo de serviço. Na seção subsequente se faz uma apresentação bem abrangente

sobre a Computação em Nuvem, mostrando suas caraterísticas, passando pelos modelos de

entrega e de implantação, até chegar aos softwares de gerenciamento de nuvem. Por fim, serão

discutidos os principais conceitos referentes às Cidades Inteligentes (Smart Cities), bem como

da IoT, mostrando como elas se relacionam com as RSSFs.

2.1 Rede de Sensores Sem Fio (RSSF)

As RSSFs são redes compostas por dispositivos de sensoriamento, onde cada nó/dispositivo

conta com basicamente três componentes: processamento, comunicação e fonte de energia (RAJ-

KUMAR et al., 2013). Esse tipo de rede caracteriza-se por ter comunicação multi-salto e serem

auto-organizáveis, colaborativas e autoconfiguráveis (ZHANG; SUN; YAN, 2013). Dentro da

rede, cada nó pode tornar-se um nó de sensoriamento, nó servedouro ou nó gateway (ISLAM

et al., 2012) (Figura 2.1). O primeiro tipo só se encarrega de obter os dados do ambiente e

convertê-los em mensagens, para serem enviadas ao nó gateway através dos outros nós, depen-

dendo do protocolo de comunicação da rede. O segundo tipo representa um grupo de nós de

sensoriamento e se encarrega de receber as mensagens com os dados coletados pelos nós de

sensoriamento e pode, adicionalmente, fazer um processamento adicional como agrupamento,

agregação e, em alguns casos, compressão e cifragem, para diminuir a redundância nos dados

e a carga na rede (KULKARNI; FöRSTER; VENAYAGAMOORTHY, 2011). O último é o

2.1. REDE DE SENSORES SEM FIO (RSSF) 21

nó que comunica a rede com uma rede externa (Internet) e, portanto, se encarrega de fazer a

transformação entre os protocolos de comunicação da rede interna e da rede externa.

Figura 2.1: Rede de sensores sem fio (RSSF)

Esse tipo de rede é fortemente condicionada à reduzida capacidade dos dispositivos

que a compõem, aliadas à limitação de quantidade de memória, capacidade de processamento,

consumo de energia, comunicação, mobilidade e escalabilidade. Ademais, o compartilhamento

dos dados dos sensores, de forma eficiente, é um desafio ((HASSAN; SONG; HUH, 2009)),

dado que esses tipos de redes são desenvolvidas com objetivos específicos e configuradas sob

parâmetros estritamente ligados ao tipo de serviço, ou das próprias especificações e necessidades

dos usuários.

Estudos recentes (MITTON et al., 2012)(SOLDATOS; SERRANO; HAUSWIRTH, 2012)

apontam que os recursos das RSSFs deveriam ser expostos como serviços, visando lidar com a

necessidade de uma infraestrutura de RSSF reutilizável, flexível e gerenciável, para simplificar

a operação e manutenção do sistema, além da redução de custos. Portanto, as RSSFs devem

tornar-se infraestruturas que sejam capazes de fornecer serviços, para vários usuários finais

simultaneamente, em vez de ter infraestruturas individuais, para fins específicos, como é típico

das infraestruturas atuais.

Adicionalmente, as RSSFs são vistas como elementos intrínsecos a conceitos como o da

IoT e SoS, onde a oferta de serviços inovadores, baseados na integração digital de infraestruturas

físicas, através de sistemas de Tecnologias da Informação e Comunicação (TIC), que permitem

a prestação de serviços sob demanda. Deste modo, estes tipos de redes são vistas como um

elemento promissor na concepção de cidades inteligentes e aplicações afins. A crença ampla-

mente difundida é que a sinergia entre a RSSF e computação em nuvem oferecerá uma solução

potencial, para a gestão de redes da próxima geração, na forma de dados e de virtualização de

infraestrutura (REA; ASLAM; PESCH, 2013).

2.2. MIDDLEWARE 22

2.2 Middleware

É uma camada de software que lida com a execução e desenvolvimento de aplicações dis-

tribuídas. Localiza-se entre o Sistema Operacional (SO) e a aplicação abstraindo a complexidade

e a heterogeneidade dos elementos do sistema, além de coordenar como eles interagem entre si

(MAHMOUD, 2004). Basicamente, utiliza mecanismos de comunicação de baixo nível com a

infraestrutura, para assim fornecer uma comunicação de alto nível para as aplicações distribuídas

(STAVROPOULOS et al., 2013). Os middlewares podem ser classificados em diversas categorias,

e essas categorias estão baseadas, por exemplo, na abstração fornecida para a programação da

comunicação (tuplas distribuídas, procedimentos, mensagens e objetos distribuídos), em como

as entidades se comunicam (cliente/servidor, ponto-a-ponto e publish/subscribe), e no tipo de

comunicação (síncrona, assíncrona).

Especialmente para o caso das RSSFs, os middlewares visam ocultar a complexidade e

heterogeneidade das plataformas de hardware e de rede subjacentes, facilitando e aprimorando o

gerenciamento dos recursos do sistema, além de aumentar a previsibilidade das execuções das

aplicações. Como visto na Seção 2.1, os principais pontos críticos de operação deste tipo de

redes são a limitação da quantidade e capacidade dos recursos, a topologia de rede dinâmica e

as limitações das Application Programming Interfaces (APIs) embutidas no SO de baixo nível.

Assim, este tipo de software está focado em permitir o desenvolvimento de aplicações, entregando

abstrações do sistema de tal forma que o programador possa centrar-se nas regras do negócio,

sem preocupar-se com a implementação de baixo nível, além de proporcionar serviços, com

código reutilizável, que permitam executar funções complexas sem enfrentar códigos profundos

e complicados, objetivando o aprimoramento do gerenciamento e da gestão da infraestrutura,

através de serviços eficientes (WANG et al., 2008).

2.2.1 Middleware Orientado a Mensagens (MOM)

Em um Middleware Orientado a Mensagens (MOM) o tipo de primitiva de interação é a

passagem de mensagens mediante uma comunicação assíncrona. Este tipo de middleware possui

dois modelos de comunicação: um através de filas ou Ponto-a-Ponto (Point-to-Point (PTP)) e

outro através de tópicos ou publish/subcribe.

O modelo PTP usa filas para estabelecer a comunicação entre os clientes ou usuários.

O cliente que encaminha a mensagem para uma fila é chamado de "produtor"e o cliente que

recebe ou lê as mensagens é chamado de "consumidor". Neste caso, o produtor é ciente do

destino da mensagem e a envia diretamente para a fila do consumidor (Figura 2.2). Este modelo é

caracterizado pelo fato de apenas um consumidor ler a mensagem e por não ser necessário que o

produtor esteja em execução, no momento em que o consumidor lê a mensagem. Portanto, não é

necessário que o consumidor esteja em execução no momento que o produtor envia a mensagem.

Por sua vez, o Modelo publish/subscribe, para estabelecer a comunicação entre clientes

2.2. MIDDLEWARE 23

Figura 2.2: Modelo PTP

usa a publicação de mensagens em um determinado tópico. Os clientes que desejam os dados

sobre um determinado tópico, chamados de "assinantes"(subscribers), podem registrar seu

interesse em receber as mensagens do “publicador” (publisher) (Figura 2.3). Este modelo

se caracteriza pelo fato de ambos, assinante e publicador, não estarem cientes um do outro;

múltiplos consumidores podem ler a mensagem; existe uma dependência temporal entre os

publicadores e assinantes de um tópico. Além do mais, o assinante do tópico deve estar em

execução continuamente para receber as mensagens. Para oferecer algumas caraterísticas de QoS

este tipo de middleware conta com mecanismos de persistência para as mensagens (manter cópia

das mensagens em um local de armazenamento estável), dado que elas podem ser transmitidas e

processadas horas depois do envio. Para garantir a entrega, por exemplo, este tipo de middleware

pode utilizar um, ou vários, dos seguintes mecanismos: o uso de Sistemas de Sistema de

Gerenciamento de Banco de Dados (SGBD), o reenvio de mensagens, e uso de prioridades e de

ranqueamento das mensagens.

Figura 2.3: Modelo publish/subscribe

2.2.2 Java Message Service (JMS)

É um padrão para desenvolvimento de MOM em linguagem Java, o qual possui uma

API que define as interfaces que devem acessar os programas (clientes) escritos em Java, para

poder usar os recursos de um Message Broker em conformidade com a especificação Java

Message Service (JMS). Cada mensagem é formada por três partes: o cabeçalho (identificador,

prioridade, tempo de expiração, transmissor, etc.), um conjunto de atributos adicionais e a carga

2.3. COMPUTAÇÃO ORIENTADA A SERVIÇOS (COS) 24

útil (payload). A API JMS suporta os modelos de troca de mensagens PTP e publish/subscribe.

Os elementos básicos, no primeiro modelo, são: Queue, Senders e Receivers; do segundo são:

Publishers, Subscribers e Topics.

2.3 Computação Orientada a Serviços (COS)

A COS é um paradigma computacional que utiliza o serviço como elemento principal

para o desenvolvimento de aplicações distribuídas. Sob esse paradigma, construir uma aplicação

implica descobrir, invocar e compor serviços disponíveis na rede e que, adicionalmente, podem

estar espalhados por várias organizações (PAPAZOGLOU; HEUVEL, 2007).

Um serviço computacional é uma entidade autônoma, independente da plataforma e

fornece alguma “capacidade/funcionalidade” para os clientes, através da troca de mensagens.

Esses tipos de serviços caracterizam-se por serem reutilizáveis e de baixo acoplamento, devido

a redução das dependências entre o usuário e o provedor (os consumidores do serviço são

acoplados ao serviço somente na duração da utilização). Atualmente, os WS são a tecnologia

mais promissora para trabalhar sob o paradigma da Service-Oriented Computing (SOC), pois

fornecem a base para o desenvolvimento e execução de processos ou fluxos de negócios, que são

distribuídos através da rede e estão disponíveis por meio de interfaces e protocolos padrão (AL-

JAROODI; MOHAMED, 2012). Normalmente, usa-se a Internet como meio de comunicação

e estão baseados em padrões abertos baseados em XML, como: i) o Simple Object Access

Protocol (SOAP), para fazer o intercâmbio de informação; ii) a Web Services Description

Language (WSDL), para a definição do próprio serviço, e; iii) a linguagem Web Services Business

Process Execution Language (WS-BPEL), para a orquestração de serviços ((KYUSAKOV et al.,

2013)).

Outro conceito chave é SOA, o qual conceitua e sistematiza a maneira lógica para

desenvolver e fornecer serviços distribuídos em uma rede, por meio de interfaces publicáveis e

detectáveis (PAPAZOGLOU et al., 2008). Como pode-se observar na Figura ??, esta arquitetura

está composta por três camadas (Infraestrutura, Composição e Gerenciamento), a qual inclui

as caraterísticas do serviço, que são transversais nas três camadas: a semântica do serviço, as

caraterísticas não funcionais e a QoS.

Na camada mais baixa encontram-se os elementos fundamentais para executar um sis-

tema baseado em SOA, essa infraestrutura deve fornecer um middleware orientado a serviço,

encarregado de conectar os componentes do sistema, que fornecerá os canais de acesso aos servi-

ços sobre vários tipos de redes (sistemas heterogêneos) e que permitirá a descrição, publicação,

busca e invocação de serviços. Esse middleware é chamado de Enterprise Service Bus (ESB),

e além das funções descritas anteriormente ele está encarregado de estabelecer os padrões de

troca de mensagens, prover recursos de transação e segurança, habilitar métricas de desempenho,

dar suporte à configuração dinâmica, permitir o monitoramento do comportamento/estado dos

serviços, fazer a conversão de protocolo/dados, fornecer a automação de tarefas e de prover o

2.3. COMPUTAÇÃO ORIENTADA A SERVIÇOS (COS) 25

Figura 2.4: Arquitetura Orientada a Serviço (SOA), adaptado e traduzido de(PAPAZOGLOU et al., 2008)

gerenciamento remoto do sistema.

Já na camada intermediária, chamada de camada de composição, faz-se referência

às funcionalidades e caraterísticas que permitem agregar vários serviços num único serviço

composto, que segue uma regra de negócio preestabelecida, e que afinal pode ser oferecido como

uma aplicação ou solução completa para os usuários. Ao se falar de serviços Web compostos,

os termos de orquestração e coreografia descrevem dois aspectos na criação de processos de

negócio. Basicamente, na orquestração o controle do processo sempre é feito só por uma das

partes, o que difere da coreografia, que é mais colaborativa e permite que cada parte envolvida

possa descrever o seu papel na interação. Duas das especificações mais utilizadas na orquestração

e na coreografia são WS-BPEL e Web Services Choreography Description Language (WS-CDL)

respetivamente (PELTZ, 2003); a WS-BPEL fornece uma gramática baseada em XML, para

descrever a lógica de controle necessária na coordenação dos serviços Web, que participam

de um fluxo de processo; portanto, através dela consegue-se especificar tanto processos de

negócios executáveis, quanto processos de negócios abstratos. A WS-CDL descreve apenas o

comportamento de colaboração, desde um ponto de vista global, entre WS. Sendo assim, não

aborda a definição de processos de negócios executáveis como WS-BPEL faz. Isso significa que

nenhum processo único gerencia a interação entre os serviços.

Finalmente, a camada superior chamada de: gerenciamento e monitoramento estabelece

que no desenvolvimento de serviços e aplicações, através de serviços compostos, devem existir

mecanismos que forneçam elementos que constantemente estejam revisando o perfeito funcio-

2.4. COMPUTAÇÃO EM NUVEM 26

namento dos sistemas, que implementam os serviços da Web e os padrões de comportamento

dos mesmos. Portanto, coletar informações sobre serviços, processos de negócio, recursos

gerenciados, etc., assim como dos eventos ou das informações produzidas pelos serviços é

o primeiro passo para realizar ações de gerenciamento, que afinal visam apoiar a tomada de

decisões, através da análise dessas informações, para gerenciar os recursos adequadamente,

objetivando que o desempenho dos sistemas e serviços esteja em sintonia com as políticas e os

requerimentos funcionais e não funcionais do sistema e dos usuários.

Os benefícios de se utilizar este paradigma são: a) permitir que os desenvolvedores de

aplicativos consigam de forma rápida e dinâmica aumentar a quantidade de aplicativos, criando

soluções através de serviços compostos, que usam ativos de software existentes; b) uso de

procedimentos mais ágeis de evolução e manutenção, os quais permitem também a integração

entre sistemas construídos em diferentes linguagens e que possivelmente sejam executados em

diferentes ambientes, devido ao baixo acoplamento dos serviços e às interfaces padronizadas

conseguindo se comunicar, e; c) redução nos custos, graças a reutilização de código e porque o

processo de negócio está alinhado com os processos organizacionais.

2.4 Computação em Nuvem

A computação na nuvem (do inglês Cloud Computing) é definida pelo Instituto Nacional

de Padrões e Tecnologia dos EUA (National Institute of Standards and Technology (NIST))

como:

Cloud Computing is a model for enabling ubiquitous, convenient, on-demand

network access to a shared pool of configurable computing resources (e.g.,

networks, servers, storage, applications, and services) that can be rapidly

provisioned and released with minimal management effort or service provider

interaction [. . . ] (MELL; GRANCE, 2011)

Portanto, a computação em nuvem é um modelo para acesso sob demanda a um conjunto

compartilhado de recursos computacionais configuráveis, como por exemplo: redes, servidores,

armazenamento, aplicações, serviços e software, que podem ser facilmente provisionados como

e quando necessário (RAO et al., 2012). Tipicamente é descrita em termos de proporcionar "X

as a Service"(XaaS), que define uma filosofia geral de assumir tudo como um serviço (REA;

ASLAM; PESCH, 2013).

2.4.1 Caraterísticas

As principais caraterísticas da computação em nuvem, além de uma breve descrição das

mesmas encontram-se na Tabela 2.1 (ANSARI et al., 2013), abaixo:

2.4.2 Papéis

A seguir serão descritos os papéis dos envolvidos na Computação em Nuvem, são eles:


Tabela 2.1: Caraterísticas da computação em nuvem

Caraterística DescriçãoUso sob demanda O consumidor de nuvem pode acessar (uma vez configurada) aos

recursos de nuvem sem precisar de intervenção do provedor denuvem.

Acesso ubíquo Os serviços de nuvem são “amplamente” acessíveis (e.g., suportea vários protocolos de transporte).

Multitenancy Uma única instância de um programa serve a vários consumidoresde nuvem (tenants) mantendo o isolamento entre eles.

Elasticidade Habilidade de escalar (aumentar/diminuir) os recursos de TICde forma transparente em reposta às condições de execução e àssolicitações do consumidor/provedor de nuvem.

Medição Capacidade de manter registro de uso dos recursos TIC da nuvem.O usuário paga apenas o que usa.

Resiliência Redundância de recursos de TIC dentro da mesma nuvem, mas emoutra localização física (ou outra nuvem).

� Provedor de Nuvem: Entidade que provê os recursos de TIC, disponibiliza os

serviços de nuvem seguindo um Acordo de Nível de Serviço (Service Level Agree-

ment (SLA)), é responsável pelo gerenciamento/administração da nuvem, e aluga os

serviços aos consumidores.

� Consumidores de Nuvem: Pessoa ou empresa que assina um SLA para consumir

recursos de provedores de nuvem.

� Dono do serviço da nuvem: Pessoa ou empresa que “legalmente” possui o serviço

de nuvem.

� Administrador dos recursos da nuvem: Pessoa ou empresa responsável pela ad-

ministração dos recursos de TI da nuvem.

� Auditor de Nuvem: Empresa ou pessoa independente (autorizada) que avalia os

ambientes de nuvem (e.g., segurança e desempenho).

� Carrier de Nuvem: Entidade responsável pela conectividade entre o provedor e o

consumidor de nuvem.

2.4.3 Benefícios e Riscos

Os benefícios e riscos (DILLON; WU; CHANG, 2010) de utilizar a computação em

nuvem são apresentados na Tabela 2.2.


Tabela 2.2: Benefícios e Riscos da computação em nuvem

Benefícios Riscos• Investimentos reduzidos em TI. • Aumento na vulnerabilidade de segurança.• Redução/eliminação de investimento inicialem TI.

• Segurança compartilhada com o provedorde nuvem.

• Grande investimento do provedor de nuveme não do cliente.

• Provedor de nuvem tem acesso aos dados.

• Acesso sob demanda e “pay-as-you-go”. • Compartilhamento dos recursos com outrosconsumidores de nuvem.

• Percepção de recursos ilimitados. • Controle operacional reduzido (quem con-trola tudo é o provedor de nuvem).

• Fina granularidade na adição/remoção derecursos de TI.

• Grandes distâncias entre prove-dor/consumidor de nuvem podem levara grandes variações nos atrasos de rede.

• Aplicações podem ser facilmente movidasde um local/dispositivo.

• Portabilidade limitada entre provedores denuvem.

• Aumento na Disponibilidade e Confiabili-dade.

• Falta de padrões sobre computação em nu-vem.

2.4.4 Modelos de entrega de Nuvem

Os modelos de entrega de nuvem são estabelecidos a partir dos tipos “pré-definidos” de

recursos de TIC que podem ser fornecidos por ela. Os modelos básicos são Infraestrutura como

Serviço (IaaS – Infrastructure as a Service), Plataforma como Serviço (PaaS - Platform as a

Service) e Software como Serviço (SaaS – Software as a Service), os quais estão descritos na

Tabela 2.3.

Tabela 2.3: Modelos de entrega de nuvem

Modelo Características ExemploIaaS Os recursos de infraestrutura tipicamente são ofereci-

dos como elementos virtualizados (facilitando a esca-labilidade e a customização da infraestrutura), que sãoacessados ou gerenciados por serviços, ou ferramentasde nuvem.

Hardware, conec-tividade de rede,armazenamento.

PaaS Os recursos para suporte ao desenvolvimento e execu-ção de aplicações (Ferramentas, bibliotecas, serviços,etc.)

Google App Engine(Java, Python e Go).

SaaS Recursos são programas (“comerciais”), tipicamentedisponibilizados como serviços.

Word Online.

Na Figura 2.5 pode-se observar como estes modelos interagem numa arquitetura em

camadas, relacionando algumas das tecnologias incluídas na camada, assim como exemplos de


ferramentas existentes no mercado, que oferecem os serviços próprios dessa camada.

Figura 2.5: Arquitetura de Computação na Nuvem, traduzido de (ZHANG; CHENG;BOUTABA, 2010)

2.4.5 Modelos de implantação

Os modelos de implantação diferenciam as nuvens por dono, tamanho e acesso. Dentre

eles os tipos mais comuns são a nuvem pública, nuvem de comunidade, a nuvem privada e a

nuvem híbrida. A nuvem pública, pertence a um provedor (empresa/organização) que permite o

acesso público, o qual geralmente é pago (Figura 2.6). O provedor de nuvem é responsável pela

criação e manutenção da infraestrutura.

Figura 2.6: Nuvem Pública (ERL; PUTTINI; MAHMOOD, 2013)

A nuvem privada é mantida por uma única empresa ou organização, a qual usa tecnologias

de nuvem para centralizar o acesso aos seus recursos de TI, assim ela é tanto provedora como

consumidora de nuvem (Figura 2.7).


Figura 2.7: Nuvem Privada, traduzido de (ERL; PUTTINI; MAHMOOD, 2013)

A nuvem de comunidade é similar a uma nuvem pública, mas com acesso restrito a

consumidores ou clientes pertencentes a um grupo específico ou comunidade, ela pode ser uma

nuvem pública, mas com acesso restrito e/ou limitado (Figura 2.8).

Figura 2.8: Nuvem de Comunidade, traduzido de (ERL; PUTTINI; MAHMOOD, 2013)

A nuvem híbrida é considerada como a combinação de dois (2) ou mais dos modelos

anteriores. Neste modelo os dados que são considerados sigilosos normalmente ficam armazena-

dos na nuvem privada e aqueles que são públicos ficam armazenados sob qualquer dos outros

modelos (Figura 2.9).

2.4.6 Tecnologias envolvidas

Dentre as tecnologias envolvidas na computação em nuvem encontram-se: a virtualização

(e.g., servidores, recursos), as tecnologias de rede (e.g., Rede de Área Local (Local Area

Network (LAN)), Rede de longa distância (Wide Area Network (WAN)), Internet, etc.), Data


Figura 2.9: Nuvem Híbrida, traduzido de (ERL; PUTTINI; MAHMOOD, 2013)

Centers (e.g., computação em grade, clusterização), tecnologias Web (e.g., Uniform Resource

Locator (URL), Hypertext Transfer Protocol (HTTP), HyperText Markup Language (HTML),

etc.), tecnologias multi-inquilino (do inglês, multitenancy), que permitem acesso simultâneo a

um recurso por vários usuários, e tecnologias de serviços (e.g., WSDL, Universal Description,

Discovery and Integration (UDDI), SOAP, Representational State Transfer (REST), eXtensible

Markup Language (XML), ESB, etc.).

Detalhadamente, a virtualização é o processo de conversão de um recurso físico de TI em

recurso virtual ou simulado, o qual é realizado por um software de virtualização, e.g., VMware1,

KVM2, XEN3, etc. Quando se usa a virtualização, o sistema operacional do “servidor virtual”

não sabe ou não está ciente da virtualização, portanto os servidores virtuais podem facilmente

migrar de um servidor físico para outro. O software de virtualização é chamado comumente

como hypervisor e são classificados em dois tipos, como hypervisor de “Tipo 1 (ou bare-metal)”,

onde o software de virtualização é instalado diretamente no hardware da máquina hospedeira,

e como hypervisor de “Tipo 2”, no qual o software de virtualização roda como uma aplicação

hospedada por um sistema operacional (SO) instalado na máquina hospedeira. As arquiteturas

de cada um desses tipos encontram-se nas figuras 2.10 e 2.11, respetivamente.

2.4.7 Gerenciadores de Nuvem

As plataformas para a computação em nuvem servem, geralmente, para construir e

gerenciar arquiteturas, independentemente do tipo de infraestrutura física envolvida. Através do

uso deste tipo de plataformas, empresas, organizações de pesquisa e administrações públicas

podem criar suas próprias arquiteturas, com base na infraestrutura existente (WIND, 2011).

Atualmente, no mercado existem soluções proprietárias (e.g., Amazon Web Services – AWS,

1http://www.vmware.com/br2http://www.xenproject.org/3http://www.linux-kvm.org/

http://www.vmware.com/br

http://www.xenproject.org/

http://www.linux-kvm.org/


Figura 2.10: Hypervisor Tipo 1 (bare-metal)

Figura 2.11: Hypervisor Tipo 2

Microsoft Windows Azure), implementados principalmente por provedores de nuvem pública,

e plataformas Open-Source (e.g., Cloudstack, openNebula, Eucalyptus, Openstack), que têm

surgido como projetos de pesquisa ou soluções comunitárias para nuvens privadas (ENDO et al.,

2009).

Dentre todos esses frameworks, o Openstack aparece como uma das melhores opções

para criar nuvens privadas e hibridas, dada a compatibilidade que possui com o Amazon EC2

(Amazon Elastic Compute Cloud) e Amazon S3 (Amazon Simple Storage Service). Outro ponto a

favor é que este projeto é apoiado por várias empresas no mundo e é baseado em códigos usados

pela NASA (National Aeronautics and Space Administration) e pela Rackspace4 (SEFRAOUI;

AISSAOUI; ELEULDJ, 2012). Adicionalmente, oferece uma documentação simples, sendo

possível construir uma nuvem mesmo que o usuário não tenha pessoal especializado (Von

Laszewski et al., 2012).

O OpenStack repousa sobre dois grandes projetos diferentes: o primeiro, chamado de

Nova, gerencia principalmente, os recursos de computação e de rede, enquanto o segundo, cha-

mado de Swift, é encarregado do armazenamento distribuído na nuvem (CORRADI; FANELLI;

FOSCHINI, 2014). Os projetos restantes são listados na Tabela 2.4, com as suas respetivas

descrições e o nome do serviço associado. A Figura 2.12 mostra como estes se comunicam e

4Rackspace Inc. Empresa de gerenciamento de computação em nuvem, espalhada e reconhecida mundialmente.https://www.rackspace.com/pt-br

https://www.rackspace.com/pt-br

2.5. INTERNET DAS COISAS (IOT) 33

interagem entre si.

Tabela 2.4: Descrição dos Serviços do Openstack

Serviço Projeto DescriçãoDashboard Horizon Fornece um front-end, baseado na web, para interagir com

os serviços do OpenStack.Computação Nova Gerencia o ciclo de vida de instâncias de máquinas virtuais

(VM).Rede Neutron Permite a conectividade de rede como um serviço, para

outros serviços do Openstack. Fornece uma API para queos usuários definam as redes, permite a criação das RedesVirtuais de Inquilinos e suas possíveis conexões.

Armazenamentode objetos

Swift Armazena e recupera objetos de dados não estruturados,através de uma API RESTful baseada em HTTP.

Armazenamentode bloques

Cinder Fornece armazenamento persistente para instâncias em exe-cução.

Identificação Keystone Fornece um serviço de autenticação e autorização para osoutros serviços do OpenStack. Também fornece um catálogocom todas as interfaces dos serviços do OpenStack.

Imagens Glance Armazena e recupera imagens de máquinas virtuais.Telemetria Ceilometer Monitora e mensura vários aspetos da nuvem para fatura-

mento, benchmarking, escalabilidade e para fins estatísticos.Orquestração Heat Orquestra várias composições de aplicações de nuvem

usando o modelo nativo de template ou o formato AWS

CloudFormation.Banco de dados Trove Fornece Bancos de dados como serviço (Database as a Ser-

vice (DaaS)) escaláveis e confiáveis tanto para bancos dedados relacionais quanto para não relacionais.

2.5 Internet das Coisas (IoT)

A IoT refere-se a objetos (coisas) singularmente identificáveis e a suas representações

virtuais em uma estrutura interconectada, tal como a Internet. Esses objetos são elementos do

cotidiano, que podem ser lidos, reconhecidos, localizados, endereçados e controlados, através

da Internet, usando tecnologias de rede como: Radio Frequency Identification (RFID), Wi-

Fi, WAN, Long Term Evolution (LTE), etc. No entanto, nesses objetos não estão incluídos

apenas os dispositivos eletrônicos ou os produtos com maior desenvolvimento tecnológico, como

veículos e equipamentos, mas também se incluem coisas como alimentos, roupas, materiais,

matérias primas, etc. (RAO et al., 2012). Assim, a IoT compõe-se de dispositivos heterogêneos

5Openstack Conceptual Architecture – http://docs.openstack.org/icehouse/

install-guide/install/apt/content/ch_overview.html

http://docs.openstack.org/icehouse/install-guide/install/apt/content/ch_overview.html


2.6. CIDADES INTELIGENTES (SMART CITIES) 34

Figura 2.12: Arquitetura do Openstack5

incorporados à rede, que se comunicam através de enlaces cabeados ou sem fio à Internet, para

apoiar aplicações baseadas nas informações obtidas dos objetos, que sejam sensíveis ao contexto

e que permitam interagir com o mundo físico de forma ubíqua (Figura 2.13).

As abstrações atuais da IoT para o desenvolvimento de aplicações tentam ocultar a

heterogeneidade da rede e o processamento distribuído, realizando esse processo em uma

outra infraestrutura (e.g., nuvem) e os objetos passam a ser somente provedores de dados

(LAUKKARINEN; SUHONEN; HäNNIKäINEN, 2013).

2.6 Cidades Inteligentes (Smart Cities)

O termo “Cidade Inteligente” é uma visão onde as cidades podem oferecer para os

cidadãos novos serviços, com base na integração digital das infraestruturas da cidade, através

de sistemas de computação, os quais permitem a prestação de serviços sob demanda (REA;

ASLAM; PESCH, 2013). Este conceito nasce da necessidade de gerenciamento de vários

problemas causados pelo desenfreado crescimento populacional em centros urbanos, que afetam

diretamente vários serviços, tais como transporte, segurança, abastecimento e consumo de água

e energia elétrica, saneamento, utilização de recursos naturais, gestão de desastres, dentre outros.

Em um ponto de vista simplista, a gestão de cada serviço sugere um monitoramento cons-

6http://www.theexaminer.com/features/commentary/internet-things

http://www.theexaminer.com/features/commentary/internet-things


Figura 2.13: Internet das Coisas (IoT)6

tante, pelo uso de mecanismos para a coleta de dados dos entornos, os quais serão processados e

analisados, retornando como resposta algum tipo de ação, que garanta a prestação dos serviços

em níveis satisfatórios de qualidade. Por sua vez, a visão complexa da aplicação do gerencia-

mento de serviços, de forma distribuída e integrada, exige uma solida utilização de algum tipo de

sensor nos elementos dos sistemas, de modo segmentado, para que a partir desse monitoramento

unitário seja construída uma visão abrangente da cidade, dedicada à manutenção eficiente dos

seus serviços, com o objetivo de melhorar a qualidade dos mesmos. Desde este ponto de vista,

cada elemento do sistema deveria contar com alguma tecnologia da informação embutida, que o

converta em um provedor de dados e, ao mesmo tempo, que colaborativamente faça chegar essa

informação a uma entidade centralizada, responsável pelo processamento inteligente da gestão

do serviço (e.g., Sensores e IoT) (SILVA et al., 2013). Uma ilustração do exemplo anterior será

mostrado na Figura 2.14, na qual é observado como vários dispositivos/objetos se comunicam

entre si, para encaminhar dados de sensoriamento de intensidade de ruído, em um determinado

local de uma cidade.

Adicionalmente, o compartilhamento dessas informações pode ser estratégico, não só

para oferta de serviços avançados, mas também para entender as correlações entre os dados. Este

último pode ser muito complexo, dado que depende de algoritmos sofisticados (e.g., inteligência

artificial). A ideia do tal compartilhamento massivo de dados, remete ao conceito de sistema de

sistemas, que visam alcançar a integração orientada a tarefas de diferentes "sistemas"fornecidos

por organizações públicas e privadas independentes, oferecendo novos níveis de eficácia e

eficiência nas cidades (MITTON et al., 2012). Na Figura 2.15 pode-se observar um exemplo


Figura 2.14: Aplicação Smart City - Monitoramento da intensidade de ruído (JIN et al.,2014)

apresentado em PERERA et al. (2014) de como o serviço de coleta de lixo pode ser aprimorado,

através do conceito de cidade inteligente usando tecnologias de comunicação sem fio (e.g., RFID,

RSSF, IoT) e computação na nuvem.

Figura 2.15: Aplicação Smart City – Gerenciamento eficiente do serviço de coleta delixo (ZHANG et al., 2014)

2.7. CONSIDERAÇÕES FINAIS 37

2.7 Considerações Finais

Este capítulo apresentou um resumo dos conceitos, que fundamentam o desenvolvimento

de infraestruturas de integração de RSSF com a computação na nuvem, referentes a este trabalho.

Neste sentido, a seção inicial apresentou os principais conceitos relativos às RSSFs. Em seguida,

foi apresentado o conceito de middleware e sua relação com as RSSFs. Na seção seguinte foram

apresentados os principais conceitos da computação orientada a serviço, além dos principais

fatores que aportam esta abordagem no desenvolvimento de aplicações. Na seção subsequente,

foi feita uma aproximação abrangente da Computação em Nuvem. Por fim, foram tratados os

temas referentes às Cidades Inteligentes (Smart Cities), e à Internet das coisas (IoT), que as

relacionam com as RSSFs.

383838

3Trabalhos Relacionados

Este capítulo tem por finalidade apresentar os principais trabalhos na área da integração

entre RSSFs com computação em nuvem, que visam lidar com as limitações intrínsecas desse

tipo de rede, através de outras tecnologias como a virtualização de sensores, middleware e a

SOA.

Particularmente, este capítulo inicia com a apresentação dos temas de virtualização de

sensores e uma abordagem de integração de RSSFs com computação em nuvem chamada de

Sensor-Cloud. Por fim, os estudos relacionados a estes dois tópicos são discutidos e apresentados,

ressaltando-se tanto suas contribuições, quanto suas limitações.

3.1 Virtualização de Sensores

A virtualização de sensores e de RSSFs visa separar os serviços da infraestrutura e

permitir a criação de novos negócios, através da comercialização de recursos entre múltiplos

provedores de serviços e clientes (ISLAM et al., 2012). Existem três tipos de virtualização de

sensores classificados nos seguintes níveis: nó, rede e virtualização de dados.

A virtualização no nível de nó permite a execução de múltiplas aplicações concorrente-

mente em um mesmo nó. Isto permite explorar as capacidades individuais dos nós para executar

várias tarefas de aplicação (Figura 3.1). Este tipo de virtualização pode ser classificada como

sequencial e simultânea. A virtualização sequencial é aquela na qual a execução das aplicações é

feita uma a uma (em série), apresentando a vantagem da facilidade de implementação e a desvan-

tagem de que existem tempos de espera no enfileiramento das execuções. Já na virtualização

simultânea, as tarefas das aplicações são executadas em fatias de tempo pequenas, mudando

rapidamente entre estas.

Esta abordagem apresenta a vantagem de que a execução das aplicações gastará menor

tempo, dado que uma única aplicação não poderá bloquear o sistema até terminar sua execução,

sendo que a desvantagem é o aumento da complexidade de implementação. Um exemplo desta

implementação é o uso de um middleware para intermediar entre as aplicações e os sensores.

Portanto, os sensores não dependem da aplicação que os utilizará, e as aplicações também não

3.1. VIRTUALIZAÇÃO DE SENSORES 39

estarão cientes de que sensores a utilizarão. Assim, os principais desafios que este tipo de

solução apresenta são: como fazer que uma nova aplicação encontre os sensores que respondam

às suas necessidades e, como negociar com os donos das infraestruturas de sensores para poder

utilizá-los (NAVARRO et al., 2011).

Figura 3.1: Virtualização no nível de nó (KHAN et al., 2015).

A virtualização no nível de rede, permite a criação de redes virtuais de sensores (Virtual

Sensor Networks - VSN), que são subgrupos de sensores dedicados a atender as necessidades

de uma aplicação em um tempo determinado. Assim, a criação de subgrupos é dinâmica,

assegurando um melhor uso dos recursos, uma vez que os nós remanescentes podem ser utilizados

para responder às necessidades de outras aplicações. Estes subconjuntos podem variar em

tamanho e em número de acordo com os requisitos da aplicação (REA; ASLAM; PESCH, 2013).

Existem duas possibilidades para criar os subgrupos, uma é sobre uma mesma infraestrutura

física de rede (Figura 3.2) e a outra é ter diferentes infraestruturas físicas de rede e criar subgrupos

entre os nós das diferentes infraestruturas (Figura 3.3) (KHAN et al., 2015). Para possibilitar

este tipo de virtualização deve existir um protocolo de rede de sensores virtuais, que forneça

as funcionalidades para formar as sub-redes, utilizá-las, adaptá-las segundo as necessidades e

realizar a manutenção dos subconjuntos, que colaboram em uma tarefa específica.

A virtualização de dados permite que o usuário final só tenha acesso aos dados coletados

pelos sensores. Assim, eles não podem mudar parâmetros ou configurações da infraestrutura

física da RSSF (REA; ASLAM; PESCH, 2013), mas podem dispor dos dados como se eles

fossem propriedade do usuário. Na Tabela 3.1 são expostas, sucintamente, algumas das vantagens

e desvantagens de utilizar cada um destes tipos de virtualização.

3.2. INTEGRAÇÃO RSSF E NUVEM (SENSOR-CLOUD) 40

Figura 3.2: Várias redes virtuais sobre uma única infraestrutura de rede (KHAN et al.,2015).

Figura 3.3: Uma rede virtual sobre várias infraestruturas de rede (KHAN et al., 2015).

3.2 Integração RSSF e Nuvem (Sensor-Cloud)

Na integração das RSSFs com a computação na nuvem o principal termo adotado na

literatura é Sensor-Cloud (ANSARI et al., 2013). Uma Sensor-Cloud é uma infraestrutura

compartilhada, onde múltiplas aplicações e usuários finais podem interagir com as infraestruturas

físicas das RSSFs sem requerer uma mudança fundamental na forma como os recursos delas são

gerenciados, especificamente no nível do dispositivo físico (REA; ASLAM; PESCH, 2013). Esta

interação permite que várias das limitações das RSSFs, como a capacidade de armazenamento

e processamento de dados, tornem-se muito mais fáceis de tratar, dado que a computação em

nuvem oferece uma grande capacidade de recursos computacionais, os quais permitem manipular

uma enorme quantidade de dados gerados pelas RSSFs. Dado que a implantação das RSSFs é

cara e a manutenção dos sensores é bastante elevada, haverá naturalmente uma sensível economia

na infraestrutura com o uso das Sensor-Clouds, pois pode-se efetivamente dividir os custos tanto

com o compartilhamento da RSSFs com os inquilinos, bem como o da IaaS da nuvem (RAO

et al., 2012).

3.3. ANÁLISE DOS TRABALHOS RELACIONADOS 41

Tabela 3.1: Comparação dos tipos de virtualização de RSSFs

Tipo devirtualização

Vantagens Desvantagens

Nó Maior controle no acesso aos dispo-sitivos físicos de sensoriamento.

Algoritmos complexos de virtualiza-ção ou execução concorrente; Maiorconsumo de energia.

Rede Criação dinâmica de sub-redes a par-tir de infraestruturas existentes.

Protocolos ou mecanismos de comu-nicação de rede virtual não padroni-zados.

Dados Pode ser utilizada qualquer represen-tação de dados, dependendo das ne-cessidades do usuário e do desenvol-vedor.

Representações virtuais não padroni-zadas; Carece de mecanismos paragerenciar os dispositivos físicos.

Os objetivos básicos a serem atingidos neste tipo de arcabouço são: coletar e processar

dados de várias redes de sensores, permitir o compartilhamento de dados em grande escala,

oferecer a colaboração entre usuários e aplicações na nuvem e prover a interação entre aplicações

multidisciplinares que vão além das fronteiras organizacionais (ANSARI et al., 2013). Assim,

os usuários podem usar os sensores sem se preocupar com suas localizações e especificações

detalhadas. A infraestrutura de nuvem contém mecanismos para traduzir as funções padrões dos

sensores virtuais, em funções específicas para os diferentes tipos de sensores físicos. Neste ponto

é fundamental o uso dos modelos de virtualização, explicados na Seção 3.1, já que dependendo de

como sejam definidas as representações virtuais dos sensores, os sensores físicos são preparados

para compartilhar as suas funcionalidades. Consequentemente, os usuários podem solicitar

sensores virtuais ou grupos de sensores virtuais, e após o provisionamento, liberá-los quando se

tornarem desnecessários. Na Tabela 3.2 pode-se observar um resumo dos benefícios obtidos ao

se integrar RSSF e a computação em nuvem, com base em (ANSARI et al., 2013).

Para este arcabouço, os modelos de nuvem PaaS e SaaS são as opções mais populares,

pois além de trazer os dados das RSSFs para a nuvem, o uso de PaaS permite desenvolver e

gerenciar serviços que podem ser oferecidos como SaaS (GLITHO; MORROW; POLAKOS,

2013).

3.3 Análise dos trabalhos relacionados

Como mencionado no começo deste capítulo, a seguir apresenta-se uma análise de

algumas das propostas relacionadas com a integração das RSSFs com a nuvem. Para cada uma

delas ressaltam-se tanto os seus benefícios, quanto as suas limitações. No final do capítulo, duas

tabelas resumem os aspectos mais importantes desses trabalhos.

No trabalho de MITTON et al. (2012) os autores, baseados no termo “Sensing and


Tabela 3.2: Caraterísticas das propostas Sensor-Cloud

Caraterística DescriçãoAnálise A grande integração de dados de sensores, de várias redes de sensores,

os torna atraentes para diversos tipos de análises (e.g., mineração dedados).

Escalabilidade As organizações podem ampliar ou adicionar serviços extras de for-necedores de computação em nuvem sem ter que fazer maiores inves-timentos.

Colaboração A enorme quantidade de dados permite que os usuários e as aplicaçõescompartilhem processos e tarefas.

Visualização Através de ferramentas os usuários podem prever as tendências futurasque têm de ser suportadas pelo sistema.

Provisionamento O fornecimento de uma vasta quantidade de recursos, adequados parao processamento, e o armazenamento de dados para aplicações emlarga escala.

Multitenancy A possibilidade de um serviço responder a inúmeras invocações para-lelamente, para atender a demanda dos usuários/inquilinos.

Automação A diminuição da intervenção humana nos processos, para melhorar otempo de entrega e de resposta.

Flexibilidade A capacidade de responder a grandes solicitações, de diversas aplica-ções, que aleatoriamente podem compartilhar recursos.

Otimização de Re-cursos

O provisionamento de recursos caros, de infraestrutura tecnológica,com menor custo.

Tempo de Resposta O tempo de resposta dos dados de várias redes ou dispositivos permiteque os usuários tomem decisões críticas em tempo quase real.

Actuation as a Service” (SAaaS), propõem um esquema com dois elementos principais, “Cloud”

e “Node”. No elemento “Cloud” se destacam os provedores do SAaaS, os quais devem ter

um componente chamado “Volunteer Cloud Manager”. Este componente está encarregado de

definir e impor estratégias de gestão do sistema, através de uma interação contínua com cada

dispositivo que pertence à nuvem, além da descoberta e indexação de serviços, do gerenciamento

de SLA e de QoS e do Frontend. No elemento “Node” existe um único componente chamado de

"Devices", que representa os sensores e é composto de dois módulos: o primeiro é encarregado

da virtualização dos sensores e o segundo de fazer a ligação entre os sensores virtualizados e o

elemento “Cloud”.

Nesse trabalho, a virtualização é feita principalmente nos nós gateway da(s) RSSF(s),

abstraindo as caraterísticas do hardware dos dispositivos de sensoriamento que a compõem, assim

como as tecnologias e topologia de comunicação usadas entre os sensores, representando-os

como um único dispositivo na nuvem. Para isto, eles implementaram a solução de virtualização

em um framework chamado CLEVERSens, que pode rodar sobre os sistemas operacionais

Contiki ou TinyOS (HADIM; MOHAMED, 2006) (HADIM; MOHAMED, 2006), o qual é


fundamentado em padrões baseados em XML, para a representação de metadados de sensores,

especificação e codificação de dados de sensoriamento, consultas e filtros de dados e dispositivos,

interfaces WS para expor funcionalidades dos sensores, etc.

Por último, eles apresentam um cenário de cidade inteligente como teste, e mostram

alguns resultados de caráter qualitativo, ressaltando as vantagens da proposta, baseados somente

nas vantagens individuais de cada tecnologia, que compõem a proposta, carecendo ainda de uma

avaliação quantitativa do mesmo.

Já em (YURIYAMA; KUSHIDA, 2010) os autores, além de definirem os elementos

que compõem a arquitetura, classificam os usuários a partir dos papéis que eles têm dentro

da infraestrutura Sensor-Cloud. Neste, também foram definidos os fluxos de informação e de

processo entre os elementos, assim como as ações que o sistema deverá fazer caso um fluxo

não cumpra uma regra. Eles adicionam o conceito de grupo de sensores virtuais e estabelecem

uma relação de propriedade entre o usuário e o grupo virtual de sensores que esteja utilizando,

deixando-o com completo poder de ativar ou desativar seus sensores virtuais, definir a frequência

de coleta de dados, e verificar o seu estado. Porém, deixam de lado alguns detalhes muito

importantes, a saber: como é feita a virtualização dos sensores, como padronizar os dados que

são obtidos dos sensores físicos, como provisionar recursos para os grupos virtuais de sensores e

como alterar as configurações dos sensores físicos, se for necessário, dentre outros.

No final, através de uma tabela de pros e contras, eles comparam a infraestrutura Sensor-

Cloud, com o compartilhamento direto dos sensores físicos, chegando a conclusões como uma

arquitetura Sensor-Cloud fornece sensores aos usuários de forma rápida, controlável e fácil. No

entanto, uma arquitetura física de sensores requer que o usuário seja especializado e, embora,

a resposta dos sensores seja mais rápida porque não tem camadas adicionais, o gerenciamento

consome maior tempo.

Uma abordagem similar é apresentada por ARJUN et al. (2015), mas neste caso além

da virtualização no nível de nó (sensores virtuais) os autores também utilizam o conceito de

virtualização no nível de rede (redes overlay), com o objetivo de fornecer a capacidade de

formar dinamicamente grupos de sensores para realizar ou executar tarefas de forma isolada e

transparente entre aplicações. Adicionalmente, apresentam um módulo de gerenciamento de

nuvem de tipo SaaS para gerenciar dados que possam ser utilizados para prever emergências.

Para isto, este modulo fornece mecanismos de armazenamento de dados, backups de dados

e de aplicações, assim como funções de alerta baseadas em uma técnica chamada ID3. Os

autores também mostram uma grande preocupação com a segurança do sistema, e por essa razão

adicionalmente propõem um mecanismo de autenticação baseado em Secure Shell (SSH).

Finalmente, os autores apresentam um experimento onde o objetivo é fazer a extração de

dados ambientais utilizando a sua proposta, para realizar processos estatísticos que permitam

obter informação valiosa e adequada que serva de entrada para o algoritmo ID3 proposto e

assim poder chagar a prever emergências ou desastres. Embora esta abordagem não apresente

uma avaliação da proposta em termos de capacidade ou em termos de tempo de resposta para o


usuário, os autores agregam-lhe valor ao fornecer um algoritmo inteligente para a manipulação e

extração de informação dos dados coletados por sensores de diferentes tipos grandezas físicas.

Por outro lado, em (ZHU et al., 2010), os autores apresentam a implementação de um

protótipo chamado “Gateway IoT”, o qual tem como principais objetivos: realizar o encami-

nhamento de dados entre as RSSFs e as aplicações; transformar os protocolos de comunicação

entre redes, e; fazer o gerenciamento e controle das RSSFs. Além disso, ressaltam que existe a

necessidade de construir um conjunto de instruções e padrões extensíveis para todos os Gateways

IoT, a fim de unificar a funcionalidade de gerenciamento e controle das RSSFs e deles mesmos.

Apresentam a proposta em três camadas, chamadas de Percepção, Transmissão e Aplicação. Na

primeira delas, o objetivo é adquirir, coletar e processar os dados do mundo físico. A camada de

percepção é composta por dispositivos de sensoriamento e as RSSFs em geral. Na segunda, o ob-

jetivo é fazer a transferência dos dados através de longas distâncias, sobre redes de comunicação

tradicionais de banda larga móvel, ou de tecnologias de comunicação Wi-Fi. Na última camada,

o objetivo é fornecer os serviços aos diferentes tipos de usuários, fazendo a correspondência

entre os dados vindos da camada anterior e os requerimentos deles.

Outra implementação é apresentada em (BARBARÁN; DÍAZ; RUBIO, 2014), na qual os

autores defendem que a sua proposta tem uma nova estrutura que simplifica a integração de RSSF

na nuvem, devido a que esta é altamente reconfigurável, fornece mecanismos de auto-gestão e

leva em conta requisitos de tempo real. Eles apresentam um interessante conceito chamado de

"canais virtuais"(Vitual Channels - VC). Estes canais são utilizados para trocar mensagens entre

cada dispositivo real e a seu respetiva representação virtual que é executada na Nuvem. Embora

o conceito de VC não seja uma ideia nova, os autores mostram as vantagens deste conceito, pelo

fato de ser um modelo de coordenação genérico para a programação de aplicações que trabalham

em paralelo ou de forma distribuída que já tem sido aplicado no contexto das RSSFs.

Por fim, os autores apresentam alguns trechos de código com os quais definem o com-

portamento dos VCs e dos componentes de gerenciamento do sistema que permitem realizar a

comunicação entre os dispositivos reais e virtuais. Os autores informam que o trabalho ainda

encontra-se em processo de desenvolvimento e testes da sua proposta e definem que a sua

próxima tarefa é estabelecer qual mecanismo é o mais adequado entre usar um middleware ou

SOA para fornecer as funções do framework como serviços na nuvem.

A WSN-Service Orchestration Architecture (WSN-SOrA) é uma proposta apresentada

por (ASLAM; REA; PESCH, 2012), a qual propõe uma abordagem para orquestrar o provisio-

namento de serviços de sistemas embarcados de rede, e permite às RSSFs atuar como parte da

infraestrutura de nuvem, facilitando o provisionamento sob demanda dos seus serviços. Eles

partem da ideia que as RSSFs podem ser entregues sob o paradigma Network as a Service (NaaS),

o qual corresponde ao domínio do modelo IaaS de nuvem. Os autores argumentam que para que

isto seja possível todos os níveis ou camadas de uma RSSF devem suportar as funcionalidades

associadas ao princípio da SOA e, ao contrário das propostas anteriores utilizam o conceito de

WSN-Cloud, em vez do conceito Sensor-Cloud. Isto significa que para os autores os sensores


devem ser considerados como um outro recurso físico, oferecido no modelo IaaS da computação

na nuvem.

Em seguida, os autores apresentam a arquitetura em três camadas. Na primeira camada

estão os sensores físicos, os quais são virtualizados através de WS, que expõem algumas das suas

funcionalidades (para isto os dispositivos devem suportar IPv6/6LowPAN nas suas interfaces

de rede); na camada intermediária encontram-se os nós gateway, os quais são a ponte entre

a RSSF e os sistemas externos e, a última camada, considerada como a camada principal, é

computacionalmente mais poderosa e, geralmente, roda a plataforma para a implementação de

componentes de gerenciamento do sistema e dos end-points, que são expostos para que outros

usuários ou sistemas entrem em contato com os elementos do domínio da RSSF. Com isso,

para fazer o provisionamento a WSN-SOrA fornece um sistema de automação abrangente para

provisionamento, introduzindo o conceito de orquestração baseada em modelos ou templates,

essa orquestração permite o rápido provisionamento de serviços nos dispositivos das três camadas,

que cumprem com os requisitos do usuário da nuvem.

Por fim, fazem uma avaliação qualitativa da proposta e destacam principalmente dois

pontos. O primeiro é a simplicidade, dado que ao encapsular em modelos ou templates toda a

codificação complexa, elimina-se a necessidade de conhecimento técnico, por parte do usuário

para configurar ou alterar a rede. O segundo ponto é a escalabilidade, porque tem a capacidade de

fornecer um rápido provisionamento de grande escala de redes, com relativa facilidade. Porém,

visto que em outros estudos (DELICATO et al., 2003) (GLOMBITZA; PFISTERER; FISCHER,

2009), tem-se demostrado que os fatores de consumo de energia, largura de banda e/ou memória

aumentam quando se utilizam WS diretamente nos sensores. Uma avaliação qualitativa mostraria

se na realidade a WSN-SOrA poderia ser sustentável em grande escala e sob uma alta demanda

de uso concorrente.

Similarmente, em (RAJESH et al., 2010) os autores propõem integrar os elementos

da sua proposta através de uma arquitetura SOA, onde os nós sensores são catalogados como

prestadores de serviços e os nós gateway são considerados como consumidores. Além desses dois

elementos, eles apresentam um terceiro, chamado de “Controlador de Integração – CI”, o qual é

a porta que permite a comunicação do usuário final com o sistema e vice-versa; encarrega-se de

disponibilizar os dados de sensoriamento na Internet, fazendo uso de tecnologias de nuvem; é

responsável por fornecer a recuperação do sistema caso chegasse a falhar; e também cuida da

autenticação dos usuários, fornecendo as configurações e parâmetros necessários dependendo do

perfil ao qual pertença. Dentro do CI existe adicionalmente um “Agente de Registro”, que fornece

uma visão única de todos os serviços oferecidos pelos sensores ou pelas RSSFs, permitindo e

facilitando a orquestração e agregação dos mesmos.

Embora, na proposta se relatem como caraterísticas do sistema a orquestração de serviços

e o uso de computação em nuvem, não há detalhes nem se especifica como esses elementos

lidam com as necessidades da proposta ou dos usuários, nem como eles são integrados dentro do

CI. Essa lacuna é ainda maior, dado que apesar de apresentar um cenário de testes, carece de


uma avalição qualitativa ou quantitativa, que permita vislumbrar os ganhos ou perdas, ao utilizar

diretamente uma arquitetura SOA em dispositivos com poucos recursos, como são os sensores.

Deixando de lado a arquitetura SOA, em (AHMED; GREGORY, 2011) os autores focam

a sua proposta sobre um middleware do tipo publish/subscribe para fornecer os dados aos

usuários, tal como para armazenar tanto os eventos gerados por eles, quanto os gerados pelos

dados. O processo de consulta começa, por um lado, quando um usuário solicita acesso a um

determinado tipo de dado e o sistema cria uma assinatura, com base neste pedido, e transmite o

evento de inscrição para o middleware; por outro lado, quando os dados são recebidos na nuvem,

vindos das RSSF, são identificados e classificados pela unidade de processamento (Data Process

Unity (DPU)) de dados, para logo após serem publicados. São enviadas também notificações

do evento para a fila de eventos. Cada vez que um novo evento é publicado, cada assinatura é

avaliada pela correspondência de evento e uma vez que o evento encontra uma correspondência

nos dados publicados, este é disponibilizado para o usuário.

Nessa proposta, embora eles definam os fluxos de interação entre os componentes do

sistema e os usuários, existe uma preocupação com a segurança dos dados, além de abordarem a

integração das redes de sensores sem fio com a computação na nuvem, não deixando claro como

é que os componentes principais de sua arquitetura tiram proveito das caraterísticas da nuvem.

Além do mais, não apresentam uma avaliação da proposta mostrando se é vantajoso utilizar esse

tipo de middleware para disponibilizar dados de sensoriamento.

Da mesma forma que na proposta anterior, em (SOLDATOS; SERRANO; HAUSWIRTH,

2012) também é definida uma estrutura de middleware, mas desta vez, como parte de uma in-

fraestrutura de nuvem, que objetiva permitir a formulação e otimização da auto-organização

dinâmica de ambientes de nuvem focados em aplicações IoT. Segundo os autores, essa estrutura

permitirá que os provedores de serviços possam implantar infraestruturas baseadas em nuvem,

que fornecerão serviços da IoT, que respondam às solicitações e requisitos dos usuários finais

apropriadamente. Adicionalmente, determinam que esses tipos de sistemas devam ser autonô-

micos, baseados em computação utilitária (Utility Computing), de código aberto e totalmente

livres, dinâmicos, escaláveis, auto gerenciáveis, baseados em padrões e interoperáveis com outras

arquiteturas IoT. A partir dessas caraterísticas, é estabelecido um passo-a-passo para executar

uma requisição de um serviço IoT no middleware, no qual podem-se ressaltar tarefas como a

seleção de objetos pertinentes, de acordo com os objetivos e as especificações de serviços, a

modelagem da composição de serviços e a configuração automatizada dos objetos conectados à

Internet, que estarão envolvidos na prestação de serviços.

Para validar a sua proposta, os autores avaliam conceitualmente os tópicos apresentados

e a capacidade deles de responder às necessidades intrínsecas de cenários próprios da IoT, como:

E-Science, Manufatura e Cidades Inteligentes.

Na Tabela 3.3 há uma breve descrição do que é proposto pelos autores nos trabalhos

relacionados, além disso, são mostradas as camadas escolhidas para a arquitetura, qual é a sua

principal preocupação ou o que eles consideram mais relevante para ser atingido, se foram


apresentados testes e de que tipo e, por último, se usam middleware e de que forma. Na Tabela

3.4 são mostradas as propostas que se relacionam com conceitos chave na integração de RSSFs

com nuvem como a padronização de dados, a automatização de processos, a orquestração de

serviços, o uso de SOA, a execução de monitoramento, dentre outros.

3.3.A

NÁ

LIS

ED

OS

TR

AB

AL

HO

SR

EL

AC

ION

AD

OS

48

Tabela 3.3: Comparação de caraterísticas dos trabalhos relacionados - Parte 1

Referência Descrição Camadas Foco Testes Middleware Cenários

(MITTON et al.,

2012)

Propõem uma Arquite-

tura que permite adici-

onar novas capacidades

de sensoriamento com

zero configuração, con-

ferindo sistemas com

uma alta reatividade e

alto nível de escalabili-

dade.

Node; Cloud Zero configura-

ções

Não apresentam Usado na nuvem para

compartilhar informa-

ção entre usuários e/ou

serviços.

Smart

Cities.

(SOLDATOS;

SERRANO;

HAUSWIRTH,

2012)

Apresentam uma estru-

tura de middleware, que

visa permitir a auto-

organização dinâmica

de ambientes de nuvem

otimizada para aplica-

ções da IoT.

Mundo fí-

sico; Mundo

virtualizado;

Acesso

Apoiar o de-

senvolvimento

de serviços

IoT sobre

ambientes de

nuvem.

Fazem uma avali-

ação qualitativa

de proposta e a

sua correlação

com diversos

cenários.

Usado para entregar ser-

viços de IoT de forma

dinâmica e de acordo

com um modelo de utili-

dade.

E-Science,

Smart

Cities,

Indústria.

Continua na página seguinte

3.3.A

NÁ

LIS

ED

OS

TR

AB

AL

HO

SR

EL

AC

ION

AD

OS

49

Tabela 3.3 – Continuação da tabela


(LEE et al.,

2010)

Propõem um modelo de

computação adequado

para atender as deman-

das computacionais im-

previsíveis, que são ge-

radas por aplicações de

sensoriamento e monito-

ramento ambiental.

Sensor; Ga-

teway; Nuvem

Balanceamento

de carga na

nuvem

Avaliam a capaci-

dade de resposta

da Amazon EC2

ao fazer balance-

amento de carga,

quando é subme-

tida a cargas dinâ-

micas de dados de

sensoriamento.

Usam um middleware

chamado LooCI, para

fazer a comunicação en-

tre os sensores e os com-

ponentes da arquitetura.

Monitoramento

ambiental.

(GLOMBITZA;

PFISTERER;

FISCHER,

2009)

Apresentam uma abor-

dagem para integrar

RSSF com processos

de negócios utilizando

Business Process

Execution (BPEL) e

WS.

Web Service Aprimoramento

no uso dos

recursos

Medição dos tem-

pos de resposta de

um processo de

negócio genérico.

Não usam devido ao uso

de WS diretamente nos

nós.

Não especi-

ficado.


3.3.A

NÁ

LIS

ED

OS

TR

AB

AL

HO

SR

EL

AC

ION

AD

OS

50



(ARJUN et al.,

2015)

Apresentam uma arqui-

tetura de nuvem baseada

em SaaS que fornece

mecanismos de virtuali-

zação, segurança e com-

partilhamento de dados

através de redes sociais.

Módulo de

RSSF e vir-

tualização;

Módulo de

SaaS; Módulo

de Nuvem

Compartilha-

mento de

RSSF entre

múltiplas apli-

cações usando

os conceitos

de sensores

virtuais e

overlay.

Mostram um pro-

cesso de monito-

ramento de dados

meteorológicos e

como este fornece

alertas de possí-

veis desastres atra-

vés de de redes so-

ciais.

Usam-no, mas não espe-

cificam de qual tipo é,

nem como este é usado.

Monitoramento

ambiental.

(AHMED; GRE-

GORY, 2011)

Apresentam um fra-

mework de integração

RSSF e computação

na nuvem, com o

objetivo de facilitar a

transferência de dados

das RSSFs à nuvem.

Sensor; Contro-

lador; Nuvem

Segurança no

acesso aos da-

dos

Não apresentam Publish/Subscribe

usado para fornecer

os dados aos usuários,

assim como para arma-

zenar os eventos que

geram tanto os usuários,

quanto os dados.

Não especi-

ficado.


3.3.A

NÁ

LIS

ED

OS

TR

AB

AL

HO

SR

EL

AC

ION

AD

OS

51



(ZHU et al.,

2010)


tetura que permite a

comunicação entre as

RSSFs e redes de co-

municação tradicionais

(móvel) ou Internet, e

apresentam o elemento

IoT gateway, como ele-

mento facilitador dessa

integração.

Sensor; Ga-

teway; Pla-

taforma de

gerenciamento.

IoT gateway

como ele-

mento para

lidar com

a heteroge-

neidade que

existe entre

as RSSFs e

as redes mó-

veis/Internet.

Não apresentam Não usam Smart

Home.

(BARBARÁN;

DÍAZ; RUBIO,

2014)


tetura que utiliza um fra-

mework que baseia-se

em canais virtuais para

fazer a comunicação en-

tre os dispositivos de

sensoriamento e a nu-

vem.

Nuvem; Vir-

tualização;

Gateway;

Sensor

Framework

para sim-

plificar a

integração das

RSSF com a

nuvem.

Não apresentam Não usam Trânsito;

Energia

Nuclear


3.3.A

NÁ

LIS

ED

OS

TR

AB

AL

HO

SR

EL

AC

ION

AD

OS

52



(YURIYAMA;

KUSHIDA,

2010)

Propõem uma infraes-

trutura que fornece sen-

sores virtuais, para que

os usuários não preci-

sem se preocupar com

localização ou especifi-

cações dos sensores físi-

cos.

Cliente; Portal

de Provisi-

onamento;

Gerenciamento

de recursos; Mo-

nitoramento;

Virtualização de

grupos de sen-

sores; Sensores

físicos.

Gerenciamento

dos sensores

virtuais

Não apresentam,

no entanto, apor-

tam um quadro

comparativo entre

os prós e con-

tras de usar infra-

estruturas Sensor-

Cloud, ou de aces-

sar diretamente as

infraestruturas fí-

sicas de sensoria-

mento.

Não usam. Serviços de

clima.

(RAJESH et al.,

2010)

Propõem um sistema de

controle para a recupera-

ção e o armazenamento

de dados de sensores in-

dustrias na nuvem.

Sensoriamento;

Controlador;

Nuvem

Heterogeneidade

dos dados

Não apresentam Não usam devido ao uso

de WS diretamente nos

nós.

Aplicações

industriais.


3.3.A

NÁ

LIS

ED

OS

TR

AB

AL

HO

SR

EL

AC

ION

AD

OS

53



(ASLAM; REA;

PESCH, 2012)

Partindo do conceito

de Rede como serviço

NaaS, propõem uma so-

lução para a orquestra-

ção do processo de pro-

visionamento de servi-

ços de RSSF.

Rede; Gateway;

Enterprise

Core;

Virtualização

de sensores no

nível de rede e

orquestração

de serviços.

Comparação do

comportamento

dos sensores com

e sem a proposta,

em aspectos

como retransmis-

são de dados e

quantidade de

usuários, que

podem comparti-

lhar um mesmo

serviço.

Não usam. Não especi-

ficado.

(PIYARE; LEE,

2013)

Apresentam uma abor-

dagem que usa WS

(REST), para a parte da

aplicação e o monitora-

mento remoto.

Sensor; Coorde-

nação; Supervi-

são

Consumo de

bateria

Medem o con-

sumo da bateria

ao enviar mensa-

gens de diferentes

tamanhos, e atra-

vés de simulação

estabelecem o

tempo máximo de

vida da bateria.

Não usam E-Health,

Smart

Home.

3.3.A

NÁ

LIS

ED

OS

TR

AB

AL

HO

SR

EL

AC

ION

AD

OS

54

Tabela 3.4: Comparação de caraterísticas dos trabalhos relacionados - Parte 2

Referência VirtualizaçãoPadronizaçãode dados

Automatizaçãode processos Monitoramento

Modelo deserviço Workflows

Escalabilidade /Elasticidade

Orquestraçãode serviços SOA

(MITTON et al.,2012)

✓ ✓ ✓ ✓ ✓ ✗ ✓ ✗ ✗

(SOLDATOS;SERRANO;HAUSWIRTH,2012)

✓ ✗ ✓ ✗ ✓ ✓ ✓ ✗ ✓

(LEE et al.,2010)

✗ ✗ ✗ ✓ ✗ ✗ ✓ ✗ ✗

(GLOMBITZA;PFISTERER;FISCHER,2009)

✗ ✓ ✓ ✗ ✗ ✓ ✗ ✓ ✓

(ARJUN et al.,2015)

✓ ✗ ✗ ✓ ✓ ✗ ✓ ✗ ✗

(AHMED; GRE-GORY, 2011)

✗ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗

(RAJESH et al.,2010)

✗ ✓ ✗ ✓ ✓ ✗ ✗ ✗ ✓

(ZHU et al.,2010)

✗ ✓ ✓ ✗ ✓ ✗ ✓ ✗ ✗

(BARBARÁN;DÍAZ; RUBIO,2014)

✓ ✗ ✗ ✗ ✓ ✗ ✓ ✗ ✗

(YURIYAMA;KUSHIDA,2010)

✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗

(ASLAM; REA;PESCH, 2012)

✗ ✗ ✓ ✗ ✓ ✓ ✓ ✗ ✓

(PIYARE; LEE,2013)

✗ ✓ ✗ ✓ ✗ ✗ ✗ ✗ ✓



Este capítulo apresentou os principais trabalhos relacionados da integração de RSSFs

com computação na nuvem, além da explicação de dois tópicos correlatos, a virtualização de

sensores e o arcabouço Sensor-Cloud. Diversos trabalhos foram apresentados, onde as suas

principais características foram descritas e comparadas, ressaltando-se as principais diferenças

entre eles.

No final, Seção 3.3, percebe-se que, embora as diversas propostas mencionadas abordem

diversos aspectos da integração de RSSFs com a nuvem, elas só atendem a um subconjunto de

características. Consequentemente, prover uma solução abrangente, que responda a todos os

requisitos apresentados neste capítulo como relevantes, não é trivial e sugere que ainda existem

muitos desafios no processo de construção deste de sistema.

565656

4Arquitetura Proposta

Este capítulo apresenta a arquitetura de alto nível proposta que lida com a integração

das RSSFs com a computação em nuvem. Na primeira seção, todas as camadas da arquitetura

são explicadas, com destaque para funcionalidade e responsabilidade de cada um dos elementos

que a compõem. A Seção 4.2 apresenta a implementação de um testbed baseado na arquitetura

proposta, mostrando o processo de desenvolvimento do mesmo, desde a infraestrutura física,

passando pelo desenvolvimento da plataforma, até chegar ao desenvolvimento do software

baseado no modelo de serviço. Por fim, na Seção 4.3, são apresentados quatro dos fluxos de

informação, onde se relata como os dados trafegam entre os diferentes componentes do sistema

para atingir um objetivo específico (e.g., Coleta de dados). Também serão explicadas algumas

métricas, para realizar a avaliação do desempenho da proposta.

4.1 Arquitetura

A arquitetura proposta baseia-se no paradigma SOC e utiliza os princípios de SOA,

com o intuito de aproveitar as vantagens de usar serviços como elementos fundamentais de

interação e execução das funcionalidades, que colaborativamente visam atender aos requisitos

e às necessidades do gerenciamento eficiente de dados das RSSFs heterogêneas. Portanto, a

arquitetura é definida em quatro camadas: Camada de Aplicação, Camada de Serviços, Camada

de Virtualização e Camada Física. A ideia principal com essas quatro camadas é estabelecer uma

arquitetura modular que proverá suporte a QoS e alta escalabilidade, assim como, uma separação

lógica e funcional entre os componentes que a compõem. Na Figura 4.1 pode-se observar a

arquitetura e suas camadas, assim como, cada elemento será explicado a seguir.

4.1.1 Camada de Aplicação

Nesta camada são definidos os papéis que as aplicações dos usuários podem ter dentro

da arquitetura, e assim a partir deles poder estabelecer permissões, níveis de serviço, responsabi-

lidades e tipo de dados que podem acessar. Nesta camada também são considerados os papéis

herdados das entidades próprias da computação em nuvem.

4.1. ARQUITETURA 57

Figura 4.1: Arquitetura proposta.

� Administradores - são aquelas entidades que cumprem com os papéis de donos e

gerenciadores das infraestruturas físicas das RSSFs e, portanto, gerenciam os dados

que essas redes coletam. Incluem-se também as entidades que gerenciam, monitoram

e fazem manutenção dos recursos e dos serviços envolvidos nas infraestruturas IaaS

e PaaS da nuvem;

� Terceiros - empresas ou organizações que têm o potencial de alugar os serviços

que são prestados pelo sistema, com o intuito de oferecer serviços complementares

aportando um valor agregado funcional;

� Comunidade Científica - organizações de caráter investigativo, que pretendem

acessar dados e as infraestruturas de rede de sensores e de nuvem com objetivos

acadêmicos.

� Visitantes - entidades ou aplicações que estão por fora das caraterísticas dos grupos

anteriores, que pretendem utilizar a informação ou os dados do sistema para responder

necessidades próprias ou de terceiros (exemplo, redes sociais).

4.1. ARQUITETURA 58

4.1.2 Camada de Serviço

Nesta camada encontram-se todos os módulos que agrupam serviços comuns para prestar

as funcionalidades predefinidas na proposta, alguns deles são responsabilidades intrínsecas, por

exemplo, do ESB ou do BPS e, portanto, a implementação dos mesmos reside meramente em

fazer uma configuração apropriada de cada um.

� SLA: Define os níveis e acordos de serviço dependendo do tipo de usuário, definido

na camada anterior;

� Escalonador: é responsabilidade do ESB e é onde se define a programação de

atividades que devem ser realizadas automaticamente, como coleta periódica de

dados, replicação de informação, dentre outros;

� Identificação e Acesso: Estabelece os parâmetros e o processo de acesso ao sistema

para cada um dos tipos de usuários cadastrados no sistema;

� Registro de serviços: Permite cadastrar ou apagar serviços no sistema;

� Composição de Serviços: Permite a criação de serviços compostos a partir de

serviços básicos de sensoriamento, armazenamento e processamento de dados;

� Monitoramento: Define e gerencia os parâmetros de monitoramento de todos os

serviços cadastrados no sistema. Este processo também pode ser feito por cada um

dos módulos, visando ter uma visão de comportamento por componente;

� Distribuição/Localização: Contém o algoritmo que define onde vão ser armazena-

dos determinados dados, os quais podem ser caraterizados e organizados a partir da

sua informação de origem, de suas propriedades, dentre outros. Neste caso, o pro-

cesso de decisão está encarregado somente de avaliar se o serviço de armazenamento

está executando corretamente;

� Descoberta: Permite aos usuários ou aos módulos do sistema encontrar serviços, a

partir de parâmetros ou necessidades próprias;

� Publicação: Disponibiliza os serviços cadastrados, para que possam ser acessados

pelos outros módulos e usuários do sistema;

� Armazenamento de dados: Contém as instruções para levar a cabo o armazena-

mento dos dados, a partir das instruções recebidas do módulo “Distribuição/Localização”;

� Processamento de dados: Encarrega-se de receber, formatar, agregar, etc., os dados

provenientes das RSSFs. Neste caso, esta tarefa é responsabilidade do ESB, o qual

possui as ferramentas para levar a cabo as funções anteriormente citadas;

4.2. IMPLEMENTAÇÃO DA PROPOSTA 59

� Alocação de recursos: Contém algoritmos para determinar se as solicitações aos

serviços podem ser respondidas, ou se elas têm de ser rejeitadas por falta, ou ocupação

de recursos físicos ou virtuais. Este módulo é responsabilidade direta de cada

uma das aplicações de gerenciamento das infraestruturas de nuvem, porém, elas

habilitam a possibilidade de serem programadas para fazer reconfiguração dinâmica

dos parâmetros de execução, o que afinal, apresenta um desafio na hora de estabelecer

parâmetros de QoS fim-a-fim;

� Mensagens: Contém as funcionalidades e os componentes para poder fazer a comu-

nicação entre módulos, entre módulos e serviços, bem como entre serviços. Para a

comunicação entre os serviços de redes e os usuários finais é usado um MOM, e para

a comunicação entre componentes é usado um ESB.

4.1.3 Camada de Virtualização

Nesta camada se agrupam as representações lógicas dos recursos de sensoriamento,

processamento, rede, memória e armazenamento.

� Virtual RSSF: Representa a possibilidade de gerar representações lógicas de sensores

ou de grupos de sensores, dependendo das necessidades dos usuários, partindo da

disponibilidade e estado dos recursos físicos, com que dispõem as RSSFs;

� Nuvem Privada: Na Nuvem privada o objetivo é fornecer os componentes de

armazenamento dos dados coletados;

� Nuvem Híbrida: Na nuvem híbrida o objetivo é manter a possibilidade de replicação

dos dados coletados, assim como aproveitar as capacidades de processamento tanto

de nuvens privadas, quanto de nuvens públicas.

4.1.4 Camada Física

Nesta camada encontram-se todos os dispositivos físicos ou reais que fornecem e supor-

tam as funcionalidades de sensoriamento, processamento e armazenamento.

4.2 Implementação da proposta

Para a implementação, o cenário base é um sistema de monitoramento ambiental (Fi-

gura 4.2), que obtém dados de fenômenos como: temperatura, CO2, luminosidade, etc., no

qual os sensores comunicam-se através de serviços, ou interfaces oferecidas por um middleware

embutido em cada um dos dispositivos de sensoriamento, que por sua vez possui os algoritmos,

ou protocolos de encaminhamento dos dados coletados para o gateway da rede. O gateway é


um dispositivo com maior poder computacional, que comumente oferece a possibilidade de

ser acessado e reprogramado mais facilmente, do que os dispositivos de sensoriamento. Ele

está encarregado de fazer o processamento prévio dos dados (e.g., agregação, criptografia,

etc.), para logo repassá-los a um dispositivo (Service Provider) encarregado de armazená-los e

disponibilizá-los para os usuários finais através de, por exemplo, serviços Web.

Figura 4.2: Cenário – Monitoramento ambiental (Luminosidade, CO2, temperatura)

Como o objetivo desta proposta é lidar com várias das limitações que possuem os sistemas

de sensoriamento baseados no cenário descrito (ora discutidos no Capítulo 3), o dispositivo

“Service provider” é substituído por um arcabouço de nuvem, que oferece uma infraestrutura

como serviço gerenciada com Openstack. Para a instalação do Openstack utilizou-se a versão

Icehouse, que foi instalada e configurada como recomendado no manual fornecido no site

"OpenStack Installation Guide for Ubuntu 12.04/14.04 (LTS)", em várias máquinas rodando o

SO Ubuntu 14.04(LTS). Neste manual, a configuração base é estabelecida a partir de três tipos

de nós: um nó controlador, um nó de rede e um nó de computação, este último podendo ser

replicado tantas vezes quantas forem necessárias; neste caso, foram configuradas três máquinas

deste tipo (Figura 4.3).

Na Tabela 4.1, encontram-se as especificações das máquinas utilizadas para a criação da

IaaS, assim como os módulos ou serviços, próprios do Openstack, instalados em cada uma delas

(A explicação de cada um desses módulos encontra-se no site “Openstack – Architecture”1).

A implementação do background da arquitetura foi realizada em um framework chamado

WSO2©, o qual proporciona toda uma plataforma de middleware, para desenvolver soluções SOA

1http://docs.openstack.org/icehouse/install-guide/install/apt/content/ch_

overview.html




Figura 4.3: IaaS – Openstack

na nuvem. Para suportar os serviços oferecidos pela proposta dessa plataforma usam-se quatro

produtos, são eles: o WSO2 Application Server (AS), o WSO2 Business Process Server (BPS),

o WSO2 Data Service Server (DSS) e o WSO2 Enterprise Service Bus (ESB). Adicionalmente,

foram utilizados: um Message Broker JMS chamado ActiveMQ, da Apache Software Foundation

e um banco de dados MySQL, para desenvolver e suportar o componente de virtualização dos

sensores e para fazer o armazenamento dos dados, respetivamente. Cada uma dessas ferramentas

disponibiliza interfaces de gerenciamento e monitoramento, que permitem estabelecer parâmetros

de QoS e segurança, assim como realizar o rastreamento do comportamento da mesma e dos

serviços, que estejam publicados ou oferecidos nelas.

Na Figura 4.4 mostra-se cada um dos servidores anteriormente descritos, representados

como componentes e no canto superior esquerdo de cada um deles, na cor marrom podem ser

observadas as portas de administração, e na cor preta a porta pela qual os serviços são publicados.

Dentro de cada componente mostram-se os nomes dos arquivos WSDL, que definem como

acessar os serviços oferecidos por cada módulo ou servidor. As setas vermelhas mostram como

eles se comunicam entre si e como consomem os serviços dos outros através de protocolos

como HTTP, SOAP ou JMS. O componente do ActiveMQ tem os nomes das possíveis filas, que

representarão cada um dos sensores, ou redes de sensores designadas a cada cliente ou usuário.

Consequentemente, a implementação do software para dar suporte à proposta foi feita

desenvolvendo os serviços e a lógica do negócio, como descrito a seguir. A virtualização dos

dados dos sensores é realizada através do conceito de fila do MOM, utilizando a API JMS.

Basicamente, para cada requisição feita por um usuário dos dados de um determinado sensor,


Tabela 4.1: Servidores IaaS

Máquina ProcessadorMemória

RAM Armazenamento Módulos instalados

ControllerProcessadorIntel® Xeon®E5-2609

8 GB 520 GB

RabbitMQ; Keystone;Glance; Nova manage-ment; Neutron server;ML2-plugin; Horizon;Heat; Ceilometer core

NetworkProcessadorIntel® Xeon®E5-2609

2 GB 520 GB

ML2-plugin; Agenteda Camada 2(OpenvSwitch – OVS);Agente da Camada 3;Agente DHCP

Compute(1-3)

ProcessadorIntel® Xeon®E5-2609

16 GB 1 TB

Nova Hypervisor;KVM ou QEMU;ML2-Plugin; Agente daCamada 2(OVS)

ou rede de sensores, se criará uma fila para esse usuário, que manterá os dados requisitados

(réplica dos originais), até ele finalmente consumi-los; isto permite o desacoplamento temporal

do usuário com o sistema, além de dar ao usuário a sensação de possuir controle total sobre os

mesmos. Paralelamente, haverá uma fila de gerenciamento, na qual chegarão todos os dados de

todos os sensores ou redes de sensores, e da qual o sistema os coletará para armazená-los no(s)

banco(s) de dados.

As filas serão preenchidas pelos nós com o perfil de gateway, o qual está encarregado

de receber os dados coletados (agregados) da rede de sensores. Esse nó também se encarregará

de criar as filas dentro do middleware, se elas não existirem, assim como, enfileirar os dados

adequadamente em cada fila. Dado que esse middleware JMS também conta com o modelo

publish/subscribe, surge a possibilidade de criar tópicos de gerenciamento para os sensores, nos

quais o objetivo é publicar as instruções de reconfiguração para cada sensor físico. Assim, cada

sensor ou rede pode se subscrever no tópico relacionado a seu próprio gerenciamento e, portanto,

receber a instrução no momento que ela aparecer.

Os serviços de armazenamento e consulta nos bancos de dados são de responsabilidade

do DSS, o qual permite expor interfaces tipo WS com as operações para o gerenciamento dos

dados nos bancos de dados. Isto possibilita que sem importar o SGBD, sejam utilizadas as

interfaces padronizadas e o servidor seja o encarregado de fazer as conversões entre tipos de

dados e entre funções. Dado que esses serviços não dependem do servidor de aplicações, nem

dos outros servidores, surge a possibilidade de serem alcançados por outras vias, se necessário,

externamente.


Figura 4.4: Diagrama de componentes

No AS se programam os serviços, para acessar os dados nas filas geradas no middleware

JMS. Nesses serviços e em outros existirá a possibilidade de adicionar algoritmos, por exemplo:

baseados em inteligência computacional, encarregados de determinar dinamicamente a locali-

zação dos dados, além de decidir se é necessário fazer replicação destes, buscando melhorar a

tolerância a falhas e minimizando a distância entre os dados armazenados e os usuários finais.

Adicionalmente, este servidor contém os mecanismos que suportam a criação de interfaces

gráficas de usuário (GUI) via Web, utilizando a linguagem de programação Java, para acessar,

apresentar, gerenciar, etc., os dados gerados pelas RSSFs.

No servidor de orquestração de serviços (BPS) foi criado o serviço de armazenamento

que é executado periodicamente, o qual é um serviço composto, que inclui o fluxo de dados entre

os serviços de acesso às filas e os serviços de armazenamento no banco de dados. Este servidor

fica encarregado de gerar e executar serviços, que sejam composições ou combinações entre

serviços próprios do sistema, ou serviços externos a ele. De maneira suplementar, também será

possível que os desenvolvedores de aplicações para as RSSFs orquestrem serviços, de tal forma

que possam responder a requisições de dados, para qualquer combinação definida pelo usuário

final.

No ESB todos aqueles serviços básicos de consulta, armazenamento, inteligência, repli-

cação, etc., criados e disponibilizados nos outros servidores, foram registrados como endpoints

e disponibilizados, através de Service Proxys, que permitem monitorar, transformar e rotear as

mensagens recebidas e encaminhadas por cada um deles. Da mesma forma é possível monitorar a

execução e o comportamento de cada serviço individualmente, através das ferramentas fornecidas

diretamente pelo servidor. Dado que os serviços são registrados como Endpoints, dentro do

ESB eles poderão ser acessados por um identificador único, o que permite que a localização e

implementação do serviço seja transparente para o usuário e, se for preciso, no sistema serviço


ou suas regras de execução podem ser trocadas sem afetar diretamente o usuário, desde que o

identificador do endpoint seja mantido o mesmo.

Para responder à caraterística de automação, aproveita-se a capacidade fornecida pelo

ESB, para sincronizar ou agendar a execução de tarefas ou serviços. Assim, o serviço de

armazenamento provido pelo Business Process Server (BPS) é executado automaticamente como

uma tarefa programada, sendo invocado com uma periodicidade que dependerá da carga de dados

no sistema. Esta tarefa será replicada para prover escalabilidade no processo de coleta, para lidar

com maiores quantidades de dados coletados de uma ampla variedade de RSSFs.

Como pode-se observar na Figura 4.5 todo o framework da WSO2 e fornecido por uma

infraestrutura de computação na nuvem do tipo PaaS, chamada Apache Stratos, que roda sobre a

infraestrutura de nuvem do tipo IaaS gerenciada com OpenStack. A plataforma Apache Stratos

habilita cada um dos servidores em máquinas virtuais diferentes, para assim responder com os

recursos de software e hardware adequados, que suportem as necessidades das aplicações, dos

usuários, dos desenvolvedores, e dos administradores do sistema. Dado o caso de que os serviços,

os usuários ou os requerimentos mudem com o tempo, este tipo de infraestrutura permitirá alterar

dinamicamente os recursos alocados, dependendo das novas necessidades.

Figura 4.5: Infraestrutura da implementação da proposta

O resultado de todo o arcabouço anterior será um conjunto de serviços Web, que dispo-

4.3. FLUXOS DE INFORMAÇÃO 65

nibilizará as funções que permitirão registrar e consultar dados de sensoriamento, assim como

funções de gerenciamento das redes ou dos sensores registrados. Como as interfaces estão bem

definidas sobe padrões WS* com tipos de dados, ou tipos de estruturas baseadas em tipos de

dados primitivos, o sistema responderá ao principal desafio desse tipo de ferramenta, isto é, a

interoperabilidade.

4.3 Fluxos de informação

Nesta seção encontram-se vários diagramas de sequência que mostram a relação entre os

componentes de sensoriamento com os componentes da plataforma como serviço, assim como, os

principais fluxos de informação e as medições realizadas na arquitetura proposta. Cada processo

está representado com uma cor nas setas de comunicação: a cor laranja representa o processo de

coleta de dados e disponibilização dos mesmos no MOM e a cor verde representa o processo de

armazenamento dos dados coletados no banco de dados. A numeração estabelece o passo-a-passo

de cada processo. Para todos os próximos casos, o “Usuário” representa uma ou várias aplicações

desenvolvidas, para acessar os serviços com as informações obtidas previamente.

4.3.1 Fluxo-Recepção

Recepção de dados (seta laranja na 4.6). Esse processo é periódico e é executado

dependendo das configurações dos tempos de coleta nos sensores ou nas RSSFs. A seguir será

apresentada a sequência do fluxo-recepção:

1. O (s) sensor (es) encaminha (m) os dados coletados periodicamente para o gateway

da RSSF. Neste projeto, os dados de sensoriamento serão gerados aleatoriamente no

tempo e, cada vez que se gerar um dado, a ele será adicionada a data com a hora exata

da medição. O gateway fica rodando continuamente à espera dos dados enviados

pelos sensores. Dentro deste dispositivo um tempo é gasto no processamento dos

dados (agregação, criptografia, etc.);

2. O nó gateway encaminha os dados processados para o ESB, através de uma interface.

Assim, o gateway deve ser programado, para que encaminhe os dados processados

para a interface Web Service (SOAP, REST), ou JMS apropriada no ESB;

3. O ESB recebe os dados e os encaminha imediatamente, para uma fila no MOM que

está encarregada de receber todos os dados coletados. O MOM adicionará aos dados

da medição, a data e hora de entrada na fila. Este passo se faz necessário, porque

permite manter os dados ativos, caso seja preciso realizar processamento adicional

(e.g., adicionar as medições a outras filas de gerenciamento, ou de usuários inscritos

para receber determinados dados).


4.3.2 Fluxo-Coleta

Coleta e armazenamento de dados (seta verde na Figura 4.6). Paralelamente no ESB roda

uma tarefa programada, encarregada de chamar o processo que adquire os dados da fila geral do

MOM e os armazena no banco de dados. A seguir será apresentada a sequência do fluxo-coleta:

1. A tarefa programada é ativada periodicamente e se encarrega de chamar um WS no

BPS, o qual é uma composição de serviços e tem o fluxo que permite obter os dados

do MOM, para armazená-los em um banco de dados;

2. Quando a composição é ativada, manda uma mensagem para o MOM, para que ele

devolva o primeiro elemento, ou dado coletado que esteja na fila;

3. O MOM responderá com uma medição, ou com uma mensagem nula se não tiver

dados. Para o primeiro caso, à medição serão adicionadas data e hora, de sua retirada

da fila;

4. A composição avaliará se o dado recebido é diferente de nulo. Se for nulo, o processo

devolverá uma mensagem vazia para o BPS, caso contrário, chamará o Web Service,

no DSS encarregado de ingressar os dados no banco de dados;

5. O Web Service no DSS recebe os dados e executa um procedimento no banco de dados,

para fazer a inserção dos mesmos. No exato momento em que o banco de dados faz a

inserção da medição, na tabela correspondente, um gatilho adicionará o valor de data

e hora no campo da inserção da medição. Se tiver sucesso o procedimento responderá

com uma mensagem de “OK” para o BPS, ou com uma mensagem de erro;

6. Finalmente, a composição no BPS responderá com uma mensagem, para o ESB que

mostrará se todo o processo foi feito satisfatoriamente, ou se ocorreu algum erro.

4.3.3 Fluxo-Registro

Registro de usuário para obter dados dos sensores (seta verde na Figura 4.7). A seguir

será apresentado a sequência do fluxo-registro:

1. O usuário se autentica no sistema e entra no portal da aplicação;

2. A aplicação mostra todos os sensores pertencentes ao sistema, tanto os ativos como

os que estão inoperantes ou desligados no momento. Isto é importante porque embora

o sensor não esteja ligado, o sistema permite acessar os dados das medições salvos

no banco de dados, assim como do histórico do sensor;

3. O usuário seleciona os sensores, dos quais quer receber informações e pede para a

aplicação fazer o registro de sua solicitação;


Figura 4.6: Diagrama de fluxo recepção/coleta

4. A aplicação, através de uma interface Web Service, se comunica com o ESB, este

último disponibiliza a interface sob diferentes protocolos de transporte e com mensa-

gens de resposta em formato XML ou JSON;

5. O ESB liga a comunicação entre a aplicação e o BPS, no qual existe uma composição

de serviços, encarregada de criar o cadastro do usuário para receber os dados de um

determinado sensor. O BPS começa o fluxo para criar a subscrição;

6. O BPS verifica se existe uma subscrição previa desse usuário, para esse determinado

sensor. Caso a encontre ele adiciona o identificador do sensor virtual à mensagem de

resposta do BPS para o ESB e pula o processo para o passo 8. Caso contrário, faz o

processo de criação da fila, ou do tópico que vai representar o sensor (sensor virtual)

e associa qualquer desses dois ao usuário como dono ou administrador daquele sensor

virtual;

7. O MOM responde para o BPS com o Identificador do sensor virtual;

8. O BPS através de uma interface Web Service, disponibilizada no DSS, verifica se

existem dados históricos desse determinado sensor;

9. Se existir, ele retorna uma mensagem com a URL de um Web Service autorizado para

consultar os dados, e caso contrário responde com uma mensagem vazia;

10. O BPS responde para o ESB com uma mensagem composta das informações obtidas

nos passos 7 e 9;

11. O ESB formata a mensagem recebida do BPS, de forma que seja adequada aos

protocolos de comunicação e às necessidades do usuário:


12. A aplicação fornece ao usuário a mensagem obtida no processo, de uma forma legível

e entendível para ele.

4.3.4 Fluxo-Consulta

Este fluxo (seta laranja na Figura 4.7) depende do fluxo descrito na 4.3.2, dado que ao

executá-lo no sistema, são criados todos os elementos que vão fornecer as informações que

usuário cadastrou para receber. A seguir será apresentada a sequência do fluxo-consulta:

1. O usuário com a informação e as indicações, recebidas do fluxo anterior, pode acessar

os serviços que lhe permitiram obter os dados das medições dos sensores subscritos

anteriormente. Assim, através de um Web Service, fornecido pelo ESB, poderá

acessar as mensagens do sensor virtual, criado no MOM, passando como parâmetro

o identificador do sensor virtual;

2. O ESB, com o identificador do sensor virtual, se comunica com o MOM para começar

a receber os dados nele armazenados;

3. Em paralelo o ESB se comunica com o DSS, através da URL obtida no fluxo anterior,

para consultar os dados do histórico desse sensor virtual;

4. A resposta do MOM com os dados obtidos é repassada para o ESB, e este processo

começa a ser repetido periodicamente, dependendo das configurações definidas pelo

usuário na hora da subscrição;

5. O DSS responde para o ESB, com o aglomerado dos dados históricos do sensor

virtual;

6. O ESB começa a responder para o usuário com as informações que continuamente

está recebendo do MOM e do DSS. Até o usuário parar o processo.


Este capítulo apresentou os principais detalhes sobre a arquitetura proposta, assim como

os de sua implementação. No início do capítulo, a arquitetura foi descrita elemento por elemento,

com o intuito de serem mostradas as funcionalidades e responsabilidades de cada módulo. Em

seguida, foi descrita a implementação da proposta, explicando o processo de desenvolvimento da

IaaS, da PaaS, assim como do software baseado no modelo de serviço, que suporta as aplicações

de RSSF em ambientes de nuvem. Por fim, foram apresentados quatro fluxos de informação e a

sua relação com cada um dos componentes da plataforma. O Capítulo 5, a seguir, abordará a

avaliação experimental. Os fluxos descritos neste capítulo nortearão a definição de métricas de

avaliação de desempenho da proposta.


Figura 4.7: Diagrama de fluxo registro/consulta

707070

5Avaliação Experimental

O objetivo desta avaliação é caracterizar o comportamento da implementação, baseada

na arquitetura proposta, avaliando a sua capacidade de resposta, considerando diferentes cargas

de dados (Seção 4.3.1) e configurações de coleta (4.3.2).

5.1 Métricas

As métricas para determinar o comportamento da proposta são:

� “Atraso de Coleta” – A diferença entre a data e hora de coleta da grandeza física,

com a data e hora de entrada da mesma na fila, corresponderá ao atraso de coleta

gerado pelo tráfego do dado coletado através das diferentes redes (RSSF, Internet e a

rede interna do OpenStack) até chegar na fila de processamento (Figura 4.6);

� “Tempo de Enfileiramento” – A diferença entre a data e hora de entrada do dado

coletado na fila, com a da saída do mesmo da fila permitirá medir o tempo de

enfileiramento dos dados coletados (Figura 4.7);

� “Tempo de Processamento” – A diferença entre a data e hora de saída do dado

coletado da fila e a data de inserção do mesmo no banco de dados permitirá medir o

tempo de processamento e de tráfego dos dados através dos componentes ESB, BPS

e MOM (Figura 4.7);

� “Atraso fim-a-fim” – A diferença entre a data e hora de criação da medição e da

data e hora de armazenamento da mesma, permitirá medir a totalidade do tempo

adicional que os elementos da arquitetura proposta adicionam à mensagem, o que

pode ser tomado também, como o atraso que tem o sistema para disponibilizar o

dado para o usuário final (Figura 4.7).

Nesta seção a nomenclatura utilizada para referir-se às métricas definidas anteriormente

será:

5.2. VARIÁVEIS 71

� Atraso fim-a-fim: aFF

� Atraso de Coleta: aC

� Tempo de Enfileiramento: tE

� Tempo de Processamento: tP

5.2 Variáveis

As variáveis que foram usadas são:

� Fornecedores (F): Quantidade de RSSFs simuladas que geram dados para alimentar

o sistema;

� Intervalo de geração de dados (I): Intervalo de tempo que define a frequência com a

qual os dados poderão ser criados aleatoriamente por um fornecedor. Quanto menor

o intervalo, com maior rapidez serão gerados os dados;

� Tarefas programadas de coleta automática de dados (S): Quantidade de tarefas pro-

gramadas, para fazer a coleta automatizada de dados. Cada tarefa pode ser executada

no mínimo a cada segundo.

5.3 Procedimento de medição

Cada experimento foi executado durante um tempo T de 1800s, sendo que os dados ou

medições foram gerados variando tanto a quantidade de tarefas de coleta, quanto a quantidade de

fornecedores, assim como os intervalos de geração de dados.

Como definido na Tabela 5.1, o primeiro cenário corresponde a fixar o número de tarefas

(S = 2) e a variar F e I dentro dos elementos do conjunto resultado de F x I, que é composto por

18 elementos.

Os outros dois cenários têm uma configuração similar, fixando o valor de S em 4, para

o cenário B, e em 8, para o cenário C, porém os valores de F são o duplo e o quádruplo,

respetivamente, dos valores utilizados no cenário A, completando um total de 56 experimentos.

Tabela 5.1: Cenários.

Cenário F IA: S = 2 5,10,15 [1,10],[1,9],[1,8],[1,7][1,6],[1,5]B: S = 4 10,20,30 [1,10],[1,9],[1,8],[1,7][1,6],[1,5]C: S = 8 20,40,60 [1,10],[1,9],[1,8],[1,7][1,6],[1,5]

5.4. RESULTADOS 72

Assim, por exemplo, dentro do cenário A o sistema foi configurado para rodar duas

tarefas de coleta de dados (S = 2) e o primeiro experimento foi feito com F = 5 e I = [1,10] pelo

tempo T definido na seção Experimentos (1800s). O segundo foi feito com F = 5 e I = [1,9], e

assim por diante, até chegar ao último experimento desta configuração com F = 15 e I = [1,5].

A partir deste ponto, para facilitar a leitura, será utilizada a seguinte nomenclatura para

se fazer referência a cada experimento: Experimento (S,F,I), ou simplesmente (S,F,I). Assim,

(2,5,[1,10]) refere-se ao experimento feito com duas tarefas de coleta, 5 fornecedores e com um

intervalo de geração aleatória de dados entre 1s e 10s.

Ao término de cada experimento, as 4 métricas foram extraídas do banco de dados, onde

a unidade de medida é o segundo (s), com uma precisão de 6 casas decimais, como pode se

observar na Tabela 5.2 com um trecho das medições.

Tabela 5.2: Trecho de medições das métricas

aFF tE tT tP

... ... ... ...0,860849 0,000002 0 0,8608470,104726 0,000001 0 0,1047250,825268 0,000002 1E-06 0,8252650,918293 0,000002 0 0,9182910,660968 0,000001 1E-06 0,6609661,04476 0,999388 0 0,0453681,04651 0,999368 1E-06 0,0471371,04706 0,999125 0 0,0479360,214088 0,000001 1E-06 0,2140861,07913 0,999056 0 0,0800710,384 0,000002 0 0,383998

0,827972 0,000002 0 0,827970,971784 0,000001 1E-06 0,9717821,05173 0,999831 0 0,0519011,0511 0,999172 0 0,051931

1,03556 0,000002 0 1,03556... ... ... ...

5.4 Resultados

Os resultados são agrupados por cenário, mostrando informações tanto das métricas,

quanto dos dados que não conseguiram ser atendidos no intervalo de tempo T. A percentagem

desses dados não atendidos, em relação ao total de dados gerados pelos fornecedores (F) no

mesmo período T, é chamada de taxa de descarte. Devido ao fato da métrica aFF corresponder à

soma dos valores das outras três métricas (equação☛✡

✟✠5.1 ), e também por determinar o tempo no

5.4. RESULTADOS 73

qual o dado, ou a medição se encontrará disponível no sistema, tal métrica foi escolhida para

efetuar a análise dos resultados dos experimentos.

aFF = aC+ tE + tP☛✡

✟✠5.1

A primeira informação mostrada está numa tabela que contém a quantidade de medições,

que não foram atendidas no período de tempo T em cada experimento, seguidamente há uma

tabela similar, mas com os valores dos tempos médios de vida das medições. Nessas duas tabelas

encontram-se ressaltados vários campos, que indicam que o sistema não poderá responder ade-

quadamente sob a configuração respetiva. Além dessas tabelas, são apresentados três diagramas

de caixa, nos quais pode se visualizar a distribuição dos dados y, sua variação dependendo da

variável Intervalo (I).

É importante ressaltar, que no processo de coleta automático foi percebido, que devido

às limitações próprias do ESB, uma tarefa programada pode ter no mínimo uma periodicidade de

1s, pelo qual ela só conseguiria atender no máximo a 3600 dados coletados em uma hora. Como

explicado na Seção 4.2, para lidar com está limitação de capacidade de atendimento a cargas

com taxas superiores, as tarefas podem ser replicadas tantas vezes quanto for necessário, assim

para este caso a tarefa foi replicada duas (Cenário A), quatro (Cenário B) e oito vezes (Cenário

C).

5.4.1 Cenário A

Na Tabela 5.3 foram ressaltados em negrito aqueles experimentos que geraram taxas de

descarte, dado que as duas tarefas de coleta automatizada de dados não conseguiram processar

todos os dados, que foram gerados pelos fornecedores. Aqueles experimentos com F = 5 e F

= 10, que tiveram sua taxa de descarte em zero mantiveram as médias dos tempos de vida na

faixa dos 0,60s até 0,65s (Tabela 5.4). No entanto, quando nos experimentos (2,15,[1,10]) e

(2,15,[1,15]) não houve taxa de descarte, porque todos os dados conseguiram ser recuperados,

processados e armazenados, porém os tempos médios de atraso fim-a-fim ultrapassaram os 3

minutos.

Tabela 5.3: Taxa de descarte de dados, S = 2

. IF 10 9 8 7 6 55 0,00% 0,00% 0,00% 0,00% 0,00% 0,00%10 0,00% 0,00% 6,93% 29,53% 50,58% 67,06%15 0,00% 0,00% 12,68% 31,89% 50,54% 71,83%

Para este caso, dado que o administrador do sistema o configure com só duas tarefas,

terá a possibilidade de aceitar de zero a 5 clientes, que se caracterizem por gerar dados com uma

5.4. RESULTADOS 74

Tabela 5.4: Tempo médio do aFF, S = 2

tV IF 10 9 8 7 6 55 0,6030 0,6220 0,6382 0,6346 0,6373 0,6472

10 0,6539 0,6382 32,4127 130,3628 180,8520 233,617215 178,5410 218,4419 252,8496 292,1365 328,4652 352,0893

periodicidade de 1s, até uma periodicidade de 10s, sem ter perdas no processamento. Ademais,

poderá atender de zero a 15 clientes, mas eles só poderão gerar medições com uma periodicidade

entre 10s e 9s no máximo, o que na realidade permitiria responder às necessidades de diversas

aplicações, que não sejam consideradas como de alto risco, e.g., aplicações ambientais, por isso

o usuário não vai ser afetado se os dados chegarem com maiores atrasos.

Na Figura 5.1 pode-se observar como os experimentos deste cenário mantêm um compor-

tamento similar, na dispersão dos dados até o terceiro quartil, sem importar quão rápido sejam

gerados os dados. Isto mostra que a implementação configurada, sob os parâmetros estabelecidos

no experimento, é escalável quando aumentar a periodicidade de geração dos dados em cada

uma das fontes. Do terceiro quartil até o máximo, o restante dos dados teve tempos de vida

superiores a 1s, chegando à faixa dos 4s.

Figura 5.1: Diagrama de caixa (2,5,*).

Na Figura 5.2 percebe-se que a partir do experimento (2,10,[1,8]) os tempos de vida

começam a aumentar e a se espalhar exponencialmente, devido ao fato das duas tarefas não

conseguirem atender o volume de dados gerado. Assim, a mediana e valor máximo de aFF

aumentam a valores que ultrapassam o minuto e meio. Isto significa que a configuração deste

experimento não deve ser utilizada.

Na Figura 5.3 pode-se perceber, que embora o sistema não consiga lidar com um volume

de dados gerado por 15 fontes, o espalhamento do tempo de vida deles aumenta gradualmente,

até alcançar tempos de vida superiores aos 2 min, chegando a obter valores ao redor dos 20 min.

O que mostra que, devido a esse comportamento dos tempos de atraso fim-a-fim, eles poderiam

ser simulados com uma função exponencial, própria dos sistemas que utilizam enfileiramento.

5.4. RESULTADOS 75



5.4.2 Cenário B

Nesse cenário, no qual foram configuradas quatro tarefas de coleta automatizada, pode-se

observar que essas quatro tarefas podem lidar com 10 fontes de dados que gerem suas medições

no máximo a cada 5s, para não gerar taxas de descarte (Tabela 5.5), obtendo tempos médios de

atraso fim-a-fim próximos ao segundo (Tabela 5.6).


. IF 10 9 8 7 6 510 0,00% 0,00% 0,00% 0,00% 0,00% 0,00%20 0,00% 0,00% 4,17% 18,68% 33,81% 53,65%30 31,31% 40,22% 57,13% 75,03% 93,16% 123,12%

Como observado na Figura 5.4, 75% dos dados gerados nos 6 experimentos se mantêm

abaixo de 1,05s, evidenciando que o sistema tem um comportamento majoritariamente estável,

conseguindo processar os diferentes volumes de dados sem gerar taxas de descarte.

A distribuição dos dados na configuração com S = 4 e F = 20 tem um comportamento

5.4. RESULTADOS 76


tV IF 10 9 8 7 6 510 0,8632 0,8076 0,9699 0,8330 0,8592 0,933720 1,1556 1,8893 55,8626 127,9918 192,3417 248,451130 176,2268 215,4888 244,0378 286,5050 313,0651 357,2638


similar ao da configuração com S = 2 e F = 10, no qual o sistema só consegue atender todos os

dados gerados mediante os intervalos I = [1,10] e I = [1,9] (Figura 5.5).


Como esperado, as quatro tarefas não conseguiram processar todos os dados gerados

através dos diferentes intervalos, isto mostra que duplicar o número de fornecedores, ou fontes

de dados, não é o bastante para duplicar as tarefas de coleta automatizada e atender os dados

gerados por eles (Figura 5.6). Assim, fica aberto o caminho para estudos futuros, que avaliem a

proporção de tarefas de coleta em relação a quantidade de fornecedores.

5.4. RESULTADOS 77


5.4.3 Cenário C

Para o caso em que foram quadruplicadas as configurações inicias do sistema, pode-se

observar que oito tarefas de coleta de dados só conseguem processar dados de 20 fornecedores,

sem gerar taxas de descarte. Embora alguns valores médios do aFF estejam próximos a 1,5s

(Experimentos (8,40,[1,10]) e (8,40,[1,9])) (Tabela 5.8), nestes foram descartadas mais que 40%

das medições geradas (Tabela 5.7).


. IF 10 9 8 7 6 520 0,00% 0,00% 0,00% 0,00% 0,00% 0,00%40 41,47% 41,07% 36,47% 25,71% 72,74% 84,73%60 34,23% 88,27% 60,80% 60,03% 74,65% 131,49%


tV IF 10 9 8 7 6 520 0,8701 0,9595 0,8931 0,9661 0,9937 0,9792884240 1,1625 1,9908 11,9845 77,7763 113,4389 165,520160 124,7894 140,3748 206,1792 228,4181 270,0195 313,1939

Na Figura 5.7 percebe-se que quanto mais rápido os dados são gerados a mediana se

aproxima ao terceiro quartil, que é aproximadamente 1,08s, apresentando um comportamento

similar ao analisado no cenário B quando F = 10.

5.4. RESULTADOS 78


Na Figura 5.8 é possível observar, que embora tenha um comportamento similar ao dos

experimentos do cenário B com F =20, ter o dobro de tarefas de coleta rodando permite diminuir

em 400s os valores máximos obtidos, e em 200s os valores que se encontram entre o terceiro

quartil e a mediana.


Na Figura 5.9, observa-se que conforme a periodicidade da geração dos dados, diminui-se

os tempos de atraso fim-a-fim deles, além de se espalharem mais em relação à mediana. Chegando

a obter valores aproximados aos 20 min. Devido que a quantidade de dados enfileirados começa

a aumentar no decorrer do tempo, e, portanto, os tempos de enfileiramento são bem maiores no

final do período T.

5.4.4 Comparação entre cenários

Analisando os resultados dos cenários em conjunto, pode-se indicar que as configurações

adequadas, para responder aos requerimentos de atendimento, a uma determinada quantidade de

fontes de dados ou fornecedores, são àquelas que se encontram nas tabelas de taxa de descarte e

tempo médio de vida, que não estão em negrito.

5.5. DISCUSSÃO 79


Este mesmo padrão pode ser observado na comparação das médias, de todos os experi-

mentos, apresentada na Figura 5.10, onde pode se observar que o sistema mantém um tempo

de atraso baixo, até o ponto onde a configuração não responde adequadamente. Assim, a con-

figuração (2,10,[1,9]) é a configuração limite do cenário A, a partir da qual o tempo médio

começa a crescer significativamente; para o cenário B, a configuração limite é (4, 20, [1,9]). Já

para o cenário C é (8,40,[1,9]), mas cabe ressaltar que para este cenário em especial, depois da

configuração (8,20,[1,5]) começa a existir descarte de dados, embora o aumento na média do

atraso fim-a-fim não seja de mais de 1s.

Figura 5.10: Comparação valores médios de aFF.

5.5 Discussão

As métricas utilizadas neste trabalho foram estabelecidas, com o intuito de se medir o

impacto dos elementos da plataforma, no tempo de disponibilização dos dados para o usuário

final. Em relação às propostas analisadas no capítulo de Trabalhos Relacionados, estas métricas


podem ser consideradas como novidade, dado que em nenhum desses documentos os autores

oferecem elementos de medição, que avaliem o desempenho de suas propostas neste aspecto.

Do ponto de vista prático a avaliação experimental fornece uma visão inicial do compor-

tamento do testbed e, sugere, tomando como base o tempo de atraso fim-a-fim, as configurações

que deveriam ser feitas no sistema, para viabilizar uma resposta acertada na hora de atender até

sessenta fontes de dados ou RSSFs. Considerando este ponto de vista, e fazendo a correlação

com a aplicabilidade da implementação, no contexto de cidades inteligentes, esta implementação

forneceria uma infraestrutura para aplicações que não sejam críticas, ou que não dependam de

obter dados em tempo real, como aplicações ambientais (e.g., temperatura, CO2 e umidade),

dado que a sobrecarga no tempo de disponibilização dos dados, que agrega a proposta como

mínimo é de meio segundo, e pode chegar até os 5 minutos.


Este capítulo apresentou uma avaliação experimental, que analisa a sobrecarga no tempo

de disponibilização dos dados, que é agregada pelos componentes propostos na implementação da

arquitetura. No início do capítulo foi apresentada uma visão geral dos experimentos. Logo após,

foram definidas as representações das métricas estabelecidas no capítulo anterior, assim como

as variáveis que foram utilizadas. Em seguida, foi apresentado o procedimento sistemático de

medição, em conjunto com a metodologia aplicada para os experimentos. Por fim, os resultados

dos experimentos foram apresentados, agrupados por cenário, com a sua respectiva explicação,

assim como a discussão dos mesmos, em relação à viabilidade da implementação da arquitetura

proposta.

Estes experimentos mostraram que a implementação da arquitetura gera uma sobrecarga

no tempo de disponibilização dos dados, que impacta minimamente no desempenho neste tipo

de sistemas.

818181

6Conclusões

As diversas propostas mencionadas no capítulo de trabalhos relacionados abordam dife-

rentes aspectos da integração de RSSFs com a nuvem, porém, elas só atendem a um subconjunto

de características. Consequentemente, prover uma solução abrangente, que responda a todos

os requisitos considerados no presente trabalho como relevantes, não é trivial e sugere que no

processo de construção deste tipo sistemas é preciso lidar com muitos desafios.

Devido a proposta ser baseada no paradigma de computação orientada a serviço, herda

muitos dos componentes e serviços da arquitetura orientado a serviço SOA, o que permite

aproveitar estudos correlatos úteis, para definir os componentes, as responsabilidades, os papéis

e os fluxos de informação, que são aplicados a este tipo de sistemas.

Disponibilizar as funcionalidades das RSSFs, através do modelo de serviço, oferece um

aprimoramento na criação de aplicações, dado que todas essas funcionalidades passam a ter

interfaces, que se caracterizam por serem reutilizáveis, componíveis, flexíveis e gerenciáveis.

A virtualização dos dados das redes de sensores, feita através do conceito de fila do

MOM, como foi proposto neste trabalho, permite o desacoplamento temporal do usuário com

o sistema, além de dar ao usuário a sensação de posse sobre os dados, podendo acessá-los

quando e como quiser. Adicionalmente, o uso de interfaces de serviços padronizadas, como WS,

como pontos de acesso aos sensores virtualizados possibilita a conectividade entre os sensores

heterogêneos.

O modelo de entrega de nuvem PaaS responde melhor às necessidades dos arcabouços

de integração de RSSFs com computação na nuvem, devido ao fato de que não só fornecem

os recursos para acessar, manipular, armazenar e publicar os dados, mas também oferece todo

um conjunto de ferramentas, para o desenvolvimento de aplicações, que façam uso dos dados

coletados no contexto de cidades inteligentes.

Embora seja óbvio que a implementação de uma arquitetura, como a proposta, adici-

one uma sobrecarga nos tempos de disponibilização de dados para o usuário final, devido à

ampla quantidade de componentes, que interveêm nos processos próprios destes sistemas, a

implementação de um testbed permite ao pesquisador quantificar, através de experimentos, o

comportamento real dos mesmos. Adicionalmente, estas quantificações podem ser utilizadas

6.1. CONTRIBUIÇÕES 82

para gerar simulações que vislumbrem o comportamento da proposta em função do tempo.

6.1 Contribuições

As principais contribuições deste trabalho são:

� Uma arquitetura de alto nível baseada em computação orientada a serviço (SOC),

que permite a combinação de RSSFs com a computação na nuvem, visando atender

aos requisitos funcionais e não funcionais de aplicações, no contexto de cidades

inteligentes;

� Uma análise comparativa das soluções, que têm sido apresentadas até o momento,

destacando as principais caraterísticas que os projetos de integração de RSSFs com a

computação da nuvem deveriam ter. Assim como, os pontos fortes que são explorados,

para aprimorar o desenvolvimento deste tipo de arcabouço no contexto das cidades

inteligentes;

� Um mecanismo de virtualização de dados para as RSSFs, baseado no conceito de fila

dos MOM, com o intuito de dar ao usuário final a sensação de posse dos sensores e,

portanto, o usuário tem a possibilidade de dispor à vontade dos sensores virtualizados;

� Um mecanismo de armazenamento de dados automatizado, que aproveita a capa-

cidade do ESB, para sincronizar e executar tarefas de forma programada, visando

melhorar os tempos de resposta nos processos de coleta e armazenamento de dados;

� Uma plataforma de serviços, para suportar o desenvolvimento de aplicações de

RSSFs, sob o modelo de sensoriamento como serviço, que não só permite o aprovei-

tamento das informações que os dados geram, mas que também fornece toda uma

infraestrutura para criar aplicações, através da combinação de serviços oferecidos,

tanto internamente, quanto por organizações externas ao sistema;

� Uma implementação (testbed), baseada na arquitetura proposta, que permite fazer

uma avaliação inicial, e que vislumbra o impacto que tem a sobrecarga dos elementos

que a compõe, adicionando este tipo de arquitetura;

� Quatro métricas para a análise do impacto de arcabouços de integração de RSSFs

com computação na nuvem, que caracterizam estes tipos de sistemas em termos de

tempo de disponibilização dos dados para o usuário final.

6.2 Trabalhos Futuros

Como trabalhos futuros são propostas as seguintes atividades como desdobramento da

arquitetura desenvolvida:

6.2. TRABALHOS FUTUROS 83

� Desenvolvimento de um algoritmo baseado em inteligência computacional para

determinar a localização geográfica dos dados coletados das RSSFs, que aprimore a

disponibilização dos mesmos, dependendo das caraterísticas do usuário final e do seu

contexto. Assim, este algoritmo poderia ser oferecido como um WS, que por sua vez

seria incluso no processo de coleta automatizado.

� Estudo de mecanismos de reconfiguração dinâmica para cada um dos módulos

da camada de serviço da arquitetura proposta, separadamente e em conjunto. A

arquitetura define uma série de componentes que podem ser utilizados e configurados

individualmente ou em conjunto, isto permite que possa ser feito um ajuste fino

de forma automatizada do sistema, visando melhorar o desempenho do mesmo em

termos de capacidade de processamento, disponibilidade dos recursos, dentre outros.

� Modificação da proposta de virtualização de dados de sensores proposta nesta dis-

sertação, feita através de filas, para adicionar a capacidade de gerenciamento dos

parâmetros de execução dos sensores físicos. Isto é, habilitar a possibilidade de re-

configurar os parâmetros de execução dos sensores, visando melhorar o desempenho

dos mesmos ou para melhorar, por exemplo, o seu consumo de energia.

� Definição de outras métricas que avaliem o impacto dos elementos da arquitetura,

com o intuito de gerar configurações adequadas, relacionadas a diferentes tipos de

aplicações, no contexto de cidades inteligentes. Cada componente da arquitetura, em

suas três camadas, oferece a possibilidade de ser configurado segundo as necessidades

do usuário, assim, se fosse possível medir o comportamento de cada um deles, teriam-

se dados históricos que permitiriam prever comportamentos futuros e, portanto,

poderiam ser estabelecidos como base para alimentar os algoritmos de reconfiguração

dinâmica, individualmente ou como um todo.

� Mecanismo para atender os requisitos das aplicações críticas, no contexto de cidades

inteligentes, que requeiram dados em tempo real. Isto é, dadas as caraterísticas de

uma aplicação crítica, o sistema deveria ter a capacidade de estabelecer quais dos com-

ponentes, definidos na arquitetura, seriam adequados e deveriam ser incluídos para

responder às necessidades deste tipo de aplicação, baseando-se no comportamento e

desempenho histórico de cada um dos componentes.

848484

Referências

AHMED, K.; GREGORY, M. Integrating wireless sensor networks with cloud computing. In:INT. CONF. MOB. AD-HOC SENS. NETWORKS, MSN 2011, 2011. Proceedings. . . Ieee,2011. p.364–366.

AL-JAROODI, J.; MOHAMED, N. Service-oriented middleware: a survey. J. Netw. Comput.Appl., [S.l.], v.35, n.1, p.211–220, Jan. 2012.

ANSARI, W. S. et al. A Survey on Cloud-Sensor : architecture , applications and approaches.Int. J. Distrib. Sens. Networks, [S.l.], v.2013, p.1–36, 2013.

ARJUN, D. et al. Integrating cloud-WSN to analyze weather data and notify SaaS user alertsduring weather disasters. In: ADVANCE COMPUTING CONFERENCE (IACC), 2015 IEEEINTERNATIONAL. Anais. . . [S.l.: s.n.], 2015. p.899–904.

ASLAM, M. S.; REA, S.; PESCH, D. Service Provisioning for the WSN Cloud. 2012 IEEEFifth Int. Conf. Cloud Comput., [S.l.], p.962–969, June 2012.

BARBARÁN, J.; DÍAZ, M.; RUBIO, B. A Virtual Channel-Based Framework for theIntegration of Wireless Sensor Networks in the Cloud. In: FUTURE INTERNET OF THINGSAND CLOUD (FICLOUD), 2014 INTERNATIONAL CONFERENCE ON. Anais. . . [S.l.: s.n.],2014. p.334–339.

CORRADI, A.; FANELLI, M.; FOSCHINI, L. VM consolidation: a real case based onopenstack cloud. Futur. Gener. Comput. Syst., [S.l.], v.32, n.1, p.118–127, 2014.

DELICATO, F. et al. A flexible web service based architecture for wireless sensor networks.23rd Int. Conf. Distrib. Comput. Syst. Work. 2003. Proceedings., [S.l.], 2003.

DILLON, T.; WU, C. W. C.; CHANG, E. Cloud Computing: issues and challenges. Adv. Inf.Netw. Appl. (AINA), 2010 24th IEEE Int. Conf., [S.l.], p.27–33, 2010.

ENDO, P. T. et al. A Survey on Open-source Cloud Computing Solutions. Comput. Networks,[S.l.], v.508, n.December, p.3–16, 2009.

ERL, T.; PUTTINI, R.; MAHMOOD, Z. Cloud Computing: concepts, technology, &architecture. [S.l.]: Pearson Education, 2013.

GLITHO, R.; MORROW, M.; POLAKOS, P. A cloud based — Architecture for cost-efficientapplications and services provisioning in wireless sensor networks. In: JT. IFIP WIREL. MOB.NETW. CONF., 6. Anais. . . [S.l.: s.n.], 2013.

GLOMBITZA, N.; PFISTERER, D.; FISCHER, S. Integrating wireless sensor networks intoweb service-based business processes. Proc. 4th Int. Work. Middlew. Tools, Serv. Run-TimeSupport Sens. Networks - MidSens ’09, [S.l.], p.25–30, 2009.

HADIM, S.; MOHAMED, N. Middleware: middleware challenges and approaches for wirelesssensor networks. IEEE distributed systems online, [S.l.], n.3, p.1, 2006.

HASSAN, M. M.; SONG, B.; HUH, E.-N. A framework of sensor-cloud integrationopportunities and challenges. 2009. 618–626p.

REFERÊNCIAS 85

ISLAM, M. M. et al. A survey on virtualization of wireless sensor networks. Sensors, [S.l.],v.12, n.2, p.2175–2207, Jan. 2012.

ISLAM, M. M.; HUH, E.-N. Virtualization in Wireless Sensor Network: challenges andopportunities. J. Networks, [S.l.], v.7, n.3, p.412–418, Mar. 2012.

JAMSHIDI, M. System of systems engineering: innovations for the twenty-first century. [S.l.]:John Wiley & Sons, 2011. v.58.

JIN, J. et al. An Information Framework for Creating a Smart City Through Internet of Things.IEEE Internet Things J., [S.l.], v.1, n.2, p.112–121, 2014.

KHAN, I. et al. Wireless Sensor Network Virtualization: a survey. IEEE Commun. Surv.Tutorials, [S.l.], n.c, p.1–1, 2015.

KULKARNI, R. V.; FöRSTER, A.; VENAYAGAMOORTHY, G. K. Computational intelligencein wireless sensor networks: a survey. IEEE Commun. Surv. Tutorials, [S.l.], v.13, n.1,p.68–96, 2011.

KYUSAKOV, R. et al. Integration of wireless sensor and actuator nodes with IT infrastructureusing service-oriented architecture. Industrial Informatics, IEEE Transactions on, [S.l.], v.9,n.1, p.43–51, 2013.

LAUKKARINEN, T.; SUHONEN, J.; HäNNIKäINEN, M. An Embedded Cloud Design forInternet-of-Things. Int. J. Distrib. Sens. Networks, [S.l.], v.2013, p.1–13, 2013.

LEE, K. et al. Extending sensor networks into the cloud using amazon web services. In:NETWORKED EMBEDDED SYSTEMS FOR ENTERPRISE APPLICATIONS (NESEA),2010 IEEE INTERNATIONAL CONFERENCE ON. Anais. . . [S.l.: s.n.], 2010. p.1–7.

MAHMOUD, Q. Middleware for Communications. [S.l.]: Wiley, 2004.

MELL, P.; GRANCE, T. The NIST definition of cloud computing [Recommendations of theNational Institute of Standards and Technology-Special Publication 800-145]. Washington DC:NIST. Recuperado de http://csrc. nist. gov/publications/nistpubs/800-145/SP800-145. pdf,[S.l.], 2011.

MIRASHE, S. P.; KALYANKAR, N. V. Cloud Computing. Commun. ACM, [S.l.], v.51, n.7,p.9, 2010.

MITTON, N. et al. Combining Cloud and sensors in a smart city environment. 2012. 247p.v.2012, n.1.

NAVARRO, M. et al. VITRO Architecture: bringing virtualization to wsn world. 2011 IEEEEighth Int. Conf. Mob. Ad-Hoc Sens. Syst., [S.l.], p.831–836, Oct. 2011.

PAPAZOGLOU, M. P. et al. Service-Oriented Computing: a research roadmap. Int. J. Coop.Inf. Syst., [S.l.], v.17, n.02, p.223–255, 2008.

PAPAZOGLOU, M. P.; HEUVEL, W.-J. van den. Service oriented architectures: approaches,technologies and research issues. VLDB J., [S.l.], v.16, n.3, p.389–415, Mar. 2007.

PELTZ, C. Web services orchestration and choreography. Computer (Long. Beach. Calif).,[S.l.], v.36, n.10, p.46–52, Oct. 2003.

REFERÊNCIAS 86

PERERA, C. et al. Sensor search techniques for sensing as a service architecture for the internetof things. Sensors Journal, IEEE, [S.l.], v.14, n.2, p.406–420, 2014.

PIYARE, R.; LEE, S. R. Towards internet of things (iots): integration of wireless sensor networkto cloud services for data collection and sharing. arXiv preprint arXiv:1310.2095, [S.l.], v.5,n.5, p.59–72, 2013.

RAJESH, V. et al. Integration of wireless sensor network with cloud. In: ITC 2010 - 2010 INT.CONF. RECENT TRENDS INFORMATION, TELECOMMUN. COMPUT. Anais. . . Ieee,2010. p.321–323.

RAJKUMAR, B. et al. Wireless Sensor Networks In Cloud Computing. , [S.l.], v.2, n.4,p.1384–1388, 2013.

RAO, B. B. P. et al. Cloud computing for Internet of Things & sensing based applications. In:SIXTH INT. CONF. SENS. TECHNOL., 2012. Anais. . . [S.l.: s.n.], 2012. p.374–380.

REA, S.; ASLAM, M. S.; PESCH, D. Serviceware-A service based management approach forWSN cloud infrastructures. In: IEEE INT. CONF. PERVASIVE COMPUT. COMMUN. WORK.PERCOM WORK. 2013, 2013. Anais. . . [S.l.: s.n.], 2013. n.March, p.133–138.

SEFRAOUI, O.; AISSAOUI, M.; ELEULDJ, M. OpenStack: toward an open-source solution forcloud computing. Int. J. Comput. Appl., [S.l.], v.55, n.3, p.38–42, 2012.

SILVA, W. M. da et al. Smart cities software architectures. Proc. 28th Annu. ACM Symp.Appl. Comput. - SAC ’13, New York, New York, USA, p.1722, 2013.

SOLDATOS, J.; SERRANO, M.; HAUSWIRTH, M. Convergence of utility computing with theInternet-of-things. In: INT. CONF. INNOV. MOB. INTERNET SERV. UBIQUITOUSCOMPUT. IMIS 2012, 6. Proceedings. . . Ieee, 2012. p.874–879.

STAVROPOULOS, T. G. et al. aWESoME: a web service middleware for ambient intelligence.Expert Syst. Appl., [S.l.], v.40, n.11, p.4380–4392, Sept. 2013.

Von Laszewski, G. et al. Comparison of multiple cloud frameworks. Proc. - 2012 IEEE 5th Int.Conf. Cloud Comput. CLOUD 2012, [S.l.], p.734–741, 2012.

WANG, M. et al. Middleware for wireless sensor networks: a survey. J. Comput. Sci. . . . , [S.l.],v.23, n.2006, p.305–326, 2008.

WIND, S. Open source cloud computing management platforms: introduction, comparison, andrecommendations for implementation. 2011 IEEE Conf. Open Syst. ICOS 2011, [S.l.],p.181–185, 2011.

YURIYAMA, M.; KUSHIDA, T. Sensor-cloud infrastructure physical sensor management withvirtualized sensors on cloud computing. In: INT. CONF. NETWORK-BASED INF. SYST.NBIS 2010, 13. Proceedings. . . Ieee, 2010. p.1–8.

ZHANG, G. A. et al. Joint routing and channel assignment algorithms in cognitive wirelessmesh networks. Eur. Trans. Telecommun., [S.l.], 2014.

ZHANG, P.; SUN, H.; YAN, Z. A Novel Architecture Based on Cloud Computing for WirelessSensor Network. Proc. 2nd Int. Conf. Comput. Sci. Electron. Eng. (ICCSEE 2013), [S.l.],n.Iccsee, p.472–475, 2013.

REFERÊNCIAS 87

ZHANG, Q.; CHENG, L.; BOUTABA, R. Cloud computing: state-of-the-art and researchchallenges. J. Internet Serv. Appl., [S.l.], v.1, n.1, p.7–18, 2010.

ZHU, Q. et al. IOT Gateway: bridgingwireless sensor networks into internet of things. 2010IEEE/IFIP Int. Conf. Embed. Ubiquitous Comput., [S.l.], p.347–352, Dec. 2010.

arquitetura baseada em redes de sensores sem fio e ... · as a service) pelo apache stratos, que...

Documents