Modelo de red de estaciones meteorológicas con plataforma IOT

Texto completo

(1)MODELO DE RED DE ESTACIONES METEOROLÓGICAS MODULARES CON PLATAFORMA IOT. PRESENTADO POR JEFFERSON RICARDO CHIVATA CASTRO COD: 20102005059. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERIA INGENIERIA ELECTRÓNICA BOGOTÁ D.C. 2017.

(2) MODELO DE RED DE ESTACIONES METEOROLÓGICAS MODULARES CON PLATAFORMA IOT. PRESENTADO POR JEFFERSON RICARDO CHIVATA CASTRO COD: 20102005059. Proyecto de grado para optar por el tı́tulo de Ingeniero Electrónico. Director: Ing. MSc. César Andrey Perdomo Charry. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERIA ELECTRÓNICA BOGOTÁ D.C. 2017.

(3) CONTENIDO. Pág.. 1. RESUMEN. 5. 2. INTRODUCCIÓN. 7. 3. OBJETIVOS. 8. 3.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8. 3.2. Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8. 4. RED DE ESTACIONES METEOROLÓGICAS 4.1. DISEÑO DE LA ARQUITECTURA DE HARDWARE . . . . . . . . . . . . .. 9 9. 4.1.1. Elemento de adquisición de datos y actuadores . . . . . . . . . . . . . . 11 4.1.2. Estación meteorológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.3. Elemento de salida con conexión a internet (Gateway) . . . . . . . . . . 27 4.2. DISEÑO DE LA ARQUITECTURA DE SOFTWARE . . . . . . . . . . . . . . 29 4.2.1. Lógica de programación del sistema de adquisición de datos . . . . . . . 32 4.2.2. Red de comunicación inalámbrica Estación-Gateway . . . . . . . . . . . 33 4.2.3. Lógica de programación de las Estaciones Meteorológicas . . . . . . . . 37 4.2.4. Lógica de programación del elemento de salida Gateway . . . . . . . . . 39 4.2.5. Comunicación Gateway con la nube . . . . . . . . . . . . . . . . . . . . 40. 5. SOLUCIÓN EN LA NUBE PARA PERMITIR LA GESTIÓN DE LA INFORMACIÓN. 42. 6. CASO DE USO DE RECEPCIÓN Y ENVÍO DE DATOS REMOTAMENTE. 3. 45.

(4) 7. CONCLUSIONES. 54. 8. REFERENCIAS Y ANEXOS. 55. 4.

(5) 1.. RESUMEN. En Agosto del año 2015 en la Universidad Distrital se realizó un trabajo como proyecto de grado para la carrera de Ingenierı́a Electrónica, el cual se titula ’DISEÑO DE UNA ESTACIÓN METEOROLÓGICA MODULAR QUE PERMITA CONEXIÓN REMOTA Y GESTIÓN DE DATOS VÍA INTERNET’[1], en donde se muestra una propuesta de diseño e implementación de un prototipo de estación meteorológica modular. Los datos se obtienen por medio de una sola tarjeta, de la estación meteorológica, y se envı́an por módulos Xbee a Raspberry Pi que se utiliza como elemento de salida a internet. En esta tarjeta Raspberry Pi se implementa un programa de código abierto llamado WeeWX el cual se encarga de subir las mediciones a una base de datos MySQL que corre en un servidor remoto donde se presentan a través de una unica aplicación web alojada allı́ mismo los datos obtenidos. Ver Figura 1. Figura 1: Esquema de funcionamiento unidireccional. Fuente: Diseño de una estación meteorológica modular que permita conexión remota y gestión de datos via internet. Universidad Distrital, Facultad de ingenierı́a, proyecto de grado.. Basado en el trabajo anterior, en este proyecto se propone un modelo más completo y adaptable que permite la conexión modular de una forma más sencilla y que la información tenga la posibilidad de viajar en ambos sentidos (bidireccionalmente), con un recuadro de un extremo denominado ’Estaciones Meteorológicas modulares’ que representa el conjunto de estaciones en su totalidad, y del otro lado un recuadro denominado ’Dispositivos de visualización y/o control’ que representa los diferentes dispositivos electrónicos que interactúan a través de otro elemento llamado ’internet’ con el otro extremo. Ver Figura 2.. 5.

(6) Figura 2: Diagrama bidireccional general del sistema. Se describe a lo largo de este documento la estrategia para lograr el concepto de IoT por medio de analizar en un sentido el flujo de los datos de adquisición (desde los sensores) y en el sentido contrario a este flujo los datos de control (desde los Clientes Web), lo cual permite que en efecto de forma remota se puedan monitorear y a la vez realizar procesos de control al sistema. Usando la estrategia del protocolo de máquina-máquina llamado MQTT se realiza el envı́o de los datos de medición y de control ’publicándolos’ a nombre de una ruta en particular, y para la recepción de los datos a través de la ’suscripción’ a la ruta ya creada.. 6.

(7) 2.. INTRODUCCIÓN. El clima es uno de los temas más estudiados a nivel mundial desde diferentes ramas del conocimiento, posicionándose como uno de los problemas modernos más importantes y de mayor relevancia junto con el crecimiento poblacional[2]. Lo anterior se debe a que el clima influencia de forma directa positiva o negativa en las actividades económicas, en campos como el agrı́cola, de pesca, construcción, entre otros [3]. En el caso especifico de Colombia, se pueden evidenciar cambios climáticos de larga cobertura, además de microclimas diversos, gracias a aspectos geográficos y atmosféricos que generan diferentes formas de fenómenos meteorológicos causados por precipitaciones, radiación solar, temperatura, sistemas de vientos, altitud, continentalidad y humedad atmosférica[4]. Colombia cuenta actualmente con el Instituto de Hidrologı́a, Meteorologı́a y Estudios Ambientales IDEAM, que es una entidad pública encargada de prestar servicios de gestión de información sobre el estado y las dinámicas de los recursos naturales y del medio ambiente[5], enfocandose principalmente en el estudio del clima para con esto poder prevenir los efectos de variabilidad climática como El Niño y La Niña[6]. Sin embargo, cabe resaltar que para el 2012 solo el 12 % de las estaciones son automáticas, es decir que trasmiten datos en tiempo real[1]; esto genera un retraso en el uso de dichos datos y por ende, dificultades en modelamientos climatológicos como por ejemplo la predicción del clima para periodos cortos. Dicho lo anterior, para diferentes estudios realizados ya sea por entidades nacionales publicas o particulares, es necesario contar con multiple información meteorológica automática, y en lo posible de fácil acceso, para lo cual el IDEAM debe administrar los datos de las variables obtenidas en diferentes estaciones meteorológicas distribuidas por todo el territorio colombiano de forma eficiente. No obstante, dicha información aunque puede ser adquirida libremente debido a que es de carácter publico, es necesario dirigirse a un punto de atención del IDEAM y presentar una solicitud especificando la periodicidad de los datos y el código de la estación o estaciones más cercanas al punto de interés y luego de haber transcurrido el tiempo establecido es posible obtener la información, lo cual lo hace un proceso de consulta dispendioso[5]. Actualmente se han desarrollado estaciones meteorológicas modulares al alcance de cualquier organización o persona interesada en meteorologı́a y climatologı́a que desee tener independencia en la obtención de datos para uso particular como es el caso de un proyecto de grado de la Universidad Distrital Francisco José de Caldas, en donde se desarrolló una estación meteorológica la cual se conecta a internet para el envı́o de los datos pero de forma unidireccional con un modelamiento individual (solo una estación y solo un destinatario web)[7]. En consecuencia se plantea la siguiente pregunta: ¿Es posible diseñar un modelo de red con más de una estación meteorológica modular donde se integre los datos de dichas estaciones implementadas localmente y conectadas a internet, para que diferentes usuarios puedan administrar remotamente la información de forma bidireccional de acuerdo a su interés particular? 7.

(8) 3. 3.1.. OBJETIVOS. Objetivo General. Diseñar e implementar un modelo de red de estaciones meteorológicas modulares locales utilizando el internet de las cosas (IoT).. 3.2.. Objetivos Especı́ficos Diseñar e implementar un sistema de forma modular para entregar y recibir datos a un sistema conectado a internet. Diseñar e implementar un sistema en la nube que permita la gestión de la información de una red de estaciones meteorológicas remotas que integran diferentes sensores y actuadores aprovechando las caracterı́sticas de IoT. Comprobar la integración y unificación de la información obtenida de la red de Estaciones Meteorológicas a través de Internet de forma bidireccional en un aplicativo web remoto.. 8.

(9) 4. 4.1.. RED DE ESTACIONES METEOROLÓGICAS. DISEÑO DE LA ARQUITECTURA DE HARDWARE. Primero que todo es importante definir cada uno de los elementos que conforman de manera general el sistema para que de esta manera se logre una debida integración de las soluciones de diseño particulares. En la Figura 3, se muestra detallado solo el extremo de las ’Estaciones Meteorológicas modulares’ de la Figura 2 ya que para este caso es el único que cuenta realmente con un diseño de Hardware, en donde básicamente se inicia de izquierda a derecha con unos elementos de adquisición y actuadores que interactúan con una estación meteorológica correspondiente, las cuales por medio de un módulo de comunicación, que en este caso ya se define como inalámbrico por facilidad en el modo de uso, se les permite el envı́o de forma bidireccional de la información con un elemento de salida en común con conexión a internet denominado Gateway. Este modelo se estará desarrollando en los siguientes enumerados.. Figura 3: Modelo general con ambos sentidos de flujo de la información. 9.

(10) Para las pruebas del desarrollo de este proyecto se utilizó la tarjeta de desarrollo LaunchPad MSP-430F5529LP de Texas Instrument, ya que se considera un kit de desarrollo económico y sencillo para programar en lenguajes de bajo y medio nivel el microcontrolador MSP430F5529 en donde toda la tarjeta en su mayorı́a es de propósito general para el control de las funcionalidades del mismo. Además ofrece una manera fácil de comenzar a desarrollar en el MSP430, con emulación para depuración. Ver Figura 4.. Figura 4: Tarjeta de desarrollo www.ti.com/lit/ug/slau533c/slau533c.pdf. LaunchPad. MSP-EXP430F5529LP.. Fuente:. Cuadro 1: Caracteristicas más sobresalientes de LaunchPad MSP430F5529LP [8] Caracteristica Descripción Emulador Lite eZ-FET, con la aplicación UART. (Open-source) Pines 40 Conectores configurables hembra y macho Puertos USB Capacidad para emular y desarrollar aplicaciones USB con un solo cable USB. Hub USB. Consumo energético Bus de 5V reducido a 3.3 V usando un convertidor dc-dc. La interfaz de usuario que trae se limita de forma sencilla a botones y LED’s, y de forma externa la salida a pantallas u otros módulos por medio de sus pines (Ver Cuadro 1) previamente configurados del microcontrolador MSP430F5529 (Ver Figura 5) el cual muestra caracteristicas relevantes en el Cuatro 2.. 10.

(11) Figura 5: Asignación de pines microcontrolador http://www.ti.com/lit/ds/symlink/msp430f5529.pdf. MSP-EXP430F5529.. Fuente:. Cuadro 2: Caracteristicas más sobresalientes de microcontrolador MSP430F5529 [9] Caracteristica Descripción CPU 25MHz 16-bit Memoria RAM 8 KB GPIO Pins 63 Consumo energético 3.6 V hasta 1.8 V. 4.1.1.. Elemento de adquisición de datos y actuadores. Si bien cada Estación Meteorológica se plantea como un elemento integral, el flujo de la información para algunos de los elementos que la conforman tales como las unidades finales (actuadores y dentro de los elementos de adquisición los sensores), en un sentido estricto no es bidireccionales o las unidades no permiten el flujo de la información en más de un solo sentido por las propiedades mismas del Hardware ya sea solo haciendo entrega datos o solo recibiendo datos respectivamente.. Elemento de adquisición de datos Una de las caracterı́sticas más importantes en relación con un usuario final es la facilidad de uso que un dispositivo provee, por tal motivo se plantea que la estación meteorológica sea modular, es decir que permita la conexión de módulos a la misma; sin embargo esta conexión de los módulos básicamente esta direccionada a que sea conectar y usar (Plug-and-Play). Por 11.

(12) tal razón es que se debe diseñar cada modulo o elemento de adquisición como un circuito de interfaz sensor-microcontrolador, de modo que permita directamente ser añadido o quitado a una estación meteorológica local como se muestra en la Figura 6.. Figura 6: Diagrama de interfaz directa para elemento de adquisición. Para lograr la conexión de diferentes módulos al mismo tiempo en una estación en particular, se diseña la comunicación con I2C entre el microntrolador del elemento de adquisición (slave) y el microcontrolador de la estación (master); utilizando entre todos los elementos de adquisición la topologı́a en bus en donde solo hay un canal de comunicaciones y todos los dispositivos comparten el mismo canal.. Figura 7: Diagrama de conexión I2C de los elementos de adquisición a la estación. Como parte del diseño de Hardware es importante agregar que para el correcto funcionamiento de I2C, es necesario añadir dos resistencias de Pull-up; es decir una resistencia de cada una de las lı́neas del Bus de Datos hacia una fuente de alimentación (VCC), la cual será colocada o asumida por la tarjeta de la estación meteorológica, por lo tanto, no se tendrán en cuenta para el diseño de los diferentes módulos de adquisición de datos. 12.

(13) Con base a lo anterior, en el Software de Easily Applicable Graphical Layout Editor - Eagle, el cual es un programa que permite el diseño de diagramas y PCB’s, que tiene una gran cantidad de herramientas, librerı́as y funcionalidades que permite de forma fácil y profesional la creación de tarjetas electrónicas, se hace el diseño de cada uno los componentes que se necesitan para el correcto funcionamiento de los elementos de adquisición. En primera instancia, en la Figura 8 se encuentra una parte del esquemático en donde se muestra como parte esencial el microcontrolador de la tarjeta, las partes básicas para su correcto funcionamiento dentro de lo cual está el reloj, un botón de Reset y voltajes de referencia.. Figura 8: Esquemático con Microcontrolador, reloj y voltajes de referencia diseñado en EAGLE.. Por otra parte, en la Figura 9 se encuentra las conexiones a puertos de una forma genérica, ya que en este caso se pretende por cuestión de costos que se pueda utilizar el mismo diseño y tarjeta para que interactúe de una forma más sencilla con cualquier sensor correctamente configurado que se quiera acoplar. Cuando se utiliza con un diseño de tarjeta de propósito especı́fico, evidentemente la cantidad de conexiones se reduce de manera notoria tanto en tamaño como en versatilidad.. 13.

(14) Figura 9: Esquemático con puertos de conexión y testigos diseñado en EAGLE.. Una vez se genera toda la parte referente al esquemático, se hacer la relación y organización de cada uno de los componentes sobre la tarjeta o board de la manera más conveniente para la interacción con la misma. Para este caso en la parte superior derecha se diseña la tarjeta para que los pines de programación y alimentación queden un poco más aislados y visibles a la perspectiva del usuario. En la parte izquierda y derecha de la tarjeta se propone dos buses de datos de que pueden ser utilizados de forma genérica par a los sensores que se quieran utilizar. Además la tarjeta cuenta con un testigo LED y un botón de Reset. Ver Figura 10.. Figura 10: PCB final de tarjeta del sensor diseñada en EAGLE.. 14.

(15) Es importante igualmente visualizar en un visor de paquetes los componentes en tercera dimensión y ası́ dar una mejor idea del modelo y que va de acuerdo a lo propuesto. Ver Figura 11.. Figura 11: Visualización en tercera dimension de la PCB con sus compenentes. Fuente: http://3dbrdviewer.cytec.bg/. Una vez terminado el diseño de la tarjeta encargada de recibir los sensores; en el costado izquierdo de la Figura 12 se muestra la foto de la PCB en un estado finalizado pero sin componentes y en el lado derecho de la misma imagen una foto donde los componentes, en su mayorı́a superficiales, han sido debidamente colocados y probados para garantizar el correcto funcionamiento.. Figura 12: Resultado final de la tarjeta para los sensores. Para la programación de las tarjetas se utilizó Code Composer Studio, un entorno de desarrollo integrado (IDE) de TI (Texas Instruments) para microcontroladores, ya sea la creación 15.

(16) y edición de código fuente, compilación, depuración e integración del programa al microcontrolador o procesadores integrados. Incluye una optimización del compilador C/C++. El IDE es de media dificultad de uso pero proporciona buena documentacion para el desarrollo de aplicaciones de sistemas embebidos. Para finalizar se describirán de forma sencilla y puntual algunos de los sensores más comunes y las variables que se pueden medir recopilados en el Cuadro 3. Cuadro 3: Variables principales con su respectivo intrumento de medición[10] Variable Instrumento Dirección del viento Veleta Velocidad del viento Anemómetro Presión atmosférica Barómetro Humedad del aire Higrómetro Precipitación Pluviómetro Temperatura Termómetro. Anemómetro: Este sensor mide la velocidad del viento (m/s) y utiliza un molino de tres aspas que en su extremo posee cazoletas, el cua gira en el momento en que el viento sopla y de esta manera se obtiene el registro de vueltas, bien sea dado directamente por un contador o registrado sobre una banda de papel; con esto se calcula la velocidad[11] Para el diseño del anemómetro por contador es suficiente con generar uno o varios puntos de referencia con el objetivo de detectar el momento en el que se pasa por este punto.. Figura 13: Diagrama de sensor https://www.thingiverse.com/thing:41367. con. punto. de. referencia.. Fuente:. Como se muestra en la Figura anterior, se establece un solo punto conformado por un par de sensores (transmisor y receptor) los cuales se encuentran de forma estática en un solo punto. En medio de ellos se coloca un disco perforado que gira de acuerdo al 16.

(17) eje que se encuentra sujeto a las aspas que reciben el impacto del viento y generan el movimiento. El disco perforado cuenta con dos agujeros, uno a cada extremo de la pieza, con el objetivo de no dejar puntos ’muertos’ o ’ciegos’ al momento de medir sobre todo en el caso de estar moviéndose a una velocidad muy baja. Cada vez que el sensor pasa por un agujero del disco genera un nivel en alto y cada vez que pasa por un punto no perforado del disco genera un nivel en bajo. Esta actividad se hace ciclicamente hasta obtener una serie de pulsos a partir del cual es posible sustraer la frecuencia y calcular la velocidad con la siguiente fórmula: V = 5 ∗ f − 0,0005 ∗ f 2 − 0,000014 ∗ f 2. (1). La ecuación 1 resulta de poder medir el valor captado por el sensor de acuerdo a la velocidad de un objeto donde se conozca la velocidad a la que viaja, como por ejemplo de un carro moviendose en diferentes direcciones y a distiantas velocidades. Seguidamente se interpolan los resultados y se grafican para ası́ obtener la ecuación que describe el comportamiento.. Figura 14: Gráfica de resultados de https://www.thingiverse.com/thing:41367. la. medida. e. interpolación. del. sensor.. Este sensor también cuenta con un diseño de cada una de las piezas en tercera dimensión lo cual fue útil para el proyecto con el fin de poderlas imprimir en una impresora 3D y ası́ proceder a armar toda la estructura del mismo como se muestra en la Figura 15.. Figura 15: Diagrama 3d sensor. Fuente: https://www.thingiverse.com/thing:41367. 17.

(18) La estructura del anemómetro es dividida en tres partes relevantes las cuales son: Una cabecera compuesta de los aspas y el eje, otra parte es el cuerpo donde se encuentra el disco perforado y los sensores, y por ultimo un soporte para sostener todo el sensor en su conjunto. Para facilitar el movimiento y generar baja fricción entre la cabecera y el cuerpo se propone el uso de unos rodamientos. El resultado se puede evidenciar en la Figura 16 y Figura 17.. Figura 16: Impresora 3D Makerbot Replicator 2x (Izquierda). Página de diseño 3D Makerbot (Derecha). Figura 17: Anemómetro finalizado e implementado. Veleta: Es un instrumento sencillo que indica la dirección del viento y consta de un eje sobre el que está colocado un señalador, el cual debe ofrecer la menor resistencia al aire. Gracias a que la dirección del viento es la misma hacia donde apunta la veleta, 18.

(19) es importante poseer una ubicación correcta de la misma por lo que es necesario que sea colocada a la mayor altura posible sobre la superficie del suelo y además debe estar alejada de cualquier obstáculo que interfieran o provoquen alteraciones en las corrientes de aire como edificios, arboles etc.[12] Al contrario del anemómetro, este sensor debe ofrecer la menor resistencia al aire posible, ya que más que girar con el viento, debe permitir evidenciar la dirección en la que el viento se dirige.. Figura 18: Diagrama de interfaz directa para elemento de adquisición. Fuente: https://www.thingiverse.com/thing:42858. En este caso la veleta cuenta con la misma tecnologı́a del sensor anterior, con la diferencia que tiene cinco pares de sensores los cuales al momento de estar en alto o en bajo y por la perforación del disco al interior del cuerpo de la estructura, permite saber la posición en la que se encuentra por el número en bits que se registra.. Figura 19: Disco con números de https://www.thingiverse.com/thing:42858. bits. posibles. por. perforaciones.. Fuente:. La estructura de la veleta podrı́a dividirse en tres partes relevantes las cuales son: Una cabecera compuesta por veleta y punta, otra parte es el cuerpo donde se encuentra el 19.

(20) disco perforado y los sensores, y por ultimo un soporte para sostener todo el sensor en su conjunto. De la misma manera entre la cabecera y el cuerpo se propone el uso de unos rodamientos.. Figura 20: Diagrama sensor 3d. Fuente: https://www.thingiverse.com/thing:42858. El resultado del impreso se puede evidenciar en la Figura 21.. Figura 21: Veleta finalizada e implementada. Temperatura: Instrumento que permite medir la temperatura de un ambiente en diversas horas del dı́a. Se conocen diversos tipos de termómetros utilizados en meteorologı́a, de donde los más comunes son el termómetro de extremas y el termómetro de suelo; el primero se obtiene las temperaturas mı́nima y máxima ocurridas en un instante de tiempo que comúnmente es un dı́a; por otra parte el termómetro de suelo penetra verticalmente hacia arriba y se utiliza a poca profundidad, teniendo el depósito de mercurio encerrado en una varilla recta [13].. 20.

(21) Actuadores Al igual que los elementos de adquisición los actuadores también deben ser de fácil uso, por lo cual en este caso y a diferencia del anterior, los actuadores estarán integrados en la misma tarjeta de las estaciones meteorológicas; y aunque se considerará como un módulo independiente, su manipulación e integración se manejaran de forma estática y a partir de determinadas instrucciones recibidas por la estación enviará al respectiva señal de control a los actuadores y utilizadas a conveniencia del mismo usuario final.. 4.1.2.. Estación meteorológica. Luego de tener listo el diseño fı́sico de algunos de los módulos que se pueden conectar, se procede al diseño de la estación meteorológica teniendo en cuenta que se va a encargar de coordinar la información de cada uno de estos elementos. Cada uno de los bloques de la Figura 22 representa una funcionalidad y/o módulo de la estación (El recuadro ’Actuadores’ aunque si bien se encuentra fijo en la tarjeta de la estación meteorológica, se coloca por aparte para mostrar que es un módulo independiente).. Figura 22: Diagrama de bloques estación meteorológica. 21.

(22) A continuación se muestra una descripción del diseño de los bloques de la Figura anterior. Sistema de alimentación y carga: Por tratarse de una estación meteorológica que va a ser colocada en lugares donde la conexión a una fuente de alimentación fija como una toma corriente no es posible, es necesario recurrir a otras tecnologı́as para la obtención de la energı́a como son los paneles solares. Dichos paneles solares se encargan de tomar la energı́a del sol y transformarla en corriente eléctrica, no obstante, esta corriente por depender de un agente externo no es uniforme y constante, ya que cuando hay ausencia u obstrucción de la fuente solar esta disminuye o desaparece, y cuando hay aumento de la fuente solar por no ser aprovechada o consumida en su totalidad se pierde; por tal motivo es necesario contar con un sistema que cuente con un gestor baterı́as y energı́a, un elemento de almacenamiento que en este caso será una Baterı́a LiPo por sus caracterı́sticas de mayor densidad de la energı́a, tasa de descarga y ligereza, y por ultimo un panel solar encargado de suministrar la energı́a. Microcontrolador: Para el microcontrolador de la estación meteorológica se seleccionó el MSP430F5529 por sus caracterı́sticas de bajo consumo y memoria RAM que se ajusta a las necesidades del proyecto (Ver Figura 5 y Cuadro 2). Este microcontrolador cuenta con los componentes eléctricos básicos para el funcionamiento, los puertos habilitados y fácil conexión tanto del puerto I2C en donde se conectarán los elementos de adquisición, el puerto serie de comunicación UART, entre otros. Interfaz de programación: Para la facilidad de programación y manipulación del microcontrolador ya fijado en la tarjeta de desarrollo de la estación meteorológica, es conveniente como parte del diseño dejar una interfaz o unos sockets disponibles para versatilidad al momento de cargar un programa. Teniendo claro todas y cada una de las etapas o partes que componen la estación meteorológica (Figura 22), al igual que en el diseño de los elementos de adquisición se propone tres esquemáticos. El primero de ellos que aparece en la Figura 23, muestra un esquemático con relación a las conexiones de energı́a que va a utilizar la tarjeta. En la parte superior izquierda se muestra la entrada microusb que permite la alimentación a toda la tarjeta ya sea por medio de un cargador de 5 V convencional, o como se nombró anteriormente, con la alimentación provista por un panel solar cuando no se dispone de una toma corriente cercana y utilizar fuentes de energı́a alternativas. La alimentación eléctrica de entrada es suministrada y gestionada por un cargador de baterı́as que se encuentra en la parte superior derecha del esquemático, quien se encargará de tomar 22.

(23) la energı́a y realizar dos labores, tanto energizar toda la tarjeta y los componentes que se conecten desde una baterı́a LiPo, como también de recargar y mantener disponible la energı́a en dicha baterı́a. Finalmente en la parte inferior de la imagen se garantiza por medio de un regulador la debida alimentación a toda la tarjeta.. Figura 23: Esquemático de alimentación y carga diseñado en EAGLE.. Para el siguiente recuadro del esquemático que se encuentra en la Figura 24, es importante notar que es básicamente la misma configuración que la Figura 8 ya que solo contiene el mismo microcontrolador con cada uno de los elementos básicos que se necesitan para su funcionamiento (Microcontrolador, Reloj, voltajes de referencia, botón de Reset).. Figura 24: Esquemático con Microcontrolador, reloj y voltajes de referencia diseñado en EAGLE.. 23.

(24) Para el último recuadro del esquemático mostrado en la Figura 25, se amplı́a la posibilidad de testigos y de botones con los cuales se puede interactuar. Además de esto de agrega una ranura de conexión de más en donde se hará la respectiva conexión de los sensores al bus I2C.. Figura 25: Esquemático con puertos de conexión y testigos diseñado en EAGLE.. En la Figura 26 se organiza cada uno de los elementos que hacen parte de este diseño de la estación meteorológica. En la parte superior izquierda se coloca la entrada de alimentación; en la parte superior central el regulador; en seguida de la parte superior el administrador de baterı́as; en la parte central el micronctrolador; y por último en la parte externa de la tarjeta (izquierda y derecha) los puertos que serán utilizados para llevar a cabo las diferentes tareas como son el uso de UART, I2C, entre otros.. Figura 26: PCB final de tarjeta de la estación diseñada en EAGLE.. Finalmente, en la Figura 27 se muestra una vista superior del modelo en tercera dimensión de los paquetes de la estación meteorológica.. 24.

(25) Figura 27: Visualización en tercera dimension de la PCB con sus compenentes. Fuente: http://3dbrdviewer.cytec.bg/. Para la comunicacion inalambrica de los datos que se van a enviar y recibir se utiliza el Xbee. Xbee es un dispositivo electrónico que permite la interconexión y la comunicación inalámbrica entre ellos y aunque estos modulos cuentan con varias referencias y tecnologias, permite en su mayoria la misma configuración de sus pines independientemente de estos modelos. Estos módulos utilizan el protocolo de red llamado IEEE 802.15.4 para crear redes para punto a punto o punto a multipunto. Fueron diseñados para aplicaciones que requieren de un alto tráfico de datos, baja latencia y una sincronización de comunicación predecible basado en el protocolo Zigbee. En términos simples, los XBee son módulos inalámbricos fáciles de usar[16]. Una vez terminado el diseño de la tarjeta de la estación; en el costado izquierdo de la Figura 28 se muestra la foto de la PCB en un estado finalizado pero sin componentes y en el lado derecho de la misma imagen una foto donde los componentes, en su mayorı́a superficiales, han sido debidamente colocados y probados para garantizar el correcto funcionamiento.. Figura 28: Resultado final de la tarjeta para la estación meteorológica. 25.

(26) 4.1.3.. Elemento de salida con conexión a internet (Gateway). Como elemento de salida con conexión a Internet y que permite una fácil programación se seleccionó la tarjeta de desarrollo Raspberry Pi 3 la cual será la encargada de tomar toda la información de las estaciones meteorológicas a través de un módulo de comunicación inalámbrica conectado al (GPIO - general purpose input/output). Ver Figura 29 y 30. En esta tarjeta se utilizará igualmente el módulo Xbee y su modo de funcionamiento se desarrolla en la sección de Diseño de Software. La Raspberry Pi es una tarjeta de desarrollo similar a un computador usual pero más limitado, de bajo costo y bajo consumo del tamaño de una tarjeta de crédito. Cuenta con la posibilidad de instalar y configurar un sistema operativo, el cual debe ser instalado en la SD que va en una de sus ranuras, lo que permite desarrollar y correr diferentes tipos de Software[17].. Figura 29: Tarjeta de desarrollo Raspberry Pi. Fuente: www.raspberrypi.org. Figura 30: Entradas y salidad de proposito general (GPIO) de tarjeta de desarrollo Raspberry Pi. Fuente: www.raspberrypi.org/documentation/usage/gpio/. 26.

(27) Cuadro 4: Caracteristicas más sobresalientes de Raspberry Pi 3 [17] Caracteristica Descripción CPU 1.2GHz 64-bit quad-core ARMv8 Memoria RAM 1 GB GPIO Pins 40 Puertos USB 2.0 4 Red de conectividad Ethernet (RJ-45), Wifi 802.11n, Bluetooth 4.1 Consumo energético 800 mA, (4.0 W). En las Figuras 31 y 32 se evidencia el resultado de tarjeta que se implementa en la Raspberry Pi.. Figura 31: Esquemático y PCB de tarjeta para Raspberry Pi. Figura 32: Tarjeta para Raspberry Pi. 27.

(28) 4.2.. DISEÑO DE LA ARQUITECTURA DE SOFTWARE. Actualmente dentro de la tecnologı́a del mundo de los dispositivos conectados a internet IoT se encuentran implementados diferentes protocolos ya estructurados como por ejemplo MQTT, REST, CoAP, STOMP, ZeroMQ, OpenWire y AMQP. Sin embargo, Message Queue Telemetry Transport - MQTT[18] permite tener una buena experiencia por ser un protocolo de mensajerı́a sencillo y ligero, diseñado para dispositivos limitados, para un bajo ancho de banda y latencia alta o redes no confiables, y para mejorar el uso de la energı́a de la baterı́a. MQTT es un protocolo inventado por IBM y hace referencia a la comunicación machine-tomachine (M2M) por medio de un conjunto de reglas basadas en publicaciones y suscripciones como se muestra en la Figura 33, en donde un cliente ’publica’ su información enviándola a un broker o nodo central que se encarga de mantener activo el canal gestionando la información recibida y transmitiéndola a uno o varios nodos que se encuentren ’suscritos’ al cliente que entrego los datos.. Figura 33: .. Los datos de la comunicación se fundamentan en unos temas (topics) que el cliente inicial publica con su respectivo mensaje, y los nodos que desean recibirlo se suscriben a ese tema; dicho tema se representa por una cadena jerárquica separada por ’/’ como una ruta a seguir (Ver Figura 16).. 28.

(29) Figura 34: .. Aunque el problema planteado en este proyecto puede tener diversas soluciones en Software, continuando con el planteamiento de la Figura 2, una forma sencilla de abordarlo es simplificar todo el sistema a un conjunto de tres elementos individuales donde uno de ellos actúa como un nodo central en topologı́a estrella y debido a la organización resultante del sistema simplificado es posible adoptar una serie de reglas basadas en publicaciones y subscripciones siguiendo la metodologı́a usada en el protocolo MQTT (Ver Figura 33), en donde un extremo hace la publicación de los datos al nodo central, quien se encarga de gestionarla como una ruta de tema y lo envı́a a cada uno de los suscritos a dicha ruta en otro extremo. Sin embargo, por ser un sistema que trabaja de forma bidireccional, es importante mirar a cada uno de los nodos de los extremos como un publicador y como un suscriptor dependiendo el sentido en el que se haga el envı́o de los datos. De acuerdo a lo anterior, en la Figura 35 se muestra un diagrama unidireccional de las estaciones meteorológicas actuando como publicadoras a un Broker central en donde los datos suministrados hacen relación de forma más puntual al valor obtenido de los sensores que integran este bloque como se vera mas adelante, y el nodo del lado derecho de dispositivos de visualización como elementos suscritos a la ruta que ha publicado el valor de interés como pueden ser servicios de Internet, aplicaciones de escritorio o móviles, entre otros suscritos que 29.

(30) estén interesados en la información publicada.. Figura 35: .. A su vez, la Figura 36 muestra como al tomar la dirección en la que viajan los datos en el otro sentido; estos servicios Web, aplicaciones de escritorios o móviles pasan a ser los dispositivos de control quienes se encargan de publicar los datos en el broker y para que en este caso se puedan aplicar a uno de los actuadores asociados a la ruta.. Figura 36: .. A continuación se desarrollará de forma más especifica el diseño lógico que se tendrá en cuenta para el desarrollo del Software de cada uno de los elementos individuales y de esta manera lograr la solución propuesta anteriormente.. 4.2.1.. Lógica de programación del sistema de adquisición de datos. Aunque los elementos actuadores no requieren una lógica de programación ya que solo se encargan de recibir una señal de entrada booleana (Alto/Bajo), no sucede lo mismo para el 30.

(31) caso de los elementos de adquisición quienes deben interactuar con el microcontrolador de la estación meteorológica de una forma sencilla pero a la vez coordinada permitiendo ası́ tanto la adición de nuevos elementos de adquisición como el continuo envı́o de los datos desde los sensores. Por tal razón se considerará cada una de las actividades de los microcontroladores como una tarea individual (Task) dentro de un programa basado en Multitarea (Multitasking), donde unas tareas tendrán mayor complejidad que otras pero todas se podrán realizar de manera rápida y eficaz, y si bien no son rigurosamente simultaneas, sı́ se manejaran cercanamente a múltiples tareas en paralelo.. Tarea de petición y suministro de información de nuevo sistema de adquisición de datos: Esta tarea hará parte del Multitarea del microcontrolador que se encuentra en cada uno de los sensores, el cual se encargará de que una vez sea conectado el sensor de forma fı́sica al módulo I2C, enviar a la estación el carácter del sensor que tiene integrado con el fin de identificarse como un nuevo elemento reconociendo todas las caracterı́sticas de su sensor y ası́ obtener una nueva dirección de I2C que se le asignará con la cual podrá hacer peticiones más adelante al momento de enviar datos de su sensor. (ver Figura 37).. Figura 37: Diagrama de interacción entre Elemento de Adquisición y Estación Meteorológica.. Tarea adquisición de datos: Esta tarea hará parte del Multitarea del microcontrolador que se encuentra en cada uno de los sensores y simplemente se encargará de una vez sea identificado y otorgado una dirección de I2C de la terea anterior, hacer peticiones a las estaciones meteorológicas para poder entregar los datos del respectivo sensor. 31.

(32) 4.2.2.. Red de comunicación inalámbrica Estación-Gateway. Este punto es tomado por aparte ya que es importante mostrar de forma más detalla la comunicación y la coordinación que se tiene en cuenta para la debida gestión de la información. Esta tarea es una de las iniciales para las Estaciones y actúa en conjunto con una tarea del Gateway. Para comenzar se aclarará los conceptos respecto a topologı́as en el área de las comunicaciones y el Zigbee. Para el primer concepto a tener en cuenta, en la teorı́a de redes de comunicación, existe una clasificación de acuerdo a la tecnologı́a o configuración que esta maneja. Uno de los tipos más esenciales y sencillos es la topologı́a punto a punto que hace referencia al enlace más simple que se genera entre solo dos puntos o nodos, que fue la utilizada para conectar los actuadores a la Estación Meteorológica. Ver Figura 38.. Figura 38: Topologı́a punto a punto.. También es posible encontrar la topologı́a de la Figura 39, denominada topologı́a en bus y utilizada para la conexión en I2C de los sensores a la tarjeta de la Estación Meteorológica ya que se permite la transmisión de información por un solo canal a cualquier dispositivo particular mientras que las otras escuchan, dejando que todas los demás dispositivos que no son requeridas igualmente reciban la información que se transmite pero no respondan[19].. Figura 39: Topologı́a en bus. 32.

(33) Aunque existen muchas más topologı́as, por último y de mayor interés en esta sección es la Topologı́a de red en estrella (punto a multipunto) ya que esta arquitectura de red todos los nodos se conectan entre si pasando por un nodo central que trabaja de forma maestra por medio de uno más caminos y va a ser la utilizada en la comunicación inalámbrica entre las Estaciones y el Gateway utilizando módulos Xbee[20].. Figura 40: Topologı́a con controlador central. Como segundo concepto a tener en cuenta es el protocolo Zigbee que consiste según la página oficial Zigbee como ’una alianza y un estándar de redes en estrella de eficiencia energética y de costos. XBee utiliza el estándar Zigbee y lo agrega y envuelve en un pequeño empaque elegante’[21]. El protocolo Zigbee ofrece tres tipos de elementos como se muestra en la Figura 41. Figura 41: .. 33.

(34) Coordinador ZigBee (ZigBee Coordinator, ZC): Este es el nodo más activo de la red ya que es el encargado de establecerla inicialmente, almacenando la información sobre la red, seguridad y coordinación. Por red se encuentra solo un dispositivos de estos.. Router ZigBee (ZigBee Router, ZR): Estos dispositivos de nodo actúan como elementos intermedios, cuya funcionalidad principal es retransmitir los datos a otros nodos conectados a él.. Dispositivo final (ZigBee End Device, ZED): Estos dispositivos a diferencia de los dos anteriores tienen la funcionalidad de comunicarse solamente con el Coordinador o Router que lo posee en una de sus ramas ya que el no tiene ningún nodo más a su cargo, por ende su consumo es más reducido.. Una vez aclarados estos dos conceptos, en primera instancia encontramos para este proyecto el uso de los módulos Xbee en la comunicación inalámbrica como se ha dicho con anterioridad, ya que permiten una comunicación tanto de punto a multipunto, como de multipunto a un solo punto aprovechando su estándar Zigbee que cuenta con diversos componentes a la hora de abordar problemas de este tipo por el envı́o de datos de forma bidireccional que se requiere; un solo nodo Coordinador a varios nodos denominados dispositivos finales, ası́ como de estos múltiples dispositivos finales a un solo punto común Coordinador. ver Figura 41.. Dicho Coordinador será configurado en el Xbee del Gateway (Raspberry) el cual se encargará dentro de la red de iniciar el intercambio de datos con un solo dispositivo final seleccionado dentro de la red (Estación Meteorológica). Para el diseño de la solución se propone que cada periodo de tiempo desde el momento en que las estaciones son energizadas envı́an en forma de broadcast al coordinador un código de quererse acoplar y el usuario que quiere que se integre a un Gateway en especı́fico, de forma manual deberá accionar un botón para que de forma automática se haga el reconocimiento y sincronización. 34.

(35) Figura 42: Diagrama de interacción entre Gateway una estación nueva y las estaciones ya existentes.. En la Figura anterior se muestra cómo luego de accionar un pulsador en la tarjeta del Gateway a la cual se quiere integrar; el Gateway suspende o silencia la comunicación con las otras estaciones meteorológicas que se encuentran activas en ese mismo instante para darle paso a la comunicación particular con la estación que hasta ahora ingresa a la red de comunicación. Esta nueva estación se encarga de proporcionar la información necesaria para que se pueda enviar a la nube, con el fin recibir un código de aprobación con el cual podrá asociarse a una ruta que se creará para los módulos que se vayan conectando donde los sensores pueden publicar los datos medidos por medio de las Estaciones. 35.

(36) Una vez se le asigna este código único a la estación recién integrada, el Gateway se encarga de enviar el código de reactivación ’ $ ’ para continuar con el funcionamiento normal junto con todas y cada una de las estaciones que ya se encuentran en la red de comunicación.. 4.2.3.. Lógica de programación de las Estaciones Meteorológicas. De la misma manera que los elementos de adquisición, las actividades del microntrolador de las estaciones meteorologicas tambien seran desarrolladas como tareas individuales de una multitarea. Tarea de busqueda y asignación de nueva dirección I2C al nuevo sistema de adquisición de datos: Dado que cada uno de los sistemas de adquisición cuando son conectados por primera vez responden a la dirección I2C que traen por defecto (Dirección 0X02h), es el dispositivo maestro o en este caso la estación meteorológica quien inicia la petición a esa dirección y una vez encuentra una respuesta, como se veı́a anteriormente, es realmente cuando el microcontrolador que trae el sensor responde y es capaz de interactuar con él. (Ver Figura 42).. Figura 43: Diagrama general con suscriptor a la izquierda y publicador a la derecha. La Figura 43 describe cómo una de las tareas de la estación meteorológica se encarga de cada determinado tiempo enviar una petición a la dirección de nueva estación con el fin de hallar una respuesta y de ser ası́, poder en primera medida identificar la clase de sensor conectado y en segunda medida asignar una nueva dirección I2C a dicho dispositivo con el fin de liberar la dirección por defecto 0X02h y poder dar paso a futuros nuevos dispositivos que se acoplen. Tarea lectura de datos desde sistemas de adquisición: Esta tarea se encarga de tomar todos los valores que se encuentran en los sensores y enviarlos cada determinado 36.

(37) tiempo. Para este ejercicio, se considera que el microcontrolador hace una petición a cada una de las direcciones I2C activas de los módulos que se encuentran conectados a la tarjeta de la estación guardándolas en la memoria y refrescándolas cada vez que se haga esta tarea cada determinado periodo de tiempo. Liberar direcciones I2C: Es importante saber que las direcciones del bus I2C en primera instancia son definidas y en segunda instancia es necesario saber cuándo módulos ya no se encuentran conectados o activos, por un lado para no hacer dispendioso el trabajo de llamar direcciones que no ya no están en uso en todo momento, tanto como para poder volver a usar direcciones. Básicamente consiste en que si un dispositivo no responde después de determinadas veces, es descartado como una dirección disponible y colocada como disponibles. Envı́o de datos de las estaciones por XBee: Una vez los sistemas de adquisición de los sensores responden con sus datos, se toma la información de todos estos sensores y se organiza en formato JSON para ser transmitido por UART a través del módulo Xbee el cual permite por las caracterı́sticas del protocolo Zigbee enviar varios datos de forma estable y segura por su sistema de rectificación. Esta tarea inicia luego de que el Broker o Gateway selecciona en forma de Broadcast el código de la Estación que le fue asignado (Ver Figura 44) para poder publicar en una ruta ’Estación/sensor’ el valor tomado.. Figura 44: Diagrama general con suscriptor a la izquierda y publicador a la derecha. Tarea de activación de actuadores: Aunque si bien esta tarea es una de las más sencillas ya que solo se trata de poner una señal en alto o en bajo a cada uno de 37.

(38) los actuadores que se encuentran en la tarjeta, no obstante el dato del estado de los actuadores se toma de la respuesta que da el Broker a la estación por el dato de un sensor que recibió.. 4.2.4.. Lógica de programación del elemento de salida Gateway. De la misma manera que los microcontroladores de los dispositivos de adquisición y de las estaciones meteorológicas, el Gateway también trabajará con multitarea y a continuación se mostrará la descripción de cada uno de sus tareas (incluyendo brevemente la tarea del item anterior).. Tarea de busqueda y conexión a red WIFI: Si bien esta tarea es sencilla en términos generales ya que solo se trata de hacer un tipo de escaneo para ver si el Gateway tiene la posibilidad de engancharse a una red WIFI y de ser posible conectarse, de esta tarea depende muchas otras tareas o decisiones dentro de las mismas, ya que por ejemplo como se mostrara más adelante, si hay conexión a internet los datos que sean suministrados desde las estaciones meteorológicas serán almacenadas de forma local o subidas directamente a internet. La solución sencilla que se propone en esta tarea es que cada determinado tiempo se hace un chequeo de la conexión a internet para hacer la conmutación que se requiera en la tareas que requiera internet y además de esto para hacer más complejo el asunto de conexión y validación con la red WIFI, se propone un único nombre y única clave que sean guardadas por defecto en la memoria de la Raspberry y a la cual sea la que busque la tarjeta para poderse conectar de forma determinada. Tarea de busqueda de nueva Estación Meteorológica: Como ya se explicó en el item anterior, aunque la integración y asociación de una estación meteorológica a la red del Gateway está dada de forma automática, ésta actividad se activa si y solo si a partir de una acción manual por parte del usuario final en la tarjeta del Gateway por medio de un pulsador y ası́ hacer la integración automática solo en el momento que se requiera. Tarea de recepción datos de sensores desde las Estaciones Meteorológicas: Consiste en que cada determinado periodo de tiempo, el elemento de salida Gateway toma los datos que se tenga en ese momento el buffer UART en este caso recibidos por los módulos Xbee y guardarlos de manera temporal en la memoria de la Raspberry. Tarea de respaldo en base de datos local y base de datos en la nube: Esta actividad consiste en tomar una decisión de acuerdo a el resultado de la actividad ”Tarea de búsqueda de nueva Estación Meteorológica”de guardar la información que se encuentra almacenada de manera temporal, de la tarea anteriormente descrita, para 38.

(39) ser guardada en la base de datos local (cuando no se encuentra una conexión de red de internet presente) o de enviar directamente los datos al servicio web que los recibe (cuando hay conexión de internet). Se utilzó SQLite como ’un motor de base de datos SQL de dominio público autónomo, de alta confiabilidad, incorporado y con todas las funciones’[22], es preciso decir que es el motor de base de datos más utilizado sobretodo en gran variedad de dispositivos móviles precisamente por ser publico, y no solo esto, sino que es un programa muy ligero; pero a pesar de ello mantiene confiabilidad y prestaciones de un motor más robusto, lo cual lo hace una buena opción cuanto se cuenta con poco espacio de almacenamiento o memoria en un dispositivo. Tarea de monitoreo base de datos y memoria disponible en el Gateway: Para evitar desbordamientos innecesarios de la memoria de la Raspberry, esa tarea se encarga de estar monitoreando la cantidad de información en la base de datos local y la capacidad o disponibilidad de la tarjeta para seguir guardando información. Muestra de forma visual por medio de un testigo que ya no es posible seguir obteniendo más datos y bloquea las tareas relacionadas al almacenamiento continuo de información. Una vez hay internet también se encarga de desocupar las tablas de la base de datos que se relacionan a los datos de los sensores y vuelve a activar las funcionalidades anteriormente deshabilitadas para continuar trabajando normalmente.. 4.2.5.. Comunicación Gateway con la nube. La respuesta exitosa de la comunicación de la tarjeta del Gateway con la nube es de suma importancia, ya que esto significa tener los datos disponibles de forma remota. No obstante, se debe resaltar que múltiples estaciones meteorológicas con conexión a Internet pueden estar enviado información de manera constante y persistente, por lo cual es conveniente enviar los datos de la manera más conveniente posible tanto en formato como en arquitectura. Siguiendo con el concepto de MQTT en donde a nombre de una ruta se publica un valor (ver Figura 34), se busca en primera instancia crear la ruta completa (Gateway/Estación/Sensor - Valor), para lo cual todo el proceso se inicia de acuerdo a la Figura 45 con una identificación con la nube por parte de la tarjeta Gateway por medio de un código interno de cada Raspberry. Una vez se identifica ya tiene la capacidad de comunicarse con la nube y transmitir información. Es importante notar que en la Figura 42, se muestra cómo una vez se hace la conexión y acoplamiento entre la estación y Gateway del numeral 6.2.2, el Gateway es quien Registra en la nube la información correspondiente a la estación meteorológica conectada con el fin de recibir un código único con el cual se podrá irse armando la ruta de publicación junto con el número de sensor que se tiene en la nube ya registrado. Una vez la tarjeta de salida a internet Gateway tiene todos los datos de la ruta (Gateway/Estación/Sensor) y los envı́a, recibe un código que representa finalmente a todo el camino 39.

(40) a seguir para hallar el sensor en referencia y a su vez publicar los valores.. Figura 45: Diagrama general con suscriptor a la izquierda y publicador a la derecha. Para la programación de las tareas de la Raspberry se utilizó Python, un lenguaje de programación que se destaca por la fácil interpretación del formato de su codigo el cual es abierto y compatible con varias plataformas. Python cuenta con una gran variedad de librerı́as y paquetes de software que le permite ser un lenguaje de rápido desarrollo e integración eficazmente.. 40.

(41) 5.. SOLUCIÓN EN LA NUBE PARA PERMITIR LA GESTIÓN DE LA INFORMACIÓN. Se define un Servicio Web (Web Service - WS) como un Software conformado por un conjunto de aplicaciones o de tecnologı́as las cuales intercambian datos entre sı́ en la web por protocolos de comunicación de estándar abierto para dar interoperabilidad e integración a los desarrolladores de Software, como por ejemplo HTTP, con el objetivo de ser consumidos como servicios máquina a máquina, por lo cual no cuenta con una interfaz de usuario. Los proveedores de servicios web WS ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web. Figura 46: Estructura de Servicio web convencional. El proveedor de servicios web WS proporciona en la web o publica la información y su WSDL (Web Services Description Language) el cual describe las operaciones, los argumentos de entrada / salida y el argumento WS para el servidor de integración de descubrimiento de descripción universal (UDDI) (el registro de servicios). El desarrollador llamado cliente móvil (solicitante del servicio) encuentra entonces los WS necesarios en el servidor UDDI. Finalmente, el código de aplicación del cliente se genera a partir del WSDL como una función de enlace al WS a través de una solicitud en un protocolo estándar obteniendo una respuesta de información deseada [23].. 41.

(42) Lo que hasta aquı́ se ha denominado como el broker, el cual es el encargado de actuar como un nodo central de gestión de la información, debe estar en la nube como un aplicativo web que permita no solo recibir datos y enviarlos a otro punto, si no que de forma sencilla permita a cualquier usuario acceder a la información de forma intuitiva. Si bien en este punto es posible utilizar cualquier aplicativo en la nube como hace normalmente con cualquier API (Interfaz de programación de aplicaciones), para este caso por fácil uso e integración se utilizara un Web Service. Cabe recordar que si bien un Web Service no necesita ningún tipo de integración embebido dentro de los códigos de los aplicativos que corren sobre los dispositivos que quieran acceder o enviar información del broker, sino que simplemente basta con enviar estrictamente mediante protocolos de red la información de entrada requerida para ası́ obtener una respuesta deseada; si ası́ se quiere ver, el Web Service podrı́a verse simplemente como un conjunto de métodos de programación con parámetros de entrada y salida sin conocer su funcionamiento o estructura que se encuentra en la nube y que pueden puede ser consumidos o utilizados mediante protocolos de red. El Web Service como se muestra en la Figura 46, está conformado por un WSDL donde se especifica claramente cada uno de dichos métodos que lo conforman y de qué manera pueden ser consumidos. A continuación se hará una descripción de cada uno de los métodos que se utilizaran en este proyecto.. Registrar Estación: Este servicio permite al Gateway, una vez se ha conectado, registrar en la base de datos en la nube datos relacionados con el nombre, la latitud, la longitud y comentarios de una nueva estación meteorológica que sea conectada por primera vez, retornando un código único para dicha estación. Registrar Sensor: Similar al servicio anterior, este servicio le permite al Gateway por medio del código propio y del código de la estación a la cual se conecta el sensor, registrar la información con respecto al nombre, tipo, variable, y comentarios de dicho sensor en la nube. Cabe resaltar que generalmente todos los sensores son registrados de forma previa y simplemente es atribuido el código a las tarjetas de las sensores ya que muy rara vez los sensores varı́an y basto con solo identificarse con el código que ya está en la nube para saber todos los datos anteriormente mencionados; sin embargo se genera este servicio con la posibilidad de cualquier otro medio registrar nuevos sensores futuros no existentes en la base de datos. Registrar para Publicar: Este servicio crea por medio del envı́o del código del Gateway, el código de la Estación Meteorológica y el código del Sensor la ruta o camino a donde se puede publicar los datos obtenidos. Si esta fue utilizada anteriormente, devolverá el código de la ruta ya existente para poder publicar. 42.

(43) Publicar Sensor: Una vez se tiene el código de la ruta, este servicio permite publicar o postear el valor medido por el sensor final del camino. Este servicio retorna el valor de los actuadores a la tarjeta que publicó. Información de Todas las Estaciones Existentes: Este servicio tiene como parámetro de entrada el campo ’Activo’ donde se puede enviar un booleano ”true.o ”false”para indicar si se retorna toda la información de las Estaciones Meteorológicas existentes en la nube o todas las estaciones meteorológicas que solo estén activas en ese momento. Información de una Estación Individual: Este servicio retorna toda la información relacionada a una Estación Meteorológica, como el código, nombre, comentario, y sensores conectados a la estación. Información de una Sensor Asociado a una Estación Individual: Este servicio por medio del envı́o de parámetros de entrada fecha inicial y fecha final los valores relacionados a los datos medidos por un sensor en particular durante esta el periodo de tiempo de estas fechas. Suscribir Url a un Sensor y Estación Individual: Tras el envı́o de una URL, la estación y el sensor que se desea; este servicio asocia dicha URL a todos los datos que se publiquen para ser recibidos en tiempo real. Publicar en Actuador: Este servicio permite publicar el valor que se quiera colocar en los actuadores de la tarjeta de la Estación Meteorológica que se requiera controlar remotamente.. Para la implementación de la solución en la nube, se utilizó un servidor que se encuentra en la Universidad Distrital con la dirección rita.udistrital.edu.co y puerto 23624, en el cual se aloja el Web Service y también un usuario final presentado como aplicativo Web en donde se evidenciará y se desarrollará una comprobación más puntual de uso en la siguiente Unidad. Todo el módulo de Web Service se desarrolló en Hypertext Preprocessor - PHP[11], un lenguaje de código especialmente adecuado para el desarrollo web (sobretodo modificar el contenido de forma dinámica) y que puede ser usado en HTML. Principalmente es usado en el lado del servidor pero también en diferentes tipos de aplicaciones. Tiene la capacidad de conexión con diversas bases de datos,funciones nativas sin necesidad de incluirlas o importarlas. Para la base de datos se utiliza MySQL, que es una base de datos cuya licencia es dual, open source bastante sencilla y para la gestión de la Base de Datos en el servidor se utiliza phpMyAdmin[24], una herramienta de software libre que actúa como un tipo de interfaz de usuario escrito, como su nombre lo indica en PHP, el cual permite la administración de una base de datos MySQL a través de Internet de una forma muy sencilla o también por medio de sentencias SQL directamente.. 43.

(44) En primera instancia de acuerdo a la Figura 46, el Web Service suministra un WSDL en donde es posible encontrar los métodos que se ofrecen para ser consumidos ya mencionados con anterioridad, cada uno de ellos con los parámetros de entrada que se requieren como la salida que se genera. Ese WSDL puede consultarse de forma visual en la dirección http://rita.udistrital.edu.co:23624/WebService.php y para entrada de consumo del Web Service en los clientes de máquina en la dirección http://rita.udistrital.edu.co:23624/WebService.php?wsdl.. 44.

(45) 6.. CASO DE USO DE RECEPCIÓN Y ENVÍO DE DATOS REMOTAMENTE. Una vez finalizado todo el modelo de red de estaciones meteorológicas de forma modular utilizando IoT, se muestra una prueba real de uso en donde se genera básicamente el uso de un sensor y control remotamente utilizando la URL ya mencionada http://rita.udistrital.edu.co:23624/. En las Figuras 47 y Figura 48 se encuentra la primera vista de cara al usuario denominada Página de Inicio. Aquí se encuentra descrito el objetivo general y los específicos. Además trae la opción de poder mirar un breve resumen e imagen del proyecto en cuestión. Finalmente un link al grupo de investigación LASER. Figura 47: Página de Inicio. Objetivos.. Figura 48: Página de Inicio. Resumen.. 45.

(46) El aplicativo en la web cuenta con una pestaña llama ’Mapa de Estaciones’ en donde un usuario final puede encontrar un mapa que cuenta con una señales rojas y señales verdes, que representan Estaciones Meteorológicas inactivas y activas en el presente respectivamente. Ver Figura 49. Una vez que cada estación es energizada e identificada por el Gateway, aparece en la posición geográfica suministrada por la estación con todos los datos y en primera instancia de color rojo ya que aunque ha sido conectada, no se encuentra en un proceso de actividad de envío de datos en tiempo real, es decir que solo se encontrara activa si después de determinado tiempo no ha dejado de hacer publicaciones de cada uno de los sensores que gestiona cada estación.. Figura 49: Mapa con Estaciones Meteorológicas. Sobre el mapa es posible seleccionar cualquier estación para desplegar un dialogo como se muestra en la Figura 50 y Figura 51. Este dialogo contiene en su interior toda la información que la estación ha suministrado por primera vez cuando se conectó. En la parte superior se ve el nombre que se le ha dado, seguidamente de izquierda a derecha información sobre el 46.

(47) estado de la estación, el código único de la estación y la fecha en la cual se ha instalado la misma. En la parte central se encuentran dos botones de suma importancia, Consultar Lista de sensores y Consultar Actuadores, los cuales permitirán interactuar de forma más directa con la estación, sin embargo este punto se explicará más adelante. Y finalmente en la parte inferior el comentario de la estación.. Figura 50: Dialogo de Estación Activa.. Figura 51: Dialogo de Estación Inactiva.. La Figura 52 deja ver que una vez es oprimido el primer botón de la parte central, Consultar Lista de Sensores, se despliegue un menú con los sensores que en están o han sido conectados a la estación meteorológica.. 47.

(48) Figura 52: Estación Meteorologica con sensor integrado en la lista.. En la Figura 53 se ve más en detalle una tabla que se genera con información general sobre el sensor que ha sido conectado y a su vez dos nuevos botones, Histórico del Sensor y Tiempo Real del Sensor. El primero de estos botones, permite al usuario final ver un gráfico y una tabla con todos los datos que han sido obtenidos a los largo de las publicaciones del sensor que se desea consultar. No obstante, esta información puede ser filtrada y la gráfica impresa al criterio del usuario.. Figura 53: Información general de sensor asociado a la Estación. Tareas Historico y Tiempo Real habilitadas.. 48.

(49) Como se dijo anteriormente, también está el botón consultar actuadores el cual consiste en este caso el despliegue de tres switch para hacer un control remoto sobre la estación en cuestión colocando en alto o en bajo los actuadores.. Figura 54: Función de actuadores remotos activados.. En la última vista de las pestañas se encuentra toda la información y grafica de los que se han recolectado gracias a la gestión de la plataforma, los cuales pueden ser filtrado por un calendario para acotar las fechas que se desean (Figura 55) y la forma de imprimir o guardar la imagen de la graficas (Figura 56).. Figura 55: Vista de datos registrados por el sensor de forma histórica con filtro en la parte izquierda superior.. 49.

(50) Figura 56: Vista de datos registrados por el sensor de forma histórica con exportación a imagen e impresión en la parte derecha superior de la gráfica.. Como prueba de concepto, en la Figura 57 se muestra la conexion real que se realiza del sensor de velocidad del viento que ya esta integrada con la tarjeta del sensor desarrollada en los puntos anteriores, la cual por medio de los pines de polarizacion (Rojo-VCC y NegroGND) y los pines de I2C (Amarillo-SDA y Verde-SCL) a una de las trajetas de Estacion Meterorologica.. Figura 57: Imagen de modo de conexión para integración entre el sensor y la Estación Meteorológica.. Una vez se proporciona una red de Wifi conocida al Gateway, en este caso la red con ID: Stations y Password: Stations, la Raspberry se conecta manteniendo encendido el LED testigo 50.

(51) el cual indicara parpadeando cada periodo de 10 segundos si la conexión a la red todavía esta o de lo contrario apagando el testigo si no es así. Como se mostró en el diseño del Gateway, es necesario una vez se energiza la Estación, oprimir el botón en la Raspberry para activar la tarea de Encontrar una Estación nueva; No obstante el botón debe ser oprimido hasta que el testigo LED parpadea a una mayor frecuencia. Figura 58.. Figura 58: Presentación final de conexión de todo el sistema funcionando en conjunto.. Figura 59: Vista de mapa de las estaciones meteorológicas en el aplicativo Web. A la izquierda el mapa sin la nueva estación y a la derecha con el reconocimiento de la nueva estación.. Las coordenadas de geográficas de la Universidad Distrital sede de Ingeniería proporcionada por la tarjeta de la Estación Meteorológica, como se muestra en la Figura 59, a la izquierda se encuentra el mapa antes de ser conectada la estación la cual no contiene la ubicación de la estación actual, y al lado derecho de la Figura 59 el mapa con la ubicación ya existente luego de ser identificada y registrada la nueva estación meteorológica en el Web Service y vista en 51.

(52) la aplicación Web. Es importante denotar que toda la información que viaja desde el Web Service viene en formato JavaScript Object Notation (JSON), que aunque si bien no es como tal un lenguaje de programación, sí constituye una estructura de datos o formato de texto que le permite ser clasificado como un lenguaje de marcado ya que consiste en la escritura e interpretación por medio de una marca o nombre con su determinado valor separado por dos puntos ’:’ de la siguiente manera: "Nombre": "Valor" Así puede ser leído por cualquier otro lenguaje de programación y poder empaquetar datos de diferentes tipos uno dentro de otro como se muestra en la Figura 60.. Figura 60: Estructura general JSON. Con la información del sensor en la tarjeta del sensor se procede a conectar directamente la Estación meteorológica lo cual coloca la posición en el mapa en verde de activo y poder interactuar por medio del aplicativo Web a cada una de las funcionalidades descritas anteriormente. Por ejemplo, Ver en tiempo real la información, el histórico de muestras, enviar datos desde el aplicativo a cada uno de los actuadores de la tarjeta. Ver Figura 61 y 62.. Figura 61: Captura y gráfica de datos en tiempo real del nuevo sensor integrado a la Estación Meteorológica.. 52.

(53) Figura 62: Vista de información de la estación y sensor seleccionada con grafica de histórico y tabla de datos.. 53.

(54) 7.. CONCLUSIONES. - Se ha logrado desarrollar e implementar un sistema que le brinde al usuario final, la facilidad de integrar sensores modularmente para obtener su informacion y control de forma remota - Se ha logrado desarrollar e implementar la integracion de diversas tecnologias para una facilidad e intuicion para el usario final - El proyecto realizado promueve la investigacion en el area de meteorologia por el uso de sensores e interfases graficas para el manejo de datos - Si bien la plataforma esta implementada para uso de USB impetearologico es posible por su versatibilidad de diseño solucionar otros problemas que requiera captura de datos y control remoto - Se encuentra en la utilizacion de la energia solar una fuente de energia alterna para dispositivos y de bajo consumo - La topologia de red un breve control permite mejor gastar de la que viaja bidirectamente - La conexion en IZC para el caso de l integracion de edistintos dispositivos al mismo bus con distintas procedencias es de facil uso y de adaptibilidad con el control de las - Aunque si bien utilizar una tarjeta por cader sensar influye en un mayor recurso fisico, tener una tarjeta de forma particular que construye la informacion y afigmacion del sensor solo se permita para moyor. 54.

(55) 8.. REFERENCIAS Y ANEXOS. Referencias [1] J. F. Boshell V. Informe de Consultoría: Gestión De Información Agroclimática En Colombia. Programa Adapt. al Cambio Climático en la Región Andin., 2012. [2] Salthammer, T.; Uhde, E.; Schripp, T.; Schieweck, A.; Morawska, L.; Mazaheri, M.; Clifford, S.; He CongRong; Buonanno, G.; Querol, X.; Viana, M.; Prashant KumarGlobal challenges for the 21st century: the role and strategy of the agri-food sector. Fraunhofer WKI, Department of Material Analysis and Indoor Chemistry, Braunschweig, Germany. 2016. [3] Castro Colina, L.; Sova, C.; Martínez Barón, D.; Saravia, D.Mapping the influence of social actors at different levels for Central America: climate change and agriculture. Estudios Urbanos y Ambientales por El Colegio de México, México, D.F., Mexico. [4] Subgerencia Cultural del Banco de la República. (2015). Clima: elementos y factores. Clima elementos y factores. [5] IDEAM Clima elementos y factores. Colombia.Recuperado de http://www.ideam.gov.co [6] CORNARE. Fenómeno. El. Niño. y. La. Niña.. Colombia.. Recuperado. de. http://www.cornare.gov.co/contactenos/139-gestion-del-riesgo/336-fenomeno-el-nino-yla-nina [7] Andrés Felipe Cruz Bernal(2015). DISEÑO DE UNA ESTACIÓN METEOROLÓGICA MODULAR QUE PERMITA CONEXIÓN REMOTA Y GESTIÓN DE DATOS VÍA INTERNET. Universidad Distrital, Facultad de ingeniería, proyecto de grado. [8] The User’s guide MSP430F5529 LaunchPad Development Kit (MSP-EXP430F5529LP) [Online]. Available: http://www.ti.com/lit/ug/slau533c/slau533c.pdf [Accessed: January2017]. [9] Datasheet. MSP430F5529.. Texas. Instruments. [Online].. Available:. http://www.ti.com/lit/ds/symlink/msp430f5529.pdf [Accessed: January-2017]. [10] C. Meruane and R. Garreaud. Instrumentos Meteorológicos y Humedad Atmosférica Módulo 1. Universidad de Chile Facultad de Ciencias Físicas y Matemáticas Departamento de Geofísica, 2005. [11] Diccionario. de. definiciones. de. palabras. http://definicion.de [Accessed: January-2017]. 55. o. conceptos. [Online].. Available:.

(56) [12] Guías. prácticas. [Online].. Available:. http://www.guiaspracticas.com/estaciones-. meteorologicas [Accessed: January-2017]. [13] DR.. Alfred. MÜller.. Meteorologische. Intrumente. KG. [Online].. Available:. http://www.rfuess-mueller.de/121-0S.pdf [Accessed: January-2017]. [14] The. oficial. page. Chemistry. from. Spain. [Online].. Available:. http://www.quimica.es/enciclopedia [Accessed: January-2017]. [15] Castellanos Velasco Luis Ángel. Barómetro. Medición e instrumentación. Universidad Autónoma de México, Marzo 2015. [16] Página oficial de Xbee [Online]. Available: http://xbee.cl [Accessed: January-2017]. [17] Página oficial de Raspberry Pi [Online]. Available: https://www.raspberrypi.org [Accessed: January-2017]. [18] Página oficial de MQTT [Online]. Available: http://mqtt.org [Accessed: January-2017]. [19] I.S.T. La Recoleta. Curso de Redes. Universidad de Perú, 2003. [20] José Capmany Francoy, Beatriz Ortega Tamarit. Redes Ópticas. Editorial Limusa, 2009. [21] Página oficial de Zigbee [Online]. Available: http://www.zigbee.org [Accessed: January2017]. [22] Página oficial de SQLite [Online]. Available: https://www.sqlite.org [Accessed: January2017]. [23] Ting-Huan Kuo, Chi-Hua Chen, Hsu-Yang Kung. Applications of the web service middleware framework based on the BPEL. IEEE, 29 December 2016. [24] Página oficial de phpMyAdmin [Online]. Available: https://www.phpmyadmin.net/ [Accessed: January-2017].. 56.