Lange Zeit schien die Aufgabe der industriellen Peripherie recht einfach zu sein: Eine Maschine erzeugte Daten; ein Gateway sammelte diese, konvertierte Protokolle und leitete die Informationen an ein SCADA-System, eine Datenbank oder die Cloud weiter. Die weitergehende Verarbeitung erfolgte in der Regel an anderer Stelle.
Dieses Modell hat nach wie vor seine Berechtigung, beschreibt jedoch nicht mehr alles, was in der Nähe der Maschine geschieht. Industrielle Geräte können mittlerweile Visualisierungen ausführen, Daten lokal verarbeiten und Anwendungen unterstützen, für die früher separate Computer oder eine entfernte Infrastruktur erforderlich waren. Die relevante Konstruktionsfrage für einen Maschinenbauer ändert sich damit ebenfalls: Welche Funktionen müssen in der Nähe des Prozesses ausgeführt werden, und welche können an anderer Stelle ausgeführt werden?
Die Betrachtung des „Edge“ als Rechenebene hilft bei der Beantwortung dieser Frage. Sie bezieht Anforderungen an Konnektivität, Verarbeitung und Anwendungen von Anfang an in die Maschinenarchitektur ein und lässt gleichzeitig Raum dafür, dass verschiedene Geräte unterschiedliche Aufgaben übernehmen.
Der Begriff „Edge“ kann einen festen Punkt im System suggerieren. In der Praxis kann er jedoch ein kompaktes Gateway neben einer SPS, eine HMI, auf der zusätzliche Anwendungen laufen, oder einen Industrie-PC beschreiben, der Informationen von mehreren Automatisierungskomponenten verarbeitet. Diese Knoten können mit lokalen Servern und Cloud-Diensten zusammenarbeiten, wobei jeder die Aufgaben übernimmt, die seinen Fähigkeiten entsprechen.
LF Edge beschreibt ein Edge-Kontinuum, das sich von Feldgeräten bis hin zu zentralisierten Rechenzentren erstreckt. Seine Taxonomie betont die Kompromisse, die mit der Platzierung von Rechenressourcen entlang dieses Pfades verbunden sind, darunter Latenz, Bandbreite, Autonomie, Sicherheit und Datenschutz. Die Europäische Kommission beschreibt in ähnlicher Weise ein Cloud–Edge–IoT-Kontinuum und stellt fest, dass die Verarbeitung möglicherweise näher an den Ort der Datenerstellung verlagert werden muss, um Anforderungen hinsichtlich Latenz, Sicherheit und Datenschutz zu erfüllen.
Für OEMs ist dies sinnvoller als eine einfache Wahl zwischen lokaler Datenverarbeitung und der Cloud. Eine Bedienoberfläche muss möglicherweise auch dann noch nutzbar bleiben, wenn eine externe Verbindung ausfällt. Ein Flotten-Dashboard kann nützlicher sein, wenn Informationen von vielen Maschinen zusammengeführt werden. Eine Anwendung, die auf ein lokales Ereignis reagiert, stellt wiederum andere Anforderungen. Die Architektur sollte diese Unterschiede widerspiegeln.
Das herkömmliche Gateway war bislang eine effektive Brücke zwischen Protokollen und Systemen. Seine Kommunikationsfunktion bleibt unverzichtbar, insbesondere wenn eine Maschine Informationen mit Geräten unterschiedlicher Generationen oder Hersteller austauschen muss. Doch das Sammeln und Weiterleiten jedes Rohwerts ist nicht immer der beste Weg, um diese Informationen nutzbar zu machen.
Man stelle sich eine Maschine vor, die einen kontinuierlichen Messwertstrom erzeugt. Bevor diese Werte die Maschine verlassen, könnte eine Anwendung sie filtern oder aggregieren, Kontext hinzufügen, eine relevante Veränderung erkennen oder einem Bediener einen sofortigen Überblick verschaffen. Einige Informationen verbleiben möglicherweise vor Ort; ein kleinerer, aussagekräftigerer Datensatz wird möglicherweise an übergeordnete Systeme weitergeleitet. Dies ist eine architektonische Entscheidung darüber, welche Aufgaben in der Nähe des Prozesses ausgeführt werden sollten, und nicht nur eine Frage der Netzwerkkapazität.
Industrielle Normungsgremien befassen sich mit demselben Wandel. Im Juni 2026 stellte die OPC Foundation fest, dass die industrielle Digitalisierung „weit mehr als nur Protokollkonnektivität“ erfordert, und beschrieb Anforderungen an Gateways, zu denen eine sichere und semantische Integration über OT-, Unternehmens- und Cloud-Umgebungen hinweg gehört. Das bedeutet nicht, dass jedes Gateway jede Rechenaufgabe ausführen muss. Es bedeutet jedoch, dass der Zugriff auf Daten nur ein Teil davon ist, sie wiederverwendbar zu machen.
Ein Temperaturwert ist beispielsweise nützlicher, wenn eine andere Anwendung das Asset identifizieren kann, das ihn erzeugt hat, sowie dessen Einheiten und seine Beziehung zum Prozess. Die OPC Foundation bringt es auf den Punkt: „Industriedaten werden erst dann wirklich wiederverwendbar, wenn ihre Bedeutung mit ihnen mitwandert.“In ihrer Erörterung der OPC-UA-Informationsmodelle wird erläutert, wie gemeinsame Beschreibungen von Assets, Typen und Beziehungen diesen Kontext über Edge- und Cloud-Anwendungen hinweg bereitstellen können.
Da immer mehr Rechenleistung in der Nähe der Maschine zur Verfügung steht, kann ein Edge-Knoten Aufgaben übernehmen, die über die reine Kommunikation hinausgehen. Er könnte Visualisierungen, lokale Datenerfassung oder Analysen hosten und gleichzeitig eine Verbindung zu einer Remote-Plattform herstellen, um eine längerfristige Speicherung und Transparenz über den gesamten Maschinenpark hinweg zu gewährleisten. Ein leistungsfähigerer Industrie-PC kann Anwendungen unterstützen, die zusätzliche Rechenkapazität oder eine andere Betriebsumgebung benötigen.
Diese Möglichkeiten heben die Unterscheidungen zwischen Automatisierungsfunktionen nicht auf. Visualisierung, Analytik und deterministische Steuerung haben unterschiedliche Anforderungen an Timing und Verfügbarkeit. Sicherheitsrelevante Funktionen erfordern eine eigene technische Bewertung. Software-Updates, Cybersicherheit und Wartung müssen ebenfalls für jede in die Maschine integrierte Arbeitslast berücksichtigt werden.
Dies macht die Zuordnung von Arbeitslasten zu einer praktischen Disziplin der Konzeption. Welche Funktionen müssen auch ohne Internetverbindung weiterlaufen? Welche Daten sollten lokal verarbeitet oder gespeichert werden? Welche Anwendungen müssen isoliert werden? Welche Software wird sich während der Lebensdauer der Maschine am häufigsten ändern? Die Antworten auf diese Fragen sind wertvoller als die Entscheidung, zuerst eine Gerätekategorie auszuwählen und anschließend jede Funktion darin unterzubringen.
Die digitalen Anforderungen einer Maschine enden selten bereits bei der Inbetriebnahme. Zunächst steht vielleicht die Ferndiagnose im Vordergrund, gefolgt von einer umfassenderen Datenerfassung, Energieüberwachung oder der Integration in die Systeme des Kunden. Neue Software-Dienste können weitere Anforderungen mit sich bringen. Wenn jeder Schritt ein weiteres isoliertes Gerät sowie eigene Verbindungen, Updates und Konfigurationen erfordert, kann die Wartung der Gesamtarchitektur erschwert werden.
Die Planung des Edge als Rechenebene bedeutet nicht, jede Maschine für jeden möglichen zukünftigen Einsatz zu dimensionieren. Für eine Anwendung mag ein kompaktes Gateway ausreichen; eine andere benötigt möglicherweise eine dedizierte Steuerung neben einem leistungsfähigeren Edge-Computer. Entscheidend ist das Verständnis, wie Funktionen hinzugefügt werden können und wo sie ausgeführt werden können, ohne das gesamte System immer wieder neu aufbauen zu müssen.
Die richtige Architektur dürfte daher je nach Maschine variieren. Der nachhaltige Wandel liegt in der Methode: Man beginnt mit den betrieblichen und softwaretechnischen Workloads, bewertet deren Einschränkungen und wählt dann die Hardware und die Konnektivität aus, die diese unterstützen.
Das Portfolio von EXOR spiegelt diese verschiedenen Ebenen der Datenverarbeitung wider. MicroEdge Plus ist ein kompaktes Gateway und Edge-Controller mit industrieller Kommunikation über die Protokolle OPC UA, MQTT und JMobile. EXOR listet unter den Funktionen JMobile Web HMI, eine Linux/Yocto-Plattform sowie optionale CODESYS-SPS-Fähigkeiten auf. Es ist ein Beispiel dafür, wie Konnektivität und lokale Funktionen in einem kompakten Gerät koexistieren können.
Für Anwendungen mit höheren Rechenanforderungen bietet die Xedge-Serie Industrie-PC-Formate für das Datenmanagement und die industrielle IoT-Integration. JMobile sorgt für Visualisierung und industrielle Kommunikation über HMIs, Gateways und Edge-Geräte hinweg. EXOR beschreibt außerdem XPLC als Teil seines umfassenderen Software-Steuerungsangebots. Die genaue Kombination hängt von den Anforderungen der Maschine ab; diese Technologien stellen unterschiedliche Ressourcen innerhalb einer umfassenderen Architektur dar.
Für einen Maschinenbauer ist es entscheidend, bewusst entscheiden zu können, was lokal ausgeführt wird, welche Rechenebene dies unterstützt und wie diese Ebene mit dem Rest des Systems verbunden ist. Ein Gateway, eine HMI und ein IPC können unterschiedliche Arbeitslasten bewältigen, ohne als voneinander unabhängige technologische Inseln betrachtet zu werden.
Das industrielle Gateway spielt weiterhin eine wichtige Rolle. Seine Bedeutung nimmt zu, da Maschinendaten zunehmend in der Nähe ihrer Quelle verarbeitet und ausgewertet werden müssen. Gleichzeitig schaffen leistungsfähigere Plattformen Raum für lokale Anwendungen, die zuvor an anderer Stelle ausgeführt werden mussten.
Der industrielle Edge wird daher zunehmend zu einer Rechenebene und nicht mehr nur zu einer einzelnen Box im Schaltschrank. Für OEMs lautet die entscheidende Frage nicht mehr nur, wie eine Maschine vernetzt wird. Es geht vielmehr darum , was in ihrer Nähe geschehen muss, was an anderer Stelle geschehen kann und wie sich diese Entscheidungen im Zuge der Weiterentwicklung der Maschine bewähren werden.