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 Orquestração da
Distribuição de Água no Semiárido Brasileiro
Baseada em Internet das Coisas e Computação
em Nuvem

Universidade Federal de Pernambuco
posgraduacao@cin.ufpe.br
http://cin.ufpe.br/~posgraduacao

RECIFE
2017
Wilson Alves da Silva

Uma Arquitetura para Orquestração da Distribuição de
Água no Semiárido Brasileiro Baseada em Internet das
Coisas e Computação em Nuvem

Trabalho apresentado ao Programa de Pós-
graduação em Ciência da Computação do
Centro de Informática da Universidade Fe-
deral de Pernambuco como requisito parcial
para obtenção do grau de Mestre em Ciência
da Computação.

Universidade Federal de Pernambuco

Orientador: Vinícius Cardoso Garcia

RECIFE
2017
FICHA
Dissertação de Mestrado apresentada por Wilson Alves da Silva à Pós-Graduação em
Ciência da Computação do Centro de Informática da Universidade Federal de Pernam-
buco, sob o título “Uma Arquitetura para Orquestração da Distribuição de Água
no Semiárido Brasileiro Baseada em Internet das Coisas e Computação em
Nuvem” Orientador: Vinícius Cardoso Garcia e aprovada pela Banca Examinadora
formada pelos professores:

Prof. Dr. Kiev Santos da Gama
Centro de Informática / UFPE

Prof. Dr. Nelio Alessandro Azevedo Cacho
Departamento de Informática / UFRN

Prof. Dr. Orientador: Vinícius Cardoso Garcia
Centro de Informática / UFPE

Visto e permitida a impressão.
Recife, 29 de Agosto de 2017.

Prof. Aluizio Fausto Ribeiro Araújo
Coordenador da Pós-Graduação em Ciência da Computação do
Centro de Informática da Universidade Federal de Pernambuco.
À minha família, em especial à minha esposa por sempre me proporcionar totais
condições para a realização dos meus estudos, apoiar-me e incentivar-me. Aos meus
irmãos. Dedico.
Agradecimentos

Primeiramente, agradeço a Deus por tudo que tem providenciado em minha vida, e por
ter dado-me força e determinação para concluir este trabalho.
A minha esposa, Luciana Ramos, que tolerou pacientemente minha ausência nos úl-
timos dois anos, que estive dedicado a essa Pós-Graduação. Agradeço pelo amor, pela
compreensão, pelo respeito, enfim por ser a pessoa que me completa.
Ao meu orientador, professor Dr. Vinícius Cardoso Garcia, pelo empenho e boa vontade
em me orientar no que fosse preciso para a conclusão dessa dissertação de mestrado. Que
me apoiou, sempre mostrando as melhores soluções, com sua experiência e conhecimento.
Aos demais docentes do programa de Pós-Graduação do Centro de Informática da
UFPE pela competência com que transmitiram os conteúdos e ensinamentos.
Agradeço a todos os amigos do Centro de Informática, que por muitas vezes ajudaram-
me durante todo o mestrado, pois sem as trocas de ideias esta pesquisa não seria possível.
Agradeço também, aos meus amigos do Exército Brasileiro, com os quais tenho ou
tive a honra de servir. A vocês meu muito obrigado por toda a colaboração e auxílio neste
projeto.

A todos, os meus mais sinceros agradecimentos.
A verdadeira motivação vem de
realização, desenvolvimento pessoal,
satisfação no trabalho e reconhecimento.
(Frederick Herzberg)
Resumo
Na região Semiárida brasileira o regime de chuvas é caracterizado por períodos longos
de estiagem com secas prolongadas, fazendo com que no ano de 2016 fossem gastos mais
de um bilhão de Reais em programas de distribuição de água à população carente dessa
região, dos quais cerca de 14% desse recurso foi gasto em fiscalização. A forma de fiscali-
zação atual não contempla nenhuma maneira de mensurar a quantidade ou a qualidade
da água recebida e várias notícias de fraudes publicadas pela mídia em geral indicam que
essa fiscalização é um processo caro e propício a erro. O problema então é como melhorar
o monitoramento e fiscalização na distribuição de água, ampliando a transparência e a
eficiência de programas federais de distribuição deste recurso. Sistemas de Internet das
Coisas (IoT), são capazes de transmitir informações sobre volume e qualidade da água,
estas informações podem ser usadas de forma integrada com os sistemas de tomada de
decisão para fins de gestão. No entanto, as limitações dos dispositivos IoT requerem uma
tecnologia como Computação em Nuvem para complementar suas aplicações, dado que a
Computação em Nuvem possui capacidades praticamente ilimitadas em termos de arma-
zenamento e processamento. Motivado pela importância do programa de distribuição de
água para o Semiárido brasileiro e pela necessidade de definição de um framework para
permitir a integração de soluções parciais para fiscalização destes tipos de programas,
este trabalho apresenta uma arquitetura baseada em IoT e Computação em Nuvem que
disponibiliza serviços para orquestrar a distribuição de água no Semiárido brasileiro. Para
atingir os objetivos deste trabalho foi realizado um mapeamento das principais tecnolo-
gias empregadas em Sistemas de Gerenciamento de Recursos Hídricos que utilizam IoT e
foi realizada uma análise do emprego da Tecnologia da Informação como instrumento de
apoio à fiscalização do programa de distribuição de água. Apoiado nestes conhecimentos
foi especificada, projetada e implementada uma arquitetura de referência. Por fim, a par-
tir de uma avaliação pôde-se mensurar o quão a Arquitetura Proposta está apta para ser
implantada em um contexto real.

Palavras-chaves: Internet das Coisas, Computação em Nuvem, Engenharia de Software
Baseada em Evidência, Segurança, Arquitetura de Software, Distribuição 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 master’s 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 – Cartão e leitor de cartão usados no processo de distribuição de água . . 35
Figura 3 – Processo de distribuição de água . . . . . . . . . . . . . . . . . . . . . 36
Figura 4 – Etapas do Mapeamento Sistemático 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 publicação . . . . . . . . . . . . . . . . . . . 42
Figura 9 – MSL - Artigos por País de publicação . . . . . . . . . . . . . . . . . . . 43
Figura 10 – MSL - Artigos por Camadas de IoT . . . . . . . . . . . . . . . . . . . . 44
Figura 11 – MSL - Comunicação Interna e Externa . . . . . . . . . . . . . . . . . . 44
Figura 12 – MSL - Comunicação Interna por Artigos . . . . . . . . . . . . . . . . . 45
Figura 13 – MSL - Comunicação Externa . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 14 – MSL - Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 15 – MSL - Técnicas de medição 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 Computação em Nuvem . . . . . . . . . . . . . . . . . . 49
Figura 19 – MSL - Características Arduino e Raspberry Pi . . . . . . . . . . . . . . 52
Figura 20 – Síntese do Mapeamento Sistemático 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 seleção da Plataforma IoT . . . . . . . . . . . . . . . . 66
Figura 25 – Arquitetura IoT empregada . . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 26 – Divisões físicas e lógicas da Arquitetura de Software . . . . . . . . . . . 69
Figura 27 – Atividades realizadas pela Arquitetura Proposta . . . . . . . . . . . . . 70
Figura 28 – Visão Lógica da AS proposta . . . . . . . . . . . . . . . . . . . . . . . 71
Figura 29 – Diagrama de sequência da atividade de Gerar Token de Entrega . . . . 72
Figura 30 – Diagrama de sequência da atividade Realizar Entrega . . . . . . . . . . 73
Figura 31 – Diagrama de sequência módulo Nó . . . . . . . . . . . . . . . . . . . . 74
Figura 32 – Diagrama de classes resumido Camada de Negócio AS . . . . . . . . . 75
Figura 33 – Diagrama de Classe do Mediador de Dados . . . . . . . . . . . . . . . . 81
Figura 34 – Resultado da avaliação dos cenários . . . . . . . . . . . . . . . . . . . . 94
Figura 35 – Avaliação das Tecnologias de Comunicação para SGRH . . . . . . . . . 115
Lista de Tabelas

Tabela 1 – Padrões Arquiteturais. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Tabela 2 – Resultado da avaliação dos protocolos de comunicação . . . . . . . . . 61
Tabela 3 – Trabalhos secundários sobre Plataformas IoT . . . . . . . . . . . . . . 65
Tabela 4 – Serviços desejáveis em uma Plataforma de IoT . . . . . . . . . . . . . . 65
Tabela 5 – Características desejáveis em uma Plataforma de IoT . . . . . . . . . . 66
Tabela 6 – Mapeamento dos componentes da AS em processos e threads . . . . . . 76
Tabela 7 – Visão Fisica da AS - Gateway . . . . . . . . . . . . . . . . . . . . . . . 80
Tabela 8 – Visão Fisica da AS - Nó . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Tabela 9 – Visão Fisica da AS - Plataforma IoT . . . . . . . . . . . . . . . . . . . 81
Tabela 10 – Mapeamento de Requisitos X Módulos . . . . . . . . . . . . . . . . . . 84
Tabela 11 – Características dos métodos SAAM e ATAM . . . . . . . . . . . . . . . 87
Tabela 12 – Etapas do método de avaliação . . . . . . . . . . . . . . . . . . . . . . 88
Tabela 13 – Expertise da Equipe de Avaliação . . . . . . . . . . . . . . . . . . . . . 89
Tabela 14 – Execução da avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Tabela 15 – Atributos de Qualidade ordenados por prioridade . . . . . . . . . . . . 91
Tabela 16 – Cenários propostos para avaliação da AS . . . . . . . . . . . . . . . . . 93
Tabela 17 – MSL - Artigos selecionados . . . . . . . . . . . . . . . . . . . . . . . . 114
Lista de Abreviaturas e Siglas

AS Arquitetura de Software.

BLE Bluetooth Low Energy.

EB Exército Brasileiro.

ESBE Engenharia de Software Baseada em Evidências.

GCDA Sistema de Gestão e Controle de Distribuição de Água.

IoT Internet das Coisas.

LAN Rede de Área Local.

MEM Módulo Embarcado de Monitoramento.

MSL Mapeamento Sistemático da Literatura.

OCP Operação Carro-Pipa.

OME Organizações Militares Executoras.

PA Padrão Arquitetural.

PAbst Ponto de Abastecimento.

PMES Primeiro Mandamento da Engenharia de Software.

QA Atributos de Qualidade.

SGRH Sistemas de Gerenciamento de Recursos Hídricos.

TI Tecnologia da Informação.

WAN Rede de Longa Distância.

Wi-Fi Wireless Fidelity.

WSN Rede de Sensores Sem Fio.
Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1 Motivação e Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Hipótese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.1 Objetivos Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5 Escopo Negativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.6 Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . 20

2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . 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 Computação em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1 Características Essenciais . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.2 Modelos de Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.3 Formas de Distribuição . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Integração Computação em Nuvem e Internet das Coisas . . . . . . 25
2.4 Engenharia de Software Baseada em Evidência . . . . . . . . . . . . 27
2.5 Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.1 Padrões 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 Pública - RSA e ECC . . . . . . . . . . . . . . . . . 30
2.7 Considerações Finais do Capítulo . . . . . . . . . . . . . . . . . . . . 31

3 REVISÃO DA LITERATURA . . . . . . . . . . . . . . . . . . . . . . 32
3.1 Análise do Modelo de Distribuição de Água no Semiárido Brasileiro 32
3.1.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.2 Sistemas de Informação na Distribuição de Água . . . . . . . . . . . . . . 33
3.1.2.1 GCDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.2.2 GPIPABRASIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.3 Processo de Distribuição de Água . . . . . . . . . . . . . . . . . . . . . . 34
3.1.4 Problemas no Método Atual de Distribuição de Água . . . . . . . . . . . . 36
3.1.5 Resumo da Seção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Execução da Busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.2.3 Critérios de Seleção dos Estudos . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.3 Síntese e Análise dos Dados . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.3.1 Extração e Análise dos Dados . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.3.2 Respostas das Questões de Pesquisa . . . . . . . . . . . . . . . . . . . . . . 43
3.2.3.3 Discussão dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.3.4 Síntese do Mapeamento Sistemático da Literatura . . . . . . . . . . . . . . . 53
3.2.4 Resumo da Seção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.3 Considerações Finais do Capítulo . . . . . . . . . . . . . . . . . . . . 54

4 ARQUITETURA PROPOSTA . . . . . . . . . . . . . . . . . . . . . 55
4.1 Requisitos para Arquitetura Proposta . . . . . . . . . . . . . . . . . . 55
4.1.1 Resumo da Seção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 Especificação da Arquitetura IoT . . . . . . . . . . . . . . . . . . . . 57
4.2.1 Definição do Modelo de Arquitetura IoT Empregado . . . . . . . . . . . . 57
4.2.2 Camada de Percepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.2.1 Unidade de Medição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.2.2 Unidade de Processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.2.3 Unidade de Alimentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.2.4 Unidade de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.3 Camada de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.3.1 Gateway Móvel para IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.3.2 Definição da Camada de Rede da Arquitetura Proposta . . . . . . . . . . . . . 63
4.2.4 Camada de Processamento . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.4.1 Plataformas de Mediação de Dados de IoT . . . . . . . . . . . . . . . . . . . 63
4.2.4.2 Revisão da Literatura de Plataformas de Mediação de Dados para IoT . . . . . 64
4.2.4.3 Guideline para Seleção da Plataforma IoT . . . . . . . . . . . . . . . . . . . 66
4.2.5 Resumo da Seção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3 Especificação da Arquitetura de Software . . . . . . . . . . . . . . . . 68
4.3.1 Arquitetura de Software Proposta . . . . . . . . . . . . . . . . . . . . . . 70
4.3.1.1 Visão Lógica da Arquitetura de Software . . . . . . . . . . . . . . . . . . . . 70
4.3.1.2 Visão de Execução da Arquitetura de Software . . . . . . . . . . . . . . . . . 76
4.3.1.3 Visão de Caso de Uso da Arquitetura de Software .
. . . . . . . . . . . . . . 77
4.3.2 Implementação de Referência . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.3.2.1 Plataforma IoT - FIWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.3.2.2 Visão Física da Arquitetura de Software . . . . . .
. . . . . . . . . . . . . . 79
4.3.2.3 Visão de Implementação da Arquitetura de Software . . . . . . . . . . . . . . 79
4.3.3 Validação da Arquitetura de Software . . . . . . . . . . . . . . . . . . . . 82
4.3.3.1 PMES versus Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . 83
4.3.3.2 Requisitos Elicitados versus Módulos da Arquitetura de Software . . . . . . . . 84
4.3.4 Resumo da Seção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.4 Considerações Finais do Capítulo . . . . . . . . . . . . . . . . . . . . 84

5 AVALIAÇÃO DA ARQUITETURA PROPOSTA . . . . . . . . . . . 85
5.1 Métodos de Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.1.1 SAAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.1.2 ATAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2 Protocolo da Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2.1 Definição do Método de Avaliação . . . . . . . . . . . . . . . . . . . . . . 87
5.2.2 Equipe de Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3 Execução da Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3.1 Primeira Reunião . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3.2 Segunda Reunião . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3.3 Terceira Reunião . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.4 Resultados da Avaliação da Arquitetura . . . . . . . . . . . . . . . . . 93
5.4.1 Resultados da Avaliação dos Cenários . . . . . . . . . . . . . . . . . . . . 94
5.4.2 Resultados Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.5 Ameaças à Validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.5.1 Alto Desvio Padrão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.5.2 Relacionamento Interpessoal . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.5.3 Possível Avaliação de uma Implementação Específica . . . . . . . . . . . . 97
5.6 Considerações Finais do Capítulo . . . . . . . . . . . . . . . . . . . . 98

6 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . 99
6.1 Visão Geral da Solução Proposta . . . . . . . . . . . . . . . . . . . . 99
6.2 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.3 Contribuições da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.4 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.5 Possibilidade de Utilização da Arquitetura em Outros Domínios . . 103
6.6 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
APÊNDICES 112

APÊNDICE A – ARTIGOS SELECIONADOS MSL . . . . . . . . . 113

APÊNDICE B – TABELA DE AVALIAÇÃO DAS TECNOLOGIAS
DE COMUNICAÇÃO PARA SGRH . . . . . . . . 115

APÊNDICE C – DESCRIÇÃO DOS SERVIÇOS E CARACTERÍS-
TICAS DESEJÁVEIS EM UMA PLATAFORMA
DE IOT . . . . . . . . . . . . . . . . . . . . . . . . 116
16

1 Introdução

Este capítulo apresenta a motivação e a justificativa para realização deste trabalho, bem
como o problema e a definição da hipótese de pesquisa. A partir disto são apresenta-
dos os objetivos, geral e específicos desta pesquisa, a organização de todo o trabalho é
apresentada no final deste capítulo.

1.1 Motivação e Justificativa
Hoje em dia, um dos maiores desafios a ser resolvido é o de gerir a escassez de água. A
Organização Mundial de Saúde reporta que 750 milhões de pessoas em todo o mundo não
têm acesso à água potável, o que é cerca de um nono da população mundial (JMP, 2016).
O Semiárido brasileiro, formado pela região Nordeste do Brasil, norte de Minas Gerais
e norte do Espírito Santo, abrange uma área de 1.663.200 km2 e é conhecida como Polígono
da Seca. Nessa região o regime de chuvas é caracterizado por períodos 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 não oferece condições
para a perfuração de poços profundos e existem poucos rios nesta região (PADILHA et
al., 2004). Nessas circunstâncias, torna-se imprescindível a busca de soluções alternativas
para o problema da seca no Semiárido brasileiro.
Assim, com o objetivo de levar água potável às áreas atingidas pela seca nesta região,
no ano de 2000 foi criado pelo Governo Federal o Programa Emergencial de Distribuição
de Água. A Operação Carro-Pipa (OCP) é uma das ações deste programa e tem por
objetivo a distribuição de água potável às populações atingidas pela seca no Semiárido
brasileiro. Segundo dados obtidos do sistema que gerencia esse programa, no ano de
2016, esta operação atendeu a 789 municípios por mês, trabalhando com 6.502 Pipeiros,
os quais entregaram 219.658 carradas em 65.310 pontos de abastecimento, distribuíndo
2.087.045m3 de água e atendendo a uma população de 3.440.558 por mês, sendo gastos
nesse ano R$ 1.021.682.120,57 (GCDA, 2017).
A fiscalização da distribuição de água à população carente desta região é realizada
pelo Exército Brasileiro (EB). Apenas com essa fiscalização são gastos anualmente cerca
de 14% de todo o recurso financeiro destinado à operação (SIAFI, 2017). A fiscalização do
serviço é realizada de duas maneiras: a primeira fisicamente com equipes de fiscalização
que constantemente estão nas localidades assistidas; e a segunda é por meio de um sistema
de rastreamento que permite o acompanhamento da captação e entrega da água. Porém,
a forma de fiscalização atual não contempla nenhuma maneira de mensurar a quantidade
ou a qualidade da água recebida, o que torna essa fiscalização um processo caro e propício
a erro ou muitas vezes fraude. Um indicativo disto é que diversos veículos de comunicação
Capítulo 1. Introdução 17

têm reportado constantes fraudes na OCP. Apenas para ilustrar, cita-se abaixo algumas
matérias veiculadas:

• Em dezembro de 2013 uma equipe de reportagem de uma importante rede de televi-
são brasileira durante dois meses percorreu a região Nordeste para investigar como
a operação funciona1 . Eles reportaram que: "vítimas da seca recebem água conta-
minada em caminhões-pipa" e que "encontraram tanques imundos" e "entregas que
não chegam nunca".

• Em fevereiro de 2017 a Polícia Rodoviária Federal prendeu duas pessoas por fraudar
a OCP no Ceará2 . A dupla fazia percursos simulados com os aparelhos de GPS em
um carro. Dessa forma, eles receberiam pelo serviço e pela quilometragem rodada,
mas sem gastar óleo diesel de seus caminhões e, efetivamente, sem realizar o serviço
de coleta e entrega de água de forma correta.

• Em janeiro de 2017 um motorista de um caminhão-pipa foi flagrado pela Polícia
Militar do Ceará despejando cerca de nove mil litros de água potável em um córrego,
no município de Maracanaú, Região Metropolitana de Fortaleza3 . O trabalho dele
seria transportar a água que seria distribuída gratuitamente. Porém, ao invés 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
Exército, investiga mais uma suspeita de fraude na OCP4 . Segundo os agentes, a
informação que receberam é que sempre no final da tarde alguns veículos chegam ao
local e derramam água potável pertencente a OCP. Provavelmente recebendo como
se as tivesse entregue.

Motivado por esses fatos e dada a importância do programa de distribuição de água
para o Semiárido brasileiro, fica evidente a necessidade de serem empregados meios au-
tomatizados para realizar a fiscalização e o monitoramento da distribuição de água nesta
região.
Os sistemas de IoT são capazes de transmitir informações em tempo real sobre proces-
sos naturais, como nível e grau de pureza de água de rios e mananciais, estas informações
podem ser usadas de forma integrada com os sistemas de tomada de decisão para fins de
gestão dos recursos naturais (MAIA et al., 2007). Porém, 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
Capítulo 1. Introdução 18

2010). Assim, as limitações dos dispositivos associados à IoT, requerem uma tecnologia
como Computação em Nuvem para complementar este campo (DIAZ; CRISTIAN; RUBIO,
2016). Computação em Nuvem tem capacidades virtualmente ilimitadas em termos de
poder de armazenamento e processamento (BOTTA et al., 2014), que são os principais en-
traves da IoT. Portanto, através da Computação em Nuvem, a Internet das Coisas pode
ser abstraída de suas principais limitações.
Embora os desafios enfrentados pela indústria de água sejam globais e existam diversos
fornecedores e grandes empresas que participam ativamente na área da gestão da água,
as soluções desses desafios são baseadas cada vez mais em soluções locais fornecidas por
pequenas empresas (ROBLES et al., 2014). Neste contexto, é urgentemente necessária a
definição de um framework para canalizar esses esforços, não só para reforçar as sinergias
entre os diferentes players, mas também para permitir a integração e adoção generalizada
de soluções parciais.

1.2 Problema
Neste contexto, o problema é como melhorar o monitoramento e fiscalização na distribui-
ção de água com o mínimo de intervenção humana, ampliando assim a transparência e a
eficiência de programas de distribuição de água.
Diante do problema apresentado, o presente trabalho propõe desenvolver uma arqui-
tetura baseada em Internet das Coisas e Computação em Nuvem, utilizando a metodolo-
gia de Engenharia de Software Baseada em Evidências, para auxiliar no monitoramento
e controle da distribuição de recursos hídricos, definindo, investigando e analisando as
principais tecnologias e práticas aplicadas no atual estado da arte para apresentar uma
Arquitetura de Software (AS) que disponibilize serviços para orquestrar a distribuição de
água no Semiárido brasileiro.

1.3 Hipótese
Visto a evidente necessidade de serem empregados meios automatizados para realizar a
fiscalização e o monitoramento da distribuição de água no Semiárido brasileiro e conside-
rando que:
i. a Internet das Coisas fornece meios para coletar informações sobre fenômenos
naturais, como nível e pureza de água em rios e mananciais;
ii. a Computação em Nuvem tem capacidades virtualmente ilimitadas em termos
de armazenamento e processamento, principais limitações da IoT;
iii. existe a necessidade da definição de um framework para permitir a integração e
adoção generalizada de soluções aos desafios enfrentados pela indústria de água.
Capítulo 1. Introdução 19

Diante disto, a hipótese que conduz este trabalho é:
É possível especificar, projetar e implementar uma arquitetura baseada em Internet das
Coisas e Computação em Nuvem que disponibilize serviços para orquestrar a distribuição
de água no Semiárido brasileiro.

1.4 Objetivos
Esta pesquisa visa propor uma arquitetura para auxiliar no monitoramento e controle da
distribuição de água que:
• proveja meios de fiscalizar a quantidade e a qualidade da água entregue;
• proveja mecanismos para que novos requisitos e novas aplicações possam ser desen-
volvidos com base nos serviços ofertados.
Diante disso, os objetivos desta pesquisa são divididos em geral e específicos, listados a
seguir:

1.4.1 Objetivos Geral
Este trabalho tem como objetivo geral especificar, projetar e implementar uma arquitetura
baseada em IoT e Computação em Nuvem que disponibilize serviços para orquestrar a
distribuição de água no Semiárido brasileiro.

1.4.2 Objetivos Específicos
1. Realizar uma análise do modelo de distribuição de água no Semiárido brasileiro e
da utilização da Tecnologia da Informação (TI) como instrumento de melhoria dos
processos de fiscalização da OCP;

2. Mapear as principais tecnologias e técnicas empregadas em Sistemas de Gerencia-
mento de Recursos Hídricos (SGRH) que utilizam o paradigma de IoT;

3. Discutir um conjunto de requisitos fundamentais que devem ser atendidos na im-
plantação de uma arquitetura para SGRH;

4. Especificar uma arquitetura baseada em IoT e Computação em Nuvem para SGRH;

5. Projetar e implementar uma AS para um SGRH para orquestrar a distribuição de
água no semiárido brasileiro;

6. Avaliar a Arquitetura proposta.
Capítulo 1. Introdução 20

1.5 Escopo Negativo
Como a solução proposta por esta dissertação faz parte de um contexto amplo, um con-
junto de aspectos relacionados não serão tratados neste trabalho. Assim, os seguintes
aspectos não fazem parte do escopo deste trabalho:

• Comunicação em tempo-real: Embora seja de suma importância, a comunicação
em tempo-real com as cisternas dos beneficiários do programa com a finalidade de
verificar a quantidade de água em tempo-real não será contemplado neste trabalho.
Isso se dá devido a grande dificuldade de comunicação entre as localidades onde se
encontram essas cisternas com a Internet.

• Controle a fraudes específicas: Este trabalho é uma contribuição para um melhor
controle e fiscalização, não sendo pretensão prever todas as possíveis fraudes a que
o programa de distribuição de água está exposto.

• Predição de necessidade de abastecimento de cisternas: Este projeto não prevê meios
de predizer a real necessidade de cada cisterna, sendo esse serviço sugerido como
um trabalho futuro.

1.6 Organização da Dissertação
O restante desta dissertação está organizado conforme se segue:

• Capítulo 2: apresenta o referencial teórico utilizado durante o desenvolvimento
desta pesquisa;

• Capítulo 3: apresenta uma revisão da literatura, onde é realizada uma análise do
emprego da TI na fiscalização da OCP e são mapeadas as principais tecnologias e
técnicas empregadas em SGRH;

• Capítulo 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;

• Capítulo 5: discute o processo de avaliação da Arquitetura Proposta e apresenta
os principais resultados;

• Capítulo 6: conclui esta dissertação por meio de um resumo das principais contri-
buições desta pesquisa, apresentação dos principais trabalhos relacionados e discus-
sões a respeito de direções para pesquisas futuras.
21

2 Referencial Teórico

Este capítulo tem como objetivo explanar os conceitos e estudos utilizados como base
para a presente pesquisa. Na seção 2.1 são apresentadas as principais características da
Internet das Coisas. Na seção 2.2 são apresentados os conceitos básicos de Computação em
Nuvem. A seção 2.3 apresenta o conceito de CloudIoT, que é a integração da Computação
em Nuvem com a Internet das Coisas. A seção 2.4 explana sobre a Engenharia de Software
Baseada em Evidências (ESBE), usada para apoiar o método de pesquisa adotado. Para
auxiliar no melhor entendimento deste trabalho, a seção 2.5 explana sobre Arquitetura
de Software. Por fim, na seção 2.6 é explicado o que é e como funcionam os métodos de
assinatura digital.

2.1 Internet das Coisas
A Internet das Coisas ou IoT, acrônimo do inglês 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 título de uma apresentação que ele fez na empresa Procter
& Gamble (P&G).
IoT tem como objetivo estender a Internet a bens onipresentes no mundo físico, propor-
cionando um ambiente inteligente, ligando as coisas e pessoas, que logicamente é composta
por três partes: objetos inteligentes, interoperabilidade e aplicações (ZHOU; ZHANG, 2014).

2.1.1 Elementos da Internet das Coisas
Seis tecnologias são amplamente utilizados para a implantação de produtos baseados IoT.
A Figura 1 mostra os elementos que compõe a IoT segundo a visão de Al-Fuqaha et al.
(2015). A seguir são descritos cada um desses elementos.

Figura 1 – Elementos da Internet das Coisas

Fonte: Al-Fuqaha et al. (2015)
Capítulo 2. Referencial Teórico 22

1. Identificação: Diversos métodos de identificação estão disponíveis para a IoT, como
códigos de produtos eletrônicos (EPC) e códigos ubíquos (uCode). O endereçamento
dos objetos IoT é necessário para diferenciar entre o ID do objeto e sua localização.
2. Detecção/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. Comunicação: As tecnologias de comunicação conectam objetos heterogêneos entre
si, formando uma Rede de Sensores Sem Fio (WSN) e conecta esses a redes diversas,
Internet ou Intranet, para fornecer serviços inteligentes específicos.
4. Computação: As unidades de processamento (por exemplo, microcontroladores,
microprocessadores) e aplicações de software representam a capacidade computaci-
onal da IoT. Várias plataformas foram desenvolvidas para executar aplicações IoT.
5. Serviços: Em geral os serviços IoT podem ser classificados em quatro classes: ser-
viços relacionados à identidade, serviços de agregação de informações, serviços de
colaboração e serviços ubíquos.
6. Semântica: Na IoT refere-se à capacidade de extrair conhecimento inteligente-
mente por diferentes máquinas para fornecer os serviços necessários. A extração de
conhecimento inclui a descoberta, reconhecimento de padrões e análise de dados.

2.1.2 Modelos de Arquitetura IoT
Uma tentativa inicial para a coordenação dos esforços realizados por vários projetos em
IoT foi realizada em 2010 no contexto dos eventos da Future Internet Architecture (FIA)1 .
Aproveitando as entradas de vários projetos destes eventos, um modelo de arquitetura em
três camadas para IoT foi descrito em Wu et al. (2010).
O modelo básico da IoT consiste de fato na arquitetura de três camadas: Camada
de Percepção, a Camada de Rede e Camada de Aplicação (KHAN et al., 2012; WU et
al., 2010). Devido ao rápido desenvolvimento da IoT, o modelo de arquitetura de três
camadas não 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 adição de duas novas camadas: Camada de Processamento e Camada
de Negócios. 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 Percepção: representa os sensores e atuadores físicos da IoT que visam
coletar e processar informações. Esta camada inclui sensores para coletar localização,
temperatura, peso, movimento, vibração, aceleração, umidade e etc.
1
http://www.nets-fia.net/
Capítulo 2. Referencial Teórico 23

• Camada de Rede: transfere os dados produzidos pela camada de Percepção para a
camada superior. Os dados podem ser transferidos através de várias 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 heterogêneos sem considerar uma plataforma específica. Essa ca-
mada processa dados recebidos, toma decisões e fornece os serviços necessários.
• Camada de Aplicação: fornece os serviços solicitados pelos clientes. Por exemplo, a
camada de Aplicação pode fornecer medições de temperatura e umidade do ar ao
cliente que solicita esses dados.
• Camada de Negócio: gere as atividades e serviços globais do sistema IoT. As res-
ponsabilidades desta camada são a construção de um modelo de negócio, gráficos,
fluxogramas, etc. com base nos dados recebidos da camada de Aplicação.

2.1.3 Aplicabilidade de IoT
Devido à dupla capacidade de executar e detectar situações (como, por exemplo, coletar
informações sobre fenômenos naturais, parâmetros médicos, etc.), a IoT tem enormes
potencialidades para o desenvolvimento de novas aplicações inteligentes em vários campos
de atuação (BORGIA, 2014).
Borgia (2014) agrupa as aplicações em três grandes domínios: domínio industrial,
domínio de cidades inteligentes, e domínio da saúde e bem-estar. A autora complementa
afirmando que cada domínio não é isolado, mas são parcialmente sobrepostos, uma vez
que algumas aplicações são compartilhadas.
Nem todas as aplicações da Internet das Coisas têm atualmente o mesmo nível de
maturidade. Muitas áreas de atuação ainda estão em fase experimental e outras são mais
futuristas e ainda estão em um estágio inicial (BORGIA, 2014).

2.2 Computação em Nuvem
Existem diversas propostas de definição para o paradigma da computação em nuvem,
sendo a definição do National Institute of Standards and Technology (NIST) uma das
mais aceitas na comunidade: "Modelo que permite o acesso através de rede ubíqua, de
acordo com a demanda, a um pool compartilhado de recursos computacionais que podem
ser rapidamente provisionados e liberados com um esforço mínimo de gerenciamento ou
interação com o provedor de serviços" (MELL et al., 2011).
Nesse contexto, essa tecnologia emerge como uma opção capaz de reduzir custos atra-
vés de uma abordagem onde os recursos computacionais são pagos quando utilizados (RA-
MAKRISHMAN et al., 2010). Tal fato tem atraído os olhares de gigantes como a Amazon,
Google, Salesforce, Microsoft, IBM, HP, entre outros. Estas organizações ofertam serviços
Capítulo 2. Referencial Teórico 24

como Amazon EC22 , Google App Engine3 , Salesforce4 , Windows Azure5 e Dropbox6 , que
oferecem soluções com promessas de baixo custo, através das quais seus usuários podem
ter acesso aos serviços de maneira ubíqua.

2.2.1 Características Essenciais
As características essenciais representam as vantagens oferecidas pelas soluções da com-
putação em nuvem e a destingue de outros paradigmas computacionais, suas principais
características são (MELL et al., 2011):
• Alocação de recursos sob demanda: permite que o usuário possa dimensionar
a infraestrutura necessária sob demanda. Esta característica permite que usuários
solicitem recursos em tempo de execução à medida que necessitam.
• Amplo acesso à rede: os recursos são disponbilizados através do ambiente de rede
e devem estar disponíveis para acesso através de uma ampla gama de dispositivos
como tablets, PCs, smartphones, entre outros.
• Pooling de Recursos: os recursos computacionais do provedor de serviço são
estruturados para servir a múltiplos usuários utilizando um modelo multi-tennant,
que disponibiliza diferentes recursos físicos e virtuais de maneira dinâmica conforme
a necessidade do usuário. Há um senso de independência local, ou seja, o usuário
não precisa ter conhecimento da localização física dos recursos computacionais.
• Elasticidade rápida: característica que permite que os recursos disponíveis ao
usuário pareçam ilimitados, pois tais recursos podem ser adicionados e removidos
de maneira rápida e automática, conforme a necessidade da carga de trabalho.
• Serviço medido: os recursos de um provedor são automaticamente controlados e
otimizados, através da capacidade de medição em um nível de abstração adequado
para o tipo de serviço. A utilização dos recursos pode ser controlada, monitorada e
relatada com transparência entre o provedor e consumidor do serviço.

2.2.2 Modelos de Serviço
Os provedores da computação em nuvem oferecem seus serviços de acordo com três mo-
delos apresentados abaixo:
• Infraestrutura Como Serviço (IaaS): através deste modelo o provedor de servi-
ços pode comercializar elementos de infraestrutura (cpu, memória, armazenamento,
etc) e a responsabilidade de corrigir, atualizar e manter o sistema operacional ou
qualquer outro software é do cliente. Neste modelo o usuário não 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/
Capítulo 2. Referencial Teórico 25

fraestrutura física mas sim os sistemas operacionais, armazenamento, aplicativos e
componentes de rede.
• Plataforma Como Serviço (PaaS): neste modelo o provedor de serviços fornece
sistemas operacionais, linguagens de programação e ambientes de desenvolvimento
de software. Neste modelo o usuário tem controle sobre configurações e aplicações
implantadas nesta infraestrutura.
• Software Como Serviço (SaaS): software de propósito específico é o produto
fornecido neste modelo de serviço. Os sistemas são disponibilizados ao usuário por
meio de interfaces como um navegador de Internet. O usuário pode administrar e
controlar apenas configurações específicas do próprio sistema.

2.2.3 Formas de Distribuição
Os ambientes de computação em nuvem podem ser distribuídos de quatro formas diferen-
tes nos quesitos acesso e disponibilidade:
• Nuvem Pública: a infraestrutura da nuvem é disponibilizada ao público geral,
acessível a qualquer usuário que tenha conhecimento da localização do serviço.
• Nuvem Privada: a infraestrutura é de utilização exclusiva de uma organização,
sendo disponibilizada local ou remotamente, administrada pela própria empresa ou
terceiros.
• Nuvem Comunitária: a infraestrutura é compartilhada por uma comunidade de
organizações com interesses em comum.
• Nuvem Híbrida: a infraestrutura é composta por duas ou mais nuvens de quais-
quer tipos mencionados acima. A conexão entre elas é feita via tecnologia proprie-
tária ou padronizada e permite a portabilidade de dados e aplicações.

2.3 Integração Computação em Nuvem e Internet das Coisas
Recentemente, a Computação em Nuvem tem sido defendida como uma solução promis-
sora para atender a alguns dos requisitos de IoT, onde a integração desses dois paradigmas
é chamado de CloudIoT. A Computação em Nuvem promete um investimento inicial re-
duzido, alta disponibilidade, tolerância a falhas e escalabilidade praticamente infinita,
características que atraíram a atenção tanto do meio acadêmico como da indústria (ZHOU
et al., 2010). Esses recursos são 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 adoção do paradigma CloudIoT são:
Recursos de armazenamento - Oferecendo capacidade de armazenamento prati-
camente ilimitada, de baixo custo e sob demanda, a Computação em Nuvem é a solução
mais conveniente e rentável para lidar com os dados produzidos pela IoT (RAO et al.,
Capítulo 2. Referencial Teórico 26

2012). Uma vez na Nuvem, os dados podem ser tratados de forma homogênea através de
APIs padrão, podem ser protegidos pela aplicação de segurança e acessados diretamente
e visualizados de forma ubíqua.
Recursos computacionais - Os dispositivos IoT têm recursos limitados de proces-
samento que podem não permitir o processamento de dados no local. As capacidades de
processamento ilimitadas da Computação em Nuvem e do seu modelo on-demand permi-
tem que o processamento de IoT seja adequadamente satisfeito (DASH et al., 2010). Outras
perspectivas são a realização de processamento on-the-fly para implementar aplicativos
escaláveis, em tempo real, colaborativos e centrados no sensor, para gerenciar eventos
complexos, e implementar a realização de algumas tarefas para economizar energia (RAO
et al., 2012; DASH et al., 2010).
Elasticidade rápida - Uma das principais características da Computação em Nuvem
é o provisionamento elástico de recursos. Em aplicações IoT que trabalham com recursos
naturais não previsíveis, essa é uma característica bastante interessante.
Recursos de comunicação - Um dos requisitos de IoT é fazer com que os dispositivos
se comuniquem. A nuvem oferece uma solução eficaz e barata para conectar, acompanhar e
gerenciar qualquer coisa de qualquer lugar a qualquer momento (RAO et al., 2012). Graças
à disponibilidade de redes de alta velocidade, a Computação em Nuvem possibilita o
monitoramento e o controle das coisas remotas, sua coordenação, suas comunicações, 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, eficiência, disponibilidade e segurança podem ser difíceis de obter. A integração
com a Nuvem resolve a maioria desses problemas, fornecendo recursos adicionais como
facilidade de acesso, facilidade de uso e custos de implantação reduzidos (FOX et al., 2012;
SUCIU et al., 2013).
Novos paradigmas - A adoção de CloudIoT possibilita novos cenários para serviços e
aplicações inteligentes baseados na extensão da Computação em Nuvem através das coisas,
criando novos paradigmas como: SaaS (Sensoramento como Serviço), SenaaS (Sensor como
Serviço), DBaaS (Banco de Dados como Serviço), DaaS (Dados como Serviço) e IPMaaS
(Gestão de Identidade e de Políticas como um Serviço) (RAO et al., 2012; SUCIU et al.,
2013).
Nos últimos anos, surgiram várias plataformas, protocolos e sistemas para enfrentar
os desafios da integração da Computação 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 integração é considerada ser uma opção
viável para facilitar o desenvolvimento de aplicativos de IoT (SUCIU et al., 2014).
Capítulo 2. Referencial Teórico 27

2.4 Engenharia de Software Baseada em Evidência
A ESBE é um paradigma da Engenharia de Software que permite identificar, selecionar e
sintetizar evidências a partir de estudos primários (KITCHENHAM, 2004). Surgido inicial-
mente na medicina, o objetivo enunciado da ESBE é proporcionar os meios pelos quais as
melhores evidências de pesquisas possam ser integradas às experiências práticas e valores
humanos no processo de tomada de decisão no desenvolvimento e manutenção de software.
Segundo Kitchenham (2004) são três os métodos sistemáticos para se conduzir pes-
quisas com base nos princípios da ESBE:
1. Revisões Sistemáticas da Literatura (RSL): destinadas a identificar, anali-
sar e interpretar as evidências disponíveis relacionadas a uma questão específica de
pesquisa, uma RSL tem uma metodologia bem definida e a questão de pesquisa es-
pecífica é tratada de maneira imparcial. Normalmente estão relacionadas a questões
do tipo: “Um tratamento X aplicado a uma população P é mais eficiente para se
obter o resultado R no contexo C quando comparado com o tratamento Y?”
2. Mapeamento Sistemático da Literatura (MSL): também categorizado como
estudo exploratório, apresenta uma ampla revisão de estudos primários em uma área
ou tópico específico no intuito de identificar quais as provas disponíveis sobre um
tema em questão. Normalmente relacionados a questões do tipo “O que sabemos
sobre o tema X?”, MSLs objetivam identificar todas as pesquisas que procuram
responder questões amplas e exploratórias sobre as tendências de uma determinada
área.
3. Meta-análise: é o método pelo qual, através de análise estatística, sintetiza-se os
resultados de diferentes estudos primários independentes para integrar, combinar
e resumir seus resultados de forma a responder a uma determinada questão de
pesquisa.
Muitas tecnologias são transferidas para a indústria sem terem passado por um pro-
cesso adequado de avaliação que permita a caracterização do seu grau de maturidade
(KAINDL et al., 2002). A ESBE visa a encurtar esta lacuna, incentivando um maior rigor
metodológico. Segundo Kitchenham (2004), ESBE deve prover meios pelos quais melho-
res evidências provenientes da pesquisa possam ser integradas com experiência prática no
processo de tomada de decisão. Assim, a utilização de uma metodologia baseada em evi-
dência representada por revisões sistemáticas contribui satisfatoriamente para a definição
de uma nova técnica ou tecnologia (MAFRA; RAFAEL; TRAVASSOS, 2006).

2.5 Arquitetura de Software
Uma AS é uma abstração de alto nível de um sistema de Software, que tem por objetivo,
fornecer uma descrição de como o mesmo irá funcionar, dividindo-o em módulos e descre-
Capítulo 2. Referencial Teórico 28

Tabela 1 – Padrões Arquiteturais.

Categoria Padrão
Blackboard
Estrutural Layers
Pipes and Filters
Sistemas Distribuídos Brokers
MVC
Sistemas Interativos
PAC
Microkernel
Sistemas Adaptáveis
Reflection
Fonte: Adaptado de (BUSCHMANN et al., 1996)

vendo como esses módulos estão conectados entre si, e como é feita a comunicação entre
os módulos, bem como as tecnologias que são 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 técnica para uma forma ilustrada. Para descrever uma arquitetura de software,
normalmente usa-se um modelo composto de vários pontos de vista ou perspectivas.

2.5.1 Padrões Arquiteturais
Os Padrões Arquiteturais (PAs) são modelos para o desenvolvimento de AS baseados
em problemas comuns em determinadas áreas, ou seja, são soluções já comprovadas que
podem ser usadas para resolver problemas semelhantes, assim agilizando o processo de
resolução desses problemas.
PAs fornecem conhecimento de design reutilizável na forma de soluções comprovadas
para problemas de software recorrentes em um contexto ou de domínio particular (ZDUN
et al., 2004). Os PAs representam a organização dos sistemas de software. Eles definem,
entre outros aspectos, os tipos de componentes e conectores utilizados em descrições
arquiteturais.
Em Buschmann et al. (1996), os PAs são agrupados de acordo com as características
dos sistemas em que eles são mais aplicáveis, com uma categoria tratando das questões
gerais de estruturação. Na Tabela 1 são listadas as categorias e os padrões nelas contidos.
Desses padrões dois serão usados neste trabalho: Layers e Broker.

2.5.1.1 Layers

O PA Layers ajuda a estruturar aplicações que podem ser decompostas em grupos de
subtarefas onde cada grupo está em um nível parcial de abstração (BUSCHMANN et al.,
Capítulo 2. Referencial Teórico 29

1996).
Para Buschmann et al. (1996), uma abordagem em camadas é considerada uma prática
melhor do que implementar o protocolo como um bloco monolítico, uma vez que imple-
mentar conceitualmente diferentes questões separadas tem vários benefícios, por exemplo,
ajudando o desenvolvimento por equipes e apoiando a codificação incremental e testes.
Com esse PA melhores tecnologias de implementação, como novas linguagens ou algorit-
mos, podem ser incorporadas simplesmente reescrevendo uma seção delimitada de código.

2.5.1.2 Broker

O PA Broker pode ser usado para estruturar sistemas de software com componentes
distribuídos que interagem com chamadas de serviços remotos. Um Broker é responsável
por coordenar a comunicação, como por exemplo, encaminhar pedidos, bem como, para
transmissão de resultados e exceções. Esse tipo de sistema funciona com três componentes,
o Publicador (Publisher), o Broker e Assinante (Subscribe).
Segundo Buschmann et al. (1996), o PA Broker, para aplicações distribuídas, pode
acessar serviços de outras aplicações simplesmente pelo envio de mensagens a objetos
mediadores, sem se preocupar com questões específicas relacionadas à comunicação entre
processos, como a sua localização.
Segundo Levy e Losavio (1999), o PA Broker é usado para, estruturar sistemas distri-
buídos com componentes dissociados que interagem por invocações de serviços remotos,
o qual é responsável por coordenar as comunicações. Um componente Broker pode ser in-
troduzido para gerenciar a comunicação entre clientes e servidores, desta forma, o padrão
cliente-servidor muda para o padrão Broker.

2.6 Assinatura Digital
Criptografia é a arte de transformar, de maneira reversível a informação de sua forma ori-
ginal para outra ilegível. Existem duas classes de criptografia, a simétrica e a assimétrica.
A criptografia assimétrica foi proposta por W. Diffie e M. Hellman em 1976, nesta classe
de criptografia para haver uma troca de informações entre remetente e destinatário não é
necessário o compartilhamento de uma chave comum, como ocorre na simétrica.
Em resumo, uma assinatura digital típica envolve dois processos criptográficos: 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 pública do remetente
para autenticá-la.
Capítulo 2. Referencial Teórico 30

2.6.1 Aspectos Gerais
A técnica usada na criptografia de chave pública é o uso de algoritmos de chave assimé-
trica, nos quais cada usuário tem um par de chaves criptográficas – uma chave pública e
uma chave privada. As chaves são relacionadas matematicamente, mas os parâmetros são
escolhidos de forma que o cálculo da chave privada a partir da chave pública seja inviável.
Os sistemas de criptografia de chave pública são classificadas em três categorias:
• Com base no problema de fatoração inteira, como RSA;
• Com base em logaritmo discreto, como o Algoritmo de Assinatura Digital (DSA);
• Com base na curva elíptica, como a Curva Elíptica Diffie Hellman (ECDH).
Uma aplicação prática de um sistema de encriptação de chave pública é garantir a
confidencialidade, onde uma mensagem que o emissor deseja encriptar usa a chave pública
do destinatário e essa mensagem só pode ser decriptada pela chave privada correspondente
do destinatário.
Outra aplicação da criptografia de chave pública é a assinatura digital. A utilização
da assinatura digital providencia a prova inegável 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 alteração da mensagem faz com que a assinatura não cor-
responda mais ao documento;
• irretratabilidade ou não-repúdio - o emissor não pode negar a autenticidade da
mensagem.

2.6.2 Algoritmos de Chave Pública - RSA e ECC
RSA (Rivest-Shamir-Adleman) é a mais bem sucedida implementação de sistemas de
chaves assimétricas (GUSTAVO et al., 2012). Seu nome vem das iniciais dos três 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 exponenciação modular do produto de dois números primos para encriptar
e decriptar mensagens. Sua segurança 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 força bruta sobre o módulo
(AGRAWAL, 2013). Este ataque pode ser dificultado aumentando o tamanho da chave.
Os principais problemas no algoritmo RSA são:
• Aumento do tempo de processamento - O tempo de decodificação aumenta aproxi-
madamente oito vezes com a duplicação do tamanho da chave;
Capítulo 2. Referencial Teórico 31

• Maior necessidade de armazenamento de chaves - O armazenamento de chaves requer
uma quantidade significativa de memória para armazenamento;
• A geração de chaves é complexa e demorada. O tempo aumenta consideravelmente
à medida que o tamanho da chave aumenta;
• Sobrecarga de computação devido às operações de exponenciação, o que requer mais
multiplicações e operações modulares.
A introdução de Criptografia de Curvas Elípticas (ECC) por Neal Koblitz e Victor
Miller, de forma independente em 1985, tem obtido novos algoritmos de chave pública
baseados no problema do logaritmo discreto. As operações matemáticas de ECC são
definidas sobre a curva elíptica: 𝑌 2 = 𝑥3 + 𝑎𝑥 + 𝑏, onde cada valor de a e b gera uma
curva elíptica diferente.
Problemas de logaritmo discreto sobre curvas elípticas são matematicamente mais
complexos do que o problema de fatoração inteira como RSA (AGRAWAL, 2013). Por isso
criptografia por curvas elípticas podem rivalizar com a segurança de outros criptosistemas
usando uma chave menor. Por exemplo uma criptografia por curvas elípticas com chave
pública de tamanho 160 bits são tão seguros quanto criptosistemas RSA e DSA com chave
pública de tamanho 1024 bits (AGRAWAL, 2013). Com chave de tamanho menor, cripto-
sistemas de curva elíptica podem oferecer menor requisitos de memória, implementação
mais rápida e menor requisito de largura de banda (SUTIKNO et al., 2002).

2.7 Considerações Finais do Capítulo
Este capítulo descreveu o referencial teórico utilizado durante o desenvolvimento desta
pesquisa. Foram explanados os principais conceitos e definições de Internet das Coisas
e Computação em Nuvem e a integração desses dois paradigmas, ESBE, Arquitetura de
Software e Assinatura Digital.
No próximo capítulo será apresentada uma revisão da literatura, realizada a fim de
entender como o programa de distribuição de água no Semiárido brasileiro funciona e
de ter uma visão precisa do estado da arte dos Sistemas de Gerenciamento de Recursos
Hídricos.
32

3 Revisão da Literatura

Este capítulo tem por objetivo analisar como o programa de distribuição de água no
Semiárido brasileiro funciona e emprega a TI em seu apoio e também apresentar o estado
da arte de SGRH que empregam IoT. Para isso na seção 3.1 é realizada uma análise
do modelo de distribuição de água empregado no Semiárido brasileiro e na seção 3.2 é
realizado um MSL a fim de obter um survey das tecnologias de IoT empregadas nestes
sistemas.

3.1 Análise do Modelo de Distribuição de Água no Semiárido Bra-
sileiro
As políticas públicas de intervenção realizadas no Semiárido brasileiro para superação
da problemática da seca, em geral, são insuficientes para sanar a demanda de água da
população, sendo necessário para a sua complementação o uso de carros-pipa contratados
pelo Governo Federal (PASSADOR; CLAUDIA, 2010).
O Programa Emergencial de Distribuição de Água, conhecido nacionalmente como
Operação Carro-Pipa (OCP), é uma iniciativa do Governo Federal que tem a finalidade
de entregar água potável à população carente da região semiárida do Brasil. Essa operação
atende cerca de 1.000 municípios com um gasto anual de mais de 1 bilhão de reais.
A presente seção tem por finalidade promover uma análise do modelo de distribuição
de água empregado e da utilização da TI como instrumento de melhoria dos processos
de fiscalização da OCP, bem como, apresentar os benefícios e limitações do uso dessa
tecnologia.

3.1.1 Metodologia
Quanto à forma de abordagem, esta subseção caracteriza-se por uma pesquisa qualitativa
por haver uma aproximação do pesquisador ao campo de trabalho para um melhor deline-
amento das questões, dos instrumentos de coleta e do grupo a ser pesquisado (MERRIAM,
2009). A pesquisa foi feita em um ambiente real, nos escritórios da OCP do EB, sendo
realizadas entrevistas com os seus coordenadores, auxiliares, analistas e desenvolvedores
dos SI usados nesta operação e acompanhamento do processo in loco como observador.
Compreensão do Domínio tem como objetivo adquirir um bom entendimento do do-
mínio do sistema a ser implementado e a Elicitação 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
Capítulo 3. Revisão da Literatura 33

diversos estudos de background para entender e avaliar como os sistemas empregados
documentam os fluxos de informação, procedimentos de trabalho, regras de negócios e
formas de intercâmbio entre as unidades envolvidas.
Neste sentido, foi realizada uma exaustiva pesquisa bibliográfica, utilizando como fon-
tes de busca: artigos e trabalhos acadêmicos; Regulamentos, Portarias, Diretrizes, Normas
e Boletins do Exército; Diretrizes de Planejamento, Ordens de Serviço e seus anexos, fi-
chas de cadastro, contratos, relatórios, pesquisas de opinião, cartilhas, planilhas, recibos
e demais documentos contendo orientações sobre a OCP; manual dos sistemas específicos
utilizados; estudos das atividades de fiscalização realizadas na operação que ainda não
foram automatizadas; análise de dados de marketing, estatísticas de uso e desempenho,
custos médios, entre outros artefatos.
Também foram realizadas diversas entrevistas semiestruturadas e sessões de grupo não
estruturado para o levantamento de requisitos e entendimento do domínio.

3.1.2 Sistemas de Informação na Distribuição de Água
A fim de prover o Exército Brasileiro com elementos para o planejamento, controle e
fiscalização da OCP nos diferentes níveis (gerencial, coordenação e operacional) o Governo
Federal dispõem do Sistema de Gestão e Controle de Distribuição de Água (GCDA).
Mantido e desenvolvido pelo EB desde o ano de 2005, o GCDA utiliza das informações
disponíveis no Sistema Integrado de Administração 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 logística do programa, o Ministério da Integração Nacional teve a
necessidade de contratar uma empresa para desenvolver e implantar um sistema de rastre-
amento veicular que fornecesse informações de geoprocessamento para o próprio ministério
e para o sistema GCDA. Para essa finalidade, foi então 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 módulos que proporcionam inúmeros benefícios nos processos
de apoio às equipes de fiscalização da OCP (LOPES, 2016), como os descritos abaixo:
• Informações sobre municípios, pontos de coleta (Mananciais) e abastecimento de
água (Ponto de Abastecimento (PAbst)), itinerários, prestadores de serviço (Pipei-
ros), carros-pipa, líderes comunitários, entre outras;
• Orientações sobre o posicionamento geográfico dos pontos de coleta e abastecimento
de água, sedes de Organizações Militares Executoras (OME) e municípios 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
Capítulo 3. Revisão da Literatura 34

• Disponibilização de consultas e relatórios, para acompanhamento e controle da exe-
cução da distribuição de água; e
• Informações consolidadas em todos os escalões, de acordo com o perfil de usuário.

3.1.2.2 GPIPABRASIL

O Sistema de Monitoramento da Logística da Entrega de Água por Carros-Pipa (GPIPA-
BRASIL), contratado pelo Ministério da Integração, tem como objetivo atender a OCP
nos seguintes requisitos (LOPES, 2016):
• Rastreamento eletrônico do percurso realizado pelo Pipeiro durante a entrega de
água, apresentando as informações de posicionamento do veículo, 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 informações de data,
horário e posição geográfica, mediante leitura de um cartão magnético de posse do
Pipeiro;
• Registro das entregas de água confirmadas pelo sistema, bem como, as entregas
pendentes para análise dos operadores;
• Produção de alertas de notificação das entregas de água pendentes, informando se
o Pipeiro contratado violou alguma regra estabelecida no seu plano de trabalho ou
se há algum problema técnico no Módulo Embarcado de Monitoramento (MEM); e
• Geração de um arquivo (lote de entregas de água confirmadas por Pipeiro e por mês
de trabalho) para ser importado no GCDA. Esses dados servirão para confecção dos
pagamentos dos Pipeiros.

3.1.3 Processo de Distribuição de Água
O GCDA e o GPIPABRASIL atuam em conjunto no processo de distribuição e recebi-
mento de água executado na OCP. Neste processo são empregados três atores: Operador
do GCDA, Pipeiro e o Beneficiário (responsável pelo PAbst). Também são utilizados os
seguintes artefatos: tablet, cartão magnético de posse do Pipeiro, cartão magnético de
posse do Beneficiário, equipamento de leitura dos cartões magnéticos, 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 cartão magnético com seus dados
pessoais e um equipamento de leitura deste cartão, apresentados na Figura 2. Este equipa-
mento de leitura comunica-se com o MEM, fixo no carro-pipa, o qual possui comunicação
via telefonia móvel (antena GSM/GPRS e Chips de duas operadoras) com o GPIPA-
BRASIL e um GPS. Por fim, o Beneficiário também possui um cartão magnético com
seus dados pessoais, usado como assinatura no processo.
A distribuição de água funciona da seguinte forma, sintetizado na Figura 3:
Capítulo 3. Revisão da Literatura 35

Figura 2 – Cartão e leitor de cartão usados no processo de distribuição de água

Fonte: o Autor

1. O Pipeiro comparece à OME para receber seu plano de distribuição, o qual consta:
datas dos abastecimentos, Manancial em que deve encher o carro-pipa, PAbst que
devem suprir e itinerário que deve ser seguido;
2. Na data estabelecida, o Pipeiro vai para o Manancial, enche o carro-pipa e passa
o seu cartão magnético no leitor. Esse leitor recebe os dados do Pipeiro e repassa
para o MEM. O MEM então inicia o processo de entrega, inserindo as localizações
geográficas 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 Beneficiário.
5. Após a entrega da água, o Pipeiro passa seu cartão magnético novamente no equi-
pamento de leitura para fechar a entrega. Novamente o equipamento de leitura do
cartão apenas repassa os dados do Pipeiro para o MEM.
6. Para realmente fechar a entrega, o Beneficiário também passa o seu cartão magnético
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 cartão do Pipeiro e do Beneficiário, o MEM insere os dados
de localização geográfica 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
tão logo consiga sinal de rede celular.
9. Finalizando o processo, é feito pelo GPIPABRASIL a integração dos dados, importando-
os para o GCDA, que armazena as informações em seu banco de dados.
O pagamento do Pipeiro é calculado: com base na distância percorrida entre o Manan-
cial e o PAbst em um itinerário pré-estabelecido; a qualidade das estradas no itinerário,
no sistema chamado de "momento da entrega"; e a quantidade de água entregue ao Bene-
ficiário em metros cúbicos. Sendo assim, o valor de cada entrega é calculado da seguinte
forma: Valor Entrega=distância*volume*momento.
Capítulo 3. Revisão da Literatura 36

Figura 3 – Processo de distribuição de água

Fonte: GCDA

3.1.4 Problemas no Método Atual de Distribuição de Água
As informações obtidas pelo GPIPABRASIL são repassadas apenas mensalmente para a
equipe do GCDA, a qual necessita dessas informações atualizadas diariamente. Um caso
típico de falha por esse motivo é de um PAbst ser abastecido por dois Pipeiros distintos
no mesmo mês, ultrapassando a necessidade mensal do Beneficiário.
Outro problema é a quebra constante dos MEM, sendo manutenido e distribuído 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 propício a erro e fraude.
Também houve relato de suspeita de danificação do MEM voluntariamente por parte dos
Pipeiros, a fim de não serem monitorados.
Outro problema no processo é a confecção do plano de trabalho baseado totalmente
em estatística. Neste modelo a entrega em um PAbst é calculada segundo estudos que
estimam que, em média, as necessidades de água típicas dos assistidos pelos programas de
cisternas são da ordem 16 mil litros/família/8 meses. Seguindo esse modelo, a distribuição
termina não sendo uniforme, ocorrendo que muitos Beneficiários ficam com suas cisternas
secas por longo período, 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 interação humana, principalmente com as leituras dos cartões.
Essa leitura além de dar uma complexidade a mais no processo também é propensa a
erro, uma vez que o Pipeiro ou o Beneficiário pode acreditar que fez a leitura sem tê-la
Capítulo 3. Revisão da Literatura 37

feito ou fazê-la várias 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 cartão no leitor para gravar as coordenadas e data-hora de abastecimento.
Desta forma, controla-se apenas que o Pipeiro passou pelo Manancial, não 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 ausência de
controle da quantidade e da qualidade da água entregue. Não se sabe quanto o Pipeiro
pegou de água no Manancial e pior de tudo, não se sabe quanto ele entregou no PAbst.
Neste modelo não existe nenhuma fiscalização na entrega do volume e da qualidade do
recurso, havendo apenas o controle da entrega, sabe-se que entregou, mas não se sabe
quanto nem em que condições. Segundo relatos, muitas vezes ocorre a situação 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, desperdiçando recurso ou caracterizando fraude.

3.1.5 Resumo da Seção
Esta seção apresentou um análise do processo de distribuição de água e do emprego da TI
como instrumento de melhoria dos processos de fiscalização da OCP. A partir da análise
dos dois sistemas empregados e do processo de distribuição de água usado na OCP foram
levantados seus benefícios, deficiências, 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 técnicas empregadas nas abordagens usadas para
sistemas de monitoramento, distribuição e gerenciamento de recursos hídricos, chama-
das genericamente neste trabalho de Sistemas de Gerenciamento de Recursos Hídricos ou
SGRH. Desta forma verificou-se a necessidade de se mapear essas tecnologias e técnicas.
De acordo com Kitchenham (2007), um MSL deve identificar, avaliar, interpretar e
comparar todas as fontes relevantes, a fim de responder a questões sobre as tendências de
uma determinada área de pesquisa. Diante disto, com a consolidação deste MSL pretende-
se ter uma visão precisa do estado da arte dos SGRH que utilizam IoT.

3.2.1 Perguntas de Pesquisa
Com base no cenário descrito acima, levantou-se a questão principal para condução dessa
pesquisa: quais as principais tecnologias e técnicas empregadas em SGRH que utilizam o
Capítulo 3. Revisão da Literatura 38

paradigma de IoT como abordagem principal?
Baseado nessa pergunta, oito Questões 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 são empregados nestes sistemas?
• QP3 – Quais tecnologias de comunicação são usadas neste sistemas?
• QP4 - Quais sensores são usados nestes sistemas?
• QP5 - Quais técnicas ou sensores são usados para medir volume de água?
• QP6 - Quais controladores ou microcontroladores são usados nestes sistemas?
• QP7 - Quais as formas de energia são empregadas para alimentação destes sistemas?
• QP8 – Esses sistemas usam Computação em Nuvem?
A proposta deste mapeamento é identificar tecnologias de forma quantitativa, assim
espera-se encontrar resultados como: porcentagem de projetos que usam Computação 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 Ciência da Computação pela Universidade Federal
de Pernambuco. As subseções 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. Porém, devido ao interesse de mapear esses
sistemas e à abordagem mais horizontal utilizada nas Questões de Pesquisa, entendeu-se
que um MSL seria o método mais adequado para esse mapeamento.
Para a definição do protocolo foram empregadas as ideias de Kitchenham (2004):
• Identificar as necessidades da área pesquisada;
• Formular Questões de Pesquisa dirigidas;
• Executar busca exaustiva para obter os estudos primários;
• Avaliação qualitativa dos estudos primários;
• Identificação de dados necessários para responder as Questões de Pesquisa;
• Extração dos dados;
• Resumo e síntese dos resultados extraídos dos estudos (meta-análise);
• Interpretação dos resultados para determinar sua aplicabilidade;
• Escrita do Mapeamento.
A adaptação dessas ideias resultou nas etapas do processo adotado nessa pesquisa,
conforme apresentado na Figura 4.
Capítulo 3. Revisão da Literatura 39

Figura 4 – Etapas do Mapeamento Sistemático da Literatura

Fonte: o Autor

3.2.2.2 Execução da Busca

Esta etapa iniciou-se com a definição 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 periódicos e publicações relacionadas
à Elsevier, IEEE, ACM e Springer, uma vez que eles são considerados uns dos líderes
em publicação de produções científicas de alta qualidade (BRERETON, 2007). Essa busca
também serviu para melhorar os termos para a string de busca.
Os termos selecionados, bem como sinônimos e plurais foram armazenados em uma
planilha eletrônica, 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 combinações.
Após a definição da string, foi realizada a busca automática. Para execução 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 técnica snowball. Essa
técnica consiste em pesquisar as referências dos artigos selecionados em busca de trabalhos
Capítulo 3. Revisão da Literatura 40

relevantes que não foram encontrados pelos engenhos de busca. Deste modo, os estudos
disponíveis eram comparados com os já existentes da busca automática e manual. Se o
estudo já houvesse sido armazenado anteriormente, o último era então descartado.

3.2.2.3 Critérios de Seleção dos Estudos

Cada estudo retornado através das buscas foi avaliado em relação a sua relevância quanto
a esse MSL. Assim, todos passaram por critérios de exclusão e inclusão.
Critérios de inclusão:
• O trabalho explora SGRH com IoT como foco principal;
• O trabalho apresenta um SGRH com IoT, mesmo que seja a implementação de um
estudo de caso ou avaliação de uma técnica, ideia ou contribuição.
Critérios de exclusão:
• Estudos sem foco na área de IoT;
• Estudos duplicados;
• Keynotes, Whitepapers e apresentações;
• Trabalhos antes de 1999;
• O estudo não responde às questões de pesquisa.
A exclusão de Keynotes, Whitepapers e apresentações fez-se pelo interesse da busca
ser realizada em bibliotecas digitais científicas, porém a inclusão desses artefatos pode
enriquecer a pesquisa com contribuições de cunho comercias e experimentais. Foram ex-
cluídos também 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 critério de exclusão também
carece de esclarecimento: alguns artigos mesmo passando por todas as fases do processo
de seleção não expunham detalhes sobre o sistema, inviabilizando a extração das respostas
às questões de pesquisa.
Primeiramente, os critérios foram aplicados nos títulos, palavras-chave e abstract. Em
seguida foram executados na introdução e conclusão. Até este momento apenas os traba-
lhos que claramente estavam fora do escopo desta pesquisa foram excluídos. Por último,
as versões completas dos estudos restantes foram lidas para uma análise mais detalhada.

3.2.3 Síntese e Análise dos Dados
Esta subseção apresenta os resultados obtidos a partir do MSL, descrito na seção anterior.
Para um melhor entendimento, os resultados foram agrupados em quatro categorias:
• Extração e análise de dados: informações gerais sobre os dados retornados.
• Respostas das Questões de Pesquisa: foram agrupadas nessa categoria as res-
postas relacionadas a cada Questão de Pesquisa.
• Discussão dos resultados: uma discussão baseada nos principais resultados.
Capítulo 3. Revisão da Literatura 41

• Síntese do mapeamento: é apresentado um resumo dos resultados obtidos deste
mapeamento.

3.2.3.1 Extração e Análise dos Dados

Os dados apresentados aqui advêm da execução do protocolo definido na subseção 3.2.2,
resumidos na Figura 6. Esta subseção está dividida em (a) Seleção dos Dados e (b) Análise
dos Dados.

Figura 6 – MSL - Resumo do protocolo

Fonte: o Autor

a. Seleção dos Dados
Da aplicação do protocolo executado neste MSL, já aplicados todos os filtros de seleção
nos artigos encontrados na pesquisa ad-hoc, na busca manual, na busca automática e
por cima aplicada a técnica Snowball, chegou-se a um total de 55 artigos selecionados,
apresentados no Anexo A.
A Figura 7 (a) apresenta os resultados parciais da aplicação dos critérios de seleção
na busca automática e (b) resume o resultado final da seleção dos dados desse MSL.

b. Análise dos Dados
Por ano
Para essa pesquisa levou-se em consideração 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,
porém são trabalhos com termos genéricos o que inviabilizaria a execução da busca.
Apesar da exclusão de 195 trabalhos por esse filtro, houve-se a preocupação de ler o
título e abstract desses artigos, o que confirmou sua exclusão. Uma possível explicação
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
Capítulo 3. Revisão da Literatura 42

Figura 7 – MSL - Artigos selecionados

(a) Resultados parciais da busca automática (b) Artigos selecionados
Fonte: o Autor

Internet of Things existir, é a possível classificação 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, porém, vale salientar
que essa pesquisa ocorreu em meados daquele ano.

Figura 8 – MSL - Artigos por ano de publicação

Fonte: o Autor

Por País da instituição dos autores
O país 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 países e a
preocupação dos pesquisadores quanto à gerência de recursos hídricos.
Neste MSL não foi encontrado nenhum trabalho brasileiro. Esse é um campo com
potencial de ser explorado por pesquisadores brasileiros, uma vez que a falta de água
Capítulo 3. Revisão da Literatura 43

Figura 9 – MSL - Artigos por País de publicação

Fonte: o Autor

faz com que a população rural e das pequenas cidades do Semiárido brasileiro fiquem
submetidas a condições de extrema dificuldade (PADILHA et al., 2004).

3.2.3.2 Respostas das Questões de Pesquisa

Esta pesquisa utilizou uma abordagem quantitativa baseada no texto, palavras-chave e
figuras dos trabalhos selecionados para obter as resposta. Existem Questões de Pesquisas
que não são respondidas por todos os trabalhos selecionados, assim, para se computar a
resposta de cada QP são utilizados os trabalhos selecionados que respondem a questão,
esses trabalhos são chamados de trabalhos válidos neste MSL.
QP1 – Quais os tipos de SGRH que empregam IoT. Esses sistemas podem
ser categorizados?
Baseado nos artigos selecionados, pôde-se chegar a algumas áreas de pesquisas rela-
cionadas com SGRH. Esse agrupamento foi feito por certas características dos sistemas,
como por exemplo, tipos de sensores usados, necessidade de atuadores, palavras-chaves e
termos encontrados nos artigos.
Após esse agrupamento, chegou-se a cinco categorias básicas: Gerenciamento de água,
Água na agricultura, Monitoramento de água, Monitoramento de enchente e Suprimento
de água.
QP2 – Quais modelos de arquitetura de IoT são empregados nestes siste-
mas?
Os dados para a resposta a essa questão foram obtidos a partir da declaração explícita
do trabalho quanto à arquitetura usada. Para isso foi considerada arquitetura composta
por cinco camadas: camada de Percepção, camada de Rede, camada de Processamento,
camada de Aplicação e camada de Negócios (MIAO, 2012).
Assim, dos 55 artigos selecionados 31 trabalhos não fazem qualquer alusão à arquite-
tura empregada. Para esses trabalhos que não declaram a arquitetura usada não houve
esforço para classificá-los quanto à arquitetura, este esforço está fora do escopo deste tra-
balho. A Figura 10 mostra os resultados dos artigos válidos para essa questão de pesquisa.
Neste MSL 59% dos trabalhos válidos declaram ou explicitam usar a arquitetura em
3 camadas, desta forma, neste trabalho encontra-se evidência que a maioria dos SGRH
Capítulo 3. Revisão da Literatura 44

Figura 10 – MSL - Artigos por Camadas de IoT

Fonte: o Autor

empregam o modelo de arquitetura de IoT clássica em 3 camadas, sendo: Camada de
Percepção, Camada de Rede e Camada de Aplicação.
QP3 – Quais tecnologias de comunicação são usadas nestes sistemas?
Al-Fuqaha et al. (2015) distinguem três abordagens de IoT diferentes para a conectivi-
dade de dispositivos: (i) um protocolo de baixa potência (por exemplo, Zigbee, Bluetooth,
Z-Wave) que é integrado com a infraestrutura LAN através de um gateway de aplicação,
(ii) dispositivo conectado diretamente à LAN (Ethernet/Wi-Fi), (iii) o dispositivo se co-
necta diretamente ao usuário (por exemplo rede celular, Wi-Fi).
Assim, essa questão de pesquisa é subdividida em duas: QP3.1 comunicação interna e
QP3.2 comunicação externa. A Figura 11 mostra essa subdivisão utilizada neste MSL.

Figura 11 – MSL - Comunicação Interna e Externa

Fonte: o Autor

Para compreender o que é comunicação 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.
Capítulo 3. Revisão da Literatura 45

• Destino - É o destino dos dados obtidos pelo Nó, onde esses dados podem ser
acessados pelo usuário, através de uma nuvem de dados, tablets ou celulares.
• Gateway - É um dispositivo intermediário geralmente destinada a interligar redes,
separar domínios de colisão, ou traduzir protocolos.
• Comunicação interna - É a comunicação entre:
- o sensor e o controlador dentro de um Nó;
- um Nó e o Gateway do sistema;
- Nós que formam uma WSN.
• Comunicação externa – É a comunicação entre um Nó e o destino, ou entre um
Gateway e o destino.
QP3.1 - Comunicação Interna ou LAN.
Neste MSL em 4 artigos não foi possível computar a forma de comunicação interna.
A Figura 12 mostra a síntese dos resultados desta subquestão de pesquisa.

Figura 12 – MSL - Comunicação Interna por Artigos

Fonte: o Autor

Uma forma empregada de comunicação em SGRH é a comunicação direta entre os Nós
e o Gateway, sendo usado em 23% dos trabalhos válidos. Neste modelo o sensor é plugado
diretamente ao controlador, o qual possui alguma forma de comunicação com o destino.
Verificou-se também que, Bluetooth e Wi-Fi são duas tecnologias também usadas em
SGRH. Nesta pesquisa, ambas as tecnologias foram usadas em 8% dos trabalhos válidos.
Por fim, neste MSL verificou-se que Zigbee é a tecnologia mais empregada para realizar
a comunicação interna em SGRH, sendo usada em 57% dos trabalhos válidos, isso se deve
principalmente ao seu baixo consumo de energia.
QP3.2 - Comunicação Externa ou WAN.
É a comunicação usada entre Nó ou Gateway e o destino. A Figura 13 mostra uma
síntese das tecnologias encontradas neste MSL.
Apesar de ser uma das tecnologias mais antigas, GSM é a forma de comunicação mais
empregada nos SGRH, sendo usada em 11 trabalhos válidos. Como se vê na Figura 13 (a),
somando os trabalhos que usam as tecnologias GSM ou GPRS tem-se quase metade dos
trabalhos válidos. Outra forma bastante empregada é a ligação cabeada entre o Gateway
e a Internet através do padrão Ethernet, sendo usado em 24% dos trabalhos.
Capítulo 3. Revisão da Literatura 46

Figura 13 – MSL - Comunicação Externa

(a) Comunicação Externa por Artigos (b) Comunicação Externa por Ano
Fonte: o Autor

Figura 14 – MSL - Sensores

(a) Tipos de Sensores (b) Sensores e Tecnologias por Categoria
Fonte: o Autor

Uma técnica que está sendo empregada recentemente é usar o smartphone como Ga-
teway. Neste MSL essa forma de comunicação foi chamada de diversa, por usar todas as
tecnologias de comunicações disponíveis nestes aparelhos, podendo ser GSM, GPRS, 3G,
4G e Wi-Fi. Dois trabalhos válidos usaram essa tecnologia em suas soluções.
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
técnicas como o uso do aparelho celular como Gateway e tecnologias como 3G, 4G e Wi-Fi.
QP4 - Quais sensores são usados nestes sistemas?
A partir dos artigos selecionados foi possível descobrir os principais sensores usados
em SGRH. A Figura 14 (a) enumera esses sensores.
Além desses sensores, também são usadas tecnologias como câmera 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 técnicas ou sensores são usados para medir volume de água?
Em diversos campos relacionados à água, como os sistemas de aviso de pré-enchente
e sistemas de irrigação dados relativos ao nível de água são informações fundamentais.
Capítulo 3. Revisão da Literatura 47

Figura 15 – MSL - Técnicas de medição de volume de água

(a) Técnicas de medição de volume de água (b) Síntese das Técnicas
Fonte: o Autor

Figura 16 – MSL - Controladores usados em IoT

(a) Controladores empregados por artigo (b) Síntese dos Controladores usados
Fonte: o Autor

A Figura 15 mostra o resultado da extração dos artigos selecionados nesse MSL quanto
às técnicas e tecnologias usadas para medição do volume de água. Dos 55 artigos seleci-
onados 23 artigos não usam sensor de nível de água, ou seja 58% dos artigos empregam
este tipo de sensor. Dos artigos que empregam sensor, 7 não descrevem a tecnologia usada
para obter o nível de água. Assim, resultaram 25 trabalhos válidos.
Como mostra a Figura 15 (b) 60% dos artigos válidos utilizam a técnica de sensor
ultrassônico.
QP6 - Quais controladores são usados para desenvolver esses sistemas?
IoT usa diversas tecnologias emergentes, essas tecnologias utilizam recentes técnicas
eletrônicas e incorporam computadores digitais embutidos baseados em microprocessado-
res para funções de controle, análise e comunicação. Microcontrolador é um dispositivo
em um único circuito integrado o qual contém um núcleo de processador, memória e
periféricos programáveis de entrada e saída.
A Figura 16(a) mostra o resultado da extração de dados em busca dessa questão de
pesquisa. Essa não é uma pergunta trivial de se responder, uma vez que diversos trabalhos
não descrevem o controlador usado no sistema proposto. Em 33% dos artigos selecionados
não foi possível definir qual o controlador usado.
Capítulo 3. Revisão da Literatura 48

Figura 17 – MSL - Formas de energia usadas em SGRH

(a) Formas de energia usadas por artigos (b) Síntese das formas de energia
Fonte: o Autor

Outra dificuldade é a grande variedade de controladores usados para desenvolver
SGRH. Em 21 artigos são usados diversos controladores que aparecem em apenas um
único trabalho.
Os controladores que merecem destaques são Arduino2 e Raspberry Pi3 . Este MSL
mostra evidências que ambos controladores são os mais usados em SGRH, como mostra
a Figura 16(b), onde esses controladores aparecem em 26% e 19% dos artigos válidos
respectivamente.
QP7 - Quais as formas de energia são empregadas nestes sistemas?
A forma de obtenção de energia em SGRH é uma questão importante uma vez que
muitos dos Nós nestes tipos de sistemas estão localizados em locais sem acesso a energia
externa, ou seja, energia fornecida por uma empresa de distribuição de energia elétrica,
ou em locais de difícil 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 não ser o tema principal dos artigos selecionados. A Figura 17 (a) mostra
o resultado da extração dos dados em busca da resposta a essa questão de pesquisa.
A Figura 17 (b) mostra a resposta da pergunta de pesquisa, considerando-se apenas
os artigos válidos. A forma de energia externa tem apenas 7%, isso se deve principalmente
a dificuldade de obtenção desse tipo de energia nestes sistemas. Apenas 3% dos sistemas
usam a forma de captação ou geração de energia dentro do próprio sistema. Juntamente
com Bateria, a Energia Solar é a forma de energia mais usada nesses sistemas, ambas
sendo usadas em 45% dos artigos válidos.
QP8 – Esses sistemas usam Computação 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 não Computação 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/
Capítulo 3. Revisão da Literatura 49

Figura 18 – MSL - Uso de Computação em Nuvem

(a) Uso de Computação em Nuvem por artigo (b) Uso de Computação em Nuvem por ano
Fonte: o Autor

usam o paradigma de computação em nuvem nos SGRH.
A Figura 18 (b) mostra o uso da Computação em Nuvem nos SGRH por ano. Nesse
MSL, constatou-se que o paradigma de computação 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 Discussão dos Resultados

Com base nos resultados obtidos no MSL, a discussão dos resultados está dividida nos
seguintes temas:
a. Tecnologias de comunicação em SGRH;
b. Sensores usados em SGRH;
c. Técnicas e sensores de nível de água;
d. Controladores usados em SGRH; e
e. Energia usada para alimentação dos Nós em SGRH.

a. Tecnologias de comunicação em SGRH
Segundo evidências mapeadas neste MSL, para estabelecer a comunicação interna do
SGRH as tecnologias mais usadas são (i) Zigbee 57%, (ii) Bluetooth 8% e (iii) Wi-Fi 8%
dos trabalhos válidos.
(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 versão do Bluetooth, especifi-
cada na sua versão 4.0, de baixo consumo de energia. BLE permite diminuir os níveis
de consumo de energia em aparelhos que não precisam transmitir grandes volumes de
dados. Isso ocorre porque ele foi projetado para aplicações que precisam enviar poucas
informações e de forma esporádica.
Bluetooth e BLE não são tecnologias concorrentes, uma vez que o foco principal do
BLE são aplicações cujo gasto de energia seja mínimo, normalmente envolvendo apenas
Capítulo 3. Revisão da Literatura 50

informar um estado ou servir de gatilho, não abrangendo tráfego contínuo de dados como
é o caso da versão 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 potência em redes sem fio, incluindo soluções para
a utilização 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 (América) e 868Mhz (Europa) e com taxas de transferência de dados
de 250kbps, 40kbps e 20kbps respectivamente.
Dependendo da velocidade de conexão, o alcance de transmissão varia entre 10m e
100m, podendo chegar a mais, dependendo diretamente da potência dos equipamentos e
de características ambientais, como obstáculos físicos e interferência eletromagnética.
(iii) Wi-Fi
Wireless Fidelity (Wi-Fi), definido em IEEE 802.11, fornece comunicação ininterrupta
ao usuário em taxas de dados mais altas que Zigbee e BLE, porém sua principal desvan-
tagem em relação a esses é o alto consumo de energia.
Os principais padrões na família IEEE 802.11 são:
• IEEE 802.11a: Frequência 5 GHz com capacidade teórica de 2 Mbps;
• IEEE 802.11b: Frequência 2,4 GHz com capacidade teórica de 11 Mbps;
• IEEE 802.11g: Frequência 2,4 GHz com capacidade teórica de 54 Mbps;
• IEEE 802.11n: Frequência 2,4 GHz e/ou 5 GHz com capacidade de 150 a 600 Mbps.
Comparação Zigbee, BLE e Wi-Fi
Quanto ao número máximo de dispositivos pertencentes a uma rede, o BLE pode ter
8 células contra 65.000 possíveis com uma rede Zigbee e 2.007 para uma estrutura Wi-Fi.
Zigbee, foi projetado para ser uma alternativa de baixa potência para Bluetooth, e de
fato oferece um desempenho significativamente melhorado de 30mW em comparação com
o 100mW do Bluetooth. Porém, 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 portáteis, sujeitos a curtos intervalos de uso. Por outro lado, Wi-Fi
é projetado para uma conexão mais longa e necessita de dispositivos com uma fonte de
alimentação substancial.
Os três protocolos aqui comparados possuem mecanismos de criptografia e autentica-
ção para segurança da informação. O padrão 802.15.4 requer o uso do algoritmo AES com
chaves e comprimentos de bloco de 128 bits. Da mesma forma que a especificação Zigbee,
a confidencialidade da sessão no BLE também é fornecida pela criptografia AES.

b. Sensores de qualidade de água usados em SGRH
A Portaria 2.914, de 12 de dezembro de 2011, do Ministério da Saúde, dispõe sobre os
procedimentos de controle e de vigilância da qualidade da água para consumo humano e
Capítulo 3. Revisão da Literatura 51

seu padrão de potabilidade. Ela estabelece os parâmetros a serem medidos e controlados
para que a água seja considerada própria para o consumo humano.
No seu Art. 3º essa portaria diz que: "Toda água destinada ao consumo humano, distri-
buída coletivamente por meio de sistema ou solução alternativa coletiva de abastecimento
de água, deve ser objeto de controle e vigilância 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. Técnicas e sensores de nível de água
Existem diversos sensores comerciais e propostos pela academia que se propõem a
realizar a medição do nível de água e muitos fatores afetam a seleção desses sensores,
alguns deles são: qualidade, ambiente a ser usado, intervalo de medição, tempo de resposta
e custo do sensor (LOIZOU; KOUTROULIS, 2016).
Uma boa solução para sistemas de medição em aplicações de nível de água é o uso de
sensores capacitivos. Nesta técnica o nível do líquido contido entre placas de metal altera
a capacitância total do sensor. Devido à grande variedade de materiais disponíveis no
mercado, os sensores capacitivos de nível de líquido podem ser de baixo custo e certificados
para contato com água potável.
As principais desvantagens da abordagem de tipo capacitivo são que ela pode ser
afetada por capacitâncias parasitas e que o desempenho em longo prazo dos materiais de
construção devem ser testado (LOIZOU; KOUTROULIS, 2016). Além 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 potável.
Atualmente, os sensores de ultrassons são os sensores de nível de água mais utilizados
em tanques de armazenamento de líquidos em grande escala, por serem não invasivos,
serem facilmente instalados e seu funcionamento não depender do tipo de líquido (KONS-
TANTINOS et al., 2015). Sensores ultrassônicos capturam ondas acústicas refletidas a partir
da superfície da água, onde o tempo de viagem de onda corresponde à distância entre a
superfície da água e o sensor.
No entanto, estes sensores apresentam a principal desvantagem de que as ondas sonoras
emitidas sobre a superfície do líquido podem ser dispersadas, por exemplo, devido a
movimento do líquido ou a existência de bolhas, o que pode resultar em erro de precisão.

d. Controladores usados em SGRH
IoT usa um controlador para funções de controle, análise e comunicação, empregados
para controlar os sensores e as comunicações dos sistemas. Neste MSL verificou-se uma
grande variedade de controladores usados em SGRH. Porém, duas plataforma de prototi-
pagem se destacaram: Arduino e Raspberry Pi, sendo usados em 26% e 19% dos trabalhos
válidos respectivamente.
Capítulo 3. Revisão da Literatura 52

Figura 19 – MSL - Características Arduino e Raspberry Pi

Fonte: Arduino4 e Raspberry Pi5

Arduino e Raspberry Pi são duas plataformas bem diferentes. Raspberry Pi é um
computador totalmente funcional, enquanto o Arduino é um microcontrolador. Enquanto
o Arduino é uma plataforma específica para desenvolvimento de projetos eletrônicos, o
Raspberry Pi é um computador completo com sistema operacional, interface com usuário,
possibilidade de ligação de periféricos e afins. A Figura 19 mostra as principais caracte-
rísticas destas duas plataformas.
O preço e o tamanho dos dois dispositivos são praticamente as únicas semelhanças.
Raspberry Pi é cerca de 40 vezes mais rápido no que diz respeito a velocidade de clock do
que o Arduino e possui 128.000 vezes mais memória RAM. O Raspberry Pi é um com-
putador independente que pode executar um sistema operacional Linux. Essas vantagens
de configuração de hardware do Raspberry custam um consumo de energia quatro vezes
maior do que a do Arduino.
Enquanto o Raspberry Pi é superior na aplicação de software, a simplicidade do Ar-
duino faz com que seja uma solução mais adequada para projetos de hardware puro. O
Arduino tem uma capacidade de trabalho em tempo-real e analógico 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 condução de motores, leitura de sensores e tarefas
com LED.

e. Energia usada para alimentação dos Nós em SGRH
A forma de obtenção de energia em SGRH é importante uma vez que muitos dos
Nós nestes tipos de sistemas estão localizados em locais sem acesso a energia externa,
ou encontram-se em locais de difícil acesso para troca de bateria. Segundo esse MSL, as
formas de alimentação de energia mais usadas em SGRH são (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 opção, porém 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 Aquisição de
Dados ECG Sem Fio, no qual para alimentação é usado Bateria de 9V e 250 mAh, sendo
Capítulo 3. Revisão da Literatura 53

usado uma Placa Arduino, um Sensor e um módulo Bluetooth para comunicação. Os com-
ponentes usados para esse sistema consomem aproximadamente 65mA. A bateria neste
sistema durou em torno de 22 horas de extração contínua de dados de eletrocardiograma.
(ii) Painel de Energia Solar
A principal desvantagem do projeto alimentado por bateria é que ele vai esgotar após
certo tempo. Esta desvantagem pode ser eliminada usando recursos naturais como energia
solar. Os painéis solares são dispositivos que convertem luz solar em energia elétrica.
As principais vantagens de usar painel solar são: é uma fonte renovável, energia limpa,
possui baixo custo de manutenção e pode ser usado em locais não atendidos por outras
fontes de energia. Suas desvantagens são: em dias de chuva ou com baixa incidência de
sol diminui a geração de energia e no período da noite não ocorre a produção de energia.
O estado da arte é usar um painel solar para capturar energia, e então usar uma
bateria para armazená-la. Assim, este dispositivo funciona como uma fonte de alimentação
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 não há incidência
solar suficiente.
(iii) Fonte Externa
Nesta solução um adaptador é usado para converter a energia elétrica fornecida por
companhias especializadas em alimentação para os dispositivos.
A opção com energia externa oriunda de uma rede convencional de energia possui a
vantagem de ser uma fonte constante de energia e de baixo custo. Porém essa solução
possui o inconveniente de ter cabos elétricos saindo da fonte até o Nó, o que em alguns
casos podem chegar a dezenas de metros.

3.2.3.4 Síntese do Mapeamento Sistemático da Literatura

Sintetizando este mapeamento, a Figura 20 apresenta as tecnologias, padrões e tendên-
cias dos SGRH descobertos no MSL, dispostos por camadas do modelo de arquitetura
IoT. Na primeira linha de componentes têm-se as categorias de SGRH, sendo essa a Ca-
mada de Negócio, a partir daí, a figura se desenvolve nas demais camadas: Aplicação,
Processamento, Rede e Percepção.
Uma possível leitura desta figura é: Gerenciamento de Água é uma categoria dos
SGRH, o qual possui obrigatoriamente uma aplicação que pode ser web, mobile ou os
dois; esses sistemas possuem obrigatoriamente uma tecnologia de comunicação externa,
onde as tecnologias que se destacaram foram GPRS e GSM; esses sistemas podem ter um
Gateway para realizar a comunicação externa; esses sistemas podem fazer uso do para-
digma da Computação em Nuvem; todos os sistemas de gerenciamento de água devem
possuir Nó; esses Nós precisam obrigatoriamente de uma tecnologia de comunicação in-
terna, onde Zigbee é o padrão de fato; os Nós devem usar um ou mais Controladores para
coordenar as leituras dos sensores e as comunicações; todos os Nós precisam obrigatoria-
Capítulo 3. Revisão da Literatura 54

Figura 20 – Síntese do Mapeamento Sistemático da Literatura

Fonte: o Autor

mente de Sensores, o sensor mais usado é o sensor de nível de água, e a tecnologia mais
empregada para esse tipo de sensor é a tecnologia ultrassônica; por fim, todo Nó precisa
de alimentação elétrica e essa alimentação pode ser por Bateria, Painel Solar, energia
Externa ou uma combinação destes.

3.2.4 Resumo da Seção
Esta seção apresentou o MSL das técnicas e tecnologias usadas nos SGRH. A partir deste
MSL pôde-se chegar a diversas conclusões que servirão de escopo inicial e referencial
teórico para o desenvolvimento deste trabalho.

3.3 Considerações Finais do Capítulo
Este capítulo na seção 3.1 descreveu o resultado da análise de como o programa de distri-
buição de água no Semiárido brasileiro funciona e emprega a TI em seu apoio e apresentou
na seção 3.2 o estado da arte de SGRH que empregam IoT através de um MSL.
No próximo capítulo será apresentada a Arquitetura Proposta como solução do pro-
blema de pesquisa desta dissertação.
55

4 Arquitetura Proposta

Este capítulo tem por objetivo apresentar a Arquitetura Proposta para solução do pro-
blema de pesquisa desta dissertação. Para isso na seção 4.1 são apresentados um conjunto
de requisitos fundamentais a serem atendidos pela arquitetura. A seção 4.2 define o mo-
delo de arquitetura IoT usado, descrevendo as tecnologias empregadas em cada camada
da arquitetura. Por fim, a seção 4.3 apresenta a especificação da arquitetura de software,
detalhando as Camada de Aplicação e Camada de Negócio e validando a AS especificada.

4.1 Requisitos para Arquitetura Proposta
Dos resultados obtidos da metodologia aplicada na seção 3.1 foi possível elicitar os princi-
pais requisitos necessários para o desenho de uma Arquitetura Proposta para um SGRH
para a região semiárida do Brasil.
Os requisitos tratados nesta solução não 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-
plementação 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: Mínima interação do usuário
Como visto na seção 3.1.4, um dos principais problemas relatados no atual modelo de
distribuição de água é a grande quantidade de interação humana no processo. Assim, a
arquitetura deve atender aos requisitos do sistema com o mínimo envolvimento do usuário.
Req #2: Interoperabilidade
Interoperabilidade é a capacidade de um sistema se comunicar de forma transparente
com outro. A infraestrutura de gestão da água atualmente implantada consiste em muitos
processos interligados que devem ser geridos utilizando sistemas legados. Substituir esses
sistemas por novos não é sempre uma solução viável. Assim, a arquitetura deve apoiar a
integração com sistemas legados.
Req #3: Eficiência Energética
Em SGRH os Nós podem ficar em locais de difícil acesso a energia externa conven-
cional, precisando ser alimentado por outras fontes, como bateria, por exemplo. Como a
quantidade de Nós é da ordem de dezenas de milhares, caso esse requisito não seja levado
em consideração o consumo de energia pode inviabilizar o projeto, devido principalmente
a dificuldade da gerência do funcionamento destes Nós.
Capítulo 4. Arquitetura Proposta 56

Req #4: Ubiquidade/Mobilidade
Este termo corresponde a qualquer tecnologia móvel capaz de capturar informações
sobre o ambiente ou atuar sobre ele (SANCHEZ, 2011). Ao considerar que o número de
smartphones em uso no Brasil chegou a 168 milhões em maio de 2016 (MEIRELLES, 2016),
é natural associar ubiquidade ao uso destes dispositivos e usá-los em soluções de SGRH.
Req #5: Segurança
Devido à natureza do sistema proposto, que trabalha com um valor monetário consi-
derável e gera dados sensíveis à administração pública, não é admissível que a arquitetura
não satisfaça este requisito. Todo dado deve ser protegido fazendo uso das políticas de
privacidade e segurança, tanto em relação à disponibilidade quanto ao armazenamento.
Req #6: Geolocalização
Como visto na seção 3.1, o sistema atual faz uso direto de informações georreferen-
ciadas tanto para monitoramento das entregas como para a localização dos Mananciais
e PAbsts. Neste sentido, a arquitetura proposta deve empregar tecnologias e técnicas de
geolocalização para manter essas funcionalidades.
Req #7: Disponibilidade
Para permitir o fornecimento de informações contextualizadas a arquitetura deve ser
altamente disponível. Para isso, a arquitetura deve implementar diversos requisitos, entre
eles: acomodar o crescimento da rede, aplicações e serviços de IoT; permanecer operacional
mesmo na presença de falhas; e estar disponível em todos os momentos. Esse requisito
também se aplica aos Nós, os quais devem está disponível, se não a todo momento, pelo
menos em horários predeterminados.
Req #8: Flexibilidade/Extensibilidade
O sistema deve fornecer uma arquitetura flexível e extensível permitindo a integração
de diferentes sistemas baseados em tecnologias específicas. A arquitetura deve ser inde-
pendente de padrões específicos de hardware e software a fim de permitir a inserção de
novos serviços e ser capaz de adaptar-se a novos requisitos.
Req #9: Baixo custo
Tendo em vista que o sistema proposto trabalha com diversos Nós, atualmente com
mais de 65 mil PAbsts, caso as tecnologias e dispositivos empregados na solução não sejam
economicamente viáveis, o custo pode inviabilizar o projeto. Assim, este requisito deve
ser observado em todo projeto, de forma a mantê-lo o mais econômico possível.
Req #10: Adequação aos modelos atuais de distribuição de água
O sistema deve seguir algumas características e particularidades dos modelos atuais de
distribuição de recursos hídricos empregados na região de semiárido do Brasil, devido a
força de lei e investimentos já realizados. Não propondo, por exemplo, novos modelos de
negócios ou de logística. Em resumo, este requisito certifica que o sistema proposto deve
alterar o mínimo possível os modelos de distribuição de água empregados atualmente na
região em que for aplicado.
Capítulo 4. Arquitetura Proposta 57

4.1.1 Resumo da Seção
Elicitados os principais requisitos necessários para o desenho de uma arquitetura proposta
para um SGRH em regiões semiáridas brasileira, na próxima seção será apresentada a
arquitetura de IoT da solução proposta que visa atingir estes requisitos.

4.2 Especificação da Arquitetura IoT
Nesta seção será definido o modelo de arquitetura IoT que será usado neste trabalho.
Depois serão apresentadas as camadas da arquitetura proposta, analisando opções que
podem ser usadas para implementar essa arquitetura.
Para definir as tecnologias e técnicas mais adequadas para implementar a arquitetura
proposta foram levados em consideração os resultados do MSL realizado na seção 3.2, as
características da região onde será implantado o SGRH e os requisitos elicitados na seção
4.1. O objetivo é montar uma prateleira com opções de tecnologias e técnicas que podem
ser usadas para implementar a arquitetura proposta neste trabalho.

4.2.1 Definição do Modelo de Arquitetura IoT Empregado
Arquiteturas são necessárias para representar, organizar e estruturar a IoT de uma forma
que lhe permita funcionar de maneira eficiente e eficaz (WHITMORE et al., 2015). Uma série
de artigos propõem vários projetos de arquitetura conceitual para atender aos requisitos
de aplicações em IoT (KORTUEM et al., 2010). Essa diversidade de projetos destaca a
importância da questão da definição da arquitetura a ser empregada (WHITMORE et al.,
2015). Porém, pesquisas em IoT ainda estão em sua fase infantil, e, portanto, não 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 número de camadas e
seu escopo são definidos dependendo das infraestruturas, tecnologias e tipos de sistemas
de IoT. Como a escalabilidade e a interoperabilidade têm uma grande importância em
aplicações IoT, definir a arquitetura com melhores abstrações pode facilitar essas questões
(MASHAL et al., 2015).
Assim, da análise da revisão da literatura de modelos de arquitetura de IoT conclui-se
que:
• ainda não há uma arquitetura padrão para IoT (MASHAL et al., 2015);
• a integração entre IoT e Computação em Nuvem é uma opção viável 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 Computação em
Nuvem (SUCIU et al., 2014), sendo o mais empregado em projetos de IoT (MASHAL
Capítulo 4. Arquitetura Proposta 58

et al.,
2015).
Desta forma, existem evidências que o modelo de arquitetura de IoT em cinco camadas
integrado com a Computação em Nuvem é um modelo viável 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 próximas subseções serão
apresentadas as camadas desta arquitetura, propondo opções de tecnologias que podem
ser usadas para implementação da arquitetura.

4.2.2 Camada de Percepção
Tipicamente um Nó de uma WSN possui 4 unidades principais, conectadas entre si: uni-
dade de sensor, unidade de processamento, unidade de comunicação e unidade de alimen-
tação (CHEN; YEN-KUANG, 2012). A Figura 22 mostra a interação destas unidades.

Figura 22 – Unidades de um Nó IoT

Fonte: Partynski e Koo (2013)

Para a montagem da prateleira da Camada de Percepção, serão analisadas as tecno-
logias e técnicas disponíveis para essas quatro unidades, obtidas através dos resultados
do mapeamento sistemático realizado na seção 3.2, a fim de propor opções que possam
atender aos requisitos do projeto.
Capítulo 4. Arquitetura Proposta 59

4.2.2.1 Unidade de Medição

Consiste dos sensores para medir os valores físicos. Nesta arquitetura são usados sensores
para medir o volume de água entregue e sua qualidade. Assim, segundo o MSL, as opções
de sensores para essa arquitetura são:
Sensor de Nível de Água
Segundo o MSL, as técnicas mais empregadas neste tipo de sensor são capacitivos e
ultrassônicos. Loizou e Koutroulis (2016) afirmam que o sistema de medição de nível de
água capacitivo alcança desempenho equivalente ao de um dispositivo de detecção de nível
de água de ultrassom comercialmente disponível e possui um custo de fabricação menor.
Porém, para utilização de sensores de nível de água para grandes projetos de SGRH
a compra de um modelo comercial de sensor ultrassônico pode ser a mais recomendada,
devido ao custo deste tipo de sensor ser relativamente baixo e ser uma solução padrão de
mercado, já bastante usada e experimentada em projetos de grande porte.
Sensor de Qualidade da Água
Nessa pesquisa não foi encontrado um único sensor de qualidade de água que abranja
todos os parâmetros estabelecidos pela Portaria 2.914 do Ministério da Saúde, que rege
as normas para que uma água seja considerada própria para consumo humano. O MSL
realizado na seção 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 enumeração serve como um ponto de partida, devendo cada caso ser analisado
e adequado à sua realidade. No caso do Semiárido 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 módulo são 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 Nós usados neste projeto de SGRH, onde a unidade
de processamento é usada basicamente para controlar a leitura e a comunicação interna
dos sensores, acredita-se que a melhor escolha para esse projeto pode ser a plataforma
Arduino. Outro fator que leva a essa recomendação é o seu menor consumo energético,
cerca de 4 vezes menor que Raspberry Pi.
Capítulo 4. Arquitetura Proposta 60

4.2.2.3 Unidade de Alimentação

A energia hidrelétrica, ainda não chega a todos os locais do Semiárido brasileiro. Além
disso, utilizar cabos elétricos que podem atingir dezenas de metros talvez não 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 manutenção. Essa
desvantagem fere diretamente os requisitos Req #3: Eficiência Energética, Req #7: Dis-
ponibilidade e Req #9: Baixo custo.
No Brasil, a insolação é satisfatória durante todo ano, principalmente na região a ser
implantado o SGRH (PADILHA et al., 2004). As principais desvantagens enumeradas pela
literatura quanto ao uso de painel solar são: a não geração de energia durante a noite
e seu custo. A primeira resolve-se com a utilização de bateria recarregável alimentada
pelo painel solar. Quanto à segunda, existem diversas soluções no mercado com baixo
custo, por exemplo, um módulo 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 opção para alimentar um Nó é painel
solar, devido ao baixo custo de aquisição e manutenção e da abundância de incidência
solar nesta região.

4.2.2.4 Unidade de Comunicação

A fim de avaliar quais as tecnologias para comunicação interna mais se adequam ao
SGRH proposto, foi criada uma matriz de três dimensões, que consiste dos requisitos da
Arquitetura de Proposta do SGRH versus as principais características das três tecnologias
mais usadas para comunicação interna em SGRH (elicitados do MSL) versus a Avaliação
da Tecnologia, essa matriz é apresentada no Apêndice B.
Os requisitos avaliados nesta matriz foram: Req #3: Eficiência Energética, Req #5:
Segurança, Req #4: Ubiquidade/Mobilidade e Req #10: Adequação aos modelos atuais de
distribuição de água. Atribuídos os seguintes conceitos: A - Atende Completamente, B -
Atende Satisfatoriamente e C - Não Atende.
Para essa avaliação foi empregada uma equipe formada por um Doutor em Engenharia
de Telecomunicações, um Doutor e um Mestre em Segurança da Informação, um Mestre
em Engenharia Elétrica e dois Especialista de Negócio (Analistas do GCDA). Após uma
rápida explanação dos requisitos do negocio, esses especialistas analisaram as caracterís-
ticas e então fizeram a atribuição dos conceitos.
Para obter-se o resultado final do conceito de cada tecnologia de comunicação desta
matriz foi empregado o critério do conceito mais baixo. Neste critério o conceito do Re-
quisito é o conceito mais baixo daquele conjunto de características 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
Capítulo 4. Arquitetura Proposta 61

Tabela 2 – Resultado da avaliação dos protocolos de comunicação

Req # Requisito Bluetooth Zigbee BLE Wi-Fi
Req #3 Consumo Energético C A A C
Req #4 Ubiquidade/Mobilidade A C B A
Req #5 Segurança B B B B
Req #10 Adequação aos modelos atuais B B B B
Resultado Final C C B C
Fonte: O Autor

final da tecnologia resulta do conceito mais baixo atribuído a ela. A Tabela 2 sintetiza o
resultado desta avaliação.
Como visto na Tabela 2, as tecnologias Bluetooth e Wi-fi não atenderam ao requisito
Req #3: Consumo Energético. Já a tecnologia Zigbee não atendeu ao requisito Req #4:
Ubiquidade/Mobilidade por não 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 disponíveis neste campo avançam rapida-
mente e há necessidade de avaliação e comparação contínuas de suas características.

4.2.3 Camada de Rede
IoT é um paradigma onde as coisas são capazes de obter dados ou informações do mundo
físico 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 através de um gateway.
A conexão direta à Internet usando a conexão sem fio por rede celular (GPRS/3G/4G)
são geralmente soluções caras, uma vez que esse tipo de conexão requer assinatura com
uma operadora de rede celular. Se todos os Nós de um grande sistema IoT usarem rede
celular, o custo dos Nós poderá inviabilizar sua implantação (SEOL et al., 2015).
Outro problema a ser observado é quanto a cobertura das redes celulares. Segundo
a Telecom (2016), mais de 1,5 mil municípios do Brasil são atendidos por apenas uma
operadora de celular e a maioria destes municípios encontram-se no Semiárido brasileiro.
Essa região não é um mercado atraente para a entrada de outras prestadoras, podendo
haver, assim, diversos Nós sem cobertura celular, por falta de interesse das operadoras.
Outro risco ligado a esse problema é o fato da necessidade de se ter contrato com várias
operadoras, o que aumentaria os custos e a complexidade administrativa do projeto.
Assim, por essas características citadas acima, acredita-se que a ligação direta dos Nós
com a Internet não é uma boa opção para esse trabalho, sendo necessário um gateway
para essa conexão.
Capítulo 4. Arquitetura Proposta 62

4.2.3.1 Gateway Móvel para IoT

Um dispositivo de gateway para IoT é responsável por permitir a conectividade entre a
Rede de Área Local (LAN) dos sensores e a Rede de Longa Distância (WAN). Esses dispo-
sitivos também podem implementar funções relacionadas à segurança, realizar descoberta
dos dispositivos e seus serviços e servir como dispositivo de Fog Computing.
Fog Computing é um paradigma que consiste na alocação do poder de processamento
para mais perto do limite da rede. Também por vezes denominado de Edge Computing,
Fog Computing amplia o paradigma da Computação em Nuvem até a borda da rede,
possibilitando assim uma nova geração de aplicações e serviços (BONOMI et al., 2012). A
Fog Computing adiciona uma camada a mais de poder de computação entre o nó e a
nuvem, mantendo a análise crítica mais próxima do dispositivo. Desta forma, dispositivos
individuais se tornam nós 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 móvel como gateway, sendo esse um Nó intermediário
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 conexão de
dispositivos através de um gateway deve ser preferida quando os projetos são sensíveis ao
custo ou consumo energético.
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
móvel e autônomo de serviço é apresentada em Golchay et al. (2011). Neste trabalho os
autores propõem uma abordagem de middleware orientado a serviços onde os smartphones
fornecem serviços de gateway para preencher a lacuna existente entre os serviços IoT e
os serviços em nuvem. Pereira e Aguiar (2014) estudaram a viabilidade dos smartphones
como gateways. Entre suas conclusões está que hoje em dia, as redes celulares oferecem
áreas de ampla cobertura, alta taxa de dados e latência decrescente e, portanto, são um
facilitador chave das comunicações Machine-To-Machine (M2M).
Os smartphones estão cada vez mais presentes no dia-a-dia do brasileiro. De acordo
com dados da 27ª Pesquisa Anual de Administração e Uso de Tecnologia da Informação
nas Empresas, realizada pela Fundação Getúlio Vargas (FGV-SP) (MEIRELLES, 2016), o
número de aparelhos smartphones em uso no Brasil chegou a 168 milhões em maio de
2016. Segundo a pesquisa, a projeção é que, até 2018, o número de smartphones chegue a
236 milhões, mais de um aparelho por habitante.
Como na maioria dos casos esses aparelhos possuem capacidade significativa de arma-
zenamento e computação, são equipados com tecnologias de comunicação Wi-Fi, Blueto-
oth ou BLE, redes celulares, GPS e sensores embutidos (LAINE et al., 2014), eles estão se
tornando os candidatos ideais para coletar, processar e encaminhar dados provenientes de
dispositivos IoT.
Capítulo 4. Arquitetura Proposta 63

4.2.3.2 Definição da Camada de Rede da Arquitetura Proposta

Dos fatos descritos acima, conclui-se que nesta arquitetura, a comunicação entre os Nós e
a Internet exige um gateway, uma vez que nos locais dos Nós pode não haver conectividade
WAN e essas duas redes podem trabalhar com padrões diferentes, Bluetooth e rede celular,
por exemplo. Como os dispositivos nos Nós apresentam restrições de recursos, o gateway
também é responsável por diversas tarefas extras de armazenamento e processamento.
Assim, baseado na revisão da literatura e nas características da região onde será empre-
gado o SGRH, tem-se evidências que os smartphones são a escolha ideal para desempenhar
o papel de um gateway móvel neste trabalho, uma vez que estão largamente disponíveis
para a população, são menos limitados que os dispositivos utilizados nos Nós e possuem
várias alternativas de conectividade.

4.2.4 Camada de Processamento
A Computação em Nuvem é a tecnologia primária desta camada. Este paradigma usado
em prol da IoT fornece um ambiente onde uma grande variedade de serviços de hardware
e software são construídos com base nos conceitos de escalabilidade e elasticidade, permi-
tindo que programadores de aplicações de IoT possam trabalhar com objetos heterogêneos
sem considerar uma plataforma específica, formando assim o conceito de plataforma de
mediação de dados para IoT, também referenciado como middleware.
Atualmente existe uma grande variedade de soluções de plataformas de mediação de
dados para IoT e selecionar qual a plataforma mais apropriada para uma necessidade
especifica não é e uma tarefa trivial. Assim, essa subseção pretende propor um guideline
para a seleção de uma plataforma de mediação de dados a ser usado na Camada de
Processamento em projetos de SGRH.

4.2.4.1 Plataformas de Mediação de Dados de IoT

Uma plataforma de mediação de dados de IoT tem como principal objetivo conectar
e unificar objetos e sistemas heterogêneos, permitindo a coleta e o processamento de
informações em larga escala (ATZORI; IERA; MORABITO, 2010).
Não há um consenso sobre as melhores plataformas de mediação de dados para IoT,
uma vez que cada plataforma tem seu foco e características específicos. 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 países no ano de 2016. Esse
projeto foi realizado em colaboração com 25 das maiores empresas de tecnologia do mundo.
A Figura 23 mostra o resultado desta pesquisa.
2
https://www.hackster.io/survey
Capítulo 4. Arquitetura Proposta 64

Figura 23 – Principais Plataformas IoT

Fonte: (AGUSTIN, 2017)

Os resultados revelaram que o grupo permanece dividido, porém 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 não
usar uma plataforma IoT e construir seu próprio banco de dados e aplicativo dentro de
seu próprio servidor de nuvem.

4.2.4.2 Revisão da Literatura de Plataformas de Mediação de Dados para IoT

Como visto acima, existem diversas plataformas de mediação de dados para IoT, assim
essa revisão da literatura tem por finalidade buscar insights para montar um guideline
para a seleção de uma plataforma a ser usada na Camada de Processamento em projetos
de SGRH. Para a realização desta revisão foram analisados trabalhos secundários sobre
plataformas de mediação de dados para IoT, uma vez que esses trabalhos catalogam,
analisam e comparam essas plataformas.
Os trabalhos secundários foram selecionados em busca automática e empregando a
técnica snowball. Para a busca automática foram usados os mesmos engenhos de busca
empregados na seção 3.2. A string de busca genérica 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 seleção dos trabalhos relevantes para essa revisão foi empre-
gada a técnica snowball nos artigos selecionados, chegando a um total de 7 trabalhos
Capítulo 4. Arquitetura Proposta 65

Tabela 3 – Trabalhos secundários sobre Plataformas IoT

Autor #Plataformas O que analisa
Levantamento das lacunas a
Mineraud et al. (2016) 37
serem preenchidas
Questões relacionadas ao modelo
Silva et al. (2015) 35
de dados utilizado
Visão geral sobre os middleware
Fersi (2015) Não cita
mais conhecidos
Suporte a múltiplos elementos
Mazhelis (2014) 12
de aplicação
Visão geral das soluções
Köhler et al. (2014) 6
disponíveis
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 análise. Vale ressaltar que esta revisão não se trata de uma Revisão Sistemática da
Literatura, logo não goza de todo o rigor desta metodologia.
A Tabela 3 relaciona os trabalhos secundários selecionados, apresentando os autores,
o ano da publicação, a quantidade de plataformas analisadas e o que o trabalho analisa
nessas plataformas.
Da análise desses trabalhos secundários, foram catalogados: (i) Os principais serviços
que devem ser fornecidos por uma Plataforma IoT; e (ii) As características desejáveis em
uma Plataforma de IoT. Esses serviços e características são apresentados nas tabelas 4 e
5, respectivamente, e suas descrições no Anexo C.

Tabela 4 – Serviços desejáveis em uma Plataforma de IoT

# Serviço
1 Serviços de Gerenciamento de Dispositivos
2 Serviços de Sensores
3 Serviços de Armazenamento
4 Serviços de Analytics
5 Visualização dos dados dos Sensores
Fonte: O Autor
Capítulo 4. Arquitetura Proposta 66

Tabela 5 – Características desejáveis em uma Plataforma de IoT

# Característica # Característica
1 Descoberta de recursos 2 Gerenciamento de recursos
3 Gestão de dados 4 Gerenciamento de Eventos
5 Gerenciamento de código 6 Escalabilidade
7 Tempo real ou oportunidade 8 Confiabilidade
9 Disponibilidade 10 Mobilidade
11 Segurança e privacidade 12 Provisão de Abstração
13 Facilidade de implantação 14 Popularidade
15 Abstração de Programação 16 Interoperável
17 Baseado em serviços 18 Adaptativo
19 Context-aware 20 Autônomo
21 Distribuído
Fonte: O Autor

4.2.4.3 Guideline para Seleção da Plataforma IoT

Esse guideline baseia-se na ESBE, onde a tomada de decisão fundamenta-se na análise de
estudos secundários.
As plataformas de mediação de dados em IoT, embora possam variar de acordo com os
seus objetivos, possuem um conjunto de requisitos essenciais para viabilizar a integração e
processamento de dados (ZHOU, 2012). Um compilado desses requisitos são apresentados
nas Tabelas 4 e 5.
Como visto, existem diversos trabalhos científicos voltados a pesquisar e comparar as
diversas Plataformas de IoT através de surveys e Revisões Sistemáticas 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 disponíveis; elencam suas
principais características; e comparam essas Plataformas sobre uma determinada ótica.
Este trabalho propõem a seguinte sequência para a seleção da Plataforma IoT a ser
usada na Camada de Processamento para um projeto de SGRH, mostrados na Figura 24.

Figura 24 – Guideline para seleção da Plataforma IoT

Fonte: o Autor
Capítulo 4. Arquitetura Proposta 67

Etapa 1. Selecionar os requisitos - Para selecionar os requisitos desejáveis para a
plataforma de mediação de dados, deve-se:
• Usar as Tabelas de Requisitos (4 e 5) e selecionar os requisitos desejados; E
• Adicionar requisitos específicos, não elencados na Tabela de Requisitos, com base
nos requisitos do sistema a ser construído. Por exemplo, suporte a linguagem de
programação específica, custo financeiro da plataforma, tipo de licença, etc.
• Confeccionar o documento de requisitos desejáveis.
Etapa 2. Selecionar a Revisão Sistemática - De posse do documento de requisitos
desejáveis, selecionar o trabalho secundário que melhor analisa os requisitos desejáveis:
• Realizar uma pesquisa nos engenhos de busca, científicos ou não, a procura de tra-
balhos secundários que melhor atendam às necessidades do pesquisador. Um ponto
de partida para essa busca pode ser a string de busca realizada para esta revisão da
literatura (subseção 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 secundário selecionado e do documento de requisitos desejáveis,
analisar o referido estudo secundário para selecionar qual a plataforma que melhor
atende aos requisitos do sistema IoT a ser implantado.
Não foram encontrados requisitos específicos em SGRH que diferenciem a Camada
de Processamento em relação a outros sistemas. Sendo assim, o emprego deste guideline
aplica-se normalmente para esses tipos de sistemas.

4.2.5 Resumo da Seção
Nesta seção foi definido o modelo de arquitetura IoT usado neste trabalho, sendo esse em
cinco camadas usando Computação em Nuvem como Camada de Processamento e tendo
um smartphone como gateway móvel. 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
Capítulo 4. Arquitetura Proposta 68

Na próxima seção serão apresentadas as camadas de software desta arquitetura, sendo
essas: Camada de Aplicação e Camada de Negócio, onde será analisada a AS empregada
neste trabalho.

4.3 Especificação da Arquitetura de Software
Baseado nas demandas e requisitos elicitados na seção 4.1, esta seção propõe uma AS
que disponibiliza serviços para orquestrar a distribuição de água no Semiárido brasileiro.
O foco da solução proposta consiste em atender a estes requisitos, bem como prover
mecanismos para que novos requisitos possam ser incluídos, de acordo com o contexto de
cada aplicação a ser desenvolvida com base nos serviços 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 intersecção dessas são as leis universais que se aplicam a todos os tipos de sistemas.
Essas leis universais são:
R: Todo sistema deve ter provisões que lhe permitam ser reutilizado em diferentes
contextos e por sistemas diferentes;
E: Todo sistema deve ter provisões que permitam que ele seja estendido para aco-
modar novos comportamentos;
A: Todo sistema deve ter provisões que lhe permita oferecer analytics para permitir
a medição e rastreamento de seu uso;
L: Todo sistema deve ter provisões que permitam que ele seja fracamente acoplado
para reduzir tanto as interdependências entre seus módulos/componentes, quanto
outros sistemas com os quais possivelmente interage;
FU: todo sistema, grande e pequeno, deve ter disposições que permitam que ele seja
mantido e atualizado, seja dentro ou fora do sistema propriamente dito;
CK: todo sistema, grande e pequeno, deve ter provisões que lhe permitam adquirir
e usar o conhecimento de contexto para decidir se está funcionando corretamente
ou não;
IN: todo sistema, grande e pequeno, deve ter provisões que lhe permita ser inde-
pendente de sua rede tanto quanto possível; na ausência da rede, os sistemas devem
degradar graciosamente a um nível de utilidade que se assemelhe a um sistema to-
talmente independente, pequeno e isolado;
G: em geral, para todos os tipos de sistemas, as preocupações de segurança 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.
Capítulo 4. Arquitetura Proposta 69

Outro fator importante para engenharia de software é quanto a segurança. Para Sêmola
(2003), o resultado de uma gestão de segurança da informação adequada deve oferecer
suporte a cinco pontos principais:
• Confidencialidade: somente as pessoas autorizadas terão acesso às informações;
• Integridade: as informações serão confiáveis e exatas. Pessoas não autorizadas não
podem alterar os dados;
• Disponibilidade: o acesso às informações sempre que for necessário por pessoas au-
torizadas;
• Autenticidade: garante que em um processo de comunicação os remetentes não se
passem por terceiros e nem que a mensagem sofra alterações durante o envio;
• Legalidade: garante que as informações foram produzidas respeitando a legislação
vigente.
Assim, para desenvolver a Arquitetura de Software, foram considerados esses três
aspectos: os requisitos elicitados, o PMES e a segurança da informação.
Nesta arquitetura, a Camada de Aplicação abrange os aplicativos e subsistemas usados
nas três camadas inferiores que se integram e oferecem serviços para a Camada de Negócio.
A Camada de Negócio é subdividida em duas partes: Camada de Negócio da Arquitetura
de Software (Camada de Negócio AS) e Sistemas Externos. A Figura 26 mostra as divisões
físicas e lógicas desta arquitetura.
Como se vê na Figura 26 (a), as camadas de Processamento, Aplicação e uma parte da
Camada de Negócio estão no mesmo ambiente (Plataforma IoT), enquanto as camadas de
Rede e Percepção estão nos ambientes Smartphone e Microcontrolador respectivamente.
Na Figura 26 (b) existe apenas uma divisão, entre as camadas de Aplicação e Negócio,
pelo motivo de a nível de software serem camadas diferentes.

Figura 26 – Divisões físicas e lógicas da Arquitetura de Software

Fonte: o Autor

Para descrever a Arquitetura de Software detalhadamente será utilizado o método
de descrição de AS baseado em visões, conhecido como “4+1” (The 4+1 View Model of
Architecture) proposto por Kruchten (1995). Segundo Kruchten (1995) a descrição de uma
Capítulo 4. Arquitetura Proposta 70

arquitetura pode ser organizada em torno de quatro pontos de vista: Lógica, Execução,
Implementação e Física, e em seguida, ilustrada por alguns casos de uso selecionados ou
cenários que se tornam um quinto ponto de vista.
Para esta descrição, serão apresentadas a Arquitetura de Software Proposta e uma
Implementação de Referência.
Arquitetura de Software Proposta - consiste da arquitetura de forma conceitual
e abstrata, independente de tecnologia, detalhada através das visões Lógicas, Execução,
e Cenários.
Implementação de Referência - consiste de uma implementação de referência da
Arquitetura Proposta, empregando tecnologias elicitadas na Especificação da Arquitetura
IoT. Esta arquitetura será detalhada usando as visões de Implementação e Física.

4.3.1 Arquitetura de Software Proposta
Antes de começar a detalhar a AS, vale a pena mostrar a sequência de atividades para a
realização da entrega de uma Carrada, empregando a arquitetura proposta, apresentada
na Figura 27. Essa sequência está detalhada na visão de caso de uso desta arquitetura.

Figura 27 – Atividades realizadas pela Arquitetura Proposta

Fonte: O Autor

4.3.1.1 Visão Lógica da Arquitetura de Software

Esta visão demonstra a organização da AS a partir do ponto de vista funcional. Nesta visão
os principais elementos, como subsistemas, módulos e a interface entre estes elementos
são especificados. A Figura 28 ilustra a arquitetura do ponto de vista lógico e abaixo são
descritos seus módulos.
Mediador de Dados (MD)
Este é o principal módulo da arquitetura, sendo responsável pela orquestração das
mensagens e armazenamento das principais entidades e dados do sistema. Esse módulo
encontra-se na Plataforma IoT e deve gozar das características de um ambiente de Com-
putação em Nuvem, como: elasticidade, ubiquidade, escalabilidade, acesso amplo via rede
Capítulo 4. Arquitetura Proposta 71

Figura 28 – Visão Lógica da AS proposta

Fonte: O Autor

e segurança. Para coordenar a comunicação, esse módulo deve implementar o PA Broker,
uma vez que esse padrão é usado para estruturar sistemas de software com componentes
distribuídos que interagem com chamadas de serviços remotos.
Os principais atores do módulo Mediador de Dados são:
• Produtor de Contexto - entidade (por exemplo, um Nó IoT) capaz de gerar
contexto;
• Consumidor de Contexto - entidade (por exemplo, uma aplicação baseada em
contexto) que explora informações de contexto.
Esse módulo representa o ponto de entrada para as aplicações e serviços externos da
Camada de Negócio, provendo mecanismos necessários para o acesso e a comunicação com
a AS e entre seus módulos. Todas as comunicações com este módulo devem ocorrer através
da API fornecida por ele. Com essas interfaces, pode-se fazer as seguintes operações:
• Registrar Produtor de Contexto;
• Atualizar contexto;
• Ser notificado quando da alteração de contexto ou com uma frequência determinada;
• Consultar contexto.
Um princípio fundamental deste módulo é a total dissociação entre os Produtores
e os Consumidores de Contexto. Desta forma um Consumidor não necessita saber qual
Produtor publicou um evento, assim como um Produtor não precisa conhecer qualquer
Consumidor. Como resultado, esse módulo é uma ponte que permite que aplicações ex-
ternas da Camada de Negócio gerenciem eventos de forma mais simples escondendo a
complexidade da coleta de recursos dos Nós.
Autenticador
Este módulo é o responsável pela criação do Token para autorização da comunicação
do Gateway (dispositivo de posse do Pipeiro) com o Nó (Cisterna do Beneficiário) e da
autenticação do Pacote de Recebimento gerado no Nó e transmitido pelo Gateway.
Capítulo 4. Arquitetura Proposta 72

O Módulo Autenticador encontra-se na Plataforma IoT, porém em uma máquina vir-
tual diferente do Mediador de Dados. Essa decisão arquitetural de manter esses dois mó-
dulos no mesmo ambiente se explica pela maior facilidade na gestão das Chaves Pública
e Privadas do Autenticador e dos Nós, facilitando a comunicação entre esses módulos.
Esses módulos se comunicam através da API disponibilizada pelo Mediador de Dados.
Para essa comunicação o módulo Autenticador deve ser registrado no módulo Mediador
de Dados de forma que quando uma atualização de contexto ocorra ele seja notificado.
Uma atualização de contexto nesse caso pode ser um pedido de geração de Token ou um
pedido de autenticação de Pacote de Recebimento.
Este módulo é o responsável direto pela autenticidade das informações trocadas entre
o Gateway, o Nó e o Mediador de Dados. Tendo em vista que os Nós não possuem
necessariamente acesso a Internet, a metodologia de Token proposta neste trabalho não
é a convencional, na qual os interessados possuem acesso à Internet, mas sim gerada a
partir da assinatura com Chave Privada e autenticação com Chave Pública, garantindo
assim a autenticidade de um pacote. A Figura 29 mostra o diagrama de sequência das
atividades de Gerar Token de Entrega e Autenticar um Pacote de Recebimento.

Figura 29 – Diagrama de sequência da atividade de Gerar Token de Entrega

Fonte: O Autor

Para a geração de um Token de Entrega o Módulo Mediador de Dados notifica o
Módulo Autenticador, passando um pacote com os dados da entrega a ser realizada.
Então o Módulo Autenticador assina esse pacote com sua Chave Privada. O Módulo
Autenticador então atualiza o contexto passando o Token para o Mediador de Dados.
Por outro lado, para a autenticação de um Pacote de Recebimento o Módulo Mediador
de Dados notifica o Módulo Autenticador, passando o Pacote de Recebimento (previa-
mente assinado com a Chave Privada do Nó). Módulo Autenticador autentica esse pacote
com a Chave Pública do Nó. O Módulo Autenticador então atualiza o contexto passando
o Pacote de Recebimento para o Mediador de Dados com o resultado da verificação.
Capítulo 4. Arquitetura Proposta 73

Gateway
A função principal deste módulo/subsistema é transferir o pacote de Entrega para o
Nó e transmitir o Pacote de Recebimento para o Mediador de Dados. Outra função de
responsabilidade do Gateway é monitorar o deslocamento a fim de armazenar o itinerário
realizado, a data-hora de passagem pelo Manancial estabelecido para o recebimento do
recurso hídrico e a localização do Nó onde houve a transmissão do Pacote de Entrega.
Esse módulo encontra-se de posse do Pipeiro e deve possuir tecnologia de geolocali-
zação integrada e um razoável poder de processamento e armazenamento. Outra carac-
terística que o Gateway deve possuir é acesso aos protocolos de comunicação 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
comunicação empregados nesta arquitetura. A comunicação deste módulo com os outros
subsistemas e módulos da arquitetura é da seguinte forma: via API entre o Gateway e o
Mediador de Dados; e via protocolo de comunicação interna entre o Gateway e o Nó.
A Figura 30 mostra o diagrama de sequência da atividade de realizar entrega de uma
Carrada, na esfera de responsabilidade do Gateway.

Figura 30 – Diagrama de sequência da atividade Realizar Entrega

Fonte: O Autor

Para realizar essa atividade, primeiramente o Gateway registra-se no Mediador de
Dados para poder receber notificação. Após 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. Então o Gateway recebe do Mediador de Dados a
notificação com o Token da entrega.
Neste momento o Gateway começa 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
Capítulo 4. Arquitetura Proposta 74

chegada e partida, gerando o Pacote de Entrega.
Ao chegar ao local previsto para entrega, o Gateway estabelece a comunicação com o
Nó. Após isso, o Gateway envia o Pacote de Entrega para o Nó. Após a entrega da água,
o Gateway então recebe o Pacote de Recebimento, gerado pelo Nó.
Após 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.

A principal função deste módulo/subsistema é validar o Pacote de Entrega e gerar
o Pacote de Recebimento. Também faz parte das atribuições deste módulo controlar os
sensores usados para medir o volume e a qualidade da água recebida.
Esse módulo encontra-se no microcontrolador, o qual é colocado fisicamente na cisterna
que irá receber o recurso hídrico. Esse subsistema armazena em sua memória obrigatori-
amente o identificador da cisterna, a Chave Privada do Nó e a Chave Pública do Módulo
Autenticador. A comunicação desse módulo se dá por protocolo de comunicação interna
com o módulo Gateway.
Devido a falta de comunicação com a Internet por parte do Nó, para garantir a auten-
ticidade do Pacote de Entrega, bem como do Pacote de Recebimento, é usada a técnica
de assinatura com Chave Privada e verificação com Chave Pública. A Figura 31 mostra
as atividades realizadas por esse módulo.

Figura 31 – Diagrama de sequência módulo Nó

Fonte: O Autor

Tudo começa com o estabelecimento da comunicação dos dispositivos Gateway e Nó.
Após isso o Nó recebe o pacote de Entrega. De posse do pacote, o Token então é verificado
com a Chave Pública do Autenticador para validar a autenticidade do Pacote.
Capítulo 4. Arquitetura Proposta 75

No próximo passo, o Nó inicia a medição do volume de água. Essa medição ocorre até
que o volume de água entregue seja igual ao previsto no Pacote de Entrega, ou que haja
uma interrupção por parte do Gateway. O Volume de água recebido fará parte do Pacote
de Recebimento. Após receber o volume de água o Nó faz a medição da pureza da água,
o qual também fará parte do Pacote de Recebimento.
Após medir a pureza da água, o Nó gera o Pacote de Recebimento, concatenando as
informações 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 módulo Gateway.
Camada de Negócio
A Camada de Negócio possui duas divisões: Camada de Negócio da Arquitetura de
Software e Sistemas Externos.
Camada de Negócio AS
Esse módulo encontra-se na Plataforma IoT e consiste apenas de um pacote que contém
classes de negócio e interfaces para os Casos de Usos: Manter Nós, Manter Plano de
Trabalho, Manter Manancial, Manter Pipeiro e Manter Carrada.
Esse pacote é utilizado pela Camada de Aplicação e pode ser reusado pelos Sistemas
Externos que utilizam os serviços fornecidos por esta arquitetura para implementar um
proxy a fim de facilitar a comunicação com o Módulo Mediador de Dados. A Figura 32
mostra o diagrama de classes resumido deste módulo.

Figura 32 – Diagrama de classes resumido Camada de Negócio AS

Fonte: O Autor

Sistemas Externos
São quaisquer sistemas externos que utilizem os serviços fornecidos pela Arquitetura
Proposta. Esses sistemas são implementados, hospedados e mantidos por terceiros, não
fazendo parte desta arquitetura.
A comunicação destes sistemas com a arquitetura proposta se dá através da API dis-
ponibilizada pelo Mediador de Dados. Esses sistemas podem reusar as classes e interfaces
contidas no pacote do Módulo Camada de Negócio AS para implementar um proxy para
auxiliar a utilização dessa API.
Capítulo 4. Arquitetura Proposta 76

Tabela 6 – Mapeamento dos componentes da AS em processos e threads

Módulo Processo Thread
1 inicial
Mediador de Dados 1 Principal + 1 por notificação
e 1 por requisição
1 inicial
Autenticador 1 Principal
+ 1 por requisição
1 principal
Gateway 1 Principal + 1 por operação de rede
+ 1 por operação de geolocalização
Nó 1 Principal 1 principal
Camada de Negócio Implementação externa Implementação externa
Fonte: O Autor

4.3.1.2 Visão de Execução da Arquitetura de Software

Esta visão apresenta o mapeamento dos componentes lógicos da AS em processos e threads
em tempo de execução, resumidos na Tabela 6.
Mediador de Dados
Este módulo é um processo multithread. o Mediador de Dados cria uma nova thread
para cada solicitação (consulta ou atualização) e para cada notificação de saída. Essas
threads são destruídas quando seu trabalho finaliza.
Autenticador
Este módulo também é formado por um processo multithread. Esse módulo é composto
por uma thread inicial para começar e gerenciar o processo e uma nova thread é criada
para cada requisição, uma vez que as requisições são gerenciadas de forma independente.
Gateway
Esse módulo é formado por um processo composto por uma thread principal e várias
outras threads. A thread principal gerencia todas as tarefas do subsistema. As outras
threads, são responsáveis pela execução das tarefas de monitoramento do deslocamento e
comunicação com o Mediador de Dados e com o 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 consideração as limitações do microcontrolador usado para imple-
mentar o Nó, deixando o processo o mais simples possível.
Capítulo 4. Arquitetura Proposta 77

Camada de Negócio
A Camada de Negócio AS não possui nenhum processo, por se tratar apenas de um
pacote de classes e interfaces a serem reusadas e implementadas. Os Sistemas Externos
não têm relação com essa arquitetura proposta no que concerne a Visão de Execução.

4.3.1.3 Visão 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 disponíveis para outros
sistemas. É importante salientar que apenas para as Atividades #1, #2 e #7 é necessário
acesso a comunicação externa (Internet), nas demais não há essa necessidade. Segue abaixo
a descrição 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 Negócio;
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 mudança 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 começa 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 comunicação com o Nó.
Atividade #4: Validação 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 pública do
Autenticador;
3. O Nó autoriza a entrega do recurso hídrico.
Atividade #5: Entrega da água
Capítulo 4. Arquitetura Proposta 78

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: Geração 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 validação da entrega da
Carrada;
3. O Mediador de Dados notifica o Autenticador da mudança de contexto;
4. O Autenticador valida a autenticidade do Pacote de Recebimento, abrindo o
pacote com a chave pública 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 Usuário. O Pipeiro é o ator que age
diretamente com o caso de uso Realizar Entrega que é o principal caso de uso do sistema.
Já o Usuário é 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 representação para uma
sequência de tarefas como deslocar-se para os locais (Manancial e Cisterna) e descarregar
o recurso hídrico na cisterna. O caso de uso Realizar Entrega usa todos os casos de uso
necessários para realizar essa atividade.

4.3.2 Implementação de Referência
Esta subseção consiste de uma implementação de referência da Arquitetura Proposta
(Arquitetura IoT e Arquitetura de Software Proposta). Para propósitos de testes e vali-
dações da Arquitetura Proposta, foi utilizada uma infraestrutura mínima de serviço do
FIWARE3 , um Arduino Uno e um smartphone Android 4 . A implementação de referência
desta Arquitetura de Software está disponível em um domínio público5 .
3
https://www.fiware.org
4
https://www.android.com/
5
https://github.com/wasufms/SGRH
Capítulo 4. Arquitetura Proposta 79

4.3.2.1 Plataforma IoT - FIWARE

A FIWARE é uma plataforma genérica e extensível para serviços da Internet do Futuro por
meio de um conjunto de especificações abertas, disponibilizadas por APIs e implementadas
em componentes denominados Generic Enablers (GEs) (BATISTA et al., 2016). Os campos
de atuação desta plataforma são bastante diversificados, indo desde agricultura, saúde,
energia, meio ambiente, transporte, segurança urbana e mídias sociais.
Segundo Batista et al. (2016), o desenvolvimento dos GEs objetiva compor o núcleo
da plataforma FIWARE e são componentes fundamentais para essa plataforma. As im-
plementações de cada GE são compostas por um conjunto de componentes, que juntos
suportam as funcionalidades fornecidas através de APIs, desta maneira provendo interfa-
ces interoperáveis de acordo com as especificações abertas definidas para cada GE.
A funcionalidade e especificação dos GEs fornecidas pelo FIWARE podem ser acessa-
das através de um catálogo público6 , de modo que se possa selecionar as APIs apropriadas
a serem usadas. Os GE estão 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 utilizáveis para vários domínios têm
proporcionado à FIWARE um grande e crescente uso a nível Internacional (BATISTA et
al., 2016). A nível de Brasil, a FIWARE vem sendo adotada em projetos que envolvem
seu uso em Smart City e IoT, por pesquisadores de algumas instituições acadêmicas.

4.3.2.2 Visão Física da Arquitetura de Software

As Tabelas 7, 8 e 9 mostram as configurações de hardware e software usados na imple-
mentação de referência. Logicamente, para a utilização em um ambiente real de produção
deve-se analisar as soluções de Plataforma de IoT oferecidas pelos provedores para obter
melhor desempenho da arquitetura proposta.

4.3.2.3 Visão de Implementação da Arquitetura de Software

Esta visão descreve as estratégias utilizadas para a implementação 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 padrão arquite-
tural Broker, implementado no Mediador de Dados. Esse decisão de projeto basea-se no
6
https://catalogue.fiware.org/
7
https://www.fi-ppp.eu/
Capítulo 4. Arquitetura Proposta 80

Tabela 7 – Visão 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
Memória RAM 2 GB
GPS A-GPS/GLONASS/BeiDou
Fonte: O Autor

Tabela 8 – Visão Fisica da AS - Nó

Arduino Uno
Microcontrolador ATmega328P
Memória Flash 32 KB (ATmega328P)
SRAM 2 KB (ATmega328P)
EEPROM 1KB (ATmega328P)
Velocidade de Clock 16 MHz
Sensor Ultrasônico HC-SR04
Módulo Bluetooth HC-05
Fonte: O Autor

fato deste PA ser idealizado para sistemas distribuídos, que é o caso desta arquitetura
proposta.
O módulo Mediador de Dados usa o Orion Context Broker, que é uma implementação
do FIWARE para o PA Broker, implementado com o Padrão de Design Publish/Subscribe,
fornecendo uma API RESTful para troca de informações de contexto. Para implementar
a API RESTful este módulo usa as interfaces NGSI-9 e NGSI-10, empregando a notação
JSON8 .
Este módulo utiliza como banco de dado para armazenar as informações de contexto
e os dados do sistema o banco NoSQL MongoDB, que é um banco de dados baseado
em arquivo sem transações e sem junções. As informações de Contexto e os dados são
representadas através de estruturas de dados genéricas denominadas ContextElement. Um
Elemento de Contexto refere-se a informações que são produzidas, coletadas ou observadas
8
http://www.json.org/json-pt.html
Capítulo 4. Arquitetura Proposta 81

Tabela 9 – Visão Fisica da AS - Plataforma IoT

FIWARE
Mediador de Dados
Hardware 4096 MB RAM , 2 VCPU, 40GB Disk
Sistema Operacional Linux Red Hat versão 4.4.7
Orion Context Broker Versão 1.3.0
MongoDB Versão 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 Versão 8
Camada de Negócio
Configurações idênticas ao Autenticador
Fonte: O Autor

que podem ser relevantes para processamento, análises e extração de conhecimento. Um
ContextElement normalmente fornece informações de uma determinada entidade, sendo
ela uma coisa física ou parte de uma aplicação. 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 implementação de
sistemas de chaves assimétricas, sendo atualmente o mais utilizado entre os algoritmos
assimétricos (GUSTAVO et al., 2012). Porém, em testes de implementação, esse algoritmo
consumiu toda a memória 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 elípticas projetado para ser mais
rápido do que os esquemas de assinatura digital existentes, sem sacrificar a segurança.
Capítulo 4. Arquitetura Proposta 82

Desta forma, este módulo implementa o algoritmo de assinatura digital EdDSA para
realizar a encriptação e decriptação dos pacotes, usados como assinatura e verificação
respectivamente, utilizando a linguagem de programação Java.
A troca de mensagem com o Mediador de Dados é realizada usando a notação JSON
utilizando a biblioteca fornecida pelo Google Inc. conhecida como GSON9 .
Gateway
A implementação deste módulo/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 aplicações-chave. A troca de
mensagem com o Mediador de Dados é realizada também usando a notação JSON com
a biblioteca GSON. E semelhante ao módulo Autenticador, esse módulo também reusa o
pacote da Camada de Negócio para as classes de entidade.

Esse módulo/subsistema é implementado de forma estruturada na linguagem de pro-
gramação C. Possui uma função principal que controla o fluxo do programa e repete-se
continuamente permitindo que o sistema funcione dinamicamente.
A implementação da atividade de verificar a autenticidade do Token e gerar o Pacote
de Recebimento é realizada com a utilização da biblioteca Ed25519 do Arduinolibs10 . Essa
biblioteca é uma implementação na linguagem C do algoritmo EdDSA.
Camada de Negócio
A Camada de Negócio 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 três componentes. O Modelo contém a funcio-
nalidade principal e os dados. As Visões exibem informações ao usuário, enquanto que os
Controladores lidam com as entradas do usuário (BUSCHMANN et al., 1996).
Isso não 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 através da interface REST usando a notação JSON.

4.3.3 Validação da Arquitetura de Software
Esta subseção 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. Não é propósito desta subseção avaliar a
Arquitetura de Software quanto a esses aspectos, isso fica por conta do próximo capítulo.
9
https://sites.google.com/site/gson/gson-user-guide
10
https://github.com/rweather/arduinolibs/tree/master/libraries/Crypto
Capítulo 4. Arquitetura Proposta 83

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 não descumprir, esse conjunto de lei. Essa subseção mostra
como a AS proposta se relaciona com as leis que regem esse mandamento. A avaliação de
quanto a AS obedece a essas leis é realizada na avaliação da arquitetura proposta.
R - Ser reutilizado por diferentes sistemas: Esse é um dos principais objetivos da
AS proposta, fornecer serviços para diferentes sistemas. Com os dados e informações
sendo disponibilizados como serviços web, diferentes sistemas podem utilizar os dados
disponibilizados pela AS proposta. Outra forma de ser reutilizado é o uso da Arquitetura
Proposta em outros domínios, como por exemplo, na distribuição 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 módulo Camada de Negócio AS.
A - Oferecer Analytics: No momento, a Arquitetura não cumpre diretamente essa lei,
porém 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 módulos e subsistemas só se comunicam por mensagem,
além de estarem em ambientes e/ou máquinas virtuais separadas. O que contribui também
com o cumprimento dessa lei é a total dissociação entre os Produtores de Contexto e os
Consumidores onde um não precisa ter conhecimento do outro.
FU - Permitir ser mantido e atualizado: A separação em módulo e subsistemas auxilia
o cumprimento desta lei. Outra decisão arquitetural que corrobora com essa lei é empregar
protocolos, padrões e algoritmos bem definidos e abertos como REST, NGSI, JSON e
MVC na implementação 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 são válidas ou não.
IN - Ser, na medida do possível, independente de rede: O sistema necessita de rede
para funcionar, uma vez que é um sistema distribuído, porém é projetado para mesmo
sem rede cumprir sua tarefa de forma independente e isolado, completando-a assim que
obtiver acesso a rede.
G - Preocupações de segurança e integridade equilibrada com a usabilidade: É um
dos principais requisitos do sistema, sendo trabalhado fortemente na autenticidade das
mensagens trocadas entre os módulos através da assinatura digital, com o mínimo de
interação humana.
11
https://catalogue.fiware.org/enablers/complex-event-processing-cep-proactive-technology-online
Capítulo 4. Arquitetura Proposta 84

Tabela 10 – Mapeamento de Requisitos X Módulos

Requisito MD Autenticador Gateway Nó Negócio
Mínima interação do usuário R C C R
Interoperabilidade R C C C
Eficiência Energética C R
Ubiquidade/Mobilidade C R
Segurança C R C R C
Geolocalização R
Disponibilidade R R C C C
Flexibilidade/Extensibilidade R R
Baixo custo C C C R
Adequação modelos atuais C C C C R
Fonte: O Autor

4.3.3.2 Requisitos Elicitados versus Módulos da Arquitetura de Software

A Tabela 10 lista o módulo da arquitetura proposta que: [C] Contribui para o atendimento
de um requisito; e [R] Responsável direto para que o requisito seja contemplado ou que
afeta diretamente esse requisito.
Como nota-se, mais de um módulo pode ser o responsável pelo atendimento do requi-
sito, bem como um certo módulo pode não contribuir com esse requisito.

4.3.4 Resumo da Seção
Nesta seção foi especificada a Arquitetura de Software da arquitetura proposta neste
trabalho, sendo detalhadas a Arquitetura de Software Proposta e a Implementação de
Referência desta arquitetura. Para isso, foram apresentadas as Camada de Aplicação e
Camada de Negócio através da metodologia 4+1. Também foi apresentado uma validação
da Arquitetura de Software com o PMES e com os requisitos elicitados, relacionando-a
com esses aspectos.

4.4 Considerações Finais do Capítulo
Neste capítulo foram apresentados um conjunto de requisitos fundamentais a serem aten-
didos na implementação e implantação de uma arquitetura para SGRH no contexto deste
trabalho. Após essa definição 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 próximo capítulo essa arquitetura será avaliada por especialistas em diversas áreas
relacionada com este trabalho, a fim de validar a arquitetura proposta.
85

5 Avaliação da Arquitetura Proposta

A avaliação da arquitetura de software é um meio poderoso para tomar decisões sobre
sistemas, avaliar e mitigar riscos e identificar formas de melhoria e migração de sistemas
de software. A avaliação da arquitetura atinge esses objetivos ao prever as propriedades
dos sistemas antes de serem construídos 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 avaliação da arquitetura de software é fornecer meios eficazes para de-
terminar características 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 avaliações de AS, concluíram que a avaliação
de AS pode ser um instrumento extremamente útil para apoiar a tomada de decisão de
arquitetura e orientar o alinhamento estratégico de negócios e tecnologias em um sistema.
Sendo assim, podemos concluir que tão importante quanto definir a arquitetura de
um sistema é realizar uma avaliação do que foi definido, com o objetivo de identificar as
possíveis falhas antes que se tornem grandes problemas no futuro.
Este capítulo visa avaliar a Arquitetura Proposta neste trabalho. Para tal, na seção
5.1 serão apresentados dois métodos de avaliação de AS amplamente aceitos e validados
na literatura. Posteriormente, na seção 5.2, será discutido o protocolo adotado para a
avaliação desta AS. Na seção 5.3 é apresentada como foi a execução da avaliação propri-
amente dita. Em seguida, a seção 5.4 discute alguns resultados e comentários a respeito
das principais questões que surgiram durante a avaliação desta AS. Além disso, a seção
5.5 discute as principais ameaças à validade da avaliação.

5.1 Métodos de Avaliação
Várias abordagens diferentes têm sido propostas para avaliar arquiteturas de software, tais
como baseadas na experiência, baseada em cenários, modelagem matemática e baseada
em simulação. Entre essas abordagens, as baseadas em cenários estão bastante maduras
e experimentadas (PATIDAR; SUMAN, 2015).
Cenário é uma breve descrição de algum uso antecipado ou desejado do sistema. Es-
sas descrições são formuladas em termos de qualidades, como por exemplo: "como essa
arquitetura é modificável?", a fim de responder a seguinte questão: "como essa arquitetura
acomodará a seguinte mudança?" (KAZMAN et al., 1996).
A literatura apresenta vários métodos de avaliação, com diferentes objetivos e con-
textos de execução, isto pode ser constatado em Patidar e Suman (2015). Para filtrar
Capítulo 5. Avaliação da Arquitetura Proposta 86

esse conjunto de métodos, a condição utilizada neste trabalho levou em consideração os
Atributos de Qualidade (QA), acrônimo do inglês Quality Attribute, que o método visa
avaliar, como modificabilidade, segurança e as leis fundamentas da engenharia de software
descritas em Meira et al. (2016).
Analisando o trabalho realizado por Patidar e Suman (2015), dois métodos candidatos
a serem utilizados foram selecionados: SAAM (KAZMAN et al., 1994) e ATAM (KAZMAN
et al., 2000). SAAM é o método pioneiro de avaliação de arquitetura, este método é a base
de todos os métodos de avaliação. O ATAM é um refinamento do SAAM, sendo ATAM
o padrão de fato para avaliações de arquitetura (KNODEL; NAAB, 2014). Outro fator que
levou a essa seleção foi que, segundo Patidar e Suman (2015), dentre os vários métodos
apenas SAAM e ATAM estão sendo aplicados na indústria.

5.1.1 SAAM
SAAM (Software Architecture Analysis Method) é um método de avaliação simples que
pode ser adaptado a diferentes contextos. Foi originalmente desenvolvido para permitir
a comparação de soluções arquiteturais concorrentes, analisando principalmente os QA
modificabilidade e funcionalidade.
Método bastante estabelecido, SAAM é amplamente utilizado nos demais QA, tais
como portabilidade, extensibilidade e integrabilidade. Este método tem sido aplicado em
vários estudos de caso, incluindo sistema de informação global, ambiente de desenvol-
vimento de interface de usuário, sistemas Web e sistema de áudio embutido (KNODEL;
NAAB, 2014).
Este método inclui 6 atividades: desenvolvimento dos cenários; descrição da AS avali-
ada; classificação e priorização dos cenários; avaliação dos cenários individual e indireta;
interação entre os cenários; e avaliação global dos cenários (KAZMAN et al., 1994).
As principais vantagens da utilização do SAAM são a melhoria na documentação da
AS e a identificação de riscos cedo no ciclo de vida do software (KAZMAN et al., 1994).

5.1.2 ATAM
ATAM (Architecture Tradeoff Analysis Method) é um método baseado em cenários, re-
finado do SAAM, porém, mais complexo que este. A aplicação do ATAM revela quão
bem uma AS satisfaz aos requisitos de qualidade desejados, além de identificar os riscos
arquiteturais e os conflitos (trade-offs) existentes para se alcançar tais requisitos.
O ATAM é um método que ajuda as partes interessadas a entender as consequências
das decisões arquitetônicas em relação aos requisitos de atributo de qualidade do sistema
(BASS; NORD, 2012). Algumas aplicações do método ATAM são: sistemas de sensor de
temperatura remoto e Battlefield Control System (PATIDAR; SUMAN, 2015).
Capítulo 5. Avaliação da Arquitetura Proposta 87

O ATAM inclui 4 atividades principais: (i) Descrição: apresentação do ATAM, dos ob-
jetivos de negócios e da AS; (ii) Investigação e Análise: geração dos atributos de qualidade
utilizando utility tree; análise das abordagens arquiteturais; brainstorm e priorização dos
cenários; (iii) Testes: Análise da AS proposta; (iv) Apresentação dos Resultados (KAZMAN
et al., 2000).
Segundo Kazman et al. (2000), os principais objetivos da ATAM são: Elicitar e refinar
os requisitos de atributos de qualidade da AS; Elicitar e refinar uma declaração precisa
das decisões de projeto arquitetural; e Avaliar as decisões de projeto arquiteturais para
determinar se satisfazem convenientemente os requisitos de qualidade.

5.2 Protocolo da Avaliação
Para a escolha do processo de avaliação a ser usado foram analisados os principais métodos
oferecidos na literatura. De todos os métodos SAAM e ATAM eram os que melhor aten-
diam aos propósitos desta avaliação. Porém, nenhum dos dois, isoladamente, atendiam
completamente às necessidades e peculiaridade deste projeto, sendo necessário uma adap-
tação desses métodos, assim como propôs Tomas (2014). Desta forma, para a realização
da avaliação foi seguido o protocolo descrito abaixo.

5.2.1 Definição do Método de Avaliação
O método aplicado para avaliar esta arquitetura basea-se na metodologia proposta por
Tomas (2014), que consiste basicamente em combinar os métodos de avaliação SAAM e
ATAM. A escolha deste método para avaliação deste trabalho fundamenta-se na neces-
sidade de características contidas nos dois métodos de avaliação, 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 quão a arquitetura está apta para ser empregada.
Por outro lado, os atributos de qualidades avaliados pelo método ATAM está mais de
acordo com o propósito desta dissertação, avaliar múltiplos QA. Por fim, ainda segundo
Patidar e Suman (2015), uma das aplicações para o método ATAM é avaliar sistema de
sensor de temperatura remoto, o que está no contexto desta dissertação.

Tabela 11 – Características dos métodos SAAM e ATAM

SAAM ATAM
Objetivo Aptidão da Arquitetura trade-off
Atributos de Qualidade Modificabilidade Múltiplos
Aplicação do Método Sistemas de áudio incorporado Sensores temp. remoto
Fonte: Adaptado de (PATIDAR; SUMAN, 2015)
Capítulo 5. Avaliação da Arquitetura Proposta 88

Tabela 12 – Etapas do método de avaliação

# Etapa
1ª Apresentação do Processo de avaliação
2ª Apresentação dos Objetivos de Negócios
3ª Apresentação da Arquitetura Proposta
4ª Priorização dos Atributos de Qualidade
5ª Contextualização sobre cenários
6ª Apresentação dos cenários
7ª Priorização dos cenários
8ª Avaliação dos cenários propostos
9ª Avaliação das interações entre cenários e QA
10ª Consolidação dos Resultados
Fonte: O Autor

Um dos motivos que também levaram à necessidade de realizar uma adaptação dos
métodos de avaliação é o fato de a AS proposta ser regida pelo PMES. Assim, os QA e
os cenários devem avaliar o quão a AS proposta está adequada às leis universais descritas
em Meira et al. (2016).
Outro fator é que para a definição do método de avaliação a ser empregado foi levado
em consideração a necessidade de se avaliar a Arquitetura Proposta como um todo, não
apenas a AS, mas também a Arquitetura IoT descrita na seção 4.2.
Assim, esta avaliação é baseada no SAAM e ATAM, como propôs Tomas (2014),
porém com atividades adequadas à avaliação 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 método adaptado.

5.2.2 Equipe de Avaliação
Seguindo recomendação da ATAM, os avaliadores escolhidos para participar da equipe
são de diferentes áreas de pesquisa, com diferentes experiências e visões. 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
distribuição de água no Semiárido brasileiro). Vale ressaltar que um mesmo avaliador
pode ter mais de uma expertise. A Tabela 13 ilustra as expertises dos envolvidos.
Capítulo 5. Avaliação da Arquitetura Proposta 89

Tabela 13 – Expertise da Equipe de Avaliação

Expertise Doutor Mestre Especialista
Engenheiros de Sistemas 1
Computação em Nuvem 1 1
Internet das Coisas 2
Arquiteturas Escaláveis 1
Engenheiro em Telecomunicações 1
Engenheiro de Software 4
Segurança da Informação 1 3
Especialistas em Negócios 3
Fonte: O Autor

5.3 Execução da Avaliação
Seguindo o protocolo do processo de avaliação, definido na seção 5.2, o processo foi exe-
cutado dividindo as etapas em 3 reuniões, descritas na Tabela 14.

5.3.1 Primeira Reunião
O objetivo da primeira reunião foi apresentar o processo de avaliação, os objetivos de
negócios da Arquitetura Proposta e contextualizar os avaliadores no processo de avaliação.
As etapas da reunião foram as seguintes:
1. Apresentação do Processo de Avaliação (Duração 30 min): Inicialmente,
foram descritos os dois principais métodos de avaliação de AS, ressaltando as principais
diferenças entre eles. Posteriormente foram apresentadas as peculiaridades deste trabalho.
Consequentemente, o processo de avaliação a ser utilizado foi descrito. O objetivo desta

Tabela 14 – Execução da avaliação

1. Apresentação do Processo de Avaliação
2. Apresentação dos Objetivos de Negócios
Primeira Reunião 3. Apresentação da Arquitetura Proposta
4. Priorização dos Atributos de Qualidade
5. Contextualização sobre Cenários
6. Apresentação dos Cenários
Segunda Reunião 7. Priorização dos Cenários
8. Avaliação dos Cenários propostos
9. Avaliação das interações entre cenários e QA
Terceira Reunião
10. Consolidação dos Resultados
Fonte: O Autor
Capítulo 5. Avaliação da Arquitetura Proposta 90

etapa foi situar os avaliadores em relação ao objetivo do processo e aos próximos passos.
2. Objetivos de Negócios (Duração 30 min): A segunda etapa da reunião teve a
intenção de definir e apresentar os objetivos de negócios da Arquitetura Proposta, para isso
foi convidado um avaliador especialista no negócio para realizar uma rápida explanação.
Este passo foi importante para que os participantes da avaliação entendessem o contexto
do sistema e também as limitações técnicas existentes para a execução do projeto. Todos
esses aspectos foram apresentados para ajudar na definição dos cenários e priorização dos
QA a serem considerados no processo de avaliação.
3. Apresentação da Arquitetura Proposta (Duração 60 min): Seguindo uma
recomendação relatada em Tomas (2014), essa apresentação da arquitetura não foi total-
mente detalhada nesta fase, pois aquele autor relatou em seu trabalho que esta apresen-
tação poderia ser uma ameaça a validade do método. O autor do trabalho aqui proposto
também acredita que essa apresentação detalhada pode ser um viés para a elicitação dos
cenários.
Assim, neste passo foi apresentada para os avaliadores a Arquitetura Proposta, através
de um software totalmente funcional realizando o fluxo principal do caso de uso Realizar
entrega de uma Carrada. Esta apresentação foi de suma importância para que os avali-
adores percebessem se os requisitos funcionais foram implementados e avaliar se de fato
satisfazem as necessidades do negócio.
4. Priorização dos Atributos de Qualidade (Duração 45 min): Como os par-
ticipantes não estavam acostumados ao conceito de Atributos de Qualidade, inicialmente
foi descrito o que são e quais os objetivos dos mesmos.
Um pré-requisito de uma avaliação é ter uma clara declaração 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 votação para priorizar quais atributos melhor expressam
os objetivos de negócios, apresentados anteriormente. Nesta votação, cada participante
pode usar 3 votos entre os QA. A soma destes votos representa a prioridade atribuída
pelos avaliadores. A Tabela 15 exibe o resultado desta votação ordenado por prioridade.
5. Contextualização sobre Cenários (Duração 15 min): O último passo dessa
primeira reunião, foi a contextualização sobre cenários. Da mesma forma como os atributos
de qualidade, inicialmente foi realizada uma apresentação sobre o que são e quais as
necessidades dos cenários. Em seguida, alguns cenários foram exemplificados, como “Qual
o impacto na arquitetura para disponibilizar um novo tipo de dado” e “A AS deve permitir
suporte a serviços em Cloud Computing já existentes”.
Por fim, uma planilha online1 foi compartilhada com os avaliadores para que eles
pudessem propor cenários de utilização da Arquitetura Proposta com base nos objetivos
de negócios. Um prazo de 4 dias foi estipulado para essa atividade.
1
https://github.com/wasufms/SGRH/blob/master/Proposta_Cenarios.pdf
Capítulo 5. Avaliação da Arquitetura Proposta 91

Tabela 15 – Atributos de Qualidade ordenados por prioridade

Fonte
Atributo de Qualidade # Votos
Característica ISO/IEC 25010
Equilíbrio Segurança, Meira et al. (2016)
5
integridade e usabilidade Segurança e Usabilidade
ISO/IEC 25010
Confiabilidade Maturidade, Disponibilidade, 5
Tolerância a falhas, Recuperabilidade
Permitir ser manutenido Meira et al. (2016)
4
e atualizado Manutenibilidade - Modificabilidade
Ser, na medida do possível, Meira et al. (2016)
4
independente de rede -
ISO/IEC 25010
Desempenho/eficiência Tempo-comportamento, 4
Utilização de recursos, Capacidade
ISO/IEC 25010
Aprendizagem, Operabilidade,
Usabilidade 3
Proteção contra erros de usuário,
Interface do usuário, Estética, 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, Substituição
Ser estendido para acomodar Meira et al. (2016)
1
novos comportamentos Manutenibilidade-Modificabilidade
ISO/IEC 25010
Funcionalidade 1
Integridade, Correção, Adequação
Usar conhecimento Meira et al. (2016)
0
de contexto -
Meira et al. (2016)
Oferecer Analytics 0
Manutenibilidade -Analisabilidade
ISO/IEC 25010
Compatibilidade 0
Coexistência, Interoperabilidade
Fonte: O Autor
Capítulo 5. Avaliação da Arquitetura Proposta 92

5.3.2 Segunda Reunião
A Segunda Reunião foi marcada uma semana depois da primeira. Como uma preliminar,
em 15 minutos foram relembradas as etapas anteriores da avaliação, os objetivos de negócio
e Arquitetura Proposta. Esta reunião seguiu as seguintes etapas:
Detalhamento da AS Proposta (Duração 30 min): Embora fora da metodolo-
gia proposta inicialmente, essa etapa foi realizada nesta fase a fim de mitigar um possível
víeis nas etapas anteriores de priorização de QA e elicitação dos cenários. Nesta etapa a
Arquitetura Proposta foi detalhada pelo arquiteto através de uma visão de módulos. Para
tal, foi utilizada a metodologia de descrição de AS "4+1".
6. Apresentação dos Cenários (Duração 60 min): Nesta etapa foram discuti-
dos todos os cenários propostos, onde alguns tiveram que ser reescritos para um melhor
entendimento de todos os avaliadores. Para que esses cenários pudessem realmente ser
útil à avaliação foi necessário considerar os cenários mais aplicáveis, coerentes e factíveis
na Arquitetura Proposta. Desta maneira, alguns cenários, quando de consenso geral, fo-
ram reescritos ou excluídos. Como exemplo, tem-se o seguinte cenário: É extremamente
importante desenvolver uma interface amigável ao usuário, tendo em vista que o público
alvo do produto são pessoas com baixo conhecimento tecnológico. Apesar de importante e
relevante, os avaliadores acreditaram que esse não era um cenário útil à avaliação.
7. Priorização dos Cenários (Duração 30 min): Nesta fase os cenários elici-
tados foram discutidos novamente e um peso de relevância foi atribuído para cada um
deles. Para isso foi realizada uma votação para priorizar os cenários, considerando os mais
aplicáveis, coerentes e factíveis. Nesta votação cada participante pode usar 3 votos entre
os cenários, onde a soma representa a prioridade atribuída pelos avaliadores.
8. Avaliação dos Cenários propostos (Duração 15 min): Para essa etapa
um formulário online2 foi compartilhado com os avaliadores para que esses avaliassem
o quão os cenários elicitados condizem com a natureza da Arquitetura Proposta. Para
essa avaliação foram estipulados 4 dias para os avaliadores. Os cenários resultantes são
exibidos na Tabela 16, ordenados de acordo com a priorização.

5.3.3 Terceira Reunião
Da mesma forma que a segunda reunião, a terceira e última reunião foi marcada uma
semana depois. O objetivo primordial dessa reunião foi consolidar os resultados e definir
as possíveis ações a serem tomadas para aprimorar a proposta.
9. Avaliação das interações entre Cenários e Atributos de Qualidade (Du-
ração 60 min): Nesta primeira etapa da reunião, os avaliadores discutiram o quão os
cenários priorizados conflitavam com os atributos de qualidade.
2
https://github.com/wasufms/SGRH/blob/master/Avaliacao_Cenarios.pdf
Capítulo 5. Avaliação da Arquitetura Proposta 93

Tabela 16 – Cenários propostos para avaliação da AS

Id Cenário
C1 Fornecer segurança aos dados transmitido e recebidos pelos dispositivos e nuvem
C2 A AS deve permitir escalabilidade sob demanda de serviço
C3 Consumir pouca largura de banda da rede devido a qualidade das redes móveis
C4 A AS deve ter Tolerância a falhas
C5 Permitir a comunicação entre dispositivos heterogêneos. (Ex. celular, Arduino)
C6 Resiliência a falha de comunicação com a Cloud (outras formas de comunicação SMS)
C7 A AS deve permitir a comunicação via API
C8 A AS deve permitir Suporte a serviços em Cloud Computing já existentes
C9 A aplicação embarcada no hardware das cisternas deve consumir poucos recursos
C10 Permitir a priorização de determinadas localidades na fila de requisições de assinaturas
C11 Permitir a flexibilização do tamanho do token de certificação
C12 Permitir a substituição do hardware Arduino pelo raspberry pi, visando desempenho
C13 A AS deve ser construída com tecnologias open source
C14 Suportar a modificação do MD no caso da identificação de vulnerabilidades
C15 Comunicação entre o Nó e o MD deve ser mínima e independente de conexão
C16 Aplicação em Cloud deve usar Containers para reduzir o custo do uso de VM
C17 Permitir (implementar) um protocolo de comunicação entre o Gateway e o No
C18 Permitir o Armazenamento dos dados para análise futura
C19 Permitir que se possa fazer mais de uma reserva por vez
C20 Permitir Inteoperbilidade oferecendo um protocolo de comunicação comum e aberto
C21 Permitir possível unificação do Autenticador e Mediador de Dados em uma mesma VM
C22 A AS deve conter uma forma de comunicação contingente entre o Gateway e o Nó
C23 Assegurar que a replicação das msg criptografadas não causem impacto sobre o sistema
C24 Suportar armazenamento do tipo Object Storage para baratear o custo Plataforma IoT
Fonte: O Autor

10. Consolidação dos Resultados (Duração 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 priorização dos Atri-
butos de Qualidade e os Cenários elicitados. Depois estes artefatos e resultados foram
discutidos e analisados pelo arquiteto e avaliadores.

5.4 Resultados da Avaliação da Arquitetura
Conforme descrito na seção anterior, para mensurar quantitativamente o quão a Arqui-
tetura Proposta contempla cada cenário, foi criado um formulário online com todos os
cenários, ordenados por prioridade. Neste formulário, cada participante deveria atribuir
Capítulo 5. Avaliação da Arquitetura Proposta 94

uma nota de 0 a 5 para a adequação de cada cenário, onde 5 representa que a AS ATENDE
TOTALMENTE e 0 que NÃO ATENDE ao cenário em questão. Outra forma de avaliar
é: caso a AS não contemple o cenário, qual o impacto na arquitetura para que tal cenário
seja contemplado. Assim, 5 representa que NÃO HÁ IMPACTO NA AS e 0 que a O IM-
PACTO É TÃO GRANDE QUE A AS NÃO TEM CONDIÇÕES DE IMPLEMENTAR
TAL CENÁRIO.
Apartir deste formulário, foram obtidas algumas conclusões, que serão apresentadas
nas próximas subseções.

5.4.1 Resultados da Avaliação dos Cenários
Cada participante respondeu o formulário online independentemente. A partir disso, fo-
ram consolidadas todas as respostas anonimamente. A Figura 34 ilustra a média e o
desvio padrão das respostas, além de 4 faixas de satisfatoriedade, definidas pelos próprios
participantes da avaliação.

Figura 34 – Resultado da avaliação dos cenários

Fonte: o Autor

Como é possível notar, na opinião dos participantes, a Arquitetura Proposta atende
79% dos cenários de maneira Excelente. Essa boa avaliação se dá principalmente devido
ao fato de muitos cenários estarem relacionados com características ofertadas pela Com-
putação em Nuvem, que é o uma das bases deste trabalho.
Vale aqui ressaltar que esta arquitetura em si não implementa nenhum das caracte-
rísticas essenciais da Computação em Nuvem, como por exemplo elasticidade ou amplo
acesso a rede, porém a arquitetura é desenhada de forma que o seu módulo principal
esteja em uma Plataforma de mediação de dados IoT que deve fornecer todos os serviços
de Computação em Nuvem.
Outro fator que contribui com essa avaliação otimista é devido a muitos cenários esta-
rem relacionados a segurança, que é outro fator diretamente relacionado a este trabalho.
Capítulo 5. Avaliação da Arquitetura Proposta 95

Os cenários melhores avaliados foram: C7 - A AS deve permitir a comunicação via
API, C9 - A aplicação embarcada no hardware das cisternas (Nó) deve consumir poucos
recursos e C13 - A AS deve ser construída com tecnologias open source. A excelente
avaliação destes cenários se dá principalmente por serem cenários que fazem parte dos
requisitos elicitados no início do projeto ou terem sido observados durante a realização da
implementação de referência, sendo assim contemplados na arquitetura.
O único cenário avaliado como Satisfatório foi C22 - A AS deve conter uma forma de
comunicação contingente entre o Gateway e o Nó. Esse resultado já era esperado devido
ao fato de a Arquitetura Proposta não prevê nenhuma forma de comunicação contingente
caso a comunicação interna do Nó deixe de funcionar por algum motivo. Esse cenário
também é o que apresentou maior desvio padrão, isso se deve ao fato de que muitos
avaliadores acreditam que esse problema pode ser resolvido colocando-se dois módulos de
comunicação no Nó.
Os cenários piores avaliados, C6 - Resiliência a falha de comunicação com a Cloud
(outras formas de comunicação SMS), C10 - Permitir a priorização de determinadas
localidades na fila de requisições de assinaturas e C22 - A AS deve conter uma forma de
comunicação contingente entre o Gateway e o Nó, são os que apresentam maior desvio
padrão. Uma possível relação é o fato dos avaliadores serem oriundos de diversas áreas,
assim algum stakeholder pode não compreender corretamente a questão, acreditando que
um determinado cenário é de difícil implementação, enquanto que um especialista na
área avalia que é um cenário contemplado ou facilmente implementável na Arquitetura
Proposta.

5.4.2 Resultados Gerais
Esta subseção visa elencar os resultados gerais obtidos a partir do processo de avaliação
executado. Estes resultados foram extraídos a partir das discussões com os participantes
e não necessariamente são observados nos artefatos do processo.
Durante o processo de avaliação foi realizada a etapa de Avaliação das interações
entre Cenários 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 também que apesar de alguns QA, como Usar conhecimento de
contexto; Oferecer Analytics e Compatibilidade, não serem contemplados na Arquitetura
Propostas, para os avaliadores, esses QA não 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 possível, independente de rede; e Equilíbrio Segurança, integridade e usabilidade.
O primeiro foi contemplado devido ao Gateway móvel, o qual depois de ter recebido o
Token da entrega não necessita mais de rede para funcionar, e o segundo devido à técnica
implementada de usar Token através de assinatura digital entre os módulos.
Capítulo 5. Avaliação da Arquitetura Proposta 96

Por fim, duas questões foram relatados pelos avaliadores no que tange à solução 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 técnica que permite ao usuário fraudar a sua localização.
Quanto ao problema de backup, no momento, esse pode ser considerado como uma questão
aberta na Arquitetura Proposta que deve ser melhor trabalhada. Referente à Location
Spoof existem diversas técnicas que devem ser implementadas a nível de programação
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 Exército Brasileiro.

5.5 Ameaças à Validade
No tocante à avaliação da arquitetura previamente descrita, foram identificadas ameaças
à validade que não afetam diretamente o resultado final desta avaliação. No entanto, é
interessante discuti-las como forma de subsidiar a tomada de decisões corretas no que se
refere à realização de eventuais trabalhos futuros que possam compartilhar aspectos com
a presente pesquisa.

5.5.1 Alto Desvio Padrão
Uma das ameaças identificadas está relacionada à heterogeneidade de expertises dos ava-
liadores. Apesar da utilização de uma equipe multidisciplinar ser recomendada pelas téc-
nicas de avaliação ATAM e SAAM, observou-se, da análise dos resultados da avaliação
dos cenários, que alguns stakeholders não compreenderam totalmente algumas questões,
provavelmente, em virtude da falta de conhecimento técnico na área específica. Em de-
corrência disso, registrou-se um considerável desvio padrão das notas atribuídas a alguns
aspectos em suas respectivas avaliações.
Acredita-se que a melhor forma de se mitigar esta ameaça seja a realização do agrupa-
mento das questões por áreas de conhecimento. Desta forma, todos os avaliadores conti-
nuariam analisando todos os cenários. Todavia, seriam atribuídos pesos distintos à luz das
expertises individuais. Por exemplo, as respostas do grupo de avaliadores especialistas na
área de Segurança da Informação teriam um peso maior do que os atribuídos às respostas
de outros grupos na avaliação de questões referentes ao tema "Segurança da Informação".
3
Um script funcional para Android encontra-se na implementação de referência desta arquitetura
Capítulo 5. Avaliação da Arquitetura Proposta 97

5.5.2 Relacionamento Interpessoal
Outro aspecto que poderia, supostamente, ameaçar a validade de uma pesquisa que utiliza
técnicas de avaliação como forma de validação é a possibilidade de haver, por parte dos
avaliadores, leniência ou severidade excessiva em relação à avaliação dos cenários. Tal
situação poderia ser motivada por diversos fatores, dentre os quais poderiam-se destacar
a possibilidade de existirem laços interpessoais entre o arquiteto e os avaliadores ou, até
mesmo, a existência de interesses político-econômicos associados à aprovação ou ao veto
da pesquisa em questão.
No intuito de se mitigar a possibilidade da existência de algum viés de cunho pessoal e,
ao mesmo tempo, sem limitar o critério de seleção a pessoas que não possuíssem nenhum
vínculo - nem mesmo profissional - com o pesquisador, o que, em virtude da especificidade
do tema poderia implicar a inclusão de indivíduos despidos de qualquer familiaridade com
o problema que se deseja solucionar, buscou-se realizar a composição da equipe priorizando
a escolha de avaliadores cujas reputações possuíssem relevância perante a comunidade
científica ou, que possuíssem, pelo menos, uma bagagem profissional considerável na área
em que atuam, de modo a conferir maior credibilidade à avaliação efetuada pelos mesmos.
Além disso, com o objetivo de evitar que a avaliação fosse motivada por questões
político-econômicas associadas ao tema da pesquisa, optou-se por selecionar profissionais
de diferentes organizações. Desse modo, seria possível detectar, se fosse o caso, possíveis
padrões de decisão associados a interesses específicos.

5.5.3 Possível Avaliação de uma Implementação Específica
Outra ameaça a validade da avaliação realizada é a possível avaliação de uma implemen-
tação específica, ao invés de ser avaliada a Arquitetura Proposta. Isso pode ocorrer devido
a dificuldade de se avaliar a Arquitetura Proposta por ser uma arquitetura abstrata.
A avaliação apoiada em uma implementação de referência é uma prática permitida
na avaliação baseada em cenários, uma vez que uma implementação de referência contri-
bui com a avaliação dos cenários elicitados e posteriormente dos QA (PATIDAR; SUMAN,
2015; KAZMAN et al., 1998). Assim, a avaliação da Arquitetura Proposta com o auxílio de
uma implementação de referência é uma boa prática, porém essa avaliação não pode ser
confundida com a avaliação de um Software ou de uma implementação específica.
Este trabalho tenta evitar/mitigar esta ameaça avaliando cenários referentes à Arqui-
tetura Proposta e não a uma implementação específica. Cenários como: "É extremamente
importante desenvolver uma interface amigável ao usuário, tendo em vista que o público
alvo do produto são pessoas com baixo conhecimento tecnológico" e "O material do sensor
precisa ser apropriado para Região (corrosão, chuva)", que estavam visivelmente ligados a
uma implementação específica, quando de consenso dos avaliadores, foram excluídos desta
avaliação.
Capítulo 5. Avaliação da Arquitetura Proposta 98

Nesta avaliação, embora muitos cenários possam ser avaliados apenas pela descrição
da Arquitetura Proposta, caso não fosse apresentada uma implementação de referência, a
apreciação da adequação dos cenários à Arquitetura Proposta poderia ser comprometida.
A implementação de referência desta arquitetura apoia a avaliação de muitos dos cenários
elicitados neste trabalho, como por exemplo: "C3 - Consumir pouca largura de banda da
rede devido a qualidade das redes móveis" e "C20 - Permitir Inteoperbilidade oferecendo
um protocolo de comunicação comum e aberto", porém, sempre com o cuidado de manter
os cenários mais genéricos possíveis, mas preservando a autonomia dos avaliadores.

5.6 Considerações Finais do Capítulo
Este capítulo teve como finalidade realizar a avaliação da arquitetura proposta neste
trabalho, iniciando com a apresentação da importância e a necessidade de se avaliar
uma AS. Logo depois, foram discutidos os possíveis métodos de avaliação de AS a serem
utilizados e definido o protocolo adotado para a avaliação desta arquitetura. Neste capítulo
também foi descrita a execução da avaliação e em seguida apresentados seus resultados.
Por fim, foram apresentadas algumas ameaças à validade desta avaliação.
A partir da avaliação realizada, pôde-se mensurar o quão a arquitetura está apta
para ser implantada em um contexto real. Assim, o próximo capítulo finaliza o trabalho
descrevendo as principais conclusões e as atividades futuras.
99

6 Considerações Finais

Este trabalho apresentou uma proposta de arquitetura baseada em Internet das Coisas e
Computação em Nuvem que disponibiliza serviços para orquestrar a distribuição de água
no Semiárido brasileiro.
O Presente capítulo tem por objetivo apresentar as conclusões da pesquisa descrita
nesta dissertação, apresentando os resultados, os principais trabalhos relacionados e por
fim, algumas sugestões para trabalhos futuros.

6.1 Visão Geral da Solução Proposta
A solução proposta provê meios para a realização da seguinte sequência de atividades:
seleção da carrada a ser entregue; geração do Token que autoriza e valida a entrega
de água; monitoramento do deslocamento do Pipeiro; validação da autorização para a
entrega da água; medição do volume e qualidade da água entregue; assinatura digital
para confirmação da água recebida; e entrega do Pacote de Recebimento para a nuvem
disponibilizando esses dados como um serviço.
A Arquitetura Proposta é regida pelo Primeiro Mandamento da Engenharia de Soft-
ware de Meira et al. (2016) e consiste de módulos que implementam as cinco camadas de
sistemas IoT, a saber:
• Camada de Percepção: Módulo Nó
Encontra-se na cisterna do Beneficiário. Sua principal função é assinar e validar os
pacotes, bem como controlar os sensores usados para medir o volume e a pureza da
água recebida.
• Camada de Rede: Módulo Gateway
Encontra-se no smartphone do Pipeiro. A função principal deste módulo é realizar a
comunicação entre o Nó e o Mediador de Dados, servindo como um gateway móvel.
• Camada de Processamento: Plataforma de mediação de dados IoT
Deve gozar das características de um ambiente de Computação em Nuvem como
elasticidade, umbiquidade, escalabilidade, acesso amplo via rede e segurança.
• Camada de Aplicação: Mediador de Dados e Módulo Autenticador
Mediador de Dados: Principal módulo do sistema, sendo uma implementação do
PA Broker. Encontra-se na Plataforma IoT e é o responsável pela orquestração das
mensagens trocadas com a AS, atualização do contexto da aplicação e armazena-
mento dos dados.
Autenticador: Encontra-se na Plataforma IoT e é responsável pela criação do Token
para autorização da comunicação do Gateway com o Nó e verificação do Pacote de
Recebimento.
Capítulo 6. Considerações Finais 100

• Camada de Negócio: Camada de Negócio AS e Sistemas Externos
Camada de Negócio AS: Encontra-se na Plataforma IoT e consiste de um pacote
que contém classes de negócio e interfaces que podem ser reutilizadas por sistemas
externos.
Sistemas Externos: Quaisquer sistemas externos que utilizem os serviços fornecidos
pela Arquitetura Proposta.

6.2 Trabalhos Relacionados
Robles et al. (2014) revisaram várias soluções baseadas em IoT relacionados com a estra-
tégia de gestão inteligente de água. Neste trabalho eles listam várias iniciativas, porém,
não fazem qualquer comparação entre as diversas abordagens ou tecnologias envolvidas.
Por outro lado, nesta dissertação foram feitas diversas comparações neste sentido no MSL.
Esta dissertação mapeou diversos trabalhos de gestão de recursos hídricos baseados em
IoT, apresentados no Anexo A. Apenas para citar algumas iniciativas: Kudva et al. (2014)
propõem um sistema de monitoramento de nível de água em tempo real em um campus,
usando um sensor ultrassônico comercial. Mais tarde Prachet et al. (2015) constroem um
sistema baseado em IoT para gerenciamento da distribuição de água em um campus,
porém a pesquisa foca em construir um sensor de nível de água de baixo custo e uma
rede de sensores para interligar o campus; Perumal, Nasir e Leong (2015) propõem um
sistema de monitoramento de nível de água em tempo real baseado em IoT, esta aplicação
foi estendida para gestão dos recursos hídricos sob condições climáticas críticas por Fang
et al. (2014); Pang et al. (2015) concentram-se em uma mini-estação de água inteligente
baseada na tecnologia de comunicação sem fios e sistema embutido; Shaohong e Shen
(2015) propõem um sistema integrado baseado na IoT para monitoramento e gestão de
recursos hídricos em tempo-real.
Em todos os trabalhos levantados no MSL os Nós possuem acesso à Internet, diferen-
temente desta dissertação, sendo esse um grande diferencial deste trabalho em relação a
todos os outros.
O Grupo Tragsa é constituído pela Empresa de Transformación Agraria S.A. (Tragsa1 ),
fundada para a execução de obras e serviços de desenvolvimento rural, conservação am-
biental e operações de socorro de emergência na Espanha.
A Tragsa mantém o projeto MEGA2 que é um modelo de como uma iniciativa específica
para a Espanha, pode ser expandida para níveis europeus e internacionais. O MEGA
se propõe a desenhar uma aplicação padrão integrando tecnologias de IoT, a qual as
companhias de gestão de água devem seguir. A diferença básica é que esta dissertação
propõe uma arquitetura mais genérica, com opções de técnicas e tecnologias, enquanto
1
http://www.tragsa.es/en/
2
http://www.gestiondelagua.es/en/
Capítulo 6. Considerações Finais 101

o MEGA fornece um modelo padrão, engessado, para as companhias de gestão de água,
não oferecendo alternativas de tecnologias ou serviços que possam ser usados.
Brandão, Summer e Farias (2016) em um trabalho acadêmico propõem uma aplicação
móvel 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 diário destas atividades.
Para o georreferenciamento a aplicação é utilizada pelos Pipeiros durante a atividade
de coleta de água nos Mananciais e entrega nos PAbst, de tal forma que a aplicação seja
capaz de ler cartões de QRCode de controle nestes pontos, verificar o georreferenciamento,
armazenar tais informações localmente no dispositivo, enviando-as quando o aparelho tiver
sinal da operadora de telefonia ou estiver conectado a Internet. Já para o agendamento
automático do processo de entrega de água, os autores desenvolveram um modelo de
previsão de consumo de água a partir dos dados fornecidos pela equipe do GCDA, sendo
a regressão linear simples a técnica estatística escolhida pela equipe para consecução desse
objetivo.
Este trabalho tem algumas semelhanças com o trabalho proposto nesta disserta-
ção, como por exemplo o uso de georreferenciamento e a utilização da rede celular do
smartphone do Pipeiro. Porém, diferentemente desta dissertação, este trabalho não for-
nece serviços para terceiros, constituindo assim apenas uma evolução do GCDA. Outro
problema do trabalho proposto por Brandão, Summer e Farias (2016) é que ele não apre-
senta resultados nem qualquer tipo de avaliação quanto a seu trabalho.

6.3 Contribuições da Pesquisa
Como resultado do trabalho apresentado nesta dissertação, as seguintes contribuições
podem ser destacadas:
• Estado da arte de SGRH: A partir da revisão da literatura executada foi possível
apresentar um resumo a respeito do estado da arte de SGRH que utilizam IoT
como ferramenta de apoio, bem como uma análise do modelo de distribuição de
água empregado no Brasil e da utilização 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 análise das
soluções existentes e de estudos secundários. Estes requisitos foram elicitados para
o cenário específico da distribuição de água no semiárido brasileiro, porém, devido
a sua generalização, esses requisitos podem servir como base para a especificação e
implementação de outros SGRH.
• Especificação, implementação e avaliação de uma arquitetura para monitoramento
da distribuição de água: Foi especificada, implementada e avaliada uma arquitetura
que visa atender aos principais requisitos de um sistema para monitoramento da
Capítulo 6. Considerações Finais 102

distribuição de água no semiárido brasileiro que combina conceitos de IoT e Com-
putação em Nuvem. A Arquitetura Proposta, com algumas adaptações, pode ser
empregada ou servir de base em outros domínios de distribuição de líquidos.
• Implementação de referência: Baseado na proposta desta dissertação, uma imple-
mentação de referência foi realizada e disponibilizado em domínio público3 . Esta
implementação serve de guia para a utilização desta proposta, onde pesquisadores
e profissionais podem basear-se para desenvolver e aplicar as técnicas idealizadas e
implementas neste trabalho, como por exemplo:
– Emprego de gateway móvel: Emprego de um gateway móvel para possibilitar
a comunicação entre dois módulos onde um desses não tem acesso a Inter-
net, concebendo uma solução de gateway móvel baseada em smartphone para
interoperabilidade IoT em SGRH.
– Adaptação do emprego de assinatura digital: adaptação do emprego de Token
para autenticação de mensagens quando os receptores e transmissores não têm
contato entre si, através da técnica de assinatura digital e gateway móvel.
• Validação da adaptação de dois métodos de avaliação de AS: Tomas (2014) propôs
uma adaptação de dois métodos de avaliação de AS, a qual foi empregada nesta
avaliação. Como contribuição, esta dissertação pôde comprovar sua utilidade tam-
bém para avaliar uma arquitetura de sistema, não apenas software. Este trabalho
contribuiu ainda elicitando e tratando algumas ameaças à validade quando da uti-
lização do método empregado por Tomas (2014) e também propôs uma melhoria
para futuro emprego deste método de avaliação de Arquitetura de Software.

6.4 Trabalhos Futuros
Além deste trabalho apresentar as contribuições citadas na seção 6.3, outras perspectivas
são possíveis. Diante disso, a seguir são listadas algumas direções para trabalhos futuros
desta pesquisa:
• Comunicação em tempo-real: Projetar e especificar meios para que seja possível
a comunicação em tempo-real com os Nós, a fim de visualizar o nível de água em
tempo-real, o que pode prover meios de predizer a real necessidade de cada cisterna;
• Mecanismo de tolerância a falhas: Melhorias na estratégia de redundância de-
vem ser implementadas para que os serviços não sejam afetados devido a uma even-
tual falha em algum ponto da arquitetura, principalmente no Gateway e no Nó;
• Utilização em ambiente real: A proposta atual deverá ser implantada em um
ambiente real a partir de parceria com o Exército Brasileiro. Certamente essa etapa
vai contribuir com o aperfeiçoamento da Arquitetura Proposta, possibilitando ava-
liar outros atributos como performance e usabilidade;
3
https://github.com/wasufms/SGRH
Capítulo 6. Considerações Finais 103

• Avaliação dos resultados: A partir de sua implementação em ambiente de pro-
dução será possível avaliar e mensurar os ganhos reais da utilização da Arquitetura
Proposta para a Operação Carro-Pipa e por consequência para o Programa Emer-
gencial de Distribuição de Água.

6.5 Possibilidade de Utilização da Arquitetura em Outros Domínios
Esta Arquitetura Proposta, com algumas adaptações, pode ser empregada em outros
domínios, não apenas na distribuição de água no semiárido brasileiro. Ela pode ser em-
pregada, por exemplo, para: (i) distribuição de combustíveis líquidos, (ii) transporte e
armazenamento de leite e (iii) distribuição de água em outras partes do mundo.
(i) Distribuição de combustíveis líquidos
A distribuição de combustíveis líquidos automotivos (gasolina, álcool hidratado e óleo
diesel) no Brasil segue um modelo logístico bastante tradicional. Há três tipos de fluxos
existentes na distribuição de combustíveis: fluxos primários (das refinarias e usinas de
álcool para as bases de distribuição), fluxos de transferência (entre bases) e fluxos de
entrega (das bases para os clientes). O modal rodoviário está presente na distribuição de
combustíveis em 31% das transferências e em 100% da entrega (FIGUEIREDO, 2015).
Os crimes relacionados ao transporte de combustíveis líquidos trazem enormes pre-
juízos para o mercado, já que o combustível desviado alimenta diversas irregularidades e
gera concorrência desleal (GUIDONI, 2014). Constantemente a imprensa brasileira reporta
relatos de roubo, furto e desvio de combustível, como por exemplo em esquemas onde os
motoristas não realizam a entrega completa prevista 4 . Por isso, é essencial que se invista
em tecnologias para monitorar tanto os veículos quanto a carga transportada e entregue,
minimizando os danos causados por esses desvios (GUIDONI, 2014).
A Portaria ANP nº 248, de 2000, dispõe sobre o controle de qualidade do combustível
automotivo líquido, estabelecendo algumas obrigações ao revendedor, tais como: coleta
e análise de amostra de cada compartimento do caminhão; manutenção do registro das
análises dos últimos seis meses; e realização de análise sempre que solicitado.
Como se vê, os problemas enfrentados pela atividade de distribuição de combustíveis
líquidos no Brasil são bastante semelhantes a problemática tema desta dissertação, o que
indica um possível domínio de emprego da arquitetura proposta neste trabalho.
(ii) Transporte e armazenamento de leite cru
A produção leiteira no Brasil tem crescido nos últimos tempos, colocando o país entre
os maiores produtores e consumidores do mundo. Entre as condições essenciais para a
atividade leiteira estão o transporte e o armazenamento (SANTOS; SILVA, 2015).
4
http://www.diariodoscampos.com.br/policia/2011/02/policia-rodoviaria-flagra-desvio-de-
combustivel/1024319/
Capítulo 6. Considerações Finais 104

Devido a episódios de fraude, o setor leiteiro vem buscando se profissionalizar quanto ao
transporte, porém, ainda existem muitos desafios (RODRIGUES, 2015). Rodrigues (2015)
evidenciou algumas tecnologias que ainda não se tem neste setor no Brasil, mas que po-
deriam contribuir com toda a cadeia de transporte. A ideia seria instalar os equipamentos
nos caminhões tanques de modo a proporcionar a rastreabilidade completa do leite. Com
eles, seria possível medir o volume do leite, a temperatura, tirar um amostra para testes
e fornecer o horário e o local onde está se realizando a coleta do leite, tudo de forma
automática e sem contato físico com o transportador (RODRIGUES, 2015).
Muitas destas necessidades podem ser supridas usando as ideias chaves da arquitetura
proposta nesta dissertação, adaptando os sensores usados e as localizações dos Nós.
(iii) Distribuição de água em outras partes do mundo
Relatórios da Organização Mundial da Saúde repetem o diagnóstico que mais de 1
bilhão de pessoas, 18% da população mundial, não têm acesso a uma quantidade mínima
aceitável de água potável, e que dois terços da população do planeta em 2025 poderão
não ter acesso à água limpa (JMP, 2016).
O abastecimento de água urbana na Índia enfrenta sérios desafios, incluindo a inefi-
ciência da distribuição, devido a limitação de recursos e a ausência de tecnologia para
manter e monitorar o processo (ANJANA et al., 2015). Segundo Rahman et al. (2016), este
cenário é semelhante na maioria dos países em desenvolvimento. Assim, seguindo o mo-
delo adotado no Brasil ou realizando algumas adaptações, quanto a sensores e legislação,
acredita-se que esta Arquitetura Proposta pode ser empregada para apoiar a distribuição
de água em diferentes partes do mundo.

6.6 Conclusão
Hoje em dia, um dos grandes problemas enfrentados pela humanidade é o de gerir a
escassez de água. Na região Semiárida brasileira a falta de água faz com que a população
carente fique submetida a condições de extrema dificuldade. A fim de mitigar essa situação,
no ano de 2016 foram gastos mais de 1 bilhão de Reais em programas de distribuição de
água, dos quais cerca de 14% desse recurso foi gasto em fiscalização. Frequentes notícias
de fraudes comprovam que essa fiscalização mostra-se de certa forma ineficiente.
Neste sentido, esta dissertação apresentou uma arquitetura que usa a integração de tec-
nologias de IoT e Computação em Nuvem para implementar uma Arquitetura de Software
que disponibilize serviços para orquestrar a distribuição de água no Semiárido brasileiro.
Conforme as avaliações discutidas no capítulo 5, é possível concluir que todos os obje-
tivos, tanto o geral quantos os específicos, foram atingidos, comprovando a hipótese deste
trabalho: É possível especificar, projetar e implementar uma arquitetura baseada em In-
ternet das Coisas e Computação em Nuvem que disponibilize serviços para orquestrar a
distribuição de água no Semiárido brasileiro.
105

Referências

AGRAWAL, H. Elliptic curve cryptography using Koblitz encoding method. v. 3, p.
418–422, 2013.
AGUSTIN, P. Top IoT Platforms for Makers. 2017. Disponível 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. 72–75, 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. 1–1, 2015.
ANJANA, S.; SAHANA, M. N.; ANKITH, S.; NATARAJAN, K. An IoT based
6LoWPAN enabled Experiment for Water Management. p. 1–6, 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. 487–497, 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. 277–281, 2012.
BATISTA, T.; W; W; W; W. SmartMetropolis - Plataformas e Aplicações para Cidades
Inteligentes. Universidade Federal do Rio Grande do Norte - Instituto Metrópole 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. 13–16, 2012. Disponível 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. Disponível 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. 27–9, 2014.
BRANDãO, O.; SUMMER, H.; FARIAS, G. Georreferenciando a Operação Pipa com
um sistema móvel 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.
Referências 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. 757–762, 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. 383–388, 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. 1–19, 2016. Disponível 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. 1596–1605, 2014.
FERSI, G. A Distributed and Flexible Architecture for Internet of Things. Procedia
Computer Science, Elsevier Masson SAS, v. 73, p. 130–137, 2015. Disponível em:
<http://dx.doi.org/10.1016/j.procs.2015.12.058>.
FIGUEIREDO, R. Gargalos logísticos na distribuição de combustíveis 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. 6–12, 2012.
GCDA. Sistema de Gestão e Controle de Distribuição de Água. Acesso: maio/2017.
2017. Disponível 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. Gestão 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. 1–16, 2012.
JMP. Progress on Drinking Water and Sanitation. 2016. Disponível 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. 113–123,
2002.
Referências 107

KAZMAN, R.; ABOWD, G.; BASS, L.; CLEMENTS, P. Scenario-based analysis of
software architecture. IEEE Software, v. 13, n. 6, p. 1–14, 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. 81–90, 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. 68–78, 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. 17–19, 2012.
KITCHENHAM, B. Evidence-basedsoftware engineering. 26th International Conference
on Software Engineering, p. 113–123, 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. 115–124, 2014.
KÖHLER, M.; WÖRNER, 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. 261–266, 2015.
KORTUEM, G.; KAWSAR, F.; FITTON, D.; SUNDRAMOORTHY, V. Smart objects
as building blocks for the internet of things. IEEE Internet Computing, p. 44–51, 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. 42–50, 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. 139–145, 2014. Disponível em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6975454>.
Referências 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. 204–214, 2016.

LOPES, F. C. O uso da Tecnologia de Geoinformação no planejamento das ações de
fiscalização do Programa de Distribuição Emergencial de Água no semiárido brasileiro:
um estudo de caso no âmbito do Comando Militar do Nordeste. 2016.

MAFRA, S.; RAFAEL, F.; TRAVASSOS. Aplicando uma Metodologia Baseada em
Evidência na Definição de Novas Tecnologias de Software. XX Simpósio Brasileiro de
Engenharia de Software, p. 239–254, 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. 1–8,
2007. Disponível 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. 68–90, 2015. Disponível 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.
147–152, 2014.

MEIRA, S.; BURÉGIO, V.; BORBA, P.; GARCIA, V.; ALBUQUERQUE,
J.; SOARES, S. Programming the Universe. Proceedings of the 30th Brazilian
Symposium on Software Engineering - SBES 16, p. 153–156, 2016. Disponível em:
<http://dl.acm.org/citation.cfm?doid=2973839.2982567>.

MEIRELLES, S. F. 27ª Pesquisa Anual do Uso de TI. 2016. Disponível 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. Disponível 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. 20–22, 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. 5–16, 2016.
Disponível em: <http://dx.doi.org/10.1016/j.comcom.2016.03.015>.
Referências 109

PADILHA, J. A.; ZANGHETIN, M. F. L.; ORTEGA, E.; ORTEGA, E. O uso da água
nas microbacias hidrográficas do semiárido do nordeste brasileiro e o conceito base zero.
In: . [S.l.]: Proceedings of IV Biennial International Workshop Advances in Energy
Studies., 2004. p. 65–72.

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. 1–3, 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. 1162–1167, 2013. Disponível em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6682215>.

PASSADOR, J. L.; CLAUDIA, S. Apontamentos sobre as políticas públicas de combate
à seca no Brasil: cisternas e cidadania? Cadernos Gestão Pública e Cidadania, v. 15,
n. 56, p. 65–86, 2010.

PATIDAR, A.; SUMAN, U. A survey on software architecture evaluation methods.
2015 2nd International Conference on Computing for Sustainable Global Development
(INDIACom), p. 967–972, 2015.

PEREIRA, C.; AGUIAR, A. Towards efficient mobile M2M communications: survey and
open challenges. Sensors (Basel, Switzerland), v. 14, n. 10, p. 19582–19608, 2014.

PERUMAL, T.; NASIR, S.; LEONG, C. Y. Internet of Things ( IoT ) Enabled Water
Monitoring System. p. 86–87, 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. 374–380, 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. 821–826, 2014.

RODRIGUES, R. M. C. Transporte de leite no Brasil: avanços, desafios e tendências.
2015. Disponível em: <https://www.milkpoint.com.br/industria/cadeia-do-leite/
giro-de-noticias/transporte-de-leite-no-brasil-avancos-desafios-e-tendencias-97640n.
aspx>.
Referências 110

SANCHEZ, L. Smartsantander: the meeting point between future internet research and
experimentation and the smart cities. FUTURE NETWORK & MOBILE SUMMIT
(FUTURENETW), p. 1–8, 2011.

SANTOS, D. F.; SILVA, T. D. Logística interna de armazenagem e transporte do leite
de pequenos produtores rurais de Silveirânia: o caso da Associação APRUS. 2015.

SÊMOLA, M. Gestão Da Segurança Da Informação. ELSEVIER EDITORA, 2003.
Disponível 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. 133–144, 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. 365–368, 2015. Disponível em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=7334989>.

SIAFI. Sistema Integrado de Administração Financeira do Governo Federal. 2017.
Disponível 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 Mediação de Dados para Internet das Coisas.
42o SEMISH - Seminário 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. 513–518, 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. 1–8, 2014. Disponível 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. 53–62, 2002.

TELECOM. Brasil Telecom. 2016. Disponível 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. 261–274, 2015.

WILEY. Systematic Requirements Engineering - From System Goals to UML Models to
Software Specifications. [S.l.: s.n.], 2008.
Referências 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. 60–68, 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. Disponível 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. 35–40, 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. 40–46, 2010.
Apêndices
113

APÊNDICE A – Artigos Selecionados MSL

Id Título 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
APÊNDICE 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

APÊNDICE B – Tabela de Avaliação das
Tecnologias de Comunicação para SGRH

Figura 35 – Avaliação das Tecnologias de Comunicação para SGRH

Fonte: o Autor
116

APÊNDICE C – Descrição dos Serviços e
Características Desejáveis em uma Plataforma
de IoT

(i). Serviços desejáveis em uma Plataforma de IoT
a. Serviços de Gerenciamento de Dispositivos: registrar sensores e dispositivos de gateway, identificá-los e
endereçá-los, entre outras tarefas de gerenciamento.
b. Serviços de Sensores: registrar sensores na plataforma e criar meta-dados. Os Serviços de Sensores precisam
escalar facilmente à medida que o número de sensores e precisam ter a capacidade de lidar com uma grande variedade
de sensores.
c. Serviços de Armazenamento: armazenar dados de aplicativos de forma contínua em banco de dados relacional
e não relacional, NoSQL e arquivos Blob.
d. Serviços de Analytics: fornecer a infraestrutura para executar análises em lotes e em tempo real nas observa-
ções dos sensores. Inclui mineração de dados, agregações e correlações, detecção de padrões, processamento baseado
em regras, entre outros.
e. Visualização dos dados dos Sensores: fornecer ferramentas e APIs necessárias para criar visualização rica
dos dados capturados dos sensores, bem como dados processados resultantes de análise.
(ii). Características desejáveis em uma Plataforma de IoT
Descoberta de recursos: deve permitir a descoberta de recursos de forma automatizado. Mecanismos de desco-
berta também precisam escalar bem, e deve haver uma distribuição eficiente da carga de descoberta.
Gerenciamento de recursos: é importante que os aplicativos sejam fornecidos com um serviço que os gerencie.
Isso significa que o uso de recursos deve ser monitorado, os recursos sejam provisionados de maneira justa.
Gestão de dados: em IoT, os dados referem-se a informações detectadas pelos sensores. Uma plataforma de dados
IoT precisa fornecer serviços de gerenciamento de dados para aplicativos, incluindo aquisição, processamento e
armazenamento.
Gerenciamento de Eventos: deve transformar eventos observados simples em eventos significativos, de forma
que as aplicações sejam orientadas a informações precisas, em tempo real e inteligentes.
Gerenciamento de código: a implantação de código em um ambiente IoT deve ser diretamente suportada pela
plataforma de mediação de dados.
Escalabilidade: uma plataforma de mediação de dados de IoT precisa ser escalável para acomodar o crescimento
na rede e aplicações/serviços de IoT.
Tempo real ou oportunidade: uma plataforma de mediação de dados deve fornecer serviços em tempo real
quando a correção de uma operação dependa não apenas da sua correção lógica, mas também do tempo em que é
executada.
Confiabilidade: uma plataforma de mediação de dados deve permanecer operacional durante a duração de uma
tarefa, mesmo na presença de falhas. Cada componente ou serviço precisa ser confiável para obter confiabilidade
geral do sistema.
Disponibilidade: uma plataforma de mediação de dados deve estar disponível em todos os momentos. Os requisitos
de confiabilidade e disponibilidade devem trabalhar juntos para garantir a maior tolerância a falhas.
Mobilidade: cada dispositivo em IoT deve ser capaz de anunciar sua existência e os recursos que ele fornece sem
a necessidade de uma infraestrutura fixa, devido à alta distribuição e mobilidade dos dispositivos IoT.
Segurança e privacidade: em uma plataforma de mediação de dados de IoT a segurança precisa ser considerada
em todos os blocos funcionais e não funcionais, incluindo o aplicativo de nível de usuário e infraestrutura da
plataforma.
Provisão de Abstração: uma plataforma de mediação de dados deve fornecer abstrações em vários níveis, tais
como dispositivos heterogêneos de hardware, interfaces de hardware e software, fluxos de dados e processo de
desenvolvimento.
Facilidade de implantação: uma vez que uma plataforma de mediação de dados de IoT ou atualizações desta
plataforma é normalmente implementado pelo usuário, a implantação deve ser facilitada.
Popularidade: uma plataforma de mediação de dados deve ser continuamente suportado e estendido. Geralmente,
esta facilidade é fornecida dentro de uma comunidade de colaboradores e de pesquisadores.
Abstração de Programação: fornecer uma API para desenvolvedores de aplicativos de forma a isolar o desenvol-
APÊNDICE C. Descrição dos Serviços e Características Desejáveis em uma Plataforma de IoT 117

vimento das aplicações ou serviços das operações fornecidas pelas infraestruturas IoT subjacentes e heterogêneas.
Interoperável: deve funcionar com dispositivos, tecnologias e aplicativos heterogêneos, sem esforço adicional do de-
senvolvedor. Os componentes devem trocar informações através de diferentes redes, potencialmente com tecnologias
diferentes.
Baseado em serviços: uma arquitetura de plataforma de mediação de dados deve ser baseada em serviços para
oferecer alta flexibilidade quando novas funções precisem ser adicionadas a plataforma.
Adaptativo: uma plataforma de mediação de dados precisa ser adaptativo para que possa evoluir para se adaptar
a mudanças em seu ambiente ou contexto. Em IoT a rede e seu ambiente mudam frequentemente.
Context-aware: a arquitetura de plataforma de mediação de dados de IoT precisa estar atenta ao contexto dos
usuários, dispositivos e ambiente e usá-los para oferecer serviços eficazes e essenciais aos usuários.
Autônomo: significa autogovernado. Os dispositivos, tecnologias e aplicações são participantes nos processos de
IoT e devem ser capacitados de interagir e comunicarem-se entre si sem intervenção humana direta.
Distribuído: Os aplicativos, dispositivos e usuários de um sistema IoT em larga escala trocam informações e
colaboram entre si. Uma implementação de uma plataforma de mediação de dados precisa suportar funções que são
distribuídas através da infraestrutura física do ambiente de IoT.

Sign up to vote on this title
UsefulNot useful