104390 by UNIGIS América Latina

Master Thesis ǀ Tesis de Maestría submitted within the UNIGIS MSc programme presentada para el Programa UNIGIS MSc at/en

Interfaculty Department of Geoinformatics- Z_GIS Departamento de Geomática – Z_GIS University of Salzburg ǀ Universidad de Salzburg

Método para la Integración de IoT y Cloud en el desarrollo de aplicaciones SIG Ejemplo de recolección de datos por sensores

Method for the Integration of IoT and Cloud in GIS applications development Example of data collection by sensors by/por

Daniel Alberto Rodríguez López 01524648

A thesis submitted in partial fulfilment of the requirements of the degree of Master of Science (Geographical Information Science & Systems) – MSc (GIS)

Cuenca - Ecuador, 21 de junio del 2017

Compromiso de Ciencia Por medio del presente documento, incluyendo mi firma personal certifico y aseguro que mi tesis es completamente el resultado de mi propio trabajo. He citado todas las fuentes que he usado en mi tesis y en todos los casos he indicado su origen.

Cuenca-Ecuador, 21 junio del 2018

Daniel Alberto RodrĂguez LĂłpez

Agradecimientos Expreso un gran agradecimiento a Miguel Ángel Zúñiga, director del departamento de Ciencias de la Computación de la Universidad de Cuenca por su aporte en cuanto conocimientos, mismos que sentaron las bases teóricas para el desarrollo de este tema de tesis. De igual manera, expreso mi agradecimiento a Anton Eitzinger por su dirección en todas las etapas del desarrollo de esta tesis, y a los maestros de UNIGIS por aportar los conocimientos necesarios, que han hecho posible la conclusión exitosa de esta tesis. Por último, quiero agradecer de manera especial a mi esposa, ya que, gracias a su paciencia y constante apoyo he podido culminar el presente trabajo de tesis.

Resumen La era de los equipos de escritorio va quedando atrás, mientras que un nuevo paradigma llamado Internet de las Cosas (Internet of Things – IoT) va emergiendo rápidamente. El paradigma IoT brinda a los objetos la capacidad de ser gestionados mediante una conexión a Internet. En el mundo de los Sistemas de Información Geográfica (SIG), dichos objetos pueden ser sensores con la capacidad de automatizar el proceso de recolección y envío de información de forma masiva, para obtener así capacidades como ahorro de tiempo y recursos, eliminación de errores humanos, mejoras en rendimiento, entre otros. Por otro lado, la tendencia por el uso de plataformas cloud (p. ej., Google, Azure, Openstack, Amazon EC2, HP, etc.), ha crecido enormemente, las cuales ofertan infraestructura tecnológica en forma de servicios que pueden ser consumidos vía Internet (p. ej., almacenamiento virtual, computador virtual, etc.). El uso de plataformas cloud puede proporcionar al dominio SIG ventajas como: elasticidad, escalabilidad, reducción de costos de implementación, pago por uso, facilidad de aprovisionamiento de recursos bajo demanda, reducción de costos de infraestructura tecnológica y mantenimiento de la misma, además de una alta capacidad de procesamiento y almacenamiento, que es la característica más demandada por los desarrolladores SIG. La heterogeneidad de dispositivos IoT y mecanismos mediante los cuales los proveedores de plataformas cloud brindan el servicio al cliente, ha dificultado enormemente la integración entre estas dos tecnologías. Las arquitecturas, herramientas y métodos actualmente propuestos para su integración han sido desarrollados de forma genérica para servicios web y plataformas cloud, pero no han sido específicamente concebidos para el desarrollo de aplicaciones SIG. En esta tesis se propuso la integración de las tecnologías anteriormente mencionadas mediante la definición y descripción de un método que guía el desarrollo de aplicaciones SIG haciendo uso de un estilo arquitectónico que permite diseñar una arquitectura flexible. Dicha arquitectura implementó estándares de transmisión de datos geográficos en ambientes web propuestos en la actualidad. Se desarrolló un ejemplo de verificación que permitió validar el método propuesto. El ejemplo de verificación incluyó el uso de un sensor bajo el paradigma IoT como componente de recolección de datos espaciales de forma automática, y el uso de plataformas cloud como infraestructura tecnológica para el despliegue de una aplicación SIG de análisis espacial que hizo posible la implementación de un proceso de interpolación sobre los datos recolectados. Mediante el ejemplo de verificación fue posible la recolección, de forma automatizada, de 80 mediciones de niveles de CO y CO2 en posiciones geográficas diferentes sobre la zona industrial de la ciudad de Cuenca - Ecuador. Estas mediciones han servido de puntos de muestra para la ejecución de un proceso de interpolación IDW. Como resultado final, se ha generado una superficie de predicción del área de estudio. Esta superficie permite el cálculo de niveles de CO y CO2 en otras posiciones geográficas sobre las cuales no se ha realizado ninguna medición. Al examinar la superficie es posible observar la presencia de fábricas que contribuyen al aumento de la contaminación en el área de estudio.

Palabras clave: IoT, Cloud, Sensores, Recolección de datos.

Abstract The era of traditional desktop computer applications is lagging behind, while a new paradigm called the Internet of Things (IoT) is rapidly emerging. The IoT paradigm gives objects or things the ability to be controlled via an internet connection. In the world of Geographic Information Systems (GIS), these objects can act as sensors with the ability to automate the process of collecting and massively sending geo-referenced information. The use of IoT leads to: real-time access to information, efficient use of resources, elimination of human errors, improvements of performance, and among others. Further, the trend towards the use of cloud platforms (e.g. Google, Azure, OpenStack, Amazon EC2, HP, etc.) has grown substantially, providing a technological infrastructure of services that are consumed via Internet (p. ex. virtual storage, virtual computing, etc.). The use of cloud platforms provides advantages to the GIS domain such as elasticity, scalability, reduction of implementation costs, payment per use, provision of resources on demand, reduction of technological infrastructure and maintenance costs, high processing and storage capacity, which are some of the most demanded features by GIS developers. The heterogeneity of IoT devices and cloud customer service mechanisms, has made integration between these two technologies very difficult. The current architectures, tools and methods have developed generic methods for web services and cloud platforms integration. However, they do not approach the specific challenges of GIS applications. For integrating IoT with GIS applications, a technology integration approach was proposed and applied in this thesis for the design of flexible architectures using IoT and GIS in cloud platforms. The architecture was designed using the current data transmission standards for web environments. Validation and verification scenarios were orchestrated to endorse the feasibility of this proposal. As a prototype, a sensor following the IoT paradigm was used as a source of information with a spatial attribute, and the use of cloud platforms provided the technological infrastructure to deploy a spatial analysis of interpolation of the collected data in real-time and map results in an online map-viewer. The prototype validated the method with data automatically collected, as a result of this, 80 measurements of CO and CO2 levels in different geographical locations within the industrial zone of Cuenca - Ecuador were obtained. These measurements are taken as sample points for the execution of an IDW interpolation process. As a final result, a prediction surface of the study area was generated. This surface allows the calculation of CO and CO2 levels in other geographical positions on which no measurement has been made. Thus, the examination of such surface allows concluding on the presence of factories which causes pollution in the study area.

Keywords: IoT, Cloud, Sensors, data collection.

TABLA DE CONTENIDO 1.

Introducción ................................................................................................................. 15 1.1.

Antecedentes ......................................................................................................... 15

1.2.

Objetivos y Preguntas de Investigación ................................................................ 16

1.2.1.

Objetivo general ............................................................................................ 16

1.2.2.

Objetivos específicos ..................................................................................... 16

1.3.

Preguntas de investigación.................................................................................... 17

1.4.

Hipótesis ............................................................................................................... 17

1.5.

Justificación .......................................................................................................... 17

1.6.

Alcance ................................................................................................................. 19

Revisión de literatura ................................................................................................... 21 2.1.

2.1.1.

Arquitectura de una aplicación SIG en la web .............................................. 21

2.1.2.

Servicios Web ................................................................................................ 22

2.1.3.

SOA (Software Oriented Architecture) ......................................................... 23

2.1.4.

Internet de las Cosas (Internet of Things – IoT) ............................................ 25

2.1.5.

Cloud Computing .......................................................................................... 29

2.1.6.

Estándares OGC ............................................................................................ 30

2.1.7.

El lenguaje SPEM 2.0 para definir procesos software .................................. 35

2.1.8.

TOSCA para modelar infraestructuras Cloud ............................................... 38

2.2. 3.

Marco teórico ........................................................................................................ 21

Estado del conocimiento ....................................................................................... 40

Método para la Integración de IoT y Cloud en SIG ..................................................... 43 3.1.

Requerimientos del método .................................................................................. 43

3.1.1.

Soporte en las fases principales del desarrollo de software........................... 43

3.1.2.

Descripción de la Arquitectura de la Aplicación ........................................... 44

3.1.3.

Incorporación de estándares SIG ................................................................... 44

3.1.4.

3.2.

Descripción general del método............................................................................ 45

3.3.

Descripción detallada de las actividades del método ............................................ 46

3.3.1.

Descripción de servicios ................................................................................ 47

3.3.2.

Diseño arquitectónico .................................................................................... 50

3.3.3.

Implementación ............................................................................................. 53

3.3.4.

Diseño de infraestructura ............................................................................... 55

3.3.5.

Despliegue ..................................................................................................... 56

Ejemplo de verificación ............................................................................................... 58 4.1.

Modelado de la topología de infraestructura IoT y Cloud............................. 44

Aplicación del Método para la Integración de IoT y Cloud en SIG ..................... 59

4.1.1.

Descripción de servicios ................................................................................ 59

4.1.2.

Diseño arquitectónico .................................................................................... 61

4.1.3.

Implementación ............................................................................................. 68

4.1.4.

Diseño de infraestructura ............................................................................... 69

4.1.5.

Despliegue ..................................................................................................... 72

Resultados obtenidos .................................................................................................... 77 5.1.

Recolección de datos por sensores........................................................................ 77

5.1.1.

Operación insertObservation ......................................................................... 77

5.1.2.

Operación insertObservation ......................................................................... 78

5.1.3.

Operación getObservation ............................................................................. 80

5.2.

Procesamiento espacial ......................................................................................... 81

5.3.

Visualización de información espacial ................................................................. 81

5.4.

Discusión de resultados ........................................................................................ 84

Conclusiones ................................................................................................................ 85

Referencias ................................................................................................................... 87

ÍNDICE DE FIGURAS Figura 2.1: Arquitectura de una aplicación SIG en la web.................................................. 21 Figura 2.2: Raspberry Pi 3 Modelo B .................................................................................. 26 Figura 2.3: Usuarios finales y campos de aplicación de IoT ............................................... 27 Figura 2.4: Potencial impacto económico de IoT en 2025 .................................................. 28 Figura 2.5: Aplicaciones SWE ............................................................................................ 31 Figura 2.6: Idea básica de proceso en SPEM 2 ................................................................... 36 Figura 2.7: Terminología clave y su correspondencia en contenido del método y la definición de proceso en SPEM v2.0 .................................................................................................... 36 Figura 2.8: Ejemplo de Topología de la Aplicación............................................................ 38 Figura 2.9: Concepto de plantilla y tipo en la topología de la aplicación ........................... 39 Figura 3.1: Visión general del Método para la Integración de IoT y Cloud en SIG ........... 45 Figura 3.2: Tareas de la actividad Descripción de Servicios............................................... 48 Figura 3.3: Tareas de la actividad Diseño Arquitectónico .................................................. 51 Figura 3.4: Subtareas del Diseño de Contratos de Servicios ............................................... 52 Figura 3.5: Tareas de la actividad Implementación ............................................................. 54 Figura 3.6: Tareas de la actividad Diseño de Infraestructura .............................................. 55 Figura 3.7: Tareas de la actividad Despliegue..................................................................... 56 Figura 4.1: Componentes del escenario para el ejemplo de verificación ............................ 58 Figura 4.2: Diagrama de Participantes ................................................................................ 62 Figura 4.3: Diagrama de Contratos de Servicios ................................................................. 62 Figura 4.4: Diagrama de tipos de datos primitivos.............................................................. 63 Figura 4.5: Diagrama de tipos de mensajes ......................................................................... 64 Figura 4.6: Diagrama de Interfaces del módulo de recolección .......................................... 64 Figura 4.7: Diagrama de Interfaces del módulo de geoprocesamiento ............................... 65 Figura 4.8: Diagrama de Interfaces del módulo de visualización ....................................... 65 Figura 4.9: Protocolo de interacción de recolección ........................................................... 66 Figura 4.10: Protocolo de interacción de geoprocesamiento............................................... 66 Figura 4.11: Protocolo de interacción de visualización....................................................... 66 Figura 4.12: Diagrama Arquitectónico del Sistema ............................................................ 67 Figura 4.13: Modelo topológico de infraestructura IoT ...................................................... 72 Figura 4.14: Modelo topológico de infraestructura Cloud .................................................. 72

Figura 4.15: Diagrama de interconexión de pines GPIO con elementos electrónicos ........ 73 Figura 4.16: Aprovisionamiento manual de elementos electrónicos en el dispositivo IoT Raspberry Pi 3 Modelo B .................................................................................................... 74 Figura 4.17: Características de una Máquina Virtual en la plataforma Google Cloud ....... 74 Figura 4.18: Instancias de máquina virtual creadas............................................................. 75 Figura 4.19: Características de una Máquina Virtual CloudSQL en la plataforma Google Cloud ................................................................................................................................... 75 Figura 4.20: Listado de bases de datos como servicio ....................................................... 75 Figura 5.1: Contrato de Servicios de Recolección .............................................................. 77 Figura 5.2: Extracto de interfaz que muestra el sensor ingresado ....................................... 78 Figura 5.3: Protocolo de interacción de la operación insertarObservacion ......................... 78 Figura 5.4: Interfaz de la Aplicación de Administración .................................................... 79 Figura 5.5: Recolección de Mediciones de forma remota por medio de la Aplicación de Administración .................................................................................................................... 79 Figura 5.6: Mediciones de CO obtenidas mediante la operación getObservation............... 80 Figura 5.7: Mediciones de CO2 obtenidas mediante la operación getObservation............. 80 Figura 5.8: Interfaz Cliente de Procesamiento Espacial ...................................................... 81 Figura 5.9: Mediciones de CO realizadas en la Zona industrial de la Ciudad de Cuenca Ecuador ................................................................................................................................ 82 Figura 5.10: Mediciones de CO realizadas en la Zona industrial de la Ciudad de Cuenca Ecuador ................................................................................................................................ 82 Figura 5.11: Resultados del proceso de interpolación IDW sobre los puntos de muestra de CO........................................................................................................................................ 83 Figura 5.12: Resultados del proceso de interpolación IDW sobre los puntos de muestra de CO2...................................................................................................................................... 83

ÍNDICE DE TABLAS Tabla 2.1: Posibles operaciones según el estándar SOS...................................................... 33 Tabla 2.2: Primitivas de modelado de SPEM v2.0 .............................................................. 37 Tabla 4.1: Catálogo de Servicios ......................................................................................... 60 Tabla 4.2: Estándares OGC implementados en tipos de mensajes ...................................... 63 Tabla 4.3: Participantes a ser desarrollados ........................................................................ 68 Tabla 4.4: Requerimientos mínimos de Hardware .............................................................. 70 Tabla 4.5: Requerimientos mínimos de Software ............................................................... 71

ACRร NIMOS API

Application Programming Interface

BLE

Bluetooth Low Energy

DDSM

Desarrollo Dirigido por Modelos

DSL

Domain Specific Language

GML

Geography Markup Language

IDE

Infraestructura de Datos Espaciales

IDW

Inverse Distance Weighted

IoT

Internet of Things

MGI

McKinsey Global Institute

NIST

National Institute of Standards and Technology

OASIS

Organization for the Advancement of Structured Information Standards

OGC

Open Geospatial Consortium

OMG

Object Management Group

O&M

Observations & Measurements

REST

Representational State Transfer

RFID

Radio Frequency Identification

SensorML

Sensor Model Language

SIG

Sistemas de Informaciรณn Geogrรกfica

SLA

Service Level Agreement

SOA

Service Oriented Architecture

SoaML

Service Oriented Architecture Modeling Language

SOAP

Simple Object Access Protocol

SOS

Sensor Observation Service

SPEM

Software & Systems Process Engineering Metamodel Specification

SPS

Sensor Planning Service

SWE

Sensor Web Enablement

TOSCA

Topology and Orchestration Specification for Cloud Applications

URI

Unique Resource Identifier

URL

Uniform Resource Locators

VPN

Virtual Private Network

WFS

Web Feature Service

WMS

Web Map Service

WPS

Web Processing Service

WSDL

Web Services Description Language

XML

Extensible Markup Language

GLOSARIO •

Aplicación SIG: Software que se basa en la implementación de operaciones sobre información espacial en base a requerimientos funcionales (p. ej., recolección, geoportales, geonavegación, geomarketing, entre otras).

•

API (Application Programming Interface): Biblioteca que ofrece un conjunto de métodos o funciones previamente desarrolladas para ser utilizadas por otro software.

•

Cloud Computing: “Un modelo que permite el acceso ubicuo, adaptado y bajo demanda a través de una red a un conjunto compartido de recursos de computación configurables (p. ej., redes, servidores, almacenamiento, aplicaciones y servicios) que pueden ser aprovisionados o liberados rápidamente, con un mínimo esfuerzo de gestión o interacción por parte del proveedor del servicio” (Mell y Grance, 2011, p. 6).

•

DSL: Lenguaje Específico de Dominio, es cualquier lenguaje que esté especializado en modelar o resolver un conjunto específico de problemas.

•

Infraestructura de Datos Espaciales (IDE): Infraestructura que permite centralizar el acceso a diferentes fuentes de datos espaciales por medio de la publicación de servicios web que implementan estándares de intercambio de información espacial.

•

Middleware: Software que permite a una aplicación comunicarse e interactuar con otra aplicación a través de una red o dentro de un mismo Sistema Operativo.

•

Plugin: Componente de software que provee funcionalidades adicionales a otro software.

•

Script: Archivo de texto plano con instrucciones que son ejecutadas por un software capaz interpretarlas.

•

SLA: Un Acuerdo a Nivel de Servicio define contrato entre el cliente y el proveedor del servicio. Dentro del SLA se establecen indicadores que puedan ser medidos para regular el servicio y así asegurar el cumplimiento de las expectativas del cliente. Estos indicadores pueden ser disponibilidad, responsabilidades, garantías, requerimientos funcionales y no funcionales, entre otros.

1. INTRODUCCIÓN 1.1. Antecedentes En varios de los casos, los procesos de recolección de datos e ingreso de los mismos a una base de datos son realizados de forma manual, lo cual trae problemas en cuanto a la fiabilidad de los datos, además de que implica requerimientos excesivos de personal, tiempo y dinero. La automatización de este proceso puede eliminar en gran medida los problemas mencionados, mejorando así enormemente el rendimiento de esta tarea. Gracias a los avances tecnológicos, existen varias formas de automatizar la recolección de información espacial mediante el uso de sensores electrónicos. En algunos casos se ha dado una automatización parcial debido a que la información recolectada requiere de un intermediario, comúnmente humano, para el ingreso de datos en bases de datos espaciales. Gracias al paradigma IoT, se obtiene la capacidad de comunicar directamente los sensores con servicios web de ingreso de datos mediante Internet, y usando métodos, protocolos y estándares (Sheth, Henson, y Park, 2008), propiciando así un mayor grado de automatización. Además, existe la posibilidad de integrar una gran cantidad de sensores que ya se rigen al paradigma IoT, poniendo a disposición de las empresas una enorme red de sensores que alimentarían las base de datos con información de vital importancia para la toma de decisiones (McKinsey Global Institute, 2015). Por otro lado, las aplicaciones SIG de análisis espacial tienen una gran demanda en cuanto a capacidades de procesamiento y almacenamiento (Liu, 2013). Por esta razón, la infraestructura tecnológica necesaria para el despliegue de aplicaciones SIG tiene altos costos en cuanto a infraestructura tecnológica para su despliegue, personal para la administración de hardware y software, mantenimiento de equipos, actualizaciones constantes, licenciamiento, etc. En los últimos años, la tendencia por el uso de plataformas cloud ha ido creciendo enormemente debido a que pone a disposición del consumidor una infraestructura tecnológica sumamente potente. El usuario ya no debe preocuparse de administrar directamente el hardware y software, sino que únicamente debe consumir servicios publicados en la web (Bhat y Ahmad, 2011). Los ambientes cloud, además de ahorrar costos de administración, mantenimiento e implementación, brindan una manera de fácil acceso a

una infraestructura tecnológica con altas capacidades en cuanto a procesamiento y almacenamiento, que es una característica indispensable al momento del despliegue de aplicaciones SIG de análisis espacial (Jinnan y Sheng, 2010). La posibilidad de integrar las tecnologías anteriormente mencionadas trae una alta gama de aplicaciones posibles en el dominio SIG. Al tener un enfoque genérico, esta integración puede ser aplicada a un sinnúmero de escenarios que requieran la auto-recolección de información espacial de sensores y altas capacidades de infraestructura tecnológica para su posterior procesamiento (Gubbi, Buyya, Marusic y Palaniswami, 2013).

1.2. Objetivos y Preguntas de Investigación 1.2.1. Objetivo general Proponer un método para integrar dispositivos bajo el paradigma IoT con aplicaciones SIG desplegadas en plataformas cloud. 1.2.2. Objetivos específicos •

Proponer un método flexible que implemente protocolos y estándares que permitan la comunicación e integración entre dispositivos bajo el paradigma IoT y servicios web de aplicaciones SIG desplegadas en ambientes cloud.

•

Desarrollar un ejemplo de verificación que permita validar el método propuesto. El ejemplo consta de: auto-recolección de mediciones de CO2 y CO mediante un sensor transportable bajo el paradigma IoT, tomando como área de estudio la zona industrial de la ciudad de Cuenca-Ecuador,

•

Desplegar una aplicación SIG en una plataforma cloud con servicios web que permitan almacenar las mediciones recolectadas por el dispositivo IoT en una base de datos espacial.

•

Ejecutar un proceso de interpolación sobre información espacial seleccionada de la base de datos espacial de mediciones y presentar los resultados en un ambiente web. El servicio encargado de este proceso debe estar desplegado en una plataforma Cloud.

1.3. Preguntas de investigación •

¿Cómo implementar una arquitectura flexible que permita la automatización de procesos de recolección de datos por medio de sensores?

•

¿Cómo automatizar el ingreso de datos recolectado por sensores en una base de datos espacial,

•

¿Cómo integrar el proceso de recolección de datos por sensores con procesos de análisis de información espacial desplegados en una infraestructura con altas capacidades de procesamiento y almacenamiento?

1.4. Hipótesis La integración de tecnologías IoT y Cloud Computing en Sistemas de Información Geográfica mediante la aplicación de protocolos y estándares, permite automatizar procesos de recolección de datos espaciales de sensores y potencia las capacidades de análisis espacial, además de la gestión de infraestructura tecnológica requerida por este tipo de sistemas.

1.5. Justificación El Instituto Global de Investigación McKinsey (MGI) presenta un estudio con un punto de vista económico sobre el increíble potencial del paradigma IoT (McKinsey Global Institute, 2015). Realiza un análisis acerca de 9 áreas sobre las cuales IoT puede ser aplicado y estima un impacto potencial de $ 3.9 a $11.1 trillones de dólares por año en 2025. También hacen énfasis en que la interoperabilidad entre sistemas IoT es crítica, ya que este tema representa un 40% del potencial de las aplicaciones IoT. En este trabajo se propone la integración entre servicios de recolección de datos y servicios de procesamiento desplegados en ambientes cloud potenciando así el procesamiento de la información recolectada, que es otro tema abordado en el estudio ya mencionado; ya que no toda la información es procesada de una forma correcta, por ejemplo, únicamente un 1% de la información recolectada por 30000 sensores en plataformas petroleras es procesada. Solo en 2011, el número de dispositivos intercomunicados ha superado el número de personas y se espera que para el 2020 este número alcance a 24 millones de dispositivos (Gubbi et al., 2013). Gracias a la gran cantidad de sensores contenidos en estos dispositivos,

es posible la recolección de grandes volúmenes de información aplicables a sectores tales como transporte, industria, educación, vehículos, arquitectura, marketing, entre otros (Ara, Gajkumar Shah y Prabhakar, 2016). En cuanto a tecnologías cloud, en los últimos años la tendencia hacia el uso de este tipo de soluciones tecnológicas ha ido creciendo progresivamente en el dominio de los SIG. Son varias las ventajas que se obtienen con el uso de plataformas cloud, de entre las cuales las más aplicables en el dominio SIG son las siguientes (Bhat y Ahmad, 2011; Liu, 2013): •

Procesamiento y almacenamiento: gran capacidad en cuanto a estas características debido a las enormes infraestructuras tecnológicas que los proveedores cloud ponen a disposición de sus clientes. Además, se tiene la característica de elasticidad, la cual permite la asignación de mayor capacidad de procesamiento o almacenamiento en el momento que la aplicación lo requiera; esto sin necesidad de realizar tareas como reinstalación de software o instalación manual de hardware. Todo es realizado mediante un sistema de administración web.

•

Reducción de costos: el usuario experimenta un cambio total debido a que no es necesario preocuparse de tareas de mantenimiento de hardware o logística para la instalación del mismo, además de que su administración se realiza mediante un servicio desplegado en la web. Esto reduce la cantidad de personal requerido para este tipo de tareas.

•

Pago por uso: Los ambientes cloud se basan en arrendamiento de infraestructura y servicios, por lo que el cobro se realizará de acuerdo al uso. En lapsos de tiempo en los que una aplicación no requiera de grandes capacidades o incluso no sea usada, esto será reflejado en una gran reducción de costos.

En esta tesis se propone un método para la integración de dispositivos bajo el paradigma IoT con servicios desplegados utilizando la infraestructura tecnológica de plataformas cloud. Uno de los problemas de la gran cantidad de sensores que en la actualidad proveen información, es que esta no es procesada de una manera correcta. La posibilidad de integrar estas dos tecnologías trae una alta gama de aplicaciones SIG posibles, ya que las grandes capacidades de los ambientes cloud proveen el entorno adecuado para el procesamiento de la información espacial recolectada por los sensores. Un método que guie a los

desarrolladores en la creación de aplicaciones SIG por medio de la definición de una arquitectura flexible, protocolos y estándares permite llevar a cabo esta integración. Algunos ejemplos de la aplicación de la integración anteriormente propuesta pueden ser: en el campo climatológico, para recolectar información de puntos estratégicamente geo localizados, mismos que podrán ser utilizados como puntos de muestra para procesos de interpolación; en el campo ambiental se puede instalar sensores de polución en vehículos gubernamentales, para así proporcionar a las municipalidades indicadores de calidad de aire; otra aplicación puede la implementación de sensores de ruido ambiental ubicados en sectores estratégicos de un área urbana para identificar los niveles de contaminación sónica. Las posibilidades son bastante amplias, únicamente dependen de la imaginación del desarrollador SIG.

1.6. Alcance La presente tesis contempla la definición de un método de integración de tecnologías IoT y Cloud. Este método, a partir del diseño de una arquitectura flexible, tendrá la capacidad de guiar a los desarrolladores SIG en la creación de una aplicación SIG que implemente dispositivos IoT georeferenciados para tareas tales como la recolección de datos de sensores, además de que brindará soporte a nivel de diseño en el proceso de despliegue de la aplicación SIG sobre la infraestructura provista por una plataforma Cloud. La aplicación SIG debe también tener la capacidad de implementar servicios de procesamiento y visualización de la información espacial recolectada por los dispositivos IoT. El método propuesto deberá adoptar patrones de diseño que permitan su eficiencia y productividad. Ya que el objetivo principal es la integración de tecnologías, deberá proveer los mecanismos para lograrlo. Deben ser adoptados además protocolos y estándares para beneficiar la integración. A continuación, se desarrollará un ejemplo de verificación que permita validar el método propuesto. El ejemplo de verificación deberá permitir la auto-recolección de mediciones de CO2 y CO mediante un dispositivo IoT transportable conectado a un sensor de calidad de aire, tomando como área de estudio la zona industrial de la ciudad de Cuenca-Ecuador. El dispositivo IoT debe poder integrarse a servicios contenidos en una aplicación SIG desplegada en una plataforma Cloud. La aplicación SIG debe poder almacenar la

informaciรณn recolectada en una base de datos espacial, poder ejecutar un proceso de interpolaciรณn espacial sobre datos seleccionados de dicha base de datos espacial y mostrar los resultados en un ambiente web.

2. REVISIÓN DE LITERATURA 2.1. Marco teórico 2.1.1. Arquitectura de una aplicación SIG en la web La necesidad de publicar tanto procesos como información geográfica de forma masiva a provocado que las aplicaciones SIG sean desarrolladas para ambientes web. Desde un punto de vista de arquitectura, las funcionalidades básicas de un sistema de información geográfica son: i) almacenamiento, para lo cual es necesaria una base de datos espacial; ii) análisis, donde se procesan los datos espaciales para convertirlos en información útil para toma de decisiones; y iii) visualización, que presenta la información al usuario final. Estas funcionalidades básicas deben ser provistas a través de servicios web. La Figura 2.1 muestra la arquitectura básica de una aplicación SIG en la web.

Aplicación SIG web

Internet Artefactos de comunicación

Base de datos Geográfica

Usuario

Servidor de mapas y procesos

Figura 2.1: Arquitectura de una aplicación SIG en la web

Los elementos básicos que componen una aplicación SIG en la web son los siguientes: •

Interfaz de Usuario: Brinda al usuario final la capacidad de interactuar con la aplicación SIG.

•

Artefactos de comunicación: Los diferentes componentes de la aplicación se comunican a través del intercambio de mensajes enviados entre servicios web. Es necesario proveer artefactos que permitan el consumo de los métodos publicados dentro de los servicios. Para esta tarea existen herramientas, APIs y plugins proporcionadas por terceros o por el propio desarrollador, que facilitan la creación de aplicaciones SIG (p. ej. Openlayers, Geodjango, ArcGis API para javascript, etc.).

•

Servidores de mapas y procesos: Este componente es el encargado de interactuar con la base de datos espacial, proveyendo métodos de visualización, procesamiento y almacenamiento a través de servicios estandarizados (p. ej. Geoserver, Mapserver, ArcGis for server, 52 north, etc.).

•

Base de datos espacial: Por lo general este componente fusiona tanto datos alfanuméricos como espaciales y puede ser accedido por el servidor de mapas mediante un punto de acceso en Internet o dentro de una red local.

La comunicación entre los distintos componentes de la aplicación debe darse de forma uniforme, para lo cual se han definido estándares de comunicación que dependen de la naturaleza del servicio. Este tipo de estándares son vitales al momento de la definición de las interfaces que posibilitan la integración de servicios. Los estándares propuestos por OGC pueden implementarse de forma adecuada a un escenario donde la aplicación SIG sea desplegada en un ambiente cloud (Evangelidis, Ntouros, Makridis y Papatheodorou, 2014). 2.1.2. Servicios Web Son aplicaciones desplegadas en una red, con la capacidad de ser consumidas por un cliente. Utiliza protocolos y estándares que permiten el intercambiar datos entre aplicaciones. Cada uno de los componentes de software que integran las aplicaciones SIG pueden ser vistos como servicios reusables débilmente acoplados y con funcionalidades distintas, pero con un propósito común (Canto, Pereda y Segurola, 2006). En base a esto se pude definir una Arquitectura Basada en Servicios (Service Oriented Architecture – SOA) para aplicaciones SIG (Naseer, Aldoobi y Alkazemi, 2015). La principal ventaja de los servicios web es su interoperabilidad, ya que mediante sus interfaces es posible comunicar aplicaciones desarrolladas en diferentes lenguajes de programación o plataformas. Para el intercambio de la información se utilizan mensajes basados en texto. Estos mensajes pueden utilizar diferentes protocolos, de entre los cuales,

los más utilizados son SOAP (Simple Object Access Protocol) y REST (Representational State Transfer): •

SOAP: Protocolo estándar para intercambio de datos basado en XML (Extensible Markup Language). Implementa un esquema de descripción de servicios mediante WSDL. Sus principales características son: extensibilidad, neutralidad e independencia.

•

REST: Contiene su propio estilo arquitectónico y tiene la capacidad de ejecutar procesos o transferir información en formatos XML Json. La mayoría de los recursos que proveen los servicios web no se encuentran disponibles de forma física, sino que son desplegados a petición del cliente.

Un servicio web es accedido mediante un Identificador de Recursos Uniforme (Unique Resource Identifier − URI), mismo que brinda un punto de acceso único. Los servicios web son definidos y descritos mediante un catálogo que permite a estos ser descubiertos por otras aplicaciones. Tanto el catálogo de servicios como el servicio propiamente utilizan formatos de intercambio estándar tales como XML o Json. 2.1.3. SOA (Software Oriented Architecture) SOA es un estilo arquitectónico que permite diseñar y desarrollar sistemas informáticos distribuidos. Su principal característica es la posibilidad de integrar sistemas de forma fácil y flexible. Las empresas lo han adoptado para la integración de sistemas anteriormente desarrollados con nuevos sistemas ya adquiridos o en proceso de desarrollo. Sus características de adaptación a los cambios permiten una rápida integración entre los componentes del sistema, mismos que, según el paradigma SOA, son considerados servicios (Zúñiga-Prieto, 2017). Es necesario comprender ciertos conceptos, normas, directrices, principios y patrones de diseño si se quiere adoptar el estilo arquitectónico SOA. El principal concepto de SOA es que la lógica de negocio de la aplicación debe ser separada en servicios débilmente acoplados, es decir con un alto grado de independencia entre ellos. En el ámbito de aplicaciones web, estos servicios son un conjunto de aplicaciones más pequeñas que, mediante la aplicación de protocolos y estándares, permiten el intercambio de información y la ejecución de procesos de negocio definidos por su desarrollador.

Los servicios desplegados bajo el paradigma SOA pueden tener distintos dominios de propiedad. Esto quiere decir que, en muchos de los casos los servicios no pertenecen a la empresa que desarrolla el sistema. En algunos casos se puede consumir servicios publicados y previamente desarrollados por otras empresas, ahorrando así el esfuerzo de desarrollarlos desde cero. Este consumo de servicios se da en la modalidad de arrendamiento en la mayoría de los casos. Existen servicios web publicados de forma estándar que permiten el intercambio de información geográfica. Estos servicios son provistos por Infraestructuras de Datos Espaciales (IDEs). Un estándar muy usado para el intercambio de información espacial en ambientes web y cloud es el propuesto por la empresa Open Geospatial Consortium (OGC) (Evangelidis et al., 2014). 2.1.3.1. SoaML (Software Oriented Architecture Modeling Language) “La especificación SoaML provee un metamodelo y un perfil de UML para la especificación y diseño de servicios dentro de una arquitectura SOA” (OMG, 2012, p. 13). SoaML extiende las capacidades de UML − lenguaje de modelado estándar − para poder modelar arquitecturas SOA de forma fácil. Algunas de las capacidades más importantes que soporta son las siguientes (Zúñiga-Prieto, 2017): •

Identificación de servicios: Especifica los requerimientos de los servicios, además de sus dependencias.

•

Especificación de servicios: Describe las funcionalidades, capacidades, protocolos, reglas de uso y requerimientos para que un cliente los consuma.

•

Políticas de uso: Propuestas por el proveedor

•

Descripción de interfaces: Define como los mensajes serán conformados al momento de la interacción con otros servicios.

•

Secuencia de interacción: Describe en artefactos como Diagramas de Secuencia el flujo de mensajes entre los distintos servicios que conforman la aplicación.

•

Definición de servicios de orquestación: Este tipo de servicios facilitan la comunicación entre los demás servicios.

SoaML implementa el enfoque de Contratos de Servicios, facilitando la interoperabilidad entre servicios. Para el diseño de la arquitectura de una aplicación que será desplegada en un ambiente web, son necesarios 4 elementos principales dentro de SoaML (Zúñiga-Prieto, 2017): •

Services Architecture: Contiene la arquitectura completa de la aplicación que se pretende modelar.

•

Partícipant: Son entidades que pueden actuar como consumidores o proveedores de servicios. Pueden ser personas, empresas o componentes de software.

•

Service Contract: Acuerdo entre los Participantes que define: o Roles que cumplirá cada participante. o Operaciones que serán realizadas. Estas operaciones incluyen la definición de las interfaces de comunicación de servicios, es decir como la información será enviada por medio de mensajes. o Protocolo de interacción que permite modelar el flujo de mensajes que serán intercambiados entre los participantes.

•

Role Binding: Enlaza un participante con el Contrato de Servicios indicando el rol que dicho participante cumplirá.

2.1.4. Internet de las Cosas (Internet of Things – IoT) El paradigma IoT se deriva del enfoque de computación ubicua (Caceres y Friday, 2012) y consiste en que las cosas del entorno que rodea al ser humano puedan ser gestionadas y accedidas mediante una conexión a Internet en cualquier momento y lugar. Estas cosas o también llamados dispositivos IoT (sensores, actuadores, dispositivos móviles, etc.) tienen la capacidad de ser fácilmente integrados en entornos cotidianos tales como vehículos, ambientes de trabajo, hogares, lugares públicos, etc. IoT se deriva del concepto de Computación Ubicua, misma que se basa en que los objetos del entorno adquieran capacidades de cómputo. Por esta razón, los dispositivos IoT tienen capacidades de cómputo, que en muchos de los casos son mínimas y únicamente las suficientes para poder gestionar el hardware del dispositivo a través de una conexión a Internet.

2.1.4.1. Elementos de IoT El término IoT se compone por 2 palabras, las cuales contienen los 2 elementos principales Internet y Cosas. Un tercer elemento es la semántica que contiene el conocimiento necesario para la implementación de IoT (Atzori, Iera y Morabito, 2010). •

Internet: No solo hace referencia al hardware necesario para la conexión a Internet si no a la topología de red entera y al Middleware necesario para comunicarse e interactuar con el dispositivo IoT a través de Internet.

•

Cosas: Hace referencia a objetos que pueden encontrarse en el entorno del ser humano. Estos objetos contienen el hardware necesario para su gestión mediante el elemento Internet. Deben contener además el software necesario para realizar dicha gestión, realizando actividades reprogramadas tales como recolección de datos o acciones definidas en un actuador. Ejemplos de cosas pueden ser: smartphones, sensores, actuadores, RFID (Radio Frequency Identification), equipos preprogramados como Raspberry, Arduino, Microcontroladores PIC, entre otras cosas.

•

Semántica: Hace referencia al conocimiento necesario para la implementación de un dispositivo IoT. Es decir, la forma de como representar, almacenar, interconectar, buscar y organizar la información generada por el dispositivo IoT. Los estándares de intercomunicación, interacción, almacenamiento y procesamiento de información juegan un rol importante en este elemento.

2.1.4.1.1. Raspberry Pi Este es un dispositivo con una alta gama de campos de aplicación, de entre los cuales resalta su uso como dispositivo IoT (Zhao, Jegatheesan y Loon, 2015), ya que reúne todos los elementos mencionados anteriormente. La Figura 2.2 muestra un dispositivo Raspberry Pi. Las Figura 2.2: Raspberry Pi 3 Modelo B

dimensiones de este tipo de dispositivos lo hacen portable,

aunque presenta algunos problemas en cuanto a la alimentación de corriente necesaria para hacerlo funcionar. Su principal característica es la posibilidad de instalar un Sistema Operativo para su gestión, brindando la capacidad de instalar software que permita la ejecución de código de programación desarrollado en lenguajes como Python, Java, php, html, etc. Tiene además capacidades de conectividad WiFi nativa o 3g, radio frecuencia, bluetooth, entre otras.

Otras especificaciones técnicas de Raspberry Pi 3 modelo B: •

Quad Core 1.2GHz Broadcom BCM2837 64bit CPU

•

1GB RAM y Puerto Micro SD para almacenamiento

•

BCM43438 wireless LAN y Bluetooth Low Energy (BLE) integrados

•

40-pin GPIO extendido

•

4 puertos USB 2

•

Micro USB para alimentación que requiere 5 Voltios, 2.5 Amperios

2.1.4.2. Aplicaciones IoT Existe una gama interminable de campos de acción en los cuales el paradigma IoT puede ser aplicado. Basta con la necesidad de gestionar elementos tales como sensores, actuadores o cosas típicas que se pueden encontrar en el entorno a través de una conexión a Internet. La Figura 2.3 muestra algunos de estos campos de acción, pero IoT no se limitan a estos, ya que lleva un enfoque genérico y la única limitación para su aplicación es la imaginación del desarrollador.

Figura 2.3: Usuarios finales y campos de aplicación de IoT Fuente: (Gubbi et al., 2013)

Desde un punto de vista económico, se puede identificar un potencial impresionante en cuanto a las aplicaciones que pueden ser desarrolladas con IoT. El Instituto Global de Investigación McKinsey presenta un estudio realizado para el 2025, en el cual se abordan 9 campos de acción sobre los cuales se realiza un pronóstico de ingresos basado en los porcentajes de adopción que la tecnología IoT ha presentado (ver Figura 2.4). Estiman que para el 2025 los ingresos por aplicaciones IoT pueden ser de $3.9 a $11.1 trillones de dólares por año (McKinsey Global Institute, 2015).

Figura 2.4: Potencial impacto económico de IoT en 2025 Fuente: (McKinsey Global Institute, 2015)

2.1.5. Cloud Computing “Un modelo que permite el acceso ubicuo, adaptado y bajo demanda a través de una red a un conjunto compartido de recursos de computación configurables (p. ej., redes, servidores, almacenamiento, aplicaciones y servicios) que pueden ser aprovisionados o liberados rápidamente, con un mínimo esfuerzo de gestión o interacción por parte del proveedor del servicio” (Mell y Grance, 2011, p. 6). En el campo de aplicación SIG, sirve como infraestructura tecnológica que permite el despliegue de servicios, sean estos de recolección de información, procesamiento, visualización, transaccionales, entre otros. En este modelo de negocio los recursos de infraestructura (hardware, software y servicios) son arrendados, liberando al usuario de muchas de las tareas de mantenimiento. La gestión de los recursos cloud se realiza a través de una conexión a Internet sobre la plataforma que el proveedor cloud pone a disposición del cliente. 2.1.5.1. Modelos de servicio cloud Los diferentes tipos de modelos de servicios cloud pueden ser vistos como capas situadas una sobre otras (Breiter, Spatzier y Behrendt, 2011). En base a este modelo las tareas de aprovisionamiento, despliegue, administración, comunicación y manteniendo serán diferentes, así como las operaciones que el proveedor cloud tendrá que realizar para que estas tareas se cumplan. Existen 3 modelos de servicios cloud: •

Infraestructura como servicio: Es una virtualización de hardware y software que permite al usuario una gestión de los recursos cloud a un más bajo nivel. Existe una alta gama de recursos posibles a aprovisionar en este modelo, tales como servidores virtuales, discos duros, tarjetas de red, redes privadas y públicas, corta fuegos, sistemas operativos, balanceadores de carga, etc.

•

Plataforma como servicio: Provee un entorno de desarrollo que permite la creación, administración, hospedaje y mantenimiento de aplicaciones y servicios. No es necesaria la administración de todos los recursos que son propios de infraestructura, únicamente alguno de ellos como cantidad de memoria, capacidades de procesamiento, etc.

•

Software como servicio: Son completas aplicaciones desplegadas en plataformas cloud, sobre las cuales las tareas de administración, soporte y mantenimiento son

asumidas por el proveedor. El usuario únicamente requiere del acceso a través de una conexión a Internet. 2.1.6. Estándares OGC “OGC es un consorcio internacional de más de 520 empresas, agencias gubernamentales y universidades que participan en un proceso de consenso para desarrollar estándares de interfaz públicamente disponibles. Los estándares OGC soportan soluciones interoperables que "geo-activan" los servicios Web, inalámbricos y basados en la localización, y los sistemas informáticos convencionales. Los estándares capacitan a los desarrolladores de tecnología para que la información espacial y los servicios complejos sean accesibles y útiles con todo tipo de aplicaciones” (OGC, 2017, párr. 1) OGC provee estándares para el intercambio de información espacial a través de la web. Provee estándares para la mayoría de los campos sobre los que una aplicación SIG puede actuar (p. ej. intercambio de datos obtenidos por sensores, ejecución de procesos espaciales, publicación de mapas en ambientes web, etc.). 2.1.6.1. SWE (Sensor Web Enablement) Los estándares SWE fueron desarrollados por la empresa OGC. Permiten a los desarrolladores hacer que todos los tipos de sensores, actuadores y repositorios de datos de sensores sean detectables, accesibles y utilizables a través de la Web (OGC, 2012b). Este estándar mantiene lazos con otros estándares de recolección de datos con sensores tales como IEEE 1451, TML, CAP, WS-N, ASAP. Su objetivo es integrar diversas tecnologías relacionadas con sensores de una forma rápida y práctica. Sensores conectados a Internet (IoT) alrededor del mundo requieren estandarización en cuanto a su información y a las mediciones que estos recolectan. Esta estandarización es un elemento clave para su integración. SWE es capaz de suplir tanto requerimientos básicos como complejos con respecto a información de sensores en ambientes web, tomando como elemento primordial la ubicación geográfica de sensores y mediciones (OGC, 2012a).

Figura 2.5: Aplicaciones SWE Fuente: (OGC, 2012b)

Varios de los estándares propuestos por OGC y SWE en el área de manejo de datos de sensores a través de la web, permiten la integración de tecnologías. En los últimos tiempos han emergido varias tecnologías que requieren la interacción con sensores y actuadores a través de la Web (p. ej. IoT, comunicación máquina a máquina M2M, mapeo Web, Realidad Aumentada, dispositivos móviles, Geomarketing, redes sociales, etc.) (OGC, 2012a). SWE permite un marco de trabajo que aborda varias de las áreas sobre las cuales un sensor puede desempeñarse. Los principales estándares propuestos dentro del marco de trabajo de SWE son: •

Observations & Measurements (O&M): Modelos y estructuras XML para la descripción de observaciones y mediciones.

•

PUCK Protocol Standard: Define protocolos que permite: recuperación de metadatos de sensores estructurados bajo el estándar SensorML, código para manejadores (drivers) de sensores e información técnica acerca del sensor. Estos protocolos permiten la instalación automática de los dispositivos.

•

Sensor Model Language (SensorML): Modelos y estructuras XML para la descripción de datos del sensor, además del proceso interno del mismo y sus procesos de observación

•

Sensor Observation Service (SOS): Describe las interfaces que posibilitan la interacción con el sensor a manera de servicio web, posibilitando el acceso a métodos de obtención de observaciones y descripción de sensores. Este estándar permite la interacción con uno o varios sensores (red de sensores).

•

Sensor Planning Service (SPS): Permite la creación de servicios web que permite definir planes para tareas de recolección automatizadas. Permite determinar la factibilidad de recolectar información de uno o más sensores, y presentar solicitudes de recolección.

•

SWE Common Data Model: Define modelos de bajo nivel para el intercambio de datos entre nodos SWE.

•

SWE Service Model: Define tipos de datos para el intercambio de mensajes entre servicios SWE. Para esto se definen operaciones, parámetros y tipos de respuestas.

2.1.6.1.1. SOS (Sensor Observation Service) SOS proporciona una interfaz estandarizada que define modelos, estructuras XML, tipos de datos, operaciones, estructuras de mensajes web y estructuras de bases de datos que permiten gestionar y recuperar metadatos y observaciones de sistemas de sensores heterogéneos (OGC, Bröring, Stasch y Echterhoff, 2012). Debido a las interfaces y protocolos propuestos en este estándar es posible la interoperabilidad con otros sistemas, no solo de recolección de datos, sino también de procesamiento o visualización de información recolectada por sensores. SOS depende del estándar O&M de SWE para la codificación de los datos de observaciones y mediciones provistos por los sensores. SOS fue diseñado para proveer un acceso web a los datos de los sensores, por esta razón requiere de los modelos y tipos de datos definidos en el estándar O&M. La Tabla 2.1 describe las posibles operaciones según el estándar SOS.

Tabla 2.1: Posibles operaciones según el estándar SOS Fuente: (OGC et al., 2012)

Componente

Operación

Descripción

SOS Core

GetCapabilities

Obtener metadatos de las operaciones disponibles en el servidor SOS.

DescribeSensor

Obtener metadatos acerca de un sensor.

GetObservation

Acceso a las observaciones mediante filtros espaciales, temporales y temáticos.

Enhanced

GetObservationByID Obtener una observación mediante su código de identificación.

Operations Extension

GetFeatureOfInterest

Provee un acceso a las características de interés que el servidor SOS provee.

Transactional

InsertSensor

Registra un sensor.

Extension

DeleteSensor

Elimina sensores y sus elementos asociados.

InsertObservation

Inserta observaciones tomadas por los sensores.

Result

Handling InsertResultTemplate Inserta una plantilla de resultados para las observaciones.

Extension GetResultTemplate

Obtiene plantillas de resultados.

InsertResult

Inserta resultados de las observaciones.

GetResult

Obtiene resultados de observaciones.

2.1.6.2. WPS (Web Processing Service) El estándar WPS permite normar la forma en la cual los servicios de procesamiento espacial son publicados en un ambiente Web, proporcionando una interfaz simple que permita operaciones de descubrimiento y acceso (OGC, 2007). Los procesos espaciales son convertidos en servicios web que permiten, mediante entradas de datos definidas, la ejecución de procesos espaciales y la obtención de una salida con los datos resultantes. Los datos de entrada y salida son proporcionados en diferentes formatos a través de la red. Estos datos pueden ser imágenes como GeoTIFF, formatos de intercambio como GML (Geography Markup Language), datos planos, datos obtenidos de un servidor (WFS, Web

Feature Service), entre otros; todo depende de los requerimientos de información definidos por el desarrollador. En su versión 2.0 ha incorporado soporte tanto para protocolos y arquitecturas SOAP como para REST. Los métodos de descripción permiten entradas y salidas estructuradas. Los procesos pueden ser descritos en distintos niveles de abstracción y dependiendo del lenguaje o las herramientas utilizadas al momento del desarrollo. Además, es posible la ejecución de métodos de forma síncrona y asíncrona (OGC, Mueller y Pross, 2015). El estándar WPS define únicamente 3 operaciones básicas al momento de publicar los servicios, por esta razón no se puede conocer en una primera impresión las operaciones SIG disponibles. Estas 3 operaciones son: •

GetCapabilities: Realiza una petición que proporciona los metadatos (nombres y descripciones generales) de cada uno de los procesos ofrecidos por el servidor WPS.

•

DescribeProcess: Proporciona información detallada sobre los procesos que se pueden ejecutar en la instancia de servicio, incluidas las entradas requeridas, sus formatos permitidos y las salidas que se pueden producir.

•

Execute: Permite a un cliente ejecutar un proceso específico, utilizando los valores de parámetros de entrada proporcionados y devolviendo las salidas producidas.

2.1.6.3. WMS (Web Map Service) Los Servicios Web de Mapas permiten la publicación dinámica de información geográfica almacenada en una base de datos espacial en forma de mapas por medio de una interfaz HTTP. Los mapas son presentados en forma de imágenes de diferentes formatos tales como PNG, GIF, JPG, vectoriales (SVG), entre otros; todo depende de las capacidades del servidor de mapas (OGC y de la Beaujardiere, 2006). El usuario puede interactuar con los mapas ejecutando operaciones de navegación o filtrados. Dichas operaciones pueden ser soportadas por APIs o plugins que permitan al cliente web comunicarse con el servidor de mapas por medio del envío de solicitudes vía URL (Uniform Resource Locators). Las solicitudes, en la mayoría de los casos requieren de parámetros que también deben ser agregados en la URL. Estos parámetros dependerán del tipo de solicitud (p. ej. extensión del mapa en una solicitud GetMap).

Existen 3 tipos de operaciones posibles en el estándar WMS. Estas operaciones son vistas como solicitudes, ya que son enviadas por una URL. Cada una de ellas con parámetros distintos que pueden variar dependiendo del servidor de mapas: •

GetCapabilities: Realiza una petición que retorna, en formato XML, los metadatos del servicio WMS (sistemas de coordenadas soportados, espacios de trabajo, capas, formatos de imágenes soportados, versiones, entre otros).

•

GetMap: Retorna un mapa en un formato específico, según un área de interés determinada y capas seleccionadas. Parámetros adicionales pueden ser especificados, tales como filtros, versión, color de fondo, sistema de coordenadas utilizado para mostrar el mapa, entre otros.

•

GetFeatureInfo: Provee información de las geometrías de capas seleccionadas en un punto específico del espacio según un sistema de coordenadas.

2.1.7. El lenguaje SPEM 2.0 para definir procesos software Software & Systems Process Engineering Metamodel Specification (SPEM2.0) es un estándar propuesto por Object Management Group (OMG), cuyo objetivo es la descripción de procesos de software (OMG, 2008). SPEM permite definir una guía clara de los procesos involucrados en el desarrollo de software, además de los roles involucrados. La principal ventaja de usar SPEM es que tiene la capacidad de acomodarse a un amplio rango de métodos y procesos de desarrollo en diferentes estilos, antecedentes culturales, niveles de formalismo, modelos de ciclo de vida y campos especializados (OMG, 2008). Debido a su naturaleza genérica, puede ser utilizado para la descripción del proceso de desarrollo de aplicaciones SIG. En una visión central de SPEM, se pueden identificar tres elementos principales para representar procesos (Ruiz y Verdugo, 2008): Tarea, Rol y Producto de trabajo como se muestra en la Figura 2.6. Las tareas representan las actividades que se debe realizar, los roles representan al personal involucrado en la tarea (responsabilidades de cada participante sobre las actividades a realizarse) y los productos de trabajo son los resultados que se obtienen en la tarea o también pueden ser entradas que requiere una tarea. Como se puede observar, SPEM a más de describir procesos, permite identificar responsabilidades sobre el personal y los resultados esperados de cada proceso.

Figura 2.6: Idea básica de proceso en SPEM 2 Fuente: (Ruiz y Verdugo, 2008)

Se pueden distinguir 2 grupos de trabajo en SPEM (ver Figura 2.7). En primera instancia se definen conceptos clave como contenido del método. En segunda instancia se reutilizan los contenidos del método como procesos, p. ej. uso de un Modelo Arquitectónico del Sistema como producto de trabajo. En el centro se encuentra la Orientación o Guías que pueden ser utilizadas en ambos grupos, p. ej. estándares OGC.

Figura 2.7: Terminología clave y su correspondencia en contenido del método y la definición de proceso en SPEM v2.0 Fuente: (Zúñiga-Prieto, 2017)

Como se puede observar en la Figura 2.7, SPEM contiene una notación que permite modelar la mayoría de escenarios posibles en procesos de software. La Tabla 2.2 muestra las notaciones primitivas para el modelado.

Tabla 2.2: Primitivas de modelado de SPEM v2.0 Fuente: (Zúñiga-Prieto, 2017)

Icono

Nombre

Descripción

Definición

Conjunto de habilidades, competencias y responsabilidades

de rol

de un individuo o grupo.

Definición de tarea

Describen una unidad de trabajo a ser asignada o manejada. Identifica el trabajo que se lleva a cabo por los roles. Una tarea puede ser desglosada en pasos.

Definición de producto de trabajo

Definen productos usados o producidos por las tareas. Pueden ser: artefactos de naturaleza tangible o artefactos entregables. Pueden asociarse entre ellos con relaciones de agregación, composición o impacto. Clasifican elementos como tareas, roles o productos

Categoría

basándose en criterios establecidos por el ingeniero de procesos. Hay diferentes tipos de categorías: grupos de roles, disciplinas (para tareas) o dominios (para productos). Proveen información adicional relacionada a otros elementos.

Guías

Existen subtipos de guías: activos reusables, guías o plantillas de documentación, entre otros. Representan un rol que lleva a cabo una tarea o actividad de

Uso de rol

un proceso. Hacen referencia a la definición de un rol (Contenido del Método).

Uso

tarea Uso

Representan una tarea en un proceso definido. Hacen referencia a la definición de una tarea (Contenido del Método).

de Representan una entrada o salida de una actividad o tarea.

producto de Hacen referencia a la definición de un producto (Contenido trabajo Actividad

del Método). Representan un conjunto de tareas que se ejecutan dentro de un proceso con sus respectivos roles y productos de trabajo.

Paquete de Representan un paquete que contiene todos los elementos de proceso

un proceso. Describen una parte significativa y consistente del trabajo

Paso

general descrito para una Definición de Tarea. Representa todo el trabajo que se debe hacer para lograr el objetivo de desarrollo de la Definición de Tarea.

2.1.8. TOSCA para modelar infraestructuras Cloud Topology and Orchestration Specification for Cloud Applications (TOSCA) es un Lenguaje específico del Dominio (Domain Specific Language – DSL) propuesto por OASIS (Organization for the Advancement of Structured Information Standards) para la descripción de los componentes de infraestructuras Cloud y la interacción entre ellos, esto se conoce como topología de la aplicación (OASIS, 2015). TOSCA también tiene la capacidad de describir de forma estandarizada los planes de administración de la aplicación a desplegar. Está pensado además para la automatización del proceso de despliegue y administración de aplicaciones en entornos Cloud. La topología de la aplicación proporciona una visión estructural de una aplicación que será, o ya ha sido, desplegada sobre un entorno cloud. En la notación propuesta por TOSCA para la topología de la aplicación, los vértices representan los recursos Cloud, tales como máquina virtual, sistema operativo, artefactos de despliegue (compilado de la aplicación o paquetes de despliegue), entre otros; mientras que las aristas que unen los nodos son relaciones. Tanto un nodo como una relación pueden tener propiedades. La Figura 2.8 muestra un ejemplo de la topología de una aplicación utilizando la notación provista por TOSCA.

Figura 2.8: Ejemplo de Topología de la Aplicación

La notación para la topología de la aplicación utiliza se basa en el concepto de Plantilla y Tipo. La plantilla es la definición del nodo o relación, mientras que el tipo se refiere a la instancia de la plantilla. Este concepto puede resultar confuso si no se tiene conocimientos de esta notación, pero al observar la Figura 2.9 se tendrá un mejor entendimiento. TOSCA usa el concepto de plantilla para definir especificaciones genéricas sobre un componente, mientras que los tipos son usados para crear de forma tangible un componente según la plantilla previamente definida.

Figura 2.9: Concepto de plantilla y tipo en la topología de la aplicación

Existen más conceptos relacionados con TOSCA, pero únicamente los conceptos abordados en cuanto a la topología de la aplicación serán los utilizados en las secciones siguientes de esta tesis.

2.2. Estado del conocimiento Mark Weiser dio lugar al término Ubicomp (Computación Ubicua). Este término implica la integración de la informática en el entorno humano para dar paso a su automatización. En el artículo de Caceres y Friday (2012) se presentan a las tecnologías Cloud e IoT como oportunidades de gran potencial para el crecimiento de la infraestructura Ubicomp. En el dominio SIG, la implementación de tecnologías Cloud aporta una alta gama de características. Liu (2013) menciona algunas características de los SIG en ambientes cloud, entre las más notables: una arquitectura basada en servicios para facilitar su administración; la posibilidad de extender las capacidades de hardware según las necesidades de la aplicación; pago por uso; modelos de despliegue que facilitan la instalación de la infraestructura necesaria para correr aplicaciones. Al ser las plataformas cloud una infraestructura que funciona sobre un ambiente web, son compatible con otras tecnologías que tengan la capacidad de acceso a dicho ambiente, como es el caso de las tecnologías IoT. Gubbi et al. (2013) proponen la integración de plataformas cloud y el paradigma IoT. No solo se propone la recolección de datos mediante sensores, sino que se muestra la posibilidad de implementar actuadores, mismos que se disparan en función de decisiones tomadas por sistemas informáticos. Se propone además una arquitectura que permite la integración de tecnologías, pero tanto esta arquitectura como el caso de estudio propuesto son demasiado generales y no se incursiona demasiado en el dominio SIG. En el documento de Botta, Donato, Persico y Pescapé (2016) se presenta las tecnologías Cloud e IoT como una sola. Muestran las capacidades que pueden ser alcanzadas al darse su integración, además de que se muestran algunos proyectos que podrían lograrse y los campos de aplicación sobre los cuales se podría trabajar. No se realiza un ejemplo de alguna aplicación resultante de la integración de las tecnologías, pero es un excelente punto de partida para conocer el gran poder que se tendría a disposición. Se puede apreciar un mayor acercamiento al dominio SIG al implementar paradigmas IoT en el artículo de Priya, Sivaranjani y Sivakumari (2016). El aporte es amplio, ya que se realiza una clasificación de técnicas de comunicación, tipos de componentes usados y los tipos de SIG sobres los cuales puede ser implementado IoT. Aunque no se realiza ninguna

aplicación ni se mencionan plataformas cloud, permite identificar los componentes necesarios para desarrollar este tema de tesis. FIWARE es una plataforma auspiciada por la Unión Europea. Una de sus principales capacidades es brindar herramientas cloud para el desarrollo de proyectos. López, Pavón, Navarro, Soto y Torres (2016) presentan un sistema para el área de agricultura de precisión, donde realizan la integración de tecnologías IoT y Cloud. Presentan una arquitectura propia fuerte y segura, pero no se presenta un enfoque dirigido al dominio SIG ni tampoco métodos de procesamiento espacial. En los trabajos de Bröring et al. (2011); Sagl, Lippautz y Resch (2011) se ha definido una arquitectura aplicando estándares para la recolección de datos basados en el estándar SOS de OGC. Esto permite la comunicación con otros servicios tales como procesamiento. Este trabajo provee un mayor grado de interacción entre servicios de recolección y procesamiento. Los casos de estudio propuestos, aunque no incluyen puntualmente dispositivos IoT, son un excelente punto de partida para este trabajo de tesis. Existen trabajos que proponen enfoques basados en el estilo arquitectónico Arquitectura Orientada a Servicios (SOA) como es el caso de Chen, Guo y Bao (2016). Propone un enfoque que permite lidiar con problemas de interacción con dispositivos IoT. Este estudio puede ser tomado como punto de partida para la implementación de una arquitectura que permita un mayor grado de integración de servicios. Este trabajo puede ser potenciado con lo presentado en el artículo de Zúñiga-Prieto, Insfran, Abrahao y Cano-Genoves (2016b), que muestran las potencialidades de SoaML para el modelado completo de la aplicación además de la integración de servicios cloud. El libro Ingeniería de Software publicado por Somerville (2015) muestra un proceso genérico que permite a los desarrolladores la integración de servicios Web basándose en el paradigma SOA. Se presenta métodos para el diseño de arquitecturas que pueden acoplarse a cualquier área. No se presenta un acercamiento propiamente al área de los SIG y más puntualmente a servicios de recolección de datos por sensores y procesamiento espacial, pero demuestra tener una lógica lo suficientemente sólida para aplicar sus procesos y métodos en la integración que se pretende abordar en este trabajo de tesis. El método DIARy propuesto por Zúñiga-Prieto et. al. (2016b) muestra un proceso muy bien documentado para la integración incremental de microservicios. Se basa en el paradigma

SOA para la integración y hace uso del Desarrollo Dirigido por Modelos (DDSM) a base de metamodelos basados en SoaML para la definición de la arquitectura del sistema. Este método mantiene una temática de servicios genéricos y no tiene una orientación a dispositivos IoT ni a aplicaciones SIG. Las investigaciones realizadas se centran en detallar los campos de aplicación, además de las capacidades que se puede obtener al integrar las tecnologías anteriormente mencionadas. Varias arquitecturas han sido propuestas, pero no se ha definido exactamente como realizar la comunicación entre sensores y aplicaciones de gestión de la información. Ya que la integración debe darse mediante un ambiente web, la forma en la cual los servicios deben comunicarse debe ser correctamente especificada y regulada mediante una arquitectura desarrollada según procesos y métodos lógicos complementados con estándares de transmisión de datos que permitan la integración entre tecnologías tan distintas como lo son IoT y plataformas Cloud.

3. MÉTODO PARA LA INTEGRACIÓN DE IOT Y CLOUD EN SIG La aproximación inicial al método propuesto en esta tesis, ha sido previamente difundida en el documento de Rodríguez, Rodríguez y Zúñiga (2017). En esta sección se presenta el método completo y con el nivel de detalle suficiente como para definir un proceso flexible de diseño, implementación y despliegue, que permita la integración de dispositivos bajo un paradigma IoT con servicios contenidos en una aplicación SIG que utilice la infraestructura tecnológica provista por plataformas cloud para su despliegue. Los dispositivos IoT tendrán la capacidad de automatizar procesos como recolección y envío de datos georeferenciados, para lo cual los dispositivos utilizados deben tener la capacidad de desplegar servicios web. Este método no está pensado para dispositivos con menores características, que no son capaces de desplegar servicios web (p. ej. PICs, Arduino, PLCs, entre otros). Este método tiene un enfoque de integración de servicios web, por lo que se ha adoptado los protocolos, estándares y prácticas definidas en el estilo arquitectónico SOA (ver sección 2.1.3). Además, es necesaria la incorporación de estándares SIG (p. ej. los propuestos por OGC ver sección 2.1.6), para permitir así la definición de interfaces estándar y reutilizables al momento de modelar la arquitectura de la aplicación.

3.1. Requerimientos del método Como producto de trabajo inicial y como entrada de la primera actividad del proceso, se debe proporcionar una Especificación de Requerimientos del Sistema. Este producto de trabajo deberá contener detalles funcionales del sistema. A partir de este requerimiento principal, el método debe cumplir los siguientes requerimientos: 3.1.1. Soporte en las fases principales del desarrollo de software Ya que el método propuesto se basa en una Arquitectura Orientada a Servicios (SOA), debe brindar soporte para las etapas principales de la Ingeniería de Servicios (Somerville, 2015): i) identificación de servicios, definiendo los servicios involucrados en la aplicación y sus requerimientos funcionales; ii) diseño de servicios, donde se definen las interfaces de cada servicio y la forma en la cual se comunican con otros servicios por medio de mensajes utilizando protocolos SOAP o Rest (ver sección 2.1.2); iii) implementación y despliegue, donde la aplicación es desarrollada y desplegada utilizando plataformas Cloud y dispositivos IoT.

3.1.2. Descripción de la Arquitectura de la Aplicación La aplicación consta de elementos arquitectónicos (p. ej. servicios web, interfaces, mensajes, etc.), mismos que deben poder ser modelados como unidades independientes. El éxito de la integración de tecnologías radica en que los elementos arquitectónicos tengan el mayor nivel de independencia y puedan interactuar entre sí sin depender de otros elementos. La arquitectura de la aplicación debe describir servicios que requieran tanto de plataformas cloud, como servicios que requieran de dispositivos IoT para su despliegue. La descripción de la arquitectura debe especificar, a un alto nivel de abstracción, la relación e interacción entre los diferentes servicios independientemente de la tecnología que estos requieran para su implementación y despliegue. 3.1.3. Incorporación de estándares SIG Existen varios estándares SIG que rigen el desarrollo de las interfaces de los servicios web dependiendo de su funcionalidad (p. ej. recolección de datos de sensores georeferenciados, geoprocesamiento, visualización de información espacial, entre otros). El diseño arquitectónico debe promover el uso de estos estándares para salvaguardar la interoperabilidad con otros servicios SIG. La mayoría de aplicaciones SIG consumen servicios publicados por IDEs, mismas que ponen a disposición de los clientes SIG grandes cantidades de información y procesos espaciales, todo esto por medio de servicios web. Las IDEs hacen uso de estándares SIG que rigen la forma en la cual los servicios deben ser consumidos. Por esta razón, el método propuesto debe poder implementar los estándares necesarios para que la aplicación SIG pueda hacer uso de dichos servicios. 3.1.4. Modelado de la topología de infraestructura IoT y Cloud Si bien los servicios Web de las aplicaciones SIG serán desplegados en plataformas cloud, las capacidades actuales de algunos dispositivos IoT permiten hospedar servicios Web que incrementan su funcionalidad, por lo tanto el método debería permitir la descripción de dos tipos de topologías: i) Topología de infraestructura IoT, la cual describirá los componentes de hardware y sus conexiones (p. ej., dispositivos IoT, medios de comunicación, sensores, etc.) así como el software a ser desplegado en dichos componentes; ii) Topología de

infraestructura cloud, la que deberá describir la disposición de todos los recursos cloud. Los recursos cloud son los elementos de hardware y software virtuales ofrecidos por proveedores cloud sobre los cuales se desplegarán los servicios de la aplicación SIG, o dichos servicios utilizarán para satisfacer sus requerimientos.

3.2. Descripción general del método La Figura 3.1 muestra una visión general de las actividades, lineamientos y productos entregables del método. Para la definición del proceso se ha utilizado SPEM 2.0 (ver sección 2.1.7) debido a que permite modelar el flujo de trabajo del método en forma de actividades, además de que permite la especificación de productos de trabajo, estándares y roles.

Figura 3.1: Visión general del Método para la Integración de IoT y Cloud en SIG

La visión general del método muestra las siguientes actividades: •

Descripción de servicios: Esta actividad toma como entrada el producto de trabajo Especificación de Requerimientos para identificar y describir los servicios que intervienen en la aplicación. Como producto de trabajo resultante de esta actividad se debe desarrollar un Catálogo de Servicios que describa a alto nivel las funcionalidades de cada servicio. Es necesario incluir una categorización de cada servicio en base a dichas funcionalidades. Ya que en algunos de los casos existen servicios que ya han sido desarrollados por terceros, y están disponibles en paquetes de software que únicamente deben ser desplegados o consumidos, es necesario especificar qué servicios provistos por terceros serán implementados en la aplicación SIG.

•

Diseño Arquitectónico: Esta actividad es la más importante, ya que es aquí donde se diseñará la forma en la cual los servicios interactúan. El diseño arquitectónico tiene

como objetivo describir la estructura y comportamiento de la aplicación. La estructura está definida por los servicios que conforman la aplicación, mientras que el comportamiento está definido por las interacciones entre estos servicios. Dentro de esta actividad será aplicado el estilo arquitectónico SOA y hará uso de estándares SIG para el modelado de las interfaces de los servicios. Toma como producto de trabajo de entrada el Catálogo de Servicios y el producto de trabajo resultante será un Modelo Arquitectónico del Sistema. Se sugiere el uso del lenguaje SoaML como herramienta para el modelado. •

Implementación: En base al Modelo Arquitectónico del Sistema, los servicios que componen la aplicación son desarrollados en esta actividad. No todos los servicios serán desarrollados, ya que en algunos casos se utilizarán paquetes de software provistos por terceros o se consumirán servicios ya publicados. El resultado de esta actividad son los Artefactos de Despliegue necesarios para desplegar la aplicación. Dichos artefactos pueden ser código de programación compilado, paquetes de software, instaladores, entre otros.

•

Diseño de infraestructura: Como entrada de esta actividad se tomarán los Artefactos de Despliegue desarrollados y provistos por terceros. En base a estos artefactos se definirán los requerimientos de hardware y software necesarios para que la aplicación pueda ser ejecutada. Como productos de trabajo de esta actividad se desarrollará un Modelo Topológico de la Infraestructura tanto para entornos cloud como para dispositivos IoT. Se sugiere el uso de la notación propuesta por TOSCA para el modelado.

•

Despliegue: Esta actividad inicia con el aprovisionamiento de la infraestructura necesaria para que la aplicación pueda ser desplegada. A continuación, se despliegan los artefactos desarrollados en la actividad Implementación y los artefactos provistos por terceros. Esta actividad, de manera opcional, puede ser automatizada mediante el desarrollo de Scripts de Aprovisionamiento y Despliegue. Existen herramientas que permiten dicha automatización, pero no es obligatoria su utilización en este método.

3.3. Descripción detallada de las actividades del método A continuación, se examinarán a mayor detalle las actividades propuestas en el método para la Integración de IoT y Cloud en SIG. Se explotará el diagrama SPEM de la Figura 3.1 de

tal manera que se puedan detallar las tareas involucradas en cada actividad, los roles que cumplirá cada uno de los participantes, productos de trabajo generados y estándares involucrados. Como mínimo deben existir 3 tipos de participantes (roles) involucrados en las actividades del método: •

Arquitecto de Software: Es el encargado de diseñar la arquitectura del sistema. Debe tener los conocimientos suficientes para implementar el estilo arquitectónico SOA. Tomará las decisiones necesarias para diseñar las interfaces de los servicios de tal manera que puedan ser integradas de forma efectiva. Estará también involucrado en el diseño de la topología de la infraestructura.

•

Desarrollador: Personal con conocimientos de programación capaces de crear la aplicación SIG en base a un Modelo Arquitectónico del Sistema.

•

Especialista en Operaciones: Este tipo de personal es el encargado de aprovisionar la infraestructura necesaria para el despliegue de los servicios que componen la aplicación, ya sea en plataformas cloud o en dispositivos IoT. En el caso de los dispositivos IoT, debe tener los suficientes conocimientos de electrónica para conectar los componentes que el dispositivo requiera para lograr sus objetivos funcionales.

3.3.1. Descripción de servicios En esta actividad únicamente se involucra el Arquitecto de Software. Como entrada para esta actividad, se toma el producto de trabajo la Especificación de Requerimientos de la Aplicación SIG. Este producto de trabajo debe tener el nivel de detalle suficiente para que el Arquitecto de Software pueda contemplar todos los objetivos funcionales de la aplicación SIG en tareas de diseño. Este método no brinda soporte para el desarrollo de este producto de trabajo, únicamente describe los servicios a un alto nivel de abstracción. La Figura 3.2 muestra las tareas, roles y productos de trabajo involucrados en la actividad de Diseño de servicios.

Figura 3.2: Tareas de la actividad Descripción de Servicios

La primera tarea es identificar los servicios involucrados en la aplicación SIG en base a la Especificación de Requerimientos. Como primer producto de trabajo es necesario generar un Listado de Servicios. De acuerdo a Somerville (2015), los servicios identificados deben tener las siguientes características: •

Independientes: deben poder funcionar por si solos sin depender de otros servicios.

•

Reusables: deben poder ser accedidos en diferentes etapas del flujo de trabajo de la aplicación y ser reutilizados de la misma forma en todos los escenarios.

•

Ajustables: deben operar siempre en la misma forma, para que, al ser accedidos se tenga la certeza del resultado a obtener.

•

Simples: deben tener la menor cantidad de operaciones posibles y contener funcionalidades concretas, pero deben además ser útiles para cumplir los objetivos de la aplicación.

La siguiente tarea es Descripción de Servicios. Esta tarea permite definir un resumen de las funcionalidades que debe cumplir cada servicio. Esta tarea entrega como producto de trabajo una primera versión del Catálogo de Servicios. Ya que en la actividad de Implementación se toma este producto de trabajo como entrada, es necesario que las funcionalidades descritas tengan el suficiente nivel de detalle como para desarrollarlas sin problemas.

Por último, la tarea Categorización de Servicios permite definir una categoría para cada servicio según su naturaleza. Este método propone una categorización que engloba de manera genérica los servicios que pueden estar involucrados en una aplicación SIG integrada con dispositivos IoT. Dependiendo de las necesidades de la aplicación, es posible agregar más categorías. Las categorías planteadas son las siguientes: •

Dispositivos IoT: Servicios ofrecidos por Dispositivos IoT. Este tipo de servicios no solo pueden ser de recolección de datos georeferenciados, sino cualquier otro tipo de funcionalidad que un dispositivo IoT pueda proveer (p. ej. actuadores que disparan acciones en base a eventos como cambio de temperatura.)

•

Servicios SIG: Geoservicios que han sido desarrollados en base a estándares SIG. Los geoservicios pueden tener distintos objetivos; por ejemplo, acceso a datos, geoprocesamiento, exploración de datos, geovisualización, entre otros.

•

Servicios de negocio: Servicios que tienen como objetivo gestionar los demás servicios o implementan funcionalidades de negocio y realizar procesos que no tienen un ámbito espacial.

•

Recursos Cloud: Son servicios provistos por plataformas cloud que son utilizados por la aplicación SIG. Por ejemplo, servicios de bases de datos espaciales desplegadas según el modelo PaaS (ver sección 2.1.5.1).

Existen servicios que ya han sido desarrollados por terceros y pueden ser reutilizados por la aplicación SIG. Este tipo de servicios pueden estar disponibles en la Internet para ser consumidos o sus creadores proveen los artefactos necesarios (archivos compilados, paquetes de software o instaladores) para desplegarlos junto con la aplicación SIG. Es necesario especificar en el Catálogo de Servicios, cuáles servicios serán desarrollados y cuáles serán implementados por medio de servicios de terceros. Al final, el Catálogo de Servicios debe tener al menos los siguientes campos: nombre del servicio, descripción, funcionalidades, categoría de servicio y si es o no provisto por terceros. Es posible añadir metadatos adicionales dependiendo de la Especificación de Requerimientos y otras necesidades específicas de la aplicación.

3.3.2. Diseño arquitectónico Una vez creado el Catálogo de Servicios, en esta actividad se debe diseñar el comportamiento de los servicios y la forma en la cual estos interactúan unos con otros. Esta interacción debe regirse al estilo arquitectónico SOA (ver sección 2.1.3). Se ha elegido SOA debido a que permite la integración y acoplamiento de servicios sin importar el lenguaje de programación sobre el cual estos han sido desarrollados (Somerville, 2015), o la tecnología en la cual estos han sido implementados y desplegados (Chen et al., 2016). En esta actividad interviene únicamente el Arquitecto de Software y tiene la obligación de documentar de manera útil todas las decisiones relacionadas con la arquitectura de la aplicación con el fin de utilizarlas eficientemente. Es generalmente aceptado documentar las arquitecturas de software mediante el uso de múltiples vistas (Hofmeister et al., 2005; Kruchten, 1995); en donde, UML es utilizado para modelar estas vistas. Por otro lado, en el caso de aplicaciones basadas en servicios, el lenguaje SoaML es generalmente utilizado y se sugiere su implementación en esta actividad, ya que extiende las capacidades de modelado de UML y permite el manejo eficiente de sus múltiples vistas. En la sección 2.1.3.1 se detallan los fundamentos teóricos necesarios para el modelado usando SoaML. Para resolver los problemas de interoperabilidad entre servicios, SoaML plantea un enfoque de Contratos de Servicios. Este enfoque propone que los servicios no se comuniquen entre ellos directamente, sino que exista un intermediario llamado Contrato de Servicios que orqueste el flujo de mensajes. Por ejemplo, si un servicio de recolección de datos requiere almacenar información en la base de datos, debe enviar un mensaje con la información necesaria al Contrato de Servicios, y este a su vez se encargará de enviar los mensajes a los destinatarios correspondientes, para así completar el flujo. La mayor ventaja de implementar Contratos de Servicios es que si el formato de los mensajes es alterado en un servicio, únicamente se deben cambiar las interfaces dentro del Contrato de Servicios, mas no en todos los servicios que requieran el consumo del servicio alterado. Además, el Contrato de Servicios tiene la responsabilidad de mantener la compatibilidad con todos los participantes que este orqueste, permitiendo que servicios implementados en diferentes lenguajes de programación y diferentes tecnologías se integren sin problemas. Por esta razón, los Contratos de Servicios son el corazón de la integración entre tecnologías IoT

y cloud propuesta en este método. La Figura 3.3 muestra las tareas que deben ser realizadas en la actividad de Diseño Arquitectónico.

Figura 3.3: Tareas de la actividad Diseño Arquitectónico

En la primera tarea de esta actividad se definen los Participantes. En la mayoría de los casos, cada servicio definido en el Catálogo de Servicios será tomado como participante. Existen excepciones en las que un participante esté compuesto por varios servicios, esto dependerá del criterio del Arquitecto de Software. La siguiente tarea, Diseño de Contratos de Servicios será explicada a mayor detalle en la sección 3.3.2.1 debido a su vital importancia para la integración. En dicha sección se detallarán las subtareas involucradas. Por último, se realizará el Diseño Arquitectónico del Sistema, donde se especifican las relaciones entre los participantes y Contratos de Servicios. Para concluir esta actividad es necesario que las interfaces y los roles diseñados dentro de los Contratos de Servicios se encuentren debidamente definidos. En las Figuras 3.3 y 3.4 se pueden observar los siguientes productos de trabajo: Diagrama de Participantes, Diagrama de Contratos de Servicios, Diagrama de Secuencias y Diagrama Arquitectónico. La combinación de todos estos productos de trabajo da como resultado el Modelo Arquitectónico del Sistema, que es el producto de trabajo resultante de la actividad de Diseño Arquitectónico.

3.3.2.1. Diseño de Contratos de Servicios Los Contratos de Servicios son servicios de orquestación que permiten el flujo de mensajes entre los demás servicios. Por esta razón, internamente deben modelar la estructura de las interfaces de los servicios participantes y el flujo de mensajes que permita su comunicación. Esta definición debe regirse a estándares SIG para fortalecer la interoperabilidad. La Figura 3.4 muestra las subtareas a ser realizadas en la tarea de Diseño de Contratos de servicio.

Figura 3.4: Subtareas del Diseño de Contratos de Servicios

La primera subtarea permite la definición de tipos de datos primitivos. Es necesario contemplar todos los tipos de mensajes que puedan utilizarse en los lenguajes de programación utilizados en la actividad de Implementación. En la segunda subtarea se crean los tipos de mensajes que serán utilizados para definir las interfaces. En la tercera subtarea serán definidas las interfaces utilizando los tipos de mensajes y tipos de datos primitivos previamente definidos. En estas 2 subtareas es vital el uso de estándares SIG, sobre todo al momento de definir las interfaces de los servicios con categoría Servicio SIG. Los estándares SIG proveen información de los mensajes que se espera reciban los diferentes Servicios SIG, por lo tanto, al definir las interfaces, el Arquitecto de Software determina el estándar SIG adecuado para cada servicio que tenga la categoría Servicios SIG, y define las interacciones en base a los mensajes descritos en el estándar. Los estándares SIG más comúnmente usados son los propuestos por OGC (Evangelidis et al., 2014). OGC ha

desarrollado un compendio de estándares que pueden ajustarse a la mayoría de servicios dependiendo de sus objetivos funcionales (ver sección 2.1.6) (p. ej. SWE para recolección de datos por sensores, WPS para la ejecución de procesos espaciales, WMS para la navegación y visualización de información espacial, entre otros). La última subtarea define el protocolo de interacción entre los diferentes servicios, es decir, el flujo con el cual los mensajes serán enviados entre los distintos participantes. Como Producto de trabajo de esta subtarea se tiene un Diagrama de Secuencias, mismo que será utilizado por los desarrolladores en la actividad de Implementación para la creación de los Contratos de Servicios. Los productos de trabajo mostrados en la Figura 3.4 se encuentran dentro del producto de trabajo Diagrama de Contratos de Servicios. Esto se debe a que por cada Contrato de Servicios se deben seguir las subtareas anteriormente mencionadas. 3.3.3. Implementación Los desarrolladores proceden a la creación de los diferentes servicios que componen la aplicación SIG a partir del producto de trabajo Modelo Arquitectónico del Sistema. En esta etapa se hace uso de diferentes tecnologías y lenguajes de programación dependiendo de la tecnología en la cual serán implementados los servicios. Por ejemplo, si la tecnología utilizada será un dispositivo IoT Raspberry Pi, es posible utilizar el lenguaje de programación Python, ya que este permite, por medio de módulos ya desarrollados, la utilización de pines GPIO para la comunicación con sensores electrónicos. Únicamente serán desarrollados los servicios que no consten en el Catálogo de Servicios como provistos por terceros. Es necesario tener en cuenta el diseño de las interfaces que se ha definido en el Modelo Arquitectónico del Sistema, ya que éstas permiten la integración de los servicios desarrollados y los servicios provistos por productos de software de terceros. Por ejemplo, al momento del envío de datos de sensores, los mensajes y sus interfaces deben ser compuestos en base al estándar SOS, que es parte del estándar SWE. Los Contratos de Servicios que implementan las interacciones deben contar con métodos de orquestación basados en los Diagramas de Secuencia generados.

En etapas de negociación del consumo de un servicio se definen Service Level Agreements (Acuerdos a Nivel de Servicio – SLAs) entre el cliente y el proveedor de un servicio para realizar acuerdos que permitan garantizar la calidad del servicio. Es necesario también tener en cuenta los requerimientos definidos en los SLAs, que son productos de trabajo que sirven de entrada para esta actividad, ya que especifican parámetros como disponibilidad, responsabilidades, garantías, requerimientos funcionales y no funcionales, entre otros.

Figura 3.5: Tareas de la actividad Implementación

La Figura 3.5 muestra las tareas a ser realizadas en la actividad de Implementación. La primera tarea es el desarrollo de los servicios contenidos por cada participante. La siguiente tarea es el desarrollo de los Contratos de Servicios. A continuación, es necesario realizar las pruebas necesarias que garanticen que los servicios se comunican correctamente y las funcionalidades definidas en el Catálogo de Servicios se cumplan de manera eficiente. Este método no contempla la definición de pruebas al momento de la implementación, por lo cual, los desarrolladores deben recurrir a métodos que permitan probar el software de manera eficiente. De ser necesario se debe recurrir a personal especializado en la tarea de pruebas. Una vez que se haya completado el desarrollo de la aplicación SIG y se hayan realizado las pruebas necesarias, se procede a generar los Artefactos de Despliegue. Estos artefactos deben permitir la ejecución de la aplicación en la tecnología para la cual fueron creados, ya sea esta cloud o IoT.

3.3.4. Diseño de infraestructura Al momento del Diseño de la Infraestructura tecnológica para el despliegue de la aplicación SIG, se requiere la intervención de todo el personal. Es necesaria una buena comunicación entre Desarrolladores, Arquitectos de Software y Especialista en Operaciones, ya que cada uno realizará tareas que permitan crear un diseño eficiente. En cuanto a la infraestructura, es necesario realizar una diferenciación de 2 categorías: infraestructura IoT e infraestructura cloud. Esto debido a que son tecnologías diferentes, pero que pueden ser descritas con una notación común. Para esta actividad se sugiere la utilización de la notación provista por TOSCA (ver sección 2.1.8) para el modelado de la topología de la aplicación. Esta notación está diseñada para el modelado de infraestructuras cloud (Binz, Breiter, Leyman y Spatzier, 2012), pero ya que permite la definición de recursos de hardware y software, también será utilizada para modelar la infraestructura IoT. La Figura 3.6 muestra las tareas a ser realizadas en la actividad de Diseño de infraestructura.

Figura 3.6: Tareas de la actividad Diseño de Infraestructura

En la primera tarea, en base a los Artefactos de Despliegue resultantes de la actividad de Implementación y a los Artefactos de Despliegue provistos por terceros, es necesario que los Desarrolladores y el Especialista en Operaciones definan los requerimientos en cuanto a la topología de la infraestructura tecnológica de hardware y software, que permitirá el despliegue y ejecución de los servicios. Al hablar de topología se refiere a la forma en la cual los elementos de la infraestructura están conectados e interactúan entre sí.

En la siguiente tarea de modelado estarán involucrados el Arquitecto de Software y el Especialista en Operaciones. Mediante la utilización de la notación provista por TOSCA, se procede a crear los productos de trabajo Modelo Topológico de Infraestructura, tanto para tecnología cloud como para IoT. Es necesario tomar en cuenta todos componentes electrónicos que deben ser conectados a los dispositivos IoT para que permitan cumplir con las funcionalidades previamente definidas. 3.3.5. Despliegue Esta es la última actividad del método. Se divide en 2 tareas principales: aprovisionamiento de la infraestructura y despliegue de artefactos desarrollados (productos de trabajo de la actividad de Implementación) o artefactos provistos por terceros. En esta actividad está involucrado únicamente el Especialista en Operaciones. De ser necesario se requerirá el soporte de los Desarrolladores en esta actividad para comprobar el correcto funcionamiento de la aplicación. La Figura 3.7 muestra las tareas a ser realizadas en la actividad de Despliegue.

Figura 3.7: Tareas de la actividad Despliegue

El aprovisionamiento toma como entrada los Modelos topológicos de infraestructura IoT y cloud. En el caso de IoT es necesario el ensamblaje de los componentes electrónico, a más de los elementos de hardware y softwares relacionados con los dispositivos IoT. En el caso de las plataformas cloud se realiza el aprovisionamiento de recursos virtuales cloud.

Las plataformas cloud son extensamente heterogéneas, por lo que, dependiendo del proveedor seleccionado, la forma en la que los recursos cloud son ofertados será diferente (Yue, Zhou, Gong y Hu, 2013). Esto es algo que se debe tener en mente al momento de seleccionar un proveedor cloud, ya que las actividades de migración pueden resultar costosas. Una vez aprovisionada la infraestructura se procede a desplegar los servicios que componen la aplicación SIG utilizando los artefactos de despliegue desarrollados y los provistos por terceros. Cada servicio debe poder ser accedido mediante puntos de acceso en forma de URL. Es necesario realizar las configuraciones necesarias para que todas las URLs puedan ser accedidas, sobre todo en el caso de los dispositivos IoT. Para lograr esto, se pueden implementar IP pública, dominios, VPN (Virtual Private Network) o cualquier otro mecanismo que permita conectar los servicios cloud con los servicios desplegados en dispositivos IoT. De manera opcional, el Especialista en Operaciones puede crear Scripts de Aprovisionamiento y Despliegue que permitan automatizar esta actividad. Existen herramientas que permiten dicha automatización, pero no es obligatoria su utilización en este método. Hasta este punto, la aplicación SIG ha sido desplegada tanto en ambientes cloud como dispositivos IoT. La última tarea es la realización de pruebas que garanticen el correcto funcionamiento de la aplicación. Si esta es una fase de producción, donde el software va a ser presentado al cliente final, las pruebas deben ser más rigurosas, buscando la coherencia con la especificación de requerimientos inicial y los SLAs definidos para cada servicio.

4. EJEMPLO DE VERIFICACIÓN Para ilustrar el método para la Integración de IoT y Cloud en SIG propuesto en esta tesis se ha definido el siguiente escenario empírico: la municipalidad de la ciudad de CuencaEcuador requiere determinar la calidad de aire en su zona industrial, en base a la medición de niveles de CO y CO2 por medio de sensores geoposicionados; una vez recolectados los datos, estos deben ser almacenados en una base de datos espacial para su posterior geoprocesamiento por medio de un método de interpolación IDW (Inverse Distance Weighted); los resultados de la interpolación deben ser visualizados en un entorno web. La Figura 4.1 muestra de manera gráfica los componentes que deben estar presentes en la arquitectura del sistema.

Figura 4.1: Componentes del escenario para el ejemplo de verificación

En base a los componentes de la Figura 4.1 se han definido 3 módulos. La Especificación de Requerimientos de cada módulo se presenta a continuación: •

Módulo de recolección de datos: Se encarga de realizar la medición de niveles de CO y CO2. Estas mediciones deben realizarse por medio de sensores electrónicos portátiles y georeferenciados basados en el paradigma IoT. Todas las mediciones tomadas serán enviadas a un servicio que permita integrarlas y almacenarlas en una base de datos espacial.

•

Módulo de procesamiento espacial: Este módulo ejecutará un proceso de interpolación de tipo IDW sobre mediciones seleccionadas de la base de datos espacial. La selección de las mediciones se realizará por medio de un filtro parametrizable.

•

Módulo de visualización: Luego de la ejecución del geoprocesamiento es necesario presentar los resultados en un mapa interactivo sobre un ambiente web.

La aplicación SIG resultante debe ser desplegada en la plataforma cloud ofertada por Google. Se ha seleccionado este proveedor cloud debido a que pone a disposición del cliente una base de datos de software libre (motor de base de datos PostgreSQL) como recurso cloud en la modalidad PaaS. Además, en cuanto a costos, brinda un periodo de prueba con el suficiente tiempo para el desarrollo del ejemplo de verificación. En cuanto al dispositivo IoT para la recolección de datos, se requiere utilizar Raspberry Pi Modelo B, debido a que este dispositivo brinda capacidades de conexión a internet, además de que es capaz albergar un sistema operativo, mismo que permite el despliegue de servicios web (Zhao, et. al., 2015). Otra de las razones por las que se ha seleccionado este dispositivo, su amplia comunidad de desarrolladores y su facilidad de programación utilizando el lenguaje de programación Python, mismo que cuenta con módulos que facilitan el procesamiento de información espacial (Dobesova, 2011).

4.1. Aplicación del Método para la Integración de IoT y Cloud en SIG El producto de trabo inicial y necesario para la aplicación del método es la Especificación de Requerimientos de la Aplicación SIG, mismo que ya ha sido detallado. A continuación, se abordan las actividades, tareas y subtareas del método que se han seguido para el desarrollo del ejemplo de verificación planteado: 4.1.1. Descripción de servicios 4.1.1.1. Identificación de Servicios El Arquitecto de Software toma como entrada en esta actividad la Especificación de Requerimientos de la aplicación SIG. En base a este producto de trabajo se ha realizado la tarea de Identificación de Servicios. El listado de los servicios identificados es el siguiente: •

Administración para recolección

•

Cliente de geoprocesamiento

•

Recolección IoT

•

Geoprocesamiento

•

Integración de mediciones

•

Cliente de visualización

•

Base de datos espacial.

•

Visualización

4.1.1.2. Descripción y Categorización de Servicios Las tareas de descripción y categorización de los servicios identificados han dado como resultado el Catálogo de Servicios que se puede observar en la Tabla 4.1: Tabla 4.1: Catálogo de Servicios

Nombre

Administración para recolección

Descripción

Funcionalidades

Servicio encargado

Iniciar el flujo de trabajo de

de la administración

la recolección en tiempo real.

del

Obtener un listado de las

mediciones en base a un

módulo

recolección datos.

Recolección IoT

Servicio

recolección

Servidor de

que

almacenamiento

de mediciones. Base

datos

Servicio

almacenamiento

espacial.

negocio

Tomar mediciones de niveles de CO y CO2.

Dispositivo

Envío de mediciones en

IoT

tiempo real.

permite la recepción y

mediciones

Servicio de

De Terceros

filtro.

mediciones.

Integración

Categoría

Integrar

almacenar

mediciones de niveles de CO y CO2.

Servicio SIG

Base de datos alfanumérica y

Recurso

espacial.

Cloud.

Enviar peticiones para la

Cliente

geoprocesamiento

Servicio que ejecuta métodos

geoprocesamiento.

ejecución de métodos de interpolación IDW.

Servicio de

Definir un filtro para la

negocio

selección de los datos a interpolar.

Geoprocesamiento

Servidor estándar de geoprocesamiento Servicio encargado

Cliente visualización

mostrar

resultados

los de

geoprocesamiento.

Visualización

Servidor estándar de visualización.

Recibir

peticiones

ejecución de un proceso de interpolación IDW. Enviar

peticiones

para

mostrar los resultados del geoprocesamiento. Recibir peticiones para la obtención de resultados del geoprocesamiento.

Servicio SIG

Servicio de negocio

Servicio SIG

La columna “De terceros” especifica si el servicio debe ser desarrollado o se implementarán servicios que ya han sido desarrollados por terceros. 4.1.2. Diseño arquitectónico Esta actividad toma como entrada el Catálogo de Servicios previamente realizado. El resultado es el Modelo Arquitectónico del Sistema, mismo que se ha realizado utilizando el plugin Papyrus del IDE Eclipse, mediante el perfil SoaML, que permite extender las capacidades de UML para realizar modelos basados en SOA. El Modelo Arquitectónico del Sistema consta de los siguientes diagramas: •

Diagrama de Participantes

•

Diagrama de Contratos de Servicios

•

Diagrama de Tipos Primitivos

•

Diagrama de Tipos de Mensajes

•

Diagrama de Interfaces

•

Protocolo de Interacción (uno por cada Contrato de Servicios)

•

Diagrama Arquitectónico del Sistema

Caca diagrama consta de elementos arquitectónicos. Antes de hacer uso de un elemento arquitectónico, este debe ser previamente definido en su diagrama correspondiente. Por ejemplo, en el Diagrama Arquitectónico se hace uso de elementos de tipo Participante, mismos que deben haber sido definidos previamente en el Diagrama de Participantes. En cuanto a la notación utilizada para los nombres de los elementos arquitectónicos del modelo, cuando se realiza la definición de un elemento el nombre inicia con una letra Mayúscula, mientras que cuando se hace uso de esta definición se inicia con una letra minúscula. Por ejemplo, en el Diagrama de Participantes un elemento arquitectónico es definido con el nombre “RecoleccionIoT”, mientras que, en el Diagrama de Arquitectura cuando se hace uso de la definición de este participante, se utiliza el nombre “dispositivoIoT” empezando con minúscula. En este caso el uso de la definición sería dispositivoIoT: RecoleccionIoT. Este concepto es similar al utilizado en la programación orientada a objetos. Por ejemplo, una clase se define con el nombre “Persona”, mientras que el objeto que crea una instancia

de esta clase tiene el nombre “cliente”. En código de programación se define de la siguiente manera: Persona cliente = new Person(). 4.1.2.1. Diseño de Participantes En esta tarea, por cada servicio del Catálogo de Servicio se ha creado un participante, como se muestra en la Figura 4.2:

Figura 4.2: Diagrama de Participantes

4.1.2.2. Diseño de Contratos de Servicios En la Especificación de Requerimientos del Sistema se definieron módulos. Por cada módulo se ha creado un Contrato de Servicios para agrupar los servicios según sus funcionalidades. El diagrama resultante se observa en la Figura 4.3.

Figura 4.3: Diagrama de Contratos de Servicios

Este diagrama utiliza la definición de interfaces realizada en el Diagrama de Interfaces, mismo que a su vez utiliza la definición de tipos primitivos y tipos de mensaje definidos en los diagramas correspondientes. En la construcción de estos mensajes es necesaria la

implementación de estándares SIG que garanticen la interoperabilidad de los servicios. A continuación, se detallan las subtareas donde se desarrollan dichos diagramas: 4.1.2.2.1. Diseño de tipos de datos primitivos Los datos primitivos definidos en esta subtarea dependen de los lenguajes de programación que se pretende utilizar en la actividad de implementación (p. ej. PHP y Python). En este caso se han definido los datos primitivos que se observan en la Figura 4.4.

Figura 4.4: Diagrama de tipos de datos primitivos

Este diagrama contiene la definición de los tipos de datos primitivos. Se puede observar que algunos nombres no empiezan con mayúscula, como se especificó anteriormente. Esto se debe a que se deben usar los mismos nombres definidos en los lenguajes de programación que se pretende utilizar. 4.1.2.2.2. Diseño de Tipos de Mensajes En esta subtarea los mensajes han sido definidos en base a los necesarios para la ejecución de los métodos de las interfaces, algunos según estándares SIG. No todos los tipos de mensajes deben regirse a estándares SIG, ya que los servicios con la categoría Servicios de Negocio implementan funcionalidades que no están normadas por estándares, sino que dependen de las necesidades de la aplicación. Para los tipos de mensajes regidos a un estándar SIG se ha utilizado el prefijo “MsgOGC”. En cuanto a los estándares SIG, se ha utilizado los propuestos por OCG (ver Tabla 4.2). Tabla 4.2: Estándares OGC implementados en tipos de mensajes

Tipo de Mensaje MsgOCGDatosSensor

MsgOCGDatosMedicion

MsgOGCListadoMediciones

Estándar Sensor Web Enablement (SWE) - Sensor Observation Service (SOS) Sensor Web Enablement (SWE) - Sensor Observation Service (SOS) Sensor Web Enablement (SWE) - Sensor Observation Service (SOS)

Método inserSensor

insertObservation

getObservation

MsgOCGGeoprocesamiento

Web Processing Service (WPS)

execute

MsgOCGVisualizacion

Web Map Service (WMS)

getMap y describeLayer

Este diagrama resultante se puede observar en la Figura 4.5.

Figura 4.5: Diagrama de tipos de mensajes

4.1.2.2.3. Diseño de Interfaces Esta subtarea requiere de la definición de tipos de datos primitivos y tipos de mensajes realizada en las subtareas anteriores. Es aquí donde se definen los métodos que se implementarán al momento de la orquestación de mensajes realizada por el Contrato de Servicios. Por esta razón, se han utilizado los estándares SIG que permitan garantizar la interoperabilidad de la aplicación. No todas las interfaces definidas siguen estándares SIG, ya que algunas interfaces serán implementadas sobre servicios de categoría Servicio de Negocio. Se han utilizado los mismos estándares OCG que en la subtarea anterior. El nombre de las interfaces que siguen un estándar SIG inician su nombre con el prefijo “OCG_nombre_estándar”. Las interfaces también se han separado por módulos como se observa en las Figuras 4.6, 4.7 y 4.8

Figura 4.6: Diagrama de Interfaces del módulo de recolección

Figura 4.7: Diagrama de Interfaces del módulo de geoprocesamiento

Figura 4.8: Diagrama de Interfaces del módulo de visualización

En el caso del servicio de base de datos espacial no se han definido interfaces, ya que los servicios SIG se conectan directamente con la base de datos sin ejecutar ningún método. Es necesario resaltar que la operación obtenerObservación de la interfaz RecolecciónIoT (ver Figura 4.6) contiene el parámetro idGas, que permite especificar si el gas que se pretende medir es CO o CO2. 4.1.2.2.4. Diseño de Protocolos de Interacción Ya que los Contratos de Servicios realizarán la orquestación de mensajes entre los diferentes servicios, es necesario definir el orden con el cual estos mensajes serán enviados. Esto se realiza mediante un protocolo de interacción diseñado por un Diagrama de Secuencia. Por cada Contrato de Servicios se ha diseñado un diagrama. Únicamente el Contrato de Servicios de recolección tiene un condicional con varias operaciones a realizar, ya que este implementa funciones de inserción de sensores, inserción de mediciones y obtención de mediciones. Los demás Contratos de Servicios no contienen condicionales y muestran una única operación. En el Diagrama de Secuencia cada línea de vida representa un Participante (servicio) y cada mensaje representa la ejecución de un método. Los métodos ya han sido definidos en el Diagrama de Interfaces, mientras que los parámetros de cada método han sido definidos en los Diagramas de tipos de datos primitivos y tipos de mensajes.

Los protocolos de interacción se muestran en las Figuras 4.9, 4.10 y 4.11:

Figura 4.9: Protocolo de interacción de recolección

Figura 4.10: Protocolo de interacción de geoprocesamiento

Figura 4.11: Protocolo de interacción de visualización

4.1.2.2.5. Diseño de la Arquitectura del Sistema En esta tara es necesario mostrar una visión global de como los Participantes se conectan con sus respectivos Contratos de Servicios, para que, a su vez, estos realicen la orquestación de mensajes definida en los protocolos de interacción correspondientes. Los participantes de nombre sos_52N, wps_52N y wms_geoserver implementan estándares propuestos por OCG. En el caso del participante baseDatos, no se requiere un Contrato de Servicios como intermediario para consumir sus servicios, sino que los participantes pueden conectarse directamente. El diagrama resultante se observa en la Figura 4.12.

Figura 4.12: Diagrama Arquitectónico del Sistema

Se han agrupado los Participantes y Contratos de Servicios por colores según sus módulos correspondientes. En el caso de la base de datos espacial, este participante tiene un color distintivo, ya que es accedido por todos los módulos (en algunos casos de forma indirecta). En el caso del participante sos_52N, este se conecta también con el Contrato de Servicios del módulo de geoprocesamiento, ya que permite la ejecución del método getObservation para obtener mediciones almacenadas en la base de datos espacial según un filtro.

4.1.3. Implementación Como entrada para esta actividad se toma el Modelo Arquitectónico del Sistema. No todos los servicios que se detallan en la arquitectura tienen que ser desarrollados, pero serán utilizados en esta etapa. Para la categoría de Servicios SIG se ha tomado el siguiente software que ya ha sido desarrollado por terceros e implementan estándares OGC: •

Integración de mediciones: Servicio SOS provisto por el software 52n-sensorwebsos versión 4.3.6 de la empresa 52North (52° North, 2017).

•

Geoprocesamiento: Servicio WPS provisto por el software 52n-wps versión 3.6.1 de la empresa 52North (52° North, 2016).

•

Visualización: Servicio WMS provisto por el servidor Geoserver versión 2.11.2, un proyecto comunitario de OSGeo Project (OSGeo, 2017).

En cuanto a SLAs, se han definido los siguientes parámetros para garantizar la calidad del servicio: alta disponibilidad, los servicios deben estar disponibles todo el tiempo; y escalabilidad, las capacidades de procesamiento y almacenamiento deben poder ser aumentadas sin necesidad que el servicio sea detenido o realizar procesos de reinstalación. Estos dos parámetros definidos en los SLAs pueden ser solventados debido a las características que provee la plataforma cloud de Google. A continuación, se describen las tareas realizadas en esta actividad: 4.1.3.1. Desarrollo de Participantes Para los servicios desarrollados se ha utilizado los lenguajes de Programación descritos en la Tabla 4.3: Tabla 4.3: Participantes a ser desarrollados

Servicio

Lenguaje de programación

Administración para recolección

PHP con javascript

Recolección IoT

Python

Cliente de geoprocesamiento

PHP con javascript

Cliente de visualización

PHP con javascript y el API de OpenLayers

En el caso del servicio de base de datos espacial, se ha utilizado CloudSQL, que es un servicio con el modelo PaaS provisto por la plataforma de Google Cloud. Este servicio pone a disposición del consumidor una base de datos con un motor PostgreSQL. Esta base de

datos es desplegada sobre una máquina virtual con sistema operativo Linux. Además, se ha instalado la extensión PostGIS para permitir la creación de bases de datos espaciales. 4.1.3.2. Desarrollo de Contratos de Servicios Los Contratos de Servicios generados en el Modelo Arquitectónico del Sistema no se encuentran en el Catálogo de Servicios. Estos son resultado de la actividad de Diseño de Arquitectura, pero deben ser desarrollados en esta etapa. El lenguaje de programación utilizado para el desarrollo de los Contratos de Servicios es PHP. Es necesario poner especial atención en las interfaces definidas para el consumo de cada servicio. 4.1.3.3. Pruebas Una vez desarrollado el código fuente de los diferentes paquetes software de la aplicación SIG, se procede a la etapa de pruebas. Debido a que es un ejemplo de verificación y no se dispone de personal especializado en pruebas, esta tarea ha sido realizada por el personal de Desarrollo. En esta etapa, las pruebas no se realizan sobre ambientes de producción, únicamente de desarrollo. Se han tomado también los parámetros definidos en los SLAs para esta tarea. 4.1.3.4. Generación de Artefactos de Despliegue Por último, se han generado los Artefactos de Despliegue, que, tanto en el caso de PHP como de Python, son paquetes de software que tienen que ser ubicados en la ruta de publicación de un servidor web para ser ejecutados. Estos Artefactos de Despliegue, conjuntamente con los provistos por terceros serán desplegados en la actividad correspondiente. 4.1.4. Diseño de infraestructura 4.1.4.1. Especificación de Requerimientos La primera etapa de esta actividad es la definición de requerimientos de hardware y software de la aplicación SIG. Para esta tarea se toman los Artefactos de Despliegue desarrollados y los provistos por terceros. A continuación, se detallan estos requerimientos:

4.1.4.1.1. Requerimientos de Hardware En este ejemplo de verificación, como artefactos de despliegue, se han desarrollado paquetes de software en lenguaje de programación PHP y Python. Estos paquetes de software requieren mínimas capacidades hardware debido a que desempeñan funcionalidades básicas. Por esta razón, es necesario brindar mayor importancia a los requerimientos de hardware de artefactos de despliegue provistos por terceros. La definición de los requerimientos de hardware se ha realizado en base a la experiencia del Especialista en Operaciones. Los artefactos de despliegue provistos por terceros ya han sido definidos en la actividad de implementación. Además, se ha definido que para base de datos se implementará utilizando un servicio CloudSQL. Los requerimientos de hardware mínimos se detallan en la tabla Tabla 4.4. Tabla 4.4: Requerimientos mínimos de Hardware

Artefacto de despliegue 52n-sensorweb-sos versión 4.3.6

Requerimientos mínimos de Hardware Número de cores para el procesador: 1 Memoria RAM: 4gb Especio de almacenamiento: 10gb Número de cores para el procesador: 2

52n-wps versión 3.6.1

Memoria RAM: 8gb Especio de almacenamiento: 100gb

Geoserver versión 2.11.2

Número de cores para el procesador: 1 Memoria RAM: 4gb Especio de almacenamiento: 10gb Número de cores para el procesador: 1

CloudSQL

Memoria RAM: 4gb Especio de almacenamiento: dinámico

Paquetes de software PHP

Número de cores para el procesador: 1 Memoria RAM: 2gb Especio de almacenamiento: 10gb Procesador Quad Core 1.2GHz 1GB RAM Puerto Micro SD para almacenamiento

Dispositivo IoT

Conexión wireless Pines GPIO con entradas digitales El dispositivo IoT deberá estar conectado a un sensor de calidad de aire que permita la lectura de niveles de CO y CO2, además de un sensor GPS que permita obtener la ubicación del dispositivo.

4.1.4.1.2. Requerimientos de Software En el módulo de recolección de datos, se debe realizar una conexión de red entre el dispositivo IoT y la máquina virtual que hospeda al Contrato de Servicios correspondiente, para permitir así la comunicación entre servicios. Por esta razón, es necesaria la implementación de una VPN que permita que el Contrato de Servicios correspondiente acceda al dispositivo IoT por medio de un punto de acceso ligado a una dirección IP. Los requerimientos mínimos de software se detallan en la Tabla 4.5. Tabla 4.5: Requerimientos mínimos de Software

Artefacto de despliegue

Requerimientos mínimos de Software

52n-sensorweb-sos

Sistema operativo: Linux Centos 7

versión 4.3.6

Servidor de aplicaciones: Tomcat

52n-wps versión 3.6.1

Sistema operativo: Linux Centos 7 Servidor de aplicaciones: Tomcat

Geoserver versión

Sistema operativo: Linux Centos 7

2.11.2

Servidor de aplicaciones: Tomcat Sistema operativo: Linux Centos 7

CloudSQL

Base de datos alfanumérica: PostgreSQL Base de datos alfanumérica: Extensión PostGIS Sistema operativo: Linux Centos 7

Paquetes de software

Servidor de aplicaciones: Apache

PHP

Conexión a red virtual: VPN Entorno de ejecución: PHP Sistema operativo: Raspbian Servidor de aplicaciones: Apache

Dispositivo IoT

Entorno de ejecución: Python Proxy: CGI-Python implementado sobre Apache Conexión a red virtual: Cliente VPN

4.1.4.2. Modelado de infraestructura En el caso de los paquetes que serán desplegados en plataformas cloud, no es óptimo aprovisionar una máquina virtual para cada artefacto de despliegue, por esta razón se ha modelado la infraestructura de forma que algunos artefactos serán desplegados sobre una misma máquina virtual. Utilizando la notación para la topología de la aplicación provista por tosca, los Modelos topológicos de infraestructura se observan en las Figuras 4.13 y 4.14.

4.1.4.2.1. Modelo topolรณgico de infraestructura IoT

Figura 4.13: Modelo topolรณgico de infraestructura IoT

4.1.4.2.2. Modelo topolรณgico de infraestructura Cloud

Figura 4.14: Modelo topolรณgico de infraestructura Cloud

4.1.5. Despliegue 4.1.5.1. Aprovisionamiento Para la actividad de despliegue se toma como entrada los Modelos Topolรณgicos de Infraestructura. En primer lugar, es necesario realizar el aprovisionamiento. En el caso de infraestructura cloud se aprovisionan los recursos de forma virtual y en el caso de IoT es necesario realizar un aprovisionamiento manual.

Para la infraestructura IoT, el dispositivo utilizado es un Raspberry Pi 3 Modelo B, en éste se instaló el sistema operativo Raspbian mismo que, mediante la instalación de un servidor web Apache y las capacidades de conexión a internet del Raspberry Pi, soporta una comunicación bajo protocolo HTTP codificando la información según el estándar SOS. Se configuró además un cliente VPN para que el Contrato de Servicios desplegado en Google Cloud pueda acceder al dispositivo Raspberry Pi por medio de una dirección IP como punto de acceso. El dispositivo IoT Raspberry Pi recolecta la información del sensor MQ-135 conectado a los pines GPIO del mismo. Debido a que este sensor entrega las mediciones en forma de señales analógicas, fue necesaria la transformación a señales digitales por medio de un circuido integrado ADC MPC3002. La Figura 4.15 muestra las conexiones electrónicas realizadas con los pines GPIO del dispositivo Raspberry Pi.

Figura 4.15: Diagrama de interconexión de pines GPIO con elementos electrónicos

En el caso del geoposicionamiento, se ha conectado, en un puerto USB, un sensor GPS UBlox7 para determinar la posición geográfica. El aprovisionamiento de este y los demás componentes electrónicos descritos en el Modelo Topológico de Infraestructura IoT se ha realizado de forma manual (ver Figura 4.16).

1: Sensor de Calidad de Aire MQ135

3: Interfaz de Conexión con Pines GPIO

2: Convertidor Analógico–Digital MPC3002

4: Sensor GPS U-Blox7

Figura 4.16: Aprovisionamiento manual de elementos electrónicos en el dispositivo IoT Raspberry Pi 3 Modelo B

Para la infraestructura cloud se ha utilizado la plataforma provista por Google. Se ha implementado la máquina virtual especificada en el modelo. La plataforma Google Cloud brinda la flexibilidad necesaria para crear instancias de máquinas virtuales en base a las características descritas en el Modelo Topológico de Infraestructura Cloud. La Figura 4.17 muestra las características ingresadas para la máquina virtual que alberga los servidores 52 North para recolección y geoprocesamiento.

Figura 4.17: Características de una Máquina Virtual en la plataforma Google Cloud

La Figura 4.18 muestra las instancias de las máquinas virtuales que han sido creadas según el Modelo Topológico de la Infraestructura Cloud. Las IPs externas han sido generadas de forma dinámica por la plataforma cloud como se puede observar en la Figura 4.18. Mediante estas IPs se accederá a los servicios correspondientes.

Figura 4.18: Instancias de máquina virtual creadas

Para la base de datos espacial se ha desplegado el servicio CloudSQL, que la plataforma de Google ofrece en la modalidad PaaS utilizando el motor de base de datos PostgreSQL. El servicio CloudSQL no implementa directamente una base de datos espacial, por ello se ha instalado la extensión PostGIS como ya se ha mencionado anteriormente. La Figura 4.19 muestra las características ingresadas para la máquina virtual que alberga la base de datos espacial con un modelo PaaS.

Figura 4.19: Características de una Máquina Virtual CloudSQL en la plataforma Google Cloud

La Figura 4.20 muestra que la instancia con la máquina virtual de base de datos espacial ha sido creada de forma satisfactoria. Se puede observar la IP de acceso y el puerto es 5432.

Figura 4.20: Listado de bases de datos como servicio

4.1.5.2. Despliegue La siguiente tarea es el despliegue de los servicios restantes de la aplicación SIG sobre la infraestructura de Google Cloud aprovisionada. Inicialmente se desplegó los servidores SOS y WPS cuyos paquetes de software han sido provistos por 52 North. A continuación, se desplegó el servidor Geoserver que provee el servicio WMS de visualización. Por último, se desplegó los paquetes de software desarrollados en los lenguajes de programación PHP y Python sobre los servidores virtuales y dispositivos IoT correspondientes. En el caso de servidores virtuales, se desplegó los paquetes de software sobre un servidor Apache complementado con PHP. En el caso del dispositivo IoT, se desplegó el servicio de recolección de datos sobre el servidor Apache en forma de un CGI-proxy codificado en el lenguaje de programación Python. 4.1.5.3. Pruebas Por último, se ha realizado las pruebas correspondientes que garanticen el correcto funcionamiento de la aplicación. Se han ejecutado las mismas pruebas que fueron realizadas en la actividad de implementación. Adicionalmente se ejecutaron pruebas que permitan verificar la correcta y eficiente integración de los servicios de recolección de datos por medio del dispositivo IoT y los demás servicios de la aplicación SIG que fueron desplegados utilizando la infraestructura provista por la plataforma cloud de Google. En la sección 5 se muestran los resultados obtenidos.

5. RESULTADOS

OBTENIDOS

PARA

EJEMPLO

VERIFICACIÓN 5.1. Recolección de datos por sensores Se prestará especial atención a este módulo, ya que es donde ocurre la integración de tecnologías. El Contrato de Servicios encargado de la orquestación de los servicios de recolección de datos es el que permite la integración entre el dispositivo IoT Raspberry Pi y los servicios desplegados en la plataforma cloud de Google (ver Figura 5.1). Las mediciones recolectadas son almacenadas en la base de datos espacial, para posteriormente ser utilizadas en operaciones de geoprocesamiento.

Figura 5.1: Contrato de Servicios de Recolección

El Protocolo de Interacción correspondiente a este Contrato de Servicios contiene 3 operaciones: insertSensor, insertObservation y getObservation (ver Figura 4.9). De estas 3 operaciones, la más importante es insertObservation, ya que ejecuta la recolección de mediciones y permite verificar que la integración entre tecnologías IoT y Cloud se ha realizado de forma correcta. 5.1.1. Operación insertObservation Mediante la operación “insertSensor” se ha creado un sensor con la capacidad de medir niveles de CO y CO2. El nombre del sensor es “Calidad-Aire-Cuenca”. Es necesario también ingresar parámetros adicionales a este método, como se ha especificado en la definición de tipos de mensajes (ver Figura 4.5). El participante que inicia la interacción es el Administrador de Recolección (admin: AdminRecolección), y el que recepta la petición luego de pasar por el Contrato de Servicios es el Servidor 52 North SOS (sos_52N: IntegraciónMediciones). La Figura 5.2 muestra una captura de la interfaz del Cliente de Visualización de mediciones provista por el servidor 52 North SOS. Se puede observar que los tipos de mediciones han sido catalogados como fenómenos por esta aplicación.

Figura 5.2: Extracto de interfaz que muestra el sensor ingresado

5.1.2. Operación insertObservation En esta operación intervienen todos los participantes del Contrato de Servicios de Recolección, ya que permite la interacción entre la Aplicación de Administrar, el Dispositivo IoT y el servidor SOS 52 North, que permite la recepción de un mensaje bajo el estándar SOS con el valor medido. El protocolo de interacción de esta operación se puede observar en la Figura 5.3.

Figura 5.3: Protocolo de interacción de la operación insertarObservacion

La Figura 5.4 muestra una captura de la interfaz de la Aplicación de Administración mediante la cual se empieza la interacción. El resto del Protocolo de Interacción es transparente para el usuario, ya que el proceso completo es asistido por el Contrato de Servicios. Es necesario seleccionar el tipo de gas que se pretende medir CO o CO2, ya que el método obtenerObservación requiere el parámetro idGas. Al final la Aplicación de Administración recibe un mensaje de respuesta con el valor medido y su ubicación.

Figura 5.4: Interfaz de la Aplicación de Administración

Ya que la Aplicación de Administración está desplegada en un ambiente cloud, se puede realizar una petición de forma remota para la recolección de una medición. En la Figura 5.5 se puede observar que la medición ha sido realizada por medio de un dispositivo Smartphone. Se ha implementado una aplicación en el Dispositivo Raspberry que permite, en tiempo real, mostrar la última medición realizada.

Figura 5.5: Recolección de Mediciones de forma remota por medio de la Aplicación de Administración

Para este Ejemplo de Verificación fueron insertadas 80 mediciones en posiciones geográficas diferentes. Por cada posición geográfica se realizó la medición de niveles de CO y CO2. En la sección 5.3 se observarán más a detalle dichas mediciones mediante la utilización del módulo de visualización. 5.1.3. Operación getObservation Esta operación permite realizar una consulta de los valores almacenados en la base de datos espacial. Las Figuras 5.6 y 5.7 muestran una captura de la interfaz Cliente del servidor SOS 52 North, que permite realizar la operación getObservation de forma visual.

Figura 5.6: Mediciones de CO obtenidas mediante la operación getObservation

Figura 5.7: Mediciones de CO2 obtenidas mediante la operación getObservation

5.2. Procesamiento espacial Este proceso se realiza de forma transparente para el usuario, ya que ha sido implementado mediante la ejecución de servicios que se comunican por medio de mensajes orquestados por un Contrato de Servicios de forma asíncrona. Se inicia la interacción mediante la interfaz de una aplicación Cliente (ver Figura 5.8) y el procesamiento es realizado por un servidor 52 North WPS, que ejecuta un proceso de interpolación IDW.

Figura 5.8: Interfaz Cliente de Procesamiento Espacial

En la interfaz Cliente es necesario seleccionar un rango de fechas para conformar el filtro de mediciones que será enviado como parámetro en el mensaje correspondiente. Una vez terminado el procesamiento espacial, el resultado será almacenado en forma de un archivo de imagen georeferenciado con extensión tif. Posteriormente este resultado será visualizado mediante la implementación de servicios con estándar WMS (ver sección 5.3).

5.3. Visualización de información espacial Este módulo implementa una aplicación Cliente en ambiente web, que permite el consumo de servicios web bajo el estándar WMS. Estos servicios web son publicados mediante un servidor Geoserver. Geoserver se conecta de forma directa a la base de datos espacial, para así publicar las capas de puntos correspondientes a las mediciones de CO y CO2. Ya que el servidor SOS 52 North tiene una estructura propia para la base de datos espacial, se implementó una consulta en formato SQL para obtener los datos de forma diferenciada. Las Figuras 5.9 y 5.10 muestran las 80 mediciones de CO y CO2 realizadas sobre la zona Industrial de la Ciudad de Cuenca-Ecuador, mediante la interfaz de Visualización.

Figura 5.9: Mediciones de CO realizadas en la Zona industrial de la Ciudad de Cuenca - Ecuador

Figura 5.10: Mediciones de CO realizadas en la Zona industrial de la Ciudad de Cuenca - Ecuador

El resultado del procesamiento espacial ha creado una superficie de predicción en base a un proceso de interpolación IDW que tomó como entrada los 80 puntos de muestra. Las Figuras 5.11 y 5.12 se muestran los resultados utilizando un mapa interactivo que permite la navegación sobre el área de estudio (Zona industrial de la ciudad de Cuenca - Ecuador).

Figura 5.11: Resultados del proceso de interpolación IDW sobre los puntos de muestra de CO

Figura 5.12: Resultados del proceso de interpolación IDW sobre los puntos de muestra de CO2

5.4. Discusión de resultados Se ha realizado un seguimiento al proceso completo de Recolección, Procesamiento y Visualización de información espacial. Este seguimiento demuestra el correcto funcionamiento de la aplicación SIG desplegada en la plataforma cloud de Google integrado con un dispositivo IoT Raspberry, que permite la automatización del proceso de recolección de información espacial. Se han recolectado 80 mediciones de niveles de CO y CO2 en posiciones geográficas diferentes sobre la zona industrial de la ciudad de Cuenca - Ecuador. Estas mediciones han servido de puntos de muestra para la ejecución de un proceso de interpolación IDW. Como resultado final, se ha generado una superficie de predicción en formato tif. Esta superficie permite el cálculo de niveles de CO y CO2 en el resto de posiciones geográficas sobre las cuales no se ha realizado ninguna medición. La leyenda de la superficie de predicción generada, agrupa los valores obtenidos en rangos cuantitativos en orden ascendente desde un color más claro a un color más obscuro. Se puede observar que existen lugares donde los valores de CO y CO2 son más altos. Esto ayuda a la toma de decisiones al momento de definir medidas que permitan combatir la contaminación en esta zona. Existen fábricas que contribuyen al aumento de la contaminación en el área de estudio. Es posible identificar la ubicación de dichas fábricas gracias a la superficie de predicción generada. Como ya se mencionó en el Estado del conocimiento (sección 2.2), en temas de integración de tecnologías IoT y cloud en el dominio SIG, se han realizado estudios de las posibles aplicaciones (Liu, 2013); definido arquitecturas (Gubbi et al., 2013); implementado estándares de transmisión de datos por sensores (Bröring et al., 2011; Sagl, et. al., 2011); creado herramientas de integración (López et al., 2016; Zúñiga-Prieto, Insfran y Abrahão, 2016a); o definido enfoques de integración basado en SOA (Chen et al., 2016; ZuñigaPrieto, Abrahao e Insfran, 2015). A diferencia de los estudios ya mencionados, el método de integración propuesto en esta tesis permite guiar al desarrollador al momento de diseñar, implementar y desplegar aplicaciones SIG. Los resultados obtenidos al implementar este método mediante un ejemplo práctico, han permitido validar su aplicabilidad en un escenario real y brindan el nivel de detalle necesario para ser replicado en cualquier otro escenario con características similares.

6. CONCLUSIONES En esta tesis se han identificado varios problemas al momento de integrar tecnologías IoT y cloud en el desarrollo de aplicaciones SIG. Los planteamientos actuales no proveen una guía que permita la definición de una arquitectura de software flexible que, mediante la implementación de protocolos y estándares, integre servicios de una aplicación SIG independientemente de su tecnología y brinde soporte a las etapas principales del desarrollo de software: Diseño, Desarrollo y Despliegue de la aplicación. Se ha propuesto un método para el desarrollo de aplicaciones SIG desplegadas en plataformas cloud y permite la integración de dispositivos IoT para automatizar las funcionalidades de la aplicación. Este método, a diferencia de las propuestas mencionadas en trabajos relacionados, guía a los desarrolladores de aplicaciones durante la ejecución de las actividades de descripción de servicios, diseño arquitectónico y de infraestructura, desarrollo y despliegue. Se han sugerido lenguajes de especificación que brindan el soporte para lograr los objetivos de cada actividad. Se han categorizado los tipos de servicios y se plantean modelos que permitan soportar las características o requerimientos no funcionales de alto nivel de acuerdo a cada categoría de servicio, lo cual aporta gran flexibilidad para la toma de decisiones en etapas posteriores. Además, el método promueve la aplicación de estándares SIG al momento de la definición de las interfaces de los servicios, permitiendo así la integración con otros servicios SIG, dispositivos IoT y servicios publicados por IDEs. La aplicabilidad del método propuesto fue ilustrada con un ejemplo de verificación de una aplicación SIG en donde los servicios que conforman su arquitectura fueron desplegados en la plataforma Google Cloud y su proceso de recolección de datos fue realizado por sensores de calidad de aire bajo el paradigma IoT. Los requerimientos funcionales del ejemplo de verificación son los siguientes: •

Auto-recolección de mediciones de CO2 y CO mediante un sensor transportable bajo el paradigma IoT, tomando como área de estudio la zona industrial de la ciudad de Cuenca-Ecuador,

•

Desplegar una aplicación SIG en una plataforma cloud con servicios web que permitan almacenar las mediciones recolectadas por el dispositivo IoT en una base de datos espacial.

•

El ejemplo de verificación ha permitido poner a prueba la aplicabilidad del método propuesto en un ambiente real con éxito mediante la implementación de 3 módulos: Recolección, Procesamiento y Visualización de información espacial. Se han mostrado los resultados obtenidos en la ejecución de la aplicación resultante. A pesar de que la propuesta se ha centrado en recolección de datos por sensores, es posible la utilización de dispositivos IoT como actuadores que ejecuten tareas en base a eventos de la aplicación, según necesidades funcionales de misma. Es necesario tomar en cuenta que el método propuesto, únicamente puede integrar dispositivos IoT con la capacidad de desplegar servicios web.

7. REFERENCIAS 52° North. (2016). WPS webserver. Recuperado el 18 de septiembre de 2017, a partir de http://52north.org/communities/geoprocessing/wps/ 52° North. (2017). SOS webserver. Recuperado el 18 de septiembre de 2017, a partir de http://52north.org/communities/sensorweb/sos/ Ara, T., Gajkumar Shah, P., y Prabhakar, M. (2016). Internet of Things Architecture and Applications: A Survey. Indian Journal of Science and Technology, 9(45). https://doi.org/10.17485/ijst/2016/v9i45/106507 Atzori, L., Iera, A., y Morabito, G. (2010). The Internet of Things: A survey. Computer Networks, 54(15), 2787–2805. https://doi.org/10.1016/j.comnet.2010.05.010 Bhat, M. A., y Ahmad, B. (2011). Cloud Computing : A solution to Geographical Information Systems (GIS), International Journal on Computer Science and Engineering. 3(2), 594–600. Binz, T., Breiter, G., Leyman, F., y Spatzier, T. (2012). Portable cloud services using TOSCA.

IEEE

Internet

Computing,

16(3),

80–85.

https://doi.org/10.1109/MIC.2012.43 Botta, A., Donato, W. De, Persico, V., y Pescapé, A. (2016). Integration of Cloud Computing and Internet of Things : A survey. Future Generation Computer Systems, 56, 684–700. https://doi.org/10.1016/j.future.2015.09.021 Breiter, G., Spatzier, T., y Behrendt, M. (2011). Cloud Computing — An Industry Perspective.

Information

Technology,

53(4),

165–172.

https://doi.org/10.1524/itit.2011.0639 Bröring, A., Echterhoff, J., Jirka, S., Simonis, I., Everding, T., Stasch, C., … Lemmens, R. (2011).

New

generation

Sensor

Web

Enablement.

Sensors

(Vol.

11).

https://doi.org/10.3390/s110302652 Caceres, R., y Friday, A. (2012). Ubicomp systems at 20: Progress, opportunities, and challenges.

IEEE

Pervasive

https://doi.org/10.1109/MPRV.2011.85

Computing,

11(1),

14–21.

Canto, M., Pereda, D., y Segurola, A. (2006). Service Oriented Architecture (SOA). Proyecto SOA-TSI4, 1–6. Chen, I. R., Guo, J., y Bao, F. (2016). Trust Management for SOA-Based IoT and Its Application to Service Composition. IEEE Transactions on Services Computing, 9(3), 482–495. https://doi.org/10.1109/TSC.2014.2365797 Dobesova, Z. (2011). Programming language Python for data processing. 2011 International Conference on Electrical and Control Engineering, ICECE 2011 - Proceedings, 4866– 4869. https://doi.org/10.1109/ICECENG.2011.6057428 Evangelidis, K., Ntouros, K., Makridis, S., y Papatheodorou, C. (2014). Geospatial services in

the

Cloud.

Computers

and

Geosciences,

63,

116–122.

https://doi.org/10.1016/j.cageo.2013.10.007 Gubbi, J., Buyya, R., Marusic, S., y Palaniswami, M. (2013). Internet of Things (IoT): A vision, architectural elements, and future directions. Future Generation Computer Systems, 29(7), 1645–1660. https://doi.org/10.1016/j.future.2013.01.010 Hofmeister, C., Kruchten, P., Nord, R. L., Obbink, H., Ran, A., y America, P. (2005). Generalizing a Model of Software Architecture Design from Five Industrial Approaches. WICSA conf., 77–88. https://doi.org/10.1109/WICSA.2005.36 Kruchten, P. (1995). The 4+ 1 view model of architecture. Software, IEEE, November 1(November), 9. https://doi.org/10.1109/52.469759 Liu, Z. (2013). Typical characteristics of cloud GIS and several key issues of cloud spatial decision support system. Proceedings of the IEEE International Conference on Software

Engineering

and

Service

Sciences,

ICSESS,

668–671.

https://doi.org/10.1109/ICSESS.2013.6615395 López, J. A., Pavón, N., Navarro, H., Soto, F., y Torres, R. (2016). A software architecture based on FIWARE cloud for Precision Agriculture. Agricultural Water Management, 183, 123–135. https://doi.org/10.1016/j.agwat.2016.10.020 McKinsey Global Institute. (2015). The Internet of Things: Mapping the Value Beyond the Hype,

(June).

Recuperado

febrero

2018,

partir

https://www.mckinsey.de/files/unlocking_the_potential_of_the_internet_of_things_fu

ll_report.pdf Mell, P. M., y Grance, T. (2011). The NIST definition of cloud computing. https://doi.org/10.6028/NIST.SP.800-145 Naseer, A., Aldoobi, H. I., y Alkazemi, B. Y. (2015). A service-oriented architecture for GIS applications. 2015 10th International Joint Conference on Software Technologies (ICSOFT), 2, 1–5. https://doi.org/10.5220/0005556501510155 OASIS, Organization for the Advancement of Structured Information Standards. (2015). TOSCA Simple Profile in YAML Version 1 . 0 Committee Specification Draft 04 / Public Review Draft 01, (August). Recuperado el 12 de febrero de 2018, a partir de http://docs.oasis-open.org/tosca/TOSCA-Simple-ProfileYAML/v1.0/csprd01/TOSCA-Simple-Profile-YAML-v1.0-csprd01.pdf OMG, Object Management Group. (2008). Software y Systems Process Engineering MetaModel Specification V2.0, (April), 236. https://doi.org/formal/2008-04-01 OMG, Object Management Group. (2012). Service oriented architecture Modeling Language (SoaML) Specification. Language, (March), 1–144. OGC, Open Geospatial Consortium. (2007). OGC Web Processing Service. Recuperado el 12 de febrero de 2018, a partir de http://www.opengeospatial.org/standards/wps OGC, Open Geospatial Consortium. (2012a). ¿Por qué OGC está involucrado en Sensores Web?

Recuperado

enero

2017,

partir

http://www.opengeospatial.org/domain/swe OGC, Open Geospatial Consortium. (2012b). Sensor Web Enablement. Recuperado el 1 de julio de 2017, a partir de http://www.opengeospatial.org/ogc/markets-technologies/swe OGC, Open Geospatial Consortium. (2017). About OGC. Recuperado el 1 de enero de 2017, a partir de http://www.opengeospatial.org/ogc OGC, Open Geospatial Consortium, Bröring, A., Stasch, C., y Echterhoff, J. (2012). OGC Sensor Observation Service Interface Standard. OGC Implementation Standard, 12–6, 163.

Recuperado

febrero

http://www.opengeospatial.org/standards/sos

2018,

partir

OGC Open Geospatial Consortium, y de la Beaujardiere, J. (2006). OpenGIS® Web Map Server

Implementation

Specification.

Organization

Environment.

https://doi.org/http://www.opengeospatial.org/standards/wms OGC Open Geospatial Consortium, Mueller, M., y Pross, B. (2015). OGC WPS Interface Standard, 1–133.

Recuperado el

de febrero de

2018, a

partir de

https://portal.opengeospatial.org/files/14-065 OSGeo. (2017). Geoserver. Recuperado el 18 de septiembre de 2017, a partir de http://geoserver.org/ Priya, R. V., Sivaranjani, S., y Sivakumari, S. (2016). GIS Enabled Internet of Things ( IoT ) Applications : An Overview, 41, 2392. Rodríguez, D., Rodríguez, J., y Zúñiga, M. (2017). Hacia un método para la integración de IoT y aplicaciones SIG desplegadas en plataformas Cloud. En INCISCOS 2017 International Conference on Information Systems and Computer Science. Quito, Ecuador. Ruiz, F., y Verdugo, J. (2008). Guía de Uso de SPEM 2 con EPF Composer. Composer, Version 3., 93. Sagl, G., Lippautz, M., y Resch, B. (2011). Near Real-Time Geo-Analyses for Emergency Support: An Radiation Safety Exercise. 14th AGILE International, (Figure 2), 1–8. Recuperado

febrero

2018,

partir

http://guenthersagl.com/publications/Sagl et al 2011 AGILE GeoAnalyses for Emergency Support.pdf Sheth, A., Henson, C., y Park, V. (2008). Semantic Sensor Web. Somerville, I. (2015). Ingeniería de software. (L. M. C. Castillo, Ed.) (Novena edi). México: Pearson Educación. Yue P., Zhou H., Gong J. y Hu L. (2013). Geoprocessing in Cloud Computing platforms – a comparative analysis. International Journal of Digital Earth, 6(4), 404-425. https://doi.org/10.1080/17538947.2012.748847 Zhao, C., Jegatheesan, J., y Loon, S. C. (2015). Exploring IOT Application Using Raspberry

Pi | BibSonomy. International Journal of Computer Networks and Applications, 2(1), 27–34. Zúñiga-Prieto, M. (2017). Reconfiguración Dinámica e Incremental de Arquitecturas de Servicios Cloud Dirigida por Modelos. Universidad Politécnica de Valencia. Zuñiga-Prieto, M., Abrahao, S., y Insfran, E. (2015). Perfil UML para el Modelado de la Integración de Servicios Cloud en Procesos de Desarrollo Incremental. XI Jornadas de Ciencia e Ingeniería de los Servicios (JCIS). Recuperado el 12 de febrero de 2018, a partir

http://biblioteca.sistedes.es/wp-

content/uploads/2015/09/JCIS_2015_submission_14.pdf Zúñiga-Prieto, M., Insfran, E., y Abrahão, S. (2016a). Architecture Description Language for Incremental Integration of Cloud Services Architectures. Proceedings - 2016 IEEE 10th International Symposium on the Maintenance and Evolution of Service-Oriented and

Cloud-Based

Environments,

MESOCA

2016,

16–23.

https://doi.org/10.1109/MESOCA.2016.10 Zúñiga-Prieto, M., Insfran, E., Abrahao, S., y Cano-Genoves, C. (2016b). Incremental Integration of Microservices in Cloud Applications. Information Systems Development: Complexity in Information Systems Development (ISD2016 Proceedings), (August), 93–105.