Colombia es uno de los países con mayor número de recursos hídricos en el mundo, 3 veces mayor que los demás países de Latinoamérica. Por esto existe un alto interés en preservar dichos recursos [1]. Un método que logra este objetivo son los Sistemas de Drenaje Urbano Sostenible (SUDS).

Los SUDS son sistemas para la gestión de aguas pluviales, que replican procesos hidrológicos naturales en el desarrollo urbanístico, controlando la escorrentía en el paisaje urbano. Sirven como apoyo a los sistemas de alcantarillado en las ciudades, cuya capacidad es sobrepasada debido a la falta de infiltración natural del agua en las zonas urbanas. Permiten la reducción de los eventos de inundación y la restauración del ciclo hidrológico natural. Como se puede observar en la Figura 1, con la expansión de las grandes ciudades y el uso del suelo para infraestructura urbana, se causa la impermeabilización de una gran parte del suelo. En consecuencia, el agua que antes se infiltraba naturalmente, ahora sobrepasa el sistema de alcantarillado y circula por las calles, por lo que se requiere de procesos para su recolección y transporte.

Figura 1. Comparación de la infiltración del agua en un entorno natural y uno urbano [2].

Este problema causa inundaciones en las ciudades, contaminación y alteración del ciclo natural del agua, ya que evita que la lluvia se infiltre en el terreno y recargue los acuíferos [1]. Los SUDS ayudan a prevenir estas situaciones, por medio del uso de los espacios verdes para compensar la falta de infiltración natural en el suelo y así restaurar el ciclo hidrológico natural. Algunos ejemplos de SUDS son [1]: cunetas verdes, Sistemas de Techos Verdes o Cubiertas Vegetalizadas, Superficies permeables.

En el piloto MySUDS se construyó una cuneta verde (ver figura que sigue) que tiene el objetivo de transportar la escorrentía proveniente de las zonas impermeables en la ciudad. Son importantes herramientas para la retención de basuras gruesas y sólidos suspendidos aportando a la remoción de contaminantes en el agua.

Figura 2. Cuneta verde [2]

A pesar del gran potencial de los SUDS no hay mucha información cuantitativa sobre el rendimiento y funcionamiento de dichos sistemas. Además, cuando se implementan las mediciones suelen hacerse de manera manual, lo que resulta en reducción de la eficiencia del sistema y espacio para errores humanos.

Problema 

La secretaría de Ambiente y el Acueducto de Bogotá contactaron a la Universidad de Los Andes para diseñar e implementar un piloto de un SUD en el Parque Metropolitano San Cristóbal, uno de los parques más importantes del suroriente de Bogotá, ubicado en la localidad de San Cristóbal.

Este parque cuenta con una extensión cercana a las 11 hectáreas y uno de sus mayores atractivos son sus amplias zonas verdes. Como se puede apreciar en la Figura que sigue, el parque es delimitado por el Río Fucha el cual debido a las lluvias ha generado en múltiples ocasiones inundaciones en el barrio Santa Ana [6]. Por tanto se propone realizar una intervención en la zona que permita desviar las aguas del Río Fucha hacía un SUD ubicado en el parque, de manera que se puedan evitar las inundaciones en el barrio circundante.

Para poder monitorear el rendimiento de la cuneta se requiere el monitoreo de los eventos de precipitación; y el nivel del agua y conductividad en cada una de las cámaras del canal.

Nota: Le sugerimos con énfasis ver estos videos que contextualizan el proyecto:

1. Video que relata el problema y la solución global
2. Video que muestra estructuralmente el SUD construído en el parque San Cristóbal

Figura 3. Ubicación del Parque San Cristobal

Descripción del Desarrollo del Proyecto

El proyecto se desarrolló en dos etapas: (i) la construcción del sistema físico de desviación del Río Fucha hacía la cuneta, y (ii) el diseño y despliegue del sistema de monitoreo basado en IoT.

En la primera fase se construyó un sistema que desvía el agua del río al parque; dicho sistema está conformado por una compuerta, dos cámaras una de entrada de agua y otra de salida y una cuneta verde para el drenaje. Con la construcción de este sistema se espera que el volumen de agua en la cámara de salida sea menor que el de la cámara de entrada (ver figura que sigue). Adicionalmente se instalaron sensores en cada cámara para medir la eficiencia del sistema, pero la recolección de los datos inicialmente era manual.

Figura 4. Vista aérea del Sistema MySUDS del Parque San Cristobal

La segunda etapa tuvo como finalidad incluir las tecnologías de IoT para automatizar la recolección y el almacenamiento de los datos del sistema para su posterior explotación.

A continuación se presentará el análisis y diseño de la arquitectura del proyecto MySUDS para dar respuesta a las necesidades de automatización de la recolección y el almacenamiento de los datos del sistema. Por un lado, el análisis incluye los siguientes pasos: identificación de problemas/oportunidades, identificación de interesados y sus necesidades, identificación de requisitos de alto nivel, dilemas éticos del proyecto e historias de arquitectura. Por otro lado, presentaremos las decisiones de diseño tomadas en el proyecto, utilizando la arquitectura de referencia por capas que se sigue en el curso, a saber: capa de dispositivos, capa de red, capa de datos y capa de aplicación.

Análisis de requisitos del Sistema IoT

Identificar problemas y oportunidades

Por falta de infiltración natural del agua de lluvia se generan inundaciones, obstrucción en los sistemas de drenaje y alcantarillado existentes, deterioro en la calidad del agua. Todo esto afecta al barrio vecino y a los ciudadanos.

Identificar interesados

Analizar las necesidades de los interesados

Mitigar el impacto negativo causado por la reducción de la infiltración natural del agua en áreas urbanas.

Mejorar la calidad del agua que fluye hacia los cuerpos de agua naturales. Río Fucha.

Prevenir inundaciones en la ciudad.

Acceso a un parque en buen estado.

Analizar cuáles son los requisitos de alto nivel

Requisitos funcionales de alto nivel

• Desviar caudal del río aledaño al parque para evitar inundaciones
• Visualizar datos de flujo del agua (escorrentía) y conductividad en tiempo real a la entrada y salida del SUDS.
• Buscar eventos históricos de lluvia.
• Descargar los datos relacionados con un evento para realizar la analítica por fuera del sistema utilizando herramientas preexistentes.
• Enviar notificaciones cuando un evento de lluvia comienza.

Requisitos de calidad de alto nivel

• Alto Volumen de datos
• Latencia de envío de mensajes menor a 300ms
• Tiempo de respuesta de las consultas de información menor a 1 minuto
• Seguridad de los datos
• Protección a la intemperie
• Medición de otras variables de interés

Historias de arquitectura

A continuación, presentamos un subconjunto de las historias de arquitectura del sistema MySUDS:

Ejemplo 1 (desempeño)

Cuando hago clic en la opción de buscar eventos de lluvia

Dado que la plataforma opera normalmente, pero se tiene un gran volumen de muestras de conductividad y nivel almacenadas en la base de datos

Yo como investigador quiero obtener los eventos que se encuentran dentro de un rango de fechas dado

Para que pueda visualizar todos los eventos y adquirir una percepción general de los mismos

Esto debe suceder en menos de un 1 minuto

Ejemplo 2 (escalabilidad)

Cuando un dispositivo envía datos al sistema

Dado que la plataforma opera en modo sobrecargado, por envío concurrente de datos desde 1000 dispositivos distribuidos en varios parques en una ventana de 60 min., usando conectividad de red Sigfox

Yo como diseñador quiero que los datos se almacenen correctamente

Para realizar consultas posteriores

Debe suceder que el envío y almacenamiento de los datos tarde menos de 300 milisegundos

Ejemplo 3 (integridad de la información)

Cuando un dispositivo envía datos al sistema

Dado que conectividad de red Sigfox funciona en modo degradado por lluvia

Yo como diseñador quiero que el envío de los datos se repita 3 veces

Para mitigar potencial pérdida de información

Debe suceder que se pierda a lo sumo 10% de los datos colectados por los dispositivos

Ejemplo 4 (confidencialidad)

Cuando un dispositivo envía datos al sistema

Dado que la plataforma opera normalmente y se tiene conectividad de red Sigfox

Yo como IDRD quiero que los datos viajen de forma segura

Para que no puedan ser leídos por terceras partes

Debe suceder que todos los datos transmitidos viajan encriptados

Ejemplo 5 (estética)

Cuando se instalen los dispositivos en un parque

Dado que la plataforma opera normalmente

Yo como IDRD quiero asegurar el correcto funcionamiento de los dispositivos

Para que se inicie el monitoreo de la eficiencia del canal de drenaje

Debe suceder que los dispositivos se protejan de la intemperie mientras se integran a la estética del parque

Ejemplo 6 (robustez)

Cuando se instalen los dispositivos en un parque

Dado que la plataforma opera normalmente

Yo como IDRD quiero asegurar el correcto funcionamiento de los dispositivos

Para que se inicie el monitoreo de la eficiencia del canal de drenaje

Debe suceder que los dispositivos son capaces de funcionar en un ambiente a la intemperie y con humedad elevada

Ejemplo 7 (eficiencia energética)

Cuando se inicie un evento de lluvia

Dado que la batería de un dispositivo está al 10%

Yo como diseñador quiero que se active el mecanismo de alimentación alternativo (paneles solares)

Para que se asegure el envío de datos

Debe suceder que la alimentación alternativa perdure hasta que el evento de lluvia termine, teniendo en cuenta que un evento de lluvia en el parque dura 1 hora en promedio

Ejemplo 8 (interoperabilidad)

Cuando un dispositivo envía datos al sistema

Dado que la plataforma opera normalmente

Yo como diseñador quiero que las peticiones sean procesadas por el backend

Para que se asegure la recepción y almacenamiento de los datos

Esto debe suceder con peticiones provenientes de tarjetas NodeMCU.

Ejemplo 9 (control de actuadores)

Cuando se detecte el evento de inicio de lluvia (es decir, el promedio de las mediciones de agua del pluviómetro en los últimos 30 minutos es mayor a 30 milímetros)

Dado que el sistema opera normalmente

Yo como IDRD quiero que se accionen las compuertas para encauzar el agua hacia el parque

Para evitar inundaciones en la inmediaciones del parque

Esto debe suceder a lo sumo 5 minutos después de detectado el evento

Identificar dilemas éticos del proyecto y su mitigación

El desvío del caudal del río aledaño al parque para evitar inundaciones trae consigo los siguientes dilemas:

• Aumento de presencia de insectos por agua estancada en el parque.
• Se prohíbe el uso total o parcial del parque.
• Posibles malos olores.
• Zonas inseguras.

Se mitigan los dilemas éticos diseñando el canal de tal forma que solo se desvía la cantidad de agua del río aledaño que puede absorber el suelo del parque en un tiempo de 6 horas, de tal forma que no se genera estancamiento de agua por largos períodos de tiempo y por lo tanto se evita presencia de insectos y malos olores en el parque. Minimizando así las restricciones al uso del parque por parte de los ciudadanos.

Diseño del sistema IoT

La figura que sigue ilustra los principales elementos de la arquitectura de MySUDS. Son tres dispositivos de capa física: uno en la cámara de entrada, uno en la cámara de salida y uno en el techo de una construcción del parque que detecta el inicio de lluvia. Los dispositivos se conectan a la capa de datos (que corre en la nube) a través de antenas Sigfox. Una capa de aplicación Web permite la visualización y explotación de los datos. Esto será detallado a continuación.

Figura 5. Principales elementos de arquitectura del sistema IoT

Diseño de la Capa de Dispositivos del Sistema IoT

A continuación se enuncian las principales decisiones a tener en cuenta en el diseño de la Capa de Dispositivos del Sistema.

Variables de monitoreo

Teniendo en cuenta la priorización de requisitos funcionales de alto nivel las variables mínimas a monitorear son las siguientes:

• Medición de la intensidad de una precipitación
• Medición de nivel del agua en las cámaras
• Medición de conductividad del agua en las cámaras

Definición de sensores

Después de realizar una revisión de los sensores disponibles en el mercado se definieron los siguientes sensores para ser implementados en el sistema:

• Medición de la intensidad de una precipitación: Con el objetivo de estimar los niveles de precipitación de manera continua, se seleccionó el pluviómetro de balancín, marca Davis modelo número 7857M. Este pluviómetro se compone por un embudo colector de lluvia, enganchado a una base plástica con mecanismo de inclinación, cuenta con un filtro para impedir la entrada de desechos y púas de seguridad para evitar la llegada de aves.

Internamente, el pluviómetro se compone por un data logger Easy log, modelo EL- USB-5 y dos cazoletas dispuestas en un mecanismo basculante. Durante un evento de lluvia, cada vez que una de las cazoletas se llena, se emite un pulso y se registra la hora en el data logger; así mismo por efecto de la gravedad, el mecanismo basculante gira y se dispone la otra cazoleta vacía para la medición. El volumen asociado a cada cazoleta es de 0.2 mm de precipitación. El área de recolección es de 214 𝑐𝑚2 , puede registrar de 0.0 a 999.8 mm de lluvia diaria y su exactitud es del ±4% para lluvias de hasta 50 mm/ hora y del ±5% para lluvias entre 50 y 100 mm/hora.

El pluviómetro debe quedar nivelado, por lo que cuenta con una burbuja de nivel que requiere permanecer centrada. Por otra parte, el data logger cuenta con una batería cuya duración aproximada es de 1 año y una capacidad de almacenamiento de hasta 32510 datos.

• Medición de conductividad del agua en las cámaras: La medición de conductividad se realizó con la sonda Global Water WQ-Cond-1, que utiliza 4 electrodos para la adquisición de datos en forma continua. Esta sonda está indicada para su uso en ríos y aguas subterráneas, para lo que cuenta con una carcasa resistente, un metro de cable entre el sensor y el módulo de interfaz y 25 pies de cable para conectar al dispositivo de recolección de datos. Trae incorporado un sensor de temperatura para compensar automáticamente la medición de conductividad en un 2%/°C, normalizada a 25°C. Igualmente, un módulo de interfaz en línea convierte los datos digitales de conductividad y temperatura en dos señales separadas de 4 a 20 mA para el registro de datos.

La exactitud de la sonda es del ±0.5% para las mediciones de conductividad y del ±0.2% para temperatura, y cuenta su resolución es de 0.1µS y 0.01°C.

• Medición del nivel del agua en las cámaras: Esta medición se realizó con la sonda Global Water WL705, la cual utiliza tecnología de medición de distancia por ultrasonidos para un control preciso del nivel de agua sin contacto. Esta sonda está indicada para su uso en canalizaciones, vertederos, aguas residuales, y/ o en flujo de canal abierto, para este fin el sensor contiene un transductor robusto en una carcasa sellada de acero inoxidable para una larga vida útil y proporciona una salida de 4 a 20 mA.

La exactitud de la sonda es del ±0.5%, su resolución es de 0.02286 cm y tiene una velocidad de actualización de 50 ms.

Definición de frecuencia de muestreo

Teniendo en cuenta que en evento de lluvia en el parque San Cristobal dura habitualmente 1 hora y que la cantidad de mensajes disponibles ofrecidos por el operador de SigFox en Colombia son 140 mensajes disponibles por día, se estimó que los mensajes deben ser envíados cada 1 minuto cuando se inicia un evento de lluvia.

Definición de actuadores

Al detectarse un evento de lluvia se debe habilitar la apertura de una compuerta que desvíe el caudal del río al sistema de drenaje urbano, para este fin se planea la utilización de un actuador hidráulico para activar la válvula de apertura de la compuerta.

Definición de la forma de conexión de los dispositivos de borde

Los dispositivos de monitoreo, tanto en el canal como en el techo, se comunicarán directamente a la red SigFox. Para este fin se utilizará una Antena DVK-SFUS-1-GEVK SigFox en cada uno de los dispositivos conectados a una placa de desarrollo NodeMCU, la cual también nos facilita la integración de los sensores seleccionados.

Definición de gateway

Para este desarrollo no se requiere la instalación de un gateway que nos ayude con la recolección y procesamiento de los datos ya que todos los dispositivos de monitoreo se conectarán directamente a la red SigFox.

Diseño de la Capa de Red del Sistema IoT

Selección de las Tecnologías de Comunicación para la Capa de Red

Para el caso específico de este proyecto se seleccionó la tecnología SigFox dado que la universidad tiene un acuerdo con el operador de la red en Colombia y se quería realizar una prueba de concepto del funcionamiento de esta red en Bogotá.

Selección del Protocolo IoT para la Capa de Red

La siguiente tabla muestra una comparación de algunas de las características a tener en cuenta de los protocolos que podrían ser utilizados en el despliegue del sistema IoT propuesto.

Para esta implementación se escogió el protocolo MQTT ya que tiene una cabecera con un menor tamaño generando una menor sobrecarga de datos en las transmisiones; ofrece unas características de calidad de servicio que garantizan una menor pérdida de mensajes entre la capa física y la nube; y permite transmisión asíncrona.

Diseño de la Capa de Datos del Sistema IoT

• Recolección de datos:
• Frecuencia de envío: una vez iniciado un evento de lluvia, los dispositivos envían mediciones de conductividad y nivel a la nube cada minuto
• Formato: se envía un mensaje de 12 bytes en ASCII (este tamaño es impuesto por SigFox). La información que iba en el mensaje variaba de acuerdo con el propósito. Había tres propósitos posibles: reportar una medición, una alarma o un healthcheck. Cuando se reportaba una medición iba: la magnitud colectada (nivel de agua en canal, nivel de agua en pluviómetro o conductividad), el tipo de señal (e.g., digital, analógica, pulso) y el canal de entrada donde se conecta el sensor al NodeMCU. El tipo de alarma que se reportaba era el inicio de un evento de lluvia. El healthcheck servía para identificar si el dispositivo estaba funcionando correctamente.
• Seguridad: para evitar riesgos de seguridad de suplantación de dispositivos cada antena Sigfox se autentica con la nube usando una clave y cada mensaje contiene un token para garantizar que viene de una antena Sigfox previamente autenticada.
• Limpieza: En este proyecto sí se hace limpieza de medidas de nivel de agua con valor cero. Estas aparecen súbitamente (por ejemplo, pasando de 10 a 0 cm) y son incoherentes porque siempre hay agua en el canal mientras llueve. Las mediciones anómalas se deben a basuras que se fijan a los sensores. Decidimos que sea la capa de datos la que elimina valores de nivel de agua incoherentes ya que es esta capa la que sabe si un evento de lluvia se ha iniciado. Los dispositivos que tienen los sensores de nivel y conductividad no tienen pluviómetro por lo tanto los primeros no tienen conocimiento del inicio de un evento de lluvia
• Almacenamiento: los datos se almacenan en una base relacional y una no relacional de series de tiempo. Se escoge la relacional para guardar los metadatos del dominio que tienen una menor proyección de crecimiento de registros (por ej., usuarios). Se escoge la base de series de tiempo para almacenar las mediciones las cuales tienen una mayor dinámica de crecimiento con respecto a los otros datos. Las bases de datos de series de tiempo son flexibles de forma que la estructura de los datos puede cambiar en el tiempo con facilidad. Además, pueden almacenar un volumen alto de información de forma agregada lo que optimiza las consultas. La figura que sigue muestra el modelo de datos del proyecto. En la base de series de tiempo se está almacenando la entidad "Measurement" que contiene el tipo de medición (ya sea nivel, conductividad, lluvia), el valor y el momento en el tiempo en que se tomó la medición. También, esta entidad tiene una referencia al sensor que tomó la medición. Note que la información completa de los sensores se encuentra en la base relacional, esto implica que los diseñadores de la solución deben manejar las relaciones entre las diferentes fuentes de datos que se están usando. Adicionalmente, la base relacional tiene las entidades "User, "Sensor, Event". "User" sirve para almacenar información general de los usuarios del sistema, la cual es particularmente útil para el envío de notificaciones. "Sensor" almacena información de los dispositivos IoT, distinguiendo los que están en la entrada del canal de los que están en la salida. Por último, "Event" representa un evento de lluvia cuyos atributos indican el momento exacto del inicio y fin de lluvia. Cuando un evento de lluvia termina, el sistema calcula y guarda indicadores (por ej., duración, volumen, picos) para posterior consulta.

Fig. 6 Modelo de datos del sistema

• Procesamiento de datos: se hace analítica descriptiva a través de visualizaciones que permiten, por ejemplo, comparar el nivel de agua lluvia versus el nivel de agua entrante y saliente del canal para saber el nivel de eficiencia del mismo. Esto se implementa a través de un procesamiento en streaming. En particular, se usa un Bróker MQTT que recibe las mediciones desde los dispositivos y las propaga al componente que almacena los datos en la base de datos de series de tiempo. Cuando el modelo de datos cambia automáticamente se actualizan las visualizaciones.

Diseño de la Capa de Aplicación del Sistema IoT

Lógica

• Procesamiento de eventos: se implementó a través de un bróker de mensajería, un ejemplo de evento sigue: si el nivel de agua > X entonces envíe mensaje SMS a los investigadores. Este evento está asociado al requisito de envío de notificaciones a los interesados.
• Servicios: los diagramas de componentes y despliegue que aparecen más abajo muestran cada uno de los servicios del sistema y sus relaciones. Un bróker de mensajería sirve de intermediario entre los dispositivos y los servicios. Unos servicios tienen acceso a los diferentes tipos de persistencia y otros son consumidos por la interfaz gráfica. Vale la pena resaltar que todos los componentes se despliegan en una nube pública y que los dispositivos alcanzan internet a través de la tecnología Sigfox. A continuación, sigue una breve descripción de cada servicio:
• Reception: coloca los mensajes enviados por los dispositivos en un tópico particular del bróker de mensajería, teniendo en cuenta el tipo de mensaje, ya sea medición, alarma o healthcheck.
• Crude data: consume los mensajes de tipo " medición" del bróker y los almacena los datos en la base de datos de series de tiempo.
• Event manager: consume los mensajes de tipo "alarma (inicio o fin de lluvia)" del bróker. Cuando se trata de un "inicio de lluvia" se registra en la base de datos. Cuando se trata de un "fin de lluvia" se actualiza el estado del evento de iniciado a finalizado en la base de datos.
• Notification manager: consume los mensajes de tipo "alarma" y "healthcheck del bróker", los formatea y envía a los usuarios por SMS.
• Aggregated data: consume los mensajes de tipo "alarma (fin de lluvia)" del bróker. Cuando esto sucede, el componente primero consulta la base de datos buscando el evento cuyo ID coincida con el que viene en el mensaje. Después de eso, el componente calcula todos los indicadores y metadatos del evento de lluvia, a partir de las mediciones asociadas que están almacenadas en la base de datos de series temporales.
• Historical serving: maneja todas las solicitudes de los clientes web que quieren consumir la información que está en las bases de datos.

Fig. 7 Diagrama de componentes

Fig. 8 Diagrama de despliegue

• Seguridad: para proteger la capa de aplicación los usuarios deben autenticarse y autorizarse utilizando un servicio tercerizado (i.e., Auth0). Una vez autenticado, el cliente web recibe un token que es usado para asegurar el envío de las próximas peticiones de negocio. El token tiene un tiempo de duración que al vencerse impone una nueva fase de "inicio de sesión" al usuario. Se prefirió un servicio tercerizado sobre uno propio para evitar hacer todo el desarrollo del componente de seguridad desde cero.

Interfaz gráfica

• Visualización: MySUDS ofrece un tablero de control web y la opción de descargar reportes. El tablero de control ofrece dos ayudas visuales que se aprecian de forma consolidada en el mockup que sigue:

Fig. 9 Mockup de MySUDS

• Visualización 1: muestra cifras consolidadas de un evento de lluvia en curso, por ej., duración de un evento, fecha y hora de inicio y fin, pico en los flujos de agua entrantes y salientes asociados al canal. Esta visualización puede ayudar a tomar decisiones inmediatas como el cierre temporal de la zona del parque donde está la cuneta, si el evento de lluvia es más largo de lo normal y el SUD no está absorbiendo el agua con la velocidad habitual. Esta visualización es usada por los administradores del parque.
• Visualización 2: contiene una gráfica de barras (en azul) y de línea (rojo) en un mismo plano. El eje de las X representa el tiempo. El eje de las y de la izquierda representa la cantidad de agua que entró al canal. Finalmente, el eje de las Y de la derecha representa el flujo del agua que sale del canal. Esta visualización ayuda a comparar el nivel de agua lluvia versus el nivel de agua entrante y saliente del canal para saber el nivel de eficiencia de dicho canal. Esta visualización es usada por los investigadores que construyeron el canal.
• Explicación del Mockup: se aplicaron las siguientes buenas prácticas:
• Distribución de la información: note que lo primero en aparecer en pantalla es la información "real time" (visualización 1 y 2) la cual soporta la toma de decisiones inmediatas. Por otro lado, se puede acceder al menú "historic" para descargar los reportes de mediciones colectadas en un cierto rango de fechas.
• Fuentes: note que se definieron fuentes para: títulos principales, opciones del menú/títulos de visualización y datos
• Colores: se escogieron 3 colores para el tablero (adicionales al fondo que es blanco), a saber: negro para las fuentes, azul y rojo para la gráfica
• Tipos de visualización: se escogieron visualizaciones estándar. La primera agrupa texto que habla del evento de lluvia en curso. La segunda mezcla un histograma y un diagrama de línea
• Uso de computación de borde/niebla: no se contempló la necesidad de este tipo de computación porque se quería probar la calidad de servicio (e.g., seguridad, disponibilidad) de Sigfox para unir la capa física y los servicios de nube

[1] M. P. Molina León, L. Gutiérrez y J. Salazar, «Sistemas Urbanos de Drenaje Sostenible,» Secretaria Distrital de Ambiente Subidrección de Ecourbanismo y gestión ambiental empresarial, Bogotá D.C., 2011.

[2] «Hidrología Sostenible,» [En línea]. Available: http://www.hidrologiasostenible.com.

[3] «LA NETWORK,» [En línea]. Available: https://la.network/techos-verdes-bajan-la-temperatura-en-clima-tropical/.

[4] S. Ramadhin, S. Anand, R. Aishwarya y R. Yogitha, «Smart drainage and health monitoring system of manual scavenger using IoT,» de 5th International Conference on Intelligent Computing and Control Systems, Madurai, India, 2021.

[5] M. Pérez Rubi y J. Hack, «Co-design of experimental nature-based solutions for decentralized dry-weather runoff treatment retrofitted in a densely urbanized area in Central America,» Springer, nº Ambio 50, p. 1498–1513, 2021.

[6] Noticiasrcn.com. "En la localidad de San Cristóbal alertan por crecimiento y desbordamiento del río Fucha". Disponible en: https://www.noticiasrcn.com/bogota/bogota-alertan-por-crecimiento-y-desbordamiento-del-rio-fucha-384132 (accedido el 4 de abril de 2022).

Versión 1.0