Digitalización de los flujos de datos para predicción energética de edificios inteligentes a través de la implementación de un data-lake bajo técnicas Big-Data

UNIVERSIDAD DE VALLADOLID ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIÓN TRABAJO DE FIN DE MÁSTER MÁSTER UNIVERSITARIO EN INGENIERÍA DE TELECOMUNICACIÓN Digitalización de los flujos de datos para predicción energética de edificios inteligentes a través de la implementación de un data-lake bajo técnicas Big-Data Autor: D. David Arévalo González Tutores: D. José Luis Hernández García Dr. D. Ignacio de Miguel Jiménez Valladolid, Julio 2024 TÍTULO: Digitalización de los flujos de datos para predicción energética de edificios inteligentes a través de la implementación de un data-lake bajo técnicas Big-Data AUTOR:D. David Arévalo González TUTORES:D. José Luis Hernández García Dr. D. Ignacio de Miguel Jiménez DEPARTAMENTO: Departamento de Teoría de la Señal y Comunicaciones e Ingeniería Telemática Tribunal PRESIDENTE:Dr. D. Ramón J. Durán Barroso VOCAL:Dr. Juan Carlos Aguado Manzano SECRETARIO:Dr. Ramón de la Rosa Steinz SUPLENTE 1: Dra. D.ª Patricia Fernández del Reguero SUPLENTE 2: Dr. Juan Blas Prieto SUPLENTE 3: Dr. Alfonso Bahillo Martínez FECHA:Julio 2024 CALIFICACIÓN: Agradecimientos En primera instancia me gustaría expresar mi más sincero agradecimiento a todos los participantes y miembros del consorcio del proyecto DigiBUILD (financiado por la Unión Europea, Grant Agreement 101069658) [ 1 ] por los recursos proporcionados y la invaluable ayuda durante el desarrollo de este proyecto, así como por su dedicación y esfuerzo. Además, cabe destacar y agradecer los esfuerzos tanto sociales como económicos que ha supuesto la financiación proporcionada por la Comisión Europea, no sólo en el proyecto DigiBUILD sino en todos aquellos que favorecen la innovación y la investigación en todas sus formas. En lo relativo al trabajo me gustaría agradecer el apoyo de Jose y Susana, así como de Nacho, por el apoyo y todos los consejos aportados para poder llevar a cabo el trabajo con la excelencia que requiere y facilitar el desarrollo del mismo. Por otro lado, agradecer a mi familia y pareja, Teresa, Roberto, Álvaro y Carlos, el apoyo tan grande que han sido, no solo en la realización del trabajo, sino en todo mi periodo de formación superior. Gracias por estar en los mejores y en los peores momentos permitiendo terminar esta etapa siendo mi mejor versión. I Resumen Actualmente, nos encontramos en un periodo de transición digital donde muchos procesos, tanto industriales como cotidianos, están sufriendo una migración hacia lo digital, específicamente en nuestro caso, en el sector de la construcción. Hasta ahora, el enfoque que se ha estado implementando se conoce como un enfoque de silo, donde cada uno de los actores interesados gestiona individualmente sus datos de forma aislada. Proponiendo una alternativa al enfoque actual, en este Trabajo Fin de Máster se han desarrollado metodologías de extracción, transformación y almacenaje de datos procedentes de un gran número de fuentes heterogéneas a lo largo de 10 edificios piloto dotándolos de homogeneidad y calidad. Además, se ha definido una base de datos que permite su consumo a través de una interfaz homogénea. Finalmente, se ha querido demostrar una forma de compartición y uso de los datos de los servicios de DigiBUILD a través de la definición de una API para la predicción de diferentes variables energéticas. Todo este desarrollo se ha podido llevar a cabo bajo los materiales y el marco de desarrollo del proyecto europeo DigiBUILD y, más en concreto en nombre de CARTIF, cuyo fin último es la solución que se propone. Palabras Clave Espacios de datos, ETLs, big-data,data-lake, interoperabilidad, calidad de datos, edificios inteligentes, eficiencia energética, machine learning. II Abstract Currently, we are in a period of digital transition where many processes, both industrial and everyday-life, are undergoing a migration towards digitalization, specifically in our case, in the construction sector. Until now, the approach that has been implemented is known as a silo approach, where each stakeholder manages their data individually and in isolation. Proposing an alternative to the current approach, in this Master’s Thesis, methodologies for extracting, transforming, and storing data from a large number of heterogeneous sources have been developed across 10 pilot buildings, endowing them with homogeneity and quality. Additionally, a database has been defined that allows its consumption through a homogeneous interface. Finally, an API has been developed to showcase how a sharing point to some energy-related forecasting servies work. All this development has been carried out under the materials and the development framework of the European project DigiBUILD and, more specifically as CARTIF, whose ultimate goal is the proposed solution. Keywords Data spaces, ETLs, big-data, data-lake, interoperability, data quality, smart building, energy efficiency, machine learning. III Capítulo 1 Introducción Este capítulo de la memoria pretende servir como contextualización del marco de trabajo y del propio desarrollo de este trabajo de fin de máster, de ahora en adelante, TFM. En este documento se expondrán las hipótesis iniciales, desarrollos y resultados obtenidos a lo largo de las tareas a realizar dentro del proyecto. El presente TFM se desarrolla dentro del proyecto europeo llamado High-Quality DataDriven Services for a Digital Built Environment towards a Climate-Neutral Building Stock, o su acrónimo DigiBUILD [ 2 ]. DigiBUILD es un proyecto en el que colaboran un consorcio de empresas europeas bajo la supervisión de la Agencia Ejecutiva del Clima, Infraestructura y Medioambiente Europea (CINEA) [3], supeditada a la Comisión Europea (EC) [4]. Este proyecto se ubica dentro del programa de innovación e investigación Horizon Europe, en el sector del uso de energía [ 5 ]. La convocatoria del proyecto es HORIZON-CL5-2021-D4-01 oEfficient, sustainable and inclusive energy use y su tema HORIZON-CL5-2021-D4-01-03 o Advanced data-driven monitoring of building stock energy performance. El proyecto tiene una duración estimada de 36 meses, habiendo comenzado el día 1 de junio del 2022 y se espera que finalice en junio del 2025, aunque las tareas que conciernen al TFM tiene una fecha de finalización anterior. 1.1. Hipótesis Actualmente, los edificios de nueva generación están siendo diseñados atendiendo a las posibles medidas de digitalización de los mismos, teniendo la infraestructura ya instalada o teniendo en cuenta su potencial instalación. Por otra parte, algunos de los edificios que no son de nueva o reciente construcción también están sufriendo la transformación hacia la monitorización y el control de los procesos y consumos propios del edificio. Esta transformación se conoce como digitalización y consiste en la instalación de sensores o componentes electrónicos que permitan algún tipo de monitorización o gestión remota y automática del edificio, automatización 1 CAPÍTULO 1. INTRODUCCIÓN de procesos dentro del mismo o meramente la extracción de datos para un control y posible identificación de problemas. El fin último de esta digitalización, en gran parte de los casos, es la eficiencia energética, con una monitorización de los recursos de los edificios y mejorando u optimizando la gestión y el mantenimiento de los mismos. DigiBUILD tiene como objetivo la transformación de edificios digitales e inteligentes que integren y gestionen de forma propia sus fuentes de datos de una forma proactiva. Esto es un paradigma de organización diferente al que se ha empleado tradicionalmente, conocido como “enfoque de silo”. El enfoque de silo consiste en tener sistemas o agrupaciones de los mismos con bases de datos internas, y la interacción entre estos sistemas independientes es complicada debido a su estructura. Este enfoque es problemático en sistemas u organizaciones de gran tamaño, dado que los equipos independientes no pueden trabajar y realizar operaciones de forma rápida y eficaz sobre los datos dentro del dominio de otro equipo debido a la interacción reducida entre ellos [ 1 ]. El proyecto en el que trabajamos hace uso de datos de alta calidad y servicios de edificios digitales de nueva generación. Además, desarrolla un entorno inclusivo de intercambio de datos entre las diferentes partes interesadas para el diseño y desarrollo de servicios orientados al usuario final, alineado con las propuestas de la Nueva Iniciativa Bauhaus Europea. La Nueva Iniciativa Bauhaus Europea fue lanzada por la Comisión Europea en septiembre de 2020. Se inspira en la famosa Escuela Bauhaus que funcionó en Alemania entre 1919 y 1933, que era una escuela de arte y diseño que buscaba integrar las artes y la tecnología para hacer frente a los retos sociales y económicos de la época. La Nueva Iniciativa Bauhaus Europea pretende combinar diseño, sostenibilidad, accesibilidad, asequibilidad y atractivo estético en la creación de espacios y productos. La idea es fomentar la innovación y la creatividad para hacer frente a los retos contemporáneos, como el cambio climático y la transición a una economía más ecológica [6]. DigiBUILD proporciona diferentes herramientas abiertas accesibles desde la nube para la transformación de estos edificios “silo” en edificios digitales, interoperables e inteligentes. Estas herramientas mejoran la toma de decisiones en lo relativo a la supervisión y evaluación del rendimiento, la planificación de infraestructura de los edificios, la formulación de políticas y la reducción de riesgos en las inversiones [ 1 ]. Sobre este framework se crean servicios y análisis de datos que emplean inteligencia artificial (IA) y se desarrollan gemelos digitales que se alimenten de datos de alta calidad para proporcionar de forma transparente, una mejor toma de decisiones informadas y el intercambio de información dentro del entorno construido y el sector de la construcción. Como conclusión de este pequeño apartado, se especifica que la hipótesis del trabajo es que, mediante la digitalización y la integración de sistemas de monitorización y gestión remota que se han implementado, se pueden optimizar los procesos y el consumo energético en edificios tanto nuevos como existentes. Se plantea que esta transformación hacia edificios inteligentes, que integran y gestionan sus datos de manera proactiva y colaborativa, permitirá mejorar significativamente la eficiencia energética y la sostenibilidad en el sector de la construcción. La Figura 1 muestra el logo creado por el consorcio para el proyecto [ 7 ] en el que se trabaja en este TFM. 2 CAPÍTULO 1. INTRODUCCIÓN Figura 1: Logo de DigiBUILD 1.2. Objetivos A continuación, se expondrán las diferentes tareas propuestas para cumplir en este TFM, siendo éstos soportados por el proyecto DigiBUILD, como se acaba de mencionar. Definir todas las conexiones con las diferentes interfaces y puntos de extracción de datos de los pilotos y otras fuentes de datos externas para la extracción de datos estáticos y datos en tiempo dinámicos, así como su tratamiento, formateo e ingestión. Aplicar metodologías de calidad de datos para evaluar los datos dinámicos adquiridos. Utilizar un Data Warehouse (DWH) de mejora donde se almacenarán los datos dinámicos extraídos de los pilotos mencionados anteriormente y generación de propuestas. Desarrollar una API como interfaz de compartición de datos en la capa de servicios de predicción basados en inteligencia artificial (IA) y en los datos almacenados en el DWH, sirviendo estos como una de las aplicaciones de los objetivos anteriores. El desarrollo de los propios servicios no está incluido en este trabajo. Cada uno de estos objetivos no se considera como un hito aislado, sino que se pretende la construcción del flujo completo de ingestión de datos provenientes de una gran cantidad de fuentes muy heterogéneas y poder obtenerlos a través de una interfaz única y uniforme, siendo almacenados de forma persistente y manteniendo unos estándares de calidad altos. 1.3. Estructura del documento En esta sección se describe la organización y el contenido de los capítulos y apartados que componen el documento: Capítulo 2 (Contexto): En este capítulo de la memoria se exponen los diferentes campos de conocimiento necesarios para la comprensión y desarrollo del trabajo, así como la organización de los objetivos descritos anteriormente y su distribución dentro de la arquitectura de DigiBUILD. Se comienza mencionando la herramienta de creación de los procesos de tratamiento de datos empleada. Después, se explican las consideraciones generales respecto al big data para nuestro TFM. Por último, se muestra un diagrama conceptual de 3 CAPÍTULO 1. INTRODUCCIÓN las tareas en forma de diagrama de bloques, donde se explican las relaciones y los flujos de los bloques asociándolas con las tareas desarrolladas en el TFM. Capítulo 3 (Arquitectura del sistema): En el siguiente capítulo, se desarrollan conceptos de arquitectura en sistemas big data y, en concreto, la arquitectura que se ha propuesto para el sistema de DigiBUILD, haciendo especial hincapié en las tareas que hemos desarrollado. Capítulo 4 (Extracción de datos dinámicos): En el tercer capítulo del documento se encuentra el grueso del trabajo. Aquí se muestran los diferentes procesos de conexión a fuentes de datos, su extracción, la transformación y su almacenaje en el DWH. Capítulo 5 (Metodologías de calidad de datos): En este capítulo se explican los conceptos más importantes sobre la calidad de los datos, las diferentes métricas seleccionadas para la evaluación de los datos en el proyecto y su implementación en el sistema. Capítulo 6 (Base de datos para el almacenamiento de datos dinámicos contextuales: Data Warehouse): Se explican los conceptos más relevantes del DWH que se ha utilizado, así como el manejo big data en la definición de la base de datos y la optimización de queries para reducir la carga de procesamiento y el volumen de datos. Además, se proporciona alguna pincelada sobre la importancia de los metadatos en el proyecto y su sincronización con los datos dinámicos. Por último, se hace mención al desarrollo de una API que hace uso del DWH para proporcionar acceso a varios dervicios que generan predicciones para diferentes pilotos. Capítulo 7 (Conclusiones): Finalmente se procede a mencionar las diferentes conclusiones a las que se ha llegado con el desarrollo de todas las tareas mencionadas. 4 Capítulo 2 Contexto del proyecto En esta sección, se procede a la definición de los conceptos más relevantes relativos al desarrollo del proyecto que permitan entender su desarrollo, así como a la explicación de la organización de los diferentes objetivos definidos anteriormente en el contexto del TFM y de la arquitectura de DigiBUILD. 2.1. Big Data Big data se refiere a colecciones de datos de gran tamaño que exceden las capacidades de los sistemas de procesamiento de datos tradicionales [ 8 ]. El interés en big data ha crecido exponencialmente en los últimos tiempos, estimulado por avances en comunicaciones y mejoras significativas en los sistemas para procesar y almacenar datos. En este periodo de expansión digital, se ha creado un volumen de datos sin parangón originado por distintas fuentes, incluyendo las redes sociales, transacciones electrónicas, dispositivos del Internet de las Cosas (IoT), entre otras. La habilidad para guardar, procesar utilizar este masivo volumen de datos ha marcado el inicio de una nueva era en decisiones informadas por datos, innovación y adaptación de servicios, resaltando su crucial importancia en una amplia gama de áreas como la ingeniería y administración de recursos. Las cinco Vs o dimensiones del big data delinean las características esenciales que constituyen estos intrincados conjuntos de datos. Estas dimensiones son: Volumen, Velocidad, Variedad, Veracidad y Valor. Volumen alude a la cantidad de datos producidos a cada instante. Velocidad hace referencia a la rapidez con la que estos datos son generados, recolectados y analizados. Variedad destaca la amplia gama de tipos y fuentes de datos, abarcando desde formatos estructurados hasta no estructurados, como textos, imágenes, vídeos, etc. Veracidad señala la fiabilidad y exactitud de los datos, un elemento crucial para la elaboración de análisis confiables. Finalmente, Valor se centra en la habilidad de transformar estos datos en información útil y práctica, representando el fin último de cualquier proyecto de big data. Cada uno de estos aspectos introduce desafíos y posibilidades específicas, impulsando el avance de tecnologías y métodos particulares 5 CAPÍTULO 2. CONTEXTO DEL PROYECTO para el manejo eficaz de los big data [9]. La importancia de las aplicaciones de análisis de big data radica en su capacidad para abordar y aprovechar estas dimensiones. Al gestionar el Volumen, permiten a las organizaciones procesar y analizar grandes conjuntos de datos que de otro modo serían inmanejables. En cuanto a la Velocidad, estas aplicaciones pueden capturar y analizar datos desde en tiempo real hasta frecuencias como de un día, siendo escenarios completamente diferente, lo que resulta crucial para tomar decisiones rápidas basadas en información actualizada. El hecho de tener frecuencias de generación de datos tan diferentes pone mucho más en valor la implementación de la dimensión de la velocidad con un enfoque big data en nuestro caso de aplicación. La Variedad se aborda permitiendo la integración y el análisis de datos procedentes de múltiples fuentes y formatos, desde estructurados a no estructurados. La Veracidad se garantiza mediante herramientas y algoritmos que limpian y verifican los datos, asegurando análisis precisos. Por último, el Valor surge de la transformación de grandes volúmenes de datos en información procesable y decisiones informadas, maximizando así el impacto y la eficiencia de la organización o de la aplicación [ 9 ]. 2.2. Diagrama conceptual En la figura 2 podemos ver un diagrama conceptual y general de los diferentes bloques en los que agrupamos las tareas que se desarrollan en este TFM, así como los bloques que se relacionan directamente con éstos. El objetivo será explicar desde un punto de vista más general la organización, flujos y relaciones de los diferentes objetivos de nuestro proyecto y su implementación. En la parte inferior del diagrama, se distinguen las fuentes de datos, las cuales pueden clasificarse como internas o externas al proyecto. Las fuentes internas abarcan datos estáticos, como metadatos, y dinámicos, que comprenden información temporal de variables físicas y lógicas presentes en los pilotos o demostradores del proyecto. Por otro lado, las fuentes externas, que comprenden APIs y otros espacios de datos ajenos al proyecto, tales como pronósticos y registros meteorológicos históricos, además de otros espacios de datos preexistentes pertenecientes a organismos públicos europeos. En el siguiente bloque del diagrama, encontramos los procesos ETL, que se abordarán de forma más extensa en el capítulo 4 de la memoria. Estos procesos conforman el grueso de nuestro trabajo y su función es la siguiente: se establecen conexiones con los diversos flujos de datos en cada uno de los pilotos existentes, a través de interfaces de bases de datos, APIs u otros protocolos de comunicación, considerando tanto su formato como su disponibilidad. Cabe destacar la amplia variedad de protocolos de acceso a estos datos, así como la gran cantidad de variables físicas y puntos medidos con los que se trabaja. Además, se aplicarán transformaciones a dichos flujos para dotar a los datos de un formato homogéneo y uniforme, así como de limpiar y filtrar los datos no relevantes para el sistema. Estos datos homogéneos y tratados servirán como entradas de los bloques Data Lake y Gemelos Digitales, cuyo desarrollo no se corresponde a las tareas de este trabajo. 6 CAPÍTULO 2. CONTEXTO DEL PROYECTO Figura 2: Diagrama conceptual del TFM En estas ETLs se extraen datos dinámicos y, en los casos en los que sea posible, datos estáticos o metadatos. Los metadatos aportan información muy variada y diferente, como por ejemplo sobre la estructura física o lógica en la que se divide el piloto, unidades de medida de las variables de los datos dinámicos, localización, estado de los dispositivos de medida, etc. Los datos dinámicos son los valores de las magnitudes que se miden en los pilotos o fuentes externas y serán almacenados en el próximo bloque, el Data Lake, más concretamente en el Data Warehouse (DWH). A continuación, encontramos el bloque Data Lake. Como ya hemos mencionado, este bloque se alimenta de los datos en dinámicos que producen las ETLs. Su función principal es almacenar datos, por lo que principalmente está compuesto de varias bases de datos. La más importante de ellas, y la que nosotros implementamos y poblamos es el Data Warehouse, explicado en el capítulo 6, y que consiste en el almacén de los datos dinámicos, es decir, de medidas obtenidas de los diferentes pilotos. El Data Lake tiene como salida los datos históricos que almacena para 7 CAPÍTULO 2. CONTEXTO DEL PROYECTO los bloques de Servicios y de Gemelos Digitales. Finalmente, se encuentra el bloque de servicios. Estos servicios consumen los metadatos y datos que se almacenan en el Data Lake provenientes tanto de fuentes internas como externas. Estos servicios emplean algoritmos de inteligencia artificial y se basan en la utilización de los datos extraídos en los pasos previos del flujo. Los servicios están diseñados ad-hoc para cada piloto, aunque cada servicio se comparta entre diferentes pilotos. El contenido relativo a los servicios que concierne a este trabajo de fin de Máster se centre únicamente en el desarrollo de una API para hacer uso de los mismos. Esta interfaz se describe en la sección 6.6 de la memoria. Esta API sirve como pequeño repositorio de modelos de IA para la predicción de variables energéticas de forma ajena a este TFM. Las salidas de los diferentes servicios se emplean tanto como entradas para los diferentes gemelos digitales desarrollados como resultados finales para los usuarios en una interfaz gráfica (GUI) cuyo desarrollo tampoco corresponde a los objetivos de este trabajo. En esta sección de la memoria se ha mencionado el concepto de piloto, pero sin explicar qué es. Un piloto se puede corresponder con uno o varios edificios, sistemas energéticos o infraestructuras dedicadas a diferentes ámbitos, como podría ser un edificio de oficinas, un edificio educativo o una fábrica. En DigiBUILD se cuenta con 10 pilotos diferentes repartidos por toda Europa. Cada uno de ellos es gestionado por una de las empresa del consorcio. Estos pilotos se encuentran sensorizados y exportan y/o almacenan datos tanto de variables energéticas (como puede ser la energía que produce una caldera, la potencia que genera una instalación de placas fotovoltaicas, el consumo de un cargador de coches eléctricos, la temperatura de unas oficinas o la potencia que se consume en un enchufe) como variables lógicas (como puede ser la apertura de puertas y ventanas). En la figura 3 podemos ver la distribución de los pilotos y su organización atendiendo a los objetivos de los servicios definidos para cada uno de ellos. De forma general, se organizan en tres clusters atendiendo a la orientación de los servicios que ofrecen, siendo el cluster 1: desempeño de los edificios, cluster 2: edificios vs. la gestión óptima de la infraestructura y cluster 3: políticas y finanzas. Figura 3: Pilotos del proyecto 8 CAPÍTULO 2. CONTEXTO DEL PROYECTO 2.3. Herramientas software empleadas 2.3.1. Pentaho Pentaho [ 10 ] es una suite de programas libres enfocados en el business intelligence (BI). El BI consiste en la extracción y generación de información y conocimiento a partir de datos de una empresa para mejorar y facilitar la toma de decisiones dentro de la misma. Se emplean datos extraídos a lo largo de todo el proceso productivo para generar información sobre el funcionamiento y situación de la empresa, así como toma de decisiones anticipadas o respaldo a la hora de la toma de decisiones. Se ha decidido utilizar Pentaho como la herramienta big data del proyecto debido varios motivos. El más importante de ellos es la multitud de tareas que un único software permite integrar: desde la extracción y tratamiento de los datos, hasta su almacenamiento, migración y sincronización. Otra razón es la facilidad de uso que tiene gracias a su interfaz gráfica y modelo de creación de ETLs basado en diagramas de bloques, haciendo que la curva de aprendizaje para un uso extensivo del programa sea muy rápida. Además, actualmente una primera versión del data warehouse se encuentra desplegado Pentaho Server, que es una herramienta de la suite con funcionalidades que pueden aportar avances a las tareas que hemos desarrollado como parte de este proyecto. Entre estas tareas destacan: la integración de las ETLs, creación de informes personalizados con posibilidad de exportación a diferentes formatos, análisis OLAP de grandes volúmenes de datos de forma muy rápida e interactiva a través de cubos Mondrian, generación de dashboards y visualizadores especializados, entre otras. Dentro de esta suite se encuentra Pentaho Data Integration (PDI) o Kettle. Esta es una aplicación de análisis de big data que facilita la gestión integral de datos, permitiendo a sus usuarios aprovechar el valor de sus datos para obtener información, tomar decisiones y obtener ventajas competitivas, es decir, para aplicar BI. Esta aplicación destaca en la gestión eficaz de estas dimensiones, cubriendo el tratamiento de todas ellas. Kettle facilita la extracción, transformación y carga (ETL) de grandes volúmenes de datos, abordando así el aspecto Volumen. Su capacidad para procesar datos dinámicos afecta directamente a la dimensión Velocidad. En cuanto a la Variedad, kettle admite una amplia gama de tipos y fuentes de datos, desde las bases de datos tradicionales hasta los formatos de datos modernos, como las redes sociales y los flujos de datos en directo. La veracidad se ve reforzada por sus potentes funciones de limpieza y validación de datos, que garantizan que sólo se utilicen para el análisis datos precisos y de alta calidad. Por último, al facilitar la transformación de datos en bruto en información significativa, Kettle permite a las organizaciones extraer el máximo valor de sus datos, impulsando decisiones estratégicas y operativas basadas en pruebas sólidas. Dentro de DigiBUILD, nuestro trabajo se centra principalmente en asentar las bases para la aplicación del BI, esto es, la obtención, formateo y almacenaje de un gran volumen de datos provenientes de una gran cantidad de interfaces y fuentes. 9 CAPÍTULO 3. ARQUITECTURA DEL SISTEMA Suite de gemelos digitales: Esta capa es una capa similar a la capa de aplicación del modelo TCP/IP. Engloba todas las herramientas para el desarrollo de los diferentes gemelos digitales de los pilotos del proyecto. Estos gemelos se consideran claves para la transformación digital y son la contraparte digital del sistema físico. La ubicación de las tareas que desarrollamos en base a las diferentes capas de la arquitectura y su definición y atribución de responsabilidades en nuestro trabajo se realiza de la siguiente forma. Las tareas que se desarrollan en el capítulo 4 están relacionadas con la capa de comunicación. La aplicación de métricas de calidad de datos del capítulo 5 son la responsabilidad asignada a la capa de middleware. En el capítulo 6 se exponen los desarrollos correspondientes con el componente Data Warehouse de la capa del Data Lake, si bien se dedica la sección 6.6 a explicar el desarrollo de una interfaz para la compartición de datos y así poder acceder a los servicios de predicción (capa de framework de servicio). 16 Capítulo 4 Extracción de Datos Dinámicos En este capítulo de la memoria procederemos a describir las diferentes metodologías desarrolladas para la ingestión de datos dinámicos de los diferentes pilotos y fuentes externas. En relación con lo expuesto en el capítulo 2, las tareas desarrolladas en este capítulo se corresponden con las capas de campo y de interoperabilidad de datos que podemos observar en la figura 4. Sus funciones comprenden los siguientes objetivos: conexión con un gran número interfaces empleando diferentes protocolos, extracción de datos, preprocesado y formateo de los mismos mediante procesos de Extracción, Transformación y Filtrado (ETL). Como primer paso para poder llevar a cabo el desarrollo de este objetivo, se construye un inventario de datos junto a desarrolladores de otra tarea relacionada dentro del proyecto [ 28 ]. Para poder llevar a cabo este inventariado de datos se siguen los diferentes pasos: Identificación de los servicios y gemelos digitales que se implementan teniendo en cuenta su definición en el caso de cada piloto. Identificación de los sistemas de energía que se necesitan en cada servicio o gemelo digital. Caracterización de esos sistemas, teniendo sus datos, descripciones técnicas y de los componentes de los forman. Selección de los datasets relevantes de cada piloto atendiendo a los requisitos de los servicios y gemelos digitales. Generación del propio inventario, incluyendo la información más importante, como la descripción de los datasets, disponibilidad de los datos, volumen anual que almacenar, velocidad, frecuencia de muestreo y de publicación, interfaces de extracción, veracidad y fiabilidad. Interfaces de extracción de datos dinámicos Una vez definido el inventario de datos, se seleccionan los datasets más relevantes. Para poder trabajar con estos datos, los responsables técnicos de los pilotos desarrollan las diferentes 17 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS interfaces de extracción de datos que sean necesarias en cada caso. La Tabla 1 [ 28 ] recoge un resumen de los diferentes datasets y los diferentes protocolos necesarios para su extracción. Piloto Detalles de interfaz Dataset Protocolo Formato Frecuencia 01 BMS1 MQTT3[29] Texto 5 min. EMS25 min. Control de luz Eventos Control de acceso Eventos Ocupación Eventos 02 Ethera Nemocloud API4 JSON5[30] 5 min. Ellona Ellonasoft API45 min. Wattsense Wattsense API41 min. 03 3PhaseMeters InfluxDB [31] CSV6[32] 15 min. y 1 h. 04 BEMS7SFTP9[33] CSV6[32] 15 y 30 min. DEMS815 y 30 min. 05a Estaciones de carga API4JSON5[30] 15 min. PV10 10 min. Datos edificio 5 y 20 min. EV11 10 min. 05b PV10 SolarEdge API4JSON5[30] 1 min. Confort JotMotiqa API415 min. Consumo energético MQTT3[29] Texto 1 min. Ocupación Google Calendar API4[34] CSV6[32] Eventos Consumo energético Google Drive API4[35] 15 min. 06 Datos edificio API4JSON5[30] 30 seg. 07 BEMS7SFTP9[33] CSV6[32] 15 min. 08 Datos edificio MQTT3[29] Texto 1 min. Netatmo API4JSON5[30] 5 min. 09 BMS1PostgreSQL [36] Texto 5 a 30 min. Tabla 1: Interfaces para la extracción de datos dinámicos A continuación, se dará una breve explicación de los protocolos abiertos que aparecen en la tabla anterior. MQTT o Message Queuing Telemetry Transfer es un protocolo de intercambio de mensajes a través de colas gestionadas por un broker que se emplea para permitir la comunicación 1BMS: Building Management System - Sistema de Gestión del Edificio 2EMS: Energy Management System - Sistema de Gestión de la Energía 3MQTT: Message Queuing Telemetry Transport - Transporte de Mensajes de Telemetría en Colas 4API: Application Programming Interface - Interfaz de Programación de Aplicación 5JSON: JavaScript Object Notation - Notación de Objetos de JavaScript 6CSV: Comma Separated Values - Valores Separados por Comas 7BEMS: Building Energy Management System - Sistema de Gestión de la Energía en Edificios 8DEMS: District Energy Management System - Sistema de Gestión de la Energía en Distritos 9SFTP: Secure File Transfer Protocol - Protocolo Seguro de Transferencia de Ficheros 10PV: Photovoltaic Energy - Energía Fotovoltaica 11EV: Electrical Vehicle - Vehículo Eléctrico 18 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS de mensajes de mediciones o similares entre instancias o aplicaciones. InfluxDB es una base de datos de series temporales diseñada y optimizada para manejar grandes volúmenes de datos que tienen una marca temporal. Es particularmente útil para aplicaciones que requieren el almacenamiento, consulta y análisis de datos que varían con el tiempo, como sistemas big data. El protocolo SFTP o SSH File Transfer Protocol se emplea para la transferencia de ficheros de forma segura sobre HTTP. Las APIs de Google Calendar yDrive permiten la extracción de datos sobre eventos y ficheros respectivamente a través de los diferentes endpoints que tienen disponibles. Por último, mediante el lenguaje SQL podemos hacer peticiones a la base de datos de PostgreSQL sobre HTTP. Formatos de representación de los datos Por otra parte, se emplean diferentes formatos de representación de los datos. Entre ellos podemos encontrar el formato de texto plano; el formato JavaScript Object Notation o JSON, que implementa estructuras clave-valor y listas con contenido legible; el formato Comma-Separated Values o CSV, que consiste e la enumeración de diferentes valores separados por un caracter concreto, como “,” o “;”. Podemos observar cómo existe una gran variedad de interfaces para la extracción de los datos mencionados. Entre ellas podemos destacar el protocolo MQTT, las interfaces de bases de datos (InfluxDB yPostgreSQL), el protocolo de transferencia de ficheros (SFTP) o APIs genéricas que implementan los dispositivos. Cada una de estas interfaces se corresponderá con un flujo de datos dentro de las transformaciones para cada piloto. Elementos relevantes de Pentaho Previo a la inserción de los datos en el DWH (base de datos destinada a almacenar los datos de las series temporales), un módulo de sincronización se hará cargo de la integración de los propios datos, manteniendo la armonía entre las muestras de datos de los pilotos. Además, los datos estáticos pueden ser extraídos de las propias ETLs, por lo cual, también es necesario mantener la armonización de los metadatos de las ETLs y de los repositorios de metadatos estáticos. El desarrollo de este módulo es ajeno a los objetivos del TFM, pero se explicará más adelante en esta memoria. La implementación de estos procesos ETL se ha empleado la herramienta Pentaho Data Integration, también conocida como Kettle dentro de la Suite de herramientas que se ofrecen dentro del software, como se ha mencionado en el capítulo 2. Este software basa la programación de las ETL mediante diagramas de bloques que desempeñan diferentes funciones de tratamiento de datos y dispone de una interfaz sencilla y un funcionamiento muy intuitivo. Además, permiten como entradas y salidas una gran variedad de fuentes de datos. También dispone de un marketplace donde se publican diferentes plug-ins, lo cual aumenta todavía más la versatilidad que tenemos a nuestro alcance. Se ha decidido utilizar esta herramienta para poder mantener todos los flujos de datos alojados en una única aplicación de servidor y de forma centralizada donde se 19 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS encuentren corriendo simultáneamente. Estos procesos ETL necesitan de otro elemento importante para su ejecución y orquestación, los jobs. En Pentaho, los jobs son componentes clave que permiten orquestar y gestionar flujos de trabajo complejos en procesos de integración de datos. Sus características principales comprenden: la orquestación de tareas controlando la ejecución de múltiples pasos y ETLs, el control de flujo mediante lógica condicional, la automatización mediante la ejecución repetitiva y programada, la integración de componentes variados como operaciones con el SO, ejecución de comandos o scripts, llamadas a servicios web o ejecución de ETLs u otros jobs. Un modelo genérico de los flujos de datos en las ETLs implementadas se ilustra en la figura 5 [ 28 ]. El proceso se inicia con la fase de extracción de datos utilizando las interfaces descritas en la tabla 1, lo cual nos permite capturar los datos en su formato original. A partir de este conjunto inicial, se separan los datos en dos categorías principales: datos estáticos y datos dinámicos. Estos dos flujos de datos son dirigidas hacia el data lake, aunque se almacenan en bases de datos distintas dentro de este. En nuestro caso es de interés el DWH, almacén de los datos dinámicos. Además, los datos dinámicos se derivan hacia dos flujos adicionales: uno enfocado en el análisis de calidad de datos y otro destinado al consumo en tiempo real de datos, este último a través de Kafka. Figura 5: Flujos genéricos en una ETL El flujo de análisis de la calidad de los datos se implementa directamente embebida en las transformaciones de los pilotos, empleando los bloques nativos de Kettle. En el capítulo 5 se explicará en profundidad el contenido relativo a esta líneas e procesamiento de las ETLs. Por simplificar la estructura de éstas, se omitirá en las figuras de las transformaciones. Más adelante se describirá el flujo de calidad de datos, el cual es igual para todas las ETLs. Kafka oApache Kafka es una plataforma de streaming de eventos desarrollada especialmente para el manejo de grandes volúmenes de datos en tiempo real. Normalmente se emplea en escenarios donde la integridad de los datos y la tolerancia a fallos son puntos críticos, el cual es nuestro caso. En la tabla 2 se pueden ver los diferentes topics que se han definido en base a las necesidades de tanto los servicios como de los gemelos digitales de los pilotos del proyecto. En ellos se publican mensajes en función del piloto y la categoría de los datos. Observamos cómo para el piloto 09 o NTUA no se ha definido ninguno, debido a que este piloto no requiere de gemelo digital. También, se aprecia que el piloto 04 se ha desagregado en VEOLIA-FASA o 04a y VEOLIA-RVENA o 04b, dado que éste consta de dos localizaciones geográficas (Valladolid y Burgos respectivamente) y, por lo tanto, de dos gemelos digitales, los cuales necesitan el consumo de los mensajes en topics diferentes. También se producen datos sobre BEMS o DEMS 20 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS en todos los pilotos excepto en EDF (02) e IEECP (08); sobre calidad de aire en UCL (01), EDF, FOCCHI (05b) e IEECP ; sobre carga de vehículo eléctrico en 05a y 06 y sobre generación fotovoltaica en 05a. Finalmente, mencionar que para fuentes externas de datos se ha desarrollado una ETL para la ingestión de datos sobre predicciones meteorológicas. Esta transformación se emplea para los pilotos de UCL, EDF, IASI&SITTA (03), VEOLIA-FASA, VEOLIA-RVENA, EMOT (05a) y HERON(06). La construcción de los topics se ha llevado a cambo mediante la concatenación de tres campos: el nombre del proyecto, el piloto al que está destinado el topic y el uso o la categoría de los datos en inglés separados por puntos (digibuild.NN{x}.ORIGEN). Esta decisión se ha tomado dado que Kafka no permite la creación de subtopics contenidos en topics, y esta forma es el estándar de facto pese a permitir otros caracteres de separación entre campos que conforman un topic [37, 38]. Piloto Origen Topic 01 Meteorología digibuild.01.weather Datos edificio digibuild.01.building Calidad aire digibuild.01.airquality 02 Meteorología digibuild.02.weather Calidad aire digibuild.02.airquality 03 Meteorología digibuild.03.weather Datos edificio digibuild.03.building 04a Meteorología digibuild.04a.weather Datos distrito digibuild.04a.district 04b Meteorología digibuild.04b.weather Datos distrito digibuild.04b.district 05a Meteorología digibuild.05a.weather Datos edificio digibuild.05a.building PV digibuild.05a.pv EV digibuild.05a.ev 05b Datos edificio digibuild.05b.building Calidad aire digibuild.05b.airquality 06 Meteorología digibuild.06.weather Datos edificio digibuild.06.building EV digibuild.06.ev 07 Datos edificio digibuild.07.building Air quality digibuild.07.airquality 08 Calidad Aire digibuild.08.airquality Tabla 2: Topics para la publicación de datos en tiempo real Las transformaciones que se han implementado se definen dentro de lo que en Pentaho se conoce como job o Trabajo. En estos jobs se definen diferentes parámetros como la periodicidad a la que queramos que se ejecuten las transformaciones, las credenciales de autenticación e identificación o los propios parámetros de las mismas. Por otro lado es en estos jobs donde en algunos casos hemos tenido que definir algunas de las conexiones con las interfaces de datos 21 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS según la posibilidad de hacerlo dentro de la propia transformación o no, es decir, con la ejecución de scripts de Shell oPython. Además, se han implementado en todos estos jobs alarmas que notifican por correo a los administradores si sucede algún error en la ejecución tanto del job como de la transformación. A continuación procedemos a la descripción detallada de las diferentes ETLs desarrolladas para cada piloto, incluyendo información sobre las fuentes de datos y la implementación de los jobs. 22 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS 4.1. ETL del piloto 01 - UCL El piloto de la University College London (UCL) se centra en la digitalización y monitoreo de datos en diversos edificios de la universidad. El objetivo es mejorar la eficiencia energética y el confort de los ocupantes mediante la recolección y análisis de datos detallados provenientes de diferentes sistemas de construcción. Su objetivos engloban: Desarrollar auditorías energéticas efectivas, implementar un sistema de monitoreo dinámico para recolectar datos en tiempo real, mejorar la interoperabilidad de los sistemas de gestión de edificios, proporcionar análisis detallados para optimizar el uso de la energía o asegurar un alto nivel de confort para los ocupantes. Todos estos objetivos se alcanzan mediante el desarrollo de las ETLs y el cálculo de diferentes KPIs o Key Performance Indicators. 4.1.1. Dimensiones del big data Tras analizar la información de este piloto, podemos identificar en las cinco dimensiones del big data la siguiente información: Valor: El piloto 01 está formado por dos edificios con localización geográfica cercana. El valor extraído de todos los datos de este piloto son los mencionados KPIs para poder alcanzar los objetivos propuestos, como la generación de servicios de referencia comparativa o benchmarking. Variedad: El piloto de UCL incluye para este proyecto la extracción de datos ambientales como la temperatura o el CO2 , variables de presencia como apertura de puertas, ventanas o sensores lumínicos y de consumos de agua fría y caliente y producción de energía fotovoltaica. Para este piloto nos encontramos con múltiples datasets los cuales contienen casi 700 variables relativas a BMS, EMS, controles de luz y acceso y ocupación, recolectando aproximadamente 3800 puntos. El piloto 01 consta de una única interfaz para la extracción de los datos. Esta interfaz se basa en el protocolo MQTT, que se emplea para la transmisión de mensajes entre diferentes aplicaciones. MQTT se basa en el paradigma publicación/suscripción [ 29 ], creando colas de mensajes para cada uno de los topics o temas en los que se publican dichos mensajes. Volumen: Entre los dos edificos que conforman el piloto se estima que se generan más de 3 GB de datos al año relevantes para el proyecto de DigiBUILD. Velocidad: En este piloto el periodo de muestreo también es muy variado, comprendiendo desde los 5 minutos hasta cada segundo o incluso basada en eventos. Por otra parte, la velocidad con la que se tienen disponibles los datos que se generan a las frecuencias mencionadas es en tiempo real gracias a la utilización del protocolo MQTT, dependiendo en la latencia de la propia red. Veracidad: El responsable del piloto mantiene la totalidad los datos generados bajo su propia gobernanza. Pudiendo ser accedidos desde el exterior mediante credenciales empleados en nuestra identificación en el broker MQTT. 23 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS 4.1.2. Flujos de datos Job El job definido para este piloto (figura 6) está formado únicamente por la llamada a la ETL y el bloque de alarma por mail y no es necesario especificar ningún otro parámetro sobre frecuencia de ejecución o credenciales de autenticación o autorización. Figura 6: Job piloto 01 Transformación La transformación correspondiente a este piloto puede ser observada en la figura 7. Puede verse como consta de un único flujo de procesamiento, como se ha hecho mención a lo largo de esta sección. Figura 7: ETL piloto 01 La transformación comienza con la ingesta de datos a través de un broker MQTT. Primero, procedemos con la suscripción a los diferentes topics del broker o “servidor” MQTT. Los datos que obtenemos tienen un formato JSON y no cuentan con un parámetro temporal para ubicar las medidas generadas. En este bloque se especifican las credenciales de acceso para la propia 24 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS extracción de datos mediante usuario y contraseña, así como las características de la extracción, como especificar un keep-alive o temporizador de inactividad y ajustar el tamaño de los lotes que se reciben para no excedernos en cuanto a los recursos de ejecución. A continuación, se filtran los topics, que se corresponden con el edificio y los sistemas cuyos datos van a ser integrados en el sistema. Este filtrado se hace extrayendo los puntos de medida definidos previamente en el DWH y que han sido proporcionados por el responsable técnico del piloto. Esta extracción se lleva a cabo mediante una petición SQL a la tabla del DWH donde se almacena el listado de los sensores relevantes para el proyecto. Este filtrado se lleva a cabo mediante la unión de los flujos y el filtrado de las filas que no encuentren una coincidencia con la lista de sensores del DWH. Después, se conforma una variable temporal con un formato concreto para ser consistente con la estructura de tablas que se ha definido en el DWH llamado calendar_id. Este parámetro será calculado en todas las transformaciones y constará de la siguiente información: partiendo de una variable de fecha, con el formato yyyy/mm/dd hh:MM:ss.SSS, siendo yyyy el año, mm el mes, dd el día, hh la hora, MM los minutos, ss los segundos y SSS la parte decimal de los segundos. La variable temporal calendar_id que necesitamos asociar a cada medición se forma con los datos anteriores y debe tener el formato: yyyymmddhhMM. En el capítulo 6 se explicará la motivación de la utilización de este parámetro y su función dentro del DWH. La conformación del calendar_id se lleva a cabo mediante la extracción de la fecha y horas actuales, ya que suponemos que los retardos entre la medición y la consumición son despreciables. Finalmente, se procede a la exportación de los datos transformados hacia diferentes ramas haciendo uso de un filtrado. Una de estas ramas es la de metadatos, los cuales no serán utilizados por nuestra parte y simplemente se eliminan todas las variables relativas a ellos del flujo (topic, equipo, punto, instancia, espacio y nivel). Las otras dos salidas del flujo las conforman los datos temporales, formados por una modificación parcial del topic para la generación del identificador del sensor asociado de forma unívoca al dispositivo y a la medición, el identificador temporal y el valor medición. La parte final de esta transformación consiste en la inserción de los datos en el DWH. En la rama de los datos dinámicos se realiza el filtrado de datos separándolos por BMS y de calidad de aire y se publican en el broker de kafka en los topics digibuild.01.building y digibuild.01.airquality respectivamente. Cada entrada de datos que se introduce en el DWH que se deba publicar en el broker de Kafka se tendrá se transformar de acuerdo a la estructura de la figura 8. La parte superior muestra cada una de las entradas del DWH. Se observan los campos calendar_id, que identifica el timestamp de la medida con el formato que se ha descrito anteriormente; sensor_id, que es el nombre único que identifica a cada sensor, y f_value, el cual es el valor de la medida. El formato del mensaje que se publica en el broker es una equivalencia directa en formato JSON. 25 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Figura 14: ETL piloto 02 - Línea Wattsense meidos y los sensores. Entre ellos se encuentran, el identificador del sensor, el identificador de la variable, el nombre de la magnitud que mide o la unidad de medida empleada. Por otro lado, Figura 15: Piloto 02: Línea Ethera - Salida de metadatos para los datos dinámicos (Figura 16), podemos ver los campos que conforman el identificador de la variable medida (structure, source e id), el valor de la propia medida y la variable temporal calendar_id. Línea Ellona Para la segunda interfaz de la cual hemos extraído los datos, la API de Ellona, obtenemos las salidas expuestas en las figuras 17 y 18. 32 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Figura 16: Piloto 02: Línea Ethera - Salida de datos dinámicos En cuanto a los metadatos de este flujo (Figura 17), se han podido obtener únicamente en formato JSON debido a su compleja estructura interna. Es por esta estructura que, a partir de la foto es difícil ver con qué metadatos cuenta. En definitiva tenemos información de los sensores empleados, su hardware, el estado del mismo y también información sobre las variables almacenadas que se han obtenido a través de la API. Figura 17: Piloto 02: Línea Ellona - Salida de metadatos Por otra parte, los datos dinámicos (Figura 18) sí se han podido extraer como en ocasiones anteriores. Podemos observar cómo más o menos se repite la misma estructura en todas las salidas de los datos dinámicos. Esto es debido a que las bases de datos del DWH en las que almacenamos 33 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS estos datos tienen todas la misma estructura de tablas. Esto permite la homogeneidad del acceso a los datos de la que se ha hablado en capítulos iniciales de esta memoria. Dicho esto, observamos la variable temporal calendar_id, el valor de las medidas y las dos columnas cuya concatenación produce el identificador de los puntos de medida. Figura 18: Piloto 02: Línea Ellona - Salida de datos dinámicos Línea Wattsense Por último, en el tercer flujo de la transformación de este piloto, obtenemos datos a través de la API de Wattsense. Las salidas de esta interfaz pueden verse en las figuras 19 y 20. A continuación se comenta su contenido. Como parte de los metadatos de este piloto, en la figura 19 se observan los metadatos de Wattsense. En concreto, se extraen identificadores de los equipos, puntos de medida, dispositivos y propiedad de los mismos. Además, se recoge el nombre de la magnitud y su unidad de medida. Por último, en cuanto a los datos dinámicos de este piloto, (Figura 20), vemos que se genera la variable temporal calendar_id, el identificador de medida, que se usa como identificador del punto en el DWH y el valor del mismo. 34 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Figura 19: Piloto 02: Línea Wattsense - Salida de metadatos Figura 20: Piloto 02: Línea Wattsense - Salida de datos dinámicos 35 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS 4.3. ETL del piloto 03 - IASI&SITTA El piloto IASI&SITTA incluye dos edificios administrativos propiedad y operados por el Municipio de Iasi, la tercera ciudad más grande de Rumanía. Los edificios son el Palacio Rasnoveanu, una construcción histórica de 1880 y una ocupación de 180 personas, y la Pirámide Dubet, un edificio más reciente y una ocupación de 170 personas. Ambos edificios operan los días laborales en horario de mañana y tarde. El objetivo principal del piloto es desarrollar Certificados de Desempeño Energético (EPC) más efectivos y precisos, integrados con el Libro de Registro Digital del Edificio (DBL). La digitalización y monitoreo de las instalaciones son claves para asegurar la interoperabilidad y la recopilación de datos. Tras analizar la información de este piloto, podemos identificar en las cinco dimensiones del big data la siguiente información: Valor: Como en los pilotos anteriores, en IASI&SITTA se obtendrán perfiles de consumos junto con información del entorno para poder alcanzar de forma satisfactoria la mejora de los EPCs mencionados junto con una mejora de la digitalización de los edificios y, por consiguiente, la explotación de los datos extraídos. Variedad: Este piloto cuenta con datasets con información sobre calidad de aire exterior e interior (como la temperatura, la humedad, la presión y la concentración de CO2 ), consumos de electricidad, aire caliente y aire frío, almacenando un total de 10 variables diferentes. El piloto 03 cuenta únicamente con una interfaz. Esta interfaz se corresponde con la API HTTP que ofrece la base de datos InfluxDB en su versión 3.0 para atender peticiones SQL. Esta base de datos es de código abierto y se ha desarrollado especialmente para facilitar el almacenamiento de series temporales [40]. En Kettle no existe actualmente un plugin que permita integrar como fuente de datos una base de datos InfluxDBv3, por lo que se ha tenido que integrar un código en Python que lleva a cabo las siguientes funciones: • Instalación de las librerías necesarias para la ejecución. • Definición del cliente de BBDD de InfluxDBv3 con los credenciales proporcionados por el piloto. • Generación de certificados TLS para la petición a la API. • Definición de las peticiones SQL para consumo de energía eléctrica y calidad de aire especificando el periodo temporal deseado. • Guardado de los datos obtenidos en dos ficheros CSV. Volumen: Para el piloto 3, contamos con una producción limitada de datos alcanzando apenas los 3,5 MB al año. Pese a tener un volumen más reducido que el resto de pilotos, mantiene la exuberancia de las otras dimensiones del big data sin dejar de ser un piloto interesante en este aspecto. 36 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Velocidad: En este piloto, las variables que se almacenan se generan con un periodo de 15 minutos para las magnitudes de calidad del aire y 1 hora para los consumos de energía. Veracidad: El único punto de acceso a los datos almacenado en el piloto 03 es a través de la API que proporciona la base de datos InfluxDB. Para poder hacer uso del endpoint se deben tener en cuenta diferentes medidas de seguridad para el acceso a los datos, como la identificación del usuario con sus credenciales o la creación de unos certificados TLS. Por esto, consideramos que las extracciones proporcionan datos no mutados y fiables. 4.3.1. Flujo de datos Job En el job definido para este piloto (figura 21) se encuentra el bloque de ejecución del script de Python que se ha explicado anteriormente. Este script genera como salidas dos ficheros CSV. Posteriormente se ejecuta la transformación, la cual no requiere la parametrización de ninguna variable. Además, definimos la línea de alarma por mail en caso de algún error en la ejecución. Este job esta configurado con un periodo de repetición de una hora. Figura 21: Job piloto 03 Transformación La transformación asociada al piloto 03 consta de dos flujos de datos. Cada uno de ellos se corresponde con un fichero CSV extraído en el paso previo en el job. La primera de ellas (Figura 22), relativa al consumo eléctrico, comienza directamente con la separación de los datos estáticos y los dinámicos. Los metadatos no sufren ninguna transformación más, mientras que los datos temporales calculan el calendar_id antes del guardado de los datos en el DWH y en el broker en el topic digibuild.03.building (previa composición de los mensajes en formato JSON). La otra línea se corresponde con los datos sobre calidad de aire (figura 23 inferior). Se comienza con un pivotaje de los datos, previo a la separación de los metadatos y datos temporales. De nuevo, los metadatos no sufren ninguna transformación adicional, mientras que los datos temporales concatenan dos de sus campos para la formación del identificador único de los sensores y calculan el calendar_id. En la línea de calidad de aire se exportan los datos al DWH. 37 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Figura 22: ETL piloto 03 - Línea Energía Figura 23: ETL piloto 03 - Línea Calidad Aire 4.3.2. Salidas En para este piloto, la conexión con la base de datos en el flujo de datos de energía se produjo posterior al desarrollo de la transformación, por lo cual no se obtuvo una muestra de la salida producida. A pesar de ello, se ha expuesto que el formato de origen y las transformaciones son los mismos en ambos casos, por lo que podemos asegurar que el formato de la salida será igual en ambos flujos. Como resultado de la línea de calidad de aire, se obtienen dos salidas de datos, uno de metadatos y otro de datos dinámicos. A continuación, procedemos a describir estas salidas. En lo referente a los metadatos (Figura 24) vemos diferentes campos relativos a los dispositivos de medida. Entre ellos se encuentran, el identificador del sensor (dirección MAC), fecha de última actualización, tipo de dispositivo, nombre del módulo (nombre de la habitación), disponibilidad del dispositivo, listado de magnitudes medibles, localización, nombre de la estación, identificador del módulo (dirección MAC), fecha de actualización del módulo. Por otro lado, para los datos dinámicos (Figura 25), podemos ver la MAC del dispositivo, que se usará como identificador del punto concatenado junto con el nombre de la magnitud, el valor de la propia medida y la variable temporal calendar_id. 38 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Figura 24: Piloto 03: Línea Calidad de Aire - Salida de metadatos Figura 25: Piloto 02: Línea Calidad de Aire - Salida de datos dinámicos 39 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS 4.4. ETL del piloto 04 - VEOLIA El piloto 04 cuenta con dos distritos de redes de calefacción separados geográficamente. Estos distritos registran datos a nivel de BEMS y DEMS. Los objetivos de este piloto son, principalmente, la mejora de la calidad de los datos que actualmente se monitorizan en ambos distritos y, como producto de este objetivo, se propone como meta alcanzar el punto óptimo de operación para los distritos energéticos a través de los gemelos digitales, en definitiva, sus recursos energéticos. En ambos distritos energéticos, tenemos diferentes objetivos. Comenzando por la recopilación de datos, integrando datos dinámicos y estáticos de múltiples fuentes en un sistema unificado. Además, optimización energética, mejorando la eficiencia energética mediante el análisis avanzado de datos, así como implementar sistemas de gestión que optimicen el uso de recursos energéticos. Finalmente, contribuir a la sostenibilidad ambiental reduciendo el consumo energético y las emisiones de carbono. Todos estos objetivos se consiguen mediante la adopción de tecnologías avanzadas para la transformación digital en la gestión de infraestructuras. 4.4.1. Dimensiones del big data Tras analizar la información sobre VEOLIA, podemos identificar en las cinco dimensiones del big data la siguiente información: Valor: El valor o la información que obtendremos de los datos de ambos distritos serán patrones de necesidad de calefacción en función del tamaño de los propios distritos, del precio del gas y de parámetros ambientales externos, principalmente la temperatura y la radiación solar. De esta forma, se podrán alcanzar los objetivos propuestos para el piloto. Variedad: El distrito de FASA monitoriza mas de 750 variables, mientras que el de Río Vena, sólo 15. Estas variables comprenden datasets de las diferentes partes de las redes de calor, como la sala de calderas, datos meteorológicos, de la subestación y del sistema de generación fotovoltaica. Volumen: A diferencia del caso anterior y dado el elevado número de variables relevantes del piloto, el volumen de datos que se genera asciende a aproximadamente 290 MB mensuales o 3,5 GB al año. Velocidad: Las diferentes variables para le piloto 4 se muestrean cada 15 minutos. En este piloto, se cuenta con una única interfaz de datos, como en el caso del anterior piloto. Esta vez el protocolo que implementa esta interfaz es SFTP, que internamente emplea peticiones SQL para acceder a las tablas donde almacenan los datos. Para cada distrito se genera un fichero CSV diariamente conteniendo los registros de todas sus variables. Estos ficheros son publicados en el servidor SFTP de los edificios del piloto con una frecuencia, independientemente de la frecuencia de muestreo que tenga configurada cada punto de recogida de datos del sistema. 40 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Veracidad: Se ha mencionado el uso del protocolo SFTP, el cual se emplea en la transferencia de ficheros de forma segura, además de solicitar credenciales proporcionados por el responsable técnico del piloto. 4.4.2. Flujos de datos Job El job asociado al piloto 04 (figura 26) consta de dos flujos. En cada uno de los flujos de lleva a cabo la conexión y extracción de los ficheros CSV mencionados en el párrafo anterior. Tras la descarga de los datos energéticos, se procede a la llamada de los dos ficheros ETL generados. Para ambas líneas se ha definido la alarma vía e-mail en caso de error en la ejecución del job. Limitados por la frecuencia de publicación de dichos ficheros en el servidor FTP del piloto, se ha definido un periodo de ejecución para el job de un día. Figura 26: Job piloto 04 Transformación Pese a ser dos transformaciones diferentes (Figuras 27 y 28), el formato de origen de los datos y, por tanto, el procesamiento es similar, por lo que se explicará simultáneamente para ambos casos. Tras la importación de los datos almacenados en los ficheros CSV que se han extraído en el job del servidor SFTP, comenzamos cambiando el caracter empleado como punto decimal, de coma a punto (“,” por “.”). Después, se separan algunos de los campos en diferentes subcampos y es a partir de aquí cuando podemos diferenciar entre la parte de metadatos y la parte de datos dinámicos del flujo. Tras la separación, en la parte de los metadatos se vuelven a separar diferentes campos y se eliminan las columnas originales para dar lugar a la versión final de los mismos y se procede a eliminar las filas que se repiten. En la parte de los datos dinámicos, se filtran las variables sólo relevantes para su almacenamiento y uso. Este filtrado se lleva a cabo mediante una petición SQL a la tabla del DWH donde se almacena el listado de variables de VEOLIA 41 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS el acceso a los endpoints de los flujos de datos del edificio ni de producción fotovoltaica. Es por esto que se mostrará la salida del flujo de datos de las estaciones de carga. La figura 35 nos muestra un extracto de dicha salida. En ella se pueden observar columnas con una estructura similar a lo expuesto en anteriores casos, como un identificador de medida, en este caso el número de la estación de carga. Además, del valor de las medidas y el instante temporal en el que han sido tomadas con el formato definido al comienzo del capítulo de esta memoria. Figura 35: Piloto 05a: Línea CS - Salida de datos dinámicos 48 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS 4.6. ETL del piloto 05b - FOCCHI El piloto de FOCCHI se desarrolla en un edificio de las oficinas centrales de la fábrica de FOCCHI en Rimini, Italia. Este piloto emplea dos sistemas principales de BMS para recopilar datos de sensores ambientales (temperatura, humedad, luminancia, presencia, etc.) y medidores de energía. Dada la fragmentación de estos sistemas. Los objetivos principales del piloto incluyen la homogeneización de los servicios de monitoreo para enfrentar estos desafíos, optimizando el uso de energía y proporcionando a los gerentes de Recursos Humanos y de Instalaciones análisis para verificar y asegurar un mayor nivel de bienestar para los ocupantes . 4.6.1. Dimensiones del big data Tras analizar la información sobre el piloto 05, podemos identificar en las cinco dimensiones del big data la siguiente información: Valor: Se pretende generar una mejora en la comodidad en el acceso a la información gracias a la homogeneización de los datos, así como mejoras en la visualización y, por tanto, en el control ambiental y consumo gracias a los Digital Twins, además de poder producir perfiles de comportamiento en los trabajadores de las oficinas. Variedad: Se cuenta con multitud de fuentes de datos diferentes dentro de varios edificios, conformando los siete datasets disponibles. Existen dos sistemas de gestión de edificios (BMS) principales que recopilan datos dinámicos e históricos de consumo energético, producción de energía fotovoltaica, parámetros ambientales internos y externos, y retroalimentación de usuarios. En total se alcanzan unas 350 variables diferentes. Estos datasets no son accesibles desde una misma interfaz. La extracción de datos de este piloto se centra principalmente en 4 de estas interfaces. Estas interfaces son accedidas empleando los procedimientos que se describen a continuación. Volumen: La cantidad de datos generados en este piloto es bastante grande, pero no se especifica por parte de los responsables del mismo de forma concreta. Las interfaces de extracción de los datos tienen frecuencias de muestreo elevadas y variadas, proporcionando datos con una granularidad desde cada segundo hasta cada hora. Gracias al conocimiento de la frecuencia y la cantidad de variables podemos estimar que no será uno de los pilotos que menos volumen de datos produzca dentro de DigiBUILD. Velocidad: La generación de datos en cada uno de los flujos tienen frecuencias muy variables, como hemos mencionado en la dimensión anterior recorren desde el segundo hasta la hora. En algunos de ellos, como el que emplea MQTT, se generan prácticamente cada segundo, mientras que la generación de los ficheros CSV en la línea de Google Drive se generan diariamente. Es por esto que se ha decidido unificar la frecuencia de la extracción de los datos en todas las interfaces, ajustándola a 1 vez al día. 49 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Veracidad: Como en anteriores ocasiones, los datos provienen de servidores custodiados y mantenidos por el responsable del piloto. Su equipo son los únicos con capacidades de gestionar los accesos a los datos y, por consiguiente, velar por su correcto funcionamiento y capacidad de medición. Además, los accesos a las diferentes interfaces se llevan cabo empleando pórtalos estándar seguros, como HTTPS o MQTTS. 4.6.2. Flujos de datos Job El job correspondiente al piloto 05b (Figura 36) está formado por dos bloques de ejecución de scripts externos para la extracción de datos para varios de los flujos que se explicarán a continuación. Posteriormente, se llama a la transformación, pasándole como parámetros la clave de la API y los credenciales de dichos flujos, para la API y el broker. Observamos en la figura que si en alguno de estos pasos se produce algún tipo de error, se informará mediante un e-mail a los administradores configurados. Figura 36: Job piloto 05b Transformación La primera interfaz de datos (Figura 37) se corresponde con la API que proporciona datos de generación fotovoltaica. La transformación comienza con la obtención de los parámetros pasados desde el job, siendo estos la frecuencia de ejecución y los credenciales de acceso a las APIs. En esta interfaz se extraen los datos de dos endpoints de una API, la cual requiere autenticación que mencionamos. Tras las llamadas a la API se extraen los campos y subcampos del JSON que son relevantes y se unifican los flujos. Después, Se procede a formatear los datos aplicando filtrado de valores nulos, haciendo un pivotaje y formando los campos que nos interesan mediante concatenación de diferentes columnas del flujo. También, se procede a la generación del parámetro temporal calendar_id. A continuación, se separan los datos dinámicos de los metadatos y se filtran las variables necesarias mediante una petición SQL a la tabla del DWH donde se almacena el listado de variables de FOCCHI, así como con la unión de los flujos y el filtrado de las filas que no encuentren una coincidencia entre la lista de puntos del DWH y 50 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS las variables extraídas de la API. Finalmente, los datos temporales se vuelcan en el DWH. De esta interfaz no se exporta ninguna variables al broker Kafka. Figura 37: ETL piloto 05b - Línea generación PV Para el segundo flujo (Figura 38), extraemos los mismos argumentos que pasa el job. Después, extraemos los datos de otra API que requiere autenticación y ésta genera un token de sesión al hacer una consulta a un endpoint y autenticarnos. Tras la obtención de este token, procedemos a la extracción de los datos en un endpoint diferente. Ahora se procede al formateo de los datos originales extrayendo los campos relevantes de la respuesta de la API y se transforman los valores de las variables booleanas a un equivalente numérico, se forman los campos relevantes mediante la concatenación de diferentes columnas y se lleva a cabo un pivotaje para poder tener una estructura de los datos en columnas. Tras ello, se separa la parte de metadatos del flujo. Finalmente, procedemos al filtrado de los puntos que se han definido en el DWH y su posterior exportación al mismo DWH y a en Kafka en los topics de las variables en datos de edificio (digibuild.05b.building) y de calidad de aire (digibuild.05b.airquality). El filtrado se hace tras obtener un listado de sensores relevantes del piloto y cruzarlo con los sensores obtenidos en la API. El tercer flujo (Figura 39) consiste en una fuente de datos formada por un broker MQTT donde se publican, haciendo uso de un token para la autenticación, los mensajes con contenido de la misma índole que en la API anterior. Tras dicha extracción, obtenemos una respuesta con datos en formato JSON y se aplican filtros consecutivos para la obtención de los parámetros específicos dependiendo del tipo de sensor que los haya generado embebidos en subcampos de la estructura JSON. En cada sub-flujo que hemos generado se aplica un pivotaje de los datos para conseguir una estructura pura en columnas y se unifican todos ellos. Después, generamos el parámetro temporal calendar_id. Posteriormente, se filtran los puntos registrados en el DWH mediante el cruzamiento del listado de sensores almacenados en el DWH y los obtenidos del broker. Por último, se exportan al mencionado DWH y en Kafka en el topic digibuild.05b.building. Cabe destacar que en este flujo no extraemos ningún metadato. 51 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Figura 38: ETL piloto 05b - Línea sala 1 Figura 39: ETL piloto 05b - Línea sala 2 En el cuarto y último flujo (Figura 40), se extraen los datos mediante un script que se ejecuta en el job mediante una autenticación en la API de Google Drive. Los datos extraídos en formato CSV contienen información de consumos energéticos de diferentes partes del edificio de aplicación. Tras la importación de los datos, se eliminan las columnas no relevantes para el proyecto y se transforma el separador decimal de “,” a “.”. Después se genera el parámetro calendar_id y se pivota la tabla de datos resultante. Como últimos pasos del flujo se procede a filtrar únicamente los sensores registrados y se exportan los datos limpios y formateados al DWH y al topic de Kafka digibuild.05b.building. 52 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Figura 40: ETL piloto 05b - Línea Google Drive Salidas En este apartado procedemos a explicar las salidas de las diferentes líneas que conforman los flujos de datos del piloto de FOCCHI. De nuevo, cabe destacar que las figuras presentadas son muestras parciales del proceso de desarrollo de las ETLs y no enseña el formato final que se ha elegido en el procesamiento de los datos generados. En la figura 41 se observa una muestra de datos dinámicos extraída de la interfaz de la línea de generación fotovoltaica del piloto 05b. En ella se aprecian las columnas de Type ysensor_ID, empleadas como identificador de las variables extraídas de energía y potencia, una columna que contiene el valor de la medida (todas ellas son ceros debido a que son en hora de la madrugada) y, por último, la variable temporal. Figura 41: Piloto 05a: Línea generación PV - Salida de datos dinámicos La segunda muestra de las salidas de este piloto (Figura 42) se corresponde con los datos dinámicos de la línea de la sala 2. En ella se aprecian salidas de tres tipos de dispositivos diferentes. Uno de estos tipos mide consumos energéticos de los fancoils de la sala bajo medida, 53 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS así como un identificador de los mismos y el correspondiente parámetro temporal en el que fueron tomadas estas medidas. Otro tipo de sensor mide temperatura y humedad, mientras que el tercero genera mediciones de dióxido de carbono, manteniendo la columna de identificador de medidor y de temporalidad. Figura 42: Piloto 05a: Línea Sala 2 - Salida de datos dinámicos 54 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS 4.7. ETL del piloto 06 - HERON El piloto HERON es liderado por la empresa HERON, dedicada a la producción, suministro y comercialización de electricidad. El demostrador dentro del proyecto consiste en múltiples apartamentos que forman parte del mismo edificio, incluyendo un punto de carga individual. El principal objetivo del piloto es promover edificios libres de carbono y gestionar la flexibilidad de la demanda agregada de múltiples viviendas. La armonización de datos y la interoperabilidad son aspectos clave a considerar debido a la heterogeneidad de los datos que se generan, incluyendo medidores inteligentes de electricidad del edificio, datos de sensores, carga de vehículos eléctricos y activos de generación renovable. 4.7.1. Dimensiones del big data Tras analizar la información sobre HERON, podemos identificar en las cinco dimensiones del big data la siguiente información: Valor: En HERON podemos generar análisis de patrones de consumo energético de los convivientes del edificio, algoritmos de balanceo de carga relativo a los consumos o respuesta flexible de la demanda, así como modelos de predicción de esta demanda a partir de los datos que obtenemos del propio piloto y que nos ayudarían a alcanzar los objetivos propuestos. Variedad: El piloto 06 está conformado por las diferentes fuentes de datos generadas en un único edificio. Este piloto cuenta con 7 diferentes conjuntos de datos diferentes, los cuales cubren datos de enchufes y medidores inteligentes, generación de energías renovables diversas, mediciones de CO2y vehículo eléctrico. En este caso de uso sólo se extraen datos de una única interfaz. Además, la generación de datos en casa punto de este piloto es del orden de minutos. Por ambas razones, se ha establecido que la extracción de datos se lleve a cabo automáticamente cada diez minutos. Volumen: En HERON se llegan a producir anualmente un volumen de datos entorno a los 2,5 GB. Estos datos se encuentran originalmente en diferentes formatos de representación (Tabla 1). Velocidad: Las frecuencias de muestreo de los diferentes datasets varían desde los 30 segundos hasta cada varias horas. En nuestro caso, implementaremos la recolección de los datos relativos a la potencia y energía eléctrica en enchufes inteligentes, lo que limita esta variedad de frecuencias a únicamente los 30 segundos. Veracidad: Como se ha mencionado, en el piloto 06 contamos solamente con una API para la adquisición de los datos desarrollada por el propio piloto. La extracción de los datos requiere hacer una petición HTTPS, enviando los credenciales en el cuerpo de la misma, se obtiene un token para nuestra autenticación en futuras peticiones. Además, el mismo piloto es quien gestiona y almacena sus propios datos, así como los sensores y 55 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS dispositivos dedicados a la generación de los mismos. Por estos motivos, se considera que tanto su procedencia como su valor son confiables en mayor o menor medida. 4.7.2. Flujos de datos Job La estructura del job desarrollado (figura 43) consiste únicamente en la llamada a la ETL. Se pasan como parámetros los credenciales para la identificación del usuario al extraer los datos de la API del piloto, así como la frecuencia de ejecución del job. Se define además la alarma vía e-mail en caso de que se produzca un error en la ejecución. Figura 43: Job piloto 06 Transformación La transformación asociada a este piloto se puede ver en la figura 44. En ella, se comienza extrayendo los argumentos pasados a través del job, como los credenciales o la periodicidad de ejecución del propio job. Después, se envía una petición a uno de los endpoints de la API autenticándonos y de esta forma obtenemos un token de sesión válido para la extracción de los datos. Una vez obtenido el token, lo extraemos del campo JSON correspondiente en la respuesta y generamos una nueva URL para solicitar un listado de dispositivos. Una vez obtenida la respuesta con el listado, el flujo se separa en metadatos y datos dinámicos. En relación a los metadatos, se lleva a cabo una petición con un nuevo URL creado a partir d elos dispositivos obtenidos para preguntar a un nuevo endpoint por información sobre dichos dispositivos. Los datos dinámicos son obtenidos en respuesta a una petición al endpoint pertinente y extraídos los campos y subcampos de interés de la estructura JSON. Cada una de las fases de los smart meters de las diferentes variables energéticas registradas hacen que sea necesario dividir el flujo. Posteriormente, en el flujo de energía de retorno se eliminan los valores nulos dado que no todos los dispositivos lo miden y en el subflujo de relés se transforman los valores de Booleanos “On” y “Off” a numéricos “1” y “0”. Después, se pivotan los datos y se unen, generando de esta forma un único flujo con estructura en columnas. A continuación, se genera el parámetro 56 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS temporal calendar_id. Por último, se filtran los puntos relevantes cruzando el listado de variables definidas en el DWH y los obtenidos de la API y se exportan al mismo DWH, así como a los topics digibuild.06.building ydigibuild.06.ev respectivamente del broker Kafka. Figura 44: ETL piloto 06 Salidas En este apartado procedemos a explicar las salidas de las diferentes líneas que conforman los flujos de metadatos y datos dinámicos del piloto de HERON. Para la salida de metadatos (Figura 45) observamos una tabla con información sobre los dispositivos que miden las variables energéticas en el edificio de HERON. Estas variables son el tipo de dispositivo dentro del fabricante en forma numérica o de texto, el nombre de los mismos, un identificador del apartamento en el que se encuentran, su fecha de registro y las magnitudes que mide cada uno de ellos. En contraparte, tenemos los datos dinámicos, cuya muestra podemos ver en la figura 46. En 57 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Figura 52: ETL piloto 08 - Línea MQTT credenciales y genera tanto un access token como un refresh token. Cada vez que se quiere acceder a un recurso protegido dentro de la API, se manda en la cabecera el access token y puede hacer uso de él hasta que éste expira. Una vez el access token caduca, se emplea el refresh token para solicitar otro access token al servidor, evitando tener que autenticarse de nuevo con los credenciales. Este mecanismo mejora la seguridad de los datos en servidores dada la corta vida útil de los access tokens, así como un mayor control de la revocabilidad de los permisos y sesiones activas y, finalmente, para la experiencia del usuario, evitando tener que identificarse constantemente. Tras la obtención del token, procedemos a la extracción del listado de estaciones disponibles en la API. Después, se extrae dicha lista del objeto JSON recibido y es a partir de aquí cuando se separan los metadatos del flujo. Respecto a los datos dinámicos, se extraen a partir de una nueva petición al endpoint indicado. Una vez con los datos en el flujo, separamos las columnas que contienen múltiples datos concatenados y juntamos las que necesitamos que formen un único tipo de dato. Después, se lleva a cabo un pivotaje para obtener la estructura por columnas que buscamos, se filtran las muestras vacías y se calcula el calendar_id. Finalmente, se filtran los puntos medidos mediante un cruce con la lista de variables almacenadas en la tabla del piloto del DWH, obteniendo así únicamente los relevantes para el proyecto. Esta exportación se lleva a cabo tanto hacia el DWH como al broker en el topic digibuild.08.airquality. Salidas En este apartado procedemos a explicar las salidas de las dos líneas que conforman los flujos de datos dinámicos del piloto 08. Para la primera línea, la correspondiente con el cliente MQTT, podemos ver en la figura 54 el formato de los datos previo a la trasposición de las columnas que contienen las medidas. Cabe destacar que la situación final consistirá en que la columna de identificación de las variables sea la concatenación de la columna device_id y el nombre de la magnitud correspondiente además de una columna con el correspondiente valor medido. Por último y, como en todos los pilotos y flujos, la columna de la variable temporal calendar_id. 64 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Figura 53: ETL piloto 08 - Línea Netatmo Figura 54: Piloto 08: Línea MQTT - Salida de datos dinámicos En el caso de la línea de la interfaz Netatmo (Figura 55), se generará una columna que identifique el punto de medida con la concatenación de las columnas Device, Measure yNumber, el valor de la medida se corresponderá con Message en formato numérico y, de nuevo, la temporalidad aportada por el calendar_id. 65 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Figura 55: Piloto 08: Línea Netatmo - Salida de datos dinámicos 66 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS 4.10. ETL del piloto 09 - NTUA Por último, el piloto NTUA está implementado en un conjunto de edificios universitarios dentro del campus de la Universidad Técnica Nacional de Atenas. Estos edificios son representativos de las instalaciones educativas típicas y proporcionan un entorno adecuado para probar y validar tecnologías avanzadas de gestión energética. Proporciona un entorno rico y diversificado para la evaluación de tecnologías avanzadas de gestión energética, abarcando una amplia gama de sistemas y dispositivos que trabajan juntos para optimizar el uso de energía y mejorar la sostenibilidad de las operaciones del campus universitario. Entre los objetivos de este demostrador destacamos la implementar tecnologías avanzadas de gestión energética así como su monitoreo y análisis para reducir su consumo energéticos. Además, de la valoración de la viabilidad de inversiones y beneficios obtenidos de mejoras que supondrían inversiones en las soluciones de eficiencia energética. 4.10.1. Dimensiones del big data Tras analizar la información sobre el piloto 09, podemos identificar en las cinco dimensiones del big data la siguiente información: Valor: Gracias a la explotación del monitoreo continuo de los datos, pueden llevarse a cabo controles de consumos más exhaustivos que permitan detectar fallas en el uso de las instalaciones o equipos, así como llevar a cabo análisis con gran detalle de las potenciales inversiones en equipos y su rentabilidad en el corto y largo plazo. Variedad: Este piloto está formado por un único edificio y cuenta con un numero bastante limitado de mediciones. Se recogen datos en diferentes 2 datasets: sobre consumos energéticos, siendo aire acondicionado, luz y ventilación, y sobre parámetros de confort, siendo temperatura y humedad relativa. Volumen: La estimación del volumen de datos generado en este demostrador asciende a los 1,5 GB anuales. En comparación con los demás demostradores podemos observar que es uno de los que más cantidad de datos genera. Velocidad: Los sensores y medidores operando en las instalaciones recogen datos en periodos que varían entre los 5 minutos y la media hora en función de la variable física que midan. Para la extracción de los datos de los diferentes datasets se ha migrado la base de datos de una InfluxDB a una PostgreSQL y se vuelcan los datos dos veces al día. Así, la extracción de los datos se lleva a cabo mediante una petición SQL a una gran cantidad de tablas y donde se especifica el periodo temporal de las mediciones que se desean recuperar. La generación de datos se lleva a cabo cada 10 minutos aproximadamente, pero el volcado en la base de datos a través de la cual tenemos accesibles los mismos se hace dos veces al día, limitando de esta forma el número de veces que hacemos las peticiones. 67 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Veracidad: La veracidad de los datos extraídos en este piloto está asegurada dado que en el proceso de petición y respuesta se emplea el protocolo TLS. Además, el acceso a la base de datos de PostgreSQL que consultamos requiere de una autenticación. 4.10.2. Flujos de datos Job El job correspondiente a esta transformación (figura 56) cuenta únicamente con el bloque de ejecución de la propia ETL. A esta ETL no se le pasa ningún parámetro, dado que la identificación se lleva a cabo en la definición de la conexión con la base de datos y le frecuencia de ejecución del job necesita ser un literal dentro de las peticiones SQL. En este job también se implementan las alarmas por correo electrónico en caso de error de ejecución en la transformación. Figura 56: Job piloto 09 Transformación En la transformación para el piloto 09 (figura 57) comenzamos con dos flujos que realizan peticiones SQL a la base de datos del piloto. Esto se debe a la existencia de diferentes columnas en cada caso, lo que evita que ambos flujos puedan ser unificados sin ningún formateo previo. En la primera, las peticiones se realizan a las diferentes tablas que contienen datos sobre consumos energéticos de aire acondicionado y de luz. En la segunda extraemos datos sobre magnitudes ambientales, como la temperatura y la humedad. En ambas líneas se lleva a cabo un pivotaje de los datos para poder extraer los metadatos. Con los dos flujos de los datos dinámicos, se unifican y se procede a realizar un pivotaje. Después, se unen dos de las columnas para formar el identificador de los sensores y se construye el calendar_id. Para finalizar, filtramos los puntos relevantes que almacenamos en la tabla del piloto dentro de nuestra base de datos del DWH y se exportan los datos al DWH. En este caso no se requiere de exportación a ningún topic del broker. 68 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Figura 57: ETL piloto 09 Salidas En este apartado procedemos a explicar las salidas de las tablas de las cuales extraemos los datos dinámicos del piloto de NTUA. Comenzando por la figura 58, donde vemos los datos de la tabla de consumos de energía de los aires acondicionados y de la iluminación de diferentes salas de los edificios del demostrador. Podemos identificar las columnas de nombre de objeto y medida como las que se han usado de forma concatenada para identificar el punto de medida. Además, las columnas de valor de las medidas y de temporalidad como en los demás casos expuestos. De forma equivalente, en la figura 59 observamos una muestra de datos de la tabla que almacena datos sobre magnitudes de calidad de aire. Las columnas que se observan son iguales que en el caso anterior y tienen el mismo tratamiento en la salida de la propia ETL. 69 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Figura 58: Piloto 09: Tabla Aire Acondicionado e Iluminación - Salida de datos dinámicos Figura 59: Piloto 09: Tabla Calidad Aire - Salida de datos dinámicos 70 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS 4.11. ETL de la API meteorológica Esta ETL emplea como entrada de datos una de las fuentes externas del proyecto. En este caso se utiliza la API meteorológica de WeatherBit. El motivo de la elección de este servicio es por la disponibilidad de una licencia por parte de nuestra organización. Los pilotos cuyos servicios y/o gemelos digitales requieren de información meteorológica proporcionada por esta API son UCL (01), EDF (02), IASI&SITTA (03), VEOLIA FASA (04a), VEOLIA RVENA (04b), EMOT (05a) y HERON (06). 4.11.1. Dimensiones del big data Valor: El valor que se extrae en este caso es más directo y sencillo que en las interfaces de los pilotos. Esto se debe a que principalmente se usa para servicios de predicción de generación fotovoltaica o de consumos de calefacción o por los gemelos digitales de algunos de dichos pilotos. Variedad: Adicionalmente, una ventaja con respecto a otros servicios de predicción meteorológica es que esta API proporciona datos sobre una gran variedad de variables meteorológicas (más de 20), entre ellas, varios tipos de radiación solar, las cuales afectan directamente a los datos de los pilotos sobre la generación fotovoltaica y, por consiguiente, son datos muy relevantes para los servicios de predicción de este tipo de energía. De las diversas magnitudes que proporciona ese servicio, las más importantes son las que extraemos para el caso de aplicación, que son apenas 10. Estas variables son la temperatura, la presión, la velocidad y dirección del viento, la humedad, la cobertura del cielo y las radiaciones difusa, directa, global y estimada. Cada vez que se ejecuta la transformación se hace una llamada pidiendo las previsiones a 10 días con frecuencia horaria de los pilotos que requieren datos meteorológicos Volumen: Las características que nos concede el acceso a este servicio son 25.000 llamadas por día (25 llamadas por segundo), predicción meteorológica diaria con horizonte temporal de 16 días, predicción meteorológica horaria con horizonte temporal de 10 días y predicción meteorológica minutal con horizonte temporal de 1 hora. Velocidad: La API de la que extraemos datos en esta ETL proporciona, de la forma en la que la usamos en nuestro caso de uso, predicciones meteorologías con frecuencia horaria. Con motivo de no sobrecargar la máquina en la que corren los procesos que ejecutan las transformaciones, se a considerado que una frecuencia de ejecución diaria es suficiente para cubrir las necesidades de extracción de estos datos. Veracidad: La ejecución de las peticiones a la API a través del bloque que proporciona Pentaho nos asegura el uso del protocolo seguro TLS que, junto con la autenticación del usuario para el uso de la API podemos considerar una extracción de datos veraces. 71 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS 4.11.2. Flujos de datos Job El job desarrollado para la transformación de WeatherBit (Figura 60) consta únicamente de la llamada a la ETL. No se requiere de ningún parámetro del que haga uso la transformación. La repetición de la ejecución del job está configurada para ser llevada a cabo diariamente. Figura 60: Job API meteorológica Transformación La transformación implementada (figura 61) cuenta con un único flujo de datos, aunque dentro del mismo se tratan simultáneamente los datos de las peticiones de los diferentes pilotos que las requieren. Específicamente, los pilotos que requieren de esta información meteorológica son los pilotos 01, 02, 03, 04 (ambos), 05a y 06, como se ha mencionado en el apartado anterior. La extracción de los datos meteorológicos se lleva a cabo a través de peticiones HTTP al endpoint correspondiente de la API. Para estas peticiones se utiliza la localización geográfica de los diferentes pilotos interesados, devolviendo los datos en formato JSON. Tras la obtención de los datos de predicción meteorológica en formato JSON de cada uno de los pilotos se formatean los datos extrayéndolos de subcampos del JSON original, haciendo un pivotajes y calculando el parámetro calendar_id. Por último, se exportan las predicciones obtenidas y formateadas al DWH. Además, se emplea el campo city_name para poder discernir a qué topic de Kafka publicarlo. Estos topics son los siguientes: 4.11.3. Salidas del flujo En la figura 62 podemos ver la salida de la ETL. En la primera columna se especifica el nombre de la ciudad a la que se corresponden los datos de la predicción. EN la segunda columna se observa el mensaje que se va a publicar en Kafka, con los campos de magnitud, calendar_id (como en los pilotos) y el valor. Además, estas predicciones obtenidas a través de la API se almacenarán en el DWH con el 72 CAPÍTULO 4. EXTRACCIÓN DE DATOS DINÁMICOS Figura 61: ETL API meteorológica Piloto Topic 01 - UCL digibuild.01.weather 02 - EDF digibuild.02.weather 03 - IASI&SITTA digibuild.03.weather 04a - VEOLIA FASA digibuild.04a.weather 04b - VEOLIA RVENA digibuild.04b.weather 05a - EMOT digibuild.05a.weather 06 - HERON digibuild.06.weather Tabla 3: Topics de predicción meteorológica Figura 62: Salida de Kafka API meteorológica mismo formato que se almacenan los datos de las ETLs de los pilotos: [calendar_id,sensor_id, valor]. 73 CAPÍTULO 6. BASE DE DATOS PARA DE DATOS CONTEXTUALES Y DINÁMICOS: DATA WAREHOUSE Y KNOWLEDGE GRAPH 6.1. DWH: Bases de datos relacionales y no relacionales Las bases de datos pueden clasificarse, principalmente en dos grandes tipos: las bases de datos relacionales (SQL) o las no relacionales (No-SQL). Las bases de datos relacionales almacenan los datos en tablas, estas tablas comparten la información, creando de esta forma relaciones entre ellas. Cada una de estas tablas tiene una columna que almacena un identificador único para cada entrada de la tabla, conocido como clave primaria, que puede ser referenciada en las otras tablas que conformen el esquema de la base de datos para poder dar lugar a las relaciones mencionadas. El uso de esta clave primaria en otra tabla la convierte en clave foránea de la misma. Las ventajas de este tipo de bases de datos son las siguientes: Cumple con el estándar ACID [ 11 ]: Esto asegura la fiabilidad de las transacciones en entornos de procesamiento de datos. ACID es un acrónimo que se refiere a Atomicidad (cada transacción se ejecuta por completo o no se ejecuta en absoluto), Coherencia (cada transacción lleva la base de datos de un estado válido a otro también válido), Aislamiento (las transacciones se ejecutan como si fueran la única en el sistema, aun cuando se ejecutan concurrentemente), y Durabilidad (los resultados de una transacción se mantienen incluso en caso de fallos del sistema). Este conjunto de propiedades garantiza que las bases de datos mantengan la integridad de los datos y soporten transacciones seguras y estables. Precisión de los datos: Esto pretende evitar la duplicidad de los datos haciendo que no se almacene información de forma redundante. Normalización: Ayuda a que los datos se almacenen de forma organizada intentando que no se generen anomalías o intentando evitarlas en la medida de lo posible. Facilidad en su implementación: Dado que existen multitud de herramientas y el lenguaje SQL están tan extendidos, se encuentran en un estado de optimización elevado en los gestores de bases de datos. Las bases de datos no relacionales, por el contrario, no cuentan con una estructura rígida para le almacenamiento de los datos. Se diseñan teniendo en cuenta su flexibilidad y gran escalabilidad horizontal. Se pueden categorizar en diferentes tipos, cada uno de ellos con fortalezas y debilidades específicas. Las ventajas de este tipo de bases de datos complementan las de las relacionales, siendo principalmente la flexibilidad y la escalabilidad. Nuestros datos han sido tratados y procesados en las ETLs que se han definido, por lo que ha cuentan con una estructura estándar. Además, al manejar tales volúmenes de datos (debido a que trabajamos con una gran cantidad de pilotos y multitud de variables y fuentes de datos), se requiere reducir al máximo posible la redundancia de información y, en definitiva su espacio en disco. Es por esto que se ha decidido trabajar con bases de datos relacionales. En concreto, trabajamos con bases de datos PostgreSQL [36]. En la fase de desarrollo del proyecto, previa a la fase de producción, se ha decidido definir un esquema para cada uno de los pilotos de forma independiente, aunque alojados en la misma 80 CAPÍTULO 6. BASE DE DATOS PARA DE DATOS CONTEXTUALES Y DINÁMICOS: DATA WAREHOUSE Y KNOWLEDGE GRAPH máquina. Además, el tipo de esquema elegido para la estructura de la base de datos ha sido el esquema en estrella. 6.2. DWH: Esquema en estrella El esquema en estrella es una de las configuraciones más empleadas en las arquitecturas de bases de datos en multitud de sistemas en multitud de campos diferentes. Esta configuración esta formada por dos tipos de tablas: Tabla de hechos: Es el núcleo de la estructura de tablas y almacena las claves foráneas de las demás tablas, además de otras variables cuantitativas. Es conveniente este tipo de topología ya que permite la aplicación de diferentes cálculos a estas variables cuantitativas de una forma directa y más sencilla. Esta tabla de hechos almacena instancias de las observaciones que, en nuestro caso, sería cada medición tomada por uno de los sensores en un instante temporal concreto. Tablas de dimensiones: Cada una de estas tablas almacena información de los campos (columnas) de la tabla de hechos, donde se referencia su clave primaria. Su tamaño es mucho más reducido que el de la tabla de hechos. Esta topología permite generar estructuras de datos y peticiones más simples, además de ser mucho más fácil de comprender por usuarios ajenos. Como se ha mencionado, facilita operaciones sobre los datos, como la agregación, y además, el mantenimiento. En la figura 66 podemos observar un ejemplo de esta topología de base de datos donde, en el centro se encuentra la tabla de hechos y las tablas de dimensiones están conectadas con ella. Figura 66: Esquema en estrella La aplicación de esta estructura de base de datos en nuestra base de datos ha sido respaldada por las recomendaciones de desarrolladores de software para gestión de big data como puede ser 81 CAPÍTULO 6. BASE DE DATOS PARA DE DATOS CONTEXTUALES Y DINÁMICOS: DATA WAREHOUSE Y KNOWLEDGE GRAPH el caso de Microsoft Power BI [ 45 ]. Es sus guías de recomendaciones sobre la estructuración de los datos sugieren el empleo de esta topología o, en su defecto, la configuración en “copo de nieve”, donde las dimensiones pueden estar formadas por varias tablas, no una única. Es una configuración similar a la explicada anteriormente, pero con una complejidad un poco superior. Una característica que pretendemos explotar al máximo es la normalización, que se ha mencionado como ventaja de las bases de datos relacionales. Esta normalización consiste en la extracción de los datos al máximo posible de la tabla de hechos, dejando en cada una de sus entradas únicamente las claves foráneas de todas las dimensiones definidas y el menor número de columnas con datos en ella 6.3. Definición de la base de datos dinámica del Data Warehouse Para concluir con este capítulo se procede a describir la estructura definida para los diferentes esquemas propuestos en nuestra base de datos de PostgreSQL. Para la fase de desarrollo del proyecto se ha decidido implementar une esquema individual para cada uno de los pilotos que conforman el proyecto de DigiBUILD. Cada uno de estos esquemas estará alimentados directamente por la respectiva ETL como se ha descrito en capítulos anteriores. En total se definirán 10 esquemas diferentes. En la figura 67 podemos ver cómo definimos todos los esquemas. La tabla de hechos, llamada f_tsData está formada por cuatro campos o columnas: ts_id:Es la clave primaria de la tabla de hechos, representa de forma única cada entrada de datos en la misma. Es un entero autoincremental. calendar_id:Es la clave foránea de la dimensión temporal. Representa el instante temporal en el que se ha tomado la medida por parte de un sensor concreto. Sigue la estructura explicada en la sección 4.1. Es un tipo de dato entero grande. sensor_id:Es la clave foránea de la dimensión sensor. Identifica únicamente al sensor que toma la medida registrada. Es una cadena de caracteres. value:Este campo de la tabla de hechos es el único que no es una clave foránea y representa el dato como tal. Es la cantidad medida de las deferentes magnitudes físicas que mide cada uno de los sensores de los pilotos. Como podemos observar en dicha figura, también existen tres dimensiones de los datos. Estas dimensiones son: d_calendar, que identifica el momento de la toma de datos de cada entrada de la tabla de hechos; d_sensor, que identifica cada uno de los sensores de los que se recoge datos en cada uno de los pilotos; y d_sensor_type, que define qué tipo de sensor es cada sensor definido en la anterior tabla. 82 CAPÍTULO 6. BASE DE DATOS PARA DE DATOS CONTEXTUALES Y DINÁMICOS: DATA WAREHOUSE Y KNOWLEDGE GRAPH Figura 67: Diagrama de tablas del DWH La tabla d_calendar está formada por las siguientes columnas: calendar_id:Es la clave primaria de esta tabla e identifica unívocamente cada instante temporal con una granularidad de minutos. Su formato está descrito en la sección 4.1. El formato de datos es un entero. year:Se corresponde con el año de la medida. Es un entero de cuatro cifras. month:Se corresponde con el mes de la medida. Es un entero de dos cifras que comprende del 01 al 12. day:Se corresponde con el día del mes de la medida. Es un entero de dos cifras que comprende del 01 al 31. hour:Se corresponde con la hora de la medida. Es un entero de dos dígitos que comprende el rango entre 00 y 23. minute:Se corresponde con los minutos en los que se tomó la medida. Es un entero de dos dígitos definido entre 00 y 59. timestamp:Se corresponde con la fecha y hora de la medida. Tiene el formato timestamp de PostgreSQL. La tabla d_sensor está formada por las siguientes columnas: sensor_id:Se corresponde con la clave primaria de la tabla de sensores. Identifica únicamente a cada uno de los sensores de cada piloto. Es un tipo de dato de cadena de caracteres. name:Esta columna es el nombre del sensor. Es una cadena de caracteres. sensor_type:Este campo se corresponde con la clave foránea de la dimensión tipo de sensor. Identifica qué magnitud física o lógica mide el sensor. 83 CAPÍTULO 6. BASE DE DATOS PARA DE DATOS CONTEXTUALES Y DINÁMICOS: DATA WAREHOUSE Y KNOWLEDGE GRAPH min_value:Se corresponde con el valor mínimo del rango medible esperado tiene cada sensor. Esta variable es un número decimal. max_value:Se corresponde con el valor máximo del rango medible esperado del sensor. En caso de ser magnitudes acumuladas su valor será null. Esta variables es de tipo decimal. frequency:Esta variable describe la frecuencia con la que toma muestras el sensor. Esta columna almacena datos de tipo doble. Por último, la tabla d_sensor_type está formada por las columnas de sensor_type_id, que es la clave primaria de la tabla e identifica unívocamente cada uno de los tipos de sensor que hay en formato de número entero; y la variable type, que describe la magnitud medida y es de tipo cadena de caracteres. Para disminuir el tiempo de respuesta por parte de PostgreSQL, es decir, reducción de la carga computacional, cuando se lleva a cabo un petición o query a los esquemas implementando herencia. En los casos de manejo de tablas de tamaño considerable los retardos pueden llegar a ser tan notorios que generen fallos y errores en la gestión de los datos. Esta herencia consiste en la asignación automática de columnas y valores a tablas “hijas” para poder modelar de una mejor manera las relaciones de diferenciación entre entidades. El concepto de herencia en PostgreSQL es bastante prominente y permite implementarlo. Tanto es así que existe una extensión de la base de datos llamada TimeScale [ 46 ] que permite llevar a cabo la herencia de forma mucho más sencilla con la implementación de la entidad “hipertabla”. En el futuro se estudiará la migración del DWH a esta extensión mencionada para poder mejorar la cantidad de recursos empleada para atender a estas peticiones. En este caso,la herencia se ha implementado en la tabla d_calendar, donde se han creado tablas “hijas” mensuales que han heredado las columnas de la tabla de calendario definida en 67. Gracias a esto, cuando se lleve a cabo una consulta, PostgreSQL podrá acceder de una manera más rápida y sin requerir de tanto tiempo de procesamiento. 6.4. DWH: Propuestas para la mejora de la gestión de grandes volúmenes de datos Hasta ahora se ha mencionado alguna consideración que se ha tenido en cuenta para cumplir con la gestión de un gran volumen de datos, como la normalización, la herencia o la arquitectura en estrella o de copo de nieve. En esta sección se propondrán otras medidas que se tendrán en cuenta para mejorar el rendimiento de las consultas y mejorar el tiempo de respuesta del sistema. Pre-filtrado y calidad de datos La primera medida a tener en cuenta es la reducción del duplicado de información almacenada al máximo posible. Esto se está llevando a cabo mediante el pre-filtrado que se implementa en 84 CAPÍTULO 6. BASE DE DATOS PARA DE DATOS CONTEXTUALES Y DINÁMICOS: DATA WAREHOUSE Y KNOWLEDGE GRAPH las ETLs. Esto no evita que en dos ejecuciones diferentes que extraigan datos superpuestos a ejecuciones anteriores no almacenen información previamente guardada. Una solución a esto podría ser hacer una búsqueda previa a la inserción de los datos ya existentes dentro de la misma ETL, lo que podría llevar a aumentar considerablemente la duración de la ejecución del propio proceso, o modificar la arquitectura actual del DWH haciendo, por ejemplo, que el identificador del sensor y el instante en el que se ha tomado la medida sean claves primarias. Existen muchas otras modificaciones de la arquitectura que podrían ser estudiadas e implementadas, pero la más inmediata sería la que se acaba de explicar. Gestión automática de herencias Actualmente, en la definición de las diferentes bases de datos de cada uno de los pilotos se están implementando herencias con respecto a la variable temporal de las telemetrías. Esta definición se las herencias se lleva a cabo de forma manual, separando las entradas de la tabla de hecho por meses. Se han mencionado con anterioridad que estamos empleando una base de datos PostgreSQL. Pero una mejora en la gestión de un volumen elevado de datos sin necesidad de hacer un gran despliegue de medios en la migración sería el empleo de TimescaleDB. TimescaleDB [ 46 ] es una extensión de PostgreSQL diseñada específicamente para la gestión del almacenamiento de series de datos temporales. Añade una capa de abstracción sobre las tablas normales de PostgreSQL, facilitando la gestión de grandes conjuntos de datos temporales mediante la automatización de muchas de las tareas asociadas con el diseño, la inserción y la consulta de estos datos. Aunque se esté llevando a cabo la definición de las herencias de forma manual, esta extensión permite un proceso de definición y manejo mucho más simple y optimizado que lo implementado actualmente. Indexación La indexación permite mejorar el desempeño de la base de datos reduciendo el número de acciones que realiza, como por ejemplo, la cantidad de búsquedas en disco para completar una petición. En todo tipo de aplicaciones se busca la mayor inmediatez posible a la hora de satisfacer las peticiones obtenidas pero, en el caso de sistemas de big data es un punto mucho más crítico debido a la extensión que pueden alcanzar las tablas. La creación de índices permite reducir el número de consultas y, por tanto, de tiempo necesario para satisfacer la petición. En las situaciones donde no existen los índices, la tabla al completo es analizada en búsqueda de entradas que satisfagan las consultas realizadas, mientras que si se ha definido previamente un índice, el número de filas que se consultan se reduce 85 CAPÍTULO 6. BASE DE DATOS PARA DE DATOS CONTEXTUALES Y DINÁMICOS: DATA WAREHOUSE Y KNOWLEDGE GRAPH considerablemente. Los índices no requieren de ninguna actualización ni gestión posterior a su creación, el propio sistema de base de datos se encarga de actualizar automáticamente la información de las nuevas entradas [47]. Particionado de los datos y procesamiento distribuido y paralelo La utilización de frameworks y aplicaciones que permiten la gestión de bases de datos distribuidas en diferentes máquinas. El empleo de estas utilidades puede ser tanto por aumento del tiempo de respuesta como por seguridad en el almacenamiento de los datos. Existen frameworks altamente depurados, como Apache Hadoop [ 48 ], que permite la gestión y el procesamiento de grandes volúmenes de datos a través de diferentes clusters, así como un escalado horizontal automático para adaptarse de forma dinámica a las necesidades del sistema. Hadoop también tiene flexibilidad en cuanto al tipo de datos que almacena, permitiendo los estructurados, semi-estructurados y no estructurados. Las características a destacar a mayores de lo que se ha mencionado son la capacidad del procesamiento de los datos en paralelo a través de los diferentes clusters, un negociador de recursos que permite asignar y despachar las tareas de una forma optimizada. Tiene resistencia a fallos gracias a copas de los datos que le permiten recuperación de la información entre los diferentes clusters. Actualmente, su empleo está muy extendido en sistemas de compañías tan grandes como Meta oGoogle, por lo que podemos suponer que la aportación respecto a la gestión de big data es considerable y fácilmente implementable en DigiBUILD Cubos OLAP Mondrian de Pentaho Pentaho implementa una herramienta de código abierto conocida como OLAP (Online Analytic Processing) Mondrian [ 49 ]. Se emplea principalmente para la creación de entidades conocidas como cubos OLAP, que son estructuras de datos multidimensionales que permiten el almacenamiento de grandes volúmenes de datos y la aplicación eficiente de métricas agregadas. Gracias a la definición de estos cubos se pueden llevar a cabo análisis interactivos complejos que pueden definirse de forma gráfica sobre los datos que contengan. Además, permiten llevar a cabo operaciones como filtrados, agrupaciones, drill-down y resúmenes con el fin de permitirnos obtener la información más relevante de los datos en cada caso. Los cubos OLAP están diseñados para proporcionar un rendimiento óptimo en consultas analíticas complejas, incluso sobre grandes volúmenes de datos. Esto es idóneo para un sistema de almacenamiento que requiera de gestión big data. Esta optimización la consigue gracias a 86 CAPÍTULO 6. BASE DE DATOS PARA DE DATOS CONTEXTUALES Y DINÁMICOS: DATA WAREHOUSE Y KNOWLEDGE GRAPH pre-procesado de los datos, compresión de los datos y optimización automática de las consultas. Finalmente, cabe mencionar que cuenta con la integración de herramientas de BI, como la creación de informes y dashboards que incluyen cálculos de métricas avanzadas. 6.5. Metadatos y su sincronización En el contexto de DigiBUILD, los metadatos juegan un papel crucial en la gestión y utilización eficiente de los datos relacionados con la digitalización de edificios. Los metadatos proporcionan información esencial sobre los datos dinámicos recopilados, permitiendo una mejor comprensión, organización, seguimiento y búsqueda de los mismos. Estos incluyen detalles como la fuente de los datos, el tipo de datos, las condiciones bajo las cuales se recopilaron, y cualquier otra información relevante que describa el contexto y las características de los mismos. En proyectos big data como en el que se desarrolla este TFM, donde la integración y el análisis de datos de múltiples fuentes y formatos son fundamentales para lograr los objetivos del proyecto, los metadatos son la piedra angular. 6.5.1. Elementos del data lake En el data lake que se genera en DigiBUILD se manejan cantidades de datos dinámicos muy altas, como se ha expuesto en el capítulo 4. Es por eso que la unión de estos datos dinámicos con los metadatos debe llevarse a cabo de forma cuidado. Para ello, en este proyecto se ha propuesto la definición de estructuras de datos comunes que permitan este unión. El data lake definido previamente a este trabajo por componentes ajenos al TFM se compone de varios bloques principales, cada uno con funciones específicas. La arquitectura se divide en tres componentes de Data Warehouse y dos componentes de Knowledge Graph: Servicios de Catálogo de Datos: Es la interfaz del data lake con otras aplicaciones aguas arriba del sistema. Esta interfaz facilita el acceso y la gestión a los datos. Base de Datos de Series Temporales: En este componente se alojan los datos que se extraen de las ETLs y de bases de datos de históricos. En el podemos almacenar además datos en tiempo real y es uno de los componentes más críticos del data lake. Almacén de Data Marts: Es un almacén que contiene estructuras conocidas como Data Marts, que son combinaciones de datos estáticos y dinámicos que funcionan a modo de informes o reports facilitando el análisis y los servicios de BI. Graph DB: Almacena grafos semánticos en formato RDF o Resource Description Framework utilizando archivos de tríadas TTL o Turtle. Estos grafos nos permiten conectar los datos dinámicos del DWH con datos estáticos del almacenamiento de objetos usando tecnologías semánticas. 87 CAPÍTULO 6. BASE DE DATOS PARA DE DATOS CONTEXTUALES Y DINÁMICOS: DATA WAREHOUSE Y KNOWLEDGE GRAPH Almacenamiento de Objetos: Guarda información estática en forma de archivos de datos abiertos. Estos datos incluyen modelos de información de edificios, geometría y otros contextos estáticos relevantes para el análisis. 6.5.2. Mecanismos de sincronización En el núcleo de las estructuras del data lake, los datos dinámicos se vinculan a los datos estáticos mediante grafos semánticos. Estos grafos se forman siguiendo una ontología desarrollada en el proyecto DigiBUILD, la cual reutiliza conceptos de las ontologías REC yBrick. Las ontologías son marcos de trabajo que se emplean para definir estructuras de conocimiento que se utilizan para organizar y categorizar información, modelar relaciones conceptuales y mejorar la gestión del conocimiento. La ontología definida para DigiBUILD consta de cinco módulos: Módulo Central: Contiene tipos de datos esenciales que conectan los tipos de datos de los otros módulos. Módulo de Edificación: Incluye datos espaciales sobre los pilotos, sus sistemas de distribución y los activos que abarcan, en definitiva, la información espacial. Módulo Contextual: Contiene tipos de datos relacionados con agentes, vehículos y recursos externos. Módulo Cuantitativo: Comprende tipos de datos cuantitativos categorizados en grupos de energía, operación, confort, economía, desempeño y medio ambiente. Módulo Temporal: Incluye tipos de metadatos para datos de series temporales y sus relaciones semánticas con tipos de datos del módulo cuantitativo. Todos los enlaces semánticos se producen a través del módulo central y se ha establecido que cada fuente de datos dinámicos se representa mediante un objeto de clase “Punto” y se conecta con una “Referencia de Serie Temporal” a una entrada de la base de datos. 6.6. Interfaz para compartición de datos Como parte de la hipótesis de este trabajo, se ha explicado cómo se plantea un paradigma diferente en el diseño del sistema de DigiBUILD, opuesto a los sistemas desarrollados con anterioridad bajo el nombre de enfoque de silo. Este nuevo paradigma permitiría que los edificios inteligentes puedan gestionar sus datos y compartirlos con las partes interesadas de forma integral en el sistema de una forma más accesible y controlada para el público objetivo en cada caso de uso. 88 CAPÍTULO 6. BASE DE DATOS PARA DE DATOS CONTEXTUALES Y DINÁMICOS: DATA WAREHOUSE Y KNOWLEDGE GRAPH Anteriormente, se ha explicado que los diferentes pilotos que forman parte del consorcio se engloban dentro del big data. Estos datos se extraen, formatean y almacenan para hacer uso de ellos. Una vez almacenados, cada piloto tiene asociados unos servicios, los cuales hacen uso de dichos datos para ofrecer un valor añadido según su objetivo. Es en este punto donde nos enfocaremos en esta sección. En la arquitectura (capítulo 3) las funcionalidades que satisface el desarrollo de esta sección están asociadas al bloque APIs for Learning Services de la capa framework de servicio. Estas funcionalidades se construyen sobre los bloques funcionales del data lake, dado que hacen uso de los datos tanto estáticos como dinámicos que han sido previamente extraídos, tratados y almacenados, así como dotados de la sincronización necesaria para explotar la información que contienen. Estas capas superiores giran entorno a los gemelos digitales y los servicios de inteligencia artificial desarrollados. El desarrollo llevado a cabo correspondiente a esta sección de la memoria se trata de una interfaz o API para hacer uso de los diferentes servicios de inteligencia artificial. El desarrollo de estos servicios y los modelos asociados no forman parte de este TFM. Este acceso a los servicios se lleva a cabo mediante una API, como se ha mencionado. El desarrollo de esta interfaz se ha llevado a cabo en Python, utilizando la librería FastAPI. Esta interfaz se encuentra en fase de desarrollo todavía, por lo que los modelos y sus métricas se almacenan en local y las predicciones meteorológicas son muestras también en local. En el momento del despliegue de la interfaz, se almacenarán tanto los modelos como sus evaluaciones en una base de datos y las predicciones meteorológicas se obtendrán mediante una llamada a un servicio público externo, como el de Open Meteo, previamente mencionado. A continuación, se procede a la explicación de las diferentes funcionalidades que permite esta interfaz. 6.6.1. Endpoints En la API desarrollada podemos encontrar los siguientes endpoints o funciones que realiza la interfaz (Figura 68). En esta figura generada automáticamente por la librería de Python empleada, podemos ver en el título el nombre de dicha librería (FastAPI). A continuación, se observan dos categorías en las que hemos dividido los tres endpoints: Base Endpoints:Que se emplean para conocer información sobre los modelos disponibles. Model Inference:Que se emplea para poder utilizar los modelos de predicción energética. Para poder interactuar con la API podemos hacerlo a través de peticiones HTTP con los parámetros que cada uno de los endpoints requiere o bien hacerlo a través de la documentación que genera FastAPI. En las siguientes secciones se explicarán las funciones de cada uno de los endpoints indicando 89 Capítulo 7 Conclusiones En este último capítulo de la memoria se incluye una recopilación de las ideas y conclusiones a las que se ha llegado tras la realización del presente proyecto. La elaboración y el desarrollo de este trabajo de fin de máster ha supuesto una oportunidad de formación y/o profundización en los temas principales que toca. Los temas en los que se ha llevado a cabo investigación han sido muy diversos: formación en ingeniería y sistemas de energía para el conocimiento del entorno del proyecto, formación en los diferentes protocolos de acceso y de seguridad en las fuentes de datos, especialización en procesos y funcionalidades de tratamiento de datos en Python, formación sobre sistemas big data y el uso de PDI para la definición de las ETLs y los jobs asociados, formación sobre el despliegue y funcionamiento de Apache Kafka, investigación en definición de estructuras de bases de datos y técnicas de gestión big data en las mismas. Durante el proceso de las tareas que se han llevado a cabo, se ha interactuado con otras tareas de DigiBUILD que no se engloban este TFM, pero ha sido necesario y beneficioso para poder tomar decisiones sobre diferentes cuestiones. Comenzando por la base de nuestra hipótesis, hemos estado en contacto con los responsables técnicos de los pilotos y con los propios pilotos para conocer en primera mano el estado, la relevancia, la accesibilidad y los sistemas que guardan los diferentes datasets enumerados en los documentos de DigiBUILD para poder adecuar dichos sistemas o los procedimientos y protocolos de acceso a los recursos para poder utilizarlos en Petaho. Iniciados los procesos de conexión y extracción en las fuentes de datos, se han tenido que modificar los planes iniciales como migraciones de los sistemas de almacenamiento, actualización de protocolos o similares. En cada uno de los pilotos se han conformado los formatos de los identificadores de los sensores de forma diferente en cada instancia en función de la disponibilidad de información. En adición, se han analizado los casos de uso de cada uno de los pilotos para agrupar los servicios y definir un listado de topics para la exportación de datos aKafka de la forma más organizada y centralizada. Como consecuencia del desarrollo de este proyecto dentro de DigiBUILD, se han podido plasmar los desarrollos e ideas generadas durante la realización en dos contribuciones en dos importantes congresos internacionales sobre eficiencia energética y energías renovables. Uno de 96 CAPÍTULO 7. CONCLUSIONES estos congresos es SpliTech 1 . Es un congreso internacional donde se exponen los desarrollos más novedosos sobre tecnologías inteligentes y sostenibles. En concreto, se proponen soluciones en los campos del internet de las cosas, eficiencia energética, smart cities o salud inteligente. El otro congreso es el taller internacional del IEEE sobre la metrología (o el estudio científico de las mediciones) para entornos donde vivimos o MetroLivEnv 2 . En él se exponen los desarrollos más punteros en relación a los avances en metrología, incluyendo diseños en sistemas a lo largo de todo el ciclo de vida de los edificios, como por ejemplo, diagnósticos, sistemas de monitoreo IoT, gemelos digitales o calidad de aire entre otros. Las contribuciones se han desarrollado con los compañeros de la University College London, con los que CARTIF comparte el desarrollo de tareas relacionadas con las capas del sistema en las que se desarrolla este trabajo. Las referencias (pendientes de publicación) son las siguientes: J. L. Hernández, D. Arévalo, S. Martín, K. Katsigarakis, G. N. Lilis, D. Rovas, I. de Miguel, “Using Extraction, Transformation and Loading procedures for digitalisation of buildings”, 9th International Conference on Smart and Sustainable Technologies (SpliTech 2024), Split-Bol (Croacia), 25-28 de junio de 2024. J. L. Hernández, D. Arévalo, S. Martín, K. Katsigarakis, G. N. Lilis, D. Rovas, I. de Miguel, “Connection of dynamic and static data: A data lake for building digitalisation”, 2024 IEEE International Workshop on Metrology for Living Environment (IEEE MetroLivEnv 2024), Chania, Creta (Grecia), 12-14 de junio de 2024. 1https://splitech.org/ 2https://www.metrolivenv.org/ 97 CAPÍTULO 7. CONCLUSIONES 98 Glosario API Application Programming Interface | Interfaz de Programación de la Aplicación. 3, 4, 6, 8, 10, 15, 18, 19, 28–34, 36, 37, 42, 44–46, 50–52, 55–57, 63, 64, 71, 72, 89, 90, 93, 94 BBDD Databases | Bases de Datos. 36 BEM Building Energy Model | Model Energético del Edificio. 44 BEMS Building Energy Management System | Sistema de Gestión de Energía para Edificios. 18, 20, 40, 59 BI Business Intelligence | Inteligencia de Negocio. 9, 87 BIM Building Information Model | Modelo de Información del Edificio. 44 BMS Building Monitoring Systems | Sistemas de Monitoreo de Edificio. 18, 23, 25, 49 CINEA European Climate, Infrastructure and Environment Executive Agency | Agencia Ejecutiva del Clima, Infraestructura y Medioambiente Europea. 1 CKAN Comprehensive Knowledge Archive Network | Red de Archivos de Conocimiento Integral. 14 CSV Comma Separated Values | Valores Separados por Comas. 18, 19, 36, 37, 40, 41, 44, 49, 52, 59, 60 DBL Digital Building Logbook | Registro Digital del Edificio. 36 DEMS District Energy Managment System | Sistema de Gestión de Energía para Distritos. 18, 20, 40 DigiBUILD High-Quality Data-Driven Services for a Digital Built Environment towards a Climate-Neutral Building Stock | Servicios Basados en Datos de Alta Calidad para Entorno Digital Construido hacia un Conjunto de Edificios Respetuosos con el Medioambiente. I , 1–5, 8, 9, 11, 13, 14, 23, 44, 49, 59, 75, 77, 79, 82, 86–88, 96 DL Deep Learning | Aprendizaje Profundo. 11 DWH Data Warehouse | Almacén de Datos. 3, 4, 7, 19, 20, 25, 30, 31, 33, 34, 37, 41, 42, 46, 47, 50–52, 57, 60, 61, 63, 64, 68, 72, 75, 77–79, 84, 85, 87 99 Glosario EC European Comission | Comisión Europea. 1, 14 EMS Energy Monitoring Systems | Sistemas de Monitoreo de Energía. 18, 23 EPC Energy Performance Certificate | Certificado de Eficiencia Energética. 36 ETL Extraction, transformation and Load | Extracción, transformación y carga. 6, 7, 9, 17, 19–24, 41, 47, 53, 56, 60–63, 68, 69, 71–73, 76–80, 82, 85, 87, 96 EV Electrical Vehicle Charge | Carga de Vehículo Eléctrico. 18, 21, 44 FTP File Transfer Protocol | Protocolo de Transferencia de Ficheros. 41, 59, 60 GUI Graphical User Interface | Interfaz Gráfica de Usuario. 8 HTTP HyperText Transfer Protocol | Protocolo de Transferencia de HiperTexto. 19, 29, 36, 45, 46, 50, 55, 72, 89, 90 IA Artifitial Intelligence | Inteligencia Artificial. 2, 3, 8, 11, 15 IAQ Indoor Air QUality | Calidad de Aire Interior. 44 IDS-RAM International Data Spaces-Reference Architecture Model | Modelo de Arquitectura de Referencia-Espacios de Datos Internacionales. 13 IDSA International Data Spaces Association | Asociación Internacional de Espacios de Datos. 13 IEEE Institute of Electrical and Electronics Engineers | Instituto de Ingenieros Eléctricos y Electrónicos. 97 IoT Internet of the Things | Internet de las Cosas. 5, 14, 97 JSON JavaScript Object Notation | Notación de Objeto JavaScript. 18, 19, 24, 25, 30, 33, 37, 42, 46, 50, 51, 56, 64, 72, 90, 92, 94 KPI Key Performance Indicator | Indicador Clave de Rendimiento. 23 MAC Media Access Control | Control de Acceso al Medio. 38 MAE Mean Absolute Error | Error Absoluto Medio. 94 ML Machine Learning | Aprendizaje Automático. 11, 62, 78 MQTT Message Queuing Telemetry Transport | Transporte de Mensajes Encolados de Telemetría. 18, 19, 23, 24, 44, 49–51, 62–64 MSE Mean Squared Error | Error Cuadrático Medio. 94 OLAP Online Analytical Processing | Procesado Analítico Online. 9, 86 100 Glosario PDI Pentaho Data Integration. 9 PV Photovoltaic Generation | Generación Fotovoltaica. 18, 21, 44 RDF Resource Description Framework | Marco de Descripción de Recursos. 87 SFTP Safe File Transfer Protocol | Protocolo Seguro de Transferencia de Ficheros. 18, 19, 40, 41 SQL Structured Query Language | Lenguaje Estructurado de Peticiones. 19, 25, 30, 31, 36, 40, 41, 47, 50, 67, 68, 80 SSH Secure Shell | Shell Seguro. 19 STD Standard Deviation | Desviación Típica. 77, 78 TCP/IP Transmission Control Protocol/Internet Protocol | Protocolo de Control de la Transmisión/Protocolo de Internet. 16 TFM - | Trabajo de Fin de Máster. 1–6, 8, 11, 19, 77, 79, 87, 89, 96 TLS Tansport Layer Security | Seguridad de la Capa de Transporte. 36, 37 URL Uniform Resource Locator | Localizador Uniforme de Recursos. 30, 56, 63 101 Bibliografía [1] Comisión Europea, “High-Quality Data-Driven Services for a Digital Built Environment towards a Climate-Neutral Building Stock - Grant Agreement 101069658.” https://doi.org/10.3030/101069658, 17 junio 2022. Accedido: 27 de mayo de 2024. [2] Consorcio Proyecto DigiBUILD, “DigiBUILD - Página web.” https://digibuild-project.eu/, 2023. Accedido: 27 de mayo de 2024. [3] Agencia Ejecutiva del Clima, Infraestructura y Medioambiente Europea, Comisión Europea, “CINEA - Página web.” https://cinea.ec.europa.eu/index_en, noviembre de 2023. Accedido: 27 de mayo de 2024. [4] Comisión Europea, “Comisión Europea - Página web.” https://commission.europa.eu/index_en, noviembre de 2023. Accedido: 27 de mayo de 2024. [5] Agencia Ejecutiva del Clima, Infraestructura y Medioambiente Europea, “Programa de investigación “Energy Use (Horizon Europe)” - Página web.” https://cinea.ec.europa.eu/programmes/horizon-europe/energy-use-horizon-europe_en, noviembre de 2023. Accedido: 27 de mayo de 2024. [6] Joint Research Centre, “Bauhaus Initiative - Página web.” https://new-europeanbauhaus.europa.eu/about/about-initiative_en, julio de 2023. Accedido: 27 de mayo de 2024. [7] Consorcio DigiBUILD, Euroheat & Power, “Communication, dissemination, and capacitybuilding activities (progress and report plan),” Tech. Rep. D7.3, Euroheat & Power, noviembre 2023. [8] V. Mayer-Schönberger y K. Cukier, Big data : la revolución de los datos masivos. Turner Libros, junio 2013. [9] I. Lee, “Big Data: dimensions, evolution, impacts, and challenges,” Business Horizons, vol. 60, pp. 293–303, enero 2017. [10] Hitachi Vantara LLC, “Pentaho Data Integration - Página web.” https://www.hitachivantara.com/pentaho/pentaho-plus-platform.html. Accedido: 27 de mayo de 2024. 102 [11] Comité técnico ISO/IEC JTC 1, Modelo OSI TP: Estándar ACID (ISO/IEC 10026-1:1998), ch. 4. Organización de Estandarización Internacional - ISO, octubre 1998. Accessed: 27 May 2024. [12] Consorcio DigiBUILD, Ethnicon Metsovion Polytechnion, “DigiBUILD architecture towards an Energy Efficient Building Data Space,” Tech. Rep. D1.5, Ethnicon Metsovion Polytechnion, abril 2023. [13] International Data Spaces Association, “Reference Architecture Model,” Tech. Rep. IDSRAM 4.0, International Data Spaces Association, abril 2019. [14] GAIA-X, “GAIA-X - Framework,” Tech. Rep. 22.04, GAIA-X, abril 2022. [15] FIWARE Foundation, “FIWARE - Página web.” https://www.fiware.org/. Accedido: 27 de mayo de 2024. [16] Comisión Europea, “Modular Big Data Applications for Holistic Energy Services in Buildings - Grant Agreement 101000158.” https://doi.org/10.3030/101000158, 7 septiembre 2020. Accedido: 27 de mayo de 2024. [17] Consorcio MATRYCS, Comisión Europea, “MATRYCS - Página web.” https://matrycs.eu/. Accedido: 27 de mayo de 2024. [18] Comisión Europea, “BD4NRG: Big Data for Next Generation Energy - Grant Agreement 872613.” https://doi.org/10.3030/872613, 26 noviembre 2020. Accedido: 27 de mayo de 2024. [19] Consorcio BD4NRG, Comisión Europea, “BD4NRG - Página web.” https://www.bd4nrg.eu/. Accedido: 27 de mayo de 2024. [20] Comisión Europea, “Harmonised Building Information Speedway for Energy-Efficient Renovation - Grant Agreement 820553.” https://doi.org/10.3030/820553, 17 agosto 2018. Accedido: 27 de mayo de 2024. [21] Consorcio BIM-SPEED, Comisión Europea, “BIM-SPEED - Página web.” https://www.bim-speed.eu/en. Accedido: 27 de mayo de 2024. [22] Comisión Europea, “BIM2TWIN: Optimal Construction Management & Production Control - Grant Agreement 958398.” https://doi.org/10.3030/958398, 24 septiembre 2020. Accedido: 27 de mayo de 2024. [23] Consorcio BIM2TWIN, Comisión Europea, “BIM2TWIN - Página web.” https://bim2twin.eu/. Accedido: 27 de mayo de 2024. [24] Comisión Europea, “Buildings as a Service (Ecosystem) - Grant Agreement 288409.” https://cordis.europa.eu/project/id/288409/es, mayo 2012. Accedido: 27 de mayo de 2024. [25] Consorcio BaaS, Comisión Europea, “Proyecto BaaS - Página web.” https://www.baasproject.eu/. Accedido: 27 de mayo de 2024. 103 [26] Comisión Europea, “Smart Transition of EU cities towards a new concept of smart Life and Economy - Grant Agreement.” https://doi.org/10.3030/731297, 26 octubre 2016. Accedido: 27 de mayo de 2024. [27] Consorcio mySMARTLife, Comisisón Europea, “mySMARTLife - Página web.” https://www.mysmartlife.eu/mysmartlife/. Accedido: 27 de mayo de 2024. [28] Consorcio DigiBUILD, Fundación CARTIF, “Dynamic data ingestion and data quality methodologies,” Tech. Rep. D2.2, Fundación CARTIF, 11 2023. [29] MQTT Org., “MQTT: The Standard for IoT Messaging - Página web.” https://mqtt.org/, 2022. Accedido: 27 de mayo de 2024. [30] Comité Técnico ISO/IEC JTC 1/SC 22, “The JSON data interchange syntax,” Tech. Rep. ISO/IEC 21778:2017, Organización de Estandarización Internacional - ISO, noviembre 2017. [31] InfluxData, Inc., “InfluxDBv3 Real-time Analytic Platform - Página web.” https://www.influxdata.com/products/influxdb-overview/. Accedido: 27 de mayo de 2024. [32] Y. Shafranovich, “Common Format and MIME Type for Comma-Separated Values (CSV) Files.” RFC 4180, octubre 2005. [33] REBEX ˇ CR, “Estándares SFTP - Página web.” https://www.sftp.net/specification. Accedido: 27 de mayo de 2024. [34] Google LLC, “Google Workspace: Google Calendar API Documentation.” https://developers.google.com/calendar/api/guides/overview?hl=es-419, marzo 2024. Accedido: 27 de mayo de 2024. [35] Google LLC, “Google Workspace: Google Drive API Documentation.” https://developers.google.com/drive/api/guides/about-sdk?hl=es-419, marzo 2024. Accedido: 27 de mayo de 2024. [36] PostgreSQL Organization, “PostgreSQL - Página web.” https://www.postgresql.org/, 2024. Accedido: 27 de mayo de 2024. [37] Confluent, Inc., “Documentación Apache Kafka - Página web.” https://docs.confluent.io/kafka/overview.html. Accedido: 27 de mayo de 2024. [38] Conduktor, Inc., “Convención de nombres en topics de Kafka - Página web.” https://www.conduktor.io/kafka/kafka-topics-naming-convention/, 2024. Accedido: 27 de mayo de 2024. [39] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, y L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” Tech. Rep. RFC 2617, Network Working Group, junio 1999. [40] InfluxData, Inc., “InfluxDB Project - Repositorio de GitHub.” https://github.com/influxdata/influxdb, abril 2013. Accedido: 27 de mayo de 2024. 104 [41] L. L. Pipino, Y. W. Lee, y R. Y. Wang, “Data quality assessment,” Communications of the ACM, vol. 45, pp. 211–218, abril 2022. [42] C. J. Fox, A. Levitin, y T. C. Redman, “The notion of data and its quality dimensions,” Information Processing and Management, vol. 30, pp. 9–19, enero 1994. [43] F. Sidi, P. H. Shariat Panahy, L. S. Affendey, M. A. Jabar, H. Ibrahim, y A. Mustapha, “Data quality: A survey of data quality dimensions,” in 2012 International Conference on Information Retrieval & Knowledge Management, pp. 300–304, marzo 2012. [44] CARTIF, “Centro Tecnológico CARTIF - Página web.” https://www.cartif.es/. Accedido: 27 de mayo de 2024. [45] Microsoft Power BI, “Understand Star Schema and the importance for power BI.” https://learn.microsoft.com/en-us/power-bi/guidance/star-schema, frebrero 2023. Accedido: 27 de mayo de 2024. [46] Timescale, Inc., “ Timescale: PostgreSQL ++ for time series and events - Página web.” https://www.timescale.com/, 2024. Accedido: 27 de mayo de 2024. [47] PostgreSQL Organization, “PostgreSQL Documentation: Chapter 11. Indexes.” https://www.postgresql.org/docs/current/indexes.html. Accedido: 27 de mayo de 2024. [48] The Apache Software Foundation, “Apache Hadoop - Página web.” https://hadoop.apache.org/. Accedido: 27 de mayo de 2024. [49] Pentaho y J. Hyde, “Pentaho: Mondrian Documentation.” https://mondrian.pentaho.com/documentation/olap.php. Accedido: 27 de mayo de 2024. 105