Produktionsdaten im Brownfield: Warum die Maschinenanbindung selten das eigentliche Problem ist

WISSEN | Industrial Data

In vielen Digitalisierungsprojekten lautet die erste Frage:
Wie bekommen wir die Daten aus der Maschine?

Dabei ist genau das häufig der einfachste Teil.
OPC UA, Modbus, S7, proprietäre Schnittstellen oder ein Gateway – irgendwie kommt man an die Daten.

Das eigentliche Problem beginnt danach oder besser gesagt „davor“.

Welche Daten brauchen wir überhaupt? – und welches Problem wollen wir damit lösen?
Was bedeutet ein Maschinenzustand? Welcher Zähler ist für unsere KPIs (bspw. OEE) relevant? Woher kommt der aktuelle Auftrag? Können wir dieselbe Information auch für Traceability, Reporting oder Analytics verwenden? Und funktioniert das noch genauso, wenn statt einer Maschine plötzlich 300 integriert werden sollen?
5.000 verfügbare SPS-Tags erzeugen noch kein belastbares OEE. Sie lösen keine Traceability. Sie reduzieren keinen Reportingaufwand. Und sie sorgen auch nicht automatisch dafür, dass Produktion und Management bessere Entscheidungen treffen können.

Das Ziel ist nicht, Maschinen anzubinden. Das Ziel ist, aus Produktionsdaten verlässliche und wiederverwendbare Informationen zu machen.

Von Martin Waßmann – IT/OT Experts

Die Maschine ist selten das eigentliche Problem

In vielen Digitalisierungsprojekten startet die Diskussion ungefähr so:

Wie bekommen wir die Daten aus der Maschine?

Das ist verständlich. Aber häufig die falsche erste Frage. Denn in den meisten Fällen bekommt man die Daten irgendwie heraus.
Viel interessanter sind Fragen wie:

• Welche Information brauchen wir überhaupt?
• Welches Businessproblem wollen wir damit lösen?
• Woher kommt diese Information heute?
• Können wir ihr vertrauen?
• Wird dieselbe Information später noch für andere Use Cases gebraucht?
• Und funktioniert das Ganze auch noch bei 50, 200 oder 500 Maschinen?

Nehmen wir ein einfaches Beispiel:

Das Unternehmen möchte OEE automatisieren. Dann lautet die Anforderung nicht:

Wir brauchen Maschinendaten.

Sondern beispielsweise:

Wir müssen wissen, wann eine Maschine produziert, wann sie steht, wie viel Gutmenge und Ausschuss produziert wurde und welcher Auftrag gerade läuft.

Das klingt ähnlich. Ist aber etwas völlig anderes.

Mehr Daten lösen das Problem nicht

Ein beliebtes Vorgehen lautet:

Wir holen erstmal alle Daten. Später schauen wir, was wir damit machen.

Kann man machen. Kann hat man später sehr viele Daten.
Glückwunsch.

Nur beantwortet die Menge der Daten nicht automatisch irgendeine relevante Frage. Eine SPS kann tausende Variablen enthalten. Für einen konkreten Use Case brauche ich vielleicht zehn davon. Oder fünf. Oder ich stelle fest, dass eine entscheidende Information überhaupt nicht aus der SPS kommt.

Der aktuelle Produktionsauftrag liegt vielleicht im MES.
Der Qualitätsstatus in einem anderen System.
Die Sollgeschwindigkeit in den Stammdaten.
Der Maschinenzustand muss aus mehreren Signalen hergeleitet werden.
Plötzlich ist das vermeintliche „Maschinendatenproblem“ gar kein Maschinenproblem mehr.

Es ist ein Informationsproblem.

OEE ist dafür ein schönes Beispiel

OEE wird gern verwendet, weil es vermeintlich einfach ist.

Availability.
Performance.
Quality.

Drei Kennzahlen. Was soll schon schiefgehen?

In der Realität ziemlich viel.
Für eine belastbare Berechnung brauche ich unter anderem:

• Maschinenzustände,
• Gutmenge,
• Ausschuss,
• geplante Produktionszeit (Wann startet die Schicht eigentlich genau?),
• Sollgeschwindigkeit oder Ideal Cycle Time,
• Auftragskontext,
• gegebenenfalls Stillstandsgründe.

Und dann beginnen die interessanten Fragen.

Was bedeutet „Maschine läuft“?
Ist Automatikbetrieb bereits Produktion?
Was passiert, wenn die Maschine läuft, aber kein Produkt produziert?
Welcher Zähler ist führend?
Wird Ausschuss direkt erfasst oder später korrigiert?
Welche Sollgeschwindigkeit gilt für welches Produkt?
Woher kommt der Auftrag?

Plötzlich ist klar:

Der Zugriff auf einen OPC-UA-Server war vermutlich der einfachste Teil des gesamten Problems.

Von einem Datenpunkt zu einer Information

Eine SPS liefert beispielsweise:

DB17.DBD24 = 126

Technisch einwandfrei. Nur weiß außerhalb der Steuerung niemand, was das bedeutet.
Eine Anwendung braucht schlussendlich mehr Kontext:

Verpackungsmaschine 5 → Geschwindigkeit = 126 Stück/min

Und vielleicht zusätzlich:

Standort → Linie → Maschine → Auftrag → Geschwindigkeit

Erst dadurch wird aus einem technischen Datenpunkt eine Information, die auch außerhalb des ursprünglichen Systems verstanden werden kann.
Genau diese Übersetzung wird in Projekten häufig unterschätzt und in Pilotprojekten übergangen.

Und sie ist einer der Gründe, warum eine einzelne Maschinenanbindung fast immer funktioniert – während der Rollout / die Skalierung später teuer wird.

Ein Pilot kann sehr erfolgreich sein – und trotzdem die falsche Architektur beweisen

Spielen wir’s mal durch:
Eine Maschine.
Ein Gateway.
Ein OPC-UA-Client.
Ein Dashboard.
Diagramme sichtbar.
Pilot erfolgreich.

So weit, so gut.

Nur sagt das noch wenig darüber aus, ob der Ansatz für einen Rollout taugt, oder? Bei der zweiten Maschine ist die Datenstruktur etwas anders. Bei Nummer fünf kommt ein anderer Hersteller dazu. Maschine 20 besitzt kein OPC UA. Maschine 35 verwendet dieselben IP-Adressen wie Maschine 12. Bei Maschine 50 stellt sich heraus, dass ein Zustandsmodell aus dem Pilot für eine andere Maschine nicht funktioniert.

Und irgendwann merkt jemand, dass jede Maschine mehrere Stunden oder Tage manuell konfiguriert werden muss.

Ein Pilot beweist, dass etwas technisch funktioniert.
Ein Rollout beweist, ob es wirtschaftlich und betrieblich funktioniert.

Das ist ein großer Unterschied.

Die Kosten entstehen durch Skalierung

Bei einer Maschine ist manuelle Arbeit noch machbar und günstig.
Bei hundert Maschinen nicht mehr.

Wenn jedes neue Asset bedeutet:

• Verbindung individuell konfigurieren,
• Variablen manuell suchen,
• Datenpunkte einzeln mappen,
• Namen korrigieren,
• Firewallregeln abstimmen,
• Zertifikate verteilen,
• Monitoring konfigurieren,
• Dokumentation schreiben,
• Anwendung X erneut anpassen,

dann habe ich kein skalierbares Integrationsmodell.
Ich habe nur denselben Projektaufwand hundertmal.

Und genau da liegt häufig der Business Case einer vernünftigen Produktionsdatenarchitektur. Nicht darin, dass Daten plötzlich moderner transportiert werden.

Sondern darin, dass der nächste Use Case und die nächste Maschine nicht wieder bei null beginnen.

Der zweite Use Case ist der eigentliche Test

Nehmen wir an, ich habe Daten einer Maschine für den KPI: OEE angebunden.

Ein halbes Jahr später kommt ein Traceability Case. Dann der nächste: Energie-Monitoring. Später danach vielleicht Predictive Maintenance oder ein KI-Anwendungsfall.

Die entscheidende Frage die ihr euch stellen solltet:

Kann ich die bereits erschlossenen Informationen wiederverwenden? Oder baut jeder Use Case seine eigene Verbindung zur Maschine? Bin ich gezwungen die Erklärung der Daten manuell in die nächste Applikation zu bringen?

Wenn OEE, Reporting, MES, Analytics und KI jeweils ihre eigene Integration aufbauen, habe ich zwar mehrere funktionierende Anwendungen.

Aber keine gemeinsame Datenarchitektur. Das funktioniert, bis es nichtmehr funktioniert. Keine gute Architektur.

Warum genau hier ein Unified Namespace interessant wird, haben wir hier beschrieben.

Brownfield heißt nicht: alte Maschinen

Brownfield wird gern mit „alter Maschinenpark“ übersetzt. Das ist mir zu einfach, denn eine relativ neue Maschine kann genauso Brownfield sein.

Entscheidend ist eher:

Ich muss mit dem arbeiten, was bereits vorhanden ist.

Und das im Grunde fast immer heterogen.

Maschine A hat OPC UA. Maschine B hat ebenfalls OPC UA – liefert aber im Wesentlichen SPS-Adressen. Maschine C spricht Modbus. Maschine D muss über S7 angebunden werden. Maschine E veröffentlicht bereits MQTT. Und bei Maschine F erklärt der Hersteller, dass Änderungen an der Steuerung nicht vorgesehen sind.

Das ist kein Sonderfall. Das ist Produktion.

Standardisieren heißt nicht, jede Maschine gleich zu machen

Genau hier entsteht häufig die nächste falsche Idee:

Dann definieren wir OPC UA als Standard und alle Maschinen müssen OPC UA können.

Kann man machen. Hilft nur wenig, wenn 70 Prozent der vorhandenen Maschinen diesen Standard nicht erfüllen. Das Brownfield lässt sich nicht wegdefinieren und auch nicht umdefinieren.

Deshalb würde ich nicht versuchen, unterhalb der Informationsschicht zwanghaft technische Einheitlichkeit herzustellen.

Die Maschine sollte über den sinnvollsten verfügbaren Weg integriert werden.
Das kann OPC UA sein. Es kann Modbus sein. Es kann etwas anderes sein.

Wichtiger ist, was anschließend passiert.

Die technische Integration darf heterogen sein. Die bereitgestellte Information sollte es möglichst nicht mehr sein.

Oder noch kürzer:

Unten darf es kompliziert sein. Oben sollte es das nicht mehr sein.

OPC UA löst nicht automatisch das Datenmodell

OPC UA ist dabei ein sehr hilfreicher Standard. Aber auch hier gilt:

OPC UA vorhanden bedeutet nicht automatisch Information verstanden.

Ich habe genügend OPC-UA-Server gesehen, die technisch hervorragend funktionieren und trotzdem kaum mehr liefern als SPS-Variablen mit kryptischen Namen.

Dann habe ich zwar eine moderne Schnittstelle, aber das fachliche Problem bleibt.

Die Frage ist deshalb nicht nur:

Können wir auf die Daten zugreifen?

Sondern:

Versteht eine Anwendung danach auch, was diese Daten bedeuten?

Warum OPC UA, MQTT und Unified Namespace unterschiedliche Aufgaben lösen, beschreiben wir hier.

Fünf Maschinenzustände – fünf verschiedene Wahrheiten

Genau dort wird es im Brownfield interessant.
Maschine A liefert:

State = 2

Maschine B:

Operating = TRUE

Maschine C:

Auto = 1
Running = 1
Fault = 0

Und bei Maschine D gibt es überhaupt keinen eindeutigen Maschinenstatus.

Für das OEE-System sollen aber alle vier liefern:

• Produktion
• Stillstand
• Störung
• geplante Pause

Also muss irgendwo aus technischen Signalen eine fachliche Information entstehen.
Wenn jede Anwendung diese Logik selbst implementiert, bekomme ich irgendwann unterschiedliche Wahrheiten.

Reporting sagt: 82 Prozent.
MES sagt: 77 Prozent.
Das Excel des Produktionsleiters sagt: 85 Prozent.
Und anschließend diskutieren alle darüber, welche Zahl stimmt.

Das Problem ist dann nicht OEE.

Das Problem ist, dass niemand festgelegt hat, was die zugrunde liegenden Informationen eigentlich bedeuten.

Wo sollte diese Übersetzung passieren?

Möglichst nah an der Quelle. Nicht zwingend direkt in der SPS.

Aber bevor die maschinenspezifischen Besonderheiten an fünf verschiedene Anwendungen weitergegeben werden.

Dann kann aus:

DB17.DBX2.1

oder:

Operating = TRUE

oder einer Kombination aus drei Signalen immer dieselbe Information werden:

MachineState = Production

Für die Anwendungen darüber spielt es anschließend keine Rolle mehr, welcher Hersteller darunter steckt.

Und genau hier beginnt Skalierung interessant zu werden.

Der Wert liegt in der Wiederverwendbarkeit

Das ist für mich einer der wichtigsten Punkte. Eine Information sollte nicht nur für einen Use Case erschlossen werden.

Wenn ein zuverlässiger Maschinenzustand einmal vorhanden ist, kann er möglicherweise verwendet werden für:

• OEE,
• Produktionsreporting,
• Schichtberichte,
• Alarmierung,
• Energieanalyse,
• Wartung,
• Analytics,
• KI.

Damit verändert sich der Business Case.
Ich finanziere nicht mehr für jeden Use Case dieselbe Integration neu.

Ich baue eine Informationsbasis, auf der weitere Anwendungen aufsetzen können.

Genau deshalb geht es bei Industrial Data nicht um möglichst viele Daten.

Es geht um möglichst gut nutzbare Informationen.

Und dann kommen Netzwerk, Security und Betrieb

Natürlich muss die Technik funktionieren. Produktionsdaten fallen schließlich nicht im Internet vom Himmel. Maschinen stehen in OT-Netzen. Dazwischen liegen normalerweise Firewalls. Zertifikate müssen verwaltet werden. IP-Adressen sind manchmal doppelt (NAT ist ein riesen Thema).
DNS und NTP sind nicht immer selbstverständlich. Maschinenhersteller brauchen natürlich Remote Access. Und irgendjemand muss merken, wenn eine Verbindung ausfällt.
Das gehört alles dazu.

Aber auch hier gilt:

Diese Themen sind Mittel zum Zweck.

Das Businessziel lautet nicht:

Wir möchten eine schöne Firewallregel.

Das Ziel lautet beispielsweise:

Produktionsinformationen aus 300 Maschinen sollen zuverlässig für mehrere Anwendungen bereitstehen.

Die Architektur muss dieses Ziel ermöglichen – sicher und betreibbar.

Skalierung bedeutet auch: Es muss betreibbar werden

Im Pilot kann ein Projektteam vieles manuell lösen. Bei 50, 200 oder 500 Maschinen funktioniert das nicht mehr.
Dann geht es nicht nur darum, ob Daten ankommen. Sondern auch darum:

• Wie werden neue Maschinen integriert?
• Wie werden Konfigurationen und Zertifikate verwaltet?
• Wie erkennen wir, wenn Daten fehlen oder eine Verbindung ausfällt?
• Wer ist für Betrieb und Änderungen verantwortlich?
• Wie kommt ein weiteres Werk dazu?

Für mich ist eine Produktionsdatenarchitektur deshalb nicht dann skalierbar, wenn theoretisch 500 Maschinen angeschlossen werden können.

Sie ist skalierbar, wenn Maschine 501 kein neues Projekt mehr ist.

Ein funktionierender Datenfluss ist noch kein funktionierender Service.

Am Ende beginnt es mit einer anderen Frage

In vielen Projekten lautet die erste Frage:

Wie bekommen wir die Daten aus der Maschine?

Ich würde anders anfangen:

Welches Problem wollen wir lösen und welche Informationen brauchen wir dafür?

Danach kommt:

1. Wo entstehen diese Informationen?
2. Wie müssen sie beschrieben werden, damit andere Systeme sie verstehen?
3. Wie können sie wiederverwendbar und skalierbar bereitgestellt werden?
4. Und erst dann: Welche Technologie brauchen wir dafür?

Das klingt banal. In Projekten wird diese Reihenfolge trotzdem erstaunlich oft umgedreht.

Dann startet die Diskussion beim Broker, beim Gateway oder bei OPC UA – und irgendwann versucht man, das Businessproblem an die ausgewählte Technologie anzupassen.

Das ist die falsche Richtung.
Technologie sollte aus der Anforderung entstehen. Nicht die Anforderung aus der Technologie.

Häufige Fragen

Ist die Maschinenanbindung im Brownfield schwierig?

Technisch meistens nicht grundsätzlich. Die größere Herausforderung besteht darin, aus unterschiedlichen Maschinen und Schnittstellen konsistente und verlässliche Informationen zu erzeugen, die für mehrere Anwendungen genutzt werden können.

Sollte man zunächst alle verfügbaren Maschinendaten erfassen?

Normalerweise nicht. Welche Informationen benötigt werden, sollte sich aus konkreten Use Cases und Geschäftsanforderungen ableiten. Mehr Daten bedeuten nicht automatisch mehr Nutzen.

Braucht jede Maschine OPC UA?

Nein. OPC UA ist häufig eine sehr gute Schnittstelle, aber Brownfield-Architekturen müssen auch mit Modbus, S7, proprietären Schnittstellen und anderen Technologien umgehen können.

Brauche ich dafür zwingend einen Unified Namespace?

Nein. Ein UNS kann ein sehr gutes Architekturkonzept sein, ist aber kein Selbstzweck.
Entscheidend ist zunächst das Problem. Danach die benötigten Informationen. Und erst dann die Architektur.

Über den Autor

Martin Waßmann ist Gründer von IT/OT Experts und unterstützt produzierende Unternehmen bei Digitalstrategie, IT/OT-Integration und skalierbaren Produktionsdatenarchitekturen. Schwerpunkte sind unter anderem Brownfield-Integration, Unified Namespace, MQTT und OPC UA.

Mehr über Martin Waßmann