Gobierno de Ontologías en Sofia2 (parte I)

Como ya conocéis las ontologías son el concepto clave de Sofia2 y el que le da esa visión semántica (en este post podéis ver cómo se trabaja con ontologías en la Plataforma).

 

En este primer post de una serie de 3 definiremos los conceptos básicos:

Gobierno de Ontologías en Sofia2 (parte II)

Gobierno de Ontologías en Sofia2 (parte III)

Otro tema fundamental en un Sistema es que existan una serie de normas, estándares de definición, tipos de datos predefinidos,… en general un gobierno de los conceptos que se manejan en el sistema:

Imaginemos una Smart City en la que Sofia2 se usa como Plataforma IoT para interconectar cualquier tipo de red de sensores, parece lógico que todos los dispositivos envíen la información de su posición geográfica en el mismo formato, o la medida y su magnitud de forma coherente.

Para ayudar en este gobierno Sofia2 propone una serie de recomendaciones de las que en diversos post haremos un repaso.

(no quiero dejar de agradecer a Oscar Sacristán el trabajo como creador e impulsor de estas normas 🙂 Gracias!!!).

Entidades manejadas por la Plataforma

La Plataforma Sofia2 gestiona dos tipos de entidades:

  • Assets. Un asset es todo elemento (físico o virtual) capaz de generar o consumir información de carácter sensorial y gestionarla a través de la Plataforma
  • Ontologías. Una ontología puede no estar asociado a un Asset o bien referirse a un Asset cuando queremos independizar de la fuente de los datos (en este caso los assets generan información y dicha información se modela por medio de ontologías en la Plataforma).

Ontologías

Sofia2 permite crear ontologías a medida conforme a las necesidades del usuario, sin embargo propone un conjunto base de ontologías que permiten modelar todo un Sistema (una Smart City por ejemplo):

  • Feed (medidas). Se trata de la información de medida emitida por los assets conectados. Pueden ser medidas instantáneas, agregaciones por períodos de tiempo, cálculos, etc… Un feed puede recoger varias medidas simultáneamente y todos los feeds deben de estar georreferenciados (puntos, líneas o áreas) pudiendo ser éstos móviles.
  • Command (comandos u órdenes). Se trata de las órdenes enviadas a los assets con capacidades de actuación. Dichas órdenes son asíncronas (no existe respuesta inmediata) por lo que existen dos tipos de comandos.

Comandos request. Las instrucciones enviadas a un Asset.

Comandos response. Las respuestas o ACKs enviadas por los Assets a dichos comandos. Las respuestas a los comandos únicamente indican la confirmación de la recepción de dicha instrucción.

  • Alert (alertas). Las alertas son mensajes de notificación de situaciones (alertas, incidencias, mensajes, notificaciones, etc…) y tienen la particularidad de que su estado así como su nivel de criticidad cambia a lo largo del tiempo desde un mensaje inicial que genera la alerta hasta el cierre de la misma. Las alertas no se conocen a priori, es decir, se generan en el momento en el que suceden.
  • Schedule (eventos). Los eventos reflejan situaciones conocidas en el tiempo y en el espacio, es decir, ocurren durante un periodo de tiempo en un lugar concreto y, normalmente, se conocen a priori.
  • Audit (log). Los mensajes de auditoría o log son internos a la Plataforma y se utilizan para hacer explícitas y dejar gestionadas situaciones concretas particulares de los Assets. Por ejemplo, el encendido de una farola, el mal funcionamiento de un sensor, etc…
  • KPI (indicador). Los indicadores son un tipo especial de medida y su característica principal es que no son generados por un único Asset. Se trata de cálculos realizados sobre múltiples datos, series históricas e incluso capas de datos espaciales que se almacenan como medidas en Plataforma.

 

Assets

Dependiendo de su naturaleza y de cómo se conectan dichos assets a la Plataforma se establece una clasificación de los mismos en:

  • Assets del Inventario de la Plataforma. Son Assets directamente gestionados por la Plataforma (a través de opción Assets) por lo cual se debe de conocer a priori toda la información sobre los mismos que permita conectarse a ellos directamente. Se dividen a su vez en dos tipos:

Managed: Se trata de los Assets conectados a la Plataforma es decir, gestionados por los KPs. Su característica principal es que los KPs que los gestionan necesitan conocer toda la información de acceso físico a los mismos.

Unmanaged. Se trata de Assets conocidos en el inventario de la Plataforma, que generan y consumen información de la misma, pero para los cuales no es responsabilidad del módulo de interconexión su gestión final, es decir, son gestionados por otros sistemas de información que se integran en la Plataforma.

  • Assets Virtuales. Los assets virtuales son a priori no conocidos, generan información y esta llega a la Plataforma a través de integraciones, normalmente contra otros servicios de información en la nube, como por ejemplo las redes sociales.

 

Una vez explicado veamos algunos ejemplos:

Instancia de Ontología Feed para autobús en movimiento:

O una Alerta:

 

Para definir un Asset primero debo elegir o definir un tipo de Asset, en el tipo de Asset están las propiedades fijas para el Asset (como el fabricante) y las de configuración, que se configuran para un Asset concreto.

El Asset Dron01 de tipo JPiDrone: (en breve un miniejército de drones :D)

Gobierno de Ontologías en Sofia2 (parte I)

Un comentario en “Gobierno de Ontologías en Sofia2 (parte I)

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s