Depois de validar a viabilidade financeira do Projeto Atlas, a LogiTrack avança para a etapa mais técnica: escolher os dispositivos e protocolos de comunicação que farão a arquitetura IoT funcionar na prática. O plano de negócios convenceu o conselho, mas agora o desafio é físico. É hora de transformar planilhas e diagramas em sinais reais trafegando pela rede.

Na reunião inicial da semana, Marina Costa, engenheira de software, abre o cronograma de implementação com um alerta:

“O que definirmos aqui vai determinar a confiabilidade do sistema. Escolher o protocolo errado pode significar dados perdidos, atrasos e sensores que param no meio da estrada.”

A equipe técnica se reúne no laboratório da LogiTrack, apelidado internamente de Base Atlas. Sobre a mesa, há três kits de desenvolvimento: um com módulo LoRa, outro com Wi-Fi e o último com 4G/LTE. Cada tecnologia apresenta vantagens e limitações. LoRa oferece grande alcance e baixo consumo de energia, mas pouca largura de banda. Wi-Fi é barato, mas limitado a curtas distâncias. Já o 4G garante cobertura nacional, mas implica custo mensal por chip e maior consumo elétrico.

Pedro Nascimento, coordenador de TI, defende o uso de 4G nos caminhões de longa distância, enquanto Marina propõe LoRa para rotas regionais e depósitos. “Não existe solução única”, afirma ela. “Nosso sistema precisa ser híbrido: usar o que cada ambiente oferece de melhor.” O grupo decide testar ambas as opções em campo, com gateways configurados para redirecionar dados conforme a rede disponível.

O segundo debate gira em torno do protocolo de comunicação entre dispositivos e servidor. Marina apresenta duas alternativas principais: MQTT (Message Queuing Telemetry Transport) e HTTP (HyperText Transfer Protocol). Ela explica que o MQTT é ideal para IoT porque trabalha com publicação e assinatura de tópicos, permitindo que sensores transmitam dados em intervalos regulares e servidores processem apenas o necessário. “É leve, rápido e tolerante a falhas”, resume. O HTTP, por outro lado, é mais robusto para integrações com sistemas corporativos e APIs REST, mas gera overhead maior em conexões contínuas.

A discussão se intensifica quando Carlos Menezes, gerente de operações, questiona a necessidade de investir em múltiplos padrões.

“Isso não vai complicar a manutenção? Por que não escolhemos apenas um e simplificamos tudo?”

Juliana Prado, analista de dados, intervém:

“A operação da LogiTrack não é uniforme. Há caminhões em áreas urbanas e outros em regiões com cobertura mínima. A arquitetura precisa se adaptar a essa heterogeneidade, não o contrário.”

Com base nessa visão, o time define uma arquitetura de comunicação em camadas adaptativas: os sensores enviam dados via MQTT para o broker quando há rede estável; se a conexão falhar, armazenam localmente e reenviam via HTTP quando possível. Esse modelo garante resiliência e continuidade de dados, mesmo sob falhas intermitentes.

Nas semanas seguintes, o grupo executa testes de campo com protótipos instalados em dois caminhões da rota São Paulo–Campinas. Um sensor de temperatura é configurado para enviar leituras a cada 15 segundos. Os engenheiros acompanham os dados em tempo real pelo console MQTT e, paralelamente, pelo painel HTTP hospedado na nuvem. Durante o trajeto, uma falha proposital de rede é simulada. Após 10 minutos sem sinal, o sistema reconecta automaticamente e reenvia os dados armazenados. O teste é bem-sucedido — e comprova que o design híbrido é viável.

Ao final do experimento, Marina apresenta um relatório técnico: o protocolo MQTT consumiu 83% menos largura de banda do que HTTP e apresentou latência média de 1,3 segundo. O HTTP, embora mais pesado, foi essencial para sincronizar registros e permitir auditorias de logs. A combinação dos dois protocolos se mostra ideal para a operação da LogiTrack, equilibrando eficiência e rastreabilidade.

Na última reunião do ciclo, Henrique Duarte, o CEO, revisa os resultados e sorri:

“Pela primeira vez, vejo dados viajando da estrada direto para a nuvem. Agora estamos falando em visibilidade real.”

Com os protocolos e componentes definidos, o Projeto Atlas entra oficialmente na fase de integração. O próximo desafio será proteger essa comunicação contra falhas e ameaças externas — o tema da próxima aula: Segurança em IoT.