Drogheda/00-Project-Management/client-comms/2026-06-20_Actualizacion-Confiabilidad-Backend_ICAVE.md

85 lines
4.0 KiB
Markdown

# Actualización de Confiabilidad — Plataforma de Telemetría HBOX
**Proyecto Drogheda (GPS-RTK) · Backend / Servidor**
Helgen Technologies · 20 de junio de 2026 · Preparado para ICAVE — Hutchison Ports
---
## Resumen ejecutivo
A raíz de las desconexiones reportadas, realizamos un **análisis de causa raíz del
backend** (el servidor que recibe la telemetría de las unidades y la reenvía a Wialon).
Identificamos y **corregimos tres causas de raíz en el software del servidor** que estaban
sacando unidades de Wialon — incluyendo casos en los que **la unidad transmitía
correctamente pero la plataforma la descartaba**.
**Las tres correcciones ya están desplegadas en producción y verificadas.** La
ruggedización de la electrónica de campo, el PCB de producción y el manejo térmico del
gabinete avanzan **en paralelo**, como frentes independientes.
## Lo que se observó en campo
- La flota completa se desconectaba prácticamente **al mismo tiempo**.
- Unidades que "morían" y **no regresaban** a Wialon, aun estando encendidas y transmitiendo.
## Causa raíz (en el backend, no en el radio)
1. **Bloqueo en cadena.** El servidor enviaba a Wialon y esperaba la confirmación dentro del
mismo hilo en que recibía los datos de toda la flota. Un solo envío lento, o un enlace
superior intermitente, **congelaba la recepción de todas las unidades a la vez** → explica
la caída simultánea de la flota.
2. **Filtro "anti-salto" demasiado rígido.** Descartaba saltos de posición grandes, pero **sin
actualizar su punto de referencia**: una unidad que se movía mientras estaba desconectada
(o con un primer dato atípico) quedaba **bloqueada de forma permanente** — transmitía bien,
pero ya nunca volvía a aparecer.
3. **Identidad por dirección IP bajo CGNAT.** El operador celular agrupa muchas SIM detrás de
una misma IP pública; al identificar por IP, el servidor **confundía unas unidades con
otras**, generando saltos falsos y mezcla de datos.
## Hallazgo clave
Confirmamos que **varias unidades reportadas como "muertas" estaban en realidad EN LÍNEA y
transmitiendo correctamente**: la falla estaba en el backend, no en su hardware. Esto nos
permite separar con certeza las fallas de software de las de campo.
## Correcciones desplegadas
- **Procesamiento concurrente:** el reenvío a Wialon ya no bloquea la recepción. Una unidad
lenta o un enlace superior caído **ya no afecta al resto de la flota**.
- **Filtro anti-salto con auto-recuperación:** **nunca** bloquea de forma permanente a una
unidad sana — se re-ancla por sí solo — y sigue rechazando saltos físicamente imposibles.
- **Identidad por dispositivo (a prueba de CGNAT):** se elimina la mezcla de datos entre
unidades que comparten IP del operador.
- **Despliegue seguro:** con respaldo automático, verificación de estado y **reversión
automática** ante cualquier falla.
## Mayor visibilidad
- El tablero (**monitor.helgen.dev**) ahora distingue una **"unidad sin señal"** de una
**unidad en línea que el backend no estaba reenviando** — para no confundir un problema de
plataforma con una falla de equipo.
- Las bitácoras se envían a una plataforma en la nube (Grafana) para diagnóstico y
trazabilidad, **sin saturar el disco del servidor**.
## Validación
Pruebas de extremo a extremo que reproducen enlace superior lento, IPs compartidas (CGNAT) y
saltos de posición: **10 de 10 verificaciones aprobadas** antes de salir a producción.
## Estado y próximos pasos
| Frente | Estado |
|---|---|
| Backend / servidor (confiabilidad) | ✅ **Corregido y en producción** |
| Ruggedización de la electrónica de campo | 🔧 En proceso (paralelo) |
| PCB de producción | 🔧 En diseño (paralelo) |
| Manejo térmico del gabinete | 🔧 En proceso (paralelo) |
El backend se **rediseñó para escalar a cientos de unidades**, en línea con la meta de **30
unidades operativas para agosto**.
---
*Borrador preparado por Helgen Technologies para revisión de Leo antes de compartirse con el
cliente.*