IoT Data Models: Iniciativas y Sofia2 Data Model

¿Qué es un Data Model?

Un Data Model representa la estructura de tus datos y relaciones, por tanto organiza los elementos y estandariza como se relacionan unos con otros.

¿Por qué utilizar un Data Model en el ámbito IoT?

Los Data Models son fundamentales en el ámbito IoT donde tratamos con assets físicos, medidas, dispositivos, procesos, personas,… y el nuestro IoT Data Model debe ser capaz de modelar todos estos conceptos.

Un Data Model nos da una representación uniforme de todos los elementos de nuestro sistema, esto tienen numerosos beneficios:

  • Reuso: la capacidad de modelar componentes que luego podré reusar es una práctica estándar que permite ahorrar en costes
  • Flexibilidad: una vez creado el modelo, este permite que sea fácil actualizar, modificar o eliminar elementos del modelo sin necesidad de rehacer el sistema
  • Escalabilidad: simplifica el clonado y modificación de dispositivos que son similares o se comportan de la misma forma que otros ya testados.
  • Interoperabilidad: usar un Data Model que se base en estándares (JSON, XML,…) simplifica que este Data Model pueda usarse en aplicaciones futuras de forma sencilla
  • Colaboración: Un Data Model nos permite predefinir links, relaciones, acciones entre componentes, permitiendo que esto se defina cuando se está creando el modelo de modo que diferentes equipos puedan trabajar en partes
  • Independencia de la Plataforma: un Data Model permite una integración transparente con otros sistemas. Un modelo correctamente formado hará más sencillo crear aplicaciones como analítica sobre los datos

Iniciativas de estandarización de un Data Model en IoT

NOTA: No hemos considerado los protocolos de comunicación como MQTT-SN, LWM2M o CoAP, aunque en algunos casos hay ciertos solapes puestos estos protocolos pueden llevar embebido un Data Model.

 

En el mundo IoT existen varias propuestas para intentar estandarizar un Data Model único, aunque la realidad es que ninguna de ellas tiene una penetración en el mercado suficiente como para decantarse de forma unívoca por ella.

A continuación se incluye una tabla con información relevante sobre algunas de estas iniciativas:

  Descripción Organiz Formato Versión
SensorML http://www.opengeospatial.org/standards/sensorml

Sensor Model Language pretende definir semánticamente prceoss y componentes relacionados con las medidas, con el objetivo de conseguir interoperabilidad

OGC XML +XSD 2.0

2014

AMON https://amee.github.io/AMON/

Formato para definir datos de dispositivos

AMEE JSON 3.1

2012

SensorThings http://www.opengeospatial.org/standards/sensorthings

Forma abierta y unificada de conectar dispositivos, datos y aplicaciones.

OGC JSON +

OData

1.0

2016

GSMA IoT Big Data Armonized Data Model https://www.gsma.com/iot/wp-content/uploads/2016/11/CLP.26-v1.0.pdf

Definición de entidades de uso común en IoT y Big Data creando modelos harmonizados en ámbitos Agricultura, Automoción, Environment, Industria, Smart City y Smart Home

GSMA JSON +schema.org 1.0

2016

FIWARE Data Model https://www.fiware.org/data-models/

Adaptación de GSMA Data Model sustituyendo schema.org para definición de Data Modelo por JSON-Schema para simplificar su uso

FIWARE JSON +

JSON-Schema

1.0

2017

¿Qué tienen en común estas iniciativas?

El grueso de estas iniciativas (sobre todo las más actuales) usan JSON como formato de intercambio.

Respecto a JSON podemos decir:

  • Es un formato de intercambio ligero, en la actualidad se ha convertido en el estándar de intercambio sustituyendo a XML en la mayoría de los escenarios

a2.jpg

  • Es el formato usado “para todo” por los grandes en el mundo Web: Google, Amazon,…
  • Es el formato por defecto de la “API Economy” con la que por ejemplo los bancos y organizaciones ofrecen sus datos
  • Es un formato que se usa en las modernas aplicaciones Web y móviles por ser mucho más ligero que XML
  • Es un formato ligero, adecuado para dispositivos IoT

Para definir la estructura de un JSON (por ejemplo que atributos son obligatorios o el tipo de datos) existe JSON-Schema (el equivalente a XML-Schema), aunque en la actualidad no es de uso obligatorio ni está ampliamente estandarizado y existen otras iniciativas.

Sobre JSON y JSON-Schema y por debajo de estándares como los que mencionábamos tenemos otros formatos y definiciones como OData o schema.org, pero tampoco tienen una penetración masiva.

Sofia2 Data Model

Ontologías Sofia2

En Sofia2 a la Entidad del Data Model usado (Sofia2 Data Model) la denominamos Ontologías.

Las Ontologías Sofia2 permiten modelar desde conceptos sencillos como una medida a conceptos complejos como una organización.

Las Ontologías en Sofia2 se definen en JSON+JSON Schema.

Origen de las Ontologías Sofia2

El concepto de Ontología viene del proyecto europeo I+D SOFIA del que se origina Sofia2, que usaba como Data Model Ontologías RDF/OWL conforme los principios de la Web semántica.

Cuando en 2013 Indra considera evolucionar SOFIA para crear una plataforma empresarial (Sofia2) que pueda usarse en proyectos productivos y complejos se realiza un análisis y pruebas empíricas y se concluye que la tecnología subyacente a las ontologías tradicionales modeladas en OWL no escala conforme a las necesidades de los proyectos IoT y Big Data.

Tras considerar diversas opciones se considera que JSON+JSON Schema es la mejor propuesta de presente y futuro.

Conceptos del Sofia2 Data Model

El concepto clave del Sofia2 Data Model es la Ontología, como ya hemos dicho, pero existen otros conceptos importantes, como el Template y la Instancia de la Ontología.

  Template Ontología Instancia Ontología
Representa Plantilla, bien creada por un administrador, bien creada conforme a un estándar concreto (AMON, FIWARE Data Model) que permite que las Ontologías se creen de Entidad que representa un concepto sobre el que trabaja la Plataforma. Es un registro concreto de la Entidad que define la Ontología
Ejemplos Plantilla definiendo los atributos de Calidad medioambiental conforme el FIWARE Data Model

-Pla

Calidad Medioambiental (obtenida de un dispositivo)

-Previsión metereológica (obtenida por un algoritmo)

-Calidad medioambiental obtenida en una hora concreta en un punto concreto

-Previsión para una región y mes concreto

Formato JSON-Schema JSON-Schema

(soporta GeoJSON, OData)

JSON

(GeoJSON)

Dónde están -No se almacenan, son una definición Independiente del motor de persistencia elegido: en un modelo relacional representan una tabla, en una BD NoSQL tipo documental una colección de documentos,,… Independiente del motor de persistencia elegido: en un modelo relacional representan un registro, en una BD NoSQL tipo documental un documento concreto,….
Más info Soportado por completo estándares AMON y FIWARE Data Model Soportan versionado

Soportan consultas geográficas

 

 Sofia2 Data Model en el Control Panel de Sofia2

Template

El concepto de Template representa una Plantilla sobre la que luego podrán crearse las Entidades.

Por tanto sólo se permite a los usuarios con rol ADMINISTRADOR crear estas Plantillas:

a1

En la Plataforma sólo tienen permiso para crear Templates o Plantillas, como puede verse en la imagen:

Las Plantillas tienen asociadas una o varias categorías que me permiten categorizarlas y buscar por estas.

Una Plantilla se representa por un JSON-Schema:

a3.jpg

Ontología

La Ontología es el concepto clave del Sofia2 Data Model y también del funcionamiento completo de la plataforma, ya que sobre estas se desencadenan el resto de procesos:

  • Reglas: se aplican ante la llegada de una instancia de ontología (o bien planificadas) y permite acceder a los atributos de las ontologías para accionar en base a esta
  • Dashboards: se construyen bien representando en tiempo real las instancias que van llegando a la plataforma bien a través de una consulta a estas
  • Analítica: los modelos ML típicamente se realizan sobre las ontologías almacenadas en la infraestructura Big Data de la plataforma (BDH)

Los usuarios Sofia2 con rol COLABORADOR pueden crear Ontologías, existen diversos mecanismos de crear Ontologías, los principales son:

  • Creación Paso a Paso: me permite crear Ontologías indicándole los atributos que componen la ontología, el tipo de datos de cada uno y si son obligatorios. Es la opción ideal para ontologías sencillas (equivalentes a una Tabla)
  • Creación mediante JSON-Schema: en este caso crearemos la Ontología bien definiendo el JSON-Schema que representa mi entidad, bien partiendo de un template ya creado.

Si seleccionamos la creación vía Ontología entonces me pedirá que seleccione una de las categorías:

a4.jpg

Y una vez seleccionada una de ellas (por ejemplo GSMA) me dará la opción de seleccionar una de las Plantillas:

a5

Soporta además:

La creación de la Ontología a partir de un Schema XML (XSD).

La creación de la Ontología a través de un diagrama UML que se crea en el propio Panel de Control

  • Creación desde CSV o Excel: esta opción es muy útil cuando tenemos un fichero con datos con los que quiero hacer una carga inicial en la plataforma. La Plataforma me irá guiando y solicitando la información que necesita hasta generar de forma automática el JSON-Schema que representa los datos pasados:

q1

  • Creación desde JSON/XML: equivalente a la creación desde Excel en este caso podré subir una JSON o XML para que la Plataforma cree la Ontología correspondiente.
  • Creación Ontología Tipo KPI: en este caso lo que estamos haciendo es crear una Ontología que se calcula en base a cálculos sobre otras ontologías
  • Creación Ontología Tipo TimeSeries: el concepto de Time Series se refiere a datos de tipo Serie Temporal, la plataforma soporta la creación de estos modelos de forma sencilla: 

    Instancia de Ontología

    Representa una instanciación de una ontología, típicamente en un momento concreto y posición concreta.

    La Plataforma ofrece diversas herramientas para acceder a las instancias, la más usadas por el desarrollador será la Consola BDTR y BDH que permite a través de un wizard generar consultas sobre las ontologías:

q3.jpg

 

 

 

Desde la herramienta puedo visualizar los datos de la Ontología (instancias) en formato nativo de la Plataforma, esto es en JSON:

q3.jpg

Pero también puedo representar los datos en formato TABLA e incluso exportarlos a formato CSV, Excel o XML.

 

 

IoT Data Models: Iniciativas y Sofia2 Data Model

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

Usando el nuevo Visor #OpenData de Sofia2

Blog de Sofia2 IoT Platform

En la última release de Sofia2 se ha incorporado una utilidad que permite visualizar ontologías definidas como públicas dentro de un Visor OpenData.

En este post vamos a:

  • Buscar un DataSet
  • Cargar el DataSet en Sofia2
  • Visualizarlo en el nuevo Visor

BÚSQUEDA DEL DATASET

Existen numerosos portales donde buscar un DataSet a cargar, por ejemplo:

  • Portal de datos abiertos de la Unión Europea: este portal agrupa fuentes de datos gratuitas disponibles por parte de las instituciones de la Unión Europea. Hay sobre 8200 datasets y podéis acceder a ellos en Portal de datos abiertos de UE
  • Portal de datos abiertos del Gobierno de USA: Al igual que en los datos del portal de la Unión Europea son fuentes de datos gratuitas y libres para su explotación. Además ofrecen ejemplos de aplicaciones desarrolladas, Se puede acceder a través de este enlace: Portal de datos abiertos de USA
  • Quandl: Quandl…

Ver la entrada original 423 palabras más

Usando el nuevo Visor #OpenData de Sofia2

Publicada Release 4.1 de Sofia2 IoT Platform

Ya está disponible la release 4.1 de Sofia2 IoT Platform.

Esta release se ha disponibilizado en la Plataforma de Experimentación Sofia2 CloudLab.

Ver otras releases

Esta release se ha centrado en mejorar e incorporar nuevas herramientas para el desarrollador, entre estas podemos destacar:

MEJORAS EN EL PANEL DE CONTROL

Dentro de la propuesta de valor de la Plataforma Sofia2, el desarrollador es un punto clave, en esa línea estamos trabajando de continuo en mejorar la relación del desarrollador con la consola:

  • Nueva Pantalla de Inicio del Control Panel: a partir de ahora cuando un usuario accede a la plataforma ve un grafo con su “Universo Sofia”, esto es las entidades creadas (Ontologías), clientes (ThinKPs), dashboards, reglas,…y sus relaciones, además pinchando en cada uno de los elementos puedo navegar directamente a su UI de edición:

  • Ayuda integrada en la consola: a partir de ahora desde dentro de la consola podéis buscar cualquier término, esta búsqueda se hace sobre el Blog

y sobre la web de ayuda de la plataforma:

Y NUEVAS UTILIDADES PARA EL USUARIO DE LA PLATAFORMA

Y siguiendo con simplificar la vida de los usuarios de la plataforma hemos incorporado nuevas herramientas que esperamos simplifiquen su día a día:

  • Exportación e importación de elementos entre entornos: esta funcionalidad permite desde el panel de control seleccionar los elementos creados en un entorno (ontologías, proyectos, ThinKPs, APIS,…) y exportarlos, la plataforma genera un ZIP que luego podré importar en otra instancia de la plataforma. Con este mecanismo puedo comenzar el desarrollo en un entorno y luego migrar de forma sencilla todo este desarrollo.

  •  Integración de Proyecto Sofia2 con Git: la plataforma permite configurar una conexión con un repositorio Git, una vez configurado por el administrador cuando creamos un proyecto esto replicará la estructura en este repositorio Git.

  •  Conversión de Ontologías a DTOs Java: permite generar desde una ontología la clase Java que la representa (incluidas anotaciones para pasar de Java a JSON y JSON a Java), de este modo podré trabajar en este lenguaje con la ontología como una clase más

  • Mejoras en Motor Scripting: para ayudar en la creación de scripts, el editor de scripts soporta el autocompletado (pulsando Ctrl+Espacio)

Además en el log de procesos pueden encontrarse los errores en la ejecución del script:

NUEVAS FUNCIONALIDADES EN MOTOR DASHBOARDS

En base a las necesidades identificadas en algunos de los proyectos en los que colaboramos se han incluido:

  • Paso de parámetros tanto a gadgets como a dashboards para que estos lo pasen a la consulta con la que se cargan los datos
  • Internacionalización de los textos: desde el propio editor podremos definir un JSON de internacionalización que luego se utiliza en los campos:

  • Plantillas de Gadget: esta funcionalidad permite disponilibilizar un gadget tipo HTML5 como plantilla de modo que otros usuarios puedan crear sus propios gadgets completando los parámetros asociados al gadget
  • Gadget tipo Weather: en función de la configuración es capaz de mostrar para una localización temperatura y previsiones

NUEVAS FUNCIONALIDADES EN MOTOR SINÓPTICOS

Este módulo se inició como demostración de lo que podíamos hacer con la plataforma y tecnologías Web (SVG) en un ámbito tradicionalmente copado por los SCADAS.

Gracias a las mejoras identificadas por los colaboradores en esta nueva versión soportamos:

NUEVAS FUNCIONALIDADES EN API MANAGER:

El API Manager cada vez es un componente más habitual en arquitecturas SW, este componente que cumple ya 3 años en la plataforma sigue incorporando novedades como:

DIFUSIÓN DE LA PLATAFORMA

Uno de los focos de trabajo en la plataforma es que la plataforma sea usable tanto para un rol usuario como para un rol Desarrollador avanzado o científico de datos, y para eso disponer de material formativo es muy importante.

En esta versión hemos generado estas guías:

Publicada Release 4.1 de Sofia2 IoT Platform

Release 4.1 Sofia2 IoT Platform Published

Release 4.1 of Sofia2 IoT Platform is already available.

In this release has been made available the Sofia2 CloudLab Experimentation Platform

See other releases

This release has been centered on improving and incorporating new tools for the developer, among them we can highlight:

IMPROVEMENTS IN THE CONTROL PANEL

Inside the value proposal for the Sofia2 platform, the developer is a key element, and in this line we are continuously working on improving the relationship of the developer with the console:

  • New control panel landing page: From now on when a user accesses the console is presented with a graph displaying his ‘Sofia Universe’, that is, created entities (ontologies), clients (ThinKPs), dashboards, rules… and their relationships. Also, clicking on each of this elements you can navigate straight to their specific UI.

  • Console integrated help: From now one you can search for any term directly from the console, for example, this search is done over the blog:

and over the platform web help:

AND NEW UTILIDES FOR THE USER OF THE PLATFORM:

Also, following the line of simplifying the platform user’s daily life, we have incorporated new tool we hope can ease their day-to-day:

  • Exportation and importation of elements between environments: This functionality allows, from the control panel, to select the elements created in an environment (ontologies, projects, ThinKPs, APIs) and export them. The platform generates a ZIP file able to be used later for import on another platform. With this mechanism I can start development on one environment and later migrate everything to another in a simple way.
  • Sofia2 project integration with Git: The platform allows to configure a connection with a git repository. Once this is configured by an administrator, when we create a project, this will replicate the structure in the Git repository.
  • Ontology to Java DTOs: This allows to generate a Java class from an ontology (including annotations to migrate from Java to Json and viceversa).

  • Improvements on the scripting engine: To help with the script creation, the editor now supports autocompletion (using to Ctrl+Space combination).

Also on the process log the script errors can be found:

NEW FUNCTIONALITIES ON THE DASHBOARD ENGINE

Bases on the requirements identified on some projects we collaborate with we have also included:

  • Parameter passing either to gadgets or dashboards, so they can, in turn, pass them to the queries they use to load data
  • ·Text internationalization: From the editor we can now define an internationalization JSON to be used on the fields:

  • Gadget templates: This functionality allows to make available a HTML5 as a template so other users can create their own gadgets completing the template with their own parameters associated to the gadget.
  • Weather type gadget : Depending on the configuration now it is possible to display temperature and predictions based on location

NEW FUNCTIONALITIES ON THE SYNOPTIC ENGINE

This module started as a demonstration on what could we do with the platform and SVG web technologies on a field traditionally dominated by the SCADAs.

Thanks to the improvements identified by the collaborators, on this new version we support

NEW API MANAGER FEATURES:

The API Manager is an increasingly more commonly found on SW architectures. This component, now 3 years old, has incorporated features like:

PLATFORM DIFUSION

One of the work focus of the platform is for it to be accessible either for a user role, an advanced developer or a data scientist, and for that disposing of learning material is very important.

For this release we have generated the following guides:

Release 4.1 Sofia2 IoT Platform Published