Was ist SCADA? Aufbau, Abgrenzung zu HMI, MES und DCS

Die vier Buchstaben stehen für Supervisory Control and Data Acquisition, sinngemäß überwachendes Steuern und Datenerfassung. Der Name beschreibt die Aufgabenteilung genau: Ein SCADA steuert nicht selbst im Millisekundentakt, das tun die Steuerungen. Es beaufsichtigt sie, sammelt ihre Werte und erlaubt einen Eingriff dort, wo ein Mensch entscheiden muss.

Ein typisches System besteht aus drei Teilen. Ein SCADA-Server hält die Datenhaltung, die Alarmlogik und die Historie. Bedienstationen zeigen die Anlage und nehmen Eingaben entgegen. Dazwischen liegen Kommunikationstreiber zu den Steuerungen, etwa über Feldbusse oder über OPC UA.

Nicht jede Feldstelle ist eine SPS. In weit verteilten Anlagen, etwa in der Wasserversorgung oder in Energienetzen, sitzen an den entfernten Stationen Remote Terminal Units (RTU): Sie erfassen die Werte, melden sie an das SCADA und führen seine Befehle aus, häufig über Fernwirkprotokolle wie IEC 60870-5-104 oder DNP3.

Was ein SCADA fachlich leistet und in welchen Branchen es eingesetzt wird, behandelt Was ist ein SCADA-System auf manubes. Hier geht es um die Abgrenzung und die Anbindung.

SCADA sitzt auf der Prozessleitebene der Automatisierungspyramide. Unter ihm liegen die Steuerungen, über ihm das MES. Welche Levelzahl gilt, hängt vom Modell ab: ISA führt SCADA in seiner ISA-95-Beschreibung unter Level 3, verbreitete Purdue-Darstellungen unter Level 2.

Diese Ordnung beschreibt Zuständigkeiten. Den Datenwegen gibt sie in der Praxis keine Richtung mehr vor: Ein ERP kann auch direkt mit dieser Ebene sprechen. Dort liegen die Werte bereits gesammelt vor, und das ERP erhält den Stand der Anlage von jetzt statt den von gestern Nacht.

Mehr dazu: Was ist ISA-95? Fünf Ebenen, IEC 62264 und die Automatisierungspyramide

Ein HMI ist die Bedienoberfläche einer Maschine oder eines Bereichs. Ein SCADA ist das System, das viele davon zusammenführt.

Praktisch heißt das: Das HMI am Extruder zeigt den Extruder. Das SCADA zeigt alle Extruder, ihre Alarme, ihre Historie und erlaubt den Vergleich. Ein HMI kann Teil eines SCADA sein.

Der Unterschied verschwimmt bei Web-HMIs, die von mehreren Stellen erreichbar sind, und er verschwimmt noch mehr, seit Panels selbst Netzwerkteilnehmer sind und eigene Historien führen können. Die brauchbare Trennlinie ist deshalb der Umfang: Bedient eine Oberfläche eine Anlage, oder überwacht sie einen Anlagenverbund und erlaubt den Vergleich zwischen seinen Teilen? Steht in einer Ausschreibung, ein System sei HMI und SCADA zugleich, ist damit noch wenig gesagt. Die nützliche Rückfrage lautet, wie viele Anlagen es gleichzeitig zeigt und ob es deren Werte gegeneinander stellen kann.

Mehr dazu: Was ist ein HMI? Bedienebene, Web-HMI und Anbindung an die IT

Beide sammeln Produktionsdaten, aber sie beantworten verschiedene Fragen.

Der Unterschied liegt im Auftragsbezug.

Ein SCADA zeigt, dass Ofen 3 auf 180 Grad läuft. Ein MES ordnet diese 180 Grad der Charge 4711 zu und damit der Qualitätsakte.

In der Praxis überlappen sich beide, und viele SCADA-Systeme haben MES-Funktionen dazubekommen. Die Zuordnung bleibt trotzdem nützlich: Sie legt fest, welches System bei einem Widerspruch zwischen zwei Zahlen maßgeblich ist.

Ein DCS (Distributed Control System, deutsch Prozessleitsystem) ist historisch für die kontinuierliche Prozessindustrie gebaut: Chemie, Raffinerie, Papier, Pharma. Die Regelung ist dort Teil des Systems, nicht der einzelnen Steuerung, und Verfügbarkeit ist die oberste Anforderung.

Ein SCADA kommt aus der verteilten Überwachung: Wasserversorgung, Energienetze, Fertigung mit vielen Einzelmaschinen. Die Steuerung bleibt bei den Anlagen, das SCADA überwacht sie und erlaubt den Eingriff.

Die Grenze verschwimmt seit Jahren, und in Ausschreibungen werden beide Begriffe teils synonym benutzt. Als Tendenz gilt: Ein DCS ist eher ein geschlossenes System, mit herstellerspezifischen Schnittstellen und einer Freigabepraxis, die Änderungen bewusst erschwert. Ein SCADA ist eher offen, spricht häufiger Standardprotokolle und lässt sich schneller erweitern. Für das einzelne Produkt ist das keine verlässliche Auskunft, denn es gibt auch Leitsysteme mit OPC-Schnittstelle und geschlossene SCADA-Systeme. Vor einer Anbindung ist deshalb zu klären, welche Schnittstellen das installierte System in seiner Version anbietet und ob sie freigeschaltet sind. Davon hängt ab, ob der Weg über eine dokumentierte Schnittstelle führt oder über eine Freigabe beim Hersteller.

Mehr dazu: Was ist ein Prozessleitsystem (DCS)?

Dabei sind zwei Richtungen zu unterscheiden, und sie sind technisch verschieden.

Erste Richtung: Das SCADA liest. Es holt sich Werte von den Steuerungen, über Treiber für deren eigene Protokolle oder über OPC UA. Eine Middleware kann dabei selbst als OPC-UA-Server auftreten und dem SCADA Daten anbieten, die gar nicht aus einer Steuerung kommen: Werte aus einer Datenbank, aus einem ERP, aus einem Webdienst. Das SCADA behandelt diese Quelle wie eine weitere Steuerung.

Auf diesem Weg lässt sich auch der Zustand einer Verbindung selbst bereitstellen. Das SCADA zeigt dann neben den Anlagenwerten auch, ob die Strecke zum ERP steht. Ein Alarm auf einer abgerissenen Schnittstelle erscheint so in der Leitwarte und nicht nur in einem Serverprotokoll.

Ein SCADA lässt sich so auch beliefern, statt nur abgefragt zu werden. Laut der Anwenderübersicht auf opc-router.de (Stand der Seite: Juli 2026) versorgte ein brasilianisches Bergbauunternehmen seine SCADA-Software an fünf Standorten auf diesem Weg: KEPServerEX las die Allen-Bradley-Steuerungen und gab die Werte über OPC UA an den OPC Router weiter, dort wurden sie per Skript zu JSON-Objekten umgeformt und über REST an das SCADA geschickt.

Zweite Richtung: Aus dem SCADA heraus. Werte sollen in eine Datenbank, ein MES, ein ERP oder eine Cloud. Dafür liest eine Middleware die SCADA-Daten und schreibt sie weiter. Welche Wege ein SCADA dafür öffnet, hängt vom Produkt ab: etwa ein eigener OPC-Server (OPC UA oder klassisch OPC DA), die Datenbank seines Archivs oder eine REST- oder MQTT-Schnittstelle. Der OPC Router kann jeden dieser Wege mit dem passenden Plug-in ansprechen; Historien aus einem OPC-UA-Server liest er über Historical Access.

Der Gewinn kann dabei auch in der Entkopplung liegen. Laut derselben Anwenderübersicht sammelte ein spanischer Hersteller von Molkereiprodukten Werte von einem OPC-Server, verwaltete darüber seine Redundanz und versorgte damit seine PI-Systeme, also eine Historian-Datenbank. Als Nutzen nennt die Anwenderübersicht, dass das Unternehmen seine Datenanalysesysteme verbessern oder wechseln könne, ohne die Art der Datenextraktion aus dem Prozess zu ändern.

Eine solche Anbindungsschicht kann Systeme verschiedener Art und verschiedener Hersteller zusammenführen. Laut dem Anwenderbericht zu ZewaTec auf opc-router.de (Stand der Seite: Januar 2025) verband der Systemintegrator ZewaTec bei einem Hersteller von Wachstechnologien das SAP-System mit zwei Siemens-Systemen und einem Yokogawa-Leitsystem. Die erste Lösung bestand aus vielen Teillösungen mit rund 20.000 Zeilen Code. Nach der Umstellung auf den OPC Router ersetzten dessen grafische Verbindungen laut dem Bericht über 90 Prozent dieser Programmierung.

Ein zweiter Fall koppelt ein Leitsystem mit einem Prüfsystem. Laut der Anwenderübersicht betrieb ein Papierhersteller in der Türkei sein Qualitätskontrollsystem und sein DCS auf zwei getrennten Servern, das eine für die Papierwerte, das andere für Prozessgrößen wie Bahngeschwindigkeit und Temperatur. Beide brachten einen OPC-DA-Server mit, Kepware übersetzte nach OPC UA. Eine OPC-Router-Instanz verband die Tags zwischen Qualitätssystem und DCS, eine zweite sammelte auf einem dritten Server alles ein und schrieb es in eine SQL-Datenbank. Die täglichen, wöchentlichen und monatlichen Berichte erstellte auf diesem dritten Server ein zweites inray-Produkt, der Factory Application Server (FAS).

SCADA und Auswertung lesen dieselbe Anlage und kommen trotzdem zu verschiedenen Ergebnissen. Das kann geschehen, ohne dass eine der beiden Seiten falsch konfiguriert wäre: Die Abweichung folgt dann aus der Bauart der Anbindung. Dazu kommt der Ausfall eines Zielsystems, der nur dann dauerhaft Spuren hinterlässt, wenn vorher nicht festgelegt wurde, was während des Ausfalls geschehen soll.

Eine wertgesteuerte Anbindung meldet Stände, keine Ereignisse

Der Trend im SCADA zeigt eine Spitze, einen Umschaltvorgang, einen Zählerschritt. In der Datenbank fehlt er. Beide Reihen stammen aus derselben Quelle, keine meldet einen Fehler, und beide sind formal korrekt.

Die Ursache: Eine wertgesteuerte Anbindung, die je Lesezyklus nur den letzten Stand erhält, reagiert auf die Änderungsmeldungen, die sie bekommt, und nicht unmittelbar auf Änderungen in der Anlage. Eine solche Meldung beschreibt den Stand am Ende eines Lesezyklus. Ändert sich ein Datenpunkt innerhalb eines Zyklus zweimal, hat der Zwischenwert für den Leser nie existiert. Es gibt weder eine Quittung noch eine Lückenmeldung, also zeigt keine der beiden Seiten an, dass etwas fehlt.

Das Verhalten ist dokumentiert. Das OPC-Router-Handbuch schreibt zum Data-Change-Trigger: „Ändert sich der Datenpunkt innerhalb eines Lesezyklus mehrfach, sieht der OPC Router nur den letzten Stand – die Zwischenwerte gehen ohne Meldung verloren.“

Woran es sich zeigt: Nur im Vergleich, etwa ein Zählerstand aus der Anlage gegen die Summe der einzeln übertragenen Ereignisse. Wo Vollständigkeit zählt, gehört deshalb ein Zähler dazu.

Was beim Betrieb liegt. Der Zähler gehört in die Steuerung, und keine Middleware holt das nach: Ein Ereignis, das die SPS nicht nummeriert, hat für jede nachgelagerte Auswertung nie stattgefunden. Drei Dinge gehören ins SPS-Programm. Erstens der Zähler selbst, der bei neuen Daten um eins erhöht wird. Zweitens die Reihenfolge, also zuerst alle zusammengehörenden Werte schreiben und den Zähler zuletzt setzen. Drittens ein Timeout für die ausbleibende Quittung. Der dritte Punkt fällt leicht unter den Tisch, weil sein Fehlen keine Meldung erzeugt: Ein Transfer, der nicht ausgelöst hat, bleibt schlicht aus. Die Lückensuche in der Zählerspalte ist danach eine Auswertung im Zielsystem.

Im OPC Router. Wo kein Datensatz verloren gehen darf, ist eine wertgesteuerte Anbindung die falsche Wahl. Der OPC Router bietet dafür den Message- und den Bit-Trigger an. Beim Message-Trigger zählt die Steuerung jeden Datensatz hoch, und laut Handbuch erzeugt jede Zähleränderung genau einen Transfer. Der Bit-Trigger löst auf ein gesetztes Bit aus. Folgen mehrere Ereignisse aufeinander, empfiehlt das Handbuch den Message-Trigger, weil er auf einem Änderungszähler beruht. Bei beiden kann der Router über einen Antwort-Datenpunkt quittieren; ist das eingeschaltet, erkennt die Steuerung an einer ausbleibenden Quittung, dass sie wiederholen muss. Vor dem Lesen wartet der Router einen zusätzlichen Zyklus ab, damit die Steuerung alle zusammengehörenden Werte schreiben konnte. Außerdem kann er ein Fehlerbit in der Steuerung setzen, wenn ein Transfer fehlschlägt. Der Zählerwert des Message-Triggers lässt sich als Feld mitschreiben. Damit ist im Zielsystem nachprüfbar, ob ein Datensatz fehlt oder doppelt angekommen ist. Für den Neustart gibt es die Option „Beim Start auslösen“, die in einer ihrer Stellungen den Datensatz nachholt, dessen Message- und Antwort-ID beim Neustart auseinanderliefen.

Trend und Datenbank lösen nach verschiedenen Regeln aus

Zwei Reihen derselben Größe über denselben Zeitraum, und sie haben nicht einmal gleich viele Punkte. Der Mittelwert weicht ab, obwohl beide Seiten dieselbe Quelle lesen.

Die Ursache: Ein Trend im SCADA zeichnet häufig zeitgesteuert auf, also in einem festen Raster; manche Archive zeichnen auch bei Änderung mit Totband auf. Eine Datenbankanbindung läuft oft wertgesteuert, also nur bei Änderung. Beides ist korrekt und beschreibt dieselbe Anlage. Aber ein Mittelwert über eine wertgesteuerte Reihe gewichtet nach der Anzahl der Änderungen, nicht nach der Zeit. Eine Größe, die eine Stunde ruhig steht und dann fünf Minuten springt, sieht in den beiden Reihen systematisch verschieden aus.

Woran es sich zeigt: Die Reihen unterscheiden sich in der Punktzahl, bevor sie sich im Wert unterscheiden. Zählen ist deshalb der schnellere Prüfgriff als mitteln.

Was beim Betrieb liegt. Welche Logik gilt, ist eine Entwurfsentscheidung über die Auswertung, und sie muss auf beiden Seiten dieselbe sein. Die SCADA-Seite stellt niemand in einer Middleware ein. Dazu kommen zwei Dinge im Zielsystem: Es muss den mitgelieferten Zeitstempel verwenden statt seines eigenen Eingangszeitpunkts, und der Zeithorizont muss zusammenpassen. Ein Trend im Fünf-Sekunden-Raster und eine Datenbankreihe im Minutenraster sind auch bei gleicher Auslöselogik nicht vergleichbar.

Im OPC Router. Er unterstützt beide Logiken. Zeitgesteuert löst der Cron-Trigger zu Terminen aus, die ein Cron-Ausdruck beschreibt, bis hinunter zur Sekunde und hinauf zu Wochentag, Monat und Jahr. Wertgesteuert löst der Data-Change-Trigger aus. Beides lässt sich kombinieren: Der Data-Change-Trigger kann zusätzlich spätestens nach einem eingestellten Intervall auslösen, auch wenn sich der Wert nicht geändert hat, und macht so aus einer Treppe eine Reihe mit mindestens einer Stützstelle je Intervall. Umgekehrt lässt sich begrenzen, wie oft er auslöst. Das senkt die Last und gibt dafür Zwischenwerte auf: Am Ende der Sperrzeit wird der zuletzt gemeldete Wert nachgeliefert, mit dem Zeitstempel seiner Messung und nicht dem der Übertragung.

Der Time-Trigger ergibt trotz seines Namens kein festes Raster. Laut Handbuch berechnet der Router das Intervall ab dem Ende des letzten Transfers: Bei der Einstellung 1 s wird nicht sekündlich übertragen, sondern jeweils 1 Sekunde nach dem vorherigen Transfer. Für zwei deckungsgleiche Reihen ist deshalb der Cron-Trigger die passende Wahl.

Ein aggregierter Historienwert ist eine Rechnung, keine Messung

Derselbe Bericht über denselben Zeitraum, zweimal gezogen, liefert zwei verschiedene Zahlen. Oder die Kurve hat keine Lücke, obwohl die Anlage nachweislich stand.

Die Ursache hat zwei voneinander unabhängige Teile. Erstens darf ein Historian seinen Bestand nachträglich korrigieren. Ein gewöhnlicher Lesezugriff liefert den heutigen Stand, nach einer Korrektur also den korrigierten Wert. Die ersetzten Fassungen gibt der Server nur auf gesonderte Anforderung heraus. Zweitens wird ein Mittelwert, ein Minimum oder ein Maximum über ein Intervall vom Server berechnet, und je nach Aggregat gehört Interpolation über fehlende Werte zum Verfahren. Die glatte Kurve über den Stillstand hinweg ist dann das vereinbarte Ergebnis.

Woran es sich zeigt: Ein Bericht, der sich beim Nachziehen ändert. Ein Aggregat, das über einen Stillstand hinweg unauffällig verläuft. Der Prüfgriff ist, dieselbe Abfrage einmal roh und einmal aggregiert zu stellen.

Was beim Betrieb liegt. Zuerst muss der Server Historical Access überhaupt unterstützen. Das Handbuch schreibt, das Lesen der Historie sei „nur für OPC UA-Server verfügbar, die die OPC-UA-Spezifikation Historical Access unterstützen“. Ein SCADA, das seine Trends nur intern hält, ist auf diesem Weg nicht lesbar. Ist der Weg da, gehört die Rechnung immer noch dem Server. Deshalb lohnt der Blick auf die Option „Use Server Capabilities Defaults“: Ist sie aktiv, gelten die Vorgaben des Servers, und die eigenen Einstellungen zu Extrapolation und Qualitätsanteil wirken nicht. Welche Aggregation für einen Bericht gilt, bleibt eine Entwurfsentscheidung, die vor dem ersten Bericht fällt.

Im OPC Router. Er liest Historiendaten über OPC UA Historical Access in zwei Modi: roh, also die einzeln gespeicherten Werte, oder verarbeitet, also über Intervalle zusammengefasst. Ob dabei auch die Änderungen an Historienwerten gelesen werden, ist im Rohmodus einstellbar. Im verarbeiteten Modus rechnet der OPC-UA-Server, und ob er über eine Lücke zwischen zwei Werten interpoliert, hängt am gewählten Aggregat. Die Einstellung zur Extrapolation betrifft nur die Fortschreibung über den letzten vorhandenen Wert hinaus. Ein akzeptierter Anteil schlechter und ein erforderlicher Anteil guter Werte, jeweils in Prozent, legen fest, wie das Ergebnis eines Intervalls mit schlechten Werten gekennzeichnet wird, sofern nicht die Vorgaben des Servers gelten.

Der Prüfgriff von oben lässt sich damit ohne Sonderentwicklung projektieren: Roh und verarbeitet sind zwei Lesemodi desselben Transferobjekts, also zwei Flows. Der Zeitstempel des Servers und der des OPC Router lassen sich getrennt ausgeben, damit Mess- und Abholzeitpunkt unterscheidbar bleiben.

Aus der Praxis: Laut der Anwenderübersicht auf opc-router.de (Stand der Seite: Juli 2026) hat ein japanischer Hersteller von Dämmstoffen den Historian seines DCS durch eine InfluxDB ersetzt; der OPC Router übertrug dorthin alle paar Sekunden über 10.000 Datenpunkte. Die Zahl zeigt die Größenordnung der Last, wenn eine Historie aus dem Leitsystem herausgelöst wird.

Werte mit schlechter Qualität werden verworfen, und die Lücke sieht nicht aus wie eine

Die Anlage hatte eine Störung. Im SCADA steht sie als Alarm und als flache Linie. In der Datenbank steht für diesen Zeitraum gar nichts, und der Schichtmittelwert lässt die Schicht besser aussehen, als sie war, weil die schlechte Phase nicht enthalten ist.

Die Ursache: Über OPC trägt jeder Wert neben Zahl und Zeitstempel eine Qualität. Eine Anbindung filtert darauf, und was sie nicht akzeptiert, wird verworfen, statt als ungültig gekennzeichnet weiterzugehen. Von sich aus überlebt die Qualität die Grenze zum Zielsystem ohnehin nicht: Ein gewöhnliches Zielschema hat nur eine Spalte für die Zahl, solange niemand eine zweite anlegt. Also bleibt am Ende eine Lücke, und eine Lücke ist von „es lief nichts“ nicht zu unterscheiden.

Woran es sich zeigt: Die Störungsphase fehlt in der Auswertung vollständig, statt als schlechte Werte darin zu stehen.

Was beim Betrieb liegt. Die Abwägung selbst gehört dem Betreiber. Nur „Good“ durchzulassen ist eine legitime Wahl, sie erzeugt aber die Lücke von oben; alle Zustände durchzulassen bringt Werte in die Auswertung, die nicht belastbar sind. Zwei Dinge werden dabei leicht übersehen. Erstens sitzt die Einstellung an der Anbindung und nicht am einzelnen Flow; braucht ein Berichtsflow andere Qualitäten als ein Steuerungsflow, ist eine zweite Anbindung nötig. Zweitens muss das Zielsystem eine Spalte für die Qualität haben, und die Auswertung muss sie benutzen. Ein mitgeschriebener, aber nicht ausgewerteter Qualitätscode ändert am falschen Schichtmittelwert nichts. Und ein sauber gekennzeichneter schlechter Wert bleibt ein Befund über eine Störung, er wird dadurch kein Messwert.

Im OPC Router. Ob ein Wert mit eingeschränkter oder schlechter Qualität überhaupt verarbeitet wird, legt die OPC-Anbindung im Feld „Erlaubte Qualities“ fest, von nur „Good“ bis zu allen Zuständen. Lässt man auch schlechte Qualitäten zu, kann der OPC Router die Qualität im Flow als eigenes Feld mitgeben, als Zahl oder als Klartext. Bei klassischen OPC-Datenpunkten steht dann etwa die 192 für „good“ in der Spalte. Statt einer Lücke steht in der Zieltabelle ein Wert mit dem Vermerk, warum ihm nicht zu trauen ist. Voraussetzung bleibt, dass das Zielsystem ein Feld dafür hat und die Auswertung es berücksichtigt.

Zwei weitere Stellschrauben zielen direkt auf die stille Lücke. Sind schlechte Qualitäten in der Anbindung zugelassen, kann der Data-Change-Trigger zusätzlich auf eine Qualitätsänderung auslösen; damit wird aus dem Übergang gut zu schlecht zu gut eine Folge datierter Zeilen. Und der Data-Change-Missing-Trigger löst aus, wenn sich ein Datenpunkt innerhalb eines Prüfzeitraums nicht ändert, auf Wunsch samt den Metadaten des zuletzt bekannten Werts.

Die Lücke kann vom Zielsystem stammen

In der Datenbank fehlt eine Stunde. Die Anlage lief, die Werte waren gut, die Anbindung meldet keinen Fehler mehr. Was fehlte, war die Gegenstelle: ein Wartungsfenster, ein Neustart, eine Netzstrecke.

Die Ursache: Eine Anbindung ohne Zwischenspeicher überträgt in dem Moment, in dem sie ausgelöst wird. Ist die Gegenstelle nicht erreichbar, hat der Vorgang keinen Ort, an dem er warten könnte. Danach läuft alles weiter, und es bleibt keine Spur davon.

Woran es sich zeigt: Diese Lücke hat scharfe Ränder und deckt sich mit einem Ereignis im Zielsystem, nicht mit einem Ereignis in der Anlage. Legt man Wartungsfenster und Fehlzeiten nebeneinander, wird der Zusammenhang sichtbar.

Was beim Betrieb liegt. Erstens muss Store and Forward an zwei Stellen eingeschaltet sein, global und zusätzlich in jedem Flow, der puffern soll; nur global eingeschaltet puffert es nichts. Zweitens gehört die Entscheidung pro Flow getroffen, denn nicht für jeden Wert ist Nachliefern sinnvoll. Drittens muss jeder Datensatz einen eigenen Wert- oder Aufzeichnungszeitstempel mitführen, weil die Reihenfolge beim Nachliefern nicht garantiert ist; das ist eine Entscheidung über das Datenmodell im Zielsystem. Viertens müssen Vorhaltezeit und Speicherkapazität dimensioniert werden, denn nach Ablauf der Vorhaltezeit werden zu alte Werte verworfen.

Im OPC Router. Fällt ein Zielsystem zeitweise aus, kann der OPC Router die betroffenen Transfers zwischenspeichern und nachreichen, sobald die Übertragung wieder möglich ist. Vorhaltezeit, Speicherkapazität und das Verhalten bei voller Kapazität sind einstellbar, und der Status jedes zwischengespeicherten Datensatzes ist im Statusbaum sichtbar.

Dazu gehören vier Einschränkungen. Store and Forward steht in der Regel an den Transferobjekten am Ende eines Flows zur Verfügung; ob es an einem bestimmten greift, zeigt nach dem Einschalten das Store-and-Forward-Symbol. Die nachgereichten Werte kommen nicht zwingend in ihrer ursprünglichen Reihenfolge an. Schlägt das Nachreichen fehl, wird es nach einigen Versuchen nicht weiter ausgeführt; laut Handbuch betrifft das in der Regel ungültige Datensätze. Und für Werte, bei denen nur der aktuelle Zustand zählt, rät der Hersteller ausdrücklich davon ab, weil sonst veraltete Werte verspätet geschrieben werden. Für ein Visualisierungs-Tag im SCADA ist Store and Forward also die falsche Wahl, für eine Chargenmeldung die richtige.

Zwei Fälle löst Store and Forward nicht: Ein wegen schlechter Qualität verworfener Wert ist kein Fehler im Zielsystem und landet nicht im Puffer, und ein Zwischenwert, der den Router nie erreicht hat, lässt sich auch nicht zwischenspeichern. Store and Forward ist zudem ein Add-on. Ob es in der vorhandenen Lizenz enthalten ist, klärt man vor der Planung.

Nein, sie verschiebt seine Aufgaben. Das Bedienen und Eingreifen bleibt vor Ort, weil es auch funktionieren muss, wenn die Internetverbindung ausfällt. Was in die Cloud wandert, ist die Auswertung über Anlagen und Standorte hinweg: Kennzahlen, Vergleiche, Berichte.

Daraus ergibt sich eine Schichtung. Steuerungen und SCADA bleiben, wo sie sind. Eine Anbindungsschicht bringt die Werte nach oben. Darüber liegt eine Plattform, die auswertet, ohne selbst zu steuern. Diese Rolle übernimmt manubes.

Wie das in einem gewachsenen Werk aussehen kann, zeigt ein Fall aus Japan. Laut der Anwenderübersicht auf opc-router.de (Stand der Seite: Juli 2026) vermittelte der OPC Router bei einem Hersteller von Kohlenstoffmaterialien zwischen Mitsubishi-Steuerungen, Stromzählern, MySQL, Excel, einem GE-SCADA, einem Historian und einer IoT-Plattform, an die er über REST lieferte. Einsehen ließ sich der Anlagenstatus per Webbrowser und auf Geräten im eigenen VPN-Netz: Produktionsdaten, Energieverbrauch und Bedarf, Steuerungsdaten, Alarme und Ereignisse, historische Daten und Trends. Das GE-SCADA blieb dabei eines von mehreren Systemen, zwischen denen der OPC Router vermittelte.

Mehr dazu: Was ist ein MES? Aufgaben, Abgrenzung zum ERP und die Schnittstellen · Was ist OPC UA?