Modifier

Traiter les données de véhicule en temps réel à l’aide de l’IoT

Azure Cosmos DB
Azure IoT Edge
Azure Sphere
Azure Stream Analytics
Azure SQL Database

Idées de solution

Cet article présente une idée de solution. Si vous souhaitez que nous développions le contenu avec d’autres informations, telles que des cas d’usage potentiels, d’autres services, des considérations d’implémentation ou un guide des prix, adressez-nous vos commentaires GitHub.

Cette solution crée un pipeline permettant l’ingestion et le traitement en temps réel des données des appareils IoT sur une plateforme d’analytique Big Data dans Azure. L’architecture utilise Azure Sphere et Azure IoT Hub pour gérer les messages télématiques, tandis qu’Azure Stream Analytics les traite.

Architecture

Diagram showing vehicle data ingestion, processing, and visualization.

Téléchargez un fichier Visio de cette architecture.

Dataflow

Les données circulent dans la solution comme suit :

  1. Les messages télématiques (vitesse, emplacement, etc.) sont envoyés par un appareil mobile Azure Sphere à Azure IoT Hub. Dans un scénario greenfield, le fabricant du véhicule peut inclure un module Sphere dans chaque véhicule au moment de sa fabrication. Dans un scénario brownfield, le véhicule est équipé d’une solution de télématique pour le marché secondaire.

  2. Azure Stream Analytics récupère le message en temps réel depuis Azure IoT Hub, traite le message en fonction de la logique métier et envoie les données à la couche de service pour le stockage.

  3. Différentes bases de données sont utilisées en fonction des données. Azure Cosmos DB stocke les messages, tandis que la base de données SQL Azure stocke les données relationnelles et transactionnelles, et agit comme une source de données pour la couche de présentation et d’action. Azure Synapse contient des données agrégées et agit comme source de données pour les outils de Business Intelligence.

  4. Des applications web, mobiles, BI et de réalité mixte peuvent être créées sur la couche de service. Par exemple, vous pouvez exposer les données de couche de service à l’aide d’API pour des utilisations tierces (compagnies d’assurances, fournisseurs, etc.).

  5. Lorsqu’un véhicule nécessite une maintenance auprès d’un concessionnaire, un appareil Azure Sphere est connecté au port OBD-II du véhicule par un technicien de service.

  6. L’application Azure Sphere se connecte au port OBD-II du véhicule et diffuse les données OBD-II vers Azure IoT Edge via MQTT. L’appareil Azure Sphere est connecté via le Wi-Fi à l’appareil Azure IoT Edge installé dans le centre de services. Les données OBD-II sont diffusées d’Azure IoT Edge vers Azure IoT Hub et traitées dans le même pipeline de traitement des messages.

    • Avec la dernière version 20.10 du système d’exploitation, Azure Sphere peut maintenant se connecter de façon sécurisée à Azure IoT Edge à l’aide de ses propres certificats d’appareil. Le certificat d’appareil Azure Sphere est propre à chaque appareil et il est automatiquement renouvelé par le service de sécurité Azure Sphere toutes les 24 heures après que l’appareil a réussi le processus d’authentification et d’attestation à distance.

    • Azure Sphere communique directement avec le service de sécurité Azure Sphere et non par le biais d’Azure IoT Edge. Le service de sécurité Azure Sphere est un service cloud Microsoft qui communique avec les circuits intégrés Azure Sphere pour permettre la maintenance, la mise à jour et le contrôle. Abrégé parfois en AS3.

  7. Le répartiteur MQTT à usage général est à présent disponible dans Azure IoT Edge. L’appareil Azure Sphere publie des messages dans la rubrique MQTT intégrée à IoT Hub (devices/{sphere_deviceid}/messages/events/).

    • Les modules Azure IoT Edge sont des applications conteneurisées gérées par IoT Edge et peuvent exécuter des services Azure (tels qu’Azure Stream Analytics), des modèles ML personnalisés ou votre propre code propre à la solution.

  8. Un technicien de service, doté d’un HoloLens, peut s’abonner à la rubrique MQTT (devices/{sphere_deviceid}/messages/events/) et afficher de façon sécurisée les données OBD-II à l’aide d’une application HoloLens contenant un client MQTT. Le client HoloLens MQTT doit être autorisé à se connecter et à s’abonner à la rubrique. En connectant le HoloLens directement à la passerelle IoT Edge, le technicien de service peut afficher les données du véhicule en quasi-temps réel, évitant ainsi la latence liée à l’envoi des données vers le cloud et inversement. Le technicien de service peut également interagir avec le port OBD-II du véhicule (par exemple, désactiver le voyant qui indique de « vérifier le moteur ») même lorsque le centre de service est déconnecté du cloud.

Composants

  • Azure Sphere est une plateforme d’applications générales sécurisée qui présente des fonctionnalités de sécurité et de communication intégrées pour les appareils connectés à Internet. Elle comprend une unité de microcontrôleur (MCU) transversale, connectée et sécurisée, un système d’exploitation Linux personnalisé et un service de sécurité cloud qui offre une sécurité continue et renouvelable.

  • Azure IoT Edge fournit le répartiteur MQTT et exécute des applications de périphérie intelligente localement pour garantir une utilisation de bande passante réduite et à faible latence.

  • Azure IoT Hub est situé dans la couche d’ingestion et prend en charge la communication bidirectionnelle vers les appareils, ce qui permet d’envoyer des actions du cloud ou d’Azure IoT Edge vers l’appareil.

  • Azure Stream Analytics (ASA) fournit un traitement des flux serverless en temps réel qui peut exécuter les mêmes requêtes dans le cloud et sur la périphérie. ASA sur Azure IoT Edge peut filtrer ou agréger des données localement, ce qui permet de prendre des décisions intelligentes sur les données à envoyer au cloud en vue d’un traitement ou d’un stockage plus poussé.

  • Azure Cosmos DB, Azure SQL Database et Azure Synapse Analytics se trouvent dans la couche de stockage de service. Azure Stream Analytics peut écrire des messages directement sur Azure Cosmos DB à l’aide d’une sortie. Les données peuvent être agrégées et déplacées d’Azure Cosmos DB et d’Azure SQL vers Azure Synapse à l’aide d’Azure Data Factory.

  • Azure Synapse Analytics est un système distribué permettant de stocker et d’analyser des jeux de données volumineux. Son recours à un traitement parallèle massif (MPP) lui permet d’exécuter des analyses hautes performances.

  • Azure Synapse Link pour Azure Cosmos DB vous permet d’effectuer de l’analytique en quasi temps réel sur les données opérationnelles dans Azure Cosmos DB, sans aucun impact en termes de perfomances ou de coûts sur votre charge de travail transactionnelle, en utilisant les deux moteurs d’analytique disponibles depuis votre espace de travail Azure Synapse : SQL Serverless et des pools Spark.

  • Microsoft Power BI est une suite d’outils d’analyse métier permettant d’analyser des données et de partager des insights. Power BI peut interroger un modèle sémantique stocké dans Analysis Services ou interroger directement Azure Synapse.

  • Azure App Services peut être utilisé pour générer des applications web and mobiles. Azure API Management peut être utilisé pour présenter des données à des tiers en fonction des données stockées dans la couche de service.

  • Microsoft HoloLens peut être utilisé par des techniciens de service pour afficher les données des véhicules (l’historique de maintenance, les données OBD-II, les diagrammes de composants, etc.) de façon holographique pour faciliter le dépannage et la réparation.

Autres solutions

  • Synapse Link est la solution Microsoft par défaut pour l’analyse des données Azure Cosmos DB.

Détails du scénario

L’ingestion, le traitement et la visualisation des données de véhicules sont des fonctionnalités clés nécessaires pour créer des solutions de véhicules connectés. En capturant et en analysant ces données, nous pouvons déchiffrer des insights utiles et créer des solutions.

Prenons l’exemple de véhicules équipés d’appareils télématiques : nous pouvons surveiller en direct l’emplacement des véhicules, planifier des itinéraires optimisés, fournir une assistance aux conducteurs et soutenir les secteurs qui consomment ou exploitent des données télématiques (par exemple les assureurs). Pour les fabricants de véhicules, les informations de diagnostic peuvent fournir des informations importantes sur la maintenance et les garanties en lien avec les véhicules.

Cas d’usage potentiels

Imaginez une société de fabrication de voitures qui souhaite créer une solution aux fins suivantes :

  • Envoyer de façon sécurisée des données en temps réel dans le cloud à partir de capteurs et d’ordinateurs intégrés installés dans ses véhicules.

  • Créer des services à forte valeur ajoutée pour ses clients et revendeurs en analysant l’emplacement des véhicules et d’autres données de capteur (telles que les capteurs liés au moteur ou à l’environnement).

  • Stocker les données pour un traitement en aval supplémentaire afin de fournir des insights actionnables (des alertes de maintenance pour les propriétaires de véhicules, des informations sur les accidents pour les compagnies d’assurances, etc.).

  • Permettre aux techniciens de service des concessionnaires d’interagir avec les véhicules à l’aide d’une application de réalité mixte pour faciliter le dépannage et la réparation (par exemple en utilisant une application HoloLens pour afficher des données en temps réel et afficher/effacer les codes de diagnostic disponibles via le port OBD-II d’un véhicule, afficher les procédures de réparation ou afficher un diagramme 3D des composants).

Contributeurs

Cet article est mis à jour et géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Étapes suivantes