Lógica de viajes personalizada en Navixy: configure reglas para cada flota

Configure los parámetros estándar de viaje de Navixy para que coincidan con la forma de operar de una flota específica, sin construir un pipeline de datos independiente. Lea la historia completa para descubrir cómo ajustar las reglas de viaje, validar el resultado, versionar la lógica y reutilizarla en distintas implementaciones para clientes.

La mayoría de los software de telemática ofrecen una entidad de viaje ya definida. La plataforma decide cuándo empieza el movimiento, cuánto puede durar una parada, cuándo un viaje se convierte en dos, y qué movimientos son demasiado cortos para contar. Para una flota de carretera estándar, esos valores predeterminados suelen funcionar bien. El desafío aparece cuando una flota opera de forma diferente.

• El equipo de construcción puede desplazarse solo 50 metros entre áreas de trabajo.
• Una ruta de mensajería puede incluir varias paradas de seis minutos que, aun así, deberían formar parte de un mismo recorrido de entrega.
• A otro cliente puede importarle mucho más el hecho de moverse del Almacén A al Cliente B que las coordenadas exactas donde empezó y terminó el viaje.

Aquí es donde la lógica de viajes configurable se vuelve útil. Con IoT Query, la plataforma de análisis de Navixy, los TSP y los integradores de sistemas pueden tomar la transformación de viajes existente y adaptar cómo se agrega la telemetría bruta para formar viajes. El flujo de trabajo se puede mantener como YAML, versionarlo, reutilizarlo en distintas implementaciones y ajustarlo sin reconstruir un pipeline de datos independiente para cada cliente.

Para mostrar el flujo de trabajo de forma más clara y transparente, usamos Transformation Builder, una herramienta visual para diseñar flujos de transformación de datos. Ayuda a ver cómo se conecta cada paso con el siguiente, dónde se aplican reglas específicas y cómo se genera finalmente el dato de viaje.

Cómo Navixy convierte la telemetría bruta en viajes personalizados

Un rastreador GPS envía coordenadas, velocidad, marcas de tiempo, estados del dispositivo y otra telemetría. Un viaje aparece solo después de que la plataforma aplica un conjunto de reglas sobre esos datos. Esta distinción importa porque esas reglas son, precisamente, el punto donde ocurre la personalización.

En forma simplificada:

Telemetría bruta → Detección de movimiento → Límites del viaje → Validación del viaje → Contexto de negocio

IoT Query parte de la telemetría en la capa de datos sin procesar. La transformación estándar de viajes convierte luego esos puntos en registros de viaje estructurados, con límites, duración, distancia y otras métricas calculadas. Por eso, la transformación estándar necesita un conjunto de reglas predeterminadas.

Por ejemplo, utiliza un umbral de estacionamiento de cinco minutos, un tiempo de espera de 20 minutos para huecos de datos, y criterios mínimos de velocidad y distancia para distinguir el movimiento real del ruido del GPS. Son suposiciones razonables para muchas flotas, pero no son universales.

Si la definición operativa de viaje del cliente es distinta, puede conservar la transformación existente y cambiar solo la lógica que ya no se ajusta. El modelo resultante sigue siendo simple:

Telemetría bruta → Lógica de transformación configurable → Conjunto de datos analítico personalizado

El flujo de trabajo modificado puede escribir el resultado en processed_custom_data, mientras la transformación estándar de Navixy sigue ejecutándose por separado.

Esto también hace que las pruebas sean más seguras: no es necesario reemplazar el conjunto de datos de viajes estándar solo para validar otra definición.

Tres casos de uso para la lógica de viajes personalizada en Navixy con IoT Query

La forma más sencilla de ver dónde resulta útil la lógica de viajes personalizada es observar operaciones en las que las suposiciones estándar para flotas de carretera ya no se cumplen.

Detectar viajes cortos de 50 metros en maquinaria pesada

Las flotas de construcción y la maquinaria pesada son un buen ejemplo, porque las limitaciones de las suposiciones estándar para flotas de carretera se hacen evidentes rápidamente. Imagine equipos moviéndose dentro de una obra. Una cargadora puede desplazarse entre 50 y 80 metros entre áreas de trabajo a baja velocidad.

Un filtro de viajes estándar puede considerar razonablemente eso como ruido del GPS. Sin embargo, para esta operación se trata de un movimiento real que el cliente puede querer analizar. Simplemente reducir el umbral final de distancia no basta. Primero hay que clasificar los puntos subyacentes como movimiento.

Por ejemplo, la lógica de Moving Status (estado de movimiento) se puede ajustar de un umbral de 3 km/h a 1 km/h, y permitir cambios de distancia más cortos:

version: 2
name: Generate Trips (no zones)

cte_nodes:
  - id: custom_5
    type: custom
    label: Moving Status
    sources: [filter_1]
    params:
      custom_sql: |-
        SELECT *,
          CASE
            WHEN speed >= 1
              AND (distance_meters > 10 OR is_moving = 1)
              THEN 'moving'
            ELSE 'stopped'
          END AS moving_status
        FROM filter_1

Este es un fragmento del flujo de trabajo, no una configuración completa, pero muestra la idea básica: el comportamiento del viaje se controla mediante configuración legible y lógica SQL.

Los criterios de validación final deben seguir entonces la misma definición:

HAVING COUNT(*) >= 2
   AND MAX(w.speed) >= 1
   AND ROUND(ST_Length(...)) >= 30

Aquí, la velocidad mínima pasa de 3 km/h a 1 km/h, y la distancia mínima de viaje, de 100 metros a 30. La telemetría que llega no ha cambiado; lo que cambió es su interpretación.

Sin embargo, hay una contrapartida importante: al bajar los umbrales de movimiento, aumenta la probabilidad de que la deriva del GPS se clasifique como un viaje real. Antes de programar el flujo de trabajo en producción, compare los resultados con un conjunto de movimientos de equipo ya conocidos. En la práctica, esa validación es más útil que intentar encontrar un umbral teóricamente “correcto”.

Mantener las paradas de mensajería dentro de un mismo viaje

Las operaciones de mensajería plantean un desafío distinto. Una ruta de entrega puede incluir docenas de paradas cortas. Si una entrega tarda seis minutos en lugar de cuatro, un umbral de estacionamiento de siete minutos puede dividir en dos viajes lo que el negocio considera una sola ruta. En este caso, no hay motivo para rediseñar el flujo de trabajo.

Aumentar el umbral de estacionamiento de 300 a 600 segundos puede bastar para mantener estas paradas dentro del mismo viaje. Si los huecos de conectividad también fragmentan la ruta, el umbral de hueco de datos se puede ajustar de la misma manera.

Una regla útil aquí es partir del flujo de trabajo existente y cambiar el menor número de suposiciones posible. Eso facilita validar y mantener el resultado. También facilita explicar la configuración más adelante, cuando alguien pregunte por qué los viajes de este cliente se comportan diferente al modelo estándar.

Añadir contexto de negocio a los viajes

Los umbrales son solo un tipo de personalización. Las coordenadas en sí rara vez son lo que un despachador, un analista o un cliente finalmente quiere ver.

Un registro como 55.7558, 37.6173 → 55.7412, 37.6231 es preciso, pero la pregunta operativa suele ser otra: ¿el camión fue del almacén al sitio del cliente?

Un flujo de trabajo personalizado puede comparar las coordenadas de inicio y fin del viaje con geocercas en processed_common_data.zones_geom y añadir campos como:

Campo	Significado
start_zone	Geocerca que contiene el inicio del viaje
end_zone	Geocerca que contiene el final del viaje

El viaje resultante puede ahora decir: Almacén → Sitio del cliente, sin necesitar otra herramienta de BI o aplicación que reconstruya ese contexto después.

En este punto, el flujo de trabajo hace algo más que ajustar la detección de viajes: está dando forma a la entidad analítica según cómo funciona realmente la operación del cliente.

Ese mismo enfoque se puede extender con información del conductor, estados de sensores, zonas operativas u otros datos de negocio disponibles en la implementación.

Por qué gestionar los flujos de viaje personalizados como YAML

El grafo visual es útil cuando se quiere entender el flujo de trabajo. El YAML se vuelve útil cuando hay que gestionar ese flujo de trabajo como un activo de ingeniería.

Todo flujo de transformación se puede exportar como YAML. La configuración describe los nodos, los parámetros, las conexiones y la programación detrás de la transformación. Para los equipos que construyen soluciones similares una y otra vez, esto ofrece cuatro ventajas prácticas:

1. Versionar la lógica. En lugar de que alguien cambie 300 por 600 en la interfaz y nadie recuerde por qué tres meses después, el YAML puede vivir en Git. El cambio se convierte en un diff normal, con historial y revisión.
2. Reutilizar una implementación validada. Si ya construyó la lógica de viajes para un tipo de flota de construcción, cuenta con un punto de partida mucho más sólido para el siguiente cliente con operaciones similares.
3. Mover flujos de trabajo entre implementaciones. La misma configuración se puede importar a otra cuenta de Navixy en lugar de reconstruirla nodo por nodo.
4. Trabajar con la configuración de forma programática. Como el flujo de trabajo es texto estructurado, los scripts y las herramientas de IA pueden inspeccionarlo y modificarlo directamente. Esta opción resulta cada vez más útil para los integradores de sistemas.

Cómo pueden trabajar las herramientas de IA con configuraciones de viaje en YAML

Una vez que la transformación existe como texto estructurado, usar IA resulta mucho más directo. En lugar de intentar explicarle un flujo de trabajo visual a un asistente, puede entregarle el YAML exportado junto con un requisito operativo concreto.

Por ejemplo: Este es nuestro flujo de trabajo actual de Trips. Este cliente opera maquinaria de construcción que se desplaza habitualmente entre 30 y 80 metros a 1–2 km/h. ¿Qué nodos y umbrales están impidiendo actualmente que esos movimientos se clasifiquen como viajes?

Un asistente de IA puede identificar los nodos relevantes y sugerir cambios.

Un generador de flujos de trabajo puede ir más allá y devolver un archivo YAML actualizado.

Un agente autónomo podría, en principio, encargarse de una parte mayor del ciclo: leer la configuración, modificarla, ejecutar el flujo de trabajo y comparar el resultado con un conjunto de viajes ya conocido.

Hay una limitación importante. El YAML explica cómo funciona el flujo de trabajo, no cómo funciona la operación del cliente. Antes de pedirle a una herramienta de IA que modifique la lógica de viajes, dele el contexto operativo que necesita.

Sin ese contexto, una herramienta de IA puede producir un YAML perfectamente válido que, aun así, codifique la lógica de negocio equivocada.

Por eso, aquí la IA resulta más útil como una forma de acelerar el trabajo de configuración, no como un sustituto para entender la operación de la flota.

Para un recorrido más técnico de estos casos de uso, incluidos los nodos y parámetros exactos, los riesgos de validación, las consideraciones de programación, los patrones de edición de YAML y recomendaciones para asistentes y agentes de IA, consulte Analistas de datos → Casos de uso en la documentación de Navixy.

Cómo reutilizar la lógica de viajes personalizada entre clientes

Para un TSP o un integrador de sistemas, la lógica de viajes personalizada se vuelve especialmente valiosa cuando distintos clientes operan bajo condiciones muy diferentes. Los datos de telemática subyacentes pueden ser los mismos, pero la definición analítica no tiene por qué serlo. Tampoco es necesario reconstruir la pila de analítica para cada implementación.

Parta de una transformación existente. Cambie las suposiciones que importan. Valide el resultado frente al comportamiento real de la flota. Mantenga el YAML resultante bajo control de versiones. Reutilícelo cuando la siguiente implementación tenga un requisito similar.

Los viajes son un ejemplo conveniente, pero el mismo principio se aplica a agregaciones de sensores, eventos del conductor, métricas del vehículo y otras entidades analíticas. La oportunidad más amplia es controlar cómo los datos de telemática brutos se convierten en datos que la operación de su cliente realmente puede usar.

¿Tiene un caso de uso de cliente que no se ajusta a la lógica de viajes estándar? Contáctenos para hablar sobre cómo construir y mantener una transformación personalizada en IoT Query.