proyecto fin de grado - oa.upm.esoa.upm.es/38797/1/tfg_lidia_andres_espinal.pdf · para ellos, los...

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA Y SISTEMAS DE TELECOMUNICACIÓN

PROYECTO FIN DE GRADO

TÍTULO: Gestión de dispositivos integrados en una Arquitectura de la

Red de las Cosas

AUTOR: Lidia Andrés Espinal

TITULACIÓN: Grado en Ingeniería Telemática

TUTOR (o Director en su caso): Vicente Hernández Díaz

DEPARTAMENTO: Departamento de Ingeniería Telemática y Electrónica

VºBº

Miembros del Tribunal Calificador:

PRESIDENTE: Alfonso Martín Marcos

VOCAL: Vicente Hernández Díaz

SECRETARIO: José Fernán Martínez Ortega Fecha de lectura:

Calificación:

El Secretario,

A mi abuelo Manuel.

AGRADECIMIENTOS

Quiero agradecer a mis padres su apoyo fundamental para poder conseguir este objetivo que ahora se hace realidad. Gracias sobre todo a mi madre por haberme hecho ver la luz al final del túnel cuando parecía que no la había y por enseñarme a que hay que perseverar ante las adversidades.

Agradecer a mi hermana Laura toda su comprensión y estar siempre cuando necesitaba su apoyo.

También quiero dar las gracias a José por su paciencia y constancia durante estos años en la universidad. Sin ti esto no hubiera sido igual.

Gracias a mis amigos Jorge, Sara e Ismael por todo su apoyo y ánimos en los momentos difíciles de la carrera.

Y como no, dar las gracias a mi tutor Vicente por querer que yo realizara este proyecto y por confiar en que sería capaz de realizarlo.

ETSIST Campus Sur UPM Julio de 2015

Gestión de dispositivos integrados en una Arquitectura de la Red de las Cosas 1

RESUMEN

La Arquitectura de la Red de las Cosas (IoT) hace referencia a una red de objetos cotidianos interconectados digitalmente. Gracias a IoT, no sólo podemos almacenar, analizar e intercambiar información y datos con dichos objetos, sino que además ellos pueden tener la capacidad de interactuar entre ellos de forma autónoma. Para ellos, los objetos cotidianos disponen de actuadores y sensores que permiten modificar su comportamiento y conocer su estado y propiedades, respectivamente.

La gestión de IoT combina todas las funcionalidades necesarias para coordinar un sistema con una Arquitectura de la Red de las Cosas. Una buena gestión del sistema puede reducir costes, mejorar la asistencia a problemas de uso inesperado, corregir fallos y permitir la escalabilidad del sistema permitiéndole la incorporación de nuevos módulos y funcionalidades.

En este Proyecto Fin de Grado se realizará primero un análisis de los aspectos de IoT relacionados con la gestión de dispositivos integrados en la Arquitectura de la Red de las Cosas. Después se procederá a realizar la especificación y el diseño de plataforma de gestión. Y finalmente se desarrollarán un caso de uso que permita validar algunos elementos de la plataforma diseñada. Se realizarán distintas pruebas para comprobar una correcta gestión de los dispositivos como el correcto funcionamiento del diseño previamente establecido, por medio, entre otras, de las siguientes operaciones: listar los elementos conectados, posibilidad de obtener y/o modificar dichos elementos (su configuración y su estado) o presentar informes y comprobar el estado en el que se encuentran los dispositivos: operativos o no operativos.

De tal forma, en esta memoria se plasma como se ha desarrollado la gestión de dispositivos integrados en un sistema con Arquitectura de la Red de las Cosas utilizando tanto plataformas Intel Galileo como Arduino.


2 Gestión de dispositivos integrados en una Arquitectura de la Red de las Cosas



ABSTRACT

The Architecture of the Internet of Things (IoT) refers to a network of digitally interconnected everyday objects. With IoT, not only we can store, analyze and exchange information and data with objects, but they can also autonomously interact among them. To accomplish that, the everyday objects are made of actuators and sensors that let us act on their behavior and know their state and properties, respectively.

Management of IoT combines all the functionalities needed for coordinating a system with an Architecture of the Internet of Things. A good management system can reduce faults, improve assistance to reduce unexpected problems, correct errors and allow the scalability of the system, allowing the addition of new modules and functionalities.

In this Degree Final Project, an analysis about aspects of IoT related to the management of devices integrated into the Architecture of the Internet of things is carried out first. Then, the specification and the design of the management platform is made. Finally, a use case will be developed to validate some elements of the designed platform. Several tests will be run to check the correct management of the devices such as the proper functioning of the design previously established, requesting, among others, the following set of operations: list the connected elements, possibility to obtain or modify these elements (their configuration and their state) or reporting and checking which devices are operating or non-operating.

So, in this memory it is explained how it has been carried out the management of devices integrated in a system with an Architecture of the Internet of Things (IoT), based on the Intel Galileo and Arduino platforms.



ÍNDICE DE CONTENIDOS RESUMEN ............................................................................................................................ 1

ABSTRACT .......................................................................................................................... 3

ÍNDICE DE FIGURAS ......................................................................................................... 7

ÍNDICE DE TABLAS ........................................................................................................... 9

1. LISTA DE ACRÓNIMOS .......................................................................................... 11

2. INTRODUCCIÓN ....................................................................................................... 13

3. MARCO TECNOLÓGICO ......................................................................................... 15

3.1 Gestión de IoT ...................................................................................................... 15

3.2 Antecedentes sobre gestión de recursos ................................................................ 19

3.2.1 WS-Management ........................................................................................... 19

3.2.2 Estándares ...................................................................................................... 19

3.2.3 Tipos de mensajes .......................................................................................... 20

3.3 CoAP: Protocolo para aplicaciones con limitaciones ........................................... 21

3.3.1 Características ................................................................................................ 23

3.3.2 Formatos del mensaje .................................................................................... 23

3.4 Sistema empotrado ................................................................................................ 25

3.4.1 Arduino .......................................................................................................... 25

3.4.2 Intel Galileo ................................................................................................... 25

3.4.3 ZigBee ........................................................................................................... 26

4. DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA ................................................. 29

4.1 Análisis de requisitos ............................................................................................ 29

4.1.1 Diseño del sistema ......................................................................................... 32

4.1.2 Diseño del sistema con diagramas de subsistemas y componentes ............... 40

4.2 Despliegue utilizado por el sistema y ejecutado por cada nodo ........................... 42

5. RESULTADOS ........................................................................................................... 49

5.1 Intercambio de mensajes del registro de los sensores ........................................... 49

5.2 Intercambio de mensajes para el recurso configuration (configuración) .............. 50

5.3 Intercambio de mensajes para el recurso report (presentación de informes) ........ 53

5.4 Intercambio de mensajes para el recurso state (estado) ........................................ 53

5.5 Intercambio de mensajes para el recurso current (corriente) ................................ 56

6. MANUAL DE USUARIO .......................................................................................... 59

6.1 Descargar el software necesario............................................................................ 59

6.2 Utilización del IDE Arduino ................................................................................. 61

6.3 Utilización del Entorno de Eclipse ....................................................................... 64



6.4 Desarrollo del sistema .......................................................................................... 66

6.4.1 Sensor ............................................................................................................ 66

6.4.2 Sensor y coordinador ..................................................................................... 70

6.4.3 Sensores y coordinador ................................................................................. 73

6.4.4 Aplicación java .............................................................................................. 76

7. CONCLUSIONES ...................................................................................................... 77

7.1 Problema inicial .................................................................................................... 77

7.2 Solución propuesta ............................................................................................... 77

7.3 Resultados obtenidos ............................................................................................ 78

7.4 Conocimiento nuevo ............................................................................................. 78

7.5 Trabajos futuros .................................................................................................... 78

8. GLOSARIO ................................................................................................................. 81



ÍNDICE DE FIGURAS

Figura 1: modelo funcional de IoT ...................................................................................... 16 Figura 2: Grupo funcional de gestión dentro del modelo funcional de IoT ........................ 18 Figura 3: método get ............................................................................................................ 20 Figura 4: método put ........................................................................................................... 20 Figura 5: método delete ....................................................................................................... 21 Figura 6: método create ....................................................................................................... 21 Figura 7: formato del mensaje CoAP .................................................................................. 23 Figura 8: placa de Arduino UNO ........................................................................................ 25 Figura 9: placa Intel Galileo ................................................................................................ 26 Figura 10: módulo ZigBee ................................................................................................... 27

Figura 11: Sistema desarrollado .......................................................................................... 32 Figura 12: Interfaz gráfica de la aplicación java ................................................................. 33 Figura 13: placa emontx ...................................................................................................... 34 Figura 14: sensor SCT-013 .................................................................................................. 34 Figura 15: adaptador del enchufe ........................................................................................ 35 Figura 16: circuito bombilla ................................................................................................ 36 Figura 17: medida bombilla 100W ...................................................................................... 37 Figura 18: medida bombilla 60W ........................................................................................ 38 Figura 19: medida bombilla 40W ........................................................................................ 39 Figura 20: diagrama de subsistemas .................................................................................... 40 Figura 21: diagrama de componentes .................................................................................. 41 Figura 22: sistema completo ................................................................................................ 42 Figura 23: diagrama de componentes de la interfaz gráfica ................................................ 43 Figura 24: diagrama de componentes del coordinador ........................................................ 44

Figura 25: diagrama de componentes del sensor de corriente ............................................ 44 Figura 26: código dispatcher del coordinador.ino ............................................................... 45 Figura 27: código dispatcher del coordinador.ino ............................................................... 45 Figura 28: código del componente Medidor ....................................................................... 46 Figura 29: código del componente Gestor ........................................................................... 46

Figura 30: diagrama de componentes de la base de datos ................................................... 47 Figura 31: fichero de texto DireccionSensor.txt .................................................................. 47 Figura 32: fichero de texto report.txt ................................................................................... 48 Figura 33: dirección y recursos del primer sensor ............................................................... 49 Figura 34: dirección y recursos del segundo sensor ............................................................ 50

Figura 35: mensaje GET de la configuración ...................................................................... 50 Figura 36: mensaje GET de la configuración. ..................................................................... 51 Figura 37: mensaje PUT de la configuración ...................................................................... 52

Figura 38: mensaje GET de la presentación de informes .................................................... 53 Figura 39: mensaje GET del estado ..................................................................................... 53 Figura 40: mensaje GET del estado a OFF ......................................................................... 54 Figura 41: mensaje PUT del estado ..................................................................................... 55

Figura 42: mensaje PUT del estado a OFF .......................................................................... 55 Figura 43: mensaje GET de la corriente .............................................................................. 56 Figura 44: fichero report.txt ................................................................................................ 56



Figura 45: fichero DireccionSensor.txt ............................................................................... 57 Figura 46: descarga del firmware ........................................................................................ 59 Figura 47: carga del firmware en la placa Intel Galileo ...................................................... 60 Figura 48: librería RXTX .................................................................................................... 61 Figura 49: selección de la placa .......................................................................................... 61 Figura 50: selección del puerto COM ................................................................................. 62 Figura 51: cargar código a la placa ..................................................................................... 63 Figura 52: seleccionar proyecto eclipse .............................................................................. 64 Figura 53: abrir el proyecto java ......................................................................................... 65 Figura 54: ejecutar proyecto java ........................................................................................ 65 Figura 55: interfaz gráfica de la aplicación java ................................................................. 66 Figura 56: línea código del sketch sensor.ino .................................................................... 66 Figura 57: placa Intel Galileo: Sensor ................................................................................. 67 Figura 58: tarjeta microSD de la Intel Galileo .................................................................... 67

Figura 59: conexión del sensor............................................................................................ 68 Figura 60: abrir el monitor serie .......................................................................................... 68 Figura 61: medidas del sensor ............................................................................................. 69 Figura 62: líneas del código sketch sensor.ino:................................................................... 70 Figura 63: conexión del coordinador al PC ......................................................................... 70 Figura 64: medidas recibidas por el coordinador ................................................................ 71 Figura 65: comparación de los datos entre el coordinador y el sensor ............................... 72 Figura 66: conexión del segundo sensor ............................................................................. 73 Figura 67: código sensor 1 del sketch sensor.ino ................................................................ 73 Figura 68: código sensor 2 del sketch sensor.ino ................................................................ 74 Figura 69: conexión completa de los 2 sensores ................................................................. 74 Figura 70: monitor serie del coordinador con los 2 sensores .............................................. 75 Figura 71: interfaz gráfica de la aplicación java ................................................................. 76

Figura 72: intercambio de mensajes entre el coordinador y el sensor ................................ 76



ÍNDICE DE TABLAS

Tabla 1: analogías ................................................................................................................ 22 Tabla 2: registro de los sensores ......................................................................................... 30 Tabla 3: configuración ........................................................................................................ 30 Tabla 4: presentación de informes ...................................................................................... 31 Tabla 5: estado .................................................................................................................... 31 Tabla 6: medición de la corriente ....................................................................................... 32



1. LISTA DE ACRÓNIMOS

HTTPS: Hypertext Transfer Protocol Secure

SOAP: Simple Object Access Protocol

REST: REpresentational State Transfer

URI: Uniform Resource Identifier

XML: eXtensible Markup Language

DTLS: Datagrama Transport Layer Security

CoAP: Protocolo para aplicaciones con limitaciones

SOA: Arquitectura Orientada A Servicios



2. INTRODUCCIÓN

Al hablar de la Red de las Cosas (IoT) [1] se hace referencia a una red de objetos cotidianos interconectados digitalmente. Por medio de IoT se puede almacenar, analizar e intercambiar información y datos con dichos objetos. Se persigue además que los objetos del mundo real que forman parte de IoT puedan interactuar entre ellos, dando lugar a sistemas heterogéneos más inteligentes. Se abren así las puertas a que un coche busque en su proximidad un dispositivo GPS y sepa automáticamente la ruta que está siguiendo, o a que ese mismo coche interactúe de forma automática con la infraestructura de la carretera para conocer si hay alguna incidencia en los próximos kilómetros. Según el modelo conceptual de IoT en el documento D1.5 [2], la interacción con los objetos cotidianos se puede hacer a través de los sensores y actuadores que éstos tengan conectados. En este contexto, un actuador sería un dispositivo capaz de transformar energía eléctrica para poder activar un proceso con la finalidad de generar algún efecto concreto sobre el objeto cotidiano. Mientras que el sensor sería un dispositivo capacitado para detectar acciones o estímulos externos del objeto cotidiano y generar una señal eléctrica o información digital acorde a la magnitud física que miden o sensan, como por ejemplo harían un sensor de temperatura o de corriente.

Uno de los aspectos contemplados en el modelo funcional de IoT en el documento D1.5 [2], y que está aún muy poco desarrollado, es la gestión de los diferentes elementos que componen un sistema basado en IoT. La gestión se encarga de coordinar y controlar funcionalidades como la configuración, los fallos, la presentación de informes, los dispositivos y el estado. La necesidad de una gestión puede verse clara con la necesidad de reducir costes, asistir a problemas de uso inesperado, corregir fallos y permitir la escalabilidad del sistema permitiéndole la incorporación de nuevos módulos y funcionalidades de manera sencilla.

Después de ver lo que implica IoT y lo desarrollado que está, se plantea la cuestión de que nadie se ha fijado aún en lo poco desarrollada que está la gestión asociada a toda red como IoT.

Por consiguiente, el objetivo de este Proyecto Fin de Grado es proponer una solución que permita gestionar los dispositivos de una IoT conforme a modelo y a la arquitectura que se propone en IoT (documento D1.5 del proyecto europeo IoT-A) [2].

El objetivo secundario es evaluar las capacidades de la plataforma de Intel Galileo para formar parte de la arquitectura de IoT.

Otro objetivo planteado al inicio del proyecto fue desarrollar un prototipo que permita validar la solución propuesta.



Por tanto, en esta memoria se han desarrollado los siguientes apartados, con el objetivo de analizar los requisitos para construir un sistema basado en IoT que incorpora funcionalidades de gestión y diseñar una posible solución:

Apartado 3. Marco Tecnológico: Dentro del marco tecnológico se explica la gestión de IoT, los antecedentes sobre gestión de recursos y la descripción de las partes del sistema empotrado.

Apartado 4. Descripción de la solución propuesta: En este apartado se describe la solución propuesta, destacando la labor realizada en dos fases consecutivas: el análisis de requisitos y el diseño.

Apartado 5. Resultados: En esta sección se describe el intercambio de los mensajes entre el coordinador y los sensores, con el formato descrito en el apartado 4.1.2

Descripción del sensor.

Apartado 6. Manual de usuario: Se ha desarrollado un manual de usuario para ser capaz de reproducir y ejecutar todo el sistema, tanto el software como el hardware, paso a paso.

Apartado 7. Conclusiones: Se muestra, como visión general del trabajo realizado se describe el problema inicial, la solución planteada y los resultados obtenidos.



3. MARCO TECNOLÓGICO

La Red de las Cosas (IoT) es una red de objetos físicos con conectividad que les permite lograr un intercambio de datos entre ellos.

En cuanto a la gestión de los dispositivos que componen la Arquitectura de la Red de las Cosas, aparece la problemática de que no todos los dispositivos comparten el mismo protocolo de comunicación entre ellos ni el mismo sistema operativo, por tanto hay que realizarla e implementarla de manera específica dependiendo del dispositivo del que se trate y la manera de la que se quiera obtener información de él y/o utilizar.

Dentro del marco tecnológico se explicará la gestión de IoT, los antecedentes sobre gestión de recursos y la descripción de las partes del sistema empotrado.

3.1 Gestión de IoT

Las capacidades de gestión de IoT [3] pueden ser clasificadas en capacidades genéricas y capacidades específicas.

Las capacidades de gestión genéricas en IoT son básicamente las siguientes:

Gestión de dispositivos, como activación y desactivación de dispositivos remotos, diagnóstico, actualización del firmware y/o del software, gestión del estado del dispositivo.

Gestión de la topología de red local.

Gestión la congestión y del tráfico, así como la detección de las condiciones de saturación de la red y la aplicación de las reservas de recursos para los flujos de datos imprescindibles para el funcionamiento de la red o urgentes.

Las capacidades de gestión específicas están relacionadas con los requisitos específicos de la aplicación, por ejemplo, requisitos de control de la línea de transmisión por la red de suministro eléctrico inteligente.



En IoT se necesita la gestión y/o la interacción entre los grupos de funcionalidad que componen el diagrama del modelo funcional de IoT. Los grupos funcionales del modelo funcional de IoT son:

Proceso de Gestión de IoT: se refiere a la integración conceptual de los procesos de sistemas de gestión con la arquitectura de IoT.

Servicio de Organización: actúa como un centro de comunicación entre otros grupos de funcionalidad.

Entidad Virtual y Servicio de IoT: se refieren a las interacciones en estos grupos funcionales en un nivel de abstracción.

Comunicación: abstrae la variedad de esquemas de interacción derivados de las muchas tecnologías de dispositivos que pertenecen a sistemas de IoT y proporciona una interfaz común para el Servicio de IoT.

Gestión: combina todas las funcionalidades que se necesitan para coordinar un sistema de IoT.

Seguridad: es responsable de garantizar la seguridad y privacidad de los sistemas de IoT.

Figura 1: modelo funcional de IoT



La gestión combina todas las funcionalidades que se necesitan para coordinar el sistema de IoT. La necesidad de una gestión puede verse clara con por lo menos cuatro metas del sistema de alto nivel:

Reducir de costes: controlando el coste de un sistema, que está diseñado para una cantidad máxima de usuarios y/o casos de uso.

Asistir problemas de uso inesperados: el sistema de IoT está basado en un modelo incompleto de la realidad. Es decir, para un mismo tipo de usuario empleando patrones de actividad, en el mundo físico pueden surgir imprevistos. Una posibilidad podría ser que los errores se introduzcan en el sistema a través de una gestión errónea, o incluso que los dispositivos pudieran simplemente morir de repente. Esta última opción es más probable que se dé en IoT, ya que los márgenes de costes para equipos IoT y por lo tanto su fiabilidad pueden ser mucho menor que la de los equipos tradicionales de telecomunicaciones. Con la gestión de IoT conseguimos proporcionar estrategias y acciones para la reducción de los impactos de situaciones imprevistas. Estos impactos pueden ser fallos de enlace, sobrecarga de colas, etc. Para poder adaptarse mejor a las nuevas situaciones, es muy importante que la gestión tenga una buena visión general del estado del sistema.

Manejo de errores: en cuanto a la imprevisibilidad del comportamiento futuro del sistema. Esto es sumamente importante en sistemas de IoT complejos y también en sistemas de IoT en el que los dispositivos no proporcionan un modelo para su conducta. Las medidas que se realizan para cumplir este objetivo son:

o Predicción de posibles fallos

o Detección de fallos existentes

o Reducción de los efectos de fallos

o Reparación de fallos

Flexibilidad: hay que incorporar cierta flexibilidad en el sistema en lugar de diseñar un nuevo sistema cada vez que las necesidades cambian. El diseño de un sistema se basa en los requisitos de casos de uso. Sin embargo, estos requisitos de casos de uso no son estáticos. Debido a la flexibilidad, la gestión del sistema de IoT será capaz de adecuarse a los cambios según las necesidades de los usuarios en cada momento. Esto puede tener lugar durante el arranque, puesta en marcha o también en tiempo de ejecución.

Estas cuatro metas se pueden alcanzar con el uso de dispositivos de IoT para el seguimiento de calidad de servicio. Incluso las áreas como la gestión de residuos podrían llegar a beneficiarse de la automatización y optimización en IoT.



En cuanto a la descomposición del grupo funcional de gestión dentro del modelo funcional de IoT, como se aprecia en la siguiente figura, consta de cinco componentes funcionales:

Configuración: se encarga de la inicialización de la configuración del sistema, es decir, de la recogida y almacenamiento de configuración de los dispositivos. También se encarga del seguimiento de cambios en la configuración y de la planificación de posibles futuras ampliaciones del sistema.

Fallos: se identifican, aíslan, corrigen y registran. Cuando se produce un fallo, el componente funcional en el que se ha producido se encarga de notificar de dicho fallo.

Presentación de informes: uno de los objetivos de dichos informes es determinar la eficiencia del sistema.

Dispositivo: se encarga de la gestión de los dispositivos y la información asociada a cualquier componente del sistema de IoT.

Estado: supervisa y predice el estado del sistema de IoT. Proporciona una lista de diagnóstico del sistema del pasado, presente y futuro.

Figura 2: Grupo funcional de gestión dentro del modelo funcional de IoT



3.2 Antecedentes sobre gestión de recursos

En cuanto a los antecedentes sobre gestión de recursos cabe destacar WS-Management.

3.2.1 WS-Management

El protocolo WS-Management [4] fue desarrollado por un grupo de fabricantes de hardware y software como un estándar público para el intercambio de datos de gestión de forma remota con cualquier dispositivo informático que implementa dicho protocolo.

3.2.2 Estándares

La implementación actual del protocolo WS-Management se basa en las siguientes especificaciones de estándares:

HTTPS

SOAP sobre HTTP (perfil de WS-I)

SOAP 1.2

WS-Addressing

WS-Transfer

WS-Enumeration

WS-Eventing

La intención del protocolo es proporcionar consistencia e interoperabilidad para las operaciones de gestión a través de muchos tipos de dispositivos (incluyendo firmware) y sistemas operativos.



3.2.3 Tipos de mensajes

Los cuatro tipos de mensajes [5] más destacables son:

WS-Transfer Get: la operación get recupera representaciones de recursos. El mensaje puede ser utilizado para devolver un conjunto de información XML complejo, como podría ser un objeto, o para devolver un único valor simple.

WS-Transfer Put: se utiliza la operación put si un recurso puede ser actualizado en su totalidad dentro de las limitaciones del esquema XML correspondiente para el recurso.

Figura 3: método get

Figura 4: método put



WS-Transfer Delete: la operación delete elimina instancias de recursos.

WS-Transfer Create: la operación create crea recursos y modelos.

3.3 CoAP: Protocolo para aplicaciones con limitaciones

CoAP [6] es un protocolo del nivel de Aplicación para nodos y redes de recursos limitados y aplicaciones M2M (machine-to-machine, es decir, sensores que actúa en función de unos parámetros previamente programados sin la intervención del ser humano), ofreciendo una función parecida al HTTP.

CoAP es un protocolo de software utilizado en dispositivos electrónicos muy simples que les permite comunicarse de forma interactiva a través de Internet. Básicamente, está dirigido a pequeños sensores de baja potencia, interruptores, válvulas y componentes similares que deben ser controlados o supervisados de forma remota, a través de redes de Internet estándar.

Figura 5: método delete

Figura 6: método create



CoAP es una capa de aplicación del protocolo que se destina para su uso en dispositivos de Internet con recursos limitados, tales como WSN nodos.

CoAP está diseñado para traducir fácilmente a HTTP para la integración simplificada con la web, a la vez que satisface necesidades especializadas como multicast, tiene muy bajo costo operativo y es bastante simple. Estas características son importantes para IoT ya que la eficiencia es muy importante. CoAP puede funcionar en la mayoría de los dispositivos que admiten UDP o un análogo de UDP.

CoAP ofrece servicios en sus nodos siguiendo el modelo REST (Representational State Transfer), en el que un cliente envía una petición y el servidor donde se encuentra el recurso responde con el estado de éste.

Las operaciones de REST son:

GET: recupera una representación de recursos.

PUT: se utiliza para modificar los recursos.

POST: se utiliza para crear los recursos.

DELETE: se utiliza para eliminar un recurso.

Se suelen comparar con las operaciones asociadas a la tecnología de base de datos: CREATE, READ, UPDATE, DELETE. Otras analogías pueden también ser hechas como con el concepto de copiar y pegar.

Podemos ver en la siguiente tabla las analogías:

Tabla 1: analogías

Acción REST Copy & Paste

Create PUT Pegar

Read GET Copiar

Update POST Pegar después

Delete DELETE Cortar

Mediante el protocolo CoAP se pueden descubrir recursos por medio del “Discovery” especificado en la rfc 6690 [7]. En esta especificación, esto se desarrolla utilizando un GET a “.well-known/core” en el servidor, el cuál devuelve un payload en el formato de enlace del núcleo.

Por ejemplo en nuestro sistema el coordinador enviaría un mensaje de petición/solicitud a los sensores de manera broadcast, es decir, este mensaje llegaría a todos los sensores que estuvieran encendidos y éstos responderían con un mensaje con su dirección

https://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=search&rurl=translate.google.es&sl=en&u=https://en.wikipedia.org/wiki/Application_layer&usg=ALkJrhjZ16Wf5PJsP574OYps_QjJurSnLg

https://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=search&rurl=translate.google.es&sl=en&u=https://en.wikipedia.org/wiki/WSN&usg=ALkJrhiY8aLNFQTGSbIF2MCQdUaEyeSKNg

https://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=search&rurl=translate.google.es&sl=en&u=https://en.wikipedia.org/wiki/HTTP&usg=ALkJrhgpE7gd4VwDc-p3FPSWRFV53BQbcQ

https://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=search&rurl=translate.google.es&sl=en&u=https://en.wikipedia.org/wiki/Multicast&usg=ALkJrhgCXJPjNqLSwIQt_w4sHvadvj0NqQ

https://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=search&rurl=translate.google.es&sl=en&u=https://en.wikipedia.org/wiki/User_Datagram_Protocol&usg=ALkJrhiVnz7_U1LKkDIEgsjWFig6kgrMHw



y los recursos que realiza para que el coordinador tuviera constancia de los sensores que hay disponibles para interactuar con ellos.

3.3.1 Características

CoAP está diseñado con las siguientes características:

Complejidad del análisis.

URI y apoyo de tipo contenido.

Soporte para el descubrimiento de los recursos proporcionados por los servicios CoAP conocidos.

Suscripciones simples para un recurso y notificaciones push resultantes.

Almacenamiento en caché simple basado en max-age, que establece la duración máxima de la caché.

3.3.2 Formatos del mensaje

Los mensajes de CoAP, especificados en la rfc 7252 [8], están codificados en un formato binario simple.

El formato del mensaje comienza con una cabecera de tamaño fijo de 4 bytes. Esto es seguido por una muestra (Token) de longitud variable de valor simbólico, que puede estar entre 0 y 8 bytes de longitud:

Figura 7: formato del mensaje CoAP

https://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=search&rurl=translate.google.es&sl=en&u=https://en.wikipedia.org/wiki/URI&usg=ALkJrhgQ4sM7ot5N31Lw_Rp5v68aqrwpng



Los campos en la cabecera son los siguientes:

Version (Ver): Entero sin signo de 2 bits. Indica el número de la versión CoAP. Las implementaciones de esta especificación deberán establecer este campo a 1 (01 binario). Otros valores están reservados para futuras versiones. Los mensajes con los números de versión desconocidos se ignoran.

Type (T): Entero sin signo de 2 bits. Indica si este mensaje es de Confirmación (0), no confirmación (1), Reconocido (2), o de Reinicio (3).

Token Length (TKL): Entero sin signo de 4 bits. Indica la longitud del campo simbólico de longitud variable (0-8 bytes). Longitudes 9-15 están reservadas.

Code: 8 bits entero sin signo, se dividió en una clase de 3 bits (más bits significativos) y un detalle de 5 bits (bits menos significativos), documentado como "c.dd", donde "c" es un dígito de 0 a 7 para el subcampo de 3 bits y "dd" dos dígitos 00-31 para el 5-bit subcampo. La clase puede indicar una petición (0), un éxito respuesta (2), una respuesta de error del cliente (4), o un error en el servidor respuesta (5). (El resto de valores de la clase son reservados.) Como caso especial, Código 0.00 indica un mensaje vacío. En caso de una solicitud, el campo Código indica el método de petición; en caso de una respuesta, un código de respuesta.

CoAP tiene dos tipos de mensajes: solicitudes y respuestas, mediante un sencillo formato de cabecera base binaria. La cabecera base puede ir seguida por opciones en un formato de longitud-valor optimizado. CoAP tiene por defecto destino a UDP y opcionalmente a DTLS, proporcionando un alto nivel de seguridad de las comunicaciones.

Cualquier byte después de la cabecera en el paquete se considera el cuerpo del mensaje si los hubiera. La longitud del cuerpo del mensaje está implícito por la longitud del datagrama.

https://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=search&rurl=translate.google.es&sl=en&u=https://en.wikipedia.org/wiki/DTLS&usg=ALkJrhi4tiQLrKjkLiSXs3CEFxyPUo70sg



3.4 Sistema empotrado

A continuación se procederá a describir cada parte utilizada del sistema desarrollado.

3.4.1 Arduino

Arduino [9] es una herramienta para que los ordenadores puedan detectar y controlar el mundo físico. Es una plataforma de computación física de código abierto basado en una placa electrónica simple, y un entorno de desarrollo para desarrollar software para la placa.

El lenguaje de programación Arduino es una implementación de Wiring, que se basa en el entorno de programación multimedia Processing.

3.4.2 Intel Galileo

Intel Galileo [10] combina la tecnología de Intel con soporte para tarjetas de hardware Arduino, utilizando el entorno de desarrollo de software de Arduino y sus bibliotecas. La placa de desarrollo ejecuta un sistema operativo Linux de código abierto con las bibliotecas de software de Arduino, que permite reusar software existente: sketchs. Intel Galileo se puede programar a través de OS X, Microsoft Windows y el software operativo host

Figura 8: placa de Arduino UNO



Linux. La placa está diseñado para ser el hardware y el software compatible con el ecosistema de Arduino.

Figura 9: placa Intel Galileo

3.4.3 ZigBee

ZigBee [11] es la especificación de un conjunto de protocolos de alto nivel de comunicación inalámbrica para su utilización con radiodifusión digital de bajo consumo, basada en el estándar IEEE 802.15.4 de redes inalámbricas de área personal (wireless personal area network, WPAN). Su objetivo son las aplicaciones que requieren comunicaciones seguras con baja tasa de envío de datos y maximización de la vida útil de sus baterías.

Su mayor uso es en el ámbito de la domótica. La razón de ello son las siguientes características que lo diferencian de otras tecnologías:

Su bajo consumo.

Su topología de red en malla.

http://es.wikipedia.org/wiki/Radio_digital

http://es.wikipedia.org/wiki/Norma_(tecnolog%C3%ADa)

http://es.wikipedia.org/wiki/IEEE_802.15.4

http://es.wikipedia.org/wiki/WPAN

http://es.wikipedia.org/wiki/WPAN

http://es.wikipedia.org/wiki/Red_en_malla



Su fácil integración (se pueden fabricar nodos con muy poca electrónica).

Figura 10: módulo ZigBee



4. DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA

Según el modelo funcional de IoT, descrito en el apartado 3.1 Gestión de IoT, se puede apreciar que está aún muy poco desarrollada la gestión de los diferentes elementos que componen un sistema basado en IoT. La gestión coordinar y supervisa las funcionalidades descritas en el modelo funcional de IoT, las cuales son:

Configuración

Fallos

Presentación de informes

Dispositivos

Estado

En este proyecto hemos implementado las funcionalidades de configuración, presentación de informes, dispositivos y estado.

4.1 Análisis de requisitos

Este apartado se centra en analizar los requisitos que cualquier sistema basado en IoT, que desee implementar mecanismos de gestión, debe satisfacer.

En IoT, cualquier capacidad física de un dispositivo físico, se mapea en el mundo computacional como un recurso, accesible mediante servicios, considerando siempre la definición de servicio que se da en el modelo de referencia de SOA [12].

Por tanto, las capacidades de gestión de los objetos deben ser mapeadas como recursos a los que se puede acceder mediante SOA. Más concretamente, se ha decidido que la solución tecnológica más adecuada es REST y el protocolo CoAP (este último queda justificado porque se va a proporcionar una solución válida para cualquier dispositivo de bajas capacidades).

La implicación del uso de las operaciones de REST dentro del sistema desarrollado es el siguiente:

GET: permite conocer el estado de un objeto, la configuración, los informes que se van guardando con las operaciones que va realizando y las medidas que realiza el sensor.

PUT: permite modificar el estado de un objeto y la configuración.



El formato de los mensajes, para que exista comunicación entre el coordinador y los sensores, está basado en el protocolo CoAP, descrito en el apartado 3.3 CoAP: Protocolo

para aplicaciones con limitaciones, y es el siguiente:

Intercambio de mensajes cuando el coordinador pide que se registren los sensores:

Tabla 2: registro de los sensores

Con este mensaje el coordinador solicita a los sensores que están encendidos que envíen su dirección con los recursos que realizan. El mensaje de solicitud se basa en la RFC 6690 del protocolo CoAP [7].

Intercambio de mensajes para la configuración:

Tabla 3: configuración

Con el mensaje GET el coordinador solicita que se le devuelva la configuración que tiene el sensor y éste se la devuelve. Y con el mensaje PUT el coordinador hace que el sensor reinicie su fichero .txt, tanto el que se guarda en el PC como el que se guarda en la tarjeta SD de la placa Intel Galileo y que devuelva la nueva configuración.

Coordinador (solicitud)

galileo://.well_known/core

Sensor (respuesta)

galileo://.well_known/core/PUT?direccion=DirecciónSensor/galileo://

DirecciónSensor/medidor&galileo://DirecciónSensor/gestor


galileo://DirecciónSensor/configuration/GET

galileo://DirecciónSensor/configuration/PUT

Sensor (respuesta)

galileo://DirecciónSensor/configuration/PUT?ConfiguraciónSensor



Intercambio de mensajes para la presentación de informes:

Tabla 4: presentación de informes

En la presentación de informes sólo existe el mensaje GET. El coordinador solicita el “report” (la presentación del informe) y el sensor devuelve el fichero .txt que tiene guardado en la tarjeta SD con los movimientos que ha ido realizando.

Intercambio de mensajes para el estado:

Tabla 5: estado

Con el mensaje GET el coordinador solicita que se le devuelva el estado que tiene el sensor y éste se lo devuelve. Y con el mensaje PUT el coordinador cambia el estado del sensor a “ON” o a “OFF”, y el sensor le devuelve su estado actualizado.


galileo://DirecciónSensor/report/GET

Sensor (respuesta)

Información almacenada en la tarjeta SD de Intel Galileo (del sensor)


galileo://DirecciónSensor/state/GET

galileo://DirecciónSensor/state/PUT?param=EstadoSensor

Sensor (respuesta)

galileo://DirecciónSensor/state/PUT?EstadoSensor



Intercambio de mensajes para la medición del sensor:

Tabla 6: medición de la corriente

En la medición del sensor sólo existe el mensaje GET, igual que en la presentación de informes. El coordinador solicita las medidas de corriente que realiza el sensor y éste comienza en ese momento a medir y se las devuelve.

4.1.1 Diseño del sistema

Se ha desarrollado un prototipo que va a permitir ilustrar cómo se implementa, para un sistema basado en IoT, la solución que se propone en apartados anteriores. El prototipo desarrollado se compone de tres partes principales, como se puede ver en la siguiente figura, que son: el PC, el coordinador y el sensor.


galileo://DirecciónSensor/current/GET

Sensor (respuesta)

galileo://DirecciónSensor/current/PUT?CorrienteSensor

Figura 11: Sistema desarrollado



Para poder alcanzar el objetivo del sistema, se han implementado una serie de funciones de gestión de IoT, ya explicadas en el apartado 3.1 Gestión de IoT.

Las funciones implementadas son las siguientes:

Configuración: cada sensor tiene guardada su configuración en un fichero de texto llamado DireccionSensor.txt y éste es mando al coordinador cuando es solicitado.

Presentación de informes: el coordinador solicita al sensor el fichero de texto que guardan internamente en su tarjeta SD para tener constancia de lo que ha ido realizando el sensor.

Dispositivo: el coordinador se encarga de la gestión de los dispositivos, solicitando que se registren los dispositivos disponibles por medio de un mensaje de respuesta que incluye su dirección y los recursos que implementa.

Estado: el sensor responde con su estado al coordinador cuando éste lo solicita.

Y en cuanto al proceso de funcionamiento que se realiza es el siguiente:

Desde el PC a través de su interfaz gráfica hecha con una aplicación java, como se puede ver en la siguiente figura, en el espacio para el “ENVÍO DEL MENSAJE AL SENSOR” se envía el mensaje al sensor dependiendo de que se quiera que realice el sensor o de que información se quiere que facilite en el espacio “RESPUESTA DEL SENSOR”. Una vez que le llega la respuesta del sensor el PC la almacena en un fichero de texto llamado DireccionSensor.txt que se encuentra en la carpeta asociada al proyecto de la aplicación java.

Figura 12: Interfaz gráfica de la aplicación java



El coordinador actúa de Gateway, es decir, reenvía por medio del módulo ZigBee el mensaje desde el PC al sensor.

El sensor al llegarle el mensaje del PC a través del coordinador, responde con un mensaje de respuesta con la información que se le ha solicitado o se pone a medir corriente y la envía al coordinador para que salga por pantalla en la interfaz gráfica.

Para que la comunicación utilizando ZigBee sea posible se ha configurado en el sketch del sensor los puertos Serial y Serial1 para que la Intel Galileo transmita y reciba, según las especificaciones de Intel [13].

El sensor realiza la medida de la corriente cuando le llega dicho mensaje desde el coordinador y para ello requiere tener conectado a la Intel Galileo una placa emontx, figura 13, para poder conectar el sensor SCT-013, figura 14, y un adaptador de enchufe, figura 15, se usa este enchufe para que el sensor sólo mida corriente de una fase del cable, ya que si lo realizara de todo el cable se tendrían las dos fases y por tanto la corriente que entra es la misma que la que sale y ésta sería cero.

Figura 14: sensor SCT-013

Figura 13: placa emontx



El sensor SCT-013 [14] es un sensor para medir corriente alterna y sus características son:

Corriente de entrada: 0 ~ 100A AC

Modo de salida: 0 ~ 50 mV

No linealidad: ± 3%

Resistencia Grado: Grado B

Temperatura de trabajo: -25 ° C ~ + 70 ° C

Rigidez dieléctrica (entre la cáscara y la salida): 1000 V AC / 1min 5 mA

Longitud del cable: 1m

Tamaño: 13mm x 13mm

Y sus aplicaciones son:

Adecuado para la medición de corriente

Vigilancia y protección de motores AC

Equipos de iluminación

Compresor de aire

Figura 15: adaptador del enchufe



Para comprobar el margen de error del sensor midiendo corriente, se han realizado 3 medidas con una bombilla diferente en cada una de ellas, realizando el siguiente circuito:

Figura 16: circuito bombilla



Para una bombilla de 100W:

La intensidad teórica que debería salir sería: 𝐼 =𝑃

𝑉=

100𝑊

220𝑉= 455 𝑚𝐴

Y con la medida del sensor se obtienen los siguientes datos:

Figura 17: medida bombilla 100W





𝑉=

60𝑊

220𝑉= 273 𝑚𝐴







𝑉=

40𝑊

220𝑉= 182 𝑚𝐴



Como se puede apreciar con los datos de las 3 medidas, comparándolos con la intensidad teórica, a medida que la intensidad decrece el error entre la medida obtenida por el sensor y la teórica es mayor. Y a su vez, a medida que la intensidad crece el error entre la medida obtenida por el sensor y la teórica es menor y éstas se acercan más.



4.1.2 Diseño del sistema con diagramas de subsistemas y componentes

En cuanto al diseño del sistema se puede dividir en dos diagramas: diagrama de subsistemas y de componentes.

El diagrama de subsistemas, siguiente figura, consta de 4 subsistemas claros: el subsistema Manager/coordinador, el subsistema del sensor de corriente, el subsistema de la interfaz gráfica y el subsistema de la base de datos (BBDD).

El subsistema de la interfaz gráfica interactúa con el coordinador, para que envíe los mensajes al sensor por ZigBee, y con la base de datos para guardar en el fichero de texto DireccionSensor.txt que se encuentra en el PC, todas las operaciones que va enviando el sensor.

El subsistema del coordinador, interactúa con la interfaz gráfica, para saber que mensajes enviar al sensor, y con el sensor de corriente para solicitarle información o que realice medidas de corriente.

El subsistema del sensor de corriente, interactúa con el coordinador, para recibir los mensajes y saber qué hacer en cada momento, y con la base de datos para guardar en la tarjeta SD de la Intel Galileo el fichero de texto, llamado report.txt, con todas las operaciones que va realizando.

El subsistema de la base de datos, interactúa tanto con la interfaz gráfica, ya que ésta guarda las operaciones recibidas del sensor en el fichero DireccionSensor.txt que se

Figura 20: diagrama de subsistemas



encuentra en el PC, y con el sensor de corriente, el cual guarda el fichero report.txt con todas las operaciones que va realizando el sensor en la tarjeta SD de la Intel Galileo.

En el diagrama de componentes, siguiente figura, se puede apreciar de qué se compone cada subsistema.

Las operaciones implementadas han sido las siguientes:

configuration: el coordinador al solicitar la configuración del sensor con un GET, éste se la devuelve. Y en el caso de que quisiera modificarla utilizaría un PUT y entonces el sensor la modificaría y se la devolvería al coordinador.

report: el coordinador solicita al sensor la presentación de informes con un GET y éste se la devuelve.

state: el coordinador pide al sensor el estado con un GET y éste se la devuelve. Si el coordinador quisiera que la modificara utilizaría un PUT en el que le enviaría un parámetro con el nuevo estado, el sensor la modificaría y después se la devolvería.

current: al solicitar el coordinador al sensor la corriente con un GET, el sensor comienza a medirla y se la devuelve.

Figura 21: diagrama de componentes



4.2 Despliegue utilizado por el sistema y ejecutado por cada nodo

El diseño que se ha seguido para desarrollar el sistema completo está compuesto por los elementos principales que se han mencionado en el apartado anterior: PC, coordinador y sensores:

Figura 22: sistema completo

Desde la interfaz gráfica de la aplicación java que se encuentra en el PC, se envía el mensaje al sensor pasando por el coordinador que hace de gateway y se lo envía por ZigBee. Una vez que los sensores identifican, por medio de la dirección del mensaje recibido, si el mensaje es para él o no, hará una cosa u otra:

Si el sensor identifica que el mensaje es para él, lo siguiente que hace es comprobar que se encuentra en el estado de ON y si es así después analiza que se le está pidiendo, pudiendo ser que envíe información al coordinador de su configuración o de su estado, que mande la información de las operaciones realizadas almacenada en el documento de texto report.txt de la tarjeta SD o que comience a medir corriente y envíe dichos datos.

Si el sensor identifica que el mensaje es para él, pero se encuentra en el estado de OFF, no responderá nada al coordinador, ya que no pude realizar ninguna función al encontrarse apagado.



Si el sensor identifica que el mensaje no es para él, éste no respondería nada al coordinador.

El despliegue del sistema completo se puede analizar viendo los diagramas de componentes de cada subsistema:

En el subsistema de la interfaz gráfica, se aprecia en la siguiente figura, el componente GUI, el cual se compone de la aplicación java realizada para poder mandar y recibir los mensajes entre el coordinador y los sensores de corriente (solicitud-respuesta).

Figura 23: diagrama de componentes de la interfaz gráfica



En el subsistema Manager o del coordinador, en la siguiente figura se ve el componente Gestor, compuesto por el sketch coordinador.ino. El objetivo del código de dicho sketch es la comunicación bidireccional de mensajes con los sensores a través de ZigBee.

En el subsistema del sensor de corriente, los componentes son tres: Dispatcher, Medidor y Gestor:

Figura 25: diagrama de componentes del sensor de corriente

Figura 24: diagrama de componentes del coordinador



El dispatcher es el encargado de analizar si la dirección del mensaje de solicitud coincide con la del sensor de corriente:

En el caso de que coincida comprueba que el sensor esté encendido (estado a ON):

Después analiza el recurso solicitado. Dependiendo del recurso que se trate, el dispatcher mandará el resto del mensaje al componente Medidor o al componente Gestor para que ellos se encarguen de analizar la operación que se está pidiendo y devolver al coordinador el mensaje de respuesta con la información solicitada.

Los recursos que el coordinador puede solicitar al sensor de corriente son los siguientes:

current: puede pedir que el sensor comience a medir corriente y le envíe dichos datos.

state: puede solicitar que el sensor le haga saber su estado: encendido (ON) o apagado (OFF).

configuration: puede requerir que el sensor le envíe la información sobre su configuración, la cual está compuesta por su dirección y el estado en el estado que se encuentre.

report: puede querer saber todas las operaciones que ha ido realizando el sensor. Dichas operaciones están almacenadas en el fichero de texto report.txt que se encuentra en la tarjeta SD de la Intel Galileo.

Figura 26: código dispatcher del coordinador.ino

Figura 27: código dispatcher del coordinador.ino



Y las operaciones que el coordinador puede pedir al sensor de corriente son dos:

GET: pidiendo el envío de información acerca del recurso del mensaje de solicitud.

PUT: solicitando la modificación de algún parámetro del recurso del mensaje de solicitud.

En el caso de que se trate del recurso current, el dispatcher mandará el resto del mensaje al componente Medidor, y tan sólo constará de la operación GET, ya que iniciaría la medición de corriente y la enviaría al coordinador:

Y si se trata de los otros tres recursos: state, configuration o report, e dispatcher mandará el resto del mensaje al componente Gestor y dependiendo del recurso que sea tendrá una sola operación (GET) o las dos (GET y PUT):

Figura 28: código del componente Medidor

Figura 29: código del componente Gestor



En el subsistema de la base de datos, se encuentra el componente Datos:

Este componente hace referencia tanto al fichero de texto DireccionSensor.txt con la información de las operaciones que va solicitando el coordinador que se guarda en el PC:

Figura 30: diagrama de componentes de la base de datos

Figura 31: fichero de texto DireccionSensor.txt



Como al fichero de texto report.txt que se guarda en la tarjeta SD del sensor con la información de las operaciones que va realizando el sensor:

Figura 32: fichero de texto report.txt



5. RESULTADOS

Con respecto al rendimiento del sistema principalmente se puede hablar del tiempo de respuesta.

El tiempo de respuesta del sistema viene definido por el código del sketch de los sensores, ya que a medida que se ha ido desarrollando se han incluido una serie de delays, para que el código se ejecute en su tiempo justo y no dé lugar a ningún colapso de información, ni de pérdida de mensajes, evitando de esta manera perder datos o que el sistema quede bloqueado momentáneamente.

El sistema no es muy rápido pero tampoco lento. Se han ido incluyendo delays para adecuar el código a las necesidades que va necesitando el sistema en cada momento, es decir, dependiendo de la información que el coordinador solicite al sensor.

A continuación se describirá el intercambio de los mensajes, con el formato descrito en el apartado 4.1 Análisis de requisitos, entre el coordinador y los sensores.

5.1 Intercambio de mensajes del registro de los sensores

El coordinador envía a los sensores que estén encendidos el mensaje: galileo://.well_known/core, para obtener sus direcciones y los recursos que realizan. Del primer sensor recibe:

Figura 33: dirección y recursos del primer sensor



Y del segundo sensor recibe:

5.2 Intercambio de mensajes para el recurso configuration

(configuración)

Operación GET:

Se puede ver como el coordinador le envía al sensor el mensaje: galileo://DireccionSensor/configuration/GET, para obtener la configuración de dicho sensor, compuesta por la dirección y el estado:

o Primero se recibe la respuesta con la dirección del sensor:

Figura 35: mensaje GET de la configuración

Figura 34: dirección y recursos del segundo sensor



o Y después se recibe la respuesta con el estado del sensor:

Figura 36: mensaje GET de la configuración.



Operación PUT:

El coordinador solicita al sensor con el mensaje: galileo://DireccionSensor/configuration/PUT que modifique su configuración, para que el sensor reinicie su fichero report.txt de la tarjeta microSD con la nueva configuración, compuesta por la dirección y el estado del sensor. Y el sensor devuelve como respuesta la información de la configuración, un mensaje con la dirección y el siguiente con el estado del sensor:

Figura 37: mensaje PUT de la configuración



5.3 Intercambio de mensajes para el recurso report (presentación de

informes)

Operación GET:

El coordinador solicita al sensor con el mensaje: galileo://DireccionSensor/report/GET la presentación de informes, para que el sensor envíe su configuración y las operaciones que se han ido guardando en su fichero report.txt de la tarjeta microSD:

5.4 Intercambio de mensajes para el recurso state (estado)

Operación GET:

El coordinador solicita al sensor con el mensaje: galileo://DireccionSensor/state/GET el estado, para que el sensor responda con un mensaje con su estado:

Figura 38: mensaje GET de la presentación de informes

Figura 39: mensaje GET del estado



Si el estado devuelto fuera OFF el siguiente mensaje que el sensor devolvería después de informar de cuál es su estado sería uno avisando de que el dispositivo está apagado y de que en caso de que se quiera utilizar se debe encender:

Figura 40: mensaje GET del estado a OFF



Operación PUT:

El coordinador solicita al sensor con el mensaje: galileo://DireccionSensor/state/PUT?param=EstadoSensor que modifique el estado, para que el sensor cambie su estado a encendido (ON) o apagado (OFF) y responda con un mensaje con su estado:

En el caso de que el estado que se modifique sea OFF después del mensaje anterior el sensor también envía uno avisando de que el dispositivo está apagado y que si se desea utilizar se debe encender:

Figura 41: mensaje PUT del estado

Figura 42: mensaje PUT del estado a OFF



5.5 Intercambio de mensajes para el recurso current (corriente)

Operación GET:

El coordinador solicita al sensor con el mensaje: galileo://DireccionSensor/current/GET que se ponga a medir corriente y envíe las medidas, y éste le responde con las medidas:

Hay que destacar que todas las operaciones que va realizando el sensor se guardan en el fichero de texto report.txt de su tarjeta microSD:

Figura 43: mensaje GET de la corriente

Figura 44: fichero report.txt



Y las operaciones que va solicitando el coordinador y sus respuestas de los distintos sensores se van almacenando en el fichero de texto DireccionSensor.txt del PC dentro de la carpeta del proyecto java:

El contenido tanto del fichero report.txt de la tarjeta microSD como el del fichero DireccionSensor.txt del PC se puede ver en el apartado 4.2 Despliegue utilizado por el

sistema y ejecutado en cada nodo.

Figura 45: fichero DireccionSensor.txt



6. MANUAL DE USUARIO

Para ser capaz de reproducir y ejecutar todo el sistema, existen una serie de pasos a seguir:

6.1 Descargar el software necesario

Por un lado es necesario descargar el IDE de Arduino para poder implementar los sketchs necesarios para que el sistema funcione y/o cargarlos en las placas.

Ya que los sensores se integran en una placa Intel Galileo, es necesario descargar el IDE de Arduino 1.5.3, del siguiente enlace:

http://www.intel.com/support/galileo/sb/CS-035101.htm

El coordinador de la red IEEE802.15.4 se instala en una placa Arduino, para lo que se ha empleado la versión 1.6.5 del IDE de Arduino. Se puede descargar desde el siguiente enlace:

http://www.arduino.cc/en/Main/Software

Para poder utilizar las placas Intel Galileo como sensores, es necesario descargar el firmware y actualizarlo en el IDE de Arduino 1.5.3 para Intel Galileo, en Ayuda Firmware Update:

Figura 46: descarga del firmware


http://www.arduino.cc/en/Main/Software



No se debe desconectar la placa de la alimentación ni de USB al PC mientras dura el proceso de actualización de firmware:

El enlace para descargar el firmware es mismo que para descargar el IDE de Arduino 1.5.3:


Para la utilización de la aplicación java, es necesario descargar el entorno de programación de Eclipse para implementar, depurar y ejecutar el código. La descarga se realiza en el siguiente enlace:

http://www.eclipse.org/downloads/packages/eclipse-ide-java-developers/lunasr2

También es necesario descargar una versión de java 1.8. Dependiendo del uso que se le quiera dar a la aplicación se pueden descargar dos tipos de paquetes:

JRE: para ejecutar archivos de java. Se descarga en el siguiente enlace:

http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html

JDK: para desarrollas archivos de java y ejecutarlos. Se descarga en el siguiente enlace:

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

Y por último, es necesario descargar el paquete de la librería RXTX correspondiente:

http://mfizz.com/oss/rxtx-for-java

Figura 47: carga del firmware en la placa Intel Galileo


http://www.eclipse.org/downloads/packages/eclipse-ide-java-developers/lunasr2





http://mfizz.com/oss/rxtx-for-java



Para la instalación del paquete se almacenan los archivos .dll en la carpeta del proyecto de eclipse:

6.2 Utilización del IDE Arduino

Una vez abierto el entorno de Arduino, se conecta la placa y se busca el tipo de placa que sea. En el caso de la Intel Galileo sería de la siguiente manera:

Figura 49: selección de la placa

Figura 48: librería RXTX



También se selecciona el puerto COM asociado a la placa:

Figura 50: selección del puerto COM



Después de seleccionar todo, cargamos el código a la placa:

Figura 51: cargar código a la placa



6.3 Utilización del Entorno de Eclipse

Para abrir el entorno de Eclipse, lo primero que hay que hacer es seleccionar la carpeta en el que esté el proyecto java:

Figura 52: seleccionar proyecto eclipse



Una vez seleccionada comprobamos que es la carpeta correcta y damos al botón “OK” para que se abra el entorno java con el proyecto cargado:

Con el proyecto java cargado, se ejecuta dando al play:

Figura 54: ejecutar proyecto java

Figura 53: abrir el proyecto java



Y como resultado se puede ver la interfaz gráfica de la aplicación java, con la que se pueden comunicar el coordinador y los sensores:

6.4 Desarrollo del sistema

En este apartado se describirá como se ha ido implementando el sistema poco a poco hasta llegar al sistema final por completo.

6.4.1 Sensor

Para comenzar a desarrollar el sistema, se hará una prueba únicamente con el sensor, para ello en el sketch sensor.ino añadimos la siguiente línea de código al comienzo de la función loop ():

Figura 55: interfaz gráfica de la aplicación java

Figura 56: línea código del sketch sensor.ino



Lo segundo que se hace es añadir a una placa Intel Galileo, una placa emontx y el módulo ZigBee. Para que pueda haber comunicación más adelante con el coordinador, se ha tenido que hacer una conexión de los pines Rx y Tx directamente al módulo ZigBee, para que la información no se devuelva por USB sino por ZigBee:

Para poder guardar el fichero de texto report.txt en el sensor, es necesario meter una tarjeta microSD de máximo 32 GB en la Intel Galileo:

A continuación, se conecta el sensor SCT-013 a la placa emontx y a su vez éste al

adaptador del enchufe al que está conectado el cargador del portátil, para que el sensor mida

Figura 57: placa Intel Galileo: Sensor

Figura 58: tarjeta microSD de la Intel Galileo



su corriente. Y se conecta la fuente de alimentación a la placa Intel Galileo y el cable USB al puerto USB Client de la placa Intel Galileo:

Después de eso se carga el sketch sensor.ino a la Intel Galileo y se abre la ventana del monitor serie:

Figura 60: abrir el monitor serie

Figura 59: conexión del sensor



Como se aprecia en la siguiente figura, se pueden ver las medidas de la corriente que va realizando el sensor:

Figura 61: medidas del sensor



6.4.2 Sensor y coordinador

Después de comprobar el correcto funcionamiento del sensor de manera independiente. Se añade al código del sketch del sensor.ino otra línea de código más para que envíe la medida realizada por ZigBee al coordinador:

También se añade el coordinador, conectándolo por el puerto USB del PC, con el módulo XBee conectado a los puertos 2 y 3 para que el Arduino reciba los datos del sensor a través de ZigBee y no del puerto USB:

Figura 63: conexión del coordinador al PC

Figura 62: líneas del código sketch sensor.ino:



Se selecciona la placa del coordinador: Arduino Uno, el puerto COM utilizado por el coordinador y se le carga el sketch coordinador.ino para que el sensor a la vez que va realizando las medidas de corriente se las vaya enviando al coordinador por ZigBee, y éste las muestre por su ventana de monitor serie:

Figura 64: medidas recibidas por el coordinador



Se puede apreciar que las medidas que realiza el sensor, derecha de la siguiente figura, coinciden con los datos que recibe el coordinador, izquierda de la siguiente figura:

Figura 65: comparación de los datos entre el coordinador y el sensor



6.4.3 Sensores y coordinador

Y por último para completar el sistema entero, añadimos una segunda Intel Galileo como un sensor más:

Se carga en el primer sensor el sketch sensor.ino pero añadiendo en el código un identificativo para cada sensor y un delay diferente, para que el coordinador no reciba la información de los dos sensores justo a la vez, en el caso del primer sensor sería “sensor 1” y delay(1000):

Estas líneas sólo se añadirían para esta prueba, ya que al ejecutar la aplicación java y realizar la comunicación de los mensajes entre el coordinador y los sensores desde la interfaz gráfica, no hay ningún problema de que se solapen los mensajes recibidos en el

Figura 67: código sensor 1 del sketch sensor.ino

Figura 66: conexión del segundo sensor



coordinador porque él mismo es el que al solicitar los recursos en el mensaje de solicitud, pone al principio la dirección del sensor al que va dirigido.

Y en el caso del segundo se cargaría el sketch sensor2.ino y las líneas del código cambiarían en poner “sensor 2” y el delay un poco mayor delay(1500):

El primer sensor sigue midiendo la corriente del cargador del portátil y el segundo sensor medirá la corriente que pasa por el circuito de la bombilla, utilizado en el apartado 4.1.1 Objetivo el sistema, con una bombilla de 100W:

Figura 68: código sensor 2 del sketch sensor.ino

Figura 69: conexión completa de los 2 sensores



Se puede apreciar como el coordinador recibe tanto los datos de un sensor como del otro:

Figura 70: monitor serie del coordinador con los 2 sensores



6.4.4 Aplicación java

Con el sistema completo, se puede poner en funcionamiento la aplicación java para ver desde la interfaz gráfica como es el intercambio de los mensajes, con el formato descrito en el apartado 4.1.2 Descripción del sensor, entre el coordinador y los sensores:

En el recuadro del “Envío del mensaje al sensor” es donde se escribe el mensaje que se va a enviar desde el coordinador al sensor. Y en el recuadro de “Respuesta del sensor” se ve lo que recibe el coordinador como respuesta de lo que envía el sensor. Un ejemplo del intercambio de mensajes, al solicitar desde el coordinador la medida de corriente, es el siguiente:

Figura 71: interfaz gráfica de la aplicación java

Figura 72: intercambio de mensajes entre el coordinador y el sensor



7. CONCLUSIONES

Como visión general del trabajo realizado se va a proceder a describir el problema inicial propuesto, la solución planteada y los resultados obtenidos.

7.1 Problema inicial

En la gestión de los dispositivos que componen la Arquitectura de la Red de las Cosas, aparece la problemática de que no todos los dispositivos comparten el mismo protocolo de comunicación entre ellos ni tampoco hacen la gestión de la misma manera, no contemplan las mismas operaciones. En este sentido el documento D1.5 de IoT-A propone un conjunto cerrado de operaciones que son las que aquí se han intentado especificar e implementar. Por todo esto, hay que realizar la gestión e implementarla de manera específica dependiendo del dispositivo del que se trate y la manera de la que se quiera obtener información de él y/o utilizar.

7.2 Solución propuesta

Con este objetivo de desarrollar e implementar la gestión en una Arquitectura de la Red de las Cosas, se ha montado un sistema con una placa Arduino como coordinador, que actúa únicamente como gateway, varias placas Intel Galileo como sensores y un PC. Desde el PC se inicia la interfaz gráfica para interactuar con los sensores, por medio de los mensajes que se escriben en ella. El coordinador manda el mensaje a los sensores por ZigBee y el sensor al que corresponda (que coincida su dirección con la del mensaje de solicitud) responderá al coordinador con un mensaje con la información solicitada y éste se verá en la interfaz gráfica. Se han desarrollado varios componentes funcionales de IoT: configuración, estado, presentación de informes y dispositivo. Este último componente de funcionalidad consiste en que desde la interfaz gráfica del PC se puede mandar un mensaje para que los sensores que estén encendidos/operativos manden un mensaje de respuesta con su dirección y los recursos que realizan. Y también se ha añadido la funcionalidad de que el sensor actúe de medidor, la cual es su función principal, y envíe al PC, a través del coordinador, un mensaje con la medida realizada.

Con el despliegue e implementación de este prototipo se ha conseguido el objetivo inicial: proponer y desarrollar una manera de gestionar sistemas con dispositivos conectados a IoT usando CoAP. De esta manera, la solución propuesta cumple tanto las condiciones del mundo científico sobre gestión de sistemas/dispositivos como las condiciones que plantea IoT. Siendo una forma más sencilla y viable de gestionar dispositivos.

Una vez cumplido el objetivo inicial, se tiene una solución que nos proporciona de forma efectiva, gestionar dispositivos conforme propone IoT.



7.3 Resultados obtenidos

Se ha conseguido el objetivo inicial deseado: desarrollar la gestión correcta, de una manera más sencilla y viable, del sistema de los componentes funcionales de IoT mencionados anteriormente, ya que era el objetivo principal de este Proyecto de Fin de Grado.

En las pruebas realizadas, en el apartado 5 Resultados, del sistema se puede ver como el mensaje que el sensor devuelve al coordinador es el esperado, descrito en el apartado 4.1.2 Descripción del sistema. En caso de que el sensor esté encendido envía el mensaje solicitado y en caso contrario el sensor envía el mensaje avisando de que el dispositivo está apagado y de que si se quiera utilizar se debe encender.

El tiempo de respuesta entre que el coordinador envía el mensaje de solicitud al sensor y que el sensor responde con la información solicitada es también el esperado para que no se produzca solapamiento entre mensajes.

No existe perdida de paquetes entre el coordinador y el sensor en ninguno de los dos sentidos de la comunicación bidireccional. Por tanto, al no perderse ningún paquete no existe perdida de información.

7.4 Conocimiento nuevo

El conocimiento nuevo que se puede derivar de toda la información expuesta en esta memoria, consiste principalmente en la comunicación entre las placas Intel Galileo y la placa Arduino y sobretodo en el desarrollo de la gestión del sistema como Arquitectura de la Red de las Cosas.

Se ha desarrollado un protocolo utilizando CoAP y siguiendo las especificaciones del modelo propuesto para IoT: los recursos de un dispositivo se modelan y se ofrecen como servicios. Básicamente lo que es REST, pero para el desarrollo de este proyecto se ha seguido el protocolo CoAP para no sobrecargar las capacidades de los dispositivos, ya que es un protocolo más ligero que los que se propone para SOAP-HTTP-TCP.

7.5 Trabajos futuros

Como futuras líneas de trabajo se podría desarrollar la gestión del sistema por completo, implementando los componentes funcionales de IoT que faltan que en este caso sería el de fallos.

Además se podrían proponer y desarrollar nuevas operaciones como por ejemplo la que se ha desarrollado en este proyecto para obtener las medidas de corriente de los sensores.

Existen también otras posibles plataformas para desarrollar sistemas con las características que se han propuesto en este prototipo. Como pueden ser: Raspberri Pi,



BeagleBone o incluso hacer una mezcla de varias de estas plataformas para probar un sistema más heterogéneo.

Otro trabajo futuro sería proponer una ampliación de IoT-A management para que incluya aspectos de M2M, que ahora mismo no cubre como puede ser proporcionar información de inteligencia sobre los datos previamente normalizados. Esta ampliación desarrollando aspectos de M2M haría posible que IoT llegue al entorno industrial y robótica industrial.

Se podría estudiar el comportamiento del sistema cuando hay muchos más sensores, es decir, analizar su escalabilidad viendo hasta cuántos dispositivos sería capaz de soportar.



8. GLOSARIO

WS-Addressing: define un espacio de nombres que se utiliza para identificar servicios web.

WS-Transfer: define las operaciones de envío y recepción de la representación de un recurso y las operaciones de concreto para la creación o eliminación de un recurso y de su representación correspondiente.

WS-Enumeration: protocolo que enumera una secuencia de elementos XML que pueden representar las colecciones de datos, registros u otras estructuras de información lineal.

WS- Eventing: protocolo que permite a un servicio web (el suscriptor) suscribirse y aceptar los mensajes de notificación de eventos de otro servicio web (el origen del evento).

Firmware: bloque de instrucciones de máquina para propósitos específicos, grabado en una memoria, normalmente de lectura/escritura, que establece la lógica de más bajo nivel que controla los circuitos electrónicos de un dispositivo de cualquier tipo.

WinRM: es una característica de Windows Vista que permite a los administradores ejecutar scripts de gestión remota. Se ocupa de las conexiones remotas por medio del Protocolo de WS-Management. Tiene características similares a las de Windows Management Instrumentation (WMI) que se ha instalado en todos los ordenadores que utilizan Windows Millennium Edition (Me), Windows 2000, Windows XP o Windows Server 2003.

POST: envía información desde el cliente para que sea procesada y actualice o agregue información en el servidor, como sería la carga o actualización en sí de una noticia. [15]

Wiring: plataforma similar de programación de código abierto.



LISTA DE REFERENCIAS BIBLIOGRÁFICAS

[1] «CISCO,» [En línea]. Available: http://www.cisco.com/web/ES/tomorrow-starts-here/ioe/index.html. [Último acceso: 20 febrero 2015].

[2] F. Carrez, «IoT-Architecture-Documento D1.5 de IoT-A,» 15 julio 2013. [En línea]. Available: http://www.iot-a.eu/public/public-documents/d1.5/view. [Último acceso: 28 febrero 2015].

[3] N. I.-T. Y.2060, «SERIE Y: INFRAESTRUCTURA MUNDIAL DE LA INFORMACIÓN, ASPECTOS DEL PROTOCOLO INTERNET Y REDES DE LA PRÓXIMA GENERACIÓN,» 06/2012.

[4] «MSDN-Microsoft,» 2015. [En línea]. Available: https://msdn.microsoft.com/en-us/library/aa384470%28v=vs.85%29.aspx.

[5] D. -. Microsoft. [En línea]. Available: http://www.dmtf.org/sites/default/files/standards/documents/DSP0226_1.0.0.pdf. [Último acceso: 28 febrero 2015].

[6] X. G. Gimenez. [En línea]. Available: http://upcommons.upc.edu/pfc/handle/2099.1/18314. [Último acceso: 20 febrero 2015].

[7] Z. Shelby, agosto 2012. [En línea]. Available: https://tools.ietf.org/html/rfc6690. [Último acceso: 25 marzo 2015].

[8] Z. Shelby, junio 2014. [En línea]. Available: http://tools.ietf.org/html/rfc7252. [Último acceso: 20 marzo 2015].

[9] «Arduino,» [En línea]. Available: http://www.arduino.cc/en/Guide/Introduction. [Último acceso: 14 junio 2015].

[10] «Proyectos Arduino,» 12 abril 2014. [En línea]. Available: http://www.proyectosarduino.com/arduino-intel-galileo/. [Último acceso: 14 junio 2015].

[11] «ZigBee Alliance,» 2015. [En línea]. Available: http://www.zigbee.org/what-is-zigbee/. [Último acceso: 14 junio 2015].

[12] C. M. MacKenzie, «OASIS,» 2 agosto 2006. [En línea]. Available: https://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf. [Último acceso: 10 junio 2015].

[13] Intel, Intel® Galileo Board, Intel® Galileo Gen 2 Board, and Intel® Edison Board, 2014.



[14] «SIGMA,» 2015. [En línea]. Available: http://www.sigmaelectronica.net/000v-p-2170.html. [Último acceso: 18 junio 2015].

[15] C. Á. Caules, «arquitecturajava,» 14 junio 2013. [En línea]. Available: http://www.arquitecturajava.com/servicios-rest/. [Último acceso: 12 marzo 2015].

proyecto fin de grado - oa.upm.esoa.upm.es/38797/1/tfg_lidia_andres_espinal.pdf · para ellos, los...

Documents