Esta es la segunda parte de este artículo. Donde estaré realizando una explicación extensa de un proyecto que desarrollé la materia Infraestructura Avanzada de Redes de Sensores.
Para ir directamente a la práctica visita el repositorio: https://github.com/joseluisramon/Water-Metering-System
Una explicación del proyecto en vídeo se encuentra aquí
Selección de Red de Comunicaciones
En la sección anterior se indicó que el costo de los contadores era un costo fijo, ya que casi todos los contadores residenciales disponibles en España tienen un costo aproximado de 35 euros. Los costos variables dentro del proyecto serán aquellos relacionados con los elementos que se necesitan para implementar la red de comunicación
OPCION 1: Solución M-Bus
Para la solución basada en M-bus se consideró utilizar el concentrador que se muestra en la Figura 7. Es un convertidor Marca Decode, Modelo MM20-GSM. El cual realizar lecturas de hasta 20 esclavos M-bus. En Sevilla la mayoría de las residencias tiene menos de 20 pisos, por lo tanto, este concentrador permitiría agrupar los medidores de agua de un edificio. Lo cual es muy bueno al momento de sectorizar las mediciones.
Dentro de sus prestaciones más interesantes está la posibilidad de realizar la configuración de los mensajes que se enviarán vía GSM por medio de una interfaz de usuario. Esto permite configurar el mensaje SMS únicamente con la información de mayor utilidad para la empresa de distribución.
OPCION 2: Solución LoRaWan
Para la solución basada en LoRaWan tiene que adosar un módulo de transmisión LoRa al medidor de agua. Esto hace que su precio sea ligeramente superior al medidor que tiene un módulo M-bus. Se profundizará en esto al final de esta sección.
Los concentradores LoRaWan permiten trabajar con muchos más dispositivos que los que los M-bus. Por ejemplo, el concentrador Marca Ursalink, Modelo UG87, puede trabajar hasta con 2000 dispositivos LoRaWan. Esto reduce en gran medida la cantidad de concentradores necesarios para implementar la red. Sin embargo, requiere de una instalación más complicada, ya que los lectores LoRaWan debería tener línea directa con el concentrador.
Estimación de Precios / Áreas de Influencia
Para poder estimar el costo de la red se decidió limitar geográficamente el área que se quería atender en esta primera etapa. Para ello fue planteada la siguiente pregunta
¿Cuánto me costaría implementar un sistema de tele medición de agua en el Barrio de Triana en Sevilla?
En primer lugar, se quería confirmar si el alcance de los concentradores LoRaWan podría cubrir la zona de Triana. Las especificaciones del concentrador considerado dicen que tiene un alcance de hasta 11km, considerando que los edificios del barrio están contenidos en un área menor a 1.87km² se puede calcular que un concentrador es más que suficiente.
Sin embargo, la cantidad de habitantes en Triana es de aproximadamente 49mil personas. Hacer el cálculo de como dividir esas personas en unidades habitacionales, tiendas y bares y demás establecimientos que consumen agua escapa al alcance de este proyecto. Para simplificar decidimos estimar la cantidad de medidores en el área dada a unos 15mil.
| Solución Meter Bus + GSM | Unidades | Costo | Subtotal |
|---|---|---|---|
| Medidor de agua + Adaptador MeterBus cableado | 15000 | 38.00 € | 570 000.00 € |
| Concentrador M-bus. Marca Decode. (Unds = 15000 / 20) | 750 | 232.00 € | 174 000.00 € |
| Interconexión / Instalación / Contrato GSM | 15000 | 20.00 € | 300 000.00 € |
| TOTAL | 1 044 000.00 € |
Por otra parte
| Solución LoRaWan | Unidades | Costo | Subtotal |
|---|---|---|---|
| Medidor de Agua + Adaptador LoRaWan. | 15000 | 42.00 € | 630 000.00 € |
| Concentrador LoRaWan. Marca Ursalink. (Unds = 15000 / 2000) | 8 | 1 100.00 € | 8 800.00 € |
| Interconexión / Instalación / Servidor Web | 15000 | 30.00 € | 450 000.00 € |
| TOTAL | 1 088 800.00 € |
Si bien la solución LoRaWan requiere muchos menos concentradores, el costo de instalarlos los postes, cablear las antenas y contratar el servidor web requerido por LoRaWan es mayor que el requerido para implementar la red M-bus. Adicionalmente, el concentrador M-bus me permite fragmentar y organizar mis mediciones, agrupándolas por edificaciones que se encuentren cercanas geográficamente.
Dado el presupuesto estimado y la facilidad para agrupar las mediciones de los sensores, el desarrollo del proyecto se hará por medio de Meter Bus, es decir, la OPCIÓN 1.
Almacenamiento de Datos
En la Figura 5 se presenta la red que será construida por medio de los medidores. Conociendo esta red se planteó un diagrama entidad-relación para el sistema tomando en cuenta lo siguiente:
- Hay varios distritos dentro de una ciudad. En cada distrito se encuentra N concentradores
- Cada concentrador puede agrupar hasta 20 medidores de agua
- Cada medidor de agua realiza al menos una lectura semanal y presenta la cantidad de agua que ha consumido desde la última vez que se realizó la medición.
Por medio de queries se puede construir una tabla donde se almacenen las lecturas históricas de cada distrito y de cada cliente. Semanalmente, la tabla debería replicarse y guardarse para acceder a los históricos de cada cliente y también para calcular los agregados por distrito.
Puesto que en este caso se va a estar trabajando con una simulación del sistema, se va a trabajar con la tabla de históricos o ‘logs’.
| log_id | log_date | slave_id | master_id | district_id | water_amount |
|---|---|---|---|---|---|
| 1 | 2020-06-01 10:05:00 | 1 | 1 | 4 | 300 |
| 2 | 2020-06-01 10:15:00 | 3 | 2 | 2 | 200 |
| 3 | 2020-06-01 10:25:00 | 2 | 1 | 4 | 400 |
El slave_id indica el medidor de cada cliente. El master_id es el identificador del concentrador y el district_id es el identificador de los barrios dentro de Triana. Por medio de relaciones se podrían extraer los nombres completos de cada uno de los elementos antes indicados
Simulación
Para simular el funcionamiento del sistema se decidió utilizar la distribución que se muestra en la Figura 10. La generación de datos dentro del sistema se hará por medio de Node-RED. El flow construido se muestra a continuación y está disponible en el repositorio que se indica al comienzo del artículo
Entonces, sabiendo la distribución de los medidores y cómo se generarán los datos, la tabla de logs quedará de la siguiente manera:
Para mejor compresión he decidido implementar la siguiente tabla
| log_id | log_date | slave_name | master_name | district_name | water_amount |
|---|---|---|---|---|---|
| 1 | 2020-06-01 10:05:00 | slave1 | master1 | distric1 | 300 |
| 2 | 2020-06-01 10:15:00 | slave3 | master2 | distric2 | 200 |
| 3 | 2020-06-01 10:25:00 | slave2 | master1 | distric1 | 400 |
| 4 | 2020-06-01 10:35:00 | slave1 | master1 | distric1 | 230 |
| 5 | 2020-06-01 10:45:00 | slave3 | master2 | distric2 | 110 |
Con las condiciones antes mencionadas se estableció en entorno de simulación, el cual puede verse mucho mejor en el vídeo que presento al principio de este articulo.
Conclusion y consideraciones finales
Desarrollar este proyecto fue una tarea muy interesante que permite tener una idea de todas las posibilidades que nos brinda una herramienta como Grafana. Sin embargo, quedan algunas cosas pendientes o posibles mejoras
- Almacenamiento (PostgreSQL)
- Trabajar con entidades separadas en vez de escribir en una única tabla.
- Escribir directamente en la tablas de cada una de las entidades
- Crear el querie que me produzcan la tabla logs.
- Generación de Datos (Node-RED)
- Simplificar la forma en que se escriben los datos en la bases de datos.
- Utilizar nodos JOIN para unir las lecturas generadas por cada uno de los medidores y escribir en la base de datos una única vez
- Generación de datos más realistas. Que sigan un patrón o una función.
- Visualización (Grafana)
- Generar alarmas dentro de Grafana, para que aparezcan en el tablero
- Descargar los datos de un usuario por medio de grafana.
- Utilizar fuentes de datos adicionales
Estas son sólo algunas de las cosas que se me ocurrieron. Pero estoy abierto a más sugerencias.
Espero que este archivo haya sido de su interés y quedo atento a sus comentarios. Saludos
jlrcolmenares 