Sofia2 participates in the SESIAD Virtual Laboratory

labVirtual

 

The Virtual Laboratory of the Secretary of State for the Information Society and Digital Agenda (SESIAD) was born under the standard UNE 178104 “Integrated management systems of the smart city” with the aim of becoming a benchmark for national and international platforms, being a place of experimentation in which companies and developers can evaluate the compatibility of their products with different Smart Cities platforms.

 

labVirtual

 

Currently, platforms that participate in the Virtual Laboratory are Sofia2, from Minsait by Indra, SmartBrain from Cellnex and Thinking City from Telefónica. They collaborate with SESIAD contributing their expertise and participating in the improvement of interoperability between platforms.

 

plataformas

 

As we saw in IoT Data Models: Initiatives and Sofia2 Data Model, there are different Initiatives of standardization of a Data Model in IoT. A Data Model represents the structure of your data and relationships, and therefore, organizes the elements and standardizes how they relate to each other.

 

gsma1

 

GSMA and FIWARE Data Models are defined in JSON, so their representation as Sofia2’s Ontology is immediate. We saw how they are supported and how easy it is to work with these entities in Sofia2

 

To achieve better interoperability between platforms, NGSI 9/10 v2 was selected as a common protocol for the Interoperability Layer. We saw in this document how they are supported and how to consume APIS modeled according to the semantic FIWARE Data Model and published in Sofia2 following the NGSI 9/10 v2 protocol.

 

In our experience with the Virtual Laboratory, in addition to making recommendations for new attributes and modifications in the Data Model, we had the opportunity to perform a Proof of Concept (PoC) by creating a connection  and transformation flow of real data from Smart City A Coruña to GSMA/FIWARE Data Model on Sofia2’s Platform.

 

In this example, Smart Coruña parking data is collected and is ingested in an Ontology on the Sofia2’s platform. Each time an instance of this ontology is received, a Script is launched and transforms this data adapting them to the Data Model and, consulting them, we see how, effectively, the Data Models are fulfilled.

 

dataingestGSMA

 

Also in this Proof of Concept we could publish this data through the API MANAGER of Sofia2 to later see that anyone with the proper permits can access this data via API, Curl or through the Virtual Laboratory portal.

 

consumptionGSMA

 

 

All this process is explained in the post Acquisition, transformation and consumption of data with GSMA/FIWARE Data Model, and has been captured in the demonstrator, which, in addition to parking data, collects data from beaches and museums.

 

demostrador

 

You can find all the information related to the SESIAD Virtual Laboratory here, as well as all the necessary tools (Data Model, APIs, Security tokens, examples …) to develop on the platforms complying with this interoperability model here

 

 

 

 

Sofia2 participates in the SESIAD Virtual Laboratory

Acquisition, transformation and consumption of data with GSMA/FIWARE Data Model

dataingestGSMA

 

In the post How to work with Data Model FIWARE/GSMA in Sofia2 we saw how the Sofia2 platform supports the GSMA and FIWARE Data Models. We learned how to create Ontologies according to these models and how to insert data and consult them using the tool available on the BDTR and BDH Console. We also saw how to publish this Ontology as a RESTFul API and how to consume the API.

 

In addition, we have the document Use of FIWARE Data Model and API NGSI9 publication, where we explain how to consume APIS modeled conformant FIWARE Data Model semantics and published in the Platform following the NGSI-9 protocol.

 

For the example, we use the Ontologies:

  • GSMA_OffStreetParking_Destino
  • GSMA_PointOfInterest_Beach
  • GSMA_PointOfInterest_Museum

 

Step by step we explains how to subscribe to these Ontologies, how to consult your Data through the BDTR and BDH Console, how to subscribe to NGSI-9 APIs and consume them through the API Manager developer portal and how to access these APIs via Curl.

 

consumptionGSMA

 

With all this information, and knowing that Sofia2 allows you to create Rules Scripts (it is advisable to read the Scripting Engine Sofia2 User Guide) that will be executed before the arrival of instances of Ontologies or every so often, it is easy to understand how we can receive data with a determined structure and transform them to meet these Data Models.

 

We will check it through the following flow:

 

dataingestGSMA

 

In this example, Smart Coruña car park data is collected, an Ontology is ingested on the Sofia2 platform, each time an instance of this ontology is received, a Script is launched that transforms this data adapting it to the Data Model and consulting it, we see as indeed, it is fulfilled with the GSMA and FIWARE Data Models.

 

ejemploparking1

Acquisition, transformation and consumption of data with GSMA/FIWARE Data Model

Sofia2 participa en el Laboratorio Virtual SESIAD

labVirtual

 

El Laboratorio Virtual de la Secretaría de Estado para la Sociedad de la Información y Agenda Digital (SESIAD) nace bajo la norma UNE 178104 “Sistemas integrales de gestión de la ciudad inteligente” con el objetivo de convertirse en una referencia de plataformas a nivel nacional e internacional, siendo un lugar de experimentación en el que empresas y desarrolladores puedan evaluar la compatibilidad de sus productos con diferentes plataformas Smart Cities.

 

labVirtual

 

Actualmente, plataformas que participan en el Laboratorio Virtual son Sofia2, de Minsait by Indra, SmartBrain de Cellnex y Thinking City de Telefónica. Éstas colaboran con SESIAD aportando su expertise y participando en la mejora de la interoperabilidad entre plataformas.

 

plataformas

 

Como vimos en IoT Data Models: Iniciativas y Sofia2 Data Modelexisten diferentes Iniciativas de estandarización de un Data Model en IoT. Un Data Model representa la estructura de tus datos y relaciones, y por tanto, organiza los elementos y estandariza como se relacionan unos con otros.

 

gsma1

 

Los Data Models GSMA y FIWARE se definen en JSON por lo que su representación como Ontología Sofia2 es inmediata. Vimos cómo se soportan y de qué manera tan sencilla se puede trabajar con estas entidades en Sofia2

 

Para conseguir una mejor interoperabilidad entre plataformas, se seleccionó NGSI 9/10 v2 como protocolo común para la Capa de Interoperabilidad. Vimos en este documento cómo se soportan y cómo consumir APIS modeladas conforme semántica FIWARE Data Model y publicadas en Sofia2 siguiendo el protocolo NGSI 9/10 v2.

 

En nuestra experiencia con el Laboratorio Virtual, además de realizar recomendaciones de nuevos atributos y modificaciones en los Data Model, hemos tenido la posibilidad de realizar una Prueba de Concepto (PoC) creando un Flujo de conexión y transformación de datos reales provenientes de Smart City A Coruña a GSMA/FIWARE Data Model en la Plataforma Sofia2.

 

En este ejemplo, se recogen datos de parkings de Smart Coruña y se ingestan en la plataforma Sofia2 a una Ontología. Cada vez que se recibe una instancia de esta ontología se lanza un Script que transforma estos datos adaptándolos a los Data Model y, consultándolos, vemos como efectivamente, se cumple con los Data Model.

 

flujodeconexion

 

También, en esta Prueba de Concepto, pudimos publicar estos datos por medio del API MANAGER de Sofia2, para posteriormente, ver que cualquiera con los debidos permisos, puede acceder a estos datos vía API, Curl o mediante el portal del Laboratorio Virtual.

 

consumodatos

 

Todo este proceso queda explicado en el post Adquisición, transformación y consumo de datos GSMA/FIWARE Data Model, y ha sido plasmado en el demostradorque, además de los datos de parkings, recoge datos de playas y museos.

 

demostrador

 

Puedes encontrar toda la información relativa al Laboratorio Virtual SESIAD aquí, así como todas las herramientas (Data Model, APIs, Tokens de seguridad, ejemplos…) necesarias para desarrollar en las plataformas cumpliendo con este modelo de interoperabilidad aquí

Sofia2 participa en el Laboratorio Virtual SESIAD

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

Adquisición, transformación y consumo de datos GSMA/FIWARE Data Model

flujoDeconexion

En el post Cómo trabajar con Data Model FIWARE/GSMA en Sofia2 vimos cómo la plataforma Sofia2 soporta los Data Models GSMA y FIWARE. Aprendimos cómo crear Ontologías conforme a estos modelos y cómo insertar datos y consultarlos mediante la herramienta disponible en la plataforma Consola BDTR y BDH. También vimos cómo publicar esta Ontología como un API RESTFul y cómo consumir el API.

 

Además, disponemos del documento Uso de FIWARE Data Model y publicación API NGSI9donde se explica cómo consumir APIS modeladas conforme semántica FIWARE Data Model y publicadas en la Plataforma siguiendo el protocolo NGSI-9.

 

Para el ejemplo se utilizan las Ontologías:

  • GSMA_OffStreetParking_Destino
  • GSMA_PointOfInterest_Beach
  • GSMA_PointOfInterest_Museum

 

Paso a paso se explica cómo suscribirnos a éstas Ontologías, cómo consultar sus Datos mediante la Consola BDTR y BDH, cómo suscribirse a APIs NGSI-9 y consumirlas mediante el portal del desarrollador del API Manager y cómo acceder a estas APIs vía Curl.

 

consumoDatos

 

Con toda esta información, y conociendo que Sofia2 permite crear Reglas Scripts (se aconseja leer el documento Guía de Uso Motor Scripting Sofia2) que se ejecutarán ante la llegada de instancias de Ontologías o cada cierto tiempo, es fácil entender cómo podemos recibir datos con una estructura determinada y transformarlos para cumplir con estos Data Models. 

 

Lo comprobaremos mediante el siguiente flujo:

flujoDeconexion

 

En este ejemplo, se recogen datos de parkings de Smart Coruña, se ingestan en la plataforma Sofia2 a una Ontología, cada vez que se recibe una instancia de esta ontología se lanza un Script que transforma estos datos adaptándolos a los Data Model y consultándolos, vemos como efectivamente, se cumple con los Data Models GSMA y FIWARE.

 

ejemploparking

Adquisición, transformación y consumo de datos GSMA/FIWARE Data Model

Data Model GSMA en Sofia2

1

Se ha disponibilizado en Sofia2 la documentación que define el soporte y funcionamiento de los Data Model GSMA en la plataforma Sofia2.

La asociación GSMA (asociación de operadores móviles) está trabajando en un IoT Big Data Harmonised Data Model. Por otro lado en la iniciativa FIWARE se han inspirado en el Data Model GSMA para crear los FIWARE Data Models.

Los Data Models GSMA (también llamados FIWARE DataModel) se definen en JSON, por lo que su representación como Ontología Sofia2 es inmediata. Para ello, haremos uso de las plantillas predefinidas en Sofia2 que soportan los anteriores modelos:

plantillas

En la documentación, que te puedes descargar aquí, o puedes consultar en versión web aquí, encontrarás cómo se definen los modelos de datos en Sofia2 para soportar los Data Models GSMA, ejemplos de uso, y un completo “Hands On” que abarca la creación de Ontologías, carga de datos mediante CRUD de Instancias, consulta de datos con la Consola BDTR y BDH, y cómo publicar Ontologías como API RESTFUL.

Data Model GSMA en Sofia2

Cómo trabajar con Data Model FIWARE/GSMA en Sofia2

La asociación GSMA (asociación de operadores móviles está trabajando en un IoT Big Data Harmonised Data Model

Que define estas entidades: AgriCrop, AgriGreenHouse, AgriParcel, AgriParcelOperation, AgriParcelRecord, AgriPest, AgriProduct, AgriProductType, AgriSoil, AirQualityObserved, Building, BuildingOperation, BuildingType, Device, DeviceModel, DeviceOperation, EnvironmentObserved, Machine, MachineModel, MachineOperation, PointOfInterest, Road, RoadSegment, Subscriber, SubscriptionService,Vehicle, VehicleFault, VehicleType, WaterQualityObserved, WeatherForecast y WeatherObserved.

Por otro lado en la iniciativa FIWAREse han inspirado en el Data Model GSMA para crear los FIWARE Data Models, donde además se han seleccionado un conjunto de Entidades sobre estas de GSMA:

  • Alarms Events related to risk or warning conditions which require action taking.
  • Parks & Gardens Data models intended to make an efficient, effective and sustainable management of green areas.
  • Environment Enable to monitor air quality and other environmental conditions for a healthier living.
  • Point of Interest Specific point locations that someone may find useful or interesting. For instance, weather stations, touristic landmarks, etc.
  • Civic Issue tracking Data models for civic issue tracking interoperable with the de-facto standard Open311.
  • Street Lighting Modeling street lights and all their controlling equipment towards energy-efficient and effective urban illuminance.
  • Device IoT devices (sensors, actuators, wearables, etc.) with their characteristics and dynamic status.
  • Transportation Transportation data models for smart mobility and efficient management of municipal services.
  • Indicators Key performance indicators intended to measure the success of an organization or of a particular activity in which it engages.
  • Waste Management Enable efficient, recycling friendly, municipal or industrial waste management using containers, litters, etc.
  • Parking Real time and static parking data (on street and off street) interoperable with the EU standard DATEX II.
  • Weather Weather observed, weather forecasted or warnings about potential extreme weather conditions.

Los Data Models GSMA y FIWARE se definen en JSON por lo que su representación como Ontología Sofia2 es inmediata (recomendamos al respecto leer el documento Gobierno de Ontologías o el conjunto de posts al respecto).

En Sofia2 se soportan ya estas entidades vía Plantillas (una plantilla sirve para crear ontologías partiendo de una definición):

A continuación veremos cómo Sofia2 permite trabajar con estas entidades, pongamos el ejemplo de la entidad WeatherObserved (This entity contains a harmonised description of the weather at a particular location and time. This entity is primarily associated with the vertical segments of the environment and agriculture but is applicable to many different applications):

Seguir leyendo “Cómo trabajar con Data Model FIWARE/GSMA en Sofia2”

Cómo trabajar con Data Model FIWARE/GSMA en Sofia2