Como construir um sistema de monitoramento de sensores em tempo real para armazéns e além

Se você constrói fluxos para armazéns, sites de cadeia fria ou instalações técnicas, este caso mostra como transformar dados telemáticos existentes em um sistema de monitoramento de sensores sob medida, sem adicionar um pipeline de dados separado. Ele também detalha a arquitetura da aplicação: acesso PostgreSQL, configuração de sensores, lógica de limiares ao vivo, histórico, relatórios e mapa.

Imagine um armazém em que leituras de temperatura e umidade já são coletadas por dispositivos conectados. A equipe de operações pode não precisar de outra tela organizada por rastreadores e IDs de sensores. Pode precisar de uma resposta mais simples: quais câmaras frias ou zonas de armazenamento estão agora dentro da faixa configurada?

IoT Query, a plataforma de analytics de frotas da Navixy, oferece acesso estruturado a dados de frota e sensores via PostgreSQL, enquanto o integrador define a interface em torno do fluxo do cliente. Sensoriqua, uma aplicação construída por um parceiro Navixy, demonstra essa abordagem. Ela agrupa canais de sensores individuais por zona física, aplica limites configurados e mostra o status operacional antes dos valores brutos.

A codificação por cores na interface facilita interpretar o status sem conferir cada leitura. Verde significa que todas as leituras configuradas de uma zona estão na faixa definida. Vermelho destaca uma zona em que pelo menos um sensor está fora do limiar. Um status neutro significa que nenhum limiar foi configurado para aquele sensor.

Onde o monitoramento de sensores por zona se aplica

O mesmo padrão de aplicação pode atender vários cenários em que os usuários trabalham com locais físicos, e não com IDs de dispositivo:

• Clientes farmacêuticos e de armazéns de alimentos podem precisar de registros de temperatura e umidade organizados por zona de armazenamento e documentados segundo GxP ou padrões de conformidade de cadeia fria. Para uma trilha de auditoria, a pergunta relevante é qual zona permaneceu na faixa especificada, e não qual ID de dispositivo produziu uma leitura individual.
• Clientes de data centers e salas de servidores podem precisar de status por fileira de racks ou por sala, para que a operação confira uma área específica sem cruzar uma planilha.
• Clientes de salas limpas e laboratórios monitoram condições ambientais que podem variar entre áreas de um espaço controlado.
• Clientes de estufas e agricultura podem monitorar microclimas por setor de cultivo, em que as condições diferem entre seções da mesma instalação.
• Operadores de museus e arquivos podem organizar o monitoramento de temperatura e umidade por sala, alinhando as leituras aos espaços onde as coleções são guardadas.
• Clientes industriais podem agrupar dados de condição de equipamentos por linha de produção, oficina ou ala do prédio.

Em cada caso, o IoT Query fornece os dados telemáticos e de sensores. O integrador determina como a aplicação mapeia essas leituras para os locais e os conceitos operacionais do cliente.

O que compõe um sistema de monitoramento de sensores sob medida

Sensoriqua é uma implementação de referência construída por um parceiro Navixy para um tipo específico de fluxo. A aplicação roda sobre o Navixy IoT Query, com acesso SQL direto aos dados de sensores.

A arquitetura combina três camadas centrais da aplicação, com histórico, relatórios e mapa:

1. Acesso a dados: uma conexão PostgreSQL direta a um banco dentro do IoT Query.
2. Configuração de sensores: um mapeamento persistente entre objetos-fonte, canais de sensor, zonas definidas pelo cliente, limiares, fatores de escala e rótulos de exibição. Os dados de sensores podem ser organizados independentemente dos rastreadores que os entregaram.
3. Painel ao vivo: um dashboard que consulta valores recentes em intervalo configurável, avalia limiares no navegador e apresenta o status agregado por zona.
4. Histórico e relatórios: uma vista de consulta para comparar leituras ao longo do tempo, revisar mínimo, máximo e média diários e identificar anomalias ou padrões recorrentes.
5. Mapa: uma vista de localização que posiciona os objetos monitorados no mapa e permite filtrá-los por condição de limiar. Isso é útil quando armazéns ou outros sites estão distribuídos em várias localidades.

O backend recupera dados e armazena a configuração da aplicação. O frontend calcula o estado visual atual a partir da última resposta, de modo que o status da zona não precisa ser mantido como um registro separado no servidor.

Camada 1: Acessar dados de sensores diretamente pelo IoT Query

No login, o backend da Sensoriqua envia as credenciais do usuário para o Navixy App Connect. Essa ferramenta funciona como gateway de integração: mantém a autenticação da plataforma e o acesso a bancos no contexto de aplicação da Navixy, enquanto a Sensoriqua trata o fluxo específico do cliente.

As leituras estão disponíveis em raw_telematics_data e raw_business_data, com valores de sensores expostos como colunas, e não como linhas. Para preencher a lista de sensores disponíveis de cada objeto, a Sensoriqua consulta dinamicamente os conjuntos de colunas em inputs, states e tracking_data_core.

Explore os detalhes da camada Raw data do IoT Query na documentação da Navixy para analistas.

Assim, um operador que configura o sistema de monitoramento de sensores vê os nomes de dispositivos que realmente existem nos dados do cliente, em vez de escolher em uma lista estática predefinida.

O acesso SQL direto também dá ao integrador controle sobre como esses dados são consultados. A aplicação pode, por exemplo, calcular médias de 1 minuto, alterar janelas de sparkline ou pedir um período histórico específico sem um endpoint extra em um contrato REST fixo.

A consulta e a interface podem, portanto, ser adaptadas ao fluxo de monitoramento do cliente, enquanto o IoT Query permanece a camada de dados subjacente.

Camada 2: Configurar sensores independentemente dos rastreadores

A segunda camada é um mapa persistente de sensores que define quais sensores pertencem a cada zona e como suas leituras devem ser interpretadas.

Cada sensor configurado armazena:

• o objeto e a coluna da tabela-fonte da qual lê
• um rótulo legível
• um multiplicador, usado como fator de escala antes da exibição para conversão de unidades ou calibração
• limiares MIN e MAX, que definem a faixa operacional usada para o status visual
• uma profundidade de sparkline, que define quantas horas de médias de 1 minuto o widget exibe: 1, 2, 4 ou 8 horas

Os sensores são organizados em planos de dashboard nomeados, ou painéis que correspondem a zonas físicas como uma câmara fria, uma fileira de racks ou um setor de estufa.

Um mesmo dashboard pode conter vários planos, e cada plano contém os sensores atribuídos àquele local. Isso separa a forma como os usuários trabalham com a interface de monitoramento da estrutura de rastreadores usada para transportar as leituras originais.

O mapa de sensores é armazenado no banco de estado da aplicação.

Camada 3: Calcular o status ao vivo da zona a partir de leituras recentes

O painel ao vivo usa polling em vez de atualizações push. Ele recupera dados novos em um intervalo configurável de 30 segundos, 1 minuto ou 5 minutos.

Os endpoints de dados ao vivo consultam o PostgreSQL do IoT Query diretamente e devolvem os valores. A avaliação de limiares então ocorre no navegador.

Depois de aplicar o multiplicador configurado, o frontend compara cada leitura com os limites MIN e MAX. Um valor fora de qualquer um dos limites muda o status daquele sensor para vermelho. Se qualquer sensor de uma zona estiver vermelho, o painel da zona também é exibido em vermelho. Se todos os sensores configurados permanecerem dentro dos limiares, o painel é verde. Um sensor neutro não tem limiar configurado.

Essa arquitetura mantém o backend sem estado em relação à saúde da zona. Ele armazena configuração e recupera leituras, enquanto o status atual da zona é recalculado a partir do último polling bem-sucedido.

Na implementação atual, a aplicação não mantém um registro no servidor do momento em que um limiar foi cruzado. Também não envia notificações push nem enfileira alertas. Se o polling falhar, os valores exibidos permanecem inalterados até a próxima solicitação bem-sucedida.

Revisar leituras históricas e relatórios diários

O painel ao vivo responde se uma zona monitorada está agora dentro da faixa. As vistas de histórico e relatórios da Sensoriqua fornecem as leituras de fundo para uma revisão de mais longo prazo.

O endpoint de histórico aceita um ID de objeto, um nome de sensor e um intervalo de tempo, e então recupera leituras brutas do IoT Query por um período de até 90 dias. A aplicação as renderiza como um gráfico interativo com faixas de limiar sobrepostas.

A vista de relatório agrega a série temporal em estatísticas diárias para cada sensor:

• mínimo
• máximo
• média

Os relatórios podem ser exportados em vários formatos:

• JSON: agregados diários brutos
• HTML e PDF: tabelas formatadas com gráficos embutidos
• XLSX: saída de planilha

A agregação e a renderização ocorrem no navegador. O backend permanece a camada de recuperação de dados, enquanto a aplicação cliente gera e baixa o relatório sem uma etapa extra de renderização no servidor.

Adicionar contexto geográfico às exceções de sensores

O IoT Query também dá à Sensoriqua acesso aos dados de localização associados aos objetos monitorados. A vista de mapa da Sensoriqua plota a última posição GPS de cada objeto junto com as leituras recentes. Os operadores podem filtrar o mapa por entidade de negócio e condição de limiar.

Para um cliente que opera vários armazéns ou sites técnicos, o operador pode filtrar objetos com leituras fora da faixa, localizar o site relevante e abrir a vista detalhada de sensores.

O objeto não precisa se mover para que a localização seja útil. Um gateway estacionário pode identificar um armazém fixo ou um site técnico no mapa.

Construir a aplicação de monitoramento na camada de dados do IoT Query

A camada de dados brutos do IoT Query permite à Sensoriqua acessar o fluxo de sensores via PostgreSQL sem introduzir uma API de middleware separada nem um pipeline ETL sob medida.

As leituras são expostas em uma estrutura de colunas consistente. Os desenvolvedores da Sensoriqua adicionaram configuração de zonas e avaliação de limiares sem alterar os dados de origem.

Do ponto de vista da Sensoriqua, as tabelas do IoT Query permanecem somente leitura. O sistema de monitoramento de sensores atua como camada de aplicação e visualização, em vez de criar outra cópia dos dados telemáticos.

O Navixy IoT Logic, uma ferramenta de automação de processos de dados, pode executar regras contra o mesmo fluxo de forma independente. Isso mantém a apresentação dos dados na aplicação sob medida separada da automação de fluxos.

Usar a Sensoriqua como implementação de referência

Para provedores de serviços telemáticos e integradores de sistemas, o caso destaca como uma aplicação sob medida pode ser construída com capacidades existentes da Navixy:

• autenticação App Connect
• consultas PostgreSQL diretas ao IoT Query
• um esquema persistente de zona e configuração de sensores
• avaliação de limiares no cliente
• consultas de dados históricos
• exportações de resumo diário
• filtragem geográfica de objetos monitorados

A Sensoriqua usa esses blocos para criar um sistema de monitoramento de sensores por zona. Um integrador pode usar o mesmo modelo de acesso a dados para outras aplicações, incluindo vistas de saúde de equipamentos, dashboards operacionais específicos do cliente, relatórios sob medida, telas de monitoramento ambiental ou ferramentas de monitoramento baseadas em mapa.

Se o fluxo de monitoramento do seu cliente não puder ser representado de forma eficaz em um dashboard padrão, entre em contato com a equipe Navixy para discutir opções de construção de uma aplicação IoT Query sob medida.