IoT et Big Data sur la plateforme Azure : Introduction à SoCars
Big Data et IoT sont deux sujets très en vogue ces derniers temps. Pour rappel, l’IoT, ou Internet des Objets, est le “nouveau nom” du concept de M2M : la communication de machine vers machine. Le Big Data désigne une philosophie pour stocker et traiter une masse conséquente de données pas toujours structurée.
Dans le labo des Experts SOAT, nous nous sommes creusés sur le sujet de l’IoT et du Big Data. En effet, il nous fallait une plateforme de démonstration pour expérimenter autour de ces sujets.
Etant partenaire de Microsoft, nous avons donc décidé de monter un démonstrateur tirant parti de la plateforme Azure et permettant d’adresser les problématiques de l’IoT et du Big Data.
Bien sûr, le but n’est pas d’être exhaustif dans la manière de traiter le sujet, mais plutôt de donner un aperçu et de démocratiser ces sujets sur un exemple bien concret.
C’est comme ça qu’est né SoCars.
Présentation
Le champ d’application de l’Internet des Objets est infiniment grand. Cela va du capteur embarqué sur le terrain à la caisse enregistreuse de supermarché en passant par les voitures connectées, les téléphones, bracelets fitness et mêmes serveurs informatiques.
Le Big Data nous donne des outils pour stocker et traiter des volumes de données colossaux. Mais la plus grosse valeur ajoutée n’est pas de savoir stocker ou traiter, ceux-ci sont là pour nous aider à donner un sens à une information en assemblant les différentes données, afin de pouvoir analyser, tirer des tendances, comprendre et prédire le modèle.
Le premier enjeu est d’avoir un système qui génère une quantité d’informations suffisante pour pouvoir être analysée, mais il faut aussi que ce système soit compréhensible par tous, qu’on puisse interagir avec lui, et dont on puisse tirer des indicateurs simples.
Un des premiers contextes qui vient à l’esprit est le monde automobile et le trafic routier. En effet, c’est un exemple qui parle au plus grand nombre, étant un enjeu majeur ces derniers temps (voiture automatisée, sécurité routière, développement durable) et un environnement suffisamment mature technologiquement pour envisager son instrumentation (ce qui est déjà fait d’ailleurs).
Cependant, un problème majeur se présente par rapport au cahier des charges initial : non nous ne pouvions pas installer des capteurs dans tout Paris, ni brancher les feux de circulation de l’agglomération pour les piloter depuis notre compte Azure, la préfecture aurait, je pense, moyennement apprécié l’opération.
La solution a donc été de recréer Paris dans un simulateur.
Ce simulateur permet plusieurs choses :
- Générer du trafic routier selon un emploi du temps (simulation d’heures de pointe et d’heures creuses)
- Lorsqu’une voiture apparaît sur la carte, elle a une origine A et une destination B. Pour effectuer le trajet de A vers B, il est possible de spécifier la stratégie (aléatoire, plus court, etc.)
- Les intersections sont munies de feux de signalisation, activables à distance
- Une vue aérienne permet de consulter un aperçu du trafic actuel
Enjeux
Une fois ce simulateur en place, nous avons pu définir plusieurs sources de télémétrie. La première est dans chaque tronçon de route : dès qu’une voiture entre dans une rue, la plaque d’immatriculation, le nom de la rue et l’heure sont relevés.
De manière complémentaire, les relevés de position des voitures sont envoyés également à intervalles réguliers. Enfin, les feux de circulation publient également leurs changements d’état.
Avec cette masse de données, voici les différents enjeux auxquels nous allons tenter de répondre :
- Le premier enjeu du scénario est de récolter ces données : elles représentent un volume conséquent à ingérer et à répartir pour le traitement, surtout si celui-ci doit se faire en temps réel.
- Le second enjeu est d’être en mesure, à partir de ces informations brutes, de bâtir une cartographie et de construire des indicateurs représentant l’état du système, en bref transformer la donnée brute en une information intelligible.
- Le troisième enjeu est de pouvoir corriger le système lors de problèmes en agissant dessus grâce aux informations obtenues.
- Enfin, le dernier enjeu (et peut-être le plus complexe) est d’empêcher ces problèmes de survenir (au lieu de les corriger à posteriori).
Le simulateur
Voici une capture partielle du simulateur en question :
Il représente donc, pour le moment, Paris intramuros avec ses principaux axes. Comme précisé plus haut, chaque carrefour est muni de feux de signalisation pour réguler le trafic. Les voitures, représentées par des points, ne peuvent pas se doubler et par conséquent, un afflux de trafic peut créer des bouchons comme aux alentours de la Place de la Concorde (vers la droite).
Dans la version simple, l’algorithme de calcul de parcours pour une voiture est de type “plus court” (Djikstra).
Bien que le simulateur possède une interface graphique en WPF, elle est présente uniquement pour la mise au point et n’est pas destinée à être publiée.
Et maintenant ?
Chaque enjeu sera traité à l’aide d’une ou plusieurs solutions techniques. Le premier article cette série (cette introduction mise à part) concerne la transmission d’information via Azure EventHub.
Les différentes briques traitées par la suite seront : Azure IoT Hub, Azure Stream Analytics, Azure HDInsight (Hadoop), Azure Service Fabric et Azure Machine Learning.
SoCars a été présentée lors des Microsoft Tech’Days, Rendre les routes intelligentes avec Microsoft Azure.