máster universitario en ingeniería de...
TRANSCRIPT
Equation Chapter 1 Section 1
Trabajo Fin de Máster
Máster Universitario en Ingeniería de
Telecomunicación
Diseño e implementación de una arquitectura IoT
basada en tecnologías Open Source.
Autor: Antonio Cobos Domínguez
Tutor: Germán Madinabeitia Luque
Dep. Ingeniería Telemática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2016
iii
Trabajo Fin de Máster
Máster Universitario en Ingeniería de Telecomunicación
Diseño e implementación de una arquitectura IoT
basada en tecnologías Open Source.
Autor:
Antonio Cobos Domínguez
Tutor:
Germán Madinabeitia Luque
Profesor titular
Dep. de Ingeniería Telemática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2016
v
Trabajo Fin de Máster: Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
Autor: Antonio Cobos Domínguez
Tutor: Germán Madinabeitia Luque
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
Sevilla, 2016
El Secretario del Tribunal
vii
A mi familia
A mis amigos
ix
Agradecimientos
A mis padres, nadie más que ellos se merece estas líneas. Antonio y Rosario, os quiero. Gracias por vuestro
apoyo en todos los sentidos. Me siento orgulloso de tener unos padres así y de poder ser el reflejo del cariño que
me habéis dado. A pesar de ser una familia con pocos recursos, me habéis enseñado que el dinero es secundario
para conseguir mis objetivos. Toda mi vida tendré un sentimiento de lealtad, respeto y agradecimiento hacia
vosotros. Como diría Don Vito Corleone, “Un hombre que no vive con su familia no puede ser un hombre”. Yo
siempre tendré en mi corazón un hogar formado por nosotros tres, donde nuestras almas jamas dejen de vivir
juntas.
No puedo olvidarme de mi Abuela Ana, mi Abuela Chica, mi titi Fali, mi tata Pili, mi tio Baldo, mi tio Carlos,
mi tia Toñi, mi tio Seba, mi tía Carlota y Ricardo (✞), gracias por estar siempre ahí. Tambien gracias a mi prima
Ana y mis primos Luis y Carlos. Y por su puesto darles gracias a mis primos Rafalito y Lucia, que desde
pequeños han estado conmigo y han sido como mis hermanos, y aunque la distancia y la edad nos separe, siempre
parece que sigue todo igual cuando nos volvemos a ver.
Gracias a mis dos abuelos, que velan por mí desde el universo y me aportan energía.
A mis amigos de la cochera, de San Diego, BLACPAAS MIMCT, muchas gracias a todos. Para mis Peppers
una mención especial; que nunca pare de sonar un Antonio Antonio entre risas y palmas.
Mención especial merece Andrés Gómez Ferrer, el cual ha invertido en mí su dedicación, su sacrificio, sus
conocimientos y su piso para la elaboración de este proyecto. Muchas gracias, de corazón.
Agradecer también a Carmen, Ana, Silvia y Belén por la aportación de las citas célebres que encabezan los
capítulos de este proyecto.
Por último, y no menos importante, un abrazo a mi Javi y a mi Carlos, porque pase lo que pase siempre estaremos
unidos. Un brindis por esas risas de madrugada. Salud.
Gracias a todos por estar y permanecer en mi vida. Cada uno me aportáis algo diferente que me hace ser mejor
persona.
GRACIAS
xi
Resumen
El mundo del Internet de las Cosas ha revolucinado el paradigma de las redes inalámbricas clásicas. Se introduce
un nuevo concepto llamado WSN (Wireless Sensors Network-Red Inalámbrica de Sensores). Este proyecto tiene
como objetivo analizar todos los actores que toman partido en este paradigma y crear un escenario con los que
hayan resultado mas adecuados, teniendo en cuenta coste, consumo y viabilidad.
Se ha creado un escenario emulando una Smart Home con tecnologías innovadoras y de código abierto que
permiten tener monitorizados y controlados ciertos parámetros de una casa. En esta casa inteligente toman
partido tecnologías como Telegram App, Apache Kafka, Procesador de Eventos Complejos (CEP), y Dweet.io.
Con respecto al hardware, se hace uso de Arduino, Raspberry Pi, antenas NRF24L01+ y multiples sensores y
módulos electrónicos.
Índice
Agradecimientos ........................................................................................................................................... ix
Resumen ....................................................................................................................................................... xi
Índice ........................................................................................................................................................... xii
Índice de Tablas ............................................................................................................................................ xv
Índice de Figuras ........................................................................................................................................ xvii
1 Introducción ........................................................................................................................................... 1 1.1. Contexto y evolución del IoT ....................................................................................................................... 1
1.1.1 Evolución del IoT ................................................................................................................................. 1 1.1.2 Características y arquitectura del IoT ................................................................................................ 2 1.1.3 Aplicaciones del IoT ............................................................................................................................. 5
1.2. Objetivo ........................................................................................................................................................ 6
2 Arquitectura General ............................................................................................................................. 7 2.1 Arquitectura general ................................................................................................................................... 8
2.1.1 Caso de uso genérico ........................................................................................................................ 11
3 Alternativas ......................................................................................................................................... 13 3.1 Tecnologías inalámbricas ......................................................................................................................... 13
3.1.1 Bluetooth Low Energy - IEEE 802.15.1 ............................................................................................. 13 3.1.2 ZigBee - IEEE 802.15.4 ....................................................................................................................... 19 3.1.3 Wi-Fi - IEEE 802.11p-WAVE .............................................................................................................. 21 3.1.4 ShockBurst Mejorado........................................................................................................................ 26 3.1.5 Comparación de tecnologías ............................................................................................................ 28
3.1.5.1 Canales de radio ........................................................................................................................ 29 3.1.5.2 Tamaño de la red ....................................................................................................................... 29 3.1.5.3 Seguridad ................................................................................................................................... 29 3.1.5.4 Tiempo de transmisión ............................................................................................................. 29 3.1.5.5 Eficiencia en la codificación de los datos ................................................................................. 30 3.1.5.6 Consumo de potencia ............................................................................................................... 31 3.1.5.7 Coste de Hardware .................................................................................................................... 34
3.2 Nodo-pasarela ........................................................................................................................................... 34 3.2.1 Características .................................................................................................................................... 35
3.2.1.1 Consumo .................................................................................................................................... 36 3.2.1.2 Coste ........................................................................................................................................... 36 3.2.1.3 Usabilidad................................................................................................................................... 37
3.3 Microcontrolador ...................................................................................................................................... 37 3.4 Cloud ........................................................................................................................................................... 39
3.4.1 Kafka ................................................................................................................................................... 39 3.4.1.1 Procesamiento de eventos complejos (CEP-Complex Events Processing)............................ 41
3.4.2 Dweet ................................................................................................................................................. 42 3.4.3 Telegram App .................................................................................................................................... 42
4 Elección de Alternativas ....................................................................................................................... 43 4.1 Elección de protocolo inalámbrico ........................................................................................................... 43
xiii
4.2 Elección de nodo pasarela ......................................................................................................................... 45
5 Desarrollo y funcionamiento ............................................................................................................... 47 5.1 Desarrollo y funcionalidad de las distintas partes ................................................................................... 47
5.1.1 Arduino ............................................................................................................................................... 47 5.1.2 Raspberry Pi 3 .................................................................................................................................... 52 5.1.3 Cloud ................................................................................................................................................... 57 5.1.4 Dweet ................................................................................................................................................. 58 5.1.5 Telegram App ..................................................................................................................................... 59 5.1.6 Scripts en la cloud .............................................................................................................................. 60
5.2 Escenario final ............................................................................................................................................ 61 5.3 Desarrollo y funcionalidad de la solución (Casos de Uso) ....................................................................... 64
6 Conclusiones ........................................................................................................................................ 69 6.1 Líneas futuras ............................................................................................................................................. 69
Anexo I ........................................................................................................................................................ 71
Anexo II ....................................................................................................................................................... 81
Anexo III ..................................................................................................................................................... 101
Anexo IV ..................................................................................................................................................... 107
Referencias ................................................................................................................................................ 111
xv
ÍNDICE DE TABLAS
Tabla 3–1. Tipos de PDU de anuncio para difusiones 18
Tabla 3–2. Comparación de tecnologías. 28
Tabla 3–3. Parámetros típicos de protocolos inalámbricos. 30
Tabla 3–4. Consumo de los chipsets de cada protocolo. 32
Tabla 3–5. Costes de adquisición de los dispositivos. 34
Tabla 3–6. C.H.I.P. vs Raspberry Pi 3. 35
Tabla 3–7. Coste de equipos. 37
Tabla 4–1. Elección de protocolo. 44
Tabla 4–2. Comparación de nodos pasarela. 45
Tabla 5–1. Conexión Arduino-NRF24L01+. 50
Tabla 5–2. Conexiones de 28BYJ-48. 51
Tabla 5–3. Conexión Raspberry Pi con NRF24L01+. 56
xvii
ÍNDICE DE FIGURAS
Figura 1-1. Momento en el que nace IoT. Fuente: ISBG Cisco 2
Figura 1-2. Sistema Básico IoT. 3
Figura 1-3. Arquitectura básica del IoT. 4
Figura 1-4. Arquitectura básica del IoT. 4
Figura 1-5. Escenario genérico del IoT. 5
Figura 2-1. Pasarela y nodos distribuidos de una WSN. 7
Figura 2-2. Topologías típicas de una WSN. 8
Figura 2-3. Arquitectura general. 10
Figura 2-4. Diagrama de secuencia en modo manual. 11
Figura 2-5. Diagrama de secuencia en modo automátic. 12
Figura 3-1. Torre de protocolos de BLE. 14
Figura 3-2. Topología bus-estrella. 15
Figura 3-3. Scatternet (conjunto de piconet). 16
Figura 3-4. Formato de trama BLE. 17
Figura 3-5. Paquete de datos BLE. 18
Figura 3-6. Paquete de difusión BLE. 19
Figura 3-7. Formato de 802.15.4 PHY. 19
Figura 3-8. Pila de protocolos de ZigBee. 20
Figura 3-9. Topologías de ZigBee. 20
Figura 3-10. Pila de protocolos de WAVE.. 21
Figura 3-11. Operación Multicanal de WAVE. 22
Figura 3-12. Estructura de trama PHY IEEE 802.11p. 23
Figura 3-13. Trama PHY de 802.11p. 24
Figura 3-14. Formato WSMP. 24
Figura 3-15. Formato WSA. 24
Figura 3-16. VANET Ad-hoc. 25
Figura 3-17. VANET Celular. 25
Figura 3-18. VANET Híbrida. 26
Figura 3-19. Paquete de ShorckBurst Enhanced. 26
Figura 3-20. Campo de control de paquete. 27
Figura 3-21. PRX usando Multiceiver. 27
Figura 3-22. Tiempo de transmisión vs Tamaño de los datos. 30
Figura 3-23. Eficiencia en codificación (%). 31
Figura 3-24. Potencia consumida por cada protocolo. 32
Figura 3-25. Potencia recibida dependiendo del rango de señal. 33
Figura 3-26. Indicadores de rendimiento. 36
Figura 3-27. Top 10 de MiniPCs en Junio de 2016. 37
Figura 3-28. Arduino Nano v3.1. 38
Figura 3-29. Diagrama de pines de Arduino Nano. 39
Figura 3-30. Topic particionado. 40
Figura 3-31. Procesador de eventos complejos. 41
Figura 4-1. Comparativa de protocolos. 44
Figura 4-2. Dispositivo NRF24L01+ (antena microstrip) 45
Figura 4-3. Comparativa de nodos pasarela. 46
Figura 4-4. Raspberry Pi 3. 46
Figura 5-1. Formato de paquete NRF24L01+. 48
Figura 5-2. Pines de NRF24L01+. 50
Figura 5-3. Cableado de DHT11. 51
Figura 5-4. Cableado sensor FC-37. 51
Figura 5-5. Fichero “types.json”. 52
Figura 5-6. Formato de paquete Raspberry - Kafka. 52
Figura 5-7. Payload de paquete Raspberry-Kafka. 52
Figura 5-8 Mensaje Kafka-Raspberry. 53
Figura 5-9. Fichero “dispositivos.json”. 53
Figura 5-10. Pines físicos Raspberry Pi. 55
Figura 5-11. Pines GPIO de la Raspberry Pi. 55
Figura 5-12. Bot de Telegram. 60
Figura 5-13. Teclado Telegram. 61
Figura 5-14. Escenario final. 63
Figura 5-15. Lectura de temperatura del DHT11. 64
Figura 5-16. Encendido automatizado de led azul. 65
Figura 5-17. Encendido automático de led rojo. 65
Figura 5-18. Sensor de lluvia inactivo. 66
Figura 5-19. Activación de motor emulando apertura de ventana. 66
Figura 5-20. Sensor de lluvia activo. 67
Figura 5-21. Activación del motor emulando cierre de ventana. 67
Figura 6-1. Topología en árbol. 70
xix
1
1 INTRODUCCIÓN
ebido al rápido avance de las tecnologías durante el siglo XXI, la sociedad está caminando hacia un
modelo “siempre conectado”. La aparición de Internet supuso un gran cambio en la vida del ser humano,
desde la comunicación hasta la educación, la ciencia o los negocios. En la mayoría de estos casos, la
principal forma de comunicación es humano a humano [1].
Sin embargo, Internet está evolucionando y cambiando constantemente y se puede considerar que la próxima
evolución de Internet es el “Internet de las Cosas” (IoT, Internet of Things), lo que transformará la actual forma
de comunicación hacia un modelo máquina a máquina (M2M) [2].
Según la recomendación Y.2060 [3] de la ITU-T (Sector de estandarización de la Unión Internacional de
Telecomunicaciones), el IoT puede definirse como “una infraestructura global de la sociedad de la información,
que permite ofrecer servicios avanzados mediante la interconexión de objetos (físicos y virtuales) gracias a la
interoperabilidad de tecnologías de la información y la comunicación (TIC) presentes y futuras”.
Esta definición puede resumirse en que el Internet de las Cosas es una extensión de Internet donde objetos físicos
del mundo real forman parte de este, es decir, están identificados unívocamente, tienen acceso a la red y se
conoce su posición y estado, ofreciendo servicios en Internet y combinando de esta manera el mundo físico y
digital.
1.1. Contexto y evolución del IoT
1.1.1 Evolución del IoT
Los orígenes del IoT tal y como se conoce hoy día se remontan al año 1999 en el Instituto Tecnológico de
Massachusetts (MIT) cuando se fundó el Auto-ID Centre [4]. Su objetivo era investigar acerca del sucesor del
código de barras y como solución se discutió sobre la identificación por radiofrecuencia (RFID), un sistema de
almacenamiento electrónico y recuperación de datos remotos mediante etiquetas. A partir de aquí, se dieron
cuenta del potencial que tendría poder identificar cualquier objeto de forma única y controlarlo asimismo
mediante su conexión a Internet. De esta forma surgió el término “Internet de las Cosas”.
D
La gente sabe el precio de todo, pero no conoce el valor de nada.
Oscar Wilde
Introducción
2
Otras organizaciones, como el Grupo para Soluciones Empresariales para Internet (IBSG) de Cisco, piensan que
el IoT surge simplemente cuando hay más cosas u objetos conectados a la red que personas [5]. Así, se podría
decir que es en algún momento entre 2008 y 2009, con el auge de smartphones y tablets, cuando hay más
dispositivos conectados a Internet que personas. Como se puede apreciar en la Figura 1-1 el número de
dispositivos conectados a Internet en 2010 se estimaba en 12500 millones, mientras que la población mundial
alcanzaba 6800 millones de personas.
Figura 1-1. Momento en el que nace IoT. Fuente: ISBG Cisco
Este crecimiento se debe básicamente a los avances en la tecnología, destacando el abaratamiento de sensores,
procesadores o acceso a Internet; así como el desarrollo de tecnologías como las comunicaciones inalámbricas,
el Big Data o el desarrollo de IPv6 [6].
1.1.2 Características y arquitectura del IoT
Existen una serie de características fundamentales que identifican al Internet of Things y se describen a
continuación [3]:
• Interconectividad: esta es la característica que dota al IoT de todo su potencial, ya que permite la
compatibilidad y el acceso a la infraestructura mundial de la información y la comunicación.
• Servicios relacionados con objetos: IoT proporciona servicios relacionados con objetos dentro de las
restricciones de esos objetos.
• Heterogeneidad: dispositivos basados en diferentes plataformas hardware y redes pueden interactuar
entre sí.
• Cambios dinámicos: tanto el estado de los dispositivos (reposo, activo, conectado, desconectado, …)
como el contexto (ubicación, velocidad, …) o el número de dispositivos pueden variar de forma
dinámica.
• Escalabilidad: el número de dispositivos IoT interconectados va a incrementarse espectacularmente
durante los próximos años, lo que hará necesaria la gestión de datos generados, su interpretación y su
manipulación de forma eficiente.
3
3 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
Por otra parte, el requisito mínimo que debe cumplir cualquier dispositivo en IoT es que disponga de capacidades
de comunicación. Asimismo, existen otros requisitos de alto nivel:
1. Conectividad basada en la identificación: para interconectar distintos objetos estos deben estar
identificados. Además, puede ser necesario manejar identificadores heterogéneos.
2. Compatibilidad: como los sistemas pueden ser heterogéneos, es necesario garantizar la compatibilidad
en muchos casos para el uso de diferentes servicios.
3. Capacidades basadas en la ubicación: en algunos casos las comunicaciones y servicios relacionados con
los objetos dependerá de la información sobre la ubicación de estos y/o de los usuarios.
4. Seguridad: todo objeto conectado presenta amenzas de seguridad. Es esencial mantener requisitos de
seguridad a la hora de integrar varios dispositivos y redes de dispositivos de forma que se mantenga la
integridad, la confidencialidad y la autenticidad de los datos.
5. Protección de la privacidad: algunos objetos recaban información de la salud del usuario, por lo que es
esencial que se dé soporte a la protección de los datos, ya sea durante la transmisión, el almacenamiento
o el procesamiento de estos.
6. Autoconfiguración (plug and play): Los dispositivos IoT deben soportar su configuración automática
En definitiva, a partir de las características y requisitos expuestos, un sistema básico basado en IoT que
implemente diferentes tipos de aplicaciones o servicios debe seguir el siguiente flujo de trabajo [1]:
Figura 1-2. Sistema Básico IoT.
• Detección, identificación y comunicación del objeto: dependiendo del tipo de sensor con el que el objeto
esté equipado, este podrá detectar cambios en temperatura, velocidad, humedad, etc. A partir de una
combinación de sensores se podrán crear distintos servicios inteligentes.
• Procesamiento y actuación: a partir de la información obtenida por el sensor, esta se transmite a través
de la red hacia un dispositivo inteligente o sistema que procesa la información y determina la acción a
realizar.
El sistema o dispositivo inteligente que realiza la acción proporciona servicios inteligentes e incluye además
Introducción
4
mecanismos para facilitar información al administrador sobre el estado o acciones llevadas a cabo. Las
características y requisitos definidos anteriormente se resumen en la arquitectura definida en el IoT.
La Figura 1-3 muestra la arquitectura básica de IoT, dividida en tres capas [7]:
Figura 1-3. Arquitectura básica del IoT.
• Capa de percepción (Perception Layer): este nivel es el responsable de recoger las propiedades físicas
de los objetos (temperatura, humedad, localización…) mediante sensores y convertir la información en
señales digitales para poder transmitirlas por la red. De esta forma, los sensores, la tecnología RFID,
códigos de barras o GPS, entre otras, son las tecnologías claves en esta capa.
• Capa de red (Network Layer): esta capa tiene como función principal enviar los datos recogidos por la
capa de percepción hacia su destino mediante la red a través de 3G, 4G, WiFi, Bluetooth, ZigBee u
otras tecnologías.
• Capa de aplicación (Application Layer): la función de la capa de aplicación es el desarrollo de todo tipo
de aplicaciones en función del objetivo que tenga y de los datos recogidos por la capa de percepción.
Es el nivel más importante en cuanto al papel que juega en el desarrollo del IoT.
Desde un punto de vista técnico la arquitectura expuesta anteriormente describe el IoT. Sin embargo, debido al
gran desarrollo que está teniendo, es necesario considerar también la gestión y el modelo de negocio en esta
arquitectura. Así, se podría considerar que la arquitectura genérica del IoT consta de 5 capas, añadiendo la capa
de Procesamiento y la capa de Negocio al modelo básico de tres capas como se muestra en la Figura 1-4:
Figura 1-4. Arquitectura básica del IoT.
5
5 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
1.1.3 Aplicaciones del IoT
El eje central del IoT y su desarrollo son las aplicaciones [8]. Las capacidades que aportan un procesador, una
memoria y otros recursos electrónicos, hacen que el Internet de las Cosas tenga aplicaciones en casi todos los
campos que se puedan imaginar. Algunas de las aplicaciones con más interés son la domótica (smart home), el
transporte inteligente (smart transport), aplicaciones industriales, las ciudades inteligentes (smart city) o
aplicaciones medicinales (smart health).
Figura 1-5. Escenario genérico del IoT.
En cualquier caso, las aplicaciones IoT deben tener alguna de las siguientes capacidades [9]:
a) Localización: las aplicaciones IoT deben recoger en muchos casos información sobre la localización de
los dispositivos IoT. La posición geográfica se puede obtener de forma absoluta o relativa a partir del
GPS, RFID, CID, etc. y aporta información esencial para las siguientes aplicaciones:
• Seguimiento de activos móviles: mediante aplicaciones de este tipo es posible monitorizar el
estado y seguimiento de productos y mercancías, muy útil en aplicaciones industriales.
• Gestión de flota de vehículos: a partir del conocimiento de la localización en tiempo real de
una flota de vehículos es posible desarrollar aplicaciones para gestionar y organizar los
vehículos y conductores en un negocio de este tipo.
• Sistema de información de tráfico: a partir del seguimiento de un gran número de vehículos se
puede obtener información del tráfico en tiempo real en una aplicación, de forma que el usuario
pueda conocer la ruta más eficiente para alcanzar su destino.
b) Registro ambiental: algunos sistemas IoT pueden registrar información de procesos físicos o químicos
medioambientales, tales como temperatura, humedad, intensidad de la luz, polución, etc., mediante los
sensores de los objetos. Así, se pueden implementar algunas soluciones como estas:
Introducción
6
• Prevención y detección de desastres medioambientales: utilizando un gran número de sensores
que midan parámetros ambientales es posible crear sistemas de monitorización para prevenir
desastres medioambientales como erupciones volcánicas.
• Monitorización médica de forma remota: mediante dispositivos IoT utilizados en enfermos es
sería posible proporcionar indicaciones médicas de forma remota.
c) Control remoto: las aplicaciones IoT pueden controlar los terminales remotamente, de forma que en
función de la información que estos recolectan se puedan ejecutar comandos desde la aplicación.
Algunas aplicaciones que hagan uso de esta característica pueden ser:
• Control domótico: a través de las aplicaciones IoT se pueden controlar electrodomésticos y
objetos del hogar de forma remota.
• Recuperación de desastres: los usuarios pueden iniciar remotamente procedimientos para
recuperarse de desastres a partir de dispositivos IoT que estén preparados para ello, de forma
que se minimicen pérdidas.
d) Ad Hoc Networking: en muchos casos es necesario la rápida auto organización de las capacidades de
red. Por ejemplo, en una red de vehículos se puede organizar rápidamente la red entre estos y/o las
infraestructuras de la carretera para poder transmitir los datos recogidos en cualquier momento.
1.2. Objetivo
Con este proyecto se pretende diseñar, implementar y analizar una red de sensores. Esto permitirá un aprendizaje
a todos los niveles de lo que suponen los sistemas embebidos en el mundo actual. Obviamente, este estudio se
realiza sobre un escenario reducido y de bajo coste. El estudio implicará el análisis de dispositivos, protocolos y
tecnologías que actualmente se usan en las redes de sensores.
Se barajarán las opciones de usar dispositivos como Raspberry Pi, C.H.I.P. y Arduino. Entre los protocolos a
usar, obviando los basados en HTTP, se valorará el uso de ZigBee, Bluetooth LE, 802.11p y ShockBurst. Con
respecto a las tecnologías, se usarán Apache Kafka, Telegram y AWS.
Por último, se realizará un escenario para presentar algunos casos de uso y demostrar la coherencia de todas las
tecnologías y software a pesar de la heterogeneidad de éstos.
7
2 ARQUITECTURA GENERAL
a topología es una parte importante del diseño de las redes de sensores. Ésta puede marcar la diferencia
entre una red eficiente (ancho de banda, potencia, tiempo, etc.) o no. La topología típica en este tipo de
redes es la denominada Ad-Hoc en la cual, cada nodo puede comunicarse inalámbricamente con los demás
nodos de la red, y estos con él (punto a multipunto y viceversa). En este caso, este tipo de topología no es válida
para este proyecto, ya que se pretende recolectar diferentes típos de métricas. Es por esto que se necesita un nodo
central por el que pase todo el tráfico y así poder recoger los datos de los sensores y realizar históricos, gráficas,
indicadores de rendimiento, etc.
En concreto, el tipo de red que se pretende realizar es una red de sensores inalámbricos (WSN). Una red WSN es
una red inalámbrica que consiste en dispositivos autónomos distribuidos utilizando sensores para monitorizar
condiciones físicas o ambientales. Un sistema WSN [10] incorpora una pasarela que provee conectividad
inalámbrica hacía internet y viceversa (ver Figura 2-1). El protocolo inalámbrico que se seleccione depende en
los requerimientos de la aplicación. Algunos de los estándares disponibles incluyen radios de 2.4 GHz basados
en los estándares IEEE 802.15.4 o IEEE 802.11 (Wi-Fi) o radios propietarios, los cuales son de 900 Mhz.
Figura 2-1. Pasarela y nodos distribuidos de una WSN.
Los nodos WSN están típicamente organizados en uno de los tres tipos de topologías de red que se muestran en
la Figura 2-2. En la topología en estrella, cada nodo se conecta directamente a la pasarela. En la de tipo árbol,
cada nodo se conecta a un nodo de mayor jerarquía en el árbol y después a la pasarela, los datos son enrutados
desde el nodo de menor jerarquía en el árbol hasta la pasarela. Finalmente, para ofrecer mayor confiabilidad, las
redes tipo malla, donde los nodos se pueden conectar a múltiples nodos en el sistema y enviar los datos por el
camino disponible de mayor confiabilidad. Finalmente, los datos han de pasar igualmente por la pasarela para
L
Es preciso conocer al máximo los problemas de nuestro tiempo,
pero también las necesidades esenciales del hombre, que no han
cambiado, pues el hombre es nuestra principal unidad de medida.
José Antonio Coderch
Arquitectura General
8
llegar a Internet.
Figura 2-2. Topologías típicas de una WSN.
Nótese que la topología en estrella es la que más se adecúa al tipo de red que se quiere realizar en este proyecto,
ya que todos los datos de los nodos pasarán obligatoriamente a través de la pasarela.
Bien es cierto, que, si se quiere realizar alguna de las dos topologías restantes, se podrían implementar sobre la
marcha modificando las direcciones de reenvío de los nodos.
2.1 Arquitectura general
La arquitectura que se plantea consta de un conjunto de sensores que se conectan a uno o varios
microcontroladores. Estos microcontroladores tienen unos dispositivos conectados a ellos que permiten la
comunicación en ambos sentidos con un nodo pasarela, el cual también tiene un dispositivo inalámbrico
conectado a él. Una vez que el nodo pasarela obtiene los datos de los sensores se envían a la nube para que se
pueda disponer de ellos. La idea es que además de obtener datos de los sensores también se pueda actuar sobre
otros dispositivos conectados a los microcontroladores. El protocolo inalámbrico de comunicación en la red
local, así como los distintos dispositivos (microcontroladores y nodo pasarela) y tecnologías que se usarán, serán
analizados y evaluados para su posterior elección.
En el siguiente diagrama, se representa la topología general. Se pretende crear un escenario típico de Smart
Home, en el cuál se encuentran sensores y actuadores. Se desea recoger datos de los sensores para poder actuar
consecuentemente con los actuadores. Se podrá actuar tanto manualmente, como automáticamente. Se hara una
explicación paso a paso por colores:
Naranja - Proceso en el que se recogen los datos de los sensores para almacenarlos en un datastore (servicio
de almacenamiento) en la nube:
1. Envío de datos por parte de los sensores de forma inalámbrica al nodo pasarela.
2. Recepción de los datos de los sensores por parte del nodo pasarela.
3. Escritura por parte del nodo pasarela en el sistema de colas de la nube de los datos de los sensores.
4. Envío de eventos al correlador de eventos y al servicio encargado de escribir los datos en el datastore.
5. Escritura de los datos en datastore vía HTTPS.
Verde - Proceso por el cuál se actúa automáticamente sobre los actuadores mediante la recolección,
procesamiento y análisis de los datos ofrecidos por los sensores:
1. Escritura del correlador en la cola de mensajes.
2. Lectura por parte del nodo pasarela de la cola de mensajes y envío de los mensajes inalámbricamente a
9 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
los dispositivos
3. Actuación sobre sensores.
Amarillo – Proceso en el que se actúa de manera manual sobre los actuadores mediante una aplicación
móvil:
1. Envío de actuación sobre los sensores al servicio vía HTTPS
2. Escritura en la cola de mensajes de la orden a ejecutar.
3. Lectura del nodo pasarela.
4. Comunicación inalámbrica entre sensores y nodo pasarela.
5. Actuación sobre sensores.
Azul – Proceso en el que se recolectan datos de los sensores de manera manual a través de una aplicación
móvil:
1. Envío de petición de datos por parte de la aplicación móvil (vía HTTPS) al servicio encargado de
comunicarse entre ésta y la cola de mensajes.
2. Envío de la petición de datos al datastore por parte del servicio mencionado en el paso anteior (via
HTTPS).
3. Respuesta del datastore con los datos requeridos (vía HTTPS).
4. Respuesta del servicio antes mencionado a la aplicación móvil con los datos solicitados (via HTTPS).
Arquitectura General
10
Figura 2-3. Arquitectura general.
11 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
2.1.1 Caso de uso genérico
Atendiendo a la arquitectura anterior (figura 2-3) se presenta un caso de uso en el cual se presenta la secuencia
de operaciones a realizar en una situación hipotética. Se presenta un caso donde se quiere medir la temperatura
de una habitación y actuar en consecuencia a los valores de ésta. Hay dos modos de funcionamiento:
Manual
En primer lugar, desde la aplicación móvil, se consulta la temperatura que uno de los sensores está midiendo.
El valor obtenido por el sensor se transmite al microcontrolador. Desde el microcontrolador se envía el valor
de temperatura hasta el nodo pasarela mediante las antenas. Una vez llega al nodo pasarela, éste envía el dato
a la cola de mensajes, la cual lo sitúa en el servicio de almacenamiento. Desde el servicio de almacenamiento,
la aplicación lee los datos de temperatura obtenidos y se los presenta al usuario en la aplicación móvil.
Posteriormente, si se quiere modificar la temperatura de la habitación, desde la aplicación móvil se envía una
orden hasta uno de los actuadores (aire acondicionado). Esta orden se envía a la cola de mensajes, que es
consumida por el nodo pasarela. El nodo pasarela envía la orden al microcontrolador para que encienda el
aire acondicionado en consecuencia a si se quiere aumentar o disminuir la temperatura de la habitación. En la
siguiente figura se puede observar la secuencia de operaciones a realizar.
Figura 2-4. Diagrama de secuencia en modo manual.
Arquitectura General
12
Automático
El usuario crea una regla en el correlador de eventos diciendo que cuando la temperatura supere/no llegue a
cierto umbral se actúe sobre el aire acondicionado. De este modo, cuando le llegue el valor medido desde los
sensores a la cola de mensajes, el correlador lo evaluará y enviará una respuesta en consecuencia con la regla
que se le ha definido. Esta respuesta es enviada a la cola de mensajes que finalmente le llevará la orden al
microcontrolador a través del nodo pasarela, y, por tanto, a actuar en el aire acondicionado. En la siguiente
figura se puede observar la secuencia de operaciones a realizar.
Figura 2-5. Diagrama de secuencia en modo automático.
13
3 ALTERNATIVAS
n este apartado se presentan y valoran varias alternativas actuales que pueden tomar parte en el escenario
que se plantea. En primer lugar, se analizarán las diferentes tecnologías inlámbricas, cuyo fin es el de
comunicar los sensores con el nodo pasarela sin necesidad de cables. En segundo lugar, se analizarán los
diferentes dispositivos que se podrán usar cómo nodo pasarela. Por último, se justificará el uso de unos
microcontroladores y software adecuados.
3.1 Tecnologías inalámbricas
En esta sección se hará un analisis exaustivo de los protocolos inalámbricos que suelen aparecer en los escenarios
de redes de sensores [11] [12]. Se tendrán en cuenta aspectos relacionados con los canales de radio, el tamaño
de la red, la seguridad, el tiempo de trnasmisión, la eficiencia en la codificación de los datos, el consumo de
potencia, y el coste. Esta sub-sección cobra vital importancia en el diseño y despliegue de una red de sensores,
ya que se introducen parámetros como el consumo de potencia y de ancho de banda. También cobra interés el
coste de los dispositivos, puesto que presupuesto del proyecto escala linealmente con el número de dispositivos
que se introduzcan en él.
3.1.1 Bluetooth Low Energy - IEEE 802.15.1
Bluetooth Low Energy (BLE) [13] es una tecnología inalámbrica desarrollada por Bluettoh Special Interest
Group (SIG) para las comunicaciones de corto alcance. En contraste con los tipos de Bluetooth anteriores, BLE
ha sido diseñado como una solución de bajo consumo para el control y monitorización de aplicaciones. BLE es
una característica distintiva de la especificación Bluetooth 4.0.
ZigBee proporciona una arquitectura de red mallada, ideal para redes complejas y multi-nodos, y Wi-Fi
proporciona una velocidad de transmisión de datos alta. La ventaja de BLE con respecto a estas dos soluciones
inalámbricas de baja potenciason el bajo coste, la simplicidadad y el bajo consumo de potencia en aplicaciones
que transmiten pequeñas cantidades de datos. Esto hace que BLE sea aplicable a diferentes casos de uso tales
como sanidad, electrodomésticos, energía inteligente y seguridad.
E
La acción es la clave fundamental de cualquier éxito.
Pablo Picasso
Alternativas
14
A continuación, se presentarán las características de ésta tecnología:
• Pila de protocolos
La pila de protocolos de BLE está compuesta de dos partes: El Controlador y el Host. El Controlador
está compuesto de la capa física y la capa de enlace, y normalmente se implementa en un pequeño
System-on-Chip (SOC) con comunicación vía radio integrada. El Host corre en un procesador de
aplicación e incluye funcionalidades de una capa superior a la anterior tales como, por ejemplo, Logical
Link Control and Adaptation Protocol (L2CAP), Attribute Protocol (ATT), Generic Attribute Profile
(GATT), Security Manager Protocol (SMP), y Generic Access Profile (GAP). La comunicación entre
el Host y el Controlador se realiza mediante la interfaz Host Controller Interface (HCI). Finalmente,
los perfiles que no son del núcleo (es decir, las funcionalidades de la capa de aplicación que no están
definidas en la especificación de Bluetooth) pueden ser usadas en la capa superior de la parte de Host.
En la Fig. 3-1 se muestra la pila de protocolos de BLE.
Figura 3-1. Torre de protocolos de BLE.
A continuación, se describirán cada una de las capas de la figura anterior:
▪ Capa Física- Pysical Layer: BLE opera en la banda Médico-Científica Industrial (ISM) de
2.4 GHz y define cuarenta canales de Radio Frecuencia (RF) con 2 MHz de espaciado de
canal. Hay dos tipos de canales de radiofrecuencia:
o Canales de anuncio: Usados para el descubrimiento de dispositivos, establecimiento
de conexión y transmisiones en difusión.
o Canales de datos: Usados para la comunicación bidireccional entre dispositivos.
Se definen tres canales como canales de anuncio. Estos canales tienen frecuencias centrales
(asignadas a conciencia) que minimizan el solapamiento con los canales 1, 6 y 11 de IEEE
802.11, los cuales se usan comúnmente en varios países.
Un mecanismo de salto en frecuencia adaptativo se usa en los canales de datos con el fin de
afrontar los problemas de interferencias, desvanecimientos y multi-trayecto. Este mecanismo
selecciona uno de los 37 canales de datos disponibles para la comunicación durante un intervalo
de tiempo dado.
Todos los canales físicos usan una modulación GFSK (Gaussian Frequency Shift Keying), que
es fácil de implementar. El índice de la modulación se sitúa entre 0.45 y 0.55, lo que permite
reducir los picos de consumo de potencia. La velocidad de la capa física de datos es de 1Mbps.
15 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
▪ Capa de enlace - Link Layer: En BLE, cuando un dispositivo solo necesita hacer una difusión
de los datos, transmite los datos en paquetes de anuncio a través de los canales de anuncio. A
cualquier dispositivo que transmita paquetes de anuncio se le llama un anunciador. La
transmisión de los paquetes a través de los canales de anuncio tiene lugar en intervalos de
tiempo llamados eventos de anuncio. Dentro de un mismo evento de anuncio, el anunciador
usa secuencialmente cada canal de anuncios para la transmisión de paquetes. Los dispositivos
cuyo fin único es el de recibir datos a través de los canales de anuncio, son llamados
buscadores/analizadores (scanners).
La comunicación bidireccional entre dos dispositivos precisa de reciprocidad por ambas partes.
La creación de una conexión entre dos dispositivos es un procedimiento asíncrono a través del
cual, un anunciador anuncia a través del canal de anuncios que se trata de un dispositivo
conectable, mientras que el otro dispositivo (conocido como iniciador) escucha esos anuncios.
Cuando un iniciador encuentra a un anunciador, puede transmitir un mensaje de petición de
conexión (Connection Request) al anunciador, el cual crea una conexión punto a punto entre
los dos dispositivos. Ambos dispositivos se pueden comunicar usando los canales de datos
físicos. Los paquetes de una conexión se identifican mediante un código de acceso de 32 bits
generado aleatoriamente.
BLE define dos roles de dispositivo en la capa de enlace para una conexión creada: el maestro
(actúa como iniciador) y el esclavo (actúa como anunciador). Un maestro puede gestionar
múltiples conexiones simultaneas con diferentes esclavos, donde cada esclavo puede estar
conectado solamente a un master. A una red formada por un maestro y sus esclavos se le llama
piconet, y tiene una topología en estrella.
En una topología BLE (Figura 3-2), cada esclavo se comunica con el maestro en canales físicos
separados. A diferencia de una piconet de bluetooth clásico (Figura 3-3), donde todos los
esclavos escuchan las conexiones entrantes y por tanto necesitan estar en standby
constantemente, un esclavo BLE es el que “invita” a que le conecten (se anuncia) permitiendo
así tener un control del consumo de potencia. Un maestro BLE, que se supone que tiene menos
restricciones de potencia, escuchará anuncios y establecerá conexiones.
Figura 3-2. Topología bus-estrella.
Alternativas
16
Figura 3-3. Scatternet (conjunto de piconet).
Con el fin de ahorrar energía, los esclavos están en modo sleep por defecto y se levantan
periódicamente para escuchar posibles paquetes que vengan del maestro. El maestro determina
los instantes en los que los esclavos tienen que escuchar y, por tanto, coordina el acceso al
medio usando un esquema TDM (Time Division Multiple Access). El maestro también
proporciona al esclavo la información necesaria para el algoritmo por salto de frecuencia
(incluidos el mapa de canales de datos a usar) y para la supervisión de la conexión. Los
parámetros necesarios para la gestión de una conexión son transmitidos en el mensaje de
petición de conexión (Connection Request) y pueden ser actualizados durante la conexión.
▪ L2CAP: El principal objetivo de L2CAP es multiplexar los datos de las 3 capas superiores
(ATT, SMP y LLC, por encima de la conexión de la capa de enlace). Los datos de estos
servicios son manejados por L2CAP. Las capacidades de segmentación y reensamblado no se
utilizan, ya que los protocolos de capa superior proporcionan unidades de datos que se ajustan
al tamaño de carga útil L2CAP máximo, que es igual a 23 bytes en BLE.
▪ ATT: Define la comunicación entre dos dispositivos, que hacen el papel de servidor y cliente
respectivamente, por encima de un canal L2CAP dedicado. El servidor tiene un conjunto de
atributos. Un atributo es una estructura de datos que guarda la información gestionada por el
GATT, el protocolo que opera por encima de ATT. El papel de cliente o de servidor lo
determina el GATT, y es independiente de los roles de esclavo o maestro.
El cliente puede acceder a los atributos del servidor mediante el envío de peticiones, las cuales
activan el envío de respuestas por parte del servidor. Para una mejor eficiencia, un servidor
puede enviar a un cliente incluso dos tipos de mensajes no solicitados que contengan atributos:
(i) notificaciones, las cuales no se confirman; e (ii) indicaciones, las cuales requieren que el
cliente mande una confirmación. Un cliente también puede mandar comandos al servidor con
el fin de establecer valores a los atributos. Las peticiones/respuestas y las
indicaciones/notificaciones siguen un esquema de parada y espera (stop-and-wait).
▪ GATT: Este protocolo define un framework que usa ATT para el descubrimiento de servicios
y el intercambio de características de un dispositivo a otro. Una característica es un conjunto
de datos los cuales incluyen un valor y propiedades. Los datos relacionados con los servicios y
las características se guardan en atributos. Por ejemplo, un servidor que ejecuta un servicio de
"sensor de temperatura" puede tener en cuenta una característica de "temperatura" que utiliza
17 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
un atributo para describir el sensor, otro atributo para almacenar valores de medición de
temperatura y otro atributo para especificar las unidades de medida.
▪ GAP y Perfiles de Aplicación: En el nivel más alto del núcleo de la pila BLE, GAP especifica
los roles, los modos y los procedimientos de los dispositivos para el descubrimiento de
dispositivos y servicios, la gestión del establecimiento de la conexión y la seguridad. GAP
define cuatro roles con requerimientos específicos en el controlador subyacente: Locutor,
Observador, Periférico y Central. Un dispositivo en el papel de Locutor, solo envía datos
(mediante los canales de anuncio) y no soporta conexiones con otros dispositivos. El rol de
Observadores es complementario al de Locutor, es decir, tiene como propósito recibir los datos
transmitidos por el Locutor. El rol de Central está diseñado para los dispositivos que se
encargan de iniciar y gestionar múltiples conexiones, mientras que el rol de Periférico, está
diseñado para dispositivos simples que hagan uso de una conexión simple con un dispositivo
con rol de Central. Por tanto, los roles Central y Periférico precisan que el dispositivo
controlador soporte los roles de maestro y esclavo respectivamente. Un dispositivo puede
soportar varios roles, pero solo un rol puede ser adoptado al mismo tiempo.
Finalmente, dado que ciertos tipos de aplicaciones pueden beneficiarse de la reutilización de
funcionalidades comunes, se pueden construir perfiles adicionales en la parte superior del GAP.
Bluetooth sigue una jerarquía de perfiles, por lo que se puede definir un nuevo perfil que
incluya todos los requisitos de un perfil existente. Un perfil de nivel más alto que especifica
cómo las aplicaciones pueden interoperar se denomina perfil de aplicación. Los perfiles de
aplicación, también especificados por el Bluetooth SIG, favorecen la interoperabilidad entre
dispositivos de diferentes fabricantes.
• Formato de trama
La Figura 3-4 muestra el formato de trama de BLE. Está compuesto por: Preambulo (1 byte), Dirección
de acceso (4 bytes), Cabecera de PDU (2 bytes), Cabecera L2CAP (4 bytes), Codigo de opciones de
ATT (1 byte), Parametros/Payload (carga útil) (hasta 22 bytes), Comprobación de Integridad de
Mensaje (4 bytes) y Código de Redundancia Cíclica (3 bytes).
Figura 3-4. Formato de trama BLE.
La figura anterior es meramente orientativa. Su fin es el de mostrar cómo actúan los campos de la pila
en el formato del paquete. El tamaño real de los paquetes BLE va desde los 8 a los 47 bytes [14], cuyos
campos se encuentran desglosados en la siguiente figura.
Alternativas
18
Figura 3-5. Paquete de datos BLE.
La figura anterior muestra un paquete de datos BLE estándar (nótese que el campo MIC no aparece en
esta figura). El preámbulo es un valor de un byte que se usa para la sincronización con el receptor. Para
paquetes de disfusión siempre valdrá 0xAA. La dirección de acceso (Access Address) también es fija
para paquetes de difusión (0x8E89BED6). El Packet Payload consiste en una cabecera y un payload
(carga útil). La cabecera describe el tipo de paquete y el tipo de PDU (PDU Type) define el propósito
del dispositivo. Para difusiones, hay tres tipos diferentes de PDU, mostrados en la Tabla 3-1.
Tipo de PDU Nombre de Paquete Descripción
0000 ADV_IND Modo difusión. Sólo transmite
información.
0010 ADV_NONCONN_IND Modo periférico. Transmite y
además puede recibir.
0110 ADV_SCAN_IND Añade información de las
respuestas de escaneos al modo
periférico anterior.
Tabla 3–1. Tipos de PDU de anuncio para difusiones
El bit TxAdd indica si la dirección del anunciador (contenida en el Payload) es pública (TxAdd =0) o
aleatoria (TxAdd=1). RxAdd está reservado para otros tipos de paquetes, los cuales no aplican a la
difusión.
El Payload del paquete incluye la dirección de anuncio junto con los datos anunciados definidos por el
usuario, como se muestra en la Figura 3-6.
19 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
Figura 3-6. Paquete de difusión BLE.
3.1.2 ZigBee - IEEE 802.15.4
ZigBee - IEEE 802.15.4 [15], define las especificaciones para WPAN de tasa baja Low Rate-WPAN que
soportan dispositivos simples que consumen una potencia mínima y normalmente operan en un radio de 10
metros (Personal Operating Space-POS). ZigBee proporciona una red mallada confiable, auto organizada,
multi-salto y con una gran duración de la batería en los dispositivos.
Hay dos tipos diferentes de dispositivos que pueden pariticipar en una red LR-WPAN: Un dispositivo de función
completa - Full Function Device (FFD) y un dispositivo de función reducida – Reduced Function Device (RFD).
El FFD puede operar en tres modos: como un coordinador PAN, un coordinador o un dispositivo. Un FFD
puede hablar con los RFD o con otros FFD, peron un RFD sólo puede hablar con un FFD. Un RFD se suele
utilizar para aplicaciones muy simples, como un interruptor de una luz o un sensor de infrarrojos pasivo. Un
RFD no necesita enviar grandes cantidades de datos y sólo puede asociarse únicamente con un FFD a la vez.
Por tanto, el RFD puede ser implementado usando recursos mínimos.
El FFD que se active primero puede establecer su propia red y llegar a ser el coordinador PAN. Todas las
redes en estrella operan independientes al resto de redes en estrella que estén funcionando en ese momento.
Esto se consigue mediante la elección de un identificador PAN, el cual no esté siendo usado en ese momento
por cualquier otra red que pueda actuar en el radio de influencia. Una vez elegido el identificador PAN, el
coordinador PAN puede permitir a otros dispositivos unirse a su red.
Un RFD puede conectarse a un árbol de clusters como un nodo hoja en cada rama, ya que éste sólo puede
asociarse con un FFD a la vez. Cualquiera de los FFDs puede actuar como un coordinador y proporcionar
servicios de sincronización a otros dispositivos u otros coordinadores. Sólo uno de esos coordinadores puede ser
el coordinador general de la PAN, el cual puede tener más recursos computacionales que cualquier otro
dispositivo en la PAN.
A continuación, se presenta el formato de trama de 802.15.4 (cabe destacar que este estándar se centra en las
dos capas inferiores de la pila ZigBee como se muestra en la figura 3-7):
Figura 3-7. Formato de 802.15.4 PHY.
Alternativas
20
• Preámbulo (32 bits): Sincronización
• Comienzo del delimitador del paquete (8 bits)
• Cabecera PHY (8 bits): Indíca la longitud de la PSDU
• PSDU (0 a 1016 bits): Campo de datos
A continuación, se presenta la pila de protocolos de ZigBee:
Figura 3-8. Pila de protocolos de ZigBee.
Por último, se muestran las diferentes topolgías compatibles con ZigBee
Figura 3-9. Topologías de ZigBee.
21 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
3.1.3 Wi-Fi - IEEE 802.11p-WAVE
IEEE 802.11p es un estándar que se sitúa dentro de las llamadas tecnologías Dedicated Short-Range
Communications (DSRC). Su propósito es crear un estándar WLAN para redes vehiculares. DSRC usa la
misma capa física que 802.11a e introduce cambios en parámetros como la tolerancia a la frecuencia del reloj
de símbolos, tolerancia a la frecuencia de transmisión, temperaturas de operacíon, etc.
Utiliza canales de 10 MHz (la mitad que en 802.11a), por tanto, son posibles tasas de transmisión de 3 a 27
Mbps. 802.11p usa la banda de 5,850-5,925 Ghz (ITS-RS, Intelligent Transportation Systems Radio Service)
que se ha reservado en EEUU por la FCC para aplicaciones DSRC. También se han reservado en Europa 30
Mhz en la banda de 5.9 Ghz para este tipo de aplicaciones. Las frecuencias elegidas aportan ciertas ventajas a
las señales (menor desvanecimiento de señal y robustez frente a multi-trayectos) con respecto a otras.
IEEE 802.11p tiene una gran importancia dentro de la familia de estándares IEEE 1609 Family of Standards for
Wireless Access Vehicular Environments (WAVE). El modo WAVE define la operación de dispositivos
basados en 802.11 en entornos donde las propiedades de la capa física cambian rápidamente y donde se requieren
intercambios de comunicación con duraciones cortas. Este estándar define un conjunto mínimo de
especificaciones que aseguran la interoperabilidad entre los dispositivos inalámbricos en entornos de cambios
impredecibles y en situaciones donde la entrega de mensajes debe completarse en tiempos muy cortos con
respecto a 802.11.
A continuación, se presentarán las características de ésta tecnología:
• Pila de protocolos
La pila de protocolos IEEE 1609 está pensada para WAVE (aunque también tiene soporte para TCP/IP)
e incluye su propio protocolo de nivel de red y transporte, denominado WAVE short message protocol
(WSMP). Esta pila soporta comunicaciones de vehículo a vehículo (V2V) y comunicaciones vehículos-
infraestructuras (V2I). La pila consiste en los protocolos IEEE 1609.1, IEEE 1609.2, IEEE 1609.3 y
IEEE 1609.4, los cuales quedan recogidos en la siguiente figura.
Figura 3-10. Pila de protocolos de WAVE..
La capa MAC de 802.11p usa el mecanismo EDCA (Enhanced Distributed Channel Access) derivado
de 802.11e. Esto permite un acceso priorizado al canal gracias al uso de colas con diferentes espacios
de arbitraje entre tramas (AIFS). La cola con la mayor prioridad tendrá que esperar el menor tiempo
(menor AIFS) antes de que su transmisión pueda comenzar. Gana la batalla la estación con el tráfico de
mayor prioridad.
En un sistema IEEE 1609 hay dos tipos de dispositivos: unidades de a bordo (OBU, On-Board Units)
y unidades distribuidas a lo largo de la carretera (RSU, RoadSide Units), sin que sea necesario ningún
tipo de autenticación o procedimiento de asociación para unirse a la red.
Alternativas
22
Dentro del estandar IEEE 1609, se encuentran diferentes sub-estándares:
• IEEE 1609.1 gestiona los recursos situados en la capa de aplicación. Se encarga de multiplexar
las comunicaciones entre un transmisor y múltiples receptores. El caso de uso estándar se basa
en la proporción de un servicio a un OBU por parte de un RSU.
• IEEE 1609.3 implementa el protocolo WSMP (Figura 3-14), el cual actúa a nivel de capa 3 y
4 (red y transporte) dando servicios a la capa de aplicación, como pueden ser el de determinar
características del canal físico (i.e. potencia de transmisión).
• IEEE 1609.2 añade mecanismos de seguridad.
• Una estación compatible con WAVE debe soportar un canal de control (CCH) y múltiples
canales de servicio (SCH) tal como se define en IEEE 1609.4 (Figura 3-11).
Figura 3-11. Operación Multicanal de WAVE.
La manera en que dichos canales se usan es decidida por 802.11p. Un dispositivo escucha en el canal
CCH hasta que un anuncio de servicio (WSA, WAVE Service Advertisement, figura 3-13) se recibe.
Este WSA contiene información sobre un servicio en uno de los SCHs. El CCH está orientado a la
transmisión de mensajes cortos y no permite tráfico IP.
• Formato de trama [16]
802.11p regula las capas inferiores de WAVE. 802.11p proviene del estándar 802.11, sólo que tiene
ciertas modificaciones para su uso en entornos vehiculares (por ejemplo, disminuir el ancho de banda a
la mitad). La siguiente figura muestra la Unidad de Datos de Protocolo (Protocol Packet Data Unit-
PPDU), la cual está compuesta de un preámbulo, un campo de señal y un payload (carga útil).
23 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
Figura 3-12. Estructura de trama PHY IEEE 802.11p.
A continuación, se desglosan los campos de la trama:
• Preámbulo: el campo preámbulo marca el comienzo de la trama física. Se suele usar para
seleccionar la antena apropiada y corregir la frecuencia y la compensación de tiempo. Gracias
a este campo se puede entrenar al oscilador controlado por tensión (VCO) del receptor con la
señal de reloj que le va llegando para así tener una sincronización lo más exacta posible con el
emisor y, por tanto, poder conseguir un muestreo y demodulación perfectos [1]. También se
obtiene el estado de la información del canal (CSI), los símbolos OFDM de entrenamiento o
los símbolos pilotos que forman parte de cada símbolo OFDM utilizado. Los pilotos tienen el
fin de estimar el canal y corregir los errores de transmisión.
En concreto, el campo preámbulo está formado por 12 símbolos de entrenamiento, los cuales
son añadidos para proporcionar una descripción del comportamiento de la frecuencia del canal
y la sincronización temporal de la recepción. Consiste en diez Short Training Symbol (STS) y
dos Long Training Symbols (LTS).
Siete de los 10 STS símbolos cortos de OFDM son responsables de la detección de señal, del
control automático de ganancia y la selección de diversidad. También, permiten la estimación
de la frecuencia de las sub-portadoras y la estimación del canal. STS está compuesto de 12 sub-
portadoras. Los otros 3 STS son responsables de la sincronización temporal y la compensación
frecuencial.
Los dos LTS se usan para la estimación de canal y para que el receptor tenga una frecuencia
exacta. LTS está compuesto de 53 sub-portadoras incluyendo un valor de continua (DC) de
cero. El receptor las usa para la sintonización exacta del canal.
• Campo de Señal (SIG): Este campo se usa para especificar la velocidad y la longitud de la
información. El campo SIG consta de 24 bits divididos en 5 sub-campos, Rate, Reserved,
Length, Parity, y Tail. El campo Rate consta de 4 bits los cuales contienen la información sobre
el tipo de modulación y la relación de codificación que se usa en el resto del paquete. El campo
Length indica el número de octetos en la PSDU (del payload). Los últimos 6 bits en el campo
Señal son la cola (Tail) de la trama, la cual está puesta a cero. Estos ceros se usan para
sincronizar el decodificador en el receptor, y también se usa para devolver al codificador
convolucional al estado inicial (zero state).
• Campo de datos (payload): Este campo es el encargado de llevar los datos en sí (dentro del
campo PSDU). La cola tiene la misma función que en campo anterior, y el campo servicio
indica el tipo de servicio usado.
En la siguiente figura, se puede observar la trama mas detalladamente.
Alternativas
24
Figura 3-13. Trama PHY de 802.11p.
Los tiempos que se muestran en la parte superior de la figura son mayores que en 802.11a, algo normal,
puesto que se han modificado parámetros que afectan a este tipo de cosas.
Para completar WAVE, por encima de 802.11p se sitúa el estándar del IEEE 1609. Puesto que WAVE
no es el motivo de estudio en esta sección, se adjuntan unas figuras orientativas de cómo serían los
paquetes completos.
Figura 3-14. Formato WSMP.
Figura 3-15. Formato WSA.
25 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
• Arquitectura [17]
Realmente, al ser este un protocolo de nivel físico, se pueden plantear diversos tipos de arquitectura
siempre y cuando se tenga a este protocolo en la base de la pila. No obstante, puesto que es un protocolo
diseñado para las redes vehiculares, la arquitectura a seguir es la que usan las VANETs (Vehicular Ad-
hoc Network). Están clasificada en 3 grupos:
• Redes Ad-hoc puras: Las redes Ad-hoc puras se usan en situaciones de emergencia
donde no hay una infraestructura existente. Los nodos se ayudan entre sí pasándose
información y creando conexiones. Cada nodo actúa como un router. En los entornos
VANET, la comunicación entre vehículos (Vehicle-to-Vehicle-V2V) es una red Ad-hoc
pura porque no se necesita una infraestructura para la comunicación entre vehículos.
Las redes Ad-hoc son redes que se organizan ellas misma y que no necesitan de
infraestructura, sin embargo, su rango es limitado.
Figura 3-16. VANET Ad-hoc.
• Redes Celulares/WLAN puras: Estas redes son puramente celulares y los puntos de
acceso están conectados con internet y recopilan información para analizarla. Este
sistema se usa en la comunicación vehículo-infraestructura (Vehicle-to-Infrastructure-
V2I) para proporcionar información. Las redes vehiculares basadas en redes
inalámbricas o celulares se usan para obtener información de aparcamiento,
navegación web y entretenimiento. Los sistemas celulares siguen sufriendo el
problema del despliegue de una infraestructura fija. LAN y DSRC son las tecnologías
más consideradas en las comunicaciones V2V y V2I.
Figura 3-17. VANET Celular.
Alternativas
26
• Redes híbridas: La combinación de las redes celulares y las Ad-hoc dan como resultado
las redes híbridas y, por tanto, también su arquitectura es una combinación de las dos
arquitecturas anteriores, combinando así sus características. Esta red usa a los
vehículos que cuentan con las características WLAN y celular como pasarelas. A
través de una red multi-salto, los vehículos que no tengan la característica WLAN,
podrán comunicarse con otros. La comunicación de corto rango, auto-organización y
auto-gestión, y bajo ancho de banda son características que diferencian a las VANETs
de otro tipo de redes Ad-hoc.
Figura 3-18. VANET Híbrida.
3.1.4 ShockBurst Mejorado
ShockBurst Mejorado [16] es un protocolo de la capa de enlace de datos. Se trata de un protocolo de la marca
NORDIC SEMICONDUCTOR. Este protocolo permite la implementación de potencias ultra bajas y alto
rendimiento en comunicaciones. Esta solución no añade una complejidad excesiva al nodo central de la red. Este
protocolo tiene el modo MultiCeiver, el cual es una característica que se obtiene al poner un dispositivo en modo
receptor, pudiendo así configurar 6 tuberías paralelas (en este caso) de datos con direcciones únicas. Una tubería
de datos es un canal lógico en el canal de radio frecuencia físico.
Además de eso hay un receptor primario (PRX) que puede recibir los datos de las 6 tuberías de un mismo canal
de frecuencia. A cada tubería se le puede configurar un comportamiento individual.
A continuación, se presenta el formato de paquete de éste protocolo.
Figura 3-19. Paquete de ShorckBurst Enhanced.
El paquete contiene diferentes campos:
• Preambulo (1 byte): Secuencia de bits que se usa para detectar niveles bajos (0) y altos (1) en el receptor.
El preámbulo tiene una longitud de 1 byte y puede ser 01010101 o 10101010. Si el primer bit en la
dirección es un 1, el preámbulo es automáticamente puesto a 10101010 y si el primer bit es un 0, el
preámbulo se pone a 01010101. Esto se hace de esta forma para asegurar que hay las suficientes
transiciones en el preámbulo para estabilizar el receptor.
27 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
• Dirección-Address (3-5 bytes): Este campo representa la dirección del receptor. Una dirección asegura
que el paquete correcto sea detectado por el receptor. Este campo puede ser configurado para ser de 3,
4, o, 5 bytes.
• Control del paquete-Packet Control Field (9 bits): La siguiente figura muestra el formato del campo de
control del paquete.
Figura 3-20. Campo de control de paquete.
▪ Longitud de payload (6 bits): Este campo especifica la longitud del payload en bytes. La
longitud del payload puede ser desde 0 a 32 bytes. Si es 000000 indica que la longitud es de 0
byte (se usa solo para los paquetes de asentimiento), si es 100000 significa que el payload será
de 32 bytes.
▪ PID-Identificador de paquete: Se usa para detectar si el paquete recibido es nuevo o es una
retransmisión.
▪ NO_ACK: Esta bandera solo se usa cuando la característica del asentimiento automatico está
activa. Poniendo la bandera a 1, indica al receptor que el paquete no tiene que ser auto-asentido
• Payload: Es el contenido del paquete definido por el usuario.
• CRC: Se trata del mecanismo de detección de errores en el paquete.
En la siguiente figura se puede observar cómo es la topología típica para esta solución.
Figura 3-21. PRX usando Multiceiver.
Alternativas
28
3.1.5 Comparación de tecnologías
En la siguiente tabla se recogen las principales diferencias de los cuatro protocolos nombrados anteriormente.
Protocolo Bluetooth LE ZigBee Wi-Fi-WAVE ShockBurst
Especificación IEEE 802.15.1 IEEE 802.15.4 IEEE 802.11p RF4CE
Banda de
frecuencia
2.4 GHz 868/915 MHz;
2.4GHz
5.9 GHz 2.4 GHz; 5 GHz
Max. Régimen
binario
1 Mb/s 250 Kb/s 27 Mb/s 2 Mb/s
Rango Nominal 1-100 m 10 – 150 m 10 m – 1Km 30 m (antenas de
parche integradas)
[17]
Potencia
nominal
transmitida
(-20) - 10 dBm (-32) - 0 dBm 15 - 20 dBm (-18) – 0 dBm
Número de
canales de
RadioFrecuencia
40 1/10;16 7 126
Ancho de banda
de canal
2 MHz 0.3/0.6 MHz; 2
MHz
10 MHz 1MHz; 2MHz
Tipo de
modulación
GFSK BPSK (+ASK), O-
QPSK
BPSK, QPSK,
COFDM, CCK,
M-QAM
GFSK
Tamaño máx. de
la red
Ilimitado 65.000 62.000 7
Encriptación AES cifrado en
bloque (128)
AES cifrado en
bloque
WEP y AES Sin encriptado (se
puede añadir AES
[18])
Autenticación Secreto
compartido
CBC-MAX
(extensión de
CCM)
WPA2 (802.11i) Secreto
compartido
Protección de
datos
24-bit CRC 16-bit CRC 32-bit CRC 16-bit CRC
Tabla 3–2. Comparación de tecnologías.
A continuación, se analizarán a fondo los aspectos más importantes de la tabla anterior.
29 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
3.1.5.1 Canales de radio
Los protocolos Bluetooth LE, ZigBee y ShockBurst pueden trabajar en la banda de 2.4GHz, la cual es libre (sin
licencia) en la mayoría de los países y que es conocida como la banda industrial, científica y médica (Industrial,
Scientific, and Medical – ISM). Wi-Fi-WAVE usa la banda de 5,850-5,925 Ghz (ITS-RS, Intelligent
Transportation Systems Radio Service). Bluetooth LE usa salto en frecuencia (FHSS/AFH) con 40 canales y un
ancho de banda de 2 MHz, mientras que ZigBee usa espectro expandido por secuencia directa (DSSS) con 16
canales y 2 MHz de ancho de banda. Wi-Fi-WAVE usa DSSS (802.11), Complementary Code Keying-CCK
(802.11b), ó modulación OFDM (Orthogonal Frequency Division Multiplexing) con 7 canales de radio
frecuencia y 10 MHz de ancho de banda. ShockBurst utiliza DS/FH-SS [19] (Direct Sequence Spread Spectrum
y Frequency-Hopping Spread Spectrum) con 126 canales de radio frecuencia y de 1 a 2 MHz de ancho de banda
(en función del régimen binario).
3.1.5.2 Tamaño de la red
El número máximo de dispositivos que pueden pertenecer a una red celular es ilimitado para Bluetooth LE,
sobre 65000 para una red en estrella de ZigBee, desde 100 hasta 62000 para Wi-Fi-WAVE y 7 (6 esclavos más
un master) para una red en estrella (modo Multiceiver) de ShockBurst (para cada canal de frecuencia).
3.1.5.3 Seguridad
Los 4 protocolos tienen autenticación y encriptación. Cada uno tiene sus ventajas e inconvenientes, pero para el
uso docente que se va a hacer de los dispositivos en este proyecto, lo importante es que al menos este cifrada la
comunicación. Si bien es cierto que algunos incorporan la seguridad en la propia definición del protocolo en sí
y otros simplemente lo permiten realizando una implementación software o hardware.
3.1.5.4 Tiempo de transmisión
El tiempo de transmisión depende de régimen binario, el tamaño del mensaje, y la distancia entre 2 nodos. La
fórmula para el tiempo de transmisión (µs) se puede describir de la siguiente manera:
𝑇𝑡𝑥 = (𝑁𝑑𝑎𝑡𝑎 + (𝑁𝑑𝑎𝑡𝑎
𝑁𝑚𝑎𝑥𝑃𝑙𝑑×𝑁𝑜𝑣ℎ𝑑)) ×𝑇𝑏𝑖𝑡 + 𝑇𝑝𝑟𝑜𝑝
donde 𝑁𝑑𝑎𝑡𝑎 es el tamaño de los datos, 𝑁𝑚𝑎𝑥𝑃𝑙𝑑 es el tamaño máximo de los datos, 𝑁𝑜𝑣ℎ𝑑 es el tamaño de
cabecera, 𝑇𝑏𝑖𝑡 es el tiempo de bit, y 𝑇𝑝𝑟𝑜𝑝 es el tiempo de propagación entre dos dispositivos cualquiera. Por
simplicidad, el tiempo se propagación se va a considerar despreciable. Los parámetros de los cuatro protocolos
inalámbricos usados para este estudio están listados en la Tabla 3-3. Como se muestra en la Figura 3-22, el
tiempo de transmisión para ZigBee es mayor que el de los demás debido a su régimen binario (250 Kbit/s).
Obviamente, el tiempo de transmisión es proporcional al tamaño de la carga útil e inversamente proporcional al
régimen binario máximo.
Alternativas
30
Protocolo Bluetooth LE ZigBee Wi-Fi -WAVE ShockBurst
Especificación IEEE 802.15.1 IEEE 802.15.4 IEEE 802.11p RF4CE
Máx. Régimen
Binario (Mbit/s)
1 0.25 27 2
Tiempo de bit (µs) 1 4 0.037 0.5
Max. Carga útil
(payload) (bytes)
39 102 2312 32
Max. Overhead
(bytes)
8 31 58 8
Eficiencia en
codificación (%)
94.41 76.52 97.18 80.00
Tabla 3–3. Parámetros típicos de protocolos inalámbricos.
Figura 3-22. Tiempo de transmisión vs Tamaño de los datos.
3.1.5.5 Eficiencia en la codificación de los datos
La eficiencia en la codificación de los datos está definida por el cociente entre el tamaño de los datos y el tamaño
del mensaje (i.e. el número total de bytes usados para la transmisión de datos. La fórmula para la eficiencia en
la codificación (%) es la siguiente:
31 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
𝑃𝑐𝑜𝑑𝐸𝑓𝑓 = 𝑁𝑑𝑎𝑡𝑎
𝑁𝑑𝑎𝑡𝑎 + (𝑁𝑑𝑎𝑡𝑎
𝑁𝑚𝑎𝑥𝑃𝑙𝑑×𝑁𝑜𝑣ℎ𝑑)
Los parámetros que aparecen en la Tabla 3-3 también se usan para comparar la eficiencia de codificación. Según
la expresión anterior, para un tamaño de datos pequeño (inferior a 339 bytes), Bluetooth LE es la mejor solución.
También, ZigBee y ShockBurst tienen una buena eficiencia para datos inferiores a 102 y 32 bytes
respectivamente. Obviamente, para datos de gran tamaño ShockBurst y ZigBee no son una buena opción. No
obstante, para una red de sensores inalámbrica, el tamaño de los datos normalmente es pequeño (por ejemplo,
los datos de temperatura en un entorno de monitorización requieren menos de 4 bytes). Es por ello que Bluetooth
LE, ZigBee o ShockBurst pueden ser una buena elección (desde el punto de vista de eficiencia en la codificación
de los datos). Se muestra una comparativa gráfica en la Figura 3-23.
Figura 3-23. Eficiencia en codificación (%).
3.1.5.6 Consumo de potencia
Bluetooth LE, ZigBee y ShockBurst están creados para productos portables, de poco rango y potencia de batería
limitada. Es por ello que consumen muy poca potencia y, en algunos casos, no afectarán sensiblemente a la vida
de la batería. Por otro lado, Wi-Fi-WAVE está diseñado para conexiones de rangos y entornos especiales. Los
consumos de potencia en la transmisión y recepción se encuentran en la Tabla 3-4. Los datos que se muestran
son para productos particulares. La Figura 3-24indica el consumo de potencia en mW según el protocolo
utilizado (en transmisión-TX y recepción-RX).
Si lo que se quiere es usar dispositivos donde el consumo de potencia sea importante y las aplicaciones que se
requieran de ellos necesitan un régimen binario bajo, Bluetooth LE, ZigBee y ShockBurst son los más
adecuados.
Alternativas
32
*En modo activo, no en sleep mode
Standard Bluetooth LE ZigBee Wi-Fi -WAVE ShockBurst
VDD(voltios) 1.8 3 3.3 1.9-3.6 (Las
corrientes son para
una Vdd=3 V)
TX (mA)* 15 24.7 60.45 11.3 (para 0dBm de
potencia)
RX (mA)* 15 27 70 13.5(para 2Mbps)
Tabla 3–4. Consumo de los chipsets de cada protocolo.
Figura 3-24. Potencia consumida por cada protocolo.
La potencia recibida por un sensor inteligente para cada paquete de datos separados una distancia d se predice
mediante los modelos de espacio libre de Friss y de reflexión de dos rayos en tierra plana. La potencia recibida
sigue la siguiente ecuación [24], [25]:
33 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
Donde:
L - Pérdidas de trayecto
ℎ𝑡 - Altura de la antena transmisora
ℎ𝑟 - Altura de la antena receptora
d - Distancia entre transmisor y receptor
λ - Longitud de onda (velocidad de la luz/frecuencia de la señal)
La Figgura 3-25 muestra la evolución de la potencia de recepción basada en el rango de la señal para los
protocolos estudiados dado un tamaño de paquete fijo. Los parámetros del cálculo son los siguientes: 𝐿 =1, 𝐺𝑡 = 𝐺𝑡 = 1, ℎ𝑡 = ℎ𝑟 = 1.5 𝑚.
Teniendo en cuenta las potencias de transmisión obtenidas en la Figura 3-24 y la ecuación anterior, para una λ
de 0.125m (2.4 GHz, excepto para WAVE que son 5GHz), el resultado es el siguiente:
Figura 3-25. Potencia recibida dependiendo del rango de señal.
Alternativas
34
3.1.5.7 Coste de Hardware
En este apartado se analizarán los coses de adquisición de cada dispositivo que implementa los protocolos
anteriores. Se utilizará Amazon como establecimiento de referencia para los precios. Así se intentará establecer
la mayor igualdad entre los dispositivos.
A continuación, se adjunta una tabla con el hardware, los precios y los enlaces para su adquisición.
Dispositivo Coste (€) URL
Bluetooth LE 28.50 https://www.amazon.es/Bluefruit-Bluetooth-Energy-nRF8001-
Breakout/dp/B00RXWX8JI/ref=sr_1_4?ie=UTF8&qid=1493176494&sr=8-
4&keywords=bluetooth+low+energy
Módulo
ZigBee
+Antena
54.15 https://www.amazon.es/XBee-1-mW-Antena-alambre-
1/dp/B01FB1LN94/ref=sr_1_16?ie=UTF8&qid=1479897481&sr=8-
16&keywords=zigbee+antena
https://www.amazon.es/Bluetooth-Escudo-Control-Inal%C3%A1mbrico-
Arduino/dp/B01M4S982V/ref=sr_1_4?ie=UTF8&qid=1479898946&sr=8-
4&keywords=zigbee++modulo
Wi-Fi-WAVE
(RSU)
73.60 https://www.amazon.es/Cisco-RV110W-inal%C3%A1mbricos-Ethernet-
100Base-
T/dp/B0053XTW5S/ref=sr_1_1?s=electronics&ie=UTF8&qid=1493176565&
sr=1-1&keywords=802.11p
NRFL24L01+ 0.989 https://www.amazon.es/NRF24L01-transceptor-inal%C3%A1mbrico-
Arduino-
Microcontrolle/dp/B01C2NOKDU/ref=sr_1_1?ie=UTF8&qid=1479899791&
sr=8-1&keywords=nrf24l01
Tabla 3–5. Costes de adquisición de los dispositivos.
A simple vista, se podría descartar ZigBee por su elevado coste, ya que para el propósito de este proyecto los
demás dispositivos podrían funcionar perfectamente. No obstante, en la siguiente sección se realizará una
comparativa gráfica.
3.2 Nodo-pasarela
En este apartado se valorará qué tipo de dispositivo se usará para el nodo-pasarela, también llamado fog-node.
Este nodo se encarga de proporcionar conexión hacia Internet desde la red local (donde se encuentran los
microcontroladores con los sensores). El fog-node será consciente de todo el tráfico que vaya hacia Internet y lo
enrutará convenientemente.
Se van a comparar dos miniPC: la Raspberry PI y C.H.I.P. El gran potencial de estos mini ordenadores recae en
su bajo coste con respecto al rendimiento que ofrecen.
En primer lugar, se analizarán las características de cada uno de estos equipos, y posteriormente se hablará de
su potencia, coste y usabilidad.
35 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
3.2.1 Características
A continuación, se presentan tabuladas las características de ambos equipos.
Dispositivo C.H.I.P. [27] Raspberry Pi 3 [28]
Puerto GPIO 80 pines 40 pines
Procesador AllWinner R8 a 1 GHz
(monocore ARM Cortex-A8)
Broadcom BCM2837 de 1.2
GHz ARMv8 quad core
Cortex-A53 de cuatro núcleos.
64 bits
Memoria RAM 512 MB 1GB SDRAM LPDDR2
Almacenamiento 4 GB No (ranura Micro SD)
Alimentación Adaptador USB 5V y 300 mA 5V a 2.5A a través de conector
hembra microUSB
Alimentación Por Batería
Externa
Una celda LiPo 3,7V (no
incluida) con dos pines 2-pin
JST-PH de 2,0 mm
No
Conectividad WiFi 802.11b/g/n WiFi 802.11n
Bluetooth Low Energy Sí Sí
Puertos Usb 1 x USB-A, 1 x Micro USB
con OTG
4 x USB 2.0
Salida De Vídeo
Compuesto
Sí (cable mini TRRS a RCA
incluido)
Si
Licencia Open Hardware Propietario
Dimensiones 40 x 60 mm 86 x 56 x 20 mm
Otros Conector MPI CSI-2 de 15
vías para cámara de vídeo HD
Raspberry Pi.
Conector de interfaz serie de
display de 15 vías.
Tabla 3–6. C.H.I.P. vs Raspberry Pi 3.
Alternativas
36
Estas características pueden ser respaldadas por algunas pruebas realizadas por la Escuela Europea de Robótica,
donde se realizan algunas pruebas de rendimiento con sysbench [29].
Figura 3-26. Indicadores de rendimiento.
3.2.1.1 Consumo
En términos de potencia, ambas tecnologías están a la par. Obviamente la Raspberry Pi 3 necesita algo más de
potencia debido a sus periféricos extras y su microprocesador. En concreto consume unos 4.5W [30] si se llevara
a condiciones extremas. Sin embargo, C.H.I.P. consume unos 1.25 - 3W [31].
3.2.1.2 Coste
Lo primero que es necesario aclarar en ambos casos es que, aunque efectivamente el coste de las placas con los
componentes básicos es el que indican sus fabricantes, no será el coste final de estos dispositivos.
En ese coste influyen los accesorios que se necesiten para poner en funcionamiento estos equipos. Algunos de
esos accesorios son opcionales, pero otros serán necesarios todo el tiempo. Es el caso del coste del
almacenamiento en la Raspberry Pi (sin Micro SD no se puede hacer nada), el de los cables para alimentarlo o
los que hacen que se pueda conectar a un televisor o un monitor HDMI.
A continuación, se presenta una tabla con los costes asociados:
37 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
Dispositivo C.H.I.P. [32] Raspberry Pi 3
Precio 10 € 30 €
Coste HDMI 15 € (adaptador en formato
“placa sombrero”)
0 € (incluido)
Coste Almacenamiento 0 € (4 GB incluidos de serie) 5 € (4 GB de almacenamiento
microSD)
Precio Total 25 € 35 €
Tabla 3–7. Coste de equipos.
3.2.1.3 Usabilidad
A continuación, se presentan unos resultados de un estudio realizado por Hacker SBCs [33] en los cuales se
presenta el Top 10 de placas (el método usado para el ranking ha sido Borda Count). Borda Count se trata de un
método de elección en el cual los votantes clasifican los dispositivos en orden de preferencia.
Figura 3-27. Top 10 de MiniPCs en Junio de 2016.
3.3 Microcontrolador
Para los microcontroladores, se ha decidido usar las placas de Arduino. El uso de placas Arduino tiene muchas
ventajas. A continuación, se presentan las más significativas, las cuales justifican la elección de este
microcontrolador:
• Open Source: Plataforma de código y hardware abierto (licencias gratuitas)
• Fácil programación: Arduino te ofrece un entorno de desarrollo integrado (IDE) con funciones
preestablecidas que reducen la lógica a lectura de entradas, control de tiempos y salidas de una manera
semántica e intuitiva. Por eso lo convierte en una herramienta perfecta para iniciarse en el mundo de la
Alternativas
38
electrónica.
Arduino tiene la ventaja de que no necesita ningun tipo de tarjeta de programación como pasa con los
microcontroladores, puesto que es la misma placa la que se conecta vía serial a la computadora usando
un cable USB y se pueden cargar los programas totalmente en vivo, sin riesgo de dañar la tarjeta debido
a su protección adicional. El código posee su propio lenguaje de alto nivel llamado Processing.
• Documentación y tutoriales en exceso: Si algo tiene Arduino es que Internet esta plagado literalmente
de documentación sobre esta plataforma. Desde la misma página de Arduino, del IDE que también
viene con multitud de ejemplos y los tutoriales en la red, se pueden descargar multitud de ejemplos e
ideas. Además de permitir un desarrollo sencillo.
• Librerías: Una de las ventajas más grandes que tiene Arduino es que poseen librerías para prácticamente
cualquier componente externo que se le quiera acoplar.
• Precio: Existen placas en el mercado de tamaño y precio mínimos. En el caso del arduino Nano, tiene
las mismas funcionalidades que el Arduino UNO sólo que el microprocesador es más compacto y se
disponen de menos puertos de E/S. El precio del Arduino nano no suele sobrepasar los 5 euros. Es un
coste muy asumible para hacer una red de sensores grande y de bajo coste.
• Periféricos y aplicaciones: Arduino también es compatible con infinidad de periféricos de otras marcas
como Xbee, Teclados, LCD, sensores digitales, dispositivos de Sparkfun, serial, 1-Wire, SD-Card entre
muchos otros. Gracias a su versatilidad, Arduino se ha convertido en la placa de desarrollo con la que
prácticamente se puede hacer de todo, desde domotizar un hogar u oficina, aplicaciones en robótica
como cerebro de un robot has ser utilizado como nodos de tecnologías WSN.
Figura 3-28. Arduino Nano v3.1.
El arduino nano está compuesto por un total de 32 pines. 14 digitales y 8 analógicos. Los pines restantes son de
alimentación (2), tierra (2), reset(2), señal de entrada (1) y referencia (1). En la Figura 3-29 se puede ver el
diagrama de pines de entrada/salida del Arduino nano.
Cada uno de los 14 pines digitales del Nano puede ser usado como entrada o salida, usando las funciones
pinMode(),digitalWrite(), y digitalRead(). Operan a 5 voltios. Cada pin puede proveer o recibir un máximo de
40mA y poseen una resistencia de pull-up (desconectada por defecto) de 20 a 50 kOhms. Además algunos pines
poseen funciones especializadas:
• Serial: 0 (RX) y 1 (TX). (RX) usado para recibir y (TX) usado para transmitir datos vía serie. Estos
pines están conectados a los pines correspondientes del chip USB-a-TTL de FTDI.
• Interrupciones Externas: pines 2 y 3. Estos pines pueden ser configurados para activar una
interrupción por paso a nivel bajo, por flanco de bajada o flanco de subida, o por un cambio de valor.
• PWM: pines 3, 5, 6, 9, 10, y 11. Proveen de una salida PWM de 8-bits cuando se usa la función
analogWrite().
39 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
• SPI: pines 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). Estos pines soportan la comunicación SPI, la
cual, a pesar de poseer el hardware, no está actualmente soportada en el lenguaje Arduino.
• LED: Pin 13. Existe un LED conectado al pin digital 13. Cuando el pin se encuentra en nivel alto, el
LED está encendido, cuando el pin está a nivel bajo, el LED estará apagado.
El Nano posee 8 entradas analógicas, cada una de ellas provee de 10 bits de resolución (1024 valores diferentes).
Por defecto miden entre 5 voltios y tierra, sin embargo es posible cambiar el rango superior usando la función
analogReference(). También, algunos de estos pines poseen funciones especiales:
• I2C: Pines 4 (SDA) y 5 (SCL). Soporta comunicación I2C (TWI) usando la librería Wire.
Hay algunos otros pines en la placa:
• AREF. Tensión de referencia por las entradas analógicas. Se configura con la función
analogReference().
• RESET. Si se establece este pin a nivel bajo se reseteará el Arduino. Normalmente se usa para añadir
un botón de reset que mantiene a nivel alto el pin reset mientras no es pulsado.
Figura 3-29. Diagrama de pines de Arduino Nano.
3.4 Cloud
En esta sección se ahondará en la parte de la cloud, la cual permitirá realizar cualquier operación
(actuación/lectura) sobre la red local de sensores (desde el fog-node hacia dentro). En la nube (AWS) se
encuentra el nodo Kafka que se encargará de reenviar los mensajes desde la Raspberry Pi a Telegram App y a
Dweet y también se encargará de reenviar los mensajes que Telegram App manda a la Raspberry Pi para que
esta pueda actuar sobre los sensores. Todas las acciones que se se presentan en las siguientes secciones se han
de hacer en el nodo Kafka.
3.4.1 Kafka
Apache Kafka es un servicio distribuido, particionado y con posibilidad de replicación que ofrece la
funcionalidad de un sistema de colas de mensajes [42]. Todas las comunicaciones realizadas en Apache Kafka
usan conexiones TCP. La sincronía del servicio y el descubrimiento de nodos se realiza a través de Apache
ZooKeeper. Apache Kafka es el punto de entrada de información en nuestro sistema.
Alternativas
40
Apache Kafka está formado por diversos componentes que forman su arquitectura, estos componentes son
detallados a continuación:
• Topic y particiones
Un topic es una categoría donde los mensajes son publicados. Para cada topic, el clúster de Kafka
mantiene un índice que se encuentra particionado, como se muestra en la Figura 3-30.
Figura 3-30. Topic particionado.
Cada partición es una secuencia, ordenada e inmutable, de mensajes que están continuamente apilados.
Los mensajes en las particiones tienen asignados un identificador que es denominado offset, este
identifica de forma única al mensaje en su partición.
El clúster de Kafka mantiene los mensajes publicados, tanto si son consumidos como si no, por un
período de tiempo configurable. Después de este tiempo los mensajes son borrados y se libera la
memoria que estaba reservada.
Las particiones del clúster son distribuidas sobre los servidores que lo constituyen, distribuyendo la
carga en varios nodos, también se puede replicar las particiones para conseguir alta disponibilidad de la
información. Cada partición tiene un servidor que actúa como líder y varios o ninguno que actúan como
seguidores. El líder se encarga de leer y escribir todas las peticiones para la partición, mientras los
seguidores replican pasivamente la información del líder. Si el líder falla, uno de los seguidores se
convierte automáticamente en líder.
• Productores
Los productores publican los mensajes a un determinado topic. El productor es responsable de elegir
qué mensaje envía cada partición de cada topic. Esto se puede hacer con un balanceo round-robin para
distribuir la carga o se puede implementar un balanceador personalizado. Los servidores de Kafka o
brokers, por defecto, escuchan los mensajes en el puerto 9092.
• Consumidores
Los consumidores de Kafka pueden tener instancias en distintos procesos o maquinas, cada consumidor
de Kafka tiene un identificador de grupo. Este identificador proporciona dos modos de funcionamiento:
• Si todas las instancias de consumidores tienen el mismo grupo, entonces la cola trabaja como
una cola que balancea la carga a través de los consumidores.
• Si todos los consumidores tienen diferentes instancias, entonces la cola trabaja como una cola
de publicación-subscripción y todos los mensajes son enviados en difusión a todos los grupos.
41 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
Normalmente, cada grupo tiene múltiples instancias de consumidor para proporcionar escalabilidad y
alta disponibilidad.
Los consumidores usan ZooKeeper para llevar un conteo de los offsets por los que van leyendo y cual
es el offsets actual de un topic.
El hecho de elegir Apache Kafka es por la escalabilidad horizontal que éste presta y la robustez ante fallos que
tiene.
3.4.1.1 Procesamiento de eventos complejos (CEP-Complex Events Processing)
Un CEP [43] es un procesador de eventos que combina datos de múltiples orígenes para crear eventos o patrones
que requieren de unas circunstancias más complicadas. En este caso, se ha usado el CEP de redborder, puesto
que es de código libre y es sencillo de usar. Este CEP ejecuta un conjunto de reglas, que como se ha dicho, puede
inferir eventos, patrones y/o secuencias. La entrada de esas reglas son todos los eventos de un mismo topic de
Kafka, y el resultado de esos cálculos son insertados en un nuevo topic (o conjunto de topics). Las reglas se se
pueden añadir o eliminar mediante una API REST.
A continuación, se presenta una figura genérica que muestra el funcionamiento de este CEP
Figura 3-31. Procesador de eventos complejos.
Las reglas son la unidad de trabajo en este CEP, las cuales están escritas en JSON y accesibles/modificables
mediante una API REST. Estas reglas son una combinación de planes de ejecución de una librería llamada
Siddhi y algunos datos mas que ayudan al mapeo de los topics de Kafka a los flujos de Siddhi.
Siddhi [44] es el motor de este CEP. Se trata de una librería en Java creada por WSO2 que actua como un motor
de procesamiento de eventos, lo cual permite trabajar con flujos de datos y combinarlos, analizarlos, etc. Para
saber cómo escribir los planes de ejecución se ha de conocer el lenguaje de peticiones de Siddhi (Siddhi Query
Language), que es como un lenguaje SQL simple, el cual permite trabajar con flujos de datos.
Alternativas
42
3.4.2 Dweet
Dweet.io es un datastore que se puede comunicar con máquinas, sensores, dispositivos y gadgets (cosas)
mediante mensajes llamados de manera informal ‘dweets’. Se asigna a cada ‘cosa’ un nombre inequívoco y ésta
podrá publicar en dweet. Dweet.io permite que se pueda acceder a los datos de los sensores mediante una API
RESTful [45].
Cada dweet puede tener un payload de hasta 2.000 caracteres. En el modo gratuito, estos dweets son públicos,
sin embargo, se pueden privatizar con la versión de pago, la cual consiste en pagar 1 euro al mes por cada ‘cosa’
a la cual quiera privatizar sus mensajes. En el caso de este proyecto, sólo tenemos una ‘cosa’, la Raspberry Pi.
Al ser un escenario de prueba, con datos que no requieren confidencialidad, se ha optado por el modo gratuito.
El modo de pago proporcionaría un token identificativo, necesario para acceder a los dweets además de poder
nombrar a la ‘cosa’ con el nombre que se desee (también permite el envío de alertas vía email). El modo gratuito
sólo permite usar nombres no usados ni bloqueados por los usuarios de pago. Además, el modo de pago permitirá
obtener históricos de los datos publicados en este datastore. Para un uso experimental, la modalidad gratuita es
más que suficiente para el objetivo de este proyecto.
3.4.3 Telegram App
Telegram es una aplicación de mensajería enfocada a la velocidad y seguridad, es muy rápida, simple y gratis.
Se puede usar Telegram en todos los dispositivos (de un mismo usuario) al mismo tiempo y con una
sincronización de los mensajes perfecta.
Telegram ofrece dos tipos de APIs. La API Bot permite crear programas que usan la interfaz de Telegram para
el intercambio de mensajes y la API Telegram que permite crear clientes de Telegram personalizados [47]. Para
este proyecto, se usarán los llamados Bots de Telegram. Estos Bots son aplicaciones de terceros que se ejecutan
dentro de Telegram. Se puede interactuar con los bots mediante el envío de mensajes, comandos o peticiones
inline. En resumen, se tratan de peticiones HTTP realizadas a través de la interfaz de Telegram, lo que permite
realizarlas desde cualquier sitio (infraestructura cloud de Telegram) y de una forma más visual y conocida.
Es por esto último, por lo que s eha decidido usar esta aplicación móvil (que además tiene una versión web) para
consultar datos de los sensores y enviar datos a los actuadores. Se ahorran así posibles vulnerabilidades a la hora
de crear una aplicación propia y se consigue también una compenetraciónmuy buena con Kafka, cosa que con
una aplicación creada desde cero no sería tan fácil de conseguir.
43
4 ELECCIÓN DE ALTERNATIVAS
n este capitulo se comparan yeligen las alternativas presentadas en el capítulo anterior atendiendo a
parámetros representativos que permitan tomar una buena elección teniendo en cuenta el escenario
presentado. En primer lugar, se elige el protocolo inalámbrico que se encargará de la comunicación entre
los sensores y el nodo-pasarela. Por último, se eligirá el nodo-pasarela mas adecuado. En ambas secciones se
realizan cálculos numéricos para cuantificar las diferentes opciones y poder hacer una elección objetiva.
4.1 Elección de protocolo inalámbrico
A continuación, se elegirá el protocolo a utilizar para llevar las comunicacionesentre los sensores y el nodo
pasarela. En el capitulo anterior se valoran ciertos parámetros, los cuales sirven para tener una elección
fundamentada del protocolo a elegir.
Las principales restricciones para elegir una tecnología inalámbrica son las siguientes [26]:
• Rango
• Confiabilidad
• Ancho de Banda
• Consumo de potencia
• Seguridad
• Coste
Para el caso particular que se presenta, el tamaño máximo de nodos que soporta una tecnología y la distancia
que deben de cubrir estos no es de gran importancia, ya que una Smart Home no precisa de un número muy
elevado de sensores y no se necesitan cubrir grandes distancias.
Puesto que en este escenario no se mueven grandes cantidades de datos y estos no son críticos, los tiempos de
trasmisión, la seguridad y la eficiencia de codificación no son parámetros a tener en cuenta para la elección de
una tecnología.
Por tanto, de las cinco características presentadas, se hará más hincapié en el Coste, Ancho de Banda y
Consumo de Potencia.
A continuación, se presenta una comparativa gráfica de estos tres parámetros, donde el consumo de potencia es
E
La ley no debe tornar al pasado, sino prever el futuro.
Niccolo Maquiavelo
Elección de Alternativas
44
representado por el volumen de las bolas (aunque también se muestra numéricamente dentro de éstas).
Tecnología Coste (euros) Ancho de Banda (MHz) Consumo de Potencia (mW)
Bluetooth LE 28,50 1 27 ZigBee 54,15 2 81 Wi-Fi-WAVE (RSU)
73,60 10 231
ShockBurst 0,989 2 40,5
Tabla 4–1. Elección de protocolo.
Figura 4-1. Comparativa de protocolos.
La figura de mérito es la que menor coste, ancho de banda y volumen de bola tenga. Es por tanto que la bola
más cercana al origen y más pequeñita, es la que mas convendrá para este cometido.
Nótese que la elección de dispositivo se hace teniendo en cuenta el objetivo de este proyecto. Si se quisiera un
entorno a gran escala habría que plantearse otros parámetros para la elección de dispositivos (alcance, payload,
etc.).
Por tanto, y acorde a lo anteriormente comentado, el dispositivo elegido será el NRF24L01+ que implementa
ShockBurst.
0
2
4
6
8
10
12
0 10 20 30 40 50 60 70 80 90
AN
CH
O D
E B
AN
DA
(M
HZ)
PRECIO (EUROS)
Comparativa de ProtocolosBluetooth LE ZigBee Wi-Fi-WAVE ShockBurst
45 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
Figura 4-2. Dispositivo NRF24L01+ (antena microstrip)
4.2 Elección de nodo pasarela
A continuación, se elegirá el nodo pasarela a utilizar para llevar los datos desde los sensores a la nuve y desde
esta a los actuadores. En el capitulo anterior se valoran ciertos parámetros, los cuales sirven para tener una
elección fundamentada de la elección.
Si se quisiera un equipo de mayor rendimiento se optará por la Raspberry Pi 3 (Figura 3-26 del apartado 3.2.1).
No obstante, no es este aspecto el más determinante para la elección del dispositivo a elegir, pero la Raspberry
ya cuenta con ciertos puntos a su favor.
Con respecto al consumo de potencia (Apartado 3.2.1.1), nótese que no hay una gran diferencia entre las
potencias consumidas para decantarse por uno u otro. En el mundo del IoT, los consumos bajos, y por ende la
autonomía, son características muy deseables. En este caso tendrán autonomías parecidas.
Desde el punto de vista del coste (Apartado 3.2.1.2), aunque hay 10€ de diferencia entre ambos, no es una
diferencia significativa, ya que se ha intentado equiparar dos equipos a los que se le pueden añadir diferentes
módulos o prescindir de ellos (aumentar el tamaño de la microSD de la Raspberry Pi 3 o prescindir del HDMI
del C.H.I.P. haciendo uso de la salida RCA. Y así muchas variantes). Es por ello que se consideren estos precios
como orientativos.
Por último, el aspecto más determinante para elegir el miniPC a utilizar ha sido la usabilidad (Apartado 3.2.1.3).
Si hay algo por lo que la Raspberry Pi destaque sobre los demás equipos es por la comunidad que tiene detrás.
Esta comunidad permite tener mucha información de cómo trabajar con este equipo.
Por tanto, se hará hincapié en la Usabilidad, el Coste, y el Consumo.
A continuación, se presenta una comparativa gráfica de estos tres parámetros, donde el consumo de potencia es
representado por el volumen de las bolas (aunque también se muestra numéricamente dentro de éstas).
MiniPC Usabilidad (sin unidades) Coste (€) Consumo (W)
C.H.I.P. 70 25 3
Raspberry Pi 3 370 35 4,5
Tabla 4–2. Comparación de nodos pasarela.
Elección de Alternativas
46
Figura 4-3. Comparativa de nodos pasarela.
La figura de mérito es la que menor coste, y volumen de bola tenga y la que mayor usabilidad tenga. Es por
tanto que la bola más baja, mas pequeña y lejana del origen será la elegida.
Nótese que la elección de dispositivo se hace teniendo en cuenta el objetivo de este proyecto. Puesto que sólo se
necesitará de un nodo pasarela, y el consumo y coste no difieren mucho entre sí, la usabilidad será el prarámetro
determinante para la elección.
Quizá la Raspberry Pi 3 sea algo más cara, pero se dispone de mucha información para trabajar con ella. Por
tanto, se elegirá la Raspberry Pi 3 como nodo central de la topología. Además, se adapta perfectamente a los
Arduino y a los dispositivos de comunicación inalámbrica (NRF24L01+) previamente elegidos.
Figura 4-4. Raspberry Pi 3.
3
4.5
0
5
10
15
20
25
30
35
40
45
0 50 100 150 200 250 300 350 400 450
PR
ECIO
(EU
RO
S)
USABILIDAD
Comparativa de MiniPCs
CHIP Raspberry Pi 3
47
5 DESARROLLO Y FUNCIONAMIENTO
n este capitulo, se van a explicar las funcionalidades, librerías, e implementación de los distintos
componentes. En primer lugar, se desarrolla todo lo relacionado con los Arduino, seguidamente se hará
lo propio con la Raspberry Pi 3 y, por último, se explicará la parte de la cloud en la cual toman partido
Kafka, Dweet y Telegram App. Además, se presentarán varios casos de uso que aportarán una visión global de
cómo funciona la arquitectura.
5.1 Desarrollo y funcionalidad de las distintas partes
5.1.1 Arduino
Para el desarollo del código que se ha implementado en el Arduino, se ha usado el IDE Arduino Software. Este
IDE es el oficial que se puede descargar desde la página de Arduino. Este entorno está escrito en Java y además
es un software de código abierto [34]. En el Arduino es donde se conectarán los sensores, que serán controlados
por éste.
El lenguaje de programación de Arduino es C++, aunque es posible programarlo en otros lenguajes. No es un
C++ puro, sino que es una adaptación que proveniente de avr-libc que provee de una librería de C de alta calidad
para usar con GCC (compilador de C y C++) en los microcontroladores AVR de Atmel, denominado avr-gcc,
y otras muchas funciones específicas para las MCU AVR de Atmel. Los programas de arduino están compuestos
por un solo fichero con extensión “ino”, aunque es posible organizarlo en varios ficheros. El fichero principal
siempre debe estar en una carpeta con el mismo nombre que el fichero [35].
En el escenario planteado se tienen 3 arduinos. Uno de ellos leerá de sensores y otros dos actuarán sobre
dispositivos.
Arduino nº 1
Este dispositivo se encarga de obtener los valores de temperatura y humedad en el ambiente que envía el sensor
DHT11 y también el valor que reporta un sensor de lluvia. Una vez se obtengan estos valores, se enviarán
inalámbricamente a la Rasberry Pi mediante el NRF24L01+. Estos datos son introducidos en el payload (struct)
del mensaje, el cual estará compuesto de un identificador (char [4]) para indicar que se está midiendo y un valor
(float) que indica lo medido en los sensores. El paquete lo completa una cabecera. Por tanto, el formato del
paquete enviado es el que se uestra en la Figura 5-1. Puesto que se tiene un payload de tamaño limitado, para
indicar el tipo de medida que se está reportando se hará uso de un solo carácter que sea representativo (“H” para
la humedad, “T” para la temperatura y “L” para la lluvia). El código de este dispositivo está disponible en el
E
La acción es la clave fundamental de cualquier éxito.
Pablo Picasso
Desarrollo y funcionamiento
48
Anexo I.
Campos Cabecera (5 bytes) Payload (0-32)
Contenido Dirección Estructura de datos
Figura 5-1. Formato de paquete NRF24L01+.
Arduino nº 2
Este dispositivo se encarga de actuar sobre 2 leds, los cuales representan la activación/desactivación de un aire
acondicionado. El arduino recibe un paquete con la misma estructura de siempre, sólo que en este caso el payload
tiene tipos diferentes (un char para indicar sobre que led se está actuando y un char para indicar el estado al que
se quiere poner el led) donde se indica el led el cual se quiere modificar su estado y el valor del estado (ON/OFF).
Por el mismo motivo que antes (limite de tamaño en el payload), al arduino le llega en el campo sensor de su
payload una ‘R’ o una ‘B’ (rojo y azul respectivamente), y a partir de ahí éste se encargará de discernir que led
encender. El código de este arduino se encuentra en el Anexo I.
struct payload_t
{
char sensor;
char on_off;
};
Arduino nº 3
Este arduino se encarga de actuar sobre un motor de 4 fases que será el encargado de la automatización del
cierre/apertura de una ventana. El obejtivo de este dispositivo es activar/desactivar el motor. El formato del
paquete recibido es el mismo que el que reciben los otros dos arduinos, y el payload es exactamente igual que
el mostrado para el Arduino nº 2, la única diferencia es que llega el paquete con un carácter ‘M’, el cual indica
que se debe actuar sobre el motor. El código de este dispositivo se encuentra en el Anexo I.
La raspberry pi necesita saber la dirección de los NRF24L01+ para poder enviarle los paquetes al dispositivo en
cuestión. Los arduinos envían todos a la raspberry pi, por tanto, todos envían al mismo NRF24L01+ (el
conectado a la raspberry pi).
Librerias y sensores/módulos
A continuación, se van a detallar los sensores usados (y sus librerías) y el esquema de cableado para el despliegue
del escenario.
En primer lugar, se han de conocer las librerías necesarias para poder usar los dispositivos de comunicación
inalámbrica NRF24L01+ sobre los Arduinos. Se instalarán dos librerías:
• RF24 [36]: Esta librería está diseñada para:
- Ser más compatible con las especificaciones operacionales del chip que da el fabricante,
permitiendo también a los usarios mas avanzados salirse de estas especificaciones.
- Maximizar las capacidades de los NRF24L01+ cuando se usan a través de los Arduino.
- Tener una comunicación más fiable, libre de errores y con más características.
- Que el driver sea mas fácil de usar por los principiantes y con ejemplos bien documentados.
49 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
• RF24Network [37]: Esta clase implementa una capa de red OSI usando los dispositivos NRF24L01+
que son manejados por la librería anterior. El objetivo de esta librería es crear una alternativa a las
radiocomunicaciones ZigBee.
Ahora se presentarán algunos fragmentos del código del receptor y del emisor usando las librerías anteriores:
Receptor
RF24 radio(7,8);//Selección de los pines en el Arduino
RF24Network network(radio);
//Inicialización del SPI, de la radiación de señal y del canal-nodo
SPI.begin();
radio.begin();
network.begin(/*canal*/ 90, /*direccion del nodo receptor*/ este_nodo);
RF24NetworkHeader header;//Inicialización de cabecera
network.read(header,DATOS,TAM_DATOS));//lectura de los datos
Transmisor
RF24 radio(7,8); //Selección de los pines en el Arduino
RF24Network network(radio);
//Inicialización del SPI, de la radiación de señal y del canal-nodo
SPI.begin();
radio.begin();
network.begin(/*canal*/ 90, /*direccion del nodo transmisor*/ este_nodo);
RF24NetworkHeader header(/*nodo receptor*/ el_otro_nodo);
network.write(header,DATOS,TAM_DATOS));//escritura de los datos
Desarrollo y funcionamiento
50
Por último, se presentará el esquema del cableado para conectar el dispositivo NRF24L01+ al arduino:
Figura 5-2. Pines de NRF24L01+.
En la siguiente tabla se presenta la conexión entre los pines anteriores y los de Arduino:
PIN NRF24L01+ Arduino-P1 Conector
1 GND (GND)
2 VCC (3V3)
3 CE (D7)
4 CSN (D8)
5 SCK (D13)
6 MOSI (D11)
7 MISO (D12)
8 IRQ Not Connected
Tabla 5–1. Conexión Arduino-NRF24L01+.
Sensor DHT11: Humedad y temperatura [38]
• Librería: Este sensor es el único que necesita una librería externa, ya que todos los demás tienen sus
librerías integradas por defecto en el IDE de Arduino. Con esta librería se podrá hacer un uso más
cómodo del sensor. Con esta línea, se leerían la humedad y temperatura y se guardarían en las variables
humi y temp
dht11.read(humi, temp)
51 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
• Cableado: En la siguiente imagen se presenta un esquema de cableado. El cable rojo y negro representan
5 v y tierra respectivamente. El cable morado va conectado a cualquier pin que sea digital (en este caso
el pin 2).
Figura 5-3. Cableado de DHT11.
Sensor FC-37: Sensor de lluvia [39].
Este sensor no necesita de librería especial. A continuación, se presenta el esquema de cableado que ha de
seguirse para conectar este sensor al Arduino.
Con un simple digitalRed(9) se podrá leer la información de este sensor.
Figura 5-4. Cableado sensor FC-37.
Motor 28BYJ-48: Motor de 4 fases.
Este sensor no necesita de librería especial. A continuación, se presenta el esquema de cableado que ha de
seguirse para conectar este motor al Arduino. Este motor viene con una placa llamada breakout. En la
siguiente tabla se presenta el mapeo de cables del Arduino con el breakout.
ARDUINO 12 11 10 9
BREAKOUT IN1 IN2 IN3 IN4
Tabla 5–2. Conexiones de 28BYJ-48.
Para utilizar éste motor, ver el Anexo I, donde se vé su código.
Desarrollo y funcionamiento
52
5.1.2 Raspberry Pi 3
Para el desarrollo del código que se ha implementado en la Raspberry Pi 3, no se ha usado ningún IDE,
simplemente se han utilizado editores de texto propios del S.O. instalado en el dispositivo, el cual es Raspbian,
basado en Debian. La Raspberry Pi 3 es la que recibirá/enviará datos a/desde los sensores/nube. El código está
escrito en C++, por lo que se ha compilado con gcc.
La Raspberry Pi lee datos del nodo Kafka y reporta los datos a este. En este dispositivo se tienen dos ficheros,
el consumidor y el productor. El consumidor leerá los datos de Kafka y el productor se los enviará a este.
Productor
Cuando la Raspberry Pi recibe un paquete de un arduino que le está reportando inalámbricamente el valor de un
sensor, ésta parsea un fichero en formato json (Figura 5-5). Este fichero consiste en un mapeo del carácter que
le llega por parte de los Arduinos a un string el cual sea mas intuitivo para trabajar con él y así poder enviar los
datos a kafka con la cadena (y no con un simple char, aunque se podría).
{
"T": "temperatura",
"H": "humedad",
"L": "lluvia"
}
Figura 5-5. Fichero “types.json”.
Una vez hecho el mapeo, se envía un paquete a Kafka con el siguiente formato:
Campo Key Payload
Contenido ID dispositivo (raspberry-casa) Estructura de datos en formato
json
Figura 5-6. Formato de paquete Raspberry - Kafka.
El paquete anterior contiene el identificador que se le haya querido dar a la raspberry y una estructura en formato
json (ver Figura 5-7), que contiene un timestamp y los valores de los diferentes sensores. Este paquete, que se le
asociará un topic, será enviado a Kafka (en este caso, sólo habrá un topic llamado metrics)
{
"humedad" : 50.0,
"lluvia" : 0.0,
"temperatura" : 19.0,
"timestamp" : "1480253414"
}
Figura 5-7. Payload de paquete Raspberry-Kafka.
53 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
Consumidor
Cuando la Raspberry lee del nodo Kafka, leerá todos los mensajes que pertenezcan al mismo topic (en este caso
se leen los mensajes pertenecientes al topic actions). Estos mensajes tienen formato json y se encuentran en la
cola Kafka. En el contenido del mensaje se encuentran la dirección del arduino y del sensor sobre el que se
quiere actuar, y el valor de la actuación (On/Off). Notese que los mensajes que se consumen son todos
actuaciones sobre los arduino, y que dentro del contenido del mensaje se están introduciendo las direcciones de
los dispositivos oportunos. Se puede ver un ejemplo de mensaje en la Figura 5-8.
{
"DEV":"031",
"SENSOR":"B",
"STATE":"ON"
}
Figura 5-8 Mensaje Kafka-Raspberry.
Se puede observar como al leer este mensaje, la raspberry mandaría un mensaje mediante el NRF24L01+ al
Arduino cuya dirección es la 031. La orden sería la de encender el led azul. No obstante, para poder realizar las
acciones de una forma mas intuitiva, se ha creado un fichero llamado dispositivos .json cuya función consiste
en tener un mapeo de las direcciones de los dispositivos sobre los que se quiere actuar con un nombre que los
identifique unívocamente.
{
"ventana": "041",
"aire": "031"
}
Figura 5-9. Fichero “dispositivos.json”.
Así, cuando la Raspberry lea un mensaje de Kafka para actuar sobre el dispositivo aire, ésta leerá el json y
enviará al Arduino cuya dirección es la 031, un mensaje a través de su NRF24l01+ con un payload el cual
consiste en una estructura con forma del que recibe el Arduino nº2.
El código de consumidor y productor se encuentra en el Anexo II.
Librerías y módulos
Para poder trabajar con los pines de la Raspberry Pi, es necesario activar el modulo SPI (Serial Peripheral
Interface). SPI es un estándar para controlar casi cualquier dispositivo electrónico digital que acepte un flujo de
bits serie regulado por un reloj. Por tanto, es necesaria su activación en la Raspberry, la cual se explica a
continuación:
• Introducir el siguiente comando:
sudo raspi-config
• Actualizar la herramienta mediante el menú, tal como se indica.
• Seleccionar Advanced y enable the SPI kernel module
• Actualizar otro software y librerias:
Desarrollo y funcionamiento
54
sudo apt-get update
sudo apt-get upgrade
Una vez realizados los pasos anteriores, ya estará activado el módulo SPI tras reiniciar la Raspberry Pi. Sólo
falta instalar los drivers. La Raspberry Pi incluye por defecto el driver BCM2835 [40] y sólo será necesario
instalarlo mediente el siguiente comando:
sudo make install -B
Se pueden realizar otro tipo de construcciones con MRAA o SPIDEV, pero es necesario realizar más pasos de
configuración y descargarse paquetes adicionales.
A continuación, se explicará cómo instalar las librerías necesarias para el manejo del NRF24L01+ a través de
la Raspberry Pi. Se instalarán las librerías nrf24 y nrf24Network, cuyos objetivos se describen en el apartado
anterior. En las siguientes líneas se presentan las instrucciones para instalar estas librerías en la Raspberry Pi:
RPi-RF24
• Crear un directorio que contendrá las librerías RF24 y RF24Network y acceder a él:
mkdir ~/rf24libs
cd ~/rf24libs
• Clonar el repo RF24
git clone https://github.com/tmrh20/RF24.git RF24
• Cambiar al Nuevo directorio RF24:
cd RF24
• Construir la librería, y ejecutar un fichero de ejemplo
sudo make install
cd examples_RPi
make
sudo ./gettingstarted
RPi-RF24Network
• Entrar en el mismo directorio que contiene la carpeta de la librería RF24
cd ~/rf24libs
• Clonar el repo RF24Network
git clone https://github.com/tmrh20/RF24Network.git RF24Network
• Copiar la carpeta RF24Network al directorio actual, y borrar el resto
cd RF24Network
• Construir la librería
sudo make install cd examples_RPi make sudo ./helloworld_rx OR sudo ./helloworld_tx
La información de conexión es la siguiente:
Se usa el ping 15/GPIO22 de la raspberry para el CE del NRF24l01+ y el pin 27/GPIO8(CE0) para el CSN. Esta
55 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
configuración se declarará en los ficheros de la Raspberry Pi que usen el NRF24L01+ de esta forma:
RF24 radio(RPI_V2_GPIO_P1_15, BCM2835_SPI_CS0, BCM2835_SPI_SPEED_8MHZ);
Nótese que se puede configurar la velocidad del bus SPI, aunque se han dejado los 8MHz que vienen por defecto.
En las siguientes imágenes, se presentan tanto los pines físicos como los pines GPIO de la Raspberry Pi 3.
Posteriormente en la Tabla 5-3 se presentan el mapeo de conexiones entre el NRF24L01+ y la Raspberry Pi 3,
tomando como referencia la Figura 5-10 y las Figura 5-11.
Figura 5-10. Pines físicos Raspberry Pi.
Figura 5-11. Pines GPIO de la Raspberry Pi.
PIN NRF24L01+ RPI RPi-Pines físicos
1 GND rpi-gnd (25)
2 VCC rpi-3v3 (17)
3 CE rpi-gpio22 (15)
4 CSN rpi-gpio8 (24)
5 SCK rpi-sckl (23)
6 MOSI rpi-mosi (19)
7 MISO rpi-miso (21)
Desarrollo y funcionamiento
56
8 IRQ Not Connected
Tabla 5–3. Conexión Raspberry Pi con NRF24L01+.
La siguiente librería es la que permite la comunicación entre la Raspberry y el nodo Kafka de la nube. En la
siguiente sección se hará mayor hincapié en la parte de Kafka.
Librdkafka [41]: librdkafka es una librería implementada en C del protocolo Apache Kafka, la cual contiene el
soporte para el Consumidor y para el Productor. Ha sido diseñada con la intención de tener una gran fiabilidad
y alto rendimiento en el envio de mensajes. Actualmente se alcanzan cuotas de mas de 1 millón de mensajes por
segundo para el productor y 3 millones de mensajes por segundo para el consumidor. Librdkafka también
proporciona una interfaz nativa de C++ (es la que usaremos, ya que el código está en este lenguaje).
Las instrucciones para usar esta librería son las siguientes:
• Construcción
./configure
make
sudo make install
• Uso en código: Al compilar, añadir las siguientes opciones.
-lrdkafka++
A continuación, se presenta un ejemplo básico usando ésta librería.
Productor
//Creación del productor
RdKafka::Producer *producer = RdKafka::Producer::create(conf, errstr);
//Creación del topic
RdKafka::Topic *topic = RdKafka::Topic::create(producer, topic_str,
tconf, errstr);
//Producción del mensaje
producer->produce(topic, partition, RdKafka::Producer::RK_MSG_COPY /*
Copy payload */, const_cast<char *>(line.c_str()),
line.size(), NULL, NULL);
producer->poll(0);
Consumidor
//Creación del consumidor
RdKafka::Consumer *consumer = RdKafka::Consumer::56réate(conf, errstr);
//Creación del topic
RdKafka::Topic *topic = RdKafka::Topic::create(consumer, topic_str,tconf,
errstr);
//Comienzo del consumidor
57 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
consumer->start(topic, partition, start_offset);
//Consumición del mensaje (topic, partición y offset)
RdKafka::Message *msg = consumer->consume(topic, partition, 1000);
msg_consume(msg, NULL);
consumer->poll(0);
Ahora ya está todo listo en la Raspberry Pi para el desarrollo del escenario planteado.
5.1.3 Cloud
A continuación, se presentan las reglas del CEP que se han usado para el escenario creado y lo que implican
cada una de ellas:
"id": "aireRule",
"version": 2,
"input": ["metrics"],
"output": { "outputStream": "actions" },
"executionPlan":
"from metrics#window.timeBatch(5 min) select avg(temperatura) as avgTemperatura insert into avgMetrics;
from avgMetrics [avgTemperatura > 22] select 'ON' as STATE, 'aire' as DEV, 'B' as SENSOR insert into
outputStream;
from avgMetrics [avgTemperatura < 22] select 'OFF' as STATE, 'aire' as DEV, 'B' as SENSOR insert into
outputStream;
from avgMetrics [avgTemperatura < 19] select 'ON' as STATE, 'aire' as DEV, 'R' as SENSOR insert into
outputStream; from avgMetrics [avgTemperatura > 19] select 'OFF' as STATE, 'aire' as DEV, 'R' as SENSOR
insert into outputStream;"
}
Esta regla lee del topic metrics y el flujo de salida lo inserta en el topic actions. Con esta regla se hace una media
de la temperatura leída en una ventana de 5 minutos. Si la temperatura sobrepasa los 22 grados se enciende el
led azul (representaría una bajada de temperatura en el aire acondicionado). Si la temperatura es menor que 22
grados se apagaría el led azul, y si llega a bajar más de los 19 grados, se encendería el led rojo (representaría un
aumento de temperatura en el aire acondicionado). En el momento que supere los 19 grados el led rojo se
apagará.
{
"id": "motorRule",
"version": 2,
"input": ["metrics"],
"output": { "outputStream": "actions" },
"executionPlan":
"from metrics#window.timeBatch(5 min) select avg(lluvia) as avgLluvia insert into avgMetrics;
Desarrollo y funcionamiento
58
from avgMetrics [avgLluvia > 0] select 'ON' as STATE, 'ventana' as DEV, 'M' as SENSOR insert into
outputStream;
from avgMetrics [avgLluvia == 0] select 'OFF' as STATE, 'ventana' as DEV, 'M' as SENSOR insert into
outputStream;"
}
Esta regla lee del topic metrics y el flujo de salida lo inserta en el topic actions. Con esta regla se hace una media
de los valores obtenidos del sensor de lluvia (que es 1 ó 0) leidos en una ventana de 5 minutos. Si la media es
mayor que cero significa que en algún momento ha empezado a llover y por tanto se activará el motor (representa
a una ventana automática). Si la media es cero, significa que ha parado de llover y por tanto la ventana se abrirá.
En el Anexo IV se introducen los aspectos mas técnicos y ficheros de configuración necesarios, así como la
instalación de Kafka.
5.1.4 Dweet
Para poder enviar los datos que Kafka pida a Dweet y poder recibir las publicaciones que Kafka hace en este
datastore es necesario usar una librería en Node.js llamada node-dweetio.
Node-dweetio [46]: Este modulo de node.js permite la interacción con dweet.io. Para instalarlo via npm se ha
de ejecutar el siguiente comando:
npm install node-dweetio –save
A continuación, se presenta un ejemplo del envío y recepción de un dweet:
//Inicialización del cliente
var dweetClient = require(“node-dweetio”);
var dweetio = new dweetClient();
//Envío de un dweet con el nombre de la cosa
dweetio.dweet_for(“MI_COSA”, {some:”data”}, function(err, dweet){
console.log(dweet.thing); // “MI_COSA”
console.log(dweet.content); // Contenido del dweet
console.log(dweet.created); // Timestamp
});
//Get del ultimo dweet enviado por MI_COSA
dweetio.get_latest_dweet_for(“MI_COSA”, function(err, dweet){
var dweet = dweet[0]; // Un dweet es siempre una table de 1
console.log(dweet.thing); // El nombre de MI_COSA
console.log(dweet.content); // El contenido del dweet
console.log(dweet.created); // Fecha de creación del dweet
});
59 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
El modo publicador/suscriptor sería asi:
Publicador/Suscriptor
//En escucha de todos los dweets de una cosa.
Dweetio.listen_for(“MI_COSA”, function(dweet){
// Acción deseada
});
//Parar de escuchar dweets de una cosa.
Dweetio.stop_listening_for(“MI_COSA”);
//Parar de escuchar todos los dweet de cualquier cosa
dweetio.stop_listening();
Con esta librería ya se tiene el nodo Kafka listo para soportar lacomunicación via RESTful con Dweet.io
5.1.5 Telegram App
Los bots permiten hacer muchas cosas, pero en ete caso será útil para reportar el estado de los sensores de la red
vía Telegram y actuar sobre ellos. Se ha utilizado una librería para crear bots de Telegram escrita en Node.js. Se
valoró también la creación de estos con Ruby, pero se decidió realizar con Node debido a que tenía mejor
puntuación en GitHub.
Telegram-node-bot [48]: Se trata de un módulo muy potente para la creación de bots de Telegram. Para
instalarlo se ha de introducir la siguiente línea en el terminal:
npm install –save telegram-node-bot
En primer lugar, se necesita crear un bot y obtener el token. Este token se obtiene escribiéndole (via Telegram)
al llamado @BotFather, el cual lo devolverá. Con esto ya se tiene el bot legitimado por Telegram e identificado.
A continuación, se va a escribir un bot simple para que se vea un ejemplo básico de cómo funciona esto.
‘use strict’
//Inicialiación del bot
const Telegram = require(‘telegram-node-bot’)
const TelegramBaseController = Telegram.TelegramBaseController
const TextCommand = Telegram.TextCommand
const tg = new Telegram.Telegram(‘TOKEN’)
//Clase a la que se accede cuando un usuario escribe ping en el bot
class PingController extends TelegramBaseController {
/**
* @param {Scope} $
*/
pingHandler($) {
$.sendMessage(‘pong’)
}
Desarrollo y funcionamiento
60
get routes() {
return {
‘pingCommand’: ‘pingHandler’
}
}
}
//Aquí se trata el mensaje que se escribe en el bot (si escribe ping
ejecuta una acción determinada
tg.router
.when(
new TextCommand(‘ping’, ‘pingCommand’),
new PingController()
)
Figura 5-12. Bot de Telegram.
5.1.6 Scripts en la cloud
Para cerrar esta sección se van a explicar dos scripts los cuales aportan toda la lógica que se necesita para que el
escenario actue como se desea. El código de estos dos scripts se encuentra en el Anexo III
En primer lugar, se detallará el funcionamiento del archivo kafka2dweet.js y posteriormente del archivo
telegram2dweet.js
kafka2dweet.js
Este fichero se encarga de escribir los mensajes de Kafka en dweet con un topic determinado. Es el que permite
que todos los reportes que la Raspberry hace a Kafka de los valores de sus sensores, sean enviados a dweet con
el topic metrics para su posterior consumo por parte de Telegram.
61 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
telegram2dweet.js
Este fichero se encarga de crear un bot de Telegram el cual puede o leer de dweet o escribir en Kafka. Este
fichero permite la creación de un teclado que aparece en Telegram con las medidas que se quieran obtener (ver
Figura 5-13)
Figura 5-13. Teclado Telegram.
Al pulsar algún botón, se envía un mensaje a dweet para obtener la ultima medida que Kafka (mediante el script
anterior) insertó en el datastore.
Para acceder a ese teclado se ha de insertar la cadena /query en Telegram. Si se quiere actuar sobre algún sensor,
la orden a insertar es /action , donde el bot irá preguntando sobre los sensores de los dispositivos en los que se
quiere actuar y el valor de la actuación (dispositivo:aire o ventana, sensor: B, R o M para led azul, rojo o motor
y valor:on/off). Cuando se realiza una acción, realmente se está escribiendo en el nodo Kafka, del cual leerá la
Raspberry posteriormente (topic actions) y actuará de forma consecuente en los sensores.
5.2 Escenario final
En el siguiente diagrama, se representa la topología general, con todos los tipos de comunicaciones posibles y
con las tecnologías y dispositivos seleccionados. Se hara una explicación paso a paso por colores:
Naranja:
6. Envío de datos de los sensores de lluvia, humedad y temperatura de forma inalámbrica a través de los
NRF24L01+.
7. Recepción de los datos de los sensores por parte de la Raspberry Pi.
8. Escritura (vía Kafka Protocol) por parte de la Raspberry Pi en el nodo Kafka (situado en la nube - AWS)
de los datos de los sensores, asociandoles un topic.
9. Envío de eventos al Procesador de Eventos Complejos (vía Kafka Protocol) y al script (kafka2dweet)
encargado de escribir los datos en el datastore (Dweet).
10. Escritura de los datos en Dweet vía HTTPS.
Verde:
4. Escritura del CEP en un topic del nodo Kafka vía Kafka Protocol.
5. Lectura de la Raspberry Pi de Kafka (vía Kafka Protocol) y envío de los mensajes inalámbricamente a
los dispositivos (vía ShockBurst Protocol).
6. Actuación (On/Off) sobre el led azul y el motor.
Desarrollo y funcionamiento
62
Amarillo:
6. Envío de actuación sobre los sensores (ControlSensors) al Bot de Telegram vía HTTPS
7. Escritura en Kafka (vía Kafka Protocol) de la orden a ejecutar asociada a un topic.
8. Lectura de la Raspberry Pi (vía Kafka Protocol) del topic en cuestión.
9. Comunicación inalámbrica entre Arduino y Raspberry Pi vía ShockBurst Protocol.
10. Actuación (On/Off) sobre el led rojo.
Azul:
5. Envío de petición de datos (/query) por parte de Telegram App (vía HTTPS) al Bot de Telegram.
6. Envío de la petición de datos al servicio Dweet por parte del Bot de Telegram (via HTTPS).
7. Respuesta de dweet con los datos requeridos (vía HTTPS).
8. Respuesta del Bot de Telegram a Telegram App con los datos solicitados (via HTTPS).
En el Anexo IV se explican los pasos necesarios para ejecutar todos los programas (y sus ficheros de
configuración)
63 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
Figura 5-14. Escenario final.
Desarrollo y funcionamiento
64
5.3 Desarrollo y funcionalidad de la solución (Casos de Uso)
En este apartado se presentarán dos casos de uso reales:
Aire Acondicionado.
Este caso de uso se basa en un climatizador, donde se medirá la temperatura de una habitación y en función de
ésta se irá aumentando o disminuyendo la temperatura de un aire acondicionado representado por dos leds, el
rojo para el aumento de la temperatura y el azul para la bajada.
En primer lugar, se mide la temperatura del sensor DHT11.
Figura 5-15. Lectura de temperatura del DHT11.
El sensor es el aparato celeste de la derecha. La medida que toma este sensor se envía al arduino (placa azul de
la izquierda), que está tomando datos continuamente de este y enviándoselos a la Raspberry Pi mediante la
antena NRF24L01+ (placa negra de abajo a la izquierda). La Rapsberry envía los datos recibidos a Kafka
mediante el productor de ésta. En la nube, el CEP lee de Kafka y procesa los datos en función de sus reglas.
Cuando la temperatura pasa de los 22ºC se pone la orden de enceder el led azul (disminuir temperatura en el aire
acondicionado) en el nodo Kafka con el topic actions. Al leer la raspberry de Kafka mediente el consumidor,
ésta manda la orden a otro Arduino (encargado de los leds) mediante NRF24L01+ y éste encenderá el led azul
automáticamente.
65 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
Figura 5-16. Encendido automatizado de led azul.
Del mismo modo que se ha explicado antes, se encenderá el led rojo (aumentar temperatua en el aire
acondicionado) cuando la temperatura baje de los 22ºC y le lleguen los datos al CEP.
Figura 5-17. Encendido automático de led rojo.
Cuando la temperatura alcanza los 22ºC los dos leds permanecerán apagados. Se presupone que la temperatura
actual es la que se quería tener en la habitación, por tanto, el CEP no realiza ninguna acción.
Desarrollo y funcionamiento
66
Ventana
En este caso, se medirá si está lloviendo o no, y en función de ese valor, se abrirá o no la ventana de la casa, la
cual está representada por un motor.
En primer lugar, se plantea el escenario en el que no está lloviendo y la ventana está cerrada. Por tanto, el sensor
de lluvia (aparato de abajo en la figura 5-18) reportará su estado al arduino y éste a la raspberry mediante la
antena. La raspberry (el productor) escribe en Kafka en el topic metrics, del cual leerá el CEP y ésta al revisar
sus reglas, insertará en Kafka en el topic actions la acción de encender el motor (que representa a la ventana).
Entonces, la raspberry (el consumidor) tomará la acción a realizar y se la enviará inalámbricamente al arduino,
que será el encargado de decirle al motor (aparato de la izquiera en la figura 5-19) que se active en el sentido
correcto para abrir la ventana.
Figura 5-18. Sensor de lluvia inactivo.
Figura 5-19. Activación de motor emulando apertura de ventana.
67 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
La siguiente situación que se plantea es cuando ha empezado a llover y la ventana está abierta. Por tanto, el
sensor de lluvia reportara su estado al arduino y éste a la raspberry inalámbricamente. La raspberry (el productor)
escribe en Kafka en el topic metrics, del cual leerá el CEP y éste al revisar sus reglas, insertará en Kafka en el
topic actions la acción de encender el motor (que representa a la ventana). Entonces, la raspberry (el consumidor)
tomará la acción a realizar y se la enviará inalámbricamente al arduino, que será el encargado de decirle al motor
(aparato de la izquiera en la figura 5-120) que se active en el sentido correcto para cerrar la ventana.
Figura 5-20. Sensor de lluvia activo.
Figura 5-21. Activación del motor emulando cierre de ventana.
Desarrollo y funcionamiento
68
Para el control del motor, se ha usado un sensor de paso realizado con leds infrarrojos (leds de la izquierda en
laplaca de la figura 5-21). Este sensor de paso hace que el motor se pare cuando la ventana llegue al final o al
principio del marco. Además, este sensor también controla el estado actual del motor para que éste no actúe en
situaciones no deseadas. El bolígrafo que aparece en la Figura 5-21, emula el marco de la ventana (cuando la
ventana llega al fin o al principio).
69
6 CONCLUSIONES
Qué desperdicio de talento. Él eligió el dinero en vez del poder, un error que
casi todos cometen. Dinero es la gran mansión en Sarasota que empieza a
caerse a pedazos después de diez años. Poder es el viejo edificio de roca que
resiste por siglos. No puedo respetar a alguien que no entienda la diferencia.
Frank Underwood
n este capítulo se van a comentar las conclusiones obtenidas a partir del desarrollo de este proyecto. En
primer lugar, destacar que las tecnologías o dispositivos que se escojan para un determinado escenario, no
son soluciones únicas. Siempre habrá una tecnología o dispositivo alternativos.
En este proyecto en particular, se ha implementado una red local en estrella, sin embargo, se podría haber
planteado una red en árbol mucho mas barata que las de ZigBee gracias a la implementación de una librería de
NRF24L01+ en concreto.
Queda patente que la comunidad que respalda al mundo del IoT es muy grande y está en continuo crecimiento.
Esto hace posible que, con unos conocimientos básicos de electrónica, se puedan realizar grandes redes de
sensores y a muy buen precio. No obstante, para tener comunicaciones de alta calidad sí se puede apreciar el
salto de coste en los dispositivos. Obviamente, el incremento del coste hace de la red un entorno con
comunicaciones mas fiables, aunque no siempre existe una relación proporcional coste-calidad como se ha
comentado anteriormente. Siempre hay alternativas de bajo coste.
Con respecto a las tecnologías en la nube (Apache Kafka, Dweet.io y Telegram), son altamente escalables y
gratuitas. El uso de cola de mensajes para las peticiones resulta muy útil, ya que ante caídas puntuales se pueden
retomar los mensajes desde donde se dejaron. Con Telegram App se ha conseguido una interfaz para envío de
peticiones HTTP basada en la nube que tiene Telegram implementada. Esto, junto al nodo de Kafka en AWS
permiten tener acceso a la red local desde cualquier punto del mundo.
Por último, destacar la infinidad de mejoras que se le pueden hacer a este tipo de redes. No existe un techo visible
que se pueda alcanzar al realizar una red de sensores. Siempre se tiene margen de mejora, tanto como se quiera
invertir en tecnología y tiempo.
A continuación, se presentan algunas posibles mejoras pensadas durante la realización de este proyecto.
6.1 Líneas futuras
Se han pensado algunas líneas futuras para mejorar el proyecto, tanto a nivel de topología, como de tecnologías.
A pesar de que se ha presentado una topología en estrella, se podría realizar una red en árbol (típica de ZigBee)
con un coste mucho menor gracias a los NRF24L01+ y a la librería RF24Network [49]. A continuación, se
puede observar una topología de ejemplo, la cual está totalmente probada y funciona a la perfección.
E
Conclusiones
70
Figura 6-1. Topología en árbol.
Otra mejora posible podría ser la fácil detección de nodos nuevos en la red local. Actualmente hay que tocar
código en la raspberry para añadir la dirección a los Arduino para que puedan interactuar con esta. La idea
consiste en que los Arduinos que se conecten por primera vez a la red, anuncien un identificador basado en algun
parámetro físico del dispositivo a la raspberry y ésta pueda añadirlo automáticamente a su lista de dispositivos
conocidos.
También se plantea el cambio del datastore por una BBDD propia, que permitirera un mayor compendio de
funcionalidades. Además, se podría personalizar la interfaz del Bot de Telegram para que sea aún mas intuitiva.
71
ANEXO I
A continuación, se presenta el código del Arduino nº 1:
sensores.ino
/*
Fichero de Arduino que recoge los datos de los sensores
*/
//Librerías necesarias
#include <RF24Network.h>
#include <RF24.h>
#include <SPI.h>
#include <DHT11.h>
#include <stdio.h>
#include <stdlib.h>
int pin3=3;
int pin=2;
DHT11 dht11(pin);
RF24 radio(7,8); //Pines del NRF24
RF24Network network(radio);
const uint16_t this_node = 01; // Direccion de este node
const uint16_t other_node = 00; // Dirección de la raspberry
const unsigned long interval = 2000; //ms
// Estructura del payload
struct payload_t {
char tipo[4];
float valor;
};
Anexo I
72
void setup(void)
{
//Inicializaciones
Serial.begin(57600);
pinMode(pin3, INPUT);
SPI.begin();
radio.begin();
network.begin(/*canal*/ 90, /*direccio de este nodo*/ this_node);
}
void loop() {
network.update(); //Comprueba la red regularmente
/Variables
unsigned long now = millis();
int err;
float temp, humi,lluvif;
int lluvi;
char temperatura[10]={0};
char humedad[10]={0};
char lluvia[10]={0};
//Lectura de humedad y temperatura
if((err=dht11.read(humi, temp))==0)
{
sprintf(humedad,"%f",humi);
sprintf(temperatura,"%f",temp);
if ( now - last_sent >= interval )
{
last_sent = now;
//Lectura de lluvia
lluvi=digitalRead(pin3);
//Paso de float a int
73 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
lluvi=!lluvi;
if (lluvi==0)
lluvif=0.0;
else
lluvif=1.0;
sprintf(lluvia,"%f",lluvi);
//Envío de datos
payload_t payload = { "H", humi};
RF24NetworkHeader header(/*to node*/ other_node);
bool ok = network.write(header,&payload,sizeof(payload));
delay(10000);
payload_t payload2 = {"T",temp};
RF24NetworkHeader header2(/*to node*/ other_node);
bool ok2 = network.write(header2,&payload2,sizeof(payload2));
delay(10000);
payload_t payload3 = {"L",lluvif};
RF24NetworkHeader header3(/*to node*/ other_node);
bool ok3 = network.write(header3,&payload3,sizeof(payload2));
delay(10000);
}
}
}
Anexo I
74
Código de Arduino nº 2:
aire.ino
#include <RF24Network.h>
#include <RF24.h>
#include <SPI.h>
#include <printf.h>
//** Definiciones **//
RF24 radio(7,8);
RF24Network network(radio);
const uint16_t this_node = 031;
struct payload_t {
char sensor;
char on_off;
};
int rojo=2; //definimos el valor del pin para el led rojo
int azul=3; //definimos el valor del pin para el led azul
//** Programa **//
void setup() {
pinMode(azul,OUTPUT); //declaramos el pin azul como salida
pinMode(rojo,OUTPUT); //declaramos el pin rojo como salida
Serial.begin(57600);
SPI.begin();
radio.begin();
radio.startListening();
network.begin(/*canal*/ 90, this_node);
}
void loop() {
network.update();
75 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
//Ejecutar mientras la red este disponible
while ( network.available() ) {
RF24NetworkHeader header;
payload_t payload;
network.read(header,&payload,sizeof(payload));
Serial.println(payload.sensor);
Serial.println(payload.on_off);
if(payload.sensor=='R'){
if(payload.on_off=='1'){
digitalWrite(rojo,HIGH); //encendemos el led rojo
}else{
digitalWrite(rojo,LOW);
}
}
if(payload.sensor=='B'){
if(payload.on_off=='1'){
digitalWrite(azul,HIGH); //encendemos el led azul
}else{
digitalWrite(azul,LOW);
}
}
}
}
Anexo I
76
Código para el Arduino nº 3
motor.ino
#include <RF24Network.h>
#include <RF24.h>
#include <SPI.h>
#include <printf.h>
//definicion de pins
const int motorPin1 = 2; // 28BYJ48 In1
const int motorPin2 = 3; // 28BYJ48 In2
const int motorPin3 = 4; // 28BYJ48 In3
const int motorPin4 = 5; // 28BYJ48 In4
//definicion variables
int motorSpeed = 1200; //variable para fijar la velocidad
int stepCounter = 0; // contador para los pasos
int stepsPerRev = 4076; // pasos para una vuelta completa
int dif=1023;
int sensorValue = 0;
//tablas con la secuencia de encendido (descomentar la que necesiteis)
//secuencia 1-fase
//const int numSteps = 4;
//const int stepsLookup[4] = { B1000, B0100, B0010, B0001 };
//secuencia 2-fases
//const int numSteps = 4;
//const int stepsLookup[4] = { B1001, B1100, B0110, B0011 };
//secuencia media fase
const int numSteps = 8;
const int stepsLookup[8] = { B1000, B1100, B0100, B0110, B0010, B0011,
B0001, B1001 };
RF24 radio(7,8);
RF24Network network(radio);
const uint16_t this_node = 041;
77 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
struct payload_t {
char sensor;
char on_off;
};
void setup()
{
//declarar pines como salida
pinMode(motorPin1, OUTPUT);
pinMode(motorPin2, OUTPUT);
pinMode(motorPin3, OUTPUT);
pinMode(motorPin4, OUTPUT);
Serial.begin(115200);
SPI.begin();
radio.begin();
radio.startListening();
network.begin(/*canal*/ 90, this_node);
}
void loop()
{
sensorValue = analogRead(A1);
Serial.println(sensorValue);
Serial.println(dif);
network.update();
while ( network.available() ) {
RF24NetworkHeader header;
payload_t payload;
network.read(header,&payload,sizeof(payload));
//Si esta lloviendo y la ventana está abierta se cierra
if(payload.on_off=='1' && sensorValue!=dif){
digitalWrite(9,HIGH); //encendemos el led azul
dif=sensorValue-13;
for (int i = 0; i < stepsPerRev * 2; i++)
{
Anexo I
78
clockwise();
delayMicroseconds(motorSpeed);
}
}
//Si no esta lloviendo y la ventana está cerrada abrirla
else if (payload.on_off=='0' && sensorValue==dif ){
digitalWrite(9,LOW);
dif=sensorValue-13;
for (int i = 0; i < stepsPerRev * 2; i++)
{
anticlockwise();
delayMicroseconds(motorSpeed);
}
}
else
{
delay(1);
}
}
delay(1000);
}
void clockwise()
{
stepCounter++;
if (stepCounter >= numSteps) stepCounter = 0;
setOutput(stepCounter);
}
void anticlockwise()
{
stepCounter--;
79 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
if (stepCounter < 0) stepCounter = numSteps - 1;
setOutput(stepCounter);
}
void setOutput(int step)
{
digitalWrite(motorPin1, bitRead(stepsLookup[step], 0));
digitalWrite(motorPin2, bitRead(stepsLookup[step], 1));
digitalWrite(motorPin3, bitRead(stepsLookup[step], 2));
digitalWrite(motorPin4, bitRead(stepsLookup[step], 3));
}
Anexo I
80
81
ANEXO II
Código del consumidor:
consumer.cpp
/*CONSUMIDOR*/
/*Este codigo permite que la Raspberry Pi pueda consumir
los mensajes que le llegan desde el nodo Kafka que tenemos en
la nube*/
//Librerias necesarias para el manejo de cadenas, parseos JSON, manejo del
NRF24L01 y comunicacion con Kafka
#include <iostream>
#include <string>
#include <cstdlib>
#include <cstdio>
#include <csignal>
#include <cstring>
#include <ctype.h>
#include <algorithm>
#include <RF24/RF24.h>
#include <RF24Network/RF24Network.h>
#include <iostream>
#include <ctime>
#include <stdio.h>
#include <time.h>
#include <sstream>
#include <librdkafka/rdkafkacpp.h>
#include <csignal>
#include <jsoncpp/json/value.h>
#include <jsoncpp/json/json.h>
#include <fstream>
#ifndef _MSC_VER
#include <sys/time.h>
Anexo II
82
#endif
#ifdef _MSC_VER
#include "../win32/wingetopt.h"
#include <atltime.h>
#elif _AIX
#include <unistd.h>
#else
#include <getopt.h>
#include <unistd.h>
#endif
using namespace std;
// Configuracion pra GPIO 22 CE y CE1 CSN con velicidad SPI @ 8Mhz
RF24 radio(RPI_V2_GPIO_P1_15, RPI_V2_GPIO_P1_24, BCM2835_SPI_SPEED_8MHZ);
//Definicion del canal
RF24Network network(radio);
// Direccion de este nodo en formato Octal (01,021, etc)
const uint16_t this_node = 01;
const unsigned long interval = 2000; //ms
char switch_onoff = 0;
// Estructura del payload
struct payload_t {
char sensor;
char on_off;
};
//Definicion de variables
static bool run = true;
static bool exit_eof = false;
83 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
static int eof_cnt = 0;
static int partition_cnt = 0;
static int verbosity = 1;
static long msg_cnt = 0;
static int64_t msg_bytes = 0;
static void sigterm (int sig) {
run = false;
}
/**
* @Marca de tiempo en formato corto-String
*/
static void print_time () {
#ifndef _MSC_VER
struct timeval tv;
char buf[64];
gettimeofday(&tv, NULL);
strftime(buf, sizeof(buf) - 1, "%Y-%m-%d %H:%M:%S",
localtime(&tv.tv_sec));
fprintf(stderr, "%s.%03d: ", buf, (int)(tv.tv_usec / 1000));
#else
std::wcerr << CTime::GetCurrentTime().Format(_T("%Y-%m-%d
%H:%M:%S")).GetString()<< ": ";
#endif
}
//Case para tratamiento de eventos (error, estadisticas, log, etc.)
class ExampleEventCb : public RdKafka::EventCb {
public:
void event_cb (RdKafka::Event &event) {
print_time();
switch (event.type())
{
case RdKafka::Event::EVENT_ERROR:
std::cerr << "ERROR (" << RdKafka::err2str(event.err())
<< "): " << event.str() << std::endl;
if (event.err() == RdKafka::ERR__ALL_BROKERS_DOWN)
run = false;
Anexo II
84
break;
case RdKafka::Event::EVENT_STATS:
std::cerr << "\"STATS\": " << event.str() << std::endl;
break;
case RdKafka::Event::EVENT_LOG:
fprintf(stderr,"LOG-%i-%s: %s\n", event.severity(),
event.fac().c_str(), event.str().c_str());
break;
case RdKafka::Event::EVENT_THROTTLE:
std::cerr << "THROTTLED: " << event.throttle_time() <<
"ms by " << event.broker_name() << " id " <<
(int)event.broker_id() << std::endl;
break;
default:
std::cerr << "EVENT " << event.type() <<" (" <<
RdKafka::err2str(event.err()) << "): " <<
event.str() << std::endl;
break;
}
}
};
class ExampleRebalanceCb : public RdKafka::RebalanceCb {
private:
static void part_list_print (const
std::vector<RdKafka::TopicPartition*>&partitions)
{
for (unsigned int i = 0 ; i < partitions.size() ; i++)
std::cerr << partitions[i]->topic() <<"[" <<
partitions[i]->partition() << "], ";
std::cerr << "\n";
}
public:
void rebalance_cb (RdKafka::KafkaConsumer *consumer,
85 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
RdKafka::ErrorCode err,
std::vector<RdKafka::TopicPartition*>&partitions)
{
std::cerr << "RebalanceCb: " << RdKafka::err2str(err) << ": ";
part_list_print(partitions);
if (err == RdKafka::ERR__ASSIGN_PARTITIONS) {
consumer->assign(partitions);
partition_cnt = partitions.size();
} else {
consumer->unassign();
partition_cnt = 0;
}
eof_cnt = 0;
}
};
//Consumidor del mensaje
void msg_consume(RdKafka::Message* message, void* opaque) {
switch (message->err()) {
case RdKafka::ERR__TIMED_OUT:
break;
case RdKafka::ERR_NO_ERROR:
/* Mensaje real */
{
network.update();
Json::Value root; //Contendra el valor de root despues del
parseo.
Json::Reader reader;
Json::Value root2;
Json::Reader reader2;
bool parsing_ok = reader.parse(static_cast<const char
*>(message->payload()), root,
false);
if ( !parsing_ok )
{
// Reporta al usuario el fallo y en que lugar del
Anexo II
86
documento se encuentra.
std::cout << reader.getFormatedErrorMessages()<< "\n";
}
std::string sensor_id = root.get("SENSOR", "UTF-8" ).asString();
std::string state = root.get("STATE", "UTF-8" ).asString();
std::string device_id = root.get("DEV", "UTF-8" ).asString();
std::string str1 ("ON");
std::ifstream dispositivos("dispositivos.json",
std::ifstream::binary);
bool parseo_fichero_ok = reader2.parse(dispositivos, root2,
false);
if ( !parseo_fichero_ok )
{
// Reporta al usuario el fallo y en que lugar del
documento se encuentra
std::cout << reader2.getFormatedErrorMessages()<< "\n";
}
std::transform(device_id.begin(),device_id.end(),
device_id.begin(),::tolower);
std::string arduino = root2.get(device_id, "UTF-8" ).asString();
uint16_t other_node = std::stoi(arduino, nullptr, 0);
if (state.compare(str1) == 0) {
switch_onoff = '1';
} else {
switch_onoff = '0';
}
payload_t payload = {*sensor_id.c_str(), switch_onoff};
std::cout << payload.sensor << "\n";
std::cout << payload.on_off << "\n";
RF24NetworkHeader header(/*to node*/ other_node);
bool ok = network.write(header, &payload, sizeof(payload));
if (ok == 0) {
sleep(3);
87 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
network.write(header, &payload, sizeof(payload));
}
}
break;
case RdKafka::ERR__PARTITION_EOF:
/* Ultimo mensaje */
if (exit_eof && ++eof_cnt == partition_cnt) {
std::cerr << "%% EOF reached for all " << partition_cnt
<<" partition(s)" << std::endl;
run = false;
}
break;
case RdKafka::ERR__UNKNOWN_TOPIC:
case RdKafka::ERR__UNKNOWN_PARTITION:
std::cerr<<"Consume failed: "<<message->errstr()<< std::endl;
run = false;
break;
default:
/* Errores */
std::cerr<<"Consume failed: "<<message->errstr()<< std::endl;
run = false;
}
}
class ExampleConsumeCb : public RdKafka::ConsumeCb {
public:
void consume_cb (RdKafka::Message &msg, void *opaque) {
msg_consume(&msg, opaque);
}
};
int main (int argc, char **argv) {
Anexo II
88
// Inicializacion de los ajustes del NRF24L01
radio.begin();
delay(5);
network.begin(/*canal*/ 90, /*direccion del nodo*/ this_node);
radio.printDetails();
//Variables Kafka
std::string brokers = "localhost";
std::string errstr;
std::string topic_str;
std::string mode;
std::string debug;
std::vector<std::string> topics;
bool do_conf_dump = false;
int opt;
int use_ccb = 0;
/*
* Creacion de objetos de configuracion
*/
RdKafka::Conf *conf = RdKafka::Conf::create(RdKafka::Conf::CONF_GLOBAL);
RdKafka::Conf *tconf = RdKafka::Conf::create(RdKafka::Conf::CONF_TOPIC);
ExampleRebalanceCb ex_rebalance_cb;
conf->set("rebalance_cb", &ex_rebalance_cb, errstr);
//Tratamiento de parametros de ejecucion
while ((opt = getopt(argc, argv, "g:b:z:qd:eX:AM:f:qv")) != -1) {
switch (opt) {
case 'g':
if (conf->set("group.id",optarg,errstr)!=
RdKafka::Conf::CONF_OK)
{
std::cerr << errstr << std::endl;
exit(1);
}
break;
89 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
case 'b':
brokers = optarg;
break;
case 'z':
if (conf->set("compression.codec", optarg, errstr) !=
RdKafka::Conf::CONF_OK)
{
std::cerr << errstr << std::endl;
exit(1);
}
break;
case 'e':
exit_eof = true;
break;
case 'd':
debug = optarg;
break;
case 'M':
if (conf->set("statistics.interval.ms",optarg,errstr)!=
RdKafka::Conf::CONF_OK)
{
std::cerr << errstr << std::endl;
exit(1);
}
break;
case 'X':
{
char *name, *val;
if (!strcmp(optarg, "dump")) {
do_conf_dump = true;
continue;
}
name = optarg;
if (!(val = strchr(name, '=')))
{
std::cerr<<"%% Expected -X property=value,not"<<
Anexo II
90
name << std::endl;
exit(1);
}
*val = '\0';
val++;
/* Intentar "topic." */
RdKafka::Conf::ConfResult res = RdKafka::Conf::CONF_UNKNOWN;
if (!strncmp(name, "topic.", strlen("topic.")))
res = tconf->set(name + strlen("topic."), val, errstr);
if (res == RdKafka::Conf::CONF_UNKNOWN)
res = conf->set(name, val, errstr);
if (res != RdKafka::Conf::CONF_OK) {
std::cerr << errstr << std::endl;
exit(1);
}
}
break;
case 'f':
if (!strcmp(optarg, "ccb"))
use_ccb = 1;
else {
std::cerr << "Unknown option: " << optarg << std::endl;
exit(1);
}
break;
case 'q':
verbosity--;
break;
case 'v':
verbosity++;
break;
91 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
default:
goto usage;
}
}
for (; optind < argc ; optind++)
topics.push_back(std::string(argv[optind]));
if (topics.empty() || optind != argc) {
usage:
fprintf(stderr,
"Usage: %s -g <group-id> [options] topic1 topic2..\n"
"\n"
"librdkafka version %s (0x%08x)\n"
"\n"
" Options:\n"
" -g <group-id> Consumer group id\n"
" -b <brokers> Broker address (localhost:9092)\n"
" -z <codec> Enable compression:\n"
" none|gzip|snappy\n"
" -e Exit consumer when last message\n"
" in partition has been received.\n"
" -d [facs..] Enable debugging contexts:\n"
" %s\n"
" -M <intervalms> Enable statistics\n"
" -X <prop=name> Set arbitrary librdkafka "
"configuration property\n"
" Properties prefixed with \"topic.\" "
"will be set on topic object.\n"
" Use '-X list' to see the full list\n"
" of supported properties.\n"
" -f <flag> Set option:\n"
" ccb - use consume_callback\n"
" -q Quiet / Decrease verbosity\n"
" -v Increase verbosity\n"
"\n"
"\n",
argv[0],
RdKafka::version_str().c_str(), RdKafka::version(),
Anexo II
92
RdKafka::get_debug_contexts().c_str());
exit(1);
}
/*
* Establecimiento de propiedades de configuracion
*/
conf->set("metadata.broker.list", brokers, errstr);
if (!debug.empty()) {
if (conf->set("debug", debug, errstr) != RdKafka::Conf::CONF_OK) {
std::cerr << errstr << std::endl;
exit(1);
}
}
ExampleEventCb ex_event_cb;
conf->set("event_cb", &ex_event_cb, errstr);
conf->set("default_topic_conf", tconf, errstr);
delete tconf;
if (do_conf_dump) {
int pass;
for (pass = 0 ; pass < 2 ; pass++) {
std::list<std::string> *dump;
if (pass == 0) {
dump = conf->dump();
std::cout << "# Global config" << std::endl;
} else {
dump = tconf->dump();
std::cout << "# Topic config" << std::endl;
}
for (std::list<std::string>::iterator it = dump->begin();
it != dump->end(); )
93 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
{
std::cout << *it << " = ";
it++;
std::cout << *it << std::endl;
it++;
}
std::cout << std::endl;
}
exit(0);
}
signal(SIGINT, sigterm);
signal(SIGTERM, sigterm);
/*
* Modo Consumidor
*/
/*
* Creacion de consumidor
*/
RdKafka::KafkaConsumer *consumer = RdKafka::KafkaConsumer::create(conf,
errstr);
if (!consumer) {
std::cerr << "Failed to create consumer: " << errstr << std::endl;
exit(1);
}
delete conf;
std::cout << "% Created consumer " << consumer->name() << std::endl;
/*
* Suscripcion a topics
*/
RdKafka::ErrorCode err = consumer->subscribe(topics);
if (err) {
std::cerr<< "Failed to subscribe to "<< topics.size() << " topics: "
Anexo II
94
<< RdKafka::err2str(err) << std::endl;
exit(1);
}
/*
* Consumo de menmsajes
*/
while (run) {
if (use_ccb) {
std::cerr << "Use callback: Not implemented" << std::endl;
break;
}
RdKafka::Message *msg = consumer->consume(1000);
msg_consume(msg, NULL);
delete msg;
}
#ifndef _MSC_VER
alarm(10);
#endif
/*
* Parada del consuimidor
*/
consumer->close();
delete consumer;
std::cerr << "% Consumed " << msg_cnt << " messages ("
<< msg_bytes << " bytes)" << std::endl;
RdKafka::wait_destroyed(5000);
return 0;
}
95 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
Código del productor:
producer.cpp
/*PRODUCTOR*/
/*Este codigo permite que la Raspberry Pi pueda producir
los mensajes hacia el nodo Kafka que tenemos en
la nube*/
//Librerias necesarias para el manejo de cadenas, parseos JSON, manejo del
NRF24L01 y comunicacion con Kafka
#include <RF24/RF24.h>
#include <RF24Network/RF24Network.h>
#include <iostream>
#include <ctime>
#include <stdio.h>
#include <time.h>
#include <string>
#include <sstream>
#include <librdkafka/rdkafkacpp.h>
#include <csignal>
#include <jsoncpp/json/value.h>
#include <jsoncpp/json/json.h>
#include <fstream>
using namespace std;
// Configuracion pra GPIO 22 CE y CE1 CSN con velicidad SPI @ 8Mhz
RF24 radio(RPI_V2_GPIO_P1_15, BCM2835_SPI_CS0, BCM2835_SPI_SPEED_8MHZ);
RF24Network network(radio);
// Direccion de este nodo en formato Octal (01,021, etc)
const uint16_t this_node = 00;
// Direccion del otro nodo
const uint16_t other_node = 01;
// Estructura del payload
Anexo II
96
struct payload_t {
char type[4];
float value = 0.00;
};
//Definicion de variables
static bool run = true;
static void sigterm (int sig) {
run = false;
}
std::string timestr(time_t t) {
std::stringstream strm;
strm << t;
return strm.str();
}
int main(int argc, char** argv)
{
// Configuracion NRF24
radio.begin();
delay(5);
network.begin(/*canal*/ 90, this_node);
radio.printDetails();
//Carga de fichero de mapeo
std::ifstream types_file("types.json", std::ifstream::binary);
Json::Value types;
types_file >> types;
cout << types;
Json::FastWriter fastWriter;
Json::Value myjson;
// Configuracion Kafka
std::string errstr;
std::string brokers = "52.214.6.80:9092";
std::string topic_str = "metrics";
int32_t partition = RdKafka::Topic::PARTITION_UA;
RdKafka::Conf *conf = RdKafka::Conf::create(RdKafka::Conf::CONF_GLOBAL);
97 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
RdKafka::Conf *tconf = RdKafka::Conf::create(RdKafka::Conf::CONF_TOPIC);
conf->set("metadata.broker.list", brokers, errstr);
signal(SIGINT, sigterm);
signal(SIGTERM, sigterm);
//Creacion del productor
RdKafka::Producer *producer = RdKafka::Producer::create(conf, errstr);
if (!producer) {
std::cerr << "Failed to create producer: " << errstr << std::endl;
}
std::cout << "% Created producer " << producer->name() << std::endl;
//Creacion del topic
RdKafka::Topic *topic = RdKafka::Topic::create(producer, topic_str, tconf,
errstr);
if (!topic) {
std::cerr << "Failed to create topic: " << errstr << std::endl;
}
std::time_t time_0 = time(nullptr);
//Ejecucion
while (run)
{
//Envio mientras la red esta disponible
network.update();
while ( network.available() ) {
RF24NetworkHeader header;
payload_t payload;
//Leemos el payload y lo guardamos en una cadena
network.read(header, &payload, sizeof(payload));
std::string type(payload.type);
std::ostringstream ss;
ss << payload.value;
std::string value(ss.str());
//Se parsea a un JSON
myjson[types[type].asString()] = payload.value;
Anexo II
98
myjson["timestamp"] = timestr(std::time(nullptr));
//Saca por pantalla el json obtenido
cout << myjson;
//Calcula la diferencia de tiempo entre lecturas y si
es mayor que 3 segundos envia una nueva lectura
printf("Diferencia de tiempo %d \n", (std::time(nullptr)) -
time_0);
if ((std::time(nullptr)) - time_0 > 3)
{
time_0 = time(nullptr);
std::string key = "raspberry-casa";
std::string jsonData_0 = fastWriter.write(myjson);
std::string jsonData = jsonData_0.substr(0,
jsonData_0.size()-1);
RdKafka::ErrorCode resp = producer->produce(topic,
partition, RdKafka::Producer::RK_MSG_COPY,
(char*)jsonData.c_str(), jsonData.length(),
key.c_str(), key.length(), NULL);
if (resp != RdKafka::ERR_NO_ERROR)
std::cerr << "% Produce failed: " <<
RdKafka::err2str(resp) << std::endl;
else
std::cout << "% Produced message("
<<jsonData.length()
<< " bytes)"<<std::endl;
producer->poll(0);
//limpio
}
}
delay(2000);
}
delete topic;
delete producer;
99 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
return 0;
}
Anexo II
100
101
ANEXO III
kafka2dweet.js
var Kafka = require('no-kafka');
var consumer = new Kafka.SimpleConsumer({'connectionString':
'52.214.6.80:9092'});
var dweetClient = require("node-dweetio");
var dweetio = new dweetClient();
var sleep = require('sleep');
var dataHandler = function (messageSet, topic, partition) {
messageSet.forEach(function (m) {
var json = JSON.parse(m.message.value.toString('utf8'));
dweetio.dweet_for(m.message.key.toString('utf8'), json,
function(err, dweet){if(err != undefined) console.log(err)});
sleep.sleep(5);
});
};
return consumer.init().then(function () {
return consumer.subscribe('metrics', dataHandler);
});
Anexo III
102
telegram2dweet.js
'use strict'
const Telegram = require('telegram-node-bot')
const TelegramBaseController = Telegram.TelegramBaseController
const TextCommand = Telegram.TextCommand
const tg = new
Telegram.Telegram('273793514:AAGQ8L2qXixlS6EazGeTJZ2ta8hmNldwB80')
var dweetClient = require("node-dweetio");
var dweetio = new dweetClient();
var kafka = require('kafka-node'),
HighLevelProducer = kafka.HighLevelProducer,
client = new kafka.Client(),
producer = new HighLevelProducer(client);
class QueryController extends TelegramBaseController {
/**
* @param {Scope} $
*/
queryHandler($) {
dweetio.get_latest_dweet_for("raspberry-casa", function(err, dweet){
if(err == null) {
var dweet = dweet[0]; // Dweet siempre es un array de 1
console.log(dweet.thing); // El nombre generado
console.log(dweet.content); // El contenido del dweet
console.log(dweet.created); // La fecha de creación del dweet
$.runMenu({
message: "Select measure to show!",
oneTimeKeyboard: true,
options: {
parse_mode: 'Markdown'
},
layout: 2,
'Temperature': () =>
{
$.sendMessage(dweet.content.temperatura)
},
'Humidity': () =>
{
103 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
$.sendMessage(dweet.content.humedad)
},
'Rain': () =>
{
$.sendMessage(dweet.content.lluvia)
}
})
} else {
console.log(err);
}
});
}
get routes() {
return {
'QueryCommand': 'queryHandler'
}
}
}
const form = {
dev: {
q: 'What is the device that you want to modify?',
error: 'sorry, wrong input',
validator: (message, callback) => {
if(message.text) {
callback(true, message.text) //you must pass the result also
return
}
callback(false)
}
},
sensor: {
q: 'What is the sensor that you want to modify?',
error: 'sorry, wrong input',
validator: (message, callback) => {
if(message.text) {
callback(true, message.text) //you must pass the result also
return
}
Anexo III
104
callback(false)
}
},
status: {
q: "What is the new status's sensor?",
error: 'Sorry, valid status: ON/OFF',
validator: (message, callback) => {
if(message.text &&
(message.text.toLowerCase() === 'on' ||
message.text.toLowerCase() === 'off'))
{
callback(true, message.text.toUpperCase())
return
}
callback(false)
}
}
}
class LedController extends TelegramBaseController {
/**
* @param {Scope} $
*/
ledHandler($) {
$.runForm(form, (result) => {
var data={DEV: result.dev,SENSOR: result.sensor,STATE: result.status}
var payload = [{ topic: 'actions', messages: JSON.stringify(data) }];
producer.send(payload, function (err, data) {
if(err != null) {
$.sendMessage("Your request wasn't processed correctly :(");
console.log(err);
}
else {
$.sendMessage('Your request was processed correctly :)');
}
});
})
105 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
}
get routes() {
return {
'LedCommand': 'ledHandler'
}
}
}
tg.router
.when(new TextCommand('/query', 'QueryCommand'), new QueryController())
.when(new TextCommand('/action', 'LedCommand'), new LedController())
Anexo III
106
107
ANEXO IV
En este apartado se explicará los pasos a seguir para la instalación y ejecución de los códigos anteriores.
1. Descargarse el IDE de Arduino de la página oficial. Una vez descargadop solo hay que elegir el puerto
serie al que está conectado y pulsar el botón de cargar que sale en la parte superior izquierda del menú.
2. Ejecutar los códigos del Anexo II en la Raspberry Pi.
• Compilación y ejecución del consumidor (cambiar por IP del nodo Kafka)
~]# g++ consumer.cpp -lrf24-bcm -lrf24network -lrdkafka++
-lstdc++ -std=gnu++0x -ljsoncpp -fpermissive -o consumer
~]# ./consumer -b 52.208.189.186:9092 -g test metrics
• Compilación y ejecución del productor
~]# g++ producer.cpp -lrf24-bcm -lrf24network -lrdkafka++
-lstdc++ -std=gnu++0x -ljsoncpp -o producer
~]# ./producer
3. Descargar e instalar node.js en el nodo de la nube.
~]# curl --silent --location https://rpm.nodesource.com/setup_6.x |
bash -
~]# yum -y install nodejs
~]# yum groupinstall 'Development Tools'
4. Descargar Kafka y CEP en el nodo de la nube
~]# wget http://apache.rediris.es/kafka/0.10.1.0/kafka_2.11-
0.10.1.0.tgz
~]# wget https://github.com/redBorder/cep/archive/master.zip
5. Ejecutar Zookeeper y Kafka en el nodo de la nube
~]# cd kafka_2.11-0.10.1.0/
~]# bin/zookeeper-server-start.sh -daemon config/zookeeper.properties
~]# bin/kafka-server-start.sh -daemon config/server.properties
Nótese que se ha de cambiar la IP en el fichero server. properties con la de la maquina donde se
encuentre el nodo Kafka.
6. A continuación, se han de instalar los dos scripts. Se instalan en el nodo de la nube.
~]# node kafka2dweet
~]# node telegram2dweet
Anexo IV
108
Si faltara alguna librería realizar los siguientes pasos:
~]# npm install no-kafka
~]# npm install node-dweetio
~]# npm install telegram-node-bot
~]# npm install kafka-node
7. Ejecutar CEP
~]# java -cp ./:cep-0.1.1-SNAPSHOT-selfcontained.jar
net.redborder.cep.CorrelationService config.yml &
Para añadir una regla…
~]# curl -X POST -H 'Content-Type: application/json' -d
@aireRule.json http://localhost:8888/v1
Cambiar aireRule.json por el nombre de la regla que se quiera añadir.
El fichero de configuración que se necesita para la ejecución se adjunta a continuación (modificar IP
oportunamente)
config.yml
rest_uri: http://localhost:8888
state_file: /root/cep/state.json
sources:
- name: kafka
class: net.redborder.cep.sources.kafka.KafkaSource
properties:
zk_connect: localhost:2181
kafka_brokers: 52.208.189.186:9092
sinks:
- name: kafka
class: net.redborder.cep.sinks.kafka.KafkaSink
properties:
kafka_brokers: 52.208.189.186:9092
parsers:
json: net.redborder.cep.sources.parsers.JsonParser
streams:
metrics:
source: kafka
parser: json
attributes:
timestamp: long
temperatura: double
109 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
humedad: double
lluvia: double
Anexo IV
110
111
REFERENCIAS
[1] R. Khan, S. U. Khan, S. Khan and R. Zaheer, "Future Internet: The Internet of Things Architecture, Possible
Applications and Key Challenges," in 10th International Conference on Frontiers of Information Technology,
2012.
[2] S. Kraijak and P. Tuwanut, "A survey on IoT architectures, protocols, applications, security, privacy, real-world
implementation and future trends," in 11th International Conference on Wireless Communications, Networking
and Mobile Computing, 2015.
[3] UIT-T-REC-Y.2060, "Descripción general de Internet de los objetos," 2012.
[4] "http://www.redbite.com/the-origin-of-the-internetof-things/," [Online].
[5] D. Evans, "Internet de las cosas Cómo la próxima evolución de Internet lo cambia todo".
[6] S. Jankowski, J. Covello, H. Bellini, J. Ritchie and D. Costa, "The Internet of Things: Making sense of the next
mega-trend," Goldman, Sachs & Co., 2014.
[7] M. Wu, T.-J. Lu, F.-Y. Ling, J. Sun and H.-Y. Du, "Research on the architecture of Internet of Things," in 3rd
International Conference on Advanced Computer Theory and Engineering (ICACTE), 2010.
[8] S. Vongsingthong and S. Smanchat, "INTERNET OF THINGS: A REVIEW OF APPLICATIONS &
TECHNOLOGIES".
[9] S. Chen, H. Xu, D. Liu, B. Hu and H. Wang, "A Vision of IoT: Applications, Challenges, and Opportunities With
China Perspective," IEEE Internet of Things Journal, vol. 1, no. 4, pp. 349-359, 2014.
[10] "National Instruments - ¿Qué es una Red de Sensores Inalámbricos?," 2009 Abril 22. [Online]. Available:
http://www.ni.com/white-paper/7142/es/.
[11] J.-S. Lee, Y.-W. Su and C.-C. Shen, "A Comparative Study of Wireless Protocols:Bluetooth, UWB, ZigBee, and
Wi-Fi," in The 33rd Annual Conference of the IEEE Industrial Electronics Society (IECON), Taipei, Taiwan, 2007.
[12] "DIGI-Connect with Confidence," [Online]. Available: http://www.digi.com/pdf/xbee-802-15-4-protocol-
comparison.
[13] C. G. J. O. and J. P. , "Overview and Evaluation of Bluetooth Low Energy: An Emerging Low-Power Wireless
Technology," Sensors, 2012.
[14] J. L. "Bluetooth® Low Energy Beacons," 2015-Revised October 2016.
[15] "Wikipedia," [Online]. Available: https://es.wikipedia.org/wiki/IEEE_802.15.4.
[16] L. W. and A. M. A. , "The Physical Layer of the IEEE 802.11p WAVE: Communication Standard: The
Specifications and Challenges," in Proceedings of the World Congress on Engineering and Computer Science, San
Referencias
112
Francisco, 2014.
[17] K. N. QURESHI and A. H. ABDULLAH, "TOPOLOGY BASED ROUTING PROTOCOLS FOR VANET AND
THEIR COMPARISON WITH MANET," Journal of Theoretical and Applied Information Technology, vol. 58,
no. 3, 2013.
[18] "Nordic Semiconductor- NRF24L01+," [Online]. Available:
https://www.nordicsemi.com/chi/content/download/2730/34105/file/nRF24L01_Product_Specification_v2_0.pdf.
[19] "Airspayce-NRF24," [Online]. Available: http://www.airspayce.com/mikem/arduino/NRF24/.
[20] "MySensors," [Online]. Available: https://forum.mysensors.org/topic/2005/software-aes-encryption-for-nrf24.
[21] C. Ai-ju and H. Yuan-juan , Medical Wireless Frequency Hopping Communication by nRF24L01, Springer.
[22] M. Lehsaini, Diffusion et couverture basées sur le clustering dans les réseaux de capteurs : application à la
domotique, 2009.
[23] T. Rappaport, Wireless Communications Principles and Practice, 2nd Edition ed., Prentice Hall, 2001.
[24] "Raspberry para torpes," [Online]. Available: https://raspberryparatorpes.net/hardware/rivales-raspberry-pi-c-h-i-
p-un-pc-por-9/.
[25] "Raspberry para torpes," [Online]. Available: https://raspberryparatorpes.net/hardware/raspberry-pi-3-model-b/.
[26] "Escuela Europea de Robótica," [Online]. Available: http://raspberryhack.com/feed/comparativa-y-benchmarks-
de-raspberry-pi-vs-odroid-vs-orange-pi-vs-m%C3%A1s.
[27] Joaquín, "AndroidPC," [Online]. Available: http://androidpc.es/blog/2016/03/14/review-raspberry-pi-3/2/.
[28] "Consumo de potencia de C.H.I.P.," [Online]. Available: https://bbs.nextthing.co/t/c-h-i-p-power-
consumption/1416/3.
[29] "CHIP," [Online]. Available: https://getchip.com/pages/chip.
[30] E. Brown, "HackerBoards.com," 22 Junio 2016. [Online]. Available: http://hackerboards.com/raspberry-pi-3-
takes-the-cake-in-2016-hacker-sbc-survey/.
[31] "Apache Foundation-Kafka Wiki," [Online]. Available:
https://cwiki.apache.org/confluence/display/KAFKA/Index.
[32] A. Gómez Ferrer and C. Rodríguez Reyes, "RESTful Complex Event Processor powered by Kafka & Siddhi,"
[Online]. Available: https://github.com/redBorder/cep.
[33] "WSO2- Complex Event Procesor," [Online]. Available:
https://docs.wso2.com/display/CEP410/SiddhiQL+Guide+3.0.
[34] "Dweet.io," [Online]. Available: https://dweet.io/.
[35] "Telegram APIs," [Online]. Available: https://core.telegram.org/api.
113 Diseño e implementación de una arquitectura IoT basada en tecnologías Open Source.
[36] S. Chakkor, M. Baghouri, C. El Ahmadi and A. Hajraoui, "Comparative Performance Analysis of Wireless
Communication Protocols for Intelligent Sensors and Their Applications," (IJACSA) International Journal of
Advanced Computer Science and Applications, vol. 5, no. 4, 2014.
[37] "Arduino IDE," [Online]. Available: https://github.com/arduino/Arduino/.
[38] "Aprendiendo Arduino," [Online]. Available: https://aprendiendoarduino.wordpress.com/tag/ide/.
[39] TMRh20, "Libreria RF24 - Arduino," [Online]. Available: https://github.com/TMRh20/RF24.
[40] TMRh20, "Optimized Network Layer for nRF24L01(+) Radios on Arduino," [Online]. Available:
https://github.com/TMRh20/RF24Network.
[41] "Prometec," [Online]. Available: http://www.prometec.net/sensores-dht11/.
[42] L. LLamas, "Tutoriales Arduino," [Online]. Available: http://www.luisllamas.es/2016/02/arduino-lluvia/.
[43] M. McCauley , "C library for Broadcom BCM 2835 as used in Raspberry Pi," [Online]. Available:
http://www.airspayce.com/mikem/bcm2835.
[44] M. Edenhill, "Librrería Kafka C y C++," [Online]. Available: https://github.com/edenhill/librdkafka.
[45] "Libreria Dweet-Kafka," [Online]. Available: https://github.com/buglabs/node-dweetio.
[46] N. Abovyan, "Telegram-node-bot," [Online]. Available: https://github.com/naltox/telegram-node-bot.
[47] "Newly Optimized RF24Network Layer," [Online]. Available:
https://tmrh20.github.io/RF24Network/Tuning.html.
[48] "Datasheet de BlueCore2," Cambridge Silicon Radio (CSR), [Online]. Available:
http://www.icbank.com/icbank_data/community/comm_tt/0049_BC2-EXTERNAL.pdf.
[49] "Datasheet de CC2430," Chipcon of Texas Instruments, [Online]. Available:
http://www.ti.com/lit/ds/symlink/cc2430.pdf.
[50] Conexant, Single-Chip WLAN Radio CX5311, Newport Beach, CA, 2006.
[51] "Datasheet de NRF24L01+," Nordic Semiconductor, [Online]. Available:
http://www.datasheet.es/PDF/906332/nRF24L01+-pdf.html.
[52] TMRh20, "Optimized High Speed NRF24L01+ Driver Class Documenation," [Online]. Available:
https://tmrh20.github.io/RF24/RPi.html.
[53] "Bluetooth-Bluetooth Core Specification," [Online]. Available:
https://www.bluetooth.com/specifications/bluetooth-core-specification.
[54] "RF Wireless World," [Online]. Available: http://www.rfwireless-world.com/Terminology/difference-between-
piconet-and-scatternet-in-bluetooth.html.