Prozessanalysator in DCS, MES und SCADA – IT/OT-Prüfliste

Die Implementierung eines Prozessanalysators, der nicht in die Steuerungsebene integriert ist, endet stets auf die gleiche Weise – der Bediener blickt auf einen separaten Bildschirm, und die Daten gelangen niemals in die Qualitätsberichte. Daher behandeln wir bei jeder Implementierung die Integration mit DCS, MES und SCADA als separaten Arbeitsstrom und nicht als Anhang zur Gerätelieferung. Dieser Artikel ordnet, worin sich diese drei Ebenen aus Sicht des Analysators unterscheiden, welche Protokolle sinnvoll sind, wo die IT/OT-Grenze verläuft und wie eine realistische Abnahme-Checkliste aussieht.

DCS, MES, SCADA – was wir integrieren und womit

Aus der Perspektive eines Prozessanalysators erfüllen die drei Automatisierungsebenen unterschiedliche Rollen und erfordern unterschiedliche Daten:

• DCS (Distributed Control System) – Echtzeit-Steuerungsebene (Sekunden). Hier landen die Messergebnisse, die wie jede andere Prozessvariable behandelt werden (z. B. „freier Formaldehyd im Reaktor, Gew.-%”), zusammen mit den Messqualitätsflags. Das DCS soll entscheiden, ob der Prozess planmäßig verläuft und wann ein Batch beendet wird.
• SCADA (Supervisory Control and Data Acquisition) – Visualisierungs- und Trendarchivierungsebene. Der Bediener sieht die zeitliche Ergebnis-Kurve, Alarme und den Gerätestatus. SCADA ist sehr oft das, was der Bediener „neben dem DCS” sieht, und übernimmt in kleineren Anlagen gleichzeitig die Rolle des DCS.
• MES (Manufacturing Execution System) – Produktionsausführungsebene: Chargennummer, Operationsreihenfolge, Rezepturparameter, Konformitätsbericht. Die Ergebnisse des Analysators gelangen hier aggregiert im Batch-Kontext – nicht als Rohspektren, sondern z. B. „Endgehalt an Biuret”, „Erfüllung des Endpunkt-Kriteriums”.

Ein gutes Integrationsprojekt trennt diese drei Ströme bewusst. Dieselbe Datenquelle (Analysator und sein chemometrisches Modell) versorgt alle drei Ebenen, jedoch in einer anderen Granularität, mit einer anderen zeitlichen SLA und einem anderen Format.

Protokolle – was wir in polnischen und europäischen Anlagen tatsächlich antreffen

Auf der Ebene der Feldbus-/Steuerungsebene trifft man heute auf zwei dominierende Familien:

• PROFIBUS DP / PROFINET — vorherrschend in europäischen Anlagen, insbesondere in der Chemie und Petrochemie auf Basis von Siemens ausgelegt. PROFIBUS bleibt in älteren Anlagen präsent; PROFINET (Industrial Ethernet) verdrängt ihn in neuen Projekten.
• Modbus RTU / TCP – Niedrige Integrationsebene, bewährt sich als universelle Brücke zwischen einem Feldgerät und einer Steuerung eines Drittherstellers. Günstig, einfach, semantisch eingeschränkt.
• OPC UA – De-facto-Standard für die Integration MES ↔ DCS sowie für IT/OT-Szenarien. Trägt Semantik (Informationsmodell), Sicherheitsfunktionen (Zertifikate, Signierung & Verschlüsselung) und ist die Grundlage für Architekturen gemäß der NAMUR Open Architecture.
• Ethernet/IP – Dominierend in amerikanischen Anlagen auf Basis von Rockwell/Allen-Bradley; in der polnischen chemischen Industrie seltener anzutreffen.

Aus unserer Praxis: Der Analysator liefert Ergebnisse in einem Zeitraum von einigen bis zu mehreren zehn Sekunden, daher besteht keine Notwendigkeit, harte DCS-Zeitschleifen zu verfolgen. PROFINET oder OPC UA über ein Gateway decken die meisten Fälle ab. Die MES-Ebene ist praktisch immer OPC UA oder REST API – vom Integrations-Gateway in der OT-Ebene.

IT/OT-Grenze – wo sie zu setzen ist

Der Prozessanalysator steht in der OT-Ebene (Operational Technology) – in der Produktionshalle, an die Automatisierung angeschlossen. Qualitätsdaten und Batch-Berichte müssen jedoch zum MES, Data Warehouse und BI-Tools in der IT-Ebene gelangen. Die Grenze muss bewusst sein:

• OT-Zone – Analysator, sein Rechner mit chemometrischen Modellen, PLC/DCS-Steuerung. Kommunikation über Feldbus oder dediziertes Industrial Ethernet im Steuerungs-VLAN.
• Industrielle DMZ-Zone – Integrations-Gateway (OPC UA Server, Historian-Connector, REST-Gateway). Hier endet der Zugriff aus der IT-Ebene, die Daten sind signiert und versioniert.
• IT-Zone – MES, ERP, Datenanalysetools. Zugriff nur auf das Gateway in der DMZ, niemals direkt auf den Analysator.

Praktische Konsequenz: Wenn das IT-Team „Zugriff auf Raman-Spektren” zum Trainieren von Vorhersagemodellen haben möchte, wird dieser Zugriff über einen Export aus dem Gateway realisiert – mit RBAC-Kontrolle, Audit-Trail und einem Mock des Produktionsverkehrs. Nicht durch direkten Anschluss an das Steuerungsnetzwerk.

Integrations-Checkliste – vom Workshop bis zur Abnahme

Jede Implementierung eines Analysators in einer DCS/MES/SCADA-Umgebung durchläuft bei uns dieselbe Struktur:

1. Integrations-Workshop (1 Tag) – Unter Beteiligung des Instandhaltungsteams, der Automatisierung, der IT und des Prozessverantwortlichen. Wir legen fest: welche Variablen an das DCS, welche an die SCADA, welche Aggregate an das MES gehen, physikalische Protokolle, IP-Adressen, VLAN, Firewall-Richtlinien.
2. Schnittstellenspezifikation – Dokument: Variablenliste – Name, Typ, Einheit, Aktualisierungsfrequenz, Qualitätsflags, Mapping auf Register / OPC UA NodeId. Von beiden Seiten unterzeichnet.
3. FAT (Factory Acceptance Test) – Bei uns bei Gekko Photonics testen wir die Kommunikation des Analysators mit einer simulierten Steuerung oder einer physischen Teststeuerung, die vom Kunden bereitgestellt wird. Wir überprüfen jede Variable aus der Liste, den Alarmpfad und das Verhalten bei Kommunikationsausfall.
4. SAT (Site Acceptance Test) – Nach der Lieferung an die Linie. Hier testen wir die reale Kette: Analysator → Gateway → DCS → SCADA → MES, am realen Prozess mit Referenzproben.
5. Validierung des chemometrischen Modells – Separater Strom. Die Ergebnisse des Analysators müssen mit der Referenzmethode im Labor (z. B. Titration, HPLC) konsistent sein. Hier messen wir typischerweise einen RMSECV von unter 0,2 Gew.-% für Kalibrationsbereiche von 0,1–5 %, abhängig vom Analyten und der Matrix.
6. Serviceverfahren — wer auf den Alarm „keine Daten vom Analysator” reagiert, wie die Rekalibrierung abläuft, wer die Berechtigungen in Spectrally OS hat, wie wir Spektren archivieren.

Häufigste Integrationsfehler

• Fehlende Messqualitätsflags – Der Analysator sendet einen Wert, aber kein Flag „Daten niedriger Qualität, z. B. verschmutzte Sonde, Modell außerhalb des Bereichs”. Ohne dies weiß der Bediener nicht, wann er der Zahl vertrauen und wann er eine Entscheidung zurückstellen soll.
• Verwechslung der Ebenen – Rohspektren, die ins MES gelangen (Gigabytes nutzloser Aufzeichnung) oder aggregierte Batch-Berichte, die das DCS überfluten (Verlangsamung der Reaktionszeit).
• Fehlender Zeit-Synchronisationspfad – Analysator und Steuerung haben unterschiedliche Uh.
• Den Analysator direkt für das IT-Netz öffnen – ein Sicherheitsfehler, der erst nach dem ersten Cybersicherheitsaudit verschwindet. Alles läuft über das Gateway in der DMZ.
• Nicht definierte Service-SLA – wer reagiert, innerhalb welcher Zeit, auf den Vorfall „Analysator publiziert keine Daten an das DCS“. Ohne diese Festlegung bleibt die Instandhaltung allein mit einem Gerät, das sie nicht kennt.

Lösungen von Gekko Photonics – Integration von Spectrally X1 in DCS, MES und SCADA

Unser Spectrally X1 INLINE unterstützt nativ Modbus. Das deckt die meisten europäischen Chemieanlagen ab. Wo OPC UA, Modbus TCP oder Ethernet/IP benötigt werden, realisieren wir die Integration über ein Gateway in der OT-Ebene – vom nativen Steuerungsprotokoll auf dasjenige, das das DCS/SCADA des Kunden erwartet.

Die Software-Schicht Spectrally OS verwaltet die Spektrenerfassung, die chemometrischen Modelle (CNN, PLS, PCA) und die Archivierung der Rohspektren. Sie exportiert Ergebnisse in den Formaten CSV, PDF und RAW, bietet rollenbasierte Zugriffskontrolle und läuft unter Debian GNU/Linux 13.2 – was das Cybersicherheitsaudit und die Zertifizierung bei Kunden aus der Pharma- oder Lebensmittelbranche vereinfacht. Dashboards in SpectrallyUI liefern dem Bediener in der SCADA-Ebene Spektren- und Trenddiagramme, ohne dass diese im übergeordneten System von Grund auf neu erstellt werden müssen.

Für Laborszenarien – Modellvalidierung, Rohstoffverifizierung, IQC – kombinieren wir den X1 INLINE mit dem Spectrally X1 LAB zu einem gemeinsamen chemometrischen Ökosystem. Im Labor erstellte Modelle übertragen wir in die Produktion, ohne sie von Grund auf neu schreiben zu müssen.

Das vollständige Angebot unserer Analysatoren – mit einer Liste der Varianten und Konfigurationen – finden Sie auf der Seite /analizatory/. Für branchenspezifische Details – Phenol-Formaldehyd-Harze, Düngemittel, Kosmetika, Kohlenwasserstoffe – laden wir Sie in unsere Wissensdatenbank ein, wo wir weitere Beiträge über Raman-Spektroskopie in konkreten Anwendungen veröffentlichen.

FAQ – Häufig gestellte Fragen

Kommuniziert der Spectrally X1 INLINE nativ über OPC UA?

Nativ bietet der Analysator Modbus. OPC UA realisieren wir über ein Integrations-Gateway in der OT-Schicht – dies ermöglicht die Trennung der Steuerung und die Aufrechterhaltung der OPC-UA-Semantik (Informationsmodell, Zertifikate, Signatur und Verschlüsselung) ohne Kompromisse bei der Cybersicherheit.

Wie lange dauert eine typische Integration des Analysators in ein DCS?

Die reine Kommunikationsintegration – vom Workshop bis zum SAT – dauert in der Regel 2–6 Wochen, abhängig von der Verfügbarkeit der Teams auf Kundenseite und dem Reifegrad der DCS-Dokumentation. Die vollständige Implementierung des Analysators (mit Validierung des chemometrischen Modells und Serviceverfahren) dauert bei uns typischerweise 3–5,5 Monate.

Müssen wir das OPC-UA-Gateway separat kaufen?

Abhängig vom Projekt liefern wir das Gateway im Rahmen des Implementierungspakets oder binden es in ein bestehendes Kundengateway ein (falls die Anlage bereits eine DMZ-Schicht hat). Die Entscheidung treffen wir in der Phase des Integrationsworkshops auf Basis der OT-Netzwerkarchitektur.

Wie geht Gekko Photonics mit Cybersicherheitsaudits um?

Spectrally OS basiert auf Debian GNU/Linux 13.2 mit einer Sicherheitsupdate-Richtlinie, rollenbasierter Zugriffskontrolle und vollständigem Audit-Trail. Für Kunden aus der Pharmazie, Lebensmittel- und Getränkeindustrie sowie regulierten Sektoren stellen wir Dokumentation bereit: Architekturbeschreibung, Portliste, Härtungsrichtlinien, Mapping auf IEC 62443. Cybersicherheitsaudits führen wir gemeinsam mit dem IT-Team des Kunden in der Workshop-Phase und vor der Abnahme durch.

Verbleiben die Raman-Spektren in der OT-Schicht oder gehen sie in ein Data Warehouse?

Dies ist eine Designentscheidung. Standardmäßig archivieren wir Rohspektren lokal in Spectrally OS (aufgrund des Volumens – typischerweise Gigabyte pro Monat). An MES und Data Warehouse senden wir aggregierte Ergebnisse, Qualitätsflags und Batch-Metadaten. Der Export von Rohspektren in das IT-Data Warehouse erfolgt auf Anfrage im Batch-Modus über das OPC-UA-Gateway oder REST von der DMZ aus.

Testmessung und technische Beratung

Jede Implementierung beginnen wir mit einem Gespräch mit Ihrem Automatisierungs- und IT-Team – eine 30-minütige technische Beratung reicht aus, um festzustellen, ob der Raman-Analysator in Ihrer DCS-/MES-/SCADA-Architektur sinnvoll ist, welche Protokolle tatsächlich benötigt werden und wo die IT/OT-Grenze zu setzen ist. Danach bieten wir innerhalb von 2 Wochen eine Testmessung Ihrer Proben in unserem Labor an – dies ermöglicht die Bestätigung, dass Raman die richtige Methode für Ihren Analyten und Ihre Matrix ist, bevor Sie in die CAPEX-Phase eintreten. Kontaktieren Sie uns — wir senden die Vorlage der Variablenliste für den Integrationsworkshop und schlagen einen Termin vor.