Detección de anomalías en la recopilación de datos de electricidad en tiempo real – Parte 1

Por Ivan Vargas, Arquitecto de Soluciones.

Intro

La recopilación de grandes cantidades de datos y el procesamiento por lotes es un enfoque bastante común y rentable. Sin embargo, a medida que aumenta el volumen de datos y los problemas empresariales requieren que estos procesos se lleven a cabo con mayor frecuencia y rapidez, es necesario evaluar alternativas a este modelo. En este contexto, los enfoques relacionados con la adquisición y procesamiento de datos de streaming para el procesamiento en tiempo real han demostrado ser una alternativa eficiente para satisfacer los diferentes requisitos del negocio. Los recursos computacionales se escalan de manera más eficiente y permiten realizar análisis y decisiones al procesar estos datos.

La propuesta de esta serie de 3 posts de blog es explorar una arquitectura para la recogida de datos de energía eléctrica, con el fin de identificar anomalías en los datos recogidos de cada medidor y permitir el desencadenamiento de acciones remotas si se detecta alguna desviación de comportamiento. También agregaremos paneles para monitorear esta colección en la vista de un operador de este sistema. Además, los datos recogidos se almacenarán para su posterior procesamiento y se enriquecirán con datos de registro para que sea posible generar análisis históricos por fecha, región, ciudad y estado, por ejemplo. El resultado de esta colección también se puede utilizar para cumplir con otros casos de uso, como modelos de previsión de consumo de energía. Para ello, AWS proporciona Quickstart Utility Meter Data Analytics en AWS.

Esta publicación es la primera parte de esta serie en la que describiremos el blueprint completo de arquitectura utilizando los servicios de AWS. En la segunda parte, discutiremos en detalle cómo recopilar y hacer que los datos estén disponibles a través de streaming para su procesamiento en tiempo real. En la tercera y última parte, hablaremos sobre cómo agregar los datos recopilados para generar información e ideas cruzando información transaccional y catastral.

Contexto empresarial y volumétrico

Utilizaremos el mercado eléctrico brasileño con un ejemplo del uso de la arquitectura propuesta. En este contexto, tanto los generadores como los consumidores deben enviar sus datos de contadores diariamente. Estos datos contienen información del flujo de energía que pasa en el medidor y deben ser capturados y agregados a intervalos de 5 minutos, es decir, tenemos 288 registros de datos de energía para cada medidor por día. Según el informe de gestión de la Cámara de Comercialización de Electricidad – CCEE de 2019, el año pasado terminó con 23.485 puntos de medición. El punto de medición aquí es un concepto lógico para la abstracción de la instalación física y consiste básicamente en dos medidores de potencia, el principal y el posterior. Por lo tanto, la volumetría esperada en este contexto es de 46.970 metros enviando 288 registros de medición por día, con un total de más de 13,5 millones de registros diarios. El formato del archivo cargado es XML y tiene un tamaño promedio de 300kb, lo que genera un volumen diario alrededor de 14Gib. La ventana mensual de datos procesados gira alrededor de 400 millones de registros y 420 GiB de datos. Aún de acuerdo con el informe anterior, el mercado experimentó un crecimiento del 17% entre 2018 y 2019. Podemos considerar que este volumétrico también crece en la misma proporción.

Teniendo en cuenta el volumen anterior, el procesamiento de estos datos a través de streaming y en tiempo real tiene mucho sentido y aporta beneficios como la flexibilidad de la plataforma tecnológica, la detección de comportamientos inesperados de forma rápida y un monitoreo preciso que puede desencadenar acciones tempranas como el mantenimiento o la desconexión de metros, por ejemplo.

El ejemplo del caso de uso citado anteriormente se refiere a la opinión desde la perspectiva de la Cámara de Comercialización de Energía Eléctrica (CCEE). Sin embargo, este caso de uso también es aplicable a los distribuidores de energía, pero en un conjunto diferente de información. Los distribuidores suelen utilizar soluciones de gestión de datos de medición (MDM) específicas para su parque de medidores y ejecutan comandos remotos además de la recopilación de datos.

La arquitectura propuesta

La propuesta de esta serie de publicaciones de blog es ejemplificar cómo se puede resolver el caso de uso propuesto mediante los servicios de AWS. No es el objetivo aquí detallar una arquitectura de referencia de extremo a extremo sobre el tema, ya que requeriría un enfoque más profundo de algunos componentes de la arquitectura (como los metros, por ejemplo). En esta arquitectura, utilizamos un dispositivo Raspberry PI para demostrar las posibilidades de comunicación bidireccional mediante AWS IoT Core, sin el compromiso de abordar la arquitectura específica del dispositivo mediante servicios de AWS como AWS IoT Greengrass o FreeTos, específicos para este fin.

El siguiente diagrama detalla la arquitectura completa utilizada durante esta serie de entradas de blog:

Imagen 1 – Arquitectura completa

El diagrama se dividió en 3 bloques: Ingestión de datos, procesamiento casi en tiempo real y visualización de datos históricos. A continuación describimos los componentes de cada bloque y resaltados por la numeración correspondiente:

Ingestión de datos

Ubicación física de un generador de energía que contiene dos metros para fines de redundancia. Estos medidores envían una carga útil JSON a través del protocolo MQTT o HTTPS a AWS IoT Core, que es un servicio gestionado y actúa como agente de MQTT para recopilar datos de millones de dispositivos. Asociados con AWS IoT Device Management, son responsables de la seguridad mediante el intercambio de claves públicas y privadas entre dispositivos, lo que facilita la transmisión segura de información a través de TLS 1.2. Reglas de IoT es responsable de enrutar los mensajes a dos componentes: Amazon Kinesis Data Stream, que contiene los datos originales y sin transformación, y Amazon Elasticsearch Service, un servicio gestionado por AWS para clústeres de Elasticsearch con Kibana.
Los datos añadidos por las Reglas de IoT a Amazon Kinesis Data Streams son consumidos por tres componentes: Amazon Kinesis Data Analytics y dos Firehoses de Amazon Kinesis. Kinesis Firehose S3 Dump es responsable de almacenar en búfer los datos entrantes agregar los diversos mensajes y guardar en Amazon S3 en formato comprimido Parquet. Firehose Elasticsearch Buffer controla la entrada de datos en Amazon Elasticsearch Service para evitar la sobrecarga de componentes debido al volumen de datos.

Procesamiento casi en tiempo real

Amazon Elasticsearch Service creó 2 paneles Kibana para realizar un seguimiento de los datos que se envían y también para notificar las anomalías detectadas. Los paneles se actualizan automáticamente minuto a minuto, teniendo en cuenta el tiempo mínimo de almacenamiento en búfer para Amazon Kinesis Firehose.
Amazon Kinesis Data Analytics es responsable de detectar anomalías mediante algoritmos de aprendizaje automático. Las anomalías identificadas se insertan en Amazon Elasticsearch Service y Amazon S3. Además, la función Set-Timestamp de Lambda enriquece los datos, incluyendo la puntuación de anomalía y la marca de tiempo.
La segunda función Lambda llamada anomaly-Checker envía un mensaje MQTT a AWS IoT Core con la puntuación de la anomalía y el comando remoto para ejecutarse si está por encima de un umbral parametrizado.
El dispositivo físico que simula el medidor de potencia, en este caso utilizando un Raspberry PI, demuestra la recepción de datos de AWS IoT Core a través de MQTT para actualizar el panel al estado del dispositivo y también ejecutar comandos remotos enviados por el paso anterior. Por ejemplo, activar una alarma en el plano del generador o deshabilitar la entrada de energía en un medidor son algunos comandos relevantes en este escenario.

Visualización de datos históricos

Los datos almacenados en Amazon S3 están catalogados por AWS Glue Data Catalog. Anteriormente se particionaron en Amazon Kinesis Firehose en dimensiones Año, Mes, Día y Tiempo, y se actualizan con un rastreador creado en AWS Glue. Con Amazon Athena, asignamos archivos de Parquet y CSV (con los datos de registro) disponibles en S3 como tablas externas y hacemos que las consultas SQL estén disponibles con la combinación de datos de medición y datos de registro para la asignación de conjuntos de datos en Amazon QuickSight.
Con Amazon QuickSight, generamos un panel interactivo con datos agregados con historial de recopilación y capacidad para desglosar por año, mes, día, hora, estado, ciudad, propietario del medidor, medidor, tipo de datos recopilados y puntuación de anomalías.

Beneficios y próximos pasos

Hasta ahora hemos hablado de cómo resolver el caso de uso descrito utilizando los servicios de AWS con un enfoque escalable y flexible basado en eventos y utilizando únicamente servicios gestionados. Esta estrategia trae como principales beneficios:

Eliminación de la necesidad de gestión de servidores;
Flexibilidad para agregar nuevas funcionalidades porque se pueden agregar nuevas reglas al flujo existente sin afectar al flujo de datos principales.
Modelo de costo de pago por uso, que permite escalar el TCO de la solución junto con el volumen de datos recorridos;
Escala a millones de dispositivos con procesamiento en tiempo real de gigabytes de datos

En las siguientes publicaciones vamos a describir cómo crear implementar esta arquitectura paso a paso.

Sobre el autor

Ivan Vargas es Arquitecto de Soluciones de AWS enfocado en empresas del segmento digital que ya han nacido o tienen la mayor parte de sus operaciones en la nube. Actúa ayudando a los clientes al diseñar e influir en soluciones basadas en los servicios de AWS. Con más de 15 años de experiencia en Arquitectura, Desarrollo Web y Gestión de TI, Ivan ha trabajado en varios proyectos de desarrollo y modernización de aplicaciones.

Blog de Amazon Web Services (AWS)