Comparativa solución Edge Sofia2 – AWS IoT

Diagrama01

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.

Diagrama01

 

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

Diagrama01.jpg

 

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.

 

Diagrama01.jpg

 

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).

Diagrama01

 

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.

Diagrama01

 

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.

Diagrama01.jpg

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.

Diagrama01.jpg

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…

Diagrama01

 

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:

Diagrama01.jpg

 

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:

Diagrama01

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.

Diagrama01.jpg

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.

 

Comparativa solución Edge Sofia2 – AWS IoT

Actualizada Guía de primeros pasos con Sofia2

Se ha actualizado la Guía de primeros pasos con Sofia2, descargable desde la sección de descargas para desarrolladores de sofia2.com http://sofia2.com/desarrollador.html

En esta nueva guía, orientada a desarrolladores sin experiencia en la plataforma Sofia2,  se ilustra paso a paso y con un ejemplo de principio a fin, todo el flujo de trabajo IoT con Sofia2:

flujo

De manera que cualquier usuario que siga esta guía a modo de taller, podrá empezar a trabajar con la plataforma, adquiriendo sobre la marcha el conocimiento básico para:

  • Crear una ontologia donde almacenar las entidades de su aplicación
  • Crear un ThinKP (aplicación) y conectarlo al IoT Broker de Sofia2 para enviar datos a la plataforma.
  • Crear un dashboard en el que representar las datos que envia su ThinKP.
  • Crear una regla de negocio en la plataforma, activada por los datos de su ThinKP.
  • Exponer los datos que su ThinKP envia a su ontologia como un API REST a través del API Manager.

Tras finalizar la guía, el desarrollador habrá adquirido un aprendizaje de la plataforma, que le permitirá comprender muchos de los conceptos y le servirán como base para realizar desarrollos mas complejos y profundizar en el uso de las capacidades avanzadas de Sofia2.

Actualizada Guía de primeros pasos con Sofia2

Despliegue remoto de flujos en Node-RED con Sofia2

Como ya hemos comentado en otros posts, Node-RED es una herramienta visual que proporciona un motor de flujos ligero capaz de ejecutarse en dispositivos de capacidades reducidas, como puede ser una Raspberry Pi.

En este post vamos a mostrar cómo es posible editar de forma centralizada, en la consola de administración de Sofia2, flujos Node-RED, que posteriormente se desplegaran de forma remota en dispositivos. Como dispositivo de ejemplo y de video demostrador utilizaremos una Raspberry Pi modelo A.

El despliegue remoto de flujos, lo realizará en el dispositivo, un ThinKP bastante ligero, cuya misión será, a través del protocolo de mensajería SSAP de Sofia2, recibir nuevos flujos editados en la plataforma y desplegarlos en la instancia de Node-RED local del dispositivo.

image001

Seguir leyendo “Despliegue remoto de flujos en Node-RED con Sofia2”

Despliegue remoto de flujos en Node-RED con Sofia2

¿Qué es Node-RED?

Node-RED es un motor de flujos con enfoque IoT, que permite definir gráficamente flujos de servicios, a través de protocolos estándares como REST, MQTT, Websocket, AMQP… ademas de ofrecer integración con apis de terceros, tales como Twitter, Facebook, Yahoo!…

Se trata de una herramienta visual muy ligera, programada en NodeJS y que puede ejecutarse desde en dispositivos tan limitados como una Raspberry, hasta en plataformas complejas como IBM Bluemix, Azure IoT o Sofia2 Platform.

Seguir leyendo “¿Qué es Node-RED?”

¿Qué es Node-RED?

Kit de soluciones Smartcity Sofia2-Libelium

Sofia2 es una de las plataformas elegidas por Libelium para, a través de su marketplace, comercializar soluciones IoT en el ámbito SmartCities

La solución base (https://www.the-iot-marketplace.com/libelium-sofia2-solution-kit) se compone de un kit compuesto por un concentrador Meshlium, con el software cliente de Sofia2 instalado de fábrica, así como de un conjunto de dispositivos Plug & Sense! con los que monitorizar distintos parámetros de calidad ambiental, calidad del aire y datos meteorológicos:

Seguir leyendo “Kit de soluciones Smartcity Sofia2-Libelium”

Kit de soluciones Smartcity Sofia2-Libelium

Mejoras en motor de suscripciones

En la Release 3.0 de Sofia2 se han incluido nuevas mejoras en el motor de suscripciones del SIB de Sofia2, para resolver de manera mas eficiente algunas consultas comunes a las que se suscriben las Apps Sofia2. En concreto las consultas de tipo Select * from <ontología> y las de tipo Select [*,[lista_campos]] from <ontología> where <ruta_atributo>=’<valor>’

Esta optimización cobra importancia cuando hay un gran número de Apps Sofia2 suscritas a una misma ontología:

  • Select * from <ontología>: Cuando muchas Apps están suscritos al mismo evento, Por ejemplo una misma Alarma que tiene que ser notificada en tiempo real a cientos de Apps.
  • Select [*,[lista_campos]] from <ontología> where <ruta_atributo>=’<valor>’: Cuando una misma ontología es utilizada por cientos de Apps, pero determinados eventos solo tienen que notificarse a uno o solo un grupo reducido de Apps. Por ejemplo en una ontología de comandado.

Seguir leyendo “Mejoras en motor de suscripciones”

Mejoras en motor de suscripciones