Punku, control de...

CARRERA DE ESPECIALIZACIÓNEN SISTEMAS EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Punku, control de accesos

Autor:Ing. Esteban Daniel Volentini

Director:Ing. Juan Manuel Cruz (FIUBA, UTN-FRBA)

Jurados:Esp. Ing. Eric Pernia (FIUBA, UNQ)

Esp. Ing. Diego Brengi (INTI)Esp. Ing. Alejandro Permingeat (FIUBA, USAT-Motion)

Este trabajo fue realizado en la Ciudad de San Miguel de Tucumán,entre marzo de 2019 y marzo de 2020.

III

Resumen

El presente documento describe el desarrollo de Punku, un equipo destinado acontrolar el acceso en una puerta utilizando tarjetas de proximidad. Surge por la

necesidad de la empresa EQUISER de renovar un equipo existente que hoyresulta obsoleto por los avances de la tecnología. Se espera que el producto

desarrollado brinde más funcionalidad con un costo de fabricación menor al delequipo actual.

El proyecto de desarrollo incluyó la especificación de requisitos, la definición delas pruebas de aceptación, el diseño del hardware contemplando la producción

en escala y el desarrollo del firmware utilizando un sistema operativo de tiemporeal. Para verificar el correcto funcionamiento del equipo se realizaron pruebas

unitarias y de integración automatizadas.

V

Agradecimientos

Al todo el claustro de la EITI, y en especial a Sergio Saade, por el apoyo brindadopara completar esta carrera especialización.

VII

Índice general

Resumen III

1. Introducción General 11.1. Descripción del problema . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Introducción Específica 72.1. Tarjetas de proximidad . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2. Aplicaciones para dispositivos móviles . . . . . . . . . . . . . . . . 82.3. Protocolos inalámbricos . . . . . . . . . . . . . . . . . . . . . . . . . 92.4. Características del equipo . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.1. Requisitos específicos . . . . . . . . . . . . . . . . . . . . . . 112.4.2. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.3. Pruebas de aceptación . . . . . . . . . . . . . . . . . . . . . . 20

3. Diseño e Implementación 273.1. Diseño del hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2. Prototipo del hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3. Diseño del firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1. Arquitectura del firmware . . . . . . . . . . . . . . . . . . . . 303.3.2. Capa de abstracción del hardware . . . . . . . . . . . . . . . 333.3.3. Capa de controladores . . . . . . . . . . . . . . . . . . . . . . 333.3.4. Tareas del sistema . . . . . . . . . . . . . . . . . . . . . . . . 37

3.4. Desarrollo del firmware . . . . . . . . . . . . . . . . . . . . . . . . . 443.4.1. Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . 443.4.2. Pruebas de integración en las tareas del sistema . . . . . . . 463.4.3. Uso del tipo de abstracto de datos . . . . . . . . . . . . . . . 46

4. Ensayos y Resultados 494.1. Pruebas de concepto . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2. Pruebas funcionales del hardware . . . . . . . . . . . . . . . . . . . 504.3. Pruebas unitarias y de integración . . . . . . . . . . . . . . . . . . . 524.4. Resultado de las pruebas . . . . . . . . . . . . . . . . . . . . . . . . . 53

5. Conclusiones 555.1. Resultados Obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . . 555.2. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Bibliografía 57

IX

Índice de figuras

1.1. Diagrama de bloques del equipo actual . . . . . . . . . . . . . . . . 31.2. Fotografía del equipo actual . . . . . . . . . . . . . . . . . . . . . . . 3

3.1. Diagrama de bloques del equipo desarrollado . . . . . . . . . . . . 283.2. Modelo tridimensional de la placa electrónica . . . . . . . . . . . . . 293.3. Problemas con la máscara antisoldante del prototipo . . . . . . . . . 303.4. Diagrama de componentes del firmware del equipo . . . . . . . . . 313.5. Diagrama de clases del firmware del equipo . . . . . . . . . . . . . 323.6. Diagrama de estados con cerradura electromagnética y sin sensor . 343.7. Diagrama de estados con cerradura electromagnética y sensor . . . 343.8. Diagrama de estados con cerradura motorizada y sin sensor . . . . 353.9. Diagrama de estados con cerradura motorizada y sensor . . . . . . 363.10. Apertura por pulsador con cerradura electromagnética y sin sensor 383.11. Liberación por pulsador con cerradura electromagnética y sensor . 403.12. Apertura por pulsador con cerradura electromagnética y sensor . . 413.13. Liberación por lectura de una tarjeta de proximidad. . . . . . . . . . 423.14. Detalle de interacción clases Sonido y Bitacora. . . . . . . . . . . . . 43

4.1. Montaje utilizado para las pruebas de concepto . . . . . . . . . . . . 494.2. Errores detectados durante el montaje del prototipo . . . . . . . . . 514.3. Error en la asignacion de terminales del RTC . . . . . . . . . . . . . 514.4. Informe con la cobertura de las pruebas . . . . . . . . . . . . . . . . 52

XI

Índice de Tablas

1.1. Cuadro comparativo con otros equipos del mercado . . . . . . . . . 4

2.1. Tarjetas de proximidad más utilizadas en el control de accesos . . . 82.2. Comparación entre los protocolos Bluetooth y WiFi . . . . . . . . . 102.3. Resumen de los modos de funcionamiento del equipo . . . . . . . . 122.4. Caso de uso acceso por pulsador . . . . . . . . . . . . . . . . . . . . 172.5. Caso de uso acceso por tarjeta de proximidad . . . . . . . . . . . . . 182.6. Caso de uso configuración del equipo . . . . . . . . . . . . . . . . . 192.7. Caso de uso gestión de las personas autorizadas . . . . . . . . . . . 192.8. Caso de uso consulta de la bitácora de accesos . . . . . . . . . . . . 20

3.1. Herramientas utilizadas para el desarrollo del firmware . . . . . . . 45

4.1. Metricas de documentación y pruebas . . . . . . . . . . . . . . . . . 53

5.1. Cuadro comparativo con otros equipos del mercado . . . . . . . . . 56

XIII

Dedicado a Adriana, Nicolas, Lucas y Sofíaque me apoyaron incondicionalmente en este desafío.

1

Capítulo 1

Introducción General

En el presente capítulo se presentan brevemente diferentes equipos para controlde accesos, las tecnologías de identificación utilizadas por los mismos, los moti-vos que condujeron al desarrollo del trabajo junto con los objetivos y alcances delmismo.

1.1. Descripción del problema

El control de las personas que acceden a un ambiente es una de las aplicacionesque más se beneficiaron con los avances de la electrónica. El cambio de las cerra-duras mecánicas, y sus correspondientes llaves, por sistemas electrónicos llevamás de 30 años y continúa en plena expansión. Actualmente existe en el mercadouna oferta muy amplia y variada de equipos, que utilizan diferente medios paraidentificar a las personas que intentan acceder. Los métodos de identificación másdifundidos en la actualidad son:

Clave numérica: para la identificación de cada usuario se le asigna una clavenumérica que se debe ingresar mediante un teclado que forma parte delequipo. Este esquema es el más económico pero también el más inseguro,ya que la clave puede fácilmente darse a conocer a personas no autorizadas.

Tarjetas de proximidad: para la identificación del portador se utilizan unossistemas electrónicos que se alimentan al aproximarlos a un lector y trans-miten información. Las tarjetas en realidad pueden adoptar otros formatoscomo llaveros o etiquetas autoadhesivas. Este esquema resulta más costosopero también más seguro que el anterior ya que las tarjetas no pueden repli-carse fácilmente, aunque sí es posible prestarlas a personas no autorizadas.

Reconocimiento de huella digital: para la identificación se toma una imagende un dedo del usuario y se reconoce la geometría de las huellas digitales.Este esquema es el más costos y seguro de todos, ya que duplicar una huelladigital es una tarea realmente compleja.

Independientemente del medio utilizado para la identificación del usuario, todoslos equipos tienen una forma de operación y configuración similar, la que puedeser clasificada en tres grandes grupos:

Equipos autónomos: son los más económicos y fáciles de instalar, ya quesolo requieren alimentación y la conexión con el mecanismo que libera lapuerta para permitir el acceso. Dentro de este grupo podemos encontrarincluso equipos que se integran dentro de una cerradura tradicional y se

2 Capítulo 1. Introducción General

alimentan con baterías, lo que simplifica al máximo su instalación. La prin-cipal desventaja de este tipo de equipos es la gestión de las personas au-torizadas a ingresar. En general estos equipos integran unos teclados muybásicos con los que se pueden agregar y borrar las personas autorizadasmediante secuencias de códigos numéricos bastante poco amigables con losusuarios finales.

Equipos en línea: son los más seguros pero también los más costos y com-plejos de instalar. Estos equipos incorporan una interfaz de comunicacio-nes para validar cada operación de acceso con un servidor central en tiem-po real. De esta forma, la gestión de las personas autorizadas se realiza enforma centralizada sobre dicho servidor mediante un programa informáti-co mucho más simple de utilizar. Este esquema puede, además, incorporarmayor complejidad en las validaciones efectuadas para autorizar el ingre-so de una persona. La principal desventaja de este esquema es que resultamuy sensible a una falla en la red de comunicaciones o en el servidor deautorizaciones.

Equipos gestionados: son equipos autónomos que incorporan una interfazde comunicaciones para permitir su gestión en una forma más simple. Enmuchos casos son equipos que pueden además operar en línea. Podría pen-sarse que estos equipo combinan las desventajas de los dos anteriores, peroesto no es verdad. Si bien el costo es mayor que el de un equipo autónomo,no requiere toda la infraestructura de los equipos que operan en línea, loque disminuye significativamente el costo total de la solución. A cambio deese aumento en el costo permiten una gestión más simple, ya que es posibleutilizar una computadora con un software amigable.

Como se desprende del análisis anterior, resulta muy difícil encontrar un equi-po adecuado para el mercado hogareño o de pequeñas oficinas. A pesar de quela oferta del mercado es muy amplia, no existen muchos equipos que combinenadecuadamente las características de precio con la facilidad de instalación y ges-tión necesarias en un ambiente donde el usuario final posee conocimientos técni-cos muy limitados. Por estas razones la mayoría de los equipos destinados a estemercado corresponden al grupo de los equipos gestionados. Sin embargo, la ma-yoría de ellos utilizan interfaces de comunicaciones cableadas, las que complicanla instalación y permiten la gestión únicamente desde una computadora.

1.2. Motivación

Punku nace como una propuesta de la firma EQUISER para resolver el problemadel control de accesos en hogares, pequeñas oficinas, consorcios de departamen-tos y cocheras[1]. Las características más importantes de este mercado son la po-ca cantidad de puertas controladas, falta de personal técnico para la gestión delequipo, y en el caso de los consorcios y cocheras, frecuentes cambios en la listade personas autorizadas. Para lograr la mejor relación entre seguridad, precio yfacilidad de gestión, el equipo puede funcionar con tarjetas de proximidad o concontroles remotos. Además utiliza una interfaz Bluetooth que permite gestionarlodesde un dispositivo móvil, ya sea una computadora portátil, un teléfono celu-lar inteligente o una tableta. También incorpora una entrada para un sensor que

1.2. Motivación 3

permite detectar la apertura de la puerta, y una salida de alarma para informarcuando permanece abierta más tiempo del especificado.

En la figura 1.1 se presenta el diagrama de bloques del equipo, donde se puedenobservar dos unidades funcionales:

ComunicaciónBluetooth

Fuente dealimentación

Entradas ysalidas

Almacenamiento

MicrocontroladorMicrocontrolador

Base station RF

Destrabapestillo

Lector de proximidad

Puerta Procesador

Usuario Celular

FIGURA 1.1: Diagrama de bloques del equipo actual

La lectora de proximidad: es la responsable de generar el campo magnéticoque alimenta a las tarjetas y decodificar la información enviada por estas.

El procesador: es el responsable de determinar si la tarjeta leída puede ono acceder, registrar los movimientos de acceso, accionar las salidas paraautorizar el ingreso, supervisar el estado de la puerta y comunicarse con elequipo móvil para permitir gestionar su configuración.

Como puede notarse en figura 1.2, donde puede ver una imagen del equipo ac-tual, cada una de estas unidades funcionales se encuentra alojada en un gabineteindependiente. De esta manera la lectora de proximidad se puede instalar del la-do externo de la puerta y el procesador del lado interno, evitando la manipulacióndel cableado para forzar la apertura de la puerta.

FIGURA 1.2: Fotografía del equipo actual

En la tabla 5.1 se puede ver un cuadro comparativo del producto actual con otrosequipos existentes en el mercado. Como se puede observar, la oferta se polariza


en dos tipos de equipos: totalmente autónomos gestionados mediante un tecladonumérico muy limitado o equipos con conexiones cableadas (ethernet o usb) quesolo pueden ser gestionados desde computadoras de escritorio o portátiles. Enel mercado internacional sí existen equipos que se pueden gestionar desde undispositivo móvil, pero tampoco en este escenario la oferta es abundante. Porestas razones Punku constituye una solución atractiva que busca imponerse enel mercado principalmente gracias a la facilidad de manejo por parte del usuariofinal.

TABLA 1.1: Cuadro comparativo con otros equipos del mercado

Equipo Tecnología Forma de gestión Valor

EQUISERPunku

Proximidad yremotos RF

Gestionado desde uncelular usando Bluetooth

$ 15.000

Tebas208NW [2]

ProximidadTeclado numérico

integrado en el equipo$ 4.000

ZKMA300IS [3]

Proximidady huellas

Computadora conectadamediante Ethernet

$ 10.000

ANVIZT5 Pro [4]

Proximidady huellas

Computadora conectadamediante Ethernet o USB

$ 8.000

La versión de Punku que se produce actualmente cubre adecuadamente las ne-cesidades del mercado al cual está destinado. Sin embargo el diseño del equipose remonta al año 2013, y los cambios en las tecnologías sumados a nuevas po-sibilidades de uso demandaban una actualización. Después de un análisis de lasfortalezas y debilidades del equipo se determinó que era necesario realizar lassiguientes mejoras:

Cambio del procesador principal: para el desarrollo original se utilizó unmicrocontrolador producido por la empresa Freescale, perteneciente la fa-milia ColdFire[5]. Con el avance de los procesadores Cortex el fabricante fuedejando de lado el desarrollo de esta gama de productos, por lo que en estemomento el microcontrolador utilizado resulta más costoso que un procesa-dor más nuevo con mayores prestaciones. Lamentablemente no existe unaoferta por parte del fabricante de un microcontrolador con una disposiciónde terminales pensada para efectuar un reemplazo directo del utilizado ac-tualmente.

Cambio de la interfaz de comunicaciones: el equipo actual utiliza para lacomunicación una interfaz Bluetooth 2. Poco tiempo después del desarrollose aprobó la versión 4 de este protocolo, la que fue rápidamente adoptadopor la firma Apple. Esta nueva versión del protocolo no es compatible conla anterior, y si bien algunos equipos pueden funcionar en ambos modos detrabajo, este no es el caso de los equipos iPhone, donde para privilegiar laduración de la batería solo pueden operar con Bluetooth 4.

Incorporación de un reloj: al comercializar las primeras unidades surgió elrequerimiento de algunos clientes para disponer de un registro de accesocon fecha y hora de cada evento. El equipo actual no dispone de un RTC(Real Time Clock) que le permita mantener la fecha y hora cuando no dis-pone de alimentación eléctrica. De esta forma, si bien el equipo registra los

1.3. Objetivos y alcance 5

eventos con fecha y hora, se vuelve a una fecha inicial preestablecida cadavez que se reinicia, y es necesaria una comunicación desde el celular parareajustar el reloj interno. El resultado es que la mayoría de los registros deaccesos no tienen una fecha y hora válidas.

Soporte para cerraduras motorizadas: uno de los principales obstáculos enla instalación de equipos para el control de accesos en el mercado al cualestá destinado Punku, son los cortes de alimentación eléctrica. Según el ti-po de cerradura que se utilice, ante una falla de energía la puerta quedarácerrada y no se podrá acceder, o peor aún, quedará abierta en forma perma-nente. Una solución a este problema es combinar una cerradura con llavey un sistema motorizado que permita la liberación y el bloqueo de la puer-ta por cualquiera de los medios. Para esto el equipo debe poder invertir laalimentación en la salida que controla al motor, y de esta forma liberar obloquear el mecanismo en función del sentido de giro de este.

Gestión desde la nube: con el avance en la conectividad a Internet se volviómás común disponer de equipos que pueden ser gestionados en forma re-mota. En el caso de un control de accesos siempre resulta atractiva la posibi-lidad de cambiar el permiso de acceso de una persona en forma inmediatasin necesidad de estar cerca del equipo. El uso de Bluetooth como inter-faz de comunicaciones resulta un obstáculo para esta funcionalidad por sucorto alcance y porque nunca se popularizaron equipos equivalentes a losrouters de WiFi que permitan el acceso a Internet utilizando Bluetooth.

1.3. Objetivos y alcance

El objetivo general del trabajo desarrollado fue el diseño y la implementación delprototipo de una nueva versión del equipo para control de accesos Punku queresolviera los problemas mencionados en la sección 1.2.

Los objetivos particulares definidos para este fueron:

1. Diseñar el nuevo equipo utilizando un módulo de la familia ESP32 [6] delfabricante Espressif, el cual incorpora interfaces de comunicación WiFi yBluetooth en las versiones 2 y 4.

2. Agregar al nuevo equipo un circuito integrado RTC con respaldo de bateríaque le permita mantener la fecha y hora válidas, aun cuando se produzcaninterrupciones en el suministro de energía eléctrica.

3. Agregar al nuevo equipo la posibilidad de invertir la polaridad de alimen-tación en la salida que libera la cerradura de forma tal que se pueda utilizarun sistema motorizado para destrabar la puerta.

4. Mantener las características generales del equipo actual en el nuevo diseño,tratando en lo posible de mejorar aún más la facilidad de gestión del equipoy de disminuir su costo.

5. Desarrollar el firmware del equipo desde cero, utilizando un sistema ope-rativo de tiempo real y un diseño modular que permita escalar las funcio-nalidades del equipo.


El resultado esperado es entonces un prototipo totalmente funcional, que incor-pore las mejoras ya mencionadas, acompañado de la siguiente documentación:

1. Diagrama esquemático del equipo en el programa KiCad.

2. Diseño de la placa electrónica realizada en el programa KiCad.

3. Especificación de requisitos del firmware según el estándar IEEE-830.

4. Arquitectura y el diseño detallado del firmware modelado utilizando dia-gramas UML.

5. Pruebas de aceptación para validar el correcto funcionamiento del equipoescritas en metalenguaje Gherkin.

6. Código fuente del firmware para el control del equipo con documentacióny comentarios adecuados que faciliten su compresión.

7

Capítulo 2

Introducción Específica

En el presente capítulo se abordan en mayor profundidad las distintas tecnolo-gías utilizadas en el equipo. A continuación se detallan los requisitos y casos deuso relevados, junto a las pruebas de aceptación definidas para validar el correc-to funcionamiento del prototipo. Por último se presenta en forma abreviada laplanificación del proyecto efectuada oportunamente.

2.1. Tarjetas de proximidad

La identificación por radiofrecuencia o RFID (Radio Frecuency Identification) es unatecnología que permite el intercambio de información sin contacto entre un equi-po lector y un dispositivo de almacenamiento denominado transpondedor[7].También denominados etiquetas RFID, estos dispositivos pueden ser activos sicuentan con alimentación propia, o pasivos si se alimentan del campo electro-magnético generado por el equipo lector.

En el ámbito de los sistemas para el control de accesos, la mayoría de las eti-quetas RFID son pasivas y adoptan la forma de una tarjeta plástica, un llaveroo una etiqueta autoadhesiva que contiene el chip electrónico junto con la bobinaque cumple la función de antena receptora y transmisora. Las distancias de lec-tura generalmente son del orden de los 10 centímetros, pero pueden extendersehasta los 15 metros en los sistemas desarrollados para control de vehículos. En elmercado actual de Argentina podemos encontrar, principalmente, cuatro tipos detarjetas de proximidad:

Tarjetas EM4100: son las más económicas y muy difundidas en el control deaccesos. Desarrolladas originalmente por la empresa E&M Marine[8], fue-ron ampliamente copiadas por los fabricantes chinos. Estas tarjetas operancon una portadora de 125 KHz, la que modulan en amplitud para transmi-tir una trama fija de 64 bits, que encapsula un número de serie de 24 bitsprefijado durante la fabricación.

Tarjetas HID: son el grupo menos difundido en nuestro país, principalmen-te por el costo y dificultad para adquirirlas. Estas tarjetas operan tambiéncon una portadora de 125 KHz, pero la modulan en frecuencia. Tambiéntransmiten una trama fija que encapsula un número de serie definido en elproceso de fabricación, pero en este caso existen tres variantes de longitud:24, 36 o 37 bits[9].

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

Tarjetas MIFARE: son las utilizadas por los sistemas de monederos elec-trónicos y pagos de pasajes en el transporte público de pasajeros. Fuerondesarrolladas originalmente por la empresa Philips Semiconductors y hoyson mantenidas por NXP Semiconductors[10]. Estas tarjetas tienen la capa-cidad de proteger la memoria utilizando un par de claves criptográficas, deesta manera pueden impedir la lectura o escritura por parte de equipos noautorizados. Se encuentran comprendidas dentro de la norma emitida porla ISO (Organización Internacional de Normalización) para regular la operaciónde tarjetas de proximidad ISO 14443[11].

Tarjetas UHF: son las utilizadas en los sistemas de telepeaje y para con-trol vehicular, porque pueden alcanzar distancias de lecturas de hasta 15metros. Estas tarjetas también tienen la capacidad de proteger la memoriautilizando criptografía para impedir la lectura o escritura por parte de equi-pos no autorizados. Se encuentran normalizadas por la ISO para regular laoperación de tarjetas sin contacto de largo alcance en la norma ISO 18000-6C[12].

En la tabla 2.1 se puede observar la comparación entre los distintos tipos de tar-jetas de proximidad utilizadas en los sistemas para control de accesos. De estasopciones se decidió que el nuevo equipo opere con el estándar MIFARE, lo quepermite utilizar todas las tarjetas de pago electrónico para el transporte públicocomo medio de identificación y acceso, disminuyendo de esta forma la inversióninicial de la instalación.

TABLA 2.1: Cuadro comparativo con las tarjetas de proximidadmás utilizadas para el control de accesos

Nombre Frecuencia Distancia Capacidades

EM4100 125 KHz / ASK 10 a 15 cm Solo lecturaHID 125 KHz / FSK 10 a 15 cm Solo lectura

MIFARE 15.56 KHz /ASK 10 a 30 cm Lectura/EscrituraUHF 850 a 915 MHz /ASK Hasta 15 m Lectura/Escritura

2.2. Aplicaciones para dispositivos móviles

La elección del modelo de comunicación que se utilizará para la gestión del equi-po tiene gran impacto en las herramientas y complejidad de la aplicación deldispositivo móvil. Por eso, aunque el desarrollo de la misma está fuera de los al-cances del trabajo, es importante realizar un análisis de las posibles estrategias deimplementación.

El mercado de los dispositivos móviles se encuentra polarizado en dos sistemasoperativos: Android e iOS. Lamentablemente las herramientas de desarrollo e in-cluso los lenguajes utilizados por cada plataforma son totalmente incompatibles,esto significa que desarrollar una aplicación que se encuentre disponible paraambas plataformas requiere el doble de esfuerzo.

Una solución a este problema son las denominadas aplicaciones híbridas[13], lascuales en realidad son páginas WEB encapsuladas con el correspondiente navega-dor de cada plataforma en una aplicación nativa[Frameworks]. Estas aplicaciones

2.3. Protocolos inalámbricos 9

se desarrollan entonces en JavaScript y uno de los entornos más difundidos paraconstruir este tipo de aplicaciones es el conjunto Ionic Cordoba[14], el cual permi-te desarrollar una aplicación para móviles utilizando exclusivamente tecnologíaWEB.

Dado que en realidad estas aplicaciones son páginas WEB tienen una serie derestricciones, principalmente en las comunicaciones que pueden realizar y en lainteracción con los dispositivos integrados en el equipo móvil, como la cámarade fotos o el micrófono. Algunas de estas restricciones son resueltas utilizandoplugins, fragmentos de código nativo escrito para cada plataforma que funcionana modo de adaptador para que la página WEB pueda acceder a estos servicios.

La forma más natural de comunicación para este tipo de aplicaciones es utilizan-do el protocolo HTTP (HyperText Transfer Protocol)[15]. Este define un conjunto depeticiones, que permiten al cliente efectuar operaciones sobre recursos del servi-dor[16]. Originalmente el protocolo HTTP operaba sobre archivos almacenadosen el servidor, pero con el tiempo, el concepto de recurso se fue extendiendo. Enla actualidad este protocolo se utiliza ampliamente para crear, modificar, consul-tar y eliminar objetos virtuales como la configuración de un equipo o, en nuestrocaso, la lista de personas autorizadas.

Se denomina API (Application Programming Interface)[17] al conjunto de funcionesy procedimientos que una biblioteca pone a disposición para que otro programapuede operar sobre ella. En el caso de este equipo, sería el conjunto de funcio-nes que el firmware pone a disposición de la aplicación móvil para gestionarlo.Esta interfaz se denomina API REST (REpresentational State Transfer) cuando seencuentra desarrollada como un conjunto de recursos que pueden ser accedidosutilizando el protocolo HTTP. En estas interfaces la transferencia de informaciónse realiza utilizando el formato JSON(JavaScript Object Notation)[18], que es unaforma simple de codificar información en cadenas de texto.

2.3. Protocolos inalámbricos

El aumento del uso de dispositivos móviles con un poder de cómputo cada vezmayor por parte del público abre la puerta a nuevas aplicaciones para estos equi-pos. En particular para este trabajo, la intención es utilizar un dispositivo móvilcomo un teléfono inteligente o una tableta, con el fin de gestionar y configurarel equipo para control de accesos. Por esta razón es necesario que la interfaz decomunicaciones implementada sea del tipo inalámbrico, ya que si bien es técni-camente posible utilizar una interfaz USB cableada para conectarse a la mayoríade los teléfonos o tabletas, esta opción no resultaría cómoda ni comercialmenteatractiva. En la actualidad existen dos protocolos de comunicación inalámbricosque dominan el mercado:

Bluetooth: es un protocolo diseñado para una red de área personal, con unalcance típico de 10 metros, con bajas tasas de transferencias y optimizadopara extender la duración de las baterías[19]. Existen dos versiones princi-pales de este protocolo: la versión 2 y la 4, las cuales no son compatiblesentre sí. La mayoría de los dispositivos móviles actuales soportan ambasversiones del protocolo, excepto todos los equipos móviles de la firma Ap-ple, que solo soportan la versión 4 de bajo consumo. En este protocolo la


conexión se realiza entre un maestro y un esclavo, y si bien teóricamente sepueden generar redes de dispositivos, en la práctica esto nunca se imple-menta.

WiFi: es un protocolo diseñado para una red de área local, con un alcancetípico de 100 metros y altas tasas de transferencias[20]. Existen varias ver-siones de este protocolo, las cuales se pueden agrupar en dos familias: lasque utilizan una portadora de 2.4 GHz y las de 5 GHz. Las versiones másnuevas pueden utilizar ambas frecuencias simultáneamente para aumentaraún más el ancho de banda. En este protocolo la conexión se realiza general-mente entre un dispositivo y un punto de acceso, que normalmente brindaconexión con una red mayor y eventualmente con Internet.

En la tabla 2.2 se puede ver un resumen con las características más importantes delas diferentes variantes de ambos protocolos de comunicación. Para el desarrollodel equipo se decidió utilizar WiFi, porque resulta igual de sencillo establecer unaconexión punto a punto entre el dispositivo móvil y el equipo que se quiere ges-tionar, como conectarlo a la red existente en el lugar y gestionarlo desde cualquierubicación que tenga conexión con dicha red. Incluso es posible, en un futuro, elacceso del equipo a Internet, lo que permitiría su gestión desde cualquier lugardel mundo.

TABLA 2.2: Cuadro comparativo entre las diferentes variantes delos protocolos WiFi y Bluetooth

Nombre Alcance Frecuencia Velocidad

Bluetooth 2.0 10 metros 2,4 GHz 2 MBits/sBLE 10 metros 2,4 GHz 2 MBits/s

Wifi 802.11a 100 metros 5 GHz 54 MBits/sWifi 802.11b 100 metros 2,4 GHz 11 MBits/sWifi 802.11g 100 metros 2,4 GHz 54 MBits/sWifi 802.11n 100 metros 2,4 y 5 GHz 600 MBits/s

La utilización de WiFi resulta más conveniente ya que facilita el uso del conjuntode protocolos TPC/IP y disponer de un servidor HTTP estándar. De esta forma sepuede implementar una API REST que, como se explicó en la sección 2.2, simpli-ficará la comunicación con aplicaciones híbridas para celulares y páginas WEB.Esta elección también permite que, en un futuro, el equipo se conecte directamen-te a Internet, y de esta forma gestionarlo desde cualquier lugar del mundo.

2.4. Características del equipo

Dado que el objetivo del trabajo fue el diseño de un equipo comercial, se plan-teó la necesidad de permitir que pueda adaptarse a diferentes instalaciones. Laprimera de las opciones de instalación corresponde al tipo de dispositivo que seutiliza para impedir la apertura de la puerta. En este apartado podemos encontrardos opciones:

Destraba pestillo eléctrico: es un sistema mecánico que actúa como trabapara el pestillo de la puerta. Este se libera al energizar una bobina y quepor la acción de un resorte vuelve a bloquearse automáticamente cuando

2.4. Características del equipo 11

se retira la energía eléctrica. De esta forma, mientras el mismo permaneceenergizado, es posible abrir la puerta.

Cerradura electromagnética: es simplemente un electroimán que al ser ali-mentado ejerce una fuerza que impide la apertura de la puerta. En este caso,la puerta puede abrirse únicamente cuando la cerradura permanece sin ali-mentación.

Cerradura motorizada: en este caso el sistema mecánico de bloqueo es ac-cionado por un motor en lugar de una bobina. Para liberar la puerta esnecesario alimentar el motor con una determinada polaridad por un cier-to tiempo, o hasta que acciona un sensor que detecta el final del recorridodel mecanismo. La puerta permanece liberada hasta que se alimenta el mo-tor con la polaridad contraria durante un tiempo determinado, o hasta quese acciona un nuevo sensor que detecta el final del recorrido en el sentidocontrario al inicial.

Como se puede deducir de la descripción anterior, cada tipo de cerradura re-quiere una señal de control diferente. En particular la mayor diferencia está dadaentre los sistemas electromecánicos y los motorizados, debido a la necesidad deuna inversión en la alimentación para efectuar el bloqueo de la puerta.

La otra opción de instalación que podrá definir el usuario final corresponde aluso de un sensor para detectar la apertura de la puerta. En el diseño del equipose contempla la posibilidad de utilizar este sensor para poder determinar si unapersona autorizada ingresa al espacio controlado, y además informar medianteuna señal de alarma cuando la puerta permanece abierta más tiempo del ade-cuado. Un análisis rápido muestra claramente que el comportamiento del equipodebe ser diferente cuando el usuario decide no instalar el sensor para determinarla apertura de la puerta.

La combinación de las dos opciones antes analizadas determina cuatro modos defuncionamiento principales, los cuales se resumen en la tabla 2.3.

2.4.1. Requisitos específicos

Uno de los primeros puntos que detalla el estándar IEEE-830[21][22] para espe-cificación de requisitos son las interfaces externas de la aplicación. Dado que eldesarrollo analizado corresponde al firmware de un sistema embebido, las inter-faces del software tienen relación directa con las entradas y salidas de la placaelectrónica. A continuación se listan los puertos de conexiones que debe imple-mentar el nuevo equipo, incluyendo el identificador asignado a cada uno y unabreve descripción del mismo.

PNK-ES001: puerto SPI, utilizado para la comunicación con el circuito inte-grado del lector RFID.

PNK-ES002: entrada digital opto-aislada, utilizada para conectar el sensorde puerta abierta.

PNK-ES003: salida digital con inversión de polaridad, utilizada para conec-tar el actuador de la cerradura.


TABLA 2.3: Resumen de los modos de funcionamiento del equipoen función la cerradura y la instalación del sensor de puerta.

Cerradura Sensor Forma de operación

Electromagnética Sin instalar

Se libera la cerradura, cambiando el estado dela alimentación, por un tiempo predefinido. Alfinalizar este, se bloquea la cerraduravolviendo la alimentación al estado inicial.

Electromagnética Instalado

Se libera la cerradura, cambiando el estado dela alimentación, hasta detectar la apertura dela puerta sin exceder un tiempo máximopredefinido. Se supervisa que la puerta nopermanezca abierta por más de cierto tiempo.

Motorizada Sin instalar

Se libera la cerradura alimentando el motorpor un cierto tiempo. Al finalizar el mismo lapuerta permanece liberada por un tiempomáximo. Finalmente se bloquea la cerraduraalimentando el motor con polaridad inversadurante un cierto tiempo.

Motorizada Instalado

Se libera la cerradura alimentando el motorpor un cierto tiempo. Al finalizar se supervisala apertura y cierre de la puerta. Al detectar laapertura de la puerta, o al superar un tiempomáximo de espera, se bloquea nuevamente lacerradura, alimentando el motor con polaridadinversa durante un cierto tiempo.

PNK-ES004: entrada digital sin aislación, utilizada para conectar el sensorde cerradura liberada.

PNK-ES005: entrada digital sin aislación, utilizada para conectar el sensorde cerradura bloqueada.

PNK-ES006: entrada digital opto-aislada, utilizada para conectar un pulsa-dor para liberación manual de la puerta.

PNK-ES007: salida digital de contacto seco, utilizada generar una señal dealarma.

PNK-ES008: salida modulada en frecuencia, utilizada para conectar un in-dicador sonoro para el usuario.

PNK-ES009: salida digital con inversión de polaridad, utilizada para conec-tar un indicador luminoso para el usuario.

Como se explicó en el inicio de la sección 2.4 uno de los requerimientos importan-tes del equipo es poder configurar el comportamiento del mismo para adaptarlo adiferentes tipos de instalaciones. Por esta razón se decidió definir claramente cadauno los parámetros de configuración requeridos para lograr la capacidad de per-sonalización deseada. A continuación se listan los parámetros de configuración


que debe implementar el nuevo equipo, incluyendo el identificador asignado acada uno y la descripción formal del mismo.

PNK-PO001: valor numérico en el rango de 100 ms a 2.500 ms, correspondeal tiempo de accionamiento del indicador luminoso PNK-ES009 cuando seproduce la lectura de una tarjeta .

PNK-PO002: valor numérico en el rango de 100 ms a 2.500 ms, correspon-de al tiempo de accionamiento del indicador sonoro PNK-ES008 cuando seconcede el acceso a una tarjeta .

PNK-PO003: valor numérico en el rango de 100 ms a 2.500 ms, correspon-de al tiempo de accionamiento del indicador sonoro PNK-ES008 cuando sedeniega el acceso a una tarjeta .

PNK-PO004: valor numérico en el rango de 1s a 60s, corresponde al tiempomáximo que la puerta permanece liberada para permitir la apertura de lamisma .

PNK-PO005: valor numérico en el rango de 100 ms a 2.500 ms, correspondeal tiempo máximo de accionamiento del motor en cerraduras motorizadas.

PNK-PO006: valor numérico en el rango de 1s a 60s, corresponde al tiempomáximo que la puerta puede permanece abierta antes de generar una señalde alarma.

PNK-PO007: valor lógico que indica si el sensor de puerta abierta se en-cuentra conectado.

PNK-PO008: valor lógico que indica si el sistema de liberación de la puertarequiere inversión de polaridad.

PNK-PO009: valor lógico que indica si el sistema de liberación de la puertadispone de sensor para verificar el estado del mismo.

Finalmente en lo que respecta a los requisitos funcionales del equipo se los divi-dió en tres grupos para simplificar la interpretación de los mismos. EL primerocorresponde al comportamiento del equipo para el control de acceso, el segundoa las señales de salida que debe generar en función de la configuración y el tercerogrupo describe como se realizará la gestión. A continuación se listan los requisi-tos funciones que debe implementar el nuevo equipo, incluyendo el identificadorasignado a cada uno y la descripción formal del mismo.

Requisitos funcionales para el control de accesos

• PNK-RS001: el software debe recuperar el número de serie de la tarjetaMIFARE presentada ante el lector.

• PNK-RS002: el software debe indicar la lectura de una tarjeta cambian-do el color indicador luminoso durante un tiempo PNK-PO001. Paraello debe activar la salida PNK-ES009 con polaridad inversa.

• PNK-RS003: el software debe determinar si la tarjeta leída esta incluidaen una lista de personas autorizadas y conceder el acceso, o denegarlosi la misma no está incluida.

• PNK-RS004: el software debe indicar si se concede el acceso al usuariomediante una melodía de tres tonos ascendentes correspondientes a


las frecuencias de 523 Hz, 659 Hz y 784 Hz, todas con una duracciónde 100 ms. Para ello debe generar de una señal cuadrada en la interface@ref PNK-ES008 de la frecuencia especificada para cada nota.

• PNK-RS005: el software debe indicar si no se concede el acceso al usua-rio mediante una melodía de tres tonos descendentes correspondientesa las frecuencias de 784 Hz, 659 Hz y 523 Hz, todas con una duracciónde 100 ms. Para ello debe generar de una señal cuadrada en la interface@ref PNK-ES008 de la frecuencia especificada para cada nota.

• PNK-RS006: cuando concede el acceso a un usuario el software debeaccionar el actuador de la puerta para liberarla, esperar la aperturade la puerta o el tiempo máximo de espera fijado por el parámetroPNK-PO004, y al ocurrir cualquiera de los dos eventos debe volver aaccionar el actuador de la puerta para bloquearla.

• PNK-RS007: cuando un usuario abre la puerta después de un accesoautorizado el software debe supervisar que el cierre de la misma, y siesto no ocurre antes del tiempo máximo de espera fijado por el pa-rámetro PNK-PO006, entonces el software debe generar una señal dealarma hasta que ocurra el cierre de a misma. Para ello debe activar lasalida PNK-PO007 en forma permanente hasta que finalice la alarma.

• PNK-RS008: el software debe supervisar permanentemente el estadode la puerta para detectar una apertura no autorizada, y debe generaruna señal de alarma hasta que ocurra el cierre de a misma. Para ellodebe activar la salida PNK-PO007 en forma permanente hasta que fi-nalice la alarma

• PNK-RS009: cuando se activa el pulsador de ingreso conectado a laentrada PNK-ES006 el software debe conceder el acceso siguiendo elmismo comportamiento que para una tarjeta autorizada.

Requisitos funcionales para las señales generadas a los actuadores

• PNK-RS010: si el equipo esta configurado para operar sin sensor depuerta (PNK-PO007 = 0) y con un destraba pestillo eléctrico (PNK-PO008 = 0), cuando se concede el acceso, el software debe activar lasalida PNK-ES003 con polaridad directa durante el tiempo máximode accionamiento de puerta PNK-PO004. Al finalizar este tiempo deespera el software debe apagar la salida PNK-ES003.

• PNK-RS011: si el equipo esta configurado para operar con sensor depuerta (PNK-PO007 = 1) y con un destraba pestillo eléctrico (PNK-PO008 = 0), cuando se concede el acceso, el software debe activar lasalida PNK-ES003 con polaridad directa hasta que se activa el sensorde puerta abierta PNK-ES002 o hasta que se cumple el tiempo máximode accionamiento de puerta PNK-PO004. Al finalizar este tiempo deespera el software debe apagar la salida PNK-ES003.

• PNK-RS012: si el equipo esta configurado para operar sin sensor depuerta (PNK-PO007 = 0), con un motor como actuador (PNK-PO008 =1) y sin sensores en el mecanismo del motor (PNK-PO008 = 0), cuan-do se concede el acceso, el software debe activar la salida PNK-ES003


con polaridad directa durante el tiempo máximo de accionamiento delmotor PNK-PO005. Al finalizar este tiempo el software debe esperar eltiempo de apertura de la puerta PNK-PO004 y al finalizar el softwareactivar la salida PNK-ES003 con polaridad inversa durante la mismacantidad de tiempo PNK-PO005. Al finalizar este tiempo el softwaredebe apagar la salida PNK-ES003.

• PNK-RS013: si el equipo esta configurado para operar sin sensor depuerta (PNK-PO007 = 0), con un motor como actuador (PNK-PO008 =1) y con sensores en el mecanismo del motor (PNK-PO008 = 0), cuandose concede el acceso, el software debe activar la salida PNK-ES003 conpolaridad directa hasta que el se activa el sensor PNK-ES004 que indicaque el mecanismo está liberado. Después el software debe esperar eltiempo de apertura de la puerta PNK-PO004 y al finalizar el softwareactivar la salida PNK-ES003 con polaridad inversa hasta que se activael sensor PNK-ES005 que indica que el mecanismo está bloqueado. Alfinalizar este tiempo el software debe apagar la salida PNK-ES003. Síel tiempo que permanece activa la salida PNK-ES003 supera el tiempomáximo PNK-PO004 el software debe apagar la salida y registrar unacondición de error.

• PNK-RS014: si el equipo esta configurado para operar con sensor depuerta (PNK-PO007 = 1), con un motor como actuador (PNK-PO008 =1) y sin sensores en el mecanismo del motor (PNK-PO008 = 0), cuan-do se concede el acceso, el software debe activar la salida PNK-ES003con polaridad directa durante el tiempo máximo de accionamiento delmotor PNK-PO005. Al finalizar este tiempo el software debe esperarhasta que se activa el sensor de puerta abierta PKN-ES002 o hasta quese cumple el tiempo máximo de accionamiento de puerta PNK-PO004.Después el software debe activar la salida PNK-ES003 con polaridadinversa durante la misma cantidad de tiempo PNK-PO005. Al finalizareste tiempo el software debe apagar la salida PNK-ES003.

• PNK-RS015: si el equipo esta configurado para operar con sensor depuerta (PNK-PO007 = 1), con un motor como actuador (PNK-PO008 =1) y con sensores en el mecanismo del motor (PNK-PO008 = 0), cuandose concede el acceso el software debe activar la salida PNK-ES003 conpolaridad directa hasta que el se activa el sensor PNK-ES004 que indi-ca que el mecanismo está liberado. Después el software debe esperarhasta que se activa el sensor de puerta abierta PNK-ES002 o hasta quese cumple el tiempo máximo para la apertura de puerta PNK-PO004.Después el software debe activar la salida PNK-ES003 con polaridadinversa hasta que se activa el sensor PNK-ES005 que indica que el me-canismo está bloqueado. Al finalizar este tiempo el software debe apa-gar la salida PNK-ES003. Sí el tiempo que permanece activa la salidaPNK-ES003 supera el tiempo máximo PNK-PO004 el software debeapagar la salida y registrar una condición de error.

Requisitos funcionales para la gestión del equipo

• PNK-RS016: en cada lectura de tarjeta el software debe registrar en unabitácora la fecha y la hora, el número de la tarjeta leída, si se concedió


o no el acceso, si se abrió o no la puerta y si se volvió a cerrar dentrodel tiempo establecido.

• PNK-RS017: en cada acceso por pulsador el software debe registrar enuna bitácora la fecha y la hora del acceso, si se abrió o no la puerta, sise volvió a cerrar dentro del tiempo establecido.

• PNK-RS018: el software debe permitir agregar o eliminar una tarjeta ala lista de personas autorizadas mediante un protocolo de comunica-ción que utilice la red WiFi como medio de transporte.

• PNK-RS019: el software debe permitir borrar completamente la listade personas autorizadas mediante un protocolo de comunicación queutilice la red WiFi como medio de transporte.

• PNK-RS020: el software debe permitir recuperar todos los eventos dela bitácora, posteriores a una fecha especifica mediante un protocolode comunicación que utilice la red WiFi como medio de transporte.

• PNK-RS021: el software debe permitir cambiar los valores de todos losparámetros operativos mediante un protocolo de comunicación queutilice la red WiFi como medio de transporte.

2.4.2. Casos de uso

Siguiendo las recomendaciones de la ingeniería de software, se documentaron loscasos de uso del equipo como parte integral de la especificación de requisitos delsoftware del equipo a desarrollar. En las tablas 2.4, 2.5, 2.6, 2.7 y 2.8 se detallanlos cinco casos de uso identificados durante el análisis de requisitos.


TABLA 2.4: Caso de uso acceso por pulsador

Titulo Descripción

Identificador PKN-CU001Nombre Acceso por pulsadorDescripción Acceso de una persona utilizando un pulsadorActor principal UsuarioDisparadores El usuario presiona el pulsador de salidaFlujo básico 1. El usuario presiona el pulsador de salida

2. El software informa que concederá el acceso emitiendoun sonido corto y agudo3. El software acciona el mecanismo para permitir laapertura de la puerta4. El software espera el tiempo accionamiento decerradura PNK-PO0045. El usuario abre la puerta antes de que se complete eltiempo de cerradura6. El software acciona el mecanismo para impedir unanueva apertura de la puerta7. El software espera el tiempo de puerta abiertaPNK-PO0068. El usuario cierra la puerta antes de que se complete eltiempo de puerta abierta9. El software registra el acceso en la bitácora denovedades

Flujo alternativo 5. El usuario no abre la puerta antes de que se complete eltiempo PNK-PO0045.1. El software acciona el mecanismo para impedir unanueva apertura de la puerta5.2. El software registra en la bitácora de novedades que elusuario no ingresó

Flujo alternativo 8. El usuario no cierra la puerta antes de que se complete eltiempo PNK-PO0068.1. El software informa el error de puerta abierta con unsonido continuo8.2. El software espera el cierre de la puerta8.3. El usuario cierra la puerta8.4. El software deja de emitir el sonido8.5. El software registra en la bitácora de novedades que elusuario dejó la puerta abierta

Precondiciones La puerta debe estar cerradaPostcondiciones La puerta debe estar cerrada


TABLA 2.5: Caso de uso acceso por tarjeta de proximidad

Titulo Descripción

Identificador PKN-CU002Nombre Acceso por tarjeta

DescripciónAcceso de una persona autorizada utilizando una tarjetade proximidad

Actor principal Usuario con tarjeta de proximidadDisparadores El usuario presenta la tarjeta delante del lectorFlujo básico 1. El usuario presenta la tarjeta delante del lector

2. El software verifica que la tarjeta leída esta incluida en lalista de tarjetas autorizadas3. El software informa que concederá el acceso emitiendoun sonido corto y agudo4. El software acciona el mecanismo para permitir laapertura de la puerta5. El software espera el tiempo accionamiento decerradura PNK-PO0046. El usuario abre la puerta antes de que se complete eltiempo de cerradura7. El software acciona el mecanismo para impedir unanueva apertura de la puerta8. El software espera el tiempo de puerta abiertaPNK-PO0069. El usuario cierra la puerta antes de que se complete eltiempo de puerta abierta10. El software registra el acceso en la bitácora denovedades

Flujo alternativo 2. El software determina que la tarjeta leída no estáincluida en la lista de tarjetas autorizadas2.1. El software informa que no concederá accesoemitiendo un sonido largo y grave2.2. El software registra en la bitácora de novedades queno se concedió el acceso al usuario

Flujo alternativo 6. El usuario no abre la puerta antes de que se complete eltiempo PNK-PO0046.1. El software acciona el mecanismo para impedir unanueva apertura de la puerta6.2. El software registra en la bitácora de novedades que elusuario no ingresó

Flujo alternativo 9. El usuario no cierra la puerta antes de que se complete eltiempo PNK-PO0069.1. El software informa el error de puerta abierta con unsonido continuo9.2. El software espera el cierre de la puerta9.3. El usuario cierra la puerta9.4. El software deja de emitir el sonido9.5. El software registra en la bitácora de novedades que elusuario dejó la puerta abierta

Precondiciones La puerta debe estar cerradaPostcondiciones La puerta debe estar cerrada


TABLA 2.6: Caso de uso configuración del equipo

Titulo Descripción

Identificador PKN-CU003Nombre Configuración del equipo

DescripciónConfiguración del equipo desde un teléfono celular o unacomputadora

Actor principal Software de gestiónDisparadores Recepción de un comando de configuraciónFlujo básico 1. El software recibe un comando para actualizar la

configuración2. El software recibe los nuevos parámetros deconfiguración3. El software valida los nuevos parámetros deconfiguración4. El software aplica los nuevos parámetros deconfiguración5. El software envía una confirmación informando que losparámetros se aplicaron correctamente

Flujo alternativo3. Los parámetros recibidos son incorrectos

3.1. El software envía una notificación de error informandoque los parámetros son incorrectos

Precondiciones NingunaPostcondiciones Ninguna

TABLA 2.7: Caso de uso gestión de las personas autorizadas

Titulo Descripción

Identificador PKN-CU004Nombre Gestión de las personas autorizadas

DescripciónConfiguración de la lista de tarjetas autorizadas desde unteléfono celular o una computadora

Actor principal Software de gestión

DisparadoresRecepción de un comando para actualización de la lista detarjetas autorizadas

Flujo básico 1. El software recibe un comando para actualizar la lista detarjetas autorizadas2. El software recibe la nueva lista de tarjetas autorizadas3. El software valida la lista de tarjetas autorizadas recibida4. El software reemplaza la lista de tarjetas autorizadasactual por la recibida5. El software envía una confirmación informando que seactualizó la lista de tarjetas autorizadas

Flujo alternativo3. La lista de tarjetas autorizadas no es válida

3.1. El software envía una notificación de error informandoque la lista de tarjetas no es válida

Precondiciones NingunaPostcondiciones Ninguna


TABLA 2.8: Caso de uso consulta de la bitácora de accesos

Titulo Descripción

Identificador PKN-CU005Nombre Acceso a la bitácora del equipo

DescripciónConsulta de la bitácora del equipo desde un teléfonocelular o una computadora

Actor principal Software de gestiónDisparadores Recepción de un comando de consulta de la bitácora

Flujo básico1. El software recibe un comando para recuperar labitácora de novedades2. El software envía la bitácora de eventos

Flujo alternativo NingunoPrecondiciones NingunaPostcondiciones Ninguna

2.4.3. Pruebas de aceptación

El último paso de la especificación de requisitos consistió en la definición de laspruebas de aceptación del equipo, las que servirán para validar el cumplimientode los requisitos ya listados. Para formalizar las pruebas se siguieron los linea-mientos definidos por la metodología BDD (Behaviour Driven Development)[23]para el desarrollo de software. Esta propone utilizar un metalenguaje denomina-do Gherkin para escribir las pruebas en forma de un guión en lenguaje natural,de forma tal que puedan ser validadas por el cliente. Para organizar la estructurade este, el lenguaje define los siguientes elementos:

Característica: corresponde al conjunto de pruebas para validar un compor-tamiento especifico del equipo. Cada archivo de pruebas contiene una solacaracterística que se nombra con una frase corta. A continuación se debedetallar quién pide esa característica, qué acciones espera poder realizar yqué beneficio le otorga. Cada característica está formada por un conjunto deescenarios que definen las pruebas necesarias para validarla.

Escenario: corresponde a cada una de las pruebas que se efectúan para va-lidar una característica en particular. El escenario se nombra con una frasecorta que lo describa y está formado por una serie de sentencias que co-mienzan con las palabras dado, cuando y entonces. Existe también la po-sibilidad de agrupar escenarios similares utilizado una tabla de ejemplos ydefiniendo el esquema de una prueba que se repite para cada ejemplo de latabla.

Dado: corresponde a las sentencias que definen los condiciones iniciales pa-ra poder ejecutar la prueba descrita en el escenario. Normalmente se utili-zan al principio del guion.

Cuando: corresponde a las sentencias que definen las acciones que se efec-túan para completar la prueba.

Entonces: corresponde a las sentencias que describen el comportamientoesperado del equipo como resultado de efectuar una acción sobre él.


A continuación se detallan las pruebas de aceptación definidas para el equiposiguiendo la metodología propuesta.

1 Caracteristica: Permitir la apertura mediante un pulsador2 Como usuario del equipo dentro del ambiente controlado3 Quiero disponer de una forma alternativa de abrir la puerta4 Para poder salir del ambiente sin generar una alarma5 Y permitir el ingreso de personas que no tienen tarjeta6

7 Escenario: Estado inicial del equipo8 Cuando se inicia el equipo9 Entonces la salida para liberar la puerta está en reposo

10

11 Escenario: Liberacion por pulsador electromagnetica sin sensor12 Dado un equipo con una cerradura electromagnetica13 Y con el tiempo de apertura configurado en 3 segundos14 Cuando se activa la entrada para el pulsador de apertura15 Entonces se emite la secuencia de notas ascendentes16 Y la salida para liberar la puerta está activa17 Cuando transcurren 1 segundos18 Y se libera la entrada para el pulsador de apertura19 Entonces la salida para liberar la puerta está activa20 Cuando transcurren 2 segundos21 Entonces la salida para liberar la puerta está activa22 Cuando transcurren 0,1 segundos23 Entonces la salida para liberar la puerta está en reposo24

25 Escenario: Liberacion por pulsador motorizada sin sensor26 Dado un equipo con una cerradura motorizada27 Y con el tiempo de apertura configurado en 7 segundos28 Y con el tiempo del mecanismo configurado en 1 segundos29 Cuando se activa la entrada para el pulsador de apertura30 Entonces se emite la secuencia de notas ascendentes31 Y la salida para liberar la puerta está activa32 Cuando transcurren 1 segundos33 Entonces la salida para liberar la puerta está en reposo34 Cuando transcurren 3 segundos35 Y se libera la entrada para el pulsador de apertura36 Y transcurren 2 segundos37 Entonces la salida para liberar la puerta está en reposo38 Cuando transcurren 1 segundos39 Entonces la salida para liberar la puerta está invertida40 Cuando transcurren 0,1 segundos41 Entonces la salida para liberar la puerta está en reposo42

43 Escenario: Apertura por pulsador electromagnetica con sensor44 Dado un equipo con una cerradura electromagnetica45 Y con el sensor de puerta abierta instalado y configurado46 Y con el tiempo de apertura configurado en 4 segundos47 Cuando se activa la entrada para el pulsador de apertura48 Entonces se emite la secuencia de notas ascendentes49 Y la salida para liberar la puerta está activa50 Cuando transcurren 1 segundos51 Y se libera la entrada para el pulsador de apertura52 Entonces la salida para liberar la puerta está activa53 Cuando transcurren 2 segundos54 Y el sensor informa la apertura de la puerta


55 Entonces la salida para liberar la puerta está en reposo56 Cuando transcurren 4 segundos57 Y el sensor informa el cierre de la puerta58 Entonces la salida para liberar la puerta está en reposo59

60 Escenario: Liberacion por pulsador motorizada con sensor61 Dado un equipo con una cerradura motorizada62 Y con el sensor de puerta abierta instalado y configurado63 Y con el tiempo de apertura configurado en 5 segundos64 Y con el tiempo de cierre configurado en 8 segundos65 Y con el tiempo del mecanismo configurado en 1 segundos66 Cuando se activa la entrada para el pulsador de apertura67 Entonces se emite la secuencia de notas ascendentes68 Y la salida para liberar la puerta está activa69 Cuando transcurren 1 segundos70 Entonces la salida para liberar la puerta está en reposo71 Cuando transcurren 1 segundos72 Y se libera la entrada para el pulsador de apertura73 Y transcurren 1 segundos74 Y el sensor informa la apertura de la puerta75 Y transcurren 5 segundos76 Y el sensor informa el cierre de la puerta77 Entonces la salida para liberar la puerta está invertida78 Cuando transcurren 1 segundos79 Entonces la salida para liberar la puerta está en reposo

ALGORITMO 2.1: Prueba de aceptación para la validar la aperturapor pulsador.

1 Caracteristica: Permitir la apertura con tarjetas de proximidad2 Como responsable de la seguridad del ambiente controlado3 Quiero que los usuarios abran la puerta con una tarjeta rifd4 Para poder controlar y registrar quienes ingresan5

6 Escenario: Apertura por tarjeta electromagnetica con sensor7 Dado un equipo con una cerradura electromagnetica8 Y con el sensor de puerta abierta instalado y configurado9 Y con el tiempo de apertura configurado en 4 segundos

10 Y con la tarjeta A incluida en la lista de autorizados11 Cuando se acerca la tarjeta A al lector de rfid12 Entonces se emite la secuencia de notas ascendentes13 Y la salida para liberar la puerta está activa14 Cuando transcurren 1 segundos15 Y se libera la entrada para el pulsador de apertura16 Entonces la salida para liberar la puerta está activa17 Cuando transcurren 2 segundos18 Y el sensor informa la apertura de la puerta19 Entonces la salida para liberar la puerta está en reposo20 Cuando transcurren 4 segundos21 Y el sensor informa el cierre de la puerta22 Entonces la salida para liberar la puerta está en reposo

ALGORITMO 2.2: Prueba de aceptación para la validar la aperturapor tarjeta de proximidad.


1 Caracteristica: Informar si la puerta permanece abierta2 Como responsable de la seguridad del ambiente controlado3 Quiero saber cuando la puerta esta abierta indebidamente4 Para tomar las acciones correctivas pertinentes5

6 Escenario: Estado inicial del equipo7 Cuando se inicia el equipo8 Entonces la salida de alarma del equipo está en reposo9

10 Escenario: Apertura forzada breve de la puerta11 Dado un equipo con una cerradura electromagnetica12 Y con el sensor de puerta abierta instalado y configurado13 Y configurado con el tiempo minimo de alarma en 5 segundos14 Cuando el sensor informa la apertura de la puerta15 Entonces la salida de alarma del equipo está activa16 Cuando transcurren 3,5 segundos17 Y el sensor informa el cierre de la puerta18 Entonces la salida de alarma del equipo está activa19 Cuando transcurren 1,5 segundos20 Entonces la salida de alarma del equipo está activa21 Cuando transcurren 0,1 segundos22 Entonces la salida de alarma del equipo está en reposo23

24 Escenario: Apertura forzada prolongada de la puerta25 Dado un equipo con una cerradura electromagnetica26 Y con el sensor de puerta abierta instalado y configurado27 Y con el tiempo minimo de alarma configurado en 3 segundos28 Cuando el sensor informa la apertura de la puerta29 Entonces la salida de alarma del equipo está activa30 Cuando transcurren 3 segundos31 Entonces la salida de alarma del equipo está activa32 Cuando transcurren 1,5 segundos33 Y el sensor informa el cierre de la puerta34 Entonces la salida de alarma del equipo está en reposo35

36 Escenario: Apertura por pulsador sin cierre de la puerta37 Dado un equipo con una cerradura electromagnetica38 Y con el sensor de puerta abierta instalado y configurado39 Y con el tiempo de apertura configurado en 4 segundos40 Y con el tiempo de cierre configurado en 8 segundos41 Cuando se activa la entrada para el pulsador de apertura42 Entonces la salida para liberar la puerta está activa43 Cuando transcurren 1 segundos44 Y se libera la entrada para el pulsador de apertura45 Entonces la salida para liberar la puerta está activa46 Cuando transcurren 2 segundos47 Y el sensor informa la apertura de la puerta48 Entonces la salida para liberar la puerta está en reposo49 Y la salida de alarma del equipo está en reposo50 Cuando transcurren 8 segundos51 Entonces la salida para liberar la puerta está en reposo52 Y la salida de alarma del equipo está activa53 Cuando transcurren 0,1 segundos54 Y el sensor informa el cierre de la puerta55 Entonces la salida de alarma del equipo está en reposo

ALGORITMO 2.3: Prueba de aceptación para la validar la detecciónde puerta abierta.


1 Caracteristica: Autorizar o denegar el acceso a una tarjeta2 Como responsable de la seguridad del ambiente controlado3 Quiero poder agregar o quitar tarjetas autorizadas4 Para poder controlar quienes ingresan5

6 Escenario: Estado incial del equipo7 Dado un equipo con la configuracion de fabrica8 Cuando se activa se acerca la tarjeta A al lector de rfid9 Entonces no se autoriza el acceso a la tarjeta A

10 Y se emite la secuencia de notas descendentes11

12 Escenario: Autorizacion de una tarjeta13 Dado un equipo con una cerradura electromagnetica14 Y con el tiempo de apertura configurado en 3 segundos15 Y con la lista de tarjetas autorizadas vacia16 Cuando se agrega la tarjeta A a la lista de autorizadas17 Cuando se acerca la tarjeta A al lector de rfid18 Entonces se autoriza el acceso a la tarjeta A19 Y se emite la secuencia de notas ascendentes20

21 Escenario: Autorizacion de una segunda tarjeta22 Dado un equipo con una cerradura electromagnetica23 Y con el tiempo de apertura configurado en 3 segundos24 Y con la tarjeta A incluida en la lista de autorizados25 Cuando se agrega la tarjeta B a la lista de autorizadas26 Y se acerca la tarjeta B al lector de rfid27 Entonces se autoriza el acceso a la tarjeta B28 Y se emite la secuencia de notas ascendentes29

30 Escenario: Desautorizacion de una tarjeta31 Dado un equipo con una cerradura electromagnetica32 Y con el tiempo de apertura configurado en 3 segundos33 Y con la tarjeta A incluida en la lista de autorizados34 Y con la tarjeta B incluida en la lista de autorizados35 Cuando se elimina la tarjeta B a la lista de autorizadas36 Y se acerca la tarjeta B al lector de rfid37 Entonces no se autoriza el acceso a la tarjeta B38 Y se emite la secuencia de notas descendentes

ALGORITMO 2.4: Prueba de aceptación para la validar la gestionde tarjetas autorizadas.


1 Caracteristica: Registrar las aperturas y cierres de la puerta2 Como responsable de la seguridad del ambiente controlado3 Quiero saber quien y cuando abre y cierra la puerta4 Para tomar las acciones correctivas pertinentes5

6 Escenario: Apertura forzada de la puerta7 Dado un equipo con una cerradura electromagnetica8 Y con el sensor de puerta abierta instalado y configurado9 Y sin eventos previos registrados en la bitacora

10 Cuando el sensor informa la apertura de la puerta11 Entonces se registra un evento de puerta forzada12 Cuando transcurren 3 segundos13 Y el sensor informa el cierre de la puerta14 Entonces se registra un evento de puerta cerrada15 Cuando se consulta la bitacora del equipo16 Entonces se reciben los dos eventos registrados17

18 Escenario: Apertura por pulsador sin sensor19 Dado un equipo con una cerradura electromagnetica20 Y con el tiempo de apertura configurado en 3 segundos21 Cuando se activa la entrada para el pulsador de apertura22 Entonces se registra un evento de acceso correcto23 Cuando se consulta la bitacora del equipo24 Entonces se recibe el evento registrado25

26 Escenario: Liberacion por pulsador con sensor27 Dado un equipo con una cerradura electromagnetica28 Y con el sensor de puerta abierta instalado y configurado29 Y con el tiempo de apertura configurado en 3 segundos30 Y el sensor informa el cierre de la puerta31 Cuando se activa la entrada para el pulsador de apertura32 Y transcurren 3 segundos33 Entonces se registra un evento liberacion sin acceso34 Cuando se consulta la bitacora del equipo35 Entonces se recibe el evento registrado36

37 Escenario: Apertura por pulsador con sensor38 Dado un equipo con una cerradura electromagnetica39 Y con el sensor de puerta abierta instalado y configurado40 Y con el tiempo de apertura configurado en 3 segundos41 Y con el tiempo de apertura configurado en 5 segundos42 Cuando se activa la entrada para el pulsador de apertura43 Y transcurren 2 segundos44 Y el sensor informa la apertura de la puerta45 Y transcurren 4 segundos46 Y el sensor informa el cierre de la puerta47 Entonces se registra un evento de acceso correcto48 Cuando se consulta la bitacora del equipo49 Entonces se recibe el evento registrado50

51 Escenario: Apertura por pulsador sin cierre con sensor52 Dado un equipo con una cerradura electromagnetica53 Y con el sensor de puerta abierta instalado y configurado54 Y con el tiempo de apertura configurado en 3 segundos55 Y con el tiempo de apertura configurado en 5 segundos56 Cuando se activa la entrada para el pulsador de apertura57 Y transcurren 2 segundos


58 Y el sensor informa la apertura de la puerta59 Y transcurren 5 segundos60 Entonces se registra un evento de acceso y puerta abierta61 Y transcurren 4 segundos62 Entonces se registra un evento de puerta cerrada63 Cuando se consulta la bitacora del equipo64 Entonces se reciben los dos eventos registrados65

66 Escenario: Apertura por tarjeta sin sensor67 Dado un equipo con una cerradura electromagnetica68 Y con el tiempo de apertura configurado en 3 segundos69 Y con la tarjeta A incluida en la lista de autorizados70 Cuando se acerca la tarjeta A al lector de rfid71 Entonces se registra un evento de acceso correcto72 Cuando se consulta la bitacora del equipo73 Entonces se recibe el evento registrado74

75 Escenario: Lectura de tarjeta no autorizada76 Dado un equipo con una cerradura electromagnetica77 Y con el tiempo de apertura configurado en 3 segundos78 Y con la tarjeta A incluida en la lista de autorizados79 Cuando se acerca la tarjeta B al lector de rfid80 Entonces se registra un evento de tarjeta no autorizada81 Cuando se consulta la bitacora del equipo82 Entonces se recibe el evento registrado

ALGORITMO 2.5: Prueba de aceptación para la validar el registrode los eventos de acceso y alarma.

27

Capítulo 3

Diseño e Implementación

En este capítulo se presentan y fundamentan las decisiones adoptadas durante eldiseño del equipo, la implementación de la placa electrónica y el desarrollo delfirmware.

3.1. Diseño del hardware

Un aspecto muy importante que se tuvo en cuenta desde el momento mismo deseleccionar los componentes que se utilizaron en el diseño del equipo es la reali-dad del medio en el que fabricará y comercializará el producto. EQUISER es unamicroempresa que comercializa actualmente, en promedio, dos unidades al mes.Esto determina que la fabricación se efectúe en lotes de entre diez y veinte unida-des, que representan cantidades muy pequeñas para el estándar de la industriaelectrónica. Si bien la firma tiene capacidad para importar componentes del exte-rior, los constantes cambios en las políticas aduaneras del país y la incidencia delcosto de los fletes en compras pequeñas llevaron a minimizar la dependencia deproveedores extranjeros.

En este contexto, y como una solución de compromiso entre la disponibilidadlocal, la facilidad de montaje, el costo y las prestaciones, se adoptó como proce-sador principal del equipo el módulo ESP-WROOM-32D[ESP32WROOM] de laempresa Espressif. Basado en un procesador de doble núcleo Xtensa de 32bits,que puede operar con una frecuencia de hasta 240 MHz, este microcontroladordispone de 520 kB de memoria RAM interna y se integra en el módulo 4 MB dememoria flash. Implementa entradas y salidas tanto digitales como analógicas, ypuertos de comunicaciones con los protocolos SPI, I2C y UART. Para la comuni-cación inalámbrica están disponibles una interfaz Bluetooth que puede funcionarcon las versiones 2 y 4 del protocolo, y una interfaz WiFi que opera en 2.4 GHzque cumple con las variantes b, g y n del estándar IEEE802.11.

Este módulo se presenta como el sucesor del ESP8266, un diseño pensado ori-ginalmente como interfaz WiFi de bajo costo para pequeños microcontroladores,que ganó una cuota importante del mercado cuando el fabricante puso a disposi-ción del público las herramientas para desarrollar versiones propias del firmware.Esto permitió integrar la aplicación directamente dentro del módulo y convertirlode esta forma en el procesador principal del sistema. Uno de los factores clave deléxito de esta propuesta es el costo y la relativa facilidad de montaje del módulo,características que se mantienen en el ESP-WROM-32D, la versión seleccionadapara este diseño.

28 Capítulo 3. Diseño e Implementación

En la figura 3.1 se presenta el diagrama de bloques del nuevo equipo. Si se locompara con el de la figura 1.1, que corresponde al diseño original del equipo,podemos observar las siguientes diferencias:

ComunicaciónTCP/IP W-iFi

Fuente dealimentación

Reloj detiempo real

Entradas ysalidas

Almacenamiento

MicrocontroladorBase station RF

MecanismoCerradura

Puerta Procesador

Usuario

Internet

Celular

FIGURA 3.1: Diagrama de bloques del equipo desarrollado

Se unificaron las dos unidades funcionales del equipo anterior en el proce-sador. Así, quedó instalada en la puerta únicamente la placa electrónica queimplementa la antena de RFID con el circuito integrado responsable de lageneración del campo electromagnético y el procesamiento analógico de laseñal recibida. Esto permite además de reducir la cantidad de componentesy centralizar en el firmware principal todo el procesamiento de la comuni-cación con la tarjeta de proximidad.

En el bloque de entradas y salidas se cambió la conexión con el sistemade cerradura para controlar indistintamente sistemas electromagnéticos omotorizados. Asimismo se agregaron sensores de fin de carrera para el me-canismo de la cerradura, lo que además de aumentar la confiabilidad delsistema permite prolongar la vida útil de los componentes al evitar esfuer-zos innecesarios.

Se cambió el bloque de comunicaciones Bluetooth por una interfaz WiFi,lo que permitió además adoptar el protocolo TPC/IP para la comunica-ción con el equipo. Esta interfaz puede operar en modo punto de acceso,lo que permite efectuar una comunicación punto a punto con el celular dela misma forma que se hacía con el Bluetooth. Pero también puede operaren modo estación, de esta forma el equipo puede conectarse una red WiFiexistente y permitir la gestión desde cualquier dispositivo autorizado quetenga conexión con esta red.

Se incorpora un reloj de tiempo real independiente del procesador que seráel responsable de mantener la fecha y hora del sistema. Este bloque incluyeuna batería de respaldo que le permite continuar funcionando cuando elequipo no cuenta con alimentación.

3.2. Prototipo del hardware 29

3.2. Prototipo del hardware

En el diseño de la placa electrónica se siguieron los mismos criterios que ya semencionaron en la sección 3.1 para la selección de los componentes. Se decidiómantener el gabinete actual, lo que determinó la geometría de la placa y la posi-ción de la mayoría de los conectores. Se decidió también que la placa se realizaríacon las capacidades de fabricación del único fabricante de circuitos impresos dela provincia, a quien se le encomendaría la producción del primer prototipo. Conestas restricciones el circuito impreso debía resolverse en dos capas y en un áreade 87 x 66 mm.

El trazado de las pistas de cobre no resultó simple, ya que como puede observarseen la figura 3.2 una parte importante del área de la placa se encuentra ocupadapor componentes, lo que sumado a la restricción de utilizar pistas de 0,5 mm yvías de 1 mm impuesta por el proceso de fabricación aumentó la dificultad delproceso de diseño.

FIGURA 3.2: Modelo tridimensional de la placa electrónica.

Se efectuó un proceso de doble revisión sobre el diagrama esquemático del cir-cuito y el diseño de la placa, y se incorporó una serie de recomendaciones efec-tuadas por los revisores como la utilización de los planos de tierra en las zonas dela placa generadoras de ruido electromagnético. Además de los controles men-cionados, fue necesario un tercera revisión para detectar y corregir los últimoserrores antes de la fabricación de la placa.

La construcción del prototipo se efectuó en forma manual, y durante el procesose detectaron dificultades para el montaje en algunos componentes, originadosen la separación entre los planos de masa y las pistas de señales. En el diseño seadoptó un valor similar al de separación entre pistas, pero debido a la falta deprecisión en la máscara antisoldante que puede observarse en la imagen 3.3, estevalor resultó pequeño. Durante el proceso de soldadura se generaron puentes deestaño entre los terminales de los componentes y el plano de masa circundante.


FIGURA 3.3: Imagen que muestra la falta de precisión en la aplica-ción de la máscara antisoldante del prototipo.

Para resolver este problema se removieron varios componentes del prototipo, yse recurrió al uso de abundantes cantidades flux para volver a soldarlos evitandolos cortocircuitos. Este proceso demandó mucho más tiempo de montaje, por loque también se corrigió el diseño de la placa para aumentar el valor de guarda enlos planos de masa, y evitar este problema en las siguientes placas.

3.3. Diseño del firmware

3.3.1. Arquitectura del firmware

Uno de los objetivos planteados para el trabajo en la sección 1.3 fue la reinge-niería completa del firmware del equipo, que permitiera incorporar el uso de unsistema operativo de tiempo real y el reuso de los componentes comunes en otrosproyectos similares. Para esto se decidió utilizar una arquitectura de capas, quese puede observar en el diagrama de componentes de la figura 3.4. En la mismase pueden identificar claramente cuatro capas:

ESP-IDF: corresponde al conjunto de funciones provistas por el fabricantepara facilitar el desarrollo en la plataforma. Allí se incluyen los controlado-res para los puertos GPIO, SPI, I2C y PWM. También se incluye la imple-mentación del sistema de archivos FAT para tarjetas SD y de un servidorHTTP completo.

Plataforma: implementa una capa de abstracción del hardware, también co-nocida como HAL (Hardware Abstraction Layer)[24], que permite indepen-dizar el resto del código desarrollado de la plataforma provista por el fa-bricante. Esta capa facilita la reutilización del resto de los componentes enproyectos similares y la eventual migración del firmware a otra plataforma.

3.3. Diseño del firmware 31

Controladores: implementa una serie de clases que se pueden reutilizar enotros proyectos fácilmente ya que no dependen del hardware ni de la apli-cación.

Aplicación: implementa la lógica propia del equipo mediante un conjuntode tareas que ejecutan concurrentemente en un sistema operativo de tiemporeal.

Tareas de la Aplicación

Controlde Acceso

Bitácorade Eventos

Lectora deproximidad ServidorSonidos

Controladores

Sensoresdigitales

Controlde Puerta

Lista deAutorizados Configuración

Plataforma

EntradasDigitales

SalidasDigitales

Sistema deArchivos

Reloj deTiempo RealParlante

ESP-IDF

GPIO I2CFATSPI PWM HTTP

FIGURA 3.4: Diagrama de componentes del firmware del equipo.

Para el modelado de los componentes se utilizó el análisis orientado a objetos, loque arrojó como resultado una colección de clases con sus respectivos métodos yatributos. Una imagen completa de este diseño se puede observar en el diagramade clases que se muestra en la figura 3.5. Allí solo están incluidos los componentesde las tres clases superiores desarrolladas en el marco del trabajo. En las siguien-tes subsecciones se explican brevemente las responsabilidades asignadas a cadauna de estas clases.


Autorizados

CrearInstancia()AbrirArchivo()LeerBloque()EscribirBloque()EnventoListado()

AutorizadosCrear()AutorizadosValidar()AutorizadosListar()AutorizadosAgregar()AutorizadosBorrar()AutorizadosLimpiar()

Puertas

CrearInstancia()InformarEvento()PuertaCambios()

PuertaCrear()PuertaNotificar()PuertaConfigurar()PuertaEspera()PuertaLiberar()

Sensores

CrearInstancia()SensorCambios()SensorEventoEntrada()

SensorCrear()SensorNotificar()SensorEspera()SensorActivo()SensorReposo()SensorEstable()

ArbolB

CrearInstancia()BloqueOcupar()BloqueLiberar()ElementosCopiar()ElementosInsertar()ReferenciaBuscar()NodoCrear()NodoBuscar()NodoInsertar()NodoDividir()NodoRotar()NodoCorregir()NodoListar()ArbolInicializar()BuscarElemento()

ArbolCrear()ArbolBuscar()ArbolListar()ArbolInsertar()ArbolEliminar()ArbolLimpiar()

Editor

CrearInstancia()EdicionActiva()AplicarCambios()

EditorCrear()EditorAbrir()EditorComenzar()EditorConfirmar()EditorLeer()EditorEscribir()

MFRC522

PCD_Init()

Mifare

PICC_HaltA()PICC_IsNewCardPresent()PICC_ReadCardSerial()

Archivos

ArchivosConfigurar

ArchivoAbrir()ArchivoLeer()ArchivoEscribir()ArchivoMover()ArchivoBorrar()ArchivoCompletar()ArchivoCerrar()

SalidasDigitales

SalidaCrear()SalidaEscribir()SalidaPrender()SalidaApagar()SalidaCambiar()SalidaLeer()

EntradasDigitales

EntradaCrear()EntradaLeer()EntradaNotificar()

Control

ControlCrear()ControlConfigurar()

ControlNuevo()ControlEventoPulsador()ControlEventoPuerta()ControlEventoLectora()ControlTarea()

Servidor

ServidorCrear()

ServidorNuevo()InterpretarFecha()InterpretarHora()ConfigurarRed()ServidorIniciar()ServidorTarea()ServidorEvento()

ObtenerFechaHora()ConsultarReloj()ActualizarReloj()

ObtenerTarjeta()ConsultarTarjeta()BorrarTarjeta()AgregarTarjeta()

ObtenerLista()BorrarLista()

Reloj

configurado

RelojCrear()RelojActualizar()RelojConsultar()

Lectora

LectoraCrear()LectoraNotificar()

LectoraTarea()

Configuracion

ConfiguracionCrear()ConfiguracionSalvar()ConfiguracionRecuperar()

Bitacora

BitacoraCrear()BitacoraRegistrar()

BitacoraTarea()

Sonidos

SonidoCrear()SonidoCorrecto()SonidoErroneo()

SonidosTarea()

Parlantes

ParlanteCrear()ParlanteEmitir()ParlanteSilencia()

FIGURA 3.5: Diagrama de clases del firmware del equipo.


3.3.2. Capa de abstracción del hardware

Esta capa contiene una colección de clases que encapsulan las funcionalidades delentorno de desarrollo provisto por el fabricante. Su principal objetivo es brindaruna plataforma uniforme en comportamiento y documentación para el resto delfirmware. Las clases que pertenecen a esta capa son:

EntradasDigitales: encapsula toda la gestión de un terminal digital utilizadocomo entrada. Permite configurarlo durante la creación del objeto, recupe-rar el estado actual y solicitar el envío de eventos generados por interrup-ciones disparadas por cambios en su estado.

SalidasDigitales: encapsula toda la gestión de un terminal digital utilizadocomo salida. Permite configurarlo durante la creación del objeto, recuperarel estado actual y cambiarle el estado.

Archivos: encapsula toda la gestión de un archivo almacenado en la tarjetamicroSD del equipo. Después de la configuración de la propia clases per-mite la creación y el borrado de archivos, como así también la escritura ylectura de datos en ellos.

Reloj: encapsula toda la gestión del reloj de tiempo real. Permite ajustar yrecuperar la fecha y hora actuales.

Parlantes: encapsula la gestión de un parlante conectado a un terminal di-gital que opera con modulación de ancho de pulso, o PWM (Pulse WidthModulation). Permite, mediante la generación de una señal cuadrada de fre-cuencia arbitraria, emitir un tono en el parlante o silenciarlo.

3.3.3. Capa de controladores

Las clases que componen esta capa son independientes de la plataforma y dela aplicación, y por lo tanto son fácilmente reutilizables en otros proyectos. Paralograr este objetivo, la mayoría de ellas no utilizan los servicios del sistema opera-tivo, e implementan mecanismos de eventos para extraer el código dependientede la aplicación en otro componente. Las clases que pertenecen a esta capa son:

Puertas: encapsula toda la gestión de la puerta. Permite configurar el ti-po de cerradura, habilitar o ignorar el sensor de puerta abierta y definirlos tiempos correspondientes de liberación, apertura y cierre. Puede gene-rar eventos cuando se completa un ciclo de apertura. Esta clase tiene unaespecial importancia en el sistema, ya que la misma implementa aproxima-damente el 30 % de los requisitos funcionales definidos en la sección 2.4.1.Para la implementación se optó por utilizar cuatro maquinas de estado fini-tos independientes, una para cada modo de funcionamiento descrito en latabla 2.3. Para modelar las mismas se utilizaron diagramas para máquinasde estado UML[25][26], los cuales se pueden ver en las figuras 3.6, 3.7, 3.8 y3.9


CerradaDirecta = 0Inversa = 0Alarma = 0

LiberandoDirecta = 1Inversa = 0Alarma = 0

PuertaLiberar()SalidaPrender(Directa)espera = tiempo.apertura

espera == 0SalidaApagar(Directa)

FIGURA 3.6: Diagrama de estado para el control de una puerta sinsensor de apertura y con liberación electromagnética.


AlarmaDirecta = 0Inversa = 0Alarma = 1


AbiertaDirecta = 0Inversa = 0Alarma = 0

OlvidadaDirecta = 0Inversa = 0Alarma = 1

sensor.abiertaespera = tiempo.alarmaSalidaPrender(Alarma)

NO sensor.abiertaY espera == 0

SalidaApara(Alarma)

PuertaLiberar()espera = tiempo.aperturaSalidaPrender(Directa)

espera == 0SalidaApagar(Directa)

sensor.abiertaespera = tiempo.cierreSalidaApagar(Directa)

espera == 0SalidaApagar(Directa)SalidaPrender(Alarma)

NO sensor.abierta

NO sensor.abiertaSalidaApagar(Alarma)

FIGURA 3.7: Diagrama de estado para el control de una puerta consensor de apertura y con liberación electromagnética.




LiberadaDirecta = 0Inversa = 0Alarma = 0

BloqueandoDirecta = 0Inversa = 1Alarma = 0

PuertaLiberar()espera = tiempo.liberacion

SalidaPrender(Directa)

espera == 0espera = tiempo.aperturaSalidaApagar(Directa)

espera == 0espera = tiempo.liberacion

SalidaPrender(Inversa)

espera = 0SalidaApagar(Inversa)

FIGURA 3.8: Diagrama de estado para el control de una puerta sinsensor de apertura y con liberación motorizada.

ArbolB: encapsula toda la gestión de un índice utilizando la estructura dedatos denominada ArbolB o BTree[27]. Permite aprovechar las transferen-cias de bloques en los almacenamientos secundarios, como la tarjeta mi-croSD, para disminuir el tiempo de búsqueda y actualización de una listaordenada. Tanto la clase Editor, que se explica a continuación, como esta sontambién componentes críticos del sistema, ya que cualquier error en ellas setraduce en que personas autorizadas no puedan ingresar, o peor aún, en ac-cesos de personas no autorizadas. Pero a diferencia de la clase Puertas, enestas el aspecto crítico está en la implementación y no en el diseño, ya quelos algoritmos que se utilizan son ampliamente conocidos.

Editor: encapsula toda la gestión de una actualización que involucra múl-tiples escrituras en un archivo. Permite asegurar que el contenido del ín-dice de tarjetas autorizadas no resultará corrupto por una modificación in-completa. Esta clase utiliza el concepto de transacción[28] ACID (Atomicity,Consistency, Isolation and Durability)[29] muy común en las bases de datosrelacionales, que en nuestro caso se puede resumir en que cualquier cam-bio al índice se realiza siempre de manera completa, o de lo contrario, noefectúa absolutamente ningún cambio. Para la implementación se utilizóun archivo de transacciones donde se registran las escrituras de los sectoresque se van actualizando en el índice. Al completar la modificación, esta seconfirma en el mismo archivo de transacciones, y a partir de este punto secomienzan a aplicar los cambios en el archivo de datos. Si ocurre una inte-rrupción del proceso, por ejemplo por un reinicio del sistema, primero sebuscan transacciones confirmadas para aplicar los cambios nuevamente yrecién entonces se comienza la operación del sistema.



AlarmaDirecta = 0Inversa = 0Alarma = 1


LiberadaDirecta = 0Inversa = 0Alarma = 0

AbiertaDirecta = 0Inversa = 0Alarma = 0

OlvidadaDirecta = 0Inversa = 0Alarma = 1

BloqueandoDirecta = 0Inversa = 1Alarma = 0

sensor.abiertaespera = tiempos.alarma

SalidaPrender(Alarma)

NO sensor.abiertaY espera == 0

SalidaApara(Alarma)

PuertaLiberar()espera = tiempos.liberacion

SalidaPrender(Directa)

espera == 0espera = tiempos.apertura

SalidaApagar(Directa)

sensor.abiertaespera = tiempos.cierre

sensor.abiertaSalidaPrender(Alarma)

NO sensor.abiertaespera = tiempos.bloqueo

SalidaApargar(Alarma)SalidaPrender(Inversa)

espera = 0SalidaApagar(Inversa)

espera == 0espera = tiempos.liberacion

SalidaPrender(Inversa)

NO sensor.abiertaSalidaPrender(Inversa)

FIGURA 3.9: Diagrama de estado para el control de una puerta consensor de apertura y con liberación motorizada.


Autorizados: encapsula toda la gestión de una lista con las tarjetas autori-zadas a ingresar. Permite consultar si una tarjeta está autorizada, recuperartoda la lista de tarjetas autorizadas y agregar o eliminar una tarjeta en ella.Esta clase agrega muy poca lógica y es prácticamente un adaptador de laclase ArbolB para convertir la funcionalidad de un índice en una lista pre-sente/ausente. Esta clase agrega además el control de sección crítica nece-sario para que el índice pueda ser consultado y actualizado por dos tareasdiferentes que se ejecutan en forma concurrente.

Sensores: encapsula toda la gestión de filtro digital asociado a terminalesdigitales de entrada. Permite definir un valor de histéresis para eliminarlos eventos generados por ruido electromagnético. También permite gene-rar eventos por cambios en el estado del sensor y determinar si la entradadigital presenta un estado estable o se encuentra en transición.

Configuración: encapsula toda la gestión de las opciones de configuracióndel equipo. Permite consolidar las opciones que pueden cambiar en cadauno de los componentes en una estructura binaria, que puede ser converti-da desde y hacia una cadena de caracteres utilizando la codificación JSON.

3.3.4. Tareas del sistema

En esta capa se encuentran las clases que implementan directamente la lógica defuncionamiento del equipo con el mayor nivel de abstracción. Esto permite ex-tender la funcionalidad en forma simple, dado que el código aplica, casi directa-mente, las reglas de negocio del equipo. Todas las clases de esta capa encapsulantareas del sistema operativo de tiempo real que se ejecutan en forma concurrente.Las clases que componen esta capa son:

Sonidos: encapsula toda la reproducción de una melodía monofónica en unparlante. Define una secuencia de notas especificando la frecuencia y dura-ción de las mismas, y de esta manera permite generar dos sonidos distinti-vos para diferenciar los accesos autorizados de los rechazados.

Lectora: encapsula toda la comunicación con la lectora y, por medio de esta,con la tarjeta de proximidad. Permite recuperar el número de serie únicoasignado a la tarjeta y genera un evento al control para informar de unanueva lectura.

Control: encapsula toda la gestión de las reglas para la apertura y supervi-sión de la puerta. Esta clase implementa un patrón de diseño de softwaredenominado control ambiental. De esta forma convergen en un solo puntolos eventos de la clase Puerta, de la clase Sensor, de la clase Lectora y de laclase Autorizados para centralizar la respuesta y el registro a estos eventos.

Bitacora: encapsula el proceso de registro en un archivo de los eventos gene-rados por el control. Permite efectuar la escritura en el archivo, una opera-ción lenta, en forma diferida para minimizar la interferencia en los tiemposde operación del control de la puerta.

Servidor: encapsula todo el servicio de comunicación para la gestión delequipo. Permite configurar la interfaz WiFi, iniciar un servidor HTTP y


atender los pedidos recibidos interactuando con las clases Reloj, Bitacora,Configuracion y Autorizados para completar las operaciones solicitadas.

De la descripción anterior se desprende que la correcta interacción entre las clasesde esta capa resulta clave para lograr el funcionamiento esperado del equipo. Laingeniería de software nos brinda una herramienta para poder representar estasinteracciones entre los componentes de un programa: los diagramas de secuenciaUML[30]. En estos se representan las llamadas a métodos de las diferentes clasessiguiendo los casos de uso analizados en la subsección 2.4.2. En la figura 3.10 sepresenta el diagrama de secuencia correspondiente la liberación por pulsador enuna puerta con cerradura electromagnética y sin sensor de apertura.

Control Sensores Puerta Salidas Sonidos Bitacora

Sistema en reposo

loop [10 * PNK-PO004]

10 ms

Planificador

SensoresEspera(Pulsador)

PuertaEspera(Puerta)

Liberación de la puerta

Planificador


ControlEventoSensores()

PuertaLiberar(Puerta)

SalidasPrender(Directa)

SonidoCorrecto()


Bloqueo de la puerta

Tiempo de apertura (PNK-PO004)

Planificador




ControlEventoPuerta()

BitacoraRegistrar(PuertaLiberada)

FIGURA 3.10: Diagrama de secuencia correspondiente a la apertu-ra por pulsador en una puerta con cerradura electromagnética y

sin sensor de apertura.


A continuación se desarrolla el mismo diagrama para el caso de una puerta concerradura electromagnética pero con sensor de apertura. En las figuras 3.11 3.12se puede observar que en este caso el comportamiento del sistema resulta máscomplejo, aun cuando intervienen los mismos actores.



Sistema en reposo


10 ms

Planificador



SensoresEspera(PuertaAbierta)

SensorActivo(PuertaAbierta)

False


Planificador


ControlEventoSensores()

SonidoCorrecto()


SalidasPrender(Directa)




False

Bloqueo de la puerta

alt [No se abre la puerta dentro del tiempo de apertura]

Tiempo de apertura (PNK-PO004)

Planificador





False



BitacoraRegistrar(PuertaLiberada)

FIGURA 3.11: Primera parte del diagrama de secuencia correspon-diente a la apertura por pulsador en una puerta con cerradura

electromagnética y sensor de apertura.



[Apertura de la puerta dentro del tiempo de apertura]

t < Tiempo de apertura (PNK-PO004)

Planificador





True


alt [Cierre de la puerta dentro del tiempo de cierre]

t < Tiempo de cierre (PNK-PO006)

Planificador





False


BitacoraRegistrar(AperturaCierre)

[Cierre de la puerta despues del tiempo de cierre]

Tiempo de cierre (PNK-PO006)

Planificador





True

SalidaPrender(Alarma)


BitacoraRegistrar(PuertaOlvidada)

tiempo arbitrario

Planificador





False

SalidaApagar(Alarma)


BitacoraRegistrar(PuertaCerrada)

FIGURA 3.12: Continuación del diagrama de secuencia correspon-diente a la apertura por pulsador en una puerta con cerradura

electromagnética y sensor de apertura.


En la figura 3.13 se presenta el proceso de lectura y autorización de una tarjeta deproximidad. Estas secuencias reemplazan a la sección de liberación del caso baseya presentado, mientras que el resto de las secciones del diagrama se mantienensin cambios.

Lectora Mifare Control Autorizados Sonidos Bitacora

Sistema en reposo


10 ms

Planificador

PICC_IsNewCardPresent()

False


Planificador

PICC_IsNewCardPresent()

True

PICC_ReadCardSerial()

Tarjeta

ControlEventoLectora(Tarjeta)

PICC_HaltA()

alt [Tarjeta autorizada]

AutorizadosValidar(Tarjeta)

True


SonidoCorrecto()

[Tareja no autorizada]

ControlEventoLectora(Tarjeta)

AutorizadosValidar(Tarjeta)

False

BitacoraRegistrar(NoAutorizado)

SonidoErroneo()

FIGURA 3.13: Diagrama de secuencia correspondiente a la libera-ción por lectura de una tarjeta de proximidad.

Finalmente en la figura 3.14 se muestra el detalle de la interacción entre las tareasSonido y Bitácora con las clases Parlantes y Archivos, utilizando como ejemplo elcaso de una tarjeta no autorizada.


Control Sonidos Parlantes Bitacora Archivos

Planificador

BitacoraRegistrar(NoAutorizado)

xQueueSend()

SonidoErroneo()

vTaskResume()

ParlanteEmitir()

vTaskDelay()

ArchivoAbrir()

ArchivoEscribir()

ArchivoCerrar()

xQueueReceive()


Planificador

ParlanteEmitir()

vTaskDelay()

Planificador

ParlanteSilenciar()

vTaskSuspend()

FIGURA 3.14: Diagrama de secuencia con detalle de la interacciónde las tareas Sonido y Bitácora con las clases Parlantes y Archivos.


3.4. Desarrollo del firmware

3.4.1. Entorno de desarrollo

Las metodologías de desarrollo propuestas por la ingeniería de software son li-neamientos generales que deben ser ajustados a la realidad del equipo de desa-rrollo, y un proyecto que se inicia desde cero siempre es una buena oportunidadpara adoptar nuevas metodologías. Por esta razón se decidió aplicar TDD (TestDriven Development)[31] para todo el proceso de codificación. Esta estrategia detrabajo plantea el desarrollo de una prueba unitaria que valida un requerimientoespecífico en primer lugar, y recién después el código de producción necesariopara la implementación. Pero es un requisito indispensable disponer de una he-rramienta que compile y ejecute las pruebas unitarias en forma automática parapoder implementar esta propuesta. La herramienta seleccionada para esta tareafue Ceedling[32], un desarrollo en Ruby de código abierto pensado para imple-mentar TDD en sistemas embebidos. Aunque realmente está formada por trescomponentes que pueden ser utilizados en forma independiente, estos se acoplanperfectamente para funcionar como una solución integral. A estos se pueden su-mar plugins, propios o de terceros, que permiten agregar nuevas funcionalidades.Las componentes utilizadas en este trabajo fueron:

Unity: provee una variedad de funciones para verificar los resultados espe-rados en las pruebas unitarias. Estas funciones pueden comparar diferentestipos de datos, e informan las discrepancias cuando los valores no son loscorrectos[33].

Fake Function Framework: provee la capacidad de generar funciones Mocko Stub que permiten reemplazar las dependencias para poder implemen-tar pruebas unitarias en clases que requieren código que no se desea pro-bar[34][35].

Ceedling: provee la compilación, ejecución y consolidación de los resulta-dos de las pruebas unitarias, en forma automática y con un mínimo esfuerzode configuración[36].

GCOV: provee métricas con la cobertura de las pruebas ejecutadas, es decirla proporción de líneas de código fuente o de condiciones lógicas que fueronverificadas al ejecutar las pruebas unitarias[37].

CLOC: provee métricas con la cantidad de comentarios y líneas de códigofuente, para generar estadísticas que determinen la calidad del código[38].

Otro de los aspectos que se buscó optimizar desde el inicio del proyecto fue ladocumentación, tanto del diseño general como del código en sí mismo. Para estose seleccionaron dos herramientas también de código abierto que tienen la capa-cidad de trabajar en conjunto como si fueran una sola. Para la documentación delcódigo se utilizó Doxygen[39], una programa que tiene la capacidad de generarla documentación de una biblioteca a partir de comentarios especiales ubicadosen el código fuente. Para la escritura de los documentos de diseño se decidió uti-lizar la sintaxis Markdown[40] y procesarlos también con Doxygen para unificaren un solo sitio WEB toda la información del desarrollo. Para los diagramas UMLse utilizó PlantUML[41], una herramienta también de código abierto que puede

3.4. Desarrollo del firmware 45

funcionar en conjunto con Doxygen, y que permite generar los diagramas a partirde descripciones textuales muy simples y rápidas.

Finalmente, como entorno de desarrollo integrado se decidió utilizar Visual Stu-dio Code, un editor de código abierto desarrollado por Microsoft, que funcionaen las plataformas de Windows, Linux y MacOS indistintamente. Tiene ademásuna extensa biblioteca de plugins que le permiten extender la funcionalidad bá-sica. De esta forma fue posible agregarle el reconocimiento de la sintaxis en ellenguaje C en los comentarios Doxygen, en los documentos Markdown y en losdiagramas PlantUML. También se pudo disponer del procesamiento las adver-tencias por errores en la documentación devueltos por Doxygen, de la visuali-zación de los diagramas UML generados por PlantUML, de la ejecución de laspruebas unitarias mediente Ceedling y de la gestión del repositorio GIT que al-macenó el código. A estas herramientas debemos agregarles el ESP-IDF (EspressifIoT Development Framework)[42][43], el conjunto de bibliotecas y utilidades pro-vistas por el fabricante del procesador para el desarrollo del software para losprocesadores ESP32. De esta forma queda completo el entorno de desarrollo uti-lizado para el presente trabajo. En la tabla 3.1 se puede ver un resumen con elnombre de cada herramienta y una breve descripción de la función.

TABLA 3.1: Resumen de herramientas utilizadas en el desarrollodel firmware del presente trabajo.

Nombre Funcionalidad proporcionada

UnityVerificación de los resultados en las pruebas unitarias yreporte de las discrepancias

Fake FunctionFramework

Generación automática de funciones Mock y Stub pararesolver las dependencias en las pruebas unitarias

CeedlingResolución automáticamente de dependencias,compilación, ejecución y consolidación los resultados delas pruebas unitarias

GCOVDeterminación de la cobertura en las pruebas unitarias ygeneración de un reporte en forma de página WEB

CLOCGeneración de estadísticas con la proporción decomentarios y pruebas por línea de código fuente

DoxygenGeneración de la documentación consolidada con lainformación del diseño y del código en forma de unapágina WEB

PlantUMLGeneración los diagramas UML a partir de descripcionestextuales

GITMantenimiento de las versiones del código fuente delfirmware, de la documentación de diseño y de losdiagramas UML

ESP-IDFBiblioteca con los controladores y las herramientas dedesarrollo provistas por el fabricante de la plataforma

Visual StudioCode

Entorno de desarrollo integrado para la edición el códigofuente y el manejo centralizado de las herramientasutilizadas en el proyecto


3.4.2. Pruebas de integración en las tareas del sistema

La plataforma de desarrollo provista por el fabricante utiliza a FreeRTOS[44] co-mo sistema operativo de tiempo real, donde se ejecutan como tareas los serviciosde comunicaciones como el protocolo TCP/IP y el servidor HTTP. Esta versión deFreeRTOS ha sido modificada por el fabricante para poder ejecutarse en un proce-sador de doble núcleo como es ESP32[45]. Por estas razones, utilizar otro sistemaoperativo de tiempo real implicaría un esfuerzo de desarrollo muy importante,que excedería ampliamente los alcances del presente trabajo.

Lamentablemente FreeRTOS es un desarrollo complejo, que además de estar mo-dularizado para facilitar la portación a diferentes arquitecturas, tiene un códigoque puede personalizarse utilizando el archivo FreeRTOSConfig.h[46]. Todo estohacen que sea imposible generar automáticamente funciones Stub o Mock quepermitan implementar pruebas unitarias automatizadas en código que utiliza losservicios del sistema operativo.

Una de las primeras estrategias para poder conciliar la idea de aplicar TDD conlos problemas derivados de utilizar FreeRTOS fue dividir la aplicación en trescapas. De esta forma se buscó concentrar el código critico en los objetos de lacapa de controladores, y como estos no utilizan los servicios del sistema operativose pudieron desarrollar utilizando TDD. De todas formas esta solución no resultótotalmente satisfactoria, por lo que se siguió buscando una alternativa para poderejecutar pruebas automatizadas sobre las tareas.

La solución definitiva a este problema se obtuvo combinando la portabilidad deFreeRTOS y la capacidad de Ceedling de utilizar plugins. Para esto se desarrollóun plugin propio que analiza el código fuente del archivo de prueba para determi-nar si utiliza los servicios del sistema operativo. En este caso modifica el procesode compilación y enlazado para incluir una versión FreeRTOS que ejecuta comouna tarea dentro de un ambiente POSIX[47]. También modifica el código gene-rado para el runner de la prueba para iniciar el sistema operativo, y mueve lasecuencia de pruebas a una tarea de FreeRTOS que detiene el planificador comoultima operación.

De esta forma, Ceedling puede generar un ejecutable que inicia el sistema ope-rativo, ejecuta cada una de las pruebas en forma secuencial y termina una vezque se completaron las pruebas. Este comportamiento, que resulta natural en laspruebas automatizadas, es totalmente contrapuesto al uso normal de FreeRTOS,donde el sistema se inicia pero nunca se detiene. El resultado final de este desa-rrollo es la posibilidad de implementar pruebas automatizadas sobre las tareasde la capa de aplicación con las mismas herramientas utilizadas para el resto deldesarrollo.

3.4.3. Uso del tipo de abstracto de datos

Como ya se mencionó en la subsección 3.3.1, para el modelado del firmware seutilizó una metodología orientada a objetos. Uno de los inconvenientes de aplicaresta propuesta es que el lenguaje C, el más utilizado en el desarrollo de sistemasembebidos, no es un lenguaje orientado a objetos.

3.4. Desarrollo del firmware 47

Para resolver este problema existe una propuesta denominada ADT (Abstract Da-ta Type)[48][31] que, explotando el uso de punteros a estructuras, permite emularmuy fácilmente una programación orientada a objetos, utilizando el lenguaje Cestándar. Esta técnica considera un archivo de cabeceras (.h) como la interfaz pú-blica de la clase y el archivo de código fuente (.c) como la implementación priva-da, y plantea el siguiente patrón de programación:

1. La declaración incompleta de una estructura de datos en el archivo de cabe-ceras, que define el nombre pero sin enumerar los miembros. La declaraciónde esta estructura se realiza en forma completa en el archivo de código, ycada uno de sus campos es equivalente a un atributo privado del objeto.

2. La declaración de un puntero a esta estructura también en el archivo decabeceras. Este tipo de puntero podrá ser utilizado desde cualquier partedel proyecto, siempre que no se intente acceder al contenido de memoriareferenciado. Esto permite encapsular los atributos del objeto y evitar quepuedan ser alterados en forma externa.

3. Una o más funciones que devuelven como resultado un puntero a la estruc-tura declarado en el apartado anterior. Estas funciones son el equivalente alos constructores de la clase, y además son responsables de la alocación delespacio de memoria necesario para almacenar la nueva instancia del obje-to. Esta alocación podrá ser dinámica, y utilizar funciones como malloc, oestática mediante un arreglo de estructuras.

4. Varias funciones que reciben como primer parámetro el puntero retorna-do por las funciones constructoras, y que son equivalentes a los métodospúblicos de la clase.

Este patrón de programación permite generar un código que puede escalar muyfácilmente, ya que resulta irrelevante la cantidad de instancias de un mismo ele-mento. De esta forma, a pesar de que el software desarrollado solo puede contro-lar una puerta, puede inmediatamente funcionar con dos o más puertas con soloefectuar dos llamadas al constructor de la clase Puerta. En las siguientes fraccio-nes de código puede verse un ejemplo simplificado del patrón de programacióndescrito.

1 /* === Declaraciones de tipos de datos ====================== */2 //! Tipo de datos para referenciar a un objeto puerta3 typedef struct puerta_s * puerta_t;4

5 /* === Declaraciones de funciones externas ================== */6 //! Función para instanciar un objeto puerta7 puerta_t PuertaCrear(void);8

9 //! Función para configurar una puerta10 bool PuertaConfigurar(puerta_t puerta, tiempo_t apertura);11

12 //! Función para liberar la puerta y permitir un ingreso13 void PuertaLiberar(puerta_t puerta);

ALGORITMO 3.1: Porción simplificada del archivo de cabecera conla interfaz publica de la clase Puerta.

1 /* === Definicion y Macros ================================== */2 //! Cantidad maxima de puertas alocadas estaticamente3 #define PUERTAS_CANTIDAD 1


4

5 /* === Declaraciones de tipos de datos ====================== */6 //! Estructura que describe la información de una puerta7 struct puerta_s {8 puerta_estado_t estado;9 tiempo_t apertura;

10 tiempo_t espera;11 };12

13 /* === Definiciones de funciones internas =================== */14 //! Aloca la memoria necesaria para un nuevo objeto puerta15 static puerta_t CrearInstancia(void) {16 puerta_t resultado = NULL;17

18 static int usadas = 0;19 static struct puerta_s puertas[PUERTAS_CANTIDAD] = {0};20

21 if (usadas < sizeof(puertas) / sizeof(struct puerta_s)) {22 memset(&puertas[usadas], 0, sizeof(struct puerta_s));23 resultado = &puertas[usadas];24 usadas++;25 }26 return resultado;27 }28

29 /* === Definiciones de funciones externas =================== */30 puerta_t PuertaCrear(void) {31 puerta_t self = CrearInstancia();32

33 if (self != NULL) {34 self->estado = PUERTA_CERRADA;35 self->espera = 0;36 }37 return self;38 }39

40 bool PuertaConfigurar(puerta_t self, tiempo_t apertura) {41 bool resultado = false;42

43 if (self != NULL) {44 self->apertura = apertura;45 resultado = true;46 }47 return resultado;48 }49

50 void PuertaLiberar(puerta_t self) {51 if (self != NULL) {52 if (self->estado == PUERTA_CERRADA) {53 self->espera = self->apertura - 1;54 self->estado = PUERTA_LIBERADA;55 }56 }57 }

ALGORITMO 3.2: Porción simplificada del archivo de códigofuente con la implementación de la clase Puerta.

49

Capítulo 4

Ensayos y Resultados

En este capítulo se detallan las pruebas efectuadas sobre el hardware y el firmwa-re a lo largo del desarrollo y se analizan los resultados obtenidos.

4.1. Pruebas de concepto

Para determinar la factibilidad de los objetivos planteados en la sección 1.3 ypoder, al mismo tiempo, cumplir con los requerimientos funcionales detalladosen la sección 2.4.1, se implementó en la primera etapa del proyecto un modelodestinado validar todas las suposiciones efectuadas en el diseño preliminar. Paraesto se utilizó una placa de evaluación ESP32-DEVKITC-32D-F[49] ofrecida porla firma Expressif, pensada para facilitar este tipo de procesos. Usando esta placacomo núcleo, se construyó en forma cableada una maqueta de lo que sería elequipo definitivo. Una versión de este montaje puede observase en la figura 4.1.

FIGURA 4.1: Imagen con el montaje de componentes en torno a laplaca de evaluación utilizado para la prueba de concepto.

De forma similar, utilizando los ejemplos de software provisto por el fabricante enel ESP-IDF[42][43], se empezaron a estudiar y probar las bibliotecas de softwareque se utilizarían en el desarrollo. Así se pudo validar cada uno de los bloques del

50 Capítulo 4. Ensayos y Resultados

código, para empezar a integrarlos en lo que sería la primera versión del firmwaredefinitivo.

Como resultado de este proceso se obtuvo una primera versión del equipo quepodía leer una tarjeta de proximidad, determinar la fecha y hora mediante unRTC, escribir en una tarjeta de memoria microSD el identificador de la etiquetaRFID leída junto con la fecha y hora del evento, y transmitir esta informaciónmediante WiFi a una computadora.

4.2. Pruebas funcionales del hardware

La fabricación del prototipo de hardware se dividió en dos etapas: primero semontaron todos los componentes correspondientes a la etapa de alimentacióndel equipo para verificar que todas las tensiones generadas fueran correctas. Acontinuación se montaron el resto de los componentes, y se verificó, en formaordenada, el correcto funcionamiento de cada uno utilizando las siguientes prue-bas:

1. Para verificar el funcionamiento del procesador se lo configuró para iniciaren modo bootloader y grabarle un programa de prueba. De esta forma sedeterminó que el procesador no completaba el proceso de reset porque fal-taba una resistencia de pull-up en el terminal de Enable. Para resolver esteproblema se agregó la resistencia R27, que se puede ver en la figura 7.

2. Continuando con la verificación del procesador, se lo configuró para iniciaren modo normal y ejecutar el programa cargado en el apartado anterior.Durante esta prueba se determinó que el procesador no podía iniciar enmodo normal porque faltaba una resistencia de pull-up en el terminal quedetermina el modo de arranque. Para resolver este problema se agregó laresistencia R28, que se puede ver en la figura 7.

3. Con el procesador en funcionamiento, se probaron las entradas y salidasdigitales con programas simples que activan una salida como respuesta aun cambio en una entrada. Para facilitar la identificación de las causas delos problemas, todos estos programas de prueba utilizaron las funciones deconsola disponibles en este procesado. De esta forma se pueden ver en unaconsola serial de la computadora de desarrollo mensajes generados en elprograma del procesador embebido utilizando el mismo puerto de comu-nicaciones por el que se realizan los cambios de firmware.

4. Para verificar el funcionamiento de la tarjeta microSD y el sistema de ar-chivos se utilizó un programa de prueba simple para crear un archivo yalmacenar en él una cadena de texto. Para certificar que funcionamientofuese correcto se retiró la tarjeta de memoria del equipo y se comprobó elcontenido del archivo en una computadora.

5. Para verificar la comunicación con el circuito integrado responsable de lalectura de las tarjetas de proximidad se utilizó directamente la maqueta delfirmware desarrollada en las pruebas de concepto. Tampoco se encontra-ron inconvenientes en la comunicación con la lectora de proximidad en elprototipo de hardware.

4.2. Pruebas funcionales del hardware 51

FIGURA 4.2: Imagen con las correcciones efectuadas en el prototi-po para resolver los errores detectados durante el montaje.

6. Para verificar el funcionamiento del RTC también se recurrió a la maque-ta del firmware utilizada en las pruebas del apartado anterior. En este casose encontró un error importante en las conexiones del circuito integrado,originado por un error en la numeración de los terminales al definir el com-ponente en Kicad, el programa donde se realizó el diseño de toda la placaelectrónica. Este error se puede apreciar en la figura 4.3, al comparar la in-formación correspondiente a la hoja de datos[50], en la mitad izquierda dela figura, con la definición del componente, ubicada en la mitad derecha, ve-mos que todos los terminales del lado derecho se encuentran invertidos. Enla figura se pueden observar las correcciones efectuadas sobre el prototipopara subsanar este problema.

FIGURA 4.3: Imagen que compara la asignación de terminales delRTC según la hoja de datos, a la izquierda, con la efectuada en la

huella del componente Kicad.

52 Capítulo 4. Ensayos y Resultados

7. Finalmente, a lo largo de los sucesivos reinicios de la placa se determinóque al conectar la alimentación del equipo, el procesador inciaba en modobootloader en lugar de ejecutar el programa ya grabado. Se comprobó tam-bién que esto no sucedía al efectuar un reset sin interrumpir la alimentacióndel equipo. Se determinó al capacitor C4 como el responsable y se removiódel diseño, como se puede observar en la figura .

4.3. Pruebas unitarias y de integración

Como ya se explicó en la sección 3.4 todo el desarrollo del firmware se planteóutilizando la metodología TDD. Esto implica que se escribieron pruebas unitariasy de integración para la mayoría de los componentes de software desarrollados.Una forma cuantitativa de evaluar estas pruebas son los informes de coberturagenerados Ceedling, la herramienta utilizada para ejecutar las pruebas automa-tizadas y consolidar los resultados. En la figura 4.4 se puede observar el informede cobertura, donde se puede apreciar que las pruebas automatizadas ejecutancasi del 95 % de las líneas de código escritas y explora más del 80 % de las combi-naciones en los saltos condicionales.

FIGURA 4.4: Imagen con el informe de cobertura de las pruebasautomatizadas efectuadas sobre el firmware.

Para dimensionar el esfuerzo realizado en la documentación y pruebas del códigose utilizó la herramienta CLOC. Esta permite contabilizar las líneas de códigofuente y las de comentarios para cada uno de los archivos. Aplicándola en formaseparada para el código de producción y las pruebas automatizadas se obtuvieronlos valores que se muestran en la tabla 4.1. Estos se pueden resumir en la siguienteafirmación: por cada diez líneas de código de producción se escribieron siete dedocumentación y cuatro de pruebas automatizadas.

4.4. Resultado de las pruebas 53

TABLA 4.1: Tabla resumen con las métricas de documentación ypruebas obtenidas para el firmware desarrollado.

Grupo Tipo Archivos Código Comentarios Relación

ProducciónCabeceras 25 1078 2419 2,24Código C 21 3770 1243 0,33

Pruebas Código C 11 1813 1010 0,56Totales 6661 4672 0,70

4.4. Resultado de las pruebas

Los resultados de las pruebas en la placa electrónica, después de efectuar las co-rrecciones mencionadas en las secciones 3.1 y 4.2, muestran un buen comporta-miento del diseño, el cual se mostró estable durante todas las pruebas del firm-ware. En lo que respecta al firmware, por haber sido desarrollado utilizando lametodología TDD, el mismo cumplió con el comportamiento esperado sin nece-sidad de efectuar cambios.

Es importante aclarar que las pruebas de aceptación del equipo no se ejecuta-ron en forma automática, ya que para ello es necesario el desarrollo de hardwa-re específico que genere los estímulos y verifique las reacciones de la placa bajoprueba. Por esta razón estas pruebas se ejecutaron manualmente, siguiendo losguiones escritos en Gherkin que se mostraron en la sección 2.4.3, y todas fueroncompletadas en forma exitosa por el equipo desarrollado.

55

Capítulo 5

Conclusiones

En el presente capítulo se resumen las conclusiones obtenidas al completar eltrabajo y se presentan los posibles pasos a seguir.

5.1. Resultados Obtenidos

Si se contrastan los objetivos planteados en la sección 1.3 con el desarrollo ex-puesto en capítulo 3, se obtienen las siguientes conclusiones:

1. El primer objetivo se cumplió, ya que el equipo desarrollado utiliza unmicrocontrolador ESP-32 que incorpora interfaces de comunicación WiFi yBluetooth.

2. El segundo objetivo también se cumplió, dado que el diseño actual incor-pora un RTC con respaldo de batería, que le permite mantener la fecha yhora válidas aun cuando se produzcan interrupciones en el suministro deenergía eléctrica.

3. El nuevo equipo está diseñado para controlar indistintamente cerraduraselectromagnéticas o motorizadas, por lo tanto el tercer objetivo también estácumplido.

4. El nuevo equipo mantiene las características generales el diseño original,pero al utilizar una API REST sobre HTTP, resulta más simple de gestionar.Además gracias al cambio de procesador y a la unificación de las unida-des funcionales, resulta más económico que el equipo original. Esto permiteafirmar que el cuarto objetivo también está cumplido.

5. El diseño y la codificación orientados a objetos utilizados para el desarrollodel firmware permite ampliar fácilmente las capacidades del equipo. Laspruebas automatizadas implementadas disminuyen la posibilidad de intro-ducir errores al hacer cambios en el código. Todo esto constituye una plata-forma modular que permite escalar las funcionalidades del equipo, por loque se puede afirmar que también el quinto objetivo está cumplido.

En la tabla 5.1 se repite el análisis de los equipos para control de acceso existentesen el mercado, incluyendo ahora al equipo desarrollado. Como puede observarseeste último ofrece mayor cantidad de funcionalidades a un precio muy competi-tivo.

56 Capítulo 5. Conclusiones

TABLA 5.1: Cuadro comparativo con otros equipos del mercado

Equipo Tecnología Forma de gestión Valor

EQUISERPunku

(Original)

Proximidad yremotos RF

Gestionado desde uncelular usando Bluetooth

$ 3.000

Tebas208NW

[TEBAS]Proximidad

Teclado numéricointegrado en el equipo

$ 4.000

ZKMA300IS [ZK]

Proximidady huellas

Computadora conectadamediante Ethernet

$ 10.000

ANVIZT5 Pro

[ANVIZ]

Proximidady huellas

Computadora conectadamediante Ethernet o USB

$ 8.000

EQUISERPunku

(Nuevo)

Proximidad(Mifare)

Gestionado desde un celularo una computadora

usando WiFi o Internet$ 3.000

Estos resultados permiten afirmar que el equipo desarrollado cumple con todoslos objetivos planteados, y que brinda a la empresa EQUISER una nueva opciónmás competitiva para participar en el mercado de los sistemas para control de ac-cesos. El esfuerzo invertido, principalmente en el desarrollo del firmware, generóuna plataforma confiable y flexible que permite, además, ampliar esta oferta enun futuro con muy poco esfuerzo.

5.2. Trabajo Futuro

En lo que respecta al equipo desarrollado el próximo paso es, naturalmente, lafabricación de un segundo prototipo de la placa electrónica que incluya todaslas correcciones efectuadas como parte de este trabajo. Este equipo debería sersometido a pruebas de campo con clientes reales para validar el correcto funcio-namiento en las condiciones normales de operación.

También es imprescindible el desarrollo de un software de gestión para dispositi-vos móviles que permita al cliente final operar con el equipo. La versión actual dePunku se gestiona con un software desarrollado en Java que solo funciona en dis-positivos Android, la intención es reemplazarlo por una aplicación híbrida quepueda ejecutarse tanto en iOS con en Android, utilizando el mismo código.

Desde el punto de vista académico se plantea también un trabajo derivado quepuede resultar muy interesante: la automatización total de las pruebas del equipo.En este sentido el plugin desarrollado para permitir la ejecución automatizada delas pruebas de integración que utilizan FreeRTOS es un paso importante, pero queno se pudo explotar completamente por falta de tiempo. Un desafío interesantees aplicar los conceptos de integración continua en este proyecto, incluyendo laspruebas de aceptación que involucran el uso de hardware especifico para simularla iteración de los usuarios con el equipo.

57

Bibliografía

[1] EQUISER. Sistema para control de Accesos PUNKU. URL:https://equiser.com.ar/punku/ (visitado 02-04-2020).

[2] Control de acceso TEBAS 208NW. URL:https://articulo.mercadolibre.com.ar/MLA-782128833-control-acceso-pestillo-electrico-cerradura-puerta-kit-ls-_JM (visitado 02-04-2020).

[3] Control de acceso ZK MA300. URL:https://articulo.mercadolibre.com.ar/MLA-799230606-control-de-acceso-biometrico-zkteco-huella-tarjeta-personal-_JM (visitado 02-04-2020).

[4] Control de acceso ANVIZ T5-Pro. URL:https://articulo.mercadolibre.com.ar/MLA-744676463-anviz-t5-pro-control-de-acceso-por-huella-anviz-t5pro-_JM (visitado 02-04-2020).

[5] NXP ColdFire. En: Wikipedia. Page Version ID: 917535671. 24 de sep. de2019. URL: https://en.wikipedia.org/w/index.php?title=NXP_ColdFire&oldid=917535671(visitado 02-04-2020).

[6] ESP32. En: Wikipedia, la enciclopedia libre. Page Version ID: 122252080. 24 dedic. de 2019. URL:https://es.wikipedia.org/w/index.php?title=ESP32&oldid=122252080(visitado 02-04-2020).

[7] RFID. En: Wikipedia, la enciclopedia libre. Page Version ID: 124378237. 19 demar. de 2020. URL:https://es.wikipedia.org/w/index.php?title=RFID&oldid=124378237(visitado 02-04-2020).

[8] Marine SA EM Microelectronic. EM4100 Datasheet. URL: https://www.digchip.com/datasheets/parts/datasheet/147/EM4100-pdf.php(visitado 02-04-2020).

[9] HID Global Corporation. HID Proximity, 125 kHz Cards and Readers. URL:https://www.hidglobal.com/sites/default/files/resource_files/hid-prox-br-en.pdf (visitado 02-04-2020).

[10] Mifare. En: Wikipedia, la enciclopedia libre. Page Version ID: 118503303. 25 deago. de 2019. URL:https://es.wikipedia.org/w/index.php?title=Mifare&oldid=118503303(visitado 02-04-2020).

[11] International Organization for Standardization. ISO - ISO/IEC14443-3:2011 - Contactless Identification cards. URL:https://www.iso.org/standard/50942.html (visitado 02-04-2020).

[12] International Organization for Standardization. ISO/IEC 18000-6:2010Radio frequency identification for item management. ISO. Library Catalog:www.iso.org. URL: https://www.iso.org/cms/render/live/en/sites/isoorg/contents/data/standard/04/61/46149.html (visitado 02-04-2020).

[13] S.L. Profile Software Services. Aplicaciones móviles híbridas: la solución máseficiente para el desarrollo multiplataforma. URL:

https://equiser.com.ar/punku/

https://articulo.mercadolibre.com.ar/MLA-782128833-control-acceso-pestillo-electrico-cerradura-puerta-kit-ls-_JM

https://articulo.mercadolibre.com.ar/MLA-782128833-control-acceso-pestillo-electrico-cerradura-puerta-kit-ls-_JM

https://articulo.mercadolibre.com.ar/MLA-799230606-control-de-acceso-biometrico-zkteco-huella-tarjeta-personal-_JM

https://articulo.mercadolibre.com.ar/MLA-799230606-control-de-acceso-biometrico-zkteco-huella-tarjeta-personal-_JM

https://articulo.mercadolibre.com.ar/MLA-744676463-anviz-t5-pro-control-de-acceso-por-huella-anviz-t5pro-_JM

https://articulo.mercadolibre.com.ar/MLA-744676463-anviz-t5-pro-control-de-acceso-por-huella-anviz-t5pro-_JM

https://en.wikipedia.org/w/index.php?title=NXP_ColdFire&oldid=917535671

https://en.wikipedia.org/w/index.php?title=NXP_ColdFire&oldid=917535671

https://es.wikipedia.org/w/index.php?title=ESP32&oldid=122252080

https://es.wikipedia.org/w/index.php?title=RFID&oldid=124378237

https://www.digchip.com/datasheets/parts/datasheet/147/EM4100-pdf.php

https://www.digchip.com/datasheets/parts/datasheet/147/EM4100-pdf.php

https://www.hidglobal.com/sites/default/files/resource_files/hid-prox-br-en.pdf

https://www.hidglobal.com/sites/default/files/resource_files/hid-prox-br-en.pdf

https://es.wikipedia.org/w/index.php?title=Mifare&oldid=118503303

https://www.iso.org/standard/50942.html

https://www.iso.org/cms/render/live/en/sites/isoorg/contents/data/standard/04/61/46149.html

https://www.iso.org/cms/render/live/en/sites/isoorg/contents/data/standard/04/61/46149.html

58 BIBLIOGRAFÍA

https://profile.es/blog/aplicaciones-moviles-hibridas-la-solucion-mas-eficiente-para-el-desarrollo-multiplataforma/ (visitado 02-04-2020).

[14] Ionic. About Ionic Cross-Platform Mobile Development Technologies. URL:https://ionicframework.com/about (visitado 02-04-2020).

[15] Protocolo de transferencia de hipertexto. En: Wikipedia, la enciclopedia libre.Page Version ID: 124562174. 25 de mar. de 2020. URL:https://es.wikipedia.org/w/index.php?title=Protocolo_de_transferencia_de_hipertexto&oldid=124562174 (visitado 02-04-2020).

[16] Paul J. Leach y col. Hypertext Transfer Protocol – HTTP/1.1. Library Catalog:tools.ietf.org. URL: https://tools.ietf.org/html/rfc2616 (visitado02-04-2020).

[17] Interfaz de programación de aplicaciones. En: Wikipedia, la enciclopedia libre.Page Version ID: 122204387. 22 de dic. de 2019. URL:https://es.wikipedia.org/w/index.php?title=Interfaz_de_programaci%C3%B3n_de_aplicaciones&oldid=122204387 (visitado 02-04-2020).

[18] json.org. Introducción a JSON. URL: https://www.json.org/json-en.html(visitado 02-04-2020).

[19] Bluetooth. En: Wikipedia, la enciclopedia libre. Page Version ID: 124673929.29 de mar. de 2020. URL:https://es.wikipedia.org/w/index.php?title=Bluetooth&oldid=124673929(visitado 02-04-2020).

[20] Wifi. En: Wikipedia, la enciclopedia libre. Page Version ID: 124481217. 22 demar. de 2020. URL:https://es.wikipedia.org/w/index.php?title=Wifi&oldid=124481217(visitado 02-04-2020).

[21] Institute of Electrical {and} Electronics Engineers. 830-1998 - IEEERecommended Practice for Software Requirements Specifications. URL:https://standards.ieee.org/standard/830-1998.html (visitado 02-04-2020).

[22] Gonzalo Menendez. Especificación de Requisitos según el estándar de IEEE830. URL:https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf(visitado 02-04-2020).

[23] John Ferguson Smart. BDD in action: Behavior-Driven Development for thewhole software lifecycle. OCLC: ocn869265205. Shelter Island, NY: ManningPublications, 2015. 353 págs. ISBN: 978-1-61729-165-4.

[24] Hardware abstraction. En: Wikipedia. Page Version ID: 944998580. 11 demar. de 2020. URL: https://en.wikipedia.org/w/index.php?title=Hardware_abstraction&oldid=944998580 (visitado 02-04-2020).

[25] Lenguaje unificado de modelado. En: Wikipedia, la enciclopedia libre. PageVersion ID: 124532478. 24 de mar. de 2020. URL: https://es.wikipedia.org/w/index.php?title=Lenguaje_unificado_de_modelado&oldid=124532478(visitado 02-04-2020).

[26] UML Diagram Types | Learn About All 14 Types of UML Diagrams. CreatelyBlog. Library Catalog: creately.com Section: diagrams. 1 de feb. de 2012.URL:https://creately.com/blog/diagrams/uml-diagram-types-examples/(visitado 02-04-2020).

[27] Árbol-B. En: Wikipedia, la enciclopedia libre. Page Version ID: 119251566.12 de sep. de 2019. URL: https://es.wikipedia.org/w/index.php?title=%C3%81rbol-B&oldid=119251566(visitado 02-04-2020).

https://profile.es/blog/aplicaciones-moviles-hibridas-la-solucion-mas-eficiente-para-el-desarrollo-multiplataforma/

https://profile.es/blog/aplicaciones-moviles-hibridas-la-solucion-mas-eficiente-para-el-desarrollo-multiplataforma/

https://ionicframework.com/about

https://es.wikipedia.org/w/index.php?title=Protocolo_de_transferencia_de_hipertexto&oldid=124562174

https://es.wikipedia.org/w/index.php?title=Protocolo_de_transferencia_de_hipertexto&oldid=124562174

https://tools.ietf.org/html/rfc2616

https://es.wikipedia.org/w/index.php?title=Interfaz_de_programaci%C3%B3n_de_aplicaciones&oldid=122204387

https://es.wikipedia.org/w/index.php?title=Interfaz_de_programaci%C3%B3n_de_aplicaciones&oldid=122204387

https://www.json.org/json-en.html

https://es.wikipedia.org/w/index.php?title=Bluetooth&oldid=124673929

https://es.wikipedia.org/w/index.php?title=Wifi&oldid=124481217

https://standards.ieee.org/standard/830-1998.html

https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf

https://en.wikipedia.org/w/index.php?title=Hardware_abstraction&oldid=944998580

https://en.wikipedia.org/w/index.php?title=Hardware_abstraction&oldid=944998580

https://es.wikipedia.org/w/index.php?title=Lenguaje_unificado_de_modelado&oldid=124532478

https://es.wikipedia.org/w/index.php?title=Lenguaje_unificado_de_modelado&oldid=124532478

https://creately.com/blog/diagrams/uml-diagram-types-examples/

https://es.wikipedia.org/w/index.php?title=%C3%81rbol-B&oldid=119251566

https://es.wikipedia.org/w/index.php?title=%C3%81rbol-B&oldid=119251566

BIBLIOGRAFÍA 59

[28] Transacción (informática). En: Wikipedia, la enciclopedia libre. Page Version ID:117849480. 30 de jul. de 2019. URL: https://es.wikipedia.org/w/index.php?title=Transacci%C3%B3n_(inform%C3%A1tica)&oldid=117849480(visitado 02-04-2020).

[29] ACID. En: Wikipedia, la enciclopedia libre. Page Version ID: 122122178. 18 dedic. de 2019. URL:https://es.wikipedia.org/w/index.php?title=ACID&oldid=122122178(visitado 02-04-2020).

[30] Diagrama de secuencia. En: Wikipedia, la enciclopedia libre. Page Version ID:119894705. 2 de oct. de 2019. URL: https://es.wikipedia.org/w/index.php?title=Diagrama_de_secuencia&oldid=119894705 (visitado02-04-2020).

[31] James W. Grenning y Jacquelyn Carter. Test-driven development forEmbedded C. Book version P2.0. The pragmatic programmers. Dallas, Tex.:The Pragmatic Bookshelf, 2012. 326 págs. ISBN: 978-1-934356-62-3.

[32] Ceedling. Throw The Switch. Library Catalog: www.throwtheswitch.org.URL: http://www.throwtheswitch.org/ceedling (visitado 02-04-2020).

[33] ThrowTheSwitch/Unity. original-date: 2012-01-26T19:52:36Z. 1 de abr. de2020. URL: https://github.com/ThrowTheSwitch/Unity (visitado02-04-2020).

[34] Mike Long. meekrosoft/fff. original-date: 2010-12-14T15:16:42Z. 30 demar. de 2020. URL: https://github.com/meekrosoft/fff (visitado02-04-2020).

[35] ElectronVector/fake_function_framework. original-date: 2016-05-23T04:19:44Z.18 de feb. de 2020. URL:https://github.com/ElectronVector/fake_function_framework (visitado02-04-2020).

[36] ThrowTheSwitch/Ceedling. original-date: 2012-01-26T19:53:53Z. 23 demar. de 2020. URL: https://github.com/ThrowTheSwitch/Ceedling(visitado 02-04-2020).

[37] Gcov. En: Wikipedia. Page Version ID: 919359198. 3 de oct. de 2019. URL:https://en.wikipedia.org/w/index.php?title=Gcov&oldid=919359198(visitado 02-04-2020).

[38] AlDanial. AlDanial/cloc. original-date: 2015-09-07T03:30:43Z. 1 de abr. de2020. URL: https://github.com/AlDanial/cloc (visitado 02-04-2020).

[39] Doxygen: Main Page. URL: http://www.doxygen.nl/ (visitado 02-04-2020).[40] Markdown. En: Wikipedia, la enciclopedia libre. Page Version ID: 124595693.

27 de mar. de 2020. URL: https://es.wikipedia.org/w/index.php?title=Markdown&oldid=124595693(visitado 02-04-2020).

[41] herramienta de código abierto que utiliza descripciones textuales simples paradibujar diagramas UML. URL: https://plantuml.com/es/ (visitado02-04-2020).

[42] ESP-IDF Programming Guide latest documentation. URL:https://docs.espressif.com/projects/esp-idf/en/latest/esp32/ (visitado02-04-2020).

[43] espressif/esp-idf. original-date: 2016-08-17T10:40:35Z. 1 de abr. de 2020. URL:https://github.com/espressif/esp-idf (visitado 02-04-2020).

[44] FreeRTOS. En: Wikipedia, la enciclopedia libre. Page Version ID: 120184821.11 de oct. de 2019. URL: https:

https://es.wikipedia.org/w/index.php?title=Transacci%C3%B3n_(inform%C3%A1tica)&oldid=117849480

https://es.wikipedia.org/w/index.php?title=Transacci%C3%B3n_(inform%C3%A1tica)&oldid=117849480

https://es.wikipedia.org/w/index.php?title=ACID&oldid=122122178

https://es.wikipedia.org/w/index.php?title=Diagrama_de_secuencia&oldid=119894705

https://es.wikipedia.org/w/index.php?title=Diagrama_de_secuencia&oldid=119894705

http://www.throwtheswitch.org/ceedling

https://github.com/ThrowTheSwitch/Unity

https://github.com/meekrosoft/fff

https://github.com/ElectronVector/fake_function_framework

https://github.com/ThrowTheSwitch/Ceedling

https://en.wikipedia.org/w/index.php?title=Gcov&oldid=919359198

https://github.com/AlDanial/cloc

http://www.doxygen.nl/

https://es.wikipedia.org/w/index.php?title=Markdown&oldid=124595693

https://es.wikipedia.org/w/index.php?title=Markdown&oldid=124595693

https://plantuml.com/es/

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/

https://github.com/espressif/esp-idf

https://es.wikipedia.org/w/index.php?title=FreeRTOS&oldid=120184821


60 BIBLIOGRAFÍA

//es.wikipedia.org/w/index.php?title=FreeRTOS&oldid=120184821(visitado 02-04-2020).

[45] ESP-IDF FreeRTOS Changes for ESP32. URL:https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/freertos-smp.html (visitado 02-04-2020).

[46] FreeRTOS. FreeRTOS Reference Manual V10.0.0. URL:https://www.freertos.org/wp-content/uploads/2018/07/FreeRTOS_Reference_Manual_V10.0.0.pdf(visitado 02-04-2020).

[47] FreeRTOS simulator for Posix/Linux. FreeRTOS. Library Catalog:www.freertos.org. URL: /FreeRTOS-simulator-for-Linux.html (visitado02-04-2020).

[48] Tipo de dato abstracto. En: Wikipedia, la enciclopedia libre. Page Version ID:123695779. 20 de feb. de 2020. URL: https://es.wikipedia.org/w/index.php?title=Tipo_de_dato_abstracto&oldid=123695779 (visitado02-04-2020).

[49] ESP32-DevKitC V4 Getting Started. URL:https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-devkitc.html (visitado 02-04-2020).

[50] MCP7940N - Real-Time Clock - Real-Time Clock/Calendar. URL:https://www.microchip.com/wwwproducts/en/MCP7940N (visitado02-04-2020).



https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/freertos-smp.html

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/freertos-smp.html

https://www.freertos.org/wp-content/uploads/2018/07/FreeRTOS_Reference_Manual_V10.0.0.pdf

https://www.freertos.org/wp-content/uploads/2018/07/FreeRTOS_Reference_Manual_V10.0.0.pdf

/FreeRTOS-simulator-for-Linux.html

https://es.wikipedia.org/w/index.php?title=Tipo_de_dato_abstracto&oldid=123695779

https://es.wikipedia.org/w/index.php?title=Tipo_de_dato_abstracto&oldid=123695779

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-devkitc.html

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-devkitc.html

https://www.microchip.com/wwwproducts/en/MCP7940N

Punku, control de...

Documents

Transcript of Punku, control de...