id mobile - sistema de identificación personal para

CARRERA DE ESPECIALIZACIÓN ENINTERNET DE LAS COSAS

MEMORIA DEL TRABAJO FINAL

ID Mobile - Sistema de identificaciónpersonal para teléfono móvil, mediante

Bluetooth

Autor:Ing. Pedro Rosito

Director:Esp. Ing. Nelson Fortunatti

Jurados:Esp. Ing. Santiago Salamandri (FIUBA)

Mg. Lic. Leopoldo Zimperz (FIUBA)Mg. Ing. Rodrigo Tirapegui (FIUBA)

Este trabajo fue realizado en la ciudad de La Plata,entre agosto de 2020 y diciembre de 2021.

I

Resumen

En la presente memoria se describe la implementación de un sistema de controlde acceso basado en tecnología Bluetooth que es controlado mediante el uso de

un celular. Este sistema fue desarrollado para la empresa SURIX S.R.L.Para la elaboración de este trabajo se realizaron una aplicación híbrida para

Android como frontend, una API REST como backend, una base de datos SQL yun portero inteligente como actuador físico. A su vez se trabajó en la

intercomunicación entre los distintos subsistemas mencionados y en lasecurización de la misma.

En el desarrollo de este trabajo se aplicaron conocimientos referentes al diseñode aplicaciones multiplataforma, diseño de API REST, ciberseguridad,

arquitectura de datos y arquitectura de protocolos.

III

Agradecimientos

Agradezco a mi familia y amigos, en especial a mis padres, Gustavo y Ana, poracompañarme a lo largo de mi carrera universitaria y ahora durante la especia-lización. Y agradezco también de una forma especial a mí novia, Emilia, por serconstante apoyo en cada nuevo desafío.

V

Índice general

Resumen I

1. Introducción general 11.1. Introducción a la Domótica . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Cerraduras inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.1. Productos similares . . . . . . . . . . . . . . . . . . . . . . . . 31.4. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5. Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.6. Especificaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.6.1. Mínimo producto viable . . . . . . . . . . . . . . . . . . . . . 51.6.2. Producto completo . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Introducción específica 72.1. Protocolos de comunicación utilizados . . . . . . . . . . . . . . . . . 7

2.1.1. Descripción del protocolo HTTP . . . . . . . . . . . . . . . . 7Características del protocolo HTTP . . . . . . . . . . . . . . . 8

2.1.2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . 82.2. Tecnologías del backend . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1. Arquitectura REST . . . . . . . . . . . . . . . . . . . . . . . . 9Ventajas del desarrollo basado en REST . . . . . . . . . . . . 10

2.2.2. Lenguaje PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3. Tecnologías del frontend . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1. Aplicación híbrida . . . . . . . . . . . . . . . . . . . . . . . . 11Funcionamiento de las aplicaciones híbridas . . . . . . . . . 11

2.4. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.1. Ionic Framework . . . . . . . . . . . . . . . . . . . . . . . . . 12

Características de Ionic Framework . . . . . . . . . . . . . . 12Entorno de ejecución nativo Capacitor . . . . . . . . . . . . . 12

2.4.2. Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.3. Servidor Apache . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.4. Placa de desarrollo basada en chip nRF52832 . . . . . . . . . 142.4.5. SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Características . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Programación . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3. Diseño e implementación 173.1. Descripción del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1. Funcionalidades generales . . . . . . . . . . . . . . . . . . . . 173.1.2. Comunicación de apertura . . . . . . . . . . . . . . . . . . . 183.1.3. Comunicación backend . . . . . . . . . . . . . . . . . . . . . 18

3.2. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 19

VI

3.2.1. Capa de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.2. Capa de Aplicación . . . . . . . . . . . . . . . . . . . . . . . . 203.2.3. Capa de Procesamiento . . . . . . . . . . . . . . . . . . . . . 203.2.4. Capa de Transporte . . . . . . . . . . . . . . . . . . . . . . . . 203.2.5. Capa de Percepción . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3. Arquitectura de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.1. Programación . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4. Desarrollo de la API REST . . . . . . . . . . . . . . . . . . . . . . . . 243.4.1. Estructura de archivos . . . . . . . . . . . . . . . . . . . . . . 24

Conexión a la base de datos . . . . . . . . . . . . . . . . . . . 24Tratamiento de las peticiones . . . . . . . . . . . . . . . . . . 25

3.5. Desarrollo de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . 273.5.1. Estructura de archivos . . . . . . . . . . . . . . . . . . . . . . 27

Páginas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Modales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5.2. Implementación de la estructura . . . . . . . . . . . . . . . . 29Páginas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Modales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.6. Desarrollo del firmware . . . . . . . . . . . . . . . . . . . . . . . . . 313.7. Ciberseguridad del sistema . . . . . . . . . . . . . . . . . . . . . . . 31

3.7.1. Seguridad HTTP . . . . . . . . . . . . . . . . . . . . . . . . . 313.7.2. Seguridad BLE . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4. Ensayos y resultados 354.1. Banco de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2. Ensayos sobre el firmware . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.1. Ensayos sobre la API . . . . . . . . . . . . . . . . . . . . . . . 374.3. Ensayos sobre el sistema y resultados obtenidos . . . . . . . . . . . 384.4. Comparación con otras cerraduras inteligentes . . . . . . . . . . . . 42

5. Conclusiones 455.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.1. Cumplimiento de las especificaciones . . . . . . . . . . . . . 455.1.2. Cumplimiento de la planificación . . . . . . . . . . . . . . . 45

Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.3. Recursos utilizados . . . . . . . . . . . . . . . . . . . . . . . . 465.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Bibliografía 47

VII

Índice de figuras

1.1. Cerradura inteligente. . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1. Comunicación HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2. Comunicación BLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3. Comparativa entre aplicaciones. . . . . . . . . . . . . . . . . . . . . 112.4. Capacitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5. Placa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1. Diagrama en bloques del sistema. . . . . . . . . . . . . . . . . . . . . 183.2. Scan Bluetooth y detección de cerradura. . . . . . . . . . . . . . . . . 193.3. Modelo IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4. Diagrama UML de la base de datos. . . . . . . . . . . . . . . . . . . 223.5. Proceso de atención de una petición. . . . . . . . . . . . . . . . . . . 253.6. Archivos de una página en Ionic. . . . . . . . . . . . . . . . . . . . . 283.7. Aplicación separada en componentes. . . . . . . . . . . . . . . . . . 293.8. Obtención de JWT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.9. Handshake para autenticación BLE. . . . . . . . . . . . . . . . . . . . 32

4.1. Banco de pruebas para el firmware. . . . . . . . . . . . . . . . . . . . 354.2. Aplicación nRF Connect. . . . . . . . . . . . . . . . . . . . . . . . . . 364.3. Batería de tests en Postman. . . . . . . . . . . . . . . . . . . . . . . . 374.4. Captura de la consola de Android Studio. . . . . . . . . . . . . . . . 384.5. Pantallas de inicio, login y registro. . . . . . . . . . . . . . . . . . . . 384.6. Pantallas de menú, administración de cerraduras y gestión de per-

misos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.7. Pantalla de asignación de permisos irrestrictos. . . . . . . . . . . . . 394.8. Pantalla de asignación de permisos restringidos por día y horario. . 404.9. Pantalla de asignación de permisos de única vez. . . . . . . . . . . . 404.10. Pantalla de generación de reportes. . . . . . . . . . . . . . . . . . . . 414.11. Reportes generados. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

IX

Índice de tablas

1.1. Comparativa entre productos nacionales. . . . . . . . . . . . . . . . 4

4.1. Comparativa de sistemas . . . . . . . . . . . . . . . . . . . . . . . . . 424.2. Comparativa entre productos nacionales. . . . . . . . . . . . . . . . 43

1

Capítulo 1

Introducción general

En este capítulo se presentan los conceptos de domótica y cerradura inteligentecomo marco que da lugar al desarrollo del presente trabajo. Luego se introduce elestado del arte y finalmente se presentan la motivación, los objetivos y el alcancedel trabajo.

1.1. Introducción a la Domótica

La domótica es el conjunto de tecnologías aplicadas al control y la automatizacióninteligente de la vivienda, que permite una gestión eficiente del uso de la energía,que aporta seguridad y confort, además de comunicación entre el usuario y elsistema.La domótica permite dar respuesta a los requerimientos que plantean las nuevastendencias en la forma de vida, facilitando el diseño de casas y hogares más hu-manos, más personales, polifuncionales y flexibles.El sector de la domótica ha evolucionado considerablemente en los últimos años,y en la actualidad ofrece una oferta más consolidada. Hoy en día, la domóticaaporta soluciones dirigidas a todo tipo de viviendas [1].

1.1.1. Aplicaciones

Entre las aplicaciones que podemos encontrar en el ámbito de la domótica sedestacan las siguientes [2]:

Programación y ahorro energético: el ahorro energético no es algo tangible,sino legible con un concepto al que se puede llegar de muchas maneras.En muchos casos no es necesario sustituir los aparatos o sistemas del ho-gar por otros que consuman menos energía sino una gestión eficiente delos mismos. Ejemplos: programación de climatización, control de toldos ypersianas eléctricas, gestión eléctrica, etc.

Confort: el confort conlleva todas las actuaciones que se puedan llevar a ca-bo para mejorar la comodidad en una vivienda. Dichas actuaciones puedenser de carácter tanto pasivo, como activo o mixtas. Ejemplos: iluminación,control de porteros con el celular, cerraduras inteligentes, gestión multime-dia y del ocio electrónicos.

Seguridad: consiste en una red de seguridad encargada de proteger tantolos bienes patrimoniales, como la seguridad personal y la vida. Ejemplos:alarmas de intrusión, detectores de incendios, alerta médica y cámaras.

2 Capítulo 1. Introducción general

Comunicaciones: son los sistemas o infraestructuras de comunicaciones queposee el hogar. Ejemplos: teleasistencia y transmisión de alarmas.

Accesibilidad: bajo este mecanismo se incluyen las aplicaciones o instala-ciones de control remoto del entorno que favorecen la autonomía personalde personas con limitaciones funcionales o discapacidad.

El presente trabajo puede encuadrarse entre las aplicaciones de confort, seguri-dad y accesibilidad.

1.2. Cerraduras inteligentes

Una cerradura inteligente o smart look reemplaza a la cerradura tradicional, per-mitiendo su activación o desactivación a través de un dispositivo, sin la necesidadde utilizar una llave. De esta forma, el sistema de apertura o cierre pasa a ser au-tomático.Existen diversos tipos de cerraduras inteligentes, teniendo en cuenta su estética ymedios de apertura o cierre.A continuación se enumeran los dos tipos de sistemas de instalación de cerradu-ras inteligentes más comunmente utilizados:

Sistema de instalación de cerradura inteligente sustitutivo: como su deno-minación lo señala, este sistema reemplaza totalmente a la cerradura tra-dicional de la puerta. La instalación de esta cerradura inteligente suponecambios físicos en la puerta.

Sistema de instalación de cerradura inteligente complementario: no es nece-sario realizar grandes cambios en la puerta ya que la instalación de la cerra-dura inteligente se realiza sobre la existente. Este tipo de smart lock permitemonitorear solamente la apertura de la puerta.

En la figura 1.1 se puede observar una cerradura inteligente de tipo sustitutivo.

FIGURA 1.1. Cerradura inteligente.1

1Imágen tomada de: herramientas10.top

https://herramientas10.top/imagenes/las-8-mejores-cerraduras-inteligentes-1024x634.jpg

1.3. Estado del arte 3

Existen diferentes tipos de tecnologías utilizadas para la apertura de cerradurasinteligentes, algunas de ellas son:

Biométrico [3]: mediante una huella dactilar o detección de rostro.

Código de seguridad.

RFID [4]: identificación por radiofrecuencia.

WiFi [5] o Bluetooth [6]: cerraduras inteligentes conectadas al smartphonepor WiFi o Bluetooth. Estas son las más solicitadas por los usuarios, debidoa su facilidad de uso y a la incorporación de cámaras.

1.3. Estado del arte

Si bien en el mercado actual se ofrece una gran variedad de cerraduras inteligen-tes, en su gran mayoría las soluciones encontradas solamente permiten la aper-tura de una cerradura por un medio distinto al uso de una llave metálica. Tal esel caso de los sistemas de apertura que no utilizan las capacidades de un celular.Por ejemplo, podemos encontrar:

Los sistemas de apertura que utilizan tarjeta magnética.

Los sistemas que utilizan tecnologías biométricas como la detección de lahuella dactilar.

Los sistemas que permiten el ingreso de un código de seguridad por tecla-do.

Este tipo de sistemas permite el acceso sin llave, pero por lo general no incluye lacapacidad de gestionar el ingreso, mediante la emisión de permisos, del usuarioque lo utiliza.En Argentina se pueden encontrar diferentes empresas que se dedican al desa-rrollo de cerraduras de este tipo. Por ejemplo:

Teknohomes [7].

Cittyo [8].

PSLocks [9].

Siccba [10]

Gran parte de los productos desarrollados no ofrecen la opción de realizar unagestión de ingresos avanzada, como permitir la entrega de llaves virtuales a losusuarios, mantener registros de acceso o entregar permisos de ingreso en rangoshorarios determinados.Por otro lado, entre los sistemas que utilizan un celular, también se encuentrandiferencias en las tecnologías utilizadas para realizar la comunicación entre elcelular y la cerradura inteligente. En particular, muy pocos sistemas utilizan latecnología BLE (Bluetooth Low Energy).

1.3.1. Productos similares

Entre los productos nacionales que utilizan el celular como llave, es posible en-contrar sistemas que realizan la comunicación con el portero a través del uso de


tecnología Bluetooth, y a su vez ofrecen algún tipo de control de acceso. Es el ca-so de las cerraduras con control de acceso [11] ofrecidas por SICCBA, que a pesarde presentar funcionalidades similares a las que posee el sistema tratado en estetrabajo, no permite el registro de accesos ya que no posee comunicación con unservidor.En la tabla 1.1 se puede observar una comparativa entre algunos productos deventa nacional.

TABLA 1.1. Comparación entre productos nacionales.

Funcionalidad Cittyo Neo Control de accesos SICCBA

Tecnología Bluetooth Se desconoce SíGestión de ingreso avanzada Sí NoRegistro de accesos Sí NoEnvío de petición de ingreso Se desconoce No

1.4. Motivación

SURIX S.R.L. es una empresa que se dedica al diseño y venta de porteros IP parael uso domiciliario, hospitalario y empresarial. Entre sus productos se destacandiferentes tipos de porteros, algunos de ellos presentan la posibilidad de mane-jarse mediante un celular con una aplicación llamada VoIPBell [12].Teniendo en cuenta que se está produciendo un cambio tecnológico en el mun-do, donde cada vez más servicios se pueden incluir en un celular y realizar demanera automatizada, se presenta un panorama ideal para plantear avances enmateria de comodidad funcional en aspectos de la vida diaria.

1.5. Objetivos y alcance

El propósito de este trabajo es crear un sistema nuevo para la empresa, aprove-chando la conectividad con la que cuentan prácticamente todos los celulares hoyen día, abriendo la posibilidad de comenzar con una rama de productos orienta-da al internet de las cosas.En este trabajo se incluyó lo siguiente:

El diseño en Kicad [13] de una placa receptora, utilizando un módulo Nor-dic [14].

El diseño de una placa de apertura, a través de un esquemático en Kicad.

La programación de un firmware en la placa receptora para la comunicaciónvía Bluetooth con un celular.

La creación de un software en la nube de la empresa.

La creación de una base de datos en la nube de la empresa.

La creación de una aplicación para Android con posibilidad de exportarsea iOS.

1.6. Especificaciones 5

1.6. Especificaciones

En esta sección se muestran una serie de especificaciones para el trabajo tomadasde un documento redactado por el cliente.

1.6.1. Mínimo producto viable

El usuario debe poder registrarse utilizando un email y contraseña.

El usuario debe ingresar nombre completo y teléfono al registrarse.

La aplicación debe presentar un menú con opciones de ajustes de cuenta,administración de cerraduras y administración de llaves.

En los ajustes de cuenta el usuario debe poder modificar su clave.

En administración de cerraduras el usuario debe poder añadir cerraduras yadministrar permisos de ingreso.

El usuario debe poder agregar cerraduras al sistema utilizando su códigode identificación único (viene en una etiqueta en la cerradura).

La aplicación debe consultar al usuario por una descripción de la cerraduraal momento de añadirse la misma al sistema.

Al ingresar el usuario al menú de “administrar permisos de ingreso“, de-be ver una lista con todas sus cerraduras y debe poder seleccionarlas paraasignar permisos.

El usuario debe poder asignar permisos de ingreso irrestricto (en cualquierdía y hora) a sus cerraduras.

En el menú de administración de llaves el usuario debe poder ver una listade las cerraduras a las que tiene acceso.

El usuario debe poder ingresar a la aplicación utilizando su email y contra-seña.

La aplicación debe darle la opción al usuario de que su ingreso sea recor-dado, de forma tal, que en una apertura futura, no se requiera un nuevologin.

Al realizar el usuario un ingreso exitoso la aplicación debe presentarle unapantalla con una lista de las cerraduras a las que tiene acceso que sean cap-tadas por el scan Bluetooth.

La aplicación debe tener un botón que permita al usuario pedir un permisode acceso utilizando el escaneo QR del código de una cerradura.

La aplicación debe comunicarse con la API REST al menos una vez al díapara revalidar permisos de ingreso.

1.6.2. Producto completo

A las especificaciones del mínimo producto viable se les suman las siguientes:

Al registrarse un usuario en el sistema se le deberá enviar un email median-te el cuál pueda validar su cuenta.


Al registrarse un usuario el sistema debe consultarle si desea ingresar uncódigo de 4 dígitos.

En los ajustes de cuenta el usuario debe poder modificar su clave y su códi-go de 4 dígitos.

En administración de cerraduras el usuario debe poder añadir cerraduras,administrar permisos de ingreso, quitar cerraduras, cambiar cerraduras yver reportes de ingreso.

Al momento de añadir una cerradura al sistema se le debe consultar al usua-rio si desea que se pida el código de 4 dígitos para poder acceder a la misma.

Al momento de añadir una cerradura al sistema el usuario debe poder asig-narle una zona horaria. De no hacerlo solamente deben poder asignarsepermisos irrestrictos o de rango horario a esa cerradura.

Al cambiar una cerradura por otra deben transferirse todos los permisos deingreso de la cerradura original a la nueva cerradura.

El usuario debe poder asignar permisos de ingreso irrestricto (en cualquierdía y hora), ingreso restringido a días y horarios e ingreso por única vez asus cerraduras.

El usuario debe poder pedir al sistema la generación de reportes de ingresopor fecha, usuario y cerradura.

La aplicación debe guardar eventos de ingreso.

La aplicación debe comunicarse con la API REST al menos una vez al díapara revalidar permisos de ingreso y guardar reportes.

7

Capítulo 2

Introducción específica

En este capítulo se introducen las tecnologías y herramientas utilizadas en eldesarrollo del trabajo.

2.1. Protocolos de comunicación utilizados

2.1.1. Descripción del protocolo HTTP

Hypertext Transfer Protocol (HTTP) (o Protocolo de Transferencia de Hipertextoen español) es un protocolo de la capa de aplicación [15] para la transmisión dedocumentos hipermedia, como HTML [16]. Fue diseñado para la comunicaciónentre los navegadores y servidores web, aunque puede ser utilizado para otrospropósitos. Sigue el clásico modelo cliente-servidor [17], en el que un cliente esta-blece una conexión, realizando una petición a un servidor y espera una respuestadel mismo. Se trata de un protocolo sin estado, lo que significa que el servidor noguarda ningún dato (estado) entre dos peticiones. Aunque en la mayoría de casosse basa en una conexión del tipo TCP/IP [18], puede ser usado sobre cualquiercapa de transporte [19] segura o de confianza, es decir, sobre cualquier protocoloque no pierda mensajes silenciosamente, como es el caso de UDP [20][21].

FIGURA 2.1. Comunicación HTTP.1

1Imágen creada en base a una imágen tomada de: https://www.ionos.es/digitalguide/fileadmin/DigitalGuide/Screenshots_2020/diagram-of-http-communication-process-es.png

https://www.ionos.es/digitalguide/fileadmin/DigitalGuide/Screenshots_2020/diagram-of-http-communication-process-es.png

https://www.ionos.es/digitalguide/fileadmin/DigitalGuide/Screenshots_2020/diagram-of-http-communication-process-es.png

8 Capítulo 2. Introducción específica

Clientes y servidores se comunican intercambiando mensajes individuales (encontraposición a las comunicaciones que utilizan flujos continuos de datos). Losmensajes que envía el cliente, normalmente un navegador web, se llaman peticio-nes, y los mensajes enviados por el servidor se llaman respuestas.

Características del protocolo HTTP

Es sencillo: HTTP esta pensado y desarrollado para ser leído y fácilmenteinterpretado por las personas.

Es extensible: pueden desarrollarse nuevas funcionalidades, sin más queun cliente y un servidor, que comprendan la misma semántica sobre lascabeceras de HTTP.

Es un protocolo con sesiones, pero sin estados.

2.1.2. Bluetooth Low Energy

El Bluetooth de baja energía (Bluetooth Low Energy o BLE), es un subconjuntodel estándar Bluetooth v4.0. Dispone de una pila de protocolos en referencia a lacapa OSI completamente nueva y orientada a conexiones sencillas en aplicacionesde muy baja potencia (dispositivos dependientes de batería o pila).Este protocolo está diseñado para aplicaciones de bajo consumo. Esto se lograenviando pequeños paquetes de datos de forma poco frecuente. No está diseñadopara conexiones continuas ni para enviar grandes cantidades de datos. Cuando senecesitan ese tipo de características es conveniente utilizar Bluetooth clásico, quemantiene una conexión constante. Existen dos formas de conectar dispositivosBLE: Broadcaster-Observer y Central-Peripheral.

Broadcaster-Observer: no existe una conexión estándar, el Broadcaster, en-vía periódicamente señales (advertising packets) que el Observer escucha.El Broadcaster no tiene conocimiento si algún Observer se encuentra es-cuchando o no.

Central-Peripheral: es similar a la conexión Bluetooth clásica. En este casoel dispositivo central (master) encuentra un dispositivo periférico (slave) alque desea conectarse, inicia una conexión y asume el rol de gestionar laconexión y temporización.

La señal entre dispositivos se envía por RF en la banda de los 2.4 GHz.Los dispositivos Bluetooth pueden actuar como masters o slaves. La diferencia en-tre ellos es que un slave solo puede conectarse a un master, mientras que un masterpuede conectarse a varios slaves, o bien permitir que ellos se conecten entre sí,arbitrando las transferencias de información hasta un máximo de siete slaves.Cada uno de los dispositivos que se identifican vía Bluetooth, presenta una direc-ción única de 48 bits (MAC Address) y un nombre de dispositivo. La vinculaciónentre dos (o más) dispositivos se suele conocer bajo el nombre de pairing, em-parejamiento o apareamiento. Cuando se vinculan los dispositivos, se inicia unproceso en el que se identifican por nombre y MAC Address, y se solicita una cla-ve PIN para autorizar la conexión. En la figura 2.2 puede observarse el procesode emparejamiento entre dos dispositivos Bluetooth.

2.2. Tecnologías del backend 9

FIGURA 2.2. Comunicación BLE.2

2.2. Tecnologías del backend

2.2.1. Arquitectura REST

REST [22] es una arquitectura de desarrollo web que puede ser utilizada en cual-quier cliente HTTP. Es mucho más simple que otras arquitecturas, como XML-RPC [23] o SOAP [24]. Esta simplicidad se consigue porque emplea una interfazweb que usa hipermedios para la representación y transición de la información.Esta arquitectura fue definida por Roy Fielding [25] en el año 2000, quien ademáses uno de los principales artífices de la especificación del protocolo HTTP.La principal ventaja de esta arquitectura radica en que aporta a la web una ma-yor escalabilidad, es decir, da soporte a un mayor número de componentes y alas interacciones entre ellos. Ésto se explica gracias a una serie de característicasque presenta la arquitectura REST:

Es un protocolo sin estado, debido a que no se guarda la información enel servidor. Es decir, toda la información es enviada por el cliente en cadamensaje HTTP. De esta forma se consigue un ahorro en variables de sesióny almacenamiento interno del servidor.

Presenta un conjunto de operaciones bien definidas, siendo las más impor-tantes GET, POST, PUT y DELETE, que se emplea en todos los recursos.

Utiliza URIs únicas siguiendo una sintaxis universal.

Emplea hipermedios para representar la información, que suelen ser HTML,XML o JSON.

2Imágen tomada de: https://www.researchgate.net/profile/Wondimu-Zegeye/publication/311611851/figure/fig1/AS:439013854191616@1481680467048/Bluetooth-Low-Energy-Pairing.png

https://www.researchgate.net/profile/Wondimu-Zegeye/publication/311611851/figure/fig1/AS:439013854191616@1481680467048/Bluetooth-Low-Energy-Pairing.png




Descripción de las operaciones más utilizadas para la interacción con los distintosrecursos:

GET: se utiliza para acceder a los recursos.

POST: se utiliza para realizar acciones de creación de nuevos recursos.

PUT: se utiliza para modificar los recursos existentes.

DELETE: se utiliza para eliminar los recursos.

Ventajas del desarrollo basado en REST

1. Separación cliente/servidor: al ser sistemas independientes (solo se comu-nican con un lenguaje de intercambio como JSON) pueden desarrollarse co-mo proyectos autónomos. Para el cliente, la API actúa como una caja negraque expone recursos con los cuales interactuar. Mientras que la API solo seencarga de servir los recursos pedidos.

2. Independencia de tecnologías/lenguajes: puede desarrollarse utilizando cual-quier tipo de tecnología o lenguaje mientras se mantenga en su desarrollola filosofía de la arquitectura. Ésto a su vez permite la migración del sistemacompleto de una tecnología a otra sin tener la necesidad de realizar cambiosen otros componentes del sistema.

3. Escalabilidad y flexibilidad: permite el cambio de servidores, el añadido denuevos recursos o la capacidad de respuesta a nuevos tipos de operaciones.

2.2.2. Lenguaje PHP

PHP [26] es un lenguaje de programación de código abierto del lado del servidorque se utiliza principalmente para crear páginas web dinámicas. La abreviaturanació originariamente de “Personal Home Page Tools”, aunque hoy en día se haconvertido en el acrónimo recursivo para “PHP:Hypertext Preprocessor”.Mientras que los lenguajes del lado del cliente como HTML, CSS o JavaScript soninterpretados primero por el navegador web en el momento de abrir una página,el código PHP se ejecuta en el servidor web. Allí, los scripts de PHP generan elcódigo HTML que se envía después al navegador. Este no recibe el código real (elscript de PHP), sino el resultado de la ejecución del mismo.El ámbito de aplicación principal de PHP es la programación del lado del servi-dor, sobre todo de páginas dinámicas y aplicaciones. A pesar de tener una sintaxissencilla para principiantes, PHP ofrece una cantidad remarcable de funciones. Es-te lenguaje de programación se distingue por su amplio soporte a bases de datos,puede utilizarse en todo tipo de plataformas y está cubierto por una licencia PHPespecial [27] que permite su libre utilización e incluso la modificación del códigofuente.

2.3. Tecnologías del frontend 11

2.3. Tecnologías del frontend

2.3.1. Aplicación híbrida

Una aplicación híbrida es una aplicación de software que combina elementos deaplicaciones nativas, desarrolladas en lenguaje nativo (por ejemplo Java para An-droid) y aplicaciones web. Las aplicaciones híbridas son esencialmente aplicacio-nes web que se han colocado en un shell de aplicación nativo. Una vez que sedescargan de una tienda de aplicaciones y se instalan localmente, el shell puedeconectarse a cualquier capacidad que brinde la plataforma móvil a través de unnavegador integrado en la aplicación. El navegador y sus complementos se eje-cutan en el backend y son invisibles para el usuario final. En la figura 2.3 puedeobservarse una comparativa de funcionamiento entre una aplicación web, unaaplicación híbrida y una aplicación nativa.

FIGURA 2.3. Comparativa entre aplicaciones.3

Las aplicaciones híbridas son populares porque permiten a los desarrolladores es-cribir código para una aplicación móvil una vez, teniendo la capacidad de adap-tarse a múltiples plataformas. Debido a que las aplicaciones híbridas agregan unacapa adicional entre el código fuente y la plataforma de destino, pueden funcio-nar un poco más lento que las versiones nativas o web de la misma aplicación.

Funcionamiento de las aplicaciones híbridas

Las aplicaciones híbridas funcionan de manera similar a las aplicaciones web pe-ro, al igual que las aplicaciones nativas, se descargan en el dispositivo. Por otrolado, las aplicaciones híbridas comparten con las aplicaciones web el hecho deestar escritas en HTML5, CSS y JavaScript. Las mismas ejecutan código dentro de

3Imágen tomada de: https://www.gsoft.es/wp-content/uploads/2019/03/infografia-apps2.png

https://www.gsoft.es/wp-content/uploads/2019/03/infografia-apps2.png

https://www.gsoft.es/wp-content/uploads/2019/03/infografia-apps2.png


un contenedor. El motor del navegador del dispositivo se utiliza para representarel apartado visual (HTML y JavaScript) y dar acceso a API nativas para interac-tuar con el hardware específico del dispositivo.

2.4. Herramientas utilizadas

2.4.1. Ionic Framework

Ionic Framework [28] es un SDK de frontend de código abierto, que puede utili-zarse para desarrollar aplicaciones híbridas, basado en tecnologías web (HTML,CSS y Javascript). Es un framework que permite desarrollar aplicaciones para iOS,Android y la web, desde una única base de código. Se integra con los principalesframeworks de frontend, como Angular [29], React [30] y Vue [31], aunque tam-bién permite la utilización de Vanilla JavaScript. Hasta la llegada de React Nati-ve, Ionic ha sido una de las tecnologías líderes para el desarrollo de aplicacionesmóviles híbridas.

Características de Ionic Framework

Ionic se caracteriza por ser un framework que:

Permite desarrollar y desplegar aplicaciones híbridas, que funcionan enmúltiples plataformas, como iOS, Android, escritorio y la web (como unaaplicación web progresiva), todo ello con una única base de código.

Ofrece un diseño limpio, sencillo y funcional.

Emplea Capacitor [32] (o Cordova [33]) para implementar de forma nativao se ejecuta en el navegador como una aplicación web progresiva.

Está construido sobre tecnologías web: HTML, CSS y JavaScript.

Se puede usar con los frameworks frontend más populares, como Angular,React y Vue.

Entorno de ejecución nativo Capacitor

Capacitor es un proyecto de código abierto que ejecuta aplicaciones web moder-nas de forma nativa en iOS, Android, Electron y web (utilizando la tecnologíaProgressive Web App ) al tiempo que proporciona una interfaz potente y fácil deusar para acceder a los SDK nativos y las API nativas en cada plataforma.Con Capacitor, es posible desarrollar una aplicación y apuntar a un conjunto deAPI independientemente de la plataforma en la que se ejecute la misma, en lugarde administrar varias API para cada plataforma de destino.Esto significa que, por ejemplo, acceder a la cámara utiliza el mismo código eniOS / Android que en Electron y en la web. Esto facilita la creación de una aplica-ción web que se ejecute de forma nativa en dispositivos móviles, computadorasde escritorio y la web como una aplicación web progresiva. En la figura 2.4 seobserva la “ubicación“ en la que actúa capacitor (capa con el símbolo de un capa-citor) entre las tecnologías web y la capa nativa.

2.4. Herramientas utilizadas 13

FIGURA 2.4. Capa de actuación de Capacitor.4

2.4.2. Android Studio

Android Studio es el entorno de desarrollo integrado oficial para la plataformaAndroid. Fue anunciado el 16 de mayo de 2013 en la conferencia Google I/O, yreemplazó a Eclipse como el IDE oficial para el desarrollo de aplicaciones paraAndroid. La primera versión estable fue publicada en diciembre de 2014 [34].Está basado en el software IntelliJ IDEA de JetBrains [35] y ha sido publicado deforma gratuita a través de la Licencia Apache 2.0 [36]. Está disponible para lasplataformas GNU/Linux, macOS, Microsoft Windows y Google Chrome OS. Hasido diseñado específicamente para el desarrollo de Android.

2.4.3. Servidor Apache

Apache HTTP Server es un software de servidor web gratuito y de código abiertopara plataformas Unix con el cual se ejecutan el 46 % de los sitios web de todo elmundo. Es mantenido y desarrollado por la Apache Software Foundation [37].Le permite a los propietarios de sitios web servir contenido en la web, de ahí elnombre de “servidor web“. Es uno de los servidores web más antiguos y confia-bles, con la primera versión lanzada hace más de 20 años, en 1995 [38].

4Imágen tomada de: https://images.prismic.io/ionicframeworkcom/ffa25bb6-a032-44e4-b2f6-b83c5a73226f_capacitor-homepage-top-0%402x.png?auto=compress,format&rect=0,0,1089,1219&w=545&h=610&q=65

https://images.prismic.io/ionicframeworkcom/ffa25bb6-a032-44e4-b2f6-b83c5a73226f_capacitor-homepage-top-0%402x.png?auto=compress,format&rect=0,0,1089,1219&w=545&h=610&q=65




Apache es altamente personalizable, ya que tiene una estructura basada en módu-los. Los módulos le permiten a los administradores del servidor activar y desacti-var funcionalidades adicionales. Apache tiene módulos de seguridad, almacena-miento en caché, reescritura de URL, autenticación de contraseña y más. Tambiénpermite ajustar las configuraciones del servidor a través de un archivo llamado.htaccess.Algunas de las principales características de Apache son:

Cuenta con una comunidad grande de desarrolladores en todo el mundo,que contribuyen a mejorar el software, ya que el código fuente original estádisponible de forma gratuita para su visualización y colaboración.

Estructura constituida por módulos.

Es multiplataforma. Puede ser usado en servidores Windows y Linux lo queamplía sus posibilidades de uso.

Es de código abierto y de uso gratuito.

Ofrece un alto nivel de seguridad debido a sus actualizaciones constantes.

2.4.4. Placa de desarrollo basada en chip nRF52832

EL chip nRF52832 [39] es un SoC (System on a Chip) multiprotocolo de uso ge-neral. Resuelve los desafíos de una amplia gama de aplicaciones que necesitanfunciones avanzadas de Bluetooth LE, simultaneidad de protocolos y un conjun-to rico y variado de periféricos y funciones. Además, ofrece una generosa dispo-nibilidad de memoria tanto para Flash como para RAM.El nRF52832 tiene capacidad multiprotocolo con simultaneidad de protocolo com-pleto. Es compatible con Bluetooth Low Energy, incluida la función de alta velo-cidad de 2 Mbps. La red Bluetooth se puede ejecutar simultáneamente con Blue-tooth LE, lo que permite a los teléfonos inteligentes aprovisionar, poner en mar-cha, configurar y controlar los nodos de la red. También se admiten los protocolospatentados NFC, ANT y 2,4 GHz.Está construido alrededor de una CPU Arm Cortex-M4 con unidad de punto flo-tante funcionando a 64 MHz. Tiene etiqueta NFC-A para usar en soluciones sim-plificadas de emparejamiento y pago. Tiene numerosos periféricos e interfacesdigitales como PDM e I2S para micrófonos digitales y audio.Se logra un consumo de energía excepcionalmente bajo utilizando un sofisticadosistema de gestión de energía adaptable en chip.El chip de Nordic es la base del módulo de Raytac MDBT42Q [40], que propor-ciona interfaces GPIO, SPI, UART, I2C, I2S, PWM, ADC y NFC para conectar pe-riféricos y sensores. Este modulo se comercializa montado sobre una placa, queexpone pineras, leds, botones y un conector para alimentación y programación.En la figura 2.5 se puede observar una imágen de la placa de desarrollo utilizada.En la parte superior central de la misma, es posible observar el módulo de Raytac.

2.4. Herramientas utilizadas 15

FIGURA 2.5. Placa de desarrollo.

2.4.5. SQL Server

Microsoft SQL Server es un sistema de gestión de base de datos relacional, desa-rrollado por la empresa Microsoft [41].El lenguaje de desarrollo utilizado (por línea de comandos o mediante la inter-faz gráfica de Management Studio) es Transact-SQL (TSQL), una implementacióndel estándar ANSI del lenguaje SQL, utilizado para manipular y recuperar datos(DML), crear tablas y definir relaciones entre ellas (DDL).

Características

Las principales características de SQL Server son las siguientes:

Soporte de transacciones.

Soporta procedimientos almacenados.

Incluye también un entorno gráfico de administración, que permite el usode comandos DDL y DML gráficamente.

Permite trabajar en modo cliente-servidor, donde la información y datos sealojan en el servidor y los terminales o clientes de la red solo acceden a lainformación.

Además permite administrar información de otros servidores de datos. En el ma-nejo de SQL mediante líneas de comando se utiliza el SQLCMD [42], osql [43], oPowerShell [44].Para el desarrollo de aplicaciones más complejas (tres o más capas), MicrosoftSQL Server incluye interfaces de acceso para varias plataformas de desarrollo,entre ellas .NET [45], pero el servidor solo está disponible para sistemas operati-vos.


Programación

T-SQL (Transact-SQL) es el principal medio de interacción con el servidor, el cualpermite realizar las operaciones claves en SQL Server, incluyendo la creación ymodificación de esquemas de base de datos, inserción y modificación de datos enla base de datos, así como la administración del servidor como tal. Esto se realizamediante el envío de sentencias en T-SQL y declaraciones que son procesadas porel servidor y los resultados (o errores) regresan a la aplicación cliente.

17

Capítulo 3

Diseño e implementación

En este capítulo se detallan los criterios de diseño adoptados para el desarrollodel sistema y los pasos seguidos para la implementación del mismo.

3.1. Descripción del sistema

3.1.1. Funcionalidades generales

El sistema está constituido por una aplicación desarrollada utilizando Ionic, unaAPI REST programada en lenguaje PHP, una base de datos SQL y una placa Nor-dic.La aplicación tiene entre sus funcionalidades, la capacidad de detectar mediantescan Bluetooth la presencia de cerraduras (placas Nordic) pertenecientes al mis-mo sistema. Tiene también la capacidad de activar el Bluetooth en el teléfono, decaptar el código de las cerraduras utilizando scan QR y de conectarse utilizandoBLE a las cerraduras detectadas.El sistema está diseñado para que la aplicación solo sea capaz de detectar aquellascerraduras a las que tiene acceso en el día en el que se utiliza. Y luego, una vezdetectadas las cerraduras, permite el ingreso solamente a las que se tiene accesoen el horario en el que se desea ingresar.Todos los permisos de acceso son almacenados en la base de datos SQL, median-te la utilización de una serie de endpoints definidos en el backend. A los cuales laaplicación tiene acceso luego de realizar un inicio de sesión exitoso.Para verificar la validez de los permisos de acceso, la aplicación mantiene co-municación con el backend al menos una vez al día, en caso contrario bloqueacualquier posibilidad de acceso, hasta que pueda conectarse a internet y puedavalidar nuevamente los permisos.En la Figura 3.1 se muestra un diagrama de bloques en el que se puede observar,de forma simplificada, la comunicación entre las distintas partes o subsistemasque componen al sistema.

Se puede notar en la figura que existen dos opciones, opción 1 y opción 2. Esto sedebe a que el sistema se comercializará como parte de un sistema mayor coman-dado por una placa madre (portero) que conocerá los permisos de cada usuarioy en base a eso decidirá qué acciones se deben llevar a cabo una vez recibida laseñal por parte de la placa receptora (opción 1). O por otra parte, el sistema se co-mercializará de forma standalone, es decir que existirá la placa receptora junto conla placa de apertura asociadas a una puerta y la aplicación será la que decida, apartir de lo comunicado por el software en la nube, si la puerta en cuestión puedeo no abrirse (opción 2).

18 Capítulo 3. Diseño e implementación

FIGURA 3.1. Diagrama en bloques del sistema.

3.1.2. Comunicación de apertura

La comunicación entre la aplicación y la placa se produce utilizando el proto-colo BLE. La placa se encuentra realizando advertising mostrando su número deidentificación cada cierto tiempo y es detectada mediante el scan realizado porla aplicación. Al presionar el usuario sobre la cerradura encontrada, si posee lospermisos necesarios, se realiza un emparejamiento con la misma e intercambianuna serie de mensajes encriptados para validar la autenticidad de la aplicación,una vez realizado el intercambio, si fue exitoso, la cerradura envía un comandode apertura a la placa de apertura o se comunica con el portero dependiendo dela opción de cerradura adquirida.En la figura 3.2 se puede observar el proceso de scan y detección de una cerradura.

3.1.3. Comunicación backend

El backend PHP está conformado por una serie de recursos que se encargan deatender las solicitudes recibidas. Cada recurso, identificado por una direcciónweb (http://api:8000/cerraduras por ejemplo), verifica la petición que le es en-viada (POST, GET, PUT o DELETE) y si está configurado para manejarla, realizauna acción determinada.A través de los recursos expuestos por el backend se pueden obtener datos decerraduras, permisos, usuarios y reportes desde la base de datos SQL o guardardatos en la misma.

3.2. Arquitectura del sistema 19

FIGURA 3.2. Scan Bluetooth y detección de cerradura.

3.2. Arquitectura del sistema

Para una correcta descripción de la arquitectura del sistema, se utilizará como pa-trón el modelo de 5 capas de IoT. Con el objetivo de facilitar el seguimiento de lasección se presenta en la figura 3.3 como está constituido el modelo mencionado.

FIGURA 3.3. Modelo de capas IoT.1

1Imágen modificada, originalmente tomada de: https://redesmoviles.com/wp-content/uploads/2020/10/Comparacion-arquitecturas-1024x535.png

https://redesmoviles.com/wp-content/uploads/2020/10/Comparacion-arquitecturas-1024x535.png

https://redesmoviles.com/wp-content/uploads/2020/10/Comparacion-arquitecturas-1024x535.png


3.2.1. Capa de Negocio

Es la encargada de la administración y desarrollo de la solución completa de IoT ysus aplicaciones, así como de la generación de casos de negocios. Generalmente seencuentra vinculada con los servicios de la capa de aplicación de esta arquitectu-ra. En esta capa se asume la administración generalizada, control de los recursosasignados, control de accesos de usuarios y roles operativos de los mismos. Deigual modo, en esta capa se busca identificar las necesidades de control generalespara disparar el desarrollo y entrenamiento de algoritmos tendientes a automati-zar estas actividades. En la actualidad, muchos de los procesos realizados en estacapa se pueden realizar mediante servicios de computación en la nube.

3.2.2. Capa de Aplicación

Capa responsable por entregar servicios y aplicaciones específicas al usuario fi-nal. Esta capa puede entenderse como la convergencia entre IoT y las necesidadesindustriales e intelectuales, definiendo aplicaciones específicas.En esta capa se ubica la aplicación que es la encargada de prestar al usuario to-das las funcionalidades que requiere para administrar sus cerraduras. Desde laposibilidad de gestionar permisos, hasta la apertura de las puertas.

3.2.3. Capa de Procesamiento

La capa de procesamiento es la encargada del análisis y procesamiento de la in-formación que se obtiene de la capa de transporte. Debido a la gran cantidad deinformación recibida, muchas veces son necesarias técnicas de filtrado y análisisde Big Data [46] para su administración.En el caso del presente trabajo, no se deben manejar grandes volúmenes de infor-mación, o al menos no es necesario realizar un procesamiento sobre los mismos,pero sí surge la necesidad de almacenar la información de los permisos genera-dos por la aplicación, los datos de los usuarios y las cerraduras y los reportes deingreso. Por esto es que en esta capa se ubica a la API REST junto con la base dedatos SQL Server. La API es la encargada de recibir las consultas y gestionar losdatos y la base de datos se encarga de almacenar los datos y permitir el acceso alos mismos.

3.2.4. Capa de Transporte

Esta capa es la responsable del envío/recepción de la información recibida de lacapa de percepción sobre los diferentes tipos de red ya sean redes móviles, redesfijas o redes locales. Las principales redes utilizadas son 3G/4G/5G, WiFi, Blue-tooth, Zigbee, NFC entre otras. Debido al inmenso número de los dispositivosque conecta IoT y protocolos involucrados, la comunicación de diferentes redesde una forma ágil y confiable es fundamental para el desarrollo de la tecnología.Dentro de la capa de transporte, se encuentran los protocolos HTTP y BLE, sien-do el primero el encargado de transportar la información de los estados de lospermisos y los reportes de acceso, desde el celular a la API REST y de la mismahacia el celular. Por otro lado, BLE se encarga de establecer la comunicación entreel celular y la placa para lograr la apertura de la puerta.

3.3. Arquitectura de datos 21

3.2.5. Capa de Percepción

Es la capa sensorial de IoT donde los dispositivos identifican sus alrededores, re-caban información del mundo físico e interactúan con él. Esta capa está compues-ta por cámaras, GPS, sensores, terminales, RFID tags y actuadores que conviertentoda la información obtenida en señales eléctricas las cuales son más fáciles detransmitir para su posterior análisis.En esta capa es posible ubicar a la placa Nordic, que es la que posee la capacidadde actuación para interactuar con las cerraduras permitiendo la apertura de laspuertas.

3.3. Arquitectura de datos

A la hora de diseñar la estructura de la base de datos SQL, se realizó un análisisdel sistema en base a la especificación planteada por el cliente, obteniéndose comoconclusión que el sistema consta fundamentalmente de dos entidades, usuarios ycerraduras; y por otro lado, se tienen las interacciones que existen entre las mis-mas.La primera interacción que surge del análisis, es el permiso. Los usuarios debenpoder acceder a las cerraduras y para eso deben poseer permisos de acceso. Porotro lado, la acción de acceso a la cerradura debe generar un reporte. Finalmentelos usuarios deben tener la posibilidad de solicitar permisos de acceso a cerradu-ras específicas.En la figura 3.4 se observa un diagrama UML [47] de la base de datos implemen-tada.


FIGURA 3.4. Diagrama UML de la base de datos.

3.3. Arquitectura de datos 23

A continuación se realiza una breve descripción de la función de cada tabla.

Reporte: tabla que almacena los reportes de ingreso.

Solicitud: tabla que almacena las solicitudes de ingreso.

Usuario: tabla que almacena los datos de los usuarios del sistema.

Cerradura: tabla que almacena los datos de las cerraduras del sistema.

Permiso: tabla que almacena los permisos de acceso.

Las tablas están relacionadas entre sí mediante llaves foráneas [48] y mantienenrelaciones de uno o cero a muchos y de muchos a uno, como se explica debajo:

Las tablas “Permiso“, “Reporte“ y “Solicitud“ tienen relaciones de uno auno con “Usuario“ y “Cerradura“. Esto implica que cada reporte/solicitudpuede estar relacionado únicamente con un usuario y una cerradura.

La tabla “Usuario“ tiene relaciones de cero a muchos con “Reporte“, “So-licitud“, “Cerradura“ y “Permiso“. Esto implica que cada usuario cargadoen la tabla puede tener cero o muchos permisos, cero o muchas cerraduras,cero o muchas solicitudes y cero o muchos reportes.

La tabla “Cerradura“ tiene relaciones de cero a muchos con “Reporte“ y con“Solicitud“, de uno a uno con “Usuario“ y de uno a muchos con “Permiso“.Esto implica que cada cerradura cargada en el sistema puede tener muchosreportes y solicitudes asociados, únicamente un usuario, que es el dueño dela misma y al menos un permiso que se asigna automáticamente al usuariodueño de la cerradura.

3.3.1. Programación

Como se explica en el capítulo 2, para la programación de la base de datos, seutilizó la extensión del lenguaje SQL, T-SQL.En el código 3.1 se observan las sentencias utilizadas para la creación de la basede datos y la tabla de usuarios. En la primera línea se crea la base de datos conla sentencia “CREATE DATABASE“, luego se utiliza la sentencia “CREATE TA-BLE“ para crear la tabla “Usuario“ perteneciente a la base de datos “Surix“, entreparéntesis se especifican los campos que se deben crear en esa tabla.

CÓDIGO 3.1. Código para la creación de la base de datos.

CREATE DATABASE ‘Surix‘ /*!40100 DEFAULT CHARACTER SET utf8 */

CREATE TABLE ‘Surix‘.‘Usuario‘ (‘ID_usuario‘ bigint(20) NOT NULL AUTO_INCREMENT,‘Nombre‘ varchar(25) NOT NULL,‘Apellido‘ varchar(25) NOT NULL,‘Direccion‘ varchar(30) NOT NULL,‘Telefono‘ bigint(20) NOT NULL,‘Email‘ varchar(40) NOT NULL,‘Pass‘ varchar(12) NOT NULL,‘Codigo‘ int(11) DEFAULT NULL,‘Confirmado‘ tinyint(4) NOT NULL,‘Fecha_creacion‘ timestamp NOT NULL DEFAULTCURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,


PRIMARY KEY (‘ID_usuario‘),UNIQUE KEY ‘Email‘ (‘Email‘)

) ENGINE=InnoDB AUTO_INCREMENT=57 DEFAULT CHARSET=utf8

El resto de las tablas se generaron con un código similar.Cabe destacar que el orden de creación de las tablas es importante para no gene-rar errores de constraints o restricciones. Por ejemplo, no es posible crear la tablaCerradura antes de crear la tabla Usuario, ya que la tabla Cerradura tiene unallave foránea relacionada con la tabla Usuario y si la misma no existe, se pro-ducirá un error ya que la compilación intentará crear una relación con una tablainexistente.

3.4. Desarrollo de la API REST

3.4.1. Estructura de archivos

Para el desarrollo de la API REST se adoptó una estructura basada en tres “tipos“de archivos. Por un lado, el archivo index es el encargado de recibir las peticionesHTTP y explorarlas para verificar a que recurso de la API apuntan y redirigirlasal mismo para su posterior tratamiento. Por otro lado, los archivos con el nombredel recurso seguido de “Controller“, por ejemplo “cerraduraController“, son losdiferentes endpoints a los que las peticiones son dirigidas luego de pasar por elindex. En estos endpoints se verifica el método que se adjunta a la petición (GET,PUT, POST o DELETE) y en función del mismo y de los datos pedidos o recibidos,se llama a un manejador para que actúe en consecuencia. Finalmente, los mane-jadores están definidos en otros archivos denominados por el nombre del recursoterminado en “Gateway“, por ejemplo “cerraduraGateway“. En estos archivosse define y realiza la petición a la base de datos y luego se retornan los datos alrespectivo controller para su tratamiento y posterior devolución al cliente [49].

Conexión a la base de datos

La conexión a la base de datos se realiza a través del código 3.2. En las líneas3-31 se observa la creación de una clase llamada “DatabaseConnector“ que es laencargada de realizar la conexión entre la API y la base de datos. Entre las líneas7 y 25 se define el constructor de la clase, dentro del mismo, en las líneas 9-13se obtienen de las variables de entorno, los valores de los datos necesarios parainiciar la conexión. Luego, entre las líneas 15-22 se intenta establecer la conexión.Finalmente, entre las líneas 28-31 se define la función “getConnection“ mediantela cuál se retorna la conexión a la base de datos para que pueda ser utilizada enotras secciones de la API.

CÓDIGO 3.2. Atención de request login en index.1 namespace Src\mysql;23 class DatabaseConnector {45 private $dbConnection = null;67 public function __construct()8 {9 $host = getenv(’DB_HOST’);10 $port = getenv(’DB_PORT’);

3.4. Desarrollo de la API REST 25

11 $db = getenv(’DB_DATABASE’);12 $user = getenv(’DB_USERNAME’);13 $pass = getenv(’DB_PASSWORD’);1415 try {16 $this->dbConnection = new \PDO(17 "mysql:host=$host;port=$port;18 charset=utf8mb4;19 dbname=$db",20 $user,21 $pass);22 } catch (\PDOException $e) {23 exit($e->getMessage());24 }25 }2627 public function getConnection()28 {29 return $this->dbConnection;30 }31 }

Tratamiento de las peticiones

Para una mejor comprensión de la estructura de archivos planteada, se utiliza-rá la figura 3.5 junto con algunos fragmentos de código, de forma de hacer unseguimiento del proceso de atención de una petición de login por parte de uncliente.

FIGURA 3.5. Proceso de atención de una petición.


En las líneas 1 y 2 del código 3.3, se observa como se guarda en la variable “uri“‘,la dirección de la URL a la que se realizó la petición y luego se la divide, utili-zando el carácter ’/’ como separador, de esta forma, tomando como ejemplo ladirección que se muestra en la figura 3.6, en la posición 1 del arreglo “uri“ quedaalmacenada la cadena “login“. Luego, en la línea 4, se guarda el tipo de requestrealizada (GET, PUT, POST o DELETE) en la variable “requestMethod“. Final-mente, en la línea 6, se verifica si la cadena guardada en la posición 1 del arreglo“uri“ es “login“ y, de ser así, como se observa en las líneas 7 y 8, se crea un objetode la clase “loginController“ utilizando los parámetros “dbConnection“ y “re-questMethod“. Y en la línea 9 se llama al método de la clase “loginController“,“processRequest“.

CÓDIGO 3.3. Atención de request login en index.1 $uri = parse_url($_SERVER[’REQUEST_URI’], PHP_URL_PATH);2 $uri = explode( ’/’, $uri );34 $requestMethod = $_SERVER["REQUEST_METHOD"];56 if($uri[1] == ’login’){7 $controller = new loginController($dbConnection,8 $requestMethod);9 $controller->processRequest();10 }

En el código 3.4 se muestra la definición de la función “processRequest“, llamadaen el código 3.3 en la línea 9, en la misma entre las líneas 3-15 se define un switchpara actuar en función del tipo de petición recibida. En las líneas 9-11 se observaque al recibirse una petición de tipo POST, se llama a la función “loginSecure“ quese encuentra definida entre las líneas 21-28. En las líneas 23-24 se toman los valo-res recibidos en la petición y se guardan en la variable “input“, luego en la línea25 se llama al método de “loginGateway“, “login“, pasándole como parámetro lavariable “input“.

CÓDIGO 3.4. Atención de request login en index.1 public function processRequest()2 {3 switch ($this->requestMethod) {4 case ’OPTIONS’:5 $response = $this->sendHeaders();6 break;7 case ’GET’:8 break;9 case ’POST’:10 $response = $this->loginSecure();11 break;12 default:13 $response = $this->notFoundResponse();14 break;15 }16 header($response[’status_code_header’]);17 if ($response[’body’]) {18 echo $response[’body’];19 }20 }21 private function loginSecure()

3.5. Desarrollo de la aplicación 27

22 {23 $input = (array) json_decode(file_get_contents(’php://24 input’), TRUE);25 $result = $this->loginGateway->login($input);26 //...27 return $response;28 }

En el código 3.5 se observa la definición de la función “login“ en el archivo “lo-ginGateway“. Dentro de esta función en las líneas 3-6 se define la consulta SQL arealizar a la base de datos. Luego en las líneas 8-17 se intenta ejecutar la consultaa la base de datos y de funcionar correctamente, se retorna el resultado.

CÓDIGO 3.5. Atención de request login en index.1 public function login(Array $input)2 {3 $statement = "4 SELECT Nombre, Apellido, Telefono, Email,5 Pass FROM Usuario WHERE Email=:email;6 ";78 try {9 $statement = $this->db->prepare($statement);10 $statement->execute(array(11 ’email’ => $input[’email’]12 ));13 $result = $statement->fetchAll(\PDO::FETCH_ASSOC);14 return $result;15 } catch (\PDOException $e) {16 exit($e->getMessage());17 }18 }

Finalmente como se observa en la línea 27 del código 3.4 se retorna la respuesta.Es importante destacar que el código obviado en la función loginSecure, realizaun tratamiento sobre los datos obtenidos a fin de generar un token JWT (JSONWeb Token) [50] utilizado para validar las consultas posteriores.

3.5. Desarrollo de la aplicación

3.5.1. Estructura de archivos

Para el desarrollo de la aplicación se siguió el formato generado automáticamen-te por Ionic, que consta fundamentalmente de una carpeta src donde se alojantodos los componentes (en este caso páginas, modales, modelos y servicios) queconstituyen a la aplicación.

Páginas

Las páginas en Ionic son los componentes principales, ya que son las que presen-tan las vistas al usuario y permiten la interacción con el resto de los componentes.Como se observa en la figura 3.6 cada página en Ionic consta de una serie de ar-chivos. Los mismos son generados automáticamente por el framework al crearsela página.


FIGURA 3.6. Archivos de una página en Ionic.

Cada archivo tiene la funcionalidad que se explica a continuación:

El archivo con la terminación routing.module.ts contiene el código utilizadopara el ruteo de la página.

El archivo module.ts contiene las importaciones de los módulos o pluginsque debe utilizar la página.

El archivo page.html contiene el código HTML que genera la vista de lapágina.

El archivo page.scss contiene los estilos que se aplican a la página.

El archivo page.spec.ts contiene los tests a realizar sobre la página.

El archivo page.ts contiene el código que le da la funcionalidad a la página.

Modales

Los modales son páginas que se cargan por sobre la vista en la que son llama-dos y suelen utilizarse para contener formularios. Poseen exactamente la mismaestructura de archivos que las páginas.

Servicios

Los servicios son componentes que suelen utilizarse para interactuar con pluginso módulos nativos del celular o para ejecutar tareas específicas, que puede necesi-tar realizar más de un componente. De esta forma, los servicios contienen variasfunciones que pueden ser utilizadas por otros componentes con los fines ya men-cionados.Los servicios poseen una estructura de archivos más sencilla que las páginas yaque están compuestos por dos archivos, el archivo service.spec.ts que contienelos tests y el archivo service.ts que contiene las definiciones de las funciones delservicio.

3.5. Desarrollo de la aplicación 29

Modelos

Los modelos son clases definidas en archivos .ts. Generalmente en estas clases sedefinen objetos que luego son utilizados para dar formato a las respuestas espe-radas de las peticiones HTTP.

En la figura 3.7 se observa como interactúan los diferentes componentes de laaplicación.

FIGURA 3.7. Aplicación separada en componentes.

3.5.2. Implementación de la estructura

Páginas

A la hora de implementar la aplicación se crearon las siguientes páginas:

access-admin: la página access admin contiene el código necesario para ges-tionar la generación de permisos de ingreso en el sistema.

account-settings: contiene el código necesario para gestionar la configura-ción de la cuenta (cambios de contraseña o código de 4 dígitos).

add-lock: contiene el código utilizado para presentar un formulario que per-mite añadir nuevas cerraduras al sistema.

change-lock: contiene el código necesario para presentar un formulario quepermite cambiar una cerradura del sistema.

home: es la primera página que se presenta al usuario luego de que ingreseal sistema y contiene el código necesario para guardar los datos del usuarioactivo en el almacenamiento interno del celular. A su vez en esta página serealiza la gestión de permisos y la presentación de las cerraduras al usuarioluego del scan BLE.


key-admin: contiene el código para realizar la gestión de las llaves (permi-sos) que posee el usuario activo.

lock-admin: contiene el código necesario para direccionar a las páginas degestión de las cerraduras como add-lock y change-lock.

login: contiene el código necesario para mostrar el formulario de login en laaplicación.

reg-form: contiene el código necesario para mostrar el formulario de regis-tro en el sistema.

remove-lock: contiene el código para mostrar la lista de cerraduras que po-see el usuario activo y permitirle eliminarlas del sistema.

reports: contiene el código necesario para generar y obtener reportes de ac-ceso.

requests: contiene el código utilizado para mostrar una lista con las solici-tudes de acceso QR recibidas. A su vez permite la funcionalidad de aceptaro rechazar las mismas.

sign-in: se muestra al iniciar la aplicación. Tiene la funcionalidad de mos-trar dos botones uno de acceso al formulario de login y otro de acceso alformulario de registro.

Ionic genera automáticamente una primera página con el nombre de app, quecontiene la inicialización de la aplicación.Para el desarrollo de esta aplicación se utilizan solamente los archivos routing.module.tsy module.ts de la página app para realizar todo el ruteo de la aplicación y la in-clusión de módulos y plugins.

Servicios

Los servicios creados son los siguientes:

solicitud/usuario/reports/permiso/cerradura/login: son servicios encar-gados de comunicarse con la API REST. Contienen código que realiza peti-ciones http a los diferentes endpoints ofrecidos por la API.

ble: servicio encargado de implementar todas las funcionalidades BLE yhacerlas accesibles a las páginas que componen el sistema.

qr: servicio que implementa las funcionalidades QR y las hace accesibles alas páginas que componen el sistema.

login-guard: servicio utilizado para impedir el acceso a la aplicación sinrealizar previamente un login en el sistema.

Modales

En el desarrollo de la aplicación se crearon los siguientes modales:

access-admin-modal: a este modal se accede desde la página access-adminy presenta un formulario para la creación de permisos por parte del usuario.

reports-modal: a este modal se accede desde la página reports y presentaun formulario para obtener reportes de acceso.

3.6. Desarrollo del firmware 31

Modelos

Los modelos que utiliza la aplicación son los siguientes:

lock

permission

report

user

Cada uno de los modelos poseen los mismos campos que las tablas SQL mostra-das en la figura 3.4, ya que se utilizan para dar formato a los valores obtenido-s/enviados a la base de datos.

3.6. Desarrollo del firmware

Para el desarrollo del firmware se utilizó como base un ejemplo de Nordic Se-miconductor Playground [51]. En el mismo se presenta el código necesario pararealizar una conexión BLE entre un celular y la placa nRF52832.El código del ejemplo ofrece la capacidad de interacción con la placa a travésde un servicio BLE y una característica propia de ese servicio [52]. Mediante laescritura de esa característica es posible realizar acciones sobre algún hardwareconectado a la placa.Para adecuar el código del ejemplo al presente trabajo, se modificó el servicio conel fin de manejar la conexión con la aplicación y realizar la comunicación con lacerradura, en función de los datos recibidos a través de la comunicación BLE.El firmware se programó con la capacidad de realizar en simultáneo, las comu-nicaciones necesarias para el funcionamiento del sistema en sus dos opciones decomercialización (figura 3.1). Cuando la placa recibe a través del servicio los pa-rámetros adecuados por parte de la aplicación, envía una serie de pulsos tempori-zados, que son interpretados por la placa de apertura (opción de comercialización2). A su vez la placa envía los datos del usuario encriptados por UART a la placamadre si la misma se encuentra conectada (opción de comercialización 1). De estaforma es posible utilizar un único firmware para ambas versiones del sistema.

3.7. Ciberseguridad del sistema

Con el objetivo de asegurar las conexiones utilizadas por el sistema se tomaronprincipalmente dos medidas de seguridad que serán explicadas en las siguientessubsecciones.

3.7.1. Seguridad HTTP

Con el fin de asegurar la conexión HTTP entre la aplicación y la API se añadióautenticación JWT al proceso de comunicación.Para comunicarse con la API la aplicación realiza una solicitud de tipo POST a laURL terminada en /login utilizando los datos proporcionados por el usuario y, silos mismos son correctos, la API le responde con un token JWT que la aplicaciónluego utiliza para poder acceder al resto de los recursos expuestos por el backend.En la figura 3.8 se puede observar la forma de obtención de un token JWT.


FIGURA 3.8. Obtención de JWT.

Si el usuario no dispone de un token válido, la API responde a cualquier tipo deconsulta, salvo a las consultas de login y de registro de nuevo usuario, con uncódigo 401 (no autorizado).

3.7.2. Seguridad BLE

Para asegurar la conexión BLE entre la placa y el celular, se implementó un hands-hake de tres pasos que se describirá a partir de la figura 3.9.

FIGURA 3.9. Handshake para autenticación BLE.

3.7. Ciberseguridad del sistema 33

La aplicación envía a la placa una clave secreta generada aleatoriamente, la placa,luego de recibir la clave secreta, realiza sobre la misma una serie de operacionesgenerando una nueva clave (Resultado1). Por otro lado la aplicación realiza en si-multáneo las mismas operaciones, obteniendo el mismo resultado. La placa envíael Resultado1 a la aplicación y esta última verifica que coincida con el resultadoobtenido. Si los resultados coinciden, la aplicación realiza otra serie de opera-ciones sobre el Resultado1 y envía el Resultado2 a la placa, que verifica, previarealización de las mismas operaciones, que lo enviado por la aplicación coincidacon el resultado obtenido de las operaciones. Si al final del handshake no ocurrie-ron errores, la placa procede a realizar los procesos de apertura. De lo contrariose desconecta y continúa con el advertising.Utilizando un método como el mencionado, se evita que se pueda vulnerar elsistema mediante la clonación de la cerradura.

35

Capítulo 4

Ensayos y resultados

En este capítulo se describen los ensayos realizados sobre el sistema y los resulta-dos obtenidos a partir de los mismos.

4.1. Banco de pruebas

El sistema consta fundamentalmente de tres partes, la aplicación, el firmware enla placa Nordic y el backend constituido por la API y la base de datos.Para ensayar el firmware en la placa se utilizó el banco de pruebas que puedeobservarse en la figura 4.1.

FIGURA 4.1. Banco de pruebas para el firmware.

En la imágen se puede observar un J-LINK de Segger [53] junto con un J-TAG[54] para hacer de interfaz hacia la placa, también es posible distinguir la placa

36 Capítulo 4. Ensayos y resultados

nRF52832 y los cables de conexión necesarios.Con el equipo mencionado es posible realizar un debug del firmware cargado enla placa en tiempo real.Por otro lado también se utilizó para ensayar el firmware la aplicación para celu-lar nRF Connect [55], que permite verificar la conexión BLE con la placa.

Para ensayar la aplicación se utilizó un celular Motorola Moto-G8 PLUS [56], jun-to con la interfaz de debug que provee Ionic a través de Android Studio.

4.2. Ensayos sobre el firmware

Para ensayar el firmware se realizaron mayormente pruebas de uso, ya que la pla-ca posee algunos LED que fueron utilizados para probar la funcionalidad de laconexión BLE y por otro lado la capacidad de enviar el tren de pulsos de aperturapara el sistema en su variante standalone.La primera prueba realizada constó en verificar el advertising y la posibilidad deconectarse a la placa. Con ese objetivo, se programó al firmware para que el LEDverde de la placa parpadeara cada vez que la misma enviara un paquete de adver-tising. Visualmente fue posible comprobar que el LED de la placa parpadeaba y asu vez, a través del uso de la aplicación nRF Connect, fue posible verificar que laplaca era detectada por un celular, como se puede observar en la figura 4.2.

FIGURA 4.2. Aplicación nRF Connect.

Posteriormente se programó a la placa para que enviara un tren de pulsos a tra-vés de un dado pin al realizarse una conexión BLE exitosa. Ese pin se conectó aun LED, con el objetivo de poder verificar visualmente el funcionamiento de laconexión. Pudiendo constatar nuevamente, de forma visual, el parpadeo del LEDal realizarse la conexión.

4.2. Ensayos sobre el firmware 37

Finalmente se realizaron pruebas con el firmware en su versión final. En esta ver-sión se incluía el handshake de verificación de la conexión BLE. En ese caso tam-bién pudo constatarse la correcta resolución del intercambio a través del parpa-deo del LED que implicaba el envío de la señal de apertura.También se realizaron ensayos para el modo de funcionamiento en relación a unportero, pero fueron llevados a cabo por la empresa debido a la necesidad del usode más herramientas.

4.2.1. Ensayos sobre la API

Para ensayar al backend del sistema se utilizó Postman [57] y también se realiza-ron pruebas de uso.Mediante la utilización de postman se realizaron pruebas a los diferentes end-points expuestos por la API con el objetivo de verificar que respondan correcta-mente. A modo de ejemplo puede observarse en la figura 4.3 una batería de testsque se realizaron sobre un endpoint de la API, la misma se levantó localmente pararealizar pruebas.

FIGURA 4.3. Batería de tests en Postman.

El primer test intenta obtener, mediante una petición GET, un recurso protegidosin poseer un token JWT (sin estar autenticado frente al sistema), como puedeobservarse el resultado de la consulta es un estado 401 de prohibído. Luego, en elsiguiente test, se realiza una petición POST de login, con los datos válidos de unusuario del sistema, obteniendo por respuesta una confirmación de login exitosojunto con un código de estado de 200 de solicitud exitosa. En el tercer test, serealiza nuevamente la misma consulta GET que se realizó en el primer test, peroenviando en la cabecera de la solicitud el token válido, obteniendo por respuestaun código de estado de 200. Finalmente se prueba acceder mediante una peticiónGET a un recurso inexistente en el sistema, nuevamente enviando el token válido,y se obtiene una respuesta con código de estado 404 de recurso no encontrado.


4.3. Ensayos sobre el sistema y resultados obtenidos

La mayoría de las pruebas realizadas sobre la aplicación fueron de verificaciónde funcionalidades mediante el uso del sistema completo. También durante eldesarrollo se realizaron pruebas utilizando las capacidades de debug que otorgaIonic a traves del uso de Android Studio. En la figura 4.4 se puede observar ladetección de la placa Nordic, en la consola del framework de Android.

FIGURA 4.4. Captura de la consola de Android Studio.

Los ensayos finales sobre la aplicación en uso, coinciden con las pruebas de inte-gración del sistema completo, ya que la aplicación en funcionamiento interactúacon todas las partes del sistema (placa Nordic y backend).En las figuras 4.5 y 4.6 se muestran imágenes de algunas pantallas de la aplica-ción finalizada. Particularmente en la figura 4.6, se puede observar la pantallade gestión de permisos, que es una de las características más atractivas del pre-sente sistema, a través de esta pantalla es posible asignar permisos de acceso acualquier usuario existente en el sistema.

FIGURA 4.5. Pantallas de inicio, login y registro.

4.3. Ensayos sobre el sistema y resultados obtenidos 39

FIGURA 4.6. Pantallas de menú, administración de cerraduras ygestión de permisos.

Lo anteriormente mencionado puede observarse con más detalle en las figuras4.7, 4.8 y 4.9 donde se muestran las pantallas para asignación de cada tipo depermiso. Los formularios de asignación se generan dinámicamente en función dela selección del usuario.

FIGURA 4.7. Pantalla de asignación de permisos irrestrictos.


FIGURA 4.8. Pantalla de asignación de permisos restringidos pordía y horario.

FIGURA 4.9. Pantalla de asignación de permisos de única vez.

4.3. Ensayos sobre el sistema y resultados obtenidos 41

Finalmente en la figura 4.10 se muestra otra de las características principales delsistema, que es la generación de reportes.

FIGURA 4.10. Pantalla de generación de reportes.

En el formulario que se ve en la pantalla anterior, el usuario puede generar repor-tes de la siguiente forma:

Si selecciona solamente fechas, el sistema genera un reporte con todos losaccesos a las puertas de las que es dueño, entre las fechas seleccionadas.

Si selecciona fechas y usuario, el sistema genera un reporte con todos losaccesos del usuario seleccionado, a las puertas de las que es dueño, entrelas fechas seleccionadas.

Si selecciona fechas y cerradura, el sistema genera un reporte con todos losaccesos a esa cerradura, que hayan existido entre las fechas seleccionadas.

Si selecciona fechas, cerradura y usuario, el sistema genera un reporte contodos los accesos de ese usuario, a esa cerradura, en las fechas selecciona-das.

Lo anteriormente mencionado puede observarse en la figura 4.11.


FIGURA 4.11. Reportes generados.

Cabe destacar también la funcionalidad de petición de acceso que posee la apli-cación a través del uso del scan QR. Al realizar un scan QR de una cerradura delsistema, el mismo verifica contra la base de datos, quién es el dueño de la mismay le envía una solicitud de apertura, que el usuario puede visualizar y aceptardesde la aplicación instalada en su celular.

4.4. Comparación con otras cerraduras inteligentes

Al hablar del presente trabajo se pueden realizar dos tipos de comparaciones,una puede realizarse con otras cerraduras inteligentes que no utilizan un celulary otra con cerraduras inteligentes que sí lo utilizan. A continuación se realiza unacomparativa con las primeras cerraduras inteligentes mencionadas.En la Tabla 4.1 se observa una comparativa entre otros sistemas (entre los que seincluyen los que utilizan tecnología biométrica, tarjetas magnéticas o código deingreso) de acceso sin llave y este trabajo.

TABLA 4.1. Comparación entre sistemas.

Funcionalidad Sistema ID Mobile Otros sistemas

Tecnología BLE Sí NoGestión de ingreso avanzada Sí NoEnvío de petición de ingreso Sí NoGeneración de reportes Sí No

Realizar una comparativa con otras cerraduras inteligentes que utilizan un celu-lar, centrándose en los productos nacionales, es una tarea más complicada, ya quecomo se analizó en el capítulo 1, no existen tantos sistemas que sean realmentesimilares al del presente trabajo en cuanto a funcionalidades ofrecidas.

4.4. Comparación con otras cerraduras inteligentes 43

De todas formas se extiende la tabla comparativa presentada en el capítulo 1,incluyendo a este trabajo.

TABLA 4.2. Comparación entre productos nacionales.

Funcionalidad Cittyo Neo Controlde accesosSICCBA

Este traba-jo

Tecnología BLE Se desconoce No SíTecnología Bluetooth Se desconoce Sí NoGestión de ingreso avanzada Sí No SíRegistro de accesos Sí No SíEnvío de petición de ingreso Se desconoce No Sí

Por eso se puede destacar el aporte de este trabajo, ya que se trata de un segmentode productos que se encuentra en crecimiento y en plena inserción en el mercadolocal.

45

Capítulo 5

Conclusiones

En este capítulo se muestran las conclusiones sobre el trabajo realizado. A su vezse presentan algunas modificaciones o mejoras como posible trabajo futuro.

5.1. Conclusiones generales

5.1.1. Cumplimiento de las especificaciones

En la sección 1.6 se listaron una serie de especificaciones mínimas y completasplanteadas por el cliente para el desarrollo del trabajo. El objetivo del cliente erael de asegurarse al menos el cumplimiento de las especificaciones mínimas al fi-nalizar el tiempo de 600 horas estipulado.Desde un principio se buscó alcanzar las especificaciones completas para el pro-yecto y con esa idea se logró cumplir con todos los requerimientos pedidos porel cliente, exceptuando el envío de un email para validar la cuenta al realizarseun registro. En ese aspecto, se llegó a instalar un módulo en el backend PHP y serealizaron pruebas locales con éxito pero no se realizó una puesta en marcha enproducción. De todas formas el código fue entregado al cliente para que puedacontinuarse con el desarrollo.

5.1.2. Cumplimiento de la planificación

Cronograma

Se cumplió con la planificación en tiempo y forma aunque no se siguió exac-tamente con el orden de desarrollo planteado para cada tarea. Varias tareas sehicieron en simultáneo o llevaron menos tiempo de lo previsto. Por citar algunosejemplos, el desarrollo del hardware tenía un tiempo estimado de 100 horas y eltiempo empleado fue mucho menor ya que se contó con la ayuda de un empleadode SURIX. Por otro lado se estimaba dedicar 10 horas a la selección de la nube dealguna compañia para alojar al sistema pero finalmente se utilizaron los servido-res que ya tenía contratados la empresa, por lo que no se dedicó tiempo alguno aesa tarea.

Riesgos

Al realizar la planificación se planteó un riesgo relacionado con la situación en laque existieran fallas en los componentes que iban a ser utilizados para la progra-mación de la placa. En un principio se le dio una probabilidad de ocurrencia muybaja a dicho riesgo ya que los componentes iban a ser probados en la empresaantes de ser enviados. Pero al comenzar a trabajar con la placa se dio la situación

46 Capítulo 5. Conclusiones

planteada y, al considerar que ese riesgo no podía presentarse, se relacionó al pro-blema con otro riesgo planteado, relativo a la imposibilidad de realizar alguna delas instalaciones o alguna de las conexiones pertinentes para la programación dela placa. Por lo que se invirtieron horas de pruebas de forma innecesaria.

5.1.3. Recursos utilizados

Durante el desarrollo del trabajo se utilizó un recurso sumamente útil planteadopor el cliente que fue el de acordar un día a la semana para entregar un informesemanal. En dicho informe se debía dejar constancia de los avances realizadoshasta la fecha.A continuación se listan una serie de motivos por los que se puede considerarque esta técnica es útil:

Ayuda a la organización del trabajo por parte del alumno.

Ayuda al alumno a tener metas semanales claras.

Ayuda al cliente a poder hacer un seguimiento cercano de los avances delalumno.

Genera un espacio de intervención temprano en caso de que el alumno estétrabajando en algo que el cliente no desea para su producto.

Permite mantener un intercambio frecuente entre el alumno y el cliente fa-cilitando el desarrollo de una buena relación y disminuyendo la posibilidadde ocurrencia de malos entendidos.

5.2. Próximos pasos

Si bien prácticamente todas las funcionalidades requeridas para el trabajo fueroncubiertas, se puede listar una serie de modificaciones/mejoras a saber:

Portar la aplicación generada para Android hacia iOS valiéndose de las po-sibilidades ofrecidas por Ionic en relación al desarrollo de aplicaciones hí-bridas.

Completar la funcionalidad para el envío de emails de confirmación al crear-se una nueva cuenta en el sistema.

Mejorar el código de algunas funcionalidades de la aplicación de manerade facilitar el seguimiento y la trazabilidad.

Realizar más pruebas sobre la aplicación en dispositivos de distintos fabri-cantes y con diferentes versiones de Android.

Mejorar la interfaz gráfica de la aplicación.

Añadir encriptación a la base de datos.

Añadir funcionalidad de apertura utilizando alguna otra tecnología de cor-to alcance.

47

Bibliografía

[1] Asociación Española de Domótica e Inmótica. Qué es Domótica. Disponible:2021-11-01. URL:http://www.cedom.es/sobre-domotica/que-es-domotica.

[2] Wikipedia. Domótica. Disponible: 2021-11-01. URL:https://es.wikipedia.org/wiki/Dom%C3%B3tica.

[3] OneSpan. Autenticación biométrica. Disponible: 2021-11-08. URL:https://www.onespan.com/es/topics/autenticacion-biometrica.

[4] Kimaldi. RFID – Tecnología de identificación por radiofrecuencia. Disponible:2021-11-08. URL: https://www.kimaldi.com/rfid_tecnologia_de_identificacion_por_radiofrecuencia/.

[5] Wikipedia. Wifi. Disponible: 2021-11-08. URL:https://es.wikipedia.org/wiki/Wifi.

[6] Wikipedia. Bluetooth. Disponible: 2021-11-08. URL:https://es.wikipedia.org/wiki/Bluetooth.

[7] Teknohomes. Teknohomes. 2005. URL: https://teknohomes.com.ar (visitado01-11-2021).

[8] Cittyo. Cittyo. 2020. URL: https://cittyo.com/ (visitado 01-11-2021).[9] PSLocks. PSLocks. 2004. URL: https://www.pslocks.com.ar/ (visitado

01-11-2021).[10] Siccba. Siccba. 2020. URL: https://siccba.com.ar (visitado 06-11-2021).[11] Siccba. Visitado el 2021-11-06. 2020. URL:

https://siccba.com.ar/producto/control-de-accesos-siccba-tarjeta-teclado-y-app/.

[12] SURIX S.R.L. VoIPBell. Disponible: 2021-11-23. URL:https://www.surix.net/software-surix.html.

[13] Wikipedia. KiCad. Disponible: 2021-11-08. URL:https://es.wikipedia.org/wiki/KiCad.

[14] Wikipedia. Nordic Semiconductor. Disponible: 2021-11-23. URL:https://en.wikipedia.org/wiki/Nordic_Semiconductor.

[15] Oracle Corporation. Capa de aplicación. Disponible: 2021-11-08. URL:https://docs.oracle.com/cd/E19957-01/820-2981/ipov-22/index.html.

[16] MDN. HTML: Lenguaje de etiquetas de hipertexto. Disponible: 2021-11-08.URL: https://developer.mozilla.org/es/docs/Web/HTML.

[17] EcuRed. Cliente-Servidor. Disponible: 2021-11-08. URL:https://www.ecured.cu/Cliente-Servidor.

[18] IBM. Protocolos TCP/IP. Disponible: 2021-11-08. URL:https://www.ibm.com/docs/es/aix/7.2?topic=protocol-tcpip-protocols.

[19] Oracle Corporation. Capa de transporte. Disponible: 2021-11-08. URL:https://docs.oracle.com/cd/E19957-01/820-2981/ipov-19/index.html.

[20] Pamela Fox. Protocolo de datagrama de usuario (UDP). Disponible:2021-11-08. URL: https://es.khanacademy.org/computing/ap-computer-science-principles/the-internet/x2d2f703b37b450a3:transporting-

http://www.cedom.es/sobre-domotica/que-es-domotica

https://es.wikipedia.org/wiki/Dom%C3%B3tica

https://www.onespan.com/es/topics/autenticacion-biometrica

https://www.kimaldi.com/rfid_tecnologia_de_identificacion_por_radiofrecuencia/

https://www.kimaldi.com/rfid_tecnologia_de_identificacion_por_radiofrecuencia/

https://es.wikipedia.org/wiki/Wifi

https://es.wikipedia.org/wiki/Bluetooth

https://teknohomes.com.ar

https://cittyo.com/

https://www.pslocks.com.ar/

https://siccba.com.ar

https://siccba.com.ar/producto/control-de-accesos-siccba-tarjeta-teclado-y-app/

https://siccba.com.ar/producto/control-de-accesos-siccba-tarjeta-teclado-y-app/

https://www.surix.net/software-surix.html

https://es.wikipedia.org/wiki/KiCad

https://en.wikipedia.org/wiki/Nordic_Semiconductor

https://docs.oracle.com/cd/E19957-01/820-2981/ipov-22/index.html

https://developer.mozilla.org/es/docs/Web/HTML

https://www.ecured.cu/Cliente-Servidor

https://www.ibm.com/docs/es/aix/7.2?topic=protocol-tcpip-protocols

https://docs.oracle.com/cd/E19957-01/820-2981/ipov-19/index.html

https://es.khanacademy.org/computing/ap-computer-science-principles/the-internet/x2d2f703b37b450a3:transporting-packets/a/user-datagram-protocol-udp#:~:text=El%20Protocolo%20de%20datagrama%20de,o%20llegan%20fuera%20de%20orden.



48 Bibliografía

packets/a/user-datagram-protocol-udp#:~:text=El%20Protocolo%20de%20datagrama%20de,o%20llegan%20fuera%20de%20orden..

[21] MDN. HTML: Lenguaje de etiquetas de hipertexto. Disponible: 2021-11-08.URL: https://developer.mozilla.org/es/docs/Web/HTTP.

[22] GaussWebApp. Arquitectura REST: la arquitectura del momento. Disponible:2021-11-13. URL: https://gausswebapp.com/arquitectura-rest.html.

[23] Wikipedia. XML-RPC. Disponible: 2021-11-13. URL:https://es.wikipedia.org/wiki/XML-RPC.

[24] IBM Corporation. SOAP. Disponible: 2021-11-13. URL:https://www.ibm.com/docs/es/rsas/7.5.0?topic=standards-soap.

[25] Wikipedia. Roy Fielding. Disponible: 2021-11-13. URL:https://es.wikipedia.org/wiki/Roy_Fielding.

[26] The PHP Group. ¿Qué es PHP? Disponible: 2021-11-13. URL:https://www.php.net/manual/es/intro-whatis.php.

[27] Wikipedia. Licencia PHP. Disponible: 2021-11-13. URL:https://es.wikipedia.org/wiki/Licencia_PHP.

[28] Ionic Framework. Ionic Framework. Disponible: 2021-11-13. URL:https://ionicframework.com/docs.

[29] Angular. What is Angular? Disponible: 2021-11-13. URL:https://angular.io/guide/what-is-angular.

[30] Facebook Inc. Empezando. Disponible: 2021-11-13. URL:https://es.reactjs.org/docs/getting-started.html.

[31] Vue.js. Introduction. Disponible: 2021-11-13. URL:https://vuejs.org/v2/guide/.

[32] Ionic Framework. Capacitor: Cross-platform Native Runtime for Web Apps.Disponible: 2021-11-13. URL: https://capacitorjs.com/docs.

[33] The Apache Software Foundation. Overview. Disponible: 2021-11-13. URL:https://cordova.apache.org/docs/en/latest/guide/overview/index.html.

[34] Wikipedia. Android Studio. Disponible: 2021-11-23. URL:https://es.wikipedia.org/wiki/Android_Studio.

[35] Wikipedia. Intellij IDEA. Disponible: 2021-11-08. URL:https://es.wikipedia.org/wiki/IntelliJ_IDEA.

[36] Wikipedia. Apache License. Disponible: 2021-11-14. URL:https://es.wikipedia.org/wiki/Apache_License#Versi%C3%B3n_2.0.

[37] Wikipedia. Apache Software Foundation. Disponible: 2021-11-23. URL:https://es.wikipedia.org/wiki/Apache_Software_Foundation.

[38] The Apache Software Foundation. The Apache Software Foundation.Disponible: 2021-11-08. URL: https://www.apache.org/.

[39] Nordic Semiconductor. nRF52832. Disponible: 2021-11-08. URL:https://www.nordicsemi.com/products/nrf52832.

[40] Raytac. MDBT42Q-512KV2. Disponible: 2021-11-08. URL:https://www.raytac.com/product/ins.php?index_id=31.

[41] Microsoft. Microsoft. Disponible: 2021-11-08. URL:https://www.microsoft.com/es-ar.

[42] Microsoft. sqlcmd Utility. Disponible: 2021-11-23. URL:https://docs.microsoft.com/en-us/sql/tools/sqlcmd-utility?view=sql-server-ver15.

[43] Microsoft. osql Utility. Disponible: 2021-11-23. URL:https://docs.microsoft.com/en-us/sql/tools/osql-utility?view=sql-server-ver15.




https://developer.mozilla.org/es/docs/Web/HTTP

https://gausswebapp.com/arquitectura-rest.html

https://es.wikipedia.org/wiki/XML-RPC

https://www.ibm.com/docs/es/rsas/7.5.0?topic=standards-soap

https://es.wikipedia.org/wiki/Roy_Fielding

https://www.php.net/manual/es/intro-whatis.php

https://es.wikipedia.org/wiki/Licencia_PHP

https://ionicframework.com/docs

https://angular.io/guide/what-is-angular

https://es.reactjs.org/docs/getting-started.html

https://vuejs.org/v2/guide/

https://capacitorjs.com/docs

https://cordova.apache.org/docs/en/latest/guide/overview/index.html

https://cordova.apache.org/docs/en/latest/guide/overview/index.html

https://es.wikipedia.org/wiki/Android_Studio

https://es.wikipedia.org/wiki/IntelliJ_IDEA

https://es.wikipedia.org/wiki/Apache_License#Versi%C3%B3n_2.0

https://es.wikipedia.org/wiki/Apache_Software_Foundation

https://www.apache.org/

https://www.nordicsemi.com/products/nrf52832

https://www.raytac.com/product/ins.php?index_id=31

https://www.microsoft.com/es-ar

https://docs.microsoft.com/en-us/sql/tools/sqlcmd-utility?view=sql-server-ver15

https://docs.microsoft.com/en-us/sql/tools/sqlcmd-utility?view=sql-server-ver15

https://docs.microsoft.com/en-us/sql/tools/osql-utility?view=sql-server-ver15

https://docs.microsoft.com/en-us/sql/tools/osql-utility?view=sql-server-ver15

Bibliografía 49

[44] Wikipedia. PowerShell. Disponible: 2021-11-23. URL:https://es.wikipedia.org/wiki/PowerShell.

[45] Wikipedia. Microsoft .NET. Disponible: 2021-11-23. URL:https://es.wikipedia.org/wiki/Microsoft_.NET.

[46] Oracle. ¿Qué es el big data? Disponible: 2021-11-23. URL:https://www.oracle.com/ar/big-data/what-is-big-data/.

[47] Lucidchart. Qué es el lenguaje unificado de modelado (UML). Disponible:2021-11-13. URL: https://www.lucidchart.com/pages/es/que-es-el-lenguaje-unificado-de-modelado-uml.

[48] W3Schools. SQL FOREIGN KEY Constraint. Disponible: 2021-11-13. URL:https://www.w3schools.com/sql/sql_foreignkey.asp.

[49] Krasimir Hristozov. Build a Simple REST API in PHP. Disponible:2021-11-13. URL:https://developer.okta.com/blog/2019/03/08/simple-rest-api-php.

[50] Auth0. Introduction to JSON Web Tokens. Disponible: 2021-11-08. URL:https://jwt.io/introduction.

[51] Nordic Semiconductor Playground. nRF52 Bluetooth Course. Disponible:2021-11-13. URL:https://github.com/NordicPlayground/nRF52-Bluetooth-Course.

[52] MartinBL. Bluetooth low energy Services, a beginner’s tutorial. Disponible:2021-11-13. URL: https://devzone.nordicsemi.com/guides/short-range-guides/b/bluetooth-low-energy/posts/ble-services-a-beginners-tutorial.

[53] SEGGER. J-Link Debug Probes. Disponible: 2021-11-13. URL:https://www.segger.com/products/debug-probes/j-link/.

[54] Wikipedia. JTAG. Disponible: 2021-11-13. URL:https://es.wikipedia.org/wiki/JTAG.

[55] NORDIC Semiconductor. nRF Connect for Mobile. Disponible: 2021-11-13.URL: https://www.nordicsemi.com/Products/Development-tools/nRF-Connect-for-mobile.

[56] Motorola. motog8plus. Disponible: 2021-11-13. URL:https://www.motorola.es/smartphones-moto-g-plus-gen-8/p.

[57] Alejandro López. Qué es Postman y para qué sirve. Disponible: 2021-11-13.URL: https://openwebinars.net/blog/que-es-postman/.

https://es.wikipedia.org/wiki/PowerShell

https://es.wikipedia.org/wiki/Microsoft_.NET

https://www.oracle.com/ar/big-data/what-is-big-data/

https://www.lucidchart.com/pages/es/que-es-el-lenguaje-unificado-de-modelado-uml

https://www.lucidchart.com/pages/es/que-es-el-lenguaje-unificado-de-modelado-uml

https://www.w3schools.com/sql/sql_foreignkey.asp

https://developer.okta.com/blog/2019/03/08/simple-rest-api-php

https://jwt.io/introduction

https://github.com/NordicPlayground/nRF52-Bluetooth-Course

https://devzone.nordicsemi.com/guides/short-range-guides/b/bluetooth-low-energy/posts/ble-services-a-beginners-tutorial

https://devzone.nordicsemi.com/guides/short-range-guides/b/bluetooth-low-energy/posts/ble-services-a-beginners-tutorial

https://www.segger.com/products/debug-probes/j-link/

https://es.wikipedia.org/wiki/JTAG

https://www.nordicsemi.com/Products/Development-tools/nRF-Connect-for-mobile

https://www.nordicsemi.com/Products/Development-tools/nRF-Connect-for-mobile

https://www.motorola.es/smartphones-moto-g-plus-gen-8/p

https://openwebinars.net/blog/que-es-postman/

id mobile - sistema de identificación personal para

Documents