Was ist ein Prozessleitsystem (DCS)? Aufbau, Abgrenzung zu SCADA und der Weg in die IT

Die drei Buchstaben stehen für Distributed Control System, wörtlich ein verteiltes Steuerungssystem. Verteilt ist dabei die Rechenleistung: Die Regelung läuft auf mehreren Controllern nahe am Prozess, die Bedienung in einer zentralen Leitwarte. Beides ist als ein System angelegt, typischerweise als integrierte Systemfamilie mit gemeinsamer Engineering-Umgebung aus der Hand eines Herstellers. Bei hybriden und migrierten Anlagen weicht das ab, etwa wenn Fremdgeräte angebunden oder Teile eines älteren Systems weiterbetrieben werden. Im deutschen Sprachgebrauch heißt das Prozessleitsystem, abgekürzt PLS. Im Englischen heißt es neben DCS auch Process Control System (PCS).

Ein typisches Prozessleitsystem besteht aus vier Teilen. Die Controller, in der deutschen Fachliteratur den prozessnahen Komponenten (PNK) zugerechnet, führen die Regelkreise aus, also Druck, Temperatur, Durchfluss und Füllstand. Die Bedienstationen in der Leitwarte zeigen den Prozess und nehmen Sollwerte, Freigaben und Quittierungen entgegen. Ein Engineering-System hält die Konfiguration: Regelkreise, Bilder, Alarme, Rezepte. Und meist gehört ein Historian dazu, der die Messwerte über Monate und Jahre speichert.

Unterhalb der Controller liegen die Feldgeräte: Sensoren liefern die Messwerte, Aktoren wie Regelventile setzen die Stellbefehle um. Sie hängen über Ein-/Ausgabe-Module (E/A) oder einen Feldbus an den Controllern.

In der Automatisierungspyramide spannt ein Prozessleitsystem über Steuerungs- und Prozessleitebene: seine Controller auf der Steuerungsebene, auf der sonst die SPS sitzt, Leitwarte und Bedienstationen auf der Prozessleitebene, neben SCADA und HMI. In seiner Beschreibung von ISA-95 führt ISA das Prozessleitsystem als Ganzes unter Level 2. Die beiden Modelle zählen ihre Ebenen verschieden, deshalb steht hier jede Einordnung mit dem Modell, zu dem sie gehört.

Eine SPS steuert eine Maschine oder eine Linie. Ein Prozessleitsystem regelt einen Prozess, der sich über eine Produktionsanlage oder einen großen Teil davon erstreckt. Beide führen ihre Logik auf Controllern nahe am Prozess aus. Der Unterschied zu einer Sammlung einzelner Steuerungen liegt in der Einheit des Systems: Ein Regelkreis, ein Bedienbild und ein Alarm werden an einer Stelle angelegt und gelten im ganzen System. Das macht ein Prozessleitsystem konsistent, aber auch zu einem System, das man nicht nebenbei verändert.

Die beiden kommen aus verschiedenen Aufgaben. Die SPS hat die verbindungsprogrammierte Steuerung abgelöst, bei der die Logik in der Verdrahtung lag, und steuert Maschinen und Fertigungslinien. Das Prozessleitsystem kommt aus der Prozessindustrie, in der viele voneinander abhängige Regelkreise aus einer Leitwarte geführt werden.

Die Grenze ist nicht scharf. Ob ein Prozess ein Prozessleitsystem bekommt oder einzelne SPS, entscheiden eher seine Eigenschaften als ein einzelnes Merkmal der Technik: wie stark die Regelkreise voneinander abhängen, was ein Stillstand kostet und was dokumentiert werden muss.

Für die Anbindung an die IT ist der Unterschied konkret. Eine SPS wird Steuerung für Steuerung angebunden, über ihr eigenes Protokoll oder einen OPC-UA-Server auf dem Gerät, und viele Maschinen bedeuten viele Verbindungen. Ein Prozessleitsystem ist ein System mit einer Konfiguration. Ein Wert, der von außen hineingeschrieben wird, greift in eine Umgebung ein, die als Ganzes geplant und freigegeben wurde, und der Betreiber will genau wissen, was ein fremdes System daraus liest und hineinschreibt. Wie eine SPS aufgebaut ist und wie ihre Daten herauskommen, erklärt Was ist eine SPS? Aufbau, Programmierung und Anbindung an IT-Systeme.

Ein Prozessleitsystem regelt einen zusammenhängenden Prozess selbst, ein SCADA beaufsichtigt viele Anlagen, deren Steuerung bei den Anlagen bleibt, etwa in ihren SPS. Das DCS kommt historisch aus der kontinuierlichen Prozessindustrie, SCADA aus der verteilten Überwachung, zum Beispiel von Wasserversorgung und Energienetzen.

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 UA und geschlossene SCADA-Systeme.

Die Abgrenzung im Einzelnen steht im Artikel Was ist SCADA? Aufbau, Abgrenzung zu HMI, MES und DCS. In vielen gewachsenen Werken stehen beide nebeneinander, etwa ein Leitsystem für die Produktionsanlagen und ein SCADA für Nebenanlagen. Auf der IT-Seite bedient dann eine Anbindungsschicht beide.

Prozessleitsysteme stehen in der Prozessfertigung: dort, wo ein Produkt nach Rezeptur statt nach Stückliste entsteht und in Chargen oder als kontinuierlicher Strom statt in Stück gezählt wird. Typische Umgebungen sind Chemie und Petrochemie, Pharma, Papier und Getränke. Wie sich Prozessfertigung von diskreter Fertigung unterscheidet, erklärt Diskrete Fertigung vs. Prozessfertigung auf manubes.

Diese Umgebungen haben Eigenschaften gemeinsam, die zum Aufbau eines DCS passen. Der Prozess läuft oft kontinuierlich, rund um die Uhr, oder in Chargen, die man nicht mittendrin unterbricht. Ein Anhalten kostet Material oder ist sicherheitstechnisch heikel. Die Regelkreise hängen voneinander ab: Ändert sich die Temperatur in einem Reaktor, betrifft das Druck und Durchfluss anderswo. Und viele dieser Branchen sind stark reguliert, was eine vollständige Dokumentation und eine strenge Freigabepraxis mit sich bringt.

Die folgende Übersicht nennt verbreitete Systeme zur Orientierung. Sie ist weder vollständig noch eine Wertung.

Für die Anbindung an die IT zählt weniger der Name als die Frage, welche Schnittstellen ein installiertes System anbietet und in welcher Version. Viele ältere Installationen stellen ihre Werte über OPC DA bereit, also die klassische, auf Windows-DCOM aufbauende OPC-Spezifikation. Neuere Versionen bringen häufig OPC UA mit. Welche Schnittstelle in einer bestimmten Anlage freigeschaltet und lizenziert ist, klärt man mit dem Betreiber und dem Hersteller, bevor man plant.

Wie beim SCADA gibt es zwei Richtungen, und bei einem Prozessleitsystem ist die zweite heikler als die erste.

Erste Richtung: aus dem Leitsystem heraus. Messwerte, Zustände und Chargendaten sollen in eine Datenbank, ein MES, ein ERP oder in die Cloud. Eine Middleware liest dafür als OPC-Client aus dem OPC-Server des DCS, über OPC DA oder OPC UA, und schreibt die Werte weiter. Auf der Produktseite des OPC Router steht die Abkürzung PLS in einer Reihe mit SPS, SCADA und MES. Auch SAP bietet dafür eine eigene Komponente an: Laut der Seite zur SAP-Anbindung auf opc-router.de ermöglicht SAP Plant Connectivity (PCo) den Datenaustausch zwischen einem SAP-System und Datenquellen wie Prozessleitsystemen, Plant-Historian- und SPC-Systemen.

Ein Beispiel für diese Richtung nennt die Anwenderübersicht auf opc-router.de (Stand der Seite: Juli 2026): Ein japanischer Hersteller von Dämmstoffen ersetzte den Historian seines DCS durch eine InfluxDB, in die der OPC Router alle paar Sekunden über 10.000 Datenpunkte übertrug. Zusätzlich gingen Daten aus der Produktionsanlage über MQTT an das globale MES des Unternehmens in der Cloud.

Zweite Richtung: in das Leitsystem hinein. Auftragsdaten, Sollwerte oder Rezepturen sollen aus dem ERP beim Prozess ankommen, und zwar ohne Zettel. Das war die Ausgangslage beim Wachshersteller Hywax: Auftragsdaten aus SAP wurden ausgedruckt, abgeholt und an der Anlage von Hand eingegeben. Die Aufgabe lautete, die Daten aus zwei Siemens-Systemen und einem Yokogawa-Leitsystem mit SAP zu verbinden. Eine erste Lösung aus vielen Teillösungen brauchte rund 20.000 Zeilen Code. Mit dem OPC Router wurde der Datentransfer vom SAP-System an die Siemens- und Yokogawa-Anlagen grafisch aufgebaut, und laut Fallbeschreibung wurden über 90 Prozent der Programmierung durch grafische Verbindungen ersetzt.

Eine dritte Form kehrt die Rollen um: Das Leitsystem holt sich die Werte selbst. Kann es als OPC-Client lesen und tritt die Middleware als OPC-UA-Server auf, sieht das DCS dort Werte, die aus ganz anderen Systemen stammen. Das Beispiel auf der Seite zum OPC UA Server Plug-in ist ein Etikettendrucker: Sein Status wird im OPC Router als Variable bereitgestellt, das Leitsystem liest ihn als OPC-Client und kann darauf alarmieren. Über den Methoden-Trigger kann es zudem einen Druckauftrag anstoßen. Der Vorteil dieser Form liegt in der Zuständigkeit: Was gelesen wird und wann, ist im Leitsystem konfiguriert, und die Middleware muss nichts in das freigegebene System schreiben.

Grundsätzliches dazu: Was ist Middleware? · Was ist IT/OT-Integration?

Die Schwierigkeiten bei der Anbindung eines Prozessleitsystems wiederholen sich von Anlage zu Anlage, und sie sind keinem bestimmten Produkt anzulasten. Sie folgen aus der Bauart: aus dem Alter der Schnittstelle, aus der Redundanz des Leitsystems und aus der Vorauswahl, die der OPC-Server des DCS trifft, bevor ein Client einen Wert sieht.

Das Leitsystem spricht OPC DA, und OPC DA braucht DCOM

Auf dem Rechner des Leitsystems läuft die Verbindung. Von einem zweiten Rechner aus bleibt die Liste der verfügbaren OPC-Server leer, oder eine Verbindung, die jahrelang lief, bricht nach einem Windows-Update ab.

Die Ursache liegt im Unterbau. OPC DA baut auf Microsofts COM und DCOM auf. Über das Netz handelt DCOM den eigentlichen Kommunikationsport dynamisch aus: Der Client wendet sich zuerst über Port 135 an den Endpoint-Mapper des Serverrechners und erfährt dort, über welchen Port es weitergeht. Eine Firewall, die nur feste Ports freigibt, blockiert das. Dazu kommt die Sicherheit: Mit dem DCOM Hardening hat Microsoft die DCOM-Sicherheitsvorgaben verschärft; seit dem Windows-Update vom 14. März 2023 lässt sich das Hardening nicht mehr abschalten. Verbindungen, die die Vorgaben nicht erfüllen, werden blockiert.

Erkennbar ist der Fall daran: Lokal geht es, übers Netz nicht. Die Serverliste im Verbindungsdialog bleibt leer, denn laut Handbuch braucht der OPC Router DCOM-Berechtigungen, um sie vom Zielrechner zu lesen. Oder der Abbruch fällt mit einem Update zusammen.

Beim Betreiber liegt die DCOM-Konfiguration, denn sie ist eine Windows-Einstellung auf dem Rechner des Leitsystems. Beide Rechner brauchen denselben Domänenbenutzer, unter dem der Dienst läuft, oder einen lokalen Benutzer mit exakt gleichem Namen und Passwort. Port 135 wird freigegeben und der dynamische Portbereich in der Windows-Registrierung eingeschränkt, damit nur dieser Bereich in der Firewall offen sein muss. Die zweite Möglichkeit ist, DA direkt an der Quelle nach OPC UA zu wandeln. So war es bei einem Unternehmen der Papierindustrie in der Türkei. Laut der Anwenderübersicht auf opc-router.de (Stand der Seite: Juli 2026) liefen dort Leitsystem und Qualitätskontrollsystem auf zwei Servern mit je einem OPC-DA-Server, und Kepware wandelte auf beiden von OPC DA nach OPC UA (ausführlicher in Was ist SCADA?). Ein OPC Tunnel, der OPC-DA-Daten in OPC UA umwandelt, erreicht dasselbe über einen einzigen TCP/IP-Port.

Im OPC Router spricht das OPC-Classic-Plug-in OPC DA in den Versionen 1, 2 und 3; die Version wird in der Anbindung unter „DA Version“ gewählt. Für Server der Versionen 1 und 2 ist laut Handbuch die Option „Änderungsbenachrichtigungen deaktivieren“ zu setzen. Läuft der OPC Router auf demselben Rechner wie der OPC-Server des Leitsystems, fällt die DCOM-Strecke übers Netz weg.

Zwei Grenzen gehören dazu. Das Handbuch sagt wörtlich: „Port 135 und der dynamische Portbereich gehören zu Windows, nicht zum OPC Router.“ Und OPC Classic wird im Docker nicht unterstützt; für den Betrieb des OPC Router als Container ist an dieser Stelle OPC UA nötig.

Das Leitsystem ist redundant, die Anbindung nicht

Das Prozessleitsystem schaltet auf seinen Standby-Server um. In der Leitwarte läuft der Betrieb ohne Unterbrechung weiter, dafür ist die Redundanz ausgelegt. In der Datenbank beginnt zur selben Minute eine Lücke.

Die Redundanz ist eine Eigenschaft des Serverpaars, nicht der Verbindung. Ein Client, der auf eine Adresse eingestellt ist, hat keine Angaben über das Paar. Fällt der Primärserver aus, hat der Client keinen Partner mehr. Und ein Server, der noch antwortet, aber nicht mehr der aktive ist, liefert unter Umständen Werte, die nicht mehr fortgeschrieben werden. Welche Rolle ein Server im jeweiligen Moment hat, führt das Leitsystem; beim Client kommt diese Angabe nur an, wenn das Leitsystem sie als Datenpunkt bereitstellt.

Erkennbar ist der Fall am Zeitpunkt: Die Lücke beginnt mit der Umschaltung des Leitsystems, nicht mit einem Ereignis im Zielsystem. Legt man das Ereignisprotokoll des DCS neben die Fehlzeiten, stimmen die Zeitpunkte überein.

Beim Betreiber liegen der Datenpunkt, der die aktive Rolle anzeigt, und die Kenntnis der Umschaltlogik seines Herstellers. Das Handbuch zieht die Grenze ausdrücklich: „Die eigentliche Hochverfügbarkeit des Fremdsystems wird weiterhin außerhalb des OPC Routers bereitgestellt, zum Beispiel durch eine redundante Serverauslegung oder eine herstellerspezifische Failover-Lösung.“ Was mit Werten aus dem Umschaltmoment geschieht, legt der Betreiber für die Auswertung fest.

Im OPC Router lässt sich im OPC-UA- und im OPC-Classic-Plug-in neben dem primären ein Redundanzserver eintragen, dazu optional ein Lebensitem. Der Router wechselt, wenn der Primärserver nicht erreichbar ist oder das Lebensitem nicht gelesen werden kann bzw. den Wert „0“ liefert. Stellt das Leitsystem seine aktive Rolle als Datenpunkt bereit, lässt sich dieser Datenpunkt als Lebensitem eintragen. Eingestellt wird das in der OPC-Anbindung im Abschnitt „Redundanz“. Die Funktion heißt in der Lizenzübersicht „Redundante Anbindung von Sub-Systemen“, gehört zum Add-on Enterprise+ und ist in der Enterprise-Lizenz enthalten.

Davon zu trennen ist die Redundanz des OPC Router selbst: Sie betrifft die Middleware, nicht die Verbindung zum Leitsystem. Store and Forward hilft hier ebenfalls nicht, es puffert bei Ausfall des Ziels, nicht der Quelle. Das Verhalten im Umschaltmoment hängt vom Leitsystem ab und wird vor dem Betrieb getestet.

Der OPC-Server des Leitsystems filtert Änderungen vorab

Im Trend der Leitwarte sieht man feine Schwankungen. In der Datenbank steht eine Treppe, oder die Werte kommen deutlich seltener als eingestellt.

Bei OPC DA ist die Update Rate eine Anfrage des Clients, keine Anweisung. Das Handbuch formuliert es so: „Allerdings ist es abhängig vom OPC-Server, welche Update Rate berücksichtigt wird.“ Das Dead Band, also die prozentuale Mindeständerung, filtert im Server, bevor beim Client ein Wert ankommt, und es ist „optional und muss nicht von allen OPC-Servern implementiert werden“. Bei OPC UA fordert eine Sample Rate von „0“ die schnellstmögliche Rate des Servers an, und welche das ist, legt der Server fest. Was beim Client ankommt, ist an der Quelle also schon ausgewählt.

Erkennbar ist das daran, dass kleine Änderungen ganz fehlen, statt verspätet anzukommen. Die Zahl der Werte pro Stunde ist konstant niedriger, als die eingestellte Rate erwarten ließe. Das unterscheidet diesen Fall von einer Auslöselogik, die in Was ist SCADA? beschrieben ist: Dort legt der Client fest, wann er überträgt, hier hat der Server schon gefiltert.

Beim Betreiber liegt die Prüfung von Abtastung und Totband am OPC-Server des Leitsystems, denn dort fällt die Auswahl. Das Handbuch nennt als Beispiel den „Scan Mode“ von Kepware, in dem festgelegt wird, welche Scan-Rate der Server verwendet und wie weit er die Rate des Clients berücksichtigt. Das Totband gehört an eine einzige Stelle, sonst filtert man zweimal und kann nicht feststellen, welcher Filter gegriffen hat.

Im OPC Router wird der Quelle mitgeteilt, was gebraucht wird: In der OPC-Classic-Anbindung stehen „Update Rate (ms)“ und „Dead Band (%)“, im OPC-UA-Plug-in die „Sample Rate“, bei der der Wert „0“ die schnellstmögliche Rate des Servers anfordert. Für Werte, die möglichst frisch sein müssen, gibt es den Lesemodus „Synchron“: Er liest so weit wie möglich direkt aus der Datenquelle, erzeugt dafür mehr Netzwerkverkehr und ist nur im OPC-Transferobjekt umgesetzt. Erzwingen kann der Router eine Rate nicht.

Was der OPC-Server des Leitsystems vorab ausfiltert, kommt bei keinem Client an.

Prozessleitsysteme bringen große Datenpunktbestände mit; im japanischen Fall waren es über 10.000 Datenpunkte alle paar Sekunden. Bei OPC UA überwacht der Multi-Datachange-Trigger im OPC Router eine ganze Datenpunktgruppe statt einzelner Werte und prüft auf Wunsch zur Laufzeit, ob Punkte hinzugekommen oder weggefallen sind.

Für die Planung dokumentiert das Handbuch drei Messreihen zum OPC-Datentransfer mit je einer Instanz, gemessen mit einer früheren Version des OPC Router:

Der OPC Router lief in den ersten beiden Reihen auf vier Kernen mit 16 GB RAM, in der dritten auf einer virtuellen Maschine mit acht Prozessoren und bis zu 16 GB. Neuere Messungen enthält das Handbuch nicht.

Für mehr Durchsatz oder getrennte Anlagenbereiche lässt sich je Bereich eine eigene Instanz einsetzen. Das verteilt die Anbindungen auf mehrere Instanzen, hebt aber keine Grenze des OPC-Servers auf: In der Messreihe mit rund 28.500 Datenpunkten pro Sekunde war laut Handbuch der OPC-Server der begrenzende Faktor.