Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
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
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.
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.2 Diagrama de caixa (2,10,*). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3 Diagrama de caixa (2,15,*). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.4 Diagrama de caixa (4,10,*). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.5 Diagrama de caixa (4,20,*). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.6 Diagrama de caixa (4,30,*). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.7 Diagrama de caixa (8,20,*). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.8 Diagrama de caixa (8,40,*). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.9 Diagrama de caixa (8,60,*). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
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
5.5 Taxa de descarte de dados, S = 4 . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.6 Tempo médio do aFF, S = 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.7 Taxa de descarte de dados, S = 8 . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.8 Tempo médio do aFF, S = 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
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
3.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
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
4.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
5.6 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
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)
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:
2.4. COMPUTAÇÃO EM NUVEM 27
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.
2.4. COMPUTAÇÃO EM NUVEM 28
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
2.4. COMPUTAÇÃO EM NUVEM 29
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).
2.4. COMPUTAÇÃO EM NUVEM 30
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
2.4. COMPUTAÇÃO EM NUVEM 31
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/
2.4. COMPUTAÇÃO EM NUVEM 32
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
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
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
2.6. CIDADES INTELIGENTES (SMART CITIES) 35
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
2.6. CIDADES INTELIGENTES (SMART CITIES) 36
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
3.3. ANÁLISE DOS TRABALHOS RELACIONADOS 42
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 é
3.3. ANÁLISE DOS TRABALHOS RELACIONADOS 43
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
3.3. ANÁLISE DOS TRABALHOS RELACIONADOS 44
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
3.3. ANÁLISE DOS TRABALHOS RELACIONADOS 45
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
3.3. ANÁLISE DOS TRABALHOS RELACIONADOS 46
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
3.3. ANÁLISE DOS TRABALHOS RELACIONADOS 47
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
Referência Descrição Camadas Foco Testes Middleware Cenários
(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.
Continua na página seguinte
3.3.A
NÁ
LIS
ED
OS
TR
AB
AL
HO
SR
EL
AC
ION
AD
OS
50
Tabela 3.3 – Continuação da tabela
Referência Descrição Camadas Foco Testes Middleware Cenários
(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.
Continua na página seguinte
3.3.A
NÁ
LIS
ED
OS
TR
AB
AL
HO
SR
EL
AC
ION
AD
OS
51
Tabela 3.3 – Continuação da tabela
Referência Descrição Camadas Foco Testes Middleware Cenários
(ZHU et al.,
2010)
Apresentam uma arqui-
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)
Apresentam uma arqui-
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
Continua na página seguinte
3.3.A
NÁ
LIS
ED
OS
TR
AB
AL
HO
SR
EL
AC
ION
AD
OS
52
Tabela 3.3 – Continuação da tabela
Referência Descrição Camadas Foco Testes Middleware Cenários
(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.
Continua na página seguinte
3.3.A
NÁ
LIS
ED
OS
TR
AB
AL
HO
SR
EL
AC
ION
AD
OS
53
Tabela 3.3 – Continuação da tabela
Referência Descrição Camadas Foco Testes Middleware Cenários
(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)
✗ ✓ ✗ ✓ ✗ ✗ ✗ ✗ ✓
3.4. CONSIDERAÇÕES FINAIS 55
3.4 Considerações Finais
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 é
4.2. IMPLEMENTAÇÃO DA PROPOSTA 60
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
4.2. IMPLEMENTAÇÃO DA PROPOSTA 61
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,
4.2. IMPLEMENTAÇÃO DA PROPOSTA 62
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.
4.2. IMPLEMENTAÇÃO DA PROPOSTA 63
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
4.2. IMPLEMENTAÇÃO DA PROPOSTA 64
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. FLUXOS DE INFORMAÇÃO 66
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;
4.3. FLUXOS DE INFORMAÇÃO 67
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:
4.4. CONSIDERAÇÕES FINAIS 68
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.
4.4 Considerações Finais
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.
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
Figura 5.2: Diagrama de caixa (2,10,*).
Figura 5.3: Diagrama de caixa (2,15,*).
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).
Tabela 5.5: Taxa de descarte de dados, S = 4
. 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
Tabela 5.6: Tempo médio do aFF, S = 4
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
Figura 5.4: Diagrama de caixa (4,10,*).
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).
Figura 5.5: Diagrama de caixa (4,20,*).
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
Figura 5.6: Diagrama de caixa (4,30,*).
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).
Tabela 5.7: Taxa de descarte de dados, S = 8
. 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%
Tabela 5.8: Tempo médio do aFF, S = 8
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
Figura 5.7: Diagrama de caixa (8,20,*).
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.
Figura 5.8: Diagrama de caixa (8,40,*).
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
Figura 5.9: Diagrama de caixa (8,60,*).
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
5.6. CONSIDERAÇÕES FINAIS 80
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.
5.6 Considerações Finais
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.