Il y a 9 mois -

Temps de lecture 4 minutes

Un bar connecté avec du Edge et du Cloud

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:

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.

 

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.