Comment construire un système de surveillance de capteurs en temps réel pour les entrepôts et au-delà

Si vous concevez des flux pour des entrepôts, des sites de chaîne du froid ou des installations techniques, cette étude de cas montre comment transformer des données télématiques existantes en un système de surveillance de capteurs dédié, sans ajouter un pipeline de données séparé. Elle détaille aussi l'architecture de l'application : accès PostgreSQL, configuration des capteurs, logique de seuils en direct, historique, rapports et cartographie.

Prenez un entrepôt où les relevés de température et d'humidité sont déjà collectés via des appareils connectés. L'équipe opérations n'a pas forcément besoin d'un nouvel écran organisé par traceurs et identifiants de capteurs. Elle peut avoir besoin d'une réponse plus simple : quelles chambres froides ou zones de stockage sont actuellement dans la plage configurée ?

IoT Query, la plateforme d'analytique de flotte de Navixy, fournit un accès structuré aux données de flotte et de capteurs via PostgreSQL, tandis que l'intégrateur définit l'interface autour du flux du client. Sensoriqua, une application construite par un partenaire Navixy, illustre cette approche. Elle groupe des canaux de capteurs individuels par zone physique, applique des limites configurées et affiche l'état opérationnel avant les valeurs brutes.

Un code couleur clair dans l'interface rend l'état plus facile à lire sans vérifier chaque relevé. Le vert signifie que tous les relevés configurés d'une zone sont dans la plage définie. Le rouge signale une zone où au moins un capteur est hors de son seuil. Un état neutre signifie qu'aucun seuil n'a été configuré pour ce capteur.

Où s'applique la surveillance de capteurs par zone

Le même modèle d'application peut servir plusieurs scénarios où les utilisateurs travaillent avec des lieux physiques plutôt qu'avec des identifiants d'appareils :

• Les clients pharmaceutiques et d'entrepôts alimentaires peuvent avoir besoin d'enregistrements de température et d'humidité organisés par zone de stockage et documentés selon les normes GxP ou de conformité de la chaîne du froid. Pour une piste d'audit, la question pertinente est quelle zone est restée dans la plage spécifiée, plutôt que quel identifiant d'appareil a produit un relevé.
• Les clients de data centers et de salles serveurs peuvent avoir besoin d'un état par rangée de racks ou par salle, afin qu'une équipe opérations vérifie une zone précise sans recouper un tableur.
• Les clients de salles blanches et de laboratoires surveillent des conditions environnementales qui peuvent varier d'une zone à l'autre d'un espace contrôlé.
• Les clients de serres et d'agriculture peuvent surveiller des microclimats par secteur de culture, là où les conditions diffèrent d'une section à l'autre d'un même site.
• Les opérateurs de musées et d'archives peuvent organiser la surveillance de température et d'humidité par salle, en reliant les relevés aux espaces où sont conservées les collections.
• Les clients industriels peuvent grouper des données d'état d'équipement par ligne de production, atelier ou aile de bâtiment.

Dans chaque cas, IoT Query fournit les données télématiques et de capteurs. L'intégrateur détermine comment l'application associe ces relevés aux lieux et aux concepts d'exploitation du client.

De quoi se compose un système de surveillance de capteurs sur mesure

Sensoriqua est une implémentation de référence construite par un partenaire Navixy pour un type de flux précis. L'application s'appuie sur Navixy IoT Query, avec un accès SQL direct aux données de capteurs.

Son architecture combine trois couches applicatives principales, plus l'historique, les rapports et la carte :

1. Accès aux données : une connexion PostgreSQL directe à une base dans IoT Query.
2. Configuration des capteurs : un mapping persistant entre objets source, canaux de capteurs, zones définies par le client, seuils, facteurs d'échelle et libellés d'affichage. Les données de capteurs peuvent être organisées indépendamment des traceurs qui les ont livrées.
3. Tableau de bord live : un dashboard qui interroge les valeurs récentes à un intervalle configurable, évalue les seuils dans le navigateur et présente un état agrégé par zone.
4. Historique et rapports : une vue de requête pour comparer les relevés dans le temps, examiner les minimum, maximum et moyenne quotidiens, et identifier des anomalies ou des schémas récurrents.
5. Carte : une vue de localisation qui place les objets surveillés sur une carte et permet de les filtrer par condition de seuil. C'est utile lorsque les entrepôts ou d'autres sites sont répartis sur plusieurs emplacements.

Le backend récupère les données et stocke la configuration de l'application. Le frontend calcule l'état visuel courant à partir de la dernière réponse, de sorte que l'état de zone n'a pas besoin d'être maintenu comme un enregistrement serveur distinct.

Couche 1 : Accéder aux données de capteurs directement via IoT Query

Lors de la connexion, le backend Sensoriqua envoie les identifiants de l'utilisateur à Navixy App Connect. Cet outil sert de passerelle d'intégration : il conserve l'authentification plateforme et l'accès aux bases dans le contexte applicatif Navixy, tandis que Sensoriqua gère le flux spécifique au client.

Les relevés sont disponibles via raw_telematics_data et raw_business_data, avec les valeurs de capteurs exposées en colonnes plutôt qu'en lignes. Pour remplir la liste des capteurs disponibles pour chaque objet, Sensoriqua interroge dynamiquement les ensembles de colonnes de inputs, states et tracking_data_core.

Explorez le détail de la couche Raw data d'IoT Query dans la documentation Navixy destinée aux analystes.

Ainsi, un opérateur qui configure le système de surveillance de capteurs voit les noms d'appareils réellement présents dans les données du client, plutôt qu'une liste statique prédéfinie.

L'accès SQL direct donne aussi à l'intégrateur le contrôle de la façon dont ces données sont interrogées. L'application peut, par exemple, calculer des moyennes d'une minute, modifier les fenêtres de sparkline ou demander une période historique précise sans endpoint supplémentaire dans un contrat REST figé.

La requête et l'interface peuvent donc s'adapter au flux de surveillance du client, tandis qu'IoT Query reste la couche de données sous-jacente.

Couche 2 : Configurer les capteurs indépendamment des traceurs

La deuxième couche est une carte persistante des capteurs, qui définit lesquels appartiennent à chaque zone et comment interpréter leurs relevés.

Chaque capteur configuré stocke :

• l'objet et la colonne de table source dont il lit
• un libellé lisible
• un multiplicateur, utilisé comme facteur d'échelle avant affichage pour conversion d'unités ou calibration
• des seuils MIN et MAX, qui définissent la plage d'exploitation utilisée pour l'état visuel
• une profondeur de sparkline, qui définit combien d'heures de moyennes d'une minute le widget affiche : 1, 2, 4 ou 8 heures

Les capteurs sont organisés en plans de dashboard nommés, ou panneaux qui correspondent à des zones physiques telles qu'une chambre froide, une rangée de racks ou un secteur de serre.

Un même dashboard peut contenir plusieurs plans, et chaque plan contient les capteurs assignés à ce lieu. Cela sépare la façon dont les utilisateurs travaillent avec l'interface de surveillance de la structure de traceurs qui a transporté les relevés d'origine.

La carte des capteurs est stockée dans la base d'état de l'application.

Couche 3 : Calculer l'état live de la zone à partir des relevés récents

Le tableau de bord live utilise le polling plutôt que des mises à jour push. Il récupère des données fraîches à un intervalle configurable de 30 secondes, 1 minute ou 5 minutes.

Les endpoints de données live interrogent PostgreSQL d'IoT Query directement et renvoient les valeurs. L'évaluation des seuils s'exécute ensuite dans le navigateur.

Après application du multiplicateur configuré, le frontend compare chaque relevé à ses bornes MIN et MAX. Une valeur hors de l'une ou l'autre borne passe le statut de ce capteur au rouge. Si un capteur d'une zone est rouge, le panneau de zone s'affiche aussi en rouge. Si tous les capteurs configurés restent dans leurs seuils, le panneau est vert. Un capteur neutre n'a pas de seuil configuré.

Cette architecture garde le backend sans état vis-à-vis de la santé de zone. Il stocke la configuration et récupère les relevés, tandis que l'état courant de zone est recalculé à partir du dernier polling réussi.

Dans l'implémentation actuelle, l'application ne conserve pas d'enregistrement serveur de l'instant où un seuil a été franchi. Elle n'envoie pas non plus de notifications push ni ne met d'alertes en file. Si le polling échoue, les valeurs affichées restent inchangées jusqu'à la prochaine requête réussie.

Consulter l'historique des relevés et les rapports quotidiens

Le tableau de bord live répond à la question immédiate : la zone surveillée est-elle actuellement dans la plage. Les vues d'historique et de rapports de Sensoriqua fournissent les relevés sous-jacents pour un examen plus long.

L'endpoint d'historique accepte un identifiant d'objet, un nom de capteur et une plage temporelle, puis récupère les relevés bruts d'IoT Query pour une période allant jusqu'à 90 jours. L'application les rend sous forme de graphique interactif avec des bandes de seuils superposées.

La vue rapport agrège la série temporelle en statistiques quotidiennes pour chaque capteur :

• minimum
• maximum
• moyenne

Les rapports peuvent être exportés dans plusieurs formats :

• JSON : agrégats quotidiens bruts
• HTML et PDF : tableaux formatés avec graphiques intégrés
• XLSX : sortie tableur

L'agrégation et le rendu ont lieu dans le navigateur. Le backend reste la couche de récupération des données, tandis que l'application cliente génère et télécharge le rapport sans étape de rendu serveur supplémentaire.

Ajouter un contexte géographique aux exceptions de capteurs

IoT Query donne aussi à Sensoriqua accès aux données de localisation associées aux objets surveillés. La vue carte de Sensoriqua place la dernière position GPS de chaque objet avec ses relevés récents. Les opérateurs peuvent filtrer la carte par entité métier et condition de seuil.

Pour un client qui exploite plusieurs entrepôts ou sites techniques, l'opérateur peut filtrer les objets hors plage, localiser le site concerné et ouvrir sa vue détaillée des capteurs.

L'objet n'a pas besoin de bouger pour que la localisation soit utile. Une passerelle stationnaire peut identifier un entrepôt fixe ou un site technique sur la carte.

Construire l'application de surveillance sur la couche de données IoT Query

La couche de données brutes d'IoT Query permet à Sensoriqua d'accéder au flux de capteurs via PostgreSQL sans introduire d'API middleware séparée ni de pipeline ETL sur mesure.

Les relevés sont exposés dans une structure de colonnes cohérente. Les développeurs de Sensoriqua ont ajouté la configuration de zones et l'évaluation des seuils sans modifier les données source.

Du point de vue de Sensoriqua, les tables IoT Query restent en lecture seule. Le système de surveillance de capteurs agit comme une couche d'application et de visualisation, plutôt que de créer une autre copie des données télématiques.

Navixy IoT Logic, un outil d'automatisation des processus de données, peut exécuter des règles sur le même flux de façon indépendante. Cela sépare la présentation des données dans l'application sur mesure de l'automatisation des flux.

Utiliser Sensoriqua comme implémentation de référence

Pour les fournisseurs de services télématiques et les intégrateurs, l'étude de cas montre comment une application sur mesure peut s'appuyer sur des capacités Navixy existantes :

• authentification App Connect
• requêtes PostgreSQL directes vers IoT Query
• un schéma persistant de zones et de configuration de capteurs
• évaluation des seuils côté client
• requêtes de données historiques
• exports de synthèse quotidienne
• filtrage géographique des objets surveillés

Sensoriqua utilise ces blocs pour créer un système de surveillance de capteurs par zone. Un intégrateur peut réutiliser le même modèle d'accès aux données pour d'autres applications : vues d'état d'équipement, dashboards opérationnels spécifiques au client, rapports sur mesure, écrans de surveillance environnementale ou outils de surveillance cartographique.

Si le flux de surveillance de votre client ne peut pas être représenté efficacement dans un dashboard standard, contactez l'équipe Navixy pour discuter des options de construction d'une application IoT Query sur mesure.