UNIVERSIDADE PRESBITERIANA MACKENZIE PROGRAMA DE...
105
UNIVERSIDADE PRESBITERIANA MACKENZIE PROGRAMA DE P ´ OS-GRADUAC ¸ ˜ AO EM ENGENHARIA EL ´ ETRICA E COMPUTAC ¸ ˜ AO Marco Aur´ elio Borges UMA ARQUITETURA PARA INTERNET DAS COISAS PARA AN ´ ALISE DA CONCENTRAC ¸ ˜ AO DE MON ´ OXIDO DE CARBONO NA GRANDE S ˜ AO PAULO POR MEIO DE T ´ ECNICAS DE BIG DATA S˜ ao Paulo 2017
Transcript of UNIVERSIDADE PRESBITERIANA MACKENZIE PROGRAMA DE...
UNIVERSIDADE PRESBITERIANA MACKENZIEPROGRAMA DE POS-GRADUACAO EM
ENGENHARIA ELETRICA E COMPUTACAO
Marco Aurelio Borges
UMA ARQUITETURA PARA INTERNET DAS COISAS
PARA ANALISE DA CONCENTRACAO DE MONOXIDO
DE CARBONO NA GRANDE SAO PAULO POR MEIO DE
TECNICAS DE BIG DATA
Sao Paulo2017
UNIVERSIDADE PRESBITERIANA MACKENZIEPROGRAMA DE POS-GRADUACAO EM
ENGENHARIA ELETRICA E COMPUTACAO
Marco Aurelio Borges
UMA ARQUITETURA PARA INTERNET DAS COISAS
PARA ANALISE DA CONCENTRACAO DE MONOXIDO
DE CARBONO NA GRANDE SAO PAULO POR MEIO DE
TECNICAS DE BIG DATA
Dissertacao apresentada ao Programa dePos-Graduacao em Engenharia Eletrica e Com-putacao da Universidade Presbiteriana Macken-zie como requisito parcial a obtencao de tıtulode Mestre em Engenharia Eletrica e Computacao.
Orientador: Prof. Dr. Paulo Batista LopesCoorientador: Prof. Dr. Leandro Augusto da Silva
Sao Paulo2017
A B726 Borges, Marco Aurélio
Uma arquitetura para internet das coisas para análise da concentração de monóxido de carbono na grande São Paulo por meio de técnicas de Big Data / Marco Aurélio Borges – São Paulo, 2017.
80 f.: il., 30 cm Bibliografia: f. 73-79 Dissertação (Mestrado em Engenharia Elétrica e Computação) –
Universidade Presbiteriana Mackenzie, São Paulo, 2017. Prof. Dr. Paulo Batista Lopes
1. Internet das Coisas 2. Big Data 3.Sensor Data Mining 4.
Arquitetura Hadoop 5. ESP2866. Título
CDD 004.678
a Deus por ter me dado forca em to-dos os momentos.pelo apoio, incentivo incondicionaisda minha mae, meus irmaos e a mi-nha famılia.
i
AGRADECIMENTOS
Ao Instituto Presbiteriano Mackenzie pelo financiamento parcial deste projeto com
bolsa de estudo do MackPesquisa e Capes (Coordenacao de Aperfeicoamento de Pessoal
de Nıvel Superior)
Aos colegas pesquisadores dos laboratorios BigMAAp e JAS3 da Faculdade de Com-
putacao e Informatica e Escola de Engenharia Eletrica da Universidade Presbiteriana
Mackenzie.
Ao Programa de Pos-Graduacao em Engenharia Eletrica e Computacao (PPGEEC)
da Universidade Presbiteriana Mackenzie, por todo o suporte para a realizacao desta
pesquisa.
Ao meu orientador Prof. Dr. Paulo Batista Lopes e ao coorientador Prof. Dr. Leandro
Augusto da Silva, por todo o apoio, auxılio, paciencia e conhecimento compartilhados
comigo.
ii
RESUMO
A utilizacao de sensores para o monitoramento de um determinado ambiente aliada ao
uso da internet como meio de comunicacao e popularmente chamado de Internet das Coi-
sas (do ingles, Internet of Things (IoT )). A quantidade de informacao que se gera neste
ambiente IoT tem fomentado um aumento no acumulo de dados nunca antes imaginado.
Um dos importantes desafios para o seu desenvolvimento e armazenar e processar esse
grande volume de dados em aceitaveis parametros de medicao e analise. Esta pesquisa
direciona esse desafio, a partir do armazenamento e compilacao de dados oriundos de
diversos sensores ate a analise exploratoria das informacoes obtidas. Na pesquisa foram
analisados sensores de captacao de dados na Regiao Metropolitana de Sao Paulo (RMSP),
com sensores capazes de medir os ındices de monoxido de carbono (CO). A pesquisa ainda
analisa algumas arquiteturas para processamento em lote (batch) e em fluxo (stream) de
sensores e utilizar uma delas na construcao de um ambiente Big Data. Foram utiliza-
das as ferramentas de Big Data para o armazenamento, processamento e visualizacao
desses dados de IoT. Nos experimentos desenvolvidos na pesquisa foram analisados os
sensores de monoxido de carbono (MQ7), conectados atraves de uma unidade micro-
controladora que apresenta suporte ao protocolo Transmission Control Protocol/Internet
Protocol (TCP/IP). Este projeto destaca o instrumento de como compilar e executar
esses dados e a analise dos mesmos obtidos de forma dinamica. Os dados obtidos pelos
sensores IoT constatam como a media dos ındices coletados, estao muito superiores aos
padroes internacionais estabelecidos pela OMS.
Palavras-chave: Internet das Coisas, Big Data, Sensor Data Mining, Arquitetura
Hadoop e ESP2866.
i
ABSTRACT
The use of sensors for the monitoring of a given environment allied to the Internet as
a means of communication is popularly known as Internet of Things (IoT). The amount
of information generated in this environment has led to an unprecedented increase in data
collection. One of the major challenges for its development lies in the storage and the
processing of this huge volume of data into acceptable measurement and analysis parame-
ters. This research takes up this challenge by storing and compiling data from different
sensors, and by carrying out an exploratory analysis of the information gathered. In this
research, sensors that collect data from a specific Sao Paulo’s Metropolitan Area (SMA)
have been analysed. These sensors are capable of measuring carbon monoxide (CO) le-
vels. This research aims to analyse some architectures for both batch and stream sensor
processing and to use one of them for the construction of a Big Data environment. Big
Data tools were used for IoT storage, processing and visualization data. During the expe-
riments, carbon monoxide sensors (MQ7), were analysed. They were connected through a
microcontroller unit that supports the Transmission Control Protocol/Internet Protocol
(TCP/IP). This project highlights the necessary tools to execute and analyse the data
in a dynamic manner. The data collected by the sensors show that the avarage levels
of carbon monoxide are well above the international standards set by the World Health
Organization (WHO).
Keywords: Internet of Things, Big Data, Sensor Data Mining, Hadoop Architecture
and ESP2866.
i
Sumario
1 INTRODUCAO 1
1.1 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Objetivos Especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Organizacao Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 REFERENCIAL TEORICO 7
2.1 Padroes Qualidade do Ar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Internet das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Aplicacao de Sensores IoT . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Sistemas Cognitivos IoT . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Big DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Desenvolvimento Big Data . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.2 Sensor Data Mining . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.3 Data Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.4 Big Data Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.5 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4 ARQUITETURAS PARA BIG DATA e INTERNET DAS COISAS . . . . 35
2.5 Parametros do sistema Big Data para SDM . . . . . . . . . . . . . . . . . 36
2.6 Sistema, arquitetura, framework e modelo de referencia . . . . . . . . . . . 38
2.7 Arquitetura Liquid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.7.1 Estrutura da Arquitetura Liquid . . . . . . . . . . . . . . . . . . . 39
2.7.2 Distribuicao quanto ao Processamento . . . . . . . . . . . . . . . . 40
2.7.3 Limitacoes da Arquitetura . . . . . . . . . . . . . . . . . . . . . . . 41
2.8 Hadoop Distributed File System . . . . . . . . . . . . . . . . . . . . . . . . 42
2.8.1 Caracterısticas Principais . . . . . . . . . . . . . . . . . . . . . . . 43
2.8.2 MapReduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3 METODOLOGIA, PROJETO E IMPLEMENTACAO 50
3.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2 Descricao do Projeto para Implementacao da Arquitetura . . . . . . . . . . 51
3.3 Configuracao dos Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4 Armazenamento e Analise dos Dados . . . . . . . . . . . . . . . . . . . . . 54
3.5 Servidor NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4 RESULTADOS EXPERIMENTAIS 58
4.0.1 Linguagem de Programacao . . . . . . . . . . . . . . . . . . . . . . 58
4.0.2 Visualizacao de Dados . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.1 Resultados HDFS e MapReduce . . . . . . . . . . . . . . . . . . . . . . . . 66
5 CONCLUSOES 71
5.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
REFERENCIAS 79
6 ARTIGO PUBLICADO 80
Lista de Figuras
1 Captura de dados rede IoT. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Diagrama de bloco modulo ESP8266. . . . . . . . . . . . . . . . . . . . . . 14
3 Fluxograma CIoT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4 Perguntas e Repostas IBM Watson and Deep QA . . . . . . . . . . . . . . 18
5 Conceito de Big Data Analytics. . . . . . . . . . . . . . . . . . . . . . . . . 21
6 Processos de Mineracao de Dados. . . . . . . . . . . . . . . . . . . . . . . . 23
7 Big Data Analytics Infraestutura. . . . . . . . . . . . . . . . . . . . . . . . 31
8 Plataformas de Big Data e quanto ao processamento. . . . . . . . . . . . . 33
9 Integracao de dados arquitetura Liquid. . . . . . . . . . . . . . . . . . . . . 40
10 Diagrama esquematico do funcionamento do algorıtimo de MapReduce. . . 45
11 Fluxo atividades contador de palavras. . . . . . . . . . . . . . . . . . . . . 48
12 Arquitetura proposta e implementada neste Trabalho. . . . . . . . . . . . . 51
13 Exemplo da topologia de sensores. . . . . . . . . . . . . . . . . . . . . . . . 52
14 Sketch Programacao Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . 54
15 Layout sensor IoT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
16 Dados json e Url IP servidor . . . . . . . . . . . . . . . . . . . . . . . . . 55
17 Dashboard servidor NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
18 Coleta Dados Sensor 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
19 Coleta Dados Sensor 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
20 Coleta Dados Sensor 2 e 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
21 Visualizacao dos valores medios coletados pelo sensor 2. . . . . . . . . . . . 63
22 Densidade sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
iv
23 Quartil sensor 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
24 Quartil sensor 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
25 Boxplot sensor 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
26 Histograma sensor 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
27 Histograma sensor 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
28 Aplicacoes gerenciadas HDFS. . . . . . . . . . . . . . . . . . . . . . . . . . 68
29 Execucao do HUE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
30 Logs e ID Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Lista de Tabelas
1 Padroes Estaduais de Qualidade do Ar . . . . . . . . . . . . . . . . . . . . 8
2 Criterios para episodios agudos de poluicao do ar . . . . . . . . . . . . . . 9
3 Estrutura do ındice de qualidade do ar . . . . . . . . . . . . . . . . . . . . 10
4 Comparacao padroes de protocolo. . . . . . . . . . . . . . . . . . . . . . . 14
5 Comparacao escalas de atributos. . . . . . . . . . . . . . . . . . . . . . . . 26
6 Principais ferramentas de processamento em lote em Big Data. . . . . . . . 32
7 Principais ferramentas de processamento stream em Big Data. . . . . . . . 34
8 Principais ferramentas de analise interativa em Big Data. . . . . . . . . . . 35
9 Configuracoes do Cluster Yahoo. . . . . . . . . . . . . . . . . . . . . . . . . 44
10 Atividades de um MapReduce. . . . . . . . . . . . . . . . . . . . . . . . . . 49
11 Lista de Componentes Utilizados . . . . . . . . . . . . . . . . . . . . . . . 53
12 Configuracoes do Cluster servidor IoT Server. . . . . . . . . . . . . . . . . 56
vi
Lista de Quadros
1 Entradas e saıdas MapReduce. . . . . . . . . . . . . . . . . . . . . . . . . . 45
2 Codigo simulando MapReduce. . . . . . . . . . . . . . . . . . . . . . . . . . 47
3 Progamacao dados sensores R Studio. . . . . . . . . . . . . . . . . . . . . . 59
4 Script url e Loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5 Biblioteca ui.R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6 HDFS e MapRduce Stream. . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Lista de Abreviaturas e Siglas
AHP Analytic Hierarchy Process
API Application Programming Interface
BDE Big Data Ecosystem
BI Business Intelligence
CDH Cloudera Distribution for Hadoop
CETESB Companhia Ambiental do Estado de Sao Paulo
CIoT Cognitive Internet of Things
CO Monoxido de Carbono
CONSEMA Conselho Estadual do Meio Ambiente
CPUs Central Processing Units
CRS Compressed Representation Structure
DA Data Analytics
DM Data Mining
ETL Extraction Transform and Loading
FP Growth Frequent Pattern Growth
FPGAs Field Programmable Gate Arrays
GPIO General Purpose Input Output
GPUs Graphics Processing Units
HDF Hortonworks Data Flow
HDFS Hadoop Distributed File System
viii
HDP Hortonworks Data Platform
HTTP Hypertext Transfer Protocol
HUE Hadoop User Experience
IaaS Infrastructure as a Service
IoT Internet of Things
IPCS Intelligent Physical Cyber Socia
ITU International Telecommunication Union
json java script object notation
KDD knowledge Discovery in Databases
M2M Machine to Machine
MD Mineracao de Dados
MI Metas Intermediarias
MIT Massachusetts Institute of Technology
MPP Massively Parallel Processing
NLU Natural Language Understanding
NoSQL Not only Structured Query Language
OLAP Online Analytical Processing
OMS Organizacao Mundial da Saude
ORM Object Relational Mapper
PaaS Platform as a Service
PF Padroes Finais
ppm partes por milhao
PQAr Padroes de Qualidade do Ar
QA Question Answering
RAM Random Access Memory
RMSP Regiao Metropolitana de Sao Paulo
SaaS Sensing as a Service
SDM Sensor Data Mining
SMA Sao Paulo’s Metropolitan Area
SQL Structured Query Language
TCP/IP Transmission Control Protocol/Internet Protocol
UDP User Datagram Protocol
USB Universal Serial Bus
VM Virtual Machine
WHO World Health Organization
WiFi Wireless Fidelity
Yarn Yet Another Resource Negotiator
x
1 INTRODUCAO
A poluicao atmosferica e resultante de um somatorio de fatores geograficos e climaticos;
e seus efeitos nocivos sao percebidos pela populacao atraves de doencas respiratorias. A
inalacao do gas monoxido de carbono, de forma cronica, tempo prolongado e em doses
nocivas, podem provocar doencas respiratorias desde inflamacoes (traqueites e bronqui-
tes cronicas) ate enfisema pulmonar e broncopneumonias quımicas ou infecciosas. Sua
acao toxica deve-se, principalmente, a capacidade de oxidar proteınas, lipıdios e outras
substancias quımicas integrantes das celulas, lesando ou matando as mesmas, dependendo
da concentracao e do tempo de exposicao. Assim, os oxidantes fotoquımicos agravam a
acao irritante dos outros poluentes e intensificam as inflamacoes e infeccoes do sistema
respiratorio (PORTAL, 2017).
A forma mais evidente de agravar a poluicao do ar em grandes centros urbanos,
como na regiao metropolitana de Sao Paulo, e a producao de resıduos produzidos pela
combustao do diesel que movimenta a frota de caminhoes e onibus; e que sao lancados
no ar. A fumaca preta que sai dos escapamentos dos veıculos a diesel e formada pela
mistura de poluentes gasosos e particulados nocivos a saude humana como o monoxido
de carbono (PORTAL, 2017).
O Monoxido de Carbono (CO), e um gas inodoro, incolor, insıpido produzido por
queima incompleta de combustıveis que contem atomos de carbono. Essencialmente,
trata-se de uma substancia que prejudica a oxigenacao dos tecidos e, por isso, e classificada
como um asfixiante sistemico.
A Organizacao Mundial da Saude (OMS ) estabelece que uma cidade somente pode
considerar que tem um ar limpo se apresentar uma media de, no maximo, 10 partes por
milhao (ppm), (OMS, 2017). Qualquer valor acima desse ındice representa riscos para a
saude. O ındice de poluicao do ar em Sao Paulo em media e quase duas vezes superiores
ao teto estabelecido pela (OMS). A taxa e de 19 ppm. A frota da capital paulista passa de
7 milhoes de veıculos, o ultimo dado oficial do departamento e o balanco de dezembro de
2016, quando a frota da cidade fechou em 7,98 milhoes de veıculos (DENATRAN, 2017).
O monitoramento da qualidade do ar tem relevada importancia para a definicao de
polıticas de abatimento da poluicao atmosferica. E atraves da rede de monitoramento
1
que se pode constatar a evolucao das concentracoes dos poluentes como o monoxido de
carbono (CO).
A proposito da discussao da obtencao de dados de sensores, que captam alguns poluen-
tes e ındices, esses ajudam no sentido de monitorar e gerar analises que podem contribuir
com a reducao da poluicao.
Nesse contexto que emerge a Internet das Coisas, conceito que consiste na criacao
de uma infraestrutura de sensores interconectados com a finalidade monitorar, analisar e
atuar virtualmente sobre o mundo real. A definicao de Internet das Coisas, ou simples-
mente IoT (do ingles, Internet of Things), foi proposta inicialmente pelo Auto-ID center
do Massachusetts Institute of Technology (MIT ) (MATTERN F.; ZURICH, 2005) e no
relatorio de pesquisa escrito pelo International Telecommunication Union (ITU ) (ITU,
2005; ITU, 2009).
No ambiente de IoT existem diversos desafios ainda a serem superados como a necessi-
dade de interoperabilidade dos dados, o volume de informacao diversificada transmitida e
recebida, seguranca e privacidade no acesso as informacoes contextualizadas e aos servicos
de atuacao no ambiente (GAO; LEI; YU, 2015). No aspecto de armazenamento, a solucao
mais apropriada e com uso de tecnologias de Big Data que alem de auxiliar no armaze-
namento, ainda oferece recursos para processamento e visualizacao dos dados.
Alguns dispositivos como sensores, cameras e microfones, eletrodomesticos conectados
ou dispositivos de realidade aumentada, que podem ser categorizados pelo termo Internet
das Coisas (IoT), geram dados nao trataveis por sistemas desenvolvidos para processar
dados estruturados. Dados com caracterısticas como estas, grandes (volume), rapidos
(velocidade) e difıceis de serem tratados pelos sistemas atuais (variedade) definem o termo
Big Data (MADDEN, 2012).
Com o amadurecimento dessa tecnologia no sentido do aprimoramento dos sensores,
a coleta de dados e consecutivo armazenamento dos mesmos com capacidade analıtica
provocou um interesse muito grande dessa tecnologia em diversas areas do conhecimento.
O interesse mais significativo e impactante vem sendo chamado de cidades inteligentes
(do ingles, Smart Cities) cuja finalidade e a obtencao de um ambiente que proporcione
a populacao conforto, comodidade, seguranca e ambientes mais inteligentes (JIN et al.,
2014).
2
Essas tecnologias preenche um espaco entre as necessidades decorrentes da evolucao
do mercado, das informacoes, dos usuarios e coisas pelo movimento em direcao a um
framework comum que viabilize novos desafios, como quantidade adicional de informacao
que pode ser gerada e utilizada. Esse desafio de analise de grande quantidades de dados
tera grande impacto no uso da IoT em novas areas de utilizacao dos sensores inteligentes,
cidades inteligentes, transportes e muitas outras que afetarao o futuro do ecossistema glo-
bal da Internet (SKARMETA, 2013). Segundo Ganz et al. (2015) e Skarmeta (2013) as
caracterısticas da IoT, como grande volume de dados, informacoes distribuıdas, relacao de
tempo e localizacao, a heterogeneidade entre os dispositivos, dificultam o processamento
em uma arquitetura centralizada: (1) o grande volume de dados distribuıdos em diferentes
localidades ou sites torna-se uma dificuldade na centralizacao e processamento em tempo
real, que em caso de processamento centralizado requer alto desempenho; (2) essa massa
de dados gerados na IoT requer o processamento em tempo real, que em caso de pro-
cessamento centralizado tambem requer alto desempenho do hardware; (3) avaliacoes de
seguranca e privacidade, tolerancia e falhas, necessidades das empresas, ou atendimento
as normas locais, inviabilizam a arquitetura centralizada; (4) recursos escassos. (BHATT;
PATOLIYA, 2016).
O projeto Apache Hadoop e uma das ferramentas/solucoes mais conhecidas para Big
Data atualmente. Sua finalidade e oferecer uma infraestrutura para armazenamento e
processamento de grande volume de dados, provendo escalabilidade linear e tolerancia a
falhas. Segundo White (2015), em abril de 2008 o Hadoop quebrou o recorde mundial e
se tornou o sistema mais rapido a ordenar 1 terabyte, utilizando 910 maquinas essa marca
foi atingida em 209 segundos. Em 2009, este valor foi reduzido para 62 segundos.
Chen e Zhang (2014a) ao apresentar alguns princıpios essenciais para o projeto de
sistemas Big Data analıticos, mencionam que muitas arquiteturas sao propostas para
processamento paralelo, tanto para processamento em fluxo quanto para processamento
em lote. No entanto, as arquiteturas variam de acordo com o tipo de problema a ser
resolvido.
Essa alta captacao e processamento dados pode ser usado no contexto dentro de uma
Regiao Metropolitana de Sao Paulo (RMSP), na medida em que a utilizacao de sensores
passa a mapear a qualidade do ar. Sistemas de gerenciamento em uma cidade inteligente,
3
ambientes virtuais de aprendizagem e outros sistemas estao presentes nas modalidades de
transmissao on-line do dados obtidos que podem ser usados em benefıcio da populacao
de uma grande metropole, como Sao Paulo. Dentre as areas do conhecimento preocu-
padas com o desenvolvimento do processo de envio de dados de poluentes ambientais
oriundos dos sensores, duas se destacam pelo uso intensivo de dados e por suas relacoes
interdisciplinares: Mineracao de dados sensoriais ou Sensor Data Mining, (SDM ) e Data
Analytics (DA). Embora tenham em comum a preocupacao em analisar dados gerados
no contexto cientifico, visando um melhor entendimento e a melhoria deste contexto,
estas areas apresentam suas particularidades em relacao ao processamento dos mesmos
(CHITTURI; THOMAS; S., 2015).
A pesquisa na literatura por aplicacoes envolvendo Internet das Coisas e Big Data
mostrou uma importante carencia por orientacoes mais objetivas quanto a definicao e
aplicacao de arquiteturas de sistemas, a escolhas de ferramentas e a decisao de apre-
sentacao/hospedagem em nuvem ou em estrutura propria. A lacuna encontrada tornou-se
a motivacao da presente pesquisa que propoe como objetivo implementar uma arquitetura
de Big Data para Internet das Coisas que envolve o processo de coleta em tempo real, ar-
mazenamento de forma distribuıda, processamento analıtico dos dados e visualizacao das
analises. Como objetivo especıfico propoe-se aqui a validacao desta arquitetura atraves
do monitoramento de CO em algumas regioes da regiao metropolitana da cidade de Sao
Paulo.
1.1 Justificativa
Atraves das ferramentas de Big Data foi possıvel coletar, armazenar, analisar e apre-
sentar os resultados obtidos dos ındices de monoxido de carbono, e utiliza-los para indicar
o risco a que as pessoas estao expostas nos locais receptores, tais como, escolas, hospitais,
bairros com alta incidencia de doencas respiratorias, vales, proximidades dos corredores
de transportes, regioes com baixa ventilacao etc. Uma outra vantagem dessas ferramentas
foi a possibilidade de se analisar, atraves de variacoes nas taxas de emissoes, quais seriam
os impactos futuros de polıticas de prevencao da poluicao do ar (CETESB, 2017).
Os dados referentes as emissoes veiculares no inventario da CETESB sao apresentados
em toneladas/ano para a RMSP, ou seja, de forma muito agregada, e a partir deles, nao
4
e possıvel estimar as diferencas intra-urbanas nas emissoes, segundo os carregamentos de
trafego na malha viaria. Em consequencia disso, no modelo de dispersao de poluentes,
as emissoes sao representadas como se toda a frota de automoveis estivesse igualmente
distribuıda na RMSP e emitisse poluentes uniformemente por todo o territorio, o que na
pratica nao acontece (CETESB, 2017).
A implementacao de aplicacoes para Sensor Data Mining (SDM ) e Data Analytics
(DA) passa pela definicao da arquitetura da solucao, pela definicao das solucoes computa-
cionais de hardwares e softwares, pela selecao de linguagens e algoritmos para mineracao
de dados.
Uma das razoes para justificar e o conceito de cidades inteligentes, onde foi disponibi-
lizado alguns sensores MQ7 em modulo ESP2866 12F com uma placa de WiFi embutida,
as quais foram espalhados na RMSP e analisar esses dados em (batch) processamento em
lote ou (stream) processamento em fluxo continuo.
Em complemento ao citado acima, visando prover os servicos capazes de processar e
analisar o massivo volume de dados gerados pela comunicacao entre os diversos disposi-
tivos, usando interfaces abertas que permitam integracao simples entre varias aplicacoes,
o manuseio dos dados obtidos de diversos sensores ou estacoes de medicao de ındices de
CO foram realizados nas ferramentas disponıveis em Big Data atraves de sensores e os
modulos IoT.
1.2 Objetivos
1.2.1 Objetivo Geral
Um dos argumentos que motivou realizar essa pesquisa e o impacto da qualidade de
vida na cidade de Sao Paulo devido a poluicao do monoxido de carbono. A captacao desses
poluentes sao relizados atraves de sensores IoT. A coleta, armazenamento, processamento
e a visualizacao sao requisitos para a analise das tecnologias citadas, apresentar algumas
arquiteturas para este tipo de processamento e aplicar uma delas dentro do conceito
Sensor Data Mining.
5
1.2.2 Objetivos Especıficos
Como objetivos especıficos deste trabalho destacam-se:
1. Comparar algumas arquiteturas para este tipo de processamento;
2. Argumentar requisitos do processamento Big Data, como a arquitetura Hadoop
implementada;
3. Aplicar a arquitetura escolhida ao cenario Sensor Data Mining, analisando con-
juntos compostos por logs do ambiente virtual na coleta, armazenamento, analise e apre-
sentacao desses dados massivos.
4. Delinear o uso e aplicacao dos sensores IoT (MQ7) utilizados.
1.3 Organizacao Documento
Este trabalho e organizado da seguinte forma:
A Introducao apresentada neste capıtulo.
O Capıtulo 2 relaciona o embasamento teorico relevantes a pesquisa, onde sao defini-
dos os conceitos de Big Data com IoT, tecnicas de algoritmos e analise e reconhecimento
de padroes e como ocorre a captura das informacoes. Apresenta-se tambem a descricao
de arquiteturas de Big Data, analisando questoes importantes para a definicao de arqui-
teturas tais como essenciais e restricoes para o projeto de sistemas de Big Data e IoT.
O Capıtulo 3 argumenta-se a metodologia aplicada, o projeto e implementacao in-
cluindo e a coleta, armazenamento, analise e processamento.
No Capıtulo 4 verifica-se os resultados experimentais, a linguagem de programacao
usada e a visualizacao dos sensores IoT.
O Capıtulo 5 destaca as conclusoes da pesquisa, os trabalhos futuros, as possibilidades
de continuidade e os artigos publicados.
6
2 REFERENCIAL TEORICO
2.1 Padroes Qualidade do Ar
O desenvolvimento dos conhecimentos tecnicos e cientıficos encaminhou, a Uniao Eu-
ropeia e os Estados Unidos a revisao de suas referencias, com a atualizacao dos valores
dos padroes adotados, assim como a insercao de novos parametros (CETESB, 2017).
A Organizacao Mundial de Saude ( OMS) em 2015, publicou um documento com uma
revisao dos valores-guia para os poluentes atmosfericos estabelecendo a protecao da saude
da populacao, a luz dos conhecimentos cientıficos adquiridos ate entao (ORGANIZATION,
2006).
Os Padroes de Qualidade do Ar (PQAr) variam de acordo com a abordagem adotada
para balancear riscos a saude, viabilidade tecnica, consideracoes economicas e varios ou-
tros fatores polıticos e sociais, que, por sua vez, baseiam, entre outras coisas, do nıvel de
desenvolvimento e da capacidade do Estado de gerenciar a qualidade do ar. Os procedi-
mentos recomendados pela OMS estabelecem esta heterogeneidade e, admitem que, ao
elaborarem polıticas de qualidade do ar, os governos devem considerar responsavelmente,
suas circunstancias locais antes de adotarem os valores propostos como padroes nacionais.
A OMS tambem recomenda que o processo de estabelecimento de padroes visa atingir
as menores concentracoes possıveis no ambito de limitacoes locais, capacidade tecnica e
prioridades em termos de saude publica (ORGANIZATION, 2006).
O Estado de Sao Paulo em 2008 introduziu um processo de revisao dos padroes de
qualidade do ar, baseando-se nas diretrizes estabelecidas pela OMS, com participacao de
representantes de diversos setores da sociedade. Este processo culminou na publicacao do
Decreto Estadual no 59113 de 23/04/2013, estabelecendo novos padroes de qualidade do
ar por intermedio de um conjunto de metas gradativas e progressivas para que a poluicao
atmosferica seja reduzida a nıveis desejaveis ao longo do tempo (CETESB, 2017).
Tal decreto estabelece que o monitoramento da qualidade do ar no territorio do Estado
de Sao Paulo sera efetuada atraves de Padroes de Qualidade do Ar, observados os seguintes
criterios:
1. Metas Intermediarias (MI ) - estipuladas como valores temporarios a serem cumpri-
7
dos em etapas, visando a melhoria gradativa da qualidade do ar no Estado de Sao Paulo,
baseada na busca pela reducao das emissoes de fontes fixas e moveis, em linha com os
princıpios do desenvolvimento sustentavel (OMS, 2017);
2. Padroes Finais (PF ) - padroes determinados pelo melhor conhecimento cientıfico
para que a saude da populacao seja preservada ao maximo em relacao aos danos causados
pela poluicao atmosferica (OMS, 2017).
A Tabela 1 a seguir apresenta os padroes de qualidade do ar estabelecidos no DE no
59113/2013, sendo que os padroes vigentes estao sublinhados.
Tabela 1: Padroes Estaduais de Qualidade do Ar (CETESB, 2017).
Poluentes Tempo de
Amostra-
gem
MI1
(µg/cm3)
MI2
(µg/cm3)
MI3
(µg/cm3)
PF
(µg/cm3)
Partıculas Inalaveis - (MP10) 24 horas -
MAA1
120 - 40 100 - 35 75 - 30 50 - 20
Partıculas Inalaveis Finas - (MP2,5) 24 horas -
MAA1
60 - 20 50 - 17 37 - 15 25 - 10
Dioxido de Enxofre (SO2) 24 horas -
MAA1
60 - 40 40 - 30 30 - 20 20 -
Dioxido de Nitrogenio (NO2) 1 hora -
MAA1
260 - 60 240 - 50 220 - 45 200 - 40
Ozonio (O3) 8 horas 140 130 120 100
Monoxido de Carbono (CO) 8 horas - - - 9 ppm
Fumaca* (FMC) 24 horas -
MAA1
120 - 40 100 - 35 75 - 30 50-20
Partıculas Totais em Suspensao* (PTS) 24 horas
MGA2
- - - - - - 240 - 80
Chumbo** (Pb) MAA1 - - - 0,5
1 - Media aritmetica anual (MAA).
2 - Media geometrica anual (MGA).
* Fumaca e Partıculas Totais em Suspensao - parametros auxiliares a serem utilizados
apenas em situacoes especıficas, a criterio da Companhia Ambiental do Estado de Sao
8
Paulo (CETESB).
** Chumbo - a ser monitorado apenas em areas especıficas, a criterio da CETESB.
As Metas Intermediarias devem ser obedecidas em 3 (tres) etapas, assim determinadas
(CETESB, 2017):
Meta Intermediaria Etapa 1 - (MI1) - Valores de concentracao de poluentes at-
mosfericos que devem ser respeitados a partir de 24/04/2013;
Meta Intermediaria Etapa 2 - (MI2) - Valores de concentracao de poluentes at-
mosfericos que devem ser respeitados sucessivamente, a MI1, que entrara em vigor apos
avaliacoes realizadas na Etapa 1, reveladas por estudos tecnicos apresentados pelo orgao
ambiental estadual, convalidados pelo Conselho Estadual do Meio Ambiente (CONSEMA);
Meta Intermediaria Etapa 3 - (MI3) - Valores de concentracao de poluentes at-
mosfericos que devem ser considerados nos anos subsequentes a MI2, sendo que seu prazo
de duracao sera definido pelo CONSEMA, a partir do inıcio da sua vigencia, com base
nas avaliacoes realizadas na Etapa 2. Os padroes finais (PF) sao aplicados sem etapas
intermediarias quando nao forem estabelecidas metas intermediarias, como no caso do
monoxido de carbono, partıculas totais em suspensao e chumbo. Para os demais poluen-
tes, os padroes finais passam a valer a partir do final do prazo de duracao do MI3.
A Legislacao Estadual (DE no 59113/2013) estabelece tambem criterios para episodios
agudos de poluicao do ar. A declaracao dos estados de Atencao, Alerta e Emergencia, alem
dos nıveis de concentracao ultrapassados, requer a previsao de condicoes meteorologicas
desfavoraveis a dispersao dos poluentes (CETESB, 2017).
Tabela 2: Criterios para episodios agudos de poluicao do ar (CETESB, 2017).
Parametros Atencao Alerta Emergencia
Partıculas Inalaveis Finas (µg/m3) - 24 h 125 210 250
Partıculas Inalaveis (µg/m3) - 24 h 250 420 500
Dioxido de Enxofre (µg/m3) - 24 h 800 1600 2.100
Dioxido de Nitrogenio (µg/m3) - 24 h 1.130 2.260 3.000
Monoxido de Carbono (ppm - 8h) 15 30 40
Ozonio (µg/m3) - 8 h 200 400 600
9
O ındice de qualidade do ar e uma ferramenta matematica desenvolvida para sim-
plificar o processo de divulgacao da qualidade do ar. Os parametros contemplados pela
estrutura do ındice utilizado pela sao (CETESB, 2017)
A Tabela 2 apresenta os criterios agudos de poluicao do ar, como sao vistos na
sequencia dos gases citados.
• partıculas inalaveis (MP10)
• partıculas inalaveis finas (MP2,5)
• fumaca (FMC)
• ozonio (O3)
• monoxido de carbono (CO)
• dioxido de nitrogenio (NO2)
• dioxido de enxofre (SO2)
Cada poluente medido e calculado um ındice, que e um valor adimensional. Depen-
dendo do ındice atingido, o ar recebe uma qualificacao, que e uma nota para a qualidade
do ar, alem de uma cor, conforme apresentado na tabela abaixo (CETESB, 2017).
Tabela 3: Estrutura do ındice de qualidade do ar (CETESB, 2017).
Qualidade Indice MP10
(µg/m3)
MP2,5
(µg/m3)
O3
(µg/m3)
CO
(ppm)
NO2
(µg/m3)
SO2
(µg/m3)
N1 - Boa 0 - 40 0 - 50 0 - 25 0 - 100 0 - 9 0 - 200 0 - 20
N2 - Moderada 41 - 80 > 50- 100 > 25- 50 > 100 -
130
> 9 - 11 >200 -
240
>20 - 40
N3 - Ruim 81 - 120 > 100 -
150
> 50 -
75
> 130 -
160
> 11 -
13
> 240 -
320
> 40 -
365
N4 - Muito Ruim 121 - 200 > 150 -
250
> 75 -
125
> 160 -
200
> 13 -
15
> 320 -
1130
> 365 -
800
N5 - Pessima > 200 > 250 > 125 > 200 > 15 > 1130 > 800
10
Alem da qualidade do ar apresentada na Tabela 3, iniciando em N1 (Boa) ate a
escala N5 (Pessima) definida pelo orgao regulatorio de Sao Paulo (CETESB, 2017). O
CO apresenta uma variacao de 9 ate maior que 15, o qual conjuga com a informacao da
OMS citado anteriormente.
2.2 Internet das Coisas
A Internet das Coisas (IoT) esta se transformando em uma importante tendencia tec-
nologica, nao so na industria e no meio academico, mas tambem em revistas comerciais e
na mıdia, por causa de seu impacto disruptivo. Uma rede global feita por bilhoes de dis-
positivos ira mudar a maneira como viver e trabalhar, com consequencias nao totalmente
previsıveis. A IoT e percebido como um ambiente interconectado globalmente no qual
uma nova geracao de coisas cotidianas ou objetos inteligentes eliminara a distancia entre
mundos reais e virtuais, fornecendo servicos ciberfısicos personalizados. Do ponto de vista
do desenvolvedor, a realizacao de tal cenario revolucionario IoT e desafiador e tem sido
abordado ate agora de forma evolutiva. Esta abordagem consiste em tirar o melhor de
diferentes paradigmas e tecnologias de computacao bem estabelecidas, como computacao
em nuvem, computacao baseada em agentes e redes de sensores sem fio. De fato, um
processo de desenvolvimento de ecossistemas IoT e intrinsecamente complexo no nıvel de
coisa, bem como no nıvel do sistema, porque caracterısticas como inteligencia, dinamica,
interoperabilidade e autonomia sao transversalmente exigidas (SAVAGLIO; FORTINO;
ZHOU, 2016).
O desenvolvimento de uma aplicacao em Internet das Coisas necessita de uma arqui-
tetura de Big Data para a o armazenamento e analise (Big Data Analytics), do entendi-
mento da producao de sensores e a ligacao dos mesmo em uma rede unica. Nesse sentido,
o objetivo desta secao e apresentar a fundamentacao teorica sobre ambas as tematicas.
A Internet das Coisas pode ser definida como uma infraestrutura de rede global, que
interconecta fısica e virtualmente objetos, com o objetivo de explorar dados capturados
e suas capacidades de comunicacao. Essa infraestrutura abrange e envolve a Internet
e as redes de comunicacao, necessitando de identificacao unica de objetos, sensores e
capacidade de conexao, como suporte para o desenvolvimento independente de servicos e
aplicacoes. A IoT e caracterizada pelo alto grau de captura de dados, transferencia de
11
eventos de rede, conectividade e interoperabilidade (CASAGRAS, 2009).
Adicionalmente, a tecnologia IoT permite a maior interacao e alcance entre seres
humanos e maquinas, incluindo o desenvolvimento e integracao dos mais avancados hard-
ware, software e sensores. A utilizacao do termo Coisas inclui objetos do mundo real
que existem em grandes quantidades e de diferentes tipos que possuirao uma identificacao
unica na Internet.
Figura 1: Captura de dados rede IoT.
(CASAGRAS, 2009)
A Figura 1 ilustra como e um processo de captura de dados em IoT. Os dados sao ori-
ginados pelos objetos fısicos, os quais sao lidos pelo dispositivo atuador, conhecido como
gateway. Os mesmos sao enviados aos sistemas gerenciamento de informacao, conectado
a internet ou outra tecnologia de rede. A conclusao desse processamento dos dados co-
nectados aos dispositivos por uma aplicacao ou servico e uma atuacao na captura dos
dados.
O projeto Casagras (2009) explicita um modelo de alto nıvel da arquitetura da IoT.
Este modelo, reproduzido na Figura 1, consiste de tres camadas:
1. Camada fısica: nesta camada, os objetos fısicos sao identificados e considerados
componentes da IoT por meio de uso do conceito de objeto conectado.
2. Dispositivo gateway processador: estes dispositivos estabelecem e mantem a inter-
12
face entre a camada fısica e a camada de processamento de dados.
3. Camada de processamento de dados: esta camada prove os servicos de analise e
mineracao de dados que suporta as aplicacoes. Os dados sao obtidos a partir da interface
estabelecidas pelo gateway processador.
2.2.1 Aplicacao de Sensores IoT
De acordo com a Figura 2, um diagrama de bloco e apresentado, cada no e um modulo
ESP8266 que pode comunicar com um servidor principal de rede. A funcao do servidor e
iniciar a comunicacao atraves de um protocolo. Periodicamente o servidor coleta os dados
do sensor para um banco de dados. O servidor possui uma interface ethernet para acesso
a internet e para ser executado em uma arquitetura baseada em web-server. Sendo assim,
se faz a transferencia de dados do no (de sensor) para o servidor e em seguida para o no
da rede WiFi e, o usuario pode observar os dados do sensor e controlar a rede de sensores
sem fio do navegador da web remotamente (THAKER, 2016).
A Internet das Coisas oferece uma vasta gama de aplicacoes incorporadas. Com o
avanco da IoT, o conceito de rede de sensores tornou-se cada vez mais aceitavel. Os
sensores sao embutidos a internet e ao seu alcance. Os sensores sao ligados a internet e a
sua cobetura. Ha um numero de sensores com uso diferente, como, medidor de pressao,
medidor de vazao, temperatura, poluentes, CO e umidade medicao, transmissores de
nıvel. As redes sem fio sao usadas principalmente para transferir dados para a estacao de
base do sensor, pois oferece intercomunicacao estavel para instrumentos e controles como
para a automacao de edifıcios .
A maioria dos sensores de rede sao desenvolvidos nos padroes Wireless Fidelity (WiFi)
e ZigBee. O padrao ZigBee diferencia-se por desenvolver menor consumo, por um alcance
reduzido (cerca de 10 metros) em uma area pequena e comunicacao entre duas unidades
poder ser repetida sucessivamente pelas unidades existentes na rede ate atingir o destino
final. Ele trabalha no protocolo IEEE 802.15.4, baseia-se num cluster de topologia de
rede, o qual transmite os dados captados dos nos das estacoes de base. Em uma topologia
de rede em cluster como um sensor de CO e dependendo da distancia, ele levara mais
tempo para enviar dados do sensor ate a base ou servidor, conforme apresentado na Tabela
4 que traz uma comparacao entre os dois padroes (THAKER, 2016).
13
Figura 2: Diagrama de bloco modulo ESP8266.
(THAKER, 2016).
Tabela 4: Comparacao padroes de protocolo. (THAKER, 2016).
Caracterıstica WiFi ZigBee
Range 50-100 me-
tros
10-100 metros.
Taxa de Dados 11 a 54 Mbps 20, 40 e 250 Kbps.
Topologia ponto a
ponto
Ad-hoc,peer to peer,star,mesh.
Frequencia 2.4 - 5GHz 2.4 GHz.
Complexidade Alta Baixa.
Consumo de
Energia
Alta Baixo .
Os padroes citados na Tabela 4, sao definidos da seguinte forma abaixo:
• No inferior, o menor no do sensor sem fio de distancia em ralacao ao servidor.
• Intermediario e o controlador de servidor principal.
• O no supervisor lida com as possıveis falhas e com todo o controle do sistema, caso
acontece algum erro durante a transmissao de dados.
Se na transmissao entre qualquer no da rede wireless e o servidor ocorrer algum
problema, os dados detectados sao armazenados na memoria do sensor, ou no no mais
proximo, e desse no, os dados detectados sao transferidos para a estacao base. Assim,
14
este tipo de mecanismo evita todo tipo de tolerancia de erro na rede de sensores sem fio.
Todos os sensores em uma rede sao configurados de tal forma a melhorar a latencia dos
mesmos (THAKER, 2016).
2.2.2 Sistemas Cognitivos IoT
A literatura apresenta algumas definicoes de sistemas de cognicao de internet das coi-
sas (do ingles, Cognitive Internet of Things (CIoT )). Kelaidonis et al. (2012) menciona
que, uma estrutura para a virtualizacao de objetos do mundo real e a gestao cognitiva de
seus equivalentes virtuais. A estrutura consiste em nıveis de funcionalidade e cada nıvel
compreende entidades cognitivas que proporcionam os meios de auto-gestao e aprendi-
zagem, permitindo aplicacoes e objetos inteligentes e flexıveis. A estrutura apresentada
permite a abstracao da heterogeneidade que deriva da vasta quantidade de diversos objetos
e dispositivos, ao mesmo tempo em que aumenta a confiabilidade e facilita a consideracao
dos pontos de vista de varios usuarios stakeholders (proprietarios de objetos e meios de
comunicacao) integridade empresarial e, portanto, maximizacao das oportunidades de
exploracao.
A necessidade pratica impulsiona a desenvolver um novo paradigma, denominado cog-
nitivo (CIoT), para capacitar a IoT atual como um cerebro para inteligencia de alto nıvel
inspirada primeiramente pela eficacia da cognicao humana. O CIoT tem a capacidade
de ligar o mundo fısico (com objetos, recursos, etc.) e o mundo social (com a demanda
humana, comportamento social, etc.), operacao automatica de rede e provisionamento de
servicos inteligentes (WU et al., 2014).
E um novo paradigma de rede, onde objetos (fısicos / virtuais) sao interligados e se
comportam como agentes, com mınima intervencao humana, as coisas interagem umas
com as outros seguindo um contexto-consciente ciclo percepcao-acao, utilizam a metodo-
logia de compreensao para aprender tanto com o ambiente fısico quanto com redes sociais,
armazenam, processam e tem o conhecimento da base dados, abaixo sao mecanismos de
tomada de decisao eficientes em termos de recursos, com dois objetivos principais (WU
et al., 2014):
• ponte sobre o mundo fısico (com objetos, recursos, etc.) e o mundo social (com a
15
Figura 3: Fluxograma CIoT.
(WU et al., 2014).
demanda humana, o comportamento social, etc), em conjunto com eles mesmos para
formar um ciber - fısico-social (do ingles, Intelligent Physical Cyber Socia (IPCS ));
• permitindo a alocacao inteligente de recursos, operacao e provisionamento de servicos
inteligentes.
A Figura 3 resume algumas tarafes cognitivas, e apresenta um fluxo de CIoT. Como
uma ponte transparente entre o mundo fısico (com coisas fısicas / virtuais, objetos, re-
cursos, etc.) e mundo social (com a demanda humana, o comportamento social, etc.),
juntamente com ela mesma um sistema IPCS. A partir de uma visao de baixo para cima,
o processo do sistema IPCS consiste em quatro camadas principais (WU et al., 2014):
1. Sensing control layer - A camada de controle de deteccao possui interfaces diretas
com ambiente, em que os perceptores sentem o ambiente processando os estımulos e
16
retorno de entrada, observacoes para a camada superior, e os atuadores atuam para
controlar os perceptores atraves do ambiente (WU et al., 2014).
2. Data semantic knowledge layer - A camada de dados semanticos e conhecimento
analisa o sensoriamento de dados para formar util semantica e conhecimento (WU et al.,
2014).
3. Decision making layer A camada de tomada de decisao utiliza o conhecimento
semantico e abstraıda da camada inferior para permitir multiplas ou agentes interativos
para raciocinar, planejar e selecionar a acao mais adequada, com dupla funcao de apoio
aos servicos para redes humanas, sociais e estimular acoes de adaptacao ao ambiente fısico
(WU et al., 2014).
4. Service evaluation layer - A camada de avaliacao do servico compartilha interfaces
como redes sociais, nas quais fornecem servicos sob demanda as redes sociais, e um novo
desempenho em metricas sao projetadas para avaliar os servicos provisionados e retorno
do resultado da avaliacao para o processo de cognicao. Com uma metodologia sintetica,
o CIoT inclui cinco tarefas cognitivas fundamentais, sequencialmente: 1) percepcao, acao
e ciclo; 2) analise macica de dados; 3) derivacao semantica e descoberta de conhecimento;
4) tomada de decisao inteligente; 5) servicos sob demanda.
Em resumo, o ciclo percepcao e acao e a tarefa cognitiva mais primitiva no CIoT,
com a percepcao como entrada do ambiente fısico e acao como saıda para ele. De outra
maneira, o provisionamento de servicos sob demanda diretamente suporta varios servicos.
Infraestrutura como um servico (do ingles Infrastructure as a Service (IaaS ), Platform as a
Service (PaaS ) e Sensing as a Service (SaaS )), e mais amplamente (do ingles, Everything
as a service), com a aplicacao em redes humanas/sociais como tem se observados recen-
temente (WU et al., 2014).
Por outro lado, o Watson Cognitive System da IBM engloba o ecossistema da empresa,
o qual e composto de pergunta e resposta de linguagem natural e machine learning que se
tornou famoso depois de bater dois jogadores humanos peritos no quiz show ”Jeopardy”
em 2011. Ele determina suas respostas e pontuacao de confianca associada com base no
conhecimento que adquiriu. As solucoes Watson fornecem uma combinacao das seguintes
caracterısticas-chave (KOLLIA; SIOLAS, 2016):
17
• Compreender as perguntas atraves da linguagem natural. O Watson fornece pro-
cessamento de linguagem natural para ajudar a entender as complexidades da co-
municacao humana como meio de interacao do usuario e extrair conhecimento de
fontes de dados (KOLLIA; SIOLAS, 2016).
• Gerar e avaliar hipoteses, respostas e evidencias de apoio. O Watson fornece geracao
e avaliacao de hipoteses atraves da aplicacao de analises avancadas para avaliar e
avaliar um painel de respostas baseado apenas em evidencias relevantes
(KOLLIA; SIOLAS, 2016).
Figura 4: Perguntas e Repostas IBM Watson and Deep QA
(WU et al., 2014).
A Figura 4 e uma solucao de pergunta e resposta (do ingles, Question Answering
(QA)) sistema, construıdo pela IBM para aplicar linguagem natural avancada, processa-
mento, recuperacao de informacao, representacao do conhecimento, raciocınio automati-
zada e machine learning, o campo de resposta a questao de domınio aberto. Ele usa gestao
da informacao dados nao estruturados, fornece uma plataforma de integracao de diversas
colecoes de texto, fala e independentemente das abordagens algorıtmicas, linguagens de
programacao ou modelo de domınio subjacente (KOLLIA; SIOLAS, 2016).
Ainda de acordo com a Figura 4, o Watson analisa o seguinte processo:
1. Question Decomposition (Pergunta de decomposicao) - quando a pergunta e apre-
sentada, o Watson analisa para extrair suas principais caracterısticas (KOLLIA; SIOLAS,
2016).
18
2. Hypothesis Generation (Geracao de Hipoteses) - O Watson pesquisa o corpus (que
consiste em conhecimento nao estruturado) para o caminho que pode conter uma resposta
valiosa (KOLLIA; SIOLAS, 2016).
3. Hypothesis and evidence scoring (Hipoteses e evidencias de pontuacao) - Ele com-
para a linguagem da questao e a linguagem de todas as potencialidades, como algoritmos
de raciocınio especıficos. Cada um dos algoritmos executam uma comparacao diferente
(por exemplo: pesquisa para a correspondencia de termos e sinonimos, examine a tempo-
rais e espaciais) e depois produz uma ou mais pontuacoes que indicam o grau de relevancia
da resposta (deducao) a questao (KOLLIA; SIOLAS, 2016).
4. Synthesis (Sıntese) - Cada pontuacao resultante e ponderada contra uma modelo
estatıstico que, captura o desempenho do algoritmo no estabelecimento de inferencia,
entre duas passagens semelhantes para esse domınio, durante o perıodo de treinamento
de Watson. Este Modelo estatıstico e usado para resumir um nıvel de confianca como
a metrica de evidencia do Watson que o candidato A resposta e inferida pela pergunta
(KOLLIA; SIOLAS, 2016) .
5. Final Confidence Merging and Ranking (Confianca Final Fusao e Classificacao) -
Os processos (1 a 4) e repetido para cada uma das respostas dos candidatos ate o Watson
encontrar respostas que sao candidatos mais fortes do outros e finalmente retorna uma
lista classificada deles seguido por sua pontuacao de confianca (KOLLIA; SIOLAS, 2016).
Concluindo, o Watson e plataforma de inteligencia artificial para construir sistemas
cognitivos, os quais disponibilizam diversos servicos cognitivos (do ingles, Application
Programming Interface (API )), alem dos mencionados acima como: Language Speech,
Vision, Data/Insights (Dados nao estruturados), Embodied Cognition Tools, (do ingles,
Natural Language Understanding (NLU )) solucoes de chat bot, e IoT com integracao de
voz.
2.3 Big DATA
O conceito Big Data esta fundamentado, basicamente, em propriedades como volume,
velocidade, variedade e valor. Tais propriedades, muitas vezes resumidas como os V’s do
Big Data, referem-se ao volume de dados gerados e coletados em pouco perıodo de tempo
19
(velocidade), o formato em que esses dados sao disponibilizados, ou seja, de maneira
estruturada, nao-estruturada ou semi-estruturada, e a partir de analises sob os dados, o
valor que se pode agregar ao contexto em que o Big Data esta inserido. Embora se tenha
outros V’s na literatura, os principais apresentados aqui sao propriedades encontradas
em problemas de IoT (MAYER-SCHONB V. CUKIER, 2014; TIGANI; NAIDU, 2014).
Cada acao realizada por um sensor de IoT reflete em uma interacao onde dados sao
coletados e transferidos, gerando um imenso volume de dados na ordem de terabytes por
dia de medicao.
Para coloca-lo em perspectiva, 40 zettabytes e 40 trilhoes de gigabytes estimada em
57 vezes a quantidade de todos os graos de areia em todas as praias da terra. Para atingir
esse valor, todos os dados devem duplicar a cada dois anos ate 2020 Computerworld
(2012), isso incluiria, por exemplo, sensores de maquina e dispositivos inteligentes que se
comunicassem com outros dispositivos.
O Big Data e um dos desafio mais importante para o horizonte de 2020, a quantidade
de dados digitais produzidos excedera 40 zettabytes Data e Cognitive (2017), o equivalente
a 5.200 GB de dados para cada homem, mulher e crianca na Terra (COMPUTERWORLD,
2012).
As propriedades do conceito de Big Data sao chamadas de 5Vs: Volume, Velocidade,
Variedade, Valor e Veracidade, como apresentado na Figura 5. Estas propriedades envol-
vem todo o ecossistema do modelo, chamado de (do ingles, Big Data Ecosystem (BDE )),
que compreende Big Data Infrastructure, Big Data Analytics, Big Data Management e
Big Data Security (DEMCHENKO; LAAT; MEMBREY, 2014).
• Volume: estima-se que o volume de dados disponıvel no universo digital seja de 2,7
zetabytes, ou 2,7 x 1021 bytes, ou ainda 2,7 trilhoes de gigabites (FANG et al., 2015).
• Variedade: alem dos dados estruturados, dados semiestruturados e desestruturados
sao gerados por novos dispositivos tais como smart phones e aqueles categorizados
como IoT, coisas dentre as quais estao sensores remotos de objetos e ambientes,
gerenciadores de infraestrutura e construcoes, cameras e microfones, produtos co-
nectados, realidade aumentada etc. CeArley e Claunch (2012) estimam que 50%
das conexoes a internet sao geradas por coisas, que no ano de 2020 serao mais de
20
Figura 5: Conceito de Big Data Analytics.
(ACHARJYA; AHMED, 2016).
30 bilhoes de equipamentos gerando conexoes permanentes e mais de 200 bilhoes de
equipamentos gerando conexoes intermitentes;
• Velocidade: fluxos de dados sao gerados continuamente em grandes volumes;
• Variabilidade: os dados podem assumir variedades de formas e interpretacoes dife-
rentes;
• Valor: possibilidade de extrair respostas aplicaveis ao negocio (MENDES, 2017).
2.3.1 Desenvolvimento Big Data
Uma extensa coleta de dados da ordem de terabytes, petabytes podendo chegar ate
zettabytes sao gerados por diversos sensores e processados a cada dia, de diversas fontes
21
como sensores e fontes multiplas. A compilacao dessa massa de dados requer um grande
esforco, seja num cidade inteligente, onde estao espalhados diversas formas de obtencao
desses dados ou tudo que e informacao gerado atraves desde um smartphone ou qualquer
outro dispositivo eletronico, em nıveis de conhecimento dessa base de dados para uma
tomada de decisao, com isso a analise em Big Data torna-se um desafio do conhecimento
e desenvolvimento a ser atingido (ACHARJYA; AHMED, 2016).
A origem deste grande volume de dados pode ser trafego de sensores espalhados numa
determinada cidade, transacoes bancarias, pesquisas na Internet, busca em lojas digitais,
imagens de diagnostico medico, sensores de monoxido, dados governamentais, posicao de
um aparelho celular dentro da rede entre outros. Esses dispositivos sao grande geradores
de dados. De acordo com CeArley e Claunch (2012) previram que no ano de 2020 haveria
30 bilhoes de equipamentos permanentemente conectados a Internet e outros 200 bilhoes
de equipamentos intermitentemente conectados, cada um deles produzindo dados. Essa
massa de dados contem informacoes de relevancia, onde o processo de obtencao e objeto
de Mineracao de dados (HAND; MANNILA; SMYTH, 2001).
Os autores Kantardzic (2011) Jain, e Flynn (1999) mencionam a Mineracao de Da-
dos, referindo-se ao uso de algorıtimos, metodologias e tecnicas computacionais para o
desenvolvimento de modelos ou padroes originais. Porem, Hand, Mannila e Smyth (2001)
apresentam uma definicao mais completa ao relacionar a mineracao de dados a analise
de dados observacionais, visando a identificacao de relacionamentos antes ignorados e de
formas singulares que sejam compreendidas e uteis ao proprietario dos dados. Os auto-
res concordam em afirmar que a mineracao de dados diverge da analise exploratoria de
dados da Estatıstica no que refere ao grande volume de dados, a natureza observacional
dos dados e a necessidade da interacao de especialistas na descoberta/desenvolvimento
de modelos ou padroes originais. Sendo assim, os autores consultados acima mencionam
que as diferencas vao alem da definicao da Mineracao de Dados: percebem-se tambem a
dependencia desta area do conhecimento a area nomeada descoberta de conhecimento em
bases de dados (do ingles, knowledge Discovery in Databases (KDD)).
Segundo Silva, Peres e Boscarioli (2016), KDD (do ingles, Data Mining (DM )) nao sao
sinonimos, mesmo que estejam relacionados. Outros termos mais populares se misturam
com o termo mineracao de dados, como (do ingles, Extraction Transform and Loading
22
(ETL)), cubos de uma Data Warehoue, (do ingles, Online Analytical Processing (OLAP))
e estatıstica descritiva. Efetivamente, mineracao de dados e entendida como uma etapa
do processo de descoberta e conhecimento em base de dados, onde, pode abranger os
demais termos.
Tais processos, como identificados por Goldschmidt e Passos (2015) na Figura 6 como:
Figura 6: Processos de Mineracao de Dados.
(GOLDSCHMIDT; PASSOS, 2015).
• Interpretacao e Avaliacao do problema - demonstra o conhecimento do domınio de
aplicacao dos dados estudados para a identificacao de um problema significativo.
Um conjunto de variaveis de dependencia e especificado e, quando possıvel, uma
forma geral desta dependencia e proposta como hipotese inicial;
• Receber os dados transformados - O processo de geracao dos dados para as aplicacoes
de Mineracao de Dados e o observacional, sobre o qual o programador nao tem
influencia;
• Pre Processamento dos dados -processo executado apos o recebimento dos dados e
que inclui a identificacao e remocao de erros, normalizacao e compressao de dados
e selecao de atributos;
• Selecao/extracao do modelo com padrao e relacionamento - constitui na escolha e
na implementacao da tecnica de Mineracao de Dados adequada;
23
• Analise do modelo e conclusoes - definida a decisao sobre os resultados obtidos.
Nesta fase, um modelo mais simples pode ser menos exato, mas facilita a inter-
pretacao (MENDES, 2017).
2.3.2 Sensor Data Mining
A Mineracao de dados de sensores (Mining Data Sensor) por (CHITTURI; THOMAS;
S., 2015), ou (Sensor Data Mining) e o termo que direciona a area que utiliza recursos de
Big Data efetuando uma Data Analytics aplicados a leitura dos dados dos sensores, como
medicao de gas carbonico.
Apesar do processo de SDM ser equivalente aos da Mineracao de Dados (MD), o
mesmo contem caracterısticas que distinguem da mineracao de dados.
• Objetivos: em SDM ha objetivos de pesquisa direcionada, tais como melhorar o pro-
cesso da distribuicao desses sensores, tais como conhecer melhor o comportamento
dos poluentes numa grande metropole.
• Dados: ha regioes com variacoes de gases poluentes, com isso a dados a serem
minerados, podendo conter informacao semantica intrınseca, relacionamentos com
outros dados e hierarquia em multiplos nıveis;
• Tecnicas: embora muitas das tecnicas tradicionais de MD possam ser aplicadas a
SDM, algumas necessitam ser adaptadas ao contexto de saude publica e organiza-
cional.
Patel, Udayakumar e Vyas (2015) mencionam uma estrutura para extrair os dados
de sensores Data Mining sem fio. Essa estrutura consiste em uma nova formulacao para
a tecnica de mineracao de dados usando a regra de associacao por metodo de extracao
distribuıda. As relacoes sequenciais entre sensores sem fio e regras de associacao usando
a tecnica de mineracao de dados para estimar o valor de eventos perdidos e tambem para
melhorar o desempenho. O metodo distribuıdo proposto e projetado com rede de senso-
res sem fio para melhorar o tempo de vida da rede, minimizando o numero de mensagens
necessarias para o processo de mineracao. Os resultados da experiencia mostraram que
a metodologia pode reduzir o numero de mensagens trocadas pelo menos em 40% em
24
comparacao com os outros metodos existentes. A rede de sensores sem fio coleta au-
tomaticamente as informacoes ou dados. A estrutura de representacao comprimida (do
ingles, Compressed Representation Structure (CRS )) e capaz de comprimir os dados e a
rede de sensores fornece facil e rapida coleta de dados. O processo de mineracao do CRS
e comparado e analisado com o (do ingles, Frequent Pattern Growth (FP Growth)) , o
algoritmo de mineracao existente, o resultado tem mostrado que o metodo e melhor do
que FP Growth.
2.3.3 Data Analytics
O estudo do ambiente da analise dos dados sensoriais, seja nas medicoes dos poluentes
no ar baseados em dados em ferramentas de Big Data e IoT conhecido como DA (Data
Analytics).
Em termos computacionais, deve haver uma estrutura razoavel para o armazenamento
dos dados, de maneira que isso seja expansıvel para contemplar o aumento na geracao dos
dados, por exemplo, ampliacao de sensores. Nesse sentido emergem dois outros concei-
tos: O primeiro deles e a distribuicao de dados, possibilitando a ampliacao dos recursos
computacionais de armazenamento de dados e o processamento dos mesmos de forma
paralela, discutido em detalhes a seguir. O outro conceito e o de paradigma de banco
de dados nao relacional ou como popularmente chamado, (do ingles, Not only Structu-
red Query Language (NoSQL)), o qual tem como propriedade a alta disponibilidade para
armazenamento e possibilidade de se expansıvel conforme a demanda do volume de dados.
Os bancos de dados NoSQL sao uma solucao eficaz para o processamento de grandes
dados, mas esses bancos de dados sao heterogeneos. Eles oferecem diferentes modelos de
armazenamento de dados, idiomas para desenvolvedores e usuarios. Esta grande variedade
de plataformas dificulta a interoperabilidade dos dados, a integracao de dados e migracao
de dados de um sistema para outro (HAJOUI et al., 2016).
Atualmente, existem mais de 50 bancos de dados NoSQL com recursos e otimizacoes.
Cada um fornece diferentes mecanismos de armazenamento e recuperacao de dados, que
desempenho, consistencia e disponibilidade. Contudo, como varias bases de dados NoSQL
tem diferentes desempenhos e comportamento diferente em termos de consistencia e dis-
ponibilidade, e significativas para ter aplicacoes que nao estao satisfeitas com apenas um
25
deles (HAJOUI et al., 2016).
Hajoui et al. (2016) define um metodo chamado (do ingles, Analytic Hierarchy Process
(AHP)) representado na Tabela 5, ou processo de hierarquia analıtica como sendo multi
criterios para uma tomada de decisao, o qual permite aos decisores modelar um complexo
problema em uma hierarquia de estrutura, mostrando as metricas, criterios, objetivos e
alternativas. A AHP e composta por varios componentes como estruturacao hierarquica
da complexidade, comparacoes por pares, julgamentos, um metodo derivando pesos e
consideracoes de consistencia. A analise do processo de hierarquia AHP consiste nas
seguintes etapas:
1) Definir os criterios de decisao sob a forma de uma hierarquia de objetivos. A AHP
utiliza uma escala de comparacao normalizada importancia relativa mostrada na Tabela
5, as comparacoes sao feitas nos ındices usando os criterios de proporcionalidade entre
1-9.
2) Apos a geracao do vetor de prioridade, a inconsistencia de comparacao de empare-
lhamento pode ocorrer devido o erro de subjetividade humana.
Tabela 5: Comparacao escalas de atributos (HAJOUI et al., 2016).
Intensidade Definicao
1 Igual Importancia.
2 Intermediario entre 1 e 3.
3 Importancia Moderada.
4 Intermediario entre 3 e 5.
5 Fortemente mais importante.
6 Intermediario entre 5 e 7.
7 Fortemente importante.
8 Intermediario entre 7 e 9.
9 Extremamente Importante.
1/2, 1/3, 1/4,
1/5, 1/6, 1/7,
1/8, 1/9
Recıprocos de 2,3,4,5,6,7,8 e 9.
Um grande problema de interoperabilidade de dados e quando desejam explorar e
analisar dados armazenados em Sistemas. O armazenamento de dados em diferentes
26
representacoes dificulta a consulta e interpretacao de dados. Varias abordagens foram
propostas para facilitar o acesso ao banco de dados NoSQL. Alguns sao baseados na
definicao de uma API generica ou capaz de suportar o acesso aos diferentes dados, outros
sao baseados em abordagens federadas.
(HAJOUI et al., 2016) define seis criterios oriundos do Big Data de interoperabilidade
e outros complementares fazem parte dos padroes essenciais de qualidade em engenharia
de software:
1 - Modelos de dados (C1): modelos de dados utilizados nesta abordagem, armazena-
mento de chaves / valores, armazenamento de documentos e armazenamento baseado em
colunas, uma abordagem apropriada e aquela que inclui os tres modelos de dados, com
isso, mao tem limitacao de modelo de dados na escolha de banco de dados NoSQL.
2 - Quering (C2): define a complexidade das consultas que podem ser executadas,
este criterio e muito importante para aplicacoes que exigem grandes dados analıticos ou
estatısticos, ate mesmo muito determinantes na escolha de uma solucao.
3) Desempenho (C3): avalia a latencia da solucao, este criterio e muito importante,
em grandes aplicacoes a resposta pode ser em tempo real.
4) Portabilidade (C4): pode ser implementada em uma nuvem num ambiente de forma
flexıvel ou nao, pode ser implementadas no mesmo, porque nao precisar alterar o codigo.
A menos que, as bases de dados NoSQL oferecidas pela operador sao diferentes. neste
caso, devemos reescrever o codigo de a solucao.
5) Integracao (C5): a capacidade de adicionar facilmente um novo NoSQL em base
de dados em uma solucao.
6) Mapeamento (C6): se a solucao integrar um (do ingles, Object Relational Mapper
(ORM )) em API para bases de dados NoSQL, uma variante do Java formara uma API.
Dado o numero de bases de dados NoSQL, o mapeamento facilita o desenvolvimento de
aplicativos para usar em NoSQL.
Alem disso, a arquitetura orientada por modelo modeldriven e a metodologia de enge-
nharia podem ser solucao para problema em grandes dados de sensores IoT (HAJOUI et
al., 2016), o termo Big Data Analycs mais detalhado sera apresentado na proxima secao
2.7.
27
O processo de hierarquia analıtica (AHP), e um multi criterio de decisoes certas, os
quais permitem aos decisores modelar um problema complexo e uma estrutura hierarquica,
mostrando as relacoes da meta, objetivos (criterios) e alternativas. O AHP e composto por
varios componentes, tais como a estruturacao hierarquica da complexidade, comparacoes
por pares, julgamentos, um metodo de de consideracoes de consistencia. A analise processo
de hierarquico (AHP), conforme apresentado na ordem de prioridades da Tabela 5.
2.3.4 Big Data Analytics
Entende-se como o conceito de Big Data Analytics a manipulacao de quantidades
de dados nao suportadas por tecnicas e tecnologias tradicionais, bem como a conciliacao
de bases de dados com arquiteturas distintas, sendo elas estruturadas e nao estrutura-
das. Tambem formas inovadoras de processar informacoes para uma melhor percepcao e
tomada de decisao (MAYER-SCHONB V. CUKIER, 2014) (TIGANI; NAIDU, 2014).
Volumes de dados sao gerados a todo momento, milhares de terabytes sao criados
diariamente em um ambiente virtualizado. Cada clique e acao realizada por um sensor
de IoT reflete em uma interacao onde dados sao armazenados e/ou transferidos, e estes
dados podem conter valiosas informacoes, caso sejam devidamente interpretados.
O fluxo de sensores e dispositivos utilizados em aplicacoes e pela web apresentaram
o desafio de processar, analisar, armazenar e entender o grande volume de dados gerado
numa dimensao maior do que os processos, algoritmos e recursos computacionais haviam
tratado (FAN; BIFET, 2013).
Considerando as multiplas origens dos dados, seu volume e variabilidade, Fang et al.
(2015) mencionam sobre a necessidade de colaboracao multidisciplinar e de juntar esforcos
de industrias, academias e governos no desenvolvimento de novos metodos, disciplinas e
forcas de trabalho que juntem as ciencias de redes de dados, gerenciamento de dados,
computacao e estatıstica. Embora, o Big Data relacione-se com a ciencia computacional
intensiva, e suas aplicacoes se estendam as mais diversas areas de pesquisa, tais como
bioquımica, astronomia, bio-informatica, astronomia, economia, negocios, administracao
e sociologia (CHEN; ZHANG, 2014b) (KAMBATLA et al., 2014) citam algumas areas
com grande potencial de benefıcio no uso de tecnicas analıticas em Big Data:
28
• Sensores de IoT espalhados em uma RMSP, e que permitam a conectividade com
as ferramentas de analise, sao de extrema importancia para os decisores de uma
melhor qualidade de vida da populacao.
• As areas de saude e bem-estar sao umas das mais beneficiadas pelo uso de tecnicas
analıticas, tanto pelo benefıcio de bem-estar humano quanto pela quantidade de
dados que a area produz. Dados provenientes de registros medicos, diagnostico por
imagem, farmaceuticos, habitos pessoais, preferencias pessoais e registros financeiros
podem ser cruzados oferecendo significantes melhorias em intervencoes medicas e
bem-estar, bem como diminuindo custos (MENDES, 2017);
• A area governamental e o setor publico sao grandes motivadores do uso de tecnicas
analıticas e Big Data, tanto devido a polıticas governamentais quanto as acoes de
integracao de dados. Oportunidades de diminuicao de custos e de maior disponi-
bilidade somam-se as possibilidades de implementacao do voto eletronico movel,
deteccao de fraudes e de sonegacoes de impostos (MENDES, 2017);
• Internet e redes sociais representam grandes areas de aplicacao para a analise de
dados e Big Data no que tange a entrega de conteudo personalizado. Dados de in-
teracoes em funcao do tempo contribuem para entender comportamentos coletivos,
desenhar fluxos de informacao e contribuir para o gerenciamento de recursos e para
a predicao. Mineracao de grafos, pesquisa e indexacao de imagens e vıdeos ofere-
cem oportunidades de desenvolvimento e identificacao de correlacoes de entidades
(MENDES, 2017);
• Processos computacionais e experimentais em fısica, astronomia, genetica entre ou-
tros, geram grandes quantidades de dados para validacao e geracao de insights ci-
entıficos e demandam recursos computacionais capazes de analisar dados em tempo
real localmente, uma vez que os dados gerados sao maiores do que o potencial de
armazenamento e estao disponıveis geralmente em um local, requerendo tecnicas de
paralelizacao ao inves de tecnicas de computacao distribuıda (MENDES, 2017).
• Outras areas com alto potencial de benefıcio com o uso de tecnicas analıticas e
Big Data sao as relacionadas a natureza e processos naturais. Dispositivos como
satelites, radares e sensores terrestres coletam dados de fenomenos ambientais e seus
29
efeitos, ocupacao urbana, emissao de carbono, alteracao da camada polar, eventos
climaticos extremos, uso de recursos naturais e atividades humanas (MENDES,
2017);
2.3.5 Ferramentas
Demchenko, Laat e Membrey (2014) menciona que as ferramentas de Big Data Analy-
tics atualmente sao oferecidas pelos principais fornecedores mundiais de Cloud Computing
e Big Data, com servicos como o Amazon Elastic MapReduce, Microsoft Azure HD Insight,
IBM Big Data Analytics, Cloudera Enterprise, Cloudera Distribution for Hadoop (CDH ),
Hortonworks Data Flow (HDF ) e Hortonworks Data Platform (HDP), que possuem suıtes
escalaveis deHadoop e ferramentas para Analytics, posicionando-se como fornecedores de
servicos de Big Data e oferecendo seus produtos como servico as a Service.
Para a coleta e analise dos dados dos usurarios em um ambiente virtualizado como o de
Cloud Computing, faz-se necessario o uso de Big Data Analytics. Alem da infraestrutura
padrao presente em Cloud Computing (como processamento, memoria, armazenamento
e rede), outros elementos sao requeridos para suportar este sistema de Data Analytics
como: servicos de clusterizacao, ecossistema Hadoop, Apache, Kafta e outros (que en-
volve ferramentas e servicos), ferramentas especıficas de analise de dados (mineracao de
dados, visualizacao de dados), suporte a bases de dados estruturadas (do ingles, Structured
Query Language (SQL)) e nao estruturadas (NoSQL) e base de dados com processamento
paralelo massivo (do ingles, Massively Parallel Processing (MPP)) (RICHERT, 2013), Big
Data Analytics, como pode ser observado na Figura 7.
Do ponto de vista que diferencia o fenomeno Big Data do fenomeno conhecido como
(do ingles, Business Intelligence (BI )) e a oferta de ferramentas Open Source, muitas
delas desenvolvidas e disponibilizadas por grandes empresas geradoras de dados, tais como
Facebook, Yahoo, Twiter e Linkedin, tornando a implementacao de solucoes e as iniciativas
analıticas em Big Data acessıveis (CHEN; ZHANG, 2014a). A seguir algumas Tabelas,
as quais demonstram o comportamento e caracterısticas das ferramentas analıticas que
suportam o processamento Big Data, relacionadas pelas categorias: processamento em
lote, processamento em fluxo contınuo e ferramentas de analise interativa.
No campo de Big Data Analytics, pode-se classificar a analise de dados em tres nıveis,
30
Figura 7: Big Data Analytics Infraestutura.
(DEMCHENKO; LAAT; MEMBREY, 2014).
de acordo com a profundidade da analise: analıtica descritiva (Descriptive Analytics);
analıtica preditiva (Predictive Analytics) e analıtica prescritiva (Prescriptive Analytics).
Na analıtica descritiva, historicos sao explorados para apresentar o que ocorreu. Podem
ser utilizados algoritmos de regressao para identificar tendencias nas bases de dados.
Este nıvel de analise esta associado a sistemas de BI. O nıvel de analise preditiva busca
prever probabilidades e tendencias futuras, ela usa tecnicas estatısticas como regressao
linear e regressao logıstica para entender comportamentos e predizer acoes. Por meio de
mineracao de dados (data mining) identifica e extrai padroes para prover informacoes
e previsoes. Ja a analise analıtica prescritiva e voltada para a eficiencia e tomada de
decisao. E possıvel simular analises em sistemas complexos a fim de coletar informacoes
sobre o comportamento deste sistema, identificar problemas e, por meio de determinadas
tecnicas, encontrar solucoes otimizadas para a resolucao destes problemas (PROVOST;
FAWCETT, 2013).
31
A Tabela 6 apresenta ferramentas de processamento em lote, uma vez processados
grandes quantidades de dados inclusive em paralelo, nao sao apropriadas para processa-
mento de dados em fluxo contınuo.
Tabela 6: Principais ferramentas de processamento em lote em Big Data (CHEN; ZHANG,
2014b; ACHARJYA; AHMED, 2016).
Aplicacao Ferramenta Descricao
Infraestrutura e
Plataforma
Apache Ha-
doop
Plataforma para processamento paralelo distribuıdo composta um
nucleo comum (Hadoop Commom), um sistema de arquivos dis-
tribuıdo (HDFS), um framework para agendamento e gerencia-
mento de recursos do cluster (Hadoop YARN) e um sistema de
processamento paralelo (Hadoop MapReduce) (APACHE, 2017b).
Infraestrutura e
Plataforma
Microsoft
Dryad
Infraestrutura para programacao paralela e distribuıda onde a
computacao e executada como um grafo direcionado (MICRO-
SOFT, 2016).
Analise de da-
dos
Apache
Mahout
Ambiente de programacao que permite o uso de algoritmos de
aprendizagem de maquina escalaveis. Suporta algoritmos de fil-
tragem, classificacao, agrupamento, reducao de dimensionalidade
e outros (APACHE, 2017c).
Business Intelli-
gence
Jaspersoft
Business
Intelligence
Ferramenta de analise, integracao e visualizacao de dados que su-
porta integracao com bancos de dados NoSQL. Dispoe de versao
licenciada pelo modelo AGPL e versoes pagas (JASPERSOFT,
2017).
Business Analy-
tics
Pentaho
Business
Analytics
Plataforma de analise, visualizacao e integracao de dados que su-
porta integracao com distribuicoes e ferramentas Haddop, bases de
dados NoSQL e bancos de dados analıticos. Conecta-se tambem
com os principais bancos de dados relacionais e com outras origens
de dados, inclusive em nuvem (PENTAHO, 2017).
Analise
avancada por
aprendizagem
de maquina
Skytree Ser-
ver
Plataforma de analise de dados Big Data que interage com im-
plementacoes Hadoop e que implementa algoritmos de sistemas
de recomendacao, analise preditiva, agrupamento e pesquisa de
similaridade.
Visualizacao de
dados
Tableau Ferramenta de visualizacao de dados que suporta integracao com
origens de dados Hadoop, NoSQL, relacionais e arquivos.
Gerenciamento
e integracao de
dados
Talend Open
Studio
Plataforma Open Source baseada em Apache Hadoop que permite
integracao e analise de dados Big Data.
32
A Tabela 7 enumera algumas das ferramentas projetadas para processamento em fluxo
contınuo, tal como o processamento requerido em arquivos de log, dados de sensores, dados
(do ingles, Machine to Machine (M2M )), telefonia e outros dados com grande volume e
velocidade e com tipos complexos. Esses tipos de dados sao chamados de streams e exigem
ferramentas projetadas especificamente para este tipo de processamento. O processamento
em fluxo contınuo requer baixa latencia de resposta, caracterıstica esta nao presente no
modelo de processamento (CHEN; ZHANG, 2014b).
Alem de ferramentas para processamento de dados em lote e em fluxo contınuo, fer-
ramentas de analise interativa de dados Big Data tambem sao oferecidas na modalidade
Open Source, dentre as quais podem ser destacadas as que aparecem na na Figura 8
(MENDES, 2017).
Tanto o Google e Apache Drill utilizam sistemas de analise interativa, usam o modelo
MapReduce para os processamentos, os quais sao citados na Tabela 8.
Figura 8: Plataformas de Big Data e quanto ao processamento.
(CHEN; ZHANG, 2014a).
33
Tabela 7: Principais ferramentas de processamento stream em Big Data (CHEN; ZHANG,
2014a; ACHARJYA; AHMED, 2016).
Aplicacao Ferramenta Descricao
Processamento
em tempo real
Apache
Storm
Sistema de computacao distribuıda e tolerante a falhas para pro-
cessamento de streams de dados. Aplicavel a processamento
analıtico em tempo real, aprendizagem de maquina em tempo
real, ETL e outras aplicacoes distribuıdas.
Processamento
contınuo de
dados
Apache S4 Sistema de computacao distribuıda desenvolvido pelo Yahoo e li-
berado para a Apache. Processa fluxos contınuos de dados de
forma distribuıda, tolerante a falhas e componentizada.
Processamento
em tempo real
de machine
data
SQLstream
s-server
Plataforma para processamento analıtico de dados em tempo real
baseada em processamento em memoria de fluxos de dados nao
estruturados com consultas SQL. Aplicavel a dados gerados por
maquinas (machine data) (SQLSTREAM, 2017).
Processamento
em tempo real
de machine
data
Splunk Ferramenta de visualizacao e analise em tempo real de machine
data. Machine Data pode ser definido como registro definitivo
de todas as atividades e comportamentos de clientes, usuarios,
transacoes, aplicacoes, servidores, redes e dispositivos moveis. E
isto e mais que somente logs. Isto inclui configuracoes, dados de
APIs, filas de mensagens, eventos de mudancas, a saıda de co-
mandos de diagnostico, registros detalhados de chamadas e dados
de sensores de sistemas industriais, e outros dados? (SPLUNK,
2017).
Sistema de
mensageria
distribuıda
Apache
Kafka
Sistema de distribuicao de mensagens que analisa dados operaci-
onais e dados de atividades de usuarios em websites em fluxo e
com persistencia de dados.
Plataforma de
negocios em
tempo real
SAP Hana Plataforma analıtica de dados de negocios em tempo real e in-
memory e integravel com outras aplicacoes analıticas.
34
Tabela 8: Principais ferramentas de analise interativa em Big Data (CHEN; ZHANG,
2014a).
Ferramenta Descricao
Google Dremel Sistema de analise interativa complementar as computacoes baseadas em
Map/Reduce escalavel e que permite agregacoes de grandes volumes de da-
dos.
Apache Drill Sistema de analise interativa semelhante ao Google Dremel que permite pes-
quisa em bases de dados nao relacionais, que usa o modelo Map/Reduce de
processamento e que permite consultas ad hoc baseadas em SQL em grandes
volumes de dados (APACHE, 2017a)
2.4 ARQUITETURAS PARA BIG DATA e INTERNET DAS
COISAS
Considerando um projeto de Big Data e IoT, a definicao de arquitetura estabeleceu-
se como a principal tarefa e que idealmente deve levar em consideracao o desafio dos
dados apresentados pelo volume recebido e armazenados. Para aplicacoes Big Data para
mineracao de dados sensoriais sao aplicaveis as etapas da descoberta de conhecimento em
bases de dados (KDD) de pre-processamento, mineracao de dados e pos-processamento
(ACHARJYA; AHMED, 2016). Combinar estes requisitos torna-se um desafio para o Big
Data.
Na pesquisa de Big Data ha duas maneiras de processamento que sao observados,
um que computa o volume completo de dados gerando a partir dele mesmo e outro que
computa apenas o volume de dados mais recente. A estes modelos de processamento
referem-se os nomes de processamento em lote (batch) e processamento em fluxo contınuo
(stream), respectivamente. No primeiro tipo de processamento os volumes de dados sao
grandes mas as restricoes de tempo de resposta para a analise sao menos exigentes. O
segundo tipo de processamento e o requerido por aplicacoes de analise em tempo real, nos
quais a variavel tempo de resposta, ou latencia, torna-se um fator crıtico para o sucesso
(CHEN; ZHANG, 2014a)
Os sistemas e plataformas Big Data disponıveis sao adequadas a resolver um dos dois
problemas, em lote ou em fluxo contınuo, e o conceito de ”tamanho unico”(one size fits
35
all) quanto a ferramentas Big Data nao e aplicavel (CHEN; ZHANG, 2014a). As solucoes
recomendadas para lidar com os dois tipos de problemas sao o uso de ferramentas e
plataformas diferentes (CHEN; ZHANG, 2014a) ou escalonamentos diferentes (SINGH;
REDDY, 2015). Ao apresentar suas recomendacoes para a escolha de uma arquitetura
Big Data, (SINGH; REDDY, 2015) reforcam a necessidade de o objetivo da arquitetura
ser bem definido: otimizacao para velocidade ou para carga de trabalho. A otimizacao da
plataforma visando a velocidade implicara a consideracao de sistemas para processamento
em tempo real tais como (do ingles, Graphics Processing Units (GPUs) e Field Program-
mable Gate Arrays (FPGAs)). Se o objetivo e processar grandes quantidades de dados
sem restricoes quanto ao tempo de processamento, sistemas que escalem horizontalmente
sao mais adequados.
A necessidade que alguns sistemas tem de analisar dados em tempo real pode conduzir
ao questionamento se seria possıvel analisar Big Data e IoT em tempo real atendendo a
etapa de pre-processamento dos dados essencial a descoberta de conhecimento em bases
de dados (KDD) (ACHARJYA; AHMED, 2016).
2.5 Parametros do sistema Big Data para SDM
As recomendacoes para um sistema Big Data e das caracterısticas de sistemas de SDM
podem ser representadas por requisitos para uma arquitetura Big Data, os quais pode-se
usar em IoT (MENDES, 2017).
1. Estrutura a dados de grande volume - deve ser possıvel tratar grandes volumes de
dados, com seguranca (MENDES, 2017);
2. Estrutura a dados variados - deve ser possıvel armazenar dados variados, incluindo
os semi e os nao-estruturados (MADDEN, 2012);
3. Suportar dados adquiridos constantemente - deve ser possıvel lidar com dados em
uma latencia suficiente para processamento em fluxo contınuo (SOUZA; AMAZONAS,
2013);
4. Obtencao dos dados - Deve ser possıvel receber dados de diferentes origens de
dados, com dados em modelos e estruturas diversos (MENDES, 2017);
36
5. Pre-processamento - A arquitetura deve suportar o pre-processamento dos dados,
o que inclui mas nao se restringe a retirada de anomalias, normalizacao e compressao
dos dados, selecao de atributos, tratamento de dados inconsistentes, tratamento de dados
heterogeneos e de dados desatualizados (MENDES, 2017);
6. Analise - Devem ser suportados metodos analıticos e aplicacoes diversos (PATEL;
UDAYAKUMAR; VYAS, 2015);
7. Escalabilidade - A arquitetura deve ser escalavel de modo que mantenha a latencia
em nıveis aceitaveis mesmo diante do aumento de carga de trabalho. O modelo deve aten-
der demandas de processamento em lote e em fluxo contınuo dentro de limites aceitaveis.
Devem ser utilizados recursos de processamento e armazenamento paralelo, distribuıdo e
em memoria sempre que possıvel (MENDES, 2017);
8. Exatidao e precisao - Devem ser mantidos nıveis consideraveis de acuracia e de
precisao nos processos;
9. Robustez e tolerancia a falhas - Deve ser possıvel a recuperacao diante de falhas
decorrentes de duplicidade de dados, indisponibilidade de nos e concorrencia; desenvolvi-
mento;
10. Extensibilidade - A arquitetura deve permitir modificacoes sem grandes impactos
de desenvolvimento;
11. Mınima manutencao - Devem ser aplicadas solucoes o mais simples possıvel, dimi-
nuindo a necessidade de manutencao, serem liberadas e suportadas consultas arbitrarias;
12. Suporte a consultas - Devem ser aprovadas e suportadas consultas arbitrarias;
13. Capacidade de correcao - A arquitetura deve permitir a ativacao de rastreamento
para a identificacao de erros (SOUZA; AMAZONAS, 2013);
14. Restricoes de uso - A arquitetura deve estabelecer, em toda sua extensao, a
aplicacao de restricoes de uso de dados que por motivos eticos, de privacidade, de pro-
priedade intelectual, de reputacao, de seguranca ou de restricoes legais nao possam ser
expostos ou utilizados, inclusive quando forem utilizados dados que juntos aumentem a
probabilidade de identificacao. As restricoes devem poder ser aplicaveis para um usuario,
para um grupo de usuarios ou para todos os usuarios (MENDES, 2017).
37
15. Interoperabilidade - Uma caracterıstica que se refere a capacidade de diversos
sistemas e organizacoes trabalharem em conjunto (interoperar) de modo a garantir que
organizacoes e sistemas computacionais compartilhem para trocar informacoes de maneira
eficaz e eficiente (CASAGRAS, 2009).
2.6 Sistema, arquitetura, framework e modelo de referencia
As publicacoes na literatura para sistemas IoT e Big Data, para Mineracao de Dados
Sensoriais SDM ou Data Analytics, contribuem para as definicoes arquitetura, framework
e modelo de referencia. Consideram- se as apresentacoes antes de aplica-los.
• Sistema - diz respeito ao conjunto de hardware e software e suporte humano que
pertencem a uma empresa ou organizacao. Incluem computadores bem como os
programas necessarios para o processamento de dados e as pessoas responsaveis
pela respectiva gestao (ISO, 2008).
• Arquitetura - Definicao e representacao de uma estrutura para a composicao de
um sistema em termos de seus componentes computacionais, suas propriedades e
interacoes. A arquitetura de software de um programa ou sistema computacional
e a estrutura ou estruturas do sistema que abrange os componentes de software,
as propriedades externamente visıveis desses componentes e as relacoes entre eles
(ISO, 2011).
• Framework - pode ser definido como classes ou quadros cooperativos que tornam
um projeto reutilizavel para uma classe especıfica de software (IEEE. . . , 2010).
• Modelo de Referencia - determina-se como uma colecao de conceitos sobre um tema,
facilitando o particionamento de relacionamentos entre topicos relevantes do as-
sunto, podendo ser expressado por formas comuns de descricao (IEEE. . . , 1999).
A definicao de arquitetura para sistemas Big Data e IoT aparece da necessidade de
incluir e pesquisar dados em grandes volumes e com uma latencia aceitavel para o contexto
do sistema. Mesmo o escalamento dos tradicionais bancos de dados e ate mesmo a inclusao
de recursos de processamento assıncrono nao sao capazes de responder satisfatoriamente
38
a problemas tais como corrupcao de dados, tolerancia a falhas e alta disponibilidade
(NATHAN N.; WARREN, 2015).
A literatura pesquisada destaca algumas arquiteturas que permitem a combinacao de
processamento de grandes volumes e baixa latencia: Lambda e Kappa (WINGERATH
et al., 2016) (CARDENAS-BENITEZ et al., 2016) (CHENG et al., 2015) (NASIR, 2016)
(FORGEAT, 2015) e Hadoop. Em paralelo tambem tem - se o aparecimento da arquitetura
Liquid como um padrao para processamentos em tempo quase real (FERNANDEZ et al.,
2015).
2.7 Arquitetura Liquid
Para um processamento em tempo quase real, Gallidabino et al. (2016) propoem a
arquitetura Liquid, ainda emergente nesse cenario tecnologico, onde o princıpio basico e
o processamento de duas camadas, processing layer e messaging layer sendo com baixa
latencia nas mensagens, as quais recebem, pre-processam e entregam dados para os pro-
gramadores.
Basicamente o funcionamento da arquitetura Liquid e fornecer acesso de dados de
baixa latencia para suporte em tempo real stream, alem de de suportar tambem aplicacoes
em lote ( batch). Ela suporta processamento incremental altamente disponıvel (FERNAN-
DEZ et al., 2015).
A Figura 9 apresenta como a arquitetura que interliga com o HDFS, Map Reduce
(MR), Apache Samza ate chegar nos terminais, tudo isso em uma baixa latencia na
conexao entre eles. A parte inferior mesma figura apresennta a interligacao ao Big Data,
mostrando como pode ser a base do trabalho em SDM e DA representados pelos sensores,
logs e as metricas envolvidas.
2.7.1 Estrutura da Arquitetura Liquid
Ainda de acordo com a Figura 9 a estrutura de da arquitetura Liquid consiste em
duas camadas cooperantes.
1. Uma camada de mensagens fornece acesso a dados com base em metadados, que
39
Figura 9: Integracao de dados arquitetura Liquid.
(FERNANDEZ et al., 2015).
permite aos sistemas back-end ler dados de pontos especıficos em tempo real. Ele e
distribuıdo em escala para grande volumes de dados com alta disponibilidade.
2. Outra camada de processamento executa trabalhos semelhantes a ETL (Extract
Transform and Load) para sistemas back-end, garantindo acesso de dados de baixa latencia.
Esta camada pode executar processamento de dados antes de passar os dados para o sis-
tema back-end, desde a limpeza e normalizacao dos dados ate o calculo de estatısticas
agregadas ou a deteccao de erros.
2.7.2 Distribuicao quanto ao Processamento
Como resultado da arquitetura Liquid, ela incorpora, como se fosse uma a separacao
benefica do armazenamento e computacao de stack, Map Reduce, (do ingles, Hadoop
Distributed File System (HDFS ), o qual resulta em:
• Pode escalar o armazenamento e a computacao independentemente.
• Quanto a tolerancia a falhas e difıcil de conseguir a chegar a camada de processa-
40
mento.
A camada de mensagens usa Apache Kafka, um sistema altamente disponıvel de men-
sagens publicadas / subscritas distribuıdas. Os dados sao armazenados persistentemente
em logs comprometidos e distribuıdos, que sao replicados para alta disponibilidade. Para
acesso a dados de alto rendimento, a camada de mensagens explora o padrao anti-caching
comportamento arquivo cache do sistema, no qual os dados sao mantidos na (do ingles,
Random Access Memory (RAM )) por padrao e para o disco se nao for usado por um
perıodo de tempo. Como os logs comprometidos so e possıvel definir com precisao o
perıodo de tempo, apos quais dados devem ser liberados para o disco, melhorando o de-
sempenho para sistemas back-end, os quais leem o cabecalho do log (FERNANDEZ et al.,
2015).
A camada de processamento e implementada usando Apache Samza, uma estrutura de
processamento de fluxo distribuıdo que segue um processamento de paradigma, ele executa
tarefas do tipo ETL eficientemente e com baixa latencia, representando explicitamente o
estado como parte da computacao. A camada de processamento armazena dados anotados
na camada de mensagens como metadados, o que permite que os trabalhos fluxos de dados
de forma dinamica (FERNANDEZ et al., 2015).
2.7.3 Limitacoes da Arquitetura
Sendo ainda uma arquitetura recente, o emprego da mesma com uso intensivo de
recursos podem gerar trabalhos em execucao na mesma infra-estrutura, a implementacao
executa em uma Virtual Machine (VM ) Java.
A implementacao da arquitetura Liquid aborda esses desafios, na camada de men-
sagens, as particoes sao balanceadas atraves de clusters disponıveis, o que permite um
melhor equilıbrio da camada de processamento, porem a camada de processamento acaba
isolando os recursos de nıveis do sistema operacional, como Linux e Apache Yet Another
Resource Negotiator (Yarn), com isso restringe a memoria e recursos das Central Proces-
sing Units (CPUs) de cada tarefa. (FERNANDEZ et al., 2015).
41
2.8 Hadoop Distributed File System
Uma das solucoes mais conhecidas para analise de dados em larga escala e o projeto
Apache Hadoop, concebido por Doug Cutting, o mesmo criador da biblioteca de busca
textual Apache Lucene (WHITE, 2015). Os componentes principais desta ferramenta
consistem em um sistema de arquivos distribuıdos para ser executado em clusters com-
postos por maquinas de baixo custo, e tambem pelo framework de programacao paralela
MapReduce.
Quando uma base de dados alcanca a capacidade maxima de espaco preenchida por
uma unica maquina fısica, torna-se necessario distribuir esta responsabilidade com um
determinado numero de computadores. Sistemas que gerenciam o armazenamento de
arquivos em uma ou mais maquinas interligadas em rede sao denominados sistemas de
arquivos distribuıdos (WHITE, 2015).
Para Coulouris et al. (2013), um sistema de arquivos distribuıdo permite aos pro-
gramas armazenarem e acessarem arquivos remotos exatamente como se fossem locais,
possibilitando que os usuarios acessem arquivos a partir de qualquer computador em
uma rede. Questoes como desempenho e seguranca no acesso aos arquivos armazenados
remotamente devem ser comparaveis aos arquivos registrados em discos locais.
Segundo White (2015) seu funcionamento depende dos protocolos de rede que serao
utilizados. Portanto, todos os problemas relacionados a propria rede tornam -se inerentes
a este tipo de abordagem, adicionando uma complexidade muito maior aos sistemas de
arquivos distribuıdos, por exemplo, em relacao aos sistemas de arquivos convencionais.
No contexto Big Data, que engloba um volume muito grande de dados, a utilizacao de
um mecanismo para armazenar informacoes ao longo de varias maquinas e indispensavel.
Neste sentido, a camada mais baixa do Hadoop e composta por um sistema de arquivos
distribuıdos chamado Hadoop Distributed File System, ou HDFS.
O HDFS foi projetado para executar MapReduce jobs que, os quais, realizam leitura,
processamento e escrita de arquivos extremamente grandes (VENNER, 2009). Apesar de
apresentar semelhancas com os sistemas de arquivos distribuıdos existentes, seu grande
diferencial esta na alta capacidade de tolerancia a falhas, no baixo custo de hardware que
e requerido e tambem na escalabilidade linear.
42
2.8.1 Caracterısticas Principais
O HDFS foi projetado para armazenar arquivos muito grandes a uma taxa de trans-
missao de dados constante, sendo executado em clusters com hardware de baixo custo
(WHITE, 2015). Suas principais caracterısticas de design podem ser descritas a seguir:
• Arquivos muito grandes: Este sistema de arquivos distribuıdos e capaz de arma-
zenar arquivos que chegam a ocupar terabytes de espaco, portanto, e utilizado por
aplicacoes que necessitam de uma base de dados extremamente volumosa. Segundo
Shvachko et al. (2010), os clusters do Hadoop utilizados pela Yahoo chegam a ar-
mazenar 25 petabytes de dados.
• Streaming data access : Operacoes de leitura podem ser realizadas nos arquivos
quantas vezes forem necessarias, porem um arquivo pode ser escrito apenas uma
unica vez. Esta abordagem pode ser descrita como write-once, read-many-times
(WHITE, 2015). Este sistema de arquivos distribuıdos foi construıdo partindo da
ideia que este modelo e o mais eficiente para processar os dados. O HDFS tambem
realiza a leitura de qualquer arquivo a uma taxa constante, ou seja, a prioridade e
garantir vazao na leitura e nao minimizar a latencia ou prover interatividade com
aplicacoes em tempo real, como e realizado em sistemas de arquivos com proposito
geral.
• Hardware de baixo custo: O HDFS foi projetado para ser executado em hardwares
que nao precisam ter necessariamente alta capacidade computacional e tambem alta
confiabilidade. O sistema foi desenvolvido partindo do pressuposto que a chance
dos nos ao longo do cluster falharem e extremamente alta, portanto, mecanismos
de tolerancia a falha foram desenvolvidos para contornar este problema, permitindo
uma maior flexibilidade quanto ao uso de diferentes tipos de hardwares. A Tabela
9 apresenta as configuracoes das maquinas utilizadas pelo cluster Hadoop presente
na empresa Yahoo.
43
Tabela 9: Configuracoes do Cluster Yahoo ((WHITE, 2015); (SHVACHKO et al., 2010)).
Processador
(CPU)
Memoria
RAM
Espaco em disco Sistema Operacional
2 quad-core de 2
a 2,25 GHz
16 a 24 GB 4 discos SATA de 1 Terabyte Red Hat Enterprise Linux Server
2.8.2 MapReduce
MapReduce pode ser definido como um algorıtimo de programacao voltado para pro-
cessamento de grande volume de dados ao longo de varias maquinas, obtendo resultados
em tempo razoavel (WHITE, 2015). Utiliza-se o conceito de programacao distribuıda
para resolver problemas, adotando a estrategia de dividı-los em problemas menores e
independentes.
De acordo com Dean e Ghemawat (2008), o usuario deste modelo especifica uma
funcao map, que devera processar um par chave, valor gerando como produto conjuntos
intermediarios de pares chave, valor, e tambem define uma funcao reduce, responsavel
por unir todos os valores intermediarios associados a uma mesma chave.
Este modelo e baseado nas primitivas map e reduce presentes na linguagem R e
tambem em muitas outras linguagens de programacao funcional. Este paradigma foi
adotado, pois percebeu-se que varios problemas consistiam em realizar o agrupamento
das entradas de acordo com uma chave identificadora, para entao processar cada um
destes conjuntos (DEAN; GHEMAWAT, 2008).
Um programa MapReduce separa arquivos de entrada em diversas partes indepen-
dentes que servem de entrada para as funcoes map. As saıdas destas funcoes sao orde-
nadas por chave, valor e, posteriormente, transformadas em entradas do tipo chave,
lista(valores) para a funcao reduce, onde o resultado final sera salvo em um arquivo de
saıda. O Quadro 1 apresenta de maneira generica as entradas e saıdas das funcoes map e
reduce.
A grande colaboracao desta abordagem esta em disponibilizar uma interface simples
e poderosa que permite paralelizar e distribuir computacao em larga escala de forma
44
map (k1, v1) → list (k2,v2)
reduce (k2, list (v2)) → list (v2)
(DEAN; GHEMAWAT, 2008)
Quadro 1: Entradas e saıdas MapReduce.
automatica (DEAN; GHEMAWAT, 2008). O desenvolvedor precisa apenas se preocupar
com as funcoes map e reduce, todo esforco para dividir o trabalho computacional ao longo
das maquinas, entre outras questoes operacionais, sao de responsabilidade do proprio
framework.
Sob a perspectiva dos dados distribuıdos, essa e uma caracterıstica extremamente
importante, pois operacoes simples de manipulacao de dados como, por exemplo, uma
simples medida de media, torna-se um desafio aos sistemas computacionais, necessitando
assim de um processamento colaborativo de todos os recursos computacionais disponıveis
para a realizacao da operacao. Nesse aspecto um conceito importante em Big Data e
conhecido como Hadoop. O que esta por de traz desse nome sao suas propriedades para o
armazenamento distribuıdo chamado de HDFS e o MapReduce, responsavel pela consulta
aos dados armazenados de forma distribuıda. A Figura 10 ilustra o processo e a aplicacao
desses conceitos. Nessa, os dados que chegam sao quebrados logicamente e distribuıdos
em arquivos sob diferentes recursos. No momento da analise, na fase do map os diversos
recursos sao consultados, os dados desejados sao recuperados localmente e organizados
(shuffle). Por fim, na fase de reduce, os resultados isolados sao combinados e apresentados.
Figura 10: Diagrama esquematico do funcionamento do algorıtimo de MapReduce.
(THAKER, 2016).
A apresentacao dos dados pode ser feita de uma maneira visual, explorando assim
45
conceitos de visualizacao de dados ou entao como um resultado que pode ser armazenado
em uma base de dados para analises futuras.
A Figura 10 ilustra o diagrama esquematico do funcionamento do algorıtimo de Ma-
pReduce MapReduce. As entradas sao divididas em partes iguais denominadas input
splits, cada uma destas partes dao origem a uma map task, responsavel por gerar pares
intermediarios chave, valor. Cada map task realizada uma chamada a funcao map
definida pelo usuario.
Nas fases shuffle e sort, os pares intermediarios sao agrupados e ordenados de acordo
com sua chave. Este processo e realizado pelo framework. Por fim, as reduce tasks
recebem como entrada os valores resultantes das etapas shuffle e sort. Para cada entrada
chave, lista(valores) existente, uma reduce task executa uma chamada a funcao reduce
especificada pelo desenvolvedor.
Uma alternativa para contornar este problema seria o uso da programacao paralela,
analisando os arquivos em diferentes processos, utilizando quantas threads fossem ne-
cessarias. Todavia esta solucao nao e a mais eficiente, ja que os arquivos podem apresen-
tar diferentes tamanhos, ou seja, alguns processos seriam finalizados em um intervalo de
tempo menor, impossibilitando maximizar a capacidade de processamento.
Uma abordagem mais eficiente seria separar todos os arquivos em blocos pre defi-
nidos e entao dividı-los em processos distintos. Esta solucao requer um mecanismo de
sincronizacao complexo e de difıcil implementacao. Seria necessario agrupar todas as pa-
lavras e suas respectivas ocorrencias em cada uma das threads nos diferentes processos
em execucao. E mesmo assim a capacidade de processamento estaria limitada a apenas
uma maquina.
Este problema que se mostrou complexo possui uma solucao simples e de facil cons-
trucao quando utiliza-se a abordagem apresentada pelo paradigma MapReduce. Nesta
situacao, torna-se necessaria apenas a definicao de uma funcao map para realizar a con-
tagem de cada palavra presente nos arquivos de entrada, e tambem de uma funcao re-
duce para agrupar cada uma destas palavras e realizar a contagem final dos registros de
ocorrencias. Um codigo simulando com as funcoes map e reduce para este problema sao
apresentadas no Quadro 2.
46
map (String key , String value):
// key: document name
// value: document contents
for each word w in value:
EmitIntermediate (w, ”1”);
reduce ( String key , Iterator values ):
// key: a word
// values : a list of counts
int result = 0;
for each v in values :
result += ParseInt(v);
Emit( AsString( result ));
(DEAN; GHEMAWAT, 2008)
Quadro 2: Codigo simulando MapReduce.
No Quadro 2, o programa MapReduce divide todos os arquivos de entrada em input
splits, na qual a chave do par chave, valor e composta pelo numero do respectivo input
split, enquanto o valor e o proprio conteudo de sua parte no texto. Para cada par de
entrada uma funcao map sera chamada e realizara quebra da linha em palavras. Cada
um destes tokens e associado ao valor 1, gerando pares de saıda no formato palavra 1.
O framework MapReduce realiza as etapas shuffle e sort para agrupar e ordenar os
resultados das map tasks. Em seguida, para cada chave existente sera realizada uma
chamada a uma funcao reduce, na qual e responsavel por percorrer uma lista efetuando a
soma dos valores encontrados. O resultado obtido e registrado em um arquivo de saıda.
A Figura 11 apresenta o fluxo completo da execucao de um programa MapReduce
para o problema da contagem de palavras.
• Desenvolvimento MapReduce
A solucao adequada para o contexto Big Data, na qual sao analisados arquivos
extremamente volumosos, consiste na construcao de um algoritmo baseado em com-
putacao distribuıda. A grande vantagem de utilizar o modelo MapReduce e que o
desenvolvedor precisa apenas adaptar o problema para ser resolvido com as funcoes
47
Figura 11: Fluxo atividades contador de palavras.
Fonte: Adaptada pelo autor.
map e reduce. Toda a complexidade envolvida em paralelizar o processamento e
realizada pelo framework.
O MapReduce e um paradigma que permite uma implementacao flexıvel e simples
para esta situacao, para tal e necessario apenas tres coisas: Uma funcao map, uma
funcao reduce e um pedaco de codigo para execucao do job (WHITE, 2015).
Na Tabela10 estao as atividades que ocorrem em um MapReduce, e os jobs com os
responsaveis por cada uma delas.
48
Tabela 10: Atividades de um MapReduce (VENNER, 2009).
Atividade Responsavel
Configurar Job Desenvolvedor
Dividir arquivos de entrada em input splits Hadoop Framework
Iniciar map tasks com seus respectivos in-
put splits
Hadoop Framework
Definir funcao map utilizada pelas map
tasks
Desenvolvedor
Shuffle, onde as saıdas de cada map task
sao divididas e ordenadas
Hadoop Framework
Sort, onde os valores de cada uma das cha-
ves geradas pelas map tasks sao agrupados
Hadoop Framework
Iniciar reduce tasks com suas respectivas
entradas
Hadoop Framework
Definir funcao reduce, na qual e chamada
uma vez para cada chave existente
Desenvolvedor
Escrever os resultados das reduce tasks em
N partes no diretorio de saıda definido nas
configuracoes do job, onde N e o numero
de reduce tasks
Hadoop Framework
49
3 METODOLOGIA, PROJETO E IMPLEMENTACAO
3.1 Metodologia
Esta pesquisa caracteriza-se como exploratoria quanto ao seu objetivo e aplicada
quanto a sua natureza, pois se propos a estudar ferramentas, requisitos e arquiteturas
de processamento Big Data e combinou-os em uma aplicacao que processe e analise dados
de sensores IoT.
A pesquisa Quanto ao procedimento, a pesquisa caracteriza-se como bibliografica,
uma vez que o referencial teorico conduziu ao entendimento do assunto e a definicao dos
procedimentos metodologicos.
A pesquisa bibliografica identificou oportunidades de pesquisa nas areas de Sensor
Data Mining (SDM) e Data Analytics (DA), visando a acoes aplicadas. Chitturi, Thomas
e S. (2015) registram que aplicacoes de SDM tem sido desenvolvidas com base em diversas
tecnicas e tarefas de SDM, incluindo a analise e a visualizacao de dados.
O metodo de pesquisa proposto estrutura-se em nas seguintes etapas, ilustradas na
Figura 12:
• Medir: Sensores IoT ESP8266 para coleta de CO sao colocados em diferentes regioes
da regiao metropolitana da cidade de Sao Paulo.
• Coletar: Essa etapa consiste na obtencao de dados dos sensores IoT ESP8266.
• Armazenar: Nesta fase o armazenamento foi executado em um banco de dados No-
SQL, parte do processo ao obter esses dados, o qual envia a arquitetura HDFS,
aplicando a funcao MapReduce.
• Analisar: Realiza uma analise exploratoria de como processamento distribuıdo.
• Apresentar: Esta fase da metodologia, implementa a visualizacao de dados.
50
3.2 Descricao do Projeto para Implementacao da Arquitetura
Os sensores ESP8266 foram instalados num ambiente da Regiao Metropolitana de
Sao Paulo (RMSP), com o objetivo de coletar os dados de monoxido de carbono.
Figura 12: Arquitetura proposta e implementada neste Trabalho.
Fonte: Elaborada pelo autor.
O sensor ESP8266 com modulo arduıno captam os dados de monoxido de carbono,
transmitem-os via WiFi, acessam o servidor de coleta para armazenamento atraves de
uma API que permite a integracao simples de diversos tipos de sensores, o qual por sua
vez armazena os dados coletados em um banco de dados No-SQL como mostrado na
Figura 12. Os dados podem entao ser acessados via API para analise e processamento.
3.3 Configuracao dos Sensores
A disposicao dos sensores IoT esta ilustrada na Figura 13. Sao esses os sensores que
capturaram medicoes referente aos dados enviados sobre monoxido de carbono, os quais
foram espalhados em 4 regioes na RMSP. O consumo de energia de cada sensor e de
aproximadamente 560 mw.
O sensor ESP8266 e similar a um arduıno, onde o mesmo tem a vantagem de se co-
municar pela rede wireless, pois tem suporte ao protocolo TCP/IP . A unica desvantagem
e que so possibilita a leitura de um sensor analogico, pois tem apenas uma entrada.
51
Figura 13: Exemplo da topologia de sensores.
Fonte: Elaborada pelo autor.
O modulo de sensor comunica-se com o microcontrolador, utilizando uma interface
serial. E ainda existem dois pinos General Purpose Input Output (GPIO) , ou entrada
e saıda de uso geral, permitindo que o modulo seja programado diretamente e a GPIO
acionada sem a necessidade de uso de um microcontrolador.
A caracterısticas do Modulo Wireless ESP8266 (BR-ARDUINO.ORG, 2017) e:
• Conexao a redes padrao 802.11 B/G/N ;
• Alcance aproximado: 91 metros;
• Tensao de operacao : 3.3 VDC ;
• Comunicacao serial: pinos TX e RX ;
• Modos de operacao : Cliente, Access Point, Cliente+Access Point ;
• Suporta comunicacao TCP e User Datagram Protocol (UDP).
O nıvel de sinal utilizado pelo modulo foi de 3.3V, assim o pino RX (recepcao serial)
nao foi ligado diretamente ao Arduıno. Utilizou-se uma fonte externa para alimentacao
52
do modulo, pois dependendo da situacao ele pode exigir ate 300 mA de corrente, e o limite
do Arduıno e de 50 mA.
A compilacao dos dados na memoria dos sensores esta representado na Figura 14 de
acordo com o Sketch do Arduıno. Na representacao ha um sensor, chamado de IoTm002,
o qual solicita a autenticacao do Iot Server para o inicio da gravacao dos dados.
Tabela 11: Lista de Componentes Utilizados (Fonte: Elaborado pelo autor.)
Qtde. Componentes Utilizados
1 Placas Circuito Impresso Pcb Fibra De Vidro 10x5 cm
1 Fonte de 5V
1 Capacitores de 10 uF de 16V
1 Resistores de 560 Ω
2 Led´s
1 CI regulador de tensao para 3V LM 317
1 Capacitor de 220 uF de 50V
1 Modulo MQ7 - Sensor de Monoxido de Carbono
1 Chave Reset
1 Modulo WiFi ESP8266D
1 Resistores de 10 KΩ por circuito
1 Barra de pinos
2 Conectores KRE
1 Conector Borne P4
A Tabela 11 apresenta os componentes que foram utilizados para montar o sensor IoT
de apenas um dos circuitos utilizados na coleta de monoxido de carbono.
A Figura 15 apresenta o layout referente aos circuitos IoT usados nesta pesquisa.
Nesse circuito ha uma fonte de alimentacao de 5V, um circuito integrado LM317, um
regulador de tensao positiva para correntes ate 1 Ampere com uma dissipacao maxima
de 2 Watts, com isso a tensao de saıda de todo circuito foi de 3Vcc. Todos os demais
componentes eletronicos como: modulo ESP8266 e os sensores MQ7 para medicao do gas
monoxido de carbono estao representados no layout do circuito. O layout ainda tem uma
placa na cor vermelha (ESP8266-12E) com ESP8266 embutido, baixo custo, transmissao
WiFi, conexao: 802.11 b/g/n, tem todos os componentes (ate a antena) integrados a
placa, e baixo consumo de energia. Essa placa (ESP8266-12E) ajuda na interface com a
53
Figura 14: Sketch Programacao Sensor
Fonte: Adaptada de (ARDUINO, 2017).
programacao Sketch do Arduino, usando um microcontrolador via conexao com Universal
Serial Bus (USB)). Para estabelecer a conexao e a gravacao dos sensores usou- se a juncao
da placa do modulo arduıno com as conexoes fısicas de cada sensor Tx-Rx e GND-GND
para fechar o jumper do circuito.
A configuracao e para que a cada 300.000 ms ou 5 minutos cada sensor faz uma leitura
de CO e envia os dados pela rede.
3.4 Armazenamento e Analise dos Dados
A transmissao dos dados para armazenamento no servidor foi atraves do protocolo
Hypertext Transfer Protocol (HTTP) (LEACH et al., 1999). Os dados coletados sao
passados ao servidor por meio de uma API (MASSE, 2011), com isso, o servidor persiste
os dados no formato java script object notation (json), veja um exemplo dessa estrutura
de armazenamento nas Figuras 16 e 17.
54
Figura 15: Layout sensor IoT.
Fonte: Elaborada pelo autor.
Figura 16: Dados json e Url IP servidor
Fonte: Elaborada pelo autor.
55
Desta forma, os sensores transmitem os dados por stream ao servidor. A requisicao
em lote (batch) dos dados com os valores das requisicoes e feito pela mesma API por meio
do R Studio.
O R Studio e um ambiente de desenvolvimento livre e integrado com a linguagem de
programacao R (SILVA; PERES; BOSCARIOLI, 2016). Atraves do R Studio possibilitou
utilizar linhas de comando e direcionar o dados capturados dos sensores ESP8266 para as
ferramentas Apache Hadoop, HDFS, com o MapReduce, o qual realizou-se o processamento
e analise dos dados.
A visualizacao dos dados sera feita com uso do Shiny, um framework para aplicacoes
web usado na linguagem R, cuja aplicacao permite apresentar valores configuraveis pelo
usuario em caixas de dialogos.
3.5 Servidor NoSQL
Os dados capturados dos sensores de monoxido de carbono foram armazenados no
formato json, o qual permitiu compilar e gravar direto no servidor No-SQL, representado
na Figura 17 (STANDARD, 2017).
A url http://201.6.243.44:3000/dump representou o dump coleta de dados dos sensores
no formato json, representado na Figura 16 e na Arquitetura do servidor da Figura 12.
Tabela 12: Configuracoes do Cluster servidor IoT Server.
Fonte: Adaptada de (WHITE, 2015) (SHVACHKO et al., 2010).
Processador
(CPU)
Memoria
RAM
Espaco em disco Sistema Operacional
2 quad-core de 2
a 2,25 GHz
4 GB 1 disco SATA de 500 GI-
GABYTE
Ubuntu server 16.04.2 LTS
A Tabela 12 apresenta os dados de configuracao do servidor IoT Server NoSQL,
referente a CPU, Memoria, Espaco em disco e Sistema Operacional.
De acordo com a Figura 17, o processamento em batch ou stream desse grande volume
de dados, cuja uma funcao map, processou um par chave, valor gerando como produto
56
Figura 17: Dashboard servidor NoSQL
Fonte: Elaborada pelo autor.
conjuntos intermediarios de pares chave, valor, e tambem define uma funcao reduce,
responsavel por unir todos os valores intermediarios associados a uma mesma chave dos
sensores.
O Dashboard do servidor IoT Server visualiza em cada instante de 300.000 ms o input
com os sensores IoTm001, IoTm002, IoTm003, ou IoTm004 de modo aleatorio.
57
4 RESULTADOS EXPERIMENTAIS
4.0.1 Linguagem de Programacao
A linguagem de programacao aplicada foi o R de framework R Studio, usada para
desenvolver software de estatıstica e analise de dados, levantamentos de data miners, a
qual possibilitou compilar os dados dos sensores (SILVA; PERES; BOSCARIOLI, 2016).
4.0.2 Visualizacao de Dados
O projeto Shiny e um framework para aplicacoes web usado na linguagem R, cuja
uma aplicacao apresentou valores configuraveis em caixas e graficos. Nos exemplos abaixo
optou-se por utilizar informacoes captadas em stream ou fluxo contınuo dos sensores.
As Figuras 18 e 19 representam os resultados da incidencia do ındices de monoxido
de carbono num determinado perıodo de analise para duas diferentes regioes da cidade de
Sao Paulo.
Os dados referentes ao sensor 2 (na cor azul) da Figura 18 permitem verificar que
no horario de maior incidencia e concentracao de CO, o sensor registrou uma medicao
entre 30 e 35 ppm de monoxido carbono. Os dados do sensor 4 (na cor vermelho) estao
representados na Figura 19, na mesma amostragem de medicao do sensor tem-se o sensor
2, uma maior concentracao com CO, entre 45 e 55 de ppm.
Para efeitos comparativos dos resultados a Figura 20 representa os dados do sensores
agrupados, onde percebe-se claramente a diferenca nas medicoes entre os dois sensores,
sugerindo assim que na regiao monitorada pelo sensor 4 ha maiores ındices poluicao do
gas monoxido de CO.
Vale ressaltar que por estes valores medidos, pode-se perceber nitidamente que os
valores estao muito acima da media da OMS, os quais estabelecem no maximo 10 ppm.
Os resultados mınimos medidos foram entre 30 e 35 ppm referente ao sensor 2. Alem
disso, na secao 2.1 os padroes de qualidade do ar na Tabela 1, os criterios de atencao de
poluicao do ar na Tabela 2 e a estrutura dos ındices de qualidade dor ar sao apresentados
juntamente com a Tabela 3.
58
library(anytime); library(jsonlite); library(curl); library(rmr2); library(rhdfs)
url = ’http://201.6.243.44:3000/dump’
#Recebe a url acima e converte o formato json para list
document = fromJSON(txt=url)
#Converte o Posix recebido do horario para BRT
document$IoTm004$date=anytime(document$IoTm004$date/1000)
document$IoTm003$date=anytime(document$IoTm003$date/1000)
document$IoTm002$date=anytime(document$IoTm002$date/1000)
document$IoTm001$date=anytime(document$IoTm001$date/1000)
#Converte todos os dados captados dos sensores de CHARACTER para NUMERIC
document$IoTm001$data=as.numeric(document$IoTm001$data)
document$IoTm002$data=as.numeric(document$IoTm002$data)
document$IoTm003$data=as.numeric(document$IoTm003$data)
document$IoTm004$data=as.numeric(document$IoTm004$data)
#Para um melhor manuseio desmembra o document recebido no vetor Sensores
Sensor1=document$IoTm001; Sensor2=document$IoTm002
Sensor3=document$IoTm003; Sensor4=document$IoTm004
#Plot Monoxido de Carbono por Tempo (linhas) - Sensor 2
Sensor2x=Sensor2[(as.Date(Sensor2$date)=as.Date(”2017-05-29”) &
as.Date(Sensor2$date)=as.Date(”2017-06-04”) ),]
y = seq(from = as.POSIXct(min(Sensor2x$date)),
to = as.POSIXct(max(Sensor2x$date)), length.out = (length(Sensor2x$date)))
plot (y, Sensor2x$data, type=”n”, xlab=”Tempo”, ylab=”Monoxido de Carbono”)
lines(y, Sensor2x$data, type=”o”, col=”blue”, sub=)
#Plot Monoxido de Carbono por Tempo (linhas) - Sensor 2 e Sensor 4
plot (z, Sensor4x$data, type=”n”, xlab=”Tempo”, ylab=”Monoxido de Carbono”)
lines(z, Sensor4x$data, type=”o”, col=”red”, sub=)
lines(y, Sensor2x$data, type=”o”, col=”blue”, sub=)
legend(”topright”, c(”Sensor 2”, ”Sensor 4”), col = c(”blue”, ”red”),
text.col = ”black”, lty = c(1,1,1,1), pch = c(1,1,1,1), cex=0.60, ncol = 2)
Fonte: Elaborada pelo autor.
Quadro 3: Progamacao dados sensores R Studio.
59
Figura 18: Coleta Dados Sensor 2.
Fonte: Elaborada pelo autor.
Figura 19: Coleta Dados Sensor 4.
Fonte: Elaborada pelo autor.
O Quadro 3 ilustra o script da programacao executada no ambiente do R Studio,
referente as coletas dos sensores 2 e 4, os quais resultam nos graficos ilustrados na Figuras
18 e 19.
O Quadro 4 apresentou os comandos entrada e saıda das sessoes referente um loop
(ou delay) de atualizacao dos sensores ate a leitura do servidor IoT server de 300.000 ms
para a leitura de cada sensor, o qual e lido pela url citada no quadro em stream.
Os arquivos apresentados (server.R e ui.R), o primeiro executa a logica da pro-
gramacao, funcoes e processamentos necessarios e o segundo apenas a visualizacao das
60
function(input, output, session) observe(#atualiza a url apos 300.000 ms
invalidateLater (300000)
url = ’http://201.6.243.44:3000/dump’
Fonte: Elaborada pelo autor.
Quadro 4: Script url e Loop.
library(shiny)
titlePanel(”Medidas de CO na Regiao Metropolitana da Cidade de Sao Paulo”),
sidebarLayout(
sidebarPanel(
selectInput(”select”, label = h3(”Sensores”),
choices = list(”Sensor 1”= 1, ”Sensor 2”= 2, ”Sensor 3”= 3,
”Sensor 4”= 4), selected = 1),
dateRangeInput(”dates”, label = h3(”Intervalo”)),
hr(),
actionButton(”atualizar”, ”Exibir”)
),
mainPanel(
tabsetPanel(type = ”tabs”,
tabPanel(”Media”, plotOutput(”plot1”)),
tabPanel(”Quartis”, verbatimTextOutput(”plot2”)),
tabPanel(”Tempo”, DT::dataTableOutput(”plot3”)),
tabPanel(”Densidade”, plotOutput(”plot4”)),
tabPanel(”Box Plot”, plotOutput(”plot5”)),
tabPanel(”Histograma”, plotOutput(”plot6”))
))))
Fonte: Elaborada pelo autor.
Quadro 5: Biblioteca ui.R.
61
Figura 20: Coleta Dados Sensor 2 e 4.
Fonte: Elaborada pelo autor.
informacoes, conforme apresentado no Quadro 5 um exemplo dos comandos ui.R.
Com base nos dados armazenados, outras formas de abordagem de analises podem
ser realizadas. Os resultados seguintes apresentarao a construcao de paineis de analises
(dashboards) que permitem explorar melhor os resultados e auxiliar um gestor na analise
e definicao de polıticas publicas para reducao da poluicao do ar.
Os dashboards sao construıdos, com o uso de uma biblioteca em Linguagem R chamada
Shiny. Essa biblioteca permite a construcao de uma aplicacao baseada em web, em que
os dados sao apresentados em uma interface web e as analises sao feitas nos scripts de
programacao desenvolvido em R (RSTUDIO, 2017). Diferente de outras linguagens e
bibliotecas de programacao, onde as analises sao feitas e os resultados devem ser salvos
temporariamente para entao o uso de uma outra ferramenta de visualizacao, a grande
motivacao e vantagem do Shiny e manter a integracao dessas duas componentes em uma
unica aplicacao.
A interface do R Studio, como se pode ver na Figura 21, permite que se faca analises
em tempo real dos sensores com exploracoes analıticas como media, densidade, quartil,
boxplot e histograma. Outras medidas ainda podem ser incorporadas nesta interface, assim
como diversos outros sensores. Especificamente nesta figura esta apresentado o valor da
media. Como os dados estao sendo coletados a cada 300.000 ms, e estamos exibindo
62
a informacao por hora (eixo x do grafico), significa que os dados de CO apresentados
(eixo y) e a media das medicoes feitas a cada hora. A interface ainda tera uma outra
componente para permitir futuramente que se possa escolher o intervalo de tempo para o
calculo da media, ou seja, dia, mes e ate ano.
Figura 21: Visualizacao dos valores medios coletados pelo sensor 2.
Fonte: Elaborada pelo autor.
• Densidade
Para o exemplo de analise de densidade, novamente sera usado o sensor 2 como re-
ferencia. A analise da densidade ilustrada na Figura 22 mostra que ha uma distribuicao
nao linear nos ındices de CO. Ou seja, ha uma concentracao entre 20 a 25 ppm de CO por
uma variacao de 0,03 da densidade aferida, porem em outro determinado dia, apresentou-
se um acumulo de 30 a 35 ppm de monoxido de carbono em uma variacao maior da
densidade em aproximadamente 0,10.
• Quartil
Para conhecer melhor as medicoes que estao sendo feitas, uma analise importante a
se fazer e com o calculo dos valores de resumo. A analise nas Figuras 23 e 24 apresenta
medidas como media, mediana, quartil e ainda, o valor mınimo, maximo e valor ausente
(caso ocorra). Aqui tambem pode-se definir um intervalo de tempo para apresentar a
analise.
63
Figura 22: Densidade sensores
Fonte: Elaborada pelo autor.
Figura 23: Quartil sensor 2.
Fonte: Elaborada pelo autor.
Figura 24: Quartil sensor 4.
Fonte: Elaborada pelo autor.
• Boxplot
As medidas de resumo ainda podem ser apresentadas com o uso Boxplot que pra-
ticamente consolida graficamente as medidas em valores de mınimo, media, mediana e
64
maximo obtido de CO. A Figura 25 ilustra o resultado essa plotagem para as medicoes
do sensor 2.
Figura 25: Boxplot sensor 4
Fonte: Elaborada pelo autor.
• Histograma
Figura 26: Histograma sensor 2.
Fonte: Elaborada pelo autor.
O histograma apresentado nas Figuras 26 e 27 exemplifica e confirma que no horario
de menos concentracao de partıculas, ou seja em horario de menos poluicao atmosferica,
65
Figura 27: Histograma sensor 4.
Fonte: Elaborada pelo autor.
os ındices estiveram um pouco acima da recomendacao da OMS, e nos horarios de grande
concentracao de monoxido os ındices concentraram entre entre 30 e 48 ppm.
Nota - se que o sensor 4 em relacao ao sensor 2, principalmente nos horarios de pico
com maior circulacao de veıculos apresentou o maior ındice de monoxido de carbono na
atmosfera. Na media um acrescimo em torno de 14% em relacao a uma medicao na RMSP.
A execucao da arquitetura completa implementada neste trabalho de analises mais
profundas sobre os resultados que estao sendo coletadas, mantem-se aqui o escopo do
projeto que foi a proposta e implementacao de uma arquitetura para coleta de dados de
sensores de CO e o armazenamento e analise dos dados usando conceitos de Big Data e
Internet das Coisas.
4.1 Resultados HDFS e MapReduce
O Quadro 6 apresenta os comandos, algumas bibliotecas (library’s) vetores e funcoes
usadas para executar o HDFS e aplicar o Mapreduce, ate a recuperacao dos dados inseridos
no comando from.dfs , este resultado pratico confirma a teoria exemplificada no referencial
teorico na Secao 2.
O sensores IoT Server estao representados pelas variaveis x1, x2, x3 e x4 (sensores
IoTm001,IoTm002, IoTm003 e IoTm004 ), o range estabelecido em relacao aos sensores
66
library(jsonlite); library(curl); library(rmr2)
url = url(’http://201.6.243.44:3000/dump’) x=fromJSON(txt=url)
x1= x[[1]][c(0:500),]; x2= x[[2]][c(500:1000),]
x3= x[[3]][c(1000:1500),]; x4= x[[4]][c(1500:2000),]
simu1 = to.dfs(x1); simu2 = to.dfs(x2); simu3 = to.dfs(x3); simu4 = to.dfs(x4)
mapper= function(k,v) date = as.numeric(v$date) data = rbind(as.numeric(v$data)) return(keyval(1,data))
reduce =function(k, v) soma = (mean(v)) return(keyval(1,soma))
calc1 = mapreduce( input=simu1, map= mapper, reduce = reduce )
calc2 = mapreduce( input=simu2, map= mapper, reduce = reduce )
calc3 = mapreduce( input=simu3, map= mapper, reduce = reduce )
calc4 = mapreduce( input=simu4, map= mapper, reduce = reduce )
visualiza1 =from.dfs(simu1) #transformo a saıda num dataframe visualiza1
visualiza2 =from.dfs(simu2) #transformo a saıda num dataframe visualiza2
visualiza3 =from.dfs(simu3) #transformo a saıda num dataframe visualiza3
visualiza4 =from.dfs(simu4) #transformo a saıda num dataframe visualiza4
Fonte: Elaborada pelo autor.
Quadro 6: HDFS e MapRduce Stream.
foram da seguinte maneira: x1: 0 a 500, x2: 500 a 1000, x3: 1000 a 1500 e x4: 1500 a
2000, referente as posicoes de leitura de CO, na sequencia que os dados foram capturados,
essa variacao poderia ter outro range definido, como de 0 a 1000, de 2000 a 10.000, ou da
primeira ate a ultima coleta de dados. Esse criterio de escolha dos mesmos foi aleatoria,
referente a leitura do monoxido de carbono, a qualquer tempo essa medicao pode ser
realizada, desde que os sensores estejam enviando o sinal via WiFi para o servidor IoT
Server.
Apos a programacao realizada no Quadro 6, a Figura 28 apresenta um resumo com
os resultados obtidos do Hadoop, o painel gerencial e algumas aplicacoes, como e o pro-
cessamento distribuıdo, as metricas do cluster, cores virtuais, cores totais, reservado e
nos ativos. Neste caso, tem-se apenas uma maquina configurada, o cloudera manager,
podendo ampliar para um cluster maior de maquinas que desejar. Aumentando o numero
de maquinas e consequentemente o numero de dados, o Active Nodes ira mudar de 1
para 50 ou ate quanto suportar a capacidade de armazenamento. O Memory Total pode
aumentar de 8 GB para 50 GB ou superior.
67
Ainda na Figura 28 cada vez que executa o Map Reduce, ele organiza as informacoes,
onde os stream e jobs estao estruturados para facil entendimento como: arquivos subme-
tidos, arquivos pendentes em espera e arquivos executados (do ingles, Apps Submitted,
Apps Pending, Apps Running); cada vez que roda a funcao MapReduce.
Figura 28: Aplicacoes gerenciadas HDFS.
Fonte: Elaborada pelo autor.
Os resultados esperados sao registrados num arquivo de saıda com algumas das prin-
cipais rotinas executadas referente a Figura 28 como:
• ID - apresenta o enderecamento de cada rotina dos sensores IoT, a posicao 0001 do
sensor 1, assim sucessivamente ate a posicao 0004 do sensor 4.
• User - o nome estabelecido como o usuario de um VM Cloudera.
• Name - referente ao job stream executado pela funcao MapReduce.
• States e Final Status - considera os jobs executados e o status, se foram ou nao bem
sucedidos, e qual seria o erro, caso ocorresse.
A Figura 29 complementa a Figura 28 com o Hadoop User Experience (HUE ).
Neste dashboard visualiza-se, o processamento em cada etapa do Hadoop e da aplicacao
MapReduce, os destaques sao: o estado da analise com os parametros: bem-sucedido, em
execucao, falhou ou eliminado. O processamento de cada sensor IoT, o sensor 1 teve a
68
Figura 29: Execucao do HUE.
Fonte: Elaborada pelo autor.
duracao de 1,32 min em relacao ao sensor 4, o qual executou - se em 50 segundos, um
rendimento de 32% superior ao sensor 4 em relacao ao 1, por outro lado, o 3 e 4 estiveram
muito proximo os tempo de processamento.
A Figura 30 ilustra o stream job do sensor 4, o qual obteve o menor tempo de proces-
samento em comparacao com os outros, como segue-se abaixo:
• Tentativas: ele traz o numero de tentativas de execucao do processamento, junta-
mente com o numero do container 1497793764801000401000001 atribuıdo.
• Tarefas: nas funcoes map, task e reduce sao gerados dois logs task :14977937648010004m000000
e 14977937648010004m000001 e um reduce: 14977937648010004r000000, sendo o m
de map e r de reduce dos logs executados.
• Metadados: apresenta-se: o id, user, quantidade de execucoes do MapReduce, o
tempo das rotinas, a funcao dfs, o threshold dos sensores, a latencia, o timeout de
300.000 ms (dfs.client.mmap.retry.timeout.ms), basicamente apresenta-se, o resul-
tado com um resumo das rotinas do HDFS.
• Contadores: as consolidacoes gerais de maps e reduces, quantos arquivos foram
escritos e lidos em bytes e a soma total de ambos.
• MR2: e um aplicativo distribuıdo que executa o MapReduce em cima do YARN.
Apesar de apresentar semelhancas com os sistemas de arquivos distribuıdos existentes,
o HDFS, diferencia-se na alta capacidade de tolerancia a falhas, baixa latencia e no baixo
69
Figura 30: Logs e ID Job.
Fonte: Elaborada pelo autor.
custo de hardware, e tambem na execucao do MapReduce jobs, os quais, realizam leitura,
processamento e escrita de arquivos muito grandes como pode ser observado na Figura
30.
70
5 CONCLUSOES
A presente pesquisa propos a analisar e implementar uma arquitetura para internet das
coisas, utilizando ferramentas de Big Data. A proposta de desenvolver uma arquitetura
de redes de sensores, espalhados na regiao metropolitana de Sao Paulo, via WiFi, e a
sua validacao como se obteve neste trabalho, possibilita pensar em um monitoramento
mais amplo na cidade para medicoes de CO, cujos dados coletados podem ser analisados
e usados para apoiar campanhas de reducao desse poluente. Portanto, conclui-se que os
objetivos almejados neste trabalho foram alcancados com exito.
Um dos fatores relevantes para obter o exito na pesquisa foi a utilizacao de sensores IoT
com modulo ESP8266 capazes de coletar informacoes e depois enviar os dados por meio de
rede WiFi e internet a um servidor. A partir dessas medicoes utilizou-se de ferramentas de
Big Data para armazenamento, processamento e analise. O armazenamento esta sendo
realizada com uso de um banco de dados (NoSQL) IoT Server, e o processamento e
analise com o uso da Linguagem R. Ou seja, o processamento e feito de forma distribuıda
atraves da construcao de scripts em linguagem R e a visualizacao com o uso de uma
biblioteca, tambem em R, chamada Shiny. O uso de uma mesma linguagem permitiu
a facil integracao entre analise e visualizacao dos dados. Para o caso da visualizacao, a
biblioteca permite a construcao de uma aplicacao Web que facilita o acesso aos dados e,
consequentemente, as analises.
Embora neste momento do projeto e no escopo dessa pesquisa nao esteja a analise
profunda dos resultados, ja se pode perceber que os valores de CO na regiao metropolitana
de Sao Paulo ultrapassa a media estabelecida pela Organizacao Mundial de Saude (OMS)
que estabelece no maximo de 10 ppm. Na Regiao Metropolitana de Sao Paulo em que os
sensores foram colocados as medidas variam entre 30 e 40 ppm CO. Ou seja, em media tres
ate quatro vezes o recomendado pela OMS. Assim, os resultados provisoriamente obtidos
neste trabalho permitem as autoridades governamentais ter controle sobre esse indicador
de poluicao e, com isso, motiva-los a espalhar novos sensores por outras regioes da cidade.
71
5.1 Trabalhos Futuros
Como trabalhos futuros sugere-se o desenvolvimento e experimentacao da plataforma
aqui proposta com aplicacoes do mundo real com dados em tempo real. Cabe destacar
o uso da plataforma aqui descrita em um contexto real com redes de telecomunicacoes
reais e com uma escala de clientes e aplicacoes de modo a verificar o comportamento
da plataforma e do Iot Server e Apache Hadoop com um grande numero de instancias
integradas com clusters para processamento distribuıdo em Big Data.
Atestar a aplicabilidade das implementacoes algorıtmicas em diversos contextos de
IoT, de modo a elucidar se os algoritmos aqui utilizados conseguem modelar as inumeras
aplicacoes existentes nos diversos outros contextos.
Sugere-se explorar a modularidade da plataforma de IoT aqui descrita, de modo a
experimentar outras plataformas para Big Data, explorar a funcionalidade de notacoes
semanticas existentes no Iot Server e propor o uso do servico de clustering para a mode-
lagem automatica dessas notacoes semanticas.
Analisar a aplicabilidade dos servicos de reconhecimento de padroes para a seguranca
no contexto de IoT e integrar ao modulo de seguranca do IoT Server, seja no contexto de
seguranca da informacao e servicos ou a seguranca patrimonial e pessoal ou no ambito de
cidades inteligentes, de modo que as aplicacoes possam conhecer os contextos e compor-
tamentos pessoais e infiram ataques ou mudancas bruscas de comportamento individual
ou em massa.
Projeto de extensao de IoT para a cidade, destacam-se a preparacao de alguns outros
sensores e a tentativa de coloca-los nas cinco zonas da cidade (Norte, Sul, Leste, Oeste e
Centro). Melhorar a interface para permitir ao usuario que faca escolha da granularidade
no tempo de analise, ou seja, hora, dia, mes ou ano. Por fim, como mais importante, com
todos os dados coletados e armazenados, promover analises mais profundas que tentam
encontrar os causadores dos ındices de CO medidos na cidade. Apos esta etapa, verificar
e validar a escalabilidade linear oferecida pelo Hadoop.
Implementar sistemas cognitivos com inteligencia artificial usando tecnicas machine
learning, com IoT integrando solucoes de voz para tornar sensores inteligentes.
72
REFERENCIAS
ACHARJYA, D.; AHMED, K. P. A survey on big data analytics: Challenges, open
research issues and tools. INTERNATIONAL JOURNAL OF ADVANCED COMPUTER
SCIENCE AND APPLICATIONS, Citeseer, v. 7, n. 2, p. 511–518, 2016.
APACHE. Apache Drill. 2017. Disponıvel em: <https://drill.apache.org>. Acesso em:
2017-03-12.
APACHE. Apache Hadoop. 2017. Disponıvel em: <https://hadoop.apache.org>. Acesso
em: 2017-03-12.
APACHE. Mahout 0.12.0 Features by Engine. 2017. Disponıvel em: <https://mahout-
.apache.org/users/basics/algorithms.html>. Acesso em: 2017-03-12.
ARDUINO, S. Access the Online IDE. 2017. Disponıvel em: <https://www.arduino.cc-
/en/Main/Software>. Acesso em: 2017-04-10.
BHATT, A.; PATOLIYA, J. Cost effective digitization of home appliances for home
automation with low-power wifi devices. In: 2016 2nd International Conference on
Advances in Electrical, Electronics, Information, Communication and Bio-Informatics
(AEEICB). [S.l.: s.n.], 2016. p. 643–648.
BR-ARDUINO.ORG. Servidor web WiFi com Arduino e ESP8266. 2017. Disponıvel em:
<http://br-arduino.org/2015/07/arduino-servidor-web-wifi-esp8266.html>. Acesso em:
2017-04-10.
CARDENAS-BENITEZ, N. et al. Traffic congestion detection system through connected
vehicles and big data. Sensors, Multidisciplinary Digital Publishing Institute, v. 16, n. 5,
p. 599, 2016.
CASAGRAS. Casagras final report: rfid and the inclusive model for the internet of
things. [S.l.]: John Murray, 2009.
CEARLEY, D.; CLAUNCH, C. The top 10 strategic technology trends for 2013. The
Top, v. 10, 2012.
73
CETESB. Companhia Ambiental do Estado de SA£o Paulo Cetesb. 2017. Disponıvel
em: <http://www.cetesb.sp.gov.br/>.
CETESB. Qualidade do Ar. 2017. Online. Disponıvel em: <http://ar.cetesb.sp.gov.br-
/padroes-de-qualidade-do-ar/>. Acesso em: 2017-03-10.
CHEN, C. P.; ZHANG, C.-Y. Data-intensive applications, challenges, techniques and
technologies: A survey on big data. Information Sciences, v. 275, p. 314 – 347, 2014.
ISSN 0020-0255. Disponıvel em: <http://www.sciencedirect.com/science/article/pii-
/S0020025514000346>.
CHEN, C. P.; ZHANG, C.-Y. Data-intensive applications, challenges, techniques and
technologies: A survey on big data. Information Sciences, Elsevier, v. 275, p. 314–347,
2014.
CHENG, B. et al. Building a big data platform for smart cities: Experience and lessons
from santander. In: IEEE. Big Data (BigData Congress), 2015 IEEE International
Congress on. [S.l.], 2015. p. 592–599.
CHITTURI, B.; THOMAS, J.; S., I. T. New approaches for discovering unsupervised
human activities by mining sensor data. In: 2015 International Conference on Computing
and Network Communications (CoCoNet). [S.l.: s.n.], 2015. p. 118–123.
COMPUTERWORLD. 2012. Online. Disponıvel em: <http://www.computerworld.com-
/article/2493701/data-center/by-2020–there-will-be-5-200-gb-of-data-for-every-person-
on-earth.html>. Acesso em: 2017-03-12.
COULOURIS, G. et al. Sistemas Distribuıdos-: Conceitos e Projeto. [S.l.]: Bookman
Editora, 2013.
DATA, B.; COGNITIVE, A. B. the Foundation for. 2017. Online. Disponıvel em:
<http://www.idc.com/promo/thirdplatform/fourpillars/bigdataanalytics>. Acesso em:
2017-03-12.
DEAN, J.; GHEMAWAT, S. Mapreduce: simplified data processing on large clusters.
Communications of the ACM, ACM, v. 51, n. 1, p. 107–113, 2008.
74
DEMCHENKO, Y.; LAAT, C. D.; MEMBREY, P. Defining architecture components of
the big data ecosystem. In: IEEE. Collaboration Technologies and Systems (CTS), 2014
International Conference on. [S.l.], 2014. p. 104–112.
DENATRAN. Denatran gov DENATRAN. 2017. Disponıvel em: <http://www.denatran-
.gov.br/index.php/estatistica/261-frota-2016>.
FAN, W.; BIFET, A. Mining big data: current status, and forecast to the future. ACM
sIGKDD Explorations Newsletter, ACM, v. 14, n. 2, p. 1–5, 2013.
FANG, H. et al. A survey of big data research. IEEE Network, v. 29, n. 5, p. 6–9,
September 2015. ISSN 0890-8044.
FERNANDEZ, R. C. et al. Liquid: Unifying nearline and offline big data integration. In:
CIDR. [S.l.: s.n.], 2015.
FORGEAT, J. Data processing architectures - Lambda and Kappa. 2015. 2015. Online.
Disponıvel em: <https://www.ericsson.com/research-blog/data-knowledge/data-
processing-architectures-lambda-and-kappa/>. Acesso em: 2017-03-06.
GALLIDABINO, A. et al. On the architecture of liquid software: Technology alternatives
and design space. In: 2016 13th Working IEEE/IFIP Conference on Software
Architecture (WICSA). [S.l.: s.n.], 2016. p. 122–127.
GANZ, F. et al. A practical evaluation of information processing and abstraction
techniques for the internet of things. IEEE Internet of Things Journal, v. 2, n. 4, p.
340–354, Aug 2015. ISSN 2327-4662.
GAO, J.; LEI, L.; YU, S. Big data sensing and service: A tutorial. In: Big Data
Computing Service and Applications (BigDataService), 2015 IEEE First International
Conference on. [S.l.: s.n.], 2015. p. 79–88.
GOLDSCHMIDT, R.; PASSOS, E. Data Mining. [S.l.]: Elsevier Brasil, 2015.
HAJOUI, O. et al. A comparative analysis of different approaches for big data
interoperability. In: 2016 Third International Conference on Systems of Collaboration
(SysCo). [S.l.: s.n.], 2016. p. 1–4.
75
HAND, D. J.; MANNILA, H.; SMYTH, P. Principles of data mining. [S.l.]: MIT press,
2001.
IEEE Guide for Developing User Organization Open System Environment (OSE)
Profiles. IEEE Std 1003.23-1998, p. i–, 1999.
IEEE Standard for Information Technology–System and Software Life Cycle Processes–
Reuse Processes. IEEE Std 1517-2010 (Revision of IEEE Std 1517-1999), p. 1–51, Aug
2010.
ISO, I. Iec 12207 systems and software engineering-software life cycle processes.
International Organization for Standardization, Geneva, Switzerland, 2008.
ISO, I. Iec 42010:2011 systems and software engineering- architecture description.
International Organization for Standardization, 2011.
ITU. the Internet of Things. 2005 ITU. 2005. Disponıvel em: <http://www.itu.int/osg-
/spu/publications/internetofthings/>.
ITU. Internet of Things 2009 ITU. 2009. Disponıvel em: <http://www.itu.int/osg/spu-
/publications/>.
JAIN, A. K.; , M. N. ; FLYNN, P. J. Data clustering: a review. ACM computing surveys
(CSUR), Acm, v. 31, n. 3, p. 264–323, 1999.
JASPERSOFT. Business Intelligence Software Editions. 2017. Disponıvel em:
<http://www.jaspersoft.com/editions>. Acesso em: 2017-03-12.
JIN, J. et al. An information framework for creating a smart city through internet
of things. IEEE Internet of Things Journal, v. 1, n. 2, p. 112–121, April 2014. ISSN
2327-4662.
KAMBATLA, K. et al. Trends in big data analytics. Journal of Parallel and Distributed
Computing, Elsevier, v. 74, n. 7, p. 2561–2573, 2014.
KANTARDZIC, M. Data mining: concepts, models, methods, and algorithms. [S.l.]:
John Wiley & Sons, 2011.
76
KELAIDONIS, D. et al. Virtualization and cognitive management of real world objects
in the internet of things. In: 2012 IEEE International Conference on Green Computing
and Communications. [S.l.: s.n.], 2012. p. 187–194.
KOLLIA, I.; SIOLAS, G. Using the ibm watson cognitive system in educational contexts.
In: 2016 IEEE Symposium Series on Computational Intelligence (SSCI). [S.l.: s.n.],
2016. p. 1–8.
LEACH, P. J. et al. Hypertext Transfer Protocol–HTTP/1.1. [S.l.]: Draft Standard, 1999.
MADDEN, S. From databases to big data. IEEE Internet Computing, IEEE Educational
Activities Department, Piscataway, NJ, USA, v. 16, n. 3, p. 4–6, maio 2012. ISSN
1089-7801. Disponıvel em: <http://dx.doi.org/10.1109/MIC.2012.50>.
MASSE, M. REST API Design Rulebook: Designing Consistent RESTful Web Service
Interfaces. [S.l.]: ”O’Reilly Media, Inc.”, 2011.
MATTERN F.; ZURICH, E. Ubiquitous computing: scenarios for an informatized
world,communication and the media economy of the future. [S.l.]: Springer-Verlag, 2005.
MAYER-SCHONB V. CUKIER, K. Big Data: A Revolution That Will Transform How
We Live, Work, and Think. 2014. ed. [S.l.]. [S.l.]: Mariner Books, 2014.
MENDES, R. d. v. Aplicacao da arquitetura lambda na construcao de um ambiente big
data educacional para analise de dados. Dissertacao Mestrado em Engenharia Eletrica e
Computacao. Universidade Presbiteriana Mackenzie, Sao Paulo. [S.l.]: -, 2017.
MICROSOFT. Microsoft Research. 2016. Disponıvel em: <http://research.microsoft-
.com/en-us/projects/dryad>. Acesso em: 2017-03-12.
NASIR, M. A. U. Fault tolerance for stream processing engines. arXiv preprint
arXiv:1605.00928, 2016.
NATHAN N.; WARREN, J. Big Data: Principles and best practices of scalable realtime
data systems. 1. ed. [S.l.]. [S.l.]: Manning Publications, 2015.
OMS. WHO Air quality guidelines for particulate matter, ozone, nitrogen dioxide and
sulfur dioxide. 2017. Online. Disponıvel em: <http://www.who.int/phe/health topics-
/outdoorair/outdoorair aqg/en/>. Acesso em: 2017-03-10.
77
ORGANIZATION, W. H. Air quality guidelines: global update 2005: particulate matter,
ozone, nitrogen dioxide, and sulfur dioxide. [S.l.]: World Health Organization, 2006.
PATEL, T.; UDAYAKUMAR, P.; VYAS, R. Analyzing data mining techniques for
wireless sensor network protocols. In: 2015 2nd International Conference on Computing
for Sustainable Global Development (INDIACom). [S.l.: s.n.], 2015. p. 1673–1678.
PENTAHO. Data Sources for Business Analytics. 2017. Disponıvel em: <http://www-
.pentaho.com/data-sources-for-business-analytics>. Acesso em: 2017-03-12.
PORTAL. Portal do Meio Ambiente Cetesb. 2017. Disponıvel em: <http://portal.rebia-
.org.br/cidadania/2095-emissao-dos-escapamentos-dos-veiculos>.
PROVOST, F.; FAWCETT, T. Data Science for Business: What you need to know about
data mining and data-analytic thinking. [S.l.]: ”O’Reilly Media, Inc.”, 2013.
RICHERT, W. Building machine learning systems with python. [S.l.]: Packt Publishing
Ltd, 2013.
RSTUDIO, S. by. Gallery. 2017. Disponıvel em: <https://shiny.rstudio.com/gallery/>.
Acesso em: 2017-04-10.
SAVAGLIO, C.; FORTINO, G.; ZHOU, M. Towards interoperable, cognitive and
autonomic iot systems: An agent-based approach. In: 2016 IEEE 3rd World Forum on
Internet of Things (WF-IoT). [S.l.: s.n.], 2016. p. 58–63.
SHVACHKO, K. et al. The hadoop distributed file system. In: IEEE. Mass storage
systems and technologies (MSST), 2010 IEEE 26th symposium on. [S.l.], 2010. p. 1–10.
SILVA, L. A. da; PERES, S. M.; BOSCARIOLI, C. Introducao a Mineracao de Dados
Com aplicacoes em R. first. [S.l.]: Elsevier Editora Ltda, 2016.
SINGH, D.; REDDY, C. K. A survey on platforms for big data analytics. Journal of Big
Data, Springer, v. 2, n. 1, p. 8, 2015.
SKARMETA, A. Ieee aina 2013 keynote talk ii: The impact of internet of things
in big data approach and future internet. In: Advanced Information Networking and
Applications (AINA), 2013 IEEE 27th International Conference on. [S.l.: s.n.], 2013. p.
xlvii–xlvii. ISSN 1550-445X.
78
SOUZA, A. M. C.; AMAZONAS, J. R. A. A novel smart home application using
an internet of things middleware. In: Smart Objects, Systems and Technologies
(SmartSysTech), Proceedings of 2013 European Conference on. [S.l.: s.n.], 2013. p. 1–7.
SPLUNK. Splunk: Machine Data. 2017. Disponıvel em: <https://www.splunk.com-
/en us/resources/machine-data.html>. Acesso em: 2017-03-12.
SQLSTREAM. SQLStream - What is Machine Data ? 2017. Disponıvel em:
<http://www.sqlstream.com/products/what-is-machine-data>. Acesso em: 2017-03-12.
STANDARD, E.-. T. J. D. I. IntroduA§A£o ao JSON. 2017. Disponıvel em:
<http://www.json.org/json-pt.html>. Acesso em: 2017-04-10.
THAKER, T. Esp8266 based implementation of wireless sensor network with linux based
web-server. In: 2016 Symposium on Colossal Data Analysis and Networking (CDAN).
[S.l.: s.n.], 2016. p. 1–5.
TIGANI, J.; NAIDU, S. Google BigQuery Analytics. [S.l.]: John Wiley & Sons, 2014.
VENNER, J. Pro hadoop. [S.l.]: Apress, 2009.
WHITE, T. Hadoop: The Definitive Guide. 4. ed. [S.l]. [S.l.]: Hadoop, 2015.
WINGERATH, W. et al. Real-time stream processing for big data. it-Information
Technology, v. 58, n. 4, p. 186–194, 2016.
WU, Q. et al. Cognitive internet of things: A new paradigm beyond connection. IEEE
Internet of Things Journal, v. 1, n. 2, p. 129–143, April 2014. ISSN 2327-4662.
79
6 ARTIGO PUBLICADO
80
An Architecture for the Internet of Things and theUse of Big Data Techniques in the Analysis of
Carbon Monoxide
Marco Aurelio Borges, Gabriel Melo F. Correia, Massaki de O. Igarashi, Paulo Batista Lopes, Leandro A. SilvaUniversidade Presbiteriana Mackenzie
Sao Paulo, Sao Paulo, BrasilEmail: [email protected], [email protected], massaki.igarashi,paulo.lopes,[email protected]
Abstract—The use of sensors for the monitoring of a givenenvironment allied with the Internet as a means of commu-nication is popularly known as Internet of Things (IoT). Theamount of information generated in this environment has led toan unprecedented increase in data collection. One of the majorchallenges for its development lies in the storage and the process-ing of this huge volume of data into acceptable measurementsand analysis parameters. This research takes up this challengeby storing and compiling data from different sensors, and bycarrying out an exploratory analysis of the information gathered.In this research, sensors that collect data from a specific SaoPaulo’s Metropolitan Area (SMA) have been analysed. Thesesensors are capable of measuring carbon monoxide (CO) levels.This research aims to analyse the main architectures for bothbatch and stream sensor processing and to use one of themfor the construction of a Big Data environment. Big Datatools were used for IoT storage, processing and visualizationdata. During the experiments, carbon monoxide sensors (MQ7),were analysed. They were connected through a microcontrollerunit that supports the Transmission Control Protocol/InternetProtocol (TCP/IP). This project highlights the necessary tools toexecute and analyse the data in a dynamic manner. The datacollected by the sensors show that the avarage levels of carbonmonoxide are well above the international standards set by theWorld Health Organization (WHO).
Keywords—Internet of Things; Sensor Data Mining; HadoopArchitecture; Smart Cities.
I. INTRODUCTION
Atmospheric pollution is resultant of a sum of geographicand climatic factors; the harmful effects are noticed by thepeople through illnesses. The gas inhalation, in a chronicroutine (for an extended time) and in harmful dosage, mightstimulate respiratory diseases, from inflammations (chronictracheitis and bronchitis) to pulmonary emphysema as well aschemical and infectious bronchopneumonia. Once launched tothe atmosphere, the nitrogen oxide (NO2) keeps the abilityof transforming into a secondary composite. Due to thechemical oxidation lights there is a transformation into ozone(O3), which is considered the most hazardous photochemicaloxidant. Its toxic action occurs mainly due to the ability ofoxidating proteins, lipids and other substances that integratecells, damaging or even killing them depending on the con-centrations and exposure duration. Thus, the photochemicaloxidants increase the irritant action from other pollutants,
intensifying respiratory system’s inflammations and infections[1], [2].
The most evident way of worsening air pollution in hugeurban centres, Sao Paulo’s metropolitan area for example, isthe debris production from diesel combustion which movestrucks and bus fleets; and the debris are launched into the airpeople breath. The black smoke that is released from vehiclesmoved by diesel exhaust is originated by the mixture of gasesand particles of pollutants that are harmful to human health[1].
The World Health Organization establishes that a city mayonly consider a clean air if it presents the mean equal to 10micrograms of parts per million (ppm) in the maximum. Anyamount over this index represents risks to human health. Theair pollution index in Sao Paulo is more than twice the limitestablished by WHO. The current measurement is equal to 19micrograms of ppm. The Sao Paulo capital’s fleet has over 7million vehicles, the last official data from the department isthe balance from December 2016, when the city’s fleet was7.98 million vehicles [3].
The air quality monitoring has been considered of highimportance level for politics definition about reducing at-mospheric pollution. It is through the monitoring networkthat is possible to determine the rate evolution for pollutantsconcentrations, such as carbon monoxide.
In the current context, Internet of Things emerges, theconcept is based on the creation of infrastructure for intercon-nected sensors in order to monitor, analyse and virtually actabout the real world. The definition of Internet of Things, wasinitially proposed by Auto-ID centre of Massachusetts Instituteof Technology (MIT) [4] and reported on the research writtenby the International Telecommunication Union (ITU) [5], [6].
Some devices such as sensors, managers, cameras andmicrophones, conected home appliances or augmented realitydevices, which can be categorized by the term Internet ofThings, generate not treatable data by systems developed toprocess structured data. Data with characteristiscs like these,large (volume), fast (speed) and difficult to be treated by thecurrent systems (variety) define the term Big Data [7].
With the maturation of this technology towards the improve-ment of the sensors, the data collection and their empirical
2017 IEEE International Conference on Information Reuse and Integration
978-0-7695-6243-8/17 $31.00 © 2017 IEEE
DOI 10.1109/IRI.2017.76
184
storage with analytical capacity caused a great interest aboutthis technology in several knowledge areas. The most signif-icant and impressive interest has been called Smart Citieswhich purpose is to obtain an intelligent environment toprovide people with comfort, convenience, safety and smarterenvironments [8].
The Hadoop Distributed File System (HDFS) project iscurrently one of the best-known tools and solutions for BigData. Its purpose is to offer an infrastructure for storage andprocessing of large data volume, providing linear scability andfault tolerance. According to [9], in April 2008 the Hadoopbroke the world record and became the fastest system toordinate 1 terabyte, using 910 machines this mark was reachedin 209 seconds. In 2009, this amount was reduced to 62seconds.
In [10] by presenting some essencial principles for the BigData analytics system design, mention that many architecturesare proposed for parallel processing, both for batch process-ing and stream processing. However, the architectures varyaccording to the type of problem to be solved.
Through the Big Data tools it was possible to collect, store,analyze and present the results obtained from carbon monoxideindex, and use them to indicate the risk to people exposed atthe receiving sites, such as schools, hospitals, neighborhoodswith high incidence of respiratory diseases, valleys, placesaround transportation corridors, regions with low ventilationetc. Another advantage of these tools was the possibility ofanalyzing, through variations in the emission rates, what wouldbe the future impacts of air pollution prevention policies [2].
The implementation of applications for Sensor Data Mining(SDM) and Data Analytics (DA) involves the definition ofthe solution architecture, the definition of the computationalsolutions of hardware and software, the selection of languagesand algorithms for data mining [11].
One of the reasons to justify is the concept of intelligentcities, where some sensors (MQ7) were made available inmodule ESP8266 12F with a built-in WiFi card, which werespread across in the Metropolitan Region of Sao Paulo andanalyze these data in batch (batch processing) or stream(continuous flow processing).
In addition to the above, aiming to provide the services ca-pable of processing and analyzing the massive volume of datagenerated by the communication between the various devices,using open interfaces that allow simple integration betweenseveral applications, the handling of the data obtained fromvarious sensors or measuring stations of carbon monoxidewere performed in the tools available in Big Data throughsensors and IoT modules.
On IoT environment, there are various challenges that havenot been overcome yet, such as the necessity of data interoper-ability, the diversification of information that is transmitted andreceived, safety and privacy on contextualized information andservices acting on the environment accesses [12]. About thestorage aspect, the most appropriate solution is the utilizationof Big Data technologies, which assist the storage and offerresources for data processing and visualization.
A literature research about applications involving Internetof Things and Big Data revealed a deficiency of objectiveorientations related to the systems’ architecture definitionand application, to the tools choices and to presentationdecisions, cloud, hosting or even about their structure [13],[14], [15]. The gap found became the research motivation,which proposes the enforcement on Big Data architecturefor Internet of Things, involving the real time collectionprocess, distributed storage manner, analytic data processingand analyses visualization [16]. As a specific objective, thearchitecture validation through the CO monitoring in someareas inside Sao Paulo’s Metropolitan Area is proposed.
II. PROPOSED ARCHITECTURE
This research is characterised as exploratory in terms of itsobjective and applied in terms of its nature, once studyingBig Data tools, requirements and processing architectures issuggested and also combining them into an IoT sensors’ dataprocessing application and analysis.
About the procedure, the research is characterised as biblio-graphic, once the theoretical referencing conducted to the topicunderstanding and to the methodological procedure definition.
The proposed research’s method is structured over thefollowing steps, illustrated in Figure 1:
• Measure: IoT ESP8266 sensors for collection of carbonmonoxide data are disposed in different regions of SaoPaulo’s metropolitan area.
• Collect: This step consists in obtaining IoT ESP8266sensors’ data.
• Storage: In this step, the storage was executed in aNoSQL (Not Only Structured Query Language) database,part of the obtainment process, which sends Hadoop andHDFS architecture, applying the MapReduce function.
• Analysis: Exploratory analysis on how the distributedprocessing is.
• Present: This methodology phase, implements the datavisualization.
A. Description of Architecture Implementation Project
The ESP8266 sensors were installed in a Sao Paulo’smetropolitan area (SMA) environment with the objective ofcollecting data on carbon monoxide.
The ESP8266 sensor with Arduino module captures carbonmonoxide data, transmits through WiFi, access the collectorserver to storage using an API (Application ProgrammingInterface), allowing the simple integration of different typesof sensors that would store the collected data in a NoSQLdatabase as shown in Figure 1. The data may be accessed viaAPI for analysis and processing.
B. Sensors’ Configuration
The programming language applied was R, with R Studioframework, used to develop statistic and data analysis soft-ware, data miners collection, which has made it possible tocompile the data of the sensors [11].
185
Figure 1. Proposed architecture applied to this study.
The IoT sensors’ topology capture measures on carbonmonoxide sent data, which were spread around the SMA. Thepower consumption of each sensor is approximately 560 mw.
The ESP8266 sensor is similar to an Arduino; it has theadvantage of communicating through a wireless network,because of the TCP/IP protocol. The single disadvantage isthat is only possible to read an analogical sensor, because itthere is just one analogical access, which requires a multi-plexing or a serial communication with another plaque withmore analogical accesses and that captures information fromdifferent sensors [17].
The sensor’s module communicates with a micro controller,using a serial interface. There are two GPIO (General PurposeInput Output) pins, or access (entrance/exit) for general pur-poses, allowing a direct module programming and the GPIOto be added without a micro controller.
The ESP8266 wireless module’s [18] characteristics are:• Connexion to standardised 802.11 B/G/N networks;• Approximate coverage: 91 metres;• Operation tension: 3.3 Vdc;• Serial communication: TX and RX pins;• Operation modes: Client, Access Point, Client + Access
Point;• Withstand TCP and UDP communication.The signal level used by the module was equal to 3.3V.
Thus, RX (serial reception) pin was not directly connectedto the Arduino. An external power source was used for themodule due to the possible dependence on a 300 mA current,and the Arduino’s limit is equal to 50 mA.
The data record on memory is represented in Figure 2according to the Arduino’s sketch. The representation showsa sensor, known as IoTm001, which requests an IoT Serverauthentication to begin the data record.
Figure 3 illustrates a layout referent to the IoT circuitsthat were used on this research. In this layout there is a 5Vpower source, LM317 integrated circuit, a positive tensionregulator for currents of 1 Ampere maximum with a maximumdissipation equal to 2 Watts, so the exit tension was equalto 3Vcc. All the other electronic components, such as: theESP8266 module and the MQ7 sensors to measure carbonmonoxide gas are represented in the circuit layout. The layouthas also a red plate (ESP8266-12E) with ESP8266 on it, lowcost, WiFi transmission, and connexion: 802.11 b/g/n, has all
Figure 2. Sensor programming sketch.
the components integrated to the plate (even the antenna),and extremely low power consumption. This plate (ESP8266-12E) assists on the Arduino’s sketch programming interface,utilizing a USB (Universal Serial Bus) micro controller. Toestablish the sensors’ connection and record were used ajunction plate from the Arduino module with physical Tx-Rxand GND connections from each of the sensors to close thecircuit jumper.
The configuration enables each sensor to read the CO andsend the data through the network every 300,000 (millisec-onds) or 5 minutes.
Figure 3. IoT sensors’ layout.
C. Data Storage and Analysis
The data transmission to the storage on server was accordingto the Hypertext Transfer Protocol (HTTP). The collected data
186
are sent to the server using an API, with this the serverkeeps the data json (java script object notation) format, seean example of this structure in Figure 4.
Figure 4. json stored data exhibited on the browser.
Therefore, the sensors transmit the data to the server bystream. The data batch requisition with their values is doneby the same API through R Studio.
R Studio is an environment of free development and inte-grated to the R programming language. Through R Studio,it was possible to use the command lines and to directthe collected data from the ESP8266 sensors to the ApacheHadoop and HDFS tools, using MapReduce, which processedand analysed the data.
The data visualization was done using Shiny, a frameworkthat applies web, using R language, which allows presentingconfigurative values to the user in dialog boxes.
D. Server IoT
The data obtained from the carbon monoxide sensors werestored in json format, which has allowed compiling andinputing them directly to the IoT Server (NoSQL), representedin the Figure 5 [19].
The url http://201.6.243.44:3000/dump has represented thedump data collection of sensors in json format, as shown inFigure 4 and in the server architecture of Figure 1.
Processing(CPU)
MemoryRAM
Storage at Disk Operating Sys-tem
2 quad-corede 2 a 2,25GHz
4 GB 1 disco SATA de500 GIGABYTE
Ubuntu server16.04.2 LTS
Table IIOT SERVER CLUSTER SETTINGS
Table I presents the IoT Server NoSQL configuration data,regarding the CPU, Memory, Disk Space and Operating Sys-tem.
According to Figure 5, batch or stream processing of thislarge data volume, which a map function has processed a key,value pair generating as product intermidiate sets of key,value pairs, and also defines a reduce function, responsable
Figure 5. Dashboard data of the IoT server.
for joining all the intermidiate values associated with a singlesensor key.
The IoT server’s dashboard visualizes at each instant of300,000 ms (milliseconds) the input with the IoTm001,IoTm002, IoTm003, or IoTm004 sensors randomly.
III. EXPERIMENTAL RESULTS
The Figures 6 and 7 show the results of carbon monoxideindexes incidence along an analysis period for two differentregions in Sao Paulo.
Sensor’s 2 referent data, shown in Figure 6, allow veri-fying the hours with higher carbon monoxide incidence andconcentration, with an approximate measurement of 30 to 35micrograms of carbon. The sensor’s 4 data, presented in Figure7, on the other hand, showed for the same hours a higherconcentration of this harmful gas, from 45 to 55 microgramsof particles.
For comparative effects, Figure 8 shows the data from bothsensors, where it is possible to clearly notice the differencebetween the measurements at the same hours, suggesting thatfor the sensor’s 4 region the carbon monoxide pollution ishigher.
Although a deep results analysis is not a part of thestudy scope, it is interesting to highlight that by these valuesis possible to see that they are extremely over the valuesproposed by the World Health Organisation that establishes amaximum of 10 micrograms of ppm. The results were between30 and 55 of ppm.
Figure 6. Sensor’s 2 collected data.
187
Figure 7. Sensor’s 4 collected data.
Figure 8. Sensors’ 2 and 4 collected data.
Based on the stored data, some other analytical approachesmay be held. The following results will show the constructionof an analyses panel (dashboards) allowing a better explorationof the results and assists a possible manager on the analysisand definition of public policies for reducing air pollution.
The dashboards are built, as previously explained, usingan R language library, called Shiny. This library allows theconstruction of a web based application, in which the data arepresented on a web interface and the analyses are done accord-ing to programming scripts developed in R [20]. Differentlyfrom other languages and programming libraries, in which theanalyses are kept and the results must be temporally saved andonly then another visualization tool is used, the big motivationand advantage of Shiny is the maintenance of the integrationbetween these two components in the same application.
The interface, as it is possible to observe in Figure 9,allows real-time analyses of sensors with analytic explorationsas mean, density, quartiles, box plot and histogram. Someother measures might be incorporated to this interface, as wellas many other sensors. Especially in this figure, the meanvalue is presented. As the data are being collected every 5minutes, and the data exhibition is every hour (x-axis), then thecarbon monoxide presented data (y-axis) are the mean for themeasurements every hour. The interface might have anothercomponent, allowing, in the future, choosing the time intervalto calculate the mean, in other words, day, month and evenyear.
Figure 9. Mean values per day for sensor’s 2 data measurements.
For a density analysis example, sensor 2 will be usedagain for reference. The density analysis illustrated in Figure10 shows a non-linear distribution for the carbon monoxideindexes. This means that there is a concentration between 20and 25 micrograms of carbon monoxide in a 0.03 densityvariation, however in other period of the day, it is shown anaccumulation of 30 to 35 micrograms of carbon monoxideparticles in a higher density variation, close to 0.10.
Figure 10. Sensors’ density.
For a better understanding about the measurements, animportant analysis is the calculation of summary values. Theanalysis in Figure 11 presents measurements such as mean,median, quartile and even the minimum, maximum and miss-ing values. It is also possible to determine a time interval topresent the analysis.
Figure 11. Sensor’s 2 collected summary measurements.
The summary measurements might be also presented usingBox plot, which graphically consolidates the measurements inobtained minimum, mean, median and maximum values forcarbon monoxide. Figure 12 illustrates the result of this plotfor sensor’s 2 measurements as a histogram.
It is important to reinforce that the values presented previ-ously, although in an illustrative level, are real measurements
188
Figure 12. Sensor’s 2 histogram.
and were analysed considering full execution of the architec-ture implemented in this study. In this moment, the project isstill running, and it is not possible to carry further analysis onthe results, since they are still being collected. Therefore, itis maintained the project proposed scope and implementationof the architecture that is capable of collecting data fromCO sensors; and the data storage an analysis using Big Dataconcepts.
A. HDFS and MapReduce Results
Table II shows the commands, some libraries, vectors andfunctions used to implement the HDFS and to apply theMapReduce, until the recovery of the data entered in from.dfscontrol [21].
The IoT Server sensors are represented by the variablesx1, x2, x3 e x4 (sensors: IoTm001, IoTm002, IoTm003 eIoTm004), the range regarding the sensors was establishedas follows: x1: 0 to 500, x2: 500 to 1000, x3: 1000 to 1500and x4: 1500 to 2000, concerning the positions of the carbonmonoxide reading, in the sequence in which the data werecapturated, this variation could have another defined range,such as from 0 to 1000, from 2000 to 10,000, or from the firstto the last data collection. This selection criterion was random,as regards the carbon monoxide reading, this measurement canbe performed at any time, as long as the sensors are sendingthe signal via WiFi to the IoT Server.
After the programming performed in the Table II, the Figure13 presents a summary of the results obtained from theHadoop, the management panel and some applications, howthe distributed processing is, cluster metrics, virtual colors, fullcolors, reserved, and active nodes. In this case, there is onlyone configured machine, the Cloudera manager, and it canbe expanded to a larger cluster of machines. Increasing thenumber of machines and consequently the amount of data, theactive nodes will change from 1 to 50 or even how much thestorage capacity can endure. The total memory can increasefrom 8 GB to 50 GB or over.
Still in the Figure 13 each time that the MapReduce isexecuted, it organizes the information, where the stream andjobs are structured for an easy understanding such as: filessubmitted, pending files on hold and executed files, appssubmitted, apps pending, apps running; each time you run theMapReduce function.
library(jsonlite) library(curl) library(rmr2)url = url(’http://201.6.243.44:3000/dump’)
x=fromJSON(txt=url)x1= x[[1]][c(0:500),]
x2= x[[2]][c(500:1000),]x3= x[[3]][c(1000:1500),]x4= x[[4]][c(1500:2000),]
simu1 = to.dfs(x1)simu2 = to.dfs(x2)simu3 = to.dfs(x3)simu4 = to.dfs(x4)
mapper= function(k,v)date = as.numeric(v$date)
data = rbind(as.numeric(v$data))return(keyval(1,data))reduce =function(k, v)
total = (mean(v)) return(keyval(1,sum))calc1 = mapreduce( input=simu1, map= mapper, reduce = reduce )calc2 = mapreduce( input=simu2, map= mapper, reduce = reduce )calc3 = mapreduce( input=simu3, map= mapper, reduce = reduce )calc4 = mapreduce( input=simu4, map= mapper, reduce = reduce )
viewer1 =from.dfs(simu1) #output as a dataframe viewer1viewer2 =from.dfs(simu2) #output as a dataframe viewer2viewer3 =from.dfs(simu3) #output as a dataframe viewer3viewer4 =from.dfs(simu4) #output as a dataframe viewer4
Table IIHDFS AND MAPREDUCE.
Figure 13. HDFS managed applications.
The expected results are recorded in an output file withsome of the main routines performed referring to Figure 13such as:
• ID - displays the addressing of each IoT sensor routine,the position 0001 of sensor 1, successively up to position0004 of sensor 4.
• User - the name established as the user of a VM Cloudera.• Name - regarding the job stream executed by the MapRe-
duce function.• States e Final Status - consider the jobs executed and the
status, whether or not they were successful, and what theerror would be if it happened.
The Figure 14 complements the Figure 13 with the HadoopUser Experience (HUE).
This dashboard displays the processing in each step of theHadoop and the MapReduce application. The highlights are:the analysis status with the parameters: successful, running,failed, or deleted. The processing of each IoT sensor, thesensor 1 lasted 1.16 min in relation to the sensor 4, which
189
Figure 14. HUE execution.
was executed in 43 seconds, a performance 15% higher ofsensor 4 comparing to sensor 1, however, sensors 3 and 4were very close regarding their processing time.
The Figure 15 illustrates the stream job of sensor 4, whichhas achieved the shortest processing time compared to theothers, as follows:
• Attempts: shows the number of processing executionattempts, along with the 1500755734357000101000001.
• Tasks: in the functions map, task and reduce twologs tasks are generated: 15007557343570001m000000and 15007557343570001m000001 and one reduce:15007557343570001r000000, being m= map and r= re-duce of the executed logs.
• Metadata: presents: the id, user, the number of MapRe-duce executions, the time of the performance cycle, thedfs function, the sensors’ threshold, the latency, the time-out of 300,000 ms (dfs.client.mmap.retry.timeout.ms),basically it’s presenting the result with a summary of theHDFS routines.
• Counter: the general consolidations of maps and reduces,how many files were written and read in bytes, and thetotal sum of both.
• MR2: It’s a distributed app that runs MapReduce on topof the YARN (Yet Another Resource Negociator).
Figure 15. Logs and id job.
Although it presents similarities with existing distributedfile systems, the HDFS distinguishes itself because of its highfault tolerance, low latency and low hardware costs, as wellas the execution of MapReduce jobs, which perform reading,processing and writing of extremely large files as can be seenin Figure 15.
IV. CONCLUSIONS AND FUTURE WORK
The current research proposed is to analyse and implementarchitectures for the Internet of Things, using Big Data tools.The purpose of developing a network architecture of sensors,
spread across Sao Paulo’s metropolitan area, via WiFi, and itsvalidation as obtained in this study. This allowing thoughts ona broader city monitoring of carbon monoxide measurements,which data may be analysed and used to support pollutionreduction policies and campaigns. Therefore, it is possible toconclude that the desired objective of this study was achieved.
One of the relevant factors to achieve the research objectiveswas the IoT sensors use, with the ESP8266 module, that isable to collect information and send the data through WiFinetworks and Internet to a server. From these measurements,Big Data tools were used to store, process and analyse thedata. The processing and analysis used R language. In otherwords, the processing is done in a distributed manner throughthe scripts construction in R language and visualization usinga library, also in R, called Shiny. The usage of the samelanguage allowed an easier integration between data analysisand visualization. For the visualization, the library allows usto build a Web application that facilitates the data access and,consequently, the analyses.
It is already possible to notice that the carbon monoxidevalues in SMA exceed the mean values established by theWHO of a maximum equals to 10 micrograms of ppm. In theregions where the sensors were spread out, the measurementsoscillated between 30 and 40 micrograms of CO. This meansthat on average, it’s twice the recommended values. Thus,the results obtained in this study so far allow governmentalauthorities to have better control over this pollution indicatorand be motivated to disperse new sensors in other regionsacross the city.
For further studies, the development of other types ofsensors and the attempt to distribute them across any countrymight be highlighted. A better interface might also be a futuredevelopment, allowing the user to choose a granularity atthe analysis time, hour, month or year. Finally, as the mostimportant prospect, with all the collected and stored data, topromote deeper analysis with the attempt of finding the majorcontributors to these carbon monoxide indexes measured incities.
V. ACKNOWLEDGMENTS
To Instituto Presbiteriano Mackenzie for partially financingthis project with scholarships, MackPesquisa and CAPES.To BigMAAp, Electric and Electronic Engineering and JAS3laboratories at Universidade Presbiteriana Mackenzie.
REFERENCES
[1] Portal do Meio Ambiente Cetesb. 2017. Available: http://portal.rebia-.org.br/cidadania/2095-emissao-dos-escapamentos-dos-veiculos.
[2] CETESB. Companhia Ambiental do Estado de Sao Paulo Cetesb. 2017.Available: http://www.cetesb.sp.gov.br/.
[3] Denatran gov DENATRAN. 2017. Available :http://www.denatran-.gov.br/index.php/estatistica/261-frota-2016.
[4] MATTERN F.; ZURICH, E. Ubiquitous computing: scenarios for aninformatized world,communication and the media economy of the future.[S.l.]: Springer-Verlag, 2005.
[5] The Internet of Things. 2005 ITU. 2005. Available: http://www.itu.int/osg-/spu/publications/internetofthings/.
[6] Internet of Things 2009 ITU. 2009. Available: http://www.itu.int/osg/spu-/publications/.
190
[7] MADDEN, S. From databases to big data. IEEE Internet Com-puting, IEEE Educational Activities Department, Piscataway, NJ,USA, v. 16, n. 3, p. 4-6, maio 2012. ISSN 1089-7801. Available:¡http://dx.doi.org/10.1109/MIC.2012.50.
[8] JIN, J. et al. An information framework for creating a smart city throughinternet of things. IEEE Internet of Things Journal, v. 1, n. 2, p. 112-121,April 2014. ISSN 2327-4662.
[9] WHITE, T. Hadoop: The Defnitive Guide. 4. ed. [S.l]. [S.l.]: Hadoop,2015.
[10] CHEN, C. P.; ZHANG, C.-Y. Data-intensive applications, chal-lenges, techniques and technologies: A survey on big data. Informa-tion Sciences, v. 275, p. 314-347, 2014. ISSN 0020-0255. Available:http://www.sciencedirect.com/science/article/pii-/S0020025514000346.
[11] SILVA, L. A. da; PERES, S. M.; BOSCARIOLI, C. Introducao aMineracao de Dados com aplicacoes em R. First. [S.l.]: Elsevier EditoraLtda, 2016.
[12] GAO, J.; LEI, L.; YU, S. Big data sensing and service: A tutorial. In:Big Data Computing Service and Applications (BigDataService), 2015IEEE First International Conference on. [S.l.: s.n.], 2015. p. 79-88.
[13] CASAGRAS. Casagras final report: rfid and the inclusive model for theinternet of things,John Murray, 2009.
[14] THAKER, T. Esp8266 based implementation of wireless sensor networkwith linux based web-server. In: 2016 Symposium on Colossal DataAnalysis and Networking (CDAN). [S.l.: s.n.], 2016. p. 1-5.
[15] MAYER-SCHONB V. CUKIER, K. Big Data: A Revolution That WillTransform How We Live, Work, and Think. 2014. ed. [S.l.]. [S.l.]: MarinerBooks, 2014.
[16] TIGANI, J.; NAIDU, S. Google Big Query Analytics. [S.l. John Wileyand Sons, 2014.
[17] SCHWARTZ, M. Internet of Things with ESP8266. [S.l.]: Packt Pub-lishing Ltd, 2016.
[18] BR-ARDUINO.ORG. Servidor web WiFi com Arduino e ESP8266.Available: http://br-arduino.org/2015/07/arduino-servidor-web-wifi-esp8266.html.
[19] STANDARD, E.-. T. J. D. I. Introduction to JSON. 2017. Available:http://www.json.org/json-pt.html.
[20] RSTUDIO,S. by. Gallery. 2017. Available:https://shiny.rstudio.com/gallery/.
[21] SHVACHKO, K. et al. The hadoop distributed file system. In: IEEE.Mass storage systems and technologies (MSST), 2010 IEEE 26th sym-posium on. [S.l.], 2010. p. 1-10.
191
