Embed Size (px)
Citation preview
Escu
ela
Po
lité
cn
ica
Su
pe
rio
r d
e L
ina
res
UNIVERSIDAD DE JAÉN Escuela Politécnica Superior de Linares
Trabajo Fin de Grado
______
INFRAESTRUCTURA CLOUD PARA APLICACIONES EN EL
ÁMBITO DE INTERNET DE LAS COSAS
Alumno: Jesús Bermejo Torrent Tutor: Prof. D. Sebastián García Galán
Prof. D. José E. Muñoz Expósito Depto.: Ingeniería de Telecomunicación
Enero 2016
Autor
D. Jesús Bermejo Torrent
VºBº Tutores
Prof. D. Sebastián García Galán Prof. D. José E. Muñoz Expósito
Agradecimientos
El Trabajo Fin de Grado es resultado del esfuerzo y dedicación por parte del autor. Sin
embargo, no hubiera sido posible sin la ayuda de aquellas personas que de una u otra manera
me han apoyado en este esfuerzo. A todas ellas dedico estas líneas de agradecimiento.
En particular, quisiera agradecer a los profesores D. Sebastián García Galán y D. José
Enrique Muñoz Expósito, tutores de este trabajo, su apoyo y dedicación. Sin duda, el interés
estimulado por D. Sebastián y D. José Enrique ha tenido una gran influencia en el desarrollo
del mismo.
Quisiera también agradecer a D. Carlos Fernández, responsable de sistemas en el
Centro de Supercomputación de Galicia (CESGA), su apoyo durante mi estancia en Santiago
de Compostela en el verano de 2014. Durante este período, con la puesta en marcha de mi
primera infraestructura de “Cloud Computing”, me inicié en las tecnologías que permitieron
definir las bases para este trabajo y posteriormente introducirme en tecnologías “Big Data”.
A mi familia, que me ha brindado toda la ayuda posible, me ha animado en todo
momento y han conseguido que pueda disponer del tiempo necesario.
Muchas gracias a todos.
Jesús Bermejo Torrent
Linares 2016
1
TABLA DE CONTENIDO
1 Resumen ...................................................................................................................... 3
2 Introducción.................................................................................................................. 4
3 Objetivos ...................................................................................................................... 7
3.1 Objetivo del Trabajo Fin de Grado ...................................................................... 7
3.2 Organización del Documento .............................................................................. 7
4 Materiales y Métodos ................................................................................................... 9
4.1 Fundamentos Previos y Alcance del Trabajo ...................................................... 9
4.1.1 Internet de las Cosas y la Infraestructura de Telecomunicaciones ............... 9
4.1.2 Cloud Computing ........................................................................................10
4.1.3 Big Data ......................................................................................................12
4.2 Plan del Proyecto ..............................................................................................16
4.2.1 Introducción al Plan del Proyecto ................................................................16
4.2.2 Organización ..............................................................................................16
4.2.3 Metodología de Gestión ..............................................................................16
4.2.4 Programa de Trabajo – Diagrama de Gantt ................................................17
4.2.5 Descripción de las Actividades del Plan......................................................19
4.2.6 Gestión de Riesgos ....................................................................................21
4.2.7 Otros Aspectos Relevantes del Proyecto ...................................................23
4.3 Análisis ..............................................................................................................24
4.3.1 Definición del Sistema ................................................................................24
4.3.2 Hardware del Demostrador .........................................................................26
4.3.3 Entorno Tecnológico de Desarrollo .............................................................30
4.3.4 Estándares y Normas .................................................................................31
4.3.5 Requisitos ...................................................................................................31
4.3.6 Identificación de Actores y Casos de Uso Representativos ........................36
4.3.7 Sensorización/Adquisición de Datos e Interacción con Actuadores/Control 37
4.3.8 Solicitud de Análisis de Datos Masivos .......................................................40
4.3.9 Análisis de la Interfaz de Usuario ................................................................42
4.3.10 Comunicación con Sistemas Externos ........................................................42
4.4 Diseño ...............................................................................................................43
4.4.1 Definición del Sistema – Subsistemas de Diseño .......................................43
4.4.2 Subsistema Infraestructura Cloud-IaaS Computación - OpenNebula ..........44
4.4.3 Subsistema Infraestructura Cloud-IaaS Almacenamiento – Cassandra ......45
2
4.4.4 Subsistema Input/Output – Raspberry Pi y Arduino ....................................51
4.4.5 Subsistema Cloud-IoT PaaS Middleware Computación – Apache Karaf.....52
4.4.6 Subsistema Cloud-IoT PaaS Middleware Analítica - Hadoop y Spark .........58
4.4.7 Subsistema Cloud-SaaS Aplicación – Aplicaciones de Demostración ........62
4.5 Construcción del Demostrador...........................................................................64
4.5.1 Subsistema Infraestructura Cloud-IaaS Computación .................................64
4.5.2 Subsistema Infraestructura Cloud-IaaS Almacenamiento ...........................66
4.5.3 Subsistema Input/Output ............................................................................68
4.5.4 Subsistema Cloud-IoT PaaS Middleware Computación ..............................68
4.5.5 Subsistema Cloud-IoT PaaS Middleware Analítica .....................................69
4.5.6 Subsistema Cloud-SaaS Aplicación ............................................................69
4.6 Pruebas .............................................................................................................72
4.6.1 Alcance y Entorno de Pruebas ...................................................................72
4.6.2 Niveles de Prueba ......................................................................................73
5 Resultados y Discusión ...............................................................................................74
5.1 Resultados del Demostrador Realizado .............................................................74
5.2 Discusión ...........................................................................................................75
6 Conclusiones ...............................................................................................................78
6.1 Posibles Mejoras ...............................................................................................79
7 Referencias Bibliográficas ...........................................................................................80
3
1 RESUMEN
El nuevo paradigma de Internet de las Cosas se encuentra actualmente en sus
comienzos. Sus implicaciones van probablemente más allá de lo que nos podemos
imaginar al considerar un futuro de trillones de dispositivos conectados y transmitiendo
información para gestionar el entorno que nos rodea; comunicaciones, energía,
transporte, fabricación e incluso monitorizando y actuando con nuestro organismo para
mejorar los sistemas actuales de salud.
El presente Trabajo Fin de Grado pretende profundizar experimentalmente en las
arquitecturas y soluciones tecnológicas para abordar este paradigma. En el mismo se
cubre un espectro muy amplio, que va desde la sensorización e interacción con el mundo
físico, al almacenamiento, cubriendo también propuestas de plataforma para el análisis
masivo de datos, frecuentemente denominado tecnologías “Big Data”. Para extraer
conclusiones relevantes se ha desarrollado un demostrador extremo a extremo
incorporando soluciones tecnológicas de última generación para el control y adquisición
de datos y su gestión.
El demostrador desarrollado combina una infraestructura OpenNebula, para dar
soporte a la gestión de máquinas virtuales, con la base de datos NoSQL Cassandra,
altamente escalable y tolerante a fallos. Sobre esta infraestructura se ha incorporado una
solución para analítica basada en Apache Hadoop que posteriormente ha sido migrada a
Apache Spark por su mejor adecuación a los escenarios de Internet de las Cosas.
Para la integración de “las cosas” en la infraestructura de computación y analítica
se introduce el concepto de “IoT Gateway” o “pasarela IoT”. Las pasarelas se basan en
un middleware modular y dinámico orientado a servicios desarrollado sobre OSGi (Open
Services Gateway initiative) implementando el protocolo REST para la interconexión de
servicios distribuidos.
Un escenario real de despliegue se simula con un centro de datos virtual para
procesamiento en tiempo real y otro analítico. Para evaluar el correcto funcionamiento de
la infraestructura propuesta se ha desplegado una pasarela IoT sobre una Raspberry Pi
accediendo a sensores de humedad y temperatura. Sobre la infraestructura de centros de
datos simulados se han desarrollado tres aplicaciones: visualización de valores actuales
de temperatura y humedad, evolución en tiempo real de la temperatura y cálculo de
valores promedio distribuyendo tareas entre distintos nodos analíticos.
Finalmente, se han extraído y discutido conclusiones, identificando áreas de
mejora y expansión del demostrador desarrollado.
4
2 INTRODUCCIÓN
La relación entre los seres humanos y los dispositivos electrónicos con capacidad
de computación ha evolucionado muy rápidamente durante los últimos años definiendo
diferentes eras tecnológicas. Durante los años 60, en la época de los “Mainframes”, se
difundieron en el campo empresarial. Se extendieron al entorno familiar en los años 80,
con el ordenador personal. Diez años más tarde, al aparecer el teléfono móvil, se
establece una relación personal "uno a uno" (Figura 1).
Actualmente, nos estamos moviendo rápidamente hacia una relación de "uno a
muchos". Reproductores Mp3, navegadores para ayuda a la conducción, relojes y
pulseras inteligentes, Smarts-TVs son solo algunos ejemplos del creciente número de
dispositivos con conectividad a Internet. Estos dispositivos interaccionan con
infraestructuras de computación con capacidades impresionantes de procesamiento; es
el comienzo de Internet de las Cosas (Figura 2).
Figura 1: Eras tecnológicas anteriores al Internet de las Cosas
5
Figura 2: Dispositivos con conexión a Internet por cada 100 habitantes (2)
Desde el punto de vista de las infraestructuras de comunicación también podrían
identificarse tres grandes periodos en la expansión de la infraestructura (Figura 3):
Conexión de lugares geográficos dispersos.
Conexión de las personas.
Conexión de las cosas.
6
Figura 3: Evolución hacia Internet de las Cosas – Ericsson (3)
Estamos ante un nuevo escenario que requiere el desarrollo de tecnologías
capaces de afrontar los nuevos retos; el “Cloud Computing” y las tecnologías de “Big
Data” son probablemente las más representativas. Por otra parte, y en paralelo, se está
reduciendo drásticamente el coste de sensores y actuadores, así como de los
procesadores capaces de interactuar con interfaces analógicas y digitales, o incluso de
procesar información localmente con una capacidad de computación creciente. Arduino
(4) y Raspberry Pi (5) son probablemente las iniciativas actuales más representativas en
este campo.
7
3 OBJETIVOS
3.1 Objetivo del Trabajo Fin de Grado
El Internet de la Cosas es un campo cada vez más relevante en contextos de
investigación (1) y a la vez está emergiendo en aplicaciones industriales. El objetivo del
Trabajo Fin de Grado “Infraestructura Cloud para Aplicaciones en el Ámbito de Internet de
las Cosas” es el desarrollo de un demostrador basado en infraestructura Cloud y
tecnologías Big Data que permita experimentar y extraer conclusiones sobre soluciones
tecnológicas adecuadas para aplicaciones en el dominio de Internet de las Cosas.
3.2 Organización del Documento
El presente documento, tras la parte introductoria, se estructura, siguiendo las
recomendaciones para trabajos fin de grado de naturaleza experimental incluyendo un
capítulo de materiales y métodos seguido de la exposición de resultados y su discusión.
Para finalizar se presentan las conclusiones y se incluyen referencias bibliográficas
externas.
El capítulo de materiales y métodos constituye una parte relevante de la memoria
que se descompone a su vez en:
Fundamentos Previos y Alcance del Trabajo. En esta sección se introducen áreas
particularmente relevantes para poner en contexto el trabajo desarrollado. En
particular, incluye información relativa a Internet de las Cosas y a la infraestructura
de Telecomunicaciones, al Cloud Computing y a las tecnologías Big Data.
También se posiciona el alcance del proyecto en relación a estas áreas.
Plan del Proyecto. Esta sección describe la metodología llevada a cabo durante
su desarrollo y el plan de trabajo, incluyendo descripción de las actividades
llevadas a cabo y su organización temporal, recursos, áreas de riesgos más
relevantes y estrategias para minimizar estos.
Análisis. En esta sección se recoge la identificación de necesidades en términos
de requisitos y Casos de Uso UML (6) de alto nivel para definir el alcance de
trabajo. Todo ello, en términos de un lenguaje independiente de las soluciones de
diseño, constituyendo la especificación del sistema a diseñar.
Diseño. Esta sección describe cómo se resuelven, desde el punto de vista de
soluciones software, las necesidades previamente definidas respondiendo a
criterios de calidad (ej. nivel adecuado de abstracción, modularidad,...) que
faciliten su construcción y mantenimiento, así como una posible extensión. En
este caso el lenguaje utilizado es mucho más orientado al dominio software.
8
Construcción. Esta sección resume los aspectos más relevantes relativos a la
codificación y al desarrollo del trabajo, configuraciones e instalaciones necesarias
para su funcionamiento.
Pruebas. En esta sección se describe la estrategia del plan de pruebas y su
alcance, así como los criterios que se utilizan para considerarlas satisfactorias.
En el capítulo de resultados y discusión se exponen los resultados del
demostrador discutiendo los aspectos más relevantes.
Posteriormente se describen las conclusiones del trabajo desarrollado incluyendo
aspectos como observaciones globales relevantes o posibles extensiones futuras.
Finalmente, en las Referencias Bibliográficas se incluyen las fuentes externas utilizadas
para llevar a cabo el trabajo.
9
4 MATERIALES Y MÉTODOS
4.1 Fundamentos Previos y Alcance del Trabajo
Para poner en contexto el desarrollo del presente trabajo e introducir las áreas
particularmente relevantes, a continuación exponemos de manera muy breve el impacto
del Internet de las Cosas en la infraestructura de telecomunicaciones, la computación
Cloud y las tecnologías de Big Data.
4.1.1 Internet de las Cosas y la Infraestructura de Telecomunicaciones
Aunque las implicaciones del Internet de las Cosas van más allá de las
tecnológicas, nos centraremos en estas últimas e inicialmente, al enmarcase este
proyecto en un trabajo fin de grado de ingeniería telemática, en el impacto sobre las
estructuras de telecomunicaciones.
Según la visión de Marcus Weldon, presidente de los laboratorios Bell (inventores
del láser, transistor y Unix entre otras cosas), el sistema de telefonía móvil tendrá que ser
rediseñando durante los próximos años para acomodar sensores, actuadores, cámaras y
las conexiones de control remoto necesarias. La tendencia actual es tan importante como
la Revolución Industrial o la aparición de Internet; es la instrumentalización de todo lo que
nos rodea.
En los próximos años se medirá todo a nuestro alrededor y será posible controlar
la mayoría de las máquinas. Sin embargo, las redes actuales no están preparadas para
gestionar la cantidad de objetos que enviará señales durante los próximos años.
Actualmente, una estación base celular puede gestionar señales de 1.200 dispositivos
aproximadamente, suficientes para los usuarios de telefonía móvil. Durante los próximos
años deberá ser capaz de gestionar 300.000.
La señalización, como muchas otras tareas de computación masiva, se está
moviendo a la nube. Sin embargo, por los requisitos de tiempo real, esta computación es
difícil que pueda realizarse en centros de datos lejanos de manera centralizada. Los
centros de computación deben estar más cercanos a las torres. En el caso de la quinta
generación de las redes móviles (5G), el consenso industrial es mantener latencias de 1
milisegundo para poder llevar a cabo tares de control casi en tiempo real. Por esta razón,
centros de datos podrían estar situados entre 10 y 100 kilómetros de las torres. Las
celdas también deberán estar más distribuidas y cercanas a los usuarios para poder
reutilizar las frecuencias. Celdas más pequeñas, que se han retrasado en el pasado, para
reducir los costes de instalación, podría ser necesarias, permitiendo utilizar frecuencias
10
muy altas. Esto está llevando a la discusión de abrir nuevas bandas con estas
características en algunos Gobiernos (7).
Resumiendo lo anterior, y como consecuencia del Internet de las Cosas, podemos
esperar, no solo mayores necesidades de computación, sino también modelos Cloud más
distribuidos y con requisitos de tiempo real más estrictos que los actuales para permitir la
gestión optima del espectro electromagnético disponible. La evolución de la
infraestructura de comunicaciones puede depender en gran medida de aspectos
legislativos, estandarización y de la relevancia de modelos económicos que justifiquen a
los operadores actuales invertir en nuevas infraestructuras. Aun considerando importante
lo expuesto en este apartado, y el hecho de que soluciones tecnológicas abordadas
pueden ser aplicables también a la infraestructura de red, el desarrollo del demostrador
parte del estado del arte en soluciones disponibles comercialmente.
4.1.2 Cloud Computing
El Cloud Computing o Computación en Nube es un nuevo paradigma de
computación cuya principal característica es la de estar diseñado para funcionar bajo
demanda, utilizando los recursos hardware disponibles según se necesiten, típicamente
de un centro de datos. En este sentido, frecuentemente se le ha asimilado a un servicio
como la electricidad, el agua o el gas. Servicios que una vez contratados permiten un
consumo variable y su facturación es dependiendo del uso. Esta característica es
particularmente importante al modificar radicalmente el modelo de negocio del “producto
software” convencional.
Sin embargo, existen diferencias fundamentales frente a la electricidad, el agua o
el gas, que han catalizado un desarrollo sorprendentemente rápido. En este nuevo
contexto un programador individual, o un grupo pequeño de estos, puede desarrollar una
aplicación y desplegarla a nivel mundial sin coste. Los costes de operación se
repercutirán por el proveedor de la infraestructura dependiendo de los recursos
(computación, almacenamiento y red) utilizados por los usuarios de la aplicación en las
distintas partes del mundo. Esta nueva aproximación, denominada frecuentemente “pay-
as-you-go”, pone al alcance de nuevas microempresas un gran potencial, siendo una de
las principales razones de su rápido desarrollo.
En el caso de las aplicaciones móviles, el Cloud Computing ha permitido el rápido
desarrollo de los “Markets” de aplicaciones móviles, plataformas donde las empresas
(frecuentemente nuevas microempresas) las despliegan a disposición de los usuarios.
Los modelos de negocio en este caso son generalmente el pago por la descarga de la
aplicación o la publicidad que llega al usuario a través de esta. Por el alcance mundial y
11
el gran número de usuarios potenciales ha surgido una nueva categoría de aplicaciones a
precios muy reducidos, originando un despliegue muy rápido del modelo de negocio.
Desde el punto de vista arquitectónico, la elasticidad, entendida como la
capacidad crecer o decrecer en utilización de recursos según la demanda es la
característica fundamental del Cloud. La estructura de las capas de software, sin
embargo, pueden asimilarse a las convencionales funcionando, cada una de ellas, como
un servicio elástico. La equivalencia a continuación facilita el entender como el producto
software tradicional se transforman en servicio bajo el nuevo paradigma así como el
desarrollo del demostrador objetivo del trabajo (Figura 4):
Sistema operativo (producto)-> Infraestructura (como Servicio)
Middleware (producto)-> Plataforma (como servicio)
Aplicación (producto) -> Software (como servicio)
Figura 4: Capas de computación Cloud: IaaS, PaaS, SaaS
Para la gestión por software de la batería de recursos en un centro de datos
(computación, almacenamiento, red) frecuentemente se virtualizan para poder
considerarlos como un “pool” único disponible a compartir por las distintas aplicaciones.
La gestión de las distintas capas Cloud se puede llevar a cabo manualmente, por una
consola de administración, o por software, a través de un API.
12
Bajo este esquema, el dominio del proyecto se define en la Figura 5. Por la
extensión del problema cubriremos las distintas capas desde el punto de vista de Internet
de las Cosas. No abordaremos aspectos de virtualización de red, campo en el que
actualmente hay gran actividad y que, por sí mismo, según hemos introducido, podría ser
objetivo de un amplio estudio independiente.
Figura 5: Alcance del proyecto en el contexto de las áreas introducidas
4.1.3 Big Data
El concepto de Big Data emerge con la aparición de grandes volúmenes de datos
muy difíciles de capturar, almacenar, gestionar, compartir, analizar y visualizar con las
herramientas de base de datos convencionales. Estos nuevos requisitos surgen de
escenarios relativamente recientes.
Consecuencia de la infraestructura y servicios en Internet es un aumento
exponencial de los datos durante los últimos años. El Internet de las Cosas constituye un
punto de inflexión, en una tendencia ya exponencial, que originará un volumen de datos
más allá de la extrapolación de la tendencia durante los últimos años (8).
800 Terabytes, 2000
160 Exabytes, 2006
13
500 Exabytes (Internet), 2009
2.7 Zettabytes, 2012
35 Zettabytes, 2020
En general los escenarios Big Data se caracterizan por un volumen, variedad y
velocidad de generación muy superiores a los gestionados convencionalmente.
Volumen：Gigabyte(109), Terabyte(1012), Petabyte(1015), Exabyte(1018),
Zettabytes(1021)
Variedad: Datos estructurados, semi-estructurados, sin estructura (texto,
imagen, audio, video)
Velocidad: Dinámica, a veces dependiendo del tiempo.
La instrumentación de lo que nos rodea en Internet de las Cosas requerirá
procesar una importante cantidad de información. Su gestión y la toma de decisiones
asociada requerirán la explotación al límite de las tecnologías de Big Data. En la Figura 6
se presenta el valor potencial del Big Data en distintos segmentos del mercado según un
análisis del Instituto Global de McKinsey.
Figura 6: Valor potencial del Big Data
Las tecnologías de Big Data no surgen solo como consecuencia de un gran
volumen de datos en el dominio de aplicación. La infraestructura de computación en sí
14
misma es un área que está originando actualmente un amplio abanico de herramientas
de análisis y gestión de infraestructuras de computación basadas en tecnologías de Big
Data. En el “Hype Cycle” del 2015 de Gartner de la Figura 7 observamos como la
analítica avanzada para el auto-despliegue se servicios se presenta en el vértice y la
plataforma para Internet de la Cosas (IoT Platform) a mitad de la pendiente inicial.
Figura 7: Hype Cycle de Gartner 2015
Como consecuencia de lo anterior, surge un amplio abanico de soluciones en el
entorno de Big Data que, desde el punto de vista tecnológico, se pueden clasificar en las
siguientes áreas:
Almacenamiento
Búsqueda
Procesado/Analítica
Visualización
Aprendizaje
Situando estas áreas en capas representamos el dominio del proyecto en la
Figura 8. Muchas tecnologías de visualización para facilitar la interpretación de grandes
volúmenes de datos están emergiendo actualmente. En general, la más adecuada
dependerá del tipo de problema. En nuestro caso, utilizaremos tecnologías de
15
visualización convencionales, por esta razón no se ha incluido esta capa dentro del
dominio del trabajo.
Figura 8: Capas Big Data y dominio del trabajo.
16
4.2 Plan del Proyecto
4.2.1 Introducción al Plan del Proyecto
En la presente sección se describen los apartados relevantes en relación a la
planificación del Trabajo Fin de Grado cuyos objetivos se han descrito en apartados
anteriores del presente documento.
4.2.2 Organización
En relación a la organización (Tabla 1) se identifican los interesados, principales
funciones y responsabilidades respondiendo a la organización habitual en los Trabajos
Fin de Grado.
Rol/Persona Funciones/ Responsabilidades
principales
Autor: Jesús Bermejo Torrent Desarrollo del trabajo
Tutores:
Prof. D. Sebastián García Galán
Prof. D. José E. Muñoz Expósito
Apoyo y supervisión
Tribunal de evaluación Evaluación del Trabajo Fin de Grado
Tabla 1: Principales actores involucrados en el trabajo fin de grado.
4.2.3 Metodología de Gestión
Una gestión del proyecto basada en metodologías tradicionales de gestión de
proyectos en cascada, o fases secuenciales, es de difícil aplicación debido al hecho de
que las tecnologías base (Cloud Computing y Big Data) constituyen áreas nuevas de
conocimiento para el autor.
Por esta razón se ha optado por un método de gestión próximo a las metodologías
agiles, que facilitan la respuesta de la gestión a la imprevisibilidad. Para el desarrollo del
trabajo se adopta un sistema de desarrollo incremental e iterativo en secuencias
(frecuentemente denominados sprints), muy popular en los desarrollos de Internet. Sin
responder exactamente a modelos de gestión como Scrum (8) u otros, (por estar estos
orientados al desarrollo en equipos) se han adoptado muchas de sus ideas.
Teniendo en cuenta que las metodologías agiles consideran ciclos muy pequeños
y con alto paralelismo entre fases de análisis, diseño, desarrollo y pruebas, en el
Diagrama Gantt (Figura 9) se presenta información a más alto nivel. Se representan
tareas distribuidas en periodos donde el esfuerzo dedicado a las mismas ha sido
representativo, aunque en muchos casos, por la metodología adoptada en el desarrollo,
17
se han llevado a cabo actividades asociadas fuera de los periodos presentados. El
impacto de otras actividades académicas y dificultades durante el desarrollo han llevado
a la revisión de la planificación en varias ocasiones.
Fuera del periodo representado también se han llevado a cabo actividades
relevantes. En particular, durante el verano de 2014, el autor llevó a cabo una estancia en
Santiago de Compostela en la que, apoyado por el Centro de Supercomputación de
Galicia, puso en marcha y configuró una primera versión de la plataforma de Cloud
Computing utilizada en el trabajo para cubrir los requisitos de computación en la capa
IaaS.
4.2.4 Programa de Trabajo – Diagrama de Gantt
A continuación se presenta la planificación del proyecto en un Diagrama de Gantt
(Figura 9) incluyendo las actividades llevadas a cabo. Tras el diagrama de Gantt se
describen las tareas representadas.
18
Figura 9: Diagrama de Gantt.
19
4.2.5 Descripción de las Actividades del Plan
Tarea Descripción/Objetivo Estimación
Esfuerzo (h)
Fundamentos
Previos
Actividades necesarias para complementar
la formación académica del Grado con los
aspectos teóricos necesarios para llevar a cabo el
trabajo.
50
Cloud Computing Formación en tecnologías de Cloud
Computing. Incluyendo estancia en Santiago de
Compostela apoyado por el Centro de
Supercomputación de Galicia (excluida de la
estimación del esfuerzo).
20
Big Data Formación en tecnologías de Big Data para
el procesado masivo de datos.
20
Middleware Formación en tecnologías de Middleware
idóneo para el desarrollo del demostrador
10
Análisis Identificación de las necesidades del
desarrollo en términos de requisitos y Casos de
Uso (UML) en un lenguaje apropiado para un
potencial cliente o usuario no experto en software,
constituyendo la especificación del sistema a
diseñar.
20
Requerimientos Determinar las expectativas del trabajo fin
de grado en términos de requisitos al sistema a
desarrollar.
5
Casos de Uso Identificación de los diferentes Casos de
Uso posibles del sistema con el objetivo de
determinar la funcionalidad requerida.
7
Selección
Tecnologías
Evaluación y selección de las tecnologías
de desarrollo del proyecto acotando, en la medida
de lo posible, riesgos de origen tecnológico. Más
concretamente, aborda la elección de la
plataforma Cloud IaaS, almacenamiento Big Data,
soporte para analítica, middleware, sistema de
8
20
desarrollo, lenguaje de programación, librerías
auxiliares y entorno de ejecución.
Diseño Descripción de cómo se resuelven desde
el punto de vista software las necesidades
previamente definidas respondiendo a criterios de
calidad (ej. Niveles adecuados de abstracción,
modularidad, ...) que faciliten su codificación y
mantenimiento, así como una posible extensión.
En este caso el lenguaje utilizado es mucho más
orientado al dominio software.
40
Subsistemas de
Diseño
Identificación de los subsistemas a diseñar
en el contexto del análisis llevado a cabo.
7
IaaS Cloud –
OpenNebula
Diseño de la utilización de la plataforma
IaaS Cloud seleccionada – OpenNebula.
4
Big Data –
Cassandra-
Hadoop-Spark
Diseño de la solución Big Data utilizada
incluyendo soporte a almacenamiento y analítica
basada en Cassandra y Spark, Desarrollo
intermedios llevados a cabo con Hadoop y Pig
18
Middleware – OSGi
Apache Karaf
Diseño del demostrador sobre la solución
middleware seleccionada OSGi-Apache Karaf
9
Integración
Sensores
Actuadores
Diseño de la integración de sensores y
actuadores en el demostrador
2
Construcción Construcción del sistema sobre la base del
diseño definido. Incluye las actividades de
codificación así como las configuraciones e
instalaciones necesarias para su funcionamiento.
80
Pruebas Actividades para proporcionar una
cobertura satisfactoria de las pruebas requeridas
durante el desarrollo. Incluye la definición de la
estrategia de pruebas, su alcance y ejecución así
como la definición de los criterios que se utilizan
para considerarlas satisfactorias en el contexto del
trabajo fin de grado.
20
Elaboración de la
Memoria y Entrega
Actividades necesarias para la elaboración
y entrega de la memoria.
75
21
Gestión del Proyecto
Actividades necesarias para la gestión del
proyecto fin de grado incluyendo el tiempo
necesario para la interacción con el tutor y
organización personal, gestionando los riesgos
periódicamente y reasignando prioridades a
tareas y actividades.
15
TOTAL Estimación tiempo total 300
Tabla 2: Descripción de las actividades del plan de trabajo
Los esfuerzos presentados en las tareas descritas en la Tabla 2 responden a una
estimación global de esfuerzo de 300 horas. At tratarse de un trabajo fin de grado
individual no aplica una definición de recursos y asignación de tareas a los mismos según
roles y responsabilidades. En todos los casos, las actividades de desarrollo descritas han
sido llevadas a cabo por el autor.
4.2.6 Gestión de Riesgos
Por el aspecto novedoso de muchas de los temas abordados se ha llevado a cabo
una gestión de riesgos que, sin ser rigurosa, ha servido para priorizar esfuerzos. Una vez
finalizado el proyecto, los riesgos identificados inicialmente son una referencia de interés
para conocer áreas críticas que han tenido que ser gestionadas.
Los riesgos identificados a priori en el Trabajo Fin de Grado se muestran a
continuación en la Tabla 3, evaluados y con las acciones propuestas/llevadas a cabo
para abordarlos. Los valores de probabilidad, impacto y prioridad corresponden al
comienzo del trabajo. Obviamente han ido evolucionando a lo largo del proyecto. Los
valores de prioridad son asignados para no tener más de tres acciones requeridas con
prioridad máxima simultáneamente. Se consideran distintos niveles para estos últimos
valores: Baja, Media-baja, Media, Media-alta, Alta.
Para clasificar los riesgos consideramos como posibles orígenes:
La tecnología del sistema objetivo (tecnológico)
El entorno de desarrollo (entorno de desarrollo)
El desarrollo del proyecto (gestión)
Origen externo a los anteriores (externo)
Origen Descripción Prob Impct Acciones
propuestas
Prio
R
01
Tecnológico
Conocimientos
previos en
Abordar inicialmente
tareas para
Alta
22
Cloud
Computing y
Big Data
insuficientes
Alta Alto desarrollar y
consolidar
fundamentos
tecnológicos.
R
02
Gestión
Estimación
de la
dimensión
del proyecto
inadecuada
Media
-Alta
Medio
-Alto
Adoptar metodología
de gestión que facilite
reacción a
imprevistos.
Aumentar el esfuerzo
inicialmente previsto.
Adaptar requisitos si
fuera necesario.
Media-
Alta
R
03
Externo
Dedicación a
otras
demandas
académicas
requerida
mayor de la
inicialmente
prevista
Media
Medio
-Alto
Modular esfuerzos
entre todas las
demandas
académicas para
gestionar
adecuadamente las
convocatorias
disponibles.
Media
R
04
Externo
Baja por
enfermedad
imprevista
Baja
Medio
-Alto
Intentar adelantarse a
la planificación inicial
en la medida de lo
posible.
Media
R
05
Tecnológico
/ Entorno de
desarrollo
Tecnología
nueva o no
probada
Media
-baja
Medio
-Alto
Elección de
infraestructura de
desarrollo de uso
extendido.
Realizar pruebas
iniciales que permita
identificar problemas
en una fase
temprana.
Cambio de
infraestructura si
fuera necesario.
Media
–Alta
23
R
06
Entorno de
Desarrollo
Pérdida de
información
por averías
en los
equipos de
desarrollo
Baja
Alto
Plan de Back-up
frecuente
Alta
Tabla 3: Riesgos identificados gestionados
4.2.7 Otros Aspectos Relevantes del Proyecto
Por la amplitud del dominio de aplicación y el tecnológico, dominio con una gran
actividad actual y en muy rápida evolución, se prevén a priori posibilidades de expansión.
Se registrarán los criterios de las decisiones tomadas y en las conclusiones de la
memoria se documentarán posibilidades de expansión futuras.
24
4.3 Análisis
En esta sección se recogen las necesidades del desarrollo. Todo ello en términos
de un lenguaje apropiado para un lector potencial no experto en software (usuario en un
caso general), constituyendo la especificación del sistema a diseñar.
Para llevar a cabo el análisis partimos del objetivo del proyecto, identificaremos
requisitos (ambos utilizado plantillas tipo) y definiremos Casos de Uso utilizando
metodología UML (Unified Modeling Language) para definir la funcionalidad requerida en
el sistema a desarrollar. Los casos de uso representarán visualmente un objetivo que un
potencial usuario quiere lograr con el sistema.
4.3.1 Definición del Sistema
El objetivo del Trabajo Fin de Grado “Infraestructura Cloud para Aplicaciones en el
Ámbito de Internet de las Cosas” es el punto de partida para la definición del sistema.
Según expuesto inicialmente se desarrollará un demostrador basado en infraestructura
Cloud que permita experimentar y extraer conclusiones sobre soluciones tecnológicas
adecuadas para aplicaciones en el dominio de Internet de las Cosas.
OBJ–001 Infraestructura Cloud para Aplicaciones en el Ámbito de
Internet de las Cosas
Versión 1.0
Autores Jesus Bermejo Torrent
Fuente Definición del Trabajo Fin de Grado
Descripción El Trabajo Fin de Grado desarrollará un demostrador basado en
infraestructura Cloud que permita experimentar y extraer conclusiones
sobre soluciones tecnológicas adecuadas para aplicaciones en el
dominio de Internet de las Cosas.
Importancia Alta, por constituir la definición del proyecto
Estado El objetivo se encuentra aprobado como consecuencia directa
del alcance del Trabajo Fin de Grado.
Comentarios No aplican comentarios adicionales
Tabla 4: Descripción formal del objetivo del desarrollo
Desde el punto de vista hardware consideramos tres grandes categorías:
Sensores y Actuadores. Dispositivos individuales o en red (ej. redes de
sensores) con capacidad de extraer información y/o actuar sobre las cosas
o el entorno físico.
25
Clientes Cloud o Internet Gateways. Dispositivos con capacidad de integrar
los sensores y actuadores e interaccionar con el Cloud.
Dentro de esta categoría consideraremos dos subcategorías atendiendo a su
capacidad de proceso y almacenamiento. Esta determina en gran medida los entornos
software que pueden procesar.
o Clientes Cloud Limitados
o Clientes Cloud Inteligentes
La barrera entre ambos es frecuentemente difusa. En general, los clientes Cloud
Inteligentes pueden procesar sistemas operativos y middleware de alto nivel, aunque con
limitaciones. En nuestro contexto denominaremos a ambos “IoT Gateways” o pasarelas
IoT.
Servidores. Ordenadores con capacidad de ejecución de infraestructura
Cloud.
Figura 10: Categorías de elementos hardware considerados
Para que el demostrador sea suficientemente representativo debería incluir
dispositivos de cada una de tres categorías mencionadas. Recogeremos este requisito en
una plantilla tipo que utilizaremos para este propósito.
26
RNF-01 Categorías de Elementos Hardware del Demostrador
Versión 1.0
Autores Jesús Bermejo Torrent
Fuentes Memoria del Trabajo Fin de Grado. Análisis.
Objetivos
asociados
OBJ-01: Infraestructura Cloud para Aplicaciones en el Ámbito de Internet de las Cosas
Descripción Para que el demostrador sea suficientemente representativo
debería incluir dispositivos de cada una de las siguientes categorías:
Sensores y Actuadores
IoT Gateways
Servidores
Actores
No aplicable
Comentarios El requisito refiere a la sección de Análisis de la memoria donde
se identifican categorías de componentes hardware en aplicaciones de
Internet de las Cosas.
Tabla 5: Requisito sobre categorías de elementos hardware del demostrador
4.3.2 Hardware del Demostrador
Desarrollando el requisito RNF-01 definimos continuación el hardware a utilizar en
el demostrador:
Sensores y Actuadores:
Sensor DHT11 de Temperatura y Humedad Relativa (Figura 11).
Proporciona información digital de temperatura y humedad del entorno con
las siguientes características:
o Rango de medida de humedad: 20%~90%RH
o Error en la medida de humedad: ±5%RH
o Rango de medida de temperatura: 0~60℃
o Error en la medida de temperatura: ±2℃
o Voltaje de trabajo: 5V
o Tamaño: 28x12x8mm
27
Figura 11: Sensor DHT11 de temperatura y humedad
Relé de dos canales de 5V con optoacoplador (Figura 12).
Cada uno de los canales necesita de 15-20 mA. Provisto de relés
AC250V 10A, DC30V 10A su interfaz estándar puede ser controlada
directamente por un micro-controlador (8051, AVR, PIC, DSP, ARM, MSP430)
Figura 12: Relé de dos canales
Clientes Cloud / Gateways IoT:
En esta categoría se han considerado dos dispositivos representativos de
clientes limitados e inteligentes; Arduino y Raspberry Pi respectivamente.
Arduino UNO R3 ATmega328P ATMEGA16U2 (Figura 13)
o 14 Entradas/salidas digitales
o 6 Utilizables como salidas PWM (Modulación por ancho de pulsos)
o 6 Entradas analógicas
o Alimentación externa 7-12V
o Voltaje de salida 3,3V y 5V
28
Figura 13: Placa Arduino UNO
Raspberry Pi 2 B (Figura 14)
El modelo B de Raspberry Pi 2 es la segunda generación de Raspberry Pi.
Sustituye al modelo original 1 B+ en Febrero de 2015, mejorando sus características con
una CPU ARM Cortex-A7 de cuatro núcleos a 900MHz y 1GB de RAM.
Figura 14: Placa Raspberry Pi 2 modelo B
Como el modelo anterior incluye:
o Puertos USB
o 40 pins GPIO
o 1 puerto HDMI
o 1 puerto Ethernet
o 1 audio y video compuesto de 3.5mm
o 1 interfaz de Cámara (CSI)
o 1 interfaz de Display (DSI)
o 1 slot para tarjeta Micro SD
o 1 núcleo para gráficos 3D VideoCore IV
29
Por su procesador ARMv7, puede ejecutar el rango completo de distribuciones
ARM GNU/Linux incluyendo Snappy Ubuntu Core y Microsoft Windows 10.
Servidor (Figura 15):
o Procesador: Intel(R) Core(TM) i5-3450 CPU 3.10GHz
o Memoria Ram: 8 GB
o Linux Debian 7 64bits
Figura 15: Servidor Intel(R) Core(TM) i5-3450 CPU 3.10GHz
A continuación, en la Figura 16, representamos cada uno de los elementos
seleccionados sobre las categorías identificadas anteriormente.
30
Figura 16: Categorías de elementos hardware y representantes de los mismos
4.3.3 Entorno Tecnológico de Desarrollo
Una característica muy atractiva de las aplicaciones escritas en Java es que son
portables a cualquier hardware siempre que exista una Máquina Virtual Java (JVM) para
ese sistema. Esto permite al desarrollador centrarse en la aplicación y no en las
peculiaridades de la gran variedad de hardware existente. En comparación con otros
lenguajes las ventajas de Java se derivan de los conceptos de alto nivel de programación
que maneja y la gran comunidad de desarrolladores, aumentando la productividad una
vez superada la curva de aprendizaje. En nuestro caso utilizaremos Java como lenguaje
de alto nivel siempre que sea posible. En el caso de considerar Arduino lo natural sería
desarrollar en su sistema de desarrollo habitual.
Una vez seleccionado el lenguaje, se reducen las posibilidades de los entornos de
desarrollo (IDE) más adecuados, que en este caso serían Eclipse o NetBeans. El primero
ha sido el elegido, fundamentalmente, por ser la opción considerada con mayor potencial
y expectativas de futuro.
UML (Unified Modelling Language) se utiliza como tecnología de modelado para el
análisis y el diseño. StarUML es la herramienta utilizada para el dibujo de los diagramas
correspondientes.
En relación el interfaz gráfico, actualmente existen muchos entornos utilizados en
Java para interfaces de usuario como AWT, Swing, SWT, SwingX, JGoodies, JavaFX,
31
Apache Pivot y Qt Jambi. En nuestro caso, por el tipo de visualizador que necesitamos,
utilizaremos las librerías Java JFreeChart (9).
Para los desarrollos en Arduino, existen distintos entornos como Arduino IDE,
Codebender, Eclipse (permitiendo desarrollar en C y C++) y Sublime Text 2. Arduino
IDE, es el entorno de desarrollo original y más difundido. El microcontrolador se programa
en el lenguaje de programación Arduino (basado en Wiring) y el entorno de desarrollo,
basado en Processing.
Resumiendo, el entorno tecnológico para el desarrollo estará compuesto por:
Sistema operativo del demostrador: Debian 7
Sistema operativo para ofimática de apoyo: Windows 7
Herramientas de análisis y diseño UML: StarUML 5.0
Entorno de desarrollo (IDE): Eclipse 4.4 (Luna)
Máquina Virtual: Java versión 1.8.0_20
Interfaz Gráfico: Librerías Java JFreeChart
Esta relación no incluye las distintas plataformas utilizadas para cubrir los distintos
subsistemas identificados en el diseño que se abordarán más adelante.
4.3.4 Estándares y Normas
Los siguientes estándares, normas y guías han sido utilizados como referencia
para el desarrollo del Trabajo Fin de Grado
Metodología de desarrollo: Metodología ágil (inspirada en Scrum)
Modelado Análisis y Diseño: Lenguaje de Modelado Unificado (UML)
Estilo de programación: Convenciones de codificación en Java de Sun
Microsystems
Normas específica para el Trabajo Fin de Grado (9):
Normativa sobre el trabajo fin de grado en la Universidad de Jaén
Normativa sobre trabajos fin de grado en la Escuela Politécnica Superior
de Linares
Normas de estilo y estructura de TFG
Modelo de portada para TFG
4.3.5 Requisitos
Para facilitar la lectura del documento, inicialmente recogemos requisitos con
referencia a secciones previas de la memoria. Estos constituyen el punto de partida para
los casos de uso que constituirán la técnica preferente para la identificación y el análisis
de requisitos. Por su naturaleza iterativa, incremental y evolutiva son adecuados para su
uso en metodologías de desarrollo ágil como la adoptada para el trabajo.
32
A continuación se recogen requisitos reflejados en secciones previas de la
memoria.
RNF-02 Entorno Tecnológico, Estándares y Guías
Versión 1.0
Autores Jesús Bermejo Torrent
Fuentes Memoria. Apartados previos. Ver descripción.
Objetivos
asociados
OBJ-01: Infraestructura Cloud para Aplicaciones en el Ámbito de Internet de las Cosas
Descripción El entono tecnológico y de desarrollo será según lo descrito en
los siguientes apartados:
Entorno Tecnológico
Estándares y Normas
Actores
No Aplica. Requisito Tecnológico de Desarrollo
Comentarios El requisito refiere a una sección previa de la memoria para
enlazar posteriormente con los Casos de Uso que cubren el requisito.
Tabla 6: Requisito sobre entorno tecnológico, estándares y guías
RNF-03 Infraestructura Cloud (IaaS)
Versión 1.0
Autores Jesús Bermejo Torrent
Fuentes Memoria. Fundamentos Previos Alcance del Trabajo.
Objetivos
asociados
OBJ-01: Infraestructura Cloud para Aplicaciones en el Ámbito de Internet de las Cosas
Descripción El demostrador incluirá una infraestructura software (IaaS) que
permita la utilización de recursos de computación bajo demanda, según
el modelo de computación Cloud.
Actores
No Aplica
33
Comentarios Aunque en el caso de nuestro demostrador podría requerirse
intervención manual, en un contexto real este requisito debería cubrirse
con por la infraestructura software, con un mínimo de intervención
humana.
Tabla 7: Requisito de infraestructura Cloud
RNF-04 Plataforma Cloud IoT (PaaS)
Versión 1.0
Autores Jesús Bermejo Torrent
Fuentes Memoria. Fundamentos Previos Alcance del Trabajo.
Objetivos
asociados
OBJ-01: Infraestructura Cloud para Aplicaciones en el Ámbito de Internet de las Cosas
Descripción El demostrador debe proponer una plataforma PaaS que, sobre
la funcionalidad proporcionada por la capa de infraestructura (IaaS),
facilite el desarrollo de aplicaciones IoT.
Actores
No Aplica
Comentarios Aunque en el caso de nuestro demostrador podría requerirse
intervención manual, en un contexto real este requisito debería cubrirse
con por la infraestructura software, con un mínimo de intervención
humana.
Tabla 8: Requisito de plataforma IoT – PaaS
RNF-05 Infraestructura Big-Data (Almacenamiento)
Versión 1.0
Autores Jesús Bermejo Torrent
Fuentes Memoria. Fundamentos Previos Alcance del Trabajo.
Objetivos
asociados
OBJ-01: Infraestructura Cloud para Aplicaciones en el Ámbito de Internet de las Cosas
Descripción El demostrador deberá considerar capacidad de almacenamiento
escalable para cubrir los requisitos de aplicaciones en Internet de las
Cosas.
34
Actores
No Aplica
Comentarios Aunque en el caso de nuestro demostrador podría requerirse
intervención manual, en un contexto real este requisito debería cubrirse
con por la infraestructura software, con un mínimo de intervención
humana.
Tabla 9: Requisito infraestructura Big Data de almacenamiento
RNF-06 Infraestructura Big-Data (Procesamiento/Análisis)
Versión 1.0
Autores Jesús Bermejo Torrent
Fuentes Memoria. Fundamentos Previos Alcance del Trabajo.
Objetivos
asociados
OBJ-01: Infraestructura Cloud para Aplicaciones en el Ámbito de Internet de las Cosas
Descripción El demostrador deberá considerar, en el contexto de las
soluciones tecnológicas elegidas, necesidades de procesamiento de
datos potencialmente muy elevadas.
Actores
No Aplica
Comentarios Aunque en el caso del demostrador desarrollado en el trabajo
esta funcionalidad es limitada, se tendrá en cuenta que en un contexto
real la necesidad de procesamiento podría ser muy elevada.
Tabla 10: Requisito de infraestructura Big Data para procesamiento y análisis
RNF-07 Sensorización/Adquisición de Datos
Versión 1.0
Autores Jesús Bermejo Torrent
Fuentes Memoria. Fundamentos Previos Alcance del Trabajo.
Objetivos
asociados
OBJ-01: Infraestructura Cloud para Aplicaciones en el Ámbito de Internet de las Cosas
Descripción El demostrador deberá contemplar la posibilidad de incorporar un
amplio número de sensores.
35
Actores
No Aplica
Comentarios Aunque en el caso del demostrador desarrollado en el trabajo
esta funcionalidad es limitada, se tendrá en cuenta que, en un contexto
real, podría requerirse integrar en el sistema un elevado número de
sensores.
Tabla 11: Requisito de sensorización/adquisición de datos
RNF-08 Interacción con Actuadores/Control
Versión 1.0
Autores Jesús Bermejo Torrent
Fuentes Memoria. Fundamentos Previos Alcance del Trabajo.
Objetivos
asociados
OBJ-01: Infraestructura Cloud para Aplicaciones en el Ámbito de Internet de las Cosas
Descripción El demostrador deberá contemplar la posibilidad de incorporar un
amplio número de actuadores.
Actores
Usuario
Comentarios Aunque en el caso del demostrador desarrollado en el trabajo
esta funcionalidad es limitada, se tendrá en cuenta que, en un contexto
real, podría requerirse integrar en el sistema un elevado número de
actuadores.
Tabla 12: Requisito de interacción con actuadores/control
RF-01 Interfaz Usuario/Visualización de Datos
Versión 1.0
Autores Jesús Bermejo Torrent
Fuentes Memoria. Fundamentos Previos Alcance del Trabajo.
Objetivos
asociados OBJ-01: Infraestructura Cloud para Aplicaciones en el Ámbito de
Internet de las Cosas
Descripción El demostrador incorporara funciones para visualizar información
de sensores para cubrir funcionalidad de extremo a extremo de manera
36
que permita extraer conclusiones.
Actores
Usuario
Comentarios Aunque el demostrador considerará la posibilidad de visualizar de
manera independiente un gran número de sensores y actuadores, no se
abordarán técnicas específicas de presentación visual de un gran
número de datos para su análisis visual/toma de decisiones, por
considerarse fuera del alcance del trabajo.
Tabla 13: Requisito de interfaz de usuario/visualización de datos
4.3.6 Identificación de Actores y Casos de Uso Representativos
Es relevante destacar que en teoría, y a largo plazo, se prevé que las aplicaciones
en el dominio de Internet de las Cosas serán en gran medida autónomas, no requiriendo
intervención humana explícita durante la ejecución. En nuestro caso consideraremos un
actor humano que tendrá la posibilidad de intervenir, según su voluntad,
independientemente de las leyes que definen la interacción de las cosas.
Consideraremos, por lo tanto, tres actores:
Sensores. Dispositivos que extraen información de las cosas y el medio
físico exterior.
Actuadores. Dispositivos con capacidad de intervenir en el espacio físico
exterior.
Usuario. Actor humano, con posibilidad de intervenir en los actuadores
independientemente de las leyes de comportamiento definidas. También
podrá solicitar el análisis de aspectos concretos para la toma de
decisiones. En particular, en nuestro caso, el usuario podrá visualizar la ela
humedad y la temperatura, la evolución de la temperatura y valores
promedio.
Los actores identificados interaccionan con el sistema en los siguientes Casos de
Uso representativos para el diseño del demostrador:
Sensorización/Adquisición de Datos e Interacción con Actuadores/Control
Solicitud de Análisis. Visualización de valores Históricos, actuaciones de Control
y presentación de valores promedios
Con los diagramas de ambos Casos de Uso pretendemos definir a muy alto nivel
la funcionalidad que implementa el demostrador de la infraestructura, si bien esta estará
diseñada para cubrir necesidades mucho más complejas.
37
4.3.7 Sensorización/Adquisición de Datos e Interacción con Actuadores/Control
El subsistema de adquisición de datos tendrá la capacidad de leer la información
de los sensores y registrar esta de forma masiva. La temperatura y humedad serán dos
ejemplos para demostrar esta funcionalidad (Figura 17).
Pueden definirse leyes de comportamiento que definirán las situaciones en las
que el sistema interviene en el espacio físico exterior a través de actuadores (control). En
nuestro caso se documentará en el diseño, a modo de ejemplo, como se incorporaría un
relé que se activa al superarse un umbral de temperatura.
La situación de los controladores existentes definirá el estado del sistema. En el
diagrama presentado a continuación asumimos que el estado del sistema viene definido
por la situación de los actuadores en un momento determinado. Para una aproximación
más general podrían considerarse estos también almacenado en la infraestructura Big
Data y el estado del sistema definido por el último valor proporcionado por los sensores y
la situación de los actuadores. El usuario podrá sobreponerse a las leyes establecidas
definiendo la situación de los actuadores en cualquier momento.
Figura 17: Caso de uso UML. Sensorización/Adquisición de Datos e Interacción
con Actuadores/Control
38
A continuación (Tabla 14, Tabla 15, Tabla 16, Tabla 17, Tabla 18) se describen los
casos de usos identificados en el diagrama:
CS01 Adquisición Datos
Descripción Adquiere datos del entorno físico exterior o de “las
cosas”
Actores Sensor
Precondición Pasarela (Gateway) inicializada y activado el muestreo
periódico de sensores
Postcondición Información de sensor leída y enviada para
almacenamiento
Flujo normal 1. Lectura de datos del sensor 2. Envío de datos leídos a la infraestructura Big Data para
almacenamiento
Flujo alternativo Si error en lectura de datos del sensor:
1. Informar a log de sistema
Observaciones Ninguna
Tabla 14: Caso de uso adquisición de datos
CS02 Almacenamiento Datos
Descripción Almacena datos de sensores leídos en infraestructura
Big Data
Actores Sensor
Precondición Infraestructura Big Data inicializada y operativa
Recibido dato de sensor externo
Postcondición Información recibida del sensor almacenada
Flujo normal 1. Almacenamiento de la información recibida del sensor con información de tiempo
Flujo alternativo Si error en almacenamiento
1. Informar a log de sistema
Observaciones Ninguna
Tabla 15: Caso de uso almacenamiento de datos
CS03 Leyes Comportamiento
Descripción Evalúa leyes de comportamiento según la información
de los sensores para actuar sobre el entorno exterior o “las
cosas”
Actores -
39
Precondición Lectura de sensor recibida
Postcondición Solicitud de acción sobre actuador realizada (si
relevante)
Flujo normal No hay variación respecto a la medida anterior:
1. Salir
Flujo alternativo Variación respecto a la medida anterior:
1. Evaluar leyes para determinar si debe actuarse sobre los actuadores externos
2. Solicitar acción sobre actuadores si fuera el caso
Observaciones Ninguna
Tabla 16: Caso de uso leyes de comportamiento
CS04 Control
Descripción Interacciona con los actuadores para el control del
entorno exterior o “las cosas”
Actores Usuario
Actuador
Precondición Solicitud de control recibida del sistema o del usuario
Postcondición Solicitud sobre el actuador realizada (si procede)
Solicitud de almacenamiento del nuevo estado del
sistema realizada
Flujo normal 1. Solicitud sobre el actuador
Flujo alternativo Si error:
1. Informar log del sistema
Observaciones Ninguna
Tabla 17: Casos de uso acción sobre dispositivo de control
CS05 Almacenamiento Estado
Descripción Registra el estado actual del sistema
Actores -
Precondición Cambio en actuadores del sistema
Postcondición Nuevo estado de actuadores almacenado
Flujo normal 1. Almacenar nuevo estado del actuador
Flujo alternativo -
Observaciones Ninguna
Tabla 18: Caso de uso almacenamiento de estado
40
4.3.8 Solicitud de Análisis de Datos Masivos
El sistema podrá llevar a cabo análisis masivo de datos a solicitud del usuario
(Figura 18). Para mostrar esta capacidad el demostrador incorpora un ejemplo sencillo, la
presentación, a solicitud del usuario, de valores promedio de temperatura en intervalos de
tiempo definibles por el usuario. La naturaleza masiva de la analística y de los datos se
ha considerado en el contexto de los requisitos no funcionales previos. Por lo que la
infraestructura tendrá la capacidad de análisis masivo, sobre un gran volumen de datos.
Figura 18: Caso de uso UML. Solicitud de análisis de datos masivos
A continuación (Tabla 19, Tabla 20, Tabla 21, Tabla 22) se describen los Casos
de Uso identificados en el diagrama:
CS06 Lectura Datos Relevantes
Descripción Lee de la infraestructura Big Data los datos relevantes
para el análisis solicitado
Actores Usuario
Precondición Datos requeridos por solicitud de análisis
Postcondición Datos relevantes leídos
Flujo normal 1. Lectura de datos relevantes para el análisis solicitado
41
Flujo alternativo Si error:
1. Informar al log del sistema
Observaciones Ninguna
Tabla 19: Caso de uso lectura de datos relevantes
CS07 Análisis
Descripción Realiza el análisis de los datos requeridos por el usuario
Actores Usuario
Precondición Solicitud de análisis requerida por el usuario
Postcondición Resultados de análisis disponibles
Flujo normal 1. Ejecutar algorítmica de análisis
Flujo alternativo Si error:
1. Informar al usuario
Observaciones Ninguna
Tabla 20: Caso de uso solicitud de análisis
CS08 Visualización
Descripción Representa los resultados del análisis llevado a cado
Actores Usuario
Precondición Resultados de análisis disponible
Postcondición Resultados de análisis visualizados
Flujo normal 1. Presentar en dispositivo de salida el resultado del análisis
Flujo alternativo -
Observaciones Ninguna
Tabla 21: Caso de uso visualización de resultados
CS09 Evolución en Periodo
Descripción Analiza la evolución de los sensores durante un periodo,
valor promedio, de tiempo en base a la información histórica
Actores Usuario
Precondición Solicitud de análisis de evolución en periodo requerida
por el usuario
Postcondición Resultado de análisis de evolución en periodo disponible
Flujo normal 1. Ejecutar algorítmica de análisis
Flujo alternativo Si error:
1. Informar al usuario
42
Observaciones Ninguna
Tabla 22: Caso de uso evaluación de evolución en período
4.3.9 Análisis de la Interfaz de Usuario
Al tratarse de un sistema demostrador de una infraestructura, los requisitos a la
interfaz de usuario no son particularmente exigentes. Se requiere que el demostrador
tenga soporte de interfaz de usuario suficiente para demostrar su potencial en:
Presentación de valores/datos asociados a “las cosas” en el momento
actual
Presentación en tiempo real de valores
Analítica sobre valores históricos, valor promedio
4.3.10 Comunicación con Sistemas Externos
El demostrador no considera comunicaciones con sistemas externos.
43
4.4 Diseño
Esta sección describe el cómo se resuelven desde el punto de vista software las
necesidades previamente definidas respondiendo a criterios de calidad (ej. niveles
adecuados de abstracción, modularidad,...) que faciliten su codificación y mantenimiento,
así como una posible extensión. En este caso el lenguaje utilizado en el documento es
orientado al dominio software.
4.4.1 Definición del Sistema – Subsistemas de Diseño
Del análisis realizado identificamos los siguientes sub-sistemas de diseño a
desarrollar (Figura 19):
1. Subsistema Infraestructura Cloud-IaaS Computación.
2. Subsistema Infraestructura Cloud-IaaS Almacenamiento.
3. Subsistema Input/Output
a. Subsistema Raspberry Pi – Sensores & Actuadores.
b. Subsistema Arduino - Sensores & Actuadores.
4. Subsistema Cloud-IoT PaaS Middleware Computación.
5. Subsistema Cloud-IoT PaaS Middleware Analítica.
6. Subsistema Cloud-SaaS Application
En la figura a continuación se presenta la arquitectura del sistema en términos de
los subsistemas identificados.
Figura 19: Arquitectura Software y Subsistemas de Diseño
44
4.4.2 Subsistema Infraestructura Cloud-IaaS Computación - OpenNebula
La infraestructura Cloud de Computación proporciona soporte para la optimización
de la capacidad de proceso en un centro de datos. Existen diversas soluciones, aunque
es un campo muy dinámico actualmente que evoluciona hacia un nuevo concepto de
sistema operativo nativo para aplicaciones cloud. En nuestro caso, utilizamos
OpenNebula (10) como infraestructura para la gestión de máquinas virtuales.
OpenNebula es un proyecto Open Source con una importante contribución española que
permite la gestión de una variedad de hipervisores (KVM, Xen, VMware) (Figura 20).
En nuestro caso utilizamos KVM (Kernel-based Virtual Machine). KVM es una
infraestructura de virtualización que convierte el kernel de Linux en un hipervisor,
permitiéndole la ejecución de máquinas virtuales. Se integró en la versión 2.6.20 del
mismo en Febrero de 2007. Para su ejecución requiere procesadores con extensiones
hardware para virtualización.
Figura 20: Funcionalidad de OpenNebula
4.1.1.1 Entorno OpenNebula del Demostrador IoT
En el demostrador IoT, OpenNebula nos permite configurar un entorno de
demostración con dos centros de datos virtuales cada uno con dos máquinas según el
esquema de la Figura 21. En general, el Frontend ejecuta los servicios OpenNebula
mientras los nodos ejecutarían máquinas virtuales. En nuestro caso, el Frontend de
OpenNebula se ejecuta en otra máquina virtual independiente a las cuatro que se
generarán en el demostrador. El sistema de ficheros NFS deberá configurarse tanto en la
45
máquina virtual del Frontend como en la máquina física donde está instalado para la
gestión adecuada de los ficheros de imágenes. Por otra parte, deben configurarse las
redes a utilizar por las máquinas virtuales.
Figura 21: Despliegue de OpenNebula en el demostrador IoT
4.4.3 Subsistema Infraestructura Cloud-IaaS Almacenamiento – Cassandra
En un escenario de IoT donde un gran número de sensores y actuadores que
adquieren información e interactúan sobre el entorno físico, la necesidad de escalabilidad
horizontal (utilización de un elevado número de nodos) es un requisito difícil de eludir. Por
otro lado, la infraestructura de almacenamiento debe estar disponible en todo momento.
Las bases de datos NoSQL aparecen para dar respuesta a estas necesidades. Al primar
la escalabilidad sobre otras características se diferencian del modelo relacional por tener
diferente aproximación a los esquemas, no permitir Joins y no intentar garantizar ACID
(Atomicidad, Coherencia, Aislamiento y Durabilidad). En general, están orientadas a
arquitectura distribuidas, proporcionando garantías de consistencia débil y soportando
estructuras de datos sencillas. Los tipos dependen de su implementación orientada a
diferentes tipos de aplicaciones:
• Almacenamiento Clave-valor (Precursor Dynamo de Amazon).
46
• Almacenes de Familias de columnas (Precursor Google BigTable,
e.j. Hbase, Cassandra ...).
• Almacenamiento de documentos (Inspiradas en Lotus Notes, e.j.
CouchDB, MongoDB).
• Grafos (Inspiradas en Euler y teoría de grafos).
Para cubrir los requisitos de almacenamiento en un escenario IoT altamente
distribuido y tolerante a perder la conectividad entre nodos debemos escoger entre
garantizar consistencia o la disponibilidad. La necesidad de elección es consecuencia del
teorema de CAP (Figura 22) que establece que en una base de datos no se pueden
garantizar de manera simultánea consistencia, disponibilidad y tolerancia a particiones.
Figura 22: Teorema de CAP
En nuestro caso consideramos necesaria la disponibilidad y la tolerancia a
particiones aunque no se garantice en todo momento la consistencia. En este caso,
distintos nodos de almacenamiento podrían no tener la misma información en el mismo
instante de tiempo, aspecto que se tendrá en cuenta en el diseño si fuera necesario.
La Tabla 1 compara las soluciones alternativas DynamoDB, Cassandra y
CouchDB. Cassandra (11) ha sido elegida como solución de almacenamiento Big Data en
el demostrador IoT tras analizar el tipo de información a registrar y teniendo en cuenta
que al ser open source podremos incorporarla en el demostrador.
47
Nombre DynamoDB Cassandra CouchDB
Descripción Proporcionada
como servicio de
almacenamiento
escalable en el
Cloud de Amazon
Almacenamiento
Clave-Valor con
nombre y formato
de columna
variable para cada
fila. Inspirada en
ideas de BigTable
y DynamoDB
Inspirada en
Lotus Notes
orientada a
almacenamiento
de documentos
Modelo de base
de datos
Almacenamiento
de documentos.
Clave-valor
Clave-valor.
Columnas con
nombre y formato
variable.
Almacenamiento
de documentos.
Sito Web aws.amazon.com/-
dynamodb
cassandra.apache.
org
couchdb.apache.
org
Documentación
Técnica
aws.amazon.com/-
documentation/-
dynamodb
www.datastax.com/
docs
wiki.apache.org/-
couchdb
Desarrollador Amazon Apache Software
Foundation
Apache Software
Foundation
Primera versión 2012 2008 2005
Licencia Comercial Open Source Open Source
Lenguaje de
implementación
Java Erlang
Sistemas
operativos
Disponible como
servicio
BSD
Linux
OSX
Windows
Android
BSD
Linux
OSX
Solaris
Windows
SQL No No No
APIs y métodos
de acceso
RESTful HTTP API Protocolo
propietario
RESTful
HTTP/JSON API
Lenguajes de .Net C# C
48
programación
soportados
ColdFusion
Erlang
Groovy
Java
JavaScript
Perl
PHP
Python
Ruby
C++
Clojure
Erlang
Go
Haskell
Java
JavaScript
Perl
PHP
Python
Ruby
Scala
C#
ColdFusion
Erlang
Haskell
Java
JavaScript
Lisp
Lua
Objective-C
OCaml
Perl
PHP
PL/SQL
Python
Ruby
Smalltalk
Triggers No Si Si
Métodos de
Partición
Sharding Sharding Sharding
Replicación Si Si.
Factores
seleccionables
Replicación
Maestro-Esclavo
MapReduce No Si Si
Concurrencia Si Si Si
Durabilidad Si Si Si
Derechos de
acceso
Derecho de acceso
para usuarios y
roles definibles por
servicios de
identidad y acceso
de Amazon
Derecho de acceso
para usuarios
definibles por
objeto
Derecho de
acceso para
usuarios
definibles por
base de datos
Tabla 23: Comparación bases de datos NoSQL
4.1.1.2 Cassandra
Cassandra (12) es una base de datos NoSQL con un modelo de datos en columna
originalmente desarrollada por uno de los autores de Dynamo, de Amazon, trabajando
49
posteriormente para Facebook. Es una base de datos distribuida y sin un «master» y que
utiliza el protocolo Gossip y con soporte para replicación entre centros de datos
distribuidos geográficamente (Figura 23). La consistencia es ajustable con distintos
métodos (ALL, QUORUM, LOCAL_QUORUM, ONE). DataStax (13) proporciona un driver
para Java que utiliza el leguaje CQL (Cassandra Query Language) para gestionar la
información.
Figura 23: Replicación de datos en Cassandra
4.1.1.3 Simulación de Centros de Datos
Para comprobar el correcto funcionamiento del sistema de replicación
simularemos dos centros de datos utilizando máquinas virtuales. Cada una de ellas
representará un nodo físico. En general, las funciones de analítica pueden requerir una
carga de computación elevada, así como el acceso a un gran número de datos. Para que
las necesidades de computación en funciones analíticas no degrade el comportamiento
del sistema de adquisición y control, que requiere respuesta en tiempo real, se
consideran dos centros de datos con distintas responsabilidades (Figura 24):
Centro de Datos de Adquisición y Control. Llevaría a cabo la adquisición
de datos de los múltiples sensores y las funciones de control.
Centro de Datos Analítico. Orientado a las funciones de análisis masivo de
datos.
50
Como en el demostrador pretendemos únicamente sacar conclusiones relativas a
la idoneidad de la infraestructura propuesta, se considera que la simulación de dos nodos
para cada uno de los centros de datos es suficiente.
Figura 24: Despliegue de centro de datos de adquisición y control y de analítica
4.1.1.4 Modelo de Datos
Cassandra proporciona unas prestaciones muy relevantes para problemas del tipo
de nuestro demostrador que se adapta muy bien al modelo “big table” siempre que las
tablas se diseñen de la manera adecuada. Es una base de datos óptima para almacenar
grades secuencias de datos independientemente de su tipo o tamaño. Las prestaciones
en lectura por clave de fila y rango en columnas son altamente eficientes ya que se
minimiza la búsqueda en disco.
A continuación describimos tres alternativas que pueden cubrir un amplio rango de
escenarios en Internet de las Cosas.
Dispositivo único por fila. El modelo más sencillo es crear filas de datos
para cada dispositivo con el valor del tiempo de cada medida como
nombre de la columna. Como las columnas son dinámicas la fila crecerá
según sea necesario para almacenar los datos.
Partición para limitar tamaño de la fila. Aunque en Cassandra una fila
puede almacenar 2 billones de columnas, en algunos escenarios puede no
ser suficiente. Para solucionar el problema se pueden crear filas
dinámicamente complementando el identificador del dispositivo con parte
de la información del tiempo de las medidas. Podríamos, por ejemplo,
crear filas para las medidas de un determinado sensor durante un mes.
Expiración de columnas. Cassandra soporta tiempo de expiración de
columnas. En aquellos casos en los que nos interese siempre un rango
51
previo a la fecha actual podemos utilizar la opción de que columnas
previas no relevantes vayan desapareciendo automáticamente.
En el demostrador desarrollado en nuestro caso utilizaremos un modelo de datos
de almacenamiento de dispositivo único por fila (Figura 25).
Figura 25: Tablas de datos registrados en Cassandra
4.4.4 Subsistema Input/Output – Raspberry Pi y Arduino
Consideramos el subsistema Input/Output la parte de software que cubre la
interfaz con los sensores y/o actuadores. En particular incluye los drivers y software de
acceso a los dispositivos no desarrollados en Java. En nuestro escenario consideramos
dos casos, representativos de cada una de las pasarelas consideradas; Raspberry Pi y
Arduino.
Subsistema Raspberry Pi – Sensores & Actuadores
El software de acceso al sensor DHT11 incluye las librerías Adafruit.
Desarrolladas en Python, utilizan C para la lectura a bajo nivel de las
entradas/salidas de propósito general en la Raspberry Pi (GPIO). Estas
librerías se instalan y se invocan posteriormente desde el bundle OSGi de
acceso a la información del sensor.
Subsistema Arduino - Sensores & Actuadores
En este caso también pueden utilizarse las librerías Adafruit para
acceso al DHT11 desde Arduino. El acceso a los datos del sensor se llevaría a
cabo desde un bundle Java en el servidor, accediendo a Arduino por un puerto
USB.
En la Figura 26 se representa el despliegue; un único contenedor OSGi
donde la pasarela, al estar en el servidor, sería virtual (sin un soporte físico) y
sin necesidad de soporte de OSGi distribuido (DOSGi). Únicamente se
requiere sustituir el bundle de captura de datos por el correspondiente de
52
Arduino. Con este ejemplo, observamos, también, las grandes ventajas de
reutilización que proporciona un soporte a la modularidad como el de OSGi.
Figura 26: Despliegue OSGi para Arduino
4.1.1.5 Integración de Actuadores
Para la integración de actuadores en el sistema pueden considerarse distintas
alternativas. En general, la solución más idónea dependerá del tiempo de respuesta
requerido y de la distribución del sistema.
La opción más sencilla para sistemas distribuidos con requisitos de tiempo no
elevados es la supervisión periódica de los sensores relevantes para las actuaciones
concretas. En función de la información proporcionada por los sensores se controlarían
los actuadores. Esta aproximación tiene la gran ventaja de estar altamente desacoplada
de la adquisición de información, siendo muy fácil la incorporación de actuadores sin
interferir en el sistema en funcionamiento.
Tiempos de respuesta mucho mejores pueden obtenerse si se evalúa la
necesidad de modificar un actuador en el mismo momento que cambia el valor
proporcionado por un sensor, como se sugería en el análisis. También podrían
incorporarse en el sistema buses distribuidos de altas prestaciones para permitir a los
actuadores suscribirse a la lectura de los sensores y actuar en consecuencia, con tiempo
de respuesta mucho mejores que si son integrados muestreando periódicamente el valor
de los sensores relevantes. Como mencionado anteriormente, en general, la mejor
solución dependerá del tipo de problema a resolver.
4.4.5 Subsistema Cloud-IoT PaaS Middleware Computación – Apache Karaf
Para soportar la capa PaaS (Platform as a Service) utilizaremos OSGi (14), un
sistema modular y dinámico que permite la descarga remota de componentes sin
53
necesitar reinicializar la máquina virtual Java (15). Incorpora un servicio de registro que
permite a los componentes (bundles) detectar nuevos servicios aquellos que
desaparecen para adaptarse dinámicamente, dependiendo de las circunstancias.
Los componentes desplegados tienen un ciclo de vida representado en el gráfico
de la Figura 27.
Figura 27: Ciclo de vida de los bundles OSGi
Utilizaremos un contenedor incluyendo un conjunto de servicios básicos Figura 28,
Apache Karaf (16) (17) (18):
Despliegue en caliente de bundles OSGi permitiendo actualización y borrado.
Soporta las aproximaciones Blueprint y Spring.
Configuración dinámica a través del servicio ConfigurationAdmin.
Sistema de Logging.
Aprovisionamiento de librerías o aplicaciones por distintos métodos.
Integración nativa como un servicio del sistema operativo.
Consola extensible.
Acceso remoto por SSH.
Framework de seguridad basado en JAAS.
Comandos para gestionar múltiples instancias de Karaf.
54
Figura 28: Servicios básicos en Apache Karaf
Este conjunto de servicios proponen una arquitectura básica para un nodo de
computación. Los servicios son únicamente accesibles desde el nodo donde se
despliegan.
4.1.1.6 Servicios distribuidos
En nuestro caso, con pasarelas con capacidad de computación avanzada (como
la Raspberry Pi), el middleware se distribuye entre servidores y pasarelas IoT (Figura 29).
Utilizando el soporte para OSGi distribuido se pueden definir servicios en un contenedor y
estos ser accesibles desde otro más allá de las fronteras físicas de una máquina. DOSGi
(19) es un subproyecto de Apache CXF (20), la implementación de referencia de la
especificación OSGi Remote Service Admin. DOSGi permitiría invocar desde un servicio
A en una pasarela IoT un servicio B disponible en el servidor (fig.29). A continuación
describiremos el funcionamiento del mismo.
55
Figura 29: OSGi Distribuido en el middleware de computación
La especificación de Remote Service Admin define una extensión del modelo de
servicio OSGi. Usando propiedades especiales al publicar un servicio OSGi se puede
transmitir a DOSGi que exporte el servicio para consumo remoto. DOSGi escucha todos
los servicios desplegados en el contenedor local pero solo procesa aquellos que tienen la
propiedad "osgi.remote.interfaces". Si se encuentra la propiedad es exportado con las
interfaces especificadas o con todas las que implementa. Como se lleva a cabo la
exportación puede ajustarse utilizando las opciones de configuración de CXF DOSGi.
Por defecto el servicio se exportará utilizando el transporte servlet de CXF. La
URL del servicio se deriva del nombre de la interfaz. El prefijo del servlet, nombre del host
y numero del puerto por defecto pueden definirse en las opciones de configuración. Por
defecto el servicio utiliza “CXF Simple Frontend” y “Aegis Databinding”. Si la interfaz del
servicio se anota con JAX-WS @WebService entonces el defecto es “JAX-WS frontend” y
“JAXB databinding”.
La información de los servicios se propaga por el soporte al descubrimiento de
DOSGi. En nuestro caso se ha utilizado la implementación Zookeeper (21), por lo que los
metadatos del servicio se escriben en un servidor Zookeeper.
El contenedor 2 monitoriza chequeará localmente los servicios necesarios y si
están disponibles en la implementación de descubrimiento (Zookeeper en nuestro caso).
Para cada servicio encontrado crea un proxy que actúa como servicio OSGi
56
implementando la interfaz. Las peticiones que lleguen se serializan enviándolas al
servicio Endpoint. De esta forma el middleware permite llamadas casi transparentes
configurables, pudiendo usarse exclusivamente el modelo de servicio OSGí para
comunicarse más allá de las fronteras de un contenedor OSGi (Figura 30).
Figura 30: OSGi distribuido
4.1.1.7 Adquisición y Almacenamiento de Datos
En un contexto de adquisición y registro de datos definimos un servicio en la
pasarela (IoTGateway) cuya función será orquestar los servicios de captura de datos
(Datacapture Service) y el de registro de los mismos situado en el servidor (Datacapture
Service). El servicio de captura de datos por su parte interactúa con el subsistema
Input/output mientras que el servicios de registro lo hace con el subsistema Cloud-IaaS
de Almacenamiento basado en Cassandra. Deberá tenerse en cuenta que al invocarse el
servicio de almacenamiento remotamente necesitaremos definir un bundle con el API
del mismo para instalarlo en ambos (Figura 31).
57
Figura 31: Despliegue middleware de computación
4.1.1.8 Interfaz de los Servicios
El servicio IoTgateway orquesta los servicios requeridos en la pasarela a través de
las interfaces definidas en los mismos. Estas se exportan desde bundles específicos,
independientes a los que proporcionan la funcionalidad del servicio.
Servicio Datacapture. Proporciona una interfaz que permite solicitar la
actualización del valor adquirido por una de las entradas de la Raspberry
sensor(String pin)
y obtener valores de humedad y temperatura
getHumedad(), (float)
float getTemperatura(), (float)
Servicio Datapersistence. Proporciona una interfaz para solicitar almacenamiento
de la dirección MAC de la pasarela origen de los datos, marca de tiempo,
humedad y temperatura.
mac (string)
fecha (string)
humedad (float)
temeperatura (float)
58
4.1.1.9 Servicio de Almacenamiento
El servicio de almacenamiento (Datapersistence) importa los paquetes del driver
Java para Cassandra de DataStax encapsulado en un bundle independiente. Utiliza el
protocolo binario CQL (Cassandra Query Language) de esta base de datos. El driver se
comunica con el clúster para registrar, devolver, manipular o borrar datos.
4.1.1.10 Diagrama de Interacción
En el diagrama de la Figura 32 se describe el comportamiento dinámico de los
servicios en el subsistema Middleware de Computación.
El servicio IoTgateway se inicializa una vez que el de persistencia y el de captura
están iniciados. Este lanza un Thread periódico para la captura y almacenamiento de
datos. En caso de error en el almacenamiento se solicita de nuevo conexión hasta que
esta se establezca de nuevo.
Figura 32: Diagrama de interacción. Middleware de computación
4.4.6 Subsistema Cloud-IoT PaaS Middleware Analítica - Hadoop y Spark
Durante los últimos años han aparecido y evolucionado una variedad de
plataformas para abordar una necesidad creciente de analítica derivada del aumento
59
masivo de datos actual. Sin duda alguna, Hadoop (22) ha sido la herramienta que más se
ha extendido conjuntamente con su ecosistema. Hadoop (23) cubre las áreas de
almacenamiento y la del soporte para analítica. En nuestro caso, ya que la base de datos
más idónea para nuestro problema es Cassandra, ha habido que integrar la parte de
analítica sobre Cassandra. Por otra parte, se ha combinado con Pig (24) para facilitar la
creación de programas MapReduce (25), usados en Hadoop. El lenguaje de esta
plataforma es llamado Pig Latin. Este abstrae la programación del MapReduce Java en
una notación que permite trabajar a más alto nivel, similar a SQL en las bases de datos
relacionales.
Sin embargo, la utilización de Hadoop por una amplia comunidad ha permitido
identificar ciertas limitaciones y actualmente existe un desplazamiento de muchos de los
proveedores de plataformas integrables con Hadoop hacia Spark (26) (27), siendo esta
una de las plataformas actuales Big Data con desarrollo software más activo. De hecho,
durante el proyecto, al cambiar la versión de Cassandra utilizada han parecido problemas
de compatibilidad.
La recomendación del proveedor principal de Cassandra en estos momentos es la
utilización de Spark. Por esta razón, nos hemos visto forzados a aumentar
sustancialmente el esfuerzo inicialmente requerido para la consideración de Spark como
solución en nuestro demostrador. A continuación relacionamos diferencias más
relevantes entre ambas soluciones.
Velocidad. Spark ejecuta trabajos de procesamiento por lotes de 10 a 100 veces
más rápido por reducción del número de lecturas y escrituras en el disco. MapReduce no
aprovecha la memoria del clúster Hadoop al máximo. En Spark el concepto de RDD
(conjunto de datos distribuidos en memoria) le permite guardar los datos en la memoria y
almacenarla en disco si y sólo si es necesario y así no tener ningún tipo de barreras de
sincronización que podría ralentizar el proceso. Al utilizar mucho mejor la memoria, el
motor de ejecución de Spark es mucho más rápido que Hadoop MapReduce.
Facilidad de Gestión. Con Spark es posible realizar streaming, procesamiento por
lotes y aprendizaje automático, todo en el mismo clúster. Es posible controlar diferentes
tipos de cargas de trabajo. Si hay una interacción entre diversas cargas de trabajo en el
mismo proceso es más fácil de administrar y asegurar dichas cargas de trabajo, lo que
actualmente es una limitación con MapReduce.
Gestión de flujo de datos en tiempo real. Con Spark es posible modificar los datos
en tiempo real a través de Streaming Spark. Esto se basa en un nuevo modelo de Big
Data para hacer cálculos con ventanas en los flujos de datos utilizando micro lotes.
Hadoop no soporta esta posibilidad.
60
El almacenamiento en caché. Spark tiene tiempos de latencia más bajos por
almacenamiento en caché de los resultados parciales a través de la memoria de los
trabajos distribuidos a diferencia de MapReduce que está orientado por completo al
almacenamiento en disco.
Recuperación. RDD (conjunto de datos distribuidos en memoria) es la abstracción
principal de Spark. Permite la recuperación de nodos fallidos por la re-cálculo y también
incorpora un estilo de recuperación más similar a Hadoop a través de puntos de control.
API. Hadoop MapReduce tiene una API muy estricta poco versátil. En Spark se
abstraen muchos de los detalles de bajo nivel, lo que permite una mayor productividad.
También mecanismos como la difusión broadcast de variables y acumuladores son
mucho más versátiles que los mecanismos existentes en Hadoop.
Scheduler. Como consecuencia de la computación en la memoria Spark incorpora
su propio planificador de flujo, mientras que con la aproximación estándar MapReduce
se necesita un planificador de tareas externo, como Azkaban (28) o Oozie (29), para
programar los flujos complejos.
Cálculos iterativos. Spark es mucho más eficiente siempre y cuando estamos
hablando de cálculos iterativos que deben pasar por encima de los mismos datos varias
veces. Pero cuando se trata de un único paso sobre grandes volúmenes de datos por
ejemplo, la transformación de datos o la integración de datos, entonces es más eficiente
MapReduce, al ser para lo que fue diseñado.
Coste. La memoria en el clúster Spark debe ser por lo menos tan grande como la
cantidad de datos que necesita procesar, ya que los datos tienen que encajar en la
memoria para un rendimiento óptimo. Por lo tanto, si se necesita procesar realmente Big
Data, Hadoop es la opción más barata ya que el coste del espacio en el disco duro crece
a un ritmo mucho menor que el espacio de memoria.
Teniendo en cuenta las prestaciones medidas Spark debería ser más rentable ya
que menos hardware puede realizar las mismas tareas mucho más rápido, especialmente
en la nube, donde se paga potencia informática por uso.
Seguridad. En Hadoop MapReduce tiene más funciones relativas a seguridad (30)
y proyectos como Sentry (31) ya que Spark es un proyecto más reciente.
4.1.1.11 Despliegue del Subsistema Cloud-IoT PaaS Middleware Analítica
La topología de un despliegue típico de Spark es muy similar a la de Hadoop.
Necesitarmos un nodo master Spark (sustituyendo al JobTracker de Hadoop), con el
NameNode y SecondaryNameNode. Los nodos TaskTracker de Hadoop interactuando
con Cassandra se sustituirán por Spark Slaves (Figura 33).
61
Figura 33: Despliegue de Centro de Datos Analítico Cassandra-Spark
En nuestro demostrador el centro de datos analítico esta simulado con dos
máquinas virtuales integrando Cassandra y Spark mientras que el nodo master será
ejecutándose directamente sobre el servidor host (Figura 34).
Spark proporciona acceso al API utilizándose en línea de comandos para analizar
datos interactivamente. Está disponible en Scala (que se ejecuta sobre la máquina virtual)
o en Python. La abstracción más importante en Spark son los elementos distribuidos
denominados RDD (Resilient Distributed Dataset) estos pueden crearse desde los
formatos de entrada Hadoop o transformando otros RDDs. Los RDDs soportan acciones,
devolviendo valores, y transformaciones, que devuelven punteros a nuevos RDDs.
Podemos encadenar acciones y transformaciones para obtener resultados complejos.
MapReduce es un patrón común, popularizado por Hadoop que puede ser implementado
fácilmente en Spark. Spark también soporta conjuntos de datos en memoria caché a nivel
de clúster, muy útil en el caso de acceder a datos de manera repetitiva. Las aplicaciones
utilizando el API Spark pueden llevarse a cabo utilizando Scala, Pyton y Java.
En nuestro caso, para demostrar el funcionamiento, calculamos el promedio de las
temperaturas con Sript en lenguaje Scala integrando las librerías de los drivers
62
correspondientes para acceder a Cassandra. Se crea un RDD con los datos de
temperatura y calculamos el valor promedio ejecutándose en paralelo.
Figura 34: Despliegue Spark demostrador IoT
4.4.7 Subsistema Cloud-SaaS Aplicación – Aplicaciones de Demostración
En el análisis del sistema se definió la funcionalidad a cubrir desde la capa de
aplicación para la visualización de la información de los sensores registrada y resultados
de la analítica. Consideramos tres aplicaciones de demostración: Visualización de datos
actuales, evolución en tiempo real y valores promedio sobre la plataforma de analítica
(Figura 35). Asumimos que los requisitos de tiempo para la presentación de valores
actuales son menos estrictos que los de la evolución en tiempo real de ahí que se
interactúa, en cada caso de demostración, con instancias de Cassandra en distintos
centros de datos.
63
Figura 35: Aplicaciones en la capa SaaS de demostración
64
4.5 Construcción del Demostrador
En este apartado se incluye una descripción de las actividades más relevantes
llevadas a cabo en la construcción del demostrador, incluyendo desarrollo software y la
configuración del sistema. Se desarrollan a continuación en el marco de cada uno de los
subsistemas de diseño.
Figura 36: Demostrador IoT
4.5.1 Subsistema Infraestructura Cloud-IaaS Computación
Para la puesta en marcha y configuración de la infraestructura Cloud se llevan a
cabo los siguientes pasos.
Instalación en el Frontend
o Añadir el repositorio de OpenNebula a los de Debian. en nuestro caso
al estar utilizando Debian 7.
# wget -q -O-
http://downloads.opennebula.org/repo/Debian/repo.key |
apt-key add -
# echo
65
"deb http://downloads.opennebula.org/repo/4.10/Debian/7
/ stable opennebula" \
> /etc/apt/sources.list.d/opennebula.list
o Instalar los paquetes requeridos. Se actualizan los repositorios e
instalan los paquetes opennebula, opennebula-sunstone y nfs-kernel-
server correspondientes a OpenNebula, la interfaz gráfica de usuario
(GUI) y el servidor NFS.
o Configurar y lanzar los servicios. Se Inician los servicios oned y se
modifica el archivo de configuración del sunstone /etc/one/sunstone-
server.conf, para acceder al servicio desde maquinas remotas. Se
cambia :host: 127.0.0.1 a :host: 0.0.0.0
o Configurar el NFS. Se exporta /var/lib/one del frontend a los
nodos, añadiendo en /etc/exports:
/var/lib/one/ *(rw,sync,no_subtree_check,root_squash)
o Configurar la clave pública del SSH sin contraseña hacia el nodo y a sí
mismo.
Instalación de los nodos
o Instalar el repositorio en los hosts y los paquetes requeridos, en éste
caso son opennebula-node, nfs-common y bridge-utils.
o Configurar la red. Se conecta la interfaz de red a un puente, editando el
archivo /etc/network/interfaces.
auto lo
iface lo inet loopback
auto br0
iface br0 inet static
address 192.168.1.70
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off
o Configurar el NFS. Se añade al fichero /nfs/tab:
192.168.1.69:/var/lib/one/ /var/lib/one/ nfs
66
soft,intr,rsize=8192,wsize=8192,noauto
y se monta a continuación :
# mount /var/lib/one/
o Configurar el emulador de procesadores Qemu de forma que el usuario
oneadmin sea capaz de utilizar libvirt como root
Lanzamiento de la infraestructura
o Se crean las redes virtuales que usarán cada máquina virtual:
- 192.168.1.71, 192.168.1.72 para el centro de datos de
adquisición y control.
- 192.168.1.73, 192.168.1.74 para el centro de datos analítico.
o Se preparan las imágenes que usan en cada máquina virtual, en
formato qcow2.
o Por último configuramos las plantillas de las máquinas virtuales, con los
recursos para cada máquina virtual:
-Cada VM del centro de datos de adquisición de control se le asigna 1
CPU y 1024 MB de memoria.
-Cada VM del centro de datos analítico se le asigna 1 CPU y 2048 MB
de memoria.
o Se ejecutan las máquinas virtuales.
4.5.2 Subsistema Infraestructura Cloud-IaaS Almacenamiento
Instalada la versión de Cassandra 2.1.2, sobre máquinas virtuales gestionadas por
OpenNebula es necesaria la configuración de dos archivos para adaptar la base de datos
distribuida a las necesidades del demostrador. En uno se definen los parámetros
generales de configuración y en el segundo la topología. Por otra parte, hemos de definir
los “keyspaces” que definirán la política de replicación utilizando el lenguaje específico de
Cassandra (CQL). NetworkTopologyStrategy define el número de réplicas de cada
centro de datos. En nuestro caso se replica en dos nodos, tanto en el centro de datos de
adquisición y control como en el analítico, para mantener el servicio en caso de
problemas en una de las máquinas. Para la creación del “keyspace” se accede al shell
CQL de uno de los nodos pertenecientes al clúster por cqlsh:
CREATE KEYSPACE sensor WITH REPLICATION = {'class' :
'NetworkTopologyStrategy', 'DC1' : 2, 'DC2' : 2};
También definiremos las tablas donde se almacenan los valores de los sensores:
CREATE TABLE temperatura ( mac text, fecha timestamp,
temperatura text, PRIMARY KEY (mac, fecha)) with clustering
order by (fecha desc);
67
CREATE TABLE humedad ( mac text, fecha timestamp, humedad
text, PRIMARY KEY (mac, fecha)) with clustering order by
(fecha desc);
A cada uno de los nodos Cassandra en un centro de datos (token ring) se le debe
asignar un rango de valores, que se usarán durante la configuración, ya que los datos se
distribuyen usando un token. Para ello se utiliza la siguiente fórmula proporcionada por
Datastax (15) en el caso de usar un tipo de partición Murmur3Partitioner:
python -c 'print [str(((2**64 / number_of_tokens) * i) -
2**63) for i in range(number_of_tokens)]'
Quedando la asignación de tokens en la siguiente forma:
Data Center 1:
Nodo 1: -9223372036854775808
Nodo 2: 0
Data Center 2:
Nodo 3:-9223372036854775807
Nodo 4:1
A continuación se revisa parte de la configuración de los dos archivos anteriormente
mencionados:
Archivo de parámetros de configuración. Se registran en el fichero
cassandra.yaml , Puede haber diferencias de unos nodos a otros, que en
nuestro caso se limitan a la IP y el valor de los tokens. Comentamos a
continuación las modificaciones y propiedades más relevantes:
o Se modifica en todos los nodos el nombre del clúster al que pertenece:
Cluster name: IoT
o Se configura la dirección IP para escuchar a los otros nodos Cassandra
Listen_address: dirección del nodo
o Para las consultas CQL se usa el puerto 9042:
Native_transport_port: 9042
o Para las consultas de clientes mantenemos el 9160:
-rpc_port: 9160
o Debido a que Cassandra usa una lista de semillas (seeds) para
encontrar otros nodos e identificar la topología del anillo, se define más
de un nodo para tener en cuenta la posibilidad de caídas.
-seeds: “192.168.1.72,192.168.1.71”
o El particionado elegido, Murmur3Partitioner, junto con la
estrategia de replicación, es el responsable de decidir qué datos serán
almacenados en qué nodo:
68
-partitioner:
org.apache.cassandra.dht.Murmur3Partitioner
o Los tokens se configuran según los calculados anteriormente. Se
asignan en la propiedad initial_token.
o Se indica la localización de los nodos, según lo definido en el archivo
cassandra-topology.properties:
-endpoint_snitch: PropertyFileSnitch
Archivo de definición de topología. En el fichero cassandra-
topology.properties se definen los centros de datos.
#Centro de datos de adquisición y control:
192.168.1.71=DC1:RAC1
192.168.1.72=DC1:RAC1
#Centro de datos analítico
192.168.1.73=DC2:RAC1
192.168.1.74=DC2:RAC1
4.5.3 Subsistema Input/Output
En el subsistema Input/Output se han integrado desarrollos llevados a cabo
durante prácticas académicas haciendo accesible los métodos disponibles en la
Raspberry Pi. Los valores de humedad y temperatura capturados de los sensores se
obtienen a través de métodos disponibles a tal efecto:
getHumedad(), (float)
float getTemperatura(), (float)
4.5.4 Subsistema Cloud-IoT PaaS Middleware Computación
Para la construcción de este subsistema instalamos el contenedor OSGi Apache
Karaf en el servidor y en la Raspberry Pi. Se instala también el servidor Zookeeper en el
host, un cliente en la Raspberry Pi y otro en el host para mantener los servicios de OSGi
distribuido sincronizados. OSGi distribuido se configura para comunicación con protocolo
REST.
Se han desarrollado los bundles OSGi siguientes para cubrir las necesidades
identificadas en el diseño y encapsulado los drivers de acceso a Cassadra en un bundle
especifico.
IoTgateway. Orquesta los servicios en la pasarela IoT solicitando servicios
de captura de datos y almacenamiento, según se requiera.
Datacapture. Solicita datos de los sensores
DatacaptureInterfaz. Interfaz de servicio de solicitud de datos a los
sensores
69
Datapersistence. Almacena los datos en la infraestructura de
almacenamiento
PersistenceAPI. Intefaz del bundle de persistencia
OSGI-CassandraDriver. Encapsula driver de Cassandra y todas sus
dependencias externas.
4.5.5 Subsistema Cloud-IoT PaaS Middleware Analítica
Por problemas de compatibilidad detectados durante la fase de construcción ha
sido necesario identificar versiones de Spark y Cassandra compatibles y reconstruir
desde el código fuente del driver la versión compatible con ambos. Una vez instalado se
configuraran los archivos que indican el nodo master y características de los esclavos y
un segundo archivo con la identificación de los esclavos por su IP. También debe
configurarse acceso SSH sin password del master a los esclavos. Aunque existen otros
ficheros que han sido adaptados, los mencionados son los principales.
Ficheros de configuración master-esclavo (spark-env.sh). Incluye la
configuración general del clúster Spark. Ésta configuración debe ser común en
todos los nodos, en ella se incluye la configuración general del clúster. Las
propiedades más importantes definidas son:
o -export SPARK_WORKER_INSTANCES=1
Especifica el número de “workers” en cada nodo
o -export SPARK_WORKER_CORES=1
A cada “worker” se le asigna un core
o -export SPARK_WORKER_MEMORY=1G
Asigna 1 core por “worker”
o -export SPARK_MASTER_IP= 192.168.1.70
Indica la dirección IP del master Spark
Fichero identificativos de los esclavos (slaves). Este fichero se interpreta
exclusivamente en el nodo master. Incluye la siguiente información:
# A Spark Worker will be started on each of the
machines listed below.
192.168.1.73
192.168.1.74
4.5.6 Subsistema Cloud-SaaS Aplicación
El potencial de la capa de aplicación lo demostramos en tres contextos:
o Valores actuales
o Evolución en tiempo real
70
o Analítica sobre valores históricos.
Cada uno de ellos lo desarrollamos de manera independiente
apoyándonos en la plataforma.
Visualización de valores actuales (Figura 37)
Para la visualización de los valores actuales se ha adaptado uno de los
ejemplos para presentar indicadores de la librería JFreeCharts. Lo encapsulamos
en OSGi y lo enlazamos con Casandra
utilizando el bundle OSGI previamente
desarrollado. Como se comentó en el diseño,
asumimos que estamos en un escenario
donde los requisitos de respuestas no son
altos (por ejemplo evolución de la
temperatura ambiental) por lo que esta
aplicación interacciona con una instancia de
Cassandra en el centro de datos destinado a
analítica, para no interferir en el sistema de
adquisición y control.
Visualización en tiempo real (Figura 38)
En el caso de visualización en tiempo-real suponemos que los requisitos
de tiempo, sin ser de tiempo real estricto, son más fuertes que los anteriores. En
este caso, enlazamos la aplicación a una instancia de Cassandra sobre el centro
de datos de adquisición y control. De manera similar al ejemplo anterior, utilizando
JFreeCharts, muestreamos periódicamente la base de datos y presentamos la
evolución de la temperatura de forma gráfica.
Figura 37: Valores actuales de humedad y temperatura
71
Figura 38: Evolución en tiempo real de temperatura
Analítica sobre valores históricos.
Para demostrar el funcionamiento del middleware de analítica Spark se ha
desarrollado un “script” en Scala para calcular valores promedio de los registros
de temperatura. El script carga inicialmente un RDD con los valores de Casandra
de temperatura. Se calcula el valor medio de las temperaturas registradas
paralelizando. Spark proporciona una consola Web desde donde se visualiza el
reparto de carga entre los distintos nodos al solicitar una analítica (Figura 39).
Figura 39: Consola Web Spark
72
4.6 Pruebas
4.6.1 Alcance y Entorno de Pruebas
El método de pruebas en V (32), frecuente en proyectos desarrollados en
cascada, está ampliamente aceptado para pruebas de sistemas software. El guión de
las pruebas está basado en documentos de requisitos que especifican cómo validar
una característica implementada. Sin embargo, este método no puede gestionarse en
proyectos desarrollados con metodologías ágiles y tampoco en el caso de nuestro
trabajo.
Una aproximación por pruebas exploratorias es más ligera, tiene menos
sobrecarga y si se hace correctamente puede tener una cobertura adecuada. Por otra
parte, no se necesita mucha preparación por adelantado para pruebas exploratorias
útiles. Las pruebas, en nuestro contexto, tienen que ser capaz de probar cualquier
cosa, en cualquier momento, con la mínima preparación por adelantado. También
hemos de tener en cuenta el contexto de un único desarrollador y el objetivo de un
trabajo fin de grado.
Teniendo en cuenta lo expuesto y alcance del trabajo se ha adoptado la
siguiente aproximación:
Pruebas exploratorias sobre las áreas novedosas o de riesgo.
Particularmente pruebas cuyo resultado pueda impactar en el diseño.
Pruebas exploratorias de los subsistemas de diseño identificados.
Pruebas de integración de subsistemas de diseño.
Pruebas globales del sistema cubriendo toda su funcionalidad.
En relación al entorno de pruebas, las pruebas son llevadas a cabo por el
desarrollador en su propio equipo, no siendo necesario ningún entorno adicional al
utilizado para el desarrollo. En este mismo entorno se desarrollarán pruebas a los
distintos niveles descritos.
El entorno de desarrollo permite reproducir el comportamiento del sistema con
un número variable de máquinas virtuales. En algunos casos se ha llegado a los
límites de memoria del sistema y los problemas de memoria han exigido reorientar la
aproximación utilizada. En particular, el cambio de Hadoop a Spark ha obligado a
adaptar la configuración de las pruebas debido al hecho de que Hadoop está muy
orientado a trabajar en disco mientras que Spark se basa fundamentalmente en la
utilización de memoria.
73
Obviamente, aunque el entorno de pruebas es útil para comprobar el
comportamiento del sistema desde el punto de vista funcional, no se reproduce el
aumento de prestaciones que se tendría en un entorno real de un centro de datos.
4.6.2 Niveles de Prueba
El esquema de pruebas previamente descrito se puede mapear sobre tres
niveles de pruebas:
Unitarias
o De módulos concretos. Vinculadas a las actividades de instalación,
configuración y desarrollo de módulos o bloques.
o De subsistemas de diseño. Para comprobar el correcto
funcionamiento de cada uno de los subsistemas identificados
Integración de los distintos subsistemas de diseño. Comprobación de la
correcta interoperabilidad entre subsistemas.
Globales. Incluyendo todos los subsistemas
Estos tres niveles de prueba se han llevado a cabo por el desarrollador, autor
de la memoria, tal como descrito en los apartados previos.
74
5 RESULTADOS Y DISCUSIÓN
5.1 Resultados del Demostrador Realizado
Durante el trabajo fin de grado se ha desarrollado un demostrador extremo a
extremo de una infraestructura para aplicaciones en el dominio de Internet de las
Cosas. La plataforma ha sido diseñada en base a requisitos que se presentan en este
tipo de escenarios; un elevadísimo número de dispositivos (sensores y actuadores)
que adquieren información del entorno físico y “las cosas” y la necesidad de actuar
sobre estas para conseguir el objetivo deseado.
En general, un entorno de operación típico de este tipo de plataformas se
implementaría sobre centros de datos distribuidos globalmente. En nuestro caso, se ha
simulado en una infraestructura virtualizada sobre una plataforma Cloud basada en
OpenNebula. Se simulan dos centros de datos; uno asumiendo funciones de
adquisición de datos y control en tiempo real y el otro las de analítica para extraer
conclusiones que determinen acciones futuras.
En el demostrador se ha incorporado una solución de almacenamiento masivo
basada en la base de datos NoSQL Cassandra. Aunque el demostrador se ejecuta en
un entorno limitado, en todas las soluciones adoptadas durante el diseño se ha
considerado que el escenario de un potencial despliegue real sería mucho mayor. De
hecho, existen despliegues basados en la solución de almacenamiento seleccionada
por encima de 75.000 nodos en el caso de Apple y por encima de 2.500 en el caso de
Netflix.
El demostrador considera la posibilidad de incorporar en la infraestructura un
número muy elevado de sensores y actuadores utilizando dispositivos intermedios
(gateways o pasarelas) de dos tipos; inteligentes y limitados. Las pasarelas acceden a
la infraestructura Cloud/Big Data a través de un middleware software basado en
Apache Karaf.
Sobre la infraestructura de almacenamiento se ha integrado otra de analítica
basada en Apache Hadoop que posteriormente fue sustituida por una basada en
Apache Spark de mejores prestaciones para analítica masiva de datos. Esta última
plataforma de analítica considera, incluso, la posibilidad de análisis de flujos de datos
en tiempo real.
Para demostrar el funcionamiento global del sistema extremo a extremo se ha
integrado en la infraestructura propuesta un sensor de temperatura y humedad DHT11
y se han desarrollado programas de visualización de los valores actuales de los
75
sensores, evolución en tiempo real y un ejemplo de analítica sobre datos históricos
utilizando la plataforma Apache Spark.
Los resultados del proyecto demuestran el funcionamiento extremo a extremo
de la plataforma propuesta utilizando soluciones de última generación que cubren un
rango muy amplio de tecnologías. Superados en importante reto que ha supuesto la
puesta en marcha de la infraestructura, su configuración y el desarrollo de módulos
para integrar las distintas áreas, se demuestra el correcto funcionamiento del conjunto,
su potencial para escalar y la facilidad para incorporar nuevos sensores/actuadores,
así como funciones de analítica sobre datos registrados.
5.2 Discusión
Lo primero que llama la atención tras fase de análisis de un trabajo de este tipo
es que todas las soluciones de las tecnologías de la información que se enfrentan a
los nuevos escenarios de Internet de las Cosas son muy recientes. La tecnología
existente previamente no permite abordar los problemas técnicos derivados de la
gestión de la escalabilidad que se presentan en estos escenarios.
Un segundo aspecto que ha sorprendido durante el diseño y construcción del
demostrador es la velocidad en la evolución de las tecnologías relevantes. La
explotación de estas, por parte de la industria de Internet, contribuye a identificar las
limitaciones existentes, abriendo paso a nuevas soluciones a una velocidad sin
precedente. Son muchos los ejemplos durante el desarrollo que podemos utilizar para
documentar lo anterior y que en algunos casos han supuesto retos adicionales a los ya
existentes en el trabajo.
En el campo del Cloud Computing, el tamaño, y como consecuencia la
necesidad de recursos de las máquinas virtuales, está llevando a un despegue muy
rápido de soluciones alternativas más eficientes basadas en contenedores Linux (35).
El rápido despegue de estas soluciones más eficientes está avalado por el hecho de
que en el uso de infraestructuras Cloud la facturación es por recursos consumidos. El
ejemplo más representativo de las tecnologías basadas en contenedores Linux es
Docker (35). Docker utiliza recursos del sistema operativo host, no siendo necesaria la
virtualización utilizada hasta el momento. La infraestructura Cloud OpenNebula está
actualmente evolucionando a gestionar ambas soluciones; máquinas virtuales y
contenedores Docker.
Por encima de los contenedores comienza a aparecer la necesidad de
orquestarlos y emergen recientemente proyectos como Kubernetes (37), liderado por
Google. En capas más bajas, a nivel de sistema operativo, la experiencia en
plataformas distribuidas, como la propuesta, está ayudando a identificar patrones que
76
se repiten en muchas soluciones Cloud Computing/Big Data. Estos se están
trasladando al sistema operativo en proyectos como Apache Mesos (36) .
Analizando la evolución actual, parece claro que las necesidades de las
infraestructuras Cloud está ayudando definir muy rápidamente los requisitos de un
nuevo concepto de sistema operativo. Un sistema operativo dinámicamente extensible
que permita adaptarse a situaciones variables de carga utilizando toda la
infraestructura hardware que se ponga a su alcance e incluso delegando sobre otros
disponibles y geográficamente dispersos.
El campo de analítica de datos no escapa a esta rápida evolución. El Trabajo
Fin de Grado comenzó considerando Apache Hadoop, estándar de facto hasta el
momento para analítica masiva, y ha finalizado con Apache Spark, que mejora el
anterior en muchos aspectos, tal como se describe en el documento.
La rápida evolución actual deriva en problemas de compatibilidad entre
distintas versiones de las plataformas seleccionadas. Durante el desarrollo del trabajo
se ha tenido que construir desde el código fuente algunas de ellas para reproducir
versiones previas y poder integrarlas satisfactoriamente.
Por otra parte, si bien se ha demostrado el correcto funcionamiento de la
solución extremo a extremo, la estabilidad de las plataformas es una incógnita ya que
su evaluación requeriría un funcionamiento de tiempo muy elevado y en condiciones
de carga alta.
Un aspecto importante a destacar es la amplitud tecnológica del campo del
proyecto. Algunas de las áreas cubiertas podrían constituir la base de nuevos
proyectos por sí solas. El trabajo ha estado centrado en la demostración de una
propuesta para satisfacer las necesidades globales de este tipo de problemas
demostrando el correcto funcionamiento en un escenario limitado. Sin embargo, el
diseño ha considerado que el número de servidores y dispositivos podría ser muy
elevado en un escenario de despliegue real.
En el campo del hardware; pasarelas, sensores y actuadores no es ajeno a la
rápida evolución. Nuevos competidores de Raspberry han aparecido durante el
proyecto así como versiones a precios drásticamente más bajos. La Raspberry Pi
Zero, anunciada a finales de 2015 cuesta sólo 5 dólares, siendo un 40% más rápida
que la primera Raspberry Pi. En paralelo se están desarrollando nuevas tecnologías
de bajo consumo por el gran interés de sensores y actuadores sin cables y con alto
nivel de autonomía.
Todo lo anterior avala el gran interés y la oportunidad del proyecto que ha
permitido demostrar la existencia de soluciones actuales para cubrir escenarios de
77
Internet de las Cosas, si bien son muchas las áreas a seguir para mantener los
desarrollos alineados con el estado del arte.
78
6 CONCLUSIONES
Las conclusiones del Trabajo Fin de Grado pueden plantearse desde distintas
perspectivas; como extensión a la formación académica, en el marco del objetivo del
trabajo y como base a posibles mejoras y ampliaciones.
Sin duda alguna, desde el punto de vista académico, el Trabajo Fin de Grado
ha constituido una oportunidad excelente para enlazar con el estado del arte en
tecnologías que actualmente están penetrando en muchos campos, incluso en una
nueva generación de la infraestructura de red. Para la ejecución del trabajo ha sido
necesario complementar la formación académica del Grado en Ingeniería Telemática
con fundamentos teóricos en un abanico amplio de nuevas tecnologías desconocidas
para el autor. Los retos asociados a resolver problemas nuevos han requerido de
evaluaciones y toma de decisiones gestionando riesgos, resultando en una
experiencia muy enriquecedora desde el punto de vista formativo.
En el contexto del trabajo en sí mismo, se han cubierto los objetivos
inicialmente definidos y se han extendido mucho más allá proponiendo una
infraestructura extremo a extremo simulado centros de datos distribuidos.
La descomposición de las capas IaaS, PaaS y SaaS, habituales en Cloud
Computing, en seis subsistemas para llevar a cabo el análisis, diseño y construcción
del demostrador, facilita el desarrollo por división de un problema muy complejo en
otros más elementales; infraestructura de computación, infraestructura de
almacenamiento, interacción con sensores y actuadores, plataforma middleware y
pasarelas, plataforma de analítica y capa de aplicaciones. Por otra parte, esta
descomposición permite soluciones parciales muy desacopladas.
El concepto de “Gateway IoT”, o pasarela, constituye una solución modular y
flexible para integrar las cosas que pueden representarse de manera general en
términos de sensores y actuadores. Un almacenamiento NoSQL con un modelo de
datos basado en tablas orientadas a dispositivo, extensibles y con columnas variables,
se identifica como una solución adecuada por su alta escalabilidad, tolerancia a fallos
y modularidad.
La explotación de escenarios IoT requiere la integración de tecnologías Cloud y
Big Data. La analítica masiva de datos constituye una pieza fundamental para la toma
de decisiones. Separando la infraestructura de tiempo real de la de analítica en
centros de datos independientes se optimiza globalmente el sistema. Durante el
trabajo se ha demostrado la posibilidad y el potencial de las plataformas de analítica
combinadas con nuevas bases de datos orientadas al registro masivo de información,
si bien es cierto que las soluciones actuales evolucionan cada vez más rápido.
79
6.1 Posibles Mejoras
La amplitud de los campos abordados en el trabajo abre un abanico muy
amplio de posibles mejoras o ampliaciones. Algunas han sido introducidas
previamente, otras las relacionaremos brevemente ya que las posibilidades son muy
extensas.
Desde el punto de vista de la tecnología Cloud Computing probablemente el
uso de contenedores Linux como Docker (33), frente a las máquinas virtuales
utilizadas, sería la primera opción a explorar. El papel de las nubes híbridas es
también un área de interés; cómo y a qué proveedor Cloud delegar automáticamente
la necesidad de recursos en picos de carga para evitar la necesidad de diseñar un
sistema para cargas máximas.
La integración de motores de reglas de comportamiento sería otro campo de
expansión. Estas podrían integrase para articular la orquestación de sensores y
actuadores, permitiendo la modificación del comportamiento del sistema sin
programación. El aprendizaje y el papel de la Inteligencia Artificial sobre la capa de
analítica son un paso natural posterior más allá del alcance de este trabajo. De hecho,
las librerías de inteligencia artificial SystemML (34), que evolucionan del conocido
motor de IBM, Watson (35), tiene un alto nivel de compatibilidad con Spark.
En el campo de los dispositivos, existen actualmente desarrollos orientados a
máquinas virtuales Java modulares para dar respuesta a escenarios de Internet de las
Cosas con dispositivos de recursos escasos. Estos podrían estar disponibles a lo largo
de 2016. También nuevas soluciones nativas son relevantes para una integración más
óptima de la infraestructura software en servidores y clientes.
El área de red, para complementar la virtualización de computación y el
almacenamiento, la tecnologías SND (Software Defined Network) (36) y NFV (Network
Function Virtualization) (42) son campos de gran actividad actualmente.
Por otra parte, el trabajo deja intuir que las implicaciones de este tipo de
plataformas van más allá de las tecnológicas. La instrumentalización de todo lo que
nos rodea implica un conocimiento exhaustivo de las acciones de los usuarios y, por
otra parte, actualmente no conocemos los límites de la inteligencia basada
computación. Cómo integrar los requisitos de privacidad y la relación con este tipo de
infraestructuras, sin limitar sus beneficios, son también campos de investigación
relevantes. Iniciativas como la de la IEEE “Smart World y Cybermatics” (38) intentan
profundizar en los nuevos espacios emergentes considerando el Internet de la Cosas
desde una perspectiva más amplia.
80
7 REFERENCIAS BIBLIOGRÁFICAS
1. OECD. OECD Digital Economy Outlook 2015. Paris : OECD Publishing, 2015. pág. 259.
2. Growing Digital an Telco 2.0. STL partners. [En línea]
http://www.telco2research.com/articles/IoT_Impact_On_M2M_New_Endgame.
3. Arduino site. [En línea] https://www.arduino.cc/.
4. Raspberry Pi site. [En línea] https://www.raspberrypi.org/.
5. The 5th International Conference on the Internet of Things (IoT 2015). [En línea]
http://www.iot-conference.org/.
6. Unified Modeling Language™ (UML®) Resource Page. *En línea+ http://www.uml.org/.
7. With IoT mobile networks will never be the same. Marcus Weldon (Bell Labs) perspective. [En
línea] http://technewsrss.com/with-iot-mobile-networks-will-never-be-the-same/.
8. Zhang, Jiawan. Large Scale Data Analytics. [En línea]
9. Scrum Professional Assessments and Training. [En línea] https://www.scrum.org/.
10. JFree home of JFreeChart library. [En línea] http://www.jfree.org/.
11. Normativas e Impresos relacionados con el Trabajo Fin de Grado (TFG). Escuela Politécnica
Superior de Linares. Universidad de Jaen. [En línea]
http://www10.ujaen.es/conocenos/centros/epsl/docencia/trabajofindegrado2.
12. OpenNebula Cloud Management Software. [En línea] http://opennebula.org/.
13. Apache Cassandra ™. *En línea+ http://cassandra.apache.org/.
14. Neeraj , Nishant. Mastering Apache Cassandra, 2nd Edition. Birmingham : Packt Publishing
Ltd, 2013.
15. Datastax Cassandra service company site. [En línea] http://www.datastax.com/.
16. OSGi™ Alliance. The Dynamic Module System for Java. *En línea+ https://www.osgi.org/.
17. McAffer , Jeff , VanderLei , Paul y Archer , Simon . OSGi and Equinox Creating Highly Modular
Java Systems. Crawfordsville, Indiana : Pearson Education, Inc, 2010.
18. Apache Karaf. [En línea] http://karaf.apache.org/.
19. Nierbeck , Achim , y otros, y otros. Apache Karaf Cookbook. Birmingham : Packt Publishing
Ltd, 2014.
20. Edstrom, Johan y Goodyear, Jamie . Learning Apache Karaf. Birmingham : Packt Publishing
Ltd, 2013.
81
21. DOSGi Single Bundle Distribution. Apache CXF. [En línea] https://cxf.apache.org/dosgi-single-
bundle-distribution.html.
22. Apache CXF. An Open-Source Services Framework. [En línea] https://cxf.apache.org/.
23. Apache Zookeper. Highly reliable distributed coordination server. [En línea]
https://zookeeper.apache.org/.
24. Apache Hadoop. [En línea] https://hadoop.apache.org/.
25. White, Tom . Hadoop: The Definitive Guide. Sebastopol : O’Reilly Media, Inc., 2012.
26. Apache Pig. Hadoop. [En línea] https://pig.apache.org/.
27. MapReduce Tutorial. Hadoop. [En línea]
https://hadoop.apache.org/docs/r1.2.1/mapred_tutorial.html.
28. Apache Spark™ fast and general engine for large-scale data processing. [En línea]
http://spark.apache.org/.
29. Karau, Holden , y otros, y otros. Learning Spark Lightning Fast Data Analysis. Sebastopol :
O’Reilly Media, Inc, 2015.
30. Open-source Workflow Manager for Hadoop. [En línea] https://azkaban.github.io/.
31. Apache Oozie Workflow Scheduler for Hadoop. [En línea] http://oozie.apache.org/.
32. Hadoop in Secure Mode. [En línea] https://hadoop.apache.org/docs/current/hadoop-project-
dist/hadoop-common/SecureMode.html.
33. Apache Sentry role based authorization for Hadoop. [En línea] http://sentry.apache.org/.
34. Using V Models for Testing. [En línea] https://insights.sei.cmu.edu/sei_blog/2013/11/using-v-
models-for-testing.htmlhttps://insights.sei.cmu.edu/sei_blog/2013/11/using-v-models-for-
testing.html.
35. Infrastructure for container projects. [En línea] https://linuxcontainers.org/.
36. Docker. An open platform for distributed applications for developers and sysadmins. [En línea]
https://www.docker.com/.
37. Kubernetes site. [En línea] http://kubernetes.io/.
38. Apache Mesos. [En línea] http://mesos.apache.org/.
39. Apache SystemML distributed and declarative machine learning platform. [En línea]
http://systemml.apache.org/.
40. Meet Watson the platform for cognitive business. IBM. [En línea]
http://www.ibm.com/smarterplanet/us/en/ibmwatson/.
82
41. Software-Defined Networking (SDN) Definition. [En línea]
https://www.opennetworking.org/sdn-resources/sdn-definition.
42. European Telecommunications Standards Institute (ETSI) NFV Portal. [En línea]
https://portal.etsi.org/tb.aspx?tbid=789&SubTB=789,795,796,801,800,798,799,797,802.
43. IEEE Smart World y Cybermatics. [En línea] http://www.cybermatics.org/.
