DCS vs. SPS in der Wasseraufbereitung: Warum kontinuierliche Prozesschemie und diskrete Logik unterschiedliche Leitsystem-Architekturen brauchen

Mit den steigenden Anforderungen an die Wasseraufbereitung – Zero-Liquid-Discharge-Verdampfung und -Kristallisation, hochreines Wasser für die Halbleiterfertigung, tiefe Salztrennung und Schwermetallentgiftung bei schwierigen industriellen Abwässern – musste die darunterliegende Automatisierungsebene mitwachsen. Zwei Architekturen prägen diese Ebene seit Jahrzehnten: das Distributed Control System (DCS) und die speicherprogrammierbare Steuerung (SPS, im Englischen PLC). Hardware und Software sind über die Jahre ein Stück weit zusammengewachsen, wodurch hybride DCS-Plattformen und programmierbare Automatisierungscontroller (PACs) entstanden sind, die die Grenze auf dem Papier verwischen. Doch unter dieser Konvergenz beruhen beide Architekturen weiterhin auf unterschiedlichen Annahmen über Datenbankstruktur, Aufgabenplanung, Redundanz und die Tiefe der Regelkreise – Unterschiede, die weit mehr Gewicht haben als die alte Faustregel “SPS für diskrete Signale, DCS für Analogsignale” vermuten lässt.

Zwei konkurrierende Philosophien: die Maschine und der Prozess

Das maschinenzentrierte Erbe der SPS. Die SPS geht auf die Ablösung der Relaislogik in der Automobilmontage zurück. Sie wurde entwickelt, um schnelle, deterministische diskrete Logik zu beherrschen, mit Fokus auf einzelne Betriebsmittel – eine Pumpe, ein Ventil, einen Räumer – sowie deren Zustandsübergänge, Ablaufsteuerung und Sicherheitsverriegelungen. Ihr gedankliches Modell lautet Eingang, Logik, Ausgang, und sie legt Wert auf Reaktionsgeschwindigkeit und eigenständige Autonomie in einem einzigen Controller.

Das prozesszentrierte Erbe des DCS. Das DCS entstammt der Petrochemie und den kontinuierlichen Prozessindustrien und wurde entwickelt, um große, anlagenweite physikalisch-chemische Prozesse – thermische Verdampfung, Extraktion, kontinuierliche Reaktion – als ein einziges, unteilbares Fluidsystem zu beherrschen. Sein gedankliches Modell ist die Prozessbilanz, die Mehrgrößenregelung und die anlagenweite Überwachung, und es legt Wert auf die dynamische Kopplung zwischen Variablen, stationäre Genauigkeit in der Analogregelung und absolute Konsistenz der Daten über die gesamte Anlage hinweg.

Datenbankarchitektur: ein einheitliches Modell versus zwei zusammengeschraubte

Ein DCS ist von oben nach unten um eine einzige globale Datenbank herum aufgebaut. Innerhalb der Engineering-Umgebung sind ein Tag, sein Variablentyp, seine Hardware-I/O-Adresse, seine Alarmgrenzen, seine technischen Einheiten, seine Historian-Einstellungen und seine HMI-Grafiken alle in derselben einheitlichen Datenbank verankert. Legt ein Ingenieur einen PID-Baustein oder einen Ventilregelbaustein auf Controller-Ebene an, erzeugt das System automatisch das zugehörige Bedien-Faceplate, den Trendeintrag und den Alarmprotokolleintrag. Jede Online-Änderung an Logik oder Variableneigenschaften pflanzt sich ohne separaten Synchronisationsschritt zu allen betroffenen Knoten fort, was das Risiko von Tag-Diskrepanzen, das lang laufende Engineering-Projekte plagt, deutlich verringert.

Eine SPS hingegen setzt traditionell auf eine hardwarezentrierte, von unten nach oben aufgebaute Datenbank. Ihr Kern ist ein eigenständiger Controller, der Hochgeschwindigkeitslogik ausführt, und ihre Datenbank ist im Grunde eine Hardware-Speicherabbildung – Speicheradressen oder unabhängige Tags. SPS und übergeordnetes System (SCADA/HMI) sind meist völlig getrennte Softwareprodukte. Ingenieure definieren I/O und Zwischenvariablen innerhalb der SPS-Umgebung und bilden diese Variablen dann über OPC (Open Platform Communications) oder einen dedizierten Kommunikationstreiber auf die eigene, separate Datenbank des SCADA-Systems ab. Diese doppelte Datenbankstruktur bedeutet, dass Datentypkonvertierungen von Variablen, Änderungen an Alarmgrenzen und Trendarchivierungseinstellungen zweimal konfiguriert und gepflegt werden müssen – einmal in der SPS, einmal im SCADA. Ändert sich die Speicheradresse einer Variable jemals auf der SPS-Seite, muss die SCADA-Seite manuell neu verknüpft werden, sonst kommt es zu einem Kommunikationsabbruch oder einem still und heimlich falsch zugeordneten Wert.

Aufgabenplanung: feste Scan-Zyklen versus zeitgeschnittenes Multitasking

Eine SPS arbeitet mit scanbasierter zyklischer Abarbeitung: Eingangsabtastung, Programm-Logik-Scan, Ausgangsaktualisierung und Kommunikationsbehandlung in einer festen vierstufigen Schleife. Die Scanzeiten liegen typischerweise im Bereich von $\mu s$ bis $ms$ (etwa 1-10 ms), vor allem abhängig davon, wie viele Codezeilen der Scan abarbeiten muss. Das verleiht einer SPS ausgezeichnete zeitliche Determiniertheit und sehr schnellen Durchsatz bei diskreter Logik – genau das, was Hochgeschwindigkeitsverriegelungen und Ablaufsteuerungen brauchen.

Ein DCS setzt stattdessen auf Multitasking, zeitgeschnittene, interruptgesteuerte Ablaufplanung. Die Regelungslogik wird in periodische Aufgaben mit unterschiedlichen Ausführungsprioritäten aufgeteilt: Sicherheitsverriegelungen und Hochgeschwindigkeitslogik erhalten die höchste Priorität (zum Beispiel einen 50-ms-Zyklus), während komplexe kontinuierliche PID-Regelung, Entkopplungsregelung und Advanced-Process-Control-Algorithmen (APC/MPC) auf niedriger priorisierten periodischen Aufgaben laufen (200-500-ms-Zyklen). Dieses Ablaufplanungsmodell verhindert, dass eine CPU ins Stottern gerät oder einen Watchdog-Timeout auslöst, wenn sie mehrere Hundert oder mehrere Tausend gleichzeitige PID-Regelkreise eines großen kontinuierlichen Prozesses zu bewältigen hat.

Redundanz: native Systemarchitektur versus modulares Zusatzmodul

Hochverfügbarkeit ist der eigentliche Sinn der Prozessregelung, und DCS und SPS unterscheiden sich grundlegend darin, wie – und wie transparent – sie diese liefern.

Ein DCS wurde von Grund auf für unterbrechungsfreie Produktion rund um die Uhr, 365 Tage im Jahr, entwickelt, weshalb seine Redundanz nativ auf Systemebene verankert ist. Controller, Stromversorgungsmodule, der Prozessleitbus, der I/O-Bus und einzelne I/O-Kanäle sind typischerweise mit nahtloser Hot-Standby-Funktion ausgestattet. Primär- und Reserve-Controller bleiben über eine dedizierte Hardware-Speicherspiegelungsverbindung bis auf die Millisekunde synchron – Laufzustand, Zwischenvariablen, Speicherabbild, alles. Erleidet der primäre Controller einen Hardwarefehler oder fällt die Stromversorgung aus, übernimmt der Reserve-Controller ohne Ruckler: keine Unstetigkeit an irgendeinem Analogausgang, kein Zucken am Regelventil, und kein zusätzlicher Redundanz-Synchronisationscode, den der Ingenieur schreiben müsste. Fehlertolerante Abstimmung auf Karten- und Kanalebene (1oo2-, 2oo3-Schemata) ist in der Regel direkt in Hardware und Konfigurationssoftware eingebaut.

Die Redundanz einer SPS wird meist aus externen Hardware-Redundanzmodulen, Doppel-CPU-Baugruppenträgern und dedizierten Redundanz-Kommunikationsmodulen zusammengesetzt. Moderne SPS im mittleren bis oberen Leistungssegment können durchaus einen Controller-Hot-Standby erreichen, aber wie stoßfrei die Umschaltung tatsächlich abläuft und wie viel davon die Plattform transparent übernimmt, hängt stark von der konkreten Implementierung ab. In einer typischen SPS-Redundanzkonfiguration müssen Ingenieure häufig Datensynchronisationsbausteine explizit konfigurieren, Statusflags abbilden und in manchen Fällen das Halteverhalten bestimmter Module – etwa einer Analogausgangskarte – während der Umschaltung selbst behandeln.

Wo diese Umschaltung letztlich ankommt, liegt stromabwärts vom eigentlichen finalen Stellglied. Unabhängig davon, welche Architektur den Befehl erteilt, hat das Regelventil oder die Dosierpumpe, die ihn empfängt, eine eigene, separate Auslegungsfrage – der Pneumatik-Antriebsauswahl-Rechner dieser Seite deckt diesen Teil des Gesamtbilds ab.

Tiefe der Regelalgorithmen

Die Prozessregelungsbibliothek des DCS. Ein DCS wird mit einer umfangreichen Bibliothek industriell bewährter Regelbausteine hoher Ordnung ausgeliefert. Sein PID-Baustein integriert nativ Anti-Windup, stoßfreie Umschaltung zwischen Hand- und Automatikbetrieb, Vorsteuerung (Feedforward), Verhältnisregelung, adaptive Verstärkung, Smith-Prädiktoren für feste Totzeiten und Algorithmen zur Mehrgrößenentkopplung. Die Konfiguration eines Kaskaden-PID oder eines Vorsteuerungs-Rückführungs-PID besteht größtenteils darin, zwei Funktionsbausteinanschlüsse miteinander zu verdrahten; der Algorithmus übernimmt intern die Master/Slave-Zustandsverfolgung und die Hand/Automatik-Umschaltlogik.

Wie eine SPS dieselbe Mathematik umsetzt. Auch eine SPS bietet einen einfachen PID-Funktionsbaustein, doch darüber hinaus berechnet sie in der Regel nur die zeitdiskrete PID-Standardformel:

$$u(k) = K_p e(k) + K_i \sum_{i=0}^{k} e(i) T_s + K_d \frac{e(k) - e(k-1)}{T_s}$$

Sobald der Prozess Mehrgrößenentkopplung, Vorsteuerungsüberlagerung oder Hand/Automatik-Zustandsumschaltung benötigt, muss der Ingenieur zusätzlichen Structured-Text-Code (ST) schreiben, um Integratorzustands-Verriegelung, Ausgangsbegrenzung und die Verwaltung von Tracking-Variablen von Hand zu behandeln. Jede Lücke in dieser Logik zeigt sich tendenziell als Regelausgangs-Sprung genau bei der Hand/Automatik-Umschaltung, den das Feldventil als plötzlichen Ruck spürt.

Drei Dimensionen des Engineering-Lebenszyklus, die den eigentlichen Sieger bestimmen

Unterhalb der rechnerarchitektonischen Unterschiede sind es die “Ergonomie” und die tägliche Bedienerfahrung eines Leitsystems über den gesamten Projektlebenszyklus hinweg, die tatsächlich darüber entscheiden, ob eine Auswahl richtig war.

Engineering- und Implementierungsfreundlichkeit

Bei der Benutzerfreundlichkeit geht es um Entwicklungsgeschwindigkeit – vom Engineering-Entwurf und der Logikprogrammierung über die Bildschirmkonfiguration bis zur Feldinbetriebnahme.

Für die Regelkreiskonfiguration erlaubt die reichhaltige Funktionsbausteinbibliothek eines DCS – Anti-Windup, stoßfreie Umschaltung, Vorsteuerung, Verhältnisregelung, Mehrgrößenentkopplung, alles bereits eingebaut – einem Ingenieur, einen komplexen Regelkreis größtenteils durch Ziehen von Verbindungen zwischen vorgefertigten Bausteinen und das Ausfüllen von Parametern zu konfigurieren. Eine SPS verfügt nur über einen einfachen PID-Baustein und verlangt von Ingenieuren, zusätzlichen Kontaktplan-Code (Ladder Diagram, LD) oder Structured-Text-Code (ST) für Kaskaden-, Vorsteuerungs- oder Entkopplungslogik zu schreiben und dabei Integrator-Windup, stoßfreien Übergang und Ausreißervertrauen von Hand zu behandeln – eine höhere Entwicklungshürde bei weniger standardisierten Ergebnissen.

Für die HMI-Entwicklung ist ein DCS auf Ebene der Systemkonfiguration hochgradig effizient: Wird am Controller ein neuer Pumpen- oder Ventilfunktionsbaustein hinzugefügt, übernimmt die Bedienoberfläche automatisch ein standardisiertes Faceplate – Betriebsstatus, Hand/Automatik-Schalter, Störmeldetext, Echtzeittrend, alles. Eine SPS erfordert stattdessen “doppelte Arbeit”: Nachdem die Regelungslogik in der SPS-Umgebung geschrieben wurde, muss der Ingenieur separat die SCADA-Software öffnen, die Ventilgrafiken manuell zeichnen, die Tag-Kommunikationszuordnung manuell aufbauen und die Popup-Skripte sowie die Alarmauslösungslogik für das Bedienpanel manuell schreiben.

Bei der Integration von OEM-Skids dreht sich das Bild um. Da ein DCS auf einer einheitlichen Datenbank und einer bestimmten Hardwarearchitektur beruht, gestaltet sich die Einbindung eines unabhängigen Schaltschranks eines Drittanbieter-Skid-Lieferanten – etwa eines Hochdruckpumpen-Skids oder eines Ozongenerator-Skids – tendenziell umständlich; die Daten des Drittanbieters müssen üblicherweise über ein generisches Modbus- oder Profinet-Gateway abgebildet werden, was die Konsistenz der nativen Datenbank durchbricht. Eine SPS hingegen ist von Natur aus offen und modular: Die überwältigende Mehrheit der OEM-Skid-Pakete ist nativ um eine SPS als lokalen Controller herum aufgebaut, sodass SPS-Systeme auf der anlagenweiten Integrationsebene die Skid-Pakete verschiedener Anbieter mit vergleichsweise wenig Reibung über einen gemeinsamen Feldbus verknüpfen können.

Betriebs- und Wartungsfreundlichkeit

Die Wartbarkeit bestimmt unmittelbar die mittlere Wiederherstellungszeit (MTTR) einer Anlage nach einer ungeplanten Störung – und wie viel des täglichen Betriebs überhaupt ohne Unterbrechung abläuft.

Für Online-Programmierung und Download gilt: Der gesamte Existenzgrund eines DCS ist es, nicht anzuhalten. Es unterstützt echte globale inkrementelle Online-Kompilierung und stoßfreien Download: Ändert ein Ingenieur die Regelungslogik, stellt einen PID neu ein oder fügt eine neue Variable hinzu, hat der Download keinerlei Auswirkung auf den CPU-Laufzeitzustand des Controllers – Feldventilausgänge bleiben stetig, PID-Regelkreise springen nicht, und der SCADA-Bildschirm flackert nicht einmal in seiner Kommunikationsverbindung. Eine moderne SPS im mittleren bis oberen Segment unterstützt die Online-Änderung mancher Codeabschnitte, doch jede Änderung an einer Datenbausteinstruktur, an der Hardwarekonfiguration oder ein umfangreicher Logik-Neuaufbau erzwingt in der Regel einen vollständigen Download, der die SPS für Millisekunden bis Sekunden in einen Stoppmodus versetzen oder die Kommunikation mit SCADA kurzzeitig unterbrechen kann – ein reales Risiko in einer hochgefährlichen, kontinuierlich laufenden chemischen oder thermischen Prozessstufe wie einem MVR-Verdampfer, wo eine solche Unterbrechung eine Sicherheitsabschaltung auslösen kann.

Für Diagnose und Hot-Swap hält ein DCS strikte Fehlereingrenzungszonen von der Kanalebene über die Kartenebene bis zur Busebene ein, zusammen mit nativer Hot-Swap-Fähigkeit (RIOP). Wird ein Analogeingangskanal durch einen Kurzschluss in einem Feldgerät zerstört, verhindert die interne Strombegrenzung und Optoisolation der Karte, dass sich der Fehler jemals auf einen benachbarten Kanal oder den Rückwandbus ausbreitet, und die Karte kann ohne Software-Reset getauscht werden. DCS-Plattformen bieten typischerweise auch eine systemweite Sequence-of-Events-Aufzeichnung (SOE) gemäß dem Alarmmanagement-Standard ISA-18.2, mit Auflösungen bis hinunter zu 1 ms, was die Rückverfolgung der wahren Erstursache eines Vorfalls erheblich erleichtert. Die verteilten I/O-Karten einer SPS unterstützen ebenfalls häufig Hot-Swap, aber die Diagnoseinformationen müssen üblicherweise vom Ingenieur abgerufen werden, indem im SPS-Programm ein dediziertes Diagnose-Systemfunktionsbaustein (SFC/SFB) aufgerufen und das ausgewertete Ergebnis explizit an SCADA übergeben wird. Wurde diese Diagnoseroutine nie geschrieben, kann sich ein Fehler auf Kartenebene im Feld in SCADA lediglich als unspezifischer “Kommunikationsverlust” zeigen.

Skalierbarkeit und Zukunftssicherheit

Die Aufrüstbarkeit bestimmt, wie gut ein Automatisierungsgut seinen Wert über einen Anlagenlebenszyklus von 10-20 Jahren behält, und wie teuer eine Technologieerneuerung ausfällt.

Bei Abwärtskompatibilität und Lebenszyklus verpflichten sich DCS-Hersteller als Gruppe zu einem ungewöhnlich strengen Standard an Vorwärtskompatibilität – typische Systemlebenszyklen liegen bei 15-20 Jahren oder länger. Ein DCS-Controller einer neuen Generation kann oft eine zwanzig Jahre zuvor eingesetzte I/O-Karte aufnehmen, und ein älteres Engineering-Projekt kann mit geringer Störung in die neue Generation migrieren. Diese reibungslose Weiterentwicklung senkt die Kapitalkosten und das technische Risiko künftiger Automatisierungs-Upgrades einer Anlage spürbar. Der Iterationszyklus einer SPS ist kürzer – typische Hardware-Lebenszyklen liegen bei 8-12 Jahren –, und die darin verbauten Elektronikkomponenten im Konsumentensegment werden schneller ausgemustert. Ein Generationswechsel von einer SPS-Plattformfamilie zu ihrer Nachfolgerin bringt häufig einen kompletten Wechsel von Busprotokoll, Programmiersoftware und Hardware-Rückwand mit sich, sodass die Migration eines Programms in der Regel dedizierte Konvertierungswerkzeuge oder ein komplettes Neuschreiben der Logik erfordert.

Bei Hardwareerweiterung und Netzwerktopologie ist die Erweiterung eines DCS üblicherweise um eine feste, redundante Prozessnetzwerkarchitektur herum aufgebaut: Das Hinzufügen einer neuen Remote-I/O-Station lässt das System automatisch eine Knotenadresse zuweisen und die Routing-Konfiguration abschließen, was standardisiert ist, aber mit recht starren Topologiebeschränkungen einhergeht. Eine SPS bietet erheblich mehr Flexibilität bei industriellen Netzwerken und unterstützt Profinet, EtherNet/IP, Modbus TCP, EtherCAT und weitere Protokolle nebeneinander. Wird ein kleines bis mittleres System erweitert oder muss ein heterogenes Drittanbietergerät – ein Frequenzumrichter, ein smarter Wasserqualitätsanalysator, ein Roboter – angebunden werden, ist die Netzwerkanpassungsfähigkeit einer SPS die agilere Option.

Sechzehn Dimensionen im direkten Vergleich

Dimension	DCS	SPS
Designphilosophie	Prozesszentriert, kontinuierliche Prozessregelung	Maschinenzentriert, diskrete Logiksteuerung
Datenbankarchitektur	Einzige globale, einheitliche Datenbank	Unabhängige Controller-Datenbank, über OPC/Treiber auf SCADA abgebildet
Vorherrschender Regelungstyp	Analog, komplexe PID-Regelkreise, Mehrgrößenentkopplung	Diskret/digital, Hochgeschwindigkeitslogik, Ablaufsteuerung
Logikausführung	Multitasking-Zeitscheiben-Planung, periodische Aufgaben	Feste Scan-Zyklen, zyklische Abarbeitung
Scan-/Reaktionszeit	Typischer Zyklus: 50 ms – 500 ms	Sehr schnell: 1 ms – 10 ms
Engineering-Freundlichkeit	Reichhaltige native Algorithmenbibliothek; HMI-Faceplates und Alarme automatisch generiert	Einfache Algorithmenbibliothek, erfordert Ladder-/ST-Programmierung; HMI separat konfiguriert
Betriebs-/Wartungsfreundlichkeit	Globaler stoßfreier inkrementeller Online-Download; native Fehlerisolierung auf Kanalebene	Tiefgreifende Downloads können einen Stopp erzwingen; Diagnose erfordert handgeschriebene Funktionsbausteine
Redundanz	Native, systemweite Vollredundanz (Stromversorgung, Controller, Netzwerk, I/O), stoßfrei	Modulare optionale Redundanz, erfordert dedizierte Module und Synchronisation auf Codeebene
Analoge PID-Fähigkeit	Reichhaltige Bibliothek (Vorsteuerung, Kaskade, Smith-Prädiktor, MPC), starke Entkopplung	Einfacher PID-Baustein, Mehrgrößenentkopplung vergleichsweise schwierig
HMI	Tiefe native Integration; Ventil-/Pumpen-/PID-Faceplates automatisch generiert	Unabhängige SCADA-Software, Bildschirme und Tag-Kommunikation separat aufgebaut
Lebenszyklus und Kompatibilität	15-20+ Jahre, starke Hardware-Abwärtskompatibilität, reibungslose Upgrades	8-12 Jahre, schnellere Iteration, Generationswechsel erfordert Konvertierung/Neukonfiguration
Engineering-Entwicklungseffizienz	Sehr schnell für große kontinuierliche Prozesse, hohe Wiederverwendbarkeit, stoßfreie Online-Änderungen	Effizient für Logik diskreter Geräte; große Prozesse erfordern umfangreiches manuelles Tag-Mapping
Netzwerktopologie und Bus	Geschlossen-offenes Hybrid-Industrial-Ethernet, hochredundante Ring-/Doppelnetzwerke	Sehr offen, unterstützt Profinet, EtherNet/IP, Modbus TCP und weitere
Fehlerisolierung	Strikte Fehlereingrenzungszonen auf Controller- und I/O-Busebene	Ein einzelner Kartenfehler kann sich über den internen Rückwandbus auf andere Module ausbreiten
Typische Größenordnung	I/O-Anzahl über ~2.000 Punkte, hoher Analoganteil (>30%), anlagenweite Systeme	Einige Dutzend bis mehrere Tausend Punkte, flexible Verteilung, diskretlastig
Anfängliches CAPEX	Höher (Kosten für Controller und Softwarelizenzierung)	Niedriger (starkes Preis-Leistungs-Verhältnis der Hardware, klarer Vorteil bei kleinen Systemen)

Die Architektur an das Wasseraufbereitungssegment anpassen

Unterschiedliche Wasseraufbereitungsprozesse haben grundlegend verschiedene physikalisch-chemische Eigenschaften, und genau das bestimmt letztlich die richtige Leitsystemarchitektur.

Kommunale Trinkwasser- und Abwasserbehandlung ist geografisch verstreut und von diskreten Signalen dominiert, weshalb sie auf vernetzten SPS mit einer zentralen SCADA-Ebene läuft. Eine kommunale Kläranlage umfasst Pumpwerke, Rechenanlagen, Sandfänge, biologische Reaktoren – A²/O, MBR oder andere Verfahren –, Nachklärbecken und Schlammentwässerung. Die Anlage ist geografisch verteilt, mit einem hohen Grad an Autonomie der Teilanlagen; die Ausrüstung (Pumpen, Räumer, Ventile) wird von diskreter Zustandssteuerung dominiert, und die Regelungslogik besteht überwiegend aus füllstands- oder zeitbasierter Ablaufumschaltung. PID-Regelkreise (Sauerstoffregelung im Belebungsbecken, Dosierratenregelung) sind relativ wenige und weitgehend unabhängig voneinander. Die nahezu universelle Architektur ist ein zentrales SCADA-Überwachungssystem über regionale SPS-Teilanlagen im Feld: Jeder Prozessbereich erhält einen eigenen SPS-Schaltschrank, der die lokalen Anlagenverriegelungen übernimmt, während SCADA die Daten über ein Industrial Ethernet zusammenführt – eine Struktur mit klarem Vorteil sowohl bei den Kapitalkosten als auch bei der Flexibilität der Netzwerkgestaltung.

Schwierige industrielle Abwässer und Zero Liquid Discharge stellen einen stark gekoppelten thermodynamisch-chemischen Prozess dar, und das ist DCS-Territorium. In ZLD-Systemen, die um Kohlechemie-, Petrochemie- oder Rauchgasentschwefelungsabwässer herum aufgebaut sind, durchläuft die Prozesskette Vorbehandlung, Membrankonzentrierung und thermische Verdampfungskristallisation (MVR oder Mehrfacheffekt-Verdampfung). Verdampferfüllstand, Sekundärdampfdruck, Umwälzpumpenstrom und Übersättigung der Mutterlauge stehen in starker, dynamischer Wechselwirkung zueinander. Der Anteil analoger I/O macht typischerweise 30-50% der gesamten I/O aus, mit einer großen Zahl an Kaskaden-, Vorsteuerungs- und Entkopplungsregelkreisen. Fällt ein Controller aus oder beginnt ein PID-Regelkreis zu pendeln, kann der Verdampfer verkrusten oder die Zwangsumwälzpumpe kavitieren und verstopfen – und die Kosten für Stillstand, Reinigung und Wiederanlauf sind gravierend. Ein natives DCS ist hier nahezu unverzichtbar: Seine Bibliothek an Entkopplungsalgorithmen, die deterministische Multitasking-Ablaufplanung, die einheitliche globale Datenbank und die stoßfreie Online-Änderung sind es, die ein ZLD-System kontinuierlich im stationären Zustand am Laufen halten.

Hochreines Wasser für die Halbleiterfertigung (UPW) verlangt Verunreinigungskontrolle im Parts-per-Trillion-Bereich und einen spezifischen Widerstand nahe dem theoretischen Grenzwert von $18{,}2\ \text{M}\Omega\cdot\text{cm}$. Ein UPW-System besteht aus einer großen Zahl dicht gepackter, vorgefertigter OEM-Skids – Sandfiltration, RO, EDI, Mischbett-Polishing –, und es benötigt eine extrem hochfrequente Wasserqualitätsüberwachung; sobald die Wasserqualität außerhalb der Spezifikation liegt, muss ein Ventil binnen Millisekunden schließen, um die nachgelagerte Waferfertigung zu schützen. Die nahezu universelle Architektur ist eine Hybridlösung: verteilte Hochgeschwindigkeits-SPS-Skids plus ein zentrales DCS oder SCADA zur Überwachung. Jeder Skid wird unabhängig von seinem OEM-Lieferanten um eine SPS herum entwickelt und in Betrieb genommen, was modulare Liefereffizienz und Schutzreaktionen im Millisekundenbereich sichert; die zentrale Überwachungsebene wird anschließend im DCS der Anlage oder einem großen SCADA-System vereinheitlicht, was eine anlagenweite Wasserbilanzplanung und Qualitätsrückverfolgbarkeit ermöglicht. Der Beitrag dieser Seite zu Spurenverunreinigungen bei UPW in der Halbleiterfertigung geht tiefer auf die Reinheitsseite dieses Bilds ein.

Schwermetall- und Spezialabwasserbehandlung – Bergbau-, Metallurgie- und Galvanikabwässer mit Arsen, Antimon, Blei, Cadmium oder Cyanid – verlangt zweierlei zugleich: extrem präzise Chemikaliendosierung (kontinuierlich nachgeführt anhand von ORP, pH-Wert und Schwermetallkonzentration im Zulauf, ein Regelkreis, den der Chemikaliendosierungs-Rechner dieser Seite dimensionieren helfen kann), und extrem zuverlässige Sicherheitsverriegelungen, da eine außerhalb der Spezifikation liegende Einleitung binnen Sekunden abgesperrt und in ein Notfall-Auffangbecken umgeleitet werden muss. Die typische Architektur ist eine große, doppelt heiß-redundante SPS oder ein Mikro-DCS, gewählt speziell wegen der starken Analogverarbeitung in Kombination mit Redundanz auf Hardwareebene.

Drei Praxisfälle

Fall 1: Kohlechemisches Hochsalz-ZLD mit Salztrennungskristallisation

Ein Zero-Liquid-Discharge-Projekt eines großen kohlechemischen Komplexes, ausgelegt auf 12.000 m³/d, behandelt einen Zulauf mit rund 42.000 mg/L TDS (darunter Sulfat mit etwa 17.000 mg/L und Chlorid mit etwa 11.000 mg/L) über eine Kette aus zweistufiger Nanofiltrations-Salztrennung, Natriumsulfat-Verdampfungskristallisation, RO-Konzentrierung und Natriumchlorid-Verdampfungskristallisation – wobei letztlich Natriumsulfat mit $\geq 99\%$ Reinheit und Natriumchlorid mit $\geq 98\%$ Reinheit zurückgewonnen werden, bei einem Mischsalzanteil von nur etwa 10%.

Früh im Projekt wurde eine SPS+SCADA-Option direkt gegen ein DCS getestet. In der MVR-Zwangsumwälzverdampfungs-Kristallisationsstufe zeigte das DCS drei entscheidende Vorteile:

Komplexe thermodynamische Entkopplung. Kristallisatorfüllstand, Dampfdruck und Umwälzpumpenstrom stehen in starker Wechselwirkung. Das DCS führte über sein integriertes Advanced-Process-Control-Modul (APC) einen Vorsteuerungs-Kaskaden-Algorithmus aus:

$$u_{steam}(t) = K_p e_L(t) + K_i \int e_L(t)\,dt + K_d \frac{de_L(t)}{dt} + K_{ff} \cdot \Delta TDS_{in}(t)$$

der stationär mit einem 200-ms-Regelzyklus lief und die Übersättigung der Kristallisation präzise innerhalb der metastabilen Zone hielt. Das parallel getestete SPS-System zeigte mangels nativem Entkopplungsalgorithmus starkes Pendeln zwischen den PID-Regelkreisen und löste häufig Überdruck im Verdampfer aus.

Stoßfreie Online-Änderungen. Während der Hochfahr-/Fehlerbehebungsphase musste die Dosierverhältnislogik häufig angepasst werden. Die globale inkrementelle Online-Kompilierung des DCS griff nahtlos, ohne jede Störung eines PID-Ausgangs. Im SPS-Test löste der Versuch, einen geänderten Datenbaustein herunterzuladen, eine kurze Trennung von SCADA aus, und das Dosierventil fiel kurzzeitig auf null zurück.

Hardwareisolierung auf Kanalebene. Während des Betriebs verursachte ein Kurzschluss im Dichtemessgerät der Mutterlauge einen Hochdruckrückstau. Die Kanalisolierung der DCS-Karte blockierte erfolgreich die Ausbreitung des Fehlers; der Controller hielt automatisch seinen vorherigen Ausgang, meldete einen Alarm und ermöglichte den Heißaustausch der defekten Karte, ohne Stillstand (natives RIOP).

Fall 2: Ultrareinwassersystem einer Halbleiterfabrik

Das UPW-System einer 12-Zoll-Waferfabrik, ausgelegt auf 15.000 m³/d, läuft mit einer Architektur aus “SPS-Skid-Paketen plus zentralem SCADA/DCS”.

Schutzreaktion im Millisekundenbereich. Erkennt ein Inline-TOC-Analysator am Verwendungspunkt eine Wasserqualitätsabweichung (oberhalb von etwa 2 ppb), führt die lokale Skid-SPS eine feste 5-ms-zyklische Terminal-Interrupt-Routine aus und schließt ein Dreiwege-Absperrventil binnen 40 ms – wodurch erfolgreich verhindert wird, dass außerhalb der Spezifikation liegendes Wasser jemals die Fertigungslinie erreicht.

Modulare OEM-Lieferung. Achtzehn unabhängige Skids (Sandfiltration, RO, EDI, Mischbett) wurden jeweils von unterschiedlichen Lieferanten in Eigenregie mit einer SPS programmiert und in Betrieb genommen und anschließend vor Ort über Profinet und OPC UA als Standardprotokolle an das Zentralsystem angeschlossen – was die Bauzeit der Anlage deutlich verkürzte.

Fall 3: Kommunale Kläranlage mit 100.000 m³/d, intelligente Nachrüstung

Eine kommunale Kläranlage mit 100.000 m³/d baute ihre ursprüngliche Konfiguration aus “sieben unabhängigen SPS-Teilanlagen plus SCADA” zu einem einheitlichen hybriden Leitsystem um.

Controllerverteilung. Vor der Nachrüstung: sieben unabhängige SPS-Teilanlagen ohne direkte Controller-zu-Controller-Kommunikation. Danach: eine integrierte, verteilte Leitsystemarchitektur auf einer einheitlichen Plattform.

Datenbankmanagement. Vorher: sieben separate SPS-Datenbanken plus eine SCADA-Datenbank, jede unabhängig konfiguriert. Danach: eine einzige, zentralisierte, einheitliche Engineering-Datenbank.

Sauerstoffregelung in der Belüftung. Vor der Nachrüstung wurde der Sauerstoffgehalt durch einfache Ein/Aus-Zeitsteuerung gehalten und schwankte um etwa $\pm 1{,}5\ \text{mg/L}$. Nach der Nachrüstung lief die Sauerstoffregelung über Vorsteuerungs-Kaskaden-PID nach folgender Formel:

$$\text{Air Flow Request} = f(Q_{in}, \text{NH}_4^+\text{-N}_{in}) + \text{PID}_{DO}(DO_{set} - DO_{actual})$$

wodurch der Sauerstoffgehalt stabil auf etwa $\pm 0{,}3\ \text{mg/L}$ um den Sollwert gehalten wurde.

Wartung und Erweiterung. Vor der Nachrüstung erforderte die Änderung einer Variable die Konfiguration an beiden Enden und einen kurzen Stopp zum Download; danach unterstützt die Anlage den globalen, stoßfreien Online-Download, und die Wartung ist erheblich einfacher.

Energie. Nach der Nachrüstung sank der gesamte Energieverbrauch der Gebläse um 12%, und der Chemikalienverbrauch sank um 8%.

Ein quantitatives Entscheidungsmodell

Die Wahl zwischen DCS und SPS sollte nicht auf subjektiver Vorliebe beruhen – sie lässt sich direkt anhand von Projektparametern bewerten. Definieren wir einen Auswahlindex $S_{DCS}$:

$$S_{DCS} = w_1 \cdot A_r + w_2 \cdot C_l + w_3 \cdot D_g + w_4 \cdot R_u - w_5 \cdot S_k$$

wobei die Parameter wie folgt definiert sind:

• $A_r$: Anteil analoger I/O (1, wenn größer als 30%, sonst 0).
• $C_l$: Anzahl komplexer/kaskadierter/entkoppelter PID-Regelkreise (1, wenn mehr als 30 Regelkreise, sonst 0).
• $D_g$: Bedarf an globaler Datenkonsistenz und stoßfreier Online-Änderung (1 bei starkem Bedarf, 0 bei keinem).
• $R_u$: Kosten einer Unterbrechung der kontinuierlichen Produktion (1, wenn Stillstandsverluste sehr hoch sind, 0, wenn Ausfallzeiten tolerierbar sind).
• $S_k$: Anteil unabhängiger Drittanbieter-OEM-Skid-Ausrüstung (1, wenn der Skid-Anteil 50% übersteigt, sonst 0).
• $w_i$: Gewichtungskoeffizienten (empfohlen: $w_1=0{,}25,\ w_2=0{,}25,\ w_3=0{,}20,\ w_4=0{,}20,\ w_5=0{,}10$).

Entscheidungsregel:

• Wenn $S_{DCS} \geq 0{,}60$: DCS-System dringend empfohlen.
• Wenn $S_{DCS} \leq 0{,}35$: vernetzte SPS+SCADA-Architektur dringend empfohlen.
• Wenn $0{,}35 < S_{DCS} < 0{,}60$: hybrides Leitsystem empfohlen (Hybrid-DCS/PAC).

Gesamtbetriebskosten

Die Gesamtbetriebskosten (Total Cost of Ownership, TCO) setzen sich aus Investitionskosten (CAPEX) und Betriebskosten (OPEX) zusammen:

$$TCO = CAPEX_{hardware+software+engineering} + \sum_{t=1}^{N} \frac{OPEX_{maintenance} + OPEX_{downtime} + OPEX_{energy}}{(1+r)^t}$$

Wie sich die Kostenbilanz verschiebt. Beim Erstkauf liegen Hardware- und Softwarelizenzkosten einer SPS+SCADA-Lösung typischerweise 30-50% unter denen eines DCS, und dieser CAPEX-Vorteil ist bei kleinen bis mittleren Projekten besonders ausgeprägt. Während Engineering und Inbetriebnahme kann bei analogintensiven, komplexen Prozessen wie ZLD die einheitliche Datenbank und native Algorithmenbibliothek eines DCS die Zeit für die Feldinbetriebnahme um etwa 40% verkürzen und so die Engineering-Personalkosten senken. Über eine Betriebsdauer von 10-15 Jahren senken der stoßfreie Online-Download, die Fehlerisolierung auf Kanalebene, die reibungslose Abwärtskompatibilität und die Prozessoptimierungsfähigkeit (Energieeinsparung, Verbrauchsreduktion) eines DCS die Ausfallverluste und Instandhaltungskosten spürbar – und in der Praxis unterschreiten die Gesamtbetriebskosten eines DCS jene eines SPS-Systems, das häufige Neukonfigurationen erfordert, typischerweise im Bereich von 5-7 Jahren.

Fazit

Über die gesamte Bandbreite der Wasseraufbereitungsautomatisierung hinweg sind DCS und SPS weniger Konkurrenten als vielmehr zwei Architekturen mit unterschiedlichem technischem Erbgut, die jeweils Arbeit leisten, die die andere nicht ersetzen kann:

Die Kernstärke der SPS liegt in der Effizienz diskreter Logik, zeitlicher Determiniertheit und modularer Beweglichkeit. In der kommunalen Wasserver- und -entsorgung, bei Teilanlagen von Kläranlagen und bei eigenständigen Ultrareinwasser-Skids ist eine SPS-plus-SCADA-Architektur die kosteneffizienteste und flexibelste Wahl.

Die Kernstärke des DCS liegt in der Kontinuität der Prozessregelung, der globalen Datenkonsistenz und der hochverfügbaren Fehlertoleranz. Bei Zero-Liquid-Discharge-Industrieabwässern, Verdampfungskristallisation und anderen komplexen thermischen und chemischen Prozessen ist ein DCS das Werkzeug, das eine gesamte Anlage sicher, stabil und kontinuierlich am Laufen hält.

Für künftige Automatisierungsprojekte in der Wasseraufbereitung sollte die Systemauswahl jede Voreingenommenheit gegenüber einem bestimmten Hardware-Label beiseitelassen, direkt auf die physikalisch-chemische Natur des Prozesses selbst blicken und das beste Gleichgewicht zwischen Engineering-Freundlichkeit, Wartbarkeit, künftiger Aufrüstbarkeit und Gesamtbetriebskosten finden.

Weiterführende Literatur

• International Society of Automation, ISA-18.2 — Management of Alarm Systems for the Process Industries — die maßgebliche Referenz für Sequence-of-Events-Aufzeichnung und Alarmmanagement-Praxis, wie oben besprochen.
• International Electrotechnical Commission, IEC 61131-3 — Programmable Controllers, Part 3: Programming Languages — der maßgebliche Standard für die SPS-Programmierung mit Kontaktplan und Structured Text.
• International Electrotechnical Commission, IEC 61508 — Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems — die grundlegende Referenz für die Sicherheitsverriegelungs- und SIL-Betrachtungen bei hochgefährlichen Dosier- und Verriegelungsanwendungen.
• International Society of Automation, ISA-95 — Enterprise-Control System Integration — das Standardrahmenwerk für die Datenarchitektur zwischen Anlagenleitsystemen und Unternehmenssystemen.