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

50 Real IoT success stories after ten years of experience in the market

Smart Cities

Libelium presents a white paper with 50 real IoT success stories after ten years of experience in the market

With the aim to unveil its horizontal approach to the IoT market, Libelium has launched a new white paper to present 50 real smart projects deployed in 120 countries all over the world. The IoT company has summarized its most successful and appealing stories, developed with Libelium technology and its partners ecosystem, for the main verticals of the market. The white paper includes real IoT projects for environment care, water management, precision agriculture, smart cities, parking management, smart building, smart factory, logistics, retail and eHealth.

Libelium’s experience and soundness, with real solutions developed in more than 120 countries with an ecosystem of more than 90 technological companies, have labeled it as one of the market leaders. Alicia Asín, Libelium CEO, and David Gascón, Libelium CTO, analyse in the white paper the position of the company and the short-term trends and challenges that have arisen in the market.

Libelium is recognized in the IoT market to offer the most horizontal and interoperable platform allowing system integrators, software companies and Cloud servers to make compatible its sensor wireless network to more than 40 cloud platforms. “Customers escape from those who try to retain them with vendor lock-in strategies. Transparency has become indispensable for a market that is constantly in motion ”, states Alicia Asín, CEO of Libelium.

50 Real IoT success stories after ten years of experience in the market

Industrial Shields: PLCs basados en Arduino

Industrial Shields es una empresa que nace en 2012 con el objetivo de crear equipos PLCs industriales más flexibles y más baratos, por lo que apostaron por crear una solución basada en Open Hardware (Arduino, Raspberry,…).

Entre sus productos destacan los PLCS construidos sobre Arduino, que se ofrecen en 2 gamas: Gama 20 IOs y Ethernet PLC, que se diferencian fundamentalmente en el número de entradas y saldias y en el soporte Ethernet.

La gama de entrada ofrece:

En la gama Ethernet tenemos PLCs desde:

El precio varía en función del número de entradas y salidas:

Los productos se fabrican y ensamblan en España.

Más aquí.

Industrial Shields: PLCs basados en Arduino

IoT y la agricultura de precisión

La agricultura de precisión es una técnica de cultivo y gestión agrícola, que se apoya en el uso de tecnologías de la información para obtener el máximo rendimiento de cada parcela. Gracias a la aparición de nuevos sensores y actuadores y al abaratamiento de estos, ha surgido la oportunidad de conectarlos a internet, dotarlos de un backend de soporte a la toma de decisiones tanto en tiempo real como en batch y hacerlos interoperar como un único sistema integrado.

Mediante la recogida de datos del suelo, condiciones atmosféricas, monitorización del estado de los cultivos y rendimiento de las cosechas, realiza la analítica necesaria, para tomar decisiones sobre qué acciones tomar en cada momento del cultivo, desde la preparación del suelo para la siembra, hasta la cosecha.

Una tecnología fundamental para la agricultura de precisión es el GPS. La primera aplicación de este en agricultura fue para guiar y posicionar maquinaria agrícola, lo que permite:

  • Minimizar el impacto de la compactación del terreno al guiar la maquinaria siempre por las mismas rodaduras.
  • En terrenos irregulares evitar sobrecultivar y sobredifuminar químicos.
  • Alinear con exactitud las plantaciones de árboles.
  • Seguir las tareas de los empleados así como el uso que estos dan a la maquinaria.

Posteriormente el GPS se está utilizando para georeferenciar datos de muestras obtenidas y tras su análisis, elaborar mapas geográficos de acciones a aplicar.

Los principales beneficios de la agricultura de precisión son:

  • Maximización del rendimiento de cada parcela,
  • Minimización y uso óptimo del fertilizantes y pesticidas
  • Reducción del consumo de agua y de energía, así como de los residuos generados
  • Mejora de la trazabilidad alimentaria

En la agricultura de precisión existen fundamentalmente 3 tipos de análisis, cada uno relacionado con una fase en el ciclo del cultivo.

  1. Análisis de suelo: Consiste en medir las características del suelo de cultivo, para identificar que cultivos y variedades son adecuados al suelo y que carencias tienen que ser complementadas mediante fertilizantes. Se lleva a cabo en la fase previa a la siembra
  2. Análisis de cultivos: Consiste en la monitorización de los cultivos y los factores que afectan y favorecen el óptimo desarrollo de la planta, se monitorizan aspectos tales como crecimiento de la planta, grado de coloración, tiempo atmosférico, detección de plagas. Se aplica en la fase de crecimiento y maduración.
  3. Análisis de cosechas: Consiste en la monitorización de la cantidad y calidad del producto cosechado en cada zona. Permite medir el resultado de las técnicas aplicadas en fases previas, ayudando a tomar decisiones sobre futuros cultivos y tratamientos. Se aplica en la fase de recolección.

Veamos cada una de ellas:

Análisis de suelo

El análisis de suelo permite elaborar mapas con las características de los terrenos de cultivo. Para ello se toman muestras georeferenciadas que permiten conocer los niveles acidez, nitrógeno, fosforo, potasio… A partir de estas muestras se elaboran mapas que permiten identificar que cultivo o variedad es más adecuado para cada terreno, así como elaborar planes de fertilización óptimos.

Hasta ahora, el principal problema de estas técnicas es el coste de la recogida y análisis de muestras, ya que tradicionalmente se ha hecho de forma manual, tomando muestras individuales, que se envían a un laboratorio. Esta circunstancia deriva en que la cantidad de muestras por unidad de superficie es baja, por lo que la calidad de los mapas de características del suelo es relativamente pobre. Sin embargo, la aparición de sensores de tamaño relativamente pequeño y su reducción en coste, es cada vez más posible incorporarlos en la maquinaria agrícola y poder realizar el análisis sobre el terreno, lo que unido al GPS, permite elaborar anualmente mapas de calidad con un grado de muestreo muy alto.

Análisis de cultivos

El análisis de cultivos persigue el correcto desarrollo de las planta. Combina:

  • Técnicas de detección temprana de plagas. Permite localizar focos de plagas, como hongos o insectos, en su fase inicial, disparando alertas y elaborando planes de fumigación a medida por zonas. Esto favorece un uso óptimo de los pesticidas, reduciendo su uso.
  • Técnicas de humedad de suelo optimizando los sistemas de riego.
  • Técnicas de medición de niveles de clorofila a través de la monitorización de la coloración. Favoreciendo un uso óptimo de fertilizantes.

Análisis de cosechas

La mayoría de las máquinas cosechadoras modernas (cosechadoras de cereal, máquinas vendimiadoras…) están provistas de sensores que miden el flujo de producto cosechado en tiempo real, lo que combinado con la georeferenciación GPS permite la elaboración de mapas de producción para:

  • Identificar que parcelas no están alcanzando su potencial, que combinado con la información de las actuaciones llevas a cabo en dichas parcelas, puede llevar a la identificación de las causas.
  • Medir el resultado de determinados experimentos en cuanto a técnicas de cultivo o nuevas semillas y plantas modificadas genéticamente.
  • Consensuar con compañías aseguradoras el importe de las indemnizaciones por daños meteorológicos.
  • Medir el grado de cumplimiento de los programas de subvenciones.

Los siguientes pasos en la agricultura de precisión, vienen marcados por la gestión de los datos agrícolas y la aplicación de Big Data. En este sentido, encontramos iniciativas como la de la Open Ag Data Alliance (http://openag.io/), para definir estándares de gestión de datos agrícolas e interfaces para su tratamiento e intercambio. La visión de la Open Ag Data Alliance se resume en el siguiente ejemplo:

The OADA vision is best explained through an example. Consider the common use case of prescription maps. Frank is a farmer with a corn planter capable of varying seed population based on GPS location using a prescription map: i.e., under the irrigator seeds should be closer together and outside the irrigator they should be farther apart because there is less water to go around.

Andy, a local agronomist, has worked with Frank for years. Andy offers to create a custom prescription map for some of Frank’s fields. To do this, Andy says he needs the past three years of yield data, recent soil tests, as-applied fertilizer maps, outlines of Frank’s irrigator pivot coverage area, and info on the type of corn variety that Frank intends to plant in each field. Andy loads Frank’s data into an existing software package, generates a prescription map that works with Frank’s planter monitor, and gets the map to Frank before planting begins.

image0011

image0021

IoT y la agricultura de precisión

Knoema Atlas mundial de datos

Knoema ofrece en su World Data Atlas, un repositorio de fuentes de datos, series temporales, visualizaciones, estadísticas, …. sobre diversos temas (energía, salud, agricultura,…) organizados por país.

La información viene de organismos internacionales y puede exportarse en diversos formatos.

Por ejemplo en España disponemos de información económica, demográfica, energía, uso de la tierra, transporte, agricultura, salud, telecomunicaciones, educación, defensa, comercio exterior, turismo, pobreza, seguridad, medio ambiente, agua,…

Seleccionando una fuente de datos vemos un completo gráfico:

También nos permite comparar con otros países:

Explorar los datos:

O Visualizarlo en un mapa:

Además de exportarlo en diversos formatos:

Sin duda una fuente muy interesante para completar nuestros análisis.

También podemos acceder a esta información desde la aplicación de Google Chrome World Data Atlas

Knoema Atlas mundial de datos