La sortie de EdgeX 2.0, une plateforme modulaire ouverte pour permettre l'interaction entre les appareils IoT, les applications et les services, a été annoncée. La plateforme n'est pas liée au matériel de fournisseurs spécifiques ni aux systèmes d'exploitation, et elle est développée par un groupe de travail indépendant sous l'égide de la Linux Foundation. Les composants de la plateforme sont écrits en langage Go et sont distribués sous la licence Apache 2.0.
EdgeX permet de créer des passerelles reliant les appareils IoT existants et collectant des données provenant de différents capteurs. La passerelle s'occupe à la fois de l'organisation de l'interaction avec les appareils et effectue le traitement primaire, l'agrégation et l'analyse des informations, agissant comme un lien intermédiaire entre le réseau d'appareils IoT et un centre de gestion local ou une infrastructure cloud. Des traitements peuvent également être exécutés sur les passerelles sous forme de microservices. L'interaction avec les appareils IoT peut être établie par réseau filaire ou sans fil en utilisant des réseaux TCP/IP et des protocoles spécifiques (non-IP).
Des passerelles de différentes fonctions peuvent être liées en chaînes, par exemple, une passerelle de premier niveau peut gérer la gestion des appareils (system management) et assurer la sécurité, tandis qu'une passerelle de deuxième niveau (serveur fog) conserve les données entrantes, réalise des analyses et fournit des services. Le système est modulaire, donc la répartition des fonctionnalités en nœuds séparés est effectuée en fonction de la charge : dans les cas simples, une seule passerelle suffit, tandis que pour de grands réseaux IoT, un cluster entier peut être déployé.
La plateforme EdgeX repose sur la pile IoT ouverte Fuse, qui est utilisée dans les passerelles pour les appareils IoT Dell Edge Gateway. La plateforme peut être installée sur n'importe quel matériel, y compris serveurs celui basé sur CPU x86 et ARM, fonctionnant sous Linux, Windows ou macOS. Le projet comprend une sélection de microservices prêts à l'emploi pour l'analyse des données, la sécurité, la gestion et la résolution de diverses tâches. Pour le développement de microservices personnalisés, les langages Java, Javascript, Python, Go et C/C++ peuvent être utilisés. Un SDK est proposé pour le développement de pilotes pour les appareils IoT et les capteurs.
Principales modifications :
- Une nouvelle interface web a été mise en œuvre, créée à l'aide du cadre Angular JS. Parmi les avantages de la nouvelle interface utilisateur, on trouve la facilité de maintenance et d'extension des fonctionnalités, la présence d'un assistant pour connecter de nouveaux appareils, des outils pour visualiser les données, une interface considérablement améliorée pour la gestion des métadonnées, ainsi que des capacités de surveillance de l'état des services (utilisation de la mémoire, charge CPU, etc.).
- L'API pour travailler avec les microservices a été entièrement réécrite, elle n'est plus dépendante du protocole de communication, est plus sécurisée, bien structurée (utilise JSON) et suit mieux les données traitées par le service.
- L'efficacité a été améliorée et la possibilité de créer des configurations légères a été fournie. Le composant Core Data, responsable de la sauvegarde des données, n'est maintenant plus obligatoire (par exemple, il peut être exclu lorsqu'il s'agit uniquement de traiter des données provenant des capteurs sans avoir besoin de les sauvegarder).
- La fiabilité a été améliorée et les moyens d'assurer la qualité de service (QoS) ont été étendus. Lors de la transmission de données des services d'appareils (Device Services, responsables de la collecte des données des capteurs et des appareils) vers les services de traitement et de stockage des données (Application Services), il est désormais possible d'utiliser un bus de messages (Redis Pub/Sub, 0MQ ou MQTT) sans se limiter au protocole HTTP REST, tout en régulant les priorités QoS au niveau du courtier de messages. Il est également permis de transmettre directement les données du Service d'appareil vers le Service d'application avec une duplication optionnelle dans le service Core Data. La prise en charge de la transmission de données via le protocole REST est maintenue, bien qu'elle ne soit pas utilisée par défaut.
- Un module universel (secret provider) a été mis en place pour extraire des données secrètes (mots de passe, clés, etc.) depuis des stockages sécurisés, tels que Vault.
- Un outil Consul a été utilisé pour gérer le registre des services et des configurations, ainsi que pour gérer l'accès et l'authentification. Dans l'API Gateway, la prise en charge d'appels à l'API Consul a été ajoutée.
- Le nombre de processus et de services nécessitant des droits root dans les conteneurs Docker a été minimisé. Une protection a été ajoutée pour éviter l'utilisation de Redis en mode non sécurisé.
- La configuration de l'API Gateway (Kong) a été simplifiée.
- Les profils d'appareils ont été simplifiés, où sont définis les paramètres des capteurs et des appareils, ainsi que les informations sur les données collectées. Les profils peuvent être définis dans les formats YAML et JSON.
- De nouveaux services d'appareils ont été ajoutés :
- CoAP (écrit en C) avec une mise en œuvre du protocole Constrained Application Protocol.
- GPIO (écrit en Go) pour la connexion aux microcontrôleurs et à d'autres dispositifs, y compris les cartes Raspberry Pi, via les ports GPIO (General Pin Input/Output).
- LLRP (écrit en Go) avec une mise en œuvre du protocole LLRP (Low Level Reader Protocol) pour se connecter aux lecteurs d'étiquettes RFID.
- UART (écrit en Go) avec support de l'UART (Universal Asynchronous Receiver/Transmitter).
- Les fonctionnalités des services d'application (Application Services), responsables de la préparation et de l'exportation des données pour un traitement ultérieur dans des systèmes et applications cloud, ont été étendues. La prise en charge du filtrage des données des capteurs par nom de profil d'appareil et type de ressource a été ajoutée. Il est maintenant possible qu'un service envoie des données à plusieurs destinataires et de s'abonner à plusieurs bus de messages. Un modèle a été proposé pour faciliter la création rapide de ses propres services d'application.
- Les numéros de ports sélectionnés pour les microservices sont conformes aux plages recommandées par l'IANA (Internet Assigned Numbers Authority) pour une utilisation privée, ce qui permet d'éviter les conflits avec les systèmes existants.
Source : opennet.ru
