Controlador para el despacho de combustible en surtidores

CARRERA DE ESPECIALIZACIÓN ENSISTEMAS EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Controlador para el despacho decombustible en surtidores

Autor:Ing.Hanes Nahuel Sciarrone

Director:Mg. Lic. Santiago Germino (FIUBA)

Jurados:Esp. Ing. Alejandro Celery (FIUBA)

Mg. Ing. Christian Yanez Flores (FIUBA)Esp. Ing. Matias Paramidani (FIUBA)

Este trabajo fue realizado en la Ciudad Autónoma de Buenos Aires,entre marzo de 2020 y abril de 2021.

I

Resumen

En esta memoria se describe el desarrollo de hardware, firmware y software deun prototipo para el control de surtidores de combustible realizado para la

empresa ATIO International. Se presenta el desarrollo de una interfaz gráficapara la autentificación de los usuarios finales, el envío y recepción de

información de manera inalámbrica hacia un sistema de gestión contable, y latransmisión y recepción de comandos para el control de las bombas en los

surtidores.

Para llevar a cabo este trabajo se aplicaron conocimientos de programación demicrocontroladores, protocolos de comunicación y programación multitarea. Seutilizó un sistema operativo en tiempo real (FreeRTOS) y un software de control

de versiones (Git).

III

Agradecimientos

Dedicado a mi pareja que me acompañó durante la especialización, a mis padrespor apoyarme en todo momento, a mi director por incentivarme y aconsejarmepara dar lo mejor y a los docentes de la CESE por su excelente calidad educa-tiva por los conceptos aprendidos que fueron utilizados para la realización delproyecto.

V

Índice general

Resumen I

1. Introducción general 11.1. Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. Servidor de automatización Fusion . . . . . . . . . . . . . . . 11.1.2. Controlador CEM . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.3. Conectividad en controladores . . . . . . . . . . . . . . . . . 31.1.4. Interfaz de usuario en controladores de surtidores . . . . . . 4

1.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3. Alcance y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

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

2.1.1. Protocolo MQTT . . . . . . . . . . . . . . . . . . . . . . . . . 7Modelo de publicación/suscripción . . . . . . . . . . . . . . 8Cliente, broker y conexión MQTT . . . . . . . . . . . . . . . . 8Mensajes y tópicos . . . . . . . . . . . . . . . . . . . . . . . . 9Calidad de Servicio (QoS) . . . . . . . . . . . . . . . . . . . . 10

2.1.2. Protocolo NFC . . . . . . . . . . . . . . . . . . . . . . . . . . 12Etiquetas NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2. Conceptos sobre interfaz gráfica . . . . . . . . . . . . . . . . . . . . . 142.2.1. Principales componentes de una interfaz gráfica . . . . . . . 142.2.2. Formatos de color y consumo de memoria RAM . . . . . . . 15

Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Transparencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Profundidad del color . . . . . . . . . . . . . . . . . . . . . . 16

2.2.3. Consumo de memoria . . . . . . . . . . . . . . . . . . . . . . 162.2.4. Patrón de diseño en interfaces gráficas . . . . . . . . . . . . . 17

3. Diseño e implementación 193.1. Diagrama de bloques del sistema . . . . . . . . . . . . . . . . . . . . 193.2. Arquitectura de hardware . . . . . . . . . . . . . . . . . . . . . . . . 203.3. Arquitectura de firmware . . . . . . . . . . . . . . . . . . . . . . . . 233.4. Arquitectura de interfaz de usuario . . . . . . . . . . . . . . . . . . . 253.5. Implementación de la autentificación NFC . . . . . . . . . . . . . . 263.6. Protocolo de comunicación con el controlador de surtidores . . . . 28

4. Ensayos y resultados 314.1. Ensayos de la comunicación NFC . . . . . . . . . . . . . . . . . . . . 314.2. Ensayo de protocolo con controlador de surtidores . . . . . . . . . . 354.3. Ensayos de interfaz gráfica . . . . . . . . . . . . . . . . . . . . . . . . 37

VI

4.4. Ensayos de la comunicación MQTT . . . . . . . . . . . . . . . . . . . 394.5. Pruebas de integración del sistema . . . . . . . . . . . . . . . . . . . 41

5. Conclusiones 475.1. Resultados obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Bibliografía 49

VII

Índice de figuras

1.1. Controlador Fusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Dispositivo GP-Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Entradas de conexión controlador Fusion. . . . . . . . . . . . . . . . 31.4. Aplicación CEM-44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1. Ubicación de MQTTT sobre el modelo OSI. . . . . . . . . . . . . . . 72.2. Modelo de publicación/suscripción MQTT. . . . . . . . . . . . . . . 82.3. Flujo de conexión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4. Estructura del paquete de conexión al broker. . . . . . . . . . . . . . 92.5. MQTT - Ejemplo de tópico. . . . . . . . . . . . . . . . . . . . . . . . 102.6. Estructura del paquete de publicación y suscripción. . . . . . . . . . 102.7. QoS en 0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.8. QoS en 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.9. QoS en 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.10. Diagrama de funcionamiento de NFC. . . . . . . . . . . . . . . . . . 122.11. Principales componentes de una interfaz gráfica. . . . . . . . . . . . 142.12. Colores con 8 bits en cada componente RBG. . . . . . . . . . . . . . 152.13. Ejemplo de aplicar transparencia. . . . . . . . . . . . . . . . . . . . . 152.14. Modelo MVP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.15. Modelo MVP en interacción con el backend. . . . . . . . . . . . . . . 18

3.1. Diagrama en bloques del sistema. . . . . . . . . . . . . . . . . . . . . 193.2. Plataforma kit STM32F769I-Discovery utilizada en el trabajo. . . . . 213.3. Módulo ESP8266-01. . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4. Módulo PN532. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.5. Periféricos disponibles en el kit STM32F769I-Discovery. . . . . . . . 233.6. Pantalla WVGA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.7. Mecanismo de lectura por encuesta. . . . . . . . . . . . . . . . . . . 273.8. Mecanismo de lectura por IRQ. . . . . . . . . . . . . . . . . . . . . . 28

4.1. Diagrama de banco de prueba del módulo NFC. . . . . . . . . . . . 314.2. Parámetros del protocolo SPI en el analizador lógico. . . . . . . . . 324.3. Formato de trama de ACK. . . . . . . . . . . . . . . . . . . . . . . . 324.4. Formado de trama de comandos. . . . . . . . . . . . . . . . . . . . . 334.5. Comando para configurar cantidad de intentos. . . . . . . . . . . . 334.6. ACK del comando enviado. . . . . . . . . . . . . . . . . . . . . . . . 344.7. Respuesta del módulo NFC. . . . . . . . . . . . . . . . . . . . . . . . 344.8. Diagrama en bloque del banco de prueba del controlador con sur-

tidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.9. Parámetros del protocolo serial en el banco de prueba. . . . . . . . . 364.10. Captura de trama enviada al controlador de surtidores. . . . . . . . 364.11. Captura de trama recibida desde el controlador de surtidores. . . . 374.12. Primer prueba de firmware gráfico. . . . . . . . . . . . . . . . . . . . 38

VIII

4.13. Segunda prueba de firmware gráfico. . . . . . . . . . . . . . . . . . . 384.14. Obtener la dirección IP donde corren los programas. . . . . . . . . . 394.15. Primer prueba de uso del protocolo MQTT. . . . . . . . . . . . . . . 404.16. Segunda prueba de uso del protocolo MQTT. . . . . . . . . . . . . . 414.17. Inicio del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.18. Lectura del UID de una tarjeta NFC. . . . . . . . . . . . . . . . . . . 434.19. Mensaje enviado/ recibido por/al ESP8266. . . . . . . . . . . . . . . 444.20. Selector de cantidad a cargar. . . . . . . . . . . . . . . . . . . . . . . 454.21. Selección de parámetros para el despacho de combustible. . . . . . 454.22. Interacción con el controlador de surtidores. . . . . . . . . . . . . . 46

IX

Índice de tablas

2.1. Características de almacenamiento de chips NFC. . . . . . . . . . . 132.2. Formato de color en pixel vs la profundidad del color. . . . . . . . . 16

3.1. Periféricos utilizados en base a las funcionalidades del sistema. . . 203.2. Resumen de las tareas creadas. . . . . . . . . . . . . . . . . . . . . . 243.3. Stack consumido en FreeRTOS. . . . . . . . . . . . . . . . . . . . . . 25

4.1. Resumen de ensayos realizados. . . . . . . . . . . . . . . . . . . . . 46

XI

1

Capítulo 1

Introducción general

En este capítulo se realiza una descripción de los controladores de surtidores másutilizados comercialmente, como también, ciertas características de estos equiposque son explotadas en el desarrollo del trabajo.

1.1. Estado del Arte

Existe una amplia gama de controladores de surtidores que son ofrecidos pordistintas empresas. A continuación se presentan dos opciones disponibles en elmercado con sus características.

1.1.1. Servidor de automatización Fusion

El controlador Fusion, comercializado por la compañía Wayne FUELING SYS-TEMS, es un dispositivo de control que reduce los costos de implementación ypuesta en marcha por presentar una única herramienta que permite visibilizarlos dispositivos conectados, reducir los costos de mantenimiento y reducir lospotenciales puntos de falla. En la Figura 1.1 se muestra el dispositivo en cuestión[1].

FIGURA 1.1. Controlador Fusion.

2 Capítulo 1. Introducción general

El controlador Fusion implementa la funcionalidad de los siguientes dispositivos:

• Controlador de estación de servicio.

• Sistema de indicador de nivel automático.

• Consola de venta sólo de combustible.

• Cajas de interfaz y de distribución.

• Controladores de terceros.

De esta forma se abaratan los costos y se realiza la instalación de un único equipo.

1.1.2. Controlador CEM

El controlador CEM, comercializado por la compañía GILBARCO VEEDER-ROOT,es una herramienta que posee la capacidad de conectarse digitalmente con lossurtidores del mercado mediante su Dispositivo GP-Box mostrado en la Figura1.2 [2].

FIGURA 1.2. Dispositivo GP-Box.

Esta herramienta proporciona un conjunto de funcionalidades enumeradas a con-tinuación:

• Realizar control total de todos sus despachos por pico de surtidor.

• Menú totalmente configurable por niveles de acceso a usuarios que permiteel manejo de playeros, supervisores, encargado y jefe de estación.

• Seguimiento de caja, cierre de turno, cierre del día y del mes.

• Manejo de diferentes niveles de precios por surtidores.

• Manejo de cambio de precios instantáneos y cambios de precios programa-dos.

• Visualizar la capacidad teórica en tanques.

• Visualizar e imprimir los movimientos en reportes para el análisis de susventas.

• Manejo de despachos pre-seteados desde la CONSOLA CEM-44 tanto enlitros como en pesos.

• Opción de modos de despachos automático, semi-automático y operador.

1.1. Estado del Arte 3

1.1.3. Conectividad en controladores

La conectividad en los controladores proporciona grandes beneficios como per-mitir la gestión y el control de los procesos de forma remota y en tiempo real,el aumento de la eficiencia y la mejora en la toma de decisiones y acciones demantenimiento del equipo instalado. En definitiva, esto conlleva a un ahorro decostos.

La conectividad es la única manera de interactuar con los controladores que, enla mayoría de los casos, son equipos con periféricos básicos y que se encuentranen lugares de difícil acceso.

Los principales medios de conectividad son las comunicaciones inalámbricas oseriales. Los protocolos de comunicación son poco estandarizados y en ciertoscasos creados por las compañías que fabrican los equipos. Las principales funcio-nalidades son:

• Configuración de los equipos.

• Extracción de datos para la utilización de reportes.

• Interfaz para comandar al controlador y por ende a los surtidores conecta-dos.

• Realizar el mantenimiento del equipo.

• Actualización de parámetros en los surtidores (por ejemplo: cambio de pre-cios).

En la figura 1.3 se muestra las entradas de conexión que posee un controladorFusion a modo de ejemplo.

FIGURA 1.3. Entradas de conexión controlador Fusion.

Como se puede apreciar se encuentran conexiones de entrada serial, entrada Et-hernet y una conexión de antena para comunicaciones inalámbricas cómo Wi-Fi.También, en la mayoría de los controladores se encuentran entradas de moni-tor VGA, entrada HDMI y conexiones por USB con la única aclaración que estasentradas sólo se utilizan con el fin de poner en marcha o casos donde el manteni-miento por vía remota no resuelve el problema.

4 Capítulo 1. Introducción general

1.1.4. Interfaz de usuario en controladores de surtidores

Como se muestra en las figuras 1.1 y 1.2, los controladores son equipos que noposeen una pantalla, un teclado y un mouse por lo que la interacción con losusuarios finales siempre se realiza a través de dispositivos externos o aplicacionesejecutadas en una computadora.

Como ejemplo se muestra en la figura 1.4 el programa que utilizan los fabricantesdel controlador CEM para operar contra éste [2].

FIGURA 1.4. Aplicación CEM-44.

Para el caso del controlador Fusion, se utiliza un sistema operativo como Linuxo Windows donde se ejecutan programas que establecen vías de comunicación.Entonces, equipos externos denominados comúnmente puntos de venta (TPV)son los que habilitan el manejo del equipo. Esto genera la necesidad no sólo dela compra del controlador en sí, sino también un tercer dispositivo que haga deinterfaz para operar con él.

1.2. Motivación

Viendo las características en los controladores de surtidores, se planteó por partede la compañía ATIO International realizar un equipo que:

• Haga de interfaz gráfica de los controladores.

• Permita comunicarse con los controladores que son utilizados en la compa-ñía.

• Permita utilizar las herramientas de gestión con las que la compañía cuenta.

• Que pueda autentificar a los usuarios para ingresar estos datos al sistemade gestión.

La idea principal es proporcionar un producto de bajo costo que aproveche lainfraestructura de ATIO International en sistemas de gestión. De esta forma seofrece una nueva alternativa al mercado que, al ser de bajo costo, se espera queatraiga nuevos clientes y disminuya la dependencia que tiene la compañía en

1.3. Alcance y objetivos 5

relación con terminales de pago [3] que generan costos elevados en la línea deproducción.

1.3. Alcance y objetivos

1.3.1. Objetivos

El objetivo de este trabajo fue desarrollar un prototipo operativo de un sistemaque interactúe con el controlador de surtidores y utilice el sistema de gestión de lacompañía en conjunto con mecanismos de autenticación a distancia. Este trabajotiene como alcance formar las bases de un futuro producto para el mercado desuministro de combustibles que sea una alternativa más sencilla a los ya ofrecidosen la industria.

1.3.2. Alcance

El alcance del presente trabajo involucra el desarrollo del firmware del microcon-trolador encargado de configurar la interfaz para:

• Comandar el módulo de autentificación.

• Comandar la pantalla táctil y las memorias externas usadas.

• Comandar el módulo de conexión inalámbrica.

• La comunicación con el controlador de surtidores.

Dentro del desarrollo del Software se incluye:

• Lógica para renderizar las pantallas gráficas y manejar el flujo de la aplica-ción.

• Lógica para el envío de datos a través de Internet.

• La interacción con el controlador de surtidores.

• Extracción del identificador del cliente utilizando tarjetas de proximidad.

El trabajo no incluye los siguientes puntos:

• Creación de un nuevo sistema de gestión de despachos en Internet.

• Utilización del sistema de gestión ya implementado por ATIO International.Esto se debe a la falta de soporte para protocolos utilizados en Internet delas Cosas (IoT - Internet of Things).

7

Capítulo 2

Introducción específica

En este capítulo se exponen los protocolos utilizados y los conceptos de las tec-nologías aplicadas en el trabajo.

2.1. Protocolos de Comunicación

En esta sección se explican en profundidad los distintos protocolos de comunica-ción aplicados en el desarrollo del trabajo. Estos son:

• Protocolo MQTT.

• Protocolo NFC.

2.1.1. Protocolo MQTT

El protocolo MQTT (Message Queuing Telemetry Transport) [4] es un protocolo detransporte liviano ubicado en las capas superiores del Modelo OSI como se mues-tra en la Figura 2.1. Fue diseñado para el envío de datos en aplicaciones que re-quieren muy poco ancho de banda y pocos recursos para su funcionamiento.

FIGURA 2.1. Ubicación de MQTTT sobre el modelo OSI.

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

Estas características hacen que MQTT sea uno de los protocolos más utilizados enproyectos de IoT. Para entender el funcionamiento del protocolo MQTT se tienenque presentar los siguientes conceptos:

• Modelo de publicación/suscripción.

• Cliente, broker y conexión MQTT.

• Mensajes y tópicos.

• Calidad de servicio (QoS - Quality of Service).

Modelo de publicación/suscripción

El primer concepto a entender es el modelo de publicación/suscripción que seilustra en la figura 2.2. En este modelo, los dispositivos puede publicar mensajesen tópicos o suscribirse a los que sean de interés para recibir los mensajes publi-cados.

A diferencia del modelo cliente/servidor en donde ambas partes se comunicandirectamente, en este sistema, se desacopla tanto el cliente que envía el mensajecomo el o los clientes que están suscriptos al tópico y lo reciben.

La conexión entre ellos es manejada por una tercera parte llamada broker MQTT,cuyo trabajo es filtrar todos los mensajes que se reciben de los diferentes clientesy distribuirlos correctamente a sus suscriptores.

FIGURA 2.2. Modelo de publicación/suscripción MQTT.

Cliente, broker y conexión MQTT

En cuanto a su arquitectura, MQTT sigue una topología estrella donde existe unnodo central o broker con capacidad de trabajar con un gran número de clientes.

El broker MQTT es el responsable de recibir los mensajes, filtrarlos y distribuirlossegún corresponda. Es tarea del broker determinar qué cliente está suscripto a quétópico y enviar el mensaje correspondiente a estos suscriptores.

Un cliente MQTT es cualquier dispositivo (desde un simple microcontroladorhasta un servidor propiamente dicho) que ejecuta una biblioteca MQTT y se co-necta con un broker MQTT sobre una red determinada.

2.1. Protocolos de Comunicación 9

La conexión MQTT es siempre entre un cliente y el broker, como se ilustra en lafigura 2.3. Los clientes nunca se conectan entre ellos directamente. Para iniciaruna conexión, el cliente envía el mensaje CONNECT al broker. Este responde conun mensaje CONNACK y un código de estado. Una vez que la conexión quedaestablecida, el broker la mantiene abierta hasta que el cliente envía un comandode desconexión o la conexión se rompe.

FIGURA 2.3. Flujo de conexión.

El puerto estándar para comunicación no encriptada es 1883, mientras que parauna comunicación encriptada con SSL/TLS [5] se utiliza el puerto 8883. Duranteel handshake SSL/TLS el cliente valida el certificado del servidor para autenticar-lo. El cliente puede también proveer un certificado al broker durante el handshakeque podrá ser utilizado por el broker para autenticarlo. Si bien no es parte de la es-pecificación MQTT, se ha vuelto habitual que los brokers admitan la autenticaciónde clientes con certificados SSL/TLS.

Debido a que el protocolo MQTT apunta a ser un protocolo para dispositivos deIoT con recursos limitados, SSL/TLS puede no ser siempre una opción deseablepor presentar una complejidad mayor.

Para estos casos la autenticación se realiza con un nombre de usuario y una con-traseña de texto simple que el cliente envía al servidor como parte de la secuen-cia de paquetes CONNECT/CONNACK. Algunos brokers aceptan clientes anó-nimos. En tales casos, el nombre de usuario y la contraseña simplemente se dejanen blanco.

En la figura 2.4 se muestra la estructura del mensaje de conexión enviado al broker[6].

FIGURA 2.4. Estructura del paquete de conexión al broker.

Mensajes y tópicos

Los mensajes son la información que se quiere intercambiar entre los dispositivos,ya sean comandos o datos en sí mismos.

En MQTT la palabra tópico hace referencia a una cadena de caracteres que el bro-ker utiliza para filtrar mensajes para cada cliente conectado. Los tópicos puedenposeer uno o más niveles. Cada nivel de tópico está separado por una barra. Enla Figura 2.5 se muestra un ejemplo de un tópico para reporte de temperatura.


FIGURA 2.5. MQTT - Ejemplo de tópico.

No es necesario que los clientes establezcan previamente el tópico antes de haberpublicado o haberse suscripto. Este se crea en el instante de hacer la publicacióno suscripción. El broker acepta cada tópico válido sin previa inicialización.

En la Figura 2.6 se muestran las estructuras de los paquetes para realizar unasuscripción y la publicación donde se puede observar el agregado del tópico [7].

(A) Publicación.

(B) Suscripción.

FIGURA 2.6. Estructura del paquete de publicación y suscripción.

Calidad de Servicio (QoS)

La calidad de servicio (QoS - Quality of Service) es un acuerdo entre quien envíaun mensaje y el receptor del mismo, que define la garantía de entrega para unmensaje específico. Aunque los niveles más altos de QoS son más confiables, ge-neran más latencia y consumen mayor ancho de banda, por lo que los clientessuscriptos pueden especificar el nivel más alto de QoS que les gustaría recibir.Existen tres tipos de QoS en MQTT clasificados según la garantía de entrega:

• A lo sumo una vez (QoS 0): es el mínimo nivel de QoS. El mensaje se envíacomo máximo una vez y ante un fallo se produce la pérdida del mismo.En esta calidad de servicio no hay garantía de entrega como se ilustra enla Figura 2.7. El receptor no confirma la recepción del mensaje y éste no seguarda ni es retransmitido por el publicador. El mensaje es enviado por elbroker al cliente, y el broker no sabe si el mensaje fue entregado exitosamente.


FIGURA 2.7. QoS en 0.

• Al menos una vez (QoS 1): el nivel 1 de QoS garantiza que el mensaje se en-tregue al menos una vez al receptor. Puede entregarse varias veces si hay unfallo antes que el emisor reciba una confirmación. En la Figura 2.8 se mues-tra cómo el emisor del mensaje lo almacena hasta que recibe un paquetePUBACK que confirma la recepción. Es posible que un mensaje se envíe oentregue varias veces.


• Exactamente una vez (QoS 2): es el máximo nivel de QoS en MQTT. El men-saje se entrega siempre y debe ser almacenado en el emisor hasta que sereciba la confirmación de entregado. Este nivel de servicio mostrado en laFigura 2.9, garantiza que cada mensaje sea recibido sólo una vez por los re-ceptores suscriptos. El QoS 2 es el nivel de calidad de servicio más seguropero con mayor latencia. La garantía es proporcionada por al menos dosflujos de solicitud/respuesta (un acuerdo de cuatro partes) entre el emisory receptor.

Estos utilizan el identificador de paquete del mensaje PUBLISH originalpara coordinar la entrega. El cliente publica un mensaje con QoS 2. El brokerlo recibe y contesta la recepción exitosa con PUBREC. El cliente recibe elmensaje de confirmación que envió el broker y envía otro llamamo PUBRELque confirma la recepción. Por ultimo, el broker envía el mensaje PUBCOMP.



2.1.2. Protocolo NFC

La Comunicación de Campo Cercano o Near Field Communication (NFC), por sussiglas en inglés, es una tecnología de comunicación inalámbrica, de corto alcancey alta frecuencia que permite el intercambio de datos entre dispositivos. El proto-colo de comunicación y formato de intercambio de datos se encuentra basado enel estándar ISO14443 [8].

Físicamente NFC se basa en el acoplamiento inductivo entre un dispositivo detransmisión y uno de recepción. La comunicación se produce si los dos dispositi-vos son compatibles y se encuentran a unos pocos centímetros uno del otro (4cmes el máximo teórico).

Dentro de las comunicaciones NFC existen dos tipos:

• Activa: ambos dispositivos generan sus propios campos magnéticos paratransferir los datos entre ellos.

• Pasiva: uno de los dispositivos crea un campo mágneticosy el otro se apro-vecha de él para transferir los datos.

Cuando dos dispositivos con NFC se aproximan lo suficiente para que sus cam-pos magnéticos entren en contacto, se produce un acoplamiento por inducciónmagnética para transferir energía y datos entre ellos. Este acoplamiento magné-tico es la gran diferencia entre NFC y otros dispositivos como Bluetooth y Wi-Fi.[9]

En la Figura 2.10 se muestra un diagrama del funcionamiento de NFC por induc-ción [10].

FIGURA 2.10. Diagrama de funcionamiento de NFC.

La tecnología NFC ofrece tres tipos de funciones:

• El intercambio de información entre dos dispositivos por proximidad a tra-vés de Peer-to-Peer (P2P).

• Pagos rápidos y seguros con el teléfono móvil, utilizando el protocolo HostCard Emulation (HCE).

• Leer y escribir etiquetas NFC.


De las funcionalidades mencionadas, en este trabajo se utilizó la lectura de eti-quetas NFC.

Etiquetas NFC

Las etiquetas NFC o Tags NFC son transpondedores RFID que operan a 13.56MHz. Son pequeños chips conectados a una antena que poseen un código únicoy una parte de memoria regrabable. La antena permite que el chip interactúe conun reproductor de NFC, como un teléfono inteligente.

Todas las etiquetas NFC tienen un código único, llamado UID o Unique ID, ubi-cado en una parte de la memoria que no se puede sobreescribir. A través del UIDse puede asociar de forma única una etiqueta de NFC a un objeto o persona ydesarrollar aplicaciones que los identifiquen e interactúen.

Las etiquetas NFC pueden o no utilizar encriptación como medio de seguridadpara evitar la lectura de datos. A continuación se enumeran las etiquetas NFC enorden ascendente según su seguridad [11]:

• NTAG203, NTAG210, NTAG212, NTAG213, NATG215 Y NTAG216 (No tie-ne encriptación)

• Mifare Classic® 1k.

• MIFARE® DESFire® EV1 / EV2 / Light.

• MIFARE Plus®/ ICODE® DNA

• MIFARE Ultralight® C

• NTAG413 y NTAG424 DNA

Las etiquetas NFC también son utilizadas para almacenar información ademásdel uso como método de autentificación. La capacidad de almacenamiento de-pende mucho del tipo de chip NFC usado. En la tabla 2.1 se muestra un resumende la capacidad de algunas en función del tipo de chip [12].

TABLA 2.1. Características de almacenamiento de chips NFC.

CaracterísticasNTAG

203NTAG

210NTAG

212NTAG

213NTAG

215NTAG

216Mifare

Classic®

1k

MIFAREUltralight®

CTotal de memoria(Bytes)

168 80 164 180 540 924 1024 192

Memoria disponible(Bytes)

137 48 128 144 504 888 716 148

Longitud máximade URL (Caracteres)

132 41 122 132 492 854 710 132

Longitud máximade un texto(Caracteres)

130 39 120 130 490 852 708 130

Número de serie -UID (Bytes)

7 7 7 7 7 7 4 - 7 4 - 7


2.2. Conceptos sobre interfaz gráfica

Los principales conceptos sobre el diseño de interfaces gráficas son:

• Componentes que lo conforman.

• Formatos de color.

• Variables que afectan al consumo de memoria.

• Patrones de diseño más utilizados.

Al entender estos conceptos se puede dar una noción de los factores a tener encuenta al momento de tomar la decisión de realizar una aplicación gráfica.

2.2.1. Principales componentes de una interfaz gráfica

El hardware de una interfaz de usuario gráfica (GUI: Graphical User Interface) es-tá conformada por cuatro componentes principales involucrados directamente.Estos se pueden observar en la figura 2.11 junto a la forma en que interactúan[13].

FIGURA 2.11. Principales componentes de una interfaz gráfica.

• Microcontrolador (MCU): se encarga de realizar todo el procesamiento pe-sado:

• Lee las imágenes en la memoria flash y luego las escribe en RAM.

• Calcula los colores resultantes del diseño en la GUI

• Transfiere la imagen en RAM a la pantalla.

• RAM: memoria en donde se almacena la imagen resultante que se dibujaen la pantalla. Esta memoria es leída y escrita por el MCU al actualizarlos gráficos. En función de los requerimientos en el tamaño de la pantallamedido en píxeles se utiliza la RAM interna del MCU y/o una externa encaso de no ser suficiente la interna.

• Flash: memoria en donde se guardan los datos estáticos como imágenes,fuentes y textos. La flash es leída por el MCU y el contenido es escrito en laRAM.

2.2. Conceptos sobre interfaz gráfica 15

La mayoría de las veces se utiliza una flash externa, ya que la interna delMCU rara vez es suficiente para el contenido de las activos gráficos cómoimágenes y fuentes de texto a usar en el desarrollo.

• Pantalla: Es donde se muestra la imagen que es calculada por el MCU yluego almacenada en RAM. Esta imagen se conoce como framebuffer y seenvía de manera periódica hacia la pantalla.

2.2.2. Formatos de color y consumo de memoria RAM

El color en las GUI es un valor almacenado en el framebuffer dentro de la memoriaRAM que está limitado a la cantidad de posibles colores que se pueden represen-tar y mostrar en pantalla. El número de colores que un píxel puede representarimpacta directamente en la apariencia visual, en el consumo de memoria del fra-mebuffer y en el rendimiento del sistema.

Color

El color en un píxel está compuesto por tres componentes principales rojo, verdey azul de donde surgen las siglas RGB (Red - Green - Blue). La cantidad de bitsutilizados en cada componente determina los colores que pueden representarseal combinarlos. A modo de ejemplo, en la figura 2.12 se muestran algunos coloresque pueden ser formados en el caso de tener 8 bits en cada componente [13].

FIGURA 2.12. Colores con 8 bits en cada componente RBG.

Dentro de la representación de colores posibles se encuentra el caso de la escalade grises. Esta se representa por todos los colores cuyos tres componentes soniguales.

Transparencia

En ciertas aplicaciones la GUI necesita aplicar transparencia al color. Esta se defi-ne como un componente extra además de los tres básicos. Los colores con trans-parencia se mencionan como RGBA (Red - Green -Blue - Alpha). Cuando se necesitaun determinado valor de transparencia es necesario mezclar el valor del color conel componente alpha y así lograr el efecto deseado. Un ejemplo de esto se muestraen la figura 2.13 [13].

FIGURA 2.13. Ejemplo de aplicar transparencia.


Profundidad del color

La profundidad del color es el número de bits usados para describir cada colordel framebuffer. Esto se conoce como bits por píxel (bpp). Cuanto mayor cantidadde bits, mayor cantidad de colores pueden ser logrados. La ecuación 2.1 describela cantidad de colores en función de los bits utilizados.

Cantidad de colores posibles = 2bpp (2.1)

En función de la profundidad se pueden obtener los posibles formatos de color aconfigurar en el píxel . En la tabla 2.2 se muestran los más comunes en función dela profundidad de color [13].

TABLA 2.2. Formato de color en pixel vs la profundidad del color.

Profundidad Formato de pixel Cantidad de colores32 bpp RGBA8888 16777216 colores más la transparencia24 bpp RGB888 16777216 colores16 bpp RGB565 65536 colores6 bpp RGB222 32 colores4 bpp GRAY4 16 colores en escala de grises2 bpp GRAY2 4 colores en escala de grises1 bpp BW 2 colores en escala de grises

GRAY = Escala de grises.

BW = Blanco y negro.

2.2.3. Consumo de memoria

El cálculo de la memoria RAM para almacenar el framebuffer depende principal-mente de tres factores:

• Cantidad de framebuffers.

• Resolución de la pantalla en píxeles.

• Profundidad del color.

La memoria RAM necesaria se calcula con la ecuación 2.2:

Memoria consumida(Bytes) = [Resolución de la pantalla(Píxeles)×

Profundidad del color (bpp) × Cantidad de framebuffer]/8 (2.2)

La cantidad de framebuffers a utilizar varía en función de la complejidad de losgráficos a dibujar y a las características del hardware. Se presentan tres posiblescasos:

• Solo un framebuffer: ideal cuando la complejidad de los gráficos mostradosno produce efectos visuales indeseados, como por ejemplo, la superposiciónde imágenes. Se necesita tener la suficiente memoria RAM interna o externapara su almacenamiento.

2.2. Conceptos sobre interfaz gráfica 17

• Más de un framebuffer: permite dibujar gráficos complejos ya que la lectu-ra y el envío a la pantalla se realiza desde un framebuffer, mientras que enotro se escribe la siguiente imagen a dibujar. Requiere un consumo de me-moria que se multiplica por la cantidad de framebuffers pero requiere menorprocesamiento del MCU.

• Menos de un framebuffer: se utiliza un framebuffer de una capacidad de me-moria menor a la necesaria para almacenar el dibujo completo de una pan-talla. Esto es para aplicaciones ejecutadas en sistemas de muy baja capa-cidad de memoria RAM. La desventaja es la sobrecarga del MCU al tenerque realizar más operaciones de dibujo y más transferencia de datos haciala pantalla.

2.2.4. Patrón de diseño en interfaces gráficas

En el diseño de interfaces gráficas se implementan patrones de diseño. En el desa-rrollo del trabajo el patrón que se utilizó el Modelo-Vista-Presentador (MVP - Mo-del - View - Presenter) por ser uno de los más populares. Sus principales ventajasson:

• Separación de intereses: el código se divide en partes separadas. Cada unacon su propia responsabilidad, lo que hace el código más simple, reutiliza-ble y fácil de mantener.

• Pruebas unitarias: como la lógica de la interfaz de usuario UI (presenter) estáseparada de la capa visual (View), es más fácil probar las partes de formaaislada.

En la figura 2.14 se muestra de manera gráfica el patrón de diseño MVP [13].

FIGURA 2.14. Modelo MVP.

Todo lo que no forma parte de la UI en una aplicación es llamado Backend. Esteinteractúa con la UI a través del componente Model en el patrón MVP. El Backendes un componente de software que recibe eventos de la interfaz de usuario y envíaeventos a ésta. El sistema de Backend puede ejecutarse en una tarea independienteen el MCU, en un procesador independiente o en módulos en la Nube. En lafigura 2.15 se muestra lo explicado en este párrafo [13].


FIGURA 2.15. Modelo MVP en interacción con el backend.

Las responsabilidades de cada uno de los módulos del patrón de diseño MVPson:

• Modelo: almacenar información de estado para la UI. La memoria de lasvistas y los presentadores se libera al cambiar de pantalla, por lo que no sepueden utilizar para almacenar información que debe mantenerse a travésde las transiciones de pantalla.

Actúa como una interfaz entre el sistema Backend y la UI, transmitiendoeventos hacia y desde la pantalla actualmente activa.

• Vista: contiene los widgets (elementos de interacción como un botón o unabarra de desplazamiento) que son mostrados en la pantalla. Este móduloes el que observan los usuarios y capta las interacciones para mandarlas alpresentador.

• Presentador: es responsable de la lógica de negocio de la pantalla activa.Recibe los eventos del Backend que el Model envía y los eventos de la UIenviados por la View y decide qué acciones tomar.

19

Capítulo 3

Diseño e implementación

En el presente capítulo se especifican las características del hardware utilizado,se justifica la elección de la plataforma, se muestran los cálculos realizados paracumplir con los requerimientos de GUI y se explica la arquitectura del softwareque se implementado en cada uno de los módulos que conforma el sistema.

3.1. Diagrama de bloques del sistema

Para el desarrollo de este trabajo se realizó un análisis de los módulos y de losperiféricos involucrados. En el caso de los módulos, se buscó aquellos que estánampliamente disponibles en el mercado y del menor costo posible. A partir delanálisis se obtuvo el diagrama en bloques del sistema que se muestra en la figura3.1.

FIGURA 3.1. Diagrama en bloques del sistema.

El trabajo utiliza periféricos que pueden ser poco conocidos para el lector, por locual, se mencionan sus nombres y su funcionalidad dentro del MCU:

• DMA2D (Direct Memory Access 2D): se utiliza para movimientos y accesos amemoria de forma directa, sin intervención del procesador. Este periféricoes específico para gráfica y también permite hacer conversiones de coloresde píxeles automáticamente.

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

• QSPI (Quad SPI): interfaz para el manejo de memoria flash externa.

• FMC (Flexible memory controller): interfaz para realizar operaciones de escri-tura/lectura de memorias SDRAM externas.

• LTDC (LCD TFT Display Controller): interfaz de conexión paralela para elmanejo de pantallas LCD. Gracias a esta interfaz, no es necesario el agre-gado de hardware externo para el control de las pantallas, sino que todose realiza internamente en el MCU lo que permite la interacción con otrosperiféricos como el DMA2D para lograr un mejor rendimiento.

• Host DSI (Host Display serial interface): permite conectar pantallas gráficas alMCU en modo serial de alta velocidad. Por ser una interfaz serial reduce lacantidad de cables de conexión entre el MCU y la pantalla lo que facilita elruteo del PCB (Printed Circuit Board). La interfaz serie, en comparación conla interfaz paralela, transmite a menor cantidad de datos en cada ciclo dereloj. Esto se compensa al trabajar a una frecuencia más elevada de hasta500 MHz.

En la tabla 3.1 se muestra un resumen de los periféricos utilizados en base a lasfuncionalidad del sistema.

TABLA 3.1. Periféricos utilizados en base a las funcionalidades delsistema.

Periféricos FuncionalidadUART Comunicaciones inalámbricas

SPI Autentificación por NFCUART Comunicación con controlador de surtidoresQSPI

Control de interfaz gráficaFMC

DMA2DLTDC

Host DSI

3.2. Arquitectura de hardware

Para la arquitectura de hardware se tuvo en cuenta el análisis mostrado en la sec-ción 3.1 y los conceptos de la sección 2.2. Se optó por utilizar un kit en lugar deun diseño propio para poder cumplir con los plazos establecidos en la planifi-cación. Se consideró que el kit elegido tuviese a disposición el esquemático paraque luego de este trabajo, y con más tiempo de desarrollo, se simplifique la ta-rea de diseñar un PCB con el hardware y módulos necesarios. La plataforma dehardware para el desarrollo del trabajo es el kit STM32F769I-Discovery, el cual semuestra en la figura 3.2.

3.2. Arquitectura de hardware 21

(A) Lado trasero [14].

(B) Lado frontal [15].

FIGURA 3.2. Plataforma kit STM32F769I-Discovery utilizada en eltrabajo.

Se utilizaron módulos de hardware externo en el desarrollo del trabajo para cum-plir con las funcionalidades de:


• Comunicación inalámbrica: se utilizó el módulo ESP8266-01 de la compa-ñía Espressif, el cual cuenta con su propio stack TCP/IP y se maneja a tra-vés de la UART, utilizando comandos AT [16]. La incorporación del stackTCP/IP dentro del módulo permite el ahorro de memoria del MCU por nonecesitar implementarlo mediante una biblioteca, como por ejemplo, lwip(lightweight IP) [17]. En la figura 3.3 se muestra una imagen del módulo.

FIGURA 3.3. Módulo ESP8266-01.

• Autentificación por NFC: se utilizó un módulo en base al circuito integradoPN532. La interfaz de conexión con el módulo puede ser SPI, I2C o UARTy se optó por el periférico SPI como interfaz. El circuito integrado PN532permite la lectura de tarjetas NFC compatibles con el estandar ISO14443-A.Los tipos de etiquetas NFC que pueden ser leídos son:

• Mifare 1k.

• Mifare 4k.

• Mifare Ultralight.

En la figura 3.4 se muestra el módulo utilizado [18].

FIGURA 3.4. Módulo PN532.

Los puertos de expansión que permiten el acceso a los periféricos del kit sonmostrados en la figura 3.5.En estos puertos se conectaron el módulo NFC y lainterfaz de comunicación con el controlador de surtidores.

3.3. Arquitectura de firmware 23

FIGURA 3.5. Periféricos disponibles en el kit STM32F769I-Discovery.

El periférico SPI2 fue usado para conectar del módulo NFC junto con el GPIO D8para la detección de datos del mismo. La conexión con el controlador de surtido-res se realizó a través de la UART6, en la imagen se muestra como Serial6_TX ySerial6_RX.

3.3. Arquitectura de firmware

En el desarrollo del trabajo se utilizó un sistema operativo de tiempo real o RTOSpor sus siglas en inglés (Real-Time Operationing System), más específicamente FreeR-TOS [19]. La utilización de un RTOS permitió delegar la responsabilidad de admi-nistración del tiempo del MCU para concentrarse en la lógica de negocio del siste-ma. A su vez, se logró mayor escalabilidad ya que cada funcionalidad modular seconcentra en una tarea específica lo que permite agregar nuevas funcionalidades,de ser requeridas, sin necesidad de modificar lo ya implementado.

Para este trabajo se crearon las siguientes cuatro tareas:

• GUI: encargada de realizar el refresco de las pantallas gráficas, capturar loseventos del usuario y del backend para ir navegando a través del flujo denegocio y poder realizar operaciones.


• Lector NFC: encargado de activar el módulo NFC, procesar los datos de unalectura y enviar la información a la GUI para tomar decisiones de operación.

• Comunicación inalámbrica: comanda el módulo ESP8266, el armado y aná-lisis de paquetes a enviar/recibir a través del protocolo MQTT y procesar lainformación para mostrarla por la GUI.

• Comunicación con el controlador: envía o recibe mensajes al controlador desurtidores para realizar operaciones.

Para preguntar periódicamente por el estado del surtidor durante la operación decarga se empleó un reloj, que queda deshabilitado al finalizar la misma. FreeRTOSimplementa relojes a través de una tarea especial llamada service/daemon. Paraeste caso no se consideró como tal, sino como un reloj por tratarse de un serviciointerno del sistema operativo.

Se tuvieron en cuenta dos modalidades de funcionamiento en las tareas:

• Periódicas: se ejecutan indefinidamente mientras el sistema esté en ejecu-ción. Se especifica un tiempo de periodicidad en el cual la tarea se ejecutaautomáticamente.

• Por evento: son tareas que se encuentran la mayor parte del tiempo en mo-do bloqueante. Se debloquean cuando se recibe un evento externo de otrastareas.

En la tabla 3.2 se muestra un resumen de las tareas implementadas, la porción destack asignada, el nivel de prioridades y el modo de operación.

TABLA 3.2. Resumen de las tareas creadas.

Funcionalidad de latarea

Stack(Bytes)

Prioridad de latarea

Modo defuncionamiento

Comunicación conel controlador de

surtidores8312

osPriorityNormal3(27) Por evento

Comunicacióninalámbrica 4216

osPriorityNormal2(26) Por evento

Lector NFC 1144osPriorityNormal1

(25) Por evento

GUI 8312osPriorityNormal

(24) Periódica

Actualizador delestado del surtidor 256

osPriorityRealtime7(55) Periódica

Se vio la necesidad de crear señales de sincronismo para las siguientes operacio-nes:

• Colas: envío de eventos entre tareas.

• Semáforos contadores: recepción de datos por UART al utilizar interrupcio-nes.

• Semáforos binarios: inicializar la tarea de NFC y desbloquearla cuando serequiera una lectura de tarjeta.

3.4. Arquitectura de interfaz de usuario 25

• Mutexes: para evitar problemas de concurrencia en el uso de variables glo-bales.

En la tabla 3.3 se muestra un resumen del stack consumido por cada tarea y señalde sincronismo.

TABLA 3.3. Stack consumido en FreeRTOS.

Tareas y señales Stack consumidoTareasComunicación inalámbrica 4216 BytesComunicación con el controlador 8312 BytesLector NFC 1144 BytesManejo de la GUI 8312 BytesRelojPedido del estado del surtidor 48 BytesSemáforosBinarios 176 BytesContadores 176 BytesMutexes 176 BytesColas 196 BytesTotal del stack consumido 22756 Bytes

3.4. Arquitectura de interfaz de usuario

El primer paso para el diseño de la interfaz de usuario fue definir la resolución dela pantalla a emplear. El trabajo se realizó sobre una pantalla WVGA (Wide VideoGraphics Array) de cuatro pulgadas, la cual cuenta con una resolución de 800×480píxeles. En la figura 3.6 se muestra la pantalla utilizada [20].

FIGURA 3.6. Pantalla WVGA.

El formato de color elegido para la GUI fue RGBA8888 con 32 bpp, la elecciónse debió a querer representar la mayor cantidad de colores posibles y a utilizartransparencia en ventanas emergentes para el aviso de eventos.

La cantidad de framebuffers empleados fueron seleccionados en base a la compleji-dad de las pantallas a mostrar. Al no haberse usado animaciones que requieran eluso dos framebuffer, se opto por la utilización de solo uno. Esto permite un ahorrodel consumo de memoria RAM.


De la ecuación 2.2 y los datos mencionados en los parráfos anteriores se puederealizar el cálculo de memoria RAM necesaria para almacenar el framebuffer utili-zado.

RAM =800× 480píxeles × 32bpp× 1framebuffer

8

RAM =12288000 bits

8= 1536000 Bytes = 1,5 MB

Con el cálculo se obtuvo que se necesitan 1,5 MB de memoria RAM para realizarla GUI. El kit STM32F769I-Discovery cuenta con 512 kB de SRAM interna y 128Mbits (16 MB) de SDRAM externa. Luego se concluyó que se debe emplear laSDRAM externa y con esto el periférico FMC.

Para mejorar el rendimiento del MCU se decidió utilizar la carga de imágenes yasí evitar realizar cálculos en el armado de pantallas. Esto se logró al utilizar elperiférico DMA2D para acceder a la memoria de manera directa sin necesidad deprocesamiento del MCU. Al emplear carga de imágenes estas debieron almace-narse en memoria Flash externa, por lo cual, la Flash interna del MCU se reservópara código fuente y bibliotecas. El periférico QSPI fue empleado como interfazde conexión con la flash externa.

Al utilizar el periférico DMA2D se observaron los prototipos de las funciones pu-blicas para ver si la memoria Flash externa necesita alguna especificación puntual.En el fragmento de código 3.1 se observan los prototipos.

1

2 HAL_StatusTypeDef HAL_DMA2D_Start ( DMA2D_HandleTypeDef *hdma2d , u i n t 3 2 _ tpdata , u i n t 3 2 _ t DstAddress , u i n t 3 2 _ t Width , u i n t 3 2 _ t Height ) ;

3

4 HAL_StatusTypeDef HAL_DMA2D_BlendingStart ( DMA2D_HandleTypeDef *hdma2d ,u i n t 3 2 _ t SrcAddress1 , u i n t 3 2 _ t SrcAddress2 , u i n t 3 2 _ t DstAddress ,u i n t 3 2 _ t Width , u i n t 3 2 _ t Height ) ;

5

6 HAL_StatusTypeDef HAL_DMA2D_Start_IT ( DMA2D_HandleTypeDef *hdma2d ,u i n t 3 2 _ t pdata , u i n t 3 2 _ t DstAddress , u i n t 3 2 _ t Width , u i n t 3 2 _ t Height) ;

7

8 HAL_StatusTypeDef HAL_DMA2D_BlendingStart_IT ( DMA2D_HandleTypeDef *hdma2d, u i n t 3 2 _ t SrcAddress1 , u i n t 3 2 _ t SrcAddress2 , u i n t 3 2 _ t DstAddress ,u i n t 3 2 _ t Width , u i n t 3 2 _ t Height ) ;

CÓDIGO 3.1. Prototipo de las funciones de DMA2D

Del análisis se pudo concluir que DMA2D realiza acceso a la memoria a travésde punteros que se pasan como argumentos en las funciones. Esto requiere que lamemoria Flash externa deba ser mapeable para ser accesible con punteros desdeel microcontrolador.

3.5. Implementación de la autentificación NFC

La autentificación NFC se realizó a través de un módulo basado en el circuitointegrado PN532. Los modos de conexión del módulo pueden ser:

• UART.

3.5. Implementación de la autentificación NFC 27

• I2C.

• SPI.

El último modo de conexión fue seleccionado como interfaz de comunicación. Serealizó un análisis de la hoja de datos para determinar los parámetros de confi-guración requeridos y se obtuvieron las siguientes características:

• SPI del MCU como maestro.

• Tamaño de datos de 8 bits.

• Máxima frecuencia de la interfaz en 5 MHz.

• Formato de la trama compatible con el estándar Motorola.

• El primer bits de la trama es el menos significativo.

• La polaridad del reloj es baja y su fase es uno.

Se presentan dos maneras posibles de saber si hay una respuesta por parte delmódulo NFC. Estas son:

• Envío de un comando para consultar por datos disponibles. Esto implica unenvío de manera periódica y por ende, una mayor exigencia del MCU. Enla figure 3.7 se muestra un flujo de operación en este modo [21].

FIGURA 3.7. Mecanismo de lectura por encuesta.

• Detección de nivel bajo en el pin IRQ del módulo NFC a través de unainterrupción. Esto permite usar el MCU para otras operaciones lo que haceal sistema más optimo. En la figura 3.8 se muestra el flujo de una operaciónen este modo [21].


FIGURA 3.8. Mecanismo de lectura por IRQ.

Por un tema de eficiencia se optó por emplear interrupciones para la deteccióndel nivel bajo en el pin del módulo NFC.

3.6. Protocolo de comunicación con el controlador de sur-tidores

El protocolo de comunicación con el controlador de surtidores fue implementadosobre una comunicación serial. Se configuró un periférico UART del MCU con de-terminados parámetros que permitan el intercambio de datos con el controlador.Esto se muestra en el fragmento de código 3.2.

1

2 s t a t i c void MX_USART6_UART_Init ( void )3 {4 /* USER CODE BEGIN USART6_Init 0 */5 /* USER CODE END USART6_Init 0 */6

7 /* USER CODE BEGIN USART6_Init 1 */8 /* USER CODE END USART6_Init 1 */9 huart6 . I n s ta n ce = USART6 ;

10 huart6 . I n i t . BaudRate = 115200 ;11 huart6 . I n i t . WordLength = UART_WORDLENGTH_8B;12 huart6 . I n i t . S t o p B i t s = UART_STOPBITS_1 ;13 huart6 . I n i t . P a r i t y = UART_PARITY_NONE;14 huart6 . I n i t . Mode = UART_MODE_TX_RX;15 huart6 . I n i t . HwFlowCtl = UART_HWCONTROL_NONE;16 huart6 . I n i t . OverSampling = UART_OVERSAMPLING_16 ;17 huart6 . I n i t . OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE ;18 huart6 . AdvancedInit . AdvFeatureInit = UART_ADVFEATURE_NO_INIT ;19

20 i f ( HAL_UART_Init(& huart6 ) != HAL_OK) {

3.6. Protocolo de comunicación con el controlador de surtidores 29

21 Error_Handler ( ) ;22 }23 /* USER CODE BEGIN USART6_Init 2 */24 /* USER CODE END USART6_Init 2 */25 }

CÓDIGO 3.2. Inicialización de la UART para comandar elcontrolador de surtidores

El formato de comandos dentro del protocolo de comunicación varía en funciónde cual controlador de surtidor se emplee. Por ejemplo, para el controlador Fu-sion mencionado en el capítulo 2 se utiliza una cadena de caracteres donde cadaparámetro del mensaje es divido por un símbolo “|”. En el caso del controladorCEM se utiliza el formato XML [22] para armar un comando.

La compañía para la cual se realizo el trabajo utiliza en su mayor parte el controla-dor CEM. Por tal motivo se implementaron bibliotecas que permitieran construiry analizar mensajes en formato XML. A modo de ejemplo, se muestra el archivoheader de las bibliotecas que permiten la construcción del XML en el código 3.3.

1

2 # i f n d e f BUILD_XML_H_3 # def ine BUILD_XML_H_4

5 # include " stm32f7xx_hal . h "6

7 # def ine MAX_LENGTH_ATTRIBUTE 508 # def ine MAX_COUNT_ATTRIBUTE 159 # def ine MAX_COUNT_CHILDREN 20

10

11 typedef s t r u c t12 {13 u i n t 8 _ t name [MAX_LENGTH_ATTRIBUTE ] ;14 u i n t 8 _ t value [MAX_LENGTH_ATTRIBUTE ] ;15 } x m l _ a t t r i b u t e _ t ;16

17 typedef s t r u c t18 {19 x m l _ a t t r i b u t e _ t a t t r i b u t e [MAX_COUNT_ATTRIBUTE ] ;20 } xml_header_t ;21

22 typedef s t r u c t xml_element_s23 {24 u i n t 8 _ t name_tag [MAX_LENGTH_ATTRIBUTE ] ;25 u i n t 8 _ t body [ 2 5 0 ] ;26 x m l _ a t t r i b u t e _ t a t t r i b u t e [MAX_COUNT_ATTRIBUTE ] ;27 s t r u c t xml_element_s * ch i l dre n [MAX_COUNT_CHILDREN] ;28 } xml_element_t ;29

30 xml_element_t * BuildXML_Newxml ( const u i n t 8 _ t *name) ;31 xml_header_t *BuildXML_NewXmlHeader ( void ) ;32 void BuildXML_AddAtrribute ( xml_element_t * xml_element , const u i n t 8 _ t *

name , const u i n t 8 _ t * value ) ;33 void BuildXML_AddAttributeHeader ( xml_header_t * header , const u i n t 8 _ t *

name , const u i n t 8 _ t * value ) ;34 void BuildXML_AddBody ( xml_element_t * xml_element , const u i n t 8 _ t * body ) ;35 void BuildXML_AddChildren ( xml_element_t * xml_element , xml_element_t *

xml_children ) ;36 void BuildXML_FreeHeader ( xml_header_t * xml_header ) ;37 xml_element_t * BuildXML_Free ( xml_element_t * xml_element ) ;38 void BuildXML_FormatHeader ( xml_header_t * xml_header , u i n t 8 _ t * out ) ;39 u i n t 3 2 _ t BuildXML_Format ( xml_element_t * xml_element , u i n t 8 _ t * out ) ;


40

41 # endi f /* BUILD_XML_H_ */

CÓDIGO 3.3. Biblioteca para contruir XML.

El código 3.3 contiene limitaciones en el tamaño del XML que se puede construir.Estas dependen de los valores definidos en las macros MAX_LENGTH_ATTRIBUTE,MAX_COUNT_ATTRIBUTE y MAX_COUNT_CHILDREN. Con un análisis pre-vio de los comandos XML a implementar en el protocolo se pudo ajustar los va-lores en las macros para:

• Evitar la limitación.

• Utilizar XML de una mayor complejidad en el futuro

Los comandos que se utilizaron fueron:

• Iniciar despacho de combustible.

1 <?xml vers ion=" 1 . 0 " encoding="UTF−8" ?>2 <CONTROLLER_CEM>3 <COMMAN_ID>DISPATCH</COMMAN_ID>4 <NUMBER_PUMP> [ ID de l a bomba ] </NUMBER_PUMP>5 <FUEL type=" [ Combustible ] "> [ L i t r o s a cargar ] </FUEL>6 </CONTROLLER_CEM>7

• Parar la carga de combustible.

1 <?xml vers ion=" 1 . 0 " encoding="UTF−8" ?>2 <CONTROLLER_CEM>3 <COMMAN_ID>STOP</COMMAN_ID>4 <NUMBER_PUMP> [ ID de l a bomba ] </NUMBER_PUMP>5 </CONTROLLER_CEM>

• Pedir el estado de la bomba

1 <?xml vers ion=" 1 . 0 " encoding="UTF−8" ?>2 <CONTROLLER_CEM>3 <COMMAN_ID>STATE</COMMAN_ID>4 <NUMBER_PUMP> [ ID de l a bomba ] </NUMBER_PUMP>5 </CONTROLLER_CEM>

• Continuar la carga de combustible.

1 <?xml vers ion=" 1 . 0 " encoding="UTF−8" ?>2 <CONTROLLER_CEM>3 <COMMAN_ID>START</COMMAN_ID>4 <NUMBER_PUMP> [ ID de l a bomba ] </NUMBER_PUMP>5 </CONTROLLER_CEM>

31

Capítulo 4

Ensayos y resultados

En el presente capítulo se presentan las pruebas que se realizaron en cada uno delos módulos que conforman el trabajo, una descripción de los bancos de pruebaempleados y una explicación de una prueba integral del sistema en operación.

4.1. Ensayos de la comunicación NFC

Para probar el funcionamiento del módulo NFC junto con el MCU se realizó unbanco de prueba. Las partes que lo integraron fueron:

• Kit de desarrollo STM32F769I-Discovery.

• Módulo NFC basado en el circuito integrado PN532.

• Analizador lógico Zaleae.

En la figura 4.1 se muestra el diagrama del banco de prueba empleado.

FIGURA 4.1. Diagrama de banco de prueba del módulo NFC.

32 Capítulo 4. Ensayos y resultados

Se configuró el analizador lógico para detectar el protocolo SPI con los paráme-tros mostrados en la figura 4.2. La configuración de frecuencia de muestreo fue12 MS/s (Mega sample per second) durante un período de 6 segundos.

FIGURA 4.2. Parámetros del protocolo SPI en el analizador lógico.

Al observar la hoja de datos del circuito integrado se obtuvieron los formatos delas tramas a intercambiar entre el procesador y el módulo NFC. Estas se muestranen la figura 4.3 y 4.4 [21].

FIGURA 4.3. Formato de trama de ACK.

4.1. Ensayos de la comunicación NFC 33

FIGURA 4.4. Formado de trama de comandos.

En la trama de comandos el campo TFI toma valores constantes definidos en elfirmware del módulo. Estos son:

• 0xD4 en caso que la trama se envíe desde el MCU.

• 0xD5 en caso que la trama se envíe desde el circuito integrado PN532.

El campo LCS es un byte que al realizar la operación de suma con el campo LEN,el resultado de la operación debería ser 0x00. El campo LEN tiene en cuenta lacantidad de bytes de datos más uno por el campo TFI.

Por medio del analizador lógico se obtuvo las tramas mostradas en las figuras 4.5,4.6 y 4.7, donde se configura la cantidad de lecturas del módulo.

FIGURA 4.5. Comando para configurar cantidad de intentos.


FIGURA 4.6. ACK del comando enviado.

FIGURA 4.7. Respuesta del módulo NFC.

4.2. Ensayo de protocolo con controlador de surtidores 35

Para verificar la validez de cada trama se realizó:

• Envío de comandos: se verificó que el formato indicado en la hoja de datos yel capturado coincidan, que el valor del campo TFI sea 0xD4, que el cálculode LCS más LEN dé 0x00 y que en LEN se lograra el valor esperado. Sepuede concluir del análisis de la trama que el envío de comandos funcionacorrectamente.

• Trama de ACK: se verificó que el formato indicado en la hoja de datos yel capturado concuerden. Al compararlos se observó que son idénticos. Poreste motivo, se concluye que funcionan de manera correcta.

• Respuesta del módulo: se verificó que el formato capturado y teórico coin-ciden, que el valor del campo TFI fue 0xD5, que el código de respuesta delcomando coincide con el teórico y el valor de los campos TFI y LEN soncorrectos.

Con el análisis empleado y las capturas de datos obtenidas del banco de pruebase validó el funcionamiento del módulo NFC y el firmware empleado para sucontrol.

4.2. Ensayo de protocolo con controlador de surtidores

Las pruebas sobre el protocolo del controlador de surtidores se realizaron a travésde un banco de prueba que utiliza el analizador lógico. El objetivo de este fue lacaptura de las tramas XML que se envían y reciben. En la figura 4.8 se muestraun diagrama en bloque del banco de prueba empleado.

FIGURA 4.8. Diagrama en bloque del banco de prueba del contro-lador con surtidores

La frecuencia de muestreo configurada fue de 8 Ms/s, capturándose por un pe-ríodo de 2 segundos. El protocolo del controlador de surtidores con el procesadorse basa en una comunicación serial, cuyos parámetros para el banco de prueba seconfiguraron como se muestra en la figura 4.9.


FIGURA 4.9. Parámetros del protocolo serial en el banco de prue-ba.

Durante el ensayo se envió el mensaje de carga de combustible y se recibió larespuesta. En las figuras 4.10 y 4.11 se muestran las tramas capturadas con elanalizador lógico.

FIGURA 4.10. Captura de trama enviada al controlador de surti-dores.

4.3. Ensayos de interfaz gráfica 37

FIGURA 4.11. Captura de trama recibida desde el controlador desurtidores.

A partir del análisis se concluye que la trama enviada al surtidor fue correctamen-te armada por la biblioteca XML y la comunicación serial puede enviar esta tramasin inconvenientes. La respuesta recibida por parte del controlador es coherenteporque es un XML donde se tiene el objeto RESPONSE que confirma el comandoenviado.

4.3. Ensayos de interfaz gráfica

Al realizarse los ensayos sobre la interfaz gráfica no se pudo emplear ningúnbanco de prueba que valide su funcionamiento. Esto se debe a que la frecuenciade trabajo de la interfaz DSI que se utiliza para conectar la pantalla táctil es de500 MHz, lo que requiere equipos de laboratorio especiales que no son de fácilacceso.

La manera de verificar el funcionamiento de la interfaz gráfica fue realizar unaserie de pantallas. Estas permitieron observar si se presenta alguna falla. El mayor


inconveniente es no saber con exactitud si una eventual falla puede ser por unproblema de hardware o software. Se partió de la hipótesis que, si se presentasenerrores éstos serían de software por utilizar un kit ya testeado por el fabricante.

La primer prueba realizada consistió en mostrar una pantalla en la cual se vieran3 franjas con los colores rojo, verde y azul. Con esta prueba se puede verificar siel firmware gráfico realizado tiene la capacidad de dibujar sobre toda la pantalla.El ensayo realizado se muestra en la figura 4.12.

FIGURA 4.12. Primer prueba de firmware gráfico.

La segunda prueba consistió en dibujar una pantalla que muestre una ventanaemergente con un título y una imagen. Esto permitió verificar la capacidad delfirmware de realizar gráficas más complejos y la utilización del DMA2D al cargaruna imagen al framebuffer. En la figura 4.13 se muestra la pantalla gráfica imple-mentada.

FIGURA 4.13. Segunda prueba de firmware gráfico.

4.4. Ensayos de la comunicación MQTT 39

Con las pruebas implementadas se corroboró que los periféricos DMA2D, LTDC yHost DSI en el firmware gráfico realizan el intercambio de información entre ellosde manera adecuada. Se validó un correcto uso y configuración de los periféricosFMC y QSPI al mostrar imágenes almacenadas en Flash y realizar operaciones deescritura y lectura del framebuffer ubicado en la SDRAM.

4.4. Ensayos de la comunicación MQTT

La prueba sobre la comunicación MQTT no se podría haber implementado conun banco de prueba que utilice el analizador lógico y el ESP8266-01. Esto sólohubiera verificado el correcto envío de comandos AT y la respuesta del móduloinalámbrico a través de la UART. Para demostrar fehacientemente que la comuni-cación con el protocolo MQTT se realizó con éxito, se decidió utilizar un softwarede captura de paquetes de red y analizarlos.

Se empleó una aplicación que recibe y envía paquetes utilizando el protocoloMQTT para que interactue con el módulo ESP8266-01 y ejecuto Wireshark [23] enel equipo para capturar las tramas. La dirección IP del equipo se obtuvo medianteel comando ifconfig de Linux. Esto se muestra en la figura 4.14

FIGURA 4.14. Obtener la dirección IP donde corren los programas.

La primer prueba consistió en publicar un mensaje al topic CESE_PUB a travésdel ESP8266 hacia un broker con dirección IP: 18.195.227.162 y suscribir el móduloal topic CESE_SUB para recibir las respuestas. Otro cliente MQTT se suscribió altopic CESE_PUB y publicó en el topic CESE_SUB . En la figura 4.15 se muestra lacaptura de los paquetes de la red y se verifica la operación realizada.


(A) Paquete publicado por el ESP8266

(B) Paquete recibido en el ESP8266

FIGURA 4.15. Primer prueba de uso del protocolo MQTT.

En la figura 4.15 (A) se observó que el ESP8266 publicó el mensaje “A|1|B32BC520”en el topic CESE_PUB y el broker lo envió a los clientes suscriptos. Luego en lafigura 4.15 (B) se muestra la operación contraria donde el cliente implementadoen el equipo publica en el topic CESE_SUB y es recibido por el módulo.

La segunda prueba consistó en repetir la misma operación anterior, con el fin deverificar la estabilidad de la conexión. En la figura 4.16 se muestra el paquetepublicado por el ESP8266 y el cliente que se ejecutó en la PC.

4.5. Pruebas de integración del sistema 41

(A) Paquete publicado por el ESP8266

(B) Paquete recibido en el ESP8266

FIGURA 4.16. Segunda prueba de uso del protocolo MQTT.

Con el análisis de las pruebas capturadas se pudo corroborar que el móduloESP8266 cuenta con la capacidad de utilizar el protocolo MQTT tanto en el en-vío como recepción de mensajes.

4.5. Pruebas de integración del sistema

Se implementó una prueba integral del sistema donde todos los módulos que loconforman interactúan entre sí. En la prueba se hizo una lectura del UID de unatarjeta NFC, el envío y recepción de mensajes que utiliza el protocolo MQTT, elmanejo de todo el flujo de negocio a través de la interfaz gráfica y el control de


surtidores a través del protocolo serial. En la figura 4.17 se muestra el sistema aliniciar por primera vez.

FIGURA 4.17. Inicio del sistema.

Se navegó hasta la pantalla de lectura NFC, se activó el lector y se obtuvo su UID.Esta lectura se hizo simultáneamente con una aplicación para este fin. En la figura4.18 se muestran las operaciones y el UID que se obtuvo. Se pudo corroborarque ambos datos leídos concuerdan, por lo que se concluyó que el lector NFCfunciona correctamente.


(A) Lectura con el sistema implementado.

(B) Lectura a través de la aplicación.

FIGURA 4.18. Lectura del UID de una tarjeta NFC.


Al obtener el UID de la tarjeta, éste se envió usando el protocolo MQTT al brokery luego se recibió la respuesta publicado por el sistema de gestión. El formato demensaje que se utilizó fue:

Comando enviado: A|[UID]

Respuesta recibida: D|[0 o 1]|[Cantidad de litros disponibles]

En la figura 4.19 se muestra el mensaje que publicó el ESP8266 sobre el softwarede gestión y su respuesta, donde se indicó que el cliente está autorizado juntocon la cantidad de combustible. Al procesar la respuesta el sistema mostró unapantalla con los litros disponibles junto con un teclado numérico para seleccionarla cantidad. Esto se muestra en la figura 4.20. A partir de los datos obtenidosse pudo corroborar que el módulo de comunicación inalámbrica pudo utilizar elprotocolo MQTT e integrarse dentro del sistema junto con la GUI y el lector NFC.

FIGURA 4.19. Mensaje enviado/ recibido por/al ESP8266.


FIGURA 4.20. Selector de cantidad a cargar.

Para probar la comunicación con el controlador se seleccionó el tipo de combus-tible, el surtidor y la cantidad de litros a cargar. Esto se muestra en la figura 4.21.Se configuró el surtidor cinco con 33,49 litros y tipo diesel regular. Al proporcio-nar la configuración, se procesó el despacho de combustible. Esto se observa enla figura 4.22 junto con las tramas que fueron intercambiadas entre el controladorde surtidores y el sistema.

FIGURA 4.21. Selección de parámetros para el despacho de com-bustible.


(A) Tramas entre el controlador y el sistema.

(B) GUI al finalizar el despacho.

FIGURA 4.22. Interacción con el controlador de surtidores.

Al observar los datos obtenidos se verificó que el módulo de comunicación con elcontrolador se integró al sistema correctamente. Por otro lado, la interfaz gráficapermitió navegar por el flujo de negocios de la aplicación y configurar los pará-metros que fueron necesarios durante todo una operación. Por ende, se concluyóque la GUI también funcionó perfectamente.

En la tabla 4.1 se muestra un resumen de todos los ensayos aplicados durante eltrabajo.

TABLA 4.1. Resumen de ensayos realizados.

Módulos y protocolos Ensayos aislados Ensayo integralModulo Wi-Fi X X

Modulo NFC X X

Interfaz de usuario X X

Cómunicación con controlador X X

Protocolo MQTT X X

Lectura de UID × X

47

Capítulo 5

Conclusiones

En este capítulo se realiza un resumen de los conocimientos aplicados, los proble-mas que surgieron durante el desarrollo y las posibles mejoras que podrían seraplicadas a futuro.

5.1. Resultados obtenidos

Para la realización del presente trabajo se aplicaron conocimientos de:

• Implementación de gráficos en sistemas embebidos, como también, conoci-mientos de hardware gráfico que podrían ser empleados en un futuro dise-ño de PCB ajustado a las necesidades del proyecto.

• Funcionamiento del protocolo MQTT que es ampliamente utilizado en IoTy el hardware que se implemente en estos casos.

• Patrones de diseño en sistemas operativos de tiempo real y los mejores cri-terios para la elección de arquitecturas.

El trabajo implementado logró cumplir los objetivos propuestos en la planifica-ción a pesar de haber existido ciertos inconvenientes durante el desarrollo.

De los riesgos que podían manifestarse y que fueron tenidos en cuenta en la pla-nificación, la falta de tiempo dentro del horario laboral fue el único que se ma-nifestó. El plan de mitigación propuesto (acordar un tiempo de desarrollo con lacompañía antes de iniciar el proyecto) no solucionó el problema pero de todasmaneras se pudo cumplir con todos los puntos propuestos en el trabajo.

En este trabajo se hizo amplio uso del concepto de capa de abstracción comopráctica de programación. En consecuencia se logró implementar un sistema cuyofirmware y bibliotecas de código pueden ser reutilizadas, lo que permite ahorrartiempo en una continuación futura del presente trabajo.

Las pruebas realizadas corroboraron que el rendimiento obtenido fue acorde a loesperado. Se concluyó que el trabajo desarrollado puede ser una alternativa po-sible a los equipos disponibles en el mercado. La única consideración a tener encuenta es la poca memoria Flash con que cuenta la plataforma de hardware parael almacenamiento de imágenes, esto podría mejorarse en un diseño personaliza-do.

5.2. Trabajo futuro

Se considera que a futuro sería posible continuar este trabajo mediante:

48 Capítulo 5. Conclusiones

• Diseño del hardware en base a las necesidades del producto.

• Utilizar bibliotecas gráficas open source, como por ejemplo LVGL.

También se plantea el agregado de las ciertas funcionalidades por no estar actual-mente en uso de protocolo MQTT dentro los sistemas de gestión de la compañía,ademas de no estar previstos su agregado en el corto plazo:

• Permitir conexiones seguras como SSL/TLV.

• Realizar pruebas sobre controladores reales para poder hacer ajustes al pro-tocolo empleado.

• Implementar bibliotecas para utilizar el protocolo HTTP y HTTPS.

49

Bibliografía

[1] Wayne Fueling systems. Servidor de automatización Fusion™.https://wayne.com/es/productos/servidor-de-automatizacion-fusion/.

[2] DINAMICA DIGITAL. Estaciones de Servicio y Terminales de Despacho.http://dynamicadigital.com.ar/productos.html.

[3] Verifone. Anywhere. Any way. AnyPAY. https://www.verifone.com/en/us.[4] HiveMQ. Introducing the MQTT Protocol. https:

//www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt/.[5] HiveMQ. TLS/SSL - MQTT Security Fundamentals.

https://www.hivemq.com/blog/mqtt-security-fundamentals-tls-ssl/.[6] Steve. Understanding the MQTT Protocol Packet Structure. http:

//www.steves-internet-guide.com/mqtt-protocol-messages-overview/.[7] HiveMQ. MQTT Publish, Subscribe and Unsubscribe.

https://www.hivemq.com/blog/mqtt-essentials-part-4-mqtt-publish-subscribe-unsubscribe/.

[8] Wikipedia. ISO 14443. https://es.wikipedia.org/wiki/ISO_14443.[9] Ricardo Montero Lannegrand. «ESTUDIO DE TECNOLOGÍA DE

COMUNICACIÓN DE CAMPO CERCANO, NFC». 2017.[10] Joan-Carles Iglesias Sanchez. «Diseño de un dron para la lectura de

tarjetas RFID». 2016.[11] Shop NFC. Cómo elegir la etiqueta NFC.

https://www.shopnfc.com/es/content/11-como-elegir-la-etiqueta-nfc.[12] Tag NFC. NTAG Series Specifications.

https://www.tagnfc.com/es/info/11-nfc-tags-specs.[13] TouchGFX. TouchGFX Documentation.

https://support.touchgfx.com/docs/introduction/welcome.[14] KAMAMI. STM32F769I-DISC1.

https://kamami.pl/59390-thickbox_default/stm32f769i-disc1.jpg.[15] Amazon. STM32F769I-DISC1. https://www.amazon.com/Development-

Boards-Kits-STM32F769NI-STM32F769I-DISC1/dp/B0894KG9CC.[16] 330ohms. Guía sintetizada de comandos AT GSM+BT.

https://blog.330ohms.com/2019/10/18/guia-definitiva-de-comandos-at-gsmbt/.

[17] Wikipedia. lwIP. https://en.wikipedia.org/wiki/LwIP.[18] AliExpress. PN532 NFC RFID V3 Kits módulo para Arduino Android.

https://es.aliexpress.com/i/4000134574530.html.[19] FreeRTOS. The FreeRTOTM Kernel. https://www.freertos.org/RTOS.html.[20] Discovery kit with STM32F769NI MCU. UM2033. Rev. 3.

STMicroelectronics. 2018.[21] PN532 User Manual. UM2033. Rev. 2. NXP. 2007.[22] MDN Web Docs. Introducción a XML.

https://developer.mozilla.org/es/docs/Web/XML/XML_introduction.[23] WireShark. About Wireshark. https://www.wireshark.org/.

https://wayne.com/es/productos/servidor-de-automatizacion-fusion/

http://dynamicadigital.com.ar/productos.html

https://www.verifone.com/en/us

https://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt/

https://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt/

https://www.hivemq.com/blog/mqtt-security-fundamentals-tls-ssl/

http://www.steves-internet-guide.com/mqtt-protocol-messages-overview/

http://www.steves-internet-guide.com/mqtt-protocol-messages-overview/

https://www.hivemq.com/blog/mqtt-essentials-part-4-mqtt-publish-subscribe-unsubscribe/

https://www.hivemq.com/blog/mqtt-essentials-part-4-mqtt-publish-subscribe-unsubscribe/

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

https://www.shopnfc.com/es/content/11-como-elegir-la-etiqueta-nfc

https://www.tagnfc.com/es/info/11-nfc-tags-specs

https://support.touchgfx.com/docs/introduction/welcome

https://kamami.pl/59390-thickbox_default/stm32f769i-disc1.jpg

https://www.amazon.com/Development-Boards-Kits-STM32F769NI-STM32F769I-DISC1/dp/B0894KG9CC

https://www.amazon.com/Development-Boards-Kits-STM32F769NI-STM32F769I-DISC1/dp/B0894KG9CC

https://blog.330ohms.com/2019/10/18/guia-definitiva-de-comandos-at-gsmbt/

https://blog.330ohms.com/2019/10/18/guia-definitiva-de-comandos-at-gsmbt/

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

https://es.aliexpress.com/i/4000134574530.html

https://www.freertos.org/RTOS.html

https://developer.mozilla.org/es/docs/Web/XML/XML_introduction

https://www.wireshark.org/

Documents

Controlador para el despacho de combustible en surtidores