Intégration des données télématiques avec HTTP Push dans IoT Logic

Dans de nombreux secteurs, les applications télématiques ont souvent besoin de davantage de contexte que les seules données des véhicules et des appareils peuvent fournir. Par exemple, il peut être nécessaire de combiner le kilométrage avec les données du dernier entretien provenant d’un système de maintenance. Il existe plusieurs façons de réunir ces données, et le choix effectué influe sur la quantité de code, d’infrastructure et de maintenance continue nécessaire à l’intégration.

L’enrichissement HTTP Push, récemment ajouté à IoT Logic de Navixy, offre un moyen direct d’intégrer des données externes au traitement télématique. Voyons plus en détail comment il fonctionne, ce qu’il permet de créer et ce qu’il change du côté de l’intégration.

Qu’est-ce que l’enrichissement HTTP Push ?

L’enrichissement HTTP Push permet à un système externe d’envoyer des données directement à Navixy IoT Logic, un environnement low-code permettant de traiter et de transformer les données télématiques provenant d’appareils IoT et de systèmes OEM.

Le système externe envoie une requête HTTP contenant ses données. Un mapping configuré associe les données entrantes au tracker correspondant et rend les attributs disponibles pour traitement dans IoT Logic.

La télémétrie du tracker et les données externes arrivent indépendamment.

Prenons le cas d’un tracker qui transmet :

hardware_mileage = 197450

tandis qu’un système de gestion de la maintenance de flotte envoie le kilométrage enregistré lors du dernier entretien :

{
  "vehicle_ref": "VEH-318",
  "odometer_at_service": 182300
}

Les deux valeurs sont désormais disponibles dans IoT Logic. Un flux peut calculer que le véhicule a parcouru 15 150 kilomètres depuis l’entretien enregistré et utiliser le résultat dans les traitements suivants.

Le système de maintenance ne devient pas une autre source de télémétrie. Il fournit les informations qu’il détient, tandis que le tracker continue de transmettre indépendamment les données du véhicule.

Ce que les données externes apportent à un flux télématique

L’intégration d’une valeur externe dans IoT Logic est utile lorsque cette valeur peut modifier ce que le flux calcule, décide ou exécute. Deux scénarios l’illustrent particulièrement bien.

Pour une présentation plus générale des applications métier de cette approche, consultez notre article consacré à l’enrichissement des données des véhicules.

Créer des conditions à partir de deux sources de données

Certaines règles opérationnelles nécessitent à la fois des données télématiques et des informations provenant d’autres systèmes.

Prenons le cas d’un tracker qui signale qu’un véhicule frigorifique est entré dans la géofence d’un dépôt, tandis qu’un système externe fournit :

inspection_required = true

IoT Logic peut évaluer ces deux informations et utiliser le résultat pour déclencher l’étape suivante du workflow.

Le même modèle permet de combiner la localisation, le mouvement, le kilométrage, les relevés de capteurs ou d’autres données télématiques avec des autorisations, des affectations, des informations de maintenance, des statuts opérationnels et d’autres attributs externes.

L’application externe fournit le contexte dont elle dispose. IoT Logic applique ce contexte aux données du tracker, de sorte qu’aucun des deux systèmes n’a besoin de contenir à lui seul l’intégralité de la règle opérationnelle.

Déclencher une action télématique depuis un autre système

Les données externes peuvent également initier un workflow dans l’autre sens.

Une application peut savoir qu’une action doit être effectuée sur un véhicule sans disposer d’un canal de communication direct avec son tracker. Par exemple, un autre système peut envoyer :

immobilization_requested = true

La requête peut entrer dans IoT Logic via HTTP Push. Le flux peut évaluer les éventuelles conditions supplémentaires et, lorsque la configuration du flux et les capacités du tracker le permettent, déclencher l’action correspondante sur l’appareil.

L’application externe n’a pas besoin d’implémenter elle-même la couche de communication avec l’appareil. Elle fournit la requête au niveau métier, tandis que Navixy gère la communication du côté télématique.

Pour les développeurs de solutions, cela crée une séparation utile. Une application destinée au client peut participer à des workflows liés aux appareils sans avoir à implémenter également les protocoles des trackers et l’envoi des commandes.

Mapper les identifiants externes aux trackers

Le système source n’a pas besoin d’identifier un actif de la même manière que Navixy. Un système de gestion de la maintenance de flotte, par exemple, peut déjà utiliser ses propres références de véhicules :

VEH-318
VEH-319
VEH-320

Lors de la configuration de l’enrichissement HTTP Push, un paramètre approprié des données entrantes peut être utilisé comme clé primaire afin de mapper ces valeurs aux trackers :

VEH-318 → tracker 12345
VEH-319 → tracker 12346
VEH-320 → tracker 12347

Le système de maintenance peut ainsi continuer à envoyer un payload basé sur son propre identifiant :

{
  "vehicle_ref": "VEH-318",
  "maintenance_due": false,
  "work_order": "WO-98311",
  "odometer_at_service": 182300
}

IoT Logic utilise le mapping configuré pour vehicle_ref afin d’associer les données entrantes au tracker correspondant. La traduction des identifiants reste ainsi à la frontière de l’intégration, sans obliger l’application source à adopter les ID des trackers ou un autre identifiant propre à Navixy.

De l’infrastructure d’intégration à la logique métier

Avant l’enrichissement HTTP Push, les données métier externes ne pouvaient pas être intégrées directement à IoT Logic de cette manière. Cela pouvait nécessiter un composant d’intégration entre l’application externe et le traitement télématique.

Même un service relativement simple peut devoir recevoir un payload, identifier l’actif, préparer les données et les transmettre. Le code ne représente qu’une partie du travail. Le service doit également être déployé, hébergé, sécurisé, surveillé, mis à jour, dépanné, documenté et maintenu.

HTTP Push déplace cette partie de l’intégration vers IoT Logic. Le système externe envoie les données, les mappings configurés les associent aux trackers et le flux définit ce qui se passe ensuite.

Dans une solution où un composant personnalisé servirait principalement à recevoir des données externes et à les connecter au traitement télématique, HTTP Push peut supprimer entièrement un composant d’infrastructure. Pour un TSP ou un intégrateur déployant des solutions similaires pour plusieurs clients, cela signifie également un service de moins à déployer et à maintenir pour chaque implémentation.

Cela ne supprime pas le travail d’ingénierie d’intégration. La stratégie d’identification, les mappings, les schémas d’attributs, les identifiants d’accès, les tests et la gestion du cycle de vie restent importants. Ce qui change, c’est l’endroit où une grande partie de ce travail est effectuée : dans la configuration et la logique métier plutôt que dans un service logiciel supplémentaire et son infrastructure associée.

HTTP Push et les autres mécanismes d’intégration de Navixy

HTTP Push, Navixy Generic Protocol et l’API Navixy remplissent des rôles différents.

Mécanisme	Rôle
Enrichissement HTTP Push	Intégrer des attributs externes dans IoT Logic et les associer à un tracker existant afin de les traiter avec sa télémétrie
Navixy Generic Protocol	Connecter une source qui agit comme une source télématique à part entière et fournit sa propre télémétrie
API Navixy	Créer, lire, mettre à jour et supprimer les entités et configurations Navixy prises en charge

La distinction entre HTTP Push et NGP est particulièrement importante.

Avec NGP, le système connecté constitue la source de télémétrie. Avec HTTP Push, la télémétrie du tracker arrive déjà indépendamment, tandis qu’un autre système fournit des informations supplémentaires associées à ce tracker.

Cette distinction définit également une limite technique. Les principaux attributs de positionnement, tels que les coordonnées, la vitesse, le cap, le nombre de satellites et le HDOP, ne peuvent pas être remplacés via l’enrichissement HTTP Push. Si un autre système constitue la véritable source de ces mesures, il doit être connecté en tant que source télématique plutôt que traité comme une source d’enrichissement.

L’API Navixy remplit une autre fonction. Elle fournit des opérations CRUD programmatiques pour les entités et les configurations prises en charge par la plateforme, plutôt qu’une entrée alternative permettant de traiter des données externes arbitraires dans un flux IoT Logic.

Un code d’intégration personnalisé peut toujours être nécessaire dans des cas exceptionnels où les mécanismes disponibles sur la plateforme ne permettent pas de répondre aux exigences de l’intégration. Il ne devrait toutefois pas être nécessaire simplement parce qu’un système tiers possède des données qui doivent participer au traitement dans IoT Logic.

La configuration nécessite toujours un travail d’ingénierie

Déplacer la couche de transport et de mapping vers la configuration ne supprime pas le contrat d’intégration.

Prenons un mapping comme celui-ci :

VEH-318 → tracker 12345

Si le tracker est remplacé ou si l’identifiant externe change, le mapping doit être modifié en conséquence. Des identifiants stables deviennent donc de plus en plus importants à mesure que le déploiement prend de l’ampleur.

Les noms et les types d’attributs nécessitent la même rigueur. Des noms tels que :

maintenance_due
maintenance_work_order
odometer_at_service

sont plus faciles à maintenir que des champs génériques tels que status, id ou value. Et si un flux attend :

{
  "maintenance_due": true
}

remplacer la valeur par "yes" modifie le contrat de la logique qui consomme ces données.

HTTP Push utilise une clé API. L’application émettrice doit donc également protéger cet identifiant comme un secret d’intégration.

Lors de la mise en service, Data Stream Analyzer peut aider à vérifier que l’identifiant, le mapping, les attributs et les traitements en aval attendus arrivent correctement dans le flux.

Pour les déploiements de plus grande envergure, la gestion du cycle de vie des mappings, la gestion des erreurs, les limites de requêtes, la gestion des identifiants d’accès et la surveillance doivent être prises en compte avant le déploiement. Lorsque la documentation actuelle ne précise pas une limite ou un comportement particulier, il convient de le vérifier pour le déploiement concerné plutôt que de concevoir la solution sur la base d’une hypothèse.

Configurer l’enrichissement HTTP Push

L’enrichissement HTTP Push est configuré dans le nœud Data Source d’IoT Logic.

Sélectionnez les trackers qui doivent recevoir les données externes et configurez HTTP Push comme source de données logicielle. Une fois le flux enregistré, IoT Logic fournit l’URL HTTP Push utilisée par l’application externe. Les requêtes sont authentifiées à l’aide d’une clé API.

Ensuite, sélectionnez le paramètre entrant à utiliser comme clé primaire et configurez ses mappings avec les trackers correspondants :

VEH-318 → tracker 12345
VEH-319 → tracker 12346
VEH-320 → tracker 12347

L’application externe peut alors envoyer :

{
  "vehicle_ref": "VEH-318",
  "maintenance_due": false,
  "work_order": "WO-98311",
  "odometer_at_service": 182300
}

IoT Logic résout VEH-318 à l’aide du mapping configuré et rend les attributs envoyés disponibles pour traitement avec les données arrivant indépendamment du tracker.

Pour connaître les champs de configuration exacts et les exigences actuelles de HTTP Push, consultez la documentation relative à l’enrichissement HTTP Push.

Le contexte externe devient partie intégrante de la logique télématique

HTTP Push fournit aux données métier externes une entrée directe dans IoT Logic. Ces données peuvent participer à des conditions avec la télémétrie du tracker ou initier des workflows qui se poursuivent du côté télématique.

Pour les intégrateurs et les développeurs de solutions, cela peut également supprimer une infrastructure dont la seule fonction aurait été d’intégrer ces attributs externes au traitement télématique. Le travail d’ingénierie reste ainsi concentré sur les mappings, les conditions et les actions qui rendent les données combinées utiles.

Vous avez un scénario combinant données externes et télémétrie ? Contactez notre équipe pour discuter de la manière de le mettre en œuvre avec IoT Logic.