CIUDAD ENERGÉTICAMENTE INTELIGENTE (CEI) Entregable E4CC%83o... · CIUDAD ENERGÉTICAMENTE INTELIGENTE (CEI) 4/33 Este documento está bajo una Licencia Creative Commons Atribución-NoComercial-SinDerivar

© 2016 Instituto Tecnológico de Informática 28 de enero de 2015

Diseño de la infraestructura TIC

CIUDAD ENERGÉTICAMENTE INTELIGENTE (CEI)

Entregable E4.1

CIUDAD ENERGÉTICAMENTE INTELIGENTE (CEI) 2/33

Resumen

CEI (Ciudad Energéticamente Inteligente) diseña y desarrolla un sistema global de gestión inteligente que comprende la gestión energética de edificio, micro-red y ciudad desde el nivel de campo hasta el nivel de usuario.

Este proyecto está financiado por el Instituto Valenciano de Competitividad Empresarial (IVACE) y por la Unión Europea a través del Fondo Europeo de Desarrollo Regional (FEDER), dentro del Programa de Ayudas dirigidas a centros tecnológicos de la Comunidad Valenciana.

El objetivo de este paquete de trabajo es el diseño y desarrollo del sistema TIC asociado a los sistemas de gestión energética desarrollados en el PT3. El sistema consistirá en una primera capa de adquisición de datos, cuyo objetivo es recibir datos energéticos, datos meteorológicos y otros datos relevantes desde los sistemas de gestión energética desplegados por la ciudad.

Una vez recogidos los datos, la arquitectura cuenta con dos capas para el análisis inteligente:

Un motor de correlación basado en reglas permitirá declarar eventos sobre un sub-conjunto de fuentes de datos concretos.

Un motor de análisis de datos genérico empleando técnicas de Big Data y análisis estadístico de datos, permitirá un análisis más profundo sobre una gran cantidad de fuentes de datos, teniendo en cuenta para ello también datos históricos.

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

El trabajo realizado en este sistema TIC se aborda en dos entregables del proyecto CEI: E4.1 y E4.2. El primero de ellos, que se corresponde con el presente documento, se centra en la descripción de la infraestructura TIC: arquitectura cloud, el sistema de captación de datos y el motor de correlación de datos basado en reglas. El segundo documento (3) explica el tratamiento y análisis de datos empleando técnicas estadísticas sobre la infraestructura Big Data, y técnicas basadas en reglas sobre el motor de correlación. Además, dicho documento describe los módulos encargados de la visualización.


Abstract

ICT infrastructure design

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

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

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

After data collection, the system implements two analysis modules:

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

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

In order to provide these ICT services, there will be a cloud computing scalable back-end. In addition, a web-based front-end will visualize both data and their analysis results.

This document describes the ICT infrastructure: cloud big data architecture, communications layer, and correlation engine. Future documents will focus on the data analytics based on big data and rule-based techniques; and on the visualization modules.


Este documento está bajo una Licencia Creative Commons Atribución-NoComercial-SinDerivar 4.0 Internacional. Se permite libremente copiar,

distribuir y comunicar públicamente esta obra siempre y cuando se reconozca la autoría y no se use para fines comerciales. No se puede alterar, transformar o generar una obra derivada a partir de esta obra. Los derechos de autor de todas las marcas, nombres comerciales, marcas registradas, logos e imágenes pertenecen a sus respectivos propietarios.

http://creativecommons.org/licenses/by-nc-nd/4.0/

http://creativecommons.org/licenses/by-nc-nd/4.0/


Tabla de contenidos

Resumen ................................................................................................................................................ 2

Abstract ................................................................................................................................................. 3

ICT infrastructure design ........................................................................................................................ 3

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

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

1.2. Objetivos del documento ............................................................................................................ 9

1.3. Estructura del documento ........................................................................................................... 9

2. Arquitectura ................................................................................................................................. 9

3. Sistema de captación de datos ................................................................................................... 12

3.1. Paradigmas y protocolos de comunicación ............................................................................... 12

3.1.1 Request/Response ........................................................................................................... 13

3.1.2 Publish/Subscribe ............................................................................................................. 13

3.2. Módulos de fuentes de datos con intercambio en tiempo real: Bróker .................................... 15

3.3. Módulos de fuentes de datos con almacenamiento en base de datos: Sincronizador.............. 16

3.4. Servicios externos integrables vía APIs: OpenData ................................................................... 18

3.4.1 CKAN................................................................................................................................. 18

3.4.2 Tráfico .............................................................................................................................. 21

3.4.3 Información meteorológica y emergencias ...................................................................... 22

4. Arquitectura cloud ...................................................................................................................... 23

4.1. Servicios de la plataforma ......................................................................................................... 25

4.1.1 Servicios de gestión del clúster ........................................................................................ 25

4.1.2 Servicios de procesamiento de datos ............................................................................... 25

4.1.3 Servicios de almacenamiento de datos ............................................................................ 26

4.1.4 Servicios de ingesta de datos ........................................................................................... 26

4.1.5 Servicios de seguridad ...................................................................................................... 27

4.2. Implementación ........................................................................................................................ 28

4.2.1 Topología de red .............................................................................................................. 29


4.2.2 Gestor del clúster y servicios ............................................................................................ 30

5. Motor de correlación de reglas ................................................................................................... 31

5.1. Arquitectura del módulo ........................................................................................................... 31

5.2. Motor de reglas ......................................................................................................................... 32

6. Conclusiones ............................................................................................................................... 33

7. Referencias bibliográficas ........................................................................................................... 33


Tabla de figuras

Figura 1: Arquitectura del módulo desarrollado por ITI en CEI. ..........................................................9 Figura 2. Arquitectura genérica de CEI. ....................................................................................................... 11 Figura 3. Sistema de captación de datos de CEI. ....................................................................................... 15 Figura 4. Diagrama de la arquitectura con MQTT. .................................................................................. 16 Figura 5. Arquitectura conexión con Centro de Control Energético Ambiental Inteligente . .. 17 Figura 6. Arquitectura lambda. ...................................................................................................................... 24 Figura 7. Servicios de la distribución Cloudera. ....................................................................................... 25 Figura 8. Seguridad en Cloudera Manager. ................................................................................................ 27 Figura 9. Resumen de servicios Cloudera. .................................................................................................. 28 Figura 10. Instancias y asignación de recursos virtuales. .................................................................... 29 Figura 11. Topología de la red. ....................................................................................................................... 29 Figura 12. Servicios instalados. ...................................................................................................................... 30 Figura 13. Características de los nodos instalados. ................................................................................ 30


1. Introducción

1.1. Descripción del proyecto

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

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

Nodos de consumo.

Nodos de generación y almacenamiento.

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

Nodos observables y controlables de la red de distribución de energía.

Servicios tecnológicos asociados.

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

Nivel de medida y actuación energética – ambiental.

Nivel de controladores automatizados de campo para mejora energética - ambiental.

Nivel de centro de control energético – ambiental.

Nivel de aplicaciones distribuidas orientadas a usuarios.

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

Esta herramienta de mantenimiento permitirá:

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

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


1.2. Objetivos del documento

El objetivo de este documento es la descripción de la infraestructura TIC desplegada por el ITI dentro del proyecto CEI. Sus principales elementos son la capa de captación de datos; la arquitectura cloud en la que se almacenan y sobre la que se realizan los análisis estadísticos; y el motor de correlación sobre el que se llevan a cabo el análisis basado en reglas.

1.3. Estructura del documento

El presente documento contextualiza en primer lugar la arquitectura del sistema TIC, para a continuación describir los módulos encargados de:

Captación de datos (sección 3)

Arquitectura cloud (sección 4)

Motor de correlación basado en reglas lógicas (sección 5)

2. Arquitectura

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

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

Servicios web (privados) (Sección 3).


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

Planificador (Sección 3).

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

Big Data (Sección 4).

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

Modelado de contexto (Entregable E4.2 (3)).

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

Gestión de alertas y actuaciones (Sección 5 y entregable E4.2 (3)).

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

Servicios web (open data) (Entregable E4.2 (3)).

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

Interfaz (web, móvil) (Entregable E4.2 (3)).

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

M2M.

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

Empresas externas autorizadas.

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


El sistema de modelado de contexto se ha diseñado como un middleware en el que la definición de la arquitectura permite la gestión de contenidos de distinta naturaleza. Para ello se diseña una estructura dividida en capas. En esta arquitectura modular se han definido los siguientes niveles: sensorización, gestión de contextos y API de aplicaciones. El middleware está diseñado para permitir gestionar contenidos asociados a estados o entornos adaptativos. El estado o contexto hace referencia a todo lo que envuelve a un punto o centro de interés, proporcionando nuevas fuentes de información e incrementando con ello las posibles funcionalidades a desarrollar. Para la correcta ejecución de este tipo de entornos es necesaria la definición de un modelo que permita adaptar el software conectado a las características en ejecución de cada instante facilitando con ello la entrega del contenido más adecuado. Así pues, al hablar de contextos debe hacerse hincapié en que el objetivo es el ofrecimiento de la información adecuada en función de las preferencias y de las condiciones de ejecución en un instante determinado; según el tipo de dispositivo, el entorno de ejecución, el tipo de aplicación, etc.

Figura 2. Arquitectura genérica de CEI.

Los contextos se obtienen a partir de la información que periódicamente se recogen por los dispositivos de sensorización.

En el presente documento se describe la infraestructura que da soporte a estas tareas. A saber, la capa de sensorización (sección 3) y parte de la capa de gestión de contexto que aparece en la Figura 2 (planificador en la sección 3, almacén de datos Big Data en la sección 4, y el generador de alertas en la sección 5). El módulo de mantenimiento se corresponde con las herramientas desarrolladas en el paquete de trabajo 6 del proyecto CEI, mientras que el resto de módulos del gestor de contexto se documentarán en el entregable E4.2 (3).


3. Sistema de captación de datos

El objetivo de este módulo del proyecto CEI es la comunicación entre el servidor TIC y el resto de subsistemas en los que despliegan los sensores. Los datos captados por los sensores son recogidos para su posterior análisis, almacenamiento y suministro a los usuarios.

En el presente módulo se cubren las especificaciones definidas en el entregable 2.1 (2) que se muestran en la Tabla 1.

Tabla 1. Especificaciones implementadas en el sistema de captación de datos.

Especificación Resumen

S3.1.1 Cada elemento con sistema abierto conocido por el resto de elementos

S3.2.1 Arquitectura de integración abierta

S4.2.1 Medidas de seguridad

S7.4.2 Fuentes externas

El sistema de captación de datos se basa en paradigmas de comunicación escalables (por ejemplo, publish/subscribe o REST) desplegados sobre una infraestructura de protocolos de comunicación heterogéneos.

En cuanto a los métodos de volcado de datos desde las diferentes fuentes, se plantean diferentes alternativas según el proveedor de la información. Algunos datos estarán almacenados en concentradores con bases de datos (por ejemplo, el Centro de Control Energético Ambiental Inteligente), mientras otros pasarán por el sistema en modo streaming para su procesado en tiempo real, según capacidad de almacenamiento y los requisitos establecidos en el PT2 (por ejemplo, los datos del sistema de iluminación). Cabe mencionar también la integración de servidores y agregadores de información externos a la plataforma (servicios de predicción meteorológica, tráfico, emergencias, etc.). Estos servicios externos deben ser estudiados individualmente puesto que cada proveedor puede implementar su propia API para conectar con su plataforma.

A continuación, se van a plantear los paradigmas de comunicación disponibles, como los bloques del sistema de captación de datos interactúan entre si y especificaciones para cada instanciación de la arquitectura de captación.

3.1. Paradigmas y protocolos de comunicación

Desde el punto de vista del interfaz entre las fuentes o módulos de captación de datos y la plataforma CEI central (en la nube), que recogerá toda la información mediante un módulo Planificador, se plantea el requisito de que dicho interfaz de comunicaciones se lleve a cabo sobre una conexión IP.


El Internet Protocol (IP) es el principal protocolo de comunicación en la suite de protocolos de Internet para transmitir datagramas a través de la red. Es el protocolo de red más utilizado y extendido (capa 3 de la pila de protocolo de comunicación OSI). IP se ejecuta en una amplia variedad de capas físicas y MAC, por lo que es independiente del medio, que van desde radios de baja potencia como 802.15.4, 802.11 (Wi-Fi), bajo tecnologías PLC a través de la red eléctrica, o de tecnologías radio de largo alcance tales como GPRS y 3G, o a alta velocidad por cable Ethernet. IP cuenta con cualidades destacadas como interoperabilidad, reutilización, escalabilidad, soporte, fragmentación, seguridad, calidad de servicio, y estandarización. Por tanto, la pila de protocolos de comunicaciones escogida por cada módulo debe tener soporte para este protocolo de red.

De acuerdo a los requerimientos presentados por cada caso de uso (Centro de Control Energético Ambiental Inteligente ITE, iluminación…), desde la perspectiva de las capas superiores de la pila de protocolos de comunicación, dos modelos de arquitecturas con sus patrones de intercambio de información correspondientes se encuentran en las soluciones propuestas:

3.1.1 Request/Response

Es un patrón de intercambio de mensajes en el que un dispositivo envía un mensaje de solicitud a un sistema que recibe y procesa la solicitud, en última instancia, devolviendo un mensaje de respuesta. Este patrón es especialmente común en las arquitecturas cliente-servidor. Este modelo se implementa normalmente en forma síncrona, como en las llamadas a servicios web a través de HTTP, que abre una conexión y espera hasta que la respuesta se entrega o el período de tiempo de espera expira. Sin embargo, request/response también puede implementarse de forma asíncrona, retrasando la respuesta otro momento posterior (cuando una información que no estaba disponible pasa a estarlo).

3.1.2 Publish/Subscribe

Es un patrón de intercambio de mensajes donde los nodos que producen información (publicador o emisor) publican sus muestras de datos en temas o “topics” (por ejemplo, la temperatura, la ubicación, la presión). Las muestras se envían a los suscriptores que declaran un interés en un tema determinado. Esta negociación se puede gestionar de forma distribuida entre los nodos, o centralizada en una entidad intermedia denominada “bróker”. Esta arquitectura de permite a los emisores y suscriptores el estar desacoplados, mejorando así la escalabilidad de la red, y se puede mejorar con tecnologías de nube (añadiendo elasticidad, equilibrio de carga y de seguridad). También permite la mejora de las operaciones asíncronas, tales como alarmas o actuaciones (un actuador que depende de una alarma activada por un sensor emisor es informado al instante cada vez que este sensor publica la alarma), y es aconsejable para un comportamiento en tiempo real.

Las propiedades de estas arquitecturas y patrones de intercambio de información correspondientes se muestran resumidos en las tablas a continuación.


Tabla 2. Arquitecturas de intercambio de datos.

Arquitectura orientada a

eventos Arquitectura orientada a servicios

Sincronicidad Asíncrona, basada en mensajes Típicamente síncrono, basada en

llamadas remotas

Acoplo Desacoplada Completamente acoplada

Orientado a Manejo de eventos Proveer funcionalidades

Uso Publish / Subscribe Request / Response

Interacción Comunicación horizontal entre

niveles

Comunicación vertical entre niveles

jerárquicos

Aplicación Tiempo real y cuasi-real.

Comunicaciones con

restricciones temporales.

Telemetría

Sistemas estáticos, operaciones

transaccionales (bases de datos),

control no-periódico

Tabla 3. Patrones de intercambio de información.

Publish/subscribe Resquest/response

Roles Emisores y suscriptores Clientes y servicios

Patrón de

intercambio

Intercambio de información iniciado

por un suscriptor, solicitando

información de un tema, producido

por un/varios editores.

El suscriptor debe especificar

explícitamente un identificador de

tema.

Intercambio de información iniciado

por el cliente solicitando respuesta de

un servicio específico.

El cliente debe especificar

explícitamente un servicio de una

dirección concreta.

Conexión Sin conexión entre emisor y

suscriptor

Orientado a la conexión entre

cliente/servidor

Uso Manejo de eventos, el paso de

mensajes, transmisión de datos

Control, consulta de datos/metadatos

Mapeo “One-to-many” y “many-to-many” “One-to-one” and “Many-to-one”

Desde el punto de vista de una arquitectura de alto nivel, y para poder ofrecer la integración del mayor número posible de fuentes de datos, se ha optado por implementar un Planificador con interfaz multi-protocolo como pasarela entre los módulos productores de datos (Gestores energéticos, redes de iluminación, servidores externos, etc.) y la plataforma CEI Cloud. Esto significa que, dependiendo de las necesidades de los módulos, pueden hacer uso de un interfaz tipo Request/response o de un Publish/subscribe, mediante el uso de herramientas abiertas y protocolos estandarizados. En la siguiente sección se instancian estas arquitecturas


propuestas para cada caso contemplado en el proyecto, con los protocolos seleccionados para su implementación. Básicamente, el módulo Planificador a la entrada de la plataforma Cloud y de modelado de contexto, contiene diversos “habilitadores” (enablers) para cada tipo de protocolo o API necesario (ver Figura 3).

Figura 3. Sistema de captación de datos de CEI.

3.2. Módulos de fuentes de datos con intercambio en tiempo real: Bróker

Como mecanismo para el intercambio de mensajes entre clientes del middleware (sistema de modelado de contexto, CEI Cloud) y los módulos de sensorización que no están recogidos en bases de datos, se ha optado en el diseño por seguir la filosofía publish/subscribe.

En este habilitador, cuando nos referimos a emisor se trata de un sensor o dispositivo determinado de la red de sensorización, o incluso a un agregador de sensores (si pasan por un concentrador, como por ejemplo en una arquitectura similar al Gestor energético de ITE, pero sin base de datos para persistencia). El bróker en este caso se encargará de recoger todos los temas publicados por dichos sensores, y pasarlos a los módulos internos de la plataforma Cloud: el suscriptor principal es la base de datos de la plataforma, que almacena todos los datos de las diferentes fuentes para su tratamiento y análisis. También puede alimentar directamente a suscriptores que precisen tiempo real, como motores de reglas.

Este tipo de intercambio de datos acarrea el problema del descubrimiento de servicios y recursos. Por lo tanto, ha de tenerse en cuenta en el diseño de este habilitador del Planificador que la información procedente de los sensores siga la misma estructura que en el resto de fuentes de datos, como los del Centro de Control Energético Ambiental Inteligente, o al menos que en dicho habilitador se lleve a cabo la traducción necesaria para insertar los datos de sensor en la base de datos con una semántica común que pueda ser interpretada inequívocamente por los módulos de análisis.


Por tanto, anexo al bróker de este habilitador, que recoge la información que los sensores

publican en tiempo real, se tendrá un suscriptor especial a todos los temas o tópicos que adaptará (en los casos necesarios) los datos recibidos al formato presente en base de datos de la plataforma Cloud, y mediante operaciones SQL los insertará en dicha base de datos.

Para el resto de suscriptores, si no conocen a priori los recursos (temas) disponibles en el bróker a los que suscribirse, debe contemplarse la opción de descubrir recursos, bien sea mediante un módulo anexo que contenga el catalogo disponible, o mediante la consulta de los dispositivos dados de alta en la base de datos. En cualquier caso, esta elección y la implementación de las funciones de descubrimiento de servicios y catalogo y suscripción a temas es responsabilidad de los módulos de tiempo real que quieran conectar con el bróker.

Figura 4. Diagrama de la arquitectura con MQTT.

Como propuesta de protocolo de publish/suscribe para implementar este habilitador, se escoge como candidato MQTT, cuyas especificaciones pueden encontrarse en (1). Se dispone de un bróker MQTT de código abierto desarrollado en php, y se pueden simular clientes publicadores mediante diversas herramientas de código abierto, contando con la posibilidad de añadir los clientes (tanto publicadores como suscriptores) que se requieran de forma virtual.

MQTT es un protocolo conocido por todos los elementos (especificación S3.1.1). Además, su capa de gestión soporta medidas de confiabilidad, seguridad (S4.2.1, como HTTPS sobre TLS), tiempo real, calidad de servicio, y autenticación de usuarios.

3.3. Módulos de fuentes de datos con almacenamiento en base de datos: Sincronizador

Para este caso, el intercambio de mensajes entre el middleware y las fuentes de datos se basa en el paradigma Request/response, enfocada a arquitecturas de tipo cliente/servidor.


Este módulo es responsable de gran parte de la sensorización y procesado de datos de la plataforma, ya que incluye el Gestor energético CEI desarrollado por ITE (Gestor de aquí en adelante). Internamente, en el módulo el Gestor está conectado a multitud de dispositivos como contadores, vía MODBUS o Ethernet (aunque podría soportar otros interfaces físicos en el futuro), que periódicamente mandan sus datos de sensorización a su base de datos. De este modo, se ofrecen interfaces para soportar los distintos tipos de integración posibles, con una interfaz de usuario que presenta la información de manera homogénea (especificación S3.2.1).

Externamente, debe volcar los datos de energía almacenados en dicho gestor en la plataforma Cloud para su tratamiento, correlación e integración con el resto de datos de la ciudad, mediante el módulo Planificador.

Figura 5. Arquitectura conexión con Centro de Control Energético Ambiental Inteligente .

Para ello, un habilitador denominado Sincronizador, presente en el módulo Planificador, se encargará de abrir periódicamente una conexión remota con la base de datos SQL presente en el Gestor. Tras esto realizará las pertinentes consultas, que en este caso pueden reducirse a un volcado completo de todos los datos nuevos (solo los almacenados desde la última consulta) presentes en la base de datos. Tras esto, mediante otras operaciones SQL insertará los datos recibidos en la capa de persistencia de la CEI Cloud y cerrará la conexión, liberando así recursos. Este comportamiento puede realizarse estáticamente, programando consultas periódicas varias veces al día. Puede configurarse coincidente con el periodo de actualización del Gestor, es decir, conociendo a priori que se tendrán actualización de información de los contadores y analizadores eléctricos conectados al Gestor cada 15 minutos, se programarán las consultas a esta base de datos para actuar en consecuencia.

Otra aproximación proactiva contempla el envío de un mensaje de notificación desde el Gestor hacia la plataforma, indicando que está disponible una actualización de los datos. De esta forma, el Planificador solo intentará la consulta cuando exista información relevante, evitando conexiones innecesarias por ejemplo si los sensores han caído durante periodos de tiempo superiores al muestreo establecido, o si se implementan cambios en este muestreo (a mayor o menor frecuencia de muestreo) en el lado del Gestor.


En este caso se utiliza la nomenclatura Sincronizador puesto que este habilitador sencillamente se encarga de realizar respaldos de unas bases de datos locales, de menor tamaño y aisladas de otros sistemas de la plataforma, y añadir todos los respaldos de estas bases de datos para recopilar toda la información histórica en la plataforma central.

3.4. Servicios externos integrables vía APIs: OpenData

3.4.1 CKAN

CKAN, desarrollado por la organización no lucrativa “Open Knowledge Foundation”, es un sistema de gestión de datos que proporciona herramientas para agilizar la publicación, compartición, búsqueda y en general el uso de datos. Está dirigido a editores de datos (gobiernos, empresas…) que necesitan o desean crear un acceso abierto a sus datos.

Se emplea para mejorar o crear portales de datos oficiales, públicos o colaborativos. En estos portales los usuarios pueden descargar conjunto de datos en distintos formatos, además de visualizarlo de diferentes formas (tablas, gráficas, mapas…etc).

En el caso del proyecto CEI, CKAN resulta de interés en dos frentes: para la adquisición de datos de fuentes externas que complementen la información disponible en la plataforma, para su incorporación a los modelados de contexto, análisis de datos, etc., y por otro lado para la publicación de datos abiertos como servicio añadido.

Para la capa de adquisición de datos, encontramos una fuente de datos con gran cantidad de información, como es el Ayuntamiento de Valencia (plataforma VLCi - http://gobiernoabierto.valencia.es/es/data/ ), que permite la descarga de diversos conjuntos de datos mediante CKAN. Por lo tanto, tras identificar los datos que puedan resultar de interés para CEI, se pueden incorporar mediante el API público de CKAN y volcarlos en la base de datos propia para su procesado. Se muestra una captura de conjuntos de datos disponibles en el CKAN VLCi, así como usar este API REST de CKAN para descargar datos:

Llamada a catálogo de recursos disponibles (mediante http sobre método GET): http://apigobiernoabiertocatalog.valencia.es/api/3/action/package_list

Devuelve el resultado en formato JSON (contenido recortado del original, la lista completa se puede consultar en el enlace anterior):

{ "help": "http://apigobiernoabiertocatalog.valencia.es/api/3/action/help_show?name=package_list", "success": true, "result": [ "ambito-territorial-de-los-servicios-sociales", "aparcabicis", "aparcamiento-movilidad-reducida", "aparcamiento-para-motos", "aparcamientos-no-regulados",

http://gobiernoabierto.valencia.es/es/data/

http://apigobiernoabiertocatalog.valencia.es/api/3/action/package_list


"aparcamientos-ora", "aparcamientos-vehiculos", "arbolado", "arbolado-monumental", "barrios", "camaras-trafico", "carril-bici", "catalogo-datos-abiertos", "contenedores-aceite-usado", "contenedores-residuos-solidos", "datos-basicos-equipamientos-municipales", "datos-contaminacion-atmosferica-avda-francia-6a", "datos-diarios-ultimo-mes-estaciones-ruido", "distritos", "estado-trafico-tiempo-real", "expendedores-ora", "fuentes-agua-publica", "recarga-vehiculos-electricos", "reguladores-grupos-semaforicos", "relacion-bienes-inmuebles", "relacion-derechos-reales", "relacion-puntos-medidas-camaras-trafico", "relojes-termometro", "secciones-censales", "semaforos", "sentidos-circulacion", "zonas-carga-descarga" ] } Mediante una extracción sencilla de este JSON escogemos del campo “result” el conjunto de datos que se pretende descargar. Por ejemplo, “recarga-vehiculos-electricos”. Con este resultado, se hace otra llamada al API REST mediante: http://apigobiernoabiertocatalog.valencia.es/api/3/action/package_show?id=recarga-vehiculos-electricos De forma similar al anterior, este servicio web devuelve información en formato JSON (se muestra fragmento): { "help": "http://apigobiernoabiertocatalog.valencia.es/api/3/action/help_show?name=package_show", "success": true, "result": { "conformsTo": "", "hasBeginning": "", "license_title": "Atribuci\u00f3n 4.0 Internacional (CC BY 4.0)",

http://apigobiernoabiertocatalog.valencia.es/api/3/action/package_show?id=recarga-vehiculos-electricos

http://apigobiernoabiertocatalog.valencia.es/api/3/action/package_show?id=recarga-vehiculos-electricos


"last_updated": "01/12/2013", "version": "", "relationships_as_object": [ ], "private": false, "maintainer_email": "", "num_tags": 0, "references": "", "hasEnd": "", "maintainer": "", "id": "aacf1062-7ca0-4b36-85a2-d61ad537ff09", "metadata_created": "2014-10-28T09:05:31.036717", "metadata_modified": "2015-05-25T10:30:07.631518", "author": "Ayuntamiento de Valencia", "author_email": "[email protected]", "state": "active", "valid": "", "creator_user_id": "fb60b3c1-6708-4400-b8c9-5090d5bf4c93", "type": "dataset", "resources": [ { "cache_last_updated": null, "package_id": "aacf1062-7ca0-4b36-85a2-d61ad537ff09", "webstore_last_updated": null, "id": "7447ecf4-46da-49b2-b4ba-9f636361ef43", "size": null, "name_va": "Recarrega vehicles el\u00e8ctrics", "state": "active", "hash": "", "description": "Puntos de recarga el\u00e9ctrica de veh\u00edculos.", "format": "GeoJSON", "last_modified": null, "description_va": "Punts de recarrega el\u00e8ctrica de vehicles.", "url_type": null, "mimetype": null, "cache_url": null, "name": "Recarga veh\u00edculos el\u00e9ctricos", "created": "2014-10-28T10:07:54.675041", "url": "http://mapas.valencia.es/lanzadera/opendata/Tra_recarga_electrica/JSON", "webstore_url": null, "mimetype_inner": null, "position": 2, "revision_id": "0b3b773b-6bd8-467c-b4ee-3ff57be98207", "resource_type": null } }


En el JSON anterior se listan todos los formatos disponibles del dataset escogido. Siguiendo con el formato JSON, que proporciona facilidad de procesado e inteligibilidad, se escoge descargar los datos en este formato capturando el recurso “url”. Este dato será la entrada del último paso del proceso del API REST CKAN. Al acceder a esta dirección se descargará un fichero JSON con el siguiente contenido (se muestra fragmento), que puede ser procesado (seleccionando solo los campos de interés) directamente para volcarlo a una base de datos: { "type": "FeatureCollection", "crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:OGC:1.3:CRS84" } }, "features": [ { "type": "Feature", "properties": { "descripcion": "Aparcamiento Hospital-Vinatea" }, "geometry": { "type": "Point", "coordinates": [ -0.379856225068894, 39.47120176630294 ] } } ] }

3.4.2 Tráfico

Puede resultar de interés como fuente de información para los algoritmos de optimización para mantenimiento (cálculo de rutas de los técnicos de mantenimiento). La principal fuente de datos sobre el estado del tráfico en las carreteras y del estado de las infraestructuras viarias de la red nacional de carreteras es la Dirección General de Tráfico. No obstante, son datos solo de carreteras extra-urbanas por lo que no resultan de interés en esta aplicación. La opción más atractiva siguiendo este modelo de integración de datos de DGT y usuarios es la ofrecida por Google Maps y sus capas de información sobre mapas, ya que muestran información en tiempo real sobre tráfico e incidencias no solo en carreteras sino también en áreas metropolitanas, agregando varias fuentes de datos como los de la DGT y los de la red social WAZE. Además, Google Maps cuenta con una API totalmente abierta a desarrolladores (gratuita para aplicaciones abiertas y mediante licencias para aplicaciones comerciales) y es fácilmente integrable en cualquier aplicación.


Tabla 4. API de Google Maps con información de tráfico.

Funciones API de Google Maps API de Google Maps for Business

Street View

Servicio web de codificación

geográfica

2.500 solicitudes diarias 100.000 solicitudes diarias

Servicio web de rutas 2.500 solicitudes diarias con

10 hitos por solicitud

100.000 solicitudes diarias con

23 hitos por solicitud

Servicio web de matriz de

distancia

100 elementos por consulta

100 elementos cada 10 segundos

2.500 elementos diarios

625 elementos por consulta

1.000 elementos cada 10 segundos

100.000 elementos diarios

Servicio web de elevación 2.500 solicitudes diarias con

25.000 muestras diarias

100.000 solicitudes diarias con

1.000.000 muestras diarias

Resolución máxima del API de

Google Static Maps

640 x 640 2.048 x 2.048

Escala máxima del API de

Google Static Maps

2X 4X

Resolución máxima del API de

imágenes de Street View

640 x 640 2.048 x 2.048

3.4.3 Información meteorológica y emergencias

La integración de servicios de previsión meteorológica sigue un patrón similar a la información de tráfico. En este caso, la fuente de datos principal recomendada es la Agencia Estatal de Meteorología, AEMET.

El API de AEMET está disponible de forma gratuita mediante registro en su página web, y aceptación de los términos de uso. Tras ello se puede acceder a un área de usuario donde se pueden configurar los parámetros incluidos en el fichero XML a descargar, por ejemplo, el área o zona específica, población, o territorio nacional al completo. Tras esto se consigue un enlace al fichero con los datos deseados. Las consultas mediante a este API son configurables, y con una sencilla llamada a un servicio web se puede obtener la información necesaria para la plataforma CEI. Se muestra un ejemplo de consulta:

<report>

<location city="Valencia [Valencia;Espana]">

<interesting>


<url

description="prediccion">http://www.tiempo.com/valencia.htm

</url>

</interesting>

<day name="Jueves" value="20151119">

<symbol value="6" desc="Cielos nubosos"/>

<tempmin value="9"/>

<tempmax value="19"/>

<hour value="01:00">

<temp value="9"/>

<symbol value="3" desc="Cielos Nubosos"/>

</hour>


<temp value="8"/>

<symbol value="3" desc="Cielos Nubosos"/>

</hour>


<temp value="8"/>

<symbol value="4" desc="Cielos Cubiertos"/>

</hour>


<temp value="9"/>


</hour>


<temp value="10"/>


</hour>

</day>

</location>

</report>

4. Arquitectura cloud

Los sensores desplegados en la ciudad generarán una gran cantidad de datos heterogéneos de manera continua, que deben ser recibidos y procesados por el sistema. Así pues, se ha optado por el uso de una arquitectura basada en principios Big Data. De esta manera, se asegura la escalabilidad, el procesamiento de grandes cantidades de datos y el análisis de nuevos datos en tiempo reducido. Esta sección se centra en la descripción de dicha infraestructura, sobre la que se almacenarán y analizarán los datos, tal y como se documentará en el entregable E4.2 (3).

En el presente módulo se cubren las siguientes especificaciones definidas en el entregable E2.1 (2):

Tabla 5. Especificaciones implementadas en la arquitectura big data.


S4.2.1 Servidor con sistema operativo seguro

S5.3 Tratamiento de grandes cantidades de datos


S5.4 Redundancia de datos

S6 Centro de control

S6.1.1 Computación en la nube

S6.5.1 Sistemas distribuidos

S7 Análisis en el servidor

La arquitectura elegida para proporcionar capacidad de cómputo distribuida sigue el patrón lambda descrita en la siguiente figura. Este patrón proporciona una solución al acceso a datos masivos en tiempos razonables apoyándose en tres capas con funciones concretas que cito a continuación:

Figura 6. Arquitectura lambda.

La Capa Batch almacena todo el Dataset (conjunto de datos crudos disponibles para ser procesados y analizados) y pre computa una serie de vistas, almacenadas normalmente en una base de datos de sólo lectura. Estas vistas generadas a partir de todo el Dataset suelen están normalizadas y se les ha aplicado un proceso de cleanup para que no contengan datos anómalos. De este modo simplificamos el acceso a los datos para otras capas.

La Capa de Velocidad da servicio a datos en tiempo real. Se sacrifica la consistencia de la capa Batch a fin de proporcionar acceso a los datos con una latencia mínima. La información es procesada en ventanas temporales sobre las que se efectúa un proceso en Batch pero ajustado a la ventana temporal.


La Capa Servicio proporciona el acceso a los datos de las capas anteriores, se podrán consultar los datos procesados por la capa Batch o acceder a los flujos de datos en tiempo real.

Para la implementación de esta arquitectura, hemos seleccionado la solución para Big data de Cloudera, que es una distribución de Apache Hadoop que incluye una pila de servicios con la que implementamos la arquitectura lambda. En el siguiente diagrama se muestran los distintos servicios que se incluyen en la distribución.

Figura 7. Servicios de la distribución Cloudera.

4.1. Servicios de la plataforma

La plataforma Cloudera proporciona una serie de servicios instalables bajo demanda que proporcionan funcionalidades para diferentes tareas que se detallan a continuación. Dichas tareas permiten la ingesta de datos desde fuentes externas, la exportación de los datos procesados, servicios de procesamiento de datos distribuidos, librerías de machine learning, almacenamiento de ficheros de forma distribuida, servicios de gestión del clúster, etc.

4.1.1 Servicios de gestión del clúster

La administración y gestión del clúster se realiza mediante el servicio Cloudera manager. Este componente permite añadir dinámicamente nodos al clúster y la instalación de servicios sobre el mismo. Cloudera es un software de gestión de clúster de computadoras (nodos) basados en tecnología Hadoop que provee de un ecosistema de componentes de código abierto innovadora en el almacenamiento, procesamiento y análisis de los datos.

La gestión de recursos del clúster es gestionada por el servicio YARN. Establece pools de CPU y memoria que se asignan por usuarios o grupos para la ejecución de trabajos en el clúster. Esta forma común de acceso a los recursos del sistema se comparte con otros servicios, permitiendo de este modo una mayor interoperabilidad.

4.1.2 Servicios de procesamiento de datos

Para el procesado de la información en modo distribuido y en modo Batch empleamos el servicio HADOOP. Este servicio se encarga de proporcionar un API de programación JAVA


distribuida basado en el paradigma Map/Reduce. Permite el procesado de los fragmentos de información distribuida en Batch sobre HDFS aprovechando el principio de localidad. Así, cada nodo procesa la información localizada en sí mismo, reduciendo de este modo el tráfico de red que constituye un cuello de botella de otros sistemas de procesado distribuido.

Para el procesado de la información en modo distribuido y en memoria utilizamos el servicio SPARK. Consta de varios APIs con los que podemos cargar y manipular datos y procesarlos con una serie de librerías para machine learning. Apache Spark es un framework de código abierto para el procesado de datos masivos desarrollado en torno a la velocidad, facilidad de uso y análisis sofisticados.

4.1.3 Servicios de almacenamiento de datos

El servicio HDFS proporciona la capa de persistencia distribuida que da soporte al resto de servicios. Cada fichero que se añade al clúster es repartido por los distintos nodos con un factor de replicación predefinido (normalmente de tres partes). Esta distribución replicada de la información proporciona tolerancia a fallos, ya que en caso de que un fragmento de información se corrompa, de forma transparente es reparado con los fragmentos replicados. Ha sido desarrollado específicamente para el procesamiento de datos a gran escala, donde la escalabilidad, flexibilidad y rendimiento son críticos. HDFS acepta datos en cualquier formato, independientemente del esquema. Está optimizado para el procesado de flujos de datos de gran tamaño, siendo capaz de gestionar inmensas cantidades de datos (las escalas de las implementaciones probadas llegan a más de 100PB).

Para el almacenamiento distribuido de tablas disponemos del servicio Hive, que es un Dataware House distribuido que permite el acceso a la información mediante queries SQL estándar. Internamente, estas consultas se transforman en procesos distribuidos que obtienen los datos pedidos. Se trata de una infraestructura de almacenamiento de datos construida sobre Hadoop para proporcionar agregación de datos, consulta y análisis. Finalmente, proporciona un lenguaje similar a SQL llamado HiveQL con metadatos que transforma de forma transparente las consultas a procesos map/reduce.

4.1.4 Servicios de ingesta de datos

Para la ingesta de datos de tipo relacional (Bases de datos SQL) al clúster utilizamos el servicio SQOOP, que permite la importación de tablas a HDFS o Hive en paralelo. Sqoop es una aplicación con interfaz de línea de comandos para la transferencia de datos entre bases de datos relacionales y Hadoop (HDFS, Hive, etc.). Es compatible con cargas incrementales de una sola tabla o una forma libre vía consultas SQL, así como trabajos guardados que se pueden ejecutar varias veces para importar actualizaciones realizadas en una base de datos desde la última importación.

Para la ingesta de datos de tipo fichero de log al clúster empleamos el servicio Flume, que permite la importación de los mismos a HDFS o Hive en paralelo. Apache Flume proporciona un API mediante el cual se puede definir una serie de agentes (programas residentes en una máquina cliente) que se encargan de monitorizar uno o varios ficheros de log. En caso de haber cambios, se envían los mismos al clúster, centralizando ficheros de log procedentes de varios sistemas en un mismo punto para su posterior análisis.


4.1.5 Servicios de seguridad

Para cubrir los requisitos de seguridad, Cloudera manager permite el uso de seguridad básica de autenticación mediante el módulo PAM de Linux y, adicionalmente, la integración con sistemas de seguridad de uso extendido como Kerberos y LDAP, ambos integrados en el servicio de Directorio Activo.

De este modo se configuran los servicios del clúster para que sólo acepten ejecución de procesos autenticados con un ticket Kerberos, permitiendo únicamente a los usuarios debidamente autenticados el acceso a los datos y funcionalidades de la plataforma Big Data.

La siguiente imagen muestra las pantallas de Cloudera manager para la configuración de la seguridad del clúster.

Figura 8. Seguridad en Cloudera Manager.

A modo de resumen, la siguiente figura muestra los servicios de la plataforma Cloudera agrupados por roles: procesado Batch, analítica sql, servicios de búsqueda, machine learning, procesado en tiempo real y terceros. Todos ellos se ejecutan sobre Yarn, el gestor de recursos, que a su vez permite el acceso a los recursos del clúster (CPU, RAM, HDFS, Dataware House, etc.).


Figura 9. Resumen de servicios Cloudera.

4.2. Implementación

Para la implementación de la arquitectura lambda propuesta, se ha optado por aprovisionar los nodos del clúster sobre una infraestructura disponible en OpenStack. Sobre dicho clúster se han proporcionado un conjunto de recursos virtualizados consistentes en 64 cores virtuales y 262 gigas de RAM, así como una topología de red también virtual y un número limitado de instancias (imágenes de sistemas operativos) variables en recursos sobre el total disponible. En nuestro caso, hemos optado por siete instancias con las siguientes características en función del rol:

Rol master: 16 cores y 32 gigas de RAM sobre un Ubuntu virtualizado.

Rol worker: 8 cores y 32 gigas de RAM sobre un Ubuntu virtualizado. El rol master ejerce el control y reparto de trabajos entre las instancias con rol worker. Las instancias con rol worker se encargan del cómputo de los trabajos. En la siguiente figura se muestra el listado de instancias creadas y la asignación de los recursos virtuales.

Esta infraestructura Big data puede compartirse a fin de hacer un uso eficiente de los recursos del clúster, diferenciando las estructuras de directorios para el almacenamiento de datos y scripts particulares, así como esquemas propios en el Dataware House.


Figura 10. Instancias y asignación de recursos virtuales.

4.2.1 Topología de red

Cada una de las instancias pertenecen a una red virtual privada (“red_BigData”) en el rango 10.0.0.x. Dentro de esta red, los nodos del clúster tienen visibilidad entre sí. Por otro lado, se les proporciona acceso desde y hacia internet mediante un router (“router_BigData”) que habilita el acceso al clúster desde el exterior para la ingesta de datos y el acceso a los servicios del mismo. La figura siguiente muestra un diagrama con la topología implementada.

Figura 11. Topología de la red.


4.2.2 Gestor del clúster y servicios

Como gestor del clúster se ha optado por Cloudera manager, ya que es la distribución Hadoop de uso más generalizado. La instancia master asume el rol del gestor del clúster, para lo que se ha instalado el agente de control proporcionado por Cloudera. A partir del mismo, se han descubierto el resto de nodos mediante un patrón por nombre de máquina (“worker-x”). Mediante el asistente de gestión de Cloudera, se ha procedido a instalar los agentes de control sobre cada uno de los nodos de cómputo. A continuación, se han instalado los servicios que se muestran en la siguiente figura, quedando disponibles para su uso.

Figura 12. Servicios instalados.

La siguiente figura muestra el conjunto de nodos controlados por Cloudera, con un resumen de sus características como por ejemplo nombre, IP, número de roles (por servicios), último latido, promedio de carga, uso de disco y de memoria RAM, el conjunto de recursos de cómputo sobrantes, etc. Tras la instalación, estos servicios quedan disponibles para tareas de cómputo distribuido. Además, es posible la ampliación o decomisado de nodos para ajustar las capacidades de cómputo del clúster.

Figura 13. Características de los nodos instalados.


5. Motor de correlación de reglas

Los datos recolectados por el sistema de captación y posteriormente almacenados en la infraestructura big data son analizados por el sistema para ofrecer información extra a los usuarios o generar alertas automáticamente. Dichos análisis se realizan a alto nivel, puesto que se reciben datos de sensores desplegados en diversos subsistemas a lo largo de la ciudad enriquecidos con fuentes externas. Así pues, en el trabajo aquí descrito se cubren las especificaciones mostradas en la Tabla 6.

Tabla 6. Especificaciones implementadas en módulo de correlación mediante reglas.


S7.2.1 Operativa de actuación

S7.5.1 Actuadores automáticos

Se plantean dos tipos de análisis complementarios:

Análisis estadístico. Se basa en técnicas de aprendizaje automático (machine learning) que estudian las correlaciones estadísticas entre los datos para la detección automática de patrones, su clasificación o la predicción de valores futuros, entre otras aplicaciones. La infraestructura necesaria para su implementación y ejecución se ha explicado en la sección 4. La implementación y uso de estas técnicas se abordarán en el entregable E4.2 (3).

Análisis basado en reglas. Se basa en la aplicación de reglas lógicas establecidas de manera manual por un experto humano, que llevan a cabo una acción cuando se cumple una condición determinada. La infraestructura necesaria para ello se documenta en la presente sección. La explotación de este módulo se tratará en el entregable E4.2 (3).

5.1. Arquitectura del módulo

Como resultado de los tipos de análisis anteriores, se identifican sucesos o eventos. Dicho proceso extrae conocimiento de los datos en crudo, estableciendo cuándo se ha producido un hecho de interés. Una segunda fase aplica nuevas reglas lógicas para detectar alertas a partir de los eventos previamente identificados. También se contempla el establecimiento de la gravedad de la alerta detectada. Finalmente, se almacenan las alertas en la base de datos, que leerá el módulo de comunicación o visualización para mostrárselas al usuario, o para efectuar las acciones pertinentes (como enviar la alerta a los subsistemas de bajo nivel para que lancen los actuadores adecuados). Por ejemplo, supongamos que existe un sensor que mide el consumo de un tipo de energía en un contador determinado. Dicho sensor enviará periódicamente las medidas a un Gateway y éste al servidor, donde se almacenará en una tabla de la base de datos. Supongamos que el experto ha establecido que si esa medida supera un cierto umbral se genera un evento. A su


vez, ha establecido que cuando dicha medida supera el umbral durante más de un minuto (para evitar picos debidos a errores en la medición), se debe generar una alerta.

5.2. Motor de reglas

Se ha seleccionado un motor de razonamiento basado en Drools, que permite crear y desplegar sistemas de gestión de eventos complejos (Complex Event Processing) y configurarlos con gran versatilidad. Se contemplan dos tipos de reglas:

Estáticas Evalúan si unos datos determinados cumplen una condición en un momento dado. Por ejemplo, si un dato (o la relación entre varios datos) supera cierto umbral.

Dinámicas Añaden la componente temporal a las reglas estáticas, permitiendo evaluar si se producen cambios en el tiempo. Por ejemplo:

o Un evento se repite N veces durante un intervalo de tiempo determinado. o Dos eventos concretos se producen en el mismo intervalo de tiempo. o Se alternan valores superiores o inferiores a un rango con una frecuencia

superior a la de un umbral. A continuación se muestran algunos ejemplos de reglas estáticas en Drools:

package com.sample import es.iti.cei.experto.messages.Evento; rule "Alerta_grave" when m : Evento( sensorId8838 > 10, myMessage : message ) then m.setMessage( "Alerta grave en sensor energía activa Contador 88" ); m.setStatus( Evento.ALERTA ); System.out.println("DROOLS: ALERTA: "+ m ); end rule "Alerta_leve" when m : Evento(sensorId8838 > 5, myMessage : message ) then m.setMessage( " Alerta leve en sensor energía activa Contador 88" ); m.setStatus( Evento.WARNING ); System.out.println("DROOLS: EVENTO WARNING: "+ myMessage ); end rule "Normal" when m : Evento(sensorId8838 > 0, myMessage : message ) then


m.setMessage( "Medición normal en Contador 88" ); m.setStatus( Evento.INFO ); System.out.println("DROOLS: EVENTO INFO: "+ myMessage ); end rule "Sin_datos" when m : Evento(sensorId8838== null, myMessage : message ) then m.setMessage( "Sin información en Contador 88" ); m.setStatus( Evento.INFO ); System.out.println("DROOLS: EVENTO INFO: "+ myMessage ); end

6. Conclusiones

En el presente documento se ha descrito la infraestructura TIC que sirve como base a la plataforma desarrollada por el ITI en el proyecto CEI. Se ha detallado el sistema de captación de datos, la infraestructura Big Data y el motor de correlación desplegados. Sobre esta infraestructura se ejecutan los análisis de los datos mediante técnicas estadísticas y basadas en reglas, que se abordarán en el documento E4.2 (3), continuación del presente. En dicho documento también se documentará las interfaces gráficas que proporcionarán datos y resultados a los usuarios del sistema final.

7. Referencias bibliográficas

(1) Especificaciones estándar MQTT - http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf

(2) Entregable del proyecto CEI E2.1 “Informe de funcionalidades y arquitectura global”.

(3) Entregable del proyecto CEI E4.2 “Informe del sistema de tratamiento y análisis de datos masivos”

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf

Documents

CIUDAD ENERGÉTICAMENTE INTELIGENTE (CEI) Entregable E4CC%83o... · CIUDAD ENERGÉTICAMENTE INTELIGENTE (CEI) 4/33 Este documento está bajo una Licencia Creative Commons Atribución-NoComercial-SinDerivar