Die Implementierung eines Prozessanalysators, der nicht in die Steuerungsebene integriert ist, endet auf die gleiche Weise – der Bediener schaut auf einen separaten Bildschirm, und die Daten gelangen nie in die Qualitätsberichte. Bei Gekko Photonics entwerfen und fertigen wir Prozess-Raman-Analysatoren in Polen, in den Varianten Inline, Labor und tragbar, und bei jeder Implementierung ist die Integration in DCS, MES und SCADA ein separater Arbeitsstrom – kein 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 hat Spectrally OS, 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.
• Otwieranie analizatora na sieć IT bezpośrednio — pomyłka bezpieczeństwa, która znika dopiero po pierwszym audycie cyberbezpieczeństwa. Wszystko przez bramkę w DMZ.
• Niezdefiniowane SLA serwisowe — kto reaguje, w jakim czasie, na incydent „analizator nie publikuje danych do DCS”. Bez tego utrzymanie ruchu zostaje samo z urządzeniem, którego nie zna.

Rozwiązania Gekko Photonics — integracja Spectrally X1 z DCS, MES i SCADA

Nasz Spectrally X1 INLINE natywnie obsługuje PROFIBUS, PROFINET oraz GSM (do alarmowania i zdalnej diagnostyki). To pokrywa większość europejskich instalacji chemicznych. Tam, gdzie potrzebne jest OPC UA, Modbus TCP albo Ethernet/IP, integrację realizujemy przez bramkę w warstwie OT — z natywnego protokołu sterowania na ten, którego oczekuje DCS/SCADA klienta.

Warstwa software Spectrally OS zarządza akwizycją widm, modelami chemometrycznymi (CNN, PLS, PCA) i archiwizacją surowych widm. Eksportuje wyniki w formatach CSV, PDF i RAW, oferuje role-based access control i działa na Debian GNU/Linux 13.2 — co upraszcza audyt cyberbezpieczeństwa i certyfikację u klientów farmaceutycznych czy spożywczych. Dashboardy w SpectrallyUI dają operatorowi w warstwie SCADA wykresy widm i trendów bez konieczności budowania ich od zera w systemie nadrzędnym.

Dla scenariuszy laboratoryjnych — walidacja modeli, weryfikacja surowców, IQC — łączymy X1 INLINE z Spectrally X1 LAB jako wspólny ekosystem chemometryczny. Modele zbudowane w laboratorium przenosimy do produkcji bez przepisywania od zera.

Kompletna oferta naszych analizatorów — z listą wariantów i konfiguracji — jest dostępna na stronie /analizatory/. Für branchenspezifische Details — Phenol-Formaldehyd-Harze, Düngemittel, Kosmetika,, Kohlenwasserstoffe — laden wir Sie ein bazy wiedzy, 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 PROFIBUS, PROFINET und GSM. OPC UA realisieren wir über eine 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.

Pomiar testowy i konsultacja inżynierska

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.