Démystifier l'apprentissage automatique à la périphérie grâce à des cas d'utilisation réels

Edge est un terme qui fait référence à un emplacement, loin du cloud ou d'un grand centre de données, où vous disposez d'un périphérique informatique (périphérique périphérique) capable d'exécuter des applications (périphériques). L'Edge Computing consiste à exécuter des charges de travail sur ces périphériques Edge. L'apprentissage automatique en périphérie (ML@Edge) est un concept qui offre la possibilité d'exécuter des modèles ML localement sur des appareils en périphérie. Ces modèles ML peuvent ensuite être invoqués par l'application périphérique. ML@Edge est important pour de nombreux scénarios où les données brutes sont collectées à partir de sources éloignées du cloud. Ces scénarios peuvent également avoir des exigences ou des restrictions spécifiques :

• Prédictions en temps réel et à faible latence
• Connectivité médiocre ou inexistante avec le cloud
• Restrictions légales qui ne permettent pas d'envoyer des données à des services externes
• Grands ensembles de données qui doivent être prétraités localement avant d'envoyer des réponses au cloud

Voici quelques-uns des nombreux cas d'utilisation qui peuvent bénéficier de modèles ML exécutés à proximité de l'équipement qui génère les données utilisées pour les prédictions :

• Sécurité et sûreté – Une zone restreinte où opèrent des engins lourds dans un port automatisé est surveillée par une caméra. Si une personne pénètre dans cette zone par erreur, un mécanisme de sécurité est activé pour arrêter les machines et protéger l'humain.
• La maintenance prédictive – Des capteurs de vibration et audio collectent des données à partir d'une boîte de vitesses d'une éolienne. Un modèle de détection d'anomalies traite les données du capteur et identifie les éventuelles anomalies de l'équipement. Si une anomalie est détectée, le dispositif de bord peut lancer une mesure de contingence en temps réel pour éviter d'endommager l'équipement, comme engager les coupures ou déconnecter le générateur du réseau.
• Détection des défauts dans les lignes de production – Une caméra capture des images de produits sur un tapis roulant et traite les trames avec un modèle de classification d'images. Si un défaut est détecté, le produit peut être jeté automatiquement sans intervention manuelle.

Bien que ML@Edge puisse répondre à de nombreux cas d'utilisation, il existe des défis architecturaux complexes qui doivent être résolus afin d'avoir une conception sécurisée, robuste et fiable. Dans cet article, vous apprendrez quelques détails sur ML@Edge, des sujets connexes et comment utiliser les services AWS pour surmonter ces défis et mettre en œuvre une solution complète pour votre charge de travail ML à la périphérie.

Présentation de ML@Edge

Il existe une confusion commune en ce qui concerne ML@Edge et l'Internet des objets (IoT), il est donc important de clarifier en quoi ML@Edge est différent de l'IoT et comment ils pourraient se combiner pour fournir une solution puissante dans certains cas.

Une solution Edge qui utilise ML@Edge comporte deux composants principaux : une application Edge et un modèle ML (appelé par l'application) s'exécutant sur l'appareil Edge. ML@Edge consiste à contrôler le cycle de vie d'un ou plusieurs modèles ML déployés sur une flotte d'appareils en périphérie. Le cycle de vie du modèle ML peut commencer côté cloud (sur Amazon Sage Maker, par exemple) mais se termine normalement par un déploiement autonome du modèle sur l'appareil périphérique. Chaque scénario exige différents cycles de vie de modèle ML qui peuvent être composés de plusieurs étapes, telles que la collecte de données ; préparation des données; création, compilation et déploiement de modèles sur l'appareil périphérique ; chargement et exécution du modèle ; et répéter le cycle de vie.

Le mécanisme ML@Edge n'est pas responsable du cycle de vie de l'application. Une approche différente devrait être adoptée à cette fin. Le découplage du cycle de vie du modèle ML et du cycle de vie de l'application vous donne la liberté et la flexibilité nécessaires pour continuer à les faire évoluer à des rythmes différents. Imaginez une application mobile qui intègre un modèle ML en tant que ressource comme une image ou un fichier XML. Dans ce cas, chaque fois que vous entraînez un nouveau modèle et souhaitez le déployer sur les téléphones mobiles, vous devez redéployer l'ensemble de l'application. Cela consomme du temps et de l'argent et peut introduire des bogues dans votre application. En découplant le cycle de vie du modèle ML, vous publiez l'application mobile une seule fois et déployez autant de versions du modèle ML que nécessaire.

Mais comment l'IoT est-il corrélé à ML@Edge ? L'IoT concerne des objets physiques intégrés à des technologies telles que des capteurs, des capacités de traitement et des logiciels. Ces objets sont connectés à d'autres appareils et systèmes via Internet ou d'autres réseaux de communication, afin d'échanger des données. La figure suivante illustre cette architecture. Le concept a été initialement créé en pensant à des appareils simples qui collectent simplement des données à partir de la périphérie, effectuent un traitement local simple et envoient le résultat à une unité informatique plus puissante qui exécute des processus d'analyse qui aident les personnes et les entreprises dans leur prise de décision. La solution IoT est responsable du contrôle du cycle de vie des applications Edge. Pour plus d'informations sur l'IoT, reportez-vous à Internet des objets.

Si vous disposez déjà d'une application IoT, vous pouvez ajouter des fonctionnalités ML@Edge pour rendre le produit plus efficace, comme illustré dans la figure suivante. Gardez à l'esprit que ML@Edge ne dépend pas de l'IoT, mais vous pouvez les combiner pour créer une solution plus puissante. Lorsque vous faites cela, vous améliorez le potentiel de votre appareil simple pour générer des informations en temps réel pour votre entreprise plus rapidement qu'un simple envoi de données vers le cloud pour un traitement ultérieur.

Si vous créez une nouvelle solution Edge à partir de zéro avec des fonctionnalités ML@Edge, il est important de concevoir une architecture flexible qui prend en charge à la fois les cycles de vie de l'application et du modèle ML. Nous fournissons des architectures de référence pour les applications Edge avec ML@Edge plus loin dans cet article. Mais d'abord, approfondissons l'informatique de périphérie et apprenons à choisir le bon périphérique de périphérie pour votre solution, en fonction des restrictions de l'environnement.

Edge computing

Selon la distance entre l'appareil et le cloud ou un grand centre de données (base), trois caractéristiques principales des appareils périphériques doivent être prises en compte pour optimiser les performances et la longévité du système : la capacité de calcul et de stockage, la connectivité et la consommation d'énergie. Le schéma suivant montre trois groupes d'appareils de périphérie qui combinent différentes spécifications de ces caractéristiques, en fonction de leur distance par rapport à la base.

Les groupes sont les suivants:

• MEC (Multi-access Edge Computing) – Les MEC ou petits centres de données, caractérisés par une latence faible ou ultra-faible et une bande passante élevée, sont des environnements courants où ML@Edge peut apporter des avantages sans grandes restrictions par rapport aux charges de travail cloud. Les antennes et serveurs 5G dans les usines, les entrepôts, les laboratoires, etc. avec des contraintes énergétiques minimales et une bonne connectivité Internet offrent différentes façons d'exécuter des modèles ML sur des GPU et des CPU, des machines virtuelles, des conteneurs et des serveurs bare metal.
• Près du bord - C'est à ce moment que la mobilité ou l'agrégation de données sont des exigences et que les appareils ont certaines contraintes concernant la consommation d'énergie et la puissance de traitement, mais ont toujours une connectivité fiable, bien qu'avec une latence plus élevée, avec un débit limité et plus cher que "proche du bord". Les applications mobiles, les cartes spécifiques pour accélérer les modèles ML ou les appareils simples capables d'exécuter des modèles ML, couverts par des réseaux sans fil, sont inclus dans ce groupe.
• Bord éloigné – Dans ce scénario extrême, les appareils périphériques ont de fortes contraintes de consommation d'énergie ou de connectivité. Par conséquent, la puissance de traitement est également limitée dans de nombreux scénarios de périphérie distante. L'agriculture, l'exploitation minière, la surveillance et la sécurité, ainsi que le transport maritime sont des domaines dans lesquels les dispositifs distants jouent un rôle important. Les cartes simples, normalement sans GPU ou autres accélérateurs d'IA, sont courantes. Ils sont conçus pour charger et exécuter des modèles ML simples, enregistrer les prédictions dans une base de données locale et dormir jusqu'au prochain cycle de prédiction. Les appareils qui doivent traiter des données en temps réel peuvent avoir de grands stockages locaux pour éviter de perdre des données.

Défis

Il est courant d'avoir des scénarios ML@Edge où vous avez des centaines ou des milliers (voire des millions) d'appareils exécutant les mêmes modèles et applications de périphérie. Lorsque vous faites évoluer votre système, il est important de disposer d'une solution robuste capable de gérer le nombre d'appareils que vous devez prendre en charge. Il s'agit d'une tâche complexe et pour ces scénarios, vous devez vous poser de nombreuses questions :

• Comment exploiter des modèles ML sur une flotte d'appareils en périphérie ?
• Comment créer, optimiser et déployer des modèles de ML sur plusieurs appareils en périphérie ?
• Comment sécuriser mon modèle lors de son déploiement et de son exécution en périphérie ?
• Comment surveiller les performances de mon modèle et le réentraîner, si nécessaire ?
• Comment puis-je éliminer le besoin d'installer un gros framework comme TensorFlow ou PyTorch sur mon appareil restreint ?
• Comment exposer un ou plusieurs modèles avec mon application edge comme une simple API ?
• Comment créer un nouvel ensemble de données avec les charges utiles et les prédictions capturées par les appareils périphériques ?
• Comment effectuer toutes ces tâches automatiquement (MLOps plus ML@Edge) ?

Dans la section suivante, nous apportons des réponses à toutes ces questions à travers des exemples de cas d'utilisation et des architectures de référence. Nous discutons également des services AWS que vous pouvez combiner pour créer des solutions complètes pour chacun des scénarios explorés. Toutefois, si vous souhaitez commencer par un flux très simple décrivant comment utiliser certains des services fournis par AWS pour créer votre solution ML@Edge, voici un exemple :

Avec SageMaker, vous pouvez facilement préparer un ensemble de données et créer les modèles ML qui sont déployés sur les appareils périphériques. Avec Amazon Sage Maker Neo, vous pouvez compiler et optimiser le modèle que vous avez formé pour l'appareil Edge spécifique que vous avez choisi. Après avoir compilé le modèle, vous n'avez besoin que d'un runtime léger pour l'exécuter (fourni par le service). Gestionnaire de périphérie Amazon SageMaker est responsable de la gestion du cycle de vie de tous les modèles ML déployés sur votre parc d'appareils périphériques. Edge Manager peut gérer des flottes allant jusqu'à des millions d'appareils. Un agent, installé sur chacun des appareils périphériques, expose les modèles ML déployés en tant qu'API à l'application. L'agent est également responsable de la collecte des métriques, des charges utiles et des prédictions que vous pouvez utiliser pour surveiller ou créer un nouvel ensemble de données pour recycler le modèle si nécessaire. Enfin, avec Pipelines Amazon SageMaker, vous pouvez créer un pipeline automatisé avec toutes les étapes nécessaires pour créer, optimiser et déployer des modèles de ML sur votre flotte d'appareils. Ce pipeline automatisé peut ensuite être déclenché par des événements simples que vous définissez, sans intervention humaine.

Cas d'utilisation 1

Supposons qu'un constructeur d'avions souhaite détecter et suivre des pièces et des outils dans le hangar de production. Pour améliorer la productivité, toutes les pièces nécessaires et les bons outils doivent être disponibles pour les ingénieurs à chaque étape de la production. Nous voulons être en mesure de répondre à des questions telles que : Où est la partie A ? ou Où est l'outil B ? Nous avons plusieurs caméras IP déjà installées et connectées à un réseau local. Les caméras couvrent tout le hangar et peuvent diffuser des vidéos HD en temps réel via le réseau.

Panorama AWS s'intègre bien dans ce cas. AWS Panorama fournit une appliance ML et un service géré qui vous permettent d'ajouter la vision par ordinateur (CV) à votre flotte existante de caméras IP et de l'automatiser. AWS Panorama vous donne la possibilité d'ajouter un CV à vos caméras IP (Internet Protocol) existantes et d'automatiser les tâches qui nécessitent traditionnellement une inspection et une surveillance humaines.

Dans l'architecture de référence suivante, nous montrons les principaux composants de l'application s'exécutant sur un AWS Panorama Appliance. Le SDK d'application Panorama permet de capturer facilement des vidéos à partir de flux de caméras, d'effectuer des inférences avec un pipeline de plusieurs modèles ML et de traiter les résultats à l'aide de code Python s'exécutant dans un conteneur. Vous pouvez exécuter des modèles à partir de n'importe quelle bibliothèque ML populaire telle que TensorFlow, PyTorch ou TensorRT. Les résultats du modèle peuvent être intégrés aux systèmes d'entreprise de votre réseau local, ce qui vous permet de réagir aux événements en temps réel.

La solution comprend les étapes suivantes:

1. Connectez et configurez un appareil AWS Panorama au même réseau local.
2. Entraînez un modèle ML (détection d'objets) pour identifier les pièces et les outils dans chaque image.
3. Créez une application AWS Panorama qui obtient les prédictions du modèle ML, applique un mécanisme de suivi à chaque objet et envoie les résultats à une base de données en temps réel.
4. Les opérateurs peuvent envoyer des requêtes à la base de données pour localiser les pièces et les outils.

Cas d'utilisation 2

Pour notre prochain cas d'utilisation, imaginez que nous créons une dashcam pour des véhicules capables de soutenir le conducteur dans de nombreuses situations, comme éviter les piétons, sur la base d'un Carte CV25 d'Ambaralla. L'hébergement de modèles ML sur un appareil avec des ressources système limitées peut être difficile. Dans ce cas, supposons que nous disposions déjà d'un mécanisme de livraison par liaison radio (OTA) bien établi pour déployer les composants d'application nécessaires sur l'appareil périphérique. Cependant, nous bénéficierions toujours de la possibilité de déployer OTA du modèle lui-même, isolant ainsi le cycle de vie de l'application et le cycle de vie du modèle.

Gestionnaire de périphérie Amazon SageMaker ainsi que le Amazon Sage Maker Neo bien adapté à ce cas d'utilisation.

Edge Manager permet aux développeurs ML Edge d'utiliser facilement les mêmes outils familiers dans le cloud ou sur des appareils Edge. Il réduit le temps et les efforts nécessaires pour mettre les modèles en production, tout en vous permettant de surveiller et d'améliorer en permanence la qualité des modèles sur l'ensemble de votre parc d'appareils. SageMaker Edge inclut un mécanisme de déploiement OTA qui vous aide à déployer des modèles sur la flotte indépendamment de l'application ou du micrologiciel de l'appareil. La Agent Edge Manager vous permet d'exécuter plusieurs modèles sur le même appareil. L'agent collecte les données de prédiction en fonction de la logique que vous contrôlez, comme les intervalles, et les télécharge dans le cloud afin que vous puissiez réentraîner périodiquement vos modèles au fil du temps. SageMaker Edge signe cryptographiquement vos modèles afin que vous puissiez vérifier qu'ils n'ont pas été falsifiés lors de leur déplacement du cloud vers l'appareil périphérique.

Neo est un compilateur en tant que service et convient particulièrement bien à ce cas d'utilisation. Neo optimise automatiquement les modèles ML pour l'inférence sur les instances cloud et les appareils périphériques afin de fonctionner plus rapidement sans perte de précision. Vous commencez avec un modèle ML construit avec l'un des cadres pris en charge et formé à SageMaker ou ailleurs. Ensuite, vous choisissez votre plate-forme matérielle cible, (reportez-vous à la liste des Périphériques compatibles). En un seul clic, Neo optimise le modèle formé et le compile dans un package pouvant être exécuté à l'aide de l'environnement d'exécution léger SageMaker Edge. Le compilateur utilise un modèle ML pour appliquer les optimisations de performances qui extraient les meilleures performances disponibles pour votre modèle sur l'instance cloud ou l'appareil périphérique. Vous déployez ensuite le modèle en tant que point de terminaison SageMaker ou sur des appareils périphériques pris en charge et commencez à faire des prédictions.

Le diagramme suivant illustre cette architecture.

Le workflow de la solution comprend les étapes suivantes :

1. Le développeur construit, forme, valide et crée l'artefact de modèle final qui doit être déployé sur la dashcam.
2. Appelez Neo pour compiler le modèle entraîné.
3. L'agent SageMaker Edge est installé et configuré sur l'appareil Edge, dans ce cas la dashcam.
4. Créez un package de déploiement avec un modèle signé et le runtime utilisé par l'agent SageMaker Edge pour charger et appeler le modèle optimisé.
5. Déployez le package à l'aide du mécanisme de déploiement OTA existant.
6. L'application Edge interagit avec l'agent SageMaker Edge pour effectuer une inférence.
7. L'agent peut être configuré (si nécessaire) pour envoyer des exemples de données d'entrée en temps réel à partir de l'application à des fins de surveillance et d'affinement du modèle.

Cas d'utilisation 3

Supposons que votre client développe une application qui détecte les anomalies dans les mécanismes d'une éolienne (comme la boîte de vitesses, le générateur ou le rotor). L'objectif est de minimiser les dommages sur l'équipement en exécutant à la volée des procédures de protection locales. Ces éoliennes sont très chères et situées dans des endroits difficilement accessibles. Chaque turbine peut être équipée d'un dispositif NVIDIA Jetson pour surveiller les données des capteurs de la turbine. Nous avons ensuite besoin d'une solution pour capturer les données et utiliser un algorithme ML pour détecter les anomalies. Nous avons également besoin d'un mécanisme OTA pour maintenir à jour le logiciel et les modèles ML sur l'appareil.

AWS IoT Greengrass V2 ainsi qu'Edge Manager s'intègrent bien dans ce cas d'utilisation. AWS IoT Greengrass est un service cloud et d'exécution de périphérie IoT open source qui vous aide à créer, déployer et gérer des applications IoT sur vos appareils. Vous pouvez utiliser AWS IoT Greengrass pour créer des applications périphériques à l'aide de modules logiciels prédéfinis, appelés composants électriques , qui peuvent connecter vos appareils périphériques aux services AWS ou à des services tiers. Cette capacité d'AWS IoT Greengrass facilite le déploiement d'actifs sur des appareils, y compris un agent SageMaker Edge. AWS IoT Greengrass est responsable de la gestion du cycle de vie de l'application, tandis qu'Edge Manager dissocie le cycle de vie du modèle ML. Cela vous donne la flexibilité de continuer à faire évoluer l'ensemble de la solution en déployant indépendamment de nouvelles versions de l'application périphérique et des modèles ML. Le schéma suivant illustre cette architecture.

La solution comprend les étapes suivantes:

1. Le développeur construit, forme, valide et crée l'artefact du modèle final qui doit être déployé sur l'éolienne.
2. Appelez Neo pour compiler le modèle entraîné.
3. Créez un composant de modèle à l'aide d'Edge Manager avec l'intégration AWS IoT Greengrass V2.
4. Configurez AWS IoT Greengrass V2.
5. Créez un composant d'inférence à l'aide d'AWS IoT Greengrass V2.
6. L'application Edge interagit avec l'agent SageMaker Edge pour effectuer une inférence.
7. L'agent peut être configuré (si nécessaire) pour envoyer des exemples de données d'entrée en temps réel à partir de l'application à des fins de surveillance et d'affinement du modèle.

Cas d'utilisation 4

Pour notre cas d'utilisation final, examinons un navire transportant des conteneurs, où chaque conteneur dispose de quelques capteurs et transmet un signal à l'infrastructure de calcul et de stockage déployée localement. Le défi est que nous voulons connaître le contenu de chaque conteneur et l'état des marchandises en fonction de la température, de l'humidité et des gaz à l'intérieur de chaque conteneur. Nous voulons également suivre toutes les marchandises dans chacun des conteneurs. Il n'y a pas de connexion Internet tout au long du voyage et le voyage peut prendre des mois. Les modèles ML exécutés sur cette infrastructure doivent prétraiter les données et générer des informations pour répondre à toutes nos questions. Les données générées doivent être stockées localement pendant des mois. L'application Edge stocke toutes les inférences dans une base de données locale, puis synchronise les résultats avec le cloud lorsque le navire approche du port.

Cone à neige AWS ainsi que le Boule de neige AWS du Famille de neige AWS pourrait très bien s'adapter à ce cas d'utilisation.

AWS Snowcone est un appareil de migration de données et d'informatique en périphérie petit, robuste et sécurisé. Snowcone est conçu selon la norme OSHA pour un appareil élévateur pour une personne. Snowcone vous permet d'exécuter des charges de travail en périphérie à l'aide Cloud de calcul élastique Amazon (Amazon EC2) et le stockage local dans des environnements de terrain difficiles et déconnectés tels que les plates-formes pétrolières, les véhicules de recherche et de sauvetage, les sites militaires ou les usines, ainsi que les bureaux distants, les hôpitaux et les cinémas.

Snowball ajoute plus de calcul par rapport à Snowcone et peut donc être parfaitement adapté aux applications plus exigeantes. La fonctionnalité Compute Optimized fournit un GPU NVIDIA Tesla V100 en option ainsi que des instances EC2 pour accélérer les performances d'une application dans des environnements déconnectés. Avec l'option GPU, vous pouvez exécuter des applications telles que le ML avancé et l'analyse vidéo en mouvement complet dans des environnements avec peu ou pas de connectivité.

En plus de l'instance EC2, vous avez la liberté de créer et de déployer tout type de solution Edge. Par exemple : vous pouvez utiliser Amazon ECS ou un autre gestionnaire de conteneurs pour déployer l'application Edge, l'agent Edge Manager et le modèle ML en tant que conteneurs individuels. Cette architecture serait similaire au cas d'utilisation 2 (sauf qu'elle fonctionnera hors ligne la plupart du temps), avec l'ajout d'un outil de gestion de conteneurs.

Le schéma suivant illustre cette architecture de solution.

Pour mettre en place cette solution, il vous suffit de commander votre appareil Snow auprès du Console de gestion AWS et lancez vos ressources.

Conclusion

Dans cet article, nous avons discuté des différents aspects de la périphérie avec lesquels vous pouvez choisir de travailler en fonction de votre cas d'utilisation. Nous avons également discuté de certains des concepts clés autour de ML@Edge et de la manière dont le découplage du cycle de vie de l'application et du cycle de vie du modèle ML vous donne la liberté de les faire évoluer sans aucune dépendance l'un sur l'autre. Nous avons souligné comment choisir le bon appareil de périphérie pour votre charge de travail et poser les bonnes questions pendant le processus de solution peut vous aider à travailler en arrière et à affiner les bons services AWS. Nous avons également présenté différents cas d'utilisation ainsi que des architectures de référence pour vous inspirer à créer vos propres solutions qui fonctionneront pour votre charge de travail.

---

À propos des auteurs

Dinesh Kumar Subramani est un architecte de solutions senior au sein de l'équipe UKIR SMB, basée à Édimbourg, en Écosse. Il est spécialisé dans l'intelligence artificielle et l'apprentissage automatique. Dinesh aime travailler avec des clients de tous les secteurs pour les aider à résoudre leurs problèmes avec les services AWS. En dehors du travail, il aime passer du temps avec sa famille, jouer aux échecs et écouter de la musique dans tous les genres.

Samir Araújo est un architecte de solutions AI / ML chez AWS. Il aide les clients à créer des solutions d'IA / ML qui résolvent leurs défis commerciaux à l'aide d'AWS. Il a travaillé sur plusieurs projets d'IA / ML liés à la vision par ordinateur, au traitement du langage naturel, à la prévision, au ML à la périphérie, etc. Il aime jouer avec des projets de matériel et d'automatisation pendant son temps libre, et il a un intérêt particulier pour la robotique.

• Coinsmart. Le meilleur échange Bitcoin et Crypto d'Europe.
• Platoblockchain. Intelligence métaverse Web3. Connaissance amplifiée. ACCÈS LIBRE.
• CryptoHawk. Radar Altcoins. Essai gratuit.
• Source : https://aws.amazon.com/blogs/machine-learning/demystifying-machine-learning-at-the-edge-through-real-use-cases/