Sistema integrado basado en FiWare para la obtención y difusión de información de consumo y calidad de agua

Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Sistema integrado basado en FiWare para la obtención y difusión de información de consumo y calidad de agua Autor: Miguel Collado Quesada Tutor: Fernando Guerrero López e Ignacio Eguía Salinas Dpto. de Organización Industrial y Gestión de Empresa I Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2018 2 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Sistema integrado basado en FiWare para la obtención y difusión de información de consumo y calidad de agua Autor: Miguel Collado Quesada Tutor: Fernando Guerrero López e Ignacio Eguía Salinas Profesor titular Dpto. de Organización Industrial y Gestión de Empresa I Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2018 4 Proyecto Fin de Carrera: Sistema integrado basado en FiWare para la obtención y difusión de información de consumo y calidad de agua Autor: Miguel Collado Quesada Tutor: Fernando Guerrero López e Ignacio Eguía Salinas El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2018 El Secretario del Tribunal 6 A mi familia A mis amigos 8 Agradecimientos Debo de agradecer el hecho de haber llegado hasta aquí a mi familia. Especialmente, me gustaría agradecer a mis padres por todo haberlo hecho posible. A mi padre por imprimir en mi el tesón y el valor del esfuerzo. A mi madre por enseñarme que la perserverancia es la clave del éxito. A mis hermanos por estar en los buenos momentos y en los no tan buenos. A mis amigos y compañeros de trabajo por ayudarme en el proyecto, aportándome ideas y mejoras que sirvieron de utilidad. A mis tutores por todo lo aprendido gracias a hacer posible realizar este proyecto y contribuir en él. Miguel Collado Quesada Sevilla, 2018 16 ÍNDICE DE TABLAS Tabla 2–1 Diferencias IPv4 e IPv6 31! Tabla 2–2 Cabecera UDP 34! ÍNDICE DE FIGURAS Figura 2-1. Pilares IoT de conocimiento. 23! Figura 2-2. Crecimiento de numero de dispositivos. 24! Figura 2-3. Bluetooth 5.0. 25! Figura 2-4. Protocolo WiFi. 26! Figura 2-5. 802.11ax 26! Figura 2-6. LTE Cat M. 27! Figura 2-7. 802.3 en modelo OSI. 28! Figura 2-8. NB-IOT. 29! Figura 2-9. Cabecera IPv4 29! Figura 2-10. Arquitectura ZigBee. 32! Figura 2-11. Modelo 6LoWPAN 33! Figura 2-12 UDP 33! Figura 2-13. Cabecera TCP. 36! Figura 2-14. Protocolo MQTT. 37! Figura 2-15. Arquitectura DDS. 39! Figura 2-16. DTLS sobre UDP. 40! Figura 2-17. Plataforma FiWare. 41! Figura 2-18. Amazon Web Service IoT. 42! Figura 2-19. Google Cloud Platform IoT. 43! Figura 2-20. Microsoft Azure IoT. 44! Figura 2-21. IBM Watson. 44! Figura 3-1. Cloud Hosting. 48! Figura 3-2. Data/Context Management. 48! Figura 3-3. Interfaces to Network and Devices. 49! Figura 3-4. Advanced Web-Based User Interface 49! Figura 3-5. Security. 49! Figura 3-6. Internet Of Things. 50! Figura 3-7. Applications/Services and Data Delivery. 50! Figura 3-8. Árbol de Recursos NGSI-9 52! Figura 3-9. Árbol de Recursos NGSI-10 53! Figura 4-1. Arquitectura Plataforma Fiware 55! Figura 4-2. Arquitectura Orion Context Broker. 56! 18 Figura 4-3. Redundancia en Orion. 57! Figura 4-4. Agente IoT 60! Figura 4-5. Arquitectura Apache Flume. 61! Figura 5-1. Arquitectura de la solución. 65! Figura 5-2. Modelo Genérico Interfaz de Medida 66! Figura 5-3. Arquitectura Dispositivo Final. 67! Figura 5-4. Sondas de parámetros de calidad. 68! Figura 5-5. Medida de PH. 69! Figura 5-6. Muestra Medidas de PH. 70! Figura 5-7. Muestra Medidas de Oxígeno Disuelto. 71! Figura 5-8. Muestra Medidas de Conductividad Eléctrica. 72! Figura 5-9. Formula Calculo Temperatura. 72! Figura 5-10. Relación Temperatura-Resistencia. 73! Figura 5-11. Muestra Medidas de Temperatura. 73! Figura 5-12. Composición Interfaz de medida de parámetros de calidad. 74! Figura 5-13. Cadena de Datos Parámetros de Calidad. 75! Figura 5-14. Interfaz de medida de parámetros de calidad. 75! Figura 5-15. Código Interfaz de Medida de Parámetros de Calidad (I). 76! Figura 5-16. Código Interfaz de Medida de Parámetros de Calidad (II). 77! Figura 5-17. Interfaz de Medida de Consumo. 78! Figura 5-18. Muestra Medidas de Consumo. 78! Figura 5-19. Sensor de Presión. 79! Figura 5-20. Protocolo ZigBee 80! Figura 5-21. Topología en malla. 80! Figura 5-22. Módulo XBee PRO. 81! Figura 5-23. Configuración dirección XBee coordinador. 82! Figura 5-24. Método de transmisión de datos mediante XBee (I). 83! Figura 5-25. Método de transmisión de datos mediante XBee (II). 84! Figura 5-26. Router ZigBee. 85! Figura 5-27. Arquitectura Concentrador. 85! Figura 5-28. Fragmento Código Concentrador. 88! Figura 5-29. Concentrador Final. 88! Figura 5-30.Dockerfile Agente IoT. 89! Figura 5-31. Registro entidades calidad. 90! Figura 5-32. Registro Dispositivo Presión. 91! Figura 5-33. Docker Compose Orion Context Broker 92! Figura 5-34. Descripción canal. 93! Figura 5-35. Características Fuente (I). 93! Figura 5-36. Características Fuente (II). 93! Figura 5-37. Características Canal. 93! Figura 5-38. Características Sumidero. 94! Figura 5-31. Configuración Mapeo de nombres. 94! Figura 5-40. Interfaz Web Cliente. 96! Figura 5-41. Consumo Cliente. Conversión en Euros. 97! Figura 5-42. Comparativa de consumo de cliente. 97! Figura 5-43. Interfaz Web Distribuidora 98! Figura 5-44. Graficas parámetros de calidad (I). 98! Figura 5-45. Graficas parámetros de calidad (II) 99! 20 1 OBJETIVOS l principal objetivo de este Trabajo fin de Grado es el desarrollo y despliegue de una red de dispositivos productores de información y el uso final de esta información en aplicaciones que aporten valor al usuario. Todo esto se apoyará en la plataforma FiWare junto con sus componentes para conseguir una gestión que permita la flexibilidad tanto en los productores como consumidores de información, para permitir que estos puedan implementar protocolos heterogéneos y de distinta naturaleza. En nuestro caso, se integrarán los productores de información referentes a calidad y consumo de agua, para que puedan ser usados tanto para distribuidoras de agua y clientes finales, como para organismos públicos y otras entidades. Se estudiarán los diferentes componentes que forman la plataforma FIWARE para su aplicación en este determinado caso de uso. Al desplegar los componentes de la plataforma en el marco de la gestión de datos de agua, se buscará una gestión más eficiente del uso y abastecimiento del agua, así como información en tiempo real. La integración en tiempo real del abastecimiento de agua gracias a FIWARE, facilitará la detección de fugas de manera más precisa y rápida, facilitando la actuación sobre estas y su prevención. E Cuando es evidente que los objetivos no pueden ser logrados, no ajustes los objetivos, ajusta los pasos a seguir. - Confucio - 22 2 INTRODUCCIÓN n la actualidad, nos encontramos en un mundo globalizado donde abundan dispositivos de todo tipo y para diversos usos. Es por eso que surge la necesidad del uso de ecosistemas que permitan la integración de infinidad de datos heterogéneos en un sistema global, único y escalable. Gracias al avance de la tecnología y a la capacidad de recolección y uso de datos para todo tipo de negocios, se acuña el nombre de “Internet de las Cosas” como plataforma donde todos los objetos la vida cotidiana pueden interactuar y comunicarse a través de la red. A lo largo de este capitulo, se expondrá una definición del denomidado Internet de las Cosas, además de describir ciertos aspectos importantes de su historia hasta la actualidad y pasando por las diferentes tecnologías que lo hacen posible. 2.1 Introducción al Internet de las Cosas De acuerdo al IoT European Research Cluster [1] , Internet de las Cosas (IdC, en inglés IoT) es: "una infraestructura de red dinámica y global con capacidades de auto-configuración basada en protocolos de comunicación estándar y que operan entre sí donde las "cosas" físicas y virtuales tienen identidad, atributos físicos y personalidades virtuales utilizando interfaces inteligentes, siendo integradas a la perfección en la red de información". Otra definición extendida es: "la IoT es una infraestructura global para la sociedad de la información, habilitando servicios avanzados al interconectar (física y virtualmente) cosas basadas en el mundo real con modernas tecnologías de la información y comunicaciones. A través de la identificación, captura de datos y capacidades de comunicación y procesado, la IoT permite un uso pleno de los datos para ofrecer servicios a aplicaciones, a la misma vez de dotar de los requisitos de seguridad y privacidad pertinentes. Desde una perspectiva más amplia, la IoT puede ser percibida como una nueva visión con implicaciones tanto tecnológicas como sociales". La IoT se basa en tres pilares básicos de conocimiento (Figura 2-1): el diseño de las cosas (hardware), el diseño de la infraestructura de comunicación (telemática) y la toma de decisiones (semántica y de razonamiento). Así, el fenómeno de la IoT se encontraría en la zona de intersección de estas tres áreas. La tercera definición proviene de una infografía [2], que resume de una manera rápida y eficaz los conceptos básicos de esta tecnología: "los Sistemas Inteligentes (Smart Systems) y la IoT son impulsados por una combinación de (1) sensores y actuadores, (2) conectividad y (3) personas y procesos". De acuerdo con esta visión, los sensores y actuadores crean un sistema nervioso digital y, gracias a las conexiones, se habilita la disponibilidad de los datos que son transmitidos, almacenados, combinados y analizados entre sistemas que integran datos, personas, procesos y otros sistemas. Aunque menos formal, esta última es una definición simple y clara que aborda los tres principios fundamentales de la IoT: las cosas, las conexiones y los procesos. E Estamos demasiado acostumbrados a atribuir a una sola causa lo que es el producto de varias, y la mayoría de nuestras controversias proceden de eso. - Marco Aurelio - Figura 2-1. Pilares IoT de conocimiento. 2.2 Historia del Internet de las Cosas Para ponernos en contexto, tendríamos que remontarnos a 1926 para hablar del gran Nikola Tesla cuyas patentes y trabajos teóricos conformaron la base de las comunicaciones inalámbricas y de radio. El origen del Internet de las Cosas data del año 1969 cuando la red ARPANET [3] estableció comunicación entre las universidades de Stanford y Ucla, permitiendo no sólo el desarrollo de la IoT, sino de Internet propiamente dicho, la red de redes que actualmente conocemos y utilizamos diariamente. Diez años después se probó el TCP/IP, los protocolos de red en los que se basa Internet y que permiten la transmisión de datos entre computadoras. En 1990 Berners-Lee implementó la primera comunicación exitosa entre un cliente Hypertext Transfer Protocol (HTTP) y un servidor a través de Internet, había inventado la World Wide Web. Él mismo, un año más tarde, creó la primera página web. A partir de ese momento el desarrollo tecnológico es vertiginoso, comienza la revolución de Internet. En el año 1990 Jhon Romkey y Simon Hacket [4] desarrollaron el primer objeto con conexión a Internet, la primera "cosa" con capacidad de manejo remoto. Esa "cosa" fue una tostadora inteligente que podía controlarse remotamente a través de cualquier ordenador, pudiendo encenderla, apagarla o incluso controlar el tiempo de tostado. La primera aparición del IoT como hoy se conoce procede del Instituto Tecnológico de Massachusetts (MIT), en concreto del trabajo del Auto-ID Center. Este grupo, fundado en 1999, realizaba investigaciones en el campo de la identificación por radiofrecuencia en red (RFID) y las tecnologías de sensores emergentes. Fue ahí donde se empezó a formar el actual concepto que tenemos de la IoT. En 2005 la agencia de las Naciones Unidas International Telecommunications Union ITU publica el primer estudio sobre el tema. A partir de ese momento Internet de las Cosas adquiere otro nivel. “Una nueva dimensión se ha agregado al mundo de las tecnologías de información y la comunicación (TIC): a cualquier hora, en cualquier lugar, ahora vamos a tener conectividad para cualquier cosa. Las conexiones se multiplican y crearán una nueva red dinámica de redes con redes, una Internet de las Cosas”. En 2005 también comienza la aventura de Arduino, una plataforma de software y hardware abierto para el desarrollo de dispositivos digitales que puedan controlar objetos del mundo real. Esta plataforma cuenta en la actualidad con una comunidad bastante extensa en todo el mundo. Todos los productos que vende la compañía de la plataforma, son distribuidos como Hardware y Software libre bajo licencias GPL (Licencia Publica General de GNU). Atendiendo a la Figura 2.2, se puede observar el crecimiento que ha seguido la cantidad de dispositivos conectados a Internet. En el año 2003, había aproximadamente 6,3 mil millones de personas en el mundo, con un número aproximado de 500 millones de dispositivos conectados a Internet. La relación entre estas variables era de 0,08 dispositivos por persona. El auge en el desarrollo y la mejora de las tecnologías portátiles e inalámbricas como smartphones o tablets 24 elevó a 12,5 mil millones en 2010 la cantidad de dispositivos conectados a la red de redes, pasando la relación dispositivos/personas de 0,08 a 1,84, es decir, a partir de este año el número de dispositivos supera al de personas. Las predicciones apuntan a que en el año 2020 cerca de 50.000 millones de dispositivos electrónicos estarán conectados a Internet, cambiando radicalmente nuestro estilo de vida. Figura 2-2. Crecimiento de numero de dispositivos. 2.3 Tecnologías Usadas en IoT Los administradores del área de TI de las empresas y encargados de las redes y el funcionamiento del Internet de las Cosas tienen a su disposición muchas opciones distintas para conectar dispositivos de este tipo. Cada opción tiene distintas ventajas, aunque también desventajas. Aquí hablamos de algunas de ellas. 2.3.1 802.15.4 El estándar 802.15.4 define el nivel físico y el control de acceso al medio de redes inalámbricas de área personal con tasas bajas de transmisión de datos. El grupo de trabajo IEEE 802.15 es el responsable de su desarrollo. Es la tecnología en la que se apoyan protocolos como Bluetooth y arquitecturas basadas en ZigBee, un protocolo ampliamente usado en ecosistemas IoT ya que dichos ecosistemas no pueden manejar protocolos de red muy pesados debido a que esto afectaría seriamente el consumo de energía y requerirían de mayor poder de procesamiento [5]. Las características más importantes en este estándar son su flexibilidad de red, bajos costos, bajo consumo de energía. La motivación para el uso de tecnología inalámbrica es la reducción en los gastos de instalación, ya que nunca es necesario cambiar el cableado. Las redes inalámbricas implican un gran intercambio de información con un mínimo de esfuerzo de instalación. Esta tendencia es impulsada por la gran capacidad de integrar componentes inalámbricos de una forma más barata y el éxito que tienen otros sistemas de comunicación inalámbrica como los celulares. 2.3.2 Bluetooth Aunque muchos piensan que esta tecnología de red ya está muerta, el Bluetooth permite comunicaciones inalámbricas integradas para dispositivos de IoT. Como puntos a favor de la tecnología Bluetooth, encontramos su reducido consumo de energía y su seguridad. En contra, podemos decir que esta tecnología se ve limitada en temas de alcance y capacidad de la red, pasando a estar en determinados casos de uso donde intervengan comunicaciones de larga distancia [6]. La nueva versión de Bluetooth, la 5.0, viene a introducir varias mejoras [7]: • Doble de capacidad con respecto a la versión Bluetooth 4.0: Antiguamente el pico de velocidad estaba establecido en 1Mbps (Megabit por segundo). Con esta versión, existe un modo con una capacidad de 2Mbps. Esta mejora, ofrece unos beneficios adicionales: o Reduce la potencia de transmisión ya que la misma cantidad de datos es transmitida en menos tiempo. o Mejora en la coexistencia de distintas comunicaciones inalámbricas gracias a la reducción del tiempo de emisión. • Aumenta cuatro veces el rango de distancia: Esta versión añade un modo de alto alcance donde se utilizan técnicas de error de corrección de tramas llamada Corrección de Tramas hacia Delante (FEC por sus siglas en ingles). Gracias a este, en vez de requerir que el emisor reenvíe una trama en el caso de que esta contenga errores, el receptor puede reconstruir dicha trama a través de la redundancia que existe en los datos de la trama. Rangos de hasta ochocientos metros han sido testados con resultados satisfactorios durante los tests de el modo de largo alcance que Bluetooth 5.0 incorpora. Figura 2-3. Bluetooth 5.0. Como podemos ver, las nuevas implementaciones que Bluetooth 5.0 trae pueden ser beneficiosas para un amplio rango de aplicaciones IoT. Es por esto que no podemos hablar del internet de las cosas sin hablar de Bluetooth como un referente en la implementación del estándar 802.15.4 en estos casos de uso determinados. 2.3.3 WiFi WiFi se basa en el estándar del IEEE 802.11 el cual define el uso de los dos niveles inferiores de la arquitectura o modelo OSI (capa física y capa de enlace de datos), especificando las normas de funcionamiento de una red de área local inalámbrica (WLAN). Este es un protocolo inalámbrico gestionado por la WiFi Alliance [8] diseñado para intentar reemplazar a los protocolos de red de área local cableados usando comunicaciones inalámbricas sobre bandas de frecuencia de uso libre ISM (bandas de uso para industrial, científico y medico) [9]. La idea de este protocolo era la de crear un protocolo fácil de implementar, fácil de usar en conexiones inalámbricas de corto alcance con interoperabilidad entre proveedores. Además, se pensó sin la implementación de una eficiencia en el uso de la frecuencia y obviando aspectos relativos a la eficiencia energética. Las ventajas de usar este protocolo en una red IoT son el bajo costo de la infraestructura y dispositivos, la facilidad en el despliegue y eficiencia del espectro. En contra, el elevado consumo de potencia y la congestión del canal inalámbrico son grandes desventajas para el uso de dicho protocolo en una infraestructura del internet de las cosas. 32 El estándar ZigBee es mantenido por la ZigBee Alliance. El standard define las capas superiores de red sobre la capa de enlace 802.15.4 y diversos perfiles de aplicaciones permiten implementaciones interoperables del sistema completo. ZigBee puede usarse en múltiples aplicaciones, pero ha adquirido el mayor impulso y éxito en aplicaciones de energía inteligente, domótica y control de iluminación, cada una de las cuales tiene un perfil y certificación específicos de ZigBee. Otra razón por la que le ha ido tan bien al estándar ZigBee en estas áreas de aplicaciones es por la topología de red en malla que puede incluir hasta miles de nodos. Aunque el estándar ZigBee tiene una especificación IP, está separada de los perfiles populares de enlace de energía inteligente, domótica e iluminación y no ha generado mucha tracción en la industria. Para conectarse a IoT, las redes ZigBee requieren una puerta de enlace de nivel de aplicación. La puerta de enlace participa como uno de los nodos en la red ZigBee y ejecuta en paralelo una pila TCP/IP y aplicación por Ethernet o Wi- Fi para conectar la red ZigBee al Internet [23]. Figura 2-10. Arquitectura ZigBee [24]. 2.4.1.4 6LoWPAN 6LoWPAN es un acrónimo para IPv6 over Low power Wireless Personal Area Networks (IPv6 para redes de área personal inalámbricas de baja energía). La promesa de 6LoWPAN es aplicar IP al dispositivo de energía de procesamiento más limitado, más pequeño y con la menor energía. 6LoWPAN es realmente el primer estándar de conectividad inalámbrica que se creó para IoT. El estándar se creó por el grupo de trabajo 6LoWPAN del IETF y se formalizó bajo la RFC 6282 [25], en septiembre de 2011. El estándar 6LoWPAN solo define una capa de adaptación eficiente entre la capa de enlace 802.15.4 y una pila TCP/IP. Un dispositivo 6LoWPAN puede comunicarse con cualquier otro servidor o dispositivo basado en IP en Internet, incluidos los dispositivos WiFi y Ethernet. Se eligió a IPv6 como el único IP admitido en 6LoWPAN (excluido IPv4) porque admite un mayor espacio de direcciones, por lo tanto, redes mucho mayores, y también porque tiene un soporte incorporado para la configuración automática de la red. Las redes 6LoWPAN requiere una puerta de enlace Ethernet o WiFi para acceder a Internet. De forma similar a Wi-Fi, la puerta de enlace es una puerta de enlace de capa de IP y no una puerta de enlace de capa de aplicaciones, que permite a los nodos y las aplicaciones 6LoWPAN un acceso directo a Internet. Debido a que la mayor parte de la Internet implementada en la actualidad todavía usa IPv4, una puerta de enlace 6LoWPAN generalmente incluye un protocolo de conversión de IPv6 a IPv4. Figura 2-11. Modelo 6LoWPAN [26]. 6LoWPAN es bastante nuevo para el mercado. Las implementaciones iniciales usan ambas bandas ISM de 2,4 GHz y 868 MHz/ 915 MHz. Basándose en las ventajas de 802.15.4, topología de red en malla, gran tamaño de red, comunicación confiable y bajo consumo de energía, y en los beneficios de la comunicación IP, 6LoWPAN está en condiciones de alimentar al mercado en expansión de sensores conectados a Internet y otras aplicaciones de bajo rendimiento de datos y operadas con baterías. 2.4.2 Protocolos de Transporte 2.4.2.1 UDP Protocolo básico de la capa de transporte del modelo OSI usado en aplicaciones cliente/servidor basado en el protocolo IP. UDP es la principal alternativa a TCP y uno de los protocolos de red más antiguos, introducido en 1980. Se utiliza fundamentalmente para aplicaciones en tiempo real [27]. Este protocolo es muy simple ya que no proporciona detección de errores (no es un protocolo orientado a conexión). Otro escenario de uso de UDP está en programas que requieren transmisión de datos sin pérdida cuando el programa está configurado para administrar la retransmisión de paquetes perdidos y organizar los paquetes recibidos correctamente. Figura 2-12 UDP Por lo tanto, el encabezado del segmento UDP es muy simple: 34 Puerto de origen (16 bits) Puerto de destino (16 bits) Longitud total (16 bits) Suma de comprobación del encabezado (16 bits) Datos (longitud variable) Tabla 2–2 Cabecera UDP El significado de los campos UDP es el siguiente: • Puerto de origen: es el número de puerto relacionado con la aplicación del remitente del segmento UDP. Este campo representa una dirección de respuesta para el destinatario. Por lo tanto, este campo es opcional. Esto significa que, si el puerto de origen no está especificado, los 16 bits de este campo se pondrán en cero. En este caso, el destinatario no podrá responder (lo cual no es estrictamente necesario, en particular para mensajes unidireccionales). • Puerto de destino: este campo contiene el puerto correspondiente a la aplicación del equipo receptor al que se envía. • Longitud: este campo especifica la longitud total del segmento, con el encabezado incluido. Sin embargo, el encabezado tiene una longitud de 4 x 16 bits (que es 8 x 8 bits), por lo tanto, la longitud del campo es necesariamente superior o igual a 8 bytes. • Suma de comprobación: es una suma de comprobación realizada de manera tal que permita controlar la integridad del segmento. 2.4.2.2 TCP Es otro de los protocolos básicos en internet. Su acrónimo, indica que es un protocolo de control de transmisión. Permite que los datos puedan llegar al destino sin errores y en el mismo orden que se transmitieron. Además, ofrece un control de flujo para que la aplicación se vaya adaptando a las condiciones del canal de transmisión [28]. El propósito primordial de TCP es proporcionar circuitos lógicos confiables o servicios de conexión entre parejas de procesos. Esto no implica confiabilidad desde protocolos de más bajo nivel (como IP) así que TCP debe garantizar esto por sí mismo. TCP reside en el nivel de transporte del modelo de niveles convencionales. Está situado entre IP y los niveles superiores. TCP no está cargado en las pasarelas. Está diseñado para residir en los computadores o en las máquinas que se ocupan de conservar la integridad de la transferencia de datos entre extremos. Lo más común es que TCP resida en los computadores de usuario. Como IP es una red no orientada a conexión, es TCP quien se debe encargar de las tareas de fiabilidad, control de flujo, secuenciamiento, aperturas y cierres. Aunque TCP e IP estén tan relacionados que incluso se les denomine juntos "TCP/IP", TCP puede soportar otros protocolos. Por ejemplo, otro protocolo no orientado a conexión como el ISO 8473 (Protocolo de Redes No Orientado a Conexión o CNLP) podría funcionar con TCP (si se realizan algunos ajustes de los interfaces entre módulos). Además, los protocolos de aplicación, como el Protocolo de Transferencia de Correo Simple (de siglas en inglés, SMTP) se apoyan en muchos servicios que proporciona TCP. El término asociado con estos aspectos de los protocolos orientados a conexión es el de circuito virtual. Cada octeto transmitido lleva asignado un número de secuencia. El módulo TCP receptor utiliza una rutina de checksum para comprobar la posible existencia de daños en los datos producidos en el proceso de transmisión. Si los datos son aceptables, TCP envía una acepción positiva (ACK) al módulo TCP remitente. Si los datos han resultado dañados, el TCP receptor los descarta y utiliza un número de secuencia para informar al TCP remitente del problema. Como muchos otros protocolos orientados a conexión, TCP emplea temporizadores para garantizar que no transcurre un lapso de tiempo demasiado grande antes de la transmisión de aceptaciones desde el nodo receptor y/o de la transmisión de datos desde el nodo transmisor. TCP recibe datos de un protocolo de nivel superior de forma orientada a cadenas. Esto es diferente a muchos otros protocolos empleados en la industria. Los protocolos orientados a cadenas se diseñan para enviar caracteres separados y no bloques, tramas, datagramas, etc. Los datos son enviados por un protocolo de nivel superior en forma de cadenas, byte a byte. Cuando llegan al nivel TCP, los bytes son agrupados para formar segmentos TCP. Dichos segmentos se transfieren a IP (o a otro protocolo de nivel inferior) para su transmisión al siguiente destino. La longitud de los segmentos de la determina TCP, aunque el realizador de un determinado sistema puede determinar la forma en que TCP toma su decisión. TCP comprueba también la duplicidad de los datos. En el caso de que el remitente decida retransmitir los datos, el receptor descarta los datos redundantes. Estos datos redundantes podrían aparecer en la interred, por ejemplo, cuando el receptor no acepta el tráfico de manera temporizada, en cuyo caso el remitente decidirá retransmitir los datos. Además de la capacidad de transmisión de cadenas, TCP soporta también el concepto de función push. Esta función se utiliza cuando una aplicación desea asegurarse de que todos los datos que han pasado al nivel inferior se han transmitido. Para hacer eso, gobierna la gestión del buffer de TCP. Para obtener esta función, el protocolo de nivel superior envía una orden a TCP con un identificador de parámetro de push a 1. Esta operación implica que TCP envía todo el tráfico almacenado en forma de segmento o segmentos hacia su destino. Además de utilizar los números de secuencia para aceptaciones, TCP los utiliza para la reordenación de los segmentos que llegan a su destino fuera de orden. Como TCP descansa sobre un protocolo no orientado a conexión, es bastante posible que en la interred se creen datagramas duplicados. TCP también elimina los segmentos duplicados. TCP emplea un esquema de aceptación inclusiva. El número de aceptación acepta todos los octetos hasta (e incluyendo) el del número de aceptación menos uno. Este esquema es un método muy sencillo y eficiente de aceptar tráfico, pero presenta una desventaja. Por ejemplo, supongamos que se han transmitido diez segmentos y debido a las operaciones realizadas durante el proceso de encaminamiento llegan desordenados. TCP está obligado aceptar sólo el mayor número de bytes contiguos recibidos sin error. No está permitido aceptar el byte de mayor número recibido hasta que hayan llegado todos los bytes intermedios. Por tanto, como en cualquier otro protocolo orientado a conexión, podría transcurrir el periodo de temporización de aceptaciones y TCP transmisora retransmitiría el tráfico no aceptado todavía. Esas retransmisiones podrían introducir una considerable sobrecarga en la red. El módulo TCP receptor se ocupa también de controlar el flujo de los datos del transmisor, lo que es muy útil para evitar el desbordamiento de los dispositivos de almacenamiento y la saturación de la máquina receptora. La idea que utiliza TCP es algo poco usual en protocolos de comunicación. Se basa en enviar el dispositivo transmisor un valor de "ventana". Se permite que el transmisor envíe un número máximo de bytes igual al valor de su ventana. Cuando se ha llegado a ese valor, la ventana se cierra y el transmisor debe interrumpir el envío de datos. Además, TCP posee una facilidad muy útil que permite multiplexar varias sesiones de usuario en un mismo computador. Esta operación se realiza definiendo algunas convenciones para compartir puertos y sockets entre usuarios. TCP proporciona transmisión en modo dúplex integral entre las entidades que se comunican. De esta forma, la transmisión se puede efectuar en ambos sentidos sin necesidad de esperar a la señal de indicación de cambio de sentido, necesaria en las transmisiones semidúplex. Además, TCP permite a los usuarios especificar niveles de seguridad y prioridades de las conexiones. Aunque esas opciones no están incluidas en todos los protocolos TCP, están definidas en el estándar TCP. TCP proporciona el cierre seguro de los circuitos virtuales (la conexión lógica entre dos usuarios). El cierre seguro se ocupa de que todo el tráfico sea reconocido antes de la desactivación del circuito virtual. Las PDU que se intercambian entre dos módulos TCP se denominan segmentos. El segmento se divide en dos partes, la parte de cabecera y la parte de datos. La parte de datos sigue a la parte de cabecera. Los primeros dos campos del segmento se denominan puerto de fuente y puerto de destino. Esos campos de 16 bits identifican a los programas de aplicación de nivel superior que utilizan la conexión TCP [29]. 36 Figura 2-13. Cabecera TCP. El siguiente campo se denomina número de secuencia. Este campo contiene el número de secuencia del primer octeto del campo de datos de usuario. Su valore especifica la posición de la cadena de bits del módulo transmisor. Dentro del segmento especifica el primer octeto de datos de usuario. El número de secuencia se utiliza también durante la operación de gestión de la conexión. Si dos entidades TCP utilizan el segmento de solicitud de conexión, entonces el número de secuencia especifica el número de secuencia de envío inicial (ISS) que se utilizará para la numeración subsiguiente de los datos de usuario. El valor del número de aceptación permite aceptar los datos previamente recibidos. Este campo contiene el valor del número de secuencia del siguiente octeto que se espera recibir del transmisor. Con esa definición permite la aceptación inclusiva, en el sentido de que permite la aceptación de todos los octetos hasta, e incluyendo, el valor de este número menos 1. El campo de desplazamiento de datos especifica el número de palabras alineadas de 32 bits de que consta la cabecera de TCP. Este campo se utiliza para determinar dónde comienza el campo de datos [30]. Como puede esperarse, el campo reservado está reservado. Consta de 6 bits que deben valer cero. Estos bits están reservados para usos futuros. Los seis bits siguientes se denominan indicadores (flags). Son bits de control de TCP y se utilizan para especificar ciertos servicios o utilidades que se pueden emplear durante la sesión. El valor de algunos de esos bits indica cómo interpretar otros campos de la cabecera. Los seis bits mencionados llevan la siguiente información. • URG indica que el campo de puntero de urgencia es significativo. • ACK indica si el campo de aceptación es significativo. • PSH significa que el módulo va a utilizar la función push. • RST indica que la conexión se va a inicializar. • SYN indica que se van a sincronizar los números de secuencia; se utiliza en los segmentos de establecimiento de conexión como indicación de que se van a realizar algunas operaciones de preparación. • FIN indica que el remitente no tiene más datos para enviar. Es comparable a la señal de fin de transmisión (EOT) en otros protocolos. El campo siguiente, denominado ventana, se pone a un valor que indica cuántos octetos desea aceptar el receptor. Este valor se establece teniendo en cuenta el valor del campo de aceptación (número de aceptación). La ventana se establece sumando los valores del campo de ventana y del campo de número de aceptación. El campo de checksum contiene el complemento de 1 a 16 bits del complemento a 1 de la suma de todas las palabras de 16 bits del segmento, incluyendo la cabecera del texto. El propósito de este cálculo es determinar si el segmento procedente del transmisor ha llegado libre de errores. El siguiente campo del segmento, denominado puntero de urgente, se utiliza sólo si el indicador de URG está a 1. El objeto de este puntero es identificar el octeto de datos al que siguen datos urgentes. Los datos urgentes se denominan datos fuera de vida. TCP no dice lo que hay que hacer con los datos urgentes. Depende de la implementación. Dicho de otro modo, sólo se indica el lugar donde empiezan los datos urgentes, no lo que hay que hacer con ellos. El valor de este campo es un desplazamiento del número de secuencia y apunta al octeto a partir de cual siguen los datos urgentes. El campo de opciones está concebido para posibilitar futuras mejoras de TCP. Está diseñado de forma semejante al campo de opción de los datagramas de IP, en el sentido de que cada opción se especifica mediante un byte que especifica el número de opción, un campo que contiene la longitud de la opción y finalmente, los valores de la opción propiamente dichos. Finalmente, el campo de relleno asegura que la cabecera TCP ocupa un múltiplo par de 32 bits. 2.4.3 Protocolos de Aplicación 2.4.3.1 MQTT MQTT (Message Queue Telemetry Transport), que está construido sobre la pila de TCP/IP, se ha convertido en uno de los estándares para las comunicaciones de IoT [31]. Originariamente, MQTT fue inventado y desarrollado por IBM a finales de los 90. Su aplicación original era conectar sensores de los oleoductos con satélites. Tal como sugiere su nombre, es un protocolo de mensajería que soporta la comunicación asíncrona entre las partes. Un protocolo de mensajería asíncrona disocia al emisor y al receptor de los mensajes tanto en espacio como en tiempo, y, por lo tanto, es escalable en entornos de red no confiables. A pesar de su nombre, no tiene nada que ver con las colas de mensajería, y, en cambio, utiliza un modelo de publicación y suscripción. A finales del 2014, se convirtió oficialmente en un estándar abierto de OASIS, y se soporta en lenguajes de programación populares mediante la utilización de varias implementaciones de código abierto [32]. MQTT habilita el modelo Publicador/Suscriptor de una manera ligera. Permite la comunicación con servidores con un uso reducido de ancho de banda. Este protocolo está orientado a la comunicación de sensores, debido a que consume muy poco ancho de banda y puede ser utilizado en la mayoría de los dispositivos empotrados con pocos recursos (CPU, RAM, …). Figura 2-14. Protocolo MQTT. 38 El protocolo MQTT define los tipos de entidades en la red: un intermediario de mensajes y un número de clientes. El intermediario es un servidor que recibe todos los mensajes de los clientes y luego los redirige a clientes de destinos relevantes. Un cliente es cualquier cosa que pueda interactuar con el intermediario para enviar y recibir mensajes. Un cliente puede ser un sensor de IoT en el campo o una aplicación del centro de datos que procesa datos de IoT. 1. El cliente se conecta con el intermediario. Se puede suscribir a cualquier "tema" de mensajes de intermediario. Esta conexión puede ser una conexión TCP/IP simple o una conexión TLS cifrada para mensajes confidenciales. 2. El cliente publica el mensaje, sobre un tema, enviando el mensaje y el tema al intermediario. 3. Después, el intermediario redirige el mensaje a todos los clientes que están suscritos a ese tema. Ya que los mensajes MQTT están organizados por temas, el desarrollador de aplicaciones tiene la flexibilidad de especificar que ciertos clientes sólo puedan interactuar con determinados mensajes. Por ejemplo, los sensores publicarán sus lecturas sobre del tema "sensor_data" y se suscribirán al tema "config_change". Las aplicaciones de procesamiento de datos que guardan datos del sensor en una base de datos backend se suscribirán al tema "sensor_data". Una aplicación de consola de administración puede recibir los comandos del administrador del sistema para ajustar las configuraciones de los sensores, como la sensibilidad y la frecuencia de la muestra, y publicar esos cambios en el tema "config_change". 2.4.3.2 XMPP Tecnología abierta para comunicación en tiempo real. Es el mejor protocolo para conectar dispositivos con personas. Se trata de un caso especial del patrón D2S (Devices to Servers). Sus siglas son una abreviación para el término Extensible Messaging Presence Protocol [33]. XMPP es un protocolo abierto que se creó para ser usado en sistemas de mensajería instantánea originalmente, está basado en XML. Originalmente se conocía como Jabber, y el proyecto fue iniciado en 1998 por Jeremie Miller. Actualmente XMPP y sus múltiples extensiones soportan mensajería instantánea, videoconferencia, vista del estado en línea de los usuarios, y transferencia de archivos a través de clientes. Debido a que es un protocolo abierto y confiable, muchas empresas lo adoptaron como el estándar para sus servicios de chat, entre las que podemos mencionar servicios tan populares como Whatsapp, Facebook Messenger, y Gtalk. XMPP funciona de manera completamente descentralizada, está documentado, y puede ser usado en cualquier proyecto. Existen muchos clientes y servidores libres que se pueden usar de manera gratuita [34]. 2.4.3.3 DDS El primer estándar abierto e internacional que acoge el patrón Publicador/Suscriptor para comunicaciones en tiempo real de dispositivos embebidos. DDS usa una arquitectura sin Broker o servidor. Se puede ver como un bus de datos que integra y comunica máquinas inteligentes [35]. Este protocolo usa la difusión de contenido para proveer una elevada calidad de servicio a las aplicaciones que hagan uso del mismo. Figura 2-15. Arquitectura DDS [36]. DDS es un espacio global de datos distribuido. Las especificaciones de un espacio global de datos hacen de este protocolo de una buena solución para las aplicaciones que demandan la reducción de los cuellos de botella. En dicha arquitectura, las aplicaciones pueden leer o escribir de forma autónoma y asíncrona. Además, estas pueden unirte o dejar el espacio de datos en cualquier instante ya que son descubiertos en dicho espacio de forma dinámica. El resto del funcionamiento del protocolo DDS es muy parecido a MQTT. Los publicadores y suscriptores expresan su intención de producir o consumir información de determinado tipo según el teman escogido [37]. 2.4.3.4 AMQP Sistema de colas diseñado para la conexión entre servidores. Sus características fundamentales son el encolamiento, enrutamiento, seguridad y fiabilidad [38]. Este protocolo manda mensajes de transacciones entre servidores. Actúa como un middleware centrado en mensaje cuyo origen es la industria bancaria. Este puede procesar miles de colas de transacciones. AMQP está centrado en evitar la pérdida de paquetes. Las comunicaciones de los publicadores a los servidores y desde las colas de los mismos a los suscriptores se apoyan sobre TCP, el cual provee una conexión punto a punto de confianza. Además, los puntos finales deben de enviar un acuse de recibo de cada mensaje. Actualmente, dicho protocolo se usa en aplicaciones de banca. Este protocolo en IoT es usado principalmente para el plano de control de las funciones de análisis basada en servidores [39]. 2.4.3.5 DTLS Datagram Transport Layer Security (DTLS) [40], es un protocolo de comunicaciones diseñado para proteger la privacidad en las comunicaciones y prevenir su intercepción y manipulación. Está basado en el protocolo Transport Layer Security (TLS), el cual es un protocolo que provee seguridad a redes de comunicaciones basadas en computadoras. La principal diferencia entre DTLS y TLS es que el DTLS usa UDP y TLS utiliza TCP. Es usado para navegación web, correo electrónico, mensajería instantánea y voIP [41]. 40 Figura 2-16. DTLS sobre UDP. 2.4.3.6 HTTP Hypertext Transfer Protocol (HTTP) (o Protocolo de Transferencia de Hipertexto en español) es un protocolo de la aplicación para la transmisión de documentos hipermedia, como HTML [42]. Fue diseñado para la comunicación entre los navegadores y servidores web, aunque puede ser utilizado para otros propósitos también. Sigue el clásico modelo cliente-servidor, en el que un cliente establece una conexión, realizando una petición a un servidor y espera una respuesta del mismo. Se trata de un protocolo sin estado, lo que significa que el servidor no guarda ningún dato (estado) entre dos peticiones. Aunque en la mayoría de casos se basa en una conexión del tipo TCP/IP, puede ser usado sobre cualquier capa de transporte segura o de confianza, es decir, sobre cualquier protocolo que no pierda mensajes silenciosamente, tal como UDP. Con HTTP se establecen criterios de sintaxis y semántica informática (forma y significado) para el establecimiento de la comunicación entre los diferentes elementos que constituyen la arquitectura web: servidores, clientes, proxies. Fue creado en 1999 por el World Wide Web Consortium en colaboración con la Internet Engineering Task Force [43]. El funcionamiento del http se basa en un esquema de petición-respuesta entre el servidor web y el “agente usuario” (del inglés user agent) o cliente que realiza la solicitud de transmisión de datos. Un cliente puede ser un explorador determinado, cuando intentamos abrir una página web, o los rastreadores web (webcrawlers o arañas web) que las inspeccionan. A ellos el servidor brinda una respuesta estructurada de modo puntual y dotada de una serie de metadatos, que establecen las pautas para el inicio, desarrollo y cierre de la transmisión de la información. Estos son los “métodos de petición”, es decir, los comandos que disparan la ejecución de recursos determinados, cuyos archivos residen en el servidor. 2.4.3.7 CoAP Protocolo de nivel de aplicación cuyo uso se da en dispositivos de Internet con recursos limitados, como nodos WSN. CoAP está diseñado para una fácil traducción a HTTP con el fin de simplificar la integración con la web, y al mismo tiempo satisfacer necesidades especializadas como soporte multicast, bajo coste y simplicidad ya que son muy importantes para el Internet de las cosas [44]. CoAP implementa el modelo REST de HTTP (con las primitivas GET, POST, PUT y DELETE), usa cabeceras reducidas, y limita el intercambio de mensajes, añadiendo soporte UDP y otras modificaciones como mecanismos de seguridad específicos. 2.5 Plataformas IoT De la misma forma que hay numerosas aplicaciones basadas en la IoT, existen multitud de plataformas que permiten que el desarrollo de aplicaciones sea más amigable. A modo de introducción, se mencionan las características generales de cinco plataformas de IoT. 2.5.1 FiWare FiWare es una iniciativa open source (código abierto en español), financiada por la Unión Europea, que pretende impulsar la creación de estándares necesarios para desarrollar aplicaciones Smart en diferentes dominios: Smart Cities, Smart Ports, Smart Logistics, Smart Factories, entre otros. Cualquier aplicación Smart se caracteriza por recoger información relevante para la aplicación de diferentes fuentes sobre lo que está pasando en un momento dado. Esto se conoce como “información de contexto”. La información de contexto actual e histórica se procesa, visualiza y analiza a gran escala. De esta forma, se produce el comportamiento inteligente esperado [45]. FiWare quiere impulsar un estándar que describe cómo recopilar, gestionar y publicar información de contexto y adicionalmente aporta elementos que permiten explotar esta información una vez recopilada. Ese estándar no existe en la actualidad y resulta clave para construir un mercado digital único para las aplicaciones inteligentes donde las apps y soluciones pueden portarse de un cliente a otro sin grandes cambios. También resuelve de manera sencilla cómo capturar información procedente de redes de sensores, aunque se comunican usando diferentes protocolos y lenguajes IoT. En ese sentido es capaz de resolver la complejidad de tratar la información recogida por los sensores y traducirlos a un lenguaje común. Figura 2-17. Plataforma FiWare [46]. 2.5.2 Amazon Web Service Amazon Web Service para IoTm provee una colección de servicios de computación que en conjunto forman una plataforma de computación en la nube, ofrecida a través de Internet por Amazon.com. Es usado en aplicaciones populares como Dropbox o en reconocidas organizaciones como la NASA [47]. Como vemos en la siguiente imagen, Amazon Web Service cuenta con amplitud de servicios que van desde el borde de los dispositivos IoT hasta la nube. Esto proporciona una flexibilidad para poder combinar nuevos servicios y poder desplegar nuevos dispositivos. Además, este servicio IoT puede ser integrado con otros servicios que Amazon Web Service ofrece, pudiendo crear aplicaciones IoT completas. 48 facilitar la creación de aplicaciones web inteligentes. Estas ofrecen funciones comunes y reusables usadas en múltiples casos de uso en varios sectores. Las especificaciones para nuevos GE son de código abierto pudiendo ser modificadas por cualquier persona para su propio uso. Según el proyecto FiWare, los “Generic Enablers” se dividen en siete partes técnicas. 3.5.1 Cloud Hosting Los componentes que, enmarcados en esta parte técnica, son los encargados de ofrecer recursos cloud desde infraestructura y parte hardware, hasta software. Son los encargados del despliegue y provisión de máquinas virtuales, de almacenamiento robusto y escalable, etc. Además, ofrece elementos para la gestión de arquitecturas de despliegue y de gestión de políticas basadas en reglas. Por último, ofrecen soporte al despliegue automático de software y mecanismos de monitorización de los mismos. Figura 3-1. Cloud Hosting. 3.5.2 Data/Context Management Los elementos denominados como “Data/Context Management” son los encargados del procesamiento de datos, desde el despliegue de motores de análisis Big Data mediante un ecosistema Hadoop, hasta procesamiento de eventos en tiempo real y la gestión de información de contexto. Por último, en esta parte técnica, encontramos elementos responsables de la inclusión de capacidades multimedia al ecosistema para añadir componentes interactivos a las aplicaciones. Figura 3-2. Data/Context Management. 3.5.3 Interfaces to Network and Devices Estos elementos ofrecen Control e información sobre la red IoT. Permiten la abstracción y virtualización de los recursos y funcionalidades de la red. Figura 3-3. Interfaces to Network and Devices. 3.5.4 Advanced Web-Based User Interface Es necesario en un ecosistema IoT, la inclusión de elementos que permitan la comunicación con plataformas web. Esta parte cuenta con numerosas interfaces para proveer información de manera genérica mediante APIs Web de alto nivel Estandarizadas. Estas APIs comprenden desde para Realidad Virtual, datos GIS, etc. Figura 3-4. Advanced Web-Based User Interface 3.5.5 Security La seguridad es un factor clave en cualquier proyecto tecnológico. La parte técnica “Security” se encarga de la gestión de herramientas que aumenten la seguridad del sistema mediante gestión de políticas de seguridad, gestión de usuarios y funciones de proxy. Figura 3-5. Security. 3.5.6 Internet Of Things Para la inserción de información hacia el ecosistema se usan los elementos de la parte “Internet of Things” la cual cuenta con elementos para proveer APIs para comunicaciones M2M (Maquina a Máquina); para el registro a la red de nuevos dispositivos y sensores; para procesar datos en tiempo real; o para actuar sobre los dispositivos o actuadores del ecosistema. 50 Figura 3-6. Internet Of Things. 3.5.7 Applications/Services and Data Delivery Todos los datos que obtenemos del ecosistema deben de tener un consumidor final. Los elementos de esta parte técnica se encargan de proveer de servicios y APIs a los usuarios finales de los datos que fluyen dentro del ecosistema FiWare. Figura 3-7. Applications/Services and Data Delivery. 3.6 NGSI NGSI es una especificación propuesta por la OMA (Open Mobile Alliance) que se basa en una API Rest para comunicarse mediante peticiones HTTP de tipo GET y POST. Estas especificaciones están definidas en con los nombres NGSI-9 y NGSI-10 (FI-WARE NGSI Open RESTful API Specification (PRELIMINARY)). Sin embargo, el gestor de contexto FiWare NGSI no implementa todas las especificaciones de la OMA para no ser innecesariamente complejo. A pesar de eso, resuelva algunas ambigüedades en las especificaciones de la OMA y las extiende para una visión orientada a IoT. El aspecto central del modelo de información de NGSI es el concepto de entidades. Las entidades son la representación virtual de toda clase de objeto físico del mundo real. Ejemplos como mesas, habitaciones o personas pueden ser entidades. Las entidades virtuales tienen un identificador y un tipo. Por ejemplo, una entidad virtual representa a una persona llamada “José” puede tener el identificador “José” y el tipo “persona”. Cualquier información disponible de las entidades físicas es expresada en forma de atributos de las entidades virtuales. Los atributos también tienen un nombre y un tipo. Por ejemplo, la temperatura del cuerpo de José puede ser representado como un atributo con nombre “temperatura corporal” y el tipo “temperatura”. Los valores de estos atributos se definen en los contenedores de valores. Esta clase de contenedores no solo consisten en actual atributo-valor, si no que contienen una serie de metadatos. Los metadatos son los datos de los datos; en nuestro ejemplo de temperatura corporal estos metadatos pueden contener el tiempo de la medida, las unidades de esta, y otra información acerca del valor del atributo. También está el concepto de dominios de atributos en la OMA NGSI 9/10. Un dominio de atributo agrupa de manera lógica a un conjunto de atributos. Por ejemplo, el dominio de atributos “estado_salud” puede estar compuesto de los atributos “temperatura_corporal” y “presion_sanguinea”. La estructura de datos usada para el intercambio de información sobre entidades son los elementos de contexto. Un elemento de contexto contiene información sobre múltiples atributos de una entidad. El dominio de estos atributos también puede ser especificado dentro del elemento de contexto; en este caso todos los valores de atributos incluidos pertenecen a ese dominio. Un elemento de contexto contiene la siguiente información: • Un id de entidad y tipo. • Una lista de tripletas <nombre de atributo, tipo de atributo, valor de atributo> que contienen información sobre atributos de la entidad. • (Opcional) El nombre del dominio del atributo. • (Opcional) Una lista de tripletas <nombre de metadato, tipo de metadato, valor de metadato> que se aplica a todos los valores de atributos del dominio dato. La OMA NGSI define dos interfaces para intercambiar información basada en el modelo. La interfaz NGSI-10 es usada para intercambiar información sobre las entidades y atributos. La interfaz NGSI-9 es usada para información de estado de entidades y atributos. En esta interfaz, en lugar de intercambiar valores de atributos, la información acerca de quien ha suministrado cierto atributo es intercambiada. Las APIs NGSI solo soportan XML como formato de serialización de datos. XML es un lenguaje normalizado de marcado de datos similar a HTML. La representación de los recursos es transmitida entre cliente y servidor usando el protocolo HTTP 1.1, definido por el IETF en la RFC-2616 [52]. 3.6.1 FiWare NGSI-9 La interfaz NGSI-0 es una API Rest que funciona sobre HTTP. Su propósito es intercambiar información acerca de la disponibilidad de la información de contexto. Las tres principales interacciones son: • Peticiones para descubrir nuevos dispositivos o agentes donde cierta información de contexto está disponible. • Subscripciones para actualizaciones sobre información de disponibilidad de contextos (y sus correspondientes notificaciones). • Registro de información de contexto como notificaciones de disponibilidad de cierta información de contexto. El árbol de recursos de funcionalidades sigue dos aproximaciones. Por una parte, hay unos recursos para operaciones que soportan las respectivas funcionalidades mediante mensajes POST. Por otra parte, existes recursos adicionales que realizan funcionalidades de conveniencia entre dispositivos. 52 Figura 3-8. Árbol de Recursos NGSI-9. 3.6.2 FiWare NGSI-10 La interfaz NGSI-10 también se comunica mediante una API Rest a través de HTTP. Su propósito es intercambiar información de contexto. Las tres interacciones principales son: • Peticiones de información de contexto • Suscripciones de actualizaciones de información de contexto. • Actualizaciones no solicitadas invocadas por el proveedor de contenido. El árbol de recursos de funcionalidades sigue la misma arquitectura del árbol de NGSI-9. Figura 3-9. Árbol de Recursos NGSI-10 54 4 ARQUITECTURA DEL SISTEMA Cualquier ecosistema IoT debe de cumplir unos requerimientos que permita que dicho ecosistema sea escalable y distribuido, que los componentes que forman el ecosistema puedan interactuar entre ellos, y que todo esto se realice de manera eficiente y segura. La implementación de todos estos requerimientos bajo el estandar FiWare es lo que lo hace idóneo para el desarrollo del ecosistema bajo esta tecnología. A continuación, se exponen las características del ecosistema desplegado en el proyecto apoyándonos en FiWare como estandar. 4.1 Arquitectura General del Sistema El esquema de la arquitectura se presenta en la Figura 4-1, donde de abajo hacia arriba en la arquitectura se pueden observar los distintos módulos, desde la obtención de las medidas de calidad, la transmisión de éstas a través de la red MAN, su agregación e integración gracias haciendo uso de FiWare, el post-procesado de la información con distintas técnicas de análisis Big Data y su posterior representación en la plataforma web. Como se ha comentado, dicha arquitectura se fundamenta en el Context Broker Orion, por el cual circula toda la información del sistema y orquesta la interrelación con los distintos componentes de la arquitectura. Partiendo desde la base de la arquitectura, aquí se encuentran los productores de la información que son la fuente de datos de toda plataforma. Estos productores son los distintos sensores, actuadores, APIs, entre otras, que componen el sistema. Algunos de estos productores, necesitan la ayuda de determinados agentes que se encargan de la conversión de la información generada, a un formato legible para el Context Broker el cual es NGSI, que se aglutinan en el IoT Agent. Junto al Context Broker, se sitúan los diferentes simuladores, que se utilizan en los entornos de pruebas para realizar test de funcionalidad, test de esfuerzos del sistema, test de comprobaciones de la capacidad de transacción del sistema, etc. Además, permite comprobar la escalabilidad del sistema y el comportamiento ante nuevas fuentes de información conectadas. Por último, destacar que los simuladores son fundamentales para permitir evaluar el comportamiento del sistema ante los datos de productores de información simulados, que en el futuro se sustituyen por productores reales. Por encima de Orion, se encuentran los diferentes consumidores de la información producida por el sistema. Esta información, al igual que en la parte de producción, pasara por un proceso de conversión al formato estándar de las diferentes bases de datos que pueden almacenar estos datos. Este proceso de conversión será realizado por lo que se denomina conector, el cual puede variar la implementación en función de la tecnología usada por la base de datos. Además, existen componentes específicos que se encargan de la publicación de datos abiertos y del procesamiento en tiempo real y procesamiento de grandes flujos de datos. Sólo cuando conoces cada detalle de la condición del terreno puedes maniobrar y luchar. - Sun Tzu - Figura 4-1. Arquitectura Plataforma Fiware 4.2 Orion Context Broker El principal motor de FiWare es Orion Context Broker. Este es el encargado de intermediar entre los productores (publicadores) y consumidores (subscriptores). Orion Context Broker va de la mano de una base datos MongoDB la cual guarda toda la información del broker. Por esto motivo se dice que el broker no tiene memoria interna. Es la base de datos MongoDB la que guarda toda información relativa a los publicadores, es decir, toda la información relacionada a sus entidades, atributos, tiempo de actualización… y de los suscriptores, los cuales almacenan información de las entidades suscritas, los atributos, cuando mandar a esta la notificación, etc. La importancia de esta base de datos reside en que, si por alguna razón el broker tuviese algún problema, toda la información persistirá en esta MongoDB. 56 Figura 4-2. Arquitectura Orion Context Broker. FiWare Orion está desarrollado en C++. Gracias a Orion Context Broker se puede manejar al completo el ciclo de vida de la información de contexto incluidos las actualizaciones, registros y suscripciones. A través de Orion context Broker, se podrá crear elementos de contexto nuevos y administrarlos a través de actualizaciones y peticiones. Además, se podrá suscribir a determinada información para que sea mandada cuando se cumplan ciertas condiciones o la información de los elementos cambien. En la Fig 4-2 podemos ver como el Context Broker es el epicentro de toda acción donde recibe información a través del puerto estándar 1026. Además, podemos ver la interacción de este con la base de datos MongoDB la cual se encarga de la persistencia de la información. El Context Broker se comunica con la base de datos MongoDB a través del puerto estándar de mongo 27017. También se puede observar que ambas entidades, Orion y base de datos MongoDB se pueden ubicar en distintas maquinas. Con esto, se puede dotar fácilmente al sistema con redundancia, teniendo varios replicasets de la base de datos en diferentes máquinas, mejorando la fiabilidad global del sistema. De la misma manera que se pueden instanciar varias bases de datos en diferentes maquinas, se puede realizar una instanciación del bróker en varias máquinas para que, en caso de fallo, no se pierda el servicio de este durante mucho tiempo. Con la redundancia como punto clave en el despliegue de estos servicios, podemos hablar de fiabilidad del sistema. Para el aumento de dicha fiabilidad del sistema, se realiza una instanciación de varios Context Broker formando una confederación. Dicha confederación puede ser de dos tipos: push y pull. En las confederaciones de tipo push, uno de los context broker notifica al resto de las modificaciones realizadas por los productores de información. En cambio, en las confederaciones de tipo pull, el context broker receptor de la información, reenvía la misma información recibida al resto de instancias [53]. Figura 4-3. Redundancia en Orion [53]. En cuanto al context broker, su dinámica es sencilla. Este interactúa fundamentalmente con tres tipos de primitivas o mensajes: UPDATE, SUBSCRIBE y NOTIFY. El Context Broker, recibe mensajes UPDATE de los IoT Agents los cuales están registrados en dicho broker. Los IoT Agents, son los dispositivos que actúan como intermediarios entre los sensores o dispositivos productores del sistema, y el broker. Se profundizará en estos agentes más adelante. Además de los mensajes de tipo UPDATE, el context broker recibe mensajes de suscripción (SUBSCRIBE) de las aplicaciones consumidoras los cuales sirven para poder obtener información relativa a las entidades que queramos monitorizar. Los mensajes de tipo NOTIFY son los que se encargan de enviar la información del bróker a las aplicaciones consumidoras que demandan la información. En cuanto a los mensajes UPDATE, estos son enviados desde IoT Agent al broker con la información sobre los valores de los atributos de las entidades. Estos son las tres primitivas que usa el Context Broker para llevar a cabo sus funciones. Otras características de Orion Context Broker que son útiles es la gestión de tokens de autenticación para aportar seguridad y que solo puedan acceder los consumidores que cuenten con uno de estos tokens. 4.3 Dispositivos Productores de Información Los dispositivos productores de información son aquellos que proveen los datos al sistema. El IoT está formada por la red de este tipo de dispositivos físicos que son capaces de intercambiar datos. Cada dispositivo está formado por un microcontrolador embebido y un software el cual es capaz de actuar como sensor o actuador. Los sensores son capaces de enviar información del estado de ciertos elementos alrededor de él. Los actuadores son responsables de alterar el estado del sistema tras ciertas señales de control recibidas por estos. Cada dispositivo es identificado unívocamente a través del sistema de computación embebido, pero también es capaz de identificarse perteneciendo a una existente infraestructura de internet o red de dispositivos. Ya que FiWare es un sistema para administrar información de contexto. Para una solución inteligente del internet de las cosas, el contexto será el conjunto de elementos relacionados entre sí. Cada elemento IoT, será 64 5 APLICACIÓN: CASO DE USO n este apartado se va a describir los elementos que han sido desarrollados para el despliegue de una solución inteligente para la gestión y administración del consumo y distribución de agua. Esta solución recoge el nombre de AQUASIG y en este trabajo fin de grado se describen los trabajos desarrollados por el autor del mismo para el despliegue de esta. 5.1 Introducción AQUASIG se beneficia enormemente del uso de la plataforma FiWare, que es la base para garantizar una interoperabilidad de datos y tareas de integración desde los datos en tiempo real generados por el sistema de adquisición de la medida hasta las bases de datos (Big Data y con componente geográfica) que son la base para que la plataforma AQUASIG provea de servicios inteligentes dirigidos a distribuidoras y consumidores de agua a nivel urbano. Orion se encarga de recolectar toda la información de los productores, de las fuentes de información, en nuestro caso, los dispositivos de medida de calidad del agua, de consumo y de presión, y de transmitirla a los subscriptores que lo necesiten, en nuestro caso, las bases de datos Big Data. El esquema de la arquitectura de la solución diseñada para AQUASIG se presenta en la Figura 5-1, donde de abajo hacia arriba en la arquitectura se pueden observar los distintos módulos, desde la obtención de las medidas de calidad, la transmisión de éstas a través de la red MAN, su agregación e integración gracias haciendo uso de FiWare, el post-procesado de la información con distintas técnicas de análisis Big Data y su posterior representación en la plataforma web Como se ha comentado, dicha arquitectura se fundamenta en el Context Broker Orion, por el cual circula toda la información del sistema y orquesta la interrelación con los distintos componentes de la arquitectura. Partiendo desde la base de la arquitectura, aquí se encuentran los productores de la información que son la fuente de datos de la plataforma. Estos productores son los distintos sensores (caudal, presión, calidad, etc.), APIs, entre otras, que componen el sistema. Algunos de estos productores, necesitan la ayuda de determinados agentes que se encargan de la conversión de la información generada, a un tapado legible para el Context Broker, que se aglutinan en el IoT Agent Manager. . E Pon tu mano de hierro en un guante de terciopelo. - Napoleon Bonaparte - Figura 5-1. Arquitectura de la solución. Junto al Context Broker, se sitúan los diferentes simuladores, que se utilizan en los entornos de pruebas para realizar test de funcionalidad, test de esfuerzos del sistema, test de comprobaciones de la capacidad de transacción del sistema, etc. Además, permite comprobar la escalabilidad del sistema y el comportamiento ante nuevas fuentes de información conectadas a la plataforma. Por último, destacar que los simuladores son fundamentales para permitir evaluar el comportamiento del sistema ante los datos de sensores simulados, que en el futuro se sustituyen por sensores reales. Por encima de Orion, se encuentran los diferentes consumidores de la información producida por el sistema. Esta información, al igual que en la parte de producción, pasara por un proceso de conversión al formato estándar de las diferentes bases de datos que pueden almacenar estos datos. Este proceso de conversión será realizado por lo que se denomina conector, el cual puede variar la implementación en función de la tecnología usada por la base de datos. Una vez se tengan la información en las bases de datos correspondiente, se puede acceder a estas para su análisis y posterior aportación a los módulos de generación de servicios dirigidos a las distribuidoras y dirigidos a los consumidores. Para el despliegue de los componentes de la arquitectura FiWare usados en este proyecto, se usará la tecnología Docker [75]. Docker es una tecnología de contenedores software la cual permite aislar a los diferentes componentes en sus ecosistemas respectivos. 66 La herramienta de Docker que usaremos se llama Docker Compose. Docker Compose fue creada para definir y desplegar aplicaciones Docker. Se usa un fichero de configuración donde se definen los servicios requeridos para la aplicación. Esto quiere decir que con un comando podemos desplegar todos los contenedores. 5.2 Productores de Información En primer lugar, se analizan los distintos tipos de datos que debe ser capaz de procesar la plataforma, con las particularidades de cada uno, para obtener una información homogénea, fiable y completa a partir de todos esos datos, con el fin de almacenar en la base de datos dicha información para ser explotada por los servicios de la plataforma. El total de información que alimentará a la base de datos proviene del sistema de adquisición de datos, donde fundamentalmente hay tres grandes bloques de fuentes de datos que son: • Sensores de calidad de agua: Dichos sensores, estarán ubicados por sectores en función de la caracterización de la red de la distribuidora de agua. • Sensores de control de presión de tuberías de agua: Estos sensores se encuentran en troncales de la distribuidora para permitir identificar ciertas fugas de agua mediante los mismos. • Sensores de consumo de agua: Cada vivienda contara con un sensor de consumo que monitorizara en tiempo real el consumo de cada cliente. En los sub-apartados siguientes se describe la información obtenida por cada una de las fuentes de sensorizacion del proyecto, destacando aquellos procedimientos de desarrollo de sensores y pre-procesamiento previos a la incorporación al sistema de procesado de datos de AQUASIG que se describe en los siguientes apartados. 5.2.1 Interfaces Adquisición de la medida Los equipos terminales o end-device, como su mismo nombre implica, son los dispositivos de final de red, quienes están directamente integrados con los sensores instalados, sean del tipo que sean, es decir, se ha diseñado y desarrollado una interfaz de medida para equipos terminales o end-device que sea compatible con diversos tipos de sensores, como son los de calidad, consumo de agua, presión o consumo eléctrico. Estos equipos terminales están formados por los propios sensores, un componente de adquisición de medida y otro componente de comunicación inalámbrico el cual se encarga de convertir las medidas ofrecidas por los sensores en magnitudes y comandos aptos para su envío a través de la red inalámbrica implementada en el ecosistema IoT. El equipo terminal implementado debe ser capaz de conectarse con la red inalámbrica desplegada y además extraer la información del sensor o dispositivo al que se conecte, por lo que debe ser compatible con las diferentes interfaces que dispongan los equipos desplegados en la red de distribución de aguas. Figura 5-2. Modelo Genérico Interfaz de Medida En la siguiente figura se puede ver el diagrama de bloques que compone a los End Devices: Figura 5-3. Arquitectura Dispositivo Final. La mayoría de los bloques son comunes a todos los dispositivos que se encuentran en el proyecto, tal y como se ha comentado con anterioridad. Estos bloques son: Módulo microcontrolador, etapa de alimentación y etapa de periféricos. En primer lugar, el Módulo Microcontrolador, también llamado CPU, es el encargado de procesar la información extraída de los sensores y transmitirla a través del transceptor inalámbrico. La Etapa de Alimentación del End Device (ED), es la encargada de distribuir la corriente a los componentes del dispositivo. Esta recibe a través de una batería una corriente de 5V. En cuento a la Etapa de Periféricos, esta se encarga de la interconexión del microcontrolador con la memoria, los leds, la salida a pantalla, y todos los componentes externos que sean conectados al dispositivo. La Etapa de Adaptación y su conector es el módulo principal de este dispositivo ya que es el que extrae información para alimentar el sistema. En este proyecto los ED no deben tener capacidad de actuación sobre el elemento al que monitorizan, con lo que la etapa de adaptación será únicamente una interfaz de lectura, a excepción de la estación de sensores de consumo eléctrico, los cuales sí disponen de un elemento actuador para el encendido y apagado de bombas. En este sentido y debido a la gran cantidad de equipos existentes, se desarrollan bajo un enfoque de compatibilidad con respecto a otros estándares habituales en industria, como puede ser Modbus, o el uso de equipos comerciales que puedan ser integrados en la red con el objetivo de ampliar el número de magnitudes disponibles en el sistema. Involucra información procedente del sistema de adquisición de medidas de AQUASIG, donde se incluyen los sistemas de adquisición de la medida para obtener información relacionada sobre: • Caudal: asociado al consumo de agua. • Presión: asociado a la presión de agua en la distribución. • Calidad: asociado a sondas de medición de parámetros de calidad, como son: o Conductividad: mide de forma general todas las sales que tiene disueltas el agua. o pH: mide la acidez o alcalinidad del agua. o Oxígeno disuelto: mide el contenido de oxígeno disuelto. o Temperatura: mide la temperatura del agua, que influye en la solubilidad de iones, gases, etc. A continuación, en los próximos apartados se describen de forma específica cada una de las estaciones de 68 medida desarrolladas, incluyendo la descripción de los diversos prototipos diseñados y desarrollados. Todos los sensores del sistema de adquisición de medida proveen la información a la plataforma a través del envío de lecturas inalámbricas. La mayoría de las medidas que se toman en el proyecto proceden de una serie de procedimientos que resultan al final en las medidas, la magnitud que inicialmente se mide no es la que al final se representa, ya que necesita ser tratada y puesta en contexto para entender como esa medida representa la realidad que cuantifica. La finalidad de esta sección es explicar los procedimientos que se llevan a cabo en las distintas medidas desde que se obtiene la primera medida física hasta que se representa el dato finalmente como el usuario final lo ve. Así, se hace una descripción del procedimiento para conseguir la medida. 5.2.2 Estación de Medida de Parámetros de Calidad Como se ha comentado, la estación de medida diseñada puede incorporar multitud de sensores para medición de parámetros de calidad. De forma concreta, para la estación de medida de parámetros de calidad prototipo de AQUASIG se ha diseñado y desarrollado una estación con cuatro conexiones para elementos o sensores, incorporando sensores para la medición de cuatro parámetros clave para la calidad del agua, como son: pH, oxígeno disuelto, temperatura y conductividad eléctrica. En la imagen siguiente se muestran las principales características medidas por los sensores seleccionados: Figura 5-4. Sondas de parámetros de calidad. Así, la estación de medida de parámetros de calidad consta de los siguientes elementos: • Kit de medición de pH. • Kit de medición de oxígeno disuelto. • Kit de medición de temperatura. • Kit de medición de conductividad eléctrica. • Placa de control MSP432P401R. • Módulo de comunicaciones XBEE PRO S2C. La lógica de funcionamiento de la estación será la de obtener de los sensores individualmente y mediante el protocolo de comunicaciones I2C medidas de cada uno de los sensores, para luego aglutinarlas en una cadena de texto, la cual será enviada mediante el módulo de comunicaciones al coordinador de la red que se encargará de procesar esos datos. 5.2.2.1 Medida de PH La medida del pH se hace mediante un método potenciométrico, este método se basa en que entre dos soluciones con distinta concentración de iones de hidrogeno se establece una diferencia de potencial. Esta diferencia de potencial determina que cuando se ponen en contacto haya un flujo de iones de hidrógeno o lo que es lo mismo una corriente eléctrica. En la medida real del pH no se miden directamente los iones de hidrógeno, sino que se hace de forma relativa, se compara con el de una disolución de la que se conoce el pH. Para ello se usa un electrodo de pH, cuando el electrodo entra en contacto con la disolución se establece un potencial a través de la membrana de vidrio que recubre el electrodo. El potencial varía en función del pH. Para determinar el valor del pH se necesita un electrodo que no varíe su potencial para tenerlo de referencia. La diferencia de potencial (E) es proporcional a los iones de hidrógeno, y viene definida por la ecuación de Nernst. Figura 5-5. Medida de PH. Para la realización de la calibración de las medidas es importante que la disolución se encuentre a temperatura ambiente ya que el comportamiento del electrodo depende de la temperatura. El valor del factor de Nernst a una temperatura de 25oC vale aproximadamente 0.06 y el potencial de referencia se considera igual a 0, la ecuación anterior queda reducida a: Este tratamiento de la medida se hace en la etapa de adquisición de la medida de pH, que una vez seguido el procedimiento de tratamiento de los datos los entrega mediante el método elegido al controlador, para que los datos enviados por la etapa de adquisición se puedan mostrar de forma que se entienda es necesario procesarlos para que puedan ser mostrados como una cadena de texto que sea legible para cualquier equipo. Los datos en el modo I2C vienen dados en modo ASCII, debido a las particularidades del microcontrolador y 70 de la librería para el manejo del puerto I2C que se utilizan los caracteres son leídos de uno en uno y almacenados en una tabla de tipo caracteres. El carácter que se encarga de separar la parte decimal de la parte entera es el punto (“.”). Una vez se han almacenado todos los caracteres correspondientes a la medida del pH se procede a almacenar la cadena que se entrega finalmente al sistema para que la medida se procesada por otros procesos tales como el de envío de información. A continuación, se muestra una serie de datos obtenidos de una muestra real de los datos de pH procesados y preparados para ser mostrados. Figura 5-6. Muestra Medidas de PH. 5.2.2.2 Medida de Oxígeno Disuelto La medida de oxígeno disuelto se realiza mediante una sonda galvánica, que una vez pasan las moléculas de oxígeno a través de la membrana de la sonda se genera una corriente eléctrica, a medida que el oxígeno aumenta también lo hace la salida en mV de la sonda, consiguiendo así la medida. El nivel de mV que puede dar una sonda puede ser diferente para cada sonda siendo los 0 mV el único valor igual para todas que representa cuando no existe oxígeno en la disolución. Los datos en el modo I2C vienen dados en modo ASCII, debido a las particularidades del microcontrolador y de la librería para el manejo del puerto I2C que se utilizan los caracteres son leídos de uno en uno y almacenados en una tabla de tipo caracteres, una vez recibidos esos datos es necesario interpretarlos para saber la información que contienen, si se detecta que en la cadena de datos se incluye el carácter “,” se entiende que es una cadena CSV que entrega dos valores, el primero de ellos es la saturación y el segundo el valor de oxígeno disuelto, cada uno de ellos va a una cadena separada. Por regla general solo se va a usar el dato de oxígeno disuelto, pero se deja preparado el sistema para que sea capaz de usar el dato de saturación en caso de ser necesario. A continuación, se muestra una serie de datos de oxígeno disuelto de una muestra real. Figura 5-7. Muestra Medidas de Oxígeno Disuelto. 5.2.2.3 Medida de Conductividad Eléctrica Dentro de la sonda de conductividad se encuentran dos electrodos posicionados uno enfrente del otro, se les aplica un voltaje AC a los electrodos causando que los cationes se muevan hacia la parte negativamente cargada mientras que los aniones se mueven a la parte positivamente cargada, mientras más electrones libres contenga la disolución mayor será la conductividad eléctrica. Los datos en el modo I2C vienen dados en modo ASCII, debido a las particularidades del microcontrolador y de la librería para el manejo del puerto I2C que se utilizan los caracteres son leídos de uno en uno y almacenados en una tabla de tipo caracteres. Existen dos posibilidades a la hora de recepción de los datos, que se tenga solo el dato de conductividad que es el que se va a usar en la mayoría de los casos o que se disponga de una cadena CSV en la que se encuentren los datos de EC, TDS, SAL y SG. • EC = conductividad eléctrica. • TDS = total de sólidos disueltos. • SAL = salinidad. • SG = gravedad específica. La opción de que devuelva el dispositivo la cadena CSV solo está disponible a partir de la versión 2.10 del firmware, pero se deja preparado para su soporte en caso de que sea necesario. A continuación, se muestra una serie de datos de conductividad eléctrica de una muestra real. 72 Figura 5-8. Muestra Medidas de Conductividad Eléctrica. 5.2.2.4 Medida de Temperatura El dispositivo de sensorización está basado en una resistencia que varía su valor en función de la temperatura, dispone de un valor de tensión a la salida proporcional a la temperatura medida a la entrada, de forma que a mayor temperatura mayor será la tensión a la salida. Para este sensor se tiene una referencia de 1kΩ a 0oC, la temperatura se calcula mediante la siguiente: Figura 5-9. Formula Calculo Temperatura. En la imagen siguiente se muestra una pequeña tabla de la relación temperatura y resistencia del dispositivo. Figura 5-10. Relación Temperatura-Resistencia. Los datos en el modo I2C vienen dados en modo ASCII, debido a las particularidades del microcontrolador y de la librería para el manejo del puerto I2C que se utilizan los caracteres son leídos de uno en uno y almacenados en una tabla de tipo caracteres. A continuación, se muestra una serie de datos de temperatura de una muestra real. Figura 5-11. Muestra Medidas de Temperatura. 5.2.2.5 Configuración de Sensores Los sensores seleccionados son de carácter comercial, concretamente de la marca ATLAS SCIENTIFIC. Los sensores se configuran por defecto en modo UART, por lo que ha sido necesario un trabajo de reingeniería para el cambio y adaptación al modo I2C, que sea compatible con la estación de medida. El cambio a modo I2C se ha llevado a cabo mediante la programación de una placa Arduino UNO, que se conecta del puerto serie de la placa al puerto serie del Arduino siguiendo un nuevo esquema de conexiones para poder comunicar los sensores con la etapa de adquisición. Esto ha sido posible gracias al datasheet del fabricante, mediante la configuración con comandos programados 80 5.2.5 Arquitectura Red Dispositivos Finales Puesto que uno de los mayores condicionantes es la duración de la batería, pasando por la escalabilidad y la distancia que pueda ser cubierta, la decisión que se ha tomado es seleccionar y utilizar el protocolo ZigBee, ya que está enfocado a bajo consumo de los nodos. Zigbee es un protocolo de red basado en 802.15.4. Es un estándar inalámbrico de bajo consumo que funciona en la banda de 2.4GHz. Zigbee implementa la capa de red y la subcapa de aplicación sobre los niveles de enlace y físico de IEEE 802.15.4. La capa de red permite crear un mesh, debido a que hay dispositivos con capacidad de rutado, gracias a la funcionalidad de la capa de red. En interiores el alcance es de unos 75m mientras que en exterior con visión directa puede llegar a 1km. El número máximo de dispositivos direccionables es 65535, que pueden distribuirse en topologías tipo estrella, árbol o malla. Figura 5-20. Protocolo ZigBee [77]. Este protocolo ofrece una ratio consumo/alcance acorde a lo que se necesita en el proyecto, ofrece también una alta escalabilidad y la posibilidad de direccionar muchos nodos, que para zonas de alta densidad de población es adecuado. Surge el problema de que en este protocolo conforme subimos el número de nodos la probabilidad de colisión aumenta, lo que se ha tenido en cuenta a la hora de restringir el número máximos de nodos que tendrá un concentrador. La topología que se va a emplear es una mezcla de la topología de tipo malla. Los nodos end-devices tienen la capacidad de conectarse directamente con el coordinador si alcanza directamente la cobertura, en caso de que no lleguen existe la posibilidad de colocar un router que le haga de intermediario hasta el coordinador. Hay que tener en cuenta que el número máximo de elementos que el coordinador puede direccionar son 255 entre routers y end-devices. Cada router a su vez puede direccionar hasta 255 end-devices. Por ello, para una mayor escalabilidad de la red, será necesaria la introducción de routers, existiendo también la posibilidad de simplificar la red si el número de nodos es pequeño. Figura 5-21. Topología en malla. Los dispositivos de comunicaciones para implementar la tecnología ZigBee en el proyecto, han sido los XBEE PRO S2. Dichos dispositivos son unos de los más usados actualmente bajo el marco de la tecnología Zigbee. Estos dispositivos cuentan con la certificación correspondiente que les habilita a ser usado en entornos industriales. Figura 5-22. Módulo XBee PRO [78]. Los Xbee son una familia de dispositivos de comunicaciones de la empresa Digi que implementa su propia versión de ZigBee en sus dispositivos. Disponen de dos modos de funcionamiento, el modo transparente y el modo API, siendo el modo transparente para comunicaciones punto a punto y el modo API para crear redes de dispositivos en los que se puede obtener más información de la red. Implementan niveles de seguridad dentro del protocolo. Las características que resaltan del dispositivo son las siguientes: • Cobertura de 90m en interiores y 3200 en exteriores con visión directa. • Potencia de transmisión de 18 dBm. • Es posible comunicarse con el mediante la UART y SPI. • La tensión de alimentación es de 3.3V. • Posee un modo de bajo consumo donde se apaga la etapa RF donde se consiguen consumos del orden de los 5 µA. • Tiene la posibilidad de crear redes de tipo malla. • Puede funcionar como coordinador de la red, router o end device. • Bit rate: 250 kbps. • Usa la banda de 2.5 GHz. • Potencia de transmisión: 63 mW (+18 dBm). A la vista de las características de los dispositivos se ha elegido usar el XBEE PRO S2 debido a las siguientes consideraciones: • Se dispone de una comunidad muy activa. • Cubre teóricamente una distancia mayor. • Su montaje es THD lo que implica que tiene valor añadido para prototipos. • Tiene la posibilidad de usar un modo (API) en el que se implementan tramas de protocolo para el intercambio de mensajes. • Dispone de niveles de seguridad configurables para la red. • Disposición de librerías adaptadas en algunas plataformas para el manejo del modo API. Ha sido necesaria la configuración del dispositivo XBEE mediante el software del fabricante, para introducirle los siguientes parámetros: • PAN ID: este parámetro debe ser igual para todos los nodos de la red, ya que las redes se identificarán por su PAN ID, se puede usar un número arbitrario. • Channel verificantion: este parámetro busca si hay un coordinador activo en la red y en caso de haberlo tratar de conectarse a él, estará en este caso. • Encryption enable: sirve para activar el que haya seguridad en la red, se activa en este caso usando el valor 1. • Encryption options: configura las opciones de encriptado, en el caso del coordinador se usa el valor 8, este indica que la comprobación de que la clave es correcta se hará en el periodo de conexión. • Encryption key: es la clave de acceso a la red, esta es la clave que necesitaran los dispositivos de la red para poder acceder a ella. • Destination address High y Destination address Low: este parámetro sirve para identificar al nodo destino de la comunicación, con el que hay que conectarse, es este caso se introducirá la dirección del coordinador, que será el receptor de los mensajes. 82 • API enable: este parámetro permite configurar qué modo de comunicación usa el dispositivo, en este caso se usará el modo API enable with escaping. • Sleep mode: este parámetro permite controlar el modo en el que el dispositivo dormirá, en este caso el modo que interesa es el pinHiberante, que permitirá que el dispositivo será dormido mediante un pin, el cual será controlado desde la placa principal. Configurando correctamente los parámetros anteriores el dispositivo está listo para ser usado. Para la configuración de los dispositivos, se utiliza el módulo que el fabricante ofrece llamado XBee Explorer USB, el cual permite configurar y operar el modem Xbee desde PC. Basta con conectar el modem XBee Serie 2 al USB y conectarlo al ordenador tras haber instalado los drivers correspondientes. Para configurar los módulos, abriremos el software XCTU [79]. Este software lo ofrece la empresa Digi de manera gratuita y está disponible tanto para Windows, Linux y MacOS. En la misma web, se encuentra una extensa variedad de información y tutoriales que facilita la configuración de la topología tipo malla diseñada en el proyecto. 5.2.6 Interfaces Inalámbricas Equipos Terminales Los dispositivos finales forman parte de la red inalámbrica IEEE802.15.4 creada por el coordinador de la red, con las características impuestas por éste. Cada dispositivo final estará identificado de manera unívoca dentro de la red gracias a la dirección de 16bits otorgada por el coordinador, pero además estará unívocamente identificado en cualquier red gracias a su dirección fija MAC de 64bits. Al estar directamente conectados a los dispositivos finales que queramos controlar, ya sea sólo para monitorizar o también para incluir algo de actuación sobre él, dispondrán de un bloque extra que se encargará de realizar esta adaptación entre dispositivos. El envío de datos se hace mediante el módulo de comunicaciones XBEE PRO S2C que se basa en el estándar de comunicaciones ZigBee. El dispositivo posee dos modos de funcionamiento, se usa el modo API que es el más potente y beneficioso para la aplicación. Para el uso del modo API existe una librería que facilita el manejo y envío de los datos, siendo necesario tener la cadena con los valores a enviar en una tabla de tipo CHAR. Es necesario conocer la dirección MAC del dispositivo destino. En el caso de la aplicación la dirección que debe aparecer como destino es la del nodo coordinador. Figura 5-23. Configuración dirección XBee coordinador. La información viaja encriptada por el aire hasta llegar al destino donde será descifrada. Comprobado que la extracción y posterior creación de trama es correcta se pasa a comprobar que el envío de los datos a través del módulo ZigBee es correcto, para ello es necesario tener un receptor de los datos configurado como coordinador de red. Para ello su usa el equipo concentrador de datos. La prueba de los dos dispositivos es conjunta, ya que uno y otro se prueban entre ellos para descubrir problemas que puedan aparecer. Cabe destacar que esta comunicación viaja por el aire encriptada mediante una clave generada por el dispositivo que encripta la red y otra que permite el acceso de los dispositivos a ella. No es necesario preocuparse por esta encriptación ya que se genera automáticamente por el módulo de comunicaciones, la configuración de las claves se hace mediante el software del módulo de comunicaciones. Por seguridad las claves de acceso al medio y encriptación de la red no pueden ser leídas mediante el software de configuración, solamente pueden ser escritas, esto es importante ya que de no ser así cualquiera que tuviera acceso al dispositivo coordinador podría tener acceso a las claves. A través del puerto Serie del dispositivo, se puede contemplar en pantalla si el dispositivo realiza el envío de manera satisfactoria. En caso contrario, en el monitor se mostrará el error que se haya podido originar como error al encontrar coordinador, al leer paquete de respuesta, o errores del propio dispositivo transmisor. A continuación, una muestra del código que realiza el envío desde el dispositivo. Figura 5-24. Método de transmisión de datos mediante XBee (I). 84 Figura 5-25. Método de transmisión de datos mediante XBee (II). 5.2.7 Equipos Routers Estos dispositivos se encargan de aumentar la cobertura de la red. Pueden colocarse más de uno. Está formado por un XBEE POR S2C, acompañado de una fuente de alimentación que aporte energía al módulo. Su funcionalidad es la ampliar la distancia que sea capaces de cubrir los módulos además de dotar a la red de mayor escalabilidad si es necesaria. Si la distancia entre el coordinador y el nodo final es lo suficientemente grande como para que la comunicación directa no sea posible, se introducirán routers que actuaran como pasarelas para los datos hacia el coordinador de la red. En caso de que estemos direccionando más nodos de lo que es posible para el coordinador, la introducción de routers permitirá que el sistema se escale en topología de árbol, ampliando la capacidad de la red de soportar más dispositivos. Pueden unirse a redes existentes ya creadas por los coordinadores, la limitación de routers que se conectar directamente con el coordinador lo pone la tecnología, ascendiendo a 255 nodos que son el máximo que el equipo central puede direccionar. No se les permite entrar en modos de bajo consumo, lo que hace que tengan que estar siempre despiertos. Existe la posibilidad de incorporar una serie de routers que se conecten entre ellos si la distancia con el dispositivo final es grande para así poder ampliar la zona de cobertura. Dado los niveles de cobertura del protocolo, se ubican routers por cada bloque de pisos o manzana de viviendas para asi evitar al máximo perdidas de informacion de los dispositivos responsables del consumo de agua. Figura 5-26. Router ZigBee. 5.2.8 Equipos Concentradores de Datos Como se ha comentado con anterioridad, este sistema es el encargado de recopilar todos los datos recogidos por los dispositivos inalámbricos. El cuerpo principal del sistema de adquisición está formado por el llamado coordinador que es el concentrador de datos o pasarela de red. Es el elemento último de la red al que van dirigidas las medidas recogidas por los elementos finales conectador a los contadores de agua y demás elementos de la red. Es un dispositivo complejo que contiene tanto al coordinador de la red inalámbrica como a un PC embebido y otra serie de elementos que completarán la funcionalidad esperada por el Concentrador de la red. 5.2.8.1 Arquitectura Hardware La arquitectura HW necesaria para el funcionamiento del Concentrador es la siguiente: Figura 5-27. Arquitectura Concentrador. Como se puede observar en la imagen anterior, el coordinador de la red inalámbrica está integrado dentro de la arquitectura general del concentrador de datos. De manera que los elementos HW que formarán parte del concentrador son los siguientes: coordinador de red, PC Embebido y otras interfaces de comunicaciones. 86 El coordinador de la red es presenta una estructura interna prácticamente similar a la de los dispositivos finales, ya que es él el que hace de interfaz entre la red inalámbrica y el resto de los sistemas. Sus bloques internos principales son: • Etapa de alimentación: El dispositivo concentrador completo de alimenta mediante una toma de red eléctrica a 230V, con lo que la etapa de alimentación debe ser tal que pueda convertir este tipo de alimentación en los niveles de tensión e intensidad requeridas por el módulo microcontrolador y por el resto de los periféricos del coordinador. • Etapa de adaptación: La conexión con la placa principal se hará mediante la UART disponible para ello. • Transceptor inalámbrico: El transceptor inalámbrico es el bloque encargado de convertir la información recogida en el microcontrolador en energía capaz de ser transmitida de manera inalámbrica. Dicho transceptor cumplirá con las especificaciones del estándar IEEE802.15.4, cuyos puntos principales son: o Dos bandas posibles. 2.4GHz o 868MHz, ambas son bandas libres ISM. Con lo que no hay que pagar ningún tipo de licencia por su utilización. o Potencia máxima de emisión (con especial cuidado a la selección de la antena). o Latencia de media de 4ms por cada paquete (provocado por los mecanismos de acceso al medio). o Carga útil entre 80 y 100 bytes por trama. La banda de frecuencia escogida para el proyecto será la banda de 2.4 GHz que viene impuesta por el módulo elegido. El uso de una antena de la ganancia necesaria para la mejora de la cobertura también está contemplado dentro de este bloque. • Módulo microcontrolador (CPU): El módulo microcontrolador es el bloque encargado de controlar a todos y cada uno de los elementos que forman parte del dispositivo. Por esto debe tener una capacidad de computación suficiente como para controlar a todos los periféricos sin descuidar la gestión de los datos y su envío a través de la red inalámbrica. Es un microcontrolador de bajo coste y con posibilidad de muy bajo consumo para optimizar el gasto que el mismo pueda tener. Además, dispone de memoria interna suficiente como para alojar a la aplicación completar que realizará las tareas previstas para cada dispositivo en concreto. • Periféricos: Además de los bloques nombrados, existe otra serie de bloques secundarios necesarios para el funcionamiento global de los dispositivos, de hecho, dentro de periféricos pueden englobarse los circuitos de adaptación mencionados en las etapas de adaptación externa y de alimentación. Estos periféricos se usan para complementar y depurar el funcionamiento del dispositivo. Como se ha comentado anteriormente el PC embebido es un sistema inteligente con alta capacidad de cálculo capaz de interpretar los datos enviados por el coordinador, almacenarlos y hacer de pasarela de comunicaciones con los sistemas externos de gestión. Básicamente tendrá una estructura de SBC (Single Borde Computer) con las interfaces necesarias para su conexión con los elementos con los que tenga que interactuar: • Conexión I2C y SPI. • Conectores genéricos para uso de puertos series, RS 232, RS485, etc., según necesidad. • Conector y driver USB. Aunque en la imagen el bloque de alimentación aparece prácticamente como una parte más del PC embebido, realmente es un elemento más del concentrador. Su función principal es la de convertir la tensión alterna que alimenta al dispositivo completo en una tensión continua dentro de un rango admisible para la electrónica utilizada en el concentrador. De manera independiente, cada uno de los elementos que componen el concentrador dispondrán de etapas de adaptación específica para el correcto funcionamiento de ellos mismos. La CPU del PC Embebido es un microcontrolador capaz de realizar complejas operaciones de comunicación y gestión de datos, siendo además capaz de controlar todos los periféricos que intervienen en el funcionamiento del equipo. Para la obtención de las coordenadas GPS se utiliza un dispositivo externo que esté permanentemente calculando la posición GPS y pueda ofrecer esta posición al PC embebido siempre que éste se lo requiera. De esta manera esta interfaz GPS debe tener la inteligencia justa para el cálculo de la posición GPS y que además permita la consulta y configuración de esta posición a través de una interfaz serie o similares. Para el envío de datos través de GSM se necesitará que se disponga de un puerto serie para ello, para así tener un sitio mediante el que se puedan enviar los datos directamente al servidor, se hará mediante un módulo externo que permitirá la conexión mediante una tarjeta SIM con una tarifa de datos. En muchas ocasiones, el mismo módulo GPRS, es capaz de realizar la función de localizador GPS de una forma relativamente precisa. Además, este mismo modulo, también puede ayudarnos a sincronizar los relojes de los dispositivos finales con toda la red. Esta funcionalidad que tienen los módulos GPRS nos servirá para que toda la red comporta un reloj síncrono común y podamos obtener las marcas temporales de los datos enviados por los sensores de la manera más precisa posible. 5.2.8.2 Arquitectura Software En este apartado se describen los principales bloques SW que operan concretamente dentro del PC Embebido y el camino que siguen los datos desde que son recibidos hasta que son enviados al servidor de la plataforma. Es importante señalar que todo el software que se desarrolla sobre el PC Embebido corre sobre la plataforma Arduino por lo que los dispositivos necesitarán disponer de protocolos de comunicación disponible. En cuanto a los principales bloques funcionales desarrollados se tienen los siguientes: Controlador de red Man y controlador GPRS. El bloque del Controlador de red Man es el encargado de recoger las tramas de datos enviadas por el coordinador procedentes de la red inalámbrica. Se encargará de recoger y procesar toda esta información de manera rápida y fiable para evitar pérdidas de información. El módulo que se encarga de ejercer como coordinador es el XBEE PRO S2C configurado en modo coordinador de la red, siendo el encargado de recibir los mensajes provenientes de los distintos nodos de la red y entregar esa información a la placa Arduino para su posterior envío a la red. La configuración de los parámetros se hace mediante el software del fabricante XCTU. Los parámetros para configurar este nodo son los siguientes: • PAN ID: este parámetro debe ser igual para todos los nodos de la red, ya que las redes se identificarán por su PAN ID, se puede usar un número arbitrario. • Coordinator enable: este parámetro sirve para indicar si el nodo es coordinador o no, en este caso si será coordinador por lo cual usamos el valor 1. • Encryption enable: sirve para activar el que haya seguridad en la red, se activará en este caso usando el valor 1. • Encryption options: configura las opciones de encriptado, en el caso del coordinador se usará el valor 2 ya que queremos que funcione como “trust center”, que será donde se compruebe que los nodos disponen de las credenciales para acceder a la red. • Encryption key: es la clave de acceso a la red, esta será la clave que necesitaran los dispositivos de la red para poder acceder a ella. • Network encryption key: es la clave que encripta las comunicaciones. • API enable: este parámetro permite configurar qué modo de comunicación usará el dispositivo, en este caso se usará el modo API enable with escaping. Configurados todos los parámetros a los valores indicados ya se tiene listo el módulo para la comunicación. Hay que tener en cuenta que esté módulo debe de tener siempre conexión a la red eléctrica por indicación del protocolo usado por el fabricante. La gestión del dispositivo se hace desde la placa principal, se busca un flujo simple para el funcionamiento, la idea general del funcionamiento del dispositivo es la de estar continuamente escuchando el medio de transmisión para cuando llegue algún paquete leerlo, comprobar si es correcto y en caso de que lo sea levantar una bandera para indicar al flujo principal que se tiene un nuevo dato para ser procesado. El bloque del Controlador GPRS es el encargado de darle salida a los datos provenientes de los end-devices hacia el servidor. Actúa como pasarela de los datos. 88 Este es el encargado de, mediante un método GET, enviar la información al servidor. La información va en una cadena que a su vez está incluida en una dirección web. Mediante esa petición los datos llegan a la plataforma AQUASIG para su posterior explotación. Este módulo no está continuamente enviando datos ya que muchos de ellos se repetirían, teniendo en cuenta también el desaprovechamiento de recursos que esto conllevaría, cuando se reciba un nuevo dato mediante el módulo ZigBee la rutina de funcionamiento levantará una bandera para indicar que hay un nuevo dato, esta bandera activará el bloque de envío de dato al servidor, el cual también incluirá la tarea de bajar la bandera cuando el dato ha sido enviado. Figura 5-28. Fragmento Código Concentrador. En la figura anterior se muestra un fragmento del código de la rutina del coordinador. En ella, se ve como la función “recibeXbee” escucha al módulo de comunicaciones IEE802.15.4 y si esta recibe alguna información de cualquier dispositivo final, esta levanta la bandera para que se puedan enviar estos datos a través del módulo GSM. 5.2.8.3 Integración Coordinador Finalmente, los elementos que fueron seleccionados para formar parte del coordinador son: • El Arduino MEGA como pc embebido. • El módulo XBEE PRO S2C para la comunicación con la red de sensores mallada. • Módulo AdaFruit FONA 800 para transmitir la información a la plataforma AQUASIG mediante GPRS. Figura 5-29. Concentrador Final. El código desarrollado para este coordinador está escrito en Arduino, el lenguaje de programación de la plataforma Arduino. Se han diseñado funciones específicas para obtener la hora local a través de la red GSM. Por último, se ha optado por no incluir funciones de ahorro de energía en los dispositivos coordinadores, debido a que estos dispositivos están expuestos a la recepción de información por parte de cualquier dispositivo productor en cualquier instante y deben de estar preparados siempre para el envío de tramas hacia la plataforma, además de que en campo podrán situarse en ubicaciones con conexión directa a la red eléctrica. Es por esto, que los concentradores de datos se situaran de manera individual en cada calle o manzana de viviendas ya que como máximo cada uno podrá direccionar 255 dispositivos en total. 5.3 Agente IoT El agente IoT está desarrollado usando NodeJS debido a la naturaleza orientada a eventos del sistema. Este, este preparado para la recepción de información desde diferentes protocolos como MQTT, HTTP, CoAP, etc. En nuestro caso, vamos a usar la implementación del agente para su uso sobre HTTP. Para el correcto funcionamiento del componente, este necesitara de un componente que le aporte persistencia en la información. Podemos usar tanto la memoria interna del dispositivo como una base de datos externa. En nuestro caso, para aumentar la eficiencia de la arquitectura, se desplegará junto al agente una base de datos de naturaleza no relacional de tipo MongoDB. Para el despliegue del agente, usaremos la tecnología dockers para encapsular dicho componente y crear un entorno de desarrollo aislado sobre este. Figura 5-30.Dockerfile Agente IoT. En la imagen anterior, se muestra un fragmento del fichero de configuración que recoge las características para desplegar el agente. Características como la dirección de la base de datos utilizada para la persistencia de la información o del proveedor de contenido son necesarias para la interrelación del agente con la plataforma. Los puertos por donde el agente escucha y la url también son configuradas en este fichero. Una vez confeccionado correctamente el fichero de configuración, bastaría con desplegar el contenedor apoyándose sobre este fichero. El agente necesitara, una vez esté en funcionamiento, establecer una serie de servicios los cuales el agente va a publicar el contenido, y denotar los dispositivos que van a enviar información al agente, además de sus 96 5.6 Consumidores de Información Los datos obtenidos mediante CYGNUS son almacenados en una base de datos MongoDB, una base de datos de carácter no relacional, caracterizada por su agilidad y escalabilidad. Este tipo de bases de datos, permiten cambiar los esquemas de datos de manera rápida cuando las aplicaciones evoluciona, aportando además un lenguaje completo de búsquedas y consistencia estricta. La replicación nativa y la tolerancia a fallos automática ofrece fiabilidad al sistema AQUASIG y flexibilidad operativa. La concentración de la información en la base de datos, permite confeccionar un análisis de dicha información a partir de técnicas de minado de datos, que facilitan la elaboración de informes de carácter histórico, la identificación de patrones y el cálculo de posibles escenarios futuros. Los desarrollos que utilizan las bases de datos donde se almacena toda la informacion extraida de los dispositivos productores de información queda fuera del marco del actual trabajo. Por esto, a continuación, se hará una explicación meramente descriptiva para exponer el uso que se le pueden dar a dicha información. En este caso, toda la información recogida en esta base de datos nos sirve para obtener información de consumo y calidad de agua para que dicha información sea usada tanto para usuarios de viviendas domesticas como de distribuidoras de agua. En lo que respecta a la parte del cliente, existe un motor web el cual se encarga de mostrarle la información en tiempo real de los parámetros de calidad del agua que le llega al mismo. Además, el cliente podrá comprobar el consumo del mes actual en el que se encuentra, pudiéndolo comparar con los resultados obtenidos mediante gráficas. Figura 5-40. Interfaz Web Cliente. Figura 5-41. Consumo Cliente. Conversión en Euros. En las figuras anteriores se ve como, además del consumo actual y los parámetros de calidad que el usuario percibe, a partir del consumo puede comprobar el precio de su factura obtenida mediante el precio del agua en la zona y las cuotas variables y fijas que esta tiene. Además, se podrá ver el consumo de meses anteriores para que el cliente pueda identificar patrones en ellos. En la siguiente imagen, se ve como la plataforma web te permite comparar tu consumo de agua con el de años anteriores para así poder identificar malos usos del agua y poder actuar sobre ellos. La información de consumo de agua junto con la adición de ciertos consejos de uso de agua, le facilitará al cliente la gestión de este recurso tan escaso y reducir sustancialmente el gasto mensual por este concepto. Ademas, gracias a la información de calidad de agua, el cliente tendrá una mayor transparencia acerca de lo que le esta consumiendo en cada instante. Figura 5-42. Comparativa de consumo de cliente. En cuanto a la parte web que involucra a la distribuidora, esta cuenta con sistemas propios de alertas los cuales se encargan de comprobar el estado del agua a través de la información obtenida de los dispositivos, y se encarga de enviar notificaciones a los responsables para su actuación. Este sistema de alertas, cuenta con diferentes estados en función del nivel de riesgo que conlleva para notificar y actuar de manera proactiva en función del mismo. Además del sistema de alertas, la parte de la distribuidora cuenta con una interfaz web la cual sirve de apoyo a los gestores de la misma para comprobar en cada instante el estado del agua en tiempo real. En él, se podrá escoger el dispositivo desplegado el cual se quiere comprobar su estado y se mostraran en él los datos obtenidos según la fecha de obtención de los mismos. En la siguiente figura se puede ver la interfaz web diseñada para la distribuidora. 98 Figura 5-43. Interfaz Web Distribuidora Ademas, para que los gerentes puedan contemplar los datos de cada parametro de calidad con mayor calidad, se pueden ver los mismos en una serie de graficas donde se podra tener otra perspectivas de los datos y poder identificar pendientes anomalas o posibles valores fuera de lo normal. Figura 5-44. Graficas parámetros de calidad (I). Figura 5-45. Graficas parámetros de calidad (II) 100 6 CONCLUSIONES ras haber investigado y recabado información acerca del objeto de nuestro estudio para poder llevar a cabo el desarrollo del presente proyecto, y desarrollado el sistema basándose en los elementos que mejor encajaban en el marco del mismo, el siguiente paso es estudiar el resultado y expresar las conclusiones obtenidas. Comenzaremos por fijarnos en los objetivos iniciales para sacar unas primeras conclusiones. Por tanto, podemos afirmar que se han cumplido los principales objetivos del proyecto: • Se ha conseguido desarrollar varios dispositivos que se encargan de la adquisición de las medidas necesarias para el proyecto. Dichas medidas se pueden englobar como medidas de parámetros de calidad de agua, medidas de consumo de agua, medidas de consumo eléctrico y medidas de presión. • Se han implementado unas placas que se ajustan perfectamente a las necesidades del proyecto, para actuar como cerebro del sistema de adquisición de datos y contando con los puertos suficientes para su posterior integración con el resto de los componentes de la arquitectura. • Se ha implementado en las interfaces de medida una etapa de comunicaciones que cuenta con un protocolo que encaja con las especificaciones requeridas en el proyecto, además de ser abierto y pudiendo ser usado sobre las bandas ISM. • Los protocolos de nivel de aplicación usados para la comunicación de los sensores son protocolos estándares en la industria como HTTP, protocolos de tipado de datos como JSON y protocolos de transporte como UDP. • Se ha desplegado satisfactoriamente los equipos concentradores de datos, los cuales son los elementos finales de la red de área local. Además, se le ha dotado al concentrador con una conexión tipo GSM para el envío de toda información referente a las interfaces de medida hacia la plataforma • Se ha diseñado un sistema avanzado para la óptima captura, normalización y tratamiento de información en tiempo real para el procesado de datos hacia la plataforma AQUASIG procedentes del sistema de adquisición de la medida desarrollados. • El software es configurable y reconfigurable a lo largo de todo su ciclo de vida, de manera al modificar sus parámetros se adapta y actualiza su comportamiento para satisfacer las nuevas restricciones. • La arquitectura diseñada cumple con los requisitos deseados para su desarrollo, para lo que se usan tecnologías Open Source ampliamente reconocidas, innovadoras y que ofrecen altas capacidades de integración, escalabilidad y flexibilidad con los sistemas existentes en las empresas distribuidoras de agua urbana, además de incorporar elementos de confiabilidad, seguridad y persistencia de la información, otorgando robustez al sistema. • Al desplegar los componentes de la plataforma en el marco de la gestión de datos de agua y de su T . Cuantos más datos tengamos, más posibilidades tenemos de ahogarnos en ellos. - Nassim Taleb - posterior procesado de estos a través de el motor web, hemos conseguido aumentar la eficiencia del sistema de distribución, pudiendo detectar anomalías en el uso del agua y en la calidad de la misma que puede llegar al cliente provocando posibles deterioros de la salud humana. • Además, se pueden obtener patrones de comportamiento, dependencias entre parámetros, tendencias, etc, que pueden ayudar al cliente a actuar sobre ellos para la reducción del consumo. 102 REFERENCIAS ! [1] [En línea]. Available: http://www.internet-of-things-research.eu/abo ut_iot.htm. [2] «What exactly is the “Internet of Things”?,» [En línea]. Available: http://postscapes.com/what-e xactly-is- the-internet-of-things-infographic. [3] «ARPANET,» [En línea]. Available: https://www.britannica.com/topic/ARPANET. [4] «The Internet Toaster,» [En línea]. Available: https://www.livinginternet.com/i/ia_myths_toast.htm. [5] [En línea]. Available: http://www.ieee802.org/15/pub/TG4.html. [6] [En línea]. Available: https://www.bluetooth.com/bluetooth-technology/radio-versions. [7] [En línea]. Available: https://www.iotforall.com/bluetooth-5-iot/:. [8] «WiFi Alliance,» [En línea]. Available: https://www.wi-fi.org. [9] [En línea]. Available: https://www.everythingrf.com/community/ism-frequency-bands. [10] [En línea]. Available: https://www.networkworld.com/article/3196191/lan-wan/wifi-s-evolving-role-in- iot.html. [11] [En línea]. Available: http://www.3gpp.org. [12] [En línea]. Available: https://www.qualcomm.com/invention/5g/internet-of-things. [13] [En línea]. Available: http://www.ieee802.org/3/. [14] [En línea]. Available: https://searchdatacenter.techtarget.com/es/definicion/Ethernet. [15] [En línea]. Available: http://www.3gpp.org/images/PDF/R13_IOT_rev3.pdf. [16] [En línea]. Available: https://www.huawei.com/minisite/iot/img/nb_iot_whitepaper_en.pdf. [17] [En línea]. Available: http://elb105.com/empezando-a-trabajar-con-nb-iot/. [18] [En línea]. Available: https://tools.ietf.org/html/rfc791#page-1. [19] [En línea]. Available: https://www.ietf.org/rfc/rfc2460.txt. [20] [En línea]. Available: https://tools.ietf.org/html/rfc2663. [21] [En línea]. Available: https://www.solvetic.com/page/recopilaciones/s/internet/caracteristicas-diferencias- protocolo-internet-ipv4-ipv6. [22] [En línea]. Available: https://www.zigbee.org/download/standards-zigbee-specification/. [23] [En línea]. Available: https://www.arrow.com/es-mx/research-and-events/articles/wireless-connectivity- for-the-internet-of-things-one-size-does-not-fit-all . [24] [En línea]. Available: https://slideplayer.com/slide/5983758/. [25] [En línea]. Available: https://tools.ietf.org/html/rfc6282. [26] [En línea]. Available: http://www.libelium.com/products/waspmote-mote-runner-6lowpan/. [27] [En línea]. Available: https://tools.ietf.org/html/rfc768. [28] [En línea]. Available: https://tools.ietf.org/html/rfc793. [29] [En línea]. Available: https://www.ecured.cu/Protocolo_de_Control_de_Transmisi%C3%B3n. [30] [En línea]. Available: https://es.ccm.net/contents/281-protocolo-tcp. [31] [En línea]. Available: http://mqtt.org. [32] [En línea]. Available: https://www.ibm.com/developerworks/ssa/library/iot-mqtt-why-good-for- iot/index.html . [33] [En línea]. Available: https://xmpp.org. [34] [En línea]. Available: https://xmpp.org/extensions/. [35] [En línea]. Available: https://www.omgwiki.org/dds/]. [36] [En línea]. Available: http://www.rfwireless-world.com/Terminology/DDS-protocol-architecture.html. [37] [En línea]. Available: http://www.rfwireless-world.com/Terminology/DDS-protocol-architecture.html. [38] [En línea]. Available: https://www.amqp.org]. [39] [En línea]. Available: https://www.electronicdesign.com/iot/understanding-protocols-behind-internet- things. [40] [En línea]. Available: https://tools.ietf.org/html/rfc6347. [41] [En línea]. Available: https://www.vocal.com/networking/datagram-transport-layer-security-dtls/ . [42] [En línea]. Available: https://tools.ietf.org/html/rfc2616 . [43] [En línea]. Available: https://concepto.de/http/. [44] [En línea]. Available: https://tools.ietf.org/html/rfc7252 . 104 [45] [En línea]. Available: [https://iot.telefonica.com/blog/2016/09/es-fiware-estandar-iot. [46] [En línea]. Available: http://toools.es/plataforma-fiware/. [47] [En línea]. Available: https://aws.amazon.com/es/iot/. [48] [En línea]. Available: https://cloud.google.com/solutions/iot/ . [49] [En línea]. Available: https://azure.microsoft.com/es-es/overview/iot/ . [50] [En línea]. Available: https://www.ibm.com/internet-of-things. [51] [En línea]. Available: https://www.FiWare.org/. [52] [En línea]. Available: https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/NGSI-9/NGSI- 10_information_model . [53] [En línea]. Available: https://fiware-orion.readthedocs.io/en/master/user/federation/index.html. [54] [En línea]. Available: https://fiware-iotagent-json.readthedocs.io/en/latest/. [55] [En línea]. Available: https://www.omaspecworks.org/what-is-oma-specworks/iot/lightweight-m2m- lwm2m/. [56] [En línea]. Available: https://fiware-iotagent-ul.readthedocs.io/en/latest/. [57] [En línea]. Available: https://fiware-lorawan.readthedocs.io/en/latest/ . [58] [En línea]. Available: https://www.thethingsnetwork.org/docs/lorawan/] . [59] [En línea]. Available: http://flume.apache.org. [60] [En línea]. Available: http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoophdfs/HdfsUserGuide.html. [61] [En línea]. Available: https://www.mysql.com/. [62] [En línea]. Available: http://ckan.org/. [63] [En línea]. Available: https://www.mongodb.org/. [64] [En línea]. Available: https://github.com/telefonicaid/IoT-STH. [65] [En línea]. Available: http://kafka.apache.org/. [66] [En línea]. Available: https://aws.amazon.com/dynamodb/. [67] [En línea]. Available: http://www.postgresql.org/. [68] [En línea]. Available: https://carto.com. [69] [En línea]. Available: https://flume.apache.org. [70] [En línea]. Available: https://wirecloud.readthedocs.io/en/stable/ . [71] [En línea]. Available: https://knowage.readthedocs.io/en/latest/. [72] [En línea]. Available: https://kurento.readthedocs.io/en/stable/. [73] [En línea]. Available: https://fiware-cosmos-flink.readthedocs.io/en/latest/ . [74] [En línea]. Available: https://fogflow.readthedocs.io/en/latest/. [75] [En línea]. Available: https://www.docker.com. [76] [En línea]. Available: http://www.ti.com/tool/ENERGIA. [77] [En línea]. Available: https://www.zigbee.org/zigbee-for-developers/zigbee-3-0/. [78] [En línea]. Available: https://www.digi.com/products/xbee-rf-solutions/2-4-ghz-modules/xbee-zigbee. [79] [En línea]. Available: https://www.digi.com/products/xbee-rf-solutions/xctu-software/xctu.