TCCSENAI

Gabriel Galli Brandini
Letícia Mendes de Souza
Sistema de controle de acesso utilizando autenticação por RFID e

gerenciamento por meio de software WEB
São Carlos, 2022
Gabriel Galli Brandini

Letícia Mendes de Souza
Sistema de controle de acesso utilizando autenticação por RFID e

gerenciamento por meio de software WEB
Monografia apresentada ao Curso de Técnico em
Mecatrônica da Faculdade de Tecnologia e escola
SENAI de São Carlos.
Orientador: André Roberto da Silva

Coorientador: Vladimir Pinheiro da Silva
São Carlos, 2022

“O homem que evita dúvidas, nunca terá certezas.” (Johnnie Walker)
A realização de uma determinada tarefa com rapidez e confiabilidade são

característi- cas da sociedade moderna. Com isso é proposto neste trabalho o
desenvolvimento de um sistema de controle de acesso para um laboratório
trazendo mais segurança a seu patrimônio, bem como o monitoramento de seus
colaboradores, gerando relatórios mensais com carga horária de trabalho e
permitindo a seu supervisor monitorar a carga horária da jornada de trabalho
previamente estabelecida. Todo o gerenciamento do sistema é feito através de um
software WEB que pode ser acessado on-line em tempo real por meio de um
browser. Para manter a aplicação rodando 24h por dia todo o sistema, incluindo o
front-end da aplicação o back-end e banco de dados estão hospedados em um
servidor da Amazon, o Amazon Elastic Compute Cloud (Amazon EC2). Para
autenticação de um usuário no sistema foi desenvolvido em hardware um
protótipo de sistema embarcado que tem como métodos de entrada cartões RFID (
Radio Frequency Identification ) e teclado númerico. A placa de desenvolvimento
utilizada foi a ESP32-DevKitC que se comunica com o servidor pela internet por
meio de uma API ( Application Programming Interface ) pelo protocolo HTTP (
HyperText Transfer Protocol ) e, consequentemente, armazena as informações de
acesso em um sistema de gerenciamento de banco de dados, o MySQL. Um LCD
( Liquid Crystal Display ) foi utilizado para a exibição das informações
localmente. Após a finalização do projeto e com os testes realizados seus
resultados se mostraram de acordo com os objetivos propostos, sendo possível
sua implementação para quem tenha interesse em um sistema de controle de
acesso e gerenciamento via software WEB.
Palavras-chaves: controle de acesso; segurança e software WEB.
Performing a given task quickly and reliably is a characteristic of the modern

society. With this. it is proposed in this paper the development of an access
control system for a laboratory bringing more security as well as the monitoring
of its employees, generating monthly reports with workload and allowing to the
supervisor verify that the workday is being met. The system management is
performed through a WEB software that can be accessed online in real time
through a browser, and keep the application running 24 hours a day the entire
system including the front-end of the application, the back-end and database
which are hosted on an Amazon server, the Amazon Elastic Compute Cloud
(Amazon EC2). In order to authenticate a user in the system, a prototype
embedded system was developed in hardware that has as input methods RFID
cards (Radio Frequency Identification) and numeric keypad. The development
board used was the ESP32-DevKitC which communicates with the server over
the internet through an Application Programming Interface (API) using the
HyperText Transfer Protocol (HTTP) and consequently store the access
information in a database management system, MySQL. A LCD (Liquid Crystal
Display) was used to display information locally. After the project was completed
and the tests performed, it was observed the its results were in accordance with
the proposed objectives, being possible its implementation by anyone interested
in an access control system.
Key-words: access control; security and WEB software.
Pinagem do ESP32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Troca de informação entre antena e tag RFID. . . . . . . . . . . . . . . 20
Faixas de frequência de um RFID. . . . . . . . . . . . . . . . . . . . . 21
Leitor RFID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Conexão entre módulo o RC522 e Esp32. . . . . . . . . . . . . . . . . . 22
Estrutura de um cartão RFID. . . . . . . . . . . . . . . . . . . . . . . 22
Chaveiro RFID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Tipos de comunicação. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Conexão master-slave. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Comunicação SPI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Conexão pinagem SPI. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Barramento I C com dois dispositivos conectados. . . . . . . . . . . . .
2
26
Display LCD 16x2 conexão 4bits. . . . . . . . . . . . . . . . . . . . . . 30

Esquemático de ligação do display LCD com o microcontrolador. . . . 31
2C para display LCD. . . . . . . . . . . . . . . . . . . .
Módulo Serial I 31
Display LCD backlight azul. . . . . . . . . . . . . . . . . . . . . . . . . 32
Ambiente de gerenciamento do phpMyAdmin. . . . . . . . . . . . . . . 33
Editor de texto Atom. . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Criação de novo projeto. . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Exemplo de fluxo da api na rota auth-by-tag. . . . . . . . . . . . . . . 41
Tabelas utilizadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Conexão entre módulo o RC522 e Esp32. . . . . . . . . . . . . . . . . . 45
Conexão do teclado matricial com o microcontrolador. . . . . . . . . . 46
Esquemático de ligação do display LCD com o microcontrolador. . . . 46
Montagem protótipo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Tela de login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Tela ao ligar o dispositivo. . . . . . . . . . . . . . . . . . . . . . . . . . 50
Tela de login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Tela de login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Tela de login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Tela de login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Tela inicial com Wi-Fi conectado. . . . . . . . . . . . . . . . . . . . . . 51
Tela inicial sem conexão com Wi-Fi. . . . . . . . . . . . . . . . . . . . 52
Fluxograma sistema embarcado. . . . . . . . . . . . . . . . . . . . . . . 52
Software Proteus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Esquemático da placa feita no Proteus. . . . . . . . . . . . . . . . . . . 53
Fonte Hi-link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Página de histórico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Página para cadastrar um novo usuário. . . . . . . . . . . . . . . . . . 55
Página que exibe todos os usuários cadastrados. . . . . . . . . . . . . . 56
Modal para editar um usuário. . . . . . . . . . . . . . . . . . . . . . . 56
Página para gerar relatório. . . . . . . . . . . . . . . . . . . . . . . . . 57
Exemplo de relatório. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Página de ajuste de ponto. . . . . . . . . . . . . . . . . . . . . . . . . . 58
Página de gerenciamento de tags. . . . . . . . . . . . . . . . . . . . . . 59
Página de perfil do usuário. . . . . . . . . . . . . . . . . . . . . . . . . 60
Arquitetura do sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Estudo de caso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Software Wireshark. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Request HTTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Response HTTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Request HTTPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Response HTTPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Lista de tabelas
Tabela 1
Tabela 2
Tabela 3
Tabela 4
Tabela 5
Lista dee abreviaturas

siglas
RFID Radio Frequency Identification
IoT Internet of Things
API Application Programming Interface
HTTP HyperText Transfer Protocol
IHM Interface Homem Máquina
LCD Liquid Crystal Display
SPI Serial Peripheral Interface
I C
2
Inter-Integrated Circuit
SDA Serial Data
SCL Serial Clock
DAC Digital-to-Analog Converter
ADC Analog-to-Digital Converter

CAN Controller Area Network
GPIO General Purpose Input/Output
RTOS Real Time Operating System
HTML Hypertext Markup Language
CSS Cascading Style Sheets
Sumário
• Introdução
Sempre foi problema da sociedade a necessidade de ter segurança no meio em

que se vive, não somente em relação à segurança pessoal, mas também de manter um
local seguro quando não se está nele ou próximo o suficiente para tê-lo em vista
(CARDOSO, 2014).
Além da necessidade de manter um local seguro também é necessário ter o
controle sobre determinados setores, sendo possível o acesso somente por pessoas com
autorização previamente declarada. Embora soluções já conhecidas como portas e
fechaduras resolvem o problema de manter um local seguro elas não fornecem a
solução do controle de acesso (CARDOSO, 2014).
Nos últimos anos, processos de identificação automática têm sido muito
utilizados em diversos tipos de serviços industriais como logística de compra e
distribuição, empresas de manufatura e de fluxo de materiais. Esses procedimentos
automáticos conseguem fornecer informações sobre pessoas, animais, mercadorias e
produtos em trânsito (FINKENZELLER, 2010).
Com o avanço da tecnologia o custo de componentes eletrônicos está cada vez
mais baixo o que possibilita desenvolver sistemas mais complexos com menor custo
de produção e consequentemente entregando ao usuário final um produto mais barato,
que é um fator importante para o comércio.
“Os sistemas computacionais embarcados estão presentes em praticamente
todas as atividades humanas e, com os baixos custos tecnológicos atuais, tendem a
aumentar sua presença no cotidiano das pessoas” (CARRO; WAGNER, 2003).
Neste trabalho é feita a integração de um sistema embarcado que é responsável
por coletar a informação de um usuário e enviar essa informação para um software que
realiza todo o gerenciamento do controle de acesso de usuários, permitindo ou não o
usuário a ter acesso ao local e salvando todo seu histórico em banco de dados para que
um supervisor tenha controle sobre seus colaboradores.
• Objetivo Geral
A proposta do trabalho é desenvolver um sistema de controle de acesso onde
ocorre a integração de um sistema embarcado com um servidor WEB, e essa
comunicação é feita pela internet por meio de rede Wi-Fi pelo protocolo HTTP, e
que verifica a autenticidade
de um usuário no sistema.
• Objetivos Específicos
• Desenvolver um sistema embarcado do tipo fechadura eletrônica com integração

de alguns módulos como leitor RFID, teclado matricial e LCD;
• Desenvolver o back-end da aplicação, utilizando o microframework LUMEN;
• Desenvolver o front-end da aplicação utilizando o framework Angular;
• Modelar o banco de dados utilizando o MySQL para armazenar informações

de usuários e de acesso;
• Ter um histórico de acessos.
• Justificativa
A forma com que é feito o controle e liberação da utilização das
dependências dos laboratórios em geral da Escola de Minas ainda é muito manual.
O aluno precisa ir à portaria pedir a chave do laboratório, o porteiro verifica se há
uma autorização assinada pelo responsável do laboratório que permite ao aluno a
pegar a chave e utilizar o laboratório. Caso o aluno esteja autorizado o porteiro marca
em um caderno o nome do usuário e o horário em que o mesmo pegou a chave. Caso
contrário, o aluno tem acesso negado.
O desenvolvimento de um sistema de controle de acesso permite a
automatização de todo esse processo. O responsável pelo laboratório faz o cadastro de
seus alunos pelo sistema WEB e já garante o acesso dos alunos às dependências do
laboratório com um login e senha, e consequentemente já será gravado no banco de
dados todo histórico de acesso de cada usuário.
O sistema também pode ser utilizado de outras formas, como administrar horas
que um aluno tem que cumprir em uma Iniciação Científica ou monitoria, gerando um
relatório mensal com a carga horária total cumprida no mês.
• Organização e estrutura
Este trabalho está dividido em cinco capítulos, o primeiro contém uma breve
introdução sobre o tema abordado. No capítulo 2 é realizada uma revisão
bibliográfica sobre o tema estudado, contendo as especificações das tecnologias
utilizadas. No capítulo 3 apresenta-se a metodologia utilizada no desenvolvimento
do sistema. No capítulo 4 serão
apresentados os resultados obtidos e uma descrição de seu funcionamento. No capítulo

5 serão abordadas as conclusões sobre o desenvolvimento do sistema e recomendações
para trabalhos futuros.
• Revisão Bibliográfica
Esta seção apresenta definições e tecnologias utilizadas no trabalho, para um
entendimento mais profundo do sistema.
• Sistemas Embarcados
Os sistemas embarcados possuem a capacidade computacional dentro de um
circuito integrado, equipamento ou sistema. “É um sistema completo e independente,
mas preparado para realizar apenas uma determinada tarefa” (CUNHA, 2007).
O usuário de um sistema embarcado não possui acesso ao firmware do
dispositivo, mas interage com ele através de módulos acoplados, como teclado, LCD
entre outros (CUNHA, 2007).
De acordo com Barros e Cavalcante (2010) sistemas embarcados possuem
algumas características que são comuns:
• Funcionalidade única: usualmente um sistema embarcado executa somente um programa

repetidamente. Por exemplo, um pager é sempre um pager, enquanto que um computador
pessoal pode executar uma variedade de programas;
• Restrições de projeto mais rígidas: todos os sistemas de computação possuem em geral
alguma restrição de projeto a ser satisfeita, como por exemplo custo, tamanho,
desempenho, potência dissipada, etc. Nos sistemas embarcados, no entanto, estas
restrições são normalmente mais rígidas, por exemplo o custo de um sistema não pode
ser muito alto para não onerar o custo do equipamento, o tempo de resposta deve
permitir em várias aplicações processamento em tempo real e devem dissipar pouca
potência para permitir uma maior duração da bateria ou não necessitar de um sistema
de refrigeração;
• Sistemas reativos de tempo real: muitos sistemas embarcados devem reagir a mudanças no
ambiente e devem fornecer resultados em tempo real. Por exemplo um piloto automático
(cruise controller) continuamente monitora e reage a velocidade e aos sensores de freio.
Ele deve computar a aceleração e desaceleração repetidamente num intervalo de tempo.
Caso haja um retardo o controle do carro pode ser perdido.
Um sistema embarcado pode ter diversos tipos de aplicações, desde controle

de freios de um veículo automotivo, em que o dispositivo necessita fazer todo o
gerenciamento de periféricos acoplados a ele como sensores, até uma aplicação que
faz leitura de sensores de temperatura e umidade e envia os dados para um display ou
um banco dados (CHASE; ALMEIDA, 2007).
2.1.1 Placa de desenvolvimento ESP32-DevKitC

De acordo com OLIVEIRA (2017):
Internet das Coisas é muito mais que apenas ligar lâmpadas pelo
smartphone. Não é somente ligar as ‘coisas’ pela internet, mas também
torná-las inte- ligentes, capazes de coletar e processar informações do
ambiente ou das redes às quais estão conectadas
Desde que começou a popularização da internet já se pensava em formas de

fazer com que dispositivos utilizados no dia a dia pudessem se comunicar com outros
dispositivos através da internet. Com o avanço de algumas tecnologias desenvolvidas
nos últimos anos isso se tornou realidade (OLIVEIRA, 2017).
Uma das tecnologias desenvolvidas que tornou possível esse avanço foi a
criação dos módulos baseados no microcontrolador ESP8266 da Espressif Systems,
além de possuir uma boa relação preço-recurso é um componente muito interessante
para aplicações de IoT (OLIVEIRA, 2017).
Os módulos ESP8266 tem uma grande variedade de modelos, com algumas
diferen- ças, como a quantidade de entradas e saídas disponíveis para acesso externo e
tamanho do módulo (CURVELLO, 2015).
No presente trabalho é utilizada a placa de desenvolvimento ESP32-DevKitC
(Figura 1), a qual é uma placa de desenvolvimento fabricada pela empresa Espressif
Systems.
Figura 1 – Pinagem do ESP32.

Fonte: Curvello HYPERLINK "https://2.bp.blogspot.com/-
6b2Bg9WQgp0/WnHMKK5fqvI/AAAAAAAABZc/rLtEsp5R
U8gAeH0_MmzCuBANI7iSKEoqgCLcBGAs/s1600/
Pinagem.png" (2015).
O ESP32 é uma versão evoluída do ESP8266, tendo mais poder de

processamento e quantidade de entradas e saídas. Tais características tornam seu uso
em IoT algo bem interessante, fazendo com que a presença de mais periféricos permita
sua integração com mais dispositivos e componentes diversos (CURVELLO, 2015).
Dentre os protocolos de comunicação, a placa tem suporte a SPI, UART, e I 2C,
também tem suporte a infravermelho e SDIO (para interface com cartão de memória),
e se diferencia das placas de desenvolvimento mais conhecidas como Arduino por
ter suporte a
CAN (Controller Area Network), Ethernet, DAC (Digital-to-Analog Converter) e

sensor de toque (CURVELLO, 2015).
O ESP32 também possui conexaõ bluetooth e Wi-Fi sendo a conectividade
bluetooth: v4.2 BR/EDR com Bluetooth Low Energy (BLE) e Wi-Fi: 802.11 b/g/n/e/i
(802.11n @ 2.4 GHz até 150 Mbit/s) com suporte a protocolos de segurança WFA,
WPA/WPA2 e WAPI.
Algumas especificações estão listadas abaixo:
• CPU: XtensaⓍR
Dual-Core 32-bits LX6;
• ROM: 448 KBytes;
• RAM: 520 Kbytes;
• Flash: 4 MB;
• Clock máximo: 240MHz;
• Conector micro-usb;
• Portas GPIO: 25;
• GPIO com funções de PWM, I2C, SPI, etc.;
• Tensão de operação: 4,5 9V;
• Conversor analógico digital (ADC) 12-bits.

• RFID
RFID (Radio Frequency Identification) é uma tecnologia de identificação sem
a necessidade de contato, através de ondas de rádio frequência. Pode-se dividir os
dispositivos RFID em duas classes: ativa e passiva.
Os dispositivos RFID com tags ativas conseguem emitir sinal e necessitam de
uma fonte de energia para funcionar, geralmente possuem uma bateria interna
integrada mas também podem estar conectadas a uma fonte de energia. Já os
dispositivos RFID com as tags passivas são alimentadas pela energia eletromagnética
que um leitor RFID emite, e, posteriormente, este recebe os dados gravados na tag
passiva (WANT, 2006).
Um exemplo de tag ativa é o transponder de uma aeronave, que identifica a
aeronave em si bem como sua posição. E esse sinal é captado por uma base no solo,
geralmente encontrada em aeroportos. Um exemplo de tag passiva é o uso de cartões
como bilhete para transporte público em ônibus.
Algo que é possível fazer com essa tecnologia é que além de ser possível a
leitura de um dado também é possível gravar informações na etiqueta RFID. “O que se
faz, algumas vezes como uma medida paliativa, é alterar no banco de dados a
informação associada àquele código, mas não se modifica o código em si”
(CUNHA, 2016).
Uma tag passiva consiste em três partes: uma antena, um chip semicondutor
conectado à antena e alguma forma de encapsulamento. O leitor de tags é responsável
por alimentar e se comunicar com uma tag. A antena da tag captura energia e
transfere o ID da tag (Figura 2). O encapsulamento mantém a integridade da tag,
protegendo sua antena e seu chip. O encapsulamento pode ser um pequeno frasco de
vidro (Figura 3a), ou um plástico laminar (Figura 3b) (WANT, 2006).
Figura 2 – Troca de informação entre antena e tag RFID.
Fonte: Cunha (2016).
A faixa de operação de frequência das tags irá determinar uma distância

mínima necessária para que o leitor RFID consiga identicar o ID da tag (Figura 4).
Figura 3 – (a)pequeno frasco de vidro (b) plastico laminar.
Fonte: WANT (2006).

Figura 4 – Faixas de frequência de um RFID.
Fonte: Cunha (2016).
2.2.1 Módulo RC522

O módulo RFID utilizado no projeto é da fabricante TENSTAR ROBOT
(Figura 5), kit RC522. O módulo RFID opera na frequência de 13.56Mhz. O
barramento de comunicação utilizado pelo módulo é o SPI (Serial Peripheral
Interface), permite escrita e leitura, e é do tipo passivo, onde o usuário poderá utilizar
de um cartão (Figura 7) ou um chaveiro (Figura 8) que contem o ID autorizado para
autenticação no sistema.
A conexão física entre o módulo RC522 e o microcontrolador é representado na
Figura 6. Os pinos SDA e RST do módulo podem ser conectados a qualquer GPIO
(General Purpose Input/Output) do microcontrolador, e no firmware quando for
instanciado o objeto para a utilização da biblioteca do módulo RFID define-se quais
foram os GPIOs conectados.
Figura 5 – Leitor RFID.
Figura 6 – Conexão entre módulo o RC522 e Esp32.
Fonte: Próprio autor.
Figura 7 – Estrutura de um cartão RFID.
Fonte: RFIDHY (2016).
Figura 8 – Chaveiro RFID.
Fonte: Silício HYPERLINK

"https://www.vidadesilicio.com.br/quickview/ind
ex/view/id/276" (2019).
• Comunicação Serial
De acordo com Sacco (2014) às tecnologias que fazem a interligação serial
entre dispositivos podem ser separadas em duas grandes categorias, a comunicação
síncrona e comunicação assíncrona (Figura 9). Dentre os métodos conhecidos,
destacam-se três:
• UART: Universal Asynchronous Receiver Transmitter;

• SPI: Serial Peripheral Interface;
• I2C: Inter Integrated Circuit.
Figura 9 – Tipos de comunicação.
Fonte: Sacco (2014).
Na Tabela 1 temos um comparativo entre diversos padrões de dispositivos seriais:
Na comunicação serial síncrona pode-se definir o conceito de Mestre-Escravo.

O gerador do sinal de sincronismo é o Mestre (Master ) da comunicação, e os
dispositivos que recebem o sinal de sincronismo gerado são definidos por Escravos
(Slaves). A ligação mais comum desse tipo de comunicação é conectar um dispositivo
Master com vários Slaves (Figura 10) (SACCO, 2014).
Tabela 1 – Comparativo entre comunicações seriais.
Tecnologia Barramento de Taxa Fluxo de dados

comunicação máxima
UART (RS232) 2 (sem controle de fluxo) 115.200 bps Half ou Full Duplex
SPI 3 + no de Slaves 2 Mbps Full Duplex
I2C 2 (até 127 dispositivos) 400 Kbps Half Duplex
Fonte: Sacco (2014)
Figura 10 – Conexão master-slave.
• Comunicação SPI
Os sinais da comunicação SPI (Serial Peripheral Interface) possui uma direção
fixa e definida, fazendo com que sempre haja dois transistores que definem o estado de
um pino (Push-Pull). Essa é uma característica que a difere entre outros tipos de
comunicação serial, como I C e OneWire, que possui um mesmo barramento de
2
dados para os sinais de entrada e saída através do esquema de dreno-aberto (Pull-Up)

(Figura 11) (SACCO, 2014).
Figura 11 – Comunicação SPI.
Outra característica da comunicação SPI é que sempre que ocorre troca de

dados entre o Master e o Slave, essa troca acontece em ambas as direções, definindo
uma comunicação full-duplex (SACCO, 2014).
De acordo com a Tabela 2 e a Figura 12 pode-se verificar a conexão entre o
dispositivo master e o slave.
Tabela 2 – Pinos para comunicação SPI.
Pino Nome Significado Nomes

Padrão Alternativos
Do Master MOSI Master Output SDO, DO, SO
para o Slave Slave Input
Do Slave MISO Master Input SDI, DI, SI
para o Master Slave Output
Clock SCLK Serial Clock SCK, CLK
Seleção de Slave SS Slave Select CS, nSS, nCS
Fonte: Sacco (2014)
Figura 12 – Conexão pinagem SPI.
• Comunicação I2C
De acordo com Leens (2009):

O I2C é um protocolo multimestre que utiliza duas linhas de
sinais. Os dois sinais I2C são chamados de serial data (SDA) e serial
clock (SCL). Não há a necessidade de um chip select para que o
master se conecte ao slave. Praticamente qualquer número de slave e
qualquer número de master podem ser conectados a estas duas linhas
de sinais e podem se comunicar entre si utilizando um protocolo que
define que cada dispositivo conectado ao barramento possui um
endereço único, os dados são divididos em bytes de 8 bits, e possui
também alguns bits de controle para o início, fim e a direção da
comunicação para um mecanismo de reconhecimento.
O protocolo I2C consiste basicamente na conexão dos pinos SDA e SCL ao

nível lógico alto, (Figura 13). Sendo ambos os pinos bidirecionais. Quando algum
dispositivo inicia a transferência de dados no barramento ele é considerado o Master e
consequentemente os outros dispositivos conectados ao mesmo barramento são
considerados Slave (LEENS, 2009).
Figura 13 – Barramento I2C com dois dispositivos conectados.
Fonte: Leens (2009).
• Display LCD
A exibição visual eletrônica de informação já é algo presente em muitos
aspectos em nossa vida. A exibição de informações é um elemento essencial para
a interface entre a máquina e os humanos. O LCD (Liquid Crystal Display) é um
excelente sistema para exibição de informações em tela plana, sendo suas qualidades
o seu peso leve, baixa tensão de acionamento, baixo consumo de energia, alta
resolução, grande ângulo de visão, alta qualidade de cor e disponibilidade em uma
ampla faixa de tamanho de tela (GU CLAIRE E YEH, 2015).
Os módulos LCD são muito utilizados em sistemas microprocessados. Eles
podem ser gráficos e a caractere. Os módulos gráficos podem ser encontrados com
algumas variações de resolução, como 122x32, 128x64, 240x64 e 240x128 dots pixel,
e geralmente possuem 20 pinos para conexão. Já os módulos do tipo caractere são
especificados em número de linhas por colunas e podem ser encontrados nas
configurações como mostra a tabela 3 (BARBACENA; FLEURY, 1996).
Os módulos podem ser encontrados com led backlight, que facilita a leitura
durante a noite. A alimentação desse led para os módulos do tipo caractere
normalmente é feita através dos pinos 15 e 16, sendo o pino 15 ligado ao anodo e o
pino 16 ligado ao catodo, já para os módulos do tipo gráfico é utilizados os pinos 19 e
20, sendo o pino 19 ligado ao anodo e o pino 20 ao catodo (BARBACENA;
FLEURY, 1996).
Estes módulos possuem um controlador próprio que permite sua interligação
com placas de desenvolvimento como a ESP32, através de seus pinos (Tabela 4),
bastando fazer
as conexões corretas para que ocorra a troca de dados entre o módulo LCD e a placa de
desenvolvimento acoplada (BARBACENA; FLEURY, 1996).
Uma forma de se fazer essa interligação física entre o módulo e a placa de
desenvolvimento está representada pela Figura 18. Neste caso não são utilizados
os pinos 7, 8, 9 e 10, sendo algo muito útil quando a placa de desenvolvimento possui
poucas IOs (BARBACENA; FLEURY, 1996).
Tabela 3 – Módulos LCD disponíveis
Numero de Colunas
Nmero de Linhas
Quantidade de Pinos
8 2 14
12 2 14/15
16 1 14/16
16 2 14/16
16 4 14/16
20 1 14/16
20 2 14/16
20 4 14/16
24 2 14/16
24 4 14/16
40 2 16
40 4 16
Fonte: Eletronica.org (2019)
Figura 18 – Display LCD 16x2 conexão 4bits.
O display utilizado no projeto é um display 16x2 com backlight (Figura 21) de

cor azul, e a conexão entre o display e o microcontrlador foi feita através de um
módulo serial
I2C (Figura 20), fazendo com que seja possível conectar o display lcd ao
microcontrolador pela comunicação I2C utilizando os pino SDA e SCL (Figura 19),
resultando em uma economia de pinos.
Figura 19 – Esquemático de ligação do display LCD com o microcontrolador.
Figura 20 – Módulo Serial I2C para display LCD.
Fonte: FilipeFlop HYPERLINK

"https://www.filipeflop.com/blog/teclado-
matricial-4x4-arduino/" (2019).
Figura 21 – Display LCD backlight azul.
Fonte: Livre (2019).
Tabela 4 – Módulos LCD disponíveis
Pino Função Descrição

1 Alimentação Terra ou GND
2 Alimentação VCC ou +5V
3 V0 Tensão para ajuste de con-
traste
4 RS Seleção: 1-Dado, 0-Instrução
5 R/W Seleção: 1-Leitura, 0-Escrita
6 E Chip Select 1-Habilita, 0-Desabilitado
7 B0 LSB Barramento de Dados
8 B1 Barramento de Dados
15 A (qdo existir) Anodo p/ LED Backlight
16 K (qdo existir) Katodo p/ LED Backlight
• Banco de dados
Fonte: Eletronica.org (2019).
“Os sistemas de banco de dados são projetados para gerir grandes massas de
informação. A gestão dos dados envolve tanto a definição de estruturas para o
armazenamento de informações quanto os mecanismos que preveem a manipulação
da informação.” (SILBERSCHATZ; SUNDARSHAN; KORTH, 2016).
De acordo com Heuser (2009) o projeto de um novo banco de dados da-se em
três fases, descrita a seguir:
• Modelagem conceitual - nesta primeira fase, é construído um modelo conceitual, na forma

de um diagrama entidade-relacionamento. Este modelo captura as necessidades da
organização em termos da armazenamento de dados independetemante de
implementação.
• Projeto lógico - a etapa de projeto lógico objetiva transformar o modelo conceitual obtido
na primeira fase em um modelo lógico. O modelo lógico define como o banco de dados
será
implementado em um SGBD (Sistemas de Gestão de Base de Dados) específico.

• Projeto físico - na etapa de projeto físico, o modelo do banco de dados é enriquecido com
detalhes que influenciam no desempenho do banco de dados, mas não interferem em sua
funcionalidade. O modelo obtido neste passo é o modelo físico do banco de dados.
• MySQL
O banco de dados MySQl é o banco mais conhecido do mundo de código
aberto, possui grande desempenho, confiabilidade e facilidade de uso comprovados. Se
tornou a principal opção de banco para desenvolvimento de software baseado na WEB,
utilizado por grandes empresas como Facebook, Twitter, YouTube entre outros
(ORACLE, 2019).
• phpMyAdmin
O phpMyAdmin (Figura 22) é um software gratuito desenvolvido em PHP para
administrar o banco de dados MySQL através da web. Todas as operações
frequentemente usadas para gerenciamento do banco de dados, de tabelas, colunas,
relações, índices, usuários, permissões entre outras, podem ser realizadas facilmente
pela interface da aplicação de forma bem simples (BRINGING, 2019).
Também é possível visualizar de forma gráfica todas as tabelas de um banco e
as respectivas relações entre as tabelas.
Figura 22 – Ambiente de gerenciamento do phpMyAdmin.
• Framework
Com a velocidade em que a tecnologia evolui não se pode perder tempo
querendo refazer “coisas” que já foram feitas, como por exemplo iniciar toda a
arquitetura de um projeto sempre que for começar um novo. Para que um
desenvolvedor não perca esse tempo precioso a utilização de um framework é algo
bem indicado.
“Os frameworks facilitam o desenvolvimento de software, permitindo que os
desenvolvedores se ocupem mais com os requerimentos do software do que com os
detalhes tediosos, de baixo nível do sistema” (LEONARDO, 2015).
Basicamente o framework prepara todo o ambiente de desenvolvimento, e é ele
quem se responsabiliza pelo fluxo de execução da aplicação (SAUVE, 200-).
“Um framework é composto por classes/métodos que são um conjunto de
instruções pré-preparadas para realizar determinadas tarefas” (LEONARDO, 2015).
O que difere um framework de uma biblioteca formada por classes é que em
uma biblioteca as classes são independentes umas das outras, já em uma framework
existe dependências e colaboração entre elas (SAUVE, 200-).
• API
Application Programming Interface - API pode ser entendida como uma ponte
de acesso entre o front-end de uma aplicação e o seu back-end da aplicação
(FERNANDES, 2018).
Basicamente o funcionamento de uma API ocorre por meio de uma url, quando o
frond-end da aplicação faz uma requisição ao back-end.
Exemplificando como funciona uma requisição, imagine que se tenha um servi-

dor rodando o front-end no link http://meu-site.com.br, e o back-end rodando no link
http://api-meu-site.com.br.
Abrindo o site http://meu-site.com.br ele irá exibir na tela todos os estados do
Brasil, e esses estados estão armazenados em um banco de dados . O que ocorre é que
quando o site é aberto ele fará uma requisição semelhante a que você fez ao colocar o
link na barra de navegação. Por trás dos “panos”, ao abrir o site, ele irá acessar o
seguinte link http://api-meu-site.com.br/pegarTodosEstados para pegar todos os
estados. Esse “pegarTodosEstados” é chamado de end-point ou rota, que nesse caso é
responsável por trazer todos os estados ao front-end e consequentemente exibir na tela.
O que acontece é que um back-end possui vários end-points, cada um
responsável por uma operação diferente, e essas operações é que são responsáveis por
fazer toda a conexão com banco de dados para manipulação do mesmo, como gravar,
editar, excluir,
entre outros.
• Lumen Framework
O Lumen é um microframework PHP open-source baseado no framework
Laravel, desenvolvido por Taylor Otwell, o Lumen é focado no desenvolvimento de
microsserviços e APIs REST.
Todo o back-end da aplicação foi feito em Lumen, onde foram definidas todas
as rotas utilizadas pelo sistema de gerenciamento (software WEB), quanto as utilizadas
pelo sistema embarcado (protótipo desenvolvido).
• Angular Framework
Angular é um framework open-source criado pelos desenvolvedores do Google
que é voltada para desenvolvimento de interfaces de aplicações utilizando HTML,
CSS e JavaScript (AFONSO, 2018).
Todo o front-end do software WEB foi desenvolvido em Angular. Para a
criação de componentes foram utilizadas bibliotecas como Kendo-UI, Bootstrap e o
Angular Material que é uma implementação do Material Design no Angular feito
pelo Google.
• Servidor Amazon EC2

Para o funcionamento do sistema, é necessário um servidor para que todas as
ferramentas fiquem em execução 24h por dia, como o front-end da aplicação WEB,
para que o site possa ser acessado a qualquer horário, o back-end (API desenvolvida) e
o banco de dados, no caso o MySQL.
De acordo com Amazon (2019) temos uma definição sobre o que é o Amazon EC2:
O Amazon Elastic Compute Cloud (Amazon EC2) oferece uma

capacidade de computação dimensionável na nuvem da Amazon
Web Services (AWS). O uso do Amazon EC2 elimina a necessidade
de investir em hardware inicialmente, portanto, você pode
desenvolver e implantar apli- cativos com mais rapidez. Você pode
usar o Amazon EC2 para executar o número de servidores virtuais
que precisar, configurar a segurança e a rede, e gerenciar o
armazenamento. O Amazon EC2 também permite a expansão ou a
redução para gerenciar as alterações de requisitos ou picos de
popularidade, reduzindo, assim, a sua necessidade de prever o
tráfego do servidor.
Basicamente o EC2 é uma máquina virtual em que o usuário tem acesso

total a seu sistema operacional para realizar as configurações necessárias para seu
projeto. A opção utilizada é gratuita por 12 meses, sendo uma máquina com 1GB de
memória RAM
e disponibilidade de até 30GB de armazenamento. O sistema operacional utilizado é o

Ubuntu Server 18.04.1 LTS.
O acesso ao EC2 é feito remotamente por um terminal de comando. A
comunicação é feita pelo protocolo SSH (Secure SHell), o que garante segurança com
criptografia durante a comunicação com o servidor.
Para que a comunicação ocorra entre usuário e servidor algumas configurações
são necessárias, como a liberação da porta 22 do servidor. Assim, como por padrão o
acesso a um site é feito pela porta 80 de um servidor a comunicação SSH por padrão é
feita pela porta 22.
Acessando o servidor pelo terminal o usuário tem controle total sobre o
sistema operacional, e consequentemente pode fazer as instalações necessárias, como
o banco de dados MySQL, o Apache HTTP Server e outros softwares que venham a
ser necessários.
2.8.1 Apache
O servidor Apache foi criado em 1995 por Rob McCool, sendo um servidor
web livre e o mais bem sucedido, utilizado principalmente em sistemas operacionais
Linux (CANALTECH, 2019).
De acordo com Andrei (2019) o Apache é responsável por manter cerca de
46% de todos os sites hospedados na internet.
Assim, como o SSH trabalha na porta 22 o Apache, por se tratar de um
servidor web, é executado na porta 80, para que as requisições ao site funcione
normalmente.
Quando um cliente acessa o domínio de um site pela barra de navegação ela é
redirecionada a um servidor web, neste caso o Apache. Esse servidor tem a função de
verificar qual foi esse endereço de solicitação e entregar ao cliente que fez essa
requisição as informações corretas. Por exemplo se alguém acessa o endereço
http://meu-site.com.br o Apache vai entender como a rota home da aplicação e irá
enviar todo o script daquela página ao computador do cliente. O browser do cliente ao
receber todo esse script irá renderizar ele de forma visual para o cliente.
• Desenvolvimento
Nesta seção serão apresentadas as etapas do desenvolvimento do projeto,
podendo ser dividido em 4 etapas. Na primeira etapa o desenvolvimento do Firmware
do sistema embarcado, na segunda etapa o desenvolvimento da API (o Back-end) da
aplicação, na terceira etapa o desenvolvimento do Front-end da aplicação e por fim o
desenvolvimento do circuito do sistema embarcado.
• Firmware
O firmware foi feito utilizando a linguagem Arduino, que tem por base a
linguagem C++. Algumas funções foram feitas utilizando FreeRTOS, que é um
sistema operacional de tempo real.
De acordo com FreeRTOS (2018) o FreeRTOS é um RTOS (Real Time
Operating System) líder de mercado da Amazon Web Services que suporta mais de
35 arquiteturas e foi baixado uma vez a cada 3 minutos em 2017. Ele é desenvolvido
profissionalmente, com muita qualidade sendo robusto e livre para incorporar produtos
comerciais sem qualquer necessidade de expor seu código-fonte.
O FreeRTOS tornou-se o padrão RTOS de fato para microcontroladores,
removendo objeções comuns ao uso de software livre e, ao fazê-lo, forneceu um
modelo de software livre realmente atraente (FREERTOS, 2018).
O firmware desenvolvido foi dividido em 6 classes sendo elas, a classe “API”,
“Relogio”, “RFID”, “Senha”, “Tela” e “Principal”.
A classe “API”, é responsável por se conectar ao servidor e fazer todas as
requisições necessárias. Toda parte em que ocorre troca de dados entre sistema
embarcado e servidor é gerenciado por essa classe, como os métodos de autenticação,
cadastro, remoção de tags, atualizar o horário que é exibido no LCD, entre outros.
A classe “Relogio”, é responsável por toda a lógica de funcionamento da data e
hora que são exibidas no LCD. Mesmo sem conexão com o servidor é possível alterar
a data e hora manualmente pelo dispositivo e seu funcionamento flui normalmente.
A classe “RFID”, é responsável por fazer a leitura da tag de um cartão e
consequentemente de acordo com a opção desejada executar os métodos de
autenticação, cadastro ou remoção de uma tag.
A classe “Senha”, é responsável por armazenar os dados de entrada do teclado

matricial para confirmar senhas digitadas e para quando for utilizada alguma opção de
troca de senha.
A classe “Tela”, é onde ficam todas as telas do sistema, como tela inicial, que
exibe a data do sistema e os ícones de conexão com Wi-Fi e servidor, e todas as
outras telas.
A classe “Principal” é o core do sistema. Ela é responsável por determinar o
que acontece quando uma tecla é pressionada em uma determinada tela e toda
transição de telas é gerenciada por essa classe.
Dentre as funções feitas utilizando FreeROTS está a função de leitura do
teclado matricial e a função que é utilizada para o contador de segundos do sistema,
além de fazer a contagem dos segundos, também tem como objeto verificar a cada 1
minuto se possui conexão com o servidor e consequentemente exibir no LCD para que
o usuário identifique se há algum problema de conexão.
Todo o desenvolvimento do firmware foi feito utilizando o editor de texto
Atom com o package PlatformIO (Figura 23). O PlatformIO é uma ferramenta que
tem compatibilidade para gravar mais de 600 placas de desenvolvimento, sendo uma
delas a placa Arduino, não sendo necessário a IDE do Arduino para gravar um
firmware na placa.
Para o desenvolvimento desse projeto a opção de placa selecionada no
PlatformIO foi a placa DOIT ESP32 DEVKIT V1 como mostra a Figura 24.
Figura 23 – Editor de texto Atom.
• Back-End
Figura 24 – Criação de novo projeto.

Todo o back-end da aplicação foi feito utilizando o framework Lumen, que
utiliza a linguagem de programação PHP.
Dentro da arquitetura do projeto em Lumen tem-se a parte de rotas, onde são
configurados todos os end-points utilizados no projeto, tem-se também uma parte onde
são criados todos os controllers da aplicação, que são as classes onde se encontram os
métodos responsáveis pela lógica de programação feita pelo desenvolvedor. Outra
parte importante são as Models, as quais são classes que basicamente tem como
responsabilidade a comunicação com o banco de dados para realizar operações de
leitura, escrita e validação de dados.
Abaixo temos trechos de códigos que mostram como isso é feito.
Exemplo de rotas.
Esse código representa os end-points utilizados pelo sistema embarcado. Exem-

plificando o código o prefixo com nome de api significa que todas as rotas dentro da-
quele grupo possuem como prefixo a palavra api. Na prática o que acontece é que para
fazer uma requisição na rota “auth-by-tag” será feita no seguinte link, http://api-meu-
site.com.br/api/auth-by-tag, que neste caso de acordo com o protocolo HTTP é uma
rota do tipo POST.
O “TagController” é classe onde está definido todos os métodos que essas rotas
irão utilizar. No caso da rota “auth-by-tag” o método utilizado se chama
“authByTag”, e
é nele que ocorre toda a lógica de programação dessa rota.
Lógica de programação da rota “authByTag”.
A rota “auth-by-tag” é responsável por verificar a autenticidade de um cartão, e

nela são feitas algumas validações antes de verificar se a tag do cartão está cadastrada
no banco de dados. Entre as validações está a validação do código da tag, se o código
possui 8 caracteres, e a validação do tamanho da chave de autenticação. Após essa
verificação é
feita a validação do token que é gravado no firmware do sistema embarcado,

confirmando sua autenticidade.
Depois dessa validação é verificado no banco de dados se a tag está
cadastrada e se possui um usuário vinculado à ela, caso tudo esteja de acordo o
sistema retorna uma resposta confirmando a autenticidade do cartão e
consequentemente grava na tabela de histórico os dados de acesso.
A Figura 25 demonstra o fluxo de funcionamento da api ao realizar a
requisição na rota “auth-by-tag”.
Figura 25 – Exemplo de fluxo da api na rota auth-by-tag.
• Banco de Dados
O banco de dados foi modelado com as seguintes tabelas,
“adjustment_requests”, “admins”, “data_users”, “histories”, “tags” e “users”.
A tabela “adjustment_requests”, é onde ficam gravadas todas as requisições de
ajuste de ponto quando um usuário esquece de passar o cartão no leitor RFID. Quando
isso ocorre o usuário deve entrar no site e pedir uma solicitação de ajuste com a data e
hora em que deveria ter passado o cartão no leitor.
A tabela “admins”, armazena quem são os administradores do sistema de
controle de acesso. Somente os administrados possuem permissão para realizar
algumas tarefas, como o cadastro de novos usuários, ter acesso ao relatório de ponto de
todos os usuários, aceitar ou recusar a solicitação de ajuste entre outras.
A tabela “data_users”, é onde ficam armazenados os dados do usuário, como
nome, sobrenome, telefone, endereço, login e senha para autenticação via login no
sistema embarcado.
A tabela “histories”, é responsável por armazenar o histórico de acesso de

todos os usuários. Mesmo que um cartão não esteja cadastrado no sistema e tente
acessar o sistema será armazenada a tentativa de acesso, o acesso por login e
senha também são gravados nesta tabela.
A tabela “tags”, armazena o código de todos os cartões cadastrado no
sistema, para sua autenticação.
A tabela “users”, é onde fica gravado o email e senha dos usuários para acessar
o site. Todas as senhas gravadas são salvas com uma hash, não sendo possível saber a
senha de um usuário mesmo acessando o banco de dados.
A Figura 26 mostra de forma gráfica todas as tabelas criadas e seus respectivos
relacionamentos.
Figura 26 – Tabelas utilizadas.
• Segurança
Todo o ecossistema WEB da aplicação está protegido com certificado de
segurança TLS (Transport Layer Security), o “https” no início do link da página.
Isso significa que toda troca de dados entre o front-end da aplicação com a API está
protegida com criptografia, mantendo a segurança do sistema e a integridade dos
dados.
• Front-End
Todo o front-end da aplicação foi feito utilizando o framework Angular. Para
estruturação do código foi utilizada a linguagem de marcação HTML, para estilização
do layout foi utilizado CSS e para realizar todas as lógicas de programação foi
utilizada a linguagem TypeScript.
Dentro da arquitetura do Angular tem-se os componentes. Cada componente
criado possui 3 arquivos principais, o arquivo html, o arquivo css e o arquivo
typescript. No arquivo html foi feita toda estrutura daquele componente em específico,
no css as estilizações utilizadas por aquele componente e o arquivo typescript fica
responsável por toda lógica que acontece naquele componente.
Este projeto é composto por 11 componentes, sendo eles “login”, “layout-
home”, “page-historico”, “page-cadastro”, “page-ajuste”, “page-perfil”, “page-
relatorio”, “page- tags”, “page-usuario”, “modal-user-edit” e “modal-vincula-tag”.
O componente “login”, é o componente responsável por exibir a tela de login.
Além dos componentes o angular também possui os arquivos services, e são nesses
arquivos que ficam gravados os end-points que foram feitos no back-end. Basicamente
são as classes que contém os métodos utilizados nas requisições ao back-end. O que
ocorre ao efetuar o login é que no arquivo typescript do componente “login” é
instanciado um objeto da classe do serviço responsável pelo login, e a partir desse
objeto é chamado o método da requisição de login.
A seguir temos trechos de códigos que mostram como isso é feito.
Método responsável pelo login dentro do arquivo typescript do componente “login”.

O método “onSubmit” é responsável por efetuar o login de um usuário no site,
basicamente o que ele faz primeiro é verificar se o formulário de login e senha está
válido, significando que o dado de entrada no campo email é de fato um email válido e
se no campo de senha possui no mínimo 6 caracteres. Se o formulário for válido ele
atribui a uma variável com o nome “obj” os dados de email e senha do usuário. Feito
isso o objeto “authService”, que é o objeto responsável para fazer as requisições ao
back-end, executa o método “loginUser”, passando como parâmetro a variável “obj”.
Caso o retorno da requisição venha com status 200, que significa que o usuário
foi autenticado com sucesso, a página será redirecionada para aba de histórico, caso
venha com status 401, significa que o usuário não foi autenticado com sucesso,
exibindo uma mensagem na tela de login.
Abaixo temos o trecho de código do método que é responsável por fazer a
requisição de login ao back-end.
Método responsável por fazer a requisição de login ao back-end.
Como é possível verificar, a requisição é do tipo POST. Onde está definido

como “$config.apiUrl/login” é a rota definida para efetuar o login no back-end, já a
variável “obj” contém os dados que serão enviados ao back-end para de fato fazer o
login.
O componente “layout-home”, é onde foi definida toda a estrutura de layout da
aplicação.
O componente “page-historico”, é a página onde será exibida as informações
referente ao histórico de acesso dos usuários, um usuário que não é administrador só
consegue visualizar seu próprio histórico, já os administradores possuem acesso total
ao histórico.
O componente “page-cadastro”, é a página responsável por efetuar o
cadastro de novos usuários e somente os usuários que são administradores possuem
acesso à essa página.
O componente “page-ajuste”, é onde são feitas as requisições de ajuste de
ponto, caso venha a ser necessário, também é nesta página onde é exibido todo o
histórico de ajuste dos usuários, os usuários que não são administradores só tem acesso
ao seu próprio histórico de ajuste e os administradores possuem acesso ao histórico de
todos os usuários.
O componente “page-perfil”, mostra ao usuário seus próprios dados de cadastro,
podendo alterá-los caso deseje.

O componente “page-relatorio”, é onde se pode gerar o relatório de um usuário
selecionando o mês e o usuário que deseja gerar o relatório, caso o usuário não seja
administrador ele só poderá gerar o próprio relatório selecionando o mês desejado.
O componente “page-tags”, somente administradores tem acesso, e é onde
pode-se fazer o gerenciamento de tags cadastradas no sistema, como deletar uma tag,
desvincular e vincular com outro usuário.
O componente “page-usuario”, também é um componente que somente
administradores possuem acesso. É o componente responsável por realizar o
gerenciamento do usuários cadastrados como editar informações de um usuário,
deletar, alterá-lo para administrador ou desativá-lo para que ele não consiga ter
acesso ao sistema.
Os componentes “modal-user-edit” e “modal-vincula-tag” são popups que
abrem na tela para realizar alguma tarefa específica.
• Circuito
Nesta seção será apresentado o circuito do protótipo montado, as imagens a
seguir irão mostrar como foram feitas as conexões físicas entre os componentes e a
placa de desenvolvimento ESP32-DevKitC.
Figura 27 – Conexão entre módulo o RC522 e Esp32.
Figura 28 – Conexão do teclado matricial com o microcontrolador.
Figura 29 – Esquemático de ligação do display LCD com o microcontrolador.

De acordo com a Tabela 5 é possível verificar de forma mais objetiva as
conexões entre os pinos da placa de desenvolvimento e os periféricos utilizados. As
colunas nomeadas por “Pinos” representam os pinos da placa de desenvolvimento, e a
as colunas nomeadas por “Atuador” representam os periféricos.
Tabela 5 – Pinos utilizados.
Pinos Atuador Pinos Atuador Pinos Atuador

D15 rele D2 RFID D12 Teclado
SDA col - 1
D4 buzzer D5 RFID D13 Teclado
RST col - 2
RX2 led Green D18 RFID D14 Teclado
SCK col - 3
TX2 led Red D19 RFID D27 Teclado
MISO lin - 1
D21 LCD - SDA D23 RFID D26 Teclado
MOSI lin - 2
D22 LCD - SCL D33 Teclado D25 Teclado
lin - 4 lin - 3
• Resultados
Nesta seção serão apresentados os resultados obtidos após o desenvolvimento
do sistema de controle de acesso, bem como seu funcionamento.
• Sistema Embarcado
Após obter todos os componentes necessários foi feita a montagem do circuito na
protoboard (Figura 30), para a realização dos testes.
Figura 30 – Montagem protótipo.
No desenvolvimento do firmware foram criadas todas as funções que é possível

acessar pelo protótipo, dentre as funções tem-se:
• Opção de Alterar a data;

• Opção de Alterar a hora;
• Opção de Alterar a senha padrão de acesso;
• Opção de Alterar a senha do menu de configuração;
• Opção para se conectar à uma rede Wi-Fi;
• Opção de cadastrar um cartão;
• Opção de remover um cartão;
• Opção de autenticação por login e senha.
Além das funções ativas, as quais o usuário pode acessar pelo teclado, o
sistema também possui algumas funções passivas, que só podem ser alteradas via
firmware, dentre essas funções temos a função que bloqueia o sistema por 25 segundos
caso ocorra 3 erros na tentativa de autenticação, também temos a função em que o
sistema volta para a tela inicial após 1 minuto, caso esteja em alguma outra tela que
não seja a inicial, e não tenha ninguém utilizando o dispositivo.
Para poder acessar as funções ativas mencionadas anteriormente é necessário
que o usuário acesse o menu de configuração do dispositivo. Para ter acesso ao menu
de configuração é necessário que o usuário pressione a tecla ‘#’ na tela inicial. Feito
isso ele será redirecionado para uma tela em que deverá colocar uma senha de 4
dígitos para poder ter acesso ao menu.
A única opção que não é necessário acessar pelo menu é a opção de
autenticação por login e senha. Para utilizar esse método de autenticação é necessário
que o usuário esteja na tela inicial e pressione a tecla ‘*’ por 3 segundos, após esse
tempo o usuário será redirecionado para tela de login (Figura 31) e consequentemente
poderá colocar seu login e senha que foram cadastrados via software web.
Figura 31 – Tela de login.
Ao ligar o dispositivo ele irá exibir no LCD uma mensagem (Figura 32) escrita
“Rochaut” na primeira linha e na segunda linha um número de IP “192.168.4.1”. Isso
significa que para configurar o dispositivo é necessário se conectar à rede Wi-Fi que
ele criou, o nome da rede é “Rochaut”, e para efetuar as configurações necessárias
basta colar o endereço de IP na barra de navegação de um browser, isso pode ser feito
por um computador ou smartphone.
Figura 32 – Tela ao ligar o dispositivo.
Após seguir os passos anteriores será possível conectar o dispositivo a uma

rede Wi-Fi conhecida, as Figuras 33, 34, 35 e 36 mostram como é bem simples realizar
essa configuração.
Fonte: Próprio Autor.
Esses passos são necessário para conectar o dispositivo à uma rede Wi-Fi para
que ele consiga realizar toda troca de informação com o servidor através da internet.
Se tudo foi configurado corretamente o dispositivo será redirecionado para a
tela inicial (Figura 37) com o ícone de wi-fi representando que o dispositivo está
conectado à uma rede wi-fi. Caso nenhuma rede for configurada, o dispositivo após 2
minutos automaticamente é redirecionado para tela inicial, porém, ao invés de um
ícone representando a conexão com uma rede wi-fi será um ícone ‘x’ representando
que não possui conexão com nenhuma rede wi-fi (Figura 38).
Figura 37 – Tela inicial com Wi-Fi conectado.

Figura 38 – Tela inicial sem conexão com
Wi-Fi.
Para as opções de cadastro e remoção de cartões é necessário que o dispositivo

tenha conexão com o servidor, pois todo processo de cadastrar e remover as tags é
feito pelo back-end.
A opção para se conectar a uma rede Wi-Fi é para quando o dispositivo perde
conexão com alguma rede já conhecida. Se a opção for selecionada e ele encontrar a
rede que já havia se conectado anteriormente o processo de conexão ocorre
automaticamente, caso ele não encontre será necessário realizar o processo de conexão
descrito anteriormente.
Toda vez que o dispositivo é ligado ele executa a função de se conectar à uma
rede Wi-Fi, não sendo necessário realizar o processo de conexão toda vez que o
dispositivo reiniciar, e caso ele não encontre a rede, aí sim é necessário realizar o
processo de conexão.
As opções de alterar a data, alterar a hora, alterar a senha padrão de
acesso e alterar a senha do menu de configuração não precisam de conexão com o
servidor, basta selecionar a opção desejada no menu de configuração e realizar o
procedimento.
A Figura 39 representa o fluxograma de funcionamento do sistema embarcado.
Figura 39 – Fluxograma sistema embarcado.
4.1.1 Placa de circuito impresso

Utilizando o software Proteus (Figura 40) foi feito o esquemático da placa de
circuito impresso (Figura 41) para ser confeccionada. Além dos componentes já
citados anteriormente a placa possui uma fonte Hi-Link (Figura 42) que aceita como
tensão de entrada de 100 a 240Vac e tem na saída 5VDC, que é a tensão utilizada para
fazer a alimentação da circuito. A placa também conta com um relé para acionar algum
atuador, que pode ser uma fechadura.
Figura 40 – Software Proteus.

Figura 41 – Esquemático da placa feita no Proteus.
A placa não foi confeccionada, somente o seu esquemático, ficando como

sugestão para trabalhos futuros.
• Software WEB
Figura 42 – Fonte Hi-link.
Fonte:FilipeFlop (2017).
O Software web, possui dois tipos de usuários, os administradores e os

usuários comuns. Os administrados possuem acesso a todas as páginas do sistema
como a página de histórico, cadastro, usuários, relatório, ajuste, tags e perfil.
Na página de histórico (Figura 43) os administrados conseguem ter acesso ao
histórico de acesso de todos os usuários, já os usuários comuns só conseguem
visualizar seu próprio histórico de acesso.
Figura 43 – Página de histórico.
Na página de cadastro (Figura 44) somente os administradores possuem acesso.

Nesta página alguns campos são obrigatórios no preenchimento para realizar o
cadastro, como nome, email, login e senha. Os campos de login e senha serão os dados
utilizados pelo usuário ao se autenticar pelo sistema embarcado na opção de acesso por
login e senha. Esses dois campos necessariamente devem possuir 4 dígitos cada.
Também é possível dar os privilégios de administrador à um usuário ao cadastrá-lo.
Ao efetuar o cadastro de um novo usuário no sistema ele já terá acesso ao software
Figura 44 – Página para cadastrar um novo usuário.

web, basta colocar no campo de email, da página de login, o email cadastrado e no
campo de senha a concatenação dos valores inseridos em login e senha do formulário
de cadastro.
Exemplificando, se um novo usuário for cadastrado com o email,
‘jose@email.com’ e nos campos de login e senha forem colocados os valores ‘1234’ e
‘5678’ respectivamente, basta o usuário entrar na página de login do sistema e
colocar nos campos email e senha os dados ‘jose@email.com’ e ‘12345678’, e clicar
em login. Feito isso ele já terá acesso ao sistema.
A página usuários (Figura 45), também é uma página que somente os

administradores possuem acesso. Nesta página é possível deletar um usuário
cadastrado ou editar os dados de um usuário. Ao clicar na opção para editar um usuário
é aberto um modal na página (Figura 46) para que os dados sejam modificados e
posteriormente atualizados.
Figura 45 – Página que exibe todos os usuários cadastrados.
Figura 46 – Modal para editar um usuário.
Na página relatório (Figura 47), tantos os usuários administradores como os

usuários comuns possuem acesso. Assim como na página de histórico, os
administradores conseguem gerar o relatório de qualquer usuário, e os usuários
comuns podem gerar apenas seu próprio relatório.
Figura 47 – Página para gerar relatório.
Para gerar um relatório, se o usuário for administrador, basta selecionar um

mês desejado e o usuário. Caso seja um usuário comum, basta selecionar o mês
desejado e clicar no botão para gerar relatório.
Ao gerar o relatório um botão de download é exibido na tela, e ao clicá-
lo será feito o download do arquivo no formato de pdf. No relatório (Figura 48) são
exibidas algumas informações como os dados do usuário, o período de referência
daquele relatório, a quantidade de horas cumprida durante o período de referência e
um resumo contendo o dia, o horário de entrada e saída e a quantidade de horas
cumpridas em cada dia do mês.
Em relação ao horário de entrada e saída, é exibido somente o horário em que
o usuário bateu o ponto a primeira vez e o horário que o usuário bateu o ponto pela
última vez durante aquele dia, sendo possível bater o ponto quantas vezes for
necessário durante um dia. O cálculo de horas cumprida no dia é em relação aos
intervalos em que os pontos foram batidos e não em relação ao primeiro e o último
horário.
A página de ajuste (Figura 49), todos os usuários possuem acesso, é a página
onde deve ser feito o ajuste de ponto, caso necessário. Os usuários comuns só podem
fazer a solicitação de ajuste e verificar seu próprio histórico de ajuste. Já os
administradores, são responsáveis por aceitar ou recusar uma solicitação de ajuste, e
também tem acesso ao histórico de ajuste de todos os usuários.
Para realizar uma solicitação é necessário preencher o formulário com os
dados do dia e horário em que gostaria de realizar o ajuste de ponto e uma justificativa
resumida informando o motivo de tal ajuste.
Na página de tags (Figura 50), somente os administradores possuem acesso.
Nesta página é possível gerenciar todos os cartões cadastrados no sistema, sendo
possível desvin-
Figura 48 – Exemplo de relatório.
Figura 49 – Página de ajuste de ponto.
cular um cartão de um usuário e vincular com algum outro usuário ou apagar um

cartão do sistema. Também é possível verificar se a tag está ativada, ou seja, se o
cartão está habilitado para funcionar.
Figura 50 – Página de gerenciamento de tags.

Por último, tem-se a página de perfil do usuário (Figura 51), onde todos
possuem acesso. Esta página permite que os usuários editem algumas informações
pessoais, e nela também é exibida as tags do usuário e se estão ativas. A diferença
entre usuários administradores e usuários comuns em relação a esta página, é que os
administradores conseguem visualizar o código do token que é necessário colocar no
firmware do projeto para que as trocas de informações entre sistema embarcado e
back-end funcionem corretamente.
• Arquitetura do Sistema
A Figura 52 representa toda arquitetura do sistema, o Amazon EC2 representa
o servidor utilizado, com suas especificações de hardware e sistema operacional
utilizado.
O Apache e MySQL são os softwares instalados no sistema. A representação por
Back-end e Front-end são pastas onde se encontra o código fonte de cada parte da
aplicação.
O Apache é responsável por direcionar o caminho correto quando é acessado o

link http://meusite.com.br HYPERLINK "http://meusite.com.br/" ou o link
http://api-meusite.com.br.
Os end-points são as rotas utilizadas na aplicação, a API do sistema possui
tanto as rotas utilizadas no software WEB como as rotas utilizadas pelo sistema
embarcado.
Figura 51 – Página de perfil do usuário.
Figura 52 – Arquitetura do sistema.

• Segurança
Para demonstrar os resultados em relação a segurança foi feito o estudo de
caso (Figura 53) ao efetuar o Login na página WEB, simplesmente colocando o email
e a senha nos campos de entrada e pressionando o botão entrar.
Figura 53 – Estudo de caso.
Para analisar os dados que são enviados ao back-end, ao efetuar o login, e

os dados que são retornados ao front-end, foi utilizado o software Wireshark
(Figura 54).
Com o software Wireshark é possível analisar toda troca de informação que
ocorre entre seu computador e a internet.
Foram feitas duas análises ao efetuar o login, a primeira utilizando “http” na
frente do link, e a segunda utilizando “https”. A parte representada por Request são os
dados que foram enviados ao back-end e a parte representada por Response são os
dados que foram retornados ao front-end.
A Figura 55 representa a request feita utilizando “http”, como é possível
analisar, todos os dados de login e senha enviados ao back-end estão completamente
legíveis, sem nenhuma segurança ao efetuar essa troca de dados.
A Figura 56 representa o response utilizando “http”, e como é possível analisar,
todos os dados que retornam do back-end ao front-end ao efetuar o login também
es- tão completamente legíveis, podendo ter acesso diretos ao token de acesso e
algumas informações do usuário que efetuou o login.
Figura 54 – Software Wireshark.

Figura 55 – Request HTTP.
Figura 56 – Response HTTP.
Já as Figuras 57 e 58, representam a request e o response respectivamente

utilizado “https”. Como é possível analisar, tanto os dados que são enviados ao
back-end quanto os dados que são retornados ao front-end estão criptografados, não
permitindo que esses dados sejam facilmente analisados. O que garante segurança
para a aplicação.
Todo o sistema está configurado para aceitar somente requisições com “https”,
caso o usuário force uma requisição com “http” ele será redirecionado para “https”.
Figura 57 – Request HTTPS.
Figura 58 – Response HTTPS.
• Conclusão
Este trabalho apresentou um sistema de controle de acesso para ser
implementado nos laboratórios da Escola de Minas, mas que também pode ser
implementado em locais que haja a necessidade do controle de ponto de seus
colaboradores.
O sistema constitui-se de uma aplicação WEB que fica on-line 24h por dia,
hos- pedado em uma máquina virtual nos servidores da Amazon. A partir da
aplicação WEB é possível gerenciar todos os usuários cadastrados no sistema, e obter
relatórios mensais com a carga horária cumprida por seus colaboradores.
Para autenticação de um usuário no sistema foi desenvolvido o protótipo de um
sistema embarcado que tem como métodos de autenticação cartões RFID e teclado
matricial.
Foi apresentada toda a base teórica utilizada para poder concretizar as
propostas oferecidas, demonstrando como foi implementada passo a passo, mostrando
que todos os objetivos propostos foram cumpridos.
Diante do trabalho presente e de acordo com os resultados apresentados, o
projeto tem total viabilidade de ser implementado, sendo uma boa solução para
automatizar serviços para controle de acesso.
• Sugestões para trabalho futuros

Para trabalhos futuros complementando o que já foi apresentado sugere-se:
• Confeccionar a Placa de Circuito Impresso (PCI), um vez que o circuito já

está pronto;
• Colocar mais uma forma de autenticação utilizando sensor de leitura biométrica;
• Modificação do sistema para permitir controle de acesso de múltiplas salas,

cada uma com seu grupo de usuário.
Referências
AFONSO, A. O que é Angular? 2018. Disponível em: <https://blog.algaworks.com/o-
que- e-angular/>. Acesso em: 07 set. 2019. Citado na página 35.
AMAZON. Amazon Elastic Compute Cloud. 2019. Disponível em: <https://docs.aws-
.amazon.com/pt br/AWSEC2/latest/UserGuide/concepts.html>. Acesso em: 11 jan.
2019. Citado na página 35.
ANDREI. O que é Apache? Uma visão aprofundada do servidor Apache. 2019.
Disponível em: <https://www.hostinger.com.br/tutoriais/o-que-e-apache>. Acesso em:
07 set. 2019. Citado na página 36.
BARBACENA, I. L.; FLEURY, C. A. DISPLAY LCD. [S.l.: s.n.], 1996. Citado 2 vezes
nas páginas 29 e 30.
BARROS, E.; CAVALCANTE, S. Introdução aos sistemas embarcados. Artigo
apresentado na Universidade Federal de Pernambuco-UFPE, 2010. p. 36, 2010.
Citado na página 17.
BRINGING. Bringing MySQL to the web. 2019. Disponível em: <https://www-
.phpmyadmin.net/>. Acesso em: 09 jan. 2019. Citado na página 33.
CANALTECH. O que é servidor Apache? - Internet. 2019. Disponível em: <https:/-
/canaltech.com.br/internet/O-que-e-servidor-Apache/>. Acesso em: 07 set. 2019.
Citado na página 36.
CARDOSO, R. L. d. B. S. Desenvolvimento de soluções para acionamento eletrónico
de fechaduras"keyless": Rfid, keypad e biométrico. 2014. 2014. Citado na página 14.
CARRO, L.; WAGNER, F. R. Sistemas computacionais embarcados. Jornadas de
atualização em informática. Campinas: UNICAMP, 2003. 2003. Citado na página 14.
CHASE, O.; ALMEIDA, F. Sistemas embarcados. Mídia Eletrônica. Página na
internet:< www. HYPERLINK "http://www/" sbajovem. org/chase>, capturado
em, 2007. v. 10, n. 11, p. 13, 2007. Citado na
página 17.
CUNHA, A. RFID – Etiquetas com eletrônica de ponta. 2016. Disponível em:
<https://www.embarcados.com.br/rfid-etiquetas-com-eletronica-de-ponta/>. Acesso
em: 31 mai. 2018. Citado 2 vezes nas páginas 20 e 21.
CUNHA, A. F. O que são sistemas embarcados. Saber Eletrônica, 2007. v. 43, n. 414,
p. 1–6, 2007. Citado na página 17.
CURVELLO, A. Apresentando o módulo ESP8266. 2015. Disponível em: <https://www-
.embarcados.com.br/modulo-esp8266/>. Acesso em: 6 jun. 2018. Citado 2
vezes nas páginas 18 e 19.
ELETRONICA.ORG. 2019. Disponível em: < HYPERLINK
"http://www.eletronica.org/arq_apostilas/2/lcd_codigos.pdf"http://www.eletronica.org/arq
HYPERLINK "http://www.eletronica.org/arq_apostilas/2/lcd_codigos.pdf" HYPERLINK
"http://www.eletronica.org/arq_apostilas/2/lcd_codigos.pdf"apostilas-
/2/lcd HYPERLINK "http://www.eletronica.org/arq_apostilas/2/lcd_codigos.pdf"
HYPERLINK "http://www.eletronica.org/arq_apostilas/2/lcd_codigos.pdf"codigos.pdf
HYPERLINK "http://www.eletronica.org/arq_apostilas/2/lcd_codigos.pdf">.
Acesso em: 10 jan. 2019. Citado 2 vezes nas páginas 30
e 32.
FERNANDES, A. O que é API? Entenda de uma maneira simples. 2018. Disponível em:
<https://vertigo.com.br/o-que-e-api-entenda-de-uma-maneira-simples/>. Acesso em:
05 set. 2019. Citado na página 34.
FILIPEFLOP. 2017. Disponível em: <https://uploads.filipeflop.com/2017/10-
/mini-fonte-hi-link-hlk-pm01-100240vac-para-5vdc-600ma-D NQ NP 239021-
MLB20683079715 042016-F.jpg>. Acesso em: 04 set. 2019. Citado na
página 54.
FILIPEFLOP. Como usar o Teclado Matricial 4x4 com Arduino - FilipeFlop. 2019.
Disponível em: <https://www.filipeflop.com/blog/teclado-matricial-4x4-arduino/>.
Acesso em: 03 set. 2019. Citado 2 vezes nas páginas 28 e 31.
FINKENZELLER, K. RFID handbook: fundamentals and applications in contactless
smart cards, radio frequency identification and near-field communication. [S.l.]: John
Wiley & Sons, 2010. Citado na página 14.
FREERTOS. About FreeRTOS. 2018. Disponível em: <https://www.freertos.org/RTOS-
.html>. Acesso em: 11 jan. 2019. Citado na página 37.
GU CLAIRE E YEH, P. Liquid crystal display (lcd). Handbook of Digital Imaging,
2015. Wiley Online Library, 2015. Citado na página 29.
HEUSER, C. A. Projeto de banco de dados: Volume 4 da Série Livros didáticos
informática UFRGS. [S.l.]: Bookman Editora, 2009. Citado na página 32.
HIRAKAWA, A.; CUGNASCA, C. E.; CUGNASCA, C. E. Experiência 4: Interface
com teclado e display. Escola Politécnica da USP, Departamento de Engenharia de
Computação e Sistemas Digitais, 2007. 2007. Citado na página 27.
LEENS, F. An introduction to i 2 c and spi protocols. IEEE Instrumentation &
Measurement Magazine, 2009. IEEE, v. 12, n. 1, p. 8–13, 2009. Citado na página
26.
LEONARDO. Artigo: API, Framework ou Biblioteca - Gigasystems. 2015. Disponível em:
<https://www.gigasystems.com.br/artigo/94/api-framework-ou-biblioteca>. Acesso
em: 05 set. 2019. Citado na página 34.
LIVRE, M. Display Lcd 16x2 - Backlight Azul - Escrita Branca - R$ 21,99 em
Mercado Livre. 2019. Disponível em: <https://produto.mercadolivre.com.br/MLB-
798503579- display-lcd-16x2-backlight-azul-escrita-branca- JM>. Acesso em: 04 set.
OLIVEIRA, S. D. Internet das Coisas com ESP8266, Arduino e Raspberry Pi. [S.l.]:
Novatec Editora, 2017. Citado 2 vezes nas páginas 17 e 18.
ORACLE. MySQL | O Banco de Dados de Código Aberto Mais Popular | Oracle
Brasil. 2019. Disponível em: <https://www.oracle.com/br/mysql/>. Acesso em: 02 set.
RFIDHY. 2016. Disponível em: < HYPERLINK
"http://www.rfidhy.com/wp-content/uploads/2016/05/RFID-Contactless-card_08.jpg"http://
www.rfidhy.com/wp-content/uploads/2016-
/05/RFID-Contactless-card HYPERLINK
"http://www.rfidhy.com/wp-content/uploads/2016/05/RFID-Contactless-card_08.jpg"
HYPERLINK "http://www.rfidhy.com/wp-content/uploads/2016/05/RFID-
Contactless-card_08.jpg"08.jpg HYPERLINK
"http://www.rfidhy.com/wp-content/uploads/2016/05/RFID-
Contactless-card_08.jpg">. Acesso em: 03 set. 2019. Citado na
página 22.
SACCO, F. Comunicação SPI – Parte 1. 2014. Disponível em: <https://www.embarcados-

.com.br/spi-parte-1/>. Acesso em: 8 jan. 2019. Citado 3 vezes nas páginas 23, 24
e 25.
SAUVE, J. P. O que é um framework? 200–. Disponível em: < HYPERLINK
"http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/oque.htm"http://
www.dsc.ufcg.edu-
.br/˜jacques/cursos/map/html/frame/oque.htm HYPERLINK
"http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/oqu
e.htm">. Acesso em: 05 set. 2019. Citado na página 34.
SILBERSCHATZ, A.; SUNDARSHAN, S.; KORTH, H. F. Sistema de banco de
dados. [S.l.]: Elsevier Brasil, 2016. Citado na página 32.
SILíCIO, V. de. Tag Chaveiro RFID 13.56MHz | Vida de Silício. 2019. Disponível em:
<https://www.vidadesilicio.com.br/quickview/index/view/id/276>. Acesso em: 03 set.
WANT, R. An introduction to rfid technology. IEEE pervasive computing, 2006. IEEE,
v. 5, n. 1, p. 25–33, 2006. Citado 2 vezes nas páginas 20 e 21.

TCCSENAI

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCCSENAI

Enviado por

Direitos autorais:

Formatos disponíveis

Gabriel Galli Brandini

Letícia Mendes de Souza

Sistema de controle de acesso utilizando autenticação por RFID e

São Carlos, 2022

Gabriel Galli Brandini

Sistema de controle de acesso utilizando autenticação por RFID e

Orientador: André Roberto da Silva

São Carlos, 2022

A realização de uma determinada tarefa com rapidez e confiabilidade são

Palavras-chaves: controle de acesso; segurança e software WEB.

Performing a given task quickly and reliably is a characteristic of the modern

Key-words: access control; security and WEB software.

Display LCD 16x2 conexão 4bits. . . . . . . . . . . . . . . . . . . . . . 30

Editor de texto Atom. . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Lista dee abreviaturas

RFID Radio Frequency Identification

IoT Internet of Things

API Application Programming Interface

HTTP HyperText Transfer Protocol

IHM Interface Homem Máquina

LCD Liquid Crystal Display

SPI Serial Peripheral Interface

SDA Serial Data

SCL Serial Clock

DAC Digital-to-Analog Converter

ADC Analog-to-Digital Converter

GPIO General Purpose Input/Output

RTOS Real Time Operating System

HTML Hypertext Markup Language

CSS Cascading Style Sheets

Sempre foi problema da sociedade a necessidade de ter segurança no meio em

• Desenvolver um sistema embarcado do tipo fechadura eletrônica com integração

• Desenvolver o front-end da aplicação utilizando o framework Angular;

• Modelar o banco de dados utilizando o MySQL para armazenar informações

apresentados os resultados obtidos e uma descrição de seu funcionamento. No capítulo

• Funcionalidade única: usualmente um sistema embarcado executa somente um programa

Um sistema embarcado pode ter diversos tipos de aplicações, desde controle

2.1.1 Placa de desenvolvimento ESP32-DevKitC

Desde que começou a popularização da internet já se pensava em formas de

Figura 1 – Pinagem do ESP32.

O ESP32 é uma versão evoluída do ESP8266, tendo mais poder de

CAN (Controller Area Network), Ethernet, DAC (Digital-to-Analog Converter) e

Dual-Core 32-bits LX6;

• ROM: 448 KBytes;

• RAM: 520 Kbytes;

• Clock máximo: 240MHz;

• Portas GPIO: 25;

• GPIO com funções de PWM, I2C, SPI, etc.;

• Tensão de operação: 4,5 9V;

• Conversor analógico digital (ADC) 12-bits.

Figura 2 – Troca de informação entre antena e tag RFID.

Fonte: Cunha (2016).

A faixa de operação de frequência das tags irá determinar uma distância

Figura 3 – (a)pequeno frasco de vidro (b) plastico laminar.

Fonte: WANT (2006).

Fonte: Cunha (2016).

2.2.1 Módulo RC522

Figura 5 – Leitor RFID.

Figura 6 – Conexão entre módulo o RC522 e Esp32.

Fonte: Próprio autor.

Figura 7 – Estrutura de um cartão RFID.

Fonte: RFIDHY (2016).

Figura 8 – Chaveiro RFID.