Como um integrador de sistemas construiu um aplicativo de sensor com IoT Query, não APIs

Um supervisor de armazém procura um painel de gestão de frotas em busca de leituras de temperatura que estão a três cliques de profundidade. Os dados estão lá, mas a interface foi criada para despachantes, não para operações de armazenamento em baixas temperaturas. Esse descompasso entre os recursos da plataforma e as necessidades de negócio é comum. Construir aplicativos personalizados normalmente leva meses, mas este estudo de caso apresenta um caminho mais rápido.

Principais conclusões

• Crie aplicativos de monitoramento personalizados mais rapidamente com acesso direto à telemetria, eliminando a necessidade de middleware e pipelines de dados complexos.
• Simplifique o desenvolvimento de análises usando SQL para consultar dados históricos diretamente, evitando as limitações e sobrecarga de integrações baseadas em API.
• Crie painéis específicos para cada função com consultas SQL flexíveis que se alinham melhor aos fluxos de trabalho operacionais, melhorando a usabilidade e a tomada de decisões.
• Escalone sem problemas em vários armazéns e usuários, sem precisar reconstruir a infraestrutura ou lidar com restrições de API.
• Acelere o tempo de retorno concentrando-se em análises e insights por meio de SQL, em vez de manter serviços de backend ou integrações de API.

Explore o IoT Query para desbloquear todo o potencial de seus dados de telemática em aplicativos de análise personalizados.

A realidade operacional do monitoramento especializado

Plataformas de telemática de uso geral se destacam no que foram projetadas para fazer: rastreamento de veículos, otimização de rotas, análise de comportamento do motorista. Mas, quando uma empresa de logística precisa de monitoramento ambiental em várias salas de armazém, a mesma interface se torna um obstáculo.

Os supervisores neste caso precisavam de algo específico:

• Leituras de temperatura e umidade em 12 zonas de armazenamento.
• Tendências históricas para investigação de incidentes.
• Um destaque quando as condições saem das faixas aceitáveis.

Tradicionalmente, resolver esse problema exigia um de dois caminhos: estender as APIs e plataformas existentes além de seu propósito original ou construir um stack de aplicativos separado com pipelines de dados, infraestrutura e gerenciamento de funções personalizados. Ambas as abordagens introduzem complexidade desnecessária. A primeira leva a integrações e flexibilidade limitada para análises. A segunda atrasa a entrega, pois as equipes passam semanas e meses montando pipelines de dados, mantendo infraestrutura e conciliando várias fontes de dados em vez de gerar valor.

O desafio: equilibrar independência com integração

O integrador de sistemas enfrentou uma lista de requisitos que parecia simples, mas trazia implicações arquitetônicas. Os sensores já estavam implantados na rede do armazém, enviando telemetria para a Navixy. Dados de temperatura, umidade, estados de portas e tempo de funcionamento de equipamentos fluíam constantemente.

Mas os supervisores precisavam de uma interface que exibisse apenas o que era relevante para seu fluxo de trabalho:

• Status em tempo real em uma única visão.
• Consultas históricas para investigar por que o freezer na Zona 3 apresentou um pico de temperatura na última terça.
• Visões específicas para clientes que desejavam ver seu espaço de armazenamento dedicado.

O aplicativo também precisava permanecer independente, uma ferramenta focada em operações de armazém, mas ainda assim conectado à plataforma de telemática. Novos armazéns e sensores deveriam ser integrados sem reconstruir o aplicativo. As permissões de usuário deveriam respeitar a estrutura organizacional existente.

Escalabilidade significava três coisas: mais salas dentro de um armazém, mais armazéns na rede e mais usuários com diferentes níveis de permissão. A arquitetura precisava dar suporte a tudo isso sem exigir desenvolvimento sob medida para cada expansão.

Decisão arquitetônica: por que o acesso direto aos dados superou a abordagem via API

Dois caminhos arquitetônicos podiam levar a um aplicativo que funcionasse. O primeiro, usando a API da plataforma, é a escolha convencional. O segundo, acesso direto por meio de IoT Query, ofereceu um equilíbrio diferente.

A abordagem via API funciona bem em muitas integrações. Para painéis de status em tempo real, esse padrão entrega resultados rapidamente. Mas a análise histórica muda o cenário. Consultar seis meses de dados de temperatura em 12 zonas por meio de uma API implica paginação, limites de taxa e lógica de agregação de dados em middleware personalizado. O integrador precisaria criar e manter um banco de dados local, rotinas de sincronização e infraestrutura de armazenamento, tudo isso antes de escrever sequer uma linha de código do painel.

O IoT Query ofereceu uma arquitetura diferente. O aplicativo consulta uma camada de dados preparada diretamente usando SQL padrão.

"O IoT Query fornece acesso pronto para uso a dados de telemetria em tempo real e históricos, sem a necessidade de criar camadas de armazenamento e agregação", explica Andrew Melnik, VP de Dados e Soluções da Navixy. "As consultas SQL são mais rápidas do que chamadas repetidas de API permitiriam. Podemos, portanto, fornecer painéis em tempo real e análises históricas da mesma fonte de dados, mantendo a arquitetura simples. O aplicativo permanece independente, mas se integra perfeitamente com a Navixy. Particularmente para esse caso, a carga de manutenção é muito menor do que na alternativa de API.”

Implementação: do acesso ao banco de dados aos painéis operacionais

Com a decisão arquitetônica tomada, a implementação se concentrou no que os integradores de sistemas fazem de melhor: criar aplicativos que resolvem problemas específicos.

IoT Query raw data layer forneceu a base. Esse conjunto de dados contém leituras de telemetria com a estrutura e indexação necessárias para análise de séries temporais. Leituras de temperatura, medições de umidade, estados de portas e status de equipamentos, tudo consultável por meio de sintaxe SQL padrão compatível com ferramentas PostgreSQL.

O padrão de desenvolvimento era familiar para quem já criou aplicativos de análise:

1. Conectar-se à fonte de dados.
2. Escrever consultas para as métricas específicas necessárias.
3. Criar visualizações que respondam a perguntas operacionais.

Para monitoramento em tempo real, o aplicativo consulta as leituras recentes e atualiza os painéis em intervalos adequados às condições ambientais (as mudanças em nível de minuto importam menos do que as de hora em armazenamento refrigerado). Para análise histórica, a mesma fonte de dados suporta consultas de semanas ou meses sem a complexidade de fazer paginação via API.

O isolamento de clientes ocorreu por meio da estrutura organizacional já existente. Cada cliente de armazém enxerga apenas suas zonas de armazenamento designadas. O aplicativo respeita esses limites sem exigir lógica de controle de acesso personalizada.

O aplicativo entregue fornece aos supervisores exatamente o que eles precisam:

• Status ambiental em tempo real em todas as zonas monitoradas.
• Gráficos de tendências históricas para investigar anomalias.
• Alertas baseados em limiares quando as condições excedem limites aceitáveis.
• Visões específicas de clientes com isolamento adequado de dados.

O aplicativo funciona como uma ferramenta independente, mas pode ser aberto pela interface da Navixy, mantendo uma experiência coesa para usuários que trabalham tanto com a frota quanto com as operações de armazém.

Essa integração é habilitada por meio do App Connect, a ferramenta de autenticação da Navixy. Ela transfere a autenticação do usuário da plataforma para o aplicativo externo, permitindo que os usuários acessem a ferramenta de monitoramento sem precisar de um login separado. Para integradores de sistemas, isso elimina a necessidade de criar ou manter uma infraestrutura de autenticação.

O que vem a seguir: do monitoramento à previsão

À medida que o aplicativo se expande, outros KPIs podem ampliar o painel além de temperatura e umidade. Métricas como tempo de operação de equipamentos, consumo de energia e indicadores de manutenção podem ser integradas de modo transparente, usando a mesma camada de dados.

A análise preditiva representa a próxima melhoria operacional. Em vez de alertar quando as condições ultrapassam limites, o sistema pode identificar padrões que antecedem falhas. Um compressor que opera com maior frequência do que o normal. Um sensor de porta indicando períodos de abertura incomuns. Esses sinais existem nos dados históricos, aguardando análise.

Os mecanismos de alerta irão além do próprio aplicativo. A integração com fluxos de trabalho operacionais garante que as pessoas certas recebam notificações por seus canais existentes (email, mensageiros), enquanto permite reduzir ou remover alertas quando necessário.

Interfaces móveis ampliarão o acesso para supervisores durante as rondas no local. As mesmas consultas que alimentam os painéis de desktop podem gerar visões móveis focadas no status das zonas e alertas recentes.

A base é importante porque essas expansões requerem mudanças mínimas na arquitetura. A camada de dados já contém os sinais necessários para análises mais sofisticadas. A criação de novas visualizações e análises passa a ser desenvolvimento de aplicativo, não de infraestrutura.

O argumento para uma abordagem centrada em dados

Este estudo de caso ilustra um princípio que se aplica além do monitoramento de armazéns: quando a infraestrutura de dados está pronta, os integradores de sistemas podem se concentrar em aplicativos que resolvem problemas reais. Uma camada de dados preparada permite que desenvolvedores consultem telemetria estruturada por meio de SQL padrão — sem gerenciar sistemas subjacentes.

Para integradores de sistemas, isso é uma vantagem arquitetônica. Com suporte integrado para análise de séries temporais e ambientes multi-tenant, uma camada de dados pronta pode reduzir o tempo de entrega de meses para semanas.

Entre em contato conosco para habilitar o IoT Query e liberar todo o potencial dos seus dados de telemática em aplicativos de análise personalizados.

---

Perguntas Frequentes

P: Quais componentes de middleware específicos um método apenas com API exigiria?

R: O método por API exige gerenciamento de paginação, controle de limite de taxa, armazenamento local em banco de dados, rotinas de sincronização e lógica de agregação antes que o desenvolvimento do painel possa começar.

P: Como os limites de taxa da API e a paginação afetam a análise de dados históricos em grande escala?

R: Consultas históricas que abrangem meses de dados em várias zonas exigiriam manipulação extensiva de paginação e seriam restringidas pelos limites de taxa de API, tornando a análise histórica em tempo real inviável.

P: Como o IoT Query lida com dados de sensor inconsistentes ou ruidosos provenientes de diferentes dispositivos?

R: O IoT Query atualmente fornece acesso a uma Raw data layer, que contém conjuntos de dados completos de telemática e negócios com transformação mínima. De acordo com a Documentação da Navixy, as camadas Transformation e Insight para dados limpos e agregados de nível empresarial ainda estão planejadas, mas não estão geralmente disponíveis. Isso significa que os integradores atualmente trabalham principalmente com dados brutos de origem e devem levar em consideração a normalização e a limpeza em sua própria lógica de análise, conforme necessário.

P: O que acontece quando os dados de telemetria são atrasados ou estão ausentes?

R: A disponibilidade dos dados depende da conectividade do dispositivo e do comportamento de envio de relatórios. O IoT Query reflete os dados recebidos pela plataforma, portanto, os integradores devem projetar painéis e lógicas para lidar com lacunas, atrasos e conjuntos de dados incompletos.

P: Quais são os limites práticos ou considerações ao usar o IoT Query em implantações de grande escala?

R: O desempenho depende do design das consultas, do volume de dados e dos intervalos de tempo. Embora o IoT Query elimine a necessidade de infraestrutura de armazenamento personalizada, os integradores devem avaliar a eficiência das consultas, os tempos de resposta para grandes volumes de dados e a frequência de atualização dos painéis em cargas reais.

P: Como o IoT Query se integra a sistemas externos ou ferramentas de BI?

R: O IoT Query oferece acesso baseado em SQL compatível com PostgreSQL, permitindo integração com ferramentas de análise externas e aplicativos personalizados que possam se conectar a bancos de dados relacionais.

P: Como são tratados o controle de acesso e a isolação de dados multi-tenant?

R: O IoT Query segue a estrutura organizacional da plataforma, garantindo que os usuários só possam acessar e consultar dados disponíveis em sua conta e permissões atribuídas.