Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción

Equation Chapter 1 Section 1 Trabajo de Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción Autor: Dolores Raigada Romero Tutor: Antonio Jesús Sierra Collado Departamento de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2019 iii Trabajo de Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción Autor: Dolores Raigada Romero Tutor: Antonio Jesús Sierra Collado Departamento de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2019 v Trabajo Fin de Grado: Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción Autor: Dolores Raigada Romero Tutor: Antonio Jesús Sierra Collado El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2019 El Secretario del Tribunal vii A mi familia A mis amigos ix Agradecimientos A mis padres, por hacer que esto sea posible. Gracias por darme todo lo que he necesitado y empujarme siempre a seguir hacia delante. Vuestro empeño a lo largo de todos mis años como estudiante han hecho que haya llegado a donde estoy ahora y, sobre todo, que sea quien soy hoy en día. A mi hermana, por ser mi ejemplo a seguir. Por meterme en el mundo de la ingeniería y ayudarme cada vez que ha sido posible. Me has acompañado más que nunca a lo largo de mi etapa universitaria y, por supuesto, esto también es gracias a ti. A toda la gente con la que me he cruzado en estos años y han hecho que fuese todo un poco más fácil. A mis amigos de siempre y los que he hecho por el camino, gracias por apoyarme y confiar siempre en mí. Dolores Raigada Romero Sevilla, 2019 4.3.1 Dashboard 43 4.3.2 Aplicación 44 4.4 Desarrollo 44 4.4.1 Lectura y envío de datos de los sensores 44 4.4.2 Broker 49 4.4.3 Presentación de datos 53 5 Validación 57 5.1 Ejecución 57 5.2 Resultados 58 6 Conclusiones y líneas futuras 61 6.1 Conclusiones 61 6.2 Líneas futuras 62 Referencias 65 Anexos 69 xvii ÍNDICE DE ILUSTRACIONES Ilustración 1: Presentación del escenario propuesto para la solución 24 Ilustración 2: Arduino UNO 30 Ilustración 3: Ethernet Shield 31 Ilustración 4: Módulo MPU-6050 31 Ilustración 5: Módulo GPS NEO-6M 32 Ilustración 6: Esquema de comunicación de los elementos del sistema 33 Ilustración 7: Ejes en el MPU-6050 34 Ilustración 8: Movimiento angular 35 Ilustración 9: Antena con conector U.FL para comunicación del módulo NEO-6M 36 Ilustración 10: Pila de protocolos de los dispositivos MQTT 37 Ilustración 11: Paso de mensajes SUBSCRIBE/PUBLISH 41 Ilustración 12: Paso de mensajes cancelación de subscripción 43 Ilustración 13: Esquema de conexión completo 44 Ilustración 14: Configuración acceso a internet 45 Ilustración 15: Conexión completa entre Arduino y sensores 45 Ilustración 16: Esquema de conexión MP6050 con Arduino 46 Ilustración 17: Configuración MPU 46 Ilustración 18: Lectura de datos MPU-6050 46 Ilustración 19: Conexión MPU con Arduino 47 Ilustración 20: Esquema de conexión NEO-6M con Arduino 47 Ilustración 21: Configuración NEO-6M 48 Ilustración 22: Lectura de datos GPS 48 Ilustración 23: Tratamiento de datos GPS para la localización 48 Ilustración 24: Conexión Arduino con GPS 49 Ilustración 25: Página de acceso a CloudMQTT. 49 Ilustración 26: Página principal con listado de instancias creadas. 50 Ilustración 27: Paso 1 para crear nueva instancia 50 Ilustración 28: Selección de región para la instancia 51 Ilustración 29: Información de la instancia creada en CloudMQTT 51 Ilustración 30: Creación cliente MQTT 51 Ilustración 31: Conexión al broker MQTT desde el Arduino 52 Ilustración 32: Subscripción a los topics desde el Arduino 52 Ilustración 33: Publicación de la temperatura obtenida en el topic ‘temperature’ 53 Ilustración 34: Página principal IoT MQTT Panel y nueva conexión 54 Ilustración 35: Configuración avanzada de la conexión 54 Ilustración 36: Creación Panel Gauge 55 Ilustración 37: Configuración panel gráficos 55 Ilustración 38: Configuración panel URI y dashboard final. 56 Ilustración 39: Cargar programa en el Arduino 57 Ilustración 40: Datos recogidos en la aplicación móvil 58 Ilustración 41: Localización obtenida gracias al módulo NEO-6M 59 xix ÍNDICE DE TABLAS Tabla 1: Comparación entre los protocolos de publicación/subscripción 26 Tabla 2: Contenido mensaje CONNECT 38 Tabla 3: Contenido mensaje CONNACK 39 Tabla 4: Códigos de retorno del mensaje CONNACK 39 Tabla 5: Contenido mensaje PUBLISH 41 Tabla 6: Contenido mensaje SUBSCRIBE 41 Tabla 7: Contenido mensaje SUBACK 42 Tabla 8: Códigos de retorno del mensaje SUBACK 42 Tabla 9: Contenido mensaje UNSUBSCRIBE 42 xxi Acrónimos TTFF Time To First Fix, Tiempo para la primera posición IoT GPS Internet of Things, Internet de las Cosas Global Positioning System, Sistema de Posicionamiento Global U.FL Conector coaxial en miniatura para señales de alta frecuencia GB KB MHz GHz CPU RAM PWM SPI SDA SCL ISO OASIS Pub Sub dV dt dӨ bps QoS UART PSM XMPP AMQP MQTT AWS Gigabyte Kilobyte Megahercio Gigahercio Central Processing Unit, Unidad de Procesamiento Central Random Access Memory, Memoria de Acceso Aleatorio Pulse Width Modulation, Modulación de Ancho de Pulso Serial Peripheral Interface, Interfaz Periférica en Serie Serial Data Serial Clock International Organization for Standardization, Organización Internacional de Normalización Organization for the Advancement of Structured Information Standards Publish Subscribe Derivada de la velocidad Derivada del tiempo Derivada del desplazamiento angular Baudios por Segundo Quality of Service, Calidad del Servicio. Asynchronous Receiver-Transmitter, Transmisor-Receptor Asíncrono Universal Power Saving Mode, Modo de Ahorro de Energía Extensible Messaging and Presence Protocol Advanced Message Queuing Protocol Message Queue Telemetry Transport Amazon Web Services Objetivos 23 23 1 OBJETIVOS oy en día la tecnología se encuentra avanzando a un alto nivel, lo que supone importantes mejoras en nuestra calidad de vida y, por tanto, en nuestra sociedad, gracias a objetos conectados que continuamente se comunican entre ellos y estos, a su vez, se conectan con nosotros. En este primer capítulo se exponen los objetivos marcados en este proyecto relacionado con un tema actual como lo es el IoT. El término de Internet de las Cosas (IoT por sus siglas en inglés) proviene del concepto dado por Kevin Ashton, el cual lo define como objetos conectados a internet e interconectados entre ellos, principalmente a través de sensores que remiten y reciben datos de una manera continua para, a partir de estos y de su interpretación, proceder a la ejecución de acciones [9]. Resulta de especial interés que simplemente con una aplicación podamos controlar elementos de nuestra vida diaria, a los que quizás en ese momento no tengamos acceso. Es por eso por lo que se ha llevado a cabo este proyecto. Me fascina hasta dónde puede llegar la capacidad de un dispositivo conectado a internet, gracias al cual se consigue tener información de distintos sensores y poder saber su valor desde cualquier parte del mundo, simplemente teniendo conexión a internet y la aplicación móvil con la configuración correcta. El modelo Publicación/Subscripción es un estilo de mensajería en la que el emisor del mensaje no tiene visión directa con el receptor del mismo. En este modelo hay un intermediario encargado de recibir todos los mensajes y enviarlos al destinatario en cuestión [24]. Como objetivo principal, se pretende crear un sistema compuesto por un Arduino UNO al que conectar varios sensores, y configurarlos adecuadamente para poder obtener los datos tras la lectura de ambos. Una vez recibidos dichos datos, se pretende realizar publicaciones constantes hacia la nube, con el objetivo de que un cliente subscrito a esta pueda obtener el valor de los sensores en tiempo real. Estos datos se pretenden disponer en un panel de control a modo visual, desde una aplicación móvil que sea accesible en cualquier momento, mientras que el dispositivo presente conexión a la red de internet. De este modo, los objetivos a realizar en este proyecto se disponen en el siguiente orden: 1. Obtener los datos de los sensores MPU-6050 y NEO-6M, para ello se necesita que ambos se encuentren correctamente conectados al Arduino y comenzar la comunicación adaptada a cada uno de ellos. Tras esto, se obtendrán los datos de un acelerómetro, un giroscopio, un sensor de temperatura y un GPS. H Muere lentamente quien no se atreve a abandonar lo seguro para luchar por sus sueños. Jesús Quintero 2. Conexión a internet por parte del Arduino configurándolo de manera adecuada para que presente conexión a la red. 3. Creación de instancia del broker, para poder administrar los mensajes de publicación/subscripción. 4. Conexión al broker desde el Arduino, funcionando como cliente. 5. Subscripción a los topics necesarios, uno para cada valor de sensor que vayamos a necesitar. 6. Publicación de los datos leídos en el topic creado para ese campo. 7. Creación de un dashboard en el que disponer los datos, con el widget más adecuado para cada valor. 8. Subscripción de la aplicación de paneles al broker, para poder recibir la información enviada por el otro cliente. 9. Visualización de la lectura de los sensores a través del dashboard. En la ilustración 1 se muestra un esquema de la solución escogida en el que podemos apreciar tres componentes claramente diferenciados. A continuación, se realiza una breve descripción de cada uno de ellos, entrando en más detalle en el capítulo 4: • El Arduino es conectado a su componente esencial en este proyecto, el Ethernet Shield, y a dos sensores (no mostrados en el esquema), el MPU-6050 y NEO-6M. • El segundo elemento es un servidor en la nube al cual se conectará el Arduino para compartir sus datos. Este servidor admite mensajes de publicación y subscripción. • El último elemento es una aplicación usada para disponer los datos de los sensores leídos visualmente. Esta aplicación está subscrita al servidor al partir del cual le llega la información a mostrar. Ilustración 1: Presentación del escenario propuesto para la solución En este capítulo hemos podido conocer los objetivos propuestos para la correcta realización de este trabajo. En el siguiente capítulo se realiza una introducción al protocolo elegido para su implementación, así como una presentación de la solución planteada para una aplicación dedicada al sistema propuesto. 2 INTRODUCCIÓN n este capítulo se presentarán los protocolos de publicación/subscripción y sus características, para una correcta elección del protocolo más adecuado. Además de esto, se presenta la descripción de la solución propuesta para los objetivos marcados en el capítulo 1. 2.1 Protocolos de publicación/subscripción Este proyecto se desea llevar a cabo mediante un protocolo de mensajes basado en el patrón publicación/subscripción. Como se explicará en capítulos posteriores, este tipo de envío de mensajes consiste en la comunicación entre un servidor y un cliente, el cual publica mensajes a un tema específico o recibe los mensajes que son publicados por otros clientes en dicho tema. De este modo, presentaremos varios protocolos que siguen el modelo en cuestión pensando en su futura aplicación a IoT: XMPP, AMQP, MQTT y ZeroMQ [25]. ▪ XMPP es un protocolo de mensajería extensible (Extensible Messaging and Presence Protocol) basado en el intercambio de datos XML. Fue diseñado para mensajería instantánea, pero al ser extensible, presenta soporte para VoIP. Su arquitectura es descentralizada, por lo que no depende de un servidor central. Es el protocolo detrás del servidor de mensajería instantánea Ejabberd. ▪ AMQP es un protocolo de cola de mensajes avanzado (Advanced Message Queuing Protocol) usado en implementaciones populares como RabbitMQ. Está orientado a mensajes, realiza encolamiento tanto punto a punto como publicación/subscripción presentando, a su vez, exactitud y seguridad en el paso de mensajes. ▪ MQTT (Message Queue Telemetry Transport) es un protocolo puro de publicación/subscripción para dispositivos restringidos y para redes de bajo ancho de banda, alta latencia y poco fiables. Está desarrollado por IBM y estandarizado por OASIS. Tiene varias implementaciones en código abierto como el Mosquitto broker y su librería de cliente. ▪ ZeroMQ es una biblioteca de mensajería que ofrece una API de socket con patrones de mensajería bastante avanzados. Soporta tanto los modelos petición/respuesta como de publicación/subscripción. Esta biblioteca de mensajería permite agregar nuevas funciones al protocolo central. E La mejor organización no asegura los resultados. Pero una estructura equivocada sería garantía de fracaso. Peter Drucker Tecnología Utilizada 32 3.1.5 Sensor NEO-6M Gracias a la antena GPS presente en este sensor, se puede obtener la latitud y longitud para así, posteriormente, hallar la ubicación del dispositivo. La comunicación de este periférico con el Arduino se realiza mediante UART, siendo simplemente necesario para la obtención de datos la configuración de dos pines cualesquiera, como puerto de recepción y puerto de transmisión. Ilustración 5: Módulo GPS NEO-6M 3.2 Recursos Software A continuación, se comentan los recursos software envueltos en este proyecto. 3.2.1 MQTT Cloud MQTT Cloud es un broker en la nube encargado de manejar las peticiones de clientes MQTT y publicar datos a través de servidores basados en Mosquitto. Los clientes se subscriben a un tema, o publican en el mismo, a través del broker y este les hace llegar los mensajes de los temas a los que están subscritos, una vez ha llegado nueva información. 3.2.2 IoT MQTT Panel IoT MQTT Panel es una aplicación móvil que permite observar los datos leídos de los sensores gráficamente. Mediante la creación de paneles podemos tanto enviar datos como recibirlos fácilmente, a través del servidor en la nube conectado a nuestros dispositivos a través de internet. 3.2.3 Arduino IDE El Entorno de Desarrollo Integrado (IDE) de Arduino es una aplicación para ordenador escrita en Java. Este software es usado para el desarrollo de código y su posterior carga como programa a los dispositivos Arduino compatibles [15]. Una vez listados los elementos presentes en este proyecto, pasaremos al siguiente capítulo. El cuarto capítulo tiene como objetivo profundizar en la arquitectura del sistema, así como en la relación interna entre los distintos elementos. Se dispondrán las características de los sensores y su uso en este proyecto, así como la presentación de la plataforma utilizada y su protocolo de comunicación. De esta manera, se pretende dar a conocer de una forma completa los elementos que establecen el sistema para que, una vez llegados al desarrollo de la aplicación, tener un conocimiento íntegro de sus componentes. 4 APLICACIÓN DESARROLLADA a arquitectura y análisis de un sistema es crucial para su correcto entendimiento. En este capítulo se presenta la descripción de los programas realizados y su arquitectura, así como la disposición de los datos en el panel de control. Como precedente, se desarrollan los elementos del sistema para una mayor profundización y entendimiento del proyecto. En la ilustración 6 podemos observar los elementos que componen nuestro sistema. Ilustración 6: Esquema de comunicación de los elementos del sistema • El primer elemento, al que van conectados los sensores MPU-6050 y NEO-6M, es una placa Arduino Uno, a la que se encuentra acoplada su componente Ethernet Shield. Este componente, dota al Arduino de la capacidad de conectarse a internet vía cable, una vez realizada su correcta configuración. • El segundo elemento es la plataforma CloudMQTT con servidores Mosquitto en la nube. Esta plataforma es el elemento principal de nuestro sistema ya que es el encargado de recibir las peticiones de los clientes, enviando o recibiendo información de los mismos. • El tercer elemento es una aplicación móvil gracias a la cual se dispone la información leída por el Arduino y recibida en la aplicación gracias al protocolo MQTT. L Con la tecnología a nuestra disposición, las posibilidades son infinitas. Stephen Hawking Aplicación Desarrollada 34 Antes de comenzar con el desarrollo de la aplicación, es necesario tener los conocimientos previos para el correcto entendimiento del sistema. Es por esto, por lo que comenzaremos explicando las distintas partes que lo componen en profundidad. 4.1 Sensores La mayor parte de aplicaciones creadas para IoT se encargan de controlar sensores y recibir información crucial de los mismos. En este apartado se presentan los sensores usados en nuestro proyecto y se indaga en sus características más importantes. 4.1.1 MPU-6050 El MPU-6050 es un módulo dirigido a dispositivos con procesamiento de movimiento. Este dispositivo incluye una unidad de medición inercial o IMU (Inertial Measurment Units) de 6 grados de libertad (DoF) debido a la combinación de un acelerómetro y giroscopio de 3 ejes cada uno. Es capaz de procesar algoritmos de 9 ejes, y capturar movimiento en los ejes X, Y y Z a la misma vez. Ilustración 7: Ejes en el MPU-6050 Para comprender mejor el comportamiento de este módulo, es necesaria la correcta compresión del término aceleración, así como de la velocidad angular [13]. 4.1.1.1 Aceleración La aceleración es la variación de la velocidad por unidad de tiempo, definida matemáticamente como la derivada de la velocidad con respecto al tiempo: a=dV/dt A su vez, es también la segunda ley de Newton quien indica que, en un cuerpo con masa constante, la aceleración del cuerpo es proporcional a la fuerza que actúa sobre él mismo, de forma que: a=F/m Este segundo concepto es utilizado por los acelerómetros para medir la aceleración. Los acelerómetros internamente presentan los llamados MEMS (Micro Electro Mechanical Systems), gracias a los cuales es posible medir la aceleración. A pesar de que no exista movimiento, el acelerómetro siempre estará sintiendo la aceleración de la gravedad [18]. 35 Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción 4.1.1.2 Velocidad Angular La velocidad angular es la tasa de cambio del desplazamiento angular por unidad de tiempo, es decir, cómo de rápido gira un cuerpo alrededor de su eje: Ilustración 8: Movimiento angular Los giroscopios, al igual que los acelerómetros, también utilizan MEMS, aunque en este caso para medir la velocidad angular usando el efecto Coriolis, el cual hace que un objeto que se mueve sobre el radio de un disco en rotación tienda a acelerarse con respecto a ese disco según si el movimiento es hacia el eje de giro o alejándose de éste [12]. Las salidas del giroscopio están en grados por segundo, por lo tanto, para poder obtener la posición angular, es necesario integrar la velocidad angular [18]. 4.1.1.3 Características del MPU-6050 MPU-6050 consiste en un Procesador Digital de Movimiento (DMP), el cual tiene la propiedad de resolver cálculos complejos. Este dispositivo también cuenta con un convertidor analógico-digital de 16 bits, gracias al cual es posible capturar movimiento de tres dimensiones al mismo tiempo. A parte de tener integrado un acelerómetro y un giroscopio, el MPU-6050 también presenta un sensor de temperatura como característica distintiva. La comunicación del módulo se realiza a través de I2C, esto le permite trabajar con la mayoría de los microcontroladores. I2C es un bus direccional de dos cables usado para enviar datos entre circuitos integrados. Los pines SCL y SDA tienen una resistencia pull-up en la placa para obtener una conexión directa al microcontrolador o Arduino. El pin ADDR presenta internamente una resistencia a tierra por lo que, si no se conecta, la dirección por defecto será 0x68 (si se conectase, la dirección correspondiente al módulo sería 0x69) [19]. 4.1.2 Módulo GPS NEO-6M El módulo GPS permite obtener la localización del dispositivo mediante dos valores, la latitud y la longitud. A parte de estos dos parámetros, se pueden conocer el número de satélites con los que tiene visión, así como la hora a la que recibió la información, entre otros. Para entender cuál es el funcionamiento de este dispositivo, es necesario conocer cómo funciona un receptor GPS, ya que este módulo funciona principalmente como uno, gracias a su antena extraíble. 4.1.2.1 Receptores GPS El funcionamiento de los receptores GPS se basa en averiguar cómo de lejos se encuentran de un número de satélites, ya que están preprogramados para saber dónde se encuentran los satélites de GPS en cualquier momento. Los satélites transmiten información sobre su posición en el momento dado a través de radio señales hacia la Tierra. Esas señales identifican a los satélites y le dicen al receptor dónde se encuentran situados. Aplicación Desarrollada 36 El receptor entonces calcula cómo de lejos se encuentra cada satélite dependiendo de cuánto tardaron en llegar las señales. Una vez que obtiene información de al menos tres satélites, puede encontrar la ubicación en la Tierra. Este proceso se conoce como Trilateración Satelital. 4.1.2.2 Características NEO-6M El módulo NEO-6M GPS puede seguir hasta 22 satélites en 50 canales y conseguir el mayor nivel de sensibilidad del mercado. Es capaz de identificar ubicaciones en cualquier parte del mundo a la vez que presenta un bajo consumo de potencia. A diferencia de otros módulos GPS, este es capaz de obtener 5 actualizaciones de ubicación por segundo, con una precisión de 2.5 metros con respecto a la posición horizontal. Además, sus 6 funciones de posicionamiento cuentan con un TTFF definido como el tiempo requerido para que un dispositivo de navegación GPS adquiera señales de satélite y datos de navegación, y calcule una solución de posición, de menos de 1 segundo. Una de las mejores características que el chip posee es el modo de ahorro de energía (PSM). Este modo permite una reducción en el consumo de energía del sistema al encender y apagar selectivamente partes del receptor. El módulo se comunica con el microcontrolador a través de la UART, admitiendo una velocidad de transmisión de 4800bps a 230400bps, con una velocidad de transmisión predeterminada de 9600. Hay un LED presente en el módulo que se encarga de indicar si se ha obtenido comunicación con algún satélite. Parpadeará a diferente velocidad dependiendo del estado en el que se encuentre: ▪ Si el LED no parpadea entonces indica que está buscando satélites. ▪ Al parpadear cada segundo nos indica que el módulo puede ver suficientes satélites. A pesar de todas sus funcionalidades integradas, NEO-6M necesita una antena para realizar cualquier tipo de comunicación, por lo que presenta un conector U.FL hembra al que conectarla. Ilustración 9: Antena con conector U.FL para comunicación del módulo NEO-6M Una vez conexionada la antena al módulo, será necesario que la antena tenga visión directa con los satélites, ya que no es capaz de obtener información de los satélites necesarios en espacios cerrados [17]. 4.2 CloudMQTT En este apartado se explica el elemento principal del proyecto. Para poder entender el comportamiento de esta aplicación, es necesario conocer cómo funciona internamente. Para ello comenzaremos hablando del protocolo MQTT. 37 Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción 4.2.1 Protocolo MQTT La documentación oficial de este protocolo lo define como: MQTT es un protocolo de transporte de mensajes publish/subscribe entre cliente y servidor. Es ligero, abierto, simple y está diseñado para ser fácil de implementar. Estas características lo convierten en una opción ideal en muchas situaciones, incluyendo entornos restringidos como la comunicación en contextos Máquina a Máquina (M2M) e Internet de las cosas (IoT), donde se requiere una pequeña huella de código y/o el ancho de banda de la red es muy importante [1]. Como hemos podido saber gracias a la definición anterior, MQTT es un protocolo estándar de mensajería e intercambio de datos para Internet de las cosas. Es un protocolo abierto, estandarizado por OASIS e ISO, el cual provee una forma escalable y rentable de conectar los dispositivos a través de internet. Este protocolo, binario y muy ligero gracias a su mínima sobrecarga de paquetes, sobresale frente a otros protocolos como HTTP cuando se trata del envío de datos a través de cables [2, 3]. Un cliente MQTT es cualquier dispositivo que ejecute una librería MQTT y sea capaz de conectarse a un broker MQTT a través de internet. Por lo tanto, cualquier dispositivo que se comunique por MQTT a través de la pila de protocolos TCP/IP, puede ser llamado cliente MQTT. Tanto los editores como los suscriptores son clientes MQTT. A su vez, un mismo cliente es capaz de publicar y recibir mensajes. El anterior llamado broker, es el elemento complementario al cliente MQTT, constatado como el elemento principal de cualquier protocolo de publicación/subscripción. Es el responsable de recibir todos los mensajes, filtrarlos, determinar quién está subscrito a cada mensaje y enviar los mensajes a aquellos clientes subscritos [6]. Para poder manejar los mensajes correctamente, el broker dispone de varias opciones de filtrado: basado en el tema, basado en el contenido o basado en el tipo. El filtro de mensajes usado por MQTT es el basado en un tema. Este tipo de filtrado se basa en un topic (tema) que es parte de cada mensaje. El cliente se subscribe al broker para estar al tanto de los topics de interés. A partir de ese momento, el broker se asegura de que el cliente obtiene todos los mensajes que han sido publicados en esos temas [4]. 4.2.2 Conexión El protocolo MQTT está basado en TCP/IP por lo que, tanto el cliente como el broker necesitan tener una pila con estas características. Ilustración 10: Pila de protocolos de los dispositivos MQTT Aplicación Desarrollada 38 Las conexiones de los clientes siempre son manejadas por el broker. Para iniciar una conexión, el cliente le envía un mensaje CONNECT, el cual responde con CONNACK y un código de estado, devolviendo 0 en caso de que la conexión haya sido aceptada. CONTENIDO CAMPO OPCIONAL DESCRIPCIÓN clientId Obligatorio Identificador para cada cliente MQTT que se conecta a un broker, el cual lo utiliza para identificar al cliente y su estado actual. Debe ser único por cliente y broker. cleanSession Obligatorio Bandera para indicar al broker si el cliente quiere establecer o no una sesión persistente. Si la sesión es persistente, el broker almacenar todas las subscripciones del cliente y los mensajes perdidos para los que está subscrito con un QoS de nivel 1 o 2. username Sí Para la autenticación del cliente se puede enviar una combinación de usuario y contraseña. Si esta información no se encuentra encriptada, la contraseña será enviada como texto plano. username Sí lastWillTopic Sí Este mensaje notifica a otros clientes cuando un cliente se desconecta sin delicadeza (con un mensaje DISCONNECT incorrecto). En él se indica un topic, una bandera de mensaje retenido, QoS y un payload. El broker almacena este mensaje hasta que detecta que el cliente se ha desconectado. Cuando esto ocurre, el broker envía el mensaje indicado a los clientes subscritos al lastWillTopic. lastWillQoS Sí lastWillMessage Sí lastWillRetain Sí keepAlive Obligatorio Intervalo en segundos indicado al broker para definir el máximo periodo de tiempo que el broker y el cliente puede mantener una conexión sin enviar un mensaje. Tabla 2: Contenido mensaje CONNECT 39 Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción CONTENIDO CAMPO OPCIONAL DESCRIPCIÓN sessionPresent Obligatorio Bandera que indica al cliente si el broker ya tiene una sesión persistente disponible de anteriores interacciones entre ambos. returnCode Obligatorio Código de retorno que indica si la sesión ha sido establecida o, en caso contrario, por qué no se ha podido establecer. Tabla 3: Contenido mensaje CONNACK CÓDIGO SIGNIFICADO 0 Conexión aceptada. 1 Conexión rechazada, la versión de protocolo no es aceptable. 2 Conexión rechazada, identificador rechazado. 3 Conexión rechazada, el servidor no se encuentra disponible. 4 Conexión rechazada, nombre de usuario o contraseña incorrectos. 5 Conexión rechazada, sin autorización. Tabla 4: Códigos de retorno del mensaje CONNACK Una vez que la conexión ha sido establecida, el broker la mantiene abierta hasta que el cliente se desconecta o la conexión se pierde. Si el mensaje CONNECT está mal formado o ha pasado demasiado tiempo entre la apertura del socket y el envío del mensaje, el broker cierra la conexión para evitar que haya clientes que ralenticen al servidor [6]. 4.2.3 Modelo Publish/Subscribe El modelo publicación/subscripción proporciona una alternativa a la arquitectura tradicional de cliente/servidor. En el modelo cliente/servidor, un cliente se comunica directamente con el extremo. El modelo pub/sub separa al cliente que envía el mensaje (publicador) del cliente o clientes que reciben el Aplicación Desarrollada 40 mensaje (subscriptores). Los publicadores y los subscriptores nunca se comunican entre ellos directamente. De hecho, puede que no estén al tanto de la existencia de los otros. La conexión entre ellos es manejada por un tercer componente, el broker. El trabajo del broker es filtrar todos los mensajes recibidos y distribuirlos correctamente a los subscriptores. El aspecto más importante de esta arquitectura es la capacidad de dejar al margen al publicador en un mensaje enviado por el subscriptor. En resumen, el modelo pub/sub elimina la comunicación directa entre el publicador del mensaje y el receptor. La capacidad de filtrado del broker hace posible controlar qué cliente recibirá qué mensaje. Para publicar o recibir mensajes, los publicadores y subscriptores solo necesitan saber la dirección IP, o el nombre del servidor, y el puerto del broker. Pub/Sub escala mejor que el enfoque tradicional de cliente/servidor. Esto se debe a que las operaciones en el broker pueden ser paralelizadas y los mensajes pueden procesarse de una manera controlada por eventos. El almacenamiento en caché de mensajes y el enrutamiento inteligente de mensajes son, a menudo, factores decisivos para mejorar la escalabilidad [4]. Existen cinco tipos de mensajes para la comunicación entre cliente y servidor: publish, subscribe, suback, unsubscribe y unsuback [5]. 4.2.3.1 PUBLISH Cada mensaje presenta un payload (relleno) que contiene los datos a transmitir en el formato que el cliente indique. El contenido de este mensaje se puede observar en la tabla 5. CONTENIDO DESCRIPCIÓN packetId Identifica de forma exclusiva un mensaje a medida que fluye entre el cliente y el broker. topicName Cadena simple que está estructurada jerárquicamente con barras diagonales como delimitadores. qos Indica el nivel de la calidad de servicio (QoS) del mensaje. Hay tres niveles: 0, 1 y 2. El nivel de servicio determina qué tipo de garantía tiene un mensaje de alcanzar el destino previsto. retainFlag Esta bandera define si el mensaje ha sido guardado por el broker como el último valor conocido para un topic especifico. Cuando un cliente nuevo se subscribe a un topic, recibe el último mensaje almacenado para ese tema. payload Este campo es el contenido real del mensaje. Es posible enviar imágenes, texto en cualquier codificación, datos encriptados y cualquier dato binario. 41 Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción dupFlag Esta bandera indica que el mensaje es un duplicado y fue reenviado porque el destino previsto no asintió el mensaje original. Tabla 5: Contenido mensaje PUBLISH Cuando un cliente envía un mensaje al broker para ser publicado, este lee el mensaje, lo asiente, y lo procesa, de manera que determina qué clientes están subscritos al topic y les envía el mensaje. 4.2.3.2 SUBSCRIBE Para recibir mensajes de un tema, el cliente envía un mensaje de subscripción al broker. Este mensaje es muy simple, conteniendo un identificador de paquete y una lista de subscripciones. CONTENIDO DESCRIPCIÓN packetId Identifica de forma exclusiva un mensaje a medida que fluye entre el cliente y el broker. Este identificador es fijado por la librería del cliente o por el broker. qos1 topic1 qos2 topic2 … Un mensaje SUBSCRIBE puede contener múltiples subscripciones para un cliente. Cada subscripción se realiza a partir de un topic y un nivel de QoS. Tabla 6: Contenido mensaje SUBSCRIBE 4.2.3.3 SUBACK Para confirmar cada subscripción, el broker envía un mensaje de asentimiento al cliente. Este mensaje contiene el identificador de paquete del mensaje original de subscripción y una lista de códigos de retorno, devolviendo 128 en caso de fallo. Ilustración 11: Paso de mensajes SUBSCRIBE/PUBLISH Después de que un cliente envíe correctamente el mensaje de suscripción y reciba el asentimiento, obtendrá todos los mensajes publicados que coinciden con un tema en las suscripciones que contenía el mensaje SUBSCRIBE. Aplicación Desarrollada 48 Ilustración 21: Configuración NEO-6M Una vez iniciados los puertos para la comunicación UART, comenzamos a recibir información a través del monitor serie presente en el IDE. La información enviada por el dispositivo sigue el protocolo NMEA (National Marine Electronics Asociation), de modo que los datos recibidos son sentencias estándares para la recepción de datos GPS. Ilustración 22: Lectura de datos GPS Estas sentencias tienen una longitud media de 70 caracteres, en la que la información se presenta separadas simplemente por comas. Debido a esto, obtener los datos se convierte en una tarea tediosa. Para ello, incluiremos la librería ‘TinyGPS++’, la cual se encarga de facilitarnos la substracción de los distintos campos a tener en cuenta. Ilustración 23: Tratamiento de datos GPS para la localización Los campos que hemos necesitado tanto para la latitud como para la longitud han sido los grados de ambos, con 6 decimales de precisión, y el signo de ellos, para poder hallar si se trata de norte o sur. Gracias a estos datos se consigue obtener la localización completa del dispositivo. 49 Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción Ilustración 24: Conexión Arduino con GPS 4.4.2 Broker Para que los clientes puedan comunicarse con el servidor, es necesaria la creación de una instancia, la cual ofrece el nombre del servidor, los puertos de conexión y distintos datos para la seguridad de la comunicación. Para obtener una instancia del broker MQTT debemos acceder a la página oficial de CloudMQTT y registrarnos, si no lo hemos hecho anteriormente. También es posible acceder con una cuenta de GitHub o Google, por lo que en nuestro caso utilizaremos el acceso a través de la plataforma GitHub. Ilustración 25: Página de acceso a CloudMQTT. Aplicación Desarrollada 50 Tras acceder, nos encontraremos en la página principal de nuestra cuenta, en la que se muestra una lista de nuestras instancias creadas. Ilustración 26: Página principal con listado de instancias creadas. Para proceder a crear una nueva instancia, pulsaremos sobre el botón verde de la esquina superior derecha, que indica ‘Create New Instance’. Ilustración 27: Paso 1 para crear nueva instancia Esta plataforma dispone de distintos planes de subscripción dependiendo de las características del servidor que se vayan buscando. En nuestro caso, el plan Cute Cat es adecuado para nuestras necesidades ya que permite la conexión de hasta 5 clientes y es gratuito. 51 Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción Ilustración 28: Selección de región para la instancia Una vez seleccionada una región para los servidores de AWS, podremos confirmar la instancia y obtener toda la información de esta. Ilustración 29: Información de la instancia creada en CloudMQTT La comunicación de ambos sensores con el broker se lleva a cabo gracias a la librería ‘PubSubClient’. Esta librería permite la conexión de un cliente MQTT con el servidor para el posterior envío/recepción de mensajes. Ilustración 30: Creación cliente MQTT Aplicación Desarrollada 52 Para la configuración, se crea un cliente MQTT a partir de un cliente Ethernet. Con este cliente, se establece el servidor mediante el hostname y el puerto indicado en la instancia. Tras esto, ya es posible conectarse al broker. Ilustración 31: Conexión al broker MQTT desde el Arduino La conexión al servidor se llevará a cabo mediante la autenticación usuario-contraseña indicados, de nuevo, en la instancia. El campo principal de la conexión es un identificador de cliente con el que se identifican los paquetes de publicación/subscripción. El resto de los campos obligatorios indicados en la tabla 2, se encuentran definidos en la función ‘connect’, tomando los valores por defecto de 15 segundos para ‘keepAlive’ y true para ‘cleanSession’. Si la conexión ha sido exitosa, es necesario establecer un callback al que acudirá el programa tras recibir algún evento. En nuestro caso, esta función simplemente se encarga de imprimir al monitor. Para proceder a la publicación de los datos, es necesario estar subscrito con anterioridad al tema al que se quiere enviar la información. Ilustración 32: Subscripción a los topics desde el Arduino De esta forma, se van a necesitar 8 topics a los que subscribirse: ▪ MPU-6050 - acc_x : eje x acelerómetro. - acc_y : eje y acelerómetro. - acc_z : eje z acelerómetro. - temperature : temperatura dada por el acelerómetro. - gyro_x : eje x giroscopio. 53 Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción - gyro_y : eje y giroscopio. - gyro_z : eje z giroscopio. ▪ NEO-6M - map : localización obtenida por el GPS. Los datos enviados al broker deben ser cadenas, por lo que las lecturas del MPU son convertidas a tipo String antes de ser publicadas al topic. Ilustración 33: Publicación de la temperatura obtenida en el topic ‘temperature’ 4.4.3 Presentación de datos Una vez que los datos son recogidos por el broker, todos los clientes subscritos a dichos topics obtendrán la información conforme vaya llegando al servidor. La aplicación IoT MQTT Panel es un cliente MQTT que se encuentra subscrito a los topics definidos en el apartado anterior, y los presenta de forma visual. Para ello, la aplicación dispone de una larga lista de widgets de la cual se han elegido los siguientes: ▪ Gauge: la temperatura variará desde un mínimo de 0 a 50 grados con diferencia de color según el tramo en el que se encuentre. ▪ Gráfico: los ejes del acelerómetro, como los del giroscopio se disponen en dos gráficos, dentro de los cuales se diferencian tres gráficas de puntos, una por cada eje. ▪ URI: la URL enviada al topic ‘map’ podrá ser lanzada a través de este widget una vez recibida. Esta aplicación se puede obtener gratuitamente en Google Play. Una vez instalada, hay que crear una nueva conexión al broker en cuestión. Para ello se pulsa sobre el círculo naranja en la esquina inferior derecha y nos lleva a la configuración del servidor al que conectarnos. Aplicación Desarrollada 54 Ilustración 34: Página principal IoT MQTT Panel y nueva conexión Los campos se rellenan con los datos recogidos en la instancia de CloudMQTT. En opciones avanzadas es necesario proporcionar el nombre del usuario y contraseña con el que acceder a la instancia. Ilustración 35: Configuración avanzada de la conexión Una vez conectados al broker podemos comenzar a añadir los widgets necesarios para la visualización de los datos. Para ello, pulsaremos sobre el círculo naranja que aparece tal y como el de la ilustración 31. Comenzaremos por el widget ‘gauge’, para el topic ‘temperature’. 55 Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción Ilustración 36: Creación Panel Gauge El acelerómetro y giroscopio se disponen en dos gráficos de líneas, con la misma configuración, exceptuando el nombre de los topics. Ilustración 37: Configuración panel gráficos El último panel está dedicado al GPS, con una configuración muy sencilla. Este widget se encarga de lanzar la URL recibida al topic ‘map’. Aplicación Desarrollada 56 Ilustración 38: Configuración panel URI y dashboard final. El siguiente y penúltimo capítulo, muestra un ejemplo de ejecución del proyecto realizado y los resultados obtenidos tras él. 57 Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción 5 VALIDACIÓN n este capítulo se exponen las pruebas realizadas con los distintos elementos del sistema para la validación de la correcta realización del proyecto. En él sepresentan los pasos realizados para la ejecución del programa, así como los resultados obtenidos. 5.1 Ejecución El Arduino presenta una entrada para la carga de tensión, a la cual conectaremos un cable USB con puerto final el ordenador indicado en el subapartado 3.1.1. Ambos módulos se deben conectar a Arduino según la conexión especificada en el capítulo 4, como podemos comprobar en las ilustraciones 10 y 12. Además de esta conexión, es necesario que exista acceso a internet, por lo que debemos conectarle al módulo Ethernet Shield un cable Ethernet desde un router o desde algún puerto con conexión directa a la red. Tras ello, abriremos el software Arduino IDE, gracias al cual podremos cargar el programa en el dispositivo. Ilustración 39: Cargar programa en el Arduino E Una obra sin finalidad se parecería más a los delirios de un loco que a los sobrios esfuerzos del genio o del sabio. Hume Conclusiones y líneas futuras 64 64 65 Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción REFERENCIAS [1] MQTT 3.1.1 Specification, [En línea]. Disponible en: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqttv3.1.1.html [2] MQTT Getting started, [En línea]. Disponible en: https://www.hivemq.com/mqtt/ [3] Introducing the MQTT Protocol - MQTT Essentials: Part 1, [En línea]. Disponible en: https://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt/ [4] Publish & Subscribe - MQTT Essentials: Part 2, [En línea]. Disponible en: https://www.hivemq.com/blog/mqtt-essentials-part2-publish-subscribe/ [5] MQTT Publish, Subscribe & Unsubscribe - MQTT Essentials: Part 4, [En línea]. Disponible en: https://www.hivemq.com/blog/mqtt-essentials-part-4-mqtt-publish-subscribe-unsubscribe/ [6] Client, Broker / Server and Connection Establishment - MQTT Essentials: Part 3, [En línea]. Disponible en: https://www.hivemq.com/blog/mqtt-essentials-part-3-client-broker-connection- establishment/ [7] CloudMQTT Documentation, [En línea]. Disponible en: https://www.cloudmqtt.com/docs/index.html [8] Security Enabled M2M Communication using CloudMQTT Broker : IOT Part 19, [En línea]. Disponible en: https://www.engineersgarage.com/contribution/D2D-Communication-MQTT- Protocol-ClodMQTT-Broker [9] ¿Qué es el Internet de las Cosas y cómo va a cambiar nuestra sociedad?, [En línea]. Disponible en: https://www.blog.andaluciaesdigital.es/que-es-internet-de-las-cosas/ [10] Arduino Ethernet Shield, [En línea]. Disponible en: https://www.arduino.cc/en/Guide/ArduinoEthernetShield [11] Video tutorial: Using the Arduino Ethernet shield, Part 1 of 2, [En línea]. Disponible en: https://www.youtube.com/watch?v=vcOE2XAQHzY [12] Efecto Coriolis, [En línea]. Disponible en: https://es.wikipedia.org/wiki/Efecto_Coriolis [13] Sensor MPU 6050, [En línea]. Disponible en: https://www.diarioelectronicohoy.com/blog/sensormpu6050 [14] Guide to NEO-6M GPS Module with Arduino, [En línea]. Disponible en: https://randomnerdtutorials.com/guide-to-neo-6m-gps-module-with-arduino/ [15] Arduino IDE, [En línea]. Disponible en: https://en.wikipedia.org/wiki/Arduino_IDE [16] Authentication with Username and Password - MQTT Security Fundamentals, [En línea]. Disponible en: https://www.hivemq.com/blog/mqtt-security-fundamentals-authentication-username-password/ Referencias 66 66 [17] Interface ublox NEO-6M GPS Module with Arduino, [En línea]. Disponible en: https://lastminuteengineers.com/neo6m-gps-arduino-tutorial/ [18] Tutorial MPU6050, Acelerómetro y Giroscopio, [En línea]. Disponible en: https://naylampmechatronics.com/blog/45_Tutorial-MPU6050-Aceler%C3%B3metro-y- Giroscopio.html [19] Introduction to MPU6050, [En línea]. Disponible en: https://www.theengineeringprojects.com/2019/02/introduction-to-mpu6050.html [20] La mejora de las soluciones en IoT pasa por la colaboración, [En línea]. Disponible en: https://blogthinkbig.com/iot-telefonica-softwareag [21] IoT MQTT Panel FAQ and feedback, [En línea]. Disponible en: http://www.snrelectronicsblog.com/iot/iot-mqtt-panel-user-guide/ [22] IoT MQTT Panel, [En línea]. Disponible en: https://play.google.com/store/apps/details?id=snr.lab.iotmqttpanel.prod [23] MPU-6050 Datasheet, [En línea]. Disponible en: https://www.invensense.com/wpcontent/uploads/2015/02/MPU-6000-Register-Map1.pdf [24] Modelo Publicación/Subscripción, [En línea]. Disponible en: https://www.ibm.com/support/knowledgecenter/es/SSMKHH_10.0.0/com.ibm.etools.mft.doc/aq01120 _.htm [25] Happ, Daniel & Karowski, Niels & Menzel, Thomas & Handziski, Vlado & Wolisz, Adam. (2016). Meeting IoT platform requirements with open pub/sub solutions. Annals of Telecommunications. 72. 10.1007/s12243-016-0537-4. [26] Comunicaciones con Arduino, [En línea]. Disponible en: https://aprendiendoarduino.wordpress.com/2014/11/18/tema-6-comunicaciones-con-arduino-4/ 67 Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción Referencias 68 68 69 Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción ANEXOS Los programas realizados para ambos sensores presentan una arquitectura similar en la que se distinguen las siguientes partes: 1. Incluir librerías necesarias 2. Definir variables 3. Definir objetos 4. Función setup 5. Función loop En la primera parte se incluyen las librerías nombradas en los subapartados anteriores. Sin ellas no sería posible que el programa funcionara correctamente. El segundo apartado reúne la definición de constantes como la dirección de esclavo del MPU o los números de pines para la comunicación serie, así como variables para almacenar la información leída de ambos módulos. Los objetos definidos son los necesarios para las comunicaciones de internet, con los sensores y con el broker. La función setup se ejecuta una sola vez y en ella se incluye la configuración necesaria para el programa. Se inicia la comunicación serie, la conexión a internet y el servidor MQTT. En esta función también se configura el módulo MPU para que se encuentre iniciado. Por último, la función loop se ejecuta una vez tras otra, por lo que en ella se incluye la lectura de los sensores y la subscripción/publicación de la información. 1. Aplicación IoT para Arduino con MPU-6050 Anexos 70 70 71 Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción Anexos 72 72 2. Aplicación IoT para Arduino con NEO-6M 73 Recolección de datos de sensores en la IoT con Arduino y su gestión mediante un protocolo de mensajes basado en el patrón publicación y subscripción Anexos 80 80