Funcionalidad soporte multi-BDTR

image0141

En la Release 4.2 de Sofia2 IoT Platform se introdujo el concepto de multi-BDTR. Hasta ahora una instalación de Sofia2 sólo podía funcionar con una BDTR y con una BDH, es decir, si se usaba MongoDB como base de datos BDTR entonces todas las ontologías se almacenaban en esta base de datos.

En esta versión hemos añadido la capacidad de que en una misma instalación de Sofia2 se puedan gestionar diferentes BDTRs, de esta forma cuando creamos una ontología podemos seleccionar la base de datos sobre la que queremos que trabaje. Esta opción la podemos encontrar en Opciones Avanzadas > Seleccionar instancia BDTR en todas las pantallas de creación de ontología:

image0132

Esta funcionalidad nos permite tener tanto bases de datos relacionales como no relacionales en nuestra instancia de Sofia2. Para trabajar con bases de datos relacionales ,como puede ser un PostgreSQL se ha añadido una nueva funcionalidad que nos permite crear ontologías sobre este tipo de base de datos, a la cual podemos acceder desde el menú Ontologías > Crear Ontología > Crear Ontología en Base de Datos Relacional

image006

Lo que nos llevará al formulario para crear la ontología paso a paso, donde nuevamente en Opciones Avanzadas encontraremos el listado de BDTRs relacionales disponibles en la instancia de Sofia2:

post

La configuración de todas las BDTRs las realiza el administrados del sistema de la instancia de Sofia2, para ello se ha creado un nuevo rol SYS_ADMIN. Si accedemos a la instancia de Sofia2 con este rol podremos ver en un primer momento un listado de las BDTRs disponibles para la instancia:

post2

Si accedemos a Crear Instancia tenemos un formulario con todos los campos necesarios para configurar nuestras BDTRs:

post3

Cabe destacar que solo podemos tener una BDTR por defecto y que será en la cual se creen todas las ontologías si no seleccionamos ninguna BDTR en concreto en el apartado de Opciones Avanzadas de creación de ontologías.

Funcionalidad soporte multi-BDTR

Mejoras documentación de ontologías

 doc-ontologias-03
Se incluyen en la plataforma una serie de mejoras de cara a la documentación de nuestro modelo de dominio basado en ontologías.
La primera de ellas consiste en poder incluir una descripción a los atributos de una ontología en la pantalla de creación/edición de la misma y cuyo contenido quede incluido en el propio esquema JSON de ésta.
doc-ontologias-01doc-ontologias-02doc-ontologias-03doc-ontologias-04doc-ontologias-05
Se ha incluido en la pantalla de consulta de las ontologías una vista de documentación para mostrar solamente la información documental de una ontología en un formato más amigable que un json-schema y con posibilidad de exportar como pdf documental.
doc-ontologias-06doc-ontologias-07doc-ontologias-08doc-ontologias-09
En posteriores versiones se evolucionará la funcionalidad de creación de ontologías mediante modelado UML para poder modelar todas las entidades de un proyecto Sofia2 o Space en un único diagrama y poder representar relaciones lógicas entre ellas a nivel de espacio, generando las ontologías a partir de dicho modelo y de forma inversa poder obtener dicho diagrama a partir de los esquemas de las ontologías creados mediante otros modos y del esquema de relaciones. Con esta funcionalidad se dispondrá de una vista del modelo de dominio completo para un proyecto o Space pudiendo generar un reporte completo documental del mismo siempre actualizado.
doc-ontologias-10doc-ontologias-11
Mejoras documentación de ontologías

Integración de Sigfox con Sofia2

A través de las herramientas de Sofia2 la integración entre Sofia2 y Sigfox es relativamente sencilla (leer post Qué es Sigfox)

A  continuación se realiza una explicación diferenciando el desarrollo sobre la plataforma Sigfox y sobre la plataforma Sofia2.

Captura0.PNG

 Configuración en Sofia2:

Para preparar la integración en Sofia2, primero crearemos la Ontología donde almacenaremos los datos procedentes del dispositivo en crudo.

En nuestro caso, y conociendo todos los parámetros que nos envía Sigfox, creamos la ontología a partir de esta información.

Los campos serán los siguientes:

propierdades

Una vez creada nuestra ontología, la forma más sencillo es levantar un API REST para realizar la ingesta de los datos .Para ello en el apartado de API Manager en la consola de Sofia2 procedemos a crear dicha API, enlazada a la ontología que hemos generado anteriormente.

api1

Una vez creado y publicado el API con una operación POST, disponemos del servicio al cual llamará el dispositivo para enviar la información.

api2

Configuración Backend Sigfox:

Una vez logados en la plataforma de Sigfox, y con los dispositivos activados y agrupados, seleccionaremos el grupo en el cual queremos crear un nuevo callback, el cual afectará a todos los dispositivos agrupados. En este caso configuraremos el envío para los dispositivos  Sigfox Wifi  Geoloc.

sigfoxTIPOS

En la nueva pantalla que se nos muestra, seleccionamos a la izquierda “CALLBACKS”, y creamos una nueva.

Disponemos de  varias opciones para crear callbacks , en este caso seleccionamos “Custom callback” donde tendremos varios tipos de llamadas, dependiendo de la llamada que elijamos enviaremos unos datos u otros. En esta integración, nos interesa geolocalizar los dispositivos y de este modo controlar la posición de los mismos. Por ello generamos un callback de tipo GEOLOC, el cual podrá enviarnos los datos que necesitamos. Como vemos en la siguiente captura, introducimos únicamente los headers y el end point del API que hemos creado anteriormente.

Captura2

En el campo body, se crea el mensaje a enviar, donde seguiremos la estructura de la ontología, señalando aquellos datos que queremos que se envíen. Sigfox parsea los datos de las variables predefinidas entre paréntesis.

En este caso el body que enviamos es el siguiente:

Captura3

Una vez completados estos pasos, y habilitando el callback, nuestros dispositivos Sigfox estarán enviando la información a Sofia2. Puedo revisar el funcionamiento de las llamadas en el apartado de cada dispositivo independientemente, en el menu “MESSAGES”.

Captura4.PNG

Una vez comprobado que el sistema está funcionando, guardando los datos de manera correcta, podemos decir que hemos integrado los dispositivos Sigfox con Sofia2 de manera rápida y sencilla!!!

 

Integración de Sigfox con Sofia2

Integración Sofia2 en Zapier

Appsofia2

Como explicábamos en un post anterior, Zapier es una herramienta de automatización web que permite conectar aplicaciones entre sí y automatizar tareas de manera simple y sin la necesidad de tener conocimientos de programación.

 

Se ha incorporado una nueva APP Sofia2 a Zapier (aplicación de automatización web), esta APP permite automatizar tareas Sofia2 dentro de un flujo Zapier.

Así que podremos hacer cosas como:

  • Como TRIGGER suscribirnos a una ontología que cumpla ciertos criterios (a través de una query) y como ACTION enviar un correo a través de MailChimp
  • Como TRIGGER recibir un correo GMail con un asunto concreto y como ACTION insertar en una ontología para comenzar un proceso analítico.

 

Seguir leyendo “Integración Sofia2 en Zapier”

Integración Sofia2 en Zapier

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

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

Motor de KPIs

En esta release se ha incorporado la definición y creación de KPIs (Key Performance Indicator) en Sofia2. Un KPI consiste básicamente en una métrica que nos ayuda a medir y a cuantificar un progreso en función de unas metas y objetivos planteados, es decir, un KPI se diseña para mostrar cómo es el progreso en un proceso o producto en concreto.

En Sofia2 se ha implementado el concepto de KPI vía el concepto de ontología, en esta se almacenará aquella información procedente de otras ontologías que se considere relevante para el estudio de la evolución de una serie de parámetros.

Por tanto, para crear un KPI, debemos dirigirnos al menú Ontología->Crear Ontología y despues hacer click sobre Crear Ontología de tipo KPI:

kpipantallainiciales

Seguir leyendo “Motor de KPIs”

Motor de KPIs