Challenge #2 - G-Corzo/DetectorNivelAgua GitHub Wiki

Monitoreo IoT para Gestion de Agua en la Region Sabana Centro, Embalse de Tomine (Challenge #2)

Asignatura: Internet de las Cosas | Universidad de La Sabana
Integrantes: Samuel Borda Munevar, Juan Jose Gomez Saavedra, Gabriel Alejandro Corzo Fernandez
Video Demostrativo

Resumen Ejecutivo

Esta nueva entrega se desarrolla con el proposito principal de mejorar el dispositivo mediante fallas encontradas durante las pruebas y evaluacion de este durante el Challenge #1. Junto a esto, se busca la implementacion de conexiones con el dispositivo ESP32 con un servidor embebido, incluyendo su seguridad de acceso, reporte de datos historicos relevantes, despliegue inicial, desarrollo de pruebas categoricamente relevantes, y aseguracion fisica. Los cambios principales identificados de las fallas evaluativas caen dentro de:

  • Fallas al adaptarse al ambiente local
  • Componentes e metricas mal configurados
  • Componentes faltantes para calculos adicionales

🌎 1. Motivacion y Justificacion 🌎

Motivacion

Durante la evaluacion inicial del sistema, se identificaron varias areas de desarrollo donde se puede mejorar el resultado para un mejor desempeño del sistema y dispositivo relacionado, evitando menos falsos positivos o falsos negativos. Junto a esto, se identifico una necesidad de enfocar los desarrollos en el area especifica de desarrollo, donde previamente solo se desarrollo con funcionalidad sin tener presente las caracteristicas del sitio a instalar las unidades.

Justificacion

Debido a los problemas identificados durante la evaluacion del Challenge #1, junto a la falta de conexion del dispositivo, solo reportando los datos detectados in-site, se determino que el dispositivo no puede funcionar sin las correcciones y mejoras propuestas, a menos de asegurar un mal funcionamiento del sistema, haciendo el objetivo del proyecto nulo.

🧰 2. Solucion Propuesta 🧰

Restricciones de Diseño

  • Economicas: El precio por unidad operativa es la prioridad principal para ser una opcion viable para la region de foco; no debe sacrificar funcionalidad basica, pero puede admitir un margen de precision menor.
  • Espaciales: El lugar de despliegue va a ser el embalse de Tomine; la estructura fisica de la unidad debe estar diseñada para sostenerse y seguir funcionamiento durante eventos climaticos en esa ubicacion.
  • Escalables: La unidad debe ser pequeña, y en simultaneo facil de instalar en la ubicacion de interes.
  • Tecnicas: Cada unidad debe tener la capacidad de mantener un servidor embebido y conectarse con otros dispositivos de interes permitidos; debe hacer esto mientras se mantiene funcionamiento mediante una bateria.

Arquitectura Propuesta

La arquitectura propuesta sigue la misma dinamica general del diseño anterior; mismas conexiones de hardware, con unas adicionales debido a componentes nuevos. Junto a eso, se diseño la estructura del software de manera que tenga funcionalidad completa pero sin uso excesivo energetico por parte del ESP32.

Desarrollo Teorico Modular

  • Criterios de Diseño: Los criterios de diseño se enfocan en 4 aspectos especificos, y son la primera prioridad al hacer una modificacion:

    • Costos: El precio unitario de cada dispositivo fabricado debe ser lo mas bajo posible, y su precio de mantenimiento/reemplazo debe concordar con esa dinamica; las areas donde se piensan implementar no pueden soportar el presupuesto de sistemas avanzados y mantenimiento constante que viene con estos, mucho menos para despliegues en varios puntos simultaneos.
    • Efectividad: El dispositivvo debe captar toda la informacion relevante con precision y frecuencia suficiente para permitir una respuesta rapida e informada sobre situaciones de sequia o de inundacion.
    • Resistencia en el Tiempo: El diseño debe resistir los factores ambientales de la ubicacion durante tiempos prolongados, sin monitoreo constante, ni una alimentacion de poder constante, funcionando mediante cargas de bateria pequeñas
    • Tamaño: El dispositivo debe ser lo mas pequeño posible al diseñar, para facilitar la facilidad de construccion, instalacion y transportacion entre ubicaciones de despliegue.

  • Diagramas UML: Describen tanto el diseño como el funcionamiento de los componentes. Recuerda que el data-sheet de cada componente se encuentra dentro del repositorio, en la carpeta de DOCUMENTACION, y se debe consultar al hacer alguna modificacion al sistema para verificar su correcta modificacion e implementacion.

⚙️3. Configuracion Experimental.⚙️

Esta seccion consiste de la configuracion y desarrollo de pruebas del dispositivo, junto a sus resultados esperados y desempeño

Calibracion de Sensores

Para cada sensor, se ideo una calibracion de este, de manera que no se tiene que recurrir a equipos de calibracion costosos para calibrar el sistema:

  • Distancia - HC-SR04: Se bloquea fisicamente el lector en su punto mas cercano con una superficie plana, y se enciende el sistema; los datos reportados deben ser 0 o extremadamente cerca a cero (tolerancia establecida de 1e-6).
  • Temperatura/Humedad - DHT22: Se inicializa el sistema dentro de una habitacion termicamente controlada y conocidamente seca, o previamente afectada por un deshumificador, y se reportan los datos; los datos reportados por el sensor deben ser los mismos reportados por la habitacion, con humedad cerca de 0% (tolerancia de .5°C y .05% HR).
  • Presion - BMP280: Al iniciar, se debe reportar la presion atmosferica habitual de la zona (750 a 755 hPa), con una tolerancia de 5 hpa.
  • Rad. Solar - GL55: El LDR se debe bloquear con una superficie plana, y al encenderse, debe leer su voltaje minimo, ya que deberia estar reportando su resistencia maxima.

Emulacion de Condiciones Reales

Para emular las condiciones del sitio de operacion, se simula las condiciones de alerta del sitio mediante:

  • Distancia: Se aleja la superficie de medicion del lector, simulando la disminucion del nivel del agua dentro del sistema.
  • Temperatura/Humedad: Se aumenta la temperatura/sequedad del aire de medicion mediante una herramienta como un secador de pelo.
  • Rad. Solar: Se inicializa el sistema con el LDR en completa oscuridad; lentamente, se va descubriendo el LDR para simular el ciclo solar.

Umbrales de Alerta y Notificaciones

Para los umbrales de alerta, se dividieron en 3 estados generalizados; actualmente no utilizan datos historicos, solo datos presentes dentro de la lectura actual:

  • Normal: Nivel del agua mayor a 55% del rango establecido (RE), junto a riesgo de evaporacion menor a 55%.
    • En este estado, solo esta activo el LED verde, el buzzer esta apagado y no se envian notificaciones a los usuarios conectados.
  • Alerta: Nivel del agua entre 55% y 30% del RE, o riesgo de evaporacion entre 55% y 70%.
    • En este estado, se activan el LED amarillo, con un buzzer intermitente, con notificaciones correspondientes a los usuarios conectados al servidor.
  • Critico: Nivel del agua menor del 30% del RE, o riesgo de evaporacion mayor a 70%.
    • En este estado, se activan el LED rojo, y el buzzer se vuelve continuo. con notificaciones correspondientes a los usuarios conectados al servidor.

Pruebas de Robustez

Dentro del desarrollo de nuestro dispositivo, hay 2 situaciones de estres que el dispositivo debe resistir:

  • Desconexion y Reconexion: Cualquier dispositivo desconectado debe tener la capacidad de volver a conectarse dentro de un marco de 20 segundos, incluso si esta al borde del rango operacional del dispositivo.
  • Seguridad del Dispositivo: Se regulo el acceso al dispositivo mediante 2 capas de seguridad para acceder a los datos del dispositivo: una capa de acceso a una red establecida, y otra capa de verificacion adicional antes de acceder al sitio localhost. Adicionalmente, la red queda como un airlock, ya que deja a posibles atacantes registrados, mientras que los datos quedan aisolados.

Repetibilidad y Desempeño

El sistema debe tener la capacidad de repetir el proceso de recopilacion y reporte de datos de mediciones durante un periodo minimo de 8 horas; el dispositivo debe sostener este funcionamiento a su capacidad completa durante su uso mediante una bateria 3V de 5000mAh, y sobreviviendo el tiempo indicado.

📜 4. Conclusiones 📜

El desarrollo del proyecto aborda varias mejoras tanto de plantacion del objetivo como de funcionamiento para el entorno de despliegue, haciendo el dispositivo mucho mas adaptado para su ambiente, y mucho mas capaz del desarrollo de la tarea propuesta, todo sin aumentar significativamente el costo de creacion y despliegue por unidad.

Retos Presentados

  • Impresion de PCB y Cascaron 3D: Debido al periodo de tiempo donde se desarrollo el proyecto (semana de parciales para la mayoria de universidades), junto a la indisponibilidad de los sistemas de impresion 3D propios de la universidad, tanto la PCB diseñada para el sistema como su cascaron 3D externo para resistir factores ambientales fueron retrasados, impidiendo su entrega durante la sustentacion actual. Quedan como desarrollo futuro del sistema.

Trabajo futuro

Como se planteo previamente, la implementacion del PCB y cascara 3D del sistema quedan como desarrollos futuros garantizados, junto a la implementacion de un sitio en la nube para el reporte de datos, en vez de un sitio local del ESP32. Algunos desarrollos futuros posibles son pruebas de campo de tiempo extendido dentro del ambiente de prueba (embalse de Tomine), para evaluar si se activa durante una situacion de sequia real, aunque no es garantizable que se genere una situacion durante el periodo de pruebas.

🔺 5. Mejoras Respecto al Challenge #1 🔺

  • Mejor Adaptacion al Ambiente de Desarollo: Comparado con el Challenge #1, que era el desarrollo de un sistema de deteccion generico y no adaptado, el sistema actual esta configurado y diseñado para adaptarse tanto a las metricas del area, junto a sus variaciones y condiciones ambientales, para maximizar el valor del desarrollo realizado del sistema.
  • Implementacion de Evaporacion Potencial: Utilizando la radiacion solar obtenida con el nuevo sensor LDR, se logro la implementacion del calculo de la evaporacion potencial, junto a su evaluacion de riesgo potencial y desarrollo de umbrales de alerta relacionados.

🤖 6. Usos de Inteligencia Artificial 🤖

  • Se consulti Gemini Pro 3.1
  • Lo que se pregunto: "Mediante los data-sheets adjuntos, mas el diagrama del circuito adjunto, desarrolla diagramas de formato UML sobre el funcionamiento del sistema y cada uno de los componentes. Desarrolla los diagramas en codigo de Mermaid para pegar dentro de LucidChart.", junto a los anexos de los datasheets presentes en la carpeta DOCUMENTACION.
  • Se verifico mediante el software del programa ya hecho, junto a revisiones manuales de los data-sheets de cada uno de los componentes.
  • Desarrollo de la wiki estimado: 2%

📜 7. Anexos y Enlaces 📜

  • Código Fuente: Carpeta "CODIGO Y SIMULACIONES", ver guia de descarga para ejecutar el dispositivo
  • Esquemáticos y Material Extra: Carpeta "DOCUMENTACION", todos los componentes tienen sus esquematicos presentes, y se tiene una guia de asambleaje para el dispositivo
  • Video Demostrativo: Video demostrativo del sistema en funcionamiento
  • Acceso a la Wiki: Esta Wiki está alojada en GitHub y se encuentra en estado de acceso publico.