Enrichissement des données de véhicule à travers les systèmes d'entreprise

Une plateforme de gestion de flotte en sait déjà beaucoup sur le véhicule. Un système de paiement, l'application d'un fournisseur de batteries ou un répertoire de conducteurs possède d'autres informations tout aussi importantes. Souvent, ces systèmes ne partagent pas naturellement ce qu'ils savent, ce qui pousse à prendre des décisions sans avoir l'ensemble du contexte.

Relier ces éléments manquants signifiait auparavant mettre en place une autre intégration. Avec IoT Logic, nombre d'entre eux peuvent tout simplement devenir partie intégrante du flux de données du véhicule.

Un projet d'intégration de données complet derrière quelques champs supplémentaires

Et ces éléments manquants peuvent être étonnamment modestes, comme un identifiant d'actif stocké dans un ERP, une catégorie de service attribuée par une équipe d'exploitation ou une référence de contrat issue d'un CRM. Pris individuellement, aucun n'est particulièrement intéressant, mais chacun peut devenir utile lorsqu'il est accessible avec les données du véhicule.

Rien de tout cela ne ressemble à un projet d'intégration de données. Pourtant, même le transfert de quelques valeurs d'un système à un autre a traditionnellement nécessité qu'une personne définisse la connexion, la construise, la teste et l'entretienne.

L'entreprise peut avoir besoin de trois champs supplémentaires. La réponse technique peut alors se transformer en une autre intégration personnalisée.

IoT Logic propose une autre approche pour enrichir les données du véhicule. Un système externe peut envoyer des attributs supplémentaires à un dispositif déjà suivi sur la plateforme. Les données entrantes sont associées au dispositif correspondant et rejoignent son flux de données existant, où elles peuvent être utilisées pour un traitement et une automatisation supplémentaires.

Le format de la requête et les détails d'authentification sont expliqués dans la documentation technique. Nous allons ici examiner ce qui arrive aux données une fois qu'elles parviennent à la plateforme.

Comment les données externes rejoignent le flux de données du véhicule

Les données entrantes doivent d'abord identifier le bon véhicule. Le système externe les envoie avec un identifiant, et IoT Logic utilise le mappage configuré pour faire correspondre cet identifiant à un dispositif déjà enregistré sur la plateforme. Les nouveaux attributs viennent ensuite rejoindre le flux de données du dispositif, aux côtés de la télémétrie qu'il communique déjà.

Rien ne change du côté du dispositif. Le traqueur continue de transmettre ses données comme auparavant, tandis que IoT Logic peut utiliser les attributs supplémentaires dans les calculs, les conditions, l'automatisation et tout traitement ultérieur.

Normalement, le flux de télémétrie commence avec le dispositif. Le traqueur envoie un nouveau message, et ce message est traité par IoT Logic pour traitement. Les événements dans d'autres systèmes ne suivent pas nécessairement le même rythme. Un paiement peut être confirmé, un statut peut changer ou un service externe peut générer une nouvelle valeur alors que le véhicule n'a rien de nouveau à signaler.

HTTP Push permet à ces données d'entrer dans le flux au moment où l'événement externe se produit, plutôt que d'attendre le prochain message du dispositif. Par exemple, une confirmation de paiement peut arriver au moment où la transaction est approuvée et devenir partie intégrante de la logique qui détermine la suite du processus.

Enrichissement des données de véhicule dans des flux de travail réels

La suite dépend de l'usage de ces données supplémentaires par la flotte. Un statut de paiement peut déterminer si un véhicule peut être déverrouillé, des conditions météorologiques peuvent influencer la manière dont sa télémétrie est évaluée, tandis que des données issues d'un système métier interne ou d'une plateforme OEM peuvent apporter un contexte que le traqueur ne fournit pas.

Les exemples ci-dessous illustrent ces scénarios dans IoT Logic. Les flux sont présentés à titre d'exemples plutôt que comme des configurations imposées, car les attributs, les conditions et les actions exacts dépendront du système externe, des dispositifs concernés et du flux de travail en cours de création.

La confirmation de paiement peut devenir une action sur le véhicule

Imaginons un opérateur de mobilité partagée qui souhaite que le paiement et l'accès au véhicule se fassent en une seule opération. Le fournisseur de paiement sait quand une transaction est approuvée, tandis que la plateforme de gestion de flotte sait quel véhicule le client essaie d'utiliser. Sans lien entre les deux, le paiement et le contrôle du véhicule restent deux flux de travail séparés.

Le fournisseur de paiement peut envoyer le statut de la transaction avec un identifiant qui le mappe au véhicule concerné. Une fois ce statut intégré au flux de données du véhicule, IoT Logic peut l'utiliser dans la logique qui détermine la suite.

Par exemple, un paiement confirmé pourrait déclencher l'envoi d'une commande de déverrouillage au véhicule. Un paiement refusé ou manquant laisserait le véhicule verrouillé. L'opérateur obtient ainsi un seul flux automatisé au lieu de devoir coordonner séparément le système de paiement et le contrôle du véhicule.

Exemple de flux IoT Logic

Fournisseur de paiement → HTTP Push → Associer la transaction au véhicule → Vérifier le statut de paiement → Envoyer la commande de déverrouillage

Le système externe envoie un attribut tel que payment_status pour le véhicule correspondant. IoT Logic évalue la valeur et, lorsque les conditions requises sont remplies, oriente le message vers le nœud responsable de l'envoi de la commande au dispositif.

Dans un flux en production, un opérateur ajouterait normalement ses propres garanties autour de cette logique, en vérifiant par exemple la référence de transaction, l'état du véhicule ou d'autres conditions requises par le service.

Les données météorologiques peuvent rendre les règles de véhicule plus flexibles

Les règles appliquées aux véhicules fonctionnent souvent avec des seuils fixes. Cela fonctionne jusqu'à ce que les conditions autour du véhicule changent.

Une flotte peut tolérer certains comportements de vitesse, de freinage ou de déplacement sur route sèche et souhaiter une autre approche en cas de forte pluie, de verglas ou de mauvaise visibilité. Le service météorologique possède ce contexte, mais le traqueur lui-même n'est pas tenu de le mesurer.

En enrichissant les données du véhicule avec les conditions météorologiques actuelles d'une source externe, IoT Logic peut prendre en compte ce contexte pour évaluer la télémétrie du véhicule. Le même comportement peut alors produire des résultats différents selon les conditions dans lesquelles il se produit.

Pour un opérateur, cela ouvre la possibilité de règles plus situationnelles sans nécessiter une source supplémentaire de télémétrie au niveau du véhicule.

Exemple de flux IoT Logic

Service météorologique → HTTP Push → Associer les conditions au véhicule → Combiner avec la télémétrie du véhicule → Appliquer une logique spécifique aux conditions → Alerte ou action

Le service externe peut fournir des attributs décrivant les précipitations, la visibilité, la température ou les conditions de route. IoT Logic peut utiliser ces valeurs conjointement avec la télémétrie entrante du véhicule dans des calculs ou une logique conditionnelle.

Par exemple, une règle peut appliquer un seuil de vitesse différent lorsqu'un attribut météorologique mappe des conditions sévères. Les seuils exacts et la réponse demeurent un choix opérationnel plutôt qu'une prescription du mécanisme d'enrichissement lui-même.

Les données métier peuvent accompagner les données du véhicule

Tous les cas d'usage d'enrichissement ne nécessitent pas de contrôler le véhicule. Parfois, l'information utile se trouve déjà dans un système métier interne, mais trop éloignée des données opérationnelles.

Une entreprise peut gérer l'affectation des véhicules, des catégories de service, des références de contrat, des équipes responsables ou d'autres attributs opérationnels dans son ERP, CRM ou application interne. Le personnel de la flotte peut avoir besoin de certaines de ces informations pour examiner l'activité du véhicule ou exécuter des processus automatisés, même si elles n'ont rien à voir avec ce que mesure le traqueur.

Plutôt que de reproduire manuellement ces enregistrements dans la plateforme de flotte, les valeurs pertinentes peuvent être poussées vers le véhicule mappé. Elles deviennent alors disponibles aux côtés de sa télémétrie et peuvent participer au traitement, aux rapports ou à la diffusion des données en aval.

C'est une forme plus discrète d'enrichissement des données du véhicule. Rien de spectaculaire ne se produit pour le véhicule, mais la télémétrie devient bien plus utile aux personnes et aux systèmes qui l'exploitent.

Exemple de flux IoT Logic

ERP / CRM / système interne → HTTP Push → Associer les attributs métier au véhicule → Données de véhicule enrichies → Traitement ou destination en aval

Par exemple, un système interne pourrait envoyer un contract_id, un service_type ou tout autre attribut opérationnel associé au véhicule. IoT Logic peut conserver ce contexte tandis que les données du véhicule progressent dans le flux, permettant à la logique suivante ou aux systèmes en aval de travailler avec la télémétrie et des informations métier.

Les attributs à inclure dans le flux dépendent de l'activité. L'objectif n'est pas de copier l'intégralité d'un enregistrement CRM ou ERP dans la plateforme de flotte, mais de transférer seulement les quelques valeurs qui rendent les données du véhicule plus utiles.

Les données de batterie OEM peuvent combler les lacunes de la télémétrie du traqueur

Les données de batterie constituent un cas légèrement différent, car de nombreux traqueurs rapportent déjà des paramètres liés à la batterie. L'intérêt se manifeste quand un fabricant de véhicules électriques ou un système de gestion de batterie propose des informations que l'appareil télématique installé ne fournit pas.

Une plateforme OEM peut exposer des informations supplémentaires sur l'état de charge, l'état de santé de la batterie, le statut de charge ou tout autre paramètre de batterie via son propre système. Isolées, ces informations coexistent séparément de la télémétrie GPS et opérationnelle du véhicule.

En envoyant ces valeurs pertinentes vers le véhicule mappé, on réunit ces deux sources sans modifier la façon dont le traqueur transmet ses données. Les opérations de flotte peuvent ainsi combiner les informations de localisation et de déplacement avec le contexte supplémentaire fourni sur la batterie dans le même flux de données.

Pour une flotte de véhicules électriques, cela peut s'avérer nettement plus utile que de consulter séparément le portail OEM et la plateforme de gestion de flotte pour un même véhicule.

Exemple de flux IoT Logic

Plateforme OEM / BMS → HTTP Push → Associer les données au véhicule → Ajouter des attributs de batterie → Combiner avec la télémétrie du traqueur → Traitement, alerte ou système en aval

Supposons que la plateforme OEM fournisse un paramètre de batterie non inclus par le traqueur. Elle peut envoyer cette valeur sous forme d'attribut supplémentaire pour le véhicule mappé. IoT Logic dispose alors à la fois de la télémétrie native du traqueur et des données de batterie externes dans le même flux.

À partir de là, la flotte peut appliquer sa propre logique. Elle peut diriger les données enrichies vers un autre système, évaluer une condition liée à la batterie et aux activités du véhicule ou utiliser le paramètre supplémentaire comme contexte pour une alerte opérationnelle.

Dans tous ces exemples, les données externes remplissent des rôles variés, mais le véhicule reste le point de convergence. Le statut de paiement peut déclencher une action, les données météorologiques peuvent influencer une règle, les attributs métier peuvent ajouter du contexte opérationnel et les données OEM peuvent combler une lacune dans la télémétrie fournie par le traqueur.

Dans chaque cas, les données externes sont associées à un dispositif connu et ajoutées aux côtés de la télémétrie qu'il rapporte déjà. Elles ne remplacent pas les données GPS ou d'état du dispositif. Ainsi, l'enrichissement des données de véhicule se concentre sur l'ajout du contexte dont un flux de travail a besoin, tout en maintenant le véhicule au centre du flux de données.

Quand une autre source de données ne signifie plus nécessairement une autre intégration

Pour les partenaires et intégrateurs systèmes, cela modifie un échange bien connu avec un client. « Pouvons-nous également intégrer ces données dans Navixy ? » ne doit plus nécessairement se solder par « Nous allons devoir créer une intégration. »

Parfois, une intégration personnalisée reste la meilleure option. Mais lorsque le système externe peut envoyer les données requises par IoT Logic, une demande qui ressemblait à un projet de développement peut finalement se réduire à une tâche de configuration.

Cela rend également plus intéressantes les idées d'enrichissement à moindre échelle. Il ne s'agit plus seulement de savoir si un nouveau projet d'intégration de données est justifié, mais plutôt d'examiner si apporter ce contexte supplémentaire dans le flux de données du véhicule pourrait améliorer un flux de travail existant.

Vous souhaitez savoir comment l'enrichissement des données de véhicule pourrait fonctionner pour votre entreprise ? Contactez notre équipe, et nous vous aiderons à explorer votre cas d'utilisation et à répondre à vos questions.