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

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

This is the new Gartner report:

Peter Havart-Simkin tells us how Open-Source IoT can help us to address the new challenges posed by the Internet of Things. It also recommends IoT projects technical leaders to adopt, among others, IoT open source products to boost the development of IoT solutions and evaluate their use in IoT commercial systems production. Following the reference model used by Gartner for business solutions Peter lists some open-source solutions in each of the layers.

We are proud to appear as one of the open-source IoT Platfom Hub, since from the very first moment we have opted for open-source, both for the pieces on which we build the platform as well as offering an Open source version (Sofia2 Community Edition) and a free and limitless Cloud environment (Sofia2 CloudLab).

Among the open-source pieces on which we build the platform we have:

  • Moquette Broker (now an Eclipse project) as MQTT Broker
  • Spring and all its ecosystem as the platform’s main development framework (IoT Broker, …
  • JQuery, Thymeleaf, AngularJS, Bootstrap as technologies to build the Control Panel
  • Hazelcast as in memory DataGrid
  • Node-network as flows engine
  • Siddhi CEP as CEP engine
  • MongoDB, CouchDB, ElasticSearch, HBase, HIVE, Impala, … as persistence and query engines
  • Apache Zeppelin as the engine of our Notebooks
  • StreamSets as DataFlow Engine
  • Quasar as SQL analytical engine for MongoDB
  • Apache Drill as DataLink Engine
  • Spark as a streaming processing engine

Another interesting reflection of the report are the considerations that must be made when choosing open-source software, such as:

  • Maturity: how mature is the IoT project? Apart from pilots does it have projects in production?
  • Performance and stability: can the project support the estimated numbers?
  • Vendor stability: can I trust the company behind this software?
  • Support services: Will the company behind be able to provide end-to-end support? How many developers are behind? Response times? Do they offer commercial support?
  • Documentation: as a way to ensure that developers and users will be able to work with this
Gartner Report: Use Open Source to Jump-Start IoT Projects and Make IoT Vendor Decisions

Nueva Pantalla de Inicio del Control Panel

A partir de esta Release, cuando un usuario con rol colaborador accede a la plataforma, puede ver un grafo que representa su “Universo Sofia”. Es decir, puede ver las Ontologías, ThinKPs, Dashboards y Gadgets, Reglas, Proyectos etc.. que ha creado en la plataforma. En el caso de no tener aún ningun componente creado en la platafoma, se mostrará un grafo como el siguiente:

grafosincomp.png

Seguir leyendo “Nueva Pantalla de Inicio del Control Panel”

Nueva Pantalla de Inicio del Control Panel

Release 4.1: Publicación de APIS REST vía NGSI V2

En la Release 4.1 de Sofia2 IoT Platform se ha incorporado una novedad en el API Manager.

ngsi3

Se trata de la posibilidad de publicar APIS que expongan los datos a través del protocolo NGSI.

Es tan sencillo como seleccionar este nuevo tipo de API “Publicar Ontología como API REST NGSI” en API MANAGER > APIs > Crear API:

ng1

Por último, seleccionamos la operación GET disponible para este tipo de APIs y creamos el API.

A la hora de probar el API, nos fijamos en que el endpoint cumple con los requisitos del protocolo NGSI V2:

ng2

Para más información se puede consultar este post dónde se desarrolla un ejemplo completo de consultas mediante el protocolo NGSI, de donde se extrae el siguiente ejemplo de query:

ngsi4

 

 

Release 4.1: Publicación de APIS REST vía NGSI V2

Sofia2 IoT Platform vs ThingWorx IoT Platform. Primeros pasos (IV. Crear aplicaciones)

sofia2vsThingWorx

 

Este es el cuarto y último post de la serie Sofia2 IoT Platform vs ThingWorx IoT Platform. Primeros pasos. El objetivo es realizar una comparativa de uso de dos plataformas IoT como son Sofia2 y ThingWorx. Para ello, realizaremos un hands on siguiendo un flujo sencillo IoT en el que simularemos un edificio que dispone de dispositivos para la lectura de consumo energético y temperatura. Para terminar, crearemos un cuadro de mando para visualizar esta información.

 

Con el fin de conseguir una mejor comprensión de esta comparativa, hemos estructurado los pasos a seguir, comunes a las dos plataformas, en 4 posts:

  1. Registro y Login. Modelado de datos
  2. Conecta tu dispositivo
  3. Simular datos de entrada
  4. Crear Aplicaciones

 

Hoy veremos el último punto.

 

Crear Aplicaciones

 

Sofia2 IoT Platform

 

Una vez que existen datos en la plataforma y a medida que los dispositivos u otras aplicaciones se conectan con Sofia2 es posible crear aplicaciones que interoperen entre sí y exploten la información existente. Las Herramientas de Visualización de Sofia2 me permiten explotar de forma sencilla y gráfica la información almacenada dentro de la Plataforma (Ontologías). Puedo crear elementos de visualización unitaria (Gadgets), unirlos en una página web (Dashboard) o incluso crear complejos sinópticos al estilo SCADA representando la evolución de las señales (Instances).

 

El siguiente paso es crear un cuadro de mando usando las capacidades de presentación gráfica de la plataforma.

 

Creando Gadgets

 

  1. Accedemos a Visualización > Mis Gadgets

MisGadgets

2. Pulsamos en Crear Gadget

3. Usaremos el Wizard para crear nuestro primer Gadget. Lo nombramos GaugeWattsVVC (GaugeWatts + Nuestras Iniciales). Pulsamos sobre Siguiente

4. Seleccionamos nuestra Ontología. Pulsamos sobre Siguiente

5. Seleccionamos Query y pulsamos sobre Siguiente

6. Seleccionamos BDTR y pulsamos sobre Siguiente

7. En el campo consulta ponemos select c.SmartBuildingVVC.watts from SmartBuildingVVC as c limit 1 (cambiando VVC por tus iniciales). Pulsamos sobre Preview

8. Bajamos y seleccionamos la pestaña del Gadget Gauge, arrastramos el atributo value a la caja de medidas, cambiamos el Nombre a Watts y obtendremos un Gadget similar a este:

gauge2

9. Volvemos a Mis Gadgets > Crear Gadget. Ahora haremos otro Gadget, esta vez de tipo área. Lo denominaremos AreaTemperatureVVC (AreaTemperature + Nuestras Iniciales). Haremos los mismos pasos que para el gadget anterior, pero cambiando la Consulta por select * from SmartBuildingVVC as c (cambiando VVC por tus iniciales). Pulsamos sobre preview. Bajamos y seleccionamos la pestaña del Gadget Área, arrastramos los atributos timestamp (que cambiaremos el nombre a Temperature) y temperature a la caja de medidas, y obtendremos un Gadget similar a este:

GadgetAreaDos

10. Por último, crearemos un tercer Gadget de tipo Mapa, que llamaremos MapaVVC (Mapa + Nuestras Iniciales). Realizaremos los mismos pasos que para el gadget anterior, usando la Consulta select * from SmartBuildingVVC as c (cambiando VVC por tus iniciales). Pulsamos sobre preview. Bajamos y seleccionamos la pestaña del Gadget Maps, arrastramos los atributos geometry.coordinates.0 y geometry.coordinates.1.

En Medidas cambiaremos el nombre a Localización. Marcaremos los atributos address, city, state y zip y obtendremos un Gadget similar a este:

crearMapaDos

 

 

Creando Mi Dashboard

 

Llamamos Dashboard al cuadro de mandos que recoge una cantidad determinada de elementos (Gadgets). Para crear un Dashboard seguiremos los siguientes pasos:

 

  1. Accedemos mediante el menú a Visualización > Mis Dashboards
  2. Pulsamos sobre Crear Dashboard
  3. Le ponemos como nombre SmartBuildingVVC (SmartBuilding + Nuestras Iniciales)
  4. Tenemos diferentes opciones de estilado, podemos elegir un tema determinado o customizarlo con los colores que elijamos de la paleta. Elegiremos el tema Dark Blue por ejemplo.

estiloDashboard

5. Bajaremos y pulsaremos sobre Nueva Página

6. Pulsaremos sobre + y añadiremos nuestros 3 Gadgets, obteniendo un Dashboard similar a:

DashboardBienn

 

 

ThingWorx

 

ThingWorx denomina Mashup Builder al lugar donde se crean las visualizaciones, siendo los widgets los componentes que se colocan en el mashup. Por lo tanto, podríamos establecer la siguiente similitud de conceptos: lo que llamábamos Gadget en Sofia2, en ThingWorx es un widget y lo que llamábamos Dashboard, ahora es un Mashup.

 

Construyendo un Mashup

 

  1. Nos situamos encima de la pestaña Mashups, en el panel de la izquierda y pulsamos en +

Mashup

 

2. Para Mashup Type seleccionamos Page

3. Para Layout Options seleccionamos Static y pulsamos Done

4. En la pestaña Widgets de la izquierda, hacemos click y arrastramos el widget Gauge en el lienzo del centro. Este widget mostrará los watios simulados en uso.

5. Seleccionamos el objeto Gauge en el lienzo. La parte inferior izquierda de la pantalla contiene las propiedades del widget. Nos desplazamos hacia abajo y cambiamos el valor de la propiedad Legend a Watts. Observe que la etiqueta del lienzo se ha actualizado para mostrar la palabra “Watts”

6. Si el widget OpenStreetMap no está disponible, descargue e instale la Extensión de Mapa de Open Street desde ThingWorx IoT Marketplace https://marketplace.thingworx.com/

7. Hacemos click y arrastramos el widget OpenStreetMap en el lienzo del centro

8. Hacemos click y arrastramos el widget Time Series Chart en el lienzo del centro

9. Movemos los widgets y los cambiamos de tamaño para que quepan en el lienzo

10. Pulsamos en Save y nombramos el Mashup, por ejemplo MyHomeMash

mashupAMedias

 

 

Suministrando datos a un Mashup

 

  1. Si no estamos en modo edición, hacemos click en el botón de edición naranja.

edicionMashup

2. En la ficha Datos en la parte superior derecha de Mashup Builder, hacemos click en el botón verde +

3. Buscamos el Thing MyHouse en la barra de búsqueda Select Entity.

4. En la barra Select Services, buscamos QueryPropertyHistory y hacemos click en la flecha derecha azul para seleccionar este servicio. Este servicio recuperará todas las propiedades registradas del Thing MyHome

5. Marcamos la casilla Mashup Loaded y hacemos click en Done. Esto ejecutará el servicio y recuperará los datos cuando se cargue el Mashup.

addData

6. Seleccionamos y expandimos la pestaña All Data en la parte superior derecha de Mashup Builder. Se mostrarán todas las salidas de la llamada de servicio.

7. Arrastramos la propiedad watts al widget Gauge en el lienzo. Seleccionamos # Data para el destino de enlace.

MashupDesarrollado

 

8. Hacemos lo mismo para el widget OpenStreetMap vinculando house_lat_long a la SelectedLocation en el mapa.

9. Con el widget OpenStreetMap seleccionado, hacemos click en la propiedad ShowSelectionMarker en la ventana de propiedades del widget en la parte inferior izquierda del Generador de Mashup.

10. Para el Time Series Chart, arrastramos el contenedor All Data en el widget y seleccionamos Data como el destino de enlace

11. Con el widget Time Series Chart seleccionado, establecemos las siguientes propiedades mediante la ventana de propiedades del widget en la parte inferior izquierda del Mashup Builder:

Property Value
XAxisField  timestamp
DataField1 temperature

12. Pulsamos sobre Save para guardar los cambios

 

Lanzando la Aplicación

 

  1. Iniciamos la aplicación seleccionando el botón View Mashup en la parte superior. Es posible que debamos habilitar el cuadro emergente en su navegador para ver el mashup.
  2. Obtendremos un Mashup similar a este:

MashupFinal

Sofia2 IoT Platform vs ThingWorx IoT Platform. Primeros pasos (IV. Crear aplicaciones)

Soporte consultas desde el CRUD para TimeSeries

En posts anteriores hemos hablado de las ontologías TimeSeries que dan soporte al concepto de series temporales.

2

Recientemente se ha añadido una nueva funcionalidad para estas ontologías, que consiste en la posibilidad de realizar consultas desde el CRUD de la consola de administración.

Lo primero a tener en cuenta es recordar que en este tipo de ontologías, la instancia a insertar tiene que concordar con el tipo de dato definido a la hora de crear dicha ontología. En este caso la ontología con la que estamos trabajando tiene un tipo de dato simple, por tanto la instancia que se debe de enviar tendrá que ser del tipo:

{“timestamp”:{“$date”: “2014-01-30T17:14:00Z”},”value”:”string”}

Por lo que si accedemos a  Ontologías > Gestión Crud de Instancias y seleccionamos una ontología de tipo TimeSeries, el formulario que nos muestra para insertar datos, cumplirá con el esquema anterior:

time1

Otro detalle a recordar es la forma en el que se insertan los datos en las ontologías TimeSerie, dónde sólo hay una instancia por cada ventana temporal dónde se agruparan los datos enviados dependiendo de la configuración de dicha ventana. Por esta razón hasta que no cambiemos de ventana temporal, solo nos aparecerá una instancia :

time2

A la hora de borrar desde esta pantalla hay que tener en cuenta que se borrará toda la instancia correspondiente a la ventana temporal.

Soporte consultas desde el CRUD para TimeSeries