Saltar al contenido
Blog Innovación y Tecnología

Fast Data: el motor del IoT

En un futuro cercano no va a existir sector que se escape del uso de IoT ( Internet of things). Smartphonesweareables, casa conectada, coche conectado, industria 4.0, logística inteligente, retailsmart cities … TODO va a estar de una forma u otra conectado. Hemos pasado del Internet de los ordenadores (millones), al Internet de las personas (miles de millones) al Internet de las cosas (billones).

Nada nuevo que no sepamos… el IoT está ya entre nosotros y va a crecer de forma exponencial.

Esos millones de sensores desplegados en nuestros productos o infraestructuras, van a ser capad de recoger, procesar y enviarnos cantidades ingentes de información que tendremos que engullir, almacenar y procesar, con objeto de obtener un valor para la organización y para los clientes o usuarios de nuestros productos y servicios.

En algunos escenarios IoT necesitaremos procesar información en el propio dispositivo mientras que el escenario más común es que el dispositivo disponga de unos pocos sensores capaces de medir algunos parámetros del entorno (temperatura, presencia, vibración, orientación, pulso…) y tenga poca capacidad de procesamiento.

Este tipo de dispositivos IoT van a tomas sus mediciones de forma periódica o en respuesta a eventos, y nos van a transmitir esos datos a través de una infraestructura de comunicaciones  a nuestros sistemas donde tendremos que recoger y procesar la información.

El procesamiento en batch de toda esa información nos puede ayudar a optimizar  nuestros procesos, tomar decisiones de negocio o mejorar el servicio a los usuarios.

Sin embargo, los modelos de negocio realmente disruptivos vendrán de ser capaces de procesar esa información y de actuar en tiempo real, dando un valor añadido al cliente o usuario en el mismo momento que nuestro dispositivo  IoT interacciona con él.

Esta capacidad de recoger grandes cantidades de datos, procesarlos y actuar en tiempo real la llamamos Fast Data.

Fast Data es el autentico habilitador de la disrupción en el mundo IoT.

Pero, ¿Cómo puedo montar una infraestructura que me permita conectar mi mundo IoT a mis sistemas y procesar la información en tiempo real?

Para definir nuestra arquitectura de referencia vamos a centrarnos en dos componentes esenciales un la integración entre ellos: el middleware IoT y el backend de procesamiento Fast Data.

Middleware IoT.

Existen en el mercado  diversos tipos de middleware de comunicaciones especialmente diseñados para conectar dispositivos IoT. El uso de un middleware nos simplifica todas las tareas necesarias para disponer de una infraestructura escalable, robusta, segura y eficiente.

Entre los middleware existentes me gustan aquellos que cumplen las especificaciones  Data Distribution Service for real-time systems (DDS) basado en el patrón  publishsubscribe.

Estos middleware nos proveen de mensajería entre dispositivos incluyendo servicios de administración y monitorización, interoperabilidad, persistencia de mensajes, calidad de servicio, log etc.

Un buen producto y líder del mercado  de este tipo es RTI ( https://www.rti.com/ ).

Este tipo de middleware me gusta porque está orientado a transmitir no tanto un evento como un estado. Es decir, si tengo un dispositivo con varios sensores, el dispositivo puede tomar las medidas y publicar en el canal ese conjunto de medidas (su estado) para que los subscriptores lo recojan y procesen. Quizás por mi experiencia previa trabajando en CORBA, me parece muy interesante que esa descripción del dispositivo IoT se defina en lenguaje IDL que puede ser compilado posteriormente a cualquier lenguaje de programación, desde C++, Java, C# etc. Esto nos permite que cada uno de los publicadores y subscriptores puedan estar desarrollados en distintos lenguajes y plataformas, e inter-operar de forma transparente.

Infrastructura Fast Data

Ya tenemos entonces el middleware publicación/subscripción sobre el que van a fluir los mensajes entre dispositivos IoT y nuestras aplicaciones servidoras… estas deben de ser muy rápidas para ser capaces de recoger, almacenar y procesar los mensajes provenientes de miles de dispositivos por diversos canales y de devolver las respuestas adecuadas a cada dispositivo en tiempo real.

Si quiero ser MUY rápido en un sistema de este tipo, no me queda más remedio que trabajar con una infraestructura que me permita:

1 – Trabajar con todos los datos en memoria (In Memory Computing)

2- Trabajar de forma paralela (Massive Parallel Computing)

Las infrastructuras Fast Data más comunes son Spark Streaming, In Memory Database (ejemplo https://www.voltdb.com/ ) y los In Memory Data Grid IMDG (ejemplo https://www.scaleoutsoftware.com/)

En nuestro caso elegimos el IMDG porque nos permite tener en memoria un objeto con la misma definición en IDL que el objeto IoT que hemos definido para el middleware DDS.

Esta característica nos permite que la integración entre el middleware y el IMDB sea inmediata y sencilla.

¿Cómo funciona esta integración?

Vamos a mostrarlo de forma en muy alto nivel con un ejemplo sencillo a modo de ilustración.

Supongamos que tenemos un sistema de medición de la contaminación desplegado en una ciudad como Madrid con varios miles de puntos de medición. Cada uno de ellos mide cada minuto una serie de valores Co2, NO2, temperatura etc. En cada medición envía esos datos a un servidor que evalúa la contaminación en función de una serie de reglas y algoritmos para desencadenar alertas que son distribuidas a distintos agentes, los cuales tomarán distintas medidas.

En nuestro sistema, cada estación de medida, está definida por un interface IDL. Este interface se compilará por ejemplo, a lenguaje C para el desarrollo del software embebido en las estaciones, y a Java para el sistema del centro de control. Cada estación será un publisher que cada minuto publicará su estado en el canal definido en el middleware. Este se encarga de no solo transmitir el estado a los subscriptores en este caso la aplicación del servidor de control, sino además de hacerlo con las garantías de servicio y seguridad necesarias.

El sistema d control tiene un modulo que escucha el canal y cuando recibe un estado de una estación vuelca ese objeto que define el estado, en una base de datos en memoria del tipo IMDG. La primera ventaja de esta arquitectura es que no tengo que definir el modelo de datos que voy a almacenar en el servidor en memoria, es el mismo objeto que está definido para la estación, simplemente compilado de IDL a Java.

Los objetos se almacenan, modifican y localizan en la memoria del grid utilizando queries paralelas, todo ello con una latencia mínima. La capacidad de ingestión del sistema es muy alta y paralelizable.

Además el IMDG soporta la ejecución de algoritmos paralelos en todas las máquinas que están integradas en el grid (una infrastructura AWS o Azure por ejemplo), de forma que puedo desarrollar los algoritmos que van a analizar los índices de contaminación en tiempo real y generar y enviar las alarmas.

Estas alarmas se podrían enviar también por el middleware a los distintos subscribers para ser procesadas por ellos.

Este ejemplo nos muestra como una infraestructura para ser eficiente a la hora de dar respuesta en tiempo real al mundo IoT necesita trabajar en memoria de forma paralela, además de tener un alto throughtput y una baja latencia.

La combinación de middleware (RTI DDS) y servidor de procesamiento ( IMDG Scaleout sobre AWS) funciona de manera óptima para grandes volúmenes de ingestión y análisis en tiempo real, además de ser conceptualmente sencilla al ser dos tecnologías basadas en Orientación a Objetos y poder utilizar IDL para definir los mismos.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Esta web utiliza cookies, puedes ver la política de cookies aquí.    Más información
Privacidad