Edge Gateways im IIoT – die Qual der Wahl – ein Erfahrungsbericht

Um was geht es bei Edge Gateways im IIoT? 

Es gibt unzählige Geräte auf dem Markt, die als Edge oder IIoT-Gateway eingesetzt werden können sowie als diese vermarktet werden. 
In diesem Blogbeitrag will ich eine Übersicht über das Spektrum dieser Geräte geben – ohne Anspruch auf Vollständigkeit, stattdessen mit Erfahrungen, die ich bisher mit verschiedenen Geräten gemacht habe. Somit will ich hier kein Marktüberblick geben – sondern viel mehr „aus dem Nähkästchen plaudern“ und meinen persönlichen Blick auf den Markt teilen.

Kurz zur Erklärung – IIoT ist die Erweiterung von Maschinen, um digitale Services, die es ermöglichen Use-Cases wie beispielsweise Condition Monitoring umzusetzen. Um dies zu erreichen ist es meist sinnvoll, neben beispielsweise einer bestehenden MES-Anbindung, eine weitere OT-IT Konnektivität herzustellen. Auch wenn diese Funktionalität von der Maschinensteuerung übernommen werden könnte, macht es aus Sicht der Kapselung von Zuständigkeiten meistens Sinn, eine separate Hardware einzuführen, die für die IIoT-Anwendung diese Aufgabe übernimmt. Hierzu werden Edge-Geräte bzw. IoT Gateways eingesetzt. Genau genommen haben hierbei Edge-Geräte tendenziell mehr Ressourcen als IoT Gateways. Da die Übergänge dennoch fließend sind, verwende ich die Begriffe im weiteren als Synonyme.

Anforderungen an IoT Gateways

Telemetrie

Die prominenteste Aufgabe des Geräts ist es die vor Ort anfallenden Daten einzusammeln. Hier ist eine breite Konnektivität wichtig. Entscheidende Datenquellen können zum einen die Maschinensteuerungen sein, mit ihren unterschiedlichen Schnittstellen. Dazu zählen beispielsweise Siemens S7 Kommunikation oder allgemeinere Feldbusse wie Profibus, Modbus oder im mobilen Umfeld oft CAN-Bus sowie industrial Ethernet Protokolle wie Profinet, ModbusTCP, EtherCat und weitere. 

Eine weitere Art Zustandsdaten der Maschine zu erhalten ist durch extra für den IoT Use-Case angebrachte Sensoren. Hierzu zählen beispielsweise Vibrationssensoren oder Sensoren, die die Temperatur und Feuchtigkeit der Umgebungsluft überwachen, um zusätzliche Einflussfaktoren zu protokollieren, die für die reine Steuerung der Maschine nicht relevant sind. 
Wenn das Gerät dann direkt mit Sensoren über Protokolle wie IO-Link, I2C kommunizieren kann oder über analoge Spannungseingänge verfügt, – abhängig von der Art der verwendeten Sensoren, ist dies ein Vorteil, da so der Bedarf an zusätzlichen IO-Modulen entfällt.

Die Möglichkeit zusätzliche Bus-Converter oder AD-Wandler einzusetzen, besteht natürlich dennoch, aber zu welchem Preis? Oft benötigt man dann noch eine weitere Feldbus-Schnittstelle oder ähnliches, was zusätzliche Kompatibilitäts-Problematiken mit sich bringt und den Entwicklungsaufwand vergrößert. 

Wichtig ist auch eine Unterscheidung zwischen Hardware und Software. Einige Bussysteme benötigen spezielle Hardware wie beispielsweise Profibus. Andere können mit Standardhardware funktionieren wie Profinet (in einer unteren Konformitätsklasse) [https://www.profibus.com/index.php?eID=dumpFile&t=f&f=44266&token=1d81c134b224334c62d388673080f12267581e62]. So ist jedes Gerät, das Ethernet unterstützt und entweder einen vorinstallierten Profinet-Treiber besitzt oder die eigene Installation dessen zulässt, theoretisch Profinet-fähig.

Die Unterstützung von Schnittstellen muss also nicht immer zwingend ein hartes Ja/Nein sein. Hier der Versuch die Reife der Konnektivität in Kategorien aufzuteilen, aufsteigend nach Aufwand sortiert:

1. HW-Schnittstelle und konfigurierbare Treiber vorhanden (z.B. Konfiguration über Files, lokale UI, oder Cloud Anwendung (mehr dazu unten))
   
2. HW-Schnittstelle nicht im Basismodul vorhanden, aber mit vorinstallierter und konfigurierter Software durch EA Module schnell erweiterbar
   
3. HW-Schnittstelle (z.B. Ethernet/ RJ45) vorhanden, aber keine Industriespezifischen Treiber vorinstalliert (z.B. Profinet) à Software ist frei installierbar  
   
4. HW-Schnittstelle nicht vorhanden, durch IO-Module von Drittanbietern erweiterbar (z.B. Modbus TCP wird unterstützt, Erweiterung mit IO-Link-Master mit Upstream Modbus TCP)
   
5. HW-Schnittstelle (z.B. Ethernet/ RJ45) vorhanden, aber keine industriespezifischen Treiber vorinstalliert (z.B. Profinet), geschlossenes System und keine Möglichkeit eigene Software zu installieren. Hier ist ein zusätzlicher Konverter nötig.

Für ein Projekt heißt das, dass man am besten schon vorher weiß, welche Datenquellen vorliegen und wie deren Schnittstellen aussehen. Dieses Wissen erspart spätere Erweiterungen, die dank des großen Angebots an Konvertern und Eingangsmodulen immer möglich sind, jedoch aufwändig sein können.

Devicemanagement

Devicemanagement-Funktionalitäten werden im klassischen Maschinenbau oft noch vernachlässigt oder nicht hoch genug priorisiert. Es ist üblich, dass eine Änderung auf allen Maschinensteuerungen einzeln durch eine Remote-Verbindung eingespielt wird. Bei Safety-Relevanten Funktionen ist es sinnvoll vor Ort zu sein, aber für eine IIoT Lösung, die sowieso keine Aktoren steuern sollte, ist dies kein Argument. Hier kann ein ausgereiftes Devicemanagement seine Stärken voll ausspielen. Somit ist genau dies eine der wichtigsten Softwarefunktionalitäten, die ein Gateway bereitstellen muss. 

Ein umfangreiches Devicemanagement kann folgende Funktionen umfassen: 

• Zentrale Softwareverteilung und -aktualisierung (inklusive OS/Firmware Updates)
• Geräte-Inventarisierung 
• Geräte-Konfiguration
  • OT Schnittstellen-Konfiguration (z.B. für Feldbussysteme / OPC UA)
• Zentrale Datensicherung / Backups
• Lifecycle-Management
  • Massen-Inbetriebnahme/Provisionierung
  • Diebstahlsicherung (Zerstörung der Daten, Sperren der Zugänge)
  • Austausch einer Hardware, ohne Ersetzung der SW-Identität (um Konsistenz in Datenhaltung und Visualisierung zu gewährleisten) 
    

Cloud-Konnektivität

Eine sichere Cloud-Konnektivität ist heutzutage relativ einfach umgesetzt. Dennoch gibt es Unterschiede: Will ich nur Messdaten in die Cloud schicken oder Devicemanagement ermöglichen? Will ich alles von einer einzigen Plattform aus managen oder sind unterschiedliche Plattformen für Telemetrie und Devicemanagement in Ordnung? 

Diese Fragen spielen eine große Rolle bei der Wahl des passenden Gateway-Gerätes und der Abschätzung des Entwicklungsaufwandes. 

Weiterhin stellt sich bei der Cloudfähigkeit die Frage wie vorbereitet das Gateway für eine IoT Plattform bereits ist – von unausgereift bis ausgereift:

1. HW-Schnittstellen Upstream vorhanden (Ethernet WiFi, LTE,), aber keine Software neben einem Standard-Betriebssystem vorinstalliert:
   
   Nachteil ist hier, dass man sich um die gesamte Cloud-Konnektivität selbst kümmern muss. 
   
   Vorteil ist die Freiheiten, die es bietet. Viele Plattformanbieter bieten Agenten an, die die Verbindung zur Plattform herstellen und für das Senden von Messdaten über Devicemanagement-Funktionen konfiguriert werden können – z.B. Azure IoT mit der Edge-Runtime oder Cumulocity IoT mit dem thinedge.io Agent.
   
2. Devicemanagement über eine Cloud Plattform, für Messdaten lediglich Basisprotokolle vorhanden (MQTT OPC UA):
   
   In diesem Szenario wird das Gateway mit vorinstallierter Software mit der Cloud Plattform verbunden, um Devicemanagement-Funktionen bereitzustellen. Für die Übertragung von Messdaten ist eine MQTT-Schnittstelle vorbereitet, die Daten nach einer Konfiguration an einen beliebigen Empfänger senden kann, oder ein OPC UA Server, die die Daten gesammelt bereitstellt. 
   
   Hier ist es also nötig eine weitere vom Devicemanagement des Herstellers separate Plattform für die Messdaten bereitzustellen, die dann die per MQTT oder OPC UA bereitgestellten Daten empfangen bzw. abholen und weiterverarbeiten (speichern, visualisieren etc.) kann.
   
3. Volle Integration in einen (oder mehrere) Cloudanbieter:
   
   Voll integriert bedeutet, dass das Gateway bereits für die Einbindung in eine Cloudplattform vorkonfiguriert ist. Dadurch wird die Integration wesentlich vereinfacht. Es ist zudem vorteilhaft, dass durch die vorkonfigurierten Einstellungen ein schnellerer und zuverlässiger Zugriff auf Daten in die Cloud gewährleistet wird. Einige Gateway-Hersteller bieten bereits vorkonfigurierte Cloud-Gateways für einige der beliebtesten Cloud-Plattformen an, wie AWS IoT, Microsoft Azure oder Cumulocity IoT.
   

Managed OS im IoT

Ein Managed OS ist ein Betriebssystem, das speziell für ein Gerät im IoT entwickelt wurde und von einem externen Dienstleister betreut wird. Dies bedeutet, dass der Dienstleister regelmäßig Sicherheitsupdates und Patches bereitstellt, um die Integrität und Sicherheit des Systems zu gewährleisten.

Einer der Hauptvorteile von Managed OS in IoT-Geräten ist, dass sie den Betreibern eine einfache Möglichkeit bieten, ihre Geräte auf dem neuesten Stand zu halten und sicherzustellen, dass sie nicht durch Sicherheitslücken anfällig für Angriffe sind. Es gibt auch meistens einen Support, den man bei Fragen oder Problemen kontaktieren kann. Ein weiterer Vorteil von Managed OS ist, dass sie häufig speziell für die Anforderungen von IoT-Geräten optimiert sind, was bedeutet, dass sie in der Regel leichter, schneller und energieeffizienter sind als herkömmliche Betriebssysteme.

Allerdings gibt es auch einige Nachteile, die bei der Verwendung von Managed OS in IoT-Geräten berücksichtigt werden sollten. Einer davon ist, dass sie in der Regel teurer sind als herkömmliche Betriebssysteme. Der größte Nachteil jedoch ist die meist fehlende Offenheit der Systeme. Viele IoT Gateways bieten für den Projektierenden lediglich Konfigurationsmöglichkeiten der installierten Software. Das schränkt die Anwendung bei komplexeren Aufgaben ein. Beispielsweise kann es nötig sein einen weiteren Aggregationstyp für die Sensordaten einzuführen, wie die Standartabweichung oder eine Fast-Furier Transformation. Standardmäßig wird oft nur „Min“, „Max“ und „Average- Aggregation“ unterstützt. Wenn die Software des Gateways dann keine offenen Schnittstellen zur Erweiterung bietet, kann der geforderte Anwendungsfall nicht umgesetzt werden. 

Manche Gateways bieten hier Kompromisse an und lassen sehr eingeschränkt eigene Software zu, wie beispielsweise das Ewon Flexy 205, das ein C-Skript erlaubt oder das INSYS MRO, das das hosten von LXC Containern erlaubt.

Mir persönlich wäre es dennoch am liebsten Docker Container auf dem Gerät betreiben zu können und eine Schnittstelle zu den auf dem Gerät verarbeiteten Daten zu haben. Oder die Möglichkeit eine Azure IoT Edge Runtime zu installieren, um Container als Azure Modules auf dem Gerät deployen und verwalten zu können.

Die Varianten

Entstehungsgeschichten/Schwerpunkte

Viele der Geräte auf dem Markt bilden die meisten der IoT Funktionen ab, unterscheiden sich jedoch im Fokus der einzelnen Hersteller deutlich. Gerade diese „Fokus-Funktionalität“ zeichnet die Geräte dann besonders durch ausgereifte, bewährte Software mit besten Konfigurationsmöglichkeiten, guter Bedienoberfläche, guten Support, detaillierte und verständliche Dokumentation usw. aus. 
Oft ist diese Entwicklung historisch bedingt, wenn ein Hersteller in der Vergangenheit speziell in einem Bereich Experte war, nun aber auch Produkte für breitere IoT Einsätze entwickelt.

Im Folgenden möchte ich eine kleine Übersicht geben, wo die (ungefähren) Schwerpunkte einiger von mir bereits verwendeter Geräte liegen. Die Geräte wurden vom Novatec-Team sorgfältig ausgewählt und verfügen alle über eine breite IoT-Funktionalität:

• HMS Ewon Flexy 205
  • Fokus: Fernwartung/ Remote Access mit Talk2M VPN
• Insys MRX /MRO
  • Fokus: Router (Firewall, VLAN, etc)
• Vergelink
  • Fokus: Usability in der OT-Connectivity zu verschiedenen PLCs
• Revolution Pi 
  • Fokus: Hardwareerweiterbarkeit mit EA-Modulen und offenes (modifiziertes) Raspberry Pi Betriebssystem, Open Source Angebote
• DAIM Edge-OS
  • Fokus: managed OS, security 
    

Make or Buy?

Diese Frage wird bei dem Agenten besonders interessant. Dies ist die Software die Daten vor Ort sammelt, die Cloud-Konnektivität herstellt und Devicemanagement-Funktionen ermöglicht. 

Hier ist die Spannweite angebotener Geräte groß. Entweder kauft man ein blanken IPC, lediglich mit vorgegebenem Betriebssystem oder wählt ein fertiges IoT Gateway, das man per Weboberfläche konfigurieren kann. Wo ich bei mich bei ersterem um die Software selbst kümmern muss, bin ich bei Punkt zwei auf die vorhandene Funktionalität begrenzt.

Dabei hat beides seine Daseinsberechtigung. Ein fertiges IoT Gateway kann man, wenn die Funktionaltäten entsprechend ausreichen, direkt in Betrieb nehmen und ist sehr komfortabel, wenn beispielsweise ein OPC UA Client oder Modbus TCP Client von einer Weboberfläche aus konfiguriert werden kann. 

Solche Gateway Software individuell zu entwickeln, würde bei vielen Projekten das Budget sprengen und ist eben auch nur dann sinnvoll, wenn die Nachteile der besten verfügbaren Software nicht zu schwer wiegen. 

Was auf dem Markt noch fehlt:

Oft reichen die Fähigkeiten eines IoT Gateways nicht aus. Es wird zwar häufig zum Beispiel Azure unterstützt und beworben, dennoch ist Azure IoT Edge nicht installiert und kann so nicht deployed werden – lediglich eine upstream MQTT-Formatierung im für Azure Format liegt vor. 
Oder Cumulocity IoT wird für Telemetriedaten unterstützt, aber um Firmwareupdates auszurollen muss man doch in die Cloud vom Gerätehersteller. 

So wäre ein Gateway, das Treiber für Feldbusse und OPC UA zur Verfügung stellt wünschenswert, um komfortabel auf die akquirierten Messwerte zugreifen zu können. 
Dennoch sollte dem Nutzer die Entscheidung überlassen werden, welcher Agent und welche Plattform installiert wird, um alle benötigten Devicemanagement-Funktionalitäten der Plattform auszuschöpfen. Sei es nun beispielsweise der thinedge.io-Agent für Cumulocity IoT oder Azure IoT Edge für Azure sowie das Deployen von Azure IoT Edge Modulen.

Fazit

Zusammenfassend ist für die Gateway-Auswahl wichtig zu wissen welche Datenquellen vorliegen und welche Schnittstellen dort zur Verfügung stehen. Außerdem sollte das Devicemanagement und der Geräte-Lifecycle betrachtet werden. Auch die Betrachtung der Stärken der favorisierten Geräte, die alle Pflichtanforderungen erfüllen, ist relevant, um beste Usability für den Bereich der häufigsten Konfigurationsänderung zu erhalten. 

Es gibt eine große Bandbreite an Geräten. Je nach Vorlieben und Anforderungen kann man sich entscheiden, ob man eine fertige Lösung kauft oder sich selbst um die Software kümmert. Die ideale Lösung, die Offenheit für einfache Erweiterungen und Vollständigkeit an Funktionalität und Abstraktion bietet, habe ich für mich jedoch noch nicht gefunden.

Somit freue ich mich auf Neuentwicklungen und bin weiterhin mit unserem Team daran weitere geeignete Geräte, die auf die speziellen Anforderungen unserer Kunden passen, zu finden, auszutesten und individuell weiterzuentwickeln.

Mehr zu unseren IoT Services erfahren Sie hier.