Adriano Santos

Nos últimos anos, os sistemas de Driver Monitoring System (DMS) e as Dash Cams evoluíram de forma impressionante. Alcançamos a capacidade técnica de identificar dezenas de comportamentos do motorista: uso de celular, distração, fadiga, bocejos, olhos fechados, ausência do cinto, cigarro, entre muitos outros.

Contudo, essa evolução traz uma provocação crítica para a nossa indústria:

Estamos tentando identificar eventos... ou estamos tentando evitar acidentes?

Pode parecer uma diferença sutil, mas ela altera radicalmente a gestão da frota e a forma como interpretamos os dados.

O paradoxo da classificação vs. a realidade do risco​

O problema começa quando o evento passa a ser mais importante do que o comportamento.

Na rotina da videotelemetria, discussões sobre a rotulagem de um alerta tornaram-se comuns:

"Isso não foi um evento de distração genérico, foi uso de celular."

"Esse alerta foi classificado de forma incorreta."

Quando auditamos a gravação, porém, encontramos um motorista olhando repetidamente para baixo, retirando os olhos da via para manipular um aparelho.

Nesse contexto, cabe questionar:

• O que realmente colocava aquele motorista em risco?
• O nome do evento?
• Ou o fato de ele estar dirigindo distraído?

Do ponto de vista da gestão de risco, pouco importa se o algoritmo classificou aquele instante como "Uso de Celular", "Distração Visual" ou outra categoria semelhante. O risco continua exatamente o mesmo, pois o nível de exposição ao perigo e o potencial de severidade do acidente permanecem inalterados.

Segurança é um fluxo contínuo, nunca acontece em um único frame​

Existe uma tendência natural de fragmentar a análise em eventos estáticos, como se um único recorte representasse toda a verdade sobre aquele momento.

Entretanto, a condução é um processo contínuo e dinâmico. Um desvio pontual de olhar em um segundo isolado não define, por si só, o perfil de risco do condutor. O risco real reside na frequência, na duração e na combinação desses padrões ao longo do tempo.

O problema aparece quando começamos a conectar os pontos. Imagine um motorista que, nos últimos quinze minutos:

• apresentou diversos episódios de distração;
• realizou duas frenagens bruscas;
• fez mudanças de faixa agressivas;
• dirigia às duas horas da manhã;
• estava acima da velocidade média da frota.

Separadamente, talvez nenhum desses eventos justificasse uma intervenção.

Juntos, eles contam uma história completamente diferente.

O falso positivo também precisa ser colocado em perspectiva​

Falsos positivos em sistemas de fadiga são um tema recorrente na operação.

Um cenário frequente é o motorista perceber excesso de alertas, perder confiança no sistema e, em casos extremos, chegar a cobrir a câmera.

Essa discussão é extremamente válida.

Um sistema de IA, isoladamente, ainda não é perfeito.

Todo algoritmo possui falsos positivos e falsos negativos.

Mas existe um aspecto que recebe pouca atenção:

O ser humano também não é um excelente avaliador do próprio comportamento [1][2][3][4][5].

É muito comum um motorista afirmar categoricamente:

"Eu não estava distraído."

Enquanto a gravação mostra diversos segundos consecutivos com os olhos fora da via.

Isso acontece porque distração não é apenas uma decisão consciente.

Ela pode ocorrer sem que o próprio condutor perceba.

Por isso, nem todo alerta contestado deve ser automaticamente considerado um falso positivo.

Assim como nem todo alerta emitido deve ser considerado uma verdade absoluta.

A resposta normalmente está no equilíbrio entre tecnologia, contexto operacional e análise humana.

Ao priorizar a busca pelo "registro perfeito", corremos o risco de transformar a videotelemetria em um exercício meramente burocrático de auditoria de dados, distanciando-nos do seu propósito primário: a preservação de vidas e do patrimônio.

Estamos utilizando o DMS para gerenciar métricas ou para transformar a cultura de condução?

---

Referências​

[1] Kruger, J., & Dunning, D. (1999). Unskilled and unaware of it: How difficulties in recognizing one's own incompetence lead to inflated self-assessments. Journal of Personality and Social Psychology, 77(6), 1121-1134. https://doi.org/10.1037/0022-3514.77.6.1121

[2] Nisbett, R. E., & Wilson, T. D. (1977). Telling more than we can know: Verbal reports on mental processes. Psychological Review, 84(3), 231-259. https://doi.org/10.1037/0033-295X.84.3.231

[3] Timothy D. Wilson, (2002). Strangers to Ourselves: Discovering the Adaptive Unconscious https://www.amazon.com.br/Strangers-Ourselves-Discovering-Adaptive-Unconscious/dp/0674013824

[4] Mynttinen, S., Sundstrom, A., Vissers, J., Koivukoski, M., Hakuli, K., & Keskinen, E. (2009). Self-assessed driver competence among novice drivers - a comparison of driving test candidate assessments and examiner assessments in a Dutch and Finnish sample. Journal of Safety Research, 40(4), 301-309. https://doi.org/10.1016/j.jsr.2009.04.006

[5] Dang, King, & Inzlicht, (2020). Why Are Self-Report and Behavioral Measures Weakly Correlated?. https://pubmed.ncbi.nlm.nih.gov/32160564/

Nos posts anteriores, cobrimos fundamentos de conectividade e comparação entre tecnologias. Para encerrar a série, vamos para um recorte prático: conectividade IoT em ativos móveis, com foco em veículos.

O que muda quando o ativo está em movimento​

Em veículos, o link de dados muda de célula constantemente. Isso cria desafios que não aparecem com a mesma intensidade em dispositivos fixos:

• Handover frequente entre torres, com risco de perda momentânea de sessão.
• Variação brusca de sinal em túneis, serras, áreas remotas e zonas urbanas densas.
• Oscilação de tecnologia (4G, 3G e eventualmente 2G em fallback).
• Congestionamento de rede em rodovias, centros urbanos e eventos de grande porte.
• Jitter e perda de pacote impactando fluxos de vídeo e áudio em tempo real.

Por isso, telemetria veicular precisa ser projetada para intermitência, não para conectividade perfeita.

Em outras palavras: ter "barra de sinal" não significa que o sistema consegue entregar dado útil com previsibilidade. Em mobilidade, a diferença entre "conectado" e "operando bem" aparece quando a rede oscila e o sistema precisa manter contexto, ordem temporal e prioridade de eventos.

Videotelemetria e streaming em operações móveis​

Quando o caso de uso inclui câmera embarcada, upload de clipes ou streaming ao vivo, o desenho de rede precisa considerar três fatores ao mesmo tempo:

• Vazão sustentada disponível no uplink, não apenas pico momentâneo.
• Latência e jitter durante handover e mudanças de cobertura.
• Perda de pacote em trechos com sombra de sinal ou célula congestionada.

Na prática, o efeito da oscilação aparece assim:

• Streaming ao vivo: queda de bitrate, congelamento e interrupção de sessão.
• Upload de arquivos grandes (video/imagem): aumento forte de tempo total e risco de timeout.
• Telemetria de eventos: fila concorrendo com mídia e perdendo janela operacional.

Diretrizes de arquitetura para operações móveis​

Mais do que publicar uma "receita pronta", vale reforçar os princípios que sustentam uma operação confiável em mobilidade:

• Continuidade operacional acima de throughput de pico.
• Governança de dados para preservar contexto e rastreabilidade.
• Segurança e disponibilidade tratadas como requisitos de negócio.
• Observabilidade ponta a ponta para decisão técnica e operacional.

Em projetos de videotelemetria, esses princípios ajudam a equilibrar dois objetivos que frequentemente entram em conflito: responder rápido a eventos críticos e manter eficiência no transporte de dados ao longo do dia.

Na V3, tratamos esse tema como engenharia de resiliência aplicada ao negócio por meio de software. Isso significa projetar o software, o firmware embarcado na dashcam e a operação de dados com essas variáveis em mente: oscilação de rede, variação de cobertura e mudanças de rota.

Nosso produto não entrega conectividade móvel; ele entrega inteligência operacional sobre ela. Nesse contexto, a Cloud também é essencial para otimizar a operação de ponta a ponta e ampliar o monitoramento da solução como um todo.

Em vez de depender de uma implementação única, priorizamos uma abordagem orientada por risco, contexto da operação e metas de serviço. É esse cuidado contínuo com arquitetura e operação que reduz impacto em campo e sustenta qualidade ao longo do ciclo de vida da solução.

SIM M2M, multi-operadora e APN no cenário móvel​

Para veículos, a estratégia de conectividade geralmente ganha muito com:

• SIM M2M com gestão centralizada de linha e consumo.
• Perfil multi-operadora para melhorar cobertura em rotas variadas.
• APN com política adequada ao risco do negócio (pública com TLS forte ou privada com tráfego segregado).

Quando o impacto de indisponibilidade é alto, redundância de operadora deixa de ser luxo e passa a ser requisito de continuidade.

No cenário de videotelemetria, APN e política de roteamento também influenciam custo e desempenho:

• Separação de tráfego por perfil de aplicação (evento crítico vs mídia em lote).
• Definição de limites para evitar que upload de vídeo degrade dados operacionais.
• Política clara para roaming e fallback, evitando "buracos" em rotas longas.

Boas práticas operacionais para reduzir falhas​

Além de software e rede, a camada física faz diferença:

• Posicionamento correto de antena e chicote para reduzir atenuação.
• Validação de cobertura por corredor logístico real, não só por mapa teórico.
• Testes de drive test por rota crítica antes de escalar a operação.
• Monitoramento de KPIs como reconexões por hora, latência P95 e taxa de entrega.
• Medição de goodput por tipo de dado (telemetria, snapshot, clipe e stream).
• Taxa de sucesso de upload por tamanho de arquivo e por corredor logístico.

Com isso, a operação deixa de olhar apenas "dispositivo online" e passa a medir a pergunta certa: o dado chegou a tempo de gerar ação?

Monitoramento em tempo real da operação​

Para que essas métricas façam sentido prático, é essencial ter visibilidade ponta a ponta da frota. Um painel de monitoramento bem desenhado expõe:

• Saúde geral de cada dispositivo (online, offline, sinal fraco, dados acumulados).
• Agregação por rota, corredor logístico ou zona geográfica.
• Distribuição de sinal (forte, bom, fraco) por localização.
• Consumo de dados acumulado e velocidade média.
• Padrões de bateria e eventos de ignição (para veículos).
• Alertas automáticos para anomalias (dispositivo offline prolongado, oscilação de rede, timeout de uplink).

Com essas informações estruturadas e em tempo real, times de operação conseguem antecipar problemas, validar impacto de mudanças infraestruturais e comunicar com transparência o status da frota para stakeholders.

Figura: Dashboard da solução V3 de monitoramento para operações de frota. Visibilidade completa de saúde de dispositivos, distribuição de conectividade e métricas operacionais em tempo real da frota do cliente.

Normas e referências úteis​

• 3GPP e GSMA para fundamentos de redes móveis e ecossistema SIM.
• Regulamentação local e homologação de equipamentos (Anatel no Brasil).
• Práticas de segurança para IoT conectada, como ETSI EN 303 645.

Aprendizados para projetos em campo​

Conectividade para veículos é, acima de tudo, engenharia de resiliência. O projeto vencedor não é o que funciona apenas com sinal ótimo, e sim o que mantém previsibilidade operacional em movimento, com oscilação real de rede.

Em telemetria com vídeo, essa diferença fica explícita: conectividade por si só não garante dado útil. O que garante resultado é uma arquitetura que prioriza, bufferiza, retransmite com critério e adapta o fluxo de mídia ao estado real da rede.

Na Parte 2, vimos como a conectividade celular se organiza no core da operadora e como APN, políticas de rede e roteamento impactam a operação. A partir desse ponto, a próxima decisão de arquitetura é entender quando o celular deixa de ser a melhor opção e quando redes não-celulares entregam mais eficiência técnica e econômica. Neste artigo, comparamos Mesh, LoRa, LoRaWAN e Zigbee com foco em critérios práticos de escolha.

Mesh: resiliência por múltiplos caminhos​

Redes mesh permitem que nós encaminhem pacotes entre si, criando caminhos alternativos até o gateway.

Pontos fortes:

• Boa cobertura em ambientes com obstáculos.
• Tolerância a falhas de nós individuais.
• Escalabilidade local em plantas, galpões e condomínios.

Pontos de atenção:

• Planejamento de topologia e canal é essencial.
• Mais hops podem aumentar latência e consumo.
• Interferência em banda não licenciada pode degradar desempenho.

Fonte: Wikimedia Commons - File:NetworkTopology-Mesh.svg

LoRa e LoRaWAN: longo alcance com baixa taxa​

LoRa é a camada física de rádio (modulação). LoRaWAN é o protocolo de rede sobre LoRa.

Quando brilha:

• Telemetria pequena e periódica.
• Sensores alimentados por bateria por longos períodos.
• Cobertura de grandes áreas com poucos gateways.

Limitações típicas:

• Throughput baixo para cargas grandes.
• Dever de transmissão (duty cycle) e regras de espectro impactam capacidade.
• Latência e downlink limitados dependendo da classe do dispositivo.

Fonte: Wikimedia Commons - File:LoRa-RF_Ananlyzer-12-7.8k.1.jpg

Zigbee: ecossistema maduro para rede local​

Zigbee roda sobre IEEE 802.15.4 e é forte em automação predial e industrial leve.

Vantagens:

• Baixo consumo energético.
• Ecossistema amplo de módulos e sensores.
• Boa integração em redes locais de curta/média distância.

Desafios:

• Alcance por salto depende da densidade de nós roteadores.
• Coexistência em 2,4 GHz exige planejamento para evitar interferência.

Fonte: Wikimedia Commons - File:ETRX357_ZigBee_module_with_size_ref.JPG

Redes satelitais: cobertura ampla com trade-offs de latência e custo​

Quando o projeto opera fora da cobertura terrestre consistente (áreas remotas, oceânicas, mineração, agro em grande extensão), conectividade satelital deixa de ser exceção e passa a ser considerada parte da arquitetura.

De forma prática, as órbitas mais comuns entram no desenho assim:

• LEO (Low Earth Orbit): menor latência e melhor experiência para aplicações mais interativas, com constelações de muitos satélites e handovers frequentes (ex.: Starlink e OneWeb).
• MEO (Medium Earth Orbit): equilíbrio entre cobertura e latência, menos comum em IoT generalista, mas relevante em alguns serviços especializados (ex.: SES O3b).
• GEO (Geostationary Earth Orbit): grande cobertura por satélite, arquitetura mais estável do ponto de vista orbital, porém com latência maior (ex.: Inmarsat, Intelsat e Viasat).

Critérios de decisão para satélite:

• Cobertura real de campo, não apenas mapa de marketing do provedor.
• Orçamento de energia do terminal e perfil de transmissão (evento, lote, quase tempo real).
• Sensibilidade da aplicação à latência e à variação de throughput.
• Custo total: hardware, plano de dados, instalação e operação contínua.
• Estratégia híbrida com fallback terrestre (celular/LPWAN) quando disponível.
• Avaliar tráfego de mídia (imagens, clipes de vídeo e streaming): uplink sustentado, tempo de upload, risco de timeout, consumo de franquia e necessidade de priorização entre evento crítico e mídia.
• Quando o IoT é móvel, avaliar handover entre feixes/células, estabilidade de sessão em deslocamento e variação de desempenho por corredor logístico.
• Em mobilidade, considerar o impacto de velocidade e rota na perda de pacote, jitter e tempo de entrega de eventos críticos.

Em muitos projetos IoT, satélite não substitui tudo: ele complementa a conectividade terrestre para garantir continuidade operacional onde a infraestrutura tradicional não chega com previsibilidade. Em cenários móveis, essa complementaridade precisa ser validada em rota real, porque o desempenho pode variar significativamente entre regiões e condições de deslocamento.

Como escolher entre essas redes​

Use uma matriz simples de decisão:

1. Cobertura necessária: metros, quilômetros, indoor, outdoor.
2. Perfil de carga: bytes por mensagem, frequência de envio, necessidade de downlink.
3. Energia disponível: bateria, rede elétrica, ciclo de manutenção.
4. Criticidade de latência: segundos, minutos, quase tempo real.
5. Custos de implantação: gateways, manutenção, operação de rede.
6. Requisitos regulatórios e de segurança.

Uma regra prática:

• Se precisa mobilidade ampla e controle centralizado, celular tende a liderar.
• Se precisa autonomia energética e longas distâncias com pouca carga, LoRaWAN é forte.
• Se precisa rede local densa e baixa potência, Zigbee ou Mesh podem ser melhores.
• Se precisa cobertura em áreas remotas sem infraestrutura terrestre confiável, satélite (LEO/MEO/GEO) entra como opção principal ou camada de contingência.

Normas e referências técnicas​

• LoRaWAN: especificações da LoRa Alliance.
• Zigbee: especificações da Connectivity Standards Alliance (Zigbee) sobre IEEE 802.15.4.
• Redes mesh em geral: perfis e stacks variam por protocolo (Thread, Zigbee, Bluetooth Mesh).
• Segurança IoT: referências como ETSI EN 303 645 e boas práticas de gestão de chaves/credenciais.

Próximo post da série​

Na Parte 4, fechamos a série com foco em conectividade para dispositivos móveis em veículos, cobrindo desafios de mobilidade, arquitetura de resiliência e boas práticas de campo.

A melhor decisão de rede é aquela que atende ao contexto operacional real do projeto, e não apenas ao melhor benchmark de laboratório.

Na Parte 1, discutimos os fundamentos para decisões de conectividade e o desafio das áreas de sombra. Agora vamos aprofundar os aspectos técnicos da conectividade celular para IoT.

Como a rede celular funciona para um dispositivo IoT​

Quando um dispositivo IoT com modem celular envia dados, o caminho simplificado é:

1. Dispositivo + SIM fazem autenticação na rede da operadora.
2. O tráfego é encapsulado no core móvel (Evolved Packet Core (EPC) no 4G ou 5G Core (5GC) no 5G).
3. A operadora aplica políticas de roteamento, QoS e segurança.
4. O dado sai para Internet pública ou para rede privada corporativa.
5. A aplicação de IoT recebe, processa e responde.

Em termos práticos, a operadora não oferece apenas cobertura de rádio. Ela oferece controle de sessão, autenticação, roteamento e políticas de tráfego.

Fonte: Wikimedia Commons - File:GSM_ArchitecturePL.svg

SIM tradicional x SIM M2M/IoT​

Um chip M2M/IoT costuma trazer características importantes para operação em escala:

• Perfil tarifário orientado a baixo consumo de dados por dispositivo.
• Maior previsibilidade contratual para conexões permanentes.
• Recursos de gerenciamento em lote (ativação, bloqueio, diagnóstico).
• Opções multi-operadora ou roaming permanente em alguns modelos.
• Formatos industriais (2FF/3FF/4FF) e eSIM/eUICC para troca remota de perfil.

Para operações massivas, gestão remota de SIM é tão importante quanto cobertura.

APN: o que é e por que existe​

APN (Access Point Name) é o identificador lógico que diz ao core da operadora qual rede de dados o dispositivo quer alcançar e quais políticas devem ser aplicadas nessa sessão.

Na prática, o APN influencia diretamente:

• Endereçamento IP do dispositivo (privado, público, estático ou dinâmico, conforme política).
• Perfil de roteamento (Internet pública, rede privada corporativa ou ambiente híbrido).
• Regras de segurança (ACL, portas permitidas, inspeção e segmentação).
• Política de QoS e charging (prioridade de tráfego, franquia e tarifação).

Sem APN, todo tráfego cairia em uma política padrão da operadora. Com APN, você transforma conectividade em controle de serviço.

Como uma APN funciona​

Quando o dispositivo sobe sessão de dados, o APN participa do fluxo de ponta a ponta:

1. O dispositivo solicita uma sessão de dados informando o APN.
2. O core valida SIM, assinatura e permissões para aquele APN.
3. A sessão é associada a funções de controle e encaminhamento (no 4G, tipicamente MME/SGW/PGW; no 5G, funções equivalentes no 5GC).
4. O tráfego do usuário passa a seguir o caminho e as políticas do APN selecionado.
5. O backend recebe esse tráfego conforme o modelo definido: Internet, VPN/IPsec, MPLS ou interconexão dedicada.

Em termos de transporte, o plano de usuário em redes móveis usa encapsulamento em túneis (como GTP-U no contexto 3GPP), o que permite separar sessões por dispositivo e aplicar política por bearer/sessão.

Fonte: Wikimedia Commons - File:Evolved_Packet_Core.svg

APN pública x APN privada​

A diferença técnica mais importante está no domínio de roteamento e na exposição de rede.

• APN pública: geralmente usa saída compartilhada para Internet, com NAT e controles padrão.
• APN privada: encaminha tráfego para domínios restritos do cliente, com isolamento de rota e maior governança.
• APN híbrida: combina fluxos por criticidade, separando telemetria comum e dados sensíveis.

Em IoT, isso permite desenhar políticas diferentes para tipos de payload, classes de dispositivo e níveis de risco operacional.

Quando usar APN pública ou privada​

APN pública costuma funcionar bem quando:

• O dado não é sensível a ponto de exigir rede segregada.
• O backend já está preparado para Internet pública com TLS forte.
• O projeto precisa de entrada rápida em produção e custo menor.

APN privada tende a ser melhor quando:

• Existe exigência de isolamento de tráfego por compliance.
• O cliente demanda acesso restrito a endpoints internos.
• Há políticas corporativas rígidas de segurança de rede.

Em muitos cenários, uma arquitetura híbrida resolve: APN pública para telemetria não crítica e APN privada para operações sensíveis.

Banda larga no contexto IoT​

Quando o dispositivo IoT fica instalado sempre no mesmo local (por exemplo, uma loja, fábrica, escola ou condomínio), ele pode usar banda larga fixa (fibra, cabo ou rádio) como conectividade principal:

• Vantagens: alta capacidade, estabilidade, menor custo por megabyte.
• Riscos: indisponibilidade local, dependência de energia e infraestrutura do site.
• Uso ideal: gateways locais, video analytics em borda e ambientes com tráfego elevado.

Para ativos móveis, a banda larga fixa do local costuma ser usada como backhaul (o "caminho de saída" que liga a rede interna do site à internet), enquanto a conectividade do dispositivo em movimento continua no celular.

Padrões e normas relevantes​

Se a ideia é escalar com previsibilidade, vale mapear cada decisão de arquitetura a uma referência técnica:

• 3GPP: arquitetura de sistema, mobilidade, QoS, perfis IoT (incluindo evoluções de LTE-M/NB-IoT e 5G).
• GSMA: diretrizes operacionais para ciclo de vida de SIM/eSIM, roaming e gestão em escala.
• ETSI EN 303 645: baseline de segurança para dispositivos conectados e cadeia IoT.
• Regulação local: homologação, espectro e requisitos de operação (ex.: Anatel no Brasil).

Esse alinhamento evita decisões ad hoc e melhora auditoria técnica, segurança e interoperabilidade entre operadoras e fornecedores.

Próximo post da série​

Na Parte 3, vamos subir o nível técnico na comparação entre Mesh, LoRa, LoRaWAN e Zigbee, explorando topologia, capacidade, latência, consumo energético e limites práticos de cada tecnologia.

Escolher conectividade em IoT vai muito além de definir "qual rede usar". Em projetos reais, essa decisão afeta viabilidade financeira, velocidade de implantação, confiabilidade da operação e experiência do cliente no dia a dia.

Esta série foi criada para organizar esse tema de forma progressiva, conectando visão de negócio e fundamentos técnicos sem perder foco prático. A ideia é ajudar times de produto, engenharia e operações a tomarem decisões melhores antes que os problemas apareçam em campo.

Ao longo de 4 partes, vamos cobrir:

1. Fundamentos para decisões de conectividade em cenários reais de operação.
2. Rede celular para IoT e APN: funcionamento, modelos e critérios de escolha.
3. Redes não-celulares e padrões: Mesh, LoRa, LoRaWAN e Zigbee na prática.
4. Conectividade para dispositivos móveis em veículos, com foco em resiliência operacional.

O que muda quando o dispositivo vai para a rua​

Em laboratório, quase toda conectividade parece funcionar. Em produção, surgem as variáveis difíceis:

• Cobertura irregular em rodovias, subsolos, pátios industriais e áreas rurais.
• Congestionamento em horários de pico e eventos de massa.
• Troca de operadora por geografia, custo ou qualidade de sinal.
• Dependência de roaming nacional e internacional.
• Restrições de energia para equipamentos a bateria.

Essas zonas de baixa disponibilidade ou baixa qualidade de sinal são as chamadas áreas de sombra. Na prática, elas não são apenas pontos sem sinal: podem ser regiões com latência imprevisível, perda de pacotes ou oscilação de tecnologia (4G para 3G, por exemplo).

Fonte: Wikimedia Commons - File:CellTowerRichmondHill.jpg

Os três pilares da decisão de conectividade​

Uma boa arquitetura IoT costuma equilibrar três eixos:

• Cobertura efetiva: não é só o mapa da operadora, é o desempenho no local de operação.
• Custo total: módulo, chip, dados, operação, suporte e retrabalho de campo.
• Confiabilidade operacional: capacidade de transmitir quando importa, mesmo em ambiente hostil.

Se um desses pilares falha, o projeto paga a conta depois em tickets, manutenção e perda de confiança do cliente.

Tecnologias de forma simples​

Antes de aprofundar a parte técnica, vale um resumo de alto nível:

• Celular (2G/3G/4G/5G, NB-IoT, LTE-M): cobertura ampla, boa para ativos móveis e cenários distribuídos.
• Banda larga fixa (fibra/cabo/rádio): ótima capacidade onde há infraestrutura local estável.
• Redes de baixa potência e longo alcance (LoRa/LoRaWAN): ideais para telemetria leve, grande autonomia energética e longas distâncias.
• Redes de curto alcance e baixa potência (Zigbee, Bluetooth Mesh): fortes em ambientes locais com muitos nós próximos.

Não existe tecnologia universalmente melhor. Existe a tecnologia adequada para o perfil de tráfego, mobilidade, energia e criticidade de cada caso.

Onde o técnico encontra o comercial​

Do lado comercial, a conectividade entra em quatro perguntas:

1. Qual o custo mensal por ativo e como ele evolui com escala?
2. Qual o risco de indisponibilidade em regiões críticas da operação?
3. Qual o impacto de falha de comunicação no negócio do cliente?
4. Qual o modelo de suporte quando houver perda de conectividade em campo?

Do lado técnico, as respostas passam por escolha de rede, fallback, buffering local, políticas de retransmissão e observabilidade.

Estratégias para reduzir impacto de áreas de sombra​

Mesmo antes de escolher protocolos detalhados, já é possível desenhar resiliência:

• Store-and-forward: o dispositivo guarda dados localmente e retransmite quando o link retorna.
• Dual-SIM ou multi-operadora: aumenta chance de cobertura em campo.
• Telemetria adaptativa: reduz taxa de envio quando a qualidade de link cai.
• Alertas de saúde de conectividade: mede perda, latência e reconexões por dispositivo.
• Priorização de payload: envia primeiro o que é crítico para operação.

Normas e governança: por que importam​

Projetos IoT maduros alinham tecnologia com normas e diretrizes de mercado:

• 3GPP para padrões de redes móveis.
• GSMA para práticas de ecossistema móvel e SIM.
• Regulamentação local (como Anatel no Brasil) para homologação e operação.

Seguir padrões reduz risco de lock-in, melhora interoperabilidade e facilita auditoria técnica/comercial.

Fonte: Wikimedia Commons - File:Cellular_network_standards_and_generation_timeline.svg

Próximo post da série​

Na Parte 2, vamos entrar na mecânica da rede celular para IoT: como o tráfego passa pela operadora, o papel do SIM M2M, APN pública x APN privada e quando cada modelo faz sentido.

Construindo uma Plataforma moderna, escalável e segura​

Quando projetamos a V3, tínhamos um objetivo claro: entregar uma plataforma de visão computacional robusta, segura e escalável — não apenas uma API funcional. Para isso, investimos em uma arquitetura moderna, desenhada para evoluir junto com nossos clientes, com foco em isolamento, performance e conformidade legal.

Neste post, queremos compartilhar com você — desenvolvedor, integrador ou arquiteto de sistemas — como estruturamos os fundamentos da V3 sob uma ótica técnica.

Multi-tenant de verdade​

Cada cliente da V3 é provisionado em seu próprio tenant isolado, o que significa:

• Ambientes segregados lógica e computacionalmente.
• Tokens, dados, métricas e até filas de mensagens totalmente independentes.
• Possibilidade de aplicar políticas de segurança, escalabilidade e retenção de forma granular.

Essa abordagem evita o acoplamento excessivo entre contas e nos permite garantir níveis de segurança e privacidade superiores, especialmente em conformidade com a LGPD.

Escalabilidade nativa com Kubernetes​

Toda a plataforma roda em uma infraestrutura orquestrada com Kubernetes, que nos permite:

• Autoescalar componentes críticos com base em carga e volume de eventos.
• Distribuir horizontalmente processamentos intensivos como análise de vídeo e eventos de comportamento.
• Facilitar rollouts canary e blue/green com segurança.
• Executar rotinas de manutenção e upgrades com zero downtime.

A combinação de tenants isolados com Kubernetes resulta em uma operação previsível, onde cada cliente pode escalar sem afetar o desempenho do outro.

Go para o núcleo da performance​

Grande parte dos nossos microserviços — especialmente aqueles responsáveis por ingestão de eventos e gestão de dispositivos — é escrita em Go. A escolha se deu por:

• Baixa latência e ótimo gerenciamento de concorrência.
• Tempo de execução enxuto, ideal para containers.
• Compilação estática, que facilita distribuições confiáveis em múltiplos clusters.

Go é a espinha dorsal das partes que precisam de eficiência máxima em I/O e rede.

Conformidade com LGPD desde a fundação​

Desde o início, a V3 foi projetada com privacy-by-design. Isso inclui:

• Dados anonimizados quando não essenciais.
• Logs de acesso e rastreabilidade por tenant.
• Política de retenção configurável por cliente.
• Auditoria de acessos sensíveis e APIs que expõem metadados de compliance.

Não é apenas uma questão de estar em conformidade — tratamos a LGPD como um princípio de engenharia.

Observabilidade e automação contínua​

Nossa arquitetura foi desenhada para oferecer visibilidade de ponta a ponta em cada tenant, serviço e fluxo de dados. Adotamos padrões modernos de observabilidade distribuída, com rastreamento de requisições, coleta de métricas e logs estruturados desde o início — tudo com base em OpenTelemetry.

Cada evento gerado, erro capturado ou requisição processada carrega contexto rico que facilita tanto o diagnóstico em tempo real quanto auditorias retroativas. Esse nível de rastreabilidade é essencial para garantir confiabilidade em ambientes multi-tenant.

Do ponto de vista de engenharia, seguimos práticas modernas como GitOps para automação de infraestrutura e controle de versionamento, além de pipelines de integração e deploy contínuos que garantem entregas seguras e frequentes, com validações automatizadas, testes em múltiplos ambientes e rollback simplificado.

Essa combinação entre observabilidade padronizada e automação robusta nos permite operar com agilidade, mantendo altos padrões de qualidade e segurança.

Conclusão​

A API V3 não é apenas uma interface. É o ponto de entrada para uma plataforma pensada com cuidado, desde a escolha da linguagem até o provisionamento automatizado e compliance legal.

Nosso objetivo não é apenas facilitar a integração de visão computacional e telemetria, mas fornecer um ecossistema de dados confiável, elástico e seguro para qualquer escala de operação.

Se você quer conhecer mais detalhes ou está considerando uma integração mais profunda, visite nossa documentação.

Em posts futuros, entraremos a fundo nos desafios que enfrentamos ao construir e operar essa arquitetura — desde o controle fino de recursos por tenant até os aprendizados em observabilidade distribuída em larga escala.

---

A tecnologia por trás da segurança veicular também pode ser bela.