IDC Technology Spotlight: The Power of the Platform in Smart Cities

La lectura de este spotlight de IDC:

me ha hecho recordar los retos a los que nos enfrentamos cada vez que nuestra Plataforma Sofia2 a través de su personalización Indra Sofia2 Smart City Platform se implanta en una ciudad.

El autor explica y justifica la importancia de una Plataforma Smart City en el contexto de una ciudad inteligente:

La misión de una Smart City es la transformación digital enfocada a conseguir mejorar el desarrollo económico, la sostenibilidad y la operación de la ciudad y la mejorar de la calidad de vida de los residentes.

Las tecnologías emergentes son fundamentales para conseguir estos resultados, concretamente las ciudades inteligentes deben aprovechar los datos de los dispositivos, redes, infraestructura, aplicaciones para desarrollar nuevos conocimientos y nuevos productos y servicios.

Las plataformas Smart Cities son un mecanismo clave para integrar tecnologías, habilitar el desarrollo rápido de nuevas aplicaciones y crear un ecosistema conectado.

Qué es una Plataforma Smart City

Una plataforma Smart City tiene como propósito obtener mejoras a nivel ambiental, social y financiero para la ciudad.

Típicamente estas plataformas son Plataformas IoT evolucionadas y con mayor sofisticación para cumplir con los desafíos de una ciudad.

Estas plataformas aún se encuentran en una fase inicial de despliegue en organizaciones gubernamentales.

Simplificando, podríamos decir que una Plataforma Smart City es una solución que conecta dispositivos, y recogen, combinan y gestionan datos de los diferentes dominios y proveedores de servicios e la ciudad para suministrar una vista unificada de la ciudad. Esta visión holística ofrece nuevas perspectivas a los departamentos de la ciudad e incluso a terceras partes y proveen gestión y control mejorado de estos departamentos además de un mayor conocimiento de las necesidades de nuevos productos y servicios en la ciudad.

Además de esta funcionalidad básica estas plataformas se utilizan para desarrollar rápidamente nuevas soluciones, ya sea dentro de la organización o a través de un ecosistema de proveedores tales como especialistas verticales y proveedores locales. Este es un aspecto fundamental de las plataformas Smart City ya que la variedad de sistemas legacy y SCADA en funcionamiento en los diferentes departamentos y la variedad de silos como sistemas de transporte, agua, energía son barreras que hay que resolver para conseguir convertir estos silos en un ecosistema integrado e inteligente de soluciones.

Como vemos, las plataformas Smart City cumplen muchas tareas. Los datos de sensores y dispositivos son abrumadores, debido a su volumen, métodos de conectividad, formato de datos y frecuencia. La capacidad de manejar estos datos no es nativa a las plataformas tradicionales TI, la mejor forma de estandarizar y hacer frente a todos los datos, de conectar billones de objetos no conectados es tener una plataforma Smart City con un software robusto, capaz de escalar y dar el rendimiento necesario para capturar y analizar diversas fuentes de datos y formatos.

Además la plataforma debe ser flexible para permitir una integración relativamente fácil con otras aplicaciones empresariales y estar totalmente integrado con el resto de la infraestructura de TI.

Componentes de una Plataforma Smart City

Aunque la arquitectura de una plataforma Smart City varía entre vendedores existen un conjunto de componentes core de un sistema de este tipo:

· Gestión de Dispositivos: que permita que un endpoint envíe y reciba datos, peor también la provisión de endpoints, configuración remota, monitorización de datos, actualización de software, reporte de errores,…

· Gestión de conectividad: asegurando flujos de datos desde el edge hacia el cloud, todo esto gestionado y asegurado. La comunicación suele ser IP con comunicación bidireccional entre los endpoints y la plataforma por protocolos como MQTT y REST. Para despliegues basados en conectividad móvil varios vendedores ofrecen gestión de SIMs, incluído el billing. Son típicos los partnerships entre plataformas IoT y plataformas M2M para conseguir una gestión completa de la conectividad.

· Gestión del dato: es la característica más importante de las plataofrmas Smart City. Los datos son procesados y analizados a través de un “motor de reglas” que extrae datos relevantes en función de unos parámetros o reglas de negocio. Algunas plataformas ofrecen herramientas de analítica avanzada que permiten mapear datos contra un modelo predictivo. Estas capacidades a través de Machine Learning y herramientas de analítica predictiva son cada vez más importantes, aunque no sea una característica de las plataformas IoT actuales.

· Herramientas de visualización y cuadros de mando: que se pueden personalizar con la disponibilidad de widgets, pueden generar informesresúmenes de los datos IoT, pueden activar eventos y enviar notificaciones a los usuarios finales.

· Habilitadores para desarrollar aplicaciones: se soportan a través de APIs y herramientas y permite que terceros, como desarrolladores de aplicaciones, integradores de sistemas, proveedores de SaaS puedan interactuar con la plataforma. Actualmente pocos proveedores proporcionar herramientas para el desarrollo rápido de aplicaciones como parte de su plataforma.

¿Cómo puede ayudar una plataforma Smart City a resolver los grandes desafíos urbanos?

Las ciudades de todo el mundo se enfrentan a los mismos desafíos debido al crecimiento y envejecimiento de las poblaciones, a la creciente preocupación por el cambio climático y las innovaciones tecnológicas que han cambiando las expectativas de los ciudadanos de servicios gubernamentales personalizados y móviles.

Abordar estos desafíos se hace más difícil por cuestiones como el envejecimiento de las infraestructuras físicas, limitaciones de presupuesto, aumento del consumo de agua y energía, nuevas regulaciones de sostenibilidad.

Parece imposible que una plataforma Smart City pueda abordar estos complejos desafíos, pero de hecho una plataforma Smart City ayuda a ubicar los servicios de la ciudad en un contexto transformador más amplio.

Si entendemos una Smart City como un Sistema de Sistemas, lo fundamental es el ecosistema, donde los sistemas están interconectados y un sistema impacta al resto: por ejemplo si la red eléctrica se cae, se reduce el suministro de auga o se cortan las carreteras, el efecto afecta a toda una zona urbana y puede paralizar las operaciones en empresas y escuelas, afectar a la seguridad,… A la inversa, si estos sistemas están coordinados proactivamente los beneficios afectan a toda la ciudad. Las capacidades de las Plataformas Smart City para simular comportamientos y desplegar aplicaciones en la plataforma permite crear nuevos servicios muy rápidamente como aplicaciones móviles para turistas, o farolas que pueden disparar cámaras de vídeo en caso de emergencia.

En este contexto, el éxito de las plataformas Smart City depende en gran medida de que atraigan y nutran a desarrolladores de aplicaciones, integradores y sistemas y otras compañías IT para construir soluciones de valor añadido y diferenciales sobre la plataforma. La apertura de la plataforma es un eje fundamental para que el modelo colaborativo funcione. Las Plataformas deben ofrecer APIS y herramientas abiertas y extensibles y usar estándares de la industria.

Aproximaciones: Enfoque táctico vs estratégico

Al diseñar un enfoque de Plataforma Smart City la interoperabilidad entre sistema debe ser una prioridad estratégica.

Los enfoques para el despliegue de la plataforma van desde los más tácticos (usar la plataforma para la implementación de soluciones puntuales) a los más estratégicos (comenzando con pequeños proyectos selectos como componentes de un sistema holístico que está siendo diseñado para impulsar los resultados de toda la ciudad).

Las ciudades a menudo comienzan con un enfoque táctico porque es más barato en el corto plazo y soluciona rápidamente un problema específico. Las soluciones resultantes dejan poca oportunidad para reutilizar los componentes para otras aplicaciones y producen una plataforma de silos con datos no integrados, lo que puede provocar mayores costos de transmisión de datos, almacenamiento y administración, sin capacidad para reutilizar código y compartir esfuerzos de desarrollo a través de soluciones.

Un enfoque estratégico considera los distintos proyectos como parte de un sistema unificado en desarrollo y despliega la Plataforma para uso en proyectos, departamentos, sistemas y ofertas de terceros. El código se comparte para casos de uso común, los recursos de desarrollo de software se centran en la creación de alto valor añadido y la lógica empresarial de aplicaciones y las soluciones están diseñadas para aprovechar las inversiones de TI existentes, además permite un prototipado más rápido y la implementación de soluciones a escala.

Leer más

IDC Technology Spotlight: The Power of the Platform in Smart Cities

Gartner Report: Use Open Source to Jump-Start IoT Projects and Make IoT Vendor Decisions

En este nuevo informe Gartner:

Peter Havart-Simkin nos cuenta cómo el Open-Source IoT puede ayudarnos a abordar los nuevos retos que plantea IoT.

Y recomienda a los líderes técnicos de proyectos IoT entre otras, adoptar productos IoT de código abierto para impulsar el desarrollo de soluciones IoT y evaluar su uso en la producción IoT sistemas comerciales.

Siguiendo el modelo de referencia que usa Gartner para soluciones de negocio (Reference Model for IoT Business Solutions) Peter enumera algunas soluciones open-source en cada una de las capas.

Es un orgullo para nosotros aparecer como una de las IoT Platfom Hub open-source, ya que desde el arranque de nuestra plataforma hemos apostado por el open-source, tanto desde las piezas sobre las que construimos la plataforma como a la hora de ofrecer una versión open-source de la plataforma (Sofia2 Community Edition) y un entorno Cloud sin coste ni limitaciones (Sofia2 CloudLab).

Entre las piezas open-source sobre las que construimos la plataforma tenemos:

  • Moquette Broker como Broker MQTT
  • Spring y todo su ecosistema como framework de desarrollo principal de la plataforma (IoT Broker,…
  • JQuery, Thymeleaf, AngularJS, Bootstrap como tecnologías para construir el Control Panel
  • Hazelcast como DataGrid en memoria
  • Node-red como motor de flujos
  • Siddhi CEP como motor CEP
  • MongoDB, CouchDB, ElasticSearch, HBase, HIVE, Impala,… como motores de persistencia y consulta
  • Apache Zeppelin como motor de nuestros Notebooks
  • StreamSets como motor de DataFlow
  • Quasar como motor analítico SQL para MongoDB
  • Apache Drill como motor DataLink
  • Spark como motor de procesamiento en streaming

 

Otra reflexión interesante del informe es las consideraciones que debemos hacer a la hora de elegir software open-source, como:

  • Madurez: como de maduro es el proyecto IoT? Aparte de pilotos tiene proyectos en producción?
  • Rendimiento y estabilidad: puede el proyecto soportar los números estimados?
  • Estabilidad del vendor: puedo confiar en la empresa que hay detrás de este software?
  • Servicios de soporte: la empresa que está detrás podrá darme el soporte end-to-end?. Cuántos desarrolladores hay detrás? Tiempos de respuesta? Ofrecen soporte commercial?
  • Documentación: como forma de garantizar que los desarrolladores y usuarios podrán trabajar con esta

 

Gartner Report: Use Open Source to Jump-Start IoT Projects and Make IoT Vendor Decisions

Sofia2 as a technological base in the European R&D project eVacuate

eVACUATE-LOGOSOlo

 

As we mentioned in the previous post, Sofia2 IoT Platform has promoted the development of high added value solutions in customers in areas such as Smart Cities, Smart Health, Industry, Retail, Energy …

 

Sofia2InfografiaRecortada

 

One of the projects which Sofia2 serves as a technological base is eVacuate, a European innovation project whose aim is the development of a simulation and emergency management system based on IoT and Big Data technologies to define in real time the optimal routes of evacuation in large infrastructures.

 

eVACUATE-LOGO

During the last months four pilots have been carried out in which the feasibility of the project has been demonstrated and the possibility of scaling in a great number of scenarios.

 

The first evacuation exercise was held last October at Anoeta football stadium. 27 researchers from different European companies and universities were working in San Sebastián defining in real time the optimal evacuation routes for a football match in Anoeta. To do this, a good number of fans were gathered and they were asked to be placed in the main tribune. From that moment, they followed workers instructions and they lived in situ up to four types of different evacuation situations. The announcements of public address, signage, opening of doors and emergency situations varied with the aim of creating four completely different cases.

 

Here you have the video with the images and all the detailed information of the pilot in Anoeta.

 

Athens airport, a cruise ship of the company STX on French coast and finally, last May, Bilbao’s Subway, were the other scenarios in which eVacuate demonstrated its effectiveness. In all cases it was possible to reduce the evacuation time by more than 25% compared to the current evacuation systems.

 

Sofia2 as a technological base in the European R&D project eVacuate

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

Guía de Plataformas IoT según Gartner

En este informe de Gartner creado por Alfonso Velosa, Yefm V. Natis, Benoit J. Lheureux y Eric Goodness

Se dan un conjunto de recomendaciones cara a elegir una plataforma IoT, destaco lo que me ha parecido más importante:

Puntos clave:

  • Existen cientos de pequeñas y grandes empresas que ofrecen plataformas IoT y tecnologías relacionadas, donde además el marketing de cada uno hace que sea complejo la selección.
  • Ningún proveedor tiene a día de hoy una solución completa de Plataforma IoT, lo que obliga a que las empresas tengan que implementar soluciones a partir de múltiples proveedores, lo que les obligará a largo plazo a integrar.

Recomendaciones para los CIO/CTOS o responsables de TI:

  • Debido a que muchos proyectos iniciales de IoT se lanzan desde las unidades de negocio, el enfoque inicial de TI debe centrarse en la adquisición de conocimientos. Por tanto, los responsables de TI deben formar un pequeño y flexible equipo TI especializado en IoT (con representación de negocio, si es posible) que se familiarice con los proveedores de plataformas IoT existentes y sus soluciones.
  • Establecer una arquitectura a corto plazo para unificar los proyectos IoT existentes de las unidades de negocio con los sistemas empresariales existentes, equilibrando los elementos basados en Cloud con los elementos On Premise y las inversiones.
  • A largo plazo el responsable TI debe pensar en una arquitectura para soluciones de negocio IoT extremo a extremo.
  • Examinar las plataformas IoT candidatas para la organización:

A corto plazo, en función del precio y las capacidades para resolver los requisitos de proyectos específicos

A largo plazo en base a la escalabilidad y la alineación a una arquitectura global IoT.

  • Debe estar para asimilar que los productos, estrategias y mapas de ruta evolucionarán rápidamente en este mercado.
  • Debe prepararse para configurar, ampliar y personalizar una plataforma IoT para cumplir con las necesidades propias del proyecto e integrarlo en otras soluciones.

Capacidades de una Plataforma IoT:

Una Plataforma IoT es software bien en Premise , bien un Servicio Cloud (PaaS) que supervisa y gestiona diversos tipos de endpoints, a menudo a través de aplicaciones que se desarrollan sobre la plataforma.

La mayoría de las plataformas IoT son clave para construir aplicaciones de negocio.

Una plataforma IoT generalmente incorpora soluciones que involucran endpoints IoT (sensores), Gateways IoT y aplicaciones empresariales back-end.

La plataforma tiene la capacidad de:

– supervisar los flujos de eventos IoT,

– permitir la agregación de datos,

– análisis especializados

– desarrollo de aplicaciones

– integración con sistemas y servicios TI de back-end

Las capacidades de una plataforma IoT incluyen:

  • Aprovisionamiento y administración de endpoints IoT (Things) y Gateways IoT
  • Personalización y construcción de aplicaciones (incluyendo SDK, IDE, AppServer,…)
  • Procesamiento de eventos: flujo de eventos y agregación de datos, streaming analytics, almacenamiento y gestión de la información
  • Toma de decisiones: motores de reglas, orquestación de flujos de trabajo y proceso de negocio (BPM)
  • Análisis: Análisis y visualización de datos IOT (incluyendo cuadros de mando)
  • Ciberseguridad: autenticación, encriptación, gestión de certificados,…
  • Comunicaciones con dispositivos IoT (capa física como WIFI y capa de datos, como MQTT o HTTP)
  • Integración: publicación y suscripción de APIs, transformaciones, adaptadores,… para conectar con aplicaciones empresariales y fuentes de datos, servicios en la nube, aplicaciones móviles, legacy,…
  • Adaptadores
  • Interfaces de usuario, tanto para usuarios finales como para desarrolladores

Leer más

Guía de Plataformas IoT según Gartner

“Big Data and real time analytics in the IoT” Webinar

webinar

 

 

On June 21, our partner Raquel López, IoT Expert Manager of Sofia2 IoT Platform, conducted a webinar titled “Big Data and real time analytics in the IoT” in the framework of the IoT Analytics conference organized by BrightTALK.

 

In the presentation, which you can access here, Raquel explains why IoT is an excellent business opportunity and addresses various IoT Analytics cases existing in different verticals: Industry, Retail, Health, Energy…

 

It also delves into capabilities, workflow and modules that make up an IoT platform and Big Data such as Sofia2 and delves into two success stories: Smart Energy and Traceability in Distribution.

 

energy

 

You can find the Webinar slides here

“Big Data and real time analytics in the IoT” Webinar

IoT Technologies and its support in Sofia2

p1

IoT technologies make it easy to connect all kinds of things to the network and develop applications to control and manage these “things”. All the complexities of enabling connectivity, services, and deployment for these devices is the task of the IoT platform.

An IoT platform ensures integration with different hardware devices supporting a wide range of communication protocols. Through the integration interfaces provided by the platform, you can also manage the IoT data collected to specific systems for data visualization, data storage, as well as transmitting data to connected devices (configuration, notifications) or between them (controls, events ).

IoT platforms are also known as IoT Middleware, which underlines its functional role as mediator between hardware and application layers.

Let’s see an IoT flow and the components involved:

p1.PNG

Sofia2 supports each and every one of the modules in the previous diagram as follows:

 Things

         Generic IoT Platform                                  Sofia2 IoT Platform

p2                 thingssofia2

We understand Things as any device that is capable of sending data, whether sensors, surveillance cameras, robotic arms, Smart watch … Some of the devices supported by Sofia2 are:

  • Devices:
    • Opening and closing doors sensor : CLIMAX, Leedarson, Nyce, Wulian, Centralite.
    • Environmental thermometer: Several manufactures
    • Pulsoximetros: several manufactures using IEEE protocol
  • Smart Home: presence sensor: CLIMAX, Leedarson, Nyce, Wulian, Centralite, DEVELCO.
  • Smart Building: Smart Plug: Meazon, 4-Noks
  • Smart Retail:
    • Thermostat: 4-Noks, Centralite
    • IP Camera: D-LINK, Panasonic
    • Temperature and humidity sensor: Wulian, Centralite, Leedarson
    • Smoke and gas sensor: CLIMAX, DEVELCO, Leedarson, Wulian
    • Flood sensor: Centralite, CLIMAX, DEVELCO, Wulian
    • Light sensor: Leedarson
    • Smoke Listener: Centralite
    • Siren: Metalligence, Wulian
    • LED illumination: LG, Leedarson
    • Switches: CLIMAX, Centralite
    • Thermostatic valve: CLIMAX
    • Weather station: Adafruit sensors
    • Beacon: Indra, Estimote
    • Panic button: CLIMAX, Centralite
    • Smart Meters: Several manufactures
  • Smart Cities: Environmental humidity sensor: several manufactures
  • Smart Traffic: Sensor power consumption: several manufactures
  • Smart Agro: Flowmeter: several manufactures
  • Smart Tourism:
    • Tensiometer: several manufactures
    • Potentiometer: several manufactures
    • Smart metering: several manufactures
    • Traffic ligth: Cross
    • Intelligent lighting: UVAX, LUIX
    • Libelium sensors
      • Air Quality
      • Atmospheric pressure
      • Temperature
      • Humidity
      • Luminosity
      • Waspmote internal temperature, batterty level, accelerometer
  • Smart Health: scales, several manufactures using IEEE protocol
  • Smart Insurance:
    • Tensiometers: several manufactures using IEEE protocol
    • Thermometer: Fora
    • Glucometer: Fora
    • Nociceptor: several manufactures
    • Anesthesia tower: Drager, General Electric
    • Pressure sensor in bed
    • Fall sensor
    • SmartBand: Withings
  • Otros:
    • Quadrirotor/Drone: Indra, 3DRobotics, Microsoft IPCam
    • Rover/Drone: Indra
    • Raspberry Pi: Indra
    • ARduino

In addition to supporting the data collection of all these devices, Sofia2 also allows the ingestion of data from other types of sources, such as RRSS, APIs and general files:

dispositivossofia2people

Conectivity

Generic IoT Platform        Sofia2 IoT Platform

p3.PNG    Comunicacion Sofia2

Sofia2 is agnostic of the communications, with implementations in multiple protocols of light communication (REST, OPC, MODBUS,  WebSockets, MQTT, WS, JMS, AMQP…)

In addition, among others, the gateways supported by Sofia2 are:

gatewayssofia21

Services and Cloud

 Generic IoT Platform                                   Sofia2 IoT Platform

p4.PNGServiciosycloudSofia2

In the platform Sofia2 the following elementary concepts are defined:

smart space sofia2

SmartSpace

It is the collaborative universe of systems and/or devices (ThinKPs) that exchange information between them. The core of a Smart Space is the SIB (Semantic Information Broker):

SIB: It is the core of the Smart Space, acts as an element of integration of the information exchanged by the devices. There may be several in a Smart Space.

ThinKP: Each of the systems and / or applications that interoperate in the Smart Space through the SIB must be defined as ThinKP in the same. The ThinKP is an element deployed in the Smart Space that can consume and/or produce information.

Ontology: Semantic atomic element with which to model the different information systems that interoperate in the Smart Space domain.

Ontologies are semantic descriptions of a set of classes. In this way, applications that share classes (usually called concepts) of the same ontology, can exchange information through concrete instances of these common classes.

In Sofia2, these ontologies are represented in JSON-Schema format that defines and validates them.

In terms of data storage in Sofia2 we distinguish between:

databases

For each ontology can be configured a time window from which the information is considered ‘historical’.

The information remains in this database until it is automatically migrated to the historical information repository.

The stored information will be available as data source for the different modules of the platform: Integration, Machine Learning, APIManager.

Sofia2 has an API Manager with the following capabilities:

Sofia2ApiManager

Apps and Analytics

Generic IoT Platform                             Sofia2 IoT Platform

p5   AppsyAnalyticsSofia2

In sofia2/console we will find the user interface and experimentation environment with all the capabilities of the platform. In it we can not only create Ontologies to model our data, ThinKPs or ingest data files or RRSS, but also we can create rules (SCRIPTS) to process all this information in the way we are most interested, to visualize this data in Gadgets and Dashboards Or publish ontologies via API. We also have Analytics modules that will allow us to create pipelines and notebooks, or create Machine Learning flows:

ML

To conclude, here we can see the architecture of the platform Sofia2:

ArquitecturaSofia2

As well as an overview of the Sofia2 components:

flujo general Sofia2

IoT Technologies and its support in Sofia2