Was ist Middleware?
Middleware ist die Software zwischen zwei Systemen, die nicht dieselbe Sprache sprechen. Sie nimmt Daten von Maschinen, Steuerungen und Sensorik entgegen, wandelt Protokoll und Format und übergibt sie an ERP, Datenbank oder Cloud — und denselben Weg zurück. Aus vielen Einzelverbindungen wird dadurch eine Stelle, an der Anbindungen konfiguriert statt programmiert werden.
Definition: Middleware
Middleware ist Software, die zwei getrennte Anwendungen miteinander verbindet. In der Produktion liegt sie zwischen der Feldebene — Maschinen, Steuerungen, Sensorik — und der IT-Ebene mit Datenbanken, ERP- und Cloud-Systemen. Sie übersetzt Protokolle, wandelt Datenformate und stellt damit aus vielen verschiedenen Systemen eine Struktur her, in der jedes mit jedem sprechen kann.
Die Verbindung läuft in beide Richtungen: Werte aus der Anlage gehen nach oben, Aufträge und Vorgaben kommen zurück an die Linie. Genau daran erkennt man den Unterschied zu einer reinen Datensammlung — eine Middleware liest nicht nur mit, sie schreibt auch.
Was auf beiden Seiten steht
Auf der Anlagenseite stehen Steuerungen, Sensorik, Barcode-Leser, Scanner und Etikettendrucker. Auf der IT-Seite stehen Server, Datenbanken, ERP- und MES-Systeme sowie Cloud-Dienste. Beide Seiten brauchen eine passende Schnittstelle, sonst bleibt die Verbindung Handarbeit: Ein Mensch liest einen Wert ab und tippt ihn an anderer Stelle wieder ein.
Ohne Middleware wächst die Zahl der Strecken mit jedem System. Mit Middleware bleibt es bei einer Anbindung je System.
Der Unterschied ist keine Frage der Ästhetik, sondern der Pflege. Drei Anlagen und drei IT-Systeme ergeben einzeln verbunden neun Strecken, die alle gebaut, getestet und bei jeder Änderung nachgezogen werden müssen. Über eine Middleware sind es sechs Anbindungen — je System eine, unabhängig davon, wer auf der anderen Seite steht.
Wie ein Datentransfer aufgebaut ist
Jedes System einer Landschaft wird über die Schnittstelle angebunden, die es ohnehin mitbringt. Die Middleware sorgt dafür, dass jede Seite die Daten in dem Format bekommt, das sie lesen kann — und hält dafür die Schnittstellenvielfalt vor, nicht Sie.
Ein Transfer hat immer dieselben vier Stationen — unabhängig davon, welche Systeme an den Enden stehen.
Quelle lesen
Ein Wert wird dort abgeholt, wo er entsteht: an der Steuerung, am Sensor, in einer Tabelle. Die Anlage wird dafür nicht verändert.
Auslöser bestimmen
Wann läuft der Transfer — im Takt, bei einer Wertänderung, auf ein Ereignis hin? Das entscheidet über Last und Aktualität.
Umformen
Protokoll und Format werden gewandelt, Felder zugeordnet, Werte gerechnet. Hier liegt die eigentliche Arbeit einer Middleware.
Ziel beschreiben
Das Zielsystem bekommt den Datensatz so, wie es ihn erwartet — und antwortet, wenn der Transfer in beide Richtungen läuft.
Der Weg funktioniert mit einem Kommunikationsstandard wie OPC UA, MQTT oder JSON ebenso wie ohne — dann übernimmt die Middleware die Übersetzung vollständig.
Middleware, API oder Protokoll
Die drei Begriffe werden oft durcheinandergeworfen, obwohl sie verschiedene Fragen beantworten.
| Begriff | Beantwortet | Was das im Projekt heißt |
|---|---|---|
| Protokoll | Nach welchen Regeln zwei Komponenten sprechen | Legt die Form fest, aber verbindet nichts von selbst. Eine Middleware bündelt viele Protokolle und ist dadurch beweglicher. |
| API | Wie ein Programm ein anderes anspricht | Bietet ähnliche Möglichkeiten, setzt aber Programmierkenntnisse voraus — jede Verbindung ist Entwicklungsarbeit. |
| Middleware | Wie zwei Systeme dauerhaft zusammenarbeiten | Mehr Schnittstellenvielfalt ohne verpflichtendes Programmieren; die Anbindung wird konfiguriert. |
Eine API ist kein schlechterer Weg — sie ist ein anderer. Wo eine einzige, dauerhaft stabile Verbindung genügt und Entwickler ohnehin am System arbeiten, ist sie die kürzere Strecke. Sobald es mehrere Systeme sind, die sich unabhängig voneinander ändern, verschiebt sich der Aufwand von der ersten Verbindung zur Pflege aller folgenden.
Was sich im Betrieb ändert
Die Quelle des Schwesterprodukts nennt sieben Punkte: Vernetzung, Digitalisierung, Automatisierung, Prozessoptimierung, Effizienzgewinn, Prozesssicherheit und weniger Komplexität. Nüchtern zusammengefasst sind es drei Wirkungen.
Erstens fällt Abtipparbeit weg. Werte, die heute jemand abliest und an anderer Stelle einträgt, laufen automatisch — und zwar auch nachts und in der Spätschicht. Zweitens sinkt die Fehlerquote, weil eine konfigurierte Übertragung nicht vertippt und nicht vergisst. Drittens sinkt die Zahl der Stellen, an denen jemand nachsehen muss, wenn etwas klemmt: eine Verbindung statt vieler Einzelwege.
Zwei Beispiele aus der Produktion
Auftragsdaten an die Steuerung
Ein Auftrag steht im ERP oder in einer Datenbank. Statt ihn an der Linie abzuschreiben, übergibt die Middleware die Daten nach einem festgelegten Kommunikationsstandard direkt an die Steuerung. Die Produktion startet früher, und der Auftrag an der Maschine ist derselbe wie der im System.
Alarmierung bei Grenzwerten
Maschinendaten werden laufend ausgewertet. Überschreitet ein Wert — etwa eine Temperatur — die festgelegte Grenze, geht sofort eine Meldung an die zuständige Person. Der Eingriff erfolgt vorbeugend, nicht erst nach dem Stillstand.
Wenn die Landschaft wächst
Eine Systemlandschaft wächst in zwei Richtungen. Horizontal, wenn weitere Systeme in die bestehende Landschaft kommen — eine zusätzliche Linie, ein zweites Lager, ein weiteres Werk. Vertikal, wenn mehr Rechenleistung nötig wird, etwa ein weiterer Server für steigende Datenmengen.
Wichtiger als beides ist, was beim Austausch passiert: Der Kern der Übertragung bleibt gleich, egal ob Komponenten hinzukommen oder ersetzt werden. Wird das ERP gewechselt, hängt daran nicht jede einzelne Maschinenanbindung — es ändert sich eine Seite der Verbindung, nicht die Verbindung selbst. Genau das macht eine Middleware zu einer Entscheidung mit langer Haltbarkeit.
Was eine Middleware mitbringen muss
Eine Middleware, die von einer Eigenheit der Umgebung abhängt, verlagert das Problem nur. Fünf Unabhängigkeiten entscheiden darüber, ob sie trägt:
- Vom Netz. Sie darf nicht voraussetzen, wie das Netz geschnitten ist, in dem sie läuft.
- Von den Protokollen. Welche Sprache zwei Komponenten sprechen, ist ihre Sache — nicht die der Middleware.
- Vom Betriebssystem. Server, virtuelle Maschine, Docker, Kubernetes: derselbe Transfer.
- Von der Programmiersprache. Sie muss zu dem passen, was in der Landschaft schon steht.
- Vom Anwender. Sie arbeitet im Hintergrund. Wer eine Auswertung öffnet, soll nicht merken, aus wie vielen Teilen sie stammt.
Woran man eine gute erkennt
Über die Unabhängigkeit hinaus gibt es fünf Punkte, die sich vor der Auswahl prüfen lassen — und die später teuer werden, wenn man sie übergeht:
- Sicherheit. Wo Produktions- und Kundendaten laufen, gehört der Zugriff geregelt und der Weg verschlüsselt.
- Skalierbarkeit. Ein System mehr auf der OT- oder IT-Seite darf kein Projekt sein, sondern eine Konfiguration.
- Anbindungsvielfalt. Je mehr Protokolle und Systeme abgedeckt sind, desto seltener wird ein Sonderweg nötig.
- Weiterentwicklung und Support. Die Landschaft ändert sich; die Software muss mitgehen, und jemand muss erreichbar sein.
- Programmieraufwand. Wer keine Entwicklungsabteilung hat, braucht eine Oberfläche statt einer Schnittstellenbeschreibung.
Umsetzung mit connubes
connubes ist eine solche Middleware. Anbindungen werden per Drag & Drop konfiguriert statt programmiert; die Erweiterungen dafür heißen Plug-ins, Add-ons und ETL-Werkzeuge. Die Serverlizenz gilt unabhängig davon, wie viele Clients, Datenpunkte oder Verbindungen darüber laufen — der Baukasten wächst also mit, ohne dass die Kostenrechnung bei jedem neuen System neu aufgemacht werden muss.
Welche Systeme sich heute anbinden lassen, steht auf der Plug-in-Übersicht. Was die Plattform im Alltag verändert, zeigen die Anwendungsfälle.
Begriffe kurz erklärt
- OT — Operational Technology
- Die Technik, die produziert: Steuerungen, Sensorik, Antriebe, Prüf- und Kennzeichnungsgeräte.
- IT — Information Technology
- Die Technik, die verwaltet: Server, Datenbanken, ERP- und MES-Systeme, Cloud-Dienste.
- SPS
- Speicherprogrammierbare Steuerung — der Rechner, der die Maschine führt.
- Protokoll
- Der Satz Regeln, nach dem zwei Komponenten Daten austauschen, etwa OPC UA oder MQTT.
- API
- Eine programmierbare Schnittstelle einer Anwendung. Leistungsfähig, setzt aber Entwicklungsarbeit voraus.
- ETL
- Extract, Transform, Load — Werte herausziehen, umformen und in der Form weitergeben, die das Zielsystem erwartet.
Häufige Fragen
Was macht eine Middleware in der Produktion?
Sie verbindet Maschinen, Steuerungen und Sensorik mit ERP-, Datenbank- und Cloud-Systemen: Sie übersetzt Protokolle, wandelt Datenformate und überträgt Werte in beide Richtungen — von der Anlage in die IT und zurück an die Linie.
Worin unterscheidet sich Middleware von einer API?
Eine API bietet ähnliche Vernetzungsmöglichkeiten, setzt aber Programmierkenntnisse voraus. Eine Middleware bringt mehr Schnittstellenvielfalt mit und wird konfiguriert statt programmiert.
Ist ein Protokoll wie OPC UA nicht schon eine Middleware?
Nein. Ein Protokoll legt die Regeln fest, nach denen zwei Komponenten sprechen. Eine Middleware bündelt viele Protokolle und entscheidet zusätzlich, welche Daten wann und wohin übertragen werden.
Muss ich für eine Middleware programmieren können?
Nein. Die Anbindungen werden konfiguriert; bei connubes per Drag & Drop. Für Fälle, die kein Standard abdeckt, gibt es zusätzlich ein Script-Plug-in.
Was passiert, wenn wir später ein System austauschen?
Der Kern der Übertragung bleibt gleich. Es ändert sich eine Seite der Verbindung, nicht die Verbindung selbst — die übrigen Anbindungen laufen weiter.
IT/OT-IntegrationWarum die Verbindung beider Welten an fünf Stellen klemmt — und woran es liegt.Weiterlesen 
Schnittstellen und Plug-insÜber 50 Anbindungen, von OPC UA über SAP bis zum Etikettendrucker.Weiterlesen 
Cloud & ProductionWie Produktionsdaten in die Cloud kommen — und was von dort zurückfließt.Weiterlesen