Recientemente el equipo de Keepler para Madrileña Red de Gas, desplegó una plataforma de datos en AWS para la recolección de información proveniente de contadores de gas inteligentes empleando, por primera vez a nivel mundial, la integración nativa del servicio de AWS IoT Core en combinación con redes públicas de LoRaWAN, junto con el operador Everynet.
Nuestro cliente, Madrileña Red de Gas, es una compañía líder en la distribución de gas natural. De acuerdo a las nuevas políticas gubernamentales que marcan la agenda 2030, las distribuidoras de gas deberán contar con lectura telemétrica en sus contadores; esto supondrá para Madrileña Red de Gas instalar cerca de 900.000 dispositivos adicionales a los que ya dispone.
El reto: diseñar el Smart Metering del futuro
El objetivo del proyecto consistía en desplegar una arquitectura IoT en la nube pública de AWS, agnóstica a los diferentes fabricantes de dispositivos, que centralice en una única plataforma de datos escalable y dinámica la información enviada por los Smart Meters de múltiples proveedores.
Esta solución innovadora desarrollada por Keepler sobre la nube pública de AWS, es capaz de recibir, ingestar y procesar los datos enviados por los contadores de gas inteligentes (Smart Meters) mediante el uso de la tecnología LoRaWAN a través de redes públicas, para posteriormente analizar y hacer disponible la información útil a los equipos de negocio y equipos técnicos de planta mediante las herramientas de analítica de datos y Business Intelligence nativas de AWS.
La arquitectura es modular y escalable lo que permite y facilita la incorporación de nuevos Smart Meters de manera ágil y dinámica, adaptando únicamente las piezas necesarias para procesar, almacenar y decodificar la información enviada por cada dispositivo.
Un proyecto pionero en el uso de LoRaWAN
AWS anunció en 2023 el soporte para redes públicas LoRaWAN de forma nativa a través del operador Everynet, lo que convierte este proyecto de colaboración a tres entre Keepler, Madrileña Red de Gas y AWS, ha sido pionero en emplear esta funcionalidad en un entorno real.
Utilizar LoRaWAN a través de redes públicas directamente integrado en los servicios de AWS permite al cliente un ahorro significativo en el mantenimiento de la infraestructura de red relativa a LoRaWAN, ya que se elimina la necesidad de desplegar, mantener y gestionar gateways privados, utilizándose únicamente aquellos que el proveedor de red actual tenga ya instalados (gateways públicos). Además, permite unificar los costes en un único panel centralizado a través del propio servicio de billing de AWS.
La solución técnica
La solución combina e integra el mundo físico de los dispositivos o Smart Meters, con el mundo de nube pública, a través de la integración de los contadores inteligentes de gas con AWS IoT Core.
AWS IoT Core for LoRAWAN actúa como LNS (LoRAWAN Network Server) recibiendo y descifrando los mensajes de los distintos dispositivos desplegados. Una vez se reciben mensajes de los Smart Meters, el enrutado de los mismos se hace por medio de reglas que se configuran dentro del propio servicio AWS IoT Core permitiendo definir la lógica de enrutamiento asociada a cada mensaje, como por ejemplo enviar los datos para su almacenamiento y/o procesamiento a otros servicios de AWS como S3 y Kinesis Firehose.
Cada regla se ha configurado con dos acciones fundamentales: la primera es la encargada de enviar los datos a Kinesis Firehose para su procesamiento en tiempo real y, la segunda, se encarga de almacenar los datos en bruto (raw) directamente en S3 para almacenamiento a largo plazo; lo que nos habilita opciones como: auditorías, análisis de seguridad, posibles reprocesados, analítica avanzada, detección de anomalías, etc.
Arquitectura multi-rama con soporte para múltiples fabricantes de dispositivos físicos (Smart Meters) desde la ingesta del dato hasta su consumo por parte de las unidades de negocio
Diseñar la solución para procesar los datos en tiempo real o cercano a tiempo real (near real time), permite tener disponibles los datos de cada Smart Meter para su revisión y análisis con la menor latencia posible entre el envío, recepción y procesamiento. Este procesamiento en near real time (nRT) se lleva a cabo utilizando la integración nativa entre Kinesis Firehose y AWS Lambda. Cuando un mensaje llega a la plataforma a través del LNS (AWS IoT Core), se enruta mediante una regla de IoT Core hacia Kinesis Firehose, que está configurado para pre-procesar los datos mediante una función Lambda que decodifica el payload (binario o textual) y devuelve los datos en formato JSON de vuelta a Kinesis Firehose. Firehose volcará los datos a S3 en un formato columnar óptimo para su análisis y procesamiento como es Parquet. Una vez los datos se encuentran en S3, AWS Glue nos permitirá definir el modelo de datos bajo que regirá los datos almacenados en las diferentes capas o buckets.
Con todos los datos almacenados en S3 y actualizándose en nRT, junto con el modelo de datos definido y el catálogo de datos almacenado en AWS Glue, tenemos ya definida nuestra arquitectura base estándar de DataLake.
Explotar la información de un DataLake en AWS es una tarea que se lleva a cabo de una manera muy eficiente en rendimiento y coste utilizando el servicio de AWS Athena. Este servicio nos va a permitir lanzar queries SQL sobre las diferentes capas de nuestro DataLake que contienen los datos de los diferentes Smart Meters y, además, nos va a servir para definir los DataSets que serán consumidos posteriormente por cada uno de los Dashboards diseñados y definidos en QuickSight (herramienta de BI nativa de AWS).
La gran versatilidad y potencia que aporta definir una arquitectura de tipo Data Lake para soluciones IoT es que podemos centralizar diversas fuentes de datos en una única plataforma que nos permita cruzar, explorar y analizar conjuntos de datos diversos y heterogéneos, generando nueva información que aporte valor tanto técnico como de negocio. Para esta solución de Smart Meter de gas, incorporamos al Data Lake una fuente de datos abierta como es la información meteorológica proveniente de la AEMET. De esta forma, en los Dashboards de QuickSight podemos mostrar información proporcionada por los dispositivos (como consumos acumulados de gas, pronóstico de consumo para las próximas fechas, estado de las baterías de los dispositivos) incluyendo datos climáticos provenientes de AEMET, los cuales enriquecen los datos de pronóstico de tiempo de acuerdo a las temperaturas.
La plataforma está diseñada para ser multi-fabricante, permitiendo a Madrileña Red de Gas tener diferentes proveedores de contadores inteligentes (Smart Meters) desplegados bajo la misma red, unificando de este modo en una única plataforma de datos, toda la variedad requerida de dispositivos. Debido a que cada fabricante puede utilizar un mecanismo de codificación y cifrado propio para los mensajes de sus dispositivos, en IoT Core se configura una regla dedicada para cada fabricante, que a su vez, invoca a una función Lambda específicamente diseñada para decodificar el payload correspondiente. Es en IoT Core donde se registran y establecen las relaciones entre las reglas, los topics de mensajes y los contadores inteligentes asociados.
Retos técnicos del proyecto
Seguridad
Para garantizar la seguridad de los datos y la integridad de la información de extremo a extremo, se han implementado varios mecanismos de cifrado en reposo y al vuelo, que permiten garantizar que los datos permanecen seguros en todas las fases del ciclo de vida.
Para los dispositivos IoT conectados mediante la red LoRaWAN los datos se cifran utilizando claves privadas generadas al vuelo gracias a la configuración OTAA y las especificaciones del propio protocolo de comunicación. AWS IoT Core se encarga de actuar como LNS y descifrar los mensajes de cada Smart Meter.
Para mantener la seguridad del dato en reposo se ha habilitado el cifrado en los distintos elementos de la arquitectura usando KMS con claves gestionadas por AWS.
Múltiples fabricantes
Inicialmente, la arquitectura se diseñó para emplear los contadores inteligentes de un único fabricante, de manera que solo se decodificaría un payload único y el esquema de los datos a tratar en toda la arquitectura vendría dado por los campos de este payload.
No obstante, se detectó la necesidad de incorporar también los contadores inteligentes de nuevos fabricantes, con lo que se hizo necesario evolucionar la solución hacia una arquitectura multi-rama (o multi-branch) que permita decodificar varios tipos de payloads. Para ello, hubo que evolucionar junto con el diagrama de arquitectura, los esquemas de los datos, así como dinamizar la creación de los diferentes componentes involucrados en la recepción y decodificación de cada mensaje.
La arquitectura se adaptó con una regla de IoT Core para cada fabricante, las cuales se emplearon como destino a la hora de dar de alta a los contadores inteligentes. De este modo se genera una arquitectura escalable a modo de ramas para soportar múltiples fabricantes con múltiples protocolos de codificación y cifrado.
IaC (Infrastructure as Code)
Toda la arquitectura presentada previamente se despliega siguiendo las buenas prácticas definidas para IaC. En este caso se utiliza Terraform para escribir todo el código de infraestructura necesario. El mayor reto, ha sido preparar los scripts de Terraform dinámicos, de modo que puedan generar los componentes de infraestructura de forma dinámica en función del número de proveedores de Smart Meters que haya en cada momento y que facilite la adición o eliminación de de un proveedor determinado de manera ágil y dinámica, cuando la infraestructura se encuentre desplegada.
Enriquecimiento de datos
No solo se quiso mostrar un pronóstico basado en el consumo de gas de cada usuario y datos técnicos proveniente de los sensores o los servicios de AWS, sino que se optó por añadir datos de una fuente externa como AEMET.
De este modo, se diseñó un proceso de extracción de datos para obtener información climática y cruzarla con los datos de consumo con tal de ofrecer un pronóstico mucho más preciso para detectar patrones de consumo en función del clima meteorológico y predecir posibles averías y anomalías en función de las condiciones climáticas.
Dashboards con los KPIs más relevantes
El dashboard tiene la finalidad de contestar a dos requerimientos principales: estado en el que se encuentra cada dispositivo y consumo de GAS. Además se ha enriquecido con datos abiertos de AEMET para aportar más valor facilitando así el análisis y toma de decisiones para los equipos de negocio.
Se pueden destacar tres visualizaciones de todo el conjunto: Accumulated gas consumption and forecast, Last device upload y Temperature Forecast (AEMET).
Esta es una visualización que además de informar del consumo acumulado de todos los dispositivos diariamente, muestra métricas futuras basadas en aprendizaje automático utilizando las capacidades que tiene integradas Quicksight de Machine Learning Forecasting. En este caso se ha configurado Periods forward para mostrar la previsión de consumo de los próximos 3 días.
Last device upload
En esta visualización se recoge el estado de de cada dispositivo, mostrando el último envío de cada dispositivo donde se informa del: Id del dispositivo (Device), el timestamp del envío (Upload time), el estado de la batería (Battery level), el voltaje consumido en el envío (Battery voltage), si el contador ha sido manipulado (magnetic), el estado de la válvula de entrada de gas (Valve status), si el reloj interno está sincronizado (Time sync) y el consumo de gas (Gas volume) medido por cada dispositivo.
Además se han añadido una serie códigos de colores e iconos para mostrar indicaciones dependiendo del valor de los distintos campos:
- Un aspa granate en el campo Device informa que hace más de 4 horas del último envío de señal (ventana de detección de envío configurable)
- Un valor “normal” en el campo Battery level se muestra con un pulgar hacia arriba en verde. Valores por debajo de “normal” se muestran con un círculo granate.
- Un valor “normal” en el campo Magnetic, se muestra con un pulgar hacia arriba en verde.
- Un valor distinto de “sync” en el campo Time sync se muestra con la tipografía roja.
Temperature forecast (AEMET)
En esta visualización mostramos las temperaturas máximas y mínimas en Pozuelo de Alarcón para los próximos tres días (configurable para cualquier ciudad/comunidad de España), así como el estado del cielo, la cota de nieve o la probabilidad de precipitación en %. Estos datos se han obtenido del catálogo de datos abiertos que pone a disposición la AEMET. Además de temperaturas máxima y mínima, tenemos humedad relativa, precipitaciones, sensación térmica, nieve y una descripción del estado del cielo.
Esta información de fuentes abiertas de terceros, ayuda a complementar la información que se recibe de los sensores y ayuda a detectar y catalogar posibles anomalías que puedan producirse en la producción y consumo de gas motivadas, por ejemplo, por una climatología adversa.
Impacto de negocio
Con este desarrollo, Madrileña Red de Gas dispone de una Plataforma de Datos centralizada y agnóstica a cualquier fabricante de Smart Meters que va a permitir recibir y procesar los datos de los dispositivos independientemente de su origen, verificando que es factible disponer de soluciones fiables de ingesta y procesamiento en tiempo real para dispositivos que se conectan a redes de baja potencia. Esto habilita trabajar sobre redes LoraWan y sobre redes NB-IoT a futuro, facilitando la adopción de ambos tipos de redes al cliente de manera sencilla.
ℹ️ Una red NB-IoT forma parte de las redes de tipo LPWA, conocidas como redes de Bajo Consumo y Área Extensa, que permiten operar en lugares de difícil acceso y conectividad menos estable, ya que está diseñada específicamente para la comunicación de dispositivos IoT con capacidades de envío de información específicas en volumen y tiempo.
Lecciones aprendidas
- La solución se ha diseñado como una arquitectura multi rama, lo que permite añadir nuevos fabricantes de distintas marcas con diferentes tipos de datos sin tener que modificar los fabricantes anteriores, lo que garantiza la retrocompatibilidad y escalabilidad de la solución.
- No es posible automatizar al 100% el despliegue de la solución ya que hay que realizar un desarrollo ad-hoc para cada nuevo fabricante que se quiera incorporar, debido a que para poder recibir datos hay que adaptar los diferentes esquemas y mecanismos de codificación y cifrado siguiendo las especificaciones de cada fabricante.
- Las soluciones de IoT desarrollan una estrecha relación con el firmware de los dispositivos; si se actualizan es posible que haya que modificar los scripts de descifrado de los mensajes de los dispositivos, por lo que hay que estar siempre atento a nivel de soporte.
- Es importante tener una comunicación fluida con los fabricantes para que se proporcione una buena especificación actualizada, ya que dependemos totalmente de su documentación para saber cómo decodificar cada mensaje (sobre todo en los dispositivos que envían los mensajes en formato binario).
Evolución de la Plataforma de IoT
- IA/ML aplicada para vacíos en el dato y que pueda generarse el dato de forma artificial en base a variables como:
- Vecinos del dispositivo afectado
- Histórico del dispositivo afectado.
- Incorporación de procesos de IA/ML avanzados:
- Detección de patrones y/o anomalías
- Predicción del consumo en base al histórico de demanda
- Implementación de un pipeline de CICD para desplegar componentes de arquitectura o dar de alta nuevos dispositivos IoT de manera automática
Cloud Engineer at Keepler. “Technology lover, currently focused on cloud and cybersecurity areas. Passionate about learning new things and facing new challenges.”
Data Analyst & BI Analyst en Keepler. "What I wanted to be was a pianist. I've been working with data in one way or another since I started working in offices back in the Pleistocene. I'm lucky enough to do what I love and learn all the time. I love analyzing data to discover trends and I love minimalist design to display this data. In my spare time I make music... or whatever...".
0 comentarios