Aplicabilidad e Importancia de los Digital Twins en el ámbito Smart Cities

En este artículo publicado en el site de documentación de la onesait Platform se explica en detalle el concepto de Digital Twin, su aplicabilidad en el ámbito Smart Cities y cómo se soporta en la onesait Platform:

Aplicabilidad e Importancia de los Digital Twins en el ámbito Smart Cities

Análisis de Plataformas/Servicios IoT Cloud (Sofia2, FIWARE, Azure IoT, Watson IoT y Artik Cloud)

Hace unas semanas llegó a nuestras manos este trabajo Fin de Master en el que su autor, Edison Fabricio, hacía un análisis práctico de 5 plataformas IoT en la nube, entre ellas la nuestra:

El análisis realizado nos parece muy interesante y nos alegra formar parte de este estudio, así que hemos preparado este post, en el que mencionamos los puntos que nos han parecido relevantes del trabajo de Edison. El propio Edison definía el trabajo así:

Este presente trabajo de Fin de Máster busca estudiar los más prometedores servicios en la nube para IoT, tanto públicos y privados, que actualmente existen en el mercado. Se implementará un entorno de pruebas donde un dispositivo embebido enviará constantemente variables de sensores a los servicios en la nube. Al final, de los resultados observados se podrá determinar qué servicios son los más óptimos para IoT y cuáles son los más flexibles para que un desarrollador pueda construir sus aplicaciones.”

A lo largo del documento se analiza el estado del arte de IoT, se definen las capas de una arquitectura IoT, se relaciona IoT con Cloud Computing, casos de uso y retos:

Y finalmente se analizan estos servicios IoT: Sofia2, Fiware, Watson IoT de IBM, Artik Cloud de Samgung y Azure IoT Suite de Microsoft.

Tras describir la historia, conceptos, características, arquitectura y referencias de cada una de las plataformas, en el capítulo 4 (página 35) del informe Edison crea un Entorno de Pruebas para evaluar los diferentes servicios.

Tras esto, en el capítulo 5 extrae los resultados de cada una de las plataformas, el escenario probaba durante 30 días este escenario (

Podéis revisar vosotros mismos los resultados comparativos a partir de la página 45, como resumen tendríamos:

Mensajes procesados por la plataforma:

 

Características:

 

(En las pruebas con Sofia2, Edison usó el entorno gratuito Sofia2 CloudLab que permite sin limitaciones probar toda la plataforma durante tiempo indefinido pero que no ofrece SLAs).

A partir de la página 61, Edison expone sus conclusiones, en el que respecto a Sofia2 Edison concluye:

“Sofia2, en cambio, une estas dos características: es tanto libre de uso en algunos aspectos y cuenta con modelo de pago pay-as-you go. Por tanto puede resultar muy atractiva para desarrolladores que estén buscando un modelo gratuito donde implementar su proyecto piloto y poder migrar de manera fácil hacia un modelo de negocio bajo suscripción”.

Los que queráis profundizar en el análisis realizado podéis acudir al anexo, en el que se explican los pasos a seguir en cada una de las plataformas para el caso de test.

Quería acabar este post agradeciendo a Edison haber contemplado Sofia2 como una de las 5 plataformas IoT analizadas, y por supuesto aclarar que no hemos participado para nada en este análisis.

Gracias Edison, en breve publicaremos novedades muy interesantes respecto a tu análisis sobre la nueva versión de la Plataforma!.

Análisis de Plataformas/Servicios IoT Cloud (Sofia2, FIWARE, Azure IoT, Watson IoT y Artik Cloud)

OPC: De Windows COM/DCOM a OPC-UA

Origen:

La especificación OPC (OLE for Process Control) surge allá por 1996, en la época de los 90s, donde el uso de sistemas de automatización, fundamentalmente SCADAS para visualización y control basados en Windows proliferó.

En ese momento los fabricantes de interfaces HMI y software SCADAS tenían el problema de tener que escribir su propio driver para conectar con los PLCs, asi que se creó el grupo de trabajo OPC para definir un estándar para acceso a dispositivos (PLCs especialmente) desde sistemas Windows.

La especificación OPC Data Access (OPC-DA) se publica en 1996 y la versión 2 en 1998. Esta especificación se basaba en tecnologías Microsoft Windows COM (Component Object Model) y DCOM (Distributed COM).

Hoy en día OPC es el estándar universalmente aceptado) para intercambiar datos entre sistemas de automatización industrial: SCADA y HMI, gestión de procesos y Sistemas de Control Distribuidos (Distributed Control Systems – DCS) y Sistemas de Ejecución Manufacturera (Manufacturing Execution System – MES).

Tecnología OPC clásico:

OPC usa una arquitectura cliente-servidor:

· Un servidor OPC encapsula la fuente de información de proceso como un dispositivo y hace la información disponible a través de su interfaz.

· Un cliente OPC se conecta al servidor OPC y puede acceder y consumir la información ofrecida.

Como decíamos, las interfaces clásicas de OPC están basadas en la tecnología COM y DCOM de Microsoft. COM y DCOM ofrecen a un cliente un mecanismo transparente para llamar a métodos en un objeto COM en un servidor que se está ejecutando, en el mismo proceso, en otro proceso o en otro nodo de red.

Esta ventaja fue importante para el éxito de OPC pero por el contrario hacía depender a OPC de la plataforma Windows y además DCOM tenía inconvenientes como su complejidad de configuración (Dios, cómo lo recuerdo!!!) o sus timeouts.

Especificaciones OPC clásicas:

Hasta llegar a OPC-UA teníamos:

· Acceso a Datos (OPC-DA): permite leer, escribir y monitorizar variables, se usa paratransmitir datos de tiempo-real de PLCs, y otros dispositivos de control a HMIs y otras pantallas clientes. OPC-DA es el interfaz más importante de OPC, el resto de interfaces OPC se implementan como complemento a OPC-DA.

· Alarmas y Eventos (OPC-A&E): permite recibir notificaciones de eventos y de alarmas.

· Acceso a Datos Históricos (OPC-HDA) permite el acceso a datos ya almacenados. Los archivos históricos se recuperan de manera uniforme, desde un simple sistema de registro de datos serie a un complejo sistema SCADA.

Además de estos teníamos por ejemplo OPC XML-DA, la primera especificación OPC independiente-de-plataforma que reemplazaba COM/DCOM con HTTP/SOAP y tecnologías de Servicio Web (un auténtico suplicio!).

Y por fin OPC-UA:

OPC XML-DA fue el primer intento de la OPC Foundation para mantener las características exitosas de OPC pero utilizar una infraestructura neutra en cuanto a plataforma y fabricante. Entre otras razones, el bajo rendimiento de los Servicios Web XML comparado con la versión original basada en COM y los problemas de interoperabilidad al utilizar capas diferentes de Servicios Web XML, hicieron que no cumplieran con los requisitos de la nueva generación de OPC.

La OPC Unified Architecture (OPC-UA) nace con el objetivo de crear un recambio real para todas las especificaciones basadas en COM sin perder ninguna de sus características ni rendimiento. Además el modelado de datos era muy limitado en el OPC Clásico y necesitaba una mejora ofreciendo un modelo común, orientado a objetos para todos los datos OPC.

Para cumplir los objetivos definidos, OPC-UA se construye en varias capas, donde los componentes fundamentales de OPC-UA son los mecanismos de transporte y el modelo de datos.

· El transporte define diferentes mecanismos optimizados para diversos casos de uso. La primera versión de OPC-UA define un protocolo TCP binario optimizado de alto rendimiento en comunicaciones intranet así como un acceso a estándares de internet aceptados como Servicios Web, XML y HTTP para comunicaciones por internet a través de cortafuegos.

· El modelo de datos define las reglas y bloques constructivos necesarios para exponer un modelo de información con OPC-UA. Define también los puntos de entrada al espacio de direcciones y los tipos básicos utilizados para construir una jerarquía de tipos.

OPC-UA utiliza una arquitectura cliente-servidor similar al que se utiliza en OPC Clásico. Una aplicación que quiera exponer su propia información a otras aplicaciones se llama servidor UA, y una aplicación que quiera consumir información de otras aplicaciones se llama cliente UA. En OPC-UA se espera que vaya a haber muchas más aplicaciones que sean a la vez servidor UA y cliente UA en una misma aplicación que en el OPC Clásico.

Leer más

OPC: De Windows COM/DCOM a OPC-UA

Meetup on Sofia2 LPWA Integrations: SigFox, LoRaWAN & The Things Network

On February 28th, we scheduled one of our technical Meetups, this time on LPWA technologies and how easy is to integrate them on Sofia2 IoT Platform. Please join our Meetup group where we will keep you updated with our future meetup events. You may also find here the slides used during the presentation.

A big thank you also to THECUBE Madrid team for giving us free access and use of their building. They also contributed by composing this really nice video on the event, enjoy it!:

These time our speakers where Jorge Trallero and Mario Briceño from our Sofia2 Team. They highlighted how easy is to integrate data collected from IoT devices with LPWA technologies into Sofia2. 3 integrations scenarios were performed:

  • SigFox Integration
  • Private LoRa Network Integration
  • The Things Network Integration

We also had the luxury of having with us member of the core team of The Things Network Madrid Community, to present us their initiatives and to collaborate in the latter integration scenario.

Seguir leyendo “Meetup on Sofia2 LPWA Integrations: SigFox, LoRaWAN & The Things Network”

Meetup on Sofia2 LPWA Integrations: SigFox, LoRaWAN & The Things Network

Notebooks Procesando y representando datos en un mapa Leaflet con los Notebooks Sofia2

Los Notebooks Sofia2 (basados en el proyecto open-source Apache Zeppelin) permiten a los científicos de datos crear diferentes modelos y algoritmos desde el Control Panel de la plataforma Sofia2. Desde este entorno web los Data Scientists pueden cargar datos a HDFS, procesarlos con Spark, Spark o Python, consultarlos con HIVE, visualizarlos de diferentes formas y además de todo esto manejar las ontologías Sofia2 desde este entorno.

En este ejemplo de uso de los Notebooks vamos a ver cómo traernos un fichero de un sitio externo, procesarlo con Spark y representar los datos procesados en un mapa OpenStreetMap con Leaflet.

Concretamente estamos hablando de un fichero que ofrece el servicio OpenData del gobierno francés (https://www.data.gouv.fr/fr/) y que contiene los datos de las estaciones de recarga eléctrica de Francia

https://www.data.gouv.fr/fr/datasets/fichier-consolide-des-bornes-de-recharge-pour-vehicules-electriques-irve/

El fichero tiene este aspecto:

Comenzaremos por descargar el fichero hacia el directorio home de nuestro usuario:

Lo siguiente es subir este fichero de nuestro directorio local al sistema de ficheros HDFS de nuestro cluster Hadoop

Una vez en HDFS ya puedo manejar los datos con Spark, en este caso para procesar el CSV usaré la librería com.databricks.spark-csv. Para cargarla en el classpath de Spark lo más sencillo es hacer esto:

Y de esta forma tan sencilla puedo convertir el CSV almacenado en HDFS (load(“/examples/IRVE-201510.csv”)) a un DataFrame (df) y de ahí a una tabla persistente (df.write.saveAsTable)

Y una vez tengo la tabla ya puedo consultar los datos de esta de forma muy sencilla:

Además de representarlos en diferentes formatos:

Finalmente haremos la consulta que queremos representar en el mapa:

Tras esto voy a convertir los datos de la consulta a JSON para poder representarlos fácilmente, para esto usaré la librería Gson.

Haré la consulta, mapeando las columnas de los datos obtenidos a los nombres que quiero usar en el JSON:

Los datos tienen esta pinta:

Y ya solo me queda hacer el HTML+JS para pintar mi mapa, en Zeppelin para incrustar un HTML basta con empezar el párrafo con:

Mi HTML tiene este aspecto:

En él podemos ver que estamos usando Thunderforest como Layer (y un apikey que debéis generar en http://www.thunderforest.com/docs/apikeys/ para evitar la marca de agua).

El código que maneja mi JSON con las estaciones es este:

Que genera un botón Show me the map que al pulsar muestra el mapa con un marker para cada estación:

Además de ver la representación en el propio Notebook si en las opciones del párrafo selecciono Link this paragrah:

Esto me genera un URL en la que veo el mapa:

https://sofia2.com/console/notebook/#/notebook/2D1Y4DKY7/paragraph/20160519-175034_779917343?asIframe

y puedo ir pinchando sobre los diferentes markers:

Notebooks Procesando y representando datos en un mapa Leaflet con los Notebooks Sofia2

Nueva guía e IDE de desarrollo de soluciones sobre Plataforma Sofia2

image0172

 

Uno de los objetivos fundacionales de la Plataforma Sofia2 es el de simplificar y agilizar el desarrollo de todo tipo de aplicaciones, desde aplicaciones IoT en las que intervienen Gateways o dispositivos móviles a grandes sistemas Big Data, sin olvidar las aplicaciones web puras de gestión, para las que Sofia2 es un facilitador.

En este ámbito se ha añadido en la sección de Documentación  de la web sofia2.com una nueva guía que explica paso a paso cómo construir aplicaciones web (en la guía basadas en Spring Boot y Angular):

image0172

 

Complementando la guía se ha generado un entorno de desarrollo empaquetado como un ZIP que contiene todas las herramientas necesarias para construir estas soluciones (incluyendo JVM Java, IDE Eclipse, Maven, Apache Tomcat,…)

Nueva guía e IDE de desarrollo de soluciones sobre Plataforma Sofia2

Sofia2 Desktops

T_21

A área de trabalho da plataforma constitui o ponto de acesso de qualquer usuário da plataforma a qualquer um dos aplicativos fornecidos no projeto e a que o usuário tenha acesso.

No nível da plataforma, diferentes desktops podem ser criados para que um usuário possa acessar vários desktops, cada um com diferentes finalidades e aplicativos.

Escritórios são aplicativos da Web que atuam como contêineres para outras aplicações. Um administrador de plataforma controla e configura quais aplicativos são acessíveis a partir de cada mesa, associando-os à área de trabalho do próprio painel de controle da plataforma.

Ao mesmo tempo, cada administrador de aplicativos, dando-o como um projeto na própria plataforma, controlará quais usuários têm acesso ao aplicativo.

Para que cada mesa, realize o controle do acesso aos usuários da plataforma através de uma tela de login e dependendo das permissões que esse usuário tenha em cada um dos aplicativos registrados, terá acesso ou não aos aplicativos registrados como aplicativos de área de trabalho.

Em seguida, explicaremos como criá-los e usá-los.

Seguir leyendo “Sofia2 Desktops”

Sofia2 Desktops