En una arquitectura IoT, una de las capas fundamentales es la de dispositivos, ya que una gran parte (si no toda, dependiendo del caso concreto) de la captación de información se realiza en dicha capa.

 

Por lo que dentro de la estrategia de cualquier plataforma IoT, disponer de cierta capacidad de procesamiento en los dispositivos, lo que viene denominándose computación en edge, es importante por ciertas razones. Por citar algunas:

 

• Funcionamiento off-line en casos de perdida de conexión con la plataforma.
• Realizar en campo una primera agregación y filtrado de los datos, antes de enviarlos a plataforma.
• Necesidad de velocidad de respuesta en tiempo real sin latencias de red, para acciones que no necesiten de intervención de alto nivel desde plataforma.

 

Es por esto, que una plataforma IoT no está completa si no proporciona a los desarrolladores unas APIs y marco de trabajo que faciliten el desarrollo de aplicaciones en los dispositivos o concentradores.

 

En los últimos años, han surgido placas comerciales como Raspberry-PI, Beagle Bone, ODroid… que por 50€ proporcionan dispositivos con capacidades de procesamiento suficientes para ejecutar lógica compleja en Java, Python, Node.js, C/C++…, e interfaces de red y GPIO, que los convierten en el producto ideal para que innovadores, startups o cualquier otro tipo de empresa desarrollen sus propios productos en su propio laboratorio IoT, sin apenas problemas al hacer la transición al tipo de placa que desplegarán en producción ya que existen multitud de fabricantes que construyen sus concentradores y PCs industriales en estas mismas arquitecturas hardware.

 

En este post analizábamos la propuesta que hace Amazon desde AWS IoT para gestionar el procesamiento en Edge. Hoy, vamos a realizar una comparativa con la propuesta desde Sofia2:

 

• APIs de programación en dispositivo: Se trata del nivel de integración de más bajo nivel, donde un dispositivo no tiene por qué ser un Gateway, sino que realiza una conexión directa a plataforma.

 

En AWS IoT  disponemos de las siguientes: Java, Javascript, Python, C, Arduino e IOS.

 

En Sofia2 encontramos APIs de programación para: Java, Javascript, Python, Node.js, C, Arduino, .NET, Android, IOS.

 

En conclusión: Ambas plataformas están bastante alineadas con los principales lenguajes del mercado, incluyendo Sofia2 alguno más, tan importante en el mundo dispositivo como lo es Node.js y en movilidad Android.

 

• Gateways de plataforma: Son el componente de la plataforma que disponibiliza un protocolo de comunicación para que los dispositivos puedan enviar datos a la plataforma. Son especialmente importantes ya que no todos los dispositivos pueden implementar cualquier protocolo, por lo que podrían limitar la conexión a la plataforma para determinados clientes.

 

En AWS IoT el broker de comunicación es exclusivamente MQTT, bien mediante conexión TCP/IP como por HTTP vía Websocket.

 

 

En Sofia2 se dispone de los principales protocolos de comunicación IoT: MQTT, DWR (Ajax Push), REST, Websocket, AMQP.

 

A su vez, en Sofia2 los gateways de comunicación están concebidos como plugins, esto es, módulos arquitectónicamente independientes del resto de la plataforma, lo que permite habilitar en cada instalación solo los necesarios, y facilita la tarea de incluir nuevos protocolos de comunicación, sin tener que modificar nada en la plataforma, en función de necesidades concretas de un cliente (Se han desarrollado gateways específicos para JMS, Webservices o sockets TCP/IP).

 

Asimismo, el API Manager de Sofia2 proporciona otro interfaz para que cualquier dispositivo se pueda conectar con la plataforma, tanto para enviar como para consultar información, en este caso trabajando con APIs REST.

 

En conclusión: El conjunto de protocolos de comunicación para conectar con la plataforma es más completo en Sofia2, proveyendo a los dispositivos de un mayor número o de alternativas, así como de la posibilidad de incluir nuevos protocolos si así lo demanda el proyecto.

 

• Arquitectura edge basada en gateway concentrador: Es el caso en el que un dispositivo dentro de una red local asume el rol de intermediario con la plataforma, coordinando al resto de dispositivos, convirtiéndose en el anfitrión.

 

En AWS IoT la propuesta es Greengrass Core. Como comentábamos en este post se trata de un software que proporciona soporte para:

 

Mensajería MQTT en la red local del conjunto de dispositivos que coordina.

Despliegue desde plataforma y ejecución de funciones AWS Lambda en Python 2.7

Seguridad integrada con AWS IoT.

Gestión de sombras de dispositivo.

Integración con AWS IoT e invocación desde Lamdas a otros servicios AWS.

 

El dispositivo concentrador que ejecute Greengrass Core en un grupo AWS necesita procesador ARM o x86 de 1GHz, 128MB de RAM y SO Linux.

El alta de un grupo, esto es conjunto de dispositivos coordinados por otro, se realiza desde la plataforma, de manera que es posible hacer una gestión remota, así como desplegar/actualizar nuevas funciones Lambda para modificar o reconfigurar el software en campo.

 

En Sofia2 el modelo de gateway propuesto es el KP Modelo, descargable desde la web de sofia2.com.

El KP Modelo es un contenedor software, desarrollado en Java, que proporciona a los desarrolladores un entorno para la ejecución de sus aplicaciones. El KP Modelo de Sofia2, proporciona a los desarrolladores un conjunto de APIs y herramientas, para que solo se tengan que preocupar de programar la lógica de negocio de sus aplicaciones, proporcionando el KP Modelo de manera transparente, toda la infraestructura para gestionar:

 

Conexiones y reconexiones a la plataforma.

Garantía de entrega de mensajes (almacenamiento en local en modo offline y reintentos de envio).

Actualizaciones de software, configuración y reconfiguración desde plataforma.

Monitorización JMX.

 

Dentro del KP Modelo pueden convivir distintas aplicaciones concurrentemente.

 

Las aplicaciones desplegadas en el KP Modelo de Sofia2 son aplicaciones Java, que mediante un patrón event-bus, la implementación de ciertas interfaces codificando la lógica de negocio, y el uso de APIs que abstraen la política de envío de mensajes y reintentos, permiten ejecutar cualquier lógica de negocio y comunicarse con la plataforma Sofia2 en modo bidireccional (envío/notificación).

 

Estas aplicaciones se empaquetan como ficheros .war junto con su configuración y se versionan en la plataforma Sofia2, de manera que se pueden gestionar tanto desde la consola de administración como a través de los servicios REST de administración.

 

Una vez versionado tanto el software como la configuración, la gestión de la configuración de cada KP Modelo físico también se realiza desde la propia plataforma, pudiendo modificar en cualquier momento la versión que se tiene que ejecutar, de manera que KP Modelo físico descargará tanto el software como su configuración, lo desplegará en el contenedor e iniciará su ejecución.

 

A diferencia de AWS Greegrass, el KP Modelo de Sofia2 no proporciona en sí ningún broker de mensajería de MQTT o de cualquier otro tipo para conectar al gateway concentrador el resto de dispositivos. Sino que el broker puede ser desplegado o bien de manera externa y ya una aplicación contenida en el KP Modelo se conecta al broker para recoger los mensajes, o bien como otra aplicación contenida en el KP Modelo, que embebe al propio broker.

 

Esto puede añadir un extra de trabajo, pero da mayor libertad a la hora de elegir otros protocolos, sobre todo protocolos industriales o legados (Modbus, OPC, Zigbee…).

 

Además, independientemente del KP Modelo, aunque se puede utilizar en un modelo hibrido si resultase interesante, Sofia2 ha apostado por Node-RED como motor de ejecución de flujos tanto para la parte plataforma, como para la capa edge.

 

Node-RED tiene un marcado carácter IoT y puede ejecutarse prácticamente en cualquier dispositivo que pueda ejecutar Node.js, permitiendo a los usuarios desarrollar flujos mediante la conexión de nodos, que pueden conectar prácticamente con cualquier cosa, desde un pin GPIO, hasta un bot de Telegram, pasando por brokers MQTT, servidores de correo, servicios REST…

 

Dentro de la apuesta de Sofia2 por Node-RED, se han desarrollado y puesto a disposición de la comunidad de Node-RED un conjunto de nodos que permiten a los dispositivos conectar con la plataforma Sofia2, tanto para enviar, como para consumir información:

 

A la vez que se ha desarrollado la infraestructura necesaria para poder editar los flujos de manera remota desde la consola de administración de Sofia2 y desplegarlos en los dispositivos de forma remota de manera individual o masiva mediante un agente Java muy ligero:

En el siguiente video podéis verlo en mayor detalle: https://www.youtube.com/watch?v=if-B8R_d1cw

 

En conclusión: Ambas plataformas apuestan por realizar una gestión centralizada tanto del software como de su configuración, proveyendo mecanismos de despliegue y reconfiguración remotos.

 

AWS proporciona un runtime muy potente, pero menos abierto al desarrollador edge, con lógica de programación mediante funciones AWS Lamda y de nuevo orientado únicamente al protocolo MQTT. El KP Modelo de Sofia2 deja abierta la elección del protocolo en la red interna de dispositivos y proporciona mayor libertad permitiendo la ejecución de aplicaciones con la complejidad que el desarrollador decida. A su vez la integración de capacidades Node-RED, abre la puerta a que usuarios menos técnicos y más cercanos al negocio, puedan desarrollar aplicaciones de forma visual.

 

En ambos casos se apuesta por Gateways de capacidades muy reducidas con arquitecturas de bajo coste, un procesador ARM con apenas 128MB es suficiente para ambas alternativas.

 

• Arquitectura de plataforma descentralizada: En este caso se trata de una arquitectura de computación en edge más compleja que la lógica en ejecución en un gateway, permitiendo el despliegue en campo de distintos componentes de la plataforma, funcionando de manera federada con la plataforma central. Se trata de un escenario muy útil donde hay que coordinar de manera local e independiente todos los elementos de una fábrica, edificio, planta… pero a la vez es necesario mantener una visión global a nivel de lo que está ocurriendo en toda la organización o empresa, propietaria de dichas fábricas o edificios.

 

Para este escenario solo encontramos una alternativa con Sofia2, que proporciona esta descentralización gracias a la Sofia2 Gateway Edition, se trata de una versión más ligera de Sofia2 que incluye:

 

IoT Broker con todas sus capacidades.

Motor de reglas.

Base de datos de tiempo real.

Opcionalmente Base de datos de configuración local.

 

La Sofia2 Gateway Edition proporciona a cada planta autonomía para procesar todos los eventos que ocurran y ejecutar las reglas asociadas para llevar a cabo las acciones necesarias a nivel de planta y disparar las alertas que dichos eventos pudieran estar provocando, a su vez, los eventos de cada planta se almacenan en su una Base de datos de tiempo real local, lo que permite disponer a nivel de planta de todos los cuadros de mando con indicadores relevantes en la planta. Además, para mayor autonomía se puede optar por desplegar la Base de datos de configuración, de manera local en cada planta, lo que permite trabajar en modo desconectado de la instalación central.

Toda la información de tiempo real y en su caso de configuración de cada despliegue local de la Sofia2 Gateway Edition, se sincroniza en tiempo real con la instalación central de Sofia2. Lo que a su vez permite disponer de una visión global e integrada de toda la empresa, permitiendo construir reglas, procesos y cuadros de mando que agreguen información de los distintos despliegues de la Sofia2 Gateway Edition.

 

A su vez, desde la instalación central se pueden desencadenar acciones en Gateways de planta concretos, de manera que es posible disponer de reglas de más alto nivel, que analizando y evaluando eventos de las distintas plantas, ocasionen actuaciones en una concreta.

 

No es de extrañar que esta edición de Sofia2 esté íntimamente ligada a escenarios Industrial IoT, en los que es necesario gestionar y sincronizar información de distintas plantas, que a su vez han de tener un funcionamiento autónomo.