Logistique

Étude de cas Logistique et Recueil de recettes SQL

circle-exclamation

La logistique est un écosystème complexe impliquant la coordination du transport, des opérations d'entrepôt, des stocks et de l'exécution des livraisons. L'intégration de la télématique dans les processus logistiques permet aux entreprises de collecter des données temps réel sur les véhicules, les conducteurs, les itinéraires et les conditions de cargaison, ce qui améliore considérablement la prise de décision et l'efficacité opérationnelle.

Navixy IoT Query, avec ses capacités robustes d'ingestion de données et d'analyse de séries temporelles, soutient la transformation numérique des opérations logistiques en permettant une visibilité approfondie à chaque étape du cycle de vie. Ses capacités robustes d'ingestion télématique fournissent une visibilité complète sur ces opérations. Les données GPS en temps réel, le diagnostic des données des capteurs, le géorepérage et l'analyse des capteurs permettent aux opérateurs logistiques de numériser les flux de travail, d'automatiser les contrôles et de prendre des décisions éclairées.

Phase du cycle de vie
Objectifs
Cas d'utilisation couverts / Recettes

Gestion des itinéraires

Optimiser le routage des véhicules, assurer un dispatch efficace et réduire les retards

Nombre de trajets par jour Compte kilométrique par véhicule et par jour (7 derniers jours)

Surveillance de la cargaison

Garantir des conditions de transport appropriées pour les marchandises sensibles

Événements de violation de température (et d'humidité) au cours des 7 derniers jours

Exploitation des véhicules

Suivre l'utilisation de la flotte, assurer la maintenance et réduire les temps d'immobilisation

Résumé des heures moteur par véhicule / conducteur / jour (7 derniers jours) Analyse des temps d'immobilisation des véhicules Suivi des actifs sans mouvement

Sécurité et sûreté des itinéraires

Détecter les usages abusifs, les activités non autorisées et les violations de sécurité

Détection de déviation d'itinéraire - Arrêts non autorisés (24 dernières heures) Détection d'utilisation hors heures

Gestion de la conformité

Surveiller le comportement des conducteurs, appliquer les politiques et la conformité opérationnelle

Résumé des heures moteur par véhicule / conducteur / jour (7 derniers jours) Détection d'utilisation hors heures

Analyse post-livraison

Évaluer l'efficacité opérationnelle et la performance historique

Rapport de journal d'événements du véhicule Compte kilométrique par véhicule et par jour (7 derniers jours) Nombre de trajets par jour Suivi des actifs sans mouvement

Suivi des actifs sans mouvement

Ce cas identifie les actifs (par ex., véhicules ou remorques) qui n'ont pas modifié leurs GPS comparer le coordonnées minimales et maximales pendant la période. Si les deux valeurs se situent dans une fourchette très étroite (un seuil de tolérance, par ex. ±0,01 degré), nous signalons l'actif comme immobile. La requête effectue également une jointure avec les tables objects et vehicles dans raw_business_data pour récupérer des libellés d'actifs significatifs pour la sortie des résultats.

Analyse des temps d'immobilisation des véhicules

Ce cas se concentre sur l'analyse de la durée pendant laquelle les véhicules sont non opérationnels en raison de la maintenance, de pannes ou d'inactivité. Les indicateurs de temps d'immobilisation sont cruciaux pour les opérations logistiques afin de surveiller la santé de la flotte, réduire les temps d'arrêt et améliorer l'utilisation globale et l'efficacité de la planification.

Le cœur de l'analyse des temps d'immobilisation repose sur l'utilisation de la table vehicle_service_tasks de raw_business_data, qui enregistre à la fois les événements de maintenance planifiés et non planifiés. Chaque tâche contient une start_date et une end_date, représentant la période d'immobilisation. En filtrant pour les tâches de service terminées, nous pouvons calculer la durée exacte pendant laquelle chaque véhicule était hors service.

La requête calcule le temps d'immobilisation total par véhicule en sommant les durées de toutes ses tâches de service (en heures). Elle permet également une ventilation entre maintenance planifiée et non planifiée en utilisant le drapeau is_unplanned. Pour rendre les résultats plus exploitables, elle effectue une jointure avec la table vehicles afin d'inclure les libellés des véhicules, les numéros d'immatriculation et les informations de modèle.

Détection de déviation d'itinéraire

Ce cas identifie les instances où les véhicules s'écartent de leurs itinéraires assignés ou attendus — en particulier des zones géorepérées ou des corridors de livraison. Le suivi de ces déviations aide à garantir la conformité des itinéraires, à réduire les retards, à détecter les comportements de conduite à risque et à maintenir les SLA de livraison.

Cette logique compare les positions GPS réelles du véhicule provenant de tracking_data_core (dans le schéma raw_telematics_data) aux zones géographiques prédéfinies de la table zones dans raw_business_data. Ces zones représentent des itinéraires assignés ou des segments d'itinéraire. En utilisant des comparaisons géométriques via ST_DWithin, nous déterminons si un point est à l'intérieur ou à l'extérieur de la zone tampon de l'itinéraire.

La requête associe chaque position GPS à chaque zone d'itinéraire connue en utilisant un CROSS JOIN, puis applique ST_DWithin() pour vérifier si le véhicule se trouvait à l'intérieur du corridor autorisé. Nous isolons les lignes où le véhicule était en dehors de toutes les routes géorepérées et les signalons comme des déviations. La sortie finale répertorie ces déviations, incluant l'appareil, l'horodatage, le libellé du véhicule et la distance entre le point et le centre de la zone la plus proche.

Résumé des heures moteur par véhicule / conducteur / jour (7 derniers jours)

Ce cas mesure la durée pendant laquelle les moteurs ont été actifs pour chaque véhicule sur une base quotidienne, permettant aux gestionnaires de flotte de suivre l'utilisation, d'identifier la surutilisation ou la sous-utilisation, et de corréler l'activité avec les affectations de conducteurs. Lorsqu'il est lié aux conducteurs, il prend également en charge la validation des heures de travail et l'analyse de performance.

La table states dans raw_telematics_data enregistre des indicateurs d'état moteur en séries temporelles, généralement avec un state_name comme 'ignition' et une valeur de 1 (allumé) ou 0 (éteint). Pour calculer les heures moteur, nous trouvons toutes les transitions horodatées pour chaque appareil et calculons les durées pendant lesquelles le moteur était allumé (1).

Pour lier l'activité moteur à la fois aux véhicules et aux conducteurs, nous utilisons les tables objects, vehicles et driver_history de raw_business_data. Nous associons chaque enregistrement d'état au conducteur courant sur cet objet (via l'historique d'affectation des conducteurs) et au véhicule correspondant. Nous groupons ensuite les données par jour, véhicule et conducteur, en sommant le temps moteur actif total (en heures).

Événements de violation de température (et d'humidité) au cours des 7 derniers jours

Ce cas identifie des relevés de capteurs — tels que température ou humidité — qui dépassent des seuils critiques pendant le transport. La surveillance de telles violations est vitale pour les industries transportant des produits périssables (par ex., alimentaire, pharmaceutique) afin d'assurer la conformité à la chaîne du froid et d'empêcher la détérioration.

Cette requête extrait les données d'entrée des capteurs de la table inputs dans le schéma raw_telematics_data. Chaque ligne représente une lecture de capteur (par ex., température, humidité) enregistrée à un horodatage spécifique par un appareil. Nous filtrons ces enregistrements pour n'inclure que ceux des 7 derniers jours.

La logique principale de filtrage est basée sur les motifs de nom de capteur et une comparaison de leurs valeurs numériques par rapport aux seuils (par ex., >25°C pour la température, >80% pour l'humidité). Parce que la valeur est stockée en tant que texte, nous la convertissons en numérique avant d'appliquer les conditions de seuil. Pour enrichir les résultats, nous effectuons une jointure avec la table objects afin de récupérer les libellés des véhicules ou des actifs, ce qui améliore l'interprétabilité pour les gestionnaires de flotte.

Arrêts non autorisés (24 dernières heures)

Ce cas identifie les arrêts non autorisés ou non planifiés effectués par les véhicules au cours des 24 dernières heures. Il aide à détecter d'éventuelles violations des itinéraires de livraison, des pauses non autorisées ou des temps d'inactivité pouvant affecter l'efficacité énergétique et la performance des SLA.

La requête analyse les points de localisation avec une vitesse faible ou nulle en utilisant la requête La requête utilise la table tracking_data_core de raw_telematics_data pour extraire des données de localisation en séries temporelles et la vitesse. Un arrêt est détecté lorsque la vitesse descend en dessous de 3 km/h pendant une durée de plus de 2 minutes. En utilisant les fonctions LAG et LEAD, la requête segmente ces périodes de faible vitesse pour déterminer les horodatages de début et de fin de l'arrêt.

Pour détecter les arrêts non autorisés, elle filtre les emplacements qui se trouvent à l'intérieur des zones géorepérées connues (table zones) en utilisant ST_DWithin de PostGIS. Seuls les arrêts en dehors de tout tampon de zone sont signalés. Le résultat inclut l'ID du véhicule, le libellé de l'objet, l'immatriculation, les horodatages, la durée et les coordonnées pour chaque arrêt.

Détection d'utilisation hors heures

Ce cas identifie les instances où les véhicules sont exploités en dehors des heures normales de bureau — définies ici comme du lundi au vendredi, 09:00–18:00. De telles détections sont essentielles pour signaler l'utilisation non autorisée, identifier un potentiel mauvais usage du véhicule, et améliorer la sécurité des actifs.

La logique est basée sur la table tracking_data_core de raw_telematics_data, qui enregistre des événements GPS horodatés par appareil. Nous dérivons le jour de la semaine et local heure d'utilisation à partir de chaque entrée device_time et filtrons les enregistrements en dehors de la fenêtre d'activité définie

(c.-à-d. avant 9h, après 18h ou à tout moment le week-end). Pour plus de clarté, nous enrichissons les données GPS avec les métadonnées d'objet et de véhicule de raw_business_data (par ex., libellé du véhicule, immatriculation, ID d'objet). Pour des résumés plus pertinents, nous agrégons optionnellement l'utilisation pour compter combien d'événements hors heures

ROUND(longitude::numeric, 6) AS lon

Nombre de trajets par jour Ce cas mesure combien de trajets chaque véhicule effectue quotidiennement et quelle distance ils parcourent, aidant les équipes logistiques à évaluerl'utilisation des véhicules

, optimiser les itinéraires et détecter des anomalies comme des trajets incomplets ou des utilisations non signalées. Pour définir untrajet , nous utilisons un changement d'état de mouvement du véhicule — c.-à-d. transition de l'arrêt au mouvement puis retour à l'arrêt. En utilisant les valeurs de vitesse de la table tracking_data_core, la requête segmente les données en fonction de ces transitions. Un trajet est identifié comme une période de mouvement continue

où la vitesse reste au-dessus d'un seuil (par ex., >5 km/h).

  • Chaque trajet inclut : A horodatage et localisation de départ (premier point en mouvement)

  • Un horodatage et localisation de fin (dernier point en mouvement avant l'arrêt)

  • Le distance de Haversine entre les positions de départ et d'arrivée

Nous calculons le nombre de trajets et la distance totale par jour et par véhicule, éventuellement enrichis avec les étiquettes de véhicule depuis la table vehicles.

Nombre de kilomètres par véhicule et par jour (7 derniers jours)

Ce cas calcule le kilométrage quotidien (en kilomètres) pour chaque véhicule au cours des 7 derniers jours. Il est fondamental pour le suivi de l'utilisation des véhicules, la surveillance de l'efficacité énergétique, la planification de la maintenance, et la détection de sous-utilisation ou de surutilisation.

Nous extrayons tous les enregistrements GPS depuis tracking_data_core pour les 7 derniers jours. Chaque point GPS possède un horodatage, une latitude et une longitude. Pour chaque véhicule et chaque jour, nous :

  1. Trions les points GPS chronologiquement par appareil.

  2. Calculons la distance entre points consécutifs en utilisant la formule de Haversine.

  3. Sommons les distances par jour et par appareil pour obtenir le kilométrage total.

Cette approche fournit une grande précision sans dépendre de capteurs d'odomètre externes. Optionnellement, la requête effectue une jointure avec objects et vehicles pour enrichir les résultats avec les métadonnées des actifs.

Rapport de journal d'événements du véhicule

Ce cas fournit un rapport complet de tous les événements liés aux véhicules (par ex. : mise en marche, porte ouverte, freinage brusque, etc.) sur l'ensemble de la flotte. Il inclut le type d'événement, l'horodatage, et le contexte du véhicule, permettant aux équipes opérationnelles d'auditer les comportements, de suivre les activités anormales ou de générer des alertes et des analyses.

La source principale est la table states du schéma raw_telematics_data. Chaque ligne inclut : device_id (source de l'événement), device_time (horodatage), state_name (étiquette de l'événement), et value (statut ou mesure).

Pour créer un rapport exploitable :

  1. Nous extrayons tous les enregistrements des 7 derniers jours.

  2. Les grouper par le type d'événement, véhicule, et date pour fournir un compte du nombre de fois que chaque événement est survenu et quand il est survenu.

  3. Enrichir les résultats avec les métadonnées du véhicule (vehicle_label, registration_number, object_label) via objects et vehicles.

Cela fournit une chronologie quotidienne des événements sur l'ensemble de la flotte - essentielle pour le diagnostic, l'analyse comportementale et la maintenance proactive.

Mis à jour

Ce contenu vous a-t-il été utile ?