Uma Arquitetura para Orquestração Da Distribuição de Água No Semiárido Brasileiro Baseada em Internet Das Coisas e Computação em Nuvem

Wilson Alves da Silva
Uma Arquitetura para Orquestrao da

Distribuio de gua no Semirido Brasileiro
Baseada em Internet das Coisas e Computao
em Nuvem
Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br
http://cin.ufpe.br/~posgraduacao
RECIFE
2017
Wilson Alves da Silva
Uma Arquitetura para Orquestrao da Distribuio de

gua no Semirido Brasileiro Baseada em Internet das
Coisas e Computao em Nuvem
Trabalho apresentado ao Programa de Ps-

graduao em Cincia da Computao do
Centro de Informtica da Universidade Fe-
deral de Pernambuco como requisito parcial
para obteno do grau de Mestre em Cincia
da Computao.
Universidade Federal de Pernambuco
Orientador: Vincius Cardoso Garcia
RECIFE
2017
FICHA
Dissertao de Mestrado apresentada por Wilson Alves da Silva Ps-Graduao em
Cincia da Computao do Centro de Informtica da Universidade Federal de Pernam-
buco, sob o ttulo Uma Arquitetura para Orquestrao da Distribuio de gua
no Semirido Brasileiro Baseada em Internet das Coisas e Computao em
Nuvem Orientador: Vincius Cardoso Garcia e aprovada pela Banca Examinadora
formada pelos professores:
Prof. Dr. Kiev Santos da Gama

Centro de Informtica / UFPE
Prof. Dr. Nelio Alessandro Azevedo Cacho

Departamento de Informtica / UFRN
Prof. Dr. Orientador: Vincius Cardoso Garcia

Centro de Informtica / UFPE
Visto e permitida a impresso.

Recife, 29 de Agosto de 2017.
Prof. Aluizio Fausto Ribeiro Arajo

Coordenador da Ps-Graduao em Cincia da Computao do
Centro de Informtica da Universidade Federal de Pernambuco.
minha famlia, em especial minha esposa por sempre me proporcionar totais
condies para a realizao dos meus estudos, apoiar-me e incentivar-me. Aos meus
irmos. Dedico.
Agradecimentos
Primeiramente, agradeo a Deus por tudo que tem providenciado em minha vida, e por
ter dado-me fora e determinao para concluir este trabalho.
A minha esposa, Luciana Ramos, que tolerou pacientemente minha ausncia nos l-
timos dois anos, que estive dedicado a essa Ps-Graduao. Agradeo pelo amor, pela
compreenso, pelo respeito, enfim por ser a pessoa que me completa.
Ao meu orientador, professor Dr. Vincius Cardoso Garcia, pelo empenho e boa vontade
em me orientar no que fosse preciso para a concluso dessa dissertao de mestrado. Que
me apoiou, sempre mostrando as melhores solues, com sua experincia e conhecimento.
Aos demais docentes do programa de Ps-Graduao do Centro de Informtica da
UFPE pela competncia com que transmitiram os contedos e ensinamentos.
Agradeo a todos os amigos do Centro de Informtica, que por muitas vezes ajudaram-
me durante todo o mestrado, pois sem as trocas de ideias esta pesquisa no seria possvel.
Agradeo tambm, aos meus amigos do Exrcito Brasileiro, com os quais tenho ou
tive a honra de servir. A vocs meu muito obrigado por toda a colaborao e auxlio neste
projeto.
A todos, os meus mais sinceros agradecimentos.

A verdadeira motivao vem de
realizao, desenvolvimento pessoal,
satisfao no trabalho e reconhecimento.
(Frederick Herzberg)
Resumo
Na regio Semirida brasileira o regime de chuvas caracterizado por perodos longos
de estiagem com secas prolongadas, fazendo com que no ano de 2016 fossem gastos mais
de um bilho de Reais em programas de distribuio de gua populao carente dessa
regio, dos quais cerca de 14% desse recurso foi gasto em fiscalizao. A forma de fiscali-
zao atual no contempla nenhuma maneira de mensurar a quantidade ou a qualidade
da gua recebida e vrias notcias de fraudes publicadas pela mdia em geral indicam que
essa fiscalizao um processo caro e propcio a erro. O problema ento como melhorar
o monitoramento e fiscalizao na distribuio de gua, ampliando a transparncia e a
eficincia de programas federais de distribuio deste recurso. Sistemas de Internet das
Coisas (IoT), so capazes de transmitir informaes sobre volume e qualidade da gua,
estas informaes podem ser usadas de forma integrada com os sistemas de tomada de
deciso para fins de gesto. No entanto, as limitaes dos dispositivos IoT requerem uma
tecnologia como Computao em Nuvem para complementar suas aplicaes, dado que a
Computao em Nuvem possui capacidades praticamente ilimitadas em termos de arma-
zenamento e processamento. Motivado pela importncia do programa de distribuio de
gua para o Semirido brasileiro e pela necessidade de definio de um framework para
permitir a integrao de solues parciais para fiscalizao destes tipos de programas,
este trabalho apresenta uma arquitetura baseada em IoT e Computao em Nuvem que
disponibiliza servios para orquestrar a distribuio de gua no Semirido brasileiro. Para
atingir os objetivos deste trabalho foi realizado um mapeamento das principais tecnolo-
gias empregadas em Sistemas de Gerenciamento de Recursos Hdricos que utilizam IoT e
foi realizada uma anlise do emprego da Tecnologia da Informao como instrumento de
apoio fiscalizao do programa de distribuio de gua. Apoiado nestes conhecimentos
foi especificada, projetada e implementada uma arquitetura de referncia. Por fim, a par-
tir de uma avaliao pde-se mensurar o quo a Arquitetura Proposta est apta para ser
implantada em um contexto real.
Palavras-chaves: Internet das Coisas, Computao em Nuvem, Engenharia de Software

Baseada em Evidncia, Segurana, Arquitetura de Software, Distribuio de gua, Seca.
Abstract
In Brazilian semi-arid region, rainfall is characterized by long periods of drought, which
only in 2016 caused the expenditure of more than one billion reais (Brazilian currency,
about USD 330 millions) in water distribution programs for the poor population of this
region, of which about 14% were spent on surveillance. The current form of surveillance
does not contemplate any way of measuring the quantity or quality of water received, and
various fraud reports published by the local media outlets show that such surveillance
is an expensive and error-prone process. So the problem is how to improve the mon-
itoring and control of water distribution, increasing the transparency and efficiency of
the water distribution programs. Internet of Things (IoT) Systems are capable of trans-
mitting information about water volume and quality, this information can be used by
the decision-making systems for management purposes. However, the limitations of IoT
devices require a technology like Cloud Computing to complement their applications,
because Cloud Computing has virtually unlimited capabilities in terms of storage and
processing power. Motivated by the importance of the water distribution program for the
Brazilian semi-arid region and by the need to define a framework to allow the integra-
tion of partial solutions for monitoring these types of programs, this masters dissertation
presents an IoT and Cloud Computing-based architecture that provides Web services to
orchestrate the distribution of water in the Brazilian semi-arid region. In order to reach
the objectives of this work, a mapping of the main technologies used in Water Resources
Management Systems that apply IoT approach was carried out and also was realized anal-
yses of the use of Information Technology as an instrument to support the surveillance
of Brazilian water distribution program. From this knowledge was specified, designed
and implemented a reference architecture. Finally, from an evaluation, it was possible to
measure how able is the Proposed Architecture to be implemented in a real context.
Key-words: Internet of Things, Cloud Computing, Evidence-Based Software Engineer-

ing, Security, Software Architecture, Water Distribution, Drought.
Lista de Figuras
Figura 1 Elementos da Internet das Coisas . . . . . . . . . . . . . . . . . . . . . 21

Figura 2 Carto e leitor de carto usados no processo de distribuio de gua . . 35
Figura 3 Processo de distribuio de gua . . . . . . . . . . . . . . . . . . . . . 36
Figura 4 Etapas do Mapeamento Sistemtico da Literatura . . . . . . . . . . . . 39
Figura 5 MSL - Processo de refinamento da busca . . . . . . . . . . . . . . . . . 39
Figura 6 MSL - Resumo do protocolo . . . . . . . . . . . . . . . . . . . . . . . . 41
Figura 7 MSL - Artigos selecionados . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 8 MSL - Artigos por ano de publicao . . . . . . . . . . . . . . . . . . . 42
Figura 9 MSL - Artigos por Pas de publicao . . . . . . . . . . . . . . . . . . . 43
Figura 10 MSL - Artigos por Camadas de IoT . . . . . . . . . . . . . . . . . . . . 44
Figura 11 MSL - Comunicao Interna e Externa . . . . . . . . . . . . . . . . . . 44
Figura 12 MSL - Comunicao Interna por Artigos . . . . . . . . . . . . . . . . . 45
Figura 13 MSL - Comunicao Externa . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 14 MSL - Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 15 MSL - Tcnicas de medio de volume de gua . . . . . . . . . . . . . 47
Figura 16 MSL - Controladores usados em IoT . . . . . . . . . . . . . . . . . . . 47
Figura 17 MSL - Formas de energia usadas em SGRH . . . . . . . . . . . . . . . 48
Figura 18 MSL - Uso de Computao em Nuvem . . . . . . . . . . . . . . . . . . 49
Figura 19 MSL - Caractersticas Arduino e Raspberry Pi . . . . . . . . . . . . . . 52
Figura 20 Sntese do Mapeamento Sistemtico da Literatura . . . . . . . . . . . . 54
Figura 21 Modelo da arquitetura IoT . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 22 Unidades de um N IoT . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 23 Principais Plataformas IoT . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 24 Guideline para seleo da Plataforma IoT . . . . . . . . . . . . . . . . 66
Figura 25 Arquitetura IoT empregada . . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 26 Divises fsicas e lgicas da Arquitetura de Software . . . . . . . . . . . 69
Figura 27 Atividades realizadas pela Arquitetura Proposta . . . . . . . . . . . . . 70
Figura 28 Viso Lgica da AS proposta . . . . . . . . . . . . . . . . . . . . . . . 71
Figura 29 Diagrama de sequncia da atividade de Gerar Token de Entrega . . . . 72
Figura 30 Diagrama de sequncia da atividade Realizar Entrega . . . . . . . . . . 73
Figura 31 Diagrama de sequncia mdulo N . . . . . . . . . . . . . . . . . . . . 74
Figura 32 Diagrama de classes resumido Camada de Negcio AS . . . . . . . . . 75
Figura 33 Diagrama de Classe do Mediador de Dados . . . . . . . . . . . . . . . . 81
Figura 34 Resultado da avaliao dos cenrios . . . . . . . . . . . . . . . . . . . . 94
Figura 35 Avaliao das Tecnologias de Comunicao para SGRH . . . . . . . . . 115
Lista de Tabelas
Tabela 1 Padres Arquiteturais. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Tabela 2 Resultado da avaliao dos protocolos de comunicao . . . . . . . . . 61
Tabela 3 Trabalhos secundrios sobre Plataformas IoT . . . . . . . . . . . . . . 65
Tabela 4 Servios desejveis em uma Plataforma de IoT . . . . . . . . . . . . . . 65
Tabela 5 Caractersticas desejveis em uma Plataforma de IoT . . . . . . . . . . 66
Tabela 6 Mapeamento dos componentes da AS em processos e threads . . . . . . 76
Tabela 7 Viso Fisica da AS - Gateway . . . . . . . . . . . . . . . . . . . . . . . 80
Tabela 8 Viso Fisica da AS - N . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Tabela 9 Viso Fisica da AS - Plataforma IoT . . . . . . . . . . . . . . . . . . . 81
Tabela 10 Mapeamento de Requisitos X Mdulos . . . . . . . . . . . . . . . . . . 84
Tabela 11 Caractersticas dos mtodos SAAM e ATAM . . . . . . . . . . . . . . . 87
Tabela 12 Etapas do mtodo de avaliao . . . . . . . . . . . . . . . . . . . . . . 88
Tabela 13 Expertise da Equipe de Avaliao . . . . . . . . . . . . . . . . . . . . . 89
Tabela 14 Execuo da avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Tabela 15 Atributos de Qualidade ordenados por prioridade . . . . . . . . . . . . 91
Tabela 16 Cenrios propostos para avaliao da AS . . . . . . . . . . . . . . . . . 93
Tabela 17 MSL - Artigos selecionados . . . . . . . . . . . . . . . . . . . . . . . . 114
Lista de Abreviaturas e Siglas
AS Arquitetura de Software.
BLE Bluetooth Low Energy.
EB Exrcito Brasileiro.
ESBE Engenharia de Software Baseada em Evidncias.
GCDA Sistema de Gesto e Controle de Distribuio de gua.
IoT Internet das Coisas.
LAN Rede de rea Local.
MEM Mdulo Embarcado de Monitoramento.
MSL Mapeamento Sistemtico da Literatura.
OCP Operao Carro-Pipa.
OME Organizaes Militares Executoras.
PA Padro Arquitetural.
PAbst Ponto de Abastecimento.
PMES Primeiro Mandamento da Engenharia de Software.
QA Atributos de Qualidade.
SGRH Sistemas de Gerenciamento de Recursos Hdricos.
TI Tecnologia da Informao.
WAN Rede de Longa Distncia.
Wi-Fi Wireless Fidelity.
WSN Rede de Sensores Sem Fio.

Sumrio
1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1 Motivao e Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Hiptese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.1 Objetivos Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.2 Objetivos Especficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5 Escopo Negativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.6 Organizao da Dissertao . . . . . . . . . . . . . . . . . . . . . . . . 20
2 REFERENCIAL TERICO . . . . . . . . . . . . . . . . . . . . . . . 21
2.1 Internet das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.1 Elementos da Internet das Coisas . . . . . . . . . . . . . . . . . . . . . . 21
2.1.2 Modelos de Arquitetura IoT . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.3 Aplicabilidade de IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Computao em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1 Caractersticas Essenciais . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.2 Modelos de Servio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.3 Formas de Distribuio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Integrao Computao em Nuvem e Internet das Coisas . . . . . . 25
2.4 Engenharia de Software Baseada em Evidncia . . . . . . . . . . . . 27
2.5 Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.1 Padres Arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5.1.1 Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5.1.2 Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6 Assinatura Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6.1 Aspectos Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6.2 Algoritmos de Chave Pblica - RSA e ECC . . . . . . . . . . . . . . . . . 30
2.7 Consideraes Finais do Captulo . . . . . . . . . . . . . . . . . . . . 31
3 REVISO DA LITERATURA . . . . . . . . . . . . . . . . . . . . . . 32
3.1 Anlise do Modelo de Distribuio de gua no Semirido Brasileiro 32
3.1.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.2 Sistemas de Informao na Distribuio de gua . . . . . . . . . . . . . . 33
3.1.2.1 GCDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.2.2 GPIPABRASIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.3 Processo de Distribuio de gua . . . . . . . . . . . . . . . . . . . . . . 34
3.1.4 Problemas no Mtodo Atual de Distribuio de gua . . . . . . . . . . . . 36
3.1.5 Resumo da Seo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Mapeamento das Tecnologias de IoT para SGRH . . . . . . . . . . . 37
3.2.1 Perguntas de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Metodologia da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.2.1 Etapas do Mapeamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.2.2 Execuo da Busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.2.3 Critrios de Seleo dos Estudos . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.3 Sntese e Anlise dos Dados . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.3.1 Extrao e Anlise dos Dados . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.3.2 Respostas das Questes de Pesquisa . . . . . . . . . . . . . . . . . . . . . . 43
3.2.3.3 Discusso dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.3.4 Sntese do Mapeamento Sistemtico da Literatura . . . . . . . . . . . . . . . 53
3.2.4 Resumo da Seo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4 ARQUITETURA PROPOSTA . . . . . . . . . . . . . . . . . . . . . 55
4.1 Requisitos para Arquitetura Proposta . . . . . . . . . . . . . . . . . . 55
4.1.1 Resumo da Seo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 Especificao da Arquitetura IoT . . . . . . . . . . . . . . . . . . . . 57
4.2.1 Definio do Modelo de Arquitetura IoT Empregado . . . . . . . . . . . . 57
4.2.2 Camada de Percepo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.2.1 Unidade de Medio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.2.2 Unidade de Processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.2.3 Unidade de Alimentao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.2.4 Unidade de Comunicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.3 Camada de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.3.1 Gateway Mvel para IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.3.2 Definio da Camada de Rede da Arquitetura Proposta . . . . . . . . . . . . . 63
4.2.4 Camada de Processamento . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.4.1 Plataformas de Mediao de Dados de IoT . . . . . . . . . . . . . . . . . . . 63
4.2.4.2 Reviso da Literatura de Plataformas de Mediao de Dados para IoT . . . . . 64
4.2.4.3 Guideline para Seleo da Plataforma IoT . . . . . . . . . . . . . . . . . . . 66
4.2.5 Resumo da Seo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3 Especificao da Arquitetura de Software . . . . . . . . . . . . . . . . 68
4.3.1 Arquitetura de Software Proposta . . . . . . . . . . . . . . . . . . . . . . 70
4.3.1.1 Viso Lgica da Arquitetura de Software . . . . . . . . . . . . . . . . . . . . 70
4.3.1.2 Viso de Execuo da Arquitetura de Software . . . . . . . . . . . . . . . . . 76
4.3.1.3 Viso de Caso de Uso da Arquitetura de Software .
. . . . . . . . . . . . . . 77
4.3.2 Implementao de Referncia . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.3.2.1 Plataforma IoT - FIWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.3.2.2 Viso Fsica da Arquitetura de Software . . . . . .
. . . . . . . . . . . . . . 79
4.3.2.3 Viso de Implementao da Arquitetura de Software . . . . . . . . . . . . . . 79
4.3.3 Validao da Arquitetura de Software . . . . . . . . . . . . . . . . . . . . 82
4.3.3.1 PMES versus Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . 83
4.3.3.2 Requisitos Elicitados versus Mdulos da Arquitetura de Software . . . . . . . . 84
4.3.4 Resumo da Seo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5 AVALIAO DA ARQUITETURA PROPOSTA . . . . . . . . . . . 85

5.1 Mtodos de Avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.1.1 SAAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.1.2 ATAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2 Protocolo da Avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2.1 Definio do Mtodo de Avaliao . . . . . . . . . . . . . . . . . . . . . . 87
5.2.2 Equipe de Avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3 Execuo da Avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3.1 Primeira Reunio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3.2 Segunda Reunio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3.3 Terceira Reunio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.4 Resultados da Avaliao da Arquitetura . . . . . . . . . . . . . . . . . 93
5.4.1 Resultados da Avaliao dos Cenrios . . . . . . . . . . . . . . . . . . . . 94
5.4.2 Resultados Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.5 Ameaas Validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.5.1 Alto Desvio Padro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.5.2 Relacionamento Interpessoal . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.5.3 Possvel Avaliao de uma Implementao Especfica . . . . . . . . . . . . 97
6 CONSIDERAES FINAIS . . . . . . . . . . . . . . . . . . . . . . . 99
6.1 Viso Geral da Soluo Proposta . . . . . . . . . . . . . . . . . . . . 99
6.2 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.3 Contribuies da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.4 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.5 Possibilidade de Utilizao da Arquitetura em Outros Domnios . . 103
6.6 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
REFERNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
APNDICES 112
APNDICE A ARTIGOS SELECIONADOS MSL . . . . . . . . . 113
APNDICE B TABELA DE AVALIAO DAS TECNOLOGIAS

DE COMUNICAO PARA SGRH . . . . . . . . 115
APNDICE C DESCRIO DOS SERVIOS E CARACTERS-

TICAS DESEJVEIS EM UMA PLATAFORMA
DE IOT . . . . . . . . . . . . . . . . . . . . . . . . 116
16
1 Introduo
Este captulo apresenta a motivao e a justificativa para realizao deste trabalho, bem
como o problema e a definio da hiptese de pesquisa. A partir disto so apresenta-
dos os objetivos, geral e especficos desta pesquisa, a organizao de todo o trabalho
apresentada no final deste captulo.
1.1 Motivao e Justificativa

Hoje em dia, um dos maiores desafios a ser resolvido o de gerir a escassez de gua. A
Organizao Mundial de Sade reporta que 750 milhes de pessoas em todo o mundo no
tm acesso gua potvel, o que cerca de um nono da populao mundial (JMP, 2016).
O Semirido brasileiro, formado pela regio Nordeste do Brasil, norte de Minas Gerais
e norte do Esprito Santo, abrange uma rea de 1.663.200 km2 e conhecida como Polgono
da Seca. Nessa regio o regime de chuvas caracterizado por perodos longos de estiagem
com secas prolongadas, sendo a pluviosidade irregular e diferenciada (PADILHA et al., 2004).
A gua do subsolo quase sempre salobra, a grande maioria do solo no oferece condies
para a perfurao de poos profundos e existem poucos rios nesta regio (PADILHA et
al., 2004). Nessas circunstncias, torna-se imprescindvel a busca de solues alternativas
para o problema da seca no Semirido brasileiro.
Assim, com o objetivo de levar gua potvel s reas atingidas pela seca nesta regio,
no ano de 2000 foi criado pelo Governo Federal o Programa Emergencial de Distribuio
de gua. A Operao Carro-Pipa (OCP) uma das aes deste programa e tem por
objetivo a distribuio de gua potvel s populaes atingidas pela seca no Semirido
brasileiro. Segundo dados obtidos do sistema que gerencia esse programa, no ano de
2016, esta operao atendeu a 789 municpios por ms, trabalhando com 6.502 Pipeiros,
os quais entregaram 219.658 carradas em 65.310 pontos de abastecimento, distribundo
2.087.045m3 de gua e atendendo a uma populao de 3.440.558 por ms, sendo gastos
nesse ano R$ 1.021.682.120,57 (GCDA, 2017).
A fiscalizao da distribuio de gua populao carente desta regio realizada
pelo Exrcito Brasileiro (EB). Apenas com essa fiscalizao so gastos anualmente cerca
de 14% de todo o recurso financeiro destinado operao (SIAFI, 2017). A fiscalizao do
servio realizada de duas maneiras: a primeira fisicamente com equipes de fiscalizao
que constantemente esto nas localidades assistidas; e a segunda por meio de um sistema
de rastreamento que permite o acompanhamento da captao e entrega da gua. Porm,
a forma de fiscalizao atual no contempla nenhuma maneira de mensurar a quantidade
ou a qualidade da gua recebida, o que torna essa fiscalizao um processo caro e propcio
a erro ou muitas vezes fraude. Um indicativo disto que diversos veculos de comunicao
Captulo 1. Introduo 17
tm reportado constantes fraudes na OCP. Apenas para ilustrar, cita-se abaixo algumas
matrias veiculadas:
Em dezembro de 2013 uma equipe de reportagem de uma importante rede de televi-

so brasileira durante dois meses percorreu a regio Nordeste para investigar como
a operao funciona1 . Eles reportaram que: "vtimas da seca recebem gua conta-
minada em caminhes-pipa" e que "encontraram tanques imundos" e "entregas que
no chegam nunca".
Em fevereiro de 2017 a Polcia Rodoviria Federal prendeu duas pessoas por fraudar
a OCP no Cear2 . A dupla fazia percursos simulados com os aparelhos de GPS em
um carro. Dessa forma, eles receberiam pelo servio e pela quilometragem rodada,
mas sem gastar leo diesel de seus caminhes e, efetivamente, sem realizar o servio
de coleta e entrega de gua de forma correta.
Em janeiro de 2017 um motorista de um caminho-pipa foi flagrado pela Polcia

Militar do Cear despejando cerca de nove mil litros de gua potvel em um crrego,
no municpio de Maracana, Regio Metropolitana de Fortaleza3 . O trabalho dele
seria transportar a gua que seria distribuda gratuitamente. Porm, ao invs disso,
derramava os milhares de litros e recebia como se tivesse entregue.
Em maio de 2017 foi noticiado que a Policia Civil de Tau, juntamente com o
Exrcito, investiga mais uma suspeita de fraude na OCP4 . Segundo os agentes, a
informao que receberam que sempre no final da tarde alguns veculos chegam ao
local e derramam gua potvel pertencente a OCP. Provavelmente recebendo como
se as tivesse entregue.
Motivado por esses fatos e dada a importncia do programa de distribuio de gua

para o Semirido brasileiro, fica evidente a necessidade de serem empregados meios au-
tomatizados para realizar a fiscalizao e o monitoramento da distribuio de gua nesta
regio.
Os sistemas de IoT so capazes de transmitir informaes em tempo real sobre proces-
sos naturais, como nvel e grau de pureza de gua de rios e mananciais, estas informaes
podem ser usadas de forma integrada com os sistemas de tomada de deciso para fins de
gesto dos recursos naturais (MAIA et al., 2007). Porm, de maneira geral, os dispositivos
IoT possuem recurso limitados quanto a processamento e armazenamento (DASH et al.,
1
http://g1.globo.com/fantastico/noticia/2013/12/vitimas-da-seca-recebem-agua-contaminada-em-
caminhoes-pipa.html
2
http://g1.globo.com/ceara/noticia/2017/02/prf-prende-duas-pessoas-por-fraudar-operacao-carro-
pipa-no-ceara.html
3
http://g1.globo.com/ceara/noticia/2017/01/dupla-e-presa-despejando-nove-mil-litros-de-agua-de-
carro-pipa-no-ceara.html
4
http://blogdoamauryalencar.blogspot.com.br/2017/05/policia-investiga-caso-suspeito-de.html
2010). Assim, as limitaes dos dispositivos associados IoT, requerem uma tecnologia
como Computao em Nuvem para complementar este campo (DIAZ; CRISTIAN; RUBIO,
2016). Computao em Nuvem tem capacidades virtualmente ilimitadas em termos de
poder de armazenamento e processamento (BOTTA et al., 2014), que so os principais en-
traves da IoT. Portanto, atravs da Computao em Nuvem, a Internet das Coisas pode
ser abstrada de suas principais limitaes.
Embora os desafios enfrentados pela indstria de gua sejam globais e existam diversos
fornecedores e grandes empresas que participam ativamente na rea da gesto da gua,
as solues desses desafios so baseadas cada vez mais em solues locais fornecidas por
pequenas empresas (ROBLES et al., 2014). Neste contexto, urgentemente necessria a
definio de um framework para canalizar esses esforos, no s para reforar as sinergias
entre os diferentes players, mas tambm para permitir a integrao e adoo generalizada
de solues parciais.
1.2 Problema
Neste contexto, o problema como melhorar o monitoramento e fiscalizao na distribui-
o de gua com o mnimo de interveno humana, ampliando assim a transparncia e a
eficincia de programas de distribuio de gua.
Diante do problema apresentado, o presente trabalho prope desenvolver uma arqui-
tetura baseada em Internet das Coisas e Computao em Nuvem, utilizando a metodolo-
gia de Engenharia de Software Baseada em Evidncias, para auxiliar no monitoramento
e controle da distribuio de recursos hdricos, definindo, investigando e analisando as
principais tecnologias e prticas aplicadas no atual estado da arte para apresentar uma
Arquitetura de Software (AS) que disponibilize servios para orquestrar a distribuio de
gua no Semirido brasileiro.
1.3 Hiptese
Visto a evidente necessidade de serem empregados meios automatizados para realizar a
fiscalizao e o monitoramento da distribuio de gua no Semirido brasileiro e conside-
rando que:
i. a Internet das Coisas fornece meios para coletar informaes sobre fenmenos
naturais, como nvel e pureza de gua em rios e mananciais;
ii. a Computao em Nuvem tem capacidades virtualmente ilimitadas em termos
de armazenamento e processamento, principais limitaes da IoT;
iii. existe a necessidade da definio de um framework para permitir a integrao e
adoo generalizada de solues aos desafios enfrentados pela indstria de gua.
Diante disto, a hiptese que conduz este trabalho :

possvel especificar, projetar e implementar uma arquitetura baseada em Internet das
Coisas e Computao em Nuvem que disponibilize servios para orquestrar a distribuio
de gua no Semirido brasileiro.
1.4 Objetivos
Esta pesquisa visa propor uma arquitetura para auxiliar no monitoramento e controle da
distribuio de gua que:
proveja meios de fiscalizar a quantidade e a qualidade da gua entregue;
proveja mecanismos para que novos requisitos e novas aplicaes possam ser desen-
volvidos com base nos servios ofertados.
Diante disso, os objetivos desta pesquisa so divididos em geral e especficos, listados a
seguir:
1.4.1 Objetivos Geral

Este trabalho tem como objetivo geral especificar, projetar e implementar uma arquitetura
baseada em IoT e Computao em Nuvem que disponibilize servios para orquestrar a
distribuio de gua no Semirido brasileiro.
1.4.2 Objetivos Especficos

1. Realizar uma anlise do modelo de distribuio de gua no Semirido brasileiro e
da utilizao da Tecnologia da Informao (TI) como instrumento de melhoria dos
processos de fiscalizao da OCP;
2. Mapear as principais tecnologias e tcnicas empregadas em Sistemas de Gerencia-

mento de Recursos Hdricos (SGRH) que utilizam o paradigma de IoT;
3. Discutir um conjunto de requisitos fundamentais que devem ser atendidos na im-

plantao de uma arquitetura para SGRH;
4. Especificar uma arquitetura baseada em IoT e Computao em Nuvem para SGRH;
5. Projetar e implementar uma AS para um SGRH para orquestrar a distribuio de

gua no semirido brasileiro;
6. Avaliar a Arquitetura proposta.

1.5 Escopo Negativo

Como a soluo proposta por esta dissertao faz parte de um contexto amplo, um con-
junto de aspectos relacionados no sero tratados neste trabalho. Assim, os seguintes
aspectos no fazem parte do escopo deste trabalho:
Comunicao em tempo-real: Embora seja de suma importncia, a comunicao

em tempo-real com as cisternas dos beneficirios do programa com a finalidade de
verificar a quantidade de gua em tempo-real no ser contemplado neste trabalho.
Isso se d devido a grande dificuldade de comunicao entre as localidades onde se
encontram essas cisternas com a Internet.
Controle a fraudes especficas: Este trabalho uma contribuio para um melhor

controle e fiscalizao, no sendo pretenso prever todas as possveis fraudes a que
o programa de distribuio de gua est exposto.
Predio de necessidade de abastecimento de cisternas: Este projeto no prev meios

de predizer a real necessidade de cada cisterna, sendo esse servio sugerido como
um trabalho futuro.
1.6 Organizao da Dissertao

O restante desta dissertao est organizado conforme se segue:
Captulo 2: apresenta o referencial terico utilizado durante o desenvolvimento

desta pesquisa;
Captulo 3: apresenta uma reviso da literatura, onde realizada uma anlise do

emprego da TI na fiscalizao da OCP e so mapeadas as principais tecnologias e
tcnicas empregadas em SGRH;
Captulo 4: apresenta a Arquitetura Proposta, onde: define os requisitos para um

SGRH, especifica a arquitetura IoT empregada e descreve em detalhes a Arquitetura
de Software Proposta;
Captulo 5: discute o processo de avaliao da Arquitetura Proposta e apresenta

os principais resultados;
Captulo 6: conclui esta dissertao por meio de um resumo das principais contri-
buies desta pesquisa, apresentao dos principais trabalhos relacionados e discus-
ses a respeito de direes para pesquisas futuras.
21
2 Referencial Terico
Este captulo tem como objetivo explanar os conceitos e estudos utilizados como base
para a presente pesquisa. Na seo 2.1 so apresentadas as principais caractersticas da
Internet das Coisas. Na seo 2.2 so apresentados os conceitos bsicos de Computao em
Nuvem. A seo 2.3 apresenta o conceito de CloudIoT, que a integrao da Computao
em Nuvem com a Internet das Coisas. A seo 2.4 explana sobre a Engenharia de Software
Baseada em Evidncias (ESBE), usada para apoiar o mtodo de pesquisa adotado. Para
auxiliar no melhor entendimento deste trabalho, a seo 2.5 explana sobre Arquitetura
de Software. Por fim, na seo 2.6 explicado o que e como funcionam os mtodos de
assinatura digital.
2.1 Internet das Coisas

A Internet das Coisas ou IoT, acrnimo do ingls para Internet of Things, consiste em
dispositivos inteligentes onipresentes e objetos com sensores/atuadores embutidos (ASH-
TON, 2009). Segundo Ashton (2009), o termo "Internet das Coisas"foi mencionado pela
primeira vez em 1999, como ttulo de uma apresentao que ele fez na empresa Procter
& Gamble (P&G).
IoT tem como objetivo estender a Internet a bens onipresentes no mundo fsico, propor-
cionando um ambiente inteligente, ligando as coisas e pessoas, que logicamente composta
por trs partes: objetos inteligentes, interoperabilidade e aplicaes (ZHOU; ZHANG, 2014).
2.1.1 Elementos da Internet das Coisas

Seis tecnologias so amplamente utilizados para a implantao de produtos baseados IoT.
A Figura 1 mostra os elementos que compe a IoT segundo a viso de Al-Fuqaha et al.
(2015). A seguir so descritos cada um desses elementos.
Figura 1 Elementos da Internet das Coisas
Fonte: Al-Fuqaha et al. (2015)

Captulo 2. Referencial Terico 22
1. Identificao: Diversos mtodos de identificao esto disponveis para a IoT, como

cdigos de produtos eletrnicos (EPC) e cdigos ubquos (uCode). O endereamento
dos objetos IoT necessrio para diferenciar entre o ID do objeto e sua localizao.
2. Deteco/Sensoriamento: Significa reunir dados de objetos relacionados (coisas)
dentro de uma rede de sensores e envi-los para um banco de dados, Data Warehouse
ou nuvem.
3. Comunicao: As tecnologias de comunicao conectam objetos heterogneos entre
si, formando uma Rede de Sensores Sem Fio (WSN) e conecta esses a redes diversas,
Internet ou Intranet, para fornecer servios inteligentes especficos.
4. Computao: As unidades de processamento (por exemplo, microcontroladores,
microprocessadores) e aplicaes de software representam a capacidade computaci-
onal da IoT. Vrias plataformas foram desenvolvidas para executar aplicaes IoT.
5. Servios: Em geral os servios IoT podem ser classificados em quatro classes: ser-
vios relacionados identidade, servios de agregao de informaes, servios de
colaborao e servios ubquos.
6. Semntica: Na IoT refere-se capacidade de extrair conhecimento inteligente-
mente por diferentes mquinas para fornecer os servios necessrios. A extrao de
conhecimento inclui a descoberta, reconhecimento de padres e anlise de dados.
2.1.2 Modelos de Arquitetura IoT

Uma tentativa inicial para a coordenao dos esforos realizados por vrios projetos em
IoT foi realizada em 2010 no contexto dos eventos da Future Internet Architecture (FIA)1 .
Aproveitando as entradas de vrios projetos destes eventos, um modelo de arquitetura em
trs camadas para IoT foi descrito em Wu et al. (2010).
O modelo bsico da IoT consiste de fato na arquitetura de trs camadas: Camada
de Percepo, a Camada de Rede e Camada de Aplicao (KHAN et al., 2012; WU et
al., 2010). Devido ao rpido desenvolvimento da IoT, o modelo de arquitetura de trs
camadas no tem se mostrado suficiente para representar a complexidade dos sistemas
IoT atuais (MASHAL et al., 2015). Por conseguinte, uma arquitetura de cinco camadas tem
sido sugerida com a adio de duas novas camadas: Camada de Processamento e Camada
de Negcios. Esse modelo tem sido amplamente utilizado em diversos projetos de sistemas
IoT e o mais utilizado (MASHAL et al., 2015).
Assim, considerando o modelo de arquitetura em cinco camadas tem-se:
Camada de Percepo: representa os sensores e atuadores fsicos da IoT que visam
coletar e processar informaes. Esta camada inclui sensores para coletar localizao,
temperatura, peso, movimento, vibrao, acelerao, umidade e etc.
1
http://www.nets-fia.net/
Camada de Rede: transfere os dados produzidos pela camada de Percepo para a

camada superior. Os dados podem ser transferidos atravs de vrias tecnologias como
RFID, 3G, GSM, UMTS, Wi-Fi, Bluetooth Low Energy, infravermelho, Zigbee, etc.
Camada de Processamento: permite que programadores de aplicativos IoT traba-
lhem com objetos heterogneos sem considerar uma plataforma especfica. Essa ca-
mada processa dados recebidos, toma decises e fornece os servios necessrios.
Camada de Aplicao: fornece os servios solicitados pelos clientes. Por exemplo, a
camada de Aplicao pode fornecer medies de temperatura e umidade do ar ao
cliente que solicita esses dados.
Camada de Negcio: gere as atividades e servios globais do sistema IoT. As res-
ponsabilidades desta camada so a construo de um modelo de negcio, grficos,
fluxogramas, etc. com base nos dados recebidos da camada de Aplicao.
2.1.3 Aplicabilidade de IoT

Devido dupla capacidade de executar e detectar situaes (como, por exemplo, coletar
informaes sobre fenmenos naturais, parmetros mdicos, etc.), a IoT tem enormes
potencialidades para o desenvolvimento de novas aplicaes inteligentes em vrios campos
de atuao (BORGIA, 2014).
Borgia (2014) agrupa as aplicaes em trs grandes domnios: domnio industrial,
domnio de cidades inteligentes, e domnio da sade e bem-estar. A autora complementa
afirmando que cada domnio no isolado, mas so parcialmente sobrepostos, uma vez
que algumas aplicaes so compartilhadas.
Nem todas as aplicaes da Internet das Coisas tm atualmente o mesmo nvel de
maturidade. Muitas reas de atuao ainda esto em fase experimental e outras so mais
futuristas e ainda esto em um estgio inicial (BORGIA, 2014).
2.2 Computao em Nuvem

Existem diversas propostas de definio para o paradigma da computao em nuvem,
sendo a definio do National Institute of Standards and Technology (NIST) uma das
mais aceitas na comunidade: "Modelo que permite o acesso atravs de rede ubqua, de
acordo com a demanda, a um pool compartilhado de recursos computacionais que podem
ser rapidamente provisionados e liberados com um esforo mnimo de gerenciamento ou
interao com o provedor de servios" (MELL et al., 2011).
Nesse contexto, essa tecnologia emerge como uma opo capaz de reduzir custos atra-
vs de uma abordagem onde os recursos computacionais so pagos quando utilizados (RA-
MAKRISHMAN et al., 2010). Tal fato tem atrado os olhares de gigantes como a Amazon,
Google, Salesforce, Microsoft, IBM, HP, entre outros. Estas organizaes ofertam servios
como Amazon EC22 , Google App Engine3 , Salesforce4 , Windows Azure5 e Dropbox6 , que
oferecem solues com promessas de baixo custo, atravs das quais seus usurios podem
ter acesso aos servios de maneira ubqua.
2.2.1 Caractersticas Essenciais

As caractersticas essenciais representam as vantagens oferecidas pelas solues da com-
putao em nuvem e a destingue de outros paradigmas computacionais, suas principais
caractersticas so (MELL et al., 2011):
Alocao de recursos sob demanda: permite que o usurio possa dimensionar
a infraestrutura necessria sob demanda. Esta caracterstica permite que usurios
solicitem recursos em tempo de execuo medida que necessitam.
Amplo acesso rede: os recursos so disponbilizados atravs do ambiente de rede
e devem estar disponveis para acesso atravs de uma ampla gama de dispositivos
como tablets, PCs, smartphones, entre outros.
Pooling de Recursos: os recursos computacionais do provedor de servio so
estruturados para servir a mltiplos usurios utilizando um modelo multi-tennant,
que disponibiliza diferentes recursos fsicos e virtuais de maneira dinmica conforme
a necessidade do usurio. H um senso de independncia local, ou seja, o usurio
no precisa ter conhecimento da localizao fsica dos recursos computacionais.
Elasticidade rpida: caracterstica que permite que os recursos disponveis ao
usurio paream ilimitados, pois tais recursos podem ser adicionados e removidos
de maneira rpida e automtica, conforme a necessidade da carga de trabalho.
Servio medido: os recursos de um provedor so automaticamente controlados e
otimizados, atravs da capacidade de medio em um nvel de abstrao adequado
para o tipo de servio. A utilizao dos recursos pode ser controlada, monitorada e
relatada com transparncia entre o provedor e consumidor do servio.
2.2.2 Modelos de Servio

Os provedores da computao em nuvem oferecem seus servios de acordo com trs mo-
delos apresentados abaixo:
Infraestrutura Como Servio (IaaS): atravs deste modelo o provedor de servi-
os pode comercializar elementos de infraestrutura (cpu, memria, armazenamento,
etc) e a responsabilidade de corrigir, atualizar e manter o sistema operacional ou
qualquer outro software do cliente. Neste modelo o usurio no administra a in-
2
http://aws.amazon.com/pt/ec2/
3
https://appengine.google.com
4
http://www.salesforce.com/br/
5
http://www.windowsazure.com/pt-br/
6
http://www.dropbox.com/
fraestrutura fsica mas sim os sistemas operacionais, armazenamento, aplicativos e

componentes de rede.
Plataforma Como Servio (PaaS): neste modelo o provedor de servios fornece
sistemas operacionais, linguagens de programao e ambientes de desenvolvimento
de software. Neste modelo o usurio tem controle sobre configuraes e aplicaes
implantadas nesta infraestrutura.
Software Como Servio (SaaS): software de propsito especfico o produto
fornecido neste modelo de servio. Os sistemas so disponibilizados ao usurio por
meio de interfaces como um navegador de Internet. O usurio pode administrar e
controlar apenas configuraes especficas do prprio sistema.
2.2.3 Formas de Distribuio

Os ambientes de computao em nuvem podem ser distribudos de quatro formas diferen-
tes nos quesitos acesso e disponibilidade:
Nuvem Pblica: a infraestrutura da nuvem disponibilizada ao pblico geral,
acessvel a qualquer usurio que tenha conhecimento da localizao do servio.
Nuvem Privada: a infraestrutura de utilizao exclusiva de uma organizao,
sendo disponibilizada local ou remotamente, administrada pela prpria empresa ou
terceiros.
Nuvem Comunitria: a infraestrutura compartilhada por uma comunidade de
organizaes com interesses em comum.
Nuvem Hbrida: a infraestrutura composta por duas ou mais nuvens de quais-
quer tipos mencionados acima. A conexo entre elas feita via tecnologia proprie-
tria ou padronizada e permite a portabilidade de dados e aplicaes.
2.3 Integrao Computao em Nuvem e Internet das Coisas

Recentemente, a Computao em Nuvem tem sido defendida como uma soluo promis-
sora para atender a alguns dos requisitos de IoT, onde a integrao desses dois paradigmas
chamado de CloudIoT. A Computao em Nuvem promete um investimento inicial re-
duzido, alta disponibilidade, tolerncia a falhas e escalabilidade praticamente infinita,
caractersticas que atraram a ateno tanto do meio acadmico como da indstria (ZHOU
et al., 2010). Esses recursos so atraentes para IoT, pois permite que qualquer dispositivo
seja um terminal simples, sem a necessidade de possuir grandes recursos computacionais.
As principais vantagens obtidas da adoo do paradigma CloudIoT so:
Recursos de armazenamento - Oferecendo capacidade de armazenamento prati-
camente ilimitada, de baixo custo e sob demanda, a Computao em Nuvem a soluo
mais conveniente e rentvel para lidar com os dados produzidos pela IoT (RAO et al.,
2012). Uma vez na Nuvem, os dados podem ser tratados de forma homognea atravs de
APIs padro, podem ser protegidos pela aplicao de segurana e acessados diretamente
e visualizados de forma ubqua.
Recursos computacionais - Os dispositivos IoT tm recursos limitados de proces-
samento que podem no permitir o processamento de dados no local. As capacidades de
processamento ilimitadas da Computao em Nuvem e do seu modelo on-demand permi-
tem que o processamento de IoT seja adequadamente satisfeito (DASH et al., 2010). Outras
perspectivas so a realizao de processamento on-the-fly para implementar aplicativos
escalveis, em tempo real, colaborativos e centrados no sensor, para gerenciar eventos
complexos, e implementar a realizao de algumas tarefas para economizar energia (RAO
et al., 2012; DASH et al., 2010).
Elasticidade rpida - Uma das principais caractersticas da Computao em Nuvem
o provisionamento elstico de recursos. Em aplicaes IoT que trabalham com recursos
naturais no previsveis, essa uma caracterstica bastante interessante.
Recursos de comunicao - Um dos requisitos de IoT fazer com que os dispositivos
se comuniquem. A nuvem oferece uma soluo eficaz e barata para conectar, acompanhar e
gerenciar qualquer coisa de qualquer lugar a qualquer momento (RAO et al., 2012). Graas
disponibilidade de redes de alta velocidade, a Computao em Nuvem possibilita o
monitoramento e o controle das coisas remotas, sua coordenao, suas comunicaes, e o
acesso em tempo real aos dados produzidos (BOTTA et al., 2014).
Novas capacidades - A IoT caracterizada por uma alta heterogeneidade de dis-
positivos, tecnologias e protocolos. Portanto, escalabilidade, interoperabilidade, confiabi-
lidade, eficincia, disponibilidade e segurana podem ser difceis de obter. A integrao
com a Nuvem resolve a maioria desses problemas, fornecendo recursos adicionais como
facilidade de acesso, facilidade de uso e custos de implantao reduzidos (FOX et al., 2012;
SUCIU et al., 2013).
Novos paradigmas - A adoo de CloudIoT possibilita novos cenrios para servios e
aplicaes inteligentes baseados na extenso da Computao em Nuvem atravs das coisas,
criando novos paradigmas como: SaaS (Sensoramento como Servio), SenaaS (Sensor como
Servio), DBaaS (Banco de Dados como Servio), DaaS (Dados como Servio) e IPMaaS
(Gesto de Identidade e de Polticas como um Servio) (RAO et al., 2012; SUCIU et al.,
2013).
Nos ltimos anos, surgiram vrias plataformas, protocolos e sistemas para enfrentar
os desafios da integrao da Computao em Nuvem e IoT. Essas plataformas tentam
colmatar os desafios desse paradigma implementando um mediador (middleware) para as
coisas e a nuvem. Apesar destes desafios, esta integrao considerada ser uma opo
vivel para facilitar o desenvolvimento de aplicativos de IoT (SUCIU et al., 2014).
2.4 Engenharia de Software Baseada em Evidncia

A ESBE um paradigma da Engenharia de Software que permite identificar, selecionar e
sintetizar evidncias a partir de estudos primrios (KITCHENHAM, 2004). Surgido inicial-
mente na medicina, o objetivo enunciado da ESBE proporcionar os meios pelos quais as
melhores evidncias de pesquisas possam ser integradas s experincias prticas e valores
humanos no processo de tomada de deciso no desenvolvimento e manuteno de software.
Segundo Kitchenham (2004) so trs os mtodos sistemticos para se conduzir pes-
quisas com base nos princpios da ESBE:
1. Revises Sistemticas da Literatura (RSL): destinadas a identificar, anali-
sar e interpretar as evidncias disponveis relacionadas a uma questo especfica de
pesquisa, uma RSL tem uma metodologia bem definida e a questo de pesquisa es-
pecfica tratada de maneira imparcial. Normalmente esto relacionadas a questes
do tipo: Um tratamento X aplicado a uma populao P mais eficiente para se
obter o resultado R no contexo C quando comparado com o tratamento Y?
2. Mapeamento Sistemtico da Literatura (MSL): tambm categorizado como
estudo exploratrio, apresenta uma ampla reviso de estudos primrios em uma rea
ou tpico especfico no intuito de identificar quais as provas disponveis sobre um
tema em questo. Normalmente relacionados a questes do tipo O que sabemos
sobre o tema X?, MSLs objetivam identificar todas as pesquisas que procuram
responder questes amplas e exploratrias sobre as tendncias de uma determinada
rea.
3. Meta-anlise: o mtodo pelo qual, atravs de anlise estatstica, sintetiza-se os
resultados de diferentes estudos primrios independentes para integrar, combinar
e resumir seus resultados de forma a responder a uma determinada questo de
pesquisa.
Muitas tecnologias so transferidas para a indstria sem terem passado por um pro-
cesso adequado de avaliao que permita a caracterizao do seu grau de maturidade
(KAINDL et al., 2002). A ESBE visa a encurtar esta lacuna, incentivando um maior rigor
metodolgico. Segundo Kitchenham (2004), ESBE deve prover meios pelos quais melho-
res evidncias provenientes da pesquisa possam ser integradas com experincia prtica no
processo de tomada de deciso. Assim, a utilizao de uma metodologia baseada em evi-
dncia representada por revises sistemticas contribui satisfatoriamente para a definio
de uma nova tcnica ou tecnologia (MAFRA; RAFAEL; TRAVASSOS, 2006).
2.5 Arquitetura de Software

Uma AS uma abstrao de alto nvel de um sistema de Software, que tem por objetivo,
fornecer uma descrio de como o mesmo ir funcionar, dividindo-o em mdulos e descre-
Tabela 1 Padres Arquiteturais.
Categoria Padro
Blackboard
Estrutural Layers
Pipes and Filters
Sistemas Distribudos Brokers
MVC
Sistemas Interativos
PAC
Microkernel
Sistemas Adaptveis
Reflection
Fonte: Adaptado de (BUSCHMANN et al., 1996)
vendo como esses mdulos esto conectados entre si, e como feita a comunicao entre
os mdulos, bem como as tecnologias que so usadas no sistema.
AS funciona como uma forma de mostrar aos envolvidos no processo de desenvolvi-
mento (desenvolvedores, stakeholders e clientes) como o sistema ir funcionar, abstraindo
a parte tcnica para uma forma ilustrada. Para descrever uma arquitetura de software,
normalmente usa-se um modelo composto de vrios pontos de vista ou perspectivas.
2.5.1 Padres Arquiteturais

Os Padres Arquiteturais (PAs) so modelos para o desenvolvimento de AS baseados
em problemas comuns em determinadas reas, ou seja, so solues j comprovadas que
podem ser usadas para resolver problemas semelhantes, assim agilizando o processo de
resoluo desses problemas.
PAs fornecem conhecimento de design reutilizvel na forma de solues comprovadas
para problemas de software recorrentes em um contexto ou de domnio particular (ZDUN
et al., 2004). Os PAs representam a organizao dos sistemas de software. Eles definem,
entre outros aspectos, os tipos de componentes e conectores utilizados em descries
arquiteturais.
Em Buschmann et al. (1996), os PAs so agrupados de acordo com as caractersticas
dos sistemas em que eles so mais aplicveis, com uma categoria tratando das questes
gerais de estruturao. Na Tabela 1 so listadas as categorias e os padres nelas contidos.
Desses padres dois sero usados neste trabalho: Layers e Broker.
2.5.1.1 Layers
O PA Layers ajuda a estruturar aplicaes que podem ser decompostas em grupos de

subtarefas onde cada grupo est em um nvel parcial de abstrao (BUSCHMANN et al.,
1996).
Para Buschmann et al. (1996), uma abordagem em camadas considerada uma prtica
melhor do que implementar o protocolo como um bloco monoltico, uma vez que imple-
mentar conceitualmente diferentes questes separadas tem vrios benefcios, por exemplo,
ajudando o desenvolvimento por equipes e apoiando a codificao incremental e testes.
Com esse PA melhores tecnologias de implementao, como novas linguagens ou algorit-
mos, podem ser incorporadas simplesmente reescrevendo uma seo delimitada de cdigo.
2.5.1.2 Broker
O PA Broker pode ser usado para estruturar sistemas de software com componentes
distribudos que interagem com chamadas de servios remotos. Um Broker responsvel
por coordenar a comunicao, como por exemplo, encaminhar pedidos, bem como, para
transmisso de resultados e excees. Esse tipo de sistema funciona com trs componentes,
o Publicador (Publisher), o Broker e Assinante (Subscribe).
Segundo Buschmann et al. (1996), o PA Broker, para aplicaes distribudas, pode
acessar servios de outras aplicaes simplesmente pelo envio de mensagens a objetos
mediadores, sem se preocupar com questes especficas relacionadas comunicao entre
processos, como a sua localizao.
Segundo Levy e Losavio (1999), o PA Broker usado para, estruturar sistemas distri-
budos com componentes dissociados que interagem por invocaes de servios remotos,
o qual responsvel por coordenar as comunicaes. Um componente Broker pode ser in-
troduzido para gerenciar a comunicao entre clientes e servidores, desta forma, o padro
cliente-servidor muda para o padro Broker.
2.6 Assinatura Digital

Criptografia a arte de transformar, de maneira reversvel a informao de sua forma ori-
ginal para outra ilegvel. Existem duas classes de criptografia, a simtrica e a assimtrica.
A criptografia assimtrica foi proposta por W. Diffie e M. Hellman em 1976, nesta classe
de criptografia para haver uma troca de informaes entre remetente e destinatrio no
necessrio o compartilhamento de uma chave comum, como ocorre na simtrica.
Em resumo, uma assinatura digital tpica envolve dois processos criptogrficos: criar
um resumo da mensagem (hash) e criptografar esse hash com a chave privada do remetente
para assinar ou descriptografar o hash da mensagem com a chave pblica do remetente
para autentic-la.
2.6.1 Aspectos Gerais

A tcnica usada na criptografia de chave pblica o uso de algoritmos de chave assim-
trica, nos quais cada usurio tem um par de chaves criptogrficas uma chave pblica e
uma chave privada. As chaves so relacionadas matematicamente, mas os parmetros so
escolhidos de forma que o clculo da chave privada a partir da chave pblica seja invivel.
Os sistemas de criptografia de chave pblica so classificadas em trs categorias:
Com base no problema de fatorao inteira, como RSA;
Com base em logaritmo discreto, como o Algoritmo de Assinatura Digital (DSA);
Com base na curva elptica, como a Curva Elptica Diffie Hellman (ECDH).
Uma aplicao prtica de um sistema de encriptao de chave pblica garantir a
confidencialidade, onde uma mensagem que o emissor deseja encriptar usa a chave pblica
do destinatrio e essa mensagem s pode ser decriptada pela chave privada correspondente
do destinatrio.
Outra aplicao da criptografia de chave pblica a assinatura digital. A utilizao
da assinatura digital providencia a prova inegvel de que uma mensagem veio do emissor
(GUSTAVO et al., 2012). Para verificar este requisito, uma assinatura digital deve ter as
seguintes propriedades (GUSTAVO et al., 2012):
autenticidade - o receptor deve poder confirmar que a assinatura foi feita pelo
emissor;
integridade - qualquer alterao da mensagem faz com que a assinatura no cor-
responda mais ao documento;
irretratabilidade ou no-repdio - o emissor no pode negar a autenticidade da
mensagem.
2.6.2 Algoritmos de Chave Pblica - RSA e ECC

RSA (Rivest-Shamir-Adleman) a mais bem sucedida implementao de sistemas de
chaves assimtricas (GUSTAVO et al., 2012). Seu nome vem das iniciais dos trs professo-
res do Instituto de Tecnologia de Massachusetts (MIT) que inventaram este algoritmo.
Esse sistema considerado um dos mais seguros e foi o primeiro algoritmo a possibilitar
criptografia e assinatura digital (AGRAWAL, 2013).
RSA usa exponenciao modular do produto de dois nmeros primos para encriptar
e decriptar mensagens. Sua segurana est relacionada extrema dificuldade de fatorar
inteiros muito grandes. Desde que as chaves sejam geradas corretamente, a nica ma-
neira conhecida de quebrar o RSA executar um ataque de fora bruta sobre o mdulo
(AGRAWAL, 2013). Este ataque pode ser dificultado aumentando o tamanho da chave.
Os principais problemas no algoritmo RSA so:
Aumento do tempo de processamento - O tempo de decodificao aumenta aproxi-
madamente oito vezes com a duplicao do tamanho da chave;
Maior necessidade de armazenamento de chaves - O armazenamento de chaves requer

uma quantidade significativa de memria para armazenamento;
A gerao de chaves complexa e demorada. O tempo aumenta consideravelmente
medida que o tamanho da chave aumenta;
Sobrecarga de computao devido s operaes de exponenciao, o que requer mais
multiplicaes e operaes modulares.
A introduo de Criptografia de Curvas Elpticas (ECC) por Neal Koblitz e Victor
Miller, de forma independente em 1985, tem obtido novos algoritmos de chave pblica
baseados no problema do logaritmo discreto. As operaes matemticas de ECC so
definidas sobre a curva elptica: 2 = 3 + + , onde cada valor de a e b gera uma
curva elptica diferente.
Problemas de logaritmo discreto sobre curvas elpticas so matematicamente mais
complexos do que o problema de fatorao inteira como RSA (AGRAWAL, 2013). Por isso
criptografia por curvas elpticas podem rivalizar com a segurana de outros criptosistemas
usando uma chave menor. Por exemplo uma criptografia por curvas elpticas com chave
pblica de tamanho 160 bits so to seguros quanto criptosistemas RSA e DSA com chave
pblica de tamanho 1024 bits (AGRAWAL, 2013). Com chave de tamanho menor, cripto-
sistemas de curva elptica podem oferecer menor requisitos de memria, implementao
mais rpida e menor requisito de largura de banda (SUTIKNO et al., 2002).
2.7 Consideraes Finais do Captulo

Este captulo descreveu o referencial terico utilizado durante o desenvolvimento desta
pesquisa. Foram explanados os principais conceitos e definies de Internet das Coisas
e Computao em Nuvem e a integrao desses dois paradigmas, ESBE, Arquitetura de
Software e Assinatura Digital.
No prximo captulo ser apresentada uma reviso da literatura, realizada a fim de
entender como o programa de distribuio de gua no Semirido brasileiro funciona e
de ter uma viso precisa do estado da arte dos Sistemas de Gerenciamento de Recursos
Hdricos.
32
3 Reviso da Literatura
Este captulo tem por objetivo analisar como o programa de distribuio de gua no
Semirido brasileiro funciona e emprega a TI em seu apoio e tambm apresentar o estado
da arte de SGRH que empregam IoT. Para isso na seo 3.1 realizada uma anlise
do modelo de distribuio de gua empregado no Semirido brasileiro e na seo 3.2
realizado um MSL a fim de obter um survey das tecnologias de IoT empregadas nestes
sistemas.
3.1 Anlise do Modelo de Distribuio de gua no Semirido Bra-

sileiro
As polticas pblicas de interveno realizadas no Semirido brasileiro para superao
da problemtica da seca, em geral, so insuficientes para sanar a demanda de gua da
populao, sendo necessrio para a sua complementao o uso de carros-pipa contratados
pelo Governo Federal (PASSADOR; CLAUDIA, 2010).
O Programa Emergencial de Distribuio de gua, conhecido nacionalmente como
Operao Carro-Pipa (OCP), uma iniciativa do Governo Federal que tem a finalidade
de entregar gua potvel populao carente da regio semirida do Brasil. Essa operao
atende cerca de 1.000 municpios com um gasto anual de mais de 1 bilho de reais.
A presente seo tem por finalidade promover uma anlise do modelo de distribuio
de gua empregado e da utilizao da TI como instrumento de melhoria dos processos
de fiscalizao da OCP, bem como, apresentar os benefcios e limitaes do uso dessa
tecnologia.
3.1.1 Metodologia
Quanto forma de abordagem, esta subseo caracteriza-se por uma pesquisa qualitativa
por haver uma aproximao do pesquisador ao campo de trabalho para um melhor deline-
amento das questes, dos instrumentos de coleta e do grupo a ser pesquisado (MERRIAM,
2009). A pesquisa foi feita em um ambiente real, nos escritrios da OCP do EB, sendo
realizadas entrevistas com os seus coordenadores, auxiliares, analistas e desenvolvedores
dos SI usados nesta operao e acompanhamento do processo in loco como observador.
Compreenso do Domnio tem como objetivo adquirir um bom entendimento do do-
mnio do sistema a ser implementado e a Elicitao de Requisitos consiste em descobrir
requisitos candidatos e pressupostos que moldam o sistema a ser desenvolvido (WILEY,
2008). A fim de realizar essas duas fases da Engenharia de Requisitos foram realizados
Captulo 3. Reviso da Literatura 33
diversos estudos de background para entender e avaliar como os sistemas empregados

documentam os fluxos de informao, procedimentos de trabalho, regras de negcios e
formas de intercmbio entre as unidades envolvidas.
Neste sentido, foi realizada uma exaustiva pesquisa bibliogrfica, utilizando como fon-
tes de busca: artigos e trabalhos acadmicos; Regulamentos, Portarias, Diretrizes, Normas
e Boletins do Exrcito; Diretrizes de Planejamento, Ordens de Servio e seus anexos, fi-
chas de cadastro, contratos, relatrios, pesquisas de opinio, cartilhas, planilhas, recibos
e demais documentos contendo orientaes sobre a OCP; manual dos sistemas especficos
utilizados; estudos das atividades de fiscalizao realizadas na operao que ainda no
foram automatizadas; anlise de dados de marketing, estatsticas de uso e desempenho,
custos mdios, entre outros artefatos.
Tambm foram realizadas diversas entrevistas semiestruturadas e sesses de grupo no
estruturado para o levantamento de requisitos e entendimento do domnio.
3.1.2 Sistemas de Informao na Distribuio de gua

A fim de prover o Exrcito Brasileiro com elementos para o planejamento, controle e
fiscalizao da OCP nos diferentes nveis (gerencial, coordenao e operacional) o Governo
Federal dispem do Sistema de Gesto e Controle de Distribuio de gua (GCDA).
Mantido e desenvolvido pelo EB desde o ano de 2005, o GCDA utiliza das informaes
disponveis no Sistema Integrado de Administrao Financeira (SIAFI)1 para pagar o
transporte dos carros-pipa, em acordo com a Lei Federal Nr 8.666 de 21/06/1993.
Devido natureza logstica do programa, o Ministrio da Integrao Nacional teve a
necessidade de contratar uma empresa para desenvolver e implantar um sistema de rastre-
amento veicular que fornecesse informaes de geoprocessamento para o prprio ministrio
e para o sistema GCDA. Para essa finalidade, foi ento desenvolvido em 2012, um sistema
embarcado nos carros-pipa para atender a essa demanda, chamado de GPIPABRASIL.
3.1.2.1 GCDA
O GCDA composto por mdulos que proporcionam inmeros benefcios nos processos
de apoio s equipes de fiscalizao da OCP (LOPES, 2016), como os descritos abaixo:
Informaes sobre municpios, pontos de coleta (Mananciais) e abastecimento de
gua (Ponto de Abastecimento (PAbst)), itinerrios, prestadores de servio (Pipei-
ros), carros-pipa, lderes comunitrios, entre outras;
Orientaes sobre o posicionamento geogrfico dos pontos de coleta e abastecimento
de gua, sedes de Organizaes Militares Executoras (OME) e municpios atendidos,
por meio do georreferenciamento desses pontos;
Planejamento do plano de trabalho mensal dos Pipeiros contratados;
1
https://siafi.tesouro.gov.br/senha/public/pages/security/login.jsf
Disponibilizao de consultas e relatrios, para acompanhamento e controle da exe-

cuo da distribuio de gua; e
Informaes consolidadas em todos os escales, de acordo com o perfil de usurio.
3.1.2.2 GPIPABRASIL
O Sistema de Monitoramento da Logstica da Entrega de gua por Carros-Pipa (GPIPA-

BRASIL), contratado pelo Ministrio da Integrao, tem como objetivo atender a OCP
nos seguintes requisitos (LOPES, 2016):
Rastreamento eletrnico do percurso realizado pelo Pipeiro durante a entrega de
gua, apresentando as informaes de posicionamento do veculo, recebidas via GPS,
em mapas;
Registro das entregas de gua realizadas pelo Pipeiro, correspondendo os eventos de
coleta de gua no Manancial e descarga de gua no PAbst, com informaes de data,
horrio e posio geogrfica, mediante leitura de um carto magntico de posse do
Pipeiro;
Registro das entregas de gua confirmadas pelo sistema, bem como, as entregas
pendentes para anlise dos operadores;
Produo de alertas de notificao das entregas de gua pendentes, informando se
o Pipeiro contratado violou alguma regra estabelecida no seu plano de trabalho ou
se h algum problema tcnico no Mdulo Embarcado de Monitoramento (MEM); e
Gerao de um arquivo (lote de entregas de gua confirmadas por Pipeiro e por ms
de trabalho) para ser importado no GCDA. Esses dados serviro para confeco dos
pagamentos dos Pipeiros.
3.1.3 Processo de Distribuio de gua

O GCDA e o GPIPABRASIL atuam em conjunto no processo de distribuio e recebi-
mento de gua executado na OCP. Neste processo so empregados trs atores: Operador
do GCDA, Pipeiro e o Beneficirio (responsvel pelo PAbst). Tambm so utilizados os
seguintes artefatos: tablet, carto magntico de posse do Pipeiro, carto magntico de
posse do Beneficirio, equipamento de leitura dos cartes magnticos, e MEM.
O operador do GCDA utiliza um tablet para fazer o registro das coordenadas do Ma-
nancial, do trajeto e do PAbst. O Pipeiro possui um carto magntico com seus dados
pessoais e um equipamento de leitura deste carto, apresentados na Figura 2. Este equipa-
mento de leitura comunica-se com o MEM, fixo no carro-pipa, o qual possui comunicao
via telefonia mvel (antena GSM/GPRS e Chips de duas operadoras) com o GPIPA-
BRASIL e um GPS. Por fim, o Beneficirio tambm possui um carto magntico com
seus dados pessoais, usado como assinatura no processo.
A distribuio de gua funciona da seguinte forma, sintetizado na Figura 3:
Figura 2 Carto e leitor de carto usados no processo de distribuio de gua
Fonte: o Autor
1. O Pipeiro comparece OME para receber seu plano de distribuio, o qual consta:
datas dos abastecimentos, Manancial em que deve encher o carro-pipa, PAbst que
devem suprir e itinerrio que deve ser seguido;
2. Na data estabelecida, o Pipeiro vai para o Manancial, enche o carro-pipa e passa
o seu carto magntico no leitor. Esse leitor recebe os dados do Pipeiro e repassa
para o MEM. O MEM ento inicia o processo de entrega, inserindo as localizaes
geogrficas do Manancial, data-hora do enchimento e dados do Pipeiro.
3. O Pipeiro faz o deslocamento at o PAbst. Esse trajeto salvo no MEM juntamente
com os dados da entrega iniciada no passo anterior.
4. Chegando ao PAbst, o Pipeiro faz a entrega da gua na cisterna do Beneficirio.
5. Aps a entrega da gua, o Pipeiro passa seu carto magntico novamente no equi-
pamento de leitura para fechar a entrega. Novamente o equipamento de leitura do
carto apenas repassa os dados do Pipeiro para o MEM.
6. Para realmente fechar a entrega, o Beneficirio tambm passa o seu carto magntico
no equipamento de leitura, como forma de assinatura do recebimento da gua. O
equipamento de leitura novamente repassa esses dados para o MEM.
7. Ao receber os dados do carto do Pipeiro e do Beneficirio, o MEM insere os dados
de localizao geogrfica e a data-hora do abastecimento, encerrando a entrega.
8. Por fim, o MEM armazena os dados desta entrega e os envia para o GPIPABRASIL
to logo consiga sinal de rede celular.
9. Finalizando o processo, feito pelo GPIPABRASIL a integrao dos dados, importando-
os para o GCDA, que armazena as informaes em seu banco de dados.
O pagamento do Pipeiro calculado: com base na distncia percorrida entre o Manan-
cial e o PAbst em um itinerrio pr-estabelecido; a qualidade das estradas no itinerrio,
no sistema chamado de "momento da entrega"; e a quantidade de gua entregue ao Bene-
ficirio em metros cbicos. Sendo assim, o valor de cada entrega calculado da seguinte
forma: Valor Entrega=distncia*volume*momento.
Figura 3 Processo de distribuio de gua
Fonte: GCDA
3.1.4 Problemas no Mtodo Atual de Distribuio de gua

As informaes obtidas pelo GPIPABRASIL so repassadas apenas mensalmente para a
equipe do GCDA, a qual necessita dessas informaes atualizadas diariamente. Um caso
tpico de falha por esse motivo de um PAbst ser abastecido por dois Pipeiros distintos
no mesmo ms, ultrapassando a necessidade mensal do Beneficirio.
Outro problema a quebra constante dos MEM, sendo manutenido e distribudo aos
Pipeiros pelo GPIPABRASIL, onerando assim o sistema. Quando isso ocorre, o controle
passa a ser feito por papel e caneta, deixando o sistema mais propcio a erro e fraude.
Tambm houve relato de suspeita de danificao do MEM voluntariamente por parte dos
Pipeiros, a fim de no serem monitorados.
Outro problema no processo a confeco do plano de trabalho baseado totalmente
em estatstica. Neste modelo a entrega em um PAbst calculada segundo estudos que
estimam que, em mdia, as necessidades de gua tpicas dos assistidos pelos programas de
cisternas so da ordem 16 mil litros/famlia/8 meses. Seguindo esse modelo, a distribuio
termina no sendo uniforme, ocorrendo que muitos Beneficirios ficam com suas cisternas
secas por longo perodo, enquanto por outro lado, ocorre por diversas vezes a entrega em
PAbst ainda cheios.
No processo de entrega de gua propriamente dito, um dos maiores problemas relatado
a grande quantidade de interao humana, principalmente com as leituras dos cartes.
Essa leitura alm de dar uma complexidade a mais no processo tambm propensa a
erro, uma vez que o Pipeiro ou o Beneficirio pode acreditar que fez a leitura sem t-la
feito ou faz-la vrias vezes.

Outra oportunidade de melhoria neste processo quanto ao controle do local onde o
Pipeiro abasteceu o carro-pipa. Neste processo o controle realizado apenas com o Pipeiro
passando seu carto no leitor para gravar as coordenadas e data-hora de abastecimento.
Desta forma, controla-se apenas que o Pipeiro passou pelo Manancial, no que ele re-
almente encheu o carro-pipa neste local. Esse processo pode ser facilmente burlado, por
exemplo, o Pipeiro pode encher seu carro-pipa em qualquer local e s depois passar no
Manancial previsto e registrar sua passagem.
Por fim, um dos maiores problemas identificado neste estudo a total ausncia de
controle da quantidade e da qualidade da gua entregue. No se sabe quanto o Pipeiro
pegou de gua no Manancial e pior de tudo, no se sabe quanto ele entregou no PAbst.
Neste modelo no existe nenhuma fiscalizao na entrega do volume e da qualidade do
recurso, havendo apenas o controle da entrega, sabe-se que entregou, mas no se sabe
quanto nem em que condies. Segundo relatos, muitas vezes ocorre a situao do Pipeiro
chegar e o PAbst est semicheio, nesse caso, o Pipeiro recebe pelo valor completo da
entrega e vende ou joga fora o excesso, desperdiando recurso ou caracterizando fraude.
3.1.5 Resumo da Seo

Esta seo apresentou um anlise do processo de distribuio de gua e do emprego da TI
como instrumento de melhoria dos processos de fiscalizao da OCP. A partir da anlise
dos dois sistemas empregados e do processo de distribuio de gua usado na OCP foram
levantados seus benefcios, deficincias, falhas e oportunidades de melhorias.
3.2 Mapeamento das Tecnologias de IoT para SGRH

Durante os estudos preliminares de trabalhos encontrados em buscas ad-hoc, foi obser-
vado que existem diversas tecnologias e tcnicas empregadas nas abordagens usadas para
sistemas de monitoramento, distribuio e gerenciamento de recursos hdricos, chama-
das genericamente neste trabalho de Sistemas de Gerenciamento de Recursos Hdricos ou
SGRH. Desta forma verificou-se a necessidade de se mapear essas tecnologias e tcnicas.
De acordo com Kitchenham (2007), um MSL deve identificar, avaliar, interpretar e
comparar todas as fontes relevantes, a fim de responder a questes sobre as tendncias de
uma determinada rea de pesquisa. Diante disto, com a consolidao deste MSL pretende-
se ter uma viso precisa do estado da arte dos SGRH que utilizam IoT.
3.2.1 Perguntas de Pesquisa

Com base no cenrio descrito acima, levantou-se a questo principal para conduo dessa
pesquisa: quais as principais tecnologias e tcnicas empregadas em SGRH que utilizam o
paradigma de IoT como abordagem principal?

Baseado nessa pergunta, oito Questes de Pesquisa (QP) foram definidas, com objetivo
de viabilizar o desenvolvimento deste mapeamento:
QP1 Quais os tipos de SGRH que empregam IoT. Esses sistemas podem ser cate-
gorizados?
QP2 Quais modelos de arquitetura de IoT so empregados nestes sistemas?
QP3 Quais tecnologias de comunicao so usadas neste sistemas?
QP4 - Quais sensores so usados nestes sistemas?
QP5 - Quais tcnicas ou sensores so usados para medir volume de gua?
QP6 - Quais controladores ou microcontroladores so usados nestes sistemas?
QP7 - Quais as formas de energia so empregadas para alimentao destes sistemas?
QP8 Esses sistemas usam Computao em Nuvem?
A proposta deste mapeamento identificar tecnologias de forma quantitativa, assim
espera-se encontrar resultados como: porcentagem de projetos que usam Computao em
Nuvem e tipos de controladores usados.
3.2.2 Metodologia da Pesquisa

Para realizar este MSL foi empregada uma equipe formada por um doutor (revisor), dois
mestres e dois mestrandos, todos em Cincia da Computao pela Universidade Federal
de Pernambuco. As subsees a seguir descrevem como foi realizado este MSL.
3.2.2.1 Etapas do Mapeamento
O ponto inicial da pesquisa deu-se por uma busca ad-hoc executada a fim de entender
qual o estado da arte dos SGRH com IoT. Porm, devido ao interesse de mapear esses
sistemas e abordagem mais horizontal utilizada nas Questes de Pesquisa, entendeu-se
que um MSL seria o mtodo mais adequado para esse mapeamento.
Para a definio do protocolo foram empregadas as ideias de Kitchenham (2004):
Identificar as necessidades da rea pesquisada;
Formular Questes de Pesquisa dirigidas;
Executar busca exaustiva para obter os estudos primrios;
Avaliao qualitativa dos estudos primrios;
Identificao de dados necessrios para responder as Questes de Pesquisa;
Extrao dos dados;
Resumo e sntese dos resultados extrados dos estudos (meta-anlise);
Interpretao dos resultados para determinar sua aplicabilidade;
Escrita do Mapeamento.
A adaptao dessas ideias resultou nas etapas do processo adotado nessa pesquisa,
conforme apresentado na Figura 4.
Figura 4 Etapas do Mapeamento Sistemtico da Literatura
Fonte: o Autor
3.2.2.2 Execuo da Busca
Esta etapa iniciou-se com a definio da string de busca, composta por termos refinados
entre os pesquisadores. Para chegar a esses termos foram analisados os trabalhos seleci-
onados na pesquisa ad-hoc realizada anteriormente. O processo de refinamento pode ser
observado na Figura 5.
Figura 5 MSL - Processo de refinamento da busca
Fonte: o Autor
Em seguida, uma busca manual foi efetuada em peridicos e publicaes relacionadas

Elsevier, IEEE, ACM e Springer, uma vez que eles so considerados uns dos lderes
em publicao de produes cientficas de alta qualidade (BRERETON, 2007). Essa busca
tambm serviu para melhorar os termos para a string de busca.
Os termos selecionados, bem como sinnimos e plurais foram armazenados em uma
planilha eletrnica, para depois formarem a string de busca. A string de busca gen-
rica a seguinte: ((IoT OR "Internet of things"OR "Internet das Coisas") AND ("water
level"OR "water supply"OR "water distribution"OR "water management"OR "water mo-
nitoring"OR "monitoring water"OR "monitoring of water"OR "management of water"OR
"Water Supply"OR "Water Transportation"OR "gua")).
importante salientar que a string geral precisou ser adaptada para cada mecanismo
de busca devido s suas diferentes sintaxes, mas, sendo mantidas todas as combinaes.
Aps a definio da string, foi realizada a busca automtica. Para execuo dessa
busca, foram consideradas as seguintes bibliotecas digitais: ScienceDirect; SCOPUS; IEEE
Xplore e ACM Digital Library.
Por ltimo, e apenas nos artigos selecionados, foi aplicada a tcnica snowball. Essa
tcnica consiste em pesquisar as referncias dos artigos selecionados em busca de trabalhos
relevantes que no foram encontrados pelos engenhos de busca. Deste modo, os estudos
disponveis eram comparados com os j existentes da busca automtica e manual. Se o
estudo j houvesse sido armazenado anteriormente, o ltimo era ento descartado.
3.2.2.3 Critrios de Seleo dos Estudos
Cada estudo retornado atravs das buscas foi avaliado em relao a sua relevncia quanto
a esse MSL. Assim, todos passaram por critrios de excluso e incluso.
Critrios de incluso:
O trabalho explora SGRH com IoT como foco principal;
O trabalho apresenta um SGRH com IoT, mesmo que seja a implementao de um
estudo de caso ou avaliao de uma tcnica, ideia ou contribuio.
Critrios de excluso:
Estudos sem foco na rea de IoT;
Estudos duplicados;
Keynotes, Whitepapers e apresentaes;
Trabalhos antes de 1999;
O estudo no responde s questes de pesquisa.
A excluso de Keynotes, Whitepapers e apresentaes fez-se pelo interesse da busca
ser realizada em bibliotecas digitais cientficas, porm a incluso desses artefatos pode
enriquecer a pesquisa com contribuies de cunho comercias e experimentais. Foram ex-
cludos tambm os artigos escritos antes do ano de 1999, ano que marca o surgimento do
termo Internet das Coisas (SURESH et al., 2014). J o ltimo critrio de excluso tambm
carece de esclarecimento: alguns artigos mesmo passando por todas as fases do processo
de seleo no expunham detalhes sobre o sistema, inviabilizando a extrao das respostas
s questes de pesquisa.
Primeiramente, os critrios foram aplicados nos ttulos, palavras-chave e abstract. Em
seguida foram executados na introduo e concluso. At este momento apenas os traba-
lhos que claramente estavam fora do escopo desta pesquisa foram excludos. Por ltimo,
as verses completas dos estudos restantes foram lidas para uma anlise mais detalhada.
3.2.3 Sntese e Anlise dos Dados

Esta subseo apresenta os resultados obtidos a partir do MSL, descrito na seo anterior.
Para um melhor entendimento, os resultados foram agrupados em quatro categorias:
Extrao e anlise de dados: informaes gerais sobre os dados retornados.
Respostas das Questes de Pesquisa: foram agrupadas nessa categoria as res-
postas relacionadas a cada Questo de Pesquisa.
Discusso dos resultados: uma discusso baseada nos principais resultados.
Sntese do mapeamento: apresentado um resumo dos resultados obtidos deste

mapeamento.
3.2.3.1 Extrao e Anlise dos Dados
Os dados apresentados aqui advm da execuo do protocolo definido na subseo 3.2.2,

resumidos na Figura 6. Esta subseo est dividida em (a) Seleo dos Dados e (b) Anlise
dos Dados.
Figura 6 MSL - Resumo do protocolo
Fonte: o Autor
a. Seleo dos Dados

Da aplicao do protocolo executado neste MSL, j aplicados todos os filtros de seleo
nos artigos encontrados na pesquisa ad-hoc, na busca manual, na busca automtica e
por cima aplicada a tcnica Snowball, chegou-se a um total de 55 artigos selecionados,
apresentados no Anexo A.
A Figura 7 (a) apresenta os resultados parciais da aplicao dos critrios de seleo
na busca automtica e (b) resume o resultado final da seleo dos dados desse MSL.
b. Anlise dos Dados

Por ano
Para essa pesquisa levou-se em considerao os trabalhos escritos depois do ano de
1999, ano em que Kevin Ashton cunhou o termo Internet das Coisas (SURESH et al., 2014).
Antes desta data j existiam alguns trabalhos no sentido de IoT como conhecida hoje,
porm so trabalhos com termos genricos o que inviabilizaria a execuo da busca.
Apesar da excluso de 195 trabalhos por esse filtro, houve-se a preocupao de ler o
ttulo e abstract desses artigos, o que confirmou sua excluso. Uma possvel explicao
para apesar de haver uma entrada dos termos (IoT OR Internet of Things) AND nas
strings de busca, ter havido retorno de 195 artigos supostamente antes do termo IoT ou
Figura 7 MSL - Artigos selecionados
(a) Resultados parciais da busca automtica (b) Artigos selecionados

Fonte: o Autor
Internet of Things existir, a possvel classificao posterior desses trabalhos nos engenhos
de busca.
Como mostra a Figura 8, o primeiro ano que teve um trabalho relevante para esse MSL
foi o ano de 2007 com 1 trabalho. O ano de 2015 foi o que apresentou maior quantidade de
trabalhos selecionados, 25. J o ano de 2016 selecionou 17 artigos, porm, vale salientar
que essa pesquisa ocorreu em meados daquele ano.
Figura 8 MSL - Artigos por ano de publicao
Fonte: o Autor
Por Pas da instituio dos autores

O pas que mais publicou artigos selecionados para esse MSL foi a ndia, seguido pela
China, como mostra a Figura 9. Esse ndice, demonstra a necessidade destes pases e a
preocupao dos pesquisadores quanto gerncia de recursos hdricos.
Neste MSL no foi encontrado nenhum trabalho brasileiro. Esse um campo com
potencial de ser explorado por pesquisadores brasileiros, uma vez que a falta de gua
Figura 9 MSL - Artigos por Pas de publicao
Fonte: o Autor
faz com que a populao rural e das pequenas cidades do Semirido brasileiro fiquem
submetidas a condies de extrema dificuldade (PADILHA et al., 2004).
3.2.3.2 Respostas das Questes de Pesquisa
Esta pesquisa utilizou uma abordagem quantitativa baseada no texto, palavras-chave e

figuras dos trabalhos selecionados para obter as resposta. Existem Questes de Pesquisas
que no so respondidas por todos os trabalhos selecionados, assim, para se computar a
resposta de cada QP so utilizados os trabalhos selecionados que respondem a questo,
esses trabalhos so chamados de trabalhos vlidos neste MSL.
QP1 Quais os tipos de SGRH que empregam IoT. Esses sistemas podem
ser categorizados?
Baseado nos artigos selecionados, pde-se chegar a algumas reas de pesquisas rela-
cionadas com SGRH. Esse agrupamento foi feito por certas caractersticas dos sistemas,
como por exemplo, tipos de sensores usados, necessidade de atuadores, palavras-chaves e
termos encontrados nos artigos.
Aps esse agrupamento, chegou-se a cinco categorias bsicas: Gerenciamento de gua,
gua na agricultura, Monitoramento de gua, Monitoramento de enchente e Suprimento
de gua.
QP2 Quais modelos de arquitetura de IoT so empregados nestes siste-
mas?
Os dados para a resposta a essa questo foram obtidos a partir da declarao explcita
do trabalho quanto arquitetura usada. Para isso foi considerada arquitetura composta
por cinco camadas: camada de Percepo, camada de Rede, camada de Processamento,
camada de Aplicao e camada de Negcios (MIAO, 2012).
Assim, dos 55 artigos selecionados 31 trabalhos no fazem qualquer aluso arquite-
tura empregada. Para esses trabalhos que no declaram a arquitetura usada no houve
esforo para classific-los quanto arquitetura, este esforo est fora do escopo deste tra-
balho. A Figura 10 mostra os resultados dos artigos vlidos para essa questo de pesquisa.
Neste MSL 59% dos trabalhos vlidos declaram ou explicitam usar a arquitetura em
3 camadas, desta forma, neste trabalho encontra-se evidncia que a maioria dos SGRH
Figura 10 MSL - Artigos por Camadas de IoT
Fonte: o Autor
empregam o modelo de arquitetura de IoT clssica em 3 camadas, sendo: Camada de

Percepo, Camada de Rede e Camada de Aplicao.
QP3 Quais tecnologias de comunicao so usadas nestes sistemas?
Al-Fuqaha et al. (2015) distinguem trs abordagens de IoT diferentes para a conectivi-
dade de dispositivos: (i) um protocolo de baixa potncia (por exemplo, Zigbee, Bluetooth,
Z-Wave) que integrado com a infraestrutura LAN atravs de um gateway de aplicao,
(ii) dispositivo conectado diretamente LAN (Ethernet/Wi-Fi), (iii) o dispositivo se co-
necta diretamente ao usurio (por exemplo rede celular, Wi-Fi).
Assim, essa questo de pesquisa subdividida em duas: QP3.1 comunicao interna e
QP3.2 comunicao externa. A Figura 11 mostra essa subdiviso utilizada neste MSL.
Figura 11 MSL - Comunicao Interna e Externa
Fonte: o Autor
Para compreender o que comunicao interna e externa preciso definir alguns

pontos nesta figura:
N - um ponto de coleta de dados, pode ser formado por um sensor ou pelo
conjunto sensor e controlador.
Destino - o destino dos dados obtidos pelo N, onde esses dados podem ser
acessados pelo usurio, atravs de uma nuvem de dados, tablets ou celulares.
Gateway - um dispositivo intermedirio geralmente destinada a interligar redes,
separar domnios de coliso, ou traduzir protocolos.
Comunicao interna - a comunicao entre:
- o sensor e o controlador dentro de um N;
- um N e o Gateway do sistema;
- Ns que formam uma WSN.
Comunicao externa a comunicao entre um N e o destino, ou entre um
Gateway e o destino.
QP3.1 - Comunicao Interna ou LAN.
Neste MSL em 4 artigos no foi possvel computar a forma de comunicao interna.
A Figura 12 mostra a sntese dos resultados desta subquesto de pesquisa.
Figura 12 MSL - Comunicao Interna por Artigos
Fonte: o Autor
Uma forma empregada de comunicao em SGRH a comunicao direta entre os Ns

e o Gateway, sendo usado em 23% dos trabalhos vlidos. Neste modelo o sensor plugado
diretamente ao controlador, o qual possui alguma forma de comunicao com o destino.
Verificou-se tambm que, Bluetooth e Wi-Fi so duas tecnologias tambm usadas em
SGRH. Nesta pesquisa, ambas as tecnologias foram usadas em 8% dos trabalhos vlidos.
Por fim, neste MSL verificou-se que Zigbee a tecnologia mais empregada para realizar
a comunicao interna em SGRH, sendo usada em 57% dos trabalhos vlidos, isso se deve
principalmente ao seu baixo consumo de energia.
QP3.2 - Comunicao Externa ou WAN.
a comunicao usada entre N ou Gateway e o destino. A Figura 13 mostra uma
sntese das tecnologias encontradas neste MSL.
Apesar de ser uma das tecnologias mais antigas, GSM a forma de comunicao mais
empregada nos SGRH, sendo usada em 11 trabalhos vlidos. Como se v na Figura 13 (a),
somando os trabalhos que usam as tecnologias GSM ou GPRS tem-se quase metade dos
trabalhos vlidos. Outra forma bastante empregada a ligao cabeada entre o Gateway
e a Internet atravs do padro Ethernet, sendo usado em 24% dos trabalhos.
Figura 13 MSL - Comunicao Externa
(a) Comunicao Externa por Artigos (b) Comunicao Externa por Ano
Fonte: o Autor
Figura 14 MSL - Sensores
(a) Tipos de Sensores (b) Sensores e Tecnologias por Categoria

Fonte: o Autor
Uma tcnica que est sendo empregada recentemente usar o smartphone como Ga-
teway. Neste MSL essa forma de comunicao foi chamada de diversa, por usar todas as
tecnologias de comunicaes disponveis nestes aparelhos, podendo ser GSM, GPRS, 3G,
4G e Wi-Fi. Dois trabalhos vlidos usaram essa tecnologia em suas solues.
A Figura 13 (b) mostra o emprego das tecnologias ao longo dos anos. At 2014 apenas
tecnologias mais antigas foram usadas, GSM, GPRS e Ethernet. A partir de 2015 aparecem
tcnicas como o uso do aparelho celular como Gateway e tecnologias como 3G, 4G e Wi-Fi.
QP4 - Quais sensores so usados nestes sistemas?
A partir dos artigos selecionados foi possvel descobrir os principais sensores usados
em SGRH. A Figura 14 (a) enumera esses sensores.
Alm desses sensores, tambm so usadas tecnologias como cmera para os sistemas
de monitoramento de enchente e RFID em sistemas de suprimento de gua. A Figura 14
(b) mostra os sensores e as tecnologias usadas por categoria de SGRH.
QP5 - Quais tcnicas ou sensores so usados para medir volume de gua?
Em diversos campos relacionados gua, como os sistemas de aviso de pr-enchente
e sistemas de irrigao dados relativos ao nvel de gua so informaes fundamentais.
Figura 15 MSL - Tcnicas de medio de volume de gua
(a) Tcnicas de medio de volume de gua (b) Sntese das Tcnicas

Fonte: o Autor
Figura 16 MSL - Controladores usados em IoT
(a) Controladores empregados por artigo (b) Sntese dos Controladores usados
Fonte: o Autor
A Figura 15 mostra o resultado da extrao dos artigos selecionados nesse MSL quanto
s tcnicas e tecnologias usadas para medio do volume de gua. Dos 55 artigos seleci-
onados 23 artigos no usam sensor de nvel de gua, ou seja 58% dos artigos empregam
este tipo de sensor. Dos artigos que empregam sensor, 7 no descrevem a tecnologia usada
para obter o nvel de gua. Assim, resultaram 25 trabalhos vlidos.
Como mostra a Figura 15 (b) 60% dos artigos vlidos utilizam a tcnica de sensor
ultrassnico.
QP6 - Quais controladores so usados para desenvolver esses sistemas?
IoT usa diversas tecnologias emergentes, essas tecnologias utilizam recentes tcnicas
eletrnicas e incorporam computadores digitais embutidos baseados em microprocessado-
res para funes de controle, anlise e comunicao. Microcontrolador um dispositivo
em um nico circuito integrado o qual contm um ncleo de processador, memria e
perifricos programveis de entrada e sada.
A Figura 16(a) mostra o resultado da extrao de dados em busca dessa questo de
pesquisa. Essa no uma pergunta trivial de se responder, uma vez que diversos trabalhos
no descrevem o controlador usado no sistema proposto. Em 33% dos artigos selecionados
no foi possvel definir qual o controlador usado.
Figura 17 MSL - Formas de energia usadas em SGRH
(a) Formas de energia usadas por artigos (b) Sntese das formas de energia
Fonte: o Autor
Outra dificuldade a grande variedade de controladores usados para desenvolver

SGRH. Em 21 artigos so usados diversos controladores que aparecem em apenas um
nico trabalho.
Os controladores que merecem destaques so Arduino2 e Raspberry Pi3 . Este MSL
mostra evidncias que ambos controladores so os mais usados em SGRH, como mostra
a Figura 16(b), onde esses controladores aparecem em 26% e 19% dos artigos vlidos
respectivamente.
QP7 - Quais as formas de energia so empregadas nestes sistemas?
A forma de obteno de energia em SGRH uma questo importante uma vez que
muitos dos Ns nestes tipos de sistemas esto localizados em locais sem acesso a energia
externa, ou seja, energia fornecida por uma empresa de distribuio de energia eltrica,
ou em locais de difcil acesso para troca de bateria.
Neste MSL, dos 55 artigos selecionados 23 trabalhos declaram a forma de energia
empregada. Essa baixa porcentagem de resposta a essa pergunta se d principalmente
pelo fato de esse no ser o tema principal dos artigos selecionados. A Figura 17 (a) mostra
o resultado da extrao dos dados em busca da resposta a essa questo de pesquisa.
A Figura 17 (b) mostra a resposta da pergunta de pesquisa, considerando-se apenas
os artigos vlidos. A forma de energia externa tem apenas 7%, isso se deve principalmente
a dificuldade de obteno desse tipo de energia nestes sistemas. Apenas 3% dos sistemas
usam a forma de captao ou gerao de energia dentro do prprio sistema. Juntamente
com Bateria, a Energia Solar a forma de energia mais usada nesses sistemas, ambas
sendo usadas em 45% dos artigos vlidos.
QP8 Esses sistemas usam Computao em Nuvem?
Para responder a essa pergunta os trabalhos selecionados foram analisados em busca
da resposta a seguinte pergunta direta: se o trabalho usa ou no Computao em Nuvem
no SGRH proposto. Como se v na Figura 18 (a) apenas 27% dos trabalhos selecionados
2
https://www.arduino.cc/
3
https://www.raspberrypi.org/
Figura 18 MSL - Uso de Computao em Nuvem
(a) Uso de Computao em Nuvem por artigo (b) Uso de Computao em Nuvem por ano
Fonte: o Autor
usam o paradigma de computao em nuvem nos SGRH.

A Figura 18 (b) mostra o uso da Computao em Nuvem nos SGRH por ano. Nesse
MSL, constatou-se que o paradigma de computao em nuvem passou a ser usado nestes
sistemas apenas a partir do ano de 2015, onde 44% dos sistemas usaram esse paradigma.
3.2.3.3 Discusso dos Resultados
Com base nos resultados obtidos no MSL, a discusso dos resultados est dividida nos
seguintes temas:
a. Tecnologias de comunicao em SGRH;
b. Sensores usados em SGRH;
c. Tcnicas e sensores de nvel de gua;
d. Controladores usados em SGRH; e
e. Energia usada para alimentao dos Ns em SGRH.
a. Tecnologias de comunicao em SGRH

Segundo evidncias mapeadas neste MSL, para estabelecer a comunicao interna do
SGRH as tecnologias mais usadas so (i) Zigbee 57%, (ii) Bluetooth 8% e (iii) Wi-Fi 8%
dos trabalhos vlidos.
(i) Bluetooth
Bluetooth, especificado em IEEE 802.15.1, uma tecnologia bastante disseminada
atualmente, devido ao seu uso em celulares, laptops, computadores, fones de ouvido e
outros dispositivos. Bluetooth Low Energy (BLE) uma verso do Bluetooth, especifi-
cada na sua verso 4.0, de baixo consumo de energia. BLE permite diminuir os nveis
de consumo de energia em aparelhos que no precisam transmitir grandes volumes de
dados. Isso ocorre porque ele foi projetado para aplicaes que precisam enviar poucas
informaes e de forma espordica.
Bluetooth e BLE no so tecnologias concorrentes, uma vez que o foco principal do
BLE so aplicaes cujo gasto de energia seja mnimo, normalmente envolvendo apenas
informar um estado ou servir de gatilho, no abrangendo trfego contnuo de dados como

o caso da verso tradicional do Bluetooth.
(ii) Zigbee
Zigbee uma tecnologia especificada em IEEE 802.15.4 a fim de possibilitar um con-
trole seguro, de baixo custo e de baixa potncia em redes sem fio, incluindo solues para
a utilizao de redes de sensores. Seu principal atrativo o baixo consumo de energia. A
tecnologia de redes sem fio Zigbee, tem seus dispositivos operando nas faixas de 2,4GHz
(Global), 915Mhz (Amrica) e 868Mhz (Europa) e com taxas de transferncia de dados
de 250kbps, 40kbps e 20kbps respectivamente.
Dependendo da velocidade de conexo, o alcance de transmisso varia entre 10m e
100m, podendo chegar a mais, dependendo diretamente da potncia dos equipamentos e
de caractersticas ambientais, como obstculos fsicos e interferncia eletromagntica.
(iii) Wi-Fi
Wireless Fidelity (Wi-Fi), definido em IEEE 802.11, fornece comunicao ininterrupta
ao usurio em taxas de dados mais altas que Zigbee e BLE, porm sua principal desvan-
tagem em relao a esses o alto consumo de energia.
Os principais padres na famlia IEEE 802.11 so:
IEEE 802.11a: Frequncia 5 GHz com capacidade terica de 2 Mbps;
IEEE 802.11b: Frequncia 2,4 GHz com capacidade terica de 11 Mbps;
IEEE 802.11g: Frequncia 2,4 GHz com capacidade terica de 54 Mbps;
IEEE 802.11n: Frequncia 2,4 GHz e/ou 5 GHz com capacidade de 150 a 600 Mbps.
Comparao Zigbee, BLE e Wi-Fi
Quanto ao nmero mximo de dispositivos pertencentes a uma rede, o BLE pode ter
8 clulas contra 65.000 possveis com uma rede Zigbee e 2.007 para uma estrutura Wi-Fi.
Zigbee, foi projetado para ser uma alternativa de baixa potncia para Bluetooth, e de
fato oferece um desempenho significativamente melhorado de 30mW em comparao com
o 100mW do Bluetooth. Porm, com o surgimento do BLE, que consome em torno de
10% da energia consumida pelo Bluetooth, essas duas tecnologias tornaram-se atrativas
para uso em produtos portteis, sujeitos a curtos intervalos de uso. Por outro lado, Wi-Fi
projetado para uma conexo mais longa e necessita de dispositivos com uma fonte de
alimentao substancial.
Os trs protocolos aqui comparados possuem mecanismos de criptografia e autentica-
o para segurana da informao. O padro 802.15.4 requer o uso do algoritmo AES com
chaves e comprimentos de bloco de 128 bits. Da mesma forma que a especificao Zigbee,
a confidencialidade da sesso no BLE tambm fornecida pela criptografia AES.
b. Sensores de qualidade de gua usados em SGRH

A Portaria 2.914, de 12 de dezembro de 2011, do Ministrio da Sade, dispe sobre os
procedimentos de controle e de vigilncia da qualidade da gua para consumo humano e
seu padro de potabilidade. Ela estabelece os parmetros a serem medidos e controlados

para que a gua seja considerada prpria para o consumo humano.
No seu Art. 3 essa portaria diz que: "Toda gua destinada ao consumo humano, distri-
buda coletivamente por meio de sistema ou soluo alternativa coletiva de abastecimento
de gua, deve ser objeto de controle e vigilncia da qualidade da gua".
Neste MSL foram enumerados 18 tipos de sensores usados em SGRH. Acredita-se que
o emprego de um subconjunto dos sensores enumerados nas categorias Gerenciamento de
gua e Monitoramento de gua seja suficiente para a maioria dos projetos de SGRH.
c. Tcnicas e sensores de nvel de gua

Existem diversos sensores comerciais e propostos pela academia que se propem a
realizar a medio do nvel de gua e muitos fatores afetam a seleo desses sensores,
alguns deles so: qualidade, ambiente a ser usado, intervalo de medio, tempo de resposta
e custo do sensor (LOIZOU; KOUTROULIS, 2016).
Uma boa soluo para sistemas de medio em aplicaes de nvel de gua o uso de
sensores capacitivos. Nesta tcnica o nvel do lquido contido entre placas de metal altera
a capacitncia total do sensor. Devido grande variedade de materiais disponveis no
mercado, os sensores capacitivos de nvel de lquido podem ser de baixo custo e certificados
para contato com gua potvel.
As principais desvantagens da abordagem de tipo capacitivo so que ela pode ser
afetada por capacitncias parasitas e que o desempenho em longo prazo dos materiais de
construo devem ser testado (LOIZOU; KOUTROULIS, 2016). Alm disso, o material do
cabo usado para construir o sensor deve ser certificado em termos de higiene, a fim de ser
apropriado ao uso em tanques de armazenamento de gua potvel.
Atualmente, os sensores de ultrassons so os sensores de nvel de gua mais utilizados
em tanques de armazenamento de lquidos em grande escala, por serem no invasivos,
serem facilmente instalados e seu funcionamento no depender do tipo de lquido (KONS-
TANTINOS et al., 2015). Sensores ultrassnicos capturam ondas acsticas refletidas a partir
da superfcie da gua, onde o tempo de viagem de onda corresponde distncia entre a
superfcie da gua e o sensor.
No entanto, estes sensores apresentam a principal desvantagem de que as ondas sonoras
emitidas sobre a superfcie do lquido podem ser dispersadas, por exemplo, devido a
movimento do lquido ou a existncia de bolhas, o que pode resultar em erro de preciso.
d. Controladores usados em SGRH

IoT usa um controlador para funes de controle, anlise e comunicao, empregados
para controlar os sensores e as comunicaes dos sistemas. Neste MSL verificou-se uma
grande variedade de controladores usados em SGRH. Porm, duas plataforma de prototi-
pagem se destacaram: Arduino e Raspberry Pi, sendo usados em 26% e 19% dos trabalhos
vlidos respectivamente.
Figura 19 MSL - Caractersticas Arduino e Raspberry Pi
Fonte: Arduino4 e Raspberry Pi5
Arduino e Raspberry Pi so duas plataformas bem diferentes. Raspberry Pi um

computador totalmente funcional, enquanto o Arduino um microcontrolador. Enquanto
o Arduino uma plataforma especfica para desenvolvimento de projetos eletrnicos, o
Raspberry Pi um computador completo com sistema operacional, interface com usurio,
possibilidade de ligao de perifricos e afins. A Figura 19 mostra as principais caracte-
rsticas destas duas plataformas.
O preo e o tamanho dos dois dispositivos so praticamente as nicas semelhanas.
Raspberry Pi cerca de 40 vezes mais rpido no que diz respeito a velocidade de clock do
que o Arduino e possui 128.000 vezes mais memria RAM. O Raspberry Pi um com-
putador independente que pode executar um sistema operacional Linux. Essas vantagens
de configurao de hardware do Raspberry custam um consumo de energia quatro vezes
maior do que a do Arduino.
Enquanto o Raspberry Pi superior na aplicao de software, a simplicidade do Ar-
duino faz com que seja uma soluo mais adequada para projetos de hardware puro. O
Arduino tem uma capacidade de trabalho em tempo-real e analgico melhor que o Rasp-
berry Pi. Esta flexibilidade permite que o Arduino trabalhe com diversos tipos de sensores
ou chips, sendo o Arduino ideal para conduo de motores, leitura de sensores e tarefas
com LED.
e. Energia usada para alimentao dos Ns em SGRH

A forma de obteno de energia em SGRH importante uma vez que muitos dos
Ns nestes tipos de sistemas esto localizados em locais sem acesso a energia externa,
ou encontram-se em locais de difcil acesso para troca de bateria. Segundo esse MSL, as
formas de alimentao de energia mais usadas em SGRH so (i) Bateria 45%, (ii) Painel
de Energia Solar 45% e (iii) Energia externa 7% dos sistemas.
(i) Bateria
Conectar diretamente o controlador a uma bateria uma opo, porm possui o grande
inconveniente de que as baterias convencionais se esgotariam rapidamente ao fornecer
energia para esses sistemas.
Apenas para ilustrar, Ahamed et al. (2015) propuseram um Sistema de Aquisio de
Dados ECG Sem Fio, no qual para alimentao usado Bateria de 9V e 250 mAh, sendo
usado uma Placa Arduino, um Sensor e um mdulo Bluetooth para comunicao. Os com-
ponentes usados para esse sistema consomem aproximadamente 65mA. A bateria neste
sistema durou em torno de 22 horas de extrao contnua de dados de eletrocardiograma.
(ii) Painel de Energia Solar
A principal desvantagem do projeto alimentado por bateria que ele vai esgotar aps
certo tempo. Esta desvantagem pode ser eliminada usando recursos naturais como energia
solar. Os painis solares so dispositivos que convertem luz solar em energia eltrica.
As principais vantagens de usar painel solar so: uma fonte renovvel, energia limpa,
possui baixo custo de manuteno e pode ser usado em locais no atendidos por outras
fontes de energia. Suas desvantagens so: em dias de chuva ou com baixa incidncia de
sol diminui a gerao de energia e no perodo da noite no ocorre a produo de energia.
O estado da arte usar um painel solar para capturar energia, e ento usar uma
bateria para armazen-la. Assim, este dispositivo funciona como uma fonte de alimentao
de forma totalmente independente. Desta forma, o painel solar alimenta o dispositivo
durante o dia e a bateria fornece a energia durante a noite ou quando no h incidncia
solar suficiente.
(iii) Fonte Externa
Nesta soluo um adaptador usado para converter a energia eltrica fornecida por
companhias especializadas em alimentao para os dispositivos.
A opo com energia externa oriunda de uma rede convencional de energia possui a
vantagem de ser uma fonte constante de energia e de baixo custo. Porm essa soluo
possui o inconveniente de ter cabos eltricos saindo da fonte at o N, o que em alguns
casos podem chegar a dezenas de metros.
3.2.3.4 Sntese do Mapeamento Sistemtico da Literatura
Sintetizando este mapeamento, a Figura 20 apresenta as tecnologias, padres e tendn-

cias dos SGRH descobertos no MSL, dispostos por camadas do modelo de arquitetura
IoT. Na primeira linha de componentes tm-se as categorias de SGRH, sendo essa a Ca-
mada de Negcio, a partir da, a figura se desenvolve nas demais camadas: Aplicao,
Processamento, Rede e Percepo.
Uma possvel leitura desta figura : Gerenciamento de gua uma categoria dos
SGRH, o qual possui obrigatoriamente uma aplicao que pode ser web, mobile ou os
dois; esses sistemas possuem obrigatoriamente uma tecnologia de comunicao externa,
onde as tecnologias que se destacaram foram GPRS e GSM; esses sistemas podem ter um
Gateway para realizar a comunicao externa; esses sistemas podem fazer uso do para-
digma da Computao em Nuvem; todos os sistemas de gerenciamento de gua devem
possuir N; esses Ns precisam obrigatoriamente de uma tecnologia de comunicao in-
terna, onde Zigbee o padro de fato; os Ns devem usar um ou mais Controladores para
coordenar as leituras dos sensores e as comunicaes; todos os Ns precisam obrigatoria-
Figura 20 Sntese do Mapeamento Sistemtico da Literatura
Fonte: o Autor
mente de Sensores, o sensor mais usado o sensor de nvel de gua, e a tecnologia mais
empregada para esse tipo de sensor a tecnologia ultrassnica; por fim, todo N precisa
de alimentao eltrica e essa alimentao pode ser por Bateria, Painel Solar, energia
Externa ou uma combinao destes.
3.2.4 Resumo da Seo

Esta seo apresentou o MSL das tcnicas e tecnologias usadas nos SGRH. A partir deste
MSL pde-se chegar a diversas concluses que serviro de escopo inicial e referencial
terico para o desenvolvimento deste trabalho.

Este captulo na seo 3.1 descreveu o resultado da anlise de como o programa de distri-
buio de gua no Semirido brasileiro funciona e emprega a TI em seu apoio e apresentou
na seo 3.2 o estado da arte de SGRH que empregam IoT atravs de um MSL.
No prximo captulo ser apresentada a Arquitetura Proposta como soluo do pro-
blema de pesquisa desta dissertao.
55
4 Arquitetura Proposta
Este captulo tem por objetivo apresentar a Arquitetura Proposta para soluo do pro-
blema de pesquisa desta dissertao. Para isso na seo 4.1 so apresentados um conjunto
de requisitos fundamentais a serem atendidos pela arquitetura. A seo 4.2 define o mo-
delo de arquitetura IoT usado, descrevendo as tecnologias empregadas em cada camada
da arquitetura. Por fim, a seo 4.3 apresenta a especificao da arquitetura de software,
detalhando as Camada de Aplicao e Camada de Negcio e validando a AS especificada.
4.1 Requisitos para Arquitetura Proposta

Dos resultados obtidos da metodologia aplicada na seo 3.1 foi possvel elicitar os princi-
pais requisitos necessrios para o desenho de uma Arquitetura Proposta para um SGRH
para a regio semirida do Brasil.
Os requisitos tratados nesta soluo no formam um conjunto completo e fechado de
funcionalidades que devem sempre estar presentes em qualquer arquitetura para SGRH.
Contudo, acredita-se que os requisitos identificados podem servir como base para a im-
plementao de uma arquitetura para o problema de pesquisa.
Assim, para definir uma arquitetura que cubra as necessidades atuais e futuras nos
SGRH, foram identificados os seguintes requisitos:
Req #1: Mnima interao do usurio
Como visto na seo 3.1.4, um dos principais problemas relatados no atual modelo de
distribuio de gua a grande quantidade de interao humana no processo. Assim, a
arquitetura deve atender aos requisitos do sistema com o mnimo envolvimento do usurio.
Req #2: Interoperabilidade
Interoperabilidade a capacidade de um sistema se comunicar de forma transparente
com outro. A infraestrutura de gesto da gua atualmente implantada consiste em muitos
processos interligados que devem ser geridos utilizando sistemas legados. Substituir esses
sistemas por novos no sempre uma soluo vivel. Assim, a arquitetura deve apoiar a
integrao com sistemas legados.
Req #3: Eficincia Energtica
Em SGRH os Ns podem ficar em locais de difcil acesso a energia externa conven-
cional, precisando ser alimentado por outras fontes, como bateria, por exemplo. Como a
quantidade de Ns da ordem de dezenas de milhares, caso esse requisito no seja levado
em considerao o consumo de energia pode inviabilizar o projeto, devido principalmente
a dificuldade da gerncia do funcionamento destes Ns.
Captulo 4. Arquitetura Proposta 56
Req #4: Ubiquidade/Mobilidade

Este termo corresponde a qualquer tecnologia mvel capaz de capturar informaes
sobre o ambiente ou atuar sobre ele (SANCHEZ, 2011). Ao considerar que o nmero de
smartphones em uso no Brasil chegou a 168 milhes em maio de 2016 (MEIRELLES, 2016),
natural associar ubiquidade ao uso destes dispositivos e us-los em solues de SGRH.
Req #5: Segurana
Devido natureza do sistema proposto, que trabalha com um valor monetrio consi-
dervel e gera dados sensveis administrao pblica, no admissvel que a arquitetura
no satisfaa este requisito. Todo dado deve ser protegido fazendo uso das polticas de
privacidade e segurana, tanto em relao disponibilidade quanto ao armazenamento.
Req #6: Geolocalizao
Como visto na seo 3.1, o sistema atual faz uso direto de informaes georreferen-
ciadas tanto para monitoramento das entregas como para a localizao dos Mananciais
e PAbsts. Neste sentido, a arquitetura proposta deve empregar tecnologias e tcnicas de
geolocalizao para manter essas funcionalidades.
Req #7: Disponibilidade
Para permitir o fornecimento de informaes contextualizadas a arquitetura deve ser
altamente disponvel. Para isso, a arquitetura deve implementar diversos requisitos, entre
eles: acomodar o crescimento da rede, aplicaes e servios de IoT; permanecer operacional
mesmo na presena de falhas; e estar disponvel em todos os momentos. Esse requisito
tambm se aplica aos Ns, os quais devem est disponvel, se no a todo momento, pelo
menos em horrios predeterminados.
Req #8: Flexibilidade/Extensibilidade
O sistema deve fornecer uma arquitetura flexvel e extensvel permitindo a integrao
de diferentes sistemas baseados em tecnologias especficas. A arquitetura deve ser inde-
pendente de padres especficos de hardware e software a fim de permitir a insero de
novos servios e ser capaz de adaptar-se a novos requisitos.
Req #9: Baixo custo
Tendo em vista que o sistema proposto trabalha com diversos Ns, atualmente com
mais de 65 mil PAbsts, caso as tecnologias e dispositivos empregados na soluo no sejam
economicamente viveis, o custo pode inviabilizar o projeto. Assim, este requisito deve
ser observado em todo projeto, de forma a mant-lo o mais econmico possvel.
Req #10: Adequao aos modelos atuais de distribuio de gua
O sistema deve seguir algumas caractersticas e particularidades dos modelos atuais de
distribuio de recursos hdricos empregados na regio de semirido do Brasil, devido a
fora de lei e investimentos j realizados. No propondo, por exemplo, novos modelos de
negcios ou de logstica. Em resumo, este requisito certifica que o sistema proposto deve
alterar o mnimo possvel os modelos de distribuio de gua empregados atualmente na
regio em que for aplicado.
4.1.1 Resumo da Seo

Elicitados os principais requisitos necessrios para o desenho de uma arquitetura proposta
para um SGRH em regies semiridas brasileira, na prxima seo ser apresentada a
arquitetura de IoT da soluo proposta que visa atingir estes requisitos.
4.2 Especificao da Arquitetura IoT

Nesta seo ser definido o modelo de arquitetura IoT que ser usado neste trabalho.
Depois sero apresentadas as camadas da arquitetura proposta, analisando opes que
podem ser usadas para implementar essa arquitetura.
Para definir as tecnologias e tcnicas mais adequadas para implementar a arquitetura
proposta foram levados em considerao os resultados do MSL realizado na seo 3.2, as
caractersticas da regio onde ser implantado o SGRH e os requisitos elicitados na seo
4.1. O objetivo montar uma prateleira com opes de tecnologias e tcnicas que podem
ser usadas para implementar a arquitetura proposta neste trabalho.
4.2.1 Definio do Modelo de Arquitetura IoT Empregado

Arquiteturas so necessrias para representar, organizar e estruturar a IoT de uma forma
que lhe permita funcionar de maneira eficiente e eficaz (WHITMORE et al., 2015). Uma srie
de artigos propem vrios projetos de arquitetura conceitual para atender aos requisitos
de aplicaes em IoT (KORTUEM et al., 2010). Essa diversidade de projetos destaca a
importncia da questo da definio da arquitetura a ser empregada (WHITMORE et al.,
2015). Porm, pesquisas em IoT ainda esto em sua fase infantil, e, portanto, no h um
modelo de arquitetura IoT nico e consensual (MASHAL et al., 2015).
Do ponto de vista do modelo de arquitetura, a estrutura em camadas dos sistemas
IoT bastante adotada por frameworks e projetos de pesquisa (KRCO; POKRIC; CARREZ,
2014; CHAQFEH; MOHAMED, 2012). No modelo de arquitetura o nmero de camadas e
seu escopo so definidos dependendo das infraestruturas, tecnologias e tipos de sistemas
de IoT. Como a escalabilidade e a interoperabilidade tm uma grande importncia em
aplicaes IoT, definir a arquitetura com melhores abstraes pode facilitar essas questes
(MASHAL et al., 2015).
Assim, da anlise da reviso da literatura de modelos de arquitetura de IoT conclui-se
que:
ainda no h uma arquitetura padro para IoT (MASHAL et al., 2015);
a integrao entre IoT e Computao em Nuvem uma opo vivel para facilitar
o desenvolvimento de aplicativos de IoT (SUCIU et al., 2014); e
que o modelo de arquitetura em cinco camadas interage bem com a Computao em
Nuvem (SUCIU et al., 2014), sendo o mais empregado em projetos de IoT (MASHAL
et al.,
2015).
Desta forma, existem evidncias que o modelo de arquitetura de IoT em cinco camadas
integrado com a Computao em Nuvem um modelo vivel para o desenho da arquitetura
proposta neste trabalho. A Figura 21 mostra o modelo de Arquitetura IoT usado neste
trabalho.
Figura 21 Modelo da arquitetura IoT
Fonte: o Autor
Definido o modelo de arquitetura IoT que ser usado, nas prximas subsees sero
apresentadas as camadas desta arquitetura, propondo opes de tecnologias que podem
ser usadas para implementao da arquitetura.
4.2.2 Camada de Percepo

Tipicamente um N de uma WSN possui 4 unidades principais, conectadas entre si: uni-
dade de sensor, unidade de processamento, unidade de comunicao e unidade de alimen-
tao (CHEN; YEN-KUANG, 2012). A Figura 22 mostra a interao destas unidades.
Figura 22 Unidades de um N IoT
Fonte: Partynski e Koo (2013)
Para a montagem da prateleira da Camada de Percepo, sero analisadas as tecno-

logias e tcnicas disponveis para essas quatro unidades, obtidas atravs dos resultados
do mapeamento sistemtico realizado na seo 3.2, a fim de propor opes que possam
atender aos requisitos do projeto.
4.2.2.1 Unidade de Medio
Consiste dos sensores para medir os valores fsicos. Nesta arquitetura so usados sensores
para medir o volume de gua entregue e sua qualidade. Assim, segundo o MSL, as opes
de sensores para essa arquitetura so:
Sensor de Nvel de gua
Segundo o MSL, as tcnicas mais empregadas neste tipo de sensor so capacitivos e
ultrassnicos. Loizou e Koutroulis (2016) afirmam que o sistema de medio de nvel de
gua capacitivo alcana desempenho equivalente ao de um dispositivo de deteco de nvel
de gua de ultrassom comercialmente disponvel e possui um custo de fabricao menor.
Porm, para utilizao de sensores de nvel de gua para grandes projetos de SGRH
a compra de um modelo comercial de sensor ultrassnico pode ser a mais recomendada,
devido ao custo deste tipo de sensor ser relativamente baixo e ser uma soluo padro de
mercado, j bastante usada e experimentada em projetos de grande porte.
Sensor de Qualidade da gua
Nessa pesquisa no foi encontrado um nico sensor de qualidade de gua que abranja
todos os parmetros estabelecidos pela Portaria 2.914 do Ministrio da Sade, que rege
as normas para que uma gua seja considerada prpria para consumo humano. O MSL
realizado na seo 3.2 enumera os principais sensores usados em SGRH nas categorias de
Gerenciamento de gua e Monitoramento de gua. O emprego de um subconjunto desses
sensores deve ser suficiente para a maioria dos projetos de SGRH.
Essa enumerao serve como um ponto de partida, devendo cada caso ser analisado
e adequado sua realidade. No caso do Semirido brasileiro, muitos mananciais, sem
tratamento, apresentam guas enlameadas e salobras (PADILHA et al., 2004) o que leva a
necessidade de sensores de turbidez e salinidade, por exemplo.
4.2.2.2 Unidade de Processamento
O microcontrolador o principal elemento desta unidade. Como visto no MSL as principais

escolhas para esse mdulo so Arduino e Raspberry Pi. Arduino uma melhor escolha
para projetos mais simples que trabalham principalmente com hardware, enquanto que
Raspberry Pi mais recomendado para trabalhos mais complexos, que exija mais de
hardware e software e possua diversas tarefas.
Devido relativa simplicidade dos Ns usados neste projeto de SGRH, onde a unidade
de processamento usada basicamente para controlar a leitura e a comunicao interna
dos sensores, acredita-se que a melhor escolha para esse projeto pode ser a plataforma
Arduino. Outro fator que leva a essa recomendao o seu menor consumo energtico,
cerca de 4 vezes menor que Raspberry Pi.
4.2.2.3 Unidade de Alimentao
A energia hidreltrica, ainda no chega a todos os locais do Semirido brasileiro. Alm

disso, utilizar cabos eltricos que podem atingir dezenas de metros talvez no seja a melhor
escolha para um projeto de IoT.
Usar bateria tem o inconveniente da necessidade da troca constante de baterias des-
carregadas ou a necessidade de recarreg-las, aumentando o custo de manuteno. Essa
desvantagem fere diretamente os requisitos Req #3: Eficincia Energtica, Req #7: Dis-
ponibilidade e Req #9: Baixo custo.
No Brasil, a insolao satisfatria durante todo ano, principalmente na regio a ser
implantado o SGRH (PADILHA et al., 2004). As principais desvantagens enumeradas pela
literatura quanto ao uso de painel solar so: a no gerao de energia durante a noite
e seu custo. A primeira resolve-se com a utilizao de bateria recarregvel alimentada
pelo painel solar. Quanto segunda, existem diversas solues no mercado com baixo
custo, por exemplo, um mdulo Painel Solar 5.5v 1.6w 266mA, capaz de alimentar uma
plataforma Arduino, custa em torno de $10 1 .
Para este trabalho recomenda-se que a melhor opo para alimentar um N painel
solar, devido ao baixo custo de aquisio e manuteno e da abundncia de incidncia
solar nesta regio.
4.2.2.4 Unidade de Comunicao
A fim de avaliar quais as tecnologias para comunicao interna mais se adequam ao

SGRH proposto, foi criada uma matriz de trs dimenses, que consiste dos requisitos da
Arquitetura de Proposta do SGRH versus as principais caractersticas das trs tecnologias
mais usadas para comunicao interna em SGRH (elicitados do MSL) versus a Avaliao
da Tecnologia, essa matriz apresentada no Apndice B.
Os requisitos avaliados nesta matriz foram: Req #3: Eficincia Energtica, Req #5:
Segurana, Req #4: Ubiquidade/Mobilidade e Req #10: Adequao aos modelos atuais de
distribuio de gua. Atribudos os seguintes conceitos: A - Atende Completamente, B -
Atende Satisfatoriamente e C - No Atende.
Para essa avaliao foi empregada uma equipe formada por um Doutor em Engenharia
de Telecomunicaes, um Doutor e um Mestre em Segurana da Informao, um Mestre
em Engenharia Eltrica e dois Especialista de Negcio (Analistas do GCDA). Aps uma
rpida explanao dos requisitos do negocio, esses especialistas analisaram as caracters-
ticas e ento fizeram a atribuio dos conceitos.
Para obter-se o resultado final do conceito de cada tecnologia de comunicao desta
matriz foi empregado o critrio do conceito mais baixo. Neste critrio o conceito do Re-
quisito o conceito mais baixo daquele conjunto de caractersticas da tabela. O resultado
1
http://produto.mercadolivre.com.br/MLB-808486920-painel-solar-55v-16w-266ma-diy-arduino-
energia-carregador-_JM Acessado em 12/09/2016
Tabela 2 Resultado da avaliao dos protocolos de comunicao
Req # Requisito Bluetooth Zigbee BLE Wi-Fi

Req #3 Consumo Energtico C A A C
Req #4 Ubiquidade/Mobilidade A C B A
Req #5 Segurana B B B B
Req #10 Adequao aos modelos atuais B B B B
Resultado Final C C B C
Fonte: O Autor
final da tecnologia resulta do conceito mais baixo atribudo a ela. A Tabela 2 sintetiza o
resultado desta avaliao.
Como visto na Tabela 2, as tecnologias Bluetooth e Wi-fi no atenderam ao requisito
Req #3: Consumo Energtico. J a tecnologia Zigbee no atendeu ao requisito Req #4:
Ubiquidade/Mobilidade por no estar presente nos smartphones atuais. Sendo assim, a
tecnologia que melhor atendo aos requisitos do sistema proposto Bluetooth Low Energy.
importante salientar que as tecnologias disponveis neste campo avanam rapida-
mente e h necessidade de avaliao e comparao contnuas de suas caractersticas.
4.2.3 Camada de Rede

IoT um paradigma onde as coisas so capazes de obter dados ou informaes do mundo
fsico real. A Camada de Rede coleta os dados percebidos por essas coisas e envia para
a Internet. Essas coisas podem ser conectadas diretamente Internet usando tecnologias
sem fio, como por exemplo GPRS, 3G, 4G, Wi-Fi ou atravs de um gateway.
A conexo direta Internet usando a conexo sem fio por rede celular (GPRS/3G/4G)
so geralmente solues caras, uma vez que esse tipo de conexo requer assinatura com
uma operadora de rede celular. Se todos os Ns de um grande sistema IoT usarem rede
celular, o custo dos Ns poder inviabilizar sua implantao (SEOL et al., 2015).
Outro problema a ser observado quanto a cobertura das redes celulares. Segundo
a Telecom (2016), mais de 1,5 mil municpios do Brasil so atendidos por apenas uma
operadora de celular e a maioria destes municpios encontram-se no Semirido brasileiro.
Essa regio no um mercado atraente para a entrada de outras prestadoras, podendo
haver, assim, diversos Ns sem cobertura celular, por falta de interesse das operadoras.
Outro risco ligado a esse problema o fato da necessidade de se ter contrato com vrias
operadoras, o que aumentaria os custos e a complexidade administrativa do projeto.
Assim, por essas caractersticas citadas acima, acredita-se que a ligao direta dos Ns
com a Internet no uma boa opo para esse trabalho, sendo necessrio um gateway
para essa conexo.
4.2.3.1 Gateway Mvel para IoT
Um dispositivo de gateway para IoT responsvel por permitir a conectividade entre a

Rede de rea Local (LAN) dos sensores e a Rede de Longa Distncia (WAN). Esses dispo-
sitivos tambm podem implementar funes relacionadas segurana, realizar descoberta
dos dispositivos e seus servios e servir como dispositivo de Fog Computing.
Fog Computing um paradigma que consiste na alocao do poder de processamento
para mais perto do limite da rede. Tambm por vezes denominado de Edge Computing,
Fog Computing amplia o paradigma da Computao em Nuvem at a borda da rede,
possibilitando assim uma nova gerao de aplicaes e servios (BONOMI et al., 2012). A
Fog Computing adiciona uma camada a mais de poder de computao entre o n e a
nuvem, mantendo a anlise crtica mais prxima do dispositivo. Desta forma, dispositivos
individuais se tornam ns de processamento que podem lidar com tarefas menores, sem
ter que enviar todos os seus dados at a nuvem (BONOMI et al., 2012).
O conceito de usar um dispositivo mvel como gateway, sendo esse um N intermedirio
para coletar e processar dados de sensores vizinhos abordado por Wu, Talwar e Johnsson
(2011) e Zhang, Yu e Xie (2011). Ambos os trabalhos argumentam que a conexo de
dispositivos atravs de um gateway deve ser preferida quando os projetos so sensveis ao
custo ou consumo energtico.
A ideia de usar um smartphone para enviar dados de sensores para a Internet surgiu
h alguns anos. Uma das primeiras abordagens em smartphone usados como um gateway
mvel e autnomo de servio apresentada em Golchay et al. (2011). Neste trabalho os
autores propem uma abordagem de middleware orientado a servios onde os smartphones
fornecem servios de gateway para preencher a lacuna existente entre os servios IoT e
os servios em nuvem. Pereira e Aguiar (2014) estudaram a viabilidade dos smartphones
como gateways. Entre suas concluses est que hoje em dia, as redes celulares oferecem
reas de ampla cobertura, alta taxa de dados e latncia decrescente e, portanto, so um
facilitador chave das comunicaes Machine-To-Machine (M2M).
Os smartphones esto cada vez mais presentes no dia-a-dia do brasileiro. De acordo
com dados da 27 Pesquisa Anual de Administrao e Uso de Tecnologia da Informao
nas Empresas, realizada pela Fundao Getlio Vargas (FGV-SP) (MEIRELLES, 2016), o
nmero de aparelhos smartphones em uso no Brasil chegou a 168 milhes em maio de
2016. Segundo a pesquisa, a projeo que, at 2018, o nmero de smartphones chegue a
236 milhes, mais de um aparelho por habitante.
Como na maioria dos casos esses aparelhos possuem capacidade significativa de arma-
zenamento e computao, so equipados com tecnologias de comunicao Wi-Fi, Blueto-
oth ou BLE, redes celulares, GPS e sensores embutidos (LAINE et al., 2014), eles esto se
tornando os candidatos ideais para coletar, processar e encaminhar dados provenientes de
dispositivos IoT.
4.2.3.2 Definio da Camada de Rede da Arquitetura Proposta
Dos fatos descritos acima, conclui-se que nesta arquitetura, a comunicao entre os Ns e
a Internet exige um gateway, uma vez que nos locais dos Ns pode no haver conectividade
WAN e essas duas redes podem trabalhar com padres diferentes, Bluetooth e rede celular,
por exemplo. Como os dispositivos nos Ns apresentam restries de recursos, o gateway
tambm responsvel por diversas tarefas extras de armazenamento e processamento.
Assim, baseado na reviso da literatura e nas caractersticas da regio onde ser empre-
gado o SGRH, tem-se evidncias que os smartphones so a escolha ideal para desempenhar
o papel de um gateway mvel neste trabalho, uma vez que esto largamente disponveis
para a populao, so menos limitados que os dispositivos utilizados nos Ns e possuem
vrias alternativas de conectividade.
4.2.4 Camada de Processamento

A Computao em Nuvem a tecnologia primria desta camada. Este paradigma usado
em prol da IoT fornece um ambiente onde uma grande variedade de servios de hardware
e software so construdos com base nos conceitos de escalabilidade e elasticidade, permi-
tindo que programadores de aplicaes de IoT possam trabalhar com objetos heterogneos
sem considerar uma plataforma especfica, formando assim o conceito de plataforma de
mediao de dados para IoT, tambm referenciado como middleware.
Atualmente existe uma grande variedade de solues de plataformas de mediao de
dados para IoT e selecionar qual a plataforma mais apropriada para uma necessidade
especifica no e uma tarefa trivial. Assim, essa subseo pretende propor um guideline
para a seleo de uma plataforma de mediao de dados a ser usado na Camada de
Processamento em projetos de SGRH.
4.2.4.1 Plataformas de Mediao de Dados de IoT
Uma plataforma de mediao de dados de IoT tem como principal objetivo conectar
e unificar objetos e sistemas heterogneos, permitindo a coleta e o processamento de
informaes em larga escala (ATZORI; IERA; MORABITO, 2010).
No h um consenso sobre as melhores plataformas de mediao de dados para IoT,
uma vez que cada plataforma tem seu foco e caractersticas especficos. Agustin (2017)
analisou os resultados de uma pesquisa produzida pela comunidade de hardware Hackster2
para identificar quais plataformas de IoT os fabricantes e os desenvolvedores de sistemas
IoT preferem. Essa pesquisa coletou 3.319 respostas em 104 pases no ano de 2016. Esse
projeto foi realizado em colaborao com 25 das maiores empresas de tecnologia do mundo.
A Figura 23 mostra o resultado desta pesquisa.
2
https://www.hackster.io/survey
Figura 23 Principais Plataformas IoT
Fonte: (AGUSTIN, 2017)
Os resultados revelaram que o grupo permanece dividido, porm os grandes nomes

na tecnologia lideram essas escolhas. O Microsoft Azure para o IoT e o Amazon AWS
para o IoT foram nomeados por cerca de um quarto dos entrevistados cada, seguidos pelo
Google Cloud para o IoT com cerca de 15%. 11% dos entrevistados ainda preferem no
usar uma plataforma IoT e construir seu prprio banco de dados e aplicativo dentro de
seu prprio servidor de nuvem.
4.2.4.2 Reviso da Literatura de Plataformas de Mediao de Dados para IoT
Como visto acima, existem diversas plataformas de mediao de dados para IoT, assim
essa reviso da literatura tem por finalidade buscar insights para montar um guideline
para a seleo de uma plataforma a ser usada na Camada de Processamento em projetos
de SGRH. Para a realizao desta reviso foram analisados trabalhos secundrios sobre
plataformas de mediao de dados para IoT, uma vez que esses trabalhos catalogam,
analisam e comparam essas plataformas.
Os trabalhos secundrios foram selecionados em busca automtica e empregando a
tcnica snowball. Para a busca automtica foram usados os mesmos engenhos de busca
empregados na seo 3.2. A string de busca genrica usada para essa pesquisa foi a se-
guinte: String de Busca 2: (("systematic mapping"OR "systematic literature review"OR
literature review OR survey) AND ("IoT platform"OR "IoT platforms"OR "Internet of
Things platform"OR "Internet of Things platforms"OR "IoT middleware"OR "Internet of
Things middleware")).
Ao final da busca e da seleo dos trabalhos relevantes para essa reviso foi empre-
gada a tcnica snowball nos artigos selecionados, chegando a um total de 7 trabalhos
Tabela 3 Trabalhos secundrios sobre Plataformas IoT
Autor #Plataformas O que analisa

Levantamento das lacunas a
Mineraud et al. (2016) 37
serem preenchidas
Questes relacionadas ao modelo
Silva et al. (2015) 35
de dados utilizado
Viso geral sobre os middleware
Fersi (2015) No cita
mais conhecidos
Suporte a mltiplos elementos
Mazhelis (2014) 12
de aplicao
Viso geral das solues
Khler et al. (2014) 6
disponveis
Um breve resumo sobre cada
Balamuralidhar et al. (2013) 10
uma das plataformas
Resumo sobre cada uma das
Castro et al. (2012) 10
plataformas
Fonte: O Autor
para anlise. Vale ressaltar que esta reviso no se trata de uma Reviso Sistemtica da
Literatura, logo no goza de todo o rigor desta metodologia.
A Tabela 3 relaciona os trabalhos secundrios selecionados, apresentando os autores,
o ano da publicao, a quantidade de plataformas analisadas e o que o trabalho analisa
nessas plataformas.
Da anlise desses trabalhos secundrios, foram catalogados: (i) Os principais servios
que devem ser fornecidos por uma Plataforma IoT; e (ii) As caractersticas desejveis em
uma Plataforma de IoT. Esses servios e caractersticas so apresentados nas tabelas 4 e
5, respectivamente, e suas descries no Anexo C.
Tabela 4 Servios desejveis em uma Plataforma de IoT
# Servio
1 Servios de Gerenciamento de Dispositivos
2 Servios de Sensores
3 Servios de Armazenamento
4 Servios de Analytics
5 Visualizao dos dados dos Sensores
Fonte: O Autor
Tabela 5 Caractersticas desejveis em uma Plataforma de IoT
# Caracterstica # Caracterstica
1 Descoberta de recursos 2 Gerenciamento de recursos
3 Gesto de dados 4 Gerenciamento de Eventos
5 Gerenciamento de cdigo 6 Escalabilidade
7 Tempo real ou oportunidade 8 Confiabilidade
9 Disponibilidade 10 Mobilidade
11 Segurana e privacidade 12 Proviso de Abstrao
13 Facilidade de implantao 14 Popularidade
15 Abstrao de Programao 16 Interopervel
17 Baseado em servios 18 Adaptativo
19 Context-aware 20 Autnomo
21 Distribudo
Fonte: O Autor
4.2.4.3 Guideline para Seleo da Plataforma IoT
Esse guideline baseia-se na ESBE, onde a tomada de deciso fundamenta-se na anlise de

estudos secundrios.
As plataformas de mediao de dados em IoT, embora possam variar de acordo com os
seus objetivos, possuem um conjunto de requisitos essenciais para viabilizar a integrao e
processamento de dados (ZHOU, 2012). Um compilado desses requisitos so apresentados
nas Tabelas 4 e 5.
Como visto, existem diversos trabalhos cientficos voltados a pesquisar e comparar as
diversas Plataformas de IoT atravs de surveys e Revises Sistemticas da Literatura.
Esses trabalhos podem ser usados para auxiliar na escolha da Plataforma a ser empre-
gada, uma vez que: enumeram as principais Plataformas de IoT disponveis; elencam suas
principais caractersticas; e comparam essas Plataformas sobre uma determinada tica.
Este trabalho propem a seguinte sequncia para a seleo da Plataforma IoT a ser
usada na Camada de Processamento para um projeto de SGRH, mostrados na Figura 24.
Figura 24 Guideline para seleo da Plataforma IoT
Fonte: o Autor
Etapa 1. Selecionar os requisitos - Para selecionar os requisitos desejveis para a

plataforma de mediao de dados, deve-se:
Usar as Tabelas de Requisitos (4 e 5) e selecionar os requisitos desejados; E
Adicionar requisitos especficos, no elencados na Tabela de Requisitos, com base
nos requisitos do sistema a ser construdo. Por exemplo, suporte a linguagem de
programao especfica, custo financeiro da plataforma, tipo de licena, etc.
Confeccionar o documento de requisitos desejveis.
Etapa 2. Selecionar a Reviso Sistemtica - De posse do documento de requisitos
desejveis, selecionar o trabalho secundrio que melhor analisa os requisitos desejveis:
Realizar uma pesquisa nos engenhos de busca, cientficos ou no, a procura de tra-
balhos secundrios que melhor atendam s necessidades do pesquisador. Um ponto
de partida para essa busca pode ser a string de busca realizada para esta reviso da
literatura (subseo 4.2.4.2), chamada de String de Busca 2.
Etapa 3. Selecionar a Plataforma - A ltima etapa deste guideline selecionar a
plataforma a ser usada. Para isso deve-se:
De posse do trabalho secundrio selecionado e do documento de requisitos desejveis,
analisar o referido estudo secundrio para selecionar qual a plataforma que melhor
atende aos requisitos do sistema IoT a ser implantado.
No foram encontrados requisitos especficos em SGRH que diferenciem a Camada
de Processamento em relao a outros sistemas. Sendo assim, o emprego deste guideline
aplica-se normalmente para esses tipos de sistemas.
4.2.5 Resumo da Seo

Nesta seo foi definido o modelo de arquitetura IoT usado neste trabalho, sendo esse em
cinco camadas usando Computao em Nuvem como Camada de Processamento e tendo
um smartphone como gateway mvel. A partir da, foram apresentadas as camadas de
IoT desta arquitetura. A Figura 25 apresenta a arquitetura empregada.
Figura 25 Arquitetura IoT empregada
Fonte: o Autor
Na prxima seo sero apresentadas as camadas de software desta arquitetura, sendo

essas: Camada de Aplicao e Camada de Negcio, onde ser analisada a AS empregada
neste trabalho.
4.3 Especificao da Arquitetura de Software

Baseado nas demandas e requisitos elicitados na seo 4.1, esta seo prope uma AS
que disponibiliza servios para orquestrar a distribuio de gua no Semirido brasileiro.
O foco da soluo proposta consiste em atender a estes requisitos, bem como prover
mecanismos para que novos requisitos possam ser includos, de acordo com o contexto de
cada aplicao a ser desenvolvida com base nos servios oferecidos.
Segundo Meira et al. (2016) existem pelo menos dois conjuntos de leis que regem o
desenvolvimento de sistemas: um para sistemas pequenos e outro para sistemas grandes.
Uma interseco dessas so as leis universais que se aplicam a todos os tipos de sistemas.
Essas leis universais so:
R: Todo sistema deve ter provises que lhe permitam ser reutilizado em diferentes
contextos e por sistemas diferentes;
E: Todo sistema deve ter provises que permitam que ele seja estendido para aco-
modar novos comportamentos;
A: Todo sistema deve ter provises que lhe permita oferecer analytics para permitir
a medio e rastreamento de seu uso;
L: Todo sistema deve ter provises que permitam que ele seja fracamente acoplado
para reduzir tanto as interdependncias entre seus mdulos/componentes, quanto
outros sistemas com os quais possivelmente interage;
FU: todo sistema, grande e pequeno, deve ter disposies que permitam que ele seja
mantido e atualizado, seja dentro ou fora do sistema propriamente dito;
CK: todo sistema, grande e pequeno, deve ter provises que lhe permitam adquirir
e usar o conhecimento de contexto para decidir se est funcionando corretamente
ou no;
IN: todo sistema, grande e pequeno, deve ter provises que lhe permita ser inde-
pendente de sua rede tanto quanto possvel; na ausncia da rede, os sistemas devem
degradar graciosamente a um nvel de utilidade que se assemelhe a um sistema to-
talmente independente, pequeno e isolado;
G: em geral, para todos os tipos de sistemas, as preocupaes de segurana e inte-
gridade devem substituir as de funcionalidade, que por sua vez deve ser equilibrada
com a usabilidade;
O conjunto dessas leis forma o Primeiro Mandamento da Engenharia de Software
(PMES): Voc somente desenvolver e implantar sistemas REALFUCKING (MEIRA
et al., 2016), o qual reger o desenvolvimento desta arquitetura.
Outro fator importante para engenharia de software quanto a segurana. Para Smola
(2003), o resultado de uma gesto de segurana da informao adequada deve oferecer
suporte a cinco pontos principais:
Confidencialidade: somente as pessoas autorizadas tero acesso s informaes;
Integridade: as informaes sero confiveis e exatas. Pessoas no autorizadas no
podem alterar os dados;
Disponibilidade: o acesso s informaes sempre que for necessrio por pessoas au-
torizadas;
Autenticidade: garante que em um processo de comunicao os remetentes no se
passem por terceiros e nem que a mensagem sofra alteraes durante o envio;
Legalidade: garante que as informaes foram produzidas respeitando a legislao
vigente.
Assim, para desenvolver a Arquitetura de Software, foram considerados esses trs
aspectos: os requisitos elicitados, o PMES e a segurana da informao.
Nesta arquitetura, a Camada de Aplicao abrange os aplicativos e subsistemas usados
nas trs camadas inferiores que se integram e oferecem servios para a Camada de Negcio.
A Camada de Negcio subdividida em duas partes: Camada de Negcio da Arquitetura
de Software (Camada de Negcio AS) e Sistemas Externos. A Figura 26 mostra as divises
fsicas e lgicas desta arquitetura.
Como se v na Figura 26 (a), as camadas de Processamento, Aplicao e uma parte da
Camada de Negcio esto no mesmo ambiente (Plataforma IoT), enquanto as camadas de
Rede e Percepo esto nos ambientes Smartphone e Microcontrolador respectivamente.
Na Figura 26 (b) existe apenas uma diviso, entre as camadas de Aplicao e Negcio,
pelo motivo de a nvel de software serem camadas diferentes.
Figura 26 Divises fsicas e lgicas da Arquitetura de Software
Fonte: o Autor
Para descrever a Arquitetura de Software detalhadamente ser utilizado o mtodo

de descrio de AS baseado em vises, conhecido como 4+1 (The 4+1 View Model of
Architecture) proposto por Kruchten (1995). Segundo Kruchten (1995) a descrio de uma
arquitetura pode ser organizada em torno de quatro pontos de vista: Lgica, Execuo,
Implementao e Fsica, e em seguida, ilustrada por alguns casos de uso selecionados ou
cenrios que se tornam um quinto ponto de vista.
Para esta descrio, sero apresentadas a Arquitetura de Software Proposta e uma
Implementao de Referncia.
Arquitetura de Software Proposta - consiste da arquitetura de forma conceitual
e abstrata, independente de tecnologia, detalhada atravs das vises Lgicas, Execuo,
e Cenrios.
Implementao de Referncia - consiste de uma implementao de referncia da
Arquitetura Proposta, empregando tecnologias elicitadas na Especificao da Arquitetura
IoT. Esta arquitetura ser detalhada usando as vises de Implementao e Fsica.
4.3.1 Arquitetura de Software Proposta

Antes de comear a detalhar a AS, vale a pena mostrar a sequncia de atividades para a
realizao da entrega de uma Carrada, empregando a arquitetura proposta, apresentada
na Figura 27. Essa sequncia est detalhada na viso de caso de uso desta arquitetura.
Figura 27 Atividades realizadas pela Arquitetura Proposta
Fonte: O Autor
4.3.1.1 Viso Lgica da Arquitetura de Software
Esta viso demonstra a organizao da AS a partir do ponto de vista funcional. Nesta viso
os principais elementos, como subsistemas, mdulos e a interface entre estes elementos
so especificados. A Figura 28 ilustra a arquitetura do ponto de vista lgico e abaixo so
descritos seus mdulos.
Mediador de Dados (MD)
Este o principal mdulo da arquitetura, sendo responsvel pela orquestrao das
mensagens e armazenamento das principais entidades e dados do sistema. Esse mdulo
encontra-se na Plataforma IoT e deve gozar das caractersticas de um ambiente de Com-
putao em Nuvem, como: elasticidade, ubiquidade, escalabilidade, acesso amplo via rede
Figura 28 Viso Lgica da AS proposta
Fonte: O Autor
e segurana. Para coordenar a comunicao, esse mdulo deve implementar o PA Broker,

uma vez que esse padro usado para estruturar sistemas de software com componentes
distribudos que interagem com chamadas de servios remotos.
Os principais atores do mdulo Mediador de Dados so:
Produtor de Contexto - entidade (por exemplo, um N IoT) capaz de gerar
contexto;
Consumidor de Contexto - entidade (por exemplo, uma aplicao baseada em
contexto) que explora informaes de contexto.
Esse mdulo representa o ponto de entrada para as aplicaes e servios externos da
Camada de Negcio, provendo mecanismos necessrios para o acesso e a comunicao com
a AS e entre seus mdulos. Todas as comunicaes com este mdulo devem ocorrer atravs
da API fornecida por ele. Com essas interfaces, pode-se fazer as seguintes operaes:
Registrar Produtor de Contexto;
Atualizar contexto;
Ser notificado quando da alterao de contexto ou com uma frequncia determinada;
Consultar contexto.
Um princpio fundamental deste mdulo a total dissociao entre os Produtores
e os Consumidores de Contexto. Desta forma um Consumidor no necessita saber qual
Produtor publicou um evento, assim como um Produtor no precisa conhecer qualquer
Consumidor. Como resultado, esse mdulo uma ponte que permite que aplicaes ex-
ternas da Camada de Negcio gerenciem eventos de forma mais simples escondendo a
complexidade da coleta de recursos dos Ns.
Autenticador
Este mdulo o responsvel pela criao do Token para autorizao da comunicao
do Gateway (dispositivo de posse do Pipeiro) com o N (Cisterna do Beneficirio) e da
autenticao do Pacote de Recebimento gerado no N e transmitido pelo Gateway.
O Mdulo Autenticador encontra-se na Plataforma IoT, porm em uma mquina vir-

tual diferente do Mediador de Dados. Essa deciso arquitetural de manter esses dois m-
dulos no mesmo ambiente se explica pela maior facilidade na gesto das Chaves Pblica
e Privadas do Autenticador e dos Ns, facilitando a comunicao entre esses mdulos.
Esses mdulos se comunicam atravs da API disponibilizada pelo Mediador de Dados.
Para essa comunicao o mdulo Autenticador deve ser registrado no mdulo Mediador
de Dados de forma que quando uma atualizao de contexto ocorra ele seja notificado.
Uma atualizao de contexto nesse caso pode ser um pedido de gerao de Token ou um
pedido de autenticao de Pacote de Recebimento.
Este mdulo o responsvel direto pela autenticidade das informaes trocadas entre
o Gateway, o N e o Mediador de Dados. Tendo em vista que os Ns no possuem
necessariamente acesso a Internet, a metodologia de Token proposta neste trabalho no
a convencional, na qual os interessados possuem acesso Internet, mas sim gerada a
partir da assinatura com Chave Privada e autenticao com Chave Pblica, garantindo
assim a autenticidade de um pacote. A Figura 29 mostra o diagrama de sequncia das
atividades de Gerar Token de Entrega e Autenticar um Pacote de Recebimento.
Figura 29 Diagrama de sequncia da atividade de Gerar Token de Entrega
Fonte: O Autor
Para a gerao de um Token de Entrega o Mdulo Mediador de Dados notifica o

Mdulo Autenticador, passando um pacote com os dados da entrega a ser realizada.
Ento o Mdulo Autenticador assina esse pacote com sua Chave Privada. O Mdulo
Autenticador ento atualiza o contexto passando o Token para o Mediador de Dados.
Por outro lado, para a autenticao de um Pacote de Recebimento o Mdulo Mediador
de Dados notifica o Mdulo Autenticador, passando o Pacote de Recebimento (previa-
mente assinado com a Chave Privada do N). Mdulo Autenticador autentica esse pacote
com a Chave Pblica do N. O Mdulo Autenticador ento atualiza o contexto passando
o Pacote de Recebimento para o Mediador de Dados com o resultado da verificao.
Gateway
A funo principal deste mdulo/subsistema transferir o pacote de Entrega para o
N e transmitir o Pacote de Recebimento para o Mediador de Dados. Outra funo de
responsabilidade do Gateway monitorar o deslocamento a fim de armazenar o itinerrio
realizado, a data-hora de passagem pelo Manancial estabelecido para o recebimento do
recurso hdrico e a localizao do N onde houve a transmisso do Pacote de Entrega.
Esse mdulo encontra-se de posse do Pipeiro e deve possuir tecnologia de geolocali-
zao integrada e um razovel poder de processamento e armazenamento. Outra carac-
terstica que o Gateway deve possuir acesso aos protocolos de comunicao interna e
externa como definido neste trabalho, Figura 11. Desta forma, o Gateway deve funcionar
como um roteador, interligando duas redes diferentes, neste caso, os dois protocolos de
comunicao empregados nesta arquitetura. A comunicao deste mdulo com os outros
subsistemas e mdulos da arquitetura da seguinte forma: via API entre o Gateway e o
Mediador de Dados; e via protocolo de comunicao interna entre o Gateway e o N.
A Figura 30 mostra o diagrama de sequncia da atividade de realizar entrega de uma
Carrada, na esfera de responsabilidade do Gateway.
Figura 30 Diagrama de sequncia da atividade Realizar Entrega
Fonte: O Autor
Para realizar essa atividade, primeiramente o Gateway registra-se no Mediador de

Dados para poder receber notificao. Aps esse registro, o Gateway atualiza o contexto,
passando para o Mediador de Dados a Entrega a ser realizada, de escolha do Pipeiro
com base em seu Plano de Trabalho. Ento o Gateway recebe do Mediador de Dados a
notificao com o Token da entrega.
Neste momento o Gateway comea a monitorar o deslocamento, salvando em seu banco
de dados interno as coordenadas e a data-hora. Quando o Gateway chega ao Manancial
previsto para a entrega, anexa ao Token as coordenadas do Manancial e a data-hora de
chegada e partida, gerando o Pacote de Entrega.

Ao chegar ao local previsto para entrega, o Gateway estabelece a comunicao com o
N. Aps isso, o Gateway envia o Pacote de Entrega para o N. Aps a entrega da gua,
o Gateway ento recebe o Pacote de Recebimento, gerado pelo N.
Aps isso, o Gateway salva esse pacote em seu banco de dados interno e assim que
tiver acesso a rede externa atualiza o contexto, transmitindo o Pacote de Recebimento
para o Mediador de Dados.
N
A principal funo deste mdulo/subsistema validar o Pacote de Entrega e gerar
o Pacote de Recebimento. Tambm faz parte das atribuies deste mdulo controlar os
sensores usados para medir o volume e a qualidade da gua recebida.
Esse mdulo encontra-se no microcontrolador, o qual colocado fisicamente na cisterna
que ir receber o recurso hdrico. Esse subsistema armazena em sua memria obrigatori-
amente o identificador da cisterna, a Chave Privada do N e a Chave Pblica do Mdulo
Autenticador. A comunicao desse mdulo se d por protocolo de comunicao interna
com o mdulo Gateway.
Devido a falta de comunicao com a Internet por parte do N, para garantir a auten-
ticidade do Pacote de Entrega, bem como do Pacote de Recebimento, usada a tcnica
de assinatura com Chave Privada e verificao com Chave Pblica. A Figura 31 mostra
as atividades realizadas por esse mdulo.
Figura 31 Diagrama de sequncia mdulo N
Fonte: O Autor
Tudo comea com o estabelecimento da comunicao dos dispositivos Gateway e N.

Aps isso o N recebe o pacote de Entrega. De posse do pacote, o Token ento verificado
com a Chave Pblica do Autenticador para validar a autenticidade do Pacote.
No prximo passo, o N inicia a medio do volume de gua. Essa medio ocorre at

que o volume de gua entregue seja igual ao previsto no Pacote de Entrega, ou que haja
uma interrupo por parte do Gateway. O Volume de gua recebido far parte do Pacote
de Recebimento. Aps receber o volume de gua o N faz a medio da pureza da gua,
o qual tambm far parte do Pacote de Recebimento.
Aps medir a pureza da gua, o N gera o Pacote de Recebimento, concatenando as
informaes da Entrega, Pipeiro, Manancial, Cisterna, volume recebido e pureza da gua
e assinando esse pacote com a Chave Privada do N. Por fim o Pacote de Recebimento
enviado para o mdulo Gateway.
Camada de Negcio
A Camada de Negcio possui duas divises: Camada de Negcio da Arquitetura de
Software e Sistemas Externos.
Camada de Negcio AS
Esse mdulo encontra-se na Plataforma IoT e consiste apenas de um pacote que contm
classes de negcio e interfaces para os Casos de Usos: Manter Ns, Manter Plano de
Trabalho, Manter Manancial, Manter Pipeiro e Manter Carrada.
Esse pacote utilizado pela Camada de Aplicao e pode ser reusado pelos Sistemas
Externos que utilizam os servios fornecidos por esta arquitetura para implementar um
proxy a fim de facilitar a comunicao com o Mdulo Mediador de Dados. A Figura 32
mostra o diagrama de classes resumido deste mdulo.
Figura 32 Diagrama de classes resumido Camada de Negcio AS
Fonte: O Autor
Sistemas Externos
So quaisquer sistemas externos que utilizem os servios fornecidos pela Arquitetura
Proposta. Esses sistemas so implementados, hospedados e mantidos por terceiros, no
fazendo parte desta arquitetura.
A comunicao destes sistemas com a arquitetura proposta se d atravs da API dis-
ponibilizada pelo Mediador de Dados. Esses sistemas podem reusar as classes e interfaces
contidas no pacote do Mdulo Camada de Negcio AS para implementar um proxy para
auxiliar a utilizao dessa API.
Tabela 6 Mapeamento dos componentes da AS em processos e threads
Mdulo Processo Thread

1 inicial
Mediador de Dados 1 Principal + 1 por notificao
e 1 por requisio
1 inicial
Autenticador 1 Principal
+ 1 por requisio
1 principal
Gateway 1 Principal + 1 por operao de rede
+ 1 por operao de geolocalizao
N 1 Principal 1 principal
Camada de Negcio Implementao externa Implementao externa
Fonte: O Autor
4.3.1.2 Viso de Execuo da Arquitetura de Software
Esta viso apresenta o mapeamento dos componentes lgicos da AS em processos e threads

em tempo de execuo, resumidos na Tabela 6.
Mediador de Dados
Este mdulo um processo multithread. o Mediador de Dados cria uma nova thread
para cada solicitao (consulta ou atualizao) e para cada notificao de sada. Essas
threads so destrudas quando seu trabalho finaliza.
Autenticador
Este mdulo tambm formado por um processo multithread. Esse mdulo composto
por uma thread inicial para comear e gerenciar o processo e uma nova thread criada
para cada requisio, uma vez que as requisies so gerenciadas de forma independente.
Gateway
Esse mdulo formado por um processo composto por uma thread principal e vrias
outras threads. A thread principal gerencia todas as tarefas do subsistema. As outras
threads, so responsveis pela execuo das tarefas de monitoramento do deslocamento e
comunicao com o Mediador de Dados e com o N.
N
Esse subsistema formado por um processo composto por uma nica thread. Das ati-
vidades realizadas por esse subsistema a que consome mais recurso de longe as tarefes
relacionadas criptografia. Assim, a escolha do algoritmo de assinatura digital deve ser
realizada levando em considerao as limitaes do microcontrolador usado para imple-
mentar o N, deixando o processo o mais simples possvel.
Camada de Negcio
A Camada de Negcio AS no possui nenhum processo, por se tratar apenas de um
pacote de classes e interfaces a serem reusadas e implementadas. Os Sistemas Externos
no tm relao com essa arquitetura proposta no que concerne a Viso de Execuo.
4.3.1.3 Viso de Caso de Uso da Arquitetura de Software
A Arquitetura Proposta tem como principal funcionalidade realizar a entrega de uma

Carrada, realizando todos os passos para que esses dados fiquem disponveis para outros
sistemas. importante salientar que apenas para as Atividades #1, #2 e #7 necessrio
acesso a comunicao externa (Internet), nas demais no h essa necessidade. Segue abaixo
a descrio do fluxo principal do caso de uso Realizar entrega de uma Carrada:
Atividade #1: Selecionar Carrada
1. Com acesso a Internet, o Pipeiro ao se logar recebe seu Plano de Trabalho,
devidamente populado pela Camada de Negcio;
2. O Pipeiro seleciona a Carrada que deseja realizar enviando-a para o Mediador
de Dados.
Atividade #2: Recebimento do Token de Entrega
1. O Gateway atualiza o contexto no Mediador de Dados com a Carrada selecio-
nada;
2. O Gateway se inscreve no canal para ser notificado quando o Token estiver
pronto;
3. O Mediador de Dados notifica o Autenticador da mudana de contexto;
4. O Autenticador gera o Token, assinando o Pacote de Entrega com sua chave
privada;
5. O Autenticador atualiza o contexto do Mediador de Dados;
6. O Mediador de Dados notifica o Gateway da chegada do Token.
Atividade #3: Deslocamento do Pipeiro
1. O Pipeiro de posse do Token, no momento previsto pelo plano de trabalho
inicia o deslocamento;
2. O Gateway comea o monitoramento do percurso, armazenando data-hora e
coordenadas;
3. Ao chegar no Manancial o Gateway armazena a data-hora de chegada e partida;
4. Ao chegar no PAbst o Gateway inicia a comunicao com o N.
Atividade #4: Validao do Pacote de Entrega
1. O Gateway entrega o Pacote de Entrega ao N;
2. O N valida o Token, abrindo o Pacote de Entrega com a chave pblica do
Autenticador;
3. O N autoriza a entrega do recurso hdrico.
Atividade #5: Entrega da gua
1. O N monitora o volume de gua recebido;

2. Quando chega ao volume previsto ou quando o Pipeiro desejar encerrada a
entrega de gua;
3. O N mede a pureza da gua recebida.
Atividade #6: Gerao do Pacote de Recebimento
1. O N gera o Pacote de Recebimento, colocando os dados da Entrega, Ma-
nancial, Pipeiro, PAbst, volume recebido e pureza da gua em um pacote e
assinando-o com sua chave privada;
2. O N entrega o Pacote de Recebimento para o Gateway.
Atividade #7: Entrega do Pacote de Recebimento
1. O Gateway assim que tiver acesso a rede externa entrega o Pacote de Recebi-
mento ao Mediador de Dados, atualizando seu contexto;
2. O Gateway se inscreve no canal para ser notificado da validao da entrega da
Carrada;
3. O Mediador de Dados notifica o Autenticador da mudana de contexto;
4. O Autenticador valida a autenticidade do Pacote de Recebimento, abrindo o
pacote com a chave pblica do N;
5. O Autenticador atualiza o contexto do Mediador de Dados;
6. O Mediador de Dados notifica o Gateway do recebimento, encerrando a entrega.
Esse sistema possui apenas dois atores: Pipeiro e Usurio. O Pipeiro o ator que age
diretamente com o caso de uso Realizar Entrega que o principal caso de uso do sistema.
J o Usurio o ator que age com os casos de uso referentes aos Sistemas Externos.
Para a atividade principal do sistema o ator Pipeiro atua unicamente nos casos de uso
Selecionar Entrega e Realizar Entrega, sendo esse ltimo uma representao para uma
sequncia de tarefas como deslocar-se para os locais (Manancial e Cisterna) e descarregar
o recurso hdrico na cisterna. O caso de uso Realizar Entrega usa todos os casos de uso
necessrios para realizar essa atividade.
4.3.2 Implementao de Referncia

Esta subseo consiste de uma implementao de referncia da Arquitetura Proposta
(Arquitetura IoT e Arquitetura de Software Proposta). Para propsitos de testes e vali-
daes da Arquitetura Proposta, foi utilizada uma infraestrutura mnima de servio do
FIWARE3 , um Arduino Uno e um smartphone Android 4 . A implementao de referncia
desta Arquitetura de Software est disponvel em um domnio pblico5 .
3
https://www.fiware.org
4
https://www.android.com/
5
https://github.com/wasufms/SGRH
4.3.2.1 Plataforma IoT - FIWARE
A FIWARE uma plataforma genrica e extensvel para servios da Internet do Futuro por
meio de um conjunto de especificaes abertas, disponibilizadas por APIs e implementadas
em componentes denominados Generic Enablers (GEs) (BATISTA et al., 2016). Os campos
de atuao desta plataforma so bastante diversificados, indo desde agricultura, sade,
energia, meio ambiente, transporte, segurana urbana e mdias sociais.
Segundo Batista et al. (2016), o desenvolvimento dos GEs objetiva compor o ncleo
da plataforma FIWARE e so componentes fundamentais para essa plataforma. As im-
plementaes de cada GE so compostas por um conjunto de componentes, que juntos
suportam as funcionalidades fornecidas atravs de APIs, desta maneira provendo interfa-
ces interoperveis de acordo com as especificaes abertas definidas para cada GE.
A funcionalidade e especificao dos GEs fornecidas pelo FIWARE podem ser acessa-
das atravs de um catlogo pblico6 , de modo que se possa selecionar as APIs apropriadas
a serem usadas. Os GE esto classificados em sete grandes grupos: Cloud Hosting, Data/-
Context Management; Internet of Things (IoT) Services Enablement; Applications Servi-
ces and Data Delivery, Security, Interface to Networks and Devices (I2ND) Architecture
e Advanced Web-based User Interface.
Os componentes abertos e o alto investimento da FI-PPP7 , aliado grande quantidade
de GEs, bem como, o foco em fornecer elementos utilizveis para vrios domnios tm
proporcionado FIWARE um grande e crescente uso a nvel Internacional (BATISTA et
al., 2016). A nvel de Brasil, a FIWARE vem sendo adotada em projetos que envolvem
seu uso em Smart City e IoT, por pesquisadores de algumas instituies acadmicas.
4.3.2.2 Viso Fsica da Arquitetura de Software
As Tabelas 7, 8 e 9 mostram as configuraes de hardware e software usados na imple-

mentao de referncia. Logicamente, para a utilizao em um ambiente real de produo
deve-se analisar as solues de Plataforma de IoT oferecidas pelos provedores para obter
melhor desempenho da arquitetura proposta.
4.3.2.3 Viso de Implementao da Arquitetura de Software
Esta viso descreve as estratgias utilizadas para a implementao do sistema de acordo

com a Arquitetura de Software Proposta.
Mediador de Dados
Com o intuito de melhorar a qualidade da arquitetura, foi adotado o padro arquite-
tural Broker, implementado no Mediador de Dados. Esse deciso de projeto basea-se no
6
https://catalogue.fiware.org/
7
https://www.fi-ppp.eu/
Tabela 7 Viso Fisica da AS - Gateway
Smartphone
Sistema Operacional Android 6.0.1 Marshmallow
- GSM Quad Band (850/900/1800/1900)
Rede - GPRS, EDGE, UMTS, HSDPA, HSUPA, HSPA+, LTE
- Bluetooth (4.2 com A2DP/LE)
Processador Quad-core 1.5 GHz Cortex-A53
Memria RAM 2 GB
GPS A-GPS/GLONASS/BeiDou
Fonte: O Autor
Tabela 8 Viso Fisica da AS - N
Arduino Uno
Microcontrolador ATmega328P
Memria Flash 32 KB (ATmega328P)
SRAM 2 KB (ATmega328P)
EEPROM 1KB (ATmega328P)
Velocidade de Clock 16 MHz
Sensor Ultrasnico HC-SR04
Mdulo Bluetooth HC-05
Fonte: O Autor
fato deste PA ser idealizado para sistemas distribudos, que o caso desta arquitetura
proposta.
O mdulo Mediador de Dados usa o Orion Context Broker, que uma implementao
do FIWARE para o PA Broker, implementado com o Padro de Design Publish/Subscribe,
fornecendo uma API RESTful para troca de informaes de contexto. Para implementar
a API RESTful este mdulo usa as interfaces NGSI-9 e NGSI-10, empregando a notao
JSON8 .
Este mdulo utiliza como banco de dado para armazenar as informaes de contexto
e os dados do sistema o banco NoSQL MongoDB, que um banco de dados baseado
em arquivo sem transaes e sem junes. As informaes de Contexto e os dados so
representadas atravs de estruturas de dados genricas denominadas ContextElement. Um
Elemento de Contexto refere-se a informaes que so produzidas, coletadas ou observadas
8
http://www.json.org/json-pt.html
Tabela 9 Viso Fisica da AS - Plataforma IoT
FIWARE
Mediador de Dados
Hardware 4096 MB RAM , 2 VCPU, 40GB Disk
Sistema Operacional Linux Red Hat verso 4.4.7
Orion Context Broker Verso 1.3.0
MongoDB Verso 3.2.6
Autenticador
Hardware 2048 MB RAM, 1 VCPU, 20GB Disk
Sistema Operacional Ubuntu 14
Servidor HTTP Apache 2
Servidor Web Tomcat 8
Java Verso 8
Camada de Negcio
Configuraes idnticas ao Autenticador
Fonte: O Autor
que podem ser relevantes para processamento, anlises e extrao de conhecimento. Um

ContextElement normalmente fornece informaes de uma determinada entidade, sendo
ela uma coisa fsica ou parte de uma aplicao. A Figura 33 mostra o diagrama de classe
do Mediador de Dados.
Figura 33 Diagrama de Classe do Mediador de Dados
Fonte: FIWARE
Autenticador
O algoritmo de criptografia RSA de fato a mais bem sucedida implementao de
sistemas de chaves assimtricas, sendo atualmente o mais utilizado entre os algoritmos
assimtricos (GUSTAVO et al., 2012). Porm, em testes de implementao, esse algoritmo
consumiu toda a memria do N, levando a necessidade da escolha de outro algoritmo.
O algoritmo de assinatura digital da curva de Edwards (Edwards-curve Digital Signature
Algorithm - EdDSA) um algoritmo com base em curvas elpticas projetado para ser mais
rpido do que os esquemas de assinatura digital existentes, sem sacrificar a segurana.
Desta forma, este mdulo implementa o algoritmo de assinatura digital EdDSA para
realizar a encriptao e decriptao dos pacotes, usados como assinatura e verificao
respectivamente, utilizando a linguagem de programao Java.
A troca de mensagem com o Mediador de Dados realizada usando a notao JSON
utilizando a biblioteca fornecida pelo Google Inc. conhecida como GSON9 .
Gateway
A implementao deste mdulo/subsistema realizado utilizando a linguagem Java
para a plataforma Android. Android um conjunto de softwares para dispositivos m-
veis que inclui um sistema operacional, um middleware e aplicaes-chave. A troca de
mensagem com o Mediador de Dados realizada tambm usando a notao JSON com
a biblioteca GSON. E semelhante ao mdulo Autenticador, esse mdulo tambm reusa o
pacote da Camada de Negcio para as classes de entidade.
N
Esse mdulo/subsistema implementado de forma estruturada na linguagem de pro-
gramao C. Possui uma funo principal que controla o fluxo do programa e repete-se
continuamente permitindo que o sistema funcione dinamicamente.
A implementao da atividade de verificar a autenticidade do Token e gerar o Pacote
de Recebimento realizada com a utilizao da biblioteca Ed25519 do Arduinolibs10 . Essa
biblioteca uma implementao na linguagem C do algoritmo EdDSA.
Camada de Negcio
A Camada de Negcio AS um pacote de classes e interfaces escritas em linguagem
Java. Esse pacote foi idealizado para ser reutilizado usando o PA Model-View-Controller
(MVC). O MVC divide um aplicativo em trs componentes. O Modelo contm a funcio-
nalidade principal e os dados. As Vises exibem informaes ao usurio, enquanto que os
Controladores lidam com as entradas do usurio (BUSCHMANN et al., 1996).
Isso no impede que Sistemas Externos escritos em outra linguagem de programa-
o utilizem a arquitetura, uma vez que estes podem se comunicar diretamente com o
Mediador de Dados atravs da interface REST usando a notao JSON.
4.3.3 Validao da Arquitetura de Software

Esta subseo tem o objetivo de validar a Arquitetura de Software quanto a dois dos
aspectos considerados para implementar essa arquitetura: PMES e os requisitos elicitados,
relacionando-os com a Arquitetura Proposta. No propsito desta subseo avaliar a
Arquitetura de Software quanto a esses aspectos, isso fica por conta do prximo captulo.
9
https://sites.google.com/site/gson/gson-user-guide
10
https://github.com/rweather/arduinolibs/tree/master/libraries/Crypto
4.3.3.1 PMES versus Arquitetura de Software
Uma das balizas do projeto desta AS o PMES. Durante todo o projeto arquitetural foi
pensado em como cumprir, ou no descumprir, esse conjunto de lei. Essa subseo mostra
como a AS proposta se relaciona com as leis que regem esse mandamento. A avaliao de
quanto a AS obedece a essas leis realizada na avaliao da arquitetura proposta.
R - Ser reutilizado por diferentes sistemas: Esse um dos principais objetivos da
AS proposta, fornecer servios para diferentes sistemas. Com os dados e informaes
sendo disponibilizados como servios web, diferentes sistemas podem utilizar os dados
disponibilizados pela AS proposta. Outra forma de ser reutilizado o uso da Arquitetura
Proposta em outros domnios, como por exemplo, na distribuio de gasolina.
E - Ser estendido para acomodar novos comportamentos: Essa lei cumprida devido
a facilidade de criar novas entidades no Mediador de Dados, interagindo diretamente com
ele ou estendendo as classes oferecidas pelo mdulo Camada de Negcio AS.
A - Oferecer Analytics: No momento, a Arquitetura no cumpre diretamente essa lei,
porm o sistema oferece diversas oportunidades de emprego de Analytics, devido a grande
massa de dados potencialmente gerado. As Plataformas IoT possuem artefatos que podem
ser usados para essa finalidade, como por exemplo Complex Event Processing (CEP)11 da
FIWARE.
L - Fracamente acoplado: Os mdulos e subsistemas s se comunicam por mensagem,
alm de estarem em ambientes e/ou mquinas virtuais separadas. O que contribui tambm
com o cumprimento dessa lei a total dissociao entre os Produtores de Contexto e os
Consumidores onde um no precisa ter conhecimento do outro.
FU - Permitir ser mantido e atualizado: A separao em mdulo e subsistemas auxilia
o cumprimento desta lei. Outra deciso arquitetural que corrobora com essa lei empregar
protocolos, padres e algoritmos bem definidos e abertos como REST, NGSI, JSON e
MVC na implementao Arquitetura Proposta.
CK - Usar conhecimento de contexto: A partir da troca de mensagens entre os m-
dulos, o sistema consegue adquirir e usar o conhecimento de contexto para decidir se as
mensagens so vlidas ou no.
IN - Ser, na medida do possvel, independente de rede: O sistema necessita de rede
para funcionar, uma vez que um sistema distribudo, porm projetado para mesmo
sem rede cumprir sua tarefa de forma independente e isolado, completando-a assim que
obtiver acesso a rede.
G - Preocupaes de segurana e integridade equilibrada com a usabilidade: um
dos principais requisitos do sistema, sendo trabalhado fortemente na autenticidade das
mensagens trocadas entre os mdulos atravs da assinatura digital, com o mnimo de
interao humana.
11
https://catalogue.fiware.org/enablers/complex-event-processing-cep-proactive-technology-online
Tabela 10 Mapeamento de Requisitos X Mdulos
Requisito MD Autenticador Gateway N Negcio

Mnima interao do usurio R C C R
Interoperabilidade R C C C
Eficincia Energtica C R
Ubiquidade/Mobilidade C R
Segurana C R C R C
Geolocalizao R
Disponibilidade R R C C C
Flexibilidade/Extensibilidade R R
Baixo custo C C C R
Adequao modelos atuais C C C C R
Fonte: O Autor
4.3.3.2 Requisitos Elicitados versus Mdulos da Arquitetura de Software
A Tabela 10 lista o mdulo da arquitetura proposta que: [C] Contribui para o atendimento
de um requisito; e [R] Responsvel direto para que o requisito seja contemplado ou que
afeta diretamente esse requisito.
Como nota-se, mais de um mdulo pode ser o responsvel pelo atendimento do requi-
sito, bem como um certo mdulo pode no contribuir com esse requisito.
4.3.4 Resumo da Seo

Nesta seo foi especificada a Arquitetura de Software da arquitetura proposta neste
trabalho, sendo detalhadas a Arquitetura de Software Proposta e a Implementao de
Referncia desta arquitetura. Para isso, foram apresentadas as Camada de Aplicao e
Camada de Negcio atravs da metodologia 4+1. Tambm foi apresentado uma validao
da Arquitetura de Software com o PMES e com os requisitos elicitados, relacionando-a
com esses aspectos.

Neste captulo foram apresentados um conjunto de requisitos fundamentais a serem aten-
didos na implementao e implantao de uma arquitetura para SGRH no contexto deste
trabalho. Aps essa definio foi apresentado o modelo de arquitetura IoT usado, apre-
sentando as camadas desta arquitetura. Por fim foi especificada a Arquitetura de Software
da arquitetura proposta neste trabalho.
No prximo captulo essa arquitetura ser avaliada por especialistas em diversas reas
relacionada com este trabalho, a fim de validar a arquitetura proposta.
85
5 Avaliao da Arquitetura Proposta
A avaliao da arquitetura de software um meio poderoso para tomar decises sobre

sistemas, avaliar e mitigar riscos e identificar formas de melhoria e migrao de sistemas
de software. A avaliao da arquitetura atinge esses objetivos ao prever as propriedades
dos sistemas antes de serem construdos ou respondendo a perguntas sobre os sistemas
existentes (KNODEL; NAAB, 2014). Segundo Patidar e Suman (2015), na fase inicial do
sistema a AS deve ser avaliada para verificar e comparar as vantagens e desvantagens de
uma arquitetura.
O objetivo da avaliao da arquitetura de software fornecer meios eficazes para de-
terminar caractersticas de atributos de qualidade, identificar riscos potenciais no projeto
de arquitetura e entender trade-offs no projeto (PATIDAR; SUMAN, 2015). Knodel e Naab
(2014) em um trabalho com mais de 50 avaliaes de AS, concluram que a avaliao
de AS pode ser um instrumento extremamente til para apoiar a tomada de deciso de
arquitetura e orientar o alinhamento estratgico de negcios e tecnologias em um sistema.
Sendo assim, podemos concluir que to importante quanto definir a arquitetura de
um sistema realizar uma avaliao do que foi definido, com o objetivo de identificar as
possveis falhas antes que se tornem grandes problemas no futuro.
Este captulo visa avaliar a Arquitetura Proposta neste trabalho. Para tal, na seo
5.1 sero apresentados dois mtodos de avaliao de AS amplamente aceitos e validados
na literatura. Posteriormente, na seo 5.2, ser discutido o protocolo adotado para a
avaliao desta AS. Na seo 5.3 apresentada como foi a execuo da avaliao propri-
amente dita. Em seguida, a seo 5.4 discute alguns resultados e comentrios a respeito
das principais questes que surgiram durante a avaliao desta AS. Alm disso, a seo
5.5 discute as principais ameaas validade da avaliao.
5.1 Mtodos de Avaliao

Vrias abordagens diferentes tm sido propostas para avaliar arquiteturas de software, tais
como baseadas na experincia, baseada em cenrios, modelagem matemtica e baseada
em simulao. Entre essas abordagens, as baseadas em cenrios esto bastante maduras
e experimentadas (PATIDAR; SUMAN, 2015).
Cenrio uma breve descrio de algum uso antecipado ou desejado do sistema. Es-
sas descries so formuladas em termos de qualidades, como por exemplo: "como essa
arquitetura modificvel?", a fim de responder a seguinte questo: "como essa arquitetura
acomodar a seguinte mudana?" (KAZMAN et al., 1996).
A literatura apresenta vrios mtodos de avaliao, com diferentes objetivos e con-
textos de execuo, isto pode ser constatado em Patidar e Suman (2015). Para filtrar
Captulo 5. Avaliao da Arquitetura Proposta 86
esse conjunto de mtodos, a condio utilizada neste trabalho levou em considerao os

Atributos de Qualidade (QA), acrnimo do ingls Quality Attribute, que o mtodo visa
avaliar, como modificabilidade, segurana e as leis fundamentas da engenharia de software
descritas em Meira et al. (2016).
Analisando o trabalho realizado por Patidar e Suman (2015), dois mtodos candidatos
a serem utilizados foram selecionados: SAAM (KAZMAN et al., 1994) e ATAM (KAZMAN
et al., 2000). SAAM o mtodo pioneiro de avaliao de arquitetura, este mtodo a base
de todos os mtodos de avaliao. O ATAM um refinamento do SAAM, sendo ATAM
o padro de fato para avaliaes de arquitetura (KNODEL; NAAB, 2014). Outro fator que
levou a essa seleo foi que, segundo Patidar e Suman (2015), dentre os vrios mtodos
apenas SAAM e ATAM esto sendo aplicados na indstria.
5.1.1 SAAM
SAAM (Software Architecture Analysis Method) um mtodo de avaliao simples que
pode ser adaptado a diferentes contextos. Foi originalmente desenvolvido para permitir
a comparao de solues arquiteturais concorrentes, analisando principalmente os QA
modificabilidade e funcionalidade.
Mtodo bastante estabelecido, SAAM amplamente utilizado nos demais QA, tais
como portabilidade, extensibilidade e integrabilidade. Este mtodo tem sido aplicado em
vrios estudos de caso, incluindo sistema de informao global, ambiente de desenvol-
vimento de interface de usurio, sistemas Web e sistema de udio embutido (KNODEL;
NAAB, 2014).
Este mtodo inclui 6 atividades: desenvolvimento dos cenrios; descrio da AS avali-
ada; classificao e priorizao dos cenrios; avaliao dos cenrios individual e indireta;
interao entre os cenrios; e avaliao global dos cenrios (KAZMAN et al., 1994).
As principais vantagens da utilizao do SAAM so a melhoria na documentao da
AS e a identificao de riscos cedo no ciclo de vida do software (KAZMAN et al., 1994).
5.1.2 ATAM
ATAM (Architecture Tradeoff Analysis Method) um mtodo baseado em cenrios, re-
finado do SAAM, porm, mais complexo que este. A aplicao do ATAM revela quo
bem uma AS satisfaz aos requisitos de qualidade desejados, alm de identificar os riscos
arquiteturais e os conflitos (trade-offs) existentes para se alcanar tais requisitos.
O ATAM um mtodo que ajuda as partes interessadas a entender as consequncias
das decises arquitetnicas em relao aos requisitos de atributo de qualidade do sistema
(BASS; NORD, 2012). Algumas aplicaes do mtodo ATAM so: sistemas de sensor de
temperatura remoto e Battlefield Control System (PATIDAR; SUMAN, 2015).
O ATAM inclui 4 atividades principais: (i) Descrio: apresentao do ATAM, dos ob-
jetivos de negcios e da AS; (ii) Investigao e Anlise: gerao dos atributos de qualidade
utilizando utility tree; anlise das abordagens arquiteturais; brainstorm e priorizao dos
cenrios; (iii) Testes: Anlise da AS proposta; (iv) Apresentao dos Resultados (KAZMAN
et al., 2000).
Segundo Kazman et al. (2000), os principais objetivos da ATAM so: Elicitar e refinar
os requisitos de atributos de qualidade da AS; Elicitar e refinar uma declarao precisa
das decises de projeto arquitetural; e Avaliar as decises de projeto arquiteturais para
determinar se satisfazem convenientemente os requisitos de qualidade.
5.2 Protocolo da Avaliao

Para a escolha do processo de avaliao a ser usado foram analisados os principais mtodos
oferecidos na literatura. De todos os mtodos SAAM e ATAM eram os que melhor aten-
diam aos propsitos desta avaliao. Porm, nenhum dos dois, isoladamente, atendiam
completamente s necessidades e peculiaridade deste projeto, sendo necessrio uma adap-
tao desses mtodos, assim como props Tomas (2014). Desta forma, para a realizao
da avaliao foi seguido o protocolo descrito abaixo.
5.2.1 Definio do Mtodo de Avaliao

O mtodo aplicado para avaliar esta arquitetura basea-se na metodologia proposta por
Tomas (2014), que consiste basicamente em combinar os mtodos de avaliao SAAM e
ATAM. A escolha deste mtodo para avaliao deste trabalho fundamenta-se na neces-
sidade de caractersticas contidas nos dois mtodos de avaliao, SAAM e ATAM, como
mostra a Tabela 11. Segundo Patidar e Suman (2015), o objetivo do SAAM justamente o
que se precisa avaliar neste trabalho, o quo a arquitetura est apta para ser empregada.
Por outro lado, os atributos de qualidades avaliados pelo mtodo ATAM est mais de
acordo com o propsito desta dissertao, avaliar mltiplos QA. Por fim, ainda segundo
Patidar e Suman (2015), uma das aplicaes para o mtodo ATAM avaliar sistema de
sensor de temperatura remoto, o que est no contexto desta dissertao.
Tabela 11 Caractersticas dos mtodos SAAM e ATAM
SAAM ATAM
Objetivo Aptido da Arquitetura trade-off
Atributos de Qualidade Modificabilidade Mltiplos
Aplicao do Mtodo Sistemas de udio incorporado Sensores temp. remoto
Fonte: Adaptado de (PATIDAR; SUMAN, 2015)
Tabela 12 Etapas do mtodo de avaliao
# Etapa
1 Apresentao do Processo de avaliao
2 Apresentao dos Objetivos de Negcios
3 Apresentao da Arquitetura Proposta
4 Priorizao dos Atributos de Qualidade
5 Contextualizao sobre cenrios
6 Apresentao dos cenrios
7 Priorizao dos cenrios
8 Avaliao dos cenrios propostos
9 Avaliao das interaes entre cenrios e QA
10 Consolidao dos Resultados
Fonte: O Autor
Um dos motivos que tambm levaram necessidade de realizar uma adaptao dos
mtodos de avaliao o fato de a AS proposta ser regida pelo PMES. Assim, os QA e
os cenrios devem avaliar o quo a AS proposta est adequada s leis universais descritas
em Meira et al. (2016).
Outro fator que para a definio do mtodo de avaliao a ser empregado foi levado
em considerao a necessidade de se avaliar a Arquitetura Proposta como um todo, no
apenas a AS, mas tambm a Arquitetura IoT descrita na seo 4.2.
Assim, esta avaliao baseada no SAAM e ATAM, como props Tomas (2014),
porm com atividades adequadas avaliao deste trabalho. Nenhuma nova etapa foi
criada, as etapas recomendadas pelo SAAM e ATAM foram combinadas e adaptadas para
esse contexto. A Tabela 12 apresenta as etapas do mtodo adaptado.
5.2.2 Equipe de Avaliao

Seguindo recomendao da ATAM, os avaliadores escolhidos para participar da equipe
so de diferentes reas de pesquisa, com diferentes experincias e vises. Essas expertises
foram selecionadas de acordo com a natureza da AS proposta.
Ao total, 12 avaliadores foram envolvidos no processo, sendo 3 doutores, 6 mestres
e 3 especialistas (engenheiros de software e programadores que atuam no programa de
distribuio de gua no Semirido brasileiro). Vale ressaltar que um mesmo avaliador
pode ter mais de uma expertise. A Tabela 13 ilustra as expertises dos envolvidos.
Tabela 13 Expertise da Equipe de Avaliao
Expertise Doutor Mestre Especialista

Engenheiros de Sistemas 1
Computao em Nuvem 1 1
Internet das Coisas 2
Arquiteturas Escalveis 1
Engenheiro em Telecomunicaes 1
Engenheiro de Software 4
Segurana da Informao 1 3
Especialistas em Negcios 3
Fonte: O Autor
5.3 Execuo da Avaliao

Seguindo o protocolo do processo de avaliao, definido na seo 5.2, o processo foi exe-
cutado dividindo as etapas em 3 reunies, descritas na Tabela 14.
5.3.1 Primeira Reunio

O objetivo da primeira reunio foi apresentar o processo de avaliao, os objetivos de
negcios da Arquitetura Proposta e contextualizar os avaliadores no processo de avaliao.
As etapas da reunio foram as seguintes:
1. Apresentao do Processo de Avaliao (Durao 30 min): Inicialmente,
foram descritos os dois principais mtodos de avaliao de AS, ressaltando as principais
diferenas entre eles. Posteriormente foram apresentadas as peculiaridades deste trabalho.
Consequentemente, o processo de avaliao a ser utilizado foi descrito. O objetivo desta
Tabela 14 Execuo da avaliao
1. Apresentao do Processo de Avaliao

2. Apresentao dos Objetivos de Negcios
Primeira Reunio 3. Apresentao da Arquitetura Proposta
4. Priorizao dos Atributos de Qualidade
5. Contextualizao sobre Cenrios
6. Apresentao dos Cenrios
Segunda Reunio 7. Priorizao dos Cenrios
8. Avaliao dos Cenrios propostos
9. Avaliao das interaes entre cenrios e QA
Terceira Reunio
10. Consolidao dos Resultados
Fonte: O Autor
etapa foi situar os avaliadores em relao ao objetivo do processo e aos prximos passos.
2. Objetivos de Negcios (Durao 30 min): A segunda etapa da reunio teve a
inteno de definir e apresentar os objetivos de negcios da Arquitetura Proposta, para isso
foi convidado um avaliador especialista no negcio para realizar uma rpida explanao.
Este passo foi importante para que os participantes da avaliao entendessem o contexto
do sistema e tambm as limitaes tcnicas existentes para a execuo do projeto. Todos
esses aspectos foram apresentados para ajudar na definio dos cenrios e priorizao dos
QA a serem considerados no processo de avaliao.
3. Apresentao da Arquitetura Proposta (Durao 60 min): Seguindo uma
recomendao relatada em Tomas (2014), essa apresentao da arquitetura no foi total-
mente detalhada nesta fase, pois aquele autor relatou em seu trabalho que esta apresen-
tao poderia ser uma ameaa a validade do mtodo. O autor do trabalho aqui proposto
tambm acredita que essa apresentao detalhada pode ser um vis para a elicitao dos
cenrios.
Assim, neste passo foi apresentada para os avaliadores a Arquitetura Proposta, atravs
de um software totalmente funcional realizando o fluxo principal do caso de uso Realizar
entrega de uma Carrada. Esta apresentao foi de suma importncia para que os avali-
adores percebessem se os requisitos funcionais foram implementados e avaliar se de fato
satisfazem as necessidades do negcio.
4. Priorizao dos Atributos de Qualidade (Durao 45 min): Como os par-
ticipantes no estavam acostumados ao conceito de Atributos de Qualidade, inicialmente
foi descrito o que so e quais os objetivos dos mesmos.
Um pr-requisito de uma avaliao ter uma clara declarao de requisitos de atributo
de qualidade (KAZMAN et al., 2000), para isso, foram apresentados os QA definidos pela
ISO/IEC25010 e as leis universais do PMES.
Finalmente, foi realizada uma votao para priorizar quais atributos melhor expressam
os objetivos de negcios, apresentados anteriormente. Nesta votao, cada participante
pode usar 3 votos entre os QA. A soma destes votos representa a prioridade atribuda
pelos avaliadores. A Tabela 15 exibe o resultado desta votao ordenado por prioridade.
5. Contextualizao sobre Cenrios (Durao 15 min): O ltimo passo dessa
primeira reunio, foi a contextualizao sobre cenrios. Da mesma forma como os atributos
de qualidade, inicialmente foi realizada uma apresentao sobre o que so e quais as
necessidades dos cenrios. Em seguida, alguns cenrios foram exemplificados, como Qual
o impacto na arquitetura para disponibilizar um novo tipo de dado e A AS deve permitir
suporte a servios em Cloud Computing j existentes.
Por fim, uma planilha online1 foi compartilhada com os avaliadores para que eles
pudessem propor cenrios de utilizao da Arquitetura Proposta com base nos objetivos
de negcios. Um prazo de 4 dias foi estipulado para essa atividade.
1
https://github.com/wasufms/SGRH/blob/master/Proposta_Cenarios.pdf
Tabela 15 Atributos de Qualidade ordenados por prioridade
Fonte
Atributo de Qualidade # Votos
Caracterstica ISO/IEC 25010
Equilbrio Segurana, Meira et al. (2016)
5
integridade e usabilidade Segurana e Usabilidade
ISO/IEC 25010
Confiabilidade Maturidade, Disponibilidade, 5
Tolerncia a falhas, Recuperabilidade
Permitir ser manutenido Meira et al. (2016)
4
e atualizado Manutenibilidade - Modificabilidade
Ser, na medida do possvel, Meira et al. (2016)
4
independente de rede -
ISO/IEC 25010
Desempenho/eficincia Tempo-comportamento, 4
Utilizao de recursos, Capacidade
ISO/IEC 25010
Aprendizagem, Operabilidade,
Usabilidade 3
Proteo contra erros de usurio,
Interface do usurio, Esttica, Acessibilidade
Ser reutilizado por diferentes Meira et al. (2016)
2
sistemas Manutenibilidade-Reusabilidade
Meira et al. (2016)
Fracamente acoplado 2
Manutenibilidade - Modularidade
ISO/IEC 25010
Portabilidade 2
Adaptabilidade, Instalabilidade, Substituio
Ser estendido para acomodar Meira et al. (2016)
1
novos comportamentos Manutenibilidade-Modificabilidade
ISO/IEC 25010
Funcionalidade 1
Integridade, Correo, Adequao
Usar conhecimento Meira et al. (2016)
0
de contexto -
Meira et al. (2016)
Oferecer Analytics 0
Manutenibilidade -Analisabilidade
ISO/IEC 25010
Compatibilidade 0
Coexistncia, Interoperabilidade
Fonte: O Autor
5.3.2 Segunda Reunio

A Segunda Reunio foi marcada uma semana depois da primeira. Como uma preliminar,
em 15 minutos foram relembradas as etapas anteriores da avaliao, os objetivos de negcio
e Arquitetura Proposta. Esta reunio seguiu as seguintes etapas:
Detalhamento da AS Proposta (Durao 30 min): Embora fora da metodolo-
gia proposta inicialmente, essa etapa foi realizada nesta fase a fim de mitigar um possvel
veis nas etapas anteriores de priorizao de QA e elicitao dos cenrios. Nesta etapa a
Arquitetura Proposta foi detalhada pelo arquiteto atravs de uma viso de mdulos. Para
tal, foi utilizada a metodologia de descrio de AS "4+1".
6. Apresentao dos Cenrios (Durao 60 min): Nesta etapa foram discuti-
dos todos os cenrios propostos, onde alguns tiveram que ser reescritos para um melhor
entendimento de todos os avaliadores. Para que esses cenrios pudessem realmente ser
til avaliao foi necessrio considerar os cenrios mais aplicveis, coerentes e factveis
na Arquitetura Proposta. Desta maneira, alguns cenrios, quando de consenso geral, fo-
ram reescritos ou excludos. Como exemplo, tem-se o seguinte cenrio: extremamente
importante desenvolver uma interface amigvel ao usurio, tendo em vista que o pblico
alvo do produto so pessoas com baixo conhecimento tecnolgico. Apesar de importante e
relevante, os avaliadores acreditaram que esse no era um cenrio til avaliao.
7. Priorizao dos Cenrios (Durao 30 min): Nesta fase os cenrios elici-
tados foram discutidos novamente e um peso de relevncia foi atribudo para cada um
deles. Para isso foi realizada uma votao para priorizar os cenrios, considerando os mais
aplicveis, coerentes e factveis. Nesta votao cada participante pode usar 3 votos entre
os cenrios, onde a soma representa a prioridade atribuda pelos avaliadores.
8. Avaliao dos Cenrios propostos (Durao 15 min): Para essa etapa
um formulrio online2 foi compartilhado com os avaliadores para que esses avaliassem
o quo os cenrios elicitados condizem com a natureza da Arquitetura Proposta. Para
essa avaliao foram estipulados 4 dias para os avaliadores. Os cenrios resultantes so
exibidos na Tabela 16, ordenados de acordo com a priorizao.
5.3.3 Terceira Reunio

Da mesma forma que a segunda reunio, a terceira e ltima reunio foi marcada uma
semana depois. O objetivo primordial dessa reunio foi consolidar os resultados e definir
as possveis aes a serem tomadas para aprimorar a proposta.
9. Avaliao das interaes entre Cenrios e Atributos de Qualidade (Du-
rao 60 min): Nesta primeira etapa da reunio, os avaliadores discutiram o quo os
cenrios priorizados conflitavam com os atributos de qualidade.
2
https://github.com/wasufms/SGRH/blob/master/Avaliacao_Cenarios.pdf
Tabela 16 Cenrios propostos para avaliao da AS
Id Cenrio
C1 Fornecer segurana aos dados transmitido e recebidos pelos dispositivos e nuvem
C2 A AS deve permitir escalabilidade sob demanda de servio
C3 Consumir pouca largura de banda da rede devido a qualidade das redes mveis
C4 A AS deve ter Tolerncia a falhas
C5 Permitir a comunicao entre dispositivos heterogneos. (Ex. celular, Arduino)
C6 Resilincia a falha de comunicao com a Cloud (outras formas de comunicao SMS)
C7 A AS deve permitir a comunicao via API
C8 A AS deve permitir Suporte a servios em Cloud Computing j existentes
C9 A aplicao embarcada no hardware das cisternas deve consumir poucos recursos
C10 Permitir a priorizao de determinadas localidades na fila de requisies de assinaturas
C11 Permitir a flexibilizao do tamanho do token de certificao
C12 Permitir a substituio do hardware Arduino pelo raspberry pi, visando desempenho
C13 A AS deve ser construda com tecnologias open source
C14 Suportar a modificao do MD no caso da identificao de vulnerabilidades
C15 Comunicao entre o N e o MD deve ser mnima e independente de conexo
C16 Aplicao em Cloud deve usar Containers para reduzir o custo do uso de VM
C17 Permitir (implementar) um protocolo de comunicao entre o Gateway e o No
C18 Permitir o Armazenamento dos dados para anlise futura
C19 Permitir que se possa fazer mais de uma reserva por vez
C20 Permitir Inteoperbilidade oferecendo um protocolo de comunicao comum e aberto
C21 Permitir possvel unificao do Autenticador e Mediador de Dados em uma mesma VM
C22 A AS deve conter uma forma de comunicao contingente entre o Gateway e o N
C23 Assegurar que a replicao das msg criptografadas no causem impacto sobre o sistema
C24 Suportar armazenamento do tipo Object Storage para baratear o custo Plataforma IoT
Fonte: O Autor
10. Consolidao dos Resultados (Durao 60 min): Por fim, nesta etapa
os resultados foram apresentados e consolidados. Primeiramente um overview sobre cada
artefato gerado durante o processo foi apresentado, principalmente a priorizao dos Atri-
butos de Qualidade e os Cenrios elicitados. Depois estes artefatos e resultados foram
discutidos e analisados pelo arquiteto e avaliadores.
5.4 Resultados da Avaliao da Arquitetura

Conforme descrito na seo anterior, para mensurar quantitativamente o quo a Arqui-
tetura Proposta contempla cada cenrio, foi criado um formulrio online com todos os
cenrios, ordenados por prioridade. Neste formulrio, cada participante deveria atribuir
uma nota de 0 a 5 para a adequao de cada cenrio, onde 5 representa que a AS ATENDE
TOTALMENTE e 0 que NO ATENDE ao cenrio em questo. Outra forma de avaliar
: caso a AS no contemple o cenrio, qual o impacto na arquitetura para que tal cenrio
seja contemplado. Assim, 5 representa que NO H IMPACTO NA AS e 0 que a O IM-
PACTO TO GRANDE QUE A AS NO TEM CONDIES DE IMPLEMENTAR
TAL CENRIO.
Apartir deste formulrio, foram obtidas algumas concluses, que sero apresentadas
nas prximas subsees.
5.4.1 Resultados da Avaliao dos Cenrios

Cada participante respondeu o formulrio online independentemente. A partir disso, fo-
ram consolidadas todas as respostas anonimamente. A Figura 34 ilustra a mdia e o
desvio padro das respostas, alm de 4 faixas de satisfatoriedade, definidas pelos prprios
participantes da avaliao.
Figura 34 Resultado da avaliao dos cenrios
Fonte: o Autor
Como possvel notar, na opinio dos participantes, a Arquitetura Proposta atende

79% dos cenrios de maneira Excelente. Essa boa avaliao se d principalmente devido
ao fato de muitos cenrios estarem relacionados com caractersticas ofertadas pela Com-
putao em Nuvem, que o uma das bases deste trabalho.
Vale aqui ressaltar que esta arquitetura em si no implementa nenhum das caracte-
rsticas essenciais da Computao em Nuvem, como por exemplo elasticidade ou amplo
acesso a rede, porm a arquitetura desenhada de forma que o seu mdulo principal
esteja em uma Plataforma de mediao de dados IoT que deve fornecer todos os servios
de Computao em Nuvem.
Outro fator que contribui com essa avaliao otimista devido a muitos cenrios esta-
rem relacionados a segurana, que outro fator diretamente relacionado a este trabalho.
Os cenrios melhores avaliados foram: C7 - A AS deve permitir a comunicao via

API, C9 - A aplicao embarcada no hardware das cisternas (N) deve consumir poucos
recursos e C13 - A AS deve ser construda com tecnologias open source. A excelente
avaliao destes cenrios se d principalmente por serem cenrios que fazem parte dos
requisitos elicitados no incio do projeto ou terem sido observados durante a realizao da
implementao de referncia, sendo assim contemplados na arquitetura.
O nico cenrio avaliado como Satisfatrio foi C22 - A AS deve conter uma forma de
comunicao contingente entre o Gateway e o N. Esse resultado j era esperado devido
ao fato de a Arquitetura Proposta no prev nenhuma forma de comunicao contingente
caso a comunicao interna do N deixe de funcionar por algum motivo. Esse cenrio
tambm o que apresentou maior desvio padro, isso se deve ao fato de que muitos
avaliadores acreditam que esse problema pode ser resolvido colocando-se dois mdulos de
comunicao no N.
Os cenrios piores avaliados, C6 - Resilincia a falha de comunicao com a Cloud
(outras formas de comunicao SMS), C10 - Permitir a priorizao de determinadas
localidades na fila de requisies de assinaturas e C22 - A AS deve conter uma forma de
comunicao contingente entre o Gateway e o N, so os que apresentam maior desvio
padro. Uma possvel relao o fato dos avaliadores serem oriundos de diversas reas,
assim algum stakeholder pode no compreender corretamente a questo, acreditando que
um determinado cenrio de difcil implementao, enquanto que um especialista na
rea avalia que um cenrio contemplado ou facilmente implementvel na Arquitetura
Proposta.
5.4.2 Resultados Gerais

Esta subseo visa elencar os resultados gerais obtidos a partir do processo de avaliao
executado. Estes resultados foram extrados a partir das discusses com os participantes
e no necessariamente so observados nos artefatos do processo.
Durante o processo de avaliao foi realizada a etapa de Avaliao das interaes
entre Cenrios e Atributos de Qualidade. Nesta etapa os avaliadores constataram que de
maneira geral os Atributos de Qualidades com maior prioridade foram contemplados nesta
arquitetura. Foi relatado tambm que apesar de alguns QA, como Usar conhecimento de
contexto; Oferecer Analytics e Compatibilidade, no serem contemplados na Arquitetura
Propostas, para os avaliadores, esses QA no fazem parte do contexto do trabalho, haja
vista a baixa prioridade dada a eles.
Os Atributos de Qualidade mais discutidos e elogiados pelos avaliadores foram: Ser, na
medida do possvel, independente de rede; e Equilbrio Segurana, integridade e usabilidade.
O primeiro foi contemplado devido ao Gateway mvel, o qual depois de ter recebido o
Token da entrega no necessita mais de rede para funcionar, e o segundo devido tcnica
implementada de usar Token atravs de assinatura digital entre os mdulos.
Por fim, duas questes foram relatados pelos avaliadores no que tange soluo como
um todo: uma forma de manter um backup das entregas recebidas no N, para o caso
de perda do smartphone antes de enviar a entrega para a nuvem; ou problemas relativos
a Location Spoof, que uma tcnica que permite ao usurio fraudar a sua localizao.
Quanto ao problema de backup, no momento, esse pode ser considerado como uma questo
aberta na Arquitetura Proposta que deve ser melhor trabalhada. Referente Location
Spoof existem diversas tcnicas que devem ser implementadas a nvel de programao
para evitar/mitigar esta fraude3 .
De maneira geral, estes resultados mostram que a Arquitetura Proposta pode e deve
ser utilizada em um contexto real. Logo, como trabalho futuro, a proposta atual poder
ser implantada no ambiente real por meio do Exrcito Brasileiro.
5.5 Ameaas Validade

No tocante avaliao da arquitetura previamente descrita, foram identificadas ameaas
validade que no afetam diretamente o resultado final desta avaliao. No entanto,
interessante discuti-las como forma de subsidiar a tomada de decises corretas no que se
refere realizao de eventuais trabalhos futuros que possam compartilhar aspectos com
a presente pesquisa.
5.5.1 Alto Desvio Padro

Uma das ameaas identificadas est relacionada heterogeneidade de expertises dos ava-
liadores. Apesar da utilizao de uma equipe multidisciplinar ser recomendada pelas tc-
nicas de avaliao ATAM e SAAM, observou-se, da anlise dos resultados da avaliao
dos cenrios, que alguns stakeholders no compreenderam totalmente algumas questes,
provavelmente, em virtude da falta de conhecimento tcnico na rea especfica. Em de-
corrncia disso, registrou-se um considervel desvio padro das notas atribudas a alguns
aspectos em suas respectivas avaliaes.
Acredita-se que a melhor forma de se mitigar esta ameaa seja a realizao do agrupa-
mento das questes por reas de conhecimento. Desta forma, todos os avaliadores conti-
nuariam analisando todos os cenrios. Todavia, seriam atribudos pesos distintos luz das
expertises individuais. Por exemplo, as respostas do grupo de avaliadores especialistas na
rea de Segurana da Informao teriam um peso maior do que os atribudos s respostas
de outros grupos na avaliao de questes referentes ao tema "Segurana da Informao".
3
Um script funcional para Android encontra-se na implementao de referncia desta arquitetura
5.5.2 Relacionamento Interpessoal

Outro aspecto que poderia, supostamente, ameaar a validade de uma pesquisa que utiliza
tcnicas de avaliao como forma de validao a possibilidade de haver, por parte dos
avaliadores, lenincia ou severidade excessiva em relao avaliao dos cenrios. Tal
situao poderia ser motivada por diversos fatores, dentre os quais poderiam-se destacar
a possibilidade de existirem laos interpessoais entre o arquiteto e os avaliadores ou, at
mesmo, a existncia de interesses poltico-econmicos associados aprovao ou ao veto
da pesquisa em questo.
No intuito de se mitigar a possibilidade da existncia de algum vis de cunho pessoal e,
ao mesmo tempo, sem limitar o critrio de seleo a pessoas que no possussem nenhum
vnculo - nem mesmo profissional - com o pesquisador, o que, em virtude da especificidade
do tema poderia implicar a incluso de indivduos despidos de qualquer familiaridade com
o problema que se deseja solucionar, buscou-se realizar a composio da equipe priorizando
a escolha de avaliadores cujas reputaes possussem relevncia perante a comunidade
cientfica ou, que possussem, pelo menos, uma bagagem profissional considervel na rea
em que atuam, de modo a conferir maior credibilidade avaliao efetuada pelos mesmos.
Alm disso, com o objetivo de evitar que a avaliao fosse motivada por questes
poltico-econmicas associadas ao tema da pesquisa, optou-se por selecionar profissionais
de diferentes organizaes. Desse modo, seria possvel detectar, se fosse o caso, possveis
padres de deciso associados a interesses especficos.
5.5.3 Possvel Avaliao de uma Implementao Especfica

Outra ameaa a validade da avaliao realizada a possvel avaliao de uma implemen-
tao especfica, ao invs de ser avaliada a Arquitetura Proposta. Isso pode ocorrer devido
a dificuldade de se avaliar a Arquitetura Proposta por ser uma arquitetura abstrata.
A avaliao apoiada em uma implementao de referncia uma prtica permitida
na avaliao baseada em cenrios, uma vez que uma implementao de referncia contri-
bui com a avaliao dos cenrios elicitados e posteriormente dos QA (PATIDAR; SUMAN,
2015; KAZMAN et al., 1998). Assim, a avaliao da Arquitetura Proposta com o auxlio de
uma implementao de referncia uma boa prtica, porm essa avaliao no pode ser
confundida com a avaliao de um Software ou de uma implementao especfica.
Este trabalho tenta evitar/mitigar esta ameaa avaliando cenrios referentes Arqui-
tetura Proposta e no a uma implementao especfica. Cenrios como: " extremamente
importante desenvolver uma interface amigvel ao usurio, tendo em vista que o pblico
alvo do produto so pessoas com baixo conhecimento tecnolgico" e "O material do sensor
precisa ser apropriado para Regio (corroso, chuva)", que estavam visivelmente ligados a
uma implementao especfica, quando de consenso dos avaliadores, foram excludos desta
avaliao.
Nesta avaliao, embora muitos cenrios possam ser avaliados apenas pela descrio
da Arquitetura Proposta, caso no fosse apresentada uma implementao de referncia, a
apreciao da adequao dos cenrios Arquitetura Proposta poderia ser comprometida.
A implementao de referncia desta arquitetura apoia a avaliao de muitos dos cenrios
elicitados neste trabalho, como por exemplo: "C3 - Consumir pouca largura de banda da
rede devido a qualidade das redes mveis" e "C20 - Permitir Inteoperbilidade oferecendo
um protocolo de comunicao comum e aberto", porm, sempre com o cuidado de manter
os cenrios mais genricos possveis, mas preservando a autonomia dos avaliadores.

Este captulo teve como finalidade realizar a avaliao da arquitetura proposta neste
trabalho, iniciando com a apresentao da importncia e a necessidade de se avaliar
uma AS. Logo depois, foram discutidos os possveis mtodos de avaliao de AS a serem
utilizados e definido o protocolo adotado para a avaliao desta arquitetura. Neste captulo
tambm foi descrita a execuo da avaliao e em seguida apresentados seus resultados.
Por fim, foram apresentadas algumas ameaas validade desta avaliao.
A partir da avaliao realizada, pde-se mensurar o quo a arquitetura est apta
para ser implantada em um contexto real. Assim, o prximo captulo finaliza o trabalho
descrevendo as principais concluses e as atividades futuras.
99
6 Consideraes Finais
Este trabalho apresentou uma proposta de arquitetura baseada em Internet das Coisas e
Computao em Nuvem que disponibiliza servios para orquestrar a distribuio de gua
no Semirido brasileiro.
O Presente captulo tem por objetivo apresentar as concluses da pesquisa descrita
nesta dissertao, apresentando os resultados, os principais trabalhos relacionados e por
fim, algumas sugestes para trabalhos futuros.
6.1 Viso Geral da Soluo Proposta

A soluo proposta prov meios para a realizao da seguinte sequncia de atividades:
seleo da carrada a ser entregue; gerao do Token que autoriza e valida a entrega
de gua; monitoramento do deslocamento do Pipeiro; validao da autorizao para a
entrega da gua; medio do volume e qualidade da gua entregue; assinatura digital
para confirmao da gua recebida; e entrega do Pacote de Recebimento para a nuvem
disponibilizando esses dados como um servio.
A Arquitetura Proposta regida pelo Primeiro Mandamento da Engenharia de Soft-
ware de Meira et al. (2016) e consiste de mdulos que implementam as cinco camadas de
sistemas IoT, a saber:
Camada de Percepo: Mdulo N
Encontra-se na cisterna do Beneficirio. Sua principal funo assinar e validar os
pacotes, bem como controlar os sensores usados para medir o volume e a pureza da
gua recebida.
Camada de Rede: Mdulo Gateway
Encontra-se no smartphone do Pipeiro. A funo principal deste mdulo realizar a
comunicao entre o N e o Mediador de Dados, servindo como um gateway mvel.
Camada de Processamento: Plataforma de mediao de dados IoT
Deve gozar das caractersticas de um ambiente de Computao em Nuvem como
elasticidade, umbiquidade, escalabilidade, acesso amplo via rede e segurana.
Camada de Aplicao: Mediador de Dados e Mdulo Autenticador
Mediador de Dados: Principal mdulo do sistema, sendo uma implementao do
PA Broker. Encontra-se na Plataforma IoT e o responsvel pela orquestrao das
mensagens trocadas com a AS, atualizao do contexto da aplicao e armazena-
mento dos dados.
Autenticador: Encontra-se na Plataforma IoT e responsvel pela criao do Token
para autorizao da comunicao do Gateway com o N e verificao do Pacote de
Recebimento.
Captulo 6. Consideraes Finais 100
Camada de Negcio: Camada de Negcio AS e Sistemas Externos

Camada de Negcio AS: Encontra-se na Plataforma IoT e consiste de um pacote
que contm classes de negcio e interfaces que podem ser reutilizadas por sistemas
externos.
Sistemas Externos: Quaisquer sistemas externos que utilizem os servios fornecidos
pela Arquitetura Proposta.
6.2 Trabalhos Relacionados

Robles et al. (2014) revisaram vrias solues baseadas em IoT relacionados com a estra-
tgia de gesto inteligente de gua. Neste trabalho eles listam vrias iniciativas, porm,
no fazem qualquer comparao entre as diversas abordagens ou tecnologias envolvidas.
Por outro lado, nesta dissertao foram feitas diversas comparaes neste sentido no MSL.
Esta dissertao mapeou diversos trabalhos de gesto de recursos hdricos baseados em
IoT, apresentados no Anexo A. Apenas para citar algumas iniciativas: Kudva et al. (2014)
propem um sistema de monitoramento de nvel de gua em tempo real em um campus,
usando um sensor ultrassnico comercial. Mais tarde Prachet et al. (2015) constroem um
sistema baseado em IoT para gerenciamento da distribuio de gua em um campus,
porm a pesquisa foca em construir um sensor de nvel de gua de baixo custo e uma
rede de sensores para interligar o campus; Perumal, Nasir e Leong (2015) propem um
sistema de monitoramento de nvel de gua em tempo real baseado em IoT, esta aplicao
foi estendida para gesto dos recursos hdricos sob condies climticas crticas por Fang
et al. (2014); Pang et al. (2015) concentram-se em uma mini-estao de gua inteligente
baseada na tecnologia de comunicao sem fios e sistema embutido; Shaohong e Shen
(2015) propem um sistema integrado baseado na IoT para monitoramento e gesto de
recursos hdricos em tempo-real.
Em todos os trabalhos levantados no MSL os Ns possuem acesso Internet, diferen-
temente desta dissertao, sendo esse um grande diferencial deste trabalho em relao a
todos os outros.
O Grupo Tragsa constitudo pela Empresa de Transformacin Agraria S.A. (Tragsa1 ),
fundada para a execuo de obras e servios de desenvolvimento rural, conservao am-
biental e operaes de socorro de emergncia na Espanha.
A Tragsa mantm o projeto MEGA2 que um modelo de como uma iniciativa especfica
para a Espanha, pode ser expandida para nveis europeus e internacionais. O MEGA
se prope a desenhar uma aplicao padro integrando tecnologias de IoT, a qual as
companhias de gesto de gua devem seguir. A diferena bsica que esta dissertao
prope uma arquitetura mais genrica, com opes de tcnicas e tecnologias, enquanto
1
http://www.tragsa.es/en/
2
http://www.gestiondelagua.es/en/
o MEGA fornece um modelo padro, engessado, para as companhias de gesto de gua,

no oferecendo alternativas de tecnologias ou servios que possam ser usados.
Brando, Summer e Farias (2016) em um trabalho acadmico propem uma aplicao
mvel a ser utilizada pelos Pipeiros para realizar o georreferenciamento dos Mananciais e
PAbst da OCP durante as atividades de coleta e entrega de gua, bem como, realizar o
agendamento dirio destas atividades.
Para o georreferenciamento a aplicao utilizada pelos Pipeiros durante a atividade
de coleta de gua nos Mananciais e entrega nos PAbst, de tal forma que a aplicao seja
capaz de ler cartes de QRCode de controle nestes pontos, verificar o georreferenciamento,
armazenar tais informaes localmente no dispositivo, enviando-as quando o aparelho tiver
sinal da operadora de telefonia ou estiver conectado a Internet. J para o agendamento
automtico do processo de entrega de gua, os autores desenvolveram um modelo de
previso de consumo de gua a partir dos dados fornecidos pela equipe do GCDA, sendo
a regresso linear simples a tcnica estatstica escolhida pela equipe para consecuo desse
objetivo.
Este trabalho tem algumas semelhanas com o trabalho proposto nesta disserta-
o, como por exemplo o uso de georreferenciamento e a utilizao da rede celular do
smartphone do Pipeiro. Porm, diferentemente desta dissertao, este trabalho no for-
nece servios para terceiros, constituindo assim apenas uma evoluo do GCDA. Outro
problema do trabalho proposto por Brando, Summer e Farias (2016) que ele no apre-
senta resultados nem qualquer tipo de avaliao quanto a seu trabalho.
6.3 Contribuies da Pesquisa

Como resultado do trabalho apresentado nesta dissertao, as seguintes contribuies
podem ser destacadas:
Estado da arte de SGRH: A partir da reviso da literatura executada foi possvel
apresentar um resumo a respeito do estado da arte de SGRH que utilizam IoT
como ferramenta de apoio, bem como uma anlise do modelo de distribuio de
gua empregado no Brasil e da utilizao da TI em apoio a este programa.
Requisitos de uma arquitetura para SGRH: Um conjunto de requisitos essenciais que
uma arquitetura para SGRH deve atender foi estabelecido a partir da anlise das
solues existentes e de estudos secundrios. Estes requisitos foram elicitados para
o cenrio especfico da distribuio de gua no semirido brasileiro, porm, devido
a sua generalizao, esses requisitos podem servir como base para a especificao e
implementao de outros SGRH.
Especificao, implementao e avaliao de uma arquitetura para monitoramento
da distribuio de gua: Foi especificada, implementada e avaliada uma arquitetura
que visa atender aos principais requisitos de um sistema para monitoramento da
distribuio de gua no semirido brasileiro que combina conceitos de IoT e Com-

putao em Nuvem. A Arquitetura Proposta, com algumas adaptaes, pode ser
empregada ou servir de base em outros domnios de distribuio de lquidos.
Implementao de referncia: Baseado na proposta desta dissertao, uma imple-
mentao de referncia foi realizada e disponibilizado em domnio pblico3 . Esta
implementao serve de guia para a utilizao desta proposta, onde pesquisadores
e profissionais podem basear-se para desenvolver e aplicar as tcnicas idealizadas e
implementas neste trabalho, como por exemplo:
Emprego de gateway mvel: Emprego de um gateway mvel para possibilitar
a comunicao entre dois mdulos onde um desses no tem acesso a Inter-
net, concebendo uma soluo de gateway mvel baseada em smartphone para
interoperabilidade IoT em SGRH.
Adaptao do emprego de assinatura digital: adaptao do emprego de Token
para autenticao de mensagens quando os receptores e transmissores no tm
contato entre si, atravs da tcnica de assinatura digital e gateway mvel.
Validao da adaptao de dois mtodos de avaliao de AS: Tomas (2014) props
uma adaptao de dois mtodos de avaliao de AS, a qual foi empregada nesta
avaliao. Como contribuio, esta dissertao pde comprovar sua utilidade tam-
bm para avaliar uma arquitetura de sistema, no apenas software. Este trabalho
contribuiu ainda elicitando e tratando algumas ameaas validade quando da uti-
lizao do mtodo empregado por Tomas (2014) e tambm props uma melhoria
para futuro emprego deste mtodo de avaliao de Arquitetura de Software.
6.4 Trabalhos Futuros

Alm deste trabalho apresentar as contribuies citadas na seo 6.3, outras perspectivas
so possveis. Diante disso, a seguir so listadas algumas direes para trabalhos futuros
desta pesquisa:
Comunicao em tempo-real: Projetar e especificar meios para que seja possvel
a comunicao em tempo-real com os Ns, a fim de visualizar o nvel de gua em
tempo-real, o que pode prover meios de predizer a real necessidade de cada cisterna;
Mecanismo de tolerncia a falhas: Melhorias na estratgia de redundncia de-
vem ser implementadas para que os servios no sejam afetados devido a uma even-
tual falha em algum ponto da arquitetura, principalmente no Gateway e no N;
Utilizao em ambiente real: A proposta atual dever ser implantada em um
ambiente real a partir de parceria com o Exrcito Brasileiro. Certamente essa etapa
vai contribuir com o aperfeioamento da Arquitetura Proposta, possibilitando ava-
liar outros atributos como performance e usabilidade;
3
https://github.com/wasufms/SGRH
Avaliao dos resultados: A partir de sua implementao em ambiente de pro-

duo ser possvel avaliar e mensurar os ganhos reais da utilizao da Arquitetura
Proposta para a Operao Carro-Pipa e por consequncia para o Programa Emer-
gencial de Distribuio de gua.
6.5 Possibilidade de Utilizao da Arquitetura em Outros Domnios

Esta Arquitetura Proposta, com algumas adaptaes, pode ser empregada em outros
domnios, no apenas na distribuio de gua no semirido brasileiro. Ela pode ser em-
pregada, por exemplo, para: (i) distribuio de combustveis lquidos, (ii) transporte e
armazenamento de leite e (iii) distribuio de gua em outras partes do mundo.
(i) Distribuio de combustveis lquidos
A distribuio de combustveis lquidos automotivos (gasolina, lcool hidratado e leo
diesel) no Brasil segue um modelo logstico bastante tradicional. H trs tipos de fluxos
existentes na distribuio de combustveis: fluxos primrios (das refinarias e usinas de
lcool para as bases de distribuio), fluxos de transferncia (entre bases) e fluxos de
entrega (das bases para os clientes). O modal rodovirio est presente na distribuio de
combustveis em 31% das transferncias e em 100% da entrega (FIGUEIREDO, 2015).
Os crimes relacionados ao transporte de combustveis lquidos trazem enormes pre-
juzos para o mercado, j que o combustvel desviado alimenta diversas irregularidades e
gera concorrncia desleal (GUIDONI, 2014). Constantemente a imprensa brasileira reporta
relatos de roubo, furto e desvio de combustvel, como por exemplo em esquemas onde os
motoristas no realizam a entrega completa prevista 4 . Por isso, essencial que se invista
em tecnologias para monitorar tanto os veculos quanto a carga transportada e entregue,
minimizando os danos causados por esses desvios (GUIDONI, 2014).
A Portaria ANP n 248, de 2000, dispe sobre o controle de qualidade do combustvel
automotivo lquido, estabelecendo algumas obrigaes ao revendedor, tais como: coleta
e anlise de amostra de cada compartimento do caminho; manuteno do registro das
anlises dos ltimos seis meses; e realizao de anlise sempre que solicitado.
Como se v, os problemas enfrentados pela atividade de distribuio de combustveis
lquidos no Brasil so bastante semelhantes a problemtica tema desta dissertao, o que
indica um possvel domnio de emprego da arquitetura proposta neste trabalho.
(ii) Transporte e armazenamento de leite cru
A produo leiteira no Brasil tem crescido nos ltimos tempos, colocando o pas entre
os maiores produtores e consumidores do mundo. Entre as condies essenciais para a
atividade leiteira esto o transporte e o armazenamento (SANTOS; SILVA, 2015).
4
http://www.diariodoscampos.com.br/policia/2011/02/policia-rodoviaria-flagra-desvio-de-
combustivel/1024319/
Devido a episdios de fraude, o setor leiteiro vem buscando se profissionalizar quanto ao

transporte, porm, ainda existem muitos desafios (RODRIGUES, 2015). Rodrigues (2015)
evidenciou algumas tecnologias que ainda no se tem neste setor no Brasil, mas que po-
deriam contribuir com toda a cadeia de transporte. A ideia seria instalar os equipamentos
nos caminhes tanques de modo a proporcionar a rastreabilidade completa do leite. Com
eles, seria possvel medir o volume do leite, a temperatura, tirar um amostra para testes
e fornecer o horrio e o local onde est se realizando a coleta do leite, tudo de forma
automtica e sem contato fsico com o transportador (RODRIGUES, 2015).
Muitas destas necessidades podem ser supridas usando as ideias chaves da arquitetura
proposta nesta dissertao, adaptando os sensores usados e as localizaes dos Ns.
(iii) Distribuio de gua em outras partes do mundo
Relatrios da Organizao Mundial da Sade repetem o diagnstico que mais de 1
bilho de pessoas, 18% da populao mundial, no tm acesso a uma quantidade mnima
aceitvel de gua potvel, e que dois teros da populao do planeta em 2025 podero
no ter acesso gua limpa (JMP, 2016).
O abastecimento de gua urbana na ndia enfrenta srios desafios, incluindo a inefi-
cincia da distribuio, devido a limitao de recursos e a ausncia de tecnologia para
manter e monitorar o processo (ANJANA et al., 2015). Segundo Rahman et al. (2016), este
cenrio semelhante na maioria dos pases em desenvolvimento. Assim, seguindo o mo-
delo adotado no Brasil ou realizando algumas adaptaes, quanto a sensores e legislao,
acredita-se que esta Arquitetura Proposta pode ser empregada para apoiar a distribuio
de gua em diferentes partes do mundo.
6.6 Concluso
Hoje em dia, um dos grandes problemas enfrentados pela humanidade o de gerir a
escassez de gua. Na regio Semirida brasileira a falta de gua faz com que a populao
carente fique submetida a condies de extrema dificuldade. A fim de mitigar essa situao,
no ano de 2016 foram gastos mais de 1 bilho de Reais em programas de distribuio de
gua, dos quais cerca de 14% desse recurso foi gasto em fiscalizao. Frequentes notcias
de fraudes comprovam que essa fiscalizao mostra-se de certa forma ineficiente.
Neste sentido, esta dissertao apresentou uma arquitetura que usa a integrao de tec-
nologias de IoT e Computao em Nuvem para implementar uma Arquitetura de Software
que disponibilize servios para orquestrar a distribuio de gua no Semirido brasileiro.
Conforme as avaliaes discutidas no captulo 5, possvel concluir que todos os obje-
tivos, tanto o geral quantos os especficos, foram atingidos, comprovando a hiptese deste
trabalho: possvel especificar, projetar e implementar uma arquitetura baseada em In-
ternet das Coisas e Computao em Nuvem que disponibilize servios para orquestrar a
distribuio de gua no Semirido brasileiro.
105
Referncias
AGRAWAL, H. Elliptic curve cryptography using Koblitz encoding method. v. 3, p.

418422, 2013.
AGUSTIN, P. Top IoT Platforms for Makers. 2017. Disponvel em: <http:
//blog.ubidots.com/top-iot-platforms-2016>.
AHAMED, A.; SOHAG, H.; AHMAD, M.; W. Development of Low Cost Wireless ECG
Data Acquisition System. p. 7275, 2015.
AL-FUQAHA, A.; GUIZANI, M.; MOHAMMADI, M.; ALEDHARI, M.; AYYASH, M.
Internet of Things: A Survey on Enabling Technologies, Protocols and Applications.
IEEE Communications Surveys & Tutorials, PP, p. 11, 2015.
ANJANA, S.; SAHANA, M. N.; ANKITH, S.; NATARAJAN, K. An IoT based
6LoWPAN enabled Experiment for Water Management. p. 16, 2015.
ASHTON, K. That Internet of Things Thing. p. 4986, 2009.
ATZORI, L.; IERA, A.; MORABITO, G. The internet of things: A survey. Comput.
Netw., 2010.
BALAMURALIDHAR, P.; MISRA, P.; PAL, A.; W. Software platforms for internet of
things and M2M. Journal of the Indian Institute of Science, v. 93, p. 487497, 2013.
BASS, L.; NORD, R. L. Understanding the context of architecture evaluation methods.
Proceedings of the 2012 Joint Working Conference on Software Architecture and 6th
European Conference on Software Architecture, WICSA/ECSA 2012, p. 277281, 2012.
BATISTA, T.; W; W; W; W. SmartMetropolis - Plataformas e Aplicaes para Cidades
Inteligentes. Universidade Federal do Rio Grande do Norte - Instituto Metrpole Digital,
p. 47, 2016.
BONOMI, F.; MILITO, R.; ZHU, J.; ADDEPALLI, S. Fog Computing and Its Role in
the Internet of Things. Proceedings of the first edition of the MCC workshop on Mobile
cloud computing, p. 1316, 2012. Disponvel em: <http://doi.acm.org/10.1145/2342509.
2342513{\%}5Cnpapers2://publication/doi/10.1145/2342509.2342>.
BORGIA, E. The internet of things vision: Key features, applications and open
issues. Computer Communications, Elsevier B.V., v. 54, 2014. Disponvel em:
<http://dx.doi.org/10.1016/j.comcom.2014.09.008>.
BOTTA, A.; DONATO de; PERSICO, V.; PESCAPE, A. On the integration of cloud
computing and internet of things. 2nd international conference on future IoT and CC,
p. 279, 2014.
BRANDO, O.; SUMMER, H.; FARIAS, G. Georreferenciando a Operao Pipa com
um sistema mvel em Android - PipaGeo. 2016.
BRERETON, P. Lessons from applying the systematic literature review process within
the software engineering domain. Journal of Systems and Software, p. 571-583, 2007.
Referncias 106
BUSCHMANN, F.; KIRCHER, M.; VOLTER, M.; W. Pattern-Oriented Software

Architecture. A System of Patterns. New York, USA, 1996.
CASTRO, M.; JARA, A. J.; SKARMETA, A. F.; W. An analysis of M2M platforms:
Challenges and opportunities for the internet of things. Proceedings - 6th International
Conference on Innovative Mobile and Internet Services in Ubiquitous Computing, IMIS
2012, p. 757762, 2012.
CHAQFEH, M. A.; MOHAMED, N. Challenges in middleware solutions for the internet
of things. in Proc. Int. Conf. CTS, 2012.
CHEN; YEN-KUANG. Challenges and opportunities of internet of things. 17th Asia and
South Pacific Design Automation Conference, p. 383388, 2012.
DASH, S. K.; MOHAPATRA, S.; PATTNAIK, P. K.; WAS. A Survey on Applications
of Wireless Sensor Network Using Cloud Computing. International Journal of Computer
Science & Emerging Technologies, 2010.
DIAZ, M.; CRISTIAN, M.; RUBIO, B. State-of-the-art, challenges, and open
issues in the integration of Internet of Things and Cloud Computing. Journal
of Network and Computer Applications, Elsevier, p. 119, 2016. Disponvel em:
<http://dx.doi.org/10.1016/j.jnca.2016.01.010>.
FANG, S.; XU, L. D.; ZHU, Y.; AHATI, J.; PEI, H.; YAN, J.; LIU, Z. An integrated
system for regional environmental monitoring and management based on internet of
things. IEEE Transactions on Industrial Informatics, v. 10, n. 2, p. 15961605, 2014.
FERSI, G. A Distributed and Flexible Architecture for Internet of Things. Procedia
Computer Science, Elsevier Masson SAS, v. 73, p. 130137, 2015. Disponvel em:
<http://dx.doi.org/10.1016/j.procs.2015.12.058>.
FIGUEIREDO, R. Gargalos logsticos na distribuio de combustveis brasileira. 2015.
FOX, G.; KAMBURUGAMUVE, S.; HARTMAN, R. D.; HARTMAN, R. D. Architecture
and measured characteristics of a cloud based internet of things. Proc. Int. Conf.
Collaboration Technologies and Systems (CTS), IEEE, p. 612, 2012.
GCDA. Sistema de Gesto e Controle de Distribuio de gua. Acesso: maio/2017.
2017. Disponvel em: <https://intranet.gcda.eb.mil.br>.
GOLCHAY, R.; F.MOUEL; FRENOT, S.; PONGE, J. Towards Bridging IoT and Cloud
Services: Proposing Smartphones as Mobile and Autonomic Service Gateways. 2011.
GUIDONI, R. Gesto de riscos contra o roubo de cargas. 2014.
GUSTAVO, S. Q.; ADMILSON, R. L. R.; DAVID, M. E.; W. Asymmetric Encryption in
Wireless Sensor Networks. Intech, p. 116, 2012.
JMP. Progress on Drinking Water and Sanitation. 2016. Disponvel em: <https:
//www.wssinfo.org/>.
KAINDL, H.; BRINKKEMPER, S.; BUBENKO, J.; FARBEY, B.; GREENSPAN,
S.; HEITMEYER, C. Requirements Engineering and Technology Transfer: Obstacles,
Incentives and Improvement Agenda. Requirements Engineering, v. 7, n. 1, p. 113123,
2002.
Referncias 107
KAZMAN, R.; ABOWD, G.; BASS, L.; CLEMENTS, P. Scenario-based analysis of

software architecture. IEEE Software, v. 13, n. 6, p. 114, 1996.
KAZMAN, R.; BASS, L.; WEBB, M.; ABOWD, G.; WEBB, M. SAAM: a method for
analyzing the properties of software architectures. Proceedings of 16th International
Conference on Software Engineering, p. 8190, 1994.
KAZMAN, R.; KLEIN, M.; BARBACCI, M.; LONGSTAFF, T.; LIPSON, H.;
CARRIERE, J. The architecture tradeoff analysis method. Engineering of Complex
Computer Systems, 1998. ICECCS 98. Proceedings. Fourth IEEE International
Conference on, p. 6878, 1998.
KAZMAN, R.; KLEIN, M.; CLEMENTS, P.; W. ATAM : Method for Architecture
Evaluation. Cmusei, p. 83, 2000.
KHAN, R.; KHAN, S. U.; ZAHEER, R.; KHAN, S. Future internet: The internet of
things architecture,possible applications and key challenges. in the proceedings of 10th
International Conference on Frontiers of Information Technology, Islamabad, Pakistan,
p. 1719, 2012.
KITCHENHAM, B. Evidence-basedsoftware engineering. 26th International Conference
on Software Engineering, p. 113123, 2004.
KITCHENHAM, B. Guidelines for performing systematic literature reviews in software
engineering. Technical Report EBSE 2007, 2007.
KNODEL, J.; NAAB, M. Software architecture evaluation in practice: Retrospective on
more than 50 architecture evaluations in industry. Proceedings - Working IEEE/IFIP
Conference on Software Architecture 2014, WICSA 2014, p. 115124, 2014.
KHLER, M.; WRNER, D.; WORTMANN, F.; W. Platforms for the Internet of
Things An Analysis of Existing Solutions. 2014.
KONSTANTINOS, L.; EFTICHIOS, K.; DIMITRIOS, Z.; GEORGIOS, L. A low-cost
sensor based on Time-Domain Reflectometry for water level monitoring in environmental
applications. 2015 IEEE 15th International Conference on Environment and Electrical
Engineering (EEEIC), p. 261266, 2015.
KORTUEM, G.; KAWSAR, F.; FITTON, D.; SUNDRAMOORTHY, V. Smart objects
as building blocks for the internet of things. IEEE Internet Computing, p. 4451, 2010.
KRCO, S.; POKRIC, B.; CARREZ, F. Designing iot architecture(s): A european
perspective. in Proc. IEEEWF-IoT, 2014, 2014.
KRUCHTEN, P. The 4+1 View Model of Architecture. IEEE Softw., Los Alamitos, CA,
USA, p. 4250, 1995.
KUDVA, V.; AKSHAY, K.; NIHESH, R.; PRATIK, J.; MALLIKARJUN, S. Twards a
real-teme campus-scale water balance monitoring system. VLSI Design, 2014.
LAINE, T. H.; LEE, C.; SUK, H.; W. Mobile Gateway for Ubiquitous Health Care
System Using ZigBee and Bluetooth. 2014 Eighth International Conference on Innovative
Mobile and Internet Services in Ubiquitous Computing, p. 139145, 2014. Disponvel em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6975454>.
Referncias 108
LEVY, N.; LOSAVIO, F. Analyzing and Comparing Architectural Styles. Proceedings of

the 19th International Conference of the Chilean Computer Science Society, p. 87, 1999.
LOIZOU, K.; KOUTROULIS, E. Water level sensing: State of the art review and
performance evaluation of a low-cost measurement system. Measurement, Elsevier Ltd,
v. 89, p. 204214, 2016.
LOPES, F. C. O uso da Tecnologia de Geoinformao no planejamento das aes de

fiscalizao do Programa de Distribuio Emergencial de gua no semirido brasileiro:
um estudo de caso no mbito do Comando Militar do Nordeste. 2016.
MAFRA, S.; RAFAEL, F.; TRAVASSOS. Aplicando uma Metodologia Baseada em

Evidncia na Definio de Novas Tecnologias de Software. XX Simpsio Brasileiro de
Engenharia de Software, p. 239254, 2006.
MAIA, P.; EVERTON, C.; GOMES, P.; BATISTA, T.; DELICATO, F. On the
Development of Systems-of-Systems based on the Internet of Things. Proceedings of the
2014 European Conference on Software Architecture Workshops - ECSAW 14, p. 18,
2007. Disponvel em: <http://dl.acm.org/citation.cfm?id=2642803.2642828>.
MASHAL, I.; ALSARYRAH, O.; CHUNG, T. Y.; YANG, C. Z.; KUO, W. H.;
AGRAWAL, D. P. Choices for interaction with things on Internet and underlying
issues. Ad Hoc Networks, Elsevier B.V., v. 28, p. 6890, 2015. Disponvel em:
<http://dx.doi.org/10.1016/j.adhoc.2014.12.006>.
MAZHELIS, O. A framework for evaluating Internet-of-Things platforms: Application

provider viewpoint. Internet of Things (WF-IoT), 2014 IEEE World Forum on, p.
147152, 2014.
MEIRA, S.; BURGIO, V.; BORBA, P.; GARCIA, V.; ALBUQUERQUE,

J.; SOARES, S. Programming the Universe. Proceedings of the 30th Brazilian
Symposium on Software Engineering - SBES 16, p. 153156, 2016. Disponvel em:
<http://dl.acm.org/citation.cfm?doid=2973839.2982567>.
MEIRELLES, S. F. 27 Pesquisa Anual do Uso de TI. 2016. Disponvel em:

<http://eaesp.fgvsp.br/sites/eaesp.fgvsp.br/files/pesti2016gvciappt.pdf>.
MELL; PETER; GRANCE; TIMOTHY. The NIST definition of cloud computing. NIST
Special Publication, v. 145, p. 7, 2011. Disponvel em: <http://www.mendeley.com/
research/the-nist-definition-about-cloud-computing/>.
MERRIAM, B. S. Qualitative Research A Guide to Design and Implementation. [S.l.:

s.n.], 2009.
MIAO, W. Research on the architecture of internet of things. 3rd International

Conference on Advanced Computer Theory and Engineering, p. 2022, 2012.
MINERAUD, J.; MAZHELIS, O.; SU, X.; TARKOMA, S. A gap analysis of Internet-
of-Things platforms. Computer Communications, Elsevier B.V., v. 89-90, p. 516, 2016.
Disponvel em: <http://dx.doi.org/10.1016/j.comcom.2016.03.015>.
Referncias 109
PADILHA, J. A.; ZANGHETIN, M. F. L.; ORTEGA, E.; ORTEGA, E. O uso da gua

nas microbacias hidrogrficas do semirido do nordeste brasileiro e o conceito base zero.
In: . [S.l.]: Proceedings of IV Biennial International Workshop Advances in Energy
Studies., 2004. p. 6572.
PANG, X.; HONG, W.; YAO, X.; MIAO, M. Design and implementation of a smart
mini-base station for the internet of things. Asia-Pacific Microwave Conference (APMC),
v. 3, p. 13, 2015.
PARTYNSKI, D.; KOO, S. G. M. Integration of Smart Sensor Networks into

Internet of Things: Challenges and Applications. 2013 IEEE International Conference
on Green Computing and Communications and IEEE Internet of Things and
IEEE Cyber, Physical and Social Computing, p. 11621167, 2013. Disponvel em:
PASSADOR, J. L.; CLAUDIA, S. Apontamentos sobre as polticas pblicas de combate

seca no Brasil: cisternas e cidadania? Cadernos Gesto Pblica e Cidadania, v. 15,
n. 56, p. 6586, 2010.
PATIDAR, A.; SUMAN, U. A survey on software architecture evaluation methods.

2015 2nd International Conference on Computing for Sustainable Global Development
(INDIACom), p. 967972, 2015.
PEREIRA, C.; AGUIAR, A. Towards efficient mobile M2M communications: survey and
open challenges. Sensors (Basel, Switzerland), v. 14, n. 10, p. 1958219608, 2014.
PERUMAL, T.; NASIR, S.; LEONG, C. Y. Internet of Things ( IoT ) Enabled Water
Monitoring System. p. 8687, 2015.
PRACHET, V.; AKSHAY, K.; NIHESH, R.; PRATIK, J.; MALLIKARJUN, S. Towards
an IoT Based Water Management System for a Campus. 2015.
RAHMAN, S. M. M.; ALHUSSEIN, M.; MUHAMMAD, G.; ABDULLAH, K.; MAMUN,

A. Enhancing Safety in Water Transport System Based on Internet of Things for
Developing Countries. v. 2016, 2016.
RAMAKRISHMAN, L.; JACKSON, K. R.; CANON, S.; CHOLIA, S.; SHALF, J.

Defining future platform requirements for e-science clouds. In ACM symposium on Cloud
computing, 2010.
RAO, B.; SALUIA, P.; SHARMA, N.; MITTAL, A.; SHARMA, S. V. Cloud computing
for internet of things & sensing based applications. Proc. 6th Int. Conf. Sensing
Technology (ICST), IEEE, p. 374380, 2012.
ROBLES, T.; ALCARRIA, R.; MARTIN, D.; MORALES, A. An internet of things-

based model for smart water management. 28th International Conference on Advanced
Information Networking and Applications Workshops, v. 1, p. 821826, 2014.
RODRIGUES, R. M. C. Transporte de leite no Brasil: avanos, desafios e tendncias.

2015. Disponvel em: <https://www.milkpoint.com.br/industria/cadeia-do-leite/
giro-de-noticias/transporte-de-leite-no-brasil-avancos-desafios-e-tendencias-97640n.
aspx>.
Referncias 110
SANCHEZ, L. Smartsantander: the meeting point between future internet research and
experimentation and the smart cities. FUTURE NETWORK & MOBILE SUMMIT
(FUTURENETW), p. 18, 2011.
SANTOS, D. F.; SILVA, T. D. Logstica interna de armazenagem e transporte do leite

de pequenos produtores rurais de Silveirnia: o caso da Associao APRUS. 2015.
SMOLA, M. Gesto Da Segurana Da Informao. ELSEVIER EDITORA, 2003.

Disponvel em: <https://books.google.com.br/books?id=eZ2OAAAACAAJ>.
SEOL, S.; SHIN, Y.; KIM, W.; W. Design and realization of personal IoT architecture
based on mobile gateway. International Journal of Smart Home, v. 9, p. 133144, 2015.
SHAOHONG; SHEN, M. X. Q. X. J. An IoT-Based System for Water Resources

Monitoring and Management. 2015 7th International Conference on Intelligent
Human-Machine Systems and Cybernetics, p. 365368, 2015. Disponvel em:
SIAFI. Sistema Integrado de Administrao Financeira do Governo Federal. 2017.

Disponvel em: <https://siafi.tesouro.gov.br>.
SILVA, E.; OLIVEIRA, M. I. S.; OLIVEIRA, E.; GAMA, K. S.; LOSCIO, B. ernadette
F. arias. Um Survey sobre Plataformas de Mediao de Dados para Internet das Coisas.
42o SEMISH - Seminrio Integrado de Software e Hardware, 2015.
SUCIU, G.; VULPE, A.; HALUNGA, S.; FRATU, O.; TODORAN, G.; SUCIU, V.
Smart Cities Built on Resilient Cloud Computing and Secure Internet of Things. In
Control Systems and Computer Science (CSCS), 2013.
SUCIU, G.; VULPE, A.; S.HALUNGA; FRATU, O.; G.TODORAN; SUCIU, V. Smart
cities built on resilient cloud computing and secure internet of things. 19th Int. Conf.
Control Systems and Computer Science (CSCS), IEEE, p. 513518, 2014.
SURESH, P.; DANIEL, J. V.; PARTHASARATHY, V.; ASWATHY, R. H. A

state of the art review on the Internet of Things (IoT) history, technology and
fields of deployment. 2014 International Conference on Science Engineering
and Management Research (ICSEMR), p. 18, 2014. Disponvel em: <http:
//ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=7043637>.
SUTIKNO, S.; SURYA, A.; EFFENDI, R.; PAUL, W. An Implementation of Type :

Type. p. 5362, 2002.
TELECOM. Brasil Telecom. 2016. Disponvel em: <http://www.teleco.com.br/>.
TOMAS, G. H. R. P. Uma Arquitetura Para Cidades Inteligentes Baseada Na Internet

Das Coisas. Recife. Universidade Federal de Pernambuco, 2014.
WHITMORE, A.; ANURAG, A.; XU, L. D.; XU, L. D. The Internet of Things???A
survey of topics and trends. Information Systems Frontiers, v. 17, n. 2, p. 261274, 2015.
WILEY. Systematic Requirements Engineering - From System Goals to UML Models to

Software Specifications. [S.l.: s.n.], 2008.
Referncias 111
WU, G.; TALWAR, S.; JOHNSSON, K. M2M: From mobile to embedded internet. IEEE
Commun, 2011.
WU, M.; LU, T. J.; LING, F. Y.; SUN, J.; DU, H. Y. Research on the architecture of
internet of things. in Proc. 3rd ICACTE, 2010.
ZDUN, U.; KIRCHER, M.; VOLTER, M.; W. Remoting patterns: design reuse of
distributed object middleware solutions. IEEE Internet Computing, p. 6068, 2004.
ZHANG, Y.; YU, R.; XIE, S. Home M2M networks: Architectures, standards, and QoS
improvement. IEEE Commun, 2011.
ZHOU, C.; ZHANG, X. Toward the internet of things application and management:
A practical approach. Proceeding of IEEE International Symposium on a World of
Wireless, Mobile and Multimedia Networks 2014, Elsevier, 2014. Disponvel em: <http:
//www.scopus.com/inward/record.url?eid=2-s2.0-84908876758&partnerID=tZOtx3y1>.
ZHOU, H. The internet of things in the cloud: Amiddleware perspective. 1st ed. Boca
Raton, p. 3540, 2012.
ZHOU, M.; ZHANG, R.; ZENG, D.; QIAN, W. Services in the cloud computing era:
a survey. Proceedings of the 4th International Universal Communication Symposium,
IEEE, USA, p. 4046, 2010.
Apndices
113
APNDICE A Artigos Selecionados MSL
Id Ttulo Autores Ano

A1 Ubiquitous greenhouse monitoring system Rao et al. 2015
A2 Tethys - An Energy Harvesting Networked Water Flow Sensor Chiang et al 2015
A3 On the application of IoT: Monitoring of troughs water level using WSN Lukas et al. 2016
A4 QoWater: A crowd-sourcing approach for assessing the water quality Rapousis et al. 2015
Low cost system for detecting leakages along artificial dikes
A5 Schulz et al. 2008
with wireless sensor networks
Design and development of a flood warning system via
A6 A. Dersingh 2016
mobile and computer networks
A case study of internet of things: A wireless household
A7 Yang et al. 2015
water consumption monitoring system
Agricultural Drought Data Acquisition and Transmission
A8 Liu Ping 2014
System Based on Internet of Things
Real-time environmental sensor data: An application to
A9 Brandon et al. 2016
water quality using web services
Surveillance and steering of irrigation system in cloud using
A10 N Kabilan 2016
Wireless Sensor Network and Wi-Fi module
A11 Tethys: Sensor-Based Aquatic Quality Monitoring in Waterways Tzortzakis et al. 2016
Grid-based wide area water quality measurement system for
A12 J. Konyha 2016
surface water
A13 The real time monitoring of water quality in IoT environment N. Vijayakumar 2015
A14 Smart water quality monitoring system Prasad et al. 2016
A15 Water Level Meter for Alerting Population about Floods Nolasco et al. 2016
GSM and Web Application based Real-Time Automatic
A16 Dhanekula et al. 2016
Irrigation System using Raspberry pi 2 and 8051
Wireless sensor and actuator system for smart irrigation
A17 Sales et al. 2015
on the cloud
The application of internet of things system for water
A18 Yuwono et al. 2016
quality monitoring
Design and implementation of wearable device for water
A19 Khurana et al. 2016
management system for household usage
A semi-supervised approach for water quality detection based
A20 Ye Yuan 2016
on IoT network
Urban water supply network monitoring and management
A21 L. Cai et al. 2016
platform based on wireless sensor network
An android based automatic irrigation system using a
A22 Reddy et al. 2016
WSN and GPRS module
Surface and underground water level monitoring using
A23 Mihajlovic et al. 2016
wireless sensor node with energy harvesting support
A24 Towards an IoT based water management system for a campus Verma et al 2015
Challenges and solutions for advanced sensing of water
A25 Suciu et al. 2015
infrastructures in urban environments
A26 Design of a water management system Ntambi et al. 2015
APNDICE A. Artigos Selecionados MSL 114
A27 Smart irrigation using internet of things Khelifa et al. 2015

A28 Smart water meter system for user-centric consumption measurement Mudumbe 2015
Heterogeneous wireless sensor networks for flood
A29 Andersson et al. 2015
prediction decision support systems
A30 Regulation of water in agriculture field using Internet Of Things Ram et al. 2015
Remote monitoring approach for contamination
A31 Mudumbe et al. 2015
detection in drinking water
An IoT based 6LoWPAN enabled experiment
A32 Anjana et al. 2015
for water management
A33 Water parameters monitoring on a cyberwater platform Vacariu et al. 2015
ZigBee wireless sensor network for surface
A34 Chan et al. 2015
drainage monitoring and flood prediction
An integrated system for advanced water risk
A35 Haijiang Tai et al. 2015
management based on cloud computing and IoT
Automated Monitoring System for the Fish Farm
A36 Jui-Ho Chen et al. 2015
Aquaculture Environment
A37 PIPENET a wireless sensor network for pipeline monitoring Stoianov et al. 2007
Smart water monitoring and management system based
A38 Bo Cui et al. 2013
on the architecture of internet of things
Prototype of an Aquacultural Information
A39 Daokun Ma et al. 2012
System Based on Internet of Things E-Nose
A40 Embedding wireless water monitoring system in Internet Diziadak et al. 2011
Framework for a Smart Water Management System
A41 Shahanas et al. 2016
in the Context of Smart City Initiatives in India
A42 Intelligent flood information system via SMS (IFIS) Hussin et al. 2012
Hydrological Monitoring System Design and
A43 Kun Han et al. 2012
Implementation Based on IOT
Smart Rainwater Tanks as a Rainguage Network
A44 Moriyama et al. 2016
and Dam for Flood Control
IWCMSE: Integrated Water Consumption
A45 Patil et al. 2014
Monitoring Solution for Enterprises
An IoT-Based System for Water Resources
A46 Xiaocong et al. 2015
Monitoring and Management
B1 Precision Irrigation using Wireless Sensor Network Harun et al. 2015
Design and Construction of Early Flood Warning System
B2 Kuantama et al. 2013
Through SMS based on SIM300C GSMModem
Design and Construction of Water Level measurement
B3 Saraswati et al. 2012
System Accessible Through SMS
B4 Early Flood Alerts Using Short MessageService (SMS) Kuantama et al. 2012
B5 Internet of Things (IoT) Enabled WaterMonitoring System Perumal et al. 2015
B6 Monitoring of Water Level Based on Acoustic Emissions Micek et al. 2015
Real Time Wireless Monitoring and Control of Water
B7 Maqbool et al. 2013
Systems using Zigbee802.15.4
An enhanced underground pipelineWater leakage
C1 Lakshmi et al. 2015
monitoring and Detection system using wirelessSensor network
Towards a Real-Time Campus-Scale Water
C2 Kudva et al. 2015
Balance Monitoring System
Tabela 17 MSL - Artigos selecionados
115
APNDICE B Tabela de Avaliao das

Tecnologias de Comunicao para SGRH
Figura 35 Avaliao das Tecnologias de Comunicao para SGRH
Fonte: o Autor
116
APNDICE C Descrio dos Servios e

Caractersticas Desejveis em uma Plataforma
de IoT
(i). Servios desejveis em uma Plataforma de IoT

a. Servios de Gerenciamento de Dispositivos: registrar sensores e dispositivos de gateway, identific-los e
endere-los, entre outras tarefas de gerenciamento.
b. Servios de Sensores: registrar sensores na plataforma e criar meta-dados. Os Servios de Sensores precisam
escalar facilmente medida que o nmero de sensores e precisam ter a capacidade de lidar com uma grande variedade
de sensores.
c. Servios de Armazenamento: armazenar dados de aplicativos de forma contnua em banco de dados relacional
e no relacional, NoSQL e arquivos Blob.
d. Servios de Analytics: fornecer a infraestrutura para executar anlises em lotes e em tempo real nas observa-
es dos sensores. Inclui minerao de dados, agregaes e correlaes, deteco de padres, processamento baseado
em regras, entre outros.
e. Visualizao dos dados dos Sensores: fornecer ferramentas e APIs necessrias para criar visualizao rica
dos dados capturados dos sensores, bem como dados processados resultantes de anlise.
(ii). Caractersticas desejveis em uma Plataforma de IoT
Descoberta de recursos: deve permitir a descoberta de recursos de forma automatizado. Mecanismos de desco-
berta tambm precisam escalar bem, e deve haver uma distribuio eficiente da carga de descoberta.
Gerenciamento de recursos: importante que os aplicativos sejam fornecidos com um servio que os gerencie.
Isso significa que o uso de recursos deve ser monitorado, os recursos sejam provisionados de maneira justa.
Gesto de dados: em IoT, os dados referem-se a informaes detectadas pelos sensores. Uma plataforma de dados
IoT precisa fornecer servios de gerenciamento de dados para aplicativos, incluindo aquisio, processamento e
armazenamento.
Gerenciamento de Eventos: deve transformar eventos observados simples em eventos significativos, de forma
que as aplicaes sejam orientadas a informaes precisas, em tempo real e inteligentes.
Gerenciamento de cdigo: a implantao de cdigo em um ambiente IoT deve ser diretamente suportada pela
plataforma de mediao de dados.
Escalabilidade: uma plataforma de mediao de dados de IoT precisa ser escalvel para acomodar o crescimento
na rede e aplicaes/servios de IoT.
Tempo real ou oportunidade: uma plataforma de mediao de dados deve fornecer servios em tempo real
quando a correo de uma operao dependa no apenas da sua correo lgica, mas tambm do tempo em que
executada.
Confiabilidade: uma plataforma de mediao de dados deve permanecer operacional durante a durao de uma
tarefa, mesmo na presena de falhas. Cada componente ou servio precisa ser confivel para obter confiabilidade
geral do sistema.
Disponibilidade: uma plataforma de mediao de dados deve estar disponvel em todos os momentos. Os requisitos
de confiabilidade e disponibilidade devem trabalhar juntos para garantir a maior tolerncia a falhas.
Mobilidade: cada dispositivo em IoT deve ser capaz de anunciar sua existncia e os recursos que ele fornece sem
a necessidade de uma infraestrutura fixa, devido alta distribuio e mobilidade dos dispositivos IoT.
Segurana e privacidade: em uma plataforma de mediao de dados de IoT a segurana precisa ser considerada
em todos os blocos funcionais e no funcionais, incluindo o aplicativo de nvel de usurio e infraestrutura da
plataforma.
Proviso de Abstrao: uma plataforma de mediao de dados deve fornecer abstraes em vrios nveis, tais
como dispositivos heterogneos de hardware, interfaces de hardware e software, fluxos de dados e processo de
desenvolvimento.
Facilidade de implantao: uma vez que uma plataforma de mediao de dados de IoT ou atualizaes desta
plataforma normalmente implementado pelo usurio, a implantao deve ser facilitada.
Popularidade: uma plataforma de mediao de dados deve ser continuamente suportado e estendido. Geralmente,
esta facilidade fornecida dentro de uma comunidade de colaboradores e de pesquisadores.
Abstrao de Programao: fornecer uma API para desenvolvedores de aplicativos de forma a isolar o desenvol-
APNDICE C. Descrio dos Servios e Caractersticas Desejveis em uma Plataforma de IoT 117
vimento das aplicaes ou servios das operaes fornecidas pelas infraestruturas IoT subjacentes e heterogneas.
Interopervel: deve funcionar com dispositivos, tecnologias e aplicativos heterogneos, sem esforo adicional do de-
senvolvedor. Os componentes devem trocar informaes atravs de diferentes redes, potencialmente com tecnologias
diferentes.
Baseado em servios: uma arquitetura de plataforma de mediao de dados deve ser baseada em servios para
oferecer alta flexibilidade quando novas funes precisem ser adicionadas a plataforma.
Adaptativo: uma plataforma de mediao de dados precisa ser adaptativo para que possa evoluir para se adaptar
a mudanas em seu ambiente ou contexto. Em IoT a rede e seu ambiente mudam frequentemente.
Context-aware: a arquitetura de plataforma de mediao de dados de IoT precisa estar atenta ao contexto dos
usurios, dispositivos e ambiente e us-los para oferecer servios eficazes e essenciais aos usurios.
Autnomo: significa autogovernado. Os dispositivos, tecnologias e aplicaes so participantes nos processos de
IoT e devem ser capacitados de interagir e comunicarem-se entre si sem interveno humana direta.
Distribudo: Os aplicativos, dispositivos e usurios de um sistema IoT em larga escala trocam informaes e
colaboram entre si. Uma implementao de uma plataforma de mediao de dados precisa suportar funes que so
distribudas atravs da infraestrutura fsica do ambiente de IoT.

Uma Arquitetura para Orquestração Da Distribuição de Água No Semiárido Brasileiro Baseada em Internet Das Coisas e Computação em Nuvem

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Uma Arquitetura para Orquestração Da Distribuição de Água No Semiárido Brasileiro Baseada em Internet Das Coisas e Computação em Nuvem

Caricato da

Copyright:

Formati disponibili

Wilson Alves da Silva

Uma Arquitetura para Orquestrao da

Universidade Federal de Pernambuco

Uma Arquitetura para Orquestrao da Distribuio de

Trabalho apresentado ao Programa de Ps-

Universidade Federal de Pernambuco

Orientador: Vincius Cardoso Garcia

Prof. Dr. Kiev Santos da Gama

Prof. Dr. Nelio Alessandro Azevedo Cacho

Prof. Dr. Orientador: Vincius Cardoso Garcia

Visto e permitida a impresso.

Prof. Aluizio Fausto Ribeiro Arajo

A todos, os meus mais sinceros agradecimentos.

Palavras-chaves: Internet das Coisas, Computao em Nuvem, Engenharia de Software

Key-words: Internet of Things, Cloud Computing, Evidence-Based Software Engineer-

Figura 1 Elementos da Internet das Coisas . . . . . . . . . . . . . . . . . . . . . 21

Tabela 1 Padres Arquiteturais. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

BLE Bluetooth Low Energy.

ESBE Engenharia de Software Baseada em Evidncias.

GCDA Sistema de Gesto e Controle de Distribuio de gua.

IoT Internet das Coisas.

LAN Rede de rea Local.

MEM Mdulo Embarcado de Monitoramento.

MSL Mapeamento Sistemtico da Literatura.

OCP Operao Carro-Pipa.

OME Organizaes Militares Executoras.

PAbst Ponto de Abastecimento.

PMES Primeiro Mandamento da Engenharia de Software.

SGRH Sistemas de Gerenciamento de Recursos Hdricos.

WAN Rede de Longa Distncia.

Wi-Fi Wireless Fidelity.

WSN Rede de Sensores Sem Fio.

5 AVALIAO DA ARQUITETURA PROPOSTA . . . . . . . . . . . 85

APNDICE A ARTIGOS SELECIONADOS MSL . . . . . . . . . 113

APNDICE B TABELA DE AVALIAO DAS TECNOLOGIAS

APNDICE C DESCRIO DOS SERVIOS E CARACTERS-

1.1 Motivao e Justificativa

Em dezembro de 2013 uma equipe de reportagem de uma importante rede de televi-

Em janeiro de 2017 um motorista de um caminho-pipa foi flagrado pela Polcia

Motivado por esses fatos e dada a importncia do programa de distribuio de gua

Diante disto, a hiptese que conduz este trabalho :

1.4.1 Objetivos Geral

1.4.2 Objetivos Especficos

2. Mapear as principais tecnologias e tcnicas empregadas em Sistemas de Gerencia-

3. Discutir um conjunto de requisitos fundamentais que devem ser atendidos na im-

4. Especificar uma arquitetura baseada em IoT e Computao em Nuvem para SGRH;

5. Projetar e implementar uma AS para um SGRH para orquestrar a distribuio de

6. Avaliar a Arquitetura proposta.

1.5 Escopo Negativo

Comunicao em tempo-real: Embora seja de suma importncia, a comunicao

Controle a fraudes especficas: Este trabalho uma contribuio para um melhor

Predio de necessidade de abastecimento de cisternas: Este projeto no prev meios

1.6 Organizao da Dissertao

Captulo 2: apresenta o referencial terico utilizado durante o desenvolvimento

Captulo 3: apresenta uma reviso da literatura, onde realizada uma anlise do

Captulo 4: apresenta a Arquitetura Proposta, onde: define os requisitos para um

Captulo 5: discute o processo de avaliao da Arquitetura Proposta e apresenta

2.1 Internet das Coisas

2.1.1 Elementos da Internet das Coisas

Figura 1 Elementos da Internet das Coisas

Fonte: Al-Fuqaha et al. (2015)

1. Identificao: Diversos mtodos de identificao esto disponveis para a IoT, como

2.1.2 Modelos de Arquitetura IoT