86
CRISTIANA OGAWA MATSUBAYASHI, LUIS FELIPE TICIANELI FERREIRA, MATHEUS BARROS MANINI Sistema IoT para controle de estoque São Paulo (2015)
| Date post: | 23-Nov-2023 |
| Category: |
Documents |
| Upload: | independent |
| View: | 0 times |
| Download: | 0 times |
CRISTIANA OGAWA MATSUBAYASHI, LUIS FELIPE TICIANELI FERREIRA, MATHEUS BARROS MANINI
Sistema IoT para controle de estoque
São Paulo
(2015)
CRISTIANA OGAWA MATSUBAYASHI, LUIS FELIPE TICIANELI FERREIRA, MATHEUS BARROS MANINI
Sistema IoT para controle de estoque
Trabalho de Conclusão de Curso apresentado à Escola Politécnica da
Universidade de São Paulo para obtenção do título de Bacharel em Engenharia
Orientador: Prof. Dr. Sérgio Takeo Kofuji
São Paulo
(2015)
2
CRISTIANA OGAWA MATSUBAYASHI, LUIS FELIPE TICIANELI FERREIRA, MATHEUS BARROS MANINI
Sistema IoT para controle de estoque
Trabalho de Conclusão de Curso apresentado à Escola Politécnica da
Universidade de São Paulo para obtenção do título de Bacharel em Engenharia
Área Concentração: Internet das Coisas
Orientador: Prof. Dr. Sérgio Takeo Kofuji
São Paulo
(2015)
3
AGRADECIMENTOS
A conclusão deste projeto não foi apenas mérito do grupo, como também
de algumas pessoas que nos auxiliaram e guiaram durante a etapa de
desenvolvimento. Não teríamos concluído este projeto, sem o empenho e
incentivo dos professores e auxiliares da disciplina Projeto de Formatura da
Escola Politécnica da Universidade de São Paulo. Somos muito gratos ao
professor Sergio Takeo Kofuji, que aceitou dedicar seu tempo para orientar o
grupo.
Agradecimentos especiais para os familiares do grupo que sempre
apoiaram e acreditaram no trabalho de formatura, mesmo desconhecendo o
tema.
Aos auxiliares técnicos da Escola Politécnica, Luis, Adriano e Jair que
contribuíram no desenvolvimento do projeto, estando sempre abertos para
esclarecer dúvidas e ajudar a resolver algum problema.
4
RESUMO
O presente trabalho de conclusão de curso tem por objetivo apresentar
uma aplicação dos conceitos de Internet das Coisas no dia-a-dia das pessoas.
Esta aplicação consiste em um monitoramento remoto de três variáveis de um
recipiente: temperatura, umidade e concentração de gás amônia com o intuito de
evitar o apodrecimento dos alimentos bem como a ingestão de alimentos
estragados. Através de conceitos estudados, análise da tecnologia atual e
realização de uma grande variedade de testes com sensores e diferentes
padrões de comunicações para o sistema de IoT, foram definidas as tecnologias
a serem utilizadas e os componentes a serem comprados para o
desenvolvimento do produto. Esta tese apresenta tanto o processo de criação
quanto o resultado do trabalho: o protótipo dessa aplicação de Internet das
Coisas, o qual possui o nome comercial de SK-Control.
Palavras-chave: trabalho de conclusão de curso, Internet das Coisas,
monitoramento, alimentos, sensor
5
ABSTRACT
This present course conclusion work aims to present an application of
Internet of Things concepts in day-to-day lives. This application consists of a
remote monitoring of three variables in a container: temperature, umidity and
ammonia gas concentration in order to avoid food deterioration as well as
ingestion of spoiled food. Through the concepts studied, analysis of the current
technology and execution of a large variety of tests with sensors and different
communications standards for IoT, the technologies to be used and the
components to be purchased for the product development were defined. This
thesis presents both the creation process and the result of the work: the
prototype of the chosen Internet of Things application, which was given a
commercial name of SK-Control.
Keywords: course conclusion work, Internet of Things, monitoring, food, sensor
6
LISTA DE TABELAS
Table 1 - Requisitos de marketing e engenharia 34
Table 2 - Tabela de conceitos 36
Table 3 - Tabela de conceitos reavaliada 36
Table 4 - Avaliação: sistemas oepracionais 37
Table 5 - Avaliação: sensores de comunicação 38
Table 6 - Avaliação: sensores de variáveis de controle 38
Table 7 - Avaliação: sistemas operacionais embarcados 38
Table 8 - Avaliação: protocolos de comunicação 39
Table 9 – Tabela de riscos 40
Table 10 – Tabela de comparação Arduino e Yocto Linux 44
Table 11 – Avaliação: plataforma de comunicação 69
7
LISTA DE ABREVIATURA E SIGLAS
API Application Program Interface
CPU Central Processing Unit
DDR Double Data Rate
DVD Digital Video Disk
IoT Internet of Things
RAM Random-Access Memory
TCP Transmission Control Protocol
TV Televisão
UDP User Datagram Protocol
PaaS Platform as Service
8
SUMÁRIO
AGRADECIMENTOS 4
RESUMO 5
ABSTRACT 6
LISTA DE TABELAS 7
LISTA DE ABREVIATURA E SIGLAS 8
1 DEFINIÇÃO DO PROBLEMA 12
1.1 MOTIVAÇÃO 12
1.2 OBJETIVOS DO PROJETO 14
2 ESTADO DA ARTE E TRABALHOS RELACIONADOS 15
2.1 VISÃO GERAL 15
2.2 REVISÃO DA LITERATURA 15
2.2.1 IMPLEMENTATION OF A SMART FRIDGE BY USING RFID AND WEB TECHNOLOGY[1] 15
2.2.2 THE PERVASIVE FRIDGE[2] 16
2.2.3 A RFID/NFC FUSION BASED SMART REFRIGERATOR FOR WELLNESS SERVICE[3] 17
2.2.4 INTERNET REFRIGERATOR - A TYPICAL INTERNET OF THINGS[4] 17
2.3 ESTADO DA ARTE E TRABALHO 18
2.3.1 REFRIGERADORES INTELIGENTES 18
2.4 TECNOLOGIAS RELEVANTES 19
2.4.1 FRAMEWORK DE INTERNET OF THINGS 19
2.4.2 RFID 19
2.4.3 MQTT 20
2.4.4 INTEL EDISON 20
2.4.5 IBM BLUEMIX 20
9
2.4.6. GOOGLE APIS 22
2.4.7 ANDROID 22
2.4.8 BIBLIOTECAS C++ 24
2.5 ÁRVORE DE OBJETOS 26
2.6 DECOMPOSIÇÃO FUNCIONAL 29
2.7 VISÃO GERAL DO PROJETO 31
3 ESPECIFICAÇÃO DE REQUISITOS 32
3.1 REQUISITOS DE ENGENHARIA (PESO DE 1 A 5) 32
3.1.1 DESEMPENHO (PESO 4) 32
3.1.2 FUNCIONALIDADE (PESO 5) 32
3.1.3 CONFIABILIDADE E DISPONIBILIDADE (PESO 3) 32
3.1.4 ENERGIA (PESO 2) 32
3.1.5 AMBIENTAL (PESO 1) 33
3.1.6 ECONÔMICO 33
3.2 ENUMERAÇÃO DOS REQUISITOS PRINCIPAIS DE MARKETING 33
3.3 TABELA DE REQUISITOS 33
3.4 HOUSE OF QUALITY 34
4 ANÁLISE DE VIABILIDADE 35
4.1 LEQUE DES CONCEITOS INICIAIS 35
4.2 TABELA DE CONCEITOS 36
4.3 SISTEMA OPERACIONAL SMARTPHONE 37
4.3 SENSOR DE COMUNICAÇÃO COM OBJETOS 37
4.4 SENSOR DE VARIÁVEIS DE CONTROLE 38
4.5 SISTEMA OPERACIONAL EMBARCADO 38
4.6 PROTOCOLO DE COMUNICAÇÃO 39
5 ANÁLISE DE RISCO 40
5.1 RISCOS 41
6 CRONOGRAMA 42
7 DESENVOLVIMENTO DO PROJETO 43
10
7.1 HARDWARE E SENSORES 43
7.1.1 HARDWARE 43
7.1.2 MÓDULO DE ENERGIA 44
7.1.3 PREPARAÇÃO DOS AMBIENTES E PRODUÇÃO 45
7.2 COMUNICAÇÃO 69
7.2.1 FIWARE 71
7.3 BASE DE DADOS 71
7.4 DESENVOLVIMENTO MOBILE 73
7.4.1 ANDROID STUDIO 74
8 VALIDAÇÃO DO PROJETO 76
8.1 RESULTADO DOS TESTES 76
8.1.1 TESTANDO A ALIMENTAÇÃO DO SISTEMA 76
8.1.2 TESTANDO O APLICATIVO ANDROID 77
8.1.3 TESTANDO A COMUNICAÇÃO, EMBARCADO E SENSORES 78
9 SUMÁRIO E CONCLUSÕES 80
10 BIBLIOGRAFIA 83
11 ANEXOS 85
11.1 ANEXO 1 – HOUSE OF QUALITY 85
11.2 ANEXO 2 - GANT 86
11
1 DEFINIÇÃO DO PROBLEMA1.1 MOTIVAÇÃO
A comunicação, processo que permite a troca de informações, tornou-se
essencial para evolução e para a vida do ser humano. A invenção da Internet, um
meio de comunicação virtual e global, gerou forte impacto em todos os aspectos
da vida das pessoas, desde a forma de realizar diversos trabalhos, aspectos
comportamentais e até mesmo na integração social, como visto hoje em dia. A
Internet gerou uma série de aplicações em diversas áreas, como na possibilidade
de criação de smartphones, comunicação militar e, antes de tudo, computadores
pessoais. Assim como a Internet provocou um boom de tecnologia,
desenvolvimento e mudança comportamental, a área de Internet das coisas
promete fazer o mesmo. Esta se baseia na ideia de objeto inteligentes se
comunicando entre si, enviando e recebendo informações próprias ou sensoriais
com o intuito de facilitar a vida das pessoas e gerar informações e modelos mais
precisos.
Existem 7,3 bilhões de pessoas no mundo, onde 40% têm acesso à
Internet. Isto resulta em aproximadamente 3 bilhões de pessoas conectadas à
Internet. Considerando que 60% dessa população acessa Internet diariamente,
pode-se estimar que por volta de 2 bilhões de pessoas são usuárias da Internet. O
perfil de usuários de uma aplicação de Internet das Coisas é exatamente esse:
pessoas que acessam a internet diariamente.
O objetivo do grupo é criar um sistema que integre os dispositivos
(smartphone e objeto) que disponibilize funções básicas para usuários adaptarem
o aplicativo de acordo com suas preferências. O projeto será feito sobre um
recipiente (tupperware) inteligente, o qual controla a validade de alimentos, a partir
do monitoramento de três variáveis do ambiente: temperatura, umidade e
concentração de gás amônia, dentro do recipiente.
A motivação para realizar o projeto advém de dois fatores: diminuir o
desperdício de alimentos, reduzindo a quantidade de comida não estragada que é
jogada fora, e evitar consumo de alimentos estragados, que podem ocasionar
intoxicação alimentar.
12
Com relação ao desperdício de alimentos, a motivação é justificada pelo
fato de que um terço do que se é produzido no mundo, é desperdiçado a cada ano
– junto com toda a energia, mão de obra, água e produtos químicos envolvidos em
sua produção e descarte. Em outras palavras e métricas, 1,39 bilhão de toneladas
de alimento produzido por ano no planeta acaba se perdendo - seja na produção,
manuseio ou distribuição. Esta comida desperdiçada poderia saciar a fome de
28,5% da humanidade, o equivalente a dois bilhões de pessoas. No Brasil, o
desperdício de alimentos está presente em toda a cadeia, como mencionado
anteriormente, sendo:
• 10% campo
• 50% manuseio e transporte
• 30% comercialização e abastecimento
• 10% varejo (supermercados) e consumidor final (EMBRAPA)
Além do desperdício inerente a cadeia de produção de alimento até nossas
casas, ainda existe o desperdício referente a comida que estraga diariamente nas
geladeiras das famílias brasileiras. Mais especificamente, cada pessoa gera em
torno de um quilo de lixo por dia, sendo que cerca de 58% desse total é
representado por lixo orgânico, formado de restos de alimentos. É visando diminuir
justamente este tipo de desperdício, que surgiu a idéia do projeto de formatura
que consiste no controle próximo dos alimentos armazenados.
A outra motivação é que os alimentos estragados assim como os alimentos
contaminados podem trazer problemas sérios para a saúde, como consequência.
Isso porque, quando se ingere alimentos fora do prazo de validade, as pessoas
ficam expostas a uma série de complicações, podendo provocar intoxicação
alimentar, gastrite, diarreia, vômito, gases ou dor abdominal. Por isso existe a
preocupação em saber se o alimento armazenado encontra-se ou não estragado.
Além disso, cada alimento possui características próprias, ou seja, diferentes
alimentos estragam em ritmos e de maneiras diferentes, o que leva muita gente
inexperiente na cozinha a ficar em dúvida na hora de avaliar se eles podem ser
consumidos.
13
1.2 OBJETIVOS DO PROJETO
O objetivo principal do projeto é a criação de um sistema de comunicação e
sensoriamento baseado em internet das coisas. O sistema gerenciará as
comunicações e dados durante os processos. A ideia inicial é integrar um
recipiente (tupperware) com um aplicativo de celular, a partir do qual o usuário
possa interagir com o tupperware, bem como requisitar tarefas através do
aplicativo. Por fim, uma API será disponibilizada para futura criação de novos
aplicativos por qualquer desenvolvedor. O recipiente inteligente, por sua vez, será
monitorado no que concerne a temperatura, umidade e concentração de gás
amônia.
Dados do Ministério da Saúde apontam que as bactérias são responsáveis
por 83,5% dos casos de intoxicação alimentar, sendo a salmonela a grande vilã.
Os produtos que mais provocam problemas de saúde são os ovos crus e mal
cozidos (22,8%), carnes vermelhas (11,7%), sobremesas (10,9%), água (8,8%) e
leite e derivados (7,1%).
Os alimentos classificados como perecíveis - aqueles que estragam
rapidamente, como carnes, leite e os derivados, ovos, frutas, verduras e legumes
– são os que merecem mais atenção.
14
2 ESTADO DA ARTE E TRABALHOS RELACIONADOS2.1 VISÃO GERAL
O conceito e primeiros projetos envolvendo Internet das Coisas começaram
no MIT em 1999. A ideia geral seria conectar qualquer objeto presente no mundo
à internet, desde objetos sofisticados até objetos simples do cotidiano.
Conectados a internet, o usuário poderia receber informações gerais ou
especificas de todos os objetos.
O conceito geral de Internet das coisas é muito simples: dispositivo(s) de
localização comunicação RFID acoplado a um objetivo qualquer, recebendo e
enviando informações sobre esse objeto através de uma rede wireless.
Algumas empresas já começaram a fornecer serviços comerciais de
Internet das coisas. Um exemplo nessa área é a IBM. Ela já disponibiliza uma
quantidade ampla de soluções com tecnologia RFID e sensores para fabricantes e
fornecedores de bens de consumo. Como exemplo das soluções criadas pela IBM
nessa área está o trabalho feito por ela para a empresa Container Centralen. Eles
implantaram a tecnologia nos produtos da empresa e o produto foi rastreado
durante todo o seu processo logístico. Sendo esse rastreio cobrindo mais de 40
países. Dessa forma, o cliente pode cobrir todas as condições climáticas que o
produto foi exposto durante toda a sua viagem.
Um dos maiores desafios presentes e que precisam ser superados é como
interligar, reconhecer e armazenar toda as informações presentes em uma rede de
Internet das coisas. A quantidade de informações presentes para cada objeto
pode variar muito, desde um número pequeno até uma quantidade razoável de
informações por objeto (exemplo: etiqueta, origem, produtor, validade, data de
produção, trajetória manipulação e avaliações de outros consumidores).
2.2 REVISÃO DA LITERATURA
2.2.1 Implementation of a Smart Fridge by Using RFID and Web Technology[1]
15
O artigo propõe o uso de aplicativos inteligentes no dia-a-dia das pessoas,
graças ao avanço da Internet e da tecnologia, dando ênfase ao ambiente da
cozinha, onde já existem diversos aplicativos desenvolvidos. Neste contexto, o
objetivo do projeto é desenvolver uma geladeira inteligente que auxilia o usuário a
ter uma dieta mais saudável e nutritiva. O protótipo da geladeira combina o uso de
sensores, network, informação e um display e possuirá um sistema que tem uma
própria base de dados que contém os dados do usuário, como registro médico,
eventual alergia a algum alimento, peso, altura, idade, entre outros. A fim de
detectar o produto, é embutido um leitor de código de barras na porta da
geladeira. Além disso, o display disponibilizará as calorias dos alimentos, a lista de
compras, programa para controle de peso, demonstração por meio de multimídia e
receitas baseadas nos produtos armazenados dentro da geladeira.
Finalmente, para entender o conceito de geladeira inteligente, cinco diferentes
geladeiras existentes no mercado são citadas. Essas geladeiras podem incluir
serviços como TV, DVD, álbum de receitas a serem visualizadas em uma tela
LCD, conexão com Internet, calendário e utilização inteligente da energia.
2.2.2 The pervasive Fridge[2]
Esse artigo foi escrito por José Rouillard, LIFL Laboratory – University of
Lille 1. O artigo expõe o projeto da “Pervasive Fridge”, protótipo com finalidade de
alertar quando um alimento atinge o prazo de validade. A ideia por trás do projeto
surgiu em decorrência da enorme quantidade de comida estragada que é jogada
nos lixos diariamente. Logo, espera-se que com o auxílio da tecnologia, essa
quantidade diminua de forma significativa. Existem diversos aplicativos no
mercado que realizam esse tipo de controle: “ Food reminder”, “Food scanner”,
“Fridge police”, entre outros .O protótipo objetiva oferecer um sistema útil e barato
de controle. Basicamente, o produto é reconhecido por meio da câmera de celular
e armazenado no banco de dados do sistema, que relaciona o produto com seu
prórpio prazo de validade. O aplicativo, por sua vez, comunica-se com usuário
através de lembretes pop-up para avisar quais produtos estão para atingir a
validade.
16
2.2.3 A RFID/NFC Fusion based Smart Refrigerator for Wellness Service[3]
O artigo apresenta um projeto de sistema de controle de dieta alimentar, a
partir do reconhecimento do alimento através da fusão do RFID com NFC. Deste
modo, o registro do alimento fica no sistema central da geladeira que se comunica
com um aplicativo smartphone.
Para que o sistema funcione, parte-se de dois pressupostos: primeiro, o tag
é anexado ao alimento e este tag pode ser reescrito e, segundo, a porta da
geladeira é controlada pelo dispositivo NFC. Com relação ao aplicativo
smartphone, este armazenará receitas, de modo que quando o usuário clica na
receita desejada, o programa informa se os alimentos necessários encontram-se
na geladeira ou não. Além disso, o aplicativo oferece uma base de receitas dado
uma doença específica do usuário e as recomendações de receitas podem variar
de acordo com os alimentos disponíveis.
2.2.4 Internet Refrigerator - A typical Internet of things[4]
A proposta do artigo é apresentar uma geladeira totalmente comunicativa
pela internet. Dentro do sistema as tecnologias como internet, bluetooth, wi-fi,
RFID e sensores iriam possibilitar o controle e comunicação dos objetos presentes
na geladeira com o usuário.
O artigo apresenta os principais benefícios e desafios sobre uma geladeira
inteligente. Uma geladeira inteligente poderia facilitar, por exemplo, o trabalho de
um técnico. Quando algum erro de funcionamento ocorrer, a geladeira se
comunica com a central, expõe a localização do erro existente e o técnico já pode
ter um primeiro contato com a geladeira já sabendo o erro que ocorreu. Além
disso, temos as vantagens básicas como: melhor monitoramento dos alimentos,
controle maior da energia consumida.
Dentre os riscos especificados pelo autor temos a possiblidade de invasão
do sistema, se o sistema se comunica com o usuário ele pode muito bem ser
passível a comunicação de um usuário intruso. Outro risco é o recebimento de
mensagens não desejada do fabricante da geladeira ou de parceiros do mesmo.
17
Por fim, como toda aplicação que se comunica com a internet, existe o risco de
perda de privacidade do usuário.
O artigo não específica dados muitos técnicos sobre um projeto de
geladeira inteligente, ele não aborda soluções inteligentes nem dificuldades
especifica do projeto. Ele se baseia somente nas tecnologias existentes e como
elas podem ser agrupadas para a criação dessa geladeira.
2.3 ESTADO DA ARTE E TRABALHO
2.3.1 Refrigeradores Inteligentes
2.3.1.1 Samsung RF28HMELBSR/AA
Com display iterativo de 8 polegadas, possui acesso Wi-Fi à internet e
aplicativos específicos, como lista de compras, lembretes, relógio e temporização.
Além disto oferece controle de resfriamento pelo próprio painel. Possui também
comunicação com outros dispositivos, porém apenas da própria marca Samsung.
2.3.1.2 LG LFX31995ST
Este produto também oferece conexão à Internet por meio de Wi-Fi e uma
tela de LCD com aplicativos simples e específicos para geladeiras. Os aplicativos
da LG apresentam semelhança com a prova de conceito deste projeto: controle de
itens dentro da geladeira, sugestão de compras e controle de validade, tudo
acessado da geladeira com possível integração em smartphones com aplicativos
da LG. Ademais é possível definir padrões de resfriamento ou controle de
resfriamento pelo painel. Além disto este dispositivo também oferece integração
com outros eletrodomésticos da LG.
2.3.1.3 Electrolux DT80X Infinity Frost Free I Kitchen
Esta geladeira não apresenta conexão com Internet nem com outros
dispositivos, porém ainda assim possui aplicativos: lista de receitas, receitas
próprias, lembretes e fotos, dados são transferidos via conexão USB. Esse
refrigerador tem controle de temperatura interno, podendo priorizar regiões
especificas da geladeira como onde ficam as bebidas para resfria-las mais
rapidamente.
18
2.4 TECNOLOGIAS RELEVANTES
2.4.1 Framework de Internet of Things
2.4.1.1 Sofia
Sofia, Smart Objects For Intelligent Applications, pode ser definido como um
middleware que permite a interoperabilidade entre diferentes sistemas e
dispositivos. Seu objetivo principal é de tornar a “informação” existente no dia-a-
dia das pessoas acessível aos serviços inteligentes de modo a conectar o mundo
físico com sistemas. Sofia oferece uma plataforma com interoperabilidade
semântica definida, o qual permite essa troca de informações e caracteriza-se por
ser open source e aceitar multi-linguagem.
2.4.1.2 FiLab Fiware
Firware[8] é uma plataforma para desenvolvimento de aplicações que
podem envolver Internet das Coisas. A plataforma disponibiliza um grande numero
de APIs (Application Programming Interfaces) que facilitam o desenvolvimento das
aplicações. Além disso, a plataforma é open source e royalty-free.
Além disto eferece um conjunto de ferramentas de desenvolvimento de chamados
Enablers, que são programas capazes de realizar alguma tarefa sobre o
framework da Fiware. Do próprio nome, enablers são "habilitadores", são
programas que tonam alo possível seja segurança, administração ou
comunicação.
2.4.2 RFID
RFID é acrônimo de Radio-Frequency Identification, é o nome dado à
transferência de dados wireless por campos eletromagnéticos, isto é, ondes de
rádio.
O RFID tem diferenças frequências padronizadas de operação, sendo as
mais comuns nas faixas de 120-150kHz, que são faixas abertas de transmissão -
ou seja, não regulamentadas; e a faixa de 13.56MHz, uma faixa regulamentada e
padronizada no mundo [9]. Pelo fato de ter maior frequência não utiliza-se de
indutores portanto tem menor perturbação e maior distância de identificação
(podendo chegar a até 1 metro[9]).
19
O funcionamento do RFID é por emissão de rádio-frequência a partir de
algum dispositivo. A onde será absorvida pelas antenas do Tag (nome dado aos
chips de RFID que geralmente vêm em cartões plásticos) utilizando sua energia
para ativar o circuito. Muitos RFID possuem bateria própria. O circuito integrado do
RFID é então capaz de realizar gravações ou leituras sem problemas com
segurança.
2.4.3 MQTT
MQTT é o protocolo mais utilizado e famoso em termos de “baixo-peso” no
ambiente de Internet das Coisas. Seu código é simples, compacto e fácil de usar,
além de atender muitas necessidades das comunicações de IoT. Este protocolo
opera sobre UDP, o que descongestiona redes, mas ainda pode funcionar de
modo orientado à conexão, como TCP. Existem ainda diversas distribuições deste
protocolo, porém com mais funções implementadas. É o caso do MQTT-SN, por
exemplo, que fornece serviço publisher-subscriber, o que também é importante em
uma rede de sensores e atuadores. O protocolo foi recentemente introduzido à
padrões de comunicação, como para o OASIS (Advancing Open Standards for the
Information Society).
2.4.4 Intel Edison
Edison é o módulo computacional mais novo e poderoso da Intel. Com um
dual-core, dual-threaded Intel® Atom™ CPU a 500 MHz em conjunto com um
controlador Intel® Quark™ a 100 MHz, 1 GB DDR3 de RAM, 4GB de memória
Flash e Wireless 802.11 a/b/g/n em 2.4 e 5GHz em apenas 35.5 × 25.0 × 3.9 mm,
é o módulo computacional desenvolvido com maior foco para aplicações IoT.
2.4.5 IBM Bluemix
IBM Bluemix é a plataforma em nuvem de padrões abertos da IBM que
fornece aos desenvolvedores de dispositivos móveis e da web acesso ao software
IBM para integração, segurança, transação e outras funções principais, bem como
ao software de parceiros de negócios.
20
Figure 1 Workflow utilizando Blue mix
Com o amplo conjunto de serviços e tempos de execução no Bluemix, o
desenvolvedor obtém controle e flexibilidade, além de acesso a diversas opções
de dados, da análise preditiva a big data.
O Bluemix fornece os recursos a seguir:
Um intervalo de serviços que permitem construir e estender apps da web e
móveis rapidamente
Energia de processamento para a entrega de mudanças no app
continuamente
Modelos de programação e serviços adequados para o propósito
Capacidade de gerenciamento de serviços e aplicativos
Cargas de trabalho otimizadas e elásticas
Disponibilidade contínua
Dessa forma, com o desenvolvedor de aplicativos, é possível
concentrar-se no desenvolvimento do aplicativo sem necessidade de gerenciar a
infraestrutura necessária para hospedá-lo.
Em linhas gerais, o sistema operacional e as camadas de
infraestrutura ao executar aplicativos no Bluemix são relativamente simples.
Camadas como sistemas de arquivos raiz e componentes de middleware são
abstraídas. No entanto, é possível saber mais sobre estas camadas caso haja
necessidade de saber informações específicas sobre onde o aplicativo a ser
executado.
21
Figure 2 Esquemático – Bluemix
2.4.6. Google APIs
Google APIs[13] é a camada de API fornecida pela Google para inúmeros
serviços: mapas, agenda, tradução, busca e muitos outros. Esta camada oferece
serviços de computação que vão implementar funções no produto final.
2.4.7 Android
O Android é um sistema operacional da Goole para Smartphones. A google
se baseou no núcleo Linux para a criação do Android. O sistema foi criado para
smatphones baseados em telas sensiveis a toques. Desde a primeira versão essa
propriedade dos smartphones foi utilizada como recurso.
22
Figure 3 Logo do Android
Um dos motivos da escolha desse sistema operacional para o
desenvolvimento do nosso aplicativo foi sua abrangência. O Android é utilizado
como sistema operacional pela maioria das empresas de celular do mundo,
fazendo dele o sistema operacional mais utilizado do mundo. A sua loja de
aplicativos já possui milhões de aplicativos disponíveis e o sistema operacional já
chegou a grande maioria das geografias.
Figure 4 Crescimento dos SO de mobile
O código do sistema operacional é aberto, disponibilizado pela Google.
Além disso, o custo de desenvolvimento para Android é baixo, não é necessária a
compra de nenhuma licença de desenvolvimento, muito menos uma licença para a
publicação da aplicação no Google Play (loja de aplicativos).
23
A interface do Android é baseada em manipulação direta, o celular possui
normalmente acelerômetros, giroscópios e sensores de proximidade para
possibilidade opções de respostas a comando do usuário.
O desenvolvimento de aplicativos é realizado em linguagem Java, usando o
sistema de desenvolvimento Android(SDK). Esses sistemas possui uma séria de
ferramentas: depurador, biblioteca, um emulador baseado em EQMU,
documentação consolidada, tutoriais e exemplos de códigos.
Em relação a manipulação de memória, o Android possui a capacidade de
gerenciamento de memória. Dessa forma, ele manipula a memória utilizada pela
aplicação para deixa-la de forma mais otimizada possível.
2.4.8 Bibliotecas C++
2.4.8.1 BOOST
Boost é um conjunto de bibliotecas desenvolvidos na linguagem de
programação C++ que fornece suporte para tarefas e estruturas, tais como
álgebra linear, geração de números pseudo-aleatórios, processamento de imagem
multithreading, threading, expressões regulares, e testes de unidade. Ele contém
mais de oitenta bibliotecas individuais.
Figure 5 Logo do Boost
2.4.8.2 Casablanca
O C ++ REST SDK (codenome casablanca) é um projeto de biblioteca da
Microsoft para comunicação cliente-servidor baseado em nuvem usando código
nativo e API de C++ moderna, incluindo operações assíncronas.
2.4.8.3 libxbee
24
Libxbee é uma biblioteca C/C++ para ajudar o uso de comunicação ZigBee
produzida por produtos Digi XBee em execução no modo API.
Figure 6 Logo do Libxbee
2.4.8.4 Orion Context broker
O Orion Context Broker e um Enabler do Fiware que viabiliza o
armazenamento de dados com contexto (isto e, ambiente ontológico) para acesso
de outros aplicativos via query ou até mesmo subscrição a conteúdo (por tempo
ou evento).
Figure 7 Logo do Orion Context Broker
2.4.8.5 Amazon AWS
Amazon Web Services, é uma coleção de serviços de computação remota,
também chamados de serviços web, que compõem uma plataforma de
computação em nuvem oferecido pela Amazon.com.
Figure 8 Logo da Amazon AWS
2.4.8.6 REST/RESTful
25
Representational state transfer (REST) é uma arquitetura de comunicação e
transferência de dados que é utilizada por serviços que são denominados
RESTful. REST é uma das principais arquiteturas para comunicação do World
Wide Web (websites).
2.4.8.7 MRAA
MRAA é uma biblioteca de baixo nível que oferece uma tradução de
interfaces General Purpose Input/Output (GPIO) para os pinos disponíveis no Intel
Galileo ou Edison[14].
2.4.8.8 Yocto Linux
O Projeto Yocto é um grupo de trabalho Linux Foundation, cujo objetivo é
produzir ferramentas e processos que permitam a criação de distribuições Linux
para software embarcado que são independentes da arquitetura subjacente do
próprio software incorporado. [15]
Figure 9 Logo da Yocto Linux
2.5 ÁRVORE DE OBJETOS
Os requisitos designados para o sistema estão designados abaixo:
Fácil de usar
o Fácil entendimento
o Fácil de instalar
Utilização simples e fácil
Estado da arte
o Sistema Operacional gratuito
o Facilmente expansível
26
o Funções de alto nível
o Barato
o Componentes simples
o Bibliotecas de desenvolvimento simples
o Remoção de dependências de hardware
Compacto
o Físico
Ambiente internos
Ambientes externos
Ambientes com interferência eletromagnética
Ambientes selados
Resistente temperatura
o Virtual
Pouco tamanho do software
Pouco consumo na memória
Pouco uso de CPU
Pouco uso de rede
Protocolos de IoT
27
Árvore de Objetos
Camada de serviço
Estado da arte
SO gratuito
Facilmente expansivel
Funções de alto nível
Barato
Componentes simples
Bibliotecas de desenvolvimento
simples
Remoção de dependencias de
hardware
Facil de usar
Facil entendimento
Utilização simples e facil
Facil instalação
Compacto, leve e resistente
Fisico
Resistente ainterf. mag
Resistenta a temperatura
Ambientes internos
Anbientes externos
Virtual
Espaço em disco
Memória
CPU
Uso de rede
Protocolos de IoT
28
2.6 DECOMPOSIÇÃO FUNCIONAL
Visto que são dois sistemas distintos no projeto, segue abaixo a decomposição
funcional de ambos:
Decomposição funcional do sistema IoT
Módulo com interface IoT
Intel Edison
Interface Wireless
Protocolo MQTT
Cloud
Interface Bluetooth Protocolo MQTT
Processamento e computação
Sistema Operacional
Yocto
Firmware Fiware
Sensores
Temperatura
Umidade
Interface RFID
29
Decomposição funcional do Aplicativo Andriod
Aplicativo Andriod
Comunicação Wireless
Protocolo MQTT
Cloud
Administração
Cloud
Base de Dados Local
Algoritmos e Funções Internas
30
2.7 VISÃO GERAL DO PROJETO
Com base no que foi apreentado e estudado, o sistema proposto é:
Figure 10 Visão geral do projeto
31
3 ESPECIFICAÇÃO DE REQUISITOS
3.1 REQUISITOS DE ENGENHARIA (PESO DE 1 A 5)
3.1.1 Desempenho (Peso 4)
O raio de alcance mínimo entre dispositivos/sensores deve ser de 5 metros
Cada dispositivo tem capacidade mínima de controle de 3 variáveis
independentes
Capacidade de armazenamento de 7 dias de operação sem a necessidade
de uploads
O programa ocupará até, no máximo, 10% da CPU e 128M de memória
RAM
3.1.2 Funcionalidade (Peso 5)
O sistema converterá as leituras dos sensores em uma leitura digital com
acurácia de 10% dentro da faixa estipulada de medidas
Os sensores se comunicarão com o sistema central para possibilitar a troca
de informações com redes externas
As informações armazenadas na nuvem ou no sistema central podem ser
acessadas por meio de um smartphone
O sistema operacional utilizado será gratuito e as ferramentas, open source
3.1.3 Confiabilidade e disponibilidade (Peso 3)
O sistema operacional ficará disponível 24h por dia, 365/ano
O tempo de vida esperado é de 10 anos (tempo de utilização de um
processador)
O sistema utilizará protocolos seguros de comunicação e as informações
serão criptografadas
3.1.4 Energia (Peso 2)
O sistema será alimentado por uma fonte externa de energia ou por energy
harvesting
O sistema contará com uma bateria externa em caso de falta de
alimentação
32
3.1.5 Ambiental (Peso 1)
Os dispositivos devem ser capazes de operar a uma faixa de temperatura
de -5 C a 80 C
O sistema será recarregável
O sistema deve suportar a umidade do ar
3.1.6 Econômico
O sistema será constituído por sensores padronizados e amplamente
utilizados
Não há custos adicionais para integração de sistemas já existentes
O custo do sistema em relação ao eletrodoméstico em questão não deve
superar 10%
3.2 ENUMERAÇÃO DOS REQUISITOS PRINCIPAIS DE MARKETING
1 - Utilização simples e fácil
2 - Facilmente expansíves
3 - Barato
4 - Compacto
5 - Pouco tamanho do software
6 - Pouco consumo na memória
3.3 TABELA DE REQUISITOS
Requisitos de marketing
Requisitos de engenharia
4, 5,6 o programa ocupará até, no máximo, 10% da CPU e 128M de
memória RAM
33
1
O sistema será constituído por sensores padronizados e
amplamente utilizados
2 Não há custos adicionais para integração de sistemas já
existentes
3 O custo do sistema em relação ao eletrodoméstico em questão
não deve superar 10%Table 1 - Requisitos de marketing e engenharia
3.4 HOUSE OF QUALITY
A house of quality complete encontra-se no Anexo 1.
34
4 ANÁLISE DE VIABILIDADE4.1 LEQUE DES CONCEITOS INICIAIS
Design
Aplicativo xSmartphone
iOS
Andriod
Windows Phone
Sensor
Comunicação
RFID
Bluetooth
Variáveis de Controle
Temperatura
Umidade
Pressão
Software
OS Embarcado
Linux Personalizado
Distribuição Linux
Windows 10
Protocolo
MQTT
CoAP
Personalizado
35
4.2 TABELA DE CONCEITOS
Aplicativo Smartphone
Sensor de Comunicação com Objetos
Variáveis de Controle
Sistema Operacional Embarcado
Protocolo de Comunicação
iOS RFID TemperaturaDistribuição
LinuxMQTT
Andriod Bluetooth UmidadeLinux
PersonalizadoCoAP
Windows Phone
Pressão Windows 10 Personalizado
Table 2 - Tabela de conceitos
Em avaliação inicial, retiramos propostas que atenderam os seguintes fatores:
Demasiadamente trabalhosas
o Foi removida a criação de Protocolo personalizado.
Sistemas operacionais com baixo mercado ou com pouca estabilidade
o Foram removidos Windows Phone de Aplicativo Smartphone e
Windows do Sistema Operacional dos módulos computacionais.
Variáveis de pouca relação com o projeto ou produto final
o Foi removido o sensor de Pressão do conjunto de sensores.
Após avaliação inicial, obteve-se:
Aplicativo Smartphone
Sensor de Comunicação com Objetos
Variáveis de Controle
Sistema Operacional Embarcado
Protocolo de Comunicação
iOS RFID TemperaturaDistribuição
LinuxMQTT
Andriod Bluetooth UmidadeLinux
PersonalizadoCoAP
Table 3 - Tabela de conceitos reavaliada
Desta forma foi possível partir para a análise de forças e fraquezas, que
nesta etapa é mais importante que uma análise de Pugh, já que a maioria dos
conceitos ainda é bastante abstrato e necessita uma avaliação de tecnologia
antes de avaliações de qualidade em conjunto com o projeto.
Desta forma, temos a análise de forças e fraquezas abaixo:
4.3 Sistema Operacional Smartphone
Método Forças Fraquezas
iOS
1. Grande quantidade de
usuários +2. Aplicativos são confiáveis +
3. Atrai pessoas com maior
poder de compra ++
1. Necessária autorização do
AppStore para desenvolver
App --2. Linguagem de programação
menos difundida -
3. Compilador complexo -
Android
1. Maior quantidade de
usuários ++2. Linguagem de programação
simples +3. Algumas empresas vendem
ambos celulares Androids e
produtos domésticos +
1. Muitos usuários com muitas
versões diferentes do Andriod
-
Table 4 - Avaliação: sistemas operacionais
Escolha: Android
4.3 Sensor de Comunicação com Objetos
Método Forças Fraquezas
RFID1. Consumo pontual para
leitura e gravação++2. Baixo custo ++
1. Menor área de alcance -
Bluetooth 1. Maior área de alcance + 1. Consumo contínuo --
37
2. Necessidade de software para
administrar conexão em todas
as pontas --3. Custo elevado -
Table 5 - Avaliação: sensores de comunicação
Escolha: RFID
4.4 Sensor de Variáveis de Controle
Método Forças Fraquezas
Temperatura
1. Relevante para aplicação
final de geladeira ++2. Variável bastante
relevante para diversas
análises sobre produtos +
1. Temperatura de operação
do sistema é incomum -
Umidade1. Variável de difícil controle
+1. Menos relevante ação sobre
"produtos" -Table 6 - Avaliação: sensor de variáveis de controle
Escolha: Sensor de Temperatura
4.5 Sistema Operacional Embarcado
Método Forças Fraquezas
Distribuição Linux
1. Estável ++2. Suporte de comunidade
sobre distribuição ++
1. Difícil de atualizar -
2. Grande (em espaço virtual)
3. Muitos serviços não serão
utilizados --
Linux Personalizado
1. Compacto ++2. Suporte de comunidade
sobre criação +
1. Dificuldades de
desenvolvimento --
Table 7 - Avaliação: sistemas operacionais embarcados
Escolha: Linux Personalizado
38
4.6 Protocolo de Comunicação
Método Forças Fraquezas
MQTT1. Comunicação de Muitos-
para-Muitos ++1. Sem suporte para label de
mensagens -
CoAP1. Controle de recursos +2. Auto descoberta de
mensagens ++
1. Comunicação Ponto-a-Ponto
--2. Mais complexo -
Table 8 - Avaliação: protocolos de comunicação
Escolha: MQTT
39
5 ANÁLISE DE RISCOAtribui-se pesos aos riscos (ocorrência e consequências). O score de
cada item tem peso e é determinado pela multiplicação do score de
consequência vezes o score de chance de ocorrência.
Insignificante
1
Menor
2
Moderado
3
Maior
4
Extrema
5
Quase certo
(>90%) 6
6 (Moderado) 12 (Alto) 18 (Alto) 24
(Extremo)
30
(Extremo)
Provável
(50% ~ 90%)
4
4 (Baixo) 8 Moderado 12 Alto 16
(Extremo)
20
(Extremo)
Moderado
(10% ~ 50%)
3
3 (Baixo) 6 Moderado 9 Alto 12 (Alto) 15 (Alto)
Improvável
(3% ~ 10%) 2
2 (Baixo) 4
(Moderado)
6 Moderado 8
(Moderado)
10 (Alto)
Raro (<3%) 1 1 (Baixo) 2 (Baixo) 3
(Moderado)
4
(Moderado)
5
(Moderado)
Table 9 – Tabela de riscos
Como o score final é uma multiplicação, para determinação de categorias
foi definido, dado os scores apresentados, que :
√Nível≥ 4 → Risco Extremo
√Nível≥3 → Risco Alto
√Nível≥2 → Risco Moderado
√Nível<2 → Risco Baixo
40
5.1 RISCOS
1-Leitura via RFID sofrer demasiada interferência metálica (Moderada nível 8): Adicionar mais leitores resolveria o problema, a custo de aumento no custo
de produção
2-RFID não ter alcance adequado de leitura e gravação (Moderada nível 8): Adicionar mais leitores resolveria o problema, a custo de aumento no custo de
produção
3-Ambiente não comum dentro de refrigeradores pode alterar funcionamento de componentes: componentes alternativos ou construção
própria pode ser necessária (Moderado nível 4): Componentes substitutos ou
construção própria necessária
4-Sinais de comunicação, via WiFi ou bluetooth podem ser anulados dentro do refrigerador por tornar-se uma gaiola de Faraday (Alto nível 15): posicionamento de módulo de comunicação ou antenas para fora do refrigerador
será necessário
5-O cenário do Fiware não estar maduro o suficiente para o desenvolvimento de tantas funcionalidades: segurança de dados, leituras de sensores e outros (Alto nível 10): desenvolvimento de módulos de código
ou outras funcionalidades complexas será necessário.
Como já analisado na revisão bibliográfica, os riscos presentes no nosso projeto
são os mesmos riscos que os artigos apontaram para os projetos realizados por
eles. Mesmo considerando então que alguns riscos sejam relevantes, já temos a
partir de uma diversa revisão bibliográfica a maioria das soluções
implementadas para cada risco. Ou seja, depois de analisado todos esses
fatores e artigos, concluímos que a grande maioria dos riscos presentes no
nosso projeto já foram solucionados por um terceiro, o que facilitará muito nosso
trabalho no futuro.
41
6 CRONOGRAMATodo o cronograma está apresentado e o Gant está apresentado no
Anexo 2 desse documento.
42
7 DESENVOLVIMENTO DO PROJETOComo forma de organização do projeto, realizamos uma divisão de
frentes de trabalho. Cada frente poderia ser desenvolvida por um ou mais
componentes do grupo, podendo um único componente trabalhar em mais de
uma frente. Porém o desenvolvimento de cada frente e sua execução foi
planejada paralelamente. Sendo o seu desenvolvimento sendo discutido em
reuniões semanais do grupo. As seguintes frentes de trabalho foram idealizadas:
Hardware e sensores
Comunicação
Desenvolvimento Mobile
7.1 HARDWARE E SENSORES
7.1.1 Hardware
O hardware responsável pelo sensoriamento está dividido em 3 módulos:
Módulo de energia, responsável por energy-harvesting, carregamento de
baterias, baterias e conversão de tensão e fornecimento de potência; Módulo de
processamento, responsável por integrar sensores e prover interface inteligente
para tratamento de dados e comunicação; Módulo de sensores, composto pelos
sensores e suas alimentações de energia.
7.1.1.1 Arduino.h vs mraa.h
Toda programação desenvolvida sobre a biblioteca MRAA. Isto foi feito
porque os sistemas Intel Galileo e Intel Edison possuem sistema operacional
(Yocto Linux) e MRAA faz a interface de comunicação com os drivers do sistema
operacional, enquanto sistemas Arduino são chamados de bare metal, pois não
têm sistema operacional e funcionam diretamente em comunicação com o
processador. Isto traz vantagens e desvantagens, listadas a seguir:
43
Arduino Yocto Linux (mraa)
+ Tempo Real Sistema em Tempo Real - Tempo Real
× Threading
Melhor Temporização Pior
× Controle de Energia
× Controle de
Processamento (bloking)
× Paralelismo e Multi-Core
Table 10 – Tabela de comparação Arduino e Yocto Linux
Com base na comparação, pode-se ver que Arduino.h, apesar de rápido e
simples, não é ideal para aplicações complexas ou que envolvam threading ou
qualquer tipo de paralelismo. Dado o tamanho do projeto almejado, a utilização
de um sistema com sistema operacional foi inevitável. Além disso, segundo a
tabela acima, pode-se perceber que temporização e aplicação para tempo real
apresenta maior desafio nos sistemas com Yocto Linux e mraa.h.
7.1.2 Módulo de energia
Foi desenvolvido um módulo para estabilização de nível, controle de
fornecimento e energia e fornecimento de energia para os sensores e para o
módulo embarcado Edison. A conversão DC/DC foi feita utilizando módulos já
disponíveis em mercado, e foi conectada à placa de energia desenvolvida para
alimentação dos sensores. A figura abaixo mostra o esquemático do módulo
desenvolvido:
44
Figure 11 Esquemático no Eagle
Os componentes utilizados foram:-4 resistores 10k
-7 resistores 1k
-3 transistores MOSFET IRLR2908
-2 capacitores eletrolíticos B41827 2.2mF
-1 sensor de amônia MQ 135
-1 sensor de temperatura/umidade
-1 sensor RFID
- componentes auxiliares: pinhead, fios, placa para circuito impresso
7.1.3 Preparação dos Ambientes e produção
Nesta seção descreve-se detalhadamente como reproduzir todos
ambientes utilizados neste projeto.
Os ambientes são: OrionContextBroker em Cloud na Amazon AWS;
Ambiente de compilação e com boost, casablanca e libxbee no módulo
computacional Intel Edison; E o ambiente físico, que contém o Edison e
sensores conectados; O processo depende de conexão com a Internet e pode
levar um total de 12 horas, considerando esperas de compilação.
45
7.1.3.1. Preparando o servidor Fiware
A comunicação e feita em nuvem com um servidor que possui algum
enabler do Fiware. O enabler utilizado e o OrionContext Broker, que é capaz de
armazenar e administrar todos os dados colhidos por sensores e administrar
todos dispositivos conectados a ele que façam a utilização desses dados.
a) Inicialmente cria-se uma instancia na Amazon AWS:
No dashboard AWS, na seção “Compute”, selecionar EC2.
Figure 12 Dashboard Amazon AWS
Pressionar botão “Launch Instance” para criar uma nova instancia.
Figure 13 Interface Amazon AWS
OrionContext Broker, no momento desta publicação, ainda não é compatível
com versões mais recentes do CentOS (maiores que 7), portanto é
imprescindível a seleção de uma versão CentOS 6.x. Para tal, pode-se usar o
46
AWS Marketplace e buscar uma versão compatível. Para este projeto, foi
utilizada a versão CentOS 6.5.
Figure 14 Interface Amazon AWS
Após isto, seleciona-se a versão e finaliza-se a configuração de nova instância
da AWS.
Um novo grupo de segurança será gerado assim como uma chave privada (a
qual deve-se fazer download) para conexão com o servidor. Antes de conectar-
se ao servidor, e necessário editar o grupo de segurança para que habilite o
fluxo de dados pela porta padrão do Orion, 1026. Portanto deve-se acessar o
menu EC2 → Network & Security → Security Groups. Selecionando o grupo
recém-criado, deve-se habilitar conexões “Inbound” do tipo TCP na porta 1026.
Figure 15 Interface Amazon AWS
Para conectar-se à instância AWS (Linux) Acesse a pasta que contém a chave
executa-se o comando pelo terminal
chmod 400 my-key-pair.pem
E então pode conectar-se via SSH
47
ssh –I /path/my-key-pair.pem ec2-user@public_dns_name
Onde public_dns_name é o DNS público oferecido pela Amazon ou o IP
associado a instancia.
b) Instalação do mongo-db 3.0
Será necessária a adição do repositório do mongo-db para download e
instalação, portanto:
vi /etc/yum.repos.d/mongodb.repo
Após isto, adicionar as seguintes linhas no arquivo
[MongoDB]
name=MongoDB Repository
baseurl=http://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.0/
x86_64/
gpgcheck=0
enabled=1
Utilize “i” para inserir via vi, em sequida ctrl+shift+v para colar todo conteudo.
ESC para sair do modo de edicao e “:qw” seguido de “enter” para comando de
salvar e sair.
Instala-se entao o mongo-db
yum install mongodb-org
E habilita-se sua inicializacao com o boot:
chkconfig mongod on
c) Instalacao o OrionContextBroker
48
A maneira mais simples de instalar e pela utilização do comando yum, portanto
isto ira requisitar a adição de mais um repositório:
vi /etc/yum.repos.d/testbed-fi-ware.repo
Neste arquivo inclua, utilizando o mesmo processo anterior as linhas:
[testbed-fi-ware]
name=Fiware Repository
baseurl=http://repositories.testbed.fiware.org/repo/rpm/x86_64/
gpgcheck=0
enabled=1
Basta então instalar o OrionContextBroker [18]:
yum install contextBroker
Isso finaliza a preparação do modulo Orion em nuvem que já deve estar pronto
para testes.
7.1.3.2. Preparação do ambiente físico
Este ambiente é variável e aqui está representado o ambiente utilizado no
projeto que condiz com as configurações de programação, isto é, que segue a
pinagem e os sensores utilizados.
a) Conexão do Sensor de Temperatura e Umidade
Como mostrado anteriormente, o módulo Edison e Galileo, por terem um
sistema operacional por baixo de suas operações com o processador,
apresentam tempos mais lentos para algumas funções de trabalho GPIO. Um
caso expressivo é a troca de direção de uma porta de entrada para saída. Esta
operação consome cerca de 350us, um tempo muito elevado se considerarmos
que escritas podem ser feitas em 0.5us.
Os sensores DHT possuem um único canal de comunicação e seu protocolo
prevê mudança de porta de entrada para saída em intervalo de 80us, o que é
49
impossível dada a descrição do problema acima. Portanto para resolver este
problema, utilizam-se duas portas de comunicação, uma sempre input, outra
sempre output, dessa forma, separando os sinais com um diodo, podemos
simular uma comunicação de dois canais, resolvendo o problema de velocidade.
O esquemático de ligação do sensor DHT fica:
Figure 16 Esquemático no Eagle: sensor DHT
b) Conexão Digital do Sensor de Amônia
O sensor de amônia MQ135 possui saída digital de 1 bit, resultado da
comparação do nível medido com um padrão regulado pelo potenciômetro
externo. Portanto uma possível ligação do sensor de amônia é:
Figure 17 Esquemático no Eagle: sensor amônia
c) Conexão Analógica do Sensor de Amônia
O sensor de amônia MQ135 também possui saída analógica, ideal para medidas
contínuas e de precisão. A saída analógica pode ser facilmente conectada ao
Galileo. Porém o módulo Edison não possui conversor analógico-digital (ADC)
integrado, portanto a ligação com o Edison deve ser feita via um ADC. A ligação
é feita de tal forma que há dois canais: o primeiro, sempre com output,
50
funcionando como clock de amostragem para o conversor ADC; o segundo,
sempre de input, para recebimento do sinal digital na taxa que o output é escrito,
desta forma, com escrita e leitura intercaladas, é muito rápido e simples fazer a
leitura dos valores analógicos. O esquema segue representado a seguir:
Figure 18 Esquemático no Eagle: conexão analógica do sensor de amônia
d) Conexão da energia
O módulo Edison possui 4 entradas de energia. Uma especifica para bateria,
podendo até mesmo recarregar a bateria; uma para uma fonte DC; uma para o
conector micro-USB a 5V; a última uma entrada principal com regulador para 5V
e entrada a partir de 7V.
Apesar de extenso controle de energia, foi construída uma placa PCB para
fornecimento de energia para o Edison e para os sensores, centralizando o
problema. O Edison foi então energizado via micro-USB, por já possuirmos um
regulador de 5V (que é usado para outros sensores). A alimentação do
regulador é um conjunto de duas baterias de celular de padrão 3.7V em série.
Vide figura a seguir:
51
Figure 19 Teste com a bateria Samsung
7.1.3.3. Preparação do ambiente de compilação
Por razoes não bem determinadas até a publicação este documento, o
compilador cruzado “i586-poky-linux” apresenta problemas de compilação para
códigos mais complexos. Portanto o ambiente de compilação foi transferido para
o próprio embarcado Intel Edison.
É necessário que todas as ferramentas de compilação estejam
disponíveis e atualizadas, além disso, o modulo atualizado e importante para o
bom funcionamento dos módulos a serem instalados.
a) Conectando-se ao Edison
A primeira etapa consiste em conectar a energia ao modulo Intel Edison.
52
Figure 20 Edison
Reprodução de “https://software.intel.com/en-us/articles/assemble-the-intel-
edison-board-with-the-mini-breakout-board”
E então conectando a comunicação serial, acessível pela outra conexão micro-
usb:
Figure 21 Teste com a Edison
Reprodução de https://software.intel.com/en-us/articles/assemble-the-intel-
edison-board-with-the-mini-breakout-board
Nos sistemas operacionais Windows:
Neste momento será necessário instalar ou ter instalado o pacote de drivers da
Intel, disponíveis no seu website1.
Após instalados o usuário poderá confirmar a instalação com a presença dos
seguintes dispositivos USB:
1 https://software.intel.com/en-us/get-started-edison-windows-step2
53
Figure 22 Instalação do dispositivo
Reprodução de “https://software.intel.com/en-us/get-started-edison-windows-
step2”
Onde, na imagem, A porta COM10 representa a conexão serial. O usuário pode
utilizar qualquer programa com conexão serial a uma taxa de 115200 bps. No
projeto o programa utilizado foi o PuTTY[19]
No Sistema operacional Linux, acesse o Edison diretamente via driver USB0 e o
programa screen:
screen /dev/ttyUSB0 115200
O login padrão para o Edison é root, sem senha.
b) Flash da imagem do Edison
Caso ainda não exista um sistema operacional, é possível fazer o flash da
imagem do sistema operacional Yocto Linux no Edison. Para isto basta usar a
ferramenta “Flash Tool Lite” da Intel. O passo a passo desta operação encontra-
se no website da empresa[20].
c) Habilitando a rede WiFi
Conectado no Edison, para conectar-se a uma rede, utilize o comando
54
configure_edison --wifi
Caso será a primeira execução, aconselha-se realizar toda configuração do
Edison utilizando o comando
configure_edison
d) Atualizar Edison
opkg update
Para disponibilidade de alguns pacotes no Yocto Linux, será necessária a adição
de um repositório especial para o Edison [17]. Para isto:
e) Adicionar repositório
vi /etc/opkg/base-feeds.conf
No arquivo aberto inserir
src/gz all http://repo.opkg.net/edison/repo/all
src/gz edison http://repo.opkg.net/edison/repo/edison
src/gz core2-32 http://repo.opkg.net/edison/repo/core2-32
f) Antes de instalar o ambiente de desenvolvimento, e importante atualizar o
uclibc que não aparece compatível na versão do Yocto Linux [16].
opkg install
--force-overwrite uclibc
g) Instalação dos módulos de desenvolvimento e compilação
opkg install
packagegroup-core-buildessential git
Neste ponto, o ambiente está pronto para compilação e desenvolvimento. A
próxima etapa e a instalação do conjunto de bibliotecas BOOST. Apesar de
55
disponível no repositório não oficial, existem duas razoes para não instalar
usando o comando OPKG: o primeiro e porque outras dependências
(casablanca por exemplo) utilizam versões anteriores do boost, portanto, por
compatibilidade, deseja-se ter uma versão especifica; o segundo motivo e que a
instalação via opkg apresenta alguns problemas para o boost, além de não
trazerem os headers do mesmo. Manualmente, instala-se o boost:
h) Download do boost
wget -O boost_1_54_0.tar.gz
http://sourceforge.net/projects/boost/files/boost/1.54.0/boost_1_54_0.ta
r.gz/download
tar xzvf boost_1_54_0.tar.gz
cd boost_1_54_0/
A versão instalada do boost ainda pode apresentar problemas de compilação,
por conta da versão o uclib que, mesmo atualizado anteriormente, ainda pode
ter incompatibilidade. A partir da versão 1.55 do boost, o seguinte tratamento
não e mais necessário, mas para versões anteriores como e o caso necessita-se
modificar o arquivo “cstdint.hpp” [26]
i) Correção do arquivo “boost/cstdint.hpp”
Substituir linha 44
#if defined(BOOST_HAS_STDINT_H) && (!defined(__GLIBC__) ||
defined(__GLIBC_HAVE_LONG_LONG))
Por
#if defined(BOOST_HAS_STDINT_H) && (!defined(__GLIBC__) ||
defined(__GLIBC_HAVE_LONG_LONG) || (defined(__GLIBC__) && ((__GLIBC__ >
2) || ((__GLIBC__ == 2) && (__GLIBC_MINOR__ >= 17)))))
56
Com o boost preparado, compila-se e instala-se as bibliotecas necessárias, que
para este projeto são: system, filesystem, thread, chrono, regex.
j) Compilação e instalação do boost
Para gerar arquivos e configurações necessárias execute
./bootstrap --with-libraries=chrono,regex,thread,filesystem,system –
libdir=/usr/lib/
E para compilar
./b2 install
Alternativamente, a compilação pode ser feita manualmente com
CXX=g++ make .. -DCMAKE_BUILD_TYPE=Release
-DBOOST_ROOT=/home/root/boost_1_54_0/ -DOPENSSL_LIBRARIES=/usr/lib -
DOPENSSL_INCLUDE_DIR=/usr/include/openssl
Com estas etapas concluídas, e possível instalar outros módulos. O próximo e a
biblioteca casablanca. Para a instalação, além do boost, necessita-se ter uma
versão atualizada ad biblioteca LibSSL, portanto:
k) Atualização do OpenSSL
opkg install libssl
l) Pode-se agora, fazer download, compilação e instalação da biblioteca
git clone https://git.codeplex.com/casablanca
cd casablanca/Release
mkdir build.release
cd build.release
CXX=g++ -std=c++11 cmake ..
-DCMAKE_BUILD_TYPE=Release
57
make
m) Instalam-se as bibliotecas no destino padrão
cp Binaries/* /usr/lib/
Isso conclui a instalação das bibliotecas casablanca, resta agora a instalação do
LibXBee, que habilita a comunicação via ZigBee:
n) Download da biblioteca
git clone https://github.com/attie/libxbee3
o) Compilação e instalação
cd libxbee
make configure
make
make install
Concluindo a instalação de todos módulos de dependência para o programa
principal.
7.1.3.4. Instalação do programa SKControl
O programa principal utiliza-se da biblioteca SKCLib, uma biblioteca para
controle de sensores desenvolvida pelo grupo. Esta biblioteca encontra-se na
pasta SKCLib da raiz do projeto. Esta parte do projeto é independente e pode
ser copiada e utilizada em outros projetos. Uma descrição detalhada do projeto e
sua biblioteca esta apresentada a frente, na seção seguinte.
a) Para instalar o programa no ambiente Intel Edison, acesse uma pasta de preferência e execute:
58
git clone https://github.com/mangine/tcc
b) Habilite a execução dos instaladores:
cd tcc/SKC
chmod 777 compile
chmod 777 rebuild
c) Instale
./rebuild
./compile
d) Isto deve criar um executável “SKC” na pasta bin/Debug/, para iniciar o programa execute
cd bin/Debug/
./SKC
7.1.4 Desenvolvimento de Software
7.1.4.1 Bibliotecas
Biblioteca SKControl
A biblioteca SKControl visa abstrair sensores, controladores de energia e rede e
outras funcionalidades para que possam ser construídas aplicações em cima
desta. O objetivo da biblioteca é fazer sensores serem ser facilmente
implementados, sem que o usuário precise codificar rotinas de controle de um
sensor específico ou outros controles, como de dados em rede. Com a biblioteca
SK Control, o desenvolvimento de aplicações fica simples e sucinto.
Detalhamento será fornecido junto a um código exemplo. A biblioteca tem dois
grandes módulos e um módulo conector:
O primeiro módulo administra sensores e threads. Esse é responsável por ativar
sensores com agendamento de horário e/ou repetição. Este módulo também
59
administra as threads criadas e fornece processamento paralelo, além de
controlar as prioridades de execução e pausas de execução. Por fim, este
módulo também controla o fornecimento de energia para os sensores a serem
utilizados, visando reduzir o consumo quando os sensores não precisar fazer
medições.
O segundo grande módulo é o módulo de REST API. Ele providencia envio e
formatação de pacos JSON para um servidor REST/RESTful e tratamento de
problemas, além de ser assíncrono e habilitar a utilização de callbacks.
O módulo conector é um administrador de fila lock-free. A fila pode ser
preenchida e consumida por múltiplas threads e, portanto, garantindo utilização
de quantas conexões ou administradores de sensores o usuário achar
necessário.
Bibliotecas de Sensores
Neste projeto também foram feitas traduções de bibliotecas implementadas
apenas para Arduino. Sistemas Arduino são do tipo bare machine ou bare metal,
o que significa que não possuem sistema operacional, portanto não foi somente
necessária a conversão de dependências, mas muitas vezes de lógica, já que a
adição de um sistema operacional faz com que o sistema operacional não seja
perfeitamente em tempo real. As bibliotecas dos seguinte sensores foram
traduzidas para o sistema MRAA:
DHT - Sensores DHT11,DHT21, e DHT22 de temperatura e umidade.
MQ135 – Sensor de qualidade do ar baseado em CO2 e Amônia
MFRC522 – Sensor RFID padrão MFRC522
7.1.4.2 Programa SKControl
Por fim um programa foi desenvolvido para mostrar todas essas funcionalidades
ao medir Temperatura, umidade e qualidade do ar de um recipiente, o qual pode
ter condições acompanhadas em tempo real pelo celular. A descrição do
programa em conjunto com a utilização do SKCLib está apresentada a seguir.
60
7.1.4.3 Como utilizar o SKCLib
a) Criando uma fila para armazenas medidas
#include "SKCLib/RESTQueue.h"
skc::RESTQueue queue(n);
Onde n é o tamanho inicial desejado. Como a conexão com a internet pode ser
desligada quando a inatividade dos sensores, aconselha-se manter o tamanho
inicial com um valor elevado para evitar realocamentos na memória ou
travamento da fila. As funções da fila não são bloqueantes.
b) Criando um cliente de REST/RESTful
#include "SKCLib/RESTClient.h"
skc::RESTClient rc(&queue);
Onde queue é a fila recém criada, ou qualquer fila RESTQueue que o usuário
desejar fazer de interface lock-free. O Cliente irá consumir desta fila sempre que
novos itens forem inseridos. As funções do cliente não são bloqueantes.
c) Criando um administrador de sensores
#include "SKCLib/SensorManager.h"
skc::SensorManager sm(&queue);
61
Onde queue é a fila recém criada, ou qualquer fila RESTQueue que o usuário
desejar fazer de interface lock-free. O administrador de sensor pode receber
sensores para controlar e realizará medições que serão alimentadas à fila. As
funções do administrador não são bloqueantes.
d) Criando um CyberPhysicalDescriptor
“skc:: CyberPhysicalDescriptor” é um descritor ontológico de ambiente, aqui
importante para requisições do OrionContextBroker, que utiliza contextos de
ambiente para categorização de dados.
O descritor padrão pode ser criado:
skc::CyberPhysicalDescriptor::_default_cpd = new CyberPhysicalDescriptor();skc::CyberPhysicalDescriptor::_default_cpd->type = U(“valor”);skc::CyberPhysicalDescriptor::_default_cpd->name = U(“valor”);skc::CyberPhysicalDescriptor::_default_cpd->isPattern = true/false;skc::CyberPhysicalDescriptor::_default_cpd->parentName = U(“valor”);
e) Criando um Sensor
Generalizar sensores é uma tarefa quase impossível na condição atual de
programação, onde cada sensor tem um protocolo de comunicação e tipos de
iterações com seus dados e medidas diferentes. Portanto é necessário ter uma
biblioteca específica para cada sensor desejado, como já existe. Porém para ter
um sensor administrador basta implementar a classe “skc::SensorBehavior”.
A classe “skc::SensorManager” funciona como uma engine de jogos ou como o
próprio Arduino, que chama funções de inicialização e de atualização (loop). De
forma mais detalhada, é responsável por chamar funções virtuais da classe
“skc::SensorBehavior”:virtual vector<IRestRequest*> Start(); virtual vector<IRestRequest*> Stop(); virtual vector<IRestRequest*> Update(); virtual vector<IRestRequest*> Reset();
62
virtual void PowerUp(){} virtual void PowerDown(){}
A função Start é chamada sempre que um sensor for ligado. Stop() é chamada
logo antes do sensor ser desligado. A função Start será chamada apenas 1 vez
e a função Stop nunca será executada para sensores que forem configurados
como AlwaysOn (sempre ligados). A função Update() é chamada uma vez após
estabilização do sensor e repetida conforme taxa de repetição. As funções
PowerUp e PowerDown devem ser implementadas caso o sensor possa ser
ligado ou desligado. Por facilidade o usuário pode utilizar a classe
“skc::PowerPin" que implementa controle de energia utilizando pinos GPIO via
MRAA.
Tomando como exemplo o sensor DHT11, onde DHT.h é a biblioteca dht
traduzida para MRAA:
class DHTBehavior : public SensorBehavior, PowerPin{private:
DHT * dht = NULL;
public:DHTBehavior(uint8_t inpin, uint8_t outpin, uint8_t powerPin, string
id, int delay, int repeat) : SensorBehavior("DHT", id), PowerPin(powerPin){
dht = new DHT(inpin, outpin, 11); //cria o sensorSetTimeCritical(true); //o sensor tem sensibilidade ao tempo,
portanto seu comportamento terá prioridade altaSetSensorUpdateDelay(repeat); //o sensor terá medidas
repetidas a cada "repeat" msSetSensorSetupDelay(delay); // o sensor precisará de "delay"
ms para ligar e só então chamar a função Update()SetEnabled(true); //habilita sensor
}
~DHTBehavior(){if (dht != NULL) delete dht;
63
}
vector<IRestRequest*> Update(){
vector<IRestRequest*> ret = vector<IRestRequest*>(); //cria vetor de respostas
OrionUpdateContextRequest * urs = new OrionUpdateContextRequest("http://52.34.36.40:1026/", skc::CyberPhysicalDescriptor::_default_cpd); //cria requisição do tipo UpdateContext para OrionContextBroker utilizando ambiente “skc::CyberPhysicalDescriptor::_default_cpd”
dht->read(); //faz leitura com sensor
urs->AddData("Humidity", dht->readHumidity()); //adiciona medida ao pacote de dados
urs->AddData("Temperature", dht->readTemperature()); //adiciona medida ao pacote de dados
ret.push_back((IRestRequest*)urs); //insere no vetor de retorno o pacote criado
return ret;};
void PowerUp(){PowerPin::PowerUp();
}void PowerDown(){
PowerPin::PowerDown();}
};
Com cerca de 50 linhas de código foi possível criar um sensor que tomará
medidas conforme determinado pelo programador, terá paralelismo, prioridade
64
de execução e baixa interrupção, alimentará automaticamente uma lista de
medidas que podem ser consumidas por um cliente mais tarde e formata
automaticamente suas medições para formato JSON na requisição do tipo
ContextUpdate do OrionContextBroker.
f) Exemplo de main.cpp:
#include "DHTBehavior.h"#include "SKCLib/RESTQueue.h"#include "SKCLib/RESTClient.h"#include "SKCLib/SensorManager.h"
int main(int argc, char** argv){
skc::RESTQueue rq(16);skc::SensorManager sm(&rq);skc::RESTClient rc(&rq);
DHTBehavior * d = new (sm.AddSensor<DHTBehavior>())DHTBehavior(2, 3, 9, "id", 1000, 60000);
//aqui temos input no pino 2, output no pino 3, controle de enrgia no pino 9, estabilização de energização de 1000ms e medidas a cada 60000ms
sm.Launch();rc.Launch();
for (;;);}
Mais uma vez, com poucas linhas de programação temos um administrador de
threads e energia, um cliente REST e um sensor de temperatura e umidade
enviando dados a um servidor OrionContextBroker do Fiware a cada 60000 ms.
65
Baseado na demonstração supracitada, pôde-se desenvolver a aplicação
desejada de medição das condições de ambiente de recipientes. Todos códigos
produzidos encontram-se no endereço GitHub2.
7.1.4.4 Descrição dos arquivos produzidos
Abaixo segue a descrição de todos arquivos, a documentação pode ser
encontrada no GitHub do projeto2.
Lista de arquivos produzidosSKCLib/ CyberPhysicalDescriptor.h
Contêm classe responsável pela abstração de um ambiente antológico.
A classe é concreta e pode ser declarada como objeto para utilização
por classes que formam pacotes, como OrionUpdateContextRequest.
SKCLib/ EdisonHelper.h
Classe estática que contêm funções de ajuda para o módulo embarcado
Edison, como controle de Bluetooth e WiFi.
SKCLib/ IRestRequest.h
Abstração de pacote REST, classe abstrata por ser implementada para
tipos específicos de requisição, como OrionRestRequest para o caso do
OrionContextBroker.
SKCLib/ InlineHelper.h
Classe estática com funções de ajuda genéricas, porém em sua maioria
de manipulação de tempo.
SKCLib/ InterruptableThread.cpp
Implementação de InterruptableThread.h
SKCLib/ InterruptableThread.h
Classe virtual para construção de “Serviços”. Estes serviços serão
inicializados em threads paralelas e poderão ou não ser interrompidos,
pausados e resumidos. É base para SensorManager e RESTClient.
2 https://github.com/mangine/tcc/.
66
SKCLib/ OrionConvenienceQueryRequest.h
Classe com implementação de IRestRequest.h para as funções de
conveniência do OrionContextBroker[2]
SKCLib/ OrionQueryContextRequest.h
Classe com implementação de IRestRequest.h para as funções de
QueryContext do OrionContextBroker[3]
SKCLib/ OrionRestRequest.cpp
Implementação de OrionRestRequest.h
SKCLib/ OrionRestRequest.h
Classe com implementação de IRestRequest.h para as funções de
UpdateContext do OrionContextBroker (versão simples para testes)
SKCLib/ OrionSubscribeContextRequest.h
Classe com implementação de IRestRequest.h para as funções de
SubscribeContext do OrionContextBroker[4]
SKCLib/ OrionUnsubscribeContextRequest.h
Classe com implementação de IRestRequest.h para as funções de
UnsubscripbeContext do OrionContextBroker[4]
SKCLib/ OrionUpdateContextRequest.h
Classe com implementação de IRestRequest.h para as funções de
ContextUpdate do OrionContextBroker [5]
SKCLib/ OrionUpdateContextSubscriptionRequest.h
Classe com implementação de IRestRequest.h para as funções de
UpdateContextSubscription do OrionContextBroker[4]
SKCLib/ PowerPin.h
Classe com implementação de PowerUp() e PowerDown() para
dispositivos que têm energia controla por pinos GPIO via mraa.
SKCLib/ RESTClient.cpp
Implementação de RESTClient.h
SKCLib/ RESTClient.h
Cliente RESTful, para conexão e envio de pacotes REST. É um serviço
que é executado em paralelo.
67
SKCLib/ RESTQueue.h
Fila lock-free para armazenamento de objetos de tipo “IRestRequest*”,
ou seja, qualquer pacote REST que possa ser enviado a um servidor.
SKCLib/ SensorBehavior.h
Classe abstrata que descreve comportamento de qualquer sensor. Deve
ser implementada para sensores que forem ser controlados e
administrados por “skc::SensorManager”
SKCLib/ SensorManager.cpp
Implementação de SensorManager.h
SKCLib/ SensorManager.h
Administrador de Sensores que sejam derivados da Classe
“skc::SensorBehavior”. É um serviço que é executado em paralelo.
SKCLib/ TestBehavior.h
Sensor Virtual para testes.
SKCLib/ Vectors.h
Implementação de funções adicionais com vetores para facilitar
programação.
SKCLib/ ZigBeehavior.h
Implementação de “skc:: SensorBehavior” para sensor ZigBee.
SKCLib/ skc.h
Header global com definições.
Sensors/ DHT.cpp
Implementação de DHT.h
Sensors/ DHT.h
Biblioteca para sensores da família DHT, traduzido para mraa.
Sensors/ MFRC522_mraa.cpp
Implementação de mfrc522_mraa.h
Sensors/ mfrc522_mraa.h
Biblioteca para sensores do padrão de comunicação MFRC522,
traduzido para mraa.
68
Sensors/ mq135.cpp
Implementação de mq135.h
Sensors/ mq135.h
Biblioteca para sensor MQ135, traduzido para mraa.
DHTBehavior.h
Implementação de SensorBehavior para a biblioteca DHT.
MQ135Behavior.h
Implementação de SensorBehavior para a biblioteca MQ135.
globals.h
Header de globais para main.cpp
main.cpp
Função de exemplo para utilização da biblioteca, implementada para recipientes e
OrionContextBroker.
config.json
Configurações de execução do programa main.
7.2 COMUNICAÇÃO
A plataforma escolhida para concluir o projeto é o Fiware.
Atividade/Sensor ou módulo Bluemix (desenvolvimento)
FIWARE
Conexão ✓
Fabricação de JSON (NGSI10) ✓ ✓
Envio de Mensagens ✓
Recebimento de Mensagens ✓
Teste & Validação ✓Table 11 - Avaliação: plataforma de comunicação
69
Inicialmente, por se tratar de uma ferramenta muito simples de manipular
e aprender, principalmente para iniciantes em IoT, escolhemos, o Bluemix para
realizar o primeiro teste do protótipo do projeto. Posteriormente, o plano era
migrar para o Fiware, o qual é o software padrão para projetos desse tipo, sendo
este um dos requisitos propostos pelo grupo.
Figure 23 Implementação da comunicação na ferramenta Bluemix
Desenvolvemos boa parte da parte de comunicação do projeto na
plataforma Bluemix, no entanto no dia 30 de outubro de 2015, o serviço
MongoDB, foi removido do Bluemix, o que nos obrigou a mudar para o Fiware.
Figure 24 Notícia sobre a remoção do Mongo
70
7.2.1 Fiware
Figure 25 Logo do produto
Lançado 6 de setembro de 2013, o Fiware é uma plataforma que oferece
um conjunto simples, mas poderoso de APIs (Application Programming
Interfaces) que facilita o desenvolvimento de aplicativos inteligentes. As
especificações desses APIs são públicas e gratuitas. Além disso, uma referência
open source para implementação de cada componente do FIWAre é pública, de
forma que diversos provedores com baixo custo de Fiware podem surgir
rapidamente no mercado.
O Fiware se conecta a base de dados, Mongo DB, por ODBC (Open-
Database-Connectivity), o qual facilita a movimentação de dados com diferentes
estruturas.
7.3 BASE DE DADOS
Figure 26 Logo do produto
A base de dados será construída a partir do programa MongoDB. Lançada em
2009, trata-se de um banco de dados NoSQL orientado a documentos,
escalável, de alta performance e livre de esquemas, ou seja, um banco de dados
de documento:
-NoSQL: abreviação de Not Only SQL (não apenas SQL) tem por objetivo de
atender aos requisitos de gerenciamento de grandes volumes de dados, semi-
estruturados ou não estruturados. Esses bancos de dados NoSQL são
amplamente adotados em empresas como Facebook, Amazon e Google com o
intuito de atender às suas demandas de escalabilidade, alta disponibilidade e
dados não estruturados
71
-Documentos: unidades básicas de armazenamento e estes não utilizam
necessariamente qualquer tipo de estruturação pré-definida, como é o caso das
tabelas do Modelo Relacional. Logo, o MongoDB armazena coleções de
documentos. Um documento, em geral, é um objeto com um identificador único
acrescido de um conjunto de campos, que podem ser strings, listas ou
documentos aninhados. Neste modelo temos um conjunto de documentos e em
cada documento temos um conjunto de campos (chaves) e o valor deste campo.
Outra característica importante é que este modelo não depende de um esquema
rígido, ou seja, não exige uma estrutura fixa como ocorre nos bancos
tradicionais, os relacionais. Assim, é possível que ocorra uma atualização na
estrutura do documento, com a adição de novos campos, por exemplo, sem
causar problemas na estrutura do banco de dados. Esta flexibilidade é uma das
grandes vantagens deste modelo.
-Modelo de armazenamento orientado a documento: armazena documentos
no estilo parecido JSON chamado BSON, como documentos com
esquemas dinâmicos, quer dizer que eu não preciso ter a mesma estrutura em
casa registro. O objetivo do MongoDB é preencher a lacuna entre
valores/chave lojas (que são rápidos e escalonáveis) e bancos de dados
relacionais (que têm a funcionalidade rica). Atualizações in-place rápidas, ou
seja, uma transação atômica.
Figure 27 Execução do Mongodb no terminal
72
7.4 DESENVOLVIMENTO MOBILEEssa seção do relatório é destinada a documentação do desenvolvimento
da aplicação mobile pertencente ao sistema elaborado nesse projeto. A primeira
atividade referente a essa frente de trabalho foi a pesquisa e analise dos
diversos sistemas operacionais existentes para smartphone. Através da
pesquisa e do levantamento de requisitos o sistema operacional escolhido foi o
Android. Os requisitos escolhidos e a comparação entre os sistemas ja foi
mostrada anteriormente nesse relatório.
A seguinte sequência de atividades foram realizadas para a criação da aplicação
mobile:
p) Leitura e aprendizagem do sistema operacional (Android)
q) Download e estudo do ambiente de programação
r) Estudo das APIs disponíveis
s) Estudo dos tutoriais das principais funcionalidades de programação
mobile
t) Criação das primeiras aplicações mobiles
u) Estruturação tela a tela do protótipo
v) Criação do design da aplicação
w) Organização de um modelo interativo para a criação da aplicação
x) Criação da aplicação
y) Integração da aplicação com o banco de dados
z) Testes finais da aplicação
73
7.4.1 Android Studio
Figure 28 Logo do ambiente de programação
O Android Studio é pacote de desenvolvimento do sistema android, ele é
formado pelos seguintes componentes: Android Studio IDE, Android SDK tools,
Android 6.0 Platform, Android 6.0 emulator system image com API's da Google.
Os requerimentos de sistema são:
Microsoft® Windows® 8/7/Vista/2003 (32 or 64-bit)
2 GB RAM minimum, 4 GB RAM recommended
400 MB hard disk space
At least 1 GB for Android SDK, emulator system images, and caches
1280 x 800 minimum screen resolution
Java Development Kit (JDK) 7
Optional for accelerated emulator: Intel® processor with support for Intel®
VT-x, Intel® EM64T (Intel® 64) and Execute Disable (XD) Bit functionality
Uma das suas características do Studio é a capacidade de multi-telas,essa
possibilidade facilita o desenvolvimento do código ao mesmo tempo que o
resultado de design pode ser visto e os diretórios de arquivos. Um exemplo
dessa funcionalidade do Studio pode ser vista abaixo:
74
Figure 29 Tela de desenvolvimento
Devido a grande pluralidade de smartphones compatíveis que rodam o
Android, uma das tarefas mais complicadas no desenvolvimento é a criação de
um design que seja compatível com todas as telas de celulares. Como
consequência, o Studio oferece um banco de perfis de telas já pré-definidos,
facilitando o desenvolvimento do design, esse banco de perfis pode ser visto
abaixo.
Figure 30 Tela de desenvolvimento para multi produtos
75
8 VALIDAÇÃO DO PROJETO8.1 RESULTADO DOS TESTES
8.1.1 Testando a alimentação do sistema
Em suma, esta etapa possui duas funções:
1- Fornecer alimentação para o funcionamento dos sensores
2- Controlar remotamente os sensores, acionando somente o sensor a ser lido de forma obter um sistema “inteligente” de controle de energia
Vale ressaltar que a dificuldade de projetar esse sistema foi
principalmente decorrente das diferentes tensões em que cada componente
opera.
Inicialmente testamos o circuito com TBJ TIP31, que aguenta uma
corrente alta que passa pelo sensor (cerca de 800mA). No entanto, a queda de
tensão entre o coletor e emissor era muito alta, de modo que foi necessário
utilizar um outro transistor, o MOSFET smd. Com o novo modelo de transistor, a
queda de tensão era bem menor, quase insignificante, e assim, conseguimos
manter a tensão de 5V ou 3,3V para alimentar os sensores.
O circuito impresso foi projetado no software Eagle e os testes foram
feitos, inicialmente, no protoboard.
Figure 31 Teste do projeto no protoboard
76
Além do circuito a ser feito em laboratório, também foi necessário pensar
na alimentação do próprio Edison, com 5V a partir de duas baterias de celular
Samsung em série, que resulta em 6,4V. Para tal, utilizamos um regulador de
tensão de 5V.
E, para alimentar o sensor com 3.3V, utilizamos um regulador de tensão
Ams 1117 de 4.5V-7V para 3.3V. Também, foi necessário adquirir um conversor
bidirecional lógico 3.3 – 5V.
Figure 32 Teste do sistema de alimentação
Obtivemos um sistema de alimentação compatível com o funcionamento do
circuito.
8.1.2 Testando o aplicativo Android
O aplicativo foi instalado no celular de um dos integrantes.
Na tela inicial, há 2 botões:
-Configurações: o usuário pode configurar os parâmetros máximos dentro
do reciente
-Visualização dos recipientes: o usuário pode ver em tempo real as
condições do ambiente do recipiente
77
Figure 33 Teste do aplicativo
8.1.3 Testando a comunicação, embarcado e sensores
O programa SKC pode ser compilado e executado com sucesso no módulo
Edison, além de enviar corretamente os dados para a nuvem, como mostrado na
figura a seguir, seu comportamento com sensores também pode ser visto:
Figure 34 Teste da comunicação
78
Inicialmente inicializando objetos. Mais tarde colocando todo módulo em espera,
para economia de energia. Na etapa seguinte ele liga sistemas novamente,
como o WiFi, alguns segundos antes de processar os pacotes. Faz leitura com o
sensor DHT e envia via REST seguindo o padrão do Orion Context Broker.
Novamente prepara-se para entrar em espera, já que nenhum sensor ficará ativo
nos próximos 10 segundos.
79
9 SUMÁRIO E CONCLUSÕESO projeto em sua essência tem por objetivo aplicar os conceitos de
Internet das Coisas, IoT, para auxiliar no dia-a-dia das pessoas. Acreditamos
que a tecnologia pode contribuir na realização das tarefas do cotidiano e, que
em um futuro próximo quando o IoT estiver bem desenvolvido, este
revolucionará a vida das pessoas e o mundo em que vivemos como foi o caso
dos computadores, do Windows, da Google e do Android.
No caso do projeto de formatura, escolhemos aplicar esse conceito de
IoT para monitorar variáveis de ambiente remotamente e, para concretizar e
tangibilizar a ideia, definimos um caso prático dessa aplicação. Dessa forma,
delimitamos o projeto para: controle da temperatura, umidade e concentração de
gás amônia de um recipiente por meio de um aplicativo smartphone, o SK-
Control. Este conceito de controle de variáveis remotamente, entretanto, pode
ter diversas aplicações, como por exemplo, no campo da medicina no caso de
armazenamento de órgãos para transplante; no campo da pesquisa, para
monitorar o ambiente de um laboratório; ou mesmo no dia-a-dia das pessoas,
para determinar se um alimento está estragado ou não, como é o caso do
projeto em questão.
Quanto a nossa escolha do tema, a decisão de trabalhar no limite do
estado-da-arte deste campo foi, ao mesmo tempo, algo muito atrativo e
promissor, assim como foi uma ideia audaciosa, já que não tínhamos uma
comunidade desenvolvida para esclarecer dúvidas e guiar a implementação do
projeto idealizado. Neste contexto, o grupo passou horas e horas apenas
estudando e realizando testes para descobrir como implementar esse conceito
na forma mais básica. Foi necessário ter muita resiliência e determinação para
construir o que foi proposto e, claramente, no início, não suspeitávamos que
seria tão difícil assim.
Quanto ao projeto, este possui como componentes 3 sensores, um de
temperatura, um de umidade e outro para controle de validade. Esses sensores
são controlados por uma Placa Edison que também fica próximo ao ambiente
80
controlado. A placa monitora os valores dos componentes do ambiente
analisados e manda essas informações via web a um servidor. Esse servidor
possui um banco de dados MongoDB onde ele guarda todas essas informações.
Por fim, essas informações podem ser requisitas por um usuário via aplicação
mobile.
Além disso, o sistema criado possibilita a adição de novos sensores de
forma fácil e ágil, sendo dessa forma facilmente expandível. Todo um sistema de
manipulação de threads foi criado. Placas reguladoras de tensão, controle de
energia e de comunicação foram utilizadas também como partes auxiliares do
sistema.
O protótipo criado cumpre a sua função de monitoramento das
componentes ambientais que cercam o produto e por ter um caráter expansível,
pode ser usado como base para um sistema mais complexo.
De forma geral, o resultado do projeto foi acima do esperado, dado seu
grau de dificuldade e complexidade. O projeto demandou aplicar muitos
conceitos estudados durantes esses 5 anos de faculdade: trabalhamos com
eletrônica 0, 1 e 2; circuitos 1 e 2; tópicos de programação; arquitetura e redes;
práticas de eletrônica 1 e 2; introdução a programação, entre outras matérias. E,
após 1 ano árduo de trabalho, conseguimos construir um sistema, por meio do
qual um aplicativo android recebe informações sobre a temperatura, umidade e
concentração de gás amônia de um recipiente.
Em suma, acreditamos que o produto possui valor no mercado, podendo
facilmente continuar sendo objeto de estudo e desenvolvimento. Inclusive, ao
longo do projeto, o grupo pensou em diversas formas de como aprimorar o
produto, porém era inviável prosseguir com tais idéias naquele momento, mas
não deixam de ser possíveis tópicos de estudo no futuro. Com certeza, foi um
enorme aprendizado trabalhar nesse projeto e estamos satisfeitos com o
resultado.
É válido mencionar que o objetivo do projeto sofreu alterações ao longo
do processo de execução, entretanto, a idéia por trás do projeto prevalece a
81
mesma, que corresponde a aplicação de IoT como ferramenta de auxílio no dia-
a-dia das pessoas
82
10 BIBLIOGRAFIA
[1] Nguyen Gia, T. " Implementation of a Smart Fridge by Using RFID and Web Technology".Bachelor's tesis, 2012
[2] Rouillard, J. " The Pervasive Fridge" , LIFL Laboratory – University of Lille 1, 2012
[3] Byungrak Son, Chang-Sub Han, Yong-Tae Jeon e Dong-Ha Lee. A RFID/NFC Fusion based Smart Refrigerator for Wellness Service", Welleness Convergence Research Center, DGIST, Daegu, South Korea, 2014
[4] Osisanwo F.,Kuyoro S., Awodele O. " Internet Refrigerator –A typical Internet of Things (IoT). 3rd International Conference on Advances in Engineering Sciences & Applied Mathematics (ICAESAM’2015) March 23-24, 2015 London (UK)
[5] Padrão ISO: ISO/IEC 14443-1:2008 Identification cards - Contactless integrated circuit cards
[6] Angell, I., Kietzmann, J. (2006). "RFID and the end of cash?" (PDF). Communications of the ACM 49 (12): 90–96. doi:10.1145/1183236.1183237.
[7] "O Que é a Internet Das Coisas?" Futurecom Blog. N.p., 18 Julho 2013. Web. 22 Abril 2015.
[8] "FIWARE." FIWARE. N.p., n.d. Web. 21 May 2015.
[9] "36" Wide, 28 Cu. Ft. 4-Door Refrigerator with 8" Wi-Fi Enabled LCD and Counter-Height FlexZone™ Drawer." Samsung Electronics America. Web. 1 July 2015. <http://www.samsung.com/us/appliances/refrigerators/RF28HMELBSR/AA#>.
[10] "LG LFX31995ST: Smart ThinQ™ Super-Capacity 3 Door French Door Refrigerator with 8" Wi-Fi LCD Screen." Web. 1 July 2015. <http://www.lg.com/us/refrigerators/lg-LFX31995ST-french-3-door-refrigerator>.
[11] "Submarino.com." Geladeira / Refrigerador Electrolux DT80X Infinity Frost Free I Kitchen. Web. 1 July 2015. <http://www.submarino.com.br/produto/7339567/geladeira-refrigerador-electrolux-dt80x-infinity-frost-free-i-kitchen#productdetails>.
[12] "IBM Bluemix - Next-Generation Cloud App Development Platform." IBM Bluemix - Next-Generation Cloud App Development Platform. Web. 1 July 2015.
[13] "Google APIs Explorer." Google APIs Explorer. Web. 1 July 2015. https://developers.google.com/apis-explorer/#p/
83
[14] "Intel-iot-devkit/mraa." GitHub. Web. 07 Dec. 2015. https://github.com/intel-iot-devkit/mraa/wiki
[15] “Yocto Project”. Wikipedia. Wikimedia Foundation, Web. 07 Dec. 2015https://en.wikipedia.org/wiki/Yocto_Project
[16] "Installing Development Tools onto Galileo Official Linux Image." AlexTs Galileo Edison Blog. 19 June 2014. Web. 07 Dec. 2015. http://alextgalileo.altervista.org/blog/installing-development-tools-onto-official-linux-image/
[17] "AlexT's Galileo & Edison Pages." Edison Package Repo Configuration Instructions. Web. 09 Dec. 2015. http://alextgalileo.altervista.org/edison-package-repo-configuration-instructions.html
[18] "Installing Orion." Fiware-Orion. Web. 07 Dec. 2015. https://fiware-orion.readthedocs.org/en/develop/admin/install/index.html
[19] “PuTTY”. Web. 07 Dec 2015. http://www.putty.org/
[20] "Using Flash Tool Lite." IoT -. Web. 07 Dec. 2015. https://software.intel.com/en-us/using-flash-tool-lite
[21]https://github.com/mangine/tcc/
[22]http://fiwareorion.readthedocs.org/en/develop/user/walkthrough_apiv1/index.html#ngsi10-convenience-operations
[23]http://fiwareorion.readthedocs.org/en/develop/user/walkthrough_apiv1/index.html#query-context-operation
[24]http://fiwareorion.readthedocs.org/en/develop/user/walkthrough_apiv1/index.html#context-subscriptions
[25]http://fiwareorion.readthedocs.org/en/develop/user/walkthrough_apiv1/index.html#update-context-elements
[26] https://svn.boost.org/trac/boost/changeset/84950
84
11 ANEXOS11.1 ANEXO 1 – HOUSE OF QUALITY
85
11.2 ANEXO 2 - GANT
O Gant e mais detalhes das atividades se encontram a seguir.
86
