Les cas d’usage de l’Internet des Objets (IoT) dépassent le niveau de la maison connectée pour atteindre l’industrie connectée. En effet, les objets connectés suscitent de plus en plus d’intérêt pour les entreprises pour la diversité des cas d’usage possibles : maintenance prédictive, logistique connectée, santé connectée, etc. Les objets connectés permettent un meilleur suivi des processus business et un gain considérable en temps et en argent.
Cependant, l’implémentation d’une architecture d’un projet IoT peut s’avérer compliquée au vu de la diversité et complexité des dispositifs, des protocoles et des frameworks à utiliser.
Aujourd’hui, il y a de plus en plus de solutions cloud qui simplifient et accélèrent la mise en place des architectures IoT de la partie hardware à la partie back-end. Notre ambition est de vous montrer comment réaliser un tel projet.
Pour cela, on a besoin de services cloud qui:
- Seront déployés au niveau des objets connectés (edge computing)
- Assurent la communication avec le back-end (protocoles applicatifs et réseaux)
- Assurent le traitement dans le back-end (traitement serverless et stockage)
Pour vous illustrer cela, nous avons réalisé un projet de bar connecté construit de bout en bout avec des services cloud ! En effet, ce projet illustre comment associer et faire interagir différentes briques qu’on a listé plus haut. La solution a été développée sur les plateformes cloud Amazon Web Services (AWS) et Microsoft Azure. Ce choix a été motivé par la volonté de comparer différentes plateformes offrant des services IoT les plus aboutis.
Présentation du cas d’usage
Nous avons tous connu cette situation désagréable dans un bar ou un restaurant où l’on souhaite recommander une boisson, mais il faut attendre plusieurs minutes, voire dizaines de minutes, avant qu’un serveur ou une serveuse ne prenne notre commande. Désormais, commandez sans attendre votre boisson avec notre solution de bar connecté.
La figure suivante explique le fonctionnement de notre bar connecté : une camera connectée à un Raspberry Pi reconnaît automatiquement, grâce à un algorithme de reconnaissance d’image embarqué dans le Raspberry Pi, des boissons (bières, eau, jus, etc.) et transmet des commandes à un back-end cloud. Une application web permet à un barman de suivre en temps réel les commandes en cours.
Figure 1: Illustration du cas d’usage du bar connecté
Présentation de l’architecture du cas d’usage
Ce projet a nécessité l’utilisation de plusieurs services cloud, l’architecture sur AWS et Azure est résumée dans l‘image ci-dessous :
Figure 2: Architecture du bar connecté sur AWS et Azure
La caméra connectée envoie périodiquement une photo de la boisson à commander au Raspberry Pi qui se charge de l’analyser et de faire la reconnaissance d’objet. En effet, au lieu d’envoyer les images au cloud, on effectue la reconnaissance d’image en local, près des objets. Cela a l’avantage :
- d’économiser la bande passante entre le cloud et le Raspberry Pi
- d’envoyer rapidement l’information utile au cloud
- de préserver la confidentialité des données en local
- d’alléger les traitements dans le cloud et donc notre facture d’abonnement
Ce principe de délocalisation s’appelle en anglais le « Edge Computing ». AWS et Azure fournissent leurs propres services : AWS Greengrass et IoT Edge.
Après la reconnaissance d’image en local, le résultat de la reconnaissance est envoyé par MQTT (Message Queuing Telemetry Transport) au cloud. C’est ici qu’intervient l’élément central de la chaîne de communication: IoT Core pour AWS et IoT Hub pour Azure. En effet, cet élément permet de connecter, surveiller et gérer des milliards d’objets de manière sécurisée via plusieurs protocoles applicatifs (MQTT, AMQP, HTTP). En outre, à l’arrivée d’un nouveau message, il enclenche automatiquement des traitements en mode ‘serverless’ (via les services Lambda pour AWS et Functions pour Azure), afin de déterminer s’il s’agit bien d’une boisson à commander et de lui affecter un identifiant et un status « non-servi ». Par la suite, le résultat est stocké en base de données (DynamoDB pour AWS et DocumentDB pour Azure).
Pour accéder aux commandes encore « non-servies » depuis l’extérieur, un service de REST API (API Gateway pour AWS et API Management pour Azure) exposent les données via des requêtes HTTP. Avec une application web, développée à partir de Node.js, il est possible de visualiser les commandes en cours.
Figure 3: Application Web pour visualiser les commandes en cours
Pour aller plus loin…la vidéo
Vous avez maintenant la vision globale des problématiques et un exemple du cas d’usage. Dans les prochains épisodes, nous rentrerons dans les détails techniques de l’implémentation.
Cependant, pour patienter, vous pouvez regarder la vidéo de présentation du projet qui a été faite à la XebiCon. De plus, vous y trouverez également notre retour d’expérience sur l’ensemble de ces technologies, avec notamment les différences entre AWS et Azure et les difficultés rencontrées. L’ensemble du code utilisé pour la démonstration lors de la conférence est disponible sur ce dépôt GitHub.