Demostrador de Internet of Things con la tecnología IEEE 802 15 4e utilizando la plataforma OpenMote y el sistema operativo OpenWSN y theThings io

Texto completo

(1)Demostrador de Internet of Things con la tecnología IEEE 802.15.4e utilizando la plataforma OpenMote y el sistema operativo OpenWSN y theThings.io Francisco Mudarra Capdepont Máster Universitario en Ingeniería de Telecomunicación Área: Telemática Jose López Vicario Junio 2018.

(2) Copyright © Francisco Mudarra Capdepont. Reservados todos los derechos. Está prohibido la reproducción total o parcial de esta obra por cualquier medio o procedimiento, comprendidos la impresión, la reprografía, el microfilme, el tratamiento informático o cualquier otro sistema, así como la distribución de ejemplares mediante alquiler y préstamo, sin la autorización escrita del autor o de los límites que autorice la Ley de Propiedad Intelectual..

(3) FICHA DEL TRABAJO FINAL Demostrador de Internet of Things con la tecnología IEEE 802.15.4e utilizando la Título del trabajo: plataforma OpenMote y el sistema operativo OpenWSN y theThings.io. Nombre del autor: Francisco Mudarra Capdepont Nombre del consultor/a: Jose López Vicario Nombre del PRA: Xavier Vilajosana Guillen Fecha de entrega: 06/2018 Titulación:. Máster Universitario Telecomunicación. en. Ingeniería. de. Área del Trabajo Final: Telemática Idioma del trabajo: Español Palabras clave. Internet Of OpenMote. Things. (IoT),. OpenWSN,. Resumen del Trabajo En los últimos años, Internet de las cosas (IoT) se ha convertido en una de las tendencias más relevantes dentro del mundo de las telecomunicaciones. El principal objetivo de este TFM consiste en el desarrollo de un sistema que capaz de demostrar el uso del IoT utilizando para ello la tecnología IEEE 802.15.4e, combinado con el hardware de la plataforma OpenMote y el sistema operativo OpenWSN y almacenando los datos en la plataforma theThings.io. Para ello se desarrollará una aplicación en Python que funcionará bajo el entorno de OpenWSN, que será capaz de recibir las lecturas de un sensor de temperatura y otro de luminosidad. Estos datos serán procesados y tratados en una Raspberry Pi y se presentará una comparativa entre los modelos de Fog computing y de Cloud computing. Se presentarán los resultados obtenidos demostrando así la fiabilidad del sistema y la utilidad del mismo, quedando probada la demostración de un sistema IoT.. i.

(4) Abstract (in English, 250 words or less):. In recent years, the Internet of Things (IoT) has become one of the most significant trends in the world of telecommunications. The main objective of this TFM (project) is the development of a system that can demonstrate the use of the IoT using the IEEE 802.15.4e technology, combined with the OpenMote platform hardware and the OpenWSN operating system, and storing the data in the theThings.io platform. For this, an application in Python will be developed that will work under the OpenWSN environment, which will be able to receive the readings of both a temperature and a luminosity sensor. These data will be processed and treated in a Raspberry Pi and a comparison between the Fog computing and Cloud computing models will be presented. The results obtained will be presented, demonstrating the reliability and usefulness of the system, resulting in the demonstration of an 'IoT system'.. ii.

(5) Índice. 1. Introducción .................................................................................................... 1 1.1 Contexto y justificación del Trabajo ...................................................... 1 1.2 Objetivos del Trabajo .............................................................................. 1 1.3 Enfoque y método seguido .................................................................... 2 1.4 Planificación del Trabajo ........................................................................ 3 1.5 Breve sumario de productos obtenidos ................................................ 5 1.6 Breve descripción de los otros capítulos de la memoria .................... 5 2. Contexto de trabajo ........................................................................................ 6 2.1 Internet de las Cosas (IoT)...................................................................... 6 2.1.1 Introducción ...................................................................................... 6 2.1.2 Arquitectura de los sistemas IoT ....................................................... 6 2.1.3 Protocolos de los sistemas IoT ......................................................... 9 2.1.3.1 Introducción ............................................................................... 9 2.1.3.2 Protocolos de datos ................................................................. 10 2.1.3.3 Protocolos de comunicación .................................................... 12 2.2. Estándar IEEE 802.15.4 ........................................................................ 14 2.2.1 Introducción .................................................................................... 14 2.2.2 Capa de enlace de datos ................................................................ 15 2.2.3 Formato de las tramas MAC ........................................................... 16 2.3. Estándar IEEE 802.15.4e ...................................................................... 16 2.3.1 Modos de operación ....................................................................... 17 2.3.2 Low Energy ..................................................................................... 18 2.3.3 Trama IEEE 802.15.4e.................................................................... 19 2.4 Computing layers .................................................................................. 20 2.4.1 Cloud Computing ............................................................................ 20 2.4.2 Edge y Fog Computing ................................................................... 21 2.4.2.1 Introducción ............................................................................. 21 2.4.2.2 Beneficios Fog Computing ....................................................... 22 2.4.2.3 Edge Computing vs Fog Computing ........................................ 23 3. Descripción de sistema ................................................................................ 27 3.1. Introducción .......................................................................................... 27 3.2. Arquitectura del sistema ...................................................................... 28 3.3. Desarrollo software .............................................................................. 30 3.3.1 Introducción .................................................................................... 30 3.3.2. Herramientas utilizadas.................................................................. 32 3.3.3. Configuración en Raspberry Pi 3 Model B ..................................... 35 3.3.4. Definición de la red ........................................................................ 37 3.3.4.1 Introducción ............................................................................. 37 3.3.4.2 Topología ................................................................................. 37 3.3.4.2 Motes ....................................................................................... 38. iii.

(6) 3.3.4.3 Conectividad ............................................................................ 39 3.3.5. Bloque de sensores ....................................................................... 39 3.3.5.1 Modificación del firmware ........................................................ 41 3.3.6. Bloque central y aplicación en Python. .......................................... 44 3.3.7. Bloque en la nube. Plataforma THETHINGS.IO ............................ 54 4. Verificación del sistema ................................................................................ 60 4.1. Introducción .......................................................................................... 60 4.2. Verificación formación de la red con OpenWSN ............................... 60 4.3. Verificación comunicación bloque central y bloque de sensores ... 62 4.4. Verificación comunicación bloque central con THETHINGS. ........... 63 4.5. Comparación resultados Fog Computing vs Cloud Computing ...... 66 5. Conclusiones y líneas futuras....................................................................... 68 5.1. Lecciones aprendidas .......................................................................... 68 5.2. Objetivos cumplidos ............................................................................ 68 5.3. Seguimiento de la planificación .......................................................... 69 5.4. Líneas futuras de trabajo ..................................................................... 69 6. Glosario ........................................................................................................ 70 7. Bibliografía ................................................................................................... 71 8. Anexos ......................................................................................................... 73 8.1. Axeno I: Main_IoT_System .................................................................. 73. 4.

(7) Índice de figuras Ilustración 1: Diagrama de Gantt Ilustración 2: Definición IoT [2] Ilustración 3: Arquitectura sistemas IoT [6] Ilustración 4: Protocolos IoT [8] Ilustración 5: Capa y diseño CoAP [21] Ilustración 6: Topologías redes en estrella, peer-to-peer y en árbol [13] Ilustración 7: Relación IEEE 802.15.4 con el sistema OSI [22] Ilustración 8: Trama MAC IEEE 802.15.4 [12] Ilustración 9: Timeslot trama TSCH [9] Ilustración 10: Mecanismos CSL [11] Ilustración 11: Mecanismo RIT [11] Ilustración 12: Trama IEEE 802.15.4e [11] Ilustración 13: Servicios Cloud Computing [15] Ilustración 14: Fog Computing [16] Ilustración 15: Arquitectura Fog Computing en IoT [16] Ilustración 16: Capas en el procesado de datos IoT [17] Ilustración 17: Cloud & Fog Computing [23] Ilustración 18: Arquitectura del sistema Ilustración 19: Arquitectura software Ilustración 20: Git clone - TortoiseGit Ilustración 21: Definición TUN [1] Ilustración 22: Configuración TUN [1] Ilustración 23: OpenWSN con red simulada [1] Ilustración 24: OpenVisualizer entorno consola Ilustración 25: Descripción Raspberry Pi 3 Model B [24] Ilustración 26: Win32 Disk Imager Ilustración 27: Topology red simulada Ilustración 28: OpenWSN - Motes Ilustración 29: Connectivity red simulada Ilustración 30: Modificación firmware CoAP_CODE_REQ_GET Ilustración 31: Modificación firmware CoAP_CODE_REQ_GET Ilustración 32: Inicialización en Openapps.c Ilustración 33: Esquema sistema IoT Ilustración 34: lecturaDatosSensores Ilustración 35: Config_Sensores_IoT.csv Ilustración 36: Call_BBDD Ilustración 37: Main_IoT_System_Historical.csv Ilustración 38: Envio_SMS_Clientes Ilustración 39: BBDD_Clientes_IoT.csv Ilustración 40: Send_THETHINGS Ilustración 41: Flujograma Main_IoT_System.py Ilustración 42: Flujograma elección lectura Ilustración 43: Registro THETHINGS.IO Ilustración 44: Cuenta THETHINGS.IO Ilustración 45: THETHINGS.IO módulo Python Ilustración 46: Creación de un nuevo “Thing” Ilustración 47: Configuración dashboard Ilustración 48: Configuración dashboard temperatura Ilustración 49: Dashboard, actuador Ilustración 50: Recepción paquetes RPL DAO Ilustración 51: Respuesta ping a motes Ilustración 52: Inicialización red OpenWSN Ilustración 53: Captura Wireshark de la red OpenWSN Ilustración 54: Ejecución Main_IoT_System Ilustración 55: Protección ante errores de comunicación. 4 6 8 9 11 15 15 16 18 19 19 19 21 22 23 24 26 29 31 32 33 34 34 35 36 36 38 38 39 41 42 44 46 47 48 48 49 50 50 51 52 53 54 55 55 56 57 58 58 60 61 61 61 62 63.

(8) Ilustración 56: Resultados en theThings.io Ilustración 57: Actuador. Cambio de valor Ilustración 58: Resultados acción actuador Ilustración 59: Aviso vía SMS. Twilio Ilustración 60: Captura Wireshark conexión con internet Ilustración 61: Latencia con theThings.io. 64 64 65 65 66 66.

(9) Índice tablas Tabla 1: Comparativa protocolo de datos IoT [20] ..................................................................................... 12 Tabla 2: Comparativa protocolos de comunicación IoT.............................................................................. 13 Tabla 3: Propiedades del IEEE 802.15.4 [12] .............................................................................................. 14 Tabla 4: Cloud Computing vs Fog Computing [18] ..................................................................................... 25 Tabla 5: Cloud Computing vs Fog Computing 2 [18] .................................................................................. 25 Tabla 6: Pila de protocolos OpenWSN [1] ................................................................................................... 27 Tabla 7: Posibles valores para el sensor de temperatura ........................................................................... 43 Tabla 8: Posibles valores para el sensor de luminosidad ............................................................................ 43 Tabla 9: Tráfico Cloud Computing vs Fog Computing ................................................................................. 67.

(10) 1. Introducción 1.1 Contexto y justificación del Trabajo Este proyecto nace por el actual auge del Internet de las cosas (IoT – Internet of Things). En los últimos años, Internet de las cosas se ha convertido en una de las tendencias más relevantes dentro del mundo de las telecomunicaciones. Es por lo tanto, una de las motivaciones de este TFM, tanto la documentación de esta nueva tecnología, la investigación de todas las alternativas posibles para los sistemas IoT y el desarrollo de una plataforma que permita la demostración de un sistema funcional IoT. Con una demanda cada vez mayor de conexiones a internet, con mayores velocidades y de más dispositivos conectados a red, donde prácticamente cualquier dispositivo electrónico se pueda conectar a internet, es el marco ideal para el IoT. Las posibilidades del IoT van desde la automatización de procesos, domótica, eficiencia energética o gestión de la información. La eficiencia energética y el ahorro energético es una de las principales preocupaciones ambientales actuales y en las que se hace especial hincapié y uno de los pilares básicos de la domótica. En este proyecto se utilizarán nodos OpenMote sobre el sistema OpenWSN, se utilizarán los protocolos IEEE 802.15.4e, HTTP y plataformas como Raspberry Pi y THETHINGS.IO. 1.2 Objetivos del Trabajo El objetivo principal de este trabajo fin de máster es el desarrollo de una red IoT utilizando el estándar IEEE 802.15.4e sobre un sistema OpenWSN y con la plataforma THETHINGS.IO. Y el desarrollo HW de la misma red en la plataforma OpenMote y con una Raspberry Pi. Dentro del objetivo principal se puede desglosar los siguientes objetivos: -. Familiarizarse y aprender a utilizar la plataforma OpenWSN. Estudiar su funcionamiento y la puesta a punto del equipo para su correcta utilización.. -. Estudio y análisis del estándar IEEE 802.15.4e. Así como de los estándares más relevantes para poder realizar una comparativa entre ellos.. -. Estudio de los diferentes trabajar relacionados y de los nuevos conceptos de computación: Cloud computing, edge computing y fog computing.. 1.

(11) -. Estudio y documentación de las plataformas OpenWSN, OpenMote y Raspberry.. -. Desarrollar un software que permita controlar la red implementada, adquisición de datos, procesado de los datos, representación de los datos, almacenamientos de los datos y control de los mismos con los lenguajes Python y C.. -. Desarrollo de un software que permita la transmisión de datos con la plataforma de THETHINGS.IO y la representación de los mismos dentro de la plataforma.. -. Elaboración de una memoria que sirva como presentación del trabajo realizado.. 1.3 Enfoque y método seguido Cómo propuestas para el desarrollo de un demostrador de IoT, se han propuesto varios tipos de redes que permitan demostrar el uso del IoT y sus posibles beneficios. Como punto de partida, se proponen tres posibles soluciones: a). Aplicaciones de domótica que sirvan para el control de la vivienda y para mejorar el uso energético de la misma. Se propone una red formada por un sensor de luminosidad y otro de temperatura que irán reportando constantemente la cantidad de luz detectada y la temperatura medida. A su vez, esto podrá servir para abrir o cerrar persianas o para activar o desactivar la climatización según se desee. También podrá ser algo que el usuario pueda controlar según lo necesite.. b). Un control de corriente que permita activar o desactivar a petición del usuario. Esta opción finalmente se descarta que no ofrece un análisis de datos demasiado sustancial.. c). Un control de consumo de gasolina de un automóvil, para que se pueda analizar si es rentable o no la compra de un nuevo vehículo. También se ha descartado esta opción ya que la instalación sería complicada y no se usaría el estándar IEEE 802.15.4e el cual es un requisito inicial de este TFM.. Finalmente se ha optado por modelar una red de domótica que incluirá un sensor de temperatura, un sensor de luminosidad y un actuador que permita el control del usuario de ciertos elementos. Todos los sensores se crearan de forma simulada dentro de la plataforma OpenWSN. Con esto conseguiremos, una red funcional, con suficientes datos como para hacer un procesado de la información antes de enviar los datos a la nube y de tener un sistema que sea capaz de recibir. 2.

(12) información y de enviar información a los sensores para que estos puedan ser modificados. Es también importante resaltar que el trabajo las dos partes del trabajo. La primera de ellas donde se ha invertido especial esfuerzo, es la parte de documentación, de análisis del problema, de la investigación de cada uno de los aspectos tecnológicos que engloba el sistema y de los diferentes estándares que son utilizado. Y en la segunda parte, el desarrollo del sistema y la parte de innovación del mismo. Este trabajo sobre la aplicación de IoT en domótica no es único, y ya existen diversos sistemas de control de domótica en el mercado. Aunque ya se comentará con más en detalle, las principales ventajas de este trabajo respectos a otros, es la mejora de la simplicidad al usar la plataforma OpenWSN, la reducción del consumo y puesto que es código abierto cualquiera podrá continuar con el trabajo. Además se incluye un procesado previo para reducir el número de retransmisiones que se envían a la nube reduciendo así el ancho de banda requerido. También se desarrollará un software modular y configurable por usuario para que no sea necesario modificar el código. 1.4 Planificación del Trabajo Se presenta a continuación el diagrama de Gantt con la planificación temporal del TFM donde se recogen los hitos más importantes y las fechas clave de la programación. La planificación inicial se ha visto afectada debido a la necesidad de familiarizarse con las múltiples disciplinas que implica el desarrollo del TFM. El estudio de los estándares en los que está basado el sistema, protocolos y plataformas han requerido un esfuerzo especial que ha provocado el retraso del proyecto.. 3.

(13) Ilustración 1: Diagrama de Gantt. 4.

(14) 1.5 Breve sumario de productos obtenidos Los principales productos obtenidos en este TFM son: -. Modificación del firmware de OpenWSN para la emulación de sensores que simularán la emisión de datos. Para ello se enviarán datos de forma pseudoaleatoria, y en función de la hora actual, para simular un funcionamiento tipo. La función se desarrollará en C y se cargará como firmware dentro de OpenWSN.. -. Se dota al firmware también de capacidad de adquirir datos desde el nodo principal lo que permitirá el control de los sensores pudiéndolos activar o desactivar.. -. Una aplicación en Python, instalada en la Raspberry PI que se encargará de comunicarse con los diferentes sensores utilizando el protocolo de comunicación CoAP.. -. Procesado de la información previa a la emisión de datos a la nube para reducir así el número de retransmisiones y del ancho de banda requerido.. -. Módulo encargado de la comunicación la plataforma THETHING.IO y su posterior representación en la plataforma.. 1.6 Breve descripción de los otros capítulos de la memoria A continuación, se detalla un breve resumen de los capítulos de los que constará la memoria: -. Capítulo 2: Contexto del trabajo. Se detallarán los aspectos tecnológicos en los que se basa este trabajo. Introducción y detallado del Internet de las Cosas (IoT). Descripción del estándar IEEE 802.15.4e. Descripción de la plataforma OpenWSN, así como su configuración y software requerido. Descripción de los estándares de comunicación como HTTP.. -. Capítulo 3: Descripción de sistema. Se detallarán como se ha desarrollado el sistema, que elemento lo forman, descripción del software desarrollado, diseño del hardware y sus características.. -. Capítulo 4: Verificación del sistema. En este capítulo se detallarán las pruebas realizadas, comportamiento y la funcionalidad del mismo.. -. Capítulo 5: Conclusiones y líneas futuras. Se resaltarán los aspectos más importantes del proyecto, que conclusiones pueden ser tomadas y el aporte del mismo y por último que líneas futuras puede tomar el proyecto (continuación del desarrollo, comercialización, etc).. 5.

(15) 2. Contexto de trabajo 2.1 Internet de las Cosas (IoT). 2.1.1 Introducción El objetivo principal del IoT nace de la necesidad de conectar cualquier dispositivo a internet y con ello crear una nueva infinidad de aplicaciones que sin duda se ha convertido en uno de los temas más relevantes del sector y con más proyección de los últimos años. Aunque no existe una definición universal para el Internet de las Cosas, es un concepto que se refiere a la interconexión digital de objetos cotidianos a internet [3]. El termino IoT, fue usado por primera vez por el profesor Kevin Ashton en 1999. Kevin Ashton creía que el RFID (“Radio Frequency Identificacion”) era un prerrequisito para el Internet de las Cosas [4]. Es importante resaltar que la conexión de dispositivos electrónicos a internet no es concepto nuevo y que ya se utilizaba anteriormente. Ya en la década de los 80s y los 90s se utilizaban tecnologías como el M2M (Machine-to-machine) a través de las redes GSM. En 1980, en la universidad de Carnegie Melon ya se conectó una máquina de Coca-Cola a internet para su monitorización. Otros dispositivos como datafonos, son un ejemplo de dispositivos conectados a la red [5].. Ilustración 2: Definición IoT [2]. 2.1.2 Arquitectura de los sistemas IoT La arquitectura de los sistemas IoT se pueden agrupar en 4 capas bien diferenciadas. La capa de sensor, capa de redes y “Gateways”, capa de gestión de sensores y capa de aplicaciones.. 6.

(16) o Capa de sensores La capa más baja está compuesta por objetos inteligentes integrados con sensores. Los sensores permiten la interconexión del mundo físico y digital, permitiendo que la información en tiempo real sea recolectada y procesada. La reducción del hardware ha permitido la producción de potentes sensores en formas mucho más pequeñas que se integran en objetos en el mundo físico. Hay varios tipos de sensores para diferentes propósitos. Los sensores tienen la capacidad de tomar medidas tales como temperatura, calidad del aire, movimiento y electricidad. Un sensor puede medir la propiedad física y convertirla en señal que pueda ser entendida por un instrumento. La mayoría de los sensores requieren conectividad a los agregadores de sensores (gateways). Esto puede ser en forma de red de área local (LAN) como conexiones Ethernet y Wi-Fi o red de área personal (PAN) como ZigBee, Bluetooth y Ultra-Wideband (UWB). Para los sensores que no requieren conectividad con los agregadores de sensores, su conectividad con los servidores / aplicaciones de back-end puede proporcionarse mediante Wide Area Network (WAN), como GSM, GPRS y LTE. Los sensores que usan conectividad de baja potencia y baja velocidad de datos, generalmente forman redes conocidas comúnmente como redes inalámbricas de sensores (WSN). Las WSN están ganando popularidad, ya que pueden acomodar muchos más nodos de sensores a la vez que conservan la duración adecuada de la batería y cubren áreas grandes [6]. o Capa de redes y gateway Estos diminutos sensores producirán un volumen masivo de datos y esto requiere una infraestructura de red cableada o inalámbrica robusta y de alto rendimiento como medio de transporte. Las redes actuales, a menudo vinculadas con protocolos muy diferentes, se han utilizado para admitir redes de máquina a máquina (M2M) y sus aplicaciones. Con la demanda necesaria para atender una gama más amplia de servicios IOT y aplicaciones tales como servicios transaccionales de alta velocidad, aplicaciones sensibles al contexto, etc., se necesitan múltiples redes con diversas tecnologías y protocolos de acceso para trabajar entre sí en una configuración heterogénea. Estas redes pueden ser en forma de modelos privados, públicos o híbridos y están diseñadas para cumplir los requisitos de comunicación de latencia, ancho de banda o seguridad. Una posible implementación podría consistir en una infraestructura de red convergente que resuelva la fragmentación mediante la integración de redes dispares en una única plataforma de red. La abstracción de capa de red convergente permite que varias organizaciones compartan y usen. 7.

(17) la misma red de forma independiente para que su información se enrute sin comprometer sus requisitos de privacidad, seguridad y rendimiento [6]. o Capa de gestión de servicio La gestión de servicio posibilita el procesamiento de la información a través de análisis, controles de seguridad, modelado de procesos y administración de dispositivos. El análisis también se puede llevar a cabo en otras capas dentro de la arquitectura IOT. La administración de datos es la capacidad de administrar el flujo de información de datos siempre de vital importancia la seguridad de los mismos en todo el sistema de IoT [6]. o Capa de aplicación Existen diversas aplicaciones de sectores industriales que pueden aprovechar IoT. Las aplicaciones pueden ser específicas de un sector en particular, y otras aplicaciones pueden ser atractivas para múltiples sectores de la industria [6].. Ilustración 3: Arquitectura sistemas IoT [6]. 8.

(18) 2.1.3 Protocolos de los sistemas IoT 2.1.3.1 Introducción Al igual que en todas las tecnologías emergentes, en sus comienzos se produce una especie de guerra entre diferentes fabricantes y entidades reguladoras. En el mundo del IoT existen diversos protocolos que luchan por convertirse en el estándar para IoT. A continuación se presenta un esquema con los protocolos más relevantes distribuidos según la capa OSI [8]: -. Infraestructura: (ex: 6LowPAN, IPv4/IPv6, RPL) Identificación: (ex: EPC, uCode, IPv6, URIs) Transporte: (ex: Wifi, Bluetooth, LPWAN) Descubrimiento: (ex: Physical Web, mDNS, DNS-SD) Protocolos de datos: (ex: MQTT, CoAP, AMQP, Websocket, Node, XMPP, RESP API) Gestión de dispositivos: (ex: TR-069, OMA-DM) Semántica: (ex: JSON-LD, Web Thing Model) Multi-capa de estructuras: (ex: Alljoyn, IoTivity, Weave, Homekit). Ilustración 4: Protocolos IoT [8]. 9.

(19) 2.1.3.2 Protocolos de datos Se detallaran los protocolos más relevantes del momento (a fecha de redacción del actual trabajo). -. MQTT SoAP CoAP XMPP REST . MQTT. Se utiliza para dispositivos de campo con conexión celular o por satélite: Cada Kb de tráfico es valioso. Se utilizan comunicaciones bidireccionales en redes no confiables y para dispositivos alimentados por batería con bajo consumo de energía. Los dispositivos pueden dormir, pero no el 95% del tiempo. Para ellos se utilizaría MQTT-S o CoAP [7]. No es un protocolo muy recomendado para el tipo de red que se propone en este TFM. . MQTT-S. Muy parecido a MQTT pero para dispositivos que necesiten pasar más tiempo en estado de espera. Es posible escalar hasta diez veces más dispositivos que con MQTT. El cruce de direcciones NAT podría ser un problema en MQTT-S en comparación con MQTT, por lo que deben de ser direccionadas durante el proceso de diseño [7]. No es un protocolo muy recomendado para el tipo de red que se propone en este TFM. . SoAP. SoAP (Simple Object Access Protocol), es un protocolo de intercambio de información basado en XML (lenguaje de marcos extensible utilizado para almacenar datos de forma legible) diseñado para Internet, se usa para codificar información de los requerimientos de los Web Services y responder a los mensajes antes de enviarlos a la red. SOAP utiliza WSDL (Lenguaje de descripción Web Service) que es un formato XML que describe los servicios de red como un conjunto de puntos finales que operan los mensajes de petición / respuesta y UDDI (Integración universal de descripción y descubrimiento) que siendo una plataforma independiente, es una extensión del lenguaje XML que almacena y localiza aplicaciones Web Service. [21].. 10.

(20) . REST. (Representational State Transfer), se basa en HTTP para intercambiar información y no necesita encapsulado extra para ello. Es más ligero y más sencillo de utilizar pero a la vez tiene algunas limitaciones. En vez de hacer peticiones encapsuladas en un “sobre SOAP” para solicitar un servicio para lo que es necesario el wsdl, en REST las peticiones se hacen mediante el protocolo HTTP con métodos GET, POST... sin necesidad de encapsularlo. Utiliza un lo camino de comunicación entre el dispositivo y la nube y prioriza el cruce de direcciones NAT [21]. . XMPP. Escalabilidad masiva en tiempo real para aproximadamente 100.000 nodos. Se usa también cuando los mensajes del tráfico son grandes y potencialmente complicados para cada dispositivo. También se usa cuando es necesaria una seguridad extra [7]. No es un protocolo muy recomendado para el tipo de red que se propone en este TFM. . CoAP. Muy similar a MQTT-S pero con algunas mejoras respecto a ese protocolo. Con una arquitectura orientada a servicios web en vez de estar orientado a mensajes como MQTT. Es una plataforma de desarrollo libre a la que se puede acceder desde internet [7]. CoAP es, principalmente, un protocolo de “one-to-one” para transferir información de estado entre el cliente y el servidor. Si bien tiene soporte para la observación de recursos, CoAP es más adecuado para un modelo de transferencia de estado, no puramente basado en eventos. CoAP además proporciona soporte para la integración y el descubrimiento de contenido. CoAP envía y recibe paquetes UDP y está diseñado para solicitar y recibir información vía HTTP con el uso de clientes como GET, PUT, POST and DELETE [7]. Se adapta también al formato nodo-sensor con controladores de 8 bits y permite la utilización de redes 6loWPAN que fragmentan los paquetes IPv6 en pequeñas tramas de capa 2.. Ilustración 5: Capa y diseño CoAP [21]. 11.

(21) CoAP es el protocolo de datos que se utilizará para la adquisición de datos entre los sensores. El uso del protocolo de transporte UDP reduce la sobrecarga provocadas por TCP. Es un protocolo sencillo y fácil de utilizar, donde la integración con HTTP hace que sea más intuitivo de utilizar. Es aceptado por OpenWSN algo que es fundamental para el sistema y dispone de una buena cantidad de librerías de acceso libre. Se presenta a continuación, una tabla comparativa con las características más importantes de cada protocolo datos en IoT: Protocolo. CoAP. XMPP. REST. MQTT. Transporte. UDP. TCP. TCP. TCP. Mensajería. Petición/Respuesta. Publicar/Suscribir Petición/Respuesta. Petición/Respuesta. Publicar/Suscribir Petición/Respuesta. 2G, 3G, 4G Conveniencia (1000s nodos). Excelente. Excelente. Excelente. Excelente. Conveniencia LLN (1000s nodos). Excelente. Justa. Justa. Justa. Recursos de computación. 10Ks RAM/Flash. 10Ks RAM/Flash. 10Ks RAM/Flash. 10Ks RAM/Flash. Adecuado. Útil en Field Area Networks. Control remoto del cliente sobre electrodomésticos. Perfiles de consumo. Extender la mensajería empresarial a las aplicaciones de IoT. bajo. Tabla 1: Comparativa protocolo de datos IoT [20]. 2.1.3.3 Protocolos de comunicación Algunos de los protocolos de comunicación más usados en el ámbito del IoT son los siguientes: o IEEE 802.15.4 y IEEE 802.15.4e: Son un estándar que definen el acceso a nivel físico y de control de acceso para redes inalámbricas de área personal (PAN). Se usa principalmente para redes con tasas de transmisión bajas y de bajo consumo lo que lo hace ideal para el tipo de red que se pretende implementar en este TFM. Es el protocolo que utiliza OpenWSN, se comentará más en detalla en el próximo apartado. o ZigBee: Es un protocolo de alto nivel de comunicación inalámbrica para su utilización con radiodifusión digital de bajo consumo, basada en el estándar IEEE 802.15.4 de redes 12.

(22) inalámbricas de área personal (wireless personal area network, WPAN). Su objetivo son las aplicaciones que requieren comunicaciones seguras con baja tasa de envío de datos y maximización de la vida útil de sus baterías. Opera en los 2.4Ghz y su ancho de banda es de hasta 250kbps. o LoRaWan: Es una especificación para redes de baja potencia y área amplia, LPWAN (Low Power Wide Area Network), diseñada específicamente para dispositivos de bajo consumo. LoRaWAN se caracteriza por su uso en el Internet de las Cosas, y para conexiones: bidireccionales seguras, bajo consumo de energía, largo alcance de comunicación, bajas velocidades de datos, baja frecuencia de transmisión, movilidad y servicios de localización. o SigFox: Al igual que los protocolos comentados anteriormente SigFox también es un alternativa como protocolo para IoT, donde se previa el bajo consumo. Se utilizan mensajes de 12 bytes yes valido para redes de hasta 50km. Una de sus principales ventajas es que persigue la compatibilidad con los principales fabricantes del mercado. o Redes móviles: Un utilizar la propia red de telefonía móvil existente ya sea la red de GSM, UMTS o LTE. La principal ventaja es poder utilizar una red que ya está en servicio. Como principal desventaja encontramos el coste del uso de la red y que no está orientada a bajo consumo. Se presenta a continuación una comparativa entre los diferentes protocolos: Tecnología. LTE. LoRaWAN. SigFox. WiFI. ZigBee. Bandas. Banda LTE. Sub-bandas regionales. Sub-bandas regionales. 2.4 – 5.8Ghz. 2.4Ghz. 20Mhz. 125Khz – 500 Khz. 100Hz. 20, 21, 22, 23, 40, 80, 160 MHz. 600 kHz, 1.2 Mhz. OFDM, DSSS, OFDMA. CSMA/CA. DBPSK. CCK, BPSK, QPSK, 16QAM, 64QAM. DSSS, BPSK, OQPSK. 100bps / 600bps. 11-54600Mbps. 20 kbps, 40 kbps. DL UL Acceso UL Acceso DL Modulación DL. OFDMA SCFDMA. UNB / FHSS CSS. QPSK 16QAM. LoRA, (G) FSK. Máxima transferencia de datos. 1 Mbps. 0.3kbps – 50Kbps. Cobertura. 141 dB. 150-157dB. Modulación UL. 200Hz. UNB / FHSS GFSK. 146 – 162 200m 100m dB Tabla 2: Comparativa protocolos de comunicación IoT. 13.

(23) 2.2. Estándar IEEE 802.15.4. 2.2.1 Introducción El estándar IEEE 802.15.4 es un estándar definido por la entidad IEEE para el uso de redes LR-WAN (Low-Rate Wireless Personal Area Network). Como su nombre indica son redes generalmente dedicadas a redes con sensores donde la tasa de transmisiones será baja en comparación con otros tipos de redes. Se observaran transmisiones periódicas, no muy frecuentes y con tasas de envíos de datos bajas. Por lo tanto, este estándar no persigue obtener grandes velocidades de datos si no que por el contrario perseguirá un uso eficiente y bajo de la energía para que en el caso en el que los dispositivos estén conectados con batería, el consumo sea muy limitado [12]. A continuación se muestra una tabla con las principales propiedades del estándar IEEEE 802.15.4: Propiedad Rango de transmisión de datos Alcance Latencia. Rango 868 MHz: 20kb/s; 915MHz: 40kb/s; 2.4 GHz: 250 kb/s 10 – 20 Debajo de los 15 ms. 868/915 MHz: 11 canales.. Canales 2.4 GHz: 16 canales Dos PHY: 868/915 MHz y 2.4 GHz Cortos de 8 bits o 64 bits IEEE CSMA-CA y rasurado CSMA-CA El rango de temperatura industrial: 40º a +85ºC. Bandas de frecuencia Direccionamiento Canal de acceso Temperatura. Tabla 3: Propiedades del IEEE 802.15.4 [12]. El estándar IEEE 802.15.4 define la capa física y la capa de control de acceso al medio. Se espera que las redes se auto organicen y que se mantengan en funcionamiento por si mismas para reducir costes. Son varias las topologías soportadas por el estándar IEEE 802.15.4. Entre otras, las topologías más importantes son las topologías en estrella (Star network) o las topologías peer-to-peer [12].. 14.

(24) Ilustración 6: Topologías redes en estrella, peer-to-peer y en árbol [13]. Las topologías en estrella se suelen utilizar cuando los dispositivos a conectar requieren utilizar baja potencia. La topología peer-to-peer se usa para premiar la seguridad y por último la red en estructura árbol.. 2.2.2 Capa de enlace de datos La capa de enlace de datos se divide en dos sub capas: o La subcapa de enlace de acceso a medios MAC (Medium Access Control) o La subcapa de enlaces lógicos LCC (Logical link control) Dentro del modelo OSI la capa de enlace de datos queda distribuida de la siguiente forma:. Ilustración 7: Relación IEEE 802.15.4 con el sistema OSI [22]. 15.

(25) 2.2.3 Formato de las tramas MAC Lo que se persigue con las tramas MAC es que sea un protocolo simple, fácil de usar y que sea versátil para cualquier tipo de red que requiera su uso. Las tramas MAC siguen el siguiente formato:. Ilustración 8: Trama MAC IEEE 802.15.4 [12]. Las tramas MAC están formadas por: -. Encabezado (MHR): Indica que se pretende transmitir y la dirección. Unidad de servicio de datos MAC (MSDU): Pie de MAC (MFR). Dentro del campo unidad de servicio se define el campo Payload de longitud variable de hasta 127 bytes [12].. 2.3. Estándar IEEE 802.15.4e El IEEE 802.15.4e es un estándar definido por la entidad IEEE que mediante un añadido a la capa MAC incorpora nuevas funcionalidades concretas para las redes de sensores. Las principales mejoras respecto al estándar IEEE 802.15.4 son las siguientes: o Respecto al consumo energético: En IEEE 802.15.4e se implementan mejoras MAC para solucionar el problema del. 16.

(26) coste energético provocado por que los nodos intermedios en IEEE 802.15.4 requerían de estar siempre conectados. o Baja tasa de paquetes: Requiere una sincronización previa entre los nodos que forman la red. Esto provoca que la tasa de entrega de paquetes sea baja lo que es muy útil pasa sistemas de bajo consumo pero no para sistemas en tiempo real o con aplicaciones críticas. o Protección del canal: En IEEE 802.15.4e se incluye una funcionalidad para proteger el canal frente a interferencias y desvanecimientos, que lo hace ideal para entornos IoT. Estas son las principales ventajas de IEEE 802.15.4e frente a otras alternativas. Para la red que se propone en este TFM, se premiará el bajo consumo frente a otras alternativas que no son críticas en este tipo de redes, como por ejemplo, la respuesta en tiempo real que no es un requisito para la monitorización y actuación de un red de domótica. 2.3.1 Modos de operación En el estándar IEEE 802.15.4e fue publicado en abril de 2012 e incorpora nuevas mejoras y así, nuevos modos de funcionamiento que permiten su uso para aplicaciones más específicas, dotando al estándar con mayor robustez y versatilidad. Los diferentes modos de operación son los siguientes: o DSME (Deterministic & Synchronous Multi-Channel Extension): Especial para aplicaciones con alta disponibilidad, eficiencia, escalabilidad y robustez. o LLDN (Low Latency Deterministic Network): Para aplicaciones en tiempo real o con latencias muy bajas, como por ejemplo: uso en robot, industrial, etc. o TSCH (Time Slotted Channel Hopping): Se utiliza para aplicaciones de procesos de automatización. Se garantiza el ancho de banda y la latencia. Se pueden comunicar todo los nodos al mismo tiempo con el uso de diferentes canales.. 17.

(27) Ilustración 9: Timeslot trama TSCH [9]. Existe una compensación directa entre el rendimiento, la latencia y el consumo de energía. Y una programación de comunicación sin colisiones típico para aplicaciones industriales. Se utiliza también el algoritmo RR (Round Robin) para la retransmisión de paquetes. o RFID Blink (Radio Frecuency Identification Blink): Se utiliza para la identificación de personas u objetos y de la localización de los mismos. o AMCA (Asynchronous multi-channel adaptation): Se utiliza para redes más amplias o distribuidas en una región geográfica más grande. Por ejemplo: Para ciudades “Smart Cities” o en procesos de control y monitorización [10].. 2.3.2 Low Energy Low Energy (LE) es un protocolo que se define en el estándar IEEE 802.15.4e. LE permite bajar el consumo de los dispositivos por medio del duty cycle, para ellos se utilizan los mecanismos de CSL (Coordinated Sampled Listening) y Receiver Initiated Transmissions (RIT). El mecanismo de CSL consigue ahorrar energía incorporando un mecanismo que va comprobando periódicamente y ha recibido una trama de wakeup. Cuando se reciba trama de wakeup el receptor sabrá cuando despertarse y comenzar a recibir datos del emisor [11].. 18.

(28) Ilustración 10: Mecanismos CSL [11]. Por otra parte, el mecanismo RIT, se utilizado para redes PAN (Personal Area Network) que no utilizan beacons. De esta forma se envían tramas datareq utilizando CSMA/CA de forma periódica. Se escuchará el canal durante un periodo corto después de enviar las tramas para así recibir las transmisiones, una vez recibidas las tramas datareq se comenzará a enviar los datos [11].. Ilustración 11: Mecanismo RIT [11]. 2.3.3 Trama IEEE 802.15.4e Como se puede observar en la siguiente figura la trama IEEE 802.15.4e tiene la siguiente estructura:. Ilustración 12: Trama IEEE 802.15.4e [11]. 19.

(29) En la trama de la estructura IEEE 802.15.4e está formada por tres partes importantes: La MAC Header (MHR), la MAC Payload y la MAC Footer MRF y dentro de cada parte existen diferentes campos para cada uso [11]: -. Frame control: Indica el tipo de trama. Sequence Number: Etiqueta a cada trama. Addressing fields: Para especificar la dirección de destino. Auxiliary Security Header: Campo auxiliar para la seguridad. Information Elements: Que encapsulan la información.. 2.4 Computing layers 2.4.1 Cloud Computing Cloud computing nace de la necesidad de ofrecer servicios a través de Internet. La computación en la nube ofrece el acceso a recursos de software bajo demanda. Las principales características del Cloud Computing son las siguientes; Agilidad: Capacidad de mejora para ofrecer recursos tecnológicos al usuario por parte del proveedor; Costo: Reducción de los costes de la computación; Escalabilidad y elasticidad: Aprovechamiento de recursos para una respuesta en tiempo real; Independencia entre el dispositivo y la ubicación: Acceso independiente, sin depender desde donde te conectes; La tecnología de virtualización permite compartir servidores y dispositivos de almacenamiento y una mayor utilización; Rendimiento: Los sistemas en la nube controlan y optimizan el uso de los recursos de manera automática; Seguridad: Llegando a ser incluso mejor que en sistemas tradicionales; Mantenimiento: Al ser aplicaciones instaladas en la nube no es necesario un mantenimiento del usuario. Los modelos de servicio en Cloud Computing son los siguientes: -. Software as a Service (SaaS): Aplicación en línea disponible para múltiples usuarios bajo demanda. Estas aplicaciones pueden ser accesibles vía web. No es necesaria la instalación en local liberando así recursos del equipo local. Ejemplo: Google Docs, Salesforce.. -. Platform as a Service (PaaS): Plataforma para desplegar aplicaciones que se pueden escalar bajo demanda. Se permite a los usuarios desarrollar y gestionar aplicaciones sin la necesidad de tener que mantener la infraestructura. Ejemplo: Google AppEngine, cloudfoundry.. -. Infrastructure as a Service (IaaS) o Hardware as a service (HaaS): Servidores virtuales y almacenamiento disponible en forma escalable a. 20.

(30) través de la red. Se tiene el control de las aplicaciones, sistema operativo y almacenamiento de los archivos. Ejemplos: Amazon web Services, Rackspace [14]. -. Things as a Service (TaaS). Es un nuevo concepto que se está comenzando a utilizar y persigue la idea de entregar la funcionalidad IoT sin que el usuario final tenga que operar o mantener hardware extenso. Servicios que se pueden entregar en la nube para recibir y procesar los datos generados por las redes de sensores habilitados para IoT.. Ilustración 13: Servicios Cloud Computing [15]. 2.4.2 Edge y Fog Computing 2.4.2.1 Introducción “Fog Computing” o la niebla es un término que extiende el concepto de la nube para estar más cerca de las cosas que nos rodean y actúan sobre los datos de IoT.. 21.

(31) Ilustración 14: Fog Computing [16]. Estos dispositivos, denominados “fog nodes”, pueden implementarse en cualquier lugar con una conexión de red: en una fábrica, en la parte superior de un poste de energía, junto a una vía férrea, en un vehículo o en una plataforma petrolera. Cualquier dispositivo con computación, almacenamiento y conectividad de red puede ser un nodo. A diferencia del “Cloud Computing” que son servidores muy alejados de los usuarios, en el internet de las cosas (IoT) entra en juego el concepto de “Fog Computing” donde estaremos rodeados por miles de sensores, conectados y transmitiendo información [16]. Entre los ejemplos podemos encontrar controladores industriales, conmutadores, enrutadores, servidores integrados y cámaras de video vigilancia. Las posibilidades son infinitas [16]. 2.4.2.2 Beneficios Fog Computing Las ventajas del uso de “Fog Computing” son las siguientes: -. Mayor agilidad empresarial: Con las herramientas adecuadas, los desarrolladores pueden desarrollar rápidamente aplicaciones para ser implementadas donde sea necesario. Es posible generar aplicaciones para cualquier necesidad del cliente.. -. Mejor seguridad: Se pueden proteger todo los nodos “fog” utilizando la misma política, controles y procedimientos que en todas las partes de del entorno de TI.. -. Gestión de la Información, con control de privacidad: Análisis de datos confidenciales localmente en lugar de enviarlos a la nube para su análisis. Se puede monitorear y controlar los dispositivos que recopilan, analizan y almacenan datos.. -. Control del gasto operativo: Se puede procesar los datos seleccionados localmente y después enviar lo necesario a la nube [16]. Se muestra a continuación la arquitectura para “Fog Computing” basada en IoT.. 22.

(32) Ilustración 15: Arquitectura Fog Computing en IoT [16]. 2.4.2.3 Edge Computing vs Fog Computing vs Could Computing “Fog Computing” y “Edge Computing” parecen similares ya que ambas implican acercar la inteligencia y el procesamiento a la creación de datos. Sin embargo, la diferencia clave entre los dos radica en dónde se procesa la información. Un entorno “fog” ubica la inteligencia en la red de área local (LAN). Esta arquitectura transmite datos desde los puntos finales a una puerta de enlace, donde luego se transmite a las fuentes para el procesamiento y la transmisión de destino. Mientras que en “Edge computing” se realiza gran parte del procesamiento en plataformas informáticas integradas que interactúan directamente con sensores y controladores. Sin embargo, esta distinción no siempre es clara, ya que las organizaciones pueden ser muy variables en su enfoque del procesamiento de datos [17].. 23.

(33) Ilustración 16: Capas en el procesado de datos IoT [17]. Comparativa Fog Computing vs Cloud Computing Como ya se ha comentado, “Cloud Computing”, se define como un grupo de computadoras y servidores conectados a través de Internet para formar una red. Mientras que empresas y organizaciones comienzan a introducir el Internet de las cosas, la necesidad de acceder a grandes cantidades de datos de manera más rápida y local está en constante crecimiento. Aquí es donde entra en juego el concepto de "Fog Computing". “Fog Computing”, o niebla, es una infraestructura distribuida en la que ciertos procesos o servicios de aplicaciones son administrados en el borde de la red (“edge”) por un dispositivo inteligente, mientras que otros requieren que se administren en la nube. Para ello, es también necesario, una capa intermedia entre la nube y el hardware para permitir un procesamiento de datos, análisis y almacenamiento más eficientes, lo que se logra al reducir la cantidad de datos que se deben transportar a la nube. Se presenta a continuación una tabla comparativa con las principales características de cada tipo de computación.. Latencia Retardo Jitter Localización del servicio Distancia entre el. Cloud Computing Alta Alta Dentro de internet Múltiples saltos 24. Fog Computing Baja Muy bajo En el borde de las redes locales Un salto.

(34) cliente y el servidor Seguridad Posibilidad de ataques Localización definida Geo distribución Número de nodos Soporte para la movilidad Iteraciones en tiempo real Conexión última milla. Indefinida. Se puede definir. Alta. Baja. No Centralizada Pocos. Si Distribuida Muchos. Limitada. Soportada. Soportada. Soportada. Línea alquilada. Wireless. Tabla 4: Cloud Computing vs Fog Computing [18]. La mayor limitación de “Cloud Computing” se encuentra en la respuesta en tiempo real para las aplicaciones que así lo requieran. Cloud Computing La información y las aplicaciones son procesadas en la nube, esto conlleva tiempo para grandes cantidades de datos. Puede haber un problema de ancho de banda, ya que es necesario enviar cada resultado a la nube. Una respuesta lenta para escalar posibles problemas ya que los servidores están localizados en servidores remotos.. Fog Computing Más que presentar y trabajar con un servidor centralizado en la nube, fog computing opera en la capa borde o edge. Por lo que se requiere menos tiempo. Requiere un uso menor del ancho de banda, ya que esta información es trata antes de ser enviada. Puesto que se dispone de pequeños servidores edge accesible para los usuarios, es posible para fog computing reducir el tiempo de respuesta en la escalación de incidencias.. Tabla 5: Cloud Computing vs Fog Computing 2 [18]. Como conclusión, “Fog Computing” juega un papel muy importante en las demandas creadas por IoT, el aumento de dispositivos conectados a internet a la vez y transmitiendo información constantemente hace que la solución de “Cloud Computing” una herramienta insuficiente, donde los tiempos de espera, costes e eficiencia de respuesta del sistema se puede ver comprometida. Como solución se introduce el concepto de “Fog Computing” donde se procesará la información en servidores más locales y accesibles para el usuario que posteriormente se enviaran a los servidores de “Cloud Computing”. Así pues, se puede ver a “Fog Computing” como una forma de complementar a “Cloud Computing” utilizando las ventajas de cada tecnología, más que como una tecnología que pretende sustituirla.. 25.

(35) Ilustración 17: Cloud & Fog Computing [23]. 26.

(36) 3. Descripción de sistema 3.1. Introducción Con el desarrollo de este proyecto se pretende realizar la elaboración de un hardware y de un software que permita la demostración de un sistema IoT con el estándar IEEE 802.15.4e. Para ello se utilizará la plataforma OpenMote para el Hardware y OpenWSN como sistema operativo. OpenWSN proporciona una serie de implementaciones de código abierto, con una pila de protocolos completa basada en estándares del internet de las cosas (IoT) con una gran variedad de plataformas software y hardware. Esta implementación la hace muy versátil a la hora de aplicarla a redes IoT lo que ha convertido a OpenWSN en una de las plataformas más versátiles del mercado. Es una herramienta fácil de manejar y de implementar. Application. CoAP, HTTP. Transport. UDP, TCP. IP/routing. IETF RPL. Adaptation. IETF 6LoWPAN. Médium Access. IEEE802.15.4e. Phy. IEEE802.15.42006. Tabla 6: Pila de protocolos OpenWSN [1]. El sistema que se pretende desarrollar es un sistema de control y monitorización de domótica donde se pueda medir y controlar diversos parámetros de medidas que permitan hacer un uso más eficiente de la energía dentro del hogar. Para ellos, se ha implementado un sistema de que es capaz de medir la temperatura y la luminosidad de una vivienda. Con el control de estas dos magnitudes el usuario podrá conocer en todo momento el estado de su vivienda y podrá decidir si es necesario, activar la climatización, abrir o cerrar persianas en función de la luminosidad o detectar una temperatura excesivamente alta. Finalmente no ha sido posible implementar en hardware la red por lo que la solución final se presentará como una red simulada de igual o mayor complejidad que una red física. También se pretendía analizar los beneficios del control automático de las persianas en la temperatura de una vivienda para mejorar así el uso energético de la vivienda y la repercusión económica de esta mejora. 27.

(37) Como control software se presenta una aplicación en Python que se encargará del control de la red. Se encargará de comunicarse con los diferentes sensores que hay conectados a red, de almacenar los datos extraídos de los sensores y de comunicarse con ellos para accionar alguna funcionalidad extra (esto equivaldría al control de abrir o cerrar una persiana). La aplicación se encargará además de procesar la información recibida antes de subirla a la nube. Se ha prestado especial interés en desarrollar una aplicación modular que sea fácilmente editable y que soporte la ampliación de la red sin necesidad de tocar el código fuente. Para el bloque de procesamiento se ha decidido utilizar una Raspberry Pi debido a su reducido coste, tamaño y consumo que lo hacen ideal para controlar el sistema completo. Igualmente, el sistema es perfectamente funcional sobre una plataforma Windows. Y por último, el último elemento que forma parte de este trabajo es la plataforma THETHINGS.IO, donde se enviaran los datos del sistema y donde se almacenarán para que puedan ser representados fácilmente. También ha utilizado la capacidad que tiene la plataforma THETHINGS.IO de enviar datos a la red para que sirva como mecanismo de control del usuario a la red. Aunque se comentará con más detalle se ha puesto especial atención al número de llamadas que se realizan a la plataforma ya que el uso de la misma es limitado y conlleva coste. 3.2. Arquitectura del sistema El sistema está formado por tres bloques que se pueden identificar de la siguiente forma: -. El bloque de sensores.. -. El bloque central.. -. El bloque en la nube con la plataforma THETHINGS.. 28.

(38) Ilustración 18: Arquitectura del sistema. Bloque de sensores Este bloque es el encargado de tomar las medidas tanto de temperatura como de luminosidad y que serán enviadas al nodo de control (Raspberry). También será el encargado de recibir desde el nodo central las instrucciones para actuar de una forma u otra. Este bloque debería de estar formado con los diferentes sensores pero en este caso serán sensores simulados desde la plataforma OpenWSN, aunque el funcionamiento es simular. Bloque central. Este bloque esta formador por la Raspberry PI 3 aunque también podría estar formado por un ordenador con Windows. Este equipo estará configurado con las herramientas necesarias para el funcionamiento de OpenWSN así como del software necesario para su control. En este nodo central correrá la plataforma OpenWSN y el software desarrollado en Python para su control. Servirá también como base de datos para los datos capturados desde los sensores y se encargará de la comunicación con la plataforma THETHINGS.IO.. Bloque en la nube con la plataforma THETHINGS. En esta plataforma online, se recogerán los datos enviados desde el nodo central. También se configurará la forma de representar los datos tanto de forma histórica como con la medida actual. Servirá también para que el usuario pueda comunicarse con la red aplicando un control que se enviará desde THETHINGS a la red.. 29.

(39) 3.3. Desarrollo software 3.3.1 Introducción En el desarrollo y configuración del software se pueden diferenciar también tres partes importantes. -. Configuración software de Windows y Linux.. -. Desarrollo del firmware que se cargará en las placas OpenMote (Simulado), desarrollado en C.. -. Desarrollo de una aplicación de control del sistema desarrollada en Python.. En los siguientes apartados, se detallaran las herramientas utilizadas para la puesta a punto de los equipos tanto en plataformas Windows como en plataformas Linux. Se detallará también como se ha desarrollado el firmware para los Motes simulados y que hacen las veces de sensores reales. A su vez este bloque de sensores ser controlados por un firmware modelado en C, se encargará de la retransmisión de las medidas mediante el protocolo CoAP.. El módulo principal, modelado en Python, se encargará de hacer las peticiones a los sensores mediante el protocolo CoAP. Para utilizar el protocolo CoAP es necesario instalar previamente las librerías de CoAP. Estas librerías de CoAP de uso libre, son utilizadas por el programa principal para la adquisición de muestras procedentes de los sensores: p = c.GET('coap://[{0}]/i'.format(MOTE_IP)). Donde la variable MOTE_IP contendrá la IPv6 del mote al que se le quiera adquirir muestras. De una forma análoga también se utilizará la función PUT de CoAP para la implementación de actuaciones en los sensores. Esta función podría utilizarse para la apertura de una válvula, para encender o apagar un dispositivo o para que un cierto sensor funcione de una forma u otra. Puesto que en este caso los sensores son simulados, la función PUT se utilizará para hacer un cambio en los valores pseudoaleatorios, los que provocaran un cambio de magnitud en las muestras enviadas desde los sensores. Estos cambios se detallaran más adelante en la descripción del firmware.. 30.

(40) La función PUT de CoAP, es ligeramente diferente a la de GET. Es necesario también pasarle como valor la IPv6 del mote al que se quiere mandar el nuevo valor, e indicarle el nuevo valor como “payload”: p = c.PUT('coap://[{0}]/i'.format(MOTE_IP_ACTUATOR),payload = [valor_actuador],). Por último, una vez procesadas las muestras adquiridas por los sensores, estas se procesaran para ser enviadas a la plataforma de THETHINGS.IO, plataforma online para su almacenamiento y representación. También se utilizará esta plataforma para que el usuario pueda enviar cambios a los sensores. Para ello, se ha instalado las APIs de THETHINGS.IO que serán llamadas desde el programa principal para utilizar sus funciones de send & received. A continuación se muestra un esquema de la arquitectura software y como interaccionan todos los elementos entre sí:. Ilustración 19: Arquitectura software. 31.

(41) 3.3.2. Herramientas utilizadas Para la configuración de OpenWSN sobre Windows se ha seguido la referencia [1] del proyecto de Atlassian sobre OpenWSN. TortoiseGit (https://tortoisegit.org/) Con esta aplicación se podrá descargar el contenido de Github directamente, simplemente colocando la dirección del repositorio. Es una herramienta muy útil con la que se permite clonar el contenido de Github y con ella se descargará: -. El firmware de OpenWSN para cargar en los sensores OpenMote o para la creación de los sensores simulados: https://github.com/openwsn-berkeley/openwsn-fw. -. El software de OpenWSN para la red simulada, además incluye otras herramientas como OpenVisualizer necesario para el funcionamiento del sistema: https://github.com/openwsn-berkeley/openwsn-sw. -. Los módulos CoAP implementados en Python que serán necesarios para aplicar CoAP para la comunicación con los sensores: https://github.com/openwsn-berkeley/coap. Ilustración 20: Git clone - TortoiseGit. MinGW (https://sourceforge.net/projects/mingw/files/?source=navbar ). 32.

(42) Es una colección de compiladores GNU (GCC), con bibliotecas de importación y cabeceras de libre distribución que serán necesarias para la ejecución de algunas plataformas como OpenSim. Python 27 (http://sourceforge.net/projects/pywin32/) Módulo de instalación de Python necesario para la compilación de OpenWSN y para el desarrollo de las herramientas necesarias. Pycharm (https://www.jetbrains.com/pycharm/) Entorno de desarrollo de Python. Se ha elegido este entorno ya que es un entorno muy popular de Python, con una gran repositorio de librerías y que ya había trabajado con el anteriormente. SCons MinGSCons es una herramienta de construcción de software de código abierto, es decir, una herramienta de compilación y de creación de software que requiere la plataforma OpenWSN. TAP virtual interface (OpenVPN 2.4.5) OpenVPN es un software que permite la creación de una red simulada que será necesario para la simulación de los motes.. Ilustración 21: Definición TUN [1]. 33.

(43) Ilustración 22: Configuración TUN [1]. OpenSim OpenSim es una herramienta dentro del repositorio de OpenWSN que permite la creación de redes simuladas. Su funcionamiento es similar al de una red con hardware real. La principal diferencia se encuentra en que el firmware se ejecutará desde el nodo principal en vez desde los motes. OpenSim lo hace compilando el firmware del mote como un módulo de extensión de Python y creando una instancia de la clase resultante para cada mote emulado. Cuando se ejecuta la simulación, estos motes emulados se comunican con el resto de la arquitectura OpenVisualizer. Como se ilustra en el siguiente diagrama, los motes emulados interactúan de forma similar que con hardware real [1]:. Ilustración 23: OpenWSN con red simulada [1]. OpenVisualizer OpenVisualizer es una herramienta que está dentro de la plataforma OpenWSN y que es fundamental para definir la red y. 34.

(44) que se encargará de la comunicación entre los diferentes elementos. La inicialización se puede ejecutar directamente por consola o utilizando un interfaz web: scons runweb --sim. Ilustración 24: OpenVisualizer entorno consola. 3.3.3. Configuración en Raspberry Pi 3 Model B Raspberry Pi es una pequeña placa base que la forman un chip BCM2837, un procesador ARM Cortex-A53 de hasta 1.2GHz y con una RAM de 1GB. A parte a la Raspberry se le incorpora una memoria SD de 32 Gb (externa). Estos pequeños computadores tienen una potencia razonable a un precio bajo, entorno a los 30 euros, clave del éxito de estas placas. Las aplicaciones de estas placas son diversas y se pueden utilizar para casi cualquier cosa que no requiera una capacidad de procesamiento muy alta. En este TFM se utilizará servidor central del sistema, haciendo de pasarela entre los sensores, procesando la información y retransmitiéndola a la plataforma THETHING.IO.. 35.

(45) Ilustración 25: Descripción Raspberry Pi 3 Model B [24]. A la Raspberry Pi 3 se le instalará el sistema operativo Rasbian Stretch, que se puede conseguir directamente desde: https://www.raspberrypi.org/downloads/raspbian/ Raspbian incorpora un pack de software especial para el uso en programación incluyendo módulos en Python que lo hace una opción ideal para el desarrollo del sistema. Para la instalación del sistema operativo Raspbian se utiliza la herramienta Win32 Disk Imager de uso libre.. Ilustración 26: Win32 Disk Imager. 36.

(46) 3.3.4. Definición de la red 3.3.4.1 Introducción Como ya se ha comentado, se va a definir una red formada por un sensor de temperatura, por un sensor de luminosidad y por un actuador. De este modo se puede utilizar tanto la función GET como la función PUT de CoAP y demostrar la funcionalidad y la capacidad que tiene OpenWSN en el control de sensores. Puesto como la red al final ha sido una red simulada, el mote actuador que podría hubiera sido un motor que cierra o abre persianas (o cualquier otro tipo de mote que controle aperturas o encendidos) no es real, se ha decidido implementar un sistema para que el mote simulado sea capaz de detectar un valor definido por usuario e implementar un cambio de magnitud en las medidas generadas. Por lo tanto, la red simulada la formarán dos motes simulados y el modo actuador que recibe las peticiones PUT de CoAP formará parte de estos dos motes simulados. La red final está formada por el nodo principal, y dos motes adicionales para la simulación. La configuración de la red se elabora desde la plataforma OpenVisualizer de OpenWSN. Para definir la red se ha utilizado OpenVisualizer que está disponible dentro de la plataforma OpenWSN. Se puede acceder a OpenVisualizer mediante la IP de loopback: http://127.0.0.1:8080/. 3.3.4.2 Topología Para la creación de la red se ha definido una estructura peer-topeer donde todos los motes están conectados unos con otros. De esta forma todos los nodos están conectados entre sí pudiendo intercambiar información si fuera necesario o en caso de corte de una de las líneas siempre existiría una forma de acceder al mote de destino.. 37.

(47) Ilustración 27: Topology red simulada. 3.3.4.2 Motes Se ha definido también el nodo 2 como el nodo de control o DAGRoot que será el nodo principal y el encargado de gestionar la red. De esta forma en el nodo DAGRoot es donde se ejecuta el programa principal. Los nodos 1 y 3 son los motes simulados y desde donde se realizará la adquisición de datos.. Ilustración 28: OpenWSN - Motes. 38.

(48) Es posible controlar los niveles de Una vez seteado el “DAGRoot” y este se ha sincronizado correctamente, se puede observar cuáles son sus nodos vecinos, su dirección MAC, niveles de señal (RSS), etc. 3.3.4.3 Conectividad Se muestra también la relación de los sensores con el DAGRoot:. Ilustración 29: Connectivity red simulada. 3.3.5. Bloque de sensores Una de las parte del desarrollo del software consiste en la modificación del firmware de OpenWSN. El objetivo de esta modificación es la de las placas de OpenMote puedan tomar medidas correctamente y el tratamiento de las señales recibidas. En este TFM, se modificará el firmware para que genere una batería de datos aleatorios que puedan ser recibidos desde el programa principal. El firmware de control para los motes se puede obtener libremente desde el repositorio https://github.com/openwsn-berkeley/openwsn-fw. Este firmware esta modelado en C y puede ser compilado a la vez que se carga en la plataforma de OpenWSN. Para la carga y compilación en OpenWSN se realiza con la siguiente llamada:. 39.

(49) scons board=python toolchain=gcc oos_openwsn. Esta llamada realizará la compilación completa del firmware o si ya esta cargado solo compilará y cargará la parte que haya sido modificada: “ C:\Users\\Desktop\openwsn-fw>scons oos_openwsn. board=python. toolchain=gcc. . . . Compiling build\python_gcc\bsp\boards\python\supply_obj.o Compiling build\python_gcc\bsp\boards\common\aes_cbc.o Compiling build\python_gcc\bsp\boards\common\aes_ccms.o Compiling build\python_gcc\bsp\boards\common\aes_ctr.o Compiling build\python_gcc\bsp\boards\common\aes_ecb.o Compiling build\python_gcc\bsp\boards\common\firmware_crypto_engine.o Compiling build\python_gcc\bsp\boards\common\dummy_crypto_engine.o Archiving build\python_gcc\bsp\boards\libbsp.a Indexing build\python_gcc\bsp\boards\libbsp.a gcc -shared -o build\python_gcc\projects\common\oos_openwsn.pyd build\python_gcc\projects\common\03o os_openwsn\03oos_openwsn_obj.o build\python_gcc\projects\common\03oos_openwsn\openwsnmodule_o bj.o -L C:\Python27\libs -Lbuild\python_gcc\bsp\boards Lbuild\python_gcc\kernel\openos -Lbuild\python_gcc\d rivers -Lbuild\python_gcc\openstack Lbuild\python_gcc\openapps -lopenstack -lopenapps -lkernel ldr ivers -lbsp -lpython27 -Wl,--outimplib,build\python_gcc\projects\common\liboos_openwsn.a scons: done building targets.”. 40.

(50) 3.3.5.1 Modificación del firmware Con la modificación del firmware se intenta realizar la emulación de dos sensores, uno de temperatura y otro de luminosidad. Para ello se ha modificado cinfo.c para que esta pueda enviar datos pseudoaleatorios según la hora actual. Esta aplicación además tendrá la capacidad de recibir datos desde el programa principal y poder modificar así los valores enviados. La preparación de datos para que el programa principal pueda adquirirlos se elavora con la función COAP_CODE_REQ_GET. La aplicación detectará la hora actual y según la hora se enviará un dato u otro.. Ilustración 30: Modificación firmware CoAP_CODE_REQ_GET. Donde la variable “cambio_lectura” será la que el sensor reciba procedente del programa principal por medio de la función PUT de CoAP: COAP_CODE_REQ_PUT.. 41.

(51) Ilustración 31: Modificación firmware CoAP_CODE_REQ_GET. De esta forma, el programa principal recibirá dos baterías de datos según la hora y dato del actuador cargado en la variable “cambio_lectura”. Se presenta a continuación un resumen de los posibles datos que será generamos en la modificación del firmware, para el sensor de temperatura y para el sensor de luminosidad: Temperatura Hora 0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00. 0 16 14 13 12 12 11 11 11 11 12 13 14 15 16 17. 1 17 15 14 13 13 12 12 12 12 13 14 15 16 17 18. 2 18 16 15 14 14 13 13 13 13 14 15 16 17 18 19. 42. cambio_lectura 3 4 5 6 19 20 21 22 17 18 19 20 16 17 18 19 15 16 17 18 15 16 17 18 14 15 16 17 14 15 16 17 14 15 16 17 14 15 16 17 15 16 17 18 16 17 18 19 17 18 19 20 18 19 20 21 19 20 21 22 20 21 22 23. 7 23 21 20 19 19 18 18 18 18 19 20 21 22 23 24. 8 24 22 21 20 20 19 19 19 19 20 21 22 23 24 25. 9 25 23 22 21 21 20 20 20 20 21 22 23 24 25 26.