UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE UNIDADE ... · Monografia (Tecnólogo) Universidade...
57
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE UNIDADE ESPECIALIZADA EM CIÊNCIAS AGRÁRIAS CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS Thiago Victor Lima Brasil APLICAÇÃO DE MIDDLEWARE PARA O MONITORAMENTO DE UNIDADE PRODUTIVA NA AQUICULTURA Macaíba / RN Novembro, 2017
Transcript of UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE UNIDADE ... · Monografia (Tecnólogo) Universidade...
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
UNIDADE ESPECIALIZADA EM CIÊNCIAS AGRÁRIAS
CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE
SISTEMAS
Thiago Victor Lima Brasil
APLICAÇÃO DE MIDDLEWARE PARA O MONITORAMENTO DE UNIDADE
PRODUTIVA NA AQUICULTURA
Macaíba / RN
Novembro, 2017
Thiago Victor Lima Brasil
APLICAÇÃO DE MIDDLEWARE PARA O MONITORAMENTO DE UNIDADE
PRODUTIVA NA AQUICULTURA
Trabalho de conclusão de curso de graduação
apresentado à Unidade Especializada em Ciências
Agrárias da Universidade Federal do Rio Grande do
Norte como requisito parcial para a obtenção do título
de Tecnólogo (a) em Análise e Desenvolvimento de
Sistemas.
Orientador: Prof. Dr. Taniro Chacon Rodrigues
Macaíba / RN
2017
Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Rodolfo Helinski - Escola Agrícola de Jundiaí –
EAJ
Brasil, Thiago Victor Lima.
Aplicação de middleware para o monitoramento de unidade
produtiva na aquicultura / Thiago Victor Lima Brasil. - 2017.
57f.: il.
Monografia (Tecnólogo) Universidade Federal do Rio Grande do
Norte. Unidade Acadêmica Especializada em Ciências Agrárias.
Tecnologia em Análise e Desenvolvimento de Sistemas. Macaíba,
2017.
Orientador: Taniro Chacon Rodrigues.
1. Middleware - Monografia. 2. Fireware - Monografia. 3.
Orion - Monografia. 4. Sensor - Monografia. 5. IoT - Monografia.
6. Smartfarm - Monografia. I. Rodrigues, Taniro Chacon. II.
Título.
RN/UF/BSPRH CDU 004.41
Thiago Victor Lima Brasil
Aplicação de Middleware Para O Monitoramento De Unidade Produtiva Na
Aquicultura
Trabalho de conclusão de curso de graduação apresentado à Unidade Especializada em Ciências
Agrárias da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção
do título de Tecnólogo (a) em Análise e Desenvolvimento de Sistemas.
Aprovado em: ____ de _______ de _____.
BANCA EXAMINADORA
__________________________________________
Prof. Dr. Taniro Chacon Rodrigues - UFRN
__________________________________________
Prof. Dr. Josenalde Barbosa de Oliveira – EAJ/UFRN
__________________________________________
Profa. Dra. Fabiana Rodrigues de Arruda Câmara – EAJ/UFRN
DEDICATÓRIA
Dedico este trabalho primeiramente а
Deus, por ser essencial em minha vida, autor de
meu destino, refúgio, fortaleza e socorro bem
presente na angústia, ao meu pai Hilton Brasil,
minha mãe Sônia Araújo, ao meu irmão Diogo
Brasil, a minha amada e companheira Fabyanne
Batista e a todos os meus amigos e professores
que me acompanharam nesta jornada de
aprendizado e desafios. Sem vocês, não teria
chegado até aqui.
AGRADECIMENTOS
Gostaria de agradecer primeiramente a Deus, por ter sido meu refúgio bem presente na
angústia, meu conselheiro, meu consolador, meu maior motivador pois me mostrou, e ainda
mostra, em todos os pequenos detalhes, que tudo na vida tem seu propósito. Te agradeço.
Minha família, meus pais Hilton e Sonia por todo o carinho, dedicação, broncas, e
acima de tudo, amor concedidos a mim. Por terem me mostrado a importância dos valores das
palavras, respeito, compaixão, amor ao próximo. Por todos os momentos em que discutimos,
pois nestes momentos vemos o quanto somos importantes uns para os outros quando chega o
momento do perdão. Agradeço também ao meu irmão Diogo, pelas conversas, pelos
aprendizados, ora, duas pessoas com praticamente os mesmos hobbies, sempre têm conversas
‘nerds’ que duram noites até pegar no sono não é mesmo? Amo vocês, obrigado!
Agradeço também a minha companheira e amada Fabyanne, por toda motivação,
suporte, carinho, amor, atenção e tudo mais do que poderia pedir a Deus nestes momentos.
Sabemos que tudo na vida tem um propósito e as dificuldades estão para serem superadas, por
isso te agradeço, muitas bênçãos virão. Obrigado, te amo!
Agradeço aos meus professores que me acompanharam em toda de minha trajetória
nesta universidade, cada deles com suas particularidades marcantes, que construíram minha
vida acadêmica de forma espetacular, sem palavras. Obrigado. Dentre esses grandes
profissionais, destaco meu agradecimento ao meu orientador, professor e amigo Taniro. Um
profissional excepcional que mesmo em sua sobrecarga de responsabilidades aceitou me
orientar neste trabalho, me ensinou bastante e me inspirou em propor um trabalho voltado a
área de sistemas distribuídos. Muito obrigado!
Como não poderia deixar de fora, meus grandes amigos e em especial a todos que
estavam do meu lado fazendo esta graduação totalmente inesquecível. Saibam que todos os
momentos vividos até o momento estão guardados nas minhas memórias, até os extraclasses!
Como esquecer as viagens de campo, jogos virtuais e trabalhos em grupo na casa de Laércio,
nosso sábio mentor? Heriberto com sua inteligência de programação indiscutível, Felipe
Matheus com seus rages, a grande dupla Joel e Iaslan, inseparáveis e amigos formidáveis,
Filipe Bastos achando até hoje que sou empresário e o mais recente no grupo Arthur, que com
toda sua impaciência, se tornou marcante. A todos não citados até aqui, saibam que são tão
importantes quanto, pois todos detém o título de amigos. Obrigado!
“Agir, eis a inteligência verdadeira. Serei o que
quiser. Mas tenho que querer o que for. O êxito
está em ter êxito, e não em ter condições de êxito.
Condições de palácio tem qualquer terra larga,
mas onde estará o palácio se não o fizerem ali?”
Fernando Pessoa
RESUMO
Com base no crescimento populacional e tecnológico, as vertentes produtivas buscam
cada vez mais otimizar seus processos. Nesse contexto, a aquicultura se destaca como uma
atividade com grande potencial de aplicações de tecnologia para o aumento da produção. A
implantação de uma rede de sensores contribui para a análise de todos os aspectos que podem
influenciar para a qualidade da água. No entanto, a heterogeneidade dos dispositivos
existentes é um fator limitante que torna um desafio a transmissão e o envio de dados para
uma interface ou aplicação específica que ajude o produtor nas tomadas de decisões acerca da
sua unidade produtiva. O objetivo deste trabalho é desenvolver uma aplicação que utilize o
middleware: fiware orion context broker como ferramenta capaz de receber dados enviados
por sensores, independente do hardware utilizado, dando ao produtor informações do contexto
de sua unidade produtiva através de uma interface web. Este trabalho foi avaliado através de
uma prova de conceitos, analisando o comportamento da aplicação em uma sequência de
cenários que simularam prováveis situações reais em um ambiente produtivo, as quais a
aplicação correspondeu às expectativas propostas.
Palavras-chave: fiware, middleware, orion, sensor, IoT, smartfarm.
ABSTRACT
Based on population and technological growth, the productive sectors are increasingly
seeking to optimize their processes. In this context, aquaculture stands out as an activity with
great potential for technology applications to increase production. The implementation of a
sensor network contributes to the analysis of all aspects that can influence water quality.
However, the heterogeneity of existing devices is a limiting factor that makes it difficult to
transmit and send data to a specific interface or application that helps the producer to make
decisions about his production unit. The objective of this work is to develop an application
that uses the middleware: fiware orion context broker as a tool capable of receiving data sent
by sensors, regardless of the hardware used, giving the producer context information of his
production unit through a web interface. This work was evaluated through a proof of
concepts, analyzing the behavior of the application in a sequence of scenarios that simulated
probable real situations in a productive environment, which the application corresponded to
the proposed expectations.
Keywords: fiware, middleware, orion, sensor, IoT, smartfarm.
LISTA DE FIGURAS
Figura 1. Comunicação de Dispositivos com um Serviço Web. ........................................................... 15
Figura 2. Abordagem de acesso aos serviços. ....................................................................................... 16
Figura 3. Exemplo de Middleware em atuação. .................................................................................... 18
Figura 4 Arquitetura do OCB (FIWARE FORGE, 2016b) ................................................................... 23
Figura 5 Descrição do Elemento de Contexto (FIWARE FORGE, 2016b) .......................................... 25
Figura 6 Sensor DS18B20 de Temperatura (MAXIM, 2017) ............................................................... 26
Figura 7 Sensor SEN-11194 para Oxigênio Dissolvido na Água ......................................................... 27
Figura 8 Sensor de pressão atmosférica (HOBECO, 2017) .................................................................. 27
Figura 9 Sensor para Nitrito .................................................................................................................. 28
Figura 10 Arquitetura do Sistema ......................................................................................................... 29
Figura 11 Diagrama de Implantação do Trabalho ................................................................................. 31
Figura 12 Escolha da porta de comunicação do sensor ......................................................................... 31
Figura 13 Interface do Docker (Windows)............................................................................................ 32
Figura 14 Iniciando a virtualização do OCB ......................................................................................... 32
Figura 15 Sequência de comunicação ................................................................................................... 33
Figura 16 Criação de Unidade Produtora de Informação Contexto ...................................................... 34
Figura 17 Criação de PIC através do Arduino IDE ............................................................................... 35
Figura 18 Sequencia que segue a criação .............................................................................................. 35
Figura 19 Atualização da Informação de Contexto ............................................................................... 36
Figura 20 Consulta do cliente ao middleware ....................................................................................... 37
Figura 21 Resposta JSON a consulta .................................................................................................... 37
Figura 22 Resultado da consulta do Cliente .......................................................................................... 38
Figura 23 Interface Web no Primeiro Acesso ....................................................................................... 39
Figura 24 Cadastro de Novo Perfil ........................................................................................................ 40
Figura 25 Unidade Cadastrada .............................................................................................................. 41
Figura 26 Posição Geográfica de um Produtor Informação de Contexto .............................................. 41
Figura 27 Adição de novo sensor a unidade produtiva via plataforma Arduino ................................... 42
Figura 28 Layout da Interface com Produtor de Contexto Criado ........................................................ 43
Figura 29 Adição de sensor de taxa de oxigênio via cliente REST....................................................... 43
Figura 30 Nova produtores de contexto adicionados ............................................................................ 44
Figura 31 Remoção de produtor de Contexto via cliente REST ........................................................... 44
LISTA DE TABELAS
Tabela 1. Interface Uniforme RESTful ................................................................................................. 17
Tabela 2 Padrões básicos da ferramenta curl ........................................................................................ 34
SUMÁRIO
1. INTRODUÇÃO .................................................................................................................... 9
1.1 JUSTIFICATIVA ............................................................................................................... 12
1.1 OBJETIVOS ....................................................................................................................... 12
1.1.1 OBJETIVO GERAL ..................................................................................................... 12
1.1.2 OBJETIVOS ESPECÍFICOS ....................................................................................... 13
2. CONCEITOS BÁSICOS .................................................................................................... 14
2.1 COMPUTAÇÃO ORIENTADA A SERVIÇOS ................................................................ 14
2.1.1 SERVIÇO WEB .............................................................................................................. 14
2.2 REST .................................................................................................................................. 15
2.3 PUBLISH/SUBSCRIBE ..................................................................................................... 17
2.4 MIDDLEWARE ................................................................................................................. 18
2.5 FIWARE ............................................................................................................................. 20
2.5.1 HABILITADORES GENÉRICOS .................................................................................. 20
2.6.2 ORION CONTEXT BROKER (OCB) ............................................................................ 21
2.5.3 INTERFACE OMA NGSI .............................................................................................. 23
2.5.4 ENTIDADES DE CONTEXTO ...................................................................................... 24
2.6 PARÂMETROS DA QUALIDADE DA ÁGUA ............................................................... 25
2.6.1 TEMPERATURA DA ÁGUA ........................................................................................ 25
2.6.2 OXIGÊNIO DISSOLVIDO EM ÁGUA ......................................................................... 26
2.6.3 PRESSÃO ATMOSFÉRICA .......................................................................................... 27
2.6.4 NITRITO ......................................................................................................................... 27
3. ARQUITETURA DO SISTEMA ...................................................................................... 29
3.1. IMPLANTAÇÃO .............................................................................................................. 31
3.2 IMPLEMENTAÇÃO ......................................................................................................... 33
3.2.1 ENVIO DE INFORMAÇÕES AO MIDDLEWARE ...................................................... 33
3.2.2 IMPLEMENTAÇÃO DE UM PRODUTOR DE INFORMAÇÃO CONTEXTO ......... 34
3.2.3 ATUALIZAÇÃO DA INFORMAÇÃO DE CONTEXTO ............................................. 36
3.2.4 CONSULTA DO CLIENTE AS INFORMAÇÕES COLETADAS ............................... 36
4. AVALIAÇÃO ..................................................................................................................... 39
4.1 INTERFACE WEB ............................................................................................................ 39
4.1.1 CRIANDO UM PERFIL DE USUÁRIO ........................................................................ 40
4.1.2 LEITURA DAS INFORMAÇÕES DE CONTEXTO .................................................... 40
4.1.3 LEITURA DA POSIÇÃO GEOGRÁFICA .................................................................... 41
4.2 CRIAÇÃO DE UM NOVO PRODUTOR DE CONTEXTO ............................................ 42
4.2.1 NOVO PRODUTOR DE INFORMAÇÃO DE CONTEXTO (SENSOR) ..................... 42
4.2.3 REMOÇÃO DE UM PRODUTOR DE INFORMAÇÃO DE CONTEXTO .................. 44
4.3 ANALISE DE RESULTADOS .......................................................................................... 45
5. CONSIDERAÇÕES FINAIS ............................................................................................. 46
5.1 LIMITAÇÕES .................................................................................................................... 46
5.2 TRABALHOS FUTUROS ................................................................................................. 47
REFERÊNCIAS ..................................................................................................................... 48
9
1. INTRODUÇÃO
A produção de alimentos é uma atividade que tende a crescer proporcionalmente com
a população. Segundo as Organizações das Nações Unidas (ONU), a população atual é
estimada em 7 bilhões de pessoas e está projetada para crescer cerca de 1 milhão nos
próximos 12 anos e alcançar cerca de 9,6 bilhões 2050 (UNRIC, 2015). Logo, uma demanda
maior de consumidores necessitará de uma oferta maior de alimentos. Para atender a atual e
futuras demandas, agricultores e empresas agrícolas têm voltado atenção para a otimização da
capacidade de produção de alimentos através da informatização.
A crescente inovação tecnológica que vem ocorrendo nos últimos anos corrobora para
que a informatização seja uma alternativa potencial para a melhoria da qualidade produtiva,
tornando assim, a tecnologia um forte aliado na maximização da produção. Devido à grande e
crescente competitividade, é exigido do produtor muito mais especialização e aplicação de
técnicas precisas para o aumento da capacidade produtiva e rentabilidade de suas produções
(AGROCAMPO, 2017). Nesse contexto, o uso da tecnologia a fim de transmitir ao produtor
um panorama, ou contexto, abrangente de todas as particularidades em sua produção pode
auxilia-lo em tomadas de decisões como relação a manutenção, gerenciamento e mercado.
Este tecnologia que auxilia na tomada de decisões incorpora o grupo denominado Decision
Support Systems (FEHRENBACHER; DJAMASBI, 2017).
A aquicultura, ou aquacultura, é a vertente da cultura produtiva voltada ao cultivo de
organismos aquáticos como: peixes, moluscos, crustáceos, repteis e plantas aquáticas. Esta
modalidade de cultura produtiva data de cerca de dois mil anos antes de Cristo (2000 a.C.) na
China, a princípio com o monocultivo da carpa, porém também, macroalgas marinhas como
fonte de alimento (VINATEA, 2012) . Esta vertente continua a crescer em uma taxa mais
elevada que todos os outros setores da produção animal mundial, em números, a produção
mundial de pescado é de 158 milhões de toneladas (número de 2012), movimentando US$
600 bilhões/ano – sendo US$ 136 bilhões/ano em exportações. Tais dados, apontam para uma
grandeza sete vezes maior do que os negócios de carne bovina e, além disso, um hectare de
terra pode gerar 0,12 toneladas/ano de carne, enquanto na mesma medida (um hectare) de
terra, podem ser produzidas de 100 a 320 toneladas/ano de peixe, dependendo do cultivo (de
acordo com informações do Ministério da Pesca) (PORTAL BRASIL, 2015).
No contexto da aquicultura, o Brasil está em 12º no ranking mundial e estimado que
se produção for ampliada para 2 milhões de toneladas ano, o país poderá figurar entre os cinco
maiores do mundo em 2020. A aquicultura brasileira cresceu 8,6% em 22 anos, passando de
10
32,4 milhões de toneladas para 66,6 milhões de toneladas/ano. Entre o período de 2000 e
2012, na comparação com a carne bovina, o crescimento da produção de pescado em cativeiro
foi seis vezes maior. O aumento da produção do pescado foi de 6,7% enquanto o da carne foi
de 1,2% (PORTAL BRASIL, 2015).
Apesar das projeções favoráveis, é necessário o estudo de melhorias tecnológicas para
o aumento produtivo ou soluções às problemáticas relativas a produção. Por exemplo,
obtenção de informações do contexto (como temperatura, uso de energia, oxigenação, etc.) de
uma unidade produtiva. Na aquicultura, informações de contexto importantes para a produção
são, por exemplo, a quantidade de oxigênio dissolvido na água, temperatura do ambiente e da
água, funcionamento de dispositivos, como aeradores, entre outros. A falta de informação de
contexto para o gerenciamento do ciclo produtivo afeta a produção em um âmbito industrial e,
principalmente, familiar de subsistência.
Atualmente existem na literatura diversas soluções que trabalham com a obtenção de
dados de contexto de produções aquícolas. No trabalho Monitoramento da Piscicultura em
Reservatórios (SAMPAIO; COSTA, 2011), os autores apresentam uma aplicação do
biomonitoramento para estudo da decomposição foliar, que se propõe a refletir a qualidade
funcional do ecossistema aquático. O trabalho Estoques e Fluxos de Carbono no Semiárido
Nordestino: Estimativas Preliminares (SAMPAIO; COSTA, 2011) foi proposto devido a
decorrente expansão da piscicultura em reservatórios do rio São Francisco, onde houve uma
demanda estudos que avaliem sua capacidade suporte, para garantir sua sustentabilidade. A
coleta de dados desta pesquisa foi baseada na aplicação da técnica de litter bags (bolsa de
folheto) (BENFIELD et al., 1979) para análise da decomposição foliar. Uma característica
observada nesse trabalho é a necessidade da presença constante dos pesquisadores para coleta
local da informação. O envio de dados via web, e de forma intermitente, auxiliaria os
pesquisadores no monitoramento do comportamento da qualidade da água nas estações em
questão, evitando deslocamentos e proporcionando possíveis gerenciamentos quanto ao
manejo e qualidade da água providenciados de qualquer parte do globo.
O PSITECH (FAPEAM, 2017) é um software em desenvolvimento que tem como
proposta controlar os parâmetros de qualidade da água oxigênio dissolvido e temperatura em
tanques de piscicultura. O software é iniciativa de uma startup de mesmo nome que tem apoio
do governo do Amazonas por meio da Fundação de Amparo à Pesquisa do Estado do
Amazonas (Fapeam) e que tem como diferencial seu custo mais acessível em comparação aos
modelos tradicionais comercializados. O projeto é motivado devido o controle da qualidade
11
da água ser uma das principais dificuldades enfrentadas pelos piscicultores, uma vez que a
água usada nos tanques influencia diretamente na produção e na vida saudável dos peixes. Em
seu escopo, o PSITECH propõe realizar análise da água nos tanques, com equipamento capaz
de enviar informações sobre tudo o que acontece no tanque de piscicultura para um atuador. O
software compromete-se a trabalhar diretamente com atuadores, agindo da seguinte forma:
quando a temperatura da água estiver alta o controlador poderá ligar uma válvula para circular
a água. Se o oxigênio dissolvido estiver baixo, também será possível acionar o aerador para
aumentar o oxigênio dissolvido no tanque. Analisando o panorama do PISCITECH, há uma
carência de uma interface web onde estas informações possam ser exibidas ao produtor e um
registro em banco de dados com as informações proporcionando um estudo estatístico.
A Internet das coisas está preparada para impulsionar o futuro da aquicultura para o
próximo nível. Como já acontece nas cidades inteligentes (Smart Cities) (“The Smart City
Concept in the 21st Century”, 2017), o termo fazendas inteligentes (Smart Farmings) (“Big
Data in Smart Farming – A review”, 2017) vêm ganhando força no campo e nas mais diversas
atividades produtivas, tornando mais comum a relação entre as empresas e a alta tecnologia
(MEOLA, 2016). Dispositivos com acesso a rede como: sensores, smartphones, tablets e
computadores tem se tornado, cada vez mais, ferramentas facilitadoras para o gerenciamento
e manutenção de ambientes de produção, haja vista o avanço do uso do termo agricultura de
precisão (AGROCAMPO, 2017).
Dessa forma, o desenvolvimento de uma aplicação que centralize a comunicação entre
informações geradas por sensores com outros dispositivos como: smartphones, tablets ou
computadores, tem potencial para melhorar o poder de gerenciamento do ciclo produtivo e
contribuir tomadas de decisões do usuário (produtor), decisões essas como: troca de uma
determinada espécie de peixe de uma unidade produtiva a outra devido a temperatura fora do
padrões recomendados, informar ao usuário que a quantidade de oxigênio da unidade
produtiva está inadequada e requer aeração, dentre outras.
No entanto, existe atualmente uma grande heterogeneidade tanto de hardware
(sensores, processadores, memória, dispositivos mobile, etc.) quanto de software (sistemas
operacionais, protocolos de comunicação, etc.) dos dispositivos que podem ser empregados
em uma solução para IoT. A heterogeneidade, na computação, significa diferenças de
hardware, software e de meios de comunicação, e traz como desafio o desenvolvimento de
ferramentas que sejam confiáveis, estáveis e que interajam entre si independente do ambiente.
Dado isso, a utilização de uma plataforma middleware que proporcione a interação de
12
maneira independente das particularidades de cada dispositivo ou meio de comunicação, é
uma possível solução para lidar com sistemas de grande heterogeneidade.
1.1 JUSTIFICATIVA
Devido ao gradual crescimento populacional e aumento da demanda por alimentos, as
atividades aquícolas buscam meios de produzir com mais velocidade, precisão e qualidade.
Tendo em vista esses pontos, a tecnologia se torna uma grande aliada uma vez que está
presente praticamente em todos os processos atuais de produção.
Em busca da eficiência produtiva, a crescente inclusão da informatização, leva a um
aumento na quantidade de dispositivos e tecnologias envolvidas, com isso, as probabilidades
da existência de problemas com a heterogeneidade de hardware tanto de software sejam
eminentes. Como também a preocupação com a segurança, qualidade e quantidade de
informações que trafegarão nestes dispositivos.
Neste contexto, é proposto nesse trabalho de conclusão de curso a utilização do
middleware: fiware orion context broker para intermediar um ambiente que reúne
informações de vários dispositivos provenientes de um ou mais sensores. Desta forma,
aplicando o conceito de IoT a produção aquícola. Isto significa que tecnologias com
arquiteturas diferentes trabalhem em conjunto operando de maneira distribuída, tolerante a
falhas e escalável uniformemente para prover ao produtor uma interface que contenha
informações diversas sobre uma unidade produtiva.
1.1 OBJETIVOS
Esta seção tem o propósito de apresentar os objetivos deste trabalho. A seção 1.1.1
apresenta o objetivo geral do trabalho que concentra a sua ideia central. A seção 1.1.2
apresenta os objetivos específicos, expondo os pontos que se pretende alcançar com a
pesquisa e desenvolvimento.
1.1.1 OBJETIVO GERAL
O objetivo geral desse trabalho é oferecer uma interface para acesso a informações de
contexto produzidas, ou seja, informações características, por determinados dispositivos
sensores. Assim, um usuário, a partir de qualquer dispositivo que possua um navegador, será
capaz de acessar informações de contexto produzidas pelos dispositivos implantados na
unidade produtiva através de uma interface que facilite suas leituras. Com o este intuito, é
13
proposto o desenvolvimento de uma interface que reúnas as informações geradas em tempo
real pelos dispositivos sensores, organize-as em tabelas, proporcionando através deste mashup
(FICHTER, 2007), ou seja, uma interface personalizável, uma experiência intuitiva e
transparente ao usuário. Em outras palavras, tornar a tecnologia uma ferramenta a favor do
usuário para suas tomadas de decisões lhe proporcionando um melhor gerenciamento de suas
atividades em tempo real.
1.1.2 OBJETIVOS ESPECÍFICOS
Os objetivos específicos desse trabalho são:
(i) Desenvolvimento de aplicações para dispositivos com capacidade de
sensoriamento;
(ii) A implantação do middleware fiware orion context broker para intermediar a
comunicação entre as informações de contexto geradas pelos dispositivos
sensores ou atuadores.
(iii) Desenvolvimento de uma interface web que acesse e reúna os dados existentes
no middleware, assim promovendo ao usuário uma leitura amigável de toda a
informação de contexto referente a unidade produtiva em tempo real.
14
2. CONCEITOS BÁSICOS
Neste Capítulo, são apresentados os conceitos básicos que alicerçam este trabalho. São
abordados assuntos como computação orientada a serviços (Seção 2.1), padrão arquitetural
REST (Seção 2.2), um resumo teórico acerca da ferramenta middleware fiware: orion context
broker (Seção 2.6.), juntamente dos conceitos: entidades de contexto e habilitadores
genéricos.
2.1 COMPUTAÇÃO ORIENTADA A SERVIÇOS
A computação orientada a serviços (SOA ou, em inglês, SOC – Service Oriented-
Computing) é um paradigma promissor que utiliza serviços como princípios fundamentais
para o desenvolvimento de aplicações (soluções). Nesse contexto, os serviços são definidos
como elementos computacionais autônomos, auto descritivos, reusáveis e altamente portáveis,
diferindo assim de artefatos de software tradicionais. De maneira rápida e com um baixo
custo, serviços podem ser descritos, publicados, descobertos e dinamicamente agregados para
desenvolver sistemas distribuídos, interoperáveis e capazes de evoluir, podendo executar
funções que vão desde responder a simples requisições até mesmo executar processos de
negócio mais sofisticados (PAPAZOGLOU, 2003; PAPAZOGLOU et al., 2006).
Qualquer pedaço de código ou até mesmo qualquer componente de aplicação
implantado em um sistema pode ser reusado e transformado em um serviço disponível na
rede, reduzindo assim a necessidade de desenvolver novos componentes de software toda vez
que um novo processo de negócio surge (WEI; BLAKE, 2010). Assim, serviços refletem uma
abordagem de programação orientada a serviços baseada na ideia de compor aplicações
através da descoberta e invocação de serviços disponíveis através da rede para realizar alguma
dada tarefa (PAPAZOGLOU et al., 2006, 2007).
De forma geral, tem em sua essência permanecerem independentes do contexto no
qual irão ser utilizados e de linguagens de programação ou sistemas operacionais específicos,
ou seja, há um fraco acoplamento entre o provedor de serviço e o cliente que o consome.
2.1.1 SERVIÇO WEB
Dentro do contexto da Computação Orientada a Serviços os serviços web (web
services) tem ganhado destaque cada vez maior nos últimos anos devido a popularização do
uso de redes e internet. Um serviço web é qualquer software que se disponibiliza pela internet,
15
ou rede, que realiza alguma tarefa (serviço) através do recebimento de dados e que envia uma
resposta ao cliente que invocou a tarefa. Suas características apresentam serviços autônomos,
modulares, distribuídos e dinâmicos que podem ser escritos, publicados, localizados ou
invocados na rede para criar produtos, processos e cadeias de suprimentos. Esses serviços
podem ser locais, distribuídos ou baseados na web.
Um serviço web é uma coleção de protocolos abertos e padrões usados para troca de
dados entre aplicativos e/ou sistemas. Aplicativos de várias linguagens de programação e em
execução em várias plataformas podem usar serviços da web para trocar dados em uma rede
de computadores, como a internet, de maneira similar à comunicação entre processos e um
único computador. Esta interoperabilidade (por exemplo, entre Java e Python, ou aplicativos
Windows e Linux) deve-se ao uso de padrões abertos (TUTORIALSPOINT, 2017). Ou seja,
em serviços web, apesar de cada aplicação ter a sua própria "linguagem", durante o processo
de comunicação tal linguagem é traduzida para uma linguagem comum através de um formato
intermediário como XML, JSON, CSV, etc.
Abaixo, a Figura 1 demonstra um diagrama de como é realizada a comunicação entre
dispositivos heterogêneos com um serviço web disponibilizado na internet.
Figura 1. Comunicação de Dispositivos com um Serviço Web.
2.2 REST
A sigla REST significa REpresentional State Transfer (Transferência de Estado
Representativo), e é um estilo de desenvolvimento de Serviços Web (Web Services) que teve
origem na tese de doutorado de Roy Fielding (FIELDING, 2000). Este por sua vez, é coautor
16
de um dos protocolos mais utilizados no mundo, o HTTP (HyperText Transfer Protocol).
Assim, é notável que o protocolo REST é guiado pelas boas práticas de uso de HTTP:
• Uso adequado dos métodos HTTP, onde os mais utilizados são: GET, POST,
PUT, DELETE (SPRING, 2017), como exibido na Figura 2.
• Uso adequado de URL’s (Uniform Resource Locator), ou em português,
Localizador Padrão de Recursos (tradução livre);
• Uso de códigos de status padronizados para representação de sucessos ou
falhas;
• Uso adequado de cabeçalhos HTTP;
• Interligações entre vários recursos diferentes.
Figura 2. Abordagem de acesso aos serviços.
O ponto de partida do REST é o conceito de recurso. Em REST, tudo é definido em
termos de recursos, sendo estes, os conjuntos de dados que são trafegados pelo protocolo. Os
recursos são representados por URI’s (Uniform Resource Indentifiers) ou Identificador
Uniforme de Recursos.
Uma URI pode ser utilizada para identificar qualquer recurso, dar caminho para um
determinado conteúdo, dar nome a este, etc. Uma URL (Universal Resource Locator) é
utilizada apenas para fornecer caminhos, em outras palavras uma URL é uma forma de URI.
É mais natural que URI’s que não sejam URL’s sejam utilizadas em outros contextos, como
fornecimento de namespaces XML. (SAUDATE, 2014)
Na literatura é possível encontrar a terminologia RESTful que significa a capacidade
que um determinado sistema tem de implementar um serviço web utilizando o HTTP e os
17
princípios do REST. Nas arquiteturas RESTful as informações trafegam via métodos HTTP,
onde no escopo da URI é que é transferido estas informações. Por exemplo, na primeira linha
de uma solicitação HTTP para um serviço web RESTful orientado a recursos: ("GET / reports
/ open-bugs HTTP / 1.1"), nota-se basicamente o que o cliente deseja fazer, que é buscar listar
de open-bugs. Se o método HTTP não coincide com as informações do método, o serviço não
é RESTful. Se a informação de escopo não estiver no URI, o serviço não é orientado a
recursos. Estes não são os únicos requisitos. (RICHARDSON; RUBY, 2007)
Para interagir com as URL’s são utilizados métodos HTTP. A regra de ouro para esta
interação é que URL’s são substantivos e métodos HTTP são os verbos. Isto quer dizer que os
métodos HTTP são os responsáveis por provocar alterações nos recursos identificados pelas
URL’s (SAUDATE, 2014). Estas modificações são padronizadas conforme demonstra a
Tabela 1.
Tabela 1. Interface Uniforme RESTful
A Tabela 1 demonstra como os verbos HTTP são utilizados para que o RESTful tenha
seu funcionamento correto. O verbo GET tem função de recuperar os dados identificados
previamente na URL, o verbo POST que uma vez contenha em seu corpo uma informação em
JSON cria um novo recurso, o verbo PUT tem a função de atualizar um recurso já existente e
informado na URL e o verbo DELETE apaga um recurso previamente identificado na URL.
2.3 PUBLISH/SUBSCRIBE
O publish/subscribe é um paradigma de comunicação com desacoplamento entre
produtores e assinantes em termos de tempo, espaço e sincronização. No publish/subscribe os
produtores publicam (publish) informações organizadas através de “tópicos” enquanto os
assinantes especificam “tópicos” de interesse e passam a receber dados apenas dos tópicos
assinados, por isso o nome “subscribe”. Os eventos publicados são disponibilizados para seus
18
assinantes interessados, sem os produtores necessariamente conhecerem os seus assinantes e
vice-versa. (ADHIANTO et al., 2010)
Este paradigma de comunicação é baseado na troca assíncrona de mensagens, conhecidas
como eventos. Além do assincronismo, este modelo proporciona mais flexibilidade e
extensibilidade às aplicações que utilizam este modelo na inclusão de novos produtos e
consumidores.
Outra característica interessante do paradigma publish/subscriber é que os produtores
e consumidores não necessariamente necessitam estar disponíveis ao mesmo tempo.
Isso significa que um assinante pode receber as notificações mesmo que o um novo produtor
seja criado para determinado contexto. Tal característica tem alavancado o uso de aplicações
com comunicação publish/subscribe, principalmente no contexto da computação móvel, onde
a existência de uma conexão muitas vezes não pode ser garantida. Finalmente, o
publish/subscribe reflete diretamente o comportamento intrínseco de aplicações orientadas
para a informação porque a comunicação é iniciada pelos produtores de informação. (MÜHL;
BUCHMANN; BACON, 2002)
2.4 MIDDLEWARE
Um middleware (ou em português, mediador), no âmbito da computação distribuída,
basicamente é um software que realiza a mediação entre outros softwares e demais aplicações.
Em outras palavras, o termo middleware se aplica a uma camada de software que fornece uma
abstração de programação, assim como o mascaramento da heterogeneidade das redes, do
hardware, dos sistemas operacionais e das linguagens de programação subjacentes (GEORGE
COULOURIS, 2013).
Figura 3. Exemplo de Middleware em atuação.
19
Além de resolver os problemas de heterogeneidade, o middleware fornece um modelo
computacional uniforme para ser usado pelos programadores de serviços e de aplicativos
distribuídos. Os modelos possíveis incluem a invocação remota de objetos, a notificação
remota de eventos, o acesso remoto a banco de dados e o processamento de transação
distribuído (GEORGE COULOURIS, 2013).
Há diversas categorias de middlewares, cada uma delas é motivada pela escolha de
entidades que se comunicam e pelos paradigmas de comunicação associados, seguindo cinco
dos principais modelos arquitetônicos: serviços web, objetos distribuídos, componentes
distribuídos, sistemas publish/subscribe e filas de mensagens (GEORGE COULOURIS,
2013).
Exemplos de paradigmas populares de middleware são:
(i) CORBA - (Common Object Request Broker Architecture), fornece invocação
remota de objetos, a qual permite que um objeto, em um programa sendo
executado em um computador, invoque um método de um objeto em um
programa executado em outro computador. Sua implementação oculta o fato de
que as mensagens passam por uma rede para enviar o pedido de invocação e
sua resposta (GEORGE COULOURIS, 2013).
(ii) RMI - O Java Remote Method Invocation (RMI). é muito parecida com as
chamadas de procedimento remoto (RPC – Remote Prodecure Calls), mas
voltada para o mundo dos objetos distribuídos. Com essa estratégia, um objeto
chamador pode invocar um método em um objeto potencialmente remoto,
usando invocação de método remoto. Assim como na RPC, os detalhes
subjacentes geralmente ficam ocultos do usuário. Contudo, as implementações
de RMI podem ir mais além, suportando a identidade de objetos e a capacidade
associada de passar identificadores de objeto como parâmetros em chamadas
remotas. De modo geral, elas também se beneficiam de uma integração mais
forte com as linguagens orientadas a objetos (GEORGE COULOURIS, 2013).
(iii) Orion Context Broker - é uma implementação Broker Publish/Subscriber que
fornecendo as interfaces NGSI9 e NGSI10. Usando essas interfaces, os clientes
podem fazer várias operações, como registro de aplicações, atualizações de
contexto e consultas. Em outras palavras, o Publish/Subscriber atua com as
informações cadastradas por determinado produtor e as envia para os
20
assinantes específicos que demonstram interesse em recebe-la. O Orion será
apresentado com mais detalhes na seção 2.11.
2.5 FIWARE
O Fiware é uma plataforma criada pela União Europeia para o desenvolvimento e
implantação de aplicações globais para a internet. Esta plataforma possui uma API aberta,
onde é encorajado o envolvimento dos usuários e desenvolvedores, visto que o objetivo
máximo é tornar-se uma plataforma padrão com soluções reutilizáveis. Até que este objetivo
máximo seja alcançado, existe um outro objetivo que está atrelado a este, que é facilitar o
custo e a eficácia da criação e da entrega de aplicações e serviços de internet do futuro em
diversas áreas, incluindo cidades inteligentes, fazendas inteligentes, transportes sustentáveis,
energia renovável e sustentabilidade ambiental (FIWARE FORGE, 2017).
Na constituição da Fiware estão os habilitadores genéricos, que são os principais
elementos desta plataforma. Relacionados à aplicações, serviços e dados, os habilitadores
genéricos, em conjunto, dão suportes a criação de um ecossistema de aplicações, serviços e
dados sustentáveis, possibilitando o gerenciamento de serviços em um framework de
negócios, durante todo o ciclo de vida de um serviço por exemplo (PATIL; RAJESH;
SABHARWAL, 2011).
As subseções a seguir apresentam os elementos básicos inerentes ao Fiware, na qual a
subseção 2.5.1 trata dos habilitadores genéricos, já a subseção 2.5.2 trata do middleware orion
context broker e suas características, a subseção 2.5.3 discorre sobre a interface de
comunicação OMA NGSI e finalizando as subseções referentes ao Fiware, a subseção 2.5.4
que aborda as entidades de contexto.
2.5.1 HABILITADORES GENÉRICOS
Na documentação da plataforma Fiware, existem capítulos técnicos que são divididos
por conjuntos de funcionalidades responsáveis por prover serviços, tais como segurança,
infraestrutura, etc (FIWARE, 2017). As ferramentas utilizadas para realizar os serviços são
denominadas Generic Enablers (GEs) ou habilitadores genéricos, onde sua proposta é
disponibilizar uma série de funções de propósito geral, oferecidas através de APIs
(Application Programming Interface) bem definidas, facilitando o desenvolvimento de
aplicativos inteligentes em vários setores. Os GEs estabelecerão as bases da arquitetura
21
associada à sua aplicação. As especificações das API Fiware GE são públicas e isentas de
royalties (“Academia FIWARE”, 2016).
Os GEs oferecem diversos serviços que permitem, dentro de outras coisas,
compartilhar, manipular, pesquisar e processar dados acerca de entidades de contexto,
facilitando o desenvolvimento de aplicações que utilizam informações contextuais. Em alguns
casos os GEs precisam comunicar-se entre si para proverem serviços aos usuários (BATISTA
et al., 2016).
2.6.2 ORION CONTEXT BROKER (OCB)
Dentre os GEs, o Orion Context Broker (OCB) é uma implementação do
Publish/Subscribe Context Broker GE, que fornece interfaces NGSI - 9/10 (FIWARE
FORGE, 2016a). Usando estas interfaces clientes podem realizar alguns tipos de operações:
registrar aplicações que produzem contexto, atualizar informação contextual, receber
notificações quando há mudanças na informação contextual, ou quando essa mudança ocorre
com uma determinada frequência e consultar informação contextual (FIWARE FORGE,
2016b).
Alinhado com a especificação OMA NGSI padrão, a informação de contexto na
Fiware é representada através de estruturas de dados genéricas referidas como elementos de
contexto. Um elemento de contexto refere-se a informações produzidas, coletadas ou
observadas que podem ser relevantes para processamento, realizando análises e extração de
conhecimento. A Fiware suporta um conjunto de tipos básicos de dados básicos, bem como a
possibilidade de definir tipos de dados estruturados: vetores e mapas-chave (quais elementos
podem ser outros vetores, mapas-chave ou tipos de dados simples) (FIWARE FORGE,
2016b).
Em resumo, as informações de contexto no OMA NGSI são representadas através de
estruturas de dados denominadas elementos de contexto, que associaram:
• Um EntityId e EntityType, identificando de forma exclusiva a entidade a que os dados
de contexto se referem.
• Uma sequência de um ou mais atributos de elemento de dados (<nome, tipo, valor>
trigêmeos)
• Metadados opcionais vinculados a atributos (também <nome, tipo, valor> trigêmeos)
22
As interfaces NGSI-9 e NGSI-10 permitem o gerenciamento das configurações de
objetos físicos no mundo real, assim como permite um nível de abstração e remove a
complexidade de gerenciar conexões com gateways e dispositivos.
Utilizando estas interfaces, os clientes podem fazer várias operações como: (i)
Registrar aplicativos do elemento de contexto, por exemplo, um sensor de temperatura dentro
de um viveiro; (ii) Atualizar informações de contexto, por exemplo, enviar atualizações desta
temperatura; (iii) Ser notificado quando as mudanças na informação do contexto ocorrem (por
exemplo, a temperatura mudou) ou com uma determinada frequência (por exemplo, obtenha a
temperatura a cada minuto); (iv) Informações do contexto da consulta. O Orion-Context
Broker armazena informações de contexto atualizadas a partir de aplicativos, então as
consultas são resolvidas com base nessas informações.
As informações de contexto recebidas pelo middleware são armazenadas em um
banco de dados de contexto. Se outro Contexto Consumidor, como por exemplo um
dispositivo do usuário, solicitar a mesma informação de contexto para o middleware, ela pode
ser recuperada do banco de dados. (FIWARE FORGE, 2016b)
Outra característica importante é a escalabilidade, onde as informações de contexto
podem ser muito grandes (por exemplo, entidades que modelam o sensor em uma grande
cidade como Londres, São Paulo ou Tóquio). Assim, o design de projeto do Contexto deve ter
a capacidade de escalabilidade em mente. Assim, a lógica de processamento do middleware
deve ser tão apátrida quanto possível (para habilitar a escala horizontal) e a tecnologia de
banco de dados usada para implementar a persistência do contexto deve ser escalável
(FIWARE FORGE, 2016b).
Abaixo, a Figura 4 demonstra a arquitetura do Orion Context Broker, expondo seus
componentes.
23
Figura 4 Arquitetura do OCB (FIWARE FORGE, 2016b)
A seguir é apresentada uma breve descrição desta arquitetura.
Os produtores de contexto são os sensores, que encaminham mensagens ao servidor
contendo dados coletados nos sensores em formato JSON através do método HTTP POST
usando a porta 1026.
O middleware atua recebendo todos os dados enviados a partir dos sensores. Como o
Orion é uma plataforma publish/subscribe, sua atuação consiste em registrar esses dados em
seu banco, verificar se há assinantes interessados que buscam estes dados, se confirmado, os
interessados se entram na lista de assinantes e a partir desta etapa já recebem as informações.
Os subscribers, consumidores de contexto, consultam os dados através de uma
interface, que lhe proporciona ter acesso a informação que parte do produtor de contexto
específico, podendo consultar mais de uma informação relativa ao contexto simultaneamente.
2.5.3 INTERFACE OMA NGSI
A especificação de gerenciamento de contexto NGSI (Next Generation Services
Interface) da Fiware trabalha baseada na especificação da OMA (Open Mobile Alliance)
(“Open Mobile Alliance”, 2017). Isto significa que assumem a forma de uma especificação de
ligação RESTFul entre duas interfaces definidas nas especificações OMA NGSI, nomeadas de
NGSI-9 e NGSI-10. Estas interfaces são definidas para troca de informações, onde a OMA
NGSI-10 é usada para trocar informações sobre entidades e seu atributo, ou seja, valores de
atributos e metadados. Já a interface OMA NGSI-9 é usada para informações de
disponibilidade sobre entidades e seus atributos.
24
Entretanto, as especificações do Gerenciamento de Contexto NGSI da Fiware não
implementam as partes de especificações OMA, que se mostra bastante robusta e com muitas
especificações não necessárias. A interface NGSI no Fiware trabalha com modelos básicos de
gerenciamento de contexto, que são (i) entidades, (ii) atributos, (iii) domínios de atributo e
(iv) elementos de contexto.
As entidades representam o aspecto central de informação NGSI-9/10. Na qual as
entidades são as representações virtuais de todos os tipos de objetos físicos do mundo real. As
entidades possuem um identificador e um tipo, como por exemplo, uma entidade virtual que
representa uma unidade produtiva tem identificador chamado “Viveiro” e o seu tipo
“ViveiroMonitorado”.
Qualquer informação disponível sobre entidades físicas é expressa sob a forma de
atributos de entidades virtuais. Os atributos também têm um nome e um tipo. Por exemplo, a
temperatura da água em um determinado local observado seria representada como um atributo
com o nome "temperatura" e o tipo "float" (ponto flutuante, representação de números reais).
Há também um conceito de domínios de atributos no OMA NGSI-9/10. Um domínio
de atributo agrupa logicamente um conjunto de atributos. Por exemplo, o domínio de atributo
"ponto_monitorado_status" pode incluir os atributos "temperatura" e "pressão" de um
determinado ponto monitorado.
A estrutura de dados utilizada para a troca de informações sobre entidades é
denominada: elemento de contexto. Um elemento de contexto contém informações sobre
vários atributos de uma entidade, mais detalhada na seção 2.5.4.
2.5.4 ENTIDADES DE CONTEXTO
Na plataforma Fiware, as informações contextuais são representadas através de
estruturas genéricas conhecidas como entidades de contexto. Uma entidade de contexto, pode
ser usada para representar de forma virtual, elementos do mundo real, tais como uma pessoa,
um lugar, um sensor.
Informações contextuais são organizadas por meio de elementos de contexto (context
elements). Um elemento de contexto pode possuir associado a si um conjunto de elementos
atributos de contexto (context element atributes) e metadados (meta-data). Entidades de
contexto devem possuir um identificador (EntityID) e um tipo (EntityType), essa tupla
25
<identificador, tipo> identifica de forma única uma entidade. Por exemplo, podemos criar
uma entidade de contexto do tipo pessoa, com identificador joao, outras entidades do tipo
pessoa não podem possuir o identificador joao (BATISTA et al., 2016). Como demonstrado
na Figura 5 abaixo.
Figura 5 Descrição do Elemento de Contexto (FIWARE FORGE, 2016b)
Informações que caracterizam uma entidade de contexto são representadas por meio
de atributos de contexto. Um atributo de contexto é uma tripla <nome, tipo, valor>. Por
exemplo, uma das informações que caracteriza a entidade joao pode ser a sua posição
geográfica, que pode ser representada por um atributo de contexto chamado localização, do
tipo geolocalização e com valor “5.8475293, -35.2079996” indicando que joao se encontra
em Natal -RN. (BATISTA et al., 2016)
Opcionalmente, um atributo de contexto pode possuir associado a si alguns metadados
que trazem informações contextuais relacionadas a um atributo, como por exemplo, a precisão
de seu valor, sua atualidade, etc. Metadados são representados pela tripla <nome, tipo, valor>.
Tomando como exemplo o atributo de contexto localização da entidade joao, a precisão de
seu valor poderia ser representada pelo metadado com nome precisão, do tipo inteiro e com
valor 20, indicando que a localização fornecida está sujeita a uma margem de erro de 20
metros. (BATISTA et al., 2016)
2.6 PARÂMETROS DA QUALIDADE DA ÁGUA
A qualidade da água é de extrema importância para o pleno desenvolvimento do
sistema produtivo, quanto melhor a qualidade da água, menos problemas nutricionais e de
doenças ocorrerão. Esta seção está dividida em subseções que fazem breves comentários
sobre alguns dos possíveis parâmetros observados.
2.6.1 TEMPERATURA DA ÁGUA
A temperatura da água influencia diretamente o rendimento dos sistemas de produção
de organismos aquáticos, portanto, é fundamental obter informações precisas sobre o clima
26
local e a hidrodinâmica dos reservatórios para decidir qual será o local mais indicado para a
implantação dos tanques-redes por exemplo. Um dos fatores observados é o resfriamento
noturno, que diminui a temperatura da água superficial, ocasionando a estratificação da
coluna d’água (EMBRAPA, 2003). A estratificação causa uma diferença significativa entre as
densidades das camadas de água superficial, mais quente, e a de fundo, mais fria, ocasionando
problemas de circulação na coluna d’água, e provocando variações bruscas nas concentrações
de oxigênio dissolvido (EMBRAPA, 2003). Afim de monitorar este parâmetro, a Figura 6
representa um modelo do sensor DS18B20 usado para coletar informações referentes a
temperatura da água.
Figura 6 Sensor DS18B20 de Temperatura (MAXIM, 2017)
2.6.2 OXIGÊNIO DISSOLVIDO EM ÁGUA
As principais fontes de oxigênio dissolvido na água são: a fotossíntese, a difusão do ar
através da interface ar e água, e a entrada de água nos reservatórios. A concentração de
oxigênio dissolvido nos reservatórios depende diretamente de fatores como: (a) presença de
matéria orgânica e nutrientes; (b) biomassa de macrófitas; (c) densidade de fitoplâncton; (d)
quantidade de sólidos em suspensão, dentre outros (EMBRAPA, 2003).
A redução brusca e repentina da concentração de oxigênio dissolvido é uma das
principais causas da mortalidade de peixes em grandes reservatórios, devido não só a
diminuição da sua concentração, como também em função do aumento na concentração de
gás carbônico, diminuição do pH e elevação da concentração de nitritos, o que geralmente
ocorre em dias nublados durante o verão. Nessas situações, esses fatores poderão
comprometer a estabilidade ambiental e causar sérios riscos em decorrência do estresse
causado nos peixes cultivados, podendo levá-los à morte. (EMBRAPA, 2003). A Figura 7
representa o sensor modelo SEN-11194 que coleta as informações referentes ao oxigênio
dissolvido na água.
27
Figura 7 Sensor SEN-11194 para Oxigênio Dissolvido na Água
2.6.3 PRESSÃO ATMOSFÉRICA
A pressão atmosférica é interpretada como a força exercida pela atmosfera sobre a
superfície em questão. Uma queda brusca na pressão atmosférica pode ocasionar a morte de
uma grande quantidade de peixes, pois os gases do fundo dos viveiros estão em equilíbrio, e
com a queda da pressão, desencadeia a liberação dos de uma só vez, como por exemplo, o gás
sulfídrico (H2S ou gás metano CH4). Estes gases são letais aos peixes na concentração de
0,1mg/l. (MARDINI; MARDINI, 2000). A Figura 8 exibe um sensor de avaliação pressão
barométrica BAROCAP (HOBECO, 2017).
Figura 8 Sensor de pressão atmosférica (HOBECO, 2017)
2.6.4 NITRITO
O Nitrito (NO2) é um composto intermediário do processo de nitrificação, durante o
qual a amônia é oxidada para nitrito, logo após, para nitrato (NO3) pela ação das bactérias
Nitrosomonas e Nitrobacter. (MARDINI; MARDINI, 2000). Este composto é encontrado em
baixas concentrações, notadamente, em ambientes oxigenados. A nitrificação é um processo
28
predominantemente aeróbico e, como tal, ocorre somente nas regiões onde há oxigênio
dissolvido, geralmente, na coluna d’água e na superfície do sedimento do viveiro
(hipolimnio). (MARDINI; MARDINI, 2000).
Se houver um aporte de matéria orgânica fresca no fundo do viveiro (esterco), a
demanda deste material por oxigênio poderá causar condições anaeróbicas na superfície do
solo do viveiro, prejudicando o desempenho da bactéria do gênero Nitrobacter. Isso favorece
o acúmulo do nitrito na água de cultivo, podendo causar massiva mortandade de peixes.
(MARDINI; MARDINI, 2000). A concentração segura para o nitrito na água de cultivo é
abaixo de 0,5 mg/l. (MARDINI; MARDINI, 2000). A Figura 8 representa o sensor: Ion
Sensor Probes “PRO” que coleta dados de taxa de nitrito na água.
Figura 9 Sensor para Nitrito
29
3. ARQUITETURA DO SISTEMA
Conforme apresentado na introdução, este trabalho tem como o objetivo o
desenvolvimento de uma aplicação que proporcione a diferentes tipos de dispositivos, que
possuam acesso a uma interface web, a leitura de dados que são coletados por diversos tipos
dispositivos sensores. Dados estes que são enviados anteriormente a uma plataforma
middleware, que recebe os dados e disponibiliza a consulta e leitura de forma estruturada.
Para atingir o objetivo, esse capítulo apresenta a arquitetura da aplicação
desenvolvida. A arquitetura proposta é apresentada em quatro camadas seguindo o estilo
arquitetural em camadas, a saber: Produtores de contexto, Middleware, Interface do Cliente e
Consumidores de contexto, conforme ilustrado na Figura 10.
Para este desenvolvimento foi utilizado a plataforma middleware: Orion Context
Broker, servindo como intermediador na comunicação realizada entre dispositivos sensores,
denominados produtores de informação de contexto, com os dispositivos consumidores destas
informações, usuários finais através de uma interface web. A comunicação é realizada
baseada no protocolo HTTP RESTful afim de proporcionar a comunicação entre todos os
dispositivos independente de sua arquitetura ou protocolo de comunicação.
Figura 10 Arquitetura do Sistema
30
A Figura 10 apresenta a arquitetura da solução desenvolvida, em quatro camadas. Na
camada de Produtores de Contexto (Publisher) estão presentes todos produtores de
informação de contexto, ou seja, sensores que atuam captando diversos comportamentos de
uma unidade produtiva. Cada sensor tem a função de oferecer a Camada Middleware as
informações, sem interrupção, que são coletadas. De forma escalável, esta camada pode
suportar a inclusão de novos sensores e transmitir novas informações de contexto sem
prejudicar as anteriores.
A Camada Middleware é onde está localizado o Orion Context Broker (OCB),
juntamente com o armazenamento das informações produzidas pela camada de Produtores de
Contexto. A informações de contexto são armazenadas no banco de dados (MongoDB) e
disponibilizadas para o gerenciamento do OCB. Já o OCB, realizará o controle das
informações de contexto, tratando de receber as requisições dos consumidores como também
o recebimento das informações produzidas pelos produtores de contexto, e disponibilizadas
tais informações a qualquer consumidor de contexto que buscar determinada informação. O
OCB trabalha de forma que as informações sejam tratadas independente da tecnologia que a
busca, convergindo assim ao tratamento da heterogeneidade de informações.
A funcionalidade da camada de Interface do Cliente consiste em prover uma página
web de interface intuitiva. Propõe-se ser o portal de comunicação entre os consumidores de
contexto, OCB e os produtores de contexto, tornando esta comunicação totalmente
transparente ao usuário. Permitindo que o usuário possa personalizar sua forma de análise da
informação através da tecnologia de mashups, proporcionando melhor visualização das
informações de contexto a qual deseja analisar.
Por fim, a camada de Consumidores de Contexto (Subscribers), que representa a
camada dos usuários finais de todo o processo. O usuário consumidor da informação de
contexto, através da interface do cliente, irá realizar uma busca da informação que deseja
obter no momento, onde, uma vez consultado o fator assinatura será ativado e o usuário
receberá as informações de forma contínua até o mesmo encerrar o processo. Nesta camada se
encaixam todos os dispositivos que possuam acesso à internet e que tenha acesso a Interface
do Cliente.
31
3.1. IMPLANTAÇÃO
Esta seção apresenta como foi realizada a implantação de cada uma das camadas
apresentadas anteriormente no capítulo 3.
Figura 11 Diagrama de Implantação do Trabalho
Os sensores são implantados em plataformas embarcadas como: Arduino (“Arduino”,
2017), Raspbarry Pi (“Raspberry Pi”, 2017) e NodeMCU (“NodeMcu”, 2017). A implantação
dos nós sensores é realizada via porta serial (COM3, por exemplo) através do ambiente de
programação Arduino IDE (Figura 12).
Figura 12 Escolha da porta de comunicação do sensor
A definição da plataforma embarcada também é definida no mesmo ambiente de
programação. No exemplo da Figura 12 é definido a plataforma: ESP8266 NodeMCU ESP-
32
12E, devido ao seu módulo Wi-Fi, ele pode suportar redes (802.11 b/g/n) (FONSECA, 2009),
preparado para comunicação sem fio de baixa potência, operando com frequência de 2.4GHz,
possuindo suporte a WPA e WPA2 (DEMARTINI, 2013), ambos padrões de comunicação
Wi-Fi.
O ambiente que suporta tecnologicamente o middleware é a distribuição CentOS 6.x,
que nada mais é que abreviação de (Community ENTerprise Operating System), é uma
distribuição Linux (LINUX.COM, 2017) de classe corporativa derivada de códigos fonte
gratuitamente distribuídos pela Red Hat (“Red Hat Enterprise Linux”, 2017) e mantida pelo
CentOS Project (CENTOS, 2017). Trata-se de um ambiente “oficialmente suportado”.
Para a virtualização do middleware em um servidor local, foi utilizado a ferramenta
Docker (“What is Docker?”, 2017), uma plataforma de container que auxilia na construção,
gerenciamento e proteção de aplicativos. O Docker é uma ferramenta recomendada na própria
documentação da Fiware quando se opta pelo servidor local ao implementar o middleware.
Figura 13 Interface do Docker (Windows)
A inicialização da virtualização dá-se ao comando “Up” no local em que a imagem do
OCB estiver localizada, a partir deste momento o sistema operacional contendo o middleware
e o banco de dados é iniciado contendo seu próprio endereço de rede.
Figura 14 Iniciando a virtualização do OCB
33
3.2 IMPLEMENTAÇÃO
Esta seção aborda a principais fases da implementação dos componentes pertencentes
as diferentes camadas da solução proposta. As fases estão subdivididas em: (i) implementação
um produtor de informação de contexto; (ii) atualização da informação de contexto e (iii)
consulta das informações existentes.
A Figura 15 demonstra um diagrama de sequência que apresenta o modelo de
funcionamento básico da comunicação entre os nós sensores, middleware e a interface web:
Figura 15 Sequência de comunicação
O nó sensor coleta a informação de contexto de uma determinada unidade produtiva que
em seguida é enviada através de HTTP ao middlware, por sua vez o middleware armazena as
informações em seu banco de dados, tornando estas informações disponíveis as requisições
HTTP dos usuários inscritos através da interface web, caso não possua usuários assinantes, as
informações se mantem armazenadas.
3.2.1 ENVIO DE INFORMAÇÕES AO MIDDLEWARE
Para o envio de dados ao middleware, é utilizada a curl (“Curl”, 2017), ferramenta de
linha de comando para sistemas operacionais que obtém ou envia documentos/arquivos de,
como também, para servidores. Esta ferramenta tem como característica principal o suporte a
vários protocolos de comunicação como HTTP, IMAP, POP3, FTPS e etc. A utilização curl
dá-se porque é quase onipresente em qualquer sistema GNU / Linux, e como o broker atua
com a distribuição CentOS, é a ferramenta recomendada pela documentação da Fiware. No
entanto ferramenta curl, não é obrigatória, tanto que é possível usar qualquer cliente REST.
34
Os padrões básicos para qualquer implementação da ferramenta curl presente na
documentação da Fiware seguem a mesma metodologia arquitetural do REST. Como
demonstrado abaixo:
Tabela 2 Padrões básicos da ferramenta curl
3.2.2 IMPLEMENTAÇÃO DE UM PRODUTOR DE INFORMAÇÃO CONTEXTO
O middleware deve tornar-se consciente da existência de uma unidade produtora de
contexto, ou seja, a unidade que conterá os sensores. Neste trecho, é exemplificada a criação
da entidade Viveiro1, que representa uma unidade produtiva, possuindo os seguintes
atributos: temperatura, taxa de oxigênio dissolvido, concentração de nitrito e pressão. A
criação dá-se executando o método HTTP POST para a URI: /v2/entities, contendo as
informações em JSON conforme a Figura 16.
Figura 16 Criação de Unidade Produtora de Informação Contexto
35
É demonstrado nesta implementação que além dos campos id que identifica o viveiro,
como também, seu tipo (type) que o caracteriza, também há os conteúdos referentes aos
atributos, os quais representam os valores que são coletados dos sensores.
A Figura 17 demonstra a implementação de uma unidade produtora de contexto
através da plataforma Arduino IDE:
Figura 17 Criação de PIC através do Arduino IDE
A partir da criação de uma unidade produtora de contexto, a Figura 18 demonstra
middleware é registrando a informação de contexto em seu banco de dados interno, o valor
atual sempre será substituído a cada nova atualização, este processo é realizado de forma
assíncrona.
Figura 18 Sequencia que segue a criação
36
3.2.3 ATUALIZAÇÃO DA INFORMAÇÃO DE CONTEXTO
A informação de contexto é atualizada constantemente, enviando a coleta do produtor
de informação ao middleware através do método HTTP PUT respeitando o tempo
determinado no momento da implementação.
Figura 19 Atualização da Informação de Contexto
O código da Figura 19 demonstra que as variáveis do método representam o valor do
sensor (data), o próprio sensor (temp), como também o endereço host e a porta (port) a qual o
middleware está implantado. Logo substituindo estes valores, e conservando a estrutura,
demais sensores podem ser implementados através deste código na plataforma Arduino IDE.
3.2.4 CONSULTA DO CLIENTE AS INFORMAÇÕES COLETADAS
A consulta das informações de contexto existentes, são possíveis através de uma
requisição executada por qualquer aplicação que a use o verbo HTTP GET. Visando acessar
as informações de contexto armazenadas pelo OCB, a consulta é realiza da seguinte forma na
URI:
• Para consultar o Viveiro 1:
curl localhost:1026/v2/entities/Viveiro1
37
Onde:
Figura 20 Consulta do cliente ao middleware
Desta forma, é realizada uma consulta do cliente ao middleware que irá exibir a
informação referente em seu banco de dados. Na qual, neste exemplo entregará ao cliente a
seguinte informação conforme a Figura 21:
Figura 21 Resposta JSON a consulta
38
A interface web é desenvolvida para que estas informações JSON sejam organizados e
proporcionem uma leitura intuitiva ao usuário assinante que realizar a requisição. A Figura 22
exibe um modelo da interface do cliente.
Figura 22 Resultado da consulta do Cliente
Desta forma, quando houver mais de uma unidade produtora de contexto implantada
em uma unidade produtiva, as informações possam ser organizadas e listadas para facilitar a
leitura. Como também divididas em unidades produtivas aplicando a possibilidade de o
usuário possuir várias unidades produtivas.
39
4. AVALIAÇÃO
Este capítulo apresenta a avaliação da solução desenvolvida através uma prova de
conceito e de cenários de mudança que buscam refletir atividades básicas que podem ocorrer
em um cenário real. A seção 4.1 apresenta a tela inicial da interface web com os seguintes
cenários: (i) adição de um sensor; (ii) leitura da informação de contexto do sensor; (iii) leitura
de posição geográfica. Na Seção 4.2 é provocado a adição e remoção de produtores de
informação de contexto, seguindo os parâmetros impostos pela interface NGSI, afim de
avaliar o comportamento do sistema nestes cenários. A seção 4.3 trata da análise dos
resultados.
Os métodos realizados para criação, remoção e atualização das informações de
contexto, foram executados através de um cliente REST, denominado ARC (Advanced REST
Client) (“Advanced REST client for Google Chrome”, 2017), este cliente é uma extensão do
navegador Google Chrome (GOOGLE, 2017) e favorece a esta seção permitindo injetar e
receber dados através de métodos HTTP de diversos tipos de sensores não presentes
fisicamente na ocasião.
4.1 INTERFACE WEB
No primeiro acesso, o usuário deverá cadastrar o seu perfil. Haja vista, como
demonstrado na Figura 23, a interface web tem seu ponto de partida sem nenhuma informação
salva, podendo ser personalizada da forma que mais se adeque ao cenário.
Figura 23 Interface Web no Primeiro Acesso
40
4.1.1 CRIANDO UM PERFIL DE USUÁRIO
A Figura 24, mostra o campo de cadastro de novo perfil, o qual solicita informações
importantes para a personalização do perfil do usuário da interface web. A principal
informação no ato do cadastro é o local o qual o middleware está implementado
(hostname/ip), pois este campo é o que vai servir como identificador do perfil, independente
do nome de perfil informado. Neste trabalho, não houve a possibilidade de alocar o OCB em
uma unidade em nuvem, portanto é utilizado um servidor local (localhost) para hospedar a
ferramenta OCB tanto quanto a interface web.
Figura 24 Cadastro de Novo Perfil
4.1.2 LEITURA DAS INFORMAÇÕES DE CONTEXTO
A seguir, é exibida a interface web com o perfil nomeado como: “Fazenda Modelo –
EAJ - 01”. Neste perfil é apresentando unidades cadastradas, com também, os respectivos
resultados dos geradores de informação de contexto. A Figura 25, por exemplo, mostra a
unidade produtiva nomeada como “FazendaModelo1” exibindo o valor do produtor de
informação de contexto: “Temperatura”, o qual exibe o valor da informação de contexto
coletada até a última atualização.
41
Figura 25 Unidade Cadastrada
4.1.3 LEITURA DA POSIÇÃO GEOGRÁFICA
A Figura 26 exibe a posição geográfica a qual determinada unidade produtiva está
posicionada, esta informação é encontrada no momento em que o menu localização é
selecionado, bastando o usuário acessar este menu e logo em seguida escolher a unidade a
qual deseja, onde mais uma vez é demonstrada a unidade produtiva “FazendaModelo1” e seu
respectivo e único produtor de informação de contexto “Temperatura”.
Figura 26 Posição Geográfica de um Produtor Informação de Contexto
42
4.2 CRIAÇÃO DE UM NOVO PRODUTOR DE CONTEXTO
Nesta seção, é demonstrado através da plataforma Arduino e um cliente REST,
simulando hardwares distintos, como é realizada a adição e remoção de um produtor de
informação de contexto em uma determinada unidade produtiva. Onde a subseção 4.2.1 trata
da adição de novos sensores e a subseção 4.2.2 que trata da remoção de um sensor, atividades
baseadas na realidade voltadas a avaliar a escalabilidade e estabilidade do middleware.
4.2.1 NOVO PRODUTOR DE INFORMAÇÃO DE CONTEXTO (SENSOR)
Dada a necessidade do monitoramento da qualidade da água de uma produção, esta
subseção busca simular a implantação de dispositivos sensores a uma determinada unidade
produtiva, visando avaliar o comportamento do sistema como um todo.
A criação de um novo produtor de contexto, é realizado através do método HTTP
POST, que deve seguir corretamente as recomendações e exigências da interface NGSI, a
Figura 27 demonstra a adição de um novo sensor, que avalia a taxa de nitrato em água, na
unidade “FazendaModelo1”:
Figura 27 Adição de novo sensor a unidade produtiva via plataforma Arduino
Ao realizar este procedimento, atualizando do dashboard, é exibido o seguinte layout
(Figura 28). Sua posição geográfica tanto quanto seus valores foram adicionados à interface.
43
Figura 28 Layout da Interface com Produtor de Contexto Criado
Simulando a adição de outro sensor, desta vez é utilizado um cliente REST. Onde um
sensor de taxa de oxigenação da água é adicionado ao middleware (Figura 29).
Figura 29 Adição de sensor de taxa de oxigênio via cliente REST
Logo a interface exibe o resultado conforme a Figura 30:
44
Figura 30 Nova produtores de contexto adicionados
4.2.3 REMOÇÃO DE UM PRODUTOR DE INFORMAÇÃO DE CONTEXTO
A remoção de uma sensor é realizada através do método HTTP DELETE
(v2/entities/id?type=Type), onde em sua URI é necessário informar o id e type que o
identifica perante os demais produtores de informação de contexto. Simulando o
cancelamento de assinatura com um determinado sensor, a Figura 31 exibe através de um
cliente REST o comportamento após a remoção do sensor.
Figura 31 Remoção de produtor de Contexto via cliente REST
45
Após a próxima atualização, o painel que antes exibia 3 sensores cadastrados, exibirá
somente os valores referentes aos sensores o qual está com assinatura. Os demais sensores não
sofreram mudanças, atingindo assim, os resultados esperados.
4.3 ANALISE DE RESULTADOS
Esta seção trata da análise de resultados, conjectura que aborda os resultados e
avaliações obtidas após a implementação e prática dos processos realizados.
O middleware OCB agiu conforme o esperado, onde diversos dispositivos foram
adicionados e trabalhados simultaneamente quando seguido corretamente os requisitos
sugeridos pela interface NGSI e o protocolo HTTP. Estando a todo momento disponível e
sem falhas quanto sua escalabilidade e seguro quanto ao seu banco de dados.
Neste trabalho foi demonstrado cenários de mudanças, como a adição e remoção de
produtores de informação de contexto em uma unidade produtiva, o middleware em conjunto
dos sensores a interface web atingiram a expectativas. Desta forma, a interface web pôde
atingir seu propósito que era exibir ao usuário informações sobre sua unidade produtiva de
forma organizada e intuitiva.
Em hipótese, a proposta de utilizar o OCB atinge as expectativas iniciais do projeto
agindo conforme esperado nos requisitos de interoperabilidade, escalabilidade e estabilidade.
A disponibilidade dos sensores vai depender da configuração a qual o usuário optará para sua
unidade produtiva, já que diversos cenários podem ser constituídos, logo é um ponto bastante
subjetivo. Já a interface web, qualquer dispositivo com acesso à internet e navegador poderá
acessá-lo para acompanhar em tempo real a sua unidade produtiva, permitindo se adequar a
qualquer resolução devida sua implementação responsiva.
46
5. CONSIDERAÇÕES FINAIS
A utilização de uma ferramenta middleware servindo de intermediador entre a
comunicação de nós sensores e uma interface web demonstra-se bastante atrativa, uma vez
que diversos sensores possuem suas particulares formas de coletar dados, porém em muitos
dos casos não possuem formas de exibi-las em conjunto. Centralizar estas informações em um
local de fácil acesso e genérico é supostamente uma maneira de reduzir o impacto do excesso
de dispositivos.
O middleware OCB possui características e arquitetura voltadas para o trabalho da
internet das coisas (IoT), desta forma permitindo-se receber informações de diversos tipos de
dispositivos favorecendo o monitoramento para qualquer objetivo. Este trabalho foi motivado
pelo conceito de smartfarm, onde é proposto o uso do middleware como ferramenta
intermediadora para o monitoramento de uma unidade produtiva da aquicultura, observando
valores referentes aos seus respectivos produtores de contexto.
Entende-se que a utilização deste middleware juntamente com o avanço do conceito
smartfarm, possa proporcionar ainda mais um avanço significativo dado a sua disponibilidade
e baixo custo.
5.1 LIMITAÇÕES
Em seu estado atual, a interface web desenvolvida possui algumas limitações, sendo as
principais:
(i) O habilitador genérico da Fiware: Orion Context Broker, que atua como
middleware neste trabalho, não possui em seu escopo um banco de dados que
registre dados históricos de todas as suas consultas;
(ii) Apesar de termos resultados funcionais, a complexidade de implementação do
middleware em conjunto ao sensor e ao desenvolvimento da interface web,
torna necessário a utilização da aplicação em campo para resultados mais
próximos da realidade;
(iii) A criação de geradores de unidade de contexto não possui mecanismos de
descoberta automática, tornando necessário informar manualmente os dados
iniciais da unidade geradora de contexto.
47
(iv) Os valores dos produtores de informação de contexto foram gerados de forma
randômica por não possuir no momento os sensores exemplificados.
5.2 TRABALHOS FUTUROS
Diante do exposto neste trabalho a grande abrangência da plataforma Fiware, diversos
trabalhos futuros poderão ser desenvolvidos. Como por exemplo, permitir uma consulta
histórica de todos os dados de contexto gerados pelos sensores a partir do momento de sua
criação. Alguns desafios envolvem esta implementação como: a criação de um serviço web
que realize consultas constantes a unidade geradora de contexto, colete estas informações e as
armazenes em um outro banco de dados.
Outro trabalho futuro bem importante diz respeito a descoberta automática de
geradores de contexto (sensores). Atualmente, os dados dos serviços são pré-cadastrados no
middlware e a composição fica restrita a estes comandos, via plataforma de desenvolvimento
ou clientes REST, os quais requerem toda uma configuração baseada na interface NGSI.
48
REFERÊNCIAS
Academia FIWARE. Disponível em: <http://edu.fiware.org/>. Acesso em: 20 ago. 2017.
ADHIANTO, L. et al. Meeting subsctiber-defined QoS constraints in publish/subscribe
systems. Concurrency Computation Practice and Experience, v. 22, n. 6, p. 685–701,
2010.
Advanced REST client for Google Chrome. Disponível em:
<https://advancedrestclient.com/>. Acesso em: 13 nov. 2017.
AGROCAMPO. Agricultura de Precisão: a tecnologia aliada ao produtor rural.
Disponível em: <http://revistaagrocampo.com.br/agricultura-de-precisao/>. Acesso em: 7 out.
2017.
Arduino. Disponível em: <https://www.arduino.cc/>. Acesso em: 15 nov. 2017.
BATISTA, T. et al. SmartMetropolis - Plataformas e Aplicações para Cidades Inteligentes. p.
47, 2016.
BENFIELD, E. F. et al. Influence of Exposure Technique on Leaf Breakdown Rates in
Streams. Oikos, v. 33, n. 3, p. 386, 1979.
Big Data in Smart Farming – A review. Agricultural Systems, v. 153, p. 69–80, 1 maio
2017.
CENTOS. CentOS Project. Disponível em: <https://www.centos.org/>. Acesso em: 9 nov.
2017.
Curl. Disponível em: <https://curl.haxx.se/docs/manpage.html>. Acesso em: 11 fev. 2017.
DEMARTINI, F. WEP, WPA, WPA2: o que as siglas significam para o seu WiFi?
Disponível em: <https://www.tecmundo.com.br/wi-fi/42024-wep-wpa-wpa2-o-que-as-siglas-
significam-para-o-seu-wifi-.htm>. Acesso em: 16 nov. 2017.
EMBRAPA. República Federativa do Brasil Embrapa Meio Ambiente. 2003.
FAPEAM. Piscitech - Equipamento de baixo custo controla temperatura e qualidade da
água em tanques de piscicultura. Disponível em:
<http://www.fapeam.am.gov.br/equipamento-controla-temperatura-e-qualidade-da-agua-em-
tanques-de-piscicultura/>. Acesso em: 13 out. 2017.
FEHRENBACHER, D. D.; DJAMASBI, S. Information systems and task demand: An
exploratory pupillometry study of computerized decision making. Decision Support
Systems, v. 97, p. 1–11, maio 2017.
FICHTER, D. What Is a Mashup? 2007.
FIELDING, R. T. Architectural Styles and the Design of Network-based Software
49
Architectures. Disponível em:
<https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>. Acesso em: 14 nov. 2017.
FIWARE. Business Framework Consumption. 2017.
FIWARE FORGE. NGSI-9/NGSI-10 information model - FIWARE Forge Wiki.
Disponível em: <https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/NGSI-
9/NGSI-10_information_model>. Acesso em: 12 nov. 2017a.
FIWARE FORGE. FIWARE. Disponível em:
<https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecificati
on.Data.ContextBroker>. Acesso em: 20 ago. 2017b.
FIWARE FORGE. FIWARE. Disponível em:
<http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Welcome_to_the_FI-
WARE_Wiki>. Acesso em: 20 ago. 2017.
FONSECA, W. Wireless: diferenças entre as gerações b, g e n. Disponível em:
<https://www.tecmundo.com.br/internet/2764-wireless-diferencas-entre-as-geracoes-b-g-e-
n.htm>. Acesso em: 16 nov. 2017.
GEORGE COULOURIS. Sistema distribuídos: conceitos e projeto. [s.l: s.n.]. v. 0
GOOGLE. Google Chrome. Disponível em:
<https://www.google.com.br/chrome/browser/desktop/index.html>. Acesso em: 14 nov. 2017.
HOBECO. BAROCAP. Disponível em: <http://www.hobeco.net/content/sensor-de-pressao-
atmosferica-barocap>. Acesso em: 16 nov. 2017.
LINUX.COM. What is Linux? Disponível em: <https://www.linux.com/what-is-linux>.
Acesso em: 9 nov. 2017.
MARDINI, C.; MARDINI, L. Cultivo de Peixes e Seus Segredos. Disponível em:
<https://books.google.com.br/books?id=cVuP6-9GBk8C&printsec=frontcover&hl=pt-
BR#v=onepage&q&f=false>. Acesso em: 20 ago. 2017.
MAXIM. DS18B20. Disponível em: <https://www.makerlab-
electronics.com/product/waterproof-temperature-sensor-ds18b20/>. Acesso em: 18 nov. 2017.
MEOLA, A. Why IoT, Big Data & Smart Farming Are the Future of Agriculture -
Business Insider. Disponível em: <http://www.businessinsider.com/internet-of-things-smart-
agriculture-2016-10?es_p=2791926>. Acesso em: 11 nov. 2017.
MÜHL, G.; BUCHMANN, A. P.; BACON, J. M. Large-Scale Content-Based
Publish/Subscribe Systems. 2002.
NodeMcu. Disponível em: <http://www.nodemcu.com/index_en.html>. Acesso em: 15 nov.
2017.
50
Open Mobile Alliance. Disponível em: <http://www.openmobilealliance.org/wp/>. Acesso
em: 12 nov. 2017.
PAPAZOGLOU, M. P. Service -Oriented Computing : Concepts , Characteristics and
Directions. 2003.
PAPAZOGLOU, M. P. et al. Service-Oriented Computing Research Roadmap Service-
Oriented Computing Research Roadmap. n. April, p. 1–29, 2006.
PAPAZOGLOU, M. P. et al. Service-Oriented Computing: State of the Art and Research
Challenges. Computer, v. 40, n. 11, p. 38–45, nov. 2007.
PATIL, A.; RAJESH, K.; SABHARWAL, K. Comparison of Middleware Technologies -
CORBA , RMI & COM/DCOM. p. 1–27, 2011.
PORTAL BRASIL. Aquicultura tem potencial para dobrar produção em cinco anos
Produção Nacional. Disponível em: <http://www.brasil.gov.br/economia-e-
emprego/2015/06/aquicultura-tem-potencial-para-dobrar-producao-em-cinco-anos>. Acesso
em: 15 out. 2016.
Raspberry Pi. Disponível em: <https://www.raspberrypi.org/>. Acesso em: 15 nov. 2017.
Red Hat Enterprise Linux. Disponível em: <https://www.redhat.com/pt-
br/technologies/linux-platforms/enterprise-linux>. Acesso em: 9 nov. 2017.
RICHARDSON, L.; RUBY, S. RESTful Web Services. [s.l: s.n.].
SAMPAIO, E. V. D. S. B.; COSTA, T. L. DA. Revista Brasileira de Geografia Física.
Revista Brasileira de Geografia Física, v. 6, p. 1275–1291, 2011.
SAUDATE, A. Rest: Construa API’s inteligentes de maneira simples. [s.l.] Casa do
Código, 2014.
SPRING. Understanding REST. 2017.
The Smart City Concept in the 21st Century. Procedia Engineering, v. 181, p. 12–19, 1 jan.
2017.
TUTORIALSPOINT. What are Web Services. Disponível em:
<https://www.tutorialspoint.com/webservices/what_are_web_services.htm>. Acesso em: 12
out. 2017.
UNRIC. ONU projeta que população mundial chegue aos 8,5 mil milhões em 2030.
Disponível em: <http://www.unric.org/pt/actualidade/31919-onu-projeta-que-populacao-
mundial-chegue-aos-85-mil-milhoes-em-2030>. Acesso em: 3 dez. 2016.
VINATEA, L. Aquicultura. Disponível em:
<http://www.panoramadaaquicultura.com.br/paginas/Revistas/30/evolucao.asp>. Acesso em:
12 out. 2017.
51
WEI, Y.; BLAKE, M. B. Service-Oriented Computing and Cloud Computing: Challenges and
Opportunities. IEEE Internet Computing, v. 14, n. 6, p. 72–75, nov. 2010.
What is Docker? Disponível em: <https://www.docker.com/what-docker>. Acesso em: 13
nov. 2017.
