UNIVERSIDADE DE SÃO PAULOESCOLA DE ENGENHARIA DE SÃO CARLOS

Victor Oliveira Boppré

Modelo para controle de acesso utilizando Internet dasCoisas

São Carlos

2018

Victor Oliveira Boppré

Modelo para controle de acesso utilizando Internet dasCoisas

Monografia apresentada ao Curso de Enge-nharia Elétrica com Ênfase em Eletrônica,da Escola de Engenharia de São Carlos daUniversidade de São Paulo, como parte dosrequisitos para obtenção do título de Enge-nheiro Eletricista.

Orientador: Prof. Dr. Evandro Luis LinhariRodrigues

São Carlos2018

AUTORIZO A REPRODUÇÃO TOTAL OU PARCIAL DESTE TRABALHO,POR QUALQUER MEIO CONVENCIONAL OU ELETRÔNICO, PARA FINSDE ESTUDO E PESQUISA, DESDE QUE CITADA A FONTE.

Ficha catalográfica elaborada pela Biblioteca Prof. Dr. Sérgio Rodrigues Fontes daEESC/USP com os dados inseridos pelo(a) autor(a).

Boppré, Victor Oliveira Bm Modelo para controle de acesso utilizando Internet

das Coisas / Victor Oliveira Boppré; orientador EvandroLuis Linhari Rodrigues. São Carlos, 2018.

Monografia (Graduação em Engenharia Elétrica com ênfase em Eletrônica) -- Escola de Engenharia de SãoCarlos da Universidade de São Paulo, 2018.

1. Controle de acesso. 2. Monitoramento de acesso. 3. Internet das Coisas. 4. Sistemas Embarcados. 5.Smart Cities. I. Título.

Eduardo Graziosi Silva - CRB - 8/8907

-FOLHA DE APROVAÇAO

Nome: Victor Oliveira Boppré

Títu lo: "Modelo para controle de acesso utilizando Internet das Coisas"

Trabalho de Conclusão de Çurso defendido e aprovado em2 J I !..f_t 2 OJ 8 ,

com NOTA!} fi (1\/cJvt , (); 70 ), pela Comissão Julgadora:

Prof. Associado Evandro Luís Linhari Rodrigues - Orientador -SEUEESCIUSP

Prof. Assistente Edson Gesua/do - SEUEESCIUSP

Mestre Leonardo Mariano Gomes - Doutorando - SEUEESC/USP

Coordenador da CoC-Engenharia Elétrica - EESC/USP: Prof. Associado Rogério Andrade Flauzino

Este trabalho é dedicado as ciências, e todo seu progresso.

AGRADECIMENTOS

A todos que estiveram comigo durante a graduação, principalmente aos meusfamiliares, namorada, amigos e professores.

Aos meus familiares, agradeço por todo apoio, pois sem eles eu não teria alcançadouma graduação universitária.

Aos meus amigos e namorada, por prestarem todo apoio e momentos bons durantesesta etapa.

Aos professores e funcionários da universidade, que se dedicam, diariamente, auxili-ando na realização de nossos sonhos.

A Deus, por permitir esse momento e a presença de todos estes.

“Toutes les richesses du monde ne valent pas un bon ami”Voltaire

RESUMO

Boppré, Victor O. Modelo para controle de acesso utilizando Internet dasCoisas. 2018. 72p. Monografia (Trabalho de Conclusão de Curso) - Escola de Engenhariade São Carlos, Universidade de São Paulo, São Carlos, 2018.

A partir das filosofias de Smart Cities e Internet das Coisas, este trabalho visa proporum novo método, de baixo custo, de controle e monitoramento de acesso em ambientescontrolados. Este controle a ambientes será possível por meio de uma aplicação webimplementada em Python por meio do Framework Flask. Para o monitoramento o utilizador,com as credenciais necessárias, poderá acessar dados, alocados no Firebase, por meio deuma página na Web. A validação desta aplicação ocorreu pela plataforma NodeMCU, quepor meio do protocolo MQTT, atendeu as requisições feitas pela aplicação web.

Palavras-chave: Internet das Coisas, Smart Cities, Controle de Acesso, Monitoramentode Acesso, Sistemas Embarcados.

ABSTRACT

Boppré, Victor O. Model of acess control using Internet of Things. 2018. 72p.Monografia (Trabalho de Conclusão de Curso) - Escola de Engenharia de São Carlos,Universidade de São Paulo, São Carlos, 2018.

Based on the philosophies of Smart Cities and Internet of Things, this work aims topropose a new low cost method of access control. Access to environments will be possiblethrough a web application implemented in Python through the Framework Flask. Formonitoring, the user, with the necessary credentials, can access data, allocated in Firebase,through a Web page. To validate this system was used a NodeMCU platform, that responsethe requests throughout MQTT protocol.

Keywords: Internet of Things, Smart Cities, Acess Control, Access monitoring, EmbeddedSystems.

LISTA DE FIGURAS

Figura 1 – Arquitetura proposta para o projeto. . . . . . . . . . . . . . . . . . . . 25Figura 2 – Modelo de dados do banco de dados do Firebase. . . . . . . . . . . . . 28Figura 3 – Pagina de trabalho do Firebase e suas aplicações no lado esquerdo. . . 29Figura 4 – Camadas do protocolo TCP/IP. . . . . . . . . . . . . . . . . . . . . . . 30Figura 5 – Exemplificação do protoco MQTT. . . . . . . . . . . . . . . . . . . . . 31Figura 6 – Mensagem a ser enviada por HTTP. . . . . . . . . . . . . . . . . . . . 32Figura 7 – Palavra exemplo em código de barras, utilizando a codificação code39. . 34Figura 8 – Imagem Raspberry Pi 2. . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figura 9 – Ilustração do NodeMCU, com as designações de cada pino. . . . . . . . 37Figura 10 – Design dos templates das páginas para monitores. . . . . . . . . . . . . 40Figura 11 – Templates das páginas para smartphones e tablets. . . . . . . . . . . . 40Figura 12 – Página inicial do projeto, segmentada nos blocos funcionais nav,body e

footer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Figura 13 – Fluxograma da rota "cadastro". . . . . . . . . . . . . . . . . . . . . . . 44Figura 14 – Célula de dados do usuário chamado ’user ’ . . . . . . . . . . . . . . . . 44Figura 15 – Fluxograma da rota "login". . . . . . . . . . . . . . . . . . . . . . . . . 45Figura 16 – Fluxograma para criar uma sala e sua vinculação com um usuáro. . . . 46Figura 17 – Célula de sala e seus atributos. . . . . . . . . . . . . . . . . . . . . . . 46Figura 18 – Fluxograma para garantir o acesso a um usuário a uma sala, durante

uma determinada faixa de tempo. . . . . . . . . . . . . . . . . . . . . . 47Figura 19 – Fluxograma para acessar uma sala. . . . . . . . . . . . . . . . . . . . . 48Figura 20 – Fluxograma acessas o "log"de uma sala. . . . . . . . . . . . . . . . . . . 49Figura 21 – Fluxograma para criação e exibição do Qr code de um usuário. . . . . . 50Figura 22 – Fluxograma para identificação do Qr code de um usuário. . . . . . . . 51Figura 23 – Fluxo de informação entre os dispositivos. . . . . . . . . . . . . . . . . 52Figura 24 – Fluxograma do método de comunicação MQTT implementado na Rasp-

berry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Figura 25 – Fluxograma de configuração do NodeMCU. . . . . . . . . . . . . . . . . 54Figura 26 – Fluxograma de "callback"do NodeMCU. . . . . . . . . . . . . . . . . . . 55Figura 27 – Utilização dos recursos da Raspberry Pi 2 . . . . . . . . . . . . . . . . 57Figura 28 – Página inicial mostrada em dispositivos com alta resolução. . . . . . . 60Figura 29 – Página inicial mostrada em dispositivos com baixa resolução. . . . . . . 60Figura 30 – Página de cadastro mostrada em dispositivos com alta resolução. . . . 61Figura 31 – Página de cadastro mostrada em dispositivos com alta resolução. . . . 62Figura 32 – Página de login mostrada em dispositivos com alta resolução. . . . . . 62Figura 33 – Página de login mostrada em dispositivos com alta resolução. . . . . . 63

Figura 34 – Mudança na barra de navegação em dispositivos de alta resolução (a) eem baixa resolução(b). . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Figura 35 – Body da página de consulta de log de salas (a)caso o usuário sejaadministrador de alguma sala;(b) caso o usuário não administre algumasala. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Figura 36 – (A) corpo de página renderizado se o usuário identificado não foradministrador de alguma sala;(B) corpo de página renderizado se ousuário for administrador de alguma sala. . . . . . . . . . . . . . . . . 64

Figura 37 – Corpo da página renderizada quando o NodeMCU não responde em até10 segundos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Figura 38 – Corpo da página renderizada quando há uma resposta do NodeMCU. . 65Figura 39 – Corpo da página renderizada exibindo o QR code do usuário. . . . . . . 65

LISTA DE ABREVIATURAS E SIGLAS

ARM Advanced RISC Machine

API Application Programming Interface - Interface de programação deaplicações

CRLF Carriage Return Line Feed

CPU Central Processing Unit - Unidade central de processamento

CSS Cascading Style Sheets - Folhas de Estilo em Cascata

DNS Domain Name System - Sitema de nome de domínio

FTP File Transfer Protocol - Protocolo de transferência de arquivos

GPGPU General Purpose Graphics Processing Unit - Unidade de Pro-cessamento Gráfico de Propósito Geral

GPIO General Purpose Input/Output - Entrada/saída de propositogeral

GPS Global Positioning System - Sistema de posicionamento global

GPUGraphics Processing Unit -Unidade de processamento gráfico

HDMI High-Definition Multimedia Interface - Interface Multimídia deAlta Resolução

HTML HyperText Markup Language - Linguagem de Marcação deHipertexto

HTTPS High-Definition Multimedia Interface - protocolo de transferên-cia de hipertexto seguro

IDE Integrated Development Environment - Ambiente de desenvolvi-mento integrado

IEEE Institute of Electrical and Electronics Engineers - Instituto deEngenheiros Elétricos e Eletrônicos

IoT Internet of things - Internet das coisas.

IP Internet Protocol - Protocolo de Internet

JSON JavaScript Object Notation - Notificação de objeto JavaScript

MCU Microcontroller Unit - Unidade de Microcontrolador

MIT Massachusetts Institute of Technology - Instituto de Tecnologia deMassachusetts

MQTT Message Queuing Telemetry Transport - Transporte de teleme-tria do serviço de enfileiramento de mensagens

PDF Portable Document Format - Formato de documento portátil

PNG Portable Network Graphics - Gráficos Portáteis de Rede

QR Quick Response - Resposta rápida

RAM Randon Acess Memory - Memória de acesso aleatório

RFID Radio-Frequency Identification - Identificação radiofrequência

SPI Serial Peripheral Interface - Interface Periférica Serial

SSH Secure Shell - Capsula segura

SVG Scalable Vector Graphics - Gráficos vetoriais escaláveis

TCP Transmission Control Protocol - Protocolo de controle de trans-missão

UDP User Datagram Protoco - Protocolo de datagrama do usuário

UPC Universal Product Code - Código universal de produto

URL Uniform Resource Locato - Localizador uniforme de recursos

USB Universal Serial Bus - Barramento serial universal

WWW World Wide Web - Rede mundial de computadores

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.3 Justificativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.4 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 25

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . 272.1 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.1.1 Firebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2 Aplicação Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2.1 Rede de computadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.1.1 TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.1.2 MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.2.1.3 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.3 Sistemas Embarcados . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.4 Códigos de barras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.4.1 QR code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 DESENVOLVIMENTO DO PROJETO . . . . . . . . . . . . . . . . 353.1 Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.1 Raspberry Pi model 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.2 NodeMCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.1.3 Python-Firebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.4 Paho MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.5 Py Zbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.6 Python QR code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.7 Flask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.8 Eclipse IoT Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.9 Materialize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2 Métodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.1 Interface Web e fluxo de dados . . . . . . . . . . . . . . . . . . . . . . . . 403.2.1.1 Página Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2.1.2 Página de cadastro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2.1.3 Página de Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2.1.4 Criar uma sala e vincular a um usuário . . . . . . . . . . . . . . . . . . . . 453.2.1.5 Disponibilizar uma sala a um usuário . . . . . . . . . . . . . . . . . . . . . 47

3.2.1.6 Utilizar uma sala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.1.7 Verificar o log da sala . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.2.1.8 Identificação do usuário por meio do Qr code . . . . . . . . . . . . . . . . 493.2.2 Comunicação MQTT entre plataformas . . . . . . . . . . . . . . . . . . . 513.2.2.1 Método de comunicação com o NodeMCU e com Timeout . . . . . . . . . 523.2.2.2 Comunicação MQTT no NodeMCU . . . . . . . . . . . . . . . . . . . . . 52

4 RESULTADOS E DISCUSSÕES . . . . . . . . . . . . . . . . . . . . 574.1 Raspberry Pi 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.1.1 NodeMCU e MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.2 Aplicação Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

23

1 INTRODUÇÃO

Em algumas aplicações faz-se necessário o controle e o monitoramento de pessoasque acessam um ambiente ou usufruem determinado serviço, garantindo de forma seletivae restritiva, para que apenas aqueles que possuem autorização possam os utilizar. Segundoa empresa de segurança Fermax, neste ramo, o controle de acesso é a área que estuda osmelhores e mais confiáveis modelos e métodos que realizam as ações descritas acima(1). Aidentificação do usuário pode advir de dispositivos físicos como tickets, cartões RFID edocumentos; por escaneamento biométricos como digitais, palma da mão(2) e facial,talqual implementado no Iphone X(3); e credenciamento virtual, podendo ser realizadopor dispositivos como computadores, smartphones e tablets; além de algoritmos de visãocomputacional, que possibilitam a identificação de objetos, QR codes e códigos de barra.

No Brasil, observa-se uma ampla utilização do reconhecimento biométrico, estandoeste presente em bancos(4)(5)(6)(7), e no sistema eleitoral(8). Dentre os sistemas citados,os métodos utilizados de biometria foram os do escaneamento da digital, que consistena utilização de algorítimos para reconhecer os padrões das linhas presentes na digitaldo usuário(9); e da a verificação do vasos sanguíneos presentes na mão, que utiliza umsensor de infra-vermelho curto para a verificação da atividade sanguínea do usuário ecom isso reconhecer os parâmetros de suas veias. Este método é considerado mais seguro,comparado ao do reconhecimento da digital, uma vez que este pode ser fraudado utilizando-se uma superfície igual a de um usuário já cadastrado(10). Mesmo sendo utilizada emdiversos setores no Brasil, o reconhecimento biométrico possui algumas desvantagens se acompararmos com outros métodos. Segundo a análise(11), elas podem ser listadas como:dificuldade na atualização de dados em locais onde há mudança contínua de usuários, ocusto de instalação é mais caro comparado a outros sistemas e dificuldade, com magnitudepouco expressiva, de identificar e cadastrar alguns usuários.

A utilização e aquisição de smartphones, no Brasil, mostra-se com comportamentocrescente. Em um estudo chamado Consumer Barometer realizado pela Google com intuitode descobrir como a internet é utilizada e os seus principais meios de acesso, mostrou queaproximadamente 62% da população brasileira tem acesso a celulares. O estudo tambéminforma que 69% da população tem acesso a internet, sendo que a maior parte dela utilizasmartphones para se conectar.(12).

O uso de celulares extrapolou sua funcionalidade primordial, a partir destes aces-sórios consegue-se ter acesso a aplicações que envolvem transações entre bancos, dadosprecisos de GPS, informativos e monitoramento da saúde física e emocional, mineração decriptomoedas ,controle de pessoas e identificação(13). Nestes dois últimos assuntos, pode-sedestacar a popularidade do credenciamento digital como forma de identificação por meio

24

de projetos como o Sympla, que é um sistema de vendas de ingresso, cuja a identificaçãodo comprador pode ser realizada pode meio do reconhecimento de um QR Code geradopelo aplicativo para celulares da empresa, evitando-se a impressão do ingresso(14). Deforma similar, a Justiça Eleitoral brasileira desenvolveu o e-Título, que é um aplicativoque garante o acesso a uma via digital do título de eleitor, viabilizando que o usuário queo possua, o utilize como documento para votar(15).

O ramo de pesquisa de visão computacional, tem contribuído para diversas ativida-des humanas. Sua aplicação pode ser observada em diferentes setores industriais, desdea verificação da qualidade de produtos e de parâmetros de processos de manufatura(16);médicos, como o estudo e análise imagens médicas(17)(18); além de seus algoritmos auxili-arem os processos de identificação, que podem ser utilizados em sistemas de controle deacesso. O cenário brasileiro mostra uma tendência crescente na instalação de circuitos decâmeras de vigilância(19), facilitando a obtenção de imagens para serem utilizadas nestesalgoritmos. Dentre os desenvolvidos, para a finalidade de controle de acesso, podem serdestacados os de identificação biométrica, como: análise facial(20), iris e digital(21); alémdaqueles que permitem a identificação de objetos e dados da imagem, como o sistemaDetecta(22), que permite detectar informações de veículos, como sua placa, modelo, ano ecoloração. A partir destas informações, este algoritmo, verifica se houve uma utilizaçãoem casos criminais e a validade de seus documentos, auxiliando o trabalho da polícia.

1.1 Motivação

A crescente filosofia do movimento maker e o fortalecimeto do Iot, além da facilidadede obtenção de informações relacionadas a eletrônica e computação por meio da comunidadeque defende a ideologia OpenSource, motivaram a elaboração deste trabalho. Além do fatodo projeto final ter um potencial valor comercial, alta reprodutibilidade e confiabilidadepara aplicação.

1.2 Objetivos

Criar um sistema de controle de acesso de baixo custo, porém de alta confiabilidade,que permita o acesso de pessoas a locais restritos com a identificação feita por meiode smartphones, tablets e computadores conectados a internet, conforme a arquiteturarepresentada na Figura 1. Além de garantir, ao administrador do local, um gerenciamentoremoto do ambiente por meio de qualquer dispositivo que tenha acesso a internet.

25

Figura 1: Arquitetura proposta para o projeto.

1.3 Justificativas

Este documento tem um papel importante como difusor de conhecimento técnico,uma vez que nele estão presentes informações relevantes sobre área da eletrônica e com-putação. O projeto serve como referência para projetos similares, além de possuir comoproduto final um sistema de controle de acesso funcional e de baixo custo, possibilitandouma fácil replicação e instalação em diversos locais.

1.4 Organização do Trabalho

Este trabalho apresenta 5 capítulos.

• Capitulo 1 - Introdução: Mostrar uma visão ampla sobre o projeto desenvolvido,explicitando sua motivação, objetivos, justificavas, além de sua organização.

• Capitulo 2 - Fundamentação Teórica: descreve a fundamentação teórica deste docu-mento, isto é, os conceitos básicos para o seu amplo entendimento.

• Capitulo 3 - Desenvolvimento do Projeto: contém o desenvolvimento do projeto,listando os materiais e descrevendo os métodos utilizados para a síntese da aplicaçãodesejada

• Capitulo 4 - Resultados e Discussões: apresenta os resultados e discussões pertinentesaos métodos e materiais utilizados.

• Capitulo 5 - Conclusões: Explicita as conclusões do desenvolvimento do trabalho.

27

2 FUNDAMENTAÇÃO TEÓRICA

2.1 Banco de Dados

Segundo(23), um banco de dado pode ser descrito como um conjunto de dados quepossuem relação entre si, onde um dado deve possuir alguma informação relevante; e suaconstituição atende uma proposta específica. Os dados presentes em um banco de dadosderivam de uma fonte de informação, além de possuírem algum tipo de relacionamento como mundo real e com o interesse do usuário. Em seu estado da arte, aplicações de bancosde dados se estendem além das usuais, podendo ser funcionais em sistemas de informaçõesgeográficas, utilizados para um melhor acesso à dados geográficos como: imagens porsatélite, informações sobre o relevo e vegetação, como abordado por(24); para aquisiçãode alguma informação especial e análise de dados, por meio de Data Warehousing, quearmazena informações pertinentes a atividades de um usuário em bancos de dados(25), eo processamento de um conjunto de dados complexos; e em informações marítimas, pormeio de técnicas de Big Data como encontrado em(26).

Bancos de dados, além de suas informações, se diferenciam na forma em que osdados se relacionam, por meio de regras e lógicas existentes em sua constituição. Nestetrabalho será abordado apenas o modelo hierárquico, no qual há uma ramificação ordenadae hierárquica entre os dados, de forma que sua composição seja semelhante a uma árvore,em que cada dado, presente neste modelo, esteja vinculado apenas um usuário. Umrepresentante deste modelo é o banco de dados do Firebase da Google, cujo um exemplode estrutura pode ser encontrado na figura 2

2.1.1 Firebase

Firebase(27) é uma aplicação web que oferece diversas ferramentas para o desen-volvimento de sites e aplicações via web. Seus principais serviços para desenvolvimentosão:

• Firebase Analytics - consiste em uma aplicação que verifica a quantidade de usuáriose suas interações com aplicativo.

• Firebase Cloud Messaging - serviço oferecido que permite a comunicação via mensa-gens e notificações em aplicativos IOs, Android e web.

• Firebase Authentication - serviço capaz de autenticar o usuário. Esta aplicação écapaz de interagir com informações em redes sociais como: Twitter, Facebook e contasda Google para a realizar sua finalidade.

28

Figura 2: Modelo de dados do banco de dados do Firebase.

• Banco de Dados em Tempo Real - esta aplicação possui sincronismo de dadosentre cliente e o servidor na nuvem da Firebase. Para a utilização desta aplicaçãoexistem inúmeras bibliotecas que podem ser implementadas em diversas linguagensde programação, neste trabalho utilizou-se python-firebase 1.2, biblioteca que provêas funcionalidades deste API para Python 3.6.

• Firebase Storage - serviço que permite o armazenamento de arquivos, bem o serviçode download e upload.

A página principal do Firebase, bem como o menu com suas funcionalidades, estápresente na Figura 3.

2.2 Aplicação Web

Segundo (28), uma aplicação web pode ser classificada como qualquer programaque utilize como interface com o cliente o navegador. Uma aplicação web mostra-se muitovantajosa em termo de compatibilidade, uma vez que a aplicação não é desenvolvida paraum sistema operacional especifico; e sim para rodar em um navegador, assim para suautilização basta ter um browser com acesso a internet, ou localmente, com acesso ao código

29

Figura 3: Pagina de trabalho do Firebase e suas aplicações no lado esquerdo.

do programa. Logo, uma aplicação web pode ser executada em computadores com sistemasoperacionais distintos, bem como qualquer dispositivo que possua um navegador.

2.2.1 Rede de computadores

Segundo (29), uma rede de computadores pode ser considerada qualquer tipo deconexão existente entre dois ou mais dispositivos com o âmbito de compartilhamento derecursos. Mesmo possuindo este nome, uma rede de computadores não restringe seu usoapenas a este tipo de dispositivo, com o avanço tecnológico inúmeros aparelhos possuem acaracterística de comunicar com outros, trocando dados e compartilhando recursos, como:tablets, celulares, impressoras, televisores, video-games, automóveis, sensores inteligentes;constituindo assim uma rede de computadores. Assim como qualquer tipo de sistema decomunicação, em redes de computadores existem procolos, que estabelecem o formato ecomo uma mensagem será enviada e recebida, além das ações necessárias para se estabelecera comunicação. Neste trabalho o protocolo abordado será o TCP/IP.

2.2.1.1 TCP/IP

A ampla utilização deste protocolo dá-se devido a suas inúmeras qualidades como avigência de padronizações, possibilitando que este protocolo possa ser utilizado em diversosambientes, além de possuir tecnologias que possibilitam transporte de informações deformas diferentes, contemplando a interconexão de sistemas diferentes(29). O protocoloTCP/IP, consiste em uma pilha de protocolos, cada uma pertencente a uma de quatrocamadas, distintas entre si por suas características. A figura 4, ilustra as camadas existentesneste protocolo.

Conforme aumenta-se o nível da camada maior é o grau de abstração presentenos protocolos, isto é, maior será a facilidade de um usuário interagir com os protocolos

30

Figura 4: Camadas do protocolo TCP/IP.

existente nelas.

A camada de aplicação, é a camada com maior nível de abstração, nela estão todosos protocolos necessários para que a aplicação ocorra e seus principais protocolos são: oHTTP, que permite a transferência de hipertextos, sendo a base para a rede mundial decomputadores (World Wide Web); FTP que é o principal protocolo para a tranferência dearquivos, SSH protocolo comumente utilizado em aplicações onde há um login remoto comacesso a linhas de comando; DNS protocolo responsável por fazer associação de nomes dedomínios com IP; além do MQTT, um dos principais protocolos utilizados em aplicaçõesde IoT.

A camada de transporte, é a camada responsável pela transferência de dados deum dispositivo a outro, nela ocorre o tráfego das informações que serão processadas etransformadas em dados inteligíveis na camada acima. Os principais protocolos destacamada são o TCP, principal protocolo utilizado quando necessita-se de uma transmissãocom alta confiabilidade; UDP, protocolo utilizado quando não há grande compromisso naentrega confiável de todos os pacotes de um serviço, geralmente empregado em sistemascom grande fluxo de informações como streaming de vídeos e músicas, onde a perda depoucos pacotes não comprometem a qualidade do serviço.

A camada de rede, possui protocolos de controle dos pacotes que trafegarão nacamada de transferência, suas principais funcionalidades estão atreladas à escolha dasrotas que o pacote irá percorrer para ser entregue a determinado destino, o principalprotocolo desta camada é o IP, que atribui um endereço numérico a cada dispositivo.

31

A camada de ligação de dados, possui inúmeras tecnologias que permitem atransformação dos dados em níveis físicos, como amplitude de uma onda elétrica, além docontrole da rede por meio de dispositivos físicos. Está é a camada mais baixa do protocoloTCP/IP.

2.2.1.2 MQTT

Este protocolo foi desenvolvido originalmente pela IBM no final da década de 90,e possuía como um dos principais objetivos a transferência de dados entre sensores depetróleo a satélites. Seu funcionamento dá-se na forma de publicação e assinatura. Esteprotocolo é amplamente utilizado em aplicação de IoT, uma vez que contempla dispositivosque possuem redes com limitação em largura de banda e alta latência, além de sua fácilincorporação em diversos sistemas(30).

Comparando o protocolo MQTT com outros da camada de aplicação, pode-severificar as vantagens deste para aplicações de IoT, uma vez que apresenta uma comunicaçãoassíncrona, ideal para a leitura de sensores, sendo a rede responsável pela melhor escolhade sincronização e caminho à aplicação, além de não possuir cabeçalhos e regras muitoextensas, fazendo com que este protocolo seja leve.

Neste protocolo existem duas entidades, o broker e o cliente, o primeiro desem-penha um papel de servidor, isto é, ele recebe todos os dados enviados pelos clientes; edepois redireciona para todos os clientes que se interessam por aquele tipo de dado. Ofuncionamento deste protocolo pode ser exemplificado pela Figura 5.

Figura 5: Exemplificação do protoco MQTT.

A partir da Figura 5, o fluxo de dados utilizando o protocolo MQTT é feito daseguinte maneira:

32

• Os clientes se conectam ao Broker ; e assinam os tópicos dos quais desejam receberinformações. Em algumas aplicações há a necessidade de identificação.

• Clientes publicam informações em um tópico no Broker.

• O Broker redireciona a mensagem publicada a todos os clientes que assinam o tópico.

2.2.1.3 HTTP

O HTTP é um protocolo que se encontra na camada de aplicação do modelo deTCP/IP de rede de computadores. É por meio deste protocolo que são trocadas informaçõesno formato de texto, imagens, vídeos e hipertextos, entre o servidor e o cliente, sendo esteum dos protocolos mais populares da rede mundial de computadores(29).

De forma geral, o funcionamento deste protocolo inicia-se quando o cliente, pormeio de um IP e a porta que o serviço está sendo disponibilizado, se conecta com o servidor.Esta conexão pode ser estabelecida conhecendo-se o valor numérico dos itens citados acima.A porta e o IP da aplicação, podem ser acessados utilizando-se o protocolo DNS, quevinculará um domínio na web a estas informações. As mensagens a serem enviadas poreste protocolo, segundo (29), possuem o formato exemplificado na imagem da Figura 6.

Figura 6: Mensagem a ser enviada por HTTP.

O primeiro campo da mensagem, representado por "Start Line"informa se a men-sagem a ser trafegada é uma requisição ou resposta de requisição e sabe-se que estainformação chegou ao final quando consta a presença do <CRLF>, que representa um"carriage-return e line-feed", estes comandos podem ser compreendidos como retornarao inicio da linha e nova linha. O "Message Reader"representa todas as opções possíveisa serem executadas a partir desta mensagem, podendo, este campo, apresentar várias,uma ou nenhuma opções, cada uma destas é separada por um «CRLF"; e sabe-se queeste campo se finalizou na presença de uma linha em branco, isto é um «CRLF" semnenhuma informação posterior. Por fim encontra-se o corpo da mensagem "Message Body"que contém os dados relevantes a requisição ou resposta de uma requisição.

As opções disponibilizadas para uma mensagem de requisição, encontram-se naprimeira linha do "START LINE"do HTTP, em seguida é informada a versão do protocoloutilizada. As opções de requisição utilizadas neste trabalho são:

33

• GET : Retorna os dados requisitados pelo usuário.

• POST : Envia dados do usuário a ser processado pelo servidor.

Na mensagem de resposta, a primeira linha contém a versão do HTTP a ser utilizadaconcatenada com um código de três dígitos, sendo que o mais significativo informa oresultado de tal requisição. Os códigos iniciados em "1", tem um carácter informativo,indicando que a requisição foi aceita; aquelas cujos dados já foram aceitos e processadosiniciam com o dígito "2", informando que a requisição foi um sucesso. Caso alguma outraação necessite ser tomada para que a requisição seja completamente efetuada um códigoinicializado em 3 será enviado; caso a informação não seja o suficiente para ser processada,o código retornado iniciará com o número "4", indicando um erro por parte do cliente.Por fim, caso o servidor não consiga atender a solicitação um código iniciado por "5"seráenviado.

2.3 Sistemas Embarcados

Um sistema embarcado é um sistema microcontrolado cuja construção é feita parao controle de uma ou de diversas funções; de forma geral, o usuário final não tem acesso àprogramação do sistema embarcado, porém a esse é conferida a escolha das funcionalidadesdisponíveis no produto (31). Sistemas embarcados são projetados de modo que todos oscomponentes que o compõe sejam incorporados fisicamente ao sistema de operação.

A definição de um sistema embarcado se assemelha muito a de um computadorusual; a diferença entre os dois reside no fato de que um sistema embarcado é otimizadopara realização de uma determinada tarefa, refletindo no preço, no esforço computacional,na autonomia, no consumo, na conectividade, entre outros fatores do sistema escolhidopor projeto.

Existem diversas aplicações para um sistema embarcado, que vão desde o controlede uma torradeira e relógios digitais, até o controle de reatores nucleares. Devido aabrangência desta tecnologia, há a estimativa de que 98% dos microprocessadores hojefabricados são incorporados a um sistema embarcado (32).

Historicamente, o primeiro sistema embarcado foi desenvolvido pelo MIT e seuobjetivo foi incorporar o computador de bordo do Projeto Apollo em 1961 (33).

2.4 Códigos de barras

Um código de barras consiste em um conjunto gráfico de informações, que após serescaneado, pode ser decodificado a uma informação inteligível. Para seu funcionamentoutiliza-se a reflectância existente entre as cores, realizando-se uma diferenciação óptica, naqual por meio de um sensor, reconhece-se a reflexão da luz em superfícies brancas, e sua

34

absorção em superfícies escuras, possibilitando a decodificação das informações contidasnele (34).

Em sua composição, um código de barras pode ser uni-dimensional, isto é, ainformação decodificada apresentar-se-á na forma de colunas horizontais, conforme aFigura 7, sendo suas formas de decodificação mais usuais a code 3 of 9 ,UPC A, code 129(35).

Figura 7: Palavra exemplo em código de barras, utilizando a codificação code39.

Além de sua apresentação uni-dimensional, também pode decodificar informaçõesutilizando códigos de barras bi-dimensionais, nesta variante a informação codificadaapresenta-se em formas geométricas, como retângulos, hexágonos e círculos. Sendo algunsde seus modelos o PDF 417 e o QR code

2.4.1 QR code

O QR code, inicialmente, teve sua utilização aplicada no rastreamento e controle depeças de veículos durante sua etapa sua etapa de fabricação(36), porém com a popularizaçãode câmeras embarcadas em dispositivos móveis, como celulares, tablets e laptops, houvea absorção desta tecnologia em diversas atividades tais como: informações de telefones,URL, localização, até mesmo identificação de veículos como apresentada na nova placa decarros utilizadas em países do Mercosul (37).

Uma das vantagens da utilização do QR code, é que seu conteúdo pode ser acessado,mesmo que uma parte de sua representação gráfica esteja danificada. Isto é possível devidoa presença de redundâncias em sua composição. As redundâncias presentes no QR code sãoclassificadas da seguinte maneira: nível L(low), 7% da informação presente é reduntante;nível M (medium) onde 15% da informação é redundante; nível Q (quartile) com 25% deredundância; e o nível H (high) apresentando 30% de redundância (38).

Sua representação e algorítimo de síntese e decodificação são padronizados seguindoa ISO/IEC 18004:2015, que pode ser encontrada em <https://www.iso.org/standard/62021.html>

35

3 DESENVOLVIMENTO DO PROJETO

Neste capítulo serão apresentados os materiais, tanto hardware quanto software,que foram utilizados para síntese do projeto. Além dos métodos aplicados para o obtençãodos resultados desejados, garantindo sua replicabilidade e confiabilidade.

3.1 Material

Para a execução deste projeto utilizou-se a placa Raspberry Pi, modelo 2(39), comoa principal unidade de processamento de dados. Nela implementou-se todos algoritmos decontrole de acesso, interface com o usuário, e acesso ao banco de dados. A escolha destaplaca é devida ao seu baixo consumo de energia, reduzidas dimensões e capacidade deprocessamento compatível com as necessidades do projeto. Informações mais detalhadasdeste placa encontram-se na subseção 3.1.1 deste capítulo.

Para esta placa, o sistema operacional utilizado é o Raspbian Strech Lite(40),optou-se pela versão Lite devido a sua menor utilização do cartão de memória. Esta versão,porém, não possui interface gráfica, fazendo com que todas as interações com a RaspberryPi sejam feitas por meio de linhas de comando.

Visando uma maior acessibilidade à placa, utilizou-se o software PuTTY (41), possi-bilitando assim com que uma comunicação via SSH fosse estabelecida entre o computadordo usuário e a Raspberry. Para estabelecer esta conexão é necessário que o usuário configurea comunicação da Raspberry com a rede e habilite sua comunicação via SSH, localmente,necessitando, assim, de um teclado com saída USB e um monitor com entrada HDMI.

Toda a programação realizada na Raspberry Pi, utilizou a linguagem de progra-mação Python 3.6.5 (42) e para a síntese deste projeto as seguintes bibliotecas foramutilizadas: Numpy(43) para a manipulação númérica de dados; Python-Firebase(44) paraa manipulação de dados e acesso aos dados contidos no banco de dados da Firebase. Parafins de protótipo, foi utilizado o kit de desenvolvimento NodeMCU, que irá se comunicarcom o sistema desenvolvido utilizando o protocolo MQTT, desempenhando o papel decontrolar atuadores que possam realizar o papel de uma fechadura. A biblioteca utilizadana Rapberry Pi 2 para essa finalidade é a Paho MQTT. Com a finalidade de implementarum acesso facilitado para o usuário final da aplicação, utilizou-se as bibliotecas PyZbar ePy Qrcode, consecutivamente, para o reconhecimento de QR codes e sua criação.

3.1.1 Raspberry Pi model 2

Segundo o site da empresa desenvolvedora, Raspberry Pi Foundation, o primeiromodelo de sua placa de desenvolvimento começou a ser comercializada em 29 de fevereiro

36

de 2012(39), custando US$35, tendo como principal objetivo o estímulo de ciências dacomputação para crianças e jovens(45).

O modelo utilizado neste trabalho, Raspberry Pi 2, possui um processador Cortex-A7 com clock de 900MHz com quatro núcleos, além de uma memória RAM de 1 GB

e uma GPU VideoCore IV. Este modelo está mostrado na Figura 8, e é caracterizadopor conter 40 pinos GPIO, armazenamento feito por meio de cartão microSD, conexãoEthernet, 4 portas USB, saída HDMI e um consumo reduzindo, com uma potênciamédia de 1,1 W.

Figura 8: Imagem Raspberry Pi 2.

Fonte:(39)

3.1.2 NodeMCU

O NodeMCU é considerado, assim como o Arduino, uma plataforma de desen-volvimento opensource, isto é, seu projeto é aberto, podendo ser replicado e modificadopor qualquer pessoa ou instituição. Seu hardware deriva-se da ESP8266, construído pelaEspressif(46). Esta plataforma é nativamente preparada para receber programações dalinguagem Lua(47), porém devido a sua grande popularidade, esta plataforma pode serprogramada utilizando Micro Python(48) e a IDE do Arduino(49).

O NodeMCU, além de possuir hardware que o dá acesso a redes sem fio "wi-fi"utlizando o padrão IEEE 802.11 b / g / n, apresenta 12 pinos de GPIO, podendo estesserem configurados como entradas, saídas, comunicação serial, spi, além de uma entradacom conversor analógico digital. Sua CPU é de 32 bit com um clock de 80 MHz. A imagemda figura 9, apresenta o sistema com as funcionalidades desempenhadas por cada pino.

37

Figura 9: Ilustração do NodeMCU, com as designações de cada pino.

Fonte:(50).

3.1.3 Python-Firebase

A Python-Firebase é uma biblioteca criada pela comunidade que utiliza a linguagemde programação Python; e reconhecida pela própria Firebase (44). Esta biblioteca contémum conjunto de métodos para a manipulação do banco de dados armazenados nos servidoresda Firebase. Os dados obtidos por essa biblioteca são formatados no estilo de dicionário dedados, padrão utilizado no JSON. A aquisição destes dados é feita por meio de request viaHTTPS. Os principais métodos utilizados por esta biblioteca são get e post, responsáveis,respectivamente, pela obtenção e manipulação dos dados.

3.1.4 Paho MQTT

Esta biblioteca faz parte de um projeto da Fundação Eclipse(51), e nela sãosintetizados módulos que permitem o cliente conectar a qualquer broker, publicar mensagense assinar tópicos. Ela possui suporte para versões superior a 2.7.9 e 3.4 do Python.

3.1.5 Py Zbar

Este módulo importa as funcionalidades existentes no API Zbar(52), que permiteo reconhecimento dos dados decodificados em códigos de barras uni-dimensionais, e bi-dimensionais como QR codes. Este módulo possui suporte para ambas versões do Python

38

(2.7 e 3). Para sua utilização, a imagem deve possuir uma matriz com tipagem numpy comformatação de unsigned int de 8 bits(53).

3.1.6 Python QR code

Este módulo permite a criação de Qr codes, utilizando a linguagem de programaçãoPython. A imagem formada contendo a informação codificada pode possuir o formatoSVG e PNG(54).

3.1.7 Flask

Flask constitui um micro framework para desenvolvimento web descrito em Python,construído com o suporte das bibliotecas Jinja2 (uma template engine) e Werkzeug (WSGI- Web Server Gateway Interface e HTTP - HyperText Transfer Protocol) (55). Deste modo,sua função é fornecer uma estrutura base para obter-se um interfaceamento web para oprograma a ser implementado. É válido destacar que não pode-se classificar o Flask comoum servidor, dado que ele apenas realizaria a comunicação entre o servidor e o clienteconectado; porém, para pequenas aplicações, o framework é capaz de suportar a função deservidor.

Suas características permitem escolher a porta de acesso aberta para a web, verificaro método de requisição de cada página acessada (POST, GET), registrar a sessão de umusuário, portanto torna implementável a opção de login do cliente, proporcionando umaautenticação necessária para visualização e edição de certas informações, entre outrastantas funcionalidades que podem ser exploradas.

Uma extensa documentação, com exemplos e explicações, pode ser encontrada nosite oficial(55).

3.1.8 Eclipse IoT Broker

O servidor broker utilizado na comunicação via MQTT neste trabalho foi o forne-cido pela Eclipse Foundation(56), sendo esta responsável pelo desenvolvimento da IDEhomônima. O servidor disponibilizado por essa fundação pode ser acessado pelo host<iot.eclipse.org>, no qual o serviço é acessado pela porta 1883. Este servidor é executadopelo broker Mosquitto(57), que é um projeto que provê as funcionalidades dos protocolos3.1 e 3.1.1 deste tipo de comunicação e cuja biblioteca de aplicação é escrita na linguagemde programação C.

3.1.9 Materialize

Segundo os desenvolvedores(58), o Materialize é um framework capaz de produzir,de forma ágil e facilitada, páginas para web e aplicações web. Sua construção foi inspiradano Material Design, uma liguagem de design desenvolvida pela Google, para produção

39

de aplicativos para os sistemas operacionais mobile IOs, Android e para aplicações feitasdiretamente no navegador. Seu conjunto de instruções contém diretivas que realizam açõespor meio da utilização, indireta, do HTML, CSS e JavaScript em aplicações web.

3.2 Métodos

Nesta seção, primeiramente, introduzir-se-á os métodos desenvolvidos para a inter-face entre o usuário e o conteúdo presente no banco de dados alocado no Firebase. Parasíntese destes métodos as principais bibliotecas utilizadas no Python 3.6.5 foram o Flask,responsável por realizar o papel de servidor; Python-Firebase que possui métodos para ao acesso e manipulação de dados contidos no banco de dados do Firebase. A interfacegráfica da aplicação web foi inteiramente feita pelo framework Materialize. Os métodosexplorados nesta sessão, relacionados com a interface gráfica e fluxo de dados entre o bancode dados e usuário, serão:

• Planejamento da página.

• Cadastro de novos usuários.

• Login de usuários cadastrados.

• Disponibilizar uma sala a um usuário em determinado intervalo de tempo.

• Utilização de uma sala.

• Vincular uma nova sala a um usuário.

• Verificar um log de uma sala.

• Criar um Qr code para identificação do usuário.

• Utilizar a sala por meio da identificação do Qr code.

Posteriormente serão analisados os algoritmos de comunicação via MQTT entre aRaspberry Pi 2 e a plataforma NodeMCU, com a finalidade de verificação das limitações efuncionalidades do projeto desenvolvido. Estes métodos são:

• Abertura da porta, após a realização do método de sua utilização.

• Rotinas realizadas pelo NodeMCU com a finalidade de verificar o funcionamento dosistema.

Todo código desenvolvido neste projeto encontra-se no seguinte repositório: <https://github.com/victorboppre/TCC--controle-e-monitoramento-de-acesso>

40

3.2.1 Interface Web e fluxo de dados

A criação da interface web foi feita seguindo os padrões utilizados, convencional-mente, pelo HTML, a Figura 10 contém o design das páginas produzidas neste trabalhopara monitores convencionais.

Figura 10: Design dos templates das páginas para monitores.

Com o intuito do conteúdo ser acessível, também, para smartphones e tablets, aspáginas foram projetas para serem responsivas, isto é, o conteúdo da página se adéqua àsdimensões da tela do dispositivo, objetivando sua melhor visualização. Para smartphonese tablets o design da páginas são representados pela figura 11

Figura 11: Templates das páginas para smartphones e tablets.

A figura 12 apresenta a página principal do projeto, repartida com os blocos nav,body, footer.

41

Figura 12: Página inicial do projeto, segmentada nos blocos funcionais nav,body e footer.

O bloco header das figuras 10 e 11, é o cabeçalho da página, e nele encontra-seo título da página, que, geralmente, é apresentado no interior da guia de navegação; osscripts da página, usualmente escritos em JavaScript e seu estilo, representado em CSS.Neste bloco também define-se o meta que contém conteúdos intrínsecos a página, como adecodificação dos caracteres. O código abaixo, contém a declaração do cabeçalho geralutilizado neste projeto, além das especificações do Materialize.

1 <head>2 <meta http−equiv=" Content−Type " content=" text /html ; ␣ cha r s e t=UTF−8" /

>3 <meta name=" viewport " content=" width=device−width , ␣ i n i t i a l −s c a l e =1,

␣maximum−s c a l e =1.0 " />4 <t i t l e>Welcome ! ! !</ t i t l e>5 <!−− CSS −−>6 <l i n k h r e f=" https : // f on t s . g oog l e ap i s . com/ icon ? fami ly=Mater ia l+Icons

" r e l=" s t y l e s h e e t ">7 <l i n k h r e f=" {{ ur l_fo r ( ’ s t a t i c ’ , ␣ f i l ename=’ c s s / ma t e r i a l i z e . css ’ ) }} "

type=" text / c s s " r e l=" s t y l e s h e e t " media=" screen , p r o j e c t i o n " />8 <l i n k h r e f=" {{ ur l_fo r ( ’ s t a t i c ’ , ␣ f i l ename=’ c s s / s t y l e . css ’ ) }} " type="

text / c s s " r e l=" s t y l e s h e e t " media=" screen , p r o j e c t i o n " />

42

9 </head>

O bloco nav representa a barra de navegação da interface, ela é responsávelpelo redirecionamento e controle das páginas. Seu conteúdo principal são hiperligações,possibilitando vincular nomes e símbolos com uma página da internet, ou um arquivo localcom extensão HTML. O trecho de código abaixo, contém uma implementação da barra denavegação utilizada nas interfaces deste projeto, quando o usuário não está "logado":

1 <nav c l a s s=" ind igo " r o l e=" nav igat i on ">2 <div c l a s s=" nav−wrapper␣ conta ine r "><a id=" logo−conta ine r " h r e f=" /

" c l a s s=" brand−l ogo ">SmartLock</a>3 <ul c l a s s=" r i gh t ␣hide−on−med−and−down">4 <l i><a hr e f=" / p ro j e t o / ">Pro je to</a></ l i>5 <l i><a hr e f=" / cadast ro / ">Cadastro</a></ l i>6 <l i><a hr e f=" / l o g i n / ">Login</a></ l i>7 </ul>

Neste caso, a hiperligação, representada pelo href, está referenciando uma rotaestabelecida pelo Flask, assunto abordado posteriormente, com um nome, conformedestacado na figura 12. Assim, quando um nome é selecionado, a página é redirecionadapara aquela contida na hiperligação.

O bloco body representa o corpo da aplicação, nele estão contidas as informaçõespertinentes a cada página. Tendo uma página de login como referência, ela deverá conterespaços para o usuário inserir o nome e sua respectiva senha. Como o cabeçalho, barrade navegação e o rodapé mantém-se constantes, o conteúdo que difere cada página estápresente em seu corpo.

O footer contém informações do rodapé da aplicação.

3.2.1.1 Página Inicial

A página inicial é renderizada quando o usuário acessa o local em que a aplicaçãoestá alocada. Neste trabalho ela pode ser acessada diretamente pelo IP 143.107.235.54,na porta 5000. Ela é responsável pelo direcionamento do usuário para as funcionalidadesimplementadas por meio das hiperligações; quando o usuário a acessa pela primeira vez,conforme a figura 12, na barra de navegação serão exibidas opções para o redirecionamentopara a página de projeto, que contém algumas informações pertinentes a este trabalho;cadastro, responsável pelo credenciamento de novos membros ao sistema, esta funcionali-dade também pode ser acessada pelo botão presente no corpo da imagem; e login, onde ousuário poderá se identificar e usufruir dos serviços disponibilizados.

No Flask defini-se a rota de acesso à página inicial como sendo "/", assim é possívelacessa-lá, diretamente pela junção do IP e da porta, ou do IP e da porta acrecidos de

43

"/"; como exemplo para este trabalho é possível acessá-la por, <143.107.235.54:5000>ou <143.107.235.54:5000/>. O único método, em Python, utilizado quando está rotaé acessada é renderização da página, assim pode-se implementa-la da seguinte forma,utilizando o Flask, em que index.html, possui o template em HTML da página inicial:

1 @app . route ( ’ / ’ , methods=[ ’POST ’ , ’GET’ ] )2 de f index ( ) :3 re turn render_template ( ’ index . html ’ )

3.2.1.2 Página de cadastro

Quando o usuário seleciona o link "cadastro", contido no navegador, ou pressiona obotão "CADASTRE-SE AQUI!", ele é redirecionado para página de cadastro da aplicação.Esta rota utiliza o método POST, isto é, ela envia informações do cliente para o servidor,porém, utiliza o método GET em sua inicialização, renderizando a página em que o usuáriopode submeter, após selecionar o botão "Enviar"seus dados, para o credenciamento de umnovo usuário, sendo eles: nome do usuário, senha e confirmação da senha.

A aquisição destes dados é feita pelo método ”request” do Flask, que permite aobtenção das informações das TAGs "<input>"em HTML.

Quando é verificado que o usuário submeteu novos dados na página de cadastro(POST method), inicia-se o método para os analisar e, se forem válidos, alocá-los nobanco de dados do Firebase, possibilitando assim o acesso de um novo usuário conformeo fluxograma da Figura 13.

Neste método, inicialmente, verifica se as duas senhas são idênticas, caso não sejam,renderiza-se uma página contendo um alerta, informando esta condição; posteriormente,caso a primeira condição seja respeitada, verifica-se se o nome do novo usuário já não estásendo utilizado, caso esteja, renderiza-se uma página indicando este evento; por fim, seestas condições de cadastramento forem respeitadas, adiciona-se no Firebase uma célulavinculada a este usuário; nela está contida sua senha, as salas que ele tem acesso, as salasque ele é administrador; conforme a figura 14.

3.2.1.3 Página de Login

Assim como a página de cadastro, a de login, também, pode ser acessada a partirda hiperligação presente na barra de navegação. Esta rota renderiza inicialmente umapágina, para que o usuário possa inserir seus dados, afim de usufruir as funcionalidades daaplicação. O funcionamento desta rota está contido na figura 15.

Nesta rota, quando verifica-se que o usuário submeteu uma informação, primei-ramente se averígua se o nome do usuário está cadastrado, caso essa condição não sejasatisfeita, renderiza-se uma página alertando sobre este fato. Em seguida analisa se se-

44

Figura 13: Fluxograma da rota "cadastro".

Figura 14: Célula de dados do usuário chamado ’user ’

45

Figura 15: Fluxograma da rota "login".

nha informada possuí correspondência com o nome do usuário solicitado, se não tiverrenderiza uma página contendo um alerta sobre isto. Caso sejam atendidas as condiçõesde login, armazena a informação que o login foi realizado com sucesso, este fato faz comque mudanças na barra de navegação ocorra, liberando para o usuário a possibilidade defazer o logoff, utilizar uma sala, adicionar um usuário a uma sala, caso o usuário seja oadministrados dela, verificação dos log das salas que ele é administrador.

3.2.1.4 Criar uma sala e vincular a um usuário

Esta é uma funcionalidade que não está disponível para o usuário comum. A criaçãode uma sala e seu vínculo a um usuário é feita apenas por um usuário administrador. Deforma geral, esta funcionalidade pode ser representada pelo fluxograma da figura 16

Quando o usuário acessa a rota secreta para a criação de uma nova sala, há umcampo especial para o administrador do sistema se identificar, caso as credenciais sejaminválidas, o usuário e redirecionado para a página inicial; caso contrário é exibido um

46

Figura 16: Fluxograma para criar uma sala e sua vinculação com um usuáro.

campo para o administrador inserir o nome desejado de uma nova sala e do usuário, casoo nome da sala exista, o administrador é redirecionado a página inicial onde será exibidauma mensagem indicando o erro; se o nome da sala não existir, ele cria uma célula com onome da nova sala; esta célula é identificada pelo nome, conforme a Figura 17 e nela estácontida o seu log de utilização, o seu mestre e o seu estado atual; se ela está aberta oufechada. Esta rotina também faz o vinculo na célula do usuário administrador, Figura 14,no campo de "mestre_salas"o nome da sala recém criada.

Figura 17: Célula de sala e seus atributos.

47

3.2.1.5 Disponibilizar uma sala a um usuário

Esta rota é acessível apenas quando um usuário está logado, caso ocorra a tentativade acessá-la sem sua prévia identificação, um redirecionamento para a página principal éfeita. Esta funcionalidade pode ser representada pelo fluxograma da figura 18.

Figura 18: Fluxograma para garantir o acesso a um usuário a uma sala, durante umadeterminada faixa de tempo.

A primeira condicional desta rota, consiste em verificar se o usuário "logado"émestre de alguma sala, esta ação é feita verificando o atributo "mestre_salas", se ela estivervazia o corpo da página com mensagem de erro é renderizada. Caso contrário um bodycom caixas de seleções será renderizado, nestes espaços o administrador da sala poderáescolher a sala e o usuário que pretende vincular, além de escolher a data e o horário devalidade que o usuário vinculado poderá utilizá-la.

Quando um usuário é vinculado a uma sala, o seu atributo "salas_ativas"é preen-chido com uma lista de dicionários identificados pelo nome da sala; nestes dicionários sãopreenchidos com atributos pertinentes com a data e horário que expira o acesso do usuárioa uma determinada sala, está característica pode ser observada na imagem 2, contida nocapítulo materiais e métodos.

3.2.1.6 Utilizar uma sala

Assim como o rota de vincular uma sala a um usuário, a utilização de uma salasó é possível quando verifica-se que há um cliente "logado". Partindo deste princípio, ofluxograma da figura 19 contém a lógica quando esta rota é chamada.

48

Figura 19: Fluxograma para acessar uma sala.

A primeira ação a ser realizada nesta rota, é verificar se o requirimento da utilizaçãopartiu de um administrador, caso esta condição seja verdadeira, o acesso a sala é liberadodiretamente, iniciando o método de comunicação via MQTT com o NodeMCU. Caso sejaverificado que o usuário não é o administrador, averígua-se se ele possui alguma saladisponível em seu atributo "salas_ativas", caso este esteja vazio, o cliente é redirecionadoa página inicial; se existirem salas disponíveis, uma página com uma caixa de seleção comas salas será renderizada. As opções presentes, a serem selecionadas, são aquelas as quaiso tempo de utilização ainda não expirou. Caso o utilizador escolha uma sala, a aplicaçãoenviará uma mensagem para o NodeMCU via MQTT, a rotina que faz toda a comunicaçãoencontra-se no bloco "Método de comunicação com o NodeMCU com Timeout", esta rotinaserá abordada na subseção .2.2. Caso a rotina retorne um valor verdadeiro, o NodeMCUirá atuar de forma a ser possível ver a porta abrindo, sucessivamente com a renderização deuma página informando que a sala foi aberta. Caso esta plataforma não responda, ou suaresposta seja algo diferente do esperado irá renderizar uma página informando o ocorrido.

3.2.1.7 Verificar o log da sala

Esta rota possui a funcionalidade de mostrar para os administradores informaçõessobre o fluxo de pessoas em suas salas, seu acesso está garantido apenas para usuários jáidentificados, o seu fluxograma pode ser encontrado na figura 20.

A primeira condicional desta rota consiste em averiguar se o usuário é administrador

49

Figura 20: Fluxograma acessas o "log"de uma sala.

de alguma sala; caso não seja, ele será redirecionado a uma página informando que não hánenhuma sala para ele verificar o "log"; caso seja, é renderizada uma página com caixas deseleção contendo as salas que o cliente é administrador. Quando selecionada uma sala, seráinformada uma lista contendo os usuários que a utilizaram, data e horário, e notificaçãode erros, caso um usuário tente utilizar esta sala e não logre exito.

3.2.1.8 Identificação do usuário por meio do Qr code

Esta funcionalidade foi implementada com o âmbito de prover maior facilidade parao usuário. Por meio dela o controle de acesso do usuário pode ser feito pela identificaçãodo Qr code individual de cada usuário, para esta funcionalidade, porém, é necessária apresença de algum dispositivo capaz de obter a imagem do ambiente a ser controlado.Neste trabalho, a imagem é obtida por meio de uma câmera ligada a rede, e a obtençãodas imagens é feita por meio de request via http. O trecho de código responsável por essafinalidade está expresso abaixo:

1 import r eque s t s2

3 pro toco l o = ’ http :// ’4 ip = ’ 143 . 107 . 235 . 59 : 8086 ’5 ac t i on = ’ / snapshot . c g i ? ’6 usuar io = ’ user=alunos ’7 senha = ’pwd=alunos ’8

9 u r l = pro toco l o+ip+act i on+usuar io+’&’+senha10

11 re sponse = reque s t s . get ( u r l )12 i f r e sponse . status_code == 200 :

50

13 with open ( ’ id . jpg ’ , ’wb ’ ) as f i l e :14 f o r image in response . i t e r_content ( ) :15 f i l e . wr i t e ( image )

A opção de identificação do usuário via Qr Code, está presente em uma hiperligação,disponibilizada apenas quando o usuário está identificado na aplicação. O fluxograma querepresenta a rotina de mostrar o Qr code do usuário está presente na Figura 21.

Figura 21: Fluxograma para criação e exibição do Qr code de um usuário.

Primeiramente, neste método, para os usuários já credenciados na aplicação, faz-sea decodificação das credenciais do usuário; a partir dos dados decodificados cria-se umQr code para a sua identificação. A imagem contendo o Qr code de cada usuário é criadaapenas uma vez, caso seja constado que já exista tal imagem, então a aplicação apenas arenderiza na aplicação web, caso contrário, ela é feita e, posteriormente, renderizada.

A rotina de reconhecimento do Qr code utiliza captura de imagem, ao invés destreaming de vídeo. Esta escolha foi feita uma vez que que cada frame do vídeo seriaprocessado com intuito de localizar e decodificar o Qr code e esta prática exige maiorcapacidade do processador, além de criar uma latência considerável entre a imagem queestá sendo processada com aquela que está sendo obtida. O fluxograma da Figura 22,contém a rotina de identificação do Qr code de um usuário, consecutivamente, com acomunicação via MQTT com o NodeMCU.

Primeiramente, nesta rotina, uma imagem é capturada do ambiente onde desejafazer o controle de acesso. A partir desta imagem pode-se fazer o processamento, verificandoa presença de um Qr code. Todos os métodos utilizados para está finalidade são realizadorpor meio da biblioteca PyZbar e caso possua um QRcode este é decodificado. A partirdesta ação é possível encontrar as credenciais do usuário e caso este possua as credênciasválidas, inicia-se uma rotina de comunicação, idêntica a implementada na da Figura 19.Como esta rotina deve funcionar enquanto o controle de acesso está ativo, ela se encontra

51

Figura 22: Fluxograma para identificação do Qr code de um usuário.

em um laço infinito.

3.2.2 Comunicação MQTT entre plataformas

Nesta seção serão explanados os métodos utilizados para a comunicação via MQTTentre a aplicação web e a plataforma NodeMCU. As funcionalidades existentes na aplica-ção foram executadas utilizando os métodos presentes na biblioteca Paho MQTT. Estafuncionalidade é desempenhada no NodeMCU pela biblioteca pubsub(59), que possui todosos métodos para este tipo de comunicação. De forma geral a comunicação entre esses doisdispositivos é dada conforme a Figura 23.

De forma geral, primeiramente, o usuário irá requisitar o acesso a um ambiente pormeio da aplicação web, que será processado pela Raspberry Pi, e posteriormente irá publicarem um tópico no Broker. O Broker irá redirecionar a mensagem a todos os dispositivosque assinam o tópico onde foi publicado. Caso o dispositivo de interesse esteja assinandoo tópico, ele irá publicar uma mensagem em um tópico distinto do recebido, esta é umaprática importante para que ele não receba a mensagem que acabou de enviar. O brokerirá redirecionar esta última mensagem para a Raspberri Pi, que irá processar a mensagemrecebida. Caso o NodeMCU demore ou não responda, o método de controle do MQTT,implementado na Raspberry, irá declarar Timeout, finalizando a comunicação e retornandouma mensagem falsa, conforme informado no fluxograma da Figura 19, esta respostatambém é retornada quando é recebida uma mensagem diferente da esperada. Quandorecebe-se uma mensagem esperada no período de tempo pré-determinado, o método iráretornar verdadeiro, permitindo que o usuário utilize o ambiente controlado. O "Método de

52

Figura 23: Fluxo de informação entre os dispositivos.

comunicação com o NodeMCU e com Timeout"presente na Figura 19, faz todo o controleda comunicação MQTT na Raspberry.

3.2.2.1 Método de comunicação com o NodeMCU e com Timeout

Os métodos utilizados para comunicação MQTT na Raspberry Pi estão presentesno fluxograma da Figura 24.

Primeiramente, neste método, há o estabelecimento de conexão com o Broker ea declaração de um timeout, nesta aplicação o valor coincide com 10 segundos. Apósse conectar, a aplicação publica no tópico uma mensagem que ao ser processada peloNodeMCU, ocorre uma resposta a esta e libera o acesso a uma sala a ser utilizada. Apósesta ação, a aplicação assina um tópico, no qual a resposta do NodeMCU será publicadae enquanto esta mensagem não é recebida o valor do timeout é decrementado e caso elechegue a zero, este método retorna um valor booleano falso. Caso uma mensagem chegue aotópico, o qual a Raspberry assinou, o decremento do timeout é finalizado, se esta mensagemfor diferente da resposta esperada este método retorna o valor falso, se ela for igual, estemétodo irá retornar verdadeiro.

3.2.2.2 Comunicação MQTT no NodeMCU

No NodeMCU, o recebimento e o envio de mensagens em tópicos ocorre quandouma mensagem é recebida, entrando em um rotina chamada por meio de um callback,enquanto uma mensagem não é recebida, a programação embarcada verifica a conexão como ponto de acesso e com o broker. Estes métodos e ações são encontrados no fluxogramada Figura 25.

53

Figura 24: Fluxograma do método de comunicação MQTT implementado na Raspberry.

Na configuração do NodeMCU, presente no fluxograma da Figura 25, inicialmentesão declaradas as variáveis que serão utilizadas durante a programação. Posteriormente éfeita a conexão do módulo com o ponto de acesso Wi-Fi, após esta ação pode-se implementarum método para verificar se o módulo conectou-se com no Wi-Fi, e imprimir no monitorserial o Status da conexão. Esta prática auxilia no "debugger", posteriormente cria umaconexão com o broker, e referencia a função a ser chamada quando uma mensagem érecebida do broker. Após a configuração da rede e da conexão, o programa fica em umlaço verificando se ainda há conexão com o ponto de acesso e com o broker e caso nãohaja, executa a reconexão com estes. O método a ser chamado quando um callback ocorreé explicitado no fluxograma da Figura 26.

Quando o "callback" ocorre, o conteúdo da mensagem é alocado em uma variável glo-

54

Figura 25: Fluxograma de configuração do NodeMCU.

bal, uma vez que ela será processada em outro método; a seguir verifica-se o conteúdo destamensagem, com a finalidade de verificar se seu valor corresponde ao valor pré-estabelecido,caso não seja, há uma finalização desta rotina, provocando um "timeout", devido a ausênciade resposta, na rotina de comunicação MQTT da Raspberry do fluxograma da Figura19. Caso o valor recebido seja igual ao valor pré-estabelecido, envia-se uma mensagem deresposta via MQTT para a Raspberry mostrando que o módulo está pronto para acionarum atuador, fazendo assim o controle de acesso. A rotina para o acionamento do atuadoré representado pela sub-rotina "Atuador"mostrado no fluxograma 26.

55

Figura 26: Fluxograma de "callback"do NodeMCU.

57

4 RESULTADOS E DISCUSSÕES

Neste capítulo serão apresentados os resultados obtidos por meio da síntese dosmétodos, explicitados no capítulo anterior, em conjunto com os materiais selecionados,bem como suas discussões pertinentes.

4.1 Raspberry Pi 2

A utilização da Raspberry pi 2 mostrou-se eficiente em nível de protótipo desteprojeto. A placa possui reduzidas dimensões, comparadas a outros dispositivos capazes dehospedar a aplicação, como computadores e notebooks; segundo seu esquemático mecânico,fornecido pela empresa fabricante(60), esta plataforma possui 8,5 cm de comprimento e5,6 cm de largura.

Mesmo sendo um dispositivo de tamanho reduzido, esta placa possui recursossuficientes para a hospedagem do projeto desenvolvido. Para a validação deste parâmetrofoi verificado a utilização de memória ram e CPU, após a utilização em paralelo daaplicação web e do algoritmo de reconhecimento de Qr code. O comando em bash quepossibilita a visualização deste parâmetro é o "top", e o resultado de sua utilização estáapresentado na imagem da Figura 27.

Figura 27: Utilização dos recursos da Raspberry Pi 2

Na Figura 27, observa-se que há um grande esforço computacional para a realizaçãoda identificação do usuário por meio do Qr code, 77% da capacidade da CPU, ficando estetipo de funcionalidade limitado a um nesta plataforma. Em contrapartida, a aplicaçãoweb, teve uma utilização da CPU de cerca de 2,3 %. Em ambos os casos é verificada umabaixa utilização de memória. A utilização da aplicação web, apresenta um aumento de5%, em uma breve faixa de tempo, quando um request ocorre, porém, como este valor émomentâneo, a validando que aplicação tem suporte a diversos usuários, desde que elesnão realizem um request ao mesmo tempo. Caso isso ocorra a aplicação ficará mais lenta,podendo ser interrompida.

Outra métrica utilizada para verificar a eficiência do sistema é o tempo decorridopara a realização de um método ou rotina. Neste quesito foi verificada a quantidade detempo necessária para a aquisição de dados via request do Firebase e da realização darotina de aquisição de reconhecimento e de Qr codes. Para a realizar esta verificação foiutilizado o seguinte trecho de código:

58

1 import time2

3 begin = time . time ( )4 " " " Rotina a s e r v e r i f i c a d a " " "5 end = time . time ( )6 pr in t ( end − begin )

Para a aquisição da imagem de um Qr code e seu processamento, o tempo médionecessário é de 0,602609 segundos, sendo este o valor de atraso presente entre a imagem doambiente real com a imagem sendo processada. O tempo médio necessário para a realizaçãodo request foi de 0,323423 segundos. Este valor, porém é variável, sendo dependente dainternet a qual a Raspberry está conectada.

Além de possuir um acesso rápido, a utilização do Firebase garantiu uma maiorsegurança a aplicação, uma vez que as informações alocadas nele, podem ser vinculadas aregras de segurança. Caso a aplicação deste projeto vire um produto, pode-se utilizar oFirebase como banco de dados. Esta é uma solução utilizada por grandes corporações eaplicativos como: New York Times, Shazam, Duolingo e Trivago(27).

A Raspberry Pi 2, para fins de produto, não possui uso adequado, uma vez que elaimpossibilita a utilização do reconhecimento de Qr code para mais de um ambiente, alémde possuir problemas quando muitos usuários realizam request simultaneamente. Para estenível é necessário que a aplicação seja hospedada em um servidor profissional, capaz deatender simultaneamente vários usuários e prover diversos ambientes a funcionalidade dereconhecimento via Qr code.

4.1.1 NodeMCU e MQTT

A validação da utilização do NodeMCU e o protocolo MQTT, foi realizadoverificando-se a troca de mensagens entre esta e a aplicação web hospedada na RaspberryPi 2. Para esta verificação foi mensurado o tempo médio que uma resposta demora a serrespondida partindo da Raspberry Pi 2. O método utilizado para mensurar esta magnitudeé idêntico ao utilizado na Seção 4.1. Outro aspecto medido foram quantas mensagensdeixaram de ser enviadas e para este teste verificou-se a ocorrência de respostas apósenviar 100 mensagens partindo da Raspberry Pi 2.

Em ambos os testes obteve-se uma boa resposta, das 100 mensagens enviadas parao NodeMCU, todas conseguiram ser recebidas, processadas e respondidas; além de queo tempo médio de resposta foi de 2,48 segundos, para ambas plataformas conectadas auma rede de 30 mbps. Mesmo esta plataforma apresentando respostas satisfatórias, parafins comerciais e profissionais, a utilização desta plataforma torna-se inviável, por nãoapresentar homologação pela Anatel. Esta homologação é importante, pois garante que oproduto comercializado atenda os padrões de qualidade e segurança, sendo um impeditivo,

59

na sua falta, para comercialização(61).

Para fins comerciais aconselha-se a utilização do módulo BX310 fabriacado pelaSierra(62), que possui homologação pela Anatel. Os fatores motivacionais para sua adoção,além da homologação necessária para fins comerciais, é a possibilidade de acrescentar afuncionalidade de comunicação Bluetooth com outros dispositivos; expandindo as possibili-dades de uso da arquitetura apresentada. Este módulo possui de fábrica funcionalidadespara a configuração de uma comunicação via MQTT, possibilitando a portabilidade doprojeto desenvolvido neste documento, além de possuir pinos com diversas funcionalidadescomo: entradas e saída; comunicação I2C; SPI e serial, sendo esta última por onde estemódulo será configurado e controlado por meio de comandos AT. O preço corrente destemódulo, sem sua taxa de importação e entrega, está em torno de 8 U$S.

Para o controle deste módulo faz-se necessária a aplicação de um microcontroladorque possua comunicação serial, dando suporte a um baud rate de 115200, que é o valorpadrão utilizado pelo BX310. O microcontrolador recomendado para esta aplicação é oPIC18F4550 fabricado pela Microchip(63), os fatores motivadores da adoção deste módulosão: sua fácil aquisição e popularidade em nosso país, atendimento da comunicação serial, epresença de diversos pinos configuráveis, estendendo as possibilidades das funcionalidadesaplicadas neste projeto.

4.2 Aplicação Web

A aplicação web, resultante dos métodos, contidos nas seção 3.2.2, é responsiva,tal fato garante uma melhor experiência para o usuário, facilitando a visualização doconteúdo do site, uma vez que este se adapta dependendo da resolução do dispositivoidentificado. Para desktops e notebooks, o site possui uma barra de navegação horizontal,nas quais os redirecionamentos de rotas do site estão presentes. Nestes dispositivos a páginaé renderizada, levando em consideração uma tela de maiores dimensões. Em celulares etablets, o menu é apresentado de forma dinâmica, mostrando apenas os redirecionamentosdepois da opção desta funcionalidade ser pressionada; nestes dispositivos, a renderização éfeita levando em consideração sua menor dimensão.

A página inicial deste trabalho facilita a navegação do usuário, pois nela estãocontidas todas as opções para as funcionalidades do site. Sua estrutura é mostrada nasimagens 28 e 29, respectivamente, renderizadas para dispositivos com alta e baixa resoluçãoespacial.

60

Figura 28: Página inicial mostrada em dispositivos com alta resolução.

Figura 29: Página inicial mostrada em dispositivos com baixa resolução.

61

A página de cadastro possui campos de preenchimento de dados intuitivos, além deum botão que possibilita o envio das informações para serem processadas no servidor, nelaé requisitado que o usuário insira informações relevantes para seu cadastramento, comonome usuário e senha em duplicidade para a garantia delas serem introduzidas da formadesejada pelo cliente, uma vez que elas são ocultadas durante sua inserção. As figuras 3031, exibem, respectivamente, as páginas renderizadas para dispositivos de alta e baixaresolução.

Figura 30: Página de cadastro mostrada em dispositivos com alta resolução.

62

Figura 31: Página de cadastro mostrada em dispositivos com alta resolução.

A página de usuário renderizada, é similar a de cadastramento. Nela são exibidascaixas para o usuário informar o nome escolhido e sua respectiva senha, além de possuirum botão para enviar as informações para serem autenticadas, e assim liberar acessoa novas funcionalidades no site.As Figuras 30 31, exibem, respectivamente, as páginasrenderizadas para dispositivos de alta e baixa resolução, que realizam a funcionalidade delogin.

Figura 32: Página de login mostrada em dispositivos com alta resolução.

63

Figura 33: Página de login mostrada em dispositivos com alta resolução.

Após o usuário ser autenticado, novas funcionalidades são liberadas, havendouma mudança significativa na barra de navegação. As atividades são representadas porícones, cujo o símbolo remete a ação realizada ao clicar nele. As imagens 34.a e 34.b,respectivamente, para dispositivos com telas de alta e baixa resolução, apresentam asmudanças provenientes da identificação do usuário na barra de navegação, sendo que naimagem 34.b possui a descrição de cada item.

Figura 34: Mudança na barra de navegação em dispositivos de alta resolução (a) e embaixa resolução(b).

Quando escolhe-se a opção de verificar o log, o body da página renderizada varia,caso o usuário seja administrador de alguma sala o da imagem 35.a é mostrado indicandouma caixa com todas as salas que o usuário administra, caso contrário é mostrada daimagem 35.b. Ao clicar no botão enviar, um log contendo a utilização da sala será exibido.

64

Figura 35: Body da página de consulta de log de salas (a)caso o usuário seja administradorde alguma sala;(b) caso o usuário não administre alguma sala.

De forma similar, o body para vincular um usuário a uma sala por um administradoré representado na imagem 36.B quando a credencial é de um administrador, e 36.A quandoo usuário não o é.

Figura 36: (A) corpo de página renderizado se o usuário identificado não for administradorde alguma sala;(B) corpo de página renderizado se o usuário for administradorde alguma sala.

A corpo da página de utilizar uma sala, é idêntico ao de verificar um log, Figura35, para esta ao pressionar o botão enviar, é estabelecida a comunicação MQTT, e asrespostas possíveis são renderizadas no corpo da página, caso não obtenha resposta do

65

NodeMCU em até 10 segundos, a página de Figura 37 é renderizada; caso contrário, érenderizada a Figura 38, informando o exito da comunicação.

Figura 37: Corpo da página renderizada quando o NodeMCU não responde em até 10segundos.

Figura 38: Corpo da página renderizada quando há uma resposta do NodeMCU.

O modo de identificação por QR code, facilita para o usuário o acesso a uma sala.Seu funcionamento ocorre de forma similar a de um cartão, no qual o usuário deve exibirpara uma câmera o display do celular contendo o seu QR code de identificação. O corpoda página contendo a informação renderizada do QR code está na Figura 39.

Figura 39: Corpo da página renderizada exibindo o QR code do usuário.

67

5 CONCLUSÕES

De forma geral o desenvolvimento do projeto mostra-se eficiente para o processode controle de acesso. Como visto nos resultados, ele garante a verificação do registro doambiente controlado e a adição de acesso novos usuários, por qualquer pessoa no mundo,desde que estas possuam as credenciais necessárias para tais funcionalidades. Por estesmotivos, este sistema pode ser explorado em estabelecimentos como hotéis, salas alugadas,ou qualquer ambiente em que o usuário terá acesso momentâneo a ele. Nestes casos há apossibilidade de automação de diversos serviços relacionados ao controle dos usuários queutilizarão um serviço ou um ambiente, podendo a disponibilidade destes serem garantidasde forma automática durante o tempo que o serviço foi contratado. Em hotéis, por exemplo,este serviço automatizaria os serviços de check-in, garantindo o acesso imediato ao usuárioapós a confirmação do pagamento pertinente a sua estadia; outro aspecto, relacionadoa este serviço, que resulta em um maior sentimento de confiança por parte do usuárioque o utiliza, seria garantir o acesso aos registros, durante o tempo de uso, do ambientecontrolado, sendo assim possível verificar se houve algum acesso indevido a ele.

A utilização do Firebase mostrou-se funcional para este tipo de aplicação. Porutilizar um cartão microSD de 8 Gb para o armazenamento de dados, operar um bancode dados na nuvem é uma solução viável, devida a restrição de memória encontradaneste sistema. O API, possui um sistema de segurança otimizado, garantindo maiorconfidenciabilidade nas informações presentes sobre os logs gerados pelo sistema e sobre ocredenciamento do usuário; dificultando o seu acesso de forma indevida. A aplicação doFirebase, porém, necessita de acesso a rede, impossibilitando a implantação deste sistemaem locais onde há a ausência deste serviço, além da perda de sua funcionalidade casoocorra interrupção deste serviço, fazendo com que o sistema seja dependente da internetpara seu funcionamento.

A aplicação web garantiu o acesso às funcionalidades presentes no sistema a usuáriosde diversas plataformas, uma vez que é executada no navegador, tornando-se independentedo hardware e do sistema operacional do dispositivo. A produção de um site responsivomelhorou a experiência do usuário durante sua utilização, uma vez que o conteúdo presente,neste, se adapta para a sua melhor forma de exibição.

Tanto a unidade de aquisição de imagens, IP Cam quanto a de processamentoRaspberry Pi e de atuação NodeMCU, possuem preços acessíveis, sendo que a primeirapode ser encontrada por menos de 100 reais, enquanto a segunda, se optado pelo modelozero, possui o valor de 5 U$S. Porém, vale salientar que utilização de uma Raspberry Picomo unidade de processamento restringe o uso de algumas funcionalidades do sistema,como o atendimento de vários usuários ao mesmo tempo, ou a adoção de mais de um

68

ambiente com acesso garantido via QR code, para aplicações que necessitam abrangerum público maior, será necessário a utilização de um servidor, fazendo com que o custoagregado final deste produto seja incrementado, além do fato de que, caso o produtotenha um viés comercial, será necessária a mudança do NodeMCU uma vez que este nãoapresenta uma homologação da Anatel, impossibilitando sua comercialização para estesfins. Logo pode verificar que um sistema de baixo custo ficaria restrito a um projeto decontrole de acesso de nível doméstico, com apenas um ambiente sendo controlado por QRcode.

Ao analisar a arquitetura proposta por este projeto, Figura 23, nota-se que ela podeser utilizada em outras atividades, diferentes do controle de acesso. O conteúdo presentedeste trabalho consegue dar suporte a aplicações de instrumentação remota, na qual aleitura de um sinal advindo de um transdutor pode ser adquirida por um microcontroladorremotamente, enviada para um servidor, processada e mostrada para o usuário, além deser armazenada em um banco de dados, garantindo a este um histórico das medições e acriação de uma base de dados, possibilitando a aplicação de algorítimos de inteligênciaartificial, com suas possíveis eferências. Devido ao aumento do acesso no campo, aplicaçõesdeste tipo são vistas no setor de máquinas agrícolas, na qual já é possível obter informaçõesrelacionadas ao funcionamento da máquina em campo, e com isso verificar e otimizar oprocesso feito por ela, além de controlar algumas de suas funcionalidades de forma remota(64).

Para trabalhos futuros, há a possibilidade da criação de um projeto passível de sercomercializado. Para tal fim, há a necessidade da elaboração do esquemático e da placa decircuíto impresso contendo um microcontrolador, um módulo que tenha suporte a internete todos os componentes necessários para seu funcionamento. Há uma válida prospecçãode tecnologias para o reconhecimento de padrões biométricos individuais, agregando umamaior confiabilidade e facilidade para o usuário.

69

REFERÊNCIAS

1 FERMAX. Fermax Professional. Acesso em: 16 de junho de 2018. <https://www.fermax.com/intl/en/pro.html>.

2 SCIENTIFIC AMERICAN. Escâneres da palma das mãos garantem mais segurança.Acesso em: 11 de junho de 2018. <http://www2.uol.com.br/sciam/noticias/escaneres_da_palma_das_maos_garantem_mais_seguranca.html>.

3 APPLE. Sobre a tecnologia avançada do Face ID. Acesso em: 11 de junho de 2018.<https://support.apple.com/pt-br/HT208108>.

4 BRADESCO. Biometria. Acesso em: 16 de junho de 2018. <https://banco.bradesco/html/classic/canais-digitais/autoatendimento/biometria.shtm>.

5 ITAU. Biometria. Acesso em: 16 de junho de 2018. <https://www.itau.com.br/atendimento-itau/para-voce/conta-corrente/biometria/o-que-e-e-como-cadastrar-biometria-itau.html>.

6 BANCO DO BRASIL. Biometria. Acesso em: 16 de junho de 2018. <http://www.bb.com.br/pbb/pagina-inicial/bb-seguranca/biometria#/>.

7 SANTANDER. Biometria. Acesso em: 16 de junho de 2018. <https://www.santander.com.br/br/pessoa-fisica/santander/atendimento/nos-caixas-eletronicos>.

8 ELEITORAL, T. R. Identificação biométrica. Acesso em: 16 de junho de 2018.<http://www.tre-sp.jus.br/eleitor/identificacao-biometrica-1/identificacao-biometrica>.

9 WANG, Y. Q. H. A. F. D. L. L. L. G. H. Data Acquisition and Quality Analysis of3-Dimensional Fingerprints. 16 de maio de 2011. Florida: IEEE conference on Biometrics,Identity and Security.

10 STRICKLAND, E. The Biometric Wallet. Acesso em: 16 de junho de 2018.<https://spectrum.ieee.org/biomedical/imaging/the-biometric-wallet>.

11 FERMAX. Biometric Access Control: pros and cons. Acesso em: 16 de junho de 2018.<http://blog.fermax.com/eng/biometric-access-control-pros-and-const>.

12 GOOGLE. Consumer Baromether - Curated Insights. Acesso em: 11 de junho de 2018.<https://www.consumerbarometer.com/en/insights/?countryCode=BR>.

13 AN Access Control Mechanism for Remote Control of Home Security System.In: 2012 Sixth International Conference on Innovative Mobile and Internet Servicesin Ubiquitous Computing (IMIS). [s.n.], 2012. v. 00, p. 93–98. Disponível em:<doi.ieeecomputersociety.org/10.1109/IMIS.2012.146>.

14 SYMPLA. Sobre o Sympla. Acesso em: 11 de junho de 2018. <https://www.sympla.com.br/sobre-sympla>.

70

15 JUSTIçA ELEITORAL. Aplicativo e-Título da Justiça Eleitoral per-mite ao eleitor votar com documento digital. Acesso em: 11 de junhode 2018. <http://www.tse.jus.br/imprensa/noticias-tse/2017/Dezembro/aplicativo-e-titulo-da-justica-eleitoral-permite-ao-eleitor-votar-com-documento-digital>.

16 AGIN, G. J. Computer vision systems for industrial inspection and assembly.Computer, v. 13, p. 11–20, 1980.

17 CORNELL. Computer Vision and Medical Image Analysis. Acesso em: 16 de junho de2018. <http://www.via.cornell.edu/research/overview.html>.

18 LAPIMO. Laboratório de Análise e Processamento de Imagens Médicas eOdontológicas Analysis. Acesso em: 16 de junho de 2018. <http://lapimo.sel.eesc.usp.br/lapimo/drupal/>.

19 OBSERVATóRIO DE SEGURANçA PúBLICA. A era da vigilância. Acesso em: 16 dejunho de 2018. <http://www.observatoriodeseguranca.org/seguranca/cameras>.

20 PENTLAND, M. A. T. A. P. Faces Recognition Using Eigenfaces. Acesso em: 16de junho de 2018. Vision and Modeling Group, The Media Laboratory MassachusettsInstitute of Technology.

21 PENTLAND, M. A. T. A. P. Introduction to the Special Issue on Biometrics: Progressand Directions. Acesso em: 16 de junho de 2018. <https://www.computer.org/csdl/trans/tp/2007/04/i0513.pdf>.

22 GOVERNO DO ESTADO DE SãO PAULA, SECRETARIA DE SEGURANçAPúBLICA. Mapa de crimes. Acesso em: 16 de junho de 2018. <http://www.ssp.sp.gov.br/acoes/leAcoes.aspx?id=33833>.

23 ELMASRI RAMEZ; NAVATHE, S. B. Fundamentais of Database Systems. 2006.

24 CASANOVA M.A.;CâMARA, G. D. C. L. G. Bancos de Dados Geográficos. 2005.

25 CETAX. DATA WAREHOUSING. Acesso em: 06 de fevereiro de 2018.<https://www.cetax.com.br/blog/dw-data-warehousing/>.

26 LYTRA, I. et al. A big data architecture for managing oceans of data and maritimeapplications. 2017. 1216-1226 p.

27 FIREBASE. Firebase. Acesso em: 3 de outubro de 2018. <https://firebase.google.com/?hl=pt-br>.

28 WHAT Exactly Is a Web Application? Acesso em: 06 de março de 2018.<https://www.lifewire.com/what-is-a-web-application-3486637>.

29 KUROSE, K. W. R. J. F. Computer Networking. A top-down approach. 2013.

30 YUAN, M. Conhecendo o MQTT. Acesso em: 24 de setembro de 2018. <https://www.ibm.com/developerworks/br/library/iot-mqtt-why-good-for-iot/index.html>.

31 HEATH, S. Embedded systems design. 2003.

32 MATSUI., M. Selected Areas in Cryptography: 10th Annual International. 2003.

71

33 HALL, E. C. Journey to the Moon: The History of the Apollo Guidance Computer.Reston, Virginia, USA: American Institute of Aeronautics and Astronautics. 1996.

34 PALMER, R. C. The Bar Code Book. 2007.

35 MOTOROLA. Barcoding basics. Acesso em: 24 de setembro de 2018. <https://emptechgroup.com/wp-content/uploads/2013/02/EMP-Barcode101.pdf>.

36 FURHT, B. Handbook of Augmented Reality. 2011.

37 DIáRIO DO TRANSPORTE. Veículos brasileiros terão placas padrão Mercosul a partirde setembro. Acesso em: 25 de setembro de 2018. <https://diariodotransporte.com.br/2018/03/08/veiculos-brasileiros-terao-placas-padrao-mercosul-a-partir-de-setembro/>.

38 ISO/IEC. Information technology — Automatic identification and data capturetechniques — QR Code bar code symbology specification. Acesso em: 25 de setembro de2018. <https://www.iso.org/standard/62021.html>.

39 RASPBERRY. Raspberry Pi 1 Model. Acesso em: 22 de maio de 2018.<https://www.raspberrypi.org/products/raspberry-pi-1-model-b-plus/>.

40 RASPBIAN. Raspbian. Acesso em: 22 de maio de 2018. <https://www.raspberrypi.org/downloads/raspbian/>.

41 PUTTY. PuTTY. Acesso em: 22 de maio de 2018. <https://www.putty.org>.

42 PYTHON. Welcome to Python. Acesso em: 22 de maio de 2018. <https://www.python.org>.

43 NUMPY. Numpy. Acesso em: 22 de maio de 2018. <http://www.numpy.org>.

44 OZGUR. python-firebase. Acesso em: 22 de maio de 2018. <https://github.com/ozgur/python-firebase>.

45 CELLAN-JONES, R. A 15 pound computer to inspire young programmers. Acesso em:24 de maio de 2018. <http://www.bbc.co.uk/blogs/thereporters/rorycellanjones/2011/05/a_15_computer_to_inspire_young.html>.

46 ESPRESSIF. ESP8266. Acesso em: 25 de setembro de 2018. <https://www.espressif.com/en/products/hardware/esp8266ex/overview>.

47 STOER, M. nodemcu-firmware. Acesso em: 26 de setembro de 2018. <https://github.com/nodemcu/nodemcu-firmware>.

48 MICRO PYTHON. MicroPython. Acesso em: 26 de setembro de 2018.<https://micropython.org>.

49 D-A-V. ESP8266 core for Arduino. Acesso em: 26 de setembro de 2018.<https://github.com/esp8266/Arduino>.

50 IOT BYTES. NodeMCU Pinout. Acesso em: 26 de setembro de 2018.<https://iotbytes.wordpress.com/nodemcu-pinout/>.

51 ECLIPSE FOUNDATION. The Eclipse Foundation. Acesso em: 26 de setembro de2018. <https://www.eclipse.org/org/foundation/>.

72

52 ZBAR. Bar code reader. Acesso em: 26 de setembro de 2018. <http://zbar.sourceforge.net>.

53 PINCUS, Z. Zbar-py. Acesso em: 26 de setembro de 2018. <https://pypi.org/project/zbar-py/>.

54 LINCOLNLOOP. Py QRcode. Acesso em: 26 de setembro de 2018. <https://pypi.org/project/qrcode/#description>.

55 FLASK. Welcome | Flask. Acesso em: 26 de setembro de 2018. <http://flask.pocoo.org>.

56 ECLIPSE FOUNDATION. About the Eclipse Foundation. Acesso em: 8 de outubro de2018. <https://www.eclipse.org/org/>.

57 ECLIPSE FOUNDATION. Eclipse Mosquitto. Acesso em: 8 de outubro de 2018.<http://mosquitto.org>.

58 MATERIALIZE. About - Materialize. Acesso em: 28 de maio de 2018.<https://materializecss.com/about.html>.

59 KNOLLEARY. PubSub. Acesso em: 26 de setembro de 2018. <https://github.com/knolleary/pubsubclient>.

60 ADAMS, J. S. Mechanical Drawings - Raspberry Pi 2. Acesso em: 3 de outubro de2018. <https://www.raspberrypi.org/documentation/hardware/raspberrypi/mechanical/rpi_MECH_bplus_1p2.pdf>.

61 ANATEL. Portal Setor Regulado. Acesso em: 8 de outubro de 2018. <http://www.anatel.gov.br/setorregulado/apresentacao-certificacao>.

62 SIERRA. Wi-Fi and Bluetooth Modules for the Internet of Things (IoT). Acessoem: 8 de outubro de 2018. <https://www.sierrawireless.com/products-and-solutions/embedded-solutions/wifi-bluetooth-modules/>.

63 MICROCHIP. PIC18F4550. Acesso em: 8 de outubro de 2018. <https://www.microchip.com/wwwproducts/en/PIC18F4550>.

64 JOHN DEERE. Agricultura conectada é aposta da John Deere para Expointer 2018.Acesso em: 14 de outubro de 2018. <https://www.deere.com.br/pt/a-nossa-empresa/notícias/sala-de-imprensa/2018/aug/expointer-2018.html>.