Introducción

Las series temporales se gestionan en la plataforma a nivel de ontología, ya que se trata de un tipo de datos especial en el que un conjunto de medidas o señales, se agrupan en una o varias ventanas temporales, que permitan su consulta gestión de forma conjunta.

En una ontología de tipo Timeseries, cada inserción en la plataforma se puede considerar como una señal o medida y deberá ir acompañada de un timestamp, que permita agrupar dicho  valor de la señal o medida en su ventana temporal correspondiente.

Una ontología de tipo TimeSeries se caracteriza por que su esquema describe la estructura de las instancias que recibe el IoTBroker, pero no la estructura de las instancias almacenadas en el motor de Base de datos, esto es, y como veremos mas adelante, la plataforma hace una gestión interna de los datos recibidos, para construir una agrupación mas eficiente de las distintas señales.

Conceptos

A la hora de trabajar con TimeSeries en la plataforma, hay que tener en cuenta los siguientes conceptos cuando se crea una ontología:

• Timestamp: Momento exacto de la medida o señal, es obligatorio en todas las ontologías TimeSeries, de hecho la propia plataforma lo añade de forma transparente por defecto, por lo que no necesario añadir un campo de tipo Timestamp.

• Etiquetas o Tags: Son las propiedades descriptoras de una señal o medida, pero no la medida en sí. Por ejemplo en una ontología TimeSeries que recibe datos de un contador, el identificador del contador y su titular serán etiquetas o tags.

• Campos o Fields: Son las propiedades que representan el valor de una señal o medida en un momento dado.

• Datos Auxiliares: En una ontología TimeSeries, también hay información que pese a estar almacenada en la estructura TimeSeries, es costosa de recuperar en tiempo de procesamiento, debido a la estructura con la que se almacena la información. Por ejemplo, recuperar el último valor recibido, que podria ser un dato muy común, tiene cierto coste computacional en una estructura TimeSeries. Para ello se proporciona la opción Datos auxiliares, que crea otra ontología con el mismo identificador dado a la ontología TimeSeries, junto con el sufijo _stats, de manera que accediendo a la ontología <identificadorOntologia>_stats se disponga de acceso inmediato a dichos datos.

• Motor de Base de datos: La base de datos que se utilice como soporte para almacenar la serie temporal de la ontología es un aspecto muy importante a considerar, ya que de ello depende la estructura de almacenamiento. En un principio la plataforma da soporte a MongoDB, que ya propone una estructura para este tipo de datos que se describirá en puntos posteriores.

Todos estos conceptos los podemos encontrar a la hora de crear una entidad TimeSeries:

Open

Open

El ultimo concepto importante es el siguiente:

• Ventanas temporales: Una ontología TimeSeries puede tener diferentes ventanas temporales. Una ventana temporal es la unidad de tiempo en la que se agrupan las señales o medidas recibidas. Pudiendo ser:

  • Minutal.

  • Horaria.

  • Diaria.

  • Mensual.

Una vez seleccionada la unidad de la ventana, se selecciona la frecuencia de muestreo, eso es, con qué frecuencia se almacenan señales o medidas (muestras) en la ventana. La frecuencia puede ser (siempre en una unidad inferior a la de la ventana):

• Segundos.

• Minutos.

• Horas.

• Dias.

• Meses.

Además, como función de agregado, se puede indicar que política aplicar cuando se reciben varias medidas o señales para el mismo instante temporal en la ventana.

Persistencia en MongoDB

Como Base de datos de referencia para almacenar TimeSeries se ha elegido MongoDB, no obstante queda abierto a introducir nuevos sistemas gestores de base de datos en el futuro.

Una ontología TimeSeries cuyo soporte físico es MongoDB tiene las siguientes características:

• Se crea una colección en MongoDB para dar soporte al almacenamiento de los datos.

• Cuando se recibe una instancia de una ontología TimeSeries, se recupera su timestamp y se comprueba para cada ventana temporal que tenga definida en plataforma, si ya existe un documento en MongoDB para dicha señal y timestamp. Para ello se lanza una query con todos los tags o etiquetas con el valor recibido en estas y por el timestamp de cada ventana. Si existe un documento, este se actualiza en la entrada correspondiente al momento de la señal recibida. Si no existe, se crea un documento con las señales de todos los momentos a valor nulo, excepto para el momento al que pertenece la señal.

• Cada Instancia tendrá un tipo de documento en la colección con la siguiente estructura:

• windowType: Indica el tipo de ventana a la que representa el documento. Dependiendo de las ventanas que se creen desde el control panel, podrá tomar los valores:

  • MINUTES

  • HOURS

  • DAYS

  • MONTHS

• windowFrecuency: Indica la frecuencia de muestro (1 medida o señal cada X tiempo)

• windowFrecuencyUnit: Indica la unidad de frecuencia de muestro. Se aplica junto con windowFrecuency. Pej: 1 medida o señal cada 5 (windowFrecuency) segundos (windowFrecuencyUnit). Podrá tomar los valores:

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

  • MONTHS

• timestamp: Representa la fecha de agrupación de la ventana. En función del valor de windowType tendrá el siguiente formato:

  • MINUTES: yyyy-mm-dd HH:mm:00:00Z

  • HOURS: yyyy-mm-dd HH:00:00:00Z

  • DAYS: yyyy-mm-dd HH:00:00:00Z

  • MONTHS: yyyy-mm-01 00:00:00:00Z

• owner y assetId: Son campos que se declararon como Etiquetas o Tags en la ontología (Ver imagen del punto anterior)

• values: Estructura que contiene cada una de las señales o medidas recibidas en la ventana temporal que agrupa el documento. La estructura depende de la ventana temporal elegida, la unidad de frecuencia y la frecuencia con la que se reciben señales o muestras.

• En la colección se tendrá un documento por cada combinación de:

  • Tags cuyo valor sea igual.

  • Campo o field único.

  • Ventana temporal.

• assetId

• subassetId

• power

• intensity

• Horaria con señales cada segundo

• Diaria con señales cada minuto