Por qué la logística de temperatura controlada necesita datos de eventos, no solo promedios

La logística de temperatura controlada se basa en una suposición: un registro limpio significa un envío seguro. No siempre es así. El envío de un distribuidor farmacéutico es rechazado. El registro parecía limpio: 18 horas a 3,2 °C. Pero el auditor encontró 20 minutos en el muelle de carga, con la puerta abierta, un pico que los informes de viaje estándar nunca detectaron. La mayoría de los sistemas muestran trayectos y umbrales. Trips Intelli, una aplicación gratuita y de código abierto de Navixy, reconstruye un viaje como este en una única línea de tiempo, con paradas, aperturas de puerta y lecturas de sensores en un solo lugar.

A menudo los datos existen, pero están repartidos en tres tablas con tres resoluciones distintas, y nada las une para reconstruir ese momento. Los datos de reclamaciones de TT Club apuntan en la misma dirección. Más de la mitad de los incidentes de temperatura controlada provienen de instrucciones de manipulación mal comunicadas y ajustes de temperatura incorrectos, mientras que las fallas o daños en los equipos representan alrededor de una cuarta parte. En este caso, el equipo de refrigeración aguantó toda la noche. La carga quedó expuesta durante 22 minutos en el muelle.

Esta publicación muestra cómo una capa de analítica puede responder a la pregunta del auditor: ¿Qué ocurrió exactamente en el muelle de carga a las 14:22?

Los cambios de estado son donde realmente fallan los envíos sensibles a la temperatura

Las directrices de la OMS sobre el almacenamiento y transporte de productos farmacéuticos sensibles al tiempo y a la temperatura (TRS 961, Anexo 9) abordan estos puntos mediante requisitos para las zonas de carga, la cualificación de las rutas de transporte y la monitorización de la temperatura durante el trayecto. En un viaje refrigerado por carretera, la carga está más expuesta en los puntos de manipulación:

• el periodo inicial de preenfriamiento,
• la carga,
• las aperturas de puerta durante la entrega,
• el tiempo de espera en paradas múltiples,
• y las retenciones en aduanas o fronteras.

Estas no son las partes del viaje en las que brilla un registrador de temperatura. Suelen ser imprevistas y fáciles de pasar por alto en los datos promediados, y es justo cuando la cadena de frío tiene más probabilidades de romperse.

La consecuencia normativa se deduce de forma lógica. Las directrices de Buenas Prácticas de Distribución de la UE (2013/C 343/01) exigen que las desviaciones de temperatura durante el transporte se comuniquen al distribuidor y al destinatario y se investiguen conforme a un procedimiento definido. El distribuidor también debe poder demostrar que los medicamentos no estuvieron expuestos a condiciones que pudieran comprometer su calidad. La GUI-0069 de Health Canada (directrices para el control ambiental de medicamentos durante el almacenamiento y el transporte) establece expectativas similares para los medicamentos en tránsito. Una media horaria que "pasa" ofrece poco a un investigador cuando la desviación duró 22 minutos.

Para los productos frescos y las cadenas de frío de grado alimentario el texto normativo difiere, pero la realidad operativa es idéntica: un envío rechazado en un centro de distribución por problemas de temperatura se investigará evento por evento, no promedio por promedio.

El problema de integración de la logística de temperatura controlada

Este es el problema concreto de datos. Un despliegue telemático moderno suele producir tres flujos: un registro de posiciones GPS, un registro de sensor de temperatura y eventos de telemetría como encendido/apagado del motor y apertura/cierre de puertas.

En la mayoría de los sistemas de flotas, estos flujos viven en tablas separadas o son consultables con resoluciones diferentes. Según la configuración del dispositivo, las lecturas de temperatura y las posiciones GPS suelen registrarse a intervalos distintos. Los eventos de puerta llevan una marca de tiempo al segundo, pero a menudo se almacenan en un esquema diseñado para alertas en tiempo real, no para la correlación posterior.

El evento de apertura de puerta que provocó la desviación está a cuatro filas de la lectura de temperatura que lo registró. Unirlos requiere conocer los límites del viaje, el contexto de geocerca de la parada y los identificadores de canal de sensor que corresponden a un compartimento de carga concreto. La mayoría de las organizaciones no hacen esta unión en absoluto, o contratan a un integrador para construirla una vez para un solo cliente y nunca la generalizan.

Ese es el vacío. No es un problema de hardware. Es un problema de arquitectura de datos.

Navixy IoT Query, una plataforma de analítica de datos, expone todo el conjunto de datos telemáticos y de negocio como una conexión PostgreSQL directa: datos de rastreo, lecturas de sensores, eventos de geocerca, estados personalizados y metadatos de viajes en un esquema que puedes consultar con SQL estándar. IoT Query hace posible la unión. Trips Intelli hace utilizable la investigación.

Qué es Trips Intelli

La aplicación Trips Intelli cubre la capa que faltaba de correlación de eventos a nivel de viaje como una aplicación integral de inteligencia de viajes. No tiene su propia capa de ingesta de datos. Se conecta a la misma superficie PostgreSQL que puede consultar cualquier usuario de Navixy con acceso a IoT Query, y ejecuta una canalización de procesamiento de varias etapas sobre esos datos para producir analíticas de viaje y registros de cumplimiento.

La decisión de arquitectura importa para quien construye: no hay una API propietaria que negociar, ningún almacén de datos intermedio que mantener y ninguna canalización de reingesta que mantener sincronizada. El procesamiento ocurre sobre datos que ya existen.

Cinco preguntas de investigación, respondidas a nivel de viaje

Un auditor de cumplimiento que revisa un envío de temperatura controlada hará una clase específica de preguntas.

No "¿Cuál fue la temperatura promedio?", sino:

• ¿Dónde estaba el vehículo cuando el sensor cruzó el umbral?
• ¿Estaba la puerta abierta en ese momento?
• ¿Fue una parada programada o una desviación no planificada?
• ¿Ha estado este conductor haciendo turnos de horas extra?
• ¿Cuál es el perfil de riesgo de este viaje en comparación con otros del mismo corredor?

Ninguna de estas preguntas puede responderse solo con una tira de temperatura y un registro GPS. El cumplimiento de la cadena de frío debe entenderse en el contexto de todo el viaje, no como un gráfico de temperatura aparte. Trips Intelli está diseñado para reunir ruta, temperatura, eventos de puerta, paradas y estado del viaje en el mismo contexto de investigación.

Segmentación de viajes con estacionamiento clasificado. La canalización segmenta cada flujo de posiciones en viajes y paradas, clasifica cada parada como MOVING, PARKING o ENGINE_ON_PARKING, y le añade duración y contexto de geocerca. Una parada de 22 minutos en el muelle de carga de un centro de distribución es un evento distinto y etiquetado, no un hueco en el rastreo GPS.

Cumplimiento del corredor de ruta. Cada viaje se coteja con un corredor de ruta definido. Las desviaciones se clasifican por tipo: fuera de ruta, parada no autorizada, con el tramo y la marca de tiempo de la salida. También pueden calificarse por gravedad, ayudando a los analistas a distinguir una desviación menor del corredor de un evento que requiere investigación inmediata. Un conductor que hizo un desvío no planificado por el patio de un almacén sin refrigeración es un caso distinto de un conductor que se detuvo en un cross-dock programado.

Monitorización de umbrales de sensor en contexto de geocerca. La temperatura, el nivel de combustible, la humedad o cualquier sensor disponible en el esquema de IoT Query puede monitorizarse frente a umbrales mín./máx. configurables. La alerta incluye la lectura del sensor, la marca de tiempo y la geocerca en la que se encontraba el vehículo en ese momento. Esto significa que puedes responder "¿La desviación ocurrió durante la carga en el Almacén de Origen B, o durante el tránsito?" con una única consulta en lugar de una unión manual.

Correlación del estado de la puerta con la ubicación y la temperatura. Los eventos de apertura de puerta se correlacionan con la posición del vehículo y la lectura de temperatura en la misma marca de tiempo. En lugar de revisar gráficos separados, un investigador puede seguir una línea de tiempo multicapa que combina temperatura, estado de la puerta, posición en ruta y estado del viaje en una sola vista. Puedes ver, por ejemplo, que la temperatura subió de 3 °C a 11 °C durante un evento de puerta abierta de 14 minutos en las coordenadas [x, y], mientras el vehículo estaba fuera de su corredor de ruta previsto. Esa es la clase de secuencia que una investigación normativa necesita reconstruir.

Puntuación de anomalías con ML y explicación en texto claro. Cada viaje recibe una puntuación de riesgo de un modelo IsolationForest entrenado con el propio historial de viajes de la flota. Los viajes anómalos aparecen con una explicación en texto claro: "Fuera de turno / Nocturno", "Duración inusual para este corredor" o "Patrón de desviación de sensor incoherente con la ruta". Un analista puede priorizar investigaciones sin leer cada registro en bruto. La puntuación es un indicador probabilístico; un viaje señalado merece revisión, no una conclusión adversa automática.

Conoce más sobre los distintos niveles de informes de viajes en Navixy.

La vista que convierte la telemetría en bruto en un registro de investigación

La vista principal de la aplicación es una tabla de viajes con un panel de filtros, un mapa incrustado y una línea de tiempo de estados. Un responsable de cumplimiento que revisa un envío señalado puede filtrar por desviación de sensor, evento de puerta o desviación de ruta, seleccionar el viaje y ver la línea de tiempo reconstruida completa en una sola vista: posición GPS, canal de temperatura, estado de la puerta y marcadores de eventos anotados. La exportación a XLSX es de un solo clic.

Esta es la interfaz que utiliza realmente la persona que presenta una respuesta normativa o negocia una reclamación con un transportista. El desarrollador que la construyó trabaja en la capa de consultas; el responsable de cumplimiento que la usa trabaja en la capa de eventos. Ambos miran los mismos datos.

Resultados por rol: qué cambia realmente

Trips Intelli produce un único registro a nivel de viaje, correlacionando datos de GPS, sensores y eventos en una sola vista. Lo que cambia es la parte del registro que lee cada rol.

Para el responsable de cumplimiento: una desviación de temperatura puede rastrearse hasta el evento concreto de carga o de puerta que la causó, con marca de tiempo, ubicación y duración. Las BPD de la UE y la GUI-0069 de Health Canada exigen exactamente esto antes de una decisión de disposición. Antes, el registro se ensamblaba manualmente a partir de tres sistemas; ahora es una única vista filtrada.

Para el despachador: los viajes fuera de turno, los conductores con horas extra y las rutas fuera del corredor aparecen en la misma tabla que las desviaciones de temperatura. Un conductor que hace un turno nocturno en un corredor de entrega farmacéutica y un conductor con una parada no autorizada en una tienda de conveniencia son ambos visibles sin extraer informes por separado de un sistema aparte.

Para el gestor de flota: las puntuaciones de anomalías con ML hacen manejable la revisión semanal. Una flota de 200 vehículos genera 1.400 viajes por semana. Leer cada registro no es una opción. Los 12 primeros por puntuación de riesgo, revisados el lunes por la mañana, capturan los incidentes que requieren atención, incluidos aquellos en los que el registro de temperatura habría parecido correcto.

Para el integrador de sistemas que construye sobre la pila: el esquema de IoT Query que consulta es el mismo esquema disponible para cualquier desarrollador que construya sobre Navixy. Añadir un nuevo canal de sensor, un umbral específico de una normativa o un corredor de ruta específico de un cliente es un cambio de configuración y, en algunos casos, una modificación de SQL.

Trips Intelli produce el registro y la clasificación de riesgo. No certifica el cumplimiento, no garantiza la aceptabilidad de un envío ni sustituye la decisión de disposición que corresponde a una persona cualificada conforme a la normativa aplicable.

Primeros pasos con Trips Intelli: el esquema ya está ahí

IoT Query es la superficie de conexión PostgreSQL que consulta Trips Intelli. Si la operación de logística de temperatura controlada del cliente ya funciona con datos de flota de Navixy (posiciones GPS, lecturas de sensores, eventos de geocerca), el esquema ya está ahí. No necesitas construir una capa de ingesta.

Este es exactamente el tipo de problema con el que ya se están topando tus propios clientes: un envío rechazado con pruebas endebles, un equipo de cumplimiento haciendo preguntas que los datos de flota aún no pueden responder. Trips Intelli te da una respuesta lista: una solución que puedes poner ante cualquier cliente que mueva carga sensible a la temperatura, sin construir tú mismo la lógica de correlación de eventos.

Es una cosa más que puedes ofrecer a un cliente sin añadir trabajo de ingeniería.