Fermer

décembre 3, 2022

Examen des solutions IoT industrielles – Partie I11 minutes de lecture


Introduction

Edge computing et plus généralement l’essor de Industrie 4.0 offre une valeur considérable pour votre entreprise. Avoir la bonne stratégie de données est essentiel pour accéder aux bonnes informations au bon moment et au bon endroit. Le traitement des données sur site vous permet de réagir aux événements en temps quasi réel et la propagation de ces données à chaque partie de votre organisation ouvrira un tout nouveau monde de capacités et stimulera l’innovation.

Aujourd’hui, nous voulons que la périphérie soit une extension du cloud, nous recherchons la cohérence entre les environnements et les conteneurs sont au centre de cette révolution. Il faudrait beaucoup trop de temps pour faire un examen complet de toutes les solutions disponibles, donc dans cette première partie, je vais me concentrer uniquement sur AWS, Azure – en tant que principaux fournisseurs de cloud – ainsi que sur les approches de cloud hybride utilisant Kubernetes.

Vue d’ensemble de la solution

Au cœur de l’industrie 4.0 se trouve la collecte de données d’équipements et d’appareils et la diffusion de ces données aux sites locaux ainsi qu’au reste de l’organisation. Le flux de données de base peut être résumé comme suit :

  1. Les événements sont émis par les appareils IoT via OPC-UA ou MQTT vers un courtier local
  2. Une partie des données brutes est consommée directement pour un traitement en temps réel (détection d’anomalies, tableaux de bord RT, etc)
  3. Une partie des données est (sélectivement) copiée sur un courtier de messages pour les services événementiels, l’analyse en continu
  4. Les messages sont également (sélectivement) transférés vers le cloud à des fins d’analyse et d’intégration globale
  5. La configuration peut également être repoussée vers les sites après analyse

Flux de données

Collecte de données

En regardant le côté le plus en bordure de notre diagramme (en haut en vert clair), la première étape de la solution consiste à collecter les données des appareils. OPC-UA est très typique des équipements industriels et de la manière historique dont nous avons collecté les événements dans l’usine. La deuxième option, plus moderne, est MQTT, désormais disponible sur la plupart des appareils IoT et certains équipements industriels. Les deux sont des protocoles de transport optimisés pour l’IoT comme HTTP. OPC-UA spécifie également une structure de données standard pour les informations sur l’équipement, tandis que Sparkplug est la spécification de structure de données standard pour MQTT.

La plupart des usines auront un mélange des deux, avec des équipements plus anciens se connectant à un serveur OPC-UA qui est relié à un courtier MQTT

AWS

AWS IoT Sitewise Edge fournit une passerelle MQTT et offre une prise en charge prête à l’emploi pour la transformation OPC-UA vers MQTT. AWS Sitewise Edge est idéal pour surveiller les appareils sur place et exécuter/visualiser des analyses simples. La passerelle Sitewise Edge copie ensuite les données dans le cloud où elles peuvent être traitées par AWS IoT Core et reliées à d’autres systèmes. Les systèmes en aval peuvent être des services AWS IoT, d’autres services AWS comme Kinesis, S3, Quicksight, etc. ou des produits non AWS comme Kafka, Spark, EMR, Elasticsearch, etc. Sitewise Edge est un produit logiciel qui peut être déployé sur l’avant-poste AWS dont nous parlerons plus tard, ou sur une infrastructure existante, un environnement bare-metal ou virtualisé.

AWS Sitewise Edge - Source : AWS

Périphérie AWS Sitewise – Source : AWS

Azur

La périphérie Azure IoT Edge est l’équivalent d’AWS Sitewise pour Microsoft. IoT Edge se connecte directement à Azure Iot Hub pour rendre les données disponibles dans le cloud Azure, qui peuvent ensuite être traitées à l’aide de toute la gamme de services Azure tels que Stream Analytics, Functions, Event Hub, etc.

Autogéré

Vous pouvez également exécuter votre propre courtier OPC-UA & MQTT à la périphérie, dans l’une des options de calcul dont nous parlerons ci-dessous, mais vous serez responsable du transfert de ces données vers le cloud. Red Hat AMQ, Moustique Eclipse, HiveMQ sont des courtiers MQTT courants avec divers degrés de sophistication. Red Hat Fuse, qui fait partie de la Suite d’intégration Red Hatpeut également être utilisé pour configurer un serveur OPC-UA si vous n’utilisez pas déjà une solution prête à l’emploi comme Ignition d’Inductive Automation.

C’est une excellente option si vous ne faites que commencer et que vous souhaitez créer rapidement un prototype, car ils ont tous des versions d’essai et/ou sont tout simplement des solutions open source gratuites. HiveMQ et Mosquitto sont du MQTT pur, tandis que l’implémentation MQTT de Red Hat Integration est plus brute, mais offre une gamme beaucoup plus large de fonctionnalités au-delà de MQTT. Vous ne pouvez pas vous tromper avec cette option, elle évoluera très bien, vous aurez beaucoup plus de flexibilité, pas de verrouillage du fournisseur, mais il y a un assemblage requis.

Pile MQTT/Kafka autogérée – Source : RedHat

Pile MQTT/Kafka autogérée – Source : Chapeau rouge

Données en continu

Afin de traiter les données à des fins d’analyse, de détection d’erreurs, de ML en général, etc., nous devons les déplacer vers un système de messagerie plus adapté. La solution la plus courante pour ce type de charge de travail est Kafka, et la plupart des outils d’analyse savent déjà comment en consommer les données. Kafka prend également en charge la réplication entre les sites, c’est donc une excellente option pour déplacer les données entre les sites et vers le cloud.

Si vous utilisez Sitewise edge ou Azure Edge et que vous n’avez pas besoin de Kafka en périphérie, les données MQTT seront automatiquement transmises pour vous vers le cloud (AWS IoT Core & Azure IoT Hub). Vous pouvez ensuite envoyer ces données à votre cluster Kafka hébergé dans le cloud si vous le souhaitez (et vous devriez certainement le faire).

Automobile – L'impact de la California Consumer Privacy Act sur les constructeurs automobiles

Si vous utilisez votre propre courtier MQTT, vous pouvez utiliser la réplication MQTT vers le cloud dans certains cas (Mosquitto Mirroring, HiveMQ Replication), mais une meilleure option consiste à utiliser Kafka et à tirer parti de la fonctionnalité de mise en miroir.

Les implémentations de Kafka sont nombreuses, RedHat AMQ Streams, qui fait partie de la suite d’intégration RedHat, Strimzi pour Kubernetes et Confluent Kafka sont les fournisseurs les plus reconnus. Ni AWS ni Azure n’ont géré les produits Kafka à la périphérie, mais ont d’autres moyens – natifs – d’exécuter des analyses (Kinesis, Event Hub, etc.), mais nous en reparlerons plus tard.

Options de calcul

Ensuite, nous devons exécuter des charges de travail à la périphérie pour traiter les données. Encore une fois, nous aurons 3 options pour la configuration de l’infrastructure et de nombreuses options pour déployer des applications sur cette infrastructure.

AWS

Si vous ne disposez pas d’une infrastructure de calcul existante à la périphérie ou si vous essayez d’étendre votre empreinte AWS existante aux emplacements périphériques, le moyen le plus simple est sans aucun doute AWS Outpost. Outpost sont des serveurs AWS physiques que vous exécutez sur votre site, qui sont préconfigurés avec des services AWS similaires à ceux exécutés dans le cloud AWS et s’intègrent de manière transparente à votre cloud AWS existant. Considérez-le comme une région privée avec certaines limitations.

Sitewise Edge peut être déployé directement sur les serveurs Outpost en tant que solution clé en main pour l’analyse de base sur site. Vous pouvez le coupler avec Wavelength pour les sites sans connexion Internet existante, passant par les réseaux 5G.

AWS Snowball Edge est une autre option matérielle plus adaptée aux environnements difficiles, aux sites distants sans connexion lorsque vous souhaitez traiter les données localement et éventuellement déplacer les données physiquement dans le cloud (et je veux dire physiquement, comme en renvoyant l’appareil à AWS afin qu’ils peut copier le stockage)

Outpost peut exécuter localement des services AWS tels que S3, ECS, EKS, RDS, Elasticache, EMR, volumes EBS, etc.

Vous pouvez également exécuter AWS IoT Greengrass sur les deux appareils et l’utiliser pour exécuter les fonctions Lambda et Kinesis Firehose.

Voici un article intéressant sur l’exécution de Confluent Kafka sur les appareils Snowball : https://www.confluent.io/blog/deploy-kafka-on-edge-with-confluent-on-aws-snowball/

Azur

Azure IdO Edge - Source : Azure

Bord de la pile est l’homologue Azure d’AWS Outpost, avec la mini-série pour des cas d’utilisation similaires à AWS Snowball. Encore une fois, ici, une intégration transparente avec votre cloud Azure existant. Azure Stack Hub peut exécuter les services Azure localement, en créant essentiellement une région Azure sur votre site.

Périphérie IdO est le runtime, similaire à AWS Greengrass, avec des fonctionnalités spécifiques à l’IoT. Les services Azure comme Azure Functions, Azure Stream Analytics et Azure Machine Learning peuvent tous être exécutés localement via Azure IoT Edge.

Kubernetes (sur bare-metal ou vms)

Bien sûr, les deux options ci-dessus sont excellentes si vous êtes déjà familier et/ou engagé dans un fournisseur de cloud et que vous utilisez les services natifs du fournisseur de cloud. Si vous ne l’êtes pas, le temps de montée en puissance peut être un peu intimidant, et même en tant qu’architecte AWS chevronné, comprendre comment configurer tous les composants à la périphérie n’est pas simple.

Une première étape plus facile à la périphérie, que vous disposiez ou non d’une infrastructure de calcul existante, consiste à utiliser vos propres serveurs et à déployer Kubernetes. Si vous connaissez déjà Kubernetes, c’est bien sûr beaucoup plus facile. Si vous partez de zéro, sans aucune connaissance préalable de Kubernetes ou des solutions de pointe des fournisseurs de cloud, je ne sais honnêtement pas laquelle serait la plus rapide à mettre en œuvre.

Pour Kubernetes, Red Hat Openshift est une excellente option. La suite de produits Red Hat contient à peu près tout ce dont vous avez besoin pour créer une solution de pointe solide en quelques clics, via OperatorHub. L’intégration de Red Hat fournit MQTT, Kafka, des runtimes pour vos microservices de traitement de messages et Plateforme de données ouvertes pour IA/ML. Red Hat a publié un plan pour l’avantage industriel pour vous aider à démarrer : https://redhat-gitops-patterns.io/industrial-edge/

Edge IIoT sur Kubernetes

Edge IIoT sur Kubernetes

Les 3 options ont la capacité d’exécuter Kubernetes à la périphérie : AWS EKS, Azure AKS ou Kubernetes ordinaire (que je ne recommande pas) ou Openshift (le meilleur). Un grand avantage d’utiliser Openshift est l’expérience et les processus cohérents dans tous les environnements, y compris le multi-cloud. GitOps est un moyen très simple et puissant de gérer un grand nombre de clusters à grande échelle et Red Hat Advanced Cluster Manager peut être utilisé pour améliorer encore cette expérience.

Tenez compte de la complexité de la synchronisation des sites lors de l’utilisation des services natifs AWS ou Azure à la périphérie, en termes de déploiement d’applications, de changements d’architecture, etc. À l’échelle. ARM et Cloudformation sont disponibles en périphérie, mais vous ne pourrez probablement pas réutiliser votre processus CI/CD existant. Ce n’est pas le cas pour Kubernetes, les clusters edge et cloud sont traités exactement de la même manière grâce à GitOps.

Si vous optez pour Openshift, l’intégration au cloud n’est pas transparente. AWS ROSA et Azure ARO ne sont actuellement pas pris en charge sur Outpost et Stack Edge, vous êtes donc responsable de la configuration du cluster, de la sécurisation de la connexion au cloud (VPN) et de la réplication des données (Kafka Mirroring) sur le cloud… donc, comme toujours , les compromis doivent être soigneusement étudiés.

Conclusion

Les options ne manquent pas lorsqu’il s’agit de mettre en œuvre des solutions de pointe. Tous les principaux fournisseurs de cloud couvrent la plupart des besoins standard, des pipelines de données de bout en bout avec des services natifs, même des racks de serveurs préconfigurés que vous pouvez simplement insérer dans votre infrastructure existante. Ceux-ci vous permettent d’étendre facilement votre architecture cloud existante dans des emplacements physiques. Vous pouvez également apporter votre propre matériel et logiciel. Intégration Red Hat exécutée sur Openshift, ou la version récente Microshift s’exécuter sur Linux optimisé en périphérie est une solution très puissante et rentable. Il n’y a pas de bon ou de mauvais choix ici, il vous suffit de prendre en compte l’effort, le coût et le délai et de trouver la solution avec le meilleur retour sur investissement.

Restez à l’écoute pour la prochaine partie de cette série dans laquelle nous allons parcourir la démo Red Hat IIoT et voir ce que nous pouvons encore construire sur cette base.






Source link

décembre 3, 2022