Alberto Messias Costa Souza

ALBERTO MESSIAS DA COSTA SOUZA
UMA NOVA ARQUITETURA PARA INTERNET DAS COISAS COM

ANLISE E RECONHECIMENTO DE PADRES E PROCESSAMENTO
COM BIG DATA
So Paulo
2015

COM BIG DATA
Tese de Doutorado
Orientador: Prof. Dr. Jos Roberto de Almeida Amazonas
UNIVERSIDADE DE SO PAULO
ESCOLA POLITCNICA
So Paulo
2015

COM BIG DATA
Tese apresentada Escola

Politcnica da Universidade de So
Paulo para obteno do ttulo de
Doutor em Cincias.
rea de concentrao:
Sistemas Eletrnicos
Orientador:
Prof. Dr. Jos Roberto de Almeida Amazonas
So Paulo
2015
Catalogao-na-publicao
Souza, Alberto
Uma nova arquitetura para Internet das Coisas com anlise e
reconhecimento de padres e processamento com Big Data /
Souza, A. M. C. -- So Paulo, 2015.
118 p.
Tese (Doutorado) - Escola Politcnica da Universidade de So

Paulo. Departamento de Engenharia de Sistemas Eletrnicos.
1. Internet das Coisas 2. Redes de Comunicao 3.

Reconhecimento de Padres 4. Modelo de Referncia 5. Big
Data I. Universidade de So Paulo. Escola Politcnica.
Departamento de Engenharia de Sistemas Eletrnicos II. t.
Dedico ao Arthur, Alice, Evelyn, minha
me Salete e ao meu pai Geraldo.
AGRADECIMENTOS
Agradeo primeiramente a Deus pela fora de vontade, oportunidade e motivao nesta longa
caminhada. Gostaria de agradecer em especial aos meus filhos, Arthur e Alice e esposa
Evelyn, aos meus pais Salete e Geraldo, meu irmo Sandro e sua famlia Marcia, Vitria e
Davi, que por vezes, ao me ausentar e souberam me compreender e respeitar.
Agradeo ao professor Dr. Clovis Torres Fernandes por acreditar em mim, ao professor
Dr. Ivan Carlos Alcntara de Oliveira que me auxiliou no incio desta pesquisa e, sobretudo,
ao meu orientador professor Dr. Jos Roberto de Almeida Amazonas, que foi fundamental
nesta pesquisa, que soube me conduzir e cobrar.
Agradeo ainda, aos amigos que me motivaram e me acompanharam neste perodo.
No podem haver barreiras para o empenho
humano. No importa o quo ruim a vida
parea estar, sempre existe algo que voc
pode fazer e triunfar, onde h vida, h
esperana.
(Stephen Hawking)
RESUMO
A Internet das Coisas um novo paradigma de comunicao que estende o mundo vir-
tual (Internet) para o mundo real com a interface e interao entre objetos. Ela possuir um
grande nmero de dispositivos heteregneos interconectados, que dever gerar um grande
volume de dados. Um dos importantes desafios para seu desenvolvimento se guardar e
processar esse grande volume de dados em aceitveis intervalos de tempo. Esta pesquisa
enderea esse desafio, com a introduo de servios de anlise e reconhecimento de padres
nas camadas inferiores do modelo de para Internet das Coisas, que procura reduzir o pro-
cessamento nas camadas superiores. Na pesquisa foram analisados os modelos de referncia
para Internet das Coisas e plataformas para desenvolvimento de aplicaes nesse contexto.
A nova arquitetura de implementada estende o LinkSmart Middeware pela introduo de um
mdulo para reconhecimento de padres, implementa algoritmos para estimao de valores,
deteco de outliers e descoberta de grupos nos dados brutos, oriundos de origens de dados.
O novo mdulo foi integrado plataforma para Big Data Hadoop e usa as implementaes
algortmicas do framework Mahout. Este trabalho destaca a importncia da comunicao
cross layer integrada essa nova arquitetura. Nos experimentos desenvolvidos na pesquisa
foram utilizadas bases de dados reais, provenientes do projeto Smart Santander, de modo
a validar da nova arquitetura de IoT integrada aos servios de anlise e reconhecimento de
padres e a comunicao cross-layer.
Palavras-chave: Internet das Coisas. Redes de Comunicao. Reconhecimento de Padres.

Modelo de Referncia. Big Data.
ABSTRACT
The Internet of Things is a new communication paradigm in which the Internet is extended
from the virtual world to interface and interact with objects of the physical world. The IoT
has high number of heterogeneous interconnected devices, that generate huge volume data.
The most important IoT challenges is store and proccess this large volume data. This research
addresses this issue by introducing pattern recognition services into the lower layers of the
Internet of Things reference model stack and reduces the processing at the higher layers.
The research analyzes the Internet of Things reference model and Middleware platforms
to develop applications in this context. The new architecture implementation extends the
LinkSmart by introducing a pattern recognition manager that includes algorithms to estimate
parameters, detect outliers, and to perform clustering of raw data from IoT resources. The
new module is integrated with the Big Data Haddop platform and uses Mahout algorithms
implementation. This work highlights the cross-layer communication intregated in the new
IoT architecture. The experiments made in this research using the real database from Smart
Santander Framework to validate the new IoT architecture with pattern recognition services
and cross-layer communication.
Keywords: Internet of Things. Communications Network. Pattern Recognition. Refe-

rence Model. Big Data
LISTA DE ILUSTRAES
Figura 1 Mapa conceitual que destaca os conceitos pertinentes pesquisa. . 20
Figura 2 Interao entre as redes de comunicao, o mundo fsico e o virtual. 26

Figura 3 Modelo Inclusivo para a IoT. . . . . . . . . . . . . . . . . . . . . . 27
Figura 4 Modelo de Referncia para IoT proposto pelo ITU-T. . . . . . . . . 28
Figura 5 Modelo de Ecossitema para IoT, proposto pelo ITU-T. . . . . . . . 32
Figura 6 Alto nvel de taxonomia, influncias e dependncias entre o modelo
de referncia para IoT e a arquitetura de referncia para IoT. . . 33
Figura 7 Interaes entre os sub-modelos do modelo de referncia para IoT. . 34
Figura 8 Interaes entre o modelo funcional e requisitos uificados e a viso
funcional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figura 9 Grupos de funcionais do Modelo Funcional para IoT. . . . . . . . . 36
Figura 10 Categorias que impactam no desenvolvimento para IoT. . . . . . . 38
Figura 11 Estrutura em camadas do LinkSmart middleware. . . . . . . . . . . 44
Figura 12 Arquitetura ilustrativa para o desenvolvimento de servios e apli-
caes baseadas no LinkSmart. . . . . . . . . . . . . . . . . . . 45
Figura 13 Fluxo de dados com a plataforma Ubidots (UBIDOTS, 2014). . . . 46
Figura 14 Widget criado na plataforma Ubidots. . . . . . . . . . . . . . . . . 47
Figura 15 Pseudo-cdigo do algoritmo k-means. . . . . . . . . . . . . . . . . 52
Figura 16 Modelo em camadas para a minerao de dados para a IoT. . . . . 55
Figura 17 Aplicao de teste com a plataforma Ubidots. . . . . . . . . . . . . 61

Figura 18 Aplicao de teste com o LinkSmart middleware. . . . . . . . . . . 62
Figura 19 Proposta de nova estrutura em camadas do LinkSmart middleware
com os mecanismos de anlise e reconhecimento de padres. . 64
Figura 20 Representao grfica do fluxo de dados e informaes na arquite-
tura proposta. . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 21 Diagrama de classes do Pattern Manager incluindo os pacotes, a
Interface e a classe que a implementa. . . . . . . . . . . . . . . 68
Figura 22 Diagrama de Classes com a implementao do servio de clustering
no mdulo Pattern Manager. . . . . . . . . . . . . . . . . . . . 69
Figura 23 Diagrama de classes do servio de estimao de valores no mdulo
Pattern Manager. . . . . . . . . . . . . . . . . . . . . . . . . . 71
Figura 24 Diagrama de Classes do servio de deteco de outlier implemen-
tado no mdulo Pattern Manager. . . . . . . . . . . . . . . . . 73
Figura 25 Deteco de Outlier: so observados trs clusters e respectivamente
seus raios e dois pontos considerados outlier. . . . . . . . . . . 76
Figura 26 Diagrama de classes com os parmetros da comunicao cross layer
no mdulo de Pattern Manager. . . . . . . . . . . . . . . . . . 78
Figura 27 Exemplo de aplicao do processamento de eventos complexos e
criao de sensores virtuais em IoT. . . . . . . . . . . . . . . . 79
Figura 28 Aplicao disponvel com realidade aumentada e as informaes na

cidade de Santander. . . . . . . . . . . . . . . . . . . . . . . . 83
Figura 29 Pgina com o status do LinkSmart. . . . . . . . . . . . . . . . . . . 85
Figura 30 Pgina de status gerada pelo Servlet do gerenciador de padres. . . 85
Figura 31 Aplicao que simula o Resource Manager que representa a camada
fsica na validao da comunicao cross layer. . . . . . . . . . 86
Figura 32 Execuo da aplicao cliente desenvolvida para o experimento da
comunicao cross layer. . . . . . . . . . . . . . . . . . . . . . 87
Figura 33 Trecho do arquivo de LOG de execuo dos servios do Classifica-
tionManager. . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figura 34 Execuo da classe Resource Manager para experimentao do servio
de clustering na camada de middleware. . . . . . . . . . . . . . 89
Figura 35 A aplicao cliente para experimentao do servio de clustering na
camada de middleware. . . . . . . . . . . . . . . . . . . . . . 90
Figura 36 Todas as instncias mostradas em um grfico 3D e todos os clusters
identificados por nmeros e diferentes cores. . . . . . . . . . . 91
Figura 37 Decaimento do SSE pela quantidade de clusters. . . . . . . . . . . 92
Figura 38 Valores do Silhouette coefficient pela quantidade de clusters. . . . . 93
Figura 39 Execuo da aplicao de teste do servio de deteco de outlier
desenvolvido. . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figura 40 Curva ROC gereda a partir os resultados do classificador gerado com
o modelo criado pelo algoritmo de deteco de outlier desen-
volvido. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figura 41 Execuo da aplicao de teste do servio de estimao de valores
desenvolvido. . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figura 42 Grfico com as instncias reais e seus respectivos valores estimados. 98
Figura 43 Caso de uso do aplicativo para a criao de rotas com base nas prio-
ridades definidas pelo usurio. . . . . . . . . . . . . . . . . . . 99
Figura 44 Ponto de origem (175) e destino (257) indicados no mapa da cidade
de Santander. . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Figura 45 Mapa das cidade de Santander exibindo pontos de temperatura e
ocupao com o servio de deteco de outlier desativado. . . . 102
Figura 46 Primeira rota mais exibida pelo aplicativo. . . . . . . . . . . . . . 103
Figura 47 Segunda rota mais exibida pelo aplicativo. . . . . . . . . . . . . . 104
Figura 48 Terceira rota mais exibida pelo aplicativo. . . . . . . . . . . . . . . 104
Figura 49 Quarta rota mais exibida pelo aplicativo. . . . . . . . . . . . . . . 105
LISTA DE TABELAS
Tabela 1 Tabela com exemplos de valores de temperatura de entrada e metros

cbicos de gua poluda. . . . . . . . . . . . . . . . . . . . . . 49
Tabela 2 Tabela comparativa entre o LinkSmart Middleware e a plataforma

Ubidots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Tabela 3 Tabela com a descrio dos dados de temperatura obtidos no projeto

Smart Santander. . . . . . . . . . . . . . . . . . . . . . . . . . 83
Tabela 4 Tabela com a descrio dos dados de trfego obtidos no projeto
Smart Santander. . . . . . . . . . . . . . . . . . . . . . . . . . 84
Tabela 5 Tabela com o resumo das publicaes. . . . . . . . . . . . . . . . . 108

LISTA DE ABREVIATURAS E SIGLAS
2G Segunda Gerao
3G Terceira Gerao
AAAA Authentication, Authorization, Accounting, and Auditing
API Application Program Interface
Advanced Sensors and lightweight Programmable middleware for In-
ASPIRE
novative Rfid Enterprise applications
AUC Area Under Curve
BAN Body Area Networks
CAN Controler Area Network
CEP Processamento de Eventos Complexos
DCA Coleta e Anlise de Dados
DSL Digital Subscriber Line
EPA Agente de Processamento de Evento
EPC Cdigo Eletrnico de Produto
EPN Rede de Processamento de Eventos
FCAPS Fault, Configuration, Accounting, Performance, Security
FG Grupos Funcionais
FP6 Sixth Research Framework Programme
GPS Sistema de Posicionamento Global
GSN Global Sensor Network
HDFS Hadoop Distributed File System
HTTPs Protocolo de Transferncia de Hypertexto Seguro
HYDRA Heterogeneous Physical Devices in a Distribued Architecture
IoT-A Internet of Things Architecture
IPv6 Protocolo de Internet Verso 6
IoT Internet das Coisas
ITU International Telecommunication Union
LTE Long-Term Evolution Networks
MAE Mean Absolute Error
MB Mega Bytes
MIT Massachusetts Institute of Technology
MPP Massive Parallel Processing Databases
NFC Near Field Communication
OSGI Open Services Gateway Initiative
OSI Open Systems Interconnection
PHID Pattern Hardware Identification
PSTN Public Switched Telephone Network
QR Quick Response
RFID Radio Frequency Identification
RFID Identificao por Radiofrequncia
RMSE Root Mean Squared Error
ROC Receiver Operation Characteristics
SDK Software Development Kit
SIRENA Service Infrastructure for Real-time Embedded Networked Devices
SMEPP Secure Middleware For Embedded P2P
SMS Short Message Service
SOA Service-oriented Architecture
SSE Sum of the Square Errors
TB Tera Bytes
UBIWARE Smart Semantic Middleware for Ubiquitous Computing
Wi-Fi Wireless Fidelity
SUMRIO
1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1 CONCEITOS INTRODUTRIOS . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 MOTIVAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 CONCEITOS IMPORTANTES . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4 ESCOPO E OBJETIVOS DE PESQUISA . . . . . . . . . . . . . . . . . . . . 21
1.4.1 Escopo de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.2 Objetivos de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.5 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.6 ORGANIZAO DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . 24
2 INTERNET DAS COISAS, RECONHECIMENTO DE PADRES

E BIG DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1 INTERNET DAS COISAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 MODELOS DE REFERNCIA PARA IOT . . . . . . . . . . . . . . . . . . . 27
2.2.1 Modelo de referncia ITU-T . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1.1 Funcionalidades de gerenciamento . . . . . . . . . . . . . . . . . . . . . 30
2.2.1.2 Funcionalidades de segurana . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.1.3 Ecossitema da IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.2 Modelo IoT-A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.3 Modelo de referncia IoT-A . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2.4 Arquitetura de referncia IoT-A . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.4.1 Viso funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.4.2 Viso de informao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.2.4.3 Viso de desenvolvimento e operao . . . . . . . . . . . . . . . . . . . . 37
2.3 MIDDLEWARE DE INTERNET DAS COISAS . . . . . . . . . . . . . . . . . 41
2.3.1 Projeto Hydra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3.2 Projeto Ubidots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.4 ANLISE E RECONHECIMENTO DE PADRES . . . . . . . . . . . . . . . 47
2.4.1 Tcnica de regresso linear . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.4.2 Tcnicas de clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.4.2.1 Algoritmo de clustering k-means . . . . . . . . . . . . . . . . . . . . . . . 51
2.4.2.2 Algoritmo de clustering canopy . . . . . . . . . . . . . . . . . . . . . . . 51
2.4.3 Deteco de Outlier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.5 TECNOLOGIA BIG DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.5.1 Framework Hadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.6 TRATAMENTO DOS DADOS NO MODELO DE INTERNET DAS COISAS 54
2.6.1 Volume de dados gerados com a IoT . . . . . . . . . . . . . . . . . . . . . 54
2.6.2 Gerenciamento de dados em IoT . . . . . . . . . . . . . . . . . . . . . . . 56
2.6.2.1 Coleta e anlise de dados (DCA) . . . . . . . . . . . . . . . . . . . . . . 56
2.6.2.2 Sensores virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.6.2.3 Processamento de eventos complexos (CEP) . . . . . . . . . . . . . . . . 57
2.6.3 Tipos de dados em IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.7 CONSIDERAES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3 NOVA ARQUITETURA PARA INTERNET DAS COISAS COM

RECONHECIMENTO DE PADRES E BIG DATA . . . . . . . . . 59
3.1 ANLISE DE MODELOS DE REFERNCIA EM IOT . . . . . . . . . . . . 59
3.2 ANLISE CRTICA E COMPARATIVA ENTRE O LINKSMART MIDDLE-
WARE E PLATAFORMA UBIDOTS . . . . . . . . . . . . . . . . . . . . . 60
3.3 ANLISE E RECONHECIMENTO DE PADRES NAS CAMADAS DE MI-
DDLEWARE/SERVIO E DE DISPOSITIVO/GATEWAY NO MODELO DE
IOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4 ASPECTOS DE IMPLEMENTAO DO MDULO DE RECONHECIMENTO
DE PADRES E O PROCESSAMENTO COM BIG DATA . . . . . . . . . 67
3.4.1 Implementao do servio de clustering . . . . . . . . . . . . . . . . . . . 68
3.4.2 Implementao do servio de estimao de valores . . . . . . . . . . . . . 71
3.4.3 Implementao do servio de deteco de outlier . . . . . . . . . . . . . . 73
3.4.3.1 Algoritmo de deteco de outlier usando Big Data e o algoritmo de cluste-
ring k-means . . . . . . . . . . . . . . . . . . . . . . . . 75
3.4.4 Implementao da comunicao cross layer no modelo de IoT . . . . . . 76
3.5 UTILIZAO DE TCNICAS DE SENSORES VIRTUAIS E PROCESSA-
MENTO DE EVENTOS COMPLEXOS NO MODELO DE IOT . . . . . . 77
3.6 CONSIDERAES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4 VALIDAO E EXPERIMENTOS COM A NOVA ARQUITE-

TURA PARA INTERNET DAS COISAS . . . . . . . . . . . . . . . . 81
4.1 CENRIO DA VALIDAO EXPERIMENTAL . . . . . . . . . . . . . . . . 81
4.1.1 Descrio do Cenrio: Cidade Inteligente . . . . . . . . . . . . . . . . . . 81
4.1.2 Dados obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.2 MDULO DE RECONHECIMENTO DE PADRES EM EXECUO . . . . 84
4.3 APLICAO DE TESTE DA COMUNICAO CROSS LAYER . . . . . . . . 84
4.3.1 Concluses da experimentao da comunicao cross layer . . . . . . . . 88
4.4 APLICAO DE TESTE DO SERVIO DE CLUSTERING . . . . . . . . . . 89
4.4.1 Concluses da experimentao do servio de clustering . . . . . . . . . . 93
4.5 APLICAO DE TESTE DO SERVIO DE DETECO DE OUTLIER . . . 94
4.5.1 Concluses da experimentao do servio de deteco de outlier . . . . . 96
4.6 APLICAO DE TESTE DO SERVIO DE ESTIMAO DE VALORES . . 97
4.6.1 Concluses da experimentao do servio de estimao de valores . . . . 98
4.7 APLICAO ABRANGENTE NO CENRIO DE CIDADE INTELIGENTE . 99
4.7.1 Concluses quanto ao cenrio experimental da cidade inteligente . . . . 105
5 CONCLUSES E TRABALHOS FUTUROS . . . . . . . . . . . . . . 106

5.1 CONCLUSES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.2 DIVULGAO DA PESQUISA . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.3 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Referncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
17
1 INTRODUO
Este captulo tem por objetivo introduzir os principais conceitos relacionados com a pesquisa,
alm de sua motivao, escopo e objetivos. So apresentadas tambm a metodologia empre-
gada e a estrutura da tese.
1.1 CONCEITOS INTRODUTRIOS
Weiser (1999) menciona que as tecnologias mais profundas so aquelas que desaparecem.
Lyytinen e Yoo (2002) discutem que o prximo passo da computao tornar o computador
embutido nas aes naturais e interaes humanas. A essncia da computao pervasiva
reside na criao de ambientes saturados de computao e capacidade de comunicao que
se integrem com a vida humana (SATYANARAYANAN, 2001).
Essas novas tecnologias desenham um novo paradigma, a chamada era ps-PC, caracteri-
zado por milhes de dispositivos inteligentes interconectados, que devero mudar a vida das
pessoas e especialmente os negcios, usando nanotecnologia, microsistemas, redes de sen-
sores e identificao nica, alm das possveis Body Area Networks (BAN), que so redes de
comunicao com pequenos dispositivos inseridos ou implantados dentro do corpo e que se
comunicam (MATTERN; ZURICH, 2005).
Em abordagens preliminares, observa-se que devero existir centenas de dispositivos por
pessoa, por ambientes, de todas as escalas, conectados s redes sem fio, tornando a com-
putao onipresente, alm da evoluo das interfaces com os seres humanos que devero ser
mais transparentes e simples (WEISER, 1999).
Essa revoluo no influenciar somente na quantidade de informaes, mas na qualidade
dela. Inmeros e pequenos processadores embutidos em diversos objetos estaro integrados
no dia-a-dia. Weiser (1999) dizia que a tecnologia somente um meio para o propsito,
ou seja, a tecnologia uma ferramenta. Nesse momento se definia o termo computao
ubqua, numa forma mais acadmica e idealista. O termo computao pervasiva aparece
como uma tecnologia para o processamento onipresente e foi definido pela indstria (MAT-
TERN; ZURICH, 2005).
O conceito de Internet das Coisas foi proposto inicialmente pelo Auto-ID center do Mas-
sachusetts Institute of Technology (MIT) (MIT, 2011) e no relatrio de pesquisa escrito pelo
International Telecommunication Union (ITU) (ITU, 2005) (ITU, 2009).
Al-Qutayri (2010) menciona que os termos computao pervasiva e computao ubqua
podem ser empregados como sinnimos, nesta tese utiliza-se o termo Internet das Coisas
(IoT) tambm como sinnimo e deste ponto em diante ser mencionada como IoT.
18
1.2 MOTIVAO
Hurlburt, Voas e Miller (2012) mencionam que a Internet se iniciou como um meio de
comunicao num grupo restrito de pessoas. Seu desenvolvimento a tornou um meio de
comunicao entre pessoas e organizaes e posteriormente entre organizaes. Surge um
novo e importante paradigma, no qual coisas, que so inanimadas, podero ser programadas
para se comunicar, sentir e interagir com outras coisas.
Gluhak et al. (2009) discutem que este mecanismo de comunicao com o mundo fsico
possuir um grande nmero de dispositivos fsicos e que esse nmero tende a crescer em
escala (CLARK, 2005), em razo do desenvolvimento de novos dispositivos ubquos, que
devero permitir diferentes modalidades de interao, que tero como trfego principal inte-
raes centradas nos seres humanos, mas predominantemente comunicao de mquina para
mquina.
A heterogeneidade dos dispositivos deve crescer significativamente, incluindo-se pequenos
sensores e atuadores, que conforme citado em Clark (2005), agrega-se a necessidade de in-
teroperabilidade. O volume de informao diversificada gerada crescer exponencialmente,
conforme o discutido em Kitsuregawa (2008), fato este que demandar segurana e pri-
vacidade no acesso s informaes contextualizadas e aos servios de atuao no ambiente
(GLUHAK et al., 2009).
As informaes geradas pelos diferentes dispositivos devero ser processadas ou guardadas
para um posterior processamento. Conforme informam Botts et al. (2007), sero necessrios
metadados dessas informaes que possibilitem sua futura anlise, como por exemplo, me-
tadados que incluam localizao geogrfica e temporal. Conforme afirmado em Gluhak et
al. (2009) sero necessrios novos mecanismos eficientes e polticas inerentes prpria
infraestrutura da rede para o gerenciamento e armazenamento desses dados.
O fluxo de informao trafegado pela Internet fim-a-fim, ou seja, uma comunicao entre
duas ou mais entidades ou aplicaes que compartilham algo. Nesse novo modelo de rede,
a IoT, o fluxo de informaes dever tornar-se mais complexo. Esse fluxo de informao
possuir vrios atores, como, ns de origem de dados, coletores de informaes e pontos
intermedirios de processamento. Os fluxos de informaes podero ser alterados nos ns
finais ou intermedirios ao longo do caminho (GLUHAK et al., 2009).
A comunicao com o mundo real dos objetos na IoT dever criar um trfego de rede
diferente dos padres da Internet atual. Esperam-se diferentes padres de trfegos de rede,
nos quais devero existir pequenos trechos de carga til e padres irregulares conduzidos por
essa interao com o mundo real (SALTZER; REED; CLARK, 1981) (KRNIC; KRCO,
2008).
19
A IoT preenche um espao entre as necessidades decorrentes da evoluo do mercado,
das informaes, dos usurios e coisas pelo movimento em direo a um Framework comum
e que possibilite novos desafios, como a quantidade adicional de informao que pode ser
gerada e utilizada. Esse desafio de anlise de grandes quantidades de dados ter grandes
impactos no uso da IoT em novas reas como cidades inteligentes, transporte e muitas outras
que afetaro o futuro ecosistema global da Internet (SKARMETA, 2013).
Smith (2012), menciona que o gerenciamento de dados em IoT um aspecto crucial. Con-
siderando um mundo com objetos interconectados e constantemente trocando informaes
de todos os tipos, o volume de dados gerado e os processos envolvidos em gerenciar esses
dados crtico. H muitas tecnologias e fatores envolvidos no gerenciamento de dados no
contexto de IoT, dentre eles, os mais relevantes so: coleta e anlise de dados, Big Data,
redes de sensores semnticos, sensores virtuais ou processamento de eventos complexos.
No escopo da coleta e anlise de dados, h a rea de estrutura Multitenant, que destaca a
descentralizao, que necessita de diferentes componentes, distribuio geogrfica em dife-
rentes localizaes de modo a cooperar e trocar dados, funcionalidades de minerao de da-
dos, integrando capacidades para processamento de dados guardados, extraindo informaes
teis a partir do enorme conjunto de contedos armazenados (SMITH, 2012).
Bin, Yuan e Xiaoyi (2010) afirmam que a estratgia de enviar todos os dados capturados
a um n central em uma rede no otimiza o uso de energia eltrica e trfego de rede. As
caractersticas da IoT, como o grande volume de dados, informaes distribudas, relao de
tempo e localizao, a heterogeneidade entre os dispositivos e, em alguns casos, a limitao
de recursos nos dispositivos, destacam alguns problemas em uma arquitetura centralizada de
minerao de dados: (1) o grande volume de dados distribudos em diferentes localidades ou
sites, torna-se uma dificuldade na centralizao para processamento; (2) essa massa de dados
gerados na IoT necessita de processamento em tempo real, que em caso de processamento
centralizado requer alto desempenho do hardware; (3) consideraes de segurana e privaci-
dade, tolerncia a falhas, necessidades das empresas, ou atendimento s legislaes locais,
inviabilizam a arquitetura centralizada; (4) a limitao de recursos.
De acordo com Smith (2012) sero necessrios criar e prover servios capazes de pro-
cessar e analisar o massivo volume de dados gerados pela comunicao entre os diversos
dispositivos, usando interfaces abertas que permitam integrao simples entre vrias apli-
caes.
A partir dessas evidncias, destacam-se os conceitos pertinentes pesquisa e a direo de
pesquisa neste trabalho, relacionada ao tratamento de dados no modelo atual de IoT.
20
1.3 CONCEITOS IMPORTANTES
A Figura 1 ilustra o mapa conceitual elaborado para a pequisa. O mapa conceitual elenca
os principais conceitos pertinentes pesquisa, com o objetivo de aprofundar-se no conheci-
mento deles e estabelecer suas relaes.
Figura 1 - Mapa conceitual que destaca os conceitos pertinentes pesquisa.
Fonte: Elaborada pelo autor.
O modelo de referncia para IoT seguido no mapa conceitual apresenta as seguintes ca-
madas: aplicao, servios, middleware, comunicao e dispositivos; cada uma das camadas
possui um conjunto de tecnologias habilitadoras, foram citadas algumas e em paralelo a cada
camada, observa-se, com um papel fundamental, a segurana e o gerenciamento.
As camadas presentes no modelo utilizado desempenham funes especficas:
Camada de Dispositivos (entidades fsicas): que implementa a coleta de dados, atuao

no ambiente, comunicao e identificao das entidades fsicas.
21
Camada de Comunicao: que tem por funo habilitar a comunicao entre as enti-
dades fsicas e camadas superiores, requer protocolos de comunicao, como por exem-
plo, o Protocolo de Internet Verso 6 (IPv6), que devem acompanhar a evoluo das
redes de sensores e redes de sensores sem fio.
Camada de Middleware: que desempenha funes como gerenciamento, segurana e

contextualizao de dados, entidades ou servios, escalabilidade e facilidade de inte-
grao entre dispositivos heterogneos.
Camada de Servios: desempenha funes de gerenciamento de servios, segurana e

contextualazao dos servios, e podem ser implementadas sob um middleware.
Camada de Aplicao: representada por aplicaes pervasivas como, por exemplo,

aplicaes inteligentes em casas, automveis, cidades, transportes e objetos. Nessa
camada reside a inteligncia e tomada de deciso no contexto de IoT no modelo atual.
Os dados gerados na camada de entidades fsicas devem ser encaminhados uma apli-
cao, de acordo com o modelo em camadas proposto. Por sua vez, na aplicao, os dados
devero ser agregados a outros, processados e analisados, para que a aplicao possa tomar
uma deciso e executar aes no ambiente.
1.4 ESCOPO E OBJETIVOS DE PESQUISA
Esta seo tem por objetivo elencar o escopo e objetivos de pesquisa.
1.4.1 Escopo de pesquisa
No escopo da pesquisa, esto tpicos relacionados ao modelo de referncia em IoT e

arquitetura de referncia de IoT, a anlise e reconhecimento de padres, o processamento de
eventos complexos, sensores virtuais e tecnologia de big data.
No esto no escopo da tese, a identificao nica de objetos, protocolos de comunicao,
descrio de servios em IoT, segurana no modelo de IoT, redes de sensores, tecnologias
habilitadoras como: Radio Frequency Identification (RFID), cdigo de barras, Near Field
Communication (NFC), protocolo IPv6, cloud computing ou web semntica.
22
1.4.2 Objetivos de pesquisa
O principal objetivo de pesquisa : introduzir mecanismos de anlise e reconhecimento

de padres no modelo de IoT, com a abstrao e implementao de algoritmos para re-
conhecimento de padres como: algoritmos de agrupamento, que deste ponto em diante
optou-se por usar o termo em ingls clustering, estimao de valores e deteco de anoma-
lias, que deste ponto em diante optou-se por usar o termo em ingls outliers (SOUZA;
AMAZONAS, 2013). Assim, pode-se identificar os dados relevantes para anlises, prever
ou inferir sobre comportamentos humanos, sociais, animais, redes de comunicao, trnsito,
consumo, segurana, assistncia, automao, dentre inmeras outras funcionalidades men-
cionadas por Roussos (2011). Esses mecanismos de anlise e reconhecimento de padres
sero implementados em camadas inferiores do modelo, nas camadas de entidade fsica e
middleware/servios (SOUZA; AMAZONAS, 2013), conforme ilustrado na Figura 1. A im-
plementao na camada de entidade fsica ir especificar capacidades de deteco de outliers
e estimao de valores e na camada de middleware as capacidades da camada de entidade
fsica e mais o servio de clustering.
Como objetivos secundrios se tem:
1. Analisar os modelos de referncia em IoT, de modo a definir qual modelo ser utilizado
para o desenvolvimento de futuras aplicaes e experimentos na pesquisa.
2. Propor uma arquitetura para minerao e processamento distribudo de dados para a

IoT. E,
3. Propor e implementar a comunicao cross-layer, acrescentando ao modelo de arquite-

tura uma sub-camada para filtragem, minerao de dados ou estimao e introduzindo
flags que informem s camadas superiores ou aos prximos dispositivos, que ocorreram
pr-processamentos nos dados (minerao ou estimao de valores que por ventura no
tenham sido lidos). Dada a criticidade do domnio, essa pode ser uma informao im-
portante para a aplicao.
Na Figura 1 as linhas tracejadas ilustram as novas relaes entre os conceitos elencados

na pesquisa.
1.5 METODOLOGIA
A metodologia de pesquisa utilizada foi a exploratria, na qual deve-se fazer uma anlise
aprofundada do referencial terico e o posterior estudo experimental.
23
O seguinte conjunto de atividades foi desenvolvido no decorrer da pesquisa:
1. Especificao detalhada, modelagem e desenvolvimento do tema e soluo proposta.
2. Identificao e adequao do ambiente de testes e experimentaes.
3. Experimentao e anlise dos resultados.
Optou-se por fazer a anlise do referencial terico sobre IoT entre os anos de 2008 e 2015.
Como temas secundrios pesquisa foi feita a anlise de referencial terico das reas de
anlise e reconhecimento de padres e big data compreendendo essencialmente o perodo
entre os anos de 2001 e 2015.
A etapa seguinte consistiu em avaliar e estudar o material identificado, com o intuito de
criar uma base de conhecimento que possibilitasse o desenvolvimento dos objetivos propos-
tos. O desenvolvimento dos objetivos da pesquisa envolve atividades como, organizao das
informaes pesquisadas, especificao detalhada, modelagem e desenvolvimento do tema
proposto, testes e anlise dos resultados.
As etapas de especificao detalhada, modelagem e desenvolvimento do tema e soluo
proposta ocorreram entre Dezembro de 2013 e Junho de 2014. Foi desenvolvida a nova
arquitetura para IoT, com os servios de anlise e reconhecimento de padres nas camadas
fsica e de middleware do modelo de IoT, bem como sua modelagem orientada a objetos e a
comunicao cross-layer proposta.
Como cenrio experimental optou-se por utilizar o cenrio Smart Santander (KRCO et
al., 2012), que ser melhor descrito na Seo 4.1.1, esse projeto prope um cenrio expe-
rimental em larga escala, para o desenvolvimento e experimentao de aplicaes para IoT.
Os dados coletados foram inseridos em uma base de dados para posterior recuperao nos
experimentos desenvolvidos.
Para o desenvolvimento e experimentaes utilizou-se: sistema operacional Linux, lin-
guagem de programao Java, banco de dados Mysql e a plataforma para Big data Hadoop.
A etapa de experimentao e anlise dos resultados obtidos teve por objetivo avaliar se
os resultados e as concluses obtidos so consistentes ou de acordo com o esperado. Nessa
anlise, avaliou-se a necessidade de reviso dos conceitos utilizados, das hipteses assumidas
e dos desenvolvimentos propostos. Essa etapa ocorreu no perodo entre Julho e Setembro de
2014. Foram desenvolvidas aplicaes para experimentar a comunicao cross-layer, os
servios de reconhecimento de padres e a integrao com a arquitetura desenvolvida.
A elaborao de artigos para publicao em eventos internacionais consistiu em consolidar
os conceitos, resultados e contribuies obtidas com a pesquisa, em textos originais para
24
publicao em eventos e revistas internacionais. Essa atividade ocorreu no perodo entre
Outubro de 2014 e Abril de 2015.
A etapa final consistiu na elaborao do texto da tese, organizando todas as informaes
acumuladas nas etapas anteriores, alm das concluses e resultados obtidos. Essa etapa
ocorreu entre Abril e Agosto de 2015.
1.6 ORGANIZAO DO TRABALHO
Este trabalho organizado da seguinte maneira:

A Introduo apresentada neste captulo.
O Captulo 2 apresenta a fundamentao terica relacionada pesquisa, na qual so
definidos conceitos como IoT, os modelos de referncia do ITU-T e Internet of Things Ar-
chitecture (IoT-A), bem como a arquitetura de referncia proposta pelo IoT-A, middlewares
para IoT, tcnicas e algoritmos de anlise e reconhecimento de padres, como ocorre o trata-
mento de dados no modelo de IoT, quais tipos de dados e as tecnologias que permeiam seu
processamento.
O Captulo 3 apresenta a soluo proposta, mais especificamente, o detalhamento da im-
plementao da proposta de soluo e aspectos tcnicos.
O Captulo 4 traz as aplicaes desenvolvidas para experimentao e validao da arquite-
tura e algoritmos propostos.
Por fim, o Captulo 5 elenca as concluses de pesquisa e trabalhos futuros.
25
2 INTERNET DAS COISAS, RECONHECIMENTO DE PADRES E
BIG DATA
Este captulo est dividido da seguinte maneira: a Seo 2.1 tem por objetivo introduzir
conceitos relacionados Internet das Coisas; a Seo 2.2 descreve os modelos de referncia
e a arquitetura de refrencia para Internet das Coisas; a Seo 2.3 descreve a funo dos
middlewares de Internet das Coisas e mostra alguns mais relevantes para esta pesquisa; na
Seo 2.4 so mencionadas as tcnicas de anlise e reconhecimento de padres, como tcnica
de regresso, tcnicas de classificao e clustering e deteco de outliers; a Seo 2.5
mencionada a tecnologia de Big Data; a Seo 2.6 que ilustra o volume de dados gerados no
contexto de IoT e algumas tcnicas para seu gerenciamento; e, por fim, a Seo 2.7 com as
consideraes sobre o captulo.
2.1 INTERNET DAS COISAS
A IoT definida como uma infraestrutura de rede global, que interconecta fisicamente e
virtualmente objetos, com o objetivo de explorar dados capturados e suas capacidades de
comunicao. Essa infraestrutura inclui e envolve a Internet e as redes de comunicao, ela
necessita de identificao nica de objetos, sensores e capacidade de conexo, como base
para o desenvolvimento independente de servios e aplicaes. Ela caracterizada pelo
alto grau de captura autnoma de dados, transferncia de eventos de rede, conectividade e
interoperabilidade (CASAGRAS, 2009).
A Figura 2 ilustra a interao existente em qualquer implementao para IoT, que inclui a
interao entre as redes de comunicao, o mundo fsico e virtual, representado pela Inter-
net (CASAGRAS, 2009).
A IoT refere-se prxima gerao de Internet (BAHGA; MADISETTI, 2014), que pos-
suir trilhes de ns, representados por pequenos dispositivos ubquos ou embutidos nos
diversos ambientes, dotados de sensores, interconectados a servidores web, supercomputa-
dores ou clusters. Tecnologias como as redes de sensores, a identificao nica de objetos,
a comunicao mvel, a localizao em tempo real, a computao ubqua, o protocolo IPv6
integram essa nova infraestrutura de computao e comunicao.
Em (GREENGARD, 2015), o termo IoT refere-se no somente interconexo entre ob-
jetos do mundo real, mas, contextualizao de informaes referentes s coisas do mundo
real. A aplicao do termo Coisas, inclui objetos do mundo real que existem em grandes
quantidades e de diferentes tipos que possuiro uma identificao nica na Internet.
26
Figura 2 - Interao entre as redes de comunicao, o mundo fsico e o virtual.
Fonte: Adaptado de (CASAGRAS, 2009).
A Figura 3 ilustra o Modelo Inclusivo para a IoT, adaptado de (AMAZONAS, 2011) 1 .

A Figura 3 representa o processo de captura e processamento de dados em IoT, que ocorre
da seguinte maneira: os dados gerados pelos objetos fsicos so lidos pelo dispositivo in-
terrogador, tambm designado como gateway. Esses dados so enviados ao sistema de ge-
renciamento de informao, a partir desse, usando a Internet ou outras tecnologias de rede,
so obtidos outros dados associados aos objetos ou aos prprios dados iniciais. O resultado
do processamento por uma aplicao ou servio uma atuao no ambiente em que esto
presentes os objetos e/ou uma atuao sobre eles (CASAGRAS, 2009).
Conforme se observa em CASAGRAS (2009), so propostas trs classes de dispositivos
para IoT:
1. Objetos puramente passivos com identificao e dados fixos, so objetos presentes na

Physical Interface Zone, na parte superior da Figura 3.
2. Objetos dotados de moderado poder computacional e percepo de contexto, que por

meio de sensores podem gerar mensagens e variar a informao associadas a eles de
acordo com o tempo e lugar, representados pelos objetos presentes na Physical Interface
Zone, mais ao centro da Figura 3.
3. Objetos que possuem conectividade em rede, sem a interveno humana, possibilitando

a emergncia de inteligncia nos sistemas de rede, representados pelos objetos presentes
na Physical Interface Zone, na parte inferior da Figura 3.
1
Optou-se por manter as imagens com textos e nomenclaturas em ingls, tendo em vista serem reprodues
de artigos publicados em eventos internacionais.
27
Figura 3 - Modelo Inclusivo para a IoT.
Interrogator/ Host information

gateway device management
system
ID and additional
item attendant data Actuators
Wider area
communications
Physical interface zone
and networks

gateway management
device system
Actuators Internet+
Sensory data carriers
Actuators

gateway management
device system
Networked data carriers Further layers of data capture technology
Fonte: Adaptado de (AMAZONAS, 2011).
O modelo ilustrado pela Figura 3 pode ser exemplificado atravs de um processo baseado
em IoT (HUANG; LI, 2010). No dado processo um objeto do mundo real possui uma
informao, por exemplo, dentro de uma tarja eletrnica. A informao resgatada por meio
de um interrogador, que pode estar conectado a um servio ou aplicao, na qual usurios ou
aplicaes, que esto no mundo real, podero ler ou compartilhar a informao do objeto em
tempo real. Por fim, esta aplicao pode atuar no ambiente, por meio dos atuadores presentes
em objetos (AMAZONAS, 2011). Cabe ressaltar que a tarja eletrnica pode ser substituda
por outras tecnologias de identificao nica, ou seja, no se restringe tecnologia de RFID.
2.2 MODELOS DE REFERNCIA PARA IOT
Um modelo de referncia uma estrutura para entendimento de relacionamentos entre en-

tidades em um dado domnio, para se desenvolver padres ou especificaes consistentes de
suporte. Um modelo de referncia baseado no conjunto dos principais conceitos, abstra-
es, suas interaes, suas interfaces com ambientes externos que podem ser usados como
base para entendimento do dado domnio (COMER, 2015).
Uma arquitetura de referncia serve como base para a construo e projeto de arquiteturas
28
coerentes com o domnio de aplicao e baseada num modelo de referncia. Esta seo
descreve dois modelos de referncia para arquiteturas de IoT.
2.2.1 Modelo de referncia ITU-T
Esta seo descreve o modelo de referncia proposto pelo ITU-T em ITU-T (2012), as
funes propostas para as camadas e uma breve descrio do ecosistema de IoT proposto.
De acordo com a ITU-T (2012), a IoT refere-se a uma infraestrutura global de informao.
Ela envolve servios avanados pela interconexo fsica e virtual de coisas, baseando-se
na interoperabilidade das informaes e protocolos de comunicao. As coisas podem ser
quaisquer objetos do mundo fsico ou informao do mundo virtual, que possam ser identi-
ficados e integrados s redes de comunicao.
A Figura 4 ilustra o modelo de referncia ITU-T para IoT. Ele composto por 4 camadas,
que possuem capacidades de gerenciamento de funcionalidades e segurana, para se acessar
suas funcionalidades.
Figura 4 - Modelo de Referncia para IoT proposto pelo ITU-T.
Fonte: (ITU-T, 2012).
Segue a descrio detalhada de cada uma das 4 camadas:
Application Layer: contm as aplicaes para IoT.
Service Support and Application Support layer: consiste em dois grupos de funcionali-
dades:
29
Generic Support Capabilities: so as funcionalidades comuns que podem ser
usadas por diferentes aplicaes de IoT como, por exemplo, processamento e
armazenamento de dados. Essas funcionalidades podem ser iniciadas pelas fun-
cionalidades especficas de suporte de modo a as compor.
Specific Support Capabilities: essas funcionalidades so especficas de cada tipo

de aplicao de IoT. Elas consistem em agrupamentos de detalhes de implemen-
tao, que proveem diferentes suportes para os diferentes tipos de aplicaes de
IoT.
Network Layer: suas funes no so anlogas s da camada de rede e transporte

presentes no modelo de referncia Open Systems Interconnection (OSI). Essa camada
prov dois tipos de funcionalidades:
Networking Capabilities: prov controles de funes de conectividade, como

funes de acesso e controle de transporte, gerenciamento mvel de contas, au-
tenticao e autorizao (Authentication, Authorization, Accounting, and Audit-
ing (AAAA)).
Transport Capabilities: prov conectividade para o transporte de servios de IoT,

dados e informaes de aplicaes especficas, bem como o controle de transporte
e o gerenciamento relacionado IoT.
Device Layer: a camada de dispositivo pode ser dividida logicamente em dois tipos de
funcionalidades:
Device Capabilities: as funcionalidades de dispositivos incluem, mas no esto

limitadas a:
1. Interao direta com comunicao de rede: dispositivos que renem e

submetem informaes diretamente, ou seja, sem usar funcionalidades
de gateway para a comunicao de rede. Eles tambm podem receber
informaes, ou comandos, a partir dessa comunicao de rede.
2. Interao indireta com comunicao de rede: dispositivos que renem e
submetem informao indiretamente pela rede, ou seja, usam as funcio-
nalidades dos dispositivos gateway, por outro lado, so dispositivos que
podem, indiretamente, receber informaes, ou comandos, a partir da co-
municao de rede.
3. Redes Ad-hoc: dispositivos que podem construir redes ad-hoc em diver-
sos cenrios que necessitam de escalabilidade e rpido desenvolvimento.
30
4. Hibernados: dispositivos que possuem mecanismos de hibernao e aciona-
mento para economia de energia. O suporte s funcionalidades desse
dispositivo pode ser direto ou indireto e a comunicao por rede no
obrigatria.
Gateway Capabilities: as funcionalidades de gateway incluem, mas no se limi-

tam a:
1. Suporte a mltiplas interfaces: na camada de dispositivo as funcionali-

dades de gateway suportam dispositivos conectados a partir de diferentes
tecnologias com cabos ou sem fio, como redes Controler Area Network
(CAN) bus, ZigBee, Bluetooth ou Wireless Fidelity (Wi-Fi). Assim como
na camada de rede, as funcionalidades de gateway podero permitir comu-
nicao entre vrias tecnologias, como redes de telefonia Public Switched
Telephone Network (PSTN), redes de Segunda Gerao (2G) ou de Ter-
ceira Gerao (3G), Long-Term Evolution Networks (LTE), redes Ethernet
ou redes Digital Subscriber Line (DSL).
2. Converso de protocolos: h duas situaes onde essas funcionalidades
so necessrias, quando ocorrem comunicaes na camada de disposi-
tivo, que usam diferentes protocolos, por exemplo, protocolo ZigBee e
Bluetooth e quando ocorrem comunicaes envolvendo ambas as camadas
de dispositivo e de rede, usando diferentes protocolos, como por exemplo,
protocolo ZigBee na camada de dispositivo e tecnologia 3G como camada
de rede.
2.2.1.1 Funcionalidades de gerenciamento
As funcionalidades de gerenciamento em IoT incluem gerenciamento baseado nas catego-

rias Fault, Configuration, Accounting, Performance, Security (FCAPS) (ITU-T, 2012).
As funcionalidades de gerenciamento podem ser categorizadas em funcionalidades de ge-
renciamento genricas e especficas.
As funcionalidades de gerenciamento genricas em IoT incluem:
Gerenciamento remoto de dispositivos, como ativao ou desativao, diagnsticos,

atualizao de firmware ou software ou gerencimento de status de dispositivos.
Gerenciamento de topologia local.
Gerenciamento de trfego e congestionamento, como deteco de perda de pacotes e a

31
implementao de reserva de recursos para fluxos de informao sensveis ao tempo ou
ao ciclo de vida.
As funcionalidades de gerenciamento especficas so acopladas aos requisitos especficos

da aplicao, como requisitos de monitoramento de linhas de transmisso em smart grid.
2.2.1.2 Funcionalidades de segurana
H dois tipos de funcionalidades de segurana: funcionalidades genricas e especficas.

As funcionalidades de segurana genricas so independentes de aplicao e incluem:
Na camada de aplicao: autorizao, autenticao, proteo de confidencialidade e

integridade da aplicao, proteo de privacidade, auditoria e antivirus.
Na camada de rede: autorizao, autenticao, uso dos dados e sinalizao de confiden-

cialidade e sinalizao de proteo de integridade.
Na camada de dispositivo: autenticao, autorizao, validao de integridade de dis-

positivo, controle de acesso, confidencialidade de dados e proteo de integridade.
As funcionalidades de segurana especficas so acopladas aos requisitos especficos da

aplicao, por exemplo, tarifaes mveis ou necessidades de controle de acesso.
2.2.1.3 Ecossitema da IoT
De acordo com ITU-T (2012), o ecossitema de IoT composto por uma variedade de
atores de negcio. Cada um desses atores possui um papel, os papis so ilustrados pela
Figura 5.
A Figura 5 ilustra os papis de negcios presentes no ecossitema de IoT e o relacionamento
entre eles. Segue uma pequena descrio de cada um dos papis.
Device provider
O provedor de dispositivo responsvel por fornecer os dados brutos ou o contedo para

o provedor de rede e provedor de aplicao, de acordo com a lgica de negcio.
Network provider
O provedor de rede possui o papel central no ecossitema de IoT. Ele possui as seguintes
funes principais:
Acesso e integrao de recursos providos por outros provedores.

32
Figura 5 - Modelo de Ecossitema para IoT, proposto pelo ITU-T.
Fonte: (ITU-T, 2012).
Suporte e controle das capacidades de infraestrutura de IoT.
Oferecer capacidades de IoT, incluindo capacidades de rede e exposio de recursos

para outros provedores.
Platform provider
O provedor de plataforma fornece capacidades de integrao e interfaces abertas. Di-

ferentes plataformas podem oferecer diferentes capacidades para provedores de aplicao.
Capacidades de plataforma incluem tipicamente capacidades de integrao, como por exem-
plo, armazenamento de dados, processamento de dados ou gerenciamento de dispositivos e
suporte para diferentes tipos de aplicaes de IoT.
Application provider
O provedor de aplicao fornece e utiliza capacidades ou recursos providos por provedores

de rede, de dispositivos e de plataformas, de modo a prover aplicaes de IoT para aplicaes
clientes.
Application customer
A aplicao cliente o usurio das aplicaes de IoT fornecidas pelos provedores de apli-
cao. Nesse caso, uma aplicao cliente pode representar mltiplas aplicaes de usurio.
2.2.2 Modelo IoT-A
Confome se observa em Joachim e Walewski (2012), o Modelo de Referncia para IoT

prov um alto nvel de abstrao para a definio da Arquitetura de Referncia. Ele promove
33
um entendimento comum do domnio de IoT. A descrio do modelo de referncia inclui
um discurso geral sobre o domnio de IoT, um modelo de domnio como um alto nvel de
descrio, um modelo de informao que mostra como o conhecimento de IoT modelado
e um modelo de comunicao, de modo a descrever a interao entre objetos inteligentes.
A arquitetura de referncia para IoT utilizada para construo de arquiteturas para
IoT. Ela prov vises e perspectivas sobre diferentes aspectos de arquitetura respeitando
definies, implementaes e padres j existentes.
A Figura 6, ilustra as entradas e dependncias entre o modelo de referncia para IoT e a
arquitetura de referncia para a IoT.
Figura 6 - Alto nvel de taxonomia, influncias e dependncias entre o modelo de referncia para IoT e a
arquitetura de referncia para IoT.
Fonte: (JOACHIM; WALEWSKI, 2012).
De acordo com a Figura 6, o modelo de referncia para IoT prov um guia para a descri-
o da arquitetura de referncia para a IoT. Observa-se que o modelo de referncia deve ser
cunhado a partir das expectativas das partes interessadas, de cenrios de negcio e arquite-
turas existentes, de modo a criar um entendimento comum sobre o domnio de IoT. A partir
desse entendimento, so definidos os principais requisitos de aplicao, que posteriormente
definiro a arquitetura de referncia para IoT.
Joachim e Walewski (2012) mencionam que o modelo do IoT-A composto por um mo-
delo de referncia para IoT e uma arquitetura de referncia, melhores descritos em 2.2.3 e
2.2.4, respectivamente.
2.2.3 Modelo de referncia IoT-A
O modelo de referncia consiste em uma srie de submodelos, que compem um conjunto

com importantes aspectos de projeto para IoT. O mais importante o Modelo de Domnio,
34
que descreve todos os conceitos relevantes para a IoT. Os outros modelos e Arquitetura
de Referncia so baseados nos conceitos introduzidos no Modelo de Domnio. O modelo
de referncia tem o objetivo de definir uma base e linguagem comum para arquiteturas e
sistemas de IoT. A Figura 7 ilustra as interaes e os submodelos propostos.
Figura 7 - Interaes entre os sub-modelos do modelo de referncia para IoT.
Fonte: Adaptada de (JOACHIM; WALEWSKI, 2012).
O Modelo de Domnio introduz os principais conceitos da IoT, como dispositivos, servios

e entidades virtuais e as relaes entre eles. Esse nvel de abstrao independente de
tecnologia e so casos de uso e requisitos invariantes no tempo.
O Modelo de Informao foi desenvolvido baseado no modelo de domnio. Ele possui
uma estrutura (por exemplo, relacionamentos e atributos) que contm todas as informaes
(dados) que so manipuladas em um sistema de IoT, em um nvel conceitual, sem discutir
como ele dever ser representado. Sendo assim, as informaes pertinentes aos conceitos
do Modelo de Domnio so modeladas. As informaes sobre os dispositivos, servios ou
entidades virtuais so explicitamente resgatadas, armazenadas e processadas em um sistema
de IoT.
O Modelo Funcional identifica grupos de funcionalidades que dizem respeito, em muitos
casos, aos principais conceitos do Modelo de Domnio. Esses Grupos Funcionais (FG) so
construdos de forma hierrquica. Um grupo funcional prov as funcionalidades para inte-
rao com as instncias desses conceitos ou gerencia as informaes relacionadas aos con-
ceitos. As funcionalidades de gerenciamento de informao usam o modelo de Informao
de IoT como a base para estruturar suas informaes.
A funcionalidade principal em qualquer sistema computacional distribudo a comuni-
cao entre os diferentes componentes, especificamente para um sistema de IoT a hetero-
35
geneidade de tecnologias de comunicao necessrias. O modelo de comunicao introduz
conceitos para a complexa manipulao da comunicao em ambientes de IoT heterogneos.
A comunicao constitui um grupo funcional no Modelo Funcional.
A segurana e privacidade so de suma importncia em ambientes tpicos de IoT, as fun-
cionalidades relevantes e suas interdependncias e interaes so introduzidas no Modelo de
Segurana. Como no caso da comunicao, a segurana constitui um grupo funcional no
modelo funcional.
2.2.4 Arquitetura de referncia IoT-A
A arquitetura de referncia utilizada para a construo de arquiteturas de IoT, que pos-

suem necessidades especficas. Essa arquitetura segue uma abordagem de vises e perspec-
tivas e aborda os seguintes questionamentos: (1) elementos funcionais; (2) interao entre os
elementos; (3) gerenciamento de informao; (4) caractersticas operacionais; e (5) desen-
volvimento do sistema.
A Arquitetura de Referncia IoT-A prope as seguintes vises: Viso Funcional, Viso de
Informao e Viso de Desenvolvimento e Operao.
2.2.4.1 Viso funcional
A viso funcional definida pela aplicao da decomposio funcional, conforme o ilustrado

pela Figura 8.
Figura 8 - Interaes entre o modelo funcional e requisitos uificados e a viso funcional.
No primeiro passo, os requisitos so mapeados para diferentes grupos de funcionalidades

do modelo funcional. No prximo passo, os requisitos com funcionalidades semelhantes so
36
agrupados e os componentes funcionais so definidos para esses requisitos. Por fim, aps
discusses tcnicas, os componentes funcionais so refinados.
Os pontos de vista usados para a construo funcional so: (1) Requisitos Unificados e (2)
Modelo Funcional.
Todos os componentes funcionais so definidos atravs de diagramas de casos de uso, de
sequncia e definio de interfaces. O diagrama com os grupos funcionais esto ilustrados
na Figura 9.
Figura 9 - Grupos de funcionais do Modelo Funcional para IoT.
Fonte: Adaptada de (JOACHIM; WALEWSKI, 2012).
Conforme se observa na Figura 9, o diagrama funcional exibe 9 grupos funcionais do

Modelo Funcional:
Grupos funcionais de Aplicao e de Dispositivos: que esto fora do escopo da Ar-

quitetura de Referncia de IoT e esto coloridos em laranja e marcados com o nmero
1.
Grupos funcionais de Gerenciamento e de Segurana: so grupos de funcionalidades

transversais e esto coloridos em azul e marcados com o nmero 2.
Observa-se que, para cada grupo funcional h componentes funcionais especificados.

37
2.2.4.2 Viso de informao
Uma das principais propostas de conexes e objetos inteligentes em IoT a troca de infor-
maes entre cada objeto com os sistemas externos. Sendo assim, a maneira como definir,
estruturar, armazenar, processar, gerenciar e trocar as informaes de extrema importncia.
A viso de informao prov uma viso geral sobre estruturas de informaes estticas e
fluxos de informaes dinmicos.
Baseado no Modelo de Informao de IoT, essa viso deve detalhar como as informaes
relevantes devem ser representadas em um sistema de IoT. A descrio da arquitetura pro-
posta em Joachim e Walewski (2012), se ope s arquiteturas de sistemas especficos, vrias
alternativas so discutidas dentro do modelo de informao. O modelo descreve compo-
nentes que manipulam informaes, fluxos e o seu ciclo de vida nos sistemas de IoT.
O foco da Viso de Informao so as descries, a manipulao e o ciclo de vida das
informaes, mas ela fornece tambm detalhes sobre o fluxo de informao entre os sistemas
e componentes envolvidos.
2.2.4.3 Viso de desenvolvimento e operao
A viso de desenvolvimento e operao tem por objetivo prover, aos usurios do modelo
de referncia IoT-A, um conjunto de manuais, de modo a gui-los entre os diferentes projetos
e escolhas. Para isso, essa viso discute, a partir de descries de servios e identificaes de
diferentes elementos funcionais, a seleo de inmeras tecnologias disponveis em IoT para
a construo e desenvolvimento de aplicaes (JOACHIM; WALEWSKI, 2012).
A Figura 10 ilustra as categorias criadas sob a perspectiva de desenvolvimento para IoT.
Foram identificadas as categorias que tm impacto no desenvolvimento e realizao de
sistemas de IoT. Iniciando pelo modelo de domnio, so definidos trs grupos principais de
elementos: dispositivos, recursos e servios, destacados respectivamente com os nmeros 1,
2 e 3. Cada um dos grupos aborda diferentes problemas de desenvolvimento e se reflete em
capacidades operacionais do sistema.
Os pontos de vista usados no desenvolvimento e operao so:
1. O diagrama do modelo de domnio usado como um guia para descrever domnios de

aplicao especficos. A extenso de diagramas UML pode ser usada para detalhar a
interao entre os vrios elementos que iro compor a aplicao.
2. O Modelo Funcional usado como uma referncia para a definio do sistema. Ele
define grupos funcionais como servios de IoT e conectividade, que so fundamentais
38
Figura 10 - Categorias que impactam no desenvolvimento para IoT.
para a correta definio do sistema.
3. Os diagramas de conectividade de rede podem ser usados para planejar a topologia de

conectividade, de modo a implementar as capacidades de redes desejadas pelo objetivo
de aplicao. No nvel de desenvolvimento, o diagrama de conectividade pode ser usado
para definir hierarquias e os tipos de sub-redes que comporo o sistema completo de
rede de comunicao.
4. Descries dos dispositivos, como especificaes tcnicas e manuais de usurio, podem

ser usados como um mapeamento de hardware, servios e recursos sobre os requisitos
de sistema. Os dispositivos em requisitos de sistemas de IoT incluem todo espectro
de tecnologias, que vo desde simples tarjas de radiofrequncia at especificaes de
39
servidores. Essas unificaes de caractersticas principais so duas: (i) cada dispositivo
conectado com um outro formando uma parte da IoT; e, (ii) cada dispositivo in-
teligente, cada um possui um grau de complexidade, e isso provido por capacidades
computacionais. Essas duas caractersticas so as primeiras escolhas que o projetista
deve fazer. Um dado dispositivo ser completamente interopervel em um sistema de
IoT se ele respeitar as definies do Modelo Funcional. Sendo assim, para sistemas
legados que no so completamente suportados pelo modelo funcional, podero ser im-
plementados pacotes ou adaptaes de software para a compatibilidade com modelo. A
seleo da complexidade computacional para um dado dispositivo intrinseca ao obje-
tivo de aplicao. Desse modo, escolher entre diferentes tipos de conectividade no
escolher comparando apenas vantagens, mas tambm em diferentes reas. possvel
criar diferentes sistemas implementando as mesmas aplicaes ou similares a partir da
viso funcional e que sejam extremamente diferentes a partir da viso de desenvolvi-
mento e operao.
Sob o ponto de vista de escolhas de implementao importante discutir os seguintes

aspectos de conectividade:
1. Redes de sensores e atuadores.
2. RFIDs e tarjas inteligentes.
3. Wi-Fi ou outras tecnologias.
4. Redes de equipamentos mveis.
Como uma consequncia da coexistncia de diferentes tecnologias de comunicao em um

mesmo sistema, a segunda escolha de um projetista de sistema est relacionada a protocolos
de comunicao. As funcionalidades de conectividade nos sistemas de IoT so definidas
no documento de Grupos de Funcionalidades de Comunicao no Modelo Funcional. So
identificadas as seguintes possibilidades:
1. Sute de protocolos de IoT: essa a principal alternativa suportada por um projeto e

prov a melhor soluo para interoperabilidade.
2. Solues proprietrias Ad-hoc: sempre que requisitos de desempenho sejam mais im-
portantes que a versatilidade do sistema, solues Ad-hoc so um bom caminho.
3. Outros padres: dependendo do objetivo do domnio de aplicao ou regulamentaes,

o projetista dever adotar solues a partir de sugestes da suite de protocolos de IoT
ou solues adotadas em projetos anteriores.
40
Depois de selecionar os dispositivos e os mtodos de comunicao, o projetista deve
definir os recursos e servios. Essas so as peas de software que vo desde uma sim-
ples aplicao binria aumentando sua complexidade at se chegar, por exemplo, em um
complexo software de controle. O ponto principal escolher onde implantar o software
relacionado a um determinado dispositivo. As opes so:
1. Nos objetos inteligentes: essa escolha se aplica definio de recursos e servios sim-
ples, como um web-service que pode ser realizado com poucas dezenas ou centenas de
bytes.
2. Nos gateways: sempre que um dispositivo no puder executar funes necessrias, os

gateways ou outros dispositivos com maior capacidade podero suprir essa necessidade.
3. Na nuvem: os softwares podero ser implantados na nuvem. Essa soluo prov maior
disponibilidade para os servios, mas poder reduzir o desempenho, em termos de latn-
cia e fluxo de dados.
Essas escolhas podem ser feitas dependendo do tipo de dispositivo e servio.

importante tambm selecionar o tipo de tecnologia para coleta de informao pelo sis-
tema, se as informaes so unicamente providas por sensores, ou tambm por usurios.
Nesse caso, o projetista dever levar em considerao se so dados ou informaes sensveis
(por exemplo, se a segurana provida pelo dispositivo ou por um Framework), qual o
grau de disponibilidade, redundncia e resilincia. Algumas das opes so:
1. Somente local: os dados so armazenados somente em dispositivos que provm servios.

Nesse caso o sistema no necessita da complexidade de bases distribudas, mas depen-
dendo da localizao de uma requisio a resposta poder demorar e em alguns casos
at se perder.
2. Somente na Web: no so mantidas cpias nos dispositivos locais. Os dados so envia-

dos para um agregador e esses so despachados para bancos de dados.
3. Armazenamento local e em caches na Web: uma estrutura hierrquica para o armazena-

mento dos dados mantida a partir de dispositivos e de servidores.
Uma das caractersticas principais de sistemas para IoT a resoluo de servios e en-
tidades, que so providas por capacidades funcionais. Essa uma considervel carga de
requisies semnticas de recursos e servios, descoberta de novos elementos, ligaes entre
usurios e dados e recursos e servios. Em particular, isso pode ser implementado a partir da
utilizao de definies de entidades virtuais. H duas escolhas para o projetista:
41
1. Desenvolvimento interno: a parte principal instalada em servidores ao longo do sis-
tema e esses so dedicados aplicao ou compartilhados entre diferentes aplicaes
do mesmo provedor.
2. Desenvolvimento externo: a parte principal provida por uma terceira parte, o projetista
tem um conjunto de Application Program Interface (API) para o desenvolvimento.
Diferentemente de outras escolhas, essa est associada ao custo de manuteno da parte

principal do software. De fato, isto pode ser um componente crtico do sistema, como re-
quisitos de segurana, disponibilidade e robustez, mas para empresas menores as solues
externas podem ser mais viveis.
2.3 MIDDLEWARE DE INTERNET DAS COISAS
Segundo Kjaer (2005), existem diversos Middlewares de software, cuja definio um

sistema de software que prov uma camada de abstrao entre o sistema operacional e as
aplicaes em execuo, para o desenvolvimento de aplicaes no contexto de computao
pervasiva, cujo foco prover uma suite abstrada e usual para a heterogeneidade de disposi-
tivos e contextos de informao.
Em Kjaer (2005), Bandyopadhyay et al. (2011)b e Bandyopadhyay et al. (2011)a su-
gerida uma taxonomia que classifica os diversos contextware middlewares de acordo com
suas caractersticas. Alguns middlewares, representativos do estado da arte, que suportam
computao pervasiva e mvel baseada em contexto de informao so:
1. ISMB (SIMONOV, 2010).
2. Advanced Sensors and lightweight Programmable middleware for Innovative Rfid En-
terprise applications (ASPIRE) (GRANELLI et al., 2009).
3. Smart Semantic Middleware for Ubiquitous Computing (UBIWARE) (KATASONOV

et al., 2008).
4. UBISOAP (CAPORUSCIO; RAVERDY; ISSARNY, 2012).
5. UBIROAD (TERZIYAN; KAYKOVA; ZHOVTOBRYUKH, 2010).
6. Global Sensor Network (GSN) (SALEHI, 2010).
7. Secure Middleware For Embedded P2P (SMEPP) (ALBANO et al., 2007).
8. SOCRADES (CANNATA; GEROSA; TAISCH, 2008).

42
9. Service Infrastructure for Real-time Embedded Networked Devices (SIRENA) (BOHN;
BOBEK; GOLATOWSKI, 2006).
10. WHEREX (PULIAFITO et al., 2010).
11. Ubidots (UBIDOTS, 2014).
Os middlewares proveem diferentes mtodos de adaptao, coleta e mudanas de contexto,

embora possuam diferentes objetivos.
Alm dos middlwares citados, destaca-se o projeto Network Embeded System Middleware
Heterogeneous Physical Devices in a Distribued Architecture (HYDRA) desenvolvido no
mbito do Sixth Research Framework Programme (FP6) (PEREIRA; EISENHAUER, 2011)
e que ser descrito na Seo 2.3.1.
2.3.1 Projeto Hydra
O primeiro objetivo do projeto Hydra foi desenvolver um middleware de software baseado

em Service-oriented Architecture (SOA), no qual a comunicao entre as camadas inferiores
ocorre de forma transparente (PEREIRA; EISENHAUER, 2011).
O framework suporta arquiteturas distribudas ou centralizadas, segurana e confiana e
modelos de desenvolvimento de aplicaes baseados em model-driven. O desenvolvimento
do framework teve como premissa a aplicabilidade nas redes atuais e tambm nos novos
modelos de rede, com dispositivos interconectados, que dispem recursos computacionais,
energia e capacidade de memria reduzidos.
Os sistemas embarcados e a arquitetura orientada a servio mvel permitem a interopera-
bilidade de acesso a dados, informaes ou conhecimento entre plataformas heterogneas,
incluindo servios web e suporte a ambientes inteligentes para redes de dispositivos ubquos.
O segundo objetivo do projeto Hydra foi desenvolver um Software Development Kit (SDK)
que usado para o desenvolvimento de novas aplicaes e de cdigos que possam ser exe-
cutados em novos dispositivos.
Em Sarnovsky et al. (2008), so elencados dois tipos diferentes de usurios, desenvolve-
dores e usurios finais. Uma das primeiras tarefas do projeto HYDRA foi criar cenrios que
permitissem observar o comportamento de usurios finais e interao com as funcionalida-
des da plataforma em trs diferentes domnios: automao, aplicao mdica e agricultura.
Esses cenrios provm coerncia, compreenso e descries consistentes e plausveis sobre
as possveis interaes entre as principais funcionalidades imaginadas.
O objeto resultante desse projeto foi o chamado LinkSmart middleware, nome que ser
utilizado para se referir ao middleware de software desenvolvido deste ponto em diante.
43
A estrutura funcional do modelo proposto pelo projeto HYDRA dividida em duas partes:
elementos de aplicao e elementos de dispositivos. Esses elementos diferem nos seguintes
aspectos:
1. Poder computacional.
2. Propsito do componente.
3. Usurio desenvolvedor.
Os elementos de aplicao descrevem componentes que sero desenvolvidos para hard-

ware com maior capacidade de processamento e energia. Esses elementos estaro ligados a
aplicaes especficas que compem os sistemas de automao.
Os elementos de dispositivos descrevem componentes desenvolvidos baseados no Link-
Smart middleware e sero executados em pequenos dispositivos que possuem recursos e
energia limitados (SARNOVSKY et al., 2008).
A Figura 11 ilustra a estrutura em camadas do LinkSmart middleware.
Na Figura 11, os elementos do LinkSmart middleware esto entre as camadas sistema
operacional e de aplicao, exibidos no diagrama. A camada fsica est relacionada comu-
nicao de rede, enquanto a camada de aplicao contm mdulos relacionados ao geren-
ciamento do fluxo de informao, interface com o usurio, lgica da aplicao e detalhes de
configurao. Entre as duas camadas, encontra-se o LinkSmart middleware, composto por
trs sub-camadas, de rede, de servio e semntica (SARNOVSKY et al., 2008).
O LinkSmart baseia-se na arquitetura Open Services Gateway Initiative (OSGI) (BAKKER;
ERTMAN, 2013), ou seja, disponibiliza seus servios nesta especificao e, todo e qualquer
cliente que venha a se conectar dever implementar um WebSerivce Client na especificao
AXIS (JAYASINGHE; AZEEZ, 2011). A Figura 12 ilustra a arquitetura base para o desen-
volvimento de aplicaes ou servios baseando-se no LinkSmart.
Na Figura 12 se v uma camada inferior que representa a camada fsica, que deve imple-
mentar ou ter um Gateway como cliente WebService com a especificao OSGI/AXIS para
inserir dados no LinkSmart. Na camada central se encontra o LinkSmart Middeware que
prov alguns servios do modelo e, na camada superior, a aplicao que tambm deve im-
plementar ou possuir um Gateway como cliente WebSerivce na especificao OSGI/AXIS.
Os servios implementados pelo LinkSmart (LANG, 2015) mais relevantes para esta
pesquisa so:
NetworkManager: prov maneiras de registro de clientes ou servios e busca de servios

dentro do LinkSmart. Ele pode ser usado para comunicao entre dois ns de LinkSmart,
para o envio de mensagens e abstrao dos mtodos de comunicao e rede.
44
Figura 11 - Estrutura em camadas do LinkSmart middleware.
Fonte: Adaptada de (SARNOVSKY et al., 2008).
SecuritiryManager: prov servios para operaes com criptografia, gerenciamento de

chaves e certificados de segurana e conexo confivel ao Middeware.
EventManager: esse servio implementa o padro de projetos Observer (GAMMA et

al., 2006), ou seja, implementa uma arquitetura de barramento com publish-subscriber.
Esse servio prov a escalabilidade para um sensor, onde, uma nica leitura proveniente
de sensor com baixo ou nenhum poder computacional pode ser lida ou requisitada por
uma quantidade escalvel de clientes, atravs do barramento implementado por ele.
Cabe destacar a modularizao e independncia entre os servios implementados pelo

LinkSmart, pois se baseia na arquitetura OSGI.
45
Figura 12 - Arquitetura ilustrativa para o desenvolvimento de servios e aplicaes baseadas no LinkSmart.
2.3.2 Projeto Ubidots
O projeto Ubidots proveniente de uma startup promovida pelo alumni of MassChallenge

Accelerator 13 (Boston, MA) (UBIDOTS, 2014). Seu objetivo prover um Framework
para auxlio no desenvolvimento de aplicaes para a captura de dados do mundo real e sua
disponibilizao para aplicaes reais.
Desenvolvedores podem utilizar a API Ubidots para conectar dispositivos plataforma
e ter seus dados disponveis na WEB para visualizao em tempo real. Alguns conceitos
importantes no contexto de desenvolvimento de aplicativos com Ubidots so (UBIDOTS,
2014):
Data Source: trata-se de um dispositivo conectado plataforma. Um Data Source pode

conter uma ou mais variveis, cada uma contendo valores em uma srie temporal, por
exemplo, uma srie temporal com valores de temperatura e luminosidade.
Varivel: uma srie de valores resgatados ao longo do tempo, por exemplo, srie
temporal da temperatura de uma sala.
Valor: uma medida da varivel em um dado ponto no tempo, por exemplo, o valor de
25 graus celsius de uma sala s 15:35.
Evento: uma condio definida que desencadear uma ao por parte da plataforma,
por exemplo, sempre que a temperatura da sala atingir 30 graus celsius a plataforma
46
enviar uma mensagem de Short Message Service (SMS) pelo servio de telefonia, de
modo a alertar dada a medio.
Widget: so visualizaes customizadas dos dados no portal da plataforma Ubidots, por

exemplo, um grfico personalizado com a variao da temperatura da sala nas ltimas
horas.
A Figura 13 ilustra o fluxo de dados com a plataforma Ubidots.

Figura 13 - Fluxo de dados com a plataforma Ubidots (UBIDOTS, 2014).
Fonte: (UBIDOTS, 2014).
O sensor ou o gateway envia os dados para a plataforma, que por sua vez, pode disparar
uma ao, exibir a srie de dados num Widget ou disponibilizar os dados para uma aplicao
cliente qualquer.
Atravs do portal da plataforma pode-se criar eventos ao selecionar uma varivel e com-
parar com um dado valor, com os operadores >, >=, <, <=, =, por exemplo, criar um evento
sempre que a temperatura for maior ou igual a 30. Os eventos podem disparar um acesso
URL, envio de SMS, envio de email ou insero de valor em outra varivel.
Os widgets podem ser criados atravs do portal escolhendo o tipo de grfico e selecionando
as variveis que se deseja. Os tipos de widgets que podem ser selecionandos na plataforma
so: lista ou tabela de valores, grfico de linha com uma ou mais variveis, exibir o ltimo
valor da varivel, grfico de disperso com uma ou mais variveis, exibio de ponto no
mapa, caminho no mapa, indicador ou medio em escala.
Na Figura 14 so ilustrados dois widgets, esquerda, que exibe a varivel de temperatura
em um indicador e , direita que exibe um grfico de linha com duas variveis, de temperatura
e luminosidade ao longo do tempo.
A API permite clculos de mdia, varincia, valor mnimo, valor mximo, contagem de
valores e soma de valores. Ela atende a requisitos de segurana como: autenticao baseada
em tokens e trfego de informaes criptografadas atravs do Protocolo de Transferncia de
Hypertexto Seguro (HTTPs).
47
Figura 14 - Widget criado na plataforma Ubidots.
2.4 ANLISE E RECONHECIMENTO DE PADRES
Minerar dados o processo de descobrir informaes relevantes como padres, associa-

es, mudanas, anomalias e estruturas, em grandes quantidades de dados armazenados em
bancos de dados, depsitos de dados ou outros depsitos de informao. A minerao de
dados fornece percepes dos dados, descobrindo padres e relacionamentos ocultos em
grandes bancos de dados e inferindo regras a partir deles, para prever comportamentos fu-
turos (ZAKI; MEIRA, 2014).
O reconhecimento de padres uma disciplina da cincia que tem como objetivo classi-
ficar objetos em um nmero de categorias ou classes, conforme o observado em (THEODOR-
IDIS; KOUTROUMBAS, 2008). Dependendo da aplicao, esses objetos podem ser, por
exemplo, imagens, sinais de ondas de rdio, ou qualquer tipo de medida que se deseja clas-
sificar. Observa-se ainda que, com as tcnicas de reconhecimento de padres pode-se, por
exemplo, estimar valores, selecionar atributos relevantes para classificao, reconhecer pon-
tos fora da curva, chamados de outliers (DOUGHERTY, 2012).
Nas prximas sees sero descritas algumas tcnicas de anlise e reconhecimento de
padres que so relevantes para a implementao das solues propostas, so as seguintes
categorias: tcnicas de regresso, tcnicas de classificao (THEODORIDIS; KOUTROUM-
BAS, 2008) e deteco de outliers. As categorias sero descritas nas Sees 2.4.1, 2.4.2 e
2.4.3, respectivamente.
48
2.4.1 Tcnica de regresso linear
A predio numrica ou regresso definida como uma tcnica para se prever valores
numricos a partir de uma dada entrada, por exemplo uma situao industrial, onde se deseja
prever a quantidade de metros cbicos de gua poluda por determinado componente na
sada de gua corrente em um processo qumico, dado que esse valor est relacionado
temperatura de entrada da gua. Observa-se, nesse caso, que a varivel de quantidade
dependente da varivel de temperatura. Nesse exemplo, as tcnicas de regresso podem ser
utilizadas para a predio dos valores (LARSON; FARBER, 2010) (NAVIDI, 2014).
Para se prever uma varivel dependente a partir de uma outra independente usando a re-
gresso linear, se faz necessrio determinar a equao da reta de regresso que melhor mo-
dela os dados. A reta de regresso e sua equao podem ser usadas na predio do valor de
y, para um dado valor de x (LARSON; FARBER, 2010).
Uma reta de regresso, ou reta de ajuste timo, aquela para a qual a soma dos quadrados
dos resduos mnimo.
A equao de uma reta de regresso para uma varivel independente x e uma varivel
dependente y dada pela Eq.(1):
y = mx + b, (1)
onde, y o valor y previsto para um valor x dado, a inclinao m dada pela Eq.(2) e o
intercepto b dado pela Eq.(3):
P P P
n xy ( x)( y)
m= P P (2)
n x2 ( x)2
P P
y x
b = y m x = ,m (3)
n n
onde, x e y so as mdias de valores nos conjuntos de dados x e y. A reta de regresso passa
sempre pelo ponto( x, y) (LARSON; FARBER, 2010).
A Tabela 1 exemplifica valores de temperatura de entrada de gua e quantidade de metros
cbicos de gua poludos.
Para o exemplo ilustrado pela Tabela 1 observa-se, n = 8, x = 15, 8, y = 1634,
P P
xy = 3289, 9 e x2 = 32, 44. Estes valores podem ser utilizados para se calcular a
P P
inclinao m, aplicando-se a Eq.(2), e o intercepto b da reta de regresso, aplicando-se a

Eq.(3), conforme o ilustrado pelas Eq.(4) e Eq.(5) respectivamente:
8(3289, 8) (15, 8)(1634) 501, 2

m= = 50, 7287 (4)
8(32, 44) 15, 82 9, 88
49
Tabela 1 - Tabela com exemplos de valores de temperatura de entrada e metros cbicos de gua poluda.
Temperatura Vendas da Empresa
(10) (metros cbicos)
X Y
2,4 225,0
1,6 184,0
2,0 220,0
2,6 240,0
1,4 180,0
1,6 184,0
2,0 186,0
2,2 215,0
Fonte: Adaptado de (NAVIDI, 2014).
1634 15, 8
b = y m x = (50, 7287) = 204, 25 (50, 7287)(1, 975) 104, 0608 (5)
8 8
Portanto, a equao da reta de regresso para o exemplo citado dada pela Eq.(6):
y = 50, 729x + 104, 061 (6)
Para esse exemplo, discutido em Larson e Farber (2010), se consegue prever qualquer
valor de metros cbicos de gua poludos, dado por y, dependente da temperatura de pas-
sagem da gua, dada por x.
Em outros ambientes um melhor modelo de previso para uma varivel dependente pode
ser obtido com a ajuda de mais de uma varivel independente. Modelos que contm mais de
uma varivel independente so modelos de regresso mltipla, dados pela Eq. (7) (TRIOLA,
2014):
Yi = 0 + 1 Xi1 + 2 Xi2 + ... + p1 Xi,p1 + i , (7)
onde, Yi a resposta no i-simo ensaio, 0 , 1 , 2 at p1 so os parmetros das variveis

preditoras, Xi1 , Xi2 at Xi,p1 so os valores das variveis preditoras no i-simo ensaio e i
o valor do erro.
Os parmetros n so resultantes da funo de minimizao obtida atravs do mtodo dos
mnimos quadrados, de acordo com a definio dada pela Eq. (8) (TRIOLA, 2014):
n
X
f = (yi 0 X0i 1 X1i ... n Xni )2 (8)
i
50
Os valores de em forma de vetor so dados por:
~ = (0 , 1 , 2 , i ).
A predio dos valores de y deduzida pela Eq. (9):
X
Yi = j X ji = Xi i (9)
i
Conforme o observado em Larson e Farber (2010), aps se ter obtido a equao da reta de
regresso mltipla, ela poder ser utilizada para prever valores de y dentro do intervalo da
variao dos dados, utilizando a Eq.(7) ou a Eq.(9).
2.4.2 Tcnicas de clustering
Segundo Theodoridis e Koutroumbas (2008), as tcnicas de classificao esto inseridas

na rea de reconhecimento de padres, no qual se deseja classificar objetos em um determi-
nado nmero de categorias ou classes.
Em Dougherty (2012) citado que, para se dividir objetos em classes necessrio observar
as caractersticas dos objetos, verificar quais caractersticas discriminam melhor as classes e
a partir delas iniciar o processo de classificao.
Em Theodoridis e Koutroumbas (2008) e em Dougherty (2012) so encontradas diver-
sas tcnicas de classificao, como por exemplo, classificadores probabilsticos, classifi-
cadores baseados na teoria de deciso de Bayes, classificadores lineares baseados em funes
de probabilidade, classificadores baseados em rede neurais, mtodos estocsticos, classifi-
cadores polinomiais, dentre outros.
Para a criao de classificadores se deve incialmente passar por uma etapa de treinamento,
na qual criado um conjunto de treinamento, onde se conhece a quais classes essas instncias
de treinamento pertencem, para que seja possvel, posteriormente, o classificador associar
novas instncias a essas classes inicialmente impostas a ele.
Em Theodoridis e Koutroumbas (2008) e em Dougherty (2012), so mencionadas tcnicas
de criao de classificadores ou de algoritmos de clustering onde no necessariamente existe
essa etapa de treinamento.
Existem duas tcnicas de implementao de classificadores, uma tcnica chamada de
aprendizado supervisionado, na qual inicialmente o classificador passa por uma etapa de
aprendizado e seus resultados so confrontados diretamente com resultados reais. As dife-
renas obtidas entre os seus resultados e o resultado real servem para ajustar o classificador
para que, em novas iteraes desse treinamento os resultados sejam mais prximos do espe-
rado.
51
Outra tcnica utilizada o aprendizado no supervisionado, no qual no se faz necessria a
pr-definio de classes. Nessa tcnica os objetos so agrupados usando suas similaridades,
por exemplo, como a medida da distncia euclidiana, que mede a distncia entre dois pontos.
2.4.2.1 Algoritmo de clustering k-means
O algoritmo de clustering k-means foi proposto incialmente por MacQueen (1967), e uti-
liza medidas de similaridade entre os objetos.
O algoritmo deve receber como parmetro a quantidade de grupos ou clusters (desse ponto
em diante optou-se por utilizar o termo em ingls) nos quais se deseja agrupar os objetos. O
algoritmo escolhe aleatoriamente N objetos, que tornam-se representantes de cada cluster, e
so designados por centrides. A cada iterao, os outros objetos so alocados nos clusters,
ou seja, o objeto colocado no cluster do centride mais prximo. A cada iterao, o algo-
ritmo recalcula o centride, usando a mdia das distncias entre todos os integrantes do clus-
ter. Quando no ocorrerem mais variaes nos posicionamentos dos centrides, significa que
o algoritmo convergiu. A Figura 15 ilustra o pseudo-cdigo do algoritmo (DOUGHERTY,
2012).
2.4.2.2 Algoritmo de clustering canopy
A algoritmo de clustering Canopy um mtodo rpido para agrupamento de instncias

em clusters. Os objetos so representados como um ponto no espao multidimensional, o
algoritmo utiliza uma medida de distncia e dois limiares T 1 > T 2 para o processamento.
Ele inicia com um conjunto de pontos e remove um ponto aleatoriamente, cria um canopy
contendo esse ponto e percorre o restante do conjunto de pontos. Em cada ponto, se a
distncia do primeiro ponto menor que T1, se adiciona o ponto ao cluster. Se, a distncia
tambm for menor que T2, em seguida, se remove o ponto do conjunto. O algoritmo continua
a iterao at que o conjunto inicial esteja vazio, criando conjuntos com todos os objetos,
cada um contendo um ou mais pontos. Um determinado ponto pode estar em mais de um
Canopy (MCCALLUM; NIGAM; UNGAR, 2000).
Esse algoritmo usado frequentemente como um passo inicial para outros algoritmos de
clustering, como o K-Means (GIACOMELLI, 2013).
52
Figura 15 - Pseudo-cdigo do algoritmo k-means.
Fonte: (DOUGHERTY, 2012).
2.4.3 Deteco de Outlier
Segundo Zaki e Meira (2014) uma anomalia ou um outlier (desse ponto em diante ser
utilizado o termo outlier) ocorre quando uma instncia ou conjunto de instncias so consi-
deradas diferentes do restante do conjunto de dados. A deteco de outliers tem importantes
aplicaes para deteco de fraudes em cartes de crdito, fraudes em sistemas de telecomu-
nicaes, deteco de falhas, redes de sensores, deteco de intrusos, deteco de spam em
emails, diagnsticos mdicos ou aplicaes em marketing.
H trs tipos de tcnicas elencadas na literatura para a deteco de outliers: tcnicas
baseadas em distncia, baseadas em densidade ou baseadas em estatsticas (ZAKI; MEIRA,
2014). Dado o foco desta pesquisa, destaca-se a tcnica baseada em distncia, no qual uma
dada instncia considerada um outlier caso uma frao, onde p(0 < p < 1), de instn-
cias em uma base de dados esto fora do raio de uma vizinhana O. Caso esse limiar seja
muito grande, pontos que deveriam ser considerados outliers no sero, e caso esse limiar
seja muito pequeno, grande parte dos pontos sero considerados outlier erroneamente. Esta
abordagem relevante para a implementao e proposta de algoritmo que ser descrita na
53
Seo 3.4.3.
2.5 TECNOLOGIA BIG DATA
Mayer-Schonb e Cukier (2014) mencionam que Big Data refere-se a grandes conjuntos
de dados que so difceis de armazenar, pesquisar, visualizar e analisar como, por exemplo,
uma empresa area que coleta 10 terabytes de dados de sensores durante 30 minutos de vo
do avio. Nathan e Warren (2015) mencionam que Big Data usado comercialmente para
se analisar grandes quantidades de dados para se tomar decises, baseando-se na anlise do
comportamento e preferncias do consumidor.
Segundo Smith (2012), Big Data refere-se ao processamento e anlise de repositrios de
dados extremamente grandes e que no seriam possveis se processar ou analisar com as
ferramentas convencionais de anlise de dados. Big Data requer grande poder computa-
cional para processar eficientemente grandes quantidades de dados em intervalos de tempos
tolerveis. Essa tecnologia envolve Massive Parallel Processing Databases (MPP), grids
de minerao de dados, sistemas de arquivos distribudos, plataformas de computao em
nuvem, redes de comunicao e sistemas de armazenamento escalveis.
2.5.1 Framework Hadoop
Hadoop o termo usado para se referir a uma famlia de projetos relacionados, que com-
pe a infraestrutura para computao distribuda e de larga escala de processamento, que
usa o conceito de Big Data. De acordo com White (2015), Hadoop a implementao para
MapReduce e sistema de arquivos distribudo mais utilizado e conhecido.
O MapReduce um modelo de processamento de dados distribudo e um ambiente de
execuo em clusters de larga escala. Esse modelo divide o processamento em mapas e o
divide em fases, cada fase se baseia em um par de chave/valor usado como entrada e sada
para o processo. O programador especifica duas funes, o mapa e as funes de reduo,
para serem usadas na implementao e execuo especfica (WHITE, 2015).
O projeto Hadoop possui o Hadoop Distributed File System (HDFS) que um sistema de
arquivos projetado para armazenar arquivos extremamente grandes com um padro de fluxo
de acesso, executar sob clusters de mquinas de comodities ou plataformas de hardware co-
muns (WHITE, 2015). O MapReduce e o HDFS possuem uma API para o desenvolvimento
e o uso de suas funcionalidades.
Outro projeto relacionado ao Hadoop e importante para esta pesquisa o Mahout, que
um projeto de cdigo livre da fundao Apache que possui uma biblioteca de implementao
54
de algoritmos para aprendizagem de mquina. De acordo com Giacomelli (2013), o objetivo
do projeto Mahout ser uma escolha de ferramenta para aprendizado por mquina para pro-
cessamento de conjuntos de dados extremamente grandes, tanto para execuo em clusters
de instncias de Hadoop ou em uma nica mquina. O Mahout uma ferramenta desen-
volvida em linguagem de programao Java dentro do projeto de computao distribuda
Hadoop.
O projeto Mahout possui implementaes de algoritmos de classificao e clustering,
como o algoritmo K-means que possui grande relevncia para a implemetao proposta nesta
pesquisa.
2.6 TRATAMENTO DOS DADOS NO MODELO DE INTERNET DAS COISAS
Esta seo tem por objetivo ilustrar o volume de dados gerados pela IoT, os mecanismos
de gerenciamento de dados em IoT como, coleta e anlise de dados, sensores virtuais e
processamento de eventos complexos e caracterizar os tipos de dados presentes no modelo
de IoT.
2.6.1 Volume de dados gerados com a IoT
A IoT envolve uma grande quantidade de ns interconectados que possuem diferentes tec-
nologias e padres de comunicao. Observa-se que, nesse novo modelo de rede, existir
um grande nmero de ns produzindo, transmitindo e gravando dados, que sero proces-
sados, integrados, analisados, requisitados e consumidos, por outro grande conjunto de ns
(JAMES et al., 2009) (JEFFERY, 2009), para os quais sero necessrias tecnologias de ge-
renciamento de dados especfica (FAN; CHEN, 2010).
Bin, Yuan e Xiaoyi (2010) destacam que a utilizao da IoT produzir um grande volume
de dados. Pode-se tomar como exemplo um processo de cadeia de suprimentos em um
hipermercado, no qual, se a empresa adotar a tecnologia de RFID, no formato do Cdigo
Eletrnico de Produto (EPC) para identificao dos objetos e necessitar de informao de
localizao e sobre o tempo em que o objeto esteve venda, sero necessrios 18 bytes para
armazenamento dos dados de um nico objeto. Em um hipermercado, que possui em torno
de 1.000.000 de produtos ou, nesse exemplo tarjas de RFID, sero gerados 18 Mega Bytes
(MB) de dados por segundo e 1,16 Tera Bytes (TB) a cada dezoito horas, caso a frequncia
de evento de leitura dos dados seja a cada segundo.
Cooper (2009) menciona que os dados gerados a partir da IoT podem ser categorizados
em alguns tipos bsicos. So eles:
55
1. endereos ou identificadores nicos dos objetos.
2. dados descritivos dos objetos.
3. dados posicionais ou da localizao geogrfica.
4. dados de ambiente.
5. dados de redes de sensores.
Esse grande volume de dados requer mecanismos para gerenciamento, anlise e minerao
de dados na IoT.
Em Bin, Yuan e Xiaoyi (2010) proposto um modelo em camadas para minerao de
dados em IoT. Esse modelo ilustrado pela Figura 16.
Figura 16 - Modelo em camadas para a minerao de dados para a IoT.
Fonte: (BIN; YUAN; XIAOYI, 2010).
O modelo mostrado na Figura 16 composto pelas seguintes camadas: a camada inferior

que captura os dados, a prxima camada que trata do gerenciamento desses dados, imedia-
tamente aps encontra-se uma camada que deve detectar e filtrar os inmeros eventos que
56
ocorram com os objetos e, por fim, a camada superior, que dever prover servios para a
minerao dos dados capturados.
2.6.2 Gerenciamento de dados em IoT
Segundo Aggarwal, Ashish e Sheth (2013) o grande poder do paradigma da IoT est
na habilidade de prover, em tempo real, dados sobre muitos e diferentes recursos para ou-
tras mquinas, entidades inteligentes ou pessoas, para uma variedade de servios. Um dos
maiores desafios reside em como tratar os dados oriundos de diferentes recursos, extrema-
mente heterogneos, que podem conter muitos rudos, em grande escala e de forma dis-
tribuda.
Observou-se na Seo 1.2, que o gerenciamento de dados em IoT importante para o seu
desenvolvimento e pode ser dividido em alguns grupos principais de conceitos e tecnologias
relevantes para essa pesquisa (SMITH, 2012), conforme a descrio a seguir.
2.6.2.1 Coleta e anlise de dados (DCA)
A Coleta e Anlise de Dados (DCA) so representadas por mdulos ou componentes que

devem possuir capacidades de armazenamento e troca de dados para anlise ou processa-
mento (SMITH, 2012). Devem ser capazes de prover:
armazenamento de dados coletados por sensores.
permitir que sejam adicionados novos sensores no modelo, de modo a acomodar as

novas informaes coletadas.
prover API para acesso aos dados coletados.
prover APIs para acesso em tempo real aos dados coletados, como por exemplo, meca-
nismos de gerenciamento de eventos (publish, subscribe, foward e notification).
permitir a criao de regras ou filtros para os eventos.
permitir ao usurio gerenciar e automatizar processos.
permitir ao usurio criar seus fluxos de entradas de eventos vindos de um dispositivo.
prover estruturas multitenant que suporte mltiplas organizaes, diferentes tipos de

dados, padres e formatos, descentralizao, de modo a permitir uma integrao global
entre arquiteturas de IoT, prover segurana e mecanismos de minerao de dados.
57
2.6.2.2 Sensores virtuais
Um sensor virtual pode ser considerado um produto temporal, espacial ou temtico que
transforma um dado bruto, produzindo uma informao, ou seja, dados coletados, agregados
ou processados a partir de um conjunto de sensores criam um valor para um sensor virtual.
Da mesma forma, um atuador virtual pode ser um nico ponto para a distribuio de coman-
dos para um conjunto de atuadores (SMITH, 2012).
2.6.2.3 Processamento de eventos complexos (CEP)
O Processamento de Eventos Complexos (CEP) oferece uma coleo de eventos a partir

de mltiplas origens, detectando padres, filtrando, transformando, correlacionando e agre-
gando em eventos complexos (FLP et al., 2012).
O processamento de eventos complexos possui relao com os sensores virtuais. Um sen-
sor virtual pode ser usado para se implementar sensores nicos, a partir de eventos complexos
e mltiplos sensores ou inmeras origens de dados (SMITH, 2012).
Os conceitos referentes a CEP podem ser classificados em duas categorias principais: (1)
Computation oriented CEP, que tem foco em execuo on-line de algoritmos como uma
resposta entrada de eventos no sistema; e (2) Detection oriented CEP, que tem como foco
a deteco de combinaes de eventos chamados de padres ou situaes (SMITH, 2012).
Em Etzion e Niblett (2010) so definidos alguns conceitos bsicos a respeito de CEP. Um
Agente de Processamento de Evento (EPA) um componente que, dado um conjunto de
eventos de entrada, se aplica uma lgica para gerar um conjunto de eventos complexos de
sada. Uma Rede de Processamento de Eventos (EPN) uma rede com uma coleo de
EPAs, produtores de eventos e consumidores de eventos ligados a canais.
Em Wang, Cao e Zhang (2013) discute-se que as principais ideias da deteco de eventos
complexos possuem quatro passos: (1) eventos primitivos que so extrados de um grande
volume de dados; (2) as correlaes ou agregao de eventos so detectadas para se criar
um evento de negcio com operadores de eventos de acordo com regras especficas; (3)
primitivas ou composies de eventos so processadas para se extrair seu tempo, causa,
hierarquia e outros relacionamentos semnticos; e (4) a resposta enviada para o acionador
de informaes de negcio, de modo a garantir a entrega dos eventos aos seus observadores.
58
2.6.3 Tipos de dados em IoT
Em James e Cooper (2009) so discutidos os diferentes tipos de dados que esto no con-
texto de IoT. Os dados oriundos da IoT podem ser discretos ou contnuos, gerados automati-
camente ou atravs de alguma ao humana. Eles foram categorizados em algumas reas,
como se segue: RFID, identificao nica ou endereo, dados descritivos, posicionais e da-
dos ambientais, dados de sensores, modelos fsicos e dados de comandos.
2.7 CONSIDERAES FINAIS
Neste captulo foram descritas tecnologias e definies que so de extrema importncia

para a pesquisa. As caractersticas dos modelos de referncia para IoT do ITU-T e do IoT-A,
no qual pode-se destacar a especificao mais detalhada do modelo proposto pelo IoT-A.
Foram elencados diversos middleware de software para IoT, dentre eles, destaca-se o Link-
Smart Middeware, que aderente arquitetura IoT-A, adequado aos objetivos de desen-
volvimento desta pesquisa. O Captulo 3 apresenta uma anlise crtica e comparativa ente o
LinkSmart middeware e a plataforma Ubidots de modo a justificar a escolha.
Foram elencadas algumas tcnicas de anlise e reconhecimento de padres que podero
servir como base para o desenvolvimento dos recursos que se pretende integrar aquitetura
de IoT.
Por fim, foram descritos alguns mtodos de coleta e anlise de dados existentes. A tec-
nologia de Big Data, comumente aplicada na camada de aplicao. Em especial, a tcnica
de processamento de eventos complexos, que poder ser aplicada ao modelo de IoT, com
o intuito de se agregar dados para ns ou aplicaes que precisem utilizar dados em nveis
mais altos.
Foge ao escopo desta pesquisa o desenvolvimento de tcnicas de reconhecimento de padres
ou de Big Data, mas de propor a integrao de tcnicas conhecidas e validadas ao LinkSmart
middeware para se ter um framework de desenvolvimento de aplicaes e servios de IoT
poderoso, robusto e flexvel.
59
3 NOVA ARQUITETURA PARA INTERNET DAS COISAS COM
RECONHECIMENTO DE PADRES E BIG DATA
Este captulo descreve a soluo proposta, mostra como a soluo foi desenvolvida e detalha
aspectos de implementao. As solues so caracterizadas elencando os objetivos destaca-
dos na Seo 1.4.
Este captulo est organizado da segunte maneira: a Seo 3.1 ilustra a anlise comparativa
entre os modelos de referncia para IoT descritos; a Seo 3.2 faz uma anlise crtica entre
os middlewares de IoT descritos na pesquisa; a Seo 3.3 descreve a soluo proposta em
nvel arquitetural dos servios propostos no modelo de IoT; a Seo 3.4 descreve aspectos
tcnicos da implementao da soluo proposta; a Seo 3.5 descreve a tcnica de sensores
virtuais; e, por fim, a Seo 3.6 resume as consideraes finais a respeito deste captulo.
3.1 ANLISE DE MODELOS DE REFERNCIA EM IOT
Essa anlise vai ao encontro do objetivo secundrio 1, apresentado na Seo 1.4.

O modelo de referncia do ITU-T possui a especificao em camadas e uma breve descri-
o das principais funcionalidades necessrias a um sistema de IoT.
O modelo de referncia proposto pelo IoT-A define sub-modelos e a interao entre eles.
Define uma arquitetura de referncia que funciona como um modelo para a especificao,
implementao e implantao de sistemas para IoT. As especificaes partem dos requisitos
e diagramas para a especificao do sistema e vai at a especificao de tecnologias para as
camadas, como hardware, software, modelo de rede e comunicao dos dispositivos.
Ambos so modelos de referncia, porm o modelo definido pelo IoT-A, parte do modelo
de referncia e chega at a arquitetura de referncia, que guia o design do sistema de IoT.
A arquitetura implementada no Linksmart Middleware tem relao com a arquitetura pro-
posta nos documentos que descrevem a arquitetura IoT-A (JOACHIM; WALEWSKI, 2012).
Na especificao da arquitetura so mencionadas as camadas de implementao, no nvel
de comunicao, arquitetural e conceitual. O Channel Model for IoT Communication tem
relao com os nveis de abstrao dos dados ou informaes que so passados para um
prximo n ou camada de nvel de informao ou aplicao.
Esta pesquisa sugere estender o modelo IoT-A, para se estabelecer classes de dispositivos,
que especifiquem capacidades de filtragem, de estimao de valores, deteco de outlier e
anlise de clustering, conforme os objetivos elencados, e destaca-se a importcia de inserir a
comunicao cross-layer na arquitetura IoT-A. interessante adotar o modelo proposto pelo
IoT-A nas especificaes de futuras aplicaes e pesquisas.
60
3.2 ANLISE CRTICA E COMPARATIVA ENTRE O LINKSMART MIDDLEWARE E
PLATAFORMA UBIDOTS
Esta seo compara as plataformas LinkSmart e Ubidots. A Tabela 2 mostra os atributos

de cada uma das plataformas.
Tabela 2 - Tabela comparativa entre o LinkSmart Middleware e a plataforma Ubidots.
Atributo LinkSmart Middleware Plataforma Ubidots
Nvel de escalabilidade Alto No conhecido
Alto tendo em vista
Nvel de modularizao No conhecido
basear-se em (OSGI)
Estenso do framework/
Cdigo aberto Cdigo fechado
acesso ao cdigo fonte
Nvel de dificuldade para uso da API Mdio Baixo
Integrao com outras Python, Java, C, PHP,
Java e WebServices
linguagens de programao Node, Ruby e LabVIEW
Interface com dipositivos diversos Sim Sim
Segurana/Criptografia Sim Sim
Tempo de acesso/latncia Baixo Alto
Instalao on-site
Sim No
do framework
Clusters para processamento Sim No conhecido
Criao de tipos de
Sim No
objetos/instncias
Tipos de variveis Tipos Existentes em Java Apenas inteiras ou reais
Clculos no framework/API No Sim
Nvel de gerenciamento de eventos Alto Baixo
Nvel de disponibilizao dos dados Alto Baixo
Criao de widgets No Sim
Custo licenciamento de software No Sim
Dentre os diversos atributos elencados, destacam-se a possibilidade de estenso, de cria-

o de inmeros tipos de variveis ou instncias, o nvel de gerenciamento de eventos e
dados e a modularizao presentes no LinkSmart Middleware e que se mostram deficientes
61
na plataforma Ubidots.
O fato da plataforma Ubidots no permitir a criao de instncias, que contenha mais de
um atributo em um objeto, obriga que a implementao de controle seja feita no gateway ou
no dispositivo da camada fsica. Para criar esse controle o gateway deve enviar simultanea-
mente os vrios atributos, porm, no h nenhuma ligao explcita entre eles, o que pode
gerar inconsistncias para a aplicao.
A Figura 17 ilustra a execuo de uma aplicao experimental que utiliza a plataforma
Ubidots.
Figura 17 - Aplicao de teste com a plataforma Ubidots.
A aplicao de teste inseriu 5000 instncias, com trs atributos: luminosidade, tempera-
tura e horrio da leitura como varivel inteira. Cada atributo foi inserido individualmente,
somando-se 15000 registros na plataforma Ubdots, que apresentou 15 erros ao inserir o con-
junto total de instncias. Atravs da API no possvel resgatar cada valor, somente o
conjunto total com todos os registros. O tempo decorrido para a insero dos registros foi
de aproximadamente uma hora e seis minutos, para o resgate do conjunto completo o tempo
decorrido foi de aproximadamente 7 segundos. O tempo total decorrido foi relativamente
62
alto.
A Figura 18 ilustra a execuo de uma aplicao experimental que utiliza LinkSmart mi-
ddleware.
Figura 18 - Aplicao de teste com o LinkSmart middleware.
A aplicao de teste inseriu 5000 instncias, com trs atributos: luminosidade, tempera-
tura e horrio da leitura como varivel inteira, essa execuo no apresentou erros ao inserir
o conjunto total de instncias. O tempo decorrido para a insero dos registros foi de apro-
ximadamente um minuto e quarenta e nove segundos, para o resgate do conjunto completo
de dados o tempo decorrido foi de quase 2 segundos. O tempo total decorrido foi baixo
se comparado plataforma Ubidots, porm ele no pode ser um parmetro relevante para a
escolha de plataforma, tendo em vista que pode haver variaes da banda de rede disponvel
no momento da execuo da aplicao.
A plataforma Ubidots permite apenas a insero de variveis inteiras ou reais, no per-
mitindo, portanto, valores como data, hora, textos ou outros tipos quaisquer que, dependendo
do contexto da aplicao podero ser importantes.
Esses fatores justificam a opo em se desenvolver a arquitetura estendendo o LinkSmart
Middleware.
3.3 ANLISE E RECONHECIMENTO DE PADRES NAS CAMADAS DE MIDDLE-

WARE/SERVIO E DE DISPOSITIVO/GATEWAY NO MODELO DE IOT
A soluo descrita nesta Seo vai ao encontro do objetivo principal, de se acrescentar

mecanismos de anlise e reconhecimento de padres nas camadas do modelo de IoT e do
63
objetivo 3 de se criar uma estrutura para processamento distribudo para IoT.
Essa soluo acrescenta os mecanismos de anlise e reconhecimento de padres nas ca-
madas de: (1) middleware e servio no modelo de IoT; (2) na camada de dispositivos ou
entidades fsicas, nesse caso dentro de dispositivos de IoT que estejam na classe de dispo-
sitivos com reduzido poder computacional; e (3) no dispositivo de gateway de IoT. Cabe
destacar que a normalizao e sincronizao dos dados e diferentes fontes no esto no es-
copo dessa soluo e devem ser uma deciso de projeto e arquitetura da aplicao ou sistema
cliente do mdulo aqui descrito.
Optou-se por usar como base o LinkSmart middleware como uma plataforma para cria-
o de aplicaes para a IoT, que era uma necessidade apontada em Chartier (2011). Nessa
soluo acrescenta-se uma sub-camada para o reconhecimento de padres ao LinkSmart mi-
ddleware, na qual se inserem os novos servios para anlise e reconhecimento de padres ao
abstrair algoritmos para deteco de outliers, estimao de valores e algoritmo de clustering,
permitindo que eles sejam aplicados a diversos ambientes e com diversos tipos de disposi-
tivos. Dessa forma as aplicaes passam a poder resgatar informaes do middleware, ao
invs de resgatar dados capturados diretamente dos objetos interconectados.
A Figura 19 ilustra a alterao proposta na estrutura em camadas do LinkSmart middle-
ware.
A sub-camada Pattern Layer, destacada pelo retngulo possui trs gerenciadores clus-
tering manager, outlier manager e estimation manager, nos quais so implementadas as
funcionalidades para o reconhecimento de padres.
Essa implementao possui trs aspectos importantes:
1. Alterao nos Application Elements, esquerda na Figura 19, com foco na camada de
middleware ou servio.
2. Alterao nos Device Elements, direita na Figura 19, elementos de dispositivos que
podem ser embutidos em futuros dispositivos para IoT, que venham a utilizar o Link-
Smart Middleware como base para seu firmware. Os elementos de dispositivos podem
ser incorporados aos gateways de IoT.
3. Para classes de dispositivos que no possam ter os elementos de dispositivos do Link-

Smart Middleware embutidos, pretende-se criar especificaes de algoritmos que sejam
incorporados ao firmware. Essa implementao tem o foco voltado Physical layer ou
camada de entidades fsicas.
A utilizao de algoritmos de estimao de valores, de clustering e de deteco de outliers

(DOUGHERTY, 2012) (THEODORIDIS; KOUTROUMBAS, 2008) ir contribuir para a
64
Figura 19 - Proposta de nova estrutura em camadas do LinkSmart middleware com os mecanismos de anlise e
reconhecimento de padres.
minimizao do trfego de rede na modelo de IoT proposto, tendo em vista que no haver
a necessidade de enviar todos os dados camada superior, pois sero pr-processados no
prprio middleware de IoT. Aos algoritmos, soma-se a arquitetura distribuda Big Data para
a minerao de dados que pretende distribuir o armazenamento e processamento, utilizando
recursos do Framework Hadoop e do LinkSmart Middleware.
Para essa implementao utilizam-se algoritmos de:
Regresso linear para estimao de valores.
Algoritmo k-means para o clustering dos valores oriundos de sensores ligados aos dis-
positivos ou de dados que j tenham sido entregues ao LinkSmart Middleware.
Para a deteco de outliers utiliza-se o algoritmo de clustering k-means e medida de

distncia dos centrides para a deteco de outliers (DOUGHERTY, 2012) (PAMULA;
DEKA; NANDI, 2011) (LEI et al., 2012) (SOUZA; AMAZONAS, 2015).
65
A Figura 20 ilustra o fluxo de dados e informaes na arquitetura e implementao pro-
postas.
Figura 20 - Representao grfica do fluxo de dados e informaes na arquitetura proposta.
O aspecto mais importante dessa implementao o novo mdulo para reconhecimento

de padres inserido no LinkSmart Middleware. Essa implementao segue a arquitetura
proposta pelo modelo de referncia IoT-A, descrito na seo 2.2.2, e possui as seguintes
camadas:
Physical layer ou Camada fsica: essa camada de recursos fsicos, que ser chamada
deste ponto em diante de Resource Layer, representada por sensores e dispositivos
inteligentes. O gerenciador de recursos fsicos ou Resource Manager, representa os
drivers de dispositivos ou gateway que so responsveis por fazer a interface com o
LinkSmart Middleware e enviar os dados brutos ou dados pr-processados por algorit-
mos de estimao de valores ou deteco de outliers. Caso os dados gerados por um
Resource Manager sejam processados nessa camada, ele dever informar ao gerencia-
dor de configurao, chamado deste ponto em diante de Configuration Manager, no
66
LinkSmart Middleware ou diretamente aplicao. Tanto o Resource Manager quanto
a aplicao podero alterar parmetros no Resource Manager de modo a desativar o
pr-processamento e ele passe a enviar os dados brutos para a camada superior. A partir
dessa camada o fluxo de informao pode ir para a camada de middleware.
Middleware layer ou Camada de Middleware: essa camada representada pelo Link-

Smart Middleware, modificado nessa implementao pela incluso dos servios de re-
conhecimento de padres e o Configuration Manager. O Event Manager, j existente,
possui grande relevncia nessa arquitetura, porm os outros servios presentes no mi-
ddleware no so relevantes para a implementao aqui descrita. O Pattern Manager
implementa trs servios: estimao de valores, clustering e deteco de outliers. O
Configuration Manager permite que as aplicaes ou o Resource Manager possam con-
figurar parmetros no Pattern Manager, definir quando os algoritmos executaro ou o
quanto de dados dever ser armazenado, habilitar ou desabilitar os servios de reconhe-
cimento de padres ou limpar os dados armazenados. Depois do processamento dos
dados o servio de reconhecimento de padres pode enviar as informaes contextua-
lizadas para o Event Manager, que por sua vez, envia os novos eventos aos clientes.
O Event Manager prov a escalabilidade, tendo em vista que ele possui recursos para
enviar os eventos para um nico ou milhes de clientes, dependendo da estrutura de
implantao do LinkSmart.
O Event Manager pode ser acessado diretamente pelo Resource Manager, que neste
caso, no habilitou os servios de reconhecimento de padres. Essa caracterstica pode
ser escolhida no projeto da aplicao e pode ser alterada atravs do Configuration Ma-
nager.
Essa camada implementa a comunicao cross layer, tendo em vista que ela pode rece-
ber ou enviar parmetros de configurao ao Resource Manager ou para as aplicaes.
Esse o aspecto mais relevante da comunicao cross layer, na qual, o dado bruto pode
ser aberto, processado ou interpretado nessa camada, que de outra forma, seria uma
funo especfica da camada de aplicao, conforme o modelo OSI (COMER, 2015).
Application layer ou Camada de aplicao: essa camada representa as aplicaes clientes

ou suas aes de configurao. As aplicaes recebem os eventos a partir do Event Ma-
nager, sendo os dados brutos ou informaes processadas. As aes de configurao
so responsveis por configurar os parmetros no Configuration Manager ou por enviar
parmetros ao Resource Manager ou ao Middleware, para controlar seu comportamento
ou os servios de reconhecimento de padres, ativando-os ou desativando-os. Essa co-
municao bidirecional.
67
A comunicao cross layer um requisito importante nessa arquitetura e foi implemen-
tada conforme a descrio mencionada. A arquitetura proposta permite o processamento
distribudo ou em vrias camadas, tendo em vista que a informao pode ser processada em
cada n fsico, ou de rede como cada n do middleware, ou por ns de aplicao. A comuni-
cao cross layer proposta nessa arquitetura permite essa funcionalidade, que nesta pesquisa
relevante para o contexto de aplicaes de IoT.
3.4 ASPECTOS DE IMPLEMENTAO DO MDULO DE RECONHECIMENTO DE

PADRES E O PROCESSAMENTO COM BIG DATA
O LinkSmart Middleware foi implementado usando a arquitetura OSGI (BAKKER; ERT-

MAN, 2013). Para se criar um novo mdulo nesse middleware deve-se usar essa arquitetura,
estender seus pacotes e criar as Interfaces e contratos para os novos servios.
A Figura 21 ilustra o principal diagrama de classes do Pattern Manager implementado.
O diagrama de classes ilustrado pela Figura 21 descreve a estrutura dos novos pacotes
criados e includos no LinkSmart. Esses novos pacotes possuem as seguintes classes:
ClassificationManager: uma Interface que define os contratos para as chamadas de

mtodos para os novos servios. Os servios e mtodos implementados no Pattern Ma-
nager so: register e unregister que serverm respectivamente para registrar ou remover
um Pattern Hardware Identification (PHID), que um valor nico assinado para cada
fonte de dados, listar todos os PHIDs, submeter um novo dado bruto, remover dados a
partir de um PHID, executar os algoritmos, definir atributos para os algoritmos, dentre
outros mtodos que possuem as mesmas caractersticas para os outros servios.
ClassificationManagerImpl: uma classe concreta que implementa os mtodos definidos

na Interface ClassificationManager e agrega outros mtodos para a implementao do
servio OSGI. Essa classe gerencia as instncias de classes que implementam os algo-
ritmos para anlise e reconhecimento de padres e todos os PHIDs existentes no Pattern
Manager.
Diversas outras classes foram desenvolvidas para se implementar os algoritmos de reco-

nhecimento de padres e integr-los plataforma de Big Data Hadoop e sero descritas
juntamente com seus respectivos servios. Nas prximas Sees sero descritos os servios
desenvolvidos como clustering, estimao de valores e deteco de outliers e a comunicao
cross layer, respectivamente.
68
Figura 21 - Diagrama de classes do Pattern Manager incluindo os pacotes, a Interface e a classe que a imple-
menta.
3.4.1 Implementao do servio de clustering
A Figura 22 exibe o diagrama de classes que implementa o servio de clustering no m-

dulo Pattern Manager.
A Figura 22 apresenta o pacote existente eu.linksmart.pattern e os novos pacotes clusterer
e hadoop, com as seguintes classes:
PatternSubscription: essa classe cria a estrutura com os atributos para as novas classes,
que implementam os servios no mdulo Pattern Manager. Essa classe define os atribu-
tos que informam o tipo de algoritmo, se clustering, deteco de outlier ou estimao
69
Figura 22 - Diagrama de Classes com a implementao do servio de clustering no mdulo Pattern Manager.
de valores, tipos de atributos, se so numricos, textos, classes ou datas, e o valor de

PHID.
PatternSubscriptionClustering: essa classe estende a classe PatternSubscription e acres-

centa novos mtodos para o servio de clustering, como o inputInstance para se inserir
instncia de dado para o processamento, findCluster que retorna a qual cluster uma
instncia mais semelhante ou est mais prxima, setAttributesClustering que define
parmetros para o algoritmo de clustering, runPattern que inicia a execuo do algo-
ritmo, finishedRunSubscriptionClustering que notifica quando o processo de clustering
foi finalizado e o returnResultPatternClassificationClustering que retorna o resultado
do processamento. Note que essa classe no implementa o algoritmo de clustering,
70
mas ela possui um objeto ao qual ela delega esse processamento. Essa soluo permite
o desacoplamento entre o mdulo e a implementao concreta e, por fim, permite a
introduo de novas implementaes.
PatternClustering: essa Interface define a estrutura para que uma classe possa imple-
mentar os mtodos necessrios para ser um objeto de PatternClustering. Ela define os
seguintes mtodos: inputInstance, findCluster, runPattern, returnResultPatternClassi-
ficationClustering, setAttributesClustering e finishedRunSubscriptionClustering, todos
relacionados aos mtodos definidos na classe PatternSubscriptionClustering.
ResultPatternClassificationClustering: essa classe contm os atributos necessrios de

um resultado de execuo de um algoritmo de clustering. Esse objeto pode ser retornado
a uma aplicao, de modo que as informaes sobre os clusters, possam ser utilizadas
na aplicao para se contextualizar e gerar conhecimento sobre os dados processados na
camada de middleware. O resultado contm todos atributos de cada centride de cada
cluster e seus respectivos raios.
PatternClusteringHadoopImpl: essa uma importante classe no servio de clustering,

ela uma implementao concreta da Interface PatternClustering e de todos os seus
mtodos propostos. Ela implementa o algoritmo de clustering k-means, integrado ao
Hadoop para processamento distribudo com Big Data. A implementao do algoritmo
utiliza o Framework Mahout. O principal mtodo implementado na classe cria um
thread para iniciar o processo na instncia de Hadoop. Quando o processo finalizado o
mtodo altera o estado de um flag de modo a informar e enviar o resultado ao LinkSmart
EventManager e dessa maneira, todos os clientes que estiverem inscritos, recebero a
notificao com um novo valor ou conjunto de dados.
SimpleKMeansClusteringHadoop: essa classe implementa a integrao e executa um

thread do algoritmo k-means na instncia do Hadoop.
Essa implementao da arquitetura permite que qualquer outra classe possa implemen-
tar a Interface PatternClustering e ser acoplada ao mdulo. Em implementaes prvias,
foi utilizado o framework Weka como base para implementao do algoritmo de clustering,
porm, no se obtiveram resultados satisfatrios quanto aos tempos de execuo no contexto
de IoT com os conjuntos de bases de dados para experimentos. A partir desses resultados
insatisfatrios optou-se por utilizar a tecnologia de Big Data com o Hadoop e a implemen-
tao algortmica do Mahout. A implementao com Big Data permite a criao de clusters
de processamento com instncias de Hadoop, o que permite uma escalabilidade grande de
poder computacional e que seja transparente para o mdulo desenvolvido.
71
3.4.2 Implementao do servio de estimao de valores
O servio de estimao de valores possui estrutura semelhante estrutura do servio de

clustering. A classe PatternSubscription possui papel fundamental para o acoplamento do
algoritmo principal estrutura do mdulo Pattern Manager.
A Figura 23 ilustra o diagrama de classes que implementa o servio de estimao de
valores no mdulo.
Figura 23 - Diagrama de classes do servio de estimao de valores no mdulo Pattern Manager.
A Figura 23 mostra o pacote existente eu.linksmart.pattern e os novos pacotes adicionados

estimator e Weka. As seguintes classes foram desenvolvidas:
PatternSubscription: essa a mesma classe descrita no servio de clustering e possui a

mesma estrutura j descrita na Seo 3.4.1.
PatternSubscriptionEstimation: essa classe estende a classe PatternSubscription e agrega

72
novos mtodos para esse servio, como inputInstance, que possui a mesma funo des-
crita no servio de clustering, estimateSubscription para estimar um valor especfico
dada uma instncia, setAttributesEstimation para definir parmetros para o algoritmo
de estimao como, por exemplo, o atributo alvo que deve ser estimado, runPattern
para iniciar a execuo do processo de estimao finishedRunSubscriptionEstimation
para notificar quando o processo de estimao finalizado e o mtodo returnResultPat-
ternEstimation que retorna o resultado do processo de estimao. Essa classe no im-
plementa o algoritmo de estimao, mas ela possui uma instncia de PatternEstimation,
qual delegada a implementao do algoritmo. Assim como no servio de cluste-
ring, essa estrutura de orientao a objetos permite o desacoplamento entre o mdulo e
a implementao concreta dos algoritmos, permitindo assim, novas implementaes e
novos algoritmos futuros.
PatternEstimation: essa interface define a estrutura para novas classes que venham a im-
plementar os mtodos necessrios para que ela seja um PatternEstimation. Essa classe
define os seguintes mtodos: inputInstance, estimateSubscription, runPattern, return-
ResultPatternClassification, setAttributesEstimation e finishedRunSubscriptionEstima-
tion.
ResultPatternClassificationEstimation: essa classe possui todos os atributos necessrios

para o resultado ser retornado por um algoritmo de estimao. Um objeto de Result-
PatternClassificationEstimation pode ser enviado para uma aplicao cliente com as
informaes sobre o resultado do algoritmo, de modo a permitir que a prpria aplicao
possa ter a equao de regresso do conjunto de dados (DOUGHERTY, 2012), embora,
para a grande maioria dos contextos, o middleware poder estimar o valor da instncia
e apenas sinalizar para a aplicao que o algoritmo de estimao foi utilizado, tornando
o processo mais transparente para a aplicao.
PatternEstimationWekaImpl: essa a classe mais importante no servio de estimao,

ela implementa a Interface PatternEstimation e todos os seus mtodos propostos. Ela
implementa o algoritmo de regresso linear usando a implementapo do framework
Weka para o processamento dos dados. O principal mtodo implementado nessa classe
cria e inicia um thread que inicia o processo de execuo do algoritmo com as classes
do framework Weka. Quando o processo finalizado o mtodo altera o valor de um flag,
que informa e envia o resultado do processamento para o LinkSmart Event Manager.
Esse um ponto importante na estrutura de orientao a objetos que permite a inte-
grao com outras implementaes como, por exemplo, usando o processamento em
73
Big Data. Esse processo teve resultados satisfatrios quanto aos tempos de execuao,
no havendo a necessidade de se implementar usando a tecnologia de Big Data.
3.4.3 Implementao do servio de deteco de outlier
O servio de deteco de outlier possui a mesma estrutura dos servios de clustering e de

estimao de valores.
Figura 24 - Diagrama de Classes do servio de deteco de outlier implementado no mdulo Pattern Manager.
A Figura 24 ilustra o diagrama de classes implementado nesse servio. Nela observa-se o

pacote existente eu.linksmart.pattern e os novos pacotes adicionados outlier e hadoop. As
74
seguintes classes foram implementadas:
PatternSubscription: essa classe possui a mesma estrutura criada nos servios de clus-
tering e estimao de valores.
PatternSubscriptionOutLier: essa classe estende a classe PatternSubscription e agrega

novos mtodos relacionados ao servio de deteco de outlier, mtodos como: inputIn-
stance, que possui a mesma funo descrita no servio de clustering, isOutLier que
estima se uma dada instncia ou no um outlier, setAttributesOutLier que define os
parmetros a serem usados pelo algoritmo, runPattern que inicia a execuo de um
processo de deteco de outlier, finishedRunIsOutLier que notifica o trmino de um
processo de deteco de outlier e, por fim, o mtodo returnResultPatternClassification
que retorna o resultado do processamento. Essa classe, assim como nos outros servios,
no implementa o algoritmo, ela possui uma instncia de PatternOutLier que delega
a implementao e execuo do processo para outra classe. Essa soluo permite o
desacoplamento do mdulo e da implementao concreta do algoritmo e facilita a in-
troduo de novas implementaes ou de novos algoritmos.
PatternOutLier: essa Interface define a estrutura e mtodos para que uma classe seja um
PatternOutLier. Ela define a estrutura dos seguintes mtodos: inputInstance, isOutLier,
runPattern, returnResultPatternClassification, setAttributesOutLier e finishedRunIsOut-
Lier.
PatternOutLierHadoopImpl: essa a classe mais importante desenvolvida no servio de

deteco de outlier. Ela implementa a Interface PatternOutLier e todos os seus mtodos
propostos. Ela implementa o algoritmo de clustering k-means e calcula o raio de cada
grupo encontrado, informao que utilizada para estimar se uma dada instncia ou
no um outlier. Essa implementao tambm est integrada tecnologia de Big Data,
Hadoop e Mahout para a implementao e execuo do algoritmo k-means.
SimpleKMeansOutLierHadoop: essa classe implementa a integrao e execuo do al-

goritmo em um thread na instncia do Hadoop.
ResultPatternClassificationOutLier: essa classe contm os atributos necessrios de um

resultado de execuo do algoritmo de deteco de outlier. Um objeto de ResultPat-
ternClassificationOutLier pode ser enviado para uma aplicao para que ela possa usar
as informaes sobre a identificao dos outliers. Esse resultado possui informaes
sobre os grupos encontrados no algoritmo de agrupamento, os respectivos centrides de
cada cluster e seu respectivo raio.
75
Na implementao inicial, foi utilizado o algoritmo de deteco de outliers presente no
framework Weka, mas que no forneceu resultados satisfatrios no contexto de IoT, quanto
aos tempos de execuo. Optou-se pela busca de implementaes de algoritmos de deteco
de outliers utilizando a tecnologia de Big Data e no foi encontrado. O desenvolvimento e
abordagem aqui descritos so uma contribuio original desta pesquisa, conforme discutido
em Souza e Amazonas (2015)c.
Os algoritmos implementados podem ser substitudos por novas implementaes devido
estrutura de orientao a objetos desenvolvida, que permite esse desacoplamento. Essa
abstrao um importante aspecto da arquitetura de IoT aqui desenvolvida.
3.4.3.1 Algoritmo de deteco de outlier usando Big Data e o algoritmo de clustering k-

means
De acordo com Zaki e Meira (2014), abordagens que utilizam medidas de proximidade
podem ser utilizadas para a deteco de outlier. Lei et al. (2012)b desenvolveram abordagens
que utilizam algoritmos de clustering para a deteco de outliers. Tomando como base essas
descries, foi desenvolvida a proposta de algoritmo de deteco de outlier utilizando a
tecnologia de Big Data e algoritmo de clustering k-means.
Essa implementao possui os seguintes passos:
1. A aplicao insere os dados brutos para a criao do modelo de clustering.
2. executado o algoritmo de clustering Canopy (NAYAK et al., 2015), com os dados

iniciais para se propor a quantidade de clusters existentes no modelo, usando a imple-
mentao presente no framework Mahout.
3. Se executa o algoritmo k-means, com a quantidade de centrides retornadas pelo algo-

ritmo Canopy, de modo a criar o modelo de clusters, tambm usando a implementao
presente no framework Mahout (GIACOMELLI, 2013).
4. So resgatadas as informaes sobre os clusters, os centrides e os respectivos raios,

gerados pela execuo do algoritmo k-means.
5. Com base nesses valores o mtodo isOutLier pode ser usado. Sua implementao cal-
cula a distncia Euclidiana (DOUGHERTY, 2012) de uma dada instncia para todos
os centrides e caso essa distncia seja maior que o raio para cada cluster e centride a
instncia classificada como um outlier.
A Figura 25 ilustra a abordagem proposta.

76
Figura 25 - Deteco de Outlier: so observados trs clusters e respectivamente seus raios e dois pontos
considerados outlier.
Na Figura 25 so observados trs clusters gerados: cluster (1) representado pelos crcu-
los, cluster (2) representado pelo diamantes e cluster (3), presentados pelas estrelas, e dois
outliers representados pelo sinal + e marcados com o nmero 4, que esto fora dos crculos
de cada cluster, que representam seus respectivos raios.
3.4.4 Implementao da comunicao cross layer no modelo de IoT
Esta especificao de implementao da comunicao cross layer no modelo de IoT vai ao

encontro do objetivo secundrio 3, destacado na Seo 1.4. Os requisitos dessa comunicao
so:
do dispositivo para o Middleware ou servio: sempre que o dispositivo estiver utilizando

os algoritmos de estimao de valores ou deteco de outliers, o middleware ou camada
superiores devero ser avisados. Sendo assim, foram definidos os formatos de men-
sagens para essa troca de informao.
77
do Middleware/servio ou aplicao para o dispositivo: o modelo desenvolvido permite
que a aplicao ou o middleware escolham se o dispositivo deve desativar ou ativar o
uso dos algoritmos propostos, sendo assim, foram definidos os formatos de mensagens
para se permitir o controle dessas funcionalidades nos dispositivos, de modo que se
consiga ativar ou desativar cada funo especfica.
A implementao dessa comunicao poder ser incorporada nos elementos de disposi-

tivo e elementos de aplicao do LinkSmart Middleware e para dispositivos que no o te-
nham embutido, caber a especificao das interfaces e contratos de como se utilizar essas
funcionalidades, para que ele possa implement-lo e fazer uso dos mecanismos propostos.
A Figura 26 ilustra a estrutura especfica da comunicao cross layer proposta e imple-
mentada por meio do diagrama de classes.
O diagrama de classes representa a estrutura orientada a objetos desenvolvida. H duas
classes que representam os parmetros de comunicao cross layer: (1) a Interface Cross-
LayerParameter que cria a principal estrutura de um parmetro cross layer. Pode-se ob-
servar os contratos dos mtodos como, setLayer que responsvel por definir se a dada
camada dever ou no processar os dados, getLayer que responsvel por retornar a camada
em que est sendo feita a alterao, setFlag mtodo responsvel por definir uma varivel
binria que informa se o dado servio na determinada camada est ou no ativo. A classe
CrossLayerParameterImpl a implementao concreta dos mtodos definidos na Interface
CrossLayerParameter.
As classes ClassificationManager e ClassificationManagerImpl definem a estrutura e im-
plementao dos servios de reconhecimento de padres inseridos no LinkSmart. Novas
aplicaes podero usar a estrutura e servios implementados no LinkSmart Middleware,
mas para isso precisam definir os parmetros para as camadas fsica e a de middleware. A
qualquer momento, em tempo de execuo, os parmetros e comportamento das camadas
fsicas ou de middleware podero ser alterados. O software de driver de dispositivo ou o
gateway de IoT responsveis por conectar os dispositivos e o LinkSmart devem usar e in-
terpretar esses parmetros e alterar o comportamento dos dispositivos. A implementao e
abstrao orientada a objetos desenvolvida permitem futuras alteraes ou insero de novos
parmetros.
3.5 UTILIZAO DE TCNICAS DE SENSORES VIRTUAIS E PROCESSAMENTO

DE EVENTOS COMPLEXOS NO MODELO DE IOT
Essa especificao de implementao vai ao encontro do objetivo secundrio 2, destacado

na Seo 1.4. O processamento de eventos e dos dados ao longo do caminho que os dados
78
Figura 26 - Diagrama de classes com os parmetros da comunicao cross layer no mdulo de Pattern Manager.
percorrem na rede, similar ao sugerido em Gluhak et al. (2009). A cada salto na rede, no
necessariamente saltos em camada de rede, de acordo com o modelo OSI (COMER, 2015),
os dados e eventos so analisados e filtrados e ainda podero ser agregados a outros eventos,
79
criando assim valores e sensores virtuais, tambm filtrados e analisados, e ao final, observa-
se que ao longo do caminho aes podem ter sido executadas nos diversos ambientes e todo
o conhecimento agregado torna-se um conhecimento global do ambiente. A Figura 27 ilustra
um exemplo de aplicao do processamento dos eventos de dados gerados pela IoT.
Figura 27 - Exemplo de aplicao do processamento de eventos complexos e criao de sensores virtuais em
IoT.
No exemplo, se observa a aplicao da proposta de processamento dos eventos e cria-

o dos sensores virtuais, no contexto de consumo de energia em uma residncia, onde
os diversos dispositivos eletrnicos podero, de maneira autnoma, monitorar e criar um
escalonamento local para utilizao e reduo do consumo de energia eltrica. Os dados
de uma residncia podem ser analisados e agregados aos dados de outras residncias numa
80
mesma rua, com o objetivo de criar escalonamento entre todos os dispositivos, que por sua
vez, podero ser agregadas s informaes de outras ruas, bairros, municpios e estados que
possam ser atendidos por um mesma fornecedora de energia eltrica. A cada salto, as infor-
maes so analisadas e agregadas e ainda so executadas aes em cada ambiente, desde o
maior ao menor nvel de granularidade conforme se observa nas setas em sentido duplo.
Para as anlises utilizam-se os mecanismos de reconhecimento de padres inseridos no
LinkSmart Middleware, como estimao ou clustering, bem como para a criao dos valores
dos sensores virtuais, a partir da agregao dos valores oriundos de camadas inferiores no
contexto de sensores virtuais e inserindo os novos valores ou sensores virtuais como novas
fontes de dados para o middleware.
3.6 CONSIDERAES FINAIS
Neste captulo foram descritas as solues propostas e seus aspectos de implementao.

As solues vo ao encontro dos objetivos e hipteses levantados na Seo 1.4 e contribuem
para a anlise experimental, que visa validar as hipteses levantadas, de modo a contribuir
originalmente para a rea de pesquisa em questo.
Os aspectos relevantes de implementao so a abstrao desenvolvida atravs da orien-
tao a objetos, nesse caso, permitindo futuras implementaes de algoritmos e servios e
fcil acoplamento ao mdulo desenvolvido. A integrao com a tecnologia de Big Data de
maneira transparente para a camada de aplicao e para o prprio middleware outro aspecto
relevante a ser destacado na arquitetura proposta.
Todos os objetivos de pesquisa foram incorporados arquitetura proposta, com a imple-
mentao de algoritmos de reconhecimento de padres, como deteco de outliers e esti-
mao de valores na camada fsica ou Resource Manager ou na camada de middleware ou
servio, com algoritmos como, deteco de outliers, clustering e estimao de valores, e,
por fim, a comunicao cross layer, que possibilita a integrao entre todas as camadas e
funcionalidades disponibilizadas.
81
4 VALIDAO E EXPERIMENTOS COM A NOVA ARQUITETURA
PARA INTERNET DAS COISAS
Este captulo tem por objetivo documentar os experimentos e aplicaes desenvolvidas para a
validao da arquietura proposta e, adicionalmente, os algoritmos em execuo no mdulo de
reconhecimento de padres desenvolvido. Este captulo est organizado da segunte maneira:
a Seo 4.1 descreve o cenrio experimental utilizado em todas as aplicaes desenvolvidas
para os experimentos; a Seo 4.2 descreve a execuo do mdulo de reconhecimento de
padres juntamente com o LinkSmart Middleware; a Seo 4.3 descreve a execuo de uma
aplicao que valida a comunicao cross layer proposta; a Seo 4.4 descreve uma apli-
cao que valida o algoritmo de clustering; a Seo 4.5 descreve uma aplicao que valida o
algoritmo de deteco de outlier; a Seo 4.6 descreve a execuo de uma aplicao que va-
lida o algoritmo de estimao de valores e, por fim, a Seo 4.7 que descreve uma aplicao
mais abrangente que utiliza alguns dos algoritmos propostos num contexto mais prximo do
mundo real.
4.1 CENRIO DA VALIDAO EXPERIMENTAL
Na etapa de validao experimental foram desenvolvidas aplicaes para experimentos

com cada servio desenvolvido: clustering, deteco de outliers e estimao de valores. Em
seguida, a validao como prova de conceito da comunicao cross-layer e, por fim, uma
aplicao que testasse a arquitetura como um todo.
Em todas as aplicaes experimentais foi utilizado o cenrio da cidade inteligente Smart
Santander.
4.1.1 Descrio do Cenrio: Cidade Inteligente
O Projeto Smart Santander prope um cenrio experimental de grande escala para pesquisa,
que d suporte a aplicaes e servios para cidades inteligentes. De acordo com Santander
(2014), esse cenrio experimental nico, em larga escala, aberto e flexvel, que se prope a
estimular o desenvolvimento de novas aplicaes para usurio de vrios tipos, que incluem
pesquisas avanadas sobre IoT.
Os seguintes tipos de monitoramento ou dados esto disponveis (FACILITY, 2013):
Monitoramento ambiental: em torno de 2000 dispositivos de IoT, instalados em luzes de

rua ou fachadas de edifcios que disponibilizam diferentes tipos de dados como nveis
de temperatura, CO2 , rudo, luminosidade ou presena de veculos.
82
Gerenciamento de reas externas de estacionamento: em torno de 400 sensores de esta-
cionamento, instalados abaixo do asfalto em reas do centro da cidade, para se detectar
vagas de estacionamento disponveis.
Monitoramento ambiental mvel: essa classe de sensores estende o monitoramento am-

biental dos pontos estticos. Esses dispositivos foram instalados em 150 veculos pbli-
cos, que incluem nibus, txis e carros de polcia.
Monitoramento da intensidade de trfego: em torno de 60 dispositivos foram instalados

em localizaes da cidade de Santander, de modo a mensurar parmetros como volume
de trfego, ocupao, velocidade dos veculos ou tamanhos das filas.
Guia para vagas de estacionamento: as informaes das vagas de estacionamento so

exibidas em 10 painis localizados nas esquinas das principais avenidas, de modo a
guiar os motoristas s vagas disponveis.
Irrigao de parques e jardins: em torno de 50 dispositivos instalados em duas reas

verdes da cidade, monitoram a irrigao, utilizando parmetros como mistura de tem-
peratura e humidade, pluvimetro e anemmetro, de modo a possibilitar a melhor efi-
cincia na irrigao.
Realidade aumentada: em torno de 2000 etiquetas Identificao por Radiofrequncia

(RFID) ou Quick Response (QR) Code esto instaladas nos principais pontos de in-
teresse da cidade, distribuem informaes dos pontos tursticos, shoppings, lugares
pblicos, praas, parques, dentre outros. A Figura 28 ilustra a aplicao disponvel,
que utiliza o conceito de realidade aumentada e as informaes existentes.
Participao no sensoriamento: nesse cenrio os usurios que utilizam os dispositivos

mveis enviam informaes de sensoriamento, como coordenadas de Sistema de Posi-
cionamento Global (GPS), bssula, dados ambientais como rudo, temperatura, dentre
outros. Os usurios podem se inscrever para receberem ou relatarem informaes so-
bre os tipos de eventos especficos, que estejam ocorrendo em determinados locais da
cidade.
Um dos principais objetivos do projeto abastecer a comunidade cientfica de facilidades

de experimentao, usurios finais e prover servios de modo a diminuir barreiras tecnolgi-
cas e sociais com relao ao conceito IoT no dia-a-dia. A ideia atrair o interesse se demons-
trando a utilidade da plataforma Smart Santander, com um aspecto que aborda a incluso
de um conjunto de aplicaes; aplicaes em reas que possuem alto potencial de impacto
83
Figura 28 - Aplicao disponvel com realidade aumentada e as informaes na cidade de Santander.
Fonte: (FACILITY, 2013).
para os cidados, demostrando diversidade, dinamismo e escala, essencialmente no avano

em solues e protocolos, atrair indstrias, comunidades de usurio, pesquisadores e ou-
tras entidades que podero desenvolver novos servios, aplicaes, protocolos e algoritmos
(FACILITY, 2013) (KRCO et al., 2012).
4.1.2 Dados obtidos
Os dados obtidos do projeto Smart Santander esto disponveis em Jara, Genoud e Bocchi
(2014). Foram coletados dados de temperatura, longitude, latitude do ponto de coleta, data e
hora e o identificador do sensor, conforme os perodos descritos na Tabela 3:
Tabela 3 - Tabela com a descrio dos dados de temperatura obtidos no projeto Smart Santander.
Ms Dia Inicial Dia Final Qtd. Pontos de Coleta Qtd. Reg.
Abril 01 07 83 140845
Julho 29 30 66 45064
Agosto 01 04 70 98900
Dezembro 02 08 83 199075
Foram coletados dados de trfego com os atributos como a quantidade de veculos, taxa
de ocupao do local, longitude, latitude, data e hora e o identificador do sensor, conforme
os perodos descritos na Tabela 4:
Todos os dados foram inseridos num banco de dados Mysql (AFFILIATES, 2014), em
84
Tabela 4 - Tabela com a descrio dos dados de trfego obtidos no projeto Smart Santander.
Ms Dia Inicial Dia Final Qtd. Pontos de Coleta Qtd. Reg.
Abril 01 07 38 407786
Julho 29 30 38 109516
Agosto 01 04 38 218784
Dezembro 02 08 38 436112
duas tabelas, que serviro para simular as camadas 1 e 2, para as aplicaes e experimentos
a serem desenvolvidos.
Observa-se que o cenrio proposto vai ao encontro dos diversos requisitos propostos na
literatura encontrada, como desenvolvimento de uma plataforma para o desenvolvimento de
aplicao para a IoT, desenvolvimento de um modelo distribudo para minerao de dados
na IoT, desenvolvimento de novos mecanismos para processamento, armazenamento e ge-
renciamento dos dados intrinsecas arquiteturada da rede, inferncia de comportamentos e
otimizao de trfego e uso de energia.
4.2 MDULO DE RECONHECIMENTO DE PADRES EM EXECUO
A Figura 29 exibe uma pgina WEB com o status de execuo do LinkSmart com todos
os seus servios iniciados. Pode-se observar o nome do servio ClassificationManagerImpl
sublinhado, que est em execuo e registrado no LinkSmart middleware com o
HID 0.0.0.7721126273323016844.
Foi desenvolvido um Servlet para a visualizao de todos os PHID registrados no Pattern
Manager. A Figura 30 ilustra o Servlet em execuo.
Na Figura 30, pode-se observar o HID ao qual o Pattern Manager foi registrado como
servio no LinkSmart, nesse caso com o valor 0.0.0.7721126273323016844, e os 5 PHIDs
registrados no Pattern Manager, com suas respectivas classes de servios e a quantidade de
instncias de dados inseridas no mdulo de reconhecimento de padres.
4.3 APLICAO DE TESTE DA COMUNICAO CROSS LAYER
Foi desenvolvida uma aplicao que simula o resource manager e uma aplicao cliente
de teste.
Os dados utilizados nesse experimento e em todos os prximos experimentos descritos
nas prximas sees so provenientes da Guildfords facility proposto no projeto Smart San-
tander (NATI et al., 2013).
85
Figura 29 - Pgina com o status do LinkSmart.
Figura 30 - Pgina de status gerada pelo Servlet do gerenciador de padres.
Os dados requisitados foram inseridos em um banco de dados Mysql (DUBOIS, 2014)

e foi desenvolvida uma classe que simula o resource manager. Essa classe prov dados
86
como temperatura e luminosidade de um sensor chamado node25. Essa experimentao,
bem como as aplicaes descritas nas experimentaes dos algoritmos de clustering e de
deteco de outlier, nas Sees 4.4 e 4.5, respectivamente, so provas de conceito, por isso
o uso dos dados de um nico sensor, porm a arquitetura desenvolvida est preparada para
processar grandes volumes de dados de acordo com o conceito de Big Data.
Para ilustrar a proposta de comunicao cross layer foram criadas duas aplicaes: (1)
ResourceManager que representa a camada fsica e responsvel por resgatar os dados a
partir do banco de dados Mysql e envi-los para o pattern manager no LinkSmart Middle-
ware; e (2) a aplicao cliente responsvel por controlar o comportamento das camadas de
Middleware e fsica.
Figura 31 - Aplicao que simula o Resource Manager que representa a camada fsica na validao da comu-
nicao cross layer.
A Figura 31 ilustra a execuo da aplicao que simula o Resource Manager que repre-
senta a camada fsica. Essa aplicao implementa duas funes: ela possui a implementao
do algoritmo de estimao de valores, de modo a estimar valores caso o dado real seja per-
dido e seja relevante no contexto da aplicao; e a implementao do algoritmo de deteco
de outlier, caso um dado com valor errado represente um problema para a aplicao, con-
forme o proposto em Souza e Amazonas (2013).
Outro aspecto relevante dessa aplicao a capacidade de enviar e receber parmetros a
partir e para as camadas de Middleware e aplicao. A aplicao inicia a conexo com a
camada de Middleware, informa o estado dos servios e comea a enviar as instncias com
valores de temperatura e intensidade de luminosidade do ambiente. Em um dado momento a
camada fsica recebe uma mensagem alterando o estado do parmetro de estimao de valo-
res de modo a iniciar esse servio nessa camada. Essa execuo ilustra como a comunicao
87
cross layer altera o comportamento da camada de fsica em tempo de execuo.
A Figura 32 ilustra a execuo da aplicao cliente desenvolvida para o experimento.
Figura 32 - Execuo da aplicao cliente desenvolvida para o experimento da comunicao cross layer.
A aplicao ilustrada pela Figura 32 possui duas funes: (i) ilustrar a aplicao cliente da
camada de Middleware; (ii) implementar a funo de controle do comportamento da camada
fsica e da middleware. A partir da interface grfica da aplicao o usurio pode desativar
ou ativar os servios de estimao de valores e deteco de outlier na camada fsica e os
servios de estimao de valores, deteco de outlier e clustering presentes na camada de
middleware.
Na execuo da aplicao ilustrada pela Figura 32, pode-se observar que o programa inicia
a conexo com o LinkSmart e comea a receber as instncias com seus respectivos valores.
No momento posterior, o usurio seleciona o checkbox solicitando a execuo do servio de
estimao de valores na camada fsica. Logo aps, o usurio marca o checkbox para iniciar
o servio de deteco de outlier na camada de middleware e, logo aps, o desmarca para
desabilitar o mesmo servio na camada de middleware, aes que ilustram como a comuni-
cao cross layer se faz necessria para o gerencimeto do comportamento dos servios nas
camadas inferiores do modelo de IoT proposto.
A Figura 33 ilustra um trecho do arquivo de LOG gerado pela execuo dos servios
implementados no ClassificationManager embutido no LinkSmart Middleware.
Na Figura 33 pode-se observar o trecho do arquivo de LOG que se refere execuo do
ClassificationManager no momento de execuo experimental das aplicaes de Resource
88
Figura 33 - Trecho do arquivo de LOG de execuo dos servios do ClassificationManager.
Manager e cliente. O trecho de LOG exibe algumas linhas referentes inicializao do

ClassificationManager e dos servios de reconhecimento de padres, seguido pelas aes
das aplicaes IoTResourceManager, que representa a camada fsica e ClientIoTCrossLay-
erTest, que representa a camada de aplicao. Observa-se a sequncia de aes ilustradas
na execuo das aplicaes, como o Resource Manager enviando as instncias para o Link-
Smart, a aplicao cliente enviando mensagens para a camada fsica com o parmetro para
inciar o servio de estimao de valores. A camada de aplicao enviando as mensagens para
a camada de Middleware para iniciar e, posteriormente, para desativar o servio de deteo
de outlier nessa camada.
Percebe-se pela experimentao descrita que a camada de aplicao se comunica com as
camadas fsica e de middleware de modo a alterar seus comportamentos.
4.3.1 Concluses da experimentao da comunicao cross layer
Nesse experimento foi validada a implementao da estrutura de comunicao cross layer

na arquitetura de IoT. A estrutura integra-se nova arquitetura de IoT implementada atravs
da estenso do LinkSmart Middleware com os servios de deteco de outlier, estimao de
valores e algoritmo de clustering na camada de middleware, e a implementao de servios
para a deteco de outlier e estimao de valores na camada fsica.
89
A implementao da estrutura proposta permite que a camada de aplicao interaja com
as camada inferiores no modelo de IoT e modifique seus comportamentos, mais especifi-
camente nas camadas fsica e de middleware. A camada de aplicao pode habilitar ou
desabilitar os servios existentes.
As aplicaes desenvolvidas para o experimento validam a proposta de comunicao cross
layer integradas arquitetura de IoT, com servios de reconhecimento de padres e dados
reais provinientes do projeto Smart Santander.
4.4 APLICAO DE TESTE DO SERVIO DE CLUSTERING
A classe Resource Manager requisita um PHID de modo a se registrar como um nova

origem de dados no Pattern Manager. Nesse momento passado parmetro de configurao
de algoritmo, que pode ser de deteco de outlier, estimao de valores ou de clustering. No
prximo passo, a classe pode enviar os dados ao Pattern Manager.
Figura 34 - Execuo da classe Resource Manager para experimentao do servio de clustering na camada de
middleware.
A Figura 34 ilustra a aplicao que simula o Resource Manager em execuo. A aplicao

requisita o servio ClassificationManagerImpl, que representa o servio do Pattern Manager
e solicita um PHID, de modo a se registrar no mdulo. Observa-se que a aplicao foi
registrada com o PHID 9167016986134 e ela passa a enviar as instncias de dados para o
90
Pattern Manager. Esses dados correspondem a dados de temperatura e luminosidade da base
de dados no dia 01/02/2014, no horrio entre 00 : 00 : 00 e 23 : 59 : 59.
A aplicao cliente desenvolvida, implementa duas funes: (i) utilizar o mdulo de Pat-
tern Manager como cliente; e (ii) usar os servios do novo mdulo como um coordenador, de
modo a controlar a execuo do algoritmo. A Figura 35 ilustra a execuo dessa aplicao.
Figura 35 - A aplicao cliente para experimentao do servio de clustering na camada de middleware.
Na Figura 35 pode-se observar a aplicao cliente requisitando e listando todas as classes

Resource Manager registradas no Pattern Manager. Em seguida, a classe inicia a execuo
do algoritmo de clustering. Quando a execuo do algoritmo finalizada a classe recebe uma
notificao enviada pelo servio do LinkSmart Event Manager. Logo aps, a classe solicita
a classificao de uma nova instncia e as informaes sobre os clusters encontrados pelo
algoritmo. A instncia passada como parmetro foi classificada no cluster 4, sendo assim,
ela composta por valor de tempo, temperatura e intensidade de luz que est mais prxima
91
do centride 4, sem exceder o raio do cluster encontrado.
Pode-se observar que os 5 clusters encontrados, expressam consistentemente a classifi-
cao existente na variao dos dados de temperatura e luminosidade em um dia. A Figura
36 exibe todas as instncias em um grfico em 3D.
Figura 36 - Todas as instncias mostradas em um grfico 3D e todos os clusters identificados por nmeros e
diferentes cores.
Na Figura 36 os clusters esto identificados por nmeros e diferentes cores. O eixo x re-
presenta a variao de tempo, entre 00:00:01 e 23:59:59, porm, no grfico no exibidos sem
a seprao por :; o eixo y representa a intensidade de luz, que varia entre 0 e 700, porm o
sensor de luminosidade retorna valores mnimos e mximos entre 0 e 1024; e o eixo z repre-
senta a temperatura, que varia entre 16 e 24 graus Celsius. Pode-se observar que o algoritmo
cria clusters consistentes ao separar todas as instncias nos 5 clusters, conforme a seguir:
cluster (1) representado em ciano, cluster (2) representado em azul, cluster (3) representado
em magenta, cluster (4) representado em verde, e, por fim, o cluster (5) representado em
vermelho. Em cada centro de cluster, esto localizados crculos pretos, que representam os
centrides de cada cluster encontratos pelo algoritmo e um crculo maior, que representa o
raio de cada cluster.
O modelo proposto pelo algoritmo foi validado atravs do Sum of the Square Errors (SSE)
92
e pelo Silhouette Coefficient, sugerido em Zaki e Meira (2014). Para se encontrar a quanti-
dade ideal de clusters optou-se por se mininizar o valor de SSE, porm no se chegar a zero.
Ao se desenhar o grfico de decaimento do SSE observa-se a acentuao da curva ou um
ponto de mergulho.
Os valores obtidos pelo decaimento do SSE so mostrados na Figura 37.
Figura 37 - Decaimento do SSE pela quantidade de clusters.
Na Figura 37 observa-se o decaimento do valor de ESS, no qual no eixo das abscissas est
a quantidade de clusters e no eixo das ordenadas os valores de SSE. Adotando o critrio de
SSE < 1.63145 como ponto de mergulho da curva, pode-se verificar no grfico que o valor
ideal de clusters 5.
O silhouette coefficient fornece valores entre 0 e 1, sendo que a quantidade ideal de clusters
deve possuir um valor mais prximo de 1. Os valores obtidos pelo clculo do Silhouette
coefficient so mostrados na Figura 38, com os valores de Silhouette coefficient no eixo das
ordenadas e as respectivas quantidades de clusters no eixo das abscissas. O ponto com valor
de Silhouette coefficient mais prximo de 1 5.
Assim, a quantidade ideal de clusters para o modelo proposto de 5 clusters e a imple-
mentao proposta prope e classifica o modelo a contento, demonstrando que a arquitetura
93
Figura 38 - Valores do Silhouette coefficient pela quantidade de clusters.
e a implementao do servio de clustering produzem resultados satisfatrios.
4.4.1 Concluses da experimentao do servio de clustering
O desenvolvimento de uma aplicao especfica est fora do escopo desta pesquisa, pois
o principal objetivo e contribuio a arquitetura e o processameto nas camadas inferiores
do modelo de IoT e no somente na camada de aplicao, como ocorre no modelo OSI.
A abordagem modular desenvolvida permite a incorporao de diferentes implementaes
algortmicas e garante a independncia entre a implementao dos algoritmos e arquitetura.
A implementao da aplicao de teste ilustra a validao da arquitetura e do servio de
clustering com bases de dados reais do projeto Smart Santander. Sua execuo permite
verificar que a nova arquitetura com o mdulo de anlise reconhecimento de padres com
Big Data, baseada na arquitetura IoT-A em funcionamento com o LinkSmart Middleware
consegue modelar dados do mundo real na camada de middleware e diminuir a carga de
processamento na camada de aplicao.
O servio de clustering pode ser til para a contextualizao e classificao dos dados
94
oriundos das diferentes fontes de dados no contexto de IoT, pode ser utilizado para a criao
de sensores virtuais, como por exemplo, uma aplicao que necessite apenas do contexto
de temperatura e taxa de ocupao de determinadas reas da cidade, que no necessite dos
dados reais e precisos dos diversos sensores. O servio de clustering poderia apenas informar
se a temperatura e a taxa de ocupao esto altos ou baixos
4.5 APLICAO DE TESTE DO SERVIO DE DETECO DE OUTLIER
A aplicao cliente desenvolvida neste experimento possui trs funes: (i) ser um Re-
source Manager que resgata os dados e os insere no Middleware, (ii) ser um cliente do
mdulo de reconhecimento de padres; e (iii) usar o mdulo como coordenador, de modo a
configurar e controlar a execuo do algoritmo de deteco de outlier.
A Figura 39 ilustra a execuo da aplicao de teste do servio de deteco de outlier
desenvolvido.
Essa aplicao inicia a conexo com o LinkSmart Middleware, resgata e insere todas as
instncias no mdulo, cria o modelo com as instncias reais e, por fim, o resgata do Mi-
ddleware. No prximo passo, a aplicao gera novas instncias para a anlise, submete cada
instncia ao modelo criado e exibe os resultados na interface grfica.
Conforme se observa em Han, Kamber e Pei (2011) e Zumel, Mount e Porzak (2014),
para se avaliar o desempenho de um preditor ou classificador pode-se construir uma curva
Receiver Operation Characteristics (ROC), mas se faz necessrio reduz-la a um valor es-
calar. Para isso, pode-se calcular a rea abaixo da curva ou Area Under Curve (AUC), que
assumir valores entre 0 e 1. Um classificador perfeito possui AUC igual a 1 e classificadores
aleatrios possuem valores de AUC iguais a 0, 5. Observa-se que o ponto (0, 1) no espao
ROC representa um classificador perfeito e qualquer classificador que estiver acima da linha
diagonal que vai do ponto (0, 0) ao ponto (1, 1) dado como melhor do que um classificador
aleatrio e possuir valor de AUC acima de 0, 5 (ZUMEL; MOUNT; PORZAK, 2014). A
Figura 40 exibe a curva ROC gerada considerando os resultados do classificador criado a
partir do modelo de dados real gerado pelo algoritmo de deteco de outlier proposto.
A sua (AUC) com o valor de 0.8967, que considerado um bom resultado para um classi-
ficador.
Para esse modelo de teste criado, foram inseridas 8595 instncias reais, 8595 instncias
outliers criadas com valores aleatrios a partir de instncias reais. O conjunto com as ins-
tncias reais e as instncias outliers foram submetidas anlise do algoritmo de deteco
de outlier implementado. A aplicao desenvolvida exibe todas as instncias submetidas ao
modelo, respectivamente com o resultado de sua classificao se outlier, com o resultado
95
Figura 39 - Execuo da aplicao de teste do servio de deteco de outlier desenvolvido.
verdadeiro ou falso. Este conjunto de resultados foi utilizado para gerar a curva ROC.
A execuo da aplicao utilizou dados com a temperatura e luminosidade referentes ao
perodo entre 01/02/2014 s 00 : 00 : 00 e 01/02/2014 s 23 : 59 : 59. Foram executados
testes utilizando valores obtidos em perodos dirios para todos os dias do ms de fevereiro.
Obteve-se respectivamente os seguintes valores de mnimo, mdio e mximo AUC 0.8456,
0.8762 e 0.9465 para os testes executados. A partir destes resultados pode-se observar que o
algoritmo teve um desempenho satisfatrio.
A aplicao desenvolvida verifica as duas funes de: (i) implementar a coordenao de
execuo e parametrizao do algoritmo, de se carregar as instncias e, posteriormente, criar
o modelo no pattern manager; e (ii) verificam a arquitetura integrada ao LinkSmart Middle-
ware. Uma aplicao que utilize a arquitetura desenvolvida com o servio de detecto de
outlier receber todas as instncias sem nenhum outlier, eliminando uma carga maior de
processamento em se analisar essa situao no conjunto completo de dados. A arquitetura
96
Figura 40 - Curva ROC gereda a partir os resultados do classificador gerado com o modelo criado pelo algoritmo
de deteco de outlier desenvolvido.
envia informaes filtradas para todas as aplicaes clientes, que reduz o processamento
na camada de aplicao, o que contribui para maior eficincia energtica e o aumento da
escalabilidade, quanto quantidade de clientes com maior ou menor poder computacional.
4.5.1 Concluses da experimentao do servio de deteco de outlier
A implementao da aplicao de teste valida o algoritmo proposto e a nova arquitetura

de IoT usando bases de dados reais do projeto Smart Santander. A execuo ilustrou o
funcionamento da arquitetura integrada ao LinkSmart e que o servio de deteco de outlier,
implementado na camada de middleware, consegue criar modelos a partir de dados reais.
As curvas ROC geradas a partir dos resultados ilustram o bom desempenho do algoritmo de
deteco de outlier proposto, e que uma das contribuies originais da pesquisa (SOUZA;
AMAZONAS, 2015).
O servio de deteco de outlier ser til para aplicaes nas quais a preciso das leituras
de dados sejam crticas e quaisquer valores distantes dos reais represetem aes com grandes
impactos errnoes no ambiente.
97
4.6 APLICAO DE TESTE DO SERVIO DE ESTIMAO DE VALORES
A aplicao desenvolvida nesse experimento possui trs funes: (i) ser um Resource
Manager que resgata os dados e os insere no Middleware, (ii) ser um cliente do mdulo de
reconhecimento de padres; e (ii) usar o mdulo como coordenador, de modo a controlar a
execuo do algoritmo de estimao de valores. Essa classe prov dados como temperatura
e luminosidade do sensor node25.
A Figura 41 ilustra a execuo da aplicao desenvolvida para os experimentos com o
servio de estimao de valores.
Figura 41 - Execuo da aplicao de teste do servio de estimao de valores desenvolvido.
Pode-se observar na Figura 41 que a aplicao desenvolvida possui as trs funes: (i)
de Resource Manager com que ela resgata os dados da base de dados, (ii) como coor-
denador, inicia a conexo com o LinkSmart, requisita um PHID, nesse caso com o valor
98
6587741324587 e, logo aps, inicia o envio das instncias para o PatternManager e no final
da insero a aplicao solicita a criao do modelo de regresso linear no Middleware, (iii)
como aplicao cliente, ela solicita o modelo de regresso e faz os testes com a tcnica de
validao cruzada, de modo a validar o modelo criado pelo Middleware.
Como resultados a aplicao exibe Mean Absolute Error (MAE), com o valor 0, 3153,
e o Root Mean Squared Error (RMSE) (CHAI; DRAXLER, 2014), com o valor 0, 4096,
que so indicadores estatsticos de desempenho. A Figura 42 ilustra as instncias e valores
estimados exibidos como resultado na aplicao, no processo de validao cruzada.
Figura 42 - Grfico com as instncias reais e seus respectivos valores estimados.
Os valores estimados esto prximos dos valores reais e os valores de MAE e RMSE
so relativamente baixos, ou seja, o modelo criado pelo PatternManager consegue um bom
desempenho para esse contexto de dados ou aplicao.
4.6.1 Concluses da experimentao do servio de estimao de valores
A aplicao de teste desenvolvida verifica a aplicabilidade e funcionalidade do servio

de estimao de valores no modelo de IoT. Observou-se experimentalmente que o mdulo
99
desenvolvido conseguiu modelar o conjunto de dados reais e contexto de aplicao ade-
quadamente com desempenho satisfatrio.
O servio de estimao de valores ser til para aplicaes nas quais a preciso das leituras
de dados sejam crticas, ele poder ser utilizado sempre ocorreram erros ou elas sejam ine-
xistentes.
4.7 APLICAO ABRANGENTE NO CENRIO DE CIDADE INTELIGENTE
Esta seo tem por objetivo descrever uma aplicao para o mundo real que utilize as fun-
cionalidades do novo modelo de IoT proposto, os algoritmos e os servios de reconhecimento
de padres nas camadas fsica e de middleware.
Como aplicao experimental foi desenvolvido um aplicativo que cria rotas na cidade de
Santander utilizando as prioridades definidas pelo usurio com base nas variveis existentes,
como temperatura, taxa de ocupao e distncia em metros. Esse aplicativo realiza uma
prova de conceito utilizando o modelo de IoT, com resgate de dados do ambiente e tomada
de deciso por parte da aplicao, que inicia aes no ambiente, nesse caso, criando rotas
possveis para o usurio com base em suas preferncias e utilize a nova arquitetura proposta
com os algoritmos e os servios de reconhecimento de padres na camada fsica e middle-
ware.
A Figura 43 ilustra o diagrama de caso de uso do aplicativo proposto.
Figura 43 - Caso de uso do aplicativo para a criao de rotas com base nas prioridades definidas pelo usurio.
O aplicativo gera rotas com base nas prioridades definidas pelo usurio atravs da inter-
face. O caso de uso criar rota, inclui a obteno dos dados atravs da implementao da
interface com o LinkSmart Middleware que, por sua vez, utiliza, estima ou detecta outliers
com base nos dados obtidos do ambiente.
A implementao desse aplicativo utiliza os algoritmos da camada fsica e do mdulo
100
de anlise e reconhecimento de padres propostos na pesquisa e adicionados ao LinkSmart
Middleware. A prova de conceito contempla as seguintes propostas e implementaes:
Deteco de outliers: de modo a detectar anomalias ou mudanas bruscas na tempera-

tura ou nas taxas de ocupao dos ambientes, caso ocorram medies errneas o mi-
ddleware ou a camadda fsica podero perceber e informar s camadas superiores.
Predio de valores: caso ocorram as leituras errneas, falhas de comunicao com

os sensores ou sejam detectados outliers a camada fsica ou de middleware podero
estimar os valores.
Criao de sensores virtuais: para a agregao e abstrao dos valores e tipos de dados
para aplicaes mais abrangentes no contexto de temperatura e trnsito de bairros e da
cidade como um todo, o aplicativo criar um nico valor para caracterizar cada uma das
rotas possivelmente escolhidas.
Sugere-se a utilizao dos mecanismos de comunicao Cross Layer de modo a permitir

o controle do comportamento das camadas fsica e middleware.
A camada inferior tem por funo resgatar os dados do ambiente, atravs do Framework
do Smart Santander ou de outras aplicaes mveis e inser-los no LinkSmart Middleware ou
camada imediatamente superior, nesse caso, a implementao realizada atravs de classes
que resgatam os dados do banco de dados Mysql. Nessa camada, foram implementados os
algoritmos de deteco de outlier e de estimao de valores pois, caso, o sensor ou a classe
que o representa no tiverem a leitura no dado momento, o algoritmo poder estimar o valor.
Caso ocorra um erro de leitura e esses valores estejam muito distantes dos valores comuns,
o algoritmo de deteco de outlier poder alertar as camadas superiores e inclusive usar o
servio de estimao para um valor mais prximo de um valor real.
A camada imediatamente superior representada pelo LinkSmart Middleware, ao qual
foram agregados os mdulos de anlise e reconhecimento de padres a serem utilizados nas
implementaes. Nesse caso, a implementao recebe os valores da camada inferior e tem a
possibilidade de estimar valores ou detectar outliers sobre as leituras recebidas.
A camada superior representa a aplicao cliente, que poder fazer uso dos dados brutos
ou das informaes geradas pela execuo dos algoritmos na camada de Middleware e fsica.
Tendo em vista que no h uma aplicao de controle, optou-se por criar uma configu-
rao fixa no aplicativo, nesse caso desabilitando as funcionalidades de deteco de outlier
e estimao de valores na camada fsica e habilitando-as na camada de middleware, desse
modo, os algoritmos implementados no LinkSmart estimam valores, caso no existam, ou
detectam outliers, que esto presentes nos dados obtidos.
101
O aplicativo desenvolvido utiliza os dados de temperatura e taxa de ocupao existentes
entre os dias 01 e 07 de abril de 2013. A interao com o usurio ocorre atravs do nave-
gador de Internet: o aplicativo exibe os pontos de coleta de dados de temperatura e taxa de
ocupao, utilizando a Google Maps API (INC., 2014). Para os pontos de coleta de tem-
peratura se exibe um crculo em vermelho com a medio e para cada ponto de coleta de
taxa de ocupao se exibe um crculo azul, em ambos os casos o dimetro do crculo indica
a medio existente ou estimada.
Com base nas prioridades que o usurio define para as variveis, o aplicativo escolhe uma
melhor rota. Para cada envio de formulrio o aplicativo incrementa uma hora nos dados de
leitura e a cada vinte e quatro envios o aplicativo incrementa a data, sendo que a data limite
07 de abril de 2013.
Foi utilizada a Eq.10 de modo a identificar e eleger a rota mais interessante no dado mo-
mento, criando assim o sensor virtual.
distanceii+1 distancemin
Wri = 1i i0 temp t + occupation o + d
P tempi tempmin occupationi occupationmin
max tempmin max occupationmin
i distancemax distancemin
(10)
Onde, Wri representa a adequao de uma dada rota. Sua composio o somatrio do valor
da temperatura normalizado e multiplicado pela prioridade da temperatura, somado ao valor
de ocupao normalizado e multiplicada pela prioridade da taxa de ocupao, somado
distncia em metros normalizada, do ponto i at o prximo ponto da rota e, por fim, dividido
pelo nmero total de saltos da rotai . O aplicativo possui valores pr-definidos de prioridades
onde, Baixa possui o valor 1, Mdia Baixa possui o valor 0, 75, Mdia possui o valor de 0, 5,
Mdia Alta possui o valor de 0, 25 e Alta possui o valor de 0, 1. Assim, a melhor rota dever
possuir o menor valor de Wi .
Existem 81 pontos de leituras de temperatura e 38 pontos de leitura para a taxa de ocu-
pao. Optou-se por fixar o ponto de origem e destino, de modo a ter um conjunto maior
de rotas e de leitura de ambas as variveis. Desse modo, as rotas definidas pelo aplicativo
possuem origem no ponto 175 e destino no ponto 257. Na Figura 44, ambos os pontos esto
destacados no mapa.
Observou-se que na base de dados h alguns outliers e, portanto, importante ativar o
servio de deteco de outliers na camada de middleware. A Figura 45 ilustra o mapa com o
servio de deteco de outlier desativado, exibindo trs pontos com leituras errneas para o
dado momento.
A Figura 46 ilustra a rota mais exibida no aplicativo, ao se atribuir prioridade alta para
taxa de ocupao e prioridades baixas para temperatura e distncia.
O aplicativo exibe a rota desenhada no mapa da cidade de Santander, por quais pontos ela
passa e quais as intensidades das leituras de temperatura e taxa de ocupao em cada ponto,
102
Figura 44 - Ponto de origem (175) e destino (257) indicados no mapa da cidade de Santander.
Figura 45 - Mapa das cidade de Santander exibindo pontos de temperatura e ocupao com o servio de de-
teco de outlier desativado.

103
Figura 46 - Primeira rota mais exibida pelo aplicativo.
no dado momento, nesse caso, s 0h e 59:59 do dia 01 de Abril de 2013.

A Figura 47 ilustra a segunda rota mais exibida no aplicativo, nesse caso ao se atribuir
prioridade alta para temperatura, ou seja, o usurio tem preferncia por pontos mais frios e
prioridades baixas para taxa de ocupao e distncia percorrida. Observam-se como opes
do aplicativo, a possibilidade de se remover ou exibir os cculos e pontos de leituda da tela,
deixando assim, uma visualizao mais limpa da rota proposta pelo aplicativo.
A Figura 47 exibe a melhor rota no horrio entre 2h e 2:59 do dia 01 de Abril de 2013.
A Figura 48 ilustra a terceira rota mais exibida no aplicativo, nesse caso, ao se atribuir
prioridade alta para temperatura e baixas para taxa de ocupao e distncia.
A Figura 48 exibe a melhor rota no horrio entre 9h e 9:59 do dia 02 de Abril de 2013.
Nesse intervalo de tempo a taxa de ocupao tem leituras mais altas, se comparada aos
horrios anteriores.
A Figura 49 ilustra a quarta possvel rota mais exibida, nesse caso tambm para prioridade
alta para temperatura e baixas para taxa de ocupao e distncia.
A rota exibida na Figura 49 a melhor no horrio entre 16h e 16:59 do dia 03 de Abril de
2013.
104
Figura 47 - Segunda rota mais exibida pelo aplicativo.
Figura 48 - Terceira rota mais exibida pelo aplicativo.

105
Figura 49 - Quarta rota mais exibida pelo aplicativo.
4.7.1 Concluses quanto ao cenrio experimental da cidade inteligente
Pode-se observar que o aplicativo sugerido junto ao cenrio do Smart Santander utiliza a
nova arquitetura de IoT e mdulos do LinkSmart Middleware desenvolvidos e propostos na
pesquisa, mais especificamente a deteco de outlier utilizando a tecnologia de BigData, es-
timao de valores na camada de middleware e a utilizao de tcnica de criao de sensores
virtuais, nesse caso ao se criar mtricas para a criao de rotas usando dados de sensores e
middleware de IoT.
Com esse estudo de caso comprova-se a utilidade dos mdulos desenvolvidos, de modo
a simplificar o desenvolvimento de aplicaes para IoT. Nesse caso, especificamente, se
poupam o trfego de rede e otimizam processamentos, pois no dado cenrio, o processa-
mento para a deteco de outliers e estimao de valores realizado uma nica vez pelo
middleware, sem a necessidade de um novo processamento na camada de aplicao.
106
5 CONCLUSES E TRABALHOS FUTUROS
Este captulo tem por objetivo resumir as concluses, os resultados da pesquisa e apresentar
sugestes para pesquisas futuras.
Este captulo est organizado da seguinte maneira, a Seo 5.1 traz as concluses da
pesquisa; a Seo 5.2 traz os resultados de pesquisa e publicaes; e, por fim, a Seo 5.3
descreve os trabalhos futuros propostos para esta pesquisa.
5.1 CONCLUSES
O tratamento e o processamento dos dados gerados com o modelo de IoT um aspecto

crucial e que foi abordado como tema principal desta pesquisa. Observou-se a necessidade
de mecanismos eficientes para o processamento e que eles no ocorram somente na camada
de aplicao e a necessidade de se ter um modelo de referncia para guiar o desenvolvimento
de aplicaes para IoT e de um Middleware que implemente esse modelo.
Dentro desse contexto, foi proposta a utilizao do modelo de referncia desenvolvido
pelo IoT-A e a utilizao do LinkSmart Middleware como plataforma para o desenvolvimento
de aplicaes e a introduo dos mecanismos de anlise e reconhecimento de padres nas
camadas fsica e de Middleware neste novo modelo de IoT.
Todos os objetivos de pesquisa elencados no Captulo 1 foram alcanados com as imple-
mentaes desenvolvidas, bem como seus respectivos experimentos.
Os experimentos demonstraram que o modelo IoT-A, juntamente com o LinkSmart Mi-
ddleware atendem aos requisitos para o desenvolvimento de aplicaes no contexto de IoT.
A nova arquitetura proposta permite o desenvolvimento de aplicaes de IoT e prov
servios para o reconhecimento de padres nas camadas fsica e de middleware, integrada
tecnologia de Big Data para processamento distribudo.
Cabe destacar que inicialmente o desenvolvimento com a plataforma de Big Data no era
um requisito para a implementao da soluo, porm, ao se verificar que a implementao
utilizando o framework weka, que implementa algoritmos de reconhecimento de padres,
no obteve resultados satisfatrios quanto aos tempos de execuo optou-se por inserir essa
soluo como uma caracterstica importante para arquiteturas de IoT.
A arquitetura desenvolvida integra servios de deteco de outliers e estimao de valores
na camada fsica e no impe a implementao dos algoritmos. Os servios de deteco de
outliers, estimao de valores e clustering esto presentes na camada de middleware. Essa
arquitetura foi integrada plataforma de Big Data Hadoop e as implementaes algortimcas
usam o framework Mahout.
107
Outro aspecto relevante da arquitetura que sua estrutura orientada a objetos permite
a fcil integrao de outras implementaes algortimcas ou de plataformas de Big Data,
desde que sejam satisfeitos e implementados os contratos das interfaces criadas.
Observa-se que os servios desenvolvidos possuem um desacoplamento e independncia
com o LinkSmart Middleware, sendo assim, podero ser utilizados em conjunto com outros
middlewares de IoT.
Cabe ressaltar a importncia da comunicao cross-layer aqui proposta, que permite a
ativao de desativao dos servios nas camadas fsica e de middleware, pela classe ou
software com a funo de coordenao para a parametrizao dos algoritmos e controle dos
servios. A comunicao cross-layer uma caracterstica importante para arquitetura de IoT.
5.2 DIVULGAO DA PESQUISA
As contribuies deste trabalho foram publicadas em veculos internacionais e so:
1. O uso do LinkSmart Middleware como plataforma para IoT foi apresentado na confe-
rncia SmartSystech, em Julho de 2013, disponvel na IEEE Xplore digital library, com
o artigo A Novel Smart Home Application Using an Internet of Things Middleware
(SOUZA; AMAZONAS, 2013), no qual, foi proposta uma aplicao de casa inteligente
utilizando o LinkSmart Middleware como plataforma de IoT.
2. A principal contribuio desta pesquisa foi publicada no Journal of Machine to Machine

Communications - River Publishers, em Maio de 2015, no artigo Novel IoT Architec-
ture with Pattern Recognition Mechanism and Big Data (SOUZA; AMAZONAS,
2015), no qual se destaca a utilizao do modelo de referncia IoT-A, do LinkSmart
Middleware, introduzida por completa a nova plataforma de IoT, com os servios de
reconhecimento de padres nas camadas fsica e de middleware, integrada plataforma
de Big Data, bem como sua estrutura orientada a objetos que permite futuras imple-
mentaes e, por fim, a experimentao da arquitetura e do servio de clustering.
3. A implementao do algoritmo de deteco de outlier descrita nesta tese uma con-

tribuio original apresentada na conferncia 6th International Conference on Ambi-
ent Systems, Networks and Technologies (ANT-2015), presente no Procedia Computer
Science, volume 52, com o artigo An Outlier Detect Algorithm using Big Data Pro-
cessing and Internet of Things Architecture (SOUZA; AMAZONAS, 2015), que
descreve a abordagem e implementao do algoritmo usando a tecnologia de Big Data
e algoritmo de clustering em sua implementao e, por fim, sua experimentao in-
tegrada arquitetura de IoT.
108
4. A comunicao cross layer proposta e implementada nesta pesquisa foi publicada na
conferncia EMERGING 2015, The Seventh International Conference on Emerging
Networks and Systems Intelligence, em Julho de 2015, presente na Think Mind digi-
tal library, com o artigo A New Internet of Things Architecture with Cross-Layer
Communication, que descreve a comunicao cross layer integrada nova arquitetura
de IoT, ao LinkSmart Middleware e a tecnologia de Big Data, bem como a comprovao
experimental desta arquitetura e comunicao (SOUZA; AMAZONAS, 2015).
A Tabela 5 resume todas as contribuies originais da pesquisa publicadas em eventos ou

revistas internacionais.
Tabela 5 - Tabela com o resumo das publicaes.
No. Ttulo Publicao Ano Formato
A Novel Smart Home SmartSystech
1 Application Using an Conference 2013 Proceedings
Internet of Things Middleware IEEE Xplore
Novel IoT Architecture Journal of Machine to
2 with Pattern Recognition Machine Communications 2015 Journal
Mechanism and Big Data River Publishers
An Outlier Detect
ANT Conference 2015
Algorithm using
3 Procedia on Computer 2015 Proceedings
Big Data Processing and
Science
Internet of Things Architecture
A New Internet of Things
IARIA Conference
4 Architecture with 2015 Proceedings
Think Mind digital library
Cross-Layer Communication
5.3 TRABALHOS FUTUROS
Como trabalhos futuros sugere-se o desenvolvimento e experimentao da plataforma aqui

proposta com aplicaes do mundo real com dados em tempo real. Cabe destacar o uso da
plataforma aqui descrita em um contexto real com redes de telecomunicaes reais e com
uma escala de clientes e aplicaes de modo a verificar o comportamento da plataforma e do
LinkSmart Middleware com um grande nmero de instncias integradas com clusters para
processamento distribudo em Big Data.
Atestar a aplicabilidade das implementaes algortimcas em diversos contextos de IoT, de
modo a elucidar se os algoritmos aqui utilizados conseguem modelar as inmeras aplicaes
existentes nos diversos outros contextos.
109
Propor outros servios com reconhecimento de padres e inteligncia artificial no Link-
Smart Middleware ou em outros frameworks para IoT.
Atestar a aplicabilidade de tcnicas de extrao de caractersticas, ou do ingls feature
extraction, para a criao de sensores virtuais integrada arquitetura de IoT aqui proposta,
de modo a reduzir o nmero de dimenses a que se pretende analisar com um maior ganho
de informao.
Sugere-se explorar a modularidade da plataforma de IoT aqui descrita, de modo a experi-
mentar outras plataformas para Big Data, explorar a funcionalidade de notaes semnticas
existentes no LinkSmart Middleware e propor o uso do servio de clustering para a mode-
lagem automtica dessas notaes semnticas.
Analisar a aplicabilidade dos servios de reconhecimento de padres segurana no con-
texto de IoT e integrar ao mdulo de segurana do LinkSmart middleware, seja no contexto
de segurana da informao e servios ou segurana patrimonial e pessoal ou no mbito de
cidades inteligentes, de modo que as aplicaes possam conhecer os contextos e comporta-
mentos pessoais e infiram ataques ou mudanas bruscas de comportamento individual ou em
massa.
Sugere-se acoplar os servios desenvolvidos nessa arquitetura a outros middlewares de
IoT e plataformas de computao em nuvem.
Alm dos trabalhos propostos, segure-se o desenvolvimento de um conjunto de aplicaes
com base nos dados obtidos do projeto Smart Santander, se prope ou se estendem as
seguintes aplicaes futuras a curto e mdio prazo:
Aplicaes para dispositivos mveis e pervasivas, com interao atravs de udio, mo-
nitores de vdeo e tablets embutidos nos diversos ambientes, que ilustrem e contextu-
alizem a temperatura dos ambientes especficos e em comparao com medies ante-
riores.
Aplicaes para dispositivos mveis ou pervasivas para a predio de temperatura nos

diversos ambientes, mesmo que no possuam sensores.
Aplicaes para dispositivos mveis ou pervasivas que ilustrem o trfego da determi-

nada regio na qual o usurio se encontra e que possa predizer o trfego para determi-
nados horrios, com base em contextualizao e em medies histricas e comporta-
mentais.
Aplicaes que possam predizer a temperatura com base nos dados de trfego da cidade.
No futuro, ao se agregar dados como luminosidade, nvel de CO2 , contextos dos ambientes
e lugares pblicos, informaes sobre as rotas e destinos dos veculos, a insero de atuado-
110
res em janelas, cortinas, sistemas de aquecimento e de ar condicionado em locais pblicos
fechados, podero ser propostas aplicaes como:
Aplicaes para dispositivos mveis ou pervasivas que contextualizem o usurio sobre

o seu comportamento e impacto no ambiente, que essas aplicaes possam atuar nos
ambientes pblicos, atravs do controle e atuao nos sistemas de ar condicionado,
luzes e abertura e fechamento de cortinas ou janelas, irrigao, buscando aumentar a
eficincia energtica no dado ambiente.
Aplicaes para dispositivos mveis ou pervasivas que possam atuar de maneira social
no trfego e locomoo na cidade, tendo em vista as possveis rotas e destinos dos
veculos privados e pblicos e da populao como um todo. Essas aplicaes podero
atuar nos sistemas de controle de vagas nos estacionamentos e vagas pblicas, atuar nas
aplicaes de GPS, de modo a minimizar impactos nas rotas e trfego na cidade.
Aplicaes pervasivas ou mveis que possam predizer as caractersticas do trfego na

cidade antecipadamente usando os dados de destinos dos usurios.
Aplicaes mveis e pervasivas para segurana privada, de modo que a aplicao co-
nhea o comportamento e rotas e destinos com veculos pblicos ou privados do usurio
e detecte, caso ocorram, alteraes inesperadas de comportamento.
Aplicaes pervasivas nas ruas e avenidas que possam detectar o comportamento de

deslocamento da populao em eventos urbanos, seja com veculos privados ou pbli-
cos e possam alterar as sinalizaes, sentidos das vias, semforos, dentre outros atua-
dores, dado o comportamento histrico ou inesperado nas ruas e avenidas. Que essas
aplicaes possam interagir em tempo real com as aplicaes de GPS e de deslocamento
utilizadas pela populao.
Aplicaes que possam alterar ou criar novos destinos e rotas para o transporte pblico,
dado o comportamento histrico ou imediato da cidade. Que essas aplicaes possam
interagir em tempo real com as aplicaes mveis de deslocamento utilizadas pela po-
pulao.
Aplicaes mveis e pervasivas para a sugesto de atraes, eventos, lugares, cultura,

etc. para o usurio, de modo que a aplicao reconhea o comportamento e padro do
usurio e mais se adapte ao seu gosto.
111
Referncias
AFFILIATES, O. C. and/or its. Mysql: the worlds most popular open source database. June
2014. Online http://www.mysql.com/; accessado em 03-Julho-2014.
AGGARWAL, C.; ASHISH, N.; SHETH, A. The internet of things: a survey from the
data-centric perspective. In: Managing and Mining Sensor Data. Managing and Mining
Sensor Data. [S.l.]: Springer US, 2013. p. 383428.
AL-QUTAYRI, M. A. Smart Home Systems. 1. ed. [S.l.]: In-Teh, 2010.
ALBANO, M. et al. Towards secure middleware for embedded peer-to-peer systems: ob-
jectives and requirements. 2007. DOI: 10.1.1.90.5982. In RSPSI 07: Workshop on Require-
ments and Solutions for Pervasive Software Infrastructures, 2007, pp. 16.
AMAZONAS, J. R. d. A. Network virtualization and cloud computing: iot en-

abling thecnologies. Casagras2 Academic Seminar, September 2011. Online
http://www.casagras2.com.br/downloads/day2/2-Jose_Roberto_de_Almeida_Amazonas-
Network_Virtualization_and_Cloud_Computing_IoT_enabling_echnologies.pdf; acces-
sado em 28-Abril-2013.
BAHGA, A.; MADISETTI, V. Internet of Things: A Hands-On Approach. [S.l.]: Vijay

Madisetti, 2014.
BAKKER, P.; ERTMAN, B. Building Modular Cloud Apps with OSGi. [S.l.]: O Reilly
Media, 2013.
BANDYOPADHYAY, S. et al. Role of middleware for internet of things: a study. Interna-

tional Journal of Computer Science Engineering Survey, p. 94 105, 2011.
BANDYOPADHYAY, S. et al. A survey of middleware for internet of things. In: Recent

Trends in Wireless and Mobile Networks. Recent Trends in Wireless and Mobile Net-
works. [S.l.]: Springer Berlin Heidelberg, 2011. (Communications in Computer and Infor-
mation Science, v. 162), p. 288296.
BIN, S.; YUAN, L.; XIAOYI, W. Research on data mining models for the internet of things.
2010 International Conference on Image Analysis and Signal Processing, Ieee, p. 127
132, 2010.
BOHN, H.; BOBEK, A.; GOLATOWSKI, F. Sirena - service infrastructure for real-
time embedded networked devices: a service oriented framework for different domains.
Networking, International Conference on Systems and International Conference
on Mobile Communications and Learning Technologies, 2006. ICN/ICONS/MCL
2006. International Conference on. p. 4343, April 2006. DOI: 10.1109/ICNICON-
SMCL.2006.196.
112
BOTTS, M. et al. Ogc sensor web enablement: overview and high level architecture. Open
Geospatial Consortium, Inc. Withepaper, OGC 07-165, 2007.
CANNATA, A.; GEROSA, M.; TAISCH, M. Socrades: a framework for developing intel-
ligent systems in manufacturing. Industrial Engineering and Engineering Management,
2008. IEEM 2008. IEEE International Conference on. p. 19041908, Dec 2008. DOI:
10.1109/IEEM.2008.4738203.
CAPORUSCIO, M.; RAVERDY, P.-G.; ISSARNY, V. Ubisoap: a service-oriented middle-

ware for ubiquitous networking. Services Computing, IEEE Transactions on, v. 5, n. 1,
p. 8698, Jan 2012. DOI: 10.1109/TSC.2010.60.
CASAGRAS, E. F. P. Casagras final report: rfid and the inclusive model for the internet of
things. 2009.
CHAI, T.; DRAXLER, R. R. Root mean square error (rmse) or mean absolute error (mae)?
arguments against avoiding rmse in the literature. Geoscientific Model Development, v. 7,
n. 3, p. 12471250, 2014. DOI: 10.5194/gmd-7-1247-2014.
CHARTIER, P. Regulations and standards. Casagras2 Academic Seminar, Casagras2,

September 2011. Online http://www.casagras2.com.br/downloads/day2/3-Paul_Chartier-
Regulations_and_Standards.pdf; accessado em 28-Abril-2013.
CLARK, D. e. a. Making the world (of communications) as different place. End-to-End

Research Group, IRTF, ACM SIGCOMM Computer Communication Review, p. 91
96, 2005.
COMER, D. E. Computer Networks and Internets. [S.l.]: Pearson, 6th Edition, 2015.
COOPER, J. Challenges for database management in the internet of things. IETE Technical
Review., v. 26:320-9, 2009.
DOUGHERTY, G. Pattern Recognition and Classification: An Introduction. 2013. ed.

[S.l.]: Springer, 2012.
DUBOIS, P. MySQL Cookbook: Solutions for Database Developers and Administra-

tors. [S.l.]: OReilly Media, August 2014.
ETZION, O.; NIBLETT, P. Event Processing in Action. 1st. ed. Greenwich, CT, USA:
Manning Publications Co., 2010.
FACILITY, S. Smart santander - future internet research and experimentation. 2013. Online
http://www.smartsantander.eu/index.php/testbeds/item/132-santander-summary; accessado
em 17-Julho-2014.
113
FAN, T.; CHEN, Y. A scheme of data management in the internet of things. Proceedings of
IC-NIDC2010, 2010.
FLP, L. J. et al. Predictive complex event processing: a conceptual framework for com-
bining complex event processing and predictive analytics. Proceedings of the Fifth Balkan
Conference in Informatics. p. 2631, 2012. DOI: 10.1145/2371316.2371323.
GAMMA, E. et al. Padres de Projetos: Solues Reutilizveis. [S.l.]: BOOKMAN

COMPANHIA ED, 2006.
GIACOMELLI, P. Apache Mahout Cookbook. [S.l.]: Packt Publishing, 2013.
GLUHAK, A. et al. Towards an arquitecture for a real world internet. Towards the Future
Internet, p. 313324, 2009.
GRANELLI, F. et al. Middleware building blocks for architecting rfid systems, in mo-
bile lightweight wireless systems, ser. lecture notes of the institute for computer sciences,
social informatics and telecommunications engineering. Eds. Springer Berlin Heidel-
berg, 2009, vol. 13, pp. 325336, 2009. DOI: http://dx.doi.org/10.1007/978-3-642-03819-8
31. Online http://ec.europa.eu/information-society/activities/foi/events/fippp/docs/mikhail-
simonov.pdf; accessado em 11-Agosto-2013.
GREENGARD, S. The Internet of Things (The MIT Press Essential Knowledge series).
[S.l.]: The MIT Press (March 20, 2015), 2015.
HAN, J.; KAMBER, M.; PEI, J. Data mining: concepts and techniques, third edition (the
morgan kaufmann series in data management systems). Morgan Kaufmann, July 2011.
HUANG, Y.; LI, G. Descriptive models for internet of things. International Conference
on Intelligent Control and Information Processing, August 2010.
HURLBURT, G.; VOAS, J.; MILLER, K. The internet of things: a reality check. IT Pro-
fessional, v. 14, n. 3, p. 5659, 2012. DOI: 10.1109/MITP.2012.60.
INC., G. Google maps javascript api v3. 2014. Online

https://developers.google.com/maps/documentation/javascript/reference?hl=pt-br; ac-
cessado em 09-Maro-2015.
ITU. ITU: internet reports 2005: the Internet of Things. 2005. Online
http://www.itu.int/internetofthings; accessado em 28-Outubro-2014.
ITU. ITU: Internet of Things 2009: executive summary. 2009. Online

http://www.itu.int/osg/spu/publications/internt of things; accessado em 28-Outubro-2014.
114
ITU-T. Overview of the internet of things. SERIES Y: Global Information Infrastruc-
ture, Internet Protocol Aspects and Next Generation Networks - Frameworks and
functional architecture models, ITU-T REc.Y.2060, 2012.
JAMES, A.; COOPER, J. Challenges for database management in the internet of things.
v. 26, n. 5, p. 320329, 2009. DOI: 10.4103/0256-4602.55275.
JAMES, A. et al. Research directions in database architectures for internet of things: a

communication of the first international workshop on database architectures for the internet
of things (dait 2009). p. 225233, 2009.
JARA, A. J.; GENOUD, D.; BOCCHI, Y. Big data for smart cities with knime a real experi-
ence in the smartsantander testbed. Software: Practice and Experience, p. n/an/a, 2014.
DOI: 10.1002/spe.2274.
JAYASINGHE, D.; AZEEZ, A. Apache Axis2 Web Services. [S.l.]: Packt Publishing; 2
edition, 2011.
JEFFERY, K. The Internet of Things: The Death of a Traditional Database? IETE Techni-
cal Review, v. 26, n. 5, p. 313319, 2009. DOI: 10.4103/0256-4602.55272.
JOACHIM, W.; WALEWSKI, S. Internet of things architecture iot-a. Deliverable D1.4 -

Converged architectural reference model for the IoT v2.0, 2012.
KATASONOV, A. et al. Smart semantic middleware for the internet of things.

2008. "in ICINCO-ICSO08, 2008, pp. 169178; Online: Disponvel em:
http://www.mit.jyu.fi/ai/papers/ICINCO-2008.pdf; accessado em 11-Agosto-2013".
KITSUREGAWA, M. Socio sense and cyber infrastructure for information explosion

era: projects in japan. Lecture Notes in Computer Science, v. 4443, 2008.
KJAER, K. E. A survey of context-aware middleware. Hydra Project, 2005.
KRCO, S. et al. Smartsantandera smart city experimental platform. 2012.
KRNIC, J.; KRCO, S. Impact of wsn applicatoins generated traffic on wcdma access net-
works. Proc. of the IEEE PIMRC08, Cannes, France, 2008.
LANG, J. P. Linksmart 2.2 documentation. 2015. Online

https://www.linksmart.eu/redmine/projects/linksmart-opensource/wiki; accessado em
11-Maio-2015.
LARSON, R.; FARBER, B. Estatstica aplicada. 4. ed. So Paulo: Pearson Prentice Hall,
2010.
115
LEI, D. et al. Automatic k-means clustering algorithm for outlier detection. In: Informa-
tion Engineering and Applications. Information Engineering and Applications. [S.l.]:
Springer London, 2012. (Lecture Notes in Electrical Engineering, v. 154), p. 363372.
LEI, D. et al. Automatic k-means clustering algorithm for outlier detection. In: Informa-
tion Engineering and Applications. Information Engineering and Applications. [S.l.]:
Springer London, 2012. (Lecture Notes in Electrical Engineering, v. 154), p. 363372.
LYYTINEN, K.; YOO, Y. Issues and challenges in ubiquitous computing. COMMUNI-

CATIONSOF THE ACM, Vol. 45, No. 12. p.63-65., 2002.
MACQUEEN, J. Some methods for classification and analysis of multivariate observations.

In 5-th Berkeley Symposium on Mathematical Statistics and Probability. p. 281297,
1967.
MATTERN, F.; ZURICH, E. Ubiquitous computing: scenarios for an informatized world,

communication and the media economy of the future. Springer-Verlag, pp. 145-163, 2005.
MAYER-SCHONB, V.; CUKIER, K. Big Data: A Revolution That Will Transform How
We Live, Work, and Think. 2014. ed. [S.l.]: Eamon Dolan/Mariner Books, March 2014.
MCCALLUM, A.; NIGAM, K.; UNGAR, L. H. Efficient clustering of high-dimensional

data sets with application to reference matching. Proceedings of the Sixth ACM SIGKDD
International Conference on Knowledge Discovery and Data Mining. p. 169178, 2000.
DOI: 10.1145/347090.347123.
MIT. The auto-id savant specification 1.0. 2011. Online http://www.epcglobalinc.org; ac-
cessado em 28-Outubro-2014.
NATHAN, N.; WARREN, J. Big Data: Principles and best practices of scalable realtime
data systems. 1. ed. [S.l.]: Manning Publications, May 2015.
NATI, M. et al. Smartcampus: a user-centric testbed for internet of things experimenta-

tion. Wireless Personal Multimedia Communications (WPMC), 2013 16th Interna-
tional Symposium on. p. 16, June 2013.
NAVIDI, W. Statistics for Engineers and Scientists. 4. ed. [S.l.]: McGraw-Hill Education,
January 2014.
NAYAK, S. et al. An integrated clustering framework using optimized k-means with firefly
and canopies. Computational Intelligence in Data Mining - Volume 2. p. 333343, 2015.
DOI: 10.1007.
116
PAMULA, R.; DEKA, J.; NANDI, S. An outlier detection method based on clustering.
Emerging Applications of Information Technology (EAIT), 2011 Second International
Conference on. p. 253256, Feb 2011. DOI: 10.1109/EAIT.2011.25.
PEREIRA, J.; EISENHAUER, M. Hydra - networked embedded system middleware for

heterogeneous physical devices in a distributed architecture final report. 2011.
PULIAFITO, A. et al. Making the internet of things a reality: the wherex solution. The
Internet of Things. p. 99108, 2010.
ROUSSOS, G. Sensor and actuators netoworks: from smart dust to the hu-
man internet. Casagras2 Academic Seminar, Casagras2, September 2011. On-
line http://www.casagras2.com.br/downloads/day1/5-George_Roussos-Sensor_and_Actua-
tor_Networks_within_IoT.pdf; accessado em 28-Abril-2013.
SALEHI, A. Design and implementation of an efficient data stream processing system.

2010. PhD. dissertation, Ecole Polytechnique Federale de Lausanne (EPFL); Online:
http://biblion.epfl.ch/EPFL/theses/2010/4611/EPFL TH4611.pdf, Acessado em 25-Agosto-
2013.
SALTZER, J.; REED, D.; CLARK, D. End-to-end arguments in system design. 2nd Inter-
national Conference on Dist Systems, Paris France, 1981.
SANTANDER, S. Smart santander - future internet research and experimentation. 2014.

Online http://www.smartsantander.eu; accessado em 17-Julho-2014.
SARNOVSKY, M. et al. First demonstrator of hydra middleware architecture for building

automation. Hydra Project, June 2008.
SATYANARAYANAN, M. Pervasive computing: vision and challenges. IEEE Personal

Communications, 2001.
SIMONOV, M. Ismb middleware for iot (rfid). 2010. Online

http://ec.europa.eu/information-society/activities/foi/events/fippp/docs/mikhail-
simonov.pdf; accessado em 11-Agosto-2013.
SKARMETA, A. IEEE AINA 2013 keynote talk II: the impact of internet of things in
big data approach and future internet. Advanced Information Networking and Applica-
tions (AINA), 2013 IEEE 27th International Conference on. p. xlviixlvii, 2013. DOI:
10.1109/AINA.2013.160.
SMITH, I. The Internet of Things 2012: New Horizons. [S.l.]: CASAGRAS2, 2012.
117
SOUZA, A. M.; AMAZONAS, J. R. A novel smart home application using an internet
of things middleware. Smart Objects, Systems and Technologies (SmartSysTech), Pro-
ceedings of 2013 European Conference on. p. 17, 2013.
SOUZA, A. M.; AMAZONAS, J. R. A new internet of things architecture with cross-layer

communication. p. 1 6, 2015. EMERGING 2015, The Seventh International Conference
on Emerging Networks and Systems Intelligence, IARIA Conference.
SOUZA, A. M.; AMAZONAS, J. R. A novel iot architecture with pattern recognition mech-
anism and big data. Journal of Machine to Machine Communications, v. 1, n. 4, p. 245
272, 2015. DOI: http://doi: 10.13052/jmmc2246-137X.134. River Publishers.
SOUZA, A. M.; AMAZONAS, J. R. An outlier detect algorithm using big data process-
ing and internet of things architecture. Procedia Computer Science, v. 52, n. 0, p. 1010
1015, 2015. DOI: http://dx.doi.org/10.1016/j.procs.2015.05.095. The 6th International Con-
ference on Ambient Systems, Networks and Technologies (ANT-2015), the 5th International
Conference on Sustainable Energy Information Technology (SEIT-2015).
TERZIYAN, V.; KAYKOVA, O.; ZHOVTOBRYUKH, D. Ubiroad: semantic middleware

for context-aware smart road environments. 2010. In Internet and Web Applications and
Services (ICIW), 2010 Fifth International Conference on, may 2010, pp. 295-302.
THEODORIDIS, S.; KOUTROUMBAS, K. Pattern Recognition, Fourth Edition. 4th. ed.

[S.l.]: Academic Press, 2008.
TRIOLA, M. F. Essentials of Statistics. 5. ed. [S.l.]: Pearson, January 2014.
UBIDOTS, C. About ubidots. 2014. Online http://ubidots.com/about-ubidots.html; acces-

sado em 08-Abril-2015.
UBIDOTS, C. Ubidots overview. 2014. Online http://ubidots.com/docs/get-

started/overview.html; accessado em 08-Abril-2015.
WANG, Y.; CAO, K.; ZHANG, X. Complex event processing over distributed prob-
abilistic event streams. Computers and Mathematics with Applications, 2013. DOI:
http://dx.doi.org/10.1016/j.camwa.2013.06.032.
WEISER, M. The computer for the 21st century. SIGMOBILE Mob. Comput. Com-
mun. Rev., New York, NY, USA, ACM, v. 3, n. 3, p. 311, jul 1999. 9 p. DOI:
10.1145/329124.329126.
WHITE, T. Hadoop: The Definitive Guide. 4. ed. [S.l.]: OReilly Media, Inc., 2015.
ZAKI, M. J.; MEIRA, W. J. Data Mining and Analysis: Fundamental Concepts and
Algorithms. 1. ed. [S.l.]: Cambridge University Press, 2014.
118
ZUMEL, N.; MOUNT, J.; PORZAK, J. Practical Data Science with R. 1. ed. [S.l.]: Man-
ning, April 2014.

Alberto Messias Costa Souza

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Alberto Messias Costa Souza

Diunggah oleh

Hak Cipta:

Format Tersedia

ALBERTO MESSIAS DA COSTA SOUZA

UMA NOVA ARQUITETURA PARA INTERNET DAS COISAS COM

UMA NOVA ARQUITETURA PARA INTERNET DAS COISAS COM

UMA NOVA ARQUITETURA PARA INTERNET DAS COISAS COM

Tese apresentada Escola

Tese (Doutorado) - Escola Politcnica da Universidade de So

1. Internet das Coisas 2. Redes de Comunicao 3.

Palavras-chave: Internet das Coisas. Redes de Comunicao. Reconhecimento de Padres.

Keywords: Internet of Things. Communications Network. Pattern Recognition. Refe-

Figura 1 Mapa conceitual que destaca os conceitos pertinentes pesquisa. . 20

Figura 2 Interao entre as redes de comunicao, o mundo fsico e o virtual. 26

Figura 17 Aplicao de teste com a plataforma Ubidots. . . . . . . . . . . . . 61

Figura 28 Aplicao disponvel com realidade aumentada e as informaes na

Tabela 1 Tabela com exemplos de valores de temperatura de entrada e metros

Tabela 2 Tabela comparativa entre o LinkSmart Middleware e a plataforma

Tabela 3 Tabela com a descrio dos dados de temperatura obtidos no projeto

Tabela 5 Tabela com o resumo das publicaes. . . . . . . . . . . . . . . . . 108

2 INTERNET DAS COISAS, RECONHECIMENTO DE PADRES

3 NOVA ARQUITETURA PARA INTERNET DAS COISAS COM

4 VALIDAO E EXPERIMENTOS COM A NOVA ARQUITE-

5 CONCLUSES E TRABALHOS FUTUROS . . . . . . . . . . . . . . 106

1.1 CONCEITOS INTRODUTRIOS

Fonte: Elaborada pelo autor.

Camada de Dispositivos (entidades fsicas): que implementa a coleta de dados, atuao

Camada de Middleware: que desempenha funes como gerenciamento, segurana e

Camada de Servios: desempenha funes de gerenciamento de servios, segurana e

Camada de Aplicao: representada por aplicaes pervasivas como, por exemplo,

1.4 ESCOPO E OBJETIVOS DE PESQUISA

Esta seo tem por objetivo elencar o escopo e objetivos de pesquisa.

1.4.1 Escopo de pesquisa

No escopo da pesquisa, esto tpicos relacionados ao modelo de referncia em IoT e

O principal objetivo de pesquisa : introduzir mecanismos de anlise e reconhecimento

2. Propor uma arquitetura para minerao e processamento distribudo de dados para a

3. Propor e implementar a comunicao cross-layer, acrescentando ao modelo de arquite-

Na Figura 1 as linhas tracejadas ilustram as novas relaes entre os conceitos elencados

1. Especificao detalhada, modelagem e desenvolvimento do tema e soluo proposta.

2. Identificao e adequao do ambiente de testes e experimentaes.

3. Experimentao e anlise dos resultados.

1.6 ORGANIZAO DO TRABALHO

Este trabalho organizado da seguinte maneira:

2.1 INTERNET DAS COISAS

Fonte: Adaptado de (CASAGRAS, 2009).

A Figura 3 ilustra o Modelo Inclusivo para a IoT, adaptado de (AMAZONAS, 2011) 1 .

1. Objetos puramente passivos com identificao e dados fixos, so objetos presentes na

2. Objetos dotados de moderado poder computacional e percepo de contexto, que por

3. Objetos que possuem conectividade em rede, sem a interveno humana, possibilitando

Interrogator/ Host information

Interrogator/ Host information

Interrogator/ Host information

Networked data carriers Further layers of data capture technology

Fonte: Adaptado de (AMAZONAS, 2011).

2.2 MODELOS DE REFERNCIA PARA IOT

Um modelo de referncia uma estrutura para entendimento de relacionamentos entre en-

2.2.1 Modelo de referncia ITU-T

Fonte: (ITU-T, 2012).

Segue a descrio detalhada de cada uma das 4 camadas:

Application Layer: contm as aplicaes para IoT.

Specific Support Capabilities: essas funcionalidades so especficas de cada tipo

Network Layer: suas funes no so anlogas s da camada de rede e transporte

Networking Capabilities: prov controles de funes de conectividade, como

Transport Capabilities: prov conectividade para o transporte de servios de IoT,

Device Capabilities: as funcionalidades de dispositivos incluem, mas no esto

1. Interao direta com comunicao de rede: dispositivos que renem e

Gateway Capabilities: as funcionalidades de gateway incluem, mas no se limi-