Lógica de viagens personalizada na Navixy: configure regras para cada frota

Configure os parâmetros padrão de viagem da Navixy para corresponder à forma como uma frota específica opera, sem construir um pipeline de dados separado. Leia a história completa para saber como ajustar as regras de viagem, validar o resultado, versionar a lógica e reutilizá-la em diferentes implementações de clientes.

A maioria dos softwares de telemetria oferece uma entidade de viagem pronta. A plataforma decide quando o movimento começa, quanto tempo uma parada pode durar, quando uma viagem se transforma em duas, e quais movimentos são muito curtos para contar. Para uma frota rodoviária padrão, esses valores predefinidos geralmente funcionam bem. O desafio surge quando uma frota opera de forma diferente.

• O equipamento de construção pode se deslocar apenas 50 metros entre áreas de trabalho.
• Uma rota de entregas pode incluir várias paradas de seis minutos que ainda devem pertencer a uma única corrida de entrega.
• Outro cliente pode se importar muito mais com o deslocamento do Armazém A ao Cliente B do que com as coordenadas exatas de início e fim da viagem.

É aqui que a lógica de viagens configurável se torna útil. Com o IoT Query, a plataforma de análise da Navixy, TSPs e integradores de sistemas podem aproveitar a transformação de viagens existente e adaptar a forma como a telemetria bruta é agregada em viagens. O fluxo de trabalho pode ser mantido em YAML, versionado, reutilizado em diferentes implementações e ajustado sem reconstruir um pipeline de dados separado para cada cliente.

Para demonstrar o fluxo de trabalho de forma mais clara e transparente, usamos o Transformation Builder, uma ferramenta visual para projetar fluxos de transformação de dados. Ele ajuda a ver como cada etapa se conecta à próxima, onde regras específicas são aplicadas e como os dados de viagem resultantes são gerados.

Como a Navixy transforma telemetria bruta em viagens personalizadas

Um rastreador GPS envia coordenadas, velocidade, marcas de tempo, estados do dispositivo e outras telemetrias. Uma viagem só aparece depois que a plataforma aplica um conjunto de regras a esses dados. Essa distinção importa porque é exatamente aí que a personalização acontece.

Em forma simplificada:

Telemetria bruta → Detecção de movimento → Limites da viagem → Validação da viagem → Contexto de negócio

O IoT Query começa com a telemetria na camada de dados brutos. A transformação padrão de viagens então converte esses pontos em registros de viagem estruturados, com limites, duração, distância e outras métricas calculadas. Por isso, a transformação padrão precisa de um conjunto de regras predefinidas.

Por exemplo, ela usa um limite de estacionamento de cinco minutos, um tempo limite de 20 minutos para lacunas de dados, além de critérios mínimos de velocidade e distância para distinguir movimento real de ruído de GPS. São suposições razoáveis para muitas frotas, mas não são universais.

Se a definição operacional de viagem do cliente for diferente, você pode manter a transformação existente e alterar apenas a lógica que não se aplica mais. O modelo resultante continua simples:

Telemetria bruta → Lógica de transformação configurável → Conjunto de dados analítico personalizado

O fluxo de trabalho modificado pode gravar o resultado em processed_custom_data, enquanto a transformação padrão da Navixy continua sendo executada separadamente.

Isso também torna os testes mais seguros: não é necessário substituir o conjunto de dados de viagens padrão só para validar outra definição.

Três casos de uso para a lógica de viagens personalizada na Navixy via IoT Query

A forma mais simples de ver onde a lógica de viagens personalizada se torna útil é observar operações em que as suposições padrão para frotas rodoviárias não se aplicam mais.

Detectar viagens curtas de 50 metros em equipamentos pesados

Frotas de construção e equipamentos pesados são um bom exemplo, porque as limitações das suposições padrão para frotas rodoviárias ficam evidentes rapidamente. Imagine equipamentos se movendo em um canteiro de obras. Uma carregadeira pode se deslocar de 50 a 80 metros entre áreas de trabalho, em baixa velocidade.

Um filtro de viagens padrão pode razoavelmente tratar isso como ruído de GPS. Para essa operação, no entanto, trata-se de um movimento real que o cliente pode querer analisar. Simplesmente reduzir o limite final de distância não é suficiente. Os pontos subjacentes primeiro precisam ser classificados como movimento.

Por exemplo, a lógica de Moving Status pode ser ajustada de um limite de 3 km/h para 1 km/h, permitindo variações de distância menores:

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 é um trecho do fluxo de trabalho, não uma configuração completa, mas mostra a ideia básica: o comportamento da viagem é controlado por configuração legível e lógica SQL.

Os critérios de validação final devem então seguir a mesma definição:

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

Aqui, a velocidade mínima passa de 3 km/h para 1 km/h, enquanto a distância mínima de viagem passa de 100 metros para 30. A telemetria recebida não mudou; o que mudou foi a interpretação dela.

Há, no entanto, uma troca importante: quando os limites de movimento são reduzidos, aumenta a chance de a deriva do GPS ser classificada como uma viagem real. Antes de agendar o fluxo de trabalho em produção, compare os resultados com um conjunto de movimentos de equipamentos já conhecidos. Na prática, essa validação é mais útil do que tentar encontrar um limite teoricamente “correto”.

Manter as paradas de entrega dentro de uma única viagem

Operações de entrega criam um desafio diferente. Uma rota de entregas pode incluir dezenas de paradas curtas. Se uma entrega leva seis minutos em vez de quatro, um limite de estacionamento de sete minutos pode dividir em duas viagens o que o negócio considera uma única rota. Nesse caso, não há motivo para redesenhar o fluxo de trabalho.

Aumentar o limite de estacionamento de 300 para 600 segundos pode ser suficiente para manter essas paradas dentro da mesma viagem. Se lacunas de conectividade também estiverem fragmentando a rota, o limite de lacuna de dados pode ser ajustado da mesma forma.

Uma regra útil aqui é partir do fluxo de trabalho existente e alterar o menor número possível de suposições. Isso facilita validar e manter o resultado. Também facilita explicar a configuração depois, quando alguém perguntar por que as viagens desse cliente se comportam diferente do modelo padrão.

Adicionar contexto de negócio às viagens

Os limites são apenas um tipo de personalização. As coordenadas em si raramente são o que um despachante, analista ou cliente realmente quer ver.

Um registro como 55.7558, 37.6173 → 55.7412, 37.6231 é preciso, mas a pergunta operacional provavelmente é outra: o caminhão saiu do armazém e chegou ao local do cliente?

Um fluxo de trabalho personalizado pode comparar as coordenadas de início e fim da viagem com geofences em processed_common_data.zones_geom e adicionar campos como:

Campo	Significado
start_zone	Geofence que contém o início da viagem
end_zone	Geofence que contém o fim da viagem

A viagem resultante agora pode dizer: Armazém → Local do cliente, sem exigir que outra ferramenta de BI ou aplicativo reconstrua esse contexto depois.

Nesse ponto, o fluxo de trabalho faz mais do que ajustar a detecção de viagens: ele molda a entidade analítica de acordo com a forma como a operação do cliente realmente funciona.

Essa mesma abordagem pode ser estendida com informações do motorista, estados de sensores, zonas operacionais ou outros dados de negócio disponíveis na implementação.

Por que gerenciar fluxos de viagem personalizados como YAML

O grafo visual é útil quando você quer entender o fluxo de trabalho. O YAML se torna útil quando é preciso gerenciar esse fluxo de trabalho como um ativo de engenharia.

Todo fluxo de transformação pode ser exportado como YAML. A configuração descreve os nós, parâmetros, conexões e a programação por trás da transformação. Para equipes que constroem soluções semelhantes repetidamente, isso traz quatro vantagens práticas:

1. Versionar a lógica. Em vez de alguém trocar 300 por 600 em uma interface e ninguém lembrar por quê três meses depois, o YAML pode viver no Git. A mudança se torna um diff normal, com histórico e revisão.
2. Reutilizar uma implementação validada. Se você já construiu a lógica de viagens para um tipo de frota de construção, você tem um ponto de partida muito mais sólido para o próximo cliente com operações semelhantes.
3. Mover fluxos de trabalho entre implementações. A mesma configuração pode ser importada para outra conta Navixy em vez de ser reconstruída nó por nó.
4. Trabalhar com a configuração de forma programática. Como o fluxo de trabalho é texto estruturado, scripts e ferramentas de IA podem inspecioná-lo e modificá-lo diretamente. Essa opção está se tornando especialmente útil para integradores de sistemas.

Como ferramentas de IA podem trabalhar com configurações de viagem em YAML

Depois que a transformação existe como texto estruturado, usar IA se torna muito mais direto. Em vez de tentar explicar um fluxo de trabalho visual a um assistente, você pode fornecer o YAML exportado junto com um requisito operacional concreto.

Por exemplo: Este é nosso fluxo de trabalho de Trips atual. Este cliente opera equipamentos de construção que se deslocam regularmente de 30 a 80 metros a 1–2 km/h. Quais nós e limites estão atualmente impedindo que esses movimentos sejam classificados como viagens?

Um assistente de IA pode identificar os nós relevantes e sugerir mudanças.

Um gerador de fluxo de trabalho pode ir além e devolver um arquivo YAML atualizado.

Um agente autônomo poderia, em princípio, assumir uma parte maior do ciclo: ler a configuração, modificá-la, executar o fluxo de trabalho e comparar o resultado com um conjunto de viagens já conhecido.

Há uma limitação importante. O YAML explica como o fluxo de trabalho funciona. Ele não explica como a operação do cliente funciona. Antes de pedir a uma ferramenta de IA para modificar a lógica de viagens, dê a ela o contexto operacional necessário.

Sem esse contexto, uma ferramenta de IA pode produzir um YAML perfeitamente válido que ainda assim codifica a lógica de negócio errada.

Por isso, a IA é mais útil aqui como forma de acelerar o trabalho de configuração, e não como substituto para entender a operação da frota.

Para um passo a passo mais técnico desses casos de uso, incluindo os nós e parâmetros exatos envolvidos, riscos de validação, considerações de agendamento, padrões de edição de YAML e recomendações para assistentes e agentes de IA, veja Analistas de dados → Casos de uso na documentação da Navixy.

Como reutilizar a lógica de viagens personalizada entre clientes

Para um TSP ou integrador de sistemas, a lógica de viagens personalizada se torna especialmente valiosa quando clientes diferentes operam em condições muito distintas. Os dados de telemetria subjacentes podem ser os mesmos; a definição analítica, porém, não precisa ser. Você também não precisa reconstruir a pilha de análise para cada implementação.

Comece com uma transformação existente. Altere as suposições que importam. Valide o resultado com base no comportamento real da frota. Mantenha o YAML resultante sob controle de versão. Reutilize-o quando a próxima implementação tiver um requisito semelhante.

Viagens são um exemplo conveniente, mas o mesmo princípio se aplica a agregações de sensores, eventos de motorista, métricas de veículo e outras entidades analíticas. A oportunidade mais ampla é controlar como os dados brutos de telemetria se transformam em dados que a operação do seu cliente pode realmente usar.

Tem um caso de uso de cliente que não se encaixa na lógica de viagens padrão? Fale com a gente para discutir como construir e manter uma transformação personalizada no IoT Query.