Informe del sistema de tratamiento y análisis de datos masivos€¦ · Figura 1: Arquitectura del módulo desarrollado por ITI en CEI. 9 Figura 2. Data wrangling en Scala, fragmento

© 2017 Instituto Tecnológico de Informática 24 de enero de 2017

Informe del sistema de tratamiento y análisis de

datos masivos

CIUDAD ENERGÉTICAMENTE INTELIGENTE (CEI)

Entregable E4.2

E4.2 CIUDAD ENERGÉTICAMENTE INTELIGENTE (CEI) PÁGINA 2 de 36


Abstract

Big Data Analytics system report

CEI (Ciudad Energéticamente Inteligente – Energetically Smart City) aims at improving the energy and environment conditions of living areas of the city, by managing correctly the existing infrastructures and resources. The improvement will be enabled by the development of technology systems (energy nodes control technologies, energy‐environmental sensors technologies, technologies for the improvement of maintenance methodologies) that make possible the control of energy and environment conditions of those areas.

This project is funded by the Instituto Valenciano de Competitividad Empresarial (IVACE) and the European Union through the Fondo Europeo de Desarrollo Regional (FEDER).

This work package aims at designing and developing the ICT system associated to the energy management systems considered in the project. The first layer of this architecture tackles data acquisition: energy data, weather data, and other relevant data from the energy management systems deployed in the city.

After data collection, the system implements two analysis modules:

A rule‐based correlation engine, which will identify events over a subset of data sources.

A big data analytics engine, which will learn from historical data by applying statistical techniques.

This document describes the components of the Big Data Analytics platform, focusing on the data processing and analysis (both statistical and rule‐based). Finally, a front‐end web shows the information handled by the platform.


Resumen

El objetivo de este paquete de trabajo es el diseño y desarrollo del sistema TIC asociado a los sistemas de gestión energética desarrollados en el proyecto. De este modo, se recopilarán los datos que se recojan en el proyecto a nivel de la ciudad, se procesarán y extraerá información útil que se mostrará en una herramienta de asistencia a la toma de decisiones.

La plataforma resultante incluye en primer lugar una primera capa de adquisición de datos, cuyo objetivo es recibir datos energéticos y otros datos relevantes desde los sistemas de gestión energética desplegados por la ciudad. Una vez recogidos y almacenados dichos datos, la arquitectura cuenta con dos capas para su análisis inteligente:

Un motor de correlación basado en reglas permite declarar eventos sobre un sub‐conjunto de fuentes de datos concretos.

Un motor de análisis de datos basado en técnicas de Big Data y análisis estadístico de datos, que permite un análisis más profundo sobre una gran cantidad de fuentes de datos, teniendo en cuenta para ello datos históricos.

Para proporcionar estos servicios TIC, se ha desarrollado un back‐end escalable basado en Cloud Computing, junto con un front‐end con interfaz web para la visualización de los datos y los resultados del análisis.

El trabajo realizado en este sistema TIC se aborda en dos entregables del proyecto CEI: E4.1 y E4.2. El primero de ellos se centró en la descripción de la infraestructura TIC: arquitectura cloud, el sistema de captación de datos y el motor de correlación de datos basado en reglas. Por otra parte, el entregable E4.2, el presente documento, describe los componentes finalmente implementados en la plataforma, centrándose en el tratamiento y análisis de datos empleando técnicas estadísticas sobre la infraestructura Big Data, y las técnicas basadas en reglas sobre el motor de correlación. Además, se describen los módulos encargados de la visualización.

La integración y validación de la plataforma se abordará en los entregables E6.4 (Herramienta final de mantenimiento), E5.3 (Informe de incorporación de fuentes de datos abiertas del entorno), y E7.2 (Testeo del sistema en ITI).


Tabla de Contenidos

Resumen ............................................................................................................................................ 3

1. Introducción .............................................................................................................................. 8

1.1. Descripción del proyecto ............................................................................................................. 8

1.2. Objetivos del documento ............................................................................................................ 8

1.3. Arquitectura y estructura del documento ................................................................................... 9

2. Interfaz de comunicaciones. ..................................................................................................... 10

2.1. Comprobar el funcionamiento del API ...................................................................................... 11

2.2. Declaración de un nuevo dataSource en el sistema .................................................................. 12

2.3. Declaración de sensores asociados a un dataSource ................................................................ 12

2.4. Inserción de medidas ................................................................................................................ 13

2.5. Obtención de medidas de un sensor ......................................................................................... 13

3. Repositorios y tratamiento de datos ......................................................................................... 13

3.1. Base de datos intermedia ......................................................................................................... 14

3.2. Repositorio big data .................................................................................................................. 14

3.3. Tratamiento de datos................................................................................................................ 15

3.3.1 Data fusion ....................................................................................................................... 15

3.3.2 Data wrangling ................................................................................................................. 16

4. Análisis de datos basado en modelado estadístico .................................................................... 18

4.1. Estado del arte y de la práctica en el análisis de datos de edificios .......................................... 18

4.1.1. Progreso con respecto al estado del arte ............................................................................. 19

4.2. Motor de análisis estadístico .................................................................................................... 19

5. Análisis de datos basado en reglas ............................................................................................ 21

5.1. Control estadístico de calidad para la detección de anomalías ................................................ 21

5.2. Motor de alertas ....................................................................................................................... 22

6. Front‐end web ......................................................................................................................... 23

6.1. Arquitectura software ............................................................................................................... 24

6.2. Metodología de desarrollo ........................................................................................................ 26

6.3. Pantallas ................................................................................................................................... 27

6.3.3 Landing page .................................................................................................................... 27

6.3.4 Pantalla de cuadro de mando del sistema ....................................................................... 29


6.3.5 Pantalla de configuración de edificios .............................................................................. 30

6.3.6 Pantalla de configuración de usuarios ............................................................................. 31

6.3.7 Pantalla de configuración de parámetros de la web ........................................................ 32

6.3.8 Pantalla de visualización de correlaciones ....................................................................... 32

6.3.9 Pantalla de visualización de datos de los sensores .......................................................... 33

6.3.10 Pantalla de consulta de histórico de anomalías ............................................................... 34

6.3.11 Pantalla de consulta del detalle de la anomalía ............................................................... 34

7. Conclusiones ............................................................................................................................ 35

8. Referencias bibliográficas ......................................................................................................... 36


Tabla de figuras

Figura 1: Arquitectura del módulo desarrollado por ITI en CEI. 9 Figura 2. Data wrangling en Scala, fragmento de código. 16 Figura 3. Diagrama entidad relación de base de datos CEI. 17 Figura 4. Optimización de modelos Deep learning. 21 Figura 5. Detección de anomalías con análisis de residuos. 22 Figura 6. Plan de ejecución CEI en WSO2 CEP. 23 Figura 7. Árbol de navegación de la herramienta de visualización de datos. 24 Figura 8. Tecnologías empleadas en front‐end. 25 Figura 9. Front‐end: landing page. 27 Figura 10. Front‐end: open data caster o CKAN. 28 Figura 11. Front‐end: pantalla de Log‐in. 28 Figura 12. front‐end: dashboard. 29 Figura 13. Front‐end: configuración de edificios. 30 Figura 14. Front‐end: configuración de usuarios. 31 Figura 15. Front‐end: configuración de la web. 32 Figura 16. Front‐end: correlaciones. 32 Figura 17. Front‐end: datos del sensor. 33 Figura 18. Front‐end: histórico de anomalías. 34 Figura 19. Detalle de las anomalías. 34


1. Introducción

1.1. Descripción del proyecto

El proyecto CEI propone mejorar el estado energético y ambiental de áreas habitadas de las ciudades a través de la correcta gestión de las infraestructuras y recursos que disponen las mismas.

Esta mejora se propone desde el desarrollo de sistemas tecnológicos que permitan controlar los estados energéticos y ambientales de áreas que tiendan a ser optimizadas energéticamente. Habitualmente, y más con la irrupción de las Redes Inteligentes, estas áreas dispondrán de:

• Nodos de consumo. • Nodos de generación y almacenamiento. • Nodos de consumo que disponen de recursos de generación y almacenamiento

integrados. Nodos Activos. • Nodos observables y controlables de la red de distribución de energía. • Servicios tecnológicos asociados.

Por tanto, el proyecto propone el diseño y desarrollo de un sistema global de gestión inteligente de este tipo de áreas. Los niveles de gestión de los que se compone el sistema CEI propuesto (“Ciudad Energéticamente Inteligente”) son los siguientes:

• Nivel de medida y actuación energética – ambiental. • Nivel de controladores automatizados de campo para mejora energética ‐

ambiental. • Nivel de centro de control energético – ambiental. • Nivel de aplicaciones distribuidas orientadas a usuarios.

El proyecto, además, para lograr un entorno energético y ambiental mejorado, propone, aparte de gestionarlo adecuadamente en cuanto a sus usos energéticos, el diseño y desarrollo de una herramienta integral de mantenimiento avanzado que trabaje en colaboración con los otros sistemas de gestión energética.

Esta herramienta de mantenimiento permitirá:

• Adelantarse a posibles situaciones anómalas de funcionamiento que hayan podido ser detectadas predictivamente mediante el análisis inteligente de las variables energéticas que rigen su funcionamiento.

• Asignar adecuadamente los recursos de mantenimiento para las infraestructuras de consumo y recursos implicados en las áreas de gestión.

1.2. Objetivos del documento

El objetivo de este documento es la descripción del tratamiento y análisis de datos sobre la infraestructura TIC desplegada por el ITI dentro del proyecto CEI. Se revisa la arquitectura general del sistema, así como la configuración final de cada uno de sus componentes. Se hace especial hincapié en las técnicas de preparación de datos y análisis estadístico basado en big data analytics, además de la herramienta de visualización final.


1.3. Arquitectura y estructura del documento

Figura 1: Arquitectura del módulo desarrollado por ITI en CEI.

Tal y como se aprecia en la Figura 1, la arquitectura TIC planteada en el documento E2.1 se compone de los siguientes componentes:

• Servicios web (privados).

Capa de comunicación con el resto de sistemas del proyecto. Recibe o pide los datos provenientes de los sensores desplegados o los resultados de análisis realizados por otros sistemas externos.

• Planificador.

Organiza la recogida de datos, adaptándose a las necesidades de sus proveedores. Puede pedirlos de manera activa o recibirlos de manera pasiva.

• Big Data.

Módulo encargado de gestionar la infraestructura sobre la que se almacenan los datos y se llevan a cabo los análisis estadísticos. Se adopta una filosofía big data para hacer frente al volumen, variabilidad y velocidad de los datos.

• Modelado de contexto.

Módulo encargado del análisis de los datos y la generación de eventos. El análisis se basa en la aplicación de modelos estadísticos aprendidos automáticamente a partir de colecciones de datos históricos.

• Gestión de alertas y actuaciones.


Módulo encargado de aplicar reglas lógicas previamente establecidas para la generación de alertas o actuaciones a partir de la lectura de los datos o los eventos generados por los modelos estadísticos.

• Servicios web (open data).

Capa de comunicación con herramientas externas y de visualización, a las que se les ofrece vía API los datos recogidos, los resultados de los análisis realizados, o las alertas generadas.

• Interfaz (web, móvil).

Aplicación gráfica para mostrar los datos recogidos, los resultados de los análisis realizados, o las alertas generadas. Se contemplan tres roles de usuarios en el proyecto: ciudadano, administración y mantenimiento.

• M2M.

Posible comunicación máquina a máquina para ofrecer los datos recogidos, los resultados de los análisis realizados, o las alertas generadas.

• Empresas externas autorizadas.

Empresas externas que pueden acceder a los datos recogidos, los resultados de los análisis realizados, o las alertas generadas para la implementación de sus propias aplicaciones.

El presente documento detalla la implementación final de los componentes anteriores en las siguientes secciones:

• Interfaz de comunicaciones. Cubre los componentes de servicios web privados, el planificador, servicios web (open data), M2M, Empresas externas autorizadas.

• Repositorios y tratamiento de datos. Cubre el componente big data. • Análisis de datos basado en modelado estadístico. Cubre el componente modelado

de contexto. • Análisis de datos basado en reglas. Cubre el componente gestión de alertas y

actuaciones. • Front‐end web. Cubre el componente interfaz.

2. Interfaz de comunicaciones.

Este módulo ofrece mecanismos para interactuar con la plataforma desarrollada por ITI en el proyecto CEI. De este modo, otras plataformas pueden enviar datos (como es el caso de la implementada por ITE), o consultar datos y resultados (es decir, servicios web open data para M2M o empresas externas autorizadas).

La interoperabilidad se implementa a distintos niveles:

• Estándares. La comunicación se basa en tecnologías estándar bien conocidas. El ITI publica un API basada en servicios web REST para el intercambio de mensajes JSON.

• Identificación. La información manejada se identifica correctamente: cada sensor, fuente de datos, canal, medida, resultado, etc. se registra en catálogos.


• Planificador. Este módulo puede ser pasivo (es decir, espera hasta que algún elemento externo solicita el comienzo de un proceso de comunicación); o activo (se consultan APIs externos para solicitar nuevos datos).

La capa de comunicaciones debe ser compatible con aplicaciones externas heterogéneas, ofreciendo una interfaz común, versátil y abstracta. Para ello, se definen los siguientes conceptos:

• Fuente de datos (data source): cada dispositivo que pueda enviar datos a la interfaz. Usualmente, coordinadores de red o gateways que almacenan medidas de sus sensores asociados y periódicamente los envían a nuestro servidor.

• Catálogo: conjunto de sensores asociados a una fuente de datos concreta. • Sensor: un dispositivo que captura medidas de su entorno a través de uno o más

canales. Estas medidas se envían a su fuente de datos correspondiente. • Canal (channel): medida física asociada a un sensor.

Se ofrecen los siguientes servicios web REST implementados en Python:

• Registro de fuentes de datos. • Registro de un catálogo. • Envío de datos. • Consulta de datos.

Estos servicios se pueden invocar a través de una URL del tipo:

http://servidor:puerto/cei-api/rest/[input|output]/servicio

Los pasos habituales son:

1. Registro de cada fuente de datos que vaya a enviar medidas. 2. Registro del catálogo de sensores y canales de la fuente de datos. 3. Envío de medidas.

En primer lugar, los servicios ofrecidos se podrán acceder a partir de esta dirección, añadiendo posteriormente el método adecuado que quieres invocarse o usarse:

Root URL: xxx

Un ejemplo (no exclusivo) de cómo modelar el sistema podría ser:

DataSource (fuente de datos): que sirve para abarcar un conjunto de elementos, en este caso, podría ser una micro‐red.

Sensor: podría modelar a cada uno de los edificios que aglutina una micro‐red.

Channels (canales): son cada uno de los valores y medidas que puede proporcionar un edificio.

A continuación, se muestran ejemplos de las principales llamadas que pueden efectuarse con los servicios ofrecidos incluyendo unos ejemplos genéricos.

2.1. Comprobar el funcionamiento del API

Este método permite comprobar si los servicios están actualmente “levantados” en la máquina servidora. Se devuelve un JSON con información descriptiva sobre el servidor. Obviamente si al


realizar la llamada al servicio se retorna algún valor implica que la máquina servidora es accesible y ejecutando los servicios web.

2.2. Declaración de un nuevo dataSource en el sistema

En este caso se procede a declarar el dataSource con los siguientes campos obligatorios:

• dataSourceName: nombre alfanumérico para el dataSource. Será usado por el usuario como identificador del mismo.

• address: establece una dirección (usualmente IP/DNS/MAC) para declarar la procedencia general de datos, aunque no impide usar cualquier otro tipo de direccionamiento. Son datos descriptivos.

• description: cualquier otra información que desee indicarse para el objeto. • sensors: listado de sensores del dataSource. Puede estar a valor ‘null’ y ser

declarados los sensores posteriormente. Los campos de los sensores se describen en apartado posterior.

Retorna un identificador interno usado por la base de datos para el dataSource. Ese identificador es de uso interno. Si además se han facilitado sensores también se facilitarán sus identificadores internos.

2.3. Declaración de sensores asociados a un dataSource

Hay que hacer notar que el dataSource debe estar declarado previamente antes de proceder al registro de sensores asociados al mismo. Se facilita una lista con los sensores que dispone el dataSource. Por cada sensor se definen los siguientes campos:

• sensorName: nombre alfanumérico para el sensor. Será usado por el usuario como identificador del mismo.

• address: establece una dirección (usualmente IP/DNS/MAC) del sensor dentro de su red/dominio (dataSource) , aunque no impide usar cualquier otro tipo de direccionamiento. Son datos descriptivos.

• description: cualquier otra información que desee indicarse para el sensor. • sensorType: información descriptiva sobre el tipo de sensor, que puede ser

empleada para caracterizar al mismo sensor. • sensorsChannels: que contiene un listado con cada uno de los canales asociados al

sensor. La descripción de los canales se comenta a continuación.

Por cada canal se tiene:

• channelId: identificador con valor numérico entero para el canal. • unit: unidad empleada por el valor proporcionado por el canal, como puede ser

“m”, “l”, “kg” o cualquier otra. Es información descriptiva. • maximumValue: información descriptiva sobre el posible máximo valor que puede

retornar el canal. • minimumValue: información descriptiva sobre el posible mínimo valor que puede

retornar el canal. • granularity: proporciona información sobre la granularidad o distancia entre dos

medidas consecutivas. • tolerance: proporciona información sobre el error o tolerancia máxima que

devuelve la sonda.


• sensorDataType: información descriptiva sobre el tipo de datos que proporciona la sonda (int, long, float, string, …), aunque puede emplearse para cualquier otro propósito de caracterización descriptiva de la sonda.

• location: empleado para especificar la localización física de la sonda. Retorna una secuencia con los identificadores de uso interno que han sido asociados a los sensores.

2.4. Inserción de medidas

Este método es empleado para insertar valores de medidas procedentes por cada dataSource, sensor y sus canales. Se facilita un JSON en el método POST en la que se indica el dataSourceName para el cual se proceden a insertar medidas. A continuación, en el ‘incomingDataSensorPayloadMessage’ se especifica una lista con cada uno de los sensores que se van a proporcionar las medidas:

• sensorName: en la que se indica el identificador de sensor. • incomingDataSensorChannelsPayload: en la que se incluyen las medidas por los

canales del sensor, que se corresponden con: o measureTimestamp: que indica el valor de timestamp en el que se efectuó la

medida. o channelId: que indica el identificador de canal. o measureValue: que indica el valor de la medida en sí.

Retorna una lista con los identificadores usados internamente por cada una de las medidas insertadas.

2.5. Obtención de medidas de un sensor

En este método pueden especificarse los parámetros para obtenerse información más “refinada”. Si no se especifica ninguno se retorna todos los datos de la base de datos. El orden de parámetros es el siguiente:

• Parámetro 1: indica el nombre del dataSource. • Parámetro 2: indica el nombre del sensor. • Parámetro 3: indica el identificador de canal.

Existen adicionalmente otros métodos para proporcionar información más precisa, como puede ser estableciendo una serie de fechas.

3. Repositorios y tratamiento de datos

Este módulo se encarga del almacenamiento y preparación de la información manejada por la plataforma. Así, se diferencian dos repositorios:

• Base de datos intermedia basada en MySQL. La interfaz de comunicaciones emplea este repositorio para almacenar la información: medidas de sensores, resultados de los análisis estadísticos, etc.

o Se ha primado un acceso rápido a costa de la capacidad de almacenar grandes cantidades de datos, para lo cual se cuenta con el repositorio basado en tecnologías big data. Así, el API podrá ofrecer unos tiempos de respuesta


menores. Por ello, será necesario eliminar periódicamente información de esta base de datos, constituyendo un repositorio temporal.

• Repositorio big data. La información se almacena en Hive, dentro del clúster big data del ITI. De este modo se garantiza:

o Escalabilidad. El repositorio puede almacenar grandes cantidades de datos, tanto las medidas de los sensores desplegados en la ciudad, como los resultados producidos por los modelos estadísticos. En caso de ser necesario, el clúster puede añadir nuevos nodos de manera transparente para aumentar la capacidad de almacenamiento.

o Robustez. El factor de replicación propio de HDFS asegura que la información se mantendría en caso de una hipotética pérdida o corrupción de nodos.

o Almacenamiento y procesado distribuido. La distribución de los datos entre los nodos permite la implementación de potentes algoritmos paralelos imposible en una arquitectura no big data.

• Tratamiento de datos: data fusión y data wrangling. Se fusiona la información procedente de diferentes sensores y se prepara para la posterior aplicación de técnicas estadísticas. Este módulo se implementa en Spark, de manera que se pueden procesar las grandes cantidades de datos que maneja Hive en un tiempo razonable.

3.1. Base de datos intermedia

Se han definido las siguientes tablas para almacenar la información que llega al API y los resultados de los análisis (éstos últimos se consideran como un canal más asociado al sensor), como se muestra en la Figura 3:

• CONFIG_DewiServerIface. Almacena la configuración y descripción del servidor que aloja los servicios.

• CATALOGUE_DataSource. Almacena información de cada Fuente de datos. • CATALOGUE_Sensor. Almacena información de los sensores asociados a una Fuente de

datos determinada. • CATALOGUE_SensorChannel. Almacena información de los canales asociados a un

sensor determinado. • DATA_IncomingData. Almacena cada medida recibida por una Fuente de datos. • DATA_IncomingDataChannel. Almacena cada canal asociado a cada medida.

3.2. Repositorio big data

Los datos manejados en la plataforma se almacenan en la infraestructura big data que se detalló en el entregable E4.1, permitiendo su tratamiento posterior de manera distribuida. Para ello, un script en Scala conecta periódicamente con la base de datos MySQL descrita en el punto anterior para recopilar los nuevos datos que hayan llegado a través del API. A continuación, se muestra un fragmento de dicho código.

package com.cloudera.datascience import scala.reflect.runtime.universe import org.apache.log4j.Level import org.apache.log4j.Logger import org.apache.spark.SparkConf import org.apache.spark.SparkContext import org.apache.spark.sql.SQLContext import org.apache.spark.sql.SaveMode import org.apache.spark.sql.functions.avg import org.apache.spark.sql.functions.count import org.apache.spark.sql.functions.dayofmonth import org.apache.spark.sql.functions.expr


import org.apache.spark.sql.functions.hour import org.apache.spark.sql.functions.max import org.apache.spark.sql.functions.min import org.apache.spark.sql.functions.minute import org.apache.spark.sql.functions.month import org.apache.spark.sql.functions.second import org.apache.spark.sql.functions.sum import org.apache.spark.sql.functions.udf import org.apache.spark.sql.functions.unix_timestamp import org.apache.spark.sql.functions.year import org.apache.spark.sql.types.StringType import org.joda.time.DateTime; import org.joda.time.DateTimeConstants; import org.joda.time.format.DateTimeFormat; import org.joda.time.format.DateTimeFormatter; import org.apache.spark.storage.StorageLevel; object General_a extends App { Logger.getLogger("org").setLevel(Level.OFF) Logger.getLogger("akka").setLevel(Level.OFF) var HOST = "192.168.180.22"; var DB = "cei"; var HIVE = "cei" val MYSQL_DRIVER = "com.mysql.jdbc.Driver"; var MYSQL_USERNAME = "cei"; var MYSQL_PWD = "*****"; var horas = 1; if(args.length == 5) { HOST = args(0).asInstanceOf[String]; DB = args(1).asInstanceOf[String]; HIVE = args(2).asInstanceOf[String]; MYSQL_USERNAME = args(3).asInstanceOf[String]; MYSQL_PWD = args(4).asInstanceOf[String]; } if(args.length == 6) { HOST = args(0).asInstanceOf[String]; DB = args(1).asInstanceOf[String]; HIVE = args(2).asInstanceOf[String]; MYSQL_USERNAME = args(3).asInstanceOf[String]; MYSQL_PWD = args(4).asInstanceOf[String]; horas = Integer.parseInt(args(5)); }

3.3. Tratamiento de datos

Este módulo prepara los datos almacenados en Hive para la aplicación posterior del modelado

estadístico. Se compone de dos pasos: data fusion y data wrangling. Ambos se implementan

mediante scripts de Scala que interactúan con Spark y Hive.

3.3.1 Data fusion

La fusión de los datos persigue integrar diferentes fuentes de datos para crear unidades estadísticas que serán empleadas en los análisis posteriores. En el caso de CEI, se ha considerado interesante correlacionar los valores actuales de un sensor con sus valores anteriores. El procedimiento es como sigue:

• Unificación de tablas. Cada fila tendrá toda la información relativa a una medida en concreto (en los pasos previos se encontraba dispersa en varias tablas).

• Cálculo de estadísticas básicas: media, máximo, mínimo, suma y contador. • Desagregación de la información temporal. Para cada timestamp, se obtiene su hora,

número de día, día de la semana, mes y año. • Agrupamiento temporal al nivel de minuto (parametrizable), de manera que cada

medida tendrá un único valor por minuto (en el caso de que la medida tuviera una mayor frecuencia, se calcularía la media en ese minuto). Se trata de una manera eficaz para implementar el alineamiento temporal entre varias variables. En caso de que no hubiera ningún valor en ese intervalo de tiempo, se interpola con la información de


valores anteriores y posteriores. Todos los cálculos se realizan en Spark de manera distribuida.

• Agrupamiento multidimensional de todas las medidas de interés (y sus estadísticas) (columnas) en cada minuto (filas).

3.3.2 Data wrangling

Preparación de las unidades multidimensionales previamente obtenidas para ser ingeridas como series temporales por parte del módulo de análisis estadístico. El objetivo es añadir a cada fila la información de los instantes anteriores, de manera que cada unidad estadística se compone de una serie temporal que puede ser procesada directamente por las técnicas Deep learning. La Figura 2 muestra un fragmento de este código.

Figura 2. Data wrangling en Scala, fragmento de código.


Figura 3. Diagrama entidad relación de base de datos CEI.


4. Análisis de datos basado en modelado estadístico

Este componente se encarga del análisis de los datos almacenados en la plataforma a nivel de ciudad con el objetivo de extraer información útil más allá de las medidas en crudo. En concreto, se centra en la aplicación de técnicas de Deep learning para la predicción de valores futuros de las medidas y para la detección de situaciones anómalas en los datos actuales. En resumen:

• Se implementan técnicas de aprendizaje automático (machine learning) que aprovechan la infraestructura big data tanto para almacenamiento como para procesado de los datos. Para ello, se utiliza Spark, MLLib y H2O.

• En concreto, se aplican técnicas basadas en Deep learning, que han demostrado su adecuación en este contexto (ver sección de estado del arte).

• Estas técnicas se aplican tanto para la predicción de valores futuros como para la detección de anomalías, comparando el valor predicho con el valor real.

• La evaluación de estos modelos se realiza mediante MSE. • La optimización de los parámetros se realiza mediante una búsqueda grid search. • Se implementa una rutina para entrenar modelos a partir de datos estadísticos. Estos

modelos se almacenan en HDFS. • Se implementa una rutina para analizar los nuevos datos que llegan a través del API. Se

considerarán anómalos según la diferencia entre dichos datos y las predicciones realizadas por los modelos previamente entrenados. Los resultados se almacenan en los repositorios (MySQL y Hive), de forma que estarán disponibles a través del API. Adicionalmente, se publican las anomalías en un servidor MQTT interno para que posteriormente puedan ser analizadas por el motor de correlación.

4.1. Estado del arte y de la práctica en el análisis de datos de edificios

A continuación, revisamos brevemente publicaciones recientes sobre las tecnologías que se emplean habitualmente para el análisis de datos medidos en edificios, y como se implementan en los sistemas de automatización de edificios. De esta manera, mostraremos la adecuación de las técnicas que basadas en Deep learning que aplica nuestro componente de análisis de datos.

Xiao y Fan [1] destacan los beneficios de las técnicas de minería de datos para analizar los datos recogidos en los edificios actuales. Indican además que, aunque se han empleado en estudios anteriores, en raras ocasiones se aplican sobre grandes cantidades de datos, por lo que no aprovechan todo su potencial. Por su parte, Fan et al. [2] añaden que cuando se aplican técnicas de análisis de datos sobre edificios, no se suele estudiar las relaciones temporales, limitándose al análisis de correlaciones entre variables en un instante dado.

Foucquier et al. [5] revisan las técnicas principales para predecir el consumo energético en edificios, destacando el aprendizaje automático (machine learning). La fiabilidad de estas técnicas depende en gran medida de la calidad y cantidad de los datos disponibles. Pese a que no es sencillo comparar diversas técnicas, ya que dependen de los datos con que se han entrenado, los autores subrayan que los métodos más utilizados para la predicción energética son las redes neuronales artificiales y las máquinas de soporte vectorial. En concreto, Mocanu et al. [4] demuestran cómo las técnicas actuales de Deep learning logran resultados de mejor calidad que el resto.


Finalmente, Najafabadi et al. [6] resaltan el auge de las técnicas de Big data analytics, y en particular Deep learning. Big data ha crecido en importancia para organizaciones tanto públicas como privadas que disponen de grandes cantidades de datos sobre un dominio específico, que pueden contener información útil para resolver diversos problemas. Los algoritmos de Deep learning extraen abstracciones complejas de alto nivel analizando grandes cantidades de datos de manera no supervisada, constituyendo pues una valiosa herramienta ya que la mayor parte de los datos que se recogen en edificios (y en la mayoría de entornos) no están etiquetados ni categorizados.

4.1.1. Progreso con respecto al estado del arte

El resumen del estado del arte del apartado anterior confirma que las técnicas propuestas en CEI se pueden considerar punteras y un avance claro en diversos aspectos:

• Se analizan los datos recogidos en edificios con técnicas punteras de aprendizaje automático, como es el Deep learning.

• Se almacenan y procesan grandes cantidades de datos en una arquitectura big data. • En comparación con otros sistemas, los sistemas de gestión de edificios habituales no

suelen aprovechar las grandes cantidades de datos que recogen continuamente. • Además, los estudios previos en este campo raramente analizan la componente

temporal de los datos recogidos. • Se adaptan y ajustan las técnicas a las necesidades y datos del proyecto CEI.

4.2. Motor de análisis estadístico

Tal y como se ha comentado anteriormente, este componente aplica técnicas de aprendizaje automático para obtener modelos estadísticos que analicen los nuevos datos que lleguen al API. En concreto, los modelos Deep learning empleados se especializan en la predicción de los futuros valores de las medidas. Sin embargo, hemos encontrado interesante extender su aplicación para la detección de anomalías en los datos, que se enviarán al módulo de mantenimiento del proyecto como síntoma de posibles problemas a corregir.

Se han implementado scripts en Python para el entrenamiento de los modelos y su uso para predecir futuros valores y analizar anomalías en datos presentes. Se han invocado librerías big data (Spark MLlib y H2O), capaces de resolver problemas de escalabilidad, tanto en términos de almacenamiento como de procesamiento. De este modo, los principales pasos son:

• Se parte de un conjunto de datos históricos para la fase de experimentación y la optimización de las técnicas. El conjunto se divide en:

o Producción, con los datos de los últimos 100 intervalos temporales. Esta partición se empleará para evaluar nuestros modelos finales, simulando un escenario real en el que llegan nuevos datos en tiempo real.

o Desarrollo, compuesto por el resto de los datos. Esta partición se usará para entrenar y optimizar los modelos estadísticos.

• Para cada terna fuente de datos‐sensor‐canal, se entrena un modelo Deep learning para predecir el próximo valor de dicho canal. Así, la capa de salida de la red será la predicción del valor. Por su parte, la capa de entrada se compone de los valores de los canales del mismo sensor de los últimos n intervalos temporales. Cabe recordar que tanto los valores utilizados en la capa de entrada como el valor predicho fueron preparados en la fase de data wrangling para facilitar el montaje de esta red neuronal.


• Optimización de hiperparámetros. Este paso persigue encontrar la mejor configuración de cada modelo. Para ello, comparamos la calidad de modelos con diversas configuraciones en cuanto a número de capas, neuronas por capa, épocas, activación, dropout, etc. La búsqueda de estos hiperparámetros se optimiza siguiendo una estrategia de red aleatoria. La Figura 4 muestra un ejemplo de una de las optimizaciones realizadas, en la que cada línea se corresponde con un modelo con unos parámetros determinados. El número final de cada fila es la desviación residual, que se toma como medida de calidad. Para evitar el sobre‐entrenamiento, la optimización se valida con un 10% de la partición de producción, que no se utilizarán en el resto de fases de entrenamiento. Otro 10% se separa para el testeo final. El 80% restante se emplea para el entrenamiento de los modelos estadísticos.

• Una vez que la fase de optimización ha encontrado la mejor configuración del modelo, lo evaluamos con la partición de producción separada en el primer paso, datos que no ha visto en el entrenamiento, por lo que se asemeja a una situación real.

• Evaluación de los modelos. Para evaluar de manera automática la calidad de los modelos entrenados, analizamos la variabilidad de los sensores que estamos prediciendo. Esta variabilidad (SStot, suma de cuadrados total) se puede dividir en la variabilidad capturada por las variables introducidas en el modelo (SSreg, suma de cuadrados explicada), y la variabilidad que se corresponde con el resto de variables no contempladas (SSres, suma de cuadrados residual).

SStot=SSreg+SSres En un buen modelo, SSres será bajo, ya que el modelo será capaz de explicar la mayor parte de la variabilidad. En general, el coeficiente de determinación (R2) evalúa su relación:

R2=100*SSreg/SStot De esta forma, R2 es un estadístico que proporciona información sobre lo bien que se ajusta el modelo. En regresión, R2 indica lo bien que se aproxima a los datos reales. Si R2 es igual a 1, significa que la regresión se ajusta perfectamente a los datos. Además de R2, utilizaremos el MSE (error mínimo cuadrado) para evaluar los modelos, que estima el error de las predicciones en las mismas unidades que el valor predicho (KW, KWh, etc.).

• Todos estos pasos se implementan en dos scripts Python: o Entrenamiento. Se ejecuta periódicamente para añadir al conjunto de

entrenamiento los nuevos datos que han llegado desde la última ejecución. De esta manera, nuestros modelos se adaptan continuamente a las características actuales de los datos. La primera ejecución de este script inicializa los modelos con un conjunto histórico de datos.

o Análisis. Se ejecuta periódicamente para generar nuevas predicciones futuras tomando en cuenta los datos llegados desde su última ejecución. Además, el script analiza los datos para detectar anomalías. Las predicciones y sus diferencias con los datos reales se envían por MQTT al motor de correlación (ver sección siguiente), y vía API a la base de datos MySQL para su almacenamiento. De esta manera, podrán ser accedidos desde el exterior a través del API. En la base de datos, estos datos tienen un campo “visible” (por defecto a “0”), para que el motor de correlación pueda marcarlos de acuerdo con sus reglas de decisión.


Figura 4. Optimización de modelos Deep learning.

5. Análisis de datos basado en reglas Este componente implementa una serie de reglas para discernir si un evento constituye una alerta.

Finalmente, se ha basado en WSO2 Complex Event Processor (CEP), que a su vez se basa en Apache Siddhi. WSO2 CEP permite utilizar reglas dinámicas, por lo que no tienen que compilarse, y con una sintaxis similar a SQL. Además, ofrece todo un ecosistema de componentes con los que se podría integrar (múltiples tipos de conectores con receptores de eventos previamente implementados, monitorización, bus empresarial, etc.).

WSO2 CEP soporta múltiples formas de comunicación de alertas:

• XML, JSON, Map y Eventos de Texto vía JMS; • notificaciones e‐mail, SMS; • servicios RESTful y SOAP; • MySQL y Cassandra; • Kafka, MQTT, Fichero, Websocket.

La comunicación con el CEP se realiza a través de un servidor MQTT interno. Cuando el módulo identifica una alerta, la escribe en el repositorio MySQL y podría enviar un correo de notificación si fuera necesario. También podría acceder a un API externo de actuación.

5.1. Control estadístico de calidad para la detección de anomalías

En CEI, proponemos detectar situaciones inusuales comparando las predicciones proporcionadas por los modelos estadísticos con los valores reales. Esta comparación se plantea mediante la estimación de residuos. Un residuo (e), e=y‐ŷ es la diferencia entre el valor real y su estimación para cada instante. Se considera que un residuo es normal cuando es cercano a 0. El concepto de “cercanía” es una abstracción cuyas fronteras tienen que establecerse.


El entrenamiento de un modelo nos otorga la oportunidad de estimar su error a través de la desviación estándar residual (σe). Cuanto mayor sea ésta, peor es el modelo. Asumiendo que los residuos se distribuyen normalmente N(μ=0, σ=σe), dicha distribución puede ayudarnos a establecer qué puede considerarse anómalo desde un punto de vista estadístico, comparando valores reales y estimados. Cuando mayor sea el valor absoluto de un residuo, menor será la probabilidad de que disco valor absoluto residual aparezca en una situación normal. Así, la distribución de probabilidad residual estimada nos ayudará a establecer los límites para clasificar los residuos como situaciones normales o anómalas. De esta forma, podemos diferenciar dos niveles: [μ−1.96∗σe;μ+1.96∗σe] y [μ−2.97∗σe;μ+2.97∗σe] (se pueden ajustar estos intervalos según la precisión deseada). Todos los residuos en el primer nivel se considerarán situaciones normales. En otro caso, se marcarán como sospechosos de constituir una situación anómala, ya que la probabilidad de que sean normales es baja al ser alta su distancia absoluta a 0. La Figura 5 muestra un ejemplo de aplicación en la que únicamente se detectaría una situación anómala.

Esta metodología puede producir falsos positivos al clasificar como anómalo un valor que aparezca, por su naturaleza, poco común pese a ser normal. Existen técnicas de control estadístico de la calidad que pueden minimizar tales falsos positivos, como por ejemplo Shewhart, CUSUM or EWMA. Además, otros estadísticos aumentan la potencia del control, como ̅ o la desviación, entre otros aspectos de la variable. Por otra parte, para aquellos casos que no sigan una distribución normal, este método se puede aplicar con la distribución más apropiada.

Figura 5. Detección de anomalías con análisis de residuos.

5.2. Motor de alertas

Los modelos estadísticos anteriores identifican qué datos entrantes son anómalos, y publican dichos eventos a través de un servidor interno MQTT. El motor de alertas CEP se suscribe a dicho canal MQTT, de forma que cada evento nuevo lanzará un análisis basado en reglas para decidir si dicho evento se considera como una alerta que mostrar al usuario. En CEI, se ha implementado este análisis basado en reglas en WSO2 Complex Event Processor (CEP).

CEP define planes de ejecución con los siguientes elementos (ver Figura 6):


• Receptor de eventos (event receiver): fuentes de datos a analizar. En un plan de ejecución determinado, el receptor de eventos seleccionado se denomina “input stream”. En nuestro caso, MQTT.

• Consulta (query): regla que se lanza sobre el input stream, expresada en una sintaxis similar a SQL. Si la regla se evalúa como cierta, la consulta escribirá un mensaje JSON en el “output stream”.

• Publicador de eventos (event publisher): maneras posibles para publicar los resultados de la evaluación de las reglas. En un plan de ejecución dado, el publicador de eventos seleccionado se denomina “output stream”. En nuestro caso, RDBMS, ya que la alerta se almacena en la base de datos MySQL.

Figura 6. Plan de ejecución CEI en WSO2 CEP.

6. Front‐end web

Se ha desarrollado una aplicación web para mostrar tanto las medidas enviadas al API como el resultado de los análisis. Dado que en el proyecto se tratan grandes cantidades de datos, se han escogido tecnologías que se pueden relacionar con entornos big data.

• Front‐end en AngularJS: este marco Javascript puede crear vistas de usuario para representar los datos. Las aplicaciones resultantes son ligeras, disociando la parte del cliente de la del servidor, descomponiéndose en componentes web enlazados.

• Back‐end en NodeJS, un entorno asíncrono escrito en ECMAScript que permite servidores web altamente escalables.

• Acceso a la infraestructura big data vía librerías JAVA específicas, como ZeroMQ • Capa de persitencia con MySQL Big‐Tables y motor InnoDB. Se trata de una base de

datos relacional ágil y simple, con una latencia de consultas reducida incluso con grandes cantidades de datos.

La plataforma ITI dispone de un componente de visualización de datos y anomalías consistente en una aplicación web en la que los usuarios pueden identificarse para acceder a cinco funcionalidades principales:

1. Dashboard: panel que recoge un conjunto de widgets que resumen el estado de los edificios en materia de detección de anomalías e indicadores de optimización. Es


posible llegar hasta el detalle de un sensor para ver las anomalías asociadas y sus medidas.

2. Anomalías: muestra el histórico de las anomalías detectadas por el motor de correlación de datos y notificadas por el sistema experto. Permite la búsqueda por diferentes parámetros y acceder al detalle de la anomalía para su gestión.

3. Sensores: permite acceder al conjunto de sensores de los edificios para graficar sus medidas a la par que un conjunto de indicadores de eficiencia energética.

4. Correlaciones: funcionalidad que permite simular comparar las correlaciones entre datos de diferentes sensores, seleccionables desde un formulario.

5. Configuración: conjunto de funcionalidades que permiten al usuario configurar el edificio, sus sensores, parámetros de funcionamiento de la herramienta de visualización, así como los usuarios del sistema.

A continuación, se muestra el árbol de navegación que se ha implementado en la herramienta, así como una descripción detallada de cada una de las funcionalidades implementadas.

Figura 7. Árbol de navegación de la herramienta de visualización de datos.

6.1. Arquitectura software

El componente de visualización de datos y anomalías de la plataforma ITI incluye mecanismos de representación de datos que permitan la creación de un interfaz de consulta orientada a la explotación de la información resultante de los procesos de análisis de datos.

En este sentido, la aplicación de técnicas informáticas convencionales en la aplicación web no es suficiente, sino que es necesario la aplicación de técnicas ligadas a tecnologías Big Data para la representación visual de grandes cantidades de datos. Aumentar las capacidades en la toma de decisiones pasa por aplicar técnicas para representar de forma ágil grandes volúmenes de datos y proveer de elementos gráficos que faciliten su comprensión para la extracción de conclusiones y nuevo conocimiento.


Para poder llevar a cabo el desarrollo del componente de visualización bajo estas premisas, ha sido necesario diseñar una arquitectura de software en tres capas donde cada componente puede ser integrado en la aplicación de front‐end mediante la utilización de una Application Programming Interface (API) basada en servicios web REST.

En la figura anterior, podemos ver una organización arquitectónica basada en la agrupación de tecnologías que son orquestadas para componer la aplicación final. En concreto, las tecnologías utilizadas en cada capa son:

AngularJS: Framework escrito en Javascript que permite la creación de las vistas del interfaz de usuario y la representación de los datos. Destaca por la generación de aplicaciones ligeras, disociación del lado cliente del servidor y su descomposición en webcomponents enlazados.

NodeJS: entorno asíncrono de ejecución multiplataforma escrito en ECMAScript que destaca por permitir la creación de servidores web altamente escalables. Sirve de enlace entre los datos y la aplicación web gracias a servicios web de alto rendimiento para manejar grandes cantidades de datos.

JAVA: lenguaje de programación de ámbito general y de uso muy extendido que permite el acceso a la capa de persistencia mediante la utilización de librerías específicas como Cassandra y Spring.

MySQL Big‐Tables: Sistema de Gestión de Base de Datos Relacional que se utiliza para proveer de datos a la aplicación de Front‐End de forma ágil y sencilla. Se emplea el motor InnoDB compilado en modo Big‐Tables para permitir el almacenamiento de históricos de datos y facilitar el proceso de consulta a la infraestructura Big Data, reduciendo así la latencia de consulta.

Figura 8. Tecnologías empleadas en front‐end.


6.2. Metodología de desarrollo

Cada uno de los webcomponents, servicios y aplicaciones identificados en el proyecto, pueden ser desarrollados de forma independiente gracias a la incorporación de las filosofías de integración Mashup1 y RESTFUL.

En particular, dicha filosofía permitirá ver cada elemento del sistema como un consumidor de contenidos que deben ser alimentados por la capa persistencia basada en Cassandra.

De este modo, la arquitectura propuesta ha permitido al equipo de desarrollo realizar un enfoque en el que:

El interfaz web es un elemento que invoca a cada uno de los servicios o webcomponents desarrollados para orquestarlos dentro de un reto funcional superior a ellos mismos.

Cada servicio o webcomponent ha podido ser desarrollado como un elemento independiente, interconectado con el resto de elementos a través de un API REST. Esto ha permitido disponer de un entorno tecnológico específico en cada caso, como se ha presentado en la sección anterior, en el que ha sido necesaria la generación de un conjunto de servicios web que permitan acceder y proveer contenidos.

Pueden construirse soluciones funcionales híbridas en las que distintos servicios y aplicaciones de otras capas realizan las tareas de proveer contenidos, datos, etc.

Ha permitido la construcción de un sistema escalable en el que cada componente se podría desplegar en un nodo diferente.

Ha permitido la construcción de aplicaciones y servicios clave para soportar parte de la ejecución de procesos de negocio necesarios para la implementación del prototipo.

1 Un mashup es una página web o aplicación que usa y combina datos, presentaciones y funcionalidad procedentes de una o más fuentes para crear nuevos servicios


6.3. Pantallas

A continuación, se repasan las pantallas implementadas en el front‐end.

6.3.3 Landing page

Figura 9. Front‐end: landing page.

Esta es la pantalla de bienvenida a la plataforma ITI, en esta pantalla se describen los objetivos del proyecto:

MAXIMIZACIÓN DE LA ENERGÍA SOSTENIBLE

Potenciación del uso de energías sostenibles mediante la optimización del control y balance energético.

DISMINUCIÓN DE CONSUMOS DE ENERGÍA

Mediante el desarrollo de algoritmos de Predicción, Gestión y Balance Energético de Generación y Demanda.

REDUCCIÓN DE EMISIONES CONTAMINANTES

Gracias al desarrollo de nuevas tecnologías para sensores medioambiental y de entorno.

REDUCCIÓN DE COSTES DE MANTENIMIENTO

Mediante el uso de técnicas de mantenimiento predictivo y optimización para la planificación.

Así mismo se presentan los participantes del proyecto y la información de contacto:

ITE: Instituto Tecnológico de la Energía

ITI: Instituto Tecnológico de Informática


Finalmente se dispone de dos enlaces uno al login de la aplicación principal descrito en el siguiente punto y el acceso al CKAN, web que gestiona las fuentes abiertas del proyecto.

Figura 10. Front‐end: open data caster o CKAN.

Figura 11. Front‐end: pantalla de Log‐in.

Esta pantalla permite el acceso a la web de la plataforma, requiere la creación de una cuenta de usuario previa al acceso. Dicha cuenta consta de correo electrónico y una contraseña. La validación se realiza contra el backend REST implementado en Node.js.

Una vez validadas las credenciales del usuario se accederá a la pantalla del cuadro de mando del sistema, que permite a su vez del acceso al resto del sistema.


6.3.4 Pantalla de cuadro de mando del sistema

Figura 12. front‐end: dashboard.

La pantalla de cuadro de mando del sistema de la plataforma ITI muestra un resumen del estado del sistema, consta de dos componentes:

Grafico del sistema: Muestra un resumen de estado de los distintos edificios sensorizados en el sistema de producción, asociando un icono a cada edificio y un código de colores en función del número y tipo de anomalías detectadas por la plataforma. Verde indica que no existen anomalías detectadas, Amarillo que hay anomalías de baja criticidad y Rojo que existen anomalías de criticidad alta

Cuadro de indicadores: Muestra un conjunto de KPI´s (indicadores) preestablecidos como el consumo medio de los edificios, últimas anomalías detectadas, un ranking de la eficiencia de los edificios y un gráfico temporal con los consumos a nivel de semana, mes y año.

En la barra de la izquierda se muestra el menú de acceso al resto de pantallas de la aplicación, Dashboard (Actual), Anomalías, Sensores y Configuración. Esta barra es común a toda la aplicación permitiendo la navegabilidad en cualquier momento al resto de pantallas del sistema.


6.3.5 Pantalla de configuración de edificios

Figura 13. Front‐end: configuración de edificios.

Esta pantalla permite la configuración de los elementos de la plataforma, permite dar de alta ciudades, edificios, así como sensores instalados en los edificios.

Todo elemento del sistema consta de una descripción que facilita su identificación para el usuario y un código único dentro del sistema, ambos editables desde esta pantalla.


6.3.6 Pantalla de configuración de usuarios

Figura 14. Front‐end: configuración de usuarios.

Esta pantalla permite la configuración de los usuarios que podrán acceder al sistema, permitiendo su alta, modificación y borrado. Se consideran los siguientes datos:

Nombre

Email (login del sistema)

Estado (Activo/Desactivado)

Contraseña (contraseña del sistema)

Confirmación de contraseña


6.3.7 Pantalla de configuración de parámetros de la web

Figura 15. Front‐end: configuración de la web.

Esta pantalla permite configuración de los parámetros de la web, se puede definir el número de puntos usados en las gráficas, sigma (nivel de tolerancia del error) definido en las gráficas, así como dos seleccionables que permiten activar o desactivar distintos tipos de anomalías.

La configuración de los parámetros es particular para cada usuario del sistema, permitiendo de este modo adecuar la interfaz web a los gustos o requerimientos de cada uno de ellos.

6.3.8 Pantalla de visualización de correlaciones

Figura 16. Front‐end: correlaciones.

Esta pantalla muestra un formulario que permite seleccionar un edificio y hacer una comparativa visual sobre las correlaciones de los datos entre dos sensores del edificio. Dichas


correlaciones se muestran a modo de histórico en una gráfica temporal a nivel de día, mes y año.

6.3.9 Pantalla de visualización de datos de los sensores

Figura 17. Front‐end: datos del sensor.

Esta pantalla permite la visualización y comparativa de la información de sensores disponible para cada edificio configurado en el sistema. La gráfica muestra los datos de los sensores seleccionados durante el intervalo de fechas seleccionado.

La búsqueda por fechas realizada es una consulta agregada contra el clúster con un determinado número de puntos por gráfica (1500‐2000), según el parámetro seleccionado en la pantalla de configuración de la web. De este modo, la visualización de datos es independiente del volumen almacenado, permitiendo al usuario la consulta de históricos de larga duración sin afectar al rendimiento del sistema.


6.3.10 Pantalla de consulta de histórico de anomalías

Figura 18. Front‐end: histórico de anomalías.

Esta pantalla muestra el histórico de anomalías producidas en el sistema, permite una búsqueda paginada, así como una búsqueda por descripción de la anomalía.

El listado de anomalías muestra información sobre el estado de la anomalía, la fecha de alta en el sistema, la criticidad, el tipo, el sensor o sensores a los que está asociada, así como una descripción de la misma sobre la que se permite la búsqueda.

Pulsando sobre una anomalía en concreto, se accede a la pantalla de detalle de la anomalía que describimos a continuación.

6.3.11 Pantalla de consulta del detalle de la anomalía

Figura 19. Detalle de las anomalías.

Esta pantalla muestra en detalle la información de una anomalía dada, amplia la información de la pantalla anterior proporcionando información del histórico de cambios de estado de la misma, así como parámetros relativos al modelo estadístico que género la anomalía informando detalles como la probabilidad y confianza en la predicción.

Adicionalmente se permite la manipulación del estado de la anomalía, permitiendo al usuario:


Planificar la anomalía, marca la anomalía como procesada y planifica una actuación sobre el sensor o sensores asociados a la misma.

Posponer la anomalía, aplaza temporalmente el tratamiento de la anomalía a la espera de un evento con mayor confianza o probabilidad.

Descartar la anomalía, marca la anomalía como eliminada del sistema, sin tratamiento de la misma.

7. Conclusiones El presente documento ha descrito los componentes implementados por ITI en la plataforma TIC de CEI, cuya arquitectura de detalló en el entregable E4.1. En resumen, esta plataforma es capaz de almacenar los datos recopilados por los sensores desplegados en la ciudad, modelarlos estadísticamente, predecir futuros comportamientos, y detectar anomalías. Para ello, se combinan tecnologías y técnicas punteras del ámbito de Big Data Analytics. En todo momento, se ha seguido una filosofía flexible, de forma que la plataforma será fácilmente adaptable a nuevos tipos de sensores o técnicas.

La integración de esta plataforma con el resto de componentes del proyecto CEI se valida en los entregables “E6.4 Herramienta final de mantenimiento”, centrado en la aplicación del sistema de detección de anomalías; en “E5.3 Informe de incorporación de fuentes de datos abiertas del entorno”, centrado en la incorporación de fuentes open data; y “E7.2 Teste del sistema en ITI”, centrado en la incorporación y análisis de datos captados por ITE.


8. Referencias bibliográficas [1] Fu Xiao, Cheng Fan, Data mining in building automation system for improving building

operational performance, Energy and Buildings, Volume 75, June 2014, Pages 109‐118,

ISSN 0378‐7788

[2] Cheng Fan, Fu Xiao, Henrik Madsen, Dan Wang, Temporal knowledge discovery in big

BAS data for building energy management, Energy and Buildings, Volume 109, 15

December 2015, Pages 75‐89, ISSN 0378‐7788

[3] Hai‐xiang Zhao, Frédéric Magoulès, A review on the prediction of building energy

consumption, Renewable and Sustainable Energy Reviews, Volume 16, Issue 6, August

2012

[4] Elena Mocanu, Phuong Nguyen, Madeleine Gibescu, Wil L. Kling, Deep learning for

estimating building energy consumption, Sustainable Energy, Grids and Networks,

Available online 7 March 2016, ISSN 2352‐4677

[5] A. Foucquier, S. Robert, F. Suard, L. Stéphan, A. Jay. State of the art in building modelling and energy performances prediction: A review. Renewable Sustainable

Energy Rev., 23 (2013), pp. 272–288

[6] Najafabadi, Maryam M; Villanustre, Flavio; Khoshgoftaar, Taghi M; Seliya, Naeem;

Wald, Randall; Muharemagic, Edin; Deep learning applications and challenges in big

data analytics,Journal of Big Data,2,1,1‐21,2015,Springer International Publishing

Documents

Informe del sistema de tratamiento y análisis de datos masivos€¦ · Figura 1: Arquitectura del módulo desarrollado por ITI en CEI. 9 Figura 2. Data wrangling en Scala, fragmento