Estado del proyecto: En desarrollo activo
Por qué nació este proyecto
Trabajo en un instituto de diagnóstico por imágenes donde conviven equipos de alta complejidad: resonadores magnéticos (MRI), tomógrafos computados (TC), gammacámaras (SPECT) y equipos de tomografía por emisión de positrones (PET). Cada uno de ellos depone condiciones ambientales y de infraestructura muy específicas para funcionar correctamente, y cualquier desvío puede traducirse en imágenes de mala calidad, tiempos de inactividad no planificados o, en el peor caso, daño en equipos cuyo costo de reposición es millonario.
Hay una frase que funciona como eje de este proyecto: “lo que no se mide no se puede mejorar”. Y durante mucho tiempo, varias variables críticas de nuestra infraestructura no se medían de forma continua ni automatizada.
Los chillers de agua son el sistema de enfriamiento de los resonadores magnéticos. Mantienen el gradiente térmico necesario para que el imán superconductor opere en condiciones estables. Si una bomba falla, si la tensión de alimentación está fuera de rango o si la temperatura del agua de enfriamiento sube sin control, el equipo puede entrar en quench —un evento en el que el helio líquido del imán se evapora bruscamente, con consecuencias técnicas y económicas muy serias.
A eso se le suma la necesidad de monitorear temperatura y humedad ambiente en las salas de gammacámara y PET, donde las condiciones del entorno afectan directamente la calidad de los estudios y la vida útil de los detectores.
Decidí encarar el desarrollo de un sistema de monitoreo propio, por etapas, desde lo más básico hasta incorporar análisis predictivo con machine learning.
Arquitectura general del sistema
El stack tecnológico elegido para este proyecto es:
- Microcontrolador: ESP32 (WiFi integrado, bajo costo, alto rendimiento para IoT)
- Base de datos de series temporales: InfluxDB
- Visualización: Grafana (dashboards en tiempo real)
- Sensores (etapa actual): DHT11, DS18B20, SCT-013 (pinza amperométrica)
La elección de ESP32 + InfluxDB + Grafana responde a un criterio de robustez, escalabilidad y costo. Es un stack ampliamente usado en monitoreo industrial y académico, con comunidad activa y documentación sólida. Grafana permite construir paneles expresivos con alertas configurables, lo que en el contexto clínico es especialmente valioso.
Etapa 1: Temperatura, humedad y corriente
Variables monitoreadas
Temperatura y humedad ambiente — sensor DHT11
El DHT11 es un sensor digital de bajo costo que mide temperatura y humedad relativa mediante un único bus de datos. En esta etapa cumple la función de validar el concepto del sistema: confirmar que los datos llegan correctamente a InfluxDB y se visualizan en Grafana. Es el punto de partida antes de incorporar sensores con mayor precisión y rango.
La principal limitación encontrada con este sensor es la limitación del rango de medición en la humedad, que por disposiciones propias del sensor se limita entre el 20% y 90%, provocando cortes en la medición de datos cuando la humedad baja o sube de este nivel:
De todas formas, esto no representa un impedimento, sobre todo en esta etapa de prototipado: niveles por debajo del 20% y por encima del 90% son atípicos.
Temperatura del agua del tanque del chiller — sensor DS18B20
El DS18B20 es un termómetro digital de precisión que opera sobre protocolo 1-Wire. Su gran ventaja es que puede sumergirse o instalarse en contacto directo con el fluido a monitorear. En este caso, se utiliza para registrar la temperatura del agua en el tanque de enfriamiento del chiller. Este dato es crítico: un aumento sostenido puede anticipar un problema en la disipación térmica mucho antes de que el equipo genere una alarma propia.
Corriente eléctrica — pinza amperométrica SCT-013 / referencia UNIT
Para esta variable se incorporó una pinza amperométrica no invasiva (tipo SCT-013) que se instala sobre el conductor sin necesidad de interrumpir el circuito. Actualmente, estoy evaluando el uso de este sensor, dado que los valores registrados no correlacionan de forma consistente con la referencia medida con una pinza amperométrica UNIT, incluso luego de hacer varios intentos de calibración por software. Este es un punto abierto en el desarrollo, que se revisará en detalle antes de avanzar a la siguiente etapa.
Nota técnica: La discrepancia en las lecturas de corriente puede deberse a la calibración del sensor, al rango de corriente del circuito bajo prueba, o a interferencias en la señal analógica. Se está evaluando migrar directamente al módulo PZEM-004T, que ofrece medición de corriente, tensión, frecuencia y factor de potencia en un solo módulo con protocolo Modbus.
Dashboard en Grafana
Las variables se visualizan en tiempo real en un panel de Grafana con resolución configurable. El panel muestra:
- Temperatura ambiente (°C)
- Humedad relativa (%)
- Temperatura del agua del tanque (°C)
- Corriente (A) — en validación
Hasta ahora el sistema cuenta con diferentes formas de visualización: gráficos de series temporales, “tacómetros” con el estado en tiempo real.
Lógica de reconexión automática — watchdog
Uno de los desafíos reales del entorno hospitalario es la inestabilidad de la red WiFi en zonas técnicas. El ESP32 puede perder conexión con el broker o con el servidor de InfluxDB, y si no hay un mecanismo de recuperación, se pierden datos y el monitoreo queda ciego.
Para resolverlo, se implementó un algoritmo de watchdog que monitorea continuamente el estado de la conexión. Ante una pérdida de enlace, el sistema intenta reconectarse de forma automática en ciclos, sin necesidad de intervención manual. Este comportamiento es fundamental para garantizar la continuidad del monitoreo en un entorno donde nadie va a estar mirando la pantalla las 24 horas.
Próximas etapas del proyecto
Etapa 2 — Monitoreo eléctrico completo (PZEM-004T)
El módulo PZEM-004T permite medir, en un único dispositivo, las siguientes variables eléctricas:
- Tensión de red
- Corriente
- Potencia activa
- Frecuencia de distribución
- Factor de potencia (cos φ)
- Energía acumulada (kWh)
Estas variables son esenciales para detectar condiciones anómalas en la alimentación de bombas y compresores: tensión fuera de rango, frecuencia inestable o factor de potencia bajo pueden indicar problemas en la red eléctrica o en la carga misma antes de que se produzca una falla.
Etapa 3 — Almacenamiento local ante pérdida de conexión
Una limitación actual del sistema es que, cuando se pierde la conexión con InfluxDB, los datos simplemente no se registran. La próxima evolución incluye implementar un buffer local en la memoria flash del ESP32 para almacenar las mediciones durante períodos de desconexión y enviarlas al servidor cuando el enlace se reestablezca.
Esto garantiza la integridad del historial de datos, lo que es especialmente importante cuando se quiere usar esa información para análisis y modelos predictivos.
Etapa 4 — Despliegue en campo
Hasta ahora el sistema estuvo operando en el taller, en condiciones controladas de prueba. El siguiente paso es instalarlo efectivamente en la sala de máquinas, en contacto real con el chiller y los tableros eléctricos. Ese paso implica también resolver el encapsulado del hardware, la alimentación del sistema y la gestión del cableado en un entorno industrial.
Etapa 5 — Machine learning para forecasting
La etapa más ambiciosa del proyecto. Una vez que el sistema lleve suficiente tiempo recolectando datos históricos, el objetivo es entrenar modelos de series temporales para hacer forecasting de las variables críticas: anticipar una posible falla térmica, detectar tendencias en la corriente que sugieran desgaste en un motor, o predecir cuándo el factor de potencia podría salir del rango aceptable.
El stack candidato para esta etapa incluye Python con librerías como Prophet o modelos LSTM sobre PyTorch, conectados al historial almacenado en InfluxDB.
Reflexiones del proceso
Este proyecto nació de una necesidad concreta: tener visibilidad sobre una infraestructura crítica. El hecho de desarrollarlo por etapas, desde los sensores más simples hasta la capa de inteligencia artificial, permite validar cada componente antes de agregar complejidad.
No todo salió como se esperaba desde el inicio. El problema con el sensor de corriente es un buen ejemplo: el desarrollo real tiene fricciones, y documentarlas es parte del proceso de ingeniería, no un fracaso. La idea es que esta bitácora refleje exactamente eso: el avance real, con sus aciertos y sus puntos abiertos.
El post se va a ir actualizando a medida que el proyecto progrese. La próxima actualización debería incluir la integración del PZEM, el primer despliegue en campo y las fotos del prototipo montado.
Leave a Reply