La posición correcta en el momento equivocado
Un camión pierde la señal a las diez de la mañana y la recupera a las doce. En cuanto vuelve, manda dos cosas a la vez: las posiciones que guardó sin señal y las que genera en ese momento. Todas son correctas. Si la plataforma no distingue unas de otras, mezcla la historia con el presente.
Una posición puede ser técnicamente correcta y, aun así, provocar una decisión operativa equivocada si se interpreta fuera de su contexto temporal. De eso trata esta nota.
Durante años trabajamos con rastreo GPS, telemetría y equipos embebidos, por redes celulares GSM/GPRS y por LoRaWAN. En movilidad no se puede suponer que la comunicación será permanente. Lo importante no es sólo cuánto tiempo se desconecta un equipo, sino cómo se comporta mientras y qué pasa cuando vuelve.
Las cifras de los ejemplos son ilustrativas: salen de un simulador con una jornada supuesta de una flota, no de mediciones de nuestras plataformas.
No es un equipo conectado a una base de datos
La forma más sencilla de pensar la telemetría es un equipo que manda datos y una base de datos que los guarda. Con esa idea, guardar y reenviar parece un problema del equipo: que tenga memoria suficiente y que mande lo que guardó.
Nuestra evolución ha sido dejar de pensarlo así. Hoy lo vemos como un sistema distribuido donde cada etapa tiene su responsabilidad: recibir, confirmar, transportar, almacenar, interpretar y presentar. El problema no termina cuando el equipo consigue reenviar su información. También importa lo que la plataforma hace con ella.
Del lado del equipo, además, no hay una regla general. Cómo guarda, cuánto le cabe y qué hace cuando se llena depende del fabricante, del firmware y del modelo. Unos guardan y transmiten después; otros tienen límites de memoria o configuraciones propias. Hay que validarlo equipo por equipo.
Tres horas distintas para el mismo dato
Cada posición tiene tres momentos:
- Cuándo se generó, en el equipo.
- Cuándo la recibió el servidor.
- Cuándo quedó disponible para la operación, ya procesada.
En una jornada sin fallas, las tres caen casi juntas. Después de una desconexión, se separan: una posición generada a las 11:30 puede llegar a las 12:00 y, con la cola del servidor llena, quedar disponible hasta cuatro minutos después.
El reloj del equipo también merece atención. Con GPS, el equipo puede tomar la hora del sistema de posicionamiento, pero no todos mantienen una hora confiable en cualquier condición. Y si la hora del evento no es confiable, todo lo que se construya encima tampoco.
Confirmar no es procesar
Cuando un equipo vuelve a tener señal, no necesariamente llega todo, en orden y sin repetidos. Eso depende del protocolo y de cómo se implementó. En integraciones por TCP con protocolos como JT808, hay que entender sus mecanismos de secuencia, confirmación y retransmisión.
Y hay una diferencia crítica: que el gateway confirme que recibió un mensaje no significa que toda la plataforma ya lo procesó y lo guardó. Si una confirmación se pierde, el equipo vuelve a mandar lo mismo, y el servidor tiene que aceptar el repetido sin crear registros ni eventos duplicados.
Reconocer un repetido tampoco es trivial. No basta con que coincidan el equipo y la hora. Tampoco basta el número de secuencia: en JT808 es de dos bytes y vuelve a empezar en cero, así que se repite. Lo correcto es idempotencia por protocolo y tipo de evento: un identificador único del mensaje cuando lo hay y es confiable, y claves compuestas cuando hace falta.
Algunos protocolos ayudan desde la recepción. En JT808, el envío de posiciones en bloque, el mensaje 0x0704, dice si son posiciones normales o guardadas en una zona sin cobertura. Con esa marca, el gateway puede reconocer la historia desde que llega. La marca va por bloque, y hay equipos que mandan lo guardado como posiciones normales, sin ella. Si cada modelo de equipo y cada versión de firmware la usan es algo que hay que validar, no suponer.
Aceptar conexiones no es procesarlas
No es lo mismo recibir una posición de cada equipo a intervalos regulares que recibir de golpe todo lo atrasado de muchos equipos mientras siguen entrando las posiciones actuales. Aceptar conexiones TCP es una capacidad; procesar y guardar todo lo recibido es otra.
En el simulador, una flota de 50 equipos manda una posición por minuto durante ocho horas. A las 10:00 se cae la red para 41 de ellos durante dos horas. Cada equipo guarda hasta 100 posiciones y, al llenarse, tira la más vieja. Al volver, manda lo presente sin esperar y reenvía lo guardado a dos registros por segundo, y el 2 % de las confirmaciones se pierde. La plataforma procesa 10 mensajes por segundo, doce veces la carga normal de la flota.
La señal vuelve a las 12:00, y en menos de un minuto la cola del servidor llega a 3,634 mensajes; la espera, a 6.1 minutos. En esa cola, 63 posiciones actuales esperaron más de cinco minutos detrás de la historia acumulada de la flota. En el camino se perdieron 843 posiciones porque la memoria se llenó, llegaron 436 repetidos por confirmaciones perdidas y 1,728 llegadas fueron fuera de orden.
Más memoria no lo arregla todo. En la misma jornada, con 500 posiciones por equipo no se pierde nada, pero la avalancha crece: la cola llega a 4,406 mensajes y 139 posiciones actuales esperan más de cinco minutos.
Historia o presente
Lo más delicado no es sólo perder información. Es recibir información válida fuera de su contexto temporal.
Si la plataforma trata todo lo que llega como si pasara ahora, la historia se mezcla con el presente, y eso pega en recorridos, reportes, geocercas, alarmas e indicadores. Con una geocerca es muy claro: si un vehículo entró a una zona restringida hace tres horas y la posición apenas llega al servidor, no tiene sentido una alerta que diga que acaba de entrar.
En el simulador hay 194 entradas y salidas reales de una geocerca en la jornada. Una plataforma que trata todo como “ahora” da 240 alertas: 140 a tiempo, 54 de cosas que pasaron hace rato avisadas como si pasaran en ese momento, y 46 falsas, de historia y repetidos que se mezclan con el presente y hacen que el equipo parezca entrar y salir. Además, guarda los 436 repetidos. Esas falsas dependen de cómo reenvía el equipo: si todo sale en orden, bajan a 30; sin confirmaciones perdidas, a 16; con las dos cosas, a cero.
Una plataforma que separa historia y presente descarta los repetidos, guarda la historia en su lugar y sólo avisa lo presente. Da 156 alertas: 140 a tiempo y 16 tardías que dicen que son tardías. Ninguna falsa, aunque eso es por construcción: el simulador sólo trae las fallas que le pusimos. Y el recorrido, reconstruido con la hora de cada posición, recupera bien fechadas 186 de las 194 entradas y salidas; a las 8 que faltan les borró el registro la memoria llena del equipo, y eso ya no lo arregla ninguna plataforma.
Lo que haría hoy
Tratar la desconexión como condición normal, no como excepción. El diseño empieza suponiendo que la comunicación va a fallar.
Separar las responsabilidades en capas:
- Recepción: aceptar, validar e identificar los mensajes del equipo.
- Mensajería: desacoplar la comunicación del procesamiento con colas.
- Persistencia: guardar de forma idempotente, sin duplicados.
- Procesamiento temporal: distinguir lo histórico de lo actual.
- Reglas de negocio: evaluar geocercas, alarmas y condiciones operativas respetando el contexto temporal.
- Presentación: mostrar bien tanto el último estado conocido como el historial.
Guardar la hora del evento y la hora de recepción por separado. La posición histórica conserva su hora original, si es válida, y la recepción se registra aparte. Así se reconstruye el recorrido sin alterar la cronología.
Distinguir una condición actual de un evento histórico detectado después. Lo histórico reconstruye el recorrido; lo actual dispara alertas. Si algo pasó sin señal y se descubre al volver, se registra como lo que es.
Medir dónde se atora. Separar recepción, cola y procesamiento permite ver en qué punto del flujo se produce un retraso, en vez de adivinarlo.
En nuestras arquitecturas actuales trabajamos con gateways de recepción, RabbitMQ, servicios de procesamiento, bases de datos y distribución de eventos con Socket.IO. Eso desacopla la recepción del procesamiento, aunque por sí solo no garantiza que un equipo haya conservado todo durante la desconexión.
Para probarlo con otra flota, otra caída de la red, otra memoria u otro ritmo de proceso, está el simulador de guardar y reenviar: corre en el navegador y compara las dos plataformas con las tres horas de cada dato.
Recibir información no es lo mismo que recibir información oportuna, y procesar correctamente un mensaje no garantiza que lo estemos interpretando en el contexto temporal adecuado. Una buena plataforma de telemetría no sólo soporta que los equipos se desconecten: recupera su historia sin confundirla con el presente.
Israel Negrete Lepe es ingeniero en electrónica. Veinticinco años haciendo que sistemas distintos funcionen juntos en condiciones reales: del sensor, el vehículo o la transacción al backend, los datos, la seguridad y la operación. Hoy, cada vez más, IA en el borde.