Vom Maschinenbauer zum Plattformbetreiber – Teil 2

Standards, Protokolle & Technologie für den Aufbau von IoT-Plattformen – Teil 2 von 3

Dieser zweite Teil der Expert View Serie richtet sich wieder an Technologie-Entscheider im Maschinen- und Anlagenbau. Nachdem sich der erste Teil mit der Frage beschäftigt hat, wie derzeit der Status Quo in der Maschinen- und Anlagenbau-Branche im Kontext der Digitalisierung aussieht und sich maßgeblich an Strategie-Entscheider richtet, dreht es sich im zweiten Teil der Expert View Serie „Vom Maschinenbauer zum Plattformbetreiber“ um Protokolle, Standards und Technologien, die beim Aufbau einer IoT-Plattform zu beachten sind.

IoT-Platform-From machine manufacturer to platform operator

Dabei ist die grundlegende Frage Make-or-Buy. Diese Frage hängt stark von der IoT- Strategie ab. Je stärker die Produkte und Plattformen am Markt als Umsatz- und Erfolgsfaktor des Unternehmens positioniert sind, desto eher muss das Unternehmen eigene Leistungen in Sachen Technologie und Business Case erbringen. Auf Basis vorgegebener Standards und Technologien sollten die Entscheider den IoT-Plattformen einen individuellen Anstrich verpassen – „Buy & Create IoT“ heißt das Motto der Zukunft.

Aber vor allem die veraltete IT- und Technologie-Architektur ist eine zentrale Herausforderung, die den Unternehmen die Umsetzung ihrer IoT-Projekte erschwert.

Daher schauen wir uns die wichtigsten Punkte bei der Umsetzung einer IoT-Plattform an, insbesondere Themen, die relevant sind für Prototyping, Plattform-Design & Sourcing, Implementierung & Integration, sowie Production & Scale:

Schneller IoT-Plattform Prototyp mit wichtigen Kernfunktionen

Services und Dokumentationen zur Unterstützung der Erstellung eines Prototyps (PoC) / Minimum Viable Products (MVP), der bereits wesentliche Funktionsbereiche innerhalb einer Testumgebung erfüllen kann. Dazu gehören auch Werkzeuge zur Messung von Performance, Skalierung und Data Analytics.

Kompatibilität mit allen gängigen Kommunikationsprotokollen

Die Sicherstellung von Messaging und Datenübertragung zwischen mehreren Geräten vom IoT Edge (Sensor) bis in die IT-Infrastruktur ist einer der wichtigsten Punkte, der beim Aufbau einer IoT-Plattform berücksichtigt werden muss. Durch die gängigen Kommunikationsprotokolle werden maschinenübertragbare und maschinenlesbare Informationen transferiert und können so verarbeitet und zurückgespielt werden. IoT-Plattformen und -Services benötigen die Kompatibilität und Integration mit möglichst allen Standards, da diese teilweise aufeinander aufbauen und sich ergänzen.

Dabei kann die IoT-Plattform auf allen Ebenen entsprechende Daten filtern und zusammenfassen. Sensoren senden beispielsweise nicht alle Daten in die Cloud, sondern nur diejenigen, die dort zur Fehleranalyse notwendig sind. Andere Daten die zu lokalen Regelmechanismen benötigt werden, verlassen unter Umständen nie die Fertigung.

Zu diesen Standards gehören u. a. HTTP-Protokolle. HTTP (Hypertext Transfer Protocol) hat den Vorteil in vielen Software-Tools integriert zu sein und lässt sich darüber hinaus schnell implementieren, wenn es um die Übertragung von Daten geht. Sofern die Datenmenge keine große Rolle spielt, kann HTTP tatsächlich eine Alternative sein. HTTP ergibt vor allem dann Sinn, wenn kleine Datenmengen an Clients geschickt werden sollen, wenn es unter Einsatz von REST-APIs genutzt wird und wenn die Internet-/Netzwerkanbindung schnell und stabil genug ist.

Sobald aber die Bandbreite und das Datenvolumen von maßgeblicher Bedeutung sind, sollte man besser auf MQTT (Message Queuing Telemetry Transport), CoAP (Constrained Application Protocol) oder XMPP (Extensible Messaging and Presence Protocol) setzen. XMPP wird allerdings zusehends weniger eingesetzt, ist aber bei bestimmten Anwendungsfällen dennoch nützlich.

MQTT hingegen ist eines der meistgenutzten Protokolle. MQTT ist sehr skalierbar und vor allem für große IoT-Umgebungen mit einer Vielzahl von Devices sinnvoll. Umfangreiche IoT-Anwendungsfälle, insbesondere bei Produktionsprozessen, lassen sich so gut abdecken.

Protokolle-Standards-From machine manufacturer to platform operator

Generell muss festgehalten werden, dass es keine Standard-Formel gibt, um zu ermitteln, welches IoT-Protokoll am besten geeignet ist. Je nach Einsatzgebiet hängt dies, von der Leistung der Devices, der Geschwindigkeit und Bandbreite des Netzwerks, der eingesetzten Programmiersprache und dem Einsatzort ab. Unternehmen, die sich mit dem IoT beschäftigen, kommen letztendlich kaum umhin, alle relevanten Protokolle zumindest zu testen.

Gleiche Geräte (eines Herstellers) kommunizieren meist binär. Wenn es Herstellerübergreifend offener wird, sind meist XML und Web-Protokolle zu empfehlen. Dazu gehören auch REST Calls mit einem JSON Format.

Lokale Kommunikation, zum Beispiel zwischen einem Roboter und dem Fließband, ist meist synchron und binär. Wenn also das Fließband aufhört Daten zu senden bleibt der Roboter sofort stehen (dies wäre eine typische OPC UA Anwendung).

Bei weit entfernter Kommunikation ist entweder HTTP zu empfehlen, insbesondere dann, wenn es keine zuverlässige Kommunikation sein muss, alternativ MQTT – Bei diesem Protokoll kann man die Quality of Service so einstellen, dass ein Datensatz exakt einmal erfolgreich übermittelt wird.

Status Open Platform Communication

Ein weiteres Kommunikationsprotokoll ist OPC UA. Open Platform Communication ist eines der wichtigsten Kommunikationsprotokolle für das IoT-Umfeld, welches durch die OPC Foundation (ca. 700 Mitglieder) maßgeblich weiterentwickelt und vorangetrieben wird.

Mit OPC wird der Zugriff auf Maschinen, Devices und andere Systeme im industriellen Umfeld standardisiert und es ermöglicht den gleichartigen und herstellerunabhängigen Datenaustausch.

Das UA in OPC UA steht dabei für „Unified Architecture“ und beschreibt die neueste Spezifikation des Standards. Der Unterschied zum Vorgänger liegt in der Plattformunabhängigkeit durch die Abkehr von COM/DCOM hin zu rein binärer TCP/IP oder alternativ SOAP Kommunikation. Zudem unterstützt OPC UA neben vielen weiteren Verbesserungen auch eine semantische Beschreibung von Daten.

Im Allgemeinen eignet sich die OPC-Semantik, um Daten zu beschreiben auch für die Kommunikation mit der Cloud. Die meisten verbinden aber mit OPC die lokale Binär-Kommunikation, wobei zu beachten ist, dass genau diese lieber nicht über die Cloud erfolgen sollte.

Wenn man in der maschinellen Anlage OPC UA verwendet, und Daten in die Cloud transportieren möchte, nimmt man meist ein Gateway, dass eine OPC UA Quelle, zum Beispiel in eine MQTT Queue oder in HTTP, umformt.

OPC UA schlägt so die Brücke zwischen der IP-basierten IT-Welt und den Fertigungsanlagen. Alle Daten der Fertigungsprozesse werden über ein einziges Protokoll übertragen – egal ob innerhalb einer Maschine, zwischen Maschinen oder zwischen einer Maschine und einer Datenbank in der Cloud.

Skalierbarkeit von Datenmengen und Kostenoptimierung

Die Fähigkeit, auf das Wachstum der Datenmenge, die durch vernetzte Geräte herbeigeführt wird, flexibel reagieren zu können, sollte beim Aufbau einer IoT-Plattform unbedingt berücksichtigt werden. Stark steigende Datenvolumen sollten von der Infrastruktur (Server, Storage, Netzwerk etc.) durch eine horizontal skalierbare Plattform aufgefangen werden können. Es muss sichergestellt werden, dass Devices, Anwendungen, Datentypen und Protokolle in Echtzeit ganzheitlich erfasst und integriert werden können.

Gleichzeitig muss die Skalierung insofern kosteneffizient erfolgen, dass die Auslastung möglichst hoch, die Erweiterung der Infrastruktur nach Bedarf jedoch jederzeit möglich ist. Somit muss eine hohe Infrastrukturelastizität in Abhängigkeit der Dynamik des Lastverhaltens gewährleistet sein.

Skalierung wird u. a. erreicht:

  1. indem zwischen Sensor/Aktor und der Cloud ein Edge-Device liegt.
  2. indem ein entsprechendes fehlertolerantes Protokoll gewählt wird, z. B. MQTT, wenn viele Sensoren/Aktoren verwendet werden, oder indem binäre und synchrone Protokolle lokal in fehlertolerante Protokolle umgesetzt werden und die Daten lokal selektiert werden, zum Beispiel mit einem Gateway oder einer Mini-Edge oder Medium Edge.
  3. indem Workloads an die richtige Stelle innerhalb der Topologie kommen. Wenn man in der Maschine beispielsweise 24*7 eine Videoanalyse laufen lässt, ist diese besser in einer Heavy Edge aufgehoben. Rechenleistung im 24*7 Betrieb ist in der Cloud auch nicht viel günstiger, wie professionell in der Edge. Die Workloads die allerdings Daten zwischen Werken oder entlang der Supply-Chain aggregieren oder kollaborieren, sollten in der Cloud sein.

Applikationen für Monitoring

Beim Betrieb der IoT-Plattform sollte die Möglichkeit, Überwachungslösungen zu verwenden, um Metriken über die Komponenten der Anwendung abzurufen, gegeben sein. Diese können über Dashboards und aggregierte Monitoring-Werkzeuge bereitgestellt werden. Wichtige Standardinformationen sind beispielsweise die Maschinenintegrität, die Auslastung sowie die Wartungszustände. Diese werden über die o. g. oder auch weitere spezifische Protokolle übertragen. Auch Alarmsysteme und ereignisbasierte Abfragen können relevant sein.

Schnittstellen – z. B. ERP & MES

Das Angebot von APIs und Standard-Konnektoren zu gängigen Bestandssystemen für den Abruf und Austausch von Daten, z. B. SAP, inklusive des Managements und der Erweiterung dieser APIs und Schnittstellen, sollte auf jeden Fall bereitstehen.

Referenzprojekte & Ökosystem aus der Maschinen- & Anlagenbau-Branche

Referenzprojekte und Erfahrungswerte (Best Practices) aus dem Umfeld Digital Twins im Maschinenbau auf der jeweiligen Plattform, sollten in jedem Falle so weit wie möglich als Blaupause dienen; ebenso dedizierte Services für die jeweilige Branche / den Einsatzbereich sowie Individualisierungsmöglichkeiten seitens des Anbieters.

Ein weiteres elementares Thema ist neben dem IoT-Produkt und dem jeweiligen Technologieeinsatz das Ökosystem. Vor allem innovative Unternehmen, die im Kontext von IoT schon weit vorangeschritten sind, können sich nicht in einem Vakuum entfalten und weiterentwickeln. So sind Unternehmen vielmehr auf verschiedene Ressourcen und unterschiedliche Plattformen, Technologien, Prozesse und Standards angewiesen, damit sie kooperative Netzwerke schaffen und Geschäftsmodelle erstellen können.

Automatisierte Reaktionen

Die Nutzung von Tools und Plattformdiensten sowie die Integration gängiger Standards und Drittanbieterdienste zur Herbeiführung automatisierter Reaktionen auf Basis der Sensordaten und der jeweiligen Maschinenzustände ist maßgeblich. Dazu zählen insgesamt die Automatisierung der Infrastruktur, der IoT-Plattform sowie der Datendienste.

Plattformunabhängigkeit, Cloud-Anbieter, On-Premise etc.

Die Unabhängigkeit der IoT-Plattform ist ebenfalls ein wichtiger Punkt, der bei der Auswahl der richtigen Partner eine wichtige Rolle spielt. Beschränkt man sich von vornherein auf einen Technologieanbieter, besteht die Gefahr eines Vendor Lock-In, fehlende Individualisierungsmöglichkeiten der Technologie, nicht ausreichende Virtualisierungs- und Managementdienste sowie Erweiterbarkeit der Architektur durch zusätzliche Cloud- oder On-Premise-Architekturen (Hybrid Cloud).

Zugriff auf die Maschinenflotte für den Hersteller & den Kunden

Für den Maschinenhersteller ist vor allem die Möglichkeit der Vernetzung und des Zugriffs auf relevante (anonymisierte) Daten aller Maschinen im Live-Betrieb einer der zentralsten Punkte. Im Wesentlichen ist das Berechtigungsmanagement, die Verschlüsselung, sowie die Konkretisierung der Interdependenz zwischen Plattform, Maschine, Kunde und Hersteller der Dreh-& Angelpunkt.

Für den Kunden (Maschinenbetreiber) muss aber die Möglichkeit bestehen, dass die Bereitstellung von individuellen Nutzergruppen bzw. der Entkopplung der Kunden von der restlichen IoT-Plattform zum Aufbau einer eigenen IoT-Umgebung mit dedizierter Steuerung, Entwicklung, Verwaltung etc. seitens dieses Kunden mit ausschließlich Meta-Management-Funktionen des Herstellers möglich ist.

Der entscheidende Punkt ist, dass der Anlagenbetreiber dem Anlagenhersteller so viele Daten zur Verfügung stellen sollte, dass der Hersteller in der Lage ist eine Predictive Maintenance (vorrausschauende Wartung) anzubieten und die Anlage weiter zu optimieren. Hersteller und Betreiber sollten deshalb einen offenen Dialog über die angemessene Datenspende führen. Anders ist das, wenn der Anlagenhersteller die Maschine als Equipment as a service anbietet. Dann gehören ihm ggf. die Daten und der Betreiber wird eine Verschwiegenheits-Regelung mit ihm vereinbaren.

Zusammenfassung & Self-Check IoT-Platform

Zusammenfassend lässt sich sagen, dass gerade die Technologie-Auswahl sehr von den Anforderungen einer jeweiligen Branche und der Digitalstrategie. des Unternehmens abhängt. Insbesondere bei der Evaluierung der Technologie sollte zusätzlich externe Hilfe in Anspruch genommen werden.

Betrachten wir die notwendigen technologischen Komponenten, ohne auf konkrete Produkte einzugehen, kann man diese grundsätzlich in drei Gruppen gliedern:

  • Software, die auf dem Edge Device läuft
  • Software, die man braucht, um die Edge Devices zu managen und mit
    ihnen zu kommunizieren (Device Control Management)
  • und letztlich Cloud Backends für die Erstellung weiterer Applikations-Logik.

Dazu kommen noch Infrastrukturkomponenten, die wiederum ein konsistentes Plattformmanagement sicherstellen.

IoT-Plattform-Design-Kriterien – Check

Designkriterien Bewertung
Interoperabilität zwischen Maschinen
Kompatibilität mit allen gängigen
Kommunikationsprotokollen wie
MQTT, CoAP, HTTP, OPC UA
Skalierbarkeit von Datenmengen
und Kostenoptimierung
Schneller IoT-Prototyp mit
wichtigen Kernfunktionen
Applikationen für Monitoring
z. B. Echtzeitfortschritt, Maschinenverfügbarkeit
Schnittstellen z. B. ERP
Automatisierte Reaktionen
Plattformunabhängigkeit
Cloudanbieter, On-Premise etc.
Zugriff für den Kunden auf seine Maschine
Zugriff für Hersteller auf die Maschinenflotte
Anwendungsszenarien durch Digital Twin

 

Im dritten und letzten Teil der Expert View Serie „Vom Maschinenbauer zum Plattformbetreiber“ geht es konkret darum, wie digitales Business in der Industrie gelingt und Maschinen- und Anlagenbauer zu einer Plattform-Ökonomie (Use Cases, Produkte, Geschäftsmodelle) gelangen.

Sharing Expertise – buchen Sie ihren kostenfreien Initial-Workshop!

Buchen Sie noch heute Ihren kostenfreien Initial-Workshop, um die Digitalisierungspotentiale in Ihrem Unternehmen identifizieren und heben zu können.

Identifikations-Workshop zu folgenden Themen: Digitalstrategie und datengetriebene Geschäftsmodelle, IT-Infrastrukturstrategie, Data-Science, Prozessautomatisierung, kundenspezifische Produktions-Software, Digital Twin Simulation, Applikations-Modernisierung & individuelle Software-Entwicklung.

  • Bestandsaufnahme
  • Best Practices
  • Anforderungsanalyse
  • Zielbild / Lösungskonzept
  • Ideen für Proof of Concept

#Cloudflight

Sharing Expertise - buchen Sie ihren kostenfreien Initial-Workshop!

Schreiben Sie uns

Schreiben Sie uns

Menü