Kitabı oku: «Innovando la educación en la tecnología», sayfa 19

Propuesta de un patrón de arquitecturas de software para la interoperabilidad en dispositivos en la capa al borde de un ecosistema IoT

Juan Moreno-Motta

juan.moreno2@unmsm.edu.pe / Escuela de Ingeniería de Sistemas e Informática, Universidad Nacional Mayor de San Marcos, Lima, Perú

Felipe Moreno-Vera

felipe.moreno@ucsp.edu.pe / Departamento de Ciencia de la Computación, Universidad Católica San Pablo, Arequipa, Perú

Frank Moreno-Vera

fmorenov@uni.pe / Escuela de Ingeniería Electrónica, Universidad Nacional de Ingeniería, Lima, Perú

Recepción: 31-5-2019 / Aceptación: 9-7-2019

RESUMEN. En los últimos años el Internet de las cosas ha generado una disrupción en el ecosistema de soluciones para usuarios finales con aplicaciones en la salud, agroindustria, medio ambiente y otras soluciones heterogéneas. Cada una de estas tienen su propio formato para verbalizar los datos proporcionados por los diferentes servicios SOAP, RESTful, REST-LD en formato JSON o XML que pueden ser entendidos por personas. Estos dispositivos se denominan “heterogéneos” porque provienen de diferentes proveedores de manufactura, diferentes lenguajes de programación como C, C++, Lua, Python, JavaScript, etc. Este documento se enfoca sobre dispositivos restringidos, es decir, dispositivos con poca capacidad de procesamiento y memoria con diferentes cadenas de datos sensados. Esta investigación propone un patrón de arquitectura de software para la interoperabilidad entre los dispositivos al borde de un ecosistema IoT y entre ecosistemas entre sí.

PALABRAS CLAVE: interoperabilidad, IoT, dispositivos restringidos, microservicios, semántica web, encoder, decoder, fog computing, edge computing, REST API, software architecture, IoT Ecosystem

Proposal for a Software Architecture Pattern for the Interoperability Between Devices on the Edge of an IoT Ecosystem Layer

ABSTRACT. In recent years, the Internet of Things has generated a disruption in the solution ecosystem for end users with applications in health, agro-industry, environment and other heterogeneous solutions. Each of these solutions has its own format to verbalize the data provided by different web services, including SOAP, RESTful and REST-LD, in JSON or XML format, so that said data can be understood by people. These devices are called “heterogeneous” because they come from different manufacturers and use different programming languages such as C, C++, Lua, Python, Javascript, etc. This document focuses on constrained devices, that is, devices with little processing capacity and memory, and different chains of acquired data. This research proposes a software architecture pattern for interoperability between devices on the edge of an IoT ecosystem and between ecosystems.

KEYWORDS: interoperability, IoT, constrained devices, microservices, semantic web, encoder, decoder, fog computing, edge computing, REST API, software architecture, IoT ecosystem

1. INTRODUCCIÓN
1.1 Revisión previa

El Internet of Things (de ahora en adelante, IoT) no es una tecnología nueva, es la convergencia de muchas tecnologías para soluciones como la salud, medio ambiente, manufactura, ahorro de energía, seguridad ciudadana. El IoT es un sistema de objetos físicos que se pueden descubrir, controlar o interactuar con dispositivos electrónicos que se comunican a través de varias interfaces de red y que, finalmente, se pueden conectar a Internet (Guinard y Trifa, 2016). Hasta hace poco, los proyectos de IoT se centraban principalmente en la creación de implementaciones a pequeña escala, cerradas y aisladas en las que los dispositivos no estaban diseñados para ser fácilmente accesibles o reprogramables (Guinard y Trifa, 2016).

En el año 2014, según en el estudio realizado por Oliver Klein (2017), se informó que en el año 2013 existían 1 billón de unidades de Smartphone y que para el año 2017 se esperaba 1.7 billones. En el mismo año, Jaimini (2017) indicó que en el año 2014 National Health Interview Survey realizó un estudio sobre el asma que afecta a los niños en EE. UU. lo cual conlleva a la pérdida de días de escuela y otros costos sociales. En ese año se estimó que para el año 2017 se incrementarían los dispositivos IoT a 15 mil millones y que el almacenamiento de los datos superaría 150 exabytes.

1.2 Actualidad

Talavera et al. (2017) realizan un trabajo de estado del arte sobre el número de implementaciones de IoT en los sectores de la agroindustria y el medio ambiente, tomando como referencia los resultados de otros, los clasificaron en identificación (3578), en selección (2652), en elegibles (720) y se tomaron finalmente 72 proyectos. Como resultado presentaron una arquitectura que trata de consolidar el ancho espectro de implementación (véase la figura 1). Uno de los retos que consideran en su trabajo de investigación es que una estandarización más sólida ayudaría a mejorar la compatibilidad entre diferentes proveedores y garantizar las medidas de seguridad más sólidas en todas las capas de IoT, desde los dispositivos de campo hasta los proveedores de la nube y las interfaces de usuario final. Este punto se refiere a la interoperabilidad entre las distintas capas de comunicación.

También en el año 2017, se desarrolló una plataforma para el control y monitoreo de la salud de personas dentro de sus hogares. Esta plataforma fue denominada SPHERE (Sensor Platform for HEalthcare in Residential Environment). Este proyecto determinó que existen nueve requerimientos que el IoT necesita cubrir y uno de ellos es la interoperabilidad. En el caso de dispositivos restringidos, es decir, con baja capacidad de memoria y procesamiento, Elsts, Oikonomou, Fafoutis y Piechocki (2017) consideran que los sistemas deben cumplir con los estándares y protocolos de IoT existentes de baja potencia para 1) ser susceptible de futuras extensiones con componentes de terceros; 2) reducir el tiempo de aprendizaje para el nuevo personal.

Existen muchas soluciones de IoT. Cada implementación de IoT presenta retos de requerimientos no funcionales como son seguridad, almacenamiento, escalabilidad, interoperabilidad y energía. Alkhalil y Ramadan (2017) mencionan que los retos relativos a la procedencia de los datos, a pesar de las técnicas actuales, sigue siendo un desafío en su implementación y optimización. Por lo cual el reto de procedencia de datos se enlaza directamente con la interoperabilidad.

En la actualidad, la interoperabilidad es uno de los desafíos en las implementaciones de soluciones de IoT. Se realiza demasiado esfuerzo al integrar la información generada por los diferentes dispositivos en el dominio de salud, agroindustria y medio ambiente. Dentro de cada dominio existen diferentes sensores, para cada sensor existen diferentes marcas y fabricantes (Pace et al., 2017). Cada marca y fabricante trae consigo herramientas de desarrollo, con su propio lenguaje de programación. Los datos generados tienen diferentes estructuras tanto en la cabecera como en el cuerpo del mensaje transmitido, generando un riesgo de privacidad aumentando este desafío de interoperabilidad (Madaan, Ahad y Sastry, 2017).

1.3 Propuesta de solución

Después de analizar los trabajos previos, se identificó el reto de la interoperabilidad y la procedencia de los datos como parte de ella en las soluciones de IoT.

Pace et al. (2017) presentan su trabajo para apoyar la interoperabilidad de dos aplicaciones de asistencia médica Active and Assisted Living (AAL) mediante la integración de dos plataformas heterogéneas y no interoperables ya existentes como BodyCloud y universalAAL. Este trabajo concluye con la propuesta del marco de trabajo INTER-IoT. Este proyecto tiene un horizonte hasta el 2020 y es un proyecto de la Comunidad Europea. Un caso de uso específico es INTERHealth que se despliega para validar el INTER-IoT propuesto. El proyecto estuvo compuesto por tres bloques de construcción principales: infraestructuras orientadas a capas (INTER-LAYER) para adaptar capas de pares heterogéneas (dispositivo a dispositivo, conexión de red a red, middleware a middleware, servicios de aplicaciones a servicios de aplicación, datos y semántica a datos y semántica (véase la figura 2).

Di Martino, Esposito, Augusto Maisto, y Nacchia (2017) mencionan que existen varios actores que están en proceso de crear plataformas interoperables como M2M, AllJoyn, OIC y INTER-IoT, revisado líneas arriba. Presentan una propuesta de un marco de trabajo que permite una solución de interoperabilidad. Realizan una investigación sobre los diferentes IDL (interface description language) como los APIs WADL, RAML, BluePrint y OpenAPI para RESTful.

Di Martino et al., (2017) presentan un framework como propuesta, que se aprecia en la figura 3, en el cual se muestra una arquitectura de alto nivel. Los componentes principales se destacan junto con los flujos de comunicación e interacción entre ellos. El AgnosticEndPoint es la interfaz que el usuario puede usar para realizar la solicitud. El middleware es el componente que es responsable de comprender si una entrada proporcionada por el usuario es útil para uno de los endpoints del proveedor registrado en el sistema; transformar la entrada proporcionada por el usuario en algo soportado por un “endpoint” del proveedor específico o múltiple; hacer la solicitud actual a VendorEndPoint; transformar la salida del VendorEndPoint en el formato estándar proporcionado por el AgnosticEndPoint.

Yacchirema, Palau y Esteve (2017) proponen una arquitectura con dos capas: capa lógica de aplicación y capa de módulos comunes. La primera capa expone servicios; la segunda, cinco módulos básicos que habilitan la interoperabilidad de IoT para todos los servicios que se quieran supervisar, se la denomina Smart IoT Gateway y es la que aumenta la flexibilidad y escalabilidad del AAL-IoTSys propuesto. Esta arquitectura se desarrolló considerando que los dispositivos IoT, generalmente, son de recursos limitados o restringidos en términos de procesamiento, memoria y almacenamiento. La figura 4 muestra la arquitectura propuesta.

Andročec, Tomaš y Kišasondi (2017) plantean el uso de la web semántica para permitir la interoperabilidad en IoT utilizando JSON-LD. La idea básica de JSON-LD es crear una descripción de los datos en forma de un llamado contexto. También exploran algunas posibilidades de interoperabilidad y comunicación entre dispositivos IoT económicos.

Sun, Li y Memon (2017) formulan una REST API y una comparación entre la arquitectura monolítica y de microservicios. Utiliza REST API para la comunicación desde los dispositivos, incluyendo el registro del mismo en el ecosistema. La asignación de microservicios a dispositivos funciona dinámicamente al interactuar con el servicio central, proporciona un buen soporte para la (WoT) y tiene una mayor adaptabilidad, escalabilidad e interoperabilidad.

Lim, Majumdar y Nandy (2010) y Malik y Kim (2017) proponen y comparan arquitecturas basadas en servicios SOAP y REST API como propuesta de solución a la interoperabilidad.

Kum, Moon y Lim (2017) exponen una arquitectura novel para construir aplicaciones para fog computing, usando el procesamiento de datos en el borde en vez de hacerlo en la nube.

Petersen, Bindner, Poulsen y You (2017a) y Wendt, Faschang, Leber, Pollhammer y Deutsch (2013) hacen una demostración del desempeño de los diferentes formatos llegando a la conclusión de que el formato binario generado con Protobuff desarrollado por Google es el de mejor rendimiento y menor uso de memoria (véase la figura 5).

2. PROPUESTA

Hemos revisado varias propuestas de arquitectura de software para superar la interoperabilidad, así como de formatos de datos SOAP y REST API. Estas van desde microservicios y pasan por web semántica como JSON-LD, en ambos casos se requiere de capacidad de procesamiento y memoria que poseen los servidores, pero no dispositivos restringidos. Nuestro enfoque en este estudio es para dispositivos de bajo procesamiento y capacidad de memoria. La procedencia de los datos forma parte del reto de la interoperabilidad. Consideramos que existen ambientes hostiles de comunicación por lo que la trama de datos serializada debe ser muy compacta. La propuesta va dirigida a la capa al borde de un ecosistema de IoT (véase la figura 6).

Para nuestra propuesta tomamos como base el estudio comparativo de Petersen et al. (2017a) donde se demuestra un gran rendimiento utilizando el formato binario para la transferencia de datos desde los dispositivos.

2.1 Componentes que conforman la arquitectura

Describimos los componentes que conforman la arquitectura propuesta:

Device. Representa todos los dispositivos que se conectan al ecosistema a través del componente middleware. Aquí se debe implementar la serialización en formato binario. En general pueden ser sensores y actuadores.

• Sensor: detecta magnitudes físicas o químicas.

• Actuador: transforma la energía para causar un efecto en un elemento externo.

Middleware. Se encarga de recibir el formato binario. Este componente hace uso del componente processing que tiene mayor capacidad de procesamiento ya que se comporta como un servidor. Este componente también hace uso del componente file system como archivo de configuración del ecosistema.

MessageQueue. Se encarga de proporcionar alta disponibilidad y escalabilidad. Asegura que, ante la presencia de alta concurrencia, la trama de datos de los dispositivos se guarden siempre en la cola de mensajes para que de esa forma gestionar el encolamiento (Rostanski, Grochla y Seman, 2014).

Security. Este componente es un servicio consumido por el middleware. A cada device se le asigna un ID único mediante un certificado que luego será validado por este servicio.

Processing. Se encarga de procesar los formatos de datos binarios que son recibidos desde el componente device.

Repository. Es de persistencia donde se terminarán alojando las tramas de datos.

Managment interface. Interfaz de administración a la cual se puede acceder desde un terminal que puede ser un PC, una laptop o un celular. Mediante este administrador se registran los tipos de dispositivos, los dispositivos, el middleware y el ecosistema.

File system. Describe las propiedades del ecosistema y guarda los certificados de los ID de los device encriptados.

Services. Es la capa de servicios que el fog computing puede entregar para que otros dispositivos externos puedan recibir información (de sensores) o enviar una acción a ejecutar (actuadores).

Fog computing. Alberga componentes descritos. Fog computing tiene todas las ventajas del cloud computing (Paharia y Bhushan, 2018).

Cloud computing. Este componente, que está fuera del ecosistema de IoT, es el repositorio final y es donde se deben realizar el análisis y los cálculos de gran volumen de información. De tipo propietario de ciento de miles de servidores dedicados. De alta disponibilidad, permite que se puedan generar múltiples análisis de datos para diferentes fines (Mengistu, Alahmadi, Albuali, Alsenani y Che, 2018).