Veröffentlichung der EdgeX 2.0 Plattform für das Internet der Dinge

Die Veröffentlichung von EdgeX 2.0 wurde vorgestellt, einer offenen, modularen Plattform zur Gewährleistung der Interoperabilität zwischen IoT-Geräten, Anwendungen und Diensten. Die Plattform ist nicht an die Hardware bestimmter Anbieter oder Betriebssysteme gebunden und wird von einer unabhängigen Arbeitsgruppe unter der Schirmherrschaft der Linux Foundation weiterentwickelt. Die Komponenten der Plattform sind in Go geschrieben und stehen unter der Apache 2.0-Lizenz.

EdgeX ermöglicht die Erstellung von Gateways, die vorhandene IoT-Geräte verbinden und Daten von verschiedenen Sensoren sammeln. Das Gateway kümmert sich sowohl um die Organisation der Interaktion mit den Geräten als auch um die Durchführung der ersten Verarbeitung, Aggregation und Analyse von Informationen, wobei es als Zwischenglied zwischen einem Netzwerk von IoT-Geräten und einem lokalen Managementzentrum oder einer Cloud-Managementinfrastruktur fungiert. Auf den Gateways können auch Handler ausgeführt werden, die als Mikrodienste formuliert sind. Die Interaktion mit IoT-Geräten kann über kabelgebundene oder drahtlose Netzwerke unter Verwendung von TCP/IP-Netzen und spezifischen (Nicht-IP) Protokollen organisiert werden.

Gateways verschiedener Art können in Ketten verbunden werden. Beispielsweise kann ein Gateway der ersten Ebene Aufgaben im Bereich Geräteverwaltung (Systemmanagement) und Sicherheit übernehmen, während ein Gateway der zweiten Ebene (Fog-Server) eingehende Daten speichert, Analysen durchführt und Services bereitstellt. Das System ist modular, daher erfolgt die Aufteilung der Funktionalität auf separate Knoten je nach Last: In einfachen Fällen genügt ein Gateway, während für große IoT-Netzwerke möglicherweise ein ganzer Cluster bereitgestellt werden kann.

Die Grundlage von EdgeX bildet der offene IoT-Stack Fuse, der in Gateways für IoT-Geräte wie Dell Edge Gateway eingesetzt wird. Die Plattform kann auf beliebiger Hardware installiert werden, einschließlich Server Hardware mit x86- und ARM-CPUs, die unter Linux, Windows oder macOS betrieben wird. Das Projekt umfasst eine Sammlung von fertigen Mikrodiensten zur Datenanalyse, Sicherheit, Verwaltung und zur Lösung verschiedener Aufgaben. Für die Entwicklung eigener Mikrodienste können die Programmiersprachen Java, Javascript, Python, Go und C/C++ verwendet werden. Für die Entwicklung von Treibern für IoT-Geräte und Sensoren wird ein SDK angeboten.

Hauptänderungen:

• Eine neue Web-Oberfläche wurde implementiert, die mit dem Angular JS-Framework erstellt wurde. Zu den Vorteilen des neuen GUI gehören die einfache Wartung und Erweiterung der Funktionalität, die Verfügbarkeit eines Assistenten zur Verbindung neuer Geräte, Mittel zur Datenvisualisierung, eine erheblich verbesserte Benutzeroberfläche zur Verwaltung von Metadaten und Überwachungsmöglichkeiten für den Zustand von Diensten (z. B. Speicherverbrauch, CPU-Auslastung usw.).
• Die API zur Interaktion mit Mikrodiensten wurde vollständig neu geschrieben und ist jetzt unabhängig vom Kommunikationsprotokoll, sicherer, gut strukturiert (benutzt JSON) und bietet bessere Möglichkeiten zur Verfolgung der vom Dienst verarbeiteten Daten.
• Die Effizienz wurde erhöht und die Möglichkeit zur Erstellung leichter Konfigurationen geschaffen. Die Core Data-Komponente, die für die Datenspeicherung zuständig ist, ist jetzt nicht mehr obligatorisch (zum Beispiel kann sie weggelassen werden, wenn nur Daten von Sensoren verarbeitet werden sollen, ohne sie speichern zu müssen).
• Die Zuverlässigkeit wurde erhöht und die Mittel zur Gewährleistung der Servicequalität (QoS) erweitert. Bei der Übertragung von Daten von den Gerätediensten (Device Services, verantwortlich für die Datenerfassung von Sensoren und Geräten) zu den Anwendungsdiensten (Application Services) kann jetzt eine Nachrichtenbus (Redis Pub/Sub, 0MQ oder MQTT) verwendet werden, ohne an das HTTP-REST-Protokoll gebunden zu sein und die QoS-Prioritäten auf der Ebene des Message Brokers zu steuern. Zudem ist die direkte Datenübertragung von Device Service zu Application Service mit optionaler Duplizierung in den Core Data Service erlaubt. Die Unterstützung der Datenübertragung über das REST-Protokoll bleibt erhalten, wird jedoch standardmäßig nicht verwendet.
• Ein universelles Modul (Secret Provider) wurde implementiert, um geheime Daten (Passwörter, Schlüssel usw.) aus geschützten Speichern wie Vault abzurufen.
• Zur Verwaltung des Dienstregisters und der Einstellungen sowie zur Zugriffs- und Authentifizierungssteuerung wurde das Tool Consul eingesetzt. Im API Gateway wurde die Unterstützung für den Zugriff auf die API von Consul bereitgestellt.
• Die Anzahl der Prozesse und Dienste, die Root-Rechte in Docker-Containern benötigen, wurde minimiert. Ein Schutz wurde hinzugefügt, um die Verwendung von Redis im unsicheren Modus zu verhindern.
• Die Konfiguration des API Gateway (Kong) wurde vereinfacht.
• Die Geräteprofile wurden vereinfacht, in denen die Parameter für Sensoren und Geräte sowie die gesammelten Daten festgelegt werden. Die Profile können in den Formaten YAML und JSON definiert werden.
• Neue Gerätedienste hinzugefügt:
  • CoAP (in C geschrieben) mit Implementierung des Constrained Application Protocol.
  • GPIO (in Go geschrieben) zur Verbindung mit Mikrocontrollern und anderen Geräten, einschließlich Raspberry Pi-Platinen, über GPIO-Ports (General Pin Input/Output).
  • LLRP (in Go geschrieben) mit Implementierung des LLRP (Low Level Reader Protocol) zur Verbindung mit RFID-Lesegeräten.
  • UART (in Go geschrieben) mit Unterstützung für UART (Universal Asynchronous Receiver/Transmitter).
• Die Funktionen der Anwendungsdienste (Application Services), die für die Vorbereitung und den Export von Daten zur weiteren Verarbeitung in Cloud-Systemen und -Anwendungen verantwortlich sind, wurden erweitert. Unterstützung für die Datenfilterung von Sensoren nach Gerätenamen und Ressourcentyp hinzugefügt. Die Möglichkeit, Daten von einem Dienst an mehrere Empfänger zu senden und sich auf mehrere Nachrichtenbusse zu abonnieren, wurde umgesetzt. Eine Vorlage für die schnelle Erstellung eigener Anwendungsdienste wurde vorgeschlagen.
• Die ausgewählten Portnummern für Microservices entsprechen den von der IANA (Internet Assigned Numbers Authority) empfohlenen Bereichen für die private Nutzung, um Konflikte mit bestehenden Systemen zu vermeiden.

Quelle: opennet.ru