Gestão de frotas com telemetria IoT: arquitetura completa de rastreamento e predição

O problema real

Uma transportadora com 340 veículos em 14 estados chegou com três dores: combustível sumindo sem explicação, manutenções corretivas custando R$ 2,3 milhões por ano e zero visibilidade entre o CD e o cliente final. Planilhas existiam, mas ninguém confiava nos números.

O projeto integrou telemetria IoT de ponta a ponta, do sensor no tanque de diesel ao alerta no celular do gestor. Este post detalha a arquitetura, decisões de protocolo, detecção de fraude e manutenção preditiva. Para o app mobile, veja App offline-first para frota.

Escolha de protocolos IoT

Não existe protocolo IoT universal. Cada cenário tem restrições diferentes de energia, banda e latência.

MQTT para telemetria em tempo real

O MQTT foi a escolha para toda comunicação veículo-servidor. Motivos diretos:

• Overhead mínimo: o header do MQTT tem 2 bytes. Em conexões 2G/3G instáveis no interior do Brasil, cada byte conta.
• QoS configurável: usamos QoS 1 (at-least-once) para dados de posição GPS e QoS 2 (exactly-once) para eventos críticos como alertas de impacto.
• Publish/subscribe: o broker (EMQX) distribui mensagens para múltiplos consumers sem o device precisar saber quem está escutando.

Cada veículo publica em tópicos estruturados: frota/{empresa_id}/veiculo/{placa}/telemetria. O backend consome via subscribers dedicados.

LoRaWAN para sensores em pátios e depósitos

Nos CDs e pátios, instalamos sensores de temperatura e presença de veículo usando LoRaWAN. Esses sensores precisam durar 2 a 3 anos com uma bateria AA. LoRaWAN consome microwatts comparado ao cellular. Um gateway cobre 2 km de raio, suficiente para qualquer pátio.

Sigfox para rastreamento de ativos simples

Contêineres e reboques parados por dias receberam trackers Sigfox. A limitação (140 mensagens/dia, 12 bytes cada) não importa aqui. Um ping de GPS a cada 10 minutos basta para saber onde o ativo está. Custo baixo por dispositivo.

Arquitetura de rastreamento GPS

O pipeline de rastreamento funciona assim:

[OBD-II + GPS module no veículo]
       ↓ MQTT (QoS 1)
[EMQX Broker - 3 nós clusterizados]
       ↓
[Python consumer (asyncio + aiomqtt)]
       ↓ paralelamente:
  ├── [Redis] → cache de última posição (TTL 60s)
  ├── [TimescaleDB] → série temporal completa
  └── [Kafka] → stream para alertas e analytics
       ↓
[React frontend + Mapbox GL JS]
  → WebSocket para posição real-time
  → Camadas: posição, rota planejada, geofences, heatmap de paradas

Números de produção

Métrica	Valor
Veículos simultâneos	340
Eventos MQTT/segundo (pico)	~1.200
Latência device → mapa	< 3 segundos (4G), < 8 segundos (2G)
Retenção TimescaleDB	18 meses (compressão nativa)
Tamanho médio/evento	280 bytes
Uptime do broker EMQX	99,94% em 12 meses

O Redis guarda apenas a última posição de cada veículo. Quando o frontend abre o mapa, a primeira carga vem do Redis (~2ms). Atualizações subsequentes chegam via WebSocket.

O TimescaleDB recebe tudo: posição, velocidade, RPM, temperatura do motor, nível de combustível. Compressão nativa reduziu storage em 87%. Sem isso, seriam 42 GB/mês de telemetria.

Detecção de fraude de combustível

Desvio de combustível é problema endêmico em frotas brasileiras. Nossa detecção cruza três fontes:

1. Sensor de nível no tanque (ultrassônico, precisão de ±2%). Mede o volume real a cada 30 segundos.

2. Notas fiscais de abastecimento importadas via integração com o sistema financeiro.

3. Consumo esperado por trecho. O modelo conhece o consumo médio daquele veículo (l/km varia entre 2,8 e 4,1 dependendo do caminhão) e a distância percorrida.

O algoritmo dispara alerta quando:

• O volume abastecido na NF diverge em mais de 5% da variação medida pelo sensor no tanque.
• O consumo real entre dois abastecimentos difere mais de 15% do consumo esperado para a distância GPS.
• Há queda brusca no nível do tanque (> 10 litros em < 2 minutos) fora de um ponto de abastecimento cadastrado.

def detectar_anomalia_combustivel(veiculo_id: str, janela_horas: int = 24):
    leituras = get_leituras_tanque(veiculo_id, janela_horas)
    abastecimentos = get_abastecimentos_nf(veiculo_id, janela_horas)

    for abastecimento in abastecimentos:
        nivel_antes = leitura_mais_proxima(leituras, abastecimento.ts, delta=-300)
        nivel_depois = leitura_mais_proxima(leituras, abastecimento.ts, delta=+300)

        variacao_sensor = nivel_depois.litros - nivel_antes.litros
        variacao_nf = abastecimento.litros

        divergencia = abs(variacao_sensor - variacao_nf) / variacao_nf
        if divergencia > 0.05:
            criar_alerta(
                tipo="DIVERGENCIA_ABASTECIMENTO",
                veiculo_id=veiculo_id,
                divergencia_pct=divergencia * 100,
                dados={"sensor": variacao_sensor, "nf": variacao_nf}
            )

Nos primeiros 3 meses de operação, o sistema identificou 23 eventos de divergência confirmada. A transportadora estimou economia de R$ 180 mil/ano só em combustível recuperado.

Manutenção preditiva

Manutenção preventiva é calendário. Preditiva é dados. Trocar óleo a cada 10.000 km é preventiva. Trocar quando a análise de temperatura e viscosidade indica degradação real é preditiva.

Dados coletados via OBD-II

• Temperatura do óleo do motor: baseline por veículo, alerta quando sobe acima de 2 desvios padrão
• Padrão de RPM: aceleração agressiva constante indica desgaste prematuro de embreagem e freios
• Temperatura dos freios: sensor dedicado nos eixos dianteiros
• Tensão da bateria: queda gradual indica necessidade de troca antes da falha
• Códigos DTC (Diagnostic Trouble Codes): lidos automaticamente e correlacionados com histórico de falhas

O modelo

Usamos um Isolation Forest treinado por veículo. Cada caminhão tem seu próprio baseline (um Volvo FH 540 tem padrões completamente diferentes de um VW Constellation). O modelo recebe janelas de 1 hora de telemetria agregada e classifica como normal ou anômalo.

Quando o score de anomalia ultrapassa o threshold por 3 janelas consecutivas, o sistema gera ordem de serviço automática para inspeção.

Resultado em 12 meses: redução de 34% em manutenções corretivas e aumento de 12% na disponibilidade da frota.

Desafios reais em produção

Conectividade celular no Brasil

Rota entre Belém e Marabá (PA): 600 km com trechos de 40 minutos sem sinal. O módulo IoT no veículo tem buffer local de 2.000 eventos. Quando a conexão volta, faz flush ordenado por timestamp. O backend trata dados atrasados sem quebrar a série temporal no TimescaleDB.

Volume de dados

340 veículos a cada 15 segundos geram ~1.960 eventos/minuto em estado normal. No pico (6h-8h), sobe para 1.200 eventos/segundo. O gargalo real foi o write throughput do TimescaleDB. Resolvemos com batch inserts a cada 2 segundos via buffer no consumer Python.

Bateria dos devices

Sensores LoRaWAN nos pátios duram 28 meses em média. Módulos OBD-II usam a alimentação 12V/24V do veículo. Para veículos parados por semanas, implementamos deep sleep com wake a cada 4 horas para reportar posição e tensão de bateria.

Stack completa

Camada	Tecnologia
Frontend	React + TypeScript, Mapbox GL JS, Recharts
Backend	Python (FastAPI + asyncio), consumers MQTT dedicados
Broker IoT	EMQX (cluster 3 nós)
Banco principal	PostgreSQL 16
Série temporal	TimescaleDB (extensão PostgreSQL)
Cache	Redis 7 (posição real-time + sessões)
Streaming	Kafka (alertas e analytics assíncronos)
Modelo ML	scikit-learn (Isolation Forest), retreino semanal
Infra	AWS (ECS Fargate + RDS + ElastiCache)

O que aprendemos

Projeto de IoT em frota brasileira é projeto de infraestrutura. O código é a parte fácil. O difícil é hardware em campo, conectividade precária e motoristas que desconectam sensores. A escolha de protocolos no início determinou quase tudo: MQTT para latência baixa, LoRaWAN para bateria longa, Sigfox para custo baixo. Tentar usar um protocolo para tudo é o erro mais comum em projetos IoT de frota.