• No se han encontrado resultados

Internet of things en smart cities

N/A
N/A
Protected

Academic year: 2020

Share "Internet of things en smart cities"

Copied!
18
0
0

Texto completo

(1)

Internet of Things en Smart Cities

Presentado por:

Sebastián Arturo Rodríguez Ordóñez

Juan Camilo Tangarife Palacio

Asesor:

Yezid Enrique Donoso Meisel

Ph.D. in Information Technology

Departamento de Ingeniería de Sistemas y Computación

Universidad de los Andes

Bogotá, D.C., Colombia

(2)

Contenido

0. Resumen ... 4

1. Introducción ... 5

1.1. Enunciado del problema ... 5

1.2. Diseño e implementación. ... 5

1.3. Resultados obtenidos. ... 5

1.4. Estructura del documento... 5

2. Descripción General ... 6

2.1. Objetivos ... 6

2.2. Antecedentes ... 6

2.3. Identificación del problema y de su importancia ... 6

3. Diseño y especificaciones ... 8

3.1. Definición del problema ... 8

3.2. Especificaciones ... 8

3.2.1. Requerimientos funcionales... 8

3.2.2. Requerimientos no funcionales ... 9

3.2.3. Otros ... 10

3.3. Restricciones ... 10

4. Desarrollo del Diseño ... 11

4.1. Recolección de información ... 11

4.2. Alternativas de Diseño ... 11

4.2.1. Broker MQTT ... 11

4.2.2. Microcontrolador ... 11

4.2.3. Aplicación móvil ... 11

5. Implementación ... 13

5.1. Descripción de la implementación ... 15

5.1.1. Etapa Servidor: ... 15

5.1.2. Etapa Microcontrolador Arduino: ... 15

5.1.3. Etapa Aplicación móvil: ... 16

6. Conclusiones... 17

6.1. Discusión ... 17

(3)
(4)

0.

Resumen

Desde el boom del Internet en la década de los 90 se han abierto un mundo de posibilidades para mejorar la calidad de vida de las personas. En la actualidad tenemos millones de todo tipo de dispositivos conectados a internet, con lo cual podemos ofrecer aún más servicios. En el futuro cercano se espera que todos estos servicios se comuniquen sin la necesidad de la intervención humana, lo cual se habilita con las comunicaciones M2M (Machine to Machine). Este proyecto busca aprovechar la tecnología emergente de las comunicaciones M2M para brindar un servicio en SmartCities (ciudades inteligentes) utilizando SmartPhones.

La funcionalidad del servicio que se desarrolló en este proyecto busca mejorar la calidad de vida utilizando dispositivos para controlar un circuito electrónico de manera remota, de esta forma la casa del ciudadano “sabe” su posición y puede tomar decisiones basándose en su movimiento.

(5)

1.

Introducción

Con la gran cantidad de dispositivos que tienen la capacidad de conectarse a internet, como sensores y actuadores, se abre un gran mercado de posibilidades. Nuestra idea busca implementar en Colombia un servicio para los ciudadanos y así empezar a evolucionar hacia el concepto de Smart Cities, y así tener a nuestro país en la vanguardia de nuevas tecnologías.

Dado que se espera que en un futuro las redes de sensores se conecten con aplicaciones de software para brindar nuevas funcionalidades, quisimos desarrollar un proyecto en el cual se conecten dispositivos con sensores y actuadores que se pueden monitorear y controlar de manera remota utilizando comunicaciones M2M.

1.1.

Enunciado del problema

En la actualidad existen aplicaciones para controlar los servicios de una casa de manera remota, pero es necesario que haya una interacción explícita entre el usuario y la aplicación. La solución para este proyecto exige que las comunicaciones sean M2M para minimizar la intervención humana con el sistema, y que aun así se tomen decisiones basándose en el contexto que se encuentra el usuario para controlar las funcionalidades del hogar.

1.2.

Diseño e implementación.

Para solucionar el problema identificado fue necesario utilizar un microcontrolador que se ubica en la casa del usuario y una aplicación móvil para conocer el contexto de éste. También se utilizó un servidor para intermediar las comunicaciones entre la aplicación móvil y el microcontrolador. En las secciones de diseño del documento se puede encontrar información más detallada.

1.3.

Resultados obtenidos.

Se implementó un sistema con comunicaciones M2M capaz de utilizar la información del contexto del usuario para tomar decisiones en un microcontrolador. Desafortunadamente no fue posible integrar el sistema con un electrodoméstico, lo cual hace parte del trabajo futuro del proyecto.

1.4.

Estructura del documento.

En la primera parte del documento se introduce el proyecto y se realiza una breve descripción del tema, esto permite contextualizar al lector para un pleno entendimiento del proyecto. Posteriormente se describen detalladamente las etapas de diseño e implementación del sistema desarrollado. Finalmente, se concluye con respecto a los resultados esperados del proyecto, además se introduce el panorama futuro de las tecnologías propuestas.

(6)

2.

Descripción General

2.1.

Objetivos

 Lograr un acercamiento a las nuevas tecnologías (IoT, M2M, Smart Cities) del mercado para prestar nuevos servicios a las personas y poder mejorar su calidad de vida.

 Verificar la funcionalidad del protocolo MQTT para las comunicaciones M2M.

 Diseñar una arquitectura capaz de soportar varios servicios que funcionen sobre MQTT.

2.2.

Antecedentes

Actualmente existen varios proyectos de SmartHomes, que permiten a los residentes manipular diferentes electrodomésticos a distancia desde un celular, una tableta, un computador u otros dispositivos con acceso a internet. Desafortunadamente, la mayoría de estos proyectos no utilizan protocolos de comunicación M2M y sigue siendo necesaria la intervención humana.

En el artículo Smart Home Research [1], se plantea un proyecto donde es posible manejar todos los electrodomésticos desde una aplicación en un SmartPhone. Esto se realiza a través de Bluetooth e infrarrojo, lo cual hace que sea necesario que la persona este a pocos metros de distancia del microcontrolador encargado de enviar las señales de control a los electrodomésticos. A pesar de brindar una gran funcionalidad, otra desventaja que se presenta es que es necesario que el usuario interactúe directamente con el sistema para manipular un dispositivo de la casa, es decir, el sistema no es reactivo al contexto del usuario.

Existen otro tipo de proyectos donde el usuario puede manipular servicios de su SmartHome a distancia, como se explica en el artículo de Soliman [2], según el cual se utilizan sensores para brindarle información al usuario del estado de su casa. La comunicación en este caso se realiza utilizando el protocolo HTTP5 (Web Services y Servicios Cloud), el cual cumple con las funcionalidades requeridas pero no fue diseñado para soportar comunicaciones M2M y por lo tanto sigue siendo necesaria la intervención humana.

2.3.

Identificación del problema y de su importancia

Como se mencionó anteriormente, actualmente existen implementaciones de SmartHomes que prestan funcionalidades y servicios eficazmente, y requieren de un usuario. El problema identificado es que tanto el software como el hardware de estas implementaciones requieren de la interacción explícita con un ser humano, cuando se podría realizar de manera automática. Solucionar este tipo de problemas posibilitará nuevas funcionalidades y servicios que mejorarán la calidad de vida de las personas.

La implementación de estas soluciones se puede realizar con Internet of Things (IoT), lo cual es una tendencia tecnológica global en auge [3]. Con la llegada del IoT se espera que los objetos comunes tengan acceso a internet, puedan brindar información y prestar servicios, lo cual es necesario para la implementación de SmartHomes.

(7)

Adicionalmente, como afirma Covington en su artículo [4], la cantidad de dispositivos conectados a internet ya sobrepasa a la población humana y es una brecha que está aumentando con el paso de los años. Por tal razón es necesario lograr intercomunicar los dispositivos conectados a internet, puesto que llegará un momento en el cual la cantidad de estos sea tal que no será posible controlar cada uno de ellos individualmente.

(8)

3.

Diseño y especificaciones

3.1.

Definición del problema

Con la gran cantidad de dispositivos por persona conectados a internet, es necesario desarrollar aplicaciones que los comuniquen sin la necesidad de la intervención humana, y de esta manera prestar nuevos servicios a los usuarios.

3.2.

Especificaciones

3.2.1.

Requerimientos funcionales

Nombre RF-01 – Encender LED del microcontrolador cuando el usuario se encuentre a menos de 1 km de la casa.

Resumen Utilizando el GPS del dispositivo móvil del usuario calcular la distancia a la que se encuentra de la casa, para así encender el LED. Entradas

Posición usuario. Posición casa. Resultados

El led se ha encendido con éxito.

Tabla 1. Requerimiento funcional 1

Nombre RF-02 – Apagar LED cuando el usuario se encuentre a más de 1 km de la casa.

Resumen Utilizando el GPS del dispositivo móvil del usuario calcular la distancia a la que se encuentra de la casa, para así apagar el LED. Entradas

Posición usuario. Posición casa. Resultados

El led se ha apagado con éxito.

Tabla 2. Requerimiento funcional 2

Nombre RF-03 – Apagar el servicio de la aplicación móvil cuando el usuario se encuentre en su casa. Resumen Detectar que el usuario se encuentra en su casa

(9)

móvil que detecta y envía las posiciones del usuario. Entradas Posición usuario. Posición casa. Resultados

El servicio se ha desactivado con éxito

Tabla 3. Requerimiento funcional 2

3.2.2.

Requerimientos no funcionales

Nombre RNF-01 – Sistema reactivo a la posición del usuario.

Crítico Si.

Tipo Necesario.

Descripción Los requerimientos se deben cumplir sin que sea necesaria la intervención humana.

Criterios de aceptación: Ninguno de los requerimientos funcionales requiere de la interacción explicita de un ser humano.

Tabla 4. Requerimiento no funcional 1

Nombre RNF-02 – Transmisión de Datos en formato JSON.

Crítico No.

Tipo No necesario.

Descripción Los datos transmitidos entre los

componentes del sistema deben enviarse en formato JSON.

Criterios de aceptación Todos los archivos enviados a través del sistema usan el formato JSON.

Tabla 5. Requerimiento no funcional 2

Nombre: RNF-03 – Uso protocolo MQTT.

Crítico Si.

Tipo Necesario.

Descripción El sistema debe hacer uso del protocolo MQTT para garantizar una comunicación M2M de manera fácil y rápida.

Criterios de aceptación: Todas las comunicaciones entre las entidades del sistema se realizan utilizando el protocolo MQTT.

(10)

3.2.3.

Otros

Uno de los puntos críticos para el buen funcionamiento del proyecto es la precisión del GPS del que dispone el SmartPhone del usuario, como se puede observar en los requerimientos funcionales. Por lo tanto es importante recordar que el GPS tiene una precisión aproximada de 15 metros, la cual puede verse afectada por objetos metálicos, elementos electrónicos y condiciones de la tropósfera (temperatura, presión y humedad). [5]

En cuanto a las comunicaciones M2M con el protocolo MQTT es necesario contar con un Broker MQTT que sirva como intermediario entre el usuario y el microcontrolador que se encuentra en la casa. Los principales aspectos que se deben conocer del funcionamiento del Broker son los siguientes [6]:

 Para manejar la comunicación el Broker cuenta con topics, o temas, en los cuales se puede publicar información.

 Para consultar la información publicada en un topic es necesario suscribirse previamente a éste.

3.3.

Restricciones

Dado que los fondos para realizar el proyecto no son muy grandes, fue necesario utilizar un microcontrolador Arduino Galileo marca Intel® proporcionado por la Universidad de los Andes. A éste dispositivo se le instaló una imagen del sistema operativo Linux, para así poder manejar la conexión a Internet. Este dispositivo es el encargado de procesar el mensaje enviado por el Smartphone, para tomar la decisión de encender o apagar el LED.

En cuanto a las restricciones de seguridad, es necesario garantizar que la posición del usuario será totalmente privada y nada, exceptuando el microcontrolador, tendrá acceso a ésta.

(11)

4.

Desarrollo del Diseño

Para lograr comunicaciones M2M con el protocolo MQTT, como se establece en los requerimientos no funcionales, es necesario contar con mínimo 3 actores en el sistema: un Broker encargado de manejar la comunicación, un cliente que publique mensajes en un topic en este Broker y un cliente que se suscriba al topic para obtener la información publicada [7]. Estos actores serán un servidor con IP pública donde se ejecute el Broker MQTT, una aplicación móvil que publique mensajes y un microcontrolador que los reciba.

4.1.

Recolección de información

El proceso de recolección de información se llevó a cabo a través de la página web del protocolo MQTT [8], en donde se establecen los diferentes Brokers y clientes existentes. En ésta se encontró que existe compatibilidad con diferentes lenguajes de programación tales como Java, C++, Python, JavaScript, .NET, entre otros. También existen librerías para soportar el protocolo MQTT en dispositivos específicos tales como Arduino, Netduino, Nanode, entre otros.

4.2.

Alternativas de Diseño

Durante el proceso de diseño se contemplaron diferentes alternativas para los actores del sistema:

4.2.1.

Broker MQTT

Como Broker MQTT seleccionamos la implementación de Mosquitto, porque es un software libre, con un proceso de instalación y configuración sencillo, y que además ofrece librerías para realizar tareas de Debug.

Mosquitto es compatible con varios sistemas operativos como Windows, Mac y Linux [9]. Se decidió instalarlo en la distribución Ubuntu 14.04.2 LTS ya que es un sistema operativo estable.

4.2.2.

Microcontrolador

Inicialmente se habían contemplado dos opciones para el microcontrolador: RaspBerry PI y Arduino. Se escogió Arduino, a pesar de las facilidades de comunicación proporcionadas por RaspBerry PI, a causa de las restricciones económicas del proyecto. El dispositivo utilizado en el proyecto es un Arduino Intel® Galileo, que fue proporcionado por la Universidad de los Andes.

4.2.3.

Aplicación móvil

Al momento de decidir en qué sistema realizar la aplicación móvil se contemplaron los sistemas operativos iOS y Android. Dado que se encontró que en ambos casos se proporcionaban funcionalidades similares, se escogió el sistema operativo Android, ya que no requería una curva de aprendizaje tan grande.

Al concluir las decisiones de diseño, se logró establecer una infraestructura determinada para el proyecto. A continuación se muestran los componentes incluidos dentro del sistema.

(12)
(13)

5.

Implementación

Siguiendo la etapa de diseño se realizaron implementaciones de software para el Arduino y para el sistema operativo de dispositivos móviles Android. También se realizó la configuración del Broker MQTT.

Para lograr una comunicación adecuada entre estos tres componentes del sistema, de manera que se cumpliera el requerimiento de realizar comunicaciones M2M, se propuso el siguiente modelo de comunicación:

Figura 2. Diagrama de comunicaciones

En este modelo se observa cómo interactúan los diferentes componentes del sistema, en donde se evidencia que el foco de la comunicación es el servidor. Éste administra los mensajes y decide a cuales clientes serán enviados y a cuáles no. A continuación se describe el flujo de información entre las entidades del sistema:

Configuraciones Previas:

o Servidor: Creación de los topics que serán utilizados para comunicar la aplicación móvil con el Arduino, un topic para enviar la posición (Aplicación Móvil hacia Arduino) y otro para notificar un cambio en el estado del LED (Arduino hacia Aplicación Móvil).

(14)

o Aplicación Móvil: Se suscribe al topic creado en el servidor para recibir el estado del LED.

1. Activar funcionalidad: El usuario abre la aplicación y mediante un Toggle Button enciende o apaga el procedimiento encargado de publicar la posición capturada por el GPS del dispositivo en el topic “pg1-comit/posiciones” del Broker MQTT.

Nota: Al activar la funcionalidad, el dispositivo se suscribe al topic “pg1-comit/estado” donde recibirá actualizaciones del estado del LED (Encendido/Apagado).

Figura 3. Captura de aplicación móvil

2. Enviar Posición (Dispositivo móvil => MQTT Broker): Cuando se obtiene la posición del GPS se crea una cadena de caracteres con formato JSON. Esta cadena se convierte en un arreglo de bytes y se publica en el topic “pg1-comit/posiciones” del Broker MQTT.

3. Enviar posición (MQTT Broker => Arduino): El Servidor envía la información recibida en el topic “pg1-comit/posiciones” a los equipos suscritos a éste, es decir al Arduino.

4. Calcular distancia: Se procede a calcular la distancia entre la posición del Arduino (Hogar), la cual es fija, y la latitud y longitud recibidos desde el Broker MQTT. Si esta distancia es menor a un parámetro del sistema se procede a encender el LED, de lo contrario se apaga.

(15)

En caso de que la distancia sea casi nula, se notifica al dispositivo a través del servidor que éste se encuentra en casa para deshabilitar el servicio. Este procedimiento se ejecuta cada vez que se publica nuevo contenido en el topic al que se suscribió el Arduino, en donde se encuentra la posición del dispositivo móvil (Usuario).

5. Notificar cambio de estado (Arduino => Broker MQTT): Si el LED cambia de estado o si se detecta que el usuario ha llegado a casa se publica en el topic destinado para esto dicho cambio.

6. Notificar cambio de estado (Broker MQTT => Dispositivo móvil): El servidor envía la información proveniente del Arduino a los clientes suscritos al topic “pg1-comit/estado”. El dispositivo móvil recibe la información de cambio de estado del LED y le informa al usuario. Si en el mensaje leído se indica que el usuario se encuentra en casa se procede a apagar el servicio de detección de cambio de ubicación.

5.1.

Descripción de la implementación

5.1.1.

Etapa Servidor:

Para implementar el Broker MQTT se instalaron los paquetes de Mosquitto en el servidor Linux. Al ejecutar el Broker se creó un socket en el puerto 1883, por el cual se reciben las comunicaciones con el protocolo MQTT.

El Broker se puede configurar para manejar autenticación de clientes, ejecutar otras instancias, cambiar el puerto donde escucha, entre otros. Pero para el proyecto se utilizó la configuración por defecto.

Es importante anotar Mosquitto aún está en desarrollo y puede presentar algunos problemas. Por fortuna, existen Brokers de prueba que funcionan sin fallas:

 http://test.mosquitto.org/  http://iot.eclipse.org/

5.1.2.

Etapa Microcontrolador Arduino:

Teniendo en cuenta que el microcontrolador seleccionado fue Arduino Intel® Galileo, fue necesario instalar una imagen compatible del sistema operativo Linux, en este caso se le instaló una imagen Linux Yocto [10], la cual incluye Python, Node.js, WiFi drivers y permite conexiones por medio de SSH.

Con la imagen de Linux instalada, fue posible conectarle al Arduino una tarjeta PCI Intel Centrino® Advanced-N 6205, la cual habilita la conexión a redes WiFi. El driver de esta tarjeta está incluido en la imagen Linux instalada

(16)

Para conectarse a la red WiFi fue necesario instalar la librería connman para Node.js [11], la cual permite conectarse a una red WiFi con seguridad WEP, WPA o WPA2 y recordar la red a la que se conecta.

Al tener el Arduino conectado a Internet se procedió a desarrollar un Script en el lenguaje Python que se suscribe al topic donde el dispositivo móvil publica su posición en formato JSON. Al recibir la información publicada del topic, se procesa el JSON y se calcula la distancia desde la posición recibida hasta la posición del Arduino, y posteriormente se guarda el resultado en un archivo de texto. Además, se desarrolló otro script para publicar en un topic diferente los cambios del estado del LED.

Por último se implementó un Sketch (código en lenguaje similar a C para ejecutar en Arduino), el cual se encarga de ejecutar el script en Python y posteriormente leer el archivo donde se guarda el resultado de éste. Si la distancia leída del archivo es menor a un parámetro del sistema se procede a encender el LED, y a apagarlo de lo contrario. Si el LED cambia de estado, se procede a ejecutar el script de Python encargado de publicar este cambio. En caso de se detecte que el usuario ha llegado a su casa, a partir de la distancia calculada, se envía esta información a través del script que publica los cambios de estado.

5.1.3.

Etapa Aplicación móvil:

Para la implementación de la aplicación móvil en Android, fue necesario crear dos clases principales en el proyecto. Una de estas se comunica con la interfaz gráfica y otra funciona como servicio.

En este servicio se implementó la comunicación con el Broker MQTT, a través de una librería creada por IBM (IA92) [12]. En este servicio se especifica a que topics se suscribe la aplicación, para así ser notificada en caso de que se publiquen mensajes en estos topics. Además de esta funcionalidad del servicio, en este se indicó que estará suscrito a los cambios de ubicación del dispositivo móvil, los cuales serán notificados por el sistema operativo.

A través de este servicio, en el momento en el que ocurra algún cambio de ubicación del dispositivo móvil, se genera una cadena de caracteres en formato JSON que se publica en el topic indicando las nuevas coordenadas del dispositivo móvil (Usuario).

En la interfaz gráfica se cuenta con un Toggle Button, en donde se indica si se quiere prender o apagar esta funcionalidad, con lo cual se deja de publicar los cambios de posición. Además, existe una imagen para informarle al usuario si el LED está encendido o apagado.

(17)

6.

Conclusiones

6.1.

Discusión

El desarrollo del proyecto fue exitoso porque se desarrollaron aplicaciones capaces de comunicarse con un protocolo Machine To Machine (M2M) y así abrir la posibilidad de implementar nuevos servicios para construir Smart Cities.

Aun así, se presentaron algunos inconvenientes en la configuración del Arduino Galileo, lo cual retrasó el desarrollo del proyecto. Estos problemas se presentaron porque el Intel® Galileo es totalmente diferente a las demás placas Arduino, y por lo tanto es necesario verificar que los recursos consultados en internet sean compatibles con la placa Intel® Galileo. A pesar de esto, el Arduino Galileo facilita procesos de conexión, acceso al sistema operativo, manejo de archivos, entre otros; siempre y cuando se apliquen las configuraciones adecuadas.

6.2.

Trabajo futuro

El proyecto desarrollado es solo el inicio de la construcción de Smart Cities a través de la implementación de servicios en Smart Homes. Para que este proyecto sea comercialmente útil es necesario adecuar el Arduino Galileo para controlar diferentes electrodomésticos y así brindar una funcionalidad a las personas que les permita acceder a más servicios en sus hogares.

El paso a seguir en el proyecto sería agregar seguridad al sistema en diferentes niveles, desde la encriptación de los paquetes manejados en los diferentes componentes hasta la autenticación en la comunicación MQTT. Esto garantizaría que los servicios que presta el proyecto solo sean consumidos por el respectivo usuario y que la información intercambiada no pueda ser conocida por un tercero.

Otro proyecto para implementar en Smart Homes y Smart Cities sería instalar una red de sensores en el hogar capaz de tomar decisiones y controlar los electrodomésticos basándose en las mediciones del ambiente. De esta manera se estarían integrando redes de sensores, comunicaciones M2M y computación ubicua para brindar una mejor calidad de vida a las personas.

Este proyecto también podría adaptarse para controlar los semáforos y mejorar el tráfico vehicular en las ciudades. El foco de este proyecto sería instalar dispositivos en vehículos y semáforos que utilizando sus posiciones e incluyendo el tráfico actual decida el cambio de luz más adecuado para el semáforo.

Es importante invertir y realizar proyectos de Smart Cities, ya que se espera que en los próximos años la tecnología mejore la calidad de vida en las personas, haciendo que las ciudades sean proveedoras de información y servicios para los ciudadanos.

(18)

7.

Referencias

[1] L. Jiang, D.-Y. Liu y B. Yang, «Smart Home Research,» IEEEXplore, 29 Agosto 2004.

[2] M. Soliman, T. Abiodun, T. Hamouda, J. Zhou y C.-H. Lung, «Smart Home: Integrating Internet of Things with Web Services and Cloud Computing,» IEEEXplore, 2013.

[3] G. Press, «Forbes,» 8 Agosto 2014. [En línea]. Available:

http://www.forbes.com/sites/gilpress/2014/08/18/its-official-the-internet-of-things-takes-over-big-data-as-the-most-hyped-technology/. [Último acceso: 3 Mayo 2015].

[4] M. Covington y R. Carskadden, «Threat Implication of the Internet of Things,» IEEXplore, 2013.

[5] J. McNamara, GPS for Dummies, Indianapolis: Wiley Publishing, Inc., 2004.

[6] MQTT.ORG, «MQTT Wiki,» [En línea]. Available: http://mqtt.org/wiki. [Último acceso: 22 Mayo 2015].

[7] MQTT.ORG, «FAQ - Frequently Asked Questions,» [En línea]. Available: http://mqtt.org/faq. [Último acceso: 22 Mayo 2015].

[8] MQTT.ORG, «MQTT Software,» [En línea]. Available: http://mqtt.org/software. [Último acceso: 22 Mayo 2015].

[9] Mosquitto, «Downloads | Mosquitto,» [En línea]. Available: http://mosquitto.org/download. [Último acceso: 22 Mayo 2015].

[10] Intel, «Intel Download Center,» [En línea]. Available:

https://downloadcenter.intel.com/download/23171/Intel-Galileo-software-package. [Último acceso: 22 Mayo 2015].

[11] npm inc., «connman,» [En línea]. Available: https://www.npmjs.com/package/connman. [Último acceso: 22 Mayo 2015].

[12] IBM, «IBM IA92: WBI Brokers - Java implementation of WebSphere MQ Telemetry transport - United States,» [En línea]. Available:

(http://www- 01.ibm.com/support/docview.wss?rs=171&uid=swg24006006&loc=en_US&cs=utf-8&lang=en). . [Último acceso: 22 Mayo 2015].

Referencias

Documento similar

First stage of the experiment is to check that data are being acquired properly by the embedded platform of the node. This embedded platform allowed to be programmed using the

Porcentaje de radiación solar interceptada (RSI; 0,35 - 2,5 µm) y de radiación fotosintéticamente activa interceptada (RFAI) a lo largo del ciclo de cultivo para las

En el capítulo de desventajas o posibles inconvenientes que ofrece la forma del Organismo autónomo figura la rigidez de su régimen jurídico, absorbentemente de Derecho público por

First, we must remember that time travel (specially a trip to the past, or a two-way trip) would only be possible in the block universe. In the presentist alternative,

Volviendo a la jurisprudencia del Tribunal de Justicia, conviene recor- dar que, con el tiempo, este órgano se vio en la necesidad de determinar si los actos de los Estados

Cedulario se inicia a mediados del siglo XVIL, por sus propias cédulas puede advertirse que no estaba totalmente conquistada la Nueva Gali- cia, ya que a fines del siglo xvn y en

The part I assessment is coordinated involving all MSCs and led by the RMS who prepares a draft assessment report, sends the request for information (RFI) with considerations,

(Sistema de Gestión de Seguridad en el Trabajo) , que deben ser aplicadas por todos los empleadores públicos y privados, los contratantes de