de cada um dos sistemas diferenciando a qualidade de servi¸co (QoS) com e sem criptografia da mensagem enviada. Na Se¸c˜ao 4.1 e Se¸c˜ao 2.4 foram abordadas as quest˜oes da seguran¸ca e criptografia do sistema.
Para a realiza¸c˜ao dos testes foram utilizados os seguintes recursos:
• Plataforma mobile: envio da mensagem;
• Raspberry Pi: recebimento da mensagem;
• Banda larga: 15 Mbps de download e 1.5 Mbps de upload;
• Broker IP: test.mosquitto.org.
A implementa¸c˜ao da comunica¸c˜ao com o protocolo MQTT ocorreu com diferentes n´ıveis de QoS, variando de acordo com a necessidade de cada local que era utilizado. Para ilustrar, na tela de monitoramento (Figura 44) existem 4 op¸c˜oes de envio de mensagem com diferentes n´ıveis de QoS como publisher. As op¸c˜oes nestes casos s˜ao para movimentar os eixos x e y com QoS 0 e para gravar v´ıdeo ou capturar fotos foram utilizados QoS 1. No caso de subscriber, para o recebimento nos eixos X e Y foram mantidos os n´ıveis de QoS, por´em para inicializar a grava¸c˜ao ou capturar foto foram utilizados QoS 2 para as duas funcionalidades, com o objetivo de receber apenas uma vez os dados.
Figura 44 – Tela de Monitoramento
Fonte: Autoria Pr´opria
O processo de obten¸c˜ao do tempo de envio de dados de cada um dos n´ıveis de QoS foi realizado da seguinte maneira: quando a mensagem est´a pronta pra ser enviada, gera-se um timestamp com o tempo atual do envio, o qual ´e criptografado quando h´a necessidade. Esse timestamp ´e enviado como mensagem para a Raspberry Pi (sendo criptografado, ´e necess´ario antes passar pela etapa de descriptografia). Ap´os isso, gera-se um novo timestamp e, com esses dois timestamps, ´e realizada a diferen¸ca de tempo entre eles para determinar o tempo total do processo. O estudo foi realizado com as mensagens criptografadas e normais, com 30 medi¸c˜oes em cada um dos casos, ou seja, para publisher com QoS 0 e o subscriber com QoS 0 foram realizadas 30 medi¸c˜oes; com QoS 1 foram realizadas mais 30 medi¸c˜oes; e assim por diante. Os dados resultados foram usados na an´alise.
Os gr´aficos representados nas Figuras 45, 46 e 47 s˜ao do tempo resposta para cada
um poss´ıveis dos casos. Neles ´e poss´ıvel observar que a criptografia aumenta o tempo m´edio e o desvio padr˜ao, por´em n˜ao ´e um fator que compromete o desempenho, pois s˜ao valores muito similares. Tamb´em ´e poss´ıvel notar que com o aumento do QoS h´a um acr´escimo no tempo de transmiss˜ao, que ´e bem percept´ıvel se comparados os resultados obtidos. Na Figura 47 os valores de respostas ficam entre 1900 ms at´e 2900 ms no caso com criptografia, enquanto nas Figuras 45 e 46, os valores ficam abaixo de 1300 ms.
Portanto, para o sistema criptografado foi obtido um resultado vi´avel para os dois casos:
para a quest˜ao da movimenta¸c˜ao dos servomotores nos eixos com um atraso de aproximadamente
1051±89 ms, onde foi utilizado o n´ıvel de QoS 0 para o envio e QoS 1 para a recep¸c˜ao, que
pode ser observado na Figura 45 (a) na coluna do QOS 1. Para a grava¸c˜ao de v´ıdeos e captura de fotos foi obtido um atraso de aproximadamente 1157±119 ms, demonstrando ser um sistema robusto para a comunica¸c˜ao. Neste ´ultimo caso foi utilizado o n´ıvel de QoS 1 para o envio e QoS 2 para a recep¸c˜ao, que pode ser observado na Figura 46 (a) na coluna do QOS 2.
Figura 45 – Android QOS 0
7HPSRPV
Figura 46 – Android QOS 1
Figura 47 – Android QOS 2
7HPSRPV
5 CONCLUS˜AO
O objetivo deste trabalho foi desenvolver um sistema de seguran¸ca com reconhecimento facial capaz de ter conectividade com plataformas de dispositivos m´ovel e navegador webpara o controle e acesso do sistema. Outro aspecto relevante ´e a robustez e confiabilidade nas quest˜oes de reconhecimento facial e na seguran¸ca das informa¸c˜oes transmitidas e armazenadas. O projeto apresentou algumas dificuldades no decorrer do seu desenvolvimento, que foram superadas com novas pesquisas e mudan¸cas de estrat´egias no entendimento do funcionamento das tecnologias utilizadas. Apesar disso, todos os objetivos citados na introdu¸c˜ao deste documento foram alcan¸cados com sucesso, o trabalho teve uma dura¸c˜ao de aproximadamente um ano e dois meses.
As tecnologias mais importantes utilizadas no trabalho foram o protocolo de comuni-ca¸c˜ao MQTT, o banco de dados Firebase, o microprocessador Raspberry Pi e o algoritmo de reconhecimento facial. O protocolo MQTT se demonstrou s´olido para a aplica¸c˜ao desenvolvida com a sua leveza e robustez para transmiss˜ao dos dados, por conta da caracter´ıstica de QOS para enviar e receber a mensagem. Tamb´em apresentou um baixo tempo de resposta apesar da utiliza¸c˜ao de um Broker distante e n˜ao particular.
O Firebase tamb´em se demonstrou uma excelente ferramenta para desenvolvimento das plataformas, devido `a boa documenta¸c˜ao que a empresa fornece e `as diversas ferramentas que s˜ao disponibilizadas para o desenvolvimento. Tamb´em apresenta uma boa seguran¸ca no quesito dos dados de seus usu´arios. A Raspberry Pi ´e uma plataforma vers´atil com o seu sistema operacional baseado em Linux, sendo capaz de comportar diversas tecnologias baseadas na linguagem Python. Para o reconhecimento facial foi utilizada uma biblioteca do OpenCV capaz de realizar o reconhecimento de maneira ´agil e eficiente.
No produto final foi obtido um excelente resultado utilizando a Raspberry Pi, a cˆamera, as plataformas e o protocolos de comunica¸c˜ao. ´E poss´ıvel detectar os rostos com facilidade utilizando reconhecimento facial por conta da escolha da biblioteca com um melhor desempenho, de aplica¸c˜oes com f´acil manuseio para o usu´ario que, apesar de n˜ao apresentaram um design bonito, conseguem ter interfaces bem intuitivas. Outro aspecto interessante no produto final foi o tempo de respostas para os comandos quando realizados pelas plataformas, o que demonstra a confiabilidade do produto. Al´em disso, ´e poss´ıvel implementar novas melhorias para continua¸c˜ao do projeto, como ser´a apresentado na Se¸c˜ao 5.2.